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
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
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 00000000 vs. cff10200.
0: @cff10200 length 8000002a status 0001002a
1: @cff10210 length 8000002a status 0001002a
2: @cff10220 length 8000002a status 0001002a
3: @cff10230 length 8000002a status 0001002a
4: @cff10240 length 8000002a status 0001002a
5: @cff10250 length 8000002a status 0001002a
6: @cff10260 length 8000002a status 0001002a
7: @cff10270 length 8000002a status 0001002a
8: @cff10280 length 8000002a status 0001002a
9: @cff10290 length 8000002a status 0001002a
10: @cff102a0 length 8000002a status 0001002a
11: @cff102b0 length 8000002a status 0001002a
12: @cff102c0 length 8000002a status 0001002a
13: @cff102d0 length 8000002a status 0001002a
14: @cff102e0 length 8000002a status 8001002a
15: @cff102f0 length 8000002a 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
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
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
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 0000 -> newirq=9 -> assigning IRQ 9 ... OK
was changed into
IRQ for 00:0a.0(0) via 00:0a.0 -> PIRQ 03, mask 1eb8, excl 0000 -> 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: 000000000009e800 @ 0000000000000000 (usable)
BIOS-e820: 0000000000001800 @ 000000000009e800 (reserved)
BIOS-e820: 0000000000010000 @ 00000000000f0000 (reserved)
BIOS-e820: 000000000feec000 @ 0000000000100000 (usable)
BIOS-e820: 0000000000003000 @ 000000000ffec000 (ACPI data)
BIOS-e820: 0000000000010000 @ 000000000ffef000 (reserved)
BIOS-e820: 0000000000001000 @ 000000000ffff000 (ACPI NVS)
BIOS-e820: 0000000000010000 @ 00000000ffff0000 (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 00000000, 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 00000000 00000000
CPU: After generic, caps: 0183f9ff c1c7f9ff 00000000 00000000
CPU: Common caps: 0183f9ff c1c7f9ff 00000000 00000000
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 0000 ... failed
IRQ for 00:0b.0(0) via 00:0b.0 -> PIRQ 02, mask 1eb8, excl 0000 -> 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 e0000000-e7ffffff (f=1208, d=0, p=0)
PCI: Resource 0000d800-0000d80f (f=101, d=0, p=0)
PCI: Resource 0000d400-0000d41f (f=101, d=0, p=0)
PCI: Resource 0000d000-0000d01f (f=101, d=0, p=0)
PCI: Resource 00009400-00009407 (f=101, d=0, p=0)
PCI: Resource 00009000-00009003 (f=101, d=0, p=0)
PCI: Resource 00008800-00008807 (f=101, d=0, p=0)
PCI: Resource 00008400-00008403 (f=101, d=0, p=0)
PCI: Resource 00008000-0000803f (f=101, d=0, p=0)
PCI: Resource d5000000-d501ffff (f=200, d=0, p=0)
PCI: Resource d6000000-d6ffffff (f=200, d=0, p=0)
PCI: Resource d8000000-dfffffff (f=1208, d=0, p=0)
PCI: Resource 0000a400-0000a47f (f=101, d=1, p=1)
PCI: Resource d5800000-d580007f (f=200, d=1, p=1)
PCI: Resource 0000a000-0000a01f (f=101, d=1, p=1)
PCI: Resource 00009800-00009807 (f=101, d=1, p=1)
PCI: Sorting device list...
isapnp: Scanning for Pnp cards...
isapnp: No Plug & Play device found
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.13)
Starting kswapd v1.8
parport_pc: Via 686A parallel port disabled in BIOS
pty: 256 Unix98 ptys configured
loop: enabling 8 loop devices
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PDC20265: IDE controller on PCI bus 00 dev 88
PDC20265: chipset revision 2
PDC20265: not 100% native mode: will probe irqs later
PDC20265: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.
ide0: BM-DMA at 0x8000-0x8007, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0x8008-0x800f, BIOS settings: hdc:DMA, hdd:DMA
VP_IDE: IDE controller on PCI bus 00 dev 21
VP_IDE: chipset revision 16
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c686a IDE UDMA66 controller on pci0:4.1
ide2: BM-DMA at 0xd800-0xd807, BIOS settings: hde:DMA, hdf:pio
ide3: BM-DMA at 0xd808-0xd80f, BIOS settings: hdg:DMA, hdh:pio
hda: IBM-DTLA-307060, ATA DISK drive
hde: HITACHI DVD-ROM GD-7500, ATAPI CDROM drive
hdg: PLEXTOR CD-R PX-W1210A, ATAPI CDROM drive
ide0 at 0x9400-0x9407,0x9002 on irq 10
ide2 at 0x1f0-0x1f7,0x3f6 on irq 14
ide3 at 0x170-0x177,0x376 on irq 15
hda: 120103200 sectors (61493 MB) w/1916KiB Cache, CHS=119150/16/63, UDMA(100)
hde: ATAPI 40X DVD-ROM drive, 512kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.11
hdg: ATAPI 32X CD-ROM CD-R/RW drive, 2048kB Cache, DMA
Partition check:
hda: [PTBL] [7476/255/63] hda1 hda2 hda3
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI ISAPNP enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
Real Time Clock Driver v1.10d
ppdev: user-space parallel port driver
PPP generic driver version 2.4.1
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)
IRQ for 00:0a.0(0) via 00:0a.0 -> PIRQ 03, mask 1eb8, excl 0000 -> newirq=9 -> assigning IRQ 9 -> edge ... OK
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.
PPP Deflate Compression module registered
SCSI subsystem driver Revision: 1.00
scsi0 : SCSI host adapter emulation for IDE ATAPI devices
Creative EMU10K1 PCI Audio Driver, version 0.7, 19:28:33 Nov 21 2000
PCI: Enabling device 00:0b.0 (0004 -> 0005)
emu10k1: EMU10K1 rev 8 model 0x8027 found, IO at 0xa000-0xa01f, IRQ 10
mice: PS/2 mouse device common for all mice
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 16384)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
kmem_create: Forcing size word alignment - nfs_fh
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 220k freed
Adding Swap: 208836k swap-space (priority -1)
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 0000 -> newirq=9 -> assigning IRQ 9 ... OK
>
> was changed into
>
> IRQ for 00:0a.0(0) via 00:0a.0 -> PIRQ 03, mask 1eb8, excl 0000 -> 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
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 0000 -> newirq=9 -> assigning IRQ 9 ... OK
> >
> > was changed into
> >
> > IRQ for 00:0a.0(0) via 00:0a.0 -> PIRQ 03, mask 1eb8, excl 0000 -> 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
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 f8000000 (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- 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: Memory at fedffc00 (32-bit, non-prefetchable) [size=256]
Region 1: I/O ports at fc88 [size=8]
Region 2: I/O ports at f400 [size=256]
Capabilities: <available only to root>
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- <TAbort- <MAbort- >SERR- <PERR-
Latency: 168
Interrupt: pin A routed to IRQ 11
Region 0: Memory at 10000000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=00, secondary=01, subordinate=01, sec-latency=176
Memory window 0: 10400000-107ff000 (prefetchable)
Memory window 1: 10800000-10bff000
I/O window 0: 00001000-000010ff
I/O window 1: 00001400-000014ff
BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >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: 000000000009f400 @ 0000000000000000 (usable)
BIOS-e820: 0000000000000c00 @ 000000000009f400 (reserved)
BIOS-e820: 0000000000017000 @ 00000000000e9000 (reserved)
BIOS-e820: 0000000007ef0000 @ 0000000000100000 (usable)
BIOS-e820: 000000000000fc00 @ 0000000007ff0000 (ACPI data)
BIOS-e820: 0000000000000400 @ 0000000007fffc00 (ACPI NVS)
BIOS-e820: 0000000000017000 @ 00000000fffe9000 (reserved)
Scan SMP from c0000000 for 1024 bytes.
Scan SMP from c009fc00 for 1024 bytes.
Scan SMP from c00f0000 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 ffffe000 (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 00000000 00000000, 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 00000000 00000000 00000000
CPU: After generic, caps: 0383f9ff 00000000 00000000 00000000
CPU: Common caps: 0383f9ff 00000000 00000000 00000000
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 1:00/def8 2:00/def8 3:63/0800
00:09 slot=00 0:62/0800 1:00/def8 2:00/def8 3:00/def8
01:04 slot=00 0:60/0800 1:00/def8 2:00/def8 3:00/def8
01:08 slot=00 0:60/0800 1:00/def8 2:00/def8 3:00/def8
00:0a slot=00 0:60/0800 1:00/def8 2:00/def8 3:00/def8
00:02 slot=00 0:60/0800 1:00/def8 2:00/def8 3:00/def8
00:00 slot=00 0:00/def8 1:61/08e0 2:00/def8 3:00/def8
PCI: Using IRQ router PIIX [8086/7198] at 00:07.0
PCI: IRQ fixup
00:0a.0: ignoring bogus IRQ 255
IRQ for 00:0a.0(0) via 00:0a.0 -> PIRQ 60, mask 0800, excl 0000 -> got IRQ 11
PCI: Found IRQ 11 for device 00:0a.0
PCI: The same IRQ used for device 00:02.0
PCI: Allocating resources
PCI: Resource 0000f800-0000f8ff (f=101, d=0, p=0)
PCI: Resource 0000fc00-0000fc3f (f=101, d=0, p=0)
PCI: Resource f8000000-fbffffff (f=200, d=0, p=0)
PCI: Resource 0000fc90-0000fc9f (f=101, d=0, p=0)
PCI: Resource 0000fca0-0000fcbf (f=101, d=0, p=0)
PCI: Resource fedffc00-fedffcff (f=200, d=0, p=0)
PCI: Resource 0000fc88-0000fc8f (f=109, d=0, p=0)
PCI: Resource 0000f400-0000f4ff (f=101, d=0, p=0)
PCI: Sorting device list...
isapnp: Scanning for Pnp cards...
isapnp: No Plug & Play device found
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.13)
Starting kswapd v1.8
pty: 256 Unix98 ptys configured
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PIIX4: IDE controller on PCI bus 00 dev 39
PIIX4: chipset revision 0
PIIX4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xfc90-0xfc97, BIOS settings: hda:DMA, hdb:pio
hda: IBM-DARA-212000, ATA DISK drive
hdb: CD-224E, ATAPI CDROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: 23579136 sectors (12073 MB) w/418KiB Cache, CHS=1559/240/63, UDMA(33)
Partition check:
hda: hda1 hda2 hda3 hda4
Linux PCMCIA Card Services 3.1.22
options: [pci] [cardbus] [pm]
Intel PCIC probe: not found.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 8192 bind 8192)
Yenta IRQ list 0698, PCI irq11
Socket status: 30000006
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 184k freed
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Adding Swap: 136072k swap-space (priority -1)
Serial driver version 5.02 (2000-08-09) with MANY_PORTS SHARE_IRQ SERIAL_PCI ISAPNP enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
cs: IO port probe 0x0c00-0x0cff: clean.
cs: IO port probe 0x0800-0x08ff: clean.
cs: IO port probe 0x0100-0x04ff: excluding 0x378-0x37f 0x398-0x39f 0x4d0-0x4d7
cs: IO port probe 0x0a00-0x0aff: clean.
irda_init()
irlmp_init()
IrDA: Registered device irda0
irlmp_register_client()
irtty_net_open()
irlap_change_speed(), setting speed to 9600
Installing knfsd (copyright (C) 1996 [email protected]).
PCI: Setting latency timer of device 00:00.1 to 64
As a sidenote: I am able to use a 3Com Megahertz 574B when I run
2.4.0-test11, but when I use 2.4.0-test11-ac3, every PCMCIA card I use
is detected as a memory card and fails to initialise.
Let me know if you want more information.
Erik
--
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands
Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [email protected]
WWW: http://www-ict.its.tudelft.nl/~erik/
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