| Summary: | =sys-fs/udev-197-r8 with Linux 3.7.x - systemd-udevd causes page allocation failures at bootup | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | ernsteiswuerfel <erhard_f> |
| Component: | [OLD] Core system | Assignee: | udev maintainers <udev-bugs> |
| Status: | VERIFIED WORKSFORME | ||
| Severity: | normal | CC: | god, gregkh |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | logfiles | ||
|
Description
ernsteiswuerfel
2012-12-12 21:33:07 UTC
Created attachment 332170 [details]
logfiles
Ok, finally I got some more time to test this out. I noticed that a standard kernel built with genkernel does not show these page allocation failures. So I systematically changed the kernel .config until I got my custom kernel right... It turned out that it was a single option causing these 'systemd-udevd: page allocation failure': KALLSYMS [=y] General setup ---> Configure standard kernel features (expert users) ---> Load all symbols for debugging/ksymoops [=y] Setting it to [=n] -> pagefaults, setting it to [=y] -> no pagefaults. I did not know that KALLSYMS is important for udev at all. As previously said I can't tell when I got these errors exactly, but I've been using this kernel config since 3.0, updating it with make oldconfig. And I am sure at that time I did not get these errors. Seems the problem is caused by some kernel <-> udev interaction. Any suspicious udev-activity lately, concerning KALLSYMS? No, there is nothing going on in this area that I know of. Can you please upgrade to 197-r3 and report back whether this is still happening? Upgraded to 197-r3 and kernel 3.7.4 and the issue still persists in the same way. If your kernel has CONFIG_EXPERT=y then you also need CONFIG_KALLSYMS=y Or use CONFIG_EXPERT=n $ zgrep EXPERT /proc/config.gz $ grep EXPERT /usr/src/linux/.config Let us know if this was the case. Thanks. Closing TEST-REQUEST then pending on reply to last Comment #5 $ grep EXPERT /usr/src/linux/.config CONFIG_EXPERT=y $ grep KALLSYMS /usr/src/linux/.config # CONFIG_KALLSYMS is not set (In reply to comment #7) > $ grep EXPERT /usr/src/linux/.config > CONFIG_EXPERT=y > $ grep KALLSYMS /usr/src/linux/.config > # CONFIG_KALLSYMS is not set looks like unworking combo... At least on my machine(s) it certainly is. However as said in Comment #5 this was not always the case. Check added to -r6 and 9999 I'm reopening this, as there is NOTHING in the systemd-197 source that reads kallsyms. I've CC'd gregkh as maybe he has some insight into it. I have had EXPERT=y and KALLSYMS=n (using the same config) for over a year with different kernel versions (using 3.8-rc7 now) and never seen such thing in my dmesg. I've also just checked 2 other systems of mine (with EXPERT=y & KALLSYMS=n) with gentoo-sources-3.7.8 and 3.8-rc7 respectively and none of them shows this. As we discussed on IRC, (and per what Robin says in comment 11) I'd agree to drop this check as OP might be the only one having this issue for some reason. I think, I do not know, I may be having the same issue. I get a kernel panic just after the boot process switches to a frame buffer. I normally backup to a 16G USB thumbdrive. When I remove the thumbdrive, boot process is fine. When I leave it in, kernel crashes as it can not seem to find the root partition. No entries in the message log. Process is repeatable on a six-core AMD every time a boot is attempted, and sometimes on an Intel I7. When I remove all thumb drives on boot, which I have not done in the past,no boot issues. When searching the config file # CONFIG_EXPERT is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y Rebuild using 3.7.9 release. Kernel panics with a USB drive in a port during boot, remove the drives boot is fine. Bit more info. panic arch/x86/kernel/smpc 123 update_process_times +0x56/0x62() warn /slowpath/common Transfered my kernel .config from 3.7.9 to 3.8.2 via oldconfig and recompiled. Now the page allocation failures are gone on this machine, despite # CONFIG_KALLSYMS is not set good, and with 3.7 marked EOL at kernel.org, I think it's safe to close this one now |
