Bug#348221: udev: create /dev/em8300* nodes
On Tue, Jan 17, 2006 at 09:42:57PM +0100, Marco d'Itri wrote: > On Jan 17, Kay Sievers <[EMAIL PROTECTED]> wrote: > > > That driver seem to bypass the kernel driver core. If that's the case > > the driver needs to be fixed as udevd depends on proper MAJOR/MINOR export > > in the environment now, which happens automatically if the class > > interface is used correctly. > Even if it worked with 079? Yes, udev 080 depends on proper driver core integration. With the removal of libsysfs, we have been able to optimize udev's operation not to need to open any sysfs file for a simple event, which is much more efficient. Thanks, Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#348221: udev: create /dev/em8300* nodes
On Tue, Jan 17, 2006 at 09:50:21PM +0100, Kay Sievers wrote:
> On Tue, Jan 17, 2006 at 09:42:57PM +0100, Marco d'Itri wrote:
> > On Jan 17, Kay Sievers <[EMAIL PROTECTED]> wrote:
> >
> > > That driver seem to bypass the kernel driver core. If that's the case
> > > the driver needs to be fixed as udevd depends on proper MAJOR/MINOR export
> > > in the environment now, which happens automatically if the class
> > > interface is used correctly.
>
> > Even if it worked with 079?
>
> Yes, udev 080 depends on proper driver core integration. With the
> removal of libsysfs, we have been able to optimize udev's operation
> not to need to open any sysfs file for a simple event, which is
> much more efficient.
I see this in the driver in file em8300_sysfs.c:
static CLASS_DEVICE_ATTR(dev, S_IRUGO, show_devnum, NULL);
static struct class_device_attribute *em8300_attrs[] = {
&class_device_attr_version,
&class_device_attr_dev,
NULL
};
This needs to be fixed to use the:
dev_t devt; /* dev_t, creates the sysfs "dev" */
in the struct class_device instead. Then udev will create the node
again.
Kay
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#348866: udev: 0.081-1 doesn't boot on 2.6.15 kernel
On Thu, Jan 19, 2006 at 03:24:05PM +0100, Marco d'Itri wrote: > The boot procedure stop after some times at parport without creating devices > (eg ttyS0 and others). > The udev 0.080-1 had same behaviour. Previous versions to 0.080 where > working. On the console I see: > > udevd [811]: udev_done seq 771, pid [892] exit with 1, 178 seconds old > > The above line is repeated from seq 771 to 780. Also, an error like > > udevd [811]: get_msg_from_envbuf: DEVPATH missing, ignore message Hmm, this should be almost impossible to have the kernel send an event without DEVPATH. No idea what's going on here. Are we sure that nothing uses udevsend or any other tool that talks to the udev daemon? Does blacklisting or temporarily renaming the modules "parport_pc" and "parport" and "lp" make the box booting? Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#351606: [EMAIL PROTECTED]: Re: Bug#351606: multipath mis-detects SATA raid1 by default]
On Thu, Feb 09, 2006 at 08:25:14PM +0100, Bastian Blank wrote: > Hi folks > > I got the following bugreport against multipath-tools, which by default > uses scsi_id to detect multiple paths. > > scsi_id on SATA devices (via libata) returns a string like: > | 0ATA_ST3160827AS_Linux_ATA-SCSI_simulator Add this: $ cat /etc/scsi_id.config vendor="ATA",options=-p 0x80 Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#346543: [EMAIL PROTECTED]: Bug#346543: udev netlink problems with kernel 2.6.15 on alpha]
On Sun, Jan 08, 2006 at 07:21:35PM +0100, Marco d'Itri wrote: > Any comments? > Subject: Bug#346543: udev netlink problems with kernel 2.6.15 on alpha > To: [EMAIL PROTECTED] > From: Uwe Schindler <[EMAIL PROTECTED]> > > I installed linux-image-2.6.15-1 (2.6.15-2) from Norbert on my alpha > machine. After rebooting I got some strange effects: > > udevd[pid]: error receiving netlink events: no buffer space > available > I think you should open a bug report directly at udev and tell them > to set the receive buffer size directly in the udev code so that it > does not depend on /proc/variables set before. It could also be an > error in the kernel, but on Norberts machine it works. I do not know... udevd sets the buffer size to 16Mb since some time, without fiddling around with the global sysctrls: http://kernel.org/git/?p=linux/hotplug/udev.git;a=blob;hb=HEAD;f=udevd.c#l781 If that's not working, it's probably a kernel bug on your architecture. Works fine for me, here is a big buffer filled up with a stopped udevd: $ cat /proc/net/netlink sk Eth PidGroups Rmem Wmem Dump Locks dfd86000 0 0 00 2 f7779800 0 3259 0011 00 2 dfe3f200 9 0 00 2 dfc27200 10 0 00 2 f1885200 15 6396 2789309 0 2 dffbce00 15 0 00 2 dfe3fe00 16 0 00 2 Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#346543: [EMAIL PROTECTED]: Bug#346543: udev netlink problems with kernel 2.6.15 on alpha]
On Mon, Jan 09, 2006 at 09:02:22AM +0100, Uwe Schindler wrote: > At 02:00 09.01.2006, Kay Sievers wrote: > >On Sun, Jan 08, 2006 at 07:21:35PM +0100, Marco d'Itri wrote: > >> Any comments? > > > >> Subject: Bug#346543: udev netlink problems with kernel 2.6.15 on alpha > >> To: [EMAIL PROTECTED] > >> From: Uwe Schindler <[EMAIL PROTECTED]> > >> > >> I installed linux-image-2.6.15-1 (2.6.15-2) from Norbert on my alpha > >> machine. After rebooting I got some strange effects: > >> > >> udevd[pid]: error receiving netlink events: no buffer space > >> available > > > >> I think you should open a bug report directly at udev and tell them > >> to set the receive buffer size directly in the udev code so that it > >> does not depend on /proc/variables set before. It could also be an > >> error in the kernel, but on Norberts machine it works. I do not know... > > > >udevd sets the buffer size to 16Mb since some time, without fiddling > >around with the global sysctrls: > > > >http://kernel.org/git/?p=linux/hotplug/udev.git;a=blob;hb=HEAD;f=udevd.c#l781 > > > >If that's not working, it's probably a kernel bug on your architecture. > >Works fine for me, here is a big buffer filled up with a stopped udevd: > > $ cat /proc/net/netlink > > sk Eth PidGroups Rmem Wmem Dump Locks > > dfd86000 0 0 00 2 > > f7779800 0 3259 0011 00 2 > > dfe3f200 9 0 00 2 > > dfc27200 10 0 00 2 > > f1885200 15 6396 2789309 0 2 > > dffbce00 15 0 00 2 > > dfe3fe00 16 0 00 2 > > Hm interesting. In your code I see, that you only set the actual > buffer size (not the maximum): > setsockopt(uevent_netlink_sock, SOL_SOCKET, SO_RCVBUFFORCE, > &buffersize, sizeof(buffersize)); /* == 16*1024*1024 */ No, it's "...FORCE"! > I had the same problem. When leaving out in my udev-fix script the > setting of that MAX value BEFORE the actual value via /proc it does > not work. I could check both values (MAX and CURRENT) before setting > them on boot time with a "cat" command to printout in the script as > soon as I reboot. > > As I know from the "maximum file descriptors" thing that userspace > programs can only set the current value, not the maximum value for > the whole system. On Linux this maximum value can only be set by > /proc and in Solaris in the kernel configuration file. > > Could it be that on alpha the maximum value is too small initially? No, idea, but as it obviously works on the common architectures, you need to track that on the failing box, I don't have such a system to try. Good luck, Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#350235: pcmciautils ?
On Sun, Jan 29, 2006 at 12:07:50PM +0100, Marco d'Itri wrote: > On Jan 29, di dit <[EMAIL PROTECTED]> wrote: > > I can see why the rule does not work, at the removable==1 level we have > BUS=="block" instead of the expected BUS=="ide", and DRIVER is only > available at the upper level. > Kay? Correct, that broke with the stricter logic to select the parent device in the recent udev. I'll go fix udev also to look at SYSFS at the device we received the event for and not only at the device selected by BUS. Then it should work again. In the case you compile udev yourself, can you check, if adding this to udev_rules.c fixes this? I'm on the road at the moment and don't have an IDE device, but the same logic works when testing with scsi. value = sysfs_attr_get_value(udev->dev_parent->devpath, key_name); if (value == NULL) + value = sysfs_attr_get_value(udev->dev->devpath, key_name); + if (value == NULL) goto try_parent; strlcpy(val, value, sizeof(val)); Thanks, Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#350235: pcmciautils ?
On Sun, Jan 29, 2006 at 12:07:50PM +0100, Marco d'Itri wrote:
> On Jan 29, di dit <[EMAIL PROTECTED]> wrote:
>
> I can see why the rule does not work, at the removable==1 level we have
> BUS=="block" instead of the expected BUS=="ide", and DRIVER is only
> available at the upper level.
> Kay?
>
> BUS=="ide", SYSFS{removable}=="1", DRIVER!="ide-cdrom", GOTO="no_volume_id"
>
>
> Maybe a rule like this one would work, but is it correct? (And how are
> people going to figure this?)
>
> BUS=="ide", SYSFS{block/removable}=="1", DRIVER!="ide-cdrom",
> GOTO="no_volume_id"
Sure, it is correct, but we should better not introduce dependencies on
the weird symlinks that crosslink "class devices" and "devices", they
will probably go away when we change /sys/devices to a sane layout and
the "block device" will just become a real child of the "device".
Changing udev to look with SYSFS{} at the device we got the event for,
should work just fine.
Thanks,
Kay
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#350490: udev 0.083-1 do not mount my usb drives (disk, mobile). With 0.082 it works. I downgrade it to work again
On Wed, Feb 01, 2006 at 12:00:26AM +0100, Sjoerd Simons wrote:
> On Tue, Jan 31, 2006 at 10:54:08PM +0100, Marco d'Itri wrote:
> > On Jan 30, Michael Ott <[EMAIL PROTECTED]> wrote:
> >
> > > I believe that dbus or fam will mount my disk. But my mobile memory will
> > > mount with udev 0.082 and not with 0.083. I remember that it works
> > > yesterday and after update it did not work.
> > I see that #350762 has been opened too against HAL, but I still do not
> > know what's wrong. Sjoerd, do you have any ideas about this? Kay?
> >
> > The relevant rules are:
> >
> > ENV{SEQNUM}=="[0-9]*", ENV{UDEVD_EVENT}=="1",
> > RUN+="/usr/lib/hal/hal.hotplug"
> >
> > BUS="scsi",KERNEL="sd[a-z]*",
> > PROGRAM="/etc/udev/scripts/device-removable.sh %k 'usb ieee1394'",
> > RESULT="1", MODE="0640", GROUP="hal"
> >
> > BUS="usb", KERNEL="ub[a-z]*", MODE="0640", GROUP="hal"
>
> As you guessed correctly in an earlier mail. Not adding $SUBSYSTEM as $1 to
> programs anymore breaks the hal hotplug helper.
>
> The hal currently in experimental has udev passing events over a socket
> instead
> of using the helper, so it works fine. Didn't upload it to unstable directly
> because it had the first version of my priv. patch applied to it.
>
> Luckily the priv. sep. patch seems to work fine. So i'm planning to upload
> hal
> 0.5.6 with the current priv. sep. patch and some other patches from HAL CVS
> to
> unstable which should fix this issue :)
Oh, yeah, sorry forgot the old hal helper cause we don't use it anymore for a
long time. Adding $env{SUBSYSTEM} to the rule should fix it. The current HAL
will
install its own rule in the udev directory by default.
Kay
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#350235: [EMAIL PROTECTED]: Re: Re: Bug#350235: ide pcmcia problem]
> From: Marc Haber <[EMAIL PROTECTED]>
> To: Marco d'Itri <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Cc: Marc Haber <[EMAIL PROTECTED]>
> Subject: Re: Re: Bug#350235: ide pcmcia problem
>
> found 350235 0.84-1
> thanks
>
> On Sat, Jan 28, 2006 at 01:51:39PM +0100, Marco d'Itri wrote:
> > Indeed... But maybe the recent changes in sysfs processing in udev broke
> > the rule. First, try removing the symlink to persistent.rules to verify
> > that it actually is what is exposing the bug, then after you succesfully
> > loaded the driver check with something like:
> >
> > udevinfo -a -p /block/hde/hde1
> >
> > why it's not working.
>
> I have seen the same issues on my notebook, with udev 0.84-1.
>
> > A workaround may be to add again this rule:
> >
> > BUS=="ide", SYSFS{../removable}=="1", DRIVER!="ide-cdrom",
> > GOTO="no_volume_id"
>
> I needed that addition to make the PCMCIA CF card work.
Hmm, I found a CF card and the rule works fine for me:
match_key: key DRIVER value='ide-cdrom'
match_key: match DRIVER 'ide-cdrom' <-> 'ide-disk'
match_key: DRIVER is true (non-matching value)
match_key: key BUS value='ide'
match_key: match BUS 'ide' <-> 'ide'
match_key: BUS is true (matching value)
match_rule: check 1 SYSFS keys
sysfs_attr_get_value: open
'/devices/pci:00/:00:1e.0/:04:00.0/0.0/ide0/0.0'/'removable'
sysfs_attr_get_value: new uncached attribute
'/sys/devices/pci:00/:00:1e.0/:04:00.0/0.0/ide0/0.0/removable'
sysfs_attr_get_value: add to cache
'/sys/devices/pci:00/:00:1e.0/:04:00.0/0.0/ide0/0.0/removable'
sysfs_attr_get_value: attribute
'/sys/devices/pci:00/:00:1e.0/:04:00.0/0.0/ide0/0.0/removable' does
not exist
sysfs_attr_get_value: open '/block/hda'/'removable'
sysfs_attr_get_value: new uncached attribute '/sys/block/hda/removable'
sysfs_attr_get_value: add to cache '/sys/block/hda/removable'
sysfs_attr_get_value: cache '/sys/block/hda/removable' with value '1'
match_rule: removed 0 trailing whitespace chars from '1'
match_key: key SYSFS value='1'
match_key: match SYSFS '1' <-> '1'
match_key: SYSFS is true (matching value)
match_rule: all 1 SYSFS keys matched
udev_rules_get_name: moving forward to label 'persistent_end'
What does udevtest print on your box?
This is for the CF card:
pim:/home/kay/work/src/udev # ./udevtest /block/hda
main: looking at device '/block/hda' from subsystem 'block'
udev_rules_get_name: no node name set, will use kernel name 'hda'
create_node: creating device node '/dev/hda', major = '3', minor = '0', mode
= '0640', uid = '0', gid = '6'
main: run: '/lib/udev/idedma.sh /dev/hda'
main: run: 'socket:/org/freedesktop/hal/udev_event'
main: run: 'socket:/org/kernel/udev/monitor'
This is for a real disk:
pim:/home/kay/work/src/udev # ./udevtest /block/sda
main: looking at device '/block/sda' from subsystem 'block'
run_program: '/sbin/usb_id -x'
run_program: '/sbin/usb_id' returned with status 1
run_program: '/sbin/scsi_id -g -x -s /block/sda -d /dev/.tmp-8-0'
run_program: '/sbin/scsi_id' (stdout) 'ID_VENDOR=ATA'
run_program: '/sbin/scsi_id' (stdout) 'ID_MODEL=HTS726060M9AT00'
run_program: '/sbin/scsi_id' (stdout) 'ID_REVISION=MH4O'
run_program: '/sbin/scsi_id' (stdout)
'ID_SERIAL=SATA_HTS726060M9AT00_MRH453M4HWHG7B'
run_program: '/sbin/scsi_id' (stdout) 'ID_TYPE=disk'
run_program: '/sbin/scsi_id' (stdout) 'ID_BUS=scsi'
run_program: '/sbin/scsi_id' returned with status 0
udev_rules_get_name: add symlink
'disk/by-id/scsi-SATA_HTS726060M9AT00_MRH453M4HWHG7B'
run_program: '/sbin/path_id /block/sda'
run_program: '/sbin/path_id' (stdout) 'ID_PATH=pci-:00:1f.2-scsi-0:0:0:0'
run_program: '/sbin/path_id' returned with status 0
udev_rules_get_name: add symlink 'disk/by-path/pci-:00:1f.2-scsi-0:0:0:0'
run_program: '/sbin/vol_id --export /dev/.tmp-8-0'
run_program: '/sbin/vol_id' returned with status 4
run_program: '/sbin/edd_id --export /dev/.tmp-8-0'
run_program: '/sbin/edd_id' (stdout) 'ID_EDD=int13_dev80'
run_program: '/sbin/edd_id' returned with status 0
udev_rules_get_name: add symlink 'disk/by-id/edd-int13_dev80'
udev_rules_get_name: no node name set, will use kernel name 'sda'
create_node: creating device node '/dev/sda', major = '8', minor = '0', mode
= '0640', uid = '0', gid = '6'
create_node: creating symlink
'/dev/disk/by-id/scsi-SATA_HTS726060M9AT00_MRH453M4HWHG7B' to '../../sda'
create_node: creating symlink
'/dev/disk/by-path/pci-:00:1f.2-scsi-0:0:0:0' to '../../sda'
create_node: creating symlink '/dev/disk/by-id/edd-int13_dev80' to '../../sda'
main: run: 'socket:/org/freedesktop/hal/udev_event'
main: run: 'socket:/org/kernel/udev/monitor'
Kay
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#350613: [EMAIL PROTECTED]: Bug#350613: Minor typo in manpage]
On Mon, Jan 30, 2006 at 10:51:10PM +0100, Marco d'Itri wrote: > small typo in the manpage: >GOTO Jumps to the next LABEL with a matching gname > should read >GOTO Jumps to the next LABEL with a matching name Fixed. Thanks, Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#350235: [EMAIL PROTECTED]: Re: Re: Bug#350235: ide pcmcia problem]
On Fri, Feb 03, 2006 at 12:32:40PM +0100, Marc Haber wrote: > On Wed, Feb 01, 2006 at 10:52:25AM +0100, Marco d'Itri wrote: > > On Feb 01, Marc Haber <[EMAIL PROTECTED]> wrote: > > > On Wed, Feb 01, 2006 at 03:08:42AM +0100, Kay Sievers wrote: > > > > What does udevtest print on your box? > > > With or without the block/removable rule in place? With or without the > > > CF card inserted? > > With the rule and the card. > > $ sudo udevtest /block/hde > Password: > main: looking at device '/block/hde' from subsystem 'block' > run_program: '/sbin/cdrom_id --export /dev/.tmp-33-0' > run_program: '/sbin/cdrom_id' returned with status 3 > udev_rules_get_name: no node name set, will use kernel name 'hde' > create_node: creating device node '/dev/hde', major = '33', minor = '0', mode > = '0660', uid = '0', gid = '25' > main: run: 'socket:/org/kernel/udev/monitor' > main: run: '/etc/init.d/hdparm hotplug' > main: run: 'udev_run_hotplugd block' > main: run: 'udev_run_devd block' > > Sorry for taking so much time. Oh, you need to make sure, that cdrom_id and nothing else runs on _any_ removable ide drive, just like the persistent disk rules are skipped. Every open() of a removable ide device will cause a revalidation of the partition table, which caues the events to loop. Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#317333: [EMAIL PROTECTED]: Bug#317333: acknowledged by developer (Bug#317333: fixed in udev 0.063-1)]
On Thu, Aug 25, 2005 at 07:47:56PM +0200, Marco d'Itri wrote: > An interesting comment. > Subject: Bug#317333: acknowledged by developer (Bug#317333: fixed in udev > 0.063-1) > From: Mourad De Clerck <[EMAIL PROTECTED]> > To: Marco d'Itri <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > On Thu, 2005-08-25 at 16:49 +0200, Marco d'Itri wrote: > > On Aug 14, Mourad De Clerck <[EMAIL PROTECTED]> wrote: > > > > > Unfortunately, using linux-image-2.6.12-1-k7 2.6.12-2 and udev 0.066-1 I > > > can still reproduce this bug. After boot certain devices don't show up, > > One of the udev maintainers suggested to try adding mousedev to > > /etc/modules. > > > > Actually, they are on to something because I had just found out > something significant. > > I had 2 things in my /etc/modules: > > mousedev > ide-cd > > The reason why I added mousedev is that (quite) a while back it wouldn't > get automatically loaded. ide-cd was a debian default if I am not > mistaken. > > I commented both out, and on reboot /dev/input/mice was there! Strange, the event seems to get lost. If you restore the failing setup and add a "sleep 1" before udevstart, does it work then? > Just to make sure there were no other devices missing, I started > udevstart again and compared the before and afters: > > --- dev_before_udevstart.txt2005-08-25 16:20:35.0 +0200 > +++ dev_after_udevstart.txt 2005-08-25 16:20:54.0 +0200 > @@ -1,2 +1,5 @@ > /dev/ > +/dev/dvd1 > +/dev/cdrw1 > +/dev/cdrom1 > /dev/vcsa1 > > Now this is weird (and new) - there's no clear reason why extra > (unecessary) dev nodes are made afterwards, and why he didn't make them > in the first place (on boot). The nodes point to the same thing: > > lrwxrwxrwx 1 root root 3 Aug 25 16:19 /dev/dvd -> hdc > lrwxrwxrwx 1 root root 3 Aug 25 16:20 /dev/dvd1 -> hdc > > (similarly for cdrw/cdrw1, and cdrom/cdrom1 - there's no dvd0) > > I guess it's because I commented out ide-cd too ...? > > It's still very weird that modules listed in /etc/modules have this > effect on udev. In the end the same modules are loaded, just at > different times (and maybe twice?). No, this is ok. %e is used, i think. That %e is not very smart and just increases the number if the udevdb is not cleared before the run of udevstart. Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#317333: The case of udev and the missing /dev/input/mice
On Wed, Sep 21, 2005 at 03:38:06AM +0100, Scott James Remnant wrote: > Background: in the upcoming Ubuntu 5.10 we've been having some problems > with /dev/input/mice not being created on startup despite the "mousedev" > module being hard-loaded early in the boot sequence. > (http://bugzilla.ubuntu.com/show_bug.cgi?id=12915 for those interested). > > Debian has had similar problems too (http://bugs.debian.org/317333) and > found that starting udevd earlier manually seemed to fix it. Yes, that's a good way to fix it. > After much debugging, I've finally figured out what's going on ... it's > a bit of a story, but here goes... Great, we finally have an idea why this happens. Thanks for finding that out. > On receiving the netlink event for the printer port, udevd disables > receipt of any "sequence numbered" events from udevsend (ie. those that > will almost certainly be duplicated over the netlink socket). > Unfortunately this means all the udevsend events we're about to receive > from the processes that backed off a second or so while fighting over > who got to start udevd[1]. > > These udevsend processes deliver their events to udevd, which cheerfully > ignores them because it thinks it's going to get another copy over the > netlink socket any second now. Unfortunately the netlink event has > already been and gone, and we just ignored an event we weren't supposed > to. > > > The two problems as I see them are: > > 1) The fact that receiving a netlink event disables sequence numbered >udevsend events, when there's already code to deal with de-duping >events anyway. Is there actually any need for this additional check, >can't we just queue both events and have them ignored by >msg_queue_insert() ? > > 2) That this ignoring of events is done at receipt, rather than in queue >order. This means that the "later" parport_pc netlink event is able >to disable queueing of udevsend events with a lower sequence number. > > I can envisage that #1 is necessary in case the time between receiving > the udevsend and netlink event is so long that we've already processed > and removed one of the events by the time the second is queued. Yes, that was the reason for ignoring the incoming messages. > In which case the problem becomes fixing #2, however unless the kernel > promises strict ordering of events over the netlink socket (which I > doubt, otherwise it wouldn't need sequence numbers) Netlink events are always in the right order. The SEQNUM is only needed for the forked events. > we can't assume > that we've received all of the pre-netlink events we are going to. Right, as "/proc/sys/kernel/hotplug" events are forked processes, you will never know when and in which order they will arrive. > I suspect the right solution is actually to implement history of what > events we've already processed, and de-dupe them that way; rather than > ignoring messages on receipt. We could just accept all events with a lower sequence number as the first netlink event's one, that may fix it. The "right solution" is to start udevd as one of the first things after taking over control from the kernel. This way you will only catch the events for the last "non driver core" subsystem, the input layer. At the time the input layer is fixed, the need for udevsend will completely go away and /proc/sys/kernel/hotplug should be disabled when taking over control from the kernel - it is only needed in initramfs. After input is fixed, the whole event reordering and timeout handling will be removed from udevd and we need to start udevd manually anyway. Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#329226: udevstart breaks when device not responding
On Tue, Sep 20, 2005 at 11:28:17PM +0200, Marco d'Itri wrote: > FYI. It's unreproducible even by the submitter. That's one of the problems with a synchronous udevstart. It should go away for a lot of other reasons too and I refused all the "coldplug" patches for udevstart for that reason. I expect udevstart kills (alarm) itself after 2 minutes, while it hangs in the *_id programs. There is no easy fix for this. Making udevsynthesize working good enough, which should not have this problem, seems like the best option. Kay > - Forwarded message from Stephen Frost <[EMAIL PROTECTED]> - > > Subject: Bug#329226: udevstart breaks when device not responding > Reply-To: Stephen Frost <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > X-Debian-PR-Message: report 329226 > X-Debian-PR-Package: udev > X-Debian-PR-Keywords: > From: Stephen Frost <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > > Package: udev > Version: 0.070-2 > Severity: Important > > Greetings, > > When installing udev for the first time on a system which has access > to snapshots of other partitions (on my SAN), and those snapshots were > disabled (which means IO failures when trying to read them), udev > failed to install rather badly. > > Populating the new /dev filesystem temporarily mounted on > /tmp/udev.vrFxvY/... > > ... > > [587655.084649] SCSI error : <5 0 0 0> return code = 0x802 > [587655.084682] sdc: Current: sense key: Hardware Error > [587655.084713] <> ASC=0x84 ASCQ=0x0ASC=0x84 ASCQ=0x0 > [587655.084750] end_request: I/O error, dev sdc, sector 6 > > ... > > root 8075 0.0 0.0 2944 1424 pts/1S+ 11:19 0:00 \ >/bin/sh -e /var/lib/dpkg/info/udev.postinst configure > root 8111 0.2 0.0 2200 1144 pts/1S+ 11:19 0:00 \ >/sbin/udevstart > root 8480 0.0 0.0 1820 444 pts/1D+ 11:19 0:00 \ >/sbin/vol_id --export /tmp/udev.gzcWTS/.tmp-8-32 > > ... > > dpkg: error processing udev (--configure): >subprocess post-installation script returned error exit status 1 > > ... > > I enabled the snapshots for the moment to get udev installed. I'm > curious as to what would happen if I rebooted while the snapshots were > disabled though. I do need udev, unfortunately, because multipath > depends on it. I'm pretty sure this is a situation udev needs to be > able to handle though. > > Thanks, > > Stephen > > - End forwarded message - > - Forwarded message from Stephen Frost <[EMAIL PROTECTED]> - > > Subject: Bug#329226: udevstart breaks when device not responding > Reply-To: Stephen Frost <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > X-Debian-PR-Message: report 329226 > X-Debian-PR-Package: udev > X-Debian-PR-Keywords: > From: Stephen Frost <[EMAIL PROTECTED]> > To: Marco d'Itri <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > X-Editor: Vim http://www.vim.org/ > X-Info: http://www.snowman.net > X-Operating-System: Linux/2.4.24ns.3.0 (i686) > X-Uptime: 12:19:49 up 101 days, 8:35, 12 users, load average: 0.07, 0.10, > 0.09 > X-Spam-Level: > X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER > autolearn=no version=2.60-bugs.debian.org_2005_01_02 > > * Marco d'Itri ([EMAIL PROTECTED]) wrote: > > On Sep 20, Stephen Frost <[EMAIL PROTECTED]> wrote: > > > dpkg: error processing udev (--configure): > > >subprocess post-installation script returned error exit status 1 > > Did you try to kill some process? I can't see how an error could be > > propagated from vol_id to postinst. > > Nope, I didn't kill any processes. It took it a while to fail. In case > it gets lost in irc: > > 12:10 Md: It's in the bug log > 12:11 Md: Basically, vol_id was failing. > 12:11 'cause it was trying to read the device, and the device > was, like, 'uh, no.' > 12:11 I didn't kill off any processes, no... > 12:12 Md: Well, alright, vol_id was the process which was > running when I was seeing > stuff in dmesg show up (the stuff that's in the bug > log) > 12:12 Md: It's possible there was some other issue making > udevstart fail.. > 12:13 Md: But when I enabled the snapshots, I saw vol_id go > past the first set of things > it was being run on. > 12:13 (--export /tmp/udev.gzcWTS/.tmp-8-32 went to, like, > 8-16, etc, iirc) > 12:14 It looked like udevstart was running vol_id multiple > times, and checking if it > worked or not each time, and if it didn't, was exiting > unhappily. > > It seems to me that vol_id errors should probably be non-fatal, but I'm > not entirely sure what it's doing. In this instance I would still want > the appropriate scripts to be run for the device (to properly set up the > multipath stuff for the device) even if the device can't be read at the > moment.
Bug#328960: /sbin/udevsend: main: environment buffer too small, probably not called by the kernel
On Sat, Sep 24, 2005 at 01:29:34AM +0200, Marco d'Itri wrote: > On Sep 18, Kay Sievers <[EMAIL PROTECTED]> wrote: > > > The kernel event buffer is smaller than the udevsend buffer. I expect > > udevsend is not called from the kernel. What's in /proc/sys/kernel/hotplug? > > Or maybe some symlink does still exist in the hotplug.d/ dir to call > > udevsend? Or something like this... > > Actually udevsend *was* not called by the kernel, but by the hal > post-installation script... Is this really bad? This cannot work cause the system shell environment is much too big. Invoke it with "env -i". Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#294123: udev: Bad parsing of regular expressions in *.rules
On Tue, 2005-02-08 at 21:53 -0800, Greg KH wrote: >On Wed, Feb 09, 2005 at 03:24:31AM +0100, Kay Sievers wrote: >> Can't you match against some interface attributes in sysfs, which are >> telling you which one is the first interface of this device? >> >> You may compare: >> udevinfo -a -p /class/tty/ttyUSB0 >> udevinfo -a -p /class/tty/ttyUSB1 >> >> if you find a difference between both interfaces to match against, that >> is not dependent on the kernel device name. > >This is a real tough one to try to match on, as these both point to the >same exact physical device. Same USB interface even. It's a pain, >stupid palm devices... Ahh, I see. So we may follow the link to the physical device and look for the name of the _first_ serial interface of this device? Would this solve the problem? Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#294123: udev: Bad parsing of regular expressions in *.rules
On Mon, 2005-02-14 at 09:30 -0800, Greg KH wrote: >On Sun, Feb 13, 2005 at 04:14:41AM +0100, Kay Sievers wrote: >> On Tue, 2005-02-08 at 21:53 -0800, Greg KH wrote: >> >On Wed, Feb 09, 2005 at 03:24:31AM +0100, Kay Sievers wrote: >> >> Can't you match against some interface attributes in sysfs, which are >> >> telling you which one is the first interface of this device? >> >> >> >> You may compare: >> >> udevinfo -a -p /class/tty/ttyUSB0 >> >> udevinfo -a -p /class/tty/ttyUSB1 >> >> >> >> if you find a difference between both interfaces to match against, that >> >> is not dependent on the kernel device name. >> > >> >This is a real tough one to try to match on, as these both point to the >> >same exact physical device. Same USB interface even. It's a pain, >> >stupid palm devices... >> >> Ahh, I see. So we may follow the link to the physical device and look >> for the name of the _first_ serial interface of this device? Would this >> solve the problem? > >Heh, not quite, as you usually want the _second_ serial interface to >sync off of, the first one is not useful at all (well, some tools use >it, but 99% of the users never will care about it.) > >And then there's the fun problem of some Sony devices creating two >serial "devices" where the second one is just a "fake" one, and you >really need to connect to the first. > >Bah, sometimes I really hate Palm... Yeah, I can imagine that. But would it be possible to get the right one with the information available in sysfs? Someone could write a small script which matches the vendor and return a symlink for the _right_ interface. Would that work? Btw: The "Bad parsing ..." wasn't a udev issue. It's solved. Thanks, Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#271997: hal 0.4.5 "It's going to go 100% failure in 72 hours." released
On Sun, 2005-01-16 at 18:08 +0100, Sjoerd Simons wrote:
> On Wed, Jan 12, 2005 at 05:33:39PM -0500, David Zeuthen wrote:
> >
> > Hey,
> >
> > Another week, another HAL release :-). Download from
> >
> > http://freedesktop.org/~david/dist/hal-0.4.5.tar.gz
> >
> > Changes from 0.4.4:
> >
> > - Fix bug with vfat label reading (Kay Sievers, Fredrik Nilsson, Joeny)
>
> This seems to have fixed some filesystems and broken others. I got the
> following from a debian user:
>
> I just upgraded hal (from 0.4.4-1) and noticed, that it doesn't detect
> the volume label of my usb external drive correctly anymore. I found
> this bug, and this change seems to be the cause...
>
> Both mlabel and udev_volume_id show the correct label ("ICYBOX"), but
> hal uses "AD", which is pretty useless...
What does:
hald --verbos=yes --daemon=no
print?
Thanks,
Kay
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#271997: hal 0.4.5 "It's going to go 100% failure in 72 hours." released
On Sun, 2005-01-16 at 18:36 +0100, David Eriksson wrote:
> On Sun, 2005-01-16 at 18:17 +0100, Kay Sievers wrote:
> > On Sun, 2005-01-16 at 18:08 +0100, Sjoerd Simons wrote:
> > >
> > > Both mlabel and udev_volume_id show the correct label ("ICYBOX"), but
> > > hal uses "AD", which is pretty useless...
> >
> > What does:
> > hald --verbos=yes --daemon=no
> >
> > print?
>
> I get about the same error, my mount point gets called "Ap":
>
> http://www.2good.nu/blandat/hald-mountpoint.log
There was only a one-line change in the FAT16 label reading code, but I
can't see how this is wrong.
What does:
dd if=/dev/sda1 bs=512 count=32 skip=32256 | hexdump -C
print for this volume? It will print the complete raw data of the root
directory entries.
And did you try to read the volume name on Windows?
Thanks,
Kay
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#297481: hotplug: Fails to load firmware for ipw2200 after upgrade
On Tue, 2005-03-01 at 21:26 +0100, Marco d'Itri wrote: >reassign 297481 kernel-image-2.6.8-i386 >thanks > >On Mar 01, Kay Sievers <[EMAIL PROTECTED]> wrote: > >> This kernel will not work correctly with managed events. It has holes in >> the sequence numbers. You need at least 2.6.10 if I remember correctly. >This sucks, because the next Debian release will ship 2.6.8 as the >default 2.6 kernel. Do you know what needs to be backported to fix this? It's all in lib/kobject_uevent.c and should be trivial. It was changed to increment the seqnum counter only if the kset wants to emit the event. >What else does this break? I should be safe, I think. Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#298192: udev: segfault with new rule on startup
On Tue, 2005-03-08 at 00:03 +0100, Marco d'Itri wrote:
> This rule causes udevstart 054 to segfault:
>
> BUS="pci", SUBSYSTEM="net", DRIVER="ipw2100", NAME="wlan"
>
> - Forwarded message from Thomas Breitner <[EMAIL PROTECTED]> -
>
> Subject: Bug#298192: udev: segfault with new rule on startup
> Reply-To: [EMAIL PROTECTED], [EMAIL PROTECTED]
> From: Thomas Breitner <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
>
> Thanks, here it is:
>
> mala:~/sourcen/udev-0.054# /etc/init.d/udev restart
> Recreating device nodes.../etc/init.d/udev: line 216: 10361 Segmentation
> fault udevstart
> mala:~/sourcen/udev-0.054# gdb /sbin/udevstart
> GNU gdb 6.3-debian
> Program received signal SIGSEGV, Segmentation fault.
> strcmp_pattern (p=0x805cc60 "ipw2100", s=0x1c4 )
> at namedev.c:50
> 50 if (s[0] == '\0') {
> (gdb) where
> #0 strcmp_pattern (p=0x805cc60 "ipw2100", s=0x1c4 bounds>) at namedev.c:50
Yeah, that's a bad bug in the rule matching. The sysfs_device is NULL,
and we try to find the name here. I will fix it.
But I don't know why the sysfs_device is NULL in this case, I can't
reproduce it with the same hardware. Thomas, it would be nice if you can
send the output of:
udevinfo -a -p /sys/class/net/eth
Thanks,
Kay
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#411967: udev: Name conflicts in z20_persistent.rules
> The problem lies within /dev/disk/by-id. Even though the card reader > has four slots, it only has one serial number, so only one link is > created in /dev/disk/by-id. It's called > usb-Generic_STORAGE_DEVICE_05170 and it points to one of > /dev/sd[abcd], not always the same one. I suppose there's a race > condition somewhere. > The card reader is a Kingston FCR-HS215/1, if that matters. > Vendor/device ids: 11b0:6108. Yes, that's a known issue. So far, we've seen that only for very cheap devices, not something with a brand name on it. Usually, the different ports on a card reader have different names: /dev/disk/ |-- by-id | |-- usb-_CF_TS-RD13_2511 -> ../../sdb | |-- usb-_MS_TS-RD13_2511 -> ../../sdd | |-- usb-_SD_TS-RD13_2511 -> ../../sdc | `-- usb-_XD_TS-RD13_2511 -> ../../sde ... |-- by-path | |-- pci-:00:1d.7-usb-0:3:1.0-scsi-0:0:0:0 -> ../../sdb | |-- pci-:00:1d.7-usb-0:3:1.0-scsi-0:0:0:1 -> ../../sdc | |-- pci-:00:1d.7-usb-0:3:1.0-scsi-0:0:0:2 -> ../../sdd | |-- pci-:00:1d.7-usb-0:3:1.0-scsi-0:0:0:3 -> ../../sde ... Hmm, we could add the SCSI-LUN number, like we do in path_id. Hannes, any idea what's the best fix for it? Thanks, Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#398962: [2.6.18] Platform devices incorrectly provide $MODALIAS?
On 11/25/06, Frans Pop <[EMAIL PROTECTED]> wrote: In Debian we are currently seeing some problems with drivers that are repeatedly loaded unsuccessfully: kernel: Intel ISA PCIC probe: not found. FATAL: Error inserting i82365: no such device kernel: Intel ISA PCIC probe: not found. [...] According to Marco d'Itri this could be because "platform devices in recent kernels provide $MODALIAS while they should not. So udev will always try loading again the driver after it has been loaded." He has suggested working around this by excluding loading drivers for platform devices in udev. However, Sven Luther noted that e.g. the Pegasos marvell gigabit ethernet port is a platform device for which the driver should be loaded. Can anyone shed some light on this and suggest a solution? The only sane solution is to fix the kernel platform-subsystem to use aliases instead of direct module names. In the bug you mentioned, the platform device requests its _own_ module, the one which has just created the device again. This misuse of modalias causes a modprobe-loop when the init of the module fails. The author of that code seems ignorant to the issues he creates by doing that, but we hope to get that fixed. For now you can just blacklist all platform events like Marco already suggested. Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#398962: [2.6.18] Platform devices incorrectly provide $MODALIAS?
On Tue, 2006-11-28 at 08:12 +0100, Bastian Blank wrote: > On Mon, Nov 27, 2006 at 03:45:36PM +0100, Kay Sievers wrote: > >For now you can just > > blacklist all platform events like Marco already suggested. > > Nope. modprobe don't have the knowledge that this is an alias. Exactly, that's the root of the problem. But it isn't what Marco put in the Debian package, and I was referring to. Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#401826: [PATCH] Fix inotify syscalls on M32R
Applied to the upstream udev tree. Thanks, Kay On Wed, 2006-12-06 at 16:17 +0900, Kazuhiro Inaoka wrote: > Please apply a patch to fix inotify syscalls on M32R. > --- udev-0.103/udev_sysdeps.h.org 2006-12-06 05:29:31.503967152 + > +++ udev-0.103/udev_sysdeps.h 2006-12-06 05:30:02.502139848 + > @@ -64,6 +64,10 @@ > # define __NR_inotify_init 290 > # define __NR_inotify_add_watch 291 > # define __NR_inotify_rm_watch 292 > +#elif defined (__m32r__) > +# define __NR_inotify_init 290 > +# define __NR_inotify_add_watch 291 > +# define __NR_inotify_rm_watch 292 > #elif defined (__hppa__) > # define __NR_inotify_init 269 > # define __NR_inotify_add_watch 270 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#411967: udev: Name conflicts in z20_persistent.rules
On Sat, 2007-03-03 at 17:59 +0100, Kay Sievers wrote: > > The problem lies within /dev/disk/by-id. Even though the card reader > > has four slots, it only has one serial number, so only one link is > > created in /dev/disk/by-id. It's called > > usb-Generic_STORAGE_DEVICE_05170 and it points to one of > > /dev/sd[abcd], not always the same one. I suppose there's a race > > condition somewhere. > > > The card reader is a Kingston FCR-HS215/1, if that matters. > > Vendor/device ids: 11b0:6108. > > Yes, that's a known issue. So far, we've seen that only for very cheap > devices, not something with a brand name on it. Usually, the different > ports on a card reader have different names: > /dev/disk/ > |-- by-id > | |-- usb-_CF_TS-RD13_2511 -> ../../sdb > | |-- usb-_MS_TS-RD13_2511 -> ../../sdd > | |-- usb-_SD_TS-RD13_2511 -> ../../sdc > | `-- usb-_XD_TS-RD13_2511 -> ../../sde > ... > |-- by-path > | |-- pci-:00:1d.7-usb-0:3:1.0-scsi-0:0:0:0 -> ../../sdb > | |-- pci-:00:1d.7-usb-0:3:1.0-scsi-0:0:0:1 -> ../../sdc > | |-- pci-:00:1d.7-usb-0:3:1.0-scsi-0:0:0:2 -> ../../sdd > | |-- pci-:00:1d.7-usb-0:3:1.0-scsi-0:0:0:3 -> ../../sde > ... > > Hmm, we could add the SCSI-LUN number, like we do in path_id. Ok, I talked with Hannes, and we decided to change usb_id to append "-$target:$lun" to the id of usb-mass storage devices. It looks like this now: /dev/disk/by-id/ |-- usb-Generic_STORAGE_DEVICE_02773-0:0 -> ../../sdb |-- usb-Generic_STORAGE_DEVICE_02773-0:1 -> ../../sdc |-- usb-Generic_STORAGE_DEVICE_02773-0:2 -> ../../sdd `-- usb-Generic_STORAGE_DEVICE_02773-0:3 -> ../../sde It will be part of udev 107. Hope will work as expected. Thanks, Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#415744: udev: [PATCH] fix libvolume_id.pc libdir
On Wed, 2007-03-21 at 18:43 +0200, Guillem Jover wrote: > The current .pc file has a wrong libdir (/lib), it should be /usr/lib > as there is where the .so file is located. This makes pkg-config to > not trim the -L argument which is problematic at least on sbox. What do you mean? The .so file is in /lib(64), not in /usr, it's usually needed for bootup, so it can never be in /usr. Thanks, Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#376589: udev: z25_persistent-net.rules is no longer generated
On Tue, 2006-07-04 at 19:35 +0200, Marco d'Itri wrote: > On Jul 04, Andreas Beckmann <[EMAIL PROTECTED]> wrote: > > > # ignore interfaces without a driver link > > DRIVER!="?*", GOTO="persistent_net_generator_end" > > > > If I comment out this line, z25_persistent-net.rules is generated on > > boot (if it was missing), so the test seems to be too limiting. > Too bad, because it's needed. > > > > Unless you can point me to an actual bug, then the explanation of > > > this behaviour is that your network card(s) do not support generation of > > > persistent rules, older versions of udev lacked some checks which were > > > added later. > > > > Are the following network cards too old? > > # PCI device 14e4:4401 (b44) (onboard) > > # PCI device 10ec:8139 (8139too) (PCI card) > No, and unless you added the drivers name in the comment you reported > it means that the driver symlinks exist because the script has found them. > Kay, do you have any idea about why DRIVER!="?*" is not working as > expected? The device itself does not have a DRIVER value set. We need to select a parent device with BUS to match against DRIVER, but unfortunately there are pci devices in the higher chain which don't have a driver value, so BUS=="?*", DRIVER!="?*" will not work. I see currently no easy solution other than using PHYSDEVDRIVER, until we know how to solve that. > > I attach a copy of /sys/class/net/eth* as described in #368845. > > Kernel 2.6.16-2-k7 (2.6.16-15), there are no 'driver' symlinks. > They are in the device/ directory. Care to provide: udevinfo -a -p /class/net/eth0 That should print all the DRIVER= values, just to check if that is correct. Thanks, Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#376589: udev: z25_persistent-net.rules is no longer generated
On Wed, 2006-07-05 at 14:51 +0200, Andreas Beckmann wrote:
> I switched testing to another machine that can be rebooted more easily.
> It has only one (onboard) network interface:
> # PCI device 10ec:8139 (8139too)
>
> Kay Sievers wrote:
> ...
> > Care to provide:
> > udevinfo -a -p /class/net/eth0
> >
> > That should print all the DRIVER= values, just to check if that is
> > correct.
>
> looking at device '/class/net/eth0':
> looking at device '/devices/pci:00/:00:0a.0':
> ID==":00:0a.0"
> BUS=="pci"
> DRIVER=="8139too"
> looking at device '/devices/pci:00':
> ID=="pci:00"
> BUS==""
> DRIVER==""
That looks fine.
> Marco d'Itri wrote:
> > On Jul 04, Andreas Beckmann <[EMAIL PROTECTED]> wrote:
> >
> >> # ignore interfaces without a driver link
> >> DRIVER!="?*", GOTO="persistent_net_generator_end"
> > So try replacing this rule with:
> >
> > PHYSDEVDRIVER!="?*", GOTO="persistent_net_generator_end"
> >
> > and check if it works better.
>
> There is no difference between DRIVER!="?*" and PHYSDEVDRIVER!="?*" - no
> z25_persistent-net.rules created during boot.
PHYSDEVDRIVER is an environment variable set by the kernel and needs to
be in an ENV{} key to match the value.
Kay
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#378839: bluez-pcmcia-support: udev support broken
On Wed, Jul 19, 2006 at 12:16:54PM +0200, Marco d'Itri wrote:
> Is this correct?
>
> - Forwarded message from [EMAIL PROTECTED] -
>
> From: [EMAIL PROTECTED]
> To: Debian Bug Tracking System <[EMAIL PROTECTED]>
> Subject: bluez-pcmcia-support: udev support broken
>
> Package: bluez-pcmcia-support
> Version: 3.1-2
> Severity: grave
> Justification: renders package unusable
>
>
> The udev rules supplied by the package don't work. At least on my
> system tested with a SPHINX and a Sitecom card.
>
> The solution is to replace ENV{BUS} by ENV{PHYSDEVBUS} in
> bluez-pcmcia-support.udev and to correspondingly change $DEVPATH to
> $PHYSDEVPATH in bluetooth.sh, i. e. revert to the solution I sent in
> #351106.
ENV{BUS} never existed, so it can't work. The PHYDEV* values are
deprecated and and should better not be used. They will not go away
soon, but if that can be solved without them, it would be nice.
PHYSDEVBUS is just the subsystem of the parent device, which can
probably be matched with BUS=="pcmcia".
Kay
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#378839: [Pkg-bluetooth-maintainers] Bug#378839: bluez-pcmcia-support: udev support broken
On Tue, 2006-07-25 at 12:52 +0200, Felix Homann wrote:
> On Tuesday 25 July 2006 11:12, Filippo Giunchedi wrote:
> > what about the change from DEVPATH to PHYSDEVPATH Felix proposed in
> > bluetooth.sh?
>
> Hi again,
>
> MANFID=`cat /sys/$PHYSDEVPATH/manf_id`","`cat /sys/$PHYSDEVPATH/card_id`
>
> and
>
> MANFID=`cat /sys/$DEVPATH/device/manf_id`","`cat /sys/$DEVPATH/device/card_id`
>
> seem to be equivalent in this setting. I don't know if either one is prefered
> or deprecated, but I would now prefer the latter since it's simpler:
>
> $DEVPATH -> /class/tty/ttyS2
> $PHYSDEVPATH -> /devices/pci:00/:00:1e.0/:06:01.0/0.0
PHYSDEVPATH and the 'device' link are both deprecated and will go away
some day in the future, you better pass the values you want to use in
your script down from udev with $sysfs{}. That is not dependent on a
specific order of devices in sysfs.
Kay
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#378839: [Pkg-bluetooth-maintainers] Bug#378839: bluez-pcmcia-support: udev support broken
On Tue, 2006-07-25 at 15:43 +0200, Felix Homann wrote:
> On Tuesday 25 July 2006 13:18, Kay Sievers wrote:
> > PHYSDEVPATH and the 'device' link are both deprecated and will go away
> > some day in the future, you better pass the values you want to use in
> > your script down from udev with $sysfs{}. That is not dependent on a
> > specific order of devices in sysfs.
> I've attached working (for me) rules+bluetooth.sh. $sysfs{manf_id} and
> $sysfs{card_id} are passed to bluetooth.sh.
Looks fine, and should not break, if something in sysfs changes, which
is nice.
Btw, you should be able to just do RUN+="bluetooth.sh", as udev will
look in /lib/udev/ if it does not start with a '/'.
Thanks,
Kay
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389250: udev: does not always rename wireless interface
On Wed, 2006-09-27 at 12:45 +0200, Marco d'Itri wrote:
> On Sep 27, Brice Goglin <[EMAIL PROTECTED]> wrote:
>
> > >> # PCI device 0x8086:0x4220 (ipw2200)
> > >> SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:12:f0:12:05:03",
> > >> NAME="wifi"
> > >>
> > > Try replacing DRIVERS== with PHYSEDVDRIVER== and let me know.
> > It works!
> >
> > I don't see any documentation about PHYSEDVDRIVER anywhere. Am I
> > supposed to keep using it?
It must be ENV{PHYSDEVDRIVER}==, it is just a kernel supplied
environment variable.
> Or was this only for debugging purpose?
This is just for testing, if that works, we may need to fix the
kernel to create the bus-device driver link at the proper time
to be catched by DRIVERS==.
> It is deprecated and usually should not be used, probably DRIVER can
> be fixed to work as expected.
Yes, all kernel PHYSDEV* event variables are deprecated and will be
removed from the kernel in 2 years.
Thanks,
Kay
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389892: writing_udev_rules: just unplug the card reader and insert new cards and replug
On Thu, 2006-09-28 at 16:40 +0800, Dan Jacobson wrote:
> X-debbugs-cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
> Package: udev
> Version: 0.100-1
> Severity: normal
> File: /usr/share/doc/udev/writing_udev_rules/index.html
>
> Regarding
>
> USB Card Reader
>
> These devices typically do not inform the host computer upon
> media change. So, if you plug in the device with no media, and
> then insert a card, the computer does not realise, and you do not
> have your mountable sdb1 partition node for the media.
>
> One possible solution is to take advantage of the all_partitions
> option, which will create 16 partition nodes for every block
> device that the rule matches:
>
>BUS=="usb", SYSFS{product}=="USB 2.0 CompactFlash Reader",
>SYMLINK+="cfrdr%n", OPTIONS+="all_partitions"
>
> You will now have nodes named: cfrdr, cfrdr1, cfrdr2, cfrdr3,
> ..., cfrdr15.
>
>
> I would say 1 times less complicated would be to tell the user to
> forget trying to understand all this, and
>
> 1. umount(8) cards already mounted on the reader, if any.
> 2. Unplug the reader from the USB socket.
> 3. Insert any additional cards into the reader.
> 4. Plug the reader back into the USB socket.
> 5. mount(8) your cards again.
>
> That's all.
>
> Sorry, but that's the view from us less sophisticated users.
Ick, no, just use a reasonable setup, where HAL will poll the device for
you and this is no issue at all. Nobody should write udev rules for
things like this these days.
> ===
>
> (By the way, one even wonders if BUS above should be SUBSYSTEMS.
Both work the same way. Yes, the document should be updated to use the
new key names.
> and one also wants to match all card readers, no matter the brand.
No recent system should need any of these udev rules to make
card-readers work. Udev rules or disconnect/reconnect advices are the
totally wrong solution for this problem.
> Also say what one has to do after one writes a rule. restart udevd?
> reboot? for it to take effect.
Nothing is needed. Udevd will notice any rules change by watching the
directory with inotify.
> But never mind. It is 1 times easier to forget trying to
> understand all this.)
As said, everybody can try to fiddle around with stuff like this if he's
interested in seeing how that works, we all do this sometimes. But
nothing of this should be needed today to get things working, if you
don't cripple your system or work in a very special environment and you
are expected to have that kind of special knowledge anyway.
Kay
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#392580: udev: (Some) Epson SCSI scanners not recognized as scanners
On Thu, 2006-10-12 at 13:26 +0200, Jö Fahlke wrote:
> Package: udev
> Version: 0.100-2
> Severity: normal
> Tags: patch
>
> My Epson scanner is not assigned to group "scanner" when I switch it
> on and scan the SCSI bus. This is because it identifies itself as
> type 3 (processor) and vendor "EPSON", but permissions.rules matches
> for vender "Epson".
>
> This patch solve the problem for me:
> ==
> --- /etc/udev/permissions.rules 2006/09/21 18:37:41 1.6
> +++ /etc/udev/permissions.rules 2006/10/12 10:49:09
> @@ -25,6 +25,7 @@
> SUBSYSTEMS=="scsi", ATTRS{type}=="1",
> GROUP="tape"
> SUBSYSTEMS=="scsi", ATTRS{type}=="3", ATTRS{vendor}=="HP", GROUP="scanner"
> SUBSYSTEMS=="scsi", ATTRS{type}=="3", ATTRS{vendor}=="Epson",
> GROUP="scanner"
> +SUBSYSTEMS=="scsi", ATTRS{type}=="3", ATTRS{vendor}=="EPSON",
> GROUP="scanner"
> SUBSYSTEMS=="scsi", ATTRS{type}=="5",
> GROUP="cdrom"
> SUBSYSTEMS=="scsi", ATTRS{type}=="6",
> GROUP="scanner"
>
> ==
>
> Note that some way to match values in a case insensitive manner would
> probably allow a more general fix which avoids similiar problems with
> other vendors.
fnmatch() which has a FNM_CASEFOLD option. We could use this but I don't
know a nice way to specify it in the rule key. For now you could just do
ugly things like:
ATTRS{vendor}=="E[Pp][Ss][Oo][Nn]"
Kay
Bug#422049: udev: udevinfo manual page does not document short options
It's consistent in all udev programs. Only long-options are supported today. The short options are for convenience, or for compatibility to old releases only. Thanks, Kay > Package: udev > Version: 0.105-4 > Severity: minor > File: /usr/bin/udevinfo > > udevinfo accepts some short options that are not documented in the > manual page or in udevinfo --help. It would be nice if they were > documented in both places. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383051: /lib/udev/vol_id translates volume id to uppercase for FAT partition.
On Mon, 2006-08-14 at 19:43 +0100, Tim Phipps wrote: > Package: udev > Version: 0.093-1 > Severity: normal > > Feel free to change this to minor or wishlist. I'd like vol_id to not > change the case of FAT partitions labels. I don't believe this will affect > many people since FAT partitions are usually created with upper case labels > anyway. It was quite hard to get a lower case one in there in the first > place so only lunatics like me will notice any change. Huh, what do you mean? Libvolume_id does not translate anything. What piece of software is showing a label with lowercase chars? Anyway, care to add the output of: /lib/udev/vol_id /dev/sdd1 and: strace -t -s1 /lib/udev/vol_id /dev/sdd1 so we can take a look at the label stored on your disk. Thanks, Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383200: udev: typo in man page, 'Asign' should be 'Assign'
On Tue, 2006-08-15 at 10:08 -0500, Matt Zagrabelny wrote: > Package: udev > Version: 0.093-1 > Severity: minor > > > typo in /usr/share/man/man7/udev.7.gz > > 'Asign' should be 'Assign' Fixed. Thanks, Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#366853: vol_id returns incorrect information for my randomly-encrypted swap device
On Thu, 2006-08-17 at 22:46 -0700, Andrew Pimlott wrote: > I suspect I have a similar problem to the reporter of this bug. I have > a swap partition that is set up as an encrypted dm device with a random > key, using the cryptsetup package. cryptsetup now has a test that calls > vol_id, which thinks that my partition is vfat: > > % sudo /lib/udev/vol_id /dev/hda2 > ID_FS_USAGE=filesystem > ID_FS_TYPE=vfat > ID_FS_VERSION=FAT32 > ID_FS_UUID= > ID_FS_LABEL= > ID_FS_LABEL_SAFE= > > % sudo mount -t vfat /dev/hda2 /mnt/tmp > mount: /dev/hda2: can't read superblock > > Inspecting this partition, I see clearly "MSDOS5.0", presumably the > long-preserved remnants of a vfat filesystem. However, since the kernel > refuses to mount the partition as vfat, it seems that vol_id could apply > a stricter check. > > I realize that vol_id can never be perfect, since the device metadata > may be consistent with multiple formats. And I agree that device > initialization tools (like mkswap) should zero out part of the device. > But it would still help to make vol_id more exact, because this issue > evidently bites users in practice. Perhaps there could be flags for > quick-and-dirty check versus more complete check. It's almost impossible to make libvolume_id stricter, in most cases, even the kernel mounts a mkswap formatted (and obviously corrupt) fat volume just fine and allows writing to it. It's mkswap which is horribly broken here and needs to be fixed. You can just use dd and clean the volume before reformatting it. I talked to the former maintainer of mkswap long ago and he said it's a 'feature' of mkswap not to overwrite anything not needed for the swap signature - so far, he seem not to have the slightest clue what all this is about. The maintainer has changed in the meantime, which is great, so we may have a chance to fix that now, but I didn't try to talk to him. Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#366853: vol_id returns incorrect information for my randomly-encrypted swap device
On Fri, 2006-08-18 at 08:59 -0700, Andrew Pimlott wrote: > On Fri, Aug 18, 2006 at 02:13:53PM +0200, Kay Sievers wrote: > > It's almost impossible to make libvolume_id stricter, in most cases, > > even the kernel mounts a mkswap formatted (and obviously corrupt) fat > > volume just fine and allows writing to it. > > Ok, thanks for the explanation. > > > It's mkswap which is horribly broken here and needs to be fixed. > > Hopefully the bug I filed with util-linux will produce some change. That would be nice. In case you need to argue, the mkfs.ext* tools and mkfs.reisferfs tools invalidate the start and the end (md raid) of the volume too, to overwrite old signatures after having the same problems. > > You can just use dd and clean the volume before reformatting it. > > Right--I've done that to the partition, and now I have no problem. Yeah, but it's bad, that we need to do this after that issue is known for more than a year now. Thanks, Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389250: udev: does not always rename wireless interface
On Sun, 2006-10-29 at 00:10 +0200, Brice Goglin wrote: > Kay Sievers wrote: > > This is just for testing, if that works, we may need to fix the > > kernel to create the bus-device driver link at the proper time > > to be catched by DRIVERS==. > > Just wondering whether there is anything new about this bug report. > Marco said it could be ipw2200 having the "race between driver setup and > populating the MAC address file in sysfs as some drivers do". Kay talks > about fixing the kernel. Should I talk to the ipw2200 maintainer? Or is > this a known problem that netdev people are dealing with for all drivers? It likely affects all devices, not only netdev's or certain drivers. This should fix it: http://www.kernel.org/git/?p=linux/kernel/git/gregkh/patches.git;a=blob;hb=HEAD;f=driver/driver-link-sysfs-timing.patch Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389250: udev: does not always rename wireless interface
On Sun, 2006-10-29 at 23:28 +0100, Brice Goglin wrote: > reassign 389250 linux-2.6 > thanks > Kay Sievers wrote: > > On Sun, 2006-10-29 at 00:10 +0200, Brice Goglin wrote: > > > >> Kay Sievers wrote: > >> > >>> This is just for testing, if that works, we may need to fix the > >>> kernel to create the bus-device driver link at the proper time > >>> to be catched by DRIVERS==. > >>> > >> Just wondering whether there is anything new about this bug report. > >> Marco said it could be ipw2200 having the "race between driver setup and > >> populating the MAC address file in sysfs as some drivers do". Kay talks > >> about fixing the kernel. Should I talk to the ipw2200 maintainer? Or is > >> this a known problem that netdev people are dealing with for all drivers? > >> > > > > It likely affects all devices, not only netdev's or certain drivers. > > This should fix it: > > > > http://www.kernel.org/git/?p=linux/kernel/git/gregkh/patches.git;a=blob;hb=HEAD;f=driver/driver-link-sysfs-timing.patch > > > > Yes, 2.6.19-rc3 with this patch seems to work very well, thanks a lot. > Is this patch supposed to go into 2.6.19? > > I am reassigning this bug to linux-2.6. I guess it could be tagged > fixed-upstream too. 2.6.20, I expect. It should be in -mm at the moment, automatically pulled-in from Greg's tree. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#409385: udev: not unique path_id for multiple-LUNs iSCSI targets
> I was willing to use /dev/disk/by-path/ devices with an iSCSI setup when
> I figured out not all devices were available by path. I discovered that
> it was because my iSCSI target provided several LUNs, which are not
> reflected by path_id.
>
> The attached patch solves the problem by appending the LUN to the path.
> - d="ip-${iscsi_address}:${iscsi_port}-iscsi-${iscsi_tgtname}"
> + iscsi_lun="${DEV##*:}"
> +
> d="ip-${iscsi_address}:${iscsi_port}-iscsi-${iscsi_tgtname}:${iscsi_lun}"
We already have a fix in the SLES release with -lun- as the separator.
I'll commit this for the next udev version.
Thanks,
Kay
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#398651: /dev/dvb nodes no longer created after udev upgrade
On Thu, 2006-11-16 at 12:33 +0100, Torsten Crass wrote: > > It's probably you, since DVB devices work fine for me and apparently > > everybody else. > > perhaps you and everybody else is accessing DVB devices via loadable > modules, while I'm using a rather monolithic kernel with the drivers > compiled in? > > > Are you sure that the driver has been loaded? > > According to the dmesg output I submitted together with the bug report, > both cards get reckognized and initialized properly (it seems to me). > > > Are the devices created if > > you run udevtrigger? > > Nope. Please compare the relevant sysfs-trees (/sys/class/dvb/*) of the working kernel with the non-working one. Do you see the same list of devices there? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#366853: udev: vol_id returns incorrect information for my root device
> I've found that the problem appears to be related to vol_id failing to > find proper information for my root device, /dev/sda1. I've run the > commands 'e2label', '/lib/udev/vol_id', 'mount' and 'fdisk' with the > following results: Never use any of the all broken mkfs* tools without writing zeros to the start and the end of the partition before applying a different format. Overwrite at least 64kb. (Sane formatting applications like everything that is libparted based don't need this.) Kay -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
