Date: Sat, 22 Apr 2023 13:16:38 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 270805] loader.efi: crashes with USB device attached Message-ID: <bug-270805-227-JZUbmTR7au@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-270805-227@https.bugs.freebsd.org/bugzilla/> References: <bug-270805-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D270805 --- Comment #14 from Mark Millard <marklmi26-fbsd@yahoo.com> --- (In reply to Robert Clausecker from comment #11) All my ZFS testing was with the same drive in different ports. All my UFS testing was with the same drive in different ports. (ZFS drive vs. UFS drive: same type but distinct instances.) The 2 drives are USB3.2 capable but are compatible/capable with USB3.0 (and with USB2). In this context, the WDK23 interhal hubs and ports are a mix of USB3.0 and USB3.2 . As I understand it, even for a USB3.0 device, when attached to a USB 3.2 hub/port the kernel has somewhat different activity to do. The hub/port is not fully transparent of itself. (May be you were referencing my keyboard/mouse note, where I did not reference USB2 explicitly. I do not expect that any keyboards/mice issues are relevant to the storage media issues.) As for the time: RPi4B's do not have an RTC but the ntpd startup I use deals with setting up the time anyway. That did not happen here. I'm unsure why. I ended up manually setting the date in order to allow my buildworld buildkernel test. (Again, I sometimes boot the RPi4B's with the same drives that I used for the Windows Dev Kit 2023 testing.) As for temperature: If what you report is true, it is odd that the UEFI/ACPI implementation supplies definitions for non-existing sensors. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-270805-227-JZUbmTR7au>