Bug 8896
|
Description
r
2007-08-17 03:30:55 UTC
Created attachment 12417 [details]
dmesg-s64000_ACPI_off
Created attachment 12418 [details]
dmesg-s64000_ACPI_on
Created attachment 12419 [details]
less /proc/interrupts with ACPI off
Created attachment 12420 [details]
less /proc/interrupts with ACPI=on
BIOS updated done from the site oooooooooof Packar Bell. No kernel 2.6 because I use only the stable version of kubuntu (production machine). > ACPI: BIOS age (400) fails cutoff (2000), acpi=force is required to enable
> ACPI
> ACPI: Disabling ACPI support
Please boot with "acpi=force" and verify that the system works properly.
Please boot with "acpi=off" "noapic" and verify that it fails per the initial "ACPI on" experiments (actually, this is just PIC mode and has nothing to do with ACPI).
Please attach the output from dmidecode.
Created attachment 12548 [details]
result of sudo dmidecode with acpi=force
Created attachment 12549 [details]
result of sudo dmidecode when "acpi=off noapic" options to kernel
Created attachment 12550 [details]
lspci -v with "acpi=off noapic" option passed to kernel
# with option acpi=force: the wireless is recognized, but the usb port is not working. # with options acpi=off noapic: the usb key works. no wireless recognized. You find attached the result of dmidecode, and other output files. Please indicate if you need any further info, thanks! Created attachment 12551 [details]
lspci -v with "acpi=force"
Created attachment 12552 [details]
dmesg -s64000 with "acpi=force"
Will you please upload the acpidump info? Thanks. (In reply to comment #12) > Created an attachment (id=12552) [details] > dmesg -s64000 with "acpi=force" > Created attachment 12562 [details]
sudo acpidump with option "acpi=force" to kernel
Created attachment 12563 [details]
acpidump with option to kernel "acpi=off noapic"
Here is acpidump. Don't hesitate to tell me if this is enough, or if you need more info. :-) . I have seen also a "pnpbios error" sequence at boot, if this may be useful (I updated the BIOS, but this continued to appear). Plese get the /proc/interrups after booting with acpi=force. Will you please boot the system with the option of acpi=force pci=noacpi ? Created attachment 12596 [details]
cat interrupts with "acpi=force" to kernel
Perhaps multiple bugs here, but the first one is that the BIOS has a bogus BIOS date in the DMI table: Base Board Information Manufacturer: NEC COMPUTERS INTERNATIONAL Product Name: NEC Versa Premium System Information Manufacturer: NEC Computers International Product Name: Packard Bell EasyNote BIOS Information Vendor: Insyde Software Corporation Version: R1.05 Release Date: /05/0620 There should be no difference between boots with "acpi=off" and without, since ACPI is being disabled by the cutoff date. To boot with ACPI, you can either manually add "acpi=force" as you did above, or build with CONFIG_ACPI_BLACKLIST_YEAR=0 to disable this cutoff in the kernel. If the system works in ACPI mode, we can add a white-list entry for it to enable "acpi=force" automatically. Created attachment 12598 [details]
acpidump with "acpi=force noacpi" to kernel
Created attachment 12600 [details]
dmesg -s64000 with "acpi=force noacpi" to kernel
Created attachment 12602 [details]
dmidecode with "acpi=force noacpi" to kernel
Created attachment 12603 [details]
lspci -v with "acpioff noacpi" to kernel
the /proc/interrupts shown in comment #3 is mis-labeled, It can't be from an "acpi=off" boot because it clearly shows that the acpi interrupt is enabled on IOAPIC IRQ 9. The /proc/interrupts shown in comment #4 is mis-labeled, It can't be from an ACPI enabled boot because it has no acpi interrupt. Further, it is in PIC mode, as if "noapic" were passed on the cmdline. The acpi=force /proc/interrupts shown in comment #18 look sane. However, the acpi=force dmesg in comment #12 show some serious BIOS issues: [ 3.896000] PCI: Enabling device 0000:00:10.3 (0000 -> 0002) [ 3.896000] ACPI Error (uteval-0269): Return object type is incorrect [\_SB_.PCI0.ALKD._CRS] (Node da6469f0), AE_TYPE [ 3.896000] ACPI Error (uteval-0275): Type returned from _CRS was incorrect: Integer, expected Btypes: 4 [20060707] [ 3.896000] ACPI Exception (pci_link-0278): AE_TYPE, Evaluating _CRS [20060707] [ 3.896000] ACPI: Unable to set IRQ for PCI Interrupt Link [ALKD]. Try pci=noacpi or acpi=off [ 3.896000] ACPI: Invalid IRQ link routing entry [ 3.896000] ACPI: Unable to derive IRQ for device 0000:00:10.3 [ 3.896000] ACPI: PCI Interrupt 0000:00:10.3[D]: no GSI - using IRQ 10 [ 3.896000] ehci_hcd 0000:00:10.3: EHCI Host Controller [ 3.896000] ehci_hcd 0000:00:10.3: new USB bus registered, assigned bus number 4 [ 3.896000] ehci_hcd 0000:00:10.3: irq 10, io mem 0x20010000 [ 3.896000] ehci_hcd 0000:00:10.3: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 ... [ 4.000000] VP_IDE: IDE controller at PCI slot 0000:00:11.1 [ 4.000000] ACPI: PCI Interrupt Link [ALKA] disabled and referenced, BIOS bug [ 4.000000] ACPI: PCI Interrupt Link [ALKA] BIOS reported IRQ 0, using IRQ 20 [ 4.000000] ACPI: PCI Interrupt Link [ALKA] enabled at IRQ 20 [ 4.000000] ACPI: PCI Interrupt 0000:00:11.1[A] -> Link [ALKA] -> GSI 20 (level, low) -> IRQ 16 ... please stop attaching copies of acpidump and dmidecode output -- these do not change with different kernels. > 2.6.20-16-generic
Is there any difference if you run a kernel.org 2.6.22.stable kernel?
Created attachment 12604 [details]
cat /proc/interupts with "acpi=force pci=noacpi" to kernel
Hi, Comment #17: With acpi=force pci=noacpi", the computer boots, recognize the usb but not the wireless card. I tried to be attentive in making these reports, so I just hope I did not make mispelling in options to kernel. Comment #26: I am quite newbye and do not know how to toggle between kernel versions. Take attention that I use this computer to make my office work everyday, all day. But if you provide me precise instructions with steps, and how to reverse back in case of problem, I may try. I use the stable xubuntu 7.04, so I use the embedded kernel of this version. Device (ALKD)
{
Name (_HID, EisaId ("PNP0C0F"))
Name (_UID, 0x08)
Method (_PRS, 0, NotSerialized)
{
Name (A47D, ResourceTemplate ()
{
Interrupt (ResourceConsumer, Level, ActiveLow, Shared, ,, )
{
0x00000015,
}
})
Return (A47D)
}
Method (_STA, 0, NotSerialized)
{
Return (0x0B)
}
Method (_DIS, 0, NotSerialized)
{
}
Method (_CRS, 0, NotSerialized)
{
Return (0x00)
}
Method (_SRS, 1, NotSerialized)
{
}
}
This is a second BIOS bug on this box.
_CRS for ALKD is indeed not returning a valid resource template.
Is this system running with defaults in BIOS SETUP?
Are there any ACPI or IO-APIC settings in BIOS SETUP?
Does Windows run on this box and do the IRQ settings it uses
show that it is using IOAPIC mode?
Re: acpi=force pci=noacpi [ 22.488000] wlan: 0.8.4.2 (0.9.3.1) [ 22.612000] ath_pci: 0.9.4.5 (0.9.3.1) [ 22.612000] PCI: Enabling device 0000:00:06.0 (0000 -> 0002) [ 22.612000] PCI: No IRQ known for interrupt pin A of device 0000:00:06.0. Please try using pci=biosirq. [ 22.612000] IRQ handler type mismatch for IRQ 0 [ 22.612000] current handler: timer [ 22.612000] [<c015410e>] setup_irq+0x12e/0x1e0 [ 22.612000] [<dc9af520>] ath_intr+0x0/0xc20 [ath_pci] [ 22.612000] [<c0154263>] request_irq+0xa3/0xc0 [ 22.612000] [<dc9b1f8d>] ath_pci_probe+0x1ad/0x3b0 [ath_pci] [ 22.612000] [<c01b8eee>] sysfs_create_link+0x6e/0x160 [ 22.612000] [<dc9b1de0>] ath_pci_probe+0x0/0x3b0 [ath_pci] [ 22.612000] [<c01fba86>] pci_device_probe+0x56/0x80 [ 22.612000] [<c0257aa6>] really_probe+0x66/0x190 [ 22.612000] [<c0257c19>] driver_probe_device+0x49/0xc0 [ 22.612000] [<c0257dee>] __driver_attach+0x9e/0xa0 [ 22.612000] [<c0256f7b>] bus_for_each_dev+0x3b/0x60 [ 22.612000] [<c0257944>] driver_attach+0x24/0x30 [ 22.612000] [<c0257d50>] __driver_attach+0x0/0xa0 [ 22.612000] [<c025730b>] bus_add_driver+0x7b/0x1a0 [ 22.612000] [<c01fbc54>] __pci_register_driver+0x74/0xc0 [ 22.612000] [<dc848030>] init_ath_pci+0x30/0x54 [ath_pci] [ 22.612000] [<c014422d>] sys_init_module+0x15d/0x1ba0 [ 22.612000] [<c0107a5d>] sys_mmap2+0xcd/0xd0 [ 22.612000] [<c01031f0>] sysenter_past_esp+0x69/0xa9 [ 22.612000] [<c02e0033>] xfrm_state_find+0x3d3/0x570 [ 22.612000] ======================= [ 22.612000] wifi%d: request_irq failed Please try: acpi=force pci=noacpi pci=biosirq paste the /proc/interrupts, and attach the dmesg -s64000 output Comment #29: I made no change to BIOS. I just made once an update of the BIOS from the Packard Bell site for this computer (Easy Note R1983 W, serial number: 647303620230). http://support.packardbell.com/uk/item/?sn=647303620230&g=2000 Windows is running in it, apparently without problems. No clue about the IRQ: I will check if you tell me where to look for. Is the wireless adapter attached to the motherboard? If yes, are there any options related to it in BIOS SETUP? If no, can you try moving it to another slot? in XP... Start Control Panel System Hardware Device Manager View Resources by type IRQ I know people have got this list into text form and pasted it to bug reports, but I'm not sure how they do it. In any case, the key is to note the IRQ number for the wireless and USB, and the maximum IRQ number (which will tell us if we are in PIC or IOAPIC mode) Created attachment 12605 [details]
cat /proc/interrupts with "acpi=force pci=noacpi pci=biosirq"
Created attachment 12606 [details]
dmesg -s64000 with "acpi=force pci=noacpi pci=biosirq"
Created attachment 12607 [details]
back of the computer, 1
no clue about the wireless card attached or not to the motherboard. I took a photo of the computer, once open. Have a look!
Created attachment 12608 [details]
open computer, 2
Comment #33: Read through Windows: Atheros: BUS PCI 0, device 6, function 0, IRQ 19. USB (there are 4 plugs): place 0, BUS PCI 0, device 16, function 0 (1, 2, 3). IRQ 21. (In reply to comment #35) > Created an attachment (id=12606) [details] > dmesg -s64000 with "acpi=force pci=noacpi pci=biosirq" > Thanks for your work. What Len said is very right. Maybe there are several bugs about your computer. 1.BIOS Release Date: /05/0620 . Uncorrect. The correct format should be mm/day/year 2.The info of /proc/interrupts is uncorrect. (Comment #3) When acpi is off, the system won't register the acpi interrupt. Will you please reupload the info of /proc/interrupts in the following modes? a. acpi=off b. acpi=force noapic c. acpi=force pci=noacpi Thanks. Created attachment 12632 [details]
cat /proc/interrupts with acpi=off
Created attachment 12633 [details]
cat /proc/interrupts with acpi=force pci=noacpi
Created attachment 12634 [details]
cat /proc/interrupts with acpi=force noapic
Here you are. Hope it will help. > Kernel command line: ... quiet acpi=force pci=noacpi pci=biosirq splash [ 22.656000] ath_pci: 0.9.4.5 (0.9.3.1) [ 22.656000] PCI: Enabling device 0000:00:06.0 (0000 -> 0002) [ 22.656000] PCI: No IRQ known for interrupt pin A of device 0000:00:06.0. [ 22.656000] IRQ handler type mismatch for IRQ 0 [ 22.656000] current handler: timer [ 22.656000] [<c015410e>] setup_irq+0x12e/0x1e0 [ 22.656000] [<dca91520>] ath_intr+0x0/0xc20 [ath_pci] [ 22.656000] [<c0154263>] request_irq+0xa3/0xc0 [ 22.656000] [<dca93f8d>] ath_pci_probe+0x1ad/0x3b0 [ath_pci] [ 22.656000] [<c01b8eee>] sysfs_create_link+0x6e/0x160 [ 22.656000] [<dca93de0>] ath_pci_probe+0x0/0x3b0 [ath_pci] [ 22.656000] [<c01fba86>] pci_device_probe+0x56/0x80 [ 22.656000] [<c0257aa6>] really_probe+0x66/0x190 [ 22.656000] [<c0257c19>] driver_probe_device+0x49/0xc0 [ 22.656000] [<c0257dee>] __driver_attach+0x9e/0xa0 [ 22.656000] [<c0256f7b>] bus_for_each_dev+0x3b/0x60 [ 22.656000] [<c0257944>] driver_attach+0x24/0x30 [ 22.656000] [<c0257d50>] __driver_attach+0x0/0xa0 [ 22.656000] [<c025730b>] bus_add_driver+0x7b/0x1a0 [ 22.656000] [<c01fbc54>] __pci_register_driver+0x74/0xc0 [ 22.656000] [<dc848030>] init_ath_pci+0x30/0x54 [ath_pci] [ 22.656000] [<c014422d>] sys_init_module+0x15d/0x1ba0 [ 22.656000] [<c0107a5d>] sys_mmap2+0xcd/0xd0 [ 22.656000] [<c01031f0>] sysenter_past_esp+0x69/0xa9 [ 22.656000] ======================= [ 22.656000] wifi%d: request_irq failed Thanks for confirming that pci=biosirq did not help. > Read through Windows: > Atheros: BUS PCI 0, device 6, function 0, IRQ 19. > USB (there are 4 plugs): place 0, BUS PCI 0, device 16, > function 0 (1, 2, 3). > IRQ 21 As there is no MPS table on this machine, the only way to enable the IOAPIC is via ACPI. So thanks for confirming that Windows is running in ACPI mode with IOAPIC enabled. Since you upgraded the BIOS, please go into BIOS SETUP and be sure to select the option that resets the system to its optimal defaults. This will eliminate any potential issues due to bogus CMOS values. The one I hope for is the bad DMI date that is making you need acpi=force. If it doesn't fix the DMI date problem, then Yakui, please implement a DMI based workaround to invoke "acpi=force" on this box. It is sort of interesting if we need to do this, because other bug reports suggest that Windows uses a DMI cutoff date, and so that makes you wonder what they do when they can't read the date... Perhaps they default to ACPI mode, and Linux defaults to acpi=off mode... The 2nd bug workaround is this: ACPI Error (uteval-0275): Type returned from _CRS was incorrect: Integer, expected Btypes: 4 [20060707] ACPI Exception (pci_link-0278): AE_TYPE, Evaluating _CRS [20060707] ACPI: Unable to set IRQ for PCI Interrupt Link [ALKD]. Try pci=noacpi or acpi=off Clearly Windows is interpreting this entry of 0x15 as IRQ21 and Linux is throwing it away and then doesn't know where to put the device. Linux needs a bug compatibility workaround so that we can digest an Integer return value here like Windows does. Yakui, please work with Bob on that. Ubuntu users reported this back in 2.6.17: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.17/+bug/83984 ACPI: PCI Interrupt Link [ALKD] (IRQs 21) *0 ... ACPI Error (uteval-0269): Return object type is incorrect [\_SB_.PCI0.ALKD._CRS] (Node dbfd39b4), AE_TYPE ACPI Error (uteval-0275): Type returned from _CRS was incorrect: Integer, expected Btypes: 4 [20060707] ACPI Exception (pci_link-0281): AE_TYPE, Evaluating _CRS [20060707] ACPI: Unable to set IRQ for PCI Interrupt Link [ALKD]. Try pci=noacpi or acpi=off ACPI: Invalid IRQ link routing entry ACPI: Unable to derive IRQ for device 0000:00:10.0 ACPI: PCI Interrupt 0000:00:10.0[A]: no GSI - using IRQ 11 The interesting thing here is that _PRS is valid, with IRQ 21. When Linux finds the bogus _CRS, it is abandoning the link and going to the PCI config space, which gives us 11 in the Ubuntu case and 0 here. Neither of them are in _PRS, which is quite clear that this link needs to be IRQ21 when enabled. So I'm thinking that rather than change the interpreter to grok a bogus link entry, what we should do is make the error path smarter and instead of using PCI space, we should use the _PRS when _CRS is bad. We already have a BIOS workaround in place for when _CRS returns 0, so this shouldn't be much different. Created attachment 12641 [details]
debug patch vs 2.6.23-rc4 to ignore bad _CRS
Please apply this debug patch and boot with "acpi=force"
and record the dmesg and /proc/interrupts.
(In reply to comment #44) > Since you upgraded the BIOS, please go into BIOS SETUP > and be sure to select the option that resets the system > to its optimal defaults. This will eliminate any potential > issues due to bogus CMOS values. The one I hope for > is the bad DMI date that is making you need acpi=force. OK, Now I have done this. See the following 4 attachments. Created attachment 12645 [details]
cat_proc_interrupts no_option after_bios_default & restore
Created attachment 12646 [details]
dmesg -s64000 no_option after_bios_default & restore
Created attachment 12647 [details]
cat_proc_interrupts acpi_force after_bios_default & restore
Created attachment 12648 [details]
dmesg -s64000 acpi_force_after_bios_default & restore
I have just upgraded kernel to 2.6.22-10, following these instructions (adapted to version 10 rather than 9): http://www.ubuntugeek.com/howto-upgrade-kernel2622-9-generic-in-feisty-fawn.html Same issue (no wireless until I put acpi=force, which disables usb). Please find here after 4 attachments (dmesg and /proc/interrupts with and without acpi=force). I don't know how to try the 2.6.23 kernel. If you indicate me where to look, I will try. Created attachment 12649 [details]
cat_proc_interrupts_2.6.22-10_no_option
Created attachment 12650 [details]
dmesg_2.6.22-10_no_option
Created attachment 12651 [details]
cat_proc_interrupts_2.6.22-10_acpi_force
Created attachment 12652 [details]
dmesg_2.6.22-10_acpi_force
thank you for confirming that resetting CMOS to defaults didn't have any effect on any of these BIOS bugs, nor did upgrading to 2.6.22. To test a debug patch you need to be able to apply the patch to a kernel source tree, built the kernel and boot it. As mentioned in the kernel source tree Documentation/HOWTO: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/HOWTO;h=c64e969dc33bb6e511f78984c007052e9b6cbc54;hb=HEAD you can get a kernel source tree in a number of ways, http://kernel.org/ being one of the easiest. Note, however, that you don't need 2.6.23 for this test -- you can also use 2.6.22, or even the flavor of 2.6.22 distributed by your distro, ubuntu. The debug patch there will apply with an offset, but that is just fine. (In reply to comment #56) > Created an attachment (id=12652) [details] > dmesg_2.6.22-10_acpi_force > Thanks for the info. Will you please try it with the boot option of acpi=force pci=noacpi noapic ? Had better upload the .config file. (In reply to comment #58) > Will you please try it with the boot option of acpi=force pci=noacpi noapic ? > Had better upload the .config file. Here are these infos, in the next 3 attachments. Concerning comment #57, I have difficulty/not enough time to achieve kernel recompilation (diff is ok, then all the make, then what?) Created attachment 12781 [details]
cat /proc/interrupts_2.6.22-10 with options acpi=force pci=noacpi noapic
Created attachment 12782 [details]
dmesg -s64000 2.6.22-10 with options acpi=force pci=noacpi noapic
Created attachment 12783 [details]
config of 2.6.22.10_with_diff_len
This config file has been created after I tried to patch the kernel with the patch here proposed by Len (the patch went well). Note that I am not sure about the choice of the options I indicated during menuconfig (I tried to keep out useless things, because space on disk is limited). Please provide any advice.
Created attachment 12986 [details]
workaround patch
Please test the system with boot option of acpi=force apic=debug after using the workaround patch.
Hi,
I finally managed to test your patch (to kernel 2.6.20.3 on my kubuntu 7.04):
- It applies ("it patches")
- it does not make work the wireless, with or without acpi=force
- the result of the tests you proposed are here after attached.
Let me know what else to try....
(In reply to comment #63)
> Created an attachment (id=12986) [details]
> workaround patch
>
> Please test the system with boot option of acpi=force apic=debug after using
> the workaround patch.
>
Created attachment 13191 [details]
dmesg -s64000 with patch ykhzao "acpi=force apic=debug"
Pay attention that I'm a beginner about this, so maybe something did not went as you indicated.
Created attachment 13192 [details]
cat /proc/interrupts with patch ykhzao "acpi=force apic=debug"
Created attachment 13193 [details]
.config of the new kernel with patch ykhzao
Thanks for your info. From the comment #65,66 it seems that the system can't still work well. For example , no USB interrupts.(IRQ 16). And the wireless PCI device can't be enumerated by the PCI bus, so it can't detected. Will you please confirm whether wireless is disabled in BIOS configuration? Will you please upload the dmidecode info after bios is upgraded? This is required for writing DMI workaround patch. Thanks. The BIOS is very basic, and does not allows to modify wireless. You will find hereafter screenshots of the BIOS. This is the most advanced version available, however: http://support.packardbell.com/fr/item/?sn=647303620230&g=2000 dmidecode for kernel with your patch, and the present, working wiki kernel, follow. Let me know if you need any other information. (In reply to comment #68) > Thanks for your info. > From the comment #65,66 it seems that the system can't still work well. For > example , no USB interrupts.(IRQ 16). And the wireless PCI device can't be > enumerated by the PCI bus, so it can't detected. > Will you please confirm whether wireless is disabled in BIOS configuration? > Will you please upload the dmidecode info after bios is upgraded? This is > required for writing DMI workaround patch. > Thanks. > Created attachment 13199 [details]
dmidecode for kernel 2.6.20.3 with yakui's patch, wifi is not working. "acpi=force apic=debug"
Created attachment 13200 [details]
dmidecode for 2.6.20.16 with "acpi=force". Here wifi is working.
Here are the screenshots of the BIOS, at startup: http://viewer.zoho.com/docs/dJddWi http://viewer.zoho.com/docs/dJdabh http://viewer.zoho.com/docs/eJd0G http://viewer.zoho.com/docs/zJdIbc http://viewer.zoho.com/docs/tJdqw http://viewer.zoho.com/docs/iJcdccb PS: there is a problem with the photo viewer, but if you stop the browser before it gets blocked, and then click on the "download" photo, you should have access to them. I don't know if this will help; I used to boot *.20 kernels (pb r1938) with acpi=force irqpoll, and all worked, both wireless and usb; well actually the wifi driver was buggy, but the HW was working; with *.22 kernel from gutsy now IRQPOLL is unbearable, the system is slow as hell, so I have to choose between usbs and wifi... I think this bug is related http://bugzilla.kernel.org/show_bug.cgi?id=8641 Yes, it works also for me: I have both wifi and usb working, on a former kernel 2.6.20.16 without any patch. Here are following some datas, hope it can help. This is what I was looking for! (In reply to comment #74) > I don't know if this will help; I used to boot *.20 kernels (pb r1938) with > acpi=force irqpoll, and all worked, both wireless and usb; well actually the > wifi driver was buggy, but the HW was working; with *.22 kernel from gutsy > now > IRQPOLL is unbearable, the system is slow as hell, so I have to choose > between > usbs and wifi... > Created attachment 13238 [details]
dmesg -s64000 of 2.6.20.16 with "acpi=force irqpoll"
Created attachment 13239 [details]
dmidecode of 2.6.20.16 with "acpi=force irqpoll"
Created attachment 13240 [details]
cat /proc/interrupts of 2.6.20.16 with "acpi=force irqpoll"
Thanks for the info. From the comment #79, it seems that there is no usb interrupt.Anyway,will you please confirm whether the USB can work well after using acpi=force irqpoll? Will you please test the system using the workaround patch in comment #63?(enable pci and acpi debug in kernel configuration). After the system is booted with option of acpi=force apic=debug ,please upload the following info. a. dmesg b. lspci -vvxxxx c. /proc/interrupts Thanks. With the patch of #63 applied on the kernel, the usb works but wifi does not work (as previously tested), with or without irqpoll. Here are the relative outputs: a.dmesg b.lspci c.proc interrupts. After, I also include these same 3 outputs for #76 with the previous kernel options (wifi working and usb working, but no patch), adding the option apic=debug. Created attachment 13242 [details]
dmesg_2.6.20.3 with yakui patch "acpi=force apic=debug irqpoll"
Created attachment 13243 [details]
lspci -vvxxxx with yakui patch "acpi=force apic=debug irqpoll"
Created attachment 13244 [details]
cat proc interrupts with yakui patch "acpi=force apic=debug irqpoll"
Created attachment 13245 [details]
dmesg -s64000 2.6.20.16 without patch "acpi=force apic=debug irqpoll"
Now I add the same outputs as yesterday, but adding the option apic=debug.
Created attachment 13246 [details]
lspci -vvxxxx 2.6.20.16 without patch "acpi=force apic=debug irqpoll"
Created attachment 13247 [details]
cat /proc/interrupts 2.6.20.16 with no patch and "acpi=force apic=debug irqpoll"
Thanks for the info. From the comment #83 and #85, it seems that wifi module is disabled in the comment #83. Will you please confirm whether wifi module is enabled in the kernel configuration(after using the workaround patch)? It is more helpful that pci debug is enabled in the kernel configuration. After the system is booted with option of acpi=force apic=debug , please upload the dmesg and .config file. Thanks. I can't provide the info you ask for right now (I'm not at home) but I can tell you the rt2x00 module is *not* loading and returns a -1 code IIRC there is a problem with its (shared) irq, that's why we need irqpoll (but irqpoll now is making the machine very slow, while with *.20 was ok) if i try to modprobe -r rt61pci and then modprobe rt61pci I get again that same error error: [ 51.042089] phy0 -> rt2x00pci_initialize: Error - IRQ 0 allocation failed (error -16). Tomorrow I will recompile the kernel with some additions in debug and enabling wifi, so as to be sure that it has everything you proposed (with workaround patch). Now I have made the modifications in make menuconfig. Tomorrow I will do the make-kpgp. In the meanwhile, here is the .config of the kernel that I intend to compile tomorrow. Let me know if something important is missing. Created attachment 13256 [details]
config of the kernel 2.6.22.3 that I will compile tomorrow, with yakui workaround patch. Same as #82, #83, #84, plus some additions of debug and wifi enabling options. Let me know if this is ok.
The .config file is OK. But it is more useful if the debug of PCI and ACPI in kernel configuration is enabled. Thanks Hi, I have added these debugs options to the kernel config, and I had to search a bit before it booted well. At this stage, with the patch and the acpi=force, the usb works but not the wireless. You will find here attached all the results. I made test with and without irqpoll (wireless does not works in the 2 cases). a. dmesg -s64000 b. cat /proc/interrupts c. lspci -vvxxxx d. kernel .config (In reply to comment #93) > The .config file is OK. But it is more useful if the debug of PCI and ACPI in > kernel configuration is enabled. > Thanks > Created attachment 13298 [details]
dmesg -s64000 with patch yzhkao and xconfig debugs; boot options "acpi=force apic=debug"
Created attachment 13299 [details]
cat /proc/interrupts with patch yzhkao and xconfig debugs; boot options "acpi=force apic=debug"
Created attachment 13300 [details]
lspci -vvxxxx with patch yzhkao and xconfig debugs; boot options "acpi=force apic=debug"
Created attachment 13301 [details]
dmesg -s64000 with patch yzhkao and xconfig debugs; boot options "acpi=force apic=debug irqpoll"
Created attachment 13302 [details]
cat /proc/interrupts with patch yzhkao and xconfig debugs; boot options "acpi=force apic=debug irqpoll"
Created attachment 13303 [details]
lspci -vvxxxx with patch yzhkao and xconfig debugs; boot options "acpi=force apic=debug irqpoll"
Let me know if this is enough or if you would like more infos or more tests. Thanks for the info. From the comment #95 and #98, it seems that the workaround patch can fix the following issue and configure the interrupt of PCI device using ALKD Link device correctly. ACPI Error (uteval-0275): Type returned from _CRS was incorrect: Integer, expected Btypes: 4 [20060707] [ 3.896000] ACPI Exception (pci_link-0278): AE_TYPE, Evaluating _CRS [20060707] [ 3.896000] ACPI: Unable to set IRQ for PCI Interrupt Link [ALKD]. Try pci=noacpi or acpi=off [ 3.896000] ACPI: Invalid IRQ link routing entry [ 3.896000] ACPI: Unable to derive IRQ for device 0000:00:10.3 The above error message is caused by the error _CRS method definition in ALKD device. Method (_CRS, 0, NotSerialized) { Return (0x00) } The BIOS has another problem that _SRS method is uncorrectly defined in the ALKA, ALKB, ALKC, ALKD. Method (_SRS, 1, NotSerialized) { } And the following error message is related with the above error. ACPI: PCI Interrupt Link [ALKA] disabled and referenced, BIOS bug ACPI: PCI Interrupt Link [ALKA] BIOS reported IRQ 0, using IRQ 20 ACPI: PCI Interrupt Link [ALKA] enabled at IRQ 20 ACPI: PCI Interrupt Link [ALKB] BIOS reported IRQ 11, using IRQ 23 ACPI: PCI Interrupt Link [ALKB] enabled at IRQ 23 ACPI: PCI Interrupt Link [ALKC] disabled and referenced, BIOS bug ACPI: PCI Interrupt Link [ALKC] BIOS reported IRQ 5, using IRQ 22 ACPI: PCI Interrupt Link [ALKC] enabled at IRQ 22 There still exists another problem that wifi can't work well. From the comment #60 and #61 the wifi can work and the following info is given in the dmesg: PCI: Enabling device 0000:00:06.0 (0000 -> 0002) ACPI: PCI Interrupt 0000:00:06.0[A] -> GSI 19 (level, low) -> IRQ 18 But from the comment #95 and #98 there is no such info in the dmesg. PCI: Enabling device 0000:00:06.0 (0000 -> 0002) ACPI: PCI Interrupt 0000:00:06.0[A] -> GSI 19 (level, low) -> IRQ 18 So the wireless device can't work well. From the comment #97 and #100 the wireless PCI device can be detected(00:00:06.0). If the module for wifi PCI device isn't loaded, the wirelss can't work. Will you please confirm whethre the wireless module is enabled ? Thanks. What is the exact name of this wireless module? Here is the .config: maybe you can check. (In reply to comment #103) > Will you please confirm whethre the wireless module is enabled ? > Thanks. > Created attachment 13310 [details]
file .config with yakui's workaround patch and debug modules. Hopefully, also wireless module.
wireless module are rt61pci and rt2x00pci (which is loaded if you modprobe rt61pci if I've understood right) I have added the modules in the "ubuntu added wireless network drivers", and compiled again. I booted with the modified kernel, but same result: USB is OK, but no wireless. Here you find the info: 1. dmesg -s64000 2. cat /proc/interrupts 3. lspci -vvxxxx 4. .config (In reply to comment #106) > wireless module are rt61pci and rt2x00pci (which is loaded if you modprobe > rt61pci if I've understood right) > (In reply to comment #103) > There still exists another problem that wifi can't work well. > From the comment #60 and #61 the wifi can work and the following info is > given > in the dmesg: > PCI: Enabling device 0000:00:06.0 (0000 -> 0002) > ACPI: PCI Interrupt 0000:00:06.0[A] -> GSI 19 (level, low) -> IRQ 18 > > But from the comment #95 and #98 there is no such info in the dmesg. > PCI: Enabling device 0000:00:06.0 (0000 -> 0002) > ACPI: PCI Interrupt 0000:00:06.0[A] -> GSI 19 (level, low) -> IRQ 18 > So the wireless device can't work well. > > From the comment #97 and #100 the wireless PCI device can be > detected(00:00:06.0). If the module for wifi PCI device isn't loaded, the > wirelss can't work. > Will you please confirm whethre the wireless module is enabled ? > Thanks. > I have added the modules in the "ubuntu added wireless network drivers", and compiled again. I have added RT2x00PCI and RT61PCI I booted with the modified kernel, but same result: USB is OK, but no wireless. Here you find the info: 1. dmesg -s64000 2. cat /proc/interrupts 3. lspci -vvxxxx 4. .config (In reply to comment #106) > wireless module are rt61pci and rt2x00pci (which is loaded if you modprobe > rt61pci if I've understood right) > (In reply to comment #103) > There still exists another problem that wifi can't work well. > From the comment #60 and #61 the wifi can work and the following info is > given > in the dmesg: > PCI: Enabling device 0000:00:06.0 (0000 -> 0002) > ACPI: PCI Interrupt 0000:00:06.0[A] -> GSI 19 (level, low) -> IRQ 18 > > But from the comment #95 and #98 there is no such info in the dmesg. > PCI: Enabling device 0000:00:06.0 (0000 -> 0002) > ACPI: PCI Interrupt 0000:00:06.0[A] -> GSI 19 (level, low) -> IRQ 18 > So the wireless device can't work well. > > From the comment #97 and #100 the wireless PCI device can be > detected(00:00:06.0). If the module for wifi PCI device isn't loaded, the > wirelss can't work. > Will you please confirm whethre the wireless module is enabled ? > Thanks. > Created attachment 13319 [details]
dmesg -s64000, with patch yzhkao, rt2x00pci & other debugs, options "acpi=force apic=debug"
Created attachment 13320 [details]
cat /proc/interrupts, with patch yzhkao, rt2x00pci & other debugs, options "acpi=force apic=debug"
Created attachment 13321 [details]
lspci -vvxxxx, with patch yzhkao, rt2x00pci & other debugs, options "acpi=force apic=debug"
Created attachment 13322 [details]
.config, with patch yzhkao, rt2x00pci & other debugs, options "acpi=force apic=debug"
sorry for "bugging" you guys, but I don't see news and this is really a serious bug for people owning motherboards with the same chipset (and they're many, reading launchpad) This is true: maybe you can try the patch (#63 and/or #46) on your own computer, and report the dmesg, cat /proc/interrupts, lspci -vvxxxx. (In reply to comment #113) > sorry for "bugging" you guys, but I don't see news and this is really a > serious > bug for people owning motherboards with the same chipset (and they're many, > reading launchpad) > I'm the unlucky owner of your same exact laptop (r1938 not 1983 but It think you just misspelled the model in the description :)) and same distro (now I'm just using the feisty kernel) so I think the info I could provide would be the same. Hi, I just checked, and I confirm that my computer is model 1983, not model 1938. http://support.packardbell.com/uk/item/?sn=647303620230&g=2000 Maybe it can help, it is up to you! Bye. (In reply to comment #115) > I'm the unlucky owner of your same exact laptop (r1938 not 1983 but It think > you just misspelled the model in the description :)) and same distro (now I'm > just using the feisty kernel) so I think the info I could provide would be > the > same. > they share the same main components http://support.packardbell.com/uk/item/index.php?pn=PB42B01101&g=1400 I realize that I did not effectively try the patch of Len Brown - #46 - on the kernel source. I tried only the patch of Yakui. Is it different? If so, I will do it when I have some time (not in the coming days). If someone can try this, this will help. (In reply to comment #116) > Hi, > > I just checked, and I confirm that my computer is model 1983, not model 1938. > http://support.packardbell.com/uk/item/?sn=647303620230&g=2000 > > Maybe it can help, it is up to you! Bye. > > > (In reply to comment #115) > > I'm the unlucky owner of your same exact laptop (r1938 not 1983 but It > think > > you just misspelled the model in the description :)) and same distro (now > I'm > > just using the feisty kernel) so I think the info I could provide would be > the > > same. > > > From the comment #110 it seems that the wireless module isn't still loaded correctly. Will you please attach the lsmod info when wireless can work? Thanks. Created attachment 13609 [details]
lsmod of kernel 2.6.20-16
Now the wireless and the usb are working correctly. I use the kernel 2.6.20-16, with following options: "acpi=force irqpoll" (no patch applied).
From the comment #120, the wireless module is loaded and it can work. Because irqpoll option is added, USB module can work. But the cost is to slow down the system. Will you please apply the patch(comment #63) on kernel 2.6.20-16 and try to boot it with option of acpi=force initcall_debug ?(had better use the same kernel config as in the comment #120) After the system is booted, please upload the following message. a. lsmod b. dmesg Thanks. Created attachment 13873 [details]
dmesg patch #63 acpi=force initcall_debug
please notice rt61 was blacklisted and loaded after boot; btw once modprobed and ifconfig'd up it's looking like able to associate (that driver was buggy and didn't work well with WPA), and USB seems to work too (last lines: usb thumbdrive was attached to test)
Created attachment 13874 [details]
lspci patch #63 acpi=force initcall_debug
I don't want to sound too quick, but... looks like *habemus workaround*! I hope so about wireless, I didn't say it is able to scan, so I assume it works Hi, Edoardo Thanks for your help. From the comment #122 it seems that the wifi and USB can work well. Created attachment 13965 [details]
the workaround patch about the error BIOS age
Created attachment 13966 [details]
the workaround patch about the error _CRS method
Will you please test the system after applying the patches in comment #127,128 and attach the dmesg ? Thanks. Hi, Edoardo From the above analysis and test the root cause of this bug is very clear. There are two problems about this bug. 1. BIOS age. This is caused by the error( /05/0620). The patch in comment #127 or boot option of acpi=force can fix this. 2. Error _CRS method. This is uncorrect defintion in BIOS ACPI table. The workaround patch in comment #128 can fix this. But in fact the above problems are related to BIOS. So it is more appropriate to fix this bug by updateing BIOS than the workaround patch. Hi, unfortunately the only existing new firmware for the BIOS has been reported to have the same behavior of my current, so it's useless (cheap HW, cheap support) do I still have to test the patches? #128 looks almost like a pretty printed version of the one I already tried, and the other looks trivial are they going to be included to 2.6.24 ? are they going to be backported? Can I tell people at Ubuntu they can patch their sources ? Hi, Edoardo
What a poor hardware and bios.
It will be great if you can test the patch in comment #127 and it should the same meaning with acpi=force.
The above two patches in comment #127 and #128 can fix the problems for this bug. But they seem ugly and I am not willing to send the patches to kernel.
Thanks.
re: patch in comment #127 Rather than setting acpi_force, I'd rather have the DMI option simply disable blacklist_by_year() for this box. That way, any other use of acpi=force or acpi=off are not effected. of course, building the kernel with CONFIG_ACPI_BLACKLIST_YEAR=n is also an option. But that doesn't help when running a distribution. I recommend that distributions use CONFIG_ACPI_BLACKLIST_YEAR=1999 re: patch in comment #128 this one has potential. I wonder if other systems can benefit from it. Hi Len, I guess that patch in comment #128 *does* have potential; this should be tested with other systems... at least this would be a way to justify its inclusion in the mainline Hi all, my Packard Bell had hardware problems (interface screen/motherboard plus hard disk), so even if I finally managed to repare it, this laptop is not very usable anymore. I'm happy that at last people managed to overcome the problem. Alle 20:34, il Friday 21 December 2007, hai scritto: > http://bugzilla.kernel.org/show_bug.cgi?id=8896 > > > > > > ------- Comment #134 from uncommonnonsense@gmail.com 2007-12-21 11:34 > ------- Hi Len, > > I guess that patch in comment #128 *does* have potential; this should be > tested with other systems... at least this would be a way to justify its > inclusion in the mainline I'd want to bump again up this problem... I don't want to sound annoying, but I'm wondering how people will be supposed to overcome this problem if the patch won't make it into the kernel trunk; I'm sure you understand that patching the kernel is not a solution for everybody. Isn't there even a chance that this will be implemented, maybe as a kernel boot param, as acpi=force is? something like insyde_enable_horrible_hack :) Thank you == ENODEV must be changed into == -ENODEV or the patch won't work anymore :) I still wish there were a kernel parameter for this... Hi, Edoardo What you have done is right. == ENODEV should be changed into == -ENODEV. Thanks for your work. Created attachment 15463 [details] Proposed kernel param this patch is an updated version of comment #128 , with == ENODEV changed into == -ENODEV moreover, it is my first naive attempt to create a kernel parameter... and it looks like it's working. I've created yet-another-static int (ugly, I know, but how to pass it otherwise?) called acpi_pci_link_crs_ignore set via __setup by acpi_pci_link_crs_ignore_set this int value it is checked together with the == -ENODEV so that the ugly hack is allowed only when this kernel parameter is present I would love to see this (or a cleaned up version) included, it would save me from having to recompile the kernel each time, and it would hopefully help other people too thank you I observe this same problem (kernel panic) when installing Ubuntu 8.04.1 server edition from a CD-ROM. Computer specs: ASUS M3A-H/HDMI, 4GB RAM, AMD PHENOM X3 8750, 4xSATA, 256MB Radeon 2400 PRO PCI Express. Installed kernel: 2.6.24-19-server. I can suppress the problem using acpi=off See http://ubuntuforums.org/showthread.php?t=896077 for further details of the problem and https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.24/+bug/63134 for the bug report. Apparently, the fix provided here should already be in the version of the kernel I am using, but I am still getting the problem. Please can someone advise me what information I should be providing to help get this fixed? Should I be reporting this as a separate bug? Thank you. Hi Paul, I'm not sure whether this bug has or has not to do with your problem, but unless you have the same BIOS I have, it shouldn't. By the way, even if this was the case, the patches for this bug have been judged too much of a kludge, so they haven't been merged, and never will. Moreover, unfortunately, from my last tests on kernel 2.6.26 neither these patch, neither another "cleaner" one sent me by ykzhao (which anyway is not clean 'enough') seem to be working anymore. So, finally, (and reluctantly) I gave up. Hi, Edoardo
Althoug the _CRS issue can be workaround by the patch in comment #139 or #128, IMO the issue is related with the BIOS and it had better be fixed by BIOS upgrading.
In fact there is another similar bug(10363). And the issue can be fixed by the workaround patch in http://bugzilla.kernel.org/show_bug.cgi?id=10363#C1. But it is not worth doing so in ACPICA for some broken BIOS. So I give up.
At the same time I will reopen this bug and mark it as rejected.(The workaround patch seems ugly. The issue had better be fixed by BIOS upgrading).
As it is BIOS issue, it had better be fixed by BIOS upgrading. The bug will be rejected and marked as WILL_NOT_FIX. Thanks. Hi there. Edoardo Vachhi's bug is now marked as rejected will_not_fix, but, although the symptoms appear to be the same, the problem I have reported is for a different bios. Since this bug has been marked as rejected, I will report mine as a separate bug so that it can be investigated. Thanks, Paul Also, I don't even have a wireless card, so that's not the problem. Paul I have submitted by problem as bug 11714 (http://bugzilla.kernel.org/show_bug.cgi?id=11714) Cheers. Hi all I have been looking at this problem for some time, i have tried it all acpi=force, irqpoll, pnpbios=off all of it!! but i can say in linux kernel 2.6.31.14 i can now say that the USB, Wireless now work in harmony! please try acpi=force noapictimer irqpoll Neil Sandison |