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 #2217: Noise screen of death: Freerunner
looses SDIO connection (Openmoko Public Trac)
2. Re: Openmoko Bug #2180: stable-tracking: 'rxserr' UART
messages (Openmoko Public Trac)
3. Openmoko Bug #2223: gsm0710muxd loosing packets?
(Openmoko Public Trac)
4. Re: Openmoko Bug #2180: stable-tracking: 'rxserr' UART
messages (Openmoko Public Trac)
5. Re: Openmoko Bug #2180: stable-tracking: 'rxserr' UART
messages (Openmoko Public Trac)
--- Begin Message ---
#2217: Noise screen of death: Freerunner looses SDIO connection
-----------------------------+----------------------------------------------
Reporter: xbaldauf | Owner: openmoko-kernel
Type: defect | Status: new
Priority: normal | Milestone:
Component: System Software | Version:
Severity: major | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-----------------------------+----------------------------------------------
Comment(by andy):
I added a patch
http://git.openmoko.org/?p=kernel.git;a=commitdiff;h=302131b55d1f922fe73b238202795a4cd4537ad3
that allows us to start debugging this by appending
glamo3362.slow_memory=1
on your kernel commandline.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2217#comment:2>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2180: stable-tracking: 'rxserr' UART messages
-----------------------------+----------------------------------------------
Reporter: laforge | Owner: openmoko-kernel
Type: defect | Status: new
Priority: high | Milestone: FSO
Component: System Software | Version:
Severity: major | Keywords: gps s3x24xx_serial rxerr
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-----------------------------+----------------------------------------------
Comment(by shoragan):
Is there a way to debug the interrupt latencies?
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2180#comment:4>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2223: gsm0710muxd loosing packets?
------------------------+---------------------------------------------------
Reporter: kapiteined | Owner: julian_chu
Type: defect | Status: new
Priority: normal | Milestone: Om2008.12
Component: Distro | Version: unspecified
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
------------------------+---------------------------------------------------
I use gsm0710muxd to make a GPRS connection and start a ssh tunnel to my
home network.
if i start sending larger packets (ping -s 1400) the connection comes to a
halt and no packets are forwarded any more.
If i stop gsm0710muxd and use /dev/ttySAC0 everything works fine. it seems
like gsm0710muxd is loosing packets and my ssh tunnel becomes detached.
the gprs connection itself stays intact.
As you can see from the ping log, the response times are increasing and
then comes to a halt.
I read somewhere that a sillent buffer overflow was detected, so that
might be my problem too. but i could not find a bug about that though.
I did run gsm0710muxd with the -v option and attached the log.
At 11:09:32 i stopped the connection manually.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2223>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2180: stable-tracking: 'rxserr' UART messages
-----------------------------+----------------------------------------------
Reporter: laforge | Owner: openmoko-kernel
Type: defect | Status: new
Priority: high | Milestone: FSO
Component: System Software | Version:
Severity: major | Keywords: gps s3x24xx_serial rxerr
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-----------------------------+----------------------------------------------
Comment(by andy):
I was thinking about this on and off the last days.
Harald, what drivers do you have up on your non-GTAxx device? I guess we
can rule out Glamo for a start, so Glamo MMC. What else can we know that
it isn't then? We can also rule out SDIO and AR6000 WLAN? You probably
don't have FIQ / HDQ up? USB / Ethernet over USB is up?
I had two ideas about mapping latency, first was to set all IRQs as FIQ,
log the request time immediately, and if necessary do some magic about
also having the IRQ dealt with as normal IRQ. In the normal IRQ, we add
code to also log the time it was finally serviced. This would give 100%
view of genuine latencies incorporating priority blocking relationship.
Since that's a whole project in itself, I had another idea to make some
macros and apply them to ISR entry and exit, maybe at platform, to simply
log IRQ duration without capturing the relationship between that and other
interrupts.
But neither are simple as the ARM920T does not have a CPU cycle counter
register, so we need to study timers and debug that, etc.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2180#comment:5>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2180: stable-tracking: 'rxserr' UART messages
-----------------------------+----------------------------------------------
Reporter: laforge | Owner: openmoko-kernel
Type: defect | Status: new
Priority: high | Milestone: FSO
Component: System Software | Version:
Severity: major | Keywords: gps s3x24xx_serial rxerr
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-----------------------------+----------------------------------------------
Comment(by werner):
Here's a patch for measuring the time during which interrupts are
globally disabled:
http://svn.openmoko.org/developers/werner/wlan-spi/patches-tracking/find-
irq-blockers.patch
Another source of interrupt latency can be the time during which a
specific interrupt is disabled. The execution time of an interrupt
also (indirectly) shows up in this, but it's better to measure it
directly.
- Werner
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2180#comment:6>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
_______________________________________________
buglog mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/buglog
