Philips srm7500 being initialized twice on 0.9.2a and newer

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Philips srm7500 being initialized twice on 0.9.2a and newer

Juan Manuel Santos



I've recently built a new box to use as HTPC and having some issues using lirc-0.9.2a (the same issue still happens

on 0.9.3, I've just been debugging this more on 0.9.2a). My remote is a Philips SRM7500 (yeah, the srm7500 guy, that's me :).


Software versions:


- lirc-0.9.2a

- libusb-1.0.19

- libusb-compat-0.1.5

- kernel 4.5.0 (gentoo sources)


I previously had this working with these same package versions on kernel 3.18 (gentoo sources too).

The problem happens when trying to connect a client (irw in this case, but breaks the same with Kodi).

Here is what I get in the logs (had to put all up in a public paste since otherwise I'd go over the max

message size for the mailing list):


Some 30 seconds pass and then the USB receiver is initialized a second time

('initializing Philips USB receiver'). After that, every two seconds I get the device or resource busy.


Looking at 0.9.2a source, I see the error comes from the second if highlighted here:


(Note: I previously reported an issue here in this mailing list for the detach kernel driver if).


srm7500_initialize_usbdongle() gets called from this while in srm7500_init():


If srm7500_initialize_802154_stack() fails, the while executes again and the dongle is tried to

be initialized a second time (thus causing the second print on the logs and the subsequent errors). This

is wrong I believe but I'll leave that as an excercise for the more-profficient-than-me devs :)


I've been doing some gdb today and found that the first thread/run (the one that prints

'initializing Philips[...]' for the first time) is not triggering the 'goto fail'.

So, on that first thread/run, it then goes on to srm7500_initialize_802514_stack(), which

appears to be the one failing here. In that function, the only place I can see where 0 is

returned without a log message printed is at the very beginning:



which if this takes ~30 seconds, is where we're exiting here. This happens because the function

philipsrf_input has an usb_interrupt_read with USB_TIMEOUT:


and USB_TIMEOUT is 10 seconds (and is tried 3 times in initialize_802154_stack()):


#define USB_TIMEOUT (1000*10)


Did I get things right here so far? Any help here in debugging will be greatly appreciated, and/or I'm

also available to do some testing since I have the hardware.


Juan Manuel Santos <[hidden email]>


Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.

signature.asc (836 bytes) Download Attachment