Sometimes the code dump in kernel oops reports gets truncated, like this: Code: 31 c0 5d c3 55 48 89 e5 41 54 53 66 66 66 66 90 41 89 d4 48 89 fb 41 c1 e4 09 85 f6 75 0a 44 3b 67 30 0f 84 d1 00 00 00 48 63 c6 There should be a 1-byte insn value in braces, like <30>, followed by more plain values. Other times the entire line is shown: Code: e5 66 66 66 66 90 b8 00 00 01 00 f0 0f c1 07 0f b7 d0 c1 e8 10 39 c2 74 07 f3 90 0f b7 17 eb f5 5d c3 55 48 89 e5 66 66 66 66 90 <8b> 07 89 c2 c1 c0 10 39 c2 8d 90 00 00 01 00 75 04 f0 0f b1 17 It seems to depend on the value in the brackets. Looks like this is caused by: commit 9d90c8d9cde929cbc575098e825d7c29d9f45054 "printk: do not mangle valid userspace syslog prefixes" This part of that patch looks wrong, but that may not be the whole story: + if (p[1] < '0' && p[1] > '9') + return 0;
That looks like something to fix in the dumping code: arch/x86/kernel/dumpstack_64.c printk("<%02x> ", c); Printk lines are not allowed to start with the syslog prefix <number>. It only worked in earlier versions because the kernel supported single digits only, which probably nobody has enclosed in <>. I guess the separating ' ' between the fields in the output loop needs to be moved to prefix the line and not be appended, so that the printk parser does not detect a level prefix. Alternatively it might be sufficient to add KERN_INFO in front, so that a valid prefix is always there and gets stripped by printk.
But this isn't at the start of a line. The start of the line is "<KERN_EMERG> Code: "
The current (simple) implementation of printk() does not have a concept of a new line for the input, only for the output. The syslog prefix is checked with every invocation of printk(). It was like that before the above mentioned change already, it's just that nobody ever printed '<[0-9]>' and expected it to show up in the log. Now with the (proper) multi-digit support it seams to eat the <[0-9][0-9]> matches. The newline logic in printk is a global variable, so any other user finish the line in-between multiple printk()s. I guess the best option is to change the caller to print with a leading ' '?
There is also the KERN_CONT prefix magic, which might just do the right thing here.
I'll change it to use leading spaces, that looks easy enough to do.
I've put a fix in rawhide for now.
This looks like it's been fixed upstream: http://git.kernel.org/?p=linux/kernel/git/tip/tip.git;a=commitdiff;h=13f541c10b30fc6529200d7f9a0073217709622f Seems the KERN_CONT route is how they went.
changed in git to use that version. also added to f15/f16.
[mass update] kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository. Please retest with this update.