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/
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/
From: Martin Costabel <hidden> Date: 2000-06-16 07:56:45
Geert Uytterhoeven wrote:
On Tue, 13 Jun 2000, Geert Uytterhoeven wrote:
quoted
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/
From: Timothy A. Seufert <hidden> Date: 2000-06-16 08:12:14
At 9:56 AM +0200 6/16/00, Martin Costabel wrote:
Geert Uytterhoeven wrote:
quoted
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/
From: Andreas Tobler <hidden> Date: 2000-06-16 08:35:19
"Timothy A. Seufert" wrote:
At 9:56 AM +0200 6/16/00, Martin Costabel wrote:
quoted
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/
From: Martin Costabel <hidden> Date: 2000-06-16 17:27:46
"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/