* Re: Udev rule for Digi Edgeport 8 (multi-port USB-serial adapter)
From: Philip Tait @ 2010-08-05 22:10 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=ge3Qkenj3bxgZth9gZdvQnaLvBCu54H7Ki=d2@mail.gmail.com>
On Thu, Aug 5, 2010 at 09:20, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Thu, Aug 5, 2010 at 21:05, Philip Tait <philip@naoj.org> wrote:
>> Is it safe to update Udev to a newer version that has this capability
>> (say 146), (I have to keep the same kernel version), or is it better
>> to try to update the rules to implement this feature with version 125?
>
> It's entirely distro specific what will happen if you replace the
> stock version, nobody will really be able to tell for sure what would
> happen, I guess.
>
> Maybe the rules can be backported to the old version. Here is the change:
> http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h¼4c751802147f1ff21bf52a57a2976754949453
Yes, they did back-port successfully! Problem solved - many thanks.
--
Philip J. Tait
Software Engineer, FMOS
http://subarutelescope.org
^ permalink raw reply
* Re: Udev rule for Digi Edgeport 8 (multi-port USB-serial adapter)
From: Kay Sievers @ 2010-08-05 19:24 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=ge3Qkenj3bxgZth9gZdvQnaLvBCu54H7Ki=d2@mail.gmail.com>
On Thu, Aug 5, 2010 at 21:18, Philip Tait <philip@naoj.org> wrote:
> On Thu, Aug 5, 2010 at 04:50, Greg KH <greg@kroah.com> wrote:
>> On Wed, Aug 04, 2010 at 04:21:35PM -1000, Philip Tait wrote:
>>> I'm using 2.6.31 - that's pretty recent, right?
>>
>> That's a kernel version, not a udev version :)
>>
>> And even then, no, it's almost a year old, pretty old for a kernel
>> release.
>>
>>> Do you know why '%e' was eliminated?
>>
>> What does the changelog say?
>
> The changelog in the openSUSE udev 146-3.3.1 package goes back to
> 2006-07-04 - I could see no mention of %e being removed. However,
> thanks to Kay's suggestion, seems like it is a moot point.
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h¿82b99acbc4b25fd133a88bfabf68eee23d7b0b
It's just that it produced completely unpredictable results if you
have multiple devices. There was no defined ordering.
It's basically the same problem as the uselessness of the kernel
device number, just all done again in userspace.
Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Udev rule for Digi Edgeport 8 (multi-port USB-serial adapter)
From: Kay Sievers @ 2010-08-05 19:20 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=ge3Qkenj3bxgZth9gZdvQnaLvBCu54H7Ki=d2@mail.gmail.com>
On Thu, Aug 5, 2010 at 21:05, Philip Tait <philip@naoj.org> wrote:
> Is it safe to update Udev to a newer version that has this capability
> (say 146), (I have to keep the same kernel version), or is it better
> to try to update the rules to implement this feature with version 125?
It's entirely distro specific what will happen if you replace the
stock version, nobody will really be able to tell for sure what would
happen, I guess.
Maybe the rules can be backported to the old version. Here is the change:
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h¼4c751802147f1ff21bf52a57a2976754949453
Kay
^ permalink raw reply
* Re: Udev rule for Digi Edgeport 8 (multi-port USB-serial adapter)
From: Philip Tait @ 2010-08-05 19:18 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=ge3Qkenj3bxgZth9gZdvQnaLvBCu54H7Ki=d2@mail.gmail.com>
On Thu, Aug 5, 2010 at 04:50, Greg KH <greg@kroah.com> wrote:
> On Wed, Aug 04, 2010 at 04:21:35PM -1000, Philip Tait wrote:
>> I'm using 2.6.31 - that's pretty recent, right?
>
> That's a kernel version, not a udev version :)
>
> And even then, no, it's almost a year old, pretty old for a kernel
> release.
>
>> Do you know why '%e' was eliminated?
>
> What does the changelog say?
The changelog in the openSUSE udev 146-3.3.1 package goes back to
2006-07-04 - I could see no mention of %e being removed. However,
thanks to Kay's suggestion, seems like it is a moot point.
>> I've been doing some more reading, and wondered if I need to do an
>> IMPORT{parent} somewhere, so that my rule sees the 'port-num' and
>> 'serial' attributes at the same time. Not sure how to find out what
>> value to use for 'parent', though...
>
> As Kay points out, what's wrong with /dev/serial/ ? That should provide
> you with a persistant link for serial devices like this.
/dev/serial/by-id/* is perfect for my needs - I had no idea it was
there! I just need to figure out the safest way to update a Debian
Lenny configuration to get that working.
Thanks,
--
Philip J. Tait
Software Engineer, FMOS
http://subarutelescope.org
^ permalink raw reply
* Re: Udev rule for Digi Edgeport 8 (multi-port USB-serial adapter)
From: Philip Tait @ 2010-08-05 19:05 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=ge3Qkenj3bxgZth9gZdvQnaLvBCu54H7Ki=d2@mail.gmail.com>
On Wed, Aug 4, 2010 at 18:32, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Thu, Aug 5, 2010 at 03:45, Philip Tait <philip@naoj.org> wrote:
>> I have been trying to overcome the loss of the '%e' enumeration
>> variable to make a version of the Edgeport rules that will work with
>> the current version of Udev.
>>
>> Old version:
>>
>> BUS="usb" SYSFS{idVendor}="1608" SYSFS{idProduct}="0244"
>> SYSFS{serial}="*-0" NAME="%k" SYMLINK="ttyEDGE8_0_%e"
>> BUS="usb" SYSFS{idVendor}="1608" SYSFS{idProduct}="0244"
>> SYSFS{serial}="*-1" NAME="%k" SYMLINK="ttyEDGE8_1_%e"
>>
>> Replacing it with '%m" doesn't work, because then the numbering is
>> dependent on the presence of other USB-serial devices.
>>
>> I tried this:
>>
>> ENV{portnum}=ATTRS{port_number}
>> BUS="usb",SYSFS{idVendor}="1608",SYSFS{idProduct}="0244",SYSFS{serial}="I01846004-0",
>> NAME="%k",SYMLINK="ttyEDGE8_%E{portnum}"`
>> BUS="usb",SYSFS{idVendor}="1608",SYSFS{idProduct}="0244",SYSFS{serial}="I01846004-1",
>> NAME="%k",SYMLINK="ttyEDGE8_%E{portnum}"`
>> BUS="usb",SYSFS{idVendor}="1608",SYSFS{idProduct}="0244",SYSFS{serial}="I01846004-2",
>> NAME="%k",SYMLINK="ttyEDGE8_%E{portnum}"`
>> BUS="usb",SYSFS{idVendor}="1608",SYSFS{idProduct}="0244",SYSFS{serial}="I01846004-3",
>> NAME="%k",SYMLINK="ttyEDGE8_%E{portnum}"`
>>
>> but this didn't work, I think because the 'port_number' attribute is
>> defined at a different hierarchical level than the 'serial' attribute:
>
> I guess that's all covered by the standard: /dev/serial/by-*/.
It certainly is! Thanks for the pointer, I had no idea that
capability had been added.
I need to have this functionality on a system running Udev version
125, kernel version 2.6.26
Is it safe to update Udev to a newer version that has this capability
(say 146), (I have to keep the same kernel version), or is it better
to try to update the rules to implement this feature with version 125?
--
Philip J. Tait
Software Engineer, FMOS
http://subarutelescope.org
^ permalink raw reply
* Re: Smartphone support
From: Juanje Ojeda @ 2010-08-05 18:57 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTiklEFos5eEEBSofWzLFWUbxvUvqgS-ZssTeumxI@mail.gmail.com>
2010/8/5 Kay Sievers <kay.sievers@vrfy.org>:
> On Thu, Aug 5, 2010 at 18:34, Juanje Ojeda <jojeda@emergya.es> wrote:
>
>> Did anyone check this patch? Any questions, advises, anything?
>
> I'll actually remove all these specific hardware lists for ACLs from
> udev, we should do only do classes of devices, not individual pieces
> of hardware.
>
> There is no way for us to manage this in the long term, and it needs
> to be thought through what we want here, but it surely isn't a list of
> phones in the udev source tarball installed on all systems. :)
That's true, it's very realistic to try to mantain the list in the
long term. I hope there will be a way to manage those devices.
Thanks for your answer :-)
--
Juanje Ojeda
^ permalink raw reply
* Re: Smartphone support
From: Juanje Ojeda @ 2010-08-05 18:55 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTiklEFos5eEEBSofWzLFWUbxvUvqgS-ZssTeumxI@mail.gmail.com>
2010/8/5 Jim Paris <jim@jtan.com>:
> Juanje Ojeda wrote:
>> Hi
>>
>> Did anyone check this patch? Any questions, advises, anything?
>
> This seems WAY too generic.
>
>> +SUBSYSTEM="usb", ATTR{idVendor}="04e8", TAG+="udev-acl" # Sansung
>
> For example, from http://www.linux-usb.org/usb.ids, this would cover
> all of the devices listed below.
[...]
Yeah, I'm afraid so... :-/
Thanks :-)
--
Juanje Ojeda
^ permalink raw reply
* Re: Smartphone support
From: Kay Sievers @ 2010-08-05 16:54 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTiklEFos5eEEBSofWzLFWUbxvUvqgS-ZssTeumxI@mail.gmail.com>
On Thu, Aug 5, 2010 at 18:34, Juanje Ojeda <jojeda@emergya.es> wrote:
> Did anyone check this patch? Any questions, advises, anything?
I'll actually remove all these specific hardware lists for ACLs from
udev, we should do only do classes of devices, not individual pieces
of hardware.
There is no way for us to manage this in the long term, and it needs
to be thought through what we want here, but it surely isn't a list of
phones in the udev source tarball installed on all systems. :)
Kay
^ permalink raw reply
* Re: Smartphone support
From: Jim Paris @ 2010-08-05 16:50 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTiklEFos5eEEBSofWzLFWUbxvUvqgS-ZssTeumxI@mail.gmail.com>
Juanje Ojeda wrote:
> Hi
>
> Did anyone check this patch? Any questions, advises, anything?
This seems WAY too generic.
> +SUBSYSTEM="usb", ATTR{idVendor}="04e8", TAG+="udev-acl" # Sansung
For example, from http://www.linux-usb.org/usb.ids, this would cover
all of the devices listed below.
-jim
04e8 Samsung Electronics Co., Ltd
0100 Kingston Flash Drive (128MB)
0110 Connect3D Flash Drive
0111 Connect3D Flash Drive
1003 MP3 Player and Recorder
1006 SDC-200Z
2018 WIS09ABGN LinkStick Wireless LAN Adapter
2035 Digital Photo Frame Mass Storage
2036 Digital Photo Frame Mini Monitor
3004 ML-4600
3005 Docuprint P1210
3008 ML-6060 laser printer
300c ML-1210 Printer
300e Laser Printer
3104 ML-3550N
3210 ML-5200A Laser Printer
3226 Laser Printer
3228 Laser Printer
322a Laser Printer
322c Laser Printer
3230 ML-1440
3232 Laser Printer
3236 ML-1450
3238 ML-1430
323a ML-1710 Printer
323b Phaser 3130
323c Laser Printer
323d Phaser 3120
323e Laser Printer
3240 Laser Printer
3242 ML-1510 Laser Printer
3248 Color Laser Printer
324a Laser Printer
324c ML-1740 Printer
324d Phaser 3121
325b Xerox Phaser 3117 Laser Printer
325f Phaser 3425 Laser Printer
3260 CLP-510 Color Laser Printer
3268 ML-1610 Mono Laser Printer
326c ML-2010P Mono Laser Printer
3276 ML-3050/ML-3051 Laser Printer
328e CLP-310 Color Laser Printer
3296 ML-2580N Mono Laser Printer
3409 SCX-4216F Scanner
340c SCX-5x15 series
340d SCX-6x20 series
340e MFP 560 series
340f Printing Support
3412 SCX-4x20 series
3413 SCX-4100 Scanner
3415 Composite Device
3419 Composite Device
341a Printing Support
341b SCX-4200 series
341c Composite Device
341d Composite Device
341f Composite Device
3420 Composite Device
3426 SCX-4500 Laser Printer
3605 InkJet Color Printer
3606 InkJet Color Printer
3609 InkJet Color Printer
3902 InkJet Color Printer
3903 Xerox WorkCentre XK50cx
390f InkJet Color Printer
3911 SCX-1020 series
5000 YP-MF series
5001 YP-100
5002 YP-30
5003 YP-700
5004 YP-30
5005 YP-300
5006 YP-750
500d MP3 Player
5010 MP3 Player
5011 YP-780
5013 YP-60
5015 yepp upgrade
501b MP3 Player
503b YP-U1 MP3 Player
5050 YP-U2 MP3 Player
507d YP-U3 MP3 Player
508b YP-S5 MP3 Player
5a00 YP-NEU
5a01 YP-NDU
5a03 Yepp MP3 Player
5a04 YP-800
5a08 YP-90
5a0f MTP Device
5b01 Memory Stick Reader/Writer
5b02 Memory Stick Reader/Writer
5b03 Memory Stick Reader/Writer
5b04 Memory Stick Reader/Writer
5b05 Memory Stick Reader/Writer
5b11 SEW-2001u Card
5f00 NEXiO Sync
5f01 NEXiO Sync
5f02 NEXiO Sync
5f03 NEXiO Sync
5f04 NEXiO Sync
6601 Z100 Mobile Phone
6611 MITs Sync
6613 MITs Sync
6615 MITs Sync
6617 MITs Sync
6619 MITs Sync
661b MITs Sync
661e Handheld
6620 Handheld
6622 Handheld
6624 Handheld
662e MITs Sync
6630 MITs Sync
6632 MITs Sync
663e D900e Phone
663f SGH-E720/SGH-E840
6640 Usb Modem Enumerator
6708 U600 Phone
6759 D900e Media Player
675a D900e Mass Storage
675b D900e Camera
6795 S5230
681c Galaxy Portal/Spica Android Phone
681d Galaxy Portal/Spica Android Phone
7011 SEW-2003U Card
7021 Bluetooth Device
7061 eHome Infrared Receiver
7080 Anycall SCH-W580
7081 Human Interface Device
8001 Handheld
e020 SERI E02 SCOM 6200 UMTS Phone
e021 SERI E02 SCOM 6200 Virtual UARTs
e022 SERI E02 SCOM 6200 Flash Load Disk
ff30 SG_iMON
^ permalink raw reply
* Re: Smartphone support
From: Juanje Ojeda @ 2010-08-05 16:34 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTiklEFos5eEEBSofWzLFWUbxvUvqgS-ZssTeumxI@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1239 bytes --]
Hi
Did anyone check this patch? Any questions, advises, anything?
Thanks in advance :-)
2010/7/1 Juanje Ojeda <jojeda@emergya.es>:
> Hi guys :-)
>
> I was trying to debug my Android based phone (Nexus One) and I found
> that I needed some extra permissions. I also found a bug about it[1]
> which was solved by adding ACL to the specific model so it could work.
> This change was made at revision 4fe41ac at the 70-acl.rules file.
>
> The problem with that is that the line has idVendor and idProduct, so
> the new models from the same vendor (HTC) are not supported. But there
> are new vendors with a lot of models. The list is almost (the Nexus
> One is missing) updated at the Android developer site:
> http://developer.android.com/guide/developing/device.html#VendorIds
>
> I think if we left just the idVendor we won't need to update the list
> so much and the list will keep sorter.
> I've removed the idProduct and added the whole list of vendors and
> works for me. With my Nexus One. It should be working with any HTC,
> Motorola, etc with Android.
>
> I've attached the patch in case you guys see this change good and useful.
>
> Greetings
>
> [1] https://bugs.launchpad.net/ubuntu/+source/udev/+bug/316215
--
Juanje Ojeda
[-- Attachment #2: 0001-Added-udev-acl-tag-to-the-new-android-based-smartpho.patch --]
[-- Type: text/x-patch, Size: 2425 bytes --]
From 8f92370b6102f8b811db9c2ce19d33ecdd77d925 Mon Sep 17 00:00:00 2001
From: Juanje Ojeda <jojeda@emergya.es>
Date: Thu, 1 Jul 2010 02:41:51 +0200
Subject: [PATCH] Added udev-acl tag to the new android based smartphones
It was just supported the G1 but now there are lots of new
devices. As long as each vendor has many models and Adndroid
developer site recomend to use just the idVendor, the idProduct
has been removed, so the new models from those vendors will be
supported.
The list of vendors has been extracted from:
http://developer.android.com/guide/developing/device.html#VendorIds
And it has been added the Google Nexus One, which wasn't in that list.
Signed-off-by: Juanje Ojeda <jojeda@emergya.es>
---
| 17 ++++++++++++++++-
1 files changed, 16 insertions(+), 1 deletions(-)
--git a/extras/udev-acl/70-acl.rules b/extras/udev-acl/70-acl.rules
index 8300ec2..7a12f4f 100644
--- a/extras/udev-acl/70-acl.rules
+++ b/extras/udev-acl/70-acl.rules
@@ -65,7 +65,22 @@ ENV{ID_SMARTCARD_READER}=="*?", TAG+="udev-acl"
SUBSYSTEM=="input", ENV{ID_INPUT_JOYSTICK}=="?*", TAG+="udev-acl"
# smart phones
-SUBSYSTEM=="usb", ATTR{idVendor}=="0bb4", ATTR{idProduct}=="0c02", TAG+="udev-acl"
+SUBSYSTEM=="usb", ATTR{idVendor}=="0502", TAG+="udev-acl" # Acer
+SUBSYSTEM=="usb", ATTR{idVendor}=="413c", TAG+="udev-acl" # Dell
+SUBSYSTEM=="usb", ATTR{idVendor}=="043c", TAG+="udev-acl" # Foxconn
+SUBSYSTEM=="usb", ATTR{idVendor}=="091e", TAG+="udev-acl" # Garmin-Asus
+SUBSYSTEM=="usb", ATTR{idVendor}=="0bb4", TAG+="udev-acl" # HTC
+SUBSYSTEM=="usb", ATTR{idVendor}=="12d1", TAG+="udev-acl" # Huawei
+SUBSYSTEM=="usb", ATTR{idVendor}=="0482", TAG+="udev-acl" # Kyocera
+SUBSYSTEM=="usb", ATTR{idVendor}=="1004", TAG+="udev-acl" # LG
+SUBSYSTEM=="usb", ATTR{idVendor}=="22b8", TAG+="udev-acl" # Motorola
+SUBSYSTEM=="usb", ATTR{idVendor}=="0955", TAG+="udev-acl" # Nvidia
+SUBSYSTEM=="usb", ATTR{idVendor}=="10a9", TAG+="udev-acl" # Pantech
+SUBSYSTEM=="usb", ATTR{idVendor}=="04e8", TAG+="udev-acl" # Sansung
+SUBSYSTEM=="usb", ATTR{idVendor}=="04dd", TAG+="udev-acl" # Sharp
+SUBSYSTEM=="usb", ATTR{idVendor}=="0fce", TAG+="udev-acl" # Sony Ericsson
+SUBSYSTEM=="usb", ATTR{idVendor}=="19d2", TAG+="udev-acl" # ZTE
+SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", TAG+="udev-acl" # Nexus One
# color measurement devices
ENV{COLOR_MEASUREMENT_DEVICE}=="*?", TAG+="udev-acl"
--
1.7.0.4
^ permalink raw reply related
* Re: Udev rule for Digi Edgeport 8 (multi-port USB-serial adapter)
From: Greg KH @ 2010-08-05 14:50 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=ge3Qkenj3bxgZth9gZdvQnaLvBCu54H7Ki=d2@mail.gmail.com>
On Wed, Aug 04, 2010 at 04:21:35PM -1000, Philip Tait wrote:
> I'm using 2.6.31 - that's pretty recent, right?
That's a kernel version, not a udev version :)
And even then, no, it's almost a year old, pretty old for a kernel
release.
> Do you know why '%e' was eliminated?
What does the changelog say?
> I've been doing some more reading, and wondered if I need to do an
> IMPORT{parent} somewhere, so that my rule sees the 'port-num' and
> 'serial' attributes at the same time. Not sure how to find out what
> value to use for 'parent', though...
As Kay points out, what's wrong with /dev/serial/ ? That should provide
you with a persistant link for serial devices like this.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] path_id: Handle SAS and SATA devices
From: David Zeuthen @ 2010-08-05 13:53 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100707145508.A42312A2B9@ochil.suse.de>
Hey,
On Thu, Aug 5, 2010 at 9:35 AM, Hannes Reinecke <hare@suse.de> wrote:
>> But how is the symlink
>>
>> /dev/disk/by-path/pci-0000:06:00.0-sas-0x500000e01b83f523-lun-0x0000000000000000
>> -> ../../sdn
>>
>> in any way actually useful? I mean, this link refers to the 2nd port
>> of the first LUN of some SAS device that is connected to some HBA
>> connected via PCI. I can't really see how it has anything to do with
>> the actual _path_ to do the disk. E.g. if I move the disk to another
>> PHY on the SAS expander then that link will point to that. So it's not
>> really by path. If anything, it's by-id.
>>
> Yeah, I've discussed the same thing with Kay.
> You are right, referencing the SAS WWN of the remote port is
> pointless. We should rather reference the phy-number of the local
> port this device is connected to; that we'll be getting a 'real'
> path-id for SAS.
> Guess I have to redo that thing.
That sounds good - would be nice to include the word expander in the
link name so it's easy to figure out what the link is really about.
Also remember that SAS enclosures can be nested - in fact, in many
setups people nest enclosures like this
HBA1 <-> expander1 <-> expander2 <-> expander3
Now, for a disk connected to PHY 5 of expander 1, I'd expect the name
to be like this
/dev/disk/by-path/pci-0000:06:00.0-sas-expander-0x500000e1-phy05
but what about a disk connected to PHY 6 of expander 2 (with expander
2 being connected to PHYs 10-13 through a wide port)? Would it be
/dev/disk/by-path/pci-0000:06:00.0-sas-expander-0x500000e2-phy06
or
/dev/disk/by-path/pci-0000:06:00.0-sas-expander-0x500000e1-phy10,11,12,13-sas-expander-0x500000e2-phy06
My take is that the latter is the "correct" answer but I also think
it's pretty useless (kinda like the sysfs hierarchy is super deep)....
at the same time I think the former is what 99.9% of people expects
and wants [1]. Thoughts?
> And as SES is in general handled via a different device
> we'd have a hard time getting information from there.
Right, the enclosure services device is a separate SCSI device. But
James actually already wrote a driver for such devices and it sets up
symlinks in sysfs that can be used to easily name the devices here in
user space.
David
^ permalink raw reply
* Re: [PATCH] path_id: Handle SAS and SATA devices
From: Hannes Reinecke @ 2010-08-05 13:35 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100707145508.A42312A2B9@ochil.suse.de>
David Zeuthen wrote:
> Hey Hannes,
>
> On Thu, Aug 5, 2010 at 3:37 AM, Hannes Reinecke <hare@suse.de> wrote:
>> No, that was _exactly_ my intention.
>
> Would be useful with tree /dev/disk/by-path output in the commit message.
>
>> 'by-path' is the physical path, ie the path is identified by the physical
>> properties. Hence we need to refer to the SAS port WWN here.
>> The WWN of the disk is referred to in 'by-id'.
>>
>> So the path_id program is working as expected from my POV.
>
> But how is the symlink
>
> /dev/disk/by-path/pci-0000:06:00.0-sas-0x500000e01b83f523-lun-0x0000000000000000
> -> ../../sdn
>
> in any way actually useful? I mean, this link refers to the 2nd port
> of the first LUN of some SAS device that is connected to some HBA
> connected via PCI. I can't really see how it has anything to do with
> the actual _path_ to do the disk. E.g. if I move the disk to another
> PHY on the SAS expander then that link will point to that. So it's not
> really by path. If anything, it's by-id.
>
Yeah, I've discussed the same thing with Kay.
You are right, referencing the SAS WWN of the remote port is
pointless. We should rather reference the phy-number of the local
port this device is connected to; that we'll be getting a 'real'
path-id for SAS.
Guess I have to redo that thing.
> Btw, exactly what problem are you trying to solve with this patch?
> Wouldn't it be better to, say, just use SES identifiers e.g. something
> like this
>
> /dev/disk/by-path/sas-enclosure-Promise_VTrak_J310sD-0x5001234-serial-abcd-slot05
>
> that actually tells the user that this link refers to slot 5 of an
> enclosure of the given make/model, with a WWN of 0x5001234 and serial
> number abcd. I think long-term we really want something like that....
> all it requires is a bit of programming.
>
Why, of course. But that would be 'by-id' again, as it's just referring
to the disk, not how to get there.
The idea of the 'by-path' thing is that it should describe the path
(or, in SCSI speak, the ITL Nexus) of how we access the device.
So in principle you should be able to exchange the backing device
at that point but the link would stay the same.
As for the SES identifier: in principle yes.
Only we have this darned restriction of working within the
limits of the named device _only_.
And as SES is in general handled via a different device
we'd have a hard time getting information from there.
We've been stuck with the same problem for SCSI tapes
due to the use of 'st' and 'nst' devices, but finally
got it solved via bsg. Maybe we can pull a similar trick
here, but I'm not sure.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
^ permalink raw reply
* Re: [PATCH] path_id: Handle SAS and SATA devices
From: David Zeuthen @ 2010-08-05 13:16 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100707145508.A42312A2B9@ochil.suse.de>
Hey Hannes,
On Thu, Aug 5, 2010 at 3:37 AM, Hannes Reinecke <hare@suse.de> wrote:
> No, that was _exactly_ my intention.
Would be useful with tree /dev/disk/by-path output in the commit message.
> 'by-path' is the physical path, ie the path is identified by the physical
> properties. Hence we need to refer to the SAS port WWN here.
> The WWN of the disk is referred to in 'by-id'.
>
> So the path_id program is working as expected from my POV.
But how is the symlink
/dev/disk/by-path/pci-0000:06:00.0-sas-0x500000e01b83f523-lun-0x0000000000000000
-> ../../sdn
in any way actually useful? I mean, this link refers to the 2nd port
of the first LUN of some SAS device that is connected to some HBA
connected via PCI. I can't really see how it has anything to do with
the actual _path_ to do the disk. E.g. if I move the disk to another
PHY on the SAS expander then that link will point to that. So it's not
really by path. If anything, it's by-id.
Btw, exactly what problem are you trying to solve with this patch?
Wouldn't it be better to, say, just use SES identifiers e.g. something
like this
/dev/disk/by-path/sas-enclosure-Promise_VTrak_J310sD-0x5001234-serial-abcd-slot05
that actually tells the user that this link refers to slot 5 of an
enclosure of the given make/model, with a WWN of 0x5001234 and serial
number abcd. I think long-term we really want something like that....
all it requires is a bit of programming.
(OK, so the proposed sas-enclosure- path is "local" to the enclosure
but I think that's OK - it's normally not really useful nor
interesting _where_ that particular enclosure really is - what's
interesting is that it's easy to identify slots in enclosures.)
David
^ permalink raw reply
* dvb persistant rules
From: ukasz @ 2010-08-05 13:05 UTC (permalink / raw)
To: linux-hotplug
hi
i have noticed that in my dmesg i can read mac addreses of my dvb cards.
this is unique enough variable to create persistant rules for udev.
i have:
kernel 2.6.32-2-686
udev version 157
any chance for this feature ?
my dmesg output:
[ 131.788233] tveeprom 2-0050: Hauppauge model 69100, rev B2C3, serial#
3081212
[ 131.788239] tveeprom 2-0050: MAC address is 00:0d:fe:2f:03:fc
[ 131.788244] tveeprom 2-0050: tuner model is Conexant CX24118A (idx
123, type 4)
[ 131.788248] tveeprom 2-0050: TV standards ATSC/DVB Digital (eeprom 0x80)
[ 131.788252] tveeprom 2-0050: audio processor is None (idx 0)
[ 131.788255] tveeprom 2-0050: decoder processor is CX882 (idx 25)
[ 131.788259] tveeprom 2-0050: has no radio, has IR receiver, has no IR
transmitter
[ 9592.422023] DVB: registering new adapter (bttv0)
[ 9592.847145] dst(0) dst_get_device_id: Recognise [DST-03T]
[ 9592.978578] dst(0) dst_check_stv0299: Found a STV0299 NIM
[ 9593.110557] dst(0) dst_check_mb86a15: Found a MB86A15 NIM
[ 9593.110583] dst(0) dst_get_device_id: [DST-03T] has a [MB 86A15]
[ 9593.110603] dst(0) dst_get_device_id: [DST-03T] has a [MB 86A15]
[ 9593.110624] DST type flags : 0x2 ts204 0x4 symdiv 0x10 firmware
version = 2
[ 9593.145559] dst(0) dst_get_mac: MAC Address=[00:08:ca:10:12:da]
[ 9593.145588] DVB: registering adapter 1 frontend -1803194115 (DST
DVB-S)...
[10217.708418] bt878(0): irq FDSR risc_pc5d45210
^ permalink raw reply
* Strange initramfs+udev+raid interaction creating /dev/md/*
From: Michael Guntsche @ 2010-08-05 12:49 UTC (permalink / raw)
To: linux-raid; +Cc: linux-hotplug
In-Reply-To: <20100805062615.GA4402@gibson.comsick.at>
Hi again,
Apparently this is a problem with mdadm-3.1.2 and not udev.
Reverting to 3.1.1 or reverting commit
http://neil.brown.name/git?p=mdadm;a=commitdiff;h19767b85c2b16d80c235195329470c46d4547b3
as mentioned in bugreport
http://bugs.debian.org/cgi-bin/bugreport.cgi?bugY0319
fixes the issue for me.
Kind regards,
Michael Guntsche
^ permalink raw reply
* Re: [PATCH] path_id: Handle SAS and SATA devices
From: Hannes Reinecke @ 2010-08-05 7:37 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100707145508.A42312A2B9@ochil.suse.de>
David Zeuthen wrote:
> Hi,
>
> On Mon, Jul 12, 2010 at 10:47 AM, David Zeuthen <davidz@redhat.com> wrote:
>> On Mon, 2010-07-12 at 11:07 +0200, Kay Sievers wrote:
>>> On Wed, Jul 7, 2010 at 16:55, Hannes Reinecke <hare@suse.de> wrote:
>>>> SAS devices should be referenced by the SAS address of the target;
>>>> on the initiator side we assume an identity mapping between SAS
>>>> addresses and PCI devnumber.
>>>> SATA devices have an identity mapping between SATA links and
>>>> linux scsi_host structures, so we can map the host number onto
>>>> the SATA link.
>>>> For this to work the LUN numbering needs to be updated, too,
>>>> as SATA devices do not have the concept of a LUN, whereas normal
>>>> SCSI devices have.
>>> David, any chance to give this a try on your SAS box, and see if this
>>> works as expected for you too?
>> Sure, will do later this week - it's currently powered off and in a
>> moving box!
>
> OK, I get these additional links in /dev/disk/by-path
>
> +│ ├── pci-0000:06:00.0-sas-0x500000e01b83f362-lun-0x0000000000000000
> -> ../../sds
> +│ ├── pci-0000:06:00.0-sas-0x500000e01b83f363-lun-0x0000000000000000
> -> ../../sdr
> +│ ├── pci-0000:06:00.0-sas-0x500000e01b83f442-lun-0x0000000000000000
> -> ../../sdq
> +│ ├── pci-0000:06:00.0-sas-0x500000e01b83f443-lun-0x0000000000000000
> -> ../../sdp
> +│ ├── pci-0000:06:00.0-sas-0x500000e01b83f522-lun-0x0000000000000000
> -> ../../sdo
> +│ ├── pci-0000:06:00.0-sas-0x500000e01b83f523-lun-0x0000000000000000
> -> ../../sdn
> +│ ├── pci-0000:06:00.0-sas-0x500000e01b843d92-lun-0x0000000000000000
> -> ../../sdm
> +│ └── pci-0000:06:00.0-sas-0x500000e01b843d93-lun-0x0000000000000000
> -> ../../sdl
>
> for four SAS disks with two paths each. Btw, the WWN used is
> apparently not that of the actual disk
>
> # udevadm info -q all -n /dev/sdn|grep ID_WWN> E: ID_WWN=0x500000e01b83f520
>
> which matches what is printed on the actual disk
>
> http://people.freedesktop.org/~david/FUJITSU-MAY2036RC-sas-disk-picture.jpg
>
> however the WWNs that your patch introduces differ from this. However
> those WWNs appear here
>
> # smp_discover /dev/bsg/expander-7\:0 --multiple |grep b83f52
> phy 4:T:attached:[500000e01b83f523:01 t(SSP)] 3 Gbps
> # smp_discover /dev/bsg/expander-7\:1 --multiple |grep b83f52
> phy 4:T:attached:[500000e01b83f522:00 t(SSP)] 3 Gbps
>
> e.g. the WWNs that you use are the WWNs of the actual ports, not the
> LUN itself, yes? You should probably use the LUN WWN instead. I mean,
> I think people are interested in the WWN of the LUN and they don't
> care so much about the WWN of the ports. Or maybe we want both?
> Anyway, I *think* that's the way it works but I could be wrong on some
> of the SAS details.
>
No, that was _exactly_ my intention.
'by-path' is the physical path, ie the path is identified by the physical
properties. Hence we need to refer to the SAS port WWN here.
The WWN of the disk is referred to in 'by-id'.
So the path_id program is working as expected from my POV.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
^ permalink raw reply
* Fw: Strange initramfs+udev+raid interaction creating /dev/md/*
From: Michael Guntsche @ 2010-08-05 6:26 UTC (permalink / raw)
To: linux-hotplug
Forwarding it to this list as well since I am not sure if it is a raid
or udev problem
Date: Wed, 4 Aug 2010 21:42:16 +0200
From: Michael Guntsche <mike@it-loops.com>
To: linux-raid@vger.kernel.org
Subject: Strange initramfs+udev+raid interaction creating /dev/md/*
User-Agent: Mutt/1.5.20 (2009-06-14)
Hi list,
I am facing a strange behaviour between udev and the raid code here and
to be honest I do not know where the problem is.
The problem is the following. I have two md devices
ARRAY /dev/md0 metadata=0.90 UUID;9e371a:f651d170:2a42ebe3:f331026f
ARRAY /dev/md/1 metadata=1.00 name=gibson:1
UUID/18e1fe:867d891e:501f93be:ea635188
/dev/md/1 is giving me troubles.
I am booting using an initramfs. Looking through the initramfs
scripts I see that /dev/md/1 gets created by it. The syslog on the
other hand shows me this during the boot process.
Aug 4 21:23:12 gibson mdadm[3606]: DeviceDisappeared event detected on
md device /dev/md/1
Aug 4 21:23:12 gibson mdadm[3606]: NewArray event detected on md device
/dev/md1
Apparently the device gets removed and then added as /dev/md1 as a
result /dev/md/1 disappears.
If I then run mdadm -Ds I see this
KERNEL[1280949869.791242] change /devices/virtual/block/md1 (block)
KERNEL[1280949869.792353] change /devices/virtual/block/md0 (block)
UDEV [1280949869.850176] change /devices/virtual/block/md1 (block)
UDEV [1280949870.044863] change /devices/virtual/block/md0 (block)
and /dev/md/1 is re-created.
Now my question. Why does /dev/md/1 disappear and /dev/md1 gets created?
And even if /dev/md1 gets created shouldn't this trigger udev
automatically resulting in the creation of /dev/md/1 like running mdadm
-Ds does?
The problem I have is that I cannot rally debug this during boot.
FYI running:
udevadm test /sys/block/md1/
results in the symlink /dev/md/1 being created. So either this means
that udev is really not triggered when /dev/md1 appears OR /dev/md/1 is
still existing and therefor no symlink is created.
Kind regards,
Michael Guntsche
^ permalink raw reply
* Re: Udev rule for Digi Edgeport 8 (multi-port USB-serial adapter)
From: Kay Sievers @ 2010-08-05 4:32 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=ge3Qkenj3bxgZth9gZdvQnaLvBCu54H7Ki=d2@mail.gmail.com>
On Thu, Aug 5, 2010 at 03:45, Philip Tait <philip@naoj.org> wrote:
> I have been trying to overcome the loss of the '%e' enumeration
> variable to make a version of the Edgeport rules that will work with
> the current version of Udev.
>
> Old version:
>
> BUS="usb" SYSFS{idVendor}="1608" SYSFS{idProduct}="0244"
> SYSFS{serial}="*-0" NAME="%k" SYMLINK="ttyEDGE8_0_%e"
> BUS="usb" SYSFS{idVendor}="1608" SYSFS{idProduct}="0244"
> SYSFS{serial}="*-1" NAME="%k" SYMLINK="ttyEDGE8_1_%e"
>
> Replacing it with '%m" doesn't work, because then the numbering is
> dependent on the presence of other USB-serial devices.
>
> I tried this:
>
> ENV{portnum}=ATTRS{port_number}
> BUS="usb",SYSFS{idVendor}="1608",SYSFS{idProduct}="0244",SYSFS{serial}="I01846004-0",
> NAME="%k",SYMLINK="ttyEDGE8_%E{portnum}"`
> BUS="usb",SYSFS{idVendor}="1608",SYSFS{idProduct}="0244",SYSFS{serial}="I01846004-1",
> NAME="%k",SYMLINK="ttyEDGE8_%E{portnum}"`
> BUS="usb",SYSFS{idVendor}="1608",SYSFS{idProduct}="0244",SYSFS{serial}="I01846004-2",
> NAME="%k",SYMLINK="ttyEDGE8_%E{portnum}"`
> BUS="usb",SYSFS{idVendor}="1608",SYSFS{idProduct}="0244",SYSFS{serial}="I01846004-3",
> NAME="%k",SYMLINK="ttyEDGE8_%E{portnum}"`
>
> but this didn't work, I think because the 'port_number' attribute is
> defined at a different hierarchical level than the 'serial' attribute:
I guess that's all covered by the standard: /dev/serial/by-*/.
Kay
^ permalink raw reply
* Re: Udev rule for Digi Edgeport 8 (multi-port USB-serial adapter)
From: Philip Tait @ 2010-08-05 2:21 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=ge3Qkenj3bxgZth9gZdvQnaLvBCu54H7Ki=d2@mail.gmail.com>
I'm using 2.6.31 - that's pretty recent, right?
Do you know why '%e' was eliminated?
I've been doing some more reading, and wondered if I need to do an
IMPORT{parent} somewhere, so that my rule sees the 'port-num' and
'serial' attributes at the same time. Not sure how to find out what
value to use for 'parent', though...
On Wed, Aug 4, 2010 at 16:17, Greg KH <greg@kroah.com> wrote:
> On Wed, Aug 04, 2010 at 03:45:29PM -1000, Philip Tait wrote:
>> I have been trying to overcome the loss of the '%e' enumeration
>> variable to make a version of the Edgeport rules that will work with
>> the current version of Udev.
>
> What version is that? Why not upgrade to a working one?
>
> thanks,
>
> greg k-h
>
--
Philip J. Tait
Software Engineer, FMOS
http://subarutelescope.org
^ permalink raw reply
* Re: Udev rule for Digi Edgeport 8 (multi-port USB-serial adapter)
From: Greg KH @ 2010-08-05 2:18 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=ge3Qkenj3bxgZth9gZdvQnaLvBCu54H7Ki=d2@mail.gmail.com>
On Wed, Aug 04, 2010 at 07:17:41PM -0700, Greg KH wrote:
> On Wed, Aug 04, 2010 at 03:45:29PM -1000, Philip Tait wrote:
> > I have been trying to overcome the loss of the '%e' enumeration
> > variable to make a version of the Edgeport rules that will work with
> > the current version of Udev.
>
> What version is that? Why not upgrade to a working one?
Or, better yet, just call out to a shell script or executable that
provides the needed functionality instead, if you can't upgrade udev.
hope this helps,
greg k-h
^ permalink raw reply
* Re: Udev rule for Digi Edgeport 8 (multi-port USB-serial adapter)
From: Greg KH @ 2010-08-05 2:17 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <AANLkTi=ge3Qkenj3bxgZth9gZdvQnaLvBCu54H7Ki=d2@mail.gmail.com>
On Wed, Aug 04, 2010 at 03:45:29PM -1000, Philip Tait wrote:
> I have been trying to overcome the loss of the '%e' enumeration
> variable to make a version of the Edgeport rules that will work with
> the current version of Udev.
What version is that? Why not upgrade to a working one?
thanks,
greg k-h
^ permalink raw reply
* Udev rule for Digi Edgeport 8 (multi-port USB-serial adapter)
From: Philip Tait @ 2010-08-05 1:45 UTC (permalink / raw)
To: linux-hotplug
I have been trying to overcome the loss of the '%e' enumeration
variable to make a version of the Edgeport rules that will work with
the current version of Udev.
Old version:
BUS="usb" SYSFS{idVendor}="1608" SYSFS{idProduct}="0244"
SYSFS{serial}="*-0" NAME="%k" SYMLINK="ttyEDGE8_0_%e"
BUS="usb" SYSFS{idVendor}="1608" SYSFS{idProduct}="0244"
SYSFS{serial}="*-1" NAME="%k" SYMLINK="ttyEDGE8_1_%e"
Replacing it with '%m" doesn't work, because then the numbering is
dependent on the presence of other USB-serial devices.
I tried this:
ENV{portnum}=ATTRS{port_number}
BUS="usb",SYSFS{idVendor}="1608",SYSFS{idProduct}="0244",SYSFS{serial}="I01846004-0",
NAME="%k",SYMLINK="ttyEDGE8_%E{portnum}"`
BUS="usb",SYSFS{idVendor}="1608",SYSFS{idProduct}="0244",SYSFS{serial}="I01846004-1",
NAME="%k",SYMLINK="ttyEDGE8_%E{portnum}"`
BUS="usb",SYSFS{idVendor}="1608",SYSFS{idProduct}="0244",SYSFS{serial}="I01846004-2",
NAME="%k",SYMLINK="ttyEDGE8_%E{portnum}"`
BUS="usb",SYSFS{idVendor}="1608",SYSFS{idProduct}="0244",SYSFS{serial}="I01846004-3",
NAME="%k",SYMLINK="ttyEDGE8_%E{portnum}"`
but this didn't work, I think because the 'port_number' attribute is
defined at a different hierarchical level than the 'serial' attribute:
looking at parent device
'/devices/pci0000:00/0000:00:1d.1/usb7/7-2/7-2.4/7-2.4:1.0/ttyUSB0':
KERNELS="ttyUSB0"
SUBSYSTEMS="usb-serial"
DRIVERS="edgeport_ti_2"
ATTRS{uart_mode}="0"
ATTRS{port_number}="0"
looking at parent device
'/devices/pci0000:00/0000:00:1d.1/usb7/7-2/7-2.4/7-2.4:1.0':
[....]
looking at parent device '/devices/pci0000:00/0000:00:1d.1/usb7/7-2/7-2.4':
KERNELS="7-2.4"
SUBSYSTEMS="usb"
DRIVERS="usb"
ATTRS{configuration}=""
ATTRS{bNumInterfaces}=" 1"
ATTRS{bConfigurationValue}="1"
ATTRS{bmAttributes}="e0"
ATTRS{bMaxPower}=" 0mA"
ATTRS{urbnum}="38"
ATTRS{idVendor}="1608"
ATTRS{idProduct}="0244"
ATTRS{bcdDevice}="0001"
ATTRS{bDeviceClass}="ff"
ATTRS{bDeviceSubClass}="00"
ATTRS{bDeviceProtocol}="ff"
ATTRS{bNumConfigurations}="1"
ATTRS{bMaxPacketSize0}="8"
ATTRS{speed}="12"
ATTRS{busnum}="7"
ATTRS{devnum}="18"
ATTRS{version}=" 1.10"
ATTRS{maxchild}="0"
ATTRS{quirks}="0x0"
ATTRS{authorized}="1"
ATTRS{manufacturer}="Digi International"
ATTRS{product}="Edgeport/8"
ATTRS{serial}="I01846004-0"
Any clues or ideas would be welcome!
--
Philip J. Tait
Software Engineer, FMOS
http://subarutelescope.org
^ permalink raw reply
* Re: [PATCH] path_id: Handle SAS and SATA devices
From: David Zeuthen @ 2010-08-04 21:56 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100707145508.A42312A2B9@ochil.suse.de>
Hi,
On Mon, Jul 12, 2010 at 10:47 AM, David Zeuthen <davidz@redhat.com> wrote:
> On Mon, 2010-07-12 at 11:07 +0200, Kay Sievers wrote:
>> On Wed, Jul 7, 2010 at 16:55, Hannes Reinecke <hare@suse.de> wrote:
>> >
>> > SAS devices should be referenced by the SAS address of the target;
>> > on the initiator side we assume an identity mapping between SAS
>> > addresses and PCI devnumber.
>> > SATA devices have an identity mapping between SATA links and
>> > linux scsi_host structures, so we can map the host number onto
>> > the SATA link.
>> > For this to work the LUN numbering needs to be updated, too,
>> > as SATA devices do not have the concept of a LUN, whereas normal
>> > SCSI devices have.
>>
>> David, any chance to give this a try on your SAS box, and see if this
>> works as expected for you too?
>
> Sure, will do later this week - it's currently powered off and in a
> moving box!
OK, I get these additional links in /dev/disk/by-path
+│ ├── pci-0000:06:00.0-sas-0x500000e01b83f362-lun-0x0000000000000000
-> ../../sds
+│ ├── pci-0000:06:00.0-sas-0x500000e01b83f363-lun-0x0000000000000000
-> ../../sdr
+│ ├── pci-0000:06:00.0-sas-0x500000e01b83f442-lun-0x0000000000000000
-> ../../sdq
+│ ├── pci-0000:06:00.0-sas-0x500000e01b83f443-lun-0x0000000000000000
-> ../../sdp
+│ ├── pci-0000:06:00.0-sas-0x500000e01b83f522-lun-0x0000000000000000
-> ../../sdo
+│ ├── pci-0000:06:00.0-sas-0x500000e01b83f523-lun-0x0000000000000000
-> ../../sdn
+│ ├── pci-0000:06:00.0-sas-0x500000e01b843d92-lun-0x0000000000000000
-> ../../sdm
+│ └── pci-0000:06:00.0-sas-0x500000e01b843d93-lun-0x0000000000000000
-> ../../sdl
for four SAS disks with two paths each. Btw, the WWN used is
apparently not that of the actual disk
# udevadm info -q all -n /dev/sdn|grep ID_WWN E: ID_WWN=0x500000e01b83f520
which matches what is printed on the actual disk
http://people.freedesktop.org/~david/FUJITSU-MAY2036RC-sas-disk-picture.jpg
however the WWNs that your patch introduces differ from this. However
those WWNs appear here
# smp_discover /dev/bsg/expander-7\:0 --multiple |grep b83f52
phy 4:T:attached:[500000e01b83f523:01 t(SSP)] 3 Gbps
# smp_discover /dev/bsg/expander-7\:1 --multiple |grep b83f52
phy 4:T:attached:[500000e01b83f522:00 t(SSP)] 3 Gbps
e.g. the WWNs that you use are the WWNs of the actual ports, not the
LUN itself, yes? You should probably use the LUN WWN instead. I mean,
I think people are interested in the WWN of the LUN and they don't
care so much about the WWN of the ports. Or maybe we want both?
Anyway, I *think* that's the way it works but I could be wrong on some
of the SAS details.
FWIW, I've included sg_inq(8) output in [1] for both paths to the disk.
David
[1] :
# sg_inq /dev/sdo --page 0x83
VPD INQUIRY: Device Identification page
Designation descriptor number 1, descriptor length: 12
designator_type: NAA, code_set: Binary
associated with the addressed logical unit
NAA 5, IEEE Company_id: 0xe
Vendor Specific Identifier: 0x1b83f520
[0x500000e01b83f520]
Designation descriptor number 2, descriptor length: 12
transport: Serial Attached SCSI (SAS)
designator_type: NAA, code_set: Binary
associated with the target port
NAA 5, IEEE Company_id: 0xe
Vendor Specific Identifier: 0x1b83f522
[0x500000e01b83f522]
Designation descriptor number 3, descriptor length: 8
transport: Serial Attached SCSI (SAS)
designator_type: Relative target port, code_set: Binary
associated with the target port
Relative target port: 0x1
Designation descriptor number 4, descriptor length: 28
designator_type: SCSI name string, code_set: UTF-8
associated with the target device that contains addressed lu
SCSI name string:
naa.500000E01B83F520
# sg_inq /dev/sdn --page 0x83
VPD INQUIRY: Device Identification page
Designation descriptor number 1, descriptor length: 12
designator_type: NAA, code_set: Binary
associated with the addressed logical unit
NAA 5, IEEE Company_id: 0xe
Vendor Specific Identifier: 0x1b83f520
[0x500000e01b83f520]
Designation descriptor number 2, descriptor length: 12
transport: Serial Attached SCSI (SAS)
designator_type: NAA, code_set: Binary
associated with the target port
NAA 5, IEEE Company_id: 0xe
Vendor Specific Identifier: 0x1b83f523
[0x500000e01b83f523]
Designation descriptor number 3, descriptor length: 8
transport: Serial Attached SCSI (SAS)
designator_type: Relative target port, code_set: Binary
associated with the target port
Relative target port: 0x2
Designation descriptor number 4, descriptor length: 28
designator_type: SCSI name string, code_set: UTF-8
associated with the target device that contains addressed lu
SCSI name string:
naa.500000E01B83F520
^ permalink raw reply
* Re: [PATCH] udev-acl: really fix ACL assignment in CK events
From: Kay Sievers @ 2010-08-04 10:03 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20100804115325.6599879e@hammerfall>
On Wed, Aug 4, 2010 at 11:53, Michal Schmidt <mschmidt@redhat.com> wrote:
> The previous fix for udev-acl was incomplete. The ACL were not properly
> assigned to the new user when switching from root's session because of
> the test for 'uid != 0'.
Applied.
Thanks,
Kay
^ 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