depmod gives a failure: symbol not found "i2c_smbus_read_i2c_block_data" I presume it means i2c_smbus_read_block_data S.
Sorry I didn't say which drivers. depmod: *** Unresolved symbols in /lib/modules/2.4.23/kernel/drivers/i2c/chips/ddcmon.o depmod: i2c_smbus_read_i2c_block_data depmod: *** Unresolved symbols in /lib/modules/2.4.23/kernel/drivers/i2c/chips/eeprom.o depmod: i2c_smbus_read_i2c_block_data depmod: *** Unresolved symbols in /lib/modules/2.4.23/kernel/drivers/i2c/chips/saa1064.o depmod: i2c_smbus_write_i2c_block_data
Can we please have your kernel .config?
Oh yeah, and this happens. It used to work. I upgraded kernel and lm-sensors in that order. I kept the same config. MODULE_2="w83781d force_w83697hf=9191,0x290 ignore_range=0,0,0x7f,1,0,0x7f" <1>Unable to handle kernel paging request at virtual address 0004002c e09d9af3 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[<e09d9af3>] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010206 eax: 00040004 ebx: 00000006 ecx: 00000000 edx: e09dbd2e esi: 00000000 edi: da6ac000 ebp: 00000c00 esp: c6daff38 ds: 0018 es: 0018 ss: 0018 Process sensors (pid: 6022, stackpage=c6daf000) Stack: da6ac000 e09dbd27 00000000 00000000 daba75c0 00000c00 da6ac000 00001000 c0160edf da6ac000 c6daff80 00000000 00000c00 c6daff7c 00000000 df9fb5a0 00000000 00000000 00000000 00000000 daba75a0 ffffffea 00001000 c013b563 Call Trace: [<e09dbd27>] [<c0160edf>] [<c013b563>] [<c010746f>] Code: 8b 50 28 85 d2 74 56 8b 40 24 85 c0 74 41 c7 44 24 04 2f bd >>EIP; e09d9af3 <[i2c-core]read_bus_i2c+63/e0> <===== >>edx; e09dbd2e <[i2c-core].text.end+c9f/cf1> >>edi; da6ac000 <_end+1a387afc/20681b5c> >>esp; c6daff38 <_end+6a8ba34/20681b5c> Trace; e09dbd27 <[i2c-core].text.end+c98/cf1> Trace; c0160edf <proc_file_read+bf/1c0> Trace; c013b563 <sys_read+a3/140> Trace; c010746f <system_call+33/38> Code; e09d9af3 <[i2c-core]read_bus_i2c+63/e0> 00000000 <_EIP>: Code; e09d9af3 <[i2c-core]read_bus_i2c+63/e0> <===== 0: 8b 50 28 mov 0x28(%eax),%edx <===== Code; e09d9af6 <[i2c-core]read_bus_i2c+66/e0> 3: 85 d2 test %edx,%edx Code; e09d9af8 <[i2c-core]read_bus_i2c+68/e0> 5: 74 56 je 5d <_EIP+0x5d> Code; e09d9afa <[i2c-core]read_bus_i2c+6a/e0> 7: 8b 40 24 mov 0x24(%eax),%eax Code; e09d9afd <[i2c-core]read_bus_i2c+6d/e0> a: 85 c0 test %eax,%eax Code; e09d9aff <[i2c-core]read_bus_i2c+6f/e0> c: 74 41 je 4f <_EIP+0x4f> Code; e09d9b01 <[i2c-core]read_bus_i2c+71/e0> e: c7 44 24 04 2f bd 00 movl $0xbd2f,0x4(%esp,1) Code; e09d9b08 <[i2c-core]read_bus_i2c+78/e0> 15: 00
Created attachment 23573 [details] Kernel config of the system. Here you go.
It appears that this function is defined in the i2c package, but not in the kernel i2c driver. It appears that upgrading the kernel overwrites the i2c modules, and that there is a lot of horrible interdependency and clobbering going on. This explains why the i2c modules in the modules tree weren't the ones I thought they were, but it doesn't explain the _original_ oopses. There should be some way of forcing a rebuild of stuff that lives in /lib/modules when a make modules is executed, especially if it's stuff that clobbers bits of kernel. This is generally bad.
Yes, you are supposed to have kernel I2C support disabled, and only to have the APIs there.
Did disabling i2c support in the kernel, then emerging lm_sensors take care of things?
Long and forgotten. Closing once more.
