Bug 8896 - ACPI: BIOS age (400) - Type returned from _CRS was incorrect: Integer, expected Btypes: 4 - Packard Bell/Insyde
Summary: ACPI: BIOS age (400) - Type returned from _CRS was incorrect: Integer, expect...
Status: REJECTED WILL_NOT_FIX
Alias: None
Product: ACPI
Classification: Unclassified
Component: BIOS (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: ykzhao
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-08-17 03:30 UTC by r
Modified: 2009-10-16 22:12 UTC (History)
8 users (show)

See Also:
Kernel Version: 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686 GNU/Li
Tree: Mainline
Regression: ---


Attachments
dmesg-s64000_ACPI_off (59.38 KB, text/plain)
2007-08-17 03:31 UTC, r
Details
dmesg-s64000_ACPI_on (17.71 KB, text/plain)
2007-08-17 03:32 UTC, r
Details
less /proc/interrupts with ACPI off (721 bytes, text/plain)
2007-08-17 03:33 UTC, r
Details
less /proc/interrupts with ACPI=on (577 bytes, text/plain)
2007-08-17 03:33 UTC, r
Details
result of sudo dmidecode with acpi=force (10.36 KB, text/plain)
2007-08-26 14:22 UTC, r
Details
result of sudo dmidecode when "acpi=off noapic" options to kernel (10.36 KB, text/plain)
2007-08-26 14:34 UTC, r
Details
lspci -v with "acpi=off noapic" option passed to kernel (4.13 KB, text/plain)
2007-08-26 14:34 UTC, r
Details
lspci -v with "acpi=force" (4.17 KB, text/plain)
2007-08-26 14:42 UTC, r
Details
dmesg -s64000 with "acpi=force" (22.74 KB, text/plain)
2007-08-26 14:44 UTC, r
Details
sudo acpidump with option "acpi=force" to kernel (66.47 KB, text/plain)
2007-08-27 00:55 UTC, r
Details
acpidump with option to kernel "acpi=off noapic" (66.47 KB, text/plain)
2007-08-27 01:01 UTC, r
Details
cat interrupts with "acpi=force" to kernel (748 bytes, text/plain)
2007-08-29 00:18 UTC, r
Details
acpidump with "acpi=force noacpi" to kernel (66.47 KB, text/plain)
2007-08-29 00:52 UTC, r
Details
dmesg -s64000 with "acpi=force noacpi" to kernel (18.97 KB, text/plain)
2007-08-29 00:53 UTC, r
Details
dmidecode with "acpi=force noacpi" to kernel (10.36 KB, text/plain)
2007-08-29 00:53 UTC, r
Details
lspci -v with "acpioff noacpi" to kernel (4.13 KB, text/plain)
2007-08-29 00:54 UTC, r
Details
cat /proc/interupts with "acpi=force pci=noacpi" to kernel (638 bytes, text/plain)
2007-08-29 01:10 UTC, r
Details
cat /proc/interrupts with "acpi=force pci=noacpi pci=biosirq" (598 bytes, text/plain)
2007-08-29 01:56 UTC, r
Details
dmesg -s64000 with "acpi=force pci=noacpi pci=biosirq" (18.90 KB, text/plain)
2007-08-29 01:56 UTC, r
Details
back of the computer, 1 (273.79 KB, image/jpeg)
2007-08-29 01:58 UTC, r
Details
open computer, 2 (295.22 KB, image/jpeg)
2007-08-29 01:58 UTC, r
Details
cat /proc/interrupts with acpi=off (612 bytes, text/plain)
2007-08-30 09:08 UTC, r
Details
cat /proc/interrupts with acpi=force pci=noacpi (618 bytes, text/plain)
2007-08-30 09:08 UTC, r
Details
cat /proc/interrupts with acpi=force noapic (665 bytes, text/plain)
2007-08-30 09:09 UTC, r
Details
debug patch vs 2.6.23-rc4 to ignore bad _CRS (410 bytes, patch)
2007-08-31 14:32 UTC, Len Brown
Details | Diff
cat_proc_interrupts no_option after_bios_default & restore (577 bytes, text/plain)
2007-09-01 03:19 UTC, r
Details
dmesg -s64000 no_option after_bios_default & restore (17.77 KB, text/plain)
2007-09-01 03:20 UTC, r
Details
cat_proc_interrupts acpi_force after_bios_default & restore (721 bytes, text/plain)
2007-09-01 03:21 UTC, r
Details
dmesg -s64000 acpi_force_after_bios_default & restore (22.82 KB, text/plain)
2007-09-01 03:21 UTC, r
Details
cat_proc_interrupts_2.6.22-10_no_option (577 bytes, text/plain)
2007-09-01 04:18 UTC, r
Details
dmesg_2.6.22-10_no_option (16.37 KB, text/plain)
2007-09-01 04:18 UTC, r
Details
cat_proc_interrupts_2.6.22-10_acpi_force (721 bytes, text/plain)
2007-09-01 04:19 UTC, r
Details
dmesg_2.6.22-10_acpi_force (22.43 KB, text/plain)
2007-09-01 04:19 UTC, r
Details
cat /proc/interrupts_2.6.22-10 with options acpi=force pci=noacpi noapic (659 bytes, text/plain)
2007-09-10 23:12 UTC, r
Details
dmesg -s64000 2.6.22-10 with options acpi=force pci=noacpi noapic (19.54 KB, text/plain)
2007-09-10 23:12 UTC, r
Details
config of 2.6.22.10_with_diff_len (75.74 KB, text/plain)
2007-09-10 23:18 UTC, r
Details
workaround patch (586 bytes, text/x-patch)
2007-09-29 03:09 UTC, ykzhao
Details
dmesg -s64000 with patch ykhzao "acpi=force apic=debug" (23.91 KB, text/plain)
2007-10-17 14:21 UTC, r
Details
cat /proc/interrupts with patch ykhzao "acpi=force apic=debug" (574 bytes, text/plain)
2007-10-17 14:22 UTC, r
Details
.config of the new kernel with patch ykhzao (76.19 KB, text/plain)
2007-10-17 14:23 UTC, r
Details
dmidecode for kernel 2.6.20.3 with yakui's patch, wifi is not working. "acpi=force apic=debug" (10.36 KB, text/plain)
2007-10-18 08:51 UTC, r
Details
dmidecode for 2.6.20.16 with "acpi=force". Here wifi is working. (10.36 KB, text/plain)
2007-10-18 08:52 UTC, r
Details
dmesg -s64000 of 2.6.20.16 with "acpi=force irqpoll" (27.62 KB, application/text)
2007-10-22 12:28 UTC, r
Details
dmidecode of 2.6.20.16 with "acpi=force irqpoll" (10.36 KB, application/octet-stream)
2007-10-22 12:29 UTC, r
Details
cat /proc/interrupts of 2.6.20.16 with "acpi=force irqpoll" (762 bytes, application/text)
2007-10-22 12:29 UTC, r
Details
dmesg_2.6.20.3 with yakui patch "acpi=force apic=debug irqpoll" (25.43 KB, application/text)
2007-10-23 01:19 UTC, r
Details
lspci -vvxxxx with yakui patch "acpi=force apic=debug irqpoll" (10.86 KB, application/octet-stream)
2007-10-23 01:20 UTC, r
Details
cat proc interrupts with yakui patch "acpi=force apic=debug irqpoll" (574 bytes, application/octet-stream)
2007-10-23 01:20 UTC, r
Details
dmesg -s64000 2.6.20.16 without patch "acpi=force apic=debug irqpoll" (28.59 KB, application/text)
2007-10-23 01:22 UTC, r
Details
lspci -vvxxxx 2.6.20.16 without patch "acpi=force apic=debug irqpoll" (10.92 KB, application/octet-stream)
2007-10-23 01:22 UTC, r
Details
cat /proc/interrupts 2.6.20.16 with no patch and "acpi=force apic=debug irqpoll" (721 bytes, application/text)
2007-10-23 01:24 UTC, r
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. (76.12 KB, application/octet-stream)
2007-10-23 16:02 UTC, r
Details
dmesg -s64000 with patch yzhkao and xconfig debugs; boot options "acpi=force apic=debug" (30.52 KB, application/text)
2007-10-28 11:11 UTC, r
Details
cat /proc/interrupts with patch yzhkao and xconfig debugs; boot options "acpi=force apic=debug" (615 bytes, application/text)
2007-10-28 11:12 UTC, r
Details
lspci -vvxxxx with patch yzhkao and xconfig debugs; boot options "acpi=force apic=debug" (23.25 KB, application/text)
2007-10-28 11:12 UTC, r
Details
dmesg -s64000 with patch yzhkao and xconfig debugs; boot options "acpi=force apic=debug irqpoll" (30.37 KB, application/text)
2007-10-28 11:12 UTC, r
Details
cat /proc/interrupts with patch yzhkao and xconfig debugs; boot options "acpi=force apic=debug irqpoll" (23.25 KB, application/text)
2007-10-28 11:13 UTC, r
Details
lspci -vvxxxx with patch yzhkao and xconfig debugs; boot options "acpi=force apic=debug irqpoll" (23.25 KB, application/text)
2007-10-28 11:13 UTC, r
Details
file .config with yakui's workaround patch and debug modules. Hopefully, also wireless module. (74.92 KB, application/octet-stream)
2007-10-29 03:45 UTC, r
Details
dmesg -s64000, with patch yzhkao, rt2x00pci & other debugs, options "acpi=force apic=debug" (30.43 KB, application/text)
2007-10-29 11:45 UTC, r
Details
cat /proc/interrupts, with patch yzhkao, rt2x00pci & other debugs, options "acpi=force apic=debug" (615 bytes, application/text)
2007-10-29 11:45 UTC, r
Details
lspci -vvxxxx, with patch yzhkao, rt2x00pci & other debugs, options "acpi=force apic=debug" (23.25 KB, application/text)
2007-10-29 11:46 UTC, r
Details
.config, with patch yzhkao, rt2x00pci & other debugs, options "acpi=force apic=debug" (75.05 KB, application/octet-stream)
2007-10-29 11:49 UTC, r
Details
lsmod of kernel 2.6.20-16 (4.08 KB, text/plain)
2007-11-19 00:28 UTC, r
Details
dmesg patch #63 acpi=force initcall_debug (36.67 KB, text/plain)
2007-12-05 13:21 UTC, Edoardo Vacchi
Details
lspci patch #63 acpi=force initcall_debug (1.38 KB, text/plain)
2007-12-05 13:21 UTC, Edoardo Vacchi
Details
the workaround patch about the error BIOS age (1.72 KB, patch)
2007-12-10 20:36 UTC, ykzhao
Details | Diff
the workaround patch about the error _CRS method (1.17 KB, patch)
2007-12-10 20:39 UTC, ykzhao
Details | Diff
Proposed kernel param (1.72 KB, patch)
2008-03-27 11:25 UTC, Edoardo Vacchi
Details | Diff

Description r 2007-08-17 03:30:55 UTC
Most recent kernel where this bug did not occur:2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686 GNU/Linux

Distribution: kubuntu 7.04 updated
Hardware Environment: laptop Packard Bell, Easynote R1983. Wireless card: Atheros. 
Software Environment:
Problem Description:u
Wireless works with "acpi=off" option passed to kernel, but then this disables usb. 

Steps to reproduce:
Comment 1 r 2007-08-17 03:31:48 UTC
Created attachment 12417 [details]
dmesg-s64000_ACPI_off
Comment 2 r 2007-08-17 03:32:27 UTC
Created attachment 12418 [details]
dmesg-s64000_ACPI_on
Comment 3 r 2007-08-17 03:33:00 UTC
Created attachment 12419 [details]
less /proc/interrupts with ACPI off
Comment 4 r 2007-08-17 03:33:31 UTC
Created attachment 12420 [details]
less /proc/interrupts with ACPI=on
Comment 5 r 2007-08-17 04:03:20 UTC
BIOS updated done from the site oooooooooof Packar Bell. 
No kernel 2.6 because I use only the stable version of kubuntu (production machine). 
Comment 6 Len Brown 2007-08-24 00:45:17 UTC
> 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.
Comment 7 r 2007-08-26 14:22:40 UTC
Created attachment 12548 [details]
result of sudo dmidecode with acpi=force
Comment 8 r 2007-08-26 14:34:12 UTC
Created attachment 12549 [details]
result of sudo dmidecode when "acpi=off noapic" options to kernel
Comment 9 r 2007-08-26 14:34:48 UTC
Created attachment 12550 [details]
lspci -v with "acpi=off noapic" option passed to kernel
Comment 10 r 2007-08-26 14:36:12 UTC
# 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!
Comment 11 r 2007-08-26 14:42:12 UTC
Created attachment 12551 [details]
lspci -v with "acpi=force"
Comment 12 r 2007-08-26 14:44:04 UTC
Created attachment 12552 [details]
dmesg -s64000 with "acpi=force"
Comment 13 ykzhao 2007-08-26 22:38:01 UTC
Will you please upload the acpidump info?
Thanks.

(In reply to comment #12)
> Created an attachment (id=12552) [details]
> dmesg -s64000 with "acpi=force"
> 
Comment 14 r 2007-08-27 00:55:18 UTC
Created attachment 12562 [details]
sudo acpidump with option "acpi=force" to kernel
Comment 15 r 2007-08-27 01:01:05 UTC
Created attachment 12563 [details]
acpidump with option to kernel "acpi=off noapic"
Comment 16 r 2007-08-27 01:08:18 UTC
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). 
Comment 17 ykzhao 2007-08-28 23:28:38 UTC
Plese get the /proc/interrups after booting with acpi=force.
Will you please boot the system with the option of acpi=force pci=noacpi ? 
Comment 18 r 2007-08-29 00:18:51 UTC
Created attachment 12596 [details]
cat interrupts with "acpi=force" to kernel
Comment 19 Len Brown 2007-08-29 00:49:50 UTC
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.
Comment 20 r 2007-08-29 00:52:36 UTC
Created attachment 12598 [details]
acpidump with "acpi=force noacpi" to kernel
Comment 21 r 2007-08-29 00:53:09 UTC
Created attachment 12600 [details]
dmesg -s64000 with "acpi=force noacpi" to kernel
Comment 22 r 2007-08-29 00:53:41 UTC
Created attachment 12602 [details]
dmidecode with "acpi=force noacpi" to kernel
Comment 23 r 2007-08-29 00:54:37 UTC
Created attachment 12603 [details]
lspci -v with "acpioff noacpi" to kernel
Comment 24 Len Brown 2007-08-29 01:01:35 UTC
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
...
Comment 25 Len Brown 2007-08-29 01:02:46 UTC
please stop attaching copies of acpidump and dmidecode output --
these do not change with different kernels.
Comment 26 Len Brown 2007-08-29 01:09:32 UTC
> 2.6.20-16-generic

Is there any difference if you run a kernel.org 2.6.22.stable kernel?
Comment 27 r 2007-08-29 01:10:31 UTC
Created attachment 12604 [details]
cat /proc/interupts with "acpi=force pci=noacpi" to kernel
Comment 28 r 2007-08-29 01:15:47 UTC
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.
Comment 29 Len Brown 2007-08-29 01:17:13 UTC
           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?
Comment 30 Len Brown 2007-08-29 01:22:16 UTC
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 31 r 2007-08-29 01:26:06 UTC
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. 
Comment 32 Len Brown 2007-08-29 01:26:46 UTC
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?
Comment 33 Len Brown 2007-08-29 01:32:17 UTC
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)
Comment 34 r 2007-08-29 01:56:25 UTC
Created attachment 12605 [details]
cat /proc/interrupts with "acpi=force pci=noacpi pci=biosirq"
Comment 35 r 2007-08-29 01:56:52 UTC
Created attachment 12606 [details]
dmesg -s64000  with "acpi=force pci=noacpi pci=biosirq"
Comment 36 r 2007-08-29 01:58:12 UTC
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!
Comment 37 r 2007-08-29 01:58:41 UTC
Created attachment 12608 [details]
open computer, 2
Comment 38 r 2007-08-29 02:14:20 UTC
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. 
Comment 39 ykzhao 2007-08-29 18:05:46 UTC
(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.
Comment 40 r 2007-08-30 09:08:12 UTC
Created attachment 12632 [details]
cat /proc/interrupts with acpi=off
Comment 41 r 2007-08-30 09:08:49 UTC
Created attachment 12633 [details]
cat /proc/interrupts with acpi=force pci=noacpi
Comment 42 r 2007-08-30 09:09:16 UTC
Created attachment 12634 [details]
cat /proc/interrupts with acpi=force noapic
Comment 43 r 2007-08-30 09:09:44 UTC
Here you are. Hope it will help. 
Comment 44 Len Brown 2007-08-31 14:12:00 UTC
> 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.
Comment 45 Len Brown 2007-08-31 14:27:06 UTC
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.
Comment 46 Len Brown 2007-08-31 14:32:53 UTC
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.
Comment 47 r 2007-09-01 03:18:55 UTC
(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. 
Comment 48 r 2007-09-01 03:19:46 UTC
Created attachment 12645 [details]
cat_proc_interrupts no_option after_bios_default & restore
Comment 49 r 2007-09-01 03:20:24 UTC
Created attachment 12646 [details]
dmesg -s64000 no_option after_bios_default & restore
Comment 50 r 2007-09-01 03:21:05 UTC
Created attachment 12647 [details]
cat_proc_interrupts acpi_force after_bios_default & restore
Comment 51 r 2007-09-01 03:21:38 UTC
Created attachment 12648 [details]
dmesg -s64000 acpi_force_after_bios_default & restore
Comment 52 r 2007-09-01 04:17:49 UTC
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. 
Comment 53 r 2007-09-01 04:18:22 UTC
Created attachment 12649 [details]
cat_proc_interrupts_2.6.22-10_no_option
Comment 54 r 2007-09-01 04:18:42 UTC
Created attachment 12650 [details]
dmesg_2.6.22-10_no_option
Comment 55 r 2007-09-01 04:19:05 UTC
Created attachment 12651 [details]
cat_proc_interrupts_2.6.22-10_acpi_force
Comment 56 r 2007-09-01 04:19:31 UTC
Created attachment 12652 [details]
dmesg_2.6.22-10_acpi_force
Comment 57 Len Brown 2007-09-03 13:45:18 UTC
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.
Comment 58 ykzhao 2007-09-10 02:22:16 UTC
(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.
Comment 59 r 2007-09-10 23:10:37 UTC
(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?)
Comment 60 r 2007-09-10 23:12:05 UTC
Created attachment 12781 [details]
cat /proc/interrupts_2.6.22-10 with options acpi=force pci=noacpi noapic
Comment 61 r 2007-09-10 23:12:41 UTC
Created attachment 12782 [details]
dmesg -s64000 2.6.22-10  with options acpi=force pci=noacpi noapic
Comment 62 r 2007-09-10 23:18:45 UTC
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.
Comment 63 ykzhao 2007-09-29 03:09:04 UTC
Created attachment 12986 [details]
workaround patch 

Please test the system with boot option of acpi=force apic=debug after using the workaround patch.
Comment 64 r 2007-10-17 14:20:04 UTC
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.
> 
Comment 65 r 2007-10-17 14:21:56 UTC
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.
Comment 66 r 2007-10-17 14:22:28 UTC
Created attachment 13192 [details]
cat /proc/interrupts with patch ykhzao "acpi=force apic=debug"
Comment 67 r 2007-10-17 14:23:17 UTC
Created attachment 13193 [details]
.config of the new kernel with patch ykhzao
Comment 68 ykzhao 2007-10-17 19:47:39 UTC
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.
Comment 69 r 2007-10-18 08:50:00 UTC
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.
> 
Comment 70 r 2007-10-18 08:51:48 UTC
Created attachment 13199 [details]
dmidecode for kernel 2.6.20.3 with yakui's patch, wifi is not working. "acpi=force apic=debug"
Comment 71 r 2007-10-18 08:52:41 UTC
Created attachment 13200 [details]
dmidecode for 2.6.20.16 with "acpi=force". Here wifi is working.
Comment 73 r 2007-10-18 09:16:52 UTC
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. 
Comment 74 Edoardo Vacchi 2007-10-22 03:09:17 UTC
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...
Comment 75 Edoardo Vacchi 2007-10-22 04:06:01 UTC
I think this bug is related http://bugzilla.kernel.org/show_bug.cgi?id=8641
Comment 76 r 2007-10-22 12:27:39 UTC
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...
> 
Comment 77 r 2007-10-22 12:28:38 UTC
Created attachment 13238 [details]
dmesg -s64000 of 2.6.20.16 with "acpi=force irqpoll"
Comment 78 r 2007-10-22 12:29:00 UTC
Created attachment 13239 [details]
dmidecode of 2.6.20.16 with "acpi=force irqpoll"
Comment 79 r 2007-10-22 12:29:24 UTC
Created attachment 13240 [details]
cat /proc/interrupts of 2.6.20.16 with "acpi=force irqpoll"
Comment 80 ykzhao 2007-10-22 22:58:36 UTC
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.
Comment 81 r 2007-10-23 01:18:20 UTC
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. 
Comment 82 r 2007-10-23 01:19:52 UTC
Created attachment 13242 [details]
dmesg_2.6.20.3 with yakui patch "acpi=force apic=debug irqpoll"
Comment 83 r 2007-10-23 01:20:23 UTC
Created attachment 13243 [details]
lspci -vvxxxx with yakui patch "acpi=force apic=debug irqpoll"
Comment 84 r 2007-10-23 01:20:56 UTC
Created attachment 13244 [details]
cat proc interrupts with yakui patch "acpi=force apic=debug irqpoll"
Comment 85 r 2007-10-23 01:22:15 UTC
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.
Comment 86 r 2007-10-23 01:22:39 UTC
Created attachment 13246 [details]
lspci -vvxxxx 2.6.20.16 without patch "acpi=force apic=debug irqpoll"
Comment 87 r 2007-10-23 01:24:10 UTC
Created attachment 13247 [details]
cat /proc/interrupts 2.6.20.16 with no patch and "acpi=force apic=debug irqpoll"
Comment 88 ykzhao 2007-10-23 02:50:35 UTC
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.
 
Comment 89 Edoardo Vacchi 2007-10-23 06:19:08 UTC
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
Comment 90 Edoardo Vacchi 2007-10-23 09:26:29 UTC
error:

[   51.042089] phy0 -> rt2x00pci_initialize: Error - IRQ 0 allocation failed (error -16).
Comment 91 r 2007-10-23 15:58:39 UTC
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. 
Comment 92 r 2007-10-23 16:02:45 UTC
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.
Comment 93 ykzhao 2007-10-23 18:27:10 UTC
The .config file is OK. But it is more useful if the debug of PCI and ACPI in kernel configuration is enabled. 
Thanks
Comment 94 r 2007-10-28 11:09:30 UTC
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
> 
Comment 95 r 2007-10-28 11:11:27 UTC
Created attachment 13298 [details]
dmesg -s64000 with patch yzhkao and xconfig debugs; boot options "acpi=force apic=debug"
Comment 96 r 2007-10-28 11:12:00 UTC
Created attachment 13299 [details]
cat /proc/interrupts with patch yzhkao and xconfig debugs; boot options "acpi=force apic=debug"
Comment 97 r 2007-10-28 11:12:27 UTC
Created attachment 13300 [details]
lspci -vvxxxx with patch yzhkao and xconfig debugs; boot options "acpi=force apic=debug"
Comment 98 r 2007-10-28 11:12:50 UTC
Created attachment 13301 [details]
dmesg -s64000 with patch yzhkao and xconfig debugs; boot options "acpi=force apic=debug irqpoll"
Comment 99 r 2007-10-28 11:13:21 UTC
Created attachment 13302 [details]
cat /proc/interrupts with patch yzhkao and xconfig debugs; boot options "acpi=force apic=debug irqpoll"
Comment 100 r 2007-10-28 11:13:54 UTC
Created attachment 13303 [details]
lspci -vvxxxx with patch yzhkao and xconfig debugs; boot options "acpi=force apic=debug irqpoll"
Comment 101 r 2007-10-28 11:14:59 UTC
Let me know if this is enough or if you would like more infos or more tests. 
Comment 102 ykzhao 2007-10-28 18:51:15 UTC
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




   
Comment 103 ykzhao 2007-10-28 19:28:42 UTC
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.
Comment 104 r 2007-10-29 03:44:22 UTC
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.
> 
Comment 105 r 2007-10-29 03:45:50 UTC
Created attachment 13310 [details]
file .config with yakui's workaround patch and debug modules. Hopefully, also wireless module.
Comment 106 Edoardo Vacchi 2007-10-29 03:48:00 UTC
wireless module are rt61pci and rt2x00pci (which is loaded if you modprobe rt61pci if I've understood right)
Comment 107 r 2007-10-29 11:36:54 UTC
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.
> 
Comment 108 r 2007-10-29 11:38:55 UTC
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.
> 
Comment 109 r 2007-10-29 11:45:11 UTC
Created attachment 13319 [details]
dmesg -s64000, with patch yzhkao, rt2x00pci & other debugs, options "acpi=force apic=debug"
Comment 110 r 2007-10-29 11:45:51 UTC
Created attachment 13320 [details]
cat /proc/interrupts, with patch yzhkao, rt2x00pci & other debugs, options "acpi=force apic=debug"
Comment 111 r 2007-10-29 11:46:19 UTC
Created attachment 13321 [details]
lspci -vvxxxx, with patch yzhkao, rt2x00pci & other debugs, options "acpi=force apic=debug"
Comment 112 r 2007-10-29 11:49:38 UTC
Created attachment 13322 [details]
.config, with patch yzhkao, rt2x00pci & other debugs, options "acpi=force apic=debug"
Comment 113 Edoardo Vacchi 2007-11-09 12:39:41 UTC
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)
Comment 114 r 2007-11-11 06:56:53 UTC
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)
> 
Comment 115 Edoardo Vacchi 2007-11-11 07:25:04 UTC
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.
Comment 116 r 2007-11-11 08:10:30 UTC
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.
> 
Comment 117 Edoardo Vacchi 2007-11-11 08:20:52 UTC
they share the same main components 
http://support.packardbell.com/uk/item/index.php?pn=PB42B01101&g=1400
Comment 118 r 2007-11-16 09:39:45 UTC
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.
> > 
> 
Comment 119 ykzhao 2007-11-18 22:28:07 UTC
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.
Comment 120 r 2007-11-19 00:28:47 UTC
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).
Comment 121 ykzhao 2007-11-19 18:59:47 UTC
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.
Comment 122 Edoardo Vacchi 2007-12-05 13:21:25 UTC
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)
Comment 123 Edoardo Vacchi 2007-12-05 13:21:54 UTC
Created attachment 13874 [details]
lspci patch #63 acpi=force initcall_debug
Comment 124 Edoardo Vacchi 2007-12-05 13:22:59 UTC
I don't want to sound too quick, but... looks like *habemus workaround*!

I hope so
Comment 125 Edoardo Vacchi 2007-12-05 13:24:01 UTC
about wireless, I didn't say it is able to scan, so I assume it works
Comment 126 ykzhao 2007-12-06 01:47:46 UTC
Hi, Edoardo
Thanks for your help. From the comment #122 it seems that the wifi and USB can work well.  
Comment 127 ykzhao 2007-12-10 20:36:41 UTC
Created attachment 13965 [details]
the workaround patch about the error BIOS age
Comment 128 ykzhao 2007-12-10 20:39:35 UTC
Created attachment 13966 [details]
the workaround patch about the error _CRS method
Comment 129 ykzhao 2007-12-10 20:53:43 UTC
Will you please test the system after applying the patches in comment #127,128 and attach the dmesg ?
Thanks.
Comment 130 ykzhao 2007-12-13 21:57:09 UTC
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.
Comment 131 Edoardo Vacchi 2007-12-14 00:39:51 UTC
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 ?
Comment 132 ykzhao 2007-12-14 01:08:53 UTC
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.

    
Comment 133 Len Brown 2007-12-14 15:02:32 UTC
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.
Comment 134 Edoardo Vacchi 2007-12-21 11:34:41 UTC
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
Comment 135 r 2007-12-24 02:45:40 UTC
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
Comment 136 Edoardo Vacchi 2008-01-10 10:40:29 UTC
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
Comment 137 Edoardo Vacchi 2008-03-03 00:20:00 UTC
== ENODEV must be changed into == -ENODEV or the patch won't work anymore :)

I still wish there were a kernel parameter for this...
Comment 138 ykzhao 2008-03-03 00:36:40 UTC
Hi, Edoardo
   What you have done is right.
   == ENODEV should be changed into == -ENODEV. 
   Thanks for your work.
   
Comment 139 Edoardo Vacchi 2008-03-27 11:25:01 UTC
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
Comment 140 Paul 2008-10-06 16:37:55 UTC
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.
Comment 141 Edoardo Vacchi 2008-10-06 23:41:45 UTC
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.
Comment 142 ykzhao 2008-10-07 00:36:46 UTC
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).

    
    
Comment 143 ykzhao 2008-10-07 00:38:17 UTC
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.
Comment 144 Paul 2008-10-07 01:31:27 UTC
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
Comment 145 Paul 2008-10-07 01:32:47 UTC
Also, I don't even have a wireless card, so that's not the problem.

Paul
Comment 146 Paul 2008-10-07 01:47:10 UTC
I have submitted by problem as bug 11714 (http://bugzilla.kernel.org/show_bug.cgi?id=11714)

Cheers.
Comment 147 Neil Sandison 2009-10-16 22:12:59 UTC
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

Note You need to log in before you can comment on or make changes to this bug.