[2.6.18-rc4][ACPI] System with ACPI 1.0 deadlocks when adding Elsa Gloria XL PCI video card

[Shawn Starr <shawn.starr@rogers.com>]

I managed to obtain a 'new' old PCI video card and decided to drop it into the old IBM 300PL machine which has ACPI version 1.0 only:

The moment I enable ACPI in the bios and boot the kernel with ACPI on, it attempts to load the ACPI interpreter, then hangs hard.

At first, the system was hanging in the BIOS, or during initial boot, my initial investigation  I figured I was somehow exceeding the systems power (the PCI Video card is rather huge and sucks a lot of juice) so I removed some ISA/PCI cards hoping to stop the hanging. 
That worked, but ACPI was still causing the system to deadlock on boot. Turning off ACPI, I'm able to use the system fine, even when putting heavy load onto the machine voltage levels (says sensors) remain OK.  It still however
hangs in BIOS when changing any settings (if i hard power off, the settings are still accepted, I think that's a BIOS bug).

I know ACPI 1.0 is very old now, but what I am noticing is older hardware is starting to trip weird oddities in ACPI (at least with legacy versions).

Whilst ACPI was off the kernel threw a nasty IRQ handler mismatch

[   72.940301] IRQ handler type mismatch for IRQ 14
[   72.940911]  [<c0103d3e>] show_trace_log_lvl+0x15e/0x190
[   72.941083]  [<c010448f>] show_trace+0xf/0x20
[   72.941233]  [<c0104555>] dump_stack+0x15/0x20
[   72.941385]  [<c0137cf7>] setup_irq+0xb7/0x1b0
[   72.941868]  [<c0137e93>] request_irq+0xa3/0xc0
[   72.942349]  [<c0221f99>] serial8250_startup+0x409/0x430
[   72.944365]  [<c021d888>] uart_startup+0x48/0x140
[   72.945862]  [<c021e6ae>] uart_open+0xbe/0x440
[   72.947347]  [<c020a610>] tty_open+0x170/0x340
[   72.948766]  [<c01609e9>] chrdev_open+0x89/0x170
[   72.949438]  [<c0156533>] __dentry_open+0xb3/0x1f0
[   72.950049]  [<c0156725>] nameidata_to_filp+0x35/0x40
[   72.950653]  [<c015677b>] do_filp_open+0x4b/0x60
[   72.951257]  [<c01567da>] do_sys_open+0x4a/0xe0
[   72.951860]  [<c01568ac>] sys_open+0x1c/0x20
[   72.952463]  [<c0102c91>] sysenter_past_esp+0x56/0x79
[   72.952602]  [<b7f11410>] 0xb7f11410
[   72.952706]  [<c0137cf7>] setup_irq+0xb7/0x1b0
[   72.952815]  [<c0154b8a>] kmem_cache_alloc+0x5a/0xa0
[   72.952926]  [<c0222040>] serial8250_interrupt+0x0/0x110
[   72.953036]  [<c0137e93>] request_irq+0xa3/0xc0
[   72.953146]  [<c0221f99>] serial8250_startup+0x409/0x430
[   72.953258]  [<c021d888>] uart_startup+0x48/0x140
[   72.953373]  [<c021e6ae>] uart_open+0xbe/0x440
[   72.953483]  [<c0206867>] check_tty_count+0x47/0xb0
[   72.953594]  [<c020a610>] tty_open+0x170/0x340
[   72.953703]  [<c01609e9>] chrdev_open+0x89/0x170
[   72.953812]  [<c0160960>] chrdev_open+0x0/0x170
[   72.953920]  [<c0156533>] __dentry_open+0xb3/0x1f0
[   72.954029]  [<c0156725>] nameidata_to_filp+0x35/0x40
[   72.954138]  [<c015677b>] do_filp_open+0x4b/0x60
[   72.954248]  [<c0149d50>] do_mmap_pgoff+0x500/0x6e0
[   72.954387]  [<c0156466>] get_unused_fd+0xb6/0xd0
[   72.954497]  [<c01567da>] do_sys_open+0x4a/0xe0
[   72.954606]  [<c01568ac>] sys_open+0x1c/0x20
[   72.954714]  [<c0102c91>] sysenter_past_esp+0x56/0x79

Whats also interesting about that is I notice  ACPI/non-ACPI IRQ routing being inconsistent while having two e100 cards. Sometimes one is IRQ routed, while the other is not found, depending on if I do a hard reset or a soft reset. 
(Old hardware makes for rather fun quirks doesn't it?)

IRQs in use:

           CPU0
  0:    7755786          XT-PIC  timer
  1:         10          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  5:          0          XT-PIC  parport0
  6:          3          XT-PIC  floppy
  7:          0          XT-PIC  SoundBlaster
  8:          1          XT-PIC  rtc
  9:      85240          XT-PIC  eth1
 11:      38771          XT-PIC  uhci_hcd:usb1, eth0
 12:      10585          XT-PIC  i8042
 14:      11259          XT-PIC  ide0
 15:         11          XT-PIC  ide1

lspci info on PCI card:

00:10.0 VGA compatible controller: Elsa AG Gloria XL (rev 16) (prog-if 00 [VGA])
        Subsystem: IBM: Unknown device 00db
        Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Interrupt: pin A routed to IRQ 10
        Region 0: Memory at f0000000 (32-bit, non-prefetchable) [size=64M]
        Expansion ROM at 30300000 [disabled] [size=64K]

00:10.1 Co-processor: 3DLabs GLINT Delta (rev 01)
        Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Interrupt: pin A routed to IRQ 10
        Region 0: Memory at e9dc0000 (32-bit, non-prefetchable) [size=128K]

00:10.2 Display controller: 3DLabs GLINT MX (rev 01)
        Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Interrupt: pin A routed to IRQ 10
        Region 0: Memory at e9de0000 (32-bit, non-prefetchable) [size=128K]
        Region 1: Memory at ea000000 (32-bit, non-prefetchable) [size=32M]
        Region 2: Memory at ec000000 (32-bit, non-prefetchable) [size=32M]
        Region 3: Memory at ee000000 (32-bit, non-prefetchable) [size=32M]
        Expansion ROM at fe000000 [disabled] [size=64K]

I'm not considering this to be a severe/serious problem since ACPI 1.0 is fading away..slowly. 

Just wondering if its worth regression testing ACPI 1.0 systems still (at least, until the PSU dies, then this will become moot :-)

Shawn.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/