Re: USB trouble on Ryzen 3/AsRock mobo.

2020-02-09 Thread Bob Willcox
Hi Phil,

Did you ever determine the cause and solution to the USB_ERR_TIMEOUT errors
you were getting? I just installed a recent 12.1 snapshot on a system with a
Gigabyte GA-AB350N Ryzen motherboard and am seeing similar USB_ERR_TIMEOUT
errors with this MB.

The errors on this system appear to be continuing forever as they have been
going on for over 30 minutes so far with no end in sight. On this system the
initial dmesg messages for the usb errors looks strikingly similar to yours:

Feb  9 18:46:57 han kernel: xhci0: Resetting controller
Feb  9 18:46:57 han kernel: usb_alloc_device: set address 3 failed 
(USB_ERR_TIMEOUT, ignored)
Feb  9 18:46:57 han kernel: Root mount waiting for: usbus0
Feb  9 18:46:57 han syslogd: last message repeated 1 times
Feb  9 18:46:57 han kernel: usbd_setup_device_desc: getting device descriptor 
at addr 3 failed, USB_ERR_TIMEOUT
Feb  9 18:46:57 han kernel: Root mount waiting for: usbus0
Feb  9 18:46:57 han kernel: usbd_req_re_enumerate: addr=3, set address failed! 
(USB_ERR_TIMEOUT, ignored)
Feb  9 18:46:57 han kernel: Root mount waiting for: usbus0
Feb  9 18:46:57 han syslogd: last message repeated 1 times
Feb  9 18:46:57 han kernel: usbd_setup_device_desc: getting device descriptor 
at addr 3 failed, USB_ERR_TIMEOUT
Feb  9 18:46:57 han kernel: Root mount waiting for: usbus0
Feb  9 18:46:57 han kernel: usbd_req_re_enumerate: addr=3, set address failed! 
(USB_ERR_TIMEOUT, ignored)
Feb  9 18:46:57 han kernel: Root mount waiting for: usbus0
Feb  9 18:46:57 han syslogd: last message repeated 1 times
Feb  9 18:46:57 han kernel: usbd_setup_device_desc: getting device descriptor 
at addr 3 failed, USB_ERR_TIMEOUT
Feb  9 18:46:57 han kernel: Root mount waiting for: usbus0
Feb  9 18:46:57 han kernel: usbd_req_re_enumerate: addr=3, set address failed! 
(USB_ERR_TIMEOUT, ignored)
Feb  9 18:46:57 han kernel: Root mount waiting for: usbus0
Feb  9 18:46:57 han kernel: usbd_setup_device_desc: getting device descriptor 
at addr 3 failed, USB_ERR_TIMEOUT
Feb  9 18:46:57 han kernel: Root mount waiting for: usbus0
Feb  9 18:46:57 han syslogd: last message repeated 1 times
Feb  9 18:46:57 han kernel: usbd_req_re_enumerate: addr=3, set address failed! 
(USB_ERR_TIMEOUT, ignored)
Feb  9 18:46:57 han kernel: Root mount waiting for: usbus0

Anyone have any advice on what I can do the get this to stop? The system is
fundamentally unusable as it is.

Thanks,
Bob

On Tue, Jun 19, 2018 at 09:38:17PM +0200, Phil Norman wrote:
> Hi.
> 
> I've recently converted to FreeBSD, fleeing the Windowsification of Ubuntu.
> I've been having some trouble with the USB system, which seems strange as
> FreeBSD's USB stack is, according to a friend, rock solid. I'd like to
> narrow down if this is a hardware (CPU or mobo) or software issue.
> 
> I'm running a Ryzen 3 1200, plugged into a "Fatal1ty X370 Gaming-ITX/ac"
> motherboard (chosen because it supports ECC RAM and fits in an ITX case).
> 
> On a cold boot (ie starting by flipping the physical PSU power switch), BSD
> boots up nice and quickly, without errors, and then runs for days without a
> single USB-related error on dmesg. However, any other kind of reboot which
> doesn't interrupt the electricity supply yields a large number of USB
> errors (USB_ERR_TIMEOUTs every few seconds or so) and frequent resets of
> the xhci0 controller.
> 
> On occasion, I also get problems with my keyboard randomly stopping working
> (but then, if the USB subsystem is continuously resetting, that's only to
> be expected). I also seem to get slow USB storage device read throughput
> (2MB/s from a USB3 SSD), although I can't rule out that being caused by the
> fuse ext4fs driver.
> 
> Here's what I see in dmesg when the USB system's in spam mode:
> 
> 
> xhci0: Resetting controller
> usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored)
> usbd_setup_device_desc: getting device descriptor at addr 2 failed,
> USB_ERR_TIMEOUT
> igb0: link state changed to UP
> usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT,
> ignored)
> usbd_setup_device_desc: getting device descriptor at addr 2 failed,
> USB_ERR_TIMEOUT
> uhid0 on uhub3
> uhid0:  on
> usbus1
> uhid1 on uhub3
> uhid1:  1.10/1.22, addr 4> on usbus1
> ums0 on uhub2
> ums0:  on
> usbus1
> ums0: 3 buttons and [XYZ] coordinates ID=0
> usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT,
> ignored)
> usbd_setup_device_desc: getting device descriptor at addr 2 failed,
> USB_ERR_TIMEOUT
> usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT,
> ignored)
> usbd_setup_device_desc: getting device descriptor at addr 2 failed,
> USB_ERR_TIMEOUT
> usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT,
> ignored)
> usbd_setup_device_desc: getting device descriptor at addr 2 failed,
> USB_ERR_TIMEOUT
> ugen0.2:  at usbus0 (disconnected)
> uhub_reattach_port: could not allocate new device
> uhub1: at usbus0, port 1, addr 1 (disconnected)
> uhub1: <0x1022 XHCI 

PAM modules; pthreads not reliably dispatching background threads :(.

2020-02-09 Thread Dr Josef Karthauser
Hi Folks,

Has anyone got any experience with PAM and pthreads?

We’re using a 2FA module (pam_yubico 
https://www.freebsd.org/cgi/man.cgi?query=pam_yubico=8 
).

It’s proving unreliable. Digging deeper it uses libcurl to communication to an 
HTTP endpoint, and libcurl is using pthreads for to make asynchronous DNS 
lookup requests. 

It seems that the pthreads are not being handled reliably within the PAM 
runtime context - the background threads do not complete or dispatch. It’s very 
strange.

The problem doesn’t happen if we use the same code running from a user land 
process. The pthreads are reliably in this context.

Is there a known issue with PAM and pthreads? Hints are that there are 
(https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214540 
). But that problem 
was reported 3 years ago!

HELP!

If you know something I’d really appreciate a steer!

Many thanks,
Joe
— 
Dr Josef Karthauser
Chief Technical Officer 
(01225) 300371 / (07703) 596893 
www.truespeed.com 
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"