Re: 3c59x: Using bad IRQ 0
Linus Torvalds wrote: > > On Tue, 21 Nov 2000, Jeff Garzik wrote: > > > > A caveat to this whole scheme is that usb-uhci -already- calls > > pci_enable_device before checking dev->irq, and yet cannot get around > > the "assign IRQ to USB: no" setting in BIOS. I hope that is an > > exception rather than the rule. > > Do we have a recent report of this with full PCI debug output? It might > just be another unlisted intel irq router.. Actually, I -was- able to reproduce this problem on my SMP PIIX4 box here. But as of test11-final, I am no longer able to reproduce it. Maybe some intrepid testers are willing to test 2.4.0-test11 with these BIOS settings: PNP OS: Yes Assign IRQ to USB: No It works for me... :) Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 3c59x: Using bad IRQ 0
On Tue, Nov 21, 2000 at 05:26:06PM -0800, Linus Torvalds wrote: > On Tue, 21 Nov 2000, Jeff Garzik wrote: > > > > A caveat to this whole scheme is that usb-uhci -already- calls > > pci_enable_device before checking dev->irq, and yet cannot get around > > the "assign IRQ to USB: no" setting in BIOS. I hope that is an > > exception rather than the rule. > > Do we have a recent report of this with full PCI debug output? It might > just be another unlisted intel irq router.. I don't know if this is what you're looking for, but I have indeed problems getting USB to work on my new notebook. Some info: Asus P8300, 500MHz Celeron, 128MB, Intel 440MX chipset. Here is the output from "lspci -vvx": 00:00.0 Host bridge: Intel Corporation 82440MX I/O Controller (rev 01) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- 00: 6f 12 20 07 1f 00 30 02 a2 00 00 03 00 40 00 00 10: 00 00 00 f8 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 43 10 32 13 30: 00 00 00 00 40 00 00 00 00 00 00 00 0b 01 00 00 00:07.0 ISA bridge: Intel Corporation 82440MX PCI to ISA Bridge (rev 01) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- 00: c1 11 48 04 03 00 90 02 01 00 80 07 00 00 00 00 10: 00 fc df fe 89 fc 00 00 01 f4 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 40 00 00 00 68 16 00 24 30: 00 00 00 00 f8 00 00 00 00 00 00 00 0b 01 fc 0e 00:0a.0 CardBus bridge: Ricoh Co Ltd RL5c475 (rev 80) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset- 16bInt+ PostWrite+ 16-bit legacy interface ports at 0001 00: 80 11 75 04 07 00 10 02 80 00 07 06 00 a8 02 00 10: 00 00 00 10 dc 00 00 02 00 01 01 b0 00 00 40 10 20: 00 f0 7f 10 00 00 80 10 00 f0 bf 10 00 10 00 00 30: fc 10 00 00 00 14 00 00 fc 14 00 00 ff 01 80 05 40: 00 00 00 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 I enabled DEBUG in arch/i386/kernel/pci-i386.h, and got the following output at boot: Linux version 2.4.0-test11 (root@arthur) (gcc version 2.95.2 19991024 (release)) #2 Fri Nov 24 10:28:22 CET 2000 BIOS-provided physical RAM map: BIOS-e820: 0009f400 @ (usable) BIOS-e820: 0c00 @ 0009f400 (reserved) BIOS-e820: 00017000 @ 000e9000 (reserved) BIOS-e820: 07ef @ 0010 (usable) BIOS-e820: fc00 @ 07ff (ACPI data) BIOS-e820: 0400 @ 07fffc00 (ACPI NVS) BIOS-e820: 00017000 @ fffe9000 (reserved) Scan SMP from c000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f for 65536 bytes. Scan SMP from c009f400 for 4096 bytes. On node 0 totalpages: 32752 zone(0): 4096 pages. zone(1): 28656 pages. zone(2): 0 pages. mapped APIC to e000 (01222000) Kernel command line: BOOT_IMAGE=linux-2.4.0t11 ro root=301 Initializing CPU#0 Detected 501.146 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 999.42 BogoMIPS Memory: 127064k/131008k available (923k kernel code, 3556k reserved, 61k data, 184k init, 0k highmem) Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) Page-cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) CPU: Before vendor init, caps: 0383f9ff , vendor = 0 CPU: L2 cache: 128K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: After vendor init, caps: 0383f9ff CPU: After generic, caps: 0383f9ff CPU: Common caps: 0383f9ff CPU: Intel Celeron (Coppermine) stepping 01 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: Intel PCI: BIOS32 Service Directory structure at 0xc00f6bf0 PCI: BIOS32 Service Directory entry at 0xfd762 PCI: BIOS probe returned s=00 hw=01 ver=02.10 l=01 PCI: PCI BIOS revision 2.10 entry at 0xfd987, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: IDE base address fixup for 00:07.1 PCI: Scanning for ghost devices on bus 0 PCI: IRQ init PCI: Interrupt Routing Table found at 0xc00fdf50 00:07 slot=00 0:00/def8
Re: 3c59x: Using bad IRQ 0
On Tue, Nov 21, 2000 at 05:26:06PM -0800, Linus Torvalds wrote: On Tue, 21 Nov 2000, Jeff Garzik wrote: A caveat to this whole scheme is that usb-uhci -already- calls pci_enable_device before checking dev-irq, and yet cannot get around the "assign IRQ to USB: no" setting in BIOS. I hope that is an exception rather than the rule. Do we have a recent report of this with full PCI debug output? It might just be another unlisted intel irq router.. I don't know if this is what you're looking for, but I have indeed problems getting USB to work on my new notebook. Some info: Asus P8300, 500MHz Celeron, 128MB, Intel 440MX chipset. Here is the output from "lspci -vvx": 00:00.0 Host bridge: Intel Corporation 82440MX I/O Controller (rev 01) 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 00: 86 80 94 71 06 00 00 22 01 00 00 06 00 40 80 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 00:00.1 Multimedia audio controller: Intel Corporation 82440MX AC'97 Audio Controller Subsystem: Asustek Computer, Inc.: Unknown device 1063 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- Latency: 0 Interrupt: pin B routed to IRQ 5 Region 0: I/O ports at f800 [size=256] Region 1: I/O ports at fc00 [size=64] 00: 86 80 95 71 05 00 00 00 00 00 01 04 00 00 00 00 10: 01 f8 00 00 01 fc 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 63 10 30: 00 00 00 00 00 00 00 00 00 00 00 00 05 02 00 00 00:02.0 VGA compatible controller: Silicon Motion, Inc. SM720 Lynx3DM (rev a2) (prog-if 00 [VGA]) Subsystem: Asustek Computer, Inc.: Unknown device 1332 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 f800 (32-bit, non-prefetchable) [size=64M] Capabilities: available only to root 00: 6f 12 20 07 1f 00 30 02 a2 00 00 03 00 40 00 00 10: 00 00 00 f8 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 43 10 32 13 30: 00 00 00 00 40 00 00 00 00 00 00 00 0b 01 00 00 00:07.0 ISA bridge: Intel Corporation 82440MX PCI to ISA Bridge (rev 01) 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 00: 86 80 98 71 0f 00 80 02 01 00 01 06 00 00 80 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 00:07.1 IDE interface: Intel Corporation 82440MX EIDE Controller (prog-if 80 [Master]) 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 Region 4: I/O ports at fc90 [size=16] 00: 86 80 99 71 05 00 80 02 00 80 01 01 00 40 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 91 fc 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 00:07.2 USB Controller: Intel Corporation 82440MX USB Universal Host Controller (prog-if 00 [UHCI]) 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 D routed to IRQ 11 Region 4: I/O ports at fca0 [size=32] 00: 86 80 9a 71 01 00 80 02 00 00 03 0c 00 40 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: a1 fc 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 0b 04 00 00 00:07.3 Bridge: Intel Corporation 82440MX 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: 86 80 9b 71 0b 00 80 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 00:09.0 Communication controller: Lucent Microelectronics WinModem 56k (rev 01) Subsystem: Action Tec Electronics Inc: Unknown device 2400 Control: I/O+ Mem+ BusMaster-
Re: 3c59x: Using bad IRQ 0
Linus Torvalds wrote: On Tue, 21 Nov 2000, Jeff Garzik wrote: A caveat to this whole scheme is that usb-uhci -already- calls pci_enable_device before checking dev-irq, and yet cannot get around the "assign IRQ to USB: no" setting in BIOS. I hope that is an exception rather than the rule. Do we have a recent report of this with full PCI debug output? It might just be another unlisted intel irq router.. Actually, I -was- able to reproduce this problem on my SMP PIIX4 box here. But as of test11-final, I am no longer able to reproduce it. Maybe some intrepid testers are willing to test 2.4.0-test11 with these BIOS settings: PNP OS: Yes Assign IRQ to USB: No It works for me... :) Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 3c59x: Using bad IRQ 0
Linus Torvalds wrote: > > On Thu, 23 Nov 2000, Tobias Ringstrom wrote: > > > > > > - enable DEBUG in arch/i386/kernel/pci-i386.h. This should make the code > > >print out what the pirq table entries are etc. > > > > Done. When adding the call to eisa_set_level_irq, the line > > > > IRQ for 00:0a.0(0) via 00:0a.0 -> PIRQ 03, mask 1eb8, excl -> newirq=9 -> >assigning IRQ 9 ... OK > > > > was changed into > > > > IRQ for 00:0a.0(0) via 00:0a.0 -> PIRQ 03, mask 1eb8, excl -> newirq=9 -> >assigning IRQ 9 -> edge ... OK > > Ok. > > The thing was marked as edge-triggered, which is basically always wrong > for a PCI interrupt. The above printout just means that it now noticed > that it was edge, and fixed it up in the ELCR. FWIW Via's PCI to ISA bridge has a PIRQ edge/level register. Vendor=1106h, Device=686h, PCI config offset 54h, RW Bits 7-4 reserved, zero. Bit 3: PIRQA# edge (clear bit for level) Bit 2: PIRQB# edge (clear bit for level) Bit 1: PIRQC# edge (clear bit for level) Bit 0: PIRQD# edge (clear bit for level) The bits are all supposed to default to zero (level). > > > - add the line "eisa_set_level_irq(irq);" to pirq_via_set() just before > > >the "return 1;" > > > > You certainly know your kernel very well... :-) > > That's why they pay me the big bucks. Good. > > I'll make it do the eisa_set_level_irq() in the generic code: it should > always be right (we don't do it now in the PIIX4 case, for example, but > the PIIX documentation actually says that we _should_), and there is no > need to do it separately for each interrupt router. So calling eisa_set_level_irq() means nothing will scream if we do not update [for example] the above register? Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 3c59x: Using bad IRQ 0
On Thu, 23 Nov 2000, Tobias Ringstrom wrote: > > > > - enable DEBUG in arch/i386/kernel/pci-i386.h. This should make the code > >print out what the pirq table entries are etc. > > Done. When adding the call to eisa_set_level_irq, the line > > IRQ for 00:0a.0(0) via 00:0a.0 -> PIRQ 03, mask 1eb8, excl -> newirq=9 -> >assigning IRQ 9 ... OK > > was changed into > > IRQ for 00:0a.0(0) via 00:0a.0 -> PIRQ 03, mask 1eb8, excl -> newirq=9 -> >assigning IRQ 9 -> edge ... OK Ok. The thing was marked as edge-triggered, which is basically always wrong for a PCI interrupt. The above printout just means that it now noticed that it was edge, and fixed it up in the ELCR. > > - add the line "eisa_set_level_irq(irq);" to pirq_via_set() just before > >the "return 1;" > > You certainly know your kernel very well... :-) That's why they pay me the big bucks. Good. I'll make it do the eisa_set_level_irq() in the generic code: it should always be right (we don't do it now in the PIIX4 case, for example, but the PIIX documentation actually says that we _should_), and there is no need to do it separately for each interrupt router. One down. Now just tell me if the problem with the machine that needs warm-booting from Windows is fixed by the other PCI change, and I'll be a happy camper. (Or rather, I'd be a happy camper if I knew what the cause of the disk corruption reports is. That one bugs me). Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 3c59x: Using bad IRQ 0
On Thu, 23 Nov 2000, Linus Torvalds wrote: > > > Tobias, can you confirm that calling pci_enable_device before reading > > > dev->irq fixes the 3c59x.c problem for you? > > > > Nope. The interrupts do not seem to get through. Packets are transmitted, > > but that's it. I've copied the interesting parts from dmesg: > > > > 3c59x.c:LK1.1.11 13 Nov 2000 Donald Becker and others. >http://www.scyld.com/network/vortex.html $Revision: 1.102.2.46 $ > > See Documentation/networking/vortex.txt > > PCI: Enabling device 00:0a.0 (0014 -> 0017) > > PCI: Assigned IRQ 9 for device 00:0a.0 > > eth0: 3Com PCI 3c905C Tornado at 0xa400, 00:01:02:b4:18:e4, IRQ 9 > > Ok, the VIA stuff is happy, and enables the irq routing. The fact that the > irq's don't actually seem to ever actually appear means that the enable > sequence is probably slightly buggy. > > Can you do two things? > > - enable DEBUG in arch/i386/kernel/pci-i386.h. This should make the code >print out what the pirq table entries are etc. Done. When adding the call to eisa_set_level_irq, the line IRQ for 00:0a.0(0) via 00:0a.0 -> PIRQ 03, mask 1eb8, excl -> newirq=9 -> assigning IRQ 9 ... OK was changed into IRQ for 00:0a.0(0) via 00:0a.0 -> PIRQ 03, mask 1eb8, excl -> newirq=9 -> assigning IRQ 9 -> edge ... OK > - add the line "eisa_set_level_irq(irq);" to pirq_via_set() just before >the "return 1;" You certainly know your kernel very well... :-) That did the trick, and the 3Com card works just fine. Now the only question is why this happened, but I leave that in you capable hands. /Tobias Linux version 2.4.0-test11 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #29 Thu Nov 23 18:58:29 CET 2000 BIOS-provided physical RAM map: BIOS-e820: 0009e800 @ (usable) BIOS-e820: 1800 @ 0009e800 (reserved) BIOS-e820: 0001 @ 000f (reserved) BIOS-e820: 0feec000 @ 0010 (usable) BIOS-e820: 3000 @ 0ffec000 (ACPI data) BIOS-e820: 0001 @ 0ffef000 (reserved) BIOS-e820: 1000 @ 0000 (ACPI NVS) BIOS-e820: 0001 @ (reserved) On node 0 totalpages: 65516 zone(0): 4096 pages. zone(1): 61420 pages. zone(2): 0 pages. Kernel command line: BOOT_IMAGE=linux ro root=303 BOOT_FILE=/boot/vmlinuz ide=reverse 1 ide_setup: ide=reverse : Enabled support for IDE inverse scan order. Initializing CPU#0 Detected 1009.006 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 2011.96 BogoMIPS Memory: 255116k/262064k available (1624k kernel code, 6556k reserved, 101k data, 220k init, 0k highmem) Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) CPU: Before vendor init, caps: 0183f9ff c1c7f9ff , vendor = 2 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) CPU: After vendor init, caps: 0183f9ff c1c7f9ff CPU: After generic, caps: 0183f9ff c1c7f9ff CPU: Common caps: 0183f9ff c1c7f9ff CPU: AMD Athlon(tm) Processor stepping 02 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: Intel PCI: BIOS32 Service Directory structure at 0xc00f92a0 PCI: BIOS32 Service Directory entry at 0xf0ef0 PCI: BIOS probe returned s=00 hw=11 ver=02.10 l=01 PCI: PCI BIOS revision 2.10 entry at 0xf10f0, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: IDE base address fixup for 00:04.1 PCI: Scanning for ghost devices on bus 0 PCI: Scanning for ghost devices on bus 1 Unknown bridge resource 0: assuming transparent PCI: IRQ init PCI: Interrupt Routing Table found at 0xc00f16c0 00:0c slot=01 0:01/1eb8 1:02/1eb8 2:03/1eb8 3:05/1eb8 00:0b slot=02 0:02/1eb8 1:03/1eb8 2:05/1eb8 3:01/1eb8 00:0a slot=03 0:03/1eb8 1:05/1eb8 2:01/1eb8 3:02/1eb8 00:09 slot=04 0:05/1eb8 1:01/1eb8 2:02/1eb8 3:03/1eb8 00:0d slot=05 0:05/1eb8 1:01/1eb8 2:02/1eb8 3:03/1eb8 00:04 slot=00 0:01/1eb8 1:02/1eb8 2:03/1eb8 3:05/1eb8 00:01 slot=00 0:01/1eb8 1:02/1eb8 2:03/1eb8 3:05/1eb8 00:11 slot=00 0:02/1eb8 1:03/1eb8 2:05/1eb8 3:01/1eb8 00:12 slot=00 0:01/1eb8 1:02/1eb8 2:03/1eb8 3:05/1eb8 PCI: Using IRQ router VIA [1106/0686] at 00:04.0 PCI: IRQ fixup 00:0a.0: ignoring bogus IRQ 255 00:0b.0: ignoring bogus IRQ 255 IRQ for 00:0a.0(0) via 00:0a.0 -> PIRQ 03, mask 1eb8, excl ... failed IRQ for 00:0b.0(0) via 00:0b.0 -> PIRQ 02, mask 1eb8, excl -> got IRQ 10 PCI: Found IRQ 10 for device 00:0b.0 PCI: The same IRQ used for device 00:11.0 PCI: Allocating resources PCI: Resource e000-e7ff (f=1208, d=0, p=0) PCI: Resource d800-d80f (f=101, d=0, p=0)
Re: 3c59x: Using bad IRQ 0
On Tue, 21 Nov 2000, Tobias Ringstrom wrote: > > > > Tobias, can you confirm that calling pci_enable_device before reading > > dev->irq fixes the 3c59x.c problem for you? > > Nope. The interrupts do not seem to get through. Packets are transmitted, > but that's it. I've copied the interesting parts from dmesg: > > 3c59x.c:LK1.1.11 13 Nov 2000 Donald Becker and others. >http://www.scyld.com/network/vortex.html $Revision: 1.102.2.46 $ > See Documentation/networking/vortex.txt > PCI: Enabling device 00:0a.0 (0014 -> 0017) > PCI: Assigned IRQ 9 for device 00:0a.0 > eth0: 3Com PCI 3c905C Tornado at 0xa400, 00:01:02:b4:18:e4, IRQ 9 Ok, the VIA stuff is happy, and enables the irq routing. The fact that the irq's don't actually seem to ever actually appear means that the enable sequence is probably slightly buggy. Can you do two things? - enable DEBUG in arch/i386/kernel/pci-i386.h. This should make the code print out what the pirq table entries are etc. - add the line "eisa_set_level_irq(irq);" to pirq_via_set() just before the "return 1;" Jeff, you had complete VIA docs, right? Can you check that whatever Tobias' ends up having output from the debug stuff looks sane? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 3c59x: Using bad IRQ 0
On Tue, 21 Nov 2000, Tobias Ringstrom wrote: Tobias, can you confirm that calling pci_enable_device before reading dev-irq fixes the 3c59x.c problem for you? Nope. The interrupts do not seem to get through. Packets are transmitted, but that's it. I've copied the interesting parts from dmesg: 3c59x.c:LK1.1.11 13 Nov 2000 Donald Becker and others. http://www.scyld.com/network/vortex.html $Revision: 1.102.2.46 $ See Documentation/networking/vortex.txt PCI: Enabling device 00:0a.0 (0014 - 0017) PCI: Assigned IRQ 9 for device 00:0a.0 eth0: 3Com PCI 3c905C Tornado at 0xa400, 00:01:02:b4:18:e4, IRQ 9 Ok, the VIA stuff is happy, and enables the irq routing. The fact that the irq's don't actually seem to ever actually appear means that the enable sequence is probably slightly buggy. Can you do two things? - enable DEBUG in arch/i386/kernel/pci-i386.h. This should make the code print out what the pirq table entries are etc. - add the line "eisa_set_level_irq(irq);" to pirq_via_set() just before the "return 1;" Jeff, you had complete VIA docs, right? Can you check that whatever Tobias' ends up having output from the debug stuff looks sane? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 3c59x: Using bad IRQ 0
On Thu, 23 Nov 2000, Linus Torvalds wrote: Tobias, can you confirm that calling pci_enable_device before reading dev-irq fixes the 3c59x.c problem for you? Nope. The interrupts do not seem to get through. Packets are transmitted, but that's it. I've copied the interesting parts from dmesg: 3c59x.c:LK1.1.11 13 Nov 2000 Donald Becker and others. http://www.scyld.com/network/vortex.html $Revision: 1.102.2.46 $ See Documentation/networking/vortex.txt PCI: Enabling device 00:0a.0 (0014 - 0017) PCI: Assigned IRQ 9 for device 00:0a.0 eth0: 3Com PCI 3c905C Tornado at 0xa400, 00:01:02:b4:18:e4, IRQ 9 Ok, the VIA stuff is happy, and enables the irq routing. The fact that the irq's don't actually seem to ever actually appear means that the enable sequence is probably slightly buggy. Can you do two things? - enable DEBUG in arch/i386/kernel/pci-i386.h. This should make the code print out what the pirq table entries are etc. Done. When adding the call to eisa_set_level_irq, the line IRQ for 00:0a.0(0) via 00:0a.0 - PIRQ 03, mask 1eb8, excl - newirq=9 - assigning IRQ 9 ... OK was changed into IRQ for 00:0a.0(0) via 00:0a.0 - PIRQ 03, mask 1eb8, excl - newirq=9 - assigning IRQ 9 - edge ... OK - add the line "eisa_set_level_irq(irq);" to pirq_via_set() just before the "return 1;" You certainly know your kernel very well... :-) That did the trick, and the 3Com card works just fine. Now the only question is why this happened, but I leave that in you capable hands. /Tobias Linux version 2.4.0-test11 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #29 Thu Nov 23 18:58:29 CET 2000 BIOS-provided physical RAM map: BIOS-e820: 0009e800 @ (usable) BIOS-e820: 1800 @ 0009e800 (reserved) BIOS-e820: 0001 @ 000f (reserved) BIOS-e820: 0feec000 @ 0010 (usable) BIOS-e820: 3000 @ 0ffec000 (ACPI data) BIOS-e820: 0001 @ 0ffef000 (reserved) BIOS-e820: 1000 @ 0000 (ACPI NVS) BIOS-e820: 0001 @ (reserved) On node 0 totalpages: 65516 zone(0): 4096 pages. zone(1): 61420 pages. zone(2): 0 pages. Kernel command line: BOOT_IMAGE=linux ro root=303 BOOT_FILE=/boot/vmlinuz ide=reverse 1 ide_setup: ide=reverse : Enabled support for IDE inverse scan order. Initializing CPU#0 Detected 1009.006 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 2011.96 BogoMIPS Memory: 255116k/262064k available (1624k kernel code, 6556k reserved, 101k data, 220k init, 0k highmem) Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) CPU: Before vendor init, caps: 0183f9ff c1c7f9ff , vendor = 2 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) CPU: After vendor init, caps: 0183f9ff c1c7f9ff CPU: After generic, caps: 0183f9ff c1c7f9ff CPU: Common caps: 0183f9ff c1c7f9ff CPU: AMD Athlon(tm) Processor stepping 02 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: Intel PCI: BIOS32 Service Directory structure at 0xc00f92a0 PCI: BIOS32 Service Directory entry at 0xf0ef0 PCI: BIOS probe returned s=00 hw=11 ver=02.10 l=01 PCI: PCI BIOS revision 2.10 entry at 0xf10f0, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: IDE base address fixup for 00:04.1 PCI: Scanning for ghost devices on bus 0 PCI: Scanning for ghost devices on bus 1 Unknown bridge resource 0: assuming transparent PCI: IRQ init PCI: Interrupt Routing Table found at 0xc00f16c0 00:0c slot=01 0:01/1eb8 1:02/1eb8 2:03/1eb8 3:05/1eb8 00:0b slot=02 0:02/1eb8 1:03/1eb8 2:05/1eb8 3:01/1eb8 00:0a slot=03 0:03/1eb8 1:05/1eb8 2:01/1eb8 3:02/1eb8 00:09 slot=04 0:05/1eb8 1:01/1eb8 2:02/1eb8 3:03/1eb8 00:0d slot=05 0:05/1eb8 1:01/1eb8 2:02/1eb8 3:03/1eb8 00:04 slot=00 0:01/1eb8 1:02/1eb8 2:03/1eb8 3:05/1eb8 00:01 slot=00 0:01/1eb8 1:02/1eb8 2:03/1eb8 3:05/1eb8 00:11 slot=00 0:02/1eb8 1:03/1eb8 2:05/1eb8 3:01/1eb8 00:12 slot=00 0:01/1eb8 1:02/1eb8 2:03/1eb8 3:05/1eb8 PCI: Using IRQ router VIA [1106/0686] at 00:04.0 PCI: IRQ fixup 00:0a.0: ignoring bogus IRQ 255 00:0b.0: ignoring bogus IRQ 255 IRQ for 00:0a.0(0) via 00:0a.0 - PIRQ 03, mask 1eb8, excl ... failed IRQ for 00:0b.0(0) via 00:0b.0 - PIRQ 02, mask 1eb8, excl - got IRQ 10 PCI: Found IRQ 10 for device 00:0b.0 PCI: The same IRQ used for device 00:11.0 PCI: Allocating resources PCI: Resource e000-e7ff (f=1208, d=0, p=0) PCI: Resource d800-d80f (f=101, d=0, p=0) PCI: Resource d400-d41f (f=101, d=0, p=0)
Re: 3c59x: Using bad IRQ 0
Linus Torvalds wrote: On Thu, 23 Nov 2000, Tobias Ringstrom wrote: - enable DEBUG in arch/i386/kernel/pci-i386.h. This should make the code print out what the pirq table entries are etc. Done. When adding the call to eisa_set_level_irq, the line IRQ for 00:0a.0(0) via 00:0a.0 - PIRQ 03, mask 1eb8, excl - newirq=9 - assigning IRQ 9 ... OK was changed into IRQ for 00:0a.0(0) via 00:0a.0 - PIRQ 03, mask 1eb8, excl - newirq=9 - assigning IRQ 9 - edge ... OK Ok. The thing was marked as edge-triggered, which is basically always wrong for a PCI interrupt. The above printout just means that it now noticed that it was edge, and fixed it up in the ELCR. FWIW Via's PCI to ISA bridge has a PIRQ edge/level register. Vendor=1106h, Device=686h, PCI config offset 54h, RW Bits 7-4 reserved, zero. Bit 3: PIRQA# edge (clear bit for level) Bit 2: PIRQB# edge (clear bit for level) Bit 1: PIRQC# edge (clear bit for level) Bit 0: PIRQD# edge (clear bit for level) The bits are all supposed to default to zero (level). - add the line "eisa_set_level_irq(irq);" to pirq_via_set() just before the "return 1;" You certainly know your kernel very well... :-) That's why they pay me the big bucks. Good. I'll make it do the eisa_set_level_irq() in the generic code: it should always be right (we don't do it now in the PIIX4 case, for example, but the PIIX documentation actually says that we _should_), and there is no need to do it separately for each interrupt router. So calling eisa_set_level_irq() means nothing will scream if we do not update [for example] the above register? Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 3c59x: Using bad IRQ 0
On Tue, 21 Nov 2000, Jeff Garzik wrote: > > A caveat to this whole scheme is that usb-uhci -already- calls > pci_enable_device before checking dev->irq, and yet cannot get around > the "assign IRQ to USB: no" setting in BIOS. I hope that is an > exception rather than the rule. Do we have a recent report of this with full PCI debug output? It might just be another unlisted intel irq router.. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 3c59x: Using bad IRQ 0
On Tue, 21 Nov 2000, Jeff Garzik wrote: > Tobias Ringstrom wrote: > > When saying yes to "Plug-and-play OS" in the BIOS, my 3Com 905C adapter > > stops working, since the driver tries to use IRQ 0, since the BIOS does > > not assign an IRQ to it. The driver seems to read the IRQ from the card > > before it calls pci_enable_device (and pci_set_master). > > > eth0: 3Com PCI 3c905C Tornado at 0xa400, PCI: Enabling device 00:0a.0 (0014 -> >0017) > > PCI: Assigned IRQ 9 for device 00:0a.0 > > 00:01:02:b4:18:e4, IRQ 0 > > Tobias, can you confirm that calling pci_enable_device before reading > dev->irq fixes the 3c59x.c problem for you? Nope. The interrupts do not seem to get through. Packets are transmitted, but that's it. I've copied the interesting parts from dmesg: PCI: PCI BIOS revision 2.10 entry at 0xf10f0, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware Unknown bridge resource 0: assuming transparent PCI: Using IRQ router VIA [1106/0686] at 00:04.0 PCI: Found IRQ 10 for device 00:0b.0 PCI: The same IRQ used for device 00:11.0 [...] 3c59x.c:LK1.1.11 13 Nov 2000 Donald Becker and others. http://www.scyld.com/network/vortex.html $Revision: 1.102.2.46 $ See Documentation/networking/vortex.txt PCI: Enabling device 00:0a.0 (0014 -> 0017) PCI: Assigned IRQ 9 for device 00:0a.0 eth0: 3Com PCI 3c905C Tornado at 0xa400, 00:01:02:b4:18:e4, IRQ 9 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. MII transceiver found at address 24, status 782d. Enabling bus-master transmits and whole-frame receives. [...] eth0: using NWAY autonegotiation NETDEV WATCHDOG: eth0: transmit timed out eth0: transmit timed out, tx_status 00 status e601. eth0: Interrupt posted but not delivered -- IRQ blocked by another device? Flags; bus-master 1, full 0; dirty 16(0) current 16(0). Transmit list vs. cff10200. 0: @cff10200 length 802a status 0001002a 1: @cff10210 length 802a status 0001002a 2: @cff10220 length 802a status 0001002a 3: @cff10230 length 802a status 0001002a 4: @cff10240 length 802a status 0001002a 5: @cff10250 length 802a status 0001002a 6: @cff10260 length 802a status 0001002a 7: @cff10270 length 802a status 0001002a 8: @cff10280 length 802a status 0001002a 9: @cff10290 length 802a status 0001002a 10: @cff102a0 length 802a status 0001002a 11: @cff102b0 length 802a status 0001002a 12: @cff102c0 length 802a status 0001002a 13: @cff102d0 length 802a status 0001002a 14: @cff102e0 length 802a status 8001002a 15: @cff102f0 length 802a status 8001002a eth0: Resetting the Tx ring pointer. I'm attaching lspci -vvv for the pnp and non-pnp cases. A diff between them reveals only two differences. Th first is the IRQ of the 3Com (7 or 9), and the other one is that the game port of the SBLive card is disabled (which should be irreleant). /Tobias 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 02) Subsystem: Asustek Computer, Inc.: Unknown device 8033 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- 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:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8305 (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset- FastB2B- Capabilities: [80] 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:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22) Subsystem: Asustek Computer, Inc.: Unknown device 8033 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- [disabled] [size=128K] Capabilities: [dc] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=2 PME- 00:0b.0 Multimedia audio controller: Creative Labs SB Live! EMU1 (rev 08) Subsystem: Creative Labs CT4832 SBLive! Value Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- [disabled] [size=64K]
Re: 3c59x: Using bad IRQ 0
Tobias Ringstrom wrote: > When saying yes to "Plug-and-play OS" in the BIOS, my 3Com 905C adapter > stops working, since the driver tries to use IRQ 0, since the BIOS does > not assign an IRQ to it. The driver seems to read the IRQ from the card > before it calls pci_enable_device (and pci_set_master). > eth0: 3Com PCI 3c905C Tornado at 0xa400, PCI: Enabling device 00:0a.0 (0014 -> 0017) > PCI: Assigned IRQ 9 for device 00:0a.0 > 00:01:02:b4:18:e4, IRQ 0 Tobias, can you confirm that calling pci_enable_device before reading dev->irq fixes the 3c59x.c problem for you? It sounds like the 2.4 kernel can now support "plug-n-play OS" BIOS setting, AFAICS. If moving pci_enable_device above any dev->irq checks solves Tobias' problem, we need to go through the PCI drivers and make sure we check things in the correct order in all PCI drivers. I wonder if we shouldn't move pci_resource_xxx calls until after pci_enable_device too. A caveat to this whole scheme is that usb-uhci -already- calls pci_enable_device before checking dev->irq, and yet cannot get around the "assign IRQ to USB: no" setting in BIOS. I hope that is an exception rather than the rule. Regards, Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
3c59x: Using bad IRQ 0
Linux-2.4.0-test11: When saying yes to "Plug-and-play OS" in the BIOS, my 3Com 905C adapter stops working, since the driver tries to use IRQ 0, since the BIOS does not assign an IRQ to it. The driver seems to read the IRQ from the card before it calls pci_enable_device (and pci_set_master). Quoting dmesg (from test10, but it looks the same in test11): PCI: PCI BIOS revision 2.10 entry at 0xf10f0, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware Unknown bridge resource 0: assuming transparent PCI: Using IRQ router VIA [1106/0686] at 00:04.0 PCI: Found IRQ 10 for device 00:0b.0 PCI: The same IRQ used for device 00:11.0 [...] 3c59x.c:LK1.1.9 2 Sep 2000 Donald Becker and others. http://www.scyld.com/network/vortex.html $Revision: 1.102.2.38 $ See Documentation/networking/vortex.txt eth0: 3Com PCI 3c905C Tornado at 0xa400, PCI: Enabling device 00:0a.0 (0014 -> 0017) PCI: Assigned IRQ 9 for device 00:0a.0 00:01:02:b4:18:e4, IRQ 0 *** Warning: IRQ 0 is unlikely to work! *** 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. MII transceiver found at address 24, status 782d. Enabling bus-master transmits and whole-frame receives. As you can see, the PCI driver does assign an IRQ, but the driver ignores it. I hope this is enough info to fix the problem. /Tobias - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
3c59x: Using bad IRQ 0
Linux-2.4.0-test11: When saying yes to "Plug-and-play OS" in the BIOS, my 3Com 905C adapter stops working, since the driver tries to use IRQ 0, since the BIOS does not assign an IRQ to it. The driver seems to read the IRQ from the card before it calls pci_enable_device (and pci_set_master). Quoting dmesg (from test10, but it looks the same in test11): PCI: PCI BIOS revision 2.10 entry at 0xf10f0, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware Unknown bridge resource 0: assuming transparent PCI: Using IRQ router VIA [1106/0686] at 00:04.0 PCI: Found IRQ 10 for device 00:0b.0 PCI: The same IRQ used for device 00:11.0 [...] 3c59x.c:LK1.1.9 2 Sep 2000 Donald Becker and others. http://www.scyld.com/network/vortex.html $Revision: 1.102.2.38 $ See Documentation/networking/vortex.txt eth0: 3Com PCI 3c905C Tornado at 0xa400, PCI: Enabling device 00:0a.0 (0014 - 0017) PCI: Assigned IRQ 9 for device 00:0a.0 00:01:02:b4:18:e4, IRQ 0 *** Warning: IRQ 0 is unlikely to work! *** 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. MII transceiver found at address 24, status 782d. Enabling bus-master transmits and whole-frame receives. As you can see, the PCI driver does assign an IRQ, but the driver ignores it. I hope this is enough info to fix the problem. /Tobias - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 3c59x: Using bad IRQ 0
Tobias Ringstrom wrote: When saying yes to "Plug-and-play OS" in the BIOS, my 3Com 905C adapter stops working, since the driver tries to use IRQ 0, since the BIOS does not assign an IRQ to it. The driver seems to read the IRQ from the card before it calls pci_enable_device (and pci_set_master). eth0: 3Com PCI 3c905C Tornado at 0xa400, PCI: Enabling device 00:0a.0 (0014 - 0017) PCI: Assigned IRQ 9 for device 00:0a.0 00:01:02:b4:18:e4, IRQ 0 Tobias, can you confirm that calling pci_enable_device before reading dev-irq fixes the 3c59x.c problem for you? It sounds like the 2.4 kernel can now support "plug-n-play OS" BIOS setting, AFAICS. If moving pci_enable_device above any dev-irq checks solves Tobias' problem, we need to go through the PCI drivers and make sure we check things in the correct order in all PCI drivers. I wonder if we shouldn't move pci_resource_xxx calls until after pci_enable_device too. A caveat to this whole scheme is that usb-uhci -already- calls pci_enable_device before checking dev-irq, and yet cannot get around the "assign IRQ to USB: no" setting in BIOS. I hope that is an exception rather than the rule. Regards, Jeff -- Jeff Garzik | Building 1024 | The chief enemy of creativity is "good" sense MandrakeSoft| -- Picasso - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 3c59x: Using bad IRQ 0
On Tue, 21 Nov 2000, Jeff Garzik wrote: Tobias Ringstrom wrote: When saying yes to "Plug-and-play OS" in the BIOS, my 3Com 905C adapter stops working, since the driver tries to use IRQ 0, since the BIOS does not assign an IRQ to it. The driver seems to read the IRQ from the card before it calls pci_enable_device (and pci_set_master). eth0: 3Com PCI 3c905C Tornado at 0xa400, PCI: Enabling device 00:0a.0 (0014 - 0017) PCI: Assigned IRQ 9 for device 00:0a.0 00:01:02:b4:18:e4, IRQ 0 Tobias, can you confirm that calling pci_enable_device before reading dev-irq fixes the 3c59x.c problem for you? Nope. The interrupts do not seem to get through. Packets are transmitted, but that's it. I've copied the interesting parts from dmesg: PCI: PCI BIOS revision 2.10 entry at 0xf10f0, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware Unknown bridge resource 0: assuming transparent PCI: Using IRQ router VIA [1106/0686] at 00:04.0 PCI: Found IRQ 10 for device 00:0b.0 PCI: The same IRQ used for device 00:11.0 [...] 3c59x.c:LK1.1.11 13 Nov 2000 Donald Becker and others. http://www.scyld.com/network/vortex.html $Revision: 1.102.2.46 $ See Documentation/networking/vortex.txt PCI: Enabling device 00:0a.0 (0014 - 0017) PCI: Assigned IRQ 9 for device 00:0a.0 eth0: 3Com PCI 3c905C Tornado at 0xa400, 00:01:02:b4:18:e4, IRQ 9 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. MII transceiver found at address 24, status 782d. Enabling bus-master transmits and whole-frame receives. [...] eth0: using NWAY autonegotiation NETDEV WATCHDOG: eth0: transmit timed out eth0: transmit timed out, tx_status 00 status e601. eth0: Interrupt posted but not delivered -- IRQ blocked by another device? Flags; bus-master 1, full 0; dirty 16(0) current 16(0). Transmit list vs. cff10200. 0: @cff10200 length 802a status 0001002a 1: @cff10210 length 802a status 0001002a 2: @cff10220 length 802a status 0001002a 3: @cff10230 length 802a status 0001002a 4: @cff10240 length 802a status 0001002a 5: @cff10250 length 802a status 0001002a 6: @cff10260 length 802a status 0001002a 7: @cff10270 length 802a status 0001002a 8: @cff10280 length 802a status 0001002a 9: @cff10290 length 802a status 0001002a 10: @cff102a0 length 802a status 0001002a 11: @cff102b0 length 802a status 0001002a 12: @cff102c0 length 802a status 0001002a 13: @cff102d0 length 802a status 0001002a 14: @cff102e0 length 802a status 8001002a 15: @cff102f0 length 802a status 8001002a eth0: Resetting the Tx ring pointer. I'm attaching lspci -vvv for the pnp and non-pnp cases. A diff between them reveals only two differences. Th first is the IRQ of the 3Com (7 or 9), and the other one is that the game port of the SBLive card is disabled (which should be irreleant). /Tobias 00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0305 (rev 02) Subsystem: Asustek Computer, Inc.: Unknown device 8033 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 e000 (32-bit, prefetchable) [size=128M] Capabilities: [a0] AGP version 2.0 Status: RQ=31 SBA+ 64bit- FW- Rate=x1,x2 Command: RQ=0 SBA- AGP- 64bit- FW- Rate=none 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:01.0 PCI bridge: VIA Technologies, Inc.: Unknown device 8305 (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort+ SERR- PERR- Latency: 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: e000-dfff Memory behind bridge: d600-d7df Prefetchable memory behind bridge: d7f0-dfff BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- Reset- FastB2B- Capabilities: [80] 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:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22) Subsystem: Asustek Computer, Inc.: Unknown device 8033 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 00:04.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE
Re: 3c59x: Using bad IRQ 0
On Tue, 21 Nov 2000, Jeff Garzik wrote: A caveat to this whole scheme is that usb-uhci -already- calls pci_enable_device before checking dev-irq, and yet cannot get around the "assign IRQ to USB: no" setting in BIOS. I hope that is an exception rather than the rule. Do we have a recent report of this with full PCI debug output? It might just be another unlisted intel irq router.. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
