Date: Fri, 17 Apr 2020 21:24:10 +0200 From: Hans Petter Selasky <hps@selasky.org> To: lev@FreeBSD.org, usb@freebsd.org Subject: =?UTF-8?Q?Re=3a_Cheap_UPS_with_USB_=c2=abflicker=c2=bb_with_FreeBSD?= =?UTF-8?Q?_but_not_with_Windows?= Message-ID: <6ce319aa-934a-cd26-ce79-74c192020e11@selasky.org> In-Reply-To: <b63c055b-763d-e8f5-355a-fe7917cc714c@FreeBSD.org> References: <a97d989e-fb7e-b365-458c-c12e2c161a62@FreeBSD.org> <4a0271c4-edf8-909f-c8d1-894323d1c8d5@selasky.org> <5b87bfd2-55c1-5281-b964-47dfea8c48cb@FreeBSD.org> <408f99ba-bbf9-2273-4caa-281ab96f4a91@selasky.org> <2a570645-70c4-7ead-1e7b-fd3e5b8c10cb@FreeBSD.org> <343a0da8-d1ed-dcb5-3854-042d6065771e@selasky.org> <b63c055b-763d-e8f5-355a-fe7917cc714c@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2020-04-17 20:37, Lev Serebryakov wrote: > On 17.04.2020 18:38, Hans Petter Selasky wrote: > >> Maybe the kernel was compiles w/o: >> >> options USB_DEBUG > Yep. I have kernel with this option now, and debug shows that each disconnection looks like this (there are one successful explore cycle and one which triggers disconnection): > > Apr 17 21:31:48 gateway kernel: usb_needs_explore: > Apr 17 21:31:48 gateway kernel: usb_bus_powerd: bus=0xfffffe00322b2cd8 > Apr 17 21:31:48 gateway kernel: usb_bus_powerd: Recomputing power masks > Apr 17 21:31:48 gateway kernel: uhub_explore: udev=0xfffff80006c35000 addr=1 > Apr 17 21:31:48 gateway kernel: uhub_read_port_status: port 1, wPortStatus=0x0500, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION > Apr 17 21:31:48 gateway kernel: uhub_read_port_status: port 2, wPortStatus=0x0500, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION > Apr 17 21:31:48 gateway kernel: uhub_read_port_status: port 3, wPortStatus=0x0500, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION > Apr 17 21:31:48 gateway kernel: uhub_read_port_status: port 4, wPortStatus=0x0500, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION > Apr 17 21:31:48 gateway kernel: uhub_read_port_status: port 5, wPortStatus=0x0500, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION > Apr 17 21:31:48 gateway kernel: uhub_read_port_status: port 6, wPortStatus=0x0500, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION > Apr 17 21:31:48 gateway kernel: uhub_read_port_status: port 7, wPortStatus=0x0500, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION > Apr 17 21:31:48 gateway kernel: uhub_read_port_status: port 8, wPortStatus=0x0500, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION > Apr 17 21:31:49 gateway kernel: usb_needs_explore: > Apr 17 21:31:49 gateway kernel: usb_bus_powerd: bus=0xfffffe0031f7edb0 > Apr 17 21:31:49 gateway kernel: usb_bus_powerd: Recomputing power masks > Apr 17 21:31:49 gateway kernel: uhub_explore: udev=0xfffff80006c29000 addr=1 > Apr 17 21:31:49 gateway kernel: uhub_read_port_status: port 1, wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION > Apr 17 21:31:49 gateway kernel: uhub_read_port_status: port 2, wPortStatus=0x0100, wPortChange=0x0003, err=USB_ERR_NORMAL_COMPLETION > Apr 17 21:31:49 gateway kernel: uhub_reattach_port: reattaching port 2 > Apr 17 21:31:49 gateway kernel: ugen2.2: <PPC Offline UPS> at usbus2 (disconnected) > Hi, These two bits mean (Refer to 11.24.2.7.2 Port Status Change Bits in USB20 specification): > Connect Status Change: (C_PORT_CONNECTION) Indicates a change has occurred in the port’s Current Connect Status. > > The hub device sets this field as described in Section 11.24.2.7.2.1. > 0 = No change has occurred to Current Connect status. > 1 = Current Connect status has changed. > > Port Enable/Disable Change: (C_PORT_ENABLE) This field is set to one when a port is disabled because > of a Port_Error condition (see Section 11.8.1). > So the HUB (hardware device) reports that device is disconnected and the USB stack acts accordingly. Maybe there is a quirk you need for the hardware. Could check Linux sources for EHCI/XHCI/OHCI/UHCI. --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6ce319aa-934a-cd26-ce79-74c192020e11>