* Re: net device renaming 2-step, IFNAMSIZ limit
From: Piter PUNK @ 2010-12-07 2:45 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20101129032908.GA29904@auslistsprd01.us.dell.com>
Matt Domsch wrote:
> I see this in the udev debug logs when using biosdevname (which I
> finally got working with SR-IOV devices tonight):
>
> renamed network interface eth60 to eth60-pci2#0_60
> renamed network interface eth60-pci2#0_60 to pci2#0_60
>
> So, it worked, however, note that the rename happens in 2 steps, the
> middle step of which uses a name that's dangerously close to
> IFNAMSIZ, in fact it is 15 chars there.
>
> <...>
>
> I need a solution in which the intermediate name doesn't exceed 15
> characters, and is guaranteed to be unique, as there may be lots of
> udev instances running in parallel trying to do the same thing.
>
> Ideas?
As we talk on #udev, there is a patch that uses hash32 function inside
libudev to create
the intermediate name. We use the "oldname-newname" to create the hash.
With that,
exceeding IFNAMSIZ isn't a problem:
-------cut here--------
diff --git a/udev/udev-event.c b/udev/udev-event.c
index 0648735..fc4aae0 100644
--- a/udev/udev-event.c
+++ b/udev/udev-event.c
@@ -462,6 +462,7 @@ static void rename_netif_kernel_log(struct ifreq ifr)
static int rename_netif(struct udev_event *event)
{
struct udev_device *dev = event->dev;
+ char iftmp[IFNAMSIZ*2+1];
int sk;
struct ifreq ifr;
int loop;
@@ -492,7 +493,8 @@ static int rename_netif(struct udev_event *event)
goto out;
/* free our own name, another process may wait for us */
- util_strscpyl(ifr.ifr_newname, IFNAMSIZ,
udev_device_get_sysname(dev), "-", event->name, NULL);
+ util_strscpyl(iftmp, IFNAMSIZ*2+1, udev_device_get_sysname(dev),
"-", event->name, NULL);
+ util_strscpyl(ifr.ifr_newname, IFNAMSIZ, "eth_%X",
util_string_hash32(iftmp), NULL);
err = ioctl(sk, SIOCSIFNAME, &ifr);
if (err < 0) {
err = -errno;
-------cut here--------
Ideas and fixes are welcome,
Piter PUNK
^ permalink raw reply related
* Re: net device renaming 2-step, IFNAMSIZ limit
From: Matt Domsch @ 2010-12-07 3:54 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20101129032908.GA29904@auslistsprd01.us.dell.com>
On Tue, Dec 07, 2010 at 12:45:04AM -0200, Piter PUNK wrote:
> As we talk on #udev, there is a patch that uses hash32 function inside
> libudev to create
> the intermediate name. We use the "oldname-newname" to create the hash.
> With that,
> exceeding IFNAMSIZ isn't a problem:
Thanks piterpunk.
I built udev on a Fedora 14 box, with this patch, and it works.
However, I don't see udev doing the 2-step anymore, perhaps that was
just a figment of the loglevel. Anyhow, it looks right, and doesn't
blow up.
Thanks,
Matt
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
^ permalink raw reply
* Re: biosdevname v0.3.2
From: Ben Hutchings @ 2010-12-07 18:16 UTC (permalink / raw)
To: Matt Domsch
Cc: linux-hotplug, netdev, K, Narendra, Hargrave, Jordan,
Rose, Charles, Colin Watson
In-Reply-To: <20101206140649.GA13628@auslistsprd01.us.dell.com>
On Mon, 2010-12-06 at 08:06 -0600, Matt Domsch wrote:
> Bugfix update to biosdevname, now version 0.3.2.
>
> The legacy code for reading the PCI IRQ Routing Table ($PIR) and the
> PCMCIA information has been removed. This means biosdevname will only
> report BIOS-provided names if your system has SMBIOS 2.6 or higher and
> has the information in Type 9 or Type 41. This is in preparation for
> widespread use, and will keep biosdevname from suggesting names on
> systems that are well into or beyond their useful lifetime and
> introducing an unexpected change of behavior on them. Dell PowerEdge
> 10G and newer, HP ProLiant G6 and newer are known to have SMBIOS 2.6,
> as do a number of desktop, laptop, and netbook-class systems as
> reported on the fedora-devel mailing list.
>
> This release also provides correct names for Intel and Broadcom
> quad-port GigE cards that I've tried. Format is pci<slot>#<port>.
[...]
I tried this on a Supermicro board here, which doesn't have this
information. eth0 and eth1 are LOM ports, eth2 and eth3 are on a NIC.
The debug output is:
BIOS device:
Kernel name: eth2
Assigned MAC : 00:0F:53:01:41:14
Driver: sfc
Driver version: 3.0
Firmware version: 3.0.8.2217
Bus Info: 0000:01:00.0
PCI name : 0000:01:00.0
PCI Slot : Unknown
Index in slot: 7
BIOS device:
Kernel name: eth3
Assigned MAC : 00:0F:53:01:41:15
Driver: sfc
Driver version: 3.0
Firmware version: 3.0.8.2217
Bus Info: 0000:01:00.1
PCI name : 0000:01:00.1
PCI Slot : Unknown
Index in slot: 8
BIOS device:
Kernel name: eth0
Permanant MAC: 00:30:48:90:81:9E
Assigned MAC : 00:30:48:90:81:9E
Driver: e1000e
Driver version: 1.2.7-k2
Firmware version: 0.15-4
Bus Info: 0000:0d:00.0
PCI name : 0000:0d:00.0
PCI Slot : Unknown
Index in slot: 9
BIOS device:
Kernel name: eth1
Permanant MAC: 00:30:48:90:81:9F
Assigned MAC : 00:30:48:90:81:9F
Driver: e1000e
Driver version: 1.2.7-k2
Firmware version: 0.5-7
Bus Info: 0000:0e:00.0
PCI name : 0000:0e:00.0
PCI Slot : Unknown
Index in slot: 10
It appears that 'unknown slot' is treated as a specific slot and all
devices with an unknown slot are given unique indices. Perhaps this
doesn't matter in the end, since no name is generated when the slot is
unknown.
However, the 2 NIC ports do have their own indices (specified with the
dev_id attribute) and it should be possible to distinguish slots by
PCI/PCIe topology even though the name given won't correspond to any
markings on the motherboard.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: biosdevname v0.3.2
From: Matt Domsch @ 2010-12-07 18:19 UTC (permalink / raw)
To: Ben Hutchings
Cc: linux-hotplug, netdev, K, Narendra, Hargrave, Jordan,
Rose, Charles, Colin Watson
In-Reply-To: <1291745782.21627.6.camel@bwh-desktop>
On Tue, Dec 07, 2010 at 06:16:22PM +0000, Ben Hutchings wrote:
> It appears that 'unknown slot' is treated as a specific slot and all
> devices with an unknown slot are given unique indices. Perhaps this
> doesn't matter in the end, since no name is generated when the slot is
> unknown.
Yes on all counts.
> However, the 2 NIC ports do have their own indices (specified with the
> dev_id attribute) and it should be possible to distinguish slots by
> PCI/PCIe topology even though the name given won't correspond to any
> markings on the motherboard.
Tell me more about the dev_id attribute. I'm happy to use it, but I
don't understand the rules around populating it.
Thanks,
Matt
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
^ permalink raw reply
* Re: biosdevname v0.3.2
From: Ben Hutchings @ 2010-12-07 18:41 UTC (permalink / raw)
To: Matt Domsch
Cc: linux-hotplug, netdev, K, Narendra, Hargrave, Jordan,
Rose, Charles, Colin Watson
In-Reply-To: <20101207181910.GA2643@auslistsprd01.us.dell.com>
On Tue, 2010-12-07 at 12:19 -0600, Matt Domsch wrote:
> On Tue, Dec 07, 2010 at 06:16:22PM +0000, Ben Hutchings wrote:
> > It appears that 'unknown slot' is treated as a specific slot and all
> > devices with an unknown slot are given unique indices. Perhaps this
> > doesn't matter in the end, since no name is generated when the slot is
> > unknown.
>
> Yes on all counts.
>
> > However, the 2 NIC ports do have their own indices (specified with the
> > dev_id attribute) and it should be possible to distinguish slots by
> > PCI/PCIe topology even though the name given won't correspond to any
> > markings on the motherboard.
>
> Tell me more about the dev_id attribute. I'm happy to use it, but I
> don't understand the rules around populating it.
As I understand it, dev_id is supposed to distinguish net devices
corresponding to multiple ports on a single network controller.
However, a value of 0 could mean either 'unspecified' or 'first port' so
you would have to verify that multiple net devices for the same slot
have unique dev_id values before taking them into account.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: biosdevname v0.3.2
From: Matt Domsch @ 2010-12-08 5:19 UTC (permalink / raw)
To: Ben Hutchings
Cc: linux-hotplug, netdev, K, Narendra, Hargrave, Jordan,
Rose, Charles, Colin Watson
In-Reply-To: <1291747282.21627.9.camel@bwh-desktop>
On Tue, Dec 07, 2010 at 06:41:22PM +0000, Ben Hutchings wrote:
> On Tue, 2010-12-07 at 12:19 -0600, Matt Domsch wrote:
> > On Tue, Dec 07, 2010 at 06:16:22PM +0000, Ben Hutchings wrote:
> > > It appears that 'unknown slot' is treated as a specific slot and all
> > > devices with an unknown slot are given unique indices. Perhaps this
> > > doesn't matter in the end, since no name is generated when the slot is
> > > unknown.
> >
> > Yes on all counts.
> >
> > > However, the 2 NIC ports do have their own indices (specified with the
> > > dev_id attribute) and it should be possible to distinguish slots by
> > > PCI/PCIe topology even though the name given won't correspond to any
> > > markings on the motherboard.
> >
> > Tell me more about the dev_id attribute. I'm happy to use it, but I
> > don't understand the rules around populating it.
>
> As I understand it, dev_id is supposed to distinguish net devices
> corresponding to multiple ports on a single network controller.
> However, a value of 0 could mean either 'unspecified' or 'first port' so
> you would have to verify that multiple net devices for the same slot
> have unique dev_id values before taking them into account.
Only a handful of drivers seem to populate dev_id that I can find:
[drivers/net]$ grep -r -- '->dev_id' *
cxgb4/t4_hw.c: adap->port[i]->dev_id = j;
mlx4/en_netdev.c: dev->dev_id = port - 1;
sfc/siena.c: efx->net_dev->dev_id = EFX_OWORD_FIELD(reg, FRF_CZ_CS_PORT_NUM) - 1;
My test system has none of these, so dev_id does have the expected
value of 0 for all ports, same card or whatever, but in all of these
drivers appear to use 0 to mean first port too.
So, I'm not sure how useful this field is in practice today. Right
idea though...
Thanks,
Matt
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
^ permalink raw reply
* can i use udev rules to send a dbus signal
From: shaoning @ 2010-12-08 7:58 UTC (permalink / raw)
To: linux-hotplug
hi all
I met a problem . Does anybody help me ?
I wrote a udeve rules for ntfs filesystem mount , and i want to using
dbus-send to send a dbus signal .But it seems it can not work . When I
debuge, i saw /var/log/message said it send ok. But , in fact , it can
not work. Does anybody know this issue?
PS: When exec udev rules, it should be root , and i am using a normal
user to debug and see result.
[fan@fc13 rules.d]$ cat 10-media-by-label-auto-mount.rules |grep -v ^#
KERNEL!="sd[b-z][0-9]", GOTO="media_by_label_auto_mount_end"
IMPORT{program}="/sbin/blkid -o udev -p %N"
ENV{dir_name}="usb-%k"
ENV{DISPLAY}=":0.0"
ACTION="add", ENV{ID_FS_TYPE}="ntfs",
ENV{mount_options}="relatime,utf8,gid\x100,umask\02", RUN+="/bin/mkdir
-p /media/%E{dir_name}", RUN+="/bin/mount -t ntfs-3g -o
$env{mount_options} /dev/%k /media/%E{dir_name}",
RUN+="/usr/bin/nautilus --no-desktop /media/%E{dir_name}",
RUN+="/bin/dbus-send --session --type=signal /
com.zhou.dbustest.sayhelloworld"
ACTION="remove", RUN+="/bin/umount -l /media/%E{dir_name}",
RUN+="/bin/rmdir /media/%E{dir_name}"
LABEL="media_by_label_auto_mount_end"
[fan@fc13 rules.d]$
^ permalink raw reply
* Re: can i use udev rules to send a dbus signal
From: Martin Pitt @ 2010-12-08 15:04 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <4CFF3C7A.4010608@gmail.com>
Hello shaoning,
shaoning [2010-12-08 16:06 +0800]:
> ACTION="add", ENV{ID_FS_TYPE}="ntfs",
> ENV{mount_options}="relatime,utf8,gid\x100,umask\02", RUN+="/bin/mkdir
> -p /media/%E{dir_name}", RUN+="/bin/mount -t ntfs-3g -o
> $env{mount_options} /dev/%k /media/%E{dir_name}",
> RUN+="/usr/bin/nautilus --no-desktop /media/%E{dir_name}",
> RUN+="/bin/dbus-send --session --type=signal /
> com.zhou.dbustest.sayhelloworld"
This isn't going to work like this. udev rules are executed as root,
so this tries to start nautilus and dbus-send as root, neither of
which makes sense. root doesn't have a session d-bus running, so the
dbus-send will just shout into the void.
udev isn't meant to run stuff for users, that needs to happen in the
user's session. It's possible to use su, read xauth cookies etc. to
pick the first X.org session and run stuff there, but all these are
horrible, horrible hacks.
If you are already using GNOME components, what's wrong with using
udisks and running nautilus as the automount daemon? If you can't do
that in your setup, you could also use a lightweight automount daemon
like [1].
Martin
[1] http://www.piware.de/2010/09/simple-udisks-based-automount-daemon/
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
^ permalink raw reply
* [PATCH] udevadm-info: add query for properties with quoted output
From: harald @ 2010-12-09 14:26 UTC (permalink / raw)
To: linux-hotplug
From: Harald Hoyer <harald@redhat.com>
$ udevadm info --query=shproperty --name=/dev/sda
UDEV_LOG='3'
DEVPATH='/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda'
MAJOR='8'
MINOR='0'
DEVNAME='/dev/sda'
DEVTYPE='disk'
...
DEVLINKS='/dev/block/8:0 /dev/disk/by-id/ata-APPLE_SSD_TS128B_60CS105MT4RZ /dev/disk/by-id/scsi-SATA_APPLE_SSD_TS128_60CS105MT4RZ /dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0'
This enables the use of "eval" in shell scripts:
$ eval $(udevadm info --query=shenv --name=/dev/sda)
$ echo $DEVLINKS
/dev/block/8:0 /dev/disk/by-id/ata-APPLE_SSD_TS128B_60CS105MT4RZ /dev/disk/by-id/scsi-SATA_APPLE_SSD_TS128_60CS105MT4RZ /dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0
---
libudev/libudev-private.h | 1 +
libudev/libudev-util.c | 25 +++++++++++++++++++++++++
udev/udevadm-info.c | 19 +++++++++++++++++++
3 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/libudev/libudev-private.h b/libudev/libudev-private.h
index c9ed462..277a8bf 100644
--- a/libudev/libudev-private.h
+++ b/libudev/libudev-private.h
@@ -197,6 +197,7 @@ ssize_t util_get_sys_subsystem(struct udev *udev, const char *syspath, char *sub
ssize_t util_get_sys_driver(struct udev *udev, const char *syspath, char *driver, size_t size);
int util_resolve_sys_link(struct udev *udev, char *syspath, size_t size);
int util_log_priority(const char *priority);
+size_t util_shell_encode(const char *src, char *dest, size_t size);
size_t util_path_encode(const char *src, char *dest, size_t size);
size_t util_path_decode(char *s);
void util_remove_trailing_chars(char *path, char c);
diff --git a/libudev/libudev-util.c b/libudev/libudev-util.c
index 030b78c..12b2b3d 100644
--- a/libudev/libudev-util.c
+++ b/libudev/libudev-util.c
@@ -98,6 +98,31 @@ int util_log_priority(const char *priority)
return 0;
}
+size_t util_shell_encode(const char *src, char *dest, size_t size)
+{
+ size_t i, j;
+
+ for (i = 0, j = 0; src[i] != '\0'; i++) {
+ if (src[i] = '\'') {
+ if (j+4 >= size) {
+ j = 0;
+ break;
+ }
+ memcpy(&dest[j], "'\\''", 4);
+ j += 4;
+ } else {
+ if (j+1 >= size) {
+ j = 0;
+ break;
+ }
+ dest[j] = src[i];
+ j++;
+ }
+ }
+ dest[j] = '\0';
+ return j;
+}
+
size_t util_path_encode(const char *src, char *dest, size_t size)
{
size_t i, j;
diff --git a/udev/udevadm-info.c b/udev/udevadm-info.c
index 9bd60c7..6e0feea 100644
--- a/udev/udevadm-info.c
+++ b/udev/udevadm-info.c
@@ -235,6 +235,7 @@ int udevadm_info(struct udev *udev, int argc, char *argv[])
QUERY_PATH,
QUERY_SYMLINK,
QUERY_PROPERTY,
+ QUERY_PROPERTY_QUOTED,
QUERY_ALL,
} query = QUERY_NONE;
@@ -307,6 +308,8 @@ int udevadm_info(struct udev *udev, int argc, char *argv[])
action = ACTION_QUERY;
if (strcmp(optarg, "property") = 0 || strcmp(optarg, "env") = 0) {
query = QUERY_PROPERTY;
+ } else if (strcmp(optarg, "shproperty") = 0 || strcmp(optarg, "shenv") = 0) {
+ query = QUERY_PROPERTY_QUOTED;
} else if (strcmp(optarg, "name") = 0) {
query = QUERY_NAME;
} else if (strcmp(optarg, "symlink") = 0) {
@@ -352,6 +355,7 @@ int udevadm_info(struct udev *udev, int argc, char *argv[])
" symlink pointing to node\n"
" path sys device path\n"
" property the device properties\n"
+ " shproperty the device properties in shell style key='value'\n"
" all all values\n"
" --path=<syspath> sys device path used for query or attribute walk\n"
" --name=<name> node or symlink name used for query or attribute walk\n"
@@ -421,6 +425,21 @@ int udevadm_info(struct udev *udev, int argc, char *argv[])
list_entry = udev_list_entry_get_next(list_entry);
}
break;
+ case QUERY_PROPERTY_QUOTED:
+ list_entry = udev_device_get_properties_list_entry(device);
+ while (list_entry != NULL) {
+ char *val = NULL;
+ const char *oval = udev_list_entry_get_value(list_entry);
+ size_t len = strlen(oval)*4 + 1;
+ val = malloc(len);
+ if (val) {
+ util_shell_encode(oval, val, len);
+ printf("%s='%s'\n", udev_list_entry_get_name(list_entry), val);
+ list_entry = udev_list_entry_get_next(list_entry);
+ free(val);
+ }
+ }
+ break;
case QUERY_ALL:
print_record(device);
break;
--
1.7.3.2
^ permalink raw reply related
* Re: [PATCH] udevadm-info: add query for properties with quoted output
From: David Zeuthen @ 2010-12-09 18:03 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1291904793-7271-1-git-send-email-harald@redhat.com>
On Thu, Dec 9, 2010 at 9:26 AM, <harald@redhat.com> wrote:
> From: Harald Hoyer <harald@redhat.com>
>
> $ udevadm info --query=shproperty --name=/dev/sda
> UDEV_LOG='3'
> DEVPATH='/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda'
> MAJOR='8'
> MINOR='0'
> DEVNAME='/dev/sda'
> DEVTYPE='disk'
> ...
> DEVLINKS='/dev/block/8:0 /dev/disk/by-id/ata-APPLE_SSD_TS128B_60CS105MT4RZ /dev/disk/by-id/scsi-SATA_APPLE_SSD_TS128_60CS105MT4RZ /dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0'
>
> This enables the use of "eval" in shell scripts:
> $ eval $(udevadm info --query=shenv --name=/dev/sda)
> $ echo $DEVLINKS
> /dev/block/8:0 /dev/disk/by-id/ata-APPLE_SSD_TS128B_60CS105MT4RZ /dev/disk/by-id/scsi-SATA_APPLE_SSD_TS128_60CS105MT4RZ /dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0
Would be nice if you could prefix the resulting environment variables e.g.
$ eval $(udevadm info --query=shenv --shprefix=MY_NAMESPACE --name=/dev/sda)
$ echo $MY_NAMESPACE_DEVLINKS
/dev/block/8:0 /dev/disk/by-id/ata-APPLE_SSD_TS128B_60CS105MT4RZ
/dev/disk/by-id/scsi-SATA_APPLE_SSD_TS128_60CS105MT4RZ
/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0
to ensure that no existing variables gets overwritten. You probably
also want to patch the man pages.
Thanks,
David
^ permalink raw reply
* Re: [PATCH] udevadm-info: add query for properties with quoted output
From: Kay Sievers @ 2010-12-09 18:17 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1291904793-7271-1-git-send-email-harald@redhat.com>
On Thu, Dec 9, 2010 at 19:03, David Zeuthen <zeuthen@gmail.com> wrote:
> On Thu, Dec 9, 2010 at 9:26 AM, <harald@redhat.com> wrote:
>> From: Harald Hoyer <harald@redhat.com>
>>
>> $ udevadm info --query=shproperty --name=/dev/sda
>> UDEV_LOG='3'
>> DEVPATH='/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda'
>> MAJOR='8'
>> MINOR='0'
>> DEVNAME='/dev/sda'
>> DEVTYPE='disk'
>> ...
>> DEVLINKS='/dev/block/8:0 /dev/disk/by-id/ata-APPLE_SSD_TS128B_60CS105MT4RZ /dev/disk/by-id/scsi-SATA_APPLE_SSD_TS128_60CS105MT4RZ /dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0'
>>
>> This enables the use of "eval" in shell scripts:
>> $ eval $(udevadm info --query=shenv --name=/dev/sda)
>> $ echo $DEVLINKS
>> /dev/block/8:0 /dev/disk/by-id/ata-APPLE_SSD_TS128B_60CS105MT4RZ /dev/disk/by-id/scsi-SATA_APPLE_SSD_TS128_60CS105MT4RZ /dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0
>
> Would be nice if you could prefix the resulting environment variables e.g.
>
> $ eval $(udevadm info --query=shenv --shprefix=MY_NAMESPACE --name=/dev/sda)
> $ echo $MY_NAMESPACE_DEVLINKS
> /dev/block/8:0 /dev/disk/by-id/ata-APPLE_SSD_TS128B_60CS105MT4RZ
> /dev/disk/by-id/scsi-SATA_APPLE_SSD_TS128_60CS105MT4RZ
> /dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0
>
> to ensure that no existing variables gets overwritten. You probably
> also want to patch the man pages.
There is already --export, and --export-prefix for 'udevadm info'.
That can probably be re-used.
I think, the quotes we can just always unconditionally add, when we
have whitespace in the value.
Kay
^ permalink raw reply
* biosdevname v0.3.3
From: Matt Domsch @ 2010-12-09 21:51 UTC (permalink / raw)
To: linux-hotplug, netdev, K, Narendra, Hargrave, Jordan,
Rose, Charles, Co
biosdevname, now version 0.3.3.
I re-added the PCI IRQ Routing Table lookup code. This is used as a
fallback, in the event system BIOS doesn't provide index and label
information in a way we can get at via sysfs, or via reading SMBIOS
directly. This is necessary as quite a few systems I want to
have this feature on do not yet expose this info via SMBIOS, yet the
values in $PIR are perfectly usable for this purpose.
Grab it here:
http://linux.dell.com/files/biosdevname/permalink/biosdevname-0.3.3.tar.gz
http://linux.dell.com/files/biosdevname/permalink/biosdevname-0.3.3.tar.gz.sign
git://linux.dell.com/biosdevname.git
I built this today for Fedora rawhide (will be 15), and I encourage
other distributions to pick it up as well.
shortlog:
Matt Domsch (5):
add back in PCI IRQ Routing Table lookups, as a fallback
add in the pirq.[ch] files too
sort PCI device list, set embedded_index better, use PIRQ info
as a last resort
remove Dell-specific code from make_release.sh
bump version
Thanks,
Matt
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
^ permalink raw reply
* Re: [PATCH] x86, acpi: Handle all SRAT cpu entries even have cpu
From: H. Peter Anvin @ 2010-12-15 22:01 UTC (permalink / raw)
To: Yinghai Lu
Cc: Ingo Molnar, Andrew Morton, Thomas Gleixner, Wu Fengguang,
Peter Zijlstra, LKML, Nikanth Karthikesan, David Rientjes,
Zheng, Shaohui, linux-hotplug@vger.kernel.org, Eric Dumazet,
Bjorn Helgaas, Venkatesh Pallipadi, Nikhil Rao, Takuya Yoshikawa
In-Reply-To: <4CDF3DA1.2090806@kernel.org>
On 11/13/2010 05:38 PM, Yinghai Lu wrote:
> Index: linux-2.6/arch/x86/kernel/acpi/boot.c
> =================================> --- linux-2.6.orig/arch/x86/kernel/acpi/boot.c
> +++ linux-2.6/arch/x86/kernel/acpi/boot.c
> @@ -198,6 +198,13 @@ static void __cpuinit acpi_register_lapi
> {
> unsigned int ver = 0;
>
> +#ifdef CONFIG_X86_64
> + if (id >= (MAX_APICS-1)) {
> + printk(KERN_INFO PREFIX "skipped apicid that is too big\n");
> + return;
> + }
> +#endif
> +
> if (!enabled) {
> ++disabled_cpus;
> return;
Why the #ifdef?
> Index: linux-2.6/arch/x86/mm/srat_64.c
> =================================> --- linux-2.6.orig/arch/x86/mm/srat_64.c
> +++ linux-2.6/arch/x86/mm/srat_64.c
> @@ -134,6 +134,10 @@ acpi_numa_x2apic_affinity_init(struct ac
> }
>
> apic_id = pa->apic_id;
> + if (apic_id >= MAX_LOCAL_APIC) {
> + printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%04x -> Node %u skipped that apicid too big\n", pxm, apic_id, node);
> + return;
> + }
> apicid_to_node[apic_id] = node;
> node_set(node, cpu_nodes_parsed);
> acpi_numa = 1;
> @@ -168,6 +172,10 @@ acpi_numa_processor_affinity_init(struct
> apic_id = (pa->apic_id << 8) | pa->local_sapic_eid;
> else
> apic_id = pa->apic_id;
> + if (apic_id >= MAX_LOCAL_APIC) {
> + printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%02x -> Node %u skipped apicid that is too big\n", pxm, apic_id, node);
> + return;
> + }
> apicid_to_node[apic_id] = node;
> node_set(node, cpu_nodes_parsed);
> acpi_numa = 1;
> Index: linux-2.6/drivers/acpi/numa.c
> =================================> --- linux-2.6.orig/drivers/acpi/numa.c
> +++ linux-2.6/drivers/acpi/numa.c
> @@ -275,13 +275,23 @@ acpi_table_parse_srat(enum acpi_srat_typ
> int __init acpi_numa_init(void)
> {
> int ret = 0;
> + int nr_cpu_entries = nr_cpu_ids;
> +
> +#ifdef CONFIG_X86_64
> + /*
> + * Should not limit number with cpu num that will handle,
> + * SRAT cpu entries could have different order with that in MADT.
> + * So go over all cpu entries in SRAT to get apicid to node mapping.
> + */
> + nr_cpu_entries = MAX_LOCAL_APIC;
> +#endif
>
Same here...
-hpa
^ permalink raw reply
* Re: [PATCH] x86, acpi: Handle all SRAT cpu entries even have cpu
From: Yinghai Lu @ 2010-12-15 22:40 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Ingo Molnar, Andrew Morton, Thomas Gleixner, Wu Fengguang,
Peter Zijlstra, LKML, Nikanth Karthikesan, David Rientjes,
Zheng, Shaohui, linux-hotplug@vger.kernel.org, Eric Dumazet,
Bjorn Helgaas, Venkatesh Pallipadi, Nikhil Rao, Takuya Yoshikawa
In-Reply-To: <4D093ABB.4030206@zytor.com>
On 12/15/2010 02:01 PM, H. Peter Anvin wrote:
> On 11/13/2010 05:38 PM, Yinghai Lu wrote:
>> Index: linux-2.6/arch/x86/kernel/acpi/boot.c
>> =================================>> --- linux-2.6.orig/arch/x86/kernel/acpi/boot.c
>> +++ linux-2.6/arch/x86/kernel/acpi/boot.c
>> @@ -198,6 +198,13 @@ static void __cpuinit acpi_register_lapi
>> {
>> unsigned int ver = 0;
>>
>> +#ifdef CONFIG_X86_64
>> + if (id >= (MAX_APICS-1)) {
>> + printk(KERN_INFO PREFIX "skipped apicid that is too big\n");
>> + return;
>> + }
>> +#endif
>> +
>> if (!enabled) {
>> ++disabled_cpus;
>> return;
>
> Why the #ifdef?
try to limit the affects to 32bit's bunch sub arch etc.
Thanks
Yinghai
^ permalink raw reply
* Re: [PATCH] x86, acpi: Handle all SRAT cpu entries even have cpu
From: H. Peter Anvin @ 2010-12-15 22:53 UTC (permalink / raw)
To: Yinghai Lu
Cc: Ingo Molnar, Andrew Morton, Thomas Gleixner, Wu Fengguang,
Peter Zijlstra, LKML, Nikanth Karthikesan, David Rientjes,
Zheng, Shaohui, linux-hotplug@vger.kernel.org, Eric Dumazet,
Bjorn Helgaas, Venkatesh Pallipadi, Nikhil Rao, Takuya Yoshikawa
In-Reply-To: <4D0943D5.1090404@kernel.org>
On 12/15/2010 02:40 PM, Yinghai Lu wrote:
> On 12/15/2010 02:01 PM, H. Peter Anvin wrote:
>> On 11/13/2010 05:38 PM, Yinghai Lu wrote:
>>> Index: linux-2.6/arch/x86/kernel/acpi/boot.c
>>> =================================>>> --- linux-2.6.orig/arch/x86/kernel/acpi/boot.c
>>> +++ linux-2.6/arch/x86/kernel/acpi/boot.c
>>> @@ -198,6 +198,13 @@ static void __cpuinit acpi_register_lapi
>>> {
>>> unsigned int ver = 0;
>>>
>>> +#ifdef CONFIG_X86_64
>>> + if (id >= (MAX_APICS-1)) {
>>> + printk(KERN_INFO PREFIX "skipped apicid that is too big\n");
>>> + return;
>>> + }
>>> +#endif
>>> +
>>> if (!enabled) {
>>> ++disabled_cpus;
>>> return;
>>
>> Why the #ifdef?
>
> try to limit the affects to 32bit's bunch sub arch etc.
>
I really, really don't like that... we want more unification, not less...
-hpa
^ permalink raw reply
* Re: [PATCH] x86, acpi: Handle all SRAT cpu entries even have cpu
From: Yinghai Lu @ 2010-12-15 22:57 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Ingo Molnar, Andrew Morton, Thomas Gleixner, Wu Fengguang,
Peter Zijlstra, LKML, Nikanth Karthikesan, David Rientjes,
Zheng, Shaohui, linux-hotplug@vger.kernel.org, Eric Dumazet,
Bjorn Helgaas, Venkatesh Pallipadi, Nikhil Rao, Takuya Yoshikawa
In-Reply-To: <4D094703.7080701@zytor.com>
On 12/15/2010 02:53 PM, H. Peter Anvin wrote:
> On 12/15/2010 02:40 PM, Yinghai Lu wrote:
>> On 12/15/2010 02:01 PM, H. Peter Anvin wrote:
>>> On 11/13/2010 05:38 PM, Yinghai Lu wrote:
>>>> Index: linux-2.6/arch/x86/kernel/acpi/boot.c
>>>> =================================>>>> --- linux-2.6.orig/arch/x86/kernel/acpi/boot.c
>>>> +++ linux-2.6/arch/x86/kernel/acpi/boot.c
>>>> @@ -198,6 +198,13 @@ static void __cpuinit acpi_register_lapi
>>>> {
>>>> unsigned int ver = 0;
>>>>
>>>> +#ifdef CONFIG_X86_64
>>>> + if (id >= (MAX_APICS-1)) {
>>>> + printk(KERN_INFO PREFIX "skipped apicid that is too big\n");
>>>> + return;
>>>> + }
>>>> +#endif
>>>> +
>>>> if (!enabled) {
>>>> ++disabled_cpus;
>>>> return;
>>>
>>> Why the #ifdef?
>>
>> try to limit the affects to 32bit's bunch sub arch etc.
>>
>
> I really, really don't like that... we want more unification, not less...
ok, will try to remove them.
Yinghai
^ permalink raw reply
* [PATCH 1/2] x86, acpi: add MAX_LOCAL_APIC for 32bit
From: Yinghai Lu @ 2010-12-17 3:09 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Ingo Molnar, Andrew Morton, Thomas Gleixner, Wu Fengguang,
Peter Zijlstra, LKML, Nikanth Karthikesan, David Rientjes,
Zheng, Shaohui, linux-hotplug@vger.kernel.org, Eric Dumazet,
Bjorn Helgaas, Venkatesh Pallipadi, Nikhil Rao, Takuya Yoshikawa
In-Reply-To: <4D094703.7080701@zytor.com>
We should use MAX_LOCAL_APIC for max apic ids
and MAX_APICS as number of local apics.
also apic_version[] array should max apic id related.
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
---
arch/x86/include/asm/apicdef.h | 1 +
arch/x86/include/asm/mpspec.h | 2 +-
arch/x86/kernel/apic/apic.c | 2 +-
3 files changed, 3 insertions(+), 2 deletions(-)
Index: linux-2.6/arch/x86/include/asm/apicdef.h
=================================--- linux-2.6.orig/arch/x86/include/asm/apicdef.h
+++ linux-2.6/arch/x86/include/asm/apicdef.h
@@ -145,6 +145,7 @@
#ifdef CONFIG_X86_32
# define MAX_IO_APICS 64
+# define MAX_LOCAL_APIC 256
#else
# define MAX_IO_APICS 128
# define MAX_LOCAL_APIC 32768
Index: linux-2.6/arch/x86/kernel/apic/apic.c
=================================--- linux-2.6.orig/arch/x86/kernel/apic/apic.c
+++ linux-2.6/arch/x86/kernel/apic/apic.c
@@ -1689,7 +1689,7 @@ void __init register_lapic_address(unsig
* This initializes the IO-APIC and APIC hardware if this is
* a UP kernel.
*/
-int apic_version[MAX_APICS];
+int apic_version[MAX_LOCAL_APIC];
int __init APIC_init_uniprocessor(void)
{
Index: linux-2.6/arch/x86/include/asm/mpspec.h
=================================--- linux-2.6.orig/arch/x86/include/asm/mpspec.h
+++ linux-2.6/arch/x86/include/asm/mpspec.h
@@ -6,7 +6,7 @@
#include <asm/mpspec_def.h>
#include <asm/x86_init.h>
-extern int apic_version[MAX_APICS];
+extern int apic_version[];
extern int pic_mode;
#ifdef CONFIG_X86_32
^ permalink raw reply
* [PATCH -v2 2/2] x86, acpi: Parse all SRAT cpu entries even have cpu
From: Yinghai Lu @ 2010-12-17 3:09 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Ingo Molnar, Andrew Morton, Thomas Gleixner, Wu Fengguang,
Peter Zijlstra, LKML, Nikanth Karthikesan, David Rientjes,
Zheng, Shaohui, linux-hotplug@vger.kernel.org, Eric Dumazet,
Bjorn Helgaas, Venkatesh Pallipadi, Nikhil Rao, Takuya Yoshikawa
In-Reply-To: <4D0AD464.2020408@kernel.org>
Recent Intel new system have different order in MADT, aka will list all thread0
at first, then all thread1.
But SRAT table still old order, it will list cpus in one socket all together.
If the user have compiled limited NR_CPUS or boot with nr_cpus=, could have missed
to put some cpus apic id to node mapping into apicid_to_node[].
for example for 4 sockets system with 64 cpus with nr_cpus2 will get crash...
[ 9.106288] Total of 32 processors activated (136190.88 BogoMIPS).
[ 9.235021] divide error: 0000 [#1] SMP
[ 9.235315] last sysfs file:
[ 9.235481] CPU 1
[ 9.235592] Modules linked in:
[ 9.245398]
[ 9.245478] Pid: 2, comm: kthreadd Not tainted 2.6.37-rc1-tip-yh-01782-ge92ef79-dirty #274 /Sun Fire x4800
[ 9.265415] RIP: 0010:[<ffffffff81075a8f>] [<ffffffff81075a8f>] select_task_rq_fair+0x4f0/0x623
...
[ 9.645938] RIP [<ffffffff81075a8f>] select_task_rq_fair+0x4f0/0x623
[ 9.665356] RSP <ffff88103f8d1c40>
[ 9.665568] ---[ end trace 2296156d35fdfc87 ]---
So let just parse all cpu entries in SRAT.
Also add apicid checking with MAX_LOCAL_APIC, in case We could out of boundaries of
apicid_to_node[].
it fixes following bug too.
https://bugzilla.kernel.org/show_bug.cgi?id"662
-v2: expand to 32bit according to hpa
need to add MAX_LOCAL_APIC for 32bit
Reported-and-Tested-by: Wu Fengguang <fengguang.wu@intel.com>
Reported-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Tested-by: Myron Stowe <myron.stowe@hp.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
---
arch/x86/kernel/acpi/boot.c | 5 +++++
arch/x86/mm/srat_32.c | 1 +
arch/x86/mm/srat_64.c | 10 ++++++++++
drivers/acpi/numa.c | 14 ++++++++++++--
4 files changed, 28 insertions(+), 2 deletions(-)
Index: linux-2.6/arch/x86/kernel/acpi/boot.c
=================================--- linux-2.6.orig/arch/x86/kernel/acpi/boot.c
+++ linux-2.6/arch/x86/kernel/acpi/boot.c
@@ -198,6 +198,11 @@ static void __cpuinit acpi_register_lapi
{
unsigned int ver = 0;
+ if (id >= (MAX_LOCAL_APIC-1)) {
+ printk(KERN_INFO PREFIX "skipped apicid that is too big\n");
+ return;
+ }
+
if (!enabled) {
++disabled_cpus;
return;
Index: linux-2.6/arch/x86/mm/srat_64.c
=================================--- linux-2.6.orig/arch/x86/mm/srat_64.c
+++ linux-2.6/arch/x86/mm/srat_64.c
@@ -134,6 +134,10 @@ acpi_numa_x2apic_affinity_init(struct ac
}
apic_id = pa->apic_id;
+ if (apic_id >= MAX_LOCAL_APIC) {
+ printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%04x -> Node %u skipped apicid that is too big\n", pxm, apic_id, node);
+ return;
+ }
apicid_to_node[apic_id] = node;
node_set(node, cpu_nodes_parsed);
acpi_numa = 1;
@@ -168,6 +172,12 @@ acpi_numa_processor_affinity_init(struct
apic_id = (pa->apic_id << 8) | pa->local_sapic_eid;
else
apic_id = pa->apic_id;
+
+ if (apic_id >= MAX_LOCAL_APIC) {
+ printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%02x -> Node %u skipped apicid that is too big\n", pxm, apic_id, node);
+ return;
+ }
+
apicid_to_node[apic_id] = node;
node_set(node, cpu_nodes_parsed);
acpi_numa = 1;
Index: linux-2.6/drivers/acpi/numa.c
=================================--- linux-2.6.orig/drivers/acpi/numa.c
+++ linux-2.6/drivers/acpi/numa.c
@@ -275,13 +275,23 @@ acpi_table_parse_srat(enum acpi_srat_typ
int __init acpi_numa_init(void)
{
int ret = 0;
+ int nr_cpu_entries = nr_cpu_ids;
+
+#ifdef CONFIG_X86
+ /*
+ * Should not limit number with cpu num that is from NR_CPUS or nr_cpus+ * SRAT cpu entries could have different order with that in MADT.
+ * So go over all cpu entries in SRAT to get apicid to node mapping.
+ */
+ nr_cpu_entries = MAX_LOCAL_APIC;
+#endif
/* SRAT: Static Resource Affinity Table */
if (!acpi_table_parse(ACPI_SIG_SRAT, acpi_parse_srat)) {
acpi_table_parse_srat(ACPI_SRAT_TYPE_X2APIC_CPU_AFFINITY,
- acpi_parse_x2apic_affinity, nr_cpu_ids);
+ acpi_parse_x2apic_affinity, nr_cpu_entries);
acpi_table_parse_srat(ACPI_SRAT_TYPE_CPU_AFFINITY,
- acpi_parse_processor_affinity, nr_cpu_ids);
+ acpi_parse_processor_affinity, nr_cpu_entries);
ret = acpi_table_parse_srat(ACPI_SRAT_TYPE_MEMORY_AFFINITY,
acpi_parse_memory_affinity,
NR_NODE_MEMBLKS);
Index: linux-2.6/arch/x86/mm/srat_32.c
=================================--- linux-2.6.orig/arch/x86/mm/srat_32.c
+++ linux-2.6/arch/x86/mm/srat_32.c
@@ -92,6 +92,7 @@ acpi_numa_processor_affinity_init(struct
/* mark this node as "seen" in node bitmap */
BMAP_SET(pxm_bitmap, cpu_affinity->proximity_domain_lo);
+ /* don't need to check apic_id here, because it is always 8 bits */
apicid_to_pxm[cpu_affinity->apic_id] = cpu_affinity->proximity_domain_lo;
printk(KERN_DEBUG "CPU %02x in proximity domain %02x\n",
^ permalink raw reply
* biosdevname v0.3.4
From: Matt Domsch @ 2010-12-17 5:06 UTC (permalink / raw)
To: linux-hotplug, netdev, K, Narendra, Hargrave, Jordan,
Rose, Charles, Co
biosdevname, now version 0.3.4.
The main visible change is that port indices now start at 1 rather
than 0, when assigned by biosdevname (such as falling back to PIRQ)
rather explicitly assigned by BIOS. This is in keeping with how the
indices are assigned by BIOS on Dell and HP servers.
em<port> where port starts at 1
pci<slot>#<port> where port starts at 1
As a side effect, the first VMware Workstation guest NIC now appears as pci3#1
because the virtual machine BIOS exposes the device as being in a PCI
slot via PIRQ.
This also drops an explicit dependency check on a particular udev
version. That version was supposed to properly handle parallel
conflicting renames when swizzling within the ethX namespace, but as
we've discovered, that doesn't always work. The udev in RHEL5 is
older than what we were specifying, but it works just fine, so no more
check.
Furthermore, if biosdevname somehow messes up (either through its own
bug or because of a buggy BIOS), and would assign the same name to two
different devices, it won't try to assign names to either (who knows
which is correct?). You can see the duplciates when running with the
-d debug option.
Grab it here:
http://linux.dell.com/files/biosdevname/permalink/biosdevname-0.3.4.tar.gz
http://linux.dell.com/files/biosdevname/permalink/biosdevname-0.3.4.tar.gz.sign
git://linux.dell.com/biosdevname.git
I built this today for Fedora rawhide (will be 15), and I encourage
other distributions to pick it up as well.
shortlog:
Matt Domsch (5):
require any udev
Return nothing if duplicate names would be assigned.
Don't assign names to unknown devices
only supress duplicates, not all names if any duplicates exist
start with port index 1, not index 0
Thanks,
Matt
--
Matt Domsch
Technology Strategist
Dell | Office of the CTO
^ permalink raw reply
* [ANNOUNCE] udev 165 release
From: Kay Sievers @ 2010-12-17 14:49 UTC (permalink / raw)
To: linux-hotplug
Here comes a new udev version. Thanks to all who have contributed to
this release.
The tarball can be found here:
ftp://ftp.kernel.org/pub/linux/utils/kernel/hotplug/
The development repository can be found here:
http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=summary
The ChangeLog can be found here:
http://www.kernel.org/git/?p=linux/hotplug/udev.git;a=blob;hb=HEAD;f=ChangeLog
udev 165
====
Bugfixes.
The udev database has changed, After installation of a new udev
version, 'udevadm info --convert-db' should be called, to let the new
udev/libudev version read the already stored data.
udevadm now supports quoting of property values, and prefixing of
key names:
$ udevadm info --export --export-prefix=MY_ --query=property -n sda
MY_MAJOR='259'
MY_MINOR='0'
MY_DEVNAME='/dev/sda'
MY_DEVTYPE='disk'
...
libudev now supports:
udev_device_get_is_initialized()
udev_enumerate_add_match_is_initialized()
to be able to skip devices the kernel has created , but udev has
not already handled.
libudev now supports:
udev_device_get_usec_since_initialized()
to retrieve the "age" of a udev device record.
GUdev supports a more generic GUdevEnumerator class, udev TAG
handling, device initialization and timestamp now.
The counterpart of /sys/dev/{char,block}/$major:$minor,
/dev/{char,block}/$major:$minor symlinks are now unconditionally
created, even when no rule files exist.
New and updated keymaps.
^ permalink raw reply
* Re: [PATCH -v2 2/2] x86, acpi: Parse all SRAT cpu entries even have
From: Venkatesh Pallipadi @ 2010-12-17 18:53 UTC (permalink / raw)
To: Yinghai Lu
Cc: H. Peter Anvin, Ingo Molnar, Andrew Morton, Thomas Gleixner,
Wu Fengguang, Peter Zijlstra, LKML, Nikanth Karthikesan,
David Rientjes, Zheng, Shaohui, linux-hotplug@vger.kernel.org,
Eric Dumazet, Bjorn Helgaas, Nikhil Rao, Takuya Yoshikawa
In-Reply-To: <4D0AD486.9020704@kernel.org>
linus git + these two patches still fails on my test system with the
divide error. The failure dump is similar to what I reported here
http://lkml.indiana.edu/hypermail//linux/kernel/1012.1/03641.html
This patch description talk about new Intel systems. The test system I
am seeing failure here is an ancient Intel (2 socket P4 HT) system.
AFAICS, it does not even have an SRAT table (no "ACPI: SRAT" message
in dmesg).
Thanks,
Venki
On Thu, Dec 16, 2010 at 7:09 PM, Yinghai Lu <yinghai@kernel.org> wrote:
>
> Recent Intel new system have different order in MADT, aka will list all thread0
> at first, then all thread1.
> But SRAT table still old order, it will list cpus in one socket all together.
>
> If the user have compiled limited NR_CPUS or boot with nr_cpus=, could have missed
> to put some cpus apic id to node mapping into apicid_to_node[].
>
> for example for 4 sockets system with 64 cpus with nr_cpus2 will get crash...
>
> [ 9.106288] Total of 32 processors activated (136190.88 BogoMIPS).
> [ 9.235021] divide error: 0000 [#1] SMP
> [ 9.235315] last sysfs file:
> [ 9.235481] CPU 1
> [ 9.235592] Modules linked in:
> [ 9.245398]
> [ 9.245478] Pid: 2, comm: kthreadd Not tainted 2.6.37-rc1-tip-yh-01782-ge92ef79-dirty #274 /Sun Fire x4800
> [ 9.265415] RIP: 0010:[<ffffffff81075a8f>] [<ffffffff81075a8f>] select_task_rq_fair+0x4f0/0x623
> ...
> [ 9.645938] RIP [<ffffffff81075a8f>] select_task_rq_fair+0x4f0/0x623
> [ 9.665356] RSP <ffff88103f8d1c40>
> [ 9.665568] ---[ end trace 2296156d35fdfc87 ]---
>
> So let just parse all cpu entries in SRAT.
>
> Also add apicid checking with MAX_LOCAL_APIC, in case We could out of boundaries of
> apicid_to_node[].
>
> it fixes following bug too.
> https://bugzilla.kernel.org/show_bug.cgi?id"662
>
> -v2: expand to 32bit according to hpa
> need to add MAX_LOCAL_APIC for 32bit
>
> Reported-and-Tested-by: Wu Fengguang <fengguang.wu@intel.com>
> Reported-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
> Tested-by: Myron Stowe <myron.stowe@hp.com>
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
>
> ---
> arch/x86/kernel/acpi/boot.c | 5 +++++
> arch/x86/mm/srat_32.c | 1 +
> arch/x86/mm/srat_64.c | 10 ++++++++++
> drivers/acpi/numa.c | 14 ++++++++++++--
> 4 files changed, 28 insertions(+), 2 deletions(-)
>
> Index: linux-2.6/arch/x86/kernel/acpi/boot.c
> =================================> --- linux-2.6.orig/arch/x86/kernel/acpi/boot.c
> +++ linux-2.6/arch/x86/kernel/acpi/boot.c
> @@ -198,6 +198,11 @@ static void __cpuinit acpi_register_lapi
> {
> unsigned int ver = 0;
>
> + if (id >= (MAX_LOCAL_APIC-1)) {
> + printk(KERN_INFO PREFIX "skipped apicid that is too big\n");
> + return;
> + }
> +
> if (!enabled) {
> ++disabled_cpus;
> return;
> Index: linux-2.6/arch/x86/mm/srat_64.c
> =================================> --- linux-2.6.orig/arch/x86/mm/srat_64.c
> +++ linux-2.6/arch/x86/mm/srat_64.c
> @@ -134,6 +134,10 @@ acpi_numa_x2apic_affinity_init(struct ac
> }
>
> apic_id = pa->apic_id;
> + if (apic_id >= MAX_LOCAL_APIC) {
> + printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%04x -> Node %u skipped apicid that is too big\n", pxm, apic_id, node);
> + return;
> + }
> apicid_to_node[apic_id] = node;
> node_set(node, cpu_nodes_parsed);
> acpi_numa = 1;
> @@ -168,6 +172,12 @@ acpi_numa_processor_affinity_init(struct
> apic_id = (pa->apic_id << 8) | pa->local_sapic_eid;
> else
> apic_id = pa->apic_id;
> +
> + if (apic_id >= MAX_LOCAL_APIC) {
> + printk(KERN_INFO "SRAT: PXM %u -> APIC 0x%02x -> Node %u skipped apicid that is too big\n", pxm, apic_id, node);
> + return;
> + }
> +
> apicid_to_node[apic_id] = node;
> node_set(node, cpu_nodes_parsed);
> acpi_numa = 1;
> Index: linux-2.6/drivers/acpi/numa.c
> =================================> --- linux-2.6.orig/drivers/acpi/numa.c
> +++ linux-2.6/drivers/acpi/numa.c
> @@ -275,13 +275,23 @@ acpi_table_parse_srat(enum acpi_srat_typ
> int __init acpi_numa_init(void)
> {
> int ret = 0;
> + int nr_cpu_entries = nr_cpu_ids;
> +
> +#ifdef CONFIG_X86
> + /*
> + * Should not limit number with cpu num that is from NR_CPUS or nr_cpus> + * SRAT cpu entries could have different order with that in MADT.
> + * So go over all cpu entries in SRAT to get apicid to node mapping.
> + */
> + nr_cpu_entries = MAX_LOCAL_APIC;
> +#endif
>
> /* SRAT: Static Resource Affinity Table */
> if (!acpi_table_parse(ACPI_SIG_SRAT, acpi_parse_srat)) {
> acpi_table_parse_srat(ACPI_SRAT_TYPE_X2APIC_CPU_AFFINITY,
> - acpi_parse_x2apic_affinity, nr_cpu_ids);
> + acpi_parse_x2apic_affinity, nr_cpu_entries);
> acpi_table_parse_srat(ACPI_SRAT_TYPE_CPU_AFFINITY,
> - acpi_parse_processor_affinity, nr_cpu_ids);
> + acpi_parse_processor_affinity, nr_cpu_entries);
> ret = acpi_table_parse_srat(ACPI_SRAT_TYPE_MEMORY_AFFINITY,
> acpi_parse_memory_affinity,
> NR_NODE_MEMBLKS);
> Index: linux-2.6/arch/x86/mm/srat_32.c
> =================================> --- linux-2.6.orig/arch/x86/mm/srat_32.c
> +++ linux-2.6/arch/x86/mm/srat_32.c
> @@ -92,6 +92,7 @@ acpi_numa_processor_affinity_init(struct
> /* mark this node as "seen" in node bitmap */
> BMAP_SET(pxm_bitmap, cpu_affinity->proximity_domain_lo);
>
> + /* don't need to check apic_id here, because it is always 8 bits */
> apicid_to_pxm[cpu_affinity->apic_id] = cpu_affinity->proximity_domain_lo;
>
> printk(KERN_DEBUG "CPU %02x in proximity domain %02x\n",
>
^ permalink raw reply
* Re: [PATCH -v2 2/2] x86, acpi: Parse all SRAT cpu entries even have
From: Yinghai Lu @ 2010-12-17 19:27 UTC (permalink / raw)
To: Venkatesh Pallipadi
Cc: H. Peter Anvin, Ingo Molnar, Andrew Morton, Thomas Gleixner,
Wu Fengguang, Peter Zijlstra, LKML, Nikanth Karthikesan,
David Rientjes, Zheng, Shaohui, linux-hotplug@vger.kernel.org,
Eric Dumazet, Bjorn Helgaas, Nikhil Rao, Takuya Yoshikawa
In-Reply-To: <AANLkTin-LGig2RHHmvvy5H04jQRus_1mmS1Cr4KDWKsN@mail.gmail.com>
On 12/17/2010 10:53 AM, Venkatesh Pallipadi wrote:
> linus git + these two patches still fails on my test system with the
> divide error. The failure dump is similar to what I reported here
> http://lkml.indiana.edu/hypermail//linux/kernel/1012.1/03641.html
>
> This patch description talk about new Intel systems. The test system I
> am seeing failure here is an ancient Intel (2 socket P4 HT) system.
> AFAICS, it does not even have an SRAT table (no "ACPI: SRAT" message
> in dmesg).
that could be different cause.
Do you have whole boot log with debug etc?
^ permalink raw reply
* Re: [PATCH -v2 2/2] x86, acpi: Parse all SRAT cpu entries even have
From: Kay Sievers @ 2010-12-17 19:35 UTC (permalink / raw)
To: Yinghai Lu
Cc: Venkatesh Pallipadi, H. Peter Anvin, Ingo Molnar, Andrew Morton,
Thomas Gleixner, Wu Fengguang, Peter Zijlstra, LKML,
Nikanth Karthikesan, David Rientjes, Zheng, Shaohui,
linux-hotplug@vger.kernel.org, Eric Dumazet, Bjorn Helgaas,
Nikhil Rao, Takuya Yoshikawa
In-Reply-To: <4D0BB9AD.90506@kernel.org>
Guys, mind dropping linux-hotplug@ here? Linux-kernel@ should be
enough. This list is almost entirely about *userspace* hotplug issues.
Thanks,
Kay
On Fri, Dec 17, 2010 at 20:27, Yinghai Lu <yinghai@kernel.org> wrote:
> On 12/17/2010 10:53 AM, Venkatesh Pallipadi wrote:
>> linus git + these two patches still fails on my test system with the
>> divide error. The failure dump is similar to what I reported here
>> http://lkml.indiana.edu/hypermail//linux/kernel/1012.1/03641.html
>>
>> This patch description talk about new Intel systems. The test system I
>> am seeing failure here is an ancient Intel (2 socket P4 HT) system.
>> AFAICS, it does not even have an SRAT table (no "ACPI: SRAT" message
>> in dmesg).
>
> that could be different cause.
>
> Do you have whole boot log with debug etc?
>
> --
> 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: [PATCH 1/2] x86, acpi: add MAX_LOCAL_APIC for 32bit
From: David Rientjes @ 2010-12-17 20:56 UTC (permalink / raw)
To: Yinghai Lu
Cc: H. Peter Anvin, Ingo Molnar, Andrew Morton, Thomas Gleixner,
Wu Fengguang, Peter Zijlstra, LKML, Nikanth Karthikesan,
Zheng, Shaohui, linux-hotplug@vger.kernel.org, Eric Dumazet,
Bjorn Helgaas, Venkatesh Pallipadi, Nikhil Rao, Takuya Yoshikawa,
Tejun Heo
In-Reply-To: <4D0AD464.2020408@kernel.org>
On Thu, 16 Dec 2010, Yinghai Lu wrote:
> Index: linux-2.6/arch/x86/include/asm/apicdef.h
> =================================> --- linux-2.6.orig/arch/x86/include/asm/apicdef.h
> +++ linux-2.6/arch/x86/include/asm/apicdef.h
> @@ -145,6 +145,7 @@
>
> #ifdef CONFIG_X86_32
> # define MAX_IO_APICS 64
> +# define MAX_LOCAL_APIC 256
> #else
> # define MAX_IO_APICS 128
> # define MAX_LOCAL_APIC 32768
> Index: linux-2.6/arch/x86/kernel/apic/apic.c
> =================================> --- linux-2.6.orig/arch/x86/kernel/apic/apic.c
> +++ linux-2.6/arch/x86/kernel/apic/apic.c
> @@ -1689,7 +1689,7 @@ void __init register_lapic_address(unsig
> * This initializes the IO-APIC and APIC hardware if this is
> * a UP kernel.
> */
> -int apic_version[MAX_APICS];
> +int apic_version[MAX_LOCAL_APIC];
>
> int __init APIC_init_uniprocessor(void)
> {
> Index: linux-2.6/arch/x86/include/asm/mpspec.h
> =================================> --- linux-2.6.orig/arch/x86/include/asm/mpspec.h
> +++ linux-2.6/arch/x86/include/asm/mpspec.h
> @@ -6,7 +6,7 @@
> #include <asm/mpspec_def.h>
> #include <asm/x86_init.h>
>
> -extern int apic_version[MAX_APICS];
> +extern int apic_version[];
> extern int pic_mode;
>
> #ifdef CONFIG_X86_32
>
This looks like it duplicates and conflicts with Tejun's NUMA unification
patchset, specifically http://marc.info/?l=linux-kernel&m\x129087155712396
^ permalink raw reply
* Udev rule $attr substitution
From: Josua Dietze @ 2010-12-21 18:47 UTC (permalink / raw)
To: linux-hotplug
Hi, everyone!
I'm scratching my head over this:
Rule line:
KERNEL="ttyUSB*" RUN+="myprog %p %s{idVendor} %s{idProduct}"
%p expands to something like:
/devices/pci0000:00/0000:00:1d.7/usb1/1-5/1-5:1.2/ttyUSB2/tty/ttyUSB2
But the %s (or $attr) format string will not be substituted with anything when
using udev version 157. The same rule works fine with version 125.
When doing the attribute walk with "udevadm info", the attributes are of course
found in the parent chain.
Did I miss something?
^ 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