5166 2013-09-11 19:09:09 +0000 nuc: mouse is getting disabled after few seconds of inactivity 2013-09-18 15:11:27 +0000 1 1 7 Build System, Metadata & Runtime BSPs bsps-meta-intel 1.5 x86 Multiple RESOLVED FIXED Medium normal 1.5 M5 1 nitin.a.kamble nitin.a.kamble bruce.ashfield dvhart richard.purdie ross.burton sgw tom.zanussi --- --- No (bug/feature does not impact docs) oldest_to_newest 36555 0 nitin.a.kamble 2013-09-11 19:09:09 +0000 keyboard use enables the mouse again, but it is a usability issue, which need to be addressed. a fix for similar issue went in v3.8 kernel. I believe that fix also got incorporated in the v3.10 kernel. I will double check it. 36556 1 nitin.a.kamble 2013-09-11 19:45:58 +0000 in the v3.10 kernel the usb autosuspend is on by default. It can be disabled by disabling CONFIG_PM_RUNTIME, but it is too big of a hammer for this task, it will disable dynamic suspend for all (non usb as well) devices. So the other ways to fix this issue 1. Pass this kernel parameter to each of the BSPs usb.autosuspend=-1 2. change the kernel code to disable USB autosuspend for all the BSPs drivers/usb/core/usb.c: usb_autosuspend_delay = -1; I think the 2nd way is better, but it still will ask for srcrev updates for all the BSP kernels. Nitin 36557 2 nitin.a.kamble 2013-09-11 19:58:05 +0000 yet another option is add this line to meta/recipes-kernel/linux/linux-yocto_3.10.bb from oecore. APPEND_append = " usb.autosuspend=-1" 36572 3 dvhart 2013-09-12 00:48:58 +0000 I prefer the kernel APPEND parameter over code changes. THe question is whether or not this is default policy. Given the number of failures we see with this, I suspect it should be. 36579 4 nitin.a.kamble 2013-09-12 05:15:05 +0000 Thanks Darren for the input. Now what location the APPEND var be placed? 1. it can go in meta/recipes-kernel/linux/linux-yocto_3.10.bb recipe itself, which will fix the issue for all the BSPs using YP 3.10 kernel. 2. or it can go in conf/machine/include/ia32-base.inc, which will fix all the Intel BSPs. 3. or add it to individual BSP v3.10 kernel bbappends. IMO in this case the option 1 makes most sense, but we will be affecting non-intel BSPs here. 36617 5 dvhart 2013-09-12 18:18:02 +0000 I agree, linux-yocto_3.10.bb is the best place given the number of times this failure has presented itself. 36621 6 tom.zanussi 2013-09-12 19:06:56 +0000 Just repeating what my input was on irc yesterday: (03:06:52 PM) tomz: nakamble: i don't think we want to force it on everyone (03:07:13 PM) nakamble: in fact this is a issue for any BSP (non intel also) with the v3.10 kernel (03:09:51 PM) nakamble: tomz: so what do you suggest? (03:10:18 PM) tomz: nakamble: well, if a company has a system that doesn't have broken hardware in their product (i'd guess most of the time they wouldn't be using broken hardware), they shouldn't be forced to remove something to get things to the default intended by the kernel, right? I can also see wanting to do it globally for everyone, but then why not send a patch to LKML to do that if it's really the right thing to do? 36622 7 nitin.a.kamble 2013-09-12 19:16:59 +0000 currently there is no mechanism, which will make the APPEND effective from linux-yocto_3.10.bb. The APPEND var is used by syslinux.bbclass & grub-efi.bbclass which is inherited by boot-directdisk.bbclass and it can be influenced only from global config files such as machine.conf. To influence all the BSPs there is no way other than adding the APPEND line to image.bbclass or global config file such as bitbake.conf . Which does not feel like right place to do this thing. With this situation, now we can either do it just for Intel BSPs, or change the kernel sources and update the kernel srcrevs for all the BSPs, or add one of the above global oecore locations. I also experimented disabling the USB autosuspend via udev rules, which technically should work, but I could not successfully do it yet. If there any more thought to help here, please share. Thanks, Nitin 36623 8 nitin.a.kamble 2013-09-12 19:24:48 +0000 (In reply to comment #6) > Just repeating what my input was on irc yesterday: > > (03:06:52 PM) tomz: nakamble: i don't think we want to force it on everyone > (03:07:13 PM) nakamble: in fact this is a issue for any BSP (non intel also) > with the v3.10 kernel > (03:09:51 PM) nakamble: tomz: so what do you suggest? > (03:10:18 PM) tomz: nakamble: well, if a company has a system that doesn't > have broken hardware in their product (i'd guess most of the time they > wouldn't be using broken hardware), they shouldn't be forced to remove > something to get things to the default intended by the kernel, right? > > I can also see wanting to do it globally for everyone, but then why not send > a patch to LKML to do that if it's really the right thing to do? Makes sense. then we will be backporting a patch to v3.10 tree. I discussed this issue with Sarah yesterday, She says even though USB autosuspend delay is set in the kernel, the power/control should be set to "on" for all non-hub usb devices. Which also disables the usb autosuspend. But I am finding that in our kernel all the USB devices have power/control set to "auto". She mentioned that udev rules of systemd may be turning it to "auto", which I did not find happening in our images. From all these discussions seems like a new udev rule will be right way to fix this issue. But my udev rules are not helping. Maybe someone who is a udev-fu master in can help here. 36624 9 tom.zanussi 2013-09-12 19:28:20 +0000 As I also mentioned yesterday in IRC: tomz: nakamble: in any case, i don't think the answer is to modify the code and obviously the mention of sending a patch to LKML was just making the same point that I think it's actually the WRONG thing to do. So yeah IMHO it should be a per-BSP policy. 36625 10 nitin.a.kamble 2013-09-12 20:14:44 +0000 Pulling in RP here, as this issue affects non-intel BSP also. 36626 11 dvhart 2013-09-12 20:14:56 +0000 I would typically agree with Tom on this if it weren't for the number of times we've seen this failure. However, so long as it is addressed, I don't feel like pushing on solution over the other. If we fix it per-BSP, we will likely need to do this frequently in a piecemeal way. So, let's go ahead and do this via APPEND per-BSP to address this particular bug. If we get a slew of these post 1.5, then we can reconsider a global fix. 36627 12 nitin.a.kamble 2013-09-12 20:22:27 +0000 Darren, In that case this fix also need to propogate non-intel BSPs. Can you check, wheather beaglebone is affected by this bug? If not, then it become meta-intel specific issue. If yes, then any BSP using linux-yocto-3.10 kernel is affected. I am not worried about non-intel BSPs as such, but the issue will be pointed back to linux-yocto-3.10 kernel from oecore/poky release, which IMO we should avoid. Thanks, Nitin 36628 13 dvhart 2013-09-12 20:33:51 +0000 No, I will not be able to test with Beagleboard. Does this particular bug impact more than one BSP currently? 36629 14 nitin.a.kamble 2013-09-12 20:35:24 +0000 Darren, As I see, this BSP affects all the BSPs using our linux-yocto-3.10 kernel. Thanks, Nitin 36630 15 nitin.a.kamble 2013-09-12 20:37:12 +0000 (In reply to comment #14) > Darren, > As I see, this BSP affects all the BSPs using our linux-yocto-3.10 kernel. > > Thanks, > Nitin correction, I mean: "this issue affects" and not "this BSP affects" 36631 16 ross.burton 2013-09-12 21:07:41 +0000 (In reply to comment #8) > She says even though USB autosuspend delay > is set in the kernel, the power/control should be set to "on" for all > non-hub usb devices. Which also disables the usb autosuspend. But I am > finding that in our kernel all the USB devices have power/control set to > "auto". She mentioned that udev rules of systemd may be turning it to > "auto", which I did not find happening in our images. > From all these discussions seems like a new udev rule will be right way to > fix this issue. But my udev rules are not helping. Maybe someone who is a > udev-fu master in can help here. I can look at this tomorrow as I have a reliable test case on my desk. Ross 36660 17 ross.burton 2013-09-13 09:09:30 +0000 Confirmed here, all devices are "auto". There's only one udev rule that manipulates the power/control and disabling that doesn't help. 36665 18 ross.burton 2013-09-13 09:49:14 +0000 Interesting data point is that my desktop has Debian's 3.10-2 kernel and that doesn't have this problem. 36693 19 tom.zanussi 2013-09-13 14:31:06 +0000 A quick check of the Ubuntu 3.10-2 kernel doesn't show any changes made by Ubuntu in this area. There have been a couple more changes since then to fix things that aren't in 3.10.2 (that we already have in our kernel since they're also in stable and we've of course merged those, but since you're ok with Debian 3.10.2, they wouldn't matter e.g.: usb: core: don't try to reset_device() a port that got just disconnected usb: check usb_hub_to_struct_hub() return value USB: global suspend and remote wakeup don't mix usb: check usb_hub_to_struct_hub() return value Incidentally, here's the justification for the original removal of CONFIG_USB_SUSPEND, for reference: USB: remove CONFIG_USB_SUSPEND option There's very little point in keeping CONFIG_USB_SUSPEND because almost everybody enables it. The few that don't will find that the usbcore module has gotten somewhat bigger and they will have to take active measures if they want to prevent hubs from being runtime suspended. So if everyone enables it and doesn't see problems, and Ubuntu with the same kernel doesn't see problems, it must be somewhere else. 36697 20 nitin.a.kamble 2013-09-13 14:35:04 +0000 Do usb devices on ubuntu show "on" setting or "auto" setting for the power/control in sysfs ? My guess is "on". if it is, then we need to see what is making it "on" 36879 21 nitin.a.kamble 2013-09-18 15:11:27 +0000 commit b925c752c07ff625386daf08d41744e1160fba6a Author: Nitin A Kamble <nitin.a.kamble@intel.com> Date: Fri Sep 13 21:16:44 2013 +0000 udev: avoid autosuspend of USB input devices Some of the external USB devices has internal USB hub, which make them look like "fixed" rather than "removable". And USB autosuspend does not work with some of these devices resulting in inoperable pointing device. Now the code detect these false "fixed" devices by looking at their parents. If any of their parent is "removable", then USB autosuspend is not enabled for that device, which keeps the pointing device functional. Fixes bug: [YOCTO #5166] (From OE-Core rev: d74a0ecdbc85a482cab6e7eae8dcb48185d44d84) Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>