Latest working kernel version: 2.6.26.6 (not checked with 26.7 and 26.8, yet) Earliest failing kernel version: 2.6.27.2 (confirmed al also for 27.6) Distribution: Debian etch Hardware Environment: Acer TravelMate 8204 WLMi Software Environment: Problem Description: 2.6.27.x Kernel fails to boot stopping at: ----------------------------------------------- cs: IO port probe 0x100 - 0x4ff: excluding 0x4d0 - 0x4d7 cs: IO port probe 0x800 - 0x8ff: ----------------------------------------------- Adding pci=noacpi as a kernel parameter "solve" partially the problem (i.e. the kernel boots) however the battery is not detected while the AC adapter is. Is this related or I should open another bug?
Will you please add the boot option of "pci=noacpi" and attach the output of acpidump, dmesg, lspci -vxxx? Thanks.
Created attachment 18892 [details] acpidump output
Created attachment 18893 [details] dmesg output
Created attachment 18894 [details] lspci -vxxxx output
(In reply to comment #1) > Will you please add the boot option of "pci=noacpi" and attach the output of > acpidump, dmesg, lspci -vxxx? > Thanks. Done.
Hi, Walter Thanks for the info. From the dmesg in comment #3 the PCI interrupt for some PCI devices is listed in the following: >pci 0000:03:00.2: PCI->APIC IRQ transform: INT B -> IRQ 16 >pci 0000:05:00.0: PCI->APIC IRQ transform: INT A -> IRQ 17 But from the acpidump in comment #2 they have the differen PCI interrupts by using the _PRT table.(In I/O APIC mode) PCI device 0000:03.00.2 (Pin B): The PCI interrupt is 18. PCI device 0000:05.00.0 (Pin A): The PCI interrupt is 19. It seems that the ACPI table and MPS table give the different interrupt number for the same PCI devices. Maybe it is related with the BIOS. Will you please try whether the issue can be fixed by bios upgrading? Thanks.
Hi, Walter According to the problem description it seems that it is a regression. Will you please double check whether the box can work well on 2.6.26.6 kernel? If yes, will you please use git-bisect to identify which commit the regression is caused by? If not, I will clear the regression flag. thank.
(In reply to comment #7) > Hi, Walter > According to the problem description it seems that it is a regression. > Will you please double check whether the box can work well on 2.6.26.6 Yes it works with 2.6.26.6, I'm using that version right now. > kernel? If yes, will you please use git-bisect to identify which commit the > regression is caused by? I'll try. I think the whole process will require some days, however.
I've run aebisect, I've pasted below the output. Does the result make sense? walter@acer:~/src/linux-2.6$ git bisect good 999ed65ad12e374d7445fbc13f5a1d146ae4b0da is first bad commit commit 999ed65ad12e374d7445fbc13f5a1d146ae4b0da Author: Rene Herman <rene.herman@gmail.com> Date: Fri Jul 25 19:44:47 2008 -0700 pnp: have quirk_system_pci_resources() include io resources quirk_system_pci_resources() disables a PnP mem resource that overlaps a PCI BAR so as to not keep the PCI driver from claiming the resource. Have it do the same for io resources. Here, ACPI claims ports that overlap with my soundcard causing the soundcard driver to fail to load. It's unknown why my ACPI BIOS claims those ports; it did not use to but this is not a (kernel) regression. Some odd BIOS reconfig triggered by temporarily removing the card seems to have brought this on.
cc Rene. :)
and Rafael. this should be on the regression list, right?
Reassigning to Bjorn. Currently not capable of looking at this. The 2.6.28-rc result would (I believe; haven't been around) be interesting -- a previous problem in this area (in the end a BIOS bug but still not good ofcourse) resulted in some ordering changes now in .28. Ie, this might be solved already.
walter, could you please try the latest git tree?
(In reply to comment #13) > walter, could you please try the latest git tree? > Yes. May I assume it is "safe"?
(In reply to comment #13) > walter, could you please try the latest git tree? It boots succesfully with 2.6.28rc6 and the battery is detected. The following option has catched my attention during the config stage: CONFIG_PCI_QUIRKS=y However I'm not sure if it's related. Now I have a different problem: no network. I'll investigate a bit before opening a new bug :-(
Thanks for testing. No, CONFIG_PCI_QUIRKS is a (I see) new option that allows to compile out the PCI quirk code but in this case the issue is in fact with a PnP quirk. Okay, so the issue is -- .26 and below fail for (at least) me, work for Walter, .27 works for me, fails for Walter, .28 works for us both. Both in the sense that the .27 fix is a fix versus a regression and the sense that it's a non-functional soundcard (me) versus a non-booting kernel (Walter) reverting the offending commit from 2.6.27.x would be the thing to do. That commit _is_ the right thing to do and I'm quite sure I'm not the only one with a BIOS that does odd things though; just the only one to have reported/fixed it. In that sense and given that Walter's issue is probably an obscure BIOS thing in the very same way (and already fixed in .28) deciding to leave things be might be an option as well. I obviously know how to have 2.6.27.x functional locally (and will upgrade to .28 once released if needed due to this) so I'm fine either way.
Ok, so the issue is fixed in latest kernel, right? please close it.
It is, but it is a regression in 2.6.27 so someone might want to revert the patch (comment #9) from the .27 stable series (_not_ from mainline!). As argued in #16 it is also possible noone wants to -- if Frans doesn't hugely mind 27.x not working for him I guess it's okay.
It looks like this was fixed in the 2.6.28-rc tree with commit id b563cf59c4d67da7d671788a9848416bfa4180ab, so I will add that to the 2.6.27.y tree to also resolve this issue.