Bug 152604

Summary: hiddev: sending output report silently fails on 2.4.x kernels
Product: Red Hat Enterprise Linux 3 Reporter: Boris Shingarov <boris>
Component: kernelAssignee: Pete Zaitcev <zaitcev>
Status: CLOSED WONTFIX QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: jbaron, petrides, riel
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-10-19 19:05:37 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
test client none

Description Boris Shingarov 2005-03-30 18:29:38 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

Description of problem:
Sending an output report to a HID device works perfectly with 2.6 kernels (I tested with 2.6.6, .9, .10, and .11) but not with 2.4.21, 2.4.22, or 2.4.29.

We have a device which is controlled by hid output reports.
There is one output report, with two usages.
Obtaining the report id and usage code, setting the values, and sending the report, works on 2.6.  On 2.4, the HIDIOCSREPORT ioctl succeeds (zero return code), but the report is in fact not sent to the device.  I was trying it first with 2.4.21 which is the kernel installed out-of-the-box on RHEL3, but I understand there was a major issue with multiple usages; so I tried with .29 but the behavior is the same.

So I put a bunch of printk()'s in various places of hid-core.c and hiddev.c to better understand what was going on.  Everything in hid_submit_report(), hid_write_report(), hid_output_report(), hid_submit_out(), all the way to hid_output_field(), looks normal.  Hid_output_field() gets called the right number of times (one for each of the two usages), with the correct arguemnts (like, correct usage and correct value to put in).  The problem seems to be with submit_urb(), which printks "ctrl urb status -32 received".  The return value of the ioctl itself, however, is 0.  (I would vaguely guess this has to do with the fact that the send is only initiated here, and not carried out synchronously, so when the actual error happens, the ioctl has already returned... would be happy if somebody explained to me how this works exactly).


Version-Release number of selected component (if applicable):
2.4.29

How reproducible:
Always

Steps to Reproduce:
A full test case code is attached.

Actual Results:  The report is not sent, the return code from the ioctl is 0, and the kernel outputs: "ctrl urb status -32 received".


Additional info:

Comment 1 Boris Shingarov 2005-03-30 18:33:06 UTC
Created attachment 112470 [details]
test client

Comment 2 Ernie Petrides 2005-03-31 03:32:08 UTC
Hello, Boris.  The upstream 2.4.21 kernel is not identical to the RHEL3
kernel.  Could you please verify whether this problem occurs on RHEL3?

(Red Hat bugzilla is not a mechanism for reporting upstream bugs.)

Comment 3 Boris Shingarov 2005-03-31 04:47:48 UTC
Yes it does occur on the RHEL3 kernel, both the one in the original RHEL3, and
the latest "Update 4" ("-27").

In fact, I don't even care much about the upstream 2.4 kernels; our software
works fine with 2.6.*, and the only reason why I am concerned with 2.4 is
because we would like to have out-of-the-box support for RHEL3.
The point of testing vanilla .21 and .29 was to see whether the bug was caused
by the multi-usage-report deficiency which was fixed between 21 and 22 in the
vanilla series.

Comment 4 RHEL Program Management 2007-10-19 19:05:37 UTC
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
 
For more information of the RHEL errata support policy, please visit:
http://www.redhat.com/security/updates/errata/
 
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.