> 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. -- 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
