[MEncoder-users] Mencoder involved in system crashes? WAS: DVD rip (to avi) using mencoder
Reimar Döffinger
Reimar.Doeffinger at gmx.de
Mon Dec 4 00:24:46 EET 2017
On 03.12.2017, at 20:12, Miroslav Rovis <miro.rovis at croatiafidelis.hr> wrote:
> And now, I'm actually not claiming I have issues. But only suspect there may be
> mencoder somehow involved in some of my Call Traces --not all of them, notice
> there are currently 6 opened issues at:
> https://github.com/minipli/linux-unofficial_grsec/issues
> --
>
> Not involved in all of them, but distinctly --not saying it is at fault, but
> pretty likely involved-- in today's one, the issue #21:
The fault question is trivial to answer: the kernel crashes, it's the kernel's fault. No ifs or buts involved. It's probably not what you really care about though...
> mencoder: page allocation failure: order:1, mode:0x2080024(GFP_ATOMIC|GFP_DMA32)
> https://github.com/minipli/linux-unofficial_grsec/issues/21
That SHOULD essentially mean that your system is running out of DMA memory.
It's a bit weird as 28 MB are reported as still available but maybe there are fragmentation issues or so. There should be kernel options to reserve more dma memory, which should resolve the issue from your point of view.
Now none if this is QUITE the real bug, the real bug is that the kernel driver doesn't check for allocation failure, leading to the later null pointer crash.
And then grsecurity comes in and concludes (entirely wrongly) it must have been the application's fault and blocks the user. Exemplifying why Linus doesn't want most of the grsecurity stuff anywhere near the mainline kernel...
More information about the MEncoder-users
mailing list