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]
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
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;
On Nov 23, Linus Torvalds <[email protected]> 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 ([email protected])
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: [email protected]
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 ([email protected])
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]
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;
Linus Torvalds <[email protected]> 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
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
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
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;
>
On Nov 23, Andi Kleen <[email protected]> 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]
On Nov 23, Linus Torvalds <[email protected]> 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]
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);
On Nov 23, Linus Torvalds <[email protected]> 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]
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
> 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.
On Nov 23, Linus Torvalds <[email protected]> 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]