[libhid-discuss] libhid problems with interrupt_read/write

Thomas Maclean tmaclean at sandbox.ca
Thu Apr 5 19:28:32 UTC 2007


Great!

My kernel is  2.6.9-42.0.3.EL.

As you concluded Ion is not big...  Do you know if libhid or libusb have
an byte alignment requirements?  I found it quite weird that adding small
amounts of unrelated code could cause a segfault.

I put my verson with the wrapped hid_interrupt_write here:
www.sandbox.ca/~tmaclean/tom_ion.c

This version is the one that segafaults if I add another case to the
switch statement that handles user input or if hid_interrupt_write is
called directly in the main function.

I put my stripped down vesion here:
www.sandbox.ca/~tmaclean/stripped_ion.c

What I see in the stripped version is that after a hid_interrupt_read
times out, the following write fails, the one after that works, and all
subsequent reads fail.  Is there something I am supposed to do after a
interrupt_read timeout to clear the timeout condition?

Many thanks for your help.

Regards,

Tom MacLean


----------------------
output from stripped version....

NOTICE: hid_force_open(): successfully opened USB device 003/002[0].
  TRACE: hid_interrupt_write(): writing interrupt report to device
003/002[0] ...
 NOTICE: hid_interrupt_write(): successfully sent interrupt report to
device 003/002[0]
CLEAR INPUT QUEUE=============================
  TRACE: hid_interrupt_read(): retrieving interrupt report from device
003/002[0] ...
 NOTICE: hid_interrupt_read(): successfully got interrupt report from
device 003/002[0]
Got CTS
  TRACE: hid_interrupt_read(): retrieving interrupt report from device
003/002[0] ...
 NOTICE: hid_interrupt_read(): successfully got interrupt report from
device 003/002[0]
Got CTS
  TRACE: hid_interrupt_read(): retrieving interrupt report from device
003/002[0] ...
 NOTICE: hid_interrupt_read(): successfully got interrupt report from
device 003/002[0]
  TRACE: hid_interrupt_read(): retrieving interrupt report from device
003/002[0] ...
 NOTICE: hid_interrupt_read(): successfully got interrupt report from
device 003/002[0]
  TRACE: hid_interrupt_read(): retrieving interrupt report from device
003/002[0] ...
 NOTICE: hid_interrupt_read(): successfully got interrupt report from
device 003/002[0]
  TRACE: hid_interrupt_read(): retrieving interrupt report from device
003/002[0] ...
 NOTICE: hid_interrupt_read(): successfully got interrupt report from
device 003/002[0]
  TRACE: hid_interrupt_read(): retrieving interrupt report from device
003/002[0] ...
 NOTICE: hid_interrupt_read(): successfully got interrupt report from
device 003/002[0]
  TRACE: hid_interrupt_read(): retrieving interrupt report from device
003/002[0] ...
 NOTICE: hid_interrupt_read(): successfully got interrupt report from
device 003/002[0]
  TRACE: hid_interrupt_read(): retrieving interrupt report from device
003/002[0] ...
WARNING: hid_interrupt_read(): timeout on interrupt read from device
003/002[0]
FIRST WRITE ==================================
  TRACE: hid_interrupt_write(): writing interrupt report to device
003/002[0] ...
WARNING: hid_interrupt_write(): failed to write all of interrupt report to
device 003/002[0]; requested: 3 bytes, sent: 0 bytes.
Write returned 21.
SECOND WRITE =================================
  TRACE: hid_interrupt_write(): writing interrupt report to device
003/002[0] ...
 NOTICE: hid_interrupt_write(): successfully sent interrupt report to
device 003/002[0]
CLEAR INPUT QUEUE=============================
  TRACE: hid_interrupt_read(): retrieving interrupt report from device
003/002[0] ...
WARNING: hid_interrupt_read(): failed to get all of interrupt report from
device 003/002[0]; requested: 8 bytes, sent: 0 bytes.
FIRST WRITE ==================================
  TRACE: hid_interrupt_write(): writing interrupt report to device
003/002[0] ...
WARNING: hid_interrupt_write(): failed to write all of interrupt report to
device 003/002[0]; requested: 3 bytes, sent: 0 bytes.
Write returned 21.
SECOND WRITE =================================
  TRACE: hid_interrupt_write(): writing interrupt report to device
003/002[0] ...
 NOTICE: hid_interrupt_write(): successfully sent interrupt report to
device 003/002[0]
CLEAR INPUT QUEUE=============================
  TRACE: hid_interrupt_read(): retrieving interrupt report from device
003/002[0] ...
WARNING: hid_interrupt_read(): failed to get all of interrupt report from
device 003/002[0]; requested: 8 bytes, sent: 0 bytes.
FIRST WRITE ==================================
  TRACE: hid_interrupt_write(): writing interrupt report to device
003/002[0] ...
WARNING: hid_interrupt_write(): failed to write all of interrupt report to
device 003/002[0]; requested: 3 bytes, sent: 0 bytes.
Write returned 21.
SECOND WRITE =================================
  TRACE: hid_interrupt_write(): writing interrupt report to device
003/002[0] ...
 NOTICE: hid_interrupt_write(): successfully sent interrupt report to
device 003/002[0]
  TRACE: hid_close(): closing USB device 003/002[0]...
  TRACE: hid_close(): closing handle of USB device 003/002[0]...
 NOTICE: hid_close(): successfully closed USB device 003/002[0].
  TRACE: hid_reset_parser(): resetting the HID parser for USB device
003/002[0]...
  TRACE: hid_close(): freeing memory allocated for HID parser...
  TRACE: hid_close(): resetting HIDInterface...
 NOTICE: hid_cleanup(): successfully deinitialised HID library.

[root at sonya hid_ion]# uname -a
Linux 2.6.9-42.0.3.EL #1 Fri Oct 6 05:59:54 CDT 2006 i686
i686 i386 GNU/Linux








On Thu, 5 Apr 2007, Charles Lepple wrote:

> Thomas Maclean wrote:
> >
> > Greetings:
> >
> > Please excuse me if this is the wrong forum to ask about libhid usage
> > problems ...
>
> you've come to the right place.
>
> > I am trying to debug a problem I am having with Bruce Perens' Ion
> > software, which uses libhid to access a USB HID-connected home automation
> > controller.  (See http://www.perens.com/Ion/ )
> >
> > The software uses hid_interrupt_write and and
> > hid_interrupt_read to access the controller.  I am using libhid-svn
> > (changelist 330) on a Centos 4 platform  (a redhat clone), with
> > libusb-0.1.8-3.
>
> Which kernel version does CentOS 4 use?
>
> > The software compiles without problem.  The first time it runs fine, the
> > second and subsequent times, it segfaults.  (If I run it under gdb, it
> > segafaults every second time only.)  Ion has a call to hid_interrupt_write
> > in the main function.  If I wrap this call in a function call in another
> > function, it doesn't crash, but frequently returns 21.  If I add unrelated
> > lines of code (like a new case in a switch statement that desn't do
> > anything!), it sometimes segfaults.
> >
> > I stripped down the code to the point where it writes the command to the
> > HID and then fecthes any available bytes from the output HID, in a loop
> > every 0.5 seconds (20 times). I added calls to hid_set_debug and
> > hid_set_debug_stream.  In my stripped-down version, it seems that write
> > works the first time, reads work and then the second write fails and
> > subsequent reads fail. hid_close works.  My stripped-down version doens't
> > segfault (but doesn't do anything useful!)
> >
> > My questions:
> >
> > 1)  How stable is the libhid code in SVN? (i.e. is it believed robust, or
> > highly experimental?)  No criticism implied ... I'm new around here and I
> > don't know.
>
> I would consider it stable, but then again, I don't really exercise it
> that much. The trunk is essentially a "release candidate" for 0.2.16, if
> you want to look at it that way. (I tend to make branches for things that
> might destabilize the trunk.) Also, nothing has really changed in the code
> recently - most of the changes have been to try and address shortcomings
> in the build process.
>
> A lot of what libhid does is abstraction - a determined programmer could
> replace most of the libhid calls with libusb calls one-for-one, at the
> expense of readability. The original plan (which is still being kicked
> around) was to enable programmers to use the same API but use libusb in
> Linux, Win32 calls on Windows, etc.
>
> > 2) Any suggestions as to why I might be seeing segfaults (in believed good
> > code)?
>
> Not offhand - can you post a snippet of code that shows how you are
> allocating buffers, etc.?
>
> > 3) Any idea why me second write fails? What should I be doing differently?
>
> Hard to say. See #2.
>
> --
> Charles Lepple
> clepple at ghz.cc
>
>
> _______________________________________________
> libhid-discuss mailing list
> libhid-discuss at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/libhid-discuss
>



More information about the libhid-discuss mailing list