On 05/01/2014 09:38 PM, Corey Minyard wrote:
> On 05/01/2014 08:11 PM, Guenter Roeck wrote:
>> 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 ?
>>
>
> That isn't enough to be able to report the pretimeout to the user.  You
> can set it and get it with those calls, but it also needs poll, fasync,
> and read to be able to select on a pretimeout or block on a read.
>

Ah, but now you are talking about a specific implementation, which is a bit
different. The question here is what you expect to occur when a pretimeout
happens, and you have a certain set of expectations. Personally I don't know
what the best solution is; maybe a sysfs attribute or, yes, some activity
on the watchdog device entry. Why don't you (or Don) suggest something
and come up with a patch set for review ?

Thanks,
Guenter


------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.  Get 
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Openipmi-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openipmi-developer

Reply via email to