[pkg-nvidia-devel] Bug#566337: Additional tests

[Fredrik Tolf]

For the record, the same thing happens with a vanilla kernel (I tested
on vanilla 2.6.32.7).

I also tried installing another Debian system from scratch to eliminate
any possibility of external misconfiguration, and the same thing
happened there.

I also tried a few other things just to be sure, such as connecting the
video card to different PCI-express slots, using it with or without
another card in the same machine, and various output configurations.
What causes it to fail is using the TV output and nothing else (it can
drive CRT and DVI monitors without problems, even simultaneously). If it
matters, this is my xorg.conf Device section for the TV output:

Section "Device"
        Identifier      "D_NV-TV"
        Driver          "nvidia"
        BusID           "PCI:2:0:0"
        Option          "NoLogo" "1"
        Option          "UseDisplayDevice" "TV"
        Option          "ConnectedMonitor" "TV"
        Option          "TVStandard" "PAL-G"
        Option          "TVOutFormat" "SVIDEO"
EndSection

If the original submitter of the bug is reading this, were you also
using the TV output?

I tried mounting the root filesystem with `-o sync' to get the X-server
log synced properly to disk; the last lines before the crash are these:

[snip]
(==) Feb 15 06:14:33 NVIDIA(0): DPI set to (75, 75); computed from
built-in default
(==) Feb 15 06:14:33 NVIDIA(0): Enabling 32-bit ARGB GLX visuals.
(--) Depth 24 pixmap format is 32 bpp
(II) Feb 15 06:14:33 NVIDIA(0): Initialized GPU GART.
(II) Feb 15 06:14:33 NVIDIA(0): ACPI: failed to connect to the ACPI
event daemon; the daemon
(II) Feb 15 06:14:33 NVIDIA(0):     may not be running or the
"AcpidSocketPath" X

Since that's only half of the message from the nvidia driver telling the
it cannot connect to acpid, I guess it must mean that the kernel panics
asynchronously while the X server continues to run. I guess that's
consistent with the fact that it seems to crash in an ISR, but at least
I guess it means that the X server isn't currently running any piece of
code that would be waiting for some reponse from the kernel driver. (Or
could the log message have avoided getting written to disk
despite /var/log being on a `-o sync'-mounted filesystem?) I dunno if
that helps though, seeing how the driver source isn't available to look
at anyway.