linux-kernel - Re: Linux 3.2.19 kernel panic does not enter KDB

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120611115414.06759ae3@pyramind.ukuu.org.uk>
Date:	Mon, 11 Jun 2012 11:54:14 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	eric.valette@...e.fr
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 3.2.19 kernel panic does not enter KDB

> type of answer helps nothing. I know nobody there is going to debug 
> nvidia driver but I'm not even sure its not something else. Neither are you.
> 
> So the bug is still that KDB is not entered.

There are lots of ways kdb may not get entered on a driver crash.
This is especially true from complex DMA capable hardware than can do
anything. For a lot of stuff you'd run it under something like qemu so
you could debug that way but for graphics drivers that doesn't really
work.

So to debug it you'd start by commenting out bits of the driver code to
see if it still does it if those parts are not executed. You can't do
that with the Nvidia blob so you'll have to get Nvidia to do the work.

If it was occurring with the Nouveau driver you'd be able to comment
stuff out and try and work out which particular paths triggered the
problem.

kdb not getting entered is not itself a bug - its a limitation.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/