I've released the 015 version of udev. It can be found at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-015.tar.gz
rpms built against Red Hat FC1 are available at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-015-1.i386.rpm
with the source rpm at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-015-1.src.rpm
udev allows users to have a dynamic /dev and provides the ability to
have persistent device names. It uses sysfs and /sbin/hotplug and runs
entirely in userspace. It requires a 2.6 kernel with CONFIG_HOTPLUG
enabled to run. Please see the udev FAQ for any questions about it:
kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ
For any udev vs devfs questions anyone might have, please see:
kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs
Major changes from the 014 version:
- we finally look up the chain of sysfs device entries trying to
match all devices in the chain for each rule.
What this means to users: Consider the following sysfs device:
$ tree /sys/class/input/mouse1/
/sys/class/input/mouse1/
|-- dev
|-- device -> ../../../devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0
`-- driver -> ../../../bus/usb/drivers/hid
Now this is a USB trackball. udev will follow that "device" symlink and
get to the following directory:
$ tree /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0
/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0
|-- bAlternateSetting
|-- bInterfaceClass
|-- bInterfaceNumber
|-- bInterfaceProtocol
|-- bInterfaceSubClass
|-- bNumEndpoints
|-- detach_state
|-- iInterface
`-- power
`-- state
This is the directory of the USB interface that is bound to a mouse
driver. But in itself, that directory is pretty boring, no vendor id,
no product id, no manufacturer string... What a user really wants is
the directory above this:
$ tree /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1
/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1
|-- 2-1:1.0
| |-- bAlternateSetting
| ...
|-- bConfigurationValue
|-- bDeviceClass
|-- bDeviceProtocol
|-- bDeviceSubClass
|-- bMaxPower
|-- bNumConfigurations
|-- bNumInterfaces
|-- bcdDevice
|-- bmAttributes
|-- detach_state
|-- idProduct
|-- idVendor
|-- manufacturer
|-- power
| `-- state
|-- product
`-- speed
Now this directory contains good stuff:
$ cat /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/product
Microsoft Trackball Optical?
So, in short, you can now write a udev rule for this device as:
SYSFS_product="Microsoft Trackball*", NAME="my_trackball", SYMLINK="input/mouse1"
and it will actually work :)
This is really helpful for all USB devices, and SCSI devices on USB or
Firewire buses. If anyone has any questions about this, please let me
know, or bring it up on the linux-hotplug-devel mailing list.
Another big thing in this release is 'udevinfo'. It's a way to get all
information out of the udev database about what devices are present,
what they are called, and other good stuff. It also will walk the sysfs
chain of any device and print out all information on the device which
helps out a lot in creating rules for udev.
Thanks to Kay Sievers who wrote udevinfo. Great job.
Also in this release is the start of a udev daemon. It's really in 3
pieces:
udevsend - sends the hotplug message to the udev daemon
udevd - the udev daemon, gets the hotplug messages, sorts them
in proper order, and passes them off to the udev program
to act apon them.
udev - still the same.
This lets us keep udevsend and udevd small, and hopefully bug free.
These programs still need a lot of work and polish before we feel they
are stable enough to use for everyone (they are not built right now in
the .rpm). Help is appreciated here.
Thanks a lot to Kay Sievers and Xiaofeng Ling for the work on udevsend
and udevd. Again, I really appreciate it.
Thanks also to everyone who has send me patches for this release, a full
list of everyone, and their changes is below.
udev development is done in a BitKeeper repository located at:
bk://linuxusb.bkbits.net/udev
Daily snapshots of udev from the BitKeeper tree can be found at:
http://www.codemonkey.org.uk/projects/bitkeeper/udev/
If anyone ever wants a tarball of the current bk tree, just email me.
thanks,
greg k-h
Summary of changes from v014 to v015
============================================
<mbuesch:freenet.de>:
o LFS init script update
Greg Kroah-Hartman:
o update klibc to version 0.98
o clean up udevinfo on 'make clean'
o add udevinfo man page to spec file
o remove command line documentation from udev man page
o create initial version of udevinfo man page
o added URL to spec file
o add udevinfo to udev.spec file
o add udevinfo to install target of Makefile
o rip out command line code from udev, now that we have udevinfo
o udevinfo doesn't need to declare main_envp
o move get_pair to udev_config.c because udevinfo doesn't need all of namedev.o
o more makefile cleanups
o move udevinfo into the main build and clean up the main Makefile a bit
o clean up compiler warnings if building using klibc
o make udevd only have one instance running at a time
o new testd.block script for debugging
o udevsnd : clean up message creation logic a bit
o make bk ignore udevd and udevsend binaries
o whitespace cleanups
o remove TODO item about BUS value, as it is now done
o add support for figuring out which device on the sysfs "chain" the rule applies to
Kay Sievers:
o udevinfo - now a real program :)
o udevd - cleanup and better timeout handling
o udev - next round of udev event order daemon
o fix udevd exec
o udev - udevinfo with device chain walk
o spilt udev into pieces
On Mon, Jan 26, 2004 at 01:50:36PM -0800, Greg KH wrote:
> I've released the 015 version of udev. It can be found at:
Great, 15 minuts after I've installed 014 ;-)
014 and 015 errors for me when made with 'make USE_DBUS=true':
udev_dbus.c: In function `sysbus_connect':
udev_dbus.c:41: warning: implicit declaration of function `dbg'
gcc -ldbus-1 -o udev udev.o udev_config.o udev-add.o udev-remove.o \
udevdb.o logging.o namedev.o namedev_parse.o /mnt/ram/udev-015/libsysfs/sysfs_bus.o \
/mnt/ram/udev-015/libsysfs/sysfs_class.o /mnt/ram/udev-015/libsysfs/sysfs_device.o \
/mnt/ram/udev-015/libsysfs/sysfs_dir.o /mnt/ram/udev-015/libsysfs/sysfs_driver.o \
/mnt/ram/udev-015/libsysfs/sysfs_utils.o /mnt/ram/udev-015/libsysfs/dlist.o \
tdb/tdb.o tdb/spinlock.o udev_dbus.o -lc
udev_dbus.o(.text+0x49): In function `sysbus_connect':
: undefined reference to `dbg'
udev_dbus.o(.text+0x11f): In function `sysbus_send_create':
: undefined reference to `dbg'
udev_dbus.o(.text+0x1ce): In function `sysbus_send_remove':
: undefined reference to `dbg'
collect2: ld returned 1 exit status
make: *** [udev] Error 1
(manually wrapped line with gcc in above log).
Thats with dbus-0.20 installed.
--
Tomasz Torcz Elvis Presley nie ?yje. Winni s? developerzy Debiana.
[email protected] -- marcoos w komentarzach na infojama.pl
|> Playing: - Radio 103,4 Blue FM : Najlepiej Dobrana Muzyka prosto z Poznania
Greg KH wrote:
> I've released the 015 version of udev. It can be found at:
> kernel.org/pub/linux/utils/kernel/hotplug/udev-015.tar.gz
> Also in this release is the start of a udev daemon. It's really in 3
> pieces:
> udevsend - sends the hotplug message to the udev daemon
> udevd - the udev daemon, gets the hotplug messages, sorts them
> in proper order, and passes them off to the udev program
> to act apon them.
> udev - still the same.
I'm curious about the rationale behind breaking it up into multiple chunks.
udevsend being separate I assume is so that it can be easily called from
a script while still keeping something persistant?
I'm not sure I see what separating udev and udevd into different
binaries actually buys you. Wouldn't it be just as easy to make udev be
the daemon based on runtime options or something?
Chris
--
Chris Friesen | MailStop: 043/33/F10
Nortel Networks | work: (613) 765-0557
3500 Carling Avenue | fax: (613) 765-2986
Nepean, ON K2H 8E9 Canada | email: [email protected]
On Tue, Jan 27, 2004 at 12:52:19AM -0500, Chris Friesen wrote:
> Greg KH wrote:
> >I've released the 015 version of udev. It can be found at:
> > kernel.org/pub/linux/utils/kernel/hotplug/udev-015.tar.gz
>
> >Also in this release is the start of a udev daemon. It's really in 3
> >pieces:
> > udevsend - sends the hotplug message to the udev daemon
> > udevd - the udev daemon, gets the hotplug messages, sorts them
> > in proper order, and passes them off to the udev program
> > to act apon them.
> > udev - still the same.
>
> I'm curious about the rationale behind breaking it up into multiple chunks.
>
> udevsend being separate I assume is so that it can be easily called from
> a script while still keeping something persistant?
Yes, it will be called from /sbin/hotplug.
> I'm not sure I see what separating udev and udevd into different
> binaries actually buys you. Wouldn't it be just as easy to make udev be
> the daemon based on runtime options or something?
It should be faster this way. We can send off udev to run for different
devices at the same time (blocking for any pending device changes for
any currently running udev instances.)
Take a look at the current code and let us know if you have any
questions (warning, the code is in quite a bit of flux, you might want
to look at the bk tree...)
thanks,
greg k-h
On Mon, 2004-01-26 at 23:50, Greg KH wrote:
> I've released the 015 version of udev. It can be found at:
> kernel.org/pub/linux/utils/kernel/hotplug/udev-015.tar.gz
>
'%D' is still being used in some of the examples ...
Cheers,
--
Martin Schlemmer
On Mon, 2004-01-26 at 23:50, Greg KH wrote:
Is there a known issue that the daemon do not spawn?
--
nosferatu udev-015 # DEVPATH=/block/hda ACTION=add strace -ff udevsend
block
execve("/sbin/udevsend", ["udevsend", "block"], [/* 55 vars */]) = 0
uname({sys="Linux", node="nosferatu", ...}) = 0
brk(0) = 0x804a000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x40000000
open("/etc/ld.so.preload", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
close(3) = 0
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=79435, ...}) = 0
mmap2(NULL, 79435, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40001000
close(3) = 0
open("/lib/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\31YQA4"...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1519742, ...}) = 0
mmap2(0x41500000, 1256716, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
0x41500000
mmap2(0x4162d000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x12c) = 0x4162d000
mmap2(0x41631000, 7436, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x41631000
close(3) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x40015000
set_thread_area({entry_number:-1 -> 6, base_addr:0x40015070,
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0,
limit_in_pages:1, seg_not_present:0, useable:1}) = 0
munmap(0x40001000, 79435) = 0
open("/dev/urandom", O_RDONLY) = 3
read(3, "\271\5\352\360\17,R\261X\341\265\335n\37\335!g\'\17\2\262"...,
32) = 32
close(3) = 0
exit_group(-22) = ?
--
Thanks,
--
Martin Schlemmer
On Mon, 2004-01-26 at 23:50, Greg KH wrote:
I see latest version is very noisy, and although it is a good option
to have, I think it should be tweakable (and recompiling is not always
an option if you want some quick debugging).
Attached is a simple patch to add a config option to udev.conf to toggle
logging.
Thanks,
--
Martin Schlemmer
On Thu, Jan 29, 2004 at 06:52:44AM +0200, Martin Schlemmer wrote:
> On Mon, 2004-01-26 at 23:50, Greg KH wrote:
> > I've released the 015 version of udev. It can be found at:
> > kernel.org/pub/linux/utils/kernel/hotplug/udev-015.tar.gz
> >
>
> '%D' is still being used in some of the examples ...
Ah, thanks. I've fixed that up now.
greg k-h
On Thu, Jan 29, 2004 at 06:52:05PM +0200, Martin Schlemmer wrote:
> On Mon, 2004-01-26 at 23:50, Greg KH wrote:
>
> Is there a known issue that the daemon do not spawn?
Hm, I don't know. This code is under major flux right now...
greg k-h
On Thu, 2004-01-29 at 20:30, Martin Schlemmer wrote:
<snip>
> --- udev-015/logging.c 2004-01-29 19:20:40.673380296 +0200
> +++ udev-015.log_option/logging.c 2004-01-29 20:02:41.316184344 +0200
> @@ -26,6 +26,7 @@
> #include <unistd.h>
> #include <syslog.h>
>
> +#include "udev.h"
> #include "logging.h"
>
>
> @@ -47,6 +48,9 @@ int log_message(int level, const char *f
> {
> va_list args;
>
> + if (0 != strncmp(udev_log_str, "yes", BOOL_SIZE))
This should be:
--
+ if (0 != strncmp(udev_log_str, UDEV_LOG_DEFAULT, BOOL_SIZE))
--
of course ...
> + return 0;
> +
> if (!logging_init)
> init_logging();
> va_start(args, format);
--
Martin Schlemmer
Hi Greg,
perhaps you remember me being a gentoo user wanting to switch to udev.
Well I did so, but am having some problems:
1.) Minor one: Nodes for Nvidia (I am using binary display modules
1.0.5328) ar not created. I have to do it by hand each start-up (written
into loacal.start.):
mknod /dev/nvidia0 c 195 0
mknod /dev/nvidiactl c 195 255
2.) More probelmatic: I am having some serious troubles with my Epson
Perfection USB scanner:
a) I am to dumb to write a rule for it to map it to /dev/usb/scanner0
Excerp of lsusb -v:
Bus 001 Device 004: ID 04b8:010f Seiko Epson Corp. Perfection 1250
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 0
bDeviceProtocol 255
bMaxPacketSize0 8
idVendor 0x04b8 Seiko Epson Corp.
idProduct 0x010f Perfection 1250
bcdDevice 1.00
iManufacturer 1 EPSON
iProduct 2 EPSON Scanner 010F
iSerial 0
bNumConfigurations 1
I don't exactly know which SYSFS_ field to use as the don't match the
lsusb descriptor. I tried various ones, but the scanner always gets
mapped to /dev/scanner0. I managed to get my HP printer to be mapped to
usb/lp0 by using its serial. This is my (latest non working )line for
the scanner:
BUS="usb", SYSFS_model="Perfection 1250", NAME="usb/scanner0"
Now the serious issue: When rebooting or disconnecting the scanner I get
a kernel oops:
hub 1-0:1.0: new USB device on port 2, assigned address 4
drivers/usb/image/scanner.c: USB scanner device (0x04b8/0x010f) now
attached to usb/scanner0
drivers/usb/core/usb.c: registered new driver usbscanner
drivers/usb/image/scanner.c: 0.4.16:USB Scanner Driver
usb 1-2: USB disconnect, address 4
Unable to handle kernel NULL pointer dereference at virtual address 0000001e
printing eip:
f9b370cc
*pde = 00000000
Oops: 0000 [#1]
CPU: 0
EIP: 0060:[<f9b370cc>] Tainted: PF
EFLAGS: 00010282
EIP is at disconnect_scanner+0x2c/0x6d [scanner]
eax: f685f0c0 ebx: f685f0d4 ecx: f9b370a0 edx: 00000007
esi: 00000000 edi: f73194e8 ebp: f9b3abfc esp: f78c3e50
ds: 007b es: 007b ss: 0068
Process khubd (pid: 983, threadinfo=f78c2000 task=f78da720)
Stack: f685f0c0 f9b3ac78 f685f0c0 f9b3ace0 f9a4611b f685f0c0 f685f0c0
f685f100
f685f0d4 f9b3ad00 c026c214 f685f0d4 f685f100 f73194fc f73194c0
f9b36a4f
f685f0d4 f685f0c0 f73194fc f9b3ac0c 00000000 00000000 c021cbf8
f73194fc
Call Trace:
[<f9a4611b>] usb_unbind_interface+0x7b/0x80 [usbcore]
[<c026c214>] device_release_driver+0x64/0x70
[<f9b36a4f>] destroy_scanner+0x4f/0xb0 [scanner]
[<c021cbf8>] kobject_cleanup+0x98/0xa0
[<f9a4611b>] usb_unbind_interface+0x7b/0x80 [usbcore]
[<c026c214>] device_release_driver+0x64/0x70
[<c026c345>] bus_remove_device+0x55/0xa0
[<c026b27d>] device_del+0x5d/0xa0
[<f9a4c6af>] usb_disable_device+0x6f/0xb0 [usbcore]
[<f9a46b76>] usb_disconnect+0x96/0xf0 [usbcore]
[<f9a492df>] hub_port_connect_change+0x30f/0x320 [usbcore]
[<f9a48c13>] hub_port_status+0x43/0xb0 [usbcore]
[<f9a495ba>] hub_events+0x2ca/0x340 [usbcore]
[<f9a4965d>] hub_thread+0x2d/0xf0 [usbcore]
[<c010925e>] ret_from_fork+0x6/0x14
[<c011c9e0>] default_wake_function+0x0/0x20
[<f9a49630>] hub_thread+0x0/0xf0 [usbcore]
[<c0107289>] kernel_thread_helper+0x5/0xc
Code: 80 7e 1e 00 75 2e 85 f6 74 17 8d 46 3c 8b 5c 24 08 8b 74 24
And that's it. I cannot do a clean shut-down anymore, as the scanner
module won't get unloaded. Is this an udev issue or is the module
faulty? I am using latest Linus kernel 2.6.2-rc2.
Other than that I am quite impressed by udev. I disabled the use of an
archive saving all the nodes. This was getting on my nerves with a
former udev release as populating /dev took several seconds. Now I
cannot see any delay. Very well!
bye,
Prakash
On Fri, Jan 30, 2004 at 05:45:41PM +0100, Prakash K. Cheemplavam wrote:
> Hi Greg,
>
> perhaps you remember me being a gentoo user wanting to switch to udev.
> Well I did so, but am having some problems:
>
> 1.) Minor one: Nodes for Nvidia (I am using binary display modules
> 1.0.5328) ar not created. I have to do it by hand each start-up (written
> into loacal.start.):
> mknod /dev/nvidia0 c 195 0
> mknod /dev/nvidiactl c 195 255
Heh, and you expect me to be able to modify a binary driver to work with
udev how? :)
You're on your own here...
> 2.) More probelmatic: I am having some serious troubles with my Epson
> Perfection USB scanner:
> a) I am to dumb to write a rule for it to map it to /dev/usb/scanner0
>
> I don't exactly know which SYSFS_ field to use as the don't match the
> lsusb descriptor. I tried various ones, but the scanner always gets
> mapped to /dev/scanner0. I managed to get my HP printer to be mapped to
> usb/lp0 by using its serial. This is my (latest non working )line for
> the scanner:
What does:
usbinfo -a -p /sys/class/usb/scanner0
say?
That should help you generate a proper rule.
> Now the serious issue: When rebooting or disconnecting the scanner I get
> a kernel oops:
That's because you shouldn't be using the scanner driver at all :)
Please just use the latest xscane, it can talk to the scanner through
usbfs/libusb with no kernel module needed. This is a well known bug if
you search the lkml archives...
Hope this helps.
greg k-h
>>1.) Minor one: Nodes for Nvidia (I am using binary display modules
>>1.0.5328) ar not created. I have to do it by hand each start-up (written
>
> Heh, and you expect me to be able to modify a binary driver to work with
> udev how? :)
Oh OK, then I'll shut up. :-)
> What does:
> usbinfo -a -p /sys/class/usb/scanner0
> say?
Uhm, where to get this? I don't have it and I dunno which gentoo ebuild
installs it. But I found a graphic app called "usbview". It basically
gives the same infos as lsusb. Well, nevermind, I'l try what you said
down. I'll try to get xsane goind with libusb.
Thanx,
Prakash
On Fri, 2004-01-30 at 18:45, Prakash K. Cheemplavam wrote:
> Hi Greg,
>
> perhaps you remember me being a gentoo user wanting to switch to udev.
> Well I did so, but am having some problems:
>
> 1.) Minor one: Nodes for Nvidia (I am using binary display modules
> 1.0.5328) ar not created. I have to do it by hand each start-up (written
> into loacal.start.):
> mknod /dev/nvidia0 c 195 0
> mknod /dev/nvidiactl c 195 255
>
What version baselayout? Unstable use a tarball to save device nodes
...
> 2.) More probelmatic: I am having some serious troubles with my Epson
> Perfection USB scanner:
> a) I am to dumb to write a rule for it to map it to /dev/usb/scanner0
>
> Excerp of lsusb -v:
>
> Bus 001 Device 004: ID 04b8:010f Seiko Epson Corp. Perfection 1250
> Device Descriptor:
> bLength 18
> bDescriptorType 1
> bcdUSB 1.10
> bDeviceClass 255 Vendor Specific Class
> bDeviceSubClass 0
> bDeviceProtocol 255
> bMaxPacketSize0 8
> idVendor 0x04b8 Seiko Epson Corp.
> idProduct 0x010f Perfection 1250
> bcdDevice 1.00
> iManufacturer 1 EPSON
> iProduct 2 EPSON Scanner 010F
> iSerial 0
> bNumConfigurations 1
>
> I don't exactly know which SYSFS_ field to use as the don't match the
> lsusb descriptor. I tried various ones, but the scanner always gets
> mapped to /dev/scanner0. I managed to get my HP printer to be mapped to
> usb/lp0 by using its serial. This is my (latest non working )line for
> the scanner:
>
> BUS="usb", SYSFS_model="Perfection 1250", NAME="usb/scanner0"
>
> Now the serious issue: When rebooting or disconnecting the scanner I get
> a kernel oops:
>
> hub 1-0:1.0: new USB device on port 2, assigned address 4
> drivers/usb/image/scanner.c: USB scanner device (0x04b8/0x010f) now
> attached to usb/scanner0
> drivers/usb/core/usb.c: registered new driver usbscanner
> drivers/usb/image/scanner.c: 0.4.16:USB Scanner Driver
> usb 1-2: USB disconnect, address 4
> Unable to handle kernel NULL pointer dereference at virtual address 0000001e
> printing eip:
> f9b370cc
> *pde = 00000000
> Oops: 0000 [#1]
> CPU: 0
> EIP: 0060:[<f9b370cc>] Tainted: PF
> EFLAGS: 00010282
> EIP is at disconnect_scanner+0x2c/0x6d [scanner]
> eax: f685f0c0 ebx: f685f0d4 ecx: f9b370a0 edx: 00000007
> esi: 00000000 edi: f73194e8 ebp: f9b3abfc esp: f78c3e50
> ds: 007b es: 007b ss: 0068
> Process khubd (pid: 983, threadinfo=f78c2000 task=f78da720)
> Stack: f685f0c0 f9b3ac78 f685f0c0 f9b3ace0 f9a4611b f685f0c0 f685f0c0
> f685f100
> f685f0d4 f9b3ad00 c026c214 f685f0d4 f685f100 f73194fc f73194c0
> f9b36a4f
> f685f0d4 f685f0c0 f73194fc f9b3ac0c 00000000 00000000 c021cbf8
> f73194fc
> Call Trace:
> [<f9a4611b>] usb_unbind_interface+0x7b/0x80 [usbcore]
> [<c026c214>] device_release_driver+0x64/0x70
> [<f9b36a4f>] destroy_scanner+0x4f/0xb0 [scanner]
> [<c021cbf8>] kobject_cleanup+0x98/0xa0
> [<f9a4611b>] usb_unbind_interface+0x7b/0x80 [usbcore]
> [<c026c214>] device_release_driver+0x64/0x70
> [<c026c345>] bus_remove_device+0x55/0xa0
> [<c026b27d>] device_del+0x5d/0xa0
> [<f9a4c6af>] usb_disable_device+0x6f/0xb0 [usbcore]
> [<f9a46b76>] usb_disconnect+0x96/0xf0 [usbcore]
> [<f9a492df>] hub_port_connect_change+0x30f/0x320 [usbcore]
> [<f9a48c13>] hub_port_status+0x43/0xb0 [usbcore]
> [<f9a495ba>] hub_events+0x2ca/0x340 [usbcore]
> [<f9a4965d>] hub_thread+0x2d/0xf0 [usbcore]
> [<c010925e>] ret_from_fork+0x6/0x14
> [<c011c9e0>] default_wake_function+0x0/0x20
> [<f9a49630>] hub_thread+0x0/0xf0 [usbcore]
> [<c0107289>] kernel_thread_helper+0x5/0xc
>
> Code: 80 7e 1e 00 75 2e 85 f6 74 17 8d 46 3c 8b 5c 24 08 8b 74 24
>
>
> And that's it. I cannot do a clean shut-down anymore, as the scanner
> module won't get unloaded. Is this an udev issue or is the module
> faulty? I am using latest Linus kernel 2.6.2-rc2.
>
> Other than that I am quite impressed by udev. I disabled the use of an
> archive saving all the nodes. This was getting on my nerves with a
> former udev release as populating /dev took several seconds. Now I
> cannot see any delay. Very well!
>
> bye,
>
> Prakash
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Martin Schlemmer
On Fri, Jan 30, 2004 at 06:44:00PM +0100, Prakash K. Cheemplavam wrote:
> >What does:
> > usbinfo -a -p /sys/class/usb/scanner0
> >say?
>
> Uhm, where to get this? I don't have it and I dunno which gentoo ebuild
> installs it. But I found a graphic app called "usbview". It basically
> gives the same infos as lsusb. Well, nevermind, I'l try what you said
> down. I'll try to get xsane goind with libusb.
Oops, sorry, that should have been 'udevinfo' not 'usbinfo'.
Not awake yet...
greg k-h
On Fri, 30 Jan 2004 17:45:41 +0100 you wrote in local.lists.kernel:
> Unable to handle kernel NULL pointer dereference at virtual address 0000001e
> printing eip:
> f9b370cc
> *pde = 00000000
> Oops: 0000 [#1]
> CPU: 0
> EIP: 0060:[<f9b370cc>] Tainted: PF
> EFLAGS: 00010282
> EIP is at disconnect_scanner+0x2c/0x6d [scanner]
> eax: f685f0c0 ebx: f685f0d4 ecx: f9b370a0 edx: 00000007
> esi: 00000000 edi: f73194e8 ebp: f9b3abfc esp: f78c3e50
> ds: 007b es: 007b ss: 0068
> Process khubd (pid: 983, threadinfo=f78c2000 task=f78da720)
> Stack: f685f0c0 f9b3ac78 f685f0c0 f9b3ace0 f9a4611b f685f0c0 f685f0c0
> f685f100
> f685f0d4 f9b3ad00 c026c214 f685f0d4 f685f100 f73194fc f73194c0
> f9b36a4f
> f685f0d4 f685f0c0 f73194fc f9b3ac0c 00000000 00000000 c021cbf8
> f73194fc
> Call Trace:
> [<f9a4611b>] usb_unbind_interface+0x7b/0x80 [usbcore]
> [<c026c214>] device_release_driver+0x64/0x70
> [<f9b36a4f>] destroy_scanner+0x4f/0xb0 [scanner]
> [<c021cbf8>] kobject_cleanup+0x98/0xa0
> [<f9a4611b>] usb_unbind_interface+0x7b/0x80 [usbcore]
> [<c026c214>] device_release_driver+0x64/0x70
> [<c026c345>] bus_remove_device+0x55/0xa0
> [<c026b27d>] device_del+0x5d/0xa0
> [<f9a4c6af>] usb_disable_device+0x6f/0xb0 [usbcore]
> [<f9a46b76>] usb_disconnect+0x96/0xf0 [usbcore]
> [<f9a492df>] hub_port_connect_change+0x30f/0x320 [usbcore]
> [<f9a48c13>] hub_port_status+0x43/0xb0 [usbcore]
> [<f9a495ba>] hub_events+0x2ca/0x340 [usbcore]
> [<f9a4965d>] hub_thread+0x2d/0xf0 [usbcore]
> [<c010925e>] ret_from_fork+0x6/0x14
> [<c011c9e0>] default_wake_function+0x0/0x20
> [<f9a49630>] hub_thread+0x0/0xf0 [usbcore]
> [<c0107289>] kernel_thread_helper+0x5/0xc
>
> Code: 80 7e 1e 00 75 2e 85 f6 74 17 8d 46 3c 8b 5c 24 08 8b 74 24
Same problem here. Also with Epson Perfection (640U) and kernel
2.6.2-rc1:
Unable to handle kernel NULL pointer dereference at virtual address 0000001e
printing eip:
c02ba64c
*pde = 00000000
Oops: 0000 [#1]
CPU: 0
EIP: 0060:[<c02ba64c>] Not tainted
EFLAGS: 00010282
EIP is at disconnect_scanner+0x2c/0x6d
eax: e7dc0bc0 ebx: e7dc0bd4 ecx: c02ba620 edx: 00000005
esi: 00000000 edi: e7dbab68 ebp: c03b9dfc esp: c17b1e50
ds: 007b es: 007b ss: 0068
Process khubd (pid: 5, threadinfo=c17b0000 task=e7f8e040)
Stack: e7dc0bc0 c03b9e78 e7dc0bc0 c03b9ee0 c02aa0db e7dc0bc0 e7dc0bc0 e7dc0c00
e7dc0bd4 c03b9f00 c0265414 e7dc0bd4 e7dc0c00 e7dbab7c e7dbab40 c02b9fcf
e7dc0bd4 e7dc0bc0 e7dbab7c c03b9e0c 00000000 00000000 c0207b08 e7dbab7c
Call Trace:
[<c02aa0db>] usb_unbind_interface+0x7b/0x80
[<c0265414>] device_release_driver+0x64/0x70
[<c02b9fcf>] destroy_scanner+0x4f/0xb0
[<c0207b08>] kobject_cleanup+0x98/0xa0
[<c02aa0db>] usb_unbind_interface+0x7b/0x80
[<c0265414>] device_release_driver+0x64/0x70
[<c0265545>] bus_remove_device+0x55/0xa0
[<c026447d>] device_del+0x5d/0xa0
[<c02b043f>] usb_disable_device+0x6f/0xb0
[<c02aa8f6>] usb_disconnect+0x96/0xe0
[<c02ad05f>] hub_port_connect_change+0x30f/0x320
[<c02ac993>] hub_port_status+0x43/0xb0
[<c02ad33a>] hub_events+0x2ca/0x340
[<c02ad3dd>] hub_thread+0x2d/0xf0
[<c010b25e>] ret_from_fork+0x6/0x14
[<c011e9a0>] default_wake_function+0x0/0x20
[<c02ad3b0>] hub_thread+0x0/0xf0
[<c0109289>] kernel_thread_helper+0x5/0xc
> And that's it. I cannot do a clean shut-down anymore, as the scanner
> module won't get unloaded. Is this an udev issue or is the module
> faulty? I am using latest Linus kernel 2.6.2-rc2.
Not related to udev or modules IMHO, since my kernel does not have
module support compiled in and I'm not using udev.
Andre
--
Andre Noll, http://www.mathematik.tu-darmstadt.de/~noll
Greg KH wrote:
> On Fri, Jan 30, 2004 at 06:44:00PM +0100, Prakash K. Cheemplavam wrote:
>
>>>What does:
>>> usbinfo -a -p /sys/class/usb/scanner0
>>>say?
>>
>
> Oops, sorry, that should have been 'udevinfo' not 'usbinfo'.
>
> Not awake yet...
Ok, but it doesn't help, as I guess the scanner0 entry will only appear
if I use the scanner module, which I don't want to...so no scanner0
entry in my case.
But I basicaly managed to get support vie libusb (doing a brute chmod
666 on the proc device). Just need to set the rights correctly to the
device via a script and let hotplug do the rest. Everything new to me,
but makes sense somehow...
Prakash
On Fri, Jan 30, 2004 at 06:03:11PM -0000, Andre Noll wrote:
> On Fri, 30 Jan 2004 17:45:41 +0100 you wrote in local.lists.kernel:
> > Unable to handle kernel NULL pointer dereference at virtual address 0000001e
> > printing eip:
> > f9b370cc
> > *pde = 00000000
> > Oops: 0000 [#1]
> > CPU: 0
> > EIP: 0060:[<f9b370cc>] Tainted: PF
> > EFLAGS: 00010282
> > EIP is at disconnect_scanner+0x2c/0x6d [scanner]
> > eax: f685f0c0 ebx: f685f0d4 ecx: f9b370a0 edx: 00000007
> > esi: 00000000 edi: f73194e8 ebp: f9b3abfc esp: f78c3e50
> > ds: 007b es: 007b ss: 0068
> > Process khubd (pid: 983, threadinfo=f78c2000 task=f78da720)
> > Stack: f685f0c0 f9b3ac78 f685f0c0 f9b3ace0 f9a4611b f685f0c0 f685f0c0
> > f685f100
> > f685f0d4 f9b3ad00 c026c214 f685f0d4 f685f100 f73194fc f73194c0
> > f9b36a4f
> > f685f0d4 f685f0c0 f73194fc f9b3ac0c 00000000 00000000 c021cbf8
> > f73194fc
> > Call Trace:
> > [<f9a4611b>] usb_unbind_interface+0x7b/0x80 [usbcore]
> > [<c026c214>] device_release_driver+0x64/0x70
> > [<f9b36a4f>] destroy_scanner+0x4f/0xb0 [scanner]
> > [<c021cbf8>] kobject_cleanup+0x98/0xa0
> > [<f9a4611b>] usb_unbind_interface+0x7b/0x80 [usbcore]
> > [<c026c214>] device_release_driver+0x64/0x70
> > [<c026c345>] bus_remove_device+0x55/0xa0
> > [<c026b27d>] device_del+0x5d/0xa0
> > [<f9a4c6af>] usb_disable_device+0x6f/0xb0 [usbcore]
> > [<f9a46b76>] usb_disconnect+0x96/0xf0 [usbcore]
> > [<f9a492df>] hub_port_connect_change+0x30f/0x320 [usbcore]
> > [<f9a48c13>] hub_port_status+0x43/0xb0 [usbcore]
> > [<f9a495ba>] hub_events+0x2ca/0x340 [usbcore]
> > [<f9a4965d>] hub_thread+0x2d/0xf0 [usbcore]
> > [<c010925e>] ret_from_fork+0x6/0x14
> > [<c011c9e0>] default_wake_function+0x0/0x20
> > [<f9a49630>] hub_thread+0x0/0xf0 [usbcore]
> > [<c0107289>] kernel_thread_helper+0x5/0xc
> >
> > Code: 80 7e 1e 00 75 2e 85 f6 74 17 8d 46 3c 8b 5c 24 08 8b 74 24
>
> Same problem here. Also with Epson Perfection (640U) and kernel
> 2.6.2-rc1:
Greg, I think this now makes 2 distinct bugs in the scanner kernel
driver. Maybe it should be protected with a BROKEN:
--- 1.6/drivers/usb/image/Kconfig Mon Dec 1 06:51:48 2003
+++ edited/drivers/usb/image/Kconfig Fri Jan 30 16:05:24 2004
@@ -19,7 +19,7 @@
config USB_SCANNER
tristate "USB Scanner support (OBSOLETE)"
- depends on USB
+ depends on USB && BROKEN
help
Say Y here if you want to connect a USB scanner to your computer's
USB port. Please read <file:Documentation/usb/scanner.txt> for more
... or simply removed from the kernel.
--
Tom Rini
http://gate.crashing.org/~trini/
On Thu, Jan 29, 2004 at 01:55:29PM -0800, Greg KH wrote:
> On Thu, Jan 29, 2004 at 06:52:05PM +0200, Martin Schlemmer wrote:
> > On Mon, 2004-01-26 at 23:50, Greg KH wrote:
> >
> > Is there a known issue that the daemon do not spawn?
>
> Hm, I don't know. This code is under major flux right now...
Hi Martin,
sorry, the code in the tree doesn't work.
I decided to try pthreads, cause I gave up with the I/O multiplexing,
forking and earning SIGCHLDS for manipulating the global lists.
The multithreaded udevd takes multiple events at the same time on a unix
domain socket, sorts it in a linked list and handles the timeouts if
events are missing.
It executes our current udev in the background and delays the execution
for events with the same DEVPATH. So we serialize the events only for
different devices.
I've posted the latest patch to the list a few minutes ago.
If you like, I'm happy to hear from your testing :)
If we decide not to stay with the threads model, cause klibc doesn't
support it now and ..., we at least have a working model to implement
in a different way.
thanks,
Kay
On Sat, 2004-01-31 at 05:17, Kay Sievers wrote:
> On Thu, Jan 29, 2004 at 01:55:29PM -0800, Greg KH wrote:
> > On Thu, Jan 29, 2004 at 06:52:05PM +0200, Martin Schlemmer wrote:
> > > On Mon, 2004-01-26 at 23:50, Greg KH wrote:
> > >
> > > Is there a known issue that the daemon do not spawn?
> >
> > Hm, I don't know. This code is under major flux right now...
>
> Hi Martin,
> sorry, the code in the tree doesn't work.
> I decided to try pthreads, cause I gave up with the I/O multiplexing,
> forking and earning SIGCHLDS for manipulating the global lists.
>
> The multithreaded udevd takes multiple events at the same time on a unix
> domain socket, sorts it in a linked list and handles the timeouts if
> events are missing.
> It executes our current udev in the background and delays the execution
> for events with the same DEVPATH. So we serialize the events only for
> different devices.
>
> I've posted the latest patch to the list a few minutes ago.
> If you like, I'm happy to hear from your testing :)
>
> If we decide not to stay with the threads model, cause klibc doesn't
> support it now and ..., we at least have a working model to implement
> in a different way.
>
Thanks - I wanted to have a go at it, but after not working, wanted to
check if it might be my setup, or known issue ... I will see if I can
get time to test your latest patch - anything specific you need testing
of ?
--
Martin Schlemmer
On Sat, Jan 31, 2004 at 07:54:57PM +0200, Martin Schlemmer wrote:
> On Sat, 2004-01-31 at 05:17, Kay Sievers wrote:
> > On Thu, Jan 29, 2004 at 01:55:29PM -0800, Greg KH wrote:
> > > On Thu, Jan 29, 2004 at 06:52:05PM +0200, Martin Schlemmer wrote:
> > > > On Mon, 2004-01-26 at 23:50, Greg KH wrote:
> > > >
> > > > Is there a known issue that the daemon do not spawn?
> > >
> > > Hm, I don't know. This code is under major flux right now...
> >
> > Hi Martin,
> > sorry, the code in the tree doesn't work.
> > I decided to try pthreads, cause I gave up with the I/O multiplexing,
> > forking and earning SIGCHLDS for manipulating the global lists.
> >
> > The multithreaded udevd takes multiple events at the same time on a unix
> > domain socket, sorts it in a linked list and handles the timeouts if
> > events are missing.
> > It executes our current udev in the background and delays the execution
> > for events with the same DEVPATH. So we serialize the events only for
> > different devices.
> >
> > I've posted the latest patch to the list a few minutes ago.
> > If you like, I'm happy to hear from your testing :)
> >
> > If we decide not to stay with the threads model, cause klibc doesn't
> > support it now and ..., we at least have a working model to implement
> > in a different way.
> >
>
> Thanks - I wanted to have a go at it, but after not working, wanted to
> check if it might be my setup, or known issue ... I will see if I can
> get time to test your latest patch - anything specific you need testing
> of ?
Nothing specific, I just need to know if it's working on other setups too :)
Just compile it with DEBUG=true and let the '/etc/hotplug.d/default/udev.hotplug'
symlink point to udevsend instead of udev. udevd will be automatically started.
On reboot the first sequence I get in the syslog is 138 and udevd is pid [51].
Don't mount /udev as tmpfs. udevd places its socket and lock file in there,
long before you mount it over. I just recognized it cause I had two
udevd running. /var/lock doesn't work cause it's also cleaned up after we
are running.
You may watch the syslog while connecting/disconnecting devices, to see if
the events are applied in the right order.
thanks,
Kay
On Sat, 2004-01-31 at 20:15, Kay Sievers wrote:
> > get time to test your latest patch - anything specific you need testing
> > of ?
>
> Nothing specific, I just need to know if it's working on other setups too :)
>
> Just compile it with DEBUG=true and let the '/etc/hotplug.d/default/udev.hotplug'
> symlink point to udevsend instead of udev. udevd will be automatically started.
> On reboot the first sequence I get in the syslog is 138 and udevd is pid [51].
>
> Don't mount /udev as tmpfs. udevd places its socket and lock file in there,
> long before you mount it over. I just recognized it cause I had two
> udevd running. /var/lock doesn't work cause it's also cleaned up after we
> are running.
>
Our setup runs udev for creating /dev _very_ early, so I do not think
this will be a problem - will let you know.
> You may watch the syslog while connecting/disconnecting devices, to see if
> the events are applied in the right order.
>
> thanks,
> Kay
--
Martin Schlemmer
On Sat, Jan 31, 2004 at 08:27:01PM +0200, Martin Schlemmer wrote:
> On Sat, 2004-01-31 at 20:15, Kay Sievers wrote:
>
> > > get time to test your latest patch - anything specific you need testing
> > > of ?
> >
> > Nothing specific, I just need to know if it's working on other setups too :)
> >
> > Just compile it with DEBUG=true and let the '/etc/hotplug.d/default/udev.hotplug'
> > symlink point to udevsend instead of udev. udevd will be automatically started.
> > On reboot the first sequence I get in the syslog is 138 and udevd is pid [51].
> >
> > Don't mount /udev as tmpfs. udevd places its socket and lock file in there,
> > long before you mount it over. I just recognized it cause I had two
> > udevd running. /var/lock doesn't work cause it's also cleaned up after we
> > are running.
> >
>
> Our setup runs udev for creating /dev _very_ early, so I do not think
> this will be a problem - will let you know.
What means very early?
I would expect hotplug events before your setup runs.
Kay
On Sat, 2004-01-31 at 20:39, Kay Sievers wrote:
> On Sat, Jan 31, 2004 at 08:27:01PM +0200, Martin Schlemmer wrote:
> > On Sat, 2004-01-31 at 20:15, Kay Sievers wrote:
> >
> > > > get time to test your latest patch - anything specific you need testing
> > > > of ?
> > >
> > > Nothing specific, I just need to know if it's working on other setups too :)
> > >
> > > Just compile it with DEBUG=true and let the '/etc/hotplug.d/default/udev.hotplug'
> > > symlink point to udevsend instead of udev. udevd will be automatically started.
> > > On reboot the first sequence I get in the syslog is 138 and udevd is pid [51].
> > >
> > > Don't mount /udev as tmpfs. udevd places its socket and lock file in there,
> > > long before you mount it over. I just recognized it cause I had two
> > > udevd running. /var/lock doesn't work cause it's also cleaned up after we
> > > are running.
> > >
> >
> > Our setup runs udev for creating /dev _very_ early, so I do not think
> > this will be a problem - will let you know.
>
> What means very early?
> I would expect hotplug events before your setup runs.
>
True, but then / is ro anyhow. Its before / gets mounted rw, so I would
say its early.
--
Martin Schlemmer