Re: usb/181159: Problem attaching USB device
Hi, Is there a possibility for you to try a 9-stable kernel as of today. Can you also ask the guys to connect another USB device, like an empty memory stick and see if that is detected. Thank you! --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: umcs (4-Port-USB-serial) triggering way too much ehci IRQs
Hello, Hans. You wrote 17 сентября 2013 г., 9:14:17: HPS Check using usbdump -i usbusX -f Y -s 65536 -vvv HPS what is going on. Maybe some USB transfers are returning zero length data from the chip. After closing port I disable all interrupts in chip, I've checked this (it was my first thought: ``I forget to disable internal interrupts on device close''), so, theoretically, it should stop spam system with interrupts... -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ 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: umcs (4-Port-USB-serial) triggering way too much ehci IRQs
Bezüglich Hans Petter Selasky's Nachricht vom 17.09.2013 07:14 (localtime): Hi, Check using usbdump -i usbusX -f Y -s 65536 -vvv what is going on. Maybe some USB transfers are returning zero length data from the chip. Thanks for your help! I can't really read the numbers, but these 4 actions look all the time, whe no connection is open: 08:39:19.889658 usbus1.4 SUBM-INTR-EP=0089,SPD=HIGH,NFR=1,SLEN=0,IVAL=2 frame[0] READ 16 bytes flags 0xa SHORT_XFER_OK|PIPE_BOF|0 status 0xcb023 OPEN|TRANSFERRING|STARTED|SHORT_XFER_OK|BDMA_ENABLE|BDMA_SETUP|CAN_CANCEL_IMMED|DOING_CALLBACK|0 08:39:19.891655 usbus1.4 DONE-INTR-EP=0089,SPD=HIGH,NFR=1,SLEN=8,IVAL=2,ERR=0 frame[0] READ 5 bytes C1 C1 C1 01 55 -- -- -- -- -- -- -- -- -- -- -- |U | flags 0xa SHORT_XFER_OK|PIPE_BOF|0 status 0xeb021 OPEN|STARTED|SHORT_XFER_OK|BDMA_ENABLE|BDMA_SETUP|CURR_DMA_SET|CAN_CANCEL_IMMED|DOING_CALLBACK|0 08:39:19.891658 usbus1.4 SUBM-INTR-EP=0089,SPD=HIGH,NFR=1,SLEN=0,IVAL=2 frame[0] READ 16 bytes flags 0xa SHORT_XFER_OK|PIPE_BOF|0 status 0xeb023 OPEN|TRANSFERRING|STARTED|SHORT_XFER_OK|BDMA_ENABLE|BDMA_SETUP|CURR_DMA_SET|CAN_CANCEL_IMMED|DOING_CALLBACK|0 08:39:19.893656 usbus1.4 DONE-INTR-EP=0089,SPD=HIGH,NFR=1,SLEN=8,IVAL=2,ERR=0 frame[0] READ 5 bytes C1 C1 C1 01 55 -- -- -- -- -- -- -- -- -- -- -- |U | flags 0xa SHORT_XFER_OK|PIPE_BOF|0 status 0xcb021 OPEN|STARTED|SHORT_XFER_OK|BDMA_ENABLE|BDMA_SETUP|CAN_CANCEL_IMMED|DOING_CALLBACK|0 Thanks, -Harry signature.asc Description: OpenPGP digital signature
Re: umcs (4-Port-USB-serial) triggering way too much ehci IRQs
Hello, Hans. You wrote 17 сентября 2013 г., 9:14:17: HPS Check using usbdump -i usbusX -f Y -s 65536 -vvv HPS what is going on. Maybe some USB transfers are returning zero length data from the chip. Ok, I got 500 irq/s here from my device, so, I have same problem, as topicstarter. My usbdump (9-STABLE) doesn't understand '-f Y', without filter I get: 12:42:58.929604 usbus3.2 SUBM-INTR-EP=0089,SPD=HIGH,NFR=1,SLEN=0,IVAL=2 frame[0] READ 16 bytes flags 0xa SHORT_XFER_OK|PIPE_BOF|0 status 0xeb023 OPEN|TRANSFERRING|STARTED|SHORT_XFER_OK|BDMA_ENABLE|BDMA_SETUP|CURR_DMA_SET|CAN_CANCEL_IMMED|DOING_CALLBACK|0 12:42:58.931601 usbus3.2 DONE-INTR-EP=0089,SPD=HIGH,NFR=1,SLEN=8,IVAL=2,ERR=0 frame[0] READ 5 bytes C1 01 01 01 55 -- -- -- -- -- -- -- -- -- -- -- |U | flags 0xa SHORT_XFER_OK|PIPE_BOF|0 status 0xcb021 OPEN|STARTED|SHORT_XFER_OK|BDMA_ENABLE|BDMA_SETUP|CAN_CANCEL_IMMED|DOING_CALLBACK|0 12:42:58.931607 usbus3.2 SUBM-INTR-EP=0089,SPD=HIGH,NFR=1,SLEN=0,IVAL=2 frame[0] READ 16 bytes flags 0xa SHORT_XFER_OK|PIPE_BOF|0 status 0xcb023 OPEN|TRANSFERRING|STARTED|SHORT_XFER_OK|BDMA_ENABLE|BDMA_SETUP|CAN_CANCEL_IMMED|DOING_CALLBACK|0 12:42:58.933601 usbus3.2 DONE-INTR-EP=0089,SPD=HIGH,NFR=1,SLEN=8,IVAL=2,ERR=0 frame[0] READ 5 bytes C1 01 01 01 55 -- -- -- -- -- -- -- -- -- -- -- |U | flags 0xa SHORT_XFER_OK|PIPE_BOF|0 status 0xeb021 OPEN|STARTED|SHORT_XFER_OK|BDMA_ENABLE|BDMA_SETUP|CURR_DMA_SET|CAN_CANCEL_IMMED|DOING_CALLBACK|0 12:42:58.933610 usbus3.2 SUBM-INTR-EP=0089,SPD=HIGH,NFR=1,SLEN=0,IVAL=2 frame[0] READ 16 bytes flags 0xa SHORT_XFER_OK|PIPE_BOF|0 status 0xeb023 OPEN|TRANSFERRING|STARTED|SHORT_XFER_OK|BDMA_ENABLE|BDMA_SETUP|CURR_DMA_SET|CAN_CANCEL_IMMED|DOING_CALLBACK|0 -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ 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: umcs (4-Port-USB-serial) triggering way too much ehci IRQs
Bezüglich Lev Serebryakov's Nachricht vom 17.09.2013 10:44 (localtime):
Hello, Hans.
You wrote 17 сентября 2013 г., 9:14:17:
HPS Check using usbdump -i usbusX -f Y -s 65536 -vvv
HPS what is going on. Maybe some USB transfers are returning zero length
data from the chip.
Ok, I got 500 irq/s here from my device, so, I have same problem, as
topicstarter. My usbdump (9-STABLE) doesn't understand '-f Y', without
The Y is the device addr @ bus #X.
Same posted some seconds ago :-)
Thanks,
-Harry
filter I get:
12:42:58.929604 usbus3.2 SUBM-INTR-EP=0089,SPD=HIGH,NFR=1,SLEN=0,IVAL=2
frame[0] READ 16 bytes
flags 0xa SHORT_XFER_OK|PIPE_BOF|0
status 0xeb023
OPEN|TRANSFERRING|STARTED|SHORT_XFER_OK|BDMA_ENABLE|BDMA_SETUP|CURR_DMA_SET|CAN_CANCEL_IMMED|DOING_CALLBACK|0
12:42:58.931601 usbus3.2
DONE-INTR-EP=0089,SPD=HIGH,NFR=1,SLEN=8,IVAL=2,ERR=0
frame[0] READ 5 bytes
C1 01 01 01 55 -- -- -- -- -- -- -- -- -- -- -- |U |
flags 0xa SHORT_XFER_OK|PIPE_BOF|0
status 0xcb021
OPEN|STARTED|SHORT_XFER_OK|BDMA_ENABLE|BDMA_SETUP|CAN_CANCEL_IMMED|DOING_CALLBACK|0
12:42:58.931607 usbus3.2 SUBM-INTR-EP=0089,SPD=HIGH,NFR=1,SLEN=0,IVAL=2
frame[0] READ 16 bytes
flags 0xa SHORT_XFER_OK|PIPE_BOF|0
status 0xcb023
OPEN|TRANSFERRING|STARTED|SHORT_XFER_OK|BDMA_ENABLE|BDMA_SETUP|CAN_CANCEL_IMMED|DOING_CALLBACK|0
12:42:58.933601 usbus3.2
DONE-INTR-EP=0089,SPD=HIGH,NFR=1,SLEN=8,IVAL=2,ERR=0
frame[0] READ 5 bytes
C1 01 01 01 55 -- -- -- -- -- -- -- -- -- -- -- |U |
flags 0xa SHORT_XFER_OK|PIPE_BOF|0
status 0xeb021
OPEN|STARTED|SHORT_XFER_OK|BDMA_ENABLE|BDMA_SETUP|CURR_DMA_SET|CAN_CANCEL_IMMED|DOING_CALLBACK|0
12:42:58.933610 usbus3.2 SUBM-INTR-EP=0089,SPD=HIGH,NFR=1,SLEN=0,IVAL=2
frame[0] READ 16 bytes
flags 0xa SHORT_XFER_OK|PIPE_BOF|0
status 0xeb023
OPEN|TRANSFERRING|STARTED|SHORT_XFER_OK|BDMA_ENABLE|BDMA_SETUP|CURR_DMA_SET|CAN_CANCEL_IMMED|DOING_CALLBACK|0
--
OmniLAN - UNIX Windows Netze + Systeme
Harald Schmalzbauer
Weidmannstraße 16
80997 München
Telefon: +49 (0)89 18947781
Notruf: +49 (0)89 85639293
USt-IdNr.: DE253184753
http://www.omnilan.de/
signature.asc
Description: OpenPGP digital signature
Re: umcs (4-Port-USB-serial) triggering way too much ehci IRQs
Hello, Harald. You wrote 17 сентября 2013 г., 12:46:25: HS The Y is the device addr @ bus #X. Oh :) HS Same posted some seconds ago :-) Yep, exactly the same pattern. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ 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: umcs (4-Port-USB-serial) triggering way too much ehci IRQs
On 09/17/13 10:47, Lev Serebryakov wrote: Hello, Harald. You wrote 17 сентября 2013 г., 12:46:25: HS The Y is the device addr @ bus #X. Oh :) HS Same posted some seconds ago :-) Yep, exactly the same pattern. Hi, Could you show the configuration descriptor for your device? usbconfig -d X.Y dump_curr_config_desc ? The interrupt endpoint in question can be throttled by the USB stack, if the latency of these events are not important to your application. --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: umcs (4-Port-USB-serial) triggering way too much ehci IRQs
Bezüglich Hans Petter Selasky's Nachricht vom 17.09.2013 10:57 (localtime): On 09/17/13 10:47, Lev Serebryakov wrote: Hello, Harald. You wrote 17 сентября 2013 г., 12:46:25: HS The Y is the device addr @ bus #X. Oh :) HS Same posted some seconds ago :-) Yep, exactly the same pattern. Hi, Could you show the configuration descriptor for your device? usbconfig -d X.Y dump_curr_config_desc Shall we switch to non-list-comm? Again, thanks for your help! tk:/usr/home/admin/#:21 usbconfig -d 1.4 dump_curr_config_desc ugen1.4: product 0x7840 vendor 0x9710 at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (100mA) Configuration index 0 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x0051 bNumInterfaces = 0x0001 bConfigurationValue = 0x0001 iConfiguration = 0x no string bmAttributes = 0x00a0 bMaxPower = 0x0032 Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x bAlternateSetting = 0x bNumEndpoints = 0x0009 bInterfaceClass = 0x00ff bInterfaceSubClass = 0x bInterfaceProtocol = 0x00ff iInterface = 0x no string Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0081 IN bmAttributes = 0x0002 BULK wMaxPacketSize = 0x0200 bInterval = 0x00ff bRefresh = 0x bSynchAddress = 0x Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0002 OUT bmAttributes = 0x0002 BULK wMaxPacketSize = 0x0200 bInterval = 0x00ff bRefresh = 0x bSynchAddress = 0x Endpoint 2 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0083 IN bmAttributes = 0x0002 BULK wMaxPacketSize = 0x0200 bInterval = 0x00ff bRefresh = 0x bSynchAddress = 0x Endpoint 3 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0004 OUT bmAttributes = 0x0002 BULK wMaxPacketSize = 0x0200 bInterval = 0x00ff bRefresh = 0x bSynchAddress = 0x Endpoint 4 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0085 IN bmAttributes = 0x0002 BULK wMaxPacketSize = 0x0200 bInterval = 0x00ff bRefresh = 0x bSynchAddress = 0x Endpoint 5 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0006 OUT bmAttributes = 0x0002 BULK wMaxPacketSize = 0x0200 bInterval = 0x00ff bRefresh = 0x bSynchAddress = 0x Endpoint 6 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0087 IN bmAttributes = 0x0002 BULK wMaxPacketSize = 0x0200 bInterval = 0x00ff bRefresh = 0x bSynchAddress = 0x Endpoint 7 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0008 OUT bmAttributes = 0x0002 BULK wMaxPacketSize = 0x0200 bInterval = 0x00ff bRefresh = 0x bSynchAddress = 0x Endpoint 8 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0089 IN bmAttributes = 0x0003 INTERRUPT wMaxPacketSize = 0x0010 bInterval = 0x0005 bRefresh = 0x bSynchAddress = 0x The interrupt endpoint in question can be throttled by the USB stack, if the latency of these events are not important to your application. Hmm, in my case, this 4-port-serial-USB-hub will be used as console concentrator. So most time it's doing nothing, just feeding tmux with consoles output. What latency are we talking about? Less than a some milliseconds should be fine. What I'm curious about is why my prolific USB-serial converter doesn't generate these high irqs. Thanks, -Harry signature.asc Description: OpenPGP digital signature
Re: umcs (4-Port-USB-serial) triggering way too much ehci IRQs
On 09/17/13 11:06, Harald Schmalzbauer wrote: Bezüglich Hans Petter Selasky's Nachricht vom 17.09.2013 10:57 (localtime): On 09/17/13 10:47, Lev Serebryakov wrote: Hello, Harald. You wrote 17 сентября 2013 г., 12:46:25: HS The Y is the device addr @ bus #X. Oh :) HS Same posted some seconds ago :-) Yep, exactly the same pattern. Hi, Could you show the configuration descriptor for your device? usbconfig -d X.Y dump_curr_config_desc Shall we switch to non-list-comm? Hi, That's OK. Hmm, in my case, this 4-port-serial-USB-hub will be used as console concentrator. So most time it's doing nothing, just feeding tmux with consoles output. What latency are we talking about? Less than a some milliseconds should be fine. What I'm curious about is why my prolific USB-serial converter doesn't generate these high irqs. Try this patch and see what happens: == --- umcs.c (revision 255492) +++ umcs.c (local) @@ -230,6 +230,7 @@ .bufsize = 0, /* use wMaxPacketSize */ .callback = umcs7840_intr_callback, .if_index = 0, + .interval = 20, /* ms */ }, }; BTW: I see that the umcs driver shouldn't do synchronous control transfers from the USB interrupt transfer callback. This should be postponed into some worker thread, for example the USB explore thread. See USB audio driver for an example. --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: usb/181425: commit references a PR
The following reply was made to PR usb/181425; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: usb/181425: commit references a PR
Date: Tue, 17 Sep 2013 12:58:29 + (UTC)
Author: hselasky
Date: Tue Sep 17 12:58:17 2013
New Revision: 255633
URL: http://svnweb.freebsd.org/changeset/base/255633
Log:
MFC r254572:
Force keyboards which don't have the required
HID fields to use the USB BOOT protocol for now.
PR: usb/181425
Modified:
stable/8/sys/dev/usb/input/ukbd.c
Directory Properties:
stable/8/sys/ (props changed)
stable/8/sys/dev/ (props changed)
stable/8/sys/dev/usb/ (props changed)
Modified: stable/8/sys/dev/usb/input/ukbd.c
==
--- stable/8/sys/dev/usb/input/ukbd.c Tue Sep 17 12:56:37 2013
(r255632)
+++ stable/8/sys/dev/usb/input/ukbd.c Tue Sep 17 12:58:17 2013
(r255633)
@@ -1118,8 +1118,12 @@ ukbd_parse_hid(struct ukbd_softc *sc, co
HID_USAGE2(HUP_KEYBOARD, 0x00),
hid_input, 0, sc-sc_loc_events, flags,
sc-sc_id_events)) {
- sc-sc_flags |= UKBD_FLAG_EVENTS;
- DPRINTFN(1, Found keyboard events\n);
+ if (flags HIO_VARIABLE) {
+ DPRINTFN(1, Ignoring keyboard event control\n);
+ } else {
+ sc-sc_flags |= UKBD_FLAG_EVENTS;
+ DPRINTFN(1, Found keyboard event array\n);
+ }
}
/* figure out leds on keyboard */
___
svn-src-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
___
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/181425: commit references a PR
The following reply was made to PR usb/181425; it has been noted by GNATS.
From: dfil...@freebsd.org (dfilter service)
To: bug-follo...@freebsd.org
Cc:
Subject: Re: usb/181425: commit references a PR
Date: Tue, 17 Sep 2013 12:53:16 + (UTC)
Author: hselasky
Date: Tue Sep 17 12:53:09 2013
New Revision: 255631
URL: http://svnweb.freebsd.org/changeset/base/255631
Log:
MFC r254572:
Force keyboards which don't have the required
HID fields to use the USB BOOT protocol for now.
PR: usb/181425
Modified:
stable/9/sys/dev/usb/input/ukbd.c
Directory Properties:
stable/9/sys/ (props changed)
stable/9/sys/dev/ (props changed)
Modified: stable/9/sys/dev/usb/input/ukbd.c
==
--- stable/9/sys/dev/usb/input/ukbd.c Tue Sep 17 12:50:57 2013
(r255630)
+++ stable/9/sys/dev/usb/input/ukbd.c Tue Sep 17 12:53:09 2013
(r255631)
@@ -1126,8 +1126,12 @@ ukbd_parse_hid(struct ukbd_softc *sc, co
HID_USAGE2(HUP_KEYBOARD, 0x00),
hid_input, 0, sc-sc_loc_events, flags,
sc-sc_id_events)) {
- sc-sc_flags |= UKBD_FLAG_EVENTS;
- DPRINTFN(1, Found keyboard events\n);
+ if (flags HIO_VARIABLE) {
+ DPRINTFN(1, Ignoring keyboard event control\n);
+ } else {
+ sc-sc_flags |= UKBD_FLAG_EVENTS;
+ DPRINTFN(1, Found keyboard event array\n);
+ }
}
/* figure out leds on keyboard */
___
svn-src-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
___
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: umcs (4-Port-USB-serial) triggering way too much ehci IRQs
On 09/17/13 17:38, Harald Schmalzbauer wrote: Bezüglich Hans Petter Selasky's Nachricht vom 17.09.2013 11:24 (localtime): On 09/17/13 11:06, Harald Schmalzbauer wrote: ... Shall we switch to non-list-comm? Hi, That's OK. Hmm, in my case, this 4-port-serial-USB-hub will be used as console concentrator. So most time it's doing nothing, just feeding tmux with consoles output. What latency are we talking about? Less than a some milliseconds should be fine. What I'm curious about is why my prolific USB-serial converter doesn't generate these high irqs. Try this patch and see what happens: == --- umcs.c(revision 255492) +++ umcs.c(local) @@ -230,6 +230,7 @@ .bufsize = 0,/* use wMaxPacketSize */ .callback = umcs7840_intr_callback, .if_index = 0, +.interval = 20, /* ms */ }, }; BTW: I see that the umcs driver shouldn't do synchronous control transfers from the USB interrupt transfer callback. This should be postponed into some worker thread, for example the USB explore thread. See USB audio driver for an example. --HPS I tried your patch and it works as expected: IRQs decreased to ~64/s when idle/disconnected. One interesting thing I never measured before: Console connection with 115k2 via umcs and 'while ( 21 ) echo ---... end' results in 8000 irqs/s :-( But that's also true for the prolific (uplcom). The latter just goes down to 0.0 irqs/s when idle. Doing the same with uart0 results in 1444irqs/s. Is it by design/unavoidable that transfering the same via USB multiplies by factor 5-6? Thanks, -Harry Hi, I think the adapters use very small buffers. You can try adding .interval = 4 to the other USB configs, above the one you patched, and see what happens. I cannot tell if you will loose characters or not. --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: umcs (4-Port-USB-serial) triggering way too much ehci IRQs
Bezüglich Hans Petter Selasky's Nachricht vom 17.09.2013 11:24 (localtime): On 09/17/13 11:06, Harald Schmalzbauer wrote: ... Shall we switch to non-list-comm? Hi, That's OK. Hmm, in my case, this 4-port-serial-USB-hub will be used as console concentrator. So most time it's doing nothing, just feeding tmux with consoles output. What latency are we talking about? Less than a some milliseconds should be fine. What I'm curious about is why my prolific USB-serial converter doesn't generate these high irqs. Try this patch and see what happens: == --- umcs.c(revision 255492) +++ umcs.c(local) @@ -230,6 +230,7 @@ .bufsize = 0,/* use wMaxPacketSize */ .callback = umcs7840_intr_callback, .if_index = 0, +.interval = 20, /* ms */ }, }; BTW: I see that the umcs driver shouldn't do synchronous control transfers from the USB interrupt transfer callback. This should be postponed into some worker thread, for example the USB explore thread. See USB audio driver for an example. --HPS I tried your patch and it works as expected: IRQs decreased to ~64/s when idle/disconnected. One interesting thing I never measured before: Console connection with 115k2 via umcs and 'while ( 21 ) echo ---... end' results in 8000 irqs/s :-( But that's also true for the prolific (uplcom). The latter just goes down to 0.0 irqs/s when idle. Doing the same with uart0 results in 1444irqs/s. Is it by design/unavoidable that transfering the same via USB multiplies by factor 5-6? Thanks, -Harry signature.asc Description: OpenPGP digital signature
Re: umcs (4-Port-USB-serial) triggering way too much ehci IRQs
On Tue, 2013-09-17 at 17:38 +0200, Harald Schmalzbauer wrote: Bezüglich Hans Petter Selasky's Nachricht vom 17.09.2013 11:24 (localtime): On 09/17/13 11:06, Harald Schmalzbauer wrote: ... Shall we switch to non-list-comm? Hi, That's OK. Hmm, in my case, this 4-port-serial-USB-hub will be used as console concentrator. So most time it's doing nothing, just feeding tmux with consoles output. What latency are we talking about? Less than a some milliseconds should be fine. What I'm curious about is why my prolific USB-serial converter doesn't generate these high irqs. Try this patch and see what happens: == --- umcs.c(revision 255492) +++ umcs.c(local) @@ -230,6 +230,7 @@ .bufsize = 0,/* use wMaxPacketSize */ .callback = umcs7840_intr_callback, .if_index = 0, +.interval = 20, /* ms */ }, }; BTW: I see that the umcs driver shouldn't do synchronous control transfers from the USB interrupt transfer callback. This should be postponed into some worker thread, for example the USB explore thread. See USB audio driver for an example. --HPS I tried your patch and it works as expected: IRQs decreased to ~64/s when idle/disconnected. One interesting thing I never measured before: Console connection with 115k2 via umcs and 'while ( 21 ) echo ---... end' results in 8000 irqs/s :-( But that's also true for the prolific (uplcom). The latter just goes down to 0.0 irqs/s when idle. Doing the same with uart0 results in 1444irqs/s. Is it by design/unavoidable that transfering the same via USB multiplies by factor 5-6? Thanks, -Harry I don't know about that chipset, but with the FTDI chips it does xfers in 64 byte chunks and high speed bulk data results in an astronomical number of interrupts (and if you go fast enough, lost data). I have some patches that assemble lots of the little chip-size buffers into bigger xfers that the ohci/ehci controller can handle without interrupting the processor; that helps the problem a bunch. -- Ian ___ 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
spin down a USB-attached disk?
I have a possibly dumb question. Is it possible to send a spindown command through USB to a SATA disk attached as umass? I like to spin down my disks before turning them off and with an ad-disk it's quite simple using camcontrol. I haven't been able figure how to do it through USB. -- Gary Jennejohn ___ 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: umcs (4-Port-USB-serial) triggering way too much ehci IRQs
Bezüglich Lev Serebryakov's Nachricht vom 16.09.2013 23:37 (localtime): ... To be honest, I didn't know much about USB at all, I wrote this driver without complete understanding USB magic and use USB only as transport to access MCS7840 registers... Maybe, local USB Guru Hans Petter Selasky could give cime advicec how to debug this situation. I've added freebsd-usb@ to CC: Is that worth a try? http://www.asix.com.tw/FrootAttach/driver/MCS7840_7820_FreeBSD_driver_v1.1.zip I'd just compile and see what it does, skills don't last for merging/helping with umcs :-( At least, it seems to be possible to enable RS485-mode :-) :-) signature.asc Description: OpenPGP digital signature
Re: umcs (4-Port-USB-serial) triggering way too much ehci IRQs
On Tue, 2013-09-17 at 19:32 +0200, Harald Schmalzbauer wrote: Bezüglich Ian Lepore's Nachricht vom 17.09.2013 18:16 (localtime): On Tue, 2013-09-17 at 17:38 +0200, Harald Schmalzbauer wrote: ... Try this patch and see what happens: == --- umcs.c(revision 255492) +++ umcs.c(local) @@ -230,6 +230,7 @@ .bufsize = 0,/* use wMaxPacketSize */ .callback = umcs7840_intr_callback, .if_index = 0, +.interval = 20, /* ms */ }, }; BTW: I see that the umcs driver shouldn't do synchronous control transfers from the USB interrupt transfer callback. This should be postponed into some worker thread, for example the USB explore thread. See USB audio driver for an example. --HPS I tried your patch and it works as expected: IRQs decreased to ~64/s when idle/disconnected. One interesting thing I never measured before: Console connection with 115k2 via umcs and 'while ( 21 ) echo ---... end' results in 8000 irqs/s :-( But that's also true for the prolific (uplcom). The latter just goes down to 0.0 irqs/s when idle. Doing the same with uart0 results in 1444irqs/s. Is it by design/unavoidable that transfering the same via USB multiplies by factor 5-6? Thanks, -Harry I don't know about that chipset, but with the FTDI chips it does xfers in 64 byte chunks and high speed bulk data results in an astronomical number of interrupts (and if you go fast enough, lost data). I have According to ASIX product brief, MCS7840 has 512 byte buffer. Pretty much for an UART I think, which should make 115k2 baud connections with less than 30 transfers/s work, or am I missing something? That's the internal buffer, it still does usb transfers in smaller chunks. Some ftdi chips have 4k onboard buffers but do 64-byte usb transfers. -- Ian ___ 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: umcs (4-Port-USB-serial) triggering way too much ehci IRQs
Hello, Hans. You wrote 17 сентября 2013 г., 20:04:58: HPS I think the adapters use very small buffers. You can try adding HPS .interval = 4 to the other USB configs, above the one you patched, and HPS see what happens. I cannot tell if you will loose characters or not. Datasheet promise 2x512 bytes FIFO for each port (on USB level, and typical 16 bytes buffers on UART level, because it emulates 16c550 compatible UARTs)... Maybe, my setup of these FIFO buffers are not optimal, but datasheet (even NDA-marked onem and I don't mention public, which is total bullshit) doesn't say anything about configuring these buffers. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ 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: umcs (4-Port-USB-serial) triggering way too much ehci IRQs
Hello, Harald. You wrote 17 сентября 2013 г., 21:43:17: HS Is that worth a try? HS http://www.asix.com.tw/FrootAttach/driver/MCS7840_7820_FreeBSD_driver_v1.1.zip Nope. I've started from this driver, and it even doesn't support BREAK signal (it is was first reason why I start to write new one -- I needed BREAK to enter kernel debugger). HS At least, it seems to be possible to enable RS485-mode :-) :-) I could easily add RS485 mode, BUT! FreeBSD doesn;'t have any userland API for it, and the same is true for higher and non-standard baud rates. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ 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: umcs (4-Port-USB-serial) triggering way too much ehci IRQs
On Tue, 2013-09-17 at 23:08 +0400, Lev Serebryakov wrote: Hello, Harald. You wrote 17 сентября 2013 г., 21:43:17: HS Is that worth a try? HS http://www.asix.com.tw/FrootAttach/driver/MCS7840_7820_FreeBSD_driver_v1.1.zip Nope. I've started from this driver, and it even doesn't support BREAK signal (it is was first reason why I start to write new one -- I needed BREAK to enter kernel debugger). HS At least, it seems to be possible to enable RS485-mode :-) :-) I could easily add RS485 mode, BUT! FreeBSD doesn;'t have any userland API for it, and the same is true for higher and non-standard baud rates. There's no API needed for higher baud rates. I've used cfsetspeed() to set 3mbps on ftdi chips. I've also used it for completely arbitrary speeds like 554000bps (happens to be the fastest I can run an ftdi chip on a 180mhz arm without dropping chars, but going that fast requires other changes to the driver.). -- Ian ___ 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: umcs (4-Port-USB-serial) triggering way too much ehci IRQs
Bezüglich Ian Lepore's Nachricht vom 17.09.2013 18:16 (localtime): On Tue, 2013-09-17 at 17:38 +0200, Harald Schmalzbauer wrote: ... Try this patch and see what happens: == --- umcs.c(revision 255492) +++ umcs.c(local) @@ -230,6 +230,7 @@ .bufsize = 0,/* use wMaxPacketSize */ .callback = umcs7840_intr_callback, .if_index = 0, +.interval = 20, /* ms */ }, }; BTW: I see that the umcs driver shouldn't do synchronous control transfers from the USB interrupt transfer callback. This should be postponed into some worker thread, for example the USB explore thread. See USB audio driver for an example. --HPS I tried your patch and it works as expected: IRQs decreased to ~64/s when idle/disconnected. One interesting thing I never measured before: Console connection with 115k2 via umcs and 'while ( 21 ) echo ---... end' results in 8000 irqs/s :-( But that's also true for the prolific (uplcom). The latter just goes down to 0.0 irqs/s when idle. Doing the same with uart0 results in 1444irqs/s. Is it by design/unavoidable that transfering the same via USB multiplies by factor 5-6? Thanks, -Harry I don't know about that chipset, but with the FTDI chips it does xfers in 64 byte chunks and high speed bulk data results in an astronomical number of interrupts (and if you go fast enough, lost data). I have According to ASIX product brief, MCS7840 has 512 byte buffer. Pretty much for an UART I think, which should make 115k2 baud connections with less than 30 transfers/s work, or am I missing something? some patches that assemble lots of the little chip-size buffers into bigger xfers that the ohci/ehci controller can handle without interrupting the processor; that helps the problem a bunch. I think I also have at least one FTDI adapter arround, so I'd happily testing if I can make it compile on RELENG_9_2. Thanks, -Harry signature.asc Description: OpenPGP digital signature
Re: umcs (4-Port-USB-serial) triggering way too much ehci IRQs
Lev Serebryakov wrote this message on Tue, Sep 17, 2013 at 23:08 +0400: Hello, Harald. You wrote 17 2013 ??., 21:43:17: HS Is that worth a try? HS http://www.asix.com.tw/FrootAttach/driver/MCS7840_7820_FreeBSD_driver_v1.1.zip Nope. I've started from this driver, and it even doesn't support BREAK signal (it is was first reason why I start to write new one -- I needed BREAK to enter kernel debugger). You do know of: # Solaris implements a new BREAK which is initiated by a character # sequence CR ~ ^b which is similar to a familiar pattern used on # Sun servers by the Remote Console. There are FreeBSD extensions: # CR ~ ^p requests force panic and CR ~ ^r requests a clean reboot. options ALT_BREAK_TO_DEBUGGER to add to your kernel file right? -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ 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: spin down a USB-attached disk?
On Tue, 17 Sep 2013, Gary Jennejohn wrote: I have a possibly dumb question. Is it possible to send a spindown command through USB to a SATA disk attached as umass? I like to spin down my disks before turning them off and with an ad-disk it's quite simple using camcontrol. I haven't been able figure how to do it through USB. Can't camcontrol do the same thing, regardless of how the disk is attached? ___ 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
