Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1211691 > unrolled thread

Re: [PATCH 7/7] ipmi/kcs: Don't run the KCS state machine when it is KCS_IDLE

Started byCorey Minyard <minyard@acm.org>
First post2015-08-24 01:20 +0200
Last post2015-08-27 03:40 +0200
Articles 6 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 7/7] ipmi/kcs: Don't run the KCS state machine when it  is KCS_IDLE Corey Minyard <minyard@acm.org> - 2015-08-24 01:20 +0200
    RE: [PATCH 7/7] ipmi/kcs: Don't run the KCS state machine when it  is KCS_IDLE 河合英宏 / KAWAI，HIDEHIRO   <hidehiro.kawai.ez@hitachi.com> - 2015-08-24 04:00 +0200
      Re: [PATCH 7/7] ipmi/kcs: Don't run the KCS state machine when it  is KCS_IDLE Corey Minyard <minyard@acm.org> - 2015-08-24 18:10 +0200
        RE: [PATCH 7/7] ipmi/kcs: Don't run the KCS state machine when it  is KCS_IDLE 河合英宏 / KAWAI，HIDEHIRO   <hidehiro.kawai.ez@hitachi.com> - 2015-08-25 06:00 +0200
          Re: [PATCH 7/7] ipmi/kcs: Don't run the KCS state machine when it  is KCS_IDLE Corey Minyard <minyard@acm.org> - 2015-08-26 22:30 +0200
            RE: [PATCH 7/7] ipmi/kcs: Don't run the KCS state machine when it  is KCS_IDLE 河合英宏 / KAWAI，HIDEHIRO   <hidehiro.kawai.ez@hitachi.com> - 2015-08-27 03:40 +0200

#1211691 — Re: [PATCH 7/7] ipmi/kcs: Don't run the KCS state machine when it is KCS_IDLE

FromCorey Minyard <minyard@acm.org>
Date2015-08-24 01:20 +0200
SubjectRe: [PATCH 7/7] ipmi/kcs: Don't run the KCS state machine when it is KCS_IDLE
Message-ID<q0MIp-6Pv-3@gated-at.bofh.it>
On 08/17/2015 09:54 PM, 河合英宏 / KAWAI，HIDEHIRO wrote:
>> From: Corey Minyard [mailto:tcminyard@gmail.com] On Behalf Of Corey Minyard
>>
>> This patch will break ATN handling on the interfaces.  So we can't do this.
> I understand.  So how about doing like this:
>
> 	/* All states wait for ibf, so just do it here. */
> -	if (!check_ibf(kcs, status, time))
> +	if (kcs->state != KCS_IDLE && !check_ibf(kcs, status, time))
> 		return SI_SM_CALL_WITH_DELAY;
>
> I think it is not necessary to wait IBF when the state is IDLE.
> In this way, we can also handle the ATN case.

I think it would be more reliable to go up a level and add a timeout. 
One should
be there, anyway.  I thought they were all covered, but I may have missed
something.

-corey

>
> Regards,
>
> Hidehiro Kawai
> Hitachi, Ltd. Research & Development Group
>
>> It's going to be extremely hard to recover if the BMC is not working
>> correctly when a panic happens.  I'm not sure what can be done, but if
>> you can fix it another way it would be good.
>>
>> -corey
>>
>> On 07/27/2015 12:55 AM, Hidehiro Kawai wrote:
>>> If a BMC is unresponsive for some reason, it ends up completing
>>> the requested message as an error, then kcs_event() is called once
>>> to advance the state machine.  However, since the BMC is
>>> unresponsive now, the status of the KCS interface may not be
>>> idle.  As the result, the state machine can continue to run and
>>> comsume CPU time indefinitely even if there is no more request
>>> message.  Moreover, if this happens in run-to-completion mode
>>> (i.e. context of panic_event()), the kernel hangs up.
>>>
>>> To fix this problem, this patch ignores kcs_event() call if there
>>> is no request message to be processed.
>>>
>>> Signed-off-by: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
>>> ---
>>>  drivers/char/ipmi/ipmi_kcs_sm.c |    4 ++++
>>>  1 file changed, 4 insertions(+)
>>>
>>> diff --git a/drivers/char/ipmi/ipmi_kcs_sm.c b/drivers/char/ipmi/ipmi_kcs_sm.c
>>> index 8c25f59..0e187fb 100644
>>> --- a/drivers/char/ipmi/ipmi_kcs_sm.c
>>> +++ b/drivers/char/ipmi/ipmi_kcs_sm.c
>>> @@ -353,6 +353,10 @@ static enum si_sm_result kcs_event(struct si_sm_data *kcs, long time)
>>>  	if (kcs_debug & KCS_DEBUG_STATES)
>>>  		printk(KERN_DEBUG "KCS: State = %d, %x\n", kcs->state, status);
>>>
>>> +	/* We don't want to run the state machine when the state is IDLE */
>>> +	if (kcs->state == KCS_IDLE)
>>> +		return SI_SM_IDLE;
>>> +
>>>  	/* All states wait for ibf, so just do it here. */
>>>  	if (!check_ibf(kcs, status, time))
>>>  		return SI_SM_CALL_WITH_DELAY;
>>>
>>>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1211723

From河合英宏 / KAWAI，HIDEHIRO <hidehiro.kawai.ez@hitachi.com>
Date2015-08-24 04:00 +0200
Message-ID<q0Pdf-1LJ-3@gated-at.bofh.it>
In reply to#1211691
PiBGcm9tOiBDb3JleSBNaW55YXJkIFttYWlsdG86dGNtaW55YXJkQGdtYWlsLmNvbV0gT24gQmVo
YWxmIE9mIENvcmV5IE1pbnlhcmQNCj4gDQo+IE9uIDA4LzE3LzIwMTUgMDk6NTQgUE0sIOays+WQ
iOiLseWujyAvIEtBV0FJ77yMSElERUhJUk8gd3JvdGU6DQo+ID4+IEZyb206IENvcmV5IE1pbnlh
cmQgW21haWx0bzp0Y21pbnlhcmRAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgQ29yZXkgTWlueWFy
ZA0KPiA+Pg0KPiA+PiBUaGlzIHBhdGNoIHdpbGwgYnJlYWsgQVROIGhhbmRsaW5nIG9uIHRoZSBp
bnRlcmZhY2VzLiAgU28gd2UgY2FuJ3QgZG8gdGhpcy4NCj4gPiBJIHVuZGVyc3RhbmQuICBTbyBo
b3cgYWJvdXQgZG9pbmcgbGlrZSB0aGlzOg0KPiA+DQo+ID4gCS8qIEFsbCBzdGF0ZXMgd2FpdCBm
b3IgaWJmLCBzbyBqdXN0IGRvIGl0IGhlcmUuICovDQo+ID4gLQlpZiAoIWNoZWNrX2liZihrY3Ms
IHN0YXR1cywgdGltZSkpDQo+ID4gKwlpZiAoa2NzLT5zdGF0ZSAhPSBLQ1NfSURMRSAmJiAhY2hl
Y2tfaWJmKGtjcywgc3RhdHVzLCB0aW1lKSkNCj4gPiAJCXJldHVybiBTSV9TTV9DQUxMX1dJVEhf
REVMQVk7DQo+ID4NCj4gPiBJIHRoaW5rIGl0IGlzIG5vdCBuZWNlc3NhcnkgdG8gd2FpdCBJQkYg
d2hlbiB0aGUgc3RhdGUgaXMgSURMRS4NCj4gPiBJbiB0aGlzIHdheSwgd2UgY2FuIGFsc28gaGFu
ZGxlIHRoZSBBVE4gY2FzZS4NCj4gDQo+IEkgdGhpbmsgaXQgd291bGQgYmUgbW9yZSByZWxpYWJs
ZSB0byBnbyB1cCBhIGxldmVsIGFuZCBhZGQgYSB0aW1lb3V0Lg0KDQpJdCBtYXkgYmUgc28sIGJ1
dCB3ZSBzaG91bGQgYWRkcmVzcyB0aGlzIGlzc3VlIHNlcGFyYXRlbHkgKGF0IGxlYXN0DQpJIHRo
aW5rIGFib3ZlIHNvbHV0aW9uIHJlYXNvbmFibHkgc29sdmVzIHRoZSBpc3N1ZSkuDQoNClRoaXMg
aXNzdWUgaGFwcGVucyBhZnRlciBhbGwgcXVldWVkIG1lc3NhZ2VzIGFyZSBwcm9jZXNzZWQgb3Ig
ZHJvcHBlZA0KYnkgdGltZW91dC4gIFRoZXJlIGlzIG5vIGN1cnJlbnQgbWVzc2FnZS4gIFNvIHdo
YXQgc2hvdWxkIHdlIHNldA0KYSB0aW1lb3V0IGFnYWluc3Q/ICBXZSBjYW4gYWRkIGEgdGltZW91
dCBpbnRvIG15IG5ldyBmbHVzaF9tZXNzYWdlcygpLA0KYnV0IHRoYXQgaXMgbWVhbmluZ2Z1bCBv
bmx5IGluIHBhbmljIGNvbnRleHQuICBUaGF0IGRvZXNuJ3QgaGVscA0KaW4gbm9ybWFsIGNvbnRl
eHQ7IHdlIHdvdWxkIHBlcmZvcm0gYSBidXN5IGxvb3Agb2Ygc21pX2V2ZW50X2hhbmRsZXIoKQ0K
YW5kIHNjaGVkdWxlKCkgaW4gaXBtaV90aHJlYWQoKS4NCg0KUmVnYXJkcywNCg0KSGlkZWhpcm8g
S2F3YWkNCg0KPiBPbmUgc2hvdWxkDQo+IGJlIHRoZXJlLCBhbnl3YXkuICBJIHRob3VnaHQgdGhl
eSB3ZXJlIGFsbCBjb3ZlcmVkLCBidXQgSSBtYXkgaGF2ZSBtaXNzZWQNCj4gc29tZXRoaW5nLg0K
PiANCj4gLWNvcmV5DQo+IA0KPiA+DQo+ID4gUmVnYXJkcywNCj4gPg0KPiA+IEhpZGVoaXJvIEth
d2FpDQo+ID4gSGl0YWNoaSwgTHRkLiBSZXNlYXJjaCAmIERldmVsb3BtZW50IEdyb3VwDQo+ID4N
Cj4gPj4gSXQncyBnb2luZyB0byBiZSBleHRyZW1lbHkgaGFyZCB0byByZWNvdmVyIGlmIHRoZSBC
TUMgaXMgbm90IHdvcmtpbmcNCj4gPj4gY29ycmVjdGx5IHdoZW4gYSBwYW5pYyBoYXBwZW5zLiAg
SSdtIG5vdCBzdXJlIHdoYXQgY2FuIGJlIGRvbmUsIGJ1dCBpZg0KPiA+PiB5b3UgY2FuIGZpeCBp
dCBhbm90aGVyIHdheSBpdCB3b3VsZCBiZSBnb29kLg0KPiA+Pg0KPiA+PiAtY29yZXkNCj4gPj4N
Cj4gPj4gT24gMDcvMjcvMjAxNSAxMjo1NSBBTSwgSGlkZWhpcm8gS2F3YWkgd3JvdGU6DQo+ID4+
PiBJZiBhIEJNQyBpcyB1bnJlc3BvbnNpdmUgZm9yIHNvbWUgcmVhc29uLCBpdCBlbmRzIHVwIGNv
bXBsZXRpbmcNCj4gPj4+IHRoZSByZXF1ZXN0ZWQgbWVzc2FnZSBhcyBhbiBlcnJvciwgdGhlbiBr
Y3NfZXZlbnQoKSBpcyBjYWxsZWQgb25jZQ0KPiA+Pj4gdG8gYWR2YW5jZSB0aGUgc3RhdGUgbWFj
aGluZS4gIEhvd2V2ZXIsIHNpbmNlIHRoZSBCTUMgaXMNCj4gPj4+IHVucmVzcG9uc2l2ZSBub3cs
IHRoZSBzdGF0dXMgb2YgdGhlIEtDUyBpbnRlcmZhY2UgbWF5IG5vdCBiZQ0KPiA+Pj4gaWRsZS4g
IEFzIHRoZSByZXN1bHQsIHRoZSBzdGF0ZSBtYWNoaW5lIGNhbiBjb250aW51ZSB0byBydW4gYW5k
DQo+ID4+PiBjb21zdW1lIENQVSB0aW1lIGluZGVmaW5pdGVseSBldmVuIGlmIHRoZXJlIGlzIG5v
IG1vcmUgcmVxdWVzdA0KPiA+Pj4gbWVzc2FnZS4gIE1vcmVvdmVyLCBpZiB0aGlzIGhhcHBlbnMg
aW4gcnVuLXRvLWNvbXBsZXRpb24gbW9kZQ0KPiA+Pj4gKGkuZS4gY29udGV4dCBvZiBwYW5pY19l
dmVudCgpKSwgdGhlIGtlcm5lbCBoYW5ncyB1cC4NCj4gPj4+DQo+ID4+PiBUbyBmaXggdGhpcyBw
cm9ibGVtLCB0aGlzIHBhdGNoIGlnbm9yZXMga2NzX2V2ZW50KCkgY2FsbCBpZiB0aGVyZQ0KPiA+
Pj4gaXMgbm8gcmVxdWVzdCBtZXNzYWdlIHRvIGJlIHByb2Nlc3NlZC4NCj4gPj4+DQo+ID4+PiBT
aWduZWQtb2ZmLWJ5OiBIaWRlaGlybyBLYXdhaSA8aGlkZWhpcm8ua2F3YWkuZXpAaGl0YWNoaS5j
b20+DQo+ID4+PiAtLS0NCj4gPj4+ICBkcml2ZXJzL2NoYXIvaXBtaS9pcG1pX2tjc19zbS5jIHwg
ICAgNCArKysrDQo+ID4+PiAgMSBmaWxlIGNoYW5nZWQsIDQgaW5zZXJ0aW9ucygrKQ0KPiA+Pj4N
Cj4gPj4+IGRpZmYgLS1naXQgYS9kcml2ZXJzL2NoYXIvaXBtaS9pcG1pX2tjc19zbS5jIGIvZHJp
dmVycy9jaGFyL2lwbWkvaXBtaV9rY3Nfc20uYw0KPiA+Pj4gaW5kZXggOGMyNWY1OS4uMGUxODdm
YiAxMDA2NDQNCj4gPj4+IC0tLSBhL2RyaXZlcnMvY2hhci9pcG1pL2lwbWlfa2NzX3NtLmMNCj4g
Pj4+ICsrKyBiL2RyaXZlcnMvY2hhci9pcG1pL2lwbWlfa2NzX3NtLmMNCj4gPj4+IEBAIC0zNTMs
NiArMzUzLDEwIEBAIHN0YXRpYyBlbnVtIHNpX3NtX3Jlc3VsdCBrY3NfZXZlbnQoc3RydWN0IHNp
X3NtX2RhdGEgKmtjcywgbG9uZyB0aW1lKQ0KPiA+Pj4gIAlpZiAoa2NzX2RlYnVnICYgS0NTX0RF
QlVHX1NUQVRFUykNCj4gPj4+ICAJCXByaW50ayhLRVJOX0RFQlVHICJLQ1M6IFN0YXRlID0gJWQs
ICV4XG4iLCBrY3MtPnN0YXRlLCBzdGF0dXMpOw0KPiA+Pj4NCj4gPj4+ICsJLyogV2UgZG9uJ3Qg
d2FudCB0byBydW4gdGhlIHN0YXRlIG1hY2hpbmUgd2hlbiB0aGUgc3RhdGUgaXMgSURMRSAqLw0K
PiA+Pj4gKwlpZiAoa2NzLT5zdGF0ZSA9PSBLQ1NfSURMRSkNCj4gPj4+ICsJCXJldHVybiBTSV9T
TV9JRExFOw0KPiA+Pj4gKw0KPiA+Pj4gIAkvKiBBbGwgc3RhdGVzIHdhaXQgZm9yIGliZiwgc28g
anVzdCBkbyBpdCBoZXJlLiAqLw0KPiA+Pj4gIAlpZiAoIWNoZWNrX2liZihrY3MsIHN0YXR1cywg
dGltZSkpDQo+ID4+PiAgCQlyZXR1cm4gU0lfU01fQ0FMTF9XSVRIX0RFTEFZOw0KPiA+Pj4NCj4g
Pj4+DQoNCg==
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1212326

FromCorey Minyard <minyard@acm.org>
Date2015-08-24 18:10 +0200
Message-ID<q12tQ-4cs-5@gated-at.bofh.it>
In reply to#1211723
On 08/23/2015 08:52 PM, 河合英宏 / KAWAI，HIDEHIRO wrote:
>> From: Corey Minyard [mailto:tcminyard@gmail.com] On Behalf Of Corey Minyard
>>
>> On 08/17/2015 09:54 PM, 河合英宏 / KAWAI，HIDEHIRO wrote:
>>>> From: Corey Minyard [mailto:tcminyard@gmail.com] On Behalf Of Corey Minyard
>>>>
>>>> This patch will break ATN handling on the interfaces.  So we can't do this.
>>> I understand.  So how about doing like this:
>>>
>>> 	/* All states wait for ibf, so just do it here. */
>>> -	if (!check_ibf(kcs, status, time))
>>> +	if (kcs->state != KCS_IDLE && !check_ibf(kcs, status, time))
>>> 		return SI_SM_CALL_WITH_DELAY;
>>>
>>> I think it is not necessary to wait IBF when the state is IDLE.
>>> In this way, we can also handle the ATN case.
>> I think it would be more reliable to go up a level and add a timeout.
> It may be so, but we should address this issue separately (at least
> I think above solution reasonably solves the issue).
>
> This issue happens after all queued messages are processed or dropped
> by timeout.  There is no current message.  So what should we set
> a timeout against?  We can add a timeout into my new flush_messages(),
> but that is meaningful only in panic context.  That doesn't help
> in normal context; we would perform a busy loop of smi_event_handler()
> and schedule() in ipmi_thread().

I'm a little confused here.  Is the problem that the ATN bit is stuck
high?  If so, it's going to be really hard to work around this without
breaking ATN handling.

-corey

>
> Regards,
>
> Hidehiro Kawai
>
>> One should
>> be there, anyway.  I thought they were all covered, but I may have missed
>> something.
>>
>> -corey
>>
>>> Regards,
>>>
>>> Hidehiro Kawai
>>> Hitachi, Ltd. Research & Development Group
>>>
>>>> It's going to be extremely hard to recover if the BMC is not working
>>>> correctly when a panic happens.  I'm not sure what can be done, but if
>>>> you can fix it another way it would be good.
>>>>
>>>> -corey
>>>>
>>>> On 07/27/2015 12:55 AM, Hidehiro Kawai wrote:
>>>>> If a BMC is unresponsive for some reason, it ends up completing
>>>>> the requested message as an error, then kcs_event() is called once
>>>>> to advance the state machine.  However, since the BMC is
>>>>> unresponsive now, the status of the KCS interface may not be
>>>>> idle.  As the result, the state machine can continue to run and
>>>>> comsume CPU time indefinitely even if there is no more request
>>>>> message.  Moreover, if this happens in run-to-completion mode
>>>>> (i.e. context of panic_event()), the kernel hangs up.
>>>>>
>>>>> To fix this problem, this patch ignores kcs_event() call if there
>>>>> is no request message to be processed.
>>>>>
>>>>> Signed-off-by: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
>>>>> ---
>>>>>  drivers/char/ipmi/ipmi_kcs_sm.c |    4 ++++
>>>>>  1 file changed, 4 insertions(+)
>>>>>
>>>>> diff --git a/drivers/char/ipmi/ipmi_kcs_sm.c b/drivers/char/ipmi/ipmi_kcs_sm.c
>>>>> index 8c25f59..0e187fb 100644
>>>>> --- a/drivers/char/ipmi/ipmi_kcs_sm.c
>>>>> +++ b/drivers/char/ipmi/ipmi_kcs_sm.c
>>>>> @@ -353,6 +353,10 @@ static enum si_sm_result kcs_event(struct si_sm_data *kcs, long time)
>>>>>  	if (kcs_debug & KCS_DEBUG_STATES)
>>>>>  		printk(KERN_DEBUG "KCS: State = %d, %x\n", kcs->state, status);
>>>>>
>>>>> +	/* We don't want to run the state machine when the state is IDLE */
>>>>> +	if (kcs->state == KCS_IDLE)
>>>>> +		return SI_SM_IDLE;
>>>>> +
>>>>>  	/* All states wait for ibf, so just do it here. */
>>>>>  	if (!check_ibf(kcs, status, time))
>>>>>  		return SI_SM_CALL_WITH_DELAY;
>>>>>
>>>>>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1212682

From河合英宏 / KAWAI，HIDEHIRO <hidehiro.kawai.ez@hitachi.com>
Date2015-08-25 06:00 +0200
Message-ID<q1dyW-3lN-1@gated-at.bofh.it>
In reply to#1212326
PiBGcm9tOiBDb3JleSBNaW55YXJkIFttYWlsdG86dGNtaW55YXJkQGdtYWlsLmNvbV0gT24gQmVo
YWxmIE9mIENvcmV5IE1pbnlhcmQNCj4gDQo+IE9uIDA4LzIzLzIwMTUgMDg6NTIgUE0sIOays+WQ
iOiLseWujyAvIEtBV0FJ77yMSElERUhJUk8gd3JvdGU6DQo+ID4+IEZyb206IENvcmV5IE1pbnlh
cmQgW21haWx0bzp0Y21pbnlhcmRAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgQ29yZXkgTWlueWFy
ZA0KPiA+Pg0KPiA+PiBPbiAwOC8xNy8yMDE1IDA5OjU0IFBNLCDmsrPlkIjoi7Hlro8gLyBLQVdB
Se+8jEhJREVISVJPIHdyb3RlOg0KPiA+Pj4+IEZyb206IENvcmV5IE1pbnlhcmQgW21haWx0bzp0
Y21pbnlhcmRAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgQ29yZXkgTWlueWFyZA0KPiA+Pj4+DQo+
ID4+Pj4gVGhpcyBwYXRjaCB3aWxsIGJyZWFrIEFUTiBoYW5kbGluZyBvbiB0aGUgaW50ZXJmYWNl
cy4gIFNvIHdlIGNhbid0IGRvIHRoaXMuDQo+ID4+PiBJIHVuZGVyc3RhbmQuICBTbyBob3cgYWJv
dXQgZG9pbmcgbGlrZSB0aGlzOg0KPiA+Pj4NCj4gPj4+IAkvKiBBbGwgc3RhdGVzIHdhaXQgZm9y
IGliZiwgc28ganVzdCBkbyBpdCBoZXJlLiAqLw0KPiA+Pj4gLQlpZiAoIWNoZWNrX2liZihrY3Ms
IHN0YXR1cywgdGltZSkpDQo+ID4+PiArCWlmIChrY3MtPnN0YXRlICE9IEtDU19JRExFICYmICFj
aGVja19pYmYoa2NzLCBzdGF0dXMsIHRpbWUpKQ0KPiA+Pj4gCQlyZXR1cm4gU0lfU01fQ0FMTF9X
SVRIX0RFTEFZOw0KPiA+Pj4NCj4gPj4+IEkgdGhpbmsgaXQgaXMgbm90IG5lY2Vzc2FyeSB0byB3
YWl0IElCRiB3aGVuIHRoZSBzdGF0ZSBpcyBJRExFLg0KPiA+Pj4gSW4gdGhpcyB3YXksIHdlIGNh
biBhbHNvIGhhbmRsZSB0aGUgQVROIGNhc2UuDQo+ID4+IEkgdGhpbmsgaXQgd291bGQgYmUgbW9y
ZSByZWxpYWJsZSB0byBnbyB1cCBhIGxldmVsIGFuZCBhZGQgYSB0aW1lb3V0Lg0KPiA+IEl0IG1h
eSBiZSBzbywgYnV0IHdlIHNob3VsZCBhZGRyZXNzIHRoaXMgaXNzdWUgc2VwYXJhdGVseSAoYXQg
bGVhc3QNCj4gPiBJIHRoaW5rIGFib3ZlIHNvbHV0aW9uIHJlYXNvbmFibHkgc29sdmVzIHRoZSBp
c3N1ZSkuDQo+ID4NCj4gPiBUaGlzIGlzc3VlIGhhcHBlbnMgYWZ0ZXIgYWxsIHF1ZXVlZCBtZXNz
YWdlcyBhcmUgcHJvY2Vzc2VkIG9yIGRyb3BwZWQNCj4gPiBieSB0aW1lb3V0LiAgVGhlcmUgaXMg
bm8gY3VycmVudCBtZXNzYWdlLiAgU28gd2hhdCBzaG91bGQgd2Ugc2V0DQo+ID4gYSB0aW1lb3V0
IGFnYWluc3Q/ICBXZSBjYW4gYWRkIGEgdGltZW91dCBpbnRvIG15IG5ldyBmbHVzaF9tZXNzYWdl
cygpLA0KPiA+IGJ1dCB0aGF0IGlzIG1lYW5pbmdmdWwgb25seSBpbiBwYW5pYyBjb250ZXh0LiAg
VGhhdCBkb2Vzbid0IGhlbHANCj4gPiBpbiBub3JtYWwgY29udGV4dDsgd2Ugd291bGQgcGVyZm9y
bSBhIGJ1c3kgbG9vcCBvZiBzbWlfZXZlbnRfaGFuZGxlcigpDQo+ID4gYW5kIHNjaGVkdWxlKCkg
aW4gaXBtaV90aHJlYWQoKS4NCj4gDQo+IEknbSBhIGxpdHRsZSBjb25mdXNlZCBoZXJlLiAgSXMg
dGhlIHByb2JsZW0gdGhhdCB0aGUgQVROIGJpdCBpcyBzdHVjaw0KPiBoaWdoPyAgSWYgc28sIGl0
J3MgZ29pbmcgdG8gYmUgcmVhbGx5IGhhcmQgdG8gd29yayBhcm91bmQgdGhpcyB3aXRob3V0DQo+
IGJyZWFraW5nIEFUTiBoYW5kbGluZy4NCg0KU29ycnkgZm9yIG15IGluc3VmZmljaWVudCBleHBs
YW5hdGlvbi4gIEkgYXNzdW1lIHRoZSBjYXNlIHdoZXJlDQpJQkYgYml0IGlzIGFsd2F5cyAxLiAg
SSBkb24ndCBrbm93IHdoYXQgaGFwcGVucyB3aGVuDQpCTUMgaGFuZ3MgdXAsIGJ1dCBJIGd1ZXNz
IElCRiBzdGF5cyBpbiAxIGJlY2F1c2UgbXkgc2VydmVyJ3MNCkJNQyBiZWhhdmVzIGFzIHN1Y2gg
d2hpbGUgcmVib290aW5nLg0KDQpSZWdhcmRzLA0KDQpIaWRlaGlybyBLYXdhaQ0KDQo+ID4+IE9u
ZSBzaG91bGQNCj4gPj4gYmUgdGhlcmUsIGFueXdheS4gIEkgdGhvdWdodCB0aGV5IHdlcmUgYWxs
IGNvdmVyZWQsIGJ1dCBJIG1heSBoYXZlIG1pc3NlZA0KPiA+PiBzb21ldGhpbmcuDQo+ID4+DQo+
ID4+IC1jb3JleQ0KPiA+Pg0KPiA+Pj4gUmVnYXJkcywNCj4gPj4+DQo+ID4+PiBIaWRlaGlybyBL
YXdhaQ0KPiA+Pj4gSGl0YWNoaSwgTHRkLiBSZXNlYXJjaCAmIERldmVsb3BtZW50IEdyb3VwDQo+
ID4+Pg0KPiA+Pj4+IEl0J3MgZ29pbmcgdG8gYmUgZXh0cmVtZWx5IGhhcmQgdG8gcmVjb3ZlciBp
ZiB0aGUgQk1DIGlzIG5vdCB3b3JraW5nDQo+ID4+Pj4gY29ycmVjdGx5IHdoZW4gYSBwYW5pYyBo
YXBwZW5zLiAgSSdtIG5vdCBzdXJlIHdoYXQgY2FuIGJlIGRvbmUsIGJ1dCBpZg0KPiA+Pj4+IHlv
dSBjYW4gZml4IGl0IGFub3RoZXIgd2F5IGl0IHdvdWxkIGJlIGdvb2QuDQo+ID4+Pj4NCj4gPj4+
PiAtY29yZXkNCj4gPj4+Pg0KPiA+Pj4+IE9uIDA3LzI3LzIwMTUgMTI6NTUgQU0sIEhpZGVoaXJv
IEthd2FpIHdyb3RlOg0KPiA+Pj4+PiBJZiBhIEJNQyBpcyB1bnJlc3BvbnNpdmUgZm9yIHNvbWUg
cmVhc29uLCBpdCBlbmRzIHVwIGNvbXBsZXRpbmcNCj4gPj4+Pj4gdGhlIHJlcXVlc3RlZCBtZXNz
YWdlIGFzIGFuIGVycm9yLCB0aGVuIGtjc19ldmVudCgpIGlzIGNhbGxlZCBvbmNlDQo+ID4+Pj4+
IHRvIGFkdmFuY2UgdGhlIHN0YXRlIG1hY2hpbmUuICBIb3dldmVyLCBzaW5jZSB0aGUgQk1DIGlz
DQo+ID4+Pj4+IHVucmVzcG9uc2l2ZSBub3csIHRoZSBzdGF0dXMgb2YgdGhlIEtDUyBpbnRlcmZh
Y2UgbWF5IG5vdCBiZQ0KPiA+Pj4+PiBpZGxlLiAgQXMgdGhlIHJlc3VsdCwgdGhlIHN0YXRlIG1h
Y2hpbmUgY2FuIGNvbnRpbnVlIHRvIHJ1biBhbmQNCj4gPj4+Pj4gY29tc3VtZSBDUFUgdGltZSBp
bmRlZmluaXRlbHkgZXZlbiBpZiB0aGVyZSBpcyBubyBtb3JlIHJlcXVlc3QNCj4gPj4+Pj4gbWVz
c2FnZS4gIE1vcmVvdmVyLCBpZiB0aGlzIGhhcHBlbnMgaW4gcnVuLXRvLWNvbXBsZXRpb24gbW9k
ZQ0KPiA+Pj4+PiAoaS5lLiBjb250ZXh0IG9mIHBhbmljX2V2ZW50KCkpLCB0aGUga2VybmVsIGhh
bmdzIHVwLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBUbyBmaXggdGhpcyBwcm9ibGVtLCB0aGlzIHBhdGNo
IGlnbm9yZXMga2NzX2V2ZW50KCkgY2FsbCBpZiB0aGVyZQ0KPiA+Pj4+PiBpcyBubyByZXF1ZXN0
IG1lc3NhZ2UgdG8gYmUgcHJvY2Vzc2VkLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBTaWduZWQtb2ZmLWJ5
OiBIaWRlaGlybyBLYXdhaSA8aGlkZWhpcm8ua2F3YWkuZXpAaGl0YWNoaS5jb20+DQo+ID4+Pj4+
IC0tLQ0KPiA+Pj4+PiAgZHJpdmVycy9jaGFyL2lwbWkvaXBtaV9rY3Nfc20uYyB8ICAgIDQgKysr
Kw0KPiA+Pj4+PiAgMSBmaWxlIGNoYW5nZWQsIDQgaW5zZXJ0aW9ucygrKQ0KPiA+Pj4+Pg0KPiA+
Pj4+PiBkaWZmIC0tZ2l0IGEvZHJpdmVycy9jaGFyL2lwbWkvaXBtaV9rY3Nfc20uYyBiL2RyaXZl
cnMvY2hhci9pcG1pL2lwbWlfa2NzX3NtLmMNCj4gPj4+Pj4gaW5kZXggOGMyNWY1OS4uMGUxODdm
YiAxMDA2NDQNCj4gPj4+Pj4gLS0tIGEvZHJpdmVycy9jaGFyL2lwbWkvaXBtaV9rY3Nfc20uYw0K
PiA+Pj4+PiArKysgYi9kcml2ZXJzL2NoYXIvaXBtaS9pcG1pX2tjc19zbS5jDQo+ID4+Pj4+IEBA
IC0zNTMsNiArMzUzLDEwIEBAIHN0YXRpYyBlbnVtIHNpX3NtX3Jlc3VsdCBrY3NfZXZlbnQoc3Ry
dWN0IHNpX3NtX2RhdGEgKmtjcywgbG9uZyB0aW1lKQ0KPiA+Pj4+PiAgCWlmIChrY3NfZGVidWcg
JiBLQ1NfREVCVUdfU1RBVEVTKQ0KPiA+Pj4+PiAgCQlwcmludGsoS0VSTl9ERUJVRyAiS0NTOiBT
dGF0ZSA9ICVkLCAleFxuIiwga2NzLT5zdGF0ZSwgc3RhdHVzKTsNCj4gPj4+Pj4NCj4gPj4+Pj4g
KwkvKiBXZSBkb24ndCB3YW50IHRvIHJ1biB0aGUgc3RhdGUgbWFjaGluZSB3aGVuIHRoZSBzdGF0
ZSBpcyBJRExFICovDQo+ID4+Pj4+ICsJaWYgKGtjcy0+c3RhdGUgPT0gS0NTX0lETEUpDQo+ID4+
Pj4+ICsJCXJldHVybiBTSV9TTV9JRExFOw0KPiA+Pj4+PiArDQo+ID4+Pj4+ICAJLyogQWxsIHN0
YXRlcyB3YWl0IGZvciBpYmYsIHNvIGp1c3QgZG8gaXQgaGVyZS4gKi8NCj4gPj4+Pj4gIAlpZiAo
IWNoZWNrX2liZihrY3MsIHN0YXR1cywgdGltZSkpDQo+ID4+Pj4+ICAJCXJldHVybiBTSV9TTV9D
QUxMX1dJVEhfREVMQVk7DQo+ID4+Pj4+DQo+ID4+Pj4+DQoNCg==
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1214172

FromCorey Minyard <minyard@acm.org>
Date2015-08-26 22:30 +0200
Message-ID<q1Puz-7Y2-35@gated-at.bofh.it>
In reply to#1212682
On 08/24/2015 10:53 PM, 河合英宏 / KAWAI，HIDEHIRO wrote:
>> From: Corey Minyard [mailto:tcminyard@gmail.com] On Behalf Of Corey Minyard
>>
>> On 08/23/2015 08:52 PM, 河合英宏 / KAWAI，HIDEHIRO wrote:
>>>> From: Corey Minyard [mailto:tcminyard@gmail.com] On Behalf Of Corey Minyard
>>>>
>>>> On 08/17/2015 09:54 PM, 河合英宏 / KAWAI，HIDEHIRO wrote:
>>>>>> From: Corey Minyard [mailto:tcminyard@gmail.com] On Behalf Of Corey Minyard
>>>>>>
>>>>>> This patch will break ATN handling on the interfaces.  So we can't do this.
>>>>> I understand.  So how about doing like this:
>>>>>
>>>>> 	/* All states wait for ibf, so just do it here. */
>>>>> -	if (!check_ibf(kcs, status, time))
>>>>> +	if (kcs->state != KCS_IDLE && !check_ibf(kcs, status, time))
>>>>> 		return SI_SM_CALL_WITH_DELAY;
>>>>>
>>>>> I think it is not necessary to wait IBF when the state is IDLE.
>>>>> In this way, we can also handle the ATN case.
>>>> I think it would be more reliable to go up a level and add a timeout.
>>> It may be so, but we should address this issue separately (at least
>>> I think above solution reasonably solves the issue).
>>>
>>> This issue happens after all queued messages are processed or dropped
>>> by timeout.  There is no current message.  So what should we set
>>> a timeout against?  We can add a timeout into my new flush_messages(),
>>> but that is meaningful only in panic context.  That doesn't help
>>> in normal context; we would perform a busy loop of smi_event_handler()
>>> and schedule() in ipmi_thread().
>> I'm a little confused here.  Is the problem that the ATN bit is stuck
>> high?  If so, it's going to be really hard to work around this without
>> breaking ATN handling.
> Sorry for my insufficient explanation.  I assume the case where
> IBF bit is always 1.  I don't know what happens when
> BMC hangs up, but I guess IBF stays in 1 because my server's
> BMC behaves as such while rebooting.
>
Ok, your patch above makes sense, then.  IBF is irrelevant when in idle
state,
so ignore it then, and then in your case it will return KCS_IDLE and
cause that
operation to complete.  I'm ok with the patch you posted above, I think
it will
work correctly and solve the problem.

I would like a detailed comment, though, so people (forgetful people
like me :)
can figure out why it is there.  I'd also like to save this one until
4.4 to give it some
time in linux-next for people to find issues.

Thanks,

-corey
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1214266

From河合英宏 / KAWAI，HIDEHIRO <hidehiro.kawai.ez@hitachi.com>
Date2015-08-27 03:40 +0200
Message-ID<q1Ukx-6pj-3@gated-at.bofh.it>
In reply to#1214172
PiBGcm9tOiBDb3JleSBNaW55YXJkIFttYWlsdG86dGNtaW55YXJkQGdtYWlsLmNvbV0gT24gQmVo
YWxmIE9mIENvcmV5IE1pbnlhcmQNCj4gDQo+IE9uIDA4LzI0LzIwMTUgMTA6NTMgUE0sIOays+WQ
iOiLseWujyAvIEtBV0FJ77yMSElERUhJUk8gd3JvdGU6DQo+ID4+IEZyb206IENvcmV5IE1pbnlh
cmQgW21haWx0bzp0Y21pbnlhcmRAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgQ29yZXkgTWlueWFy
ZA0KPiA+Pg0KPiA+PiBPbiAwOC8yMy8yMDE1IDA4OjUyIFBNLCDmsrPlkIjoi7Hlro8gLyBLQVdB
Se+8jEhJREVISVJPIHdyb3RlOg0KPiA+Pj4+IEZyb206IENvcmV5IE1pbnlhcmQgW21haWx0bzp0
Y21pbnlhcmRAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgQ29yZXkgTWlueWFyZA0KPiA+Pj4+DQo+
ID4+Pj4gT24gMDgvMTcvMjAxNSAwOTo1NCBQTSwg5rKz5ZCI6Iux5a6PIC8gS0FXQUnvvIxISURF
SElSTyB3cm90ZToNCj4gPj4+Pj4+IEZyb206IENvcmV5IE1pbnlhcmQgW21haWx0bzp0Y21pbnlh
cmRAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgQ29yZXkgTWlueWFyZA0KPiA+Pj4+Pj4NCj4gPj4+
Pj4+IFRoaXMgcGF0Y2ggd2lsbCBicmVhayBBVE4gaGFuZGxpbmcgb24gdGhlIGludGVyZmFjZXMu
ICBTbyB3ZSBjYW4ndCBkbyB0aGlzLg0KPiA+Pj4+PiBJIHVuZGVyc3RhbmQuICBTbyBob3cgYWJv
dXQgZG9pbmcgbGlrZSB0aGlzOg0KPiA+Pj4+Pg0KPiA+Pj4+PiAJLyogQWxsIHN0YXRlcyB3YWl0
IGZvciBpYmYsIHNvIGp1c3QgZG8gaXQgaGVyZS4gKi8NCj4gPj4+Pj4gLQlpZiAoIWNoZWNrX2li
ZihrY3MsIHN0YXR1cywgdGltZSkpDQo+ID4+Pj4+ICsJaWYgKGtjcy0+c3RhdGUgIT0gS0NTX0lE
TEUgJiYgIWNoZWNrX2liZihrY3MsIHN0YXR1cywgdGltZSkpDQo+ID4+Pj4+IAkJcmV0dXJuIFNJ
X1NNX0NBTExfV0lUSF9ERUxBWTsNCj4gPj4+Pj4NCj4gPj4+Pj4gSSB0aGluayBpdCBpcyBub3Qg
bmVjZXNzYXJ5IHRvIHdhaXQgSUJGIHdoZW4gdGhlIHN0YXRlIGlzIElETEUuDQo+ID4+Pj4+IElu
IHRoaXMgd2F5LCB3ZSBjYW4gYWxzbyBoYW5kbGUgdGhlIEFUTiBjYXNlLg0KPiA+Pj4+IEkgdGhp
bmsgaXQgd291bGQgYmUgbW9yZSByZWxpYWJsZSB0byBnbyB1cCBhIGxldmVsIGFuZCBhZGQgYSB0
aW1lb3V0Lg0KPiA+Pj4gSXQgbWF5IGJlIHNvLCBidXQgd2Ugc2hvdWxkIGFkZHJlc3MgdGhpcyBp
c3N1ZSBzZXBhcmF0ZWx5IChhdCBsZWFzdA0KPiA+Pj4gSSB0aGluayBhYm92ZSBzb2x1dGlvbiBy
ZWFzb25hYmx5IHNvbHZlcyB0aGUgaXNzdWUpLg0KPiA+Pj4NCj4gPj4+IFRoaXMgaXNzdWUgaGFw
cGVucyBhZnRlciBhbGwgcXVldWVkIG1lc3NhZ2VzIGFyZSBwcm9jZXNzZWQgb3IgZHJvcHBlZA0K
PiA+Pj4gYnkgdGltZW91dC4gIFRoZXJlIGlzIG5vIGN1cnJlbnQgbWVzc2FnZS4gIFNvIHdoYXQg
c2hvdWxkIHdlIHNldA0KPiA+Pj4gYSB0aW1lb3V0IGFnYWluc3Q/ICBXZSBjYW4gYWRkIGEgdGlt
ZW91dCBpbnRvIG15IG5ldyBmbHVzaF9tZXNzYWdlcygpLA0KPiA+Pj4gYnV0IHRoYXQgaXMgbWVh
bmluZ2Z1bCBvbmx5IGluIHBhbmljIGNvbnRleHQuICBUaGF0IGRvZXNuJ3QgaGVscA0KPiA+Pj4g
aW4gbm9ybWFsIGNvbnRleHQ7IHdlIHdvdWxkIHBlcmZvcm0gYSBidXN5IGxvb3Agb2Ygc21pX2V2
ZW50X2hhbmRsZXIoKQ0KPiA+Pj4gYW5kIHNjaGVkdWxlKCkgaW4gaXBtaV90aHJlYWQoKS4NCj4g
Pj4gSSdtIGEgbGl0dGxlIGNvbmZ1c2VkIGhlcmUuICBJcyB0aGUgcHJvYmxlbSB0aGF0IHRoZSBB
VE4gYml0IGlzIHN0dWNrDQo+ID4+IGhpZ2g/ICBJZiBzbywgaXQncyBnb2luZyB0byBiZSByZWFs
bHkgaGFyZCB0byB3b3JrIGFyb3VuZCB0aGlzIHdpdGhvdXQNCj4gPj4gYnJlYWtpbmcgQVROIGhh
bmRsaW5nLg0KPiA+IFNvcnJ5IGZvciBteSBpbnN1ZmZpY2llbnQgZXhwbGFuYXRpb24uICBJIGFz
c3VtZSB0aGUgY2FzZSB3aGVyZQ0KPiA+IElCRiBiaXQgaXMgYWx3YXlzIDEuICBJIGRvbid0IGtu
b3cgd2hhdCBoYXBwZW5zIHdoZW4NCj4gPiBCTUMgaGFuZ3MgdXAsIGJ1dCBJIGd1ZXNzIElCRiBz
dGF5cyBpbiAxIGJlY2F1c2UgbXkgc2VydmVyJ3MNCj4gPiBCTUMgYmVoYXZlcyBhcyBzdWNoIHdo
aWxlIHJlYm9vdGluZy4NCj4gPg0KPiBPaywgeW91ciBwYXRjaCBhYm92ZSBtYWtlcyBzZW5zZSwg
dGhlbi4gIElCRiBpcyBpcnJlbGV2YW50IHdoZW4gaW4gaWRsZQ0KPiBzdGF0ZSwNCj4gc28gaWdu
b3JlIGl0IHRoZW4sIGFuZCB0aGVuIGluIHlvdXIgY2FzZSBpdCB3aWxsIHJldHVybiBLQ1NfSURM
RSBhbmQNCj4gY2F1c2UgdGhhdA0KPiBvcGVyYXRpb24gdG8gY29tcGxldGUuICBJJ20gb2sgd2l0
aCB0aGUgcGF0Y2ggeW91IHBvc3RlZCBhYm92ZSwgSSB0aGluaw0KPiBpdCB3aWxsDQo+IHdvcmsg
Y29ycmVjdGx5IGFuZCBzb2x2ZSB0aGUgcHJvYmxlbS4NCj4gDQo+IEkgd291bGQgbGlrZSBhIGRl
dGFpbGVkIGNvbW1lbnQsIHRob3VnaCwgc28gcGVvcGxlIChmb3JnZXRmdWwgcGVvcGxlDQo+IGxp
a2UgbWUgOikNCj4gY2FuIGZpZ3VyZSBvdXQgd2h5IGl0IGlzIHRoZXJlLg0KDQpTdXJlLiAgSSds
bCBwb3N0IHRoZSByZXZpc2VkIHZlcnNpb24gd2l0aCBkZXRhaWxlZCBjb21tZW50IGFuZA0KZGVz
Y3JpcHRpb24gbGF0ZXIgaW5jbHVkaW5nIFBBVENIIDYvNy4NCg0KVGhhbmtzLA0KDQpIaWRlaGly
byBLYXdhaQ0KDQo=
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web