Distribution: any that will use 2.6.10 Hardware Environment: ES7000 IA-32 servers Software Environment: System initialization Problem Description: I tested the new 2.6.10 and found that the system was not booting, because interrupts were not set up right. After some debugging it turned out that the new PnP driver sets up standard legacy entries, without regards to the IRQ overrides that were processed by the time the PnP driver kicked in. Later on, the PCI devices try to set up their pins (correctly) and find them already set as ISA... and leave them as is. The system comes up with wrong interrupt settings (if comes up at all, depending upon if the boot controller was affected). I realized that the PnP started using _CRS and _PRS now. IRQ entries in _CRS and _PRS on ES7000 do not correspond to the overrides. I think that it should be some safeguard or back door of the quirk nature, since it is not clear if the IRQ entries in _CRS/PRS should reflect overrides or the overrides should be applied to them. There is a table of "excused" PNP devices, but I cannot really use it because for us it is a mouse, a keyboard, etc. I could use "quirks", but ACPI portion doesn't have it. I can disable PNP ACPI during build, of course, but SuSE/RH will likely make it default for their builds. Steps to reproduce: Build 2.6.10 kernel with PnP ACPI enabled and boot
please attach the output from acpidmp run on this machine, available in /usr/sbin, or in pmtools here http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils also, please verify that "acpipnp=off" from the 2.6.11 kernel works around this issue.
Created attachment 4559 [details] acpidmp listing for a ES7000 540 system
Created attachment 4560 [details] acpidmp listing for a ES7000 550 system
Created attachment 4561 [details] Collection of /proc/interrupts traces This capture contains /proc/interrupts for kernels booted with the following parameters: Scenario 1: (no parameters) Scenario 2: pnpacpi=off Scenario 3: pci=irqroute Scenario 4: pci=noacpi Notice that the i8042 IRQs are different between scenario one and two but in both cases, they are still in the PCI range (should be in the legacy range like scenario four).
I am closing this bug, because with new 2.6.12* kernel levels the problem went away, as result of changes in PnP and interrupt handlind code. Thanks to everyone who streightened things up and contributed to the resolution.