On Tue, Jul 26, 2016 at 01:42:13PM +0200, Max Staudt wrote: > On 07/25/2016 07:47 PM, Greg KH wrote: > > On Mon, Jul 25, 2016 at 07:36:15PM +0200, Max Staudt wrote: > >> Some serial ports may not emit IRQs properly, or there may be a defect > >> in their routing on the motherboard. > >> > >> This patch allows these ports to be used anyway (or until a better > >> workaround is known for a specific platform), though with no guarantees. > >> > >> If you have such a buggy UART, boot Linux with 8250.force_polling=1 . > > > > Ick, don't add new module parameters if at all possible. > > I agree, I'd rather not add a parameter either, but... > > - It's a hardware issue > - It needs to be handled at boot time Why? > - It can't be auto-detected (AFAIK) Why not? Can't you have a quirk for this specific, broken, device? > The idea is that this parameter allows for a workaround until someone comes > up with a workaround or autodetection (if ever). And it can be used to > debug future buggy hardware. module paramters are horrid, they don't scale (which uart is this for?), and no one ever changes them. > >> It is essentially the kernel level version of: > >> > >> setserial /dev/ttySn irq 0 > > > > Why can't you just do this instead? > > Because it's too late by the time we reach userspace. > > In case of "console=ttyS0" the decision to use polling needs to happen before > ttyS0 is opened from userspace, as the system will otherwise hang for up to > 30 seconds at a time. Input is mostly dropped, thus I can't even use BREAK+B > to force reboot it. > > As it stands now, I can't even boot the system with "rdinit=/bin/bash". > The force_polling option makes the system somewhat usable, albeit the serial > output is very slow. > > Curiously, the kernel's printk() is as fast as it should be. It's just > userspace that is slow. Any idea why that is the case? Ah, then something else might be wrong here, I suggest you track this down please. thanks, greg k-h -- 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
