Interrupt hick ups

Interrupt hick ups

[Geert Uytterhoeven]

	Hi,

Since a few kernel versions (late 2.3.x), I see interrupt hick ups when doing
disk access on my Sym53c875. I.e. when I'm typing something and the disk
shows a lot of activity, keystrokes and mouse moves happen in burst with some
delay (ca. 2 seconds).

Anyone seeing a similar thing? This is on a CHRP LongTrail.

           CPU0
  1:       3232   i8259         keyboard
  2:          0   i8259         82c59 secondary cascade
  3:      33331   i8259         serial
  4:          9   i8259         serial
  8:          0   i8259         rtc
 16:          0   OpenPIC       82c59 cascade
 22:     385557   OpenPIC       MESH
 29:      30531   OpenPIC       eth0
 31:     218039   OpenPIC       sym53c8xx
BAD:          8

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Interrupt hick ups

[Geert Uytterhoeven]

On Tue, 13 Jun 2000, Geert Uytterhoeven wrote:
> Since a few kernel versions (late 2.3.x), I see interrupt hick ups when doing
> disk access on my Sym53c875. I.e. when I'm typing something and the disk
> shows a lot of activity, keystrokes and mouse moves happen in burst with some
> delay (ca. 2 seconds).
>
> Anyone seeing a similar thing? This is on a CHRP LongTrail.
>
>            CPU0
>   1:       3232   i8259         keyboard
>   2:          0   i8259         82c59 secondary cascade
>   3:      33331   i8259         serial
>   4:          9   i8259         serial
>   8:          0   i8259         rtc
>  16:          0   OpenPIC       82c59 cascade
>  22:     385557   OpenPIC       MESH
>  29:      30531   OpenPIC       eth0
>  31:     218039   OpenPIC       sym53c8xx
> BAD:          8

It doesn't seem to happen with the 2.4.0-test1 I compiled on june 4, while
2.4.0-test1-ac7 suffers from the problem.

I suspect the changes in open_pic.c that replaced the calls to unmask_irq()
by something different?

The hick ups seem to cause temporary complete system lock ups for ca. 1.75
seconds (repeated wrist watch timing).

Gr{oetje,eeting}s,

				    Geert (in a `guessing' mood today)

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Interrupt hick ups

[Martin Costabel]

Geert Uytterhoeven wrote:
>
> On Tue, 13 Jun 2000, Geert Uytterhoeven wrote:
> > Since a few kernel versions (late 2.3.x), I see interrupt hick ups when doing
> > disk access on my Sym53c875. I.e. when I'm typing something and the disk
> > shows a lot of activity, keystrokes and mouse moves happen in burst with some
> > delay (ca. 2 seconds).
> >
> > Anyone seeing a similar thing? This is on a CHRP LongTrail.

Do you still see this in -ac16 or later? I had this, too, and from
linux-kernel I understand that everyody had it, but it's gone now.

What is gone too, unfortunately, is the phenomenal IDE speed
improvement. In late 2.3.99/early 2.4.0-test1, I had a "hdparm
-t"-measured throughput more than 3 times as high (almost 6MB/sec,
sometimes more) as with 2.2.x (1.90MB/sec). It diminished in -ac15
(3.25MB/sec), and in -ac16 it is almost back down (2.30MB/sec) to the
2.2.x values.

--
Martin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Interrupt hick ups

[Timothy A. Seufert]

At 9:56 AM +0200 6/16/00, Martin Costabel wrote:
>Geert Uytterhoeven wrote:
>>
>>  On Tue, 13 Jun 2000, Geert Uytterhoeven wrote:
>>  > Since a few kernel versions (late 2.3.x), I see interrupt hick
>>ups when doing
>>  > disk access on my Sym53c875. I.e. when I'm typing something and the disk
>>  > shows a lot of activity, keystrokes and mouse moves happen in
>>burst with some
>>  > delay (ca. 2 seconds).
>>  >
>>  > Anyone seeing a similar thing? This is on a CHRP LongTrail.
>
>Do you still see this in -ac16 or later? I had this, too, and from
>linux-kernel I understand that everyody had it, but it's gone now.
>
>What is gone too, unfortunately, is the phenomenal IDE speed
>improvement. In late 2.3.99/early 2.4.0-test1, I had a "hdparm
>-t"-measured throughput more than 3 times as high (almost 6MB/sec,
>sometimes more) as with 2.2.x (1.90MB/sec). It diminished in -ac15
>(3.25MB/sec), and in -ac16 it is almost back down (2.30MB/sec) to the
>2.2.x values.

Have you made sure your HD is set up for DMA, etc.?  For example, do
"hdparm -d1 -u1 -m16 -p4 /dev/hda" and then run the -t throughput
test.  (Use the man pages to make sure those are sane options, that's
all from memory.)

I remember similar fluctuation in 2.2.x as automatic negotiation of
DMA and so forth was first put in then taken out of the IDE driver.

Also, to make sure buffers get flushed before a test (for repeatable
results) you should do hdparm -Tt, not just hdparm -t.

   Tim Seufert

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

ide-speed was Re: Interrupt hick ups

[Andreas Tobler]

"Timothy A. Seufert" wrote:
>
> At 9:56 AM +0200 6/16/00, Martin Costabel wrote:
> >What is gone too, unfortunately, is the phenomenal IDE speed
> >improvement. In late 2.3.99/early 2.4.0-test1, I had a "hdparm
> >-t"-measured throughput more than 3 times as high (almost 6MB/sec,
> >sometimes more) as with 2.2.x (1.90MB/sec). It diminished in -ac15
> >(3.25MB/sec), and in -ac16 it is almost back down (2.30MB/sec) to the
> >2.2.x values.
>
> Have you made sure your HD is set up for DMA, etc.?  For example, do
> "hdparm -d1 -u1 -m16 -p4 /dev/hda" and then run the -t throughput
> test.  (Use the man pages to make sure those are sane options, that's
> all from memory.)
>
> I remember similar fluctuation in 2.2.x as automatic negotiation of
> DMA and so forth was first put in then taken out of the IDE driver.
>
> Also, to make sure buffers get flushed before a test (for repeatable
> results) you should do hdparm -Tt, not just hdparm -t.

Aha, just made a test and saw the same as Martin. Now with the hint from
Tim I get back to 6.30MB/s on ac19
On 2.2.16 it is still 6.xMB/s.
So now the question is for me what does the kernel parameter
hda=autotune do?
Do I always have to set this line by 'hand'(script) "hdparm -d1 -u1 -m16
-p4 /dev/hda"?

Thanks
Andreas

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Interrupt hick ups

[Martin Costabel]

"Timothy A. Seufert" wrote:

> Have you made sure your HD is set up for DMA, etc.?  For example, do
> "hdparm -d1 -u1 -m16 -p4 /dev/hda" and then run the -t throughput
> test.  (Use the man pages to make sure those are sane options, that's
> all from memory.)
>
> I remember similar fluctuation in 2.2.x as automatic negotiation of
> DMA and so forth was first put in then taken out of the IDE driver.
>
> Also, to make sure buffers get flushed before a test (for repeatable
> results) you should do hdparm -Tt, not just hdparm -t.

Yes, I did all this, except the -d1 bit which doesn't do anything on my
old drive. The numbers I gave were the maximum I could get with any kind
of tweaking.

Anyway, I am not really complaining (there are far more serious bugs in
-ac16), I guess it was just something too nice to stay for real.

--
Martin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/