Current problem reports assigned to freebsd-usb@FreeBSD.org
Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description o usb/163328 usbHardware o usb/162712 usbadded device on if_run. o usb/162306 usbusb devices cant get address asignation, no memories, o usb/162054 usbusbdump just hangs on 9.0-RC1 o usb/161793 usbpoor EHCI usb2 i/o performance o usb/160911 usbThe usb flash drive JetFlash Transcend 16GB 1100 doesn o usb/160436 usbucom wedges machine on parity error ? o usb/160299 usbMicroSDHC-to-USB adapters do not work in FreeBSD 8.x o usb/160192 usb[install] Installation from USB-Stick doesn't find the o usb/159274 usbUSB 3.0 Etron EJ168A does not work. f usb/159191 usb[fusefs-ntfs] write on fusefs-ntfs mounted partition r o usb/157376 usbLaCie USB disk not recognized o usb/157074 usb[boot] [usb8] vfs_mountroot_ask is called when no usb o usb/156898 usb[keyboard] usb keyboard does not work while boot (ps2 o usb/156735 usbNeed Quirk for Goflex USB Disk Drives o usb/156725 usbUSB stack stall cause complete system input loss o usb/156596 usb[ehci] Extremely high interrupt rate on ehci/uhci IRQ1 o usb/156000 usbrum(4) Fatal trap 18: integer divide fault while in ke o usb/155996 usbNanoBSD not booted as Disk o usb/155784 usbProblem with Transcend StoreJet 25M3 (2AJ1) on Asus M2 o usb/154710 usb[ugen] Conexant USB Modem is not working in 8.x. In 7. o usb/154506 usb[umass] Copying dir with large files makes FreeBSD loa o usb/154192 usb[umass] In Garmin Oregon GPS, only the first umass dev o i386/153851 usb[keyboard] keyboard issues on new Intel Mother boards. o usb/153703 usb[keyboard] My USB keyboard can not be used in 8-STABLE o usb/153609 usb[zyd] [panic] kernel: Fatal trap 12: page fault while o usb/153149 usb[umass] USB stick quirk regression [regression] o usb/152075 usb[usb8] [ehci] [request] Add quirk for CS5536 USB o usb/150892 usb[zyd] Whenever network contacted in any shape, way or o usb/150189 usb[run] [usb8] [patch] if_run appears to corrupt IP traf p usb/149934 usb[patch] [usb8] Transcend JetFlash V85 poor performance p usb/149900 usb[uftdi] [patch] FreeBSD 8.1 uftdi patch to support usb p usb/149764 usb[u3g] [patch] usbdevs update: Huawei K3765 3G modem o usb/149283 usb[uftdi] avrdude unable to talk to Arduino board (via u o usb/149162 usb[ural] ASUS WL-167g doesn't work in 8.1 (continue of 1 s usb/148702 usb[usb8] [request] IO DATA USB-RSAQ5 support on FreeBSD- o usb/148080 usbusbconfig(8) sometimes does not turn off the device o usb/147516 usb[umass] [usb67] kernel unable to deal with Olympus USB o i386/147475 usb[install] FreeBSD 8.x does not install on ASUS K8N4-E p usb/146871 usb[usbdevs] [usb8] [patch] provide descriprive string fo o usb/146840 usb[hang] FreeBSD 7.2 / 7.3 / 8.0 hang at startup after e o usb/146153 usb[axe] [usb8] Hosts in network doesn't receive any pack f usb/146054 usb[urtw] [usb8] urtw driver potentially out of date f usb/145513 usb[usb8] New USB stack: no new devices after forced usb p usb/145455 usb[usb8] [patch] USB debug support cannot be disabled o usb/145415 usb[umass] [usb8] USB card reader does not create slices a usb/145184 usbGENERIC can't mount root from USB on Asus EEE o usb/145165 usb[keyboard] [usb8] ukbd_set_leds_callback: error=USB_ER f kern/144938 usb[keyboard] [boot] Boot Failure with Apple (MB869LL/A) o usb/144387 usb[run] [panic] if_run panic o usb/144043 usb[umass] [usb8] USB DLT tape drive throws random errors a usb/143790 usb[boot] [cam] can not boot from usb hdd f usb/143620 usb[cdce] [usb8] the module if_cdce doesn't support my Op f usb/143294 usb[usb8] copying process stops at some time (10 - 50 sec o usb/143286 usb[ukbd] [usb8] [boot] boot failures on RELENG_8 system p usb/143186 usb[usbdevs] [usb8] [patch] add USB device IDs for Google a usb/143139 usb[umass] [usb8] [patch] Quirk for Century EX35SW4_SB4 J p usb/143045 usb[umass] [usb8] [patch] mounting Fujitsu 2600Z camera d o usb/142991 usb[uftdi] [usb67] [patch] Patch to add Crystalfontz 533 f usb/142989 usb[usb8] canon eos 50D attaches but detaches after few s f usb/142957 usb[umass] [usb8] [patch] patc
a few usb issues related to edge cases
Hans Petter, I think that I see some issues in the USB code that could cause problems in some edge cases. >From easiest to hardest: 1. I think that currently there is a LOR in usb_bus_shutdown. I think that the following patch should fix it: === --- a/sys/dev/usb/controller/usb_controller.c +++ b/sys/dev/usb/controller/usb_controller.c @@ -479,6 +481,7 @@ usb_bus_shutdown(struct usb_proc_msg *pm) bus_generic_shutdown(bus->bdev); + USB_BUS_UNLOCK(bus); usbd_enum_lock(udev); err = usbd_set_config_index(udev, USB_UNCONFIG_INDEX); @@ -497,6 +500,7 @@ usb_bus_shutdown(struct usb_proc_msg *pm) (bus->methods->set_hw_power_sleep) (bus, USB_HW_POWER_SHUTDOWN); usbd_enum_unlock(udev); + USB_BUS_LOCK(bus); } static void === Otherwise there are a lot of nasty reports like: lock order reversal: (sleepable after non-sleepable) 1st 0xff80006b0688 ohci0 (ohci0) @ /usr/src/sys/dev/usb/controller/usb_controller.c:336 2nd 0xfe00023cf070 USB config SX lock (USB config SX lock) @ /usr/src/sys/dev/usb/usb_device.c:2643 usbd_transfer_unsetup can sleep! with the following non-sleepable locks held: exclusive sleep mutex ohci0 (ohci0) r = 0 (0xff80006b0688) locked @ /usr/src/sys/dev/usb/controller/usb_controller.c:336 2. Somewhat related to the above. I think that because the USB subsystem implements the shutdown method and detaches all its drivers, then the ukbd driver won't be able to properly handle the 'shutdown -h' case where the kernel asks to "press any key to reboot" at the end. Depending on which thread wins the race (the one that executes the mainline shutdown code or the USB explore thread that detaches USB devices) there will either an immediate reboot or a later crash when any key is pressed. This is not critical, but OTOH perhaps the USB subsystem doesn't have to do the shutdown. As far as I can see a lot of the drivers just do nothing for the shutdown, for better or for worth. A side note: perhaps it would be a good idea to pass the 'how' value as an additional parameter to device_shutdown. 3. Looking at usbd_transfer_poll I see that it touches a lot of locks, including taking the bus lock. As we've discussed before, this is not safe in a particular context where the polling is supposed to be used - in the kdb/ddb context. If the lock is already taken by another thread, then instead of being able to use a USB keyboard a user would get even less debug-able crash. Also, it seems that usbd_transfer_poll calls into the usual state machine with various callbacks and dynamically made decisions about whether to execute some actions directly or defer their execution to a different thread. That code also touches locks in various places. I think that it would be more preferable to have a method that does the job in a more straight-forward way, without touching any locks, ignoring the usual code paths and assuming that no other treads are running in parallel. Ditto for the method to submit a request. As a side note: we probably need a flag to mark certain things such as e.g. the ukbd driver as "non recoverable", meaning that once those are used in the kdb context then there is no safe way to go back to normal system operation. What do you think? Thank you. -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: a few usb issues related to edge cases
On Monday 19 December 2011 13:16:17 Andriy Gapon wrote:
> Hans Petter,
>
> I think that I see some issues in the USB code that could cause problems in
> some edge cases.
> From easiest to hardest:
>
Hi,
> 1. I think that currently there is a LOR in usb_bus_shutdown. I think
> that the following patch should fix it:
> ===
> --- a/sys/dev/usb/controller/usb_controller.c
> +++ b/sys/dev/usb/controller/usb_controller.c
> @@ -479,6 +481,7 @@ usb_bus_shutdown(struct usb_proc_msg *pm)
>
> bus_generic_shutdown(bus->bdev);
>
> + USB_BUS_UNLOCK(bus);
> usbd_enum_lock(udev);
>
> err = usbd_set_config_index(udev, USB_UNCONFIG_INDEX);
> @@ -497,6 +500,7 @@ usb_bus_shutdown(struct usb_proc_msg *pm)
> (bus->methods->set_hw_power_sleep) (bus, USB_HW_POWER_SHUTDOWN);
>
> usbd_enum_unlock(udev);
> + USB_BUS_LOCK(bus);
> }
>
You are right! I believe my kernel tests were run without WITNESS.
> 2. Somewhat related to the above. I think that because the USB subsystem
> implements the shutdown method and detaches all its drivers, then the ukbd
> driver won't be able to properly handle the 'shutdown -h' case where the
> kernel asks to "press any key to reboot" at the end. Depending on which
> thread wins the race (the one that executes the mainline shutdown code or
> the USB explore thread that detaches USB devices) there will either an
> immediate reboot or a later crash when any key is pressed.
> This is not critical, but OTOH perhaps the USB subsystem doesn't have to do
> the shutdown. As far as I can see a lot of the drivers just do nothing
> for the shutdown, for better or for worth.
>
> A side note: perhaps it would be a good idea to pass the 'how' value as an
> additional parameter to device_shutdown.
The shutdown of USB is done to give USB devices at last chance to turn off or
reduce their current consumption.
In the old code the Host controller itself would be disabled, so keyboard
wouldn't have worked I believe like you suggest.
BTW: Shutdown should be executed after any "Press any key to reboot." and
shutdown should be given time to complete, hence for USB this needs to happen
in sync with the rest of the USB system.
> 3. Looking at usbd_transfer_poll I see that it touches a lot of locks,
> including taking the bus lock. As we've discussed before, this is not safe
> in a particular context where the polling is supposed to be used - in the
> kdb/ddb context. If the lock is already taken by another thread, then
> instead of being able to use a USB keyboard a user would get even less
> debug-able crash. Also, it seems that usbd_transfer_poll calls into the
> usual state machine with various callbacks and dynamically made decisions
> about whether to execute some actions directly or defer their execution to
> a different thread.
This is an optimisation. If the current thread can do the job without a LOR,
then we do it right away. Else we let another thread do it. It is possible to
have a more simple model, but then you will also get more task switches.
> That code also touches locks in various places. I
> think that it would be more preferable to have a method that does the job
> in a more straight-forward way, without touching any locks, ignoring the
> usual code paths and assuming that no other treads are running in
> parallel. Ditto for the method to submit a request.
The current USB code can be run fine without real locks, if you do a few
tricks. I have a single-threaded BSD-kernel replacement for this which works
like a charm for non-FreeBSD projects. I'm going to paste a few lines FYI:
Why not extend "struct mtx" to have two fields which are only used in case of
system polling (no scheduler running):
struct mtx {
xxx;
int owned_polling = 0;
struct mtx *parent_polling;
};
void
mtx_init(struct mtx *mtx, const char *name, const char *type, int opt)
{
mtx->owned = 0;
mtx->parent = mtx;
}
void
mtx_lock(struct mtx *mtx)
{
mtx = mtx->parent;
mtx->owned++;
}
void
mtx_unlock(struct mtx *mtx)
{
mtx = mtx->parent;
mtx->owned--;
}
int
mtx_owned(struct mtx *mtx)
{
mtx = mtx->parent;
return (mtx->owned != 0);
}
void
mtx_destroy(struct mtx *mtx)
{
/* NOP */
}
Maybe mtx_init, mtx_lock, mtx_unlock mtx_owned, mtx_destroy, etc, could be
function pointers, which are swapped at panic.
USB is SMP! To run SMP code from a single thread, you need to create a
hiherachy of the threads:
1) Callbacks (Giant)
2) Callbacks (non-Giant)
3) Control EP (non-Giant)
4) Explore thread (non-Giant)
When the explore thread is busy, we look for work in the level above and so
on. The USB stack implements this principle, which is maybe not documented
anywhere btw. If you want more than code, you can hire me to do that.
The mtx-code above I believe is far less work than to make new code which
handles the pollin
USB testers wanted for system suspend and resume
Hi, Can someone which have access to computer hardware which support system suspend and resume please test FreeBSD-10-current after this commit: http://svn.freebsd.org/changeset/base/228709 Part of the test: Remove any custom rc.d scripts which load/unload ehci/ohci/uhci/xhci during suspend and resume. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: a few usb issues related to edge cases
First replying just to couple of points where there seems to be a misunderstanding. on 19/12/2011 16:30 Hans Petter Selasky said the following: >> 2. Somewhat related to the above. I think that because the USB subsystem >> implements the shutdown method and detaches all its drivers, then the ukbd >> driver won't be able to properly handle the 'shutdown -h' case where the >> kernel asks to "press any key to reboot" at the end. Depending on which >> thread wins the race (the one that executes the mainline shutdown code or >> the USB explore thread that detaches USB devices) there will either an >> immediate reboot or a later crash when any key is pressed. >> This is not critical, but OTOH perhaps the USB subsystem doesn't have to do >> the shutdown. As far as I can see a lot of the drivers just do nothing >> for the shutdown, for better or for worth. >> >> A side note: perhaps it would be a good idea to pass the 'how' value as an >> additional parameter to device_shutdown. > > The shutdown of USB is done to give USB devices at last chance to turn off or > reduce their current consumption. > > In the old code the Host controller itself would be disabled, so keyboard > wouldn't have worked I believe like you suggest. I am not sure about the old code, I have never checked it. But the atkbd definitely works at this stage. > BTW: Shutdown should be executed after any "Press any key to reboot." and > shutdown should be given time to complete, hence for USB this needs to happen > in sync with the rest of the USB system. Have you actually ever done "shutdown -h"? In other words do you know what the "system halt" is? :) I am not sure if it would be a good idea to declare a system as "halted" before shutdown_final hooks are executed. I would rather sacrifice the whole "press a key" interactivity and simply executed hlt. That's because I think that the system halt has a very limited usage, mostly in combination with UPS, where interactivity via console/keyboard is not very important. BTW, the reason that I suggested to pass 'how' to device_shutdown is to give drivers some choice. E.g. USB could the whole shutdown thing for the cases of poweroff and reboot, but keep the devices going for halt. But probably right now we just need to make a decision whether ukbd is going to support system halt or not. If not, then I think that usb_shutdown() must wait until the explore_proc terminates. If yes, then usb_shutdown() should become a noop. Or it could become quite smart to detach/poweroff other devices in such a way that ukbd still stays usable. But that's probably harder to implement. [snip] >> As a side note: we probably need a flag to mark certain things such as e.g. >> the ukbd driver as "non recoverable", meaning that once those are used in >> the kdb context then there is no safe way to go back to normal system >> operation. > > I think you need to do shutdown _after_ the "Press any key to reboot". A flag > won't help. Umm, this suggestion was about entering and exiting KDB/DDB, not about shutdown/reboot. P.S. I've just looked at the code in stable/7 and it seems that it didn't actually unconfigured USB and detached device drivers. At least ohci_shutdown and ohci_shutdown are not called on FreeBSD. -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: a few usb issues related to edge cases
On Monday 19 December 2011 16:06:13 Andriy Gapon wrote: > First replying just to couple of points where there seems to be a > misunderstanding. > > on 19/12/2011 16:30 Hans Petter Selasky said the following: > >> 2. Somewhat related to the above. I think that because the USB > >> subsystem implements the shutdown method and detaches all its drivers, > >> then the ukbd driver won't be able to properly handle the 'shutdown -h' > >> case where the kernel asks to "press any key to reboot" at the end. > >> Depending on which thread wins the race (the one that executes the > >> mainline shutdown code or the USB explore thread that detaches USB > >> devices) there will either an immediate reboot or a later crash when > >> any key is pressed. > >> This is not critical, but OTOH perhaps the USB subsystem doesn't have to > >> do the shutdown. As far as I can see a lot of the drivers just do > >> nothing for the shutdown, for better or for worth. > >> > >> A side note: perhaps it would be a good idea to pass the 'how' value as > >> an additional parameter to device_shutdown. > > > > The shutdown of USB is done to give USB devices at last chance to turn > > off or reduce their current consumption. > > > > In the old code the Host controller itself would be disabled, so keyboard > > wouldn't have worked I believe like you suggest. > > I am not sure about the old code, I have never checked it. But the atkbd > definitely works at this stage. ATKBD is no comparison to UKBD :-) > > > BTW: Shutdown should be executed after any "Press any key to reboot." and > > shutdown should be given time to complete, hence for USB this needs to > > happen in sync with the rest of the USB system. > > Have you actually ever done "shutdown -h"? In other words do you know what > the "system halt" is? :) No, I'm usually "shutdown -p now". > I am not sure if it would be a good idea to declare a system as "halted" > before shutdown_final hooks are executed. I would rather sacrifice the > whole "press a key" interactivity and simply executed hlt. That's because > I think that the system halt has a very limited usage, mostly in > combination with UPS, where interactivity via console/keyboard is not very > important. > > BTW, the reason that I suggested to pass 'how' to device_shutdown is to > give drivers some choice. E.g. USB could the whole shutdown thing for the > cases of poweroff and reboot, but keep the devices going for halt. I see. > > But probably right now we just need to make a decision whether ukbd is > going to support system halt or not. > If not, then I think that usb_shutdown() must wait until the explore_proc > terminates. > If yes, then usb_shutdown() should become a noop. Or it could become quite > smart to detach/poweroff other devices in such a way that ukbd still stays > usable. But that's probably harder to implement. I will fix that. I see a missing wait there. Can I assume that we are allowed to sleep from device_shutdown() and that system timers still work? > P.S. I've just looked at the code in stable/7 and it seems that it didn't > actually unconfigured USB and detached device drivers. At least > ohci_shutdown and ohci_shutdown are not called on FreeBSD. Hmm. --HPS ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: a few usb issues related to edge cases
on 19/12/2011 17:11 Hans Petter Selasky said the following: > I will fix that. I see a missing wait there. Can I assume that we are allowed > to sleep from device_shutdown() and that system timers still work? I don't see any reason why either of these should be not true. Oh, and I see that you've already committed the change - thanks! -- Andriy Gapon ___ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
