> From: Corey Minyard [mailto:tcminy...@gmail.com] On Behalf Of Corey Minyard > > On 08/24/2015 10:53 PM, 河合英宏 / KAWAI，HIDEHIRO wrote: > >> From: Corey Minyard [mailto:tcminy...@gmail.com] On Behalf Of Corey Minyard > >> > >> On 08/23/2015 08:52 PM, 河合英宏 / KAWAI，HIDEHIRO wrote: > >>>> From: Corey Minyard [mailto:tcminy...@gmail.com] On Behalf Of Corey > >>>> Minyard > >>>> > >>>> On 08/17/2015 09:54 PM, 河合英宏 / KAWAI，HIDEHIRO wrote: > >>>>>> From: Corey Minyard [mailto:tcminy...@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.
Sure. I'll post the revised version with detailed comment and description later including PATCH 6/7. Thanks, Hidehiro Kawai
