* Re: udev: timeout on WAIT_FOR_SYSFS
From: Filipe Brandenburger @ 2011-08-02 19:43 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CABe66sWBkuV+Faof9V_6L4sXzxNdUtyGWmFQLbitnpF7Q89=TA@mail.gmail.com>
Hi Kay, thanks for your answers!
On Tue, Aug 2, 2011 at 15:30, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Tue, Aug 2, 2011 at 16:57, Filipe Brandenburger <filbranden@gmail.com> wrote:
>> I tried adding a call to "udevsettle" just before initializing VxVM
>> but it doesn't help, whenever I have the problem that triggers that
>> log message the devices do not show up even after udevsettle. I also
>> tried "udevtrigger" but that didn't help either.
>
> Missing devices are likely not related to udev but your
> driver/hardware/setup. I guess in the case you miss the stuff, you
> also don't have the device in /sys/block, right?
Indeed, that's the problem, the problem device is not present in
/sys/block or in /dev.
>> I saw this patch that looked interesting, it's from almost 4 years ago
>> but it resembles the codebase of RHEL5 that I'm running:
>> http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h9ea7c6c67de69379b603196a0eff6f7ce2e469a
>>
>> I'm pretty much considering applying that patch to udevd since it will
>> probably fix it, but as I can't reproduce the problem reliably I
>> wanted to ask some questions just to have more confidence in going on
>> with that fix.
>
> As said, that only makes the error logging go away, and maybe some
> udev-event users that expect proper sysfs timing.
Hmmm... So you're saying there's no correlation from the fact that I
get the "wait_for_sysfs: waiting for ... failed" message and the fact
that when I need the devices (on volume manager startup) they are
still not present? Even if I have a call to "udevsettle" just before
the volume manager initialization? Won't the failure of wait_for_sysfs
affect the result of a "udevsettle" call?
>> For instance, the log message is somewhat vague saying some SCSI disks
>> take 6.5s to populate sysfs, does someone have some details of which
>> kinds of disks cause that?
>
> I don't really remember the details, but it was probably the disk
> spin-up time, that blocked the creation of the sysfs files for
> seconds. The code that does that got all changed in later kernels to
> be timed properly.
Ok, so is it possible that this is the issue I have here? I only have
it in one machine so it may be because of faulty/suboptimal SAN behind
it?
Thanks for your answers, I'm trying to get to the bottom of it and
hopefully your help will lead me into the right direction!
Fil
^ permalink raw reply
* Re: udev: timeout on WAIT_FOR_SYSFS
From: Kay Sievers @ 2011-08-02 19:49 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CABe66sWBkuV+Faof9V_6L4sXzxNdUtyGWmFQLbitnpF7Q89=TA@mail.gmail.com>
On Tue, Aug 2, 2011 at 21:43, Filipe Brandenburger <filbranden@gmail.com> wrote:
> On Tue, Aug 2, 2011 at 15:30, Kay Sievers <kay.sievers@vrfy.org> wrote:
>> On Tue, Aug 2, 2011 at 16:57, Filipe Brandenburger <filbranden@gmail.com> wrote:
>>> I tried adding a call to "udevsettle" just before initializing VxVM
>>> but it doesn't help, whenever I have the problem that triggers that
>>> log message the devices do not show up even after udevsettle. I also
>>> tried "udevtrigger" but that didn't help either.
>>
>> Missing devices are likely not related to udev but your
>> driver/hardware/setup. I guess in the case you miss the stuff, you
>> also don't have the device in /sys/block, right?
>
> Indeed, that's the problem, the problem device is not present in
> /sys/block or in /dev.
Then the kernel has not created the device. There is nothing that udev
can do here. The message is probably only a fallout of an error that a
SCSI LUN was created, but the it failed to setup the block device.
>>> I saw this patch that looked interesting, it's from almost 4 years ago
>>> but it resembles the codebase of RHEL5 that I'm running:
>>> http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h9ea7c6c67de69379b603196a0eff6f7ce2e469a
>>>
>>> I'm pretty much considering applying that patch to udevd since it will
>>> probably fix it, but as I can't reproduce the problem reliably I
>>> wanted to ask some questions just to have more confidence in going on
>>> with that fix.
>>
>> As said, that only makes the error logging go away, and maybe some
>> udev-event users that expect proper sysfs timing.
>
> Hmmm... So you're saying there's no correlation from the fact that I
> get the "wait_for_sysfs: waiting for ... failed" message and the fact
> that when I need the devices (on volume manager startup) they are
> still not present? Even if I have a call to "udevsettle" just before
> the volume manager initialization? Won't the failure of wait_for_sysfs
> affect the result of a "udevsettle" call?
It should only block until the timeout happens, which is 5 or 10
seconds, then settle should exit.
>>> For instance, the log message is somewhat vague saying some SCSI disks
>>> take 6.5s to populate sysfs, does someone have some details of which
>>> kinds of disks cause that?
>>
>> I don't really remember the details, but it was probably the disk
>> spin-up time, that blocked the creation of the sysfs files for
>> seconds. The code that does that got all changed in later kernels to
>> be timed properly.
>
> Ok, so is it possible that this is the issue I have here? I only have
> it in one machine so it may be because of faulty/suboptimal SAN behind
> it?
It's probably the disk itself, but it's hard to tell from remote. You
need to investigate the disk, and all the hardware that connects it to
the host, or even the driver. I don't think it has anything to do with
udev, or the upper layers. You need to see /sys/block/sdX, before you
look into anything udev related.
Kay
Kay
^ permalink raw reply
* udevadm: trigger --type=failed deprecation
From: Matthew Burgess @ 2011-08-02 22:01 UTC (permalink / raw)
To: linux-hotplug
Hi all,
So, Udev-173 added a log message warning us that 'udevadm trigger
--typeúiled' is deprecated, which over in LFS we use in a 'udev_retry'
bootscript in an attempt to retry failed events, for example those
caused by slow device initialization.
The ChangeLog fails to mention a preferred alternative mechanism for
performing such event retries, or are such things not needed due to
changes in the kernel?
Any advice you can give would be appreciated.
Thanks,
Matt.
^ permalink raw reply
* Re: udevadm: trigger --type=failed deprecation
From: Kay Sievers @ 2011-08-02 23:38 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4E3873AC.3090103@linuxfromscratch.org>
On Wed, Aug 3, 2011 at 00:01, Matthew Burgess
<matthew@linuxfromscratch.org> wrote:
> So, Udev-173 added a log message warning us that 'udevadm trigger
> --typeúiled' is deprecated, which over in LFS we use in a 'udev_retry'
> bootscript in an attempt to retry failed events, for example those caused by
> slow device initialization.
What is a 'slow' device? RUN+= needs to be explicitly marked to 'fail'
events. What kind of rules do you exactly have there that tells RUN+to mark it as failed if needed?
> The ChangeLog fails to mention a preferred alternative mechanism for
> performing such event retries, or are such things not needed due to changes
> in the kernel?
>
> Any advice you can give would be appreciated.
Depends on what you need:
Real services subscribe to events and do device enumeration at
startup. They never really need hacks like 'failed' events.
Half-proper services trigger 'change' events when they are started up
to find all devices which are already there. This is a hack and not
recommended to use, but still better than hooking RUN+= stuff in, and
relying on --typeúiled.
There is no real point in time, where an init script should try once
again, just to see if has more luck than the on first run. Stuff that
needs things like that usually needs to be fixed to better integrate
with early boot, and it should no rely on udev to help papering over
such issues, and just blindly run all these events again.
If services still want that, they can implement this logic on their
own, the udev runtime directory is always writable.
Kay
^ permalink raw reply
* Re: udevadm: trigger --type=failed deprecation
From: Matthew Burgess @ 2011-08-03 9:09 UTC (permalink / raw)
To: linux-hotplug
On Wed, 3 Aug 2011 01:38:45 +0200, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Wed, Aug 3, 2011 at 00:01, Matthew Burgess
> <matthew@linuxfromscratch.org> wrote:
>> So, Udev-173 added a log message warning us that 'udevadm trigger
>> --typeúiled' is deprecated, which over in LFS we use in a 'udev_retry'
>> bootscript in an attempt to retry failed events, for example those
> caused by
>> slow device initialization.
>
> What is a 'slow' device? RUN+= needs to be explicitly marked to 'fail'
> events. What kind of rules do you exactly have there that tells RUN+> to mark it as failed if needed?
Good question. We try to stick as closely as possible to upstream's rules.
We only create 2 rules files in addition to those installed by your releases
which are:
--- Begin 55-lfs.rules ---
# /etc/udev/rules.d/55-lfs.rules: Rule definitions for LFS.
# Core kernel devices
# This causes the system clock to be set as soon as /dev/rtc becomes available.
SUBSYSTEM="rtc", ACTION="add", MODE="0644", RUN+="/etc/rc.d/init.d/setclock start"
KERNEL="rtc", ACTION="add", MODE="0644", RUN+="/etc/rc.d/init.d/setclock start"
# Comms devices
KERNEL="ippp[0-9]*", GROUP="dialout"
KERNEL="isdn[0-9]*", GROUP="dialout"
KERNEL="isdnctrl[0-9]*", GROUP="dialout"
KERNEL="dcbri[0-9]*", GROUP="dialout"
--- End 55-lfs.rules ---
and 70-persistent-net.rules which is generated by following the instructions
at http://www.linuxfromscratch.org/lfs/view/development/chapter07/network.html.
I have a suspicion that the rtc rule could fail if a user had /var as a separate
partition, and /dev/rtc was created before the /var partition had been mounted
(the setclock script calls out to hwclock, which requires /var/lib/hwclock/adjtime).
Our initscripts in question are S10udev and S40mountfs, so I guess this is
theoretically possible.
Do you agree with the above analysis, and if so what do I need to do to fix this?
I could just remove the RUN+= from the rtc rule, and have setclock be an initscript
that starts after S40mountfs. I think we used to have things configured this way, but
moved to the RUN+= method a while ago.
Aside from that issue, is there a way to ask udev to print all failed events, as opposed
to retrying them. As LFS is a fairly minimal system, I'm concerned that users may end up
creating or installing bootscripts that have similar issues, so having a way of printing
failed events would be a useful first step in diagnosing their issues.
Thanks,
Matt.
^ permalink raw reply
* Re: udevadm: trigger --type=failed deprecation
From: Kay Sievers @ 2011-08-04 20:55 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4E3873AC.3090103@linuxfromscratch.org>
On Wed, Aug 3, 2011 at 11:09, Matthew Burgess
<matthew@linuxfromscratch.org> wrote:
> On Wed, 3 Aug 2011 01:38:45 +0200, Kay Sievers <kay.sievers@vrfy.org> wrote:
>> On Wed, Aug 3, 2011 at 00:01, Matthew Burgess <matthew@linuxfromscratch.org> wrote:
> # This causes the system clock to be set as soon as /dev/rtc becomes available.
> SUBSYSTEM="rtc", ACTION="add", MODE="0644", RUN+="/etc/rc.d/init.d/setclock start"
> KERNEL="rtc", ACTION="add", MODE="0644", RUN+="/etc/rc.d/init.d/setclock start"
> I have a suspicion that the rtc rule could fail if a user had /var as a separate
> partition, and /dev/rtc was created before the /var partition had been mounted
> (the setclock script calls out to hwclock, which requires /var/lib/hwclock/adjtime).
> Our initscripts in question are S10udev and S40mountfs, so I guess this is
> theoretically possible.
>
> Do you agree with the above analysis, and if so what do I need to do to fix this?
That's all fragile. My take is that userspace should not fiddle with
the rtc clock at all. The kernel itself syncs properly with the rtc,
long before userspace even runs, which is the only sensible thing to
do, you don't want random jumps in system time. Userspace has no idea
what the correct time is until ntp runs anyway.
There is only one 'broken' setup that needs some adjusting, and that
is rtc in localtime. That should ideally be fixed by configuring
Windows to run the rtc in UTC, which works totally fine these days If
you really want to support that localtime crap, just adjust the
timezone in the kernel, but don't fiddle with broken adjtime, hwclock
or anything else. If anyone wants proper time, he needs ntp, not some
wild guessing by tools, that have no idea what the actual time really
is. What distros did here in the past is not convincing at all.
This is what systemd does:
http://cgit.freedesktop.org/systemd/commit/?idy48c4dfbea73ac21250b588089039aa17a90386
http://cgit.freedesktop.org/systemd/commit/?idÚ2617378523e007ec0c6efe99d0cebb2be994e1
and it will never touch the clock but supports rtc in localtime.
Running adjtime or hwclock and rtc in localtime will break all sorts
of setups like live-cds, and so on.
> I could just remove the RUN+= from the rtc rule, and have setclock be an initscript
> that starts after S40mountfs. Â I think we used to have things configured this way, but
> moved to the RUN+= method a while ago.
>
> Aside from that issue, is there a way to ask udev to print all failed events, as opposed
> to retrying them. Â As LFS is a fairly minimal system, I'm concerned that users may end up
> creating or installing bootscripts that have similar issues, so having a way of printing
> failed events would be a useful first step in diagnosing their issues.
No, the entire tracking of failed events will be removed. And no
events are marked as to-be-tracked by default, so there is nothing to
print usually.
If you have marked events, you can run 'trigger --typeúiled -n -v'
and it will print what it would do. But it is not used today for
anything useful, and don't rely on that in the future, it will go
away.
Kay
^ permalink raw reply
* Re: [PATCH] rules: input - fix detection of bluetooth hid devices in Xorg
From: Kay Sievers @ 2011-08-04 21:26 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1312275393-28519-1-git-send-email-thomas@archlinux.org>
On Tue, Aug 2, 2011 at 10:56, Thomas Bächler <thomas@archlinux.org> wrote:
> Commit c49df20758e0f22778cfc93b598f2929f4c86272 prevented udev from
> creating broken symlinks for bluetooth hid devices. Unfortunately,
> it also removed the ID_INPUT=1 and ID_INPUT_{KEY,MOUSE}=1 properties
> from those devices. Xorg relies on these properties for cold- and
> hotplugging of input devices.
I've moved the input_id call to the default rules.
Thanks,
Kay
^ permalink raw reply
* Support for microphone mute button on ThinkPad X220 et al
From: Thomas Hood @ 2011-08-07 17:02 UTC (permalink / raw)
To: linux-hotplug
On a ThinkPad X220 there is a microphone mute button which generates
ACPI event "ibm/hotkey HKEY 00000080 0000101b" which
corresponds to scancode 0x1a. By means of the appended patch to
the module-lenovo keymap file I map it to prog2 (and thus to
XF85Launch2 which I have configured to run a short amixer script).
There may be a better keyname to use, but I haven't seen anything
like "micmute". // Thomas Hood
$ diff -ur /lib/udev/keymaps/module-lenovo /etc/udev/keymaps/module-lenovo
--- /lib/udev/keymaps/module-lenovo 2011-04-07 14:43:35.000000000 +0200
+++ /etc/udev/keymaps/module-lenovo 2011-08-07 15:20:07.580033127 +0200
@@ -14,3 +14,4 @@
0x15 volumedown
0x16 mute
0x17 prog1 # ThinkPad/ThinkVantage button (high keycode: "vendor")
+0x1a prog2 # Microphone mute
^ permalink raw reply
* how stop udev renamed network interface eth0 to eth1
From: Carl Karsten @ 2011-08-07 19:24 UTC (permalink / raw)
To: linux-hotplug
I am trying to build a VM appliance, someone converted it to a
different vm engine (vmware / qemu) and now the networking is broke
because eth0 doesn't exist due to the new VM having a different mac.
I could add "set your mac to 123" but that's annoying.
I am guessing I can remove the reference to my mac, but I would rather
stop the behaviour so that the image can be booted in different
environments without eth0 being renamed.
I also want to do something similar with bootable USB drives, so I am
going to run into the same problem.
--
Carl K
^ permalink raw reply
* Re: how stop udev renamed network interface eth0 to eth1
From: Kay Sievers @ 2011-08-08 10:12 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CADmzSSh8S-+i6BjeQTWMtk5QAduouB4TmRLi5V=Bwu2+JoYO-A@mail.gmail.com>
On Sun, Aug 7, 2011 at 21:24, Carl Karsten <carl@personnelware.com> wrote:
> I am trying to build a VM appliance, Â someone converted it to a
> different vm engine (vmware / qemu) and now the networking is broke
> because eth0 doesn't exist due to the new VM having a different mac.
> I could add "set your mac to 123" but that's annoying.
>
> I am guessing I can remove the reference to my mac, but I would rather
> stop the behaviour so that the image can be booted in different
> environments without eth0 being renamed.
>
> I also want to do something similar with bootable USB drives, so I am
> going to run into the same problem.
You can 'mask' 75-persistent-net-generator.rules by placing an empty
file or a link to /dev/null in
/etc/udev/rules.d/75-persistent-net-generator.rules. This will disable
the file with the same name in /lib/udev, or on older udev versions,
just delete the rules file
/lib/udev/rules.d/75-persistent-net-generator.rules.
It is planned, that the logic that automatically create these
interface names will be removed from udev in the future. It turns out
to create more problems than it solves. We will require manual
configuration if specific network interface names are required.
Kay
^ permalink raw reply
* inequality operator semantics
From: Steffen Sledz @ 2011-08-11 12:25 UTC (permalink / raw)
To: linux-hotplug
Just a short question about the semantics of the != operator in conjunction with e.g. DRIVERS.
Does
DRIVERS!="xyz"
mean DRIVER for *all* parents is not equal to "xyz", or that there is *at least* one parent with this condition?
Does this semantics had changed over the time?
Regards,
Steffen Sledz
--
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sledz@dresearch-fe.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058
^ permalink raw reply
* Re: inequality operator semantics
From: Kay Sievers @ 2011-08-11 12:45 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4E43CA51.4020400@dresearch-fe.de>
On Thu, Aug 11, 2011 at 14:25, Steffen Sledz <sledz@dresearch-fe.de> wrote:
> Just a short question about the semantics of the != operator in conjunction with e.g. DRIVERS.
>
> Does
>
> Â DRIVERS!="xyz"
>
> mean DRIVER for *all* parents is not equal to "xyz", or that there is *at least* one parent with this condition?
One parent that doesn't match. DRIVERS!= not combined with more
matches makes not much sense. There should be in all cases a driver,
along the chain of parent devices, that does not match the string.
> Does this semantics had changed over the time?
Don't think so.
Kay
^ permalink raw reply
* keymap rule selection for non-DMI platforms
From: Paul Fox @ 2011-08-11 18:23 UTC (permalink / raw)
To: linux-hotplug
hi --
OLPC's latest laptop (the 1.75 model) is ARM-based. this means the
current keymap rule in rules.d/95-keymap.rules:
ENV{DMI_VENDOR}="OLPC", ATTR{[dmi/id]product_name}="XO", \
RUN+="keymap $name olpc-xo"
won't trigger -- there's no DMI information.
any thoughts on how non-PC hardware should be identifying itself
to udev? are there other examples of how this might be done?
i'm sure we could come up with something, based on examining some
other sysfs attribute, or perhaps running a command which identifies
our laptop(s), but i suspect this issue has come up before.
paul
=---------------------
paul fox, pgf@laptop.org
^ permalink raw reply
* Re: how to kow the active PCI slot name on the linux file system
From: Alan Stern @ 2011-08-12 16:02 UTC (permalink / raw)
To: linux-hotplug
On Fri, 12 Aug 2011, Sudarshan Jagadale wrote:
> *Hello sir,
>
> *Can you please let me know how to get the actual or active slot on linux
> file system? i think we call then as bus_name as well.*
Sometimes there is no PCI slot. Devices hosting a filesystem don't
have to use PCI.
However, you can always do something like this:
$ ls -l /sys/block/sda
lrwxrwxrwx. 1 root root 0 Aug 12 10:51 /sys/block/sda -> ../devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/
Replace "sda" in the ls command with the appropriate device name. The
PCI slot number can be found in the symlink information -- in this case
pci0000:00/0000:00:1f.2.
You can get the same information using udevadm:
$ udevadm info --query=symlink --name=/dev/sda
block/8:0 disk/by-id/ata-ST9250315AS_5VCD75ZW disk/by-id/scsi-SATA_ST9250315AS_5VCD75ZW disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 disk/by-id/wwn-0x5000c500218af855
> > can we have more than one active bus on single system?
Yes.
Alan Stern
^ permalink raw reply
* Some basic questions
From: Frank W. Miller @ 2011-08-12 23:59 UTC (permalink / raw)
To: linux-hotplug
Greetings,
I apologize if these questions seem trivial or are document somewhere
that I haven't searched as yet.
I'm essentially trying to build a new distro type. I currently have
kernel 2.6.39.2 booting from a USB stick. The kernel comes up using the
Intel framebuffer kms in its proper resolution and I have some basic
graphics routines that allow me to output as desired to the screen, and
NOTHING ELSE.
My next step is to get udev going. To that end, I've downloaded and
studied to some extent release 172. I'm using FC12 as my build machine
(e.g. gcc 4.4.2). This is what I think is supposed to happen, please
correct me if I'm wrong on any of this.
When I build udev, I do this:
configure --enable-static
This is to get the udev binaries to build without needing libraries.
Then:
make
I get this:
CC extras/input_id/input_id.o
extras/input_id/input_id.c: In function ‘test_key’:
extras/input_id/input_id.c:173: error: ‘BTN_TRIGGER_HAPPY’ undeclared
(first use in this function)
extras/input_id/input_id.c:173: error: (Each undeclared identifier is
reported only once
extras/input_id/input_id.c:173: error: for each function it appears in.)
make[2]: *** [extras/input_id/input_id.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
I did a search and came up with some results about kernel and udev
version mismatches but being the newbie to udev I am, I'm not sure I
understand what to do. So thats the first question?
Once I get the binaries built, I'll need to install them and the config
files in the proper places in my USB filesystem correct? I get this
output from the configure script:
udev 172
====
prefix: /usr
sysconfdir: ${prefix}/etc
sbindir: ${exec_prefix}/sbin
libdir: ${exec_prefix}/lib
rootlibdir: ${exec_prefix}/lib
libexecdir: ${exec_prefix}/libexec
datarootdir: ${prefix}/share
mandir: ${datarootdir}/man
includedir: ${prefix}/include
include_prefix: /usr/include
systemdsystemunitdir:
logging: yes
debug: no
selinux: no
compiler: gcc
cflags: -g -O2
ldflags:
rule_generator: yes
hwdb: yes
udev_acl: yes
gudev: yes
gintrospection: yes
keymap: yes
floppy: no
edd: no
usb.ids: /usr/share/hwdata/usb.ids
pci.ids: /usr/share/hwdata/pci.ids
firmware path: \"/lib/firmware/updates/\", \"/lib/firmware/\"
xsltproc: /usr/bin/xsltproc
gperf: /usr/bin/gperf
I'm assuming I'll need to install the binaries in /usr/sbin? And the
config files in /usr/share/hwdata?
I then need to start udevd on bootup correct?
OK, maybe I should see what the answers to these questions are before I
ask more silly things ;)
Thanks in advance for any assistance on this. I'd really like to keep
this as simple as possible. For example, its not clear to me what
"extras" are and how to turn them off if they are not needed.
Thanks,
FM
^ permalink raw reply
* Re: Some basic questions
From: Greg KH @ 2011-08-13 0:34 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1313193543.14425.15.camel@localhost>
On Fri, Aug 12, 2011 at 05:59:03PM -0600, Frank W. Miller wrote:
>
> Greetings,
>
> I apologize if these questions seem trivial or are document somewhere
> that I haven't searched as yet.
>
> I'm essentially trying to build a new distro type. I currently have
> kernel 2.6.39.2 booting from a USB stick. The kernel comes up using the
> Intel framebuffer kms in its proper resolution and I have some basic
> graphics routines that allow me to output as desired to the screen, and
> NOTHING ELSE.
As you are "building from scratch", why not take a look at the
description of udev in the Linux From Scratch distro? It should answer
all of these questions for you already.
Have you tried that?
greg k-h
^ permalink raw reply
* Re: Some basic questions
From: Frank W. Miller @ 2011-08-13 0:50 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1313193543.14425.15.camel@localhost>
Thanks for the reply. I did look at the LFS documentation. It really
just talks about installing their tarball and doesn't say much about
what's happening under the hood. I just looked at the LFS book, is
there some other LFS documentation that I should look at? I am working
"from scratch" but I think even more from scratch than LFS.
Thanks!
FM
On Fri, 2011-08-12 at 17:34 -0700, Greg KH wrote:
> On Fri, Aug 12, 2011 at 05:59:03PM -0600, Frank W. Miller wrote:
> >
> > Greetings,
> >
> > I apologize if these questions seem trivial or are document somewhere
> > that I haven't searched as yet.
> >
> > I'm essentially trying to build a new distro type. I currently have
> > kernel 2.6.39.2 booting from a USB stick. The kernel comes up using the
> > Intel framebuffer kms in its proper resolution and I have some basic
> > graphics routines that allow me to output as desired to the screen, and
> > NOTHING ELSE.
>
> As you are "building from scratch", why not take a look at the
> description of udev in the Linux From Scratch distro? It should answer
> all of these questions for you already.
>
> Have you tried that?
>
> greg k-h
^ permalink raw reply
* Re: Some basic questions
From: Allin Cottrell @ 2011-08-13 3:19 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1313193543.14425.15.camel@localhost>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1392 bytes --]
On Fri, 12 Aug 2011, Frank W. Miller wrote:
> My next step is to get udev going. To that end, I've downloaded and
> studied to some extent release 172. I'm using FC12 as my build machine
> (e.g. gcc 4.4.2). This is what I think is supposed to happen, please
> correct me if I'm wrong on any of this.
>
> When I build udev, I do this:
>
> configure --enable-static
>
> This is to get the udev binaries to build without needing libraries.
> Then:
>
> make
>
> I get this:
>
> CC extras/input_id/input_id.o
> extras/input_id/input_id.c: In function ‘test_key’:
> extras/input_id/input_id.c:173: error: ‘BTN_TRIGGER_HAPPY’ undeclared
Your FC12 kernel headers are too old for building udev 172. I
believe you'll need at least 2.6.34.
> Once I get the binaries built, I'll need to install them and the config
> files in the proper places in my USB filesystem correct?
Naturally. Though you can reorganize the directory structure if you
wish via options to ./configure.
> Thanks in advance for any assistance on this. I'd really like to keep
> this as simple as possible. For example, its not clear to me what
> "extras" are and how to turn them off if they are not needed.
./configure --disable-hwdb --disable-introspection \
--disable-keymap
(and so on). See ./configure --help and
http://www.linuxfromscratch.org/lfs/view/development/chapter06/udev.html
Allin Cottrell
^ permalink raw reply
* Re: Some basic questions
From: Frank W. Miller @ 2011-08-13 3:33 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1313193543.14425.15.camel@localhost>
Thanks Allin! Very helpful, or at least, I'll let you know... ;)
One question, I have the 2.6.39.2 kernel tree that I'm building for my
little project. How do I point the udev build at the kernel headers in
that tree, e.g.:
/home/fwmiller/roadrunner/build/linux/include
where "linux" in this path is actually a sym link to a directory called
linux-2.6.29.2 in the same build/ directory?
Also, can I just do all the --disable-* options to configure? Is that
the base implementation?
Thanks,
FM
On Fri, 2011-08-12 at 23:19 -0400, Allin Cottrell wrote:
> On Fri, 12 Aug 2011, Frank W. Miller wrote:
>
> > My next step is to get udev going. To that end, I've downloaded and
> > studied to some extent release 172. I'm using FC12 as my build machine
> > (e.g. gcc 4.4.2). This is what I think is supposed to happen, please
> > correct me if I'm wrong on any of this.
> >
> > When I build udev, I do this:
> >
> > configure --enable-static
> >
> > This is to get the udev binaries to build without needing libraries.
> > Then:
> >
> > make
> >
> > I get this:
> >
> > CC extras/input_id/input_id.o
> > extras/input_id/input_id.c: In function ‘test_key’:
> > extras/input_id/input_id.c:173: error: ‘BTN_TRIGGER_HAPPY’ undeclared
>
> Your FC12 kernel headers are too old for building udev 172. I
> believe you'll need at least 2.6.34.
>
> > Once I get the binaries built, I'll need to install them and the config
> > files in the proper places in my USB filesystem correct?
>
> Naturally. Though you can reorganize the directory structure if you
> wish via options to ./configure.
>
> > Thanks in advance for any assistance on this. I'd really like to keep
> > this as simple as possible. For example, its not clear to me what
> > "extras" are and how to turn them off if they are not needed.
>
> ./configure --disable-hwdb --disable-introspection \
> --disable-keymap
>
> (and so on). See ./configure --help and
> http://www.linuxfromscratch.org/lfs/view/development/chapter06/udev.html
>
> Allin Cottrell
^ permalink raw reply
* Re: Some basic questions
From: John Lumby @ 2011-08-13 18:20 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1313193543.14425.15.camel@localhost>
To install kernel headers from your own kernel tree:
. first build them -
# assuming current working dir is the top of your kernel build
INSTALL_HDR_PATH=$PWD/usr make headers_install
should create a subdirectory path usr/include containing directories
such as linux video sound asm asm-generic and others
. then cd to /usr/include and, for each directory in
<kernel>/usr/include, first rename the one in /usr/include, then copy
(or symlink it if it will always be accessible) the one under the kernel
tree.
On 08/12/11 23:33, Frank W. Miller wrote:
> Thanks Allin! Very helpful, or at least, I'll let you know... ;)
>
> One question, I have the 2.6.39.2 kernel tree that I'm building for my
> little project. How do I point the udev build at the kernel headers in
> that tree, e.g.:
>
> /home/fwmiller/roadrunner/build/linux/include
>
> where "linux" in this path is actually a sym link to a directory called
> linux-2.6.29.2 in the same build/ directory?
>
> Also, can I just do all the --disable-* options to configure? Is that
> the base implementation?
>
> Thanks,
> FM
>
>
> On Fri, 2011-08-12 at 23:19 -0400, Allin Cottrell wrote:
>> On Fri, 12 Aug 2011, Frank W. Miller wrote:
>>
>>> My next step is to get udev going. To that end, I've downloaded and
>>> studied to some extent release 172. I'm using FC12 as my build machine
>>> (e.g. gcc 4.4.2). This is what I think is supposed to happen, please
>>> correct me if I'm wrong on any of this.
>>>
>>> When I build udev, I do this:
>>>
>>> configure --enable-static
>>>
>>> This is to get the udev binaries to build without needing libraries.
>>> Then:
>>>
>>> make
>>>
>>> I get this:
>>>
>>> CC extras/input_id/input_id.o
>>> extras/input_id/input_id.c: In function ‘test_key’:
>>> extras/input_id/input_id.c:173: error: ‘BTN_TRIGGER_HAPPY’ undeclared
>> Your FC12 kernel headers are too old for building udev 172. I
>> believe you'll need at least 2.6.34.
>>
>>> Once I get the binaries built, I'll need to install them and the config
>>> files in the proper places in my USB filesystem correct?
>> Naturally. Though you can reorganize the directory structure if you
>> wish via options to ./configure.
>>
>>> Thanks in advance for any assistance on this. I'd really like to keep
>>> this as simple as possible. For example, its not clear to me what
>>> "extras" are and how to turn them off if they are not needed.
>> ./configure --disable-hwdb --disable-introspection \
>> --disable-keymap
>>
>> (and so on). See ./configure --help and
>> http://www.linuxfromscratch.org/lfs/view/development/chapter06/udev.html
>>
>> Allin Cottrell
>
> --
> 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: Some basic questions
From: Frank W. Miller @ 2011-08-14 3:25 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1313193543.14425.15.camel@localhost>
Thanks for the reply.
Correct me if I'm wrong but doesn't this essentially replace the kernel
header files in usr/include/ for the build machine with pointers to the
kernel headers for my target kernel? I'm not sure this is a good way to
go about this. Am I missing something? It would be better if there was
some compile option for udev that pointed it at the desired kernel
header files, wherever they might be?
Thanks,
FM
On Sat, 2011-08-13 at 14:20 -0400, John Lumby wrote:
> To install kernel headers from your own kernel tree:
>
> . first build them -
> # assuming current working dir is the top of your kernel build
> INSTALL_HDR_PATH=$PWD/usr make headers_install
> should create a subdirectory path usr/include containing directories
> such as linux video sound asm asm-generic and others
>
> . then cd to /usr/include and, for each directory in
> <kernel>/usr/include, first rename the one in /usr/include, then copy
> (or symlink it if it will always be accessible) the one under the kernel
> tree.
>
> On 08/12/11 23:33, Frank W. Miller wrote:
> > Thanks Allin! Very helpful, or at least, I'll let you know... ;)
> >
> > One question, I have the 2.6.39.2 kernel tree that I'm building for my
> > little project. How do I point the udev build at the kernel headers in
> > that tree, e.g.:
> >
> > /home/fwmiller/roadrunner/build/linux/include
> >
> > where "linux" in this path is actually a sym link to a directory called
> > linux-2.6.29.2 in the same build/ directory?
> >
> > Also, can I just do all the --disable-* options to configure? Is that
> > the base implementation?
> >
> > Thanks,
> > FM
> >
> >
> > On Fri, 2011-08-12 at 23:19 -0400, Allin Cottrell wrote:
> >> On Fri, 12 Aug 2011, Frank W. Miller wrote:
> >>
> >>> My next step is to get udev going. To that end, I've downloaded and
> >>> studied to some extent release 172. I'm using FC12 as my build machine
> >>> (e.g. gcc 4.4.2). This is what I think is supposed to happen, please
> >>> correct me if I'm wrong on any of this.
> >>>
> >>> When I build udev, I do this:
> >>>
> >>> configure --enable-static
> >>>
> >>> This is to get the udev binaries to build without needing libraries.
> >>> Then:
> >>>
> >>> make
> >>>
> >>> I get this:
> >>>
> >>> CC extras/input_id/input_id.o
> >>> extras/input_id/input_id.c: In function ‘test_key’:
> >>> extras/input_id/input_id.c:173: error: ‘BTN_TRIGGER_HAPPY’ undeclared
> >> Your FC12 kernel headers are too old for building udev 172. I
> >> believe you'll need at least 2.6.34.
> >>
> >>> Once I get the binaries built, I'll need to install them and the config
> >>> files in the proper places in my USB filesystem correct?
> >> Naturally. Though you can reorganize the directory structure if you
> >> wish via options to ./configure.
> >>
> >>> Thanks in advance for any assistance on this. I'd really like to keep
> >>> this as simple as possible. For example, its not clear to me what
> >>> "extras" are and how to turn them off if they are not needed.
> >> ./configure --disable-hwdb --disable-introspection \
> >> --disable-keymap
> >>
> >> (and so on). See ./configure --help and
> >> http://www.linuxfromscratch.org/lfs/view/development/chapter06/udev.html
> >>
> >> Allin Cottrell
> >
> > --
> > 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: Some basic questions
From: Frank W. Miller @ 2011-08-14 3:33 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1313193543.14425.15.camel@localhost>
OK, I got the -145 version to build with pretty much everything
disabled, so I think just the base implementation. The only binaries
that are showing up in the udev-145/udev directory are:
test-udev udevadm udevd
Now I'm going to copy these binaries to the /bin directory of my USB
filesystem and try to start udevd.
I don't want to use install, just cp, which means I'm not going to use
make install from the distro. I'll need to copy some rules I suppose,
and there are a number of files in the rules directory. I'm guessing I
don't need the rules from the distro directories. If I copy the rules
from the rules.d directory only, will that be enough?
Thanks,
FM
On Sat, 2011-08-13 at 14:20 -0400, John Lumby wrote:
> To install kernel headers from your own kernel tree:
>
> . first build them -
> # assuming current working dir is the top of your kernel build
> INSTALL_HDR_PATH=$PWD/usr make headers_install
> should create a subdirectory path usr/include containing directories
> such as linux video sound asm asm-generic and others
>
> . then cd to /usr/include and, for each directory in
> <kernel>/usr/include, first rename the one in /usr/include, then copy
> (or symlink it if it will always be accessible) the one under the kernel
> tree.
>
> On 08/12/11 23:33, Frank W. Miller wrote:
> > Thanks Allin! Very helpful, or at least, I'll let you know... ;)
> >
> > One question, I have the 2.6.39.2 kernel tree that I'm building for my
> > little project. How do I point the udev build at the kernel headers in
> > that tree, e.g.:
> >
> > /home/fwmiller/roadrunner/build/linux/include
> >
> > where "linux" in this path is actually a sym link to a directory called
> > linux-2.6.29.2 in the same build/ directory?
> >
> > Also, can I just do all the --disable-* options to configure? Is that
> > the base implementation?
> >
> > Thanks,
> > FM
> >
> >
> > On Fri, 2011-08-12 at 23:19 -0400, Allin Cottrell wrote:
> >> On Fri, 12 Aug 2011, Frank W. Miller wrote:
> >>
> >>> My next step is to get udev going. To that end, I've downloaded and
> >>> studied to some extent release 172. I'm using FC12 as my build machine
> >>> (e.g. gcc 4.4.2). This is what I think is supposed to happen, please
> >>> correct me if I'm wrong on any of this.
> >>>
> >>> When I build udev, I do this:
> >>>
> >>> configure --enable-static
> >>>
> >>> This is to get the udev binaries to build without needing libraries.
> >>> Then:
> >>>
> >>> make
> >>>
> >>> I get this:
> >>>
> >>> CC extras/input_id/input_id.o
> >>> extras/input_id/input_id.c: In function ‘test_key’:
> >>> extras/input_id/input_id.c:173: error: ‘BTN_TRIGGER_HAPPY’ undeclared
> >> Your FC12 kernel headers are too old for building udev 172. I
> >> believe you'll need at least 2.6.34.
> >>
> >>> Once I get the binaries built, I'll need to install them and the config
> >>> files in the proper places in my USB filesystem correct?
> >> Naturally. Though you can reorganize the directory structure if you
> >> wish via options to ./configure.
> >>
> >>> Thanks in advance for any assistance on this. I'd really like to keep
> >>> this as simple as possible. For example, its not clear to me what
> >>> "extras" are and how to turn them off if they are not needed.
> >> ./configure --disable-hwdb --disable-introspection \
> >> --disable-keymap
> >>
> >> (and so on). See ./configure --help and
> >> http://www.linuxfromscratch.org/lfs/view/development/chapter06/udev.html
> >>
> >> Allin Cottrell
> >
> > --
> > 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: Some basic questions
From: Allin Cottrell @ 2011-08-14 6:44 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1313193543.14425.15.camel@localhost>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3920 bytes --]
On Sat, 13 Aug 2011, Frank W. Miller wrote:
> Correct me if I'm wrong but doesn't this essentially replace the kernel
> header files in usr/include/ for the build machine with pointers to the
> kernel headers for my target kernel? I'm not sure this is a good way to
> go about this.
I think this thread is wearing out its welcome, since it's not
particularly related to udev. But briefly: Yes, John Lumby's
suggestion involves (temporarily) replacing the content of
/usr/include/linux and friends on your build host with updated
kernel headers. That's the option that occurred to me too. If you
have a better idea, fine, but don't expect to find a simple
./configure option in udev to do something as non-standard as what
you're attempting.
Allin Cottrell
> On Sat, 2011-08-13 at 14:20 -0400, John Lumby wrote:
>> To install kernel headers from your own kernel tree:
>>
>> . first build them -
>> # assuming current working dir is the top of your kernel build
>> INSTALL_HDR_PATH=$PWD/usr make headers_install
>> should create a subdirectory path usr/include containing directories
>> such as linux video sound asm asm-generic and others
>>
>> . then cd to /usr/include and, for each directory in
>> <kernel>/usr/include, first rename the one in /usr/include, then copy
>> (or symlink it if it will always be accessible) the one under the kernel
>> tree.
>>
>> On 08/12/11 23:33, Frank W. Miller wrote:
>>> Thanks Allin! Very helpful, or at least, I'll let you know... ;)
>>>
>>> One question, I have the 2.6.39.2 kernel tree that I'm building for my
>>> little project. How do I point the udev build at the kernel headers in
>>> that tree, e.g.:
>>>
>>> /home/fwmiller/roadrunner/build/linux/include
>>>
>>> where "linux" in this path is actually a sym link to a directory called
>>> linux-2.6.29.2 in the same build/ directory?
>>>
>>> Also, can I just do all the --disable-* options to configure? Is that
>>> the base implementation?
>>>
>>> Thanks,
>>> FM
>>>
>>>
>>> On Fri, 2011-08-12 at 23:19 -0400, Allin Cottrell wrote:
>>>> On Fri, 12 Aug 2011, Frank W. Miller wrote:
>>>>
>>>>> My next step is to get udev going. To that end, I've downloaded and
>>>>> studied to some extent release 172. I'm using FC12 as my build machine
>>>>> (e.g. gcc 4.4.2). This is what I think is supposed to happen, please
>>>>> correct me if I'm wrong on any of this.
>>>>>
>>>>> When I build udev, I do this:
>>>>>
>>>>> configure --enable-static
>>>>>
>>>>> This is to get the udev binaries to build without needing libraries.
>>>>> Then:
>>>>>
>>>>> make
>>>>>
>>>>> I get this:
>>>>>
>>>>> CC extras/input_id/input_id.o
>>>>> extras/input_id/input_id.c: In function ‘test_key’:
>>>>> extras/input_id/input_id.c:173: error: ‘BTN_TRIGGER_HAPPY’ undeclared
>>>> Your FC12 kernel headers are too old for building udev 172. I
>>>> believe you'll need at least 2.6.34.
>>>>
>>>>> Once I get the binaries built, I'll need to install them and the config
>>>>> files in the proper places in my USB filesystem correct?
>>>> Naturally. Though you can reorganize the directory structure if you
>>>> wish via options to ./configure.
>>>>
>>>>> Thanks in advance for any assistance on this. I'd really like to keep
>>>>> this as simple as possible. For example, its not clear to me what
>>>>> "extras" are and how to turn them off if they are not needed.
>>>> ./configure --disable-hwdb --disable-introspection \
>>>> --disable-keymap
>>>>
>>>> (and so on). See ./configure --help and
>>>> http://www.linuxfromscratch.org/lfs/view/development/chapter06/udev.html
>>>>
>>>> Allin Cottrell
>>>
>>> --
>>> 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
>>>
>>>
>>
>
>
>
--
Allin Cottrell
Department of Economics
Wake Forest University
^ permalink raw reply
* When does the kernel emits add events?
From: Steffen Sledz @ 2011-08-15 11:09 UTC (permalink / raw)
To: linux-hotplug
Hi udev-Team,
just a short question for my understanding. When does the kernel emits add events for block devices?
With 'udevadm monitor' i've seen something that is confusing me:
1. I've an unmounted vfat partition. After running 'fsck.vfat -a /dev/sdb1' an add event occurs, but not after 'fsck.vfat -V /dev/sdb1'?
2. We have an embedded device based on an OXE810 platform. When loading the related kernel module the kernel emits an add event for the disk itself (e.g. /dev/sdb) and for all partitions on it (/dev/sdb1, ...). But then the kernel continues to send add events for the disk itself until *all* partitions on it are mounted. Is this an intended behaviour? Or a bug inside the kernel module?
Regards,
Steffen Sledz
--
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sledz@dresearch-fe.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058
^ permalink raw reply
* Input devices issue with kernel 2.6.37
From: Yegor Yefremov @ 2011-08-15 12:49 UTC (permalink / raw)
To: linux-hotplug
I have an ARM based SoC (TI am3517). At the time it has 3 input
devices: touchscreen (i2c), mouse and keyboard (USB). If I start
Debian 6.0 with 2.6.32 kernel I get all three devices listed under
/dev/input/by-path so that I can use all of them in X::
platform-i2c_omap.2-event -> ../event0
platform-musb_hdrc-usb-0:1.3.3:1.0-event-kbd -> ../event1
platform-musb_hdrc-usb-0:1.3.4:1.0-event-mouse -> ../event2
If I take kernel 2.6.37 with the same Debian image I get only
touchscreen listed. It looks like if
/lib/udev/rules.d/60-persistent-input.rules would not apply during
/dev population. But if I execute:
udevadm test --actiond /sys/class/input/event1
udevadm test --actiond /sys/class/input/event2
I get all devices properly registered, so that after restarting xdm I
can use all input devices.
The same problem I have with Buildroot und udev 173.
Any idea what could be wrong and why devices would not get registered
automatically at startup with 2.6.37?
Yegor
^ 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