Bug 5166

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

yet another option is add this line to meta/recipes-kernel/linux/linux-yocto_3.10.bb from oecore.

APPEND_append = " usb.autosuspend=-1"

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.

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.

I agree, linux-yocto_3.10.bb is the best place given the number of times this failure has presented itself.

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?

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

(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.

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.

Pulling in RP here, as this issue affects non-intel BSP also.

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.

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

No, I will not be able to test with Beagleboard.

Does this particular bug impact more than one BSP currently?

Darren,
 As I see, this BSP affects all the BSPs using our linux-yocto-3.10 kernel.

Thanks,
Nitin

(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"

(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

Confirmed here, all devices are "auto".  There's only one udev rule that manipulates the power/control and disabling that doesn't help.

Interesting data point is that my desktop has Debian's 3.10-2 kernel and that doesn't have this problem.

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.

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"

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>