minyard at acm
Jun 23, 2006, 4:44 PM
Post #7 of 9
I also had a report from Matt that running the driver full-bore caused
Re: [Openipmi-developer] BUG: soft lockup detected on CPU#1, ipmi_si
[In reply to]
the mouse to go haywire. I did some testing and the mouse didn't go
haywire, but my keyboard did. I changed the udelay(1) to schedule() and
kipmi0 is running at 100% as I type right now, and things seem to be
running smoothly. Testing the performance, I got 4.5ms per message for
a get device id, which was the same as I saw before the change. So I
think this change is a good idea.
I'll let Peter test it out when he gets his machines back, and if it all
looks good I'll do a patch.
Matt Domsch wrote:
> On Thu, Jun 22, 2006 at 09:03:12AM -0500, Corey Minyard wrote:
>> Peter, can you make a code change for me and try something out?
>> If possible, could you change the call to udelay(1) in the function
>> ipmi_thread() in drivers/char/ipmi_si_intf.c to be a call to schedule()
>> instead? I'm guessing that will fix this problem.
> won't that cause the thread to be scheduled out for at least one timer
> tick (1-10ms depending on HZ), especially as it's at nice 19? This
> will cause the commands to be quite slow, which was the primary reason
> for the kthread here in the first place.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/