All of lore.kernel.org
 help / color / mirror / Atom feed
From: MALET JL <malet.jean-luc@laposte.net>
To: linux-hotplug@vger.kernel.org
Subject: Re: udev vs nvidia
Date: Thu, 26 Feb 2004 16:25:58 +0000	[thread overview]
Message-ID: <403E1E16.8010707@laposte.net> (raw)
In-Reply-To: <40312612.7070700@reactivated.net>

[-- Attachment #1: Type: text/plain, Size: 3803 bytes --]

Daniel Drake a écrit :

> If anyone is interested, I have solved the below issue. It turns out 
> that you are supposed to load the module before starting X (even 
> nvidia say so), and devfs did this automatically on bootup. So, the 
> nvidia module should be added to an autoload list, and this issue is 
> not a fault of udev/hotplug.
>
> Daniel
>
> Daniel Drake wrote:
>
>> Hi,
>>
>> Since switching to udev, I have had problems when starting X relating 
>> to nvidia drivers. I know this is a tricky situation, with the nvidia 
>> drivers being closed-source, nobody really knows how they work. If it 
>> seems likely that this problem is not udev-related, then please tell 
>> me, and I will go to nvidia instead.
>>
>> I'm not sure if this is even anything to do with udev. The only 
>> reason I suspect udev might be involved, is because of the existance 
>> of /dev nodes seems to play a part.
>>
>>
>> I am running nvidia drivers version 5336 with Martin Schlemmer's 
>> patch applied to make them export info into sysfs.
>> If I manually "modprobe nvidia", then I can see that the /dev/nvidia0 
>> and /dev/nvidiactl nodes are created. So at this stage it seems to be 
>> loaded.
>>
>>
>> Ignoring the above situation, on a normal bootup, the nvidia module 
>> is not loaded at the point where I "startx":
>>
>> # ls /dev/nvidia*
>> no such file or directory
>>
>> # startx
>> XFree86 Version 4.3.0
>> Release Date: 27 February 2003
>> [snip]
>> (==) Using config file: "/etc/X11/XF86Config"
>> Using vt 7
>> (EE) NVIDIA(0): Failed to initialize the NVIDIA kernel module!
>> (EE) NVIDIA(0):  *** Aborting ***
>> (EE) Screen(s) found, but none have a usable configuration.
>>
>> Fatal server error:
>> no screens found
>>
>> If I mknod the /dev/nvidia* nodes first, then X is able to start as 
>> normal. Also, strangely, if I "modprobe nvidia", and then "startx" 
>> then X starts as normal.
>>
>> I believe that this problem comes around because the /dev nodes are 
>> not created quickly enough.
>>
>> # modprobe nvidia && ls -l /dev/nv*
>> ls: /dev/nv*: No such file or directory
>>
>> # rmmod nvidia
>>
>> # modprobe nvidia && sleep 2 && ls -l /dev/nv*
>> crw-rw-rw-    1 root     video    195,   0 Feb 16 19:47 /dev/nvidia0
>> crw-rw-rw-    1 root     video    195, 255 Feb 16 19:47 /dev/nvidiactl
>>
>>
>> My theory is that X loads the "nvidia" module, and then immediately 
>> tries to initialize the display and whatever else. But as the nvidia* 
>> nodes arent in place, it dies.
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
> Linux-hotplug-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

here is a solution :

jlm@Sorcerer:~$ cat /etc/udev/nvidia.sh
#!/bin/sh
mknod /dev/nvidia0 c 195 0 -m a+rw
mknod /dev/nvidia1 c 195 1 -m a+rw
mknod /dev/nvidia2 c 195 2 -m a+rw
mknod /dev/nvidia3 c 195 3 -m a+rw
mknod /dev/nvidia4 c 195 4 -m a+rw
mknod /dev/nvidia5 c 195 5 -m a+rw
mknod /dev/nvidia6 c 195 6 -m a+rw
mknod /dev/nvidia7 c 195 7 -m a+rw
mknod /dev/nvidiactl c 195 255 -m a+rw

jlm@Sorcerer:~$ cat  /etc/modprobe.conf
install ppp_generic     mknod /dev/ppp c 108 0 -m 0666 && modprobe 
--ignore-install ppp_generic;
install         nvidia                  /etc/udev/nvidia.sh && modprobe 
--ignore-install nvidia;
[...]



note that the same issue occurs with pppd

[-- Attachment #2: Type: application/pgp-signature, Size: 250 bytes --]

      parent reply	other threads:[~2004-02-26 16:25 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-16 20:20 udev vs nvidia Daniel Drake
2004-02-16 20:33 ` Daniel Drake
2004-02-16 20:36 ` claude
2004-02-25 21:27 ` Daniel Drake
2004-02-26 16:25 ` MALET JL [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=403E1E16.8010707@laposte.net \
    --to=malet.jean-luc@laposte.net \
    --cc=linux-hotplug@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.