Re: [RFC] Outline of USB process integration in the kernel taskqueue system
On Thursday, November 04, 2010 5:49:22 pm Matthew Fleming wrote: On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin j...@freebsd.org wrote: On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky wrote: I think that if a task is currently executing, then there should be a drain method for that. I.E. two methods: One to stop and one to cancel/drain. Can you implement this? I agree, this would also be consistent with the callout_*() API if you had both stop() and drain() methods. Here's my proposed code. Note that this builds but is not yet tested. Implement a taskqueue_cancel(9), to cancel a task from a queue. Requested by: hps Original code: jeff MFC after: 1 week http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff For FreeBSD taskqueue_cancel() should return EBUSY, not -EBUSY. However, I would prefer that it follow the semantics of callout_stop() and return true if it stopped the task and false otherwise. The Linux wrapper for taskqueue_cancel() can convert the return value. I'm not sure I like reusing the memory allocation flags (M_NOWAIT / M_WAITOK) for this blocking flag. In the case of callout(9) we just have two functions that pass an internal boolean to the real routine (callout_stop() and callout_drain() are wrappers for _callout_stop_safe()). It is a bit unfortunate that taskqueue_drain() already exists and has different semantics than callout_drain(). It would have been nice to have the two APIs mirror each other instead. Hmm, I wonder if the blocking behavior cannot safely be provided by just doing: if (!taskqueue_cancel(queue, task, M_NOWAIT) taskqueue_drain(queue, task); If that works ok (I think it does), I would rather have taskqueue_cancel() always be non-blocking. Even though there is a race where the task could be rescheduled by another thread in between cancel and drain, the race still exists since if the task could be scheduled between the two, it could also be scheduled just before the call to taskqueue_cancel() (in which case a taskqueue_cancel(queue, task, M_WAITOK) would have blocked to wait for it matching the taskqueue_drain() above). The caller still always has to provide synchronization for preventing a task's execution outright via their own locking. -- John Baldwin ___ 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: [RFC] Outline of USB process integration in the kernel taskqueue system
On Fri, Nov 5, 2010 at 5:58 AM, John Baldwin j...@freebsd.org wrote: On Thursday, November 04, 2010 5:49:22 pm Matthew Fleming wrote: On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin j...@freebsd.org wrote: On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky wrote: I think that if a task is currently executing, then there should be a drain method for that. I.E. two methods: One to stop and one to cancel/drain. Can you implement this? I agree, this would also be consistent with the callout_*() API if you had both stop() and drain() methods. Here's my proposed code. Note that this builds but is not yet tested. Implement a taskqueue_cancel(9), to cancel a task from a queue. Requested by: hps Original code: jeff MFC after: 1 week http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff For FreeBSD taskqueue_cancel() should return EBUSY, not -EBUSY. However, I would prefer that it follow the semantics of callout_stop() and return true if it stopped the task and false otherwise. The Linux wrapper for taskqueue_cancel() can convert the return value. I used -EBUSY since positive return values reflect the old pending count. ta_pending was zero'd, and I think needs to be to keep the task sane, because all of taskqueue(9) assumes a non-zero ta_pending means the task is queued. I don't know that the caller often needs to know the old value of ta_pending, but it seems simpler to return that as the return value and use -EBUSY than to use an optional pointer to a place to store the old ta_pending just so we can keep the error return positive. Note that phk (IIRC) suggested using -error in the returns for sbuf_drain to indicate the difference between success ( 0 bytes drained) and an error, so FreeBSD now has precedent. I'm not entirely sure that's a good thing, since I am not generally fond of Linux's use of -error, but for some cases it is convenient. But, I'll do this one either way, just let me know if the above hasn't convinced you. I'm not sure I like reusing the memory allocation flags (M_NOWAIT / M_WAITOK) for this blocking flag. In the case of callout(9) we just have two functions that pass an internal boolean to the real routine (callout_stop() and callout_drain() are wrappers for _callout_stop_safe()). It is a bit unfortunate that taskqueue_drain() already exists and has different semantics than callout_drain(). It would have been nice to have the two APIs mirror each other instead. Hmm, I wonder if the blocking behavior cannot safely be provided by just doing: if (!taskqueue_cancel(queue, task, M_NOWAIT) taskqueue_drain(queue, task); This seems reasonable and correct. I will add a note to the manpage about this. Thanks, matthew If that works ok (I think it does), I would rather have taskqueue_cancel() always be non-blocking. Even though there is a race where the task could be rescheduled by another thread in between cancel and drain, the race still exists since if the task could be scheduled between the two, it could also be scheduled just before the call to taskqueue_cancel() (in which case a taskqueue_cancel(queue, task, M_WAITOK) would have blocked to wait for it matching the taskqueue_drain() above). The caller still always has to provide synchronization for preventing a task's execution outright via their own locking. -- John Baldwin ___ 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: [RFC] Outline of USB process integration in the kernel taskqueue system
On Friday, November 05, 2010 9:50:10 am Matthew Fleming wrote: On Fri, Nov 5, 2010 at 5:58 AM, John Baldwin j...@freebsd.org wrote: On Thursday, November 04, 2010 5:49:22 pm Matthew Fleming wrote: On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin j...@freebsd.org wrote: On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky wrote: I think that if a task is currently executing, then there should be a drain method for that. I.E. two methods: One to stop and one to cancel/drain. Can you implement this? I agree, this would also be consistent with the callout_*() API if you had both stop() and drain() methods. Here's my proposed code. Note that this builds but is not yet tested. Implement a taskqueue_cancel(9), to cancel a task from a queue. Requested by: hps Original code: jeff MFC after: 1 week http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff For FreeBSD taskqueue_cancel() should return EBUSY, not -EBUSY. However, I would prefer that it follow the semantics of callout_stop() and return true if it stopped the task and false otherwise. The Linux wrapper for taskqueue_cancel() can convert the return value. I used -EBUSY since positive return values reflect the old pending count. ta_pending was zero'd, and I think needs to be to keep the task sane, because all of taskqueue(9) assumes a non-zero ta_pending means the task is queued. I don't know that the caller often needs to know the old value of ta_pending, but it seems simpler to return that as the return value and use -EBUSY than to use an optional pointer to a place to store the old ta_pending just so we can keep the error return positive. Note that phk (IIRC) suggested using -error in the returns for sbuf_drain to indicate the difference between success ( 0 bytes drained) and an error, so FreeBSD now has precedent. I'm not entirely sure that's a good thing, since I am not generally fond of Linux's use of -error, but for some cases it is convenient. But, I'll do this one either way, just let me know if the above hasn't convinced you. Hmm, I hadn't considered if callers would want to know the pending count of the cancelled task. I'm not sure I like reusing the memory allocation flags (M_NOWAIT / M_WAITOK) for this blocking flag. In the case of callout(9) we just have two functions that pass an internal boolean to the real routine (callout_stop() and callout_drain() are wrappers for _callout_stop_safe()). It is a bit unfortunate that taskqueue_drain() already exists and has different semantics than callout_drain(). It would have been nice to have the two APIs mirror each other instead. Hmm, I wonder if the blocking behavior cannot safely be provided by just doing: if (!taskqueue_cancel(queue, task, M_NOWAIT) taskqueue_drain(queue, task); This seems reasonable and correct. I will add a note to the manpage about this. In that case, would you be fine with dropping the blocking functionality from taskqueue_cancel() completely and requiring code that wants the blocking semantics to use a cancel followed by a drain? -- John Baldwin ___ 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: usbconfig reset ugen4.2 hanging since an hour
Quoting Hans Petter Selasky hsela...@freebsd.org (from Tue, 2 Nov 2010 10:36:41 +0100): On Tuesday 02 November 2010 10:32:08 Alexander Leidinger wrote: Hi, I have a memory stick which made problems (the stick is used as a ZFS cache and it moaned about 8xxM write problems) in 9-current r214509. I removed the device from the config, made a camcontrol reset all, camcontrol rescan all (- device disappeared), and then tried an usbconfig reset ugen4.2 (relevant devlist part from before the call is below). The usbconfig reset does not return to the shell. I do not know if the problem with the USB memory stick is related to software or hardware. The stick survived just a weekend, I replaced it because the old one showed similar problems after surviving about 9 months... I updated -current just before the problems appeared (and then again after a week or two), but I do not remember from which revision of -current I was updating from. I will try to stress-test the memory sticks on a 8.1 system so see if it is some software problem. The big question I have for now is: shouldn't there be some kind of safety mechanism kicking in (timeout) with the usbconfig command (in this case the reset)? devlist: ---snip--- ugen4.1: EHCI root HUB Intel at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen4.2: Flash Disk USB 2.0 at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ---snip--- dmesg | grep -i usb: ---snip--- uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0xdc00-0xdc1f irq 16 at device 29.0 on pci0 usbus0: Intel 82801EB (ICH5) USB controller USB-A on uhci0 uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0xe000-0xe01f irq 19 at device 29.1 on pci0 usbus1: Intel 82801EB (ICH5) USB controller USB-B on uhci1 uhci2: Intel 82801EB (ICH5) USB controller USB-C port 0xe400-0xe41f irq 18 at device 29.2 on pci0 usbus2: Intel 82801EB (ICH5) USB controller USB-C on uhci2 uhci3: Intel 82801EB (ICH5) USB controller USB-D port 0xe800-0xe81f irq 16 at device 29.3 on pci0 usbus3: Intel 82801EB (ICH5) USB controller USB-D on uhci3 ehci0: Intel 82801EB/R (ICH5) USB 2.0 controller mem 0xfe77fc00-0xfe77 irq 23 at device 29.7 on pci0 usbus4: EHCI version 1.0 usbus4: Intel 82801EB/R (ICH5) USB 2.0 controller on ehci0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 ugen0.1: Intel at usbus0 uhub0: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus0 ugen1.1: Intel at usbus1 uhub1: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus1 ugen2.1: Intel at usbus2 uhub2: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus2 ugen3.1: Intel at usbus3 uhub3: Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1 on usbus3 ugen4.1: Intel at usbus4 uhub4: Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus4 Root mount waiting for: usbus4 Root mount waiting for: usbus4 Root mount waiting for: usbus4 Root mount waiting for: usbus4 ugen4.2: USB 2.0 at usbus4 umass0: USB 2.0 Flash Disk, class 0/0, rev 2.00/1.00, addr 2 on usbus4 Root mount waiting for: usbus4 pass3: USB 2.0 Flash Disk 5.00 Removable Direct Access SCSI-2 device da0: USB 2.0 Flash Disk 5.00 Removable Direct Access SCSI-2 device Root mount waiting for: usbus4 ugen1.2: vendor 0x1941 at usbus1 ugen1.3: vendor 0x04f9 at usbus1 ulpt0: vendor 0x04f9 product 0x0100, class 0/0, rev 1.00/1.00, addr 3 on usbus1 ugen2.2: Logitech at usbus2 uhub5: Logitech Logitech BT Mini-Receiver, class 9/0, rev 2.00/49.00, addr 2 on usbus2 ugen2.3: Logitech at usbus2 ukbd0: Logitech Logitech BT Mini-Receiver, class 0/0, rev 2.00/49.00, addr 3 on usbus2 ugen2.4: Logitech at usbus2 ums0: Logitech Logitech BT Mini-Receiver, class 0/0, rev 2.00/49.00, addr 4 on usbus2 ---snip--- Hi, If you dump all threads in this state I think you will see that USB is waiting somewhere in umass_detach(), which is preventing the usbconfig reset from grabbing the SX-lock associated with serialisation. Because umass_detach() is not returning we are stuck. I made some tests. I've used the initial stick in question on Solaris 10u9 (no ZFS errors for several postmark runs) and FreeBSD 9 (r214509, own zpool with only the stick, one postmark run and I get I/O errors - any access to the stick hangs now due to 'failmode=wait'). On FreeBSD 9 as of r212247 I do not have problems with the second stick with which I experienced errors more quickly. I do not know yet if this is because of failed hardware, or because of a problem in the USB stack. As the first traces of this appeared after an update, I lean towards a regression... I will have a look at getting some time to update the older FreeBSD 9 system to something in between the working and not working version. Bye, Alexander. -- There must be at least 500,000,000 rats in the United States; of course, I never heard the story before. http://www.Leidinger.netAlexander @
Re: [RFC] Outline of USB process integration in the kernel taskqueue system
On Fri, Nov 5, 2010 at 7:18 AM, John Baldwin j...@freebsd.org wrote: On Friday, November 05, 2010 9:50:10 am Matthew Fleming wrote: On Fri, Nov 5, 2010 at 5:58 AM, John Baldwin j...@freebsd.org wrote: On Thursday, November 04, 2010 5:49:22 pm Matthew Fleming wrote: On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin j...@freebsd.org wrote: On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky wrote: I think that if a task is currently executing, then there should be a drain method for that. I.E. two methods: One to stop and one to cancel/drain. Can you implement this? I agree, this would also be consistent with the callout_*() API if you had both stop() and drain() methods. Here's my proposed code. Note that this builds but is not yet tested. Implement a taskqueue_cancel(9), to cancel a task from a queue. Requested by: hps Original code: jeff MFC after: 1 week http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff For FreeBSD taskqueue_cancel() should return EBUSY, not -EBUSY. However, I would prefer that it follow the semantics of callout_stop() and return true if it stopped the task and false otherwise. The Linux wrapper for taskqueue_cancel() can convert the return value. I used -EBUSY since positive return values reflect the old pending count. ta_pending was zero'd, and I think needs to be to keep the task sane, because all of taskqueue(9) assumes a non-zero ta_pending means the task is queued. I don't know that the caller often needs to know the old value of ta_pending, but it seems simpler to return that as the return value and use -EBUSY than to use an optional pointer to a place to store the old ta_pending just so we can keep the error return positive. Note that phk (IIRC) suggested using -error in the returns for sbuf_drain to indicate the difference between success ( 0 bytes drained) and an error, so FreeBSD now has precedent. I'm not entirely sure that's a good thing, since I am not generally fond of Linux's use of -error, but for some cases it is convenient. But, I'll do this one either way, just let me know if the above hasn't convinced you. Hmm, I hadn't considered if callers would want to know the pending count of the cancelled task. I'm not sure I like reusing the memory allocation flags (M_NOWAIT / M_WAITOK) for this blocking flag. In the case of callout(9) we just have two functions that pass an internal boolean to the real routine (callout_stop() and callout_drain() are wrappers for _callout_stop_safe()). It is a bit unfortunate that taskqueue_drain() already exists and has different semantics than callout_drain(). It would have been nice to have the two APIs mirror each other instead. Hmm, I wonder if the blocking behavior cannot safely be provided by just doing: if (!taskqueue_cancel(queue, task, M_NOWAIT) taskqueue_drain(queue, task); This seems reasonable and correct. I will add a note to the manpage about this. In that case, would you be fine with dropping the blocking functionality from taskqueue_cancel() completely and requiring code that wants the blocking semantics to use a cancel followed by a drain? New patch is at http://people.freebsd.org/~mdf/0001-Implement-taskqueue_cancel-9-to-cancel-a-task-from-a.patch I'll try to set up something to test it today too. Thanks, matthew ___ 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: [RFC] Outline of USB process integration in the kernel taskqueue system
On Friday 05 November 2010 18:15:01 Matthew Fleming wrote:
On Fri, Nov 5, 2010 at 7:18 AM, John Baldwin j...@freebsd.org wrote:
On Friday, November 05, 2010 9:50:10 am Matthew Fleming wrote:
On Fri, Nov 5, 2010 at 5:58 AM, John Baldwin j...@freebsd.org wrote:
On Thursday, November 04, 2010 5:49:22 pm Matthew Fleming wrote:
On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin j...@freebsd.org wrote:
On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky wrote:
I think that if a task is currently executing, then there should
be a drain method for that. I.E. two methods: One to stop and one
to cancel/drain. Can you implement this?
I agree, this would also be consistent with the callout_*() API if
you had both stop() and drain() methods.
Here's my proposed code. Note that this builds but is not yet
tested.
Implement a taskqueue_cancel(9), to cancel a task from a queue.
Requested by: hps
Original code: jeff
MFC after: 1 week
http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff
For FreeBSD taskqueue_cancel() should return EBUSY, not -EBUSY.
However, I would prefer that it follow the semantics of
callout_stop() and return true if it stopped the task and false
otherwise. The Linux wrapper for taskqueue_cancel() can convert the
return value.
I used -EBUSY since positive return values reflect the old pending
count. ta_pending was zero'd, and I think needs to be to keep the
task sane, because all of taskqueue(9) assumes a non-zero ta_pending
means the task is queued.
I don't know that the caller often needs to know the old value of
ta_pending, but it seems simpler to return that as the return value
and use -EBUSY than to use an optional pointer to a place to store the
old ta_pending just so we can keep the error return positive.
Note that phk (IIRC) suggested using -error in the returns for
sbuf_drain to indicate the difference between success ( 0 bytes
drained) and an error, so FreeBSD now has precedent. I'm not entirely
sure that's a good thing, since I am not generally fond of Linux's use
of -error, but for some cases it is convenient.
But, I'll do this one either way, just let me know if the above hasn't
convinced you.
Hmm, I hadn't considered if callers would want to know the pending count
of the cancelled task.
I'm not sure I like reusing the memory allocation flags (M_NOWAIT /
M_WAITOK) for this blocking flag. In the case of callout(9) we just
have two functions that pass an internal boolean to the real routine
(callout_stop() and callout_drain() are wrappers for
_callout_stop_safe()). It is a bit unfortunate that
taskqueue_drain() already exists and has different semantics than
callout_drain(). It would have been nice to have the two APIs mirror
each other instead.
Hmm, I wonder if the blocking behavior cannot safely be provided by
just doing:
if (!taskqueue_cancel(queue, task, M_NOWAIT)
taskqueue_drain(queue, task);
This seems reasonable and correct. I will add a note to the manpage
about this.
In that case, would you be fine with dropping the blocking functionality
from taskqueue_cancel() completely and requiring code that wants the
blocking semantics to use a cancel followed by a drain?
New patch is at
http://people.freebsd.org/~mdf/0001-Implement-taskqueue_cancel-9-to-cancel-
a-task-from-a.patch
I think the:
+ if (!task_is_running(queue, task)) {
check needs to be omitted. Else you block the possibility of enqueue and
cancel a task while it is actually executing/running ??
--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: [RFC] Outline of USB process integration in the kernel taskqueue system
On Fri, Nov 5, 2010 at 10:36 AM, Hans Petter Selasky hsela...@c2i.net wrote:
On Friday 05 November 2010 18:15:01 Matthew Fleming wrote:
On Fri, Nov 5, 2010 at 7:18 AM, John Baldwin j...@freebsd.org wrote:
On Friday, November 05, 2010 9:50:10 am Matthew Fleming wrote:
On Fri, Nov 5, 2010 at 5:58 AM, John Baldwin j...@freebsd.org wrote:
On Thursday, November 04, 2010 5:49:22 pm Matthew Fleming wrote:
On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin j...@freebsd.org wrote:
On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky wrote:
I think that if a task is currently executing, then there should
be a drain method for that. I.E. two methods: One to stop and one
to cancel/drain. Can you implement this?
I agree, this would also be consistent with the callout_*() API if
you had both stop() and drain() methods.
Here's my proposed code. Note that this builds but is not yet
tested.
Implement a taskqueue_cancel(9), to cancel a task from a queue.
Requested by: hps
Original code: jeff
MFC after: 1 week
http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff
For FreeBSD taskqueue_cancel() should return EBUSY, not -EBUSY.
However, I would prefer that it follow the semantics of
callout_stop() and return true if it stopped the task and false
otherwise. The Linux wrapper for taskqueue_cancel() can convert the
return value.
I used -EBUSY since positive return values reflect the old pending
count. ta_pending was zero'd, and I think needs to be to keep the
task sane, because all of taskqueue(9) assumes a non-zero ta_pending
means the task is queued.
I don't know that the caller often needs to know the old value of
ta_pending, but it seems simpler to return that as the return value
and use -EBUSY than to use an optional pointer to a place to store the
old ta_pending just so we can keep the error return positive.
Note that phk (IIRC) suggested using -error in the returns for
sbuf_drain to indicate the difference between success ( 0 bytes
drained) and an error, so FreeBSD now has precedent. I'm not entirely
sure that's a good thing, since I am not generally fond of Linux's use
of -error, but for some cases it is convenient.
But, I'll do this one either way, just let me know if the above hasn't
convinced you.
Hmm, I hadn't considered if callers would want to know the pending count
of the cancelled task.
I'm not sure I like reusing the memory allocation flags (M_NOWAIT /
M_WAITOK) for this blocking flag. In the case of callout(9) we just
have two functions that pass an internal boolean to the real routine
(callout_stop() and callout_drain() are wrappers for
_callout_stop_safe()). It is a bit unfortunate that
taskqueue_drain() already exists and has different semantics than
callout_drain(). It would have been nice to have the two APIs mirror
each other instead.
Hmm, I wonder if the blocking behavior cannot safely be provided by
just doing:
if (!taskqueue_cancel(queue, task, M_NOWAIT)
taskqueue_drain(queue, task);
This seems reasonable and correct. I will add a note to the manpage
about this.
In that case, would you be fine with dropping the blocking functionality
from taskqueue_cancel() completely and requiring code that wants the
blocking semantics to use a cancel followed by a drain?
New patch is at
http://people.freebsd.org/~mdf/0001-Implement-taskqueue_cancel-9-to-cancel-
a-task-from-a.patch
I think the:
+ if (!task_is_running(queue, task)) {
check needs to be omitted. Else you block the possibility of enqueue and
cancel a task while it is actually executing/running ??
Huh? If the task is currently running, there's nothing to do except
return failure. Task running means it can't be canceled, because...
it's running.
Thanks,
matthew
___
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: [RFC] Outline of USB process integration in the kernel taskqueue system
Hi,
In the patch attached to this e-mail I included Matthew Fleming's patch
aswell.
1) I renamed taskqueue_cancel() into taskqueue_stop(), hence that resembles
the words of the callout and USB API's terminology for doing the same.
2) I turns out I need to have code in subr_taskqueue.c to be able to make the
operations atomic.
3) I did not update the manpage in this patch. Will do that before a commit.
4) My patch implements separate state keeping in struct task_pair, which
avoids having to change any KPI's for now, like suggested by John Baldwin I
think.
5) In my implementation I hard-coded the priority argument to zero, so that
enqueuing is fast.
Comments are welcome!
--HPS
=== kern/subr_taskqueue.c
==
--- kern/subr_taskqueue.c (revision 214796)
+++ kern/subr_taskqueue.c (local)
@@ -275,6 +275,25 @@
return (0);
}
+int
+taskqueue_stop(struct taskqueue *queue, struct task *task)
+{
+ int retval = 0;
+
+ TQ_LOCK(queue);
+
+ if (task-ta_pending != 0) {
+ STAILQ_REMOVE(queue-tq_queue, task, task, ta_link);
+ task-ta_pending = 0;
+ }
+ if (task_is_running(queue, task))
+ retval = EBUSY;
+
+ TQ_UNLOCK(queue);
+
+ return (retval);
+}
+
void
taskqueue_drain(struct taskqueue *queue, struct task *task)
{
@@ -288,6 +307,113 @@
TQ_UNLOCK(queue);
}
+
+int
+taskqueue_pair_enqueue(struct taskqueue *queue, struct task_pair *tp)
+{
+ struct task *task;
+ int retval;
+ int j;
+
+ TQ_LOCK(queue);
+
+ j = 0;
+ if (tp-tp_task[0].ta_pending 0)
+ j |= 1;
+ if (tp-tp_task[1].ta_pending 0)
+ j |= 2;
+
+ if (j == 0) {
+ /* No entries are queued. Just pick a last task. */
+ tp-tp_last = 0;
+ /* Re-queue the last queued task. */
+ task = tp-tp_task[0];
+ } else if (j == 1) {
+ /* There is only one task pending and the other becomes last. */
+ tp-tp_last = 1;
+ /* Re-queue the last queued task. */
+ task = tp-tp_task[1];
+ } else if (j == 2) {
+ /* There is only one task pending and the other becomes last. */
+ tp-tp_last = 0;
+ /* Re-queue the last queued task. */
+ task = tp-tp_task[0];
+ } else {
+ /* Re-queue the last queued task. */
+ task = tp-tp_task[tp-tp_last];
+ STAILQ_REMOVE(queue-tq_queue, task, task, ta_link);
+ }
+
+ STAILQ_INSERT_TAIL(queue-tq_queue, task, ta_link);
+
+ retval = tp-tp_last + 1;
+ /* store the actual order in the pending count */
+ task-ta_pending = retval;
+
+ if ((queue-tq_flags TQ_FLAGS_BLOCKED) == 0)
+ queue-tq_enqueue(queue-tq_context);
+ else
+ queue-tq_flags |= TQ_FLAGS_PENDING;
+
+ TQ_UNLOCK(queue);
+
+ return (retval);
+}
+
+int
+taskqueue_pair_stop(struct taskqueue *queue, struct task_pair *tp)
+{
+ struct task *task;
+ int retval = 0;
+
+ TQ_LOCK(queue);
+
+ task = tp-tp_task[0];
+ if (task-ta_pending != 0) {
+ STAILQ_REMOVE(queue-tq_queue, task, task, ta_link);
+ task-ta_pending = 0;
+ }
+ if (task_is_running(queue, task))
+ retval = EBUSY;
+
+ task = tp-tp_task[1];
+ if (task-ta_pending != 0) {
+ STAILQ_REMOVE(queue-tq_queue, task, task, ta_link);
+ task-ta_pending = 0;
+ }
+ if (task_is_running(queue, task))
+ retval = EBUSY;
+
+ TQ_UNLOCK(queue);
+
+ return (retval);
+}
+
+void
+taskqueue_pair_drain(struct taskqueue *queue, struct task_pair *tp)
+{
+ struct task *task;
+
+ if (!queue-tq_spin)
+ WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL, __func__);
+
+ TQ_LOCK(queue);
+top:
+ task = tp-tp_task[0];
+ if (task-ta_pending != 0 || task_is_running(queue, task)) {
+ TQ_SLEEP(queue, task, queue-tq_mutex, PWAIT, -, 0);
+ goto top;
+ }
+
+ task = tp-tp_task[1];
+ if (task-ta_pending != 0 || task_is_running(queue, task)) {
+ TQ_SLEEP(queue, task, queue-tq_mutex, PWAIT, -, 0);
+ goto top;
+ }
+
+ TQ_UNLOCK(queue);
+}
+
static void
taskqueue_swi_enqueue(void *context)
{
=== sys/_task.h
==
--- sys/_task.h (revision 214796)
+++ sys/_task.h (local)
@@ -51,4 +51,9 @@
void *ta_context; /* (c) argument for handler */
};
+struct task_pair {
+ struct task tp_task[2];
+ int tp_last; /* (q) index of last queued task */
+};
+
#endif /* !_SYS__TASK_H_ */
=== sys/taskqueue.h
==
--- sys/taskqueue.h (revision 214796)
+++ sys/taskqueue.h (local)
@@ -53,7 +53,11 @@
void *context);
int taskqueue_start_threads(struct taskqueue **tqp, int count, int pri,
const char *name, ...) __printflike(4, 5);
+int taskqueue_pair_enqueue(struct taskqueue *queue, struct task_pair *tp);
+int taskqueue_pair_stop(struct taskqueue *queue, struct task_pair *tp);
+void taskqueue_pair_drain(struct taskqueue *queue, struct task_pair *tp);
int taskqueue_enqueue(struct taskqueue *queue, struct task *task);
+int taskqueue_stop(struct taskqueue *queue, struct task *task);
void taskqueue_drain(struct taskqueue *queue, struct task *task);
void taskqueue_free(struct taskqueue *queue);
void taskqueue_run(struct taskqueue *queue);
@@ -78,6 +82,15 @@
} while (0)
Re: [RFC] Outline of USB process integration in the kernel taskqueue system
On Friday 05 November 2010 19:13:08 Matthew Fleming wrote:
On Fri, Nov 5, 2010 at 10:36 AM, Hans Petter Selasky hsela...@c2i.net
wrote:
On Friday 05 November 2010 18:15:01 Matthew Fleming wrote:
On Fri, Nov 5, 2010 at 7:18 AM, John Baldwin j...@freebsd.org wrote:
On Friday, November 05, 2010 9:50:10 am Matthew Fleming wrote:
On Fri, Nov 5, 2010 at 5:58 AM, John Baldwin j...@freebsd.org wrote:
On Thursday, November 04, 2010 5:49:22 pm Matthew Fleming wrote:
On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin j...@freebsd.org
wrote:
On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky
wrote:
I think that if a task is currently executing, then there
should be a drain method for that. I.E. two methods: One to
stop and one to cancel/drain. Can you implement this?
I agree, this would also be consistent with the callout_*() API
if you had both stop() and drain() methods.
Here's my proposed code. Note that this builds but is not yet
tested.
Implement a taskqueue_cancel(9), to cancel a task from a queue.
Requested by: hps
Original code: jeff
MFC after: 1 week
http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff
For FreeBSD taskqueue_cancel() should return EBUSY, not -EBUSY.
However, I would prefer that it follow the semantics of
callout_stop() and return true if it stopped the task and false
otherwise. The Linux wrapper for taskqueue_cancel() can convert
the return value.
I used -EBUSY since positive return values reflect the old pending
count. ta_pending was zero'd, and I think needs to be to keep the
task sane, because all of taskqueue(9) assumes a non-zero ta_pending
means the task is queued.
I don't know that the caller often needs to know the old value of
ta_pending, but it seems simpler to return that as the return value
and use -EBUSY than to use an optional pointer to a place to store
the old ta_pending just so we can keep the error return positive.
Note that phk (IIRC) suggested using -error in the returns for
sbuf_drain to indicate the difference between success ( 0 bytes
drained) and an error, so FreeBSD now has precedent. I'm not
entirely sure that's a good thing, since I am not generally fond of
Linux's use of -error, but for some cases it is convenient.
But, I'll do this one either way, just let me know if the above
hasn't convinced you.
Hmm, I hadn't considered if callers would want to know the pending
count of the cancelled task.
I'm not sure I like reusing the memory allocation flags (M_NOWAIT /
M_WAITOK) for this blocking flag. In the case of callout(9) we
just have two functions that pass an internal boolean to the real
routine (callout_stop() and callout_drain() are wrappers for
_callout_stop_safe()). It is a bit unfortunate that
taskqueue_drain() already exists and has different semantics than
callout_drain(). It would have been nice to have the two APIs
mirror each other instead.
Hmm, I wonder if the blocking behavior cannot safely be provided by
just doing:
if (!taskqueue_cancel(queue, task, M_NOWAIT)
taskqueue_drain(queue, task);
This seems reasonable and correct. I will add a note to the manpage
about this.
In that case, would you be fine with dropping the blocking
functionality from taskqueue_cancel() completely and requiring code
that wants the blocking semantics to use a cancel followed by a
drain?
New patch is at
http://people.freebsd.org/~mdf/0001-Implement-taskqueue_cancel-9-to-canc
el- a-task-from-a.patch
I think the:
+ if (!task_is_running(queue, task)) {
If it is running, it is dequeued from the the taskqueue, right? And while it
is running it can be queued again, which your initial code didn't handle?
--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: [RFC] Outline of USB process integration in the kernel taskqueue system
On Fri, Nov 5, 2010 at 11:35 AM, Hans Petter Selasky hsela...@c2i.net wrote:
On Friday 05 November 2010 19:13:08 Matthew Fleming wrote:
On Fri, Nov 5, 2010 at 10:36 AM, Hans Petter Selasky hsela...@c2i.net
wrote:
On Friday 05 November 2010 18:15:01 Matthew Fleming wrote:
On Fri, Nov 5, 2010 at 7:18 AM, John Baldwin j...@freebsd.org wrote:
On Friday, November 05, 2010 9:50:10 am Matthew Fleming wrote:
On Fri, Nov 5, 2010 at 5:58 AM, John Baldwin j...@freebsd.org wrote:
On Thursday, November 04, 2010 5:49:22 pm Matthew Fleming wrote:
On Thu, Nov 4, 2010 at 2:22 PM, John Baldwin j...@freebsd.org
wrote:
On Thursday, November 04, 2010 4:15:16 pm Hans Petter Selasky
wrote:
I think that if a task is currently executing, then there
should be a drain method for that. I.E. two methods: One to
stop and one to cancel/drain. Can you implement this?
I agree, this would also be consistent with the callout_*() API
if you had both stop() and drain() methods.
Here's my proposed code. Note that this builds but is not yet
tested.
Implement a taskqueue_cancel(9), to cancel a task from a queue.
Requested by: hps
Original code: jeff
MFC after: 1 week
http://people.freebsd.org/~mdf/bsd-taskqueue-cancel.diff
For FreeBSD taskqueue_cancel() should return EBUSY, not -EBUSY.
However, I would prefer that it follow the semantics of
callout_stop() and return true if it stopped the task and false
otherwise. The Linux wrapper for taskqueue_cancel() can convert
the return value.
I used -EBUSY since positive return values reflect the old pending
count. ta_pending was zero'd, and I think needs to be to keep the
task sane, because all of taskqueue(9) assumes a non-zero ta_pending
means the task is queued.
I don't know that the caller often needs to know the old value of
ta_pending, but it seems simpler to return that as the return value
and use -EBUSY than to use an optional pointer to a place to store
the old ta_pending just so we can keep the error return positive.
Note that phk (IIRC) suggested using -error in the returns for
sbuf_drain to indicate the difference between success ( 0 bytes
drained) and an error, so FreeBSD now has precedent. I'm not
entirely sure that's a good thing, since I am not generally fond of
Linux's use of -error, but for some cases it is convenient.
But, I'll do this one either way, just let me know if the above
hasn't convinced you.
Hmm, I hadn't considered if callers would want to know the pending
count of the cancelled task.
I'm not sure I like reusing the memory allocation flags (M_NOWAIT /
M_WAITOK) for this blocking flag. In the case of callout(9) we
just have two functions that pass an internal boolean to the real
routine (callout_stop() and callout_drain() are wrappers for
_callout_stop_safe()). It is a bit unfortunate that
taskqueue_drain() already exists and has different semantics than
callout_drain(). It would have been nice to have the two APIs
mirror each other instead.
Hmm, I wonder if the blocking behavior cannot safely be provided by
just doing:
if (!taskqueue_cancel(queue, task, M_NOWAIT)
taskqueue_drain(queue, task);
This seems reasonable and correct. I will add a note to the manpage
about this.
In that case, would you be fine with dropping the blocking
functionality from taskqueue_cancel() completely and requiring code
that wants the blocking semantics to use a cancel followed by a
drain?
New patch is at
http://people.freebsd.org/~mdf/0001-Implement-taskqueue_cancel-9-to-canc
el- a-task-from-a.patch
I think the:
+ if (!task_is_running(queue, task)) {
If it is running, it is dequeued from the the taskqueue, right? And while it
is running it can be queued again, which your initial code didn't handle?
True, but no taskqueue(9) code can handle that. Only the caller can
prevent a task from becoming enqueued again. The same issue exists
with taskqueue_drain().
BTW, I planned to commit the patch I sent today after testing,
assuming jhb@ has no more issues.
Thanks,
matthew
___
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: [RFC] Outline of USB process integration in the kernel taskqueue system
On Friday 05 November 2010 19:39:45 Matthew Fleming wrote: True, but no taskqueue(9) code can handle that. Only the caller can prevent a task from becoming enqueued again. The same issue exists with taskqueue_drain(). I find that strange, because that means if I queue a task again while it is running, then I doesn't get run? Are you really sure? --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: [RFC] Outline of USB process integration in the kernel taskqueue system
On Fri, Nov 5, 2010 at 11:45 AM, Hans Petter Selasky hsela...@c2i.net wrote: On Friday 05 November 2010 19:39:45 Matthew Fleming wrote: True, but no taskqueue(9) code can handle that. Only the caller can prevent a task from becoming enqueued again. The same issue exists with taskqueue_drain(). I find that strange, because that means if I queue a task again while it is running, then I doesn't get run? Are you really sure? If a task is currently running when enqueued, the task struct will be re-enqueued to the taskqueue. When that task comes up as the head of the queue, it will be run again. Thanks, matthew ___ 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: [RFC] Outline of USB process integration in the kernel taskqueue system
On Friday 05 November 2010 19:48:05 Matthew Fleming wrote: On Fri, Nov 5, 2010 at 11:45 AM, Hans Petter Selasky hsela...@c2i.net wrote: On Friday 05 November 2010 19:39:45 Matthew Fleming wrote: True, but no taskqueue(9) code can handle that. Only the caller can prevent a task from becoming enqueued again. The same issue exists with taskqueue_drain(). I find that strange, because that means if I queue a task again while it is running, then I doesn't get run? Are you really sure? If a task is currently running when enqueued, the task struct will be re-enqueued to the taskqueue. When that task comes up as the head of the queue, it will be run again. Right, and the taskqueue_cancel has to cancel in that state to, but it doesn't because it only checks pending if !running() :-) ?? --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: [RFC] Outline of USB process integration in the kernel taskqueue system
On Friday, November 05, 2010 3:00:37 pm Hans Petter Selasky wrote: On Friday 05 November 2010 19:48:05 Matthew Fleming wrote: On Fri, Nov 5, 2010 at 11:45 AM, Hans Petter Selasky hsela...@c2i.net wrote: On Friday 05 November 2010 19:39:45 Matthew Fleming wrote: True, but no taskqueue(9) code can handle that. Only the caller can prevent a task from becoming enqueued again. The same issue exists with taskqueue_drain(). I find that strange, because that means if I queue a task again while it is running, then I doesn't get run? Are you really sure? If a task is currently running when enqueued, the task struct will be re-enqueued to the taskqueue. When that task comes up as the head of the queue, it will be run again. Right, and the taskqueue_cancel has to cancel in that state to, but it doesn't because it only checks pending if !running() :-) ?? You can't close that race in taskqueue_cancel(). You have to manage that race yourself in your task handler. For the callout(9) API we are only able to close that race if you use callout_init_mtx() so that the code managing the callout wheel can make use of your lock to resolve the races. If you use callout_init() you have to explicitly manage these races in your callout handler. -- John Baldwin ___ 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: USB 3.0 Fails To Attach Western Digital My Book 3.0
On 11/04/2010 13:37, Hans Petter Selasky wrote: On Saturday 23 October 2010 15:37:55 Michael Martin wrote: On 10/23/2010 00:23, Hans Petter Selasky wrote: On Saturday 23 October 2010 02:07:59 Michael Martin wrote: On 10/21/2010 01:29, Michael Martin wrote: Thanks for the new USB 3.0 effort! I'm testing it out on 9.0-CURRENT amd64. The controller seems to find a 2.0 usb stick fine. However, when I plug in a Western Digital 3.0 drive, the device fails to attach. The WD drive attaches fine when plugging into a 2.0 port on the motherboard. Controller info: xh...@pci0:5:0:0: class=0x0c0330 card=0x chip=0x01941033 rev=0x03 hdr=0x00 vendor = 'NEC Electronics Hong Kong' class = serial bus subclass = USB bar [10] = type Memory, range 64, base 0xfbbfe000, size 8192, enabled cap 01[50] = powerspec 3 supports D0 D3 current D0 cap 05[70] = MSI supports 8 messages, 64 bit cap 11[90] = MSI-X supports 8 messages in map 0x10 cap 10[a0] = PCI-Express 2 endpoint max data 128(128) link x1(x1) ecap 0001[100] = AER 1 0 fatal 0 non-fatal 0 corrected ecap 0003[140] = Serial 1 ecap 0018[150] = unknown 1 WD 3.0 Drive Info ( while plugged into the 2.0 port ): ugen3.4:My Book 3.0 Western Digital at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0210 bDeviceClass = 0x bDeviceSubClass = 0x bDeviceProtocol = 0x bMaxPacketSize0 = 0x0040 idVendor = 0x1058 idProduct = 0x1123 bcdDevice = 0x1010 iManufacturer = 0x0001Western Digital iProduct = 0x0002My Book 3.0 iSerialNumber = 0x0003XXXRemovedXXX bNumConfigurations = 0x0001 Output when plugging in the Western Digital 3.0 into the 3.0 port: Oct 21 01:03:54 gandalf root: Unknown USB device: vendor 0x1058 product 0x1123 bus uhub4 Oct 21 01:03:54 gandalf kernel: ugen4.2:Western Digital at usbus4 Oct 21 01:03:54 gandalf kernel: umass0:Western Digital My Book 3.0, class 0/0, rev 3.00/10.10, addr 1 on usbus4 Oct 21 01:03:54 gandalf kernel: umass0: SCSI over Bulk-Only; quirks = 0x Oct 21 01:03:55 gandalf kernel: umass0:9:0:-1: Attached to scbus9 Oct 21 01:03:57 gandalf root: ZFS: zpool I/O failure, zpool=wd3.1 error=28 Oct 21 01:03:57 gandalf last message repeated 2 times Oct 21 01:03:57 gandalf root: ZFS: vdev I/O failure, zpool=wd3.1 path= offset= size= error= Oct 21 01:04:03 gandalf kernel: ugen4.2:Western Digital at usbus4 (disconnected) Oct 21 01:04:03 gandalf kernel: umass0: at uhub4, port 2, addr 1 (disconnected) Oct 21 01:04:03 gandalf kernel: (da0:umass-sim0:0:0:0): lost device Oct 21 01:04:03 gandalf kernel: (da0:umass-sim0:0:0:0): got CAM status 0xa Oct 21 01:04:03 gandalf kernel: (da0:umass-sim0:0:0:0): fatal error, failed to attach to device Oct 21 01:04:03 gandalf kernel: (da0:umass-sim0:0: Oct 21 01:04:03 gandalf kernel: 0:0): removing device entry Oct 21 01:04:14 gandalf root: ZFS: zpool I/O failure, zpool=wd3.1 error=28 Oct 21 01:04:14 gandalf last message repeated 2 times Oct 21 01:04:14 gandalf root: ZFS: vdev I/O failure, zpool=wd3.1 path= offset= size= error= Output when plugging in the WD 3.0 into the 2.0 port: Oct 21 01:15:20 gandalf root: Unknown USB device: vendor 0x1058 product 0x1123 bus uhub3 Oct 21 01:15:20 gandalf kernel: ugen3.4:Western Digital at usbus3 Oct 21 01:15:20 gandalf kernel: umass0:Western Digital My Book 3.0, class 0/0, rev 2.10/10.10, addr 4 on usbus3 Oct 21 01:15:20 gandalf kernel: umass0: SCSI over Bulk-Only; quirks = 0x Oct 21 01:15:21 gandalf kernel: umass0:9:0:-1: Attached to scbus9 Oct 21 01:15:28 gandalf kernel: da0 at umass-sim0 bus 0 scbus9 target 0 lun 0 Oct 21 01:15:28 gandalf kernel: da0:WD My Book 3.0 1123 1010 Fixed Direct Access SCSI-4 device Oct 21 01:15:28 gandalf kernel: da0: 40.000MB/s transfers Oct 21 01:15:28 gandalf kernel: da0: 953867MB (1953519616 512 byte sectors: 255H 63S/T 121600C) Output when plugging in 2.0 device into the 3.0 port: Oct 21 01:09:54 gandalf root: Unknown USB device: vendor 0x090c product 0x1000 bus uhub4 Oct 21 01:09:54 gandalf kernel: ugen4.2:USB at usbus4 Oct 21 01:09:54 gandalf kernel: umass1:USB Flash Disk, class 0/0, rev 2.00/11.00, addr 1 on usbus4 Oct 21 01:09:54 gandalf kernel: umass1: SCSI over Bulk-Only; quirks = 0x Oct 21 01:09:55 gandalf kernel: umass1:10:1:-1: Attached to scbus10 Oct 21 01:09:56 gandalf kernel: (probe0:umass-sim1:1:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 Oct 21 01:09:56 gandalf kernel: (probe0:umass-sim1:1:0:0): CAM status: SCSI Status Error Oct 21 01:09:56 gandalf kernel: (probe0:umass-sim1:1:0:0): SCSI status: Check Condition Oct 21 01:09:56 gandalf kernel: (probe0:umass-sim1:1:0:0): SCSI sense: UNIT ATTENTION asc:28,0 (Not ready to ready change, medium may have changed) Oct 21 01:09:56 gandalf kernel: da1 at umass-sim1 bus 1 scbus10 target 0 lun 0 Oct 21 01:09:56 gandalf kernel: da1:USB Flash Disk
Re: usb/130230: [quirk] [usb67] [usb] [cam] [umass] Samsung Electronics YP-U3 does not attach in 7.1-RELEASE
The following reply was made to PR usb/130230; it has been noted by GNATS. From: Boris Kochergin sp...@acm.poly.edu To: bug-follo...@freebsd.org Cc: Subject: Re: usb/130230: [quirk] [usb67] [usb] [cam] [umass] Samsung Electronics YP-U3 does not attach in 7.1-RELEASE Date: Fri, 05 Nov 2010 22:13:24 -0400 Here is the output of usbconfig dump_device_desc relevant to the device: ugen3.2: YP-U3 Samsung Electronics at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0200 bDeviceClass = 0x bDeviceSubClass = 0x bDeviceProtocol = 0x bMaxPacketSize0 = 0x0040 idVendor = 0x04e8 idProduct = 0x507c bcdDevice = 0x0220 iManufacturer = 0x0001 Samsung Electronics iProduct = 0x0002 YP-U3 iSerialNumber = 0x0003 CEFBF7F26DFF bNumConfigurations = 0x0001 It still doesn't work out of the box on any version of FreeBSD, but I am running CURRENT now, so the following makes it work: usbconfig -d 3.2 add_quirk UQ_MSC_NO_INQUIRY usbconfig -d 3.2 add_quirk UQ_MSC_NO_SYNC_CACHE usbconfig -d 3.2 reset usbconfig -d 3.2 reset ___ 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
