Most recent kernel where this bug did not occur: 2.6.15.x Distribution: Gentoo, with vanilla kernel Hardware Environment: Powerbook5,2 1.25Ghz (1st-gen Albook 15'' ADB keyboard) Software Environment: runlevel 1 console Problem Description: keywest I2C bus driver prints IRQ errors to kernel log when accessed by user-space software Steps to reproduce: (1) boot into 2.6.16.x kernel (all 2.6.16.x affected) (2) load i2c modules if applicable not compiled-in (i2c-dev, i2c-powermac, etc.) (3) scan all /dev/i2c-X with initialization of pbbuttonsd, looking for ambient light sensors and keyboard backlight control (4) access of keywest i2c devices produces kernel error messages. sample messages: KW: wrong state. Got KW_I2C_IRQ_ADDR, state: state_stop (isr: 02) KW: wrong state. Got KW_I2C_IRQ_ADDR, state: state_stop (isr: 02) KW: wrong state. Got KW_I2C_IRQ_STOP, state: state_read (isr: 04) Diagnosis: - first time for keywest failure on this system since near 2.6.9 - identical results if entire I2C subsystem as modules or all compiled-in - source: arch/powerpc/platforms/powermac/low_i2c.c - probably a bug in Ben's driver rewrite of Keywest into low-level code - other I2C code in kernel: ATI Radeon framebuffer, laptop thermal (?)
Created attachment 7865 [details] Config of kernel used for diagnostics I don't actually use this exact kernel config for anything but testing of this issue.
Created attachment 7866 [details] kernel logs of keywest failure some bootup and service init logs, including pbbuttonsd one boot with vanilla, i2c debugging on one boot with custom (but no i2c patching), i2c debugging off
Additional notes: - respective i2c hardware works with Mac OS X - respective i2c hardware works with 2.6.13.x to 2.6.15.x, any version of pbbuttonsd - system kernel headers (for glibc, etc) are linux-2.6.11 - pbbuttonsd uses its own i2c-dev.h header, could be mutual fault
Must be a problem with the low level i2c getting into some wrong state when a device doesn't reply... I'll try to find out when I find 5 minutes, in the meantime, you are welcome to compare the old i2c-keywest code with the implementation now in arch/powerpc/platforms/powermac/low_i2c.c ...
Benjamin, what is the state of powermac/low_i2c.c with regards to i2c-core? The header comment suggests that you have your own i2c implementation, but if your bus is visible through i2c-dev, this means that you have somehow registered with i2c-core. Please explain.
low_i2c is my own low level i2c interface, mostly bcs i2c core one isn't suitable for some of my needs by low level code. drivers/i2c/busses/i2c-powermac "exposes" all the busses detected by that low level interface to i2c core for higher level drivers or userland.
Created attachment 7868 [details] kernel logs of old keywest success a boot log, running pbbuttonsd, etc., on vanilla 2.6.15.0 sorry, no I2C debugging enabled for this log. will have to recompile a new image at a later date
Created attachment 7869 [details] Config of kernel with old keywest success (2.6.15.0)
Only notable differences betwen 2.6.15 adn 2.6.16 bootup and execution of pbbuttonsd (without I2C debug enabled): - 2.6.16 causes said kernel error messages - different number of identified bus channels at bootup, with different ordering of /dev/ entries loading 2.6.15.0: Found KeyWest i2c on "uni-n", 2 channels, stepping: 4 bits Found KeyWest i2c on "mac-io", 1 channel, stepping: 4 bits ... i2c /dev entries driver 2.6.16.4: i2c /dev entries driver PowerMac i2c bus pmu 2 registered PowerMac i2c bus pmu 1 registered PowerMac i2c bus mac-io 0 registered PowerMac i2c bus uni-n 1 registered PowerMac i2c bus uni-n 0 registered
Benjamin, Any diagnoses / patch trials; just ask. However, as my production (only) laptop, I'll have a long latency (maybe days) in recompiling and testing kernels. I miss my glowing keyboard enough to have diagnosed it through the night. Regards.
Created attachment 7876 [details] Rework kw low i2c to better match what was done before Please let me know if that patch helps
Response to Comment #11: Yes, the patch seems to bring the I2C behavior back to normal. Tested vanilla 2.6.16.4 and heavily patched variant also. The Albook sensors/backlight talk with pbbuttonsd, and no error messages, with or without I2C debugging on. No issues with hardware suspend/resume (but doubt this the driver could affect that anyway).
Just a note: the I2C appears to work fine with 2.6.17-rc6 vanilla.
The patch from this bug was included in kernel 2.6.17.