I do get some framebuffer-related kernel Oops (x86 32-bit machine). Although I have ksymoops binary available the running kernel does not provide /proc/ksyms so I cannot resolve the stacktrace. Please add this to .config for future releases. It would be fine if you also added the ksymoops package as well.
Which exact CONFIG_ options are you asking for?
I think this will be fixed when you do: -# CONFIG_DEBUG_FS is not set +CONFIG_DEBUG_FS=y Or maybe:? +CONFIG_DEBUG_INFO=y
Noted for next release, thanks for report. Before this gets added, you need to be sure those are the options needed otherwise I won't have a look for a while.
I'm not sure enabling debugging info on the DVD kernel is a good choice.
http://kerneltrap.org/sup/3648/oops-tracing.txt http://linux.derkeiler.com/Mailing-Lists/Kernel/2008-11/msg03316.html http://forum.soft32.com/linux2/Bug-411128-chkrootkit-kernel-17-proc-ksyms-ftopict71939.html http://oss.sgi.com/LDP/HOWTO/Kernel-HOWTO/kernel_files_info.html This boils down in my eyes to the problem that LiveDVD does not provide (at least after one booted into level 3, so maybe just fix /etc/fstab?): /boot/System.map-x86 /boot/System.map-nofb /boot/System.map-amd64 /boot/System.map-amd64-nofb Why ksymoops still looks for /proc/ksyms instead of /proc/kallsyms is unclear to me. Explicitly pointing ksymoops to /proc/kallsyms results in ksymoops complainig that it has the wrong format.
And, interesting reading is at http://linux.about.com/od/commands/l/blcmdl8_insmod.htm almost at the end of the text: <quote> The other problem with debugging kernel Oops in modules is that the contents of /proc/ksyms and /proc/modules can change between the Oops and when you process the log file. To help overcome this problem, if the directory /var/log/ksymoops exists then insmod and rmmod will automatically copy /proc/ksyms and /proc/modules to /var/log/ksymoops with a prefix of `date +%Y%m%d%H%M%S`. The system administrator can tell ksymoops which snapshot files to use when debugging an Oops. There is no switch to disable this automatic copy. If you do not want it to occur, do not create /var/log/ksymoops. If that directory exists, it should be owned by root and be mode 644 or 600 and you should run this script every day or so. The script below is installed as insmod_ksymoops_clean. #!/bin/sh # Delete saved ksyms and modules not accessed in 2 days if [ -d /var/log/ksymoops ] then set -e # Make sure there is always at least one version d=`date +%Y%m%d%H%M%S` cp -a /proc/ksyms /var/log/ksymoops/${d}.ksyms cp -a /proc/modules /var/log/ksymoops/${d}.modules find /var/log/ksymoops -type f -atime +2 -exec rm {} \; fi </quote>
(In reply to comment #4) > I'm not sure enabling debugging info on the DVD kernel is a good choice. I agree. @ reported, just boot with the no-framebuffer secondary kernel.
(In reply to comment #7) > (In reply to comment #4) > > I'm not sure enabling debugging info on the DVD kernel is a good choice. > > I agree. @ reported, just boot with the no-framebuffer secondary kernel. I don't but what can I do? Size does not matter, it is not much a change in vmlinuz size. Speed definitely not because one is more restricted by IO from the DVD drive.
(In reply to comment #7) > @ reported, just boot with the no-framebuffer secondary kernel. That does not work for me because X does not start. See the two attachments of bug #400621: dmesg with x86 nofb kernel, no extra options (30.69 KB, text/plain) 2012-01-25 13:57 UTC Xorg.0.log with x86 nofb kernel, no extra options (43.02 KB, text/plain) 2012-01-25 14:06 UTC
