amd64 head -r349794 (under Hyper-V): "panic: spin lock held too long" during a buildworld buildkernel
Looks like pmap_invalidate_range using smp_targeted_tlb_shootdown using
_mtx_lock_spin_cookie.
I'll note that I had no trouble with -r349444 building world or kernel
repeatedly, including
when I originally build -r349794 to upgrade.
The below is from my 2nd buildworld buildkernel under -r349794 (but the 2
builds were
not from scratch ones).
# more /var/crash/core.txt.2
FBSDFSSD dumped core - see /var/crash/vmcore.2
Sun Jul 7 02:26:36 PDT 2019
FreeBSD FBSDFSSD 13.0-CURRENT FreeBSD 13.0-CURRENT #24 r349794M: Sun Jul 7
01:55:57 PDT 2019
markmi@FBSDFSSD:/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/sys/GENERIC-NODBG
amd64
panic: spin lock held too long
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
Unread portion of the kernel message buffer:
spin lock 0x829540e0 (smp rendezvous) held by 0xf80ae7ebb5a0 (tid
100669) too long
timeout stopping cpus
panic: spin lock held too long
cpuid = 15
time = 1562491248
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00db5263c0
vpanic() at vpanic+0x19d/frame 0xfe00db526410
panic() at panic+0x43/frame 0xfe00db526470
_mtx_lock_indefinite_check() at _mtx_lock_indefinite_check+0x6d/frame
0xfe00db526480
_mtx_lock_spin_cookie() at _mtx_lock_spin_cookie+0xd5/frame 0xfe00db5264f0
smp_targeted_tlb_shootdown() at smp_targeted_tlb_shootdown+0x3de/frame
0xfe00db526560
pmap_invalidate_range() at pmap_invalidate_range+0x25c/frame 0xfe00db5265f0
vm_thread_stack_dispose() at vm_thread_stack_dispose+0x2c/frame
0xfe00db526640
thread_reap() at thread_reap+0x106/frame 0xfe00db526660
proc_reap() at proc_reap+0x788/frame 0xfe00db5266a0
proc_to_reap() at proc_to_reap+0x463/frame 0xfe00db5266f0
kern_wait6() at kern_wait6+0x34c/frame 0xfe00db526790
sys_wait4() at sys_wait4+0x78/frame 0xfe00db526980
amd64_syscall() at amd64_syscall+0x36e/frame 0xfe00db526ab0
fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe00db526ab0
--- syscall (7, FreeBSD ELF64, sys_wait4), rip = 0x80038f7fa, rsp =
0x7fffb168, rbp = 0x7fffb1b0 ---
KDB: enter: panic
Reading symbols from /boot/kernel/intpm.ko...Reading symbols from
/usr/lib/debug//boot/kernel/intpm.ko.debug...done.
done.
Loaded symbols for /boot/kernel/intpm.ko
Reading symbols from /boot/kernel/smbus.ko...Reading symbols from
/usr/lib/debug//boot/kernel/smbus.ko.debug...done.
done.
Loaded symbols for /boot/kernel/smbus.ko
Reading symbols from /boot/kernel/mac_ntpd.ko...Reading symbols from
/usr/lib/debug//boot/kernel/mac_ntpd.ko.debug...done.
done.
Loaded symbols for /boot/kernel/mac_ntpd.ko
Reading symbols from /boot/kernel/imgact_binmisc.ko...Reading symbols from
/usr/lib/debug//boot/kernel/imgact_binmisc.ko.debug...done.
done.
Loaded symbols for /boot/kernel/imgact_binmisc.ko
Reading symbols from /boot/kernel/filemon.ko...Reading symbols from
/usr/lib/debug//boot/kernel/filemon.ko.debug...done.
done.
Loaded symbols for /boot/kernel/filemon.ko
#0 doadump (textdump=0) at src/sys/amd64/include/pcpu.h:246
246 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n"
(OFFSETOF_CURTHREAD));
(kgdb) #0 doadump (textdump=0) at src/sys/amd64/include/pcpu.h:246
#1 0x804a152b in db_dump (dummy=,
dummy3=, dummy4=)
at /usr/src/sys/ddb/db_command.c:575
#2 0x804a12f9 in db_command (cmd_table=,
dopager=1) at /usr/src/sys/ddb/db_command.c:482
#3 0x804a1074 in db_command_loop ()
at /usr/src/sys/ddb/db_command.c:535
#4 0x804a42cf in db_trap (type=,
code=) at /usr/src/sys/ddb/db_main.c:252
#5 0x80c502bc in kdb_trap (type=3, code=0, tf=)
at /usr/src/sys/kern/subr_kdb.c:692
#6 0x810e1e2c in trap (frame=0xfe00db5262f0)
at /usr/src/sys/amd64/amd64/trap.c:621
#7 0x810bb8b5 in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:232
#8 0x80c4f9cb in kdb_enter (why=0x8134eb81 "panic",
msg=) at src/sys/amd64/include/cpufunc.h:65
#9 0x80c0226a in vpanic (fmt=,
ap=) at /usr/src/sys/kern/kern_shutdown.c:894
#10 0x80c020a3 in panic (fmt=)
at /usr/src/sys/kern/kern_shutdown.c:832
#11 0x80be128d in _mtx_lock_indefinite_check (m=,
ldap=) at /usr/src/sys/kern/kern_mutex.c:1222
#12 0x80be0dd5 in _mtx_lock_spin_cookie (c=0x829540f8,
v=) at /usr/src/sys/kern/kern_mutex.c:748
#13 0x8125b32e in smp_targeted_tlb_shootdown (mask=
{__bits = 0xfe00db526570}, vector=246, pmap=0x82a682f8,
addr1=18446741878369513472, addr2=18446741878369529856)
at /usr/src/sys/x86/x86/mp_x86.c:1671
#14
Re: Someone broke USB
On Sat, Jul 06, 2019 at 03:08:13PM -0600, Ian Lepore wrote: > On Sat, 2019-07-06 at 14:06 -0700, Steve Kargl wrote: > > On Sat, Jul 06, 2019 at 10:50:59PM +0200, Hans Petter Selasky wrote: > > > On 2019-07-06 21:41, Steve Kargl wrote: > > > > On Sat, Jul 06, 2019 at 08:33:39PM +0200, Hans Petter Selasky > > > > wrote: > > > > > On 2019-07-06 20:23, Steve Kargl wrote: > > > > > > So, how does one get usb working, again? > > > > > > > > > > > > -- Steve > > > > > > > > > > Can you show dmesg? > > > > > > > > > > > > > It looks like the enumeration of busses and devices has changed. > > > > grepping for uhub and usbus of the working and broken dmesg.boot > > > > gives > > > > > > > > > > Are you able to bisect the commit introducing the bad behaviour? > > > > > > > I'll give it a shot. I have two revision number to work with. > > > > It seems almost certain to be r349161 that causes the problem. > I've backed out the change, and the buildkernel is currently running. It won't finish for an hour or so (old hardware and rebuilding another project). -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Someone broke USB
On 2019-07-06 16:50, Hans Petter Selasky wrote: > > Are you able to bisect the commit introducing the bad behaviour? > I built and booted r349160. My 'boot mount waiting for USBUS7 -> USBUS0 issue went away but the startup halted at the 'mounting late filesystems' step of rc.conf. I had the USB issue at r349161 but building and loading the previous commit has other problems. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Someone broke USB
Hi Takanori, Can you have a look at the issues reported in this thread? Are the ACPI functions you call thread safe? USB will enumerate multiple busses at the same time. --HPS On 2019-07-06 23:08, Ian Lepore wrote: On Sat, 2019-07-06 at 14:06 -0700, Steve Kargl wrote: On Sat, Jul 06, 2019 at 10:50:59PM +0200, Hans Petter Selasky wrote: On 2019-07-06 21:41, Steve Kargl wrote: On Sat, Jul 06, 2019 at 08:33:39PM +0200, Hans Petter Selasky wrote: On 2019-07-06 20:23, Steve Kargl wrote: So, how does one get usb working, again? -- Steve Can you show dmesg? It looks like the enumeration of busses and devices has changed. grepping for uhub and usbus of the working and broken dmesg.boot gives Are you able to bisect the commit introducing the bad behaviour? I'll give it a shot. I have two revision number to work with. It seems almost certain to be r349161 that causes the problem. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Someone broke USB
On Sat, 2019-07-06 at 14:06 -0700, Steve Kargl wrote: > On Sat, Jul 06, 2019 at 10:50:59PM +0200, Hans Petter Selasky wrote: > > On 2019-07-06 21:41, Steve Kargl wrote: > > > On Sat, Jul 06, 2019 at 08:33:39PM +0200, Hans Petter Selasky > > > wrote: > > > > On 2019-07-06 20:23, Steve Kargl wrote: > > > > > So, how does one get usb working, again? > > > > > > > > > > -- Steve > > > > > > > > Can you show dmesg? > > > > > > > > > > It looks like the enumeration of busses and devices has changed. > > > grepping for uhub and usbus of the working and broken dmesg.boot > > > gives > > > > > > > Are you able to bisect the commit introducing the bad behaviour? > > > > I'll give it a shot. I have two revision number to work with. > It seems almost certain to be r349161 that causes the problem. -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Someone broke USB
On Sat, Jul 06, 2019 at 10:50:59PM +0200, Hans Petter Selasky wrote: > On 2019-07-06 21:41, Steve Kargl wrote: > > On Sat, Jul 06, 2019 at 08:33:39PM +0200, Hans Petter Selasky wrote: > >> On 2019-07-06 20:23, Steve Kargl wrote: > >>> So, how does one get usb working, again? > >>> > >>> -- Steve > >> > >> Can you show dmesg? > >> > > > > It looks like the enumeration of busses and devices has changed. > > grepping for uhub and usbus of the working and broken dmesg.boot > > gives > > > > Are you able to bisect the commit introducing the bad behaviour? > I'll give it a shot. I have two revision number to work with. -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Someone broke USB
On 2019-07-06 21:41, Steve Kargl wrote: On Sat, Jul 06, 2019 at 08:33:39PM +0200, Hans Petter Selasky wrote: On 2019-07-06 20:23, Steve Kargl wrote: So, how does one get usb working, again? -- Steve Can you show dmesg? It looks like the enumeration of busses and devices has changed. grepping for uhub and usbus of the working and broken dmesg.boot gives Are you able to bisect the commit introducing the bad behaviour? --HPS ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Someone broke USB
On Sat, Jul 06, 2019 at 08:33:39PM +0200, Hans Petter Selasky wrote: > On 2019-07-06 20:23, Steve Kargl wrote: > > So, how does one get usb working, again? > > > > -- Steve > > Can you show dmesg? > It looks like the enumeration of busses and devices has changed. grepping for uhub and usbus of the working and broken dmesg.boot gives % grep uhub dmesg.boot.working uhub0: on usbus6 uhub1: on usbus4 uhub2: on usbus3 uhub3: on usbus1 uhub4: on usbus5 uhub5: on usbus2 uhub6: on usbus0 uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered uhub5: 4 ports with 4 removable, self powered uhub0: 6 ports with 6 removable, self powered umass0 on uhub0 ukbd0 on uhub1 ums0 on uhub1 uhid0 on uhub1 % grep uhub dmesg.boot.broken uhub0 on usbus5 uhub0: on usbus5 uhub1 on usbus3 uhub1: on usbus3 uhub2 on usbus1 uhub2: on usbus1 uhub3 on usbus6 uhub3: on usbus6 uhub5 on usbus2 uhub5: on usbus2 uhub4 on usbus4 uhub4: on usbus4 uhub1: 2 ports with 2 removable, self powered uhub0: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 4 ports with 4 removable, self powered uhub3: 6 ports with 6 removable, self powered % grep usbus dmesg.boot.working usbus0 on uhci0 usbus0: 12Mbps Full Speed USB v1.0 usbus1 on uhci1 usbus1: 12Mbps Full Speed USB v1.0 usbus2: EHCI version 1.0 usbus2 on ehci0 usbus2: 480Mbps High Speed USB v2.0 usbus3 on uhci2 usbus3: 12Mbps Full Speed USB v1.0 usbus4 on uhci3 usbus4: 12Mbps Full Speed USB v1.0 usbus5 on uhci4 usbus5: 12Mbps Full Speed USB v1.0 usbus6: EHCI version 1.0 usbus6 on ehci1 usbus6: 480Mbps High Speed USB v2.0 ugen6.1: at usbus6 uhub0: on usbus6 ugen4.1: at usbus4 uhub1: on usbus4 ugen3.1: at usbus3 uhub2: on usbus3 ugen1.1: at usbus1 uhub3: on usbus1 ugen5.1: at usbus5 uhub4: on usbus5 ugen2.1: at usbus2 uhub5: on usbus2 ugen0.1: at usbus0 uhub6: on usbus0 ugen6.2: at usbus6 umass0: on usbus6 ugen4.2: at usbus4 ukbd0: on usbus4 ums0: on usbus4 uhid0: on usbus4 % grep usbus dmesg.boot.broken usbus0 on uhci0 usbus0: 12Mbps Full Speed USB v1.0 usbus1 on uhci1 usbus1: 12Mbps Full Speed USB v1.0 usbus2: EHCI version 1.0 usbus2 on ehci0 usbus2: 480Mbps High Speed USB v2.0 usbus3 on uhci2 usbus3: 12Mbps Full Speed USB v1.0 usbus4 on uhci3 usbus4: 12Mbps Full Speed USB v1.0 usbus5 on uhci4 usbus5: 12Mbps Full Speed USB v1.0 usbus6: EHCI version 1.0 usbus6 on ehci1 usbus6: 480Mbps High Speed USB v2.0 ugen5.1: at usbus5 ugen3.1: at usbus3 ugen1.1: at usbus1 ugen6.1: at usbus6 ugen4.1: at usbus4 ugen2.1: at usbus2 ugen0.1: at usbus0 uhub0 on usbus5 uhub0: on usbus5 uhub1 on usbus3 uhub1: on usbus3 uhub2 on usbus1 uhub2: on usbus1 uhub3 on usbus6 uhub3: on usbus6 uhub5 on usbus2 uhub5: on usbus2 uhub4 on usbus4 uhub4: on usbus4 -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Someone broke USB
On Sat, Jul 06, 2019 at 08:33:39PM +0200, Hans Petter Selasky wrote: > On 2019-07-06 20:23, Steve Kargl wrote: > > So, how does one get usb working, again? > > > > -- Steve > > Can you show dmesg? > This is dmesg.boot for the kernel with the non-functioning USB stack. I'll need to reboot with the older kernel to get the dmesg.boot for a kernel with a functioning stack. Do you need that as well? ---<>--- Copyright (c) 1992-2019 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 13.0-CURRENT r349777 MOBILE i386 FreeBSD clang version 8.0.1 (branches/release_80 363030) (based on LLVM 8.0.1) VT(vga): resolution 640x480 CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.05-MHz 686-class CPU) Origin="GenuineIntel" Id=0x6fd Family=0x6 Model=0xf Stepping=13 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x2010 AMD Features2=0x1 VT-x: (disabled in BIOS) HLT,PAUSE TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 3654860800 (3485 MB) Event timer "LAPIC" quality 100 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) random: unblocking device. ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard Launching APs: 1 Timecounter "TSC" frequency 1995047160 Hz quality 1000 random: entropy device external interface kbd1 at kbdmux0 module_register_init: MOD_LOAD (vesa, 0xf2bd70, 0) error 19 [ath_hal] loaded [ath_dfs] loaded [ath_rate] loaded [ar9300] loaded [ar5212] loaded [ar5416] loaded [ar5211] loaded [ar5210] loaded [ath] loaded nexus0 vtvga0: on motherboard cryptosoft0: on motherboard acpi0: on motherboard hpet0: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 cpu0: on acpi0 atrtc0: port 0x70-0x71,0x72-0x77 irq 8 on acpi0 atrtc0: registered as a time-of-day clock, resolution 1.00s Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43,0x50-0x53 irq 2 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pcib0: Ignoring 3 range above 4GB (0x12000-0x317ff) pci0: on pcib0 vgapci0: port 0xeff8-0xefff mem 0xfea0-0xfeaf,0xe000-0xefff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: aperture size is 256M, detected 7676k stolen memory vgapci0: Boot video device vgapci1: mem 0xfeb0-0xfebf at device 2.1 on pci0 uhci0: port 0x6f20-0x6f3f irq 20 at device 26.0 on pci0 usbus0 on uhci0 usbus0: 12Mbps Full Speed USB v1.0 uhci1: port 0x6f00-0x6f1f irq 21 at device 26.1 on pci0 usbus1 on uhci1 usbus1: 12Mbps Full Speed USB v1.0 ehci0: mem 0xfed1c400-0xfed1c7ff irq 22 at device 26.7 on pci0 usbus2: EHCI version 1.0 usbus2 on ehci0 usbus2: 480Mbps High Speed USB v2.0 hdac0: mem 0xfe9fc000-0xfe9f irq 21 at device 27.0 on pci0 pcib1: at device 28.0 on pci0 pcib1: [GIANT-LOCKED] pcib2: at device 28.1 on pci0 pcib2: [GIANT-LOCKED] pci1: on pcib2 wpi0: mem 0xfe8ff000-0xfe8f irq 17 at device 0.0 on pci1 pcib3: at device 28.5 on pci0 pcib3: [GIANT-LOCKED] pci2: on pcib3 bge0: mem 0xfe7f-0xfe7f irq 17 at device 0.0 on pci2 bge0: CHIP ID 0xa002; ASIC REV 0x0a; CHIP REV 0xa0; PCI-E miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: Ethernet address: 00:1d:09:ba:cc:0d uhci2: port 0x6f80-0x6f9f irq 20 at device 29.0 on pci0 usbus3 on uhci2 usbus3: 12Mbps Full Speed USB v1.0 uhci3: port 0x6f60-0x6f7f irq 21 at device 29.1 on pci0 usbus4 on uhci3 usbus4: 12Mbps Full Speed USB v1.0 uhci4: port 0x6f40-0x6f5f irq 22 at device 29.2 on pci0 usbus5 on uhci4 usbus5: 12Mbps Full Speed USB v1.0 ehci1: mem 0xfed1c000-0xfed1c3ff irq 20 at device 29.7 on pci0 usbus6: EHCI version 1.0 usbus6 on ehci1 usbus6: 480Mbps High Speed USB v2.0 pcib4: at device 30.0 on pci0 pci3: on pcib4 cbb0: at device 1.0 on pci3 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 pci3: at device 1.4 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x6fa0-0x6faf irq 16 at device 31.1 on pci0 ata0: at channel 0 on atapci0 ahci0: port 0x6eb0-0x6eb7,0x6eb8-0x6ebb,0x6ec0-0x6ec7,0x6ec8-0x6ecb,0x6ee0-0x6eff mem 0xfe9fb800-0xfe9fbfff irq 17 at device 31.2 on pci0 ahci0: AHCI v1.10 with 3 3Gbps ports, Port
Re: Problem with USB after r349133
On 2019-07-06 10:17, Graham Perrin wrote: > > I had the almost same (different bus numbers), just once, after updating > -CURRENT from r349099 to r349762. > > The subsequent boot of r349762 was free from the symptom. > > HP EliteBook 8570p, docked, with a Kensington keyboard and Logitech > trackball connected to USB ports at the side of the dock. > > At one of the USB ports at the rear of the dock was a rechargeable > motorised device, which I disconnected after the (one) USB issue. > I just built and installed r349161 and observed the same problem with the rc.conf probe for USBUS7 ... USBUS0. I will build r349160 and make a report. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Someone broke USB
On 2019-07-06 20:23, Steve Kargl wrote: So, how does one get usb working, again? -- Steve Can you show dmesg? --HPS ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Someone broke USB
Updated a month old FreeBSD-current to top of tree. Upon rebooting, the usb no longer functions. No usb mouse. No usb external hard drive. Unplugging and then re-plugging in external drive does not cause the drive to spin up. Logged in as root.` % usbconfig list No device match or lack of permissions % usbsonfig show_ifdrv No device match or lack of permissions % usbsonfig dump_all_desc No device match or lack of permissions % usbsonfig reset No device match or lack of permissions /usr/src/UPDATING does not show any recent entries for usb. So, how does one get usb working, again? -- Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Problem with USB after r349133
On 05/07/2019 16:38, Thomas Laus wrote: Root mount waiting for USBUS7 USBUS6 USBUS0. I had the almost same (different bus numbers), just once, after updating -CURRENT from r349099 to r349762. The subsequent boot of r349762 was free from the symptom. HP EliteBook 8570p, docked, with a Kensington keyboard and Logitech trackball connected to USB ports at the side of the dock. At one of the USB ports at the rear of the dock was a rechargeable motorised device, which I disconnected after the (one) USB issue. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Problem with USB after r349133
On 2019-07-05 18:05, Hans Petter Selasky wrote: > > There has been very few USB changes, except for ACPI USB support in: > > https://svnweb.freebsd.org/changeset/base/349161 > https://svnweb.freebsd.org/changeset/base/349251 > It looks like I will need to build a few kernels to see what changes made between r349133 and r349575 affected the USB Bus probes on my laptop. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
