Openmoko Bug #2180: stable-tracking: 'rxserr' UART messages
Openmoko Public Trac
bugs at docs.openmoko.org
Thu Jan 29 11:22:07 CET 2009
#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
More information about the openmoko-kernel
mailing list