RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 606806 - Backport V4L/DVB fixes from 2.6.32.25
Summary: Backport V4L/DVB fixes from 2.6.32.25
Keywords:
Status: CLOSED DUPLICATE of bug 663280
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel
Version: 6.0
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Stanislaw Gruszka
QA Contact: desktop-bugs@redhat.com
URL:
Whiteboard:
Depends On:
Blocks: 663280 682906
TreeView+ depends on / blocked
 
Reported: 2010-06-22 14:22 UTC by Stanislaw Gruszka
Modified: 2011-03-07 22:55 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 663280 (view as bug list)
Environment:
Last Closed: 2011-01-12 09:11:51 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Stanislaw Gruszka 2010-06-22 14:22:35 UTC 
Apply two upstream uvcvideo commits:

f4eabafeb3ea41801260fba624cbf2da971d19f8
"V4L/DVB (13148): uvcvideo: Handle V4L2_CTRL_TYPE_BUTTON control type in VIDIOC_QUERYCTRL"

and

cf7a50eeb6f462a0b7d1619fcb27a727a2981769
"V4L/DVB: uvcvideo: Prevent division by 0 when control step value is 0"
Comment 1 RHEL Program Management 2010-06-22 14:32:59 UTC 
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.
Comment 2 Stanislaw Gruszka 2010-06-25 08:33:20 UTC 
I will post patches when "vcvideo: Prevent division by 0 when control step value is 0" will get -stable release.
Comment 3 RHEL Program Management 2010-07-15 13:59:18 UTC 
This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release. It has
been denied for the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **
Comment 4 Stanislaw Gruszka 2010-10-29 09:53:34 UTC 
Second patch we wanted to backport (cf7a50eeb6f462a0b7d1619fcb27a727a2981769
"V4L/DVB: uvcvideo: Prevent division by 0 when control step value is 0") is fix for commit e54532e591cd5b9ce77dbc8d9786ae9f600f101a "V4L/DVB: uvcvideo: Clamp control values to the minimum and maximum values". This patch is not present in RHEL 6 hence we do not have to backport it (also both commits are not present in 2.6.32 -stable).
Comment 7 Jarod Wilson 2010-11-24 20:24:57 UTC 
What if we were to, say, take a full backport of the entire current upstream staging/for_v2.6.38 v4l/dvb tree instead?...
Comment 8 Stanislaw Gruszka 2010-11-25 12:10:29 UTC 
Hmm, is there anything that we really need? 

I considered adding 2.6.32.y -stable fixes to pretty safe, in opposite to backporting from new kernels, where can by lot of bugs in new code and new bugs introduced during backporting. And how we could test that backports? I don't think we have much video cameras and DVB adapters in house.
Comment 9 Jarod Wilson 2010-12-01 15:39:16 UTC 
We definitely don't have every device out there, but I do at least have a fair sampling in my own possession, and am currently running a few systems at home with a test build carrying a full backport, routinely stressing a few of the more popular drivers (ivtv, cx18, em28xx, cx2388x, hdpvr)...

I'm thinking we'd need to seek testing assistance with some one-off builds from some of our larger customers who actually utilize this code.
Comment 10 Mauro Carvalho Chehab 2010-12-01 19:34:12 UTC 
I have also some other devices, like cx23885, saa7134, several gspca-supported webcams, uvcvideo, etc.

It shouldn't hard to backport, as we have a backport tree that works since kernel 2.6.31.
Comment 11 Jarod Wilson 2010-12-01 19:42:13 UTC 
(In reply to comment #10)
...
> It shouldn't hard to backport, as we have a backport tree that works since
> kernel 2.6.31.

Yeah, I've actually already done the leg work here -- which is mostly take the backport tree bits, overlay them on the rhel6 tree, then fix things up as necessary (kabi work-arounds). :)

(Reminds me... most of the initial issues I encountered with thinking something was rather broken in the backports tree were simply due to one of the backport patches no longer applying because of context changes. I have an updated patch that applies cleanly, but have yet to commit it.)
Comment 12 Jarod Wilson 2010-12-01 21:55:33 UTC 
Everything builds fine out of tree from here again:

http://git.linuxtv.org/media_build.git

Then I've got a series of patches that can be overlaid on top of that to take care of kabi (well, actually... some of them probably need further cleaning/sanitization to do more than simply pass the kabi checks).
Comment 17 Stanislaw Gruszka 2010-12-15 09:34:25 UTC 
I opened bug report for full backport. If it get acks we Jarod will do the backport, we close this one bug as duplicate. Otherwise I will post only -stable patches.
Comment 18 Stanislaw Gruszka 2011-01-12 09:11:51 UTC 

*** This bug has been marked as a duplicate of bug 663280 ***
Note You need to log in before you can comment on or make changes to this bug.