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:
"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 < '0' && p > '9')
+ return 0;
That looks like something to fix in the dumping code:
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
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:
Seems the KERN_CONT route is how they went.
changed in git to use that version. also added to f15/f16.
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.