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. Openmoko Bug #2135: write kernel crash message somewhere
where it can be retrieved after reboot? (Openmoko Public Trac)
2. Re: Openmoko Bug #2135: write kernel crash message somewhere
where it can be retrieved after reboot? (Openmoko Public Trac)
3. Re: Openmoko Bug #2135: write kernel crash message somewhere
where it can be retrieved after reboot? (Openmoko Public Trac)
4. Re: Openmoko Bug #1841: white screen of death (WSOD) after
resume (Openmoko Public Trac)
5. Re: Openmoko Bug #2135: write kernel crash message somewhere
where it can be retrieved after reboot? (Openmoko Public Trac)
6. Openmoko Bug #2136: Freerunner QVGA portrait mode wrong
colors (Openmoko Public Trac)
7. Re: Openmoko Bug #2135: write kernel crash message somewhere
where it can be retrieved after reboot? (Openmoko Public Trac)
8. Re: Openmoko Bug #2135: write kernel crash message somewhere
where it can be retrieved after reboot? (Openmoko Public Trac)
--- Begin Message ---
#2135: write kernel crash message somewhere where it can be retrieved after
reboot?
-----------------------------+----------------------------------------------
Reporter: lindi | Owner: openmoko-kernel
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: System Software | Version: unspecified
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-----------------------------+----------------------------------------------
This is a wishlist bug. Would it be possible to write the kernel crash
message somewhere where it can be retrieved after reboot? Would writing to
nand (to dedicated partition) be safe? If uboot does not overwrite RAM
contents could the error be retrieved from RAM after reboot?
If this fails it should be quite easy to send the contents of the panic
message by blinking the AUX led, right? The only problem here is that
there needs to be some automated way to capture it.
Audio would be easier to capture since people have soundcards to record it
but it would probably be harder to control when the kernel has crashed
(and it would annoy everyone around you while you are booting your laptop
to capture the crash message :P).
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2135>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2135: write kernel crash message somewhere where it can be retrieved after
reboot?
-----------------------------+----------------------------------------------
Reporter: lindi | Owner: openmoko-kernel
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: System Software | Version: unspecified
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-----------------------------+----------------------------------------------
Comment(by werner):
I would use RAM. It's easy to access and it's very likely to survive a
reset. Also, since the kernel itself may not know it is dead (e.g., if
the system just hangs and you have to reset it), you would want to write
all messages to that "safe" location, so access should be inexpensive.
For retrieval, you could either extend the boot loader, or, better, only
start writing to the "safe area" after you've checked for the presence
of old content. That way, crashes occurring before the retrieval could
not be recorded (if you use multiple buffers you rotate, you could even
handle some cases, but it may not be worth the effort), but you're
probably after those that are hard to reproduce and only happen after a
while.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2135#comment:1>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2135: write kernel crash message somewhere where it can be retrieved after
reboot?
-----------------------------+----------------------------------------------
Reporter: lindi | Owner: openmoko-kernel
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: System Software | Version: unspecified
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-----------------------------+----------------------------------------------
Comment(by andy):
For folks lucky enough to have a debug board, this isn't needed since you
can just look in your terminal emulator and see the full backtrace or
whatever. But I agree if you don't have that then it is very tough to
know what the hell happened. It does not seem we can expect our devices
to give access to the debug console in a user friendly way (ie, private
USB connector for it) for foreseeable future unfortunately.
In the Linux x86 world there's a trick thing to store stuff in RTC RAM for
debugging suspend for example, but it's very ugly.
Definitely this isn't the business of the bootloader to deal with. But I
agree about using RAM.
We can use physical address at end of RAM, we could back off the 128MB we
tell Linux about a little. Next Linux boot can display it, we can
probably expose it to userspace and let initscript handle it, since we
only target case where panic could not be seen on original boot due to X
for example. If a panic is happening during boot shortly we will display
it on LCM by default in Qi case.
It should be pretty certain that you can always boot into backup rootfs /
kernel unless something awful has happened, even then you can nuke your SD
Card and come back like that with high certainty.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2135#comment:2>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1841: white screen of death (WSOD) after resume
-----------------------+----------------------------------------------------
Reporter: Rorschach | Owner: openmoko-devel
Type: defect | Status: new
Priority: highest | Milestone:
Component: unknown | Version: GTA02v5
Severity: critical | Keywords: wsod,resume
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible: always
-----------------------+----------------------------------------------------
Comment(by werner):
Turning some of those mdelay() busy-loops into msleep()s wouldn't
be so bad either ...
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1841#comment:76>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2135: write kernel crash message somewhere where it can be retrieved after
reboot?
-----------------------------+----------------------------------------------
Reporter: lindi | Owner: openmoko-kernel
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: System Software | Version: unspecified
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-----------------------------+----------------------------------------------
Comment(by lindi):
Have you tested kdump that uses kexec() to start a rescue kernel that can
use its drivers to write user and kernel memory space to disk?
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2135#comment:3>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2136: Freerunner QVGA portrait mode wrong colors
-----------------------------+----------------------------------------------
Reporter: Vladimir.Koutny | Owner: openmoko-devel
Type: defect | Status: new
Priority: normal | Milestone:
Component: unknown | Version: Om2008.9-dev
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible: always
-----------------------------+----------------------------------------------
When switching to QVGA mode using "xrandr --mode 240x320" the display is
too bright - all colors are brighter than they should be and there are
ligher/darker bars around most onscreen elements. Framebuffer content is
correct.
It is possible to fix this by rotating the screen left/right and then back
to normal (via xrandr again). This fix is then 'valid' until next xglamo
restart - even if you change to VGA and back.
Some pictures (change in color is not very clear but the light bars are):
http://people.ksp.sk/~vlado/moko/qvga.html
Kernel+Rootfs: today's 2008.9 (or my own build, doesn't matter):
Om2008.9-gta02-20081106.uImage.bin
Om2008.9-gta02-20081117.rootfs.jffs2
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2136>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2135: write kernel crash message somewhere where it can be retrieved after
reboot?
-----------------------------+----------------------------------------------
Reporter: lindi | Owner: openmoko-kernel
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: System Software | Version: unspecified
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-----------------------------+----------------------------------------------
Comment(by andy):
Nope. Project seems to be a bit dead?
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2135#comment:4>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2135: write kernel crash message somewhere where it can be retrieved after
reboot?
-----------------------------+----------------------------------------------
Reporter: lindi | Owner: openmoko-kernel
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: System Software | Version: unspecified
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-----------------------------+----------------------------------------------
Comment(by werner):
For example, just a couple of months ago, Fedora considered it pretty
much alive:
http://fedoraproject.org/wiki/Kernel/kdump
The kernel-side functionality is old, so that's why you don't read much
about it these days. The magic is in the user space you use with this.
However, I wonder if kdump may not be a bit too much overkill for our
small devices. Also, a simple buffer in a reserved RAM area would be
more reliable for just keeping messages. kdump was designed for doing
real crash dumps on big servers, with kernel state analysis and all
the bells and whistles.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2135#comment:5>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
_______________________________________________
buglog mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/buglog
