Re: USB locks up system -- WAS Re: shutdown or acpi problem
On 2014-11-17 08:58, Dag-Erling Smørgrav wrote: Dag-Erling Smørgrav d...@des.no writes: Steve Kargl s...@troutmask.apl.washington.edu writes: I'll try that tomorrow. But, I now know that this is related to using hal from ports. If I comment out both enable_dbus and enable_hal in /etc/rc.conf, the system works as I would expect (ie., usb now works for unplugging devices!). I further suspect that the problems lies in hal_probe_storage, but haven't got too much further. HAL: the gift that keeps on giving. It also has this wonderful feature where it prevents you from unmounting anything you've ever mounted, because it watches for new mountpoints in the system, opens them, and keeps the file descriptors open indefinitely. I know this isn't really germane, but I just couldn't pass up a chance to complain about HAL. Hold on. It *is* germane: hal_probe_storage auto-mounted your USB stick and is holding on to it. If this also happens with mice and keyboards etc., you're probably looking at two different issues. DES I cursed at HAL a lot because it made uC inside r0ket to crap itself partially... this thing can be USB device but apparently didn't like black magic that HAL did. Maybe it tried to read from the beginning or something. It took lot of time to figure out why it doesn't work. Now I have set of ignore files to prevent grabbing for every single device in system. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB locks up system -- WAS Re: shutdown or acpi problem
On Sat, Nov 15, 2014 at 09:44:18PM -0800, Adrian Chadd wrote: On 15 November 2014 21:41, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Thu, Nov 13, 2014 at 01:22:06PM -0800, Steve Kargl wrote: On Thu, Nov 13, 2014 at 09:34:07PM +0100, Hans Petter Selasky wrote: On 11/13/14 19:15, Steve Kargl wrote: On Thu, Nov 13, 2014 at 10:03:32AM -0800, Steve Kargl wrote: On Thu, Nov 13, 2014 at 09:25:33AM -0800, Steve Kargl wrote: On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote: I have a kernel/world from r274273 sources, which is exhibiting a new issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' work. I get to the end of shutdown and see for example All buffers synced Uptime: 4h23m15s and then the laptop just sits there. It does not power off with the -p option nor does it reboot with the -r. Has anyone else seen this behavior? The problem appears to be related to a recent change in the USB stack. If I have the following drive plugged into a usb port, the above behavior is observed on shutdown. Adding hw.usb.no_shutdown_wait: 1 to /boot/loader.conf appears to work around the 'shutdown -p now' and 'shutdown -r now' issue. Unfortunately, the bricking of the laptop is not affected by this sysctl. Once a device is plugged into a usb, it must remain plugged in. Hi, Is using this sysctl/tunable a suitable solution for you? The sysctl is a suitable solution for the shutdown issues. It is not suitable solution for the general use of using a memory stick to for example quickly transfer files. Once the memory stick is plugged into the usb port, it must remain there unless one wants to reboot the system. I rebuilt the kernel with USB_DEBUG and CAMDEBUG enabled. I need to wade through a rather large /var/log/messages to see if anything appears unusual. Well, this has been a waste of a day. The problem is caused by r273872. This is the recent random device patch. I have no idea why removing a usb device would cause the system to lock up other than random is probably trying to harvest some entropy. + des / markm That's a good catch! It's not a waste of a day. Thankyou for digging into it and finding out what introduced the failure. Hopefully between Hans, des and markm a solution can be found. Shooting into the dark. I added 'options RANDOM_DEBUG' to my kernel. Plugging in a USB device shows kernel: ugen6.2: USBest Technology at usbus6 kernel: umass0: USBest Technology USB Mass Storage Device, class 0/0, rev 2.00/1.00, addr 2 on usbus6 kernel: random: device_attach(): feeding 4 bit(s) of entropy from umass0 kernel: da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 kernel: da0: 0.00 Removable Direct Access SCSI-2 device kernel: da0: Serial Number 08102201c42413 kernel: da0: 40.000MB/s transfers kernel: da0: 963MB (1974271 512 byte sectors: 64H 32S/T 963C) kernel: da0: quirks=0x2NO_6_BYTE in /var/log/messages. Now, when I immediately pull the device from the USB port, I get kernel: ugen6.2: USBest Technology at usbus6 (disconnected) kernel: umass0: at uhub6, port 1, addr 2 (disconnected) kernel: da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 kernel: da0: 0.00 s/n 08102201c42413 detached followed by a bricked laptop, which requires a depression of the power button. Is there a 'random: device_detach():' missing between the 'umass0' and 'da0' messages in the last 4 lines. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB locks up system -- WAS Re: shutdown or acpi problem
On 16 Nov 2014, at 17:51, Steve Kargl s...@troutmask.apl.washington.edu wrote: Is there a 'random: device_detach():' missing between the 'umass0' and 'da0' messages in the last 4 lines. No. At attach time, the RNG grabs some probe entropy. At detach time it does nothing. M -- Mark R V Murray ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB locks up system -- WAS Re: shutdown or acpi problem
On Sun, 2014-11-16 at 18:17 +, Mark R V Murray wrote: On 16 Nov 2014, at 17:51, Steve Kargl s...@troutmask.apl.washington.edu wrote: Is there a 'random: device_detach():' missing between the 'umass0' and 'da0' messages in the last 4 lines. No. At attach time, the RNG grabs some probe entropy. At detach time it does nothing. M And yet... Steve has gathered evidence that the system bricks when a device is detached with the new entropy-gathering code and doesn't do so prior to that code. What else is the new code doing around detach time? -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB locks up system -- WAS Re: shutdown or acpi problem
On 16 Nov 2014, at 18:21, Ian Lepore i...@freebsd.org wrote: On Sun, 2014-11-16 at 18:17 +, Mark R V Murray wrote: On 16 Nov 2014, at 17:51, Steve Kargl s...@troutmask.apl.washington.edu wrote: Is there a 'random: device_detach():' missing between the 'umass0' and 'da0' messages in the last 4 lines. No. At attach time, the RNG grabs some probe entropy. At detach time it does nothing. M And yet... Steve has gathered evidence that the system bricks when a device is detached with the new entropy-gathering code and doesn't do so prior to that code. What else is the new code doing around detach time? Nothing, except possibly harvesting interrupt entropy. I’ll promise to be astonished if this is other-than-harmless. I’d be more suspicious of the harvester thread, but I still can’t see how its hurting :-( M -- Mark R V Murray ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB locks up system -- WAS Re: shutdown or acpi problem
On Sun, 2014-11-16 at 18:23 +, Mark R V Murray wrote: On 16 Nov 2014, at 18:21, Ian Lepore i...@freebsd.org wrote: On Sun, 2014-11-16 at 18:17 +, Mark R V Murray wrote: On 16 Nov 2014, at 17:51, Steve Kargl s...@troutmask.apl.washington.edu wrote: Is there a 'random: device_detach():' missing between the 'umass0' and 'da0' messages in the last 4 lines. No. At attach time, the RNG grabs some probe entropy. At detach time it does nothing. M And yet... Steve has gathered evidence that the system bricks when a device is detached with the new entropy-gathering code and doesn't do so prior to that code. What else is the new code doing around detach time? Nothing, except possibly harvesting interrupt entropy. I’ll promise to be astonished if this is other-than-harmless. I’d be more suspicious of the harvester thread, but I still can’t see how its hurting :-( M The point I'm trying to make here is that you trimmed away the important part of the prior messages and replied only to the part where Steve's debugging efforts were somewhat speculating. The non-speculative part was where he bisected the failure to an exact commit: The problem is caused by r273872. This is the recent random device patch. I have no idea why removing a usb device would cause the system to lock up other than random is probably trying to harvest some entropy. -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB locks up system -- WAS Re: shutdown or acpi problem
On 16 Nov 2014, at 18:31, Ian Lepore i...@freebsd.org wrote: The point I'm trying to make here is that you trimmed away the important part of the prior messages and replied only to the part where Steve's debugging efforts were somewhat speculating. The non-speculative part was where he bisected the failure to an exact commit: The problem is caused by r273872. This is the recent random device patch. I have no idea why removing a usb device would cause the system to lock up other than random is probably trying to harvest some entropy. I’m sorry my commit caused the problem. I’m also trying to find out why, but I don’t know enough about USB or mass-storage devices to know why, so this may take me a while. In the meanwhile, I’ll try to help by pointing out things I do know. M -- Mark R V Murray ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB locks up system -- WAS Re: shutdown or acpi problem
On Sun, Nov 16, 2014 at 06:34:42PM +, Mark R V Murray wrote: On 16 Nov 2014, at 18:31, Ian Lepore i...@freebsd.org wrote: The point I'm trying to make here is that you trimmed away the important part of the prior messages and replied only to the part where Steve's debugging efforts were somewhat speculating. The non-speculative part was where he bisected the failure to an exact commit: The problem is caused by r273872. This is the recent random device patch. I have no idea why removing a usb device would cause the system to lock up other than random is probably trying to harvest some entropy. I?m sorry my commit caused the problem. Nothing to be sorry about. This is -current afterall. I?m also trying to find out why, but I don?t know enough about USB or mass-storage devices to know why, so this may take me a while. In the meanwhile, I?ll try to help by pointing out things I do know. Yes, I did the bisection to find that r273872 exposes the problem. What I don't know is if this is hardware specific to a Dell Latitude D530 laptop, USB specific, or some weird interaction between the random and USB. What I also find odd is that I seem to be the only person seeing this behavior when it is trivial for me to reproduce: boot laptop, plug in usb device, wait usb recognizes the device, then unplug the device. If you have not read the entire thread, once the laptop keyboard and video output lock up, I can ssh into the laptop. If I run usbconfig, it hangs, ^T tells me it is stuck in SX Lock, and the /dev/da0* devices have not been destroyed. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB locks up system -- WAS Re: shutdown or acpi problem
On 16 Nov 2014, at 18:51, Steve Kargl s...@troutmask.apl.washington.edu wrote: I?m sorry my commit caused the problem. Nothing to be sorry about. This is -current after all. Thanks :-) I?m also trying to find out why, but I don?t know enough about USB or mass-storage devices to know why, so this may take me a while. In the meanwhile, I?ll try to help by pointing out things I do know. Yes, I did the bisection to find that r273872 exposes the problem. What I don't know is if this is hardware specific to a Dell Latitude D530 laptop, USB specific, or some weird interaction between the random and USB. What I also find odd is that I seem to be the only person seeing this behavior when it is trivial for me to reproduce: boot laptop, plug in usb device, wait usb recognizes the device, then unplug the device. Strange for me too. I’m not exactly being bombarded with bug reports. If you have not read the entire thread, once the laptop keyboard and video output lock up, I can ssh into the laptop. If I run usbconfig, it hangs, ^T tells me it is stuck in SX Lock, and the /dev/da0* devices have not been destroyed. Weirder and weirder :-(. Something with SX locks? Hmm. I do use those for attach and detach for RNG sources. Could it be that that stick of yours is somehow getting involved in the RNG source locks? M -- Mark R V Murray ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB locks up system -- WAS Re: shutdown or acpi problem
On Sun, Nov 16, 2014 at 06:55:53PM +, Mark R V Murray wrote: On 16 Nov 2014, at 18:51, Steve Kargl s...@troutmask.apl.washington.edu wrote: If you have not read the entire thread, once the laptop keyboard and video output lock up, I can ssh into the laptop. If I run usbconfig, it hangs, ^T tells me it is stuck in SX Lock, and the /dev/da0* devices have not been destroyed. Weirder and weirder :-(. Something with SX locks? Hmm. I do use those for attach and detach for RNG sources. Could it be that that stick of yours is somehow getting involved in the RNG source locks? It's not limited to a single usb device. Plugging in/Unplugging a logitech mouse dongle, the memstick, a Western Digital MY Passport external usb hard drive, all lead to the locked keyboard and video. I tried adding both RANDOM_DEBUG and USBDEBUG to the kernel, but the mount of output is mind numbing. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB locks up system -- WAS Re: shutdown or acpi problem
On 11/16/14 20:03, Steve Kargl wrote: On Sun, Nov 16, 2014 at 06:55:53PM +, Mark R V Murray wrote: On 16 Nov 2014, at 18:51, Steve Kargl s...@troutmask.apl.washington.edu wrote: If you have not read the entire thread, once the laptop keyboard and video output lock up, I can ssh into the laptop. If I run usbconfig, it hangs, ^T tells me it is stuck in SX Lock, and the /dev/da0* devices have not been destroyed. Weirder and weirder :-(. Something with SX locks? Hmm. I do use those for attach and detach for RNG sources. Could it be that that stick of yours is somehow getting involved in the RNG source locks? It's not limited to a single usb device. Plugging in/Unplugging a logitech mouse dongle, the memstick, a Western Digital MY Passport external usb hard drive, all lead to the locked keyboard and video. I tried adding both RANDOM_DEBUG and USBDEBUG to the kernel, but the mount of output is mind numbing. Hi, Can you enter kgdb when the usbconfig is froozen, and backtrace all kernel threads. You should see exactly what locks are the problem. Maybe some lock didn't get properly unlocked! Thank you! --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB locks up system -- WAS Re: shutdown or acpi problem
On Sun, Nov 16, 2014 at 08:16:36PM +0100, Hans Petter Selasky wrote: On 11/16/14 20:03, Steve Kargl wrote: On Sun, Nov 16, 2014 at 06:55:53PM +, Mark R V Murray wrote: On 16 Nov 2014, at 18:51, Steve Kargl s...@troutmask.apl.washington.edu wrote: If you have not read the entire thread, once the laptop keyboard and video output lock up, I can ssh into the laptop. If I run usbconfig, it hangs, ^T tells me it is stuck in SX Lock, and the /dev/da0* devices have not been destroyed. Weirder and weirder :-(. Something with SX locks? Hmm. I do use those for attach and detach for RNG sources. Could it be that that stick of yours is somehow getting involved in the RNG source locks? It's not limited to a single usb device. Plugging in/Unplugging a logitech mouse dongle, the memstick, a Western Digital MY Passport external usb hard drive, all lead to the locked keyboard and video. I tried adding both RANDOM_DEBUG and USBDEBUG to the kernel, but the mount of output is mind numbing. Can you enter kgdb when the usbconfig is froozen, and backtrace all kernel threads. You should see exactly what locks are the problem. Maybe some lock didn't get properly unlocked! I haven't tried kgdb. I did try to attach gdb to the usbconfig process via its pid, but gdb dumped core. I haven't looked at locks in kgdb, what command or commands should I try. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB locks up system -- WAS Re: shutdown or acpi problem
On 11/16/14 20:29, Steve Kargl wrote: On Sun, Nov 16, 2014 at 08:16:36PM +0100, Hans Petter Selasky wrote: On 11/16/14 20:03, Steve Kargl wrote: On Sun, Nov 16, 2014 at 06:55:53PM +, Mark R V Murray wrote: On 16 Nov 2014, at 18:51, Steve Kargl s...@troutmask.apl.washington.edu wrote: If you have not read the entire thread, once the laptop keyboard and video output lock up, I can ssh into the laptop. If I run usbconfig, it hangs, ^T tells me it is stuck in SX Lock, and the /dev/da0* devices have not been destroyed. Weirder and weirder :-(. Something with SX locks? Hmm. I do use those for attach and detach for RNG sources. Could it be that that stick of yours is somehow getting involved in the RNG source locks? It's not limited to a single usb device. Plugging in/Unplugging a logitech mouse dongle, the memstick, a Western Digital MY Passport external usb hard drive, all lead to the locked keyboard and video. I tried adding both RANDOM_DEBUG and USBDEBUG to the kernel, but the mount of output is mind numbing. Can you enter kgdb when the usbconfig is froozen, and backtrace all kernel threads. You should see exactly what locks are the problem. Maybe some lock didn't get properly unlocked! I haven't tried kgdb. I did try to attach gdb to the usbconfig process via its pid, but gdb dumped core. I haven't looked at locks in kgdb, what command or commands should I try. Hi, You enter: thread apply all bt That will give you the backtrace of all threads. Grep for usbconfig, and figure out which line is causing the problem in the kernel. Then look at the USB explore threads and see where they are stuck in the detach of umass! --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB locks up system -- WAS Re: shutdown or acpi problem
... or since you can ssh into the thing, try as root: procstat -ka -adrian On 16 November 2014 11:33, Hans Petter Selasky h...@selasky.org wrote: On 11/16/14 20:29, Steve Kargl wrote: On Sun, Nov 16, 2014 at 08:16:36PM +0100, Hans Petter Selasky wrote: On 11/16/14 20:03, Steve Kargl wrote: On Sun, Nov 16, 2014 at 06:55:53PM +, Mark R V Murray wrote: On 16 Nov 2014, at 18:51, Steve Kargl s...@troutmask.apl.washington.edu wrote: If you have not read the entire thread, once the laptop keyboard and video output lock up, I can ssh into the laptop. If I run usbconfig, it hangs, ^T tells me it is stuck in SX Lock, and the /dev/da0* devices have not been destroyed. Weirder and weirder :-(. Something with SX locks? Hmm. I do use those for attach and detach for RNG sources. Could it be that that stick of yours is somehow getting involved in the RNG source locks? It's not limited to a single usb device. Plugging in/Unplugging a logitech mouse dongle, the memstick, a Western Digital MY Passport external usb hard drive, all lead to the locked keyboard and video. I tried adding both RANDOM_DEBUG and USBDEBUG to the kernel, but the mount of output is mind numbing. Can you enter kgdb when the usbconfig is froozen, and backtrace all kernel threads. You should see exactly what locks are the problem. Maybe some lock didn't get properly unlocked! I haven't tried kgdb. I did try to attach gdb to the usbconfig process via its pid, but gdb dumped core. I haven't looked at locks in kgdb, what command or commands should I try. Hi, You enter: thread apply all bt That will give you the backtrace of all threads. Grep for usbconfig, and figure out which line is causing the problem in the kernel. Then look at the USB explore threads and see where they are stuck in the detach of umass! --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB locks up system -- WAS Re: shutdown or acpi problem
On Sun, Nov 16, 2014 at 04:34:38PM -0800, Adrian Chadd wrote: ... or since you can ssh into the thing, try as root: procstat -ka I'll try that tomorrow. But, I now know that this is related to using hal from ports. If I comment out both enable_dbus and enable_hal in /etc/rc.conf, the system works as I would expect (ie., usb now works for unplugging devices!). I further suspect that the problems lies in hal_probe_storage, but haven't got too much further. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB locks up system -- WAS Re: shutdown or acpi problem
On Sun, Nov 16, 2014 at 08:33:15PM +0100, Hans Petter Selasky wrote: thread apply all bt That will give you the backtrace of all threads. Grep for usbconfig, and figure out which line is causing the problem in the kernel. Then look at the USB explore threads and see where they are stuck in the detach of umass! I haven't tried the kgdb approach, yet. I can say that the problem is coming from sg device. If I have 'device sg' in my config file, the problems occur. Removing 'device sg' gives a working kernel. If I do not start hald in /etc/rc.conf, everything works as expected. Now, if hald was started at boot and I then stop hald with '/usr/local/etc/rc.d/hald stop' then the one hald relate process is not stopped. I've wrapped lines to keep this short. % ps axl | grep hald UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 10581 195 20 0 13180 3512 - I - 0:00.05 hald-probe-storage: /dev/sg1 (hald-probe-storage) Using the procstat as suggested by Adrian, I have % procstat -ka 1058 100157 hald-probe-storage hald-probe-stora mi_switch sleepq_switch sleepq_catch_signals sleepq_wait_sig _sleep sgread giant_read devfs_read_f dofileread kern_readv sys_read syscall Xint0x80_syscall -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB locks up system -- WAS Re: shutdown or acpi problem
Steve Kargl s...@troutmask.apl.washington.edu writes: I'll try that tomorrow. But, I now know that this is related to using hal from ports. If I comment out both enable_dbus and enable_hal in /etc/rc.conf, the system works as I would expect (ie., usb now works for unplugging devices!). I further suspect that the problems lies in hal_probe_storage, but haven't got too much further. HAL: the gift that keeps on giving. It also has this wonderful feature where it prevents you from unmounting anything you've ever mounted, because it watches for new mountpoints in the system, opens them, and keeps the file descriptors open indefinitely. I know this isn't really germane, but I just couldn't pass up a chance to complain about HAL. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB locks up system -- WAS Re: shutdown or acpi problem
Dag-Erling Smørgrav d...@des.no writes: Steve Kargl s...@troutmask.apl.washington.edu writes: I'll try that tomorrow. But, I now know that this is related to using hal from ports. If I comment out both enable_dbus and enable_hal in /etc/rc.conf, the system works as I would expect (ie., usb now works for unplugging devices!). I further suspect that the problems lies in hal_probe_storage, but haven't got too much further. HAL: the gift that keeps on giving. It also has this wonderful feature where it prevents you from unmounting anything you've ever mounted, because it watches for new mountpoints in the system, opens them, and keeps the file descriptors open indefinitely. I know this isn't really germane, but I just couldn't pass up a chance to complain about HAL. Hold on. It *is* germane: hal_probe_storage auto-mounted your USB stick and is holding on to it. If this also happens with mice and keyboards etc., you're probably looking at two different issues. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB locks up system -- WAS Re: shutdown or acpi problem
On Thu, Nov 13, 2014 at 01:22:06PM -0800, Steve Kargl wrote: On Thu, Nov 13, 2014 at 09:34:07PM +0100, Hans Petter Selasky wrote: On 11/13/14 19:15, Steve Kargl wrote: On Thu, Nov 13, 2014 at 10:03:32AM -0800, Steve Kargl wrote: On Thu, Nov 13, 2014 at 09:25:33AM -0800, Steve Kargl wrote: On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote: I have a kernel/world from r274273 sources, which is exhibiting a new issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' work. I get to the end of shutdown and see for example All buffers synced Uptime: 4h23m15s and then the laptop just sits there. It does not power off with the -p option nor does it reboot with the -r. Has anyone else seen this behavior? The problem appears to be related to a recent change in the USB stack. If I have the following drive plugged into a usb port, the above behavior is observed on shutdown. Adding hw.usb.no_shutdown_wait: 1 to /boot/loader.conf appears to work around the 'shutdown -p now' and 'shutdown -r now' issue. Unfortunately, the bricking of the laptop is not affected by this sysctl. Once a device is plugged into a usb, it must remain plugged in. Hi, Is using this sysctl/tunable a suitable solution for you? The sysctl is a suitable solution for the shutdown issues. It is not suitable solution for the general use of using a memory stick to for example quickly transfer files. Once the memory stick is plugged into the usb port, it must remain there unless one wants to reboot the system. I rebuilt the kernel with USB_DEBUG and CAMDEBUG enabled. I need to wade through a rather large /var/log/messages to see if anything appears unusual. Well, this has been a waste of a day. The problem is caused by r273872. This is the recent random device patch. I have no idea why removing a usb device would cause the system to lock up other than random is probably trying to harvest some entropy. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB locks up system -- WAS Re: shutdown or acpi problem
On 15 November 2014 21:41, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Thu, Nov 13, 2014 at 01:22:06PM -0800, Steve Kargl wrote: On Thu, Nov 13, 2014 at 09:34:07PM +0100, Hans Petter Selasky wrote: On 11/13/14 19:15, Steve Kargl wrote: On Thu, Nov 13, 2014 at 10:03:32AM -0800, Steve Kargl wrote: On Thu, Nov 13, 2014 at 09:25:33AM -0800, Steve Kargl wrote: On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote: I have a kernel/world from r274273 sources, which is exhibiting a new issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' work. I get to the end of shutdown and see for example All buffers synced Uptime: 4h23m15s and then the laptop just sits there. It does not power off with the -p option nor does it reboot with the -r. Has anyone else seen this behavior? The problem appears to be related to a recent change in the USB stack. If I have the following drive plugged into a usb port, the above behavior is observed on shutdown. Adding hw.usb.no_shutdown_wait: 1 to /boot/loader.conf appears to work around the 'shutdown -p now' and 'shutdown -r now' issue. Unfortunately, the bricking of the laptop is not affected by this sysctl. Once a device is plugged into a usb, it must remain plugged in. Hi, Is using this sysctl/tunable a suitable solution for you? The sysctl is a suitable solution for the shutdown issues. It is not suitable solution for the general use of using a memory stick to for example quickly transfer files. Once the memory stick is plugged into the usb port, it must remain there unless one wants to reboot the system. I rebuilt the kernel with USB_DEBUG and CAMDEBUG enabled. I need to wade through a rather large /var/log/messages to see if anything appears unusual. Well, this has been a waste of a day. The problem is caused by r273872. This is the recent random device patch. I have no idea why removing a usb device would cause the system to lock up other than random is probably trying to harvest some entropy. + des / markm That's a good catch! It's not a waste of a day. Thankyou for digging into it and finding out what introduced the failure. Hopefully between Hans, des and markm a solution can be found. -adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB locks up system -- WAS Re: shutdown or acpi problem
On Sat, Nov 15, 2014 at 09:44:18PM -0800, Adrian Chadd wrote: On 15 November 2014 21:41, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Thu, Nov 13, 2014 at 01:22:06PM -0800, Steve Kargl wrote: On Thu, Nov 13, 2014 at 09:34:07PM +0100, Hans Petter Selasky wrote: On 11/13/14 19:15, Steve Kargl wrote: On Thu, Nov 13, 2014 at 10:03:32AM -0800, Steve Kargl wrote: On Thu, Nov 13, 2014 at 09:25:33AM -0800, Steve Kargl wrote: On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote: I have a kernel/world from r274273 sources, which is exhibiting a new issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' work. I get to the end of shutdown and see for example All buffers synced Uptime: 4h23m15s and then the laptop just sits there. It does not power off with the -p option nor does it reboot with the -r. Has anyone else seen this behavior? The problem appears to be related to a recent change in the USB stack. If I have the following drive plugged into a usb port, the above behavior is observed on shutdown. Adding hw.usb.no_shutdown_wait: 1 to /boot/loader.conf appears to work around the 'shutdown -p now' and 'shutdown -r now' issue. Unfortunately, the bricking of the laptop is not affected by this sysctl. Once a device is plugged into a usb, it must remain plugged in. Hi, Is using this sysctl/tunable a suitable solution for you? The sysctl is a suitable solution for the shutdown issues. It is not suitable solution for the general use of using a memory stick to for example quickly transfer files. Once the memory stick is plugged into the usb port, it must remain there unless one wants to reboot the system. I rebuilt the kernel with USB_DEBUG and CAMDEBUG enabled. I need to wade through a rather large /var/log/messages to see if anything appears unusual. Well, this has been a waste of a day. The problem is caused by r273872. This is the recent random device patch. I have no idea why removing a usb device would cause the system to lock up other than random is probably trying to harvest some entropy. + des / markm That's a good catch! It's not a waste of a day. Thankyou for digging into it and finding out what introduced the failure. Hopefully between Hans, des and markm a solution can be found. It is a waste in that I was going to spend the day working on powl(). My next window of time for powl() hacking is probably sometime in mid to late December. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
USB locks up system -- WAS Re: shutdown or acpi problem
On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote: I have a kernel/world from r274273 sources, which is exhibiting a new issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' work. I get to the end of shutdown and see for example All buffers synced Uptime: 4h23m15s and then the laptop just sits there. It does not power off with the -p option nor does it reboot with the -r. Has anyone else seen this behavior? The problem appears to be related to a recent change in the USB stack. If I have the following drive plugged into a usb port, the above behavior is observed on shutdown. ugen6.2: Western Digital at usbus6 umass0: MSC Bulk-Only Transport on usbus6 da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 da0: WD My Passport 0748 1019 Fixed Direct Access SCSI-6 device da0: Serial Number 57584B314537324445595A31 da0: 40.000MB/s transfers da0: 1907697MB (3906963456 512 byte sectors: 255H 63S/T 243197C) da0: quirks=0x2NO_6_BYTE ses1 at umass-sim0 bus 0 scbus4 target 0 lun 1 ses1: WD SES Device 1019 Fixed Enclosure Services SCSI-6 device ses1: Serial Number 57584B314537324445595A31 ses1: 40.000MB/s transfers ses1: SCSI-3 ENC Device If this drive was never plugged into a usb port, 'shutdown -r now' and 'shutdown -p now' work as expected. If drive is plugged into a usb port, and I then unplug the drive the laptop is turned into a brick. In a vt(4) console, there is no keyboard and no output is displayed to the console. Logging into the laptop with ssh works. With the laptop in a brick state, issuing 'usbconfig' yields a wedged process with no output to the terminal and 'usbconfig' is unkillable. ^T yields load: 0.30 cmd: usbconfig 1068 [USB config SX lock] 441.15r 0.00u 0.00s 1884k. Unfortunately, a 'gdb -p 1068' yields a core dump for gdb. :( Logging into the laptop again with ssh works. Issuing the command 'camcontrol rescan all' yields Re-scan of bus 4 returned error 0xa Re-scan of bus 0 was successful Re-scan of bus 1 was successful Re-scan of bus 2 was successful Re-scan of bus 3 was successful dmesg follows my sig. -- Steve Copyright (c) 1992-2014 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 11.0-CURRENT #0 r274456: Thu Nov 13 07:45:01 PST 2014 ka...@laptop-kargl.apl.washington.edu:/usr/obj/usr/src/sys/MOBILE i386 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 VT: running with driver vga. CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.04-MHz 686-class CPU) Origin=GenuineIntel Id=0x6fd Family=0x6 Model=0xf Stepping=13 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x2000LM AMD Features2=0x1LAHF VT-x: (disabled in BIOS) HLT,PAUSE TSC: P-state invariant, performance statistics real memory = 3221225472 (3072 MB) avail memory = 3136098304 (2990 MB) Event timer LAPIC quality 400 ACPI APIC Table: DELL M08 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 Version 2.0 irqs 0-23 on motherboard random: entropy device infrastructure driver random: selecting highest priority adaptor Dummy kbd1 at kbdmux0 random: SOFT: yarrow init() random: selecting highest priority adaptor Yarrow module_register_init: MOD_LOAD (vesa, 0xc0b3a4e0, 0) error 19 acpi0: DELL M08 on motherboard hpet0: High Precision Event Timer 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 acpi0: reservation of 0, 9f000 (3) failed acpi0: reservation of 10, bf5c0400 (3) failed cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 atrtc0: AT realtime clock port 0x70-0x71,0x72-0x77 irq 8 on acpi0 Event timer RTC frequency 32768 Hz quality 0 attimer0: AT timer 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: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 vgapci0: VGA-compatible display port 0xeff8-0xefff mem 0xfea0-0xfeaf,0xe000-0xefff irq 16 at device 2.0 on pci0 vgapci0: Boot video device vgapci1: VGA-compatible display mem 0xfeb0-0xfebf at device 2.1 on pci0 uhci0: Intel 82801H (ICH8) USB controller USB-D port 0x6f20-0x6f3f irq 20 at device 26.0 on pci0 usbus0 on uhci0 uhci1:
Re: USB locks up system -- WAS Re: shutdown or acpi problem
CCing hps and mav.. On Nov 13, 2014, at 09:25, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote: I have a kernel/world from r274273 sources, which is exhibiting a new issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' work. I get to the end of shutdown and see for example All buffers synced Uptime: 4h23m15s and then the laptop just sits there. It does not power off with the -p option nor does it reboot with the -r. Has anyone else seen this behavior? The problem appears to be related to a recent change in the USB stack. If I have the following drive plugged into a usb port, the above behavior is observed on shutdown. ugen6.2: Western Digital at usbus6 umass0: MSC Bulk-Only Transport on usbus6 da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 da0: WD My Passport 0748 1019 Fixed Direct Access SCSI-6 device da0: Serial Number 57584B314537324445595A31 da0: 40.000MB/s transfers da0: 1907697MB (3906963456 512 byte sectors: 255H 63S/T 243197C) da0: quirks=0x2NO_6_BYTE ses1 at umass-sim0 bus 0 scbus4 target 0 lun 1 ses1: WD SES Device 1019 Fixed Enclosure Services SCSI-6 device ses1: Serial Number 57584B314537324445595A31 ses1: 40.000MB/s transfers ses1: SCSI-3 ENC Device If this drive was never plugged into a usb port, 'shutdown -r now' and 'shutdown -p now' work as expected. If drive is plugged into a usb port, and I then unplug the drive the laptop is turned into a brick. In a vt(4) console, there is no keyboard and no output is displayed to the console. Logging into the laptop with ssh works. With the laptop in a brick state, issuing 'usbconfig' yields a wedged process with no output to the terminal and 'usbconfig' is unkillable. ^T yields load: 0.30 cmd: usbconfig 1068 [USB config SX lock] 441.15r 0.00u 0.00s 1884k. Unfortunately, a 'gdb -p 1068' yields a core dump for gdb. :( Logging into the laptop again with ssh works. Issuing the command 'camcontrol rescan all' yields Re-scan of bus 4 returned error 0xa Re-scan of bus 0 was successful Re-scan of bus 1 was successful Re-scan of bus 2 was successful Re-scan of bus 3 was successful dmesg follows my sig. -- Steve Copyright (c) 1992-2014 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 11.0-CURRENT #0 r274456: Thu Nov 13 07:45:01 PST 2014 ka...@laptop-kargl.apl.washington.edu:/usr/obj/usr/src/sys/MOBILE i386 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 VT: running with driver vga. CPU: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz (1995.04-MHz 686-class CPU) Origin=GenuineIntel Id=0x6fd Family=0x6 Model=0xf Stepping=13 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x2000LM AMD Features2=0x1LAHF VT-x: (disabled in BIOS) HLT,PAUSE TSC: P-state invariant, performance statistics real memory = 3221225472 (3072 MB) avail memory = 3136098304 (2990 MB) Event timer LAPIC quality 400 ACPI APIC Table: DELL M08 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 Version 2.0 irqs 0-23 on motherboard random: entropy device infrastructure driver random: selecting highest priority adaptor Dummy kbd1 at kbdmux0 random: SOFT: yarrow init() random: selecting highest priority adaptor Yarrow module_register_init: MOD_LOAD (vesa, 0xc0b3a4e0, 0) error 19 acpi0: DELL M08 on motherboard hpet0: High Precision Event Timer 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 acpi0: reservation of 0, 9f000 (3) failed acpi0: reservation of 10, bf5c0400 (3) failed cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 atrtc0: AT realtime clock port 0x70-0x71,0x72-0x77 irq 8 on acpi0 Event timer RTC frequency 32768 Hz quality 0 attimer0: AT timer 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: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 vgapci0: VGA-compatible display port 0xeff8-0xefff mem 0xfea0-0xfeaf,0xe000-0xefff irq 16 at device 2.0 on pci0 vgapci0: Boot video device
Re: USB locks up system -- WAS Re: shutdown or acpi problem
On Thu, Nov 13, 2014 at 09:25:33AM -0800, Steve Kargl wrote: On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote: I have a kernel/world from r274273 sources, which is exhibiting a new issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' work. I get to the end of shutdown and see for example All buffers synced Uptime: 4h23m15s and then the laptop just sits there. It does not power off with the -p option nor does it reboot with the -r. Has anyone else seen this behavior? The problem appears to be related to a recent change in the USB stack. If I have the following drive plugged into a usb port, the above behavior is observed on shutdown. ugen6.2: Western Digital at usbus6 umass0: MSC Bulk-Only Transport on usbus6 da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 da0: WD My Passport 0748 1019 Fixed Direct Access SCSI-6 device da0: Serial Number 57584B314537324445595A31 da0: 40.000MB/s transfers da0: 1907697MB (3906963456 512 byte sectors: 255H 63S/T 243197C) da0: quirks=0x2NO_6_BYTE ses1 at umass-sim0 bus 0 scbus4 target 0 lun 1 ses1: WD SES Device 1019 Fixed Enclosure Services SCSI-6 device ses1: Serial Number 57584B314537324445595A31 ses1: 40.000MB/s transfers ses1: SCSI-3 ENC Device The problem is not restricted to hte WD My Passport drive. The memstick ugen6.2: USBest Technology at usbus6 umass0: USBest Technology USB Mass Storage Device, class 0/0, rev 2.00/1.00, addr 2 on usbus6 da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 da0: 0.00 Removable Direct Access SCSI-2 device da0: Serial Number 08102201c42413 da0: 40.000MB/s transfers da0: 963MB (1974271 512 byte sectors: 64H 32S/T 963C) da0: quirks=0x2NO_6_BYTE will also cause the system to wedge when removed. I failed to report that /dev/da0, /dev/da0s1, /dev/da0s1a, etc were not destroyed when the WD My Passport was removed. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB locks up system -- WAS Re: shutdown or acpi problem
On Thu, Nov 13, 2014 at 10:03:32AM -0800, Steve Kargl wrote: On Thu, Nov 13, 2014 at 09:25:33AM -0800, Steve Kargl wrote: On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote: I have a kernel/world from r274273 sources, which is exhibiting a new issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' work. I get to the end of shutdown and see for example All buffers synced Uptime: 4h23m15s and then the laptop just sits there. It does not power off with the -p option nor does it reboot with the -r. Has anyone else seen this behavior? The problem appears to be related to a recent change in the USB stack. If I have the following drive plugged into a usb port, the above behavior is observed on shutdown. Adding hw.usb.no_shutdown_wait: 1 to /boot/loader.conf appears to work around the 'shutdown -p now' and 'shutdown -r now' issue. Unfortunately, the bricking of the laptop is not affected by this sysctl. Once a device is plugged into a usb, it must remain plugged in. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB locks up system -- WAS Re: shutdown or acpi problem
On 11/13/14 19:15, Steve Kargl wrote: On Thu, Nov 13, 2014 at 10:03:32AM -0800, Steve Kargl wrote: On Thu, Nov 13, 2014 at 09:25:33AM -0800, Steve Kargl wrote: On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote: I have a kernel/world from r274273 sources, which is exhibiting a new issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' work. I get to the end of shutdown and see for example All buffers synced Uptime: 4h23m15s and then the laptop just sits there. It does not power off with the -p option nor does it reboot with the -r. Has anyone else seen this behavior? The problem appears to be related to a recent change in the USB stack. If I have the following drive plugged into a usb port, the above behavior is observed on shutdown. Adding hw.usb.no_shutdown_wait: 1 to /boot/loader.conf appears to work around the 'shutdown -p now' and 'shutdown -r now' issue. Unfortunately, the bricking of the laptop is not affected by this sysctl. Once a device is plugged into a usb, it must remain plugged in. Hi, Is using this sysctl/tunable a suitable solution for you? --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: USB locks up system -- WAS Re: shutdown or acpi problem
On Thu, Nov 13, 2014 at 09:34:07PM +0100, Hans Petter Selasky wrote: On 11/13/14 19:15, Steve Kargl wrote: On Thu, Nov 13, 2014 at 10:03:32AM -0800, Steve Kargl wrote: On Thu, Nov 13, 2014 at 09:25:33AM -0800, Steve Kargl wrote: On Wed, Nov 12, 2014 at 02:42:13PM -0800, Steve Kargl wrote: I have a kernel/world from r274273 sources, which is exhibiting a new issue on my old laptop. Neither 'shutdown -p now' nor 'shutdown -r now' work. I get to the end of shutdown and see for example All buffers synced Uptime: 4h23m15s and then the laptop just sits there. It does not power off with the -p option nor does it reboot with the -r. Has anyone else seen this behavior? The problem appears to be related to a recent change in the USB stack. If I have the following drive plugged into a usb port, the above behavior is observed on shutdown. Adding hw.usb.no_shutdown_wait: 1 to /boot/loader.conf appears to work around the 'shutdown -p now' and 'shutdown -r now' issue. Unfortunately, the bricking of the laptop is not affected by this sysctl. Once a device is plugged into a usb, it must remain plugged in. Hi, Is using this sysctl/tunable a suitable solution for you? The sysctl is a suitable solution for the shutdown issues. It is not suitable solution for the general use of using a memory stick to for example quickly transfer files. Once the memory stick is plugged into the usb port, it must remain there unless one wants to reboot the system. I rebuilt the kernel with USB_DEBUG and CAMDEBUG enabled. I need to wade through a rather large /var/log/messages to see if anything appears unusual. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
