Hi Alexander, I haven't seen this kernel panic before. <div class="gmail_quote">On Thu, Oct 21, 2010 at 11:03 AM, Alexander Todorov <<a href="mailto:atodorov@otb.bg">atodorov@otb.bg</a>> wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> This happens when I remove the device and plug-it in several times (usually after the 2nd time). I remove the HUB cable not the DisplayLink video device. </blockquote><div> Possibly a race condition, with removals/re-insertions. Does how quickly you do the re-insertion make a difference? </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Message from syslogd@sumu01 at Oct 21 21:00:39 ... kernel:EIP: [<c06f577b>] hcd_buffer_free+0x1b/0x110 SS:ESP 0068:f70d9f14 </blockquote><div> This function is is in the core USB stack. Within udlfb.c, the usb_free_coherent() call when we free urbs as the driver is tearing down, is the most likely caller that reaches hcd_buffer_free. Do you have the rest of the call stack? Maybe post more of the panic and any surrounding udlfb output from kern.log? So what we need to figure out is if this is a simple race where we pass something bad to usb_free_coherent, or if it's something more complicated related to other things that are getting torn down in the USB core stack itself when a device has just had a hardware removal. Also, can you post uname -a info? I'll try to reproduce this problem, too - might take some time, as I've done removal/arrival testing, and haven't caught this one yet. Thanks for catching and reporting this, Bernie </div></div>