For those without BK, I have extracted Intel's latest 2.4.x ACPI updates
into patch form:
ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.4/2.4.22-rc2-acpi1.patch.bz2
On 08.18, Jeff Garzik wrote:
> For those without BK, I have extracted Intel's latest 2.4.x ACPI updates
> into patch form:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.4/2.4.22-rc2-acpi1.patch.bz2
The patch has some strange non-ascii chars there:
- the first hunk changes a don't to a don't (an apostrophe to a non-ascii
acute accent...)
- A f?r to a für (I see the current fine on a terminal but not the second)
- Some copyright symbols...
See the 1st, 3rd and 4th hunks in the changes to Configure.help.
--
J.A. Magallon <[email protected]> \ Software is like sex:
werewolf.able.es \ It's better when it's free
Mandrake Linux release 9.2 (Cooker) for i586
Linux 2.4.22-rc2-jam1m (gcc 3.3.1 (Mandrake Linux 9.2 3.3.1-1mdk))
J.A. Magallon wrote:
> On 08.18, Jeff Garzik wrote:
>
>>For those without BK, I have extracted Intel's latest 2.4.x ACPI updates
>>into patch form:
>>
>>ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.4/2.4.22-rc2-acpi1.patch.bz2
>
>
> The patch has some strange non-ascii chars there:
> - the first hunk changes a don't to a don't (an apostrophe to a non-ascii
> acute accent...)
> - A f?r to a für (I see the current fine on a terminal but not the second)
> - Some copyright symbols...
>
> See the 1st, 3rd and 4th hunks in the changes to Configure.help.
Bug Intel, not me.
I personally think they shouldn't be changing non-ACPI-related
Configure.help entries at all, and what you point out was one of the
minor ACPI gaffs I mentioned to Marcelo and Alan.
Jeff
The ISO_8859_1 acute accent, u with diaeresis, and registered sign, have been in Config.info since Feb 2002.
Andy's tools seem to have extended them to 16-bit characters during a merge. A "minor gaff"? Okay, I guess that's fair. He promises that he doesn't know how to type a latin capital A with a circumflex on his keyboard;-).
Moving on... Is the fix to restore the 8-bit characters, or use 7-bit characters?
Thanks,
-Len
> -----Original Message-----
> From: Jeff Garzik [mailto:[email protected]]
> Sent: Monday, August 18, 2003 5:10 PM
> To: J.A. Magallon
> Cc: [email protected]
> Subject: Re: [patch] 2.4.x ACPI updates
>
>
> J.A. Magallon wrote:
> > On 08.18, Jeff Garzik wrote:
> >
> >>For those without BK, I have extracted Intel's latest 2.4.x
> ACPI updates
> >>into patch form:
> >>
> >>ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/patchki
ts/2.4/2.4.22-rc2-acpi1.patch.bz2
>
>
> The patch has some strange non-ascii chars there:
> - the first hunk changes a don't to a don't (an apostrophe to a non-ascii
> acute accent...)
> - A f?r to a für (I see the current fine on a terminal but not the second)
> - Some copyright symbols...
>
> See the 1st, 3rd and 4th hunks in the changes to Configure.help.
Bug Intel, not me.
I personally think they shouldn't be changing non-ACPI-related
Configure.help entries at all, and what you point out was one of the
minor ACPI gaffs I mentioned to Marcelo and Alan.
Jeff
Brown, Len wrote:
> The ISO_8859_1 acute accent, u with diaeresis, and registered sign, have been in Config.info since Feb 2002.
>
> Andy's tools seem to have extended them to 16-bit characters during a merge. A "minor gaff"? Okay, I guess that's fair. He promises that he doesn't know how to type a latin capital A with a circumflex on his keyboard;-).
>
> Moving on... Is the fix to restore the 8-bit characters, or use 7-bit characters?
Just sent a private message, but to relate the process to others as well...
The fix is to ensure that the ACPI updates sent to Marcelo never touch
areas of Documentation/Configure.help that do not relate to ACPI ;-)
Whatever characters are currently in Configure.help, just leave them be :)
Jeff, being a UTF8 fan, is pained saying this...
On Maw, 2003-08-19 at 03:04, Brown, Len wrote:
> The ISO_8859_1 acute accent, u with diaeresis, and registered sign, have been in Config.info since Feb 2002.
>
> Andy's tools seem to have extended them to 16-bit characters during a merge.
> A "minor gaff"? Okay, I guess that's fair. He promises that he
> doesn't know how to type a latin capital A with a circumflex on his
> keyboard;-).
8859-1 is wrong by all accounts even though the file uses it for
historical reasons. If anything his change is a good one since UTF-8
actually has all the accents for even European names (ñ, ŵ , ï etc) many
of which are missing from 8859-1.
For kernel messages we use 7bit ascii and fixed the 8bit oddments to
keep sysklogd happy, for Configure.help it is down picking something. In
the 2.5 case I'd definitely vote for UTF-8 since the configuration tools
are using libraries that grok UTF-8 properly. For 2.4 we might want to
be more conservative and use 7bit since fixing the tools is a PITA and
its wrong in most of the world to emit 8859-1 arbitarily and its wrong
in the USA to emit UTF-8 arbitarily since lots of US folks still use
8859-*
Andy/Jeff/Marcelo,
At Jeff's request, I've back ported ACPICA 20030813 from
http://linux-acpi.bkbits.net/linux-acpi-2.4 into a new tree for 2.4.22:
http://linux-acpi.bkbits.net/linux-acpi-2.4.22
I've restored acpitable.[ch], which was deleted too late for this
release cycle; and will live on until 2.4.23 -- as well as restored
CONFIG_ACPI_HT_ONLY under CONFIG_ACPI; restored the 8-bit characters
that got expanded to 16-bits in a previous merge; and deleted some dmesg
verbiage that Jeff didn't think was appropriate for the baseline kernel.
I exported this a patch and then imported onto a clone of Marcelo's
tree, so it appears as a single cset where the changes that got un-done
never happened. I've done some sanity tests on it, and will test it
some more tomorrow. Take a look at it and let me know if I missed
anything. When Andy is happy with it I'll leave it to him to re-issue a
pull request from Marcelo.
> This includes a rework of the ACPI config and cmdline options. It now
> supports DMI-based blacklisting, and cmdline options have been
> simplified to "acpi=off", "acpi=ht" (use ACPI for CPU enum only) and
> "acpi=force" (to override the blacklist.)
> It also includes some PCI IRQ routing changes, that seem to help some
> people's systems work better.
In addition, the "noapic" flag now works properly when full ACPI is
enabled.
Thanks,
-Len
Ps. The plain patch on top of Marcelo's current tree is available here:
https://sourceforge.net/project/showfiles.php?group_id=36832
----------
This will update the following files:
Documentation/kernel-parameters.txt | 8
Makefile | 2
arch/i386/kernel/acpi.c | 53 ++++-
arch/i386/kernel/acpitable.c | 10
arch/i386/kernel/acpitable.h | 4
arch/i386/kernel/dmi_scan.c | 251 +++++++++++++++++++++++-
arch/i386/kernel/io_apic.c | 14 -
arch/i386/kernel/mpparse.c | 34 ++-
arch/i386/kernel/setup.c | 54 ++---
arch/i386/kernel/smpboot.c | 2
drivers/Makefile | 2
drivers/acpi/Config.in | 2
drivers/acpi/Makefile | 7
drivers/acpi/bus.c | 2
drivers/acpi/executer/exutils.c | 2
drivers/acpi/hardware/hwregs.c | 21 +-
drivers/acpi/osl.c | 27 +-
drivers/acpi/pci_irq.c | 15 +
drivers/acpi/pci_link.c | 100 ++++++---
drivers/acpi/processor.c | 1
drivers/acpi/tables.c | 120 ++++++-----
drivers/acpi/tables/tbconvrt.c | 6
drivers/acpi/tables/tbget.c | 4
drivers/acpi/tables/tbinstal.c | 42 ++--
drivers/acpi/tables/tbrsdt.c | 2
drivers/acpi/tables/tbxfroot.c | 6
drivers/acpi/toshiba_acpi.c | 3
drivers/acpi/utilities/utglobal.c | 6
include/acpi/acconfig.h | 2
include/acpi/acpi_drivers.h | 2
include/acpi/platform/acenv.h | 6
include/asm-i386/io_apic.h | 2
32 files changed, 598 insertions(+), 214 deletions(-)
through these ChangeSets:
<[email protected]> (03/08/19 1.1097)
patch_2.4.22-rc2_to_acpi-2.4-20030813
On Tue, 19 Aug 2003, Brown, Len wrote:
> Andy/Jeff/Marcelo,
>
> At Jeff's request, I've back ported ACPICA 20030813 from
> http://linux-acpi.bkbits.net/linux-acpi-2.4 into a new tree for 2.4.22:
> http://linux-acpi.bkbits.net/linux-acpi-2.4.22
>
> I've restored acpitable.[ch], which was deleted too late for this
> release cycle; and will live on until 2.4.23 -- as well as restored
> CONFIG_ACPI_HT_ONLY under CONFIG_ACPI; restored the 8-bit characters
> that got expanded to 16-bits in a previous merge; and deleted some dmesg
> verbiage that Jeff didn't think was appropriate for the baseline kernel.
>
> I exported this a patch and then imported onto a clone of Marcelo's
> tree, so it appears as a single cset where the changes that got un-done
> never happened. I've done some sanity tests on it, and will test it
> some more tomorrow. Take a look at it and let me know if I missed
> anything. When Andy is happy with it I'll leave it to him to re-issue a
> pull request from Marcelo.
Cool!!
Ill try to take a look at the patch now (having serious conectivity issues
:()
Hi
So had this compile error :
setup.c: In function `parse_cmdline_early':
setup.c:830: `skip_ioapic_setup' undeclared (first use in this function)
setup.c:830: (Each undeclared identifier is reported only once
setup.c:830: for each function it appears in.)
Since just in arch/i386/kernel/io_apic.c, skip_ioapic_setup is declared
and in arch/i386/kernel/Makefile we have
obj-$(CONFIG_X86_IO_APIC) += io_apic.o
I think this is the correct patch.
thanks
On Wed, 2003-08-20 at 19:15, Marcelo Tosatti wrote:
>
>
> On Tue, 19 Aug 2003, Brown, Len wrote:
>
> > Andy/Jeff/Marcelo,
> >
> > At Jeff's request, I've back ported ACPICA 20030813 from
> > http://linux-acpi.bkbits.net/linux-acpi-2.4 into a new tree for 2.4.22:
> > http://linux-acpi.bkbits.net/linux-acpi-2.4.22
> >
> > I've restored acpitable.[ch], which was deleted too late for this
> > release cycle; and will live on until 2.4.23 -- as well as restored
> > CONFIG_ACPI_HT_ONLY under CONFIG_ACPI; restored the 8-bit characters
> > that got expanded to 16-bits in a previous merge; and deleted some dmesg
> > verbiage that Jeff didn't think was appropriate for the baseline kernel.
> >
> > I exported this a patch and then imported onto a clone of Marcelo's
> > tree, so it appears as a single cset where the changes that got un-done
> > never happened. I've done some sanity tests on it, and will test it
> > some more tomorrow. Take a look at it and let me know if I missed
> > anything. When Andy is happy with it I'll leave it to him to re-issue a
> > pull request from Marcelo.
>
> Cool!!
>
> Ill try to take a look at the patch now (having serious conectivity issues
> :()
>
--
S?rgioMB
email: [email protected]
Who gives me one shell, give me everything.
Marcelo,
Here's an update to the ACPI back port to the 2.4.22 tree.
The BK tree and the patch have been replaced with the new version:
http://linux-acpi.bkbits.net/linux-acpi-2.4.22
https://sourceforge.net/project/showfiles.php?group_id=36832
This incorporates feedback from Andy Grover and Patrick Mochel.
It fixed some config dependencies, and followed Patrick's lead
on #ifdef hygiene to address the build issue.
Thanks,
-Len
This will update the following files:
Documentation/Configure.help | 25 +-
Documentation/kernel-parameters.txt | 8
Makefile | 2
arch/i386/kernel/acpi.c | 66 +++++--
arch/i386/kernel/acpitable.c | 10 -
arch/i386/kernel/acpitable.h | 4
arch/i386/kernel/dmi_scan.c | 213 +++++++++++++++++++++++-
arch/i386/kernel/io_apic.c | 14 +
arch/i386/kernel/mpparse.c | 23 +-
arch/i386/kernel/setup.c | 61 ++++--
arch/i386/kernel/smpboot.c | 2
drivers/Makefile | 2
drivers/acpi/Config.in | 2
drivers/acpi/Makefile | 7
drivers/acpi/bus.c | 2
drivers/acpi/executer/exutils.c | 2
drivers/acpi/hardware/hwregs.c | 21 +-
drivers/acpi/osl.c | 27 ++-
drivers/acpi/pci_irq.c | 15 +
drivers/acpi/pci_link.c | 100 +++++++----
drivers/acpi/processor.c | 1
drivers/acpi/tables.c | 120 +++++++------
drivers/acpi/tables/tbconvrt.c | 6
drivers/acpi/tables/tbget.c | 4
drivers/acpi/tables/tbinstal.c | 42 +++-
drivers/acpi/tables/tbrsdt.c | 2
drivers/acpi/tables/tbxfroot.c | 6
drivers/acpi/toshiba_acpi.c | 3
drivers/acpi/utilities/utglobal.c | 6
drivers/hotplug/Config.in | 2
include/acpi/acconfig.h | 2
include/acpi/acpi_drivers.h | 2
include/acpi/platform/acenv.h | 6
include/asm-i386/acpi.h | 44 ++--
include/asm-i386/io_apic.h | 2
include/asm-i386/mpspec.h | 4
include/linux/acpi.h | 21 +-
37 files changed, 625 insertions(+), 254 deletions(-)
through these ChangeSets:
<[email protected]> (03/08/21 1.1100)
acpi-build.patch
<[email protected]> (03/08/21 1.1099)
acpi-20030813-2.4.22-rc2.diff
> -----Original Message-----
> From: Brown, Len
> Sent: Tuesday, August 19, 2003 8:01 PM
> To: Jeff Garzik; Grover, Andrew; 'Marcelo Tosatti'
> Cc: J.A. Magallon; Linux Kernel Mailing List; Alan Cox;
> [email protected]
> Subject: RE: [patch] 2.4.x ACPI updates
>
>
> Andy/Jeff/Marcelo,
>
> At Jeff's request, I've back ported ACPICA 20030813 from
> http://linux-acpi.bkbits.net/linux-acpi-2.4 into a new tree
> for 2.4.22:
> http://linux-acpi.bkbits.net/linux-acpi-2.4.22
>
> I've restored acpitable.[ch], which was deleted too late for
> this release cycle; and will live on until 2.4.23 -- as well
> as restored CONFIG_ACPI_HT_ONLY under CONFIG_ACPI; restored
> the 8-bit characters that got expanded to 16-bits in a
> previous merge; and deleted some dmesg verbiage that Jeff
> didn't think was appropriate for the baseline kernel.
>
> I exported this a patch and then imported onto a clone of
> Marcelo's tree, so it appears as a single cset where the
> changes that got un-done never happened. I've done some
> sanity tests on it, and will test it some more tomorrow.
> Take a look at it and let me know if I missed anything. When
> Andy is happy with it I'll leave it to him to re-issue a pull
> request from Marcelo.
>
> > This includes a rework of the ACPI config and cmdline
> options. It now
> > supports DMI-based blacklisting, and cmdline options have been
> > simplified to "acpi=off", "acpi=ht" (use ACPI for CPU enum only) and
> > "acpi=force" (to override the blacklist.)
>
> > It also includes some PCI IRQ routing changes, that seem to
> help some
> > people's systems work better.
>
> In addition, the "noapic" flag now works properly when full
> ACPI is enabled.
>
> Thanks,
> -Len
>
> Ps. The plain patch on top of Marcelo's current tree is
> available here:
> https://sourceforge.net/project/showfiles.php?group_id=36832
>
> ----------
> This will update the following files:
>
> Documentation/kernel-parameters.txt | 8
> Makefile | 2
> arch/i386/kernel/acpi.c | 53 ++++-
> arch/i386/kernel/acpitable.c | 10
> arch/i386/kernel/acpitable.h | 4
> arch/i386/kernel/dmi_scan.c | 251 +++++++++++++++++++++++-
> arch/i386/kernel/io_apic.c | 14 -
> arch/i386/kernel/mpparse.c | 34 ++-
> arch/i386/kernel/setup.c | 54 ++---
> arch/i386/kernel/smpboot.c | 2
> drivers/Makefile | 2
> drivers/acpi/Config.in | 2
> drivers/acpi/Makefile | 7
> drivers/acpi/bus.c | 2
> drivers/acpi/executer/exutils.c | 2
> drivers/acpi/hardware/hwregs.c | 21 +-
> drivers/acpi/osl.c | 27 +-
> drivers/acpi/pci_irq.c | 15 +
> drivers/acpi/pci_link.c | 100 ++++++---
> drivers/acpi/processor.c | 1
> drivers/acpi/tables.c | 120 ++++++-----
> drivers/acpi/tables/tbconvrt.c | 6
> drivers/acpi/tables/tbget.c | 4
> drivers/acpi/tables/tbinstal.c | 42 ++--
> drivers/acpi/tables/tbrsdt.c | 2
> drivers/acpi/tables/tbxfroot.c | 6
> drivers/acpi/toshiba_acpi.c | 3
> drivers/acpi/utilities/utglobal.c | 6
> include/acpi/acconfig.h | 2
> include/acpi/acpi_drivers.h | 2
> include/acpi/platform/acenv.h | 6
> include/asm-i386/io_apic.h | 2
> 32 files changed, 598 insertions(+), 214 deletions(-)
>
> through these ChangeSets:
>
> <[email protected]> (03/08/19 1.1097)
> patch_2.4.22-rc2_to_acpi-2.4-20030813
>
>
>
Hi Marcelo,
A small update to what you pulled this morning --
fixes config options CONFIG_ACPI_HT_ONLY and CONFIG_HOTPLUG_PCI_ACPI.
I'm looking forward to deleting these #ifdef CONFIG_ACPI_HT_ONLY
When we can (again) delete acpitable.[ch] in 2.4.23.
Please
bk pull http://linux-acpi.bkbits.net/linux-acpi-2.4.22
This
This will update the following files:
drivers/hotplug/Config.in | 5 +++--
include/asm-i386/acpi.h | 7 +++++++
include/linux/acpi.h | 6 ++++++
3 files changed, 16 insertions(+), 2 deletions(-)
through these ChangeSets:
<[email protected]> (03/08/22 1.1107)
linux-acpi-2.4.22.patch
ps. the plain patch is also available here:
http://prdownloads.sourceforge.net/acpi/acpi-20030813-2.4.22-rc2.diff?do
wnload
On Sat, 23 Aug 2003, Marcelo Tosatti wrote:
>
>
> On Fri, 22 Aug 2003, Brown, Len wrote:
>
> > Hi Marcelo,
> > A small update to what you pulled this morning --
> > fixes config options CONFIG_ACPI_HT_ONLY and CONFIG_HOTPLUG_PCI_ACPI.
> >
> > I'm looking forward to deleting these #ifdef CONFIG_ACPI_HT_ONLY
> > When we can (again) delete acpitable.[ch] in 2.4.23.
> >
> > Please
> >
> > bk pull http://linux-acpi.bkbits.net/linux-acpi-2.4.22
> >
> > This
> >
> > This will update the following files:
> >
> > drivers/hotplug/Config.in | 5 +++--
> > include/asm-i386/acpi.h | 7 +++++++
> > include/linux/acpi.h | 6 ++++++
> > 3 files changed, 16 insertions(+), 2 deletions(-)
> >
> > through these ChangeSets:
> >
> > <[email protected]> (03/08/22 1.1107)
> > linux-acpi-2.4.22.patch
>
> Len,
>
> Patch applied, thanks.
>
> Do you have any further information on the ACPI oops reports I sent you?
>
> Thanks
>
>
> > Len,
> >
> > Patch applied, thanks.
Great!
> > Do you have any further information on the ACPI oops
> reports I sent you?
I see this one in my inbox "Subject: 2.4.22-xx powerdown oddities" and
will follow-up.
If there are more, then forward them to me directly -- the mailing lists
have had some really weird latencies lately.
Thanks,
-Len
On Sat, 23 Aug 2003, Brown, Len wrote:
>
> > > Len,
> > >
> > > Patch applied, thanks.
>
> Great!
>
> > > Do you have any further information on the ACPI oops
> > reports I sent you?
>
>
> I see this one in my inbox "Subject: 2.4.22-xx powerdown oddities" and
> will follow-up.
>
> If there are more, then forward them to me directly -- the mailing lists
> have had some really weird latencies lately.
plus this one
ACPI kernel crash with 2.4.22-pre7 on ASUS L3800C
http://marc.theaimsgroup.com/?l=linux-kernel&m=106146576326309&w=2
Thus wrote Marcelo Tosatti:
> ACPI kernel crash with 2.4.22-pre7 on ASUS L3800C
> http://marc.theaimsgroup.com/?l=linux-kernel&m=106146576326309&w=2
Hi,
This is probably a BIOS / hardware bug, a rare occurence actually.
The logs show:
#v+
acpi_power-0363 [64] acpi_power_transition : Error transitioning device [CFAN] to D0
acpi_bus-0496 [63] acpi_bus_set_power : Error transitioning device [CFAN] to D0
acpi_thermal-0549 [62] acpi_thermal_active : Unable to turn cooling device [c12d2528] 'on'
Unable to handle kernel paging request at virtual address 876c33c4
[...]
#v-
(sometimes there's D3 in place of D0, depending on the trip points /
temperature readings), and then the oops follows. Unfortunately, I
can't provide the ksymoops output, as the kernel which the oops was logged
on has been gone long since.
Anyway, this is by no means reproducible, occurs quasi-randomly (more often
when the machine is cold, possibly due to the fact that actual state
transitions take place then), and causes various effects from keventd /
ACPI subsystem locking to system hangs.
Hope that helps, best regards,
--
Karol 'sziwan' Kozimor
[email protected]
Marcelo Tosatti wrote:
>
> On Sat, 23 Aug 2003, Brown, Len wrote:
>
>
>>>>Len,
>>>>
>>>>Patch applied, thanks.
>>
>>Great!
>>
>>
>>>>Do you have any further information on the ACPI oops
>>>
>>>reports I sent you?
>>
>>
>>I see this one in my inbox "Subject: 2.4.22-xx powerdown oddities" and
>>will follow-up.
>>
>>If there are more, then forward them to me directly -- the mailing lists
>>have had some really weird latencies lately.
>
>
> plus this one
>
> ACPI kernel crash with 2.4.22-pre7 on ASUS L3800C
> http://marc.theaimsgroup.com/?l=linux-kernel&m=106146576326309&w=2
Note that i have the same computer on run 2.4 ACPI for months without
problems...
-- eric
Thus wrote Pavel Machek:
> > This is probably a BIOS / hardware bug, a rare occurence actually.
> > The logs show:
> > #v+
> > acpi_power-0363 [64] acpi_power_transition : Error transitioning device [CFAN] to D0
> > acpi_bus-0496 [63] acpi_bus_set_power : Error transitioning device [CFAN] to D0
> > acpi_thermal-0549 [62] acpi_thermal_active : Unable to turn cooling device [c12d2528] 'on'
> > Unable to handle kernel paging request at virtual address 876c33c4
> > [...]
> > #v-
> > (sometimes there's D3 in place of D0, depending on the trip points /
> > temperature readings), and then the oops follows. Unfortunately, I
> > can't provide the ksymoops output, as the kernel which the oops was logged
> > on has been gone long since.
> >
> > Anyway, this is by no means reproducible, occurs quasi-randomly (more often
> You should be able to do echo ? > /proc/acpi/*/fan/state to stress this manually...
Of course. It prints the messages, but doesn't oops. I'm waiting to
reproduce it on 2.4.23-pre here right now.
Best regards,
--
Karol 'sziwan' Kozimor
[email protected]
Hi!
> > ACPI kernel crash with 2.4.22-pre7 on ASUS L3800C
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=106146576326309&w=2
>
> Hi,
> This is probably a BIOS / hardware bug, a rare occurence actually.
> The logs show:
> #v+
> acpi_power-0363 [64] acpi_power_transition : Error transitioning device [CFAN] to D0
> acpi_bus-0496 [63] acpi_bus_set_power : Error transitioning device [CFAN] to D0
> acpi_thermal-0549 [62] acpi_thermal_active : Unable to turn cooling device [c12d2528] 'on'
> Unable to handle kernel paging request at virtual address 876c33c4
> [...]
> #v-
> (sometimes there's D3 in place of D0, depending on the trip points /
> temperature readings), and then the oops follows. Unfortunately, I
> can't provide the ksymoops output, as the kernel which the oops was logged
> on has been gone long since.
>
> Anyway, this is by no means reproducible, occurs quasi-randomly (more often
You should be able to do echo ? > /proc/acpi/*/fan/state to stress this manually...
Pavel
--
Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...
Thus wrote Karol Kozimor:
> > You should be able to do echo ? > /proc/acpi/*/fan/state to stress this manually...
> Of course. It prints the messages, but doesn't oops. I'm waiting to
> reproduce it on 2.4.23-pre here right now.
Gotcha! (see bug http://65.172.181.4/show_bug.cgi?id=1185 for reference)
2.4.23-pre3 (with some patches): first, the messages are printed:
acpi_power-0363 [28] acpi_power_transition : Error transitioning device [CFAN] to D0
acpi_bus-0496 [27] acpi_bus_set_power : Error transitioning device [CFAN] to D0
acpi_thermal-0549 [26] acpi_thermal_active : Unable to turn cooling device [c12d24a8] 'on'
And then, 4 seconds after:
ksymoops 2.4.9 on i686 2.4.23-pre3-xcs. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.23-pre3-xcs/ (default)
-m /usr/src/linux/System.map (default)
Warning: You did not tell me where to find symbol information. I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.
Unable to handle kernel paging request at virtual address 876c33c4
*pde = 00000000
c01fd497
Oops: 0000
CPU: 0
EIP: 0010:[<c01fd497>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010246
eax: 00000000 ebx: 876c33c4 ecx: cff0fd94 edx: 00000006
esi: 876c33c4 edi: cff0fdf0 ebp: c020c608 esp: cff0fd9c
ds: 0018 es: 0018 ss: 0018
Process keventd (pid: 2, stackpage=cff0f000)
Stack: 00001001 c01fe17f 876c33c4 cff0fdc8 cff0fdf0 876c33c4 cff0fe2c c020c686
876c33c4 c020c608 cff0fdf0 00010000 c02cd715 c02cd6ca 00000050 cff0fdf4
cff0fdf4 876c33c4 c0213efe 876c33c4 cff0fdf0 00000000 00800000 c02ce900
Call Trace: [<c01fe17f>] [<c020c686>] [<c020c608>] [<c0213efe>] [<c02142f5>] [<c0214651>] [<c020ca83>] [<c0208e00>] [<c0218342>] [<c02186bf>] [<c0219402>] [<c01ecaa4>] [<c01e484d>] [<c011d02a>] [<c01256b3>] [<c0125580>] [<c0105000>] [<c01058ee>] [<c0125580>]
Code: 80 3b aa 0f 44 c3 5b c3 a1 d4 6b 3d c0 eb f7 8b 44 24 04 c3
>>EIP; c01fd497 <acpi_ns_map_handle_to_node+17/26> <=====
>>ecx; cff0fd94 <_end+fb19fbc/1241e288>
>>edi; cff0fdf0 <_end+fb1a018/1241e288>
>>ebp; c020c608 <acpi_bus_data_handler+0/39>
>>esp; cff0fd9c <_end+fb19fc4/1241e288>
Trace; c01fe17f <acpi_get_data+38/5d>
Trace; c020c686 <acpi_bus_get_device+45/ae>
Trace; c020c608 <acpi_bus_data_handler+0/39>
Trace; c0213efe <acpi_power_get_context+4a/ae>
Trace; c02142f5 <acpi_power_off_device+4a/1a7>
Trace; c0214651 <acpi_power_transition+113/13c>
Trace; c020ca83 <acpi_bus_set_power+170/298>
Trace; c0208e00 <acpi_ut_track_stack_ptr+1f/26>
Trace; c0218342 <acpi_thermal_active+c4/190>
Trace; c02186bf <acpi_thermal_check+29d/2ec>
Trace; c0219402 <acpi_thermal_notify+a9/10a>
Trace; c01ecaa4 <acpi_ev_notify_dispatch+52/75>
Trace; c01e484d <acpi_os_execute_deferred+39/75>
Trace; c011d02a <__run_task_queue+5a/70>
Trace; c01256b3 <context_thread+133/1d0>
Trace; c0125580 <context_thread+0/1d0>
Trace; c0105000 <_stext+0/0>
Trace; c01058ee <arch_kernel_thread+2e/40>
Trace; c0125580 <context_thread+0/1d0>
Code; c01fd497 <acpi_ns_map_handle_to_node+17/26>
00000000 <_EIP>:
Code; c01fd497 <acpi_ns_map_handle_to_node+17/26> <=====
0: 80 3b aa cmpb $0xaa,(%ebx) <=====
Code; c01fd49a <acpi_ns_map_handle_to_node+1a/26>
3: 0f 44 c3 cmove %ebx,%eax
Code; c01fd49d <acpi_ns_map_handle_to_node+1d/26>
6: 5b pop %ebx
Code; c01fd49e <acpi_ns_map_handle_to_node+1e/26>
7: c3 ret
Code; c01fd49f <acpi_ns_map_handle_to_node+1f/26>
8: a1 d4 6b 3d c0 mov 0xc03d6bd4,%eax
Code; c01fd4a4 <acpi_ns_map_handle_to_node+24/26>
d: eb f7 jmp 6 <_EIP+0x6>
Code; c01fd4a6 <acpi_ns_convert_entry_to_handle+0/5>
f: 8b 44 24 04 mov 0x4(%esp,1),%eax
Code; c01fd4aa <acpi_ns_convert_entry_to_handle+4/5>
13: c3 ret
Hope that helps.
Best regards,
--
Karol 'sziwan' Kozimor
[email protected]