* Re: Inhibiting plug and play
From: Greg KH @ 2013-06-18 17:55 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <51C09CA5.6020902@ubuntu.com>
On Tue, Jun 18, 2013 at 01:45:09PM -0400, Phillip Susi wrote:
> Various tools, but most notably partitioners, manipulate disks in such
> a way that they need to prevent the rest of the system from racing
> with them while they are in the middle of manipulating the disk.
> Presently this is done with a hodge podge of hacks that involve
> running some script or executable to temporarily hold off on some
> aspects ( typically only auto mounting ) of plug and play processing.
> Which one depends on whether you are running hal, udisks, udisks2, or
> systemd.
>
> There really needs to be a proper way at a lower level, either udev,
> or maybe in the kernel, to inhibit processing events until the tool
> changing the device has finished completely. The question is, should
> this be in the kernel, or in udev, and what should the interface be?
What events are you wishing to inhibit? And who is in control of them?
thanks,
greg k-h
^ permalink raw reply
* Re: Inhibiting plug and play
From: David Zeuthen @ 2013-06-18 18:03 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <51C09CA5.6020902@ubuntu.com>
Hi,
On Tue, Jun 18, 2013 at 10:45 AM, Phillip Susi <psusi@ubuntu.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Various tools, but most notably partitioners, manipulate disks in such
> a way that they need to prevent the rest of the system from racing
> with them while they are in the middle of manipulating the disk.
> Presently this is done with a hodge podge of hacks that involve
> running some script or executable to temporarily hold off on some
> aspects ( typically only auto mounting ) of plug and play processing.
> Which one depends on whether you are running hal, udisks, udisks2, or
> systemd.
>
> There really needs to be a proper way at a lower level, either udev,
> or maybe in the kernel, to inhibit processing events until the tool
> changing the device has finished completely. The question is, should
> this be in the kernel, or in udev, and what should the interface be?
When I was younger I used to think things like this was a good idea
and, in fact, did a lot of work to add complex interfaces for this in
the various components you mention. These interfaces didn't really
work well, someone would always complain that this or that edge-case
didn't work. Or some other desktop environment ended up not using the
interfaces. Or some kernel hacker running twm (with "carefully"
selected bits of GNOME or KDE to get automounting) ran into problems.
It was awful. Just awful.
What _did_ turn out to work really well - and what GNOME is using
today and have been for the last couple of years - is that the
should_automount flag [1] is set only if, and only if, the device the
volume is on, has been added within the last five seconds [2]. It's
incredibly simple (and low-tech). And judging from bug reports, it
works really well.
So please don't add complicated inhibit interfaces. They're probably
not going to work and probably not everybody is going to use them.
Thanks,
David
[1] : as used in GNOME and probably things like Ubuntu Unity and XFCE
as well, see
https://developer.gnome.org/gio/2.35/GVolume.html#g-volume-should-automount
[2] : this is where should_automount is being set
https://git.gnome.org/browse/gvfs/tree/monitor/udisks2/gvfsudisks2volume.c?id=1.17.2#n377
^ permalink raw reply
* Re: Inhibiting plug and play
From: Phillip Susi @ 2013-06-18 18:40 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <51C09CA5.6020902@ubuntu.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 6/18/2013 2:03 PM, David Zeuthen wrote:
> When I was younger I used to think things like this was a good
> idea and, in fact, did a lot of work to add complex interfaces for
> this in the various components you mention. These interfaces didn't
> really work well, someone would always complain that this or that
> edge-case didn't work. Or some other desktop environment ended up
> not using the interfaces. Or some kernel hacker running twm (with
> "carefully" selected bits of GNOME or KDE to get automounting) ran
> into problems. It was awful. Just awful.
I can't really extract any meaning from this without knowledge of what
was tried and what problems it caused. I also don't see why it can't
be something as simple as opening the device with O_EXCL.
> What _did_ turn out to work really well - and what GNOME is using
> today and have been for the last couple of years - is that the
> should_automount flag [1] is set only if, and only if, the device
> the volume is on, has been added within the last five seconds [2].
> It's incredibly simple (and low-tech). And judging from bug
> reports, it works really well.
I don't follow. You mean udisks delays auto mounting by 5 seconds?
That's not going to help if, for instance, you use gparted to move a
partition to the right. It first enlarges the partition, which
generates a remove/add event, then starts moving data. 5 seconds
later udisks tries to mount the partition, which very well may succeed
with horrible consequences.
The problem also goes beyond udisks and auto mounting, which is why I
say it really needs done either at the udev or kernel level.
For instance, a udev script may identify the new volume as part of a
raid ( leftover metadata ) and try to attach mdadm to it, at the same
time you're running mkfs. I'm also pretty sure that I have seen the
mdadm udev script race with mdadm itself while you are trying to
create a new raid volume.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJRwKm1AAoJEJrBOlT6nu75ZqMIAM/EUrDIQQn6O5dlCMAOwGSm
h/D5Pbb6amPmDiFELooQgb+BMuUw9bAYwdcukMWZB1MqBTMBOtwLGTeI9TEeWH4y
y2c753e2JBgkPnzY6iFkfPXDvsTEIZSHsx00YLZt06aDL5k/Fmt5eN+mD5pSiC2T
l1qSdhtEw2IseWVuXOjwjy5K00vIDDAaLG1o2Ff135gNx/wUaOK8nL0vSUZhDK96
V3WS4LGKJDlrGESeAyDELfuExrvtmASgohlpUEy2IK9R9lpNicudStPDZFp+dzCA
wv/D1HXkZiIRS74u6Nl3BLtWWd9rPF0ub2OXKCwURYXl2ULE7bPwaiJIdtYp/zo=BWbx
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: Inhibiting plug and play
From: David Zeuthen @ 2013-06-18 18:59 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <51C09CA5.6020902@ubuntu.com>
Hi,
On Tue, Jun 18, 2013 at 11:40 AM, Phillip Susi <psusi@ubuntu.com> wrote:
> I don't follow. You mean udisks delays auto mounting by 5 seconds?
No, it works like this: if you plug in the device, then - for example
- /dev/sdb is added and then /dev/sdb1 is added and /dev/sdb1 is
deemed to contain a FAT filesystem that could be mounted. The trick is
to only decide to automount /dev/sdb1 if /dev/sdb appeared "recently"
- e.g. within the last five seconds.
> The problem also goes beyond udisks and auto mounting, which is why I
> say it really needs done either at the udev or kernel level.
Disagree. We don't want this level of complexity in either the kernel
or udev. Why? Because it can be solved by the "policy manager" (such
as the GNOME auto-mounter described above or the RAID auto-assembly
machinery described below) do the right thing - e.g. be extremely
careful before it's doing something (such as mounting it or assembling
several of them to a RAID or VG) to a device.
> For instance, a udev script may identify the new volume as part of a
> raid ( leftover metadata ) and try to attach mdadm to it, at the same
> time you're running mkfs. I'm also pretty sure that I have seen the
> mdadm udev script race with mdadm itself while you are trying to
> create a new raid volume.
This is indeed a problem with the RAID auto-assembler being overeager
and not careful enough. In fact, I routinely just delete udev rules
for RAID and LVM assembly because they keep doing the wrong thing.
The solution here is not to add complex machinery and frameworks and
abstractions. The solution is simply to fix the underlying problems,
not paper over them.
David
^ permalink raw reply
* media-player-info 18 release
From: Martin Pitt @ 2013-07-05 5:04 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 869 bytes --]
Hey all,
these days, most modern media players fortunately use MTP, but over
the last few months there have still been some additions and
adjustments for older players, so time to push out a new release of
media-player-info:
http://www.freedesktop.org/software/media-player-info/media-player-info-18.tar.gz
sha256: 21f186714d8c90e9a78c861cfdbfc1c9ae7eada7b80152a82bec685e7b7fc565
Changes:
Dan Williams (1):
Add HP Veer
Markus Ottensmann (1):
Add Archos 5 Internet Tablet
Martin Pitt (3):
Add ZTE Score
Add LG Optimus One P500
Drop newer kindles
Pavol Babincak (1):
Fix playlist path for Sony Ericsson Xperia mini pro
Thanks to all contributors!
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
* Logitech iTouch USB keyboard scan codes
From: Albrecht Kolthoff @ 2013-07-15 21:15 UTC (permalink / raw)
To: linux-hotplug
Hi,
I noticed that Götz Christ had submitted a report on 23 Feb 2013 about broken scan codes with his Logitech keyboard and a related bug report on 2013-03-07 with some additional discussion here:
http://comments.gmane.org/gmane.linux.hotplug.devel/17650
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1152377
According to Götz' report he has a Logitech "iTouch Internet Navigator" keyboard. I got aware of his reports because I also have a Logitech Internet Navigator keyboard and his reports were pretty helpful when setting up the extra keys of my keyboard to be used with an Opensuse 12.3 64bit installation, KDE 4.10.5.
Soon I had to realize that Götz obviously has a different keyboard than me. While for instance he has finance and shopping keys I do have a shopping key but no finance (how ever that may be interpreted). Most importantly, his scan codes are others than mine: What is shopping for him means chat for me etc. Logitech obviously has produced a lot of different keyboards over the years where some of them had been named identically or very similar, but the actual keys and the scancodes are different. Some listings of those vintage keyboards:
http://www.logitech.com/de-de/support/keyboards?legacy=1
http://keytouch.sourceforge.net/keyboards_logitech.php
But this may lead to some confusion or erroneous bug reporting when for udev reasons only a sparse naming like Logitech iTouch (USB) is used (that's a whole extended family, not just a single person, so to say) or when the relevant udev rule just has a string like "Logitech USB Keyboard" for recognition of the actual keyboard. Maybe it would be a good idea to include more info for recignition; USB keyboards may be identified very easily by their vendor and product id which lsusb is happy to provide.
Anyway, here are my scancodes for this keyboard "Logitech Internet Navigator" (Logitech's product number Y-BF37), VID 046d, PID c309. Product web page:
http://www.logitech.com/de-de/support/3373
I added this line to my 95-keymap.rules:
ENV{ID_VENDOR}="Logitech*", ATTRS{idProduct}="c309", RUN+="keymap $name logitech-int-nav-046d-c309-usb-complete"
.. and I'm happy to report that this works very well. I have made two actual keymap files: one verbose file (logitech-int-nav-046d-c309-usb-complete) with all the extra keys of this keyboard (even if they had been recognized before or are practically not usable) for research and reference purposes and one terse file with just the missing or broken keys (logitech-int-nav-046d-c309-usb). Make use of this as you like.
Cheers
AK
Keymaps:
logitech-int-nav-046d-c309-usb
---------------------------------------------------------------------------------------------------------------
# Keyboard: Logitech Internet Navigator (Y-BF37) (USB)
# http://www.logitech.com/de-de/support/3373
# key names in comments = German labels as printed on the keyboard (where available)
#
0x90001 chat # Messenger/SMS
0x90002 camera # Webkamera
0x90003 prog1 # iTouch
0x90004 shop # Einkaufen
# F key functions: with F-lock key ("F-Taste") switched OFF
0xc0201 new # New (F1). Not supported by Qt.
0xc0289 reply # Reply mail (F2)
0xc028b forwardmail # Forward mail (F3)
0xc028c send # Send (F4)
0xc021a undo # Undo (F5). Not supported by Qt.
0xc0279 redo # Redo (F6). Not supported by Qt.
0xc0208 print # Print (F7)
0xc0207 save # Save (F8)
0xc0194 file # My Computer (F9)
0xc01a7 documents # My Documents (F10)
0xc01b6 images # My Pictures (F11) ??
0xc01b7 sound # My Music (F12) ??
---------------------------------------------------------------------------------------------------------------
logitech-int-nav-046d-c309-usb-complete
---------------------------------------------------------------------------------------------------------------
# Keyboard: Logitech Internet Navigator (Y-BF37) (USB)
# VID 046d, PID c309
# http://www.logitech.com/de-de/support/3373
# complete set of extra keys (including those already being recognized by current keyboard driver)
# keys broken/missing previously marked as #* in comment
# key names in comments = German labels as printed on the keyboard (where available); unlocked F-keys have symbols printed on the key
0xc018a mail # E-Mail
0x90001 chat #* Messenger/SMS
0x90002 camera #* Webkamera
0xC00B6 previoussong # previous song
0xC00B5 nextsong # next song
0xC0183 media # Media
0xC00EA volumedown # volume down
0xC00E9 volumeup # volume up
0xC00E2 mute # mute
0xC00CD playpause # play / pause
0xC00B7 stopcd # stop
0x90003 prog1 #* iTouch
0xc0221 search # Suchen
0x90004 shop #* Einkaufen
0xc022a bookmarks # Favoriten
0xc0223 homepage # Startseite
0x10082 sleep # User
# F key functions: with F-lock key ("F-Taste") switched OFF
0xc0201 new #* New (F1). Not supported by Qt.
0xc0289 reply #* Reply mail (F2)
0xc028b forwardmail #* Forward mail (F3)
0xc028c send #* Send (F4)
0xc021a undo #* Undo (F5). Not supported by Qt.
0xc0279 redo #* Redo (F6). Not supported by Qt.
0xc0208 print #* Print (F7)
0xc0207 save #* Save (F8)
0xc0194 file #* My Computer (F9)
0xc01a7 documents #* My Documents (F10)
0xc01b6 images #* My Pictures (F11) ??
0xc01b7 sound #* My Music (F12) ??
# scroll wheel + buttons at left side ("iNav" group)
#0x90006 105 #* wheelclick. Not supported by Qt.
0xc0225 forward # forward
0xc0224 back # back
---------------------------------------------------------------------------------------------------------------
^ permalink raw reply
* Re: [systemd-devel] Inhibiting plug and play
From: Lennart Poettering @ 2013-07-16 17:23 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <51C09CA5.6020902@ubuntu.com>
On Tue, 18.06.13 13:45, Phillip Susi (psusi@ubuntu.com) wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Various tools, but most notably partitioners, manipulate disks in such
> a way that they need to prevent the rest of the system from racing
> with them while they are in the middle of manipulating the disk.
> Presently this is done with a hodge podge of hacks that involve
> running some script or executable to temporarily hold off on some
> aspects ( typically only auto mounting ) of plug and play processing.
> Which one depends on whether you are running hal, udisks, udisks2, or
> systemd.
>
> There really needs to be a proper way at a lower level, either udev,
> or maybe in the kernel, to inhibit processing events until the tool
> changing the device has finished completely. The question is, should
> this be in the kernel, or in udev, and what should the interface be?
So, Kay suggested we should use BSD file locks for this. i.e. all tools
which want to turn off events for a device would take one on that
specific device fd. As long as it is taken udev would not generate
events. As soon as the BSD lock is released again it would recheck the
device.
To me this sounds like a pretty clean thing to do. Locks usually suck,
but for this purpose they appear to do exactly what they should, and
most of the problematic things with them don't apply in this specific
case.
Doing things way would be quite robust, as we have clean synchronization
and the kernel will release the locks automatically when the owner dies.
Opinions?
Lennart
--
Lennart Poettering - Red Hat, Inc.
^ permalink raw reply
* Re: [systemd-devel] Inhibiting plug and play
From: Phillip Susi @ 2013-07-16 17:35 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <51C09CA5.6020902@ubuntu.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 7/16/2013 1:23 PM, Lennart Poettering wrote:
> So, Kay suggested we should use BSD file locks for this. i.e. all
> tools which want to turn off events for a device would take one on
> that specific device fd. As long as it is taken udev would not
> generate events. As soon as the BSD lock is released again it would
> recheck the device.
>
> To me this sounds like a pretty clean thing to do. Locks usually
> suck, but for this purpose they appear to do exactly what they
> should, and most of the problematic things with them don't apply in
> this specific case.
>
> Doing things way would be quite robust, as we have clean
> synchronization and the kernel will release the locks automatically
> when the owner dies.
>
> Opinions?
Sounds like it might work.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJR5YRIAAoJEJrBOlT6nu75VLUH/3X7fHhppdUCw5WFt1PpitKK
O9tuPcs9RZBWhaQ+Ol9Sp82qnEG+mqmmCLAc3z35Zj1PpNRKTLYrGWbmqlbkPsks
ZU4UZTnr9i03uDRuQfSMtUsTpnriBILT8tfyPkH7XYulGBligI3D3Sdk6LWD6Y6J
tm0SnVlOk/tm4FasWFT4KlFp/obRuL8yUBnZvgYqyTblCeVTX2013xEtXN/TG9pH
4iNSgRTQ98K/EdZQP1yz2j/LSLn0MFQTCPU4YuDVmds9nU2iZAllaY+sSMQCSkm6
Ks4giagyhKsBw8oy3AAN5f/VEvpriuAAVrLxNNaTzTAfR//J7gHwzB40ploB3oo=+o3u
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: media-player-info 18 release
From: Tom Gundersen @ 2013-07-18 14:39 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20130705050409.GA2946@piware.de>
Hi Martin,
On Fri, Jul 5, 2013 at 7:04 AM, Martin Pitt <martin.pitt@ubuntu.com> wrote:
> time to push out a new release of media-player-info:
>
> http://www.freedesktop.org/software/media-player-info/media-player-info-18.tar.gz
> sha256: 21f186714d8c90e9a78c861cfdbfc1c9ae7eada7b80152a82bec685e7b7fc565
I think you may have forgotten to push this git tag to the public repo?
Cheers,
Tom
^ permalink raw reply
* Re: media-player-info 18 release
From: Martin Pitt @ 2013-07-18 15:52 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20130705050409.GA2946@piware.de>
Tom Gundersen [2013-07-18 16:39 +0200]:
> I think you may have forgotten to push this git tag to the public repo?
*cough*, thanks for pointing out. That's one of my main pet peeves
with git that it doesn't just effing do that with git push. Pushed!
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
^ permalink raw reply
* media-player-info 19 released
From: Martin Pitt @ 2013-07-23 7:25 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 909 bytes --]
Hello all,
thanks to Tom Gundersen media-player-info now builds a hwdb file and
only uses udev rules for the cases where hwdb maching is too limited.
This only happens when building on udev >= 196, so this is fully
backwards compatible on earlier distributions.
Changes:
media-player-info 19 (2013-07-23)
=================================
Martin Pitt (5):
Drop obsolete fdi2mpi.py
Port generator tools to Python 3
Rename mpi files with overly long names
Add Motorola Droid 4
Tom Gundersen (1):
Create udev hwdb when building with udev >= 196
Download:
http://www.freedesktop.org/software/media-player-info/media-player-info-19.tar.gz
sha256sum: 6af252daa8bc5543510e954614e122457429fe9a8d73ad27d6d67c34aff42358
--
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: media-player-info 19 released
From: Martin Pitt @ 2013-07-23 7:42 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20130723072501.GE2958@piware.de>
[-- Attachment #1: Type: text/plain, Size: 518 bytes --]
Martin Pitt [2013-07-23 9:25 +0200]:
> Download:
> http://www.freedesktop.org/software/media-player-info/media-player-info-19.tar.gz
> sha256sum: 6af252daa8bc5543510e954614e122457429fe9a8d73ad27d6d67c34aff42358
Sorry, wrong sum, that was for an older tarball. The correct one is
sha256sum: d5cfb54609d59fe18d63253842c2c56c23b8d44e361d01b34e4a9a3e5fd0265a
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
* media-player-info 21 released
From: Martin Pitt @ 2013-07-24 13:41 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 798 bytes --]
Hello all,
As yesterday's release switched to always building the hwdb/rules file
at build time instead of shipping it pre-generated (as the result
depends on the installed udev version) several distros had problem
with building under the C locale. This version fixes that.
Changes:
media-player-info 21 (2013-07-24)
=================================
Martin Pitt (6):
Fix build under non-UTF8 locales (#67242)
Fix build in separate build tree
Download:
http://www.freedesktop.org/software/media-player-info/media-player-info-21.tar.gz
sha256sum: eae5a41d27715c9280128ff770a491dae2e73e2ebeef41630b069ad0d4795127
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
* Ting Stick Udev Support
From: Tim Sander @ 2013-07-26 19:48 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 601 bytes --]
Hi
Attached are two files which enable the basic functionality to use a Ting-Stick
with Linux. They read out the TDB.TXT file which contains the book nrs and
downloads the coressponding files and clears the TDB.TXT file afterwards.
There is no signalling or anything fancy so there is no indication when the
download process is finished. Also i didn't find an easy way to post a message
to all logged in users via script.
ting.sh should be executable and placed under /usr/local/lib
99-ting.rules is placed in /etc/udev/rules.d.
The files are GPLv2 or later and created by me.
Best regards
Tim
[-- Attachment #2: ting.sh --]
[-- Type: application/x-shellscript, Size: 531 bytes --]
[-- Attachment #3: 99-ting.rules --]
[-- Type: text/plain, Size: 115 bytes --]
SUBSYSTEM=="block",KERNEL=="sd[a-z]",ACTION=="add",ATTRS{vendor}=="TingDisk",RUN:="/usr/local/lib/ting.sh /dev/%k"
^ permalink raw reply
* eMachines E725 keymap
From: Ludvig @ 2013-07-26 20:28 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 246 bytes --]
Keynao for eMachines E725. Nearly identical to the already existing Acer
one, which isn't surprising since eMachines is a sub-brand of acer, but
I'm sending it anyway.
% cat /sys/class/dmi/id/{sys_vendor,product_name}
eMachines
eMachines E725
[-- Attachment #2: emachines --]
[-- Type: text/plain, Size: 320 bytes --]
0xA9 switchvideomode # Fn+F5
0xCE brightnessup # Fn+Right
0xD5 wlan # (toggle) on-to-off
0xD6 wlan # (toggle) off-to-on
0xD7 bluetooth # (toggle) on-to-off
0xD8 bluetooth # (toggle) off-to-on
0xEF brightnessdown # Fn+Left
0xF1 f22 # Fn+F7 Touchpad toggle (off-to-on)
0xF2 f23 # Fn+F7 Touchpad toggle (on-to-off)
0xF8 fn
^ permalink raw reply
* a problem of preparing before cpu hot remove
From: chenfan @ 2013-07-31 3:56 UTC (permalink / raw)
To: linux-hotplug
Hi All,
Recently, I'm implementing cpu hot-remove for QEMU. I has a question
that there is no chance for applications to prepare vcpu-hotremove
before cpu down.
For example, if user specify cpu-pin for some applications, and its cpu
is removed, there is no notification to udev for preparing to do some
repin before cpu down. the applications would not change setting before
cpu down.
I want to know that whether there is a scenario that can notify the
applications for preparing before cpu down. and if preparing fails, I
want the cpu remove failure.
Thanks,
Chen
^ permalink raw reply
* Re: a problem of preparing before cpu hot remove
From: Greg KH @ 2013-07-31 4:06 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1375242987.26515.72.camel@localhost.localdomain>
On Wed, Jul 31, 2013 at 11:56:27AM +0800, chenfan wrote:
> Hi All,
>
> Recently, I'm implementing cpu hot-remove for QEMU. I has a question
> that there is no chance for applications to prepare vcpu-hotremove
> before cpu down.
> For example, if user specify cpu-pin for some applications, and its cpu
> is removed, there is no notification to udev for preparing to do some
> repin before cpu down. the applications would not change setting before
> cpu down.
>
> I want to know that whether there is a scenario that can notify the
> applications for preparing before cpu down. and if preparing fails, I
> want the cpu remove failure.
Right now, there isn't one, but I suggest working with the kernel ACPI
developers as they are working on some kind of notification for this
thing for CPUs and memory, as memory has the same issue that CPUs do.
Hope this helps,
greg k-h
^ permalink raw reply
* Slow firmware timeouts again (Re: [3.11 regression?] iwlwifi firmware takes two minutes to load)
From: Andy Lutomirski @ 2013-08-02 16:04 UTC (permalink / raw)
To: Johannes Berg
Cc: Linux Wireless List, Intel Linux Wireless, linux-hotplug,
linux-kernel, systemd-devel
[cc: linux-kernel, linux-hotplug, and systemd-devel. This is 3.11-rc3+]
On Fri, Aug 2, 2013 at 12:38 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Thu, 2013-08-01 at 21:38 -0700, Andy Lutomirski wrote:
>> At boot, I get:
>> [ 12.537108] iwlwifi 0000:03:00.0: irq 51 for MSI/MSI-X
>> ...
>> [ 132.676781] iwlwifi 0000:03:00.0: loaded firmware version 9.221.4.1
>> build 25532 op_mode iwldvm
>>
>> This sounds familiar, but wasn't it fixed awhile ago?
>
> It wasn't exactly fixed and it's really more of a userspace problem - we
> probably request firmware version 8, and then it takes 30 seconds to
> time out for each of 8,7,6,5, after which the next request for 4 is
> successful.
Why's it requesting those firmwares? They don't seem to exist on
intellinuxwireless.org.
I have:
CONFIG_FW_LOADER=y
# CONFIG_FIRMWARE_IN_KERNEL is not set
CONFIG_EXTRA_FIRMWARE=""
CONFIG_FW_LOADER_USER_HELPER=y
>
> I don't know why your userspace isn't behaving differently though.
>
> johannes
>
--
Andy Lutomirski
AMA Capital Management, LLC
^ permalink raw reply
* Re: Slow firmware timeouts again (Re: [3.11 regression?] iwlwifi firmware takes two minutes to load)
From: Johannes Berg @ 2013-08-02 16:21 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Linux Wireless List, Intel Linux Wireless, linux-hotplug,
linux-kernel, systemd-devel
In-Reply-To: <CALCETrU+C+sO8tJ0X5G4RDVLV=kHQQHurOnEQCoqbAouh60dng@mail.gmail.com>
On Fri, 2013-08-02 at 09:04 -0700, Andy Lutomirski wrote:
> > It wasn't exactly fixed and it's really more of a userspace problem - we
> > probably request firmware version 8, and then it takes 30 seconds to
> > time out for each of 8,7,6,5, after which the next request for 4 is
> > successful.
>
> Why's it requesting those firmwares? They don't seem to exist on
> intellinuxwireless.org.
Well for one you've never even mentioned what device you have, and then
also it's not requesting 8/7 only 6,5,4 -- I guess the timeout was
increased to 60 seconds (or I'm remembering wrong and it always was? I
thought it was 30s)
johannes
^ permalink raw reply
* Re: Slow firmware timeouts again (Re: [3.11 regression?] iwlwifi firmware takes two minutes to load)
From: Andy Lutomirski @ 2013-08-02 16:24 UTC (permalink / raw)
To: Johannes Berg
Cc: Linux Wireless List, Intel Linux Wireless, linux-hotplug,
linux-kernel, systemd-devel
In-Reply-To: <1375460484.18144.11.camel@jlt4.sipsolutions.net>
On Fri, Aug 2, 2013 at 9:21 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Fri, 2013-08-02 at 09:04 -0700, Andy Lutomirski wrote:
>
>> > It wasn't exactly fixed and it's really more of a userspace problem - we
>> > probably request firmware version 8, and then it takes 30 seconds to
>> > time out for each of 8,7,6,5, after which the next request for 4 is
>> > successful.
>>
>> Why's it requesting those firmwares? They don't seem to exist on
>> intellinuxwireless.org.
>
> Well for one you've never even mentioned what device you have, and then
> also it's not requesting 8/7 only 6,5,4 -- I guess the timeout was
> increased to 60 seconds (or I'm remembering wrong and it always was? I
> thought it was 30s)
I have an "Ultimate-N 6300 (rev 35)". It's requesting at least
versions 6 and 5 (I saw them in udevadm monitor). It looks like the
g2a and g2b variants have -5 and -6 versions, but 6000-4 appears to be
the only relevant version for my hardware.
^ permalink raw reply
* Re: Slow firmware timeouts again (Re: [3.11 regression?] iwlwifi firmware takes two minutes to load)
From: Zbigniew Jędrzejewski-Szmek @ 2013-08-02 16:28 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Johannes Berg, Linux Wireless List, Intel Linux Wireless,
linux-hotplug, linux-kernel, systemd-devel
In-Reply-To: <CALCETrU+C+sO8tJ0X5G4RDVLV=kHQQHurOnEQCoqbAouh60dng@mail.gmail.com>
On Fri, Aug 02, 2013 at 09:04:44AM -0700, Andy Lutomirski wrote:
> CONFIG_FW_LOADER_USER_HELPER=y
Do you need this? Unsetting this should help.
"""This option enables / disables the invocation of user-helper
(e.g. udev) for loading firmware files as a fallback after the
direct file loading in kernel fails. The user-mode helper is
no longer required unless you have a special firmware file that
resides in a non-standard path."""
Zbyszek
--
they are not broken. they are refucktored
-- alxchk
^ permalink raw reply
* Re: [systemd-devel] Slow firmware timeouts again (Re: [3.11 regression?] iwlwifi firmware takes two
From: Kay Sievers @ 2013-08-05 11:18 UTC (permalink / raw)
To: Zbigniew Jędrzejewski-Szmek
Cc: Andy Lutomirski, systemd-devel, Linux Wireless List,
linux-hotplug, linux-kernel, Intel Linux Wireless, Johannes Berg
In-Reply-To: <20130802162850.GL32474@in.waw.pl>
On Fri, Aug 2, 2013 at 6:28 PM, Zbigniew Jędrzejewski-Szmek
<zbyszek@in.waw.pl> wrote:
> On Fri, Aug 02, 2013 at 09:04:44AM -0700, Andy Lutomirski wrote:
>> CONFIG_FW_LOADER_USER_HELPER=y
> Do you need this? Unsetting this should help.
>
> """This option enables / disables the invocation of user-helper
> (e.g. udev) for loading firmware files as a fallback after the
> direct file loading in kernel fails. The user-mode helper is
> no longer required unless you have a special firmware file that
> resides in a non-standard path."""
On recent systems, if the kernel configures
CONFIG_FW_LOADER_USER_HELPER=y and a firmware is not found by the
kernel, the kernel will issue a request which is ignored by userspace
and will block in that for 60 seconds.
Udev is no longer in the game of firmware loading, not even as a
fallback, it will just completely ignore all kernel firmware class
events.
The source code in udev to handle firmware requests is disabled by
default, currently still kept around for old kernels without the
in-kernel firmware loader, but it will be deleted in the near future.
Any issues with firmware timeouts should be addressed in the kernel by
disabling CONFIG_FW_LOADER_USER_HELPER or by removing the fallback
code from the in-kernel loader.
Kay
^ permalink raw reply
* Re: [systemd-devel] Slow firmware timeouts again (Re: [3.11 regression?] iwlwifi firmware takes two
From: Andy Lutomirski @ 2013-08-05 16:09 UTC (permalink / raw)
To: Kay Sievers
Cc: Zbigniew Jędrzejewski-Szmek, systemd-devel,
Linux Wireless List, linux-hotplug, linux-kernel,
Intel Linux Wireless, Johannes Berg
In-Reply-To: <CAPXgP13_WRX-asL=MwCM9ERDDMq_7PLkXLr9hwTG-xCg7cm6_A@mail.gmail.com>
On Mon, Aug 5, 2013 at 4:18 AM, Kay Sievers <kay@vrfy.org> wrote:
> On Fri, Aug 2, 2013 at 6:28 PM, Zbigniew Jêdrzejewski-Szmek
> <zbyszek@in.waw.pl> wrote:
>> On Fri, Aug 02, 2013 at 09:04:44AM -0700, Andy Lutomirski wrote:
>>> CONFIG_FW_LOADER_USER_HELPER=y
>> Do you need this? Unsetting this should help.
>>
>> """This option enables / disables the invocation of user-helper
>> (e.g. udev) for loading firmware files as a fallback after the
>> direct file loading in kernel fails. The user-mode helper is
>> no longer required unless you have a special firmware file that
>> resides in a non-standard path."""
>
> On recent systems, if the kernel configures
> CONFIG_FW_LOADER_USER_HELPER=y and a firmware is not found by the
> kernel, the kernel will issue a request which is ignored by userspace
> and will block in that for 60 seconds.
>
> Udev is no longer in the game of firmware loading, not even as a
> fallback, it will just completely ignore all kernel firmware class
> events.
>
> The source code in udev to handle firmware requests is disabled by
> default, currently still kept around for old kernels without the
> in-kernel firmware loader, but it will be deleted in the near future.
Any chance you'd consider a less regression-inducing path to getting
rid of this feature? For example, have udev warn and immediate fail
firmware loading requests for a few releases, then just warn, then
drop support?
Meanwhile, CONFIG_FW_LOADER_USER_HELPER is still default y (!), so
udev has introduced massive bootup delays into the default
configuration with no warning. It might be nice to change it to
default n, get rid of everything that selects it, and possible even
rename it to something with LEGACY or OBSOLETE in the name so that
make oldconfig will prompt.
--Andy
>
> Any issues with firmware timeouts should be addressed in the kernel by
> disabling CONFIG_FW_LOADER_USER_HELPER or by removing the fallback
> code from the in-kernel loader.
>
> Kay
--
Andy Lutomirski
AMA Capital Management, LLC
^ permalink raw reply
* [PATCH] Change CONFIG_FW_LOADER_USER_HELPER to default n and don't select it
From: Andy Lutomirski @ 2013-08-05 16:29 UTC (permalink / raw)
To: linux-kernel, Kay Sievers
Cc: Zbigniew Jędrzejewski-Szmek, systemd-devel,
Linux Wireless List, linux-hotplug, Intel Linux Wireless,
Johannes Berg, Andy Lutomirski
In-Reply-To: <CALCETrXSnFPFVPkXHwz+FFA3=+pmz9V=cMHWwtN+jG1QJALWSQ@mail.gmail.com>
The systemd commit below can delay firmware loading by multiple
minutes if CONFIG_FW_LOADER_USER_HELPER=y. Unfortunately no one
noticed that the systemd-udev change would break new kernels as well
as old kernels.
Since the kernel apparently can't count on reasonable userspace
support, turn this thing off by default.
commit a3bd8447be4ea2ce230eb8ae0e815c04d85fa15a
Author: Tom Gundersen <teg@jklm.no>
Date: Mon Mar 18 15:12:18 2013 +0100
udev: make firmware loading optional and disable by default
Distros that whish to support old kernels should set
--with-firmware-dirs="/usr/lib/firmware/updates:/usr/lib/firmware"
to retain the old behaviour.
---
drivers/base/Kconfig | 15 +++++++++++----
drivers/firmware/Kconfig | 1 -
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 5daa259..de3903e 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -146,13 +146,20 @@ config EXTRA_FIRMWARE_DIR
config FW_LOADER_USER_HELPER
bool "Fallback user-helper invocation for firmware loading"
depends on FW_LOADER
- default y
+ default n
help
This option enables / disables the invocation of user-helper
(e.g. udev) for loading firmware files as a fallback after the
- direct file loading in kernel fails. The user-mode helper is
- no longer required unless you have a special firmware file that
- resides in a non-standard path.
+ direct file loading in kernel fails.
+
+ Since March 2013, a default udev build does not understand
+ firmware loading requests. These udev versions will not
+ even indicate failure; instead they cause long timeouts.
+ This can dramatically slow down the boot process.
+
+ Say Y only if you have special firmware-loading requirements
+ and if you have a non-standard helper that will handle these
+ requests.
config DEBUG_DRIVER
bool "Driver Core verbose debug messages"
diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index 07478728..9387630 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -64,7 +64,6 @@ config DELL_RBU
tristate "BIOS update support for DELL systems via sysfs"
depends on X86
select FW_LOADER
- select FW_LOADER_USER_HELPER
help
Say m if you want to have the option of updating the BIOS for your
DELL system. Note you need a Dell OpenManage or Dell Update package (DUP)
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] Change CONFIG_FW_LOADER_USER_HELPER to default n and don't select it
From: Maarten Lankhorst @ 2013-08-06 8:20 UTC (permalink / raw)
To: Andy Lutomirski
Cc: linux-kernel, Kay Sievers, Zbigniew Jędrzejewski-Szmek,
systemd-devel, Linux Wireless List, linux-hotplug,
Intel Linux Wireless, Johannes Berg
In-Reply-To: <325b19bb936d7ebae11edad86aac8f0931e8abd9.1375719828.git.luto@amacapital.net>
Op 05-08-13 18:29, Andy Lutomirski schreef:
> The systemd commit below can delay firmware loading by multiple
> minutes if CONFIG_FW_LOADER_USER_HELPER=y. Unfortunately no one
> noticed that the systemd-udev change would break new kernels as well
> as old kernels.
>
> Since the kernel apparently can't count on reasonable userspace
> support, turn this thing off by default.
>
> commit a3bd8447be4ea2ce230eb8ae0e815c04d85fa15a
> Author: Tom Gundersen <teg@jklm.no>
> Date: Mon Mar 18 15:12:18 2013 +0100
>
> udev: make firmware loading optional and disable by default
>
> Distros that whish to support old kernels should set
> --with-firmware-dirs="/usr/lib/firmware/updates:/usr/lib/firmware"
> to retain the old behaviour.
>
methinks this patch should be reverted then, or a stub should be added to udev to always fail firmware loading so timeouts don't occur.
~Maarten
^ 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