Hi 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. thanks. On Fri, Jan 30, 2015 at 11:52 PM, George Spelvin <linux@xxxxxxxxxxx> 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 > me 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 if > SysRq is received (before the following action character is received > and must be acted on). -- 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
