[ltp] * * * WARNING * * * Red Hat 7.1 - seawolf * * * WARNING * * *

Byeong-ryeol Kim linux-thinkpad@www.bm-soft.com
Sat, 21 Apr 2001 22:36:55 +0900 (KST)


On Fri, 20 Apr 2001 phil@netroedge.com wrote:

> On Sat, Apr 21, 2001 at 02:47:54AM +0200, Bill Mair wrote:
> > The newly released Red Hat 7.1 trys to install the lm_sensors package by
> >[...]
>
> Yikes, well we working with IBM. :'(
>
> We've had an open dialog with them requesting technical info and
> documents.  They are trying to make documents available to us which
> are currently company-confidential.  None of the Lm_sensors team has a
> Thinkpad, but we are aware of the problem and are doing what we can to
> get this trouble fixed or a workaround in place.
>
> The bad news is that even if we did fix it now, it wouldn't propigate
> into 7.1 as it is already released.  The good news is that the problem
> may be related to the detection script, which I doubt (cross my
> fingers) isn't run blindly by the RH7.1's installer.
>
> What I can also say, is that it appears from our dialog that Thinkpads
> use some unique uses for the PIIX4 I2C bus.  If you use or want to use
> (not recommended at this point) Lm-sensors, be sure to avoid
> installing the i2c-piix4 bus driver until we understand more.
>
> Summary: we are very much in the dark and don't have our hands on any
> hardware or technical documentation yet.  But, IBM should correct
> this.  (hopefully soon... especially with RH7.1 out! ;')
....

Hello, I'm a Korean 7-years-experienced linuxer who uses ThinkPad 600X(
26459EJ, Coppermine 500 MHZ, 192 MHZ RAM, 6X Matsushita DVD ROM Drive,
IBM Ehterjet Cardbus - Xircom oem. using tulip_cb or xircom_tulip_cb in
linux, Lucent Winmodem) which has unresolved problem such as 'EEPROM Checksum
Error' for some months.

I write this to help constructing a more precise knowledge base about
now infamous 'EEPROM Checksum Error'(error number 188 or 189).
I became aware of 'warnings about using lm_sensors' from Web sites
and mailinglist after I had met above error(error number 189) and my 600X
won't boot properly from early Februrary 2001.
There were only warnings like "Don't use lm_sensors! IBM is trying
to solve this problem.", and there was no clue for whom aleady made
'mistakes' such as using lm_sensors due to lack of information about it.
And there have been such concepts that the ThinkPad which met EEPROM
Checksum Error such as 188 or 189 would never go into CMOS screen
and never boot again.
But, it seems that this 'common sense' is partially right and partially
wrong.

My story is as folows:

I bought a used ThinkPad 600X(26459EJ with US keyboard, P-III 500, 192
MB RAM, DVD ROM Drive, LS120) in December last year.(This was originally
a Japanese model. I had wrote down model, serial number, UUID, etc.).
I initially installed Red Hat 6.2 and updated to the latetest packages
by that time.(exactly speaking, this was a localized distribution of a
Red Hat partner company in Korea, ie., LinuxKorea, Inc., but, low-level
stuffs such as kernel, glibc, etc. are the same as those of original Red
Hat 6.2. And, This distribution is irrelevant with EEPROM Checksum Error).

At first, I had to enable Lucent Windmodem, pcmcia, APM(testing supension
and hibernation using tpctl, apmd, etc.), DVD things(lindvd), external
display etc., under both 2.2 and 2.4 kernel, and these were not so difficult.
Annoying things was about Lucent Windmodem and PPP, But, it was mostly solved
by latest driver(578e or above) supplied by Lucent and changes in kernel ppp
driver.

I proceeded to 7.0 things by manually compiling and installing various
packages of Rawhide(Red Hat developmental distribution), and there had
been no big glitch until I became aware of 'EEPROM Checksum Error' at
POST time one day in early February.
Rawhide kernels had lm_sensors package and kernels were patched to use
those functions. 2.2.17 kernel package seen in updates directory of 7.0(
guinness) has 'lm_sensors', too.
I had installed these kernels, tried to detect modules adequate to
my ThinkPad 600X, and at last put lines to load modules into /etc/rc.d/
rc.local, reboot, tried 'cat /proc/.. ' to check temperature, etc.
Since I used to use computers without powering off, I had not known
there aleady ocuurred problems in my notebook.
This problem was found since the machine crashed down due to kernel
errors and I had to reset it.
At POST time, after the IBM logo appears after checking memory, suddeny
there appeared 'EEPROM Checksum Error ...', and the boot process didn't
proceed any more.

I searched Web sites about ThinkPad in IBM Web sites in USA and Japan,
but there was no solution to this problem. Lately I saw bios solutions
of 188, 189 error about latest A, T, X series, but there was no mention
about 600X or previous models.

I carried my thinkpad 600X to A/S center at Yongsan in Seoul(this is
managed by LG-IBM, a partner company in Korea).
They said "You should repalace youre motherboard, the cost would be about
one million won."(approximately this is equivalent of 800 $.)
I gave a question like "Why don't they simply replace old faulty EEPROM
with new one like other desktop mainboards? When I could not boot ASUS P/I-
P55T2P4 motherboard due to erroneous upgrade of flash ROM BIOS, I could
replace the Flash ROM itself for some cost at ordinary computer shop".
They said "We cannot service such thing, since IBM does not provide those."

BTW, 2~3 days later , I became aware follwings things:
(Of course, Your milage may vary)

I could boot my 600X by pressing F1 key simultaneously while clicking
'Restart' button when Error screen appears after entering password at
'System passwd prompt'.
I could see 'LILO' prompt and eventually login promt of linux console.
Despite of EEPROM Checksum Error The machine worked well.

After this, I tried rebooting by 'shutdown -r now' or pressing 'Ctrl-
Alt-Del'. At early POST(when screen checking system RAM appears), press
F1 persitently, and I could see 'System password prompt' and after that
could see CMOS menu.(in m$ windows 98 SE this does not occur).
At first, I thought the 'EEPROM Checksum Error' was solved, but, that was
meerly a misunderstanding.
I could go into the CMOS menu, but could not set some things about CPU,
password, network, boot sequence, initallization among various setup
menu. Some important sub-menus which could not be accessed was fixed as
it was before 'EEPROM Checksum Error' occurred.

Nevertheless, at this time, I recognized very important thing. The
information of CMOS screen shows that UUID of my notebook was changed from
'8140CF6F-CB113544-7A9FC5A9-1B0C7CA3'(the was real number when I purchased
600X) to different number, ie., '6FCF4081-4435-11CB-A9C5-9F7AA37C0C1B'.(
maybe endianness problem or so?, but now, this number was automatically
changed to another number since I used maintenace diskette and short-cut key
to try to repair UUID problem to no avail).
I'm convinced that other information such as system unit s/n, system board
s/n were the same as before, since I had wrote down those right after I
purchased it. Then, I used maintenance diskette or short-cut keys to change
the UUID number. But, IBM set it up as a 'mission impossible' for ordinary
Thinkpad user to change UUID manullay. UUID is changeable only automatically
by proper tools mentioned above, but that does not restore original UUID.

I became suspicious of the intention of 'EEPROM Checksum Error', and
reached to temporary conclusion that this is not for proper operation of
ThinkPad products but for assets managing and for preventing ThinkPad
products to be carried out of companies without permission of named assets
manager. If so, why individual owners like me suffers from special functions
only essential for middle-scale or big corporations? For individuals, Why
is this necessar? This function is useless without separate devices which
can read RFIDs, etc. If not so, should individual owners buy another device
to prevent theft?
IMHO, IBM semms to have very contradictive and ridiculous policy here, since
they forces the same UUID per product, recommends to maintain the same UUID
after replacing units and kindly informs the method of generation UUID in
their PDF manuals.
But, the UUID-generationg tools errorneously generates different UUID from
original one every time.
Generally it seems that engineers in IBM A/s center worldwide recommends
very expensive way of replacing faulty but basically working motherboard to
new motherboard for their conviniences' sake and for their business' sake.

Last, I currently can go into CMOS and boot into linux with my notebook, and
it works well inspite of some annoying time-killing procedure at hardware
booting. This is indeed inconvinient but the machine is alive. So, don't
repalace your expensive motherboards so early.
And, though I admit the possibility for 'lm_sensors' thing to corrupt specific
data of EPROM, but I think this is avoidable by merely not setting up
'lm_sensors' thing and the best thing would be such that IBM should provide
very cheap reasonable solution other than replacing motherboars for aleady
corrupted EEPROM as early as they can.

Thanks,
-- 
 "Where there is a will, there is a way."  jinbo21@hananet.net
  For the future of you and me!            hitel: jinbo21



----- The Linux ThinkPad mailing list -----
The linux-thinkpad mailing list home page is at:
http://www.bm-soft.com/~bm/tp_mailing.html