HAL lockups/crashes on Dell D-series Latitudes w/ BIOS password

[Saivann Carignan]

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.

[Miguel Ruiz (mruiz)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. I'm using Hardy Heron up to date and I cannot reproduce this problem (my system doesn't freeze). Would you test it again using the last version of Hardy?

Thanks again and we appreciate your help.

Cheers!

[Saivann Carignan (oxmosys)]

Thanks for your answer, it seems fixed in Hardy alpha 5, I can't reproduce the bug anymore. Setting to fix released!

[Saivann Carignan (oxmosys)]

As I said in comment #3, this bug seemed to be fixed in alpha 4 (probably linux 2.2.24-11) and then come back with beta 1 (linux 2.6.24-12).

[Saivann Carignan (oxmosys)]

Still confirmed with linux 2.6.24-15, pretty bad issue.

[Saivann Carignan (oxmosys)]

Disappeared with 2.6.24-16

[Aitor Pazos (aitorpazos)]

Same bug on my Latitude D420 with 2.6.24-16-generic. Kernel panic fixed with clocksource=hpet parameter as is said on Bug #190414. Symptom not fixed and I loose my right button when it happens.

[Aitor Pazos (aitorpazos)]

(Workaround) After suspending I get my right button back

[Saivann Carignan (oxmosys)]

Aitor Pazos : Do you get the same behavior than described in the bug description ( with the same dmesg outputs ) ?

[Aitor Pazos (aitorpazos)]

I get the same output and it behaves as described. Sound also stalls for 1 or 2 seconds when computer is idle for a while without touching anything.

dmesg output:

[ 266.266778] psmouse.c: GlidePoint at isa0060/serio1/input0 lost synchronization, throwing 2 bytes away.
[ 269.718340] psmouse.c: resync failed, issuing reconnect request
[ 271.968398] input: PS/2 Mouse as /devices/virtual/input/input25
[ 272.045379] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input26

[Saivann Carignan (oxmosys)]

Aitor Pazos : Thanks for your fast confirmation. Can you attach the 4 files created by these commands in a terminal?

    uname -a > uname-a.log
    cat /proc/version_signature > version.log
    dmesg > dmesg.log
    sudo lspci -vvnn > lspci-vvnn.log

[Aitor Pazos (aitorpazos)]

No problem.
Sorry for dmesg because I've suspended my laptop and interesting messages may be lost in me middle of a bunch rubbish

[Saivann Carignan (oxmosys)]

I got to reproduce the bug again today. The bug does not happen immediately when unplugging electric cable like it did in the past, but if I let the laptop without any activity for ~10 minutes, the mouse freeze.

[bro (matthijsbro)]

Hi, a discussion started here: http://ubuntuforums.org/showthread.php?p=4986873#post4986873 with people having similar problems on Dell D830.
I don't have this problem related to plugging/unplugging just with leaving it for a few minutes. Example when playing music standalone cpu peaks and sound stutters for several seconds. This, however, happened too several times when playing video (flash or mplayer alike) while I was working in another window.

[Niels Egberts (nielsegberts)]

I still can't use hardy on my Dell lattitude, has anyone found a fix/workaround for this problem?

[Andrea Ratto (andrearatto)]

I have this very same problem with 2.6.24-17 generic on a dell latitude d630. And it really bothers me.

My latitude has a "touch point", a sort of secondary mouse in the middle of the keyboard. I was wondering if this bug is somewhat related only to similar hardware configurations. Is there someone that does NOT have another mouse/touch point and experience this problem?

Ironically I was trying fedora 9 because of this problem with the thouchpad and related instability and got it there too. So it is 99% sure not Ubuntu specific and it is not being fixed in 2.5.25! That's one sneaky and evil bug.
From what I've seen many people are having this and complaining about and probably there are lots more that didn't properly identified the issue, as dell laptops are pretty common. I would really like the priority of this to be set to High, as it is a regression too, coming from gutsy.

PS I think this bug is the same of 207919.

[bro (matthijsbro)]

@Andrea, I'm pretty sure I don' t have this problem with Mandriva 2008.1 (kernel 2.6.24-?) So it might not be Ubuntu specific, It might also not be 'kernel general'.

[Niels Egberts (nielsegberts)]

I too have an extra "touch point". However my siser has got one too on her d630 and is not experiencing this problem (me jealous). But that is not a reason to not assume this bug is caused by the second-touch-thingy.

[Andrea Ratto (andrearatto)]

still present with 2.6.24-19-generic. Here are my findings:
1 battery or not battery it happens
2 it starts when using again the touchpad after a period of inactivity. (Maybe on battery this period can be shorter)
when it starts it freezes everything for some seconds, CPU usage get to 100% on all cores. At this point if you keep insisting on the touchpad you can really crash the machine. If you let go it usually just pass but you have to notice quickly.
3 sometimes the touchpad looses touchpad functionalities (eg scrolling on the right border).
4 dmesg entry "psmouse.c: GlidePoint at isa0060/serio1/input0 lost synchronization, throwing N bytes away." not always shows.
5 many people are having this problem, someone also on fedora, someone since 2.6.15, mostly on dell laptops.

I think I could get to reproduce it anytime I want, so I can produce any debug/crash information. Just tell me what to do and I'll do it.

[bro (matthijsbro)]

I can confirm Andrea's findings 100% it sums it up for me completely.
Especially that there is no relation between inplugging / outplugging of the
battery.
On the side, my now 80% complete switch to mandriva to avoid this bug
learned me that (k)ubuntu should drastically improve its kde integration...

I any testing on a dell needs done I'm available with a D830.

On Mon, Jun 9, 2008 at 2:54 PM, Andrea Ratto <email address hidden>
wrote:

> still present with 2.6.24-19-generic. Here are my findings:
> 1 battery or not battery it happens
> 2 it starts when using again the touchpad after a period of inactivity.
> (Maybe on battery this period can be shorter)
> when it starts it freezes everything for some seconds, CPU usage get to
> 100% on all cores. At this point if you keep insisting on the touchpad you
> can really crash the machine. If you let go it usually just pass but you
> have to notice quickly.
> 3 sometimes the touchpad looses touchpad functionalities (eg scrolling on
> the right border).
> 4 dmesg entry "psmouse.c: GlidePoint at isa0060/serio1/input0 lost
> synchronization, throwing N bytes away." not always shows.
> 5 many people are having this problem, someone also on fedora, someone
> since 2.6.15, mostly on dell laptops.
>
> I think I could get to reproduce it anytime I want, so I can produce any
> debug/crash information. Just tell me what to do and I'll do it.
>
> --
> [hardy]computer and touchpad is buggy when running on battery
> https://bugs.launchpad.net/bugs/189814
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[l0d0g (lee-thompson)]

I also agree with Andrea,

Seems to be related to the kernel in some way, some kernel updates exhibit the bug, others not.

I'm using a dell xps m1710, bug occurs, with power or battery, and is repeatable using kernel Linux 2.6.24-19-generic #1 SMP i686 GNU/Linux

Rolling back to the previous kernel release has provided a work around as I have had no such problems using Linux 2.6.24-18-generic #1 SMP Wed May 28 20:27:26 UTC 2008 i686 GNU/Linux,

[exactt (giesbert)]

hi guys,

check out https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/34501 or https://bugs.launchpad.net/bugs/119194 . maybe it is related...

[Andrea Ratto (andrearatto)]

You might want to give a try to adding "i8042.nomux=1" to your kernel command line.
It is *maybe* working for me.
And if someone knows what does that mean, I'd like to know...

[Niels Egberts (nielsegberts)]

Does not work for me.

I ran Hardy with that kernel-command, unplugged the powercord, moved my mouse and it froze for a few seconds. Every time I try I get this dmesg:

niels@inoue:~$ dmesg | tail
[ 389.555996] CPU0 attaching sched-domain:
[ 389.556008] domain 0: span 03
[ 389.556016] groups: 01 02
[ 389.556023] domain 1: span 03
[ 389.556031] groups: 03
[ 389.556036] CPU1 attaching sched-domain:
[ 389.556043] domain 0: span 03
[ 389.556046] groups: 02 01
[ 389.556056] domain 1: span 03
[ 389.556059] groups: 03

[Andrea Ratto (andrearatto)]

With the heat of these last days it seems to happen even more. Kernel parameters did not solve the issue.
Yesterday I also uncovered something. I was watching a video on youtybe and had the screensaver coming in every minute, so I touched the touchpad everytime the screen started to go black. This mostly resulted in a few second of audio looping and gui freeze. Interesting is that it happened with the touchpad, the "touchpoint" and the keyboard itself. So it is not specific to touchpads or the tiny blue "touch point", but also can be triggered by the keyboard.

Can also someone CC dell on this bug?
PS happened a total of three times during writing of this and crashed my laptop around 3 times a week since hardy installation, so how about setting priority to high? If it does not get solved I will have to switch distro...

[Niels Egberts (nielsegberts)]

Yes, it freezes on every input method (blue point, keyboard and touchpad).

I have installed Intrepid Alpha 1 with the cd (clean install) but this bug is still there.

[Niels Egberts (nielsegberts)]

In a duplicate (#243595) of this bug there is this comment:

"I disabled "Dim display when idle" in both AC and BAT on Gnome Power Managment and it works OK. No need for kernel paramaters though. I'll keep testing."

I did this on Intrepid Alpha 1 and to my surprise i can't reproduce the bug anymore by unplugging my powercord or leaving my laptop for a few minutes untouched. When I enable "Reduce backlight brightness when inactive" again, the bug is back.

[Andrea Ratto (andrearatto)]

Just answer me an apparent silly question if you are experiencing this.

Do you have a BIOS password set?

[Niels Egberts (nielsegberts)]

No, never had.

[Andrea Ratto (andrearatto)]

I think I now where the problem lies ultimately. Can you just do a small
test for me? Add a brighness applet to the gnome panel and try to see if
that works smoothly.

On my d630 it does not work with a bios password set, but does without.

Il giorno lun, 30/06/2008 alle 08.53 +0000, BackwardsDown ha scritto:
> No, never had.
>

[Aitor Pazos (aitorpazos)]

With last kernel and modules update (2.6.24.29-generic) I don't get the following messages anymore:
[ 266.266778] psmouse.c: GlidePoint at isa0060/serio1/input0 lost synchronization, throwing 2 bytes away.
[ 269.718340] psmouse.c: resync failed, issuing reconnect request
[ 271.968398] input: PS/2 Mouse as /devices/virtual/input/input25
[ 272.045379] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input26

No more kernel panics either.

But after being a while ( 10-20 seconds) without using it and with no cord plugged there is a strange high CPU usage for about 3 seconds and the pc seems to be hanged. Even playing music starts making noise. This behavior isn't new but is the only symptom that still occur on my laptop.

[Federico M. Pires (fpires82)]

Hi,

I'm the one of the duplicate bug :) and i do have a BIOS password set... I'll try later without setting it although it sounds weird.. I'll be back with the results.

Regards,

[Andrea Ratto (andrearatto)]

This is my idea:
gnome-power-manager tries to dim the brightness of the screen after some inactivity and then reset it upon input.
gnome-power-manager calls HAL to do the job. HAL has multiple methods of handling brightness of LCD panels. On dell machines, since hardy it uses a libsmbios.
Libsmbios has only rudimentary support for setting the brightness thought. For example it does not work if a BIOS password it set and apparently on some dell models.
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.

There is a very easy way to try if it work on your computer 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

Without a BIOS password it works fine on my laptop (D630)

Another way could be with the brightness applet of the gnome-panel.

A possible elegant solution:
Correct HAL's detection of this capability, so that it only reports it when brightness can be set with no errors. Maybe also add some way for HAL to read the bios password from config files if the user wishes so. Oh and fix libsmbios to avoid stalling on error, that is ugly.
Less elegant:
turn off HAL's usage of libsmbios in some config file and have users who want it to manually set it.

possible temporary workaround:
blacklist the dcdbas kernel module
disable dimming in gnome-power
I don't know how to disable it 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 useful.

[Niels Egberts (nielsegberts)]

Sorry, I was wrong about my statement that I had no bios-password. I have checked and I do have one.

Good to hear that you have found the source of the bug.

[Niels Egberts (nielsegberts)]

I removed my bios-password (had to call dell because I forgot it) and indeed it works like a charm.

[Aitor Pazos (aitorpazos)]

I've been trying dellLcdBrightness for a while. It doesn't matter if I enter the correct BIOS password or not ("dellLcdBrightness -a -v 1" or "dellLcdBrightness -a -v 1 -p <password>"). My D420 still acts as if it was locked.

Removing BIOS password works perfectly for me.

[Andrea Ratto (andrearatto)]

I really took interest in fixing this and it seems I finally hit the root of the problem. Thanks to you all for your comments and trials, as without the hint on gnome-power-manager I would never have though of such a thing. The community is always great!

If others having this problem confirm that it disappears with no BIOS password, probably the best thing is to open a new bug against HAL with concise infos. I'll be glad to do it myself tomorrow if nothing new shows up here.
It's nice to have stability again.

[Federico M. Pires (fpires82)]

Hi... I can confirm that the problem disappears with no BIOS password. Keep in mind that this didn't happen to me with kernel 2.6.22 and started since 2.6.23 or .24... so might be somehow related?

[Saivann Carignan (oxmosys)]

I can confirm that this bug can only be reproduced when the laptop have a BIOS password set! Thanks for finding this!

[Saivann Carignan (oxmosys)]

Still happens with 2.6.26-2 (intrepid)

[Andrea Ratto (andrearatto)]

A detailed new bug report as been opened, now that we got to the root of this:
https://bugs.launchpad.net/ubuntu/+source/hal/+bug/244606

please mark this as closed and anyone interested move to the new one.

[Saivann Carignan (oxmosys)]

Andrea Ratto : Your description in bug 244606 is excellent, however please don't hesitate to improve the description of the current bug instead of opening a new one because we have a good amount of relevant comments here. You can also add/change the package to hal if you think that this is the right one. Huge thanks for your contribution so far!

[Andrea Ratto (andrearatto)]

After many comments and investigations, found the root cause!

[Andrea Ratto (andrearatto)]

I really did not know that I could alter the original description and do the other stuff myself.

Dell guys please read the description, this matters to you.

[Mario Limonciello (superm1)]

Can we try to get a concise list of affected platforms? This isn't on all series of Dell laptops.

I just tested with an XPS1330 (Intel graphics) and wasn't able to reproduce any hangups when I turned on a BIOS password.

[Mario Limonciello (superm1)]

Also couldn't reproduce with a Studio 1535 (AMD graphics).

[Andrea Ratto (andrearatto)]

latitude d630 here. If I remember correctly there are some older latitudes as well: d620, d420.
btw did you try the command line dellLcdBrightness or the panel applet and got smooth operation?

[Mario Limonciello (superm1)]

I used the command that you posted. So it is sounding like only the
D-Series latitudes are affected then?

Andrea Ratto wrote:
> latitude d630 here. If I remember correctly there are some older latitudes as well: d620, d420.
> btw did you try the command line dellLcdBrightness or the panel applet and got smooth operation?
>
>

--
Mario Limonciello
*Dell | Linux Engineering*
<email address hidden>

[Andrea Ratto (andrearatto)]

I asked a friend to test on an inspiron and he did not have problems.
I don't have access to any more dell machines, maybe it's latitude only.
Seems kind of strange in fact to need the bios password to change brightness, at least it's not done on every line.

[Federico M. Pires (fpires82)]

It's on my Latitude D620. I can confirm that. Also as I said, i tried downgrading to kernel 2.6.22 in Hardy from the Feisty repos and it doesn't happen with the BIOS password set. So I think it's related somehow to the kernel version too. Hope this helps.

[Andrea Ratto (andrearatto)]

probably on older kernel Hal does not report brightness setting capability to gnome-power-manager, so the bug is just not triggered. You also loose that functionality if you note.

[Niels Egberts (nielsegberts)]

I confirm on a Dell D830.

[bro (matthijsbro)]

Same here on a D830.

On Wed, Jul 2, 2008 at 9:33 PM, BackwardsDown <email address hidden>
wrote:

> I confirm on a Dell D830.
>
> --
> HAL lockups/crashes on Dell D-series Latitudes w/ BIOS password
> https://bugs.launchpad.net/bugs/189814
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Mario Limonciello (superm1)]

What type of password are you setting in the BIOS? system password or admin password?

On a D830 w/ BIOS A12 I'm unable to reproduce any problems running that command with a system password set.

[Aitor Pazos (aitorpazos)]

Confirmed on my Latitude D420

El mié, 02-07-2008 a las 19:33 +0000, BackwardsDown escribió:
> I confirm on a Dell D830.
>
> --
> HAL lockups/crashes on Dell D-series Latitudes w/ BIOS password
> https://bugs.launchpad.net/bugs/189814
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in The Dell Project: New
> Status in The libsmbios project: Confirmed
> Status in “hal” source package in Ubuntu: Triaged
> Status in “libsmbios” source package in Ubuntu: Triaged
>
> Bug 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 ma...

[Andrea Ratto (andrearatto)]

Hal does not run the command with the password and that's how you are supposed to reproduce this bug.

[bog (martaina)]

thank you very much for your work!
I can confirm this bug with my BIOS password set. It s a Dell D830 running Ubuntu Hardy with 2.6.24-19-generic.
i have to try without bios password set...
will repost the result.

thanks again
(have to link my bug report to this one)

[bog (martaina)]

I disabled the password . the brightness test didnt work before unsetting it and now works perfect. hurray
thanks a lot
if i can help with any data please let my know.

[bog (martaina)]

i still get random hangs. But i dont know for shure if they are related to this issue.
i have all passwords disabled.

[Mario Limonciello (superm1)]

OK folks, I've got a solution together, and it involves fixing both libsmbios and hal. The solution has been accepted upstream for libsmbios. Once there is a new release of libsmbios that includes this fix, I'll submit it to upstream hal as well.

This is the commit in libsmbios that is necessary for the HAL fix to work:
http://linux.dell.com/git/?p=libsmbios.git;a=commitdiff;h=ad6c807303b7db44cc8c71f8b01722ff2b7b8d68;hp=1168ed653e2d95cb2336d0e851822fcd23265718

Attached is a debdiff for hardy-proposed.

[Mario Limonciello (superm1)]

Here is the debdiff for libsmbios intrepid

[Mario Limonciello (superm1)]

I've registered two branches to this bug for hal in hardy-proposed as well as hal in intrepid.

[Niels Egberts (nielsegberts)]

I'm very very happy to hear that the fix for this bug is coming in my way :D

Thank you very much.

[Mario Limonciello (superm1)]

For those interested in testing this prior to it entering hardy-proposed, i've uploaded the hardy versions to a PPA:

https://edge.launchpad.net/~superm1/+archive

Add

deb http://ppa.launchpad.net/superm1/ubuntu hardy main
deb-src http://ppa.launchpad.net/superm1/ubuntu hardy main

To your /etc/apt/sources.list if you would like to test.

[Mario Limonciello (superm1)]

Attached is an updated intrepid debdiff. Intrepid's build started to FTBFS over the weekend due to changes in libtool and debian bug 491795

[Martin Pitt (pitti)]

Thanks, Mario! Taking for sponsoring.

What about the hal task in this bug, is it 'invalid' then? Or does something need to be fixed in hal as well?

[Mario Limonciello (superm1)]

Martin:
There are two bzr branches somewhere on this bug for the fixes for hal. They are required in addition to the fixes to libsmbios that debdiffs are posted.

[Launchpad Janitor (janitor)]

This bug was fixed in the package libsmbios - 0.13.13-1ubuntu2

---------------
libsmbios (0.13.13-1ubuntu2) intrepid; urgency=low

  * debian/control:
    - Add dpatch to build-depends
  * debian/rules:
    - Add dpatch support
    - Don't clean up ltmain.sh, config.sub, or config.guess
      as they are shipped in the upstream tarball.
  * debian/patches/01_password_checking.dpatch:
    - Stub out another function for checking the status
      of a bios or admin password. (LP: #189814)

 -- Mario Limonciello <email address hidden> Fri, 18 Jul 2008 13:08:46 -0500

[Martin Pitt (pitti)]

Hal intrepid branch merged, thanks Mario!

[Launchpad Janitor (janitor)]

This bug was fixed in the package hal - 0.5.11-3~ubuntu3

---------------
hal (0.5.11-3~ubuntu3) intrepid; urgency=low

  * Add 05_dell_backlight_lockups.patch:
    -Resolves lockups caused if a BIOS password of some type is active.
     Changing backlight via BIOS w/ a BIOS password is an unsupported
     mechanism currently. (LP: #189814)
  * debian/control:
    - Depend on libsmbios 0.13.13-1ubuntu2 or later for the above patch
      to work.

 -- Mario Limonciello <email address hidden> Tue, 22 Jul 2008 16:45:13 +0200

[Martin Pitt (pitti)]

hardy branch merged, uploaded

[Martin Pitt (pitti)]

libsmbios and hal accepted into hardy-proposed. Please test and give feedback here. Thanks!

See https://wiki.ubuntu.com/Testing/EnableProposed for instructions how to enable -proposed.

[Andrea Ratto (andrearatto)]

It effectively makes the crashes stop, but I think that the fix solves just the urgent part of the bug. HAL still reports to gnome-power-manager that it can change the brightness, so probably all the related work gets done and simply fails every time with no error.
The brightness applet for example still loads fine and tries to change the brightness with no effect.
I guess that now the bug becomes: "HAL incorrectly reports brightness changing capability on Dell Latitude laptops with a BIOS password set".

PS I hoped I was in for a thank you on this one :-)

[Mario Limonciello (superm1)]

Andrea: As you pointed out, this fix only resolves the urgent part of
the bug. In perusing the HAL code, I didn't see a good way to indicate
that we could only "read" the brightness and not write it. After this
bug is finished up and closed out, we can open a new bug in the future
to try to possibly get that kind of fine grained tuning integrated.

[Martin Pitt (pitti)]

Thanks, Andrea, for your investigations and testing! As Mario pointed out, the fix, as done in the current SRU, was merely aimed at fixing the crash, which seems to work. Thus I consider this verified.

[Saivann Carignan (oxmosys)]

I wanted to add, as a late confirmation, that the latest update also removed all freeze problems on my Dell laptop under Intrepid. This is fixed, thanks for your great work!!

[Martin Pitt (pitti)]

Copied to hardy-updates.

[Mario Limonciello (superm1)]

libsmbios 2.0.3 has been released. Closing the libsmbios task.

[Timothy R. Chavez (timrchavez)]

The bug task for the somerville project has been removed by an automated script. This bug has been cloned on that project and is available here: https://bugs.launchpad.net/bugs/1305748