Re: [parisc-linux] ksoftirqd eats 100% cpu :-(

Re: [parisc-linux] ksoftirqd eats 100% cpu :-(

[Thibaut VARENE]

Tilo Riemer wrote:
> Hello list,
> 
> I use Debian 3.0 on an HP9000/710. Almost all works fine, but the 
> ksoftirqd eats all cpu time. I read that it's a bug in the kernel. Is 
> there a patch for fixing this problem?
It's a well known bug. on 7x0 and 7x5 boxes.

Maybe we should add a faq entry ?


-- 
Thibaut VARENE
PA/Linux ESIEE Team
http://pateam.esiee.fr/

[parisc-linux] ksoftirqd eats 100% cpu :-(

[Tilo Riemer]

Hello list,

I use Debian 3.0 on an HP9000/710. Almost all works fine, but the 
ksoftirqd eats all cpu time. I read that it's a bug in the kernel. Is 
there a patch for fixing this problem?


Best regards, Tilo

Re: [parisc-linux] ksoftirqd eats 100% cpu :-(

[Helge Deller]

On Monday 07 October 2002 17:20, Thibaut VARENE wrote:
> Tilo Riemer wrote:
> > Hello list,
> >
> > I use Debian 3.0 on an HP9000/710. Almost all works fine, but the
> > ksoftirqd eats all cpu time. I read that it's a bug in the kernel. Is
> > there a patch for fixing this problem?
>
> It's a well known bug. on 7x0 and 7x5 boxes.

It's a bug/feature related to the HIL drivers. 
Since we have to poll the HIL ports the whole time
the bunch of running timers increase the ksoftirqd load a lot.

> Maybe we should add a faq entry ?

This would be great.

Helge

Re: [parisc-linux] ksoftirqd eats 100% cpu :-(

[Tilo Riemer]

Hello,


>>>I use Debian 3.0 on an HP9000/710. Almost all works fine, but the
>>>ksoftirqd eats all cpu time. I read that it's a bug in the kernel. Is
>>>there a patch for fixing this problem?
>>
> It's a bug/feature related to the HIL drivers. 
> Since we have to poll the HIL ports the whole time
> the bunch of running timers increase the ksoftirqd load a lot.

Okay, if it's a feature and not a bug I can sleep without worries ;-)


Best regards and thanks, Tilo

Re: [parisc-linux] ksoftirqd eats 100% cpu :-(

[Tilo Riemer]

Hello list,

>>>I use Debian 3.0 on an HP9000/710. Almost all works fine, but the
>>>ksoftirqd eats all cpu time. I read that it's a bug in the kernel. Is
>>>there a patch for fixing this problem?

> It's a bug/feature related to the HIL drivers. 
> Since we have to poll the HIL ports the whole time
> the bunch of running timers increase the ksoftirqd load a lot.

Btw, if the mouse and keyboard are attached, the ksoftirqd needs about 
50-60%, without mouse and keyboard, it needs 100%.


Best regards, Tilo

Re: [parisc-linux] ksoftirqd eats 100% cpu :-(

[John Marvin]

> It's a bug/feature related to the HIL drivers.
> Since we have to poll the HIL ports the whole time
> the bunch of running timers increase the ksoftirqd load a lot.

I understand that polling is necessary while sending commands out
to hil devices, but input should be interrupt driven. What is the
reason for all of the polling?

John Marvin
jsm@fc.hp.com

Re: [parisc-linux] ksoftirqd eats 100% cpu :-(

[Carlos O'Donell]

> 
> > It's a bug/feature related to the HIL drivers.
> > Since we have to poll the HIL ports the whole time
> > the bunch of running timers increase the ksoftirqd load a lot.
> 
> I understand that polling is necessary while sending commands out
> to hil devices, but input should be interrupt driven. What is the
> reason for all of the polling?
> 
> John Marvin
> jsm@fc.hp.com


It's interrupt driven, but the ISR _always_ calls tasklet_schedule 
to do the real work. The HIL state machine and SERIO layer hooks
in a function to it's own tasklet so it can update on interrupt.

Most drivers usage of tasklets involves:

a- Setup and enable during module init
b- Leave them alone.

I assume that this is the case, because tasklets are CPU intensive.
It would be nice to have someone investiage this... if not, it goes
on the end of my now _really_ long todo list :)

c.

Re: [parisc-linux] ksoftirqd eats 100% cpu :-(

[Brian S. Julin]

On Tue, 8 Oct 2002, John Marvin wrote:
> I understand that polling is necessary while sending commands out
> to hil devices, but input should be interrupt driven. What is the
> reason for all of the polling?

The polling in the driver can definitely be improved.  I haven't
had the inspiration to go do so yet.

First off, on a system that has just a mouse and keyboard, doesn't
need to use any of the other features in the HP SDC (the real time
clock, which seems redundant in most systems capable of running
parisc-linux, the timers, and the tone generator), and doesn't need to
keep track of plug/unplug events for multiple mice/keyboards or transfer
large amounts of data to the HIL, which is probably going to be 90%+ of
the user base, a much simpler driver that allows the i8042 firmware to drive
the HIL MLC could be written, sort of like the USB_HIDBP stuff.

The HIL driver that's in there now is more like the full-fledged
USB driver, and repolls of the loop to check for added/removed
devices are done manually, which allows more information to be extracted
from the devices during this process.  Unfortunately, because the MLC was
designed a bit cretinously, it expects the host to wait for timeouts
and responses.  The current design uses a state machine to keep
those delays from having an impact on the real-time scheduling, rather
than busy-polling.  Unfortunately again, the system clock only has a 100HZ
frequency, so in order to provide timely responses the driver runs an
opportunistic tasklet in order to catch the CPU during a context
switch.  The linux tasket scheduler is a bit limited in that you
cannot tell it not to re-call a tasklet more than once every
N nanoseconds unless that N is as large as a full clock tick (10ms).

So most of the time the tasklet gets woken up, decides there's nothing
to do, and goes back to bed.  This should only takes a very few CPU
cycles (238 to be precise), so I don't know why it accounts for so much
time.  I guess the kernel decides when the system is idle to run the
tasklets continuously, which is not the way I was expecting them to behave
(I was expecting them to run one time per IRQ, and once all the taskets
returned and there was no work to do in userspace, the idle task would
start.  I believe that that is what the documentation I was using said
would happen when a tasklet rechedules itself, but apparently it was
wrong.)

Rest assured that the HIL driver does move aside for real work, it's
just taking the place of the idle task, really.  Not that that's
a good thing -- the idle task is supposed to use any power-saving
CPU instructions available to decrease power consumption.

BTW, does anyone have any hardware that does host-to-HIL transfers?
So far the only one I could potentially test with is the tiny
command that sets the autorepeat rate on the keyboard -- I don't even have
a keyboard with LEDs :-(

Additionally I'm interested to know if the HIL MLC chipsets were ever
used in system without the accompanying i8042.

--
Brian S. Julin

Re: [parisc-linux] ksoftirqd eats 100% cpu :-(

[Enrik Berkhan]

Hi,

On Tue, Oct 08, 2002 at 11:46:46PM -0400, Brian S. Julin wrote:
> BTW, does anyone have any hardware that does host-to-HIL transfers?

How about a "46081A HP-HIL / AUDIO EXTENSION"? Shouldn't this need
host-to-HIL transfers for audio output?

Cheers,
Enrik

Re: [parisc-linux] ksoftirqd eats 100% cpu :-(

[Tilo Riemer]

hello,

what does happen if I compile my own kernel without HIL support? My 
machine runs as server without keyboard and mouse and I hope I must 
never use the keyboard ;-)

Best regards, Tilo

Re: [parisc-linux] ksoftirqd eats 100% cpu :-(

[Helge Deller]

On Friday 11 October 2002 10:21, Tilo Riemer wrote:
> what does happen if I compile my own kernel without HIL support? My
> machine runs as server without keyboard and mouse and I hope I must
> never use the keyboard ;-)

Should work and you have no load at all.

Greetings,
Helge