This seems to happen on newer perl versions.
It is fatal in as much as the sensors are not detected.
The solution appears to be to simply add & 0x7f to the
pack statement at line 1138 of sensors_detect...
sub outb
{
my $towrite = pack( "C", $_[1] & 0x7f);
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1774 7894878c-1315-0410-8ee3-d5d059ff63e0
Patch and testing by Rudolf Marek
(mmh) Also added missing declaration for SiS963 support - my bad.
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1752 7894878c-1315-0410-8ee3-d5d059ff63e0
makefile. This prevents ever picking up headers from /usr/include
for module builds. Headers must be located in
/lib/modules/`uname -r`/build
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1746 7894878c-1315-0410-8ee3-d5d059ff63e0
From: rysanek@fccps.cz
Dear Chris,
many thanks for writing eeprom.c in the first place.
It has saved me an indefinite amount of time when I needed
to access a 24C02 in a cursed notebook battery pack that
someone's trying to refurbish.
Many more thanks to the authors of lm_sensors and Linux i2c
for writing their software, of course.
I did have to modify eepromer/eeprom.c a bit though, to support
my 24C02. The essential gotcha was this: whereas the 24C16 that
you were using supports maximum burst size of 16 bytes (the same
applies to 24C08 and 24C04), the 24C02 and 24C01 only support
bursts up to 8 bytes long.
I assume that in fact you already know this, as in your code
there's a neat #define called MAX_BYTES to hold exactly this
burst length. And, this was the first thing I modified when
I was trying to solve my problem.
There's one more associated bug though, probably a result of
the fact that your code was not tested with MAX_BYTES values
other than 16. The two for(;;) cycles for reading/writing
consecutive bursts have a wrong terminal condition: they're
comparing the loop count against MAX_BYTES instead of
(BYTES_PER_PAGE/MAX_BYTES).
With this e-mail, I am enclosing the corrected eeprom.c.
My symptoms looked like this: I read the eeprom just fine.
I did my dirty work on two bytes in the eprom dump and
flashed it back. When I re-read the eprom contents,
I found garbage - or so it seemed.
At a closer look, I found out that every second
half-burst (the second 8 bytes of the 16) was correct and
every first 8 bytes was garbled. (Compared that using two
hex editors open on consoles 1 and 2.)
After a few more seconds I found out that the two half-bursts
were really identical.
My final explanation is that each 16byte write resulted in
only the first half-burst being overwritten (the second was
left untouched), only the eeprom latched in all 16 bytes
obediently, so that its FIFO overflew and looped around
exactly once, which resulted in the *second* half-burst
being written into the *first* eight bytes...
Based largely on eeprom.c, I've already hacked a simple util
to write only those two or four bytes that matter to me (the
actual battery capacity and the write-protect stuff).
If the battery refurbishment works out, I'll update my website
to report this success, including all my code snippets.
Thanks again :)
Frank Rysanek
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1743 7894878c-1315-0410-8ee3-d5d059ff63e0
This patch fixes a race condition in the lm85 driver and adds support for the
SMC EMC6D100 and EMC6D101. The EMC6D100 and 101 chips have some additional
features that *are not* currently implemented in the driver, but the chip is
detected (by sensors-detect and the lm85 driver).
git-svn-id: http://lm-sensors.org/svn/lm-sensors/trunk@1740 7894878c-1315-0410-8ee3-d5d059ff63e0
