* Re: udev and acer batteries
From: Stéphane Guedon @ 2010-08-12 17:57 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201008111908.37155.stephane@22decembre.eu>
[-- Attachment #1: Type: Text/Plain, Size: 8070 bytes --]
Le Thursday 12 August 2010 07:25:56, Martin Pitt a écrit :
> Hello Stéphane,
>
> Stéphane Guedon [2010-08-11 19:08 +0200]:
> > I am writing to you concerning acer batteries.
> > My laptop batteries aren't detected until I plug in/out the ac_adaptator.
> > If I am at home, working on it, no problem. But if I am out of buildings,
> > where I can't have power, my power status won't be detected by my desktop
> > environnement.
>
> This is most probably a bug in hal. KDE still uses hal for hardware
> detection/management, but since it's unmaintained, I wouldn't expect
> this to be fixed anytime soon or at all.
>
> Out of interest, can you install "upower" on your machine (if it's not
> already present), and in this situation (i. e. boot when on battery
> without AC), check the output of "upower --dump" whether it detects
> your battery?
>
> Thanks,
>
> Martin
with ac power on, but battery not yet recognize :
19:44:52 stephane@luciole:~ $ upower --dump
Device: /org/freedesktop/UPower/devices/line_power_ACAD
native-path:
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ACAD
power supply: yes
updated: Thu Aug 12 19:45:09 2010 (0 seconds ago)
has history: no
has statistics: no
line-power
online: yes
Daemon:
daemon-version: 0.9.5
can-suspend: yes
can-hibernate yes
on-battery: no
on-low-battery: no
lid-is-closed: no
lid-is-present: yes
after plugging out and in :
19:45:09 stephane@luciole:~ $ upower --dump
Device: /org/freedesktop/UPower/devices/line_power_ACAD
native-path:
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ACAD
power supply: yes
updated: Thu Aug 12 19:47:07 2010 (6 seconds ago)
has history: no
has statistics: no
line-power
online: yes
Device: /org/freedesktop/UPower/devices/battery_BAT1
native-path:
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT1
vendor: SANYO
model: AS07B31
serial: 30996
power supply: yes
updated: Thu Aug 12 19:47:12 2010 (1 seconds ago)
has history: yes
has statistics: yes
battery
present: yes
rechargeable: yes
state: fully-charged
energy: 48.3294 Wh
energy-empty: 0 Wh
energy-full: 48.3294 Wh
energy-full-design: 48.84 Wh
energy-rate: 5.6499 W
voltage: 12.594 V
percentage: 100%
capacity: 98.9545%
technology: lithium-ion
History (charge):
1281635230 100.000 fully-charged
1281635226 99.426 fully-charged
1281635222 99.495 fully-charged
1281635222 0.000 unknown
History (rate):
1281635232 5.650 fully-charged
1281635224 30.225 fully-charged
1281635222 3.419 fully-charged
1281635222 0.000 unknown
Daemon:
daemon-version: 0.9.5
can-suspend: yes
can-hibernate yes
on-battery: no
on-low-battery: no
lid-is-closed: no
lid-is-present: yes
reboot on battery :
19:53:49 stephane@luciole:~ $ upower --dump
Device: /org/freedesktop/UPower/devices/line_power_ACAD
native-path:
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ACAD
power supply: yes
updated: Thu Aug 12 19:53:52 2010 (0 seconds ago)
has history: no
has statistics: no
line-power
online: no
Daemon:
daemon-version: 0.9.5
can-suspend: yes
can-hibernate yes
on-battery: no
on-low-battery: no
lid-is-closed: no
lid-is-present: yes
plugging in the ac adatator
19:53:52 stephane@luciole:~ $ upower --dump
Device: /org/freedesktop/UPower/devices/line_power_ACAD
native-path:
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ACAD
power supply: yes
updated: Thu Aug 12 19:54:02 2010 (2 seconds ago)
has history: no
has statistics: no
line-power
online: yes
Device: /org/freedesktop/UPower/devices/battery_BAT1
native-path:
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT1
vendor: SANYO
model: AS07B31
serial: 30996
power supply: yes
updated: Thu Aug 12 19:54:04 2010 (0 seconds ago)
has history: yes
has statistics: yes
battery
present: yes
rechargeable: yes
state: charging
energy: 46.62 Wh
energy-empty: 0 Wh
energy-full: 48.3294 Wh
energy-full-design: 48.84 Wh
energy-rate: 37.2738 W
voltage: 11.929 V
time to full: 2.8 minutes
percentage: 96.463%
capacity: 98.9545%
technology: lithium-ion
History (charge):
1281635643 96.463 charging
1281635643 0.000 unknown
History (rate):
1281635643 37.274 charging
1281635643 0.000 unknown
Daemon:
daemon-version: 0.9.5
can-suspend: yes
can-hibernate yes
on-battery: no
on-low-battery: no
lid-is-closed: no
lid-is-present: yes
Hope this will help you, and me !
Thanks
--
Stéphane Guedon
page web : http://www.22decembre.eu/
carte de visite : http://www.22decembre.eu/downloads/Stephane-Guedon.vcf
clé publique gpg : http://www.22decembre.eu/downloads/Stephane-Guedon.asc
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] Add keymap for Lenovo IdeaPad S10-3
From: Martin Pitt @ 2010-08-12 18:14 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1281629095.12475.99.camel@localhost>
Hello David,
David Woodhouse [2010-08-12 17:04 +0100]:
> Tested on S10-3, but presumably applicable to all IdeaPads.
Thank you! Committed with some adaptions (add to Makefile.am and sort
the list).
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
^ permalink raw reply
* Re: udev and acer batteries
From: Martin Pitt @ 2010-08-12 18:25 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201008111908.37155.stephane@22decembre.eu>
[-- Attachment #1: Type: text/plain, Size: 834 bytes --]
Bonjour Stéphane,
Stéphane Guedon [2010-08-12 19:57 +0200]:
> with ac power on, but battery not yet recognize :
>
> 19:44:52 stephane@luciole:~ $ upower --dump
> Device: /org/freedesktop/UPower/devices/line_power_ACAD
> [...]
OK, so this has the same problem as hal, not very surprising, though.
This could be a BIOS bug, or your battery wasn't properly detected
during coldplug. Does this command change anything?
sudo udevadm trigger --verbose --subsystem-match=power_supply
It should print two device paths, one for the AC and one for the
battery. If the second one is missing, then the trigger didn't help,
and it could be a kernel or BIOS bug.
Thanks,
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: udev and acer batteries
From: Stéphane Guedon @ 2010-08-12 19:59 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201008111908.37155.stephane@22decembre.eu>
[-- Attachment #1: Type: Text/Plain, Size: 1832 bytes --]
Le Thursday 12 August 2010 20:25:03, Martin Pitt a écrit :
> Bonjour Stéphane,
>
> Stéphane Guedon [2010-08-12 19:57 +0200]:
> > with ac power on, but battery not yet recognize :
> >
> > 19:44:52 stephane@luciole:~ $ upower --dump
> > Device: /org/freedesktop/UPower/devices/line_power_ACAD
> > [...]
>
> OK, so this has the same problem as hal, not very surprising, though.
>
> This could be a BIOS bug, or your battery wasn't properly detected
> during coldplug. Does this command change anything?
>
> sudo udevadm trigger --verbose --subsystem-match=power_supply
>
> It should print two device paths, one for the AC and one for the
> battery. If the second one is missing, then the trigger didn't help,
> and it could be a kernel or BIOS bug.
>
> Thanks,
>
> Martin
I have nothing in my bios concerning batteries !
just after boot :
21:51:13 root@luciole:~ # udevadm trigger --verbose --subsystem-
match=power_supply
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ACAD
plugging out and in ac adaptator :
21:51:16 root@luciole:~ # udevadm trigger --verbose --subsystem-
match=power_supply
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ACAD
/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT1
So, on your advice, do I have to make a bug report ?
I use currently gentoo tuxonice kernel, but it seems to be a standard kernel
with only hibernation patch.
On an other thing, I find strange that I can't find your gpg signature in the
ubuntu keyserver, whereas you're a ubuntu "addicted" dev ...
Best regards
--
Stéphane Guedon
page web : http://www.22decembre.eu/
carte de visite : http://www.22decembre.eu/downloads/Stephane-Guedon.vcf
clé publique gpg : http://www.22decembre.eu/downloads/Stephane-Guedon.asc
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: udev and acer batteries
From: Curtis Gedak @ 2010-08-12 21:23 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201008111908.37155.stephane@22decembre.eu>
Hi Stéphane,
Even if your BIOS does not show a setting for batteries, it might still
contain controls for your laptop batteries.
I have an Acer Aspire One AOA-110-1812 and had to upgrade my BIOS due to
a battery charging problem that was fixed by a BIOS upgrade.
This is the note regarding the problem for my Acer netbook:
http://macles.blogspot.com/2008/12/acer-aspire-one-bios-3309.html
Regards,
Curtis Gedak
Stéphane Guedon wrote:
> I have nothing in my bios concerning batteries !
>
>
^ permalink raw reply
* Re: udev and acer batteries
From: Martin Pitt @ 2010-08-13 4:50 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201008111908.37155.stephane@22decembre.eu>
[-- Attachment #1: Type: text/plain, Size: 1468 bytes --]
Hello Stéphane,
Stéphane Guedon [2010-08-12 21:59 +0200]:
> I have nothing in my bios concerning batteries !
Not in the setup screen, but the BIOS is still responsible for the
ACPI implementation. Unfortunately these often come with pretty
serious bugs :-/
>
> 21:51:13 root@luciole:~ # udevadm trigger --verbose --subsystem-
> match=power_supply
> /sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/ACAD
OK, so it's not a bug with udev at all then.
> So, on your advice, do I have to make a bug report ?
> I use currently gentoo tuxonice kernel, but it seems to be a standard kernel
> with only hibernation patch.
I don't know enough about kernel ACPI initialization to know whether
it could be a kernel bug, or is definitively a bug in the BIOS' ACPI
implementation/tables. If you make a kernel bug report, please test
with the latest upstream kernel first, and include the output of
"dmesg", which includes quite a lot of ACPI information.
But perhaps try the BIOS update first that Curtis mentioned?
> On an other thing, I find strange that I can't find your gpg signature in the
> ubuntu keyserver, whereas you're a ubuntu "addicted" dev ...
Both my old and my new key are there..
$ gpg --keyserver keyserver.ubuntu.com --search-key martin.pitt@ubuntu.com
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Timing-Problems with udev
From: Christoph Pleger @ 2010-08-13 8:51 UTC (permalink / raw)
To: linux-hotplug
Hello,
often, I have timing-problems with udev. This means that when booting
from special devices (USB-Stick, CD, ISO-Image) some of the nodes
in /dev are created when booting the one time, but are not created when
booting the other time.
For example, on the same machine, when booting from hard disk, the
device nodes for the sound hardware (e.g. /dev/dsp) are always created,
but when booting from an USB-Stick, sometimes they are not.
Or when I create an image for a bootable CD, burn the image on CD and
boot from the CD, /dev/cdrom is mounted correctly as my root
filesystem, but when I use the ISO-Image to boot a virtual
machine, /dev/cdrom cannot be mounted because the link from /dev/cdrom
to the real device node in /dev does not exist. In both cases, on the
real machine and on the virtual machine, the CD-Device is connected as
master to the secondary IDE-Port.
What can I do to avoid these timing problems? When replying, please
send your answer not only to the the mailing list, but also to my
email-address, because I did not subscribe to the list.
Regards
Christoph
^ permalink raw reply
* RE: udev and acer batteries
From: Jordan_Hargrave @ 2010-08-13 20:40 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201008111908.37155.stephane@22decembre.eu>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 1401 bytes --]
I've been looking into ACPI on laptops and have noticed the battery info is usually cached by the BIOS. The battery status/presence won't get updated unless you plug/unplug the power cord if the battery is fully charged.
--jordan hargrave
Dell Enterprise Linux Engineering
-----Original Message-----
From: linux-hotplug-owner@vger.kernel.org [mailto:linux-hotplug-owner@vger.kernel.org] On Behalf Of Curtis Gedak
Sent: Thursday, August 12, 2010 4:24 PM
To: Stéphane Guedon
Cc: martin.pitt@ubuntu.com; linux-hotplug@vger.kernel.org
Subject: Re: udev and acer batteries
Hi Stéphane,
Even if your BIOS does not show a setting for batteries, it might still
contain controls for your laptop batteries.
I have an Acer Aspire One AOA-110-1812 and had to upgrade my BIOS due to
a battery charging problem that was fixed by a BIOS upgrade.
This is the note regarding the problem for my Acer netbook:
http://macles.blogspot.com/2008/12/acer-aspire-one-bios-3309.html
Regards,
Curtis Gedak
Stéphane Guedon wrote:
> I have nothing in my bios concerning batteries !
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þ\x1a-¦[ þ)í…æèw*\x1fjg¬±¨\x1e¶‰šŽŠÝ¢jÿ¾\a«þG«éÿ¢¸\f¢·¦j:+v‰¨ŠwèjØm¶Ÿÿþø\x1e¯ù\x1e®w¥þŠàþf£¢·hšâúÿ†Ù¥
^ permalink raw reply
* udevadm triggers wrong event type for failed events
From: Andrey Borzenkov @ 2010-08-14 16:16 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 1164 bytes --]
I was puzzled why my bluetoothd was not started on boot. It turned out
the following:
- bluetoothd requires D-Bus so attempt to start it early (may be, as
early as initrd) fails
- event is saved as failed event; but only device path is preserved, no
information about which event type failed
- later udevadm trigger --type=failed is run; but by default this
triggers "change" event instead of "add". There is no "change" action
for bluetooth subsystem (nor do I think it normally emits such event) so
nothing happens.
This change was introduced relatively recently in
commit 236fae6cf1a619a92174efdf84cd7d91e7d4348d
Author: Kay Sievers <kay.sievers@vrfy.org>
Date: Mon Apr 12 17:56:32 2010 +0200
udevadm: trigger - switch default action from "add" to "change"
Now, I could of course just go and add --action=add to udev-post
initscript. The question is - is it correct to assume that every failed
event is "add"? Should not event type be preserved for later correct re-
trigger?
BTW both init/udev-retry.service from udev GIT and udev-post from Fedora
have the same problem (Mandriva is using Fedora version).
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: udev and acer batteries
From: Stéphane Guedon @ 2010-08-14 17:58 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201008111908.37155.stephane@22decembre.eu>
[-- Attachment #1: Type: Text/Plain, Size: 1789 bytes --]
Le Friday 13 August 2010 22:40:14, vous avez écrit :
> I've been looking into ACPI on laptops and have noticed the battery info is
> usually cached by the BIOS. The battery status/presence won't get updated
> unless you plug/unplug the power cord if the battery is fully charged.
>
> --jordan hargrave
> Dell Enterprise Linux Engineering
>
>
> -----Original Message-----
> From: linux-hotplug-owner@vger.kernel.org
> [mailto:linux-hotplug-owner@vger.kernel.org] On Behalf Of Curtis Gedak
> Sent: Thursday, August 12, 2010 4:24 PM
> To: Stéphane Guedon
> Cc: martin.pitt@ubuntu.com; linux-hotplug@vger.kernel.org
> Subject: Re: udev and acer batteries
>
> Hi Stéphane,
>
> Even if your BIOS does not show a setting for batteries, it might still
> contain controls for your laptop batteries.
>
> I have an Acer Aspire One AOA-110-1812 and had to upgrade my BIOS due to
> a battery charging problem that was fixed by a BIOS upgrade.
>
> This is the note regarding the problem for my Acer netbook:
> http://macles.blogspot.com/2008/12/acer-aspire-one-bios-3309.html
>
> Regards,
> Curtis Gedak
>
> Stéphane Guedon wrote:
> > I have nothing in my bios concerning batteries !
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
So, do you think there is a way to retrieve this information ?
A module to load, a specific option to the kernel, a script to run ?
Regards
--
Stéphane Guedon
page web : http://www.22decembre.eu/
carte de visite : http://www.22decembre.eu/downloads/Stephane-Guedon.vcf
clé publique gpg : http://www.22decembre.eu/downloads/Stephane-Guedon.asc
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: udev and acer batteries
From: Stéphane Guedon @ 2010-08-14 18:01 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201008111908.37155.stephane@22decembre.eu>
[-- Attachment #1: Type: text/plain, Size: 1919 bytes --]
Le Friday 13 August 2010 22:40:14, vous avez écrit :
> I've been looking into ACPI on laptops and have noticed the battery info is
> usually cached by the BIOS. The battery status/presence won't get updated
> unless you plug/unplug the power cord if the battery is fully charged.
>
> --jordan hargrave
> Dell Enterprise Linux Engineering
>
>
> -----Original Message-----
> From: linux-hotplug-owner@vger.kernel.org
> [mailto:linux-hotplug-owner@vger.kernel.org] On Behalf Of Curtis Gedak
> Sent: Thursday, August 12, 2010 4:24 PM
> To: Stéphane Guedon
> Cc: martin.pitt@ubuntu.com; linux-hotplug@vger.kernel.org
> Subject: Re: udev and acer batteries
>
> Hi Stéphane,
>
> Even if your BIOS does not show a setting for batteries, it might still
> contain controls for your laptop batteries.
>
> I have an Acer Aspire One AOA-110-1812 and had to upgrade my BIOS due to
> a battery charging problem that was fixed by a BIOS upgrade.
>
> This is the note regarding the problem for my Acer netbook:
> http://macles.blogspot.com/2008/12/acer-aspire-one-bios-3309.html
>
> Regards,
> Curtis Gedak
>
> Stéphane Guedon wrote:
> > I have nothing in my bios concerning batteries !
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
So, do you think there is a way to retrieve this information ?
A module to load, a specific option to the kernel, a script to run ?
Sorry, I forgot to say my laptop model : acer aspire 7730z, this avoid (I
think ? don't know !) your remark from your blog !
Regards
--
Stéphane Guedon
page web : http://www.22decembre.eu/
carte de visite : http://www.22decembre.eu/downloads/Stephane-Guedon.vcf
clé publique gpg : http://www.22decembre.eu/downloads/Stephane-Guedon.asc
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: udev and acer batteries
From: Curtis Gedak @ 2010-08-14 20:01 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201008111908.37155.stephane@22decembre.eu>
Hi Stéphane,
You can check for BIOS updates for your Acer laptop on the
manufacturer's web site.
In Canada their web site is:
http://www.acer.ca
The BIOS updates can be found under the "Service & Support" section
"Driver Download" subsection.
Regards,
Curtis Gedak
Stéphane Guedon wrote:
> So, do you think there is a way to retrieve this information ?
> A module to load, a specific option to the kernel, a script to run ?
>
> Sorry, I forgot to say my laptop model : acer aspire 7730z, this avoid (I
> think ? don't know !) your remark from your blog !
>
^ permalink raw reply
* Re: udevadm triggers wrong event type for failed events
From: Kay Sievers @ 2010-08-15 9:14 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <201008142016.12747.arvidjaar@mail.ru>
On Sat, Aug 14, 2010 at 18:16, Andrey Borzenkov <arvidjaar@mail.ru> wrote:
> I was puzzled why my bluetoothd was not started on boot. It turned out
> the following:
>
> - bluetoothd requires D-Bus so attempt to start it early (may be, as
> early as initrd) fails
>
> - event is saved as failed event; but only device path is preserved, no
> information about which event type failed
>
> - later udevadm trigger --typeúiled is run; but by default this
> triggers "change" event instead of "add". There is no "change" action
> for bluetooth subsystem (nor do I think it normally emits such event) so
> nothing happens.
>
> This change was introduced relatively recently in
>
> commit 236fae6cf1a619a92174efdf84cd7d91e7d4348d
> Author: Kay Sievers <kay.sievers@vrfy.org>
> Date: Â Mon Apr 12 17:56:32 2010 +0200
>
> Â Â udevadm: trigger - switch default action from "add" to "change"
>
>
> Now, I could of course just go and add --actiond to udev-post
> initscript. The question is - is it correct to assume that every failed
> event is "add"? Should not event type be preserved for later correct re-
> trigger?
It should match what we do in the initial init scripts, so adding
--actiond seems right. The defaults seems fine, which are always
'change'.
Kay
^ permalink raw reply
* Problem with udev-161 and isdn capi device nodes
From: Silvan Minghetti @ 2010-08-16 20:19 UTC (permalink / raw)
To: linux-hotplug
Hi
I'm having a problem with udev >= 154, as it warns on NAME= values
different from the kernel provided names, as done per changeset
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;hucb1ac51ea0176926c749bd0f22c19ce8b20e5f
The problem is, with the following isdn capi rules (which were removed
from udev anyway), udev is not able to create the wanted devices,
because of a missing directory (/dev/capi), which has to be created
beforehand:
SUBSYSTEM="capi", KERNEL="capi", NAME="capi20", GROUP="dialout"
SUBSYSTEM="tty", KERNEL="capi[0-9]*", NAME="capi/%n"
so, instead of /dev/capi20 we now get /dev/capi
and /dev/capi0 instead of /dev/capi/0
Is this here to stay or is this going to be changed in the kernel? The
new layout breaks quite a few apps/libs...
silvan
^ permalink raw reply
* Re: Problem with udev-161 and isdn capi device nodes
From: Kay Sievers @ 2010-08-17 6:18 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4C699D3F.9080104@gmail.com>
On Mon, Aug 16, 2010 at 22:19, Silvan Minghetti <bu1137@gmail.com> wrote:
> I'm having a problem with udev >= 154, as it warns on NAME= values different
> from the kernel provided names, as done per changeset
>
> http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;hucb1ac51ea0176926c749bd0f22c19ce8b20e5f
>
> The problem is, with the following isdn capi rules (which were removed from
> udev anyway), udev is not able to create the wanted devices, because of a
> missing directory (/dev/capi), which has to be created beforehand:
>
> SUBSYSTEM="capi", KERNEL="capi", NAME="capi20", GROUP="dialout"
> SUBSYSTEM="tty", KERNEL="capi[0-9]*", NAME="capi/%n"
>
> so, instead of /dev/capi20 we now get /dev/capi
> and /dev/capi0 instead of /dev/capi/0
>
> Is this here to stay or is this going to be changed in the kernel? The new
> layout breaks quite a few apps/libs...
It needs to be changed in the kernel. It's rather trivial, but I don't
know if anybody is working on this at the moment. I guess people have
moved to mISDN, and that's why this hasn't really come up so far?
Kay
^ permalink raw reply
* UDEV.
From: Тима @ 2010-08-18 9:51 UTC (permalink / raw)
To: linux-hotplug
Hello All!
My name is Tima, I'm embedded software developer.
I'm working on driver for Satellite Digital Video Receiver.
May I ask some question about UDEV?
^ permalink raw reply
* Re: UDEV.
From: Greg KH @ 2010-08-18 12:49 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <E1OlfId-0002cX-00.ge-star-mail-ru@f108.mail.ru>
On Wed, Aug 18, 2010 at 01:51:11PM +0400, ???? wrote:
> Hello All!
> My name is Tima, I'm embedded software developer.
> I'm working on driver for Satellite Digital Video Receiver.
>
> May I ask some question about UDEV?
You never have to ask the question "can I ask a question?" :)
^ permalink raw reply
* Re[2]: UDEV.
From: Тима @ 2010-08-19 15:07 UTC (permalink / raw)
To: linux-hotplug
Thanks.
My question (I think) is very easy. But I could not find answer in the Internet, and did not get it on forum.
My aim is to make UDEV create device node automatically on loading module.
I tied rule:
KERNEL="math", NAME="math"
meaning my device name (register char dev) is "math" and the node name I want is "math".
But nothing happens.
Is there any possibility to make such rule?
Maybe I do not export some required information to SysFS?
If you need module code I can send it to you with Makefile.
> Wed, 18 Aug 2010 05:49:31 -0700 письмо от Greg KH <greg@kroah.com>:
>
> > On Wed, Aug 18, 2010 at 01:51:11PM +0400, ???? wrote:
> > > Hello All!
> > > My name is Tima, I'm embedded software developer.
> > > I'm working on driver for Satellite Digital Video Receiver.
> > >
> > > May I ask some question about UDEV?
> >
> > You never have to ask the question "can I ask a question?" :)
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: UDEV.
From: Greg KH @ 2010-08-19 15:27 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <E1OlfId-0002cX-00.ge-star-mail-ru@f108.mail.ru>
A: No.
Q: Should I include quotations after my reply?
http://daringfireball.net/2007/07/on_top
On Thu, Aug 19, 2010 at 07:07:40PM +0400, ???? wrote:
> Thanks.
> My question (I think) is very easy. But I could not find answer in the Internet, and did not get it on forum.
> My aim is to make UDEV create device node automatically on loading module.
> I tied rule:
> KERNEL="math", NAME="math"
> meaning my device name (register char dev) is "math" and the node name I want is "math".
> But nothing happens.
> Is there any possibility to make such rule?
> Maybe I do not export some required information to SysFS?
> If you need module code I can send it to you with Makefile.
Yes, please post your kernel code. You need to hook into the driver
model to properly be able to have udev pick up your device information.
Have you done that?
thanks,
greg k-h
^ permalink raw reply
* Trouble with USB device
From: Sarah Messer @ 2010-08-19 22:01 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 8621 bytes --]
Hello,
I've been pawing through trouble-shooting notes trying to get control of a USB device under my own code.
I have the same code running on two computers; it works fine for one and not the other. My interface is written in Python, and I use pyusb 0.4.1, libusb-0.1, and up-to-date openSuSe 11.1 on both machines. I'm fairly sure the relevant parts of the /etc/udev/rules.d and /etc/fstab files are the same, though I haven't checked every one of the rules.d files.
I'm attaching scope-boot sequence output from usbmon for the two machines. The working one is daq and the non-working one is Johnny5... (There's a wry joke there for Short Circuit fans.) I can slowly process usbmon output manually, but I don't know what I'm looking for, or what other setup files might be implicated.
The usbmon output for the working machine is much longer during the boot sequence, and includes a comparable amount of data when I try to talk to it.
Here's an annotated version of the usbfs_snoop output. Again, I'm not real sure what I'm looking for in it:
24521a24522,26572
> Aug 18 16:51:05 Johnny5 kernel: usb 3-1: usbdev_ioctl: CONNECTINFO
> Aug 18 16:51:05 Johnny5 kernel: usb 3-1: usbdev_ioctl: IOCTL
> Aug 18 16:51:05 Johnny5 kernel: usb 1-2: usbdev_ioctl: CONNECTINFO
> Aug 18 16:51:05 Johnny5 kernel: usb 1-2: usbdev_ioctl: IOCTL
> Aug 18 16:51:05 Johnny5 kernel: usb 3-1: usbdev_ioctl: CONTROL
> Aug 18 16:51:05 Johnny5 kernel: usb 3-1: control read: bRequest=06 bRrequestType=80 wValue=0300 wIndex=0000 wLength=00ff
> Aug 18 16:51:05 Johnny5 kernel: usb 3-1: control read: data 04 03 09 04
> Aug 18 16:51:05 Johnny5 kernel: usb 3-1: usbdev_ioctl: CONTROL
> Aug 18 16:51:05 Johnny5 kernel: usb 3-1: control read: bRequest=06 bRrequestType=80 wValue=0303 wIndex=0409 wLength=00ff
> Aug 18 16:51:05 Johnny5 kernel: usb 3-1: control read: data 10 03 43 00 30 00 33 00 38 00 36 00 36 00 34 00
> Aug 18 16:51:10 Johnny5 kernel: usb 3-1: usbdev_ioctl: CONNECTINFO
> Aug 18 16:51:10 Johnny5 kernel: usb 3-1: usbdev_ioctl: IOCTL
> Aug 18 16:51:11 Johnny5 kernel: usb 1-2: usbdev_ioctl: CONNECTINFO
> Aug 18 16:51:11 Johnny5 kernel: usb 1-2: usbdev_ioctl: IOCTL
> Aug 18 16:51:11 Johnny5 kernel: usb 3-1: usbdev_ioctl: CONTROL
> Aug 18 16:51:11 Johnny5 kernel: usb 3-1: control read: bRequest=06 bRrequestType=80 wValue=0300 wIndex=0000 wLength=00ff
> Aug 18 16:51:11 Johnny5 kernel: usb 3-1: control read: data 04 03 09 04
> Aug 18 16:51:11 Johnny5 kernel: usb 3-1: usbdev_ioctl: CONTROL
> Aug 18 16:51:11 Johnny5 kernel: usb 3-1: control read: bRequest=06 bRrequestType=80 wValue=0303 wIndex=0409 wLength=00ff
> Aug 18 16:51:11 Johnny5 kernel: usb 3-1: control read: data 10 03 43 00 30 00 33 00 38 00 36 00 36 00 34 00
> Aug 18 16:51:11 Johnny5 kernel: usb 3-1: usbdev_ioctl: RESET
> Aug 18 16:51:11 Johnny5 kernel: usb 3-1: reset full speed USB device using uhci_hcd and address 3
> Aug 18 16:51:12 Johnny5 kernel: usb 3-1: usbdev_ioctl: CLAIMINTERFACE
> Aug 18 16:51:13 Johnny5 kernel: usb 3-1: usbdev_ioctl: SUBMITURB
> Aug 18 16:51:13 Johnny5 kernel: usb 3-1: bulk urb sending a bulk-out message
> Aug 18 16:51:13 Johnny5 kernel: usb 3-1: direction=OUT
> Aug 18 16:51:13 Johnny5 kernel: usb 3-1: userurb=00007f4b6319dfd0
> Aug 18 16:51:13 Johnny5 kernel: usb 3-1: transfer_buffer_length=20
> Aug 18 16:51:13 Johnny5 kernel: usb 3-1: actual_length=0
> Aug 18 16:51:13 Johnny5 kernel: usb 3-1: data: 01 01 fe 00 07 00 00 00 01 00 00 00 6c 6f 63 20 61 6c 6c 00 message 1, 7 characters: loc all
> Aug 18 16:51:13 Johnny5 kernel: usb 3-1: usbdev_ioctl: REAPURBDELAY
> Aug 18 16:51:13 Johnny5 kernel: usb 3-1: usbdev_ioctl: REAPURBDELAY
> Aug 18 16:51:13 Johnny5 kernel: usb 3-1: usbdev_ioctl: REAPURBDELAY
[...repeats many times over the course of the four-second timeout...]
> Aug 18 16:51:17 Johnny5 kernel: usb 3-1: usbdev_ioctl: REAPURBDELAY
> Aug 18 16:51:17 Johnny5 kernel: usb 3-1: usbdev_ioctl: REAPURBDELAY
> Aug 18 16:51:17 Johnny5 kernel: usb 3-1: usbdev_ioctl: REAPURBDELAY
> Aug 18 16:51:17 Johnny5 kernel: usb 3-1: usbdev_ioctl: SUBMITURB
> Aug 18 16:51:17 Johnny5 kernel: usb 3-1: bulk urb sending a bulk-out message
> Aug 18 16:51:17 Johnny5 kernel: usb 3-1: direction=OUT
> Aug 18 16:51:17 Johnny5 kernel: usb 3-1: userurb=00007f4b6319e700
> Aug 18 16:51:17 Johnny5 kernel: usb 3-1: transfer_buffer_length=20
> Aug 18 16:51:17 Johnny5 kernel: usb 3-1: actual_length=0
> Aug 18 16:51:17 Johnny5 kernel: usb 3-1: data: 01 01 fe 00 07 00 00 00 01 00 00 00 6c 6f 63 20 6e 6f 6e 00 message 1, 7 characters: loc non
> Aug 18 16:51:17 Johnny5 kernel: usb 3-1: usbdev_ioctl: REAPURBDELAY
> Aug 18 16:51:17 Johnny5 kernel: usb 3-1: usbdev_ioctl: REAPURBDELAY
> Aug 18 16:51:17 Johnny5 kernel: usb 3-1: usbdev_ioctl: REAPURBDELAY
[...repeats many times over the course of the four-second timeout...]
> Aug 18 16:51:21 Johnny5 kernel: usb 3-1: usbdev_ioctl: REAPURBDELAY
> Aug 18 16:51:21 Johnny5 kernel: usb 3-1: usbdev_ioctl: REAPURBDELAY
> Aug 18 16:51:21 Johnny5 kernel: usb 3-1: usbdev_ioctl: REAPURBDELAY
> Aug 18 16:51:21 Johnny5 kernel: usb 3-1: usbdev_ioctl: RELEASEINTERFACE
> Aug 18 16:51:21 Johnny5 kernel: usb 3-1: urb complete
> Aug 18 16:51:21 Johnny5 kernel: usb 3-1: direction=OUT
> Aug 18 16:51:21 Johnny5 kernel: usb 3-1: userurb=00007f4b6319dfd0
> Aug 18 16:51:21 Johnny5 kernel: usb 3-1: transfer_buffer_length=20
> Aug 18 16:51:21 Johnny5 kernel: usb 3-1: actual_length=0
> Aug 18 16:51:21 Johnny5 kernel: usb 3-1: data: 01 01 fe 00 07 00 00 00 01 00 00 00 6c 6f 63 20 61 6c 6c 00 message 1, 7 characters: loc all
> Aug 18 16:51:21 Johnny5 kernel: usb 3-1: urb complete
> Aug 18 16:51:21 Johnny5 kernel: usb 3-1: direction=OUT
> Aug 18 16:51:21 Johnny5 kernel: usb 3-1: userurb=00007f4b6319e700
> Aug 18 16:51:21 Johnny5 kernel: usb 3-1: transfer_buffer_length=20
> Aug 18 16:51:21 Johnny5 kernel: usb 3-1: actual_length=0
> Aug 18 16:51:21 Johnny5 kernel: usb 3-1: data: 01 01 fe 00 07 00 00 00 01 00 00 00 6c 6f 63 20 6e 6f 6e 00 message 1, 7 characters: loc non
I'd appreciate any suggestions you have about tracking down the difference / problem.
Thank you
-Sarah
[-- Attachment #2: monboot.daq.txt --]
[-- Type: text/plain, Size: 5893 bytes --]
ffff88007d99fd80 2897642659 C Ii:1:007:1 0:2048 1 = 02
ffff88007d99fd80 2897642675 S Ii:1:007:1 -115:2048 1 <
ffff88007e433cc0 2897642688 S Ci:1:007:0 s a3 00 0000 0001 0004 4 <
ffff88007e433cc0 2897642774 C Ci:1:007:0 0 4 = 00010100
ffff88007e433cc0 2897642784 S Co:1:007:0 s 23 01 0010 0001 0000 0
ffff88007e433cc0 2897642898 C Co:1:007:0 0 0
ffff88007d9a9980 2897643364 S Ci:1:007:0 s a3 00 0000 0001 0004 4 <
ffff88007d9a9980 2897643399 C Ci:1:007:0 0 4 = 00010000
ffff88007e4334c0 2897679556 S Ci:1:007:0 s a3 00 0000 0001 0004 4 <
ffff88007e4334c0 2897679651 C Ci:1:007:0 0 4 = 00010000
ffff88007e4334c0 2897707530 S Ci:1:007:0 s a3 00 0000 0001 0004 4 <
ffff88007e4334c0 2897707648 C Ci:1:007:0 0 4 = 00010000
ffff88007e4334c0 2897739541 S Ci:1:007:0 s a3 00 0000 0001 0004 4 <
ffff88007e4334c0 2897739648 C Ci:1:007:0 0 4 = 00010000
ffff88007e4334c0 2897771529 S Ci:1:007:0 s a3 00 0000 0001 0004 4 <
ffff88007e4334c0 2897771648 C Ci:1:007:0 0 4 = 00010000
ffff88007d99fd80 2899979679 C Ii:1:007:1 -2:2048 0
ffff88007e4334c0 2899979690 S Co:1:007:0 s 00 03 0001 0000 0000 0
ffff88007e4334c0 2899979778 C Co:1:007:0 0 0
ffff88007e4334c0 2899979821 S Co:1:002:0 s 23 03 0002 0004 0000 0
ffff88007e4334c0 2899979901 C Co:1:002:0 0 0
ffff88007d4ff6c0 2929386709 C Ii:1:002:1 0:2048 1 = 10
ffff88007d4ff6c0 2929386723 S Ii:1:002:1 -115:2048 1 <
ffff880074046a80 2929386792 S Ci:1:002:0 s a3 00 0000 0004 0004 4 <
ffff880074046a80 2929386822 C Ci:1:002:0 0 4 = 03050400
ffff880074046a80 2929386848 S Co:1:002:0 s 23 01 0012 0004 0000 0
ffff880074046a80 2929386945 C Co:1:002:0 0 0
ffff880074046a80 2929399531 S Ci:1:002:0 s a3 00 0000 0004 0004 4 <
ffff880074046a80 2929399570 C Ci:1:002:0 0 4 = 03050000
ffff880074046a80 2929399598 S Ci:1:007:0 s 80 00 0000 0000 0002 2 <
ffff880074046a80 2929399696 C Ci:1:007:0 0 2 = 0300
ffff880074046a80 2929399721 S Co:1:007:0 s 00 01 0001 0000 0000 0
ffff880074046a80 2929399821 C Co:1:007:0 0 0
ffff880074046a80 2929399846 S Ci:1:007:0 s a3 00 0000 0001 0004 4 <
ffff880074046a80 2929399946 C Ci:1:007:0 0 4 = 01010100
ffff880074046a80 2929399971 S Co:1:007:0 s 23 01 0010 0001 0000 0
ffff880074046a80 2929400070 C Co:1:007:0 0 0
ffff880074046a80 2929400095 S Ci:1:007:0 s a3 00 0000 0002 0004 4 <
ffff880074046a80 2929400195 C Ci:1:007:0 0 4 = 00010000
ffff880074046a80 2929400220 S Ci:1:007:0 s a3 00 0000 0003 0004 4 <
ffff880074046a80 2929400320 C Ci:1:007:0 0 4 = 00010000
ffff880074046a80 2929400345 S Ci:1:007:0 s a3 00 0000 0004 0004 4 <
ffff880074046a80 2929400446 C Ci:1:007:0 0 4 = 00010000
ffff880074046a80 2929400471 S Ci:1:007:0 s a3 00 0000 0005 0004 4 <
ffff880074046a80 2929400571 C Ci:1:007:0 0 4 = 00010000
ffff880074046a80 2929400596 S Ci:1:007:0 s a3 00 0000 0006 0004 4 <
ffff880074046a80 2929400696 C Ci:1:007:0 0 4 = 00010000
ffff880074046a80 2929400720 S Ci:1:007:0 s a3 00 0000 0007 0004 4 <
ffff880074046a80 2929400820 C Ci:1:007:0 0 4 = 00010000
ffff88007d99fd80 2929503528 S Ii:1:007:1 -115:2048 1 <
ffff880074046a80 2929503537 S Ci:1:007:0 s a3 00 0000 0001 0004 4 <
ffff880074046a80 2929503570 C Ci:1:007:0 0 4 = 01010000
ffff880074046a80 2929503606 S Co:1:007:0 s 23 03 0004 0001 0000 0
ffff880074046a80 2929503695 C Co:1:007:0 0 0
ffff880074046a80 2929519529 S Ci:1:007:0 s a3 00 0000 0001 0004 4 <
ffff880074046a80 2929519571 C Ci:1:007:0 0 4 = 03011000
ffff880074046a80 2929575530 S Co:1:007:0 s 23 01 0014 0001 0000 0
ffff880074046a80 2929575571 C Co:1:007:0 0 0
ffff880074046a80 2929575613 S Ci:1:000:0 s 80 06 0100 0000 0040 64 <
ffff880074046a80 2929575821 C Ci:1:000:0 0 18 = 12010002 00000040 99066803 42000102 0301
ffff880074046a80 2929575847 S Co:1:007:0 s 23 03 0004 0001 0000 0
ffff880074046a80 2929575946 C Co:1:007:0 0 0
ffff880074046a80 2929591530 S Ci:1:007:0 s a3 00 0000 0001 0004 4 <
ffff880074046a80 2929591571 C Ci:1:007:0 0 4 = 03011000
ffff88007d99fd80 2929642708 C Ii:1:007:1 0:2048 1 = 02
ffff88007d99fd80 2929642712 S Ii:1:007:1 -115:2048 1 <
ffff880074046a80 2929647530 S Co:1:007:0 s 23 01 0014 0001 0000 0
ffff880074046a80 2929647571 C Co:1:007:0 0 0
ffff880074046a80 2929647598 S Co:1:000:0 s 00 05 0015 0000 0000 0
ffff880074046a80 2929647821 C Co:1:000:0 0 0
ffff880074046a80 2929667530 S Ci:1:021:0 s 80 06 0100 0000 0012 18 <
ffff880074046a80 2929667696 C Ci:1:021:0 0 18 = 12010002 00000040 99066803 42000102 0301
ffff880074046a80 2929667726 S Ci:1:021:0 s 80 06 0600 0000 000a 10 <
ffff880074046a80 2929667821 C Ci:1:021:0 -32 0
ffff880074046a80 2929667848 S Ci:1:021:0 s 80 06 0600 0000 000a 10 <
ffff880074046a80 2929668070 C Ci:1:021:0 -32 0
ffff880074046a80 2929668097 S Ci:1:021:0 s 80 06 0600 0000 000a 10 <
ffff880074046a80 2929668321 C Ci:1:021:0 -32 0
ffff880074046a80 2929668351 S Ci:1:021:0 s 80 06 0200 0000 0009 9 <
ffff880074046a80 2929668571 C Ci:1:021:0 0 9 = 09022700 010100c0 32
ffff880074046a80 2929668598 S Ci:1:021:0 s 80 06 0200 0000 0027 39 <
ffff880074046a80 2929668821 C Ci:1:021:0 0 39 = 09022700 010100c0 32090400 0003fe03 01000705 85024000 00070506 02400000
ffff880074046280 2929668853 S Ci:1:021:0 s 80 06 0300 0000 00ff 255 <
ffff880074046280 2929668946 C Ci:1:021:0 0 4 = 04030904
ffff880074046280 2929668971 S Ci:1:021:0 s 80 06 0302 0409 00ff 255 <
ffff880074046280 2929669071 C Ci:1:021:0 0 38 = 26035400 65006b00 74007200 6f006e00 69007800 20005400 44005300 32003000
ffff880074046280 2929669100 S Ci:1:021:0 s 80 06 0301 0409 00ff 255 <
ffff880074046280 2929669196 C Ci:1:021:0 0 32 = 20035400 65006b00 74007200 6f006e00 69007800 2c002000 49006e00 63002e00
ffff880074046280 2929669224 S Ci:1:021:0 s 80 06 0303 0409 00ff 255 <
ffff880074046280 2929669321 C Ci:1:021:0 0 16 = 10034300 30003300 38003800 36003300
ffff880074046b80 2929669488 S Co:1:021:0 s 00 09 0001 0000 0000 0
ffff880074046b80 2929669696 C Co:1:021:0 0 0
ffff880074046b80 2929670002 S Ci:1:007:0 s a3 00 0000 0001 0004 4 <
ffff880074046b80 2929670071 C Ci:1:007:0 0 4 = 03010000
[-- Attachment #3: monboot.Johnny5.txt --]
[-- Type: text/plain, Size: 3100 bytes --]
ffff88007dd1c4c0 3189519458 S Ci:3:001:0 s a3 00 0000 0001 0004 4 <
ffff88007dd1c4c0 3189519475 C Ci:3:001:0 0 4 = 01010100
ffff88007dd1c4c0 3189519481 S Co:3:001:0 s 23 01 0010 0001 0000 0
ffff88007dd1c4c0 3189519484 C Co:3:001:0 0 0
ffff88007dd1c4c0 3189519486 S Ci:3:001:0 s a3 00 0000 0002 0004 4 <
ffff88007dd1c4c0 3189519490 C Ci:3:001:0 0 4 = 00010000
ffff88007d47ec80 3189623546 S Ii:3:001:1 -115:128 2 <
ffff88007dd1c4c0 3189623558 S Ci:3:001:0 s a3 00 0000 0001 0004 4 <
ffff88007dd1c4c0 3189623562 C Ci:3:001:0 0 4 = 01010000
ffff88007dd1c4c0 3189623571 S Co:3:001:0 s 23 03 0004 0001 0000 0
ffff88007dd1c4c0 3189623575 C Co:3:001:0 0 0
ffff88007dd1c4c0 3189679732 S Ci:3:001:0 s a3 00 0000 0001 0004 4 <
ffff88007dd1c4c0 3189679755 C Ci:3:001:0 0 4 = 03010000
ffff88007dd1c4c0 3189735931 S Co:3:001:0 s 23 01 0014 0001 0000 0
ffff88007dd1c4c0 3189735935 C Co:3:001:0 0 0
ffff88007dd1c4c0 3189735944 S Ci:3:000:0 s 80 06 0100 0000 0040 64 <
ffff88007dd1c4c0 3189739939 C Ci:3:000:0 0 18 = 12010002 00000040 99066803 42000102 0301
ffff88007dd1c4c0 3189740237 S Co:3:001:0 s 23 03 0004 0001 0000 0
ffff88007dd1c4c0 3189740245 C Co:3:001:0 0 0
ffff88007dd1c4c0 3189795942 S Ci:3:001:0 s a3 00 0000 0001 0004 4 <
ffff88007dd1c4c0 3189795965 C Ci:3:001:0 0 4 = 03010000
ffff88007dd1c4c0 3189851930 S Co:3:001:0 s 23 01 0014 0001 0000 0
ffff88007dd1c4c0 3189851935 C Co:3:001:0 0 0
ffff88007dd1c4c0 3189851943 S Co:3:000:0 s 00 05 000a 0000 0000 0
ffff88007dd1c4c0 3189854931 C Co:3:000:0 0 0
ffff88007dd1c4c0 3189871932 S Ci:3:010:0 s 80 06 0100 0000 0012 18 <
ffff88007dd1c4c0 3189875930 C Ci:3:010:0 0 18 = 12010002 00000040 99066803 42000102 0301
ffff88007dd1c4c0 3189875956 S Ci:3:010:0 s 80 06 0600 0000 000a 10 <
ffff88007dd1c4c0 3189878929 C Ci:3:010:0 -32 0
ffff88007dd1c4c0 3189878952 S Ci:3:010:0 s 80 06 0600 0000 000a 10 <
ffff88007dd1c4c0 3189881929 C Ci:3:010:0 -32 0
ffff88007dd1c4c0 3189881952 S Ci:3:010:0 s 80 06 0600 0000 000a 10 <
ffff88007dd1c4c0 3189884929 C Ci:3:010:0 -32 0
ffff88007dd1c4c0 3189884954 S Ci:3:010:0 s 80 06 0200 0000 0009 9 <
ffff88007dd1c4c0 3189888929 C Ci:3:010:0 0 9 = 09022700 010100c0 32
ffff88007dd1c4c0 3189888953 S Ci:3:010:0 s 80 06 0200 0000 0027 39 <
ffff88007dd1c4c0 3189892929 C Ci:3:010:0 0 39 = 09022700 010100c0 32090400 0003fe03 01000705 85024000 00070506 02400000
ffff88007e955980 3189892974 S Ci:3:010:0 s 80 06 0300 0000 00ff 255 <
ffff88007e955980 3189897929 C Ci:3:010:0 0 4 = 04030904
ffff88007e955980 3189897953 S Ci:3:010:0 s 80 06 0302 0409 00ff 255 <
ffff88007e955980 3189902928 C Ci:3:010:0 0 38 = 26035400 65006b00 74007200 6f006e00 69007800 20005400 44005300 32003000
ffff88007e955980 3189902956 S Ci:3:010:0 s 80 06 0301 0409 00ff 255 <
ffff88007e955980 3189907928 C Ci:3:010:0 0 32 = 20035400 65006b00 74007200 6f006e00 69007800 2c002000 49006e00 63002e00
ffff88007e955980 3189907957 S Ci:3:010:0 s 80 06 0303 0409 00ff 255 <
ffff88007e955980 3189912927 C Ci:3:010:0 0 16 = 10034300 30003300 38003600 36003400
ffff88007dd1c0c0 3189913064 S Co:3:010:0 s 00 09 0001 0000 0000 0
ffff88007dd1c0c0 3189915935 C Co:3:010:0 0 0
^ permalink raw reply
* cold-plugged usb flash drive not handled correctly in embedded
From: Wolfgang Wegner @ 2010-08-20 14:42 UTC (permalink / raw)
To: linux-hotplug
Hi list,
I am having a problem with udev on an embedded system and
am asking for advice on how to track this down. The system is
an ARM (kirkwood) platform with a busybox-based init. I cross-
compiled udev-161, made a simple udev start script (basically
ripped off from debian and stripped from most of the config
stuff) and a very basic rules file in
/etc/udev/rules.d/50-udev.rules:
ACTION="add", KERNEL="sd[a-z][0-9]", RUN+="/bin/mount -t auto -o rw,noauto,flush,quiet,nodev,nosuid,exec,noatime,dmask\00,fmask\x111 /dev/%k /mnt/usbdisk", OPTIONS="last_rule"
ACTION="remove", KERNEL="sd[a-z][0-9]", RUN+="/bin/umount -l /mnt/usbdisk"
It does not matter if I leave the standard rules in
/libexec/rules.d/ or if I remove them altogether, in either
case the USB flash drive is correctly mounted when plugged
into the running system but not when it is already present when
the system boots up.
I enabled debugging in udev, but have to admit I am a bit
overwhelmed by all the logging then. Here some parts which
seem to show that I did not make an obvious mistake:
udev reads correct rules file:
7.953380 [578] parse_file: reading '/etc/udev/rules.d/50-udev.rules' as rules file
Triggered by udevadm trigger, the device is correctly enumerated:
18.530148 [586] udev_device_new_from_syspath: device 0x40770 has devpath '/devices/platform/orion-ehci.0/usb1/1-1/1-1:1.0/host2/target2:0:0/2:0:0:0/block/sda/sda1'
18.530268 [586] udev_rules_apply_to_event: LINK 'block/8:1' //libexec/rules.d/50-udev-default.rules:3
18.530343 [586] udev_rules_apply_to_event: GROUP 0 //libexec/rules.d/50-udev-default.rules:72
18.530490 [586] udev_device_new_from_syspath: device 0x3eb40 has devpath '/devices/platform/orion-ehci.0/usb1/1-1/1-1:1.0/host2/target2:0:0/2:0:0:0/block/sda'
18.530894 [586] udev_device_read_db: device 0x3eb40 filled with db file data
But the mount is not executed.
When checking what would have to be done for this device manually,
the actions are correctly shown:
udevadm_test: DEVPATH=/devices/platform/orion-ehci.0/usb1/1-1/1-1:1.0/host2/target2:0:0/2:0:0:0/block/sda/sda1
[...]
udevadm_test: /dev/sda1: UUID\b56-17AE
udevadm_test: run: '/bin/mount -t auto -o rw,noauto,flush,quiet,nodev,nosuid,exec,noatime,dmask\00,fmask\x111 /dev/sda1 /mnt/usbdisk'
And removing the device also triggers the unmount:
405.042924 [623] udev_device_read_db: device 0x2b068 filled with db file data
405.043050 [623] udev_rules_apply_to_event: RUN '/bin/umount -l /mnt/usbdisk' /etc/udev/rules.d/50-udev.rules:8
while re-inserting finally also runs the mount:
417.490164 [623] udev_device_new_from_syspath: device 0x30148 has devpath '/devices/platform/orion-ehci.0/usb1/1-1/1-1:1.0/host3/target3:0:0/3:0:0:0/block/sda/sda1'
417.490282 [623] udev_rules_apply_to_event: LINK 'block/8:1' //libexec/rules.d/50-udev-default.rules:3
417.490358 [623] udev_rules_apply_to_event: GROUP 0 //libexec/rules.d/50-udev-default.rules:72
417.490408 [623] udev_rules_apply_to_event: RUN '/bin/mount -t auto -o rw,noauto,flush,quiet,nodev,nosuid,exec,noatime,dmask\00,fmask\x111 /dev/%k /mnt/usbdisk' /etc/udev/rules.d/50-udev.rules:6
417.490554 [623] udev_device_new_from_syspath: device 0x304a0 has devpath '/devices/platform/orion-ehci.0/usb1/1-1/1-1:1.0/host3/target3:0:0/3:0:0:0/block/sda'
417.490987 [623] udev_device_read_db: device 0x304a0 filled with db file data
Can anybody point me to where I have to look for the problem?
Which additional information is needed - if any - to give a
hint?
Thank you and best regards,
Wolfgang
^ permalink raw reply
* Re: cold-plugged usb flash drive not handled correctly in embedded system
From: Kay Sievers @ 2010-08-20 14:51 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100820144236.GD10027@debian-wegner1.datadisplay.de>
On Fri, Aug 20, 2010 at 16:42, Wolfgang Wegner <ww-ml@gmx.de> wrote:
> /etc/udev/rules.d/50-udev.rules:
> ACTION="add", KERNEL="sd[a-z][0-9]", RUN+="/bin/mount -t auto -o rw,noauto,flush,quiet,nodev,nosuid,exec,noatime,dmask\00,fmask\x111 /dev/%k /mnt/usbdisk", OPTIONS="last_rule"
udev 161 has no "last_rule" thing anymore.
You mount all devices, the possibly built-in ,and the plugged-in
devices at the same place? :)
> It does not matter if I leave the standard rules in
> /libexec/rules.d/ or if I remove them altogether, in either
> case the USB flash drive is correctly mounted when plugged
> into the running system but not when it is already present when
> the system boots up.
The event for the device happens during early boot where you have no
chance to mount. Do you run 'udevadm trigger' at bootup? It will
re-generate all events so that they can be handled when userspace is
running. It would need --actiond for your current rule to match.
Kay
^ permalink raw reply
* Re: cold-plugged usb flash drive not handled correctly in embedded
From: Wolfgang Wegner @ 2010-08-20 15:00 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100820144236.GD10027@debian-wegner1.datadisplay.de>
Hi,
On Fri, Aug 20, 2010 at 04:51:44PM +0200, Kay Sievers wrote:
> On Fri, Aug 20, 2010 at 16:42, Wolfgang Wegner <ww-ml@gmx.de> wrote:
> > /etc/udev/rules.d/50-udev.rules:
> > ACTION="add", KERNEL="sd[a-z][0-9]", RUN+="/bin/mount -t auto -o rw,noauto,flush,quiet,nodev,nosuid,exec,noatime,dmask\00,fmask\x111 /dev/%k /mnt/usbdisk", OPTIONS="last_rule"
>
> udev 161 has no "last_rule" thing anymore.
ok, but I guess this does not change anything, especially in the
case when I use this as the only rule. ;-)
> You mount all devices, the possibly built-in ,and the plugged-in
> devices at the same place? :)
Yes, currently I do, because only one USB device is "supported".
> > It does not matter if I leave the standard rules in
> > /libexec/rules.d/ or if I remove them altogether, in either
> > case the USB flash drive is correctly mounted when plugged
> > into the running system but not when it is already present when
> > the system boots up.
>
> The event for the device happens during early boot where you have no
> chance to mount. Do you run 'udevadm trigger' at bootup? It will
> re-generate all events so that they can be handled when userspace is
> running. It would need --actiond for your current rule to match.
The busybox start script (/etc/init.d/rcS) runs my udev start script
(/etc/init.d/start_udev.sh) which in turn runs udevadm trigger as
one of the last steps:
[...]
udevd --daemon --debug
mkdir -p /dev/.udev/queue/ /dev/.udev/rules.d/
create_dev_root_rule /dev/.udev/
udevadm trigger
create_dev_makedev
udevadm settle
exit 0
Again, I have to admit I do not really understand what
create_dev_makedev is for (copied from debian), but I am quite
sure it can do no harm...
From my understanding, this should generate all the events -
and I see the event is there, because of this:
18.530148 [586] udev_device_new_from_syspath: device 0x40770 has devpath '/devices/platform/orion-ehci.0/usb1/1-1/1-1:1.0/host2/target2:0:0/2:0:0:0/block/sda/sda1'
18.530268 [586] udev_rules_apply_to_event: LINK 'block/8:1' //libexec/rules.d/50-udev-default.rules:3
18.530343 [586] udev_rules_apply_to_event: GROUP 0 //libexec/rules.d/50-udev-default.rules:72
18.530490 [586] udev_device_new_from_syspath: device 0x3eb40 has devpath '/devices/platform/orion-ehci.0/usb1/1-1/1-1:1.0/host2/target2:0:0/2:0:0:0/block/sda'
18.530894 [586] udev_device_read_db: device 0x3eb40 filled with db file data
All I am missing is the "RUN" line here.
BTW, amazing response time! :-)
Regards,
Wolfgang
^ permalink raw reply
* Re: cold-plugged usb flash drive not handled correctly in embedded
From: Wolfgang Wegner @ 2010-08-20 15:19 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100820144236.GD10027@debian-wegner1.datadisplay.de>
On Fri, Aug 20, 2010 at 04:51:44PM +0200, Kay Sievers wrote:
> On Fri, Aug 20, 2010 at 16:42, Wolfgang Wegner <ww-ml@gmx.de> wrote:
> > /etc/udev/rules.d/50-udev.rules:
> > ACTION="add", KERNEL="sd[a-z][0-9]", RUN+="/bin/mount -t auto -o rw,noauto,flush,quiet,nodev,nosuid,exec,noatime,dmask\00,fmask\x111 /dev/%k /mnt/usbdisk", OPTIONS="last_rule"
>
> udev 161 has no "last_rule" thing anymore.
>
> You mount all devices, the possibly built-in ,and the plugged-in
> devices at the same place? :)
sorry, I should have made this clear: there is no built-in sd*
device, all internal filesystems reside in UBIFS.
(But I agree that I should make a real mount script for the
release version, just in case somebody comes up with an USB
hub or a multi card reader. ;-) )
Regards,
Wolfgang
^ permalink raw reply
* Re: cold-plugged usb flash drive not handled correctly in embedded
From: Greg KH @ 2010-08-20 15:29 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100820144236.GD10027@debian-wegner1.datadisplay.de>
On Fri, Aug 20, 2010 at 04:42:36PM +0200, Wolfgang Wegner wrote:
> Hi list,
>
> I am having a problem with udev on an embedded system and
> am asking for advice on how to track this down. The system is
> an ARM (kirkwood) platform with a busybox-based init. I cross-
> compiled udev-161, made a simple udev start script (basically
> ripped off from debian and stripped from most of the config
> stuff) and a very basic rules file in
> /etc/udev/rules.d/50-udev.rules:
> ACTION="add", KERNEL="sd[a-z][0-9]", RUN+="/bin/mount -t auto -o rw,noauto,flush,quiet,nodev,nosuid,exec,noatime,dmask\00,fmask\x111 /dev/%k /mnt/usbdisk", OPTIONS="last_rule"
> ACTION="remove", KERNEL="sd[a-z][0-9]", RUN+="/bin/umount -l /mnt/usbdisk"
>
> It does not matter if I leave the standard rules in
> /libexec/rules.d/ or if I remove them altogether, in either
> case the USB flash drive is correctly mounted when plugged
> into the running system but not when it is already present when
> the system boots up.
Perhaps because you do not have a 'mount' executable when the device is
found during the boot process?
thanks,
greg k-h
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox