Looks like the BIOS is having wrong value in ACPI _PSS table for bit_width field. Previous code use to ignore the error silently and the new code has a BUG statement to catch the error. With both previous and current code, due to this bug, cpufreq would not have worked correctly on your platform. We need to look at what BIOS has in bit_width field. So, I will have to repeat Len's comment from below. >>Please attach the output from acpidump > acpidump.out into a >>new bugzilla entry here: >>http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI >> >>You can get acpidump from the latest pmtools here: >>http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/ >> Thanks, Venki >-----Original Message----- >From: cpufreq-bounces@xxxxxxxxxxxxxxxxxx >[mailto:cpufreq-bounces@xxxxxxxxxxxxxxxxxx] On Behalf Of >Pallipadi, Venkatesh >Sent: Friday, February 16, 2007 9:49 AM >To: Len Brown; Henri Hunnekens >Cc: cpufreq; linux-acpi@xxxxxxxxxxxxxxx >Subject: RE: kernel BUG at drivers/acpi/osl.c:373! (acpi-cpufreq) > > >Hmm.. I recently changed acpi-cpufreq to use acpi_os_write_port(), >instead of its local copy of read port. Let me look at that patch >again... > >Thanks, >Venki > >>-----Original Message----- >>From: cpufreq-bounces@xxxxxxxxxxxxxxxxxx >>[mailto:cpufreq-bounces@xxxxxxxxxxxxxxxxxx] On Behalf Of Len Brown >>Sent: Friday, February 16, 2007 8:52 AM >>To: Henri Hunnekens >>Cc: cpufreq; linux-acpi@xxxxxxxxxxxxxxx >>Subject: Re: kernel BUG at drivers/acpi/osl.c:373! (acpi-cpufreq) >> >>On Friday 16 February 2007 10:03, Henri Hunnekens wrote: >> >>> Loading the acpi_cpufreq module reports a kernel bug using kernel >>> version 2.6.20. versions 2.6.18 and older work fine. >> >>> kernel BUG at drivers/acpi/osl.c:373! >> >>> [<e0074455>] acpi_cpufreq_target+0x185/0x290 [acpi_cpufreq] >>> [<c037881f>] __cpufreq_driver_target+0x3f/0x50 >>> [<c037a0de>] cpufreq_governor_performance+0x1e/0x30 >>> [<c0378984>] __cpufreq_governor+0x24/0xd0 >>> [<c0378e9b>] __cpufreq_set_policy+0xeb/0x140 >>> [<c03790fe>] cpufreq_set_policy+0x4e/0x80 >>> [<c0379d4a>] cpufreq_add_dev+0x31a/0x3e0 >>> [<c02bdfc9>] sysdev_driver_register+0x59/0xa0 >>> [<c037a027>] cpufreq_register_driver+0x67/0x100 >>> [<e007809d>] acpi_cpufreq_init+0x9d/0xa4 [acpi_cpufreq] >>> [<c01423f7>] sys_init_module+0x137/0x1b90 >>> [<c0104620>] syscall_call+0x7/0xb >>> ======================= >>> Code: f9 10 89 e5 53 89 c3 89 d0 74 12 83 f9 20 74 16 83 f9 >>08 75 16 0f b6 c2 89 >>> da ee eb 12 0f b7 c2 89 da 66 ef eb 09 89 da ef eb 04 <0f> >>0b eb fe 5b 31 c0 5d >>> c3 55 89 e5 5d c3 55 85 c0 89 e5 89 c1 >>> EIP: [<c027dbd9>] acpi_os_write_port+0x2d/0x36 SS:ESP 0068:dd3d1c8c >> >>acpi_status acpi_os_write_port(acpi_io_address port, u32 >>value, u32 width) >>{ >> switch (width) { >> case 8: >> outb(value, port); >> break; >> case 16: >> outw(value, port); >> break; >> case 32: >> outl(value, port); >> break; >> default: >>373: BUG(); >> } >> >> return AE_OK; >>} >> >>Well, acpi_os_write_port itself has not changed -- so it >>is either acpi_cpufreq, cpufreq, or how they've read and >>interpreted the tables. >> >>Please attach the output from acpidump > acpidump.out into a >>new bugzilla entry here: >>http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI >> >>You can get acpidump from the latest pmtools here: >>http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/ >> >>Also, you can build with CONFIG_ACPI_DEBUG=y and boot with >>"acpi_dbg_layer=2" >>plus "acpi_dbg_level=0xffffffff" and capture the console log. >>(or you can set these values after booted in /proc/acpi just before >>you try to load the module) >> >>and, maybe some clues from the cpufreq subsystem will help. >>cpufreq.debug=3 looks like it may give us a clue. >> >>thanks, >>-Len - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
