headers
Nils Carlson | 2 Apr 2012 14:56
Picon
Favicon

[PATCH] path_id: Re-introduce SAS phy enumeration of devices

When path_id was converted to C code the enumeration of SAS
devices by phy disappeared. This patch reintroduces enumeration
of the form

pci-0000:05:00.0-sas-phy0:1-0x500000e114de2b42:0-lun0

where phy0:1 is the reintroduced substring where 0 corresponds
to the lowest phy identifier on the port to which the device
is connected and 1 is the number of phys on the port.

Please test this patch thoroughly as it has only been tested
with an older version of udev.

Signed-off-by: Nils Carlson <nils.carlson <at> ericsson.com>
---
 src/udev-builtin-path_id.c |   80 +++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 79 insertions(+), 1 deletion(-)

diff --git a/src/udev-builtin-path_id.c b/src/udev-builtin-path_id.c
index a8559d2..c575fd4 100644
--- a/src/udev-builtin-path_id.c
+++ b/src/udev-builtin-path_id.c
 <at>  <at>  -121,13 +121,67  <at>  <at>  out:
         return parent;
 }

+static int get_sas_port_phy_id(struct udev *udev, const char *phy_name)
+{
+        struct udev_device *phydev;
+        const char *phy_id_str;
(Continue reading)

Permalink | Reply | 2 comments |
headers
Hannes Reinecke | 2 Apr 2012 15:35
Picon

Re: [PATCH] path_id: Re-introduce SAS phy enumeration of devices

Hi Nils,

Thanks a lot for this. It definitely a step in the correct
direction. However, I have some comments to make:

On 04/02/2012 02:56 PM, Nils Carlson wrote:
> When path_id was converted to C code the enumeration of SAS
> devices by phy disappeared. This patch reintroduces enumeration
> of the form
> 
> pci-0000:05:00.0-sas-phy0:1-0x500000e114de2b42:0-lun0
> 
> where phy0:1 is the reintroduced substring where 0 corresponds
> to the lowest phy identifier on the port to which the device
> is connected and 1 is the number of phys on the port.
> 
I would rather not do this.
First of all, I doubt we need the overall number of phys here.
Secondly, James B. assured me that the phy enumeration is pretty much
stable, so we should be able to use that number as-is.

Also, there is a 1:1 match between the 'phy_identifier' sysfs attribute
and the second number of the phy name itself (the first number is the
SCSI host number), so we could as well just parse the phy name and get
the number from there.
But, of course, reading the phy_identifier is okay, too.

So I would propose just to insert a 'phy1' there.

But again, thanks for doing it.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Nils Carlson | 2 Apr 2012 15:55
Picon
Favicon

Re: [PATCH] path_id: Re-introduce SAS phy enumeration of devices

Hi Hannes,

On 04/02/2012 03:35 PM, Hannes Reinecke wrote:
> Hi Nils,
>
> Thanks a lot for this. It definitely a step in the correct
> direction. However, I have some comments to make:
>
> On 04/02/2012 02:56 PM, Nils Carlson wrote:
>> where phy0:1 is the reintroduced substring where 0 corresponds
>> to the lowest phy identifier on the port to which the device
>> is connected and 1 is the number of phys on the port.
>>
> I would rather not do this.
> First of all, I doubt we need the overall number of phys here.
> Secondly, James B. assured me that the phy enumeration is pretty much
> stable, so we should be able to use that number as-is.

I agree this would be clean, the problem is that it represents an API 
change; one could argue though that that API change has already been 
made through the breakage though.

> Also, there is a 1:1 match between the 'phy_identifier' sysfs attribute
> and the second number of the phy name itself (the first number is the
> SCSI host number), so we could as well just parse the phy name and get
> the number from there.
> But, of course, reading the phy_identifier is okay, too

Yes, this would of course also work, though I think reading the 
phy_identifier is cleaner.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark K. Zanfardino | 2 Apr 2012 21:25
Picon
Gravatar

Re: udev hangs during boot (arch linux on thinkpad w520)

List,

I'm running Arch Linux (3.2.13-1-ARCH) on a Lenovo ThinkPad W520 laptop 
(I can provide exact specs if required). I have installed udev 181-5 
(from base repo). My bootloader is GRUB 0.97. The system will hang 
during the boot sequence during "Waiting for UDev uevents to be processed".

Per Kay in #udev I have added 'udev.children-max=1 udev.exec-delay=1 
udev.log-priority=debug' to my kernel loader in an effort to identify 
the source of the problem.  The system hangs perhaps 8 out of 10 boot 
attempts.  The output appears to be different each time it hangs.  I 
have tried several different combinations of kernel options and have 
disabled wifi (through the switch) in an effort to isolate the source of 
the problem, to no avail.

On the occasions when the system boots completely I have access to 
whatever log files might be helpful and will be happy to provide them.  
In an effort to provide some additional information, I have posted my 
"/var/log/everything.log" to http://codepad.org/rQww028u. I realize that 
this is everything from my logs and as such might be overwhelming.  
Please let me know specifically what I can provide to help resolve this 
issue.

Cheers!
Mark
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 2 comments |
headers
Mark K. Zanfardino | 2 Apr 2012 21:36
Picon
Gravatar

Re: udev hangs during boot (arch linux on thinkpad w520) (UPDATE)

List,

I have also copied the output from lspci -k to
http://codepad.org/JLVJ0OXr

Cheers!
Mark
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Nils Carlson | 3 Apr 2012 10:04
Picon
Favicon

[PATCH] path_id: Re-introduce SAS phy enumeration of devices v2

Changes since v1:
* Remove the number of phys from the output
* Extract the phy identifier from the symlink, less code.

When path_id was converted to C code the enumeration of SAS
devices by phy disappeared. This patch reintroduces enumeration
of the form

pci-0000:05:00.0-sas-phy0-0x500000e114de2b42:0-lun0

where phy0 is the reintroduced substring where 0 corresponds
to the lowest phy identifier on the port to which the device
is connected.

Please test this patch thoroughly as it has only been tested
with an older version of udev.

Signed-off-by: Nils Carlson <nils.carlson <at> ericsson.com>
---
 src/udev-builtin-path_id.c |   30 +++++++++++++++++++++++++++++-
 1 file changed, 29 insertions(+), 1 deletion(-)

diff --git a/src/udev-builtin-path_id.c b/src/udev-builtin-path_id.c
index a8559d2..54b22c4 100644
--- a/src/udev-builtin-path_id.c
+++ b/src/udev-builtin-path_id.c
 <at>  <at>  -127,7 +127,10  <at>  <at>  static struct udev_device *handle_scsi_sas(struct udev_device *parent, char **pa
         struct udev_device *targetdev;
         struct udev_device *target_parent;
         struct udev_device *sasdev;
(Continue reading)

Permalink | Reply | 3 comments |
headers
Kay Sievers | 3 Apr 2012 18:15
Gravatar

The future of the udev source tree

We are about to merge the udev sources into the systemd source tree.
After that, the next version of systemd will continue with udev’s
version numbering, i.e. jump immediately from 45 to 184.

After udev is merged into the systemd tree you can still build it for
usage outside of systemd systems, and we will support these builds
officially. In fact, we will be supporting this for a long time since
it is a necessity to make initrds (which lack systemd) work properly.
Distributions not wishing to adopt systemd can build udev pretty much
the same way as before, however should then use the systemd tarball
instead of the udev tarball and package only what is necessary of the
resulting build.

Today, ‘Init’ needs to be fully hotplug-capable; udev device
management and knowledge about device lifecycles is an integral part
of systemd and not an isolated logic. Due to this, and to minimize our
administrative workload, as well as to minimize duplication of code,
and to resolve cyclic build dependencies in the core OS, we have
decided to merge the two projects.

The udev built from the systemd source tree will stay compatible with
non-systemd init systems for a long time. This change is mostly a
detail of the build scheme, rather than a change of direction or
interfaces. Accordingly, the libudev API is untouched by these build
infrastructure changes. For us, compatibility is key.
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 3 comments |
headers
Greg KH | 3 Apr 2012 18:18
Favicon
Gravatar

Re: The future of the udev source tree

On Tue, Apr 03, 2012 at 06:15:13PM +0200, Kay Sievers wrote:
> We are about to merge the udev sources into the systemd source tree.
> After that, the next version of systemd will continue with udev’s
> version numbering, i.e. jump immediately from 45 to 184.

Great job on this, it makes a lot of sense.

One basic question, will the git tree location change?  If so, where is
the new one going to be at?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
Kay Sievers | 3 Apr 2012 18:22
Gravatar

Re: The future of the udev source tree

On Tue, Apr 3, 2012 at 18:18, Greg KH <gregkh <at> linuxfoundation.org> wrote:
> On Tue, Apr 03, 2012 at 06:15:13PM +0200, Kay Sievers wrote:
>> We are about to merge the udev sources into the systemd source tree.
>> After that, the next version of systemd will continue with udev’s
>> version numbering, i.e. jump immediately from 45 to 184.
>
> Great job on this, it makes a lot of sense.
>
> One basic question, will the git tree location change?  If so, where is
> the new one going to be at?

It's the systemd tree at:
  http://cgit.freedesktop.org/systemd/systemd/

Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Tom Gundersen | 3 Apr 2012 19:16
Picon
Gravatar

Re: The future of the udev source tree

On Tue, Apr 3, 2012 at 6:15 PM, Kay Sievers <kay <at> vrfy.org> wrote:
> We are about to merge the udev sources into the systemd source tree.
> After that, the next version of systemd will continue with udev’s
> version numbering, i.e. jump immediately from 45 to 184.

Thanks for the explanation. When I first heard about this I was
skeptical, but now it makes perfect sense.

Cheers,

Tom
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |

Gmane