On Thu, Jan 10, 2019 at 05:54:50PM +0200, Meelis Roos wrote:
> My HP 9000 A500 (pa-risc architecture) paniced in 5.0-rc1. It happened after printing dmesg lines about ttyS and before moving on to scsi printk-s.
> I bisected it and the panic symptoms changed during that (some had backtrace, some had just panic).
> 
> This is one of the crashes I got:
> Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
> serial 0000:00:04.0: enabling device (0146 -> 0147)
> printk: console [ttyS0] disabled
> 
> 0000:00:04.0: ttyS0 at MMIO 0xfffffffff8000000 (irq = 21, base_baud = 115200) is a 16550A
> printk: console [ttyS0] enabled
> printk: console [ttyS0] enabled
> printk: bootconsole [ttyB0] disabled
> printk: bootconsole [ttyB0] disabled
> 0000:00:04.0: ttyS1 at MMIO 0xfffffffff8000008 (irq = 21, base_baud = 115200) is a 16550A
> 0000:00:04.0: ttyS2 at MMIO 0xfffffffff8000010 (irq = 21, base_baud = 115200) is a 16550A
> serial 0000:00:05.0: enabling device (0140 -> 0143)
> 0000:00:05.0: ttyS3 at MMIO 0xfffffffff8005000 (irq = 22, base_baud = 115200) is a 16550A
> Backtrace:
>  [<0000000040502268>] pciserial_init_ports+0x128/0x240
>  [<00000000405040b8>] pciserial_init_one+0x1e0/0x2f0
>  [<00000000404b2b8c>] pci_device_probe+0xfc/0x180
>  [<0000000040513958>] really_probe+0x268/0x3d0
>  [<0000000040513d28>] driver_probe_device+0xf8/0x100
>  [<0000000040513e54>] __driver_attach+0x124/0x130
>  [<0000000040510dc4>] bus_for_each_dev+0x9c/0xe8
>  [<0000000040513040>] driver_attach+0x28/0x38
>  [<00000000405128c0>] bus_a
> 
> Normal dmesg excerpt from working kernel before the problem:
> 
> [    6.746131] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
> [    6.771772] serial 0000:00:04.0: enabling device (0146 -> 0147)
> [    6.792657] printk: console [ttyS0] disabled
> [    6.829825] 0000:00:04.0: ttyS0 at MMIO 0xfffffffff8000000 (irq = 21, base_baud = 115200) is a 16550A
> [    6.837151] printk: console [ttyS0] enabled
> [    6.877768] printk: bootconsole [ttyB0] disabled
> [    6.904352] 0000:00:04.0: ttyS1 at MMIO 0xfffffffff8000008 (irq = 21, base_baud = 115200) is a 16550A
> [    6.961051] 0000:00:04.0: ttyS2 at MMIO 0xfffffffff8000010 (irq = 21, base_baud = 115200) is a 16550A
> [    6.969881] serial 0000:00:05.0: enabling device (0000 -> 0003)
> [    7.004160] serial 0000:00:05.0: enabling SERR and PARITY (0003 -> 0143)
> [    7.030298] 0000:00:05.0: ttyS3 at MMIO 0xfffffffff8005000 (irq = 22, base_baud = 115200) is a 16550A
> [    7.041663] serial 0000:00:05.0: Couldn't register serial port 0, irq 22, type 2, error -28
> [    7.145456] sym53c8xx 0000:00:01.0: enabling device (0000 -> 0003)
> 
> 
> Bisection leads to this commit:
> 
> 6d7f677a2afa1c82d7fc7af7f9159cbffd5dc010 is the first bad commit
> commit 6d7f677a2afa1c82d7fc7af7f9159cbffd5dc010
> Author: Darwin Dingel <darwin.dingel@alliedtelesis.co.nz>
> Date:   Mon Dec 10 11:29:09 2018 +1300
> 
>     serial: 8250: Rate limit serial port rx interrupts during input overruns
> 
>     When a serial port gets faulty or gets flooded with inputs, its interrupt
>     handler starts to work double time to get the characters to the workqueue
>     for the tty layer to handle them. When this busy time on the serial/tty
>     subsystem happens during boot, where it is also busy on the userspace
>     trying to initialise, some processes can continuously get preempted
>     and will be on hold until the interrupts subside.
> 
>     The fix is to backoff on processing received characters for a specified
>     amount of time when an input overrun is seen (received a new character
>     before the previous one is processed). This only stops receive and will
>     continue to transmit characters to serial port. After the backoff period
>     is done, it receive will be re-enabled. This is optional and will only
>     be enabled by setting 'overrun-throttle-ms' in the dts.
> 
>     Signed-off-by: Darwin Dingel <darwin.dingel@alliedtelesis.co.nz>
>     Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> 
> :040000 040000 4ea6cd68ededa0c9ffaa218668ffeb35557070a5 a011db1916fbf5cfdcfff836a81e4fb5ee737003 M      drivers
> :040000 040000 b1b1dc977965eb2db6b2cc79939446a1cf2f684d 41322ab1c199f504cfcc5b2ca211b4638d41351c M      include

The patch below was just applied to my tree, hopefully ti fixes this
issue.

thanks,

greg k-h