gwes <g...@oat.com> wrote: > On 5/25/21 10:26 AM, Theo de Raadt wrote: > > Alexander Bluhm <alexander.bl...@gmx.net> wrote: > > > >> On Tue, May 25, 2021 at 04:15:26PM +0200, Mark Kettenis wrote: > >>> Wouldn't be too hard. But unless you're on a serial console, that > >>> will probably be more than a screenful of information, so not terribly > >>> useful. > >> The most important things must fit on the first VGA screen. Then > >> user can make a photo. We ship products to customers who only > >> understand this simple step. And when the machine panics, the admin > >> might also panic. > > Matches my experience. > > > > It will be very difficult to show state of multiple cpus on a small > > screen. On the other hand, only showing the first-panic can hide so > > much. These garbled reports are actually highlighting a not-simple > > case. There is big information in the garble. > > > Jumping in, sorry, > > Some sort of pseudo-ordering where each CPU -mostly- gets to put out > more than one character at a time - 2, 3, ... one line max? > No guaranteed separation/ordering but might make decipherment easier. > > No communication or dependence between CPUs needed. > > Each CPU backs off for a -very- short time after N characters. > Nanoseconds or microseconds should work. Initial delay M * CPU ? > Spin after N? If clock is ticking, spin for x ticks? > Formatting/output time per burst could (maybe) give a little fairness. > > Apologies if this is nonsense or has been covered already.
That is not the kind of code you want anywhere near the "heading to ddb" situation. We are heading to ddb because something in the 'software machine state' is busted. We need to rely upon FEWER COMPONENTS still operating normally, not more!
