Re: ipmi watchdog questions

[Guenter Roeck <linux@roeck-us.net>]

On 05/01/2014 05:38 PM, Corey Minyard wrote:
> On 05/01/2014 08:58 AM, Don Zickus wrote:
>> Hi Corey,
>>
>> I stumbled upon an issue with a partner of ours, where they booted their
>> machine and tried to load the ipmi_watchdog module by hand and it failed.
>>
>> The reason it failed was that the iTCO watchdog driver was already loaded
>> and it registered the misc device /dev/watchdog first.
>>
>> I looked at the ipmi watchdog driver and realized it was never converted
>> to the new watchdog framework where the watchdog_core module manages the
>> '/dev/watchdog' misc device.
>>
>> So being naive and not knowing much about IPMI, I decided to follow the
>> helpful document Documentation/watchdog/convert_drivers_to_kernel_api.txt
>> and convert the ipmi_watchdog to use the new watchdog framework.
>>
>> I ran into a few issues and then realized the driver itself never really
>> binds to any hardware, so it makes the conversion process a little more
>> challenging.
>>
>> So a few questions to you before I waste my time in this area:
>>
>> - Is there any prior history about why the ipmi_watchdog was never
>>    converted to the new watchdog framework?  Lack of interest? Technical
>> hurdles?
>
> Mostly lack of interest, but there are some technical hurdles.
>
> It would be hard to implement some things.  The watchdog framework has
> no concept of pretimeouts.  And IPMI is message based, you send a

Are you saying that WDIOC_SETPRETIMEOUT and WDIOC_GETPRETIMEOUT don't work
for ipmi ? If so, can you explain ?

> message to a controller to do anything, and you have to wait for the
> response.  That doesn't work very well with the watchdog interface,
> which assumes you can do everything immediately.
>
Does it ? How so ? Please elaborate; I don't immediately see how the watchdog
subsystem would prevent you from using, say, kernel threads or delayed workers
to implement asynchronous access to or from any underlying hardware.

Guenter