#Dell latitude d420 bios battery reset full#
#Dell latitude d420 bios battery reset windows#

My D820 died after an hour or so and I could reproduce this several times while playing with kernel options like disabling acpi.īy the way: Currently I'm using a Dell Latitude D810 and I have installed Dapper when the Final was released. If it survives this extreme-rebooting for some hours then I think we can be pretty sure the problem is solved. If someone has a Dell Latitude D820 (where recovering from the problem is quite easy because of the accessible CMOS battery) it would be very nice if he tries the current kernel and start it with kernel option 'init=/ sbin/reboot'. Or maybe all affected people have switched to an other laptop.

So you just have to remove one screw and this cover and then you can pull out the battery.īut after Dapper was released (with 2.6.15-23 kernel) it got very quite here. The Dell Latitude D820 has this battery under the cover of the memory slots. If it corrupts the BIOS again then you can simply remove the CMOS battery, wait some time to let the BIOS reset and it will boot again. If you can access the CMOS battery then it's safe to try Dapper again. Some people have reported success by removing the coin-cell battery, but others have not.

#Dell latitude d420 bios battery reset windows#

If you boot into Windows XP, WinXP seems to do something to restore the BIOS settings to normality. If you notice the grub timer has frozen, you can still use the keyboard to select a kernel/OS in the grub menu and boot that way. But perhaps sleep/hibernate also write to hwclock? I had to remove AC power and main battery to recover. On another occasion, I tried to do a sleep and/or hibernate and got a coma instead. I don't know if this would have written the hardware clock.

It crashed badly (touchpad, keyboard and USB mouse were not responsive, gdm would not restart and I could not select a tty) and I had to use the power button to turn off.

#Dell latitude d420 bios battery reset full#

* if, however, the BIOS does do a full verify, then it detects the corruption and halts with the 'Time-of-day clock stopped' error. However, something has failed because the grub timer does not count down, and the time displayed on the Gnome panel is incorrect.

* as long as the BIOS does not do a full verify during POST, it loads the MBR and booting continues as normal. This might be when the hwclock is written at shutdown. * something corrupts the RTC or BIOS NV data. There seem to be two phases to the problem on my Inspiron 6400 with kernel 2.6.15-22.686