Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Here? [0] I'd be interested in reading the email thread of why it still panic'd, if you have it lying around.

[0] https://github.com/freebsd/freebsd/blob/master/sys/kern/kern...



That's the one.

In traditional BSD kernels, there is a portable layer and a machine dependent layer. The cpu MD layer for context switching was called cpu_switch(), usually written in assembler. It saved the current state and switched to another. When you regained control of the cpu, you returned from cpu_switch(). There was always somewhere to switch to.

When we added multiple threads per process (part of the KSE effort back in the day), a new low level construct was added - cpu_throw(). You switched somewhere else and threw away your context, didn't put the old thread in the run queue, and never returned. We used this for quickly disposing of threads.

This was all fine, thread implementations, process/thread schedulers, etc came and went.

Somewhere along the way, somebody reused the NetBSD MD/asm layer for one of the powerpc architectures. Of course, NetBSD didn't have cpu_throw(). It was #defined to cpu_switch() because it was close enough and worked.

Until somebody tried to use threading on this powerpc architecture. The fake cpu_throw() didn't prevent a return and the system got far enough to reach the upper machine independent layers and hit the panic.

This caused some amusement. Particularly as somebody had previously suggested that the panic was unnecessary as it cannot happen but I wanted to keep it anyway.


I truly love reading about situations where unreachable code became reachable, much to the astonishment of many. Thanks for that!


This thread reminds me of my experience with the "Call Brian" error code on the 1028 radon monitor:

https://news.ycombinator.com/item?id=11397251




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: