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 #2258: xf86-video-glamo: task mmcqd:572
blocked for more than 120 seconds. (Openmoko Public Trac)
2. Re: Openmoko Bug #2209: alsactl restore wakes up X
(Openmoko Public Trac)
3. Re: Openmoko Bug #2262: backlight brightness of 11 unusable
after blank/unblank (Openmoko Public Trac)
4. Re: Openmoko Bug #2135: write kernel crash message somewhere
where it can be retrieved after reboot? (Openmoko Public Trac)
5. Re: Openmoko Bug #2263: xf86-video-glamo/703acea13: xrandr
--output LCD --mode 240x320 incorrect screen position
(Openmoko Public Trac)
6. Re: Openmoko Bug #2258: xf86-video-glamo: task mmcqd:572
blocked for more than 120 seconds. (Openmoko Public Trac)
7. Re: Openmoko Bug #2267: [wifi] kernel oops when starting
wpa_supplicant (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 ---
#2258: xf86-video-glamo: task mmcqd:572 blocked for more than 120 seconds.
-----------------------------+----------------------------------------------
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 lindi):
I keep hitting this quite often if I stop Xorg immediately after it has
been started on bootup. Lars, can you try this on your system? I would
imagine that in your development you must be restarting Xorg quite often
so it'd be interesting to know if it has been stable and with what kernel.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2258#comment:1>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2209: alsactl restore wakes up X
-----------------------------+----------------------------------------------
Reporter: lindi | Owner: openmoko-kernel
Type: defect | Status: new
Priority: low | Milestone: stable-kernel-2009.1
Component: System Software | Version:
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-----------------------------+----------------------------------------------
Changes (by arhuaco):
* priority: normal => low
* milestone: => stable-kernel-2009.1
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2209#comment:10>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2262: backlight brightness of 11 unusable after blank/unblank
-----------------------------+----------------------------------------------
Reporter: lindi | Owner: openmoko-kernel
Type: defect | Status: new
Priority: normal | Milestone: stable-kernel-2009.1
Component: System Software | Version: unspecified
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-----------------------------+----------------------------------------------
Changes (by arhuaco):
* milestone: => stable-kernel-2009.1
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2262#comment:2>
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: high | Milestone: stable-kernel-2009.1
Component: System Software | Version: unspecified
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-----------------------------+----------------------------------------------
Changes (by arhuaco):
* priority: normal => high
* milestone: => stable-kernel-2009.1
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2135#comment:19>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2263: xf86-video-glamo/703acea13: xrandr --output LCD --mode 240x320 incorrect
screen position
-----------------------------+----------------------------------------------
Reporter: lindi | Owner: openmoko-kernel
Type: defect | Status: new
Priority: low | Milestone: stable-kernel-2009.1
Component: System Software | Version:
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-----------------------------+----------------------------------------------
Changes (by arhuaco):
* priority: normal => low
* milestone: => stable-kernel-2009.1
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2263#comment:2>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2258: xf86-video-glamo: task mmcqd:572 blocked for more than 120 seconds.
-----------------------------+----------------------------------------------
Reporter: lindi | Owner: openmoko-kernel
Type: defect | Status: new
Priority: low | Milestone: stable-kernel-2009.1
Component: System Software | Version: unspecified
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-----------------------------+----------------------------------------------
Changes (by arhuaco):
* priority: normal => low
* milestone: => stable-kernel-2009.1
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2258#comment:2>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2267: [wifi] kernel oops when starting wpa_supplicant
---------------------+------------------------------------------------------
Reporter: tilman2 | Owner: openmoko-devel
Type: defect | Status: new
Priority: high | Milestone: stable-kernel-2009.1
Component: unknown | Version: unspecified
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
---------------------+------------------------------------------------------
Changes (by arhuaco):
* priority: normal => high
* milestone: => stable-kernel-2009.1
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2267#comment:2>
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: high | Milestone: stable-kernel-2009.1
Component: System Software | Version: unspecified
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-----------------------------+----------------------------------------------
Comment(by lindi):
The current shortcoming of ramconsole-1.patch are:
1) It needs mem=127M option
2) panic=20 and/or watchdog is needed so that user can recover the message
after reboot
3) It prints contents of the ringbuffer to console on bootup. This can be
very slow if the ringbuffer holds the full 1M of data.
4) Often after a crash there is an fsck and after that the system is
rebooted. This means the contents of ringbuffer is actually printed twice
to console.
5) Since contents of ringbuffer is printed to console using printk it is
limited by the size of the printk buffer, sometimes fsck+reboot is enough
to add so much data that when syslogd is finally started it can not read
the original panic message from /proc/kmsg anymore.
6) Sometimes when the system is so stuck that I need to remove the battery
to reboot it the contents of the ringbuffer starts to fade when no RAM
refresh is done. This is usually harmless but if it happens to hit the
magic word then ramconsole-1.patch will not print the contents of the
ringbuffer and there is no way to access it from userland either (I
couldn't do it via /dev/mem for some reason).
Advantages are:
1) It works and provides useful info
2) It is quite simple patch that does not modify kernel logging logic
much, it merely adds its own ringbuffer in parallel to the normal logging
which should reduce the likelyhood that it breaks something important.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2135#comment:20>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
_______________________________________________
buglog mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/buglog
