Please CC me with responses, as I am not subscribed to the list. Any
help or pointers are greatly appreciated!
I'm having trouble with the USB function of my laptop (2.4.16 kernel).
The PCI BIOS config space indicates PIN A, IRQ 9, and apparently, so
does the PIRQ table. However, the mask for the device allows only IRQ
11. Using the patch below (shamelessly stolen from John Clemens and
modified slightly -
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0111.2/0005.html), I
was able to get USB working by forcing anything showing up as IRQ 9 to
IRQ 11 (according to the PIRQ, IRQ 9 ian't usable anyway on my machine).
Obviously, this is evil, but at least it works. Also, the IDE IRQ seems
to be unrouted, but it works fine. The USB adapter is PCI device 00:02.0
USB Controller: Acer Laboratories Inc. [ALi] M5237 USB. Interestingly,
the PIRQ "Link" of the USB device is 0x59, all the others are 0x00-0x03.
What I'm wondering is - what's broken?
Is it:
1) Bad BIOS? (changing the date is as configurable as it gets - and I
have updated to the latest available version)
2) Bad Linux interperetation of ALi IRQ router? (comments in
linux/arch/i386/kernel/pci-irq.c seem to suggest it's possible)
3) Bad Hardware?
4) Bad Karma?
Is there a "correct" way to fix this? Info follows. If anyone would like
additional info (full dmesg output, etc) I'd be happy to email it
seperately.
-Cory Bell
the (very ugly, I know) patch:
--- linux/arch/i386/kernel/pci-irq.c.dist Sun Nov 4 09:31:58 2001
+++ linux/arch/i386/kernel/pci-irq.c Tue Dec 4 16:31:56 2001
@@ -583,6 +583,9 @@
}
DBG(" -> newirq=%d", newirq);
+ if (r->get(pirq_router_dev, dev, pirq) == 9) {
+ r->set(pirq_router_dev, dev, pirq, newirq);
+ }
/* Check if it is hardcoded */
if ((pirq & 0xf0) == 0xf0) {
irq = pirq & 0xf;
@@ -674,6 +677,10 @@
DBG("%s: ignoring bogus IRQ %d\n", dev->slot_name, dev->irq);
dev->irq = 0;
}
+ if (dev->irq == 9) {
+ pci_write_config_byte(dev, PCI_INTERRUPT_LINE, 0x0b);
+ dev->irq=11;
+ }
/* If the IRQ is already assigned to a PCI device, ignore its ISA use penalty */
if (pirq_penalty[dev->irq] >= 100 && pirq_penalty[dev->irq] < 100000)
pirq_penalty[dev->irq] = 0;
dmesg snippets (after patch applied):
PCI: BIOS32 Service Directory structure at 0xc00f7ea0
PCI: BIOS32 Service Directory entry at 0xfd792
PCI: BIOS probe returned s=00 hw=01 ver=02.10 l=01
PCI: PCI BIOS revision 2.10 entry at 0xfd8b0, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: IDE base address fixup for 00:0f.0
PCI: Scanning for ghost devices on bus 0
PCI: Scanning for ghost devices on bus 1
Unknown bridge resource 0: assuming transparent
Unknown bridge resource 2: assuming transparent
PCI: IRQ init
PCI: Interrupt Routing Table found at 0xc00fdf40
00:0f slot=00 0:00/4000 1:00/8000 2:00/def8 3:00/def8
00:02 slot=00 0:59/0800 1:00/def8 2:00/def8 3:00/def8
00:08 slot=01 0:03/0020 1:00/def8 2:00/def8 3:00/def8
00:04 slot=00 0:01/0800 1:02/0800 2:00/def8 3:00/def8
00:10 slot=00 0:02/0800 1:00/def8 2:00/def8 3:00/def8
00:07 slot=00 0:01/def8 1:02/def8 2:03/def8 3:04/def8
00:01 slot=00 0:01/0800 1:00/def8 2:00/def8 3:00/def8
01:00 slot=00 0:01/0800 1:00/def8 2:00/def8 3:00/def8
PCI: Attempting to find IRQ router for 10b9:1533
PCI: Using IRQ router ALI [10b9/1533] at 00:07.0
PCI: IRQ fixup
00:0f.0: ignoring bogus IRQ 255
IRQ for 00:0f.0:0 -> not routed
...
IRQ for 00:02.0:0 -> PIRQ 59, mask 0800, excl 0000 -> newirq=11 -> got IRQ 11
PCI: Found IRQ 11 for device 00:02.0
usb-ohci.c: USB OHCI at membase 0xd08b6000, IRQ 11
usb-ohci.c: usb-00:02.0, Acer Laboratories Inc. [ALi] M5237 USB
without the patch, the above chunk looks like:
IRQ for 00:02.0:0 -> PIRQ 59, mask 0800, excl 0000 -> newirq=9 -> got IRQ 9
PCI: Found IRQ 9 for device 00:02.0
usb-ohci.c: USB OHCI at membase 0xd08b6000, IRQ 9
usb-ohci.c: usb-00:02.0, Acer Laboratories Inc. [ALi] M5237 USB
dump_pirq:
Interrupt routing table found at address 0xfdf40:
Version 1.0, size 0x00a0
Interrupt router is device 00:07.0
PCI exclusive interrupt mask: 0x0000 []
Compatible router: vendor 0x10b9 device 0x1533
Device 00:0f.0 (slot 0): IDE interface
Device 00:02.0 (slot 0): USB Controller
INTA: link 0x59, irq mask 0x0800 [11]
Device 00:08.0 (slot 1): Multimedia audio controller
INTA: link 0x03, irq mask 0x0020 [5]
Device 00:04.0 (slot 0): CardBus bridge
INTA: link 0x01, irq mask 0x0800 [11]
INTB: link 0x02, irq mask 0x0800 [11]
Device 00:10.0 (slot 0): Ethernet controller
INTA: link 0x02, irq mask 0x0800 [11]
Device 00:07.0 (slot 0): ISA bridge
INTA: link 0x01, irq mask 0xdef8 [3,4,5,6,7,9,10,11,12,14,15]
INTB: link 0x02, irq mask 0xdef8 [3,4,5,6,7,9,10,11,12,14,15]
INTC: link 0x03, irq mask 0xdef8 [3,4,5,6,7,9,10,11,12,14,15]
INTD: link 0x04, irq mask 0xdef8 [3,4,5,6,7,9,10,11,12,14,15]
Device 00:01.0 (slot 0): PCI bridge
INTA: link 0x01, irq mask 0x0800 [11]
Device 01:00.0 (slot 0): VGA compatible controller
INTA: link 0x01, irq mask 0x0800 [11]
Interrupt router at 00:07.0: AcerLabs Aladdin M1533 PCI-to-ISA bridge
INT1 (link 1): irq 11
INT2 (link 2): irq 11
INT3 (link 3): irq 5
INT4 (link 4): unrouted
INT5 (link 5): unrouted
INT6 (link 6): unrouted
INT7 (link 7): unrouted
INT8 (link 8): unrouted
Serial IRQ: [enabled] [quiet] [frame=21] [pulse=12]
lspci -vvvx (after patch):
00:00.0 Host bridge: Acer Laboratories Inc. [ALi]: Unknown device 1647 (rev 04)
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: 0
Region 0: Memory at f0000000 (32-bit, prefetchable) [size=64M]
Capabilities: [b0] AGP version 2.0
Status: RQ=27 SBA+ 64bit- FW+ Rate=x1,x2
Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
Capabilities: [a4] Power Management version 1
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: b9 10 47 16 07 00 10 a2 04 00 00 06 00 00 00 00
10: 08 00 00 f0 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 b0 00 00 00 00 00 00 00 00 00 00 00
00:01.0 PCI bridge: Acer Laboratories Inc. [ALi] M5247 (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: e8100000-edffffff
Prefetchable memory behind bridge: fff00000-000fffff
BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B-
00: b9 10 47 52 1f 00 00 04 00 00 04 06 00 00 01 00
10: 00 00 00 00 00 00 00 00 00 01 01 00 f0 00 20 a2
20: 10 e8 f0 ed f0 ff 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0c 00
00:02.0 USB Controller: Acer Laboratories Inc. [ALi] M5237 USB (rev 03) (prog-if 10 [OHCI])
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: 16 (20000ns max), cache line size 08
Interrupt: pin A routed to IRQ 11
Region 0: Memory at fff70000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: b9 10 37 52 17 00 90 02 03 10 03 0c 08 10 00 00
10: 00 00 f7 ff 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 60 00 00 00 00 00 00 00 0b 01 00 50
00:04.0 CardBus bridge: Texas Instruments PCI1420
Subsystem: Hewlett-Packard Company: Unknown device 0018
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: 168, cache line size 10
Interrupt: pin A routed to IRQ 11
Region 0: Memory at 10000000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=00, secondary=02, subordinate=05, sec-latency=176
Memory window 0: 10400000-107ff000 (prefetchable)
Memory window 1: 10800000-10bff000
I/O window 0: 00004000-000040ff
I/O window 1: 00004400-000044ff
BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+ PostWrite+
16-bit legacy interface ports at 0001
00: 4c 10 51 ac 07 00 10 02 00 00 07 06 10 a8 82 00
10: 00 00 00 10 a0 00 00 02 00 02 05 b0 00 00 40 10
20: 00 f0 7f 10 00 00 80 10 00 f0 bf 10 00 40 00 00
30: fc 40 00 00 00 44 00 00 fc 44 00 00 0b 01 c0 05
40: 3c 10 18 00 01 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00:04.1 CardBus bridge: Texas Instruments PCI1420
Subsystem: Hewlett-Packard Company: Unknown device 0018
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: 168, cache line size 10
Interrupt: pin A routed to IRQ 11
Region 0: Memory at 10001000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=00, secondary=06, subordinate=09, sec-latency=176
Memory window 0: 10c00000-10fff000 (prefetchable)
Memory window 1: 11000000-113ff000
I/O window 0: 00004800-000048ff
I/O window 1: 00004c00-00004cff
BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+ PostWrite+
16-bit legacy interface ports at 0001
00: 4c 10 51 ac 07 00 10 02 00 00 07 06 10 a8 82 00
10: 00 10 00 10 a0 00 00 02 00 06 09 b0 00 00 c0 10
20: 00 f0 ff 10 00 00 00 11 00 f0 3f 11 00 48 00 00
30: fc 48 00 00 00 4c 00 00 fc 4c 00 00 0b 01 c0 05
40: 3c 10 18 00 01 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00:06.0 Bridge: Acer Laboratories Inc. [ALi] M7101 PMU
Subsystem: Acer Laboratories Inc. [ALi] ALI M7101 Power Management Controller
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-
00: b9 10 01 71 00 00 00 02 00 00 80 06 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 b9 10 01 71
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00:07.0 ISA bridge: Acer Laboratories Inc. [ALi] M1533 PCI to ISA Bridge [Aladdin IV]
Subsystem: Acer Laboratories Inc. [ALi] ALI M1533 Aladdin IV ISA Bridge
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: 0
Capabilities: [a0] Power Management version 1
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: b9 10 33 15 0f 00 10 02 00 00 01 06 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 b9 10 33 15
30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
00:08.0 Multimedia audio controller: ESS Technology ES1988 Allegro-1 (rev 12)
Subsystem: Hewlett-Packard Company: Unknown device 0018
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: 64 (500ns min, 6000ns max)
Interrupt: pin A routed to IRQ 5
Region 0: I/O ports at 8400 [size=256]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 5d 12 88 19 05 00 90 02 12 00 01 04 00 40 80 00
10: 01 84 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 18 00
30: 00 00 00 00 c0 00 00 00 00 00 00 00 05 01 02 18
00:08.1 Communication controller: ESS Technology ESS Modem (rev 12)
Subsystem: Hewlett-Packard Company: Unknown device 0018
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-
Interrupt: pin A routed to IRQ 5
Region 0: I/O ports at 8800 [size=256]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=100mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable+ DSel=0 DScale=0 PME-
00: 5d 12 89 19 01 00 90 02 12 00 80 07 00 00 80 00
10: 01 88 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 18 00
30: 00 00 00 00 c0 00 00 00 00 00 00 00 05 01 00 00
00:0f.0 IDE interface: Acer Laboratories Inc. [ALi] M5229 IDE (rev c4) (prog-if 8a [Master SecP PriP])
Subsystem: Acer Laboratories Inc. [ALi] M5229 IDE
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: 64 (500ns min, 1000ns max)
Interrupt: pin A routed to IRQ 0
Region 4: I/O ports at 1000 [size=16]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: b9 10 29 52 05 00 90 02 c4 8a 01 01 00 40 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 10 00 00 00 00 00 00 00 00 00 00 b9 10 29 52
30: 00 00 00 00 60 00 00 00 00 00 00 00 ff 01 02 04
00:10.0 Ethernet controller: Accton Technology Corporation: Unknown device 1216 (rev 11)
Subsystem: Accton Technology Corporation: Unknown device 2242
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-
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at 8c00 [size=256]
Region 1: Memory at e8001000 (32-bit, non-prefetchable) [size=1K]
Expansion ROM at <unassigned> [disabled] [size=128K]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 13 11 16 12 13 00 90 02 11 00 00 02 08 40 00 00
10: 01 8c 00 00 00 10 00 e8 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 13 11 42 22
30: 00 00 00 00 c0 00 00 00 00 00 00 00 0b 01 ff ff
01:00.0 VGA compatible controller: Trident Microsystems: Unknown device 9910 (rev 63) (prog-if 00 [VGA])
Subsystem: Hewlett-Packard Company: Unknown device 0018
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: 64
Interrupt: pin A routed to IRQ 11
Region 0: Memory at ec000000 (32-bit, non-prefetchable) [size=32M]
Region 1: Memory at e8400000 (32-bit, non-prefetchable) [size=4M]
Region 2: Memory at ea000000 (32-bit, non-prefetchable) [size=32M]
Region 3: Memory at e8100000 (32-bit, non-prefetchable) [size=32K]
Expansion ROM at <unassigned> [disabled] [size=64K]
Capabilities: [80] AGP version 2.0
Status: RQ=32 SBA+ 64bit- FW- Rate=x1,x2
Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
Capabilities: [90] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 23 10 10 99 07 00 30 02 63 00 00 03 00 40 00 00
10: 00 00 00 ec 00 00 40 e8 00 00 00 ea 00 00 10 e8
20: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 18 00
30: 00 00 00 00 80 00 00 00 00 00 00 00 0b 01 00 00
lspci -vvvx -s 00:02.0 (before patch):
00:02.0 USB Controller: Acer Laboratories Inc. [ALi] M5237 USB (rev 03) (prog-if 10 [OHCI])
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: 16 (20000ns max), cache line size 08
Interrupt: pin A routed to IRQ 9
Region 0: Memory at fff70000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: b9 10 37 52 17 00 90 02 03 10 03 0c 08 10 00 00
10: 00 00 f7 ff 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 60 00 00 00 00 00 00 00 09 01 00 50
On 4 Dec 2001, Cory Bell wrote:
> 11. Using the patch below (shamelessly stolen from John Clemens and
> modified slightly -
> http://www.uwsg.indiana.edu/hypermail/linux/kernel/0111.2/0005.html),
someone noticed! ;) Glad to see you also noticed my minor oversight in
using INTERRUPT_PIN instead of the correct INTERRUPT_LINE. Glad someone
found the work useful... A few people have asked me separately for my
patch and are using it successfully on thier laptops with no failure
reports.
> What I'm wondering is - what's broken?
> Is it:
> 1) Bad BIOS? (changing the date is as configurable as it gets - and I
> have updated to the latest available version)
Most probably.. that in combination with number 3.. And, to top it all
off, ACPI is thrown in there too as a non-PCI device on IRQ9. All in all,
quite a quirky laptop (for reference, I own an N5430, an earlier version
of your notebook).
> 2) Bad Linux interperetation of ALi IRQ router? (comments in
> linux/arch/i386/kernel/pci-irq.c seem to suggest it's possible)
Doubtful, as I have an Ali Aladdin7 board in my desktop (don't get much
more obscure than that one), and the Router works fine, as well as in a
Magik1 based motherboard I've used.
> Is there a "correct" way to fix this? Info follows. If anyone would like
> additional info (full dmesg output, etc) I'd be happy to email it
> seperately.
I've been wondering this one myself... one thing these laptops do
implement is a complete DMI table.. maybe we can do some sort of fixup
through there... does anyone know of any way to use the "DMI workarounds"
to effect PCI IRQ mapping -without- modifying the generic pci code?
And I like you patch, it's a slightly cleaner for of ugly than mine :).
john.c
--
John Clemens http://www.deater.net/john
[email protected] ICQ: 7175925, IM: PianoManO8
"I Hate Quotes" -- Samuel L. Clemens
On Tue, 2001-12-04 at 21:58, John Clemens wrote:
> someone noticed! ;) Glad to see you also noticed my minor oversight in
> using INTERRUPT_PIN instead of the correct INTERRUPT_LINE. Glad someone
> found the work useful... A few people have asked me separately for my
> patch and are using it successfully on thier laptops with no failure
> reports.
Actually, I checked your homepage before buying the laptop. In that
price/feature range, it was that or the Compaq, and the Compaq had a SMA
video chipset (blech). Would you consider putting the patch on your
website? I got the k7/sse patch, but the irq patch isn't actually
linked, I just happened across it while doing my research. I now know
WAY more about PCI interrupt routing than I ever wanted to, and I STILL
don't understand it!
> Most probably.. that in combination with number 3.. And, to top it all
> off, ACPI is thrown in there too as a non-PCI device on IRQ9. All in all,
> quite a quirky laptop (for reference, I own an N5430, an earlier version
> of your notebook).
Does ACPI work on your laptop? I wonder if XP Home Ed. works because
it's getting config info from there instead of PCIBIOS or PnPBIOS
tables? ACPI seems to work on my laptop (detects ACPI resources, thermal
zone, etc), but if I "cat /proc/acpi/events" and press the suspend or
power buttons, I don't get anything. On my old NEC Versa LX, I'd get a
few junk chars for each press (been a while since I tried it, though). I
don't see any interrupts on IRQ 9, either.
> > 2) Bad Linux interperetation of ALi IRQ router? (comments in
> > linux/arch/i386/kernel/pci-irq.c seem to suggest it's possible)
>
> Doubtful, as I have an Ali Aladdin7 board in my desktop (don't get much
> more obscure than that one), and the Router works fine, as well as in a
> Magik1 based motherboard I've used.
About interrupt routing: Does the PIRQ table actually contain the IRQ a
device is assigned to, or just a "link number" and a mask of acceptible
IRQs. I see on your laptop, the audio is on irq 5, which matches the
mask, but there seems to be no PIRQ link for 5, just like there's none
for IRQ 9 on yours or mine, yet the audio device still gets 5. Perhaps
the setup code is interpereting the "link" to mean a particular IRQ, but
is failing to validate the IRQ against the mask? Any idea how the setup
code gets from PIRQ 0x59 to IRQ 9, or PIRQ 0x48 to IRQ 11? Would you
mind emailing me a dump_pirq from your desktop ALi?
I imagine it doesn't help that the link numbers vary between machines of
the same chipset (ie, you have 0x00, 0x48-0x49, and 0x59, and I have
0x00, 0x01-0x03, and 0x59 - interesting that the "troublemaker" link #
is the same for both of us). Have you heard from anyone else with
ALi-chipset laptops having similar problems? I think the compaq I was
looking at had the same core chipset.
> I've been wondering this one myself... one thing these laptops do
> implement is a complete DMI table.. maybe we can do some sort of fixup
> through there... does anyone know of any way to use the "DMI workarounds"
> to effect PCI IRQ mapping -without- modifying the generic pci code?
Does the standard kernel have DMI? I thought that was an -ac thing... I
know I don't see any DMI messages on boot.
> And I like you patch, it's a slightly cleaner for of ugly than mine :).
Thanks! I'm still trying to find a way to move it out of generic PCI
code and at least into ALi-specific territory...
-Cory
> video chipset (blech). Would you consider putting the patch on your
> website? I got the k7/sse patch, but the irq patch isn't actually
> linked, I just happened across it while doing my research.
Sure.. I'll put yours up thought because it's slightly less intrusive. I
was hoping to find out a much cleaner way of doing this before I put it
up for anyone to use.... so i posted it here first... but as they say, the
silence was deafening...
> ACPI seems to work on my laptop (detects ACPI resources, thermal
> zone, etc), but if I "cat /proc/acpi/events" and press the suspend or
> power buttons, I don't get anything. On my old NEC Versa LX, I'd get a
> few junk chars for each press (been a while since I tried it, though). I
> don't see any interrupts on IRQ 9, either.
I'm not 100% sure how ACPI works, period. I've got it up and running, but
about the only thing it does seem to report correctly is battery life
(and, I assume, it uses ACPI idle..).. everything else appears to be just
window dressing for now.. not sure if that's a limitation of hardware or
the linux ACPI implementation.
> About interrupt routing: Does the PIRQ table actually contain the IRQ a
> device is assigned to, or just a "link number" and a mask of acceptible
> IRQs. I see on your laptop, the audio is on irq 5, which matches the
> mask, but there seems to be no PIRQ link for 5, just like there's none
> for IRQ 9 on yours or mine, yet the audio device still gets 5. Perhaps
> the setup code is interpereting the "link" to mean a particular IRQ, but
> is failing to validate the IRQ against the mask? Any idea how the setup
> code gets from PIRQ 0x59 to IRQ 9, or PIRQ 0x48 to IRQ 11? Would you
> mind emailing me a dump_pirq from your desktop ALi?
>
> I imagine it doesn't help that the link numbers vary between machines of
> the same chipset (ie, you have 0x00, 0x48-0x49, and 0x59, and I have
> 0x00, 0x01-0x03, and 0x59 - interesting that the "troublemaker" link #
> is the same for both of us). Have you heard from anyone else with
> ALi-chipset laptops having similar problems? I think the compaq I was
> looking at had the same core chipset.
I'm afraid we may both be in over our heads here. That link number
sppears to be some sort of code to help routing (see code for "see if
hard-coded, it checks for 0xf"), and the mask is just what
you think it is. However, from my gatherings, pIRQ tables are often wrong
and thus ignored by Linux a lot of times. I think the -real- problem here
is the bios is assigning IRQ's to PCI devices, and assign's 9 to the USB
on startup, writes that to it's config registers, and Linux is stuck with
it. But that's just speculation.
> Does the standard kernel have DMI? I thought that was an -ac thing... I
> know I don't see any DMI messages on boot.
Yes, they just don't print out anymore (see
arch/i386/kenrel/dmiscan.c<?>).
Who maintains the PCI irq routing code?
john.c
--
John Clemens http://www.deater.net/john
[email protected] ICQ: 7175925, IM: PianoManO8
"I Hate Quotes" -- Samuel L. Clemens
On Wed, 5 Dec 2001 11:41:44 -0500 (EST)
John Clemens <[email protected]> wrote:
<snip>
> > ACPI seems to work on my laptop (detects ACPI resources, thermal
> > zone, etc), but if I "cat /proc/acpi/events" and press the suspend or
> > power buttons, I don't get anything. On my old NEC Versa LX, I'd get a
> > few junk chars for each press (been a while since I tried it, though). I
> > don't see any interrupts on IRQ 9, either.
>
> I'm not 100% sure how ACPI works, period. I've got it up and running, but
> about the only thing it does seem to report correctly is battery life
> (and, I assume, it uses ACPI idle..).. everything else appears to be just
> window dressing for now.. not sure if that's a limitation of hardware or
> the linux ACPI implementation.
I have an N5415, and am using your k7 patch (thanks much!). I don't use USB,
so I didn't try or comment on your patch. However, I was never able to get
ACPI to work. If I compiled it in without APM compiled in, it always hung on
boot. So, I have only APM, which doesn't even show the battery life
correctly. Whether or not I can suspend, knowing battery life would be an
improvement. Is there something special I have to do to get ACPI to work?
(I'm currently using 2.4.13-ac7-preempt-k7, but I've tried 2.4.1[56] also, as
well as many earlier kernels.)
Daniel
---
Recursion n.:
See Recursion.
-- Random Shack Data Processing Dictionary
When ACPI hung on boot did you have APIC/IO-APIC compiled into
your kernel? I found when I compiled in APIC/IO-APIC on my Compaq presario
laptop it would hang on bootup also. Appears to get stuck when writing
out to a IO-Port.
-- James (QFire)
> I have an N5415, and am using your k7 patch (thanks much!). I don't use USB,
> so I didn't try or comment on your patch. However, I was never able to get
> ACPI to work. If I compiled it in without APM compiled in, it always hung on
> boot. So, I have only APM, which doesn't even show the battery life
> correctly. Whether or not I can suspend, knowing battery life would be an
> improvement. Is there something special I have to do to get ACPI to work?
> (I'm currently using 2.4.13-ac7-preempt-k7, but I've tried 2.4.1[56] also, as
> well as many earlier kernels.)
>
> Daniel
> ---
> Recursion n.:
> See Recursion.
> -- Random Shack Data Processing Dictionary
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Yeah, it was. After I sent that mail, I saw something by Alan saying APIC and
PM don't work together well, so I turned off APIC, and it no longer hangs.
Daniel
On Wed, 5 Dec 2001 13:48:27 -0500
James Cassidy <[email protected]> wrote:
>
> When ACPI hung on boot did you have APIC/IO-APIC compiled into
> your kernel? I found when I compiled in APIC/IO-APIC on my Compaq presario
> laptop it would hang on bootup also. Appears to get stuck when writing
> out to a IO-Port.
>
> -- James (QFire)
>
> > I have an N5415, and am using your k7 patch (thanks much!). I don't use
USB,
> > so I didn't try or comment on your patch. However, I was never able to
get
> > ACPI to work. If I compiled it in without APM compiled in, it always hung
on
> > boot. So, I have only APM, which doesn't even show the battery life
> > correctly. Whether or not I can suspend, knowing battery life would be an
> > improvement. Is there something special I have to do to get ACPI to work?
> > (I'm currently using 2.4.13-ac7-preempt-k7, but I've tried 2.4.1[56] also,
as
> > well as many earlier kernels.)
> >
> > Daniel
> > ---
> > Recursion n.:
> > See Recursion.
> > -- Random Shack Data Processing Dictionary
---
Recursion n.:
See Recursion.
-- Random Shack Data Processing Dictionary
On Wed, 2001-12-05 at 08:41, John Clemens wrote:
> Sure.. I'll put yours up thought because it's slightly less intrusive. I
> was hoping to find out a much cleaner way of doing this before I put it
> up for anyone to use.... so i posted it here first... but as they say, the
> silence was deafening...
Tell me about it. I've emailed ALi to ask if they'll provide docs on how
to interperet link numbers. According to Microsoft's "PCI IRQ Routing
Table Specification" at
http://www.microsoft.com/hwdev/archive/BUSBIOS/pciirq.asp, "The non-zero
link values are specific to a chip set and decided by the chip-set
vendor."
> I'm afraid we may both be in over our heads here. That link number
> sppears to be some sort of code to help routing (see code for "see if
> hard-coded, it checks for 0xf"), and the mask is just what
> you think it is. However, from my gatherings, pIRQ tables are often wrong
> and thus ignored by Linux a lot of times. I think the -real- problem here
> is the bios is assigning IRQ's to PCI devices, and assign's 9 to the USB
> on startup, writes that to it's config registers, and Linux is stuck with
> it. But that's just speculation.
Over my head? I can't even see the surface from where I am...but I'm
learning. :>
See link above. BTW, the only instances I remember hearing about the
PIRQ table being wrong was in SMP machines, where you have an io-apic
anyway.
I think I'm onto something though - in read_config_nybble (called by
pirq_ali_get), the link number (0x59 for the usb device) minus one is
(after a little mangling) added to the "magic offset" 0x48 to generate
the offset at which a nybble is read from the pci configuration space of
the IRQ Router (dev 0:7.0). Since the code is expecting 0x1-0x8, it
doesn't check for wildly larger numbers. On my box, my first nybbles at
0x48 are 9, 9, and 5, which if you pass it through the Captain ALi
decoder ring equals irq's 11, 11, and 5. Therefore, links 0x01-0x03 work
fine, but link 0x59 translates to an offset of 0x74, which (on my
machine, and I bet yours) contains 0x01. The first nybble of 0x01 is
0x1, which on the translation table equals... IRQ 9! I imagine if you
"lspci -vxxx -s 00:07" you'll see something like 0x5009 at offset 0x6b
and 0x01 at offset 0x74. Would you mind sending me a "dump_pirq" and a
"lspci -vxxx -s 00:07"? I'd like to compare them to mine to see if what
I think is happening is really happening.
You're probably right about the BIOS being the root of the problem, but
if Linux is going to use the PIRQ table, it should at least do it
correctly. Hell, maybe the BIOS is reading the same table the same way
and that's where *it's* getting IRQ 9 - it's just bizzare enough to be
possible... :>
So, am I crazy, or does this make any sense to you? I cobbled together
the following mangled perl, adapted from the irq-routing code to test my
hypotheses:
perl -e '$link = 0x59 ; $val = 0x21 ; $link = $link - 1; $offset = 0x48 + ($link >> 1) ; $nyb = (($link & 1) ? ($val >> 4) : ($val & 0xf)); printf("Link %02x, Offset %02x, Val %02x = Nybble %1x\n",$link+1,$offset,$val,$nyb);'
Just give it the link# and it should tell you the offset and nybble to
look at in config space. It may even be correct!
> Yes, they just don't print out anymore (see
> arch/i386/kenrel/dmiscan.c<?>).
I see. I thought linus didn't like c++ style comments in kernel code?
> Who maintains the PCI irq routing code?
According to MAINTAINERS and linux/arch/i386/kernel/pci-irq.c, it's
Martin Mares - [email protected], which is why I cc'd him on the first message.
Haven't heard from him, though.
> john.c
Ha. :>
-Cory
On 5 Dec 2001, Cory Bell wrote:
> http://www.microsoft.com/hwdev/archive/BUSBIOS/pciirq.asp, "The non-zero
> link values are specific to a chip set and decided by the chip-set
> vendor."
My reference has been a borrowed book at my work, "PCI Hardware and
Software, Architecture and Design. 4th ed", Appendix I "IRQ Routing Table
Example.".. it also says it's motherboard and chipset specific.
> I think I'm onto something though - in read_config_nybble (called by
> pirq_ali_get), the link number (0x59 for the usb device) minus one is
> (after a little mangling) added to the "magic offset" 0x48 to generate
> the offset at which a nybble is read from the pci configuration space of
> the IRQ Router (dev 0:7.0). Since the code is expecting 0x1-0x8, it
> doesn't check for wildly larger numbers. On my box, my first nybbles at
> 0x48 are 9, 9, and 5, which if you pass it through the Captain ALi
> decoder ring equals irq's 11, 11, and 5. Therefore, links 0x01-0x03 work
> fine, but link 0x59 translates to an offset of 0x74, which (on my
> machine, and I bet yours) contains 0x01. The first nybble of 0x01 is
> 0x1, which on the translation table equals... IRQ 9! I imagine if you
> "lspci -vxxx -s 00:07" you'll see something like 0x5009 at offset 0x6b
> and 0x01 at offset 0x74. Would you mind sending me a "dump_pirq" and a
> "lspci -vxxx -s 00:07"? I'd like to compare them to mine to see if what
> I think is happening is really happening.
You are absolutely correct :) I did the same thing a few weeks ago (when i
was really working on it), and traced the lspci -vvxxx output and
interpreted everything linux was saying about it. I was looking at it
from the acpect of maybe just changing the PCI router in config space as
well as the PCI irq from user space without requiring kernel changes at
all. The reason why I didn't try that was because i chickened out and
didn't know wether changing the PIRQ table woudl a) work or b) permanently
screw up my machine. This may still be the "correct way" however...
The other reason I stopped was that USB works, on IRQ 9, under windows
(although, it does reset the bus about once every 5 minutes or so...
highly annoying when playing games). So maybe, just maybe, the IRQ table
is right, and maybe its linux's acpi implementation that's not playing
nice.
> You're probably right about the BIOS being the root of the problem, but
> if Linux is going to use the PIRQ table, it should at least do it
> correctly. Hell, maybe the BIOS is reading the same table the same way
> and that's where *it's* getting IRQ 9 - it's just bizzare enough to be
> possible... :>
Actually, i think the BIOS might "adjust" the pIRQ table at boot to match
it's view of the world. I don't know.
> According to MAINTAINERS and linux/arch/i386/kernel/pci-irq.c, it's
> Martin Mares - [email protected], which is why I cc'd him on the first message.
> Haven't heard from him, though.
I would really appreciate comments from someone who'se had more experience
than us with pIRQ problems...
I guess the question is where to we proceed from here. Our "best option"
may be to, at DMI scan time, recognise our laptops and change both PCI
config space and the routing table to point to irq 11. And then we just
have to be brave enough to try it. PCI config spae I don't mind mucking
with... internal chipset registers on the ISA bridge, that scares me
without proper documentation. Maybe we should ask ALi for it?
john.c
--
John Clemens http://www.deater.net/john
[email protected] ICQ: 7175925, IM: PianoManO8
"I Hate Quotes" -- Samuel L. Clemens
On Thu, 2001-12-06 at 07:11, John Clemens wrote:
> You are absolutely correct :) I did the same thing a few weeks ago (when i
> was really working on it), and traced the lspci -vvxxx output and
> interpreted everything linux was saying about it. I was looking at it
> from the acpect of maybe just changing the PCI router in config space as
> well as the PCI irq from user space without requiring kernel changes at
> all. The reason why I didn't try that was because i chickened out and
> didn't know wether changing the PIRQ table woudl a) work or b) permanently
> screw up my machine. This may still be the "correct way" however...
Well, the *actual* PIRQ table is supposed to be static, according to the
spec. I don't see the $PIR signature anywhere in the ROM, so it may be
generated on boot. As for changing the IRQ router PCI config space, the
last patch is doing that already - r->set is just calling pirq_ali_set,
which fiddles the bit in question.
Could you try a new patch? Works fine for me...
--- linux/arch/i386/kernel/pci-irq.c.dist Sun Nov 4 09:31:58 2001
+++ linux/arch/i386/kernel/pci-irq.c Thu Dec 6 15:09:54 2001
@@ -157,6 +157,13 @@
{
static unsigned char irqmap[16] = { 0, 9, 3, 10, 4, 5, 7, 6, 1, 11, 0, 12, 0, 14, 0, 15 };
+ if ( pirq == 0x59 &&
+ irqmap[read_config_nybble(router, 0x48, pirq-1)] == 9) {
+ write_config_nybble(router, 0x48, pirq-1, 9);
+ pci_write_config_byte(dev, PCI_INTERRUPT_LINE, 11);
+ dev->irq = 11;
+ DBG(" GROSS HP/ALi Hack Enabled!!");
+ }
return irqmap[read_config_nybble(router, 0x48, pirq-1)];
}
It special cases link 0x59 so we can do all our nastiness in one place
(and as a bonus, we're now completely out of the generic irq code). It's
still my gut feeling that the upper bits of 0x59 mean something special,
though. Hmmm.
> The other reason I stopped was that USB works, on IRQ 9, under windows
> (although, it does reset the bus about once every 5 minutes or so...
> highly annoying when playing games). So maybe, just maybe, the IRQ table
> is right, and maybe its linux's acpi implementation that's not playing
> nice.
Would you consider running powertweak or a similar utlity under windows
and sending me a config space dump of the 00:02 and 00:07 (USB and IRQ
Router)? I'd bet windows just "probed" for the IRQ somehow. Maybe it's
even operating in some sort of "polling" mode. Since it works more
reliably under linux forced to IRQ 11 than windows on IRQ ?, I'd say the
way windows is doing thing is probably not correct. I'd do it myself,
but I don't have windows on my laptop (unless you count WINE, for
playing fallout :>).
WRT ACPI, I think for linux, it's more like A_PI, i.e. I don't think it
touches any config code, just PM stuff. They haven't even let PnPBIOS
stuff into the mainstream kernel yet, so I doubt ACPI will replace the
PCI configuration code anytime soon. Besides, I get the same behavior
with acpi=off, and you see weird things under windows.
> Actually, i think the BIOS might "adjust" the pIRQ table at boot to match
> it's view of the world. I don't know.
I looked in the ROM file came with my latest BIOS update. I don't see
the $PIR signature in there anywhere, so it may be generated, but
static.
> I would really appreciate comments from someone who'se had more experience
> than us with pIRQ problems...
That makes two of us.
> I guess the question is where to we proceed from here. Our "best option"
> may be to, at DMI scan time, recognise our laptops and change both PCI
> config space and the routing table to point to irq 11. And then we just
> have to be brave enough to try it. PCI config spae I don't mind mucking
> with... internal chipset registers on the ISA bridge, that scares me
> without proper documentation. Maybe we should ask ALi for it?
Possibilities:
1) pirq_ali_get nastiness (above)
2) previous patch nastiness
3) DMI & 1
4) DMI & 2
5) ?
What do you think? Option 1 & 3 bother me a little, given that I find it
conceptually dirty to write to registers from a function intended to
read from registers. Still, is IS more separated from the generic code,
and it's all in one place.
WRT DMI: Would we just create an is_broken_hp_pavilion_bios variable,
similar to the is_sony_vaio_laptop variable? Declare it extern in
dmi_scan.c and declare it int pci-irq.c or the other way around? Would
it have to be a global variable?
I'm not really a C coder (I don't even play one on TV), I just code by
example...and I learn fairly quickly.
I'll call ALi USA tomorrow morning. I used their "tech support page",
but got no response. Supposedly, Darlene Brown (in the San Jose, USA)
office is the one to speak to (I spoke to a secretary today). The
secretary told me they don't generally release datasheets to
individuals, but maybe I can get ahold of one, who knows. I also emailed
Dan Hollis, who posted looking for a datasheet a while ago, but he said
he never got one.
-Cory
On 06 Dec 2001 16:41:29 -0800
"Cory Bell" <[email protected]> wrote:
| On Thu, 2001-12-06 at 07:11, John Clemens wrote:
| > You are absolutely correct :) I did the same thing a few weeks ago (when i
| > was really working on it), and traced the lspci -vvxxx output and
| > interpreted everything linux was saying about it. I was looking at it
| > from the acpect of maybe just changing the PCI router in config space as
| > well as the PCI irq from user space without requiring kernel changes at
| > all. The reason why I didn't try that was because i chickened out and
| > didn't know wether changing the PIRQ table woudl a) work or b) permanently
| > screw up my machine. This may still be the "correct way" however...
|
| Well, the *actual* PIRQ table is supposed to be static, according to the
| spec. I don't see the $PIR signature anywhere in the ROM, so it may be
| generated on boot. As for changing the IRQ router PCI config space, the
| last patch is doing that already - r->set is just calling pirq_ali_set,
| which fiddles the bit in question.
|
...
|
| > Actually, i think the BIOS might "adjust" the pIRQ table at boot to match
| > it's view of the world. I don't know.
|
| I looked in the ROM file came with my latest BIOS update. I don't see
| the $PIR signature in there anywhere, so it may be generated, but
| static.
Hi-
Did your search for "$PIR" or "RIP$" ?
It is suppsed to be the latter (little-endian).
~Randy
| > I would really appreciate comments from someone who'se had more experience
| > than us with pIRQ problems...
|
| That makes two of us.
|
| > I guess the question is where to we proceed from here. Our "best option"
| > may be to, at DMI scan time, recognise our laptops and change both PCI
| > config space and the routing table to point to irq 11. And then we just
| > have to be brave enough to try it. PCI config spae I don't mind mucking
| > with... internal chipset registers on the ISA bridge, that scares me
| > without proper documentation. Maybe we should ask ALi for it?
|
| Possibilities:
| 1) pirq_ali_get nastiness (above)
| 2) previous patch nastiness
| 3) DMI & 1
| 4) DMI & 2
| 5) ?
|
| What do you think? Option 1 & 3 bother me a little, given that I find it
| conceptually dirty to write to registers from a function intended to
| read from registers. Still, is IS more separated from the generic code,
| and it's all in one place.
|
| WRT DMI: Would we just create an is_broken_hp_pavilion_bios variable,
| similar to the is_sony_vaio_laptop variable? Declare it extern in
| dmi_scan.c and declare it int pci-irq.c or the other way around? Would
| it have to be a global variable?
|
| I'm not really a C coder (I don't even play one on TV), I just code by
| example...and I learn fairly quickly.
|
| I'll call ALi USA tomorrow morning. I used their "tech support page",
| but got no response. Supposedly, Darlene Brown (in the San Jose, USA)
| office is the one to speak to (I spoke to a secretary today). The
| secretary told me they don't generally release datasheets to
| individuals, but maybe I can get ahold of one, who knows. I also emailed
| Dan Hollis, who posted looking for a datasheet a while ago, but he said
| he never got one.
On Thu, 2001-12-06 at 17:03, Randy.Dunlap wrote:
> Hi-
>
> Did your search for "$PIR" or "RIP$" ?
> It is suppsed to be the latter (little-endian).
Tried both. The flash BIOS update might be reading system specific stuff
and then appending it to the new update, though. Maybe they have
separate "code" and data areas, and the the data part never gets
overwritten.
Would you happen to have any thoughts or advice WRT the problem we have
and the proper method of addressing it? Absent a BIOS fix, of course,
which I imagine would be the ultimate solution.
-Cory
On 6 Dec 2001, Cory Bell wrote:
| On Thu, 2001-12-06 at 17:03, Randy.Dunlap wrote:
| > Hi-
| >
| > Did your search for "$PIR" or "RIP$" ?
| > It is suppsed to be the latter (little-endian).
|
| Tried both. The flash BIOS update might be reading system specific stuff
| and then appending it to the new update, though. Maybe they have
| separate "code" and data areas, and the the data part never gets
| overwritten.
|
| Would you happen to have any thoughts or advice WRT the problem we have
| and the proper method of addressing it? Absent a BIOS fix, of course,
| which I imagine would be the ultimate solution.
Nothing specific, sorry.
Get SiS, ALI, VIA, and ServerWorks to publish their specs. :)
Good luck.
--
~Randy
Hey there.
On 6 Dec 2001, Cory Bell wrote:
> On Thu, 2001-12-06 at 17:03, Randy.Dunlap wrote:
> > Hi-
> >
> > Did your search for "$PIR" or "RIP$" ?
> > It is suppsed to be the latter (little-endian).
>
> Tried both. The flash BIOS update might be reading system specific stuff
> and then appending it to the new update, though. Maybe they have
> separate "code" and data areas, and the the data part never gets
> overwritten.
>
> Would you happen to have any thoughts or advice WRT the problem we have
> and the proper method of addressing it? Absent a BIOS fix, of course,
> which I imagine would be the ultimate solution.
How new is this system?
If it's new (3-6 months) PCI IRQ information is probably encoded in ACPI
AML methods. OEMs are gradually changing from the old way (PIRQ and MP
tables, APM) to new Grand Unified Way(tm) (ACPI).
For a while now, BIOSes have shipped with both old tables and ACPI tables,
and in a lot of cases, one or the other lies. So, you're almost lucky in a
sense. Unfortunately, it doesn't solve your problem.
For some reason, the people that wrote the spec encoded PCI IRQ
information in AML (ACPI Machine Language), instead of putting them in a
flat table. Which means you need the interpretor up and running and you
need to execute those methods (don't ask, just nod and smile).
The Intel ACPI guys kinda have this working. They are able to extract and
execute the methods. But, they still have yet to make devices request and
use that information. Maybe Andy Grover can comment on this..
BTW, The latest ACPI patch is at: http://sourceforge.net/projects/acpi/.
-pat
> From: Patrick Mochel [mailto:[email protected]]
> The Intel ACPI guys kinda have this working. They are able to
> extract and
> execute the methods. But, they still have yet to make devices
> request and
> use that information. Maybe Andy Grover can comment on this..
>
> BTW, The latest ACPI patch is at:
> http://sourceforge.net/projects/acpi/.
Exactly right. Our current patch will print a nice list for each PCI to PCI
bridge, but pci-irq.c isn't actually using the data yet on IA32. (IA64 does
use _PRT data.) We'll get around to doing this (eventually) but it would
happen sooner if someone else stepped up and lent a hand...
Regards -- Andy
On Fri, 2001-12-07 at 09:35, Patrick Mochel wrote:
>
> Hey there.
Hey to you too - thanks for chiming in!
> How new is this system?
Brand spankin'. About 3 weeks old. It's definitely acronym compliant
(ACPI, DMI, etc).
> If it's new (3-6 months) PCI IRQ information is probably encoded in ACPI
> AML methods. OEMs are gradually changing from the old way (PIRQ and MP
> tables, APM) to new Grand Unified Way(tm) (ACPI).
I've already noticed that APM locks the machine when "console blanking
with APM" is turned on. The ACPI semantics seem a bit bizarre (the
executable code thing), but it's worked well on (recent) laptops I've
used. Besides, new stuff is cool!
> For a while now, BIOSes have shipped with both old tables and ACPI tables,
> and in a lot of cases, one or the other lies. So, you're almost lucky in a
> sense. Unfortunately, it doesn't solve your problem.
Bizarrely enough, it seems that BOTH the $PIR table and the ACPI table
are borken (at least HP's BIOS engineers are consistent). dump_pirq
reports that 00:02 (my usb controller) is on "link" 0x59 (all the other
links are 0x00-0x03). The $PIR *mask* is correct, though (according to
it, IRQ ll is the only allowable for that slot. As you can see below,
the ACPI table seems to agree about irq 9.
ACPI: Core Subsystem version [20011205]
...
ACPI: PCI Routing Table (bus 00)
device=02 pin=00 irq=9
device=04 pin=00 irq=11
device=04 pin=01 irq=11
device=08 pin=00 irq=5
device=10 pin=00 irq=11
ACPI: PCI Routing Table (bus 01)
device=00 pin=00 irq=11
> For some reason, the people that wrote the spec encoded PCI IRQ
> information in AML (ACPI Machine Language), instead of putting them in a
> flat table. Which means you need the interpretor up and running and you
> need to execute those methods (don't ask, just nod and smile).
Nod. :>
> The Intel ACPI guys kinda have this working. They are able to extract and
> execute the methods. But, they still have yet to make devices request and
> use that information. Maybe Andy Grover can comment on this..
>
> BTW, The latest ACPI patch is at: http://sourceforge.net/projects/acpi/.
Thanks! Just got it and tried it.
Could I get your comments on a patch against 2.4.16-stock? I'm trying to
figure out the best way to automagically work around the bug, and this
is the best I've come up with so far. I need more DMI data from other HP
5400 series AMD/ALi laptops with the problem to come up with the most
accurate matches - right now it's tied to my machine type and BIOS
version.
--- linux/arch/i386/kernel/dmi_scan.c Mon Dec 3 22:11:36 2001
+++ linux/arch/i386/kernel/dmi_scan.c Fri Dec 7 01:14:18 2001
@@ -414,6 +414,20 @@
return 0;
}
+/*
+ * Work around broken HP Pavilion Notebooks which assign USB to
+ * IRQ 9 even though it is actually wired to IRQ 11
+ */
+static __init int fix_broken_hp_bios_irq9(struct dmi_blacklist *d)
+{
+ extern int broken_hp_bios_irq9;
+ if (broken_hp_bios_irq9 == 0)
+ {
+ broken_hp_bios_irq9 = 1;
+ printk(KERN_INFO "%s detected - fixing broken IRQ routing\n", d->ident);
+ }
+ return 0;
+}
/*
* Simple "print if true" callback
@@ -603,7 +617,14 @@
NO_MATCH, NO_MATCH
} },
-
+ { fix_broken_hp_bios_irq9, "HP Pavilion N5400 Series Laptop", {
+ MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
+ MATCH(DMI_BIOS_VERSION, "GE.M1.03"),
+ MATCH(DMI_PRODUCT_VERSION, "HP Pavilion Notebook Model GE"),
+ MATCH(DMI_BOARD_VERSION, "OmniBook N32N-736")
+ } },
+
+
/*
* Generic per vendor APM settings
*/
--- linux/arch/i386/kernel/pci-irq.c Sun Nov 4 09:31:58 2001
+++ linux/arch/i386/kernel/pci-irq.c Fri Dec 7 00:38:17 2001
@@ -22,6 +22,8 @@
#define PIRQ_SIGNATURE (('$' << 0) + ('P' << 8) + ('I' << 16) + ('R' << 24))
#define PIRQ_VERSION 0x0100
+int broken_hp_bios_irq9;
+
static struct irq_routing_table *pirq_table;
/*
@@ -565,6 +567,15 @@
DBG(" -> PIRQ %02x, mask %04x, excl %04x", pirq, mask, pirq_table->exclusive_irqs);
mask &= pcibios_irq_mask;
+ /* Work around broken HP Pavilion Notebooks which assign USB to
+ IRQ 9 even though it is actually wired to IRQ 11 */
+
+ if (broken_hp_bios_irq9 && pirq == 0x59 && dev->irq == 9) {
+ dev->irq = 11;
+ pci_write_config_byte(dev, PCI_INTERRUPT_LINE, 11);
+ r->set(pirq_router_dev, dev, pirq, 11);
+ }
+
/*
* Find the best IRQ to assign: use the one
* reported by the device if possible.
On 07 Dec 2001 13:23:53 -0800
Cory Bell <[email protected]> wrote:
> Could I get your comments on a patch against 2.4.16-stock? I'm trying to
> figure out the best way to automagically work around the bug, and this
> is the best I've come up with so far. I need more DMI data from other HP
> 5400 series AMD/ALi laptops with the problem to come up with the most
> accurate matches - right now it's tied to my machine type and BIOS
> version.
I have a N5415 with the shipped BIOS. (I've downloaded but not applied the
BIOS update. I'd have to boot into Windows to apply it. :) What do you want
me to send you?
Daniel
---
Recursion n.:
See Recursion.
-- Random Shack Data Processing Dictionary
On Fri, 2001-12-07 at 13:48, Daniel Gryniewicz wrote:
> I have a N5415 with the shipped BIOS. (I've downloaded but not applied the
> BIOS update. I'd have to boot into Windows to apply it. :) What do you want
> me to send you?
Thanks for the response! I'm assuming the N5415 is an AMD Athlon or
Duron based notebook (some are PIII/Celeron). Are you having the same
problem with USB?
WRT the BIOS update, if you have WINE, you can run the .exe (I had to
use the keyboard shortcut for "Next", clicking didn't work). It won't
actually create the update disk, but it will extract the disk image into
an oddly-named directory under your WINE "TMP" directory. Look for
BIOS.IMG. Then run "dd if=BIOS.IMG of=/dev/fd0 bs=32c skip=1" (their
image format has a 32-byte header) and boom, there's your update disk!
It's even bootable.
The following patch will cause your DMI info to be printed to the screen
on boot. If you just apply the patch, recompile, and email (off-list) me
the "dmesg" output, that should be all I need. If you're feeling extra
helpful, email me the output of "dump_pirq" (from the pcmcia-cs package,
in the "debug-tools" directory) and "lspci -vvvxxx", too.
*** CUT HERE ***
--- linux/arch/i386/kernel/dmi_scan.c Mon Nov 26 14:39:41 2001
+++ linux/arch/i386/kernel/dmi_scan.c Fri Dec 7 14:25:18 2001
@@ -20,8 +20,8 @@
u16 handle;
};
-#define dmi_printk(x)
-//#define dmi_printk(x) printk x
+//#define dmi_printk(x)
+#define dmi_printk(x) printk x
static char * __init dmi_string(struct dmi_header *dm, u8 s)
{
*** CUT HERE ***
Thanks again!
-Cory
Hi!
> > You are absolutely correct :) I did the same thing a few weeks ago (when i
> > was really working on it), and traced the lspci -vvxxx output and
> > interpreted everything linux was saying about it. I was looking at it
> > from the acpect of maybe just changing the PCI router in config space as
> > well as the PCI irq from user space without requiring kernel changes at
> > all. The reason why I didn't try that was because i chickened out and
> > didn't know wether changing the PIRQ table woudl a) work or b) permanently
> > screw up my machine. This may still be the "correct way" however...
>
> Well, the *actual* PIRQ table is supposed to be static, according to the
> spec. I don't see the $PIR signature anywhere in the ROM, so it may be
> generated on boot. As for changing the IRQ router PCI config space, the
> last patch is doing that already - r->set is just calling pirq_ali_set,
> which fiddles the bit in question.
>
> Could you try a new patch? Works fine for me...
>
> --- linux/arch/i386/kernel/pci-irq.c.dist Sun Nov 4 09:31:58 2001
> +++ linux/arch/i386/kernel/pci-irq.c Thu Dec 6 15:09:54 2001
> @@ -157,6 +157,13 @@
> {
> static unsigned char irqmap[16] = { 0, 9, 3, 10, 4, 5, 7, 6, 1, 11, 0, 12, 0, 14, 0, 15 };
>
> + if ( pirq == 0x59 &&
> + irqmap[read_config_nybble(router, 0x48, pirq-1)] == 9) {
> + write_config_nybble(router, 0x48, pirq-1, 9);
> + pci_write_config_byte(dev, PCI_INTERRUPT_LINE, 11);
> + dev->irq = 11;
> + DBG(" GROSS HP/ALi Hack Enabled!!");
> + }
> return irqmap[read_config_nybble(router, 0x48, pirq-1)];
> }
Hey, this gross hack fixed USB on HP OmniBook xe3. Good! (Perhaps you
know what interrupt is right for maestro3, also on omnibook? ;-).
Pavel
--
"I do not steal MS software. It is not worth it."
-- Pavel Kankovsky
On Fri, 2001-12-07 at 12:33, Pavel Machek wrote:
> Hey, this gross hack fixed USB on HP OmniBook xe3. Good! (Perhaps you
> know what interrupt is right for maestro3, also on omnibook? ;-).
On my Pavilion (and the other 5400's as far as I can tell), maestro's on
irq 5. Wanna send me a "dump_pirq" and a "lspci -vvvxxx"? Could you try
the patch below (inspired by/stolen from Kai Germaschewski)? Also, the
newest acpi patch will print out the acpi irq routing table - might have
your info. You can tell if the patch below had any effect because it
will say it ASSIGNED IRQ XX instead of FOUND.
I believe the Omnibook XEs and the Pavilion N5400's are very similar
hardware. Several of the drivers I've seen on HP's website appear to
apply to both. If you want to help get the BIOS updated (the root cause,
IMHO), please call HP support and reference case number 1429683616 (that
9 may be a 4 - my handwriting is horrible). That's the case I logged
with thim about the broken PIR table (USB irq showing 9; being 11) and
failure to enable sse on athlon 4/duron/xp chips.
Thanks for the info!
-Cory
The "honor the irq mask" approach (works on my machine):
--- /home/cbell/linux-2.4/arch/i386/kernel/pci-irq.c Fri Dec 7 01:51:41 2001
+++ /home/cbell/linux-2.4-test/arch/i386/kernel/pci-irq.c Sat Dec 8 21:04:37 2001
@@ -581,6 +581,7 @@
* reported by the device if possible.
*/
newirq = dev->irq;
+ if (!((1 << newirq) & mask)) newirq = 0;
if (!newirq && assign) {
for (i = 0; i < 16; i++) {
if (!(mask & (1 << i)))
@@ -599,7 +600,7 @@
irq = pirq & 0xf;
DBG(" -> hardcoded IRQ %d\n", irq);
msg = "Hardcoded";
- } else if (r->get && (irq = r->get(pirq_router_dev, dev, pirq))) {
+ } else if (r->get && (irq = r->get(pirq_router_dev, dev, pirq) && ((1 << irq) & mask))) {
DBG(" -> got IRQ %d\n", irq);
msg = "Found";
} else if (newirq && r->set && (dev->class >> 8) != PCI_CLASS_DISPLAY_VGA) {
@@ -633,7 +634,7 @@
continue;
if (info->irq[pin].link == pirq) {
/* We refuse to override the dev->irq information. Give a warning! */
- if (dev2->irq && dev2->irq != irq) {
+ if (dev2->irq && dev2->irq != irq && ((1 << dev2->irq) & mask)) {
printk(KERN_INFO "IRQ routing conflict for %s, have irq %d, want irq %d\n",
dev2->slot_name, dev2->irq, irq);
continue;
Hi!
So I investigated a little more, and maestro3 soundcard is also hooked
at irq 11 -- with this *very* cruel hack it works for me (at least
playback).
--- clean/drivers/sound/maestro3.c Thu Oct 11 18:43:30 2001
+++ linux/drivers/sound/maestro3.c Sat Dec 8 23:39:28 2001
@@ -2685,7 +2683,7 @@
}
}
- if(request_irq(card->irq, m3_interrupt, SA_SHIRQ, card_names[card->card_type], card)) {
+ if(request_irq(11 /* card->irq Gross hack */, m3_interrupt, SA_SHIRQ, card_names[card->card_type], card)) {
printk(KERN_ERR PFX "unable to allocate irq %d,\n", card->irq);
Pavel
--
"I do not steal MS software. It is not worth it."
-- Pavel Kankovsky
Hi!
> Could I get your comments on a patch against 2.4.16-stock? I'm trying to
> figure out the best way to automagically work around the bug, and this
> is the best I've come up with so far. I need more DMI data from other HP
> 5400 series AMD/ALi laptops with the problem to come up with the most
> accurate matches - right now it's tied to my machine type and BIOS
> version.
Yep. Patch looks reasonable.
I have same problem on HP Omnibook xe3, and yes, your previous patch
fixed it (as I wrote you). Here's DMI output
DMI 2.2 present.
29 structures occupying 935 bytes.
DMI table at 0x000DC010.
BIOS Vendor: Phoenix Technologies LTD
BIOS Version: GD.M1.08
BIOS Release: 09/27/2001
System Vendor: Hewlett-Packard.
Product Name: HP OmniBook PC .
Version HP OmniBook XE3 GD .
Serial Number T*********.
Board Vendor: Hewlett-Packard.
Board Name: N/A.
Board Version: OmniBook N32N-736.
Asset Tag: No Asset Tag.
But... my maestro3 still does not work properly. Does yours? Or you
have another soundcard?
Pavel
--
"I do not steal MS software. It is not worth it."
-- Pavel Kankovsky
On Sat, 2001-12-08 at 15:04, Pavel Machek wrote:
> Hi!
>
> So I investigated a little more, and maestro3 soundcard is also hooked
> at irq 11 -- with this *very* cruel hack it works for me (at least
> playback).
What IRQ did the maestro think it was on previously? Could you send me a
"lspci -vvvxxx" and "dump_pirq"? I'd like to compare it to mine.
I'd be curious to see if the last patch I posted (the "honor irq masks"
patch) fixes one or both of your problems.
-Cory
Hi!
> > Hey, this gross hack fixed USB on HP OmniBook xe3. Good! (Perhaps you
> > know what interrupt is right for maestro3, also on omnibook? ;-).
>
> On my Pavilion (and the other 5400's as far as I can tell), maestro's on
> irq 5. Wanna send me a "dump_pirq" and a "lspci -vvvxxx"? Could you try
I forced maestro on irq11, and it now works, but pcmcia locks up. Maybe
11 is not correct, but it just happens frequene enough for sound to play
back?
Ugh... Yep, if I hooked maestro on USB interrupt.... Of course that would
work!
Ouch, you said you have maestro on irq5. And does it *work*? For me,
it plays mp3 but repeats portions even on wrong interrupt.
> the patch below (inspired by/stolen from Kai Germaschewski)? Also, the
> newest acpi patch will print out the acpi irq routing table - might have
> your info. You can tell if the patch below had any effect because it
> will say it ASSIGNED IRQ XX instead of FOUND.
Will patch below fix the problem or just print tables?
> apply to both. If you want to help get the BIOS updated (the root cause,
> IMHO), please call HP support and reference case number 1429683616 (that
> 9 may be a 4 - my handwriting is horrible). That's the case I logged
> with thim about the broken PIR table (USB irq showing 9; being 11) and
> failure to enable sse on athlon 4/duron/xp chips.
I'm afraid I'm not going to call HP, sitting in europe. Also not sure if
I'll be able to update BIOS, notebook is not exactly mine ("Trash anything
on the disk, but don't kill the machine").
Pavel
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
On Sun, 9 Dec 2001, Pavel Machek wrote:
> Hi!
>
> > > Hey, this gross hack fixed USB on HP OmniBook xe3. Good! (Perhaps you
> > > know what interrupt is right for maestro3, also on omnibook? ;-).
I've updated my bios on my Pavilion N5430 and guess what is shows on
the bios boot screen (if you disable the bios splash screen)... Omnibook
XE3. They are one in the same, at least model number wise. weird,
considering there are no AMD omnibooks..
> Ouch, you said you have maestro on irq5. And does it *work*? For me,
> it plays mp3 but repeats portions even on wrong interrupt.
My maestro is on IRQ 5, and the pIRQ table says it should be on IRQ 5, and
it works fine. Earlier 2.4 kernels (before .8 or .9) had all sorts of
problems with the maestro3 (actually Allegro-1), but i haven't had any
problems in a while.. Try ALSA, see if that fixes your problems.
> > apply to both. If you want to help get the BIOS updated (the root cause,
> > IMHO), please call HP support and reference case number 1429683616 (that
> > 9 may be a 4 - my handwriting is horrible). That's the case I logged
> > with thim about the broken PIR table (USB irq showing 9; being 11) and
> > failure to enable sse on athlon 4/duron/xp chips.
Good luck.. I emailed HP support, and got the "we're forwarding your
request to the BIOS people".. and that was 4 months ago.
Ohh, and Marcelo accepted the K7/SSE patch for 2.4.17, so no need for that
patch anymore..
I will try the ACPI PCI routing stuff if i get time tonight (don't have
access to the machine right now).
john.c
--
John Clemens http://www.deater.net/john
[email protected] ICQ: 7175925, IM: PianoManO8
"I Hate Quotes" -- Samuel L. Clemens
Hi!
> > Hey, this gross hack fixed USB on HP OmniBook xe3. Good! (Perhaps you
> > know what interrupt is right for maestro3, also on omnibook? ;-).
>
> On my Pavilion (and the other 5400's as far as I can tell), maestro's on
> irq 5. Wanna send me a "dump_pirq" and a "lspci -vvvxxx"? Could you try
> the patch below (inspired by/stolen from Kai Germaschewski)? Also, the
> newest acpi patch will print out the acpi irq routing table - might have
> your info. You can tell if the patch below had any effect because it
> will say it ASSIGNED IRQ XX instead of FOUND.
>
> I believe the Omnibook XEs and the Pavilion N5400's are very similar
> hardware. Several of the drivers I've seen on HP's website appear to
> apply to both. If you want to help get the BIOS updated (the root cause,
> IMHO), please call HP support and reference case number 1429683616 (that
> 9 may be a 4 - my handwriting is horrible). That's the case I logged
> with thim about the broken PIR table (USB irq showing 9; being 11) and
> failure to enable sse on athlon 4/duron/xp chips.
I called them... The girl who received call was very friendly, wanted
to assign me bug#, but I resisted. I told her your bug#, but only
reply I got was something like "all our bug numbers begin with 1327",
and she apparently had no access to global database. I am not sure the
person knew what I was talking about.
He told me there's updated bios, somewhere. Did you try that?
What exactly is wrong? You said PIR tables are broken, but with patch
below, it seems to work. What's wrong?
Pavel
> The "honor the irq mask" approach (works on my machine):
> --- /home/cbell/linux-2.4/arch/i386/kernel/pci-irq.c Fri Dec 7 01:51:41 2001
> +++ /home/cbell/linux-2.4-test/arch/i386/kernel/pci-irq.c Sat Dec 8 21:04:37 2001
> @@ -581,6 +581,7 @@
> * reported by the device if possible.
> */
> newirq = dev->irq;
> + if (!((1 << newirq) & mask)) newirq = 0;
> if (!newirq && assign) {
> for (i = 0; i < 16; i++) {
> if (!(mask & (1 << i)))
> @@ -599,7 +600,7 @@
> irq = pirq & 0xf;
> DBG(" -> hardcoded IRQ %d\n", irq);
> msg = "Hardcoded";
> - } else if (r->get && (irq = r->get(pirq_router_dev, dev, pirq))) {
> + } else if (r->get && (irq = r->get(pirq_router_dev, dev, pirq) && ((1 << irq) & mask))) {
> DBG(" -> got IRQ %d\n", irq);
> msg = "Found";
> } else if (newirq && r->set && (dev->class >> 8) != PCI_CLASS_DISPLAY_VGA) {
> @@ -633,7 +634,7 @@
> continue;
> if (info->irq[pin].link == pirq) {
> /* We refuse to override the dev->irq information. Give a warning! */
> - if (dev2->irq && dev2->irq != irq) {
> + if (dev2->irq && dev2->irq != irq && ((1 << dev2->irq) & mask)) {
> printk(KERN_INFO "IRQ routing conflict for %s, have irq %d, want irq %d\n",
> dev2->slot_name, dev2->irq, irq);
> continue;
--
Casualities in World Trade Center: 6453 dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
Hi!
> > > > Hey, this gross hack fixed USB on HP OmniBook xe3. Good! (Perhaps you
> > > > know what interrupt is right for maestro3, also on omnibook? ;-).
>
> I've updated my bios on my Pavilion N5430 and guess what is shows on
> the bios boot screen (if you disable the bios splash screen)... Omnibook
> XE3. They are one in the same, at least model number wise. weird,
> considering there are no AMD omnibooks..
I *do* have AMD omnibook on my table.
> > Ouch, you said you have maestro on irq5. And does it *work*? For me,
> > it plays mp3 but repeats portions even on wrong interrupt.
>
> My maestro is on IRQ 5, and the pIRQ table says it should be on IRQ 5, and
> it works fine. Earlier 2.4 kernels (before .8 or .9) had all sorts of
> problems with the maestro3 (actually Allegro-1), but i haven't had any
> problems in a while.. Try ALSA, see if that fixes your problems.
Interrupts are not comming. If I hook it on irq11 (usb), and make usb
generate interrupts, it plays.
> > > apply to both. If you want to help get the BIOS updated (the root cause,
> > > IMHO), please call HP support and reference case number 1429683616 (that
> > > 9 may be a 4 - my handwriting is horrible). That's the case I logged
> > > with thim about the broken PIR table (USB irq showing 9; being 11) and
> > > failure to enable sse on athlon 4/duron/xp chips.
>
> Good luck.. I emailed HP support, and got the "we're forwarding your
> request to the BIOS people".. and that was 4 months ago.
>
> Ohh, and Marcelo accepted the K7/SSE patch for 2.4.17, so no need for that
> patch anymore..
I do not much care about sse, but I'd prefer my sound working :-(.
Pavel
--
Casualities in World Trade Center: 6453 dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
On Mon, 10 Dec 2001, Pavel Machek wrote:
> > I've updated my bios on my Pavilion N5430 and guess what is shows on
> > the bios boot screen (if you disable the bios splash screen)... Omnibook
> > XE3. They are one in the same, at least model number wise. weird,
> > considering there are no AMD omnibooks..
>
> I *do* have AMD omnibook on my table.
Err.. that's weird, as if you look in HP's page, the Omnibook XE3 is
listed as Pentium3/Celeron w/ the i830MG chipset only. However, the
pictures of it show the casing to be almost identical to my N5430. But, i
don't doubt that you have one.. just an interesting observation.
> Interrupts are not comming. If I hook it on irq11 (usb), and make usb
> generate interrupts, it plays.
My apologies, i misunderstood what you were saying before.. As an
additional data point, one person who tried my origional USB hack (moving
it to IRQ 11) also reported possible problems with PCMCIA not working
anymore... this isn't my experience however. Also note that the Trident
BladeXP is also on IRQ11, not that linux should care.
Also, the N5425, and N5415 are -newer- revisions of the origional N5430
and N5470 HP Athlon based notebooks... so it's not exactly a 1:1
correlation... I'm also guessing the XE3 is not the same revision as
either of the origional ones (I have an N5430).
Also, I'm running BIOS rev GD1.08 (it shipped with GD1.03, and i tried
GD1.06 when it came out).. what is everyone else running?
john.c
--
John Clemens http://www.deater.net/john
[email protected] ICQ: 7175925, IM: PianoManO8
"I Hate Quotes" -- Samuel L. Clemens
Hi!
> > > > Hey, this gross hack fixed USB on HP OmniBook xe3. Good! (Perhaps you
> > > > know what interrupt is right for maestro3, also on omnibook? ;-).
>
> I've updated my bios on my Pavilion N5430 and guess what is shows on
> the bios boot screen (if you disable the bios splash screen)... Omnibook
> XE3. They are one in the same, at least model number wise. weird,
> considering there are no AMD omnibooks..
Get /tmp/xe3-tech-code-11-2-01.pdf document from hp. It looks like
they are ;-).
Pavel
--
Casualities in World Trade Center: 6453 dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
On Mon, 2001-12-10 at 07:26, John Clemens wrote:
> I've updated my bios on my Pavilion N5430 and guess what is shows on
> the bios boot screen (if you disable the bios splash screen)... Omnibook
> XE3. They are one in the same, at least model number wise. weird,
> considering there are no AMD omnibooks..
The DMI info is suspiciously similar to ours, as well. Same "Board
Version"...
> Good luck.. I emailed HP support, and got the "we're forwarding your
> request to the BIOS people".. and that was 4 months ago.
They never gave you a case number?
> Ohh, and Marcelo accepted the K7/SSE patch for 2.4.17, so no need for that
> patch anymore..
Woohoo!
> I will try the ACPI PCI routing stuff if i get time tonight (don't have
> access to the machine right now).
For me, the new ACPI didn't help (just had the same table, USB on IRQ
9). And, of course, it doesn't actually do the routing, just displays it
(for now).
I'm leaning toward the "Stolen from Kai" patch over the "stolen from
you" patch. Seems a bit less hackish, and IMHO, the "correct" behavior
anyway (honoring the irq mask). Of course, that could bite us on PIR
tables with bad masks. Thoughts?
-Cory
On Mon, 2001-12-10 at 08:01, Pavel Machek wrote:
> I called them... The girl who received call was very friendly, wanted
> to assign me bug#, but I resisted. I told her your bug#, but only
> reply I got was something like "all our bug numbers begin with 1327",
> and she apparently had no access to global database. I am not sure the
> person knew what I was talking about.
What, 1st-level tech support staff lacking knowledge? Surely you jest!
:> Seriously, though, I was kind of lucky - I got a guy who's into
computers and plays with a Linux box at school. He was at least
receptive to my description of the problem.
> He told me there's updated bios, somewhere. Did you try that?
Latest BIOS for my machine is 1.03 - didn't help.
> What exactly is wrong? You said PIR tables are broken, but with patch
> below, it seems to work. What's wrong?
Take a look at http://www.microsoft.com/hwdev/archive/BUSBIOS/pciirq.asp
for some background. Under linux, on an ALi chipset, the "link" numbers
are used as an offset into the PCI config space of the ISA bridge, where
the IRQ for that "link" is stored. On my machine, the link numbers are
0x01-0x03 (for everything but USB) and 0x59 (for USB). The value at the
offset for link 0x59 translates to IRQ 9. The PCI configuration space of
the USB controller indicates IRQ 9, as well. See pirq_ali_get() in
linux/arch/i386/kernel/pci-irq.c for details on how this works.
All the last patch does is match the IRQ being considered for the device
against the IRQ mask for that device in the PIR table. If it doesn't
match, the kernel assigns one that does match the mask.
To be clear: with the last patch, USB works, but not the maestro-3,
right?
The reason I keep asking you for the output of "lspci -vvvxxx" and
"dump_pirq" is so I can look at your PIR table and PCI config space and
try to determine if the same thing that happened to USB is happening to
your maestro. It's possible your maestro problem is completely
unrelated. If you're unwilling to provide that informataion for some
reason, just let me know and I'll quit asking.
-Cory
On Mon, 2001-12-10 at 09:53, John Clemens wrote:
> My apologies, i misunderstood what you were saying before.. As an
> additional data point, one person who tried my origional USB hack (moving
> it to IRQ 11) also reported possible problems with PCMCIA not working
> anymore... this isn't my experience however. Also note that the Trident
> BladeXP is also on IRQ11, not that linux should care.
PCMCIA (16-bit, not cardbus) ethernet/modem (only tried the modem) works
fine for me with the patch. Haven't tried cardbus or multiple cards.
> Also, I'm running BIOS rev GD1.08 (it shipped with GD1.03, and i tried
> GD1.06 when it came out).. what is everyone else running?
1.03 (latest available).
-Cory
Hi!
> > My apologies, i misunderstood what you were saying before.. As an
> > additional data point, one person who tried my origional USB hack (moving
> > it to IRQ 11) also reported possible problems with PCMCIA not working
> > anymore... this isn't my experience however. Also note that the Trident
> > BladeXP is also on IRQ11, not that linux should care.
>
> PCMCIA (16-bit, not cardbus) ethernet/modem (only tried the modem) works
> fine for me with the patch. Haven't tried cardbus or multiple cards.
Yep, single PCMCIA card looks good even for me, it is two cards that
break, or swapping cards like crazy. I found out that disabling irq 5
(and 9?) in config.opts looks like a good trick. (You have to enable
something in compensation so you have enough irqs available, I let
pcmcia take irq 7).
Pavel
--
Casualities in World Trade Center: 6453 dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
Hi!
> > He told me there's updated bios, somewhere. Did you try that?
>
> Latest BIOS for my machine is 1.03 - didn't help.
>
> > What exactly is wrong? You said PIR tables are broken, but with patch
> > below, it seems to work. What's wrong?
>
> Take a look at
> http://www.microsoft.com/hwdev/archive/BUSBIOS/pciirq.asp
That's ... really evil.
> for some background. Under linux, on an ALi chipset, the "link" numbers
> are used as an offset into the PCI config space of the ISA bridge, where
> the IRQ for that "link" is stored. On my machine, the link numbers are
> 0x01-0x03 (for everything but USB) and 0x59 (for USB). The value at the
> offset for link 0x59 translates to IRQ 9. The PCI configuration space of
> the USB controller indicates IRQ 9, as well. See pirq_ali_get() in
So their BIOS wrongly set irq in config space of USB controller, right?
> linux/arch/i386/kernel/pci-irq.c for details on how this works.
>
> All the last patch does is match the IRQ being considered for the device
> against the IRQ mask for that device in the PIR table. If it doesn't
> match, the kernel assigns one that does match the mask.
Ahha. May that mean that our magic w.r.t. touching pci config space on
ALI chipsets is wrong?
> To be clear: with the last patch, USB works, but not the maestro-3,
> right?
Yes.
> The reason I keep asking you for the output of "lspci -vvvxxx" and
> "dump_pirq" is so I can look at your PIR table and PCI config space and
> try to determine if the same thing that happened to USB is happening to
> your maestro. It's possible your maestro problem is completely
> unrelated. If you're unwilling to provide that informataion for some
> reason, just let me know and I'll quit asking.
I thought I already mailed you lspci.... dump_pirq is not installed on
my machine, I'll try to install it and mail you that info. [Hmm, it
may be hard, because I'm now on modem link and behind nasty firewall;
perhaps you could just mail me dump_pirq binary if it does not need
special libraries?]
Pavel
--
Casualities in World Trade Center: 6453 dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
Hi!
> > Hey, this gross hack fixed USB on HP OmniBook xe3. Good! (Perhaps you
> > know what interrupt is right for maestro3, also on omnibook? ;-).
>
> On my Pavilion (and the other 5400's as far as I can tell), maestro's on
> irq 5. Wanna send me a "dump_pirq" and a "lspci -vvvxxx"? Could you try
> the patch below (inspired by/stolen from Kai Germaschewski)? Also, the
> newest acpi patch will print out the acpi irq routing table - might have
> your info. You can tell if the patch below had any effect because it
> will say it ASSIGNED IRQ XX instead of FOUND.
The patch should contain:
> The "honor the irq mask" approach (works on my machine):
> --- /home/cbell/linux-2.4/arch/i386/kernel/pci-irq.c Fri Dec 7 01:51:41 2001
> +++ /home/cbell/linux-2.4-test/arch/i386/kernel/pci-irq.c Sat Dec 8 21:04:37 2001
> @@ -581,6 +581,7 @@
> * reported by the device if possible.
> */
> newirq = dev->irq;
> + if (!((1 << newirq) & mask)) newirq = 0;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
printk(KERN_ERR "$PIR table inconsistent; chipset dependend code told
us interrupt is at %d, but irq mask is %lx\n", dev->irq, newirq);
We should never ever workaround BIOS problem without complaining.
Otherwise patch looks sane. Did you try submitting it to
linus/marcelo?
Pavel
--
Casualities in World Trade Center: 6453 dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
On Tue, 2001-12-11 at 02:14, Pavel Machek wrote:
> The patch should contain:
>
>
> > The "honor the irq mask" approach (works on my machine):
> > --- /home/cbell/linux-2.4/arch/i386/kernel/pci-irq.c Fri Dec 7 01:51:41 2001
> > +++ /home/cbell/linux-2.4-test/arch/i386/kernel/pci-irq.c Sat Dec 8 21:04:37 2001
> > @@ -581,6 +581,7 @@
> > * reported by the device if possible.
> > */
> > newirq = dev->irq;
> > + if (!((1 << newirq) & mask)) newirq = 0;
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> printk(KERN_ERR "$PIR table inconsistent; chipset dependend code told
> us interrupt is at %d, but irq mask is %lx\n", dev->irq, newirq);
>
> We should never ever workaround BIOS problem without complaining.
It may not be a bios problem. mask = (info->irq[pin].bitmap &
pcibios_irq_mask). So an IRQ might not match the mask because the user
specified a more restrictive mask than the $PIR table.
I suppose we could use a second variable (pir_mask?) that didn't get &'d
with pcibios_irq_mask to do the checks.
Ideas, anyone?
> Otherwise patch looks sane. Did you try submitting it to
> linus/marcelo?
Not yet. Wanted to do a bit more testing, especially considering the
pcmcia problems people have had. Do your pcmcia difficulties occur
without the patch, as well?
I'll test my 16-bit pcmcia modem/nic with my pcmcia scsi adapter, and
see if I get the same breakage.
Has anyone tried dual cardbus cards?
-Cory
Hi!
> > The patch should contain:
> >
> >
> > > The "honor the irq mask" approach (works on my machine):
> > > --- /home/cbell/linux-2.4/arch/i386/kernel/pci-irq.c Fri Dec 7 01:51:41 2001
> > > +++ /home/cbell/linux-2.4-test/arch/i386/kernel/pci-irq.c Sat Dec 8 21:04:37 2001
> > > @@ -581,6 +581,7 @@
> > > * reported by the device if possible.
> > > */
> > > newirq = dev->irq;
> > > + if (!((1 << newirq) & mask)) newirq = 0;
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > printk(KERN_ERR "$PIR table inconsistent; chipset dependend code told
> > us interrupt is at %d, but irq mask is %lx\n", dev->irq, newirq);
> >
> > We should never ever workaround BIOS problem without complaining.
>
> It may not be a bios problem. mask = (info->irq[pin].bitmap &
> pcibios_irq_mask). So an IRQ might not match the mask because the user
> specified a more restrictive mask than the $PIR table.
Okay, so it might be user error, but it is worth a printk, for sure.
> > Otherwise patch looks sane. Did you try submitting it to
> > linus/marcelo?
>
> Not yet. Wanted to do a bit more testing, especially considering the
> pcmcia problems people have had. Do your pcmcia difficulties occur
> without the patch, as well?
Yep. That machine was always touchy w.r.t. pcmcia.
Pavel
--
Casualities in World Trade Center: 6453 dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
On Tue, 2001-12-11 at 07:36, Pavel Machek wrote:
> Hi!
>
> > > The patch should contain:
> > >
> > >
> > > > The "honor the irq mask" approach (works on my machine):
> > > > --- /home/cbell/linux-2.4/arch/i386/kernel/pci-irq.c Fri Dec 7 01:51:41 2001
> > > > +++ /home/cbell/linux-2.4-test/arch/i386/kernel/pci-irq.c Sat Dec 8 21:04:37 2001
> > > > @@ -581,6 +581,7 @@
> > > > * reported by the device if possible.
> > > > */
> > > > newirq = dev->irq;
> > > > + if (!((1 << newirq) & mask)) newirq = 0;
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > printk(KERN_ERR "$PIR table inconsistent; chipset dependend code told
> > > us interrupt is at %d, but irq mask is %lx\n", dev->irq, newirq);
> > >
> > > We should never ever workaround BIOS problem without complaining.
> >
> > It may not be a bios problem. mask = (info->irq[pin].bitmap &
> > pcibios_irq_mask). So an IRQ might not match the mask because the user
> > specified a more restrictive mask than the $PIR table.
>
> Okay, so it might be user error, but it is worth a printk, for sure.
I think it's more like using the mem= parameter (user choice as opposed
to user error). If you have 256MB, but you specify "mem=64m", you don't
get a kernel message saying "e820 table incorrect: motherboard says you
have 256MB, only detected 64MB".
Note that I'm not saying we shouldn't warn if the PIR table really is
inconsistent, I'm just saying we shouldn't warn about an explicit
configuration choice.
What if we did the warning earlier (before we get into the irq
detection/assignment code) in pcibios_lookup_irq()? Just complain if
!(info->irq[pin].bitmap & (1 << r->get(pirq_router_dev, dev, pirq))).
Thoughts?
> > > Otherwise patch looks sane. Did you try submitting it to
> > > linus/marcelo?
> >
> > Not yet. Wanted to do a bit more testing, especially considering the
> > pcmcia problems people have had. Do your pcmcia difficulties occur
> > without the patch, as well?
>
> Yep. That machine was always touchy w.r.t. pcmcia.
Just copied 572MB from a cdrom hung off a pcmcia scsi adapter to my
desktop box via pcmcia ethernet card - everything went fine. I don't
have any cardbus cards to test, but I imagine they would work as well. I
was assigned irq 3 and irq 10 for the two devices. I did notice that it
seemed to prefer one device inserted at a time (as opposed to coming up
with both plugged in). Odd.
-Cory
Hi!
> > So I investigated a little more, and maestro3 soundcard is also hooked
> > at irq 11 -- with this *very* cruel hack it works for me (at least
> > playback).
>
> What IRQ did the maestro think it was on previously?
It thought it had 5. But it does not have 11, either :-(. But usb
interrupt is common enough so that sound just works.
> Could you send me a
> "lspci -vvvxxx" and "dump_pirq"? I'd like to compare it to mine.
I do not have dump_pirq handy.
lspci attached.
Pavel
> I'd be curious to see if the last patch I posted (the "honor irq masks"
> patch) fixes one or both of your problems.
I'll take a look.
--
"I do not steal MS software. It is not worth it."
-- Pavel Kankovsky
Hi!
> > Hey, this gross hack fixed USB on HP OmniBook xe3. Good! (Perhaps you
> > know what interrupt is right for maestro3, also on omnibook? ;-).
>
> On my Pavilion (and the other 5400's as far as I can tell), maestro's on
> irq 5. Wanna send me a "dump_pirq" and a "lspci -vvvxxx"? Could you try
> the patch below (inspired by/stolen from Kai Germaschewski)? Also, the
> newest acpi patch will print out the acpi irq routing table - might have
> your info. You can tell if the patch below had any effect because it
> will say it ASSIGNED IRQ XX instead of FOUND.
lspci attached to another mail.
This patch makes ohci work for me, but maestro is still broken.
Pavel
> The "honor the irq mask" approach (works on my machine):
> --- /home/cbell/linux-2.4/arch/i386/kernel/pci-irq.c Fri Dec 7 01:51:41 2001
> +++ /home/cbell/linux-2.4-test/arch/i386/kernel/pci-irq.c Sat Dec 8 21:04:37 2001
> @@ -581,6 +581,7 @@
> * reported by the device if possible.
> */
> newirq = dev->irq;
> + if (!((1 << newirq) & mask)) newirq = 0;
> if (!newirq && assign) {
> for (i = 0; i < 16; i++) {
> if (!(mask & (1 << i)))
> @@ -599,7 +600,7 @@
> irq = pirq & 0xf;
> DBG(" -> hardcoded IRQ %d\n", irq);
> msg = "Hardcoded";
> - } else if (r->get && (irq = r->get(pirq_router_dev, dev, pirq))) {
> + } else if (r->get && (irq = r->get(pirq_router_dev, dev, pirq) && ((1 << irq) & mask))) {
> DBG(" -> got IRQ %d\n", irq);
> msg = "Found";
> } else if (newirq && r->set && (dev->class >> 8) != PCI_CLASS_DISPLAY_VGA) {
> @@ -633,7 +634,7 @@
> continue;
> if (info->irq[pin].link == pirq) {
> /* We refuse to override the dev->irq information. Give a warning! */
> - if (dev2->irq && dev2->irq != irq) {
> + if (dev2->irq && dev2->irq != irq && ((1 << dev2->irq) & mask)) {
> printk(KERN_INFO "IRQ routing conflict for %s, have irq %d, want irq %d\n",
> dev2->slot_name, dev2->irq, irq);
> continue;
--
"I do not steal MS software. It is not worth it."
-- Pavel Kankovsky
Hi!
> > So I investigated a little more, and maestro3 soundcard is also hooked
> > at irq 11 -- with this *very* cruel hack it works for me (at least
> > playback).
>
> What IRQ did the maestro think it was on previously? Could you send me a
> "lspci -vvvxxx" and "dump_pirq"? I'd like to compare it to mine.
>
> I'd be curious to see if the last patch I posted (the "honor irq masks"
> patch) fixes one or both of your problems.
It fixes usb problem but not maestro3 one.
dump_pirq is:
Interrupt routing table found at address 0xfdf40:
Version 1.0, size 0x00a0
Interrupt router is device 00:07.0
PCI exclusive interrupt mask: 0x0000
Compatible router: vendor 0x10b9 device 0x1533
Device 00:0f.0 (slot 0):
Device 00:02.0 (slot 0):
INTA: link 0x59, irq mask 0x0800
Device 00:08.0 (slot 1):
INTA: link 0x49, irq mask 0x0020
Device 00:04.0 (slot 0):
INTA: link 0x48, irq mask 0x0800
INTB: link 0x48, irq mask 0x0800
Device 00:10.0 (slot 0):
INTA: link 0x48, irq mask 0x0800
Device 00:07.0 (slot 0):
INTA: link 0x48, irq mask 0xdef8
INTB: link 0x48, irq mask 0xdef8
INTC: link 0x49, irq mask 0xdef8
INTD: link 0x49, irq mask 0xdef8
Device 00:01.0 (slot 0):
INTA: link 0x48, irq mask 0x0800
Device 01:00.0 (slot 0):
INTA: link 0x48, irq mask 0x0800
Interrupt router at 00:07.0: AcerLabs Aladdin M1533 PCI-to-ISA bridge
INT1 (link 1): irq 11
INT2 (link 2): irq 11
INT3 (link 3): unrouted
INT4 (link 4): unrouted
INT5 (link 5): unrouted
INT6 (link 6): unrouted
INT7 (link 7): unrouted
INT8 (link 8): unrouted
Serial IRQ: [enabled] [continuous] [frame=21] [pulse=12]
lspci is:
00:00.0 Host bridge: Acer Laboratories Inc. [ALi]: Unknown device 1647 (rev 04)
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: 0
Region 0: Memory at f0000000 (32-bit, prefetchable) [size=64M]
Capabilities: [b0] AGP version 2.0
Status: RQ=27 SBA+ 64bit- FW+ Rate=x1,x2
Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
Capabilities: [a4] Power Management version 1
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: b9 10 47 16 07 00 10 a2 04 00 00 06 00 00 00 00
10: 08 00 00 f0 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 b0 00 00 00 00 00 00 00 00 00 00 00
40: 11 2f 0f 03 1a 10 04 2f 00 20 04 00 00 20 20 00
50: 01 00 00 00 05 10 04 2f 00 20 00 00 00 20 20 ff
60: c1 4b 30 85 00 70 00 00 0c 70 72 d9 40 22 19 05
70: 8b 8b 8b 8b 00 00 00 00 40 c0 77 47 04 18 03 03
80: 31 07 53 b7 31 07 10 e1 00 01 00 00 00 00 00 00
90: 15 40 50 81 00 00 00 00 08 00 00 00 d0 ae 00 00
a0: 30 80 01 00 01 00 01 06 00 00 00 00 00 00 00 00
b0: 02 a4 20 00 13 02 00 1b 00 00 00 00 08 00 20 00
c0: 00 00 13 10 00 00 00 f0 80 68 00 c0 00 00 00 00
d0: 07 f0 45 ff 00 b1 6b 15 00 00 00 80 81 81 80 00
e0: 00 2c 23 b9 40 00 00 00 00 00 08 00 00 07 00 00
f0: 00 80 00 46 00 06 80 03 00 01 01 47 00 00 00 00
00:01.0 PCI bridge: Acer Laboratories Inc. [ALi] M5247 (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: ea100000-efffffff
Prefetchable memory behind bridge: fff00000-000fffff
BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B-
00: b9 10 47 52 1f 00 00 04 00 00 04 06 00 00 01 00
10: 00 00 00 00 00 00 00 00 00 01 01 00 f0 00 20 a2
20: 10 ea f0 ef f0 ff 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0c 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00:02.0 USB Controller: Acer Laboratories Inc. [ALi] M5237 USB (rev 03) (prog-if 10 [OHCI])
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: 16 (20000ns max), cache line size 08
Interrupt: pin A routed to IRQ 11
Region 0: Memory at fff70000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: b9 10 37 52 17 00 90 02 03 10 03 0c 08 10 00 00
10: 00 00 f7 ff 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 60 00 00 00 00 00 00 00 09 01 00 50
40: 00 00 1f 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 01 00 02 06 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00:04.0 CardBus bridge: Texas Instruments PCI1420
Subsystem: Hewlett-Packard Company: Unknown device 0018
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: 168, cache line size 04
Interrupt: pin A routed to IRQ 11
Region 0: Memory at 10000000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=00, secondary=02, subordinate=05, sec-latency=176
Memory window 0: 10400000-107ff000 (prefetchable)
Memory window 1: 10800000-10bff000
I/O window 0: 00004000-000040ff
I/O window 1: 00004400-000044ff
BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+ PostWrite+
16-bit legacy interface ports at 0001
00: 4c 10 51 ac 07 00 10 02 00 00 07 06 04 a8 82 00
10: 00 00 00 10 a0 00 00 02 00 02 05 b0 00 00 40 10
20: 00 f0 7f 10 00 00 80 10 00 f0 bf 10 00 40 00 00
30: fc 40 00 00 00 44 00 00 fc 44 00 00 0b 01 c0 05
40: 3c 10 18 00 01 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 60 b0 44 20 00 00 00 00 00 00 00 00 22 1b 9c 00
90: c0 82 66 60 00 00 00 00 00 00 00 00 00 00 00 00
a0: 01 00 11 fe 00 00 c0 00 00 08 00 00 1f 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00:04.1 CardBus bridge: Texas Instruments PCI1420
Subsystem: Hewlett-Packard Company: Unknown device 0018
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: 168, cache line size 04
Interrupt: pin A routed to IRQ 11
Region 0: Memory at 10001000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=00, secondary=06, subordinate=09, sec-latency=176
Memory window 0: 10c00000-10fff000 (prefetchable)
Memory window 1: 11000000-113ff000
I/O window 0: 00004800-000048ff
I/O window 1: 00004c00-00004cff
BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt+ PostWrite+
16-bit legacy interface ports at 0001
00: 4c 10 51 ac 07 00 10 02 00 00 07 06 04 a8 82 00
10: 00 10 00 10 a0 00 00 02 00 06 09 b0 00 00 c0 10
20: 00 f0 ff 10 00 00 00 11 00 f0 3f 11 00 48 00 00
30: fc 48 00 00 00 4c 00 00 fc 4c 00 00 0b 01 c0 05
40: 3c 10 18 00 01 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 60 b0 44 20 00 00 00 00 00 00 00 00 22 1b 9c 00
90: c0 83 66 60 00 00 00 00 00 00 00 00 00 00 00 00
a0: 01 00 11 fe 00 00 c0 00 00 08 00 00 1f 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00:06.0 Bridge: Acer Laboratories Inc. [ALi] M7101 PMU
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-
00: b9 10 01 71 00 00 00 02 00 00 80 06 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 01 40 00 00 04 00 22 00 2a 7b 00 31 00 05 00 00
50: 00 02 00 00 00 00 00 00 00 4f 01 40 00 00 00 00
60: 00 00 00 00 a5 00 00 00 00 00 00 ff 01 22 e0 0f
70: 01 81 00 00 00 2f 45 28 f7 77 00 00 f8 02 00 00
80: f6 63 0a 10 02 07 00 00 f7 00 00 20 00 00 00 00
90: 00 00 00 00 00 00 00 b2 47 00 b0 9c b0 04 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 fe 00 00
b0: 00 84 00 00 04 0a 03 00 60 14 00 00 00 00 00 00
c0: 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 06 04 00 00 00 00 00 00 00 40 00 00 00 00 00
e0: 00 80 40 80 01 00 01 06 00 00 00 00 00 00 00 00
f0: 03 00 20 1e 00 00 00 00 00 00 00 00 00 00 00 00
00:07.0 ISA bridge: Acer Laboratories Inc. [ALi] M1533 PCI to ISA Bridge [Aladdin IV]
Subsystem: Acer Laboratories Inc. [ALi] ALI M1533 Aladdin IV ISA Bridge
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: 0
Capabilities: [a0] Power Management version 1
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: b9 10 33 15 0f 00 10 02 00 00 01 06 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 b9 10 33 15
30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00
40: 01 13 08 ea 5d 02 00 03 99 00 00 00 00 00 cd 03
50: 00 00 00 00 02 00 02 01 5c 00 00 00 00 00 e0 f0
60: 42 31 00 00 00 00 00 00 00 00 00 00 05 64 25 00
70: d2 00 2b 00 09 1f 81 48 00 00 80 02 21 00 00 11
80: 07 00 33 01 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 01 00 01 06 00 00 00 00 00 00 00 00 00 00 00 00
b0: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00:08.0 Multimedia audio controller: ESS Technology ES1988 Allegro-1 (rev 12)
Subsystem: Hewlett-Packard Company: Unknown device 0018
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: 64 (500ns min, 6000ns max)
Interrupt: pin A routed to IRQ 5
Region 0: I/O ports at 1400 [size=256]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 5d 12 88 19 05 00 90 02 12 00 01 04 00 40 80 00
10: 01 14 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 18 00
30: 00 00 00 00 c0 00 00 00 00 00 00 00 ff 01 02 18
40: 7f 90 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 40 00 40 0a 00 00 00 00 00 01 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 18 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 01 00 22 76 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00:08.1 Communication controller: ESS Technology ESS Modem (rev 12)
Subsystem: Hewlett-Packard Company: Unknown device 0018
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-
Interrupt: pin A routed to IRQ 5
Region 0: I/O ports at 1800 [disabled] [size=256]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=100mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME+
00: 5d 12 89 19 00 00 90 02 12 00 80 07 00 00 80 00
10: 01 18 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 18 00
30: 00 00 00 00 c0 00 00 00 00 00 00 00 ff 01 00 00
40: 7f 90 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 40 00 40 0a 00 00 00 00 00 01 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 18 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 01 00 a2 f6 00 80 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00:0f.0 IDE interface: Acer Laboratories Inc. [ALi] M5229 IDE (rev c3) (prog-if 8a [Master SecP PriP])
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: 64 (500ns min, 1000ns max)
Interrupt: pin A routed to IRQ 0
Region 4: I/O ports at 1000 [size=16]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: b9 10 29 52 05 00 90 02 c3 8a 01 01 00 40 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 60 00 00 00 00 00 00 00 ff 01 02 04
40: 06 00 00 7a 00 00 00 00 00 02 20 c1 00 00 ba 3a
50: 00 00 00 89 0a 00 08 00 00 31 31 00 00 31 31 00
60: 01 00 02 06 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 21 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00:10.0 Ethernet controller: Accton Technology Corporation EN-1216 Ethernet Adapter (rev 11)
Subsystem: Accton Technology Corporation: Unknown device 2242
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: 64 (63750ns min, 63750ns max), cache line size 08
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at 1c00 [size=256]
Region 1: Memory at ea001000 (32-bit, non-prefetchable) [size=1K]
Expansion ROM at <unassigned> [disabled] [size=128K]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 13 11 16 12 17 00 90 02 11 00 00 02 08 40 00 00
10: 01 1c 00 00 00 10 00 ea 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 13 11 42 22
30: 00 00 00 00 c0 00 00 00 00 00 00 00 0b 01 ff ff
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 17 13 81 09 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 01 00 c2 ff 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01:00.0 VGA compatible controller: Trident Microsystems CyberBlade/XP (rev 63) (prog-if 00 [VGA])
Subsystem: Hewlett-Packard Company: Unknown device 0018
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: 64
Interrupt: pin A routed to IRQ 11
Region 0: Memory at ee000000 (32-bit, non-prefetchable) [size=32M]
Region 1: Memory at ea400000 (32-bit, non-prefetchable) [size=4M]
Region 2: Memory at ec000000 (32-bit, non-prefetchable) [size=32M]
Region 3: Memory at ea100000 (32-bit, non-prefetchable) [size=32K]
Expansion ROM at <unassigned> [disabled] [size=64K]
Capabilities: [80] AGP version 2.0
Status: RQ=32 SBA+ 64bit- FW- Rate=x1,x2
Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
Capabilities: [90] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 23 10 10 99 07 00 30 02 63 00 00 03 00 40 00 00
10: 00 00 00 ee 00 00 40 ea 00 00 00 ec 00 00 10 ea
20: 00 00 00 00 00 00 00 00 00 00 00 00 3c 10 18 00
30: 00 00 00 00 80 00 00 00 00 00 00 00 0b 01 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 02 90 20 00 07 02 00 20 00 00 00 00 00 00 00 00
90: 01 00 22 06 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Does that help?
Pavel
--
"I do not steal MS software. It is not worth it."
-- Pavel Kankovsky
On Wed, 19 Dec 2001, Pavel Machek wrote:
> dump_pirq is:
>
> Interrupt routing table found at address 0xfdf40:
> Version 1.0, size 0x00a0
> Interrupt router is device 00:07.0
> PCI exclusive interrupt mask: 0x0000
> Compatible router: vendor 0x10b9 device 0x1533
>
> Device 00:0f.0 (slot 0):
>
> Device 00:02.0 (slot 0):
> INTA: link 0x59, irq mask 0x0800
Hmmh, this doesn't fit the in-kernel ali IRQ routing code at all. Can you
mail me your ACPI DSDT, this may help to figure out how the IRQ routing
really works.
> Interrupt router at 00:07.0: AcerLabs Aladdin M1533 PCI-to-ISA bridge
> INT1 (link 1): irq 11
> INT2 (link 2): irq 11
> INT3 (link 3): unrouted
> INT4 (link 4): unrouted
> INT5 (link 5): unrouted
> INT6 (link 6): unrouted
> INT7 (link 7): unrouted
> INT8 (link 8): unrouted
> Serial IRQ: [enabled] [continuous] [frame=21] [pulse=12]
Cruel hack to route every link to irq 11 (may of course lock up your box)
setpci -s 7.0 49.b=99
setpci -s 7.0 4a.b=99
setpci -s 7.0 4b.b=99
(assumes you still hardwire the IRQ for the maestro to 11)
Does this help - do you actually get sound interrupts then? If so, you
could try to figure out which exact link it is connected to by just having
one of the above nibbles set to 9, leave the others at 0.
The Ali IRQ routing code definitely needs fixing, it'll write totally
wrong config space addresses with your $PIRQ table, it's just not clear
(to me) how to fix it correctly. The DSDT may help, documentation on the
chipset too, of course.
--Kai
Hi!
> Cruel hack to route every link to irq 11 (may of course lock up your box)
>
> setpci -s 7.0 49.b=99
Huh, this did the trick! Interrupts now arrive correctly to the
soundcard. Recording is still broken, but that's probably separate
problem. (I did not even need those two other setpci's ;-)
Pavel
--
"I do not steal MS software. It is not worth it."
-- Pavel Kankovsky
On Thu, 20 Dec 2001, Pavel Machek wrote:
> > Cruel hack to route every link to irq 11 (may of course lock up your box)
> >
> > setpci -s 7.0 49.b=99
>
> Huh, this did the trick! Interrupts now arrive correctly to the
> soundcard. Recording is still broken, but that's probably separate
> problem. (I did not even need those two other setpci's ;-)
setpci -s 7.0 49.b=09 should do the trick as well, right?
Well, let me extend your dump_pirq with info from your ACPI DSDT (lines
starting with ==):
Device 00:0f.0 (slot 0):
Device 00:02.0 (slot 0):
INTA: link 0x59, irq mask 0x0800
== LNKU
Device 00:08.0 (slot 1):
INTA: link 0x49, irq mask 0x0020
== LNKC
Device 00:04.0 (slot 0):
INTA: link 0x48, irq mask 0x0800
== LNKA
INTB: link 0x48, irq mask 0x0800
== LNKB
Device 00:10.0 (slot 0):
INTA: link 0x48, irq mask 0x0800
== LNKB
Device 00:07.0 (slot 0):
INTA: link 0x48, irq mask 0xdef8
INTB: link 0x48, irq mask 0xdef8
INTC: link 0x49, irq mask 0xdef8
INTD: link 0x49, irq mask 0xdef8
== no ACPI info here
Device 00:01.0 (slot 0):
INTA: link 0x48, irq mask 0x0800
== no ACPI info here
Device 01:00.0 (slot 0):
INTA: link 0x48, irq mask 0x0800
== LNKA
Interrupt router at 00:07.0: AcerLabs Aladdin M1533 PCI-to-ISA bridge
INT1 (link 1): irq 11
INT2 (link 2): irq 11
INT3 (link 3): unrouted
INT4 (link 4): unrouted
INT5 (link 5): unrouted
INT6 (link 6): unrouted
INT7 (link 7): unrouted
INT8 (link 8): unrouted
Serial IRQ: [enabled] [continuous] [frame=21] [pulse=12]
== LNKA IPRS (0x48) 0x0298 [3,4,7,9]
== LNKB IPRS (0x48) 0x0298 [3,4,7,9]
== LNKC IPRC (0x49) 0x0280 [7,9]
== LNKD IPRS (0x49) 0x0298 [3,4,7,9]
== LNKU IPRU (0x74) 0x0020 [5]
Your PIRQ table is hopelessly broken. The kernel code expects the "link
0x.." field to contain numbers between 0 to 7, corresponding to INT1 to
INT8. Your link field seems to contain the config space offset instead,
but that's fundamentally broken, since one config space byte determines
the routing for two links, thus it's not possible to figure out which one
is meant.
Also, USB uses a special link which won't work with the current kernel
code at all. The possible IRQ masks are quite different between the PIRQ
table and the ACPI table. (And your BIOS seems to have set the USB
controller to IRQ 11, (USB->LNKU->IRQ11), which isn't even allowed
according to the IRQ mask).
So, there's basically no chance to get the IRQ routing code working
correctly with your PIRQ table. However, using the ACPI provided info
should work fine as far as I can see. Did you try the latest ACPI snapshot
+ my ACPI IRQ routing patch? It'd be interesting to see what that gives.
(it may even work ;-)
--Kai