Re: BUG: linux 2.6.19 unable to enable acpi
On 1/19/07, Len Brown <[EMAIL PROTECTED]> wrote: On Wednesday 17 January 2007 05:34, you wrote: > On 1/17/07, Matheus Izvekov <[EMAIL PROTECTED]> wrote: > > I just tried the firmwarekit, and here are the results, attached. > > TYVM, thats a very useful tool. > > I do suspect ACPI issues on my new DG965WH MOBO:- > > http://www.intel.com/products/motherboard/DG965WH/index.htm What acpi issues do you suspect? note that linux-acpi@vger.kernel.org may be able to help. cheers, -Len Thanks Len, am still investigating about this new MOBO. Shall post more info here. ~Akula2 - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [0/5] remove ACPI motherboard driver, use PNP system driver instead (take 2)
On Friday 19 January 2007 08:37, emisca wrote: > I have posted some days ago, some problems on resume from suspend to > disk on my motherboard (asus p5ld2 se) related to acpi pnp. The serial > didn't worked after resume. Using pnpacpi=off it worked. > Now using this patch what will be the behaviour? My patches shouldn't change the behavior you're seeing. Since it seems to be related to PNPACPI, can you post the dmesgs with and without pnpacpi=off to linux-acpi? I see the ones on LKML, but it sounds like there was some user error in collecting them. Bjorn - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ACPI _SUN
On Friday 19 January 2007 11:37, Bruno Ducrot wrote: > On Fri, Jan 19, 2007 at 03:26:26PM +0530, Mohan Kumar Jami wrote: > > Hi, > > > > I have couple of questions related to _SUN object. > > > > 1) Is _SUN object be present DSDT tables? > > They are defined under DSDT or RSDT tables as any other ACPI objects > populating the ACPI namespace. The DSDT and all the SSDT's listed in the RSDT are all loaded at boot-time. However, the BIOS AML can also explicitly Load additional "dynamic" SSDTs at run-time -- and can also Unload an SSDT. In this way, objects in the name space can appear and go away at run-time. _SUN, Slot User Number, is an (optional) property of an object. So for it to change at run-time, the object that contains it would have to go away and then come back. cheers, -Len > > 2) How this DSDT table get updated? > > They can't be updated. > > > 3) Is DSDT table is static binary file or it can be dynamically updated? > > A DSDT table is not a static binary file. On most i386 or amd64 > architectures, DSDT and SSDT are part of the BIOS. > The BIOS uncompressed and copyied them into main memory at the > POST stage since the ROM is too limited in size. > > > 4) Who will update the DSDT tables? > > By the customer via BIOS updates obtained from the vendor. > > Cheers, > - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 1/5] ACPI: move FADT resource reservations from motherboard driver to osl
On Thursday 18 January 2007 18:12, Shaohua Li wrote: > > +device_initcall(acpi_reserve_resources); > Will this be called before PCI assigned resources to PCI devices? We use > fs_initcall in motherboard to avoid PCI devices use motherboard's > resources before. I think we're OK. Here's the current order: pnp_system_initfs_initcall drivers/pnp/system.c pcibios_assign_resources fs_initcall arch/i386/pci/i386.c acpi_reserve_resources device_initcall drivers/acpi/osl.c So pnp_system_init() will reserve all the motherboard resources before the PCI resources are assigned. What do you think? Bjorn - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fan speeds on HP nc6400 and nc8430
Pieter De Wit napisał(a): > Hi Luming, > > This module was build into the kernel. After make it a module and making > sure it's not loaded, I still see the problem. Here is a more detailed > problem: > > If I leave ACPI to manage the system, thermal zone TZ4 stays around 80 > C. The moment I turn on fan C318, this zone *shoots* up to 100 C and > stays there, no matter what. This fan I can't turn off again. > > Here is a cat of fans, thermal_zone status and temp. > > status: on > status: off > status: on > status: on > status: on > status: on > status: on > state: active[2] > state: ok > state: ok > state: ok > state: ok > temperature: 65 C > temperature: 61 C > temperature: 54 C > temperature: 30 C > temperature: 100 C > > This was taken during the compile of gcc. While not doing anything, the > second zone drops to 54 C (currently at 61) Show: cat /proc/acpi/thermal_zone/TZ0/trip_points or change TZ0 to TZ1 For many HP notebooks first trip point is to low. To change manually, for example: echo "105:100:100:78:70:60:50" > /proc/acpi/thermal_zone/TZ0/trip_points echo 10 > /proc/acpi/thermal_zone/TZ0/polling_frequency Then I have: [EMAIL PROTECTED]:~$ cat /proc/acpi/thermal_zone/TZ0/trip_points critical (S5): 105 C active[0]: 78 C: devices=0xcf7aea40 active[1]: 70 C: devices=0xcf7ae9dc active[2]: 60 C: devices=0xcf7ae98c active[3]: 50 C: devices=0xcf7ae93c [EMAIL PROTECTED]:~$ cat /proc/acpi/thermal_zone/TZ0/polling_frequency polling frequency: 10 seconds -- Maciej Rutecki <[EMAIL PROTECTED]> http://www.unixy.pl LTG - Linux Testers Group (http://www.stardust.webpages.pl/ltg/wiki/) smime.p7s Description: S/MIME Cryptographic Signature
Re: ACPI _SUN
On Fri, Jan 19, 2007 at 03:26:26PM +0530, Mohan Kumar Jami wrote: > Hi, > > I have couple of questions related to _SUN object. > > 1) Is _SUN object be present DSDT tables? They are defined under DSDT or RSDT tables as any other ACPI objects populating the ACPI namespace. > 2) How this DSDT table get updated? They can't be updated. > 3) Is DSDT table is static binary file or it can be dynamically updated? A DSDT table is not a static binary file. On most i386 or amd64 architectures, DSDT and SSDT are part of the BIOS. The BIOS uncompressed and copyied them into main memory at the POST stage since the ROM is too limited in size. > 4) Who will update the DSDT tables? By the customer via BIOS updates obtained from the vendor. Cheers, -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [0/5] remove ACPI motherboard driver, use PNP system driver instead (take 2)
I have posted some days ago, some problems on resume from suspend to disk on my motherboard (asus p5ld2 se) related to acpi pnp. The serial didn't worked after resume. Using pnpacpi=off it worked. Now using this patch what will be the behaviour? Bye 2007/1/19, Bjorn Helgaas <[EMAIL PROTECTED]>: The ACPI motherboard driver is mostly redundant with the PNP system driver. This series moves the little bit of ACPI-specific stuff out of the motherboard driver into acpi/osl.c, adds a little bit to the PNP system driver so it covers all the remaining functionality of the ACPI driver, and removes the ACPI driver. Thanks for the comments on the previous version. This set of patches: - Makes acpi_reserve_resources() a device_initcall(), so the FADT resources will be reserved after the pnp/system driver claims its resources. This lets us reserve a motherboard region larger than the FADT describes without conflicts. - Adds CONFIG_PNPACPI=y to the i386/defconfig patch. This is needed for the pnp/system driver to find its devices. Len asked about the CONFIG_PNP=n, CONFIG_ACPI=y case. In this case, we won't have a pnp/system driver to claim motherboard resources. But we already have this situation with other devices. My IR device responds to ioports 0x100-0x10f and my ECP parallel port responds to ioports 0x778-0x77a. If those drivers aren't loaded (or if they aren't smart enough to claim all the resources), the resources just aren't claimed. So I think a better solution for this problem would be to make the PNP core reserve all the regions for every active device, similar to what PCI does. Bjorn - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fan speeds on HP nc6400 and nc8430
The TZ4 thermal zone on all the hp compaq line nx and nc is not a temperature but the fan speed. You can see this information on the web and on hp forums. I really don't know why hp has done this.. With my nx7400 I have problems with fans only when I resume from suspend to disk and the thermal module is loaded by initramfs before resuming the system. I have also noticed that these laptops consume more energy on linux than on windows. I think that's a problem related to acpi C states. On AC I have only C1 and C2 on both cpu cores, on battery I have C1, C2 on first core and C1, C2, C3 on the second. Why there are no higher C-states? Bye 2007/1/19, Alexey Starikovskiy <[EMAIL PROTECTED]>: Did you try patches from #5534 and #7122? Pieter De Wit wrote: > Hi Luming, > > This module was build into the kernel. After make it a module and making > sure it's not loaded, I still see the problem. Here is a more detailed > problem: > > If I leave ACPI to manage the system, thermal zone TZ4 stays around 80 > C. The moment I turn on fan C318, this zone *shoots* up to 100 C and > stays there, no matter what. This fan I can't turn off again. > > Here is a cat of fans, thermal_zone status and temp. > > status: on > status: off > status: on > status: on > status: on > status: on > status: on > state: active[2] > state: ok > state: ok > state: ok > state: ok > temperature: 65 C > temperature: 61 C > temperature: 54 C > temperature: 30 C > temperature: 100 C > > This was taken during the compile of gcc. While not doing anything, the > second zone drops to 54 C (currently at 61) > > Thanks for the time, > > Pieter > > -Original Message- > From: Luming Yu [mailto:[EMAIL PROTECTED] > Sent: 2007/01/19 10:14 > To: Pieter De Wit > Cc: linux-acpi@vger.kernel.org > Subject: Re: Fan speeds on HP nc6400 and nc8430 > > Do you have psmouse module loaded ? > (i.e. CONFIG_MOUSE_PS2=m) > If yes, Please try remove it, and re-test it. > > Thanks, > Luming > > On 1/19/07, Pieter De Wit <[EMAIL PROTECTED]> wrote: > >> Hello List, >> >> I have noted that the fan speed on "idle" is much higher in Linux >> compared to XP. I have also noted that once fans are turned on, they >> never seem to return to the off state. I am currently using the 2.6.18 >> > > >> kernel from Gentoo (gentoo-sources-r6). I was wondering if there is a >> way I can lower the fan speed, or even assist the devs to get info >> regarding these notebooks (if any is needed). >> >> Thanks, >> >> Pieter >> "This e-mail is sent on the Terms and Conditions that can be accessed >> > by Clicking on this link http://www.vodacom.co.za/legal/email.jsp " > >> - >> To unsubscribe from this list: send the line "unsubscribe linux-acpi" >> in the body of a message to [EMAIL PROTECTED] More majordomo >> info at http://vger.kernel.org/majordomo-info.html >> >> > "This e-mail is sent on the Terms and Conditions that can be accessed by Clicking on this link http://www.vodacom.co.za/legal/email.jsp " > - > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fan speeds on HP nc6400 and nc8430
Did you try patches from #5534 and #7122? Pieter De Wit wrote: Hi Luming, This module was build into the kernel. After make it a module and making sure it's not loaded, I still see the problem. Here is a more detailed problem: If I leave ACPI to manage the system, thermal zone TZ4 stays around 80 C. The moment I turn on fan C318, this zone *shoots* up to 100 C and stays there, no matter what. This fan I can't turn off again. Here is a cat of fans, thermal_zone status and temp. status: on status: off status: on status: on status: on status: on status: on state: active[2] state: ok state: ok state: ok state: ok temperature: 65 C temperature: 61 C temperature: 54 C temperature: 30 C temperature: 100 C This was taken during the compile of gcc. While not doing anything, the second zone drops to 54 C (currently at 61) Thanks for the time, Pieter -Original Message- From: Luming Yu [mailto:[EMAIL PROTECTED] Sent: 2007/01/19 10:14 To: Pieter De Wit Cc: linux-acpi@vger.kernel.org Subject: Re: Fan speeds on HP nc6400 and nc8430 Do you have psmouse module loaded ? (i.e. CONFIG_MOUSE_PS2=m) If yes, Please try remove it, and re-test it. Thanks, Luming On 1/19/07, Pieter De Wit <[EMAIL PROTECTED]> wrote: Hello List, I have noted that the fan speed on "idle" is much higher in Linux compared to XP. I have also noted that once fans are turned on, they never seem to return to the off state. I am currently using the 2.6.18 kernel from Gentoo (gentoo-sources-r6). I was wondering if there is a way I can lower the fan speed, or even assist the devs to get info regarding these notebooks (if any is needed). Thanks, Pieter "This e-mail is sent on the Terms and Conditions that can be accessed by Clicking on this link http://www.vodacom.co.za/legal/email.jsp " - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html “This e-mail is sent on the Terms and Conditions that can be accessed by Clicking on this link http://www.vodacom.co.za/legal/email.jsp " - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: PROBLEM: CPU fan shuts down on load of fan.ko in kernel 2.6.18 and later
>Why do we bother with the "acpi_bus_get_power" at all? The problem
>Matthew is seeing wouldn't happen at all if we just deleted everything
>in the force_power_state block.
>
>Then we could execute _ON, _PS0, etc for a device that is already on.
>Does that cause bad things to happen? I assume the fan probably works
>as desired under Windows, so they probably do something like this.
This would work for _PSx (if device power states are controlled via _PSx
methods, we should only execute method, defined for desired power
state), but if power states are controlled via power resources, we
should execute _ON method of power resource, assigned for desired state
AND _OFF method of power resource, assigned for the current power state,
so we cannot just ignore the current device power state.
Regards.
Konstantin.
>-Original Message-
>From: [EMAIL PROTECTED] [mailto:linux-acpi-
>[EMAIL PROTECTED] On Behalf Of Bjorn Helgaas
>Sent: Tuesday, January 16, 2007 7:54 PM
>To: Karasyov, Konstantin A
>Cc: Alexey Starikovskiy; Matthew Brett; Salatiel Filho; linux-
>[EMAIL PROTECTED]
>Subject: Re: PROBLEM: CPU fan shuts down on load of fan.ko in kernel
2.6.18
>and later
>
>On Monday 15 January 2007 06:33, Karasyov, Konstantin A wrote:
>> The fan device FAN1 defines object FN01 as its power resource. _STA
>> method of FN01 always return 0x01, i.e. resource is on. So the fan
>> driver is unable to turn the fan on, because it thinks that it is
>> already in that state.
>
>The code looks like this:
>
>int acpi_bus_set_power(acpi_handle handle, int state)
>{
> ...
> if (!device->flags.force_power_state) {
> if (device->power.state == ACPI_STATE_UNKNOWN)
> acpi_bus_get_power(device->handle,
&device->power.state)
> if (state == device->power.state) {
> return 0; /* already at desired state */
> }
> ...
> acpi_power_transition(device, state);
>
>Why do we bother with the "acpi_bus_get_power" at all? The problem
>Matthew is seeing wouldn't happen at all if we just deleted everything
>in the force_power_state block.
>
>Then we could execute _ON, _PS0, etc for a device that is already on.
>Does that cause bad things to happen? I assume the fan probably works
>as desired under Windows, so they probably do something like this.
>
>Bjorn
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-acpi"
in
>the body of a message to [EMAIL PROTECTED]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Fan speeds on HP nc6400 and nc8430
Hi Luming, This module was build into the kernel. After make it a module and making sure it's not loaded, I still see the problem. Here is a more detailed problem: If I leave ACPI to manage the system, thermal zone TZ4 stays around 80 C. The moment I turn on fan C318, this zone *shoots* up to 100 C and stays there, no matter what. This fan I can't turn off again. Here is a cat of fans, thermal_zone status and temp. status: on status: off status: on status: on status: on status: on status: on state: active[2] state: ok state: ok state: ok state: ok temperature: 65 C temperature: 61 C temperature: 54 C temperature: 30 C temperature: 100 C This was taken during the compile of gcc. While not doing anything, the second zone drops to 54 C (currently at 61) Thanks for the time, Pieter -Original Message- From: Luming Yu [mailto:[EMAIL PROTECTED] Sent: 2007/01/19 10:14 To: Pieter De Wit Cc: linux-acpi@vger.kernel.org Subject: Re: Fan speeds on HP nc6400 and nc8430 Do you have psmouse module loaded ? (i.e. CONFIG_MOUSE_PS2=m) If yes, Please try remove it, and re-test it. Thanks, Luming On 1/19/07, Pieter De Wit <[EMAIL PROTECTED]> wrote: > Hello List, > > I have noted that the fan speed on "idle" is much higher in Linux > compared to XP. I have also noted that once fans are turned on, they > never seem to return to the off state. I am currently using the 2.6.18 > kernel from Gentoo (gentoo-sources-r6). I was wondering if there is a > way I can lower the fan speed, or even assist the devs to get info > regarding these notebooks (if any is needed). > > Thanks, > > Pieter > "This e-mail is sent on the Terms and Conditions that can be accessed by Clicking on this link http://www.vodacom.co.za/legal/email.jsp " > - > To unsubscribe from this list: send the line "unsubscribe linux-acpi" > in the body of a message to [EMAIL PROTECTED] More majordomo > info at http://vger.kernel.org/majordomo-info.html > This e-mail is sent on the Terms and Conditions that can be accessed by Clicking on this link http://www.vodacom.co.za/legal/email.jsp " - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
ACPI _SUN
Hi, I have couple of questions related to _SUN object. 1) Is _SUN object be present DSDT tables? 2) How this DSDT table get updated? 3) Is DSDT table is static binary file or it can be dynamically updated? 4) Who will update the DSDT tables? - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
ACPI _SUN
Hi, I have couple of questions related to _SUN object. 1) Is _SUN object be present DSDT tables? 2) How this DSDT table get updated? 3) Is DSDT table is static binary file or it can be dynamically updated? 4) Who will update the DSDT tables? - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 4/5] i386: turn on CONFIG_PNP in defconfig
On Thursday 18 January 2007 12:49, Bjorn Helgaas wrote: > On Wednesday 17 January 2007 20:08, Len Brown wrote: > > > --- mm-work13.orig/arch/i386/defconfig2007-01-11 13:56:18.0 > > > -0700 > > > +++ mm-work13/arch/i386/defconfig 2007-01-11 13:57:23.0 -0700 > > > @@ -466,7 +466,7 @@ > > > # > > > # Plug and Play support > > > # > > > -# CONFIG_PNP is not set > > > +CONFIG_PNP=y > > > > > > # > > > # Block devices > > > > shouldn't CONFIG_PNPACPI=y also appear in defconfig with this change? > > If it doesn't, then somebody who runs make oldconfig will get prompted for > > it. > > Yes, you're right. I'll add PNPACPI=y in the next round. Hmm, I guess if we're going to include it by default, it is time to delete its dependency on EXPERIMENTAL: Though so many things depend on EXPERIMENTAL these days that maybe it doesn't mean so much. config PNPACPI bool "Plug and Play ACPI support (EXPERIMENTAL)" depends on PNP && ACPI && EXPERIMENTAL > > Also, do we need to be concerned about the case where > > CONFIG_PNP=n > > CONFIG_ACPI=y > > This is the case that motherboard.c was intended to cover. > > > > CONFIG_PNP depends on ACPI (or ISA) > > But nothing mandates that somebody must select it. > > Hmmm... true. Could we get away with having ACPI select PNP? Every time I've tried to use select in recent memory it seems something goes bad. I think there is a rule, such as the thing selected can not depend on anything else, which if violated breaks people's ranconfigs and adrian get grumpy about it. So I think if we want to tie them together, then ACPI should actually depend on PNP -- which is consistent, with how ACPI depends on PM today. > Two other, longer term thoughts: > 1) I think it would be good if PNP reserved resources for all > active devices, as PCI already does (though PCI might do it > even for disabled devices). Then we really wouldn't need > system.c or motherboard.c at all. > > 2) I think we should deprecate ACPI driver registration and do > everything through PNP, with the ACPI stuff as an optional > capability of PNP devices. Then PNP=n, ACPI=y really wouldn't > make much sense. Whelp, when we're guaranteed that PNP exists when ACPI exists then we can get smarter about PNP. thanks, -Len - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fan speeds on HP nc6400 and nc8430
Do you have psmouse module loaded ? (i.e. CONFIG_MOUSE_PS2=m) If yes, Please try remove it, and re-test it. Thanks, Luming On 1/19/07, Pieter De Wit <[EMAIL PROTECTED]> wrote: Hello List, I have noted that the fan speed on "idle" is much higher in Linux compared to XP. I have also noted that once fans are turned on, they never seem to return to the off state. I am currently using the 2.6.18 kernel from Gentoo (gentoo-sources-r6). I was wondering if there is a way I can lower the fan speed, or even assist the devs to get info regarding these notebooks (if any is needed). Thanks, Pieter "This e-mail is sent on the Terms and Conditions that can be accessed by Clicking on this link http://www.vodacom.co.za/legal/email.jsp " - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] [PATCH] Power S3 Resume Optimization Patch. Request for Comment
[RFC][PATCH] Power S3 Resume optimisation
Here is a simple patch for optimising the S3 resume. With this
patch the resume time is 0.85. Given the fact that device initialisation
on the resume takes almost 70% of time, By executing the whole
"device_resume()" function on a seperate kernel thread, the resume gets
completed( ie. the user can precieve) by ~0.85 sec.
To avoid any possible race condition while processing the IO
request and to make sure all the io request are queued till the device
resume thread exits, the IO schedulars (patched cfq and as) checks a for
system_resume flag, which is set when the device resume thread starts,
if the flag is set, it doesnt put the request in the dispatch queue.
Once the flag is cleared i.e when the device resume thread is complete,
the IO-schedular behave as in normal situation.
I did some validation of this patch on a NAPA board ( Calistoga
chipset with Dothan Processor with and Without SMP)locally here and
havent noticed any issue so far. Please review and let me know what
your comments. This patch is against 2.6.18 kernel
thanks
-hari
signed-off-by: hari < [EMAIL PROTECTED]>
---
diff -ruN ../test/linux-vanilla/block/as-iosched.c
linux-2.6.18/block/as-iosched.c---
../test/linux-vanilla/block/as-iosched.c2007-01-10
13:51:33.0 +0530
+++ linux-2.6.18/block/as-iosched.c 2007-01-18 13:37:01.0
+0530
@@ -1088,6 +1088,19 @@
if (list_empty(&ad->fifo_list[adir]))
return 0;
+ /*
+* Check here for the System resume flag to be cleared, if flag
is
+ * still set the resume thread hasnt completed yet, and hence
dont
+ * takeout any new request from the FIFO
+ */
+ extern int system_resuming;
+ if (system_resuming != 0)
+ {
+#ifdef DEBUG
+ printk(" system resuming still \n");
+#endif
+ return 0;
+ }
arq = list_entry_fifo(ad->fifo_list[adir].next);
return time_after(jiffies, arq->expires);
diff -ruN ../test/linux-vanilla/block/cfq-iosched.c
linux-2.6.18/block/cfq-iosched.c
--- ../test/linux-vanilla/block/cfq-iosched.c 2007-01-11
07:59:33.0 +0530
+++ linux-2.6.18/block/cfq-iosched.c2007-01-18 13:35:02.0
+0530
@@ -1156,6 +1156,19 @@
if (!cfqd->busy_queues)
return 0;
+ /*
+* Check here for the System resume flag to be cleared, if flag
is s
+ * still set the resume thread hasnt completed yet, and hence
dont
+ * move any request from the read/write to dispatch queue
+ */
+ extern int system_resuming;
+ if (system_resuming != 0)
+ {
+#ifdef DEBUG
+ printk("System resuming still \n");
+#endif
+ return 0;
+ }
if (unlikely(force))
return cfq_forced_dispatch(cfqd);
diff -ruN ../test/linux-vanilla/kernel/power/main.c
linux-2.6.18/kernel/power/main.c
--- ../test/linux-vanilla/kernel/power/main.c 2007-01-11
08:00:11.0 +0530
+++ linux-2.6.18/kernel/power/main.c2007-01-18 13:31:56.0
+0530
@@ -19,6 +19,7 @@
#include "power.h"
+int system_resuming;
/*This is just an arbitrary number */
#define FREE_PAGE_NUMBER (100)
@@ -131,9 +132,29 @@
* console that we've allocated. This is not called for
suspend-to-disk.
*/
-static void suspend_finish(suspend_state_t state)
+static int dev_resume_proc(void * data)
{
+ /* Set the global resume flag, this will be checked by the
IO_schedular
+ * before dispatching the IO request
+ */
+ system_resuming =1;
device_resume();
+ system_resuming = 0;
+#ifdef DEBUG
+ printk(" reseting system_resume \n");
+#endif
+ return (0);
+}
+static void suspend_finish(suspend_state_t state)
+{
+ int thread;
+ system_resuming = 0;
+ thread = kernel_thread(dev_resume_proc,NULL,CLONE_KERNEL);
+ if (thread < 0)
+ {
+ printk ("Suspend resume Cannot create Kernel_thread\n");
+ device_resume();
+ }
resume_console();
thaw_processes();
enable_nonboot_cpus();
--
s3.patch.new
Description: s3.patch.new
Re: Debugging video resume problems
Does it respond to Ctl+Alt+Delete? If yes, it could be just a known black screen issue. You can try vbetool which happens to work for some lucky guys.Please google vbetool, and take a look at video.txt in documentation/power. if not, you need to sort out the broken drivers. If you need help please feel free to enter a bug in ACPI category at bugzilla.kernel.org. Thanks, Luming On 1/19/07, Richard Hughes <[EMAIL PROTECTED]> wrote: Guys, I have a shiny new Lenovo 3000 N100 laptop. Hibernate works with the latest git tree from kernel.org, but suspend fails to resume with a black screen and no other flashing LED's or other activity. I've tried 2.6.18 and 2.6.19 and neither of those work either. This laptop has no serial ports, so I can't even see if it's oopsed remotely. Is there a guide (howto) that can help debug this? I've tried nearly all the usual combinations of acpi_sleep=s3_bios,s3_mode but I really need a hand with this one. As I've got no messages on the screen at resume, I really don't know where to begin to fix this, advice would be really appreciated. Thanks, Richard Hughes. - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
