Re: strange USB timing issue with u3g
On 3/13/2019 11:46 AM, CeDeROM wrote: > Hey there! I also noticed problems with U3G module with my new Quectel > EC25E miniPCI-E module replaced the Sierra Wireless on my Panasonic > CF-C2 notebook.. sometimes (very very often) the /dev/cuaU* is not > created properly so PPP has nothing to connect to.. > > So I have to use simple usbconfig to reset devices at boot.. but that > also sometimes does not help as devices seems to have random order.. > and it causes problems with other devices that are already > attached/enumerated.. this is a bit unreliable.. > > I was wondering is there a problem with U3G module and how could I > quick fix it without the module rewrite? I am not sure its an actual problem with the u3g module per se. The error can happen with or without the u3g module loaded, so even as a ugen device, it will fail to attach. ---Mike > -- > --- > Mike Tancsa, tel +1 519 651 3400 x203 > Sentex Communications, m...@sentex.net > Providing Internet services since 1994 www.sentex.net > Cambridge, Ontario Canada ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: strange USB timing issue with u3g
Hey there! I also noticed problems with U3G module with my new Quectel EC25E miniPCI-E module replaced the Sierra Wireless on my Panasonic CF-C2 notebook.. sometimes (very very often) the /dev/cuaU* is not created properly so PPP has nothing to connect to.. So I have to use simple usbconfig to reset devices at boot.. but that also sometimes does not help as devices seems to have random order.. and it causes problems with other devices that are already attached/enumerated.. this is a bit unreliable.. I was wondering is there a problem with U3G module and how could I quick fix it without the module rewrite? Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: strange USB timing issue with u3g
On 3/13/2019 10:59 AM, Hans Petter Selasky wrote: > > Hi, > > Can you check if the auto-installer is enabled on your device or not? > HUAWEI should have some binaries for updating their dongles somewhere. > Last time I tried this I got the update from where I bought it. Though > it might require MacOS or Windows before it will install :-( > Auto install is not according to the AT commands. Note, this is a mini-pcie device, not an external USB adapter. Thanks for the suggestions! I will keep experimenting with the timings to see if I can find a reliable setting. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: strange USB timing issue with u3g
On 3/13/19 3:47 PM, Mike Tancsa wrote: On 3/12/2019 5:43 PM, Hans Petter Selasky wrote: On 3/12/19 9:49 PM, Mike Tancsa wrote: Hi, Maybe the device expects some kind of BIOS to enumerate it quickly and if not, goes into sleep mode. Try setting: hw.usb.ehci.no_hs=1 In /boot/loader.conf . Does this change anything? usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_IOERROR, ignored) usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_IOERROR, ignored) seems to reliably come up with this setting on when loading u3g out of loader.conf and letting devd do it later. The other variable that can trigger it is if I load a bunch of other klds like umodem, ucom,uplcom and uftdi. Hi, Can you check if the auto-installer is enabled on your device or not? Try Googling the AT-command to disable this. USB devices are not allowed to return with a STALL-PID on set-address messages, so this is violation of established USB standards. Maybe you need a USB wire-analyzer to nail this issue. There are a bunch of tunables for example: hw.usb.timings Although testing a bit with hw.usb.timings.extra_power_up_time=990 seems to make the error on dmesg just up come up at a different, later point. setting hw.usb.timings.port_powerup_delay=1000 does seem to help! At least I was able to boot up 50% of the time. Trying with 2000 however, does not seem to make it better. still 50/50 OK Which affect how the USB device is enumerated. Is your device running the latest firmware from HUAWEI? Not sure. I have never upgraded the firmware in these guys before. Manufacturer: Huawei Technologies Co., Ltd. Model: ME909u-523 Revision: 11.430.63.00.00 IMEI: x +GCAP: +CGSM Do you know of any references on how to do this ? Looking at the AT command manual HUAWEI should have some binaries for updating their dongles somewhere. Last time I tried this I got the update from where I bought it. Though it might require MacOS or Windows before it will install :-( AT^FOTADET OK ^FOTASTATE: 11 ^DEND: 1,33,IPV4 and tried again AT^FOTADET OK ^FOTASTATE: 11 ^FOTASTATE: 13,13 ^HCSQ: "LTE",50,41,94,10 ^HCSQ: "LTE",44,41,137,22 AT^FOTADLQ ^FOTADLQ: 1,"FIRMWARE1",0,0 I think 13 means "New version query failed" My guess is that I need to setup some specific APN data to talk to Huawei ? The modem is not specifically designed for the carrier, so I dont know if the carrier usually has stuff behind the scenes for such updates. Although the command AT^FWLOAD= This command is used to specify the upgrade type, transmit the upgrade file into the module using 1K-Xmodem, and start the upgrade. The following table lists the ports supported by the full and differential upgrades. So if I can find a firmware file, I can do an old school xmodem-1k upload. I will see if I can find one from Huawei. OK --HPS ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: strange USB timing issue with u3g
On 3/12/2019 5:43 PM, Hans Petter Selasky wrote: > On 3/12/19 9:49 PM, Mike Tancsa wrote: >> > > Hi, > > Maybe the device expects some kind of BIOS to enumerate it quickly and > if not, goes into sleep mode. > > Try setting: > hw.usb.ehci.no_hs=1 > > In /boot/loader.conf . > > Does this change anything? usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_IOERROR usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_IOERROR, ignored) usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_IOERROR, ignored) seems to reliably come up with this setting on when loading u3g out of loader.conf and letting devd do it later. The other variable that can trigger it is if I load a bunch of other klds like umodem, ucom,uplcom and uftdi. > > USB devices are not allowed to return with a STALL-PID on set-address > messages, so this is violation of established USB standards. Maybe you > need a USB wire-analyzer to nail this issue. > > There are a bunch of tunables for example: > hw.usb.timings Although testing a bit with hw.usb.timings.extra_power_up_time=990 seems to make the error on dmesg just up come up at a different, later point. setting hw.usb.timings.port_powerup_delay=1000 does seem to help! At least I was able to boot up 50% of the time. Trying with 2000 however, does not seem to make it better. still 50/50 > > Which affect how the USB device is enumerated. > > Is your device running the latest firmware from HUAWEI? Not sure. I have never upgraded the firmware in these guys before. Manufacturer: Huawei Technologies Co., Ltd. Model: ME909u-523 Revision: 11.430.63.00.00 IMEI: x +GCAP: +CGSM Do you know of any references on how to do this ? Looking at the AT command manual AT^FOTADET OK ^FOTASTATE: 11 ^DEND: 1,33,IPV4 and tried again AT^FOTADET OK ^FOTASTATE: 11 ^FOTASTATE: 13,13 ^HCSQ: "LTE",50,41,94,10 ^HCSQ: "LTE",44,41,137,22 AT^FOTADLQ ^FOTADLQ: 1,"FIRMWARE1",0,0 I think 13 means "New version query failed" My guess is that I need to setup some specific APN data to talk to Huawei ? The modem is not specifically designed for the carrier, so I dont know if the carrier usually has stuff behind the scenes for such updates. Although the command AT^FWLOAD= This command is used to specify the upgrade type, transmit the upgrade file into the module using 1K-Xmodem, and start the upgrade. The following table lists the ports supported by the full and differential upgrades. So if I can find a firmware file, I can do an old school xmodem-1k upload. I will see if I can find one from Huawei. > > --HPS > > -- --- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: strange USB timing issue with u3g
On 3/12/19 9:49 PM, Mike Tancsa wrote: I have a strange issue I started to see on RELENG11 and RELENG12 that I am not sure when it started or if its always been there. On an PCEngines APU3, with an LTE modem that works with the u3g driver, it will fail to attach if the box does not boot up fast enough. So I am guessing something gets messed up in initialization and timing ? e.g. in loader.conf I have autoboot_delay=2 dcons_load="YES" amdsbwd_load="YES" u3g_load="YES" beastie_disable="YES" comconsole_speed="115200" console="comconsole" #hw.usb.debug=1 If I pause at the boot or make the delay say 10 seconds, the device often errors out. The device normally looks like this ugen2.1: at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen1.1: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen0.1: <0x1022 XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA) ugen2.2: at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (100mA) ugen1.2: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (100mA) ugen2.3: at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (500mA) ugen2.3: at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (500mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x bDeviceSubClass = 0x bDeviceProtocol = 0x bMaxPacketSize0 = 0x0040 idVendor = 0x12d1 idProduct = 0x1573 bcdDevice = 0x0228 iManufacturer = 0x0002 iProduct = 0x0003 iSerialNumber = 0x0004 <0123456712ABCA17> bNumConfigurations = 0x0003 But about 50% of the time with a longer delay, at bootup time I get uhub4: 4 ports with 4 removable, self powered usb_alloc_device: set address 3 failed (USB_ERR_STALLED, ignored) usbd_setup_device_desc: getting device descriptor at addr 3 failed, USB_ERR_STALLED usbd_req_re_enumerate: addr=3, set address failed! (USB_ERR_STALLED, ignored) usbd_setup_device_desc: getting device descriptor at addr 3 failed, USB_ERR_STALLED usbd_req_re_enumerate: addr=3, set address failed! (USB_ERR_STALLED, ignored) usbd_setup_device_desc: getting device descriptor at addr 3 failed, USB_ERR_STALLED vs ugen0.1: <0x1022 XHCI root HUB> at usbus0 ugen1.1: at usbus1 ugen2.1: at usbus2 uhub0: <0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 uhub1: on usbus1 uhub2: on usbus2 mmcsd0: 4GB at mmc0 50.0MHz/4bit/65535-block Trying to mount root from ufs:/dev/mmcsd0s1a [ro]... uhub0: 4 ports with 4 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered Starting file system checks: /dev/mmcsd0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/mmcsd0s1a: clean, 386561 free (3113 frags, 47931 blocks, 0.1% fragmentation) ugen1.2: at usbus1 uhub3 on uhub1 uhub3: on usbus1 ugen2.2: at usbus2 uhub4 on uhub2 uhub4: on usbus2 /dev/mmcsd0s3: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/mmcsd0s3: clean, 2829 free (21 frags, 351 blocks, 0.7% fragmentation) /etc/rc: WARNING: hostid: unable to figure out a UUID from DMI data, generating a new one uhub3: 4 ports with 4 removable, self powered uhub4: 4 ports with 4 removable, self powered ugen2.3: at usbus2 u3g0 on uhub4 u3g0: on usbus2 u3g0: Found 5 ports. Enabling debug will make it fail. Any idea what it might be or how I can tweak it to it more reliably initializes ? I first start to notice it when I added a few more klds at boot time. This made the boot up process that much longer that I would run into this issue periodically. Hi, Maybe the device expects some kind of BIOS to enumerate it quickly and if not, goes into sleep mode. Try setting: hw.usb.ehci.no_hs=1 In /boot/loader.conf . Does this change anything? USB devices are not allowed to return with a STALL-PID on set-address messages, so this is violation of established USB standards. Maybe you need a USB wire-analyzer to nail this issue. There are a bunch of tunables for example: hw.usb.timings Which affect how the USB device is enumerated. Is your device running the latest firmware from HUAWEI? --HPS ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
strange USB timing issue with u3g
I have a strange issue I started to see on RELENG11 and RELENG12 that I am not sure when it started or if its always been there. On an PCEngines APU3, with an LTE modem that works with the u3g driver, it will fail to attach if the box does not boot up fast enough. So I am guessing something gets messed up in initialization and timing ? e.g. in loader.conf I have autoboot_delay=2 dcons_load="YES" amdsbwd_load="YES" u3g_load="YES" beastie_disable="YES" comconsole_speed="115200" console="comconsole" #hw.usb.debug=1 If I pause at the boot or make the delay say 10 seconds, the device often errors out. The device normally looks like this ugen2.1: at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen1.1: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA) ugen0.1: <0x1022 XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA) ugen2.2: at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (100mA) ugen1.2: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (100mA) ugen2.3: at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (500mA) ugen2.3: at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (500mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x bDeviceSubClass = 0x bDeviceProtocol = 0x bMaxPacketSize0 = 0x0040 idVendor = 0x12d1 idProduct = 0x1573 bcdDevice = 0x0228 iManufacturer = 0x0002 iProduct = 0x0003 iSerialNumber = 0x0004 <0123456712ABCA17> bNumConfigurations = 0x0003 But about 50% of the time with a longer delay, at bootup time I get uhub4: 4 ports with 4 removable, self powered usb_alloc_device: set address 3 failed (USB_ERR_STALLED, ignored) usbd_setup_device_desc: getting device descriptor at addr 3 failed, USB_ERR_STALLED usbd_req_re_enumerate: addr=3, set address failed! (USB_ERR_STALLED, ignored) usbd_setup_device_desc: getting device descriptor at addr 3 failed, USB_ERR_STALLED usbd_req_re_enumerate: addr=3, set address failed! (USB_ERR_STALLED, ignored) usbd_setup_device_desc: getting device descriptor at addr 3 failed, USB_ERR_STALLED vs ugen0.1: <0x1022 XHCI root HUB> at usbus0 ugen1.1: at usbus1 ugen2.1: at usbus2 uhub0: <0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 uhub1: on usbus1 uhub2: on usbus2 mmcsd0: 4GB at mmc0 50.0MHz/4bit/65535-block Trying to mount root from ufs:/dev/mmcsd0s1a [ro]... uhub0: 4 ports with 4 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered Starting file system checks: /dev/mmcsd0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/mmcsd0s1a: clean, 386561 free (3113 frags, 47931 blocks, 0.1% fragmentation) ugen1.2: at usbus1 uhub3 on uhub1 uhub3: on usbus1 ugen2.2: at usbus2 uhub4 on uhub2 uhub4: on usbus2 /dev/mmcsd0s3: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/mmcsd0s3: clean, 2829 free (21 frags, 351 blocks, 0.7% fragmentation) /etc/rc: WARNING: hostid: unable to figure out a UUID from DMI data, generating a new one uhub3: 4 ports with 4 removable, self powered uhub4: 4 ports with 4 removable, self powered ugen2.3: at usbus2 u3g0 on uhub4 u3g0: on usbus2 u3g0: Found 5 ports. Enabling debug will make it fail. Any idea what it might be or how I can tweak it to it more reliably initializes ? I first start to notice it when I added a few more klds at boot time. This made the boot up process that much longer that I would run into this issue periodically. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 x203 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
