* Re: advice needed for gentoo bug involving lvm2/udev
From: Kay Sievers @ 2011-12-12 23:22 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <20111003164149.GA13439@linux1>
On Mon, Dec 12, 2011 at 22:45, William Hubbs <w.d.hubbs@gmail.com> wrote:
> On Tue, Dec 06, 2011 at 04:10:13PM -0600, William Hubbs wrote:
>> On Tue, Oct 04, 2011 at 03:09:34AM +0200, Kay Sievers wrote:
>> > On Mon, Oct 3, 2011 at 18:41, William Hubbs <w.d.hubbs@gmail.com> wrote:
>> > > we have the following bug posted in gentoo's bugzilla:
>> > >
>> > > http://bugs.gentoo.org/show_bug.cgi?id65227.
>> > >
>> > > The reporter is telling me that we should use --action=change instead of
>> > > --actiond in the cold boot sequence when dev is devtmpfs. However,
>> > > this doesn't seem to be the correct fix based on earlier discussions on
>> > > this list.
>> > >
>> > > Does anyone else have any suggestions for fixing this? My thought is
>> > > that the rules for lvm2 should be fixed. What does everyone else think?
>> >
>> > --actiond is still the recommended and default way of doing coldplug.
>> >
>> > It should only be done once after udevd is started though, and never
>> > again. All later triggers should be change only.
>>
>> The reporter is now saying that --actiond does not touch nodes that
>> are already in the file system, so, for example, if you mount devtmpfs
>> on /dev then call udevadm trigger --actiond, the permissions,
>> ownership, etc, of nodes that already exist are not touched. So, he is
>> suggesting that we add another udevadm trigger call with --action=change
>> to the cold boot sequence.
>>
>> Is this a bug in udev, or should we add this extra udevadm trigger call?
>
> Hi Kay,
>
> I am re-sending this in case you didn't get it before.
>
> Basically, the reporter is now saying that the udevadm trigger
> --actiond is correct, but that the coldplug sequence should include
> udevadm trigger --action=change after the --actiond call.
>
> Is this correct?
No, udev should not trigger any 'change' event during bootup, it
should only trigger 'add' events once and very early during
bootup.
Any other issues need to be fixed by/in the tools, not hacked around in udev.
Kay
^ permalink raw reply
* Thuderbolt/Light Peak hotplug/pci errors
From: vick @ 2011-12-15 23:43 UTC (permalink / raw)
To: linux-pci@vger.kernel.org, linux-hotplug@vger.kernel.org
I have a Sony Vaio Z laptop that has an external media dock that connects to the laptop via a light peak port. The media dock has a video card, dvd, network adapter and a USB 3.0 hub in it.
When I boot the laptop with the media dock connected everything but the video card works, when I plug the media dock when the laptop is already running I get a bunch of errors and the USB hub does not work.
Below is the dmesg output with USB_DEBUG enabled from when I plug the media dock in.
This is vanilla 3.2.0-rc5 kernel from kernel.org and acpiphp module is loaded. The issue us with the usb hub on 1b:00.0 but can somebody look at the rest of the errors as well and see if something stands out?
I've also attempted to get the video card working and there's something very weird going on there. When the media dock was plugged in while booting there are 2 video cards shown by lspci - an Intel card at 2:00.0 and a radeon card at 16:00.0. However all of the xorg and proprietary ati drivers I have tried do not seem to find anything on 16:00.0 but do find video devices on 22:00.0 and 22:00.1 which does not show in lspci.
Full dmesg output can be seen here: http://www.mediafire.com/?7cc2jkx21gjxnhy,2axd6hurku3mypd
working.txt is when the media dock was connected prior to booting, nonworking1.txt is the one where the media dock was connected around the 26th second.
Thanks for the help!
[ 26.714909] ACPI: \_SB_.DOCK - docking
[ 26.717134] pci 0000:08:00.0: [8086:151b] type 1 class 0x000604
[ 26.717227] pci 0000:08:00.0: supports D1 D2
[ 26.717228] pci 0000:08:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 26.717234] pci 0000:08:00.0: PME# disabled
[ 26.717351] pci 0000:0a:00.0: [8086:151b] type 1 class 0x000604
[ 26.717442] pci 0000:0a:00.0: supports D1 D2
[ 26.717443] pci 0000:0a:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 26.717449] pci 0000:0a:00.0: PME# disabled
[ 26.717508] pci 0000:0a:03.0: [8086:151b] type 1 class 0x000604
[ 26.717604] pci 0000:0a:03.0: supports D1 D2
[ 26.717605] pci 0000:0a:03.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 26.717610] pci 0000:0a:03.0: PME# disabled
[ 26.717660] pci 0000:0a:04.0: [8086:151b] type 1 class 0x000604
[ 26.717751] pci 0000:0a:04.0: supports D1 D2
[ 26.717752] pci 0000:0a:04.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 26.717757] pci 0000:0a:04.0: PME# disabled
[ 26.717831] pci 0000:08:00.0: PCI bridge to [bus 0a-1d]
[ 26.719281] pci 0000:08:00.0: bridge window [io 0x3000-0x5fff]
[ 26.719287] pci 0000:08:00.0: bridge window [mem 0xb0000000-0xc03fffff]
[ 26.719296] pci 0000:08:00.0: bridge window [mem 0xd4400000-0xd44fffff 64bit pref]
[ 26.719363] pci 0000:0a:00.0: PCI bridge to [bus 0b-0b]
[ 26.720785] pci 0000:0a:00.0: bridge window [mem 0xc0300000-0xc03fffff]
[ 26.720861] pci 0000:0a:03.0: PCI bridge to [bus 0c-0c]
[ 26.722375] pci 0000:14:00.0: [8086:151b] type 1 class 0x000604
[ 26.722529] pci 0000:14:00.0: supports D1 D2
[ 26.722531] pci 0000:14:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 26.722538] pci 0000:14:00.0: PME# disabled
[ 26.722593] pci 0000:0a:04.0: PCI bridge to [bus 14-1d]
[ 26.723991] pci 0000:0a:04.0: bridge window [io 0x3000-0x5fff]
[ 26.723996] pci 0000:0a:04.0: bridge window [mem 0xb0000000-0xc02fffff]
[ 26.724005] pci 0000:0a:04.0: bridge window [mem 0xd4400000-0xd44fffff 64bit pref]
[ 26.724162] pci 0000:15:03.0: [8086:151b] type 1 class 0x000604
[ 26.724318] pci 0000:15:03.0: supports D1 D2
[ 26.724319] pci 0000:15:03.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 26.724327] pci 0000:15:03.0: PME# disabled
[ 26.724407] pci 0000:15:04.0: [8086:151b] type 1 class 0x000604
[ 26.724563] pci 0000:15:04.0: supports D1 D2
[ 26.724564] pci 0000:15:04.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 26.724572] pci 0000:15:04.0: PME# disabled
[ 26.724697] pci 0000:14:00.0: PCI bridge to [bus 15-1d]
[ 26.726080] pci 0000:14:00.0: bridge window [io 0x3000-0x5fff]
[ 26.726088] pci 0000:14:00.0: bridge window [mem 0xb0000000-0xc02fffff]
[ 26.726101] pci 0000:14:00.0: bridge window [mem 0xd4400000-0xd44fffff 64bit pref]
[ 26.726252] pci 0000:16:00.0: [1002:6740] type 0 class 0x000300
[ 26.726308] pci 0000:16:00.0: reg 10: [mem 0x00000000-0x0fffffff 64bit pref]
[ 26.726352] pci 0000:16:00.0: reg 18: [mem 0x00000000-0x0001ffff 64bit]
[ 26.726381] pci 0000:16:00.0: reg 20: [io 0x0000-0x00ff]
[ 26.726437] pci 0000:16:00.0: reg 30: [mem 0x00000000-0x0001ffff pref]
[ 26.726513] pci 0000:16:00.0: supports D1 D2
[ 26.726602] pci 0000:16:00.1: [1002:aa90] type 0 class 0x000403
[ 26.726661] pci 0000:16:00.1: reg 10: [mem 0x00000000-0x00003fff 64bit]
[ 26.726871] pci 0000:16:00.1: supports D1 D2
[ 26.726942] pci 0000:15:03.0: PCI bridge to [bus 16-16]
[ 26.728314] pci 0000:15:03.0: bridge window [io 0x5000-0x5fff]
[ 26.728322] pci 0000:15:03.0: bridge window [mem 0xc0200000-0xc02fffff]
[ 26.728335] pci 0000:15:03.0: bridge window [mem 0xb0000000-0xbfffffff 64bit pref]
[ 26.728501] pci 0000:17:00.0: [8086:151b] type 1 class 0x000604
[ 26.728719] pci 0000:17:00.0: supports D1 D2
[ 26.728721] pci 0000:17:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 26.728731] pci 0000:17:00.0: PME# disabled
[ 26.728810] pci 0000:15:04.0: PCI bridge to [bus 17-1d]
[ 26.730163] pci 0000:15:04.0: bridge window [io 0x3000-0x4fff]
[ 26.730171] pci 0000:15:04.0: bridge window [mem 0xc0000000-0xc01fffff]
[ 26.730185] pci 0000:15:04.0: bridge window [mem 0xd4400000-0xd44fffff 64bit pref]
[ 26.730392] pci 0000:18:00.0: [8086:151b] type 1 class 0x000604
[ 26.730619] pci 0000:18:00.0: supports D1 D2
[ 26.730620] pci 0000:18:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 26.730631] pci 0000:18:00.0: PME# disabled
[ 26.730765] pci 0000:18:01.0: [8086:151b] type 1 class 0x000604
[ 26.730986] pci 0000:18:01.0: supports D1 D2
[ 26.730988] pci 0000:18:01.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 26.730998] pci 0000:18:01.0: PME# disabled
[ 26.731115] pci 0000:18:02.0: [8086:151b] type 1 class 0x000604
[ 26.731337] pci 0000:18:02.0: supports D1 D2
[ 26.731338] pci 0000:18:02.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 26.731349] pci 0000:18:02.0: PME# disabled
[ 26.731470] pci 0000:18:03.0: [8086:151b] type 1 class 0x000604
[ 26.731692] pci 0000:18:03.0: supports D1 D2
[ 26.731693] pci 0000:18:03.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 26.731704] pci 0000:18:03.0: PME# disabled
[ 26.731829] pci 0000:18:04.0: [8086:151b] type 1 class 0x000604
[ 26.732051] pci 0000:18:04.0: supports D1 D2
[ 26.732052] pci 0000:18:04.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 26.732062] pci 0000:18:04.0: PME# disabled
[ 26.732252] pci 0000:17:00.0: PCI bridge to [bus 18-1d]
[ 26.733602] pci 0000:17:00.0: bridge window [io 0x3000-0x4fff]
[ 26.733613] pci 0000:17:00.0: bridge window [mem 0xc0000000-0xc01fffff]
[ 26.733631] pci 0000:17:00.0: bridge window [mem 0xd4400000-0xd44fffff 64bit pref]
[ 26.733851] pci 0000:19:00.0: [10ec:8168] type 0 class 0x000200
[ 26.733905] pci 0000:19:00.0: reg 10: [io 0x0000-0x00ff]
[ 26.734000] pci 0000:19:00.0: reg 18: [mem 0x00000000-0x00000fff 64bit pref]
[ 26.734059] pci 0000:19:00.0: reg 20: [mem 0x00000000-0x00003fff 64bit pref]
[ 26.734228] pci 0000:19:00.0: supports D1 D2
[ 26.734230] pci 0000:19:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[ 26.734242] pci 0000:19:00.0: PME# disabled
[ 26.734336] pci 0000:18:00.0: PCI bridge to [bus 19-19]
[ 26.735646] pci 0000:18:00.0: bridge window [io 0x4000-0x4fff]
[ 26.735674] pci 0000:18:00.0: bridge window [mem 0xd4400000-0xd44fffff 64bit pref]
[ 26.735897] pci 0000:1a:00.0: [11ab:6121] type 0 class 0x000101
[ 26.735951] pci 0000:1a:00.0: reg 10: [io 0x8000-0x8007]
[ 26.735989] pci 0000:1a:00.0: reg 14: [io 0x8040-0x8043]
[ 26.736027] pci 0000:1a:00.0: reg 18: [io 0x8200-0x8207]
[ 26.736065] pci 0000:1a:00.0: reg 1c: [io 0x8800-0x8803]
[ 26.736103] pci 0000:1a:00.0: reg 20: [io 0x900000-0x90000f]
[ 26.736142] pci 0000:1a:00.0: reg 24: [mem 0x00800000-0x008003ff]
[ 26.736294] pci 0000:1a:00.0: supports D1
[ 26.736295] pci 0000:1a:00.0: PME# supported from D0 D1 D3hot
[ 26.736307] pci 0000:1a:00.0: PME# disabled
[ 26.736365] pci 0000:1a:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force'
[ 26.737704] pci 0000:18:01.0: PCI bridge to [bus 1a-1a]
[ 26.739075] pci 0000:18:01.0: bridge window [io 0x3000-0x3fff]
[ 26.739085] pci 0000:18:01.0: bridge window [mem 0xc0100000-0xc01fffff]
[ 26.739334] pci 0000:1b:00.0: [1033:0194] type 0 class 0x000c03
[ 26.739405] pci 0000:1b:00.0: reg 10: [mem 0x00000000-0x00001fff 64bit]
[ 26.739706] pci 0000:1b:00.0: PME# supported from D0 D3hot D3cold
[ 26.739717] pci 0000:1b:00.0: PME# disabled
[ 26.739802] pci 0000:18:02.0: PCI bridge to [bus 1b-1b]
[ 26.741179] pci 0000:18:02.0: bridge window [mem 0xc0000000-0xc00fffff]
[ 26.741360] pci 0000:18:03.0: PCI bridge to [bus 1c-1c]
[ 26.742925] pci 0000:18:04.0: PCI bridge to [bus 1d-1d]
[ 26.745179] ACPI: Delete PCI Interrupt Routing Table for 0000:0a
[ 26.745497] [Firmware Bug]: ACPI(GFXA) defines _DOD but not _DOS
[ 26.747443] input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/device:1f/device:4d/device:50/device:51/device:52/LNXVIDEO:0a/input/input8
[ 26.749281] ACPI: Video Device [GFXA] (multi-head: yes rom: no post: no)
[ 26.750838] [Firmware Bug]: Duplicate ACPI video bus devices for the same VGA controller, please try module parameter "video.allow_duplicates=1"if the current driver doesn't work.
[ 26.752790] [Firmware Bug]: Duplicate ACPI video bus devices for the same VGA controller, please try module parameter "video.allow_duplicates=1"if the current driver doesn't work.
[ 26.754290] [Firmware Bug]: Duplicate ACPI video bus devices for the same VGA controller, please try module parameter "video.allow_duplicates=1"if the current driver doesn't work.
[ 26.755769] [Firmware Bug]: Duplicate ACPI video bus devices for the same VGA controller, please try module parameter "video.allow_duplicates=1"if the current driver doesn't work.
[ 26.757225] [Firmware Bug]: Duplicate ACPI video bus devices for the same VGA controller, please try module parameter "video.allow_duplicates=1"if the current driver doesn't work.
[ 26.758682] [Firmware Bug]: Duplicate ACPI video bus devices for the same VGA controller, please try module parameter "video.allow_duplicates=1"if the current driver doesn't work.
[ 26.760112] [Firmware Bug]: Duplicate ACPI video bus devices for the same VGA controller, please try module parameter "video.allow_duplicates=1"if the current driver doesn't work.
[ 26.762090] pci 0000:08:00.0: BAR 15: assigned [mem 0xb0000000-0xcbffffff pref]
[ 26.763835] pci 0000:08:00.0: BAR 14: can't assign mem (size 0x10400000)
[ 26.765355] pci 0000:08:00.0: BAR 13: assigned [io 0x3000-0x5fff]
[ 26.766702] pci 0000:0a:04.0: BAR 15: assigned [mem 0xb0000000-0xcbffffff pref]
[ 26.768037] pci 0000:0a:00.0: BAR 14: can't assign mem (size 0x100000)
[ 26.769372] pci 0000:0a:04.0: BAR 14: can't assign mem (size 0x10300000)
[ 26.770672] pci 0000:0a:04.0: BAR 13: assigned [io 0x3000-0x5fff]
[ 26.771932] pci 0000:0a:00.0: PCI bridge to [bus 0b-0b]
[ 26.773203] pci 0000:0a:03.0: PCI bridge to [bus 0c-0c]
[ 26.774463] pci 0000:14:00.0: BAR 15: assigned [mem 0xb0000000-0xcbffffff pref]
[ 26.775729] pci 0000:14:00.0: BAR 14: can't assign mem (size 0x10300000)
[ 26.776986] pci 0000:14:00.0: BAR 13: assigned [io 0x3000-0x5fff]
[ 26.778253] pci 0000:15:03.0: BAR 15: assigned [mem 0xb0000000-0xc7ffffff pref]
[ 26.779533] pci 0000:15:03.0: BAR 14: can't assign mem (size 0x100000)
[ 26.780812] pci 0000:15:04.0: BAR 14: can't assign mem (size 0x200000)
[ 26.782086] pci 0000:15:04.0: BAR 15: assigned [mem 0xc8000000-0xc80fffff 64bit pref]
[ 26.783356] pci 0000:15:03.0: BAR 13: assigned [io 0x3000-0x3fff]
[ 26.784600] pci 0000:15:04.0: BAR 13: assigned [io 0x4000-0x5fff]
[ 26.785829] pci 0000:16:00.0: BAR 0: assigned [mem 0xb0000000-0xbfffffff 64bit pref]
[ 26.787098] pci 0000:16:00.0: BAR 0: set to [mem 0xb0000000-0xbfffffff 64bit pref] (PCI address [0xb0000000-0xbfffffff])
[ 26.788379] pci 0000:16:00.0: BAR 2: can't assign mem (size 0x20000)
[ 26.789661] pci 0000:16:00.0: BAR 6: assigned [mem 0xc0000000-0xc001ffff pref]
[ 26.790950] pci 0000:16:00.1: BAR 0: can't assign mem (size 0x4000)
[ 26.792240] pci 0000:16:00.0: BAR 4: assigned [io 0x3000-0x30ff]
[ 26.793535] pci 0000:16:00.0: BAR 4: set to [io 0x3000-0x30ff] (PCI address [0x3000-0x30ff])
[ 26.794841] pci 0000:15:03.0: PCI bridge to [bus 16-16]
[ 26.796135] pci 0000:15:03.0: bridge window [io 0x3000-0x3fff]
[ 26.797446] pci 0000:15:03.0: bridge window [mem 0xb0000000-0xc7ffffff pref]
[ 26.798767] pci 0000:17:00.0: BAR 14: can't assign mem (size 0x200000)
[ 26.800078] pci 0000:17:00.0: BAR 15: assigned [mem 0xc8000000-0xc80fffff 64bit pref]
[ 26.801389] pci 0000:17:00.0: BAR 13: assigned [io 0x4000-0x5fff]
[ 26.802689] pci 0000:18:00.0: BAR 15: assigned [mem 0xc8000000-0xc80fffff 64bit pref]
[ 26.803985] pci 0000:18:01.0: BAR 14: can't assign mem (size 0x100000)
[ 26.805290] pci 0000:18:02.0: BAR 14: can't assign mem (size 0x100000)
[ 26.806570] pci 0000:18:00.0: BAR 13: assigned [io 0x4000-0x4fff]
[ 26.807842] pci 0000:18:01.0: BAR 13: assigned [io 0x5000-0x5fff]
[ 26.809111] pci 0000:19:00.0: BAR 4: assigned [mem 0xc8000000-0xc8003fff 64bit pref]
[ 26.810423] pci 0000:19:00.0: BAR 4: set to [mem 0xc8000000-0xc8003fff 64bit pref] (PCI address [0xc8000000-0xc8003fff])
[ 26.811725] pci 0000:19:00.0: BAR 2: assigned [mem 0xc8004000-0xc8004fff 64bit pref]
[ 26.813040] pci 0000:19:00.0: BAR 2: set to [mem 0xc8004000-0xc8004fff 64bit pref] (PCI address [0xc8004000-0xc8004fff])
[ 26.814344] pci 0000:19:00.0: BAR 0: assigned [io 0x4000-0x40ff]
[ 26.815647] pci 0000:19:00.0: BAR 0: set to [io 0x4000-0x40ff] (PCI address [0x4000-0x40ff])
[ 26.816940] pci 0000:18:00.0: PCI bridge to [bus 19-19]
[ 26.818232] pci 0000:18:00.0: bridge window [io 0x4000-0x4fff]
[ 26.819553] pci 0000:18:00.0: bridge window [mem 0xc8000000-0xc80fffff 64bit pref]
[ 26.820885] pci 0000:1a:00.0: BAR 5: can't assign mem (size 0x400)
[ 26.822207] pci 0000:1a:00.0: BAR 4: assigned [io 0x5000-0x500f]
[ 26.823549] pci 0000:1a:00.0: BAR 4: set to [io 0x5000-0x500f] (PCI address [0x5000-0x500f])
[ 26.824904] pci 0000:1a:00.0: BAR 0: assigned [io 0x5010-0x5017]
[ 26.826276] pci 0000:1a:00.0: BAR 0: set to [io 0x5010-0x5017] (PCI address [0x5010-0x5017])
[ 26.827669] pci 0000:1a:00.0: BAR 2: assigned [io 0x5018-0x501f]
[ 26.829073] pci 0000:1a:00.0: BAR 2: set to [io 0x5018-0x501f] (PCI address [0x5018-0x501f])
[ 26.830462] pci 0000:1a:00.0: BAR 1: assigned [io 0x5020-0x5023]
[ 26.831850] pci 0000:1a:00.0: BAR 1: set to [io 0x5020-0x5023] (PCI address [0x5020-0x5023])
[ 26.833243] pci 0000:1a:00.0: BAR 3: assigned [io 0x5024-0x5027]
[ 26.834665] pci 0000:1a:00.0: BAR 3: set to [io 0x5024-0x5027] (PCI address [0x5024-0x5027])
[ 26.836092] pci 0000:18:01.0: PCI bridge to [bus 1a-1a]
[ 26.837511] pci 0000:18:01.0: bridge window [io 0x5000-0x5fff]
[ 26.838937] pci 0000:1b:00.0: BAR 0: can't assign mem (size 0x2000)
[ 26.840290] pci 0000:18:02.0: PCI bridge to [bus 1b-1b]
[ 26.841634] pci 0000:18:03.0: PCI bridge to [bus 1c-1c]
[ 26.842987] pci 0000:18:04.0: PCI bridge to [bus 1d-1d]
[ 26.844341] pci 0000:17:00.0: PCI bridge to [bus 18-1d]
[ 26.845663] pci 0000:17:00.0: bridge window [io 0x4000-0x5fff]
[ 26.847023] pci 0000:17:00.0: bridge window [mem 0xc8000000-0xc80fffff 64bit pref]
[ 26.848390] pci 0000:15:04.0: PCI bridge to [bus 17-1d]
[ 26.849757] pci 0000:15:04.0: bridge window [io 0x4000-0x5fff]
[ 26.851098] pci 0000:15:04.0: bridge window [mem 0xc8000000-0xc80fffff 64bit pref]
[ 26.852434] pci 0000:14:00.0: PCI bridge to [bus 15-1d]
[ 26.853759] pci 0000:14:00.0: bridge window [io 0x3000-0x5fff]
[ 26.855101] pci 0000:14:00.0: bridge window [mem 0xb0000000-0xcbffffff pref]
[ 26.856433] pci 0000:0a:04.0: PCI bridge to [bus 14-1d]
[ 26.857767] pci 0000:0a:04.0: bridge window [io 0x3000-0x5fff]
[ 26.859113] pci 0000:0a:04.0: bridge window [mem 0xb0000000-0xcbffffff pref]
[ 26.860458] pci 0000:08:00.0: PCI bridge to [bus 0a-1d]
[ 26.861803] pci 0000:08:00.0: bridge window [io 0x3000-0x5fff]
[ 26.863159] pci 0000:08:00.0: bridge window [mem 0xb0000000-0xcbffffff pref]
[ 26.864512] pci 0000:08:00.0: no hotplug settings from platform
[ 26.865856] pci 0000:0a:00.0: no hotplug settings from platform
[ 26.867190] pci 0000:0a:03.0: no hotplug settings from platform
[ 26.868503] pci 0000:0a:04.0: no hotplug settings from platform
[ 26.869820] pci 0000:14:00.0: no hotplug settings from platform
[ 26.871123] pci 0000:15:03.0: no hotplug settings from platform
[ 26.872412] pci 0000:16:00.0: no hotplug settings from platform
[ 26.873698] pci 0000:16:00.1: no hotplug settings from platform
[ 26.874972] pci 0000:15:04.0: no hotplug settings from platform
[ 26.876222] pci 0000:17:00.0: no hotplug settings from platform
[ 26.877442] pci 0000:18:00.0: no hotplug settings from platform
[ 26.878650] pci 0000:19:00.0: no hotplug settings from platform
[ 26.879841] pci 0000:18:01.0: no hotplug settings from platform
[ 26.881025] pci 0000:1a:00.0: no hotplug settings from platform
[ 26.882189] pci 0000:18:02.0: no hotplug settings from platform
[ 26.883336] pci 0000:1b:00.0: no hotplug settings from platform
[ 26.884471] pci 0000:18:03.0: no hotplug settings from platform
[ 26.885597] pci 0000:18:04.0: no hotplug settings from platform
[ 26.886717] pci 0000:08:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[ 26.887831] pci 0000:08:00.0: setting latency timer to 64
[ 26.887840] pci 0000:0a:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[ 26.888944] pci 0000:0a:00.0: setting latency timer to 64
[ 26.888953] pci 0000:0a:03.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[ 26.890045] pci 0000:0a:03.0: setting latency timer to 64
[ 26.890053] pci 0000:0a:04.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[ 26.891132] pci 0000:0a:04.0: setting latency timer to 64
[ 26.891142] pci 0000:14:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[ 26.892220] pci 0000:14:00.0: setting latency timer to 64
[ 26.892232] pci 0000:15:03.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[ 26.893297] pci 0000:15:03.0: setting latency timer to 64
[ 26.893309] pci 0000:15:04.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[ 26.894377] pci 0000:15:04.0: setting latency timer to 64
[ 26.894391] pci 0000:17:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[ 26.895448] pci 0000:17:00.0: setting latency timer to 64
[ 26.895464] pci 0000:18:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[ 26.896493] pci 0000:18:00.0: setting latency timer to 64
[ 26.896509] pci 0000:18:01.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
[ 26.897510] pci 0000:18:01.0: setting latency timer to 64
[ 26.897526] pci 0000:18:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 26.898503] pci 0000:18:02.0: setting latency timer to 64
[ 26.898519] pci 0000:18:03.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[ 26.899480] pci 0000:18:03.0: setting latency timer to 64
[ 26.899496] pci 0000:18:04.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[ 26.900432] pci 0000:18:04.0: setting latency timer to 64
[ 26.900504] pcieport 0000:08:00.0: setting latency timer to 64
[ 26.900569] pcieport 0000:08:00.0: irq 48 for MSI/MSI-X
[ 26.900738] pcieport 0000:0a:00.0: setting latency timer to 64
[ 26.900799] pcieport 0000:0a:00.0: irq 49 for MSI/MSI-X
[ 26.900959] pcieport 0000:0a:03.0: setting latency timer to 64
[ 26.901021] pcieport 0000:0a:03.0: irq 50 for MSI/MSI-X
[ 26.901180] pcieport 0000:0a:04.0: setting latency timer to 64
[ 26.901241] pcieport 0000:0a:04.0: irq 51 for MSI/MSI-X
[ 26.901425] pcieport 0000:14:00.0: setting latency timer to 64
[ 26.901526] pcieport 0000:14:00.0: irq 52 for MSI/MSI-X
[ 26.901742] pcieport 0000:15:03.0: setting latency timer to 64
[ 26.901845] pcieport 0000:15:03.0: irq 53 for MSI/MSI-X
[ 26.902113] pcieport 0000:15:04.0: setting latency timer to 64
[ 26.902224] pcieport 0000:15:04.0: irq 54 for MSI/MSI-X
[ 26.902446] vgaarb: device added: PCI:0000:16:00.0,decodes=io+mem,owns=none,locks=none
[ 26.903397] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=none:owns=io+mem
[ 26.904512] vgaarb: transferring owner from PCI:0000:00:02.0 to PCI:0000:16:00.0
[ 26.905754] pcieport 0000:17:00.0: setting latency timer to 64
[ 26.905901] pcieport 0000:17:00.0: irq 55 for MSI/MSI-X
[ 26.906263] pcieport 0000:18:00.0: setting latency timer to 64
[ 26.906415] pcieport 0000:18:00.0: irq 56 for MSI/MSI-X
[ 26.906753] pcieport 0000:18:01.0: setting latency timer to 64
[ 26.906900] pcieport 0000:18:01.0: irq 57 for MSI/MSI-X
[ 26.907205] pcieport 0000:18:02.0: setting latency timer to 64
[ 26.907349] pcieport 0000:18:02.0: irq 58 for MSI/MSI-X
[ 26.907666] pcieport 0000:18:03.0: setting latency timer to 64
[ 26.907819] pcieport 0000:18:03.0: irq 59 for MSI/MSI-X
[ 26.908174] pcieport 0000:18:04.0: setting latency timer to 64
[ 26.908323] pcieport 0000:18:04.0: irq 60 for MSI/MSI-X
[ 26.908631] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[ 26.909687] r8169 0000:19:00.0: enabling device (0000 -> 0003)
[ 26.910678] r8169 0000:19:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
[ 26.911866] r8169 0000:19:00.0: setting latency timer to 64
[ 26.912049] r8169 0000:19:00.0: irq 61 for MSI/MSI-X
[ 26.912467] r8169 0000:19:00.0: eth1: RTL8168evl/8111evl at 0xffffc90000c3e000, 54:42:49:97:a2:64, XID 0c900800 IRQ 61
[ 26.913617] r8169 0000:19:00.0: eth1: jumbo features [frames: 9200 bytes, tx checksumming: ko]
[ 26.914976] xhci_hcd 0000:1b:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[ 26.916313] xhci_hcd 0000:1b:00.0: controller already in use
[ 26.916351] xhci_hcd 0000:1b:00.0: PCI INT A disabled
[ 26.917766] xhci_hcd 0000:1b:00.0: init 0000:1b:00.0 fail, -16
[ 26.919149] xhci_hcd: probe of 0000:1b:00.0 failed with error -16
[ 26.920364] acpiphp: Slot [1-1] registered
[ 26.921538] acpiphp: Slot [2] registered
[ 26.922522] acpiphp: Slot [3] registered
[ 26.923541] acpiphp: Slot [1-2] registered
[ 26.924485] acpiphp_glue: sibling found, but _SUN doesn't match!
[ 26.925541] pata_marvell 0000:1a:00.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
[ 26.925604] acpiphp: Slot [1-3] registered
[ 26.925659] acpiphp: Slot [1-4] registered
[ 26.925710] acpiphp: Slot [1-5] registered
[ 26.929479] pata_marvell 0000:1a:00.0: setting latency timer to 64
[ 26.929983] scsi6 : pata_marvell
[ 26.931004] scsi7 : pata_marvell
[ 26.931981] ata7: PATA max UDMA/100 cmd 0x5010 ctl 0x5020 bmdma 0x5000 irq 19
[ 26.932980] ata8: PATA max UDMA/133 cmd 0x5018 ctl 0x5024 bmdma 0x5008 irq 19
[ 27.295886] ata8.00: ATAPI: Optiarc DVD RW AD-7690H, 1.70, max UDMA/100
[ 27.311893] ata8.00: configured for UDMA/100
[ 27.316989] scsi 7:0:0:0: CD-ROM Optiarc DVD RW AD-7690H 1.70 PQ: 0 ANSI: 5
[ 27.334382] sr0: scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw xa/form2 cdda caddy
[ 27.335401] cdrom: Uniform CD-ROM driver Revision: 3.20
[ 27.336636] sr 7:0:0:0: Attached scsi CD-ROM sr0
^ permalink raw reply
* [PATCH] keymap: Fix touchpad toggle key on Asus
From: Keng-Yu Lin @ 2011-12-16 2:40 UTC (permalink / raw)
To: linux-hotplug
https://launchpad.net/bugs/898526
Signed-off-by: Keng-Yu Lin <kengyu@canonical.com>
---
| 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
--git a/extras/keymap/95-keymap.rules b/extras/keymap/95-keymap.rules
index 248c58f..6c44e04 100644
--- a/extras/keymap/95-keymap.rules
+++ b/extras/keymap/95-keymap.rules
@@ -47,6 +47,7 @@ ENV{DMI_VENDOR}="LENOVO*", KERNELS="input*", ATTRS{name}="ThinkPad Extra Butt
ENV{DMI_VENDOR}="LENOVO*", KERNELS="input*", ATTRS{name}="Lenovo ThinkPad SL Series extra buttons", RUN+="keymap $name 0x0E bluetooth"
ENV{DMI_VENDOR}="ASUS*", KERNELS="input*", ATTRS{name}="Asus Extra Buttons", ATTR{[dmi/id]product_name}="W3J", RUN+="keymap $name module-asus-w3j"
+ENV{DMI_VENDOR}="ASUS*", KERNELS="input*", ATTRS{name}="Asus WMI hotkeys", RUN+="keymap $name 0x6b f21"
ENV{DMI_VENDOR}="ASUS*", KERNELS="input*", ATTRS{name}="Eee PC WMI hotkeys|Asus Laptop Support|Asus*WMI*", RUN+="keymap $name 0x6B f21"
ENV{DMI_VENDOR}="ASUS*", KERNELS="input*", ATTRS{name}="Eee PC Hotkey Driver", RUN+="keymap $name 0x37 f21"
--
1.7.5.4
^ permalink raw reply related
* [PATCH 1/1] udevd: process events with timeliness requirements during exit to avoid deadlock
From: Andy Whitcroft @ 2011-12-16 17:35 UTC (permalink / raw)
To: linux-hotplug
When processing the incoming kernel event stream we typically enqueue
events, with those events being fed to workers as they become free.
The one exception is for events which indicate a timeliness requirement
(TIMEOUT=N). Queueing these would violate this constraint and so they
are started immediatly regardless of the number of workers.
Typically events with timeliness requirements are firmware events.
The common case here is for a device add event to pop out of the kernel
during device discovery, udev responds by triggering a module load event.
The module initialisation may then require firmware to initialise the
card which triggers a firmware load event for the device. This firmware
event pops out of the kernel into udevs queue. As this is blocking the
modprobe the kernel indicates timeliness on the request, and this in turn
allows the event to be processed immediatly. This convieniently avoids
a potential deadlock should all of the workers be busy running module
loads which required firmware.
In exit (udevadm control --exit) processing we currently dump the entire
incoming queue and ignore any further incoming kernel events. We then wait
for the current workers to complete any events they were assigned, before
finally exiting. However if any of the pending events should trigger a
nested event that new event would not be processed preventing completion
of the existing worker event. We will eventually timeout both leading
to a long boot delay and in some cases to partially initialised cards.
These cards often will not be repaired even during coldplug and are lost
requiring manual intervention to recover.
Modify exit processing such that we handle events with timeliness
constraints on them, bringing them into line with normal processing.
This allows events which are triggered from our existing workers events
to run to completion and allow completion of those workers. This allows
us to flush the queue and exit cleanly.
BugLink: http://bugs.launchpad.net/bugs/842560
Signed-off-by: Andy Whitcroft <apw@canonical.com>
---
udev/udevd.c | 39 ++++++++++++++++++++++++++++-----------
1 files changed, 28 insertions(+), 11 deletions(-)
This bug is triggered on some machines we have with two bnx2 network
interfaces each of which needs two firmware blobs loading. If we find the
root disks in the middle we request udev exit so we can transition to the
version in the real root. This request deadlocks resulting in a timeout.
The firmware never gets loaded for the second card and manual intervention
is required to recover the card.
It should also be noted that this change does slightly exacerbate what I
believe is an existing bug in the timeout handling. We essentially reset
the pending timout to the maximum every time we handle any incoming event,
for example when a worker completes. This does render the exact timeout
somewhat hard to predict, before and after this change.
diff --git a/udev/udevd.c b/udev/udevd.c
index 05d4b2d..19f7128 100644
--- a/udev/udevd.c
+++ b/udev/udevd.c
@@ -584,7 +584,7 @@ static void event_queue_start(struct udev *udev)
}
}
-static void event_queue_cleanup(struct udev *udev, enum event_state match_type)
+static void __event_queue_cleanup(struct udev *udev, enum event_state match_type, bool keep_timely)
{
struct udev_list_node *loop, *tmp;
@@ -594,10 +594,25 @@ static void event_queue_cleanup(struct udev *udev, enum event_state match_type)
if (match_type != EVENT_UNDEF && match_type != event->state)
continue;
+ /* Keep events which have timelyness requirements
+ * we will skew these timeouts on coldplug. */
+ if (keep_timely && udev_device_get_timeout(event->dev) > 0)
+ continue;
+
event_queue_delete(event, false);
}
}
+static void event_queue_cleanup(struct udev *udev, enum event_state match_type)
+{
+ __event_queue_cleanup(udev, match_type, false);
+}
+
+static void event_queue_cleanup_nontimely(struct udev *udev, enum event_state match_type)
+{
+ __event_queue_cleanup(udev, match_type, true);
+}
+
static void worker_returned(int fd_worker)
{
for (;;) {
@@ -1580,24 +1595,21 @@ int main(int argc, char *argv[])
int i;
if (udev_exit) {
- /* close sources of new events and discard buffered events */
+ /* close sources of new events and discard buffered events,
+ * keep the kernel channel so we can pick out events with a
+ * timeliness requirement to avoid deadlock. */
if (fd_ctrl >= 0) {
epoll_ctl(fd_ep, EPOLL_CTL_DEL, fd_ctrl, NULL);
fd_ctrl = -1;
}
- if (monitor != NULL) {
- epoll_ctl(fd_ep, EPOLL_CTL_DEL, fd_netlink, NULL);
- udev_monitor_unref(monitor);
- monitor = NULL;
- }
if (fd_inotify >= 0) {
epoll_ctl(fd_ep, EPOLL_CTL_DEL, fd_inotify, NULL);
close(fd_inotify);
fd_inotify = -1;
}
- /* discard queued events and kill workers */
- event_queue_cleanup(udev, EVENT_QUEUED);
+ /* discard queued non-timely events and kill workers */
+ event_queue_cleanup_nontimely(udev, EVENT_QUEUED);
worker_kill(udev, 0);
/* exit after all has cleaned up */
@@ -1649,8 +1661,13 @@ int main(int argc, char *argv[])
dev = udev_monitor_receive_device(monitor);
if (dev != NULL) {
- udev_device_set_usec_initialized(dev, now_usec());
- if (event_queue_insert(dev) < 0)
+ /* If we are exiting then only schedule events with
+ * timeliness requirements. */
+ if (!udev_exit || udev_device_get_timeout(dev) > 0) {
+ udev_device_set_usec_initialized(dev, now_usec());
+ if (event_queue_insert(dev) < 0)
+ udev_device_unref(dev);
+ } else
udev_device_unref(dev);
}
}
--
1.7.5.4
^ permalink raw reply
* [RESEND PATCH 1/1] udevd: process events with timeliness requirements during exit to avoid deadlock
From: Andy Whitcroft @ 2011-12-16 17:46 UTC (permalink / raw)
To: linux-hotplug
When processing the incoming kernel event stream we typically enqueue
events, with those events being fed to workers as they become free.
The one exception is for events which indicate a timeliness requirement
(TIMEOUT=N). Queueing these would violate this constraint and so they
are started immediatly regardless of the number of workers.
Typically events with timeliness requirements are firmware events.
The common case here is for a device add event to pop out of the kernel
during device discovery, udev responds by triggering a module load event.
The module initialisation may then require firmware to initialise the
card which triggers a firmware load event for the device. This firmware
event pops out of the kernel into udevs queue. As this is blocking the
modprobe the kernel indicates timeliness on the request, and this in turn
allows the event to be processed immediatly. This convieniently avoids
a potential deadlock should all of the workers be busy running module
loads which required firmware.
In exit (udevadm control --exit) processing we currently dump the entire
incoming queue and ignore any further incoming kernel events. We then wait
for the current workers to complete any events they were assigned, before
finally exiting. However if any of the pending events should trigger a
nested event that new event would not be processed preventing completion
of the existing worker event. We will eventually timeout both leading
to a long boot delay and in some cases to partially initialised cards.
These cards often will not be repaired even during coldplug and are lost
requiring manual intervention to recover.
Modify exit processing such that we handle events with timeliness
constraints on them, bringing them into line with normal processing.
This allows events which are triggered from our existing workers events
to run to completion and allow completion of those workers. This allows
us to flush the queue and exit cleanly.
BugLink: http://bugs.launchpad.net/bugs/842560
Signed-off-by: Andy Whitcroft <apw@canonical.com>
---
udev/udevd.c | 39 ++++++++++++++++++++++++++++-----------
1 files changed, 28 insertions(+), 11 deletions(-)
This bug is triggered on some machines we have with two bnx2 network
interfaces each of which needs two firmware blobs loading. If we find the
root disks in the middle we request udev exit so we can transition to the
version in the real root. This request deadlocks resulting in a timeout.
The firmware never gets loaded for the second card and manual intervention
is required to recover the card.
It should also be noted that this change does slightly exacerbate what I
believe is an existing bug in the timeout handling. We essentially reset
the pending timout to the maximum every time we handle any incoming event,
for example when a worker completes. This does render the exact timeout
somewhat hard to predict, before and after this change.
diff --git a/udev/udevd.c b/udev/udevd.c
index 05d4b2d..19f7128 100644
--- a/udev/udevd.c
+++ b/udev/udevd.c
@@ -584,7 +584,7 @@ static void event_queue_start(struct udev *udev)
}
}
-static void event_queue_cleanup(struct udev *udev, enum event_state match_type)
+static void __event_queue_cleanup(struct udev *udev, enum event_state match_type, bool keep_timely)
{
struct udev_list_node *loop, *tmp;
@@ -594,10 +594,25 @@ static void event_queue_cleanup(struct udev *udev, enum event_state match_type)
if (match_type != EVENT_UNDEF && match_type != event->state)
continue;
+ /* Keep events which have timelyness requirements
+ * we will skew these timeouts on coldplug. */
+ if (keep_timely && udev_device_get_timeout(event->dev) > 0)
+ continue;
+
event_queue_delete(event, false);
}
}
+static void event_queue_cleanup(struct udev *udev, enum event_state match_type)
+{
+ __event_queue_cleanup(udev, match_type, false);
+}
+
+static void event_queue_cleanup_nontimely(struct udev *udev, enum event_state match_type)
+{
+ __event_queue_cleanup(udev, match_type, true);
+}
+
static void worker_returned(int fd_worker)
{
for (;;) {
@@ -1580,24 +1595,21 @@ int main(int argc, char *argv[])
int i;
if (udev_exit) {
- /* close sources of new events and discard buffered events */
+ /* close sources of new events and discard buffered events,
+ * keep the kernel channel so we can pick out events with a
+ * timeliness requirement to avoid deadlock. */
if (fd_ctrl >= 0) {
epoll_ctl(fd_ep, EPOLL_CTL_DEL, fd_ctrl, NULL);
fd_ctrl = -1;
}
- if (monitor != NULL) {
- epoll_ctl(fd_ep, EPOLL_CTL_DEL, fd_netlink, NULL);
- udev_monitor_unref(monitor);
- monitor = NULL;
- }
if (fd_inotify >= 0) {
epoll_ctl(fd_ep, EPOLL_CTL_DEL, fd_inotify, NULL);
close(fd_inotify);
fd_inotify = -1;
}
- /* discard queued events and kill workers */
- event_queue_cleanup(udev, EVENT_QUEUED);
+ /* discard queued non-timely events and kill workers */
+ event_queue_cleanup_nontimely(udev, EVENT_QUEUED);
worker_kill(udev, 0);
/* exit after all has cleaned up */
@@ -1649,8 +1661,13 @@ int main(int argc, char *argv[])
dev = udev_monitor_receive_device(monitor);
if (dev != NULL) {
- udev_device_set_usec_initialized(dev, now_usec());
- if (event_queue_insert(dev) < 0)
+ /* If we are exiting then only schedule events with
+ * timeliness requirements. */
+ if (!udev_exit || udev_device_get_timeout(dev) > 0) {
+ udev_device_set_usec_initialized(dev, now_usec());
+ if (event_queue_insert(dev) < 0)
+ udev_device_unref(dev);
+ } else
udev_device_unref(dev);
}
}
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH 1/1] udevd: process events with timeliness requirements
From: Greg KH @ 2011-12-16 17:53 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1324056944-4777-1-git-send-email-apw@canonical.com>
On Fri, Dec 16, 2011 at 05:35:44PM +0000, Andy Whitcroft wrote:
> diff --git a/udev/udevd.c b/udev/udevd.c
> index 05d4b2d..19f7128 100644
> --- a/udev/udevd.c
> +++ b/udev/udevd.c
> @@ -584,7 +584,7 @@ static void event_queue_start(struct udev *udev)
> }
> }
>
> -static void event_queue_cleanup(struct udev *udev, enum event_state match_type)
> +static void __event_queue_cleanup(struct udev *udev, enum event_state match_type, bool keep_timely)
> {
> struct udev_list_node *loop, *tmp;
>
> @@ -594,10 +594,25 @@ static void event_queue_cleanup(struct udev *udev, enum event_state match_type)
> if (match_type != EVENT_UNDEF && match_type != event->state)
> continue;
>
> + /* Keep events which have timelyness requirements
> + * we will skew these timeouts on coldplug. */
> + if (keep_timely && udev_device_get_timeout(event->dev) > 0)
> + continue;
> +
Your patch is totally corrupted :(
^ permalink raw reply
* Re: [RESEND PATCH 1/1] udevd: process events with timeliness
From: Kay Sievers @ 2011-12-17 18:15 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1324057580-4960-1-git-send-email-apw@canonical.com>
On Fri, Dec 16, 2011 at 18:46, Andy Whitcroft <apw@canonical.com> wrote:
> In exit (udevadm control --exit) processing we currently dump the entire
> incoming queue and ignore any further incoming kernel events. We then wait
> for the current workers to complete any events they were assigned, before
> finally exiting. However if any of the pending events should trigger a
> nested event that new event would not be processed preventing completion
> of the existing worker event. We will eventually timeout both leading
> to a long boot delay and in some cases to partially initialised cards.
> These cards often will not be repaired even during coldplug and are lost
> requiring manual intervention to recover.
>
> Modify exit processing such that we handle events with timeliness
> constraints on them, bringing them into line with normal processing.
> This allows events which are triggered from our existing workers events
> to run to completion and allow completion of those workers. This allows
> us to flush the queue and exit cleanly.
Is 'udevadm settle' called before doing --exit in the initramfs? If
not, I guess that's why others have not seen that.
In general, requesting firmware synchronously on module init sounds
pretty broken. The firmware request should be async. If the device
allow that, done as late as the first ifup of the netdev, and not at
module load time.
If udev is not running, modprobe will hang until it runs into the
timeout? Having module init depending on a 'userspace transaction'
sounds pretty weird. How does that work when the module is
compiled-in?
The TIMEOUT= is basically just a left-over from the times of the crazy
/sbin/hotplug era, where all the hooked-in shell scripts took ages to
handle events, and the kernel's firmware loaders default was 10
seconds, and it ran into that all the time.
The patch looks sensible, but I haven't really wrapped my head around
if we really should make the TIMEOUT= handling even more special here.
I rather see the firmware loading model fixed for the affected
drivers, as I think it is very wrong, for many other reasons too, what
they do here.
Thanks,
Kay
^ permalink raw reply
* Re: [RESEND PATCH 1/1] udevd: process events with timeliness
From: Andy Whitcroft @ 2011-12-20 13:31 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1324057580-4960-1-git-send-email-apw@canonical.com>
On Sat, Dec 17, 2011 at 07:15:00PM +0100, Kay Sievers wrote:
> On Fri, Dec 16, 2011 at 18:46, Andy Whitcroft <apw@canonical.com> wrote:
> > In exit (udevadm control --exit) processing we currently dump the entire
> > incoming queue and ignore any further incoming kernel events. We then wait
> > for the current workers to complete any events they were assigned, before
> > finally exiting. However if any of the pending events should trigger a
> > nested event that new event would not be processed preventing completion
> > of the existing worker event. We will eventually timeout both leading
> > to a long boot delay and in some cases to partially initialised cards.
> > These cards often will not be repaired even during coldplug and are lost
> > requiring manual intervention to recover.
> >
> > Modify exit processing such that we handle events with timeliness
> > constraints on them, bringing them into line with normal processing.
> > This allows events which are triggered from our existing workers events
> > to run to completion and allow completion of those workers. This allows
> > us to flush the queue and exit cleanly.
>
> Is 'udevadm settle' called before doing --exit in the initramfs? If
> not, I guess that's why others have not seen that.
No we wish to avoid 'settle'ing as that would force us to wait for the
majority of device probes to complete, and we do not have the majority
of the modules in the initramfs to service them.
> In general, requesting firmware synchronously on module init sounds
> pretty broken. The firmware request should be async. If the device
> allow that, done as late as the first ifup of the netdev, and not at
> module load time.
I will agree that the right thing is to fix the kernel drivers overall.
I have looked at a few and all of the ones I have looked at seem to follow
this model, so I suspect this is not going to be a quick fix.
> If udev is not running, modprobe will hang until it runs into the
> timeout? Having module init depending on a 'userspace transaction'
> sounds pretty weird. How does that work when the module is
> compiled-in?
If udev is not running we will not trigger any modprobes in response to
the device discovery events and so cannot trigger firmware loads during
that time. If the module is built-in then we will trigger the firmware
load event, and either udev is there to service it or it is lost.
However the firmware object is coldplug-able so when udev is finally
(re)started we will replay the firmware event and expedite the firmware
load as it has timeliness set. It is only the period when we udev is
exiting that we can be running a modprobe but not willing to handle the
event (without this patch).
> The TIMEOUT= is basically just a left-over from the times of the crazy
> /sbin/hotplug era, where all the hooked-in shell scripts took ages to
> handle events, and the kernel's firmware loaders default was 10
> seconds, and it ran into that all the time.
>
> The patch looks sensible, but I haven't really wrapped my head around
> if we really should make the TIMEOUT= handling even more special here.
> I rather see the firmware loading model fixed for the affected
> drivers, as I think it is very wrong, for many other reasons too, what
> they do here.
I believe that the change makes TIMEOUT= handline consistantly special,
ie. it always triggers expedited handling regardless of whether we are
running normally or in the process of exiting. Plus, by handling these
events we can avoid deadlocking the modprobe for these bad drivers.
-apw
^ permalink raw reply
* Re: [RESEND PATCH 1/1] udevd: process events with timeliness
From: Kay Sievers @ 2011-12-20 13:44 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1324057580-4960-1-git-send-email-apw@canonical.com>
On Tue, Dec 20, 2011 at 14:31, Andy Whitcroft <apw@canonical.com> wrote:
> On Sat, Dec 17, 2011 at 07:15:00PM +0100, Kay Sievers wrote:
>> On Fri, Dec 16, 2011 at 18:46, Andy Whitcroft <apw@canonical.com> wrote:
>> > In exit (udevadm control --exit) processing we currently dump the entire
>> > incoming queue and ignore any further incoming kernel events. We then wait
>> > for the current workers to complete any events they were assigned, before
>> > finally exiting. However if any of the pending events should trigger a
>> > nested event that new event would not be processed preventing completion
>> > of the existing worker event. We will eventually timeout both leading
>> > to a long boot delay and in some cases to partially initialised cards.
>> > These cards often will not be repaired even during coldplug and are lost
>> > requiring manual intervention to recover.
>> >
>> > Modify exit processing such that we handle events with timeliness
>> > constraints on them, bringing them into line with normal processing.
>> > This allows events which are triggered from our existing workers events
>> > to run to completion and allow completion of those workers. This allows
>> > us to flush the queue and exit cleanly.
>>
>> Is 'udevadm settle' called before doing --exit in the initramfs? If
>> not, I guess that's why others have not seen that.
>
> No we wish to avoid 'settle'ing as that would force us to wait for the
> majority of device probes to complete, and we do not have the majority
> of the modules in the initramfs to service them.
What does that mean? You wait for exactly what you yourself have
triggered in the initramfs, not for anything unrelated or not loaded.
And that's very likely the right thing to do. There are usually no
other event pending at that point in time, unless you need to work
around some other kernel bug here. :)
Kay
^ permalink raw reply
* Re: [RESEND PATCH 1/1] udevd: process events with timeliness
From: Kay Sievers @ 2011-12-20 13:58 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1324057580-4960-1-git-send-email-apw@canonical.com>
On Tue, Dec 20, 2011 at 14:31, Andy Whitcroft <apw@canonical.com> wrote:
> On Sat, Dec 17, 2011 at 07:15:00PM +0100, Kay Sievers wrote:
>> The patch looks sensible, but I haven't really wrapped my head around
>> if we really should make the TIMEOUT= handling even more special here.
>> I rather see the firmware loading model fixed for the affected
>> drivers, as I think it is very wrong, for many other reasons too, what
>> they do here.
>
> I believe that the change makes TIMEOUT= handline consistantly special,
> ie. it always triggers expedited handling regardless of whether we are
> running normally or in the process of exiting. Â Plus, by handling these
> events we can avoid deadlocking the modprobe for these bad drivers.
As mentioned earlier, at this point, I rather remove the entire
TIMEOUT handling from udev to reach consistency, than make it even
more special. It's not a proper facility, it's a left-over from the
time the entire hotplug stuff was not working at all.
There are no guarantees that asynchronous events will ever be handled
in a certain time frame. Everything should have a timeout, and we
should handle that as good as we can, but we need to avoid synchronous
kernel dependencies on userspace. And kernel drivers should not get
away these days with dirty hacks like this.
Since a while we refuse to work around such broken kernel behaviour in
userspace, for the reason to put the blame and focus where it belongs:
at the bug and not at the workaround. And what you analysed here is a
kernel bug, not a userspace one.
And I still think that depending on a userspace transaction in module
init is just terribly broken. If udev is not running properly,
modprobe will just hang until a timeout is reached, and that is just
not how things should work. I think, that supporting event
inter-dependencies that way just asks for trouble in the long run.
Kay
^ permalink raw reply
* [PATCH 1/2] man: Spelling fix.
From: Ville Skyttä @ 2011-12-20 22:38 UTC (permalink / raw)
To: linux-hotplug
---
udev/udevadm.xml | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/udev/udevadm.xml b/udev/udevadm.xml
index 2fdbb42..09c22c4 100644
--- a/udev/udevadm.xml
+++ b/udev/udevadm.xml
@@ -363,7 +363,7 @@
<varlistentry>
<term><option>--timeout=</option><replaceable>seconds</replaceable></term>
<listitem>
- <para>The maximum number seonds to wait for a reply from udevd.</para>
+ <para>The maximum number seconds to wait for a reply from udevd.</para>
</listitem>
</varlistentry>
<varlistentry>
--
1.7.7.4
^ permalink raw reply related
* [PATCH 2/2] man: Fix udevadm test --action default value.
From: Ville Skyttä @ 2011-12-20 22:38 UTC (permalink / raw)
To: linux-hotplug
---
udev/udevadm.xml | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/udev/udevadm.xml b/udev/udevadm.xml
index 09c22c4..a1028ee 100644
--- a/udev/udevadm.xml
+++ b/udev/udevadm.xml
@@ -199,7 +199,7 @@
<varlistentry>
<term><option>--action=<replaceable>action</replaceable></option></term>
<listitem>
- <para>Type of event to be triggered. The default value is <command>change</command>.</para>
+ <para>Type of event to be triggered. The default value is <command>add</command>.</para>
</listitem>
</varlistentry>
<varlistentry>
--
1.7.7.4
^ permalink raw reply related
* Re: [PATCH 2/2] man: Fix udevadm test --action default value.
From: Kay Sievers @ 2011-12-20 22:48 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1324420719-23114-2-git-send-email-ville.skytta@iki.fi>
On Tue, Dec 20, 2011 at 23:38, Ville Skyttä <ville.skytta@iki.fi> wrote:
> ---
> udev/udevadm.xml | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/udev/udevadm.xml b/udev/udevadm.xml
> index 09c22c4..a1028ee 100644
> --- a/udev/udevadm.xml
> +++ b/udev/udevadm.xml
> @@ -199,7 +199,7 @@
> <varlistentry>
> <term><option>--action=<replaceable>action</replaceable></option></term>
> <listitem>
> - <para>Type of event to be triggered. The default value is <command>change</command>.</para>
> + <para>Type of event to be triggered. The default value is <command>add</command>.</para>
?
# strace -e write udevadm trigger --subsystem-match=mem --sysname-match=null
write(3, "change", 6) = 6
Kay
^ permalink raw reply
* Re: [PATCH 1/2] man: Spelling fix.
From: Kay Sievers @ 2011-12-20 22:50 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1324420719-23114-1-git-send-email-ville.skytta@iki.fi>
On Tue, Dec 20, 2011 at 23:38, Ville Skyttä <ville.skytta@iki.fi> wrote:
> ---
> udev/udevadm.xml | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Applied.
Thanks,
Kay
^ permalink raw reply
* Re: [PATCH 2/2] man: Fix udevadm test --action default value.
From: Ville Skyttä @ 2011-12-20 23:06 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <1324420719-23114-2-git-send-email-ville.skytta@iki.fi>
On 2011-12-21 00:48, Kay Sievers wrote:
> On Tue, Dec 20, 2011 at 23:38, Ville Skyttä <ville.skytta@iki.fi> wrote:
>> ---
>> udev/udevadm.xml | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/udev/udevadm.xml b/udev/udevadm.xml
>> index 09c22c4..a1028ee 100644
>> --- a/udev/udevadm.xml
>> +++ b/udev/udevadm.xml
>> @@ -199,7 +199,7 @@
>> <varlistentry>
>> <term><option>--action=<replaceable>action</replaceable></option></term>
>> <listitem>
>> - <para>Type of event to be triggered. The default value is <command>change</command>.</para>
>> + <para>Type of event to be triggered. The default value is <command>add</command>.</para>
>
> ?
>
> # strace -e write udevadm trigger --subsystem-match=mem --sysname-match=null
> write(3, "change", 6) = 6
Oops, I intended to fix the default value of "test" (as the subject
says), not "trigger", but ended up modifying/breaking the latter as the
former's default is not documented and I hit the wrong entry in the xml.
Thanks for catching it.
--
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
* SYMLINK assignment in udev rules file
From: jacky.fong @ 2011-12-21 18:47 UTC (permalink / raw)
To: linux-hotplug
Hi,
I need some help with udev rule writing. I am having difficulty
understanding the description for the SYMLINK assignment key
(http://manpages.ubuntu.com/manpages/oneiric/man7/udev.7.html). The
manpage
says,
"In case multiple devices claim the same name, the link always
points to the device with the highest link_priority."
How can you have multiple devices that claim the same name? It is said
in the description section of the manpage that "the kernel usually
just assigns unpredictable device names based on the order of
discovery." E.g. sda, sdb,...
The only situation I could think of where multiple devices claiming
the same name is when the user decides to do NAME="sda", which is not
recommended, as noted in the manpage.
Btw, none of the device file nodes are created in the filesystem
(/dev) at this
point right? Since filenames must be unique under a directory, I just
don't see the case where "multiple devices claim the same name".
Thanks,
Jacky
^ permalink raw reply
* vconsole.conf question
From: Allin Cottrell @ 2011-12-21 18:50 UTC (permalink / raw)
To: linux-hotplug
I have no need of switching from the default kernel console
font to latarcyrheb-sun16 on boot-up. Is there a way to
indicate "leave well alone" in /etc/vconsole.conf? Like
perhaps
FONT
or
FONT=""
Thanks.
--
Allin Cottrell
Department of Economics
Wake Forest University, NC
^ permalink raw reply
* Re: vconsole.conf question
From: Allin Cottrell @ 2011-12-22 18:06 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <alpine.LNX.2.00.1112211346550.468@waverley.dhcp.wfu.edu>
On Wed, 21 Dec 2011, Allin Cottrell wrote:
> I have no need of switching from the default kernel console font to
> latarcyrheb-sun16 on boot-up. Is there a way to indicate "leave well alone"
> in /etc/vconsole.conf? Like perhaps
>
> FONT
Just for the record: the above seems to work, to prevent
systemd-vconsole-setup from trying to switch fonts. It might
be helpful to mention this in the manpage for vconsole.conf.
Allin Cottrell
^ permalink raw reply
* [PATCH[ udev: ata_id: Fix length of INQUIRY command
From: Alan Stern @ 2011-12-22 21:12 UTC (permalink / raw)
To: linux-hotplug
SCSI INQUIRY commands are 6 bytes long, not 12 bytes.
Index: udev-173/extras/ata_id/ata_id.c
=================================--- udev-173.orig/extras/ata_id/ata_id.c
+++ udev-173/extras/ata_id/ata_id.c
@@ -52,7 +52,7 @@ static int disk_scsi_inquiry_command(int
size_t buf_len)
{
struct sg_io_v4 io_v4;
- uint8_t cdb[12];
+ uint8_t cdb[6];
uint8_t sense[32];
int ret;
^ permalink raw reply
* Re: [PATCH[ udev: ata_id: Fix length of INQUIRY command
From: Kay Sievers @ 2011-12-22 23:35 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <Pine.LNX.4.44L0.1112221606580.2275-100000@netrider.rowland.org>
On Thu, Dec 22, 2011 at 22:12, Alan Stern <stern@rowland.harvard.edu> wrote:
> SCSI INQUIRY commands are 6 bytes long, not 12 bytes.
Applied.
Thanks,
Kay
^ permalink raw reply
* Trying to determine if udev can be used to manage network interfaces.
From: James Ronald @ 2011-12-29 21:06 UTC (permalink / raw)
To: linux-hotplug
I'm trying to determine if udev can be used to manage the insertion
and removal an active network connection rather than using ifplugd or
such.
The board is currently running Linux 3.1 and I have verified Linux
config options per the udev README file.
"udevadm monitor" shows no uevents when the cable is inserted and
removed. Is there sometime that needs to be enabled?
"udevadm info -a -p /sys/class/net/eth0" shows the following with
values for carrier, operstate and such changing appropriately.
looking at device '/devices/platform/mv643xx_eth_port.0/net/eth0':
KERNEL="eth0"
SUBSYSTEM="net"
DRIVER=""
ATTR{addr_assign_type}="0"
ATTR{addr_len}="6"
ATTR{dev_id}="0x0"
ATTR{ifalias}=""
ATTR{iflink}="2"
ATTR{ifindex}="2"
ATTR{type}="1"
ATTR{link_mode}="0"
ATTR{address}="00:04:d1:0b:00:2c"
ATTR{broadcast}="ff:ff:ff:ff:ff:ff"
ATTR{carrier}="1"
ATTR{speed}="1000"
ATTR{duplex}="full"
ATTR{dormant}="0"
ATTR{operstate}="up"
ATTR{mtu}="1500"
ATTR{flags}="0x1003"
ATTR{tx_queue_len}="1000"
ATTR{netdev_group}="0"
looking at parent device '/devices/platform/mv643xx_eth_port.0':
KERNELS="mv643xx_eth_port.0"
SUBSYSTEMS="platform"
DRIVERS="mv643xx_eth_port"
looking at parent device '/devices/platform':
KERNELS="platform"
SUBSYSTEMS=""
DRIVERS=""
----------------------------------------------------------------
Best regards.
James Ronald - Sr. Linux Developer/Software Engineer
^ permalink raw reply
* Re: Trying to determine if udev can be used to manage network interfaces.
From: Kay Sievers @ 2011-12-30 20:52 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CAJODoNSnqnGwEff6HDdc8naoxtYZnqTB_n4Jos-c3E1upf6n+g@mail.gmail.com>
On Thu, Dec 29, 2011 at 22:06, James Ronald <james.ronald@gmail.com> wrote:
> I'm trying to determine if udev can be used to manage the insertion
> and removal an active network connection rather than using ifplugd or
> such.
>
> The board is currently running Linux 3.1 and I have verified Linux
> config options per the udev README file.
>
> "udevadm monitor" shows no uevents when the cable is inserted and
> removed. Â Is there sometime that needs to be enabled?
Udev does not and probably never will monitor the netif link state.
You need a service running that talks netlink to the kernel's network
stack, udev can not really help here.
Kay
^ permalink raw reply
* Minimum kernel version requirement
From: Tom Gundersen @ 2012-01-01 15:13 UTC (permalink / raw)
To: linux-hotplug
Hi guys,
In Arch (and, as far as I understand, also in Debian) we are
interested in making the latest udev work with the latest LTS kernel
(currently 2.6.32.51). However, the minimum requirement in udev's
README is currently listed as 2.6.34 (bumped from .32 last year). On
IRC Kay mentioned that the reason for this is some bugs in devtmpfs in
2.6.32.y. Could anyone provide any more details on what fixes are
missing?
As far as I can tell, the devtmpfs related patches included in .34.y
and not in .32.y are:
commit 015bf43b07158668c2f38af463939afcc6d19403
Author: Kay Sievers <kay.sievers@vrfy.org>
Date: Wed Oct 28 19:51:26 2009 +0100
Driver Core: devtmpfs: do not remove non-kernel-created directories
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 073120cc28ad9f6003452c8bb9d15a87b1820201
Author: Kay Sievers <kay.sievers@vrfy.org>
Date: Wed Oct 28 19:51:17 2009 +0100
Driver Core: devtmpfs: use sys_mount()
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit ed413ae6e7813d3227eef43bc6d84ca4f4fe6b21
Author: Kay Sievers <kay.sievers@vrfy.org>
Date: Wed Oct 28 19:51:06 2009 +0100
Driver core: devtmpfs: prevent concurrent subdirectory creation and removal
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 0092699643703aefca6af0aa758a73f1624d53be
Author: Kay Sievers <kay.sievers@vrfy.org>
Date: Wed Oct 28 19:50:57 2009 +0100
Driver Core: devtmpfs: ignore umask while setting file mode
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Are there any reasons why the relevant fixes are not in 2.6.32.y? Are
there any other reasons to keep the minimum requirement at .34?
I'd be happy to push some patches to Greg for inclusion in LTS if that
is all that is missing for udev to support .32.
Cheers,
Tom
^ permalink raw reply
* Re: Minimum kernel version requirement
From: Kay Sievers @ 2012-01-01 15:47 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CAG-2HqWXyMz6SSsQSv70DO=AKaPgAhxD+JWD5tDE8ZBKymGM2A@mail.gmail.com>
On Sun, Jan 1, 2012 at 16:13, Tom Gundersen <teg@jklm.no> wrote:
> In Arch (and, as far as I understand, also in Debian) we are
> interested in making the latest udev work with the latest LTS kernel
> (currently 2.6.32.51). However, the minimum requirement in udev's
> README is currently listed as 2.6.34 (bumped from .32 last year). On
> IRC Kay mentioned that the reason for this is some bugs in devtmpfs in
> 2.6.32.y. Could anyone provide any more details on what fixes are
> missing?
The bump has no hard dependency. It's devtmpfs in general which got
fixes, the 'devname' static module-load stuff, things like the
in-kernel media-presence polling which udev manages, and some
architectures which have broken syscall implementations which only got
fixed later in .34.
Only the broken syscall stuff will prevent udev from brining up these
old kernels, the rest will only cause some minor details not to work
as expected, but I guess, it's all that can be worked around.
You can only find out yourself, by testing it. I have no good idea
what in detail works and what not, because I never run 2+ years old
kernels on latest userspace. We all only support running new kernels
on old distros and not really the other way around.
I really think old distros should just update the kernel too, it is
much easier than upgrading individual components. Or if that is not
possible, check if the versions in the enterprise distros of these
tools match; these are well supported old versions of these
components. Trying to mix base system tools and hope they work, while
they are years apart from each other, putting then on top of old
kernels doesn't sound like the best idea.
Linux is really under heavy development in this area, and it's still
ongoing, and changes are pretty hard to track over years.
Kay
^ permalink raw reply
* Re: Minimum kernel version requirement
From: Tom Gundersen @ 2012-01-01 17:28 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <CAG-2HqWXyMz6SSsQSv70DO=AKaPgAhxD+JWD5tDE8ZBKymGM2A@mail.gmail.com>
On Sun, Jan 1, 2012 at 4:47 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
> The bump has no hard dependency. It's devtmpfs in general which got
> fixes, the 'devname' static module-load stuff, things like the
> in-kernel media-presence polling which udev manages, and some
> architectures which have broken syscall implementations which only got
> fixed later in .34.
>
> Only the broken syscall stuff will prevent udev from brining up these
> old kernels, the rest will only cause some minor details not to work
> as expected, but I guess, it's all that can be worked around.
Thanks for the explanation, now I have a better idea. I was aware of
the devname and media-presence stuff, but didn't think that was
relevant since it arrived post-.34 and can be worked around using
custom rules and static nodes. That custom rules might be needed on
old kernel is already clear from the README so that's fine.
If I understand you correctly, I think the README should be reverted to say
"Requirements:
- Version 2.6.32 of the Linux kernel [...]"
The broken syscalls on pre-.34 kernels on some architectures is
already mentioned explicitly:
"- Some architectures might need a later kernel, that supports accept4(),
or need to backport the accept4() syscall wiring in the kernel."
I agree that it would be best to drop old kernels, but as long as
people would like to try I guess that's up to them.
Cheers,
Tom
^ 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