Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 152604 - hiddev: sending output report silently fails on 2.4.x kernels
hiddev: sending output report silently fails on 2.4.x kernels
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Pete Zaitcev
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-03-30 13:29 EST by Boris Shingarov
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-10-19 15:05:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
test client (2.77 KB, text/plain)
2005-03-30 13:33 EST, Boris Shingarov
no flags Details

  None (edit)
Description Boris Shingarov 2005-03-30 13:29:38 EST
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):

How reproducible:

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 13:33:06 EST
Created attachment 112470 [details]
test client
Comment 2 Ernie Petrides 2005-03-30 22:32:08 EST
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-30 23:47:48 EST
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 Product and Program Management 2007-10-19 15:05:37 EDT
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:
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.

Note You need to log in before you can comment on or make changes to this bug.