On Fri, Jun 20, 2008 at 10:40 PM, Vegard Nossum <vegard.nossum@gmail.com> wrote:Aha. The device in question (PNP0b00) is discovered while doing pnpbios_init(), NOT pnpacpi_init: [ 1.712032] initcall pnpacpi_init+0x0/0x80 returned 0 after 3 msecs [ 1.716032] calling pnpbios_init+0x0/0x322 [ 1.720032] PnPBIOS: Scanning system for PnP BIOS support... [ 1.724032] PnPBIOS: Found PnP BIOS installation structure at 0xc00fc550 [ 1.728032] PnPBIOS: PnP BIOS version 1.0, entry 0xf0000:0xc580, dseg 0xf0000 ... [ 1.876032] pnp 00:03: parse allocated resources [ 1.880032] pnp 00:03: add irq 8 flags 0x0 [ 1.884032] pnp 00:03: add io 0x70-0x71 flags 0x0 [ 1.888032] pnp 00:03: parse resource options [ 1.892032] pnp 00:03: new independent option [ 1.896032] device: '00:03': device_add [ 1.900032] bus: 'pnp': add device 00:03 [ 1.904032] PM: Adding info for pnp:00:03 [ 1.908032] pnp 00:03: Plug and Play BIOS device, IDs PNP0b00 (active) So I guess this function, pnpbios_init() needs the check as well. In fact, it has this: #ifdef CONFIG_PNPACPI if (!acpi_disabled && !pnpacpi_disabled) { pnpbios_disabled = 1; printk(KERN_INFO "PnPBIOS: Disabled by ACPI PNP\n"); return -ENODEV; } #endif /* CONFIG_ACPI */ ...I guess that should be changed to say if (acpi_disabled || pnpacpi_disabled)? Or... I don't understand the purpose of the original test. But it seems to be there since the beginning of time (or, well, v2.6.12-rc2). Vegard -- "The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation." -- E. W. Dijkstra, EWD1036 --
| Linus Torvalds | Linux 2.6.27-rc8 |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Linus Torvalds | Linux 2.6.20-rc6 |
| Mike Snitzer | Re: Distributed storage. |
git: | |
| Gerrit Renker | [PATCH 03/37] dccp: List management for new feature negotiation |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | [GIT]: Networking |
| Herbert Xu | Re: Kernel oops with 2.6.26, padlock and ipsec: probably problem with fpu state ch... |
