| 2008-02-07 05:31:54 |
Saivann Carignan |
bug |
|
|
added bug |
| 2008-02-07 05:33:07 |
Saivann Carignan |
bug |
|
|
added attachment 'lspci-nn.txt' (lspci of my laptop) |
| 2008-02-21 15:39:21 |
Miguel Ruiz |
gnome-power-manager: status |
New |
Incomplete |
|
| 2008-02-23 05:15:13 |
Saivann Carignan |
gnome-power-manager: status |
Incomplete |
Fix Released |
|
| 2008-03-27 02:12:59 |
Saivann Carignan |
gnome-power-manager: status |
Fix Released |
New |
|
| 2008-03-27 02:13:14 |
Saivann Carignan |
bug |
|
|
assigned to linux (Ubuntu) |
| 2008-03-27 02:14:54 |
Saivann Carignan |
description |
This bug happens with a fresh hardy a3 or a4 install when the computer is running on battery or at the moment I plug/unplug the electric cable into my computer.
If I let the computer unused for some minutes (2-5 minutes), when I come back and try to use the mouse, the mouse move of some centimeters, suddenly freeze for almost 5 seconds, and then come back to life. It can be reproduced since it continually happens each time I use my computer after reading a short text or spooke to somebody. If I plug or unplug the electric cable, the mouse freeze again for a 7 seconds.
This bug does not happen when the electric cable is plugged, and it happens with metacity as much as compiz. |
This bug happens with a freshly installed hardy beta 1 when the computer is running on battery or at the moment I plug/unplug the electric cable into my computer.
If I let the computer unused for some minutes (2-5 minutes), when I come back and try to use the mouse, the mouse move of some centimeters, suddenly freeze for almost 5 seconds, and then come back to life. It can be reproduced since it continually happens each time I use my computer after reading a short text or spooke to somebody. If I plug or unplug the electric cable, the mouse freeze again for a 7 seconds. If any sounds are playing during the time that the mouse freeze, the sound is also corrupted and freeze.
This bug does not happen when the electric cable is plugged, and it happens with metacity as much as compiz.
Dell Inspiron 9300, i386 |
|
| 2008-03-27 02:22:20 |
Saivann Carignan |
description |
This bug happens with a freshly installed hardy beta 1 when the computer is running on battery or at the moment I plug/unplug the electric cable into my computer.
If I let the computer unused for some minutes (2-5 minutes), when I come back and try to use the mouse, the mouse move of some centimeters, suddenly freeze for almost 5 seconds, and then come back to life. It can be reproduced since it continually happens each time I use my computer after reading a short text or spooke to somebody. If I plug or unplug the electric cable, the mouse freeze again for a 7 seconds. If any sounds are playing during the time that the mouse freeze, the sound is also corrupted and freeze.
This bug does not happen when the electric cable is plugged, and it happens with metacity as much as compiz.
Dell Inspiron 9300, i386 |
This bug happens with a freshly installed hardy beta 1 when the computer is running on battery or at the moment I plug/unplug the electric cable into my computer.
If I let the computer unused for some minutes (2-5 minutes), when I come back and try to use the mouse, the mouse move of some centimeters, suddenly freeze for almost 5 seconds, and then come back to life. It can be reproduced since it continually happens each time I use my computer after reading a short text or spooke to somebody. If I plug or unplug the electric cable, the mouse freeze again for a 7 seconds. If any sounds are playing during the time that the mouse freeze, the sound is also corrupted and freeze.
This bug does not happen when the electric cable is plugged, and it happens with metacity as much as compiz.
Each time that the mouse suddenly freeze, I get this in dmesg :
[ 804.829840] psmouse.c: GlidePoint at isa0060/serio1/input0 lost synchronization, throwing 4 bytes away.
[ 807.405427] psmouse.c: resync failed, issuing reconnect request
[ 810.926845] input: PS/2 Mouse as /devices/virtual/input/input9
[ 810.973805] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input10
This might maybe be linked with bug 190414, tsc clocksource does not work on my laptop with Hardy kernel so linux switch to hpet instead after ~35 seconds waiting at boot.
This bug is not a hardware failure because it is not reproducible under Linux Ubuntu Gutsy and Windows XP.
Dell Inspiron 9300, i386 |
|
| 2008-03-27 02:22:20 |
Saivann Carignan |
title |
[hardy]laptop is buggy when running on battery |
[hardy]touchpad is buggy when running on battery |
|
| 2008-03-27 02:23:04 |
Saivann Carignan |
bug |
|
|
added attachment 'dmesg.log' (dmesg.log) |
| 2008-03-27 02:23:16 |
Saivann Carignan |
bug |
|
|
added attachment 'lspci-vvnn.log' (lspci-vvnn.log) |
| 2008-03-27 02:23:26 |
Saivann Carignan |
bug |
|
|
added attachment 'uname-a.log' (uname-a.log) |
| 2008-03-27 02:23:36 |
Saivann Carignan |
bug |
|
|
added attachment 'version.log' (version.log) |
| 2008-03-27 02:24:06 |
Saivann Carignan |
gnome-power-manager: status |
New |
Invalid |
|
| 2008-03-27 02:27:22 |
Saivann Carignan |
linux: importance |
Undecided |
Medium |
|
| 2008-03-27 02:27:22 |
Saivann Carignan |
linux: assignee |
|
ubuntu-kernel-team |
|
| 2008-03-27 02:27:22 |
Saivann Carignan |
linux: status |
New |
Confirmed |
|
| 2008-03-27 15:41:33 |
Saivann Carignan |
title |
[hardy]touchpad is buggy when running on battery |
[hardy]computer and touchpad is buggy when running on battery |
|
| 2008-04-18 23:29:33 |
Saivann Carignan |
linux: status |
Confirmed |
Fix Released |
|
| 2008-05-06 16:37:48 |
Saivann Carignan |
linux: status |
Fix Released |
Confirmed |
|
| 2008-05-06 16:37:59 |
Saivann Carignan |
linux: status |
Confirmed |
Triaged |
|
| 2008-05-06 18:04:58 |
Aitor Pazos |
bug |
|
|
added attachment 'dmesg.log' (dmesg.log) |
| 2008-05-06 18:05:41 |
Aitor Pazos |
bug |
|
|
added attachment 'lspci-vvnn.log' (lspci-vvnn.log) |
| 2008-05-06 18:06:08 |
Aitor Pazos |
bug |
|
|
added attachment 'uname-a.log' (uname-a.log) |
| 2008-05-06 18:06:50 |
Aitor Pazos |
bug |
|
|
added attachment 'version.log' (version.log) |
| 2008-06-09 13:45:22 |
bro |
bug |
|
|
added attachment 'unnamed' (unnamed) |
| 2008-07-01 02:45:27 |
Saivann Carignan |
description |
This bug happens with a freshly installed hardy beta 1 when the computer is running on battery or at the moment I plug/unplug the electric cable into my computer.
If I let the computer unused for some minutes (2-5 minutes), when I come back and try to use the mouse, the mouse move of some centimeters, suddenly freeze for almost 5 seconds, and then come back to life. It can be reproduced since it continually happens each time I use my computer after reading a short text or spooke to somebody. If I plug or unplug the electric cable, the mouse freeze again for a 7 seconds. If any sounds are playing during the time that the mouse freeze, the sound is also corrupted and freeze.
This bug does not happen when the electric cable is plugged, and it happens with metacity as much as compiz.
Each time that the mouse suddenly freeze, I get this in dmesg :
[ 804.829840] psmouse.c: GlidePoint at isa0060/serio1/input0 lost synchronization, throwing 4 bytes away.
[ 807.405427] psmouse.c: resync failed, issuing reconnect request
[ 810.926845] input: PS/2 Mouse as /devices/virtual/input/input9
[ 810.973805] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input10
This might maybe be linked with bug 190414, tsc clocksource does not work on my laptop with Hardy kernel so linux switch to hpet instead after ~35 seconds waiting at boot.
This bug is not a hardware failure because it is not reproducible under Linux Ubuntu Gutsy and Windows XP.
Dell Inspiron 9300, i386 |
This bug happens with a freshly installed hardy beta 1 when the computer is running on battery or at the moment I plug/unplug the electric cable into my computer.
If I let the computer unused for some minutes (2-5 minutes), when I come back and try to use the mouse, the mouse move of some centimeters, suddenly freeze for almost 5 seconds, and then come back to life. It can be reproduced since it continually happens each time I use my computer after reading a short text or spooke to somebody. If I plug or unplug the electric cable, the mouse freeze again for a 7 seconds. If any sounds are playing during the time that the mouse freeze, the sound is also corrupted and freeze.
This bug does not happen when the electric cable is plugged, and it happens with metacity as much as compiz.
Each time that the mouse suddenly freeze, I get this in dmesg :
[ 804.829840] psmouse.c: GlidePoint at isa0060/serio1/input0 lost synchronization, throwing 4 bytes away.
[ 807.405427] psmouse.c: resync failed, issuing reconnect request
[ 810.926845] input: PS/2 Mouse as /devices/virtual/input/input9
[ 810.973805] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input10
This bug is not a hardware failure because it is not reproducible under Linux Ubuntu Gutsy and Windows XP.
Dell Inspiron 9300, i386
Update : It has been found that this bug only appears when there is a BIOS password set on laptop computers. |
|
| 2008-07-01 02:45:27 |
Saivann Carignan |
title |
[hardy]computer and touchpad is buggy when running on battery |
[hardy]computer and touchpad is buggy with BIOS password set |
|
| 2008-07-01 19:44:21 |
Saivann Carignan |
title |
[hardy]computer and touchpad is buggy with BIOS password set |
computer and touchpad is buggy with BIOS password set |
|
| 2008-07-02 05:31:28 |
Andrea Ratto |
linux: status |
Triaged |
New |
|
| 2008-07-02 05:31:28 |
Andrea Ratto |
linux: assignee |
ubuntu-kernel-team |
|
|
| 2008-07-02 05:36:38 |
Andrea Ratto |
description |
This bug happens with a freshly installed hardy beta 1 when the computer is running on battery or at the moment I plug/unplug the electric cable into my computer.
If I let the computer unused for some minutes (2-5 minutes), when I come back and try to use the mouse, the mouse move of some centimeters, suddenly freeze for almost 5 seconds, and then come back to life. It can be reproduced since it continually happens each time I use my computer after reading a short text or spooke to somebody. If I plug or unplug the electric cable, the mouse freeze again for a 7 seconds. If any sounds are playing during the time that the mouse freeze, the sound is also corrupted and freeze.
This bug does not happen when the electric cable is plugged, and it happens with metacity as much as compiz.
Each time that the mouse suddenly freeze, I get this in dmesg :
[ 804.829840] psmouse.c: GlidePoint at isa0060/serio1/input0 lost synchronization, throwing 4 bytes away.
[ 807.405427] psmouse.c: resync failed, issuing reconnect request
[ 810.926845] input: PS/2 Mouse as /devices/virtual/input/input9
[ 810.973805] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input10
This bug is not a hardware failure because it is not reproducible under Linux Ubuntu Gutsy and Windows XP.
Dell Inspiron 9300, i386
Update : It has been found that this bug only appears when there is a BIOS password set on laptop computers. |
This description is totally rewritten by Andrea Ratto (LP andrearatto) to recap the situation. The root cause has been really hard to find as it seemed a kernel issue related to the touchpad at first.
The problem reported here and its cause have already been confirmed by at least 5 users.
This bug refers primarily to HAL, but also relates to libsmbios. It is triggered by gnome-power-manager, but it's not its fault.
Symptoms:
very frequent temporary lock-ups on input after some inactivity
frequent hard lock-ups with CAPS lock and NUM lock flashing
very frequent loss of synchronization with the touchpad, which then looses advanced functionalities; with this in dmesg
[ 804.829840] psmouse.c: GlidePoint at isa0060/serio1/input0 lost synchronization, throwing 4 bytes away.
[ 807.405427] psmouse.c: resync failed, issuing reconnect request
[ 810.926845] input: PS/2 Mouse as /devices/virtual/input/input9
[ 810.973805] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input10
Affected hardware:
dell laptops with a BIOS password set (probably all/most of them)
Releases affected
hardy for sure, probably intrepid too. gusty is not affected.
Other distro are affected too, e.g. Fedora 9.
What is known so far:
gnome-power-manager tries to dim the brightness of the screen after some inactivity and then reset it upon input.
This is a default setting, so the user has no clue of what might be causing the issue.
gnome-power-manager calls HAL to do the job. HAL on dell machines, since hardy, uses libsmbios for brightness setting.
Libsmbios needs the BIOS password even to change the brightness and HAL has no way to tell it that password, as of now. Some users have also reported that libsmbios does not work even from the command line utility, specifying the pass.
However, instead of just printing an error when it fails, it makes the computer lock for a few seconds, due to the direct interaction with the bios on a very low level. The kernel has then problems reading input events and might crash. These lock-ups should also be avoided in libsmbios, as that is really ugly. However it needs root privileges and it's HAL who is calling it again and again when it should not, so the lockups are more HAL's fault.
Testing/repoducing:
1: of course using gnome and gnome-power-manager, setting "Dim display when idle" to enabled.
Same effects can be achieved by:
2: using the command /usr/sbin/dellLcdBrightness from libsmbios-bin package.
Here's a command that rapidly switch brightness 10 times:
for x in `seq 1 10`; do sudo dellLcdBrightness -a -v 1;sleep 0.1; sudo dellLcdBrightness -a -v 5; done
#Warning it may hang your machine
3: the brightness applet of the gnome-panel.
A possible elegant solution:
* Correct HAL's detection of brightness setting capability on dell, so that it only reports it when it can be set with no errors. It might require using some test method in libsmbios, which I don't know if it is present or has to be added.
Maybe also add some way for HAL to read the bios password from config files if the user wishes so. (This is probably somewhat already planned)
Solving the stalling in libsmbios might prevent crashes, but yet HAL would keep calling it and get errors, so a fix in HAL is needed.
Less elegant:
turn off HAL's usage of libsmbios in one of its config files and have users who want it to manually set it.
possible temporary workarounds for users experiencing this:
- unset the bios password
- blacklist the dcdbas kernel module
- disable dimming in gnome-power
- I don't know how to disable this functionality from HAL, but that would be the best workaround.
NOTE: if HAL is allowed to use libsmbios a local user could exploit it to induce a denial of service or crash.
I hope this info proves clear and useful. For anything else just ask.
|
|
| 2008-07-02 05:36:38 |
Andrea Ratto |
title |
computer and touchpad is buggy with BIOS password set |
HAL crashes dell laptops with a BIOS password |
|
| 2008-07-02 05:39:43 |
Andrea Ratto |
bug |
|
|
added subscriber The Dell Team |
| 2008-07-02 05:44:38 |
Andrea Ratto |
bug |
|
|
assigned to libsmbios |
| 2008-07-02 12:45:24 |
Saivann Carignan |
hal: status |
New |
Triaged |
|
| 2008-07-02 12:45:38 |
Saivann Carignan |
libsmbios: status |
New |
Confirmed |
|
| 2008-07-02 12:46:49 |
Saivann Carignan |
title |
HAL crashes dell laptops with a BIOS password |
HAL lockups or crashes dell laptops with a BIOS password |
|
| 2008-07-02 12:48:10 |
Saivann Carignan |
description |
This description is totally rewritten by Andrea Ratto (LP andrearatto) to recap the situation. The root cause has been really hard to find as it seemed a kernel issue related to the touchpad at first.
The problem reported here and its cause have already been confirmed by at least 5 users.
This bug refers primarily to HAL, but also relates to libsmbios. It is triggered by gnome-power-manager, but it's not its fault.
Symptoms:
very frequent temporary lock-ups on input after some inactivity
frequent hard lock-ups with CAPS lock and NUM lock flashing
very frequent loss of synchronization with the touchpad, which then looses advanced functionalities; with this in dmesg
[ 804.829840] psmouse.c: GlidePoint at isa0060/serio1/input0 lost synchronization, throwing 4 bytes away.
[ 807.405427] psmouse.c: resync failed, issuing reconnect request
[ 810.926845] input: PS/2 Mouse as /devices/virtual/input/input9
[ 810.973805] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input10
Affected hardware:
dell laptops with a BIOS password set (probably all/most of them)
Releases affected
hardy for sure, probably intrepid too. gusty is not affected.
Other distro are affected too, e.g. Fedora 9.
What is known so far:
gnome-power-manager tries to dim the brightness of the screen after some inactivity and then reset it upon input.
This is a default setting, so the user has no clue of what might be causing the issue.
gnome-power-manager calls HAL to do the job. HAL on dell machines, since hardy, uses libsmbios for brightness setting.
Libsmbios needs the BIOS password even to change the brightness and HAL has no way to tell it that password, as of now. Some users have also reported that libsmbios does not work even from the command line utility, specifying the pass.
However, instead of just printing an error when it fails, it makes the computer lock for a few seconds, due to the direct interaction with the bios on a very low level. The kernel has then problems reading input events and might crash. These lock-ups should also be avoided in libsmbios, as that is really ugly. However it needs root privileges and it's HAL who is calling it again and again when it should not, so the lockups are more HAL's fault.
Testing/repoducing:
1: of course using gnome and gnome-power-manager, setting "Dim display when idle" to enabled.
Same effects can be achieved by:
2: using the command /usr/sbin/dellLcdBrightness from libsmbios-bin package.
Here's a command that rapidly switch brightness 10 times:
for x in `seq 1 10`; do sudo dellLcdBrightness -a -v 1;sleep 0.1; sudo dellLcdBrightness -a -v 5; done
#Warning it may hang your machine
3: the brightness applet of the gnome-panel.
A possible elegant solution:
* Correct HAL's detection of brightness setting capability on dell, so that it only reports it when it can be set with no errors. It might require using some test method in libsmbios, which I don't know if it is present or has to be added.
Maybe also add some way for HAL to read the bios password from config files if the user wishes so. (This is probably somewhat already planned)
Solving the stalling in libsmbios might prevent crashes, but yet HAL would keep calling it and get errors, so a fix in HAL is needed.
Less elegant:
turn off HAL's usage of libsmbios in one of its config files and have users who want it to manually set it.
possible temporary workarounds for users experiencing this:
- unset the bios password
- blacklist the dcdbas kernel module
- disable dimming in gnome-power
- I don't know how to disable this functionality from HAL, but that would be the best workaround.
NOTE: if HAL is allowed to use libsmbios a local user could exploit it to induce a denial of service or crash.
I hope this info proves clear and useful. For anything else just ask.
|
This description is totally rewritten by Andrea Ratto (LP andrearatto) to recap the situation. The root cause has been really hard to find as it seemed a kernel issue related to the touchpad at first.
The problem reported here and its cause have already been confirmed by at least 5 users.
This bug refers primarily to HAL, but also relates to libsmbios. It is triggered by gnome-power-manager, but it's not its fault.
Symptoms:
very frequent temporary lock-ups on input after some inactivity
frequent hard lock-ups with CAPS lock and NUM lock flashing
very frequent loss of synchronization with the touchpad, which then looses advanced functionalities; with this in dmesg
[ 804.829840] psmouse.c: GlidePoint at isa0060/serio1/input0 lost synchronization, throwing 4 bytes away.
[ 807.405427] psmouse.c: resync failed, issuing reconnect request
[ 810.926845] input: PS/2 Mouse as /devices/virtual/input/input9
[ 810.973805] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input10
Affected hardware:
dell laptops with a BIOS password set (probably all/most of them)
Releases affected
hardy, intrepid. gusty is not affected.
Other distro are affected too, e.g. Fedora 9.
What is known so far:
gnome-power-manager tries to dim the brightness of the screen after some inactivity and then reset it upon input.
This is a default setting, so the user has no clue of what might be causing the issue.
gnome-power-manager calls HAL to do the job. HAL on dell machines, since hardy, uses libsmbios for brightness setting.
Libsmbios needs the BIOS password even to change the brightness and HAL has no way to tell it that password, as of now. Some users have also reported that libsmbios does not work even from the command line utility, specifying the pass.
However, instead of just printing an error when it fails, it makes the computer lock for a few seconds, due to the direct interaction with the bios on a very low level. The kernel has then problems reading input events and might crash. These lock-ups should also be avoided in libsmbios, as that is really ugly. However it needs root privileges and it's HAL who is calling it again and again when it should not, so the lockups are more HAL's fault.
Testing/repoducing:
1: of course using gnome and gnome-power-manager, setting "Dim display when idle" to enabled.
Same effects can be achieved by:
2: using the command /usr/sbin/dellLcdBrightness from libsmbios-bin package.
Here's a command that rapidly switch brightness 10 times:
for x in `seq 1 10`; do sudo dellLcdBrightness -a -v 1;sleep 0.1; sudo dellLcdBrightness -a -v 5; done
#Warning it may hang your machine
3: the brightness applet of the gnome-panel.
A possible elegant solution:
* Correct HAL's detection of brightness setting capability on dell, so that it only reports it when it can be set with no errors. It might require using some test method in libsmbios, which I don't know if it is present or has to be added.
Maybe also add some way for HAL to read the bios password from config files if the user wishes so. (This is probably somewhat already planned)
Solving the stalling in libsmbios might prevent crashes, but yet HAL would keep calling it and get errors, so a fix in HAL is needed.
Less elegant:
turn off HAL's usage of libsmbios in one of its config files and have users who want it to manually set it.
possible temporary workarounds for users experiencing this:
- unset the bios password
- blacklist the dcdbas kernel module
- disable dimming in gnome-power
- I don't know how to disable this functionality from HAL, but that would be the best workaround.
NOTE: if HAL is allowed to use libsmbios a local user could exploit it to induce a denial of service or crash.
I hope this info proves clear and useful. For anything else just ask.
|
|
| 2008-07-02 12:48:42 |
Saivann Carignan |
gnome-power-manager: status |
Invalid |
Triaged |
|
| 2008-07-02 12:48:42 |
Saivann Carignan |
gnome-power-manager: importance |
Undecided |
Medium |
|
| 2008-07-02 15:26:03 |
Matt Domsch |
bug |
|
|
assigned to dell |
| 2008-07-02 19:23:47 |
Mario Limonciello |
title |
HAL lockups or crashes dell laptops with a BIOS password |
HAL lockups/crashes on Dell D-series Latitudes w/ BIOS password |
|
| 2008-07-02 19:25:04 |
Mario Limonciello |
description |
This description is totally rewritten by Andrea Ratto (LP andrearatto) to recap the situation. The root cause has been really hard to find as it seemed a kernel issue related to the touchpad at first.
The problem reported here and its cause have already been confirmed by at least 5 users.
This bug refers primarily to HAL, but also relates to libsmbios. It is triggered by gnome-power-manager, but it's not its fault.
Symptoms:
very frequent temporary lock-ups on input after some inactivity
frequent hard lock-ups with CAPS lock and NUM lock flashing
very frequent loss of synchronization with the touchpad, which then looses advanced functionalities; with this in dmesg
[ 804.829840] psmouse.c: GlidePoint at isa0060/serio1/input0 lost synchronization, throwing 4 bytes away.
[ 807.405427] psmouse.c: resync failed, issuing reconnect request
[ 810.926845] input: PS/2 Mouse as /devices/virtual/input/input9
[ 810.973805] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input10
Affected hardware:
dell laptops with a BIOS password set (probably all/most of them)
Releases affected
hardy, intrepid. gusty is not affected.
Other distro are affected too, e.g. Fedora 9.
What is known so far:
gnome-power-manager tries to dim the brightness of the screen after some inactivity and then reset it upon input.
This is a default setting, so the user has no clue of what might be causing the issue.
gnome-power-manager calls HAL to do the job. HAL on dell machines, since hardy, uses libsmbios for brightness setting.
Libsmbios needs the BIOS password even to change the brightness and HAL has no way to tell it that password, as of now. Some users have also reported that libsmbios does not work even from the command line utility, specifying the pass.
However, instead of just printing an error when it fails, it makes the computer lock for a few seconds, due to the direct interaction with the bios on a very low level. The kernel has then problems reading input events and might crash. These lock-ups should also be avoided in libsmbios, as that is really ugly. However it needs root privileges and it's HAL who is calling it again and again when it should not, so the lockups are more HAL's fault.
Testing/repoducing:
1: of course using gnome and gnome-power-manager, setting "Dim display when idle" to enabled.
Same effects can be achieved by:
2: using the command /usr/sbin/dellLcdBrightness from libsmbios-bin package.
Here's a command that rapidly switch brightness 10 times:
for x in `seq 1 10`; do sudo dellLcdBrightness -a -v 1;sleep 0.1; sudo dellLcdBrightness -a -v 5; done
#Warning it may hang your machine
3: the brightness applet of the gnome-panel.
A possible elegant solution:
* Correct HAL's detection of brightness setting capability on dell, so that it only reports it when it can be set with no errors. It might require using some test method in libsmbios, which I don't know if it is present or has to be added.
Maybe also add some way for HAL to read the bios password from config files if the user wishes so. (This is probably somewhat already planned)
Solving the stalling in libsmbios might prevent crashes, but yet HAL would keep calling it and get errors, so a fix in HAL is needed.
Less elegant:
turn off HAL's usage of libsmbios in one of its config files and have users who want it to manually set it.
possible temporary workarounds for users experiencing this:
- unset the bios password
- blacklist the dcdbas kernel module
- disable dimming in gnome-power
- I don't know how to disable this functionality from HAL, but that would be the best workaround.
NOTE: if HAL is allowed to use libsmbios a local user could exploit it to induce a denial of service or crash.
I hope this info proves clear and useful. For anything else just ask.
|
This description is totally rewritten by Andrea Ratto (LP andrearatto) to recap the situation. The root cause has been really hard to find as it seemed a kernel issue related to the touchpad at first.
The problem reported here and its cause have already been confirmed by at least 5 users.
This bug refers primarily to HAL, but also relates to libsmbios. It is triggered by gnome-power-manager, but it's not its fault.
Symptoms:
very frequent temporary lock-ups on input after some inactivity
frequent hard lock-ups with CAPS lock and NUM lock flashing
very frequent loss of synchronization with the touchpad, which then looses advanced functionalities; with this in dmesg
[ 804.829840] psmouse.c: GlidePoint at isa0060/serio1/input0 lost synchronization, throwing 4 bytes away.
[ 807.405427] psmouse.c: resync failed, issuing reconnect request
[ 810.926845] input: PS/2 Mouse as /devices/virtual/input/input9
[ 810.973805] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input10
Affected hardware:
Latitude D620, D420, D630 with a BIOS password set
Releases affected
Hardy & Intrepid
Other Distros are affected too, e.g. Fedora 9.
What is known so far:
gnome-power-manager tries to dim the brightness of the screen after some inactivity and then reset it upon input.
This is a default setting, so the user has no clue of what might be causing the issue.
gnome-power-manager calls HAL to do the job. HAL on dell machines, since hardy, uses libsmbios for brightness setting.
Libsmbios needs the BIOS password even to change the brightness and HAL has no way to tell it that password, as of now. Some users have also reported that libsmbios does not work even from the command line utility, specifying the pass.
However, instead of just printing an error when it fails, it makes the computer lock for a few seconds, due to the direct interaction with the bios on a very low level. The kernel has then problems reading input events and might crash. These lock-ups should also be avoided in libsmbios, as that is really ugly. However it needs root privileges and it's HAL who is calling it again and again when it should not, so the lockups are more HAL's fault.
Testing/repoducing:
1: of course using gnome and gnome-power-manager, setting "Dim display when idle" to enabled.
Same effects can be achieved by:
2: using the command /usr/sbin/dellLcdBrightness from libsmbios-bin package.
Here's a command that rapidly switch brightness 10 times:
for x in `seq 1 10`; do sudo dellLcdBrightness -a -v 1;sleep 0.1; sudo dellLcdBrightness -a -v 5; done
#Warning it may hang your machine
3: the brightness applet of the gnome-panel.
A possible elegant solution:
* Correct HAL's detection of brightness setting capability on dell, so that it only reports it when it can be set with no errors. It might require using some test method in libsmbios, which I don't know if it is present or has to be added.
Maybe also add some way for HAL to read the bios password from config files if the user wishes so. (This is probably somewhat already planned)
Solving the stalling in libsmbios might prevent crashes, but yet HAL would keep calling it and get errors, so a fix in HAL is needed.
Less elegant:
turn off HAL's usage of libsmbios in one of its config files and have users who want it to manually set it.
possible temporary workarounds for users experiencing this:
- unset the bios password
- blacklist the dcdbas kernel module
- disable dimming in gnome-power
- I don't know how to disable this functionality from HAL, but that would be the best workaround.
NOTE: if HAL is allowed to use libsmbios a local user could exploit it to induce a denial of service or crash.
I hope this info proves clear and useful. For anything else just ask.
|
|
| 2008-07-02 19:42:35 |
Mario Limonciello |
description |
This description is totally rewritten by Andrea Ratto (LP andrearatto) to recap the situation. The root cause has been really hard to find as it seemed a kernel issue related to the touchpad at first.
The problem reported here and its cause have already been confirmed by at least 5 users.
This bug refers primarily to HAL, but also relates to libsmbios. It is triggered by gnome-power-manager, but it's not its fault.
Symptoms:
very frequent temporary lock-ups on input after some inactivity
frequent hard lock-ups with CAPS lock and NUM lock flashing
very frequent loss of synchronization with the touchpad, which then looses advanced functionalities; with this in dmesg
[ 804.829840] psmouse.c: GlidePoint at isa0060/serio1/input0 lost synchronization, throwing 4 bytes away.
[ 807.405427] psmouse.c: resync failed, issuing reconnect request
[ 810.926845] input: PS/2 Mouse as /devices/virtual/input/input9
[ 810.973805] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input10
Affected hardware:
Latitude D620, D420, D630 with a BIOS password set
Releases affected
Hardy & Intrepid
Other Distros are affected too, e.g. Fedora 9.
What is known so far:
gnome-power-manager tries to dim the brightness of the screen after some inactivity and then reset it upon input.
This is a default setting, so the user has no clue of what might be causing the issue.
gnome-power-manager calls HAL to do the job. HAL on dell machines, since hardy, uses libsmbios for brightness setting.
Libsmbios needs the BIOS password even to change the brightness and HAL has no way to tell it that password, as of now. Some users have also reported that libsmbios does not work even from the command line utility, specifying the pass.
However, instead of just printing an error when it fails, it makes the computer lock for a few seconds, due to the direct interaction with the bios on a very low level. The kernel has then problems reading input events and might crash. These lock-ups should also be avoided in libsmbios, as that is really ugly. However it needs root privileges and it's HAL who is calling it again and again when it should not, so the lockups are more HAL's fault.
Testing/repoducing:
1: of course using gnome and gnome-power-manager, setting "Dim display when idle" to enabled.
Same effects can be achieved by:
2: using the command /usr/sbin/dellLcdBrightness from libsmbios-bin package.
Here's a command that rapidly switch brightness 10 times:
for x in `seq 1 10`; do sudo dellLcdBrightness -a -v 1;sleep 0.1; sudo dellLcdBrightness -a -v 5; done
#Warning it may hang your machine
3: the brightness applet of the gnome-panel.
A possible elegant solution:
* Correct HAL's detection of brightness setting capability on dell, so that it only reports it when it can be set with no errors. It might require using some test method in libsmbios, which I don't know if it is present or has to be added.
Maybe also add some way for HAL to read the bios password from config files if the user wishes so. (This is probably somewhat already planned)
Solving the stalling in libsmbios might prevent crashes, but yet HAL would keep calling it and get errors, so a fix in HAL is needed.
Less elegant:
turn off HAL's usage of libsmbios in one of its config files and have users who want it to manually set it.
possible temporary workarounds for users experiencing this:
- unset the bios password
- blacklist the dcdbas kernel module
- disable dimming in gnome-power
- I don't know how to disable this functionality from HAL, but that would be the best workaround.
NOTE: if HAL is allowed to use libsmbios a local user could exploit it to induce a denial of service or crash.
I hope this info proves clear and useful. For anything else just ask.
|
This description is totally rewritten by Andrea Ratto (LP andrearatto) to recap the situation. The root cause has been really hard to find as it seemed a kernel issue related to the touchpad at first.
The problem reported here and its cause have already been confirmed by at least 5 users.
This bug refers primarily to HAL, but also relates to libsmbios. It is triggered by gnome-power-manager, but it's not its fault.
Symptoms:
very frequent temporary lock-ups on input after some inactivity
frequent hard lock-ups with CAPS lock and NUM lock flashing
very frequent loss of synchronization with the touchpad, which then looses advanced functionalities; with this in dmesg
[ 804.829840] psmouse.c: GlidePoint at isa0060/serio1/input0 lost synchronization, throwing 4 bytes away.
[ 807.405427] psmouse.c: resync failed, issuing reconnect request
[ 810.926845] input: PS/2 Mouse as /devices/virtual/input/input9
[ 810.973805] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input10
Affected hardware:
Latitude D620, D420, D630, D830 with a BIOS password set
Releases affected
Hardy & Intrepid
Other Distros are affected too, e.g. Fedora 9.
What is known so far:
gnome-power-manager tries to dim the brightness of the screen after some inactivity and then reset it upon input.
This is a default setting, so the user has no clue of what might be causing the issue.
gnome-power-manager calls HAL to do the job. HAL on dell machines, since hardy, uses libsmbios for brightness setting.
Libsmbios needs the BIOS password even to change the brightness and HAL has no way to tell it that password, as of now. Some users have also reported that libsmbios does not work even from the command line utility, specifying the pass.
However, instead of just printing an error when it fails, it makes the computer lock for a few seconds, due to the direct interaction with the bios on a very low level. The kernel has then problems reading input events and might crash. These lock-ups should also be avoided in libsmbios, as that is really ugly. However it needs root privileges and it's HAL who is calling it again and again when it should not, so the lockups are more HAL's fault.
Testing/repoducing:
1: of course using gnome and gnome-power-manager, setting "Dim display when idle" to enabled.
Same effects can be achieved by:
2: using the command /usr/sbin/dellLcdBrightness from libsmbios-bin package.
Here's a command that rapidly switch brightness 10 times:
for x in `seq 1 10`; do sudo dellLcdBrightness -a -v 1;sleep 0.1; sudo dellLcdBrightness -a -v 5; done
#Warning it may hang your machine
3: the brightness applet of the gnome-panel.
A possible elegant solution:
* Correct HAL's detection of brightness setting capability on dell, so that it only reports it when it can be set with no errors. It might require using some test method in libsmbios, which I don't know if it is present or has to be added.
Maybe also add some way for HAL to read the bios password from config files if the user wishes so. (This is probably somewhat already planned)
Solving the stalling in libsmbios might prevent crashes, but yet HAL would keep calling it and get errors, so a fix in HAL is needed.
Less elegant:
turn off HAL's usage of libsmbios in one of its config files and have users who want it to manually set it.
possible temporary workarounds for users experiencing this:
- unset the bios password
- blacklist the dcdbas kernel module
- disable dimming in gnome-power
- I don't know how to disable this functionality from HAL, but that would be the best workaround.
NOTE: if HAL is allowed to use libsmbios a local user could exploit it to induce a denial of service or crash.
I hope this info proves clear and useful. For anything else just ask.
|
|
| 2008-07-03 00:13:45 |
Saivann Carignan |
description |
This description is totally rewritten by Andrea Ratto (LP andrearatto) to recap the situation. The root cause has been really hard to find as it seemed a kernel issue related to the touchpad at first.
The problem reported here and its cause have already been confirmed by at least 5 users.
This bug refers primarily to HAL, but also relates to libsmbios. It is triggered by gnome-power-manager, but it's not its fault.
Symptoms:
very frequent temporary lock-ups on input after some inactivity
frequent hard lock-ups with CAPS lock and NUM lock flashing
very frequent loss of synchronization with the touchpad, which then looses advanced functionalities; with this in dmesg
[ 804.829840] psmouse.c: GlidePoint at isa0060/serio1/input0 lost synchronization, throwing 4 bytes away.
[ 807.405427] psmouse.c: resync failed, issuing reconnect request
[ 810.926845] input: PS/2 Mouse as /devices/virtual/input/input9
[ 810.973805] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input10
Affected hardware:
Latitude D620, D420, D630, D830 with a BIOS password set
Releases affected
Hardy & Intrepid
Other Distros are affected too, e.g. Fedora 9.
What is known so far:
gnome-power-manager tries to dim the brightness of the screen after some inactivity and then reset it upon input.
This is a default setting, so the user has no clue of what might be causing the issue.
gnome-power-manager calls HAL to do the job. HAL on dell machines, since hardy, uses libsmbios for brightness setting.
Libsmbios needs the BIOS password even to change the brightness and HAL has no way to tell it that password, as of now. Some users have also reported that libsmbios does not work even from the command line utility, specifying the pass.
However, instead of just printing an error when it fails, it makes the computer lock for a few seconds, due to the direct interaction with the bios on a very low level. The kernel has then problems reading input events and might crash. These lock-ups should also be avoided in libsmbios, as that is really ugly. However it needs root privileges and it's HAL who is calling it again and again when it should not, so the lockups are more HAL's fault.
Testing/repoducing:
1: of course using gnome and gnome-power-manager, setting "Dim display when idle" to enabled.
Same effects can be achieved by:
2: using the command /usr/sbin/dellLcdBrightness from libsmbios-bin package.
Here's a command that rapidly switch brightness 10 times:
for x in `seq 1 10`; do sudo dellLcdBrightness -a -v 1;sleep 0.1; sudo dellLcdBrightness -a -v 5; done
#Warning it may hang your machine
3: the brightness applet of the gnome-panel.
A possible elegant solution:
* Correct HAL's detection of brightness setting capability on dell, so that it only reports it when it can be set with no errors. It might require using some test method in libsmbios, which I don't know if it is present or has to be added.
Maybe also add some way for HAL to read the bios password from config files if the user wishes so. (This is probably somewhat already planned)
Solving the stalling in libsmbios might prevent crashes, but yet HAL would keep calling it and get errors, so a fix in HAL is needed.
Less elegant:
turn off HAL's usage of libsmbios in one of its config files and have users who want it to manually set it.
possible temporary workarounds for users experiencing this:
- unset the bios password
- blacklist the dcdbas kernel module
- disable dimming in gnome-power
- I don't know how to disable this functionality from HAL, but that would be the best workaround.
NOTE: if HAL is allowed to use libsmbios a local user could exploit it to induce a denial of service or crash.
I hope this info proves clear and useful. For anything else just ask.
|
This description is totally rewritten by Andrea Ratto (LP andrearatto) to recap the situation. The root cause has been really hard to find as it seemed a kernel issue related to the touchpad at first.
The problem reported here and its cause have already been confirmed by at least 5 users.
This bug refers primarily to HAL, but also relates to libsmbios. It is triggered by gnome-power-manager, but it's not its fault.
Symptoms:
very frequent temporary lock-ups on input after some inactivity
frequent hard lock-ups with CAPS lock and NUM lock flashing
very frequent loss of synchronization with the touchpad, which then looses advanced functionalities; with this in dmesg
[ 804.829840] psmouse.c: GlidePoint at isa0060/serio1/input0 lost synchronization, throwing 4 bytes away.
[ 807.405427] psmouse.c: resync failed, issuing reconnect request
[ 810.926845] input: PS/2 Mouse as /devices/virtual/input/input9
[ 810.973805] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input10
Affected hardware:
Dell Latitude D620, D420, D630, D830 with a BIOS password set
Dell Inspiron 9300
Releases affected
Hardy & Intrepid
Other Distros are affected too, e.g. Fedora 9.
What is known so far:
gnome-power-manager tries to dim the brightness of the screen after some inactivity and then reset it upon input.
This is a default setting, so the user has no clue of what might be causing the issue.
gnome-power-manager calls HAL to do the job. HAL on dell machines, since hardy, uses libsmbios for brightness setting.
Libsmbios needs the BIOS password even to change the brightness and HAL has no way to tell it that password, as of now. Some users have also reported that libsmbios does not work even from the command line utility, specifying the pass.
However, instead of just printing an error when it fails, it makes the computer lock for a few seconds, due to the direct interaction with the bios on a very low level. The kernel has then problems reading input events and might crash. These lock-ups should also be avoided in libsmbios, as that is really ugly. However it needs root privileges and it's HAL who is calling it again and again when it should not, so the lockups are more HAL's fault.
Testing/repoducing:
1: of course using gnome and gnome-power-manager, setting "Dim display when idle" to enabled.
Same effects can be achieved by:
2: using the command /usr/sbin/dellLcdBrightness from libsmbios-bin package.
Here's a command that rapidly switch brightness 10 times:
for x in `seq 1 10`; do sudo dellLcdBrightness -a -v 1;sleep 0.1; sudo dellLcdBrightness -a -v 5; done
#Warning it may hang your machine
3: the brightness applet of the gnome-panel.
A possible elegant solution:
* Correct HAL's detection of brightness setting capability on dell, so that it only reports it when it can be set with no errors. It might require using some test method in libsmbios, which I don't know if it is present or has to be added.
Maybe also add some way for HAL to read the bios password from config files if the user wishes so. (This is probably somewhat already planned)
Solving the stalling in libsmbios might prevent crashes, but yet HAL would keep calling it and get errors, so a fix in HAL is needed.
Less elegant:
turn off HAL's usage of libsmbios in one of its config files and have users who want it to manually set it.
possible temporary workarounds for users experiencing this:
- unset the bios password
- blacklist the dcdbas kernel module
- disable dimming in gnome-power
- I don't know how to disable this functionality from HAL, but that would be the best workaround.
NOTE: if HAL is allowed to use libsmbios a local user could exploit it to induce a denial of service or crash.
I hope this info proves clear and useful. For anything else just ask.
|
|
| 2008-07-04 19:43:01 |
bog |
bug |
|
|
added attachment 'hwinfo.out' (hwinfo.out) |
| 2008-07-18 20:48:12 |
Mario Limonciello |
bug |
|
|
added attachment 'libsmbios_hardy_proposed.debdiff' (libsmbios hardy fix) |
| 2008-07-18 20:48:44 |
Mario Limonciello |
bug |
|
|
added attachment 'libsmbios_intrepid.debdiff' (libsmbios intrepid fix) |
| 2008-07-18 20:49:34 |
Mario Limonciello |
libsmbios: status |
Confirmed |
Fix Committed |
|
| 2008-07-18 20:51:29 |
Mario Limonciello |
dell: status |
New |
Fix Committed |
|
| 2008-07-18 20:56:20 |
Mario Limonciello |
bug |
|
|
added subscriber Ubuntu Sponsors for main |
| 2008-07-18 20:56:37 |
Mario Limonciello |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2008-07-18 21:04:25 |
Mario Limonciello |
libsmbios: assignee |
|
superm1 |
|
| 2008-07-18 21:04:37 |
Mario Limonciello |
hal: assignee |
|
superm1 |
|
| 2008-07-18 21:04:48 |
Mario Limonciello |
libsmbios: assignee |
|
superm1 |
|
| 2008-07-18 21:04:59 |
Mario Limonciello |
dell: assignee |
|
superm1 |
|
| 2008-07-21 22:03:07 |
Mario Limonciello |
bug |
|
|
added attachment 'libsmbios_intrepid.debdiff' (libsmbios intrepid fix) |
| 2008-07-22 06:19:58 |
Martin Pitt |
libsmbios: status |
Triaged |
In Progress |
|
| 2008-07-22 06:19:58 |
Martin Pitt |
libsmbios: assignee |
superm1 |
pitti |
|
| 2008-07-22 14:10:09 |
Launchpad Janitor |
libsmbios: status |
In Progress |
Fix Released |
|
| 2008-07-22 14:46:28 |
Martin Pitt |
hal: status |
Triaged |
Fix Committed |
|
| 2008-07-22 14:50:09 |
Launchpad Janitor |
hal: status |
Fix Committed |
Fix Released |
|
| 2008-07-22 14:50:46 |
Martin Pitt |
hal: status |
New |
In Progress |
|
| 2008-07-22 14:51:45 |
Martin Pitt |
hal: status |
In Progress |
Fix Committed |
|
| 2008-07-22 14:51:57 |
Martin Pitt |
libsmbios: status |
New |
Fix Committed |
|
| 2008-07-22 14:53:49 |
Martin Pitt |
bug |
|
|
added subscriber SRU Verification |
| 2008-07-31 08:36:05 |
Martin Pitt |
hal: status |
Fix Committed |
Fix Released |
|
| 2008-07-31 08:36:18 |
Martin Pitt |
libsmbios: status |
Fix Committed |
Fix Released |
|
| 2008-07-31 19:57:57 |
Mario Limonciello |
dell: status |
Fix Committed |
Fix Released |
|
| 2008-08-27 05:01:59 |
Mario Limonciello |
libsmbios: status |
Fix Committed |
Fix Released |
|
| 2008-08-27 05:01:59 |
Mario Limonciello |
libsmbios: statusexplanation |
|
libsmbios 2.0.3 has been released. Closing the libsmbios task. |
|
| 2009-07-19 05:19:15 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/karmic/libsmbios |
|
| 2009-07-19 05:25:47 |
Launchpad Janitor |
branch linked |
|
lp:~ubuntu-branches/ubuntu/hardy/libsmbios/hardy-proposed |
|
| 2010-02-21 06:53:27 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/hal |
|
| 2010-02-21 07:01:17 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/hardy-proposed/hal |
|
| 2011-02-17 08:32:15 |
Daniel Holbach |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
| 2011-02-17 08:32:31 |
Daniel Holbach |
removed subscriber [DEPRECATED] Ubuntu Sponsors for main |
|
|
|
| 2011-02-21 23:32:28 |
Benjamin Drung |
removed subscriber Ubuntu Sponsors Team |
|
|
|
| 2014-04-10 04:06:41 |
Timothy R. Chavez |
somerville: status |
New |
Fix Released |
|
| 2014-04-10 04:06:41 |
Timothy R. Chavez |
somerville: assignee |
|
Mario Limonciello (superm1) |
|
| 2014-04-10 04:06:46 |
Timothy R. Chavez |
bug task deleted |
dell |
|
|
| 2014-04-10 10:24:43 |
Timothy R. Chavez |
bug task deleted |
somerville |
|
|
