Linux 3.2.19 kernel panic does not enter KDB

Linux 3.2.19 kernel panic does not enter KDB

[Eric Valette]

Hi,

I'm currently chasing a kernel panic (dual keyboard led actually 
blinking) when playing HD using XBMC on a debian unstable X86_64 
distribution.

I'm stuck with 3.2.X kernel line until maintainer of dvbhdhomerun 
integrates 3.3 DVB api changes.

I'm stuck to nvidia 302.x because this is the only nvidia driver version 
that supports xrandr and XBMC does not support nvidia proprietary 
protocol that replaces xrandr for refresh rate selection...

Its probably dues to a bad interaction between nvidia driver/vdpau/XBMC 
because VLC can play same content without panicking but with vaapi 
acceleration API instead of VDPAU.

I have a working KGDB/KDB setup (at least hitting ALT SYST q on a tty 
show KDB help). I still get the blinking led without entering KDB. When 
video freeze, I get the a fix video image, a audio loop and the blinking 
leds but cannot get access to KDB console. Any hint?

PS: please CC me I'm not subscribed.

--eric

Re: Linux 3.2.19 kernel panic does not enter KDB

[Alan Cox]

On Sun, 10 Jun 2012 13:22:35 +0200
Eric Valette <eric.valette@free.fr> wrote:

> Hi,
> 
> I'm currently chasing a kernel panic (dual keyboard led actually 
> blinking) when playing HD using XBMC on a debian unstable X86_64 
> distribution.
> 
> I'm stuck with 3.2.X kernel line until maintainer of dvbhdhomerun 
> integrates 3.3 DVB api changes.
> 
> I'm stuck to nvidia 302.x because this is the only nvidia driver version 
> that supports xrandr and XBMC does not support nvidia proprietary 
> protocol that replaces xrandr for refresh rate selection...
> 
> Its probably dues to a bad interaction between nvidia driver/vdpau/XBMC 
> because VLC can play same content without panicking but with vaapi 
> acceleration API instead of VDPAU.
> 
> I have a working KGDB/KDB setup (at least hitting ALT SYST q on a tty 
> show KDB help). I still get the blinking led without entering KDB. When 
> video freeze, I get the a fix video image, a audio loop and the blinking 
> leds but cannot get access to KDB console. Any hint?

I think you are on the wrong list. Nvidia have kernel source code, we
don't have code to their proprietary stuff. Only they can help you.

It's quite possible the box is hanging so hard that kdb can't help you.
In that case you'll again need someone with their proprietary Nvidia
source to help you.

Alan

Re: Linux 3.2.19 kernel panic does not enter KDB

[Eric Valette]

On 10/06/2012 13:34, Alan Cox wrote:

>
> I think you are on the wrong list. Nvidia have kernel source code, we
> don't have code to their proprietary stuff. Only they can help you.
>
> It's quite possible the box is hanging so hard that kdb can't help you.
> In that case you'll again need someone with their proprietary Nvidia
> source to help you.

Maybe you are still annoyed by the picture linus has posted but that 
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.

--eric

Re: Linux 3.2.19 kernel panic does not enter KDB

[richard -rw- weinberger]

On Sun, Jun 10, 2012 at 1:38 PM, Eric Valette <eric.valette@free.fr> wrote:
> On 10/06/2012 13:34, Alan Cox wrote:
>
>>
>> I think you are on the wrong list. Nvidia have kernel source code, we
>> don't have code to their proprietary stuff. Only they can help you.
>>
>> It's quite possible the box is hanging so hard that kdb can't help you.
>> In that case you'll again need someone with their proprietary Nvidia
>> source to help you.
>
>
> Maybe you are still annoyed by the picture linus has posted but that 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.

The problem with proprietary code is that *anything* can happen.
If the crash happened within the Nvidia binary blob you are toasted...

-- 
Thanks,
//richard

Re: Linux 3.2.19 kernel panic does not enter KDB

[Eric Valette]

On 10/06/2012 14:37, richard -rw- weinberger wrote:

>> So the bug is still that KDB is not entered.
>
> The problem with proprietary code is that *anything* can happen.
> If the crash happened within the Nvidia binary blob you are toasted...
>

Yes. I just want to be sure it is the case. Even if display it dead, I 
expect that keyboard may help to reboot, sync disk but unless I dot not 
hit the correct key sequence it doesn't.

--eric

Re: Linux 3.2.19 kernel panic does not enter KDB

[Alan Cox]

> 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

Re: Linux 3.2.19 kernel panic does not enter KDB

[Eric Valette]

On 06/11/2012 12:54 PM, Alan Cox wrote:

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

Ok. I'm still wondering if KDB is not broken on 3.2.19. If on a working 
system I do

echo g > /proc/sysrq-trigger

even from a tty all I see is the help and I'm back to the login shell. 
Actions like

echo t > /proc/sysrq-trigger

are logged but I cannot really enter the debugger...

-- eric