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
On Sun, 10 Jun 2012 13:22:35 +0200
Eric Valette <[email protected]> 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
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
On Sun, Jun 10, 2012 at 1:38 PM, Eric Valette <[email protected]> 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
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
> 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
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