[Bug 255759] [Patch] Add USB product ID for ASUS USB-N14 Wireless Adaptor
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255759 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|u...@freebsd.org Component|kern|usb Keywords|patch | --- Comment #1 from Mark Linimon --- ^Triage: assign to correct mailing list. ^Triage: note that the "patch" keyword is obsolete (now inferred from attachment metadata). -- You are receiving this mail because: You are the assignee for the bug. ___ 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"
[Bug 255780] USB timeout when using BladeRF 2.0 A9
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255780 Hans Petter Selasky changed: What|Removed |Added CC||hsela...@freebsd.org --- Comment #2 from Hans Petter Selasky --- Hi, usbdump -i usbusX -f Y -s65536 -vvv might sched more light into this. Can be started before you plug the device. X.Y are numbers after ugen. --HPS -- You are receiving this mail because: You are the assignee for the bug. ___ 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: Flickering connection to UPS (again, but now I'm sure it is Ok under Windows)
On 09.05.2021 21:51, Hans Petter Selasky wrote: Could you do: usbdump -i usbusX -f Y -s 65536 -vvv Where X.Y are the numbers after ugen for this device. Are you certain that NUT only execute exactly the same commands like the windows tool for this UPS? Does apcupsd work for this device too? I've never used NUT myself. Ok, results are encouraging: If NUT's (user-mode) driver starts fast enough to detect UPS, UPS stops to disconnect and works! After that, NUT could be stopped and/or restarted, but UPS remains connected. It is almost impossible to achieve with running NUT on startup (as UPS flickering from system power-up and there is no guarantee, that startup scripts will run in proper moment). Even `devd` could be not fast enough :-( Traffic received with usbdump is here: http://lev.serebryakov.spb.ru/_sklad/ups/ups-freebsd-with-nut-no-flickr-usbdump.txt Looks like, I need small kernel-level driver which "prime" HID UPSes on connect with pre-canned requests to stop them from disconnect. -- // Lev Serebryakov ___ 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: Flickering connection to UPS (again, but now I'm sure it is Ok under Windows)
On 09.05.2021 21:51, Hans Petter Selasky wrote: [I'M ANSWERING TO BOTH MESSAGES IN THIS ONE] Could you do: usbdump -i usbusX -f Y -s 65536 -vvv Where X.Y are the numbers after ugen for this device. I'll do ASAP and return with results, but see below. Are you certain that NUT only execute exactly the same commands like the windows tool for this UPS? Of course, not! I'm sure, it is other sequence of commands at least, as NUT has generic driver for many UPSes which share one protocol, and it it not replication of Windows software. Does apcupsd work for this device too? I've never used NUT myself. Nope, it is another (not APC-compatible) protocol. > Then connect the device and run nut. nut is very slow in detecting UPSes and it can not "wait" for device to connect, so it simply can not find compatible device, as it is disconnected already. Maybe, I'll be lucky and will be able to "catch" long enough connection for nut to detect UPS and request information at leas one time. > If you don't run nut, does the same attach/detach happen? Oh. Looks like here is miscommunication. attach/detach happens WITHOUT nut on FreeBSD. But it DOESN'T even when software IS NOT installed on Windows. So: (1) Windows WITHOUT Vendor-provided software: NO DETACH, "solid" connection. (2) Windows WITH Vendor-provided software: NO DETACH, "solid" connection. (3) FreeBSD WITHOUT nut: DETACH and re-attech in the loop. (4) FreeBSD WITH nut: try to catch this combination, but it is not-trivial and fragile, not usable in production now, as UPS have detached itself before nut could start typically. -- // Lev Serebryakov ___ 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"
[Bug 255780] USB timeout when using BladeRF 2.0 A9
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255780 Konrad Jopek changed: What|Removed |Added Summary|USB timeout |USB timeout when using ||BladeRF 2.0 A9 -- You are receiving this mail because: You are the assignee for the bug. ___ 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"
[Bug 255780] USB timeout
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255780
--- Comment #1 from Konrad Jopek ---
When using BladeRF 2.0 A9 I noticed this issue:
[ERROR @ host/libraries/libbladeRF/src/board/bladerf2/bladerf2.c:123]
_bladerf2_initialize: dev->backend->get_fpga_version(dev,
&board_data->fpga_version) failed: Operation timed out
[ERROR @ host/libraries/libbladeRF/src/board/bladerf2/bladerf2.c:2186]
bladerf2_load_fpga: _bladerf2_initialize(dev) failed: Operation timed out
Here are the stats for USB device:
ugen4.2: at usbus4, cfg=0 md=HOST spd=SUPER (5.0Gbps)
pwr=ON (200mA)
{
UE_CONTROL_OK : 518
UE_ISOCHRONOUS_OK : 0
UE_BULK_OK : 2574
UE_INTERRUPT_OK : 0
UE_CONTROL_FAIL : 0
UE_ISOCHRONOUS_FAIL : 0
UE_BULK_FAIL: 26
UE_INTERRUPT_FAIL : 0
}
Not sure what happens, this may be a problem at USB 3.0 stack. However, looks
like at some point bulk transfers are failing.
Please let me know if you need more debug data.
--
You are receiving this mail because:
You are the assignee for the bug.
___
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"
[Bug 255780] USB timeout
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255780 Bug ID: 255780 Summary: USB timeout Product: Base System Version: CURRENT Hardware: arm64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: usb Assignee: u...@freebsd.org Reporter: kjo...@gmail.com -- You are receiving this mail because: You are the assignee for the bug. ___ 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"
