[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Sarge: nVidia proprietary driver vs. udev



Figured this thread might interest y'all. Sorry to post it mid-conversation...



Matt Zagrabelny wrote:
christian,

the html link from 4) below gives the commands to retrieve information
from your devices. read and use that. :)

Oh, you mean I should actually *read* your original email. ;) Sorry
about that.


an excerpt from that document follows:

# udevinfo -a -p `udevinfo -q path -n /dev/sda`
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                  try running this command seperately first.
your device has to be the first scsi drive for the above command to
work. if it is the seconds drive use /dev/sdb. third, etc...

Awesome, thanks.


how do you know udev doesnt get along well with nvidia drivers?
i have udev running on my work workstation and am using nvidia drivers,
but i compiled them, so i dont know if they are closed source.

I don't know for sure, but here's how I made that conclussion...

A) I've been using Fedora Core 3, and they have a problem between udev
and the nVidia drivers. I *think* it's a chicken/egg problem, although
no one has confirmed this:  udev won't create /dev/nvidia0, etc. until
nvidia.ko is loaded. But if nvidia.ko tries to load and doesn't see
/dev/nvidia0, etc., it barfs and refuses to load.

The main symptom of this problem is that everytime you boot, you have to
manually run "modprobe nvidia" before X can start.

In FC3, the solution is to do this:
  1. modprobe nvidia
  2. cp -a /dev/nvidia* /etc/udev/devices
I think the way this works (in FC3's version of udev, anyway) is that
when udev starts up it will copy everything in /etc/udev/devices/* over
to /dev. So my guess is this fixes the chicken/egg problem.


B) In Sarge (using 2.6, btw), I experienced the same symptom: everytime
I boot, I have to manually run "modprobe nvidia" before X can start.

Since it's the same symptom as I had in FC3, and since I'm running udev
on both distros, I figured they have the same root cause.

The problem is, I could never figure out how to fix the problem in Sarge:

- The FC3-style fix mentioned above seemed to do nothing. IIRC, Sarge
didn't even *have* a /etc/udev/devices directory initially, which makes
me suspect that FC3 and Sarge do udev somewhat differently.

- I tried creating a new service in runlevel 5: S98nvidia-startup. I
tried writing the service so that when it received the "start" command,
it would just run "modprobe nvidia". But for whatever reason, that
service didn't seem to start before gdm/kdm.



just so we are clear, udev is a user space program to create device
files in the /dev heirarchy. it does not provide any drivers or anything
like that, those are still all in the kernel.

Yeah, thanks. I'm clear on that.


cheers,

-matt zagrabely

On Tue, 2004-11-16 at 08:49 -0500, Christian Convey wrote:

Hey Matt,

Thanks a lot, I'll definitely give that a shot.

Quick question: Is there some document somewhere that taught you how to determine those particular strings you use? I.e,. "DIMAGE CAMERA " and
"0686" ?

Bummer thing about udev is that it seems to get along pretty badly with nVidia's current closed-source driver. I hope udev proves worthwhile - I'm choosing to use it instead of using nVidia's driver.

Thanks again,
Christian

Matt Zagrabelny wrote:

hey christian,

1) install udev (its only in testing and unstable)

2) make sure your kernel (if it is custom built) has tmpfs support (this
caused many days of frustration for me)

3) look in /etc/udev/ for a bunch of files related to udev

4) http://www.reactivated.net/udevrules.php  (i found this web site by
googling for "udev rules howto"

5) here is my relavent entry for my camera:

from /etc/udev/udev.rules

# Minolta DImage 7Hi
BUS="usb", SYSFS{product}="DIMAGE CAMERA  ",
SYSFS{manufacturer}="MINOLTA  DIMAGE CAMERA   ",
SYSFS{idProduct}="400f", SYSFS{idVendor}="0686", NAME="%k",
SYMLINK="camera"

the above is all on one line in my file (except for the comment :).

hope that helps.

-matt zagrabelny


On Mon, 2004-11-15 at 14:49 -0500, Christian Convey wrote:


Hey Matt,

Can you point me to any good documentation on udev? I'd like to reap the benefits you're describing, but I haven't found any good backgrounder docs on UDEV that let me understand both the overall scheme and how to get particular results (like persistent naming of my camera, flash drive, etc.)


Matt Zagrabelny wrote:


And this is my favorite. Trying to mount a USB key. There is no usb
key device, like there is one for cdrom. It gets mapped to a scsi
device (for some reason), the first one, because I don't actually have
another scsi on my computer. /dev/sda1, not /dev/sda. Terrific. Except
on my new computer at home that does not work because I have scsi hard
drive so USB key gets mapped to /dev/sdb1. Of course. Not /dev/sda2.
And that's in 2.6.8. In 2.6.9 it's something completely different like
/dev/uba, but it doesn't work because 2.6.9 is in Sid so it's still
buggy. Count another hour or two of confused googling to figure all
that out.


scsi devices are named similarly to ide ones.

ide: primary master   = /dev/hda    scsi: 1st scsi drive = /dev/sda
ide: primary slave    = /dev/hdb    scsi: 2nd scsi drive = /dev/sdb
ide: secondary master = /dev/hdc    scsi: 3rd scsi drive = /dev/sdc
ide: secondary slave  = /dev/hdd    scsi: 4th scsi drive = /dev/sdd
etc...

the numbers that follow the device is the number of the partition that
the filesystem resides on.

for example /dev/sda1 means the filesystem is on the first partition on
the first scsi drive.

to resolve these naming conflicts you of your hotplug devices you could
use udev. i have my usb camera always symlinked to /dev/camera whether
the real device is /dev/sda1 or /dev/sdb1. udev takes care of that.
then in my /etc/fstab i use /dev/camera as my device.

if you want more info about udev (and dont want to google, let me
know :).

-matt zagrabelny






Reply to: