Rocky Craig wrote:
> Corey Minyard wrote:
>
>
>> This is a proposed patch I would like people to look at. I've had
>> complaints in the past about the bogus logs and other bad effects while
>> in firmware update mode or after a BMC reset. This will hopefully fix
>> those problems.
>>
>>
>>
> I'm not sure I undestand the use model: if I know I'm going to cause
> a long timeout, is it up to me (user code) to enter this new mode?
> It seems a little heavy-handed for corner-case use (firmware updates).
>
Use cases would be handy, true :). Here are a few:
* The user sends a cold reset to the BMC. The BMC will be resetting
and thus will not be able to respond for some period of time. The
driver, when it sees the cold reset command, will automatically
not autonomously message the BMC for 30 seconds. Note it is still
the responsibility of the user to not send any commands in the
period the BMC is resetting.
* The user does a firmware upgrade using the firmware NetFN. The
BMC has a firmware upgrade mode and will not properly handle any
other commands when in firmware upgrade mode, only firmware
upgrade commands. The driver will automatically detect the
firmware upgrade commands and will not autonomously send a message
to the BMC until 30 seconds after the last firmware upgrade
command from the user.
* The user does a firmware upgrade, but the upgrade does not use the
firmware NetFN (at least not often enough to complete the upgrade
without the driver kicking things back off). The upgrade program
must put the driver into maintenance mode using the ioctl, do the
upgrade, then put the driver back into auto mode.
* The user has some other reason to want to keep the driver from
doing anything autonomously to the BMC besides looking at the
status register. It can manually put the driver into maintenance
mode. Maybe some type of calibration, performance test, or
something of that nature.
The heavy-handedness of this is in two places. It checks every message
sent to see if it is one that should put the driver into maintenance
mode. And it checks at the normal timeout times (100ms) to time out the
auto maintenance timeout. I'm going to modify the timeout checks a
little so it doesn't normally claim the lock, so it's only one check
there. That should make things better in the timer. No lock is claimed
in the message unless it is one of the given commands, and those are not
commonly used.
The code would be a lot simpler if the driver only supported manually
going into maintenance mode. However, what is currently there will work
automatically for every upgrade program I have seen.
> On the BT side, when the fix goes in to automatically come out of the
> hosed state due to these long absences, the need for this maintenance
> mode code should be reduced. I'm still waiting to hear back from
> the Motorola guys on some questions, but I may submit that part of
> the patch without hearing from them.
>
The issues are not directly related; people have complained about this
since before there was a BT driver. I would like to get the BT issues
resolved, though :).
> Also, I like the other patch about suppressing the kernel thread
> when an IRQ has been successfully registered.
>
Thanks for the feedback.
-Corey
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Openipmi-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
