Linux-rt-users archive on lore.kernel.org
 help / color / Atom feed
* Crash tool issue since printk re-implementation
@ 2020-02-12 12:10 Sebastien Fabre
  2020-02-14 12:34 ` Sebastian Andrzej Siewior
  0 siblings, 1 reply; 4+ messages in thread
From: Sebastien Fabre @ 2020-02-12 12:10 UTC (permalink / raw)
  To: linux-rt-users

Hello,

Since kernel v5.0, PREEMPT_RT patches contain printk re-implementation. This re-implementation removes some log symbols in 
VMCOREINFO and crash tool cannot retrieve kernel logs (because symbols no more exist).
Is this impact on crash expected? If so, how can we retrieve a functional crash tool with kernel v5.0 (and following) ?

Thanks,
Fabre Sebastien

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Crash tool issue since printk re-implementation
  2020-02-12 12:10 Crash tool issue since printk re-implementation Sebastien Fabre
@ 2020-02-14 12:34 ` Sebastian Andrzej Siewior
  2020-02-14 13:42   ` John Ogness
  0 siblings, 1 reply; 4+ messages in thread
From: Sebastian Andrzej Siewior @ 2020-02-14 12:34 UTC (permalink / raw)
  To: Sebastien Fabre; +Cc: linux-rt-users, John Ogness

On 2020-02-12 12:10:23 [+0000], Sebastien Fabre wrote:
> Hello,
Hi,

> Since kernel v5.0, PREEMPT_RT patches contain printk re-implementation. This re-implementation removes some log symbols in 
> VMCOREINFO and crash tool cannot retrieve kernel logs (because symbols no more exist).
> Is this impact on crash expected? If so, how can we retrieve a functional crash tool with kernel v5.0 (and following) ?

It is known, yes. I'm aware of crash and the gdb scritps should also
suffer from this. 
I'm not sure anyone took a look at it (yet) and I don't think that the
`crash' tool will accept the patches unless final printk rework is
merged upstream.

> Thanks,
> Fabre Sebastien

Sebastian

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Crash tool issue since printk re-implementation
  2020-02-14 12:34 ` Sebastian Andrzej Siewior
@ 2020-02-14 13:42   ` John Ogness
  2020-02-14 14:11     ` Gene Heskett
  0 siblings, 1 reply; 4+ messages in thread
From: John Ogness @ 2020-02-14 13:42 UTC (permalink / raw)
  To: Sebastian Andrzej Siewior; +Cc: Sebastien Fabre, linux-rt-users\

On 2020-02-14, Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
> On 2020-02-12 12:10:23 [+0000], Sebastien Fabre wrote:
>> Since kernel v5.0, PREEMPT_RT patches contain printk
>> re-implementation. This re-implementation removes some log symbols in
>> VMCOREINFO and crash tool cannot retrieve kernel logs (because
>> symbols no more exist).  Is this impact on crash expected? If so, how
>> can we retrieve a functional crash tool with kernel v5.0 (and
>> following) ?
>
> It is known, yes. I'm aware of crash and the gdb scritps should also
> suffer from this. 

Perhaps this should be listed under the "Known issues" of the PREEMPT_RT
release announcements.

John Ogness

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Crash tool issue since printk re-implementation
  2020-02-14 13:42   ` John Ogness
@ 2020-02-14 14:11     ` Gene Heskett
  0 siblings, 0 replies; 4+ messages in thread
From: Gene Heskett @ 2020-02-14 14:11 UTC (permalink / raw)
  To: linux-rt-users

On Friday 14 February 2020 08:42:57 John Ogness wrote:

> On 2020-02-14, Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
> > On 2020-02-12 12:10:23 [+0000], Sebastien Fabre wrote:
> >> Since kernel v5.0, PREEMPT_RT patches contain printk
> >> re-implementation. This re-implementation removes some log symbols
> >> in VMCOREINFO and crash tool cannot retrieve kernel logs (because
> >> symbols no more exist).  Is this impact on crash expected? If so,
> >> how can we retrieve a functional crash tool with kernel v5.0 (and
> >> following) ?
> >
> > It is known, yes. I'm aware of crash and the gdb scritps should also
> > suffer from this.
>
> Perhaps this should be listed under the "Known issues" of the
> PREEMPT_RT release announcements.
>
> John Ogness

I would like to agree, as I think that explains why an attempt to build 
5+ in this preempt-rt flavor, on an rpi4, for an rpi4 has been a no boot 
failure. 

Plus it appears I'd have to replace the bootloader because raspian puts 
the overlays in a /boot/overlays subdir whereas you are putting them 
in /boot (I think, I haven't found the .config magic twanger that puts 
them in the overlays subdir.)

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, back to index

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-12 12:10 Crash tool issue since printk re-implementation Sebastien Fabre
2020-02-14 12:34 ` Sebastian Andrzej Siewior
2020-02-14 13:42   ` John Ogness
2020-02-14 14:11     ` Gene Heskett

Linux-rt-users archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-rt-users/0 linux-rt-users/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-rt-users linux-rt-users/ https://lore.kernel.org/linux-rt-users \
		linux-rt-users@vger.kernel.org
	public-inbox-index linux-rt-users

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-rt-users


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git