* ACPI Compile error in current git (pci.h)
From: Nigel Cunningham @ 2006-03-24 4:04 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-acpi, Greg KH
[-- Attachment #1: Type: text/plain, Size: 601 bytes --]
Hi.
Current git produces the following compile error (x86_64 uniprocessor compile):
arch/x86_64/pci/mmconfig.c:152: error: conflicting types for ‘pci_mmcfg_init’
arch/i386/pci/pci.h:85: error: previous declaration of ‘pci_mmcfg_init’ was here
make[1]: *** [arch/x86_64/pci/mmconfig.o] Error 1
make: *** [arch/x86_64/pci] Error 2
I haven't found out yet how the i386 file is getting included, but I
can say that git compiled fine last night.
Greg, I believe you're the pci guru, so I thought I'd try you too.
Apologies in advance if I've gotten it wrong.
Regards,
Nigel
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* RE: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]
From: Yu, Luming @ 2006-03-24 1:31 UTC (permalink / raw)
To: Sanjoy Mahajan
Cc: linux-kernel, Linus Torvalds, Andrew Morton, Tom Seeley,
Dave Jones, Jiri Slaby, michael, mchehab, Brian Marete,
Ryan Phillips, gregkh, Brown, Len, linux-acpi, Mark Lord,
Randy Dunlap, jgarzik, Duncan, Pavlik Vojtech, Meelis Roos
es it mean we need to slow down acpi_ec_intr_read/write ?
>> Could you try to insert acpi_os_stall (100) after ACPI_DEBUG_PRINT
>> statement both in acpi_ec_intr_read/write.
>
>I added that line in those two places. The result refused to hang with
>acpi_debug_layer=0x00100010, but it did hang (on the usual
>second sleep)
>with it set to 0x10.
Really strange, how several printks could change the results.
Could you try to repalce acpi_os_stall with acpi_os_sleep(1)
in acpi_ec_intr_read/write?
>
>> Hmmm, then I cannot get the ec access log for hang case?!
>
>It seems difficult, but let's keep trying if you have other ideas for
>how to get it.
>
Also, please change I2RB copy to:
Method (I2RBcopy, 3, NotSerialized)
{
Store (Arg0, HCSL)
Store (ShiftLeft (Arg1, 0x01), HMAD)
Store (Arg2, HMCM)
Store (0x0B, HMPR)
Store(CHKS(), local0)
Store(local0, Debug)
Return (local0)
}
And boot with acpi_dbg_layer=0x10 acpi_dbg_level=0x10,
Post full log (Don't edit) for both not hang case, and hang case on
bugzilla.
There should have some clues.
Thanks,
Luming
^ permalink raw reply
* Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]
From: Sanjoy Mahajan @ 2006-03-24 1:17 UTC (permalink / raw)
To: Yu, Luming
Cc: linux-kernel, Linus Torvalds, Andrew Morton, Tom Seeley,
Dave Jones, Jiri Slaby, michael, mchehab, Brian Marete,
Ryan Phillips, gregkh, Brown, Len, linux-acpi, Mark Lord,
Randy Dunlap, jgarzik, Duncan, Pavlik Vojtech, Meelis Roos
In-Reply-To: <3ACA40606221794F80A5670F0AF15F840B417DFC@pdsmsx403>
>> So perhaps I should bisect in _SST and put in the debug lines there?
>> Here's another idea, which is a terrible hack. But there are lots of
>> lines in the DSDT like
>> If (LOr (SPS, WNTF))
>> which I imagine is saying "If something or if WinNT". So,
>> what if Linux
>> pretends to be WinNT (or W98F -- which is another common
>> test), at least
>> for the 600x? Maybe those code paths are known to work.
>>
> Yes, you can try that.
I tried the patch below.
It went to sleep fine. It wouldn't wake up with the Fn key or
closing/opening the lid (both methods wake up Linux sleep). But the
power switch did the trick, and it made it through most of the wakeup.
But the screen came back toofull of garbage and not taking keyboard
input (at least not to X), and it might have been stuck in PCI0._INI.
That was the last Execute Method on the serial console, and after that
line it was just printing dots one at a time: .......
So I had to power it down (by holding the power switch until it turned
off) and could never try the second sleep.
-Sanjoy
summary: Pretend to be Windows 98 in DSDT.
diff -r bf1b330b9a7f -r 8109ef6f6d19 dsdt/600x.dsl
--- a/dsdt/600x.dsl Tue Mar 21 12:11:19 2006 -0500
+++ b/dsdt/600x.dsl Thu Mar 23 19:49:10 2006 -0500
@@ -1090,7 +1090,7 @@ DefinitionBlock ("DSDT.aml", "DSDT", 1,
})
Method (_INI, 0, NotSerialized)
{
- If (LEqual (SCMP (\_OS, "Microsoft Windows"), Zero))
+ If (One) /* LEqual (SCMP (\_OS, "Microsoft Windows"), Zero)) */
{
Store (One, W98F)
}
^ permalink raw reply
* Re: [PATCH: 000/002] Catch notification of memory add event of ACPI via container driver.
From: KAMEZAWA Hiroyuki @ 2006-03-23 23:38 UTC (permalink / raw)
Cc: akpm, y-goto, linux-acpi, linux-kernel, len.brown
In-Reply-To: <20060323221810.8A0B.Y-GOTO@jp.fujitsu.com>
On Thu, 23 Mar 2006 22:41:05 +0900
Yasunori Goto <y-goto@jp.fujitsu.com> wrote:
>These 2 patches are to catch notification of new node's hot-add event via ACPI.
One more thing, this patch works for the case that memory device "PNP0C80" appears
in container device"ACPI0004,PNP0A05,PNP0A06". In this case, ACPI's notify just comes
to container device (not to memory device in it). This patch is necessary to deal with it.
I heared that some of firmwares (will?) use this kind of design, memory in a container,
even if it's not NUMA.
-- Kame.
^ permalink raw reply
* Re: ACPI error in 2.6.16 (AE_TIME, Returned by Handler for EmbeddedControl)
From: Francesco Biscani @ 2006-03-23 22:34 UTC (permalink / raw)
To: Yu, Luming; +Cc: Brown, Len, Linux Kernel Mailing List, linux-acpi
In-Reply-To: <3ACA40606221794F80A5670F0AF15F840B468EFD@pdsmsx403>
On Thursday 23 March 2006 04:46, Yu, Luming wrote:
> Please file this bug on bugzilla.kernel.org
> We need to find out why ?
> Could you post dmesg for ec_intr=0 , ec_intr=1 on bugzilla.
Done:
http://bugzilla.kernel.org/show_bug.cgi?id=6278
Thanks,
Francesco
--
Dr. Francesco Biscani
Dipartimento di Astronomia
Università di Padova
biscani@pd.astro.it
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]
From: Sanjoy Mahajan @ 2006-03-23 19:19 UTC (permalink / raw)
To: Yu, Luming
Cc: linux-kernel, Linus Torvalds, Andrew Morton, Tom Seeley,
Dave Jones, Jiri Slaby, michael, mchehab, Brian Marete,
Ryan Phillips, gregkh, Brown, Len, linux-acpi, Mark Lord,
Randy Dunlap, jgarzik, Duncan, Pavlik Vojtech, Meelis Roos
In-Reply-To: <3ACA40606221794F80A5670F0AF15F840B4692FA@pdsmsx403>
> Does it mean we need to slow down acpi_ec_intr_read/write ?
> Could you try to insert acpi_os_stall (100) after ACPI_DEBUG_PRINT
> statement both in acpi_ec_intr_read/write.
I added that line in those two places. The result refused to hang with
acpi_debug_layer=0x00100010, but it did hang (on the usual second sleep)
with it set to 0x10.
> Hmmm, then I cannot get the ec access log for hang case?!
It seems difficult, but let's keep trying if you have other ideas for
how to get it.
-Sanjoy
`A society of sheep must in time beget a government of wolves.'
- Bertrand de Jouvenal
^ permalink raw reply
* Re: Resume problems on Fujitsu-Siemens AMILO M7440G -- SATA
From: Michael Schierl @ 2006-03-23 19:01 UTC (permalink / raw)
To: martin schneebacher; +Cc: Mark Lord, Shaohua Li, linux-acpi, linux-ide
In-Reply-To: <20060321162547.D6F51CA0A4@ws5-11.us4.outblaze.com>
martin schneebacher schrieb:
> have you ever tried the sata_pm patch from http://tpctl.sourceforge.net/tmp/sata_pm.2.6.15-rc6.patch ?
> i have a intel SATA ICH6M interface and it works fine with this patch.
Tried it against vanilla 2.6.15 - no change.
Michael
^ permalink raw reply
* Re: CONFIG_ACPI_HOTPLUG_MEMORY=m with x86_64 devel tree
From: Andi Kleen @ 2006-03-23 15:37 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki; +Cc: akpm, y-goto, linux-acpi, tony.luck, yo-goto, kmannth
In-Reply-To: <20060323122250.c22003d0.kamezawa.hiroyu@jp.fujitsu.com>
On Thu, Mar 23, 2006 at 12:22:50PM +0900, KAMEZAWA Hiroyuki wrote:
> On 23 Mar 2006 03:43:06 +0100
> Andi Kleen <ak@muc.de> wrote:
>
> >
> > Don't do that.
> > The x86-64 kernel will preallocate memmaps when everything is enabled soon.
> > Ok that won't concern your IA64 machine immediately.
> >
> >
>
> I read hotadd-reserve patches again.. Okay, please preallocate if you want.
>
> Problem I found is:
> 1) Goto's rebuild_zonelist patch will not work if CONFIG_MEMORY_HOTPLUG=n.
> rebuild zonelist is necessary when the system has just memory < 4G at boot,
> and hot add memory > 4G. because x86_64 has DMA32, ZONE_NORAML is not included into
> zonelist at boot time if system doesn't have memory >4G at boot.
>
> 2) zone and node's spanned_pages and present_pages are not incremented. you should do.
Thanks for the review. All good points. Will fix.
I think I just can force the higher zones to be built at boot when there
are any SRATs > 4GB.
I will also add some throttling to prevent the kernel not booting
in the "1TB of hotplug ram" scenario you outlined. Probably just limit
the memory map preallocated to not more than some percentage of the
free RAM.
Just need to figure out a good limit.
Currently mem_map costs about 1.5% of RAM, so not allocating more
than e.g. 5% of RAM to hotplug memmaps would limit the hotplug memory
on a 1GB machine to 3GB. Hmm, maybe 10% but users could be annoyed
if they lose that much memory due to hotplug.
Another problem is that mem_map needs to be contiguous by node,
but that can be handled with existing functions by checking the e820 map.
-Andi
^ permalink raw reply
* Re: ACPI error in 2.6.16 (AE_TIME, Returned by Handler for EmbeddedControl)
From: Francesco Biscani @ 2006-03-23 13:52 UTC (permalink / raw)
To: Yu, Luming; +Cc: Brown, Len, Linux Kernel Mailing List, linux-acpi
In-Reply-To: <3ACA40606221794F80A5670F0AF15F840B468EFD@pdsmsx403>
On Thursday 23 March 2006 04:46, Yu, Luming wrote:
> Please file this bug on bugzilla.kernel.org
> We need to find out why ?
> Could you post dmesg for ec_intr=0 , ec_intr=1 on bugzilla.
>
>
> Thanks,
> Luming
>
Ok, I'll do it later today ASAP. I'll post when done.
Thanks,
Francesco
--
Dr. Francesco Biscani
Dipartimento di Astronomia
Università di Padova
biscani@pd.astro.it
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH: 002/002] Catch notification of memory add event of ACPI via container driver.(avoid redundant call add_memory)
From: Yasunori Goto @ 2006-03-23 13:44 UTC (permalink / raw)
To: Andrew Morton; +Cc: ACPI-ML, Linux Kernel ML, Brown, Len
In-Reply-To: <20060323221810.8A0B.Y-GOTO@jp.fujitsu.com>
When acpi_memory_device_init() is called at boottime to
register struct memory acpi_memory_device,
acpi_bus_add() are called via acpi_driver_attach().
But it also calls ops->start() function.
It is called even if the memory blocks are initialized at
early boottime. In this case add_memory() return -EEXIST, and
the memory blocks becomes INVALID state even if it is normal.
This is patch to avoid calling add_memory() for already available memory.
Signed-off-by: Yasunori Goto <y-goto@jp.fujitsu.com>
drivers/acpi/acpi_memhotplug.c | 11 +++++++++++
1 files changed, 11 insertions(+)
Index: pgdat9/drivers/acpi/acpi_memhotplug.c
===================================================================
--- pgdat9.orig/drivers/acpi/acpi_memhotplug.c 2006-03-23 19:59:01.000000000 +0900
+++ pgdat9/drivers/acpi/acpi_memhotplug.c 2006-03-23 20:20:04.000000000 +0900
@@ -234,6 +234,17 @@ static int acpi_memory_enable_device(str
* (i.e. memory-hot-remove function)
*/
list_for_each_entry(info, &mem_device->res_list, list) {
+ u64 start_pfn, end_pfn;
+
+ start_pfn= info->start_addr >> PAGE_SHIFT;
+ end_pfn = (info->start_addr + info->length - 1) >> PAGE_SHIFT;
+
+ if (pfn_valid(start_pfn) || pfn_valid(end_pfn)){
+ /* already enabled. try next area */
+ num_enabled++;
+ continue;
+ }
+
result = add_memory(info->start_addr, info->length);
if (result)
continue;
--
Yasunori Goto
^ permalink raw reply
* [PATCH: 001/002] Catch notification of memory add event of ACPI via container driver. (register start func for memory device)
From: Yasunori Goto @ 2006-03-23 13:42 UTC (permalink / raw)
To: Andrew Morton; +Cc: ACPI-ML, Linux Kernel ML, Brown, Len
In-Reply-To: <20060323221810.8A0B.Y-GOTO@jp.fujitsu.com>
This is a patch to call add_memroy() when notify reaches for
new node's add event.
When new node is added, notify of ACPI reaches container device
which means the node.
Container device driver calls acpi_bus_scan() to find and add
belonging devices (which means cpu, memory and so on).
Its function calls add and start function of belonging
devices's driver.
Howevever, current memory hotplug driver just register add function to
create sysfs file for its memory. But, acpi_memory_enable_device()
is not called because it is considered just the case that notify reaches
memory device directly. So, if notify reaches container device
nothing can call add_memory().
This is a patch to create start function which calls add_memory().
add_memory() can be called by this when notify reaches container device.
Signed-off-by: Yasunori Goto <y-goto@jp.fujitsu.com>
drivers/acpi/acpi_memhotplug.c | 22 ++++++++++++++++++++++
1 files changed, 22 insertions(+)
Index: pgdat9/drivers/acpi/acpi_memhotplug.c
===================================================================
--- pgdat9.orig/drivers/acpi/acpi_memhotplug.c 2006-03-23 19:58:48.000000000 +0900
+++ pgdat9/drivers/acpi/acpi_memhotplug.c 2006-03-23 20:20:17.000000000 +0900
@@ -57,6 +57,7 @@ MODULE_LICENSE("GPL");
static int acpi_memory_device_add(struct acpi_device *device);
static int acpi_memory_device_remove(struct acpi_device *device, int type);
+static int acpi_memory_device_start (struct acpi_device *device);
static struct acpi_driver acpi_memory_device_driver = {
.name = ACPI_MEMORY_DEVICE_DRIVER_NAME,
@@ -65,6 +66,7 @@ static struct acpi_driver acpi_memory_de
.ops = {
.add = acpi_memory_device_add,
.remove = acpi_memory_device_remove,
+ .start = acpi_memory_device_start,
},
};
@@ -429,6 +431,26 @@ static int acpi_memory_device_remove(str
return_VALUE(0);
}
+static int
+acpi_memory_device_start (struct acpi_device *device)
+{
+ struct acpi_memory_device *mem_device;
+ int result = 0;
+
+ ACPI_FUNCTION_TRACE("acpi_memory_device_start");
+
+ mem_device = (struct acpi_memory_device *) acpi_driver_data(device);
+
+ if (!acpi_memory_check_device(mem_device)){
+ /* call add_memory func */
+ result = acpi_memory_enable_device(mem_device);
+ if (result)
+ ACPI_DEBUG_PRINT((ACPI_DB_ERROR,
+ "Error in acpi_memory_enable_device\n"));
+ }
+ return_VALUE(result);
+}
+
/*
* Helper function to check for memory device
*/
--
Yasunori Goto
^ permalink raw reply
* [PATCH: 000/002] Catch notification of memory add event of ACPI via container driver.
From: Yasunori Goto @ 2006-03-23 13:41 UTC (permalink / raw)
To: Andrew Morton; +Cc: Yasunori Goto, ACPI-ML, Linux Kernel ML, Brown, Len
Hi.
These 2 patches are to catch notification of new node's hot-add event via ACPI.
They were members of v4 of new node hot-add patches.
However, I would like to merge them at first before other patch.
Because, if these 2 patches are merged into mainline, all new node's memory
can be added to node 0. If not, no memory is added even if other patches are
merged. In addition, there is no opposition to these patches.
To tell the truth, I've posted similer patches a few times to ACPI-ML.
But, unfortunately, there was no response.
So, could you apply these patches to -mm tree?
This patch is for 2.6.16-mm1.
I tested on my ia64 Tiger4 box with my node emulation.
In addition, our firmware team provided us new firmware which can allow hot-add.
These patches worked well on it. :-)
Bye.
------------------------------------------
These 2 patches are to catch notification of new node's hot-add event
via ACPI.
If a new node is added, notification of ACPI reaches container device
which means node, and container driver scans belonging devices.
To call memory device's driver, start function of acpi memory device is
necessary. First patch is to register its function.
In addition, the scanning of memory devices and call add_memory() works
even if memory is registered at boottime.
Second patch is to avoid redundant call of add_memory().
--
Yasunori Goto
^ permalink raw reply
* Re: Suspend Medion Akoya LS
From: L. A. Linden Levy @ 2006-03-23 11:59 UTC (permalink / raw)
To: Garry Williams; +Cc: lindenle, linux-acpi
In-Reply-To: <1143110861.12702.4.camel@localhost>
[-- Attachment #1: Type: text/plain, Size: 1697 bytes --]
Garry,
Thanks. I had actually just figured this out on my own this morning. I
just commented out the shutdown part of my powerbtn.sh script. Since I
dont care to shutdown with the power button I am just going to leave
it this way.
On Thu, 23 Mar 2006 05:47:40 -0500
Garry Williams <gtwilliams@gmail.com> wrote:
> On Mon, 2006-03-20 at 23:59 -0600, L. A. Linden Levy wrote:
> > Hi when I use suspend my machine wont wake up unless i hit the power
> > button but then it shuts down. It is like the keyboard is not
> > registering when it is suspended. Can anyone help me make this work?
> >
> > kernel 2.6.15
>
> Try removing the button action that is specified in a file
> in /etc/acpi/events. It may be named sample.conf, depending on your
> distribution. Then you can safely wake by pressing the power button.
>
> If that solves your problem and you still want to be able to call
> shutdown(8) by hitting the power button, then disable/enable this
> button rule in your suspend script.
>
--
---------------------------------------------
Loren A. Linden Levy
481 Loomis, Department of Physics
University of Illinois at Urbana-Champaign
1110 W. Green St., Urbana, IL 61801-3080
Tel: 217-244-7995 Fax: 217-333-1215
Email: lindenle@uiuc.edu
url: http://w3.physics.uiuc.edu/~lindenle/
_____________________________________________
---------------------------------------------
This email has been cryptographically signed.
Search for "lindenle" at pgp.mit.edu
to obtain my public key which can be used
to verify the authenticity of this message.
_____________________________________________
---------------------------------------------
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: Suspend Medion Akoya LS
From: Garry Williams @ 2006-03-23 10:47 UTC (permalink / raw)
To: L. A. Linden Levy; +Cc: linux-acpi, lindenle
In-Reply-To: <20060320235923.5b6c948b@toodles.lindenlevy.com>
On Mon, 2006-03-20 at 23:59 -0600, L. A. Linden Levy wrote:
> Hi when I use suspend my machine wont wake up unless i hit the power
> button but then it shuts down. It is like the keyboard is not
> registering when it is suspended. Can anyone help me make this work?
>
> kernel 2.6.15
Try removing the button action that is specified in a file
in /etc/acpi/events. It may be named sample.conf, depending on your
distribution. Then you can safely wake by pressing the power button.
If that solves your problem and you still want to be able to call
shutdown(8) by hitting the power button, then disable/enable this button
rule in your suspend script.
--
Garry Williams -- +1 (678) 656-4579
^ permalink raw reply
* RE: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]
From: Yu, Luming @ 2006-03-23 9:10 UTC (permalink / raw)
To: Sanjoy Mahajan
Cc: linux-kernel, Linus Torvalds, Andrew Morton, Tom Seeley,
Dave Jones, Jiri Slaby, michael, mchehab, Brian Marete,
Ryan Phillips, gregkh, Brown, Len, linux-acpi, Mark Lord,
Randy Dunlap, jgarzik, Duncan, Pavlik Vojtech, Meelis Roos
> Good, then the hang should be caused by:
>
> Store (Arg0, HCSL)
> Store (ShiftLeft (Arg1, 0x01), HMAD)
> Store (Arg2, HMCM)
> Store (0x0B, HMPR)
>
> Could you add this at the beginning of this block:
> Store (Arg0, Debug)
> And add this at the end of this block:
> Store( HMPR, Debug)
>
>I added those two lines to the DSDT with only THM0 zone, but with
>nothing else commented out. Below are the dmesgs for one sleep-wake
>cycle, plus an 'acpi -t'. I thought it would hang if I did one more
>cycle, but it didn't. So I tried five more, and it was fine too.
>
>Then I reset /proc/acpi/acpi_debug_layer to 0x10 (the boot paramater is
>acpi_dbg_layer although the /proc file is acpi_debug_layer), and
>unloaded and reloaded the thermal module. And it hung in the
>(expected)
>two cycles. I've seen this behavior before: It won't hang with lots of
>debugging turned on, but it does hang with less debugging. Strange!
Hmmm, then I cannot get the ec access log for hang case?!
acpi_hw_low_level_read(8, data, &ec->common.data_addr);
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Read [%02x] from address
[%02x]\n",
*data, address));
Does it mean we need to slow down acpi_ec_intr_read/write ?
Could you try to insert acpi_os_stall (100) after ACPI_DEBUG_PRINT
statement
both in acpi_ec_intr_read/write.
^ permalink raw reply
* Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]
From: Sanjoy Mahajan @ 2006-03-23 6:25 UTC (permalink / raw)
To: Yu, Luming
Cc: linux-kernel, Linus Torvalds, Andrew Morton, Tom Seeley,
Dave Jones, Jiri Slaby, michael, mchehab, Brian Marete,
Ryan Phillips, gregkh, Brown, Len, linux-acpi, Mark Lord,
Randy Dunlap, jgarzik, Duncan, Pavlik Vojtech, Meelis Roos
In-Reply-To: <3ACA40606221794F80A5670F0AF15F840B468F5D@pdsmsx403>
Good, then the hang should be caused by:
Store (Arg0, HCSL)
Store (ShiftLeft (Arg1, 0x01), HMAD)
Store (Arg2, HMCM)
Store (0x0B, HMPR)
Could you add this at the beginning of this block:
Store (Arg0, Debug)
And add this at the end of this block:
Store( HMPR, Debug)
I added those two lines to the DSDT with only THM0 zone, but with
nothing else commented out. Below are the dmesgs for one sleep-wake
cycle, plus an 'acpi -t'. I thought it would hang if I did one more
cycle, but it didn't. So I tried five more, and it was fine too.
Then I reset /proc/acpi/acpi_debug_layer to 0x10 (the boot paramater is
acpi_dbg_layer although the /proc file is acpi_debug_layer), and
unloaded and reloaded the thermal module. And it hung in the (expected)
two cycles. I've seen this behavior before: It won't hang with lots of
debugging turned on, but it does hang with less debugging. Strange!
> Yes, that's good idea to have separate i2rb copy for THM0 which we are
> hacking.
I tried that, but the ACPI system got a bit sick. It didn't support any
Sn states, for example. So I must have done something wrong and I'll
come back to the idea later.
-Sanjoy
`A society of sheep must in time beget a government of wolves.'
- Bertrand de Jouvenal
eth0: removing device
Unloaded prism54 driver
PM: Preparing system for mem sleep
Stopping tasks: ====================================================|
Execute Method: [\_SB_.LID0._PSW] (Node c1574808)
acpi_ec-0458 [23] ec_intr_read : Read [02] from address [32]
acpi_ec-0508 [23] ec_intr_write : Wrote [06] to address [32]
Execute Method: [\_SB_.SLPB._PSW] (Node c1574708)
Execute Method: [\_S3_] (Node e3f8a988)
Execute Method: [\_PTS] (Node e3f8ab48)
acpi_ec-0458 [23] ec_intr_read : Read [d6] from address [00]
acpi_ec-0508 [23] ec_intr_write : Wrote [96] to address [00]
acpi_ec-0458 [23] ec_intr_read : Read [9f] from address [05]
acpi_ec-0508 [23] ec_intr_write : Wrote [9e] to address [05]
acpi_ec-0458 [22] ec_intr_read : Read [87] from address [16]
acpi_ec-0508 [23] ec_intr_write : Wrote [07] to address [16]
acpi_ec-0458 [22] ec_intr_read : Read [2f] from address [17]
acpi_ec-0508 [23] ec_intr_write : Wrote [2e] to address [17]
acpi_ec-0508 [23] ec_intr_write : Wrote [83] to address [54]
acpi_ec-0508 [23] ec_intr_write : Wrote [83] to address [55]
acpi_ec-0508 [23] ec_intr_write : Wrote [83] to address [56]
acpi_ec-0508 [23] ec_intr_write : Wrote [83] to address [57]
acpi_ec-0508 [23] ec_intr_write : Wrote [83] to address [58]
acpi_ec-0508 [23] ec_intr_write : Wrote [83] to address [59]
acpi_ec-0508 [23] ec_intr_write : Wrote [83] to address [5a]
acpi_ec-0508 [23] ec_intr_write : Wrote [00] to address [5b]
acpi_ec-0508 [23] ec_intr_write : Wrote [83] to address [5c]
acpi_ec-0508 [23] ec_intr_write : Wrote [83] to address [5d]
acpi_ec-0508 [23] ec_intr_write : Wrote [83] to address [5e]
acpi_ec-0508 [23] ec_intr_write : Wrote [83] to address [5f]
acpi_ec-0508 [23] ec_intr_write : Wrote [00] to address [60]
acpi_ec-0508 [23] ec_intr_write : Wrote [83] to address [61]
acpi_ec-0508 [23] ec_intr_write : Wrote [00] to address [62]
acpi_ec-0508 [23] ec_intr_write : Wrote [00] to address [63]
acpi_ec-0458 [23] ec_intr_read : Read [00] from address [3a]
acpi_ec-0508 [23] ec_intr_write : Wrote [00] to address [3a]
acpi_ec-0508 [23] ec_intr_write : Wrote [02] to address [52]
acpi_ec-0508 [23] ec_intr_write : Wrote [09] to address [53]
acpi_ec-0508 [23] ec_intr_write : Wrote [10] to address [74]
acpi_ec-0508 [23] ec_intr_write : Wrote [0a] to address [50]
acpi_ec-0458 [22] ec_intr_read : Read [00] from address [50]
acpi_ec-0458 [22] ec_intr_read : Read [80] from address [51]
acpi_ec-0458 [22] ec_intr_read : Read [80] from address [51]
acpi_ec-0458 [23] ec_intr_read : Read [06] from address [32]
acpi_ec-0508 [23] ec_intr_write : Wrote [16] to address [32]
Execute Method: [\_SI_._SST] (Node e3f8a8c8)
acpi_ec-0508 [23] ec_intr_write : Wrote [03] to address [06]
acpi_ec-0458 [23] ec_intr_read : Read [00] from address [3a]
acpi_ec-0508 [23] ec_intr_write : Wrote [01] to address [3a]
acpi_ec-0508 [23] ec_intr_write : Wrote [01] to address [0e]
acpi_ec-0508 [23] ec_intr_write : Wrote [00] to address [0d]
acpi_ec-0508 [23] ec_intr_write : Wrote [00] to address [0c]
acpi_ec-0508 [23] ec_intr_write : Wrote [80] to address [0e]
acpi_ec-0508 [23] ec_intr_write : Wrote [00] to address [0d]
acpi_ec-0508 [23] ec_intr_write : Wrote [80] to address [0c]
uhci_hcd 0000:00:07.2: suspend_rh
uhci_hcd 0000:00:07.2: uhci_suspend
uhci_hcd 0000:00:07.2: --> PCI D0/legacy
PM: Entering mem sleep
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Back to C!
PM: Finishing wakeup.
Execute Method: [\_GPE._L0B] (Node e3f8a848)
acpi_ec-0458 [23] ec_intr_read : Read [10] from address [4e]
PCI: Found IRQ 11 for device 0000:00:02.0
PCI: Sharing IRQ 11 with 0000:00:06.0
PCI: Sharing IRQ 11 with 0000:01:00.0
acpi_ec-0741 [06] ec_gpe_intr_query : Evaluating _Q42
Execute Method: [\_SB_.PCI0.ISA0.EC0_._Q42] (Node e3f82408)
acpi_ec-0458 [26] ec_intr_read : Read [01] from address [3a]
acpi_ec-0508 [26] ec_intr_write : Wrote [01] to address [3a]
acpi_ec-0508 [26] ec_intr_write : Wrote [02] to address [52]
acpi_ec-0508 [26] ec_intr_write : Wrote [04] to address [53]
acpi_ec-0508 [26] ec_intr_write : Wrote [0b] to address [50]
acpi_ec-0458 [25] ec_intr_read : Read [0b] from address [50]
acpi_ec-0458 [25] ec_intr_read : Read [00] from address [50]
acpi_ec-0458 [25] ec_intr_read : Read [80] from address [51]
acpi_ec-0458 [25] ec_intr_read : Read [80] from address [51]
acpi_ec-0458 [25] ec_intr_read : Read [80] from address [54]
acpi_ec-0458 [25] ec_intr_read : Read [0c] from address [55]
acpi_ec-0458 [25] ec_intr_read : Read [4e] from address [58]
acpi_ec-0458 [25] ec_intr_read : Read [0c] from address [59]
acpi_ec-0458 [25] ec_intr_read : Read [f4] from address [60]
acpi_ec-0458 [25] ec_intr_read : Read [0b] from address [61]
acpi_ec-0458 [25] ec_intr_read : Read [08] from address [62]
acpi_ec-0458 [25] ec_intr_read : Read [0c] from address [63]
PCI: Found IRQ 11 for device 0000:00:02.1
uhci_hcd 0000:00:07.2: PCI legacy resume
PCI: Found IRQ 11 for device 0000:00:07.2
uhci_hcd 0000:00:07.2: uhci_resume
uhci_hcd 0000:00:07.2: uhci_check_and_reset_hc: legsup = 0x2000
uhci_hcd 0000:00:07.2: Performing full reset
usb usb1: root hub lost power or was reset
uhci_hcd 0000:00:07.2: suspend_rh
usb usb1: finish resume
uhci_hcd 0000:00:07.2: wakeup_rh
Restarting tasks...<7>hub 1-0:1.0: state 7 ports 2 chg 0000 evt 0000
done
Execute Method: [\_SI_._SST] (Node e3f8a8c8)
acpi_ec-0508 [26] ec_intr_write : Wrote [01] to address [0e]
acpi_ec-0508 [26] ec_intr_write : Wrote [00] to address [0d]
acpi_ec-0508 [26] ec_intr_write : Wrote [01] to address [0c]
acpi_ec-0508 [26] ec_intr_write : Wrote [80] to address [0e]
acpi_ec-0508 [26] ec_intr_write : Wrote [80] to address [0d]
acpi_ec-0508 [26] ec_intr_write : Wrote [80] to address [0c]
Execute Method: [\_WAK] (Node e3f8aac8)
acpi_ec-0458 [26] ec_intr_read : Read [96] from address [00]
acpi_ec-0508 [26] ec_intr_write : Wrote [d6] to address [00]
acpi_ec-0458 [26] ec_intr_read : Read [16] from address [32]
acpi_ec-0508 [26] ec_intr_write : Wrote [16] to address [32]
acpi_ec-0458 [26] ec_intr_read : Read [16] from address [32]
acpi_ec-0508 [26] ec_intr_write : Wrote [06] to address [32]
acpi_ec-0458 [26] ec_intr_read : Read [06] from address [32]
acpi_ec-0508 [26] ec_intr_write : Wrote [06] to address [32]
acpi_ec-0458 [25] ec_intr_read : Read [34] from address [36]
acpi_ec-0458 [25] ec_intr_read : <7>uhci_hcd 0000:00:07.2: suspend_rh (auto-stop)
Read [14] from address [34]
acpi_ec-0458 [25] ec_intr_read : Read [07] from address [16]
acpi_ec-0508 [26] ec_intr_write : Wrote [87] to address [16]
acpi_ec-0458 [26] ec_intr_read : Read [01] from address [3a]
acpi_ec-0508 [26] ec_intr_write : Wrote [01] to address [3a]
acpi_ec-0508 [26] ec_intr_write : Wrote [81] to address [52]
acpi_ec-0508 [26] ec_intr_write : Wrote [00] to address [53]
acpi_ec-0508 [26] ec_intr_write : Wrote [07] to address [50]
acpi_ec-0458 [25] ec_intr_read : Read [00] from address [50]
acpi_ec-0458 [25] ec_intr_read : Read [90] from address [51]
acpi_ec-0458 [25] ec_intr_read : Read [90] from address [51]
acpi_ec-0458 [25] ec_intr_read : Read [90] from address [51]
acpi_ec-0458 [26] ec_intr_read : Read [06] from address [32]
acpi_ec-0508 [26] ec_intr_write : Wrote [06] to address [32]
acpi_ec-0458 [25] ec_intr_read : Read [0f] from address [28]
acpi_ec-0508 [26] ec_intr_write : Wrote [8f] to address [28]
acpi_ec-0458 [25] ec_intr_read : Read [0f] from address [28]
acpi_ec-0458 [25] ec_intr_read : Read [0f] from address [28]
acpi_ec-0458 [25] ec_intr_read : Read [0f] from address [28]
acpi_ec-0458 [25] ec_intr_read : Read [86] from address [39]
acpi_ec-0508 [26] ec_intr_write : Wrote [18] to address [0e]
acpi_ec-0508 [26] ec_intr_write : Wrote [00] to address [0d]
acpi_ec-0508 [26] ec_intr_write : Wrote [10] to address [0c]
acpi_ec-0458 [25] ec_intr_read : Read [28] from address [17]
acpi_ec-0508 [26] ec_intr_write : Wrote [29] to address [17]
acpi_ec-0458 [26] ec_intr_read : Read [01] from address [3a]
acpi_ec-0508 [26] ec_intr_write : Wrote [01] to address [3a]
acpi_ec-0508 [26] ec_intr_write : Wrote [02] to address [52]
acpi_ec-0508 [26] ec_intr_write : Wrote [04] to address [53]
acpi_ec-0508 [26] ec_intr_write : Wrote [0b] to address [50]
acpi_ec-0458 [25] ec_intr_read : Read [00] from address [50]
acpi_ec-0458 [25] ec_intr_read : Read [00] from address [50]
acpi_ec-0458 [25] ec_intr_read : Read [80] from address [51]
acpi_ec-0458 [25] ec_intr_read : Read [80] from address [51]
acpi_ec-0458 [25] ec_intr_read : Read [80] from address [54]
acpi_ec-0458 [25] ec_intr_read : Read [0c] from address [55]
acpi_ec-0458 [25] ec_intr_read : Read [4e] from address [58]
acpi_ec-0458 [25] ec_intr_read : Read [0c] from address [59]
acpi_ec-0458 [25] ec_intr_read : Read [f4] from address [60]
acpi_ec-0458 [25] ec_intr_read : Read [0b] from address [61]
acpi_ec-0458 [25] ec_intr_read : Read [08] from address [62]
acpi_ec-0458 [25] ec_intr_read : Read [0c] from address [63]
Execute Method: [\_TZ_.THM0._PSV] (Node e3f8be48)
Execute Method: [\_TZ_.THM0._TC1] (Node e3f8bdc8)
Execute Method: [\_TZ_.THM0._TC2] (Node e3f8bd88)
Execute Method: [\_TZ_.THM0._TSP] (Node e3f8bd48)
Execute Method: [\_TZ_.THM0._AC0] (Node e3f8bf48)
acpi_ec-0458 [34] ec_intr_read : Read [00] from address [20]
Execute Method: [\_TZ_.THM0._TMP] (Node e3f8bf88)
acpi_ec-0458 [36] ec_intr_read : Read [01] from address [3a]
acpi_ec-0508 [36] ec_intr_write : Wrote [01] to address [3a]
acpi_ec-0508 [36] ec_intr_write : Wrote [02] to address [52]
acpi_ec-0508 [36] ec_intr_write : Wrote [04] to address [53]
acpi_ec-0508 [36] ec_intr_write : Wrote [0b] to address [50]
acpi_ec-0458 [35] ec_intr_read : Read [00] from address [50]
acpi_ec-0458 [35] ec_intr_read : Read [00] from address [50]
acpi_ec-0458 [35] ec_intr_read : Read [80] from address [51]
acpi_ec-0458 [35] ec_intr_read : Read [80] from address [51]
acpi_ec-0458 [35] ec_intr_read : Read [8a] from address [54]
acpi_ec-0458 [35] ec_intr_read : Read [0c] from address [55]
acpi_ec-0458 [35] ec_intr_read : Read [4e] from address [58]
acpi_ec-0458 [35] ec_intr_read : Read [0c] from address [59]
acpi_ec-0458 [35] ec_intr_read : Read [f4] from address [60]
acpi_ec-0458 [35] ec_intr_read : Read [0b] from address [61]
acpi_ec-0458 [35] ec_intr_read : Read [08] from address [62]
acpi_ec-0458 [35] ec_intr_read : Read [0c] from address [63]
Execute Method: [\_SI_._SST] (Node e3f8a8c8)
acpi_ec-0458 [26] ec_intr_read : Read [01] from address [3a]
acpi_ec-0508 [26] ec_intr_write : Wrote [00] to address [3a]
acpi_ec-0508 [26] ec_intr_write : Wrote [05] to address [06]
acpi_ec-0508 [26] ec_intr_write : Wrote [01] to address [0e]
acpi_ec-0508 [26] ec_intr_write : Wrote [00] to address [0d]
acpi_ec-0508 [26] ec_intr_write : Wrote [01] to address [0c]
acpi_ec-0508 [26] ec_intr_write : Wrote [80] to address [0e]
acpi_ec-0508 [26] ec_intr_write : Wrote [00] to address [0d]
acpi_ec-0508 [26] ec_intr_write : Wrote [00] to address [0c]
Execute Method: [\_SB_.LID0._PSW] (Node c1574808)
acpi_ec-0458 [27] ec_intr_read : Read [06] from address [32]
acpi_ec-0508 [27] ec_intr_write : Wrote [02] to address [32]
Execute Method: [\_SB_.SLPB._PSW] (Node c1574708)
ds: ds_open(socket 0)
ds: ds_open(socket 1)
ds: ds_open(socket 2)
pccard: card ejected from slot 1
PCMCIA: socket e36a8828: *** DANGER *** unable to remove socket power
ds: ds_release(socket 0)
ds: ds_release(socket 1)
# I think this where 'acpi -t' happens
Execute Method: [\_SB_.PCI0.ISA0.EC0_.BAT1._BST] (Node e3f82b48)
acpi_ec-0458 [28] ec_intr_read : Read [00] from address [3a]
acpi_ec-0508 [28] ec_intr_write : Wrote [00] to address [3a]
acpi_ec-0508 [28] ec_intr_write : Wrote [02] to address [52]
acpi_ec-0508 [28] ec_intr_write : Wrote [11] to address [53]
acpi_ec-0508 [28] ec_intr_write : Wrote [0b] to address [50]
acpi_ec-0458 [27] ec_intr_read : Read [00] from address [50]
acpi_ec-0458 [27] ec_intr_read : Read [00] from address [50]
acpi_ec-0458 [27] ec_intr_read : Read [80] from address [51]
acpi_ec-0458 [27] ec_intr_read : Read [80] from address [51]
acpi_ec-0458 [27] ec_intr_read : Read [1c] from address [74]
acpi_ec-0458 [27] ec_intr_read : Read [84] from address [64]
acpi_ec-0458 [27] ec_intr_read : Read [30] from address [65]
acpi_ec-0458 [27] ec_intr_read : Read [ff] from address [60]
acpi_ec-0458 [27] ec_intr_read : Read [66] from address [61]
acpi_ec-0458 [27] ec_intr_read : Read [00] from address [62]
acpi_ec-0458 [27] ec_intr_read : Read [00] from address [63]
acpi_ec-0458 [27] ec_intr_read : Read [00] from address [66]
acpi_ec-0458 [27] ec_intr_read : Read [00] from address [67]
acpi_ec-0458 [27] ec_intr_read : Read [00] from address [54]
acpi_ec-0458 [27] ec_intr_read : Read [86] from address [39]
acpi_ec-0458 [27] ec_intr_read : Read [86] from address [39]
acpi_ec-0458 [27] ec_intr_read : Read [86] from address [39]
Execute Method: [\_SB_.PCI0.ISA0.EC0_.BAT1._BIF] (Node e3f82b88)
acpi_ec-0458 [27] ec_intr_read : Read [86] from address [39]
acpi_ec-0458 [28] ec_intr_read : Read [00] from address [3a]
acpi_ec-0508 [28] ec_intr_write : Wrote [00] to address [3a]
acpi_ec-0508 [28] ec_intr_write : Wrote [02] to address [52]
acpi_ec-0508 [28] ec_intr_write : Wrote [11] to address [53]
acpi_ec-0508 [28] ec_intr_write : Wrote [0b] to address [50]
acpi_ec-0458 [27] ec_intr_read : Read [00] from address [50]
acpi_ec-0458 [27] ec_intr_read : Read [00] from address [50]
acpi_ec-0458 [27] ec_intr_read : Read [80] from address [51]
acpi_ec-0458 [27] ec_intr_read : Read [80] from address [51]
acpi_ec-0458 [27] ec_intr_read : Read [1c] from address [74]
acpi_ec-0458 [27] ec_intr_read : Read [00] from address [54]
acpi_ec-0458 [27] ec_intr_read : Read [20] from address [58]
acpi_ec-0458 [27] ec_intr_read : Read [76] from address [59]
acpi_ec-0458 [27] ec_intr_read : Read [00] from address [5a]
acpi_ec-0458 [27] ec_intr_read : Read [00] from address [5b]
acpi_ec-0458 [27] ec_intr_read : Read [ff] from address [5c]
acpi_ec-0458 [27] ec_intr_read : Read [66] from address [5d]
acpi_ec-0458 [27] ec_intr_read : Read [00] from address [5e]
acpi_ec-0458 [27] ec_intr_read : Read [00] from address [5f]
Execute Method: [\_SB_.PCI0.ISA0.EC0_.BAT0._BST] (Node e3f82f08)
acpi_ec-0458 [28] ec_intr_read : Read [00] from address [3a]
acpi_ec-0508 [28] ec_intr_write : Wrote [00] to address [3a]
acpi_ec-0508 [28] ec_intr_write : Wrote [02] to address [52]
acpi_ec-0508 [28] ec_intr_write : Wrote [10] to address [53]
acpi_ec-0508 [28] ec_intr_write : Wrote [0b] to address [50]
acpi_ec-0458 [27] ec_intr_read : Read [00] from address [50]
acpi_ec-0458 [27] ec_intr_read : Read [00] from address [50]
acpi_ec-0458 [27] ec_intr_read : Read [80] from address [51]
acpi_ec-0458 [27] ec_intr_read : Read [80] from address [51]
acpi_ec-0458 [27] ec_intr_read : Read [1c] from address [74]
acpi_ec-0458 [27] ec_intr_read : Read [c0] from address [64]
acpi_ec-0458 [27] ec_intr_read : Read [30] from address [65]
acpi_ec-0458 [27] ec_intr_read : Read [80] from address [60]
acpi_ec-0458 [27] ec_intr_read : Read [89] from address [61]
acpi_ec-0458 [27] ec_intr_read : Read [00] from address [62]
acpi_ec-0458 [27] ec_intr_read : Read [00] from address [63]
acpi_ec-0458 [27] ec_intr_read : Read [00] from address [66]
acpi_ec-0458 [27] ec_intr_read : Read [00] from address [67]
acpi_ec-0458 [27] ec_intr_read : Read [00] from address [54]
acpi_ec-0458 [27] ec_intr_read : Read [86] from address [38]
acpi_ec-0458 [27] ec_intr_read : Read [86] from address [38]
acpi_ec-0458 [27] ec_intr_read : Read [86] from address [38]
Execute Method: [\_SB_.PCI0.ISA0.EC0_.BAT0._BIF] (Node e3f82f48)
acpi_ec-0458 [27] ec_intr_read : Read [86] from address [38]
acpi_ec-0458 [28] ec_intr_read : Read [00] from address [3a]
acpi_ec-0508 [28] ec_intr_write : Wrote [00] to address [3a]
acpi_ec-0508 [28] ec_intr_write : Wrote [02] to address [52]
acpi_ec-0508 [28] ec_intr_write : Wrote [10] to address [53]
acpi_ec-0508 [28] ec_intr_write : Wrote [0b] to address [50]
acpi_ec-0458 [27] ec_intr_read : Read [00] from address [50]
acpi_ec-0458 [27] ec_intr_read : Read [00] from address [50]
acpi_ec-0458 [27] ec_intr_read : Read [80] from address [51]
acpi_ec-0458 [27] ec_intr_read : Read [80] from address [51]
acpi_ec-0458 [27] ec_intr_read : Read [1c] from address [74]
acpi_ec-0458 [27] ec_intr_read : Read [00] from address [54]
acpi_ec-0458 [27] ec_intr_read : Read [00] from address [58]
acpi_ec-0458 [27] ec_intr_read : Read [87] from address [59]
acpi_ec-0458 [27] ec_intr_read : Read [00] from address [5a]
acpi_ec-0458 [27] ec_intr_read : Read [00] from address [5b]
acpi_ec-0458 [27] ec_intr_read : Read [80] from address [5c]
acpi_ec-0458 [27] ec_intr_read : Read [89] from address [5d]
acpi_ec-0458 [27] ec_intr_read : Read [00] from address [5e]
acpi_ec-0458 [27] ec_intr_read : Read [00] from address [5f]
Execute Method: [\_TZ_.THM0._TMP] (Node e3f8bf88)
acpi_ec-0458 [29] ec_intr_read : Read [00] from address [3a]
acpi_ec-0508 [29] ec_intr_write : Wrote [00] to address [3a]
acpi_ec-0508 [29] ec_intr_write : Wrote [02] to address [52]
acpi_ec-0508 [29] ec_intr_write : Wrote [04] to address [53]
acpi_ec-0508 [29] ec_intr_write : Wrote [0b] to address [50]
acpi_ec-0458 [28] ec_intr_read : Read [00] from address [50]
acpi_ec-0458 [28] ec_intr_read : Read [00] from address [50]
acpi_ec-0458 [28] ec_intr_read : Read [80] from address [51]
acpi_ec-0458 [28] ec_intr_read : Read [80] from address [51]
acpi_ec-0458 [28] ec_intr_read : Read [6c] from address [54]
acpi_ec-0458 [28] ec_intr_read : Read [0c] from address [55]
acpi_ec-0458 [28] ec_intr_read : Read [4e] from address [58]
acpi_ec-0458 [28] ec_intr_read : Read [0c] from address [59]
acpi_ec-0458 [28] ec_intr_read : Read [f4] from address [60]
acpi_ec-0458 [28] ec_intr_read : Read [0b] from address [61]
acpi_ec-0458 [28] ec_intr_read : Read [08] from address [62]
acpi_ec-0458 [28] ec_intr_read : Read [0c] from address [63]
^ permalink raw reply
* RE: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]
From: Yu, Luming @ 2006-03-23 4:46 UTC (permalink / raw)
To: Sanjoy Mahajan
Cc: linux-kernel, Linus Torvalds, Andrew Morton, Tom Seeley,
Dave Jones, Jiri Slaby, michael, mchehab, Brian Marete,
Ryan Phillips, gregkh, Brown, Len, linux-acpi, Mark Lord,
Randy Dunlap, jgarzik, Duncan, Pavlik Vojtech, Meelis Roos
> How about this. The side effect of this change is that _BIF,
>_BST could
> NOT work. But I think it's just ok.
>
>
> Method (I2RB, 3, NotSerialized)
> {
> Store (Arg0, HCSL)
> Store (ShiftLeft (Arg1, 0x01), HMAD)
> Store (Arg2, HMCM)
> Store (0x0B, HMPR)
> /* Return (CHKS ())*/
> }
>
>It hangs in the usual way (2nd sleep). The boot messages had two Fatal
>opcodes, but that must be the _BIF and _BST that you mentioned:
Good, then the hang should be caused by:
Store (Arg0, HCSL)
Store (ShiftLeft (Arg1, 0x01), HMAD)
Store (Arg2, HMCM)
Store (0x0B, HMPR)
Could you add this at the beginning of this block:
Store (Arg0, Debug)
And add this at the end of this block:
Store( HMPR, Debug)
Also change boot option: acpi_debug_layer=0x00100010,
acpi_debug_level=0x10
Let me verify if ec access is just ok.
>
> Execute Method: [\_TZ_.THM0._TMP] (Node e3f8bf88)
> ACPI: Fatal opcode executed
> Execute Method: [\_TZ_.THM0._PSV] (Node e3f8be48)
> Execute Method: [\_TZ_.THM0._TC1] (Node e3f8bdc8)
> Execute Method: [\_TZ_.THM0._TC2] (Node e3f8bd88)
> Execute Method: [\_TZ_.THM0._TSP] (Node e3f8bd48)
> Execute Method: [\_TZ_.THM0._AC0] (Node e3f8bf48)
> Execute Method: [\_TZ_.THM0._SCP] (Node e3f8bec8)
> Execute Method: [\_TZ_.THM0._TMP] (Node e3f8bf88)
> ACPI: Fatal opcode executed
> ACPI: Thermal Zone [THM0] (47 C)
>
>With later modifications (e.g. commenting out one of the Store
>lines), I
>could Return(0x00) instead of commenting out the line. Let me know
>which ones to try.
Probably yes.
>
>One more thought. We know that commenting out the UPDT call in _TMP
>fixes the hang. By bisecting the UPDT method, however, we change every
>call to UPDT, including the one in THM0._TMP. So we're making extra
>changes beyond what is needed to fix the hang (and maybe producing
>another hang?).
>
>But let's continue this bisection since it's almost done. If we
>eventually find the offending statement, we can use the information in
>order to find the smallest change that fixes the hang. We make a copy
>of the original UPDT method, call it UPDTCOPY, say; same for
>I2RB. Then
>THM0._TMP can call EC0.UPDTCOPY(), which calls I2RBCOPY. And we modify
>I2RBCOPY, but we leave I2RB and UPDT alone.
>
Yes, that's good idea to have separate i2rb copy for THM0 which we are
hacking.
^ permalink raw reply
* RE: [RFC/PATCH 2.6.14.7 1/1] ACPI: Atlas ACPI driver
From: Yu, Luming @ 2006-03-23 4:00 UTC (permalink / raw)
To: Jaya Kumar; +Cc: Brown, Len, linux-acpi
>Hi Luming,
>
>Just pinging to see if this patch was okay with you.
Overall, it is good.
And you got my signed-off for this work: :-)
Signed-off-by: Luming Yu <luming.yu@intel.com>
And could you prepare the patch set including my patches
at bug 5749, and send them to akpm, (please CC me and Len brown)?
Thanks,
Luming
>
>Thanks,
>jaya
>
>On 3/14/06, jayakumar.acpi@gmail.com <jayakumar.acpi@gmail.com> wrote:
>> Hi Len, Luming, and ACPI folk,
>>
>> As per the discussion with Luming here:
>> http://marc.theaimsgroup.com/?l=linux-kernel&m=114225584330589&w=2
>> I've made the following changes to the original Atlas patch:
>> - removed __init/__exit as per Bjorn Helgaas' ASUS patch
>> - removed /proc usage and LCD control using _BCM
>> - added Atlas LCD brightness to the generic hotkey driver
>>
>> I've done this patch against 2.6.14.7 + Luming's generic hotkey
>> patch as posted here:
>> http://bugzilla.kernel.org/show_bug.cgi?id=5749
>>
>> Please let me know if it looks okay and if you have any feedback
>> or suggestions.
>>
>> Thanks,
>> Jaya Kumar
>>
>> Signed-off-by: Jaya Kumar <jayakumar.acpi@gmail.com>
>>
>> ---
>>
>> MAINTAINERS | 5 +
>> drivers/acpi/Kconfig | 11 ++++
>> drivers/acpi/Makefile | 1
>> drivers/acpi/atlas_acpi.c | 123
>++++++++++++++++++++++++++++++++++++++++++++++
>> drivers/acpi/hotkey.c | 14 +++++
>> 5 files changed, 154 insertions(+)
>>
>> ---
>>
>> diff -X linux-2.6.14.7/Documentation/dontdiff -uprN
>linux-2.6.14.7-vanilla/drivers/acpi/atlas_acpi.c
>linux-2.6.14.7/drivers/acpi/atlas_acpi.c
>> --- linux-2.6.14.7-vanilla/drivers/acpi/atlas_acpi.c
>1970-01-01 07:30:00.000000000 +0730
>> +++ linux-2.6.14.7/drivers/acpi/atlas_acpi.c 2006-03-14
>10:31:04.538158024 +0800
>> @@ -0,0 +1,123 @@
>> +/*
>> + * atlas_acpi.c - Atlas Wallmount Touchscreen ACPI Extras
>> + *
>> + * Copyright (C) 2006 Jaya Kumar
>> + * Based on Toshiba ACPI by John Belmonte and ASUS ACPI
>> + * This work was sponsored by CIS(M) Sdn Bhd.
>> + *
>> + * This program is free software; you can redistribute it
>and/or modify
>> + * it under the terms of the GNU General Public License as
>published by
>> + * the Free Software Foundation; either version 2 of the
>License, or
>> + * (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General
>Public License
>> + * along with this program; if not, write to the Free Software
>> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
>MA 02111-1307 USA
>> + *
>> + */
>> +
>> +#include <linux/kernel.h>
>> +#include <linux/module.h>
>> +#include <linux/init.h>
>> +#include <linux/types.h>
>> +#include <linux/proc_fs.h>
>> +#include <asm/uaccess.h>
>> +#include <acpi/acpi_drivers.h>
>> +
>> +#define PROC_ATLAS "atlas"
>> +#define ACPI_ATLAS_NAME "Atlas ACPI"
>> +#define ACPI_ATLAS_CLASS "Atlas"
>> +#define ACPI_ATLAS_BUTTON_HID "ASIM0000"
>> +
>> +/* button handling code */
>> +static acpi_status acpi_atlas_button_setup(acpi_handle
>region_handle,
>> + u32 function, void *handler_context,
>void **return_context)
>> +{
>> + *return_context =
>> + (function != ACPI_REGION_DEACTIVATE) ?
>handler_context : NULL;
>> +
>> + return AE_OK;
>> +}
>> +
>> +static acpi_status acpi_atlas_button_handler(u32 function,
>> + acpi_physical_address address,
>> + u32 bit_width, acpi_integer * value,
>> + void *handler_context, void *region_context)
>> +{
>> + acpi_status status;
>> + struct acpi_device *dev;
>> +
>> + dev = (struct acpi_device *) handler_context;
>> + if (function == ACPI_WRITE)
>> + status = acpi_bus_generate_event(dev, 0x80, address);
>> + else {
>> + printk(KERN_WARNING "atlas: shrugged on
>unexpected function"
>> + ":function=%x,address=%x,value=%x\n",
>> + function, (u32)address, (u32)*value);
>> + status = -EINVAL;
>> + }
>> +
>> + return status ;
>> +}
>> +
>> +static int atlas_acpi_button_add(struct acpi_device *device)
>> +{
>> + /* hookup button handler */
>> + return acpi_install_address_space_handler(device->handle,
>> + 0x81, &acpi_atlas_button_handler,
>> + &acpi_atlas_button_setup, device);
>> +}
>> +
>> +static int atlas_acpi_button_remove(struct acpi_device
>*device, int type)
>> +{
>> + acpi_status status;
>> +
>> + status = acpi_remove_address_space_handler(device->handle,
>> + 0x81, &acpi_atlas_button_handler);
>> + if (ACPI_FAILURE(status))
>> + printk(KERN_ERR "Atlas: Error removing addr
>spc handler\n");
>> +
>> + return status;
>> +}
>> +
>> +static struct acpi_driver atlas_acpi_driver = {
>> + .name = ACPI_ATLAS_NAME,
>> + .class = ACPI_ATLAS_CLASS,
>> + .ids = ACPI_ATLAS_BUTTON_HID,
>> + .ops = {
>> + .add = atlas_acpi_button_add,
>> + .remove = atlas_acpi_button_remove,
>> + },
>> +};
>> +
>> +static int atlas_acpi_init(void)
>> +{
>> + int result;
>> +
>> + result = acpi_bus_register_driver(&atlas_acpi_driver);
>> + if (result < 0) {
>> + printk(KERN_ERR "Atlas ACPI: Unable to
>register driver\n");
>> + return -ENODEV;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static void atlas_acpi_exit(void)
>> +{
>> + acpi_bus_unregister_driver(&atlas_acpi_driver);
>> +}
>> +
>> +module_init(atlas_acpi_init);
>> +module_exit(atlas_acpi_exit);
>> +
>> +MODULE_AUTHOR("Jaya Kumar");
>> +MODULE_LICENSE("GPL");
>> +MODULE_DESCRIPTION("Atlas ACPI");
>> +MODULE_SUPPORTED_DEVICE("Atlas ACPI");
>> +
>> diff -X linux-2.6.14.7/Documentation/dontdiff -uprN
>linux-2.6.14.7-vanilla/drivers/acpi/hotkey.c
>linux-2.6.14.7/drivers/acpi/hotkey.c
>> --- linux-2.6.14.7-vanilla/drivers/acpi/hotkey.c
>2006-03-13 13:50:38.000000000 +0800
>> +++ linux-2.6.14.7/drivers/acpi/hotkey.c 2006-03-13
>23:23:46.000000000 +0800
>> @@ -187,6 +187,15 @@ static struct acpi_polling_hotkey pollin
>> .id = 10001,
>> },
>> {
>> + .ids = "ACPILCD00",
>> + .name = "brightness",
>> + .poll_method = "_BCL",
>> + .action_method = "_BCM",
>> + .min = 1,
>> + .max = 31,
>> + .id = 10001,
>> + },
>> + {
>> .ids = "SNY5001",
>> .name = "brightness_default",
>> .poll_method = "GPBR",
>> @@ -268,6 +277,11 @@ struct specific_hotkey_driver_config {
>> .ids = "ATK0100",
>> .driver = NULL,
>> },
>> + {
>> + .name = "Atlas ACPI Extras Driver",
>> + .ids = "ACPILCD00",
>> + .driver = NULL,
>> + },
>> {
>> .name = "",
>> .ids = NULL,
>> diff -X linux-2.6.14.7/Documentation/dontdiff -uprN
>linux-2.6.14.7-vanilla/drivers/acpi/Kconfig
>linux-2.6.14.7/drivers/acpi/Kconfig
>> --- linux-2.6.14.7-vanilla/drivers/acpi/Kconfig 2006-03-12
>22:37:04.000000000 +0800
>> +++ linux-2.6.14.7/drivers/acpi/Kconfig 2006-03-14
>10:30:41.439669528 +0800
>> @@ -193,7 +193,18 @@ config ACPI_ASUS
>> driver is still under development, so if your
>laptop is unsupported or
>> something works not quite as expected, please use
>the mailing list
>> available on the above page
>(acpi4asus-user@lists.sourceforge.net)
>> +
>> +config ACPI_ATLAS
>> + tristate "Atlas Wallmount Touchscreen Extras"
>> + depends on X86
>> + default n
>> + ---help---
>> + This driver is intended for Atlas wallmounted
>touchscreens.
>> + The button events will show up in
>/proc/acpi/events and the lcd
>> + brightness control is controlled using
>/sys/hotkey/brightness
>>
>> + If you have an Atlas wallmounted touchscreen, say
>Y or M here.
>> +
>> config ACPI_IBM
>> tristate "IBM ThinkPad Laptop Extras"
>> depends on X86
>> diff -X linux-2.6.14.7/Documentation/dontdiff -uprN
>linux-2.6.14.7-vanilla/drivers/acpi/Makefile
>linux-2.6.14.7/drivers/acpi/Makefile
>> --- linux-2.6.14.7-vanilla/drivers/acpi/Makefile
>2006-03-13 13:50:38.000000000 +0800
>> +++ linux-2.6.14.7/drivers/acpi/Makefile 2006-03-13
>23:27:48.000000000 +0800
>> @@ -53,6 +53,7 @@ obj-$(CONFIG_ACPI_SYSTEM) += system.o ev
>> obj-$(CONFIG_ACPI_DEBUG) += debug.o
>> obj-$(CONFIG_ACPI_NUMA) += numa.o
>> obj-$(CONFIG_ACPI_ASUS) += asus_acpi.o
>> +obj-$(CONFIG_ACPI_ATLAS) += atlas_acpi.o
>> obj-$(CONFIG_ACPI_IBM) += ibm_acpi.o
>> obj-$(CONFIG_ACPI_TOSHIBA) += toshiba_acpi.o
>> obj-y += scan.o motherboard.o hotkeylib.o
>> diff -X linux-2.6.14.7/Documentation/dontdiff -uprN
>linux-2.6.14.7-vanilla/MAINTAINERS linux-2.6.14.7/MAINTAINERS
>> --- linux-2.6.14.7-vanilla/MAINTAINERS 2006-03-12
>22:36:46.000000000 +0800
>> +++ linux-2.6.14.7/MAINTAINERS 2006-03-13 23:29:01.000000000 +0800
>> @@ -355,6 +355,11 @@ M: ecashin@coraid.com
>> W: http://www.coraid.com/support/linux
>> S: Supported
>>
>> +ATLAS ACPI EXTRAS DRIVER
>> +P: Jaya Kumar
>> +M: jayakumar.acpi@gmail.com
>> +S: Maintained
>> +
>> ATM
>> P: Chas Williams
>> M: chas@cmf.nrl.navy.mil
>> -
>> To unsubscribe from this list: send the line "unsubscribe
>linux-acpi" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
^ permalink raw reply
* Re: CONFIG_ACPI_HOTPLUG_MEMORY=m with x86_64 devel tree
From: KAMEZAWA Hiroyuki @ 2006-03-23 3:59 UTC (permalink / raw)
To: Andi Kleen; +Cc: akpm, y-goto, linux-acpi, tony.luck
In-Reply-To: <20060323024306.GA90581@muc.de>
On 23 Mar 2006 03:43:06 +0100
Andi Kleen <ak@muc.de> wrote:
> > For example, our server (ia64/Fujitsu PrimeQuest) can equip memory from
> > 4G to 1T(maybe 2T in future), and SRAT will *always* say we have possible 1T memory.
> > (Microsoft requires "write all possible memory in SRAT")
> > When we reserve memmap for possible 1T memory, Linux will not work well in minimum 4G
>
> Don't do that.
> The x86-64 kernel will preallocate memmaps when everything is enabled soon.
> Ok that won't concern your IA64 machine immediately.
>
Okay... I took several cups of coffee and understood what you say.and what x86_64 does.
If X86_64=y and CONFIG_MEMORY_HOTPLUG=n, system works like this..
1. preallocate all memmap, for memory range in SRAT. initialize all.
just don't free pages (page struct) at boot time.
2. pre-initialize all pgdat/zone. even if ther are empty.(but have huge amount of
reserved pages(memmap))
3. When add_memory() is called, just call free_page(page) and make pages populated.
4.
5. Only problem is firmware configurated as "small memory + huge SRAT entry".
Correct ?
Note: "enabled" in SRAT just means "you can read this entry". not means "memory is present".
--Kame
^ permalink raw reply
* RE: ACPI error in 2.6.16 (AE_TIME, Returned by Handler for EmbeddedControl)
From: Yu, Luming @ 2006-03-23 3:46 UTC (permalink / raw)
To: Francesco Biscani, Brown, Len
Cc: Linux Kernel Mailing List, linux-acpi, Jiri Slaby
>On Thursday 23 March 2006 02:45, Brown, Len wrote:
>> does this go away if you boot with "ec_intr=0"?
>
>So far it seems like that option solves the problem. But since
>the bug appears
>very erratically I think it's better to wait for a few more reboots.
>
>BTW, when I was testing _without_ ec_intr=0 I got this in the
>log (this
>happened the first reboot after the one mentioned in my previous mail):
>
>Mar 23 03:48:50 kurtz ACPI: read EC, IB not empty
>Mar 23 03:48:50 kurtz ACPI: read EC, OB not full
>Mar 23 03:48:50 kurtz ACPI Exception (evregion-0409): AE_TIME,
>Returned by
>Handler for [EmbeddedControl] [20060127]
>Mar 23 03:48:50 kurtz ACPI Exception (dswexec-0458): AE_TIME,
>While resolving
>operands for [AE_NOT_CONFIGURED] [20060127]
>Mar 23 03:48:50 kurtz ACPI Error (psparse-0517): Method
>parse/execution failed
>[\_SB_.PCI0.ISA_.EC0_._Q20] (Node c13ecbc0), AE_TIME
>
>This is an hp pavilion ze5616ea laptop, FYI.
>
>Thanks and best regards,
>
> Francesco
Please file this bug on bugzilla.kernel.org
We need to find out why ?
Could you post dmesg for ec_intr=0 , ec_intr=1 on bugzilla.
Thanks,
Luming
^ permalink raw reply
* Re: CONFIG_ACPI_HOTPLUG_MEMORY=m with x86_64 devel tree
From: KAMEZAWA Hiroyuki @ 2006-03-23 3:22 UTC (permalink / raw)
To: Andi Kleen; +Cc: akpm, y-goto, linux-acpi, tony.luck, yo-goto
In-Reply-To: <20060323024306.GA90581@muc.de>
On 23 Mar 2006 03:43:06 +0100
Andi Kleen <ak@muc.de> wrote:
>
> Don't do that.
> The x86-64 kernel will preallocate memmaps when everything is enabled soon.
> Ok that won't concern your IA64 machine immediately.
>
>
I read hotadd-reserve patches again.. Okay, please preallocate if you want.
Problem I found is:
1) Goto's rebuild_zonelist patch will not work if CONFIG_MEMORY_HOTPLUG=n.
rebuild zonelist is necessary when the system has just memory < 4G at boot,
and hot add memory > 4G. because x86_64 has DMA32, ZONE_NORAML is not included into
zonelist at boot time if system doesn't have memory >4G at boot.
2) zone and node's spanned_pages and present_pages are not incremented. you should do.
Bye.
-- Kame
^ permalink raw reply
* Re: ACPI error in 2.6.16 (AE_TIME, Returned by Handler for EmbeddedControl)
From: Francesco Biscani @ 2006-03-23 3:01 UTC (permalink / raw)
To: Brown, Len; +Cc: Linux Kernel Mailing List, linux-acpi, Yu, Luming, Jiri Slaby
In-Reply-To: <F7DC2337C7631D4386A2DF6E8FB22B30067BF1BC@hdsmsx401.amr.corp.intel.com>
On Thursday 23 March 2006 02:45, Brown, Len wrote:
> does this go away if you boot with "ec_intr=0"?
So far it seems like that option solves the problem. But since the bug appears
very erratically I think it's better to wait for a few more reboots.
BTW, when I was testing _without_ ec_intr=0 I got this in the log (this
happened the first reboot after the one mentioned in my previous mail):
Mar 23 03:48:50 kurtz ACPI: read EC, IB not empty
Mar 23 03:48:50 kurtz ACPI: read EC, OB not full
Mar 23 03:48:50 kurtz ACPI Exception (evregion-0409): AE_TIME, Returned by
Handler for [EmbeddedControl] [20060127]
Mar 23 03:48:50 kurtz ACPI Exception (dswexec-0458): AE_TIME, While resolving
operands for [AE_NOT_CONFIGURED] [20060127]
Mar 23 03:48:50 kurtz ACPI Error (psparse-0517): Method parse/execution failed
[\_SB_.PCI0.ISA_.EC0_._Q20] (Node c13ecbc0), AE_TIME
This is an hp pavilion ze5616ea laptop, FYI.
Thanks and best regards,
Francesco
--
Dr. Francesco Biscani
Dipartimento di Astronomia
Università di Padova
biscani@pd.astro.it
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: CONFIG_ACPI_HOTPLUG_MEMORY=m with x86_64 devel tree
From: KAMEZAWA Hiroyuki @ 2006-03-23 2:55 UTC (permalink / raw)
To: Andi Kleen; +Cc: akpm, y-goto, linux-acpi, tony.luck
In-Reply-To: <20060323024306.GA90581@muc.de>
On 23 Mar 2006 03:43:06 +0100
Andi Kleen <ak@muc.de> wrote:
> On Thu, Mar 23, 2006 at 09:36:09AM +0900, KAMEZAWA Hiroyuki wrote:
> > On 23 Mar 2006 01:07:59 +0100
> > Andi Kleen <ak@muc.de> wrote:
> >
> > > On Thu, Mar 23, 2006 at 08:27:32AM +0900, KAMEZAWA Hiroyuki wrote:
> > > > On 22 Mar 2006 20:21:34 +0100
> > > > Andi Kleen <ak@muc.de> wrote:
> > > >
> > > > > > It includes add-new-zone/rebuild-zonelist...etc patches, which will be necessary
> > > > > > also for x86_64, even if it's not NUMA.
> > > > >
> > > > > Hmm? x86_64 supports NUMA systems.
> > > > >
> > > > Ah, I know.
> > > > I wrote "even if.." just because we cannot reserve mem_map for not exisiting node.
> > >
> > > Hmm actually I haven't tested it but in theory the reserve hotplug
> > > code should just work if you list the new nodes already in SRAT as empty
> > > hotplug PXMs.
> > >
> > SRAT is required by Microsoft, then most of servers will equip it, I think.
> > And SRAT just tells each cpu's/memory range's a pxm.
> >
> > But allocating memmap for SRAT entry has some problem in big system.
> >
> > For example, our server (ia64/Fujitsu PrimeQuest) can equip memory from
> > 4G to 1T(maybe 2T in future), and SRAT will *always* say we have possible 1T memory.
> > (Microsoft requires "write all possible memory in SRAT")
> > When we reserve memmap for possible 1T memory, Linux will not work well in minimum 4G
>
> Don't do that.
Don't do what ?
> The x86-64 kernel will preallocate memmaps when everything is enabled soon.
> Ok that won't concern your IA64 machine immediately.
>
BTW, why don't you just use SPARSEMEM ? and Goto-san has to consider x86_64 special case
or just should ignore x86_64 ?
- Kame
^ permalink raw reply
* Re: CONFIG_ACPI_HOTPLUG_MEMORY=m with x86_64 devel tree
From: Andi Kleen @ 2006-03-23 2:43 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki; +Cc: akpm, y-goto, linux-acpi, tony.luck
In-Reply-To: <20060323093609.8eb03249.kamezawa.hiroyu@jp.fujitsu.com>
On Thu, Mar 23, 2006 at 09:36:09AM +0900, KAMEZAWA Hiroyuki wrote:
> On 23 Mar 2006 01:07:59 +0100
> Andi Kleen <ak@muc.de> wrote:
>
> > On Thu, Mar 23, 2006 at 08:27:32AM +0900, KAMEZAWA Hiroyuki wrote:
> > > On 22 Mar 2006 20:21:34 +0100
> > > Andi Kleen <ak@muc.de> wrote:
> > >
> > > > > It includes add-new-zone/rebuild-zonelist...etc patches, which will be necessary
> > > > > also for x86_64, even if it's not NUMA.
> > > >
> > > > Hmm? x86_64 supports NUMA systems.
> > > >
> > > Ah, I know.
> > > I wrote "even if.." just because we cannot reserve mem_map for not exisiting node.
> >
> > Hmm actually I haven't tested it but in theory the reserve hotplug
> > code should just work if you list the new nodes already in SRAT as empty
> > hotplug PXMs.
> >
> SRAT is required by Microsoft, then most of servers will equip it, I think.
> And SRAT just tells each cpu's/memory range's a pxm.
>
> But allocating memmap for SRAT entry has some problem in big system.
>
> For example, our server (ia64/Fujitsu PrimeQuest) can equip memory from
> 4G to 1T(maybe 2T in future), and SRAT will *always* say we have possible 1T memory.
> (Microsoft requires "write all possible memory in SRAT")
> When we reserve memmap for possible 1T memory, Linux will not work well in minimum 4G
Don't do that.
The x86-64 kernel will preallocate memmaps when everything is enabled soon.
Ok that won't concern your IA64 machine immediately.
> > Ok there is no code yet to add hotplug cpus to specific nodes later
> > but that would be easy to add.
> >
> We found hot-add-memory-less-node problem now. So, "cpu hot add to a new node"
> will be supported later.
Again should be pretty easy.
-Andi
^ permalink raw reply
* Re: ACPI error in 2.6.16
From: Andrew Morton @ 2006-03-23 2:34 UTC (permalink / raw)
To: Jiri Slaby; +Cc: biscani, linux-kernel, linux-acpi
In-Reply-To: <4421F834.1070602@liberouter.org>
Jiri Slaby <slaby@liberouter.org> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Francesco Biscani napsal(a):
> > Hello,
> >
> > sometimes at boot I get the following from the logs:
> >
> > ACPI: write EC, IB not empty
> > ACPI Exception (evregion-0409): AE_TIME, Returned by Handler for
> > [EmbeddedControl] [20060127]
> > ACPI Error (psparse-0517): Method parse/execution failed
> > [\_SB_.PCI0.ISA_.EC0_.SMRD] (Node c13ecd40), AE_TIME
> > ACPI Error (psparse-0517): Method parse/execution failed [\_SB_.BAT1.UPBI]
> > (Node dbf42720), AE_TIME
> > ACPI Error (psparse-0517): Method parse/execution failed [\_SB_.BAT1.CHBP]
> > (Node dbf42660), AE_TIME
> > ACPI Error (psparse-0517): Method parse/execution failed
> > [\_SB_.PCI0.ISA_.EC0_.SMSL] (Node c13ecce0), AE_TIME
> > ACPI Error (psparse-0517): Method parse/execution failed
> > [\_SB_.PCI0.ISA_.EC0_._Q09] (Node c13ecc40), AE_TIME
> >
> > And after that the battery is reported as absent (even if it is physically
> > present). I get the impression that this happens when rebooting, not
> > from "cold powerons".
> >
> > This did not happen in 2.6.15, it appeared somewhere in 2.6.16-rc series.
> Could you post dmesgs of both, acpidump and .config? Could you bisect them?
>
And please Cc: linux-acpi@vger.kernel.org, thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox