* irq 15: nobody cared! with KT600 chipset and 2.6.0-test9
@ 2003-11-22 23:55 Marco d'Itri
2003-11-23 1:21 ` Linus Torvalds
2003-11-23 1:59 ` Linus Torvalds
0 siblings, 2 replies; 18+ messages in thread
From: Marco d'Itri @ 2003-11-22 23:55 UTC (permalink / raw)
To: linux-kernel
This is an ASUS A7V600 motherboard, and the second IDE channel does not
work at all. I verified that it works fine with a 2.4.x kernel.
At boot time:
kernel: ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 10
kernel: ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
kernel: ACPI: PCI Interrupt Link [LNKE] enabled at IRQ 3
kernel: ACPI: PCI Interrupt Link [LNKF] enabled at IRQ 7
kernel: ACPI: PCI Interrupt Link [LNKG] enabled at IRQ 5
kernel: ACPI: PCI Interrupt Link [LNKH] enabled at IRQ 15
kernel: PCI: Using ACPI for IRQ routing
[...]
kernel: Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
kernel: ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
kernel: VIA8237SATA: IDE controller at PCI slot 0000:00:0f.0
kernel: VIA8237SATA: chipset revision 128
kernel: VIA8237SATA: 100%% native mode on irq 3
kernel: ide2: BM-DMA at 0xa000-0xa007, BIOS settings: hde:pio, hdf:pio
kernel: ide3: BM-DMA at 0xa008-0xa00f, BIOS settings: hdg:pio, hdh:pio
kernel: VP_IDE: IDE controller at PCI slot 0000:00:0f.1
kernel: VP_IDE: chipset revision 6
kernel: VP_IDE: not 100%% native mode: will probe irqs later
kernel: ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
kernel: VP_IDE: VIA vt8237 (rev 00) IDE UDMA133 controller on pci0000:00:0f.1
kernel: ide0: BM-DMA at 0x9400-0x9407, BIOS settings: hda:DMA, hdb:DMA
kernel: ide1: BM-DMA at 0x9408-0x940f, BIOS settings: hdc:DMA, hdd:DMA
kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
kernel: hdc: IRQ probe failed (0x3cfa)
kernel: hdc: CD-ROM 50X, ATAPI CD/DVD-ROM drive
kernel: hdd: 32X10, ATAPI CD/DVD-ROM drive
kernel: irq 15: nobody cared!
kernel: Call Trace:
kernel: [<c010a92b>] __report_bad_irq+0x2b/0x90
kernel: [<c010aa24>] note_interrupt+0x64/0xa0
kernel: [<c010ac2a>] do_IRQ+0xea/0xf0
kernel: [<c01092a0>] common_interrupt+0x18/0x20
kernel: [<c011d0c4>] do_softirq+0x44/0xa0
kernel: [<c010ac11>] do_IRQ+0xd1/0xf0
kernel: [<c01092a0>] common_interrupt+0x18/0x20
kernel: [<c010aff4>] setup_irq+0x64/0xb0
kernel: [<c021a730>] ide_intr+0x0/0x130
kernel: [<c010acaf>] request_irq+0x7f/0xc0
kernel: [<c021bc86>] init_irq+0x156/0x400
kernel: [<c021a730>] ide_intr+0x0/0x130
kernel: [<c021c318>] hwif_init+0xb8/0x250
kernel: [<c021b94c>] probe_hwif_init+0x2c/0x80
kernel: [<c022761a>] ide_setup_pci_device+0x7a/0x80
kernel: [<c021902d>] via_init_one+0x3d/0x50
kernel: [<c039791d>] ide_scan_pcidev+0x5d/0x70
kernel: [<c0397976>] ide_scan_pcibus+0x46/0xd0
kernel: [<c0397823>] probe_for_hwifs+0x13/0x20
kernel: [<c0397838>] ide_init_builtin_drivers+0x8/0x20
kernel: [<c0397898>] ide_init+0x48/0x70
kernel: [<c038674b>] do_initcalls+0x2b/0xa0
kernel: [<c01278b2>] init_workqueues+0x12/0x60
kernel: [<c0105097>] init+0x27/0x110
kernel: [<c0105070>] init+0x0/0x110
kernel: [<c01072a9>] kernel_thread_helper+0x5/0xc
kernel:
kernel: handlers:
kernel: [<c021a730>] (ide_intr+0x0/0x130)
kernel: Disabling IRQ #15
kernel: ide1 at 0x170-0x177,0x376 on irq 15
And trying to mount a cdrom fails:
kernel: hdc: lost interrupt
kernel: hdc: lost interrupt
kernel: irq 15: nobody cared!
kernel: Call Trace:
kernel: [<c010a92b>] __report_bad_irq+0x2b/0x90
kernel: [<c010aa24>] note_interrupt+0x64/0xa0
kernel: [<c010ac2a>] do_IRQ+0xea/0xf0
kernel: [<c01092a0>] common_interrupt+0x18/0x20
kernel: [<c021a5af>] ide_timer_expiry+0xdf/0x1b0
kernel: [<c021a4d0>] ide_timer_expiry+0x0/0x1b0
kernel: [<c0120e90>] run_timer_softirq+0xb0/0x170
kernel: [<c011d116>] do_softirq+0x96/0xa0
kernel: [<c010ac11>] do_IRQ+0xd1/0xf0
kernel: [<c0105000>] rest_init+0x0/0x30
kernel: [<c01092a0>] common_interrupt+0x18/0x20
kernel: [<c0105000>] rest_init+0x0/0x30
kernel: [<c0107066>] default_idle+0x26/0x30
kernel: [<c01070e4>] cpu_idle+0x34/0x40
kernel: [<c03866f0>] start_kernel+0x140/0x150
kernel: [<c0386480>] unknown_bootoption+0x0/0x100
kernel:
kernel: handlers:
kernel: [<c021a730>] (ide_intr+0x0/0x130)
kernel: Disabling IRQ #15
kernel: hdc: ATAPI 50X CD-ROM drive, 128kB Cache, UDMA(33)
kernel: Uniform CD-ROM driver Revision: 3.12
kernel: hdc: lost interrupt
last message repeated 2 times
kernel: irq 15: nobody cared!
kernel: Call Trace:
kernel: [<c010a92b>] __report_bad_irq+0x2b/0x90
kernel: [<c010aa24>] note_interrupt+0x64/0xa0
kernel: [<c010ac2a>] do_IRQ+0xea/0xf0
kernel: [<c01092a0>] common_interrupt+0x18/0x20
kernel: [<c010a8b0>] handle_IRQ_event+0x20/0x70
kernel: [<c010abbc>] do_IRQ+0x7c/0xf0
kernel: [<c01092a0>] common_interrupt+0x18/0x20
kernel: [<c021a5af>] ide_timer_expiry+0xdf/0x1b0
kernel: [<c021a4d0>] ide_timer_expiry+0x0/0x1b0
kernel: [<c0120e90>] run_timer_softirq+0xb0/0x170
kernel: [<c011d116>] do_softirq+0x96/0xa0
kernel: [<c010ac11>] do_IRQ+0xd1/0xf0
kernel: [<c0105000>] rest_init+0x0/0x30
kernel: [<c01092a0>] common_interrupt+0x18/0x20
kernel: [<c0105000>] rest_init+0x0/0x30
kernel: [<c0107066>] default_idle+0x26/0x30
kernel: [<c01070e4>] cpu_idle+0x34/0x40
kernel: [<c03866f0>] start_kernel+0x140/0x150
kernel: [<c0386480>] unknown_bootoption+0x0/0x100
kernel:
kernel: handlers:
kernel: [<c021a730>] (ide_intr+0x0/0x130)
kernel: Disabling IRQ #15
[...]
This also breaks a bit the mouse:
kernel: psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost synchronization, throwing 1 bytes away.
CPU0
0: 3167529 XT-PIC timer
1: 8602 XT-PIC i8042
2: 0 XT-PIC cascade
3: 0 XT-PIC uhci_hcd, uhci_hcd
5: 0 XT-PIC ehci_hcd, VIA8233
7: 1 XT-PIC uhci_hcd, uhci_hcd
8: 5 XT-PIC rtc
9: 0 XT-PIC acpi
10: 12024 XT-PIC SysKonnect SK-98xx
11: 0 XT-PIC saa7134[0]
12: 50940 XT-PIC i8042
14: 31247 XT-PIC ide0
15: 1000005 XT-PIC ide1
NMI: 0
ERR: 0
00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400 AGP] Host Bridge (rev 80)
00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge
00:09.0 Ethernet controller: 3Com Corporation 3c940 1000Base? (rev 12)
00:0a.0 Multimedia controller: Philips Semiconductors SAA7134 (rev 01)
00:0f.0 RAID bus controller: VIA Technologies, Inc.: Unknown device 3149 (rev 80)
00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE (rev 06)
00:10.0 USB Controller: VIA Technologies, Inc. USB (rev 81)
00:10.1 USB Controller: VIA Technologies, Inc. USB (rev 81)
00:10.2 USB Controller: VIA Technologies, Inc. USB (rev 81)
00:10.3 USB Controller: VIA Technologies, Inc. USB (rev 81)
00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86)
00:10.5 Network controller: VIA Technologies, Inc.: Unknown device d104
00:11.0 ISA bridge: VIA Technologies, Inc.: Unknown device 3227
00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235 AC97 Audio Controller (rev 60)
01:00.0 VGA compatible controller: ATI Technologies Inc: Unknown device 5964 (rev 01)
01:00.1 Display controller: ATI Technologies Inc: Unknown device 5d44 (rev 01)
----------VIA BusMastering IDE Configuration----------------
Driver Version: 3.38
South Bridge: VIA vt8237
Revision: ISA 0x0 IDE 0x6
Highest DMA rate: UDMA133
BM-DMA base: 0x9400
PCI clock: 33.3MHz
Master Read Cycle IRDY: 0ws
Master Write Cycle IRDY: 0ws
BM IDE Status Register Read Retry: yes
Max DRDY Pulse Width: No limit
-----------------------Primary IDE-------Secondary IDE------
Read DMA FIFO flush: yes yes
End Sector FIFO flush: no no
Prefetch Buffer: yes no
Post Write Buffer: yes no
Enabled: yes yes
Simplex only: no no
Cable Type: 80w 80w
-------------------drive0----drive1----drive2----drive3-----
Transfer Mode: UDMA UDMA UDMA DMA
Address Setup: 120ns 120ns 120ns 120ns
Cmd Active: 90ns 90ns 90ns 90ns
Cmd Recovery: 30ns 30ns 30ns 30ns
Data Active: 90ns 90ns 90ns 90ns
Data Recovery: 30ns 30ns 30ns 30ns
Cycle Time: 15ns 15ns 60ns 120ns
Transfer Rate: 133.3MB/s 133.3MB/s 33.3MB/s 16.6MB/s
--
ciao, |
Marco | [3229 stHRfBoYMcR9Y]
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: irq 15: nobody cared! with KT600 chipset and 2.6.0-test9 2003-11-22 23:55 irq 15: nobody cared! with KT600 chipset and 2.6.0-test9 Marco d'Itri @ 2003-11-23 1:21 ` Linus Torvalds 2003-11-23 1:59 ` Linus Torvalds 1 sibling, 0 replies; 18+ messages in thread From: Linus Torvalds @ 2003-11-23 1:21 UTC (permalink / raw) To: Marco d'Itri; +Cc: linux-kernel On Sun, 23 Nov 2003, Marco d'Itri wrote: > > This is an ASUS A7V600 motherboard, and the second IDE channel does not > work at all. I verified that it works fine with a 2.4.x kernel. Can you enable DEBUG in "arch/i386/pci/pci.h" and ACPI debugging and then report what the system says at bootup both with ACPI enabled, and with "pci=noacpi". For some reason the system decides that your IDE controller is on irq3, which is clearly wrong. It's on irq15, but somebody told the PCI layer otherwise. Linus ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: irq 15: nobody cared! with KT600 chipset and 2.6.0-test9 2003-11-22 23:55 irq 15: nobody cared! with KT600 chipset and 2.6.0-test9 Marco d'Itri 2003-11-23 1:21 ` Linus Torvalds @ 2003-11-23 1:59 ` Linus Torvalds 2003-11-23 2:15 ` Marco d'Itri 1 sibling, 1 reply; 18+ messages in thread From: Linus Torvalds @ 2003-11-23 1:59 UTC (permalink / raw) To: Marco d'Itri; +Cc: Kernel Mailing List, Bartlomiej Zolnierkiewicz Oops. I read your report lazily, and didn't do it right. I just noticed that it isn't actually irq3 and the raid controller at 0:0f.0 that is the problem at all: the problem is the regular legacy stuff on 0:0f.1: hdc/hdd that is on irq15. The IRQ probe for hdc fails, for some silly reason. But we actually correctly _notice_ that it's on irq15, so I Note how we say: kernel: hdc: IRQ probe failed (0x3cfa) but then a few lines later we _have_ figured it out and say kernel: ide1 at 0x170-0x177,0x376 on irq 15 The problem _appears_ to be the fact that we already registered irq15 for the IDE driver, which will cause the probe to fail (you can't probe something that is already in use). Can you try this patch, and see if it makes a difference? I'd also like to see the full "dmesg" output (regardless of whether it works or not). Linus ----- ===== drivers/ide/ide-probe.c 1.65 vs edited ===== --- 1.65/drivers/ide/ide-probe.c Wed Sep 3 09:52:16 2003 +++ edited/drivers/ide/ide-probe.c Sat Nov 22 17:59:04 2003 @@ -413,24 +413,17 @@ udelay(5); irq = probe_irq_off(cookie); if (!hwif->irq) { - if (irq > 0) { - hwif->irq = irq; - } else { - /* Mmmm.. multiple IRQs.. - * don't know which was ours - */ - printk("%s: IRQ probe failed (0x%lx)\n", - drive->name, cookie); -#ifdef CONFIG_BLK_DEV_CMD640 -#ifdef CMD640_DUMP_REGS - if (hwif->chipset == ide_cmd640) { - printk("%s: Hmmm.. probably a driver " - "problem.\n", drive->name); - CMD640_DUMP_REGS; - } -#endif /* CMD640_DUMP_REGS */ -#endif /* CONFIG_BLK_DEV_CMD640 */ + /* Mmmm.. multiple IRQs, and we don't know + * which was ours. We'd better guess. + */ + if (irq <= 0) { + int guess = hwif->channel ? 15 : 14; + + printk("%s: IRQ probe failed (0x%lx: %d). Guessing at %d\n", + drive->name, cookie, irq, guess); + irq = guess; } + hwif->irq = irq; } } return retval; ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: irq 15: nobody cared! with KT600 chipset and 2.6.0-test9 2003-11-23 1:59 ` Linus Torvalds @ 2003-11-23 2:15 ` Marco d'Itri 2003-11-23 3:24 ` Linus Torvalds 0 siblings, 1 reply; 18+ messages in thread From: Marco d'Itri @ 2003-11-23 2:15 UTC (permalink / raw) To: Linus Torvalds; +Cc: Kernel Mailing List, Bartlomiej Zolnierkiewicz On Nov 23, Linus Torvalds <torvalds@osdl.org> wrote: >The problem _appears_ to be the fact that we already registered irq15 for >the IDE driver, which will cause the probe to fail (you can't probe >something that is already in use). > >Can you try this patch, and see if it makes a difference? I'd also like to >see the full "dmesg" output (regardless of whether it works or not). It does not. This is the output with your patch applied and PCI debugging enabled: klogd 1.4.1#11, log source = /proc/kmsg started. k highmem) Calibrating delay loop... 2875.39 BogoMIPS Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: After generic identify, caps: 0383fbff c1cbfbff 00000000 00000000 CPU: After vendor identify, caps: 0383fbff c1cbfbff 00000000 00000000 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) CPU: After all inits, caps: 0383fbff c1cbfbff 00000000 00000020 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: AMD Athlon(TM) MP 1700+ stepping 02 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX NET: Registered protocol family 16 PCI: BIOS32 Service Directory structure at 0xc00f2000 PCI: BIOS32 Service Directory entry at 0xf1940 PCI: BIOS probe returned s=00 hw=11 ver=02.10 l=01 PCI: PCI BIOS revision 2.10 entry at 0xf1970, last bus=1 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20031002 tbxface-0117 [03] acpi_load_tables : ACPI Tables successfully acquired Parsing all Control Methods:............................................................................................................................ Table [DSDT](id F004) - 363 Objects with 50 Devices 124 Methods 19 Regions ACPI Namespace successfully loaded at root c03b30bc ACPI: IRQ 9 was Edge Triggered, setting to Level Triggerd evxfevnt-0093 [04] acpi_enable : Transition to ACPI mode successful evgpeblk-0748 [06] ev_create_gpe_block : GPE 00 to 15 [_GPE] 2 regs at 000000000000E420 on int 9 Completing Region/Field/Buffer/Package initialization:....................................................... Initialized 19/19 Regions 2/2 Fields 23/23 Buffers 11/11 Packages (371 nodes) Executing all Device _STA and_INI methods:................................................... 51 Devices found containing: 51 _STA, 1 _INI methods ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 11 12) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 11 12) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 11 12) ACPI: PCI Interrupt Link [LNKE] (IRQs *3 4 5 6 7 9 10 11 12) ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 *7 9 10 11 12) ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 *5 6 7 9 10 11 12) ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 11 12) ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) PCI: IDE base address fixup for 0000:00:0f.1 PCI: Scanning for ghost devices on bus 0 PCI: Scanning for ghost devices on bus 1 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT] Linux Plug and Play Support v0.97 (c) Adam Belay PnPBIOS: Scanning system for PnP BIOS support... PnPBIOS: Found PnP BIOS installation structure at 0xc00fa100 PnPBIOS: PnP BIOS version 1.0, entry 0xf0000:0xa130, dseg 0xf0000 PnPBIOS: 12 nodes reported by PnP BIOS; 12 recorded by driver ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 10 -> edgeACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11 ACPI: PCI Interrupt Link [LNKE] enabled at IRQ 3 ACPI: PCI Interrupt Link [LNKF] enabled at IRQ 7 ACPI: PCI Interrupt Link [LNKG] enabled at IRQ 5 ACPI: PCI Interrupt Link [LNKH] enabled at IRQ 15 -> edge<6>PCI: Using ACPI for IRQ routing PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off' PCI: IRQ init PCI: Allocating resources PCI: Resource f0000000-f7ffffff (f=1208, d=0, p=0) PCI: Resource 0000b400-0000b407 (f=101, d=0, p=0) PCI: Resource 0000b000-0000b003 (f=101, d=0, p=0) PCI: Resource 0000a800-0000a807 (f=101, d=0, p=0) PCI: Resource 0000a400-0000a403 (f=101, d=0, p=0) PCI: Resource 0000a000-0000a00f (f=101, d=0, p=0) PCI: Resource 00009800-000098ff (f=101, d=0, p=0) PCI: Resource 00009400-0000940f (f=101, d=0, p=0) PCI: Resource 00009000-0000901f (f=101, d=0, p=0) PCI: Resource 00008800-0000881f (f=101, d=0, p=0) PCI: Resource 00008400-0000841f (f=101, d=0, p=0) PCI: Resource 00008000-0000801f (f=101, d=0, p=0) PCI: Resource d5800000-d58000ff (f=200, d=0, p=0) PCI: Resource 0000e000-0000e0ff (f=101, d=0, p=0) PCI: Resource e8000000-efffffff (f=1208, d=0, p=0) PCI: Resource 0000d800-0000d8ff (f=101, d=0, p=0) PCI: Resource d7800000-d780ffff (f=200, d=0, p=0) PCI: Resource d6800000-d6803fff (f=200, d=1, p=1) PCI: Resource 0000b800-0000b8ff (f=101, d=1, p=1) PCI: Resource d6000000-d60003ff (f=200, d=1, p=1) PCI: Resource d5000000-d50000ff (f=200, d=1, p=1) PCI: Resource d8000000-dfffffff (f=1208, d=1, p=1) PCI: Resource d7000000-d700ffff (f=200, d=1, p=1) PCI: Sorting device list... SBF: Simple Boot Flag extension found and enabled. SBF: Setting boot flags 0x80 Machine check exception polling timer started. devfs: v1.22 (20021013) Richard Gooch (rgooch@atnf.csiro.au) devfs: boot_options: 0x0 Initializing Cryptographic API ACPI: Power Button (FF) [PWRF] ACPI: Processor [CPU0] (supports C1) pty: 256 Unix98 ptys configured Real Time Clock Driver v1.12 Serial: 8250/16550 driver $Revision: 1.90 $ 6 ports, IRQ sharing disabled ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VIA8237SATA: IDE controller at PCI slot 0000:00:0f.0 VIA8237SATA: chipset revision 128 VIA8237SATA: 100%% native mode on irq 3 ide2: BM-DMA at 0xa000-0xa007, BIOS settings: hde:pio, hdf:pio ide3: BM-DMA at 0xa008-0xa00f, BIOS settings: hdg:pio, hdh:pio VP_IDE: IDE controller at PCI slot 0000:00:0f.1 VP_IDE: chipset revision 6 VP_IDE: not 100%% native mode: will probe irqs later ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: VIA vt8237 (rev 00) IDE UDMA133 controller on pci0000:00:0f.1 ide0: BM-DMA at 0x9400-0x9407, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0x9408-0x940f, BIOS settings: hdc:DMA, hdd:DMA hda: Maxtor 6Y080P0, ATA DISK drive hdb: MAXTOR 6L040J2, ATA DISK drive Using anticipatory io scheduler ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hdc: IRQ probe failed (0x3cfa: 0). Guessing at 15 hdc: CD-ROM 50X, ATAPI CD/DVD-ROM drive hdd: 32X10, ATAPI CD/DVD-ROM drive irq 15: nobody cared! Call Trace: [<c010a92b>] __report_bad_irq+0x2b/0x90 [<c010aa24>] note_interrupt+0x64/0xa0 [<c010ac2a>] do_IRQ+0xea/0xf0 [<c01092a0>] common_interrupt+0x18/0x20 [<c011d0c4>] do_softirq+0x44/0xa0 [<c010ac11>] do_IRQ+0xd1/0xf0 [<c01092a0>] common_interrupt+0x18/0x20 [<c010aff4>] setup_irq+0x64/0xb0 [<c021a730>] ide_intr+0x0/0x130 [<c010acaf>] request_irq+0x7f/0xc0 [<c021bca6>] init_irq+0x156/0x400 [<c021a730>] ide_intr+0x0/0x130 [<c021c336>] hwif_init+0xb6/0x250 [<c021b96c>] probe_hwif_init+0x2c/0x80 [<c022765a>] ide_setup_pci_device+0x7a/0x80 [<c021902d>] via_init_one+0x3d/0x50 [<c039791d>] ide_scan_pcidev+0x5d/0x70 [<c0397976>] ide_scan_pcibus+0x46/0xd0 [<c0397823>] probe_for_hwifs+0x13/0x20 [<c0397838>] ide_init_builtin_drivers+0x8/0x20 [<c0397898>] ide_init+0x48/0x70 [<c038674b>] do_initcalls+0x2b/0xa0 [<c01278b2>] init_workqueues+0x12/0x60 [<c0105097>] init+0x27/0x110 [<c0105070>] init+0x0/0x110 [<c01072a9>] kernel_thread_helper+0x5/0xc handlers: [<c021a730>] (ide_intr+0x0/0x130) Disabling IRQ #15 ide1 at 0x170-0x177,0x376 on irq 15 hda: max request size: 128KiB hda: 160086528 sectors (81964 MB) w/7936KiB Cache, CHS=65535/16/63, UDMA(133) /dev/ide/host0/bus0/target0/lun0: p1 p2 p3 < p5 p6 p7 p8 p9 p10 p11 > hdb: max request size: 128KiB hdb: 78177792 sectors (40027 MB) w/1820KiB Cache, CHS=65535/16/63, UDMA(133) /dev/ide/host0/bus0/target1/lun0: p1 p2 p3 p4 < p5 p6 p7 p8 p9 > mice: PS/2 mouse device common for all mice serio: i8042 AUX port at 0x60,0x64 irq 12 input: AT Translated Set 2 keyboard on isa0060/serio0 serio: i8042 KBD port at 0x60,0x64 irq 1 md: raid1 personality registered as nr 3 md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27 device-mapper: 4.0.0-ioctl (2003-06-04) initialised: dm@uk.sistina.com NET: Registered protocol family 2 IP: routing cache hash table of 4096 buckets, 32Kbytes TCP: Hash tables configured (established 32768 bind 65536) Initializing IPsec netlink socket NET: Registered protocol family 1 NET: Registered protocol family 10 IPv6 over IPv4 tunneling driver NET: Registered protocol family 15 BIOS EDD facility v0.10 2003-Oct-11, 2 devices found Please report your BIOS at http://domsch.com/linux/edd30/results.html Before receiving your second message I tried booting with pci=noacpi and it worked: Linux version 2.6.0-test9 (md@Knoppix) (gcc version 3.3.2 20030831 (Debian prerelease)) #0 Sun Oct 19 21:15:05 CEST 2003 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000001fffc000 (usable) BIOS-e820: 000000001fffc000 - 000000001ffff000 (ACPI data) BIOS-e820: 000000001ffff000 - 0000000020000000 (ACPI NVS) BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved) BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved) 511MB LOWMEM available. On node 0 totalpages: 131068 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 126972 pages, LIFO batch:16 HighMem zone: 0 pages, LIFO batch:1 DMI 2.3 present. ACPI: RSDP (v000 ASUS ) @ 0x000f62a0 ACPI: RSDT (v001 ASUS A7V600 0x42302e31 MSFT 0x31313031) @ 0x1fffc000 ACPI: FADT (v001 ASUS A7V600 0x42302e31 MSFT 0x31313031) @ 0x1fffc0b2 ACPI: BOOT (v001 ASUS A7V600 0x42302e31 MSFT 0x31313031) @ 0x1fffc030 ACPI: MADT (v001 ASUS A7V600 0x42302e31 MSFT 0x31313031) @ 0x1fffc058 ACPI: DSDT (v001 ASUS A7V600 0x00001000 MSFT 0x0100000b) @ 0x00000000 Building zonelist for node : 0 Kernel command line: reboot=warm root=/dev/md0 pci=noacpi init=/bin/bash Initializing CPU#0 PID hash table entries: 2048 (order 11: 16384 bytes) Detected 1459.817 MHz processor. Console: colour VGA+ 80x25 Memory: 515396k/524272k available (1818k kernel code, 8080k reserved, 753k data, 124k init, 0k highmem) Calibrating delay loop... 2875.39 BogoMIPS Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: After generic identify, caps: 0383fbff c1cbfbff 00000000 00000000 CPU: After vendor identify, caps: 0383fbff c1cbfbff 00000000 00000000 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) CPU: After all inits, caps: 0383fbff c1cbfbff 00000000 00000020 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: AMD Athlon(TM) MP 1700+ stepping 02 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX NET: Registered protocol family 16 PCI: BIOS32 Service Directory structure at 0xc00f2000 PCI: BIOS32 Service Directory entry at 0xf1940 PCI: BIOS probe returned s=00 hw=11 ver=02.10 l=01 PCI: PCI BIOS revision 2.10 entry at 0xf1970, last bus=1 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20031002 tbxface-0117 [03] acpi_load_tables : ACPI Tables successfully acquired Parsing all Control Methods:............................................................................................................................ Table [DSDT](id F004) - 363 Objects with 50 Devices 124 Methods 19 Regions ACPI Namespace successfully loaded at root c03b30bc ACPI: IRQ 9 was Edge Triggered, setting to Level Triggerd evxfevnt-0093 [04] acpi_enable : Transition to ACPI mode successful evgpeblk-0748 [06] ev_create_gpe_block : GPE 00 to 15 [_GPE] 2 regs at 000000000000E420 on int 9 Completing Region/Field/Buffer/Package initialization:....................................................... Initialized 19/19 Regions 2/2 Fields 23/23 Buffers 11/11 Packages (371 nodes) Executing all Device _STA and_INI methods:................................................... 51 Devices found containing: 51 _STA, 1 _INI methods ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 11 12) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 11 12) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 11 12) ACPI: PCI Interrupt Link [LNKE] (IRQs *3 4 5 6 7 9 10 11 12) ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 *7 9 10 11 12) ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 *5 6 7 9 10 11 12) ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 11 12) ACPI: PCI Root Bridge [PCI0] (00:00) PCI: Probing PCI hardware (bus 00) PCI: IDE base address fixup for 0000:00:0f.1 PCI: Scanning for ghost devices on bus 0 PCI: Scanning for ghost devices on bus 1 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT] Linux Plug and Play Support v0.97 (c) Adam Belay PnPBIOS: Scanning system for PnP BIOS support... PnPBIOS: Found PnP BIOS installation structure at 0xc00fa100 PnPBIOS: PnP BIOS version 1.0, entry 0xf0000:0xa130, dseg 0xf0000 PnPBIOS: 12 nodes reported by PnP BIOS; 12 recorded by driver PCI: Probing PCI hardware PCI: Peer bridge fixup PCI: IRQ init PCI: Interrupt Routing Table found at 0xc00f1f20 00:09 slot=00 0:03/1eb8 1:00/1eb8 2:00/1eb8 3:00/1eb8 00:0c slot=01 0:05/1eb8 1:01/1eb8 2:02/1eb8 3:03/1eb8 00:0d slot=02 0:01/1eb8 1:02/1eb8 2:03/1eb8 3:05/1eb8 00:0e slot=03 0:02/1eb8 1:03/1eb8 2:05/1eb8 3:01/1eb8 00:13 slot=04 0:03/1eb8 1:05/1eb8 2:01/1eb8 3:02/1eb8 00:0b slot=05 0:05/1eb8 1:01/1eb8 2:02/1eb8 3:03/1eb8 00:0a slot=06 0:01/1eb8 1:02/1eb8 2:03/1eb8 3:05/1eb8 01:00 slot=07 0:01/1eb8 1:02/1eb8 2:00/1eb8 3:00/1eb8 00:0f slot=00 0:06/1eb8 1:07/1eb8 2:00/1eb8 3:00/1eb8 00:10 slot=00 0:06/1eb8 1:07/1eb8 2:08/1eb8 3:09/1eb8 00:11 slot=00 0:00/1eb8 1:00/1eb8 2:08/1eb8 3:09/1eb8 PCI: Attempting to find IRQ router for 1106:0586 PCI: Using IRQ router VIA [1106/3227] at 0000:00:11.0 PCI: IRQ fixup 0000:00:09.0: ignoring bogus IRQ 255 0000:00:0a.0: ignoring bogus IRQ 255 0000:00:0f.1: ignoring bogus IRQ 255 0000:00:10.5: ignoring bogus IRQ 255 IRQ for 0000:00:09.0:0 -> PIRQ 03, mask 1eb8, excl 0000<4>PCI: IRQ 0 for device 0000:00:09.0 doesn't match PIRQ mask - try pci=usepirqmask -> newirq=0 ... failed IRQ for 0000:00:0a.0:0 -> PIRQ 01, mask 1eb8, excl 0000<4>PCI: IRQ 0 for device 0000:00:0a.0 doesn't match PIRQ mask - try pci=usepirqmask -> newirq=0 -> got IRQ 11 PCI: Found IRQ 11 for device 0000:00:0a.0 PCI: Sharing IRQ 11 with 0000:01:00.0 IRQ for 0000:00:0f.1:0 -> PIRQ 06, mask 1eb8, excl 0000<4>PCI: IRQ 0 for device 0000:00:0f.1 doesn't match PIRQ mask - try pci=usepirqmask -> newirq=0 -> got IRQ 3 PCI: Found IRQ 3 for device 0000:00:0f.1 PCI: Sharing IRQ 3 with 0000:00:0f.0 PCI: Sharing IRQ 3 with 0000:00:10.0 PCI: Sharing IRQ 3 with 0000:00:10.1 IRQ for 0000:00:10.5:3 -> PIRQ 09, mask 1eb8, excl 0000<4>PCI: IRQ 0 for device 0000:00:10.5 doesn't match PIRQ mask - try pci=usepirqmask -> newirq=0 -> got IRQ 9 PCI: Found IRQ 9 for device 0000:00:10.5 PCI: Allocating resources PCI: Resource f0000000-f7ffffff (f=1208, d=0, p=0) PCI: Resource 0000b400-0000b407 (f=101, d=0, p=0) PCI: Resource 0000b000-0000b003 (f=101, d=0, p=0) PCI: Resource 0000a800-0000a807 (f=101, d=0, p=0) PCI: Resource 0000a400-0000a403 (f=101, d=0, p=0) PCI: Resource 0000a000-0000a00f (f=101, d=0, p=0) PCI: Resource 00009800-000098ff (f=101, d=0, p=0) PCI: Resource 00009400-0000940f (f=101, d=0, p=0) PCI: Resource 00009000-0000901f (f=101, d=0, p=0) PCI: Resource 00008800-0000881f (f=101, d=0, p=0) PCI: Resource 00008400-0000841f (f=101, d=0, p=0) PCI: Resource 00008000-0000801f (f=101, d=0, p=0) PCI: Resource d5800000-d58000ff (f=200, d=0, p=0) PCI: Resource 0000e000-0000e0ff (f=101, d=0, p=0) PCI: Resource e8000000-efffffff (f=1208, d=0, p=0) PCI: Resource 0000d800-0000d8ff (f=101, d=0, p=0) PCI: Resource d7800000-d780ffff (f=200, d=0, p=0) PCI: Resource d6800000-d6803fff (f=200, d=1, p=1) PCI: Resource 0000b800-0000b8ff (f=101, d=1, p=1) PCI: Resource d6000000-d60003ff (f=200, d=1, p=1) PCI: Resource d5000000-d50000ff (f=200, d=1, p=1) PCI: Resource d8000000-dfffffff (f=1208, d=1, p=1) PCI: Resource d7000000-d700ffff (f=200, d=1, p=1) PCI: Sorting device list... SBF: Simple Boot Flag extension found and enabled. SBF: Setting boot flags 0x80 Machine check exception polling timer started. devfs: v1.22 (20021013) Richard Gooch (rgooch@atnf.csiro.au) devfs: boot_options: 0x0 Initializing Cryptographic API ACPI: Power Button (FF) [PWRF] ACPI: Processor [CPU0] (supports C1) pty: 256 Unix98 ptys configured Real Time Clock Driver v1.12 Serial: 8250/16550 driver $Revision: 1.90 $ 6 ports, IRQ sharing disabled ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VIA8237SATA: IDE controller at PCI slot 0000:00:0f.0 IRQ for 0000:00:0f.0:0 -> PIRQ 06, mask 1eb8, excl 0000 -> newirq=3 -> got IRQ 3PCI: Found IRQ 3 for device 0000:00:0f.0 PCI: Sharing IRQ 3 with 0000:00:0f.1 PCI: Sharing IRQ 3 with 0000:00:10.0 PCI: Sharing IRQ 3 with 0000:00:10.1 VIA8237SATA: chipset revision 128 VIA8237SATA: 100% native mode on irq 3 ide2: BM-DMA at 0xa000-0xa007, BIOS settings: hde:pio, hdf:pio ide3: BM-DMA at 0xa008-0xa00f, BIOS settings: hdg:pio, hdh:pio VP_IDE: IDE controller at PCI slot 0000:00:0f.1 IRQ for 0000:00:0f.1:0 -> PIRQ 06, mask 1eb8, excl 0000 -> newirq=3 -> got IRQ 3PCI: Found IRQ 3 for device 0000:00:0f.1 PCI: Sharing IRQ 3 with 0000:00:0f.0 PCI: Sharing IRQ 3 with 0000:00:10.0 PCI: Sharing IRQ 3 with 0000:00:10.1 VP_IDE: chipset revision 6 VP_IDE: not 100% native mode: will probe irqs later ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: VIA vt8237 (rev 00) IDE UDMA133 controller on pci0000:00:0f.1 ide0: BM-DMA at 0x9400-0x9407, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0x9408-0x940f, BIOS settings: hdc:DMA, hdd:DMA hda: Maxtor 6Y080P0, ATA DISK drive hdb: MAXTOR 6L040J2, ATA DISK drive Using anticipatory io scheduler ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hdc: CD-ROM 50X, ATAPI CD/DVD-ROM drive hdd: 32X10, ATAPI CD/DVD-ROM drive ide1 at 0x170-0x177,0x376 on irq 15 hda: max request size: 128KiB hda: 160086528 sectors (81964 MB) w/7936KiB Cache, CHS=65535/16/63, UDMA(133) /dev/ide/host0/bus0/target0/lun0: p1 p2 p3 < p5 p6 p7 p8 p9 p10 p11 > hdb: max request size: 128KiB hdb: 78177792 sectors (40027 MB) w/1820KiB Cache, CHS=65535/16/63, UDMA(133) /dev/ide/host0/bus0/target1/lun0: p1 p2 p3 p4 < p5 p6 p7 p8 p9 > -- ciao, | Marco | [3231 omfANXwAx0hcc] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: irq 15: nobody cared! with KT600 chipset and 2.6.0-test9 2003-11-23 2:15 ` Marco d'Itri @ 2003-11-23 3:24 ` Linus Torvalds 2003-11-23 5:49 ` Len Brown 2003-11-23 11:40 ` Marco d'Itri 0 siblings, 2 replies; 18+ messages in thread From: Linus Torvalds @ 2003-11-23 3:24 UTC (permalink / raw) To: Marco d'Itri Cc: Kernel Mailing List, Bartlomiej Zolnierkiewicz, Len Brown On Sun, 23 Nov 2003, Marco d'Itri wrote: > > It does not. This is the output with your patch applied and PCI > debugging enabled: Thanks. This is interesting. Looking at the IRQ probing output: > hdc: IRQ probe failed (0x3cfa: 0). Guessing at 15 The interesting parts are the 0x3cfa and the 0: - the "0" means that we literally didn't see any interrupt at all during the autoprobing. Sometimes autoprobing fails because we see _multiple_ interrupts, but that wasn't the case here. - 0x3cfa is the "probe cookie", which tells which irq's were free to be probed. That's 1, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13 and what's interesting is that irq 15 wasn't even probed at all (14 wasn't either, but that's easy to explain: we took that when we probed and registered ide channel 0 earlier. irq 0 and 2 are special - timer and cascade respectively). So for some reason irq 15 has already been reserved. Somebody has already registered IRQ 15 _before_ we probe for it for that hwif. And: > irq 15: nobody cared! > Call Trace: > [ ... ] > handlers: > [<c021a730>] (ide_intr+0x0/0x130) this shows that the claimer of the irq is the IDE layer itself. But why has the IDE layer already claimed that interrupt? > Before receiving your second message I tried booting with pci=noacpi and > it worked: Interesting and good in the sense that this is another clue. Why does ACPI interrupt routing cause the IDE layer to register irq 15 too early? Both the PIRQ routing code and the ACPI code give irq3 to the other IDE chip. So why has the IDE stuff registered _another_ irq15 earlier? I don't see it.. Len, Bartlomiej, do you see anything? Marco, can you try this appended (very very stupid) patch with ACPI on, so that we can see where irq15 gets registered? It won't fix anything, but I'm confused by why IRQ 15 has been registered before we probe for it.. Thanks, Linus --- ===== arch/i386/kernel/irq.c 1.45 vs edited ===== --- 1.45/arch/i386/kernel/irq.c Wed Oct 22 20:26:34 2003 +++ edited/arch/i386/kernel/irq.c Sat Nov 22 19:22:20 2003 @@ -569,6 +569,8 @@ if (!action) return -ENOMEM; + WARN_ON(irq == 15); + action->handler = handler; action->flags = irqflags; action->mask = 0; ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: irq 15: nobody cared! with KT600 chipset and 2.6.0-test9 2003-11-23 3:24 ` Linus Torvalds @ 2003-11-23 5:49 ` Len Brown 2003-11-23 11:40 ` Marco d'Itri 1 sibling, 0 replies; 18+ messages in thread From: Len Brown @ 2003-11-23 5:49 UTC (permalink / raw) To: Linus Torvalds Cc: Marco d'Itri, Kernel Mailing List, Bartlomiej Zolnierkiewicz Was ACPI enabled on the version of 2.4 that worked? If yes, I'd like to see the 2.4 dmesg and /proc/interrupts. [BTW Marco, If you collect a lot of info related to this failure, please be encouraged to attach it to a bug report -- http://bugzilla.kernel.org/ Category: Power Management, Component: ACPI -- the output from acpidmp would be helpful] > noapic This will have no effect -- we're already in PIC mode. I don't know anything about the ide layer probing interrupts, but this one is an interesting case at the low level. > ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 11 12) Here the BIOS gives us a lot of possible choices for where to send LNKH, but the list does not include 15. > ACPI: PCI Interrupt Link [LNKH] enabled at IRQ 15 > -> edge<6>PCI: Using ACPI for IRQ routing Here we program LNKH to 15, which means the BIOS told us it was already active on 15 -- there's no way we would have selected 15 based on the list of possibles above. Then we set the interrupt to level triggered -- as we do with all PCI interrupts. This may be a bad assumption -- though we do exactly the same thing in 2.4... In any case, Marco, perhaps you can try this quick hack to skip that setting for 15 and perhaps that will add a clue. thanks, -Len ===== drivers/acpi/pci_irq.c 1.22 vs edited ===== --- 1.22/drivers/acpi/pci_irq.c Tue Sep 9 06:24:14 2003 +++ edited/drivers/acpi/pci_irq.c Sun Nov 23 00:15:52 2003 @@ -372,7 +372,7 @@ * Make sure all (legacy) PCI IRQs are set as level-triggered. */ #ifdef CONFIG_X86 - if ((dev->irq < 16) && !((1 << dev->irq) & irq_mask)) { + if ((dev->irq < 15) && !((1 << dev->irq) & irq_mask)) { ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Setting IRQ %d as level-triggered\n", dev->irq)); irq_mask |= (1 << dev->irq); eisa_set_level_irq(dev->irq); On Sat, 2003-11-22 at 22:24, Linus Torvalds wrote: > On Sun, 23 Nov 2003, Marco d'Itri wrote: > > > > It does not. This is the output with your patch applied and PCI > > debugging enabled: > > Thanks. This is interesting. Looking at the IRQ probing output: > > > hdc: IRQ probe failed (0x3cfa: 0). Guessing at 15 > > The interesting parts are the 0x3cfa and the 0: > - the "0" means that we literally didn't see any interrupt at all during > the autoprobing. Sometimes autoprobing fails because we see _multiple_ > interrupts, but that wasn't the case here. > - 0x3cfa is the "probe cookie", which tells which irq's were free to be > probed. That's > > 1, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13 > > and what's interesting is that irq 15 wasn't even probed at all (14 > wasn't either, but that's easy to explain: we took that when we probed > and registered ide channel 0 earlier. irq 0 and 2 are special - timer > and cascade respectively). > > So for some reason irq 15 has already been reserved. Somebody has already > registered IRQ 15 _before_ we probe for it for that hwif. And: > > > irq 15: nobody cared! > > Call Trace: > > [ ... ] > > handlers: > > [<c021a730>] (ide_intr+0x0/0x130) > > this shows that the claimer of the irq is the IDE layer itself. > > But why has the IDE layer already claimed that interrupt? > > > Before receiving your second message I tried booting with pci=noacpi and > > it worked: > > Interesting and good in the sense that this is another clue. Why does ACPI > interrupt routing cause the IDE layer to register irq 15 too early? > > Both the PIRQ routing code and the ACPI code give irq3 to the other IDE > chip. So why has the IDE stuff registered _another_ irq15 earlier? > > I don't see it.. Len, Bartlomiej, do you see anything? > > Marco, can you try this appended (very very stupid) patch with ACPI on, so > that we can see where irq15 gets registered? It won't fix anything, but > I'm confused by why IRQ 15 has been registered before we probe for it.. > > Thanks, > > Linus > > --- > ===== arch/i386/kernel/irq.c 1.45 vs edited ===== > --- 1.45/arch/i386/kernel/irq.c Wed Oct 22 20:26:34 2003 > +++ edited/arch/i386/kernel/irq.c Sat Nov 22 19:22:20 2003 > @@ -569,6 +569,8 @@ > if (!action) > return -ENOMEM; > > + WARN_ON(irq == 15); > + > action->handler = handler; > action->flags = irqflags; > action->mask = 0; > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: irq 15: nobody cared! with KT600 chipset and 2.6.0-test9 2003-11-23 3:24 ` Linus Torvalds 2003-11-23 5:49 ` Len Brown @ 2003-11-23 11:40 ` Marco d'Itri 2003-11-23 16:40 ` Linus Torvalds 1 sibling, 1 reply; 18+ messages in thread From: Marco d'Itri @ 2003-11-23 11:40 UTC (permalink / raw) To: Linus Torvalds Cc: Kernel Mailing List, Bartlomiej Zolnierkiewicz, Len Brown, Andi Kleen On Nov 23, Linus Torvalds <torvalds@osdl.org> wrote: >Marco, can you try this appended (very very stupid) patch with ACPI on, so >that we can see where irq15 gets registered? It won't fix anything, but >I'm confused by why IRQ 15 has been registered before we probe for it.. ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hdc: IRQ probe failed (0x3cfa: 0). Guessing at 15 hdc: CD-ROM 50X, ATAPI CD/DVD-ROM drive hdd: 32X10, ATAPI CD/DVD-ROM drive Badness in request_irq at arch/i386/kernel/irq.c:572 Call Trace: [<c021a770>] ide_intr+0x0/0x130 [<c010acfc>] request_irq+0xcc/0x100 [<c021bce6>] init_irq+0x156/0x400 [<c021a770>] ide_intr+0x0/0x130 [<c021c376>] hwif_init+0xb6/0x250 [<c021b9ac>] probe_hwif_init+0x2c/0x80 [<c022769a>] ide_setup_pci_device+0x7a/0x80 [<c021906d>] via_init_one+0x3d/0x50 [<c039791d>] ide_scan_pcidev+0x5d/0x70 [<c0397976>] ide_scan_pcibus+0x46/0xd0 [<c0397823>] probe_for_hwifs+0x13/0x20 [<c0397838>] ide_init_builtin_drivers+0x8/0x20 [<c0397898>] ide_init+0x48/0x70 [<c038674b>] do_initcalls+0x2b/0xa0 [<c01278f2>] init_workqueues+0x12/0x60 [<c0105097>] init+0x27/0x110 [<c0105070>] init+0x0/0x110 [<c01072a9>] kernel_thread_helper+0x5/0xc irq 15: nobody cared! [...] -- ciao, | Marco | [3234 aln71JMBJj/2g] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: irq 15: nobody cared! with KT600 chipset and 2.6.0-test9 2003-11-23 11:40 ` Marco d'Itri @ 2003-11-23 16:40 ` Linus Torvalds 2003-11-23 18:52 ` Marco d'Itri 0 siblings, 1 reply; 18+ messages in thread From: Linus Torvalds @ 2003-11-23 16:40 UTC (permalink / raw) To: Marco d'Itri Cc: Kernel Mailing List, Bartlomiej Zolnierkiewicz, Len Brown, Andi Kleen On Sun, 23 Nov 2003, Marco d'Itri wrote: > > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > hdc: IRQ probe failed (0x3cfa: 0). Guessing at 15 > hdc: CD-ROM 50X, ATAPI CD/DVD-ROM drive > hdd: 32X10, ATAPI CD/DVD-ROM drive > Badness in request_irq at arch/i386/kernel/irq.c:572 > Call Trace: > [<c021a770>] ide_intr+0x0/0x130 There was nothing before this? The probe failed _before_ the first warning? If so, that means that the probing didn't try IRQ 15 for some other reason than it already being requested for a device. That other reason is most likely that IRQ 15 was "screaming" when the IRQ probe already started, which would have made the irq probing turn it off. So something in the ACPI code made IRQ15 active, or caused there to be a pending interrupt. I'd guess that ACPI incorrectly turns the legacy IDE interrupts to be PCI interrupts (level-triggered, active low) instead of legacy interrupts (edge-triggered, active high). But I also have to admit that the IDE irq probing code looks a bit fragile. We could be more careful about making sure that the IDE controller has its interrupt turned off before we start probing. So a patch like this might be in order - it should just make autoprobing a bit more robust. Does this one make a difference? Len - does ACPI ever change the polarity of an interrupt? Just turning the irq level-triggered shouldn't matter that much, but if some part of ACPI switches polarities around (and gets the wrong one) that would be deadly and would cause screaming interrupts when no event is pending. Linus ----- ===== drivers/ide/ide-probe.c 1.65 vs edited ===== --- 1.65/drivers/ide/ide-probe.c Wed Sep 3 09:52:16 2003 +++ edited/drivers/ide/ide-probe.c Sun Nov 23 08:35:37 2003 @@ -393,13 +393,19 @@ */ if (IDE_CONTROL_REG) { u8 ctl = drive->ctl | 2; + hwif->OUTB(ctl, IDE_CONTROL_REG); + + /* Clear drive IRQ */ + (void) hwif->INB(IDE_STATUS_REG); + udelay(5); + if (!hwif->irq) { autoprobe = 1; cookie = probe_irq_on(); /* enable device irq */ ctl &= ~2; + hwif->OUTB(ctl, IDE_CONTROL_REG); } - hwif->OUTB(ctl, IDE_CONTROL_REG); } retval = actual_try_to_identify(drive, cmd); ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: irq 15: nobody cared! with KT600 chipset and 2.6.0-test9 2003-11-23 16:40 ` Linus Torvalds @ 2003-11-23 18:52 ` Marco d'Itri 2003-11-23 19:12 ` Linus Torvalds 0 siblings, 1 reply; 18+ messages in thread From: Marco d'Itri @ 2003-11-23 18:52 UTC (permalink / raw) To: Linus Torvalds Cc: Kernel Mailing List, Bartlomiej Zolnierkiewicz, Len Brown, Andi Kleen On Nov 23, Linus Torvalds <torvalds@osdl.org> wrote: >On Sun, 23 Nov 2003, Marco d'Itri wrote: >> >> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 >> hdc: IRQ probe failed (0x3cfa: 0). Guessing at 15 >> hdc: CD-ROM 50X, ATAPI CD/DVD-ROM drive >> hdd: 32X10, ATAPI CD/DVD-ROM drive >> Badness in request_irq at arch/i386/kernel/irq.c:572 >> Call Trace: >> [<c021a770>] ide_intr+0x0/0x130 > >There was nothing before this? > >The probe failed _before_ the first warning? Yes. >Does this one make a difference? No: ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VIA8237SATA: IDE controller at PCI slot 0000:00:0f.0 VIA8237SATA: chipset revision 128 VIA8237SATA: 100%% native mode on irq 3 ide2: BM-DMA at 0xa000-0xa007, BIOS settings: hde:pio, hdf:pio ide3: BM-DMA at 0xa008-0xa00f, BIOS settings: hdg:pio, hdh:pio VP_IDE: IDE controller at PCI slot 0000:00:0f.1 VP_IDE: chipset revision 6 VP_IDE: not 100%% native mode: will probe irqs later ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: VIA vt8237 (rev 00) IDE UDMA133 controller on pci0000:00:0f.1 ide0: BM-DMA at 0x9400-0x9407, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0x9408-0x940f, BIOS settings: hdc:DMA, hdd:DMA hda: Maxtor 6Y080P0, ATA DISK drive hdb: MAXTOR 6L040J2, ATA DISK drive Using anticipatory io scheduler ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hdc: CD-ROM 50X, ATAPI CD/DVD-ROM drive hdd: 32X10, ATAPI CD/DVD-ROM drive Badness in request_irq at arch/i386/kernel/irq.c:572 Call Trace: [<c021a770>] ide_intr+0x0/0x130 [<c010acfc>] request_irq+0xcc/0x100 [<c021bd06>] init_irq+0x156/0x400 [<c021a770>] ide_intr+0x0/0x130 [<c021c398>] hwif_init+0xb8/0x250 [<c021b9cc>] probe_hwif_init+0x2c/0x80 [<c022769a>] ide_setup_pci_device+0x7a/0x80 [<c021906d>] via_init_one+0x3d/0x50 [<c039791d>] ide_scan_pcidev+0x5d/0x70 [<c0397976>] ide_scan_pcibus+0x46/0xd0 [<c0397823>] probe_for_hwifs+0x13/0x20 [<c0397838>] ide_init_builtin_drivers+0x8/0x20 [<c0397898>] ide_init+0x48/0x70 [<c038674b>] do_initcalls+0x2b/0xa0 [<c01278f2>] init_workqueues+0x12/0x60 [<c0105097>] init+0x27/0x110 [<c0105070>] init+0x0/0x110 [<c01072a9>] kernel_thread_helper+0x5/0xc irq 15: nobody cared! Call Trace: [<c010a92b>] __report_bad_irq+0x2b/0x90 [<c010aa24>] note_interrupt+0x64/0xa0 [<c010ac2a>] do_IRQ+0xea/0xf0 [<c01092a0>] common_interrupt+0x18/0x20 [<c011d104>] do_softirq+0x44/0xa0 [<c010ac11>] do_IRQ+0xd1/0xf0 [<c01092a0>] common_interrupt+0x18/0x20 [<c010b034>] setup_irq+0x64/0xb0 [<c021a770>] ide_intr+0x0/0x130 [<c010acb9>] request_irq+0x89/0x100 [<c021bd06>] init_irq+0x156/0x400 [<c021a770>] ide_intr+0x0/0x130 [<c021c398>] hwif_init+0xb8/0x250 [<c021b9cc>] probe_hwif_init+0x2c/0x80 [<c022769a>] ide_setup_pci_device+0x7a/0x80 [<c021906d>] via_init_one+0x3d/0x50 [<c039791d>] ide_scan_pcidev+0x5d/0x70 [<c0397976>] ide_scan_pcibus+0x46/0xd0 [<c0397823>] probe_for_hwifs+0x13/0x20 [<c0397838>] ide_init_builtin_drivers+0x8/0x20 [<c0397898>] ide_init+0x48/0x70 [<c038674b>] do_initcalls+0x2b/0xa0 [<c01278f2>] init_workqueues+0x12/0x60 [<c0105097>] init+0x27/0x110 [<c0105070>] init+0x0/0x110 [<c01072a9>] kernel_thread_helper+0x5/0xc handlers: [<c021a770>] (ide_intr+0x0/0x130) Disabling IRQ #15 ide1 at 0x170-0x177,0x376 on irq 15 hda: max request size: 128KiB hda: 160086528 sectors (81964 MB) w/7936KiB Cache, CHS=65535/16/63, UDMA(133) /dev/ide/host0/bus0/target0/lun0: p1 p2 p3 < p5 p6 p7 p8 p9 p10 p11 > hdb: max request size: 128KiB hdb: 78177792 sectors (40027 MB) w/1820KiB Cache, CHS=65535/16/63, UDMA(133) /dev/ide/host0/bus0/target1/lun0: p1 p2 p3 p4 < p5 p6 p7 p8 p9 > -- ciao, | Marco | [3237 agt8As3FpLsEE] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: irq 15: nobody cared! with KT600 chipset and 2.6.0-test9 2003-11-23 18:52 ` Marco d'Itri @ 2003-11-23 19:12 ` Linus Torvalds 2003-11-23 19:41 ` Marco d'Itri 0 siblings, 1 reply; 18+ messages in thread From: Linus Torvalds @ 2003-11-23 19:12 UTC (permalink / raw) To: Marco d'Itri Cc: Kernel Mailing List, Bartlomiej Zolnierkiewicz, Len Brown, Andi Kleen On Sun, 23 Nov 2003, Marco d'Itri wrote: > >Does this one make a difference? > No: Actually, it _does_ seem to make a difference. The irq probe doesn't report failure any more: > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > hdc: CD-ROM 50X, ATAPI CD/DVD-ROM drive > hdd: 32X10, ATAPI CD/DVD-ROM drive > Badness in request_irq at arch/i386/kernel/irq.c:572 so now we have happily apparently probed the irq, but the problem is that it continues to scream afterwards. So we're still unhappy, but something did actually change. I wonder why ACPI matters. It must be changing the polarity or trigger of the irq somehow - but your earlier dmesg output seems to imply that it only changes ELCR for irq9, so it must be somewhere else. Len, ideas? Also, Marco, it might actually be a VIA IDE driver bug, that leaves the interrupt on during setup somewhere (and the bug just doesn't matter when the IRQ is edge-triggered). So it would be interesting to know what happens if you disable the VIA-specific IDE support... (Btw, thanks for being so good at testing, despite the lack of major progress). Linus ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: irq 15: nobody cared! with KT600 chipset and 2.6.0-test9 2003-11-23 19:12 ` Linus Torvalds @ 2003-11-23 19:41 ` Marco d'Itri 0 siblings, 0 replies; 18+ messages in thread From: Marco d'Itri @ 2003-11-23 19:41 UTC (permalink / raw) To: Linus Torvalds Cc: Kernel Mailing List, Bartlomiej Zolnierkiewicz, Len Brown, Andi Kleen On Nov 23, Linus Torvalds <torvalds@osdl.org> wrote: >Also, Marco, it might actually be a VIA IDE driver bug, that leaves the >interrupt on during setup somewhere (and the bug just doesn't matter when >the IRQ is edge-triggered). So it would be interesting to know what >happens if you disable the VIA-specific IDE support... Nothing I can see. I will now open a bugzilla ticket as requested by Len. Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VIA8237SATA: IDE controller at PCI slot 0000:00:0f.0 VIA8237SATA: chipset revision 128 VIA8237SATA: 100%% native mode on irq 3 ide2: BM-DMA at 0xa000-0xa007, BIOS settings: hde:pio, hdf:pio ide3: BM-DMA at 0xa008-0xa00f, BIOS settings: hdg:pio, hdh:pio hda: Maxtor 6Y080P0, ATA DISK drive hdb: MAXTOR 6L040J2, ATA DISK drive hdc: CD-ROM 50X, ATAPI CD/DVD-ROM drive hdd: 32X10, ATAPI CD/DVD-ROM drive Using anticipatory io scheduler ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Badness in request_irq at arch/i386/kernel/irq.c:572 Call Trace: [<c0219c30>] ide_intr+0x0/0x130 [<c010ae0c>] request_irq+0xcc/0x100 [<c021b1c6>] init_irq+0x156/0x400 [<c0219c30>] ide_intr+0x0/0x130 [<c021b858>] hwif_init+0xb8/0x250 [<c01753c0>] init_file+0x0/0x20 [<c021bae4>] ideprobe_init+0xf4/0x106 [<c0398c7d>] ide_init_builtin_drivers+0xd/0x20 [<c0398cd8>] ide_init+0x48/0x70 [<c038679b>] do_initcalls+0x2b/0xa0 [<c01285b2>] init_workqueues+0x12/0x60 [<c010509c>] init+0x2c/0x110 [<c0105070>] init+0x0/0x110 [<c01072a9>] kernel_thread_helper+0x5/0xc irq 15: nobody cared! Call Trace: [<c010aa3b>] __report_bad_irq+0x2b/0x90 [<c010ab34>] note_interrupt+0x64/0xa0 [<c010ad3a>] do_IRQ+0xea/0xf0 [<c01092a0>] common_interrupt+0x18/0x20 [<c011ddc4>] do_softirq+0x44/0xa0 [<c010ad21>] do_IRQ+0xd1/0xf0 [<c01092a0>] common_interrupt+0x18/0x20 [<c010b144>] setup_irq+0x64/0xb0 [<c0219c30>] ide_intr+0x0/0x130 [<c010adc9>] request_irq+0x89/0x100 [<c021b1c6>] init_irq+0x156/0x400 [<c0219c30>] ide_intr+0x0/0x130 [<c021b858>] hwif_init+0xb8/0x250 [<c01753c0>] init_file+0x0/0x20 [<c021bae4>] ideprobe_init+0xf4/0x106 [<c0398c7d>] ide_init_builtin_drivers+0xd/0x20 [<c0398cd8>] ide_init+0x48/0x70 [<c038679b>] do_initcalls+0x2b/0xa0 [<c01285b2>] init_workqueues+0x12/0x60 [<c010509c>] init+0x2c/0x110 [<c0105070>] init+0x0/0x110 [<c01072a9>] kernel_thread_helper+0x5/0xc handlers: [<c0219c30>] (ide_intr+0x0/0x130) Disabling IRQ #15 ide1 at 0x170-0x177,0x376 on irq 15 hda: max request size: 128KiB hda: 160086528 sectors (81964 MB) w/7936KiB Cache, CHS=65535/16/63 /dev/ide/host0/bus0/target0/lun0: p1 p2 p3 < p5 p6 p7 p8 p9 p10 p11 > hdb: max request size: 128KiB hdb: 78177792 sectors (40027 MB) w/1820KiB Cache, CHS=65535/16/63 /dev/ide/host0/bus0/target1/lun0: p1 p2 p3 p4 < p5 p6 p7 p8 p9 > -- ciao, | Marco | [3238 gere5SFl/jVj6] ^ permalink raw reply [flat|nested] 18+ messages in thread
* RE: irq 15: nobody cared! with KT600 chipset and 2.6.0-test9 @ 2003-11-23 19:16 Brown, Len 0 siblings, 0 replies; 18+ messages in thread From: Brown, Len @ 2003-11-23 19:16 UTC (permalink / raw) To: Linus Torvalds, Marco d'Itri Cc: Kernel Mailing List, Bartlomiej Zolnierkiewicz, Andi Kleen > So something in the ACPI code made IRQ15 active, or caused > there to be a > pending interrupt. I'd guess that ACPI incorrectly turns the > legacy IDE > interrupts to be PCI interrupts (level-triggered, active low) > instead of > legacy interrupts (edge-triggered, active high). I think so too. > Len - does ACPI ever change the polarity of an interrupt? > Just turning the > irq level-triggered shouldn't matter that much, but if some > part of ACPI > switches polarities around (and gets the wrong one) that > would be deadly > and would cause screaming interrupts when no event is pending. I think that PCI Interrupt Link Devices were originally intended to map PIRQs down into PIC IRQs with standard PCI semantics -- obsoleting the bogus chip-set specific PIRQ router "standard". But the BIOS can ask us to do just about anything, and I'm finding that some system designers and BIOS writers have become much more creative in their use;-) Marco, Please file a bug per below and attach the output of acpidmp and lspci -v with full dmesg so I can decode what the BIOS is really asking us to do. Perhaps you can also add the dmesg and /proc/interrupts from the version of 2.4 that worked. I'm puzzled at what 2.6-specific change provoked this failure. Thanks, -Len How to file a bug against ACPI: http://bugzilla.kernel.org/ Category: Power Management Component: ACPI Please attach the output from acpidmp, available in /usr/sbin/, or in here http://www.intel.com/technology/iapc/acpi/downloads/pmtools-20010730.tar .gz Please attach /proc/interrupts, lspci -v and the dmesg output showing the failure, if possible. ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <UPPL.70W.11@gated-at.bofh.it>]
[parent not found: <UReK.uF.5@gated-at.bofh.it>]
* Re: irq 15: nobody cared! with KT600 chipset and 2.6.0-test9 [not found] ` <UReK.uF.5@gated-at.bofh.it> @ 2003-11-23 3:39 ` Andi Kleen 2003-11-23 4:23 ` Linus Torvalds 0 siblings, 1 reply; 18+ messages in thread From: Andi Kleen @ 2003-11-23 3:39 UTC (permalink / raw) To: Linus Torvalds; +Cc: md, linux-kernel Linus Torvalds <torvalds@osdl.org> writes: > On Sun, 23 Nov 2003, Marco d'Itri wrote: >> >> This is an ASUS A7V600 motherboard, and the second IDE channel does not >> work at all. I verified that it works fine with a 2.4.x kernel. > > Can you enable DEBUG in "arch/i386/pci/pci.h" and ACPI debugging and then > report what the system says at bootup both with ACPI enabled, and with > "pci=noacpi". > > For some reason the system decides that your IDE controller is on irq3, > which is clearly wrong. It's on irq15, but somebody told the PCI layer > otherwise. It's a long standing bug in how we handle VIA on board devices in ACPI. It was a big problem on x86-64 too until I cheated and used only PIC mode when there is a VIA southbridge. Basically VIA has very specific rules on what interrupts can be assigned to the onboard devices and they use an unusual ACPI construct for that See http://bugme.osdl.org/show_bug.cgi?id=1530 for some more details. (the same problem applies to 2.6 afaik) Here's also some older description from VIA about the issues I saved: >> 1) The _SRS method can only cope with IRQs <= 15 if SB is before VT8233. After VT8235, _SRS method need not report IRQ for internal devices due to they are +hardwired to fixed IRQ in APIC mode. [AK: that is one problem with the ACPI code - it doesn't handle that the _SRS report doesn't report it. Even ignoring the problems with older SBs which would need some special handling code] The BIOS returns fixed IRQs in the _PRS method when system is in APIC mode if SB is after +VT8235. (IDE-IRQ20, USB-IRQ21, Audio and Modem-IRQ22, LAN-IRQ23) 2) The _CRS method is hardcoded to return 0 ALWAYS for link devices in APIC mode. We feel strange for this situation. This control method will check internal device's +interrupt line (Rx3C of PCI configuration) to return current IRQ setting. Will it be possible in Linux kernel driver which will reset the Rx3C to zero ? << Forcing PIC mode will at least make it work. Of course it would be better to fix the ACPI code to handle all this properly. -Andi ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: irq 15: nobody cared! with KT600 chipset and 2.6.0-test9 2003-11-23 3:39 ` Andi Kleen @ 2003-11-23 4:23 ` Linus Torvalds 2003-11-23 5:10 ` Andi Kleen 0 siblings, 1 reply; 18+ messages in thread From: Linus Torvalds @ 2003-11-23 4:23 UTC (permalink / raw) To: Andi Kleen; +Cc: md, linux-kernel On Sun, 23 Nov 2003, Andi Kleen wrote: > > It's a long standing bug in how we handle VIA on board devices in ACPI. > It was a big problem on x86-64 too until I cheated and used only > PIC mode when there is a VIA southbridge. That doesn't explain the lack of autodetection, and the early irq15 registration. That would explain why no interrupts make it at all, but why do we not even probe for irq15 here? Linus ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: irq 15: nobody cared! with KT600 chipset and 2.6.0-test9 2003-11-23 4:23 ` Linus Torvalds @ 2003-11-23 5:10 ` Andi Kleen 2003-11-23 10:29 ` Marco d'Itri 0 siblings, 1 reply; 18+ messages in thread From: Andi Kleen @ 2003-11-23 5:10 UTC (permalink / raw) To: Linus Torvalds; +Cc: Andi Kleen, md, linux-kernel On Sat, Nov 22, 2003 at 08:23:16PM -0800, Linus Torvalds wrote: > > On Sun, 23 Nov 2003, Andi Kleen wrote: > > > > It's a long standing bug in how we handle VIA on board devices in ACPI. > > It was a big problem on x86-64 too until I cheated and used only > > PIC mode when there is a VIA southbridge. > > That doesn't explain the lack of autodetection, and the early irq15 > registration. > > That would explain why no interrupts make it at all, but why do we not > even probe for irq15 here? It's easy to test. does it work when booted with "noapic" ? -Andi ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: irq 15: nobody cared! with KT600 chipset and 2.6.0-test9 2003-11-23 5:10 ` Andi Kleen @ 2003-11-23 10:29 ` Marco d'Itri 0 siblings, 0 replies; 18+ messages in thread From: Marco d'Itri @ 2003-11-23 10:29 UTC (permalink / raw) To: Andi Kleen; +Cc: Linus Torvalds, Andi Kleen, linux-kernel, len.brown On Nov 23, Andi Kleen <ak@colin2.muc.de> wrote: >On Sat, Nov 22, 2003 at 08:23:16PM -0800, Linus Torvalds wrote: >> >> On Sun, 23 Nov 2003, Andi Kleen wrote: >> > >> > It's a long standing bug in how we handle VIA on board devices in ACPI. >> > It was a big problem on x86-64 too until I cheated and used only >> > PIC mode when there is a VIA southbridge. >> >> That doesn't explain the lack of autodetection, and the early irq15 >> registration. >> >> That would explain why no interrupts make it at all, but why do we not >> even probe for irq15 here? > >It's easy to test. does it work when booted with "noapic" ? Yes, I checked again. -- ciao, | Marco | [3232 ma6tjQg3wBT1w] ^ permalink raw reply [flat|nested] 18+ messages in thread
* irq 15: nobody cared! with KT600 chipset and 2.6.0-test9
@ 2003-11-15 10:43 Marco d'Itri
2003-11-16 11:13 ` Marco d'Itri
0 siblings, 1 reply; 18+ messages in thread
From: Marco d'Itri @ 2003-11-15 10:43 UTC (permalink / raw)
To: linux-kernel
kernel: ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 10
kernel: ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
kernel: ACPI: PCI Interrupt Link [LNKE] enabled at IRQ 3
kernel: ACPI: PCI Interrupt Link [LNKF] enabled at IRQ 7
kernel: ACPI: PCI Interrupt Link [LNKG] enabled at IRQ 5
kernel: ACPI: PCI Interrupt Link [LNKH] enabled at IRQ 15
kernel: PCI: Using ACPI for IRQ routing
[...]
kernel: Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
kernel: ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
kernel: VIA8237SATA: IDE controller at PCI slot 0000:00:0f.0
kernel: VIA8237SATA: chipset revision 128
kernel: VIA8237SATA: 100%% native mode on irq 3
kernel: ide2: BM-DMA at 0xa000-0xa007, BIOS settings: hde:pio, hdf:pio
kernel: ide3: BM-DMA at 0xa008-0xa00f, BIOS settings: hdg:pio, hdh:pio
kernel: VP_IDE: IDE controller at PCI slot 0000:00:0f.1
kernel: VP_IDE: chipset revision 6
kernel: VP_IDE: not 100%% native mode: will probe irqs later
kernel: ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
kernel: VP_IDE: VIA vt8237 (rev 00) IDE UDMA133 controller on pci0000:00:0f.1
kernel: ide0: BM-DMA at 0x9400-0x9407, BIOS settings: hda:DMA, hdb:DMA
kernel: ide1: BM-DMA at 0x9408-0x940f, BIOS settings: hdc:DMA, hdd:DMA
kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
kernel: hdc: IRQ probe failed (0x3cfa)
kernel: hdc: CD-ROM 50X, ATAPI CD/DVD-ROM drive
kernel: hdd: 32X10, ATAPI CD/DVD-ROM drive
kernel: irq 15: nobody cared!
kernel: Call Trace:
kernel: [<c010a92b>] __report_bad_irq+0x2b/0x90
kernel: [<c010aa24>] note_interrupt+0x64/0xa0
kernel: [<c010ac2a>] do_IRQ+0xea/0xf0
kernel: [<c01092a0>] common_interrupt+0x18/0x20
kernel: [<c011d0c4>] do_softirq+0x44/0xa0
kernel: [<c010ac11>] do_IRQ+0xd1/0xf0
kernel: [<c01092a0>] common_interrupt+0x18/0x20
kernel: [<c010aff4>] setup_irq+0x64/0xb0
kernel: [<c021a730>] ide_intr+0x0/0x130
kernel: [<c010acaf>] request_irq+0x7f/0xc0
kernel: [<c021bc86>] init_irq+0x156/0x400
kernel: [<c021a730>] ide_intr+0x0/0x130
kernel: [<c021c318>] hwif_init+0xb8/0x250
kernel: [<c021b94c>] probe_hwif_init+0x2c/0x80
kernel: [<c022761a>] ide_setup_pci_device+0x7a/0x80
kernel: [<c021902d>] via_init_one+0x3d/0x50
kernel: [<c039791d>] ide_scan_pcidev+0x5d/0x70
kernel: [<c0397976>] ide_scan_pcibus+0x46/0xd0
kernel: [<c0397823>] probe_for_hwifs+0x13/0x20
kernel: [<c0397838>] ide_init_builtin_drivers+0x8/0x20
kernel: [<c0397898>] ide_init+0x48/0x70
kernel: [<c038674b>] do_initcalls+0x2b/0xa0
kernel: [<c01278b2>] init_workqueues+0x12/0x60
kernel: [<c0105097>] init+0x27/0x110
kernel: [<c0105070>] init+0x0/0x110
kernel: [<c01072a9>] kernel_thread_helper+0x5/0xc
kernel:
kernel: handlers:
kernel: [<c021a730>] (ide_intr+0x0/0x130)
kernel: Disabling IRQ #15
kernel: ide1 at 0x170-0x177,0x376 on irq 15
Trying to mount a cdrom fails:
kernel: hdc: lost interrupt
kernel: hdc: lost interrupt
kernel: irq 15: nobody cared!
kernel: Call Trace:
kernel: [<c010a92b>] __report_bad_irq+0x2b/0x90
kernel: [<c010aa24>] note_interrupt+0x64/0xa0
kernel: [<c010ac2a>] do_IRQ+0xea/0xf0
kernel: [<c01092a0>] common_interrupt+0x18/0x20
kernel: [<c021a5af>] ide_timer_expiry+0xdf/0x1b0
kernel: [<c021a4d0>] ide_timer_expiry+0x0/0x1b0
kernel: [<c0120e90>] run_timer_softirq+0xb0/0x170
kernel: [<c011d116>] do_softirq+0x96/0xa0
kernel: [<c010ac11>] do_IRQ+0xd1/0xf0
kernel: [<c0105000>] rest_init+0x0/0x30
kernel: [<c01092a0>] common_interrupt+0x18/0x20
kernel: [<c0105000>] rest_init+0x0/0x30
kernel: [<c0107066>] default_idle+0x26/0x30
kernel: [<c01070e4>] cpu_idle+0x34/0x40
kernel: [<c03866f0>] start_kernel+0x140/0x150
kernel: [<c0386480>] unknown_bootoption+0x0/0x100
kernel:
kernel: handlers:
kernel: [<c021a730>] (ide_intr+0x0/0x130)
kernel: Disabling IRQ #15
kernel: hdc: ATAPI 50X CD-ROM drive, 128kB Cache, UDMA(33)
kernel: Uniform CD-ROM driver Revision: 3.12
kernel: hdc: lost interrupt
last message repeated 2 times
kernel: irq 15: nobody cared!
kernel: Call Trace:
kernel: [<c010a92b>] __report_bad_irq+0x2b/0x90
kernel: [<c010aa24>] note_interrupt+0x64/0xa0
kernel: [<c010ac2a>] do_IRQ+0xea/0xf0
kernel: [<c01092a0>] common_interrupt+0x18/0x20
kernel: [<c010a8b0>] handle_IRQ_event+0x20/0x70
kernel: [<c010abbc>] do_IRQ+0x7c/0xf0
kernel: [<c01092a0>] common_interrupt+0x18/0x20
kernel: [<c021a5af>] ide_timer_expiry+0xdf/0x1b0
kernel: [<c021a4d0>] ide_timer_expiry+0x0/0x1b0
kernel: [<c0120e90>] run_timer_softirq+0xb0/0x170
kernel: [<c011d116>] do_softirq+0x96/0xa0
kernel: [<c010ac11>] do_IRQ+0xd1/0xf0
kernel: [<c0105000>] rest_init+0x0/0x30
kernel: [<c01092a0>] common_interrupt+0x18/0x20
kernel: [<c0105000>] rest_init+0x0/0x30
kernel: [<c0107066>] default_idle+0x26/0x30
kernel: [<c01070e4>] cpu_idle+0x34/0x40
kernel: [<c03866f0>] start_kernel+0x140/0x150
kernel: [<c0386480>] unknown_bootoption+0x0/0x100
kernel:
kernel: handlers:
kernel: [<c021a730>] (ide_intr+0x0/0x130)
kernel: Disabling IRQ #15
[...]
And it also breaks a bit the mouse:
kernel: psmouse.c: Wheel Mouse at isa0060/serio1/input0 lost synchronization, throwing 1 bytes away.
CPU0
0: 3167529 XT-PIC timer
1: 8602 XT-PIC i8042
2: 0 XT-PIC cascade
3: 0 XT-PIC uhci_hcd, uhci_hcd
5: 0 XT-PIC ehci_hcd, VIA8233
7: 1 XT-PIC uhci_hcd, uhci_hcd
8: 5 XT-PIC rtc
9: 0 XT-PIC acpi
10: 12024 XT-PIC SysKonnect SK-98xx
11: 0 XT-PIC saa7134[0]
12: 50940 XT-PIC i8042
14: 31247 XT-PIC ide0
15: 1000005 XT-PIC ide1
NMI: 0
ERR: 0
This is an ASUS A7V600 motherboard.
00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400 AGP] Host Bridge (rev 80)
00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge
00:09.0 Ethernet controller: 3Com Corporation 3c940 1000Base? (rev 12)
00:0a.0 Multimedia controller: Philips Semiconductors SAA7134 (rev 01)
00:0f.0 RAID bus controller: VIA Technologies, Inc.: Unknown device 3149 (rev 80)
00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE (rev 06)
00:10.0 USB Controller: VIA Technologies, Inc. USB (rev 81)
00:10.1 USB Controller: VIA Technologies, Inc. USB (rev 81)
00:10.2 USB Controller: VIA Technologies, Inc. USB (rev 81)
00:10.3 USB Controller: VIA Technologies, Inc. USB (rev 81)
00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86)
00:10.5 Network controller: VIA Technologies, Inc.: Unknown device d104
00:11.0 ISA bridge: VIA Technologies, Inc.: Unknown device 3227
00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235 AC97 Audio Controller (rev 60)
01:00.0 VGA compatible controller: ATI Technologies Inc: Unknown device 5964 (rev 01)
01:00.1 Display controller: ATI Technologies Inc: Unknown device 5d44 (rev 01)
--
ciao, |
Marco | [3062 cavlf5SFtruTs]
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: irq 15: nobody cared! with KT600 chipset and 2.6.0-test9 2003-11-15 10:43 Marco d'Itri @ 2003-11-16 11:13 ` Marco d'Itri 0 siblings, 0 replies; 18+ messages in thread From: Marco d'Itri @ 2003-11-16 11:13 UTC (permalink / raw) To: linux-kernel On Nov 15, Marco d'Itri <md@Linux.IT> wrote: >This is an ASUS A7V600 motherboard. I verified that it works fine with a 2.4.x kernel. -- ciao, | Marco | [3076 ruo6xtkZ/r.TQ] ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2003-11-23 19:53 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-11-22 23:55 irq 15: nobody cared! with KT600 chipset and 2.6.0-test9 Marco d'Itri
2003-11-23 1:21 ` Linus Torvalds
2003-11-23 1:59 ` Linus Torvalds
2003-11-23 2:15 ` Marco d'Itri
2003-11-23 3:24 ` Linus Torvalds
2003-11-23 5:49 ` Len Brown
2003-11-23 11:40 ` Marco d'Itri
2003-11-23 16:40 ` Linus Torvalds
2003-11-23 18:52 ` Marco d'Itri
2003-11-23 19:12 ` Linus Torvalds
2003-11-23 19:41 ` Marco d'Itri
-- strict thread matches above, loose matches on Subject: below --
2003-11-23 19:16 Brown, Len
[not found] <UPPL.70W.11@gated-at.bofh.it>
[not found] ` <UReK.uF.5@gated-at.bofh.it>
2003-11-23 3:39 ` Andi Kleen
2003-11-23 4:23 ` Linus Torvalds
2003-11-23 5:10 ` Andi Kleen
2003-11-23 10:29 ` Marco d'Itri
2003-11-15 10:43 Marco d'Itri
2003-11-16 11:13 ` Marco d'Itri
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.