Re: umcs (4-Port-USB-serial) triggering way too much ehci IRQs
Let me know when this issue settles, what changes you want in the umcs kernel driver. --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: 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"
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: 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 ( 2>1 ) 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
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
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 ___ 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 г., 13:24:26: HPS> Try this patch and see what happens: It could throttle interrupts, but it doesn't explain, why device spams with interrupts when all ports are closed and all UART interrupts are disabled! HPS> BTW: I see that the umcs driver shouldn't do synchronous control HPS> transfers from the USB interrupt transfer callback. This should be HPS> postponed into some worker thread, for example the USB explore thread. HPS> See USB audio driver for an example. I've copied code from some other ucom driver... I'll take a look at USB audio. -- // Black Lion AKA Lev Serebryakov ___ 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 ___ 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 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 ( 2>1 ) 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
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
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
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 ( 2>1 ) 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"
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 ( 2>1 ) 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 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 ( 2>1 ) 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: 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: 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: 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: 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: 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 bmAttributes = 0x00a0 bMaxPower = 0x0032 Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x bAlternateSetting = 0x bNumEndpoints = 0x0009 bInterfaceClass = 0x00ff bInterfaceSubClass = 0x bInterfaceProtocol = 0x00ff iInterface = 0x Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0081 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x00ff bRefresh = 0x bSynchAddress = 0x Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0002 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x00ff bRefresh = 0x bSynchAddress = 0x Endpoint 2 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0083 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x00ff bRefresh = 0x bSynchAddress = 0x Endpoint 3 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0004 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x00ff bRefresh = 0x bSynchAddress = 0x Endpoint 4 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0085 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x00ff bRefresh = 0x bSynchAddress = 0x Endpoint 5 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0006 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x00ff bRefresh = 0x bSynchAddress = 0x Endpoint 6 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0087 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x00ff bRefresh = 0x bSynchAddress = 0x Endpoint 7 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0008 bmAttributes = 0x0002 wMaxPacketSize = 0x0200 bInterval = 0x00ff bRefresh = 0x bSynchAddress = 0x Endpoint 8 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0089 bmAttributes = 0x0003 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 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
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 ___ 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 > status 0xeb023 > > 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 > status 0xcb021 > > 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 > status 0xcb023 > > 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 > status 0xeb021 > > 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 > status 0xeb023 > > > -- 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, 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 status 0xeb023 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 status 0xcb021 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 status 0xcb023 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 status 0xeb021 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 status 0xeb023 -- // Black Lion AKA Lev Serebryakov ___ 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 status 0xcb023 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 status 0xeb021 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 status 0xeb023 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 status 0xcb021 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. 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 ___ 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"