Public bug reported:
Binary package hint: hal
This is a follow-up bug to reap the fruits of comments and testing of #189814
and its duplicates. 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, please mark as such.
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.
Please CC dell on this.
** Affects: hal (Ubuntu)
Importance: Undecided
Status: New
** Description changed:
Binary package hint: hal
This is a follow-up bug to reap the fruits of comments and testing of
#189814 and its duplicates. 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, please mark as such.
- This bug refers primarily to HAL but also to libsmbios. It is triggered by
gnome-power-manager, but it's not its fault.
+ 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 need the BIOS password even to change the brightness and HAL
- has no way to tell it, as of now. Some users have also reported that
- libsmbios does not work even from the command line utility, specifying
- the pass.
+ 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 when it should not, so the lockups are more
- HAL's fault.
+ 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.
Please CC dell on this.
--
HAL crashes dell laptops with a BIOS password
https://bugs.launchpad.net/bugs/244606
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
