linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* dmesg: PCI interrupts are no longer routed automatically.........
@ 2004-12-29  9:55 aryix
  2005-01-04 18:18 ` Bjorn Helgaas
  0 siblings, 1 reply; 11+ messages in thread
From: aryix @ 2004-12-29  9:55 UTC (permalink / raw)
  To: bjorn.helgaas, lug-list, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1 bytes --]



[-- Attachment #2: dmesg_2.6.10 --]
[-- Type: application/octet-stream, Size: 12099 bytes --]

Linux version 2.6.10ab01 (aryix@sophia) (gcc version 3.3.4 (Debian 1:3.3.4-13)) #3 Tue Dec 28 18:36:05 UTC 2004
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 0000000007ff0000 (usable)
 BIOS-e820: 0000000007ff0000 - 0000000007ff3000 (ACPI NVS)
 BIOS-e820: 0000000007ff3000 - 0000000008000000 (ACPI data)
 BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
127MB LOWMEM available.
On node 0 totalpages: 32752
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 28656 pages, LIFO batch:6
  HighMem zone: 0 pages, LIFO batch:1
DMI 2.2 present.
ACPI: RSDP (v000 VIA694                                ) @ 0x000f6c50
ACPI: RSDT (v001 VIA694 AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x07ff3000
ACPI: FADT (v001 VIA694 AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x07ff3040
ACPI: DSDT (v001 VIA694 AWRDACPI 0x00001000 MSFT 0x0100000c) @ 0x00000000
Built 1 zonelists
Kernel command line: root=/dev/hda1 ro 
Initializing CPU#0
PID hash table entries: 512 (order: 9, 8192 bytes)
Detected 601.386 MHz processor.
Using tsc for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 125732k/131008k available (2227k kernel code, 4760k reserved, 879k data, 236k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 1175.55 BogoMIPS (lpj=587776)
Security Framework v1.0.0 initialized
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: After generic identify, caps: 0081f9ff c0c1f9ff 00000000 00000000
CPU: After vendor identify, caps:  0081f9ff c0c1f9ff 00000000 00000000
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU: After all inits, caps:        0081f9ff c0c1f9ff 00000000 00000020
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: AMD-K7(tm) Processor stepping 02
Checking 'hlt' instruction... OK.
 tbxface-0118 [02] acpi_load_tables      : ACPI Tables successfully acquired
Parsing all Control Methods:....................................................................
Table [DSDT](id F004) - 286 Objects with 27 Devices 68 Methods 19 Regions
ACPI Namespace successfully loaded at root c0459c60
ACPI: setting ELCR to 0200 (from 0e00)
evxfevnt-0094 [03] acpi_enable           : Transition to ACPI mode successful
NET: Registered protocol family 16
EISA bus registered
PCI: PCI BIOS revision 2.10 entry at 0xfb460, last bus=1
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20041105
evgpeblk-0979 [06] ev_create_gpe_block   : GPE 00 to 0F [_GPE] 2 regs on int 0x9
evgpeblk-0987 [06] ev_create_gpe_block   : Found 3 Wake, Enabled 0 Runtime GPEs in this block
Completing Region/Field/Buffer/Package initialization:........................................
Initialized 18/19 Regions 1/1 Fields 16/16 Buffers 5/7 Packages (295 nodes)
Executing all Device _STA and_INI methods:..............................
30 Devices found containing: 30 _STA, 1 _INI methods
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 1 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 5 6 7 10 11 12 14 15) *9
ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 5 6 7 10 11 12 14 15) *9
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
acpi_bus-0081 [03] acpi_bus_get_device   : Error getting context for object [c7fc3848]
acpi_bus-0081 [03] acpi_bus_get_device   : Error getting context for object [c7fc3488]
pnp: PnP ACPI: found 12 devices
PnPBIOS: Disabled by ACPI
PCI: Using ACPI for IRQ routing
** PCI interrupts are no longer routed automatically.  If this
** causes a device to stop working, it is probably because the
** driver failed to call pci_enable_device().  As a temporary
** workaround, the "pci=routeirq" argument restores the old
** behavior.  If this argument makes the device work again,
** please email the output of "lspci" to bjorn.helgaas@hp.com
** so I can fix the driver.
TC classifier action (bugs to netdev@oss.sgi.com cc hadi@cyberus.ca)
pnp: the driver 'system' has been registered
pnp: match found with the PnP device '00:00' and the driver 'system'
pnp: match found with the PnP device '00:01' and the driver 'system'
Machine check exception polling timer started.
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
SGI XFS with ACLs, security attributes, realtime, large block numbers, no debug enabled
SGI XFS Quota Management subsystem
Initializing Cryptographic API
vesafb: probe of vesafb0 failed with error -6
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Real Time Clock Driver v1.12
Non-volatile memory driver v1.2
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
pnp: the driver 'serial' has been registered
pnp: match found with the PnP device '00:07' and the driver 'serial'
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
pnp: match found with the PnP device '00:08' and the driver 'serial'
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
divert: not allocating divert_blk for non-ethernet device lo
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller at PCI slot 0000:00:07.1
VP_IDE: chipset revision 16
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c686a (rev 21) IDE UDMA66 controller on pci0000:00:07.1
    ide0: BM-DMA at 0xc000-0xc007, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xc008-0xc00f, BIOS settings: hdc:DMA, hdd:pio
Probing IDE interface ide0...
hda: HDS722580VLAT20, ATA DISK drive
elevator: using anticipatory as default io scheduler
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdc: Maxtor 31024H2, ATA DISK drive
ide1 at 0x170-0x177,0x376 on irq 15
Probing IDE interface ide2...
ide2: Wait for ready failed before probe !
Probing IDE interface ide3...
ide3: Wait for ready failed before probe !
Probing IDE interface ide4...
ide4: Wait for ready failed before probe !
Probing IDE interface ide5...
ide5: Wait for ready failed before probe !
hda: max request size: 1024KiB
hda: 160836480 sectors (82348 MB) w/1794KiB Cache, CHS=16383/255/63, UDMA(66)
hda: cache flushes supported
 hda: hda1 hda2 hda3 hda4 < hda5 hda6 >
hdc: max request size: 128KiB
hdc: 19746720 sectors (10110 MB) w/512KiB Cache, CHS=19590/16/63, UDMA(66)
hdc: cache flushes not supported
 hdc: hdc1 hdc2
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard on isa0060/serio0
input: GenPS/2 Genius Wheel Mouse on isa0060/serio1
EISA: Probing bus 0 at eisa0
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 8192 bind 16384)
NET: Registered protocol family 8
NET: Registered protocol family 20
XFS mounting filesystem hda1
Ending clean XFS mount for filesystem: hda1
VFS: Mounted root (xfs filesystem) readonly.
Freeing unused kernel memory: 236k freed
NET: Registered protocol family 1
Adding 232900k swap on /dev/hda6.  Priority:-1 extents:1
SCSI subsystem initialized
w83877f_wdt: WDT driver for W83877F initialised. timeout=30 sec (nowayout=0)
8139too Fast Ethernet driver 0.9.27
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 10
PCI: setting IRQ 10 as level-triggered
ACPI: PCI interrupt 0000:00:08.0[A] -> GSI 10 (level, low) -> IRQ 10
divert: allocating divert_blk for eth0
eth0: RealTek RTL8139 at 0xdc00, 00:50:22:8f:a0:bd, IRQ 10
eth0:  Identified 8139 chip type 'RTL-8139C'
inserting floppy driver for 2.6.10ab01
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
ACPI: PCI interrupt 0000:00:07.5[C] -> GSI 11 (level, low) -> IRQ 11
PCI: Via IRQ fixup for 0000:00:07.5, from 9 to 11
PCI: Setting latency timer of device 0000:00:07.5 to 64
loop: loaded (max 8 devices)
nvidia: module license 'NVIDIA' taints kernel.
ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 10 (level, low) -> IRQ 10
NVRM: loading NVIDIA Linux x86 NVIDIA Kernel Module  1.0-6629  Wed Nov  3 13:12:51 PST 2004
device-mapper: 4.3.0-ioctl (2004-09-30) initialised: dm-devel@redhat.com
ReiserFS: hda2: found reiserfs format "3.6" with standard journal
ReiserFS: hda2: using ordered data mode
ReiserFS: hda2: journal params: device hda2, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: hda2: checking transaction log (hda2)
ReiserFS: hda2: Using r5 hash to sort names
ReiserFS: hda5: found reiserfs format "3.6" with standard journal
ReiserFS: hda5: using ordered data mode
ReiserFS: hda5: journal params: device hda5, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: hda5: checking transaction log (hda5)
ReiserFS: hda5: Using r5 hash to sort names
parport_pc: Ignoring new-style parameters in presence of obsolete ones
parport_pc: VIA 686A/8231 detected
parport_pc: probing current configuration
parport_pc: Current parallel port base: 0x378
parport0: PC-style at 0x378, irq 7 [PCSPP,EPP]
parport_pc: VIA parallel port: io=0x378, irq=7
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 11
ACPI: PCI interrupt 0000:00:09.0[A] -> GSI 11 (level, low) -> IRQ 11
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36
        <Adaptec aic7850 SCSI adapter>
        aic7850: Single Channel A, SCSI Id=7, 3/253 SCBs

(scsi0:A:3): 10.000MB/s transfers (10.000MHz, offset 15)
  Vendor: SEAGATE   Model: ST52160N          Rev: 0285
  Type:   Direct-Access                      ANSI SCSI revision: 02
Attached scsi generic sg0 at scsi0, channel 0, id 3, lun 0,  type 0
(scsi0:A:6): 10.000MB/s transfers (10.000MHz, offset 15)
  Vendor: TEAC      Model: CD-R56S           Rev: 1.0M
  Type:   CD-ROM                             ANSI SCSI revision: 02
sr0: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.20
Attached scsi CD-ROM sr0 at scsi0, channel 0, id 6, lun 0
Attached scsi generic sg1 at scsi0, channel 0, id 6, lun 0,  type 5
usbcore: registered new driver usbfs
usbcore: registered new driver hub
USB Universal Host Controller Interface driver v2.2
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 10
ACPI: PCI interrupt 0000:00:07.2[D] -> GSI 10 (level, low) -> IRQ 10
PCI: Via IRQ fixup for 0000:00:07.2, from 9 to 10
uhci_hcd 0000:00:07.2: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller
uhci_hcd 0000:00:07.2: irq 10, io base 0xc400
uhci_hcd 0000:00:07.2: new USB bus registered, assigned bus number 1
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
eth0: link up, 100Mbps, full-duplex, lpa 0x41E1
CSLIP: code copyright 1989 Regents of the University of California
PPP generic driver version 2.4.2
NET: Registered protocol family 17
NET: Registered protocol family 10
Disabled Privacy Extensions on device c03d96e0(lo)
IPv6 over IPv4 tunneling driver
divert: not allocating divert_blk for non-ethernet device sit0
lp0: using parport0 (interrupt-driven).
lp0: console ready
eth0: no IPv6 routers present
Linux agpgart interface v0.100 (c) Dave Jones

[-- Attachment #3: pci_list --]
[-- Type: application/octet-stream, Size: 6651 bytes --]

0000:00:00.0 Host bridge: VIA Technologies, Inc. VT8371 [KX133] (rev 02)
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
	Latency: 0
	Region 0: Memory at da000000 (32-bit, prefetchable) [size=32M]
	Capabilities: [a0] AGP version 2.0
		Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4
		Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP+ GART64- 64bit- FW- Rate=x4

0000:00:01.0 PCI bridge: VIA Technologies, Inc. VT8371 [KX133 AGP] (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: 0000f000-00000fff
	Memory behind bridge: d8000000-d9ffffff
	Prefetchable memory behind bridge: d0000000-d7ffffff
	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-

0000:00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 21)
	Subsystem: VIA Technologies, Inc. VT82C686/A PCI to 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

0000:00:07.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 10) (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: 32
	Region 4: I/O ports at c000 [size=16]
	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-

0000:00:07.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 10) (prog-if 00 [UHCI])
	Subsystem: VIA Technologies, Inc. (Wrong ID) USB 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-
	Latency: 32, Cache Line Size: 0x08 (32 bytes)
	Interrupt: pin D routed to IRQ 10
	Region 4: I/O ports at c400 [size=32]
	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-

0000:00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30)
	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 ? routed to IRQ 9
	Capabilities: [68] 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-

0000:00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 AC97 Audio Controller (rev 20)
	Subsystem: VIA Technologies, Inc. Onboard Audio on EP7KXA
	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 C routed to IRQ 11
	Region 0: I/O ports at cc00 [size=256]
	Region 1: I/O ports at d000 [size=4]
	Region 2: I/O ports at d400 [size=4]
	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-

0000:00:07.6 Communication controller: VIA Technologies, Inc. Intel 537 [AC97 Modem] (rev 20)
	Subsystem: SILICON Laboratories: Unknown device 4c21
	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 C routed to IRQ 9
	Region 0: I/O ports at d800 [size=256]
	Capabilities: [d0] 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-

0000:00:08.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
	Subsystem: Realtek Semiconductor Co., Ltd. RT8139
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (8000ns min, 16000ns max)
	Interrupt: pin A routed to IRQ 10
	Region 0: I/O ports at dc00 [size=256]
	Region 1: Memory at dc000000 (32-bit, non-prefetchable) [size=256]
	Capabilities: [50] 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-

0000:00:09.0 SCSI storage controller: Adaptec AHA-7850 (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: 32 (1000ns min, 1000ns max), Cache Line Size: 0x08 (32 bytes)
	Interrupt: pin A routed to IRQ 11
	Region 0: I/O ports at e000 [disabled] [size=256]
	Region 1: Memory at dc001000 (32-bit, non-prefetchable) [size=4K]

0000:01:00.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2 MX/MX 400] (rev b2) (prog-if 00 [VGA])
	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: 248 (1250ns min, 250ns max)
	Interrupt: pin A routed to IRQ 10
	Region 0: Memory at d8000000 (32-bit, non-prefetchable) [size=16M]
	Region 1: Memory at d0000000 (32-bit, prefetchable) [size=128M]
	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-
	Capabilities: [44] AGP version 2.0
		Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA- ITACoh- GART64- HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4
		Command: RQ=32 ArqSz=0 Cal=0 SBA- AGP+ GART64- 64bit- FW- Rate=x4


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: dmesg: PCI interrupts are no longer routed automatically.........
  2004-12-29  9:55 dmesg: PCI interrupts are no longer routed automatically aryix
@ 2005-01-04 18:18 ` Bjorn Helgaas
  2005-01-04 18:53   ` linux-os
  0 siblings, 1 reply; 11+ messages in thread
From: Bjorn Helgaas @ 2005-01-04 18:18 UTC (permalink / raw)
  To: aryix; +Cc: lug-list, linux-kernel

Do you have a device that doesn't work unless you specify
"pci=routeirq"?

If all your devices work, you can ignore the note in dmesg.


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: dmesg: PCI interrupts are no longer routed automatically.........
  2005-01-04 18:18 ` Bjorn Helgaas
@ 2005-01-04 18:53   ` linux-os
  2005-01-04 19:41     ` Bjorn Helgaas
  0 siblings, 1 reply; 11+ messages in thread
From: linux-os @ 2005-01-04 18:53 UTC (permalink / raw)
  To: Bjorn Helgaas; +Cc: aryix, lug-list, linux-kernel

On Tue, 4 Jan 2005, Bjorn Helgaas wrote:

> Do you have a device that doesn't work unless you specify
> "pci=routeirq"?
>
> If all your devices work, you can ignore the note in dmesg.
>
> -

I note that pci_enable_device() needs to be executed __before__
the IRQ is obtained on 2.6.10, otherwise you get the wrong IRQ
(IRQ10 on this system)B.

This doesn't seem to be correct since the IRQ connection was set
by the BIOS and certainly shouldn't be changed. On this system,
interrupts that were not shared on 2.4.n and early 2.6.n end
up being shared... See IRQ18 below.

            CPU0
   0:    1135520    IO-APIC-edge  timer
   1:       3203    IO-APIC-edge  i8042
   7:          0    IO-APIC-edge  parport0
   8:          1    IO-APIC-edge  rtc
   9:          0   IO-APIC-level  acpi
  12:         66    IO-APIC-edge  i8042
  14:      10637    IO-APIC-edge  ide0
  16:          0   IO-APIC-level  uhci_hcd, uhci_hcd
  18:         81   IO-APIC-level  libata, uhci_hcd, Analogic Corp DLB
  19:          0   IO-APIC-level  uhci_hcd
  20:        801   IO-APIC-level  eth0
  21:        982   IO-APIC-level  aic7xxx
  23:          0   IO-APIC-level  ehci_hcd
NMI:          0 
LOC:    1135484 
ERR:          0
MIS:          0

Cheers,
Dick Johnson
Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips).
  Notice : All mail here is now cached for review by Dictator Bush.
                  98.36% of all statistics are fiction.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: dmesg: PCI interrupts are no longer routed automatically.........
  2005-01-04 18:53   ` linux-os
@ 2005-01-04 19:41     ` Bjorn Helgaas
  2005-01-04 19:55       ` linux-os
  0 siblings, 1 reply; 11+ messages in thread
From: Bjorn Helgaas @ 2005-01-04 19:41 UTC (permalink / raw)
  To: linux-os; +Cc: aryix, lug-list, linux-kernel

On Tue, 2005-01-04 at 13:53 -0500, linux-os wrote:

> I note that pci_enable_device() needs to be executed __before__
> the IRQ is obtained on 2.6.10, otherwise you get the wrong IRQ
> (IRQ10 on this system)B.

Right.

> This doesn't seem to be correct since the IRQ connection was set
> by the BIOS and certainly shouldn't be changed. On this system,
> interrupts that were not shared on 2.4.n and early 2.6.n end
> up being shared... See IRQ18 below.

It's not that we are changing the IRQ, it's just that we now
do the ACPI routing at the time the driver claims the device,
rather than doing all the ACPI routing at boot-time.  The
old strategy messed with IRQs that might never be used (which
broke some things), and also didn't work for hot-plug PCI
root bridges.

Back to my original question, do you have a device that
only works when you use "pci=routeirq"?  If so, what is
it and what driver does it use?


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: dmesg: PCI interrupts are no longer routed automatically.........
  2005-01-04 19:41     ` Bjorn Helgaas
@ 2005-01-04 19:55       ` linux-os
  2005-01-05  9:40         ` David Vrabel
  0 siblings, 1 reply; 11+ messages in thread
From: linux-os @ 2005-01-04 19:55 UTC (permalink / raw)
  To: Bjorn Helgaas; +Cc: aryix, lug-list, Linux kernel

On Tue, 4 Jan 2005, Bjorn Helgaas wrote:

> On Tue, 2005-01-04 at 13:53 -0500, linux-os wrote:
>
>> I note that pci_enable_device() needs to be executed __before__
>> the IRQ is obtained on 2.6.10, otherwise you get the wrong IRQ
>> (IRQ10 on this system)B.
>
> Right.
>
>> This doesn't seem to be correct since the IRQ connection was set
>> by the BIOS and certainly shouldn't be changed. On this system,
>> interrupts that were not shared on 2.4.n and early 2.6.n end
>> up being shared... See IRQ18 below.
>
> It's not that we are changing the IRQ, it's just that we now
> do the ACPI routing at the time the driver claims the device,
> rather than doing all the ACPI routing at boot-time.  The
> old strategy messed with IRQs that might never be used (which
> broke some things), and also didn't work for hot-plug PCI
> root bridges.
>
> Back to my original question, do you have a device that
> only works when you use "pci=routeirq"?  If so, what is
> it and what driver does it use?
>
No.
I modified our drivers to accommodate the new scheme. The problem
is that I don't feel warm and fuzzy about enabling a device
__before__ an IRQ handler is in place to handle the IRQ.
For instance,  Level interrupts from PLX chips on the PCI bus
can (read do) generate interrupts when some of the BARS are
being configured. Once you get an unhandled interrupt, you
are dead because there's nothing to reset the line.

The new scheme requires that the device be enabled to get
the correct IRQ. If you did this work, maybe it would
be much better if you added a pci_set_irq() call instead
of combining your routing with enabling the device?

Cheers,
Dick Johnson
Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips).
  Notice : All mail here is now cached for review by Dictator Bush.
                  98.36% of all statistics are fiction.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: dmesg: PCI interrupts are no longer routed automatically.........
  2005-01-04 19:55       ` linux-os
@ 2005-01-05  9:40         ` David Vrabel
  2005-01-05 12:06           ` linux-os
  0 siblings, 1 reply; 11+ messages in thread
From: David Vrabel @ 2005-01-05  9:40 UTC (permalink / raw)
  To: linux-os; +Cc: Bjorn Helgaas, aryix, lug-list, Linux kernel

linux-os wrote:
> 
> For instance,  Level interrupts from PLX chips on the PCI bus
> can (read do) generate interrupts when some of the BARS are
> being configured. Once you get an unhandled interrupt, you
> are dead because there's nothing to reset the line.

Why not unconditionally clear all interrupts after configuring the chip?

David Vrabel

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: dmesg: PCI interrupts are no longer routed automatically.........
  2005-01-05  9:40         ` David Vrabel
@ 2005-01-05 12:06           ` linux-os
  2005-01-05 17:13             ` Bjorn Helgaas
  0 siblings, 1 reply; 11+ messages in thread
From: linux-os @ 2005-01-05 12:06 UTC (permalink / raw)
  To: David Vrabel; +Cc: Bjorn Helgaas, aryix, lug-list, Linux kernel

On Wed, 5 Jan 2005, David Vrabel wrote:

> linux-os wrote:
>> 
>> For instance,  Level interrupts from PLX chips on the PCI bus
>> can (read do) generate interrupts when some of the BARS are
>> being configured. Once you get an unhandled interrupt, you
>> are dead because there's nothing to reset the line.
>
> Why not unconditionally clear all interrupts after configuring the chip?
>
> David Vrabel
>

You can't configure the chip until the BARS are set up for
access. You _must_ know what the interrupt line is, before
you touch any registers so that any "waiting" interrupt
gets handled, i.e., cleared. Otherwise, the code that
inspects the PCI bus, looking for a device to claim, finds
the device, then (in order to make its IRQ correct) enables
it ... BAM that's all she wrote. No messages, no nothing,
a halted machine because the IRQ line is permanently TRUE
with no code in place to reset it.

The temporary work-around is....
 	pci_enable_device(pdev);
 	save_irq = pdev->irq;
 	pci_disable_device(pdev);	// Turn back off.

 	init_bars(....);
 	request_irq(save_irq,...)	// Put ISR in place

 	pci_write_config_byte(pdev, PCI_CACHE_LINE_SIZE, 0x08);
 	pci_write_config_byte(pdev, PCI_LATENCY_TIMER, 0x40);
 	pci_set_dma_mask(pdev, 0x00000000ffffffffULL);
 	pci_set_drvdata(pdev, NULL);
 	pci_set_power_state(pdev, 0);
 	pci_set_master(pdev);
 	pci_set_mwi(pdev);
 	pci_write_config_dword(pdev, PCI_COMMAND, PCI_CONFIG);

 	.... configure chip-specific stuff, clear interrupts, etc.
 	pci_enable_device(dev);


Now, the temporary work-around is a MACRO called ROUTE_IRQ().
If the guy who changed the PCI API adds a seperate callable
procedure to do this routing without actually enabling the
chip, I will substitute.

This work-round is a new Linux-2.6.10 bug-hack. It was never
required before

Cheers,
Dick Johnson
Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips).
  Notice : All mail here is now cached for review by Dictator Bush.
                  98.36% of all statistics are fiction.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: dmesg: PCI interrupts are no longer routed automatically.........
  2005-01-05 12:06           ` linux-os
@ 2005-01-05 17:13             ` Bjorn Helgaas
  2005-01-05 18:15               ` linux-os
  0 siblings, 1 reply; 11+ messages in thread
From: Bjorn Helgaas @ 2005-01-05 17:13 UTC (permalink / raw)
  To: linux-os; +Cc: David Vrabel, aryix, lug-list, Linux kernel

On Wed, 2005-01-05 at 07:06 -0500, linux-os wrote:
> The temporary work-around is....
>  	pci_enable_device(pdev);
>  	save_irq = pdev->irq;
>  	pci_disable_device(pdev);	// Turn back off.
> 
>  	init_bars(....);
>  	request_irq(save_irq,...)	// Put ISR in place
> 
>  	pci_write_config_byte(pdev, PCI_CACHE_LINE_SIZE, 0x08);
>  	pci_write_config_byte(pdev, PCI_LATENCY_TIMER, 0x40);
>  	pci_set_dma_mask(pdev, 0x00000000ffffffffULL);
>  	pci_set_drvdata(pdev, NULL);
>  	pci_set_power_state(pdev, 0);
>  	pci_set_master(pdev);
>  	pci_set_mwi(pdev);
>  	pci_write_config_dword(pdev, PCI_COMMAND, PCI_CONFIG);
> 
>  	.... configure chip-specific stuff, clear interrupts, etc.
>  	pci_enable_device(dev);

So prior to 2.6.10, you did something like this?

	request_irq(pdev->irq, ...);
	pci_write_config_byte(pdev, PCI_CACHE_LINE_SIZE, 0x08);
	pci_write_config_byte(pdev, PCI_LATENCY_TIMER, 0x40);
	...
	pci_enable_device(pdev);

What sort of interrupts does the device generate before it's
enabled?  I can't find anything in the PCI spec that actually
prohibits interrupts before the driver starts up the device,
but it does seem strange.

You wouldn't want your ISR mucking around with a half-initialized
device, so does it have to check a "device_configured" flag
or something?



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: dmesg: PCI interrupts are no longer routed automatically.........
  2005-01-05 17:13             ` Bjorn Helgaas
@ 2005-01-05 18:15               ` linux-os
  2005-01-10 21:38                 ` Bjorn Helgaas
  0 siblings, 1 reply; 11+ messages in thread
From: linux-os @ 2005-01-05 18:15 UTC (permalink / raw)
  To: Bjorn Helgaas; +Cc: David Vrabel, aryix, lug-list, Linux kernel

On Wed, 5 Jan 2005, Bjorn Helgaas wrote:

> On Wed, 2005-01-05 at 07:06 -0500, linux-os wrote:
>> The temporary work-around is....
>>  	pci_enable_device(pdev);
>>  	save_irq = pdev->irq;
>>  	pci_disable_device(pdev);	// Turn back off.
>>
>>  	init_bars(....);
>>  	request_irq(save_irq,...)	// Put ISR in place
>>
>>  	pci_write_config_byte(pdev, PCI_CACHE_LINE_SIZE, 0x08);
>>  	pci_write_config_byte(pdev, PCI_LATENCY_TIMER, 0x40);
>>  	pci_set_dma_mask(pdev, 0x00000000ffffffffULL);
>>  	pci_set_drvdata(pdev, NULL);
>>  	pci_set_power_state(pdev, 0);
>>  	pci_set_master(pdev);
>>  	pci_set_mwi(pdev);
>>  	pci_write_config_dword(pdev, PCI_COMMAND, PCI_CONFIG);
>>
>>  	.... configure chip-specific stuff, clear interrupts, etc.
>>  	pci_enable_device(dev);
>
> So prior to 2.6.10, you did something like this?
>
> 	request_irq(pdev->irq, ...);
> 	pci_write_config_byte(pdev, PCI_CACHE_LINE_SIZE, 0x08);
> 	pci_write_config_byte(pdev, PCI_LATENCY_TIMER, 0x40);
> 	...
> 	pci_enable_device(pdev);
>

Yes, exactly.

> What sort of interrupts does the device generate before it's
> enabled?  I can't find anything in the PCI spec that actually
> prohibits interrupts before the driver starts up the device,
> but it does seem strange.
>

The problem is that the PLX-9656BA INTCSR is not in configuration
space, but runtime registers off a BAR. The interrupt source
can be from a PLD that hasn't even had its microcode loaded
yet!

FYI, the PLX or similar clone is the bus interface chip for many
busmastering PCI boards.

> You wouldn't want your ISR mucking around with a half-initialized
> device, so does it have to check a "device_configured" flag
> or something?
>

Yes. If the device isn't configured, the ISR reads all the INTCSR
bits, then writes 0 to the register to prevent anything else.

If the PLX had been reset, then the INTCSR bits would all
be masked off. However, reset is really only guaranteed from
power OFF on some motherboards, in particuar the ones with
so-called "hot-swap" capabilites fail. There is a software
reset that, in fact, even reloads its serial EEPROM. However,
the BAR needs to be accessible for this to be used.

So it would be wonderful if the correct IRQ could be made
available before the chip could generate an interrupt.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips).
  Notice : All mail here is now cached for review by Dictator Bush.
                  98.36% of all statistics are fiction.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: dmesg: PCI interrupts are no longer routed automatically.........
  2005-01-05 18:15               ` linux-os
@ 2005-01-10 21:38                 ` Bjorn Helgaas
  2005-01-10 22:03                   ` linux-os
  0 siblings, 1 reply; 11+ messages in thread
From: Bjorn Helgaas @ 2005-01-10 21:38 UTC (permalink / raw)
  To: linux-os; +Cc: bjorn.helgaas, David Vrabel, aryix, lug-list, Linux kernel

On Wed, 2005-01-05 at 13:15 -0500, linux-os wrote:
> The problem is that the PLX-9656BA INTCSR is not in configuration
> space, but runtime registers off a BAR. The interrupt source
> can be from a PLD that hasn't even had its microcode loaded
> yet!
> 
> FYI, the PLX or similar clone is the bus interface chip for many
> busmastering PCI boards.
> 
> > You wouldn't want your ISR mucking around with a half-initialized
> > device, so does it have to check a "device_configured" flag
> > or something?
> 
> Yes. If the device isn't configured, the ISR reads all the INTCSR
> bits, then writes 0 to the register to prevent anything else.

The PLX might be a common device, but it sounds like this
particular issue depends on the design of the rest of the
board.  And presumably, nobody who cared about performance
would design a board with this property, right?  I mean, to
add a test in the ISR for a condition that exists only for
a few milliseconds at driver startup-time seems sub-optimal.

> If the PLX had been reset, then the INTCSR bits would all
> be masked off. However, reset is really only guaranteed from
> power OFF on some motherboards, in particuar the ones with
> so-called "hot-swap" capabilites fail. There is a software
> reset that, in fact, even reloads its serial EEPROM. However,
> the BAR needs to be accessible for this to be used.
> 
> So it would be wonderful if the correct IRQ could be made
> available before the chip could generate an interrupt.

If we exposed a new pcibios_route_irq() (to hide the arch-
specific nature of IRQ routing via ACPI or other information),
could you do what you need in a pci_fixup_early quirk?



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: dmesg: PCI interrupts are no longer routed automatically.........
  2005-01-10 21:38                 ` Bjorn Helgaas
@ 2005-01-10 22:03                   ` linux-os
  0 siblings, 0 replies; 11+ messages in thread
From: linux-os @ 2005-01-10 22:03 UTC (permalink / raw)
  To: Bjorn Helgaas; +Cc: David Vrabel, aryix, lug-list, Linux kernel

On Mon, 10 Jan 2005, Bjorn Helgaas wrote:

> On Wed, 2005-01-05 at 13:15 -0500, linux-os wrote:
>> The problem is that the PLX-9656BA INTCSR is not in configuration
>> space, but runtime registers off a BAR. The interrupt source
>> can be from a PLD that hasn't even had its microcode loaded
>> yet!
>>
>> FYI, the PLX or similar clone is the bus interface chip for many
>> busmastering PCI boards.
>>
>>> You wouldn't want your ISR mucking around with a half-initialized
>>> device, so does it have to check a "device_configured" flag
>>> or something?
>>
>> Yes. If the device isn't configured, the ISR reads all the INTCSR
>> bits, then writes 0 to the register to prevent anything else.
>
> The PLX might be a common device, but it sounds like this
> particular issue depends on the design of the rest of the
> board.  And presumably, nobody who cared about performance
> would design a board with this property, right?  I mean, to
> add a test in the ISR for a condition that exists only for
> a few milliseconds at driver startup-time seems sub-optimal.
>

I'm not so sure about that. There are many hardware registers
to be read in the ISR before the ISR can "decide" what it is
supposed to do. I'm not sure that the few hundred nanoseconds
required to read/test a variable is all the consequential.

What I do know is that the board must recover from all known
errors because you can't irradiate a patient with X-Rays and
then decide to throw away the data.

Also, like most bus-mastering devices, you only get an interrupt
to report something, basically one interrupt per transmitted
packet and one per received. There are a few diagnostic thing
that make more, but they are not common events. The 'packets'
are 10 megabytes in length so the interrupts are really hidden
in the noise. Even Ethernet drivers with their 1500 max byte
packets that use this interface chip should really check for
a "real" interrupt now that hot-swap is commonplace.

>> If the PLX had been reset, then the INTCSR bits would all
>> be masked off. However, reset is really only guaranteed from
>> power OFF on some motherboards, in particuar the ones with
>> so-called "hot-swap" capabilites fail. There is a software
>> reset that, in fact, even reloads its serial EEPROM. However,
>> the BAR needs to be accessible for this to be used.
>>
>> So it would be wonderful if the correct IRQ could be made
>> available before the chip could generate an interrupt.
>
> If we exposed a new pcibios_route_irq() (to hide the arch-
> specific nature of IRQ routing via ACPI or other information),
> could you do what you need in a pci_fixup_early quirk?
>

That would be wonderful. If you have a patch I will install
it immediately and change the content of my macro (the source-code
even compiles on 2.4.x so there are lots of macros).

Cheers,
Dick Johnson
Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips).
  Notice : All mail here is now cached for review by Dictator Bush.
                  98.36% of all statistics are fiction.

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2005-01-11  1:04 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-12-29  9:55 dmesg: PCI interrupts are no longer routed automatically aryix
2005-01-04 18:18 ` Bjorn Helgaas
2005-01-04 18:53   ` linux-os
2005-01-04 19:41     ` Bjorn Helgaas
2005-01-04 19:55       ` linux-os
2005-01-05  9:40         ` David Vrabel
2005-01-05 12:06           ` linux-os
2005-01-05 17:13             ` Bjorn Helgaas
2005-01-05 18:15               ` linux-os
2005-01-10 21:38                 ` Bjorn Helgaas
2005-01-10 22:03                   ` linux-os

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).