On 05/01/2015 04:45 PM, George Spelvin wrote: >> But let's back up and look at this from a system perspective. >> >> Incoming rx over this port is just one of a long list of interrupts >> not being serviced during a printk(). What about all the other serial >> ports that aren't being serviced? Are we not concerned about those >> overruns? >> >> What about all the other system devices that aren't seeing >> their interrupts serviced either? > > I thought about that. That used to be a problem, but these > days there are other processors servicing those other interrupts. > > Ever since SMP got popular, I'm used to seeing deadlock problems > on apparently working systems. As long as the lock is "unpopular", > only one or two processors are fighting over it and the rest are > just printing NMI watchdog errors. > > The serial receive is unique because it's actually disabled by console > printk. > > > As I said, a few months ago, I couldn't figure out how to do it > cleanly enough for you, got discouraged, and the issue got swapped out. > But having just picked it up again, I think I have an idea I'd like you > to look at. It's described in yesterday's e-mail that I'd appreciate > your comments on, or you can wait until I have a patch. Hi George, I just haven't had the time to review that yet, sorry. I will get to it. Regards, Peter Hurley -- 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
