A customer found their machine being hung during reboot. A vmcore was collected. The vmcore analysis shown that the reboot sequence was stuck with tasks waiting for TTY to be unlocked after Scroll Lock was pressed. The customer came back demanding a workaround. Our reply was something like "press Scroll Lock again to unlock the TTY". I wonder what comes next.

If you think working as a Senior Principal in the Kernel team is fun, think twice.

@oleksandr trying to prove @ptesarik 's point here? ;)

@oleksandr next is "but my keyboard doesn't have scroll lock!" and telling them to stop hitting C-s and try C-q. And then beer.

@ptesarik @vbabka you don't think this is the only story I've got for over 7 years on this position, do you ;)?

@vathpela What's better, we are even encouraged to prove the equivalency with a kernel source code snippet regardless of whether the customer is capable to understand it. And then beer, yes.

@oleksandr directly on the customer's keyboard, if possible.

@vathpela remote sessions are read-only, sorry

@oleksandr @vbabka One of the best stories was a kernel crash that we fully analyzed and fixed with one-liner. The customer tested and confirmed the fix, but then they refused to roll out the update, instead forcing us to write a detailed description of the exact conditions that lead to the crash, so they could mitigate them.

@vbabka @ptesarik That's something very familiar I experience on a regular basis. I bet the customers are different, but the approach to working with vendor is the same.

@oleksandr @vbabka Ah, I have realized I forgot one important point: The crash was caused by a race condition between a syscall and an external interrupt. The customer STILL preferred to roll out a workaround in all their environments…