* SMP IRQ management issues in 2.4.x
@ 2002-03-21 13:57 Fionn Behrens
2002-03-21 14:31 ` Alan Cox
0 siblings, 1 reply; 6+ messages in thread
From: Fionn Behrens @ 2002-03-21 13:57 UTC (permalink / raw)
To: linux-kernel
After changing from 2.2.18 to 2.4.17 recently, I noticed that after booting 2.4 my interrupts were routed a lot less effectively than under 2.2
I did not take it too seriously until the beginning of this week when I plugged in an extra Promise controller. I have a gigabyte 6BXD Dual Pentium Board which is a quite nice piece of hardware. Just the Award BIOS is crappy in that you cant assign IRQs directly to certain slots but only reserve certain interrupts from being distributed among the PCI Units. Anyway, until Linux 2.4, the kernel did cope quite well with that and distributed IRQs equally using the whole range of interrupts the IO-APIC delivers.
Now, I have this Promise controller and my IRQ table looks like this:
CPU0 CPU1
0: 21400 20144 IO-APIC-edge timer
1: 1349 1173 IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
5: 5 3 IO-APIC-edge serial
8: 1 1 IO-APIC-edge rtc
12: 3138 3046 IO-APIC-edge PS/2 Mouse
14: 857 6088 IO-APIC-edge ide0
15: 452 3855 IO-APIC-edge ide1
16: 24354 24086 IO-APIC-level aic7xxx, aic7xxx, aic7xxx, ide2,
ide3, nvidia
18: 501 445 IO-APIC-level EMU10K1
19: 822 765 IO-APIC-level usb-uhci, eth0
Given that IRQs<6 are all locked for serial IO that means IRQ 7,9,11 and 17
are completely unused but there are a whopping 6 devices on IRQ 16.
Needless to say that Harddrives connected to ide2 and ide3 (Promise) constantly lose interrupts when used as long as X is running (nvidia), bringing the system to crawl.
I have tried virtually everything to make Linux (and the BIOS) reconsider IRQ distribution and failed.
And yes, all DMA stuff is properly set, the disks are recognized with their real size, partitioned and initialized correctly and so on. In fact they work like a charm as long as I don't use the graphics card.
Is there any way to reassign IRQs under 2.4.x to stabilize the system?
Is there any way to make Linux-2.4.x-SMP distribute IRQs in the same fashion
Linux-2.2.x-SMP did?
Any help appreciated (including pointers on what to patch in the kernel)
Regards,
Fionn
--
I believe we have been called by history to lead the world.
G.W. Bush, 2002-03-01
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: SMP IRQ management issues in 2.4.x
2002-03-21 13:57 SMP IRQ management issues in 2.4.x Fionn Behrens
@ 2002-03-21 14:31 ` Alan Cox
2002-03-21 21:38 ` Fionn Behrens
0 siblings, 1 reply; 6+ messages in thread
From: Alan Cox @ 2002-03-21 14:31 UTC (permalink / raw)
To: Fionn Behrens; +Cc: linux-kernel
> After changing from 2.2.18 to 2.4.17 recently, I noticed that after booting
> 2.4 my interrupts were routed a lot less effectively than under 2.2
Can you post both 2.2 and 2.4 tables for comparison
> Needless to say that Harddrives connected to ide2 and ide3 (Promise)
> constantly lose interrupts when used as long as X is running (nvidia),
> bringing the system to crawl.
You should never be losing interrupts, even with everything on one IRQ line.
PCI interrupts are level trigger so don't get "lost" in the same way as ISA
ones did
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: SMP IRQ management issues in 2.4.x
2002-03-21 14:31 ` Alan Cox
@ 2002-03-21 21:38 ` Fionn Behrens
2002-03-21 22:10 ` Alan Cox
0 siblings, 1 reply; 6+ messages in thread
From: Fionn Behrens @ 2002-03-21 21:38 UTC (permalink / raw)
To: linux-kernel; +Cc: Alan Cox
On Thu, 21 Mar 2002 14:31:36 +0000 (GMT)
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > After changing from 2.2.18 to 2.4.17 recently, I noticed that after
> > booting 2.4 my interrupts were routed a lot less effectively than under
> > 2.2
>
> Can you post both 2.2 and 2.4 tables for comparison
I am afraid this will get slightly problematic since I upgraded several system components (LVM update and some ext2->ext3 partition changes amongst others) which would probably make booting back into a working 2.2 system a rather adventurous task.
I think I'll try to do it tomorrow, however. Hope nothing gets broken.
> > Needless to say that Harddrives connected to ide2 and ide3 (Promise)
> > constantly lose interrupts when used as long as X is running (nvidia),
> > bringing the system to crawl.
>
> You should never be losing interrupts, even with everything on one IRQ line.
> PCI interrupts are level trigger so don't get "lost" in the same way as ISA
> ones did
As a matter of fact I keep getting the following kernel messages when accessing large chunks of data on ide2 or ide2 only while X is running:
Mar 21 09:56:41 localhost kernel: hde: drive not ready for command
Mar 21 09:56:41 localhost kernel: hde: status error: status=0x58 { DriveReady
SeekComplete DataRequest }
Mar 21 09:56:41 localhost kernel: hde: drive not ready for command
Mar 21 09:56:41 localhost kernel: hde: write_intr error1: nr_sectors=128,
stat=0 xd0
Mar 21 09:56:41 localhost kernel: hde: write_intr: status=0xd0 { Busy }
Mar 21 09:56:41 localhost kernel: ide2: reset: success
Mar 21 09:56:41 localhost kernel: hde: status error: status=0x58 { DriveReady SeekComplete DataRequest }
[...and so on, mostly without the write_intr error, just status errors...]
When X is not running (aka opencount 0 for nvdriver) all runs smoothly.
Alas, I can't find a way to assign that nv module to its own interrupt.
Regards,
Fionn
--
I believe we have been called by history to lead the world.
G.W. Bush, 2002-03-01
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: SMP IRQ management issues in 2.4.x
2002-03-21 21:38 ` Fionn Behrens
@ 2002-03-21 22:10 ` Alan Cox
2002-03-22 14:25 ` Fionn Behrens
0 siblings, 1 reply; 6+ messages in thread
From: Alan Cox @ 2002-03-21 22:10 UTC (permalink / raw)
To: Fionn Behrens; +Cc: linux-kernel, Alan Cox
> > Can you post both 2.2 and 2.4 tables for comparison
> I am afraid this will get slightly problematic since I upgraded several system components (LVM update and some ext2->ext3 partition changes amongst others) which would probably make booting back into a working 2.2 system a rather adventurous task.
> I think I'll try to do it tomorrow, however. Hope nothing gets broken.
Don't worry about it then - that was mostly to get a feel for things.
> Mar 21 09:56:41 localhost kernel: hde: write_intr: status=0xd0 { Busy }
> Mar 21 09:56:41 localhost kernel: ide2: reset: success
> Mar 21 09:56:41 localhost kernel: hde: status error: status=0x58 { DriveReady SeekComplete DataRequest }
That doesnt look like an interrupt problem to be honest. Perhaps nvdriver
is triggering something else
(the Busy is the drive saying its still waiting for something)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: SMP IRQ management issues in 2.4.x
2002-03-21 22:10 ` Alan Cox
@ 2002-03-22 14:25 ` Fionn Behrens
2002-03-22 15:11 ` Alan Cox
0 siblings, 1 reply; 6+ messages in thread
From: Fionn Behrens @ 2002-03-22 14:25 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-kernel
On Thu, 21 Mar 2002 22:10:36 +0000 (GMT)
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > Mar 21 09:56:41 localhost kernel: hde: write_intr: status=0xd0 { Busy }
> > Mar 21 09:56:41 localhost kernel: ide2: reset: success
> > Mar 21 09:56:41 localhost kernel: hde: status error: status=0x58 {
> > DriveReady
> > SeekComplete DataRequest }
>
> That doesnt look like an interrupt problem to be honest. Perhaps nvdriver
> is triggering something else
>
> (the Busy is the drive saying its still waiting for something)
Just wanted to close the issue by saying it came out that it actually is NOT an IRQ problem.
Another close look at "hdparm -I" vs. "harparm -v" (and syslog) revealed that the hard disks had been configured for UDMA mode 5 by the controller (probably at boot time) while the Linux kernel set them to some IO mode.
Having found this out, I really wonder how the disks managed to work under any circumstances at all.
thanks for your hints and reading,
Fionn
--
I believe we have been called by history to lead the world.
G.W. Bush, 2002-03-01
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: SMP IRQ management issues in 2.4.x
2002-03-22 14:25 ` Fionn Behrens
@ 2002-03-22 15:11 ` Alan Cox
0 siblings, 0 replies; 6+ messages in thread
From: Alan Cox @ 2002-03-22 15:11 UTC (permalink / raw)
To: Fionn Behrens; +Cc: Alan Cox, linux-kernel
> > That doesnt look like an interrupt problem to be honest. Perhaps nvdriver
> > is triggering something else
> >
> > (the Busy is the drive saying its still waiting for something)
>
> Just wanted to close the issue by saying it came out that it actually is NOT an IRQ problem.
> Another close look at "hdparm -I" vs. "harparm -v" (and syslog) revealed that
> the hard disks had been configured for UDMA mode 5 by the controller
> (probably at boot time) while the Linux kernel set them to some IO mode.
>
> Having found this out, I really wonder how the disks managed to work under
> any circumstances at all.
Thats interesting in itself, and an important clue
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2002-03-22 14:56 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-03-21 13:57 SMP IRQ management issues in 2.4.x Fionn Behrens
2002-03-21 14:31 ` Alan Cox
2002-03-21 21:38 ` Fionn Behrens
2002-03-21 22:10 ` Alan Cox
2002-03-22 14:25 ` Fionn Behrens
2002-03-22 15:11 ` Alan Cox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®