(Responding to two messages with one here) Prasad Koya <prasad.koya@xxxxxxxxx> wrote: > Just wanted to know where we stand on this patch. The issue is clearly > present and we are dealing with the dropped chars in our testing > infrastructure since the days of 2.6.32. Well, I cleaned it up to something I thought was decent. As I commented earlier I'm still a bit uncertain about dropping the lock when flipping the buffer to the line discipline, but if that's a bug this patch doesn't make it any worse, and fixing it should be a separate patch anyway. On Tue, 17 Feb 2015 at 14:03, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > I don't see a patch here, sorry, what are you talking about? The patch which was presented earlier in this thread. I thought the original was ugly and proposed a version that I thought was cleaner, which led to the following exchange with you that Presad just reposted: On Fri, Jan 30, 2015 at 23:52, George Spelvin <linux@xxxxxxxxxxx> wrote: > On Fri, 30 Jan 2015 at 15:21, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: >> I hate functions that have "bool" variables like this, it's a mess and >> can cause them to do different things so you always have to look up the >> details. > > Agreed, but it was a magic flag in a structure before I made > it explicit like that, so I think it's a big improvement. > > I think I improved the original maintenance nightmare of a patch, > but I'd be delighted fo have someone with a broader understanding > of the code clean it up even more. >> Why isn't this a problem with other uarts and slow baud rates? Why >> hasn't this problem ever been reported in the past for other uarts? Is >> this really the best/only way to solve this? > > The root cause is the emergency console output feature which uses > the UART with interrupts disabled. UARTs which don't support > that don't have the issue. > > Console output can be long, and the input FIFO can overflow in the > meantime. The designers of the feature assumed the UART would > be dedicated as a console, so would not be receiving much input. > > However, here we have a use case that does have significant input. > > The change is to poll for input while polling for output. > > However, this leads to a potential deadlock. Most output can simply > be blocked for the diration of the emergency print. However, a SysRq > also uses the same emergency console output feature, so there's > a re-entrancy problem. > > This code takes the simple approach of halting input polling after > SysRq is received (before the following action character is received > and must be acted on). That response of mine, which was basically "yeah, it's not great, but it's the best I could do" elicited no further response for a few weeks, so Prasad re-pinged. -- 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
