Re: Logitech G27 leds no more supported
On Fri, October 19, 2018 4:46 pm, Simon Wood wrote: > Thanks for the report, and yes it does seem broken. I tried on > 4.17.0-rc5+ > and it seems that the 'hid-logitech' module does not know the device ID of > the G29 anymore. Oh, how easily we forget things... there's a switch on the top wheel (close to LEDs) which changes the wheel into a compatibility mode. Flipping this get wheel recognized and working on 4.17.0-rc5+ -- root@thevoid:/sys/class/leds# ls 0003:046D:C24F.0009::RPM1 0003:046D:C24F.0009::RPM4 input3::numlock input8::compose input8::scrolllock 0003:046D:C24F.0009::RPM2 0003:046D:C24F.0009::RPM5 input3::scrolllock input8::kana 0003:046D:C24F.0009::RPM3 input3::capslock input8::capslock input8::numlock root@thevoid:/sys/class/leds# cd 0003\:046D\:C24F.0009\:\:RPM4 root@thevoid:/sys/class/leds/0003:046D:C24F.0009::RPM4# ls brightness device max_brightness power subsystem trigger uevent root@thevoid:/sys/class/leds/0003:046D:C24F.0009::RPM4# cat max_brightness > brightness -- I'll rebuild HEAD to confirm it still works. Simon. PS. We should maybe pick up that other USB Id.
Re: Logitech G27 leds no more supported
On Wed, October 17, 2018 11:21 pm, Greg KH wrote: > On Wed, Oct 17, 2018 at 02:44:51PM +, elrond...@protonmail.com wrote: >> No more leds subdirectory for this wheel, someone reports me G29 leds >> stays supported correctly. >> >> No more path: /sys/class/leds/logitechwheelpath, just my keyboard leds >> are detected. Force feedback are correctly supported. >> > What kernel version did this work properly on? > > > And I think the linux-input mailing list would want to know about this, > this isn't a usb-core specific issue. I've added them to the cc: here. > thanks, Thanks for the report, and yes it does seem broken. I tried on 4.17.0-rc5+ and it seems that the 'hid-logitech' module does not know the device ID of the G29 anymore. Support was originally added in 29fae1c85166ef525b8b6518e749295e0c9d1e20, but that was a long time ago and it seems that the 'hid-core.c' stuff has somewhat changed Will continue looking for cause. Simon Syslog on insert -- Oct 19 16:16:04 thevoid kernel: [33656.156644] usb 1-2: new full-speed USB device number 12 using xhci_hcd Oct 19 16:16:05 thevoid kernel: [33656.306093] usb 1-2: New USB device found, idVendor=046d, idProduct=c260, bcdDevice=89.00 Oct 19 16:16:05 thevoid kernel: [33656.306106] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Oct 19 16:16:05 thevoid kernel: [33656.306114] usb 1-2: Product: G29 Driving Force Racing Wheel Oct 19 16:16:05 thevoid kernel: [33656.306122] usb 1-2: Manufacturer: Logitech Oct 19 16:16:05 thevoid kernel: [33656.314487] input: Logitech G29 Driving Force Racing Wheel as /devices/pci:00/:00:14.0/usb1/1-2/1-2:1.0/0003:046D:C260.0006/input/input22 Oct 19 16:16:05 thevoid kernel: [33656.373288] hid-generic 0003:046D:C260.0006: input,hiddev3,hidraw5: USB HID v1.10 Joystick [Logitech G29 Driving Force Racing Wheel] on usb-:00:14.0-2/input0 Oct 19 16:16:05 thevoid mtp-probe: checking bus 1, device 12: "/sys/devices/pci:00/:00:14.0/usb1/1-2" Oct 19 16:16:05 thevoid mtp-probe: bus: 1, device: 12 was not an MTP device Oct 19 16:16:05 thevoid upowerd[1405]: unhandled action 'bind' on /sys/devices/pci:00/:00:14.0/usb1/1-2/1-2:1.0/0003:046D:C260.0006 Oct 19 16:16:05 thevoid upowerd[1405]: unhandled action 'bind' on /sys/devices/pci:00/:00:14.0/usb1/1-2/1-2:1.0 Oct 19 16:16:05 thevoid upowerd[1405]: unhandled action 'bind' on /sys/devices/pci:00/:00:14.0/usb1/1-2 -- lsusb -vv -- Bus 001 Device 012: ID 046d:c260 Logitech, Inc. Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x046d Logitech, Inc. idProduct 0xc260 bcdDevice 89.00 iManufacturer 1 iProduct2 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 41 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 200mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 0 No Subclass bInterfaceProtocol 0 None iInterface 0 HID Device Descriptor: bLength 9 bDescriptorType33 bcdHID 1.10 bCountryCode0 Not supported bNumDescriptors 1 bDescriptorType34 Report wDescriptorLength 160 Report Descriptors: ** UNAVAILABLE ** Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 5 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 5 -- uname -a -- Linux thevoid 4.17.0-rc5+ #11 SMP Sat May 19 11:08:23 MDT 2018 x86_64 x86_64 x86_64 GNU/Linux -- filename: /lib/modules/4.17.0-rc5+/kernel/drivers/hid/hid-logitech.ko license:GPL srcversion: D51DE1425C46A412C85BBE4 alias:
[PATCH v2] HID: hiddev: fix potential Spectre v1
uref->usage_index can be indirectly controlled by userspace, hence leading
to a potential exploitation of the Spectre variant 1 vulnerability.
This field is used as an array index by the hiddev_ioctl_usage() function,
when 'cmd' is either HIDIOCGCOLLECTIONINDEX, HIDIOCGUSAGES or
HIDIOCSUSAGES.
For cmd == HIDIOCGCOLLECTIONINDEX case, uref->usage_index is compared to
field->maxusage and then used as an index to dereference field->usage
array. The same thing happens to the cmd == HIDIOC{G,S}USAGES cases, where
uref->usage_index is checked against an array maximum value and then it is
used as an index in an array.
This is a summary of the HIDIOCGCOLLECTIONINDEX case, which matches the
traditional Spectre V1 first load:
copy_from_user(uref, user_arg, sizeof(*uref))
if (uref->usage_index >= field->maxusage)
goto inval;
i = field->usage[uref->usage_index].collection_index;
return i;
This patch fixes this by sanitizing field uref->usage_index before using it
to index field->usage (HIDIOCGCOLLECTIONINDEX) or field->value in
HIDIOC{G,S}USAGES arrays, thus, avoiding speculation in the first load.
Signed-off-by: Breno Leitao
Cc:
--
v2: Contemplate cmd == HIDIOC{G,S}USAGES case
diff --git a/drivers/hid/usbhid/hiddev.c b/drivers/hid/usbhid/hiddev.c
index 23872d08308c..a746017fac17 100644
--- a/drivers/hid/usbhid/hiddev.c
+++ b/drivers/hid/usbhid/hiddev.c
@@ -512,14 +512,24 @@ static noinline int hiddev_ioctl_usage(struct hiddev
*hiddev, unsigned int cmd,
if (cmd == HIDIOCGCOLLECTIONINDEX) {
if (uref->usage_index >= field->maxusage)
goto inval;
+ uref->usage_index =
+ array_index_nospec(uref->usage_index,
+ field->maxusage);
} else if (uref->usage_index >= field->report_count)
goto inval;
}
- if ((cmd == HIDIOCGUSAGES || cmd == HIDIOCSUSAGES) &&
- (uref_multi->num_values > HID_MAX_MULTI_USAGES ||
-uref->usage_index + uref_multi->num_values >
field->report_count))
- goto inval;
+ if (cmd == HIDIOCGUSAGES || cmd == HIDIOCSUSAGES) {
+ if (uref_multi->num_values > HID_MAX_MULTI_USAGES ||
+ uref->usage_index + uref_multi->num_values >
+ field->report_count)
+ goto inval;
+
+ uref->usage_index =
+ array_index_nospec(uref->usage_index,
+ field->report_count -
+ uref_multi->num_values);
+ }
switch (cmd) {
case HIDIOCGUSAGE:
--
2.17.1
Re: Error reading USB camera in BeagleBone with ARM Debian
Hi, In any case, I double checked by setting only 1 line in the uEnv.txt file the ouput for cat /proc/cmdline is console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet musb_hdrc.use_dma=0 usbcore.autosuspend=-1 But same troubles as before Regards Josep M. On Fri, Oct 19, 2018 at 8:42 PM Bin Liu wrote: > > On Fri, Oct 19, 2018 at 02:26:51PM -0400, Alan Stern wrote: > > On Fri, 19 Oct 2018, Bin Liu wrote: > > > > > On Fri, Oct 19, 2018 at 07:19:17PM +0200, Josep M. Mirats Tur wrote: > > > > Hi Bin, > > > > > > > > I included the following line in the /boot/uEnv.txt file (attached for > > > > your info): > > > > cmdline=musb_hdrc.use_dma=0 > > > > > > I am not sure about the 'cmdline=' part. Anyway, after your board is > > > booted, use command 'cat /proc/cmdline' to check if your setting is > > > correct. > > > > There already was a "cmdline=" entry in the file: > > > > > > cmdline=coherent_pool=1M net.ifnames=0 quiet > > > > > > > > #In the event of edid real failures, uncomment this next line: > > > > #cmdline=coherent_pool=1M net.ifnames=0 quiet > > > > video=HDMI-A-1:1024x768@60e > > > > > > > > #Use an overlayfs on top of a read-only root filesystem: > > > > #cmdline=coherent_pool=1M net.ifnames=0 quiet overlayroot=tmpfs > > > > > > > > ##enable Generic eMMC Flasher: > > > > ##make sure, these tools are installed: dosfstools rsync > > > > #cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh > > > > > > > > #jmmt disable dma for musb > > > > cmdline=musb_hdrc.use_dma=0 > > > > The "musb_hdrc.use_dma=0" should have been appended to the earlier > > entry, not added separately. > > right, but this is just a testing to disable cppi dma, other existing > cmdline params seem not related to usb, so I think it is okay to > overwrite. > > Regards, > -Bin.
Re: Error reading USB camera in BeagleBone with ARM Debian
On Fri, Oct 19, 2018 at 02:26:51PM -0400, Alan Stern wrote: > On Fri, 19 Oct 2018, Bin Liu wrote: > > > On Fri, Oct 19, 2018 at 07:19:17PM +0200, Josep M. Mirats Tur wrote: > > > Hi Bin, > > > > > > I included the following line in the /boot/uEnv.txt file (attached for > > > your info): > > > cmdline=musb_hdrc.use_dma=0 > > > > I am not sure about the 'cmdline=' part. Anyway, after your board is > > booted, use command 'cat /proc/cmdline' to check if your setting is > > correct. > > There already was a "cmdline=" entry in the file: > > > > cmdline=coherent_pool=1M net.ifnames=0 quiet > > > > > > #In the event of edid real failures, uncomment this next line: > > > #cmdline=coherent_pool=1M net.ifnames=0 quiet video=HDMI-A-1:1024x768@60e > > > > > > #Use an overlayfs on top of a read-only root filesystem: > > > #cmdline=coherent_pool=1M net.ifnames=0 quiet overlayroot=tmpfs > > > > > > ##enable Generic eMMC Flasher: > > > ##make sure, these tools are installed: dosfstools rsync > > > #cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh > > > > > > #jmmt disable dma for musb > > > cmdline=musb_hdrc.use_dma=0 > > The "musb_hdrc.use_dma=0" should have been appended to the earlier > entry, not added separately. right, but this is just a testing to disable cppi dma, other existing cmdline params seem not related to usb, so I think it is okay to overwrite. Regards, -Bin.
Re: Error reading USB camera in BeagleBone with ARM Debian
On Fri, 19 Oct 2018, Bin Liu wrote: > On Fri, Oct 19, 2018 at 07:19:17PM +0200, Josep M. Mirats Tur wrote: > > Hi Bin, > > > > I included the following line in the /boot/uEnv.txt file (attached for > > your info): > > cmdline=musb_hdrc.use_dma=0 > > I am not sure about the 'cmdline=' part. Anyway, after your board is > booted, use command 'cat /proc/cmdline' to check if your setting is > correct. There already was a "cmdline=" entry in the file: > > cmdline=coherent_pool=1M net.ifnames=0 quiet > > > > #In the event of edid real failures, uncomment this next line: > > #cmdline=coherent_pool=1M net.ifnames=0 quiet video=HDMI-A-1:1024x768@60e > > > > #Use an overlayfs on top of a read-only root filesystem: > > #cmdline=coherent_pool=1M net.ifnames=0 quiet overlayroot=tmpfs > > > > ##enable Generic eMMC Flasher: > > ##make sure, these tools are installed: dosfstools rsync > > #cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh > > > > #jmmt disable dma for musb > > cmdline=musb_hdrc.use_dma=0 The "musb_hdrc.use_dma=0" should have been appended to the earlier entry, not added separately. Alan Stern
Re: Error reading USB camera in BeagleBone with ARM Debian
Hi Bin, > Do you know what is the usb throughput required in your test case? for > example image format, resolution, frame rate? Is the usb data transfer > bulk or isoch? Yes, the image format is 640 x 480 The camera can run up to 30fps, although I do not need it and set up it to 5 The Usb data transfer is "bulk" Regards Josep M. On Fri, Oct 19, 2018 at 8:01 PM Bin Liu wrote: > > On Fri, Oct 19, 2018 at 07:48:20PM +0200, Josep M. Mirats Tur wrote: > > Hi, > > > > Yes, this would be the link: > > http://shop-orbbec3d-com.3dcartstores.com/Astra-Mini_p_40.html > > Okay, It is about $160, a bit more than my bugdet... > > > In the meanwhile I'll check my application with other board. > > > > Do you think there might be a problem with the processor frequency? > > I've also crossing e-mails with ORBBEC engineers, and their only > > answer has been to suggest using an ARM processor capable of 1.8GHz > > Beagle is capable of 1GHz > > But I can not see why is this so important as long as USB is well > > synchronized and interrupts and driver work well. (Actually I'm not > > familiar with ARM USB system, is just intuition) > > I guess the cpu clock requirement is only to ensure the whole system is > capable to process the usb packets, depending on the image resolution, > fps, and any other data processing. But lower cpu clock shouldn't cause > such problem that the usb controller generates rx interrupt but fifo has > no usb packet. If ARM cannot keep up, which doesn't send IN requests on > time, the camera should just drop data. > > Do you know what is the usb throughput required in your test case? for > example image format, resolution, frame rate? Is the usb data transfer > bulk or isoch? > > Regards, > -Bin.
Re: Error reading USB camera in BeagleBone with ARM Debian
On Fri, Oct 19, 2018 at 07:48:20PM +0200, Josep M. Mirats Tur wrote: > Hi, > > Yes, this would be the link: > http://shop-orbbec3d-com.3dcartstores.com/Astra-Mini_p_40.html Okay, It is about $160, a bit more than my bugdet... > In the meanwhile I'll check my application with other board. > > Do you think there might be a problem with the processor frequency? > I've also crossing e-mails with ORBBEC engineers, and their only > answer has been to suggest using an ARM processor capable of 1.8GHz > Beagle is capable of 1GHz > But I can not see why is this so important as long as USB is well > synchronized and interrupts and driver work well. (Actually I'm not > familiar with ARM USB system, is just intuition) I guess the cpu clock requirement is only to ensure the whole system is capable to process the usb packets, depending on the image resolution, fps, and any other data processing. But lower cpu clock shouldn't cause such problem that the usb controller generates rx interrupt but fifo has no usb packet. If ARM cannot keep up, which doesn't send IN requests on time, the camera should just drop data. Do you know what is the usb throughput required in your test case? for example image format, resolution, frame rate? Is the usb data transfer bulk or isoch? Regards, -Bin.
Re: Error reading USB camera in BeagleBone with ARM Debian
Hi, Yes, this would be the link: http://shop-orbbec3d-com.3dcartstores.com/Astra-Mini_p_40.html In the meanwhile I'll check my application with other board. Do you think there might be a problem with the processor frequency? I've also crossing e-mails with ORBBEC engineers, and their only answer has been to suggest using an ARM processor capable of 1.8GHz Beagle is capable of 1GHz But I can not see why is this so important as long as USB is well synchronized and interrupts and driver work well. (Actually I'm not familiar with ARM USB system, is just intuition) Many thanks for your help today Josep M. On Fri, Oct 19, 2018 at 7:41 PM Bin Liu wrote: > > On Fri, Oct 19, 2018 at 07:33:47PM +0200, Josep M. Mirats Tur wrote: > > Hi, > > > > It seems correct, this is the output of sudo cat /proc/cmdline: > > console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 > > root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait musb_hdrc.use_dma=0 > > It looks correct. So the issue is not related to CPPI dma. > Do you have a link to buy the camera? If I can afford it, I might buy > one to take a look at this problem. > > Regards, > -Bin.
Re: Error reading USB camera in BeagleBone with ARM Debian
On Fri, Oct 19, 2018 at 07:33:47PM +0200, Josep M. Mirats Tur wrote: > Hi, > > It seems correct, this is the output of sudo cat /proc/cmdline: > console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 > root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait musb_hdrc.use_dma=0 It looks correct. So the issue is not related to CPPI dma. Do you have a link to buy the camera? If I can afford it, I might buy one to take a look at this problem. Regards, -Bin.
Re: Error reading USB camera in BeagleBone with ARM Debian
Hi, It seems correct, this is the output of sudo cat /proc/cmdline: console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait musb_hdrc.use_dma=0 So no changes :( Any other suggestion or idea? Thanks Josep M On Fri, Oct 19, 2018 at 7:31 PM Bin Liu wrote: > > On Fri, Oct 19, 2018 at 07:19:17PM +0200, Josep M. Mirats Tur wrote: > > Hi Bin, > > > > I included the following line in the /boot/uEnv.txt file (attached for > > your info): > > cmdline=musb_hdrc.use_dma=0 > > I am not sure about the 'cmdline=' part. Anyway, after your board is > booted, use command 'cat /proc/cmdline' to check if your setting is > correct. > > Regards, > -Bin. > > > > Is this format correct? > > I rebooted and checked again but still the same errors from dmesg: > > > > [ 228.863997] usb 1-1: new high-speed USB device number 2 using musb-hdrc > > [ 229.016708] usb 1-1: New USB device found, idVendor=2bc5, idProduct=0404 > > [ 229.023512] usb 1-1: New USB device strings: Mfr=1, Product=2, > > SerialNumber=0 > > [ 229.032841] usb 1-1: Product: ORBBEC Depth Sensor > > [ 229.038752] usb 1-1: Manufacturer: Orbbec(R) > > [ 249.221761] musb_host_rx 1965: Rx interrupt with no errors or packet! > > [ 249.228346] musb_host_rx 1965: Rx interrupt with no errors or packet! > > [ 249.238329] musb_host_rx 1965: Rx interrupt with no errors or packet! > > [ 249.249025] musb_ep_program 916: broken !rx_reinit, ep2 csr 0003 > > On Fri, Oct 19, 2018 at 7:00 PM Bin Liu wrote: > > > > > > On Fri, Oct 19, 2018 at 06:31:15PM +0200, Josep M. Mirats Tur wrote: > > > > Bin, > > > > > > > > I'm sorry but I cannot find that menuconfig at the Beagle... > > > > > > Never mind, but add the following to your UBoot bootargs env instead to > > > disable dma. > > > > > > musb_hdrc.use_dma=0 > > > > > > Regards, > > > -Bin. > > > > > > #Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0 > > > > uname_r=4.14.71-ti-r80 > > #uuid= > > #dtb= > > > > ###U-Boot Overlays### > > ###Documentation: > > http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays > > ###Master Enable > > enable_uboot_overlays=1 > > ### > > ###Overide capes with eeprom > > #uboot_overlay_addr0=/lib/firmware/.dtbo > > #uboot_overlay_addr1=/lib/firmware/.dtbo > > #uboot_overlay_addr2=/lib/firmware/.dtbo > > #uboot_overlay_addr3=/lib/firmware/.dtbo > > ### > > ###Additional custom capes > > #uboot_overlay_addr4=/lib/firmware/.dtbo > > #uboot_overlay_addr5=/lib/firmware/.dtbo > > #uboot_overlay_addr6=/lib/firmware/.dtbo > > #uboot_overlay_addr7=/lib/firmware/.dtbo > > ### > > ###Custom Cape > > #dtb_overlay=/lib/firmware/.dtbo > > ### > > ###Disable auto loading of virtual capes (emmc/video/wireless/adc) > > #disable_uboot_overlay_emmc=1 > > disable_uboot_overlay_video=1 > > disable_uboot_overlay_audio=1 > > disable_uboot_overlay_wireless=1 > > #disable_uboot_overlay_adc=1 > > ### > > ###PRUSS OPTIONS > > ###pru_rproc (4.4.x-ti kernel) > > #uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo > > ###pru_rproc (4.14.x-ti kernel) > > uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo > > ###pru_uio (4.4.x-ti, 4.14.x-ti & mainline/bone kernel) > > uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo > > ### > > ###Cape Universal Enable > > enable_uboot_cape_universal=1 > > ### > > ###Debug: disable uboot autoload of Cape > > #disable_uboot_overlay_addr0=1 > > #disable_uboot_overlay_addr1=1 > > #disable_uboot_overlay_addr2=1 > > #disable_uboot_overlay_addr3=1 > > ### > > ###U-Boot fdt tweaks... (6 = 384KB) > > #uboot_fdt_buffer=0x6 > > ###U-Boot Overlays### > > > > cmdline=coherent_pool=1M net.ifnames=0 quiet > > > > #In the event of edid real failures, uncomment this next line: > > #cmdline=coherent_pool=1M net.ifnames=0 quiet video=HDMI-A-1:1024x768@60e > > > > #Use an overlayfs on top of a read-only root filesystem: > > #cmdline=coherent_pool=1M net.ifnames=0 quiet overlayroot=tmpfs > > > > ##enable Generic eMMC Flasher: > > ##make sure, these tools are installed: dosfstools rsync > > #cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh > > > > #jmmt disable dma for musb > > cmdline=musb_hdrc.use_dma=0 >
Re: Error reading USB camera in BeagleBone with ARM Debian
On Fri, Oct 19, 2018 at 07:19:17PM +0200, Josep M. Mirats Tur wrote: > Hi Bin, > > I included the following line in the /boot/uEnv.txt file (attached for > your info): > cmdline=musb_hdrc.use_dma=0 I am not sure about the 'cmdline=' part. Anyway, after your board is booted, use command 'cat /proc/cmdline' to check if your setting is correct. Regards, -Bin. > > Is this format correct? > I rebooted and checked again but still the same errors from dmesg: > > [ 228.863997] usb 1-1: new high-speed USB device number 2 using musb-hdrc > [ 229.016708] usb 1-1: New USB device found, idVendor=2bc5, idProduct=0404 > [ 229.023512] usb 1-1: New USB device strings: Mfr=1, Product=2, > SerialNumber=0 > [ 229.032841] usb 1-1: Product: ORBBEC Depth Sensor > [ 229.038752] usb 1-1: Manufacturer: Orbbec(R) > [ 249.221761] musb_host_rx 1965: Rx interrupt with no errors or packet! > [ 249.228346] musb_host_rx 1965: Rx interrupt with no errors or packet! > [ 249.238329] musb_host_rx 1965: Rx interrupt with no errors or packet! > [ 249.249025] musb_ep_program 916: broken !rx_reinit, ep2 csr 0003 > On Fri, Oct 19, 2018 at 7:00 PM Bin Liu wrote: > > > > On Fri, Oct 19, 2018 at 06:31:15PM +0200, Josep M. Mirats Tur wrote: > > > Bin, > > > > > > I'm sorry but I cannot find that menuconfig at the Beagle... > > > > Never mind, but add the following to your UBoot bootargs env instead to > > disable dma. > > > > musb_hdrc.use_dma=0 > > > > Regards, > > -Bin. > > > #Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0 > > uname_r=4.14.71-ti-r80 > #uuid= > #dtb= > > ###U-Boot Overlays### > ###Documentation: > http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays > ###Master Enable > enable_uboot_overlays=1 > ### > ###Overide capes with eeprom > #uboot_overlay_addr0=/lib/firmware/.dtbo > #uboot_overlay_addr1=/lib/firmware/.dtbo > #uboot_overlay_addr2=/lib/firmware/.dtbo > #uboot_overlay_addr3=/lib/firmware/.dtbo > ### > ###Additional custom capes > #uboot_overlay_addr4=/lib/firmware/.dtbo > #uboot_overlay_addr5=/lib/firmware/.dtbo > #uboot_overlay_addr6=/lib/firmware/.dtbo > #uboot_overlay_addr7=/lib/firmware/.dtbo > ### > ###Custom Cape > #dtb_overlay=/lib/firmware/.dtbo > ### > ###Disable auto loading of virtual capes (emmc/video/wireless/adc) > #disable_uboot_overlay_emmc=1 > disable_uboot_overlay_video=1 > disable_uboot_overlay_audio=1 > disable_uboot_overlay_wireless=1 > #disable_uboot_overlay_adc=1 > ### > ###PRUSS OPTIONS > ###pru_rproc (4.4.x-ti kernel) > #uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo > ###pru_rproc (4.14.x-ti kernel) > uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo > ###pru_uio (4.4.x-ti, 4.14.x-ti & mainline/bone kernel) > uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo > ### > ###Cape Universal Enable > enable_uboot_cape_universal=1 > ### > ###Debug: disable uboot autoload of Cape > #disable_uboot_overlay_addr0=1 > #disable_uboot_overlay_addr1=1 > #disable_uboot_overlay_addr2=1 > #disable_uboot_overlay_addr3=1 > ### > ###U-Boot fdt tweaks... (6 = 384KB) > #uboot_fdt_buffer=0x6 > ###U-Boot Overlays### > > cmdline=coherent_pool=1M net.ifnames=0 quiet > > #In the event of edid real failures, uncomment this next line: > #cmdline=coherent_pool=1M net.ifnames=0 quiet video=HDMI-A-1:1024x768@60e > > #Use an overlayfs on top of a read-only root filesystem: > #cmdline=coherent_pool=1M net.ifnames=0 quiet overlayroot=tmpfs > > ##enable Generic eMMC Flasher: > ##make sure, these tools are installed: dosfstools rsync > #cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh > > #jmmt disable dma for musb > cmdline=musb_hdrc.use_dma=0
Re: Error reading USB camera in BeagleBone with ARM Debian
Hi Bin, I included the following line in the /boot/uEnv.txt file (attached for your info): cmdline=musb_hdrc.use_dma=0 Is this format correct? I rebooted and checked again but still the same errors from dmesg: [ 228.863997] usb 1-1: new high-speed USB device number 2 using musb-hdrc [ 229.016708] usb 1-1: New USB device found, idVendor=2bc5, idProduct=0404 [ 229.023512] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 229.032841] usb 1-1: Product: ORBBEC Depth Sensor [ 229.038752] usb 1-1: Manufacturer: Orbbec(R) [ 249.221761] musb_host_rx 1965: Rx interrupt with no errors or packet! [ 249.228346] musb_host_rx 1965: Rx interrupt with no errors or packet! [ 249.238329] musb_host_rx 1965: Rx interrupt with no errors or packet! [ 249.249025] musb_ep_program 916: broken !rx_reinit, ep2 csr 0003 On Fri, Oct 19, 2018 at 7:00 PM Bin Liu wrote: > > On Fri, Oct 19, 2018 at 06:31:15PM +0200, Josep M. Mirats Tur wrote: > > Bin, > > > > I'm sorry but I cannot find that menuconfig at the Beagle... > > Never mind, but add the following to your UBoot bootargs env instead to > disable dma. > > musb_hdrc.use_dma=0 > > Regards, > -Bin. > #Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0 uname_r=4.14.71-ti-r80 #uuid= #dtb= ###U-Boot Overlays### ###Documentation: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays ###Master Enable enable_uboot_overlays=1 ### ###Overide capes with eeprom #uboot_overlay_addr0=/lib/firmware/.dtbo #uboot_overlay_addr1=/lib/firmware/.dtbo #uboot_overlay_addr2=/lib/firmware/.dtbo #uboot_overlay_addr3=/lib/firmware/.dtbo ### ###Additional custom capes #uboot_overlay_addr4=/lib/firmware/.dtbo #uboot_overlay_addr5=/lib/firmware/.dtbo #uboot_overlay_addr6=/lib/firmware/.dtbo #uboot_overlay_addr7=/lib/firmware/.dtbo ### ###Custom Cape #dtb_overlay=/lib/firmware/.dtbo ### ###Disable auto loading of virtual capes (emmc/video/wireless/adc) #disable_uboot_overlay_emmc=1 disable_uboot_overlay_video=1 disable_uboot_overlay_audio=1 disable_uboot_overlay_wireless=1 #disable_uboot_overlay_adc=1 ### ###PRUSS OPTIONS ###pru_rproc (4.4.x-ti kernel) #uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo ###pru_rproc (4.14.x-ti kernel) uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo ###pru_uio (4.4.x-ti, 4.14.x-ti & mainline/bone kernel) uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo ### ###Cape Universal Enable enable_uboot_cape_universal=1 ### ###Debug: disable uboot autoload of Cape #disable_uboot_overlay_addr0=1 #disable_uboot_overlay_addr1=1 #disable_uboot_overlay_addr2=1 #disable_uboot_overlay_addr3=1 ### ###U-Boot fdt tweaks... (6 = 384KB) #uboot_fdt_buffer=0x6 ###U-Boot Overlays### cmdline=coherent_pool=1M net.ifnames=0 quiet #In the event of edid real failures, uncomment this next line: #cmdline=coherent_pool=1M net.ifnames=0 quiet video=HDMI-A-1:1024x768@60e #Use an overlayfs on top of a read-only root filesystem: #cmdline=coherent_pool=1M net.ifnames=0 quiet overlayroot=tmpfs ##enable Generic eMMC Flasher: ##make sure, these tools are installed: dosfstools rsync #cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh #jmmt disable dma for musb cmdline=musb_hdrc.use_dma=0
Re: Error reading USB camera in BeagleBone with ARM Debian
On Fri, 19 Oct 2018, Josep M. Mirats Tur wrote: > Thanks Alan, > > So, what might be the cause for those transfers that have less data > than expected? > The camera works well since in my desktop PC just works with the same > code compiled at the Beagle. > Could it be a matter of the ARM processor clock frequency? Beagle > features ARM TI AM335x at 1GHz I do not know. Alan Stern
Re: Error reading USB camera in BeagleBone with ARM Debian
On Fri, Oct 19, 2018 at 06:31:15PM +0200, Josep M. Mirats Tur wrote: > Bin, > > I'm sorry but I cannot find that menuconfig at the Beagle... Never mind, but add the following to your UBoot bootargs env instead to disable dma. musb_hdrc.use_dma=0 Regards, -Bin.
Re: Error reading USB camera in BeagleBone with ARM Debian
Bin,
I'm sorry but I cannot find that menuconfig at the Beagle...
Does this mean I need to compile and configure a new kernel from Debian sources?
On Fri, Oct 19, 2018 at 6:28 PM Bin Liu wrote:
>
> On Fri, Oct 19, 2018 at 06:17:31PM +0200, Josep M. Mirats Tur wrote:
> > Hi Bin,
> >
> > I was referring to the output of usbmon I attached in the previous
> > message (attached again)
> >
> > I'm sorry but I do not know how to acces the kernel menuconfig to
> > disable the MUSB CPPI DMA, how should I do that?
>
> In kernel menuconfig, go to
>
> Device Drivers --->
> [*] USB support --->
>Inventra Highspeed Dual Role Controller (TI, ADI, AW,
> ...)
> ...
> TI DSPS platforms
> *** MUSB DMA mode ***
> [*] Disable DMA (always use PIO)
>
> Please ensure the last option ("Disable DMA") is checked.
>
> Regards,
> -Bin.
Re: Error reading USB camera in BeagleBone with ARM Debian
On Fri, Oct 19, 2018 at 06:17:31PM +0200, Josep M. Mirats Tur wrote:
> Hi Bin,
>
> I was referring to the output of usbmon I attached in the previous
> message (attached again)
>
> I'm sorry but I do not know how to acces the kernel menuconfig to
> disable the MUSB CPPI DMA, how should I do that?
In kernel menuconfig, go to
Device Drivers --->
[*] USB support --->
Inventra Highspeed Dual Role Controller (TI, ADI, AW, ...)
...
TI DSPS platforms
*** MUSB DMA mode ***
[*] Disable DMA (always use PIO)
Please ensure the last option ("Disable DMA") is checked.
Regards,
-Bin.
Re: Error reading USB camera in BeagleBone with ARM Debian
Thanks Alan, So, what might be the cause for those transfers that have less data than expected? The camera works well since in my desktop PC just works with the same code compiled at the Beagle. Could it be a matter of the ARM processor clock frequency? Beagle features ARM TI AM335x at 1GHz Josep M. On Fri, Oct 19, 2018 at 6:15 PM Alan Stern wrote: > > On Fri, 19 Oct 2018, Josep M. Mirats Tur wrote: > > > Hi, > > > > Thanks again for your answer. > > > > I changed to the newest Debian image available for BeagleBone boards: > > The Debian 9.5 - 4.14.71-ti-r80 > > I disabled the usb "autosuspend" by issuing the command > > echo -1 | sudo tee /sys/module/usbcore/parameters/autosuspend > > > > I cannot say if now there is data coming from the USB as I cannot > > understand the output > > But I still get errors from the driver when I check the dmesg: > > > > [ 6340.997467] usb 1-1: usbfs: usb_submit_urb returned -121 > > [ 6341.198347] usb 1-1: usbfs: usb_submit_urb returned -121 > > [ 6342.299444] usb 1-1: usbfs: usb_submit_urb returned -121 > > [ 6343.867458] usb 1-1: usbfs: usb_submit_urb returned -121 > > [ 6344.168455] usb 1-1: usbfs: usb_submit_urb returned -121 > > [ 6596.714269] musb_host_rx 1965: Rx interrupt with no errors or packet! > > [ 6596.720873] musb_host_rx 1965: Rx interrupt with no errors or packet! > > [ 6596.728656] musb_ep_program 916: broken !rx_reinit, ep2 csr 0003 > > Your program expects to transfer information from the camera in chunks > of size 20 KB, right? Those -121 errors indicate times when the amount > of data received was less than that. For example, sometimes the camera > only sent 8836 bytes, or 4228, or 14468, or 11396. At least, that's > what the BeagleBone thinks it received. > > Alan Stern > > > Let see if this info suggests you or Bin any actions to check > > Many thanks again > > Josep M. > > > > On Fri, Oct 19, 2018 at 4:24 PM Alan Stern > > wrote: > > > > > > On Fri, 19 Oct 2018, Josep M. Mirats Tur wrote: > > > > > > > Hi Stern, > > > > > > > > > First question: Does you get similar failures if you plug the device > > > > > into a standard PC rather than the BeagleBone? > > > > > > > > > > > > > No, I checked with my desktop PC running Ubuntu 14.04 and it perfectly > > > > works (using exactly the same code I compile in the Beagle) > > > > > > > > > Second question: Have you tried looking at usbmon traces to see where > > > > > the communication starts to fail? > > > > > > > > > > > > > II tried now, I'm attaching the trace I get, which I cannot understand > > > > > > The usbmon trace shows a few errors in the musb-hdrc driver. Here are > > > the relevant parts: > > > > > > dcf40b00 1096317503 S Ci:1:001:0 s a3 00 0001 0004 4 < > > > dcf40b00 1096317572 C Ci:1:001:0 0 4 = 05010100 > > > > > > This shows the system polling the root-hub port status. The return > > > value indicates that the camera was just plugged into the port, but it > > > also shows that the port is suspended, which makes no sense. The > > > suspend bit remains set in later port-status queries. > > > > > > dcf39600 1096487577 S Co:1:001:0 s 23 03 0004 0001 0 > > > dcf39600 1096487621 C Co:1:001:0 0 0 > > > dce0ac80 1096537473 C Ii:1:001:1 0:2048 1 = 02 > > > dce0ac80 1096537498 S Ii:1:001:1 -115:2048 4 < > > > dcf39600 1096547461 S Ci:1:001:0 s a3 00 0001 0004 4 < > > > dcf39600 1096547507 C Ci:1:001:0 0 4 = 07051200 > > > > > > The shows the system telling the root hub to reset port 1. When the > > > reset is finished, the status shows a reset-status change (which is > > > correct) together with an enable-status change (which is wrong). (It > > > also still shows that the port is suspended!) > > > > > > dcfc0b00 1096767206 S Ci:1:001:0 s a3 00 0001 0004 4 < > > > dcfc0b00 1096767285 C Ci:1:001:0 0 4 = 07050200 > > > > > > Following the enumeration of the USB camera, the system again checks > > > the port status. The value shows an enable-status change, which is > > > supposed to mean that the port has been disabled. But the port has not > > > been disabled, as we can see from the fact that the enable-status bit > > > is also set. > > > > > > The trace ends at this point. It does not show any communication > > > failures like what you described in the original email message. > > > > > > > > > Should I load different usb modules in the system kernel? Should I > > > > > > modify a given module? > > > > > > > > > > It certainly looks like a problem in the musb-hdrc driver. You might > > > > > try asking the maintainer for that driver. > > > > > > > > Ok, could you please provide me the e-mail address where to write? > > > > > > The maintainer is Bin Liu (CC'ed). And you should also remember to CC > > > the linux-usb mailing list. > > > > > > Alan Stern > > > > > > > Thanks > > > > > > > > > > > > On Thu, Oct 18, 2018 at 9:44 PM Alan Stern > > > > wrote: > > > > > > > > > > On Thu, 18 Oct 2018, Josep M. Mirats Tur wrote: > > > > > > > > > > > Hi > > > > > >
Re: Error reading USB camera in BeagleBone with ARM Debian
On Fri, 19 Oct 2018, Josep M. Mirats Tur wrote: > Hi, > > Thanks again for your answer. > > I changed to the newest Debian image available for BeagleBone boards: > The Debian 9.5 - 4.14.71-ti-r80 > I disabled the usb "autosuspend" by issuing the command > echo -1 | sudo tee /sys/module/usbcore/parameters/autosuspend > > I cannot say if now there is data coming from the USB as I cannot > understand the output > But I still get errors from the driver when I check the dmesg: > > [ 6340.997467] usb 1-1: usbfs: usb_submit_urb returned -121 > [ 6341.198347] usb 1-1: usbfs: usb_submit_urb returned -121 > [ 6342.299444] usb 1-1: usbfs: usb_submit_urb returned -121 > [ 6343.867458] usb 1-1: usbfs: usb_submit_urb returned -121 > [ 6344.168455] usb 1-1: usbfs: usb_submit_urb returned -121 > [ 6596.714269] musb_host_rx 1965: Rx interrupt with no errors or packet! > [ 6596.720873] musb_host_rx 1965: Rx interrupt with no errors or packet! > [ 6596.728656] musb_ep_program 916: broken !rx_reinit, ep2 csr 0003 Your program expects to transfer information from the camera in chunks of size 20 KB, right? Those -121 errors indicate times when the amount of data received was less than that. For example, sometimes the camera only sent 8836 bytes, or 4228, or 14468, or 11396. At least, that's what the BeagleBone thinks it received. Alan Stern > Let see if this info suggests you or Bin any actions to check > Many thanks again > Josep M. > > On Fri, Oct 19, 2018 at 4:24 PM Alan Stern wrote: > > > > On Fri, 19 Oct 2018, Josep M. Mirats Tur wrote: > > > > > Hi Stern, > > > > > > > First question: Does you get similar failures if you plug the device > > > > into a standard PC rather than the BeagleBone? > > > > > > > > > > No, I checked with my desktop PC running Ubuntu 14.04 and it perfectly > > > works (using exactly the same code I compile in the Beagle) > > > > > > > Second question: Have you tried looking at usbmon traces to see where > > > > the communication starts to fail? > > > > > > > > > > II tried now, I'm attaching the trace I get, which I cannot understand > > > > The usbmon trace shows a few errors in the musb-hdrc driver. Here are > > the relevant parts: > > > > dcf40b00 1096317503 S Ci:1:001:0 s a3 00 0001 0004 4 < > > dcf40b00 1096317572 C Ci:1:001:0 0 4 = 05010100 > > > > This shows the system polling the root-hub port status. The return > > value indicates that the camera was just plugged into the port, but it > > also shows that the port is suspended, which makes no sense. The > > suspend bit remains set in later port-status queries. > > > > dcf39600 1096487577 S Co:1:001:0 s 23 03 0004 0001 0 > > dcf39600 1096487621 C Co:1:001:0 0 0 > > dce0ac80 1096537473 C Ii:1:001:1 0:2048 1 = 02 > > dce0ac80 1096537498 S Ii:1:001:1 -115:2048 4 < > > dcf39600 1096547461 S Ci:1:001:0 s a3 00 0001 0004 4 < > > dcf39600 1096547507 C Ci:1:001:0 0 4 = 07051200 > > > > The shows the system telling the root hub to reset port 1. When the > > reset is finished, the status shows a reset-status change (which is > > correct) together with an enable-status change (which is wrong). (It > > also still shows that the port is suspended!) > > > > dcfc0b00 1096767206 S Ci:1:001:0 s a3 00 0001 0004 4 < > > dcfc0b00 1096767285 C Ci:1:001:0 0 4 = 07050200 > > > > Following the enumeration of the USB camera, the system again checks > > the port status. The value shows an enable-status change, which is > > supposed to mean that the port has been disabled. But the port has not > > been disabled, as we can see from the fact that the enable-status bit > > is also set. > > > > The trace ends at this point. It does not show any communication > > failures like what you described in the original email message. > > > > > > > Should I load different usb modules in the system kernel? Should I > > > > > modify a given module? > > > > > > > > It certainly looks like a problem in the musb-hdrc driver. You might > > > > try asking the maintainer for that driver. > > > > > > Ok, could you please provide me the e-mail address where to write? > > > > The maintainer is Bin Liu (CC'ed). And you should also remember to CC > > the linux-usb mailing list. > > > > Alan Stern > > > > > Thanks > > > > > > > > > On Thu, Oct 18, 2018 at 9:44 PM Alan Stern > > > wrote: > > > > > > > > On Thu, 18 Oct 2018, Josep M. Mirats Tur wrote: > > > > > > > > > Hi > > > > > > > > > > I've recently acquired a BeagleBone Green with AM335x processor. I 'm > > > > > connecting a USB device (actually a 3D camera from ORBBEC) to the > > > > > Beagle USB host port. It recognizes well as I can see at the dmesg > > > > > output: > > > > > > > > > > [12411.643517] usb 1-1: new high-speed USB device number 2 using > > > > > musb-hdrc > > > > > [12411.784848] usb 1-1: New USB device found, idVendor=2bc5, > > > > > idProduct=0404 > > > > > [12411.784912] usb 1-1: New USB device strings: Mfr=1, Product=2, > > > > > SerialNumber=0 > > > > >
Re: Error reading USB camera in BeagleBone with ARM Debian
Hi, On Fri, Oct 19, 2018 at 05:35:29PM +0200, Josep M. Mirats Tur wrote: > Hi, > > Thanks again for your answer. > > I changed to the newest Debian image available for BeagleBone boards: > The Debian 9.5 - 4.14.71-ti-r80 > I disabled the usb "autosuspend" by issuing the command > echo -1 | sudo tee /sys/module/usbcore/parameters/autosuspend > > I cannot say if now there is data coming from the USB as I cannot > understand the output what output? > But I still get errors from the driver when I check the dmesg: > > [ 6340.997467] usb 1-1: usbfs: usb_submit_urb returned -121 > [ 6341.198347] usb 1-1: usbfs: usb_submit_urb returned -121 > [ 6342.299444] usb 1-1: usbfs: usb_submit_urb returned -121 > [ 6343.867458] usb 1-1: usbfs: usb_submit_urb returned -121 > [ 6344.168455] usb 1-1: usbfs: usb_submit_urb returned -121 > [ 6596.714269] musb_host_rx 1965: Rx interrupt with no errors or packet! > [ 6596.720873] musb_host_rx 1965: Rx interrupt with no errors or packet! This message means RX EP interrupt happens, but the RX FIFO has no data. I don't have any case showing this problem before, so not sure what causes the problem. Can you please try to disable MUSB CPPI DMA to see how it goes? You can disable it in kernel menuconfig. Regards, -Bin.
Re: Error reading USB camera in BeagleBone with ARM Debian
On Fri, 19 Oct 2018, Josep M. Mirats Tur wrote: > Hi Stern, > > > First question: Does you get similar failures if you plug the device > > into a standard PC rather than the BeagleBone? > > > > No, I checked with my desktop PC running Ubuntu 14.04 and it perfectly > works (using exactly the same code I compile in the Beagle) > > > Second question: Have you tried looking at usbmon traces to see where > > the communication starts to fail? > > > > II tried now, I'm attaching the trace I get, which I cannot understand The usbmon trace shows a few errors in the musb-hdrc driver. Here are the relevant parts: dcf40b00 1096317503 S Ci:1:001:0 s a3 00 0001 0004 4 < dcf40b00 1096317572 C Ci:1:001:0 0 4 = 05010100 This shows the system polling the root-hub port status. The return value indicates that the camera was just plugged into the port, but it also shows that the port is suspended, which makes no sense. The suspend bit remains set in later port-status queries. dcf39600 1096487577 S Co:1:001:0 s 23 03 0004 0001 0 dcf39600 1096487621 C Co:1:001:0 0 0 dce0ac80 1096537473 C Ii:1:001:1 0:2048 1 = 02 dce0ac80 1096537498 S Ii:1:001:1 -115:2048 4 < dcf39600 1096547461 S Ci:1:001:0 s a3 00 0001 0004 4 < dcf39600 1096547507 C Ci:1:001:0 0 4 = 07051200 The shows the system telling the root hub to reset port 1. When the reset is finished, the status shows a reset-status change (which is correct) together with an enable-status change (which is wrong). (It also still shows that the port is suspended!) dcfc0b00 1096767206 S Ci:1:001:0 s a3 00 0001 0004 4 < dcfc0b00 1096767285 C Ci:1:001:0 0 4 = 07050200 Following the enumeration of the USB camera, the system again checks the port status. The value shows an enable-status change, which is supposed to mean that the port has been disabled. But the port has not been disabled, as we can see from the fact that the enable-status bit is also set. The trace ends at this point. It does not show any communication failures like what you described in the original email message. > > > Should I load different usb modules in the system kernel? Should I > > > modify a given module? > > > > It certainly looks like a problem in the musb-hdrc driver. You might > > try asking the maintainer for that driver. > > Ok, could you please provide me the e-mail address where to write? The maintainer is Bin Liu (CC'ed). And you should also remember to CC the linux-usb mailing list. Alan Stern > Thanks > > > On Thu, Oct 18, 2018 at 9:44 PM Alan Stern wrote: > > > > On Thu, 18 Oct 2018, Josep M. Mirats Tur wrote: > > > > > Hi > > > > > > I've recently acquired a BeagleBone Green with AM335x processor. I 'm > > > connecting a USB device (actually a 3D camera from ORBBEC) to the > > > Beagle USB host port. It recognizes well as I can see at the dmesg > > > output: > > > > > > [12411.643517] usb 1-1: new high-speed USB device number 2 using musb-hdrc > > > [12411.784848] usb 1-1: New USB device found, idVendor=2bc5, > > > idProduct=0404 > > > [12411.784912] usb 1-1: New USB device strings: Mfr=1, Product=2, > > > SerialNumber=0 > > > [12411.784951] usb 1-1: Product: ORBBEC Depth Sensor > > > [12411.784986] usb 1-1: Manufacturer: Orbbec(R) > > > > > > However, when I try to read data from the camera using the OpenNi SDK > > > that ORBBEC provides for Arm devices, although I can connect to the > > > camera (in fact it toggles on the IR) I get a timeout and get no data > > > ever. The 'dmesg' output show the errors: > > > > > > [12446.755020] usb 1-1: usbfs: usb_submit_urb returned -121 > > > > > > Other users seemed to have this problem in the past, and it seems > > > related to the EHCI driver itself, > > > > The log message above indicates that the BeagleBone's USB host > > controller uses the musb-hdrc driver. This means it is not EHCI. > > > > > but I've not been able to find a > > > solution and need help urgently to solve this issue. > > > > > > The system version in my BeagleBoneGreen is Debian Debian 8.3 > > > (4.1.15-ti-rt-r43). In fact I've tested several versions including the > > > newest one available for BeagleBone (the debian 9.5 - 4.14.71-ti-r80), > > > but without success. In this case I got a different error from dmesg: > > > > > > Oct 17 16:59:29 arm kernel: [ 215.611056] musb_host_rx 1965: Rx > > > interrupt with no errors or packet! > > > Oct 17 16:59:29 arm kernel: [ 215.617649] musb_host_rx 1965: Rx > > > interrupt with no errors or packet! > > > Oct 17 16:59:29 arm kernel: [ 215.625557] musb_ep_program 916: broken > > > !rx_reinit, ep2 csr 0003 > > > > > > > > > Please I need some clues about this. > > > > First question: Does you get similar failures if you plug the device > > into a standard PC rather than the BeagleBone? > > > > Second question: Have you tried looking at usbmon traces to see where > > the communication starts to fail? > > > > > Should I load different usb modules in the system kernel? Should I > > > modify a
Re: USB hotplug on HP 255 G6 laptop
On Tue 16-10-18 17:47:17, Mathias Nyman wrote:
> On 16.10.2018 14:38, Jan Kara wrote:
> > On Wed 03-10-18 16:46:05, Jan Kara wrote:
> > > On Wed 03-10-18 17:19:33, Mathias Nyman wrote:
> > > > On 02.10.2018 17:53, Jan Kara wrote:
> > > > > On Tue 02-10-18 17:01:54, Mathias Nyman wrote:
> > > > > > On 02.10.2018 16:06, Jan Kara wrote:
> > > > > > > Hello,
> > > > > > >
> > > > > > > my wife has HP 255 G6 laptop. When it is attached to AC,
> > > > > > > everything works
> > > > > > > as expected however when it is running on battery, USB hotplug
> > > > > > > stops
> > > > > > > working - newly plugged devices do not appear to be visible to
> > > > > > > the kernel.
> > > > > > > Only when the AC is plugged back in, the kernel suddently wakes
> > > > > > > up and
> > > > > > > detects all newly attached devices. Maybe it is related to some
> > > > > > > power
> > > > > > > management? Any idea how to debug this? Dmesg from the system is
> > > > > > > attached.
> > > > > > > The kernels I've tested with (both behave the same way) are
> > > > > > > 4.18.11 kernel
> > > > > > > and also openSUSE Leap 15 kernel which is 4.12-based. Thanks in
> > > > > > > advance for
> > > > > > > any help.
> > > > > > >
> > > > > >
> > > > > > Are you running laptop mode tools or similar that would enable
> > > > > > runtime suspend
> > > > > > D3 state for xhci controller?
> > > > >
> > > > > It is openSUSE Leap 15 installation with xfce4 desktop so I assume
> > > > > there is
> > > > > some power-management going on. Not sure what I should look for but
> > > > > there's
> > > > > xfce4-power-manager running, also upowerd is running.
> > > > >
> > > > > > what does lspci -vv say?
> > > > >
> > > > > Attached.
> > > > >
> > > > > > check the content of the following files while running on battery:
> > > > > >
> > > > > > cat /sys/bus/pci/devices/:00:10.0/firmware_node/power_state
> > > > >
> > > > > D0
> > > > >
> > > > > > cat /sys/bus/pci/devices/:00:10.0/power/control
> > > > >
> > > > > auto - when on battery, on - when on AC.
> > > > >
> > > > > > try: echo on > /sys/bus/pci/devices/:00:10.0/power/control
> > > > > > before pluggin in a usb device, does it help?
> > > > >
> > > > > Yes, USB device gets recognized after this.
> > > > >
> > > >
> > > > To me this looks like xhci is runtime suspended, but controller is still
> > > > in a PCI D0 state.
> > > >
> > > > Normally the xHC should be put to PCI D3 in runtime suspend, and woken
> > > > up by a PCI PME# when a device is plugged in, but PME# is not enabled in
> > > > D0 so in this case nothing wakes up the xHC.
> > > >
> > > > The xhci runtime suspend code already stopped the controller, so
> > > > probably
> > > > you're not getting an interrupt either.
> > > >
> > > > PCI code looks at firmware ACPI tables to choose the suspend D state, if
> > > > something is off in the tables it's possible the wrong state is chosen.
> > > > worth checking.
> > > >
> > > > Could you dump the DSDT ACPI table form /sys/firmware/acpi/tables/DSDT
> > >
> > > Sure. Attached.
> > >
> > > > As a quick temporary workaround you could find and prevent the
> > > > powersaving program from enabling runtime suspend. (make sure it won't
> > > > write "auto" to /sys/bus/pci/devices/:00:10.0/power/control)
> > >
> > > OK, thanks for the hint.
> >
> > Any news here? Are really ACPI tables wrong on this laptop?
> >
>
> Can't say for sure
>
> There might be differences how Windows and Linux parse ACPI tables.
>
> If _PR0 or _PS0 is present for a device in ACPI tables then Linux will
> assume the device is ACPI power manageable, and select PCI D states from ACPI
> tables.
>
> _S3W should return the highest D-value (deepest sleep state) device can wake
> up from S3 (system suspend)
> _S0W should return the highest D-value (deepest sleep state) device can wake
> up from S0 (Runtime suspend)
>
> Your ACPI DSDT table shows:
>
> Scope (_SB.PCI0.XHC0)
> {
> Name (_PR0, Package (0x01) // _PR0: Power Resources for D0
> {
> P0U3
> })
> Name (_PR3, Package (0x01) // _PR3: Power Resources for D3hot
> {
> P3U3
> })
> Method (_S0W, 0, NotSerialized) // _S0W: S0 Device Wake State
> {
> If ((XHCD == One))
> {
> Return (0x04)
> }
> Else
> {
> Return (Zero)
> }
> }
>
> Method (_S3W, 0, NotSerialized) // _S3W: S3 Device Wake State
> {
> Return (0x04)
> }
>
>
> Those with better APCI and PCI knowledge might know more details, or better
> debugging for this,
> but it at least would be possible to check which D state is chosen by adding
> the below code,
> and recompiling the kernel:
Thanks for the patch and suggestiong. As expected this hack has fixed the
problem with the USB on that laptop. The messages in
