Linux 3.2.19 kernel panic does not enter KDB

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

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

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

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

Thanks,
//richard

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

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

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