Re: reproducible dump possibly related to ath and virtualbox
On Sun, 15 Sep 2013 23:34:45 -0700 Adrian Chadd wrote: > Hi, > > Please try -HEAD or -10. I fixed a number o AR9285 bugs there. Uh, I did this a few times before, and indeed it fixed some problems with wifi. Unfortunately, generally it broke more things than it fixed so I always ended up with clean re-install. Hope those bug fixes will be backported to 9-STABLE. -- Marko Cupać ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-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. 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-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-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, 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-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-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-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-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 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-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-13:03.mfi
Hello, I'm sorry to make you waste time on me, but I were not able to check signature on message from errata-noti...@freebsd.org Can you please point me to, or email me where to retrieve the public PGP key for email errata-noti...@freebsd.org ? That email was not found on http://www.freebsd.org/doc/pgpkeyring.txt Thank you, Andrea At 22/08/2013 03:15, FreeBSD Errata Notices wrote: >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA1 > >= >FreeBSD-EN-13:03.mfiErrata Notice > The FreeBSD Project > >Topic: data corruption with mfi(4) JBOD disks > 2TB > >Category: contrib >Module: mfi >Announced: 2013-08-22 >Credits:Steven Hartland, Doug Ambrisko >Affects:FreeBSD 9.1 >Corrected: 2012-12-03 18:37:02 UTC (stable/9, 9.1-STABLE) >2013-08-22 00:51:48 UTC (releng/9.1, 9.1-RELEASE-p6) > >For general information regarding FreeBSD Errata Notices and Security >Advisories, including descriptions of the fields above, security >branches, and the following sections, please visit >http://security.freebsd.org/>. > >I. Background > >The mfi(4) driver supports LSI's next generation PCI Express SAS RAID >controllers. The driver supports JBOD attachment through /dev/mfisyspd? >device nodes. > >Logical block addressing (LBA) is a common scheme used for specifying the >location of sectors on hard drives. > >II. Problem Description > >The way mfi(4) implements access of "syspd" or also known as JBOD always >uses READ10/WRITE10 commands for underlying disk. When writing over 2^32 >sectors, the LBA would wrap and starts writing at the beginning of the >disk. > >III. Impact > >Writing beyond 2TB to mfi(4) connected JBODs would result in data corruption. > >IV. Workaround > >No workaround is available, but systems that do not use mfi(4) as a JBOD >HBA or do not have disks with 2^32 or more sectors (2^41 or more bytes with >512-byte logical sector size) are not affected. > >V. Solution > >Perform one of the following: > >1) Upgrade your system to a supported FreeBSD stable or release / security >branch (releng) dated after the correction date. > >2) To update your present system via a source code patch: > >The following patches have been verified to apply to the applicable >FreeBSD release branches. > >a) Download the relevant patch from the location below, and verify the >detached PGP signature using your PGP utility. > ># fetch http://security.FreeBSD.org/patches/EN-13:03/mfi.patch ># fetch http://security.FreeBSD.org/patches/EN-13:03/mfi.patch.asc ># gpg --verify mfi.patch.asc > >b) Apply the patch. > ># cd /usr/src ># patch < /path/to/patch > >c) Recompile your kernel as described in >http://www.FreeBSD.org/handbook/kernelconfig.html> and reboot the >system. > >3) To update your system via a binary patch: > >Systems running a RELEASE version of FreeBSD on the i386 or amd64 >platforms can be updated via the freebsd-update(8) utility: > ># freebsd-update fetch ># freebsd-update install > >VI. Correction details > >The following list contains the revision numbers of each file that was >corrected in FreeBSD. > >Branch/path Revision >- - >stable/9/ r243824 >releng/9.1/ r254631 >- - > >VII. References > >http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/173291 > >The latest revision of this Errata Notice is available at >http://security.FreeBSD.org/advisories/FreeBSD-EN-13:03.mfi.asc > >-BEGIN PGP SIGNATURE- >Version: GnuPG v2.0.21 (FreeBSD) > >iEYEARECAAYFAlIVY1YACgkQFdaIBMps37IHmwCfZH+1Gi0u7eYMXYevu0KHaG3a >rCwAn2ecdXnLOsaC6D6i2mo4dmI4HLDk >=AwdQ >-END PGP SIGNATURE- >___ >freebsd-annou...@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-announce >To unsubscribe, send any mail to "freebsd-announce-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-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-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: reproducible dump possibly related to ath and virtualbox
On 17 September 2013 00:45, Marko Cupać wrote: > On Sun, 15 Sep 2013 23:34:45 -0700 > Adrian Chadd wrote: > > > Hi, > > > > Please try -HEAD or -10. I fixed a number o AR9285 bugs there. > > Uh, I did this a few times before, and indeed it fixed some problems with > wifi. Unfortunately, generally it broke more things than it fixed > so I always ended up with clean re-install. > > what did it break? > Hope those bug fixes will be backported to 9-STABLE. > I have no current plans (as a general statement) to backport from -HEAD to any other branches. Sorry. -adrian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-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 ( 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-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-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
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
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 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-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-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-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-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-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: reproducible dump possibly related to ath and virtualbox
On Tue, 17 Sep 2013 09:24:20 -0700 Adrian Chadd wrote: > what did it break? Nothing related to wifi, but with -HEAD and -10 being experimental, I had various problems, some related to building ports, some to general stability and compatibility. > I have no current plans (as a general statement) to backport from -HEAD to > any other branches. Sorry. Well then majority of FreeBSD users will have to wait a year or so until they benefit from your hard work, as I guess this is the time needed for current -10 to become -RELEASE. Thank you anyway, and best regards. -- Marko Cupać ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-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-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-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-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-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-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
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-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
