The real realtime preemption end game

Posted Nov 16, 2023 14:17 UTC (Thu) by grawity (subscriber, #80596)
Parent article: The real realtime preemption end game

> printk(), Gleixner said, is fully synchronous in current kernels; a call will not return until the message has been sent to all of the configured destinations.

I remember when I was managing a large Linux-based gateway, and I configured serial console (over IPMI), and later I added some iptables LOG rules, and it turned out that just a few matching packets per second would DoS it because it wasn't processing any packets while waiting for each log message to go out through ttyS1...

to post comments

The real realtime preemption end game

Posted Nov 17, 2023 1:30 UTC (Fri) by areilly (guest, #87829) [Link] (2 responses)

I remember a microVax that I used as an undergrad that had a real teletype set up as the (serial) console. Had the effect of (a) rebooting the machine if it was ever accidentally turned off, and (b) halting the machine whenever it ran out of paper. I was always amazed that the Ultrix would keep going as though nothing had happened as soon as more paper was loaded and it was put back on line.

The real realtime preemption end game

Posted Nov 17, 2023 5:51 UTC (Fri) by donald.buczek (subscriber, #112892) [Link] (1 responses)

Nothing tops the feeling when a bugcheck on vax/vms system causes all these hex dumps to be printed slowly and noisily to the paper of your hardcopy console. Physical printout and slowness signifies importance while stackdumps with hex values signify secret knowledge. This is not for mortals.

The real realtime preemption end game

Posted Nov 17, 2023 6:23 UTC (Fri) by donald.buczek (subscriber, #112892) [Link]

Oh, and of course everybody had to wait for you, while you carefully read through the secret scripture, which nobody but you could understand, until you decide to enter "b <ret>", which initiated thr printing of another few pages of startup messages during the next 10 minutes :-)