On (03/06/19 23:43), John Ogness wrote: > > Sounds like another aurgment for the new printk design. > > Assuming the bad checksum messages are considered an emergency (for > example, at least loglevel KERN_WARN), then the new printk design would > print those messages synchronously to the slow serial line in the > context of the driver as the driver is producing them. I wonder if we have several CPU doing the checksum verification. New sync printk mechanism has a Big-Konsole-spin-Lock, all CPUs that want to printk() should line up and wait, in whatever context they currently are. > There wouldn't be a lock-up, but it would definitely slow down the > driver. The situation of "messages being produced faster than the kernel > can write them" would never exist because the printk() call will only > return after the writing is completed. If the serial console is a really slow one and we have a CPU in atomic context spinnig on prb_lock, while the prb_lock is always acquired by other CPUs, then it may look like a lock-up scenario. -ss
