[ltp] T20 won't start

Michael Karcher linux-thinkpad@linux-thinkpad.org
Tue, 29 May 2007 16:16:09 +0200


--=-ZjlIw1ombS6aMyIwg+gx
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Am Dienstag, den 29.05.2007, 10:31 -0300 schrieb Henrique de Moraes
Holschuh:
> > power button was possible. I currently (on AC, batteries charged) can't
> > reproduce it just now, but I also had it with the current git kernel
> > (2.6.22-rc1 + git patches).
> Make really sure you have the latest T20 bios and ec (IBM calls it
> differently in the t20, I believe they call it "slave controller" or
> somesuch).
It is up to date, definitively.

> Check if using "shutdown" instead of "platform" for the sleep-to-disk met=
hod
> won't fix the issues.  It might, and many thinkpads seem to react very ba=
dly
> to "platform" the way 2.6.21 is doing it.
The issue is much less a problem using suspend to disk than suspend to
ram. I might try using the other method, though.

> > 2. This machine works on two mainly dead batteries (an original IBM
> > ultrabay battery, probably around 5 years old, bought used, ACPI
> This will damage your hardware even further, you know.

The only possible damage I know of is the possible EEPROM corruption on
power failure on boot. This is not an issue. I get something like 90
minutes idle runtime (backlight minimum) with these batteries. Running
without batteries is much more dangerous, to my knowledge. Is there any
further problem I should be aware of?

> > 3. I have a defective DIMM installed, but the defective areas (around
> > 25M and 108M) are excluded by memmap kernel parameters.
> memtest it regularly to make sure the areas have not spread, and that DOE=
S
> include the bit decay test, which takes a damn big while.
Will do so. But the power up problems described here also apply with
both DIMMS removed, so I don't suppose this to be the main cause.

> Also, defective DIMMS might have cells shorted,
Might be. The strange thing is: The bad cells read *random* values, not
just zero or one, even for the same cell. The bits do not fade, they are
random immediately after flushing the cache.

> which causes a lot of increased current draw when you hit them (in refres=
h, etc).
This is a good point I didn't think about. I use this defective DIMM
since three years, and have the power-on problem just since one week. Of
course the DIMM might got worse.

> This is guaranteed to cause
> suspend-to-ram to go bananas, as the memory modules themselves will refre=
sh
> during S3, and hit their bad cells...
Even S3 (the main operating mode of my laptop, reboots only if ACPI
crashed) did not make any problem in the last three years, just the
laptop-dead-on-turn-on failure seen not only on S3 resume (although it
is most critical here, as the RAM contents is gone after the spontaneous
power-off) appeared.

> >  UseSysfsPowerState mem
> >  PowerdownMethod platform
> Try "shutdown" (or "poweroff", I always forget).
It's shutdown. But it's don't care for mem, only disk needs this entry.

Thanks for your suggestions,
 Michael Karcher
--=20
Michael Karcher
Freie Universit=E4t Berlin
Institut f=FCr Experimentalphysik
Arbeitsgruppe Fumagalli
Arnimallee 14
14195 Berlin

Tel: 030-838-55591
Fax: 030-838-56299



--=-ZjlIw1ombS6aMyIwg+gx
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: Dies ist ein digital signierter Nachrichtenteil

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBGXDWpzhek2R7EicoRApi6AJ4k4+w3DIt5Ars58P/tSfrr83uWigCeJGUO
zoCkkLzbAo08bUHi0EqsK50=
=5ilW
-----END PGP SIGNATURE-----

--=-ZjlIw1ombS6aMyIwg+gx--