On Thursday 16 September 2004 11:05 am, Christoph Torens wrote: > > That's usually a sign of the driver not handling the hardware > > correctly, so that the extra delays caused by kernel printk > > change the driver timings enough to dodge a race... > > So, I have tested a few things, I removed the debug messages one by > one and now I have isolated the one that causes the working or not > working of the driver. What can I do next? > > The debug message is in the function: hci_submit_urb > I guess this means this function is buggy.
Maybe not -- but that's a nice precise clue to have. > But I have absolutely no idea what to do. > And if it's a timing problem with these debug messages, how could this be > fixed anyway? The problem is evidently that adding a delay in that routine makes the timings work. It's your job to find out why. What are the relevant timings? Does replacing the printk with mdelay(1) make it work? mdelay(10)? 100? 1000? 5000? - Dave ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
