From: Stefan Jeglinski <hidden> Date: 2000-11-29 01:55:13
usb-ohci.c: USB OHCI at membase 0xd0184000, IRQ 23
already gives a clue. Question is, what else is at IRQ 23?
Michael
In both 2.2.17 and 2.2.18pre23 (bk), 6-slot PTP (9500-ish), cards are
as follows, top to bottom:
Adaptec 2940UW
Farallon ethernet 10/100
OrangeLink firewire/usb combo
Matrox Mystique card
ixMicro TV card
ixMicro Twin Turbo card [aka imstt]
lspci -vv is attached at the end. The key point is that the entry for
the Adaptec 2940UW card and the Orangelink USB card BOTH say:
Interrupt: pin A routed to IRQ 23
Hah. So, this might explain a lot. Obviously this is why my usb mouse
only responds when there is some disk activity, and only for a
moment. It ALSO may help explain why I was having trouble booting
(kernel panic traced to aic7xxx and its call to ioremap). However,
this boot issue is still suspicious for 2 reasons:
1. 2.2.17 lspci -vv ALSO shows same shared IRQ 23, and 2.2.17
never had boot problem. But it also has no USB stuff compiled in.
2. My boot "workaround" is simply to add printk statements at
strategic points in the source. Boot problem solved. Weird.
At any rate, why are these 2 devices sharing an IRQ, and what can be
done about it? Thanks Michael Schmitz for giving me the first
concrete lead on this.
Stefan Jeglinski
lspci output for 2.2.18pre23. FWIW I also note that there are
numerous but subtle differences (in the + and - designations) between
lspci -vv for 2.2.17 and 2.2.18pre23. Is this an issue?
00:0b.0 Host bridge: Apple Computer Inc. Bandit PowerPC host bridge (rev 03)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort+
<TAbort- <MAbort+ >SERR- <PERR-
Latency: 32 set, cache line size 08
00:0d.0 SCSI storage controller: Adaptec AIC-7881U
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 8 min, 8 max, 32 set, cache line size 08
Interrupt: pin A routed to IRQ 23
Region 0: I/O ports at <unassigned>
Region 1: Memory at 80901000 (32-bit, non-prefetchable)
Expansion ROM at 80910000 [disabled]
00:0e.0 Ethernet controller: Digital Equipment Corporation DECchip
21142/43 (rev 41)
Subsystem: Standard Microsystems Corp [SMC]: Unknown device 2401
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 20 min, 40 max, 96 set
Interrupt: pin A routed to IRQ 24
Region 0: I/O ports at 1000
Region 1: Memory at 80900000 (32-bit, non-prefetchable) [disabled]
Expansion ROM at 80940000 [disabled]
00:0f.0 PCI bridge: Action Tec Electronics Inc: Unknown device 0100
(rev 11) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 32 set, cache line size 08
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
Memory behind bridge: 80800000-808fffff
BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
Capabilities: [80] Power Management version 1
Flags: PMEClk- AuxPwr- DSI- D1+ D2+ PME-
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [90] #06 [0000]
00:10.0 Class ff00: Apple Computer Inc. Grand Central I/O (rev 02)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR+
Latency: 32 set, cache line size 08
Region 0: Memory at f3000000 (32-bit, non-prefetchable)
01:0c.0 FireWire (IEEE 1394): NEC Corporation: Unknown device 00cd
(rev 01) (prog-if 10 [OHCI])
Subsystem: Orange Micro: Unknown device 8010
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 32 set, cache line size 08
Interrupt: pin A routed to IRQ 1
Region 0: Memory at 80801000 (32-bit, non-prefetchable)
Capabilities: [60] Power Management version 1
Flags: PMEClk- AuxPwr- DSI- D1- D2+ PME-
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
01:0d.0 USB Controller: OPTi Inc. 82C861 (rev 10) (prog-if 10 [OHCI])
Subsystem: OPTi Inc.: Unknown device c861
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort+ <MAbort- >SERR- <PERR-
Latency: 32 set, cache line size 08
Interrupt: pin A routed to IRQ 23
Region 0: Memory at 80800000 (32-bit, non-prefetchable)
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Michel Lanners <hidden> Date: 2000-12-01 19:56:28
Hi all,
On 28 Nov, this message from Stefan Jeglinski echoed through cyberspace:
lspci -vv is attached at the end. The key point is that the entry for
the Adaptec 2940UW card and the Orangelink USB card BOTH say:
Interrupt: pin A routed to IRQ 23
01:0d.0 USB Controller: OPTi Inc. 82C861 (rev 10) (prog-if 10 [OHCI])
[snip]
Interrupt: pin A routed to IRQ 23
and this too ->^^
Bot of these devices should get IRQ25. Why? Because on Macs, all four
IRQ lines of a PCI slot are OR'ed together on the bridge chip.
Therefore, there is one single fixed IRQ per PCI slot. So, the devices
behind the PCI-to-PCI bridge in slot 00:0f should all have the same IRQ,
which should be, following the obvious logic, IRQ 25.
Either a problem with the P2P bridge code in Linux, or with detecting
the IRQ's out of OF, as Ben suggested.
Stefan, you could try hardcoding that IRQ in the PCI fixup code, or in
the driver, and see whether that works...
Michel
-------------------------------------------------------------------------
Michel Lanners | " Read Philosophy. Study Art.
23, Rue Paul Henkes | Ask Questions. Make Mistakes.
L-1710 Luxembourg |
email mlan@cpu.lu |
http://www.cpu.lu/~mlan | Learn Always. "
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
usb-ohci.c: USB OHCI at membase 0xd0184000, IRQ 23
already gives a clue. Question is, what else is at IRQ 23?
Michael
In both 2.2.17 and 2.2.18pre23 (bk), 6-slot PTP (9500-ish), cards are
as follows, top to bottom:
Adaptec 2940UW
Farallon ethernet 10/100
OrangeLink firewire/usb combo
Matrox Mystique card
ixMicro TV card
ixMicro Twin Turbo card [aka imstt]
lspci -vv is attached at the end. The key point is that the entry for
the Adaptec 2940UW card and the Orangelink USB card BOTH say:
Interrupt: pin A routed to IRQ 23
Hah. So, this might explain a lot. Obviously this is why my usb mouse
only responds when there is some disk activity, and only for a
moment. It ALSO may help explain why I was having trouble booting
(kernel panic traced to aic7xxx and its call to ioremap). However,
this boot issue is still suspicious for 2 reasons:
1. 2.2.17 lspci -vv ALSO shows same shared IRQ 23, and 2.2.17
never had boot problem. But it also has no USB stuff compiled in.
2. My boot "workaround" is simply to add printk statements at
strategic points in the source. Boot problem solved. Weird.
At any rate, why are these 2 devices sharing an IRQ, and what can be
done about it? Thanks Michael Schmitz for giving me the first
concrete lead on this.
Shared interrupts are allowed by PCI. If it doesn't work, it means one of the
drivers (or both) can't cope with shared interrupts. The solution is to fix the
driver(s).
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/
From: Stefan Jeglinski <hidden> Date: 2000-12-04 06:09:49
[I apologize in advance to Geert, Michel, and Ben if I have
misrepresented their previous statements below - I'm trying to figure
this out still]
Geert said:
Shared interrupts are allowed by PCI. If it doesn't work, it means one of the
drivers (or both) can't cope with shared interrupts. The solution is
to fix the driver(s).
However, another consensus seems to be available, as per Michel Lanners:
01:0c.0 FireWire (IEEE 1394): NEC Corporation: Unknown device 00cd
(rev 01) (prog-if 10 [OHCI])
[snip]
Interrupt: pin A routed to IRQ 1
This is most certainly wrong -> ^
01:0d.0 USB Controller: OPTi Inc. 82C861 (rev 10) (prog-if 10 [OHCI])
[snip]
Interrupt: pin A routed to IRQ 23
and this too ->^^
Bot of these devices should get IRQ25. Why? Because on Macs, all four
IRQ lines of a PCI slot are OR'ed together on the bridge chip.
Therefore, there is one single fixed IRQ per PCI slot. So, the devices
behind the PCI-to-PCI bridge in slot 00:0f should all have the same IRQ,
which should be, following the obvious logic, IRQ 25.
Either a problem with the P2P bridge code in Linux, or with detecting
the IRQ's out of OF, as Ben suggested.
It seems to me that both should have the same interrupt, as Michel
states - after all, they are on the same PCI card; however, the
larger issue is whether neither should be 23, because 23 is already
assigned:
00:0d.0 SCSI storage controller: Adaptec AIC-7881U
[snip]
Interrupt: pin A routed to IRQ 23
Indeed, Ben has said along these lines:
Ok, I found the problem, I think, with the interrupt. I'm still
investigating, but what it looks like is that the OF tree puts the
AAPL,interrupt property in the pci-bridge node, not in the sub-nodes.
So we must make sure the routine that gets interrupts from the tree
on oldworld iterates to parent devices when it can't find the
AAPL,interrupt property.
Which again indicates that the problem is in the PCI (?) code.
So, is Geert right (PCI ok at least in this aspect, drivers are
buggy)? Or are Ben/Michel right (drivers OK, PCI/IRQ buggy)?
Stefan Jeglinski
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Benjamin Herrenschmidt <hidden> Date: 2000-12-04 14:35:20
Shared interrupts are allowed by PCI. If it doesn't work, it means one of the
drivers (or both) can't cope with shared interrupts. The solution is to
fix the
driver(s).
In fact, the problem appears to be in our prom.c code. On "oldworld"
macs, the interrupt informations in the device tree use apple non-
standard "AAPL,interrupts" properties. It appears that when a PCI<->PCI
bridge is present in a slot, Apple's OF will only set this property on
the bridge itself, not on the devices below the bridge. So we must adjust
our prom.c code to detect this case. I'll give it a try later this week.
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Timothy A. Seufert <hidden> Date: 2000-12-05 08:39:22
At 1:09 AM -0500 12/4/00, Stefan Jeglinski wrote:
So, is Geert right (PCI ok at least in this aspect, drivers are
buggy)? Or are Ben/Michel right (drivers OK, PCI/IRQ buggy)?
PCI is in fact designed to share interrupts gracefully, as Geert
said. However, sharing doesn't look like the problem here: what
Michel and Ben are talking about is that the kernel fails to
correctly identify your card's true IRQ number. On these Macs there
is a fixed mapping between PCI slots and interrupt numbers,
determined by hardware. If software gets this mapping wrong, drivers
will hook into the wrong IRQ numbers and fail to work correctly.
According to Ben, this appears to be a problem in the kernel code
which discovers information about PCI devices (including interrupt
mappings) from an Open Firmware data structure, the OF device tree.
Apparently the interrupt assignment information in the device tree is
structured somewhat differently in Old World Macs such as yours when
devices are behind a PCI to PCI bridge. (Your combo card consists of
such a bridge plus two PCI devices.)
Tim Seufert
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/