On Sat, Oct 8, 2011 at 1:49 AM, Jiri Slaby <jirislaby@xxxxxxxxx> wrote: > I cannot reproduce this. What uart driver is this with? And where does > it call uart_suspend_port from? Basically, it would mean that it calls > uart_suspend_port while userspace is still running? Or who HUPs the port > (the second point in your list)? Thank you for testing! I am working with the 8250 driver controlling the onboard UART on an nVidia Tegra T25 (ARM). You raise very good questions, and I'm happy to keep tracking down to continue to look for a deeper root cause. I continued to do some more testing of this patch (with the help of a few others) after posting the list. We tried the same setup on an x86-based board and the HUP doesn't show up. ...so my patch wasn't needed on that board (although my patch didn't hurt). ...that means, as you already pointed out, that the HUP must _not_ be coming from userspace. Probably the true bug in my system is that a spurious HUP is being generated as a result of the suspend. That is probably platform dependent and would explain why this hasn't been a bigger problem for others. ...however, even though my patch shouldn't be needed for any hardware that doesn't generate the spurious HUP, it might still be worthwhile to consider including it? ...or perhaps changing it to a BUG_ON or WARN_ON to at least detect the case of running the shutdown code after the suspend code? Definitely the case that I ran into (shutdown after suspend) will definitely cause a crash during resume. I will spend time on Monday digging into the source of the HUP and will post a followup. -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
