Send buglog mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.openmoko.org/mailman/listinfo/buglog
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of buglog digest..."
Today's Topics:
1. Re: Openmoko Bug #2145: Debian: Reading of accelerometers
broken (Openmoko Public Trac)
2. Re: Openmoko Bug #2185: AUX button makes interrupt storm
(Openmoko Public Trac)
3. Re: Openmoko Bug #2145: Debian: Reading of accelerometers
broken (Openmoko Public Trac)
4. Re: Openmoko Bug #2145: Debian: Reading of accelerometers
broken (Openmoko Public Trac)
5. Re: Openmoko Bug #2145: Debian: Reading of accelerometers
broken (Openmoko Public Trac)
6. Re: Openmoko Bug #2145: Debian: Reading of accelerometers
broken (Openmoko Public Trac)
7. Re: Openmoko Bug #2145: Debian: Reading of accelerometers
broken (Openmoko Public Trac)
--- Begin Message ---
#2145: Debian: Reading of accelerometers broken
-------------------------------------+--------------------------------------
Reporter: Defiant | Owner: hardware
Type: defect | Status: closed
Priority: normal | Milestone:
Component: hardware | Version: unspecified
Severity: normal | Resolution: fixed
Keywords: debian event2 event3 | Haspatch: 0
Blockedby: | Estimated:
Patchreview: | Blocking:
Reproducible: always |
-------------------------------------+--------------------------------------
Comment(by Johannes):
uImage-moredrivers-GTA02_andy-tracking_e142549d884a17b8.bin
18-Dec-2008 20:22 2.4M
has the problem, so using ...andy-tracking is NOT the solution per se.
Is there another kernel from 18th November as mentioned by Defiant? I
would try that too, if it were available.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2145#comment:13>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2185: AUX button makes interrupt storm
---------------------+------------------------------------------------------
Reporter: vnevoa | Owner: openmoko-devel
Type: defect | Status: new
Priority: normal | Milestone:
Component: unknown | Version: Om2008.9-dev
Severity: normal | Keywords: AUX button interrupts
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible: always
---------------------+------------------------------------------------------
Comment(by arhuaco):
Replying to [comment:10 vnevoa]:
> Oops, sorry, I only looked at the /proc/interrupts output.
Yes, you will still get the IRQ storm there... the idea is to filter it.
> Now I'm looking at the kernel messages.
>
> When I press the AUX button, I get only 1 message:
> "IRQ press:0"
> When I release the button, I get 2 messages:
> "IRQ press:0"
> "IRQ press:1"
Ok. This device is asking for a state. I will program something better
now... I think it is not hard to solve this.
In the mean time it will help us a lot if you test another image. It will
print
every IRQ. I didn't make 2 images but one image and 2 modules. You will
get a warning
when you remove the modules, I haven't researched that issue yet (it is
not fatal but it needs to be fixed).
You will need to disable suspend in your distro (using the GUI I guess).
This time we want to know the timings of the interrupts in order to tune
the filter. I'm sending 2 modules. One of them has the pulldown, let's see
if it makes a noticeable difference for you.
The idea is that for each module, you try this:
1) insert module.
2) press and release the button fast
3) wait about 1 second
please repeat 2 and 3 about 10 times.
4) remove the module
5) Do a "dmesg > module1" or "dmesg > module2"....
Then send us the dumps...
Please download from: http://wiki.emqbit.com/tmp/test2.tar
MD5SUMS:
840672c60dbd29cb98b58653aac75d6f module1.ko
224406385ed557181a6da4bfca152a49 module2.ko
0d4bec316e8c70d6bb9f561239ea0fcc uImage-moredrivers-GTA02_andy-
tracking_1c16df7be9a83288.bin
> Now I see the Power button also behaves strangely, I think.
> I press Power, and I get 3 kernel messages:
> "INT1=0x80 INT2=0x02 INT3=0x00 INT4=0x00 INT5=0x00"
> "INT1=0x00 INT2=0x00 INT3=0x00 INT4=0x00 INT5=0x00"
> "INT1=0x00 INT2=0x00 INT3=0x00 INT4=0x00 INT5=0x00"
> I release it, and I get another 3:
> "INT1=0x00 INT2=0x01 INT3=0x00 INT4=0x00 INT5=0x00"
> "INT1=0x00 INT2=0x00 INT3=0x00 INT4=0x00 INT5=0x00"
> "INT1=0x80 INT2=0x00 INT3=0x00 INT4=0x00 INT5=0x00"
> Is this supposed to happen?
I do not know... I will focus on the problem of the ticket first...
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2185#comment:11>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2145: Debian: Reading of accelerometers broken
-------------------------------------+--------------------------------------
Reporter: Defiant | Owner: hardware
Type: defect | Status: closed
Priority: normal | Milestone:
Component: hardware | Version: unspecified
Severity: normal | Resolution: fixed
Keywords: debian event2 event3 | Haspatch: 0
Blockedby: | Estimated:
Patchreview: | Blocking:
Reproducible: always |
-------------------------------------+--------------------------------------
Comment(by Johannes):
Not sure if this helps:
printing interrupt counts for lis302dl from /proc/interrupts does not
change with movement of device but with reading from /dev/input/event3.
Running the script below it does not matter if the device is laying on the
table or shaken like hell during the 10s pause, interrupt counts are
increasing at the same slow rate of 2 counts per 10s.
debian-gta02:~# while [ 1 == 1 ] ; do dd if=/dev/input/event3 bs=16
count=6 > /dev/null ; cat /proc/interrupts |grep lis302dl ; sleep 10 ;
done
6+0 records in
6+0 records out
96 bytes (96 B) copied, 0.030005 s, 3.2 kB/s
16: 521 s3c-ext0 lis302dl
60: 19262 s3c-ext lis302dl
6+0 records in
6+0 records out
96 bytes (96 B) copied, 0.036205 s, 2.7 kB/s
16: 521 s3c-ext0 lis302dl
60: 19264 s3c-ext lis302dl
6+0 records in
6+0 records out
96 bytes (96 B) copied, 0.029541 s, 3.2 kB/s
16: 521 s3c-ext0 lis302dl
60: 19266 s3c-ext lis302dl
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2145#comment:14>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2145: Debian: Reading of accelerometers broken
-------------------------------------+--------------------------------------
Reporter: Defiant | Owner: hardware
Type: defect | Status: closed
Priority: normal | Milestone:
Component: hardware | Version: unspecified
Severity: normal | Resolution: fixed
Keywords: debian event2 event3 | Haspatch: 0
Blockedby: | Estimated:
Patchreview: | Blocking:
Reproducible: always |
-------------------------------------+--------------------------------------
Comment(by DigitalPioneer):
Using andy-tracking: uImage-moredrivers-GTA02_andy-
tracking_e142549d884a17b8.bin
Getting a steady hexdump from both accelerometers regardless of whether
the phone is moving or not. :)
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2145#comment:15>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2145: Debian: Reading of accelerometers broken
-------------------------------------+--------------------------------------
Reporter: Defiant | Owner: hardware
Type: defect | Status: closed
Priority: normal | Milestone:
Component: hardware | Version: unspecified
Severity: normal | Resolution: fixed
Keywords: debian event2 event3 | Haspatch: 0
Blockedby: | Estimated:
Patchreview: | Blocking:
Reproducible: always |
-------------------------------------+--------------------------------------
Comment(by SimonKagstrom):
There is a dump sysfs entry, that should give all registers of the device.
I had a debug patch a while which offered more fine-granular access to the
registers, but I don't think that's really needed in this case. It could,
as always, be good to check the values of threshold etc.
I don't think there is any changes to the accelerometer code the last
couple of weeks, so it's strange if it suddenly broke now. However, is
this really the same issue? The original bug report suggest that the
device produces values in the opposite way than it's supposed to -
producing data while being still and not when being shaken.
The new reports seem to be a general low amount of traffic. Do the
ruby/python scripts on
http://wiki.openmoko.org/wiki/Accelerometer_data_retrieval
seem to output reasonable data at least?
// Simon
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2145#comment:16>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2145: Debian: Reading of accelerometers broken
-------------------------------------+--------------------------------------
Reporter: Defiant | Owner: hardware
Type: defect | Status: closed
Priority: normal | Milestone:
Component: hardware | Version: unspecified
Severity: normal | Resolution: fixed
Keywords: debian event2 event3 | Haspatch: 0
Blockedby: | Estimated:
Patchreview: | Blocking:
Reproducible: always |
-------------------------------------+--------------------------------------
Comment(by DigitalPioneer):
For me, I only got data when the phone was still, from hexdump or they
perl script on that page.
The andy-tracking kernel fixed the issue, but when I rotated the screen,
it screwed something up and display went white with lines of yellow, gray,
black.. across it. Not even x restart fixed it, had to reboot. I changed
kernels again.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2145#comment:17>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2145: Debian: Reading of accelerometers broken
-------------------------------------+--------------------------------------
Reporter: Defiant | Owner: hardware
Type: defect | Status: closed
Priority: normal | Milestone:
Component: hardware | Version: unspecified
Severity: normal | Resolution: fixed
Keywords: debian event2 event3 | Haspatch: 0
Blockedby: | Estimated:
Patchreview: | Blocking:
Reproducible: always |
-------------------------------------+--------------------------------------
Comment(by Johannes):
Running the ruby script from Accelerometer_data_retrieval produces this
output (device is not moved, laying on the table).
{{{
90 -36 954 958
90 -36 972 976
90 -36 954 958
90 -36 954 958
90 -36 954 958
90 -36 954 958
90 -36 972 976
}}}
Interrupt counts measured at the same time is giving this.
{{{
debian-gta02:~# while [ 1 == 1 ] ; do cat /proc/interrupts |grep lis302dl
; sleep 10 ; done
16: 521 s3c-ext0 lis302dl
60: 38414 s3c-ext lis302dl
16: 521 s3c-ext0 lis302dl
60: 39456 s3c-ext lis302dl
16: 521 s3c-ext0 lis302dl
60: 40503 s3c-ext lis302dl
}}}
So constanly reading from /dev/input/event3 produces approx. 100
interrupts per 1s.
Also I modified the ruby script to select before reading, this does not
change the behaviour at all. Again this looks like reading from
/dev/input/event3 is triggering the interrupt.
{{{
...
File.open("/dev/input/event3") do |f|
while true
select([f],nil,nil,nil)
event = f.read(16).unpack("llSSl")
...
}}}
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2145#comment:18>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
_______________________________________________
buglog mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/buglog
