Opened 15 years ago
Closed 14 years ago
#2073 closed defect (fixed)
bttv port from v4l1 to v4l2
Reported by: | Owned by: | danielk | |
---|---|---|---|
Priority: | minor | Milestone: | 0.21 |
Component: | mythtv | Version: | head |
Severity: | medium | Keywords: | |
Cc: | Ticket locked: | no |
Description
NOTE: I have modified my version of myth to use V4L2 instead of V4L1 with my bttv cards. I submit this patch in preparation for when V4L1 goes away, and for review etc.
Semi-regularily the bttv driver has a shit-fit. Luckily, for the last couple of years the bttv driver has been capable of reseting and recovering nicely in this situation. Mythtv usually doesn't handle this very well. I have experienced these errors with many flavours of bttv cards and mobos over the years:
System log:
kernel: bttv0: SCERR @ 1f66c014,bits: OFLOW FDSR SCERR* kernel: bttv0: SCERR @ 1f66c014,bits: OFLOW FDSR SCERR* kernel: bttv0: SCERR @ 1f66c014,bits: HSYNC OFLOW SCERR* last message repeated 15 times kernel: bttv0: timeout: drop=5 irq=556586/556586, risc=1f66c01c, bits: HSYNC OFLOW kernel: bttv0: reset, reinitialize kernel: bttv0: PLL can sleep, using XTAL (28636363). kernel: bttv0: SCERR @ 1f66c014,bits: OFLOW FDSR SCERR*
This results in EIO when dequeing the video buffers from V4L2, (This example is with my patch applied and shows a successful recovery):
Mythbackend log:
2006-07-17 18:21:41.509 XDS: Unhandled packet (0x2 0x2) sz(20) '' 2006-07-17 18:21:42.320 NVR(/dev/video0) Error: Reading VBI data eno: Input/output error (5) 2006-07-17 18:21:42.396 NVR(/dev/video0) Error: Reading VBI data eno: Input/output error (5) VIDIOC_DQBUF: Input/output error 2006-07-17 18:21:42.411 NVR(/dev/video0) Error: Reading VBI data eno: Input/output error (5) 2006-07-17 18:21:42.413 NVR(/dev/video0): Reset and requeue capture buffers. 2006-07-17 18:21:42.415 NVR(/dev/video0) Error: Reading VBI data eno: Input/output error (5) 2006-07-17 18:23:01.123 XDS: Unhandled packet (0x2 0x2) sz(26) '' 2006-07-17 18:27:24.431 MainServer::HandleAnnounce Monitor 2006-07-17 18:27:24.489 adding: mars as a client (events: 0)
Without this patch I usually need to restart the backend, and miss the intervening shows etc., in order to fully recover.
What this patch does:
- Resets and requeues the V4L2 video capture buffers when we get and EIO error. We have to do this because there is no way to know what state the video buffer we just tried to dequeue is in.
- Consolidates the existing reset/requeue buffer code. Needs testing by go7007 user.
- Changes -EINVAL to EINVAL. I get a positive EIO so I assume we get a positive EINVAL too but, I never got one in my testing so I couldn't verify.
- Removes goto label which is at the top of the while loop.
Shane
Attachments (1)
Change History (3)
Changed 15 years ago by
Attachment: | NVR_V4L2_reset_capture_buffers.diff added |
---|
comment:1 Changed 14 years ago by
Milestone: | → 0.21 |
---|---|
Owner: | changed from Isaac Richards to danielk |
Summary: | Recover from bttv driver resets → bttv port from v4l1 to v4l2 |
Version: | → head |
comment:2 Changed 14 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
(In [11416]) Fixes #2073. This extends support for recovery from a EINVAL or EIO to v4l2 drivers other than the go7007 using modified patch from gnome42 at gmail.
When the bttv v4l2 driver freaks it errors with one of these and you need to reset the buffer state to continue, we already had the code to do this with the go7007 so this just employs this for all v4l2 drivers. This is a safe API call for all v4l2 drivers and is recommended practice anyway. The reset also appears to help when the cx88 freaks out on channel changes (by dropping most of the damaged frames, we still need the retune hack for this driver when we get an EIO).
This does not do a reset on file changes for any drivers other than the go7007, it only does the buffer reset on errors for normal V4L2 devices.
(I removed the cosmetic fixes in the patch to make reading the changeset easier).
V4L2 capture buffer reset