CVS tests report

[mds@paradyne.com (Mark D. Studebaker )]

Great catch on the eeprom problem.
I duplicated it here.
i2cdump returns the correct values.
However all eeprom directories in /proc/sys/dev/sensors contain
the same values (I have eeproms at 50,51,52 and all the values
are from the chip at 52).

I wonder if the problem is in i2c_register_entry() in i2c-proc.c.
The function was rewritten between 2.7.0 and the branch, then
rewritten again after the branch in the HEAD branch.
I tried the i2c-proc from the HEAD branch but it oopsed
in i2c_register_entry().

I'll keep looking. Anybody with ideas speak up.

Jean Delvare wrote:
> Hi,
> 
> I finished my tests on i2c-CVS and lm_sensors2-CVS. I tested on a first
> machine with a VIA Pro this morning and already posted the results. I
> tested on three other machines since (my fifth one being dead broken, I
> couldn't even setup the network adapter to get the files). There are two
> machines based on a PIIX4 and one based on an Intel i801.
> 
> The first problem concerns unresolved symbols. Three different issues
> exist there:
> 
> depmod: *** Unresolved symbols in
> /lib/modules/2.4.18/kernel/drivers/video/matrox/matroxfb_maven.o.gz
> depmod:         i2c_inc_use_client
> depmod:         i2c_dec_use_client
> 
> This is the same I had this morning with zoran.o. I leave the resolution
> to someone else, I simply don't know what should be done.
> 
> depmod: *** Unresolved symbols in
> /lib/modules/2.4.18/kernel/drivers/i2c/i2c-algo-biths.o
> depmod:         cond_resched
> 
> This one is easily explained. cond_resched() was added in linux 2.4.20,
> so there's no suprise it is unresolved on earlier versions. A patch
> proposal is attached (borrowed the idea from diff'ing
> linux/drivers/mtd/devices/doc2000.c between 2.4.20 and 2.4.21-rc1). Note
> that this is guess work, I absolutely don't know how scheduling is
> supposed to work. The module now loads, but I couldn't test it (I have
> no device using it, as far as I know).
> 
> depmod: *** Unresolved symbols in
> /lib/modules/2.4.18/kernel/drivers/i2c/i2c-proc.o
> depmod:         unlikely
> 
> This third one is strange. The symbol name sounds funny, isn't it ;) The
> problem seems to happen only with 2.4.18 (and probably earlier) kernels
> and is a serious one (considering we hardly can do anything without
> i2c-proc). What's really strange is that unlikely() actually already
> exists in 2.4.18 (in linux/include/linux/compiler.h, a file that didn't
> change at all between 2.4.18 and 2.4.19). I'm somewhat clueless on this
> one.
> 
> The second problem I had is with the eeprom module. On two machines
> (using i2c-i801 and i2c-piix4, repectively), the eeprom module returns
> wrong values. More precisely, it returns the same values for all
> eeproms. On the first machine (my Sony laptop) I had a memory EEPROM
> showing at 0x50 and a proprietary Sony EEPROM at 0x57. Now, the Sony
> EEPROM shows at both 0x50 and 0x57. Same for the other machine where I
> have one 32MB memory chip at 0x50 and a 128MB memory chip at 0x52. Now,
> both chips pretend to be the 128MB one. I guess the recent changes on
> the module may have caused this side effect (which may have been hiding
> so far because most people will actually have the same memory chip sizes
> in all slots).
> 
> So, these things would need to be fixed before I can affirm i801 and
> piix4 drivers have been converted successfully.
> 
> (I will of course test any fix if kindly asked to :))
>