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

Hello,

 

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):

 

https://bpaste.net/show/d7c075aebe6e

 

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:

 

https://bpaste.net/show/504fcbf2dc6b

 

(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():

 

https://bpaste.net/show/b76a6a1b102b

 

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:

 

https://bpaste.net/show/c9639052155c

 

 

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:

 

https://bpaste.net/show/cc7291840af5

 

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]>

Pubkey: www.vicarious.com.ar/~godlike/godlike64.at.gmail.dot.com.asc


------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140

signature.asc (836 bytes) Download Attachment