Thread (24 messages) flat view 24 messages, 7 authors, 2017-09-20

Re: [PATCH 0/5] [RFC] printk/ia64/ppc64/parisc64: let's deprecate %pF/%pf printk specifiers

From: Helge Deller <deller@gmx.de>
Date: 2017-09-19 14:07:52
Also in: lkml

On 19.09.2017 04:05, Sergey Senozhatsky wrote:
On (09/18/17 20:39), Helge Deller wrote:
quoted
I did tried your testcases [on parisc] too.
...
quoted
and here is "modprobe zram":
  printk#7 __UNIQUE_ID_vermagic8+0xb9a4/0xbd04 [zram]
  printk#8 __UNIQUE_ID_vermagic8+0xb9a4/0xbd04 [zram]
  printk#9 do_one_initcall+0x194/0x290
  printk#10 do_one_initcall+0x194/0x290
  printk#11 do_one_initcall+0x194/0x290
  printk#12 do_one_initcall+0x194/0x290
  printk#13 zram_init+0x22c/0x2a0 [zram]
  printk#14 zram_init+0x22c/0x2a0 [zram]
  printk#15 zram_init+0x22c/0x2a0 [zram]
  printk#16 zram_init+0x22c/0x2a0 [zram]

I wonder why printk#7 and printk#8 don't show "zram_init"...
interesting... what does the unpatched kernel show?
Really strange.
The unpatched kernel shows __UNIQUE_ID_vermagic8+0xb9a4/0xbd04 too.
The symbol should be known, because later on in printk13 it shows correctly zram_init.
I'll need to dig deeper into it, but at least the regression is not due
to your patch.

Helge
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help