* Re: udev 95-keyboard-force-release.rules patch
From: Martin Pitt @ 2014-01-29 15:15 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CA+PiDdZAKJ61T6J5hMRCgCmN1=1Wq4NSCbdocmz_AccCW-aBtg@mail.gmail.com>
Hey Aleksander,
Aleksander Kowalski [2014-01-29 14:40 +0000]:
> I didn't respond because I use slackware which doesn't include systemd
> at all. I added the diff file previously as an email attachment, maybe
> this wasn't the right way to do it. Here it is as plain text:
Hm, the mail I had had no attachment at all. No idea where things went
wrong. Anyway..
> +ENV{DMI_VENDOR}="TOSHIBA", ATTR{[dmi/id]product_name}="Satellite
> [uU]300*|Satellite Pro [uU]300*|Satellite [uU]305*|SATELLITE
> [uU]500*|EQUIUM U300*", RUN+="keyboard-force-release.sh $devpath
> common-volume-keys"
Translated to hwdb and applied:
http://cgit.freedesktop.org/systemd/systemd/commit/?id…cf047
Thanks!
Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
--
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
* Reordered network interface names
From: Arkadiusz Bubała @ 2014-02-03 9:47 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 1741 bytes --]
Hello,
I have server with S5520UR motherboard running Debian Etch (with the
latest mainline kernel 3.4). This motherboard has two integrated ports:
01:00.0 Ethernet controller [0200]: Intel Corporation 82575EB Gigabit
Network Connection [8086:10a7] (rev 02)
01:00.1 Ethernet controller [0200]: Intel Corporation 82575EB Gigabit
Network Connection [8086:10a7] (rev 02)
There also additional network adapters attached:
03:00.0 Ethernet controller [0200]: Intel Corporation 82599ES 10-Gigabit
SFI/SFP+ Network Connection [8086:10fb] (rev 01)
03:00.1 Ethernet controller [0200]: Intel Corporation 82599ES 10-Gigabit
SFI/SFP+ Network Connection [8086:10fb] (rev 01)
07:00.0 Ethernet controller [0200]: Intel Corporation 82576 Gigabit
Network Connection [8086:10c9] (rev 01)
07:00.1 Ethernet controller [0200]: Intel Corporation 82576 Gigabit
Network Connection [8086:10c9] (rev 01)
0a:00.0 Ethernet controller [0200]: Intel Corporation 82576 Gigabit
Network Connection [8086:10c9] (rev 01)
0a:00.1 Ethernet controller [0200]: Intel Corporation 82576 Gigabit
Network Connection [8086:10c9] (rev 01)
Rarely after reboot interfaces are reordered and one of them is named
eth1_rename (about 20 reboots is needed to reproduce this issue). I
tried to update udev but this didn't resolve this issue. I also tried
running udev with debug-trace but it caused that only eth0 didn't have
"_rename" suffix.
I attached udev rules file, udevinfo output. I also have full logs from
udevmonitor if needed (I have problems with attaching this file it has
1MB uncompressed and 100kB compressed).
Could you give me any advices how to solve this issue?
Thank you in advance.
PS I can't reproduce this issue on Linux kernel 2.6.35.
Best regards,
Arkadiusz
[-- Attachment #2: eth.rules --]
[-- Type: text/plain, Size: 1198 bytes --]
# This file was automatically generated by the /lib/udev/write_net_rules
# program, probably run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single line.
# MAC addresses must be written in lowercase.
# PCI device 0x8086:0x10fb (ixgbe)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:1b:21:6e:6c:10", NAME="eth1"
# PCI device 0x8086:0x10fb (ixgbe)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:1b:21:6e:6c:11", NAME="eth3"
# PCI device 0x8086:0x10a7 (igb)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:15:17:aa:eb:e8", NAME="eth0"
# PCI device 0x8086:0x10c9 (igb)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:15:17:ba:4f:30", NAME="eth4"
# PCI device 0x8086:0x10c9 (igb)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:15:17:ba:4f:31", NAME="eth5"
# PCI device 0x8086:0x10c9 (igb)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:15:17:ba:4f:32", NAME="eth6"
# PCI device 0x8086:0x10c9 (igb)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:15:17:ba:4f:33", NAME="eth7"
# PCI device 0x8086:0x10a7 (igb)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:15:17:aa:eb:e9", NAME="eth2"
[-- Attachment #3: eth0.log --]
[-- Type: text/x-log, Size: 2570 bytes --]
Udevinfo starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '/devices/pci0000:00/0000:00:01.0/0000:01:00.1/net/eth0':
KERNEL=="eth0"
SUBSYSTEM=="net"
DRIVER==""
ATTR{mtu}=="1500"
ATTR{type}=="1"
ATTR{netdev_group}=="0"
ATTR{flags}=="0x1003"
ATTR{speed}=="1000"
ATTR{dormant}=="0"
ATTR{addr_assign_type}=="0"
ATTR{dev_id}=="0x0"
ATTR{duplex}=="full"
ATTR{iflink}=="6"
ATTR{addr_len}=="6"
ATTR{address}=="00:15:17:aa:eb:e9"
ATTR{operstate}=="up"
ATTR{broadcast}=="ff:ff:ff:ff:ff:ff"
ATTR{tx_queue_len}=="1000"
ATTR{ifalias}==""
ATTR{ifindex}=="6"
ATTR{link_mode}=="0"
ATTR{carrier}=="1"
looking at parent device '/devices/pci0000:00/0000:00:01.0/0000:01:00.1/net':
KERNELS=="net"
SUBSYSTEMS==""
DRIVERS==""
looking at parent device '/devices/pci0000:00/0000:00:01.0/0000:01:00.1':
KERNELS=="0000:01:00.1"
SUBSYSTEMS=="pci"
DRIVERS=="igb"
ATTRS{irq}=="28"
ATTRS{subsystem_vendor}=="0x8086"
ATTRS{broken_parity_status}=="0"
ATTRS{class}=="0x020000"
ATTRS{consistent_dma_mask_bits}=="64"
ATTRS{modalias}=="pci:v00008086d000010A7sv00008086sd000034DEbc02sc00i00"
ATTRS{dma_mask_bits}=="64"
ATTRS{local_cpus}=="00000000,00000000,00000000,0000ffff"
ATTRS{device}=="0x10a7"
ATTRS{enable}=="1"
ATTRS{msi_bus}==""
ATTRS{local_cpulist}=="0-15"
ATTRS{vendor}=="0x8086"
ATTRS{subsystem_device}=="0x34de"
ATTRS{numa_node}=="-1"
looking at parent device '/devices/pci0000:00/0000:00:01.0':
KERNELS=="0000:00:01.0"
SUBSYSTEMS=="pci"
DRIVERS=="pcieport"
ATTRS{irq}=="64"
ATTRS{subsystem_vendor}=="0x8086"
ATTRS{broken_parity_status}=="0"
ATTRS{class}=="0x060400"
ATTRS{consistent_dma_mask_bits}=="32"
ATTRS{modalias}=="pci:v00008086d00003408sv00008086sd000034DEbc06sc04i00"
ATTRS{dma_mask_bits}=="32"
ATTRS{local_cpus}=="00000000,00000000,00000000,0000ffff"
ATTRS{device}=="0x3408"
ATTRS{enable}=="2"
ATTRS{msi_bus}=="1"
ATTRS{local_cpulist}=="0-15"
ATTRS{vendor}=="0x8086"
ATTRS{subsystem_device}=="0x34de"
ATTRS{numa_node}=="-1"
looking at parent device '/devices/pci0000:00':
KERNELS=="pci0000:00"
SUBSYSTEMS==""
DRIVERS==""
ATTRS{uevent}==""
[-- Attachment #4: eth1.log --]
[-- Type: text/x-log, Size: 2573 bytes --]
Udevinfo starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '/devices/pci0000:00/0000:00:05.0/0000:03:00.0/net/eth1':
KERNEL=="eth1"
SUBSYSTEM=="net"
DRIVER==""
ATTR{mtu}=="1500"
ATTR{type}=="1"
ATTR{netdev_group}=="0"
ATTR{flags}=="0x1003"
ATTR{speed}=="10000"
ATTR{dormant}=="0"
ATTR{addr_assign_type}=="0"
ATTR{dev_id}=="0x0"
ATTR{duplex}=="full"
ATTR{iflink}=="3"
ATTR{addr_len}=="6"
ATTR{address}=="00:1b:21:6e:6c:10"
ATTR{operstate}=="up"
ATTR{broadcast}=="ff:ff:ff:ff:ff:ff"
ATTR{tx_queue_len}=="1000"
ATTR{ifalias}==""
ATTR{ifindex}=="3"
ATTR{link_mode}=="0"
ATTR{carrier}=="1"
looking at parent device '/devices/pci0000:00/0000:00:05.0/0000:03:00.0/net':
KERNELS=="net"
SUBSYSTEMS==""
DRIVERS==""
looking at parent device '/devices/pci0000:00/0000:00:05.0/0000:03:00.0':
KERNELS=="0000:03:00.0"
SUBSYSTEMS=="pci"
DRIVERS=="ixgbe"
ATTRS{irq}=="26"
ATTRS{subsystem_vendor}=="0x8086"
ATTRS{broken_parity_status}=="0"
ATTRS{class}=="0x020000"
ATTRS{consistent_dma_mask_bits}=="64"
ATTRS{modalias}=="pci:v00008086d000010FBsv00008086sd00000003bc02sc00i00"
ATTRS{dma_mask_bits}=="64"
ATTRS{local_cpus}=="00000000,00000000,00000000,0000ffff"
ATTRS{device}=="0x10fb"
ATTRS{enable}=="1"
ATTRS{msi_bus}==""
ATTRS{local_cpulist}=="0-15"
ATTRS{vendor}=="0x8086"
ATTRS{subsystem_device}=="0x0003"
ATTRS{numa_node}=="-1"
looking at parent device '/devices/pci0000:00/0000:00:05.0':
KERNELS=="0000:00:05.0"
SUBSYSTEMS=="pci"
DRIVERS=="pcieport"
ATTRS{irq}=="66"
ATTRS{subsystem_vendor}=="0x8086"
ATTRS{broken_parity_status}=="0"
ATTRS{class}=="0x060400"
ATTRS{consistent_dma_mask_bits}=="32"
ATTRS{modalias}=="pci:v00008086d0000340Csv00008086sd000034DEbc06sc04i00"
ATTRS{dma_mask_bits}=="32"
ATTRS{local_cpus}=="00000000,00000000,00000000,0000ffff"
ATTRS{device}=="0x340c"
ATTRS{enable}=="2"
ATTRS{msi_bus}=="1"
ATTRS{local_cpulist}=="0-15"
ATTRS{vendor}=="0x8086"
ATTRS{subsystem_device}=="0x34de"
ATTRS{numa_node}=="-1"
looking at parent device '/devices/pci0000:00':
KERNELS=="pci0000:00"
SUBSYSTEMS==""
DRIVERS==""
ATTRS{uevent}==""
[-- Attachment #5: eth1_rename.log --]
[-- Type: text/x-log, Size: 2491 bytes --]
Udevinfo starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '/devices/pci0000:00/0000:00:01.0/0000:01:00.0/net/eth1_rename':
KERNEL=="eth1_rename"
SUBSYSTEM=="net"
DRIVER==""
ATTR{mtu}=="1500"
ATTR{type}=="1"
ATTR{netdev_group}=="0"
ATTR{flags}=="0x1002"
ATTR{addr_assign_type}=="0"
ATTR{dev_id}=="0x0"
ATTR{iflink}=="4"
ATTR{addr_len}=="6"
ATTR{address}=="00:15:17:aa:eb:e8"
ATTR{operstate}=="down"
ATTR{broadcast}=="ff:ff:ff:ff:ff:ff"
ATTR{tx_queue_len}=="1000"
ATTR{ifalias}==""
ATTR{ifindex}=="4"
ATTR{link_mode}=="0"
looking at parent device '/devices/pci0000:00/0000:00:01.0/0000:01:00.0/net':
KERNELS=="net"
SUBSYSTEMS==""
DRIVERS==""
looking at parent device '/devices/pci0000:00/0000:00:01.0/0000:01:00.0':
KERNELS=="0000:01:00.0"
SUBSYSTEMS=="pci"
DRIVERS=="igb"
ATTRS{irq}=="40"
ATTRS{subsystem_vendor}=="0x8086"
ATTRS{broken_parity_status}=="0"
ATTRS{class}=="0x020000"
ATTRS{consistent_dma_mask_bits}=="64"
ATTRS{modalias}=="pci:v00008086d000010A7sv00008086sd000034DEbc02sc00i00"
ATTRS{dma_mask_bits}=="64"
ATTRS{local_cpus}=="00000000,00000000,00000000,0000ffff"
ATTRS{device}=="0x10a7"
ATTRS{enable}=="1"
ATTRS{msi_bus}==""
ATTRS{local_cpulist}=="0-15"
ATTRS{vendor}=="0x8086"
ATTRS{subsystem_device}=="0x34de"
ATTRS{numa_node}=="-1"
looking at parent device '/devices/pci0000:00/0000:00:01.0':
KERNELS=="0000:00:01.0"
SUBSYSTEMS=="pci"
DRIVERS=="pcieport"
ATTRS{irq}=="64"
ATTRS{subsystem_vendor}=="0x8086"
ATTRS{broken_parity_status}=="0"
ATTRS{class}=="0x060400"
ATTRS{consistent_dma_mask_bits}=="32"
ATTRS{modalias}=="pci:v00008086d00003408sv00008086sd000034DEbc06sc04i00"
ATTRS{dma_mask_bits}=="32"
ATTRS{local_cpus}=="00000000,00000000,00000000,0000ffff"
ATTRS{device}=="0x3408"
ATTRS{enable}=="2"
ATTRS{msi_bus}=="1"
ATTRS{local_cpulist}=="0-15"
ATTRS{vendor}=="0x8086"
ATTRS{subsystem_device}=="0x34de"
ATTRS{numa_node}=="-1"
looking at parent device '/devices/pci0000:00':
KERNELS=="pci0000:00"
SUBSYSTEMS==""
DRIVERS==""
ATTRS{uevent}==""
[-- Attachment #6: eth3.log --]
[-- Type: text/x-log, Size: 2575 bytes --]
Udevinfo starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '/devices/pci0000:00/0000:00:05.0/0000:03:00.1/net/eth3':
KERNEL=="eth3"
SUBSYSTEM=="net"
DRIVER==""
ATTR{mtu}=="1500"
ATTR{type}=="1"
ATTR{netdev_group}=="0"
ATTR{flags}=="0x1003"
ATTR{speed}=="65535"
ATTR{dormant}=="0"
ATTR{addr_assign_type}=="0"
ATTR{dev_id}=="0x0"
ATTR{duplex}=="full"
ATTR{iflink}=="5"
ATTR{addr_len}=="6"
ATTR{address}=="00:1b:21:6e:6c:11"
ATTR{operstate}=="down"
ATTR{broadcast}=="ff:ff:ff:ff:ff:ff"
ATTR{tx_queue_len}=="1000"
ATTR{ifalias}==""
ATTR{ifindex}=="5"
ATTR{link_mode}=="0"
ATTR{carrier}=="0"
looking at parent device '/devices/pci0000:00/0000:00:05.0/0000:03:00.1/net':
KERNELS=="net"
SUBSYSTEMS==""
DRIVERS==""
looking at parent device '/devices/pci0000:00/0000:00:05.0/0000:03:00.1':
KERNELS=="0000:03:00.1"
SUBSYSTEMS=="pci"
DRIVERS=="ixgbe"
ATTRS{irq}=="25"
ATTRS{subsystem_vendor}=="0x8086"
ATTRS{broken_parity_status}=="0"
ATTRS{class}=="0x020000"
ATTRS{consistent_dma_mask_bits}=="64"
ATTRS{modalias}=="pci:v00008086d000010FBsv00008086sd00000003bc02sc00i00"
ATTRS{dma_mask_bits}=="64"
ATTRS{local_cpus}=="00000000,00000000,00000000,0000ffff"
ATTRS{device}=="0x10fb"
ATTRS{enable}=="1"
ATTRS{msi_bus}==""
ATTRS{local_cpulist}=="0-15"
ATTRS{vendor}=="0x8086"
ATTRS{subsystem_device}=="0x0003"
ATTRS{numa_node}=="-1"
looking at parent device '/devices/pci0000:00/0000:00:05.0':
KERNELS=="0000:00:05.0"
SUBSYSTEMS=="pci"
DRIVERS=="pcieport"
ATTRS{irq}=="66"
ATTRS{subsystem_vendor}=="0x8086"
ATTRS{broken_parity_status}=="0"
ATTRS{class}=="0x060400"
ATTRS{consistent_dma_mask_bits}=="32"
ATTRS{modalias}=="pci:v00008086d0000340Csv00008086sd000034DEbc06sc04i00"
ATTRS{dma_mask_bits}=="32"
ATTRS{local_cpus}=="00000000,00000000,00000000,0000ffff"
ATTRS{device}=="0x340c"
ATTRS{enable}=="2"
ATTRS{msi_bus}=="1"
ATTRS{local_cpulist}=="0-15"
ATTRS{vendor}=="0x8086"
ATTRS{subsystem_device}=="0x34de"
ATTRS{numa_node}=="-1"
looking at parent device '/devices/pci0000:00':
KERNELS=="pci0000:00"
SUBSYSTEMS==""
DRIVERS==""
ATTRS{uevent}==""
[-- Attachment #7: eth4.log --]
[-- Type: text/x-log, Size: 2570 bytes --]
Udevinfo starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '/devices/pci0000:00/0000:00:09.0/0000:07:00.0/net/eth4':
KERNEL=="eth4"
SUBSYSTEM=="net"
DRIVER==""
ATTR{mtu}=="1500"
ATTR{type}=="1"
ATTR{netdev_group}=="0"
ATTR{flags}=="0x1003"
ATTR{speed}=="1000"
ATTR{dormant}=="0"
ATTR{addr_assign_type}=="0"
ATTR{dev_id}=="0x0"
ATTR{duplex}=="full"
ATTR{iflink}=="7"
ATTR{addr_len}=="6"
ATTR{address}=="00:15:17:ba:4f:30"
ATTR{operstate}=="up"
ATTR{broadcast}=="ff:ff:ff:ff:ff:ff"
ATTR{tx_queue_len}=="1000"
ATTR{ifalias}==""
ATTR{ifindex}=="7"
ATTR{link_mode}=="0"
ATTR{carrier}=="1"
looking at parent device '/devices/pci0000:00/0000:00:09.0/0000:07:00.0/net':
KERNELS=="net"
SUBSYSTEMS==""
DRIVERS==""
looking at parent device '/devices/pci0000:00/0000:00:09.0/0000:07:00.0':
KERNELS=="0000:07:00.0"
SUBSYSTEMS=="pci"
DRIVERS=="igb"
ATTRS{irq}=="32"
ATTRS{subsystem_vendor}=="0x0000"
ATTRS{broken_parity_status}=="0"
ATTRS{class}=="0x020000"
ATTRS{consistent_dma_mask_bits}=="64"
ATTRS{modalias}=="pci:v00008086d000010C9sv00000000sd00003550bc02sc00i00"
ATTRS{dma_mask_bits}=="64"
ATTRS{local_cpus}=="00000000,00000000,00000000,0000ffff"
ATTRS{device}=="0x10c9"
ATTRS{enable}=="1"
ATTRS{msi_bus}==""
ATTRS{local_cpulist}=="0-15"
ATTRS{vendor}=="0x8086"
ATTRS{subsystem_device}=="0x3550"
ATTRS{numa_node}=="-1"
looking at parent device '/devices/pci0000:00/0000:00:09.0':
KERNELS=="0000:00:09.0"
SUBSYSTEMS=="pci"
DRIVERS=="pcieport"
ATTRS{irq}=="68"
ATTRS{subsystem_vendor}=="0x8086"
ATTRS{broken_parity_status}=="0"
ATTRS{class}=="0x060400"
ATTRS{consistent_dma_mask_bits}=="32"
ATTRS{modalias}=="pci:v00008086d00003410sv00008086sd000034DEbc06sc04i00"
ATTRS{dma_mask_bits}=="32"
ATTRS{local_cpus}=="00000000,00000000,00000000,0000ffff"
ATTRS{device}=="0x3410"
ATTRS{enable}=="2"
ATTRS{msi_bus}=="1"
ATTRS{local_cpulist}=="0-15"
ATTRS{vendor}=="0x8086"
ATTRS{subsystem_device}=="0x34de"
ATTRS{numa_node}=="-1"
looking at parent device '/devices/pci0000:00':
KERNELS=="pci0000:00"
SUBSYSTEMS==""
DRIVERS==""
ATTRS{uevent}==""
[-- Attachment #8: eth5.log --]
[-- Type: text/x-log, Size: 2570 bytes --]
Udevinfo starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '/devices/pci0000:00/0000:00:09.0/0000:07:00.1/net/eth5':
KERNEL=="eth5"
SUBSYSTEM=="net"
DRIVER==""
ATTR{mtu}=="1500"
ATTR{type}=="1"
ATTR{netdev_group}=="0"
ATTR{flags}=="0x1003"
ATTR{speed}=="1000"
ATTR{dormant}=="0"
ATTR{addr_assign_type}=="0"
ATTR{dev_id}=="0x0"
ATTR{duplex}=="full"
ATTR{iflink}=="8"
ATTR{addr_len}=="6"
ATTR{address}=="00:15:17:ba:4f:31"
ATTR{operstate}=="up"
ATTR{broadcast}=="ff:ff:ff:ff:ff:ff"
ATTR{tx_queue_len}=="1000"
ATTR{ifalias}==""
ATTR{ifindex}=="8"
ATTR{link_mode}=="0"
ATTR{carrier}=="1"
looking at parent device '/devices/pci0000:00/0000:00:09.0/0000:07:00.1/net':
KERNELS=="net"
SUBSYSTEMS==""
DRIVERS==""
looking at parent device '/devices/pci0000:00/0000:00:09.0/0000:07:00.1':
KERNELS=="0000:07:00.1"
SUBSYSTEMS=="pci"
DRIVERS=="igb"
ATTRS{irq}=="42"
ATTRS{subsystem_vendor}=="0x0000"
ATTRS{broken_parity_status}=="0"
ATTRS{class}=="0x020000"
ATTRS{consistent_dma_mask_bits}=="64"
ATTRS{modalias}=="pci:v00008086d000010C9sv00000000sd00003550bc02sc00i00"
ATTRS{dma_mask_bits}=="64"
ATTRS{local_cpus}=="00000000,00000000,00000000,0000ffff"
ATTRS{device}=="0x10c9"
ATTRS{enable}=="1"
ATTRS{msi_bus}==""
ATTRS{local_cpulist}=="0-15"
ATTRS{vendor}=="0x8086"
ATTRS{subsystem_device}=="0x3550"
ATTRS{numa_node}=="-1"
looking at parent device '/devices/pci0000:00/0000:00:09.0':
KERNELS=="0000:00:09.0"
SUBSYSTEMS=="pci"
DRIVERS=="pcieport"
ATTRS{irq}=="68"
ATTRS{subsystem_vendor}=="0x8086"
ATTRS{broken_parity_status}=="0"
ATTRS{class}=="0x060400"
ATTRS{consistent_dma_mask_bits}=="32"
ATTRS{modalias}=="pci:v00008086d00003410sv00008086sd000034DEbc06sc04i00"
ATTRS{dma_mask_bits}=="32"
ATTRS{local_cpus}=="00000000,00000000,00000000,0000ffff"
ATTRS{device}=="0x3410"
ATTRS{enable}=="2"
ATTRS{msi_bus}=="1"
ATTRS{local_cpulist}=="0-15"
ATTRS{vendor}=="0x8086"
ATTRS{subsystem_device}=="0x34de"
ATTRS{numa_node}=="-1"
looking at parent device '/devices/pci0000:00':
KERNELS=="pci0000:00"
SUBSYSTEMS==""
DRIVERS==""
ATTRS{uevent}==""
[-- Attachment #9: eth6.log --]
[-- Type: text/x-log, Size: 2570 bytes --]
Udevinfo starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '/devices/pci0000:00/0000:00:0a.0/0000:0a:00.0/net/eth6':
KERNEL=="eth6"
SUBSYSTEM=="net"
DRIVER==""
ATTR{mtu}=="1500"
ATTR{type}=="1"
ATTR{netdev_group}=="0"
ATTR{flags}=="0x1003"
ATTR{speed}=="1000"
ATTR{dormant}=="0"
ATTR{addr_assign_type}=="0"
ATTR{dev_id}=="0x0"
ATTR{duplex}=="full"
ATTR{iflink}=="9"
ATTR{addr_len}=="6"
ATTR{address}=="00:15:17:ba:4f:32"
ATTR{operstate}=="up"
ATTR{broadcast}=="ff:ff:ff:ff:ff:ff"
ATTR{tx_queue_len}=="1000"
ATTR{ifalias}==""
ATTR{ifindex}=="9"
ATTR{link_mode}=="0"
ATTR{carrier}=="1"
looking at parent device '/devices/pci0000:00/0000:00:0a.0/0000:0a:00.0/net':
KERNELS=="net"
SUBSYSTEMS==""
DRIVERS==""
looking at parent device '/devices/pci0000:00/0000:00:0a.0/0000:0a:00.0':
KERNELS=="0000:0a:00.0"
SUBSYSTEMS=="pci"
DRIVERS=="igb"
ATTRS{irq}=="33"
ATTRS{subsystem_vendor}=="0x0000"
ATTRS{broken_parity_status}=="0"
ATTRS{class}=="0x020000"
ATTRS{consistent_dma_mask_bits}=="64"
ATTRS{modalias}=="pci:v00008086d000010C9sv00000000sd00003550bc02sc00i00"
ATTRS{dma_mask_bits}=="64"
ATTRS{local_cpus}=="00000000,00000000,00000000,0000ffff"
ATTRS{device}=="0x10c9"
ATTRS{enable}=="1"
ATTRS{msi_bus}==""
ATTRS{local_cpulist}=="0-15"
ATTRS{vendor}=="0x8086"
ATTRS{subsystem_device}=="0x3550"
ATTRS{numa_node}=="-1"
looking at parent device '/devices/pci0000:00/0000:00:0a.0':
KERNELS=="0000:00:0a.0"
SUBSYSTEMS=="pci"
DRIVERS=="pcieport"
ATTRS{irq}=="69"
ATTRS{subsystem_vendor}=="0x8086"
ATTRS{broken_parity_status}=="0"
ATTRS{class}=="0x060400"
ATTRS{consistent_dma_mask_bits}=="32"
ATTRS{modalias}=="pci:v00008086d00003411sv00008086sd000034DEbc06sc04i00"
ATTRS{dma_mask_bits}=="32"
ATTRS{local_cpus}=="00000000,00000000,00000000,0000ffff"
ATTRS{device}=="0x3411"
ATTRS{enable}=="2"
ATTRS{msi_bus}=="1"
ATTRS{local_cpulist}=="0-15"
ATTRS{vendor}=="0x8086"
ATTRS{subsystem_device}=="0x34de"
ATTRS{numa_node}=="-1"
looking at parent device '/devices/pci0000:00':
KERNELS=="pci0000:00"
SUBSYSTEMS==""
DRIVERS==""
ATTRS{uevent}==""
[-- Attachment #10: eth7.log --]
[-- Type: text/x-log, Size: 2572 bytes --]
Udevinfo starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '/devices/pci0000:00/0000:00:0a.0/0000:0a:00.1/net/eth7':
KERNEL=="eth7"
SUBSYSTEM=="net"
DRIVER==""
ATTR{mtu}=="1500"
ATTR{type}=="1"
ATTR{netdev_group}=="0"
ATTR{flags}=="0x1003"
ATTR{speed}=="1000"
ATTR{dormant}=="0"
ATTR{addr_assign_type}=="0"
ATTR{dev_id}=="0x0"
ATTR{duplex}=="full"
ATTR{iflink}=="10"
ATTR{addr_len}=="6"
ATTR{address}=="00:15:17:ba:4f:33"
ATTR{operstate}=="up"
ATTR{broadcast}=="ff:ff:ff:ff:ff:ff"
ATTR{tx_queue_len}=="1000"
ATTR{ifalias}==""
ATTR{ifindex}=="10"
ATTR{link_mode}=="0"
ATTR{carrier}=="1"
looking at parent device '/devices/pci0000:00/0000:00:0a.0/0000:0a:00.1/net':
KERNELS=="net"
SUBSYSTEMS==""
DRIVERS==""
looking at parent device '/devices/pci0000:00/0000:00:0a.0/0000:0a:00.1':
KERNELS=="0000:0a:00.1"
SUBSYSTEMS=="pci"
DRIVERS=="igb"
ATTRS{irq}=="31"
ATTRS{subsystem_vendor}=="0x0000"
ATTRS{broken_parity_status}=="0"
ATTRS{class}=="0x020000"
ATTRS{consistent_dma_mask_bits}=="64"
ATTRS{modalias}=="pci:v00008086d000010C9sv00000000sd00003550bc02sc00i00"
ATTRS{dma_mask_bits}=="64"
ATTRS{local_cpus}=="00000000,00000000,00000000,0000ffff"
ATTRS{device}=="0x10c9"
ATTRS{enable}=="1"
ATTRS{msi_bus}==""
ATTRS{local_cpulist}=="0-15"
ATTRS{vendor}=="0x8086"
ATTRS{subsystem_device}=="0x3550"
ATTRS{numa_node}=="-1"
looking at parent device '/devices/pci0000:00/0000:00:0a.0':
KERNELS=="0000:00:0a.0"
SUBSYSTEMS=="pci"
DRIVERS=="pcieport"
ATTRS{irq}=="69"
ATTRS{subsystem_vendor}=="0x8086"
ATTRS{broken_parity_status}=="0"
ATTRS{class}=="0x060400"
ATTRS{consistent_dma_mask_bits}=="32"
ATTRS{modalias}=="pci:v00008086d00003411sv00008086sd000034DEbc06sc04i00"
ATTRS{dma_mask_bits}=="32"
ATTRS{local_cpus}=="00000000,00000000,00000000,0000ffff"
ATTRS{device}=="0x3411"
ATTRS{enable}=="2"
ATTRS{msi_bus}=="1"
ATTRS{local_cpulist}=="0-15"
ATTRS{vendor}=="0x8086"
ATTRS{subsystem_device}=="0x34de"
ATTRS{numa_node}=="-1"
looking at parent device '/devices/pci0000:00':
KERNELS=="pci0000:00"
SUBSYSTEMS==""
DRIVERS==""
ATTRS{uevent}==""
^ permalink raw reply
* Re: Reordered network interface names
From: Arkadiusz Bubała @ 2014-02-03 12:44 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <52EF65B5.8040002@open-e.com>
Hello,
thank you for your response.
On 03.02.2014 13:02, Tom Gundersen wrote:
> > Rarely after reboot interfaces are reordered and one of them is named
>
> > eth1_rename (about 20 reboots is needed to reproduce this issue). I
> > tried to update udev but this didn't resolve this issue. I also tried
> > running udev with debug-trace but it caused that only eth0 didn't have
> > "_rename" suffix.
>
> This is a known problem, when trying to rename interfaces in the
> kernel namespace (ethX). It is fixed in recent versions of udev (what
> versions did you try?) by udev automatically renaming all the
> interfaces in a deterministic way (google for predictable interface
> names).
>
I understand. I tried the latest udev which compile on this system
(udev-137 downloaded from pkgs.fedoraproject.org). But now I know that
it's fixed in version 197. I'll try to resolve this issue manually.
Thank you for your help.
>
> I suggest you either use the most recent udev, or call your interfaces
> something else, lanX, say.
>
> HTH,
>
> Tom
>
Best regards,
Arkadiusz
^ permalink raw reply
* Re: [Patch v1] ACPI, x86: fix bug in associating hot-added CPUs with corresponding NUMA node
From: Rafael J. Wysocki @ 2014-02-05 0:14 UTC (permalink / raw)
To: Jiang Liu
Cc: Rafael J . Wysocki, Toshi Kani, Yinghai Lu, Yijing Wang,
Len Brown, Pavel Machek, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, x86, linux-acpi, linux-hotplug, linux-kernel,
linux-pm
In-Reply-To: <1390185115-26850-1-git-send-email-jiang.liu@linux.intel.com>
On Monday, January 20, 2014 10:31:54 AM Jiang Liu wrote:
> Current ACPI cpu hotplug driver fails to associate hot-added CPUs with
> corresponding NUMA node when doing socket online. The code path to
> associate CPU with NUMA node is as below:
> acpi_processor_add()
> ->acpi_processor_get_info()
> ->acpi_processor_hotadd_init()
> ->acpi_map_lsapic()
> ->_acpi_map_lsapic()
> ->acpi_map_cpu2node()
> cpu_subsys_online()
> ->try_online_node()
> ->node_set_online()
>
> When doing socket online, a new NUMA node is introduced in addition to
> hot-added CPU and memory device. And the new NUMA node is marked as
> online when onlining hot-added CPUs through sysfs interface
> /sys/devices/system/cpu/cpuxx/online.
>
> On the other hand, acpi_map_cpu2node() will only build the CPU to node
> map if corresponding NUMA node is already online, so it always fails
> to associate hot-added CPUs with corresponding NUMA node because the
> NUMA node is still in offline state.
>
> For the fix, we could safely remove the "node_online(node)" check in
> function acpi_map_cpu2node() because it's only called for hot-added CPUs
> by acpi_processor_hotadd_init().
>
> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
I wonder what the status here is? Did this patch go anywhere?
> ---
> arch/x86/kernel/acpi/boot.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
> index 6c0b43b..7625de9 100644
> --- a/arch/x86/kernel/acpi/boot.c
> +++ b/arch/x86/kernel/acpi/boot.c
> @@ -614,10 +614,10 @@ static void acpi_map_cpu2node(acpi_handle handle, int cpu, int physid)
> int nid;
>
> nid = acpi_get_node(handle);
> - if (nid = -1 || !node_online(nid))
> - return;
> - set_apicid_to_node(physid, nid);
> - numa_set_node(cpu, nid);
> + if (nid != -1) {
> + set_apicid_to_node(physid, nid);
> + numa_set_node(cpu, nid);
> + }
> #endif
> }
>
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* question on udev device naming before root is mounted
From: David Avery @ 2014-02-07 2:44 UTC (permalink / raw)
To: linux-hotplug
Can the device names for hard drives be forced before root is mounted
in so much so that udev rules can force via a device serial number to
be a specific /dev/sdX device name.
Looking at my pci and bios boot order I shouldn't even need to do this
but I think the defaults of udev or the sysfs?? are to move USB
devices to latter drive letters.
I am booting from a USB 16GB flash drive and would prefer the device
be sda but even if I could force it to be sdz, and force my sata
drives to be specific drive letters based on their serial numbers so
that I can create a hotswap raid array and be confident that once my
drives are installed they won't move around to different device names.
I think this information would be useful to a lot of people who have
simply given up in the past, and after weeks I was at the point of
giving up but Greg's email bot has given me one more ounce of juice to
keep trying. I really would prefer to not bother him directly but I
have a sneaking suspicion what I'm trying to accomplish isn't
possible.
I have this thread: http://ubuntuforums.org/showthread.php?t"02219
on Ubuntuforums.org where I'm trying to find out if this is possible:
I really appreciate any help, and please forgive my demeanor in my
thread on the ubuntuforums page I have a personality that takes an
acquired taste.
If there is any information needed that I haven't provided in the post
at the link above please let me know and I would be happy to provide
it.
^ permalink raw reply
* Re: question on udev device naming before root is mounted
From: Greg KH @ 2014-02-07 3:28 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CAL6czj9NV-rpbPnbX+p7YOrjXWDmaJKDO9tdpOavc7rKDRXPeA@mail.gmail.com>
On Thu, Feb 06, 2014 at 06:44:11PM -0800, David Avery wrote:
> Can the device names for hard drives be forced before root is mounted
> in so much so that udev rules can force via a device serial number to
> be a specific /dev/sdX device name.
No you can't, sorry. Please use the persistant names instead, the ones
in /dev/disk/ for this.
> Looking at my pci and bios boot order I shouldn't even need to do this
> but I think the defaults of udev or the sysfs?? are to move USB
> devices to latter drive letters.
You don't know what device is going to be discovered first, and they can
be reordered on different boots all the time. Use the /dev/disk/ links
instead.
> I am booting from a USB 16GB flash drive and would prefer the device
> be sda but even if I could force it to be sdz, and force my sata
> drives to be specific drive letters based on their serial numbers so
> that I can create a hotswap raid array and be confident that once my
> drives are installed they won't move around to different device names.
Then use the /dev/disk/ links, that way they can always be confident,
that is what they are there for.
Just ignore the kernel names, they mean nothing, use the /dev/disk/ ones
instead, as they will always be correct.
Hope this helps,
greg k-h
^ permalink raw reply
* Re: [Patch v1] ACPI, x86: fix bug in associating hot-added CPUs with corresponding NUMA node
From: Jiang Liu @ 2014-02-07 9:17 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Rafael J . Wysocki, Toshi Kani, Yinghai Lu, Yijing Wang,
Len Brown, Pavel Machek, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, x86, linux-acpi, linux-hotplug, linux-kernel,
linux-pm
In-Reply-To: <4676819.HL23G4Egmr@vostro.rjw.lan>
On 2014/2/5 8:14, Rafael J. Wysocki wrote:
> On Monday, January 20, 2014 10:31:54 AM Jiang Liu wrote:
>> Current ACPI cpu hotplug driver fails to associate hot-added CPUs with
>> corresponding NUMA node when doing socket online. The code path to
>> associate CPU with NUMA node is as below:
>> acpi_processor_add()
>> ->acpi_processor_get_info()
>> ->acpi_processor_hotadd_init()
>> ->acpi_map_lsapic()
>> ->_acpi_map_lsapic()
>> ->acpi_map_cpu2node()
>> cpu_subsys_online()
>> ->try_online_node()
>> ->node_set_online()
>>
>> When doing socket online, a new NUMA node is introduced in addition to
>> hot-added CPU and memory device. And the new NUMA node is marked as
>> online when onlining hot-added CPUs through sysfs interface
>> /sys/devices/system/cpu/cpuxx/online.
>>
>> On the other hand, acpi_map_cpu2node() will only build the CPU to node
>> map if corresponding NUMA node is already online, so it always fails
>> to associate hot-added CPUs with corresponding NUMA node because the
>> NUMA node is still in offline state.
>>
>> For the fix, we could safely remove the "node_online(node)" check in
>> function acpi_map_cpu2node() because it's only called for hot-added CPUs
>> by acpi_processor_hotadd_init().
>>
>> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
>
> I wonder what the status here is? Did this patch go anywhere?
Hi Rafael,
It's still in review stage, hasn't been accepted by any
maintainer yet.
Thanks!
Gerry
>
>> ---
>> arch/x86/kernel/acpi/boot.c | 8 ++++----
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
>> index 6c0b43b..7625de9 100644
>> --- a/arch/x86/kernel/acpi/boot.c
>> +++ b/arch/x86/kernel/acpi/boot.c
>> @@ -614,10 +614,10 @@ static void acpi_map_cpu2node(acpi_handle handle, int cpu, int physid)
>> int nid;
>>
>> nid = acpi_get_node(handle);
>> - if (nid = -1 || !node_online(nid))
>> - return;
>> - set_apicid_to_node(physid, nid);
>> - numa_set_node(cpu, nid);
>> + if (nid != -1) {
>> + set_apicid_to_node(physid, nid);
>> + numa_set_node(cpu, nid);
>> + }
>> #endif
>> }
>>
>>
>
^ permalink raw reply
* Re: [Patch v1] ACPI, x86: fix bug in associating hot-added CPUs with corresponding NUMA node
From: Rafael J. Wysocki @ 2014-02-07 12:03 UTC (permalink / raw)
To: Jiang Liu, H. Peter Anvin
Cc: Rafael J . Wysocki, Toshi Kani, Yinghai Lu, Yijing Wang,
Len Brown, Pavel Machek, Thomas Gleixner, Ingo Molnar, x86,
linux-acpi, linux-hotplug, linux-kernel, linux-pm
In-Reply-To: <52F4A4B9.2060006@linux.intel.com>
On Friday, February 07, 2014 05:17:45 PM Jiang Liu wrote:
>
> On 2014/2/5 8:14, Rafael J. Wysocki wrote:
> > On Monday, January 20, 2014 10:31:54 AM Jiang Liu wrote:
> >> Current ACPI cpu hotplug driver fails to associate hot-added CPUs with
> >> corresponding NUMA node when doing socket online. The code path to
> >> associate CPU with NUMA node is as below:
> >> acpi_processor_add()
> >> ->acpi_processor_get_info()
> >> ->acpi_processor_hotadd_init()
> >> ->acpi_map_lsapic()
> >> ->_acpi_map_lsapic()
> >> ->acpi_map_cpu2node()
> >> cpu_subsys_online()
> >> ->try_online_node()
> >> ->node_set_online()
> >>
> >> When doing socket online, a new NUMA node is introduced in addition to
> >> hot-added CPU and memory device. And the new NUMA node is marked as
> >> online when onlining hot-added CPUs through sysfs interface
> >> /sys/devices/system/cpu/cpuxx/online.
> >>
> >> On the other hand, acpi_map_cpu2node() will only build the CPU to node
> >> map if corresponding NUMA node is already online, so it always fails
> >> to associate hot-added CPUs with corresponding NUMA node because the
> >> NUMA node is still in offline state.
> >>
> >> For the fix, we could safely remove the "node_online(node)" check in
> >> function acpi_map_cpu2node() because it's only called for hot-added CPUs
> >> by acpi_processor_hotadd_init().
> >>
> >> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
> >
> > I wonder what the status here is? Did this patch go anywhere?
> Hi Rafael,
> It's still in review stage, hasn't been accepted by any
> maintainer yet.
OK
Peter, are you fine with the patch below?
Rafael
> >
> >> ---
> >> arch/x86/kernel/acpi/boot.c | 8 ++++----
> >> 1 file changed, 4 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
> >> index 6c0b43b..7625de9 100644
> >> --- a/arch/x86/kernel/acpi/boot.c
> >> +++ b/arch/x86/kernel/acpi/boot.c
> >> @@ -614,10 +614,10 @@ static void acpi_map_cpu2node(acpi_handle handle, int cpu, int physid)
> >> int nid;
> >>
> >> nid = acpi_get_node(handle);
> >> - if (nid = -1 || !node_online(nid))
> >> - return;
> >> - set_apicid_to_node(physid, nid);
> >> - numa_set_node(cpu, nid);
> >> + if (nid != -1) {
> >> + set_apicid_to_node(physid, nid);
> >> + numa_set_node(cpu, nid);
> >> + }
> >> #endif
> >> }
> >>
> >>
> >
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Re: [PATCH] pciehp: Acknowledge the spurious "cmd completed" event.
From: Bjorn Helgaas @ 2014-02-12 0:34 UTC (permalink / raw)
To: Rajat Jain
Cc: Rajat Jain, linux-pci@vger.kernel.org, linux hotplug mailing,
Kenji Kaneshige, Yijing Wang, Greg KH, Tom Nguyen,
Kristen Accardi, Rajat Jain, Guenter Roeck
In-Reply-To: <18997e8c20fb4bdd8a72e4c01b3fd308@BLUPR05MB118.namprd05.prod.outlook.com>
On Mon, Nov 25, 2013 at 07:03:11PM +0000, Rajat Jain wrote:
> Hello,
>
> > > On a different note, I feel there is still a need to apply my original
> > patch. There is still an open problem in case of spurious interrupts (or
> > in any case where the condition "if (slot_status & PCI_EXP_SLTSTA_CC)"
> > becomes true in pcie_write_cmd()). That is because once that happens, we
> > never clear that interrupt, and no further hotplug interrupts shall be
> > received unless we do that.
> >
> > I agree this is an issue and we should address it somehow. My
> > hesitation is just that I'd prefer to do some more aggressive
> > restructuring rather than apply a point fix. For example:
>
> OK, I'll attempt to fix it that way when I get time.
>
> >
> > - We currently look at PCI_EXP_SLTSTA_CC in pcie_isr(), pcie_poll_cmd(),
> > and pcie_write_cmd(). I think it would be better to look at it only in
> > pcie_isr().
> >
> > - I don't think pcie_poll_cmd() should exist at all; we should poll by
> > calling pcie_isr() instead.
> >
> > - We need pcie_write_cmd(), but I think the way it waits is backwards.
> > Currently we issue the command, then wait for it to complete. I think
> > we should issue the command, note the current time, and return without
> > waiting. The *next* time we need to issue a command, we can wait for
> > completion of the previous one (or timeout) if necessary.
> >
> > But maybe we need the point fix in the interim, especially if anybody
> > can actually produce the scenario you mention.
>
> Ok.
This patch is still in patchwork, but I've lost track of where we are.
Did you resolve this in the series that I just applied, or is it still
an outstanding issue?
Bjorn
^ permalink raw reply
* RE: [PATCH] pciehp: Acknowledge the spurious "cmd completed" event.
From: Rajat Jain @ 2014-02-12 1:08 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Rajat Jain, linux-pci@vger.kernel.org, linux hotplug mailing,
Kenji Kaneshige, Yijing Wang, Greg KH, Tom Nguyen,
Kristen Accardi, Rajat Jain, Guenter Roeck
In-Reply-To: <20140212003458.GE21057@google.com>
SGVsbG8gQmpvcm4sDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbGlu
dXgtaG90cGx1Zy1vd25lckB2Z2VyLmtlcm5lbC5vcmcgW21haWx0bzpsaW51eC1ob3RwbHVnLQ0K
PiBvd25lckB2Z2VyLmtlcm5lbC5vcmddIE9uIEJlaGFsZiBPZiBCam9ybiBIZWxnYWFzDQo+IFNl
bnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDExLCAyMDE0IDQ6MzUgUE0NCj4gVG86IFJhamF0IEphaW4N
Cj4gQ2M6IFJhamF0IEphaW47IGxpbnV4LXBjaUB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4IGhvdHBs
dWcgbWFpbGluZzsgS2VuamkNCj4gS2FuZXNoaWdlOyBZaWppbmcgV2FuZzsgR3JlZyBLSDsgVG9t
IE5ndXllbjsgS3Jpc3RlbiBBY2NhcmRpOyBSYWphdA0KPiBKYWluOyBHdWVudGVyIFJvZWNrDQo+
IFN1YmplY3Q6IFJlOiBbUEFUQ0hdIHBjaWVocDogQWNrbm93bGVkZ2UgdGhlIHNwdXJpb3VzICJj
bWQgY29tcGxldGVkIg0KPiBldmVudC4NCj4gDQo+IE9uIE1vbiwgTm92IDI1LCAyMDEzIGF0IDA3
OjAzOjExUE0gKzAwMDAsIFJhamF0IEphaW4gd3JvdGU6DQo+ID4gSGVsbG8sDQo+ID4NCj4gPiA+
ID4gT24gYSBkaWZmZXJlbnQgbm90ZSwgSSBmZWVsIHRoZXJlIGlzIHN0aWxsIGEgbmVlZCB0byBh
cHBseSBteQ0KPiA+ID4gPiBvcmlnaW5hbA0KPiA+ID4gcGF0Y2guIFRoZXJlIGlzIHN0aWxsIGFu
IG9wZW4gcHJvYmxlbSBpbiBjYXNlIG9mIHNwdXJpb3VzIGludGVycnVwdHMNCj4gPiA+IChvciBp
biBhbnkgY2FzZSB3aGVyZSB0aGUgY29uZGl0aW9uICJpZiAoc2xvdF9zdGF0dXMgJg0KPiBQQ0lf
RVhQX1NMVFNUQV9DQykiDQo+ID4gPiBiZWNvbWVzIHRydWUgaW4gcGNpZV93cml0ZV9jbWQoKSku
IFRoYXQgaXMgYmVjYXVzZSBvbmNlIHRoYXQNCj4gPiA+IGhhcHBlbnMsIHdlIG5ldmVyIGNsZWFy
IHRoYXQgaW50ZXJydXB0LCBhbmQgbm8gZnVydGhlciBob3RwbHVnDQo+ID4gPiBpbnRlcnJ1cHRz
IHNoYWxsIGJlIHJlY2VpdmVkIHVubGVzcyB3ZSBkbyB0aGF0Lg0KPiA+ID4NCj4gPiA+IEkgYWdy
ZWUgdGhpcyBpcyBhbiBpc3N1ZSBhbmQgd2Ugc2hvdWxkIGFkZHJlc3MgaXQgc29tZWhvdy4gIE15
DQo+ID4gPiBoZXNpdGF0aW9uIGlzIGp1c3QgdGhhdCBJJ2QgcHJlZmVyIHRvIGRvIHNvbWUgbW9y
ZSBhZ2dyZXNzaXZlDQo+ID4gPiByZXN0cnVjdHVyaW5nIHJhdGhlciB0aGFuIGFwcGx5IGEgcG9p
bnQgZml4LiAgRm9yIGV4YW1wbGU6DQo+ID4NCj4gPiBPSywgSSdsbCBhdHRlbXB0IHRvIGZpeCBp
dCB0aGF0IHdheSB3aGVuIEkgZ2V0IHRpbWUuDQo+ID4NCj4gPiA+DQo+ID4gPiAtIFdlIGN1cnJl
bnRseSBsb29rIGF0IFBDSV9FWFBfU0xUU1RBX0NDIGluIHBjaWVfaXNyKCksDQo+ID4gPiBwY2ll
X3BvbGxfY21kKCksIGFuZCBwY2llX3dyaXRlX2NtZCgpLiAgSSB0aGluayBpdCB3b3VsZCBiZSBi
ZXR0ZXINCj4gPiA+IHRvIGxvb2sgYXQgaXQgb25seSBpbiBwY2llX2lzcigpLg0KPiA+ID4NCj4g
PiA+IC0gSSBkb24ndCB0aGluayBwY2llX3BvbGxfY21kKCkgc2hvdWxkIGV4aXN0IGF0IGFsbDsg
d2Ugc2hvdWxkIHBvbGwNCj4gPiA+IGJ5IGNhbGxpbmcgcGNpZV9pc3IoKSBpbnN0ZWFkLg0KPiA+
ID4NCj4gPiA+IC0gV2UgbmVlZCBwY2llX3dyaXRlX2NtZCgpLCBidXQgSSB0aGluayB0aGUgd2F5
IGl0IHdhaXRzIGlzDQo+IGJhY2t3YXJkcy4NCj4gPiA+ICBDdXJyZW50bHkgd2UgaXNzdWUgdGhl
IGNvbW1hbmQsIHRoZW4gd2FpdCBmb3IgaXQgdG8gY29tcGxldGUuICBJDQo+ID4gPiB0aGluayB3
ZSBzaG91bGQgaXNzdWUgdGhlIGNvbW1hbmQsIG5vdGUgdGhlIGN1cnJlbnQgdGltZSwgYW5kIHJl
dHVybg0KPiA+ID4gd2l0aG91dCB3YWl0aW5nLiAgVGhlICpuZXh0KiB0aW1lIHdlIG5lZWQgdG8g
aXNzdWUgYSBjb21tYW5kLCB3ZSBjYW4NCj4gPiA+IHdhaXQgZm9yIGNvbXBsZXRpb24gb2YgdGhl
IHByZXZpb3VzIG9uZSAob3IgdGltZW91dCkgaWYgbmVjZXNzYXJ5Lg0KPiA+ID4NCj4gPiA+IEJ1
dCBtYXliZSB3ZSBuZWVkIHRoZSBwb2ludCBmaXggaW4gdGhlIGludGVyaW0sIGVzcGVjaWFsbHkg
aWYNCj4gPiA+IGFueWJvZHkgY2FuIGFjdHVhbGx5IHByb2R1Y2UgdGhlIHNjZW5hcmlvIHlvdSBt
ZW50aW9uLg0KPiA+DQo+ID4gT2suDQo+IA0KPiBUaGlzIHBhdGNoIGlzIHN0aWxsIGluIHBhdGNo
d29yaywgYnV0IEkndmUgbG9zdCB0cmFjayBvZiB3aGVyZSB3ZSBhcmUuDQo+IERpZCB5b3UgcmVz
b2x2ZSB0aGlzIGluIHRoZSBzZXJpZXMgdGhhdCBJIGp1c3QgYXBwbGllZCwgb3IgaXMgaXQgc3Rp
bGwNCj4gYW4gb3V0c3RhbmRpbmcgaXNzdWU/DQoNCk5vLCBJIGRpZCBub3Qgc29sdmUgaXQuIEl0
IGlzIHN0aWxsIGFuIG91dHN0YW5kaW5nIGlzc3VlLiBTbyBmYXIgSSBhbSB1c2luZyB5b3VyIHBh
dGNoIHRvIG92ZXJjb21lIHRoaXM6DQoNCmh0dHA6Ly93d3cuc3Bpbmljcy5uZXQvbGlzdHMvaG90
cGx1Zy9tc2cwNTgzMC5odG1sDQoNCkknbGwganVzdCBhdHRlbXB0IHRvIGNvbmNsdWRlIHRoZSBz
dGF0dXMgb24gdGhpcyBpc3N1ZSBzbyB0aGF0IHlvdSBjYW4gbWFrZSB0aGUgZGVjaXNpb24gb24g
dGhlIGNvdXJzZSBvZiBhY3Rpb24uIElNSE8gdGhlcmUgYXJlIDIgaW5kZXBlbmRlbnQgaXNzdWVz
IHRoYXQgd2UgZGlzY3Vzc2VkIGluIHRoaXMgdGhyZWFkOg0KCQ0KMSkgUENJZSBjb21wbGlhbnQg
SFcgKHRoYXQgZ2VuZXJhdGVzIGNtZCBjb21wbGV0ZWQgaW50ZXJydXB0cyBhdCBldmVyeSB3cml0
ZSBvZiBTbG90X2N0cmwgcmVnaXN0ZXIpIGJlaW5nIHBlbmFsaXplZCB3aXRoIDEgc2Vjb25kIGRl
bGF5IGR1cmluZyB0aGUgYm9vdCB1cC4gWW91ciBwYXRjaCBzb2x2ZXMgdGhpcy4NCg0KMikgSWYg
dGhlcmUgaXMgYSBnZW51aW5lIHNwdXJpb3VzIGludGVycnVwdCwgaXQgZG9lcyBub3QgZ2V0IGFj
a25vd2xlZGdlZC4gSSBoYWQgb3JpZ2luYWxseSBwb3N0ZWQgYSBwYXRjaCBmb3IgVEhJUyBwcm9i
bGVtLg0KaHR0cDovL3d3dy5zcGluaWNzLm5ldC9saXN0cy9ob3RwbHVnL21zZzA1ODE1Lmh0bWwN
Cg0KWW91IGhhZCBpbmRpY2F0ZWQgdGhhdCB5b3Ugd291bGQgcmF0aGVyIHdhbnQgYSBiaWdnZXIg
cmVzdHJ1Y3R1cmluZyBvZiB0aGUgZHJpdmVyIHRvIHNvbHZlICgyKS4NCg0KTXkgb2JzZXJ2YXRp
b246IE1ZIHByb2JsZW0gKGluIG15IHNldHVwKSBpcyBub3Qgc2VlbiBpZiBJIHVzZSBlaXRoZXIg
b2YgdGhlIHBhdGNoZXMgKHlvdXJzIG9yIG1pbmUpLg0KDQpNeSBvcGluaW9uOiBJIHRoaW5rIG15
IHBhdGNoIHNvbHZlcyAoMikgYnV0IG1pZ2h0IG5vdCBzb2x2ZSAoMSkgZm9yIGFsbCBjb3JuZXIg
Y2FzZXMuIEFsc28geW91ciBwYXRjaCBzb2x2ZXMgKDEpIGJ1dCBtYXkgbm90IHNvbHZlICgyKSBm
b3IgYWxsIGNvcm5lciBjYXNlcyAtVGh1cyB3ZSBzaG91bGQgcHJvYmFibHkgc29sdmUgYm90aCBv
ZiB0aGVzZSBwcm9ibGVtcyBpbmRpdmlkdWFsbHkuDQoNClRoYW5rcywNCg0KUmFqYXQNCg0KDQoN
CiANCg0KDQo+IA0KPiBCam9ybg0KPiAtLQ0KPiBUbyB1bnN1YnNjcmliZSBmcm9tIHRoaXMgbGlz
dDogc2VuZCB0aGUgbGluZSAidW5zdWJzY3JpYmUgbGludXgtaG90cGx1ZyINCj4gaW4gdGhlIGJv
ZHkgb2YgYSBtZXNzYWdlIHRvIG1ham9yZG9tb0B2Z2VyLmtlcm5lbC5vcmcgTW9yZSBtYWpvcmRv
bW8NCj4gaW5mbyBhdCAgaHR0cDovL3ZnZXIua2VybmVsLm9yZy9tYWpvcmRvbW8taW5mby5odG1s
DQo+IA0KDQo
^ permalink raw reply
* Re: [Patch v1] ACPI, x86: fix bug in associating hot-added CPUs with corresponding NUMA node
From: Jiang Liu @ 2014-02-13 2:32 UTC (permalink / raw)
To: Rafael J. Wysocki, H. Peter Anvin
Cc: Rafael J . Wysocki, Toshi Kani, Yinghai Lu, Yijing Wang,
Len Brown, Pavel Machek, Thomas Gleixner, Ingo Molnar, x86,
linux-acpi, linux-hotplug, linux-kernel, linux-pm
In-Reply-To: <1440384.cOMzyfyUzg@vostro.rjw.lan>
Ping...
On 2014/2/7 20:03, Rafael J. Wysocki wrote:
> On Friday, February 07, 2014 05:17:45 PM Jiang Liu wrote:
>>
>> On 2014/2/5 8:14, Rafael J. Wysocki wrote:
>>> On Monday, January 20, 2014 10:31:54 AM Jiang Liu wrote:
>>>> Current ACPI cpu hotplug driver fails to associate hot-added CPUs with
>>>> corresponding NUMA node when doing socket online. The code path to
>>>> associate CPU with NUMA node is as below:
>>>> acpi_processor_add()
>>>> ->acpi_processor_get_info()
>>>> ->acpi_processor_hotadd_init()
>>>> ->acpi_map_lsapic()
>>>> ->_acpi_map_lsapic()
>>>> ->acpi_map_cpu2node()
>>>> cpu_subsys_online()
>>>> ->try_online_node()
>>>> ->node_set_online()
>>>>
>>>> When doing socket online, a new NUMA node is introduced in addition to
>>>> hot-added CPU and memory device. And the new NUMA node is marked as
>>>> online when onlining hot-added CPUs through sysfs interface
>>>> /sys/devices/system/cpu/cpuxx/online.
>>>>
>>>> On the other hand, acpi_map_cpu2node() will only build the CPU to node
>>>> map if corresponding NUMA node is already online, so it always fails
>>>> to associate hot-added CPUs with corresponding NUMA node because the
>>>> NUMA node is still in offline state.
>>>>
>>>> For the fix, we could safely remove the "node_online(node)" check in
>>>> function acpi_map_cpu2node() because it's only called for hot-added CPUs
>>>> by acpi_processor_hotadd_init().
>>>>
>>>> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
>>>
>>> I wonder what the status here is? Did this patch go anywhere?
>> Hi Rafael,
>> It's still in review stage, hasn't been accepted by any
>> maintainer yet.
>
> OK
>
> Peter, are you fine with the patch below?
>
> Rafael
>
>
>>>
>>>> ---
>>>> arch/x86/kernel/acpi/boot.c | 8 ++++----
>>>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
>>>> index 6c0b43b..7625de9 100644
>>>> --- a/arch/x86/kernel/acpi/boot.c
>>>> +++ b/arch/x86/kernel/acpi/boot.c
>>>> @@ -614,10 +614,10 @@ static void acpi_map_cpu2node(acpi_handle handle, int cpu, int physid)
>>>> int nid;
>>>>
>>>> nid = acpi_get_node(handle);
>>>> - if (nid = -1 || !node_online(nid))
>>>> - return;
>>>> - set_apicid_to_node(physid, nid);
>>>> - numa_set_node(cpu, nid);
>>>> + if (nid != -1) {
>>>> + set_apicid_to_node(physid, nid);
>>>> + numa_set_node(cpu, nid);
>>>> + }
>>>> #endif
>>>> }
>>>>
>>>>
>>>
>
^ permalink raw reply
* Re: [Patch v1] ACPI, x86: fix bug in associating hot-added CPUs with corresponding NUMA node
From: H. Peter Anvin @ 2014-02-13 3:37 UTC (permalink / raw)
To: Jiang Liu, Rafael J. Wysocki
Cc: Rafael J . Wysocki, Toshi Kani, Yinghai Lu, Yijing Wang,
Len Brown, Pavel Machek, Thomas Gleixner, Ingo Molnar, x86,
linux-acpi, linux-hotplug, linux-kernel, linux-pm
In-Reply-To: <52FC2EB5.3010805@linux.intel.com>
On 02/12/2014 06:32 PM, Jiang Liu wrote:
> Ping...
Sorry, will look at it tomorrow.
-hpa
^ permalink raw reply
* /dev entry of USB device not disappearing after detach
From: Valentina Manea @ 2014-02-14 17:35 UTC (permalink / raw)
To: linux-hotplug
Hello,
I am working on a driver for a virtual USB host controller. When I attach a USB
device, everything is fine - sysfs files are created, /dev entry is
created, device is usable.
However, when I detach it, the /dev entry still remains. The sysfs
files are removed, as expected. Obviously, the /dev entry is no longer
usable, e.g. it can't be used for mounting.
The output from udevmon is here [1]. vhci_hcd is the device representing the
USB hub and 2-1 is the bus ID of the attached device.
As far as I can tell, udevd receives the remove event but, for some
reason, the /dev entry still remains.
Any help is greatly appreciated.
Thanks,
Valentina
[1] http://pastebin.com/0M2pSGw1
^ permalink raw reply
* Re: /dev entry of USB device not disappearing after detach
From: Greg KH @ 2014-02-14 18:20 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CABdoFFfdXunfN+q1wJWGJbh9UGzD+9z9257ZXMM_qDhg3X8zTQ@mail.gmail.com>
On Fri, Feb 14, 2014 at 07:35:31PM +0200, Valentina Manea wrote:
> Hello,
>
> I am working on a driver for a virtual USB host controller. When I attach a USB
> device, everything is fine - sysfs files are created, /dev entry is
> created, device is usable.
> However, when I detach it, the /dev entry still remains. The sysfs
> files are removed, as expected. Obviously, the /dev entry is no longer
> usable, e.g. it can't be used for mounting.
What /dev entry are you referring to?
Did something have it held open while the device was still connected and
hasn't closed it yet?
> The output from udevmon is here [1]. vhci_hcd is the device representing the
> USB hub and 2-1 is the bus ID of the attached device.
>
> As far as I can tell, udevd receives the remove event but, for some
> reason, the /dev entry still remains.
How about enabling debugging in the USB core to see what is going on
with the device removal path?
thanks,
greg k-h
^ permalink raw reply
* Re: /dev entry of USB device not disappearing after detach
From: Greg KH @ 2014-02-14 18:21 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CABdoFFfdXunfN+q1wJWGJbh9UGzD+9z9257ZXMM_qDhg3X8zTQ@mail.gmail.com>
Adding linux-usb@vger...
On Fri, Feb 14, 2014 at 10:20:11AM -0800, Greg KH wrote:
> On Fri, Feb 14, 2014 at 07:35:31PM +0200, Valentina Manea wrote:
> > Hello,
> >
> > I am working on a driver for a virtual USB host controller. When I attach a USB
> > device, everything is fine - sysfs files are created, /dev entry is
> > created, device is usable.
> > However, when I detach it, the /dev entry still remains. The sysfs
> > files are removed, as expected. Obviously, the /dev entry is no longer
> > usable, e.g. it can't be used for mounting.
>
> What /dev entry are you referring to?
>
> Did something have it held open while the device was still connected and
> hasn't closed it yet?
Also, the kernel is the one now responsible for managing the /dev node
creation/removal, through devtmpfs, there shouldn't be any "hotplug"
scripts involved in this process, so I doubt it's a userspace issue.
you do have CONFIG_DEVTMPFS enabled in your kernel, right?
thanks,
greg k-h
^ permalink raw reply
* Re: /dev entry of USB device not disappearing after detach
From: Valentina Manea @ 2014-02-15 12:38 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CABdoFFfdXunfN+q1wJWGJbh9UGzD+9z9257ZXMM_qDhg3X8zTQ@mail.gmail.com>
On Fri, Feb 14, 2014 at 8:21 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
>
> Also, the kernel is the one now responsible for managing the /dev node
> creation/removal, through devtmpfs, there shouldn't be any "hotplug"
> scripts involved in this process, so I doubt it's a userspace issue.
>
> you do have CONFIG_DEVTMPFS enabled in your kernel, right?
>
Hi Greg,
It seems I did not have CONFIG_DEVTMPFS and, with this option, the bug
is no longer reproducible. Since, as I've read, devtmpfs has replaced
tmpfs, there's no point in further debugging.
Thanks,
Valentina
^ permalink raw reply
* Re: /dev entry of USB device not disappearing after detach
From: Greg KH @ 2014-02-15 16:52 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CABdoFFfdXunfN+q1wJWGJbh9UGzD+9z9257ZXMM_qDhg3X8zTQ@mail.gmail.com>
On Sat, Feb 15, 2014 at 02:38:28PM +0200, Valentina Manea wrote:
> On Fri, Feb 14, 2014 at 8:21 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > Also, the kernel is the one now responsible for managing the /dev node
> > creation/removal, through devtmpfs, there shouldn't be any "hotplug"
> > scripts involved in this process, so I doubt it's a userspace issue.
> >
> > you do have CONFIG_DEVTMPFS enabled in your kernel, right?
> >
>
> Hi Greg,
>
> It seems I did not have CONFIG_DEVTMPFS and, with this option, the bug
> is no longer reproducible. Since, as I've read, devtmpfs has replaced
> tmpfs, there's no point in further debugging.
Ok, that makes sense, it wasn't a "bug", it was just that nothing was
around to delete the device node at all (udev no longer does this, it
relies on devtmpfs to be present). So all was working just fine.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] pciehp: Acknowledge the spurious "cmd completed" event.
From: Rajat Jain @ 2014-02-20 7:42 UTC (permalink / raw)
To: Rajat Jain
Cc: Bjorn Helgaas, Rajat Jain, linux-pci@vger.kernel.org,
linux hotplug mailing, Kenji Kaneshige, Yijing Wang, Greg KH,
Tom Nguyen, Kristen Accardi, Guenter Roeck
In-Reply-To: <8a021ad12c5548fe8e79e0208725c14f@DM2PR05MB671.namprd05.prod.outlook.com>
Hello Bjorn,
>>
>> On Mon, Nov 25, 2013 at 07:03:11PM +0000, Rajat Jain wrote:
>> > Hello,
>> >
>> > > > On a different note, I feel there is still a need to apply my
>> > > > original
>> > > patch. There is still an open problem in case of spurious interrupts
>> > > (or in any case where the condition "if (slot_status &
>> PCI_EXP_SLTSTA_CC)"
>> > > becomes true in pcie_write_cmd()). That is because once that
>> > > happens, we never clear that interrupt, and no further hotplug
>> > > interrupts shall be received unless we do that.
>> > >
>> > > I agree this is an issue and we should address it somehow. My
>> > > hesitation is just that I'd prefer to do some more aggressive
>> > > restructuring rather than apply a point fix. For example:
>> >
>> > OK, I'll attempt to fix it that way when I get time.
>> >
>> > >
>> > > - We currently look at PCI_EXP_SLTSTA_CC in pcie_isr(),
>> > > pcie_poll_cmd(), and pcie_write_cmd(). I think it would be better
>> > > to look at it only in pcie_isr().
>> > >
>> > > - I don't think pcie_poll_cmd() should exist at all; we should poll
>> > > by calling pcie_isr() instead.
>> > >
>> > > - We need pcie_write_cmd(), but I think the way it waits is
>> backwards.
>> > > Currently we issue the command, then wait for it to complete. I
>> > > think we should issue the command, note the current time, and return
>> > > without waiting. The *next* time we need to issue a command, we can
>> > > wait for completion of the previous one (or timeout) if necessary.
>> > >
>> > > But maybe we need the point fix in the interim, especially if
>> > > anybody can actually produce the scenario you mention.
>> >
>> > Ok.
>>
>> This patch is still in patchwork, but I've lost track of where we are.
>> Did you resolve this in the series that I just applied, or is it still
>> an outstanding issue?
>
> No, I did not solve it. It is still an outstanding issue. So far I am using your patch to overcome this:
>
> http://www.spinics.net/lists/hotplug/msg05830.html
>
> I'll just attempt to conclude the status on this issue so that you can make the decision on the course of action. IMHO there are 2 independent issues that we discussed in this thread:
>
> 1) PCIe compliant HW (that generates cmd completed interrupts at every write of Slot_ctrl register) being penalized with 1 second delay during the boot up. Your patch solves this.
>
> 2) If there is a genuine spurious interrupt, it does not get acknowledged. I had originally posted a patch for THIS problem.
> http://www.spinics.net/lists/hotplug/msg05815.html
>
> You had indicated that you would rather want a bigger restructuring of the driver to solve (2).
>
> My observation: MY problem (in my setup) is not seen if I use either of the patches (yours or mine).
>
> My opinion: I think my patch solves (2) but might not solve (1) for all corner cases. Also your patch solves (1) but may not solve (2) for all corner cases -Thus we should probably solve both of these problems individually.
>
Just wondering if you decided on how to solve this problem?
Are you planning this for 3.15?
Thanks,
Rajat
^ permalink raw reply
* Re: [PATCH] pciehp: Acknowledge the spurious "cmd completed" event.
From: Bjorn Helgaas @ 2014-02-20 22:20 UTC (permalink / raw)
To: Rajat Jain
Cc: Rajat Jain, Rajat Jain, linux-pci@vger.kernel.org,
linux hotplug mailing, Kenji Kaneshige, Yijing Wang, Greg KH,
Tom Nguyen, Kristen Accardi, Guenter Roeck
In-Reply-To: <CAA93t1rjOfVgSWepOEWBx6G0mVrdGTVt=VX9X_S-zeYSyjgsAA@mail.gmail.com>
On Thu, Feb 20, 2014 at 12:42 AM, Rajat Jain <rajatxjain@gmail.com> wrote:
> Hello Bjorn,
>
>>>
>>> On Mon, Nov 25, 2013 at 07:03:11PM +0000, Rajat Jain wrote:
>>> > Hello,
>>> >
>>> > > > On a different note, I feel there is still a need to apply my
>>> > > > original
>>> > > patch. There is still an open problem in case of spurious interrupts
>>> > > (or in any case where the condition "if (slot_status &
>>> PCI_EXP_SLTSTA_CC)"
>>> > > becomes true in pcie_write_cmd()). That is because once that
>>> > > happens, we never clear that interrupt, and no further hotplug
>>> > > interrupts shall be received unless we do that.
>>> > >
>>> > > I agree this is an issue and we should address it somehow. My
>>> > > hesitation is just that I'd prefer to do some more aggressive
>>> > > restructuring rather than apply a point fix. For example:
>>> >
>>> > OK, I'll attempt to fix it that way when I get time.
>>> >
>>> > >
>>> > > - We currently look at PCI_EXP_SLTSTA_CC in pcie_isr(),
>>> > > pcie_poll_cmd(), and pcie_write_cmd(). I think it would be better
>>> > > to look at it only in pcie_isr().
>>> > >
>>> > > - I don't think pcie_poll_cmd() should exist at all; we should poll
>>> > > by calling pcie_isr() instead.
>>> > >
>>> > > - We need pcie_write_cmd(), but I think the way it waits is
>>> backwards.
>>> > > Currently we issue the command, then wait for it to complete. I
>>> > > think we should issue the command, note the current time, and return
>>> > > without waiting. The *next* time we need to issue a command, we can
>>> > > wait for completion of the previous one (or timeout) if necessary.
>>> > >
>>> > > But maybe we need the point fix in the interim, especially if
>>> > > anybody can actually produce the scenario you mention.
>>> >
>>> > Ok.
>>>
>>> This patch is still in patchwork, but I've lost track of where we are.
>>> Did you resolve this in the series that I just applied, or is it still
>>> an outstanding issue?
>>
>> No, I did not solve it. It is still an outstanding issue. So far I am using your patch to overcome this:
>>
>> http://www.spinics.net/lists/hotplug/msg05830.html
>>
>> I'll just attempt to conclude the status on this issue so that you can make the decision on the course of action. IMHO there are 2 independent issues that we discussed in this thread:
>>
>> 1) PCIe compliant HW (that generates cmd completed interrupts at every write of Slot_ctrl register) being penalized with 1 second delay during the boot up. Your patch solves this.
>>
>> 2) If there is a genuine spurious interrupt, it does not get acknowledged. I had originally posted a patch for THIS problem.
>> http://www.spinics.net/lists/hotplug/msg05815.html
>>
>> You had indicated that you would rather want a bigger restructuring of the driver to solve (2).
>>
>> My observation: MY problem (in my setup) is not seen if I use either of the patches (yours or mine).
>>
>> My opinion: I think my patch solves (2) but might not solve (1) for all corner cases. Also your patch solves (1) but may not solve (2) for all corner cases -Thus we should probably solve both of these problems individually.
>>
>
> Just wondering if you decided on how to solve this problem?
>
> Are you planning this for 3.15?
Sorry, I haven't had a chance to work on this, so I don't think *I*
will get anything done for v3.15. To make forward progress, maybe we
should merge your original patch? Would you mind posting it again so
it gets into patchwork again?
Bjorn
^ permalink raw reply
* Re: [PATCH] pciehp: Acknowledge the spurious "cmd completed" event.
From: Rajat Jain @ 2014-02-21 1:43 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Rajat Jain, Rajat Jain, linux-pci@vger.kernel.org,
linux hotplug mailing, Kenji Kaneshige, Yijing Wang, Greg KH,
Tom Nguyen, Kristen Accardi, Guenter Roeck
In-Reply-To: <CAErSpo4n19oYLzzkwQ_QeYq9v48DQPzLsMgCoihdT7OdsXGqtg@mail.gmail.com>
On Thu, Feb 20, 2014 at 2:20 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> On Thu, Feb 20, 2014 at 12:42 AM, Rajat Jain <rajatxjain@gmail.com> wrote:
>> Hello Bjorn,
>>
>>>>
>>>> On Mon, Nov 25, 2013 at 07:03:11PM +0000, Rajat Jain wrote:
>>>> > Hello,
>>>> >
>>>> > > > On a different note, I feel there is still a need to apply my
>>>> > > > original
>>>> > > patch. There is still an open problem in case of spurious interrupts
>>>> > > (or in any case where the condition "if (slot_status &
>>>> PCI_EXP_SLTSTA_CC)"
>>>> > > becomes true in pcie_write_cmd()). That is because once that
>>>> > > happens, we never clear that interrupt, and no further hotplug
>>>> > > interrupts shall be received unless we do that.
>>>> > >
>>>> > > I agree this is an issue and we should address it somehow. My
>>>> > > hesitation is just that I'd prefer to do some more aggressive
>>>> > > restructuring rather than apply a point fix. For example:
>>>> >
>>>> > OK, I'll attempt to fix it that way when I get time.
>>>> >
>>>> > >
>>>> > > - We currently look at PCI_EXP_SLTSTA_CC in pcie_isr(),
>>>> > > pcie_poll_cmd(), and pcie_write_cmd(). I think it would be better
>>>> > > to look at it only in pcie_isr().
>>>> > >
>>>> > > - I don't think pcie_poll_cmd() should exist at all; we should poll
>>>> > > by calling pcie_isr() instead.
>>>> > >
>>>> > > - We need pcie_write_cmd(), but I think the way it waits is
>>>> backwards.
>>>> > > Currently we issue the command, then wait for it to complete. I
>>>> > > think we should issue the command, note the current time, and return
>>>> > > without waiting. The *next* time we need to issue a command, we can
>>>> > > wait for completion of the previous one (or timeout) if necessary.
>>>> > >
>>>> > > But maybe we need the point fix in the interim, especially if
>>>> > > anybody can actually produce the scenario you mention.
>>>> >
>>>> > Ok.
>>>>
>>>> This patch is still in patchwork, but I've lost track of where we are.
>>>> Did you resolve this in the series that I just applied, or is it still
>>>> an outstanding issue?
>>>
>>> No, I did not solve it. It is still an outstanding issue. So far I am using your patch to overcome this:
>>>
>>> http://www.spinics.net/lists/hotplug/msg05830.html
>>>
>>> I'll just attempt to conclude the status on this issue so that you can make the decision on the course of action. IMHO there are 2 independent issues that we discussed in this thread:
>>>
>>> 1) PCIe compliant HW (that generates cmd completed interrupts at every write of Slot_ctrl register) being penalized with 1 second delay during the boot up. Your patch solves this.
>>>
>>> 2) If there is a genuine spurious interrupt, it does not get acknowledged. I had originally posted a patch for THIS problem.
>>> http://www.spinics.net/lists/hotplug/msg05815.html
>>>
>>> You had indicated that you would rather want a bigger restructuring of the driver to solve (2).
>>>
>>> My observation: MY problem (in my setup) is not seen if I use either of the patches (yours or mine).
>>>
>>> My opinion: I think my patch solves (2) but might not solve (1) for all corner cases. Also your patch solves (1) but may not solve (2) for all corner cases -Thus we should probably solve both of these problems individually.
>>>
>>
>> Just wondering if you decided on how to solve this problem?
>>
>> Are you planning this for 3.15?
>
> Sorry, I haven't had a chance to work on this, so I don't think *I*
> will get anything done for v3.15. To make forward progress, maybe we
> should merge your original patch? Would you mind posting it again so
> it gets into patchwork again?
Just sent it again, Thanks!
^ permalink raw reply
* system hang
From: narasimharo bolisetti @ 2014-04-10 7:05 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org, kernelnewbies@nl.linux.org,
devel@linuxdriverproject.org, linux-serial@vger.kernel.org,
linux-hotplug@vger.kernel.org, greg@kroah.com,
Narasimharao Bolisetti
Cc: nrbolisetti@gmail.com, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, linux-pci@vger.kernel.org,
linux-usb@vger.kernel.org
In-Reply-To: <62C418AB752FEF4D931AB8E89E46539F02878DFC@chn-hclt-mbs06.HCLT.CORP.HCL.IN>
Hi Greg/All,
This is Narasimharao working for a s/wcompany HCLT..
I am working a issue and
the description is below:
system stops booting and
needs a series of console inputs (space bar or return) to
continue booting. Each input advances the process a little
bit.
Actually I am trying to
upgrade the s/w from usb pendrive, part of this upgrade
having multiple times we are disconnecting and connecting
the usb pen drive.
system stops booting and
needs a series of console inputs (space bar or return) to
continue booting. Each input advances the process a little
bit.
I have tried to find the
root cause for the issue but not get success, can you help
me regarding to this what is the root cause and how i can
fix this?
One more thing i observed
that the space allocated for tty by 'tty_write_room'
is suddenly consumed by more than 2k at the time of issue
occurs and gradually
consuming remaining memory
and when reaches to zero upgrade completely hangs and when
console inputs (space bar or return) to continue booting,
Each input advances the
process a little bit. This console i/p's creating some
space for the same . Is this problem in tty?
one more thing we observed
that whenever we increase the logging then this problem
happens regularly.
[ 66.233676]
EXT3-fs (sda14): using internal journal
[ 66.233691]
EXT3-fs (sda14): mounted filesystem with ordered data
mode
[ 76.822878]
par.que...par_queue_user_receive: Freeze check =0
[ 76.828711]
par.que...par_queue_user_receive: <*> returned
-ERESTARTSYS <*> event =-512
[ 76.837241]
par_ldisc_open:record is found for ttyS4
[ 76.842766]
par.que...par_queue_user_receive: Freeze check =0
[ 76.848594]
par.que...par_queue_user_receive: <*> returned
-ERESTARTSYS <*> event =-512
[ 101.781654] usb
1-1.3: USB disconnect, address 3
[ 104.029178] usb
1-1.3: new high speed USB device using fsl-ehci and address
4
[ 104.159085] scsi2
: usb-storage 1-1.3:1.0
[ 105.163726] scsi
2:0:0:0: Direct-Access Kingston
DataTraveler 2.0 1.00 PQ: 0 ANSI: 2
[ 105.173202] sd
2:0:0:0: Attached scsi generic sg1 type 0
[ 105.173686] sd
2:0:0:0: [sdb] 4006912 512-byte logical blocks: (2.05
GB/1.91 GiB)
[ 105.174177] sd
2:0:0:0: [sdb] Write Protect is off
[ 105.174188] sd
2:0:0:0: [sdb] Mode Sense: 23 00 00 00
[ 105.174197] sd
2:0:0:0: [sdb] Assuming drive cache: write through
[ 105.178804] sd
2:0:0:0: [sdb] Assuming drive cache: write through
[ 105.178825]
sdb: sdb1
[ 105.295052] sd
2:0:0:0: [sdb] Assuming drive cache: write through
[ 105.301142] sd
2:0:0:0: [sdb] Attached SCSI removable
disk
- Hangs at this place and
console i/p’s to continue booting.
I have tried with
different sizes and different vendors pen drives but problem
is the same and occurs at the same place.
Your valuable inputs and
suggetions are helpful to fix this issue.
My kernel version is:
2.6.35.6-45.fc14.i686
Thanks in advance for
helping and replying.
Regards,
Narasimharao B
::DISCLAIMER::
----------------------------------------------------------------------------------------------------------------------------------------------------
The contents of
this e-mail and any attachment(s) are confidential and
intended for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or
error-free as information could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain
viruses in transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach
any liability on the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are
solely those of the author and may not necessarily reflect
the
views or opinions of HCL or its affiliates. Any form of
reproduction, dissemination, copying, disclosure,
modification,
distribution and / or publication of this message without
the prior written consent of authorized representative of
HCL is strictly prohibited. If you have received this email
in error please delete it and notify the sender immediately.
Before opening any email and/or attachments, please check
them for viruses and other defects.
----------------------------------------------------------------------------------------------------------------------------------------------------
^ permalink raw reply
* Re: system hang
From: Willy Tarreau @ 2014-04-10 7:55 UTC (permalink / raw)
To: narasimharo bolisetti
Cc: linux-kernel@vger.kernel.org, kernelnewbies@nl.linux.org,
devel@linuxdriverproject.org, linux-serial@vger.kernel.org,
linux-hotplug@vger.kernel.org, greg@kroah.com,
Narasimharao Bolisetti, nrbolisetti@gmail.com,
stable@vger.kernel.org, linux-pci@vger.kernel.org,
linux-usb@vger.kernel.org
In-Reply-To: <1397113552.75117.YahooMailBasic@web160504.mail.bf1.yahoo.com>
On Thu, Apr 10, 2014 at 12:05:52AM -0700, narasimharo bolisetti wrote:
> My kernel version is:
> 2.6.35.6-45.fc14.i686
Maintenance for this kernel has been dropped years ago, so it very
likely contains many bugs that were fixed in more recent ones. You
should definitely upgrade.
Hoping this helps,
Willy
^ permalink raw reply
* RE: system hang
From: Narasimharao Bolisetti @ 2014-04-10 7:59 UTC (permalink / raw)
To: Willy Tarreau, narasimharo bolisetti
Cc: linux-kernel@vger.kernel.org, kernelnewbies@nl.linux.org,
devel@linuxdriverproject.org, linux-serial@vger.kernel.org,
linux-hotplug@vger.kernel.org, greg@kroah.com,
nrbolisetti@gmail.com, stable@vger.kernel.org,
linux-pci@vger.kernel.org, linux-usb@vger.kernel.org
In-Reply-To: <20140410075539.GB25198@1wt.eu>
Hi,
I have checked the same in the recent kernel versions also. Issue is still remain.
Regards,
Narasimharao B
-----Original Message-----
From: Willy Tarreau [mailto:w@1wt.eu]
Sent: 10 April 2014 13:26
To: narasimharo bolisetti
Cc: linux-kernel@vger.kernel.org; kernelnewbies@nl.linux.org; devel@linuxdriverproject.org; linux-serial@vger.kernel.org; linux-hotplug@vger.kernel.org; greg@kroah.com; Narasimharao Bolisetti; nrbolisetti@gmail.com; stable@vger.kernel.org; linux-pci@vger.kernel.org; linux-usb@vger.kernel.org
Subject: Re: system hang
On Thu, Apr 10, 2014 at 12:05:52AM -0700, narasimharo bolisetti wrote:
> My kernel version is:
> 2.6.35.6-45.fc14.i686
Maintenance for this kernel has been dropped years ago, so it very likely contains many bugs that were fixed in more recent ones. You should definitely upgrade.
Hoping this helps,
Willy
::DISCLAIMER::
----------------------------------------------------------------------------------------------------------------------------------------------------
The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and other defects.
----------------------------------------------------------------------------------------------------------------------------------------------------
^ permalink raw reply
* Re: system hang
From: greg @ 2014-04-10 15:59 UTC (permalink / raw)
To: Narasimharao Bolisetti
Cc: Willy Tarreau, narasimharo bolisetti,
linux-kernel@vger.kernel.org, kernelnewbies@nl.linux.org,
devel@linuxdriverproject.org, linux-serial@vger.kernel.org,
linux-hotplug@vger.kernel.org, nrbolisetti@gmail.com,
stable@vger.kernel.org, linux-pci@vger.kernel.org,
linux-usb@vger.kernel.org
In-Reply-To: <62C418AB752FEF4D931AB8E89E46539F02878EC8@chn-hclt-mbs06.HCLT.CORP.HCL.IN>
On Thu, Apr 10, 2014 at 07:59:38AM +0000, Narasimharao Bolisetti wrote:
>
> Hi,
>
> I have checked the same in the recent kernel versions also. Issue is still remain.
What versions have you tried, and what are the logs from those versions?
> ::DISCLAIMER::
> ----------------------------------------------------------------------------------------------------------------------------------------------------
>
> The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
> E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted,
> lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents
> (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates.
> Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the
> views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,
> distribution and / or publication of this message without the prior written consent of authorized representative of
> HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately.
> Before opening any email and/or attachments, please check them for viruses and other defects.
>
> ----------------------------------------------------------------------------------------------------------------------------------------------------
Oops, sorry, nope, I'm not allowed to respond to anyone with such an
email footer, it's not compatible with Linux kernel development (Linux
is not confidential.)
Best of luck, I suggest you work with the vendor who is forcing you to
stick with such an old kernel version.
greg k-h
^ permalink raw reply
* Fn keys on Dell Latitude E6440
From: Pali Rohár @ 2014-04-14 14:51 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: Text/Plain, Size: 1520 bytes --]
Hello,
on my notebook dell-wmi kernel driver generates some scan codes
when I press some of Fn key combinations. Now all these scan
codes are mapped to key "prog3". I would like to add some actions
for these Fn key combinations, so what do you think? Which key
codes should be assigned for these scan codes? Note that these
combinations are not special (and labeled) as other (like Fn+F11
= play/pause) and seems like windows does not recognize them.
Matthew, you are author of dell-wmi driver, do you know if there
are some other secrets key combinations? And why first 10 Fn key
combinations generate scan codes?
Output of commands:
$ lsinput
/dev/input/event7
bustype : BUS_HOST
vendor : 0x0
product : 0x0
version : 0
name : "Dell WMI hotkeys"
phys : "wmi/input0"
bits ev : EV_SYN EV_KEY EV_MSC
$ /lib/udev/keymap -i /dev/input/event7
scan code: 0x10 key code: prog3 --> Fn+Q
scan code: 0x11 key code: prog3 --> Fn+W
scan code: 0x12 key code: prog3 --> Fn+E
scan code: 0x13 key code: prog3 --> Fn+R
scan code: 0x14 key code: prog3 --> Fn+T
scan code: 0x1E key code: prog3 --> Fn+A
scan code: 0x1F key code: prog3 --> Fn+S
scan code: 0x20 key code: prog3 --> Fn+D
scan code: 0x21 key code: prog3 --> Fn+F
scan code: 0x22 key code: prog3 --> Fn+G
$ cat /sys/class/dmi/id/sys_vendor
Dell Inc.
$ cat /sys/class/dmi/id/product_name
Latitude E6440
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ 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