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 #2217: Noise screen of death: Freerunner
looses SDIO connection (Openmoko Public Trac)
3. Re: Openmoko Bug #2217: Noise screen of death: Freerunner
looses SDIO connection (Openmoko Public Trac)
4. Openmoko Bug #2229: GSM was working fine for months, suddenly
will not register using any GSM stack (Openmoko Public Trac)
5. Re: Openmoko Bug #2180: stable-tracking: 'rxserr' UART
messages (Openmoko Public Trac)
6. 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 xbaldauf):
I've been running
http://git.openmoko.org/?p=kernel.git;a=commit;h=9029dff1f370018665a6e2999632a34fd0518f4d
( Thu, 5 Feb 2009 17:01:56 +0000 (17:01 +0000) ) with kernel parameter
"glamo3362.slow_memory=1" now for about 24 hours and I have experienced 3
crashes|lockups (all during screen blank, so I do not know the cause or
whether these had to do something to do with this bug), but no crash of
the type "Noise screen of death:". Judging from the frequency of the bug
before, I think your workaround works. :-)
I'll try to change the setting from time to time to try out the other
clock and wait state settings to find an optimum setting.
I did not notice any speed difference, is there any howto or document
describing which speed should differ with respect to the waitstate number
and frequency used? Maybe there is even a kind of benchmark program? (E.g.
Is 50 MHz, 0 waitstates faster than 90 MHz, 1 waitstate?)
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2217#comment:9>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- 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 think the workaround probably works fine... I've given you the wrong
kernel commandline though, it's
glamo_core.slow_memory=1
as someone pointed out to me.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2217#comment:10>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- 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 xbaldauf):
Well, why does it (apparently) work then if I have not given the correct
kernel parameter?
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2217#comment:11>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2229: GSM was working fine for months, suddenly will not register using any GSM
stack
----------------------+-----------------------------------------------------
Reporter: danek2 | Owner: hardware
Type: defect | Status: new
Priority: normal | Milestone:
Component: hardware | Version: GTA02v5
Severity: normal | Keywords: calypso, gsm, registration
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible: always
----------------------+-----------------------------------------------------
Disclaimer: I suspect this affects my handset only, as I haven't seen
similar reports on the forums or here. One person (BillK on the forums)
has a problem he believes is similar, although his phone does still work
on some distributions, whereas mine does not. I also don't know if his
phone ever worked when using gsm0710muxd. See bug 2215.
I started using Neo Freerunner as a daily phone (with much difficulty at
first) in August '08. I was very happy with it until one day in December
it suddenly stopped registering GSM. The phone was on, I had been making
some calls in 2008.12, and a few hours later, phone still on from before,
I tried dialing out and discovered that I wasn't registered. I used a
landline to make the call I needed to make, and discovered that people had
been trying to contact me for some time and were going straight to
voicemail. I rebooted my phone, as had become common practice by that
point, but still did not register. At the time, I assumed that perhaps I
was getting poor reception (I was working in an unfamiliar building), but
a colleague of mine who was at the same location with me at the time and
has the same GSM provider was able to use his phone normally. Later, when
I was outdoors I tried rebooting again, to no avail. I got to my office,
where I had an old GSM phone, and was able to put my SIM there so I could
use a phone for the rest of the day.
When I got home that night, I tried swapping SIMs. I tried three different
SIMs from two different carriers, all of which had previously worked with
the Freerunner. Then I tried reflashing images. After a couple of
reflashes failed to restore functionality, I put the Freerunner down.
I have not once been able to successfully register GSM since the day that
it mysteriously stopped working. Every once in a while when I get the time
to mess around with the phone, I try some more troubleshooting, but have
not had much time to devote to this. Nevertheless, I have tried many
different images, including 2007.2 (or 2008.4), 2008.8, 2008.9, 2008.12,
Qtopia 4.3 and 4.4, and FSO Milestones 3, 4, and 5. GSM was known to be
working with all of these images prior to the time that it stopped
working, with the exception of FSO Milestone 5, for the obvious reason
that it was not available before the phone stopped working. Not a single
one of them has worked since the phone stopped registering.
I have also tried using GSM manually, according to
http://wiki.openmoko.org/wiki/Manually_using_GSM - this also fails. I
attempted this on 2007.2/2008.4, since the other distributions don't talk
to GSM the same way. It hangs on "Connected." and never indicates
readiness for AT commands.
I know that the SIM card is visible to the system, because it can see my
saved contacts and SMS messages, and because when I set a SIM pin it
prompts me for the PIN, accepts the correct one, and rejects an incorrect
one.
The firmware has also been updated, though this has not changed anything.
It was running moko8 at the time that it suddenly stopped working. After
updating to moko10 no change was observed.
I also tried, at BillK's suggestion, writing different UART settings to
/dev/ttySAC0, but this never achieved anything, either. See
http://lists.openmoko.org/nabble.html#nabble-tt1649863
I don't know what to do anymore at this point, and suspect that my Calypso
has mysteriously died. The only thing I haven't erased and restored on the
phone yet is the NAND u-boot environment: this got corrupted some time
ago, and when I write a new u-boot environment to partition 2 (the
partition names are not visible to DFU-Util in my NAND u-boot until I
write a u-boot environment) it gets borked again when I next reboot. The
only way to boot the phone is to boot into NOR u-boot; otherwise I get a
garbled screen. However, I don't think this has anything to do with the
GSM registration problem, as the phone had been unbootable from NAND
u-boot for about six weeks before GSM stopped registering.
I am attaching three dumps from logread:
logdump.txt was taken from 2008.12 about a week after GSM stopped working.
logdumpwpin.txt was taken from the same setup, after setting a SIM PIN
using another phone.
logdumpfso5.txt was taken today using FSO Milestone 5.
To recap:
- GSM registration worked fine for about four months.
- It suddenly and mysteriously stopped one day and hasn't worked since.
- Three different SIMs which were known to work no longer work.
- It used to work with gsmd, qpe, and gsm0710muxd. It now works with none
of these.
- It was running moko8 at the time that it stopped working. Upgrading to
moko10 did not change the situation.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2229>
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 Sascha):
I'm running debian with kernel 2.6.29 stable
821e9fa664049b1e5e97a00f6eeed3b72b67c1ba on a GTA02v5 and I get lots of
these error messages for GPS and GSM.
For the attached syslog I've removed the trace in iblock.c (it doesn't
work for me) and
I've added the port number to the rxerr messages:
{{{
Feb 8 00:51:44 gta02 kernel: [ 293.080000] rxerr: port=1 ch=0x45,
rxs=0x00000001
...
Feb 8 00:52:02 gta02 kernel: [ 310.250000] rxerr: port=0 ch=0x7e,
rxs=0x00000001
Feb 8 00:52:02 gta02 /usr/sbin/gsm0710muxd[1598]:
gsm0710muxd.c:1168:gsm0710_advanced_buffer_get_frame(): Dropping frame:
FCS doesn't match
}}}
Oh, and hardware handshake is enabled:
{{{
$ stty -F /dev/ttySAC0 -a
speed 115200 baud; rows 0; columns 0; line = 0;
intr = <undef>; quit = <undef>; erase = ^?; kill = ^U; eof = ^D; eol =
<undef>;
eol2 = <undef>; swtch = <undef>; start = <undef>; stop = <undef>; susp =
<undef>;
rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon
-ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0
vt0 ff0
-isig -icanon iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop
-echoprt
echoctl echoke
}}}
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2180#comment:9>
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):
Thanks for the report and dumps Sascha.
434 Feb 8 00:53:16 gta02 kernel: [ 384.800000] rxerr: port=1
ch=0xb5, rxs=0x00000001
435 Feb 8 00:53:16 gta02 kernel: [ 384.845000] interrupts were
disabled for 596 us !
436 Feb 8 00:53:17 gta02 kernel: [ 385.300000] rxerr: port=1
ch=0xb5, rxs=0x00000001
437 Feb 8 00:53:17 gta02 kernel: [ 385.345000] rxerr: port=1
ch=0x00, rxs=0x00000001
438 Feb 8 00:53:21 gta02 kernel: [ 389.825000] interrupts were
disabled for 599 us !
439 Feb 8 00:53:26 gta02 kernel: [ 394.925000] rxerr: port=1
ch=0x7a, rxs=0x00000001
440 Feb 8 00:53:26 gta02 kernel: [ 394.935000] interrupts were
disabled for 593 us !
441 Feb 8 00:53:31 gta02 kernel: [ 399.970000] rxerr: port=1
ch=0x0d, rxs=0x00000001
442 Feb 8 00:53:31 gta02 kernel: [ 399.970000] interrupts were
disabled for 596 us !
443 Feb 8 00:53:36 gta02 kernel: [ 404.980000] rxerr: port=0
ch=0x7e, rxs=0x00000001
444 Feb 8 00:53:36 gta02 /usr/sbin/gsm0710muxd[1598]:
gsm0710muxd.c:1168:gsm0710_advanced_buffer_get_frame(): Dropping frame:
FCS doesn't match
Well whatever else, error with b0 set (overrun) on ch0 with crtscts on is
actually illegal, unless I miss the point somewhere. There shouldn't be a
way to get an overrun seen by the RX FIFO under those circumstances.
Either the other end (GSM) is not set to use handshakes, the timing of
using them is wrong, or the detail of the error report from the serial
code is bogus somehow.
The interrupt lockout period doesn't exceed 8ms anyway and doesn't
correlate with the error presence. There can still be (and probably is)
trouble somewhere in terms of locking out serial interrupts by priority,
so some other interrupt like USB is blocking lower priority serial
service.
I think maybe we learn something if we study the damage done to the
received serial stream sequence by one of these events... if we can figure
out how many chars are dropped or what corruption is happening.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2180#comment:10>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
_______________________________________________
buglog mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/buglog
