thinking of use latest nvidia on wheezy

[Ross Boylan]

After a brief flash of success I'm now pretty much unable to access
the system, meaning both that the display is blank and that I can't
ssh in, possibly because the system isn't coming up.  I can't think of
any good reason there should be any connection between video and
networking, but there seems to be one.

I've attached the log (mailing list permitting) from a graphical 8.2
system trying to start up without the proprietary drivers.  I created
it from a Debian live system's installer on the same USB, and have
been using it in a different computer.  I stuck it in the system with
the graphics card.  X throws an exception at the end.

Vanilla Debian 8.2 doesn't seem to like the system, although I was
able to run the installer and put a fresh system in some spare space.
The test system was text only; I am attaching to the 980Ti via DVI.  I
didn't see anything in the logs that looked like a showstopper for the
system, but here are some highlights (copied by hand because of the
previous problems):
ACPI warning: SystemIO range nnn-nnn conflicts with OpRegion mmm-mmmm
(\_SB_.PCI0.SBUS.SMBI) (20140424/utaddress - 258)
#many messages similar to above
If an ACPI driver is available for this device you should use it
instead of the native driver
# not clear what device is meant, but this was shortly after
mentioning the video hardware
[drm] replacing VGA console driver
[drm] GMBUD [i915 gmus vga] timed out, falling back on bit banging on pin 2
i915 no connections reported
console switching to colour dummy device 80x25
# if output is going to a dummy device I guess that would explain why
# the monitor is blank
log entries on sound have some mentions of the PCI card

Those entries were from an 8.2 live USB boot in "failsafe" mode, which
produced a useable text console (though for some reason I couldn't get
networking going).  The 8.2 live in regular mode, like the system I
installed fresh, had a black screen and no ssh in (or signs of dhcp
requests out).

Having started this message with the end state, let me give the
history from the beginning, just after my previous message. I took my
primary wheezy system, purged all the nvidia stuff, installed the
backported 3.16 kernel, and rebooted.  The I installed nvidia via a
mix a packages I backported from experimental and binaries from
backports.  (Hmm, though I backported the packages under the old
kernel).

At first this failed because the syntactically incorrect xorg fragment
had been reinstalled; it's owned by something like
xserver-xorg-nvidia-driver (??).  When I commented it out I got a
blank screen.  Then, via ssh, I dropped in a small xorg.conf that had
"nvidia" as the device driver.  X started with the logs showing the
nvidia driver in use.

I shutdown, switched to a monitor connected via displayport, and
restarted.  The screen was blank. I switched back to the old monitor
with  DVI connection (only one video connector was attached to the
system at one time; always powered off while switching). No joy. I
suspected the initrd's might have been incorrect (e.g., some nvidia
package installed after they were created) and eventually managed to
chroot in (from an 8.2 installation CD in recovery mode, I
think--seemed to be the right kernel version, though since it wasn't
wheezy that could have caused trouble).  I updated grub, regenerated
the initrd, and installed grub to the boot sector of one disk.  It
didn't help; in fact it may have been around this point that I lost
the ability to ssh in.

Some other things I noticed at various points:
Sometimes the intel video driver showed chatter in the log.  There is
onboard Intel video; is it possible it was active and using its output
(also DVI)?  Is there any way to use the onboard video while the
nvidia card is installed?

Sometimes other drivers reported they would not touch a device that
was already bound (approximately).  So maybe the nvidia driver
prevented others from being used as a fallback?

I had some luck specifying "vesa" as the driver.

nouveau generally was tried and, I think, rejected, as expected.

vesa seemed to work, but often fb related (fbdev? fbgw?) seemed to end
up getting control.  I wasn't ever able to see the screen in that
case.  The logs would show lots of errors as fb tried to get
information (the attached log has examples).

I tried specifying blacklist=nvidia on the kernel options line (the
grub line starting with linux).  No help.

The card has a DVI-X connector; the cable is plain old DVI.

Thanks for any help.

Ross

* Even when I can see the screen in text mode, the fact that I can't
get ethernet to work means I can't transfer files I want to save via
net and I can't get the tools to partition the USB stick so I can copy
files there.  I talso suspect the live system may be blocking all of
my writes, even to my regular disks, because I though I had put a
modified xorg.conf in place (on my disk, not the live system) but
didn't see it on reboot.



On Sat, Jan 2, 2016 at 3:21 AM, Luca Boccassi <luca.boccassi at gmail.com> wrote:
> On 2 January 2016 at 06:38, Ross Boylan <rossboylan at stanfordalumni.org> wrote:
>> My screen is now blank, even in the alternate, textual VT's.  The
>> problem with the text VT's was happening before I installed the nvidia
>> drivers, and so may be separate.
>>
>> After building a bunch of packages and dpkg -i them, on reboot Xorg.log shows
>> [   126.926] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
>> [   127.031] Parse error on line 7 of section OutputClass in file
>> /usr/share/X11/xorg.conf.d/nvidia\
>> -drm-outputclass.conf
>>         "OutputClass" is not a valid section name.
>> [   127.031] (EE) Problem parsing the config file
>> [   127.031] (EE) Error parsing the config file
>> [   127.032]
>> Fatal server error:
>>
>> The full text of that conf file is
>> # This xorg.conf.d configuration snippet configures the X server to
>> # automatically load the nvidia driver when it detects a device driven by the
>> # nvidia.ko kernel module.  Please note that this only works on Linux kernels
>> # version 3.9 or higher with CONFIG_DRM enabled, and only if the nvidia.ko
>> # kernel module is loaded before the X server is started.
>>
>> Section "OutputClass"
>>     Identifier     "nvidia"
>>     MatchDriver    "nvidia-drm"
>>     Driver         "nvidia"
>> EndSection
>>
>> So it needs a newer X (I guess) and a newer kernel than I'm running.
>> I see 3.16 is available from backports, but that still wouldn't take
>> care of the X.
>>
>> Ideas?  Maybe if I took more of the packages from older versions,
>> i.e., backports for wheezy, things would work better.
>
> I forgot 3.2 was the kernel version in Wheezy main, sorry. To get the
> autoload to work you'll need 3.16 from wheezy-backports, yes.
>
> But it should not need on a newer version of the Xorg packages. Also
> the newer version of the driver packages does not need a manually
> written xorg.conf anymore, the packages will create a minimal one that
> is needed to load the driver at boot automatically.
>
> "Should" being the keyword here - once again, haven't backported to
> wheezy before :-)
>
>> Partly because the apt-get source from experimental wasn't working, I
>> downloaded the packages directly, did dpkg-source -x to unpack, and
>> dpkg-buildpackage to build them.  Then I used dpkg -i to install, and
>> iterated as I dicovered dependencies.
>>
>> I got sources for
>> glx-alternatives_0.7.1.dsc  nvidia-graphics-drivers_352.63-1.dsc
>> nvidia-support_20151021+1.dsc
>> libvdpau_1.1.1-3.dsc        nvidia-settings_346.59-1.dsc
>> though nvidia-settings had build dependencies that prevented me from building.
>>
>> I ended up with
>> dpkg -i \
>>      nvidia-installer-cleanup_20151021+1_amd64.deb \
>>      glx-diversions_0.7.1_amd64.deb \
>>      glx-alternative-mesa_0.7.1_amd64.deb \
>>      update-glx_0.7.1_amd64.deb \
>>      glx-alternative-nvidia_0.7.1_amd64.deb \
>>      nvidia-kernel-common_20151021+1_amd64.deb \
>>      nvidia-support_20151021+1_amd64.deb \
>>  nvidia-kernel-support_352.63-1_amd64.deb \
>>  nvidia-kernel-dkms_352.63-1_amd64.deb \
>>  libnvidia-ml1_352.63-1_amd64.deb \
>>   libcuda1_352.63-1_amd64.deb \
>>  libegl1-nvidia_352.63-1_amd64.deb \
>>  libnvidia-eglcore_352.63-1_amd64.deb \
>>  libgl1-nvidia-glx_352.63-1_amd64.deb \
>>  nvidia-driver_352.63-1_amd64.deb \
>>  nvidia-driver-bin_352.63-1_amd64.deb \
>>  xserver-xorg-video-nvidia_352.63-1_amd64.deb \
>>      libvdpau1_1.1.1-3_amd64.deb \
>>  nvidia-vdpau-driver_352.63-1_amd64.deb \
>>  nvidia-alternative_352.63-1_amd64.deb \
>>  libgles1-nvidia_352.63-1_amd64.deb \
>>  libgles2-nvidia_352.63-1_amd64.deb \
>>  nvidia-detect_352.63-1_amd64.deb
>>
>> Plus a few packages installed via aptitude, generally from backports.
>
> That looks correct. Sorry I forgot about nvidia-support and libvdpau,
> as I said I was writing from memory :-)
>
> You shouldn't need a newer nvidia-settings, the one in
> wheezy-backports should suffice. If you want a newer one, you can
> build the jessie version.
>
> Kind regards,
> Luca Boccassi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Xorg.log.vanilla.jessie.gz
Type: application/x-gzip
Size: 4154 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-nvidia-devel/attachments/20160104/2104d591/attachment.bin>