I have a specific vendor usb 3.0 camera, that don’t provide lpm u1 and u2 exit latencies. From dmesg i see: “Parent hub missing LPM exit latency info. Power management will be impacted”, when i connect camera. I want manually to disable LPM for this device. How it possible with tegra-xhci?
This might depend on which version you’re running, but you may try to disable usbcore.autosuspend as early as possible.
I would suggest the same as @Honey_Patouceul. If you have a use-case to describe which involves something other than problems occurring in a situation other than normal sleep mode you’ll need to describe that…if it is just a problem during normal sleep from inactivity the above should work.
@linuxdev @Honey_Patouceul can you provide information, how disable autosuspending correctly? I’m using Jetpack Linux For Tegra Image for Apalis Tk1 from Toradex (L4T 21.7 | 2.8b3 | 2018-10-11 | 1.97 GB) BSP Layers and Reference Images for Yocto Project Software | Toradex Developer Center
The Apalis version is the same as the dev kit version other than device tree (but device tree is not required). The “APPEND” key/value pair in extlinux.conf still works as usual in the older releases. So in extlinux.conf (in “/boot/” or “/boot/extlinux/” depending on how old the release is) will have “APPEND” and you add this (space delimited):
usbcore.autosuspend=-1
Note that Apalis does have their own system as well, but I think their extlinux.conf probably also exists. If not, then they may have some custom method to pass arguments to the Linux kernel at the time of boot (I mention this because they have multiple methods of installing the o/s…my experience with the Apalis is from the older T30).
I tried this, but it’s not give success in issue. There is another name of file: jetson-tk1_extlinux.conf.usb
Those files by that name are on the host and during a flash can be used to populate the TK1’s “/boot” after renaming to “extlinux.conf”. The intended file to edit is on the TK1. Are you seeing those files on the host or the TK1? Toradex does have their own customizations, but I’d think for the TK1 this would mostly be device tree edits (meaning extlinux.conf should be present on the TK1).
I see this files on TK1 module.
Do you see the “usbcore.autosuspend=-1” within the output of “cat /proc/cmdline”? If so, then this should prevent low power mode…but it won’t necessarily prevent a warning that the camera does not support LPM. Can you describe how LPM is interfering, and even if you still see an LPM message, does this in any way change functionality to work better?
NOTE: Toradex also has some Angstrom based systems. These are not L4T, although they use the same drivers. My experience with this is only the older Apalis T30, and so I’m not sure how much modification is done for the TK1 variant. If you flash with JetPack using modifications from Toradex, then I suspect only the device tree changes, but if this is a full new Angstrom modification, then things might be quite different.
Sorry for late answer. I don’t see “usbcore.autosuspend=-1” in the output of “cat /proc/cmdline”. But i change this parameter in /boot/extlinux/jetson-tk1_extlinux.conf.usb. There are no file, named “extlinux.conf”.
“/boot/extlinux/jetson-tk1_extlinux.conf.usb” is not used in boot. Only “/boot/extlinux/extlinux.conf” is used. The version you edited is used by other software to create “extlinux.conf”. The “usb” version is only if you are booting from a USB device. Most likely the file is there only for reference. This is why your edit never shows up in cmdline (and thus the edit was never put in place).
In the past Toradex used only the Angstrom distributions which were based on the L4T/NVIDIA sample rootfs. With JetPack being used I’m not sure what differences are being applied to the TK1. It is guaranteed that the device tree will change, and that a standard L4T install with the Toradex device tree would work as a regular L4T install. Is the root file system custom with the Toradex install? What is your boot device for the root file system (e.g., eMMC, USB, SATA, so on)?
@linuxdev From Toradex forum, @jaski.tx give me advice, how to disable autosuspend. At the last commentary you can see what results i get.
I am unsure if that means it worked for you or not. However, if the change doesn’t make it to “/proc/cmdline”, then there was no change.
What were the exact steps taken? Was the autosuspend the only change to the cmdline? Is it just USB not working?
Look, there are steps, that i took to solve the problem:
- First of all, i think that my problem in Link Power Management (LPM), because i saw from
dmesg
:
[ 1692.552323] usb 2-1: new SuperSpeed USB device number 7 using tegra-xhci
[ 1692.577667] usb 2-1: Parent hub missing LPM exit latency info. Power management will be impacted.
[ 1692.591443] usb 2-1: New USB device found, idVendor=dcdc, idProduct=3102
[ 1692.591456] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1692.591464] usb 2-1: Product: GEO-CMV Ver. 1.00
[ 1692.591472] usb 2-1: Manufacturer: STT llc
[ 1692.591479] usb 2-1: SerialNumber: 1700
But, as @dominik.tx wrote from Toradex - “Apalis TK1 is configured with LPM disabled…”. SOLVED. It’s not decision.
2) Then i think, that it’s enabled autosuspend mode impacts my camera. @jaski.tx wrote that i need to change
defargs
variable from u-boot and add
usbcore.autosuspend=-1
. Then i check it with
cat /proc/cmdline
and
cat /sys/module/usbcore/parameters/autosuspend
and it indicates, that autosuspend = -1. SOLVED. It’s not decision.
3) Another way to solve the task. I saw, that when i connect my camera to usb 3.0 port, from
lsusb -t
, field “Device” is empty. Then when i took from my program timeout error, i make command
lsusb -t
once more, and i see, that field “Device=usbfs”. So, is it possible to add my device to blacklist in linux by VendorID:ProductId? Maybe it help…
FYI, power management comes into effect only during sleep or some low power mode. Lack of power management would have no effect on a system where everything is running without any sort of reduced power state. When there is an issue it is usually because a device which was put in reduced power mode does not come back up the way it should as power goes back up. The hope is that removing autosuspend keeps the device from needing to transition from reduced power to full power. If the device never went into a power management mode, then no LPM bug can be of issue.
Although it is possible to need such a change to the bootloader, typically you won’t be in boot long enough to care about power saving modes. There are cases where the Linux kernel retains some of the hardware states the bootloader creates, but I don’t think that will be the case here and it is easier to test just changing the kernel first before messing with the bootloader. Since the kernel command line shows the autosuspend we know that this is in place. USB won’t go to low power suspend mode and will keep providing full power to devices.
So regardless of the warning on lack of LPM support, does the device now work the way you expect? If the device now works, then there really is no need to try and remove warning messages.
If things don’t work, then continue reading…
Having a blank description in lsusb is different than missing some of the other details. Some devices don’t have a description available, but this will have no effect on device operation. What is the exact “lsusb -t” output (don’t forget to quote it with the “</>” code icon to preserve indenting)?
When you blacklist it implies you do not want the relevant driver loading (subtle point: It is a driver being blacklisted, not a device). If the device is the camera, then it means the camera will not be accessible. For cases when more than one driver might qualify for a device it isn’t unusual to want to use a different driver for a device and blacklist the default driver in order to be sure the correct driver is used. A PC’s video driver for NVIDIA graphics is an example…one would blacklist the Nouveau driver (not the device), and then put the NVIDIA driver in place. This is a driver based blacklist.
Udev is used to identify specific USB devices and make decision changes on various aspects of the specific device. One would have to start looking closer at how details of how the device fails (other than just a message about lack of support for LPM) to know what might be useful. So the question occurs, that after autosuspend is disabled, what is the exact nature of how the device fails (beyond log warnings)?
@linuxdev I don’t know reason of my issue. I just list the points that I noticed. There is code of my program to achieve the frames from camera: CodePile | Easily Share Piles of Code. Algorithm of taking frames from camera following:
- Command FiFoInit (0x01 endpoint 5 bytes → 0x81 endpoint to receive 64 bytes of status);
- Command CamStart (similar to fifoinit);
- Cycle command GetStatus, while bit FIFOEMPTY become 1 (similar fifoint)
- Command SetDataSize (2048*2048 size if sensor CMV4000);
- Check the connection from status command, meaning usb 3.0 or usb 2.0, it give us what size of data we want to receive;
- then 0x86 endpoint to receive frame;
What logs do you prefer? There is logs from libusb library, when timeout is interrupted:
[29.884016] [00000c65] libusbx: debug [add_to_flying_list] arm timerfd for timeout in 500ms (first in line)
[29.884026] [00000c65] libusbx: debug [submit_bulk_transfer] need 1 urbs for new transfer with length 4177920
[29.885119] [00000c65] libusbx: debug [libusb_handle_events_timeout_completed] doing our own event handling
[29.885147] [00000c65] libusbx: debug [handle_events] poll() 4 fds with timeout in 60000ms
[30.384033] [00000c65] libusbx: debug [handle_events] poll() returned 1
[30.384063] [00000c65] libusbx: debug [handle_events] timerfd triggered
[30.384071] [00000c65] libusbx: debug [libusb_cancel_transfer]
[30.384783] [00000c65] libusbx: debug [disarm_timerfd]
[30.384804] [00000c65] libusbx: debug [libusb_handle_events_timeout_completed] doing our own event handling
[30.384811] [00000c65] libusbx: debug [handle_events] poll() 4 fds with timeout in 60000ms
[30.384822] [00000c65] libusbx: debug [handle_events] poll() returned 1
[30.385190] [00000c65] libusbx: debug [reap_for_handle] urb type=3 status=-2 transferred=446464
[30.385199] [00000c65] libusbx: debug [handle_bulk_completion] handling completion status -2 of bulk urb 1/1
[30.385205] [00000c65] libusbx: debug [handle_bulk_completion] abnormal reap: urb status -2
[30.385209] [00000c65] libusbx: debug [handle_bulk_completion] received 446464 bytes of surplus data
[30.385214] [00000c65] libusbx: debug [handle_bulk_completion] abnormal reap: last URB handled, reporting
[30.385219] [00000c65] libusbx: debug [usbi_handle_transfer_cancellation] detected timeout cancellation
[30.385224] [00000c65] libusbx: debug [disarm_timerfd]
[30.385231] [00000c65] libusbx: debug [usbi_handle_transfer_completion] transfer 0x98aec has callback 0xb6fb2c21
[30.385237] [00000c65] libusbx: debug [sync_transfer_cb] actual_length=446464
[36.196989] [00000c65] libusbx: debug [add_to_flying_list] arm timerfd for timeout in 1000ms (first in line)
[36.197003] [00000c65] libusbx: debug [submit_bulk_transfer] need 1 urbs for new transfer with length 24576
[36.197037] [00000c65] libusbx: debug [libusb_handle_events_timeout_completed] doing our own event handling
[36.197045] [00000c65] libusbx: debug [handle_events] poll() 4 fds with timeout in 60000ms
[37.197004] [00000c65] libusbx: debug [handle_events] poll() returned 1
[37.197037] [00000c65] libusbx: debug [handle_events] timerfd triggered
[37.197045] [00000c65] libusbx: debug [libusb_cancel_transfer]
[37.199843] [00000c65] libusbx: debug [disarm_timerfd]
[37.199868] [00000c65] libusbx: debug [libusb_handle_events_timeout_completed] doing our own event handling
[37.199875] [00000c65] libusbx: debug [handle_events] poll() 4 fds with timeout in 60000ms
[37.199885] [00000c65] libusbx: debug [handle_events] poll() returned 1
[37.199895] [00000c65] libusbx: debug [reap_for_handle] urb type=3 status=-2 transferred=0
[37.199901] [00000c65] libusbx: debug [handle_bulk_completion] handling completion status -2 of bulk urb 1/1
[37.199906] [00000c65] libusbx: debug [handle_bulk_completion] abnormal reap: urb status -2
[37.199911] [00000c65] libusbx: debug [handle_bulk_completion] abnormal reap: last URB handled, reporting
[37.199916] [00000c65] libusbx: debug [usbi_handle_transfer_cancellation] detected timeout cancellation
[37.199920] [00000c65] libusbx: debug [disarm_timerfd]
[37.199926] [00000c65] libusbx: debug [usbi_handle_transfer_completion] transfer 0x8e874 has callback 0xb6fb2c21
[37.199931] [00000c65] libusbx: debug [sync_transfer_cb] actual_length=0
I couldn’t say for sure, but those are actual USB protocol errors (meaning that this is from the USB and not from the driver to the device…likely the driver past USB never got what it needed to work with). What is the exact output of the following, once with the camera, and once without?
lsusb -t
Via just plain “lsusb” (no “-t”) you should see an ID column, and using the ID for just that camera, what is the output of this (I’m using “0955:7140”, but that is just an example…put your ID in place):
sudo lsusb -d 0955:7140 -vvv