Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#11041 closed defect (fixed)

XO-1.75 accelerometer may hang

Reported by: Quozl Owned by: saadia
Priority: normal Milestone: 1.75-software
Component: kernel Version: Development build as of this date
Keywords: XO-1.75, accelerometer Cc:
Blocked By: Blocking:
Deployments affected: Action Needed: no action
Verified: no

Description

Sometimes the accelerometer may hang. The triggering conditions have not been determined.

When it hangs, an open of the device stalls the process in D state and several lines appear in dmesg:

i2c i2c-5: i2c_pxa: timeout waiting for bus free

which are followed by one line of

lis3: power on failure

and the cycle repeats.

The symptom was cleared by removing power and main battery from the laptop.

(The power on failure message is from lis3_i2c_init. The device is connected directly to the SoC, so only the device should be responsible for bus not free.)

os19 runin-accelerometer

Attachments (2)

k1.log (43.0 KB) - added by Quozl 3 years ago.
kernel log from runin test
k2.log (37.9 KB) - added by Quozl 3 years ago.
kernel log from second runin test

Download all attachments as: .zip

Change History (15)

Changed 3 years ago by Quozl

kernel log from runin test

Changed 3 years ago by Quozl

kernel log from second runin test

comment:1 Changed 3 years ago by Quozl

Perhaps runin should declare a failure if the accelerometer hangs?

comment:2 Changed 3 years ago by Quozl

Seen in a prebuild runin log, may relate to #10882.

comment:3 Changed 3 years ago by wad

  • Action Needed changed from never set to code
  • Component changed from not assigned to kernel
  • Keywords XO-1.75 accelerometer added
  • Milestone changed from 1.75-firmware to 1.75-software
  • Owner set to buytenh
  • Version changed from not specified to Development build as of this date

This is definitely the same issue as #10882.

We need to ensure that the I2C bus for the accelerometer runs at around 25 KHz on A3/B1 motherboards. We will fix the hardware to allow full speed operation starting with C1.

The value written to the LSR field of the TWSI_LCR register on the I2C bus talking to the accelerometer should be 0X1FF, not the default 0x7E. This has already been fixed in OFW, starting with Q4B05, but the Linux driver might also need to be patched.

comment:4 Changed 3 years ago by wad

  • Owner changed from buytenh to saadia

comment:5 Changed 3 years ago by saadia

  • Action Needed changed from code to test in build

A fix to Linux has been built off of the os19 branch. It can be found in http://dev.laptop.org/~saadia/zImage-saadia.071911

This build writes 0x1ff to the LCR register for TWSI6.

comment:6 Changed 3 years ago by Quozl

  • Summary changed from XO-1.75 A3 #4 accelerometer may hang to XO-1.75 accelerometer may hang

Tested zImage-saadia.071911 on an A3, the user space read rate falls from 960 Hz to 38 Hz, consecutive samples no longer occur (because the communicate rate is below sensor sample rate), and the runin accelerometer test continues to operate at the slower rate.

(changed ticket summary)

comment:7 follow-up: Changed 3 years ago by wad

Hmm. Interesting how dropping the bit rate to 25% produced a drop in access frequency to 5%. Are we sure something else didn't change as well ?

comment:8 in reply to: ↑ 7 Changed 3 years ago by Quozl

Replying to wad:

Hmm. Interesting how dropping the bit rate to 25% produced a drop in access frequency to 5%. Are we sure something else didn't change as well ?

I'm not concerned; the range change doesn't seem wrong. I've not seen the patch yet, and would like to. But my tests of the bit rate before the patch, in conjunction with other system loads, suggested that the bit rate was limited by the CPU or memory, not the bus. Now, with a slower bus, the bottleneck has merely moved to the bus.

My test of read rate is repeated reads of the sysfs position file, effectively a test of calling lis3lv02d_get_xyz() in the driver, and this looks like it causes a read of six bytes from the device register address 0x28 over i2c. So there's a multiplier.

comment:9 Changed 3 years ago by Quozl

Error in my read rate measurement; rates above were overstated by 50%. Now retested with os21:

kernelposition read rate
vmlinuz-2.6.39_xo1.75-20110715.0319.olpc.f426c86 620 Hz
zImage-saadia.071911 25 Hz

It is the freq function in the test that measures the read rate.

comment:10 Changed 3 years ago by Quozl

  • Action Needed changed from test in build to no action
  • Resolution set to fixed
  • Status changed from new to closed

os36 kernel contains fix, works for me.

comment:11 Changed 3 years ago by Quozl

still occurs infrequently, C1 should contain pullups.

comment:12 Changed 3 years ago by Quozl

Did 44 runin cycles on two units, this problem happened in three of the cycles, and was not detected by runin-accelerometer.

comment:13 Changed 3 years ago by Quozl

olpc-runin-tests-0.14.0 has an additional fix.

Note: See TracTickets for help on using tickets.