On Tue, Sep 19, 2006 at 03:38:40PM +0200, Martin Wache wrote: > Well, it's not much information we have, so it is difficult to say > anything about it. To be honest currently I don't have a clue what could > cause this. It sounds a bit like a deadlock...
Indeed, it feels like a deadlock. Fortunately, the problem appears to be
repeatable. Tonight, I had the MPEG stream suspended for almost an hour.
When I restarted, the display was powered on and audio played for less than
a second before the system hung. (Audio output may have been produced for
more than a second, but it takes some time for the monitor to power on.)
Here's the syslog from the time of the hang:
Sep 19 22:19:10 vdr sshd[2375]: Accepted publickey for vdr from 10.0.0.3 port
34216 ssh2
Sep 19 22:19:18 vdr kernel: cx88[1]/2: cx8802_restart_queue
Sep 19 22:19:18 vdr kernel: cx88[1]/2: cx8802_restart_queue: queue is empty
Sep 19 22:19:18 vdr kernel: cx88[1]/2: queue is empty - first active
Sep 19 22:19:18 vdr kernel: cx88[1]/2: cx8802_start_dma w: 0, h: 0, f: 2
Sep 19 22:19:18 vdr kernel: cx88[1]/2: setting the interrupt mask
Sep 19 22:19:18 vdr kernel: cx88[1]/2: [bf0fc760/0] cx8802_buf_queue - first
active
Sep 19 22:19:18 vdr kernel: cx88[1]/2: cx8802_restart_queue
Sep 19 22:19:18 vdr kernel: cx88[1]/2: cx8802_restart_queue: queue is empty
Sep 19 22:19:18 vdr kernel: cx88[1]/2: queue is empty - first active
Sep 19 22:19:18 vdr kernel: cx88[1]/2: cx8802_start_dma w: 0, h: 0, f: 2
Sep 19 22:19:18 vdr kernel: cx88[1]/2: setting the interrupt mask
Sep 19 22:19:18 vdr kernel: cx88[1]/2: [bf0fc0a0/0] cx8802_buf_queue - first
active
Sep 19 22:19:18 vdr kernel: cx88[1]/2: cx8802_restart_queue
Sep 19 22:19:18 vdr kernel: cx88[1]/2: cx8802_restart_queue: queue is empty
Sep 19 22:19:18 vdr kernel: cx88[1]/2: queue is empty - first active
Sep 19 22:19:18 vdr kernel: cx88[1]/2: cx8802_start_dma w: 0, h: 0, f: 2
Sep 19 22:19:18 vdr kernel: cx88[1]/2: setting the interrupt mask
Sep 19 22:19:18 vdr kernel: cx88[1]/2: [bf0fc760/0] cx8802_buf_queue - first
active
Sep 19 22:19:27 vdr vdr: [1322] cAudioRepacker(0xC0): skipped 512 bytes to sync
on next audio frame
Sep 19 22:19:34 vdr vdr: [1323] ERROR: 1 ring buffer overflow (177 bytes
dropped)
Sep 19 22:19:40 vdr vdr: [1323] ERROR: 10256 ring buffer overflows (1928128
bytes dropped)
Sep 19 22:19:46 vdr vdr: [1323] ERROR: 11692 ring buffer overflows (2198096
bytes dropped)
Sep 19 22:19:52 vdr vdr: [1323] ERROR: 11317 ring buffer overflows (2127596
bytes dropped)
Sep 19 22:19:58 vdr vdr: [1323] ERROR: 11251 ring buffer overflows (2115188
bytes dropped)
Sep 19 22:20:04 vdr vdr: [1323] ERROR: 13308 ring buffer overflows (2501904
bytes dropped)
Those cx88 messages repeat several times a minute, and they are harmless
if I remember correctly the discussion on the v4l mailing list.
The only non-cx88 message since the playback was suspended was this one:
Sep 19 21:44:11 vdr dhclient: DHCPREQUEST on eth0 to 193.229.28.26 port 67
Sep 19 21:44:11 vdr dhclient: DHCPACK from 193.229.28.26
Sep 19 21:44:11 vdr dhclient: bound to 88.113.69.182 -- renewal in 3600 seconds.
Before resuming playback, I checked the vdr log. The tail looks like this:
[dfb] (re)configuring Videolayer to 704 x 576 (704x576)
[dfb] creating new surface (stretchBlit)
[surface capabilities] videoSurface: videoonly interlaced PixelFormat =
0x00200806
[dfb] (re)configured 0x00200806
[dfb] (re)configuring Videolayer to 720 x 576 (540x576)
[dfb] creating new surface (stretchBlit)
[surface capabilities] videoSurface: videoonly interlaced PixelFormat =
0x00200806
[dfb] (re)configured 0x00200806
[mpeg2video @ 0xa7b448a8]skipped MB in I frame at 34 0
[mpeg2video @ 0xa7b448a8]ac-tex damaged at 4 31
[mpeg2video @ 0xa7b448a8]ac-tex damaged at 0 32
[mpeg2video @ 0xa7b448a8]ac-tex damaged at 1 34
[mpeg2video @ 0xa7b448a8]ac-tex damaged at 1 35
[mpeg2video @ 0xa7b448a8]Warning MVs not available
[mpeg2video @ 0xa7b448a8]concealing 1575 DC, 1575 AC, 1575 MV errors
[mpeg2video @ 0xa7b448a8]concealing 1575 DC, 1575 AC, 1575 MV errors
[mpeg2video @ 0xa7b448a8]concealing 1575 DC, 1575 AC, 1575 MV errors
I can't remember if the second "(re)configuring" message was already there
before resuming playback. The MPEG errors certainly weren't there.
After the hang, I attached gdb to the process and captured full stack trace
of all threads (gzipped output attached). I hope that this helps.
Marko
gdb.txt.gz
Description: Binary data
_______________________________________________ Softdevice-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/softdevice-devel
