usb autosuspend not working with R28.2

I am using rel 28.2 on tx1 based custom board.
I am passing usbcore.autosuspend=-1 in extlinux.conf file, but when device boots up, i consistently see usb disconnected messgaes.
I even tried setting it through “echo -1 >/sys/module/usbcore/parameters/autosuspend” but this also doesn’t seem to work.
Both methods work well with Rel 24.1 and Rel 24.2.1
Any clues how to disable autosuspend in rel 28.2??


After booting can you verify the “autosuspend=-1” is in “/proc/cmdline”? After booting, can you verify that “cat /sys/module/usbcore/parameters/autosuspend” returns “-1”?

Then, later on, after autosuspect seems to fail, can you go back to the “cat /sys/module/usbcore/parameters/autosuspend” and check to see if it is still “-1”, or if perhaps it is instead something else? I’m thinking about a performance script possibly changing this and want to verify if it is actually autosuspend failing, or if it is instead something restoring autosuspend to a state other than “-1”.

NOTE: It was a fairly big change going from R24.x to R28.x since R24.x uses a kernel 3.x series, and after that there was a switch to kernel 4.x series.

Hi patyarahate,

Has this issue been clarified and fixed?
An result can be shared or still need further support?



Sorry for the late reply.
I could verify the things you have mentioned.
/proc/cmdline shows parameter autosuspend as autosuspend=-1
also cat /sys/module/usbcore/parameters/autosuspend shows -1 in output.
Following is the output

nvidia@tegra-ubuntu:~$ sudo cat /sys/module/usbcore/parameters/autosuspend
nvidia@tegra-ubuntu:~$ uname -a
Linux tegra-ubuntu 4.4.38+ #1 SMP PREEMPT Tue Jun 5 03:55:09 PDT 2018 aarch64 aarch64 aarch64 GNU/Linux
nvidia@tegra-ubuntu:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04 LTS
Release:        16.04
Codename:       xenial

But still i see issue of usb disconnection.
Any other suggestions?


Autosuspend does not cause a disconnect per se, it’s just a low power mode (perhaps the USB device doesn’t support suspend, in which case you might have an issue with suspend mode). If there is an actual disconnect, and since you’ve verified autosuspend is disabled, then I think the issue is something else.

What mode is your port, e.g., USB2, USB3? How many devices are on that port (“lsusb -t” would be useful to see)? What kind of power delivery is used, e.g., bus powered, or perhaps an external powered HUB provides power? In terms of how much power is required, are these low power simple devices like keyboard/mouse, or perhaps something using more power (like an external hard drive which is bus powered…or some USB3 cameras)?


yes, you are correct “Autosuspend does not cause a disconnect per se”.
I am connecting 4G LTE modem on usb interface, i faced same usb disconnect issue with rel 24.1/24.2.1.
Setting autosuspend=-1 solved it for me for rel 24.1/24.2.1.
I am connecting same modem, but with rel 28.2, i see same usb disconnect issue.
But setting autosuspend=-1, does not work with rel 28.2
So what is happening is USB is able to enumerate the device, just after it is enumerated, i see usb disconnect message.


What I’ll suggest is monitor dmesg with “dmesg --follow”, and see what the logs say just before and through the failure (get an exact error message/log). There may be some other note to add a clue with. As is it sounds like autosuspend is just one way to cause an issue. For anything WiFi I’m sure low power mode could cause a network failure, but it is still suspicious to think this would cause a USB disconnect…something else is going on at the same time.

Just to be complete, you might also monitor “sudo tail -f /var/log/Xorg.0.log”. I say this because it isn’t unusual for NetworkManager to get involved…and NetworkManager is sometimes configured by login status. I’d be curious if X mentions some sort of sleep or suspend at the same moment as disconnect.

Hi patyarahate,
Can you check the config file of r24.2.1 and r28.2? Maybe certain config is enabled on r24.2.1 and disabled on r28.2, leading to the difference.