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 #2237: pcf50633 INT1 and INT3 flood logs
with gadgetfs keyboard (Openmoko Public Trac)
2. Re: Openmoko Bug #2238: CONFIG_FUNCTION_TRACER panics very
early (Openmoko Public Trac)
3. Re: Openmoko Bug #2215: distros using fso-gsm0710muxd will
not register (Openmoko Public Trac)
4. Re: Openmoko Bug #2217: Noise screen of death: Freerunner
looses SDIO connection (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)
7. Re: Openmoko Bug #2217: Noise screen of death: Freerunner
looses SDIO connection (Openmoko Public Trac)
--- Begin Message ---
#2237: pcf50633 INT1 and INT3 flood logs with gadgetfs keyboard
-----------------------------+----------------------------------------------
Reporter: lindi | Owner: openmoko-kernel
Type: defect | Status: new
Priority: normal | Milestone:
Component: System Software | Version: unspecified
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-----------------------------+----------------------------------------------
Comment(by andy):
INT1 bit is "second" interrupt, by definition you can only get one of
those a second (in fact two due to a symptomless bug with level interrupt
handling). INT3 thing is "USB current limit ON (0x10) and OFF (0x20)".
All of these are normally masked so we don't take care about them, I don't
know why they are suddenly unmasked.
Can you dump the pcf50633 regs while this is happening so I can see the
mask registers from that?
About udev, if I understand it then udev is spinning meddling with adapter
node, it's suspicious that this is the one thing we talk about in pcf50633
but don't use in GTA02.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2237#comment:1>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2238: CONFIG_FUNCTION_TRACER panics very early
-----------------------------+----------------------------------------------
Reporter: lindi | Owner: openmoko-kernel
Type: defect | Status: new
Priority: normal | Milestone:
Component: System Software | Version: unspecified
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-----------------------------+----------------------------------------------
Comment(by fweisbec):
Hi,
Could you please test the above patch, it will disable tracing on those
naked functions.
Note that it applies on 2.6.28 (original) so tell me if it applies not
well on the openmoko kernel.
It's not a smart one, just to test. If it works, it would be better you
redefine the __naked macro with "no_instrument_function" attribute and
"naked" and replace all __attribute__((naked))__ by __naked (should
perhaps even be done in mainline).
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2238#comment:2>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2215: distros using fso-gsm0710muxd will not register
-----------------------------+----------------------------------------------
Reporter: BillK | Owner: openmoko-kernel
Type: defect | Status: new
Priority: normal | Milestone: FSO
Component: System Software | Version:
Severity: normal | Keywords: gsm0710muxd GSM modem
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible: always
-----------------------------+----------------------------------------------
Comment(by BillK):
ok, I have a working mux.
I moved the power and reset lines outside the mux for convenience - the
important line in the initialisation is the stty line in "mygsm" the
attachment to setup the uart.
The two lines that read, then set the flags+O_NONBLOCK are the probable
cause?
I am hoping that when the changes to the serial port stuff filter through,
this will go away as what I am seeing doesnt make sense if everything was
being properly handled.
I have upgraded in the interim to moko11beta firmware with no change to
this problem.
BillK
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2215#comment:6>
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):
Replying to [comment:19 xbaldauf]:
> Replying to [comment:18 andy]:
> > Replying to [comment:16 xbaldauf]:
> > > Interestingly, however, it looks like that, by using
glamo_mci.sd_max_clk=1000000, I can raise the probability of getting such
a crash like above to 100%. The crash happens always at GSM-login-time.
I wonder if we simply delay SD access enough that we still intensively use
it by the time GSM stuff starts up.
> > To be clear, at the time of this "crash", you have the permanent noisy
screen business?
>
> Sometimes, sometimes not. Sometimes the noisy screen is busy (e.g.
updated), sometimes even normal redraws happen (so the noisy screen is
overwritten with the correct content), and sometimes everything stops,
including screen updates.
Ah... that's something totally different than I understood until now. I
thought we were talking about a dynamic, jittering permanently changing
full-display "snow" of noise on the display. I have seen this many times
when working with Glamo internal memory parameters.
It would imply we crapped on the control registers by accident.
But when you say the "noisy screen is overwritten with the correct
content" it sounds instead like the bitmap placed there is wrong data, and
later it might come and invalidate and redraw that area perfectly well.
> The triggering of the bug seems to be strongly GSM-related. AFAIK, it
only happened when I login into the GSM network, place a phonecall or
receive a phonecall or short message. Thus, when I have no GSM traffic for
some hours or even days, the system seems to remain stable.
I hope only some "lucky" devices can suffer from this or we would have
heard about it long before.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2217#comment:21>
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):
works fine here. no overruns within the last 24 hours... :)
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2180#comment:29>
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):
That's great, I'll backport it to stable shortly.
But we didn't throw much light on Harald's issue since unless he soldered
in a Glamo for old times' sake :-) it won't be that code hurting it.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2180#comment:30>
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):
Replying to [comment:21 andy]:
> Replying to [comment:19 xbaldauf]:
> > Replying to [comment:18 andy]:
> > > Replying to [comment:16 xbaldauf]:
> > > > Interestingly, however, it looks like that, by using
glamo_mci.sd_max_clk=1000000, I can raise the probability of getting such
a crash like above to 100%. The crash happens always at GSM-login-time.
>
> I wonder if we simply delay SD access enough that we still intensively
use it by the time GSM stuff starts up.
Well, by now, this conclusion was too fast. Up to now, I've managed to
login 2 times without such a crash. Maybe the crash probability is
dependent on a frequency between my device and the GSM tower, or something
like this.
>
> > > To be clear, at the time of this "crash", you have the permanent
noisy screen business?
> >
> > Sometimes, sometimes not. Sometimes the noisy screen is busy (e.g.
updated), sometimes even normal redraws happen (so the noisy screen is
overwritten with the correct content), and sometimes everything stops,
including screen updates.
>
> Ah... that's something totally different than I understood until now. I
thought we were talking about a dynamic, jittering permanently changing
full-display "snow" of noise on the display. I have seen this many times
when working with Glamo internal memory parameters.
>
> It would imply we crapped on the control registers by accident.
>
> But when you say the "noisy screen is overwritten with the correct
content" it sounds instead like the bitmap placed there is wrong data, and
later it might come and invalidate and redraw that area perfectly well.
Yes. It looks like that, initially, the bug is transient in nature. It is
just that severe that the damages done are persistent (until the next
power cycle). Sometimes it may happen that I can continue working with the
device, sometimes I can continue working with the device as long as there
is no write access (because the filesystem was re-mounted read-only due to
I/O errors, but the I/O errors are now gone), and sometimes I cannot
continue at all (because of some crash, sometimes I see the red lights of
the AUX button blinking fast, sometimes not). Being able to continue
implies that the correct screen is redrawn (e.g. by changing the currently
visible application, the screen is redrawn).
>
> > The triggering of the bug seems to be strongly GSM-related. AFAIK, it
only happened when I login into the GSM network, place a phonecall or
receive a phonecall or short message. Thus, when I have no GSM traffic for
some hours or even days, the system seems to remain stable.
>
> I hope only some "lucky" devices can suffer from this or we would have
heard about it long before.
So you are suggesting a hardware failure...? I've never experienced this
bug under kernel 2.6.24 AFAIK.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2217#comment:22>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
_______________________________________________
buglog mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/buglog
