Linux: Kernel crash debugging: BUG: scheduling while atomic

Why do you see that print
"Scheduling while atomic" indicates that you've tried to sleep somewhere that you shouldn't - like within a spinlock-protected critical section or an interrupt handler.

Things to check:

1. In this case you should check if you are actually returning from some code that could cause the lock not to be released or actually sleeping in some part of the code.

2. Another error that may be spitted out during such a crash is :
BUG: workqueue leaked lock or atomic
This clearly indicates that you were not unlocking a certain lock, which could be typically caused by returning from a routine before the lock is released.

WiFi: Difference between single and multiple protection settings in the duration ID

A single protection setting is used to protect the transmission until the end of any following data management or response frame. In multiple protection setting the NAV protects until the estimated end of multiple sequence of frames.

WiFi: One line difference between delivery enabled and trigger enabled in U-APSD

Excerpt from wikipedia:

Queues may be configured to be trigger enabled, (i.e. a receipt of a data frame corresponding to the queue acts as trigger), and delivery enabled, (i.e. data stored at those queues will be released upon receipt of a frame). Queues refer to the four ACs defined for WMM.

Linux: Where to use packed structures

Not sure if the structure should be packed or not? When to use one vs the other? What is the default behavior? What do they do?

For answering these questions, please download this PDF tutorial.

Typically this stems from the question, "what is the size of this struct"?

struct test_A
{
char a;
int b;
char c;
} x;

PDF Download

Citation:
Gautam Bhanage, "Padding versus Packing in Embedded Systems Programming", Published online at www.bhanage.com. May 2020. [PDF]

Linux: Kernel Stack Corruption

What do you do when you see a crash trace like this one?

-- snip --
task: ffffffc07d4d8000 ti: ffffffc07d4d4000 task.ti
PC is at 0xc72kf
LR is at 0xc72kf
pc : [<00000000000c70c0>] lr : [<00000000000c70c0>]
sp : ffffffc07d4d7920
x29: ffffffc07d4d7720 x28: ffffffc07d4d7a58
x27: 0000000000000001 x26: ffffffc07d477780
x25: 0000000000000001 x24: ffffffc00088f000
--snip--
 [<00000000000c70c0>] (suspected corrupt symbol)