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 #2073: voice-recording.state + arecord:
Unable to handle kernel NULL pointer dereference at virtual
address 00000000 (Openmoko Public Trac)
2. Re: Openmoko Bug #2073: voice-recording.state + arecord:
Unable to handle kernel NULL pointer dereference at virtual
address 00000000 (Openmoko Public Trac)
3. Openmoko Bug #2234: sms date are empty (Openmoko Public Trac)
4. Re: Openmoko Bug #2232: unplugging with gadgetfs causes
panic: "softlockup: blocked tasks" (Openmoko Public Trac)
5. Re: Openmoko Bug #2232: unplugging with gadgetfs causes
panic: "softlockup: blocked tasks" (Openmoko Public Trac)
6. Re: Openmoko Bug #2223: gsm0710muxd loosing packets?
(Openmoko Public Trac)
7. Re: Openmoko Bug #1380: GSM modem sleeps on virtual channels
in MUX (Openmoko Public Trac)
8. Re: Openmoko Bug #2073: voice-recording.state + arecord:
Unable to handle kernel NULL pointer dereference at virtual
address 00000000 (Openmoko Public Trac)
--- Begin Message ---
#2073: voice-recording.state + arecord: Unable to handle kernel NULL pointer
dereference at virtual address 00000000
---------------------+------------------------------------------------------
Reporter: lindi | Owner: openmoko-devel
Type: defect | Status: new
Priority: normal | Milestone:
Component: unknown | Version:
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible: always
---------------------+------------------------------------------------------
Comment(by lindi):
Graeme just pointed out I should use voip-handset.state. And indeed,
"arecord | aplay" works perfectly with that!
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2073#comment:13>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2073: voice-recording.state + arecord: Unable to handle kernel NULL pointer
dereference at virtual address 00000000
---------------------+------------------------------------------------------
Reporter: lindi | Owner: openmoko-devel
Type: defect | Status: new
Priority: normal | Milestone:
Component: unknown | Version:
Severity: normal | Keywords:
Haspatch: 1 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible: always
---------------------+------------------------------------------------------
Changes (by arhuaco):
* haspatch: 0 => 1
Comment:
Replying to [comment:13 lindi]:
> Graeme just pointed out I should use voip-handset.state. And indeed,
"arecord | aplay" works perfectly with that!
It's really good to know that! As Paul said on IRC the driver should never
crash. He wrote a nice patch that I'm testing now.
https://paulfertser.is-a-geek.org/files/0001-Hack-to-temporarily-avoid-
Oops-on-recording-with-DAI.patch
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2073#comment:14>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2234: sms date are empty
----------------------+-----------------------------------------------------
Reporter: netx512k | Owner: zecke
Type: defect | Status: new
Priority: high | Milestone: Om2008.12
Component: Qtopia | Version:
Severity: normal | Keywords: qtmail sms dates
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible: always
----------------------+-----------------------------------------------------
When i read a sms, i see the date field empty.
Thanx
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2234>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2232: unplugging with gadgetfs causes panic: "softlockup: blocked tasks"
-----------------------------+----------------------------------------------
Reporter: lindi | Owner: openmoko-kernel
Type: defect | Status: in_testing
Priority: normal | Milestone:
Component: System Software | Version: unspecified
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-----------------------------+----------------------------------------------
Comment(by lindi):
{{{
$ arm-linux-gnueabi-addr2line -e ./drivers/usb/gadget/gadgetfs.o 0x1504
/home/lindi/l/neolinux/drivers/usb/gadget/inode.c:359
}}}
shows the wait_event call indeed. I changed that to
wait_event_interruptible but now I get a spinlock lockup (details in
kernel2.log).
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2232#comment:8>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2232: unplugging with gadgetfs causes panic: "softlockup: blocked tasks"
-----------------------------+----------------------------------------------
Reporter: lindi | Owner: openmoko-kernel
Type: defect | Status: in_testing
Priority: normal | Milestone:
Component: System Software | Version: unspecified
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-----------------------------+----------------------------------------------
Comment(by lindi):
My guess here is: when epio_complete is called it tries to use
req->context which points to completion struct that was allocated on stack
in ep_io() and that has already returned? Any idea why the req is still in
the queue even though ep_io calls usb_ep_dequeue?
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2232#comment:9>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2223: gsm0710muxd loosing packets?
------------------------+---------------------------------------------------
Reporter: kapiteined | Owner: julian_chu
Type: defect | Status: new
Priority: normal | Milestone: Om2008.12
Component: Distro | Version: unspecified
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
------------------------+---------------------------------------------------
Comment(by mickey):
Please flash moko11b1 firmware, this has an important fix with regards to
flow control. gsm0710muxd is likely not the problem here.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2223#comment:2>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1380: GSM modem sleeps on virtual channels in MUX
------------------------------------+---------------------------------------
Reporter: mic...@… | Owner: sean_chi...@…
Type: defect | Status: closed
Priority: high | Milestone:
Component: GSM Modem | Version: GTA02v5
Severity: normal | Resolution: wontfix
Keywords: | Haspatch: 0
Blockedby: | Estimated:
Patchreview: | Blocking:
Reproducible: |
------------------------------------+---------------------------------------
Changes (by mickey):
* haspatch: => 0
Comment:
And even more for the records, although probably no one is reading this
anymore... my analysis was wrong, it doesn't sleep on the virtual
channels, it sleeps in multiplexing mode and needs to be sent a full frame
(not just flag characters) to be woken up correctly. With regards to the
original problem, it's no longer a problem at all, since you can even wake
it up properly on mux layer (which is what fso-abyss does) and no longer
have to care on the AT layer.
Case closed :)
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1380#comment:8>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2073: voice-recording.state + arecord: Unable to handle kernel NULL pointer
dereference at virtual address 00000000
---------------------+------------------------------------------------------
Reporter: lindi | Owner: openmoko-devel
Type: defect | Status: new
Priority: high | Milestone:
Component: unknown | Version:
Severity: normal | Keywords: ALSA
Haspatch: 1 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible: always
---------------------+------------------------------------------------------
Changes (by arhuaco):
* keywords: => ALSA
* priority: normal => high
Comment:
I feel like a hen raising ducks with this ALSA thing :-) I'll try to help
anyway.
How do you feel about the dummy states we have in
sound/soc/codecs/wm8753.c?
* Is it OK to have dummy states?
* Why do we have them on the first place?
We already know that Paul's patch avoids the crash but
there are more dummy states and another ALSA state that
works by using another mode. Thus I wonder if we have to:
1. Allow dummy states as they are now and just have some code to prevent
you from opening the device when a dummy state is selected so that we
don't crash.
or
2. Do something similar to what Paul did the patch he coded for all the
other states.
I'm worried that if we do (2) we will end up with different states that
do the same thing and create even more confusion.
Please advise...
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2073#comment:15>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
_______________________________________________
buglog mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/buglog
