USB suspend/resume in linux
Does anyone know whether the linux USB drivers support the suspend feature on idle USB ports (i.e. the port has been idle for sometime and so the driver transitions it in to a low-power 'suspend' state) while the system is active and in S0 state? As far as I know, Windows don't support that, I was wondering if linux does. Please note, I have no background on linux or in OS programming (I am a hardware guy), so please be gentle with the level of technical detail in your response :-) NK - 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: /proc/acpi/thermal_zone/THRM/temperature always reports 40C - is this a bug?
On Wednesday 11 October 2006 21:03, Daniel Drake wrote: > Hi, > > Ethan, at http://bugs.gentoo.org/142635 reports that the thermal zone > always reads 40C. Is this something that should be filed at the kernel > bugzilla for further investigation, or can we simply blame a > buggy/unfixable BIOS? I understand that i2c/hwmon is the more common way > of measuring temperatures. Probably this isn't specific to a gentoo build and would happen just the same with a kernel.org build. So if it is a bug, it is probably an upstream bug. However, unless it used to work, or something bad happens, this is sort of an academic failure. I suppose if you ran Windows on the box and it displayed a changing temperature via ACPI but Linux does not, then it would be more interesting. It would be good to verify that ACPI events in general are working on the box -- eg. the power button etc -- as a failure there would also be more interesting than unchanging temperature. -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: Preventing ACPI from Damaging Your CPU
Thanks. But is 80C safe for a CPU? As I mentioned, 70C is considered dangerous for an Opteron chip. What type of temperatures can the Turions and the C2D support? On Fri, 13 Oct 2006 05:53:39 +0100, "Matthew Garrett" <[EMAIL PROTECTED]> said: > On Thu, Oct 12, 2006 at 09:41:15PM -0700, Mathew Brown wrote: > > Thanks Matthew. Just out of curiosity, how did you find out about this > > feature (forcing the fan at 80C)? Also, is this specific to HP or do > > other vendors also support this? Finally, is 80C safe for the CPU > > (Intel or AMD?)? I read that Opteron chips could be damaged if their > > temperature reaches 70C. Thanks for your help. > > A certain amount of reverse engineering of HP hardware while I was > trying to diagnose some fan problems before. The fan control chip that > HP use is pretty standard, so I think there are docs around somewhere. > > -- > Matthew Garrett | [EMAIL PROTECTED] -- Mathew Brown [EMAIL PROTECTED] -- http://www.fastmail.fm - Send your email first class - 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: Preventing ACPI from Damaging Your CPU
On Thu, Oct 12, 2006 at 09:41:15PM -0700, Mathew Brown wrote: > Thanks Matthew. Just out of curiosity, how did you find out about this > feature (forcing the fan at 80C)? Also, is this specific to HP or do > other vendors also support this? Finally, is 80C safe for the CPU > (Intel or AMD?)? I read that Opteron chips could be damaged if their > temperature reaches 70C. Thanks for your help. A certain amount of reverse engineering of HP hardware while I was trying to diagnose some fan problems before. The fan control chip that HP use is pretty standard, so I think there are docs around somewhere. -- Matthew Garrett | [EMAIL PROTECTED] - 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: Strange entries in /proc/acpi/thermal_zone for Thinkpad X60
On Thursday 12 October 2006 18:19, Jeremy Fitzhardinge wrote: > I have a Thinkpad X60 with an Intel Core Duo T2400. In > /proc/acpi/thermal_zone, I'm getting two subdirectories, each with their > own set of files: > > /proc/acpi/thermal_zone/THM0/cooling_mode: > > cooling mode: critical > > /proc/acpi/thermal_zone/THM0/polling_frequency: > > > /proc/acpi/thermal_zone/THM0/state: > state: ok > > /proc/acpi/thermal_zone/THM0/temperature: > temperature: 53 C > > /proc/acpi/thermal_zone/THM0/trip_points: > critical (S5): 127 C This means that if THM0 reaches 127, your system will shut down. You don't have much control over this one -- but you could probably lower the temperature to do a critical shut-down earlier with something like this: echo -n "126:125:124:123:122" >trip_points note that the 1st is the critical one, and the others are hot:passive:active:active place holders. > > /proc/acpi/thermal_zone/THM1/cooling_mode: > > cooling mode: passive > > /proc/acpi/thermal_zone/THM1/polling_frequency: > > > /proc/acpi/thermal_zone/THM1/state: > state: ok > > /proc/acpi/thermal_zone/THM1/temperature: > temperature: 53 C > > /proc/acpi/thermal_zone/THM1/trip_points: > critical (S5): 97 C > passive: 93 C: tc1=5 tc2=4 tsp=600 devices=0xf7eaa264 > 0xf7eaa244 You are not given the opportunity to set the active trip points here. Looks like you have just a passive trip point at 93 and we would expect to throttle when we go above 93. Presumably some other method should be kicking in the fans before this passive point is reached. The theory is that... If the fans kicked in earlier than you liked, you should be able to lower the passive trip point to below that temperature to make the system throttle before the fans kick in. But probably the root cause of your issue is that the fans are _not_ kicking in... for grins you can probably raise the passive point with something like this # echo -n "98:97:96:53:45" > trip_points but it seems that you are doing passive cooling way before you get anywhere near 93, so that is the mystery. -Len > > > The interesting thing is that the two sets of files are not consistent - > sometimes they don't even show the same temperature. > > The reason I'm interested in this is that I think it's behind some of my > cpufreq problems. Sometimes the kernel decides that I just can't raise > the max frequency above 1GHz, because its been thermally limited (I've > put printks in to confirm that its the ACPI thermal limit on the policy > notifier chain which is limiting the max speed). It seems to me that > having a thermal zone for each core is a BIOS bug, since they're really > the same chip, but the THM1 entries should be ignored. I don't believe > the CPU has ever approached either 97 C, let alone 127; while I put it > under a fair amount of load, it is sitting on a desktop with no airflow > obstructions, so if it really is overheating it suggests a serious > design problem with the hardware. > > But I'm just speculating; I'm not really sure what all this means. Any > clues? > > Thanks, > J > > ___ > Cpufreq mailing list > [EMAIL PROTECTED] > http://lists.linux.org.uk/mailman/listinfo/cpufreq > - 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: Preventing ACPI from Damaging Your CPU
Thanks Matthew. Just out of curiosity, how did you find out about this feature (forcing the fan at 80C)? Also, is this specific to HP or do other vendors also support this? Finally, is 80C safe for the CPU (Intel or AMD?)? I read that Opteron chips could be damaged if their temperature reaches 70C. Thanks for your help. On Fri, 13 Oct 2006 02:24:30 +0100, "Matthew Garrett" <[EMAIL PROTECTED]> said: > On Thu, Oct 12, 2006 at 07:26:00AM -0700, Mathew Brown wrote: > > > I've been reading an alarming article on getting Gentoo to work on the > > HP Compaq nx6325 > > (http://gentoo-wiki.com/HARDWARE_Gentoo_on_HP_Compaq_nx6325) and the > > serious ACPI problems that were encountered. The author states after > > mentioning how to apply certain patches, "Without that, the CPU might > > overheat and get damaged during heavy load (such as compiling a Gentoo > > stage ...)!" > > The author is wrong. Recent HP laptops all have hardcoded support in the > fan control hardware, which will force the fan on if the temperature > rises above 80 degrees. > -- > Matthew Garrett | [EMAIL PROTECTED] -- Mathew Brown [EMAIL PROTECTED] -- http://www.fastmail.fm - mmm... Fastmail... - 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: Preventing ACPI from Damaging Your CPU
On Thu, Oct 12, 2006 at 07:26:00AM -0700, Mathew Brown wrote: > I've been reading an alarming article on getting Gentoo to work on the > HP Compaq nx6325 > (http://gentoo-wiki.com/HARDWARE_Gentoo_on_HP_Compaq_nx6325) and the > serious ACPI problems that were encountered. The author states after > mentioning how to apply certain patches, "Without that, the CPU might > overheat and get damaged during heavy load (such as compiling a Gentoo > stage ...)!" The author is wrong. Recent HP laptops all have hardcoded support in the fan control hardware, which will force the fan on if the temperature rises above 80 degrees. -- Matthew Garrett | [EMAIL PROTECTED] - 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: HP Compaq nc6320
On Thursday, 12 October 2006 18:39, Peter Clifton wrote: > [snip] > > > I got several reports that compiling psmouse as module and unload it > > explicitly on shutdown helps to fix things on newer HPs. > > > > E.g. this report: > > About the fan and battery issue, there are three workaround: > > - Turn off the machine and quit battery, Place the battery again. > > - Next time you turn on the machine, turn it off during post. > > - "modprobe -r psmouse" (after compiling psmouse as a module) before > > shutdown the machine. > > Next time you turn on the machine, battery status is working. Not sure > > about the fans... > > My fans seemed to work ok most of the time before, it was the battery > status which hung, and the speedstep would never go to full speed. > > Everything is happy with Ubuntu's kernel 2.6.17-10 and when unloading > psmouse as part of the shutdown and reboot scripts. > > I did dig though psmouse a little, but being a non-expert, couldn't see > anything odd. > > It could be the synaptics driver part I guess, as most people have > laptops. Well, on the HPC nx6325 I'm using psmouse is apparently interfering with ACPI during resume from disk in a destructive way. Namely, with the 2.6.19-rc1-mm1 kernel the temperature in one of the thermal zones is way off during the resume, so ACPI thinks the critical thermal point has been passed and it tries to power off the system, which makes it hang. Unloading psmouse before the suspend apparently helps. I think it's synaptics too, because it spits reset failure messages during the resume, if not unloaded before. > It could be that psmouse keeps a serial driver of some sort alive, or a > bus active. Perhaps it is still receiving and processing interrupts as > the bios tries to reboot? Does someone need to open a kernel bug for > this, and where should it go? Well I guess so, and it looks like ACPI is the right place to start from. Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller - 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] ACPI header length printk format warning
On Thu, 12 Oct 2006 11:03:45 -0700 Stephen Hemminger wrote:
> Get rid of warning from printk arguments on 64 bit platforms.
size_t (sizeof) should use %zd or %zu or %zx or %zX.
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19-rc1/2.6.19-rc1-mm1/broken-out/acpi-fix-printk-format-warnings.patch
Yes, it would be nice if some patch could be merged for this.
> --- orig/drivers/acpi/tables/tbget.c
> +++ new/drivers/acpi/tables/tbget.c
> @@ -324,8 +324,9 @@ acpi_tb_get_this_table(struct acpi_point
>
> if (header->length < sizeof(struct acpi_table_header)) {
> ACPI_ERROR((AE_INFO,
> - "Table length (%X) is smaller than minimum (%X)",
> - header->length, sizeof(struct acpi_table_header)));
> + "Table length (%lx) is smaller than minimum (%zx)",
> + (unsigned long) header->length,
> + sizeof(struct acpi_table_header)));
>
> return_ACPI_STATUS(AE_INVALID_TABLE_LENGTH);
> }
> @@ -343,8 +344,8 @@ acpi_tb_get_this_table(struct acpi_point
> full_table = ACPI_ALLOCATE(header->length);
> if (!full_table) {
> ACPI_ERROR((AE_INFO,
> - "Could not allocate table memory for
> [%4.4s] length %X",
> - header->signature, header->length));
> + "Could not allocate table memory for
> [%4.4s] length %lx",
> + header->signature, (unsigned long)
> header->length));
> return_ACPI_STATUS(AE_NO_MEMORY);
> }
---
~Randy
-
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
[PATCH] ACPI header length printk format warning
Get rid of warning from printk arguments on 64 bit platforms.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
--- orig/drivers/acpi/tables/tbget.c
+++ new/drivers/acpi/tables/tbget.c
@@ -324,8 +324,9 @@ acpi_tb_get_this_table(struct acpi_point
if (header->length < sizeof(struct acpi_table_header)) {
ACPI_ERROR((AE_INFO,
- "Table length (%X) is smaller than minimum (%X)",
- header->length, sizeof(struct acpi_table_header)));
+ "Table length (%lx) is smaller than minimum (%zx)",
+ (unsigned long) header->length,
+ sizeof(struct acpi_table_header)));
return_ACPI_STATUS(AE_INVALID_TABLE_LENGTH);
}
@@ -343,8 +344,8 @@ acpi_tb_get_this_table(struct acpi_point
full_table = ACPI_ALLOCATE(header->length);
if (!full_table) {
ACPI_ERROR((AE_INFO,
- "Could not allocate table memory for
[%4.4s] length %X",
- header->signature, header->length));
+ "Could not allocate table memory for
[%4.4s] length %lx",
+ header->signature, (unsigned long)
header->length));
return_ACPI_STATUS(AE_NO_MEMORY);
}
-
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: Preventing ACPI from Damaging Your CPU
On Thursday, 12 October 2006 18:51, Mathew Brown wrote: > Thanks for your reply Rafael. However, I was looking for a generic > solution. I don't have an nx6325 but was thinking of purchasing a > laptop and was afraid that ACPI could damage / overheat by CPUs. I > think the link you provided is specific to the nx6325 unless I'm > mistaken. Is there any generic solution? Would recompiling the DSDT > and re-inserting it guarantee that no overheat / damage happens > regardless of the laptop / machine? No, it wouldn't, AFAICT. Greetings, Rafael > On Thu, 12 Oct 2006 16:46:19 +0200, "Rafael J. Wysocki" <[EMAIL PROTECTED]> > said: > > On Thursday, 12 October 2006 16:26, Mathew Brown wrote: > > > Hi, > > > I've been reading an alarming article on getting Gentoo to work on the > > > HP Compaq nx6325 > > > (http://gentoo-wiki.com/HARDWARE_Gentoo_on_HP_Compaq_nx6325) and the > > > serious ACPI problems that were encountered. The author states after > > > mentioning how to apply certain patches, "Without that, the CPU might > > > overheat and get damaged during heavy load (such as compiling a Gentoo > > > stage ...)!" > > > > > > What would be the safest way to ensure that ACPI doesn't do this to > > > your machine / laptop without disabling ACPI? Would recompiling the > > > DSDT using the Intel compiler and re-inserting it be enough to ensure > > > that ACPI doesn't cause your CPU to overheat or get damaged? Thanks > > > for your help. > > > > Please see http://bugzilla.kernel.org/show_bug.cgi?id=7122, especially > > http://bugzilla.kernel.org/show_bug.cgi?id=7122#c27 and below. > > > > Greetings, > > Rafael > > > > > > -- > > You never change things by fighting the existing reality. > > R. Buckminster Fuller > -- > Mathew Brown > [EMAIL PROTECTED] > -- You never change things by fighting the existing reality. R. Buckminster Fuller - 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: USB resume problem with IBM dock
Kristen Carlson Accardi <[EMAIL PROTECTED]> writes: > Hi Dave, Hi Kristen, > Does this happen when you have booted inside the dock station and > then suspend to disk, then resume? Yes. As a matter of fact, I can get resume to succeed by first unplugging all the USB devices while the machine is suspended. > Or is it something like, boot outside the dock station suspend to > disk, resume inside dock? Can you be more specific about how to > duplicate the problem? Tried above. If you want more specificity than that, I think I'll need some more specific questions, because at this point I don't know what more to tell you. I very much appreciate your attention to this issue :) -- Dave Abrahams Boost Consulting www.boost-consulting.com - 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: USB resume problem with IBM dock
On Thu, 12 Oct 2006 00:02:42 -0400 David Abrahams <[EMAIL PROTECTED]> wrote: > > Hi, > > I hope I've come to the right place; I'm going based on the > information in my kernel's MAINTAINERS file. > > I have been using suspend2 with a 2.6.18 kernel, my Thinkpad T60p, and > a Thinkpad Advanced dock. When resuming (from disk), suspend2 puts > all the USB devices into a suspended state so they're consistent with > the state at suspend time. If I have any devices plugged into the > dock's USB ports, it's very common that the devices fail to enter a > suspended state (or so the APIs report). When that happens, suspend2 > forces a segfault and all heck breaks loose (log excerpt appended) -- > suffice it to say I lose my suspended state, all the filesystems need > to be checked, and often it takes an additional reboot just to make > everything healthy again -- so it's really important to me to address > this problem. Please let me know if there's anything I can do to help > track this down. > > > Thanks, > Dave > Hi Dave, Does this happen when you have booted inside the dock station and then suspend to disk, then resume? Or is it something like, boot outside the dock station suspend to disk, resume inside dock? Can you be more specific about how to duplicate the problem? Thanks, Kristen > --- /var/log/syslog excerpt --- > > Oct 11 22:11:40 pereiro kernel: [7.004000] Atomic restore preparation > Oct 11 22:11:40 pereiro kernel: [7.008000] Freezing cpus ... > Oct 11 22:11:40 pereiro kernel: [7.08] usb 5-6.1: new low speed USB > device using ehci_hcd and address 5 > Oct 11 22:11:40 pereiro kernel: [7.128000] CPU 1 is now offline > Oct 11 22:11:40 pereiro kernel: [7.128000] SMP alternatives: switching > to UP code > Oct 11 22:11:40 pereiro kernel: [7.128000] CPU1 is down > Oct 11 22:11:40 pereiro kernel: [7.192000] usb 5-6.1: configuration #1 > chosen from 1 choice > Oct 11 22:11:40 pereiro kernel: [7.392000] usb 5-6.2: new full speed > USB device using ehci_hcd and address 6 > Oct 11 22:11:40 pereiro kernel: [7.484000] usb 5-6.2: configuration #1 > chosen from 1 choice > Oct 11 22:11:40 pereiro kernel: [7.484000] suspend_device(): > usb_generic_suspend+0x0/0x15c [usbcore]() returns -16 > Oct 11 22:11:40 pereiro kernel: [7.484000] usbcore: registered new > driver hiddev > Oct 11 22:11:40 pereiro kernel: [7.484000] Could not suspend device > 5-6: error -16 > Oct 11 22:11:40 pereiro kernel: [7.492000] Some devices failed to > suspend > Oct 11 22:11:40 pereiro kernel: [7.492000] [ cut here > ] > Oct 11 22:11:40 pereiro kernel: [7.492000] kernel BUG at > kernel/power/atomic_copy.c:496! > Oct 11 22:11:40 pereiro kernel: [7.492000] invalid opcode: [#1] > Oct 11 22:11:40 pereiro kernel: [7.492000] PREEMPT SMP > Oct 11 22:11:40 pereiro kernel: [7.492000] Modules linked in: usbhid > dm_mod ide_generic ehci_hcd uhci_hcd usbcore piix generic sd_mod thermal > processor fan fbcon tileblit font bitblit softcursor > Oct 11 22:11:40 pereiro kernel: [7.492000] CPU:0 > Oct 11 22:11:40 pereiro kernel: [7.492000] EIP: > 0060:[suspend_atomic_restore+487/544]Not tainted VLI > Oct 11 22:11:40 pereiro kernel: [7.492000] EFLAGS: 00010246 > (2.6.18-local-20060823 #2) > Oct 11 22:11:40 pereiro kernel: [7.492000] EIP is at > suspend_atomic_restore+0x1e7/0x220 > Oct 11 22:11:40 pereiro kernel: [7.492000] eax: 4010 ebx: > ecx: edx: 0002 > Oct 11 22:11:40 pereiro kernel: [7.492000] esi: 0001 edi: > 0001 ebp: c0393270 esp: dfcadef0 > Oct 11 22:11:40 pereiro kernel: [7.492000] ds: 007b es: 007b ss: > 0068 > Oct 11 22:11:40 pereiro kernel: [7.492000] Process busybox (pid: 2428, > ti=dfcac000 task=c21ed290 task.ti=dfcac000) > Oct 11 22:11:40 pereiro kernel: [7.492000] Stack: c034fc04 c034cd8f > 0001 0001 c014c6ee c014c921 > Oct 11 22:11:40 pereiro kernel: [7.492000]c014c7a7 c014e9f3 > c13fb860 fffa8278 0001 > Oct 11 22:11:40 pereiro kernel: [7.492000]df802a40 0001 > 0001 df802a54 c01cc84c c03931b8 c0393270 dfdc3000 > Oct 11 22:11:40 pereiro kernel: [7.492000] Call Trace: > Oct 11 22:11:40 pereiro kernel: [7.492000] [suspend_resume+110/272] > suspend_resume+0x6e/0x110 > Oct 11 22:11:40 pereiro kernel: [7.492000] > [suspend_start_anything+81/192] suspend_start_anything+0x51/0xc0 > Oct 11 22:11:40 pereiro kernel: [7.492000] > [__suspend_try_resume+23/48] __suspend_try_resume+0x17/0x30 > Oct 11 22:11:40 pereiro kernel: [7.492000] > [suspend2_attr_store+99/688] suspend2_attr_store+0x63/0x2b0 > Oct 11 22:11:40 pereiro kernel: [7.492000] [sysfs_write_file+156/240] > sysfs_write_file+0x9c/0xf0 > Oct 11 22:11:40 pereiro kernel
Re: Preventing ACPI from Damaging Your CPU
Thanks for your reply Rafael. However, I was looking for a generic solution. I don't have an nx6325 but was thinking of purchasing a laptop and was afraid that ACPI could damage / overheat by CPUs. I think the link you provided is specific to the nx6325 unless I'm mistaken. Is there any generic solution? Would recompiling the DSDT and re-inserting it guarantee that no overheat / damage happens regardless of the laptop / machine? Thanks. On Thu, 12 Oct 2006 16:46:19 +0200, "Rafael J. Wysocki" <[EMAIL PROTECTED]> said: > On Thursday, 12 October 2006 16:26, Mathew Brown wrote: > > Hi, > > I've been reading an alarming article on getting Gentoo to work on the > > HP Compaq nx6325 > > (http://gentoo-wiki.com/HARDWARE_Gentoo_on_HP_Compaq_nx6325) and the > > serious ACPI problems that were encountered. The author states after > > mentioning how to apply certain patches, "Without that, the CPU might > > overheat and get damaged during heavy load (such as compiling a Gentoo > > stage ...)!" > > > > What would be the safest way to ensure that ACPI doesn't do this to > > your machine / laptop without disabling ACPI? Would recompiling the > > DSDT using the Intel compiler and re-inserting it be enough to ensure > > that ACPI doesn't cause your CPU to overheat or get damaged? Thanks > > for your help. > > Please see http://bugzilla.kernel.org/show_bug.cgi?id=7122, especially > http://bugzilla.kernel.org/show_bug.cgi?id=7122#c27 and below. > > Greetings, > Rafael > > > -- > You never change things by fighting the existing reality. > R. Buckminster Fuller -- Mathew Brown [EMAIL PROTECTED] -- http://www.fastmail.fm - A fast, anti-spam email service. - 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: HP Compaq nc6320
[snip] > I got several reports that compiling psmouse as module and unload it > explicitly on shutdown helps to fix things on newer HPs. > > E.g. this report: > About the fan and battery issue, there are three workaround: > - Turn off the machine and quit battery, Place the battery again. > - Next time you turn on the machine, turn it off during post. > - "modprobe -r psmouse" (after compiling psmouse as a module) before > shutdown the machine. > Next time you turn on the machine, battery status is working. Not sure > about the fans... My fans seemed to work ok most of the time before, it was the battery status which hung, and the speedstep would never go to full speed. Everything is happy with Ubuntu's kernel 2.6.17-10 and when unloading psmouse as part of the shutdown and reboot scripts. I did dig though psmouse a little, but being a non-expert, couldn't see anything odd. It could be the synaptics driver part I guess, as most people have laptops. It could be that psmouse keeps a serial driver of some sort alive, or a bus active. Perhaps it is still receiving and processing interrupts as the bios tries to reboot? Does someone need to open a kernel bug for this, and where should it go? Regards Peter Clifton. - 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: HP Compaq nc6320
On Thu, 2006-10-12 at 16:53 +0200, Rafael J. Wysocki wrote: > On Thursday, 12 October 2006 02:08, Peter Clifton wrote: > > > > > Wierdly, I've lost the Battery/AC adapter status monitoring again, with > > > or without ec_intr=0. > > > > > Gets odder! > > > > Ok, > > > > Nearing completion of this tale I think.. > > > > Turns out there is a known problem with psmouse, which leaves the > > system / ACPI / something in a bad state if psmouse is loaded before > > shutdown or reboot. Googling tells me that either removing batteries, AC > > etc.. before powering up, booting Windows, or shutting down Linux with > > psmouse removed, will "fix" the symptoms. I got several reports that compiling psmouse as module and unload it explicitly on shutdown helps to fix things on newer HPs. E.g. this report: About the fan and battery issue, there are three workaround: - Turn off the machine and quit battery, Place the battery again. - Next time you turn on the machine, turn it off during post. - "modprobe -r psmouse" (after compiling psmouse as a module) before shutdown the machine. Next time you turn on the machine, battery status is working. Not sure about the fans... http://www.wolframschenck.de/nx6325.htm#sect3 Similar introduction in German: http://home.no/slazz/nx6310/nx6310.html Thomas - 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: HP Compaq nc6320
On Thursday, 12 October 2006 02:08, Peter Clifton wrote: > > > Wierdly, I've lost the Battery/AC adapter status monitoring again, with > > or without ec_intr=0. > > > Gets odder! > > Ok, > > Nearing completion of this tale I think.. > > Turns out there is a known problem with psmouse, which leaves the > system / ACPI / something in a bad state if psmouse is loaded before > shutdown or reboot. Googling tells me that either removing batteries, AC > etc.. before powering up, booting Windows, or shutting down Linux with > psmouse removed, will "fix" the symptoms. Do you remember any URLs? Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller - 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: Preventing ACPI from Damaging Your CPU
On Thursday, 12 October 2006 16:26, Mathew Brown wrote: > Hi, > I've been reading an alarming article on getting Gentoo to work on the > HP Compaq nx6325 > (http://gentoo-wiki.com/HARDWARE_Gentoo_on_HP_Compaq_nx6325) and the > serious ACPI problems that were encountered. The author states after > mentioning how to apply certain patches, "Without that, the CPU might > overheat and get damaged during heavy load (such as compiling a Gentoo > stage ...)!" > > What would be the safest way to ensure that ACPI doesn't do this to > your machine / laptop without disabling ACPI? Would recompiling the > DSDT using the Intel compiler and re-inserting it be enough to ensure > that ACPI doesn't cause your CPU to overheat or get damaged? Thanks > for your help. Please see http://bugzilla.kernel.org/show_bug.cgi?id=7122, especially http://bugzilla.kernel.org/show_bug.cgi?id=7122#c27 and below. Greetings, Rafael -- You never change things by fighting the existing reality. R. Buckminster Fuller - 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
