Running this on a slightly older version of 4.0.0-rc5 (compiled Mon Mar 23), so it might already be fixed (i did see a few changes in this department, but haven't compiled that kernel yet).
It doesn't happen very often, only happened 3 times since i first ran this kernel, probably something like every 10 boots.
It happens just after/during it modprobing all the modules from disk.
[ 10.265138] alias name [ 10.267600] omapfb omapfb: not all displays running (0 of 2) [ 10.274521] omapfb omapfb: failed to setup omapfb [ OK ] Started Load/Save Random Seed.[ 10.280661] platform omapfb: Driver omapfb requests probe deferral
Starting LSB: Raise network interfaces.... [ 10.330634] tca8418_keypad 1-0034: tca8418_write_byte failed, reg: 1, val: 25, error: -121 [ 10.342211] bq27x00-battery 1-0055: error reading voltage [ 10.352277] power_supply bq27425-0: driver failed to report `voltage_now' property: -121 [ 10.370867] bq27x00-battery 1-0055: error reading voltage [ 10.377121] power_supply bq27425-0: driver failed to report `voltage_now' property: -121 [ 10.393025] bq27x00-battery 1-0055: error reading voltage [ 10.402089] bq27x00-battery 1-0055: support ver. 1.2.0 enabled [ 10.403059] power_supply bq27425-0: driver failed to report `voltage_now' property: -121 [ 10.406652] bq27x00-battery 1-0055: error reading voltage [ 10.406658] power_supply bq27425-0: driver failed to report `voltage_now' property: -121
and keeps repeating those endlessly. I've got the full output in case you want to take a look at it. Meanwhile, i'll compile the updated 4.0.0-rc5 and see if it happens on that.
Hi aTc,
Am 03.04.2015 um 22:35 schrieb aTc atc@k-n-p.org:
Running this on a slightly older version of 4.0.0-rc5 (compiled Mon Mar 23), so it might already be fixed (i did see a few changes in this department, but haven't compiled that kernel yet).
It doesn't happen very often, only happened 3 times since i first ran this kernel, probably something like every 10 boots.
It happens just after/during it modprobing all the modules from disk.
[ 10.265138] alias name [ 10.267600] omapfb omapfb: not all displays running (0 of 2) [ 10.274521] omapfb omapfb: failed to setup omapfb [ OK ] Started Load/Save Random Seed.[ 10.280661] platform omapfb: Driver omapfb requests probe deferral
Starting LSB: Raise network interfaces....
[ 10.330634] tca8418_keypad 1-0034: tca8418_write_byte failed, reg: 1, val: 25, error: -121
That is known if the Pyra main board is not connected. It tries to contact the tca8418 but fails.
[ 10.342211] bq27x00-battery 1-0055: error reading voltage [ 10.352277] power_supply bq27425-0: driver failed to report `voltage_now' property: -121 [ 10.370867] bq27x00-battery 1-0055: error reading voltage [ 10.377121] power_supply bq27425-0: driver failed to report `voltage_now' property: -121 [ 10.393025] bq27x00-battery 1-0055: error reading voltage [ 10.402089] bq27x00-battery 1-0055: support ver. 1.2.0 enabled [ 10.403059] power_supply bq27425-0: driver failed to report `voltage_now' property: -121 [ 10.406652] bq27x00-battery 1-0055: error reading voltage [ 10.406658] power_supply bq27425-0: driver failed to report `voltage_now’ property: -121
Basically the same. But maybe the I2C probe function of the bq27x00 is not able to really check for chip presence. So it might try again.
Or it creates its /sys/class/power_supply node and some user space tool repeatedly tries to read the battery voltage (but at 10 seconds after boot it is too early).
and keeps repeating those endlessly. I've got the full output in case you want to take a look at it. Meanwhile, i’ll compile the updated 4.0.0-rc5 and see if it happens on that.
Well, I have not changed anything in this driver - just added a DT node so that we did not load that driver it before.
Maybe we can check why the bq27x00 driver successfully probes even if the chip is not connected and I2C appears to time-out. Sometimes driver maintainers did forget to correctly handle some -EPROBE_DEFER for such corner cases.
This will also be the case in the final Pyra if we operate it without battery (the bq27421 is powered by the battery and not from USB or VSYS).
BR, Nikolaus
On 04/04/2015 01:34 PM, Dr. H. Nikolaus Schaller wrote:
Hi aTc,
Maybe we can check why the bq27x00 driver successfully probes even if the chip is not connected and I2C appears to time-out. Sometimes driver maintainers did forget to correctly handle some -EPROBE_DEFER for such corner cases.
This will also be the case in the final Pyra if we operate it without battery (the bq27421 is powered by the battery and not from USB or VSYS).
Here's the full output:
normal boot: http://next.openpandora.org/omap5/a/bootn.txt failed boot: http://next.openpandora.org/omap5/a/bootf.txt
Hi,
Am 04.04.2015 um 19:44 schrieb aTc atc@k-n-p.org:
On 04/04/2015 01:34 PM, Dr. H. Nikolaus Schaller wrote:
Hi aTc,
Maybe we can check why the bq27x00 driver successfully probes even if the chip is not connected and I2C appears to time-out. Sometimes driver maintainers did forget to correctly handle some -EPROBE_DEFER for such corner cases.
This will also be the case in the final Pyra if we operate it without battery (the bq27421 is powered by the battery and not from USB or VSYS).
Here's the full output:
normal boot: http://next.openpandora.org/omap5/a/bootn.txt failed boot: http://next.openpandora.org/omap5/a/bootf.txt
Thanks!
Yes, it looks like I2C and the bq27xxx driver did run away.
I think probing is not correctly handling the case of a non-responding chip:
http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=drivers/power/bq27x00_...
calls
bq27x00_powersupply_init()
which calls
http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=drivers/power/bq27x00_...
bq27x00_update()
But bq27x00_update() does not return a communication error. It is simply ignored in
http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=drivers/power/bq27x00_...
Therefore probing can’t detect that the chip is not responding and therefore we always see the /sys/class/power_supply entry (even if the chip is not found).
So what I think should be extended is an error path from
bq27x00_read
to make the probe fail.
Now the question is why the driver sometimes repeats. This might have to do with uninitialized data. If bq27x00_read fails, it leaves the struct bq27x00_device_info *di in a random state which might make the power_supply framework retry.
But all this might be more or less intended behaviour so that a chip appearing later on the I2C is found as soon as it answers. This would make it necessary that the driver repeatedly tries to contact the chip. But even then it should handle this correctly in all situations.
Would you find some time to look into that and submit a patch for us for testing and to LKML for upstreaming?
BR, Nikolaus
Am 04.04.2015 um 20:32 schrieb Dr. H. Nikolaus Schaller hns@goldelico.com:
Hi,
Am 04.04.2015 um 19:44 schrieb aTc atc@k-n-p.org:
On 04/04/2015 01:34 PM, Dr. H. Nikolaus Schaller wrote:
Hi aTc,
Maybe we can check why the bq27x00 driver successfully probes even if the chip is not connected and I2C appears to time-out. Sometimes driver maintainers did forget to correctly handle some -EPROBE_DEFER for such corner cases.
This will also be the case in the final Pyra if we operate it without battery (the bq27421 is powered by the battery and not from USB or VSYS).
Here's the full output:
normal boot: http://next.openpandora.org/omap5/a/bootn.txt failed boot: http://next.openpandora.org/omap5/a/bootf.txt
Thanks!
Yes, it looks like I2C and the bq27xxx driver did run away.
I think probing is not correctly handling the case of a non-responding chip:
http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=drivers/power/bq27x00_...
calls
bq27x00_powersupply_init()
which calls
http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=drivers/power/bq27x00_...
bq27x00_update()
But bq27x00_update() does not return a communication error. It is simply ignored in
http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=drivers/power/bq27x00_...
Therefore probing can’t detect that the chip is not responding and therefore we always see the /sys/class/power_supply entry (even if the chip is not found).
So what I think should be extended is an error path from
bq27x00_read
to make the probe fail.
Now the question is why the driver sometimes repeats. This might have to do with uninitialized data. If bq27x00_read fails, it leaves the struct bq27x00_device_info *di in a random state which might make the power_supply framework retry.
But all this might be more or less intended behaviour so that a chip appearing later on the I2C is found as soon as it answers. This would make it necessary that the driver repeatedly tries to contact the chip. But even then it should handle this correctly in all situations.
Would you find some time to look into that and submit a patch for us for testing and to LKML for upstreaming?
A simple fix could be to change Line 448:
- if ((cache.flags & 0xff) == 0xff) + if (cache.flags < 0 || (cache.flags & 0xff) == 0xff)
If that works, then it is a bug in an improvement done by us (Marek).
If that does not improve anything, please try line 500:
- if (di->cache.capacity != cache.capacity) + if (cache.flags >= 0 && di->cache.capacity != cache.capacity)
That are at least two areas where I think an uninitialized value might have an influence (the cache struct on stack is not initialized completely: line 441).
BR, Nikolaus
On 04/04/2015 08:45 PM, Dr. H. Nikolaus Schaller wrote:
Would you find some time to look into that and submit a patch for us for testing and to LKML for upstreaming?
A simple fix could be to change Line 448:
- if ((cache.flags & 0xff) == 0xff)
- if (cache.flags < 0 || (cache.flags & 0xff) == 0xff)
If that works, then it is a bug in an improvement done by us (Marek).
Added it, still failed about the 10th reboot. Log seems to be slightly different this time : http://next.openpandora.org/omap5/a/bootf2.txt
If that does not improve anything, please try line 500:
- if (di->cache.capacity != cache.capacity)
- if (cache.flags >= 0 && di->cache.capacity != cache.capacity)
I'll give this one a try then.