View previous topic :: View next topic |
Author |
Message |
Decibels Veteran
Joined: 16 Aug 2002 Posts: 1623 Location: U.S.A.
|
Posted: Tue Mar 30, 2004 12:24 am Post subject: |
|
|
Epyon wrote: | Edit: Where did you get /etc/init.d/udev from? I don't have that file... |
Ooops, looked at the date on the file and was back from Dec last year. Must have been there when playing around with the tutorial from something else. When looked at contents, didn't think I wrote it, so thought it was new. It is something I put there testing. So shouldn't be there.
Also, they said that the problem with udev-023-r1 and nvidia/alsa is a nvidia and alsa issue, not udev.
Not sure how it became a nvidia and alsa issue when installed a new udev only and they stopped being created, but not a developer and not in on everything. So if have the problem with at least udev-023-r1, running udevstart will work. _________________ Support bacteria – they’re the only culture some people have.”
– Steven Wright
Last edited by Decibels on Tue Mar 30, 2004 1:37 am; edited 1 time in total |
|
Back to top |
|
|
Epyon l33t
Joined: 11 Sep 2003 Posts: 754 Location: NJ, USA
|
Posted: Tue Mar 30, 2004 12:28 am Post subject: |
|
|
Decibels wrote: |
Not sure how it became a nvidia and alsa issue when installed a new udev only and they stopped being created, but not a developer and not in on everything. |
Yeah I wasn't sure about that either... |
|
Back to top |
|
|
gungholady Guru
Joined: 19 Oct 2003 Posts: 392
|
Posted: Tue Mar 30, 2004 12:57 am Post subject: |
|
|
I rebooted, logged in as root, then ran "udevstart". After I did this I did the "ls /dev/nvidia*. I got back nvidia0 and nvidiactl. I ran "alsactl restore" because of the error message I was getting about alsa. I then exited as root and logged in as user. When I used "startx", kde loaded just fine and the GL screensavers are working without having to do the re-emerges. So now the question is, how do we get udevstart to run soon enough to create these devices as expected and for alsa to work properly without having to run "alsactl restore" manually? For now, should the udevstart and alsactl restore be placed in /etc/local.start? Or is there a better way to handle this? |
|
Back to top |
|
|
gungholady Guru
Joined: 19 Oct 2003 Posts: 392
|
Posted: Tue Mar 30, 2004 1:01 am Post subject: |
|
|
meowsqueak wrote: | Can we verify that udevd is started before /etc/modules.d/kernel-2.6 is processed? |
When I reboot and watch the information as it scrolls past, udevd is listed at the very beginning along with proc. The modules don't get loaded until farther down the list. Is this what you were looking for? |
|
Back to top |
|
|
Decibels Veteran
Joined: 16 Aug 2002 Posts: 1623 Location: U.S.A.
|
Posted: Tue Mar 30, 2004 1:30 am Post subject: |
|
|
gungholady, I was thinking this might fix your problem, but wasn't in on the beginning of your problem so didn't want to say for sure, cause I might be wrong. Hey, I might have the 'official' 'unofficial' guide but they don't tell me anything at all, not one bit. If I find something out, it is pretty much only from asking or experimenting. GregKH did tell me about the udevstart, but that was only after asking.
I would say at this point, /etc/conf.d/local.start would be the best bet for now. When I posted a bug on this, was told that it is a nvidia and alsa package problem. Like mentioned earlier, not sure how they worked before and after upgrading udev they stopped. Maybe will have to look at the bug reports some more and see. That is all the info I have at this time.
Haven't tried it cause ran out of time, but previously we put mknod for nvidia in local.start and worked, so shouldn't be a problem now, unless timing issue develops also. If so will probably need to add a sleep in there for a bit.
Until I have further info, wouldn't figure on having to run udevstart manually or manually enter into a script for too long. If no one gets around to testing this out, will try in the morning. _________________ Support bacteria – they’re the only culture some people have.”
– Steven Wright |
|
Back to top |
|
|
Epyon l33t
Joined: 11 Sep 2003 Posts: 754 Location: NJ, USA
|
Posted: Tue Mar 30, 2004 1:33 am Post subject: |
|
|
gungholady wrote: | So now the question is, how do we get udevstart to run soon enough to create these devices as expected and for alsa to work properly without having to run "alsactl restore" manually? For now, should the udevstart and alsactl restore be placed in /etc/local.start? Or is there a better way to handle this? |
I put udevstart in /etc/init.d/alsasound right before it does alsactl restore.
I put it directly above this line: einfo "Restoring Mixer Levels"
It works for me. I don't know about the nvidia thing. |
|
Back to top |
|
|
Decibels Veteran
Joined: 16 Aug 2002 Posts: 1623 Location: U.S.A.
|
Posted: Tue Mar 30, 2004 1:46 am Post subject: |
|
|
Epyon wrote: | I put udevstart in /etc/init.d/alsasound right before it does alsactl restore.
I put it directly above this line: einfo "Restoring Mixer Levels"
It works for me. I don't know about the nvidia thing. |
Not sure if a good idea to put in /etc/init.d/ scripts. They will get overwritten when get a new config file and you will have to keep editing them,... plus, sooner or later I would figure you would need to remove any reference you put in for udevstart.
That is why I think if put in in local.start would be fast and easy to remove later. Just an idea. _________________ Support bacteria – they’re the only culture some people have.”
– Steven Wright |
|
Back to top |
|
|
Epyon l33t
Joined: 11 Sep 2003 Posts: 754 Location: NJ, USA
|
Posted: Tue Mar 30, 2004 1:55 am Post subject: |
|
|
By the time local.start gets run on startup I can do alsactl restore without udevstart and it'll work. The lag in creating the /dev nodes is only a couple seconds. |
|
Back to top |
|
|
Decibels Veteran
Joined: 16 Aug 2002 Posts: 1623 Location: U.S.A.
|
Posted: Tue Mar 30, 2004 2:44 am Post subject: |
|
|
IDEA
When posting for help or submitting solution: Mention what udev version using with every post, at least on problems. Was looking at the nvidia problem before and only on the second time around did I see the version mentioned. This thread if very long and can be tedious to search.
Just an idea think might help find and solve problems here, cause with every couple or so udev upgrades, seem to have some big issue.
This time it looks like a udev problem, but have been told it isn't.
Using: udev-023-r1 _________________ Support bacteria – they’re the only culture some people have.”
– Steven Wright |
|
Back to top |
|
|
Epyon l33t
Joined: 11 Sep 2003 Posts: 754 Location: NJ, USA
|
Posted: Tue Mar 30, 2004 3:17 am Post subject: |
|
|
Well my problems are with udev 023-r1 and down. |
|
Back to top |
|
|
Decibels Veteran
Joined: 16 Aug 2002 Posts: 1623 Location: U.S.A.
|
Posted: Tue Mar 30, 2004 3:13 pm Post subject: |
|
|
Updated Udev Primer to include information I have so far on udevstart and the nvidia/alsa problem.
Putting /sbin/udevstart in the top of my local.start worked fine for me. _________________ Support bacteria – they’re the only culture some people have.”
– Steven Wright |
|
Back to top |
|
|
OneOfOne Guru
Joined: 28 May 2003 Posts: 368
|
Posted: Tue Mar 30, 2004 3:54 pm Post subject: |
|
|
well this odd because everything works fine here w/o any problems or any hacks..
/dev/nvidia* gets created (i have the module in modules.autoload).
alsasound and hotplug are in boot runlevel.
sys-apps/hotplug-base-20040329 *
sys-apps/hotplug-20040329 *
sys-fs/udev-023-r1 *
media-video/nvidia-glx-1.0.5336-r1 *
media-video/nvidia-kernel-1.0.5336-r1 *
media-libs/alsa-lib-1.0.3b-r2 *
media-sound/alsa-utils-1.0.3 *
Portage 2.0.50-r210 (default-x86-2004.0, gcc-3.3.3, glibc-2.3.3_pre20040207-r0, 2.6.4-rc2-love1)
peace |
|
Back to top |
|
|
Epyon l33t
Joined: 11 Sep 2003 Posts: 754 Location: NJ, USA
|
Posted: Tue Mar 30, 2004 9:00 pm Post subject: |
|
|
I had alsasound working fine when I used mm-sources. They got too buggy for me though and I went back to gentoo-dev-sources where it started again. It also happened with ck-sources. |
|
Back to top |
|
|
snowpatch n00b
Joined: 09 Mar 2003 Posts: 38 Location: Philadelphia
|
Posted: Tue Mar 30, 2004 10:02 pm Post subject: |
|
|
Epyon - the alsactl mixer restore errors at boot seem to be not a udev problem, but a alsa userspace problem according to this bug report: https://bugs.gentoo.org/show_bug.cgi?id=39345
The alsa problem you are having is the one in the above bug? Putting a call to udevstart in /etc/init.d/alsasound before the alsactl mixer restore I think only works (as does sleep n) because of the time delay introduced. I tried putting udevstart in /etc/conf.d/local.start, but it did nothing.
I have been running 2.6.4-ck1, udev-023-r1, and now hotplug-20040329. |
|
Back to top |
|
|
wdreinhart Guru
Joined: 11 Jun 2003 Posts: 569 Location: 4QFJ12345678
|
Posted: Tue Mar 30, 2004 10:21 pm Post subject: |
|
|
Udev rules! I just hacked together a few custom rules that take care of my major gripe about how Linux and devfs handled USB storage devices.
Code: |
# A usb camera.
BUS="usb", SYSFS{product}="Sony DSC", KERNEL="sd?1", NAME="%k", SYMLINK="camera"
# My Axis USB key
BUS="usb", SYSFS{idProduct}="1001", SYSFS{idVendor}="090a", KERNEL="sd?", NAME="%k", SYMLINK="pendrive"
|
See this site for more information
Now no matter what order I plug them in, the USB pen drive is /dev/pendrive, and the camera is /dev/camera. I hope this helps someone else solve their /dev annoyances. |
|
Back to top |
|
|
Decibels Veteran
Joined: 16 Aug 2002 Posts: 1623 Location: U.S.A.
|
Posted: Wed Mar 31, 2004 12:00 am Post subject: |
|
|
OneOfOne wrote: | well this odd because everything works fine here w/o any problems or any hacks..
/dev/nvidia* gets created (i have the module in modules.autoload).
alsasound and hotplug are in boot runlevel.
sys-apps/hotplug-base-20040329 *
sys-apps/hotplug-20040329 *
sys-fs/udev-023-r1 *
media-video/nvidia-glx-1.0.5336-r1 *
media-video/nvidia-kernel-1.0.5336-r1 *
media-libs/alsa-lib-1.0.3b-r2 *
media-sound/alsa-utils-1.0.3 *
Portage 2.0.50-r210 (default-x86-2004.0, gcc-3.3.3, glibc-2.3.3_pre20040207-r0, 2.6.4-rc2-love1)
peace |
As far as udevstart in local.start. I have some other stuff going on in local.start, and put udevstart at top, so maybe the extras are giving it enough time. Adding a sleep below udevstart might work for those that don't have other stuff in there like I do.
Well, upgraded hotplug, and alsa to what you have and nogo, still need to run udevstart. Haven't tried the same kernel you have so maybe that is it. Don't see a Portage 2.0.50-r210 available. But here is mine:
Portage 2.0.50-r1 (default-x86-1.4, gcc-3.3.3, glibc-2.3.3_pre20040207-r0, 2.6.3-rc1-mm1)
Also have just tried gentoo-development sources: 2.6.4-gentoo-r1 and
doesn't prevent me from having to run udevstart either. _________________ Support bacteria – they’re the only culture some people have.”
– Steven Wright |
|
Back to top |
|
|
gungholady Guru
Joined: 19 Oct 2003 Posts: 392
|
Posted: Wed Mar 31, 2004 2:34 am Post subject: |
|
|
Epyon wrote: | Decibels wrote: |
Well, adding to boot level doesn't seem to work, still have to run udevstart to get anywhere, filing bug report. |
Seems the report got marked invalid... |
I sure don't know what they meant when they marked the bug as invalid. None of the nvidia bugs I looked at even mentioned udevstart. The mention of it here (I put /sbin/udevstart in my /etc/conf.d/local.start) along with setting the sleep to 5 in the /etc/init.d/alsasound solved my problems with nvidia and alsasound. |
|
Back to top |
|
|
Epyon l33t
Joined: 11 Sep 2003 Posts: 754 Location: NJ, USA
|
Posted: Wed Mar 31, 2004 3:22 am Post subject: |
|
|
snowpatch wrote: |
The alsa problem you are having is the one in the above bug? Putting a call to udevstart in /etc/init.d/alsasound before the alsactl mixer restore I think only works (as does sleep n) because of the time delay introduced. I tried putting udevstart in /etc/conf.d/local.start, but it did nothing.
|
Putting in udevstart introduces only a 0.3 second delay. I think its creating the /dev nodes needed. Otherwise you would need to use a sleep 3 or 5 and wait until they appear.
If you put udevstart in local.start you'd need to put alsactl restore after it so that the mixer gets restored. local.start runs way after alsasound on boot. |
|
Back to top |
|
|
Admiral LSD Guru
Joined: 27 Jun 2003 Posts: 522 Location: Northam, W.A., Australia
|
Posted: Wed Mar 31, 2004 3:29 am Post subject: |
|
|
I've just settled for putting a sleep command in the alsasound init script, right before the loop as suggested in the bug report (so it doesn't get repeated multiple times and slow the boot process down even more). It's both simple and it gets the job done. I'm still not convinced it's entirely ALSA's fault seeing as I never got the problem until quite recently but until proven otherwise I'm inclined to take Gregs word on it simply because he knows more about what's going on behind the scenes than I probably ever will. _________________ Wasurenaide...
...watashi ga iru koto o.
Itsudatte soba ni iru yo.
Registered Linux user #319839 |
|
Back to top |
|
|
Decibels Veteran
Joined: 16 Aug 2002 Posts: 1623 Location: U.S.A.
|
Posted: Wed Mar 31, 2004 3:44 am Post subject: |
|
|
gungholady wrote: | Epyon wrote: | Decibels wrote: |
Well, adding to boot level doesn't seem to work, still have to run udevstart to get anywhere, filing bug report. |
Seems the report got marked invalid... |
I sure don't know what they meant when they marked the bug as invalid. None of the nvidia bugs I looked at even mentioned udevstart. The mention of it here (I put /sbin/udevstart in my /etc/conf.d/local.start) along with setting the sleep to 5 in the /etc/init.d/alsasound solved my problems with nvidia and alsasound. |
Think it is this bug right here: https://bugs.gentoo.org/show_bug.cgi?id=43946 _________________ Support bacteria – they’re the only culture some people have.”
– Steven Wright |
|
Back to top |
|
|
gungholady Guru
Joined: 19 Oct 2003 Posts: 392
|
Posted: Wed Mar 31, 2004 3:58 am Post subject: |
|
|
That was the only one I found too that came even close. It doesn't mention the udevstart though. |
|
Back to top |
|
|
Kow Apprentice
Joined: 28 Dec 2003 Posts: 227
|
Posted: Wed Mar 31, 2004 6:25 am Post subject: |
|
|
Just a heads up
If you use USB mice and currently are using devfsd and are switching to udev, that /dev/usbmouse or any sort of input devices with nodes in /dev will be gone when using udev... the correct device paths will be in /dev/input.
This effects XFree mainly.
I had my Mouse Device "/dev/usbmouse" and had to change it to "/dev/input/mice"
Keyboard is fine - I use Hardware control not software (or else grub would have no keyboard) _________________ -Kow |
|
Back to top |
|
|
Admiral LSD Guru
Joined: 27 Jun 2003 Posts: 522 Location: Northam, W.A., Australia
|
Posted: Wed Mar 31, 2004 6:33 am Post subject: |
|
|
You can change that though with some custom rules. With a couple of lines in /etc/udev/udev.rules your mouse can be /dev/mouse, /dev/usbmouse or even /dev/rodent, whatever takes your fancy. _________________ Wasurenaide...
...watashi ga iru koto o.
Itsudatte soba ni iru yo.
Registered Linux user #319839 |
|
Back to top |
|
|
danone Guru
Joined: 18 Jan 2004 Posts: 398 Location: Germany
|
Posted: Wed Mar 31, 2004 5:10 pm Post subject: |
|
|
Got problems with my harddrive on boot.
/dev/hda5 was my /boot but it cant mount them on start up after boot sequence i can mount them whats wrong there? I tried to make a rule
Code: |
KERNEL="hd[0-9]*", NAME="hd/%n", SYMLINK="%k"
device '/sys/block/hda/hda5' has major:minor 3:5
looking at class device '/sys/block/hda/hda5':
SYSFS{dev}="3:5"
SYSFS{size}="195426"
SYSFS{start}="126"
SYSFS{stat}=" 0 0 0 0"
follow the class device's "device"
looking at the device chain at '/sys/devices/pci0000:00/0000:00:1f.1/ide0/0.0':
BUS="ide"
ID="0.0"
SYSFS{detach_state}="0"
looking at the device chain at '/sys/devices/pci0000:00/0000:00:1f.1/ide0':
BUS=""
ID="ide0"
SYSFS{detach_state}="0"
looking at the device chain at '/sys/devices/pci0000:00/0000:00:1f.1':
BUS="pci"
ID="0000:00:1f.1"
SYSFS{class}="0x01018a"
SYSFS{detach_state}="0"
SYSFS{device}="0x24db"
SYSFS{irq}="3"
SYSFS{subsystem_device}="0x1022"
SYSFS{subsystem_vendor}="0x147b"
SYSFS{vendor}="0x8086"
looking at the device chain at '/sys/devices/pci0000:00':
BUS=""
ID="pci0000:00"
SYSFS{detach_state}="0"
|
also my keyboard is mapped as mouse0
Code: | device '/sys/class/input/mouse0' has major:minor 13:32
looking at class device '/sys/class/input/mouse0':
SYSFS{dev}="13:32"
follow the class device's "device"
looking at the device chain at '/sys/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.1':
BUS="usb"
ID="3-1:1.1"
SYSFS{bAlternateSetting}=" 0"
SYSFS{bInterfaceClass}="03"
SYSFS{bInterfaceNumber}="01"
SYSFS{bInterfaceProtocol}="00"
SYSFS{bInterfaceSubClass}="00"
SYSFS{bNumEndpoints}="01"
SYSFS{detach_state}="0"
SYSFS{iInterface}="00"
looking at the device chain at '/sys/devices/pci0000:00/0000:00:1d.1/usb3/3-1':
BUS="usb"
ID="3-1"
SYSFS{bConfigurationValue}="1"
SYSFS{bDeviceClass}="00"
SYSFS{bDeviceProtocol}="00"
SYSFS{bDeviceSubClass}="00"
SYSFS{bMaxPower}="100mA"
SYSFS{bNumConfigurations}="1"
SYSFS{bNumInterfaces}=" 2"
SYSFS{bcdDevice}="0110"
SYSFS{bmAttributes}="a0"
SYSFS{detach_state}="0"
SYSFS{idProduct}="0103"
SYSFS{idVendor}="0a81"
SYSFS{manufacturer}="CHESEN"
SYSFS{product}="USB Keyboard"
SYSFS{speed}="1.5"
looking at the device chain at '/sys/devices/pci0000:00/0000:00:1d.1/usb3':
BUS="usb"
ID="usb3"
SYSFS{bConfigurationValue}="1"
SYSFS{bDeviceClass}="09"
SYSFS{bDeviceProtocol}="00"
SYSFS{bDeviceSubClass}="00"
SYSFS{bMaxPower}=" 0mA"
SYSFS{bNumConfigurations}="1"
SYSFS{bNumInterfaces}=" 1"
SYSFS{bcdDevice}="0206"
SYSFS{bmAttributes}="40"
SYSFS{detach_state}="0"
SYSFS{idProduct}="0000"
SYSFS{idVendor}="0000"
SYSFS{manufacturer}="Linux 2.6.5ioIT uhci_hcd"
SYSFS{product}="Intel Corp. 82801EB USB"
SYSFS{serial}="0000:00:1d.1"
SYSFS{speed}="12"
looking at the device chain at '/sys/devices/pci0000:00/0000:00:1d.1':
BUS="pci"
ID="0000:00:1d.1"
SYSFS{class}="0x0c0300"
SYSFS{detach_state}="0"
SYSFS{device}="0x24d4"
SYSFS{irq}="9"
SYSFS{subsystem_device}="0x1022"
SYSFS{subsystem_vendor}="0x147b"
SYSFS{vendor}="0x8086"
looking at the device chain at '/sys/devices/pci0000:00':
BUS=""
ID="pci0000:00"
SYSFS{detach_state}="0"
|
what is wrong there and what i can do to get my hda5 to mount on boot _________________ [:: Processor: Intel Core 2 Duo E6300 ]::[ Mainboard: ASUS P5B Deluxe ]::[ GPU: nVidia 7900GTO ::]
[:: RAM: HyperX DDR2 800 ]::[ Samsung SH-183A SATA:: CREATiVE X-Fi XtremeMusic :: ] |
|
Back to top |
|
|
snowpatch n00b
Joined: 09 Mar 2003 Posts: 38 Location: Philadelphia
|
Posted: Wed Mar 31, 2004 7:50 pm Post subject: |
|
|
Epyon wrote: Quote: | Putting in udevstart introduces only a 0.3 second delay. I think its creating the /dev nodes needed. Otherwise you would need to use a sleep 3 or 5 and wait until they appear.
If you put udevstart in local.start you'd need to put alsactl restore after it so that the mixer gets restored. local.start runs way after alsasound on boot. |
You are correct. Thanks for pointing me to udevstart.
I removed everything from local.start. I replaced the 'sleep 3' with '/sbin/udevstart' in /etc/init.d/alsasound. There is no noticeable delay and all mixer settings are restored properly on boot.
Is this approach better than using the sleep command? I thought I read somewhere in this thread that udevstart might go away at some point. |
|
Back to top |
|
|
|