Hi Ingo, On 01/26/2017 03:19 PM, Ingo Molnar wrote: > * Lu Baolu <baolu...@linux.intel.com> wrote: > >> Fair enough. >> >> USB connection is stable enough, unless the user unplugs the >> USB cable during debugging. > What does the hardware do in this case? The XHCI registers are in the host > hardware, so they won't disappear, right? Is there some cable connection > status > bit we can extract without interrupts?
Yes, there are register bits for us to know the cable status. I will go through the spec again and give you more accurate answer later. I'm sorry. I will be off during the next 7 days for Chinese New Year holiday. My email access will be very limited during this time. I will revisit this thread after I am back from holiday. Sorry for the inconvenience. Best regards, Lu Baolu > I.e. if there's any polling component then it would be reasonable to add an > error > component: poll the status and if it goes 'disconnected' then disable > early-printk > altogether in this case and trigger an emergency printk() so that there's > chance > that the user notices [if the system does not misbehave otherwise]. > > I.e. try to be as robust and informative as lockdep - yet don't lock up the > host > kernel: lockdep too is called from very deep internals, there are various > conditions where it sees corrupt data structures (i.e. a 'disconnect' - a > system > environment outside the normal bounds of operation), yet of the kernel and > over > the last 10+ years of lockdep's existence we had very, very few cases of > lockdep > itself locking up and behaving unpredictably. > > Thanks, > > Ingo >
