Deprecating old networking protocols
The kernel has seen an uptick in testing from fuzzers lately. This has been great for the kernel as its exposed a number of bugs. See https://googleprojectzero.blogspot.com/2017/05/exploiting-linux-kernel-via-packet.html as an example. Part of this has also shown what areas of the kernel are undermaintained. One of those areas is older networking protocols. Maintainers have started pushing patches to deprecate some of these https://marc.info/?l=linux-netdev&m=151067745601327&w=2 https://marc.info/?l=linux-netdev&m=151060836604824&w=2 As the upstream kernel starts to deprecate these, Fedora is going to follow suit as well. My plan is to turn off options that are going to be deprecated. I already turned off DCCP in rawhide based on some other conversations. As always, your feedback is important here. Nobody is quite sure how much these protocols are being used so if you have use cases, please let us know. Thanks, Laura ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Re: Enabling btusb autosuspend by default
On Tue, Nov 14, 2017 at 7:49 AM, Justin Forbes wrote: > On Mon, Nov 13, 2017 at 10:16 AM, Chris Murphy > wrote: >> Some tips on how regressions might manifest and what information to >> include in a good bug report would be useful. e.g. on an Intel NUC >> when I run powertop --auto-tune, and walk away (it's a server so it >> might be days) and come back the keyboard won't work. I've never done >> any troubleshooting other than just disable the powertop systemd unit, >> I'm vaguely suspicious of usb autosuspend and it not waking up when >> keys are pressed. >> > > Auto suspend can be a real problem when it is keyboards and mice. I > know there was a huge uproar with logitech unified receiver users when > powertop would change the receiver to autosuspend and the > keyboard/mouse became unresponsive for a couple of key presses. To be > honest, I think this particular change may do much more harm than > good. > I find it ironic that this misbehaving hardware is Intel's USB stuff, in their NUC, and powertop is an Intel managed project. I'd guess the powertop folks would already know better than to apply autosuspend to Intel USB hardware. -- Chris Murphy ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Re: Enabling btusb autosuspend by default
- Original Message - > Auto suspend can be a real problem when it is keyboards and mice. I > know there was a huge uproar with logitech unified receiver users when > powertop would change the receiver to autosuspend and the > keyboard/mouse became unresponsive for a couple of key presses. To be > honest, I think this particular change may do much more harm than > good. At least it's implemented in such a way that it makes it straight forward to test for, as opposed to hunting down files in multiple subdirectories in sysfs. If we get too many broken devices to list, then it's a one-liner to disable it in the kernel build, and we still end up having a nice easy way for users to test devices which we'd add to a whitelist in user-space. ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Re: Enabling btusb autosuspend by default
On Mon, Nov 13, 2017 at 10:16 AM, Chris Murphy wrote: > On Mon, Nov 13, 2017 at 8:40 AM, Hans de Goede wrote: >> Hi all, >> >> As mentioned before I'm working on trying to improve the OOTB >> power-consumption of Fedora Workstation on laptops >> (I need to create an F28 feature page for this). >> >> On many laptops the btusb device is the only USB device not >> having USB autosuspend enabled, this causes not only the btusb >> device but also the USB controller to stay awake, together using >> aprox. 0.4W of power. Modern ultrabooks idle around 6W >> (at 50% screen brightness), 3.5W for Apollo Lake devices. >> 0.4W is a significant chunk of this (7 / 11%). >> >> So I would like to enable btusb autosuspend by default, to >> make this possible I've submitted the following kernel >> patch upstream which has just been merged (queued for 4.16): >> https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=86be3c232877b59f08561b256ff7e73ad39b0785 >> >> If it is ok with the Fedora kernel team I would like to add >> this as a patch to the Fedora kernels for now and set >> the new BT_HCIBTUSB_AUTOSUSPEND option to y. This is not >> without a risk of regressions, so this is something for >> rawhide/F28 only. > > > This is really useful work. I'm already seeing ~20% battery > improvement with Fedora 27 + 4.14.0-0.rc8.git3.1.fc28.x86_64 on an HP > Spectre, and so far no regressions. I get better battery life with > this combination than running Windows 10 with all the HP specific > drivers for this model. > > Some tips on how regressions might manifest and what information to > include in a good bug report would be useful. e.g. on an Intel NUC > when I run powertop --auto-tune, and walk away (it's a server so it > might be days) and come back the keyboard won't work. I've never done > any troubleshooting other than just disable the powertop systemd unit, > I'm vaguely suspicious of usb autosuspend and it not waking up when > keys are pressed. > Auto suspend can be a real problem when it is keyboards and mice. I know there was a huge uproar with logitech unified receiver users when powertop would change the receiver to autosuspend and the keyboard/mouse became unresponsive for a couple of key presses. To be honest, I think this particular change may do much more harm than good. Justin ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Re: Enabling btusb autosuspend by default
Am 14.11.2017 um 12:33 schrieb Reindl Harald: Am 14.11.2017 um 12:22 schrieb Gerd Hoffmann: This is really useful work. I'm already seeing ~20% battery improvement with Fedora 27 + 4.14.0-0.rc8.git3.1.fc28.x86_64 on an HP Spectre, and so far no regressions. I get better battery life with this combination than running Windows 10 with all the HP specific drivers for this model. Some tips on how regressions might manifest and what information to include in a good bug report would be useful. e.g. on an Intel NUC when I run powertop --auto-tune, and walk away (it's a server so it might be days) and come back the keyboard won't work. I've never done any troubleshooting other than just disable the powertop systemd unit, I'm vaguely suspicious of usb autosuspend and it not waking up when keys are pressed. autosuspend has a high chance to be the root cause for this one. Yes, its very messy, mostly due to bad hardware similar is happening on my homemachine with the mouse for years now, i just need to switch to a VT instead the graphical login/desktop and every few seconds the kernel pretends that the device got disconnected and connected again spitting dmesg and the current VT full so that it becomes practically unuseable forgot to say: this is a ordinary USB mouse and AFAIK no autosuspned enabled because when i enable that the keyboard is gone anyways and you can shutdown with the power button ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Re: Enabling btusb autosuspend by default
Am 14.11.2017 um 12:22 schrieb Gerd Hoffmann: This is really useful work. I'm already seeing ~20% battery improvement with Fedora 27 + 4.14.0-0.rc8.git3.1.fc28.x86_64 on an HP Spectre, and so far no regressions. I get better battery life with this combination than running Windows 10 with all the HP specific drivers for this model. Some tips on how regressions might manifest and what information to include in a good bug report would be useful. e.g. on an Intel NUC when I run powertop --auto-tune, and walk away (it's a server so it might be days) and come back the keyboard won't work. I've never done any troubleshooting other than just disable the powertop systemd unit, I'm vaguely suspicious of usb autosuspend and it not waking up when keys are pressed. autosuspend has a high chance to be the root cause for this one. Yes, its very messy, mostly due to bad hardware similar is happening on my homemachine with the mouse for years now, i just need to switch to a VT instead the graphical login/desktop and every few seconds the kernel pretends that the device got disconnected and connected again spitting dmesg and the current VT full so that it becomes practically unuseable ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Re: Enabling btusb autosuspend by default
Hi, > This is really useful work. I'm already seeing ~20% battery > improvement with Fedora 27 + 4.14.0-0.rc8.git3.1.fc28.x86_64 on an HP > Spectre, and so far no regressions. I get better battery life with > this combination than running Windows 10 with all the HP specific > drivers for this model. > > Some tips on how regressions might manifest and what information to > include in a good bug report would be useful. e.g. on an Intel NUC > when I run powertop --auto-tune, and walk away (it's a server so it > might be days) and come back the keyboard won't work. I've never done > any troubleshooting other than just disable the powertop systemd unit, > I'm vaguely suspicious of usb autosuspend and it not waking up when > keys are pressed. autosuspend has a high chance to be the root cause for this one. Yes, its very messy, mostly due to bad hardware. In qemu it took us quite some effort to get autosuspend working. It's very useful there too, usb hostadapter power consumtion on a laptop translates to cpu cycles for usb hostadapter emulation for a virtual machine. The fundamental problem is that hardware exists claiming to support autosuspend, but it's not working properly. Effect is exactly what you see: device stops working. Result is that operating systems don't enable autosuspend by default, to avoid disturbing users. udev has a whitelist of known-good hid devices (/lib/udev/rules.d/42-usb-hid-pm.rules) to deal with that. qemu hid devices are listed there, that way qemu has automatic autosuspend for linux guests. Microsoft created some "os-specific" usb descriptors which devices can define. One of the things you can do with that is set registry entries for the device. Qemu uses that to automatically enable autosuspend on windows guests, by setting SelectiveSuspendEnabled to 1. Microsoft specs: https://msdn.microsoft.com/en-us/library/windows/hardware/ff537430.aspx Qemu code: https://git.qemu.org/?p=qemu.git;a=blob;f=hw/usb/desc-msos.c;h=3652919815777d637ed4f716772f9c1ce2d0b819;hb=HEAD Possibly this can be used on linux too, to figure which devices are known-good, without having to maintain a whitelist ... cheers, Gerd ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
