Hi, I am trying to write a (USB, network) device for Linux 2.4.20, and it works fine *unless* I make a certain kind of control request to the USB stack. As soon as I do this, my box is doomed to perish in the fires of Memory Corruption within the next few minutes. (Nearly all the oopsen fault in kmalloc.) Now one scenario is that there's a bug in the 2.4.20 OHCI controller. However, there is another scenario which occurs to me... The USB device that I am driving has notoriously buggy firmware and it is very possible that all that this USB control request is really doing is making the adapter unresponsive for a second or two. This in turn allows the timers on my URBs to start expiring and hence run my timeout code. I do indeed see indications in my log that OUT requests did not complete and were timed out. The problem is that there's so much else happening at this point that only a 100% healthy kernel could survive anyway. I have examined my timeout code very carefully and I can't see anything (any more) that might corrupt memory, unless there are certain functions which I MUST NOT call within a timer callback function? I know that I mustn't schedule or block, and I don't think that I am. (Except for a spinlock.) Of course, I'm not sure which kernel functions might schedule indirectly either ... Can printk schedule, for example? I *am* setting the ASYNC_UNLINK flag when unlinking the URBs. How does the kernel run timer functions? Does it wait for a hardware IRQ to arrive, and then run every timeout function on its list which has expired? If so then would this mean that no two timer functions can run concurrently, but that a timer function can "preempt" process-context code? Such pre-emption would imply that I must not call non-reentrant functions from the timer: are there any that I should know about? Also, is there any way to temporarily "mask" a timer without deleting it, c.f. sigprocmask() and POSIX signals? Any advice appreciated here, Thanks, Chris __________________________________________________ Yahoo! Plus For a better Internet experience http://www.yahoo.co.uk/btoffer -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
