* [ANNOUNCE] kmod 10
From: Lucas De Marchi @ 2012-09-06 19:37 UTC (permalink / raw)
To: linux-modules; +Cc: LKML, linux-hotplug
Hey!
kmod 10 is out:
ftp://ftp.kernel.org/pub/linux/utils/kernel/kmod/kmod-10.tar.xz
ftp://ftp.kernel.org/pub/linux/utils/kernel/kmod/kmod-10.tar.sign
The major change was the addition of a flag in
kmod_module_probe_insert() to keep the previous behavior of
module-init-tools regarding blacklisted modules.
Other than that, improvements to testsuite and man pages. I also
re-licensed the testsuite as LGPL. If anyone wants to use in his own
project and LGPL doesn't fit your needs, let me know.
Shortlog is below
Cheers!
Lucas De Marchi
---
Colin Walters (1):
build-sys: Add --disable-manpages option
Dave Reisner (10):
Implicitly run 'make rootfs' with 'make check'
module: support reading coresize from /sys if supported
build-sys: disable jobserver for rootfs target
man/modprobe: clarify --dirname option
man/modinfo: document --basedir option
man/modinfo: document longopts for field shortcuts
man/modinfo: specify each option in separate <term> tag
man/modprobe: specify each option in separate <term> tag
man/depmod: specify each option in separate <term> tag
man/rmmod: specify each option in separate <term> tag
Lucas De Marchi (10):
testsuite: use right offset for module name
testsuite: re-license under LGPL
Use #pragma once instead of #ifndef
build-sys: add 'man' entry in summary
README: let people know they don't need to subscribe
libkmod-module: Add KMOD_PROBE_APPLY_BLACKLIST_ALIAS_ONLY flag
modprobe: Unconditionally use KMOD_PROBE_APPLY_BLACKLIST_ALIAS_ONLY
TODO: deprecate use of rmmod -w
Remove test directory
kmod 10
Martin Pitt (2):
testsuite: path wrapper: Fix open() with 3 arguments
testsuite preload: Factorize into macros, add more stat and open variants
^ permalink raw reply
* udisks2 and ACLs
From: Allin Cottrell @ 2012-09-05 13:26 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: TEXT/PLAIN, Size: 696 bytes --]
I notice that udisks-1.99.0 depends unconditionally on ACLs
(for handling permissions under /run/media). Since ACLs are
kinda redundant on personal laptop and desktop systems it
would be nice if this dependency were optional.
I'm attaching a patch to udisks' udiskslinuxfilesystem.c which
calls chown() if ACLs are not available. Since I'm not an
automake guy I'm not sure how to revise the configure script,
but the idea is that you should be able to do
--disable-acl
with the effect that ENABLE_ACL is not defined (otherwise it
is defined). And config.h.in should have added:
/* Enable ACLs */
#undef ENABLE_ACL
--
Allin Cottrell
Department of Economics
Wake Forest University, NC
[-- Attachment #2: Type: TEXT/PLAIN, Size: 2054 bytes --]
--- udiskslinuxfilesystem.c.orig 2012-08-30 13:22:17.975670390 -0400
+++ udiskslinuxfilesystem.c 2012-09-05 09:15:01.755412910 -0400
@@ -29,7 +29,9 @@
#include <stdio.h>
#include <mntent.h>
#include <sys/types.h>
+#ifdef ENABLE_ACL
#include <sys/acl.h>
+#endif
#include <errno.h>
#include <glib/gstdio.h>
@@ -781,10 +783,13 @@
/* ---------------------------------------------------------------------------------------------------- */
+#ifdef ENABLE_ACL
+
static gboolean
-add_acl (const gchar *path,
- uid_t uid,
- GError **error)
+add_user_permission (const gchar *path,
+ uid_t uid,
+ gid_t gid,
+ GError **error)
{
gboolean ret = FALSE;
acl_t acl = NULL;
@@ -817,6 +822,34 @@
return ret;
}
+#else
+
+static gboolean
+add_user_permission (const gchar *path,
+ uid_t uid,
+ gid_t gid,
+ GError **error)
+{
+ gboolean ret = FALSE;
+
+ if (chown(path, uid, gid) != 0)
+ {
+ g_set_error (error,
+ G_IO_ERROR,
+ g_io_error_from_errno (errno),
+ "Giving ownership to uid %d for `%s' failed: %m",
+ (gint) uid, path);
+ }
+ else
+ {
+ ret = TRUE;
+ }
+
+ return ret;
+}
+
+#endif /* ENABLE_ACL or not */
+
/*
* calculate_mount_point: <internal>
* @dameon: A #UDisksDaemon.
@@ -888,8 +921,8 @@
mount_dir);
goto out;
}
- /* Finally, add the read+execute ACL for $USER */
- if (!add_acl (mount_dir, uid, error))
+ /* Finally, add the read+execute ACL for $USER (or chown) */
+ if (!add_user_permission (mount_dir, uid, gid, error))
{
if (rmdir (mount_dir) != 0)
udisks_warning ("Error calling rmdir() on %s: %m", mount_dir);
^ permalink raw reply
* $attr substitution for parent devices
From: Cedric Jehasse @ 2012-08-27 8:16 UTC (permalink / raw)
To: linux-hotplug
Hi,
I have the following rules file:
#######################################################################################
ACTION!="add", GOTO="modeswitch_rules_end"
SUBSYSTEM!="usb", GOTO="modeswitch_rules_end"
ATTRS{bDeviceClass}="08", GOTO="modeswitch_rules_begin"
ATTRS{bInterfaceClass}="08", GOTO="modeswitch_rules_begin"
GOTO="modeswitch_rules_end"
LABEL="modeswitch_rules_begin"
ATTRS{idVendor}="12d1", ATTRS{idProduct}="1003",
RUN+="/usr/sbin/usb_modeswitch -c
/etc/usb_modeswitch.d/$attr{idVendor}:$attr{idProduct}"
ATTRS{idVendor}="12d1", ATTRS{idProduct}="1414",
RUN+="/usr/sbin/usb_modeswitch -c
/etc/usb_modeswitch.d/$attr{idVendor}:$attr{idProduct}"
ATTRS{idVendor}="12d1", ATTRS{idProduct}="1446",
RUN+="/usr/sbin/usb_modeswitch -c
/etc/usb_modeswitch.d/$attr{idVendor}:$attr{idProduct}"
LABEL="modeswitch_rules_end"
########################################################################################
When the matching rule is not the last rule in the file, $attr is
substituted by an empty string.
I've found out that by the time the RUN format gets applied
event->dev_parent is NULL, so it doesn't find the attributes for
substitution.
In udev_rules_apply_to_event event->dev_parent is used to loop over
the parent devices. If there are multiple rules trying to match parent
properties, event->dev_parent will be reset to NULL when there's a
non-matching rule following a matching rule.
Is this the expected behavior or not?
In this case the logical thing to do would be to substitute the format
while processing the rules. But the man-page says there are reasons to
apply the RUN format after all rules have been processed.
thanks,
Cedric
^ permalink raw reply
* How to avoid renaming of network devices (eth5 to eth0, eth6 to eth1, and so on)
From: Kevin Wilson @ 2012-08-25 10:33 UTC (permalink / raw)
To: linux-hotplug
Hello,
I am using Ubuntu with udev on a Linux machine
From time to time it happens that network devices are renamed after boot,
and this is due to udev (I know for sure that the reason for this is
uboot, because if I delete the udev
network rules file from /etc/udev/rules.d/, and reboot again, this
renaming does not occur).
What I mean more specifically is this:
I boot and I have (when running "ifconfig -a") eth0, eth1, eth2, eth3
(I have 4 network cards).
sometimes after reboot I get with ""ifconfig -a" " the following :
eth6, eth7, eth8, eth9
(I cannot specify at which occasions exactly does it happen, whether
it is as a result of some setting
I change, etc.)
How can I prevent this renaming of network devices ? Can I somehow prevent
udev renaming of network interfaces totally ?
rgs,
Kevin
^ permalink raw reply
* iwlwifi firmware problem
From: Allin Cottrell @ 2012-08-24 18:10 UTC (permalink / raw)
To: linux-hotplug
With current systemd and Linux kernel I'm seeing a problem
with loading the iwlwifi firmware at boot time:
[ 14.236171] iwlwifi: Intel(R) Wireless WiFi Link AGN driver
for Linux, in-tree:
[ 14.236174] iwlwifi: Copyright(c) 2003-2012 Intel
Corporation
[ 14.236349] iwlwifi 0000:03:00.0: pci_resource_len =
0x00002000
[ 14.236352] iwlwifi 0000:03:00.0: pci_resource_base =
ffffc90000078000
[ 14.236354] iwlwifi 0000:03:00.0: HW Revision ID = 0x34
[ 14.236750] iwlwifi 0000:03:00.0: irq 49 for MSI/MSI-X
[ 14.478203] firmware 0000:03:00.0: firmware_loading_store:
unexpected value (0)
[ 14.716820] firmware 0000:03:00.0: firmware_loading_store:
unexpected value (0)
[ 14.717063] iwlwifi 0000:03:00.0: request for firmware file
'iwlwifi-6000g2a-5.ucode' failed.
[ 14.717117] iwlwifi 0000:03:00.0: no suitable firmware
found!
This is on a ThinkPad T420s. After booting is finished I can
modprobe -r iwlwifi and reload the module, then the firmware
loads OK (version 18.168.6.1, iwlwifi-6000g2a-6.ucode). But it
would nice to have it "just work". Any suggestions? Thanks.
--
Allin Cottrell
Department of Economics
Wake Forest University, NC
^ permalink raw reply
* Re: systemd-189: missing headers?
From: Kay Sievers @ 2012-08-23 23:47 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <alpine.LNX.2.01.1208231112290.22152@waverley.dhcp.wfu.edu>
On Thu, Aug 23, 2012 at 6:21 PM, Allin Cottrell <cottrell@wfu.edu> wrote:
> On Thu, 23 Aug 2012, Kay Sievers wrote:
>> On Thu, Aug 23, 2012 at 5:35 PM, Allin Cottrell <cottrell@wfu.edu> wrote:
>>>
>>> The systemd-189 release doesn't compile out of the box on my system (gcc
>>> 4.7.1, glibc-2.16.0, Linux 3.5.2). It seems that some required headers
>>> are
>>> not being included in several source files under src/journal/.
>>> Specifically,
>>>
>>> * journald-kmsg.c, journald-console.c and journald-gperf.c all need
>>> <sys/socket.h> for struct ucred.
>>>
>>> * journald-syslog.c, journald-stream.c and journald-native.c
>>> all need <stddef.h> for offsetof().
>>
>> Mind just sending a patch that makes it work for you?
>
> No problem; patch now attached.
Applied.
Thanks,
Kay
^ permalink raw reply
* Re: systemd-189: missing headers?
From: Allin Cottrell @ 2012-08-23 16:21 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <alpine.LNX.2.01.1208231112290.22152@waverley.dhcp.wfu.edu>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 728 bytes --]
On Thu, 23 Aug 2012, Kay Sievers wrote:
> On Thu, Aug 23, 2012 at 5:35 PM, Allin Cottrell <cottrell@wfu.edu> wrote:
>> The systemd-189 release doesn't compile out of the box on my system (gcc
>> 4.7.1, glibc-2.16.0, Linux 3.5.2). It seems that some required headers are
>> not being included in several source files under src/journal/. Specifically,
>>
>> * journald-kmsg.c, journald-console.c and journald-gperf.c all need
>> <sys/socket.h> for struct ucred.
>>
>> * journald-syslog.c, journald-stream.c and journald-native.c
>> all need <stddef.h> for offsetof().
>
> Mind just sending a patch that makes it work for you?
No problem; patch now attached.
--
Allin Cottrell
Department of Economics
Wake Forest University, NC
[-- Attachment #2: Type: TEXT/PLAIN, Size: 2461 bytes --]
diff -ur a/systemd-189/src/journal/journald-console.c b/systemd-189/src/journal/journald-console.c
--- a/systemd-189/src/journal/journald-console.c 2012-08-21 21:35:30.037234329 -0400
+++ b/systemd-189/src/journal/journald-console.c 2012-08-23 12:12:42.098121723 -0400
@@ -21,6 +21,7 @@
#include <fcntl.h>
#include <unistd.h>
+#include <sys/socket.h>
#include "journald.h"
#include "journald-console.h"
diff -ur a/systemd-189/src/journal/journald-gperf.gperf b/systemd-189/src/journal/journald-gperf.gperf
--- a/systemd-189/src/journal/journald-gperf.gperf 2012-08-20 13:22:51.793235967 -0400
+++ b/systemd-189/src/journal/journald-gperf.gperf 2012-08-23 12:12:42.098121723 -0400
@@ -1,5 +1,6 @@
%{
#include <stddef.h>
+#include <sys/socket.h>
#include "conf-parser.h"
#include "journald.h"
%}
diff -ur a/systemd-189/src/journal/journald-kmsg.c b/systemd-189/src/journal/journald-kmsg.c
--- a/systemd-189/src/journal/journald-kmsg.c 2012-08-21 21:28:48.703214905 -0400
+++ b/systemd-189/src/journal/journald-kmsg.c 2012-08-23 12:12:42.098121723 -0400
@@ -23,6 +23,7 @@
#include <sys/epoll.h>
#include <fcntl.h>
#include <sys/mman.h>
+#include <sys/socket.h>
#include <systemd/sd-messages.h>
#include <libudev.h>
diff -ur a/systemd-189/src/journal/journald-native.c b/systemd-189/src/journal/journald-native.c
--- a/systemd-189/src/journal/journald-native.c 2012-08-21 21:41:47.571252600 -0400
+++ b/systemd-189/src/journal/journald-native.c 2012-08-23 12:12:42.098121723 -0400
@@ -20,6 +20,7 @@
***/
#include <unistd.h>
+#include <stddef.h>
#include <sys/epoll.h>
#include "socket-util.h"
diff -ur a/systemd-189/src/journal/journald-stream.c b/systemd-189/src/journal/journald-stream.c
--- a/systemd-189/src/journal/journald-stream.c 2012-08-21 21:38:28.815242981 -0400
+++ b/systemd-189/src/journal/journald-stream.c 2012-08-23 12:12:42.098121723 -0400
@@ -21,6 +21,7 @@
#include <fcntl.h>
#include <unistd.h>
+#include <stddef.h>
#include <sys/epoll.h>
#ifdef HAVE_SELINUX
diff -ur a/systemd-189/src/journal/journald-syslog.c b/systemd-189/src/journal/journald-syslog.c
--- a/systemd-189/src/journal/journald-syslog.c 2012-08-21 21:35:55.155235545 -0400
+++ b/systemd-189/src/journal/journald-syslog.c 2012-08-23 12:12:42.098121723 -0400
@@ -20,6 +20,7 @@
***/
#include <unistd.h>
+#include <stddef.h>
#include <sys/epoll.h>
#include "socket-util.h"
^ permalink raw reply
* Re: systemd-189: missing headers?
From: Kay Sievers @ 2012-08-23 15:44 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <alpine.LNX.2.01.1208231112290.22152@waverley.dhcp.wfu.edu>
On Thu, Aug 23, 2012 at 5:35 PM, Allin Cottrell <cottrell@wfu.edu> wrote:
> The systemd-189 release doesn't compile out of the box on my system (gcc
> 4.7.1, glibc-2.16.0, Linux 3.5.2). It seems that some required headers are
> not being included in several source files under src/journal/. Specifically,
>
> * journald-kmsg.c, journald-console.c and journald-gperf.c all need
> <sys/socket.h> for struct ucred.
>
> * journald-syslog.c, journald-stream.c and journald-native.c
> all need <stddef.h> for offsetof().
Mind just sending a patch that makes it work for you?
We do not see that issue on our systems.
Thanks,
Kay
^ permalink raw reply
* systemd-189: missing headers?
From: Allin Cottrell @ 2012-08-23 15:35 UTC (permalink / raw)
To: linux-hotplug
The systemd-189 release doesn't compile out of the box on my
system (gcc 4.7.1, glibc-2.16.0, Linux 3.5.2). It seems that
some required headers are not being included in several source
files under src/journal/. Specifically,
* journald-kmsg.c, journald-console.c and journald-gperf.c all
need <sys/socket.h> for struct ucred.
* journald-syslog.c, journald-stream.c and journald-native.c
all need <stddef.h> for offsetof().
--
Allin Cottrell
Department of Economics
Wake Forest University, NC
^ permalink raw reply
* Re: NCD, a light scripting language for network configs and much more
From: Stephen Hemminger @ 2012-08-17 16:22 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CAOA3yKKmuAi=CPE=4-hyoGJJ7D7Oa_Bug5G=1Z3xif-5iFGeOw@mail.gmail.com>
On Fri, 17 Aug 2012 12:03:55 +0200
Ambroz Bizjak <ambrop7@gmail.com> wrote:
> Hi. I'm developing a special kind of scripting language which many
> might find useful: http://code.google.com/p/badvpn/wiki/NCD
>
> It was (originally) designed for programming dynamic configuration of
> network interfaces, iptables etc. For example, there are commands that
> observe the presence and link status of network interfaces. Many
> commands are reversible, which makes it very easy to do cleanup
> automatically and implicitly, like removing IP addresses or routes
> when the link goes down on an interface.
>
> The major advantage of this language compared to existing systems like
> NetworkManager and wicd is that it's extremely hackable; you can fine
> tune almost any part of the process. For example, this simple script
> will create a network bridge, ensure that interfaces eth0 and eth1 are
> in the bridge whenever they exist (consider hotplugging USB
> interfaces), and only after eth0 (!) is up and running will it obtain
> an IP address on br0 (!) using DHCP (since we know DHCP server is on
> eth0 not eth1).
>
> process bridge {
> # Choose name of bridge.
> var("br6") bridge_dev;
>
> # Create the bridge (and destroy it on deinit).
> run({"/sbin/brctl", "addbr", bridge_dev},
> {"/sbin/brctl", "delbr", bridge_dev});
>
> # Set bridge up.
> net.up(bridge_dev);
>
> # Wake up ports.
> provide("BRIDGE");
FYI - you can use ip commands now to control bridge.
For all the new features planned, they won't be controllable via brctl.
^ permalink raw reply
* NCD, a light scripting language for network configs and much more
From: Ambroz Bizjak @ 2012-08-17 10:03 UTC (permalink / raw)
To: linux-hotplug
Hi. I'm developing a special kind of scripting language which many
might find useful: http://code.google.com/p/badvpn/wiki/NCD
It was (originally) designed for programming dynamic configuration of
network interfaces, iptables etc. For example, there are commands that
observe the presence and link status of network interfaces. Many
commands are reversible, which makes it very easy to do cleanup
automatically and implicitly, like removing IP addresses or routes
when the link goes down on an interface.
The major advantage of this language compared to existing systems like
NetworkManager and wicd is that it's extremely hackable; you can fine
tune almost any part of the process. For example, this simple script
will create a network bridge, ensure that interfaces eth0 and eth1 are
in the bridge whenever they exist (consider hotplugging USB
interfaces), and only after eth0 (!) is up and running will it obtain
an IP address on br0 (!) using DHCP (since we know DHCP server is on
eth0 not eth1).
process bridge {
# Choose name of bridge.
var("br6") bridge_dev;
# Create the bridge (and destroy it on deinit).
run({"/sbin/brctl", "addbr", bridge_dev},
{"/sbin/brctl", "delbr", bridge_dev});
# Set bridge up.
net.up(bridge_dev);
# Wake up ports.
provide("BRIDGE");
# Wait for port eth0 where we expect to have the DHCP server.
depend("BRIDGE-link");
# Obtain IP address.
net.ipv4.dhcp(bridge_dev) dhcp;
# Sanity check IP address.
ip_in_network(dhcp.addr, "127.0.0.0", "8") test_local;
ifnot(test_local);
# Assign IP address (and remove it when anything goes wrong,
# e.g. lease times out, eth0 disappears or loses link...).
net.ipv4.addr(bridge_dev, dhcp.addr, dhcp.prefix);
println("Got address: ", dhcp.addr, "/", dhcp.prefix);
rprintln("Lost address");
}
process bridge_port_eth0 {
depend("BRIDGE") br;
# Choose name of device.
var("eth0") dev;
# Wait for device to start existing (and trigger deinit
# when it stops existing).
net.backend.waitdevice(dev);
# Add it to the bridge (and remove it when it stops
# existing or we're quitting).
run({"/sbin/brctl", "addif", br.bridge_dev, dev},
{"/sbin/brctl", "delif", br.bridge_dev, dev});
# Set device up.
net.up(dev);
# Wait for link.
net.backend.waitlink(dev);
# Wake up bridge process so it can start DHCP.
provide("BRIDGE-link");
}
# other ports: same as above, just no need to wait for link
process bridge_port_eth1 {
depend("BRIDGE") br;
var("eth1") dev;
net.backend.waitdevice(dev);
run({"/sbin/brctl", "addif", br.bridge_dev, dev},
{"/sbin/brctl", "delif", br.bridge_dev, dev});
net.up(dev);
}
Note that nothing is ever leaked here. When the NCD interpreter
receives SIGTERM, it automatically cleans up everything (removes IP
addresses, destroys bridge...).
The language is suitable for much more than network configs. For
instance, it allows receiving input/evdev events from a single device
with only a few lines of code:
process main {
sys.evdev("/dev/input/by-id/usb-BTC_USB_Multimedia_Keyboard-event-kbd")
evdev;
println("Event: ", evdev.type, " ", evdev.value, " ", evdev.code);
val_equal(evdev.code, "KEY_ENTER") is_enter;
If (is_enter) {
println("You pressed enter!");
};
evdev->nextevent();
}
With some more code it's possible to automatically listen on all event
devices as they come and go.
I think it would also make a great base to build an init system upon
(implement init process in NCD language). I've toyed a little with
this and got something very simple working, see
http://code.google.com/p/ncdinit/ .
Best regards,
Ambroz Bizjak
^ permalink raw reply
* Re: killing udev for non-systemd systems
From: Colin Guthrie @ 2012-08-14 22:20 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20120814180111.GA7801@linux1>
'Twas brillig, and William Hubbs at 14/08/12 19:01 did gyre and gimble:
> You have taken a piece of software which is important to many linux
> systems (udev) and merged it into an init system (systemd) which is not
> used everywhere for a number of reasons. Now you are planning to kill
> udev for systems that do not use systemd. Why is that? Why are you
> saying that udev on non-systemd systems is a dead end?
>
> Is there some alternative for non-systemd systems?
I think you're over reacting here.
The comment about it being a dead end is likely more related to how
device management and service management are *very* closely linked
sometimes - especially if you want to do things properly and non-racy
without lots of good will sprinkled over things in the hope that they
glue together OK. So to get the most out of udev and do things properly
you *need* to integrate properly with the init system. That's what I
read from the "dead end" statement anyway.
While I'm sure Lennart and Kay are looking forward to the day they can
drop any semblance of support for a separate udev entirely, I doubt very
much it's any time in the next little while (although I'm always
prepared to be proved wrong).
And besides, even if they do it's easy enough to fork using git and
maintain a separate version while still sharing most of the code if that
floats your boat.
I suspect in a few years time we'll see a much more focused systemd
world anyway and the people who are not using it now for whatever reason
will see the light/drink the kool-aid :p
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
^ permalink raw reply
* killing udev for non-systemd systems
From: William Hubbs @ 2012-08-14 18:01 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 1584 bytes --]
Hey Lennart, Kay and all,
On Wed, Aug 01, 2012 at 06:58:39PM +0200, Lennart Poettering wrote:
> Well, we intent to continue to make it possible to run udevd outside of
> systemd. But that's about it. We will not polish that, or add new
> features to that or anything.
>
> OTOH we do polish behaviour of udev when used *within* systemd however,
> and that's our primary focus.
>
> And what we will certainly not do is compromise the uniform integration
> into systemd for some cosmetic improvements for non-systemd systems.
>
> (Yes, udev on non-systemd systems is in our eyes a dead end, in case you
> haven't noticed it yet. I am looking forward to the day when we can drop
> that support entirely.)
There are a number of reasons from what I see on my distro's development
list and from what I've seen insome patches proposed here, that everyone
isn't comfortable with systemd.
I thought the merge was more for administrative reasons, because there
is common source code between systemd and udev that you did not want to
provide as libraries.
Now though, with the attitude toward non-systemd systems that I see
above, I am starting to wonder.
You have taken a piece of software which is important to many linux
systems (udev) and merged it into an init system (systemd) which is not
used everywhere for a number of reasons. Now you are planning to kill
udev for systems that do not use systemd. Why is that? Why are you
saying that udev on non-systemd systems is a dead end?
Is there some alternative for non-systemd systems?
William
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: add loop device backing file in udev database
From: Karel Zak @ 2012-08-06 13:57 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <5deaf9514b7dafac35d4cdef91260ba1@poivron.org>
On Thu, Jun 28, 2012 at 04:38:46PM +0200, quidame@poivron.org wrote:
> >That is usually the wrong thing to do, because it can get out-of-sync,
> >and udev would pretend something that is not true anymore.
Right, /sys is always better place than udev db.
> # losetup -d /dev/loop0
> # losetup /dev/loop0 /dev/sdc1 # sdc is USB stick
There is also LOOP_CHANGE_FD ioctl, I have doubts that kernel informs
userspace about this change. (but standard userspace utils does not
use this ioctl)
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: Re-enable by-path links for ata device
From: Robert Milasan @ 2012-08-03 9:31 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20120802203126.71a8f2af@coolcat.suse.cz>
On Fri, 3 Aug 2012 10:44:11 +0200
Kay Sievers <kay@vrfy.org> wrote:
> On Thu, Aug 2, 2012 at 8:31 PM, Robert Milasan <rmilasan@suse.cz>
> wrote:
> > Hello, just created a patch for openSUSE to re-enable by-path links
> > for ata devices. The patch is based on handle_scsi_default
> > function, but instead of using "host{NUMBER}", but "ata{NUMBER}"
> > and it works almost the same as for scsi devices.
> >
> > The patch is not the best or the cleanest, but it works.
>
> We can not play these games for any new stuff, like SCSI path_id is
> doing here, it's a legacy from a time we had we no good idea how
> things should work. What SCSI path_id is doing here is "I hope it
> works, let's try ..." software, which is a model that we don't support
> anymore. :)
>
> We need the ATA transport class to export the local port number of the
> host adapter, and use that.
>
> Rebasing in userspace by making assumptions about a global in-kernel
> instance counter is racy, unreliable and can only work if all things
> would always happen in strict order, and they don't. Manual driver
> unbind/bind, parallel hotplug gets into the way of this too simple
> logic.
>
> The proper fix is to teach the kernel to export the numbers directly,
> or get the numbers in some way, but not by doing readdir() and
> starting to count and make a guess.
>
> Hope you understand that we can not do this for any new stuff, it just
> does not meet the requirements we have today.
>
> Thanks,
> Kay
It's fine with me, just wanted to make sure people know, maybe someone
needs it or wants it.
Thanks,
Robert
^ permalink raw reply
* Re: Re-enable by-path links for ata device
From: Kay Sievers @ 2012-08-03 8:44 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20120802203126.71a8f2af@coolcat.suse.cz>
On Thu, Aug 2, 2012 at 8:31 PM, Robert Milasan <rmilasan@suse.cz> wrote:
> Hello, just created a patch for openSUSE to re-enable by-path links for
> ata devices. The patch is based on handle_scsi_default function, but
> instead of using "host{NUMBER}", but "ata{NUMBER}" and it works almost
> the same as for scsi devices.
>
> The patch is not the best or the cleanest, but it works.
We can not play these games for any new stuff, like SCSI path_id is
doing here, it's a legacy from a time we had we no good idea how
things should work. What SCSI path_id is doing here is "I hope it
works, let's try ..." software, which is a model that we don't support
anymore. :)
We need the ATA transport class to export the local port number of the
host adapter, and use that.
Rebasing in userspace by making assumptions about a global in-kernel
instance counter is racy, unreliable and can only work if all things
would always happen in strict order, and they don't. Manual driver
unbind/bind, parallel hotplug gets into the way of this too simple
logic.
The proper fix is to teach the kernel to export the numbers directly,
or get the numbers in some way, but not by doing readdir() and
starting to count and make a guess.
Hope you understand that we can not do this for any new stuff, it just
does not meet the requirements we have today.
Thanks,
Kay
^ permalink raw reply
* Re-enable by-path links for ata device
From: Robert Milasan @ 2012-08-02 18:31 UTC (permalink / raw)
To: linux-hotplug
Hello, just created a patch for openSUSE to re-enable by-path links for
ata devices. The patch is based on handle_scsi_default function, but
instead of using "host{NUMBER}", but "ata{NUMBER}" and it works almost
the same as for scsi devices.
The patch is not the best or the cleanest, but it works.
Index: udev-182/src/udev-builtin-path_id.c
=================================--- udev-182.orig/src/udev-builtin-path_id.c
+++ udev-182/src/udev-builtin-path_id.c
@@ -286,6 +286,85 @@ out:
return hostdev;
}
+static struct udev_device *handle_ata(struct udev_device *parent, char **path)
+{
+ struct udev_device *hostdev;
+ int host, bus, target, lun;
+ const char *name;
+ char *base;
+ char *pos;
+ DIR *dir;
+ struct dirent *dent;
+ int basenum, len;
+
+ hostdev = udev_device_get_parent_with_subsystem_devtype(parent, "scsi", "scsi_host");
+ if (hostdev = NULL)
+ return NULL;
+
+ name = udev_device_get_sysname(parent);
+ if (sscanf(name, "%d:%d:%d:%d", &host, &bus, &target, &lun) != 4)
+ return NULL;
+
+ /* rebase ata offset to get the local relative number */
+ basenum = -1;
+ base = strdup(udev_device_get_syspath(hostdev));
+ if (base = NULL)
+ return NULL;
+ pos = strrchr(base, '/');
+ if (pos = NULL) {
+ parent = NULL;
+ goto out;
+ }
+ pos[0] = '\0';
+ len = strlen(base) - 5;
+ if (len <= 0) {
+ parent = NULL;
+ goto out;
+ }
+ base[len] = '\0';
+ dir = opendir(base);
+ if (dir = NULL) {
+ parent = NULL;
+ goto out;
+ }
+ for (dent = readdir(dir); dent != NULL; dent = readdir(dir)) {
+ char *rest;
+ int i;
+
+ if (dent->d_name[0] = '.')
+ continue;
+ if (dent->d_type != DT_DIR && dent->d_type != DT_LNK)
+ continue;
+ if (strncmp(dent->d_name, "ata", 3) != 0)
+ continue;
+ i = strtoul(&dent->d_name[3], &rest, 10);
+
+ /* ata devices start with 1, so decrease by 1 if i is bigger then 0 */
+ if (i > 0)
+ i--;
+ if (rest[0] != '\0')
+ continue;
+ /*
+ * find the smallest number; the host really needs to export its
+ * own instance number per parent device; relying on the global host
+ * enumeration and plainly rebasing the numbers sounds unreliable
+ */
+ if (basenum = -1 || i < basenum)
+ basenum = i;
+ }
+ closedir(dir);
+ if (basenum = -1) {
+ parent = NULL;
+ goto out;
+ }
+ host -= basenum;
+
+ path_prepend(path, "scsi-%u:%u:%u:%u", host, bus, target, lun);
+out:
+ free(base);
+ return hostdev;
+}
+
static struct udev_device *handle_scsi(struct udev_device *parent, char **path)
{
const char *devtype;
@@ -322,16 +401,8 @@ static struct udev_device *handle_scsi(s
goto out;
}
- /*
- * We do not support the ATA transport class, it creates duplicated link
- * names as the fake SCSI host adapters are all separated, they are all
- * re-based as host = 0. ATA should just stop faking two duplicated
- * hierarchies for a single topology and leave the SCSI stuff alone;
- * until that happens, there are no by-path/ links for ATA devices behind
- * an ATA transport class.
- */
if (strstr(name, "/ata") != NULL) {
- parent = NULL;
+ parent = handle_ata(parent, path);
goto out;
}
NOTE: The patch is for udev 182, but its easy to adapt this to systemd
187.
^ permalink raw reply
* Re: [PATCH] udev: fix typo
From: Kay Sievers @ 2012-08-01 22:56 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1343849611-7971-1-git-send-email-w.d.hubbs@gmail.com>
On Wed, Aug 1, 2012 at 9:33 PM, William Hubbs <w.d.hubbs@gmail.com> wrote:
> ---
> rules/80-drivers.rules | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/rules/80-drivers.rules b/rules/80-drivers.rules
> index 692510c..38ebfeb 100644
> --- a/rules/80-drivers.rules
> +++ b/rules/80-drivers.rules
> @@ -7,6 +7,6 @@ SUBSYSTEM="tifm", ENV{TIFM_CARD_TYPE}="SD", IMPORT{builtin}="kmod load tifm_sd
> SUBSYSTEM="tifm", ENV{TIFM_CARD_TYPE}="MS", IMPORT{builtin}="kmod load tifm_ms"
> SUBSYSTEM="memstick", IMPORT{builtin}="kmod load ms_block mspro_block"
> SUBSYSTEM="i2o", IMPORT{builtin}="kmod load i2o_block"
> -SUBSYSTEM="module", KERNEL="parport_pc", RUN{builtin}="kmod load ppdev"
> +SUBSYSTEM="module", KERNEL="parport_pc", IMPORT{builtin}="kmod load ppdev"
IMPORT and RUN should both work the same way with builtins. It's at
least supposed to work, let me know if it doesn't.
Thanks,
Kay
^ permalink raw reply
* [PATCH] udev: fix typo
From: William Hubbs @ 2012-08-01 19:33 UTC (permalink / raw)
To: linux-hotplug
---
rules/80-drivers.rules | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/rules/80-drivers.rules b/rules/80-drivers.rules
index 692510c..38ebfeb 100644
--- a/rules/80-drivers.rules
+++ b/rules/80-drivers.rules
@@ -7,6 +7,6 @@ SUBSYSTEM="tifm", ENV{TIFM_CARD_TYPE}="SD", IMPORT{builtin}="kmod load tifm_sd
SUBSYSTEM="tifm", ENV{TIFM_CARD_TYPE}="MS", IMPORT{builtin}="kmod load tifm_ms"
SUBSYSTEM="memstick", IMPORT{builtin}="kmod load ms_block mspro_block"
SUBSYSTEM="i2o", IMPORT{builtin}="kmod load i2o_block"
-SUBSYSTEM="module", KERNEL="parport_pc", RUN{builtin}="kmod load ppdev"
+SUBSYSTEM="module", KERNEL="parport_pc", IMPORT{builtin}="kmod load ppdev"
LABEL="drivers_end"
--
1.7.8.6
^ permalink raw reply related
* Re: Cabled PCIE device hotplug/hot-removal
From: Shlomo Pongratz @ 2012-07-31 14:59 UTC (permalink / raw)
To: Kaneshige, Kenji
Cc: Greg KH, linux-pci@vger.kernel.org, linux-hotplug@vger.kernel.org
In-Reply-To: <4A338DB2991D2A44B9A44B8718AECF650A477A44@G01JPEXMBYT03>
On Tue, Jul 31, 2012 at 2:02 PM, Kaneshige, Kenji
<kaneshige.kenji@jp.fujitsu.com> wrote:
>> -----Original Message-----
>> From: linux-pci-owner@vger.kernel.org
>> [mailto:linux-pci-owner@vger.kernel.org] On Behalf Of Shlomo Pongratz
>> Sent: Sunday, July 29, 2012 9:36 PM
>> To: Greg KH
>> Cc: linux-pci@vger.kernel.org; linux-hotplug@vger.kernel.org
>> Subject: Re: Cabled PCIE device hotplug/hot-removal
>>
>> On Thu, Jul 26, 2012 at 8:09 PM, Greg KH <greg@kroah.com> wrote:
>> > On Thu, Jul 26, 2012 at 08:03:09PM +0300, Shlomo Pongratz wrote:
>> >> Hi,
>> >>
>> >> I have a PCIe device connected with cables to a host (kernel 3.5.0-rc7+).
>> >> What are the handler I need to add to a driver in order to catch cable
>> >> pull-out / push-in?
>> >
>> > You shouldn't need anything special, aren't you already getting probe
>> > and disconnect callbacks when the device is discovered and removed?
>>
>
> Note that if the controller doesn't support "surprise removal", pciehp does
> nothing (just print a message) when plugging/unplugging the device. You need
> to power on the slot by "echo 1 > /sys/bus/pci/slots/XXX/power" after plugging
> the device. By this, pciehp will power on the slot and driver's .prove
> callback will be called. And for removal, you need to
> "echo 0 > /sys/bus/pci/slots/XXX/power" before unplugging the device. By doing
> this, driver's .remove callback will be called and then pciehp will power
> down the slot.
>
> If the controller supports "surprise removal" driver's .probe/.remove callbacks
> are called automatically by the pciehp's event handler when plugging/unplugging
> event (presence change detect event) happens.
>
>
>> When the device is loaded the probe is called
>> When I "echo 1" to the remove sysfs entry the remove callback is called.
>> But when I power down the card no callback is called.
>
> You need to "echo 0 > /sys/bus/pci/slots/XXX/power" to remove the device
> if you are using pciehp.
>
>
>> >
>> >> The pcisig presentation
>> >>
>> "http://www.pcisig.com/developers/main/training_materials/get_document
>> ?doc_idôca40ec1721aa7fadd05e2903b0172c36656294"
>> >> talks about PERST# detection for cabled PCIe hotplug.
>> >>
>> >> Does the kernel detect it?
>> >>
>> >> None of the pci_driver or pci_error_handlers callbacks were called
>> >> when using powered down/up the device (electrically).
>
> How did you power down/up the device (electrically)?
>
>> >
>> > Do you have the pciehp driver loaded properly when this happens?
>>
>> My {dot}config includes it into the kernel, i.e.
>> CONFIG_HOTPLUG_PCI_PCIE=y
>>
>
> You can see what kind of hot-plug driver manages the slot by checking
> /sys/bus/pci/slots/XXX/module symbolic link. On my system which has some
> PCIe hot-plug slots, I can see the following
>
> $ ls /sys/bus/pci/slots/* -l
> /sys/bus/pci/slots/21:
> total 0
> -r--r--r--. 1 root root 4096 Aug 1 02:55 adapter
> -r--r--r--. 1 root root 4096 Aug 1 02:55 address
> -rw-r--r--. 1 root root 4096 Aug 1 02:55 attention
> -r--r--r--. 1 root root 4096 Aug 1 02:55 cur_bus_speed
> -r--r--r--. 1 root root 4096 Aug 1 02:55 latch
> -r--r--r--. 1 root root 4096 Aug 1 02:55 max_bus_speed
> lrwxrwxrwx. 1 root root 0 Aug 1 02:55 module -> ../../../../module/pciehp
> -rw-r--r--. 1 root root 4096 Aug 1 02:55 power
>
> /sys/bus/pci/slots/22:
> <snip.>
>
> And pciehp_debug option might help you. With this option, you can get the
> controller infomation like below.
>
> pciehp 0000:0d:00.0:pcie24: Hotplug Controller:
> pciehp 0000:0d:00.0:pcie24: Seg/Bus/Dev/Func/IRQ : 0000:0d:00.0 IRQ 51
> pciehp 0000:0d:00.0:pcie24: Vendor ID : 0x111d
> pciehp 0000:0d:00.0:pcie24: Device ID : 0x807f
> pciehp 0000:0d:00.0:pcie24: Subsystem ID : 0x159c
> pciehp 0000:0d:00.0:pcie24: Subsystem Vendor ID : 0x10cf
> pciehp 0000:0d:00.0:pcie24: PCIe Cap offset : 0x40
> pciehp 0000:0d:00.0:pcie24: PCI resource [14] : [mem 0x92a00000-0x92bfffff]
> pciehp 0000:0d:00.0:pcie24: PCI resource [15] : [mem 0x92000000-0x921fffff 64bit pref]
> pciehp 0000:0d:00.0:pcie24: Slot Capabilities : 0x00a8005e
> pciehp 0000:0d:00.0:pcie24: Physical Slot Number : 21
> pciehp 0000:0d:00.0:pcie24: Attention Button : no
> pciehp 0000:0d:00.0:pcie24: Power Controller : yes
> pciehp 0000:0d:00.0:pcie24: MRL Sensor : yes
> pciehp 0000:0d:00.0:pcie24: Attention Indicator : yes
> pciehp 0000:0d:00.0:pcie24: Power Indicator : yes
> pciehp 0000:0d:00.0:pcie24: Hot-Plug Surprise : no
> pciehp 0000:0d:00.0:pcie24: EMI Present : no
> pciehp 0000:0d:00.0:pcie24: Command Completed : yes
> pciehp 0000:0d:00.0:pcie24: Slot Status : 0x0000
> pciehp 0000:0d:00.0:pcie24: Slot Control : 0x07c0
> pciehp 0000:0d:00.0:pcie24: Link Active Reporting supported
>
> Regards,
> Kenji Kaneshige
>
O.K. so if using lspci -vvv is see that with the PCI-bridge the slot
capability is marked with minus in the support surprise mode I need to
get another system.
That is
Capabilities: [6c] Express (v2) Root Port (Slot+), MSI 00
.....
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surpise-
Slot # 0, PowerLimit 0.000000; Interlock- NoCompl-
^ permalink raw reply
* RE: Cabled PCIE device hotplug/hot-removal
From: Kaneshige, Kenji @ 2012-07-31 11:02 UTC (permalink / raw)
To: Shlomo Pongratz, Greg KH
Cc: linux-pci@vger.kernel.org, linux-hotplug@vger.kernel.org
In-Reply-To: <CAHzK-V0idPrHhf-YuC_HAxxxQABExW7mUUWN31f-ZpdnC8W+GA@mail.gmail.com>
> -----Original Message-----
> From: linux-pci-owner@vger.kernel.org
> [mailto:linux-pci-owner@vger.kernel.org] On Behalf Of Shlomo Pongratz
> Sent: Sunday, July 29, 2012 9:36 PM
> To: Greg KH
> Cc: linux-pci@vger.kernel.org; linux-hotplug@vger.kernel.org
> Subject: Re: Cabled PCIE device hotplug/hot-removal
>
> On Thu, Jul 26, 2012 at 8:09 PM, Greg KH <greg@kroah.com> wrote:
> > On Thu, Jul 26, 2012 at 08:03:09PM +0300, Shlomo Pongratz wrote:
> >> Hi,
> >>
> >> I have a PCIe device connected with cables to a host (kernel 3.5.0-rc7+).
> >> What are the handler I need to add to a driver in order to catch cable
> >> pull-out / push-in?
> >
> > You shouldn't need anything special, aren't you already getting probe
> > and disconnect callbacks when the device is discovered and removed?
>
Note that if the controller doesn't support "surprise removal", pciehp does
nothing (just print a message) when plugging/unplugging the device. You need
to power on the slot by "echo 1 > /sys/bus/pci/slots/XXX/power" after plugging
the device. By this, pciehp will power on the slot and driver's .prove
callback will be called. And for removal, you need to
"echo 0 > /sys/bus/pci/slots/XXX/power" before unplugging the device. By doing
this, driver's .remove callback will be called and then pciehp will power
down the slot.
If the controller supports "surprise removal" driver's .probe/.remove callbacks
are called automatically by the pciehp's event handler when plugging/unplugging
event (presence change detect event) happens.
> When the device is loaded the probe is called
> When I "echo 1" to the remove sysfs entry the remove callback is called.
> But when I power down the card no callback is called.
You need to "echo 0 > /sys/bus/pci/slots/XXX/power" to remove the device
if you are using pciehp.
> >
> >> The pcisig presentation
> >>
> "http://www.pcisig.com/developers/main/training_materials/get_document
> ?doc_idôca40ec1721aa7fadd05e2903b0172c36656294"
> >> talks about PERST# detection for cabled PCIe hotplug.
> >>
> >> Does the kernel detect it?
> >>
> >> None of the pci_driver or pci_error_handlers callbacks were called
> >> when using powered down/up the device (electrically).
How did you power down/up the device (electrically)?
> >
> > Do you have the pciehp driver loaded properly when this happens?
>
> My {dot}config includes it into the kernel, i.e.
> CONFIG_HOTPLUG_PCI_PCIE=y
>
You can see what kind of hot-plug driver manages the slot by checking
/sys/bus/pci/slots/XXX/module symbolic link. On my system which has some
PCIe hot-plug slots, I can see the following
$ ls /sys/bus/pci/slots/* -l
/sys/bus/pci/slots/21:
total 0
-r--r--r--. 1 root root 4096 Aug 1 02:55 adapter
-r--r--r--. 1 root root 4096 Aug 1 02:55 address
-rw-r--r--. 1 root root 4096 Aug 1 02:55 attention
-r--r--r--. 1 root root 4096 Aug 1 02:55 cur_bus_speed
-r--r--r--. 1 root root 4096 Aug 1 02:55 latch
-r--r--r--. 1 root root 4096 Aug 1 02:55 max_bus_speed
lrwxrwxrwx. 1 root root 0 Aug 1 02:55 module -> ../../../../module/pciehp
-rw-r--r--. 1 root root 4096 Aug 1 02:55 power
/sys/bus/pci/slots/22:
<snip.>
And pciehp_debug option might help you. With this option, you can get the
controller infomation like below.
pciehp 0000:0d:00.0:pcie24: Hotplug Controller:
pciehp 0000:0d:00.0:pcie24: Seg/Bus/Dev/Func/IRQ : 0000:0d:00.0 IRQ 51
pciehp 0000:0d:00.0:pcie24: Vendor ID : 0x111d
pciehp 0000:0d:00.0:pcie24: Device ID : 0x807f
pciehp 0000:0d:00.0:pcie24: Subsystem ID : 0x159c
pciehp 0000:0d:00.0:pcie24: Subsystem Vendor ID : 0x10cf
pciehp 0000:0d:00.0:pcie24: PCIe Cap offset : 0x40
pciehp 0000:0d:00.0:pcie24: PCI resource [14] : [mem 0x92a00000-0x92bfffff]
pciehp 0000:0d:00.0:pcie24: PCI resource [15] : [mem 0x92000000-0x921fffff 64bit pref]
pciehp 0000:0d:00.0:pcie24: Slot Capabilities : 0x00a8005e
pciehp 0000:0d:00.0:pcie24: Physical Slot Number : 21
pciehp 0000:0d:00.0:pcie24: Attention Button : no
pciehp 0000:0d:00.0:pcie24: Power Controller : yes
pciehp 0000:0d:00.0:pcie24: MRL Sensor : yes
pciehp 0000:0d:00.0:pcie24: Attention Indicator : yes
pciehp 0000:0d:00.0:pcie24: Power Indicator : yes
pciehp 0000:0d:00.0:pcie24: Hot-Plug Surprise : no
pciehp 0000:0d:00.0:pcie24: EMI Present : no
pciehp 0000:0d:00.0:pcie24: Command Completed : yes
pciehp 0000:0d:00.0:pcie24: Slot Status : 0x0000
pciehp 0000:0d:00.0:pcie24: Slot Control : 0x07c0
pciehp 0000:0d:00.0:pcie24: Link Active Reporting supported
Regards,
Kenji Kaneshige
^ permalink raw reply
* Re: [PATCH SCSI] sr: check_events() ignore GET_EVENT when TUR says otherwise
From: Markus Rathgeb @ 2012-07-30 20:28 UTC (permalink / raw)
To: Kay Sievers; +Cc: James Bottomley, Tejun Heo, linux-scsi, linux-hotplug
In-Reply-To: <CAPXgP11xSaPnhO2xuXKSqar+k_PCxftgnRZiRjL=0ucFMe_fVw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1020 bytes --]
> I have 3.5 here and see the loop too, but it stops after a couple of seconds:
>
> first: KERNEL[15636.368034]
> last: KERNEL[15638.879796]
Ah, sorry then.
The udev messages reported by the udev monitor reported up to 20
seconds of udev (userspace) events. I did not filter kernel reported
messages.
# for SRC in KERNEL UDEV; do for CMD in head tail; do less udev.log |
grep ${SRC} | ${CMD} -n1; done; done
KERNEL[83579.700428] add /devices/pci0000:00/0000:00:04.1/usb5/5-4 (usb)
KERNEL[83582.989470] change
/devices/pci0000:00/0000:00:04.1/usb5/5-4/5-4:1.0/host31/target31:0:0/31:0:0:1/block/sr1
(block)
UDEV [83579.747646] add /devices/pci0000:00/0000:00:04.1/usb5/5-4 (usb)
UDEV [83601.504952] add
/devices/pci0000:00/0000:00:04.1/usb5/5-4/5-4:1.0/host31/target31:0:0/31:0:0:0/block/sdb/sdb1
(block)
I should also disable the dbus logging verbosity:
journald reported 494 complete dbus messages and 846 (475 + 371)
suppressed dbus messages.
That is really too much (but not your problem).
Thanks!!
[-- Attachment #2: journald.log.gz --]
[-- Type: application/x-gzip, Size: 2081 bytes --]
[-- Attachment #3: udev.log.gz --]
[-- Type: application/x-gzip, Size: 4540 bytes --]
^ permalink raw reply
* Re: [PATCH SCSI] sr: check_events() ignore GET_EVENT when TUR says otherwise
From: Kay Sievers @ 2012-07-30 19:41 UTC (permalink / raw)
To: Markus Rathgeb; +Cc: James Bottomley, Tejun Heo, linux-scsi, linux-hotplug
In-Reply-To: <CAOcK=CMPjZGNMiPS9LJMG6=t7sbLxjSkTikwRL2nhq6tewfofQ@mail.gmail.com>
On Mon, Jul 30, 2012 at 9:06 PM, Markus Rathgeb
<maggu2810@googlemail.com> wrote:
> Hello!
>
> Do you remember?
> I get it again, is there something I could do?
>
> I attached a file that contains the "udevadm monitor" log.
>
> I am using a v3.5.0 linux kernel (containing some gentoo patches).
> Should I test it with a vanilla one?
I have 3.5 here and see the loop too, but it stops after a couple of seconds:
first: KERNEL[15636.368034]
last: KERNEL[15638.879796]
The kernel log says:
[15634.066481] sr 13:0:0:1: GET_EVENT and TUR disagree continuously,
suppress GET_EVENT events
Kay
^ permalink raw reply
* Re: [PATCH SCSI] sr: check_events() ignore GET_EVENT when TUR says otherwise
From: Markus Rathgeb @ 2012-07-30 19:06 UTC (permalink / raw)
To: James Bottomley; +Cc: Kay Sievers, Tejun Heo, linux-scsi, linux-hotplug
In-Reply-To: <1311180316.8570.1.camel@mulgrave>
[-- Attachment #1: Type: text/plain, Size: 3109 bytes --]
Hello!
Do you remember?
I get it again, is there something I could do?
I attached a file that contains the "udevadm monitor" log.
I am using a v3.5.0 linux kernel (containing some gentoo patches).
Should I test it with a vanilla one?
Here the versions of some packages (kernel, udev, systemd):
sys-kernel/gentoo-sources-3.5.0
sys-fs/udev-186
sys-apps/systemd-44-r1
Here (again) the information about the two sticks I run in trouble
after plug them in:
# udevadm info --path=/block/sdb
P: /devices/pci0000:00/0000:00:04.1/usb5/5-4/5-4:1.0/host22/target22:0:0/22:0:0:0/block/sdb
N: sdb
S: disk/by-id/usb-SanDisk_Cruzer_07745302FB131CFA-0:0
S: disk/by-path/pci-0000:00:04.1-usb-0:4:1.0-scsi-0:0:0:0
E: DEVLINKS=/dev/disk/by-id/usb-SanDisk_Cruzer_07745302FB131CFA-0:0
/dev/disk/by-path/pci-0000:00:04.1-usb-0:4:1.0-scsi-0:0:0:0
E: DEVNAME=/dev/sdb
E: DEVPATH=/devices/pci0000:00/0000:00:04.1/usb5/5-4/5-4:1.0/host22/target22:0:0/22:0:0:0/block/sdb
E: DEVTYPE=disk
E: ID_BUS=usb
E: ID_DRIVE_THUMB=1
E: ID_INSTANCE=0:0
E: ID_MODEL=Cruzer
E: ID_MODEL_ENC=Cruzer\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20
E: ID_MODEL_ID=5406
E: ID_PART_TABLE_TYPE=dos
E: ID_PATH=pci-0000:00:04.1-usb-0:4:1.0-scsi-0:0:0:0
E: ID_PATH_TAG=pci-0000_00_04_1-usb-0_4_1_0-scsi-0_0_0_0
E: ID_REVISION=8.02
E: ID_SERIAL=SanDisk_Cruzer_07745302FB131CFA-0:0
E: ID_SERIAL_SHORT=07745302FB131CFA
E: ID_TYPE=disk
E: ID_USB_DRIVER=usb-storage
E: ID_USB_INTERFACES=:080650:
E: ID_USB_INTERFACE_NUM=00
E: ID_VENDOR=SanDisk
E: ID_VENDOR_ENC=SanDisk\x20
E: ID_VENDOR_ID=0781
E: LVM_SBIN_PATH=/sbin
E: MAJOR=8
E: MINOR=16
E: SUBSYSTEM=block
E: TAGS=:systemd:
E: UDISKS_PARTITION_TABLE=1
E: UDISKS_PARTITION_TABLE_COUNT=1
E: UDISKS_PARTITION_TABLE_SCHEME=mbr
E: UDISKS_PRESENTATION_NOPOLICY=0
E: USEC_INITIALIZED=79287950141
# udevadm info --path=/block/sdb
P: /devices/pci0000:00/0000:00:04.1/usb5/5-4/5-4:1.0/host23/target23:0:0/23:0:0:0/block/sdb
N: sdb
S: disk/by-id/usb-SanDisk_Cruzer_22427202FB10CD97-0:0
S: disk/by-path/pci-0000:00:04.1-usb-0:4:1.0-scsi-0:0:0:0
E: DEVLINKS=/dev/disk/by-id/usb-SanDisk_Cruzer_22427202FB10CD97-0:0
/dev/disk/by-path/pci-0000:00:04.1-usb-0:4:1.0-scsi-0:0:0:0
E: DEVNAME=/dev/sdb
E: DEVPATH=/devices/pci0000:00/0000:00:04.1/usb5/5-4/5-4:1.0/host23/target23:0:0/23:0:0:0/block/sdb
E: DEVTYPE=disk
E: ID_BUS=usb
E: ID_DRIVE_THUMB=1
E: ID_INSTANCE=0:0
E: ID_MODEL=Cruzer
E: ID_MODEL_ENC=Cruzer\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20
E: ID_MODEL_ID=5406
E: ID_PART_TABLE_TYPE=dos
E: ID_PATH=pci-0000:00:04.1-usb-0:4:1.0-scsi-0:0:0:0
E: ID_PATH_TAG=pci-0000_00_04_1-usb-0_4_1_0-scsi-0_0_0_0
E: ID_REVISION=8.02
E: ID_SERIAL=SanDisk_Cruzer_22427202FB10CD97-0:0
E: ID_SERIAL_SHORT=22427202FB10CD97
E: ID_TYPE=disk
E: ID_USB_DRIVER=usb-storage
E: ID_USB_INTERFACES=:080650:
E: ID_USB_INTERFACE_NUM=00
E: ID_VENDOR=SanDisk
E: ID_VENDOR_ENC=SanDisk\x20
E: ID_VENDOR_ID=0781
E: LVM_SBIN_PATH=/sbin
E: MAJOR=8
E: MINOR=16
E: SUBSYSTEM=block
E: TAGS=:systemd:
E: UDISKS_PARTITION_TABLE=1
E: UDISKS_PARTITION_TABLE_COUNT=1
E: UDISKS_PARTITION_TABLE_SCHEME=mbr
E: UDISKS_PRESENTATION_NOPOLICY=0
E: USEC_INITIALIZED=342063581
[-- Attachment #2: insert-stick.log.gz --]
[-- Type: application/x-gzip, Size: 4558 bytes --]
^ permalink raw reply
* Re: Cabled PCIE device hotplug/hot-removal
From: Greg KH @ 2012-07-29 14:59 UTC (permalink / raw)
To: Shlomo Pongratz; +Cc: linux-pci, linux-hotplug
In-Reply-To: <CAHzK-V0idPrHhf-YuC_HAxxxQABExW7mUUWN31f-ZpdnC8W+GA@mail.gmail.com>
On Sun, Jul 29, 2012 at 03:36:09PM +0300, Shlomo Pongratz wrote:
> On Thu, Jul 26, 2012 at 8:09 PM, Greg KH <greg@kroah.com> wrote:
> > On Thu, Jul 26, 2012 at 08:03:09PM +0300, Shlomo Pongratz wrote:
> >> Hi,
> >>
> >> I have a PCIe device connected with cables to a host (kernel 3.5.0-rc7+).
> >> What are the handler I need to add to a driver in order to catch cable
> >> pull-out / push-in?
> >
> > You shouldn't need anything special, aren't you already getting probe
> > and disconnect callbacks when the device is discovered and removed?
>
> When the device is loaded the probe is called
> When I "echo 1" to the remove sysfs entry the remove callback is called.
> But when I power down the card no callback is called.
Then I would blame your pci hotplug controller, that is its
responsibility.
> >> The pcisig presentation
> >> "http://www.pcisig.com/developers/main/training_materials/get_document?doc_idôca40ec1721aa7fadd05e2903b0172c36656294"
> >> talks about PERST# detection for cabled PCIe hotplug.
> >>
> >> Does the kernel detect it?
> >>
> >> None of the pci_driver or pci_error_handlers callbacks were called
> >> when using powered down/up the device (electrically).
> >
> > Do you have the pciehp driver loaded properly when this happens?
>
> My {dot}config includes it into the kernel, i.e.
> CONFIG_HOTPLUG_PCI_PCIE=y
And is it working properly? Does your hardware support this (i.e. your
BIOS?)
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