Re: Low umass performance with USB 2.0 ports
> > Oops, it seems that this patch also does not work as expected: after some > > time of playing with flash card and working with the system it started to > > stall as unpatched system, but it freezes the system -- even IP stack was > > frozen (I am using DEVICE_POLLING), so I were to remove the flash from the > > port -- system was unfrozen and continued to work. So something is still > > bad with the USB. I'll try to do some long testing with USB 1.1 -- maybe it > > will show the same behaviour after some more time. > > Do you mean my patch? Yes. And I've noticed the second, worst, thing: my cd-burner refused to burn anything using atapi-cam. I've not tested the native atapi (via burncd), because it is broken (at least with many new drives). After recompiling the clean 5.x kernel the problem gone. I don't have much time today to make experiments, but I'll try to check this issue once again. -- rea ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Low umass performance with USB 2.0 ports
On Thursday 01 September 2005 11:37, Eygene A. Ryabinkin wrote:
> > If Scott's patch doesn't work, could you have tried to install the
> > following (compiles on FreeBSD 5/6/7):
>
> Yes, it also works and does even better work: FAT 32 and FAT 16
> permormance are just the same and there is no additional load as been with
> the Scott's patch.
> So I definitely would vote for this fix.
>
> > Download the three files below into a new directory and type
> > "make install" (to uninstall type "make deinstall")
> > http://home.c2i.net/hselasky/isdn4bsd/privat/usb/Makefile
> > http://home.c2i.net/hselasky/isdn4bsd/privat/usb/new_usb_1_5_4.diff.bz2
> > http://home.c2i.net/hselasky/isdn4bsd/privat/usb/new_usb_1_5_4.tar.bz2
>
> Can this fix be transformed into the patch? It will be very helpful to the
> committers to have in the form of patch. Are there any reasons to make it
> in the way you did?
I did things like I did it, so I would be saved the work of upgrading my patch
every time the source code changes. I am currently working on getting this
ported to NetBSD, so maybe the official USB system of FreeBSD can be upgraded
without splitting with NetBSD.
At the present moment there are too many changes made, so a single patch will
not be so good.
> Thank you for your work!
On Thursday 01 September 2005 14:08, you wrote:
> > Yes, it also works and does even better work: FAT 32 and FAT 16
> > permormance are just the same and there is no additional load as been
> > with the Scott's patch.
Interesting.
> > So I definitely would vote for this fix.
>
> Oops, it seems that this patch also does not work as expected: after some
> time of playing with flash card and working with the system it started to
> stall as unpatched system, but it freezes the system -- even IP stack was
> frozen (I am using DEVICE_POLLING), so I were to remove the flash from the
> port -- system was unfrozen and continued to work. So something is still
> bad with the USB. I'll try to do some long testing with USB 1.1 -- maybe it
> will show the same behaviour after some more time.
Do you mean my patch?
Maybe you can turn on debugging when the system starts freezing:
sysctl hw.usb.debug=15
sysctl hw.usb.umass.debug=-1
sysctl hw.usb.ehci.debug=15 # note: produces alot of output !
Set these variables to zero to turn off debugging.
If the system resumes to normal operation when you pull the device plug, it is
most likely a timeout in "umass" that takes too long. In the file
"/sys/dev/usb/umass.c":
Add:
sc->timeout = 1000;
Before:
/* Read the Command Status Wrapper via bulk-in endpoint. */
if (umass_setup_transfer(sc, sc->bulkin_pipe,
&sc->csw, UMASS_BBB_CSW_SIZE, 0,
next_xfer)) {
umass_bbb_reset(sc, STATUS_WIRE_FAILED);
return;
}
See if you get any timeout messages while stressing the system.
--HPS
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Low umass performance with USB 2.0 ports
On Thu, Sep 01, 2005 at 12:44:21PM +0400, Eygene A. Ryabinkin wrote:
> > Actually, I just peeked inside the Linux EHCI code and it does a dummy
> > read immediately after writing to the status register:
> >
> > /* clear (just) interrupts */
> > writel (status, &ehci->regs->status);
> > readl (&ehci->regs->command); /* unblock posted write */
> >
> > I wonder if that's the whole trick here. Would someone be willing to
> > try the attached patch instead of the one that Ian posted?
> Yes, that solved my problem. But the patch (for 5.x) uses different line
> numbers:
> -
> --- /sys/dev/usb/ehci.c.orig Thu Sep 1 10:59:51 2005
> +++ /sys/dev/usb/ehci.c Thu Sep 1 10:48:59 2005
> @@ -580,6 +580,7 @@
> return (0);
>
> EOWRITE4(sc, EHCI_USBSTS, intrs); /* Acknowledge */
> + EOREAD4(sc, EHCI_USBCMD); /* Flush posted writes on PCI */
> sc->sc_bus.intr_context++;
> sc->sc_bus.no_intrs++;
> if (eintrs & EHCI_STS_IAA) {
> -
> Apart from this the patch works: the writing process still spends much time
> in the wdrain state, but no stalls occurs.
>
> Just a remark: my USB 2.0 controller chip is made by NEC, not VIA.
>
> For a FAT curiosity: FAT 32 gives 700K/sec and FAT 16 -- 3 Mb/sec.
FAT32 vs. FAT16 shouldn't be a difference, but the smaller cluster
sizes that you usually get with FAT32 decrease the average transfer
size.
Basicly you can get around 500-1000 transactions per second over USB,
unless interleaving multiple transactions is done.
Since msdosfs does no aggregation you can end up with e.g. 512 Byte
transactions.
700kB/s points to an FS with 2k cluster size.
Currently I'm unshure if umass allows interleaving transactions, but
your numbers makes me believe that it does not.
--
B.Walter BWCThttp://www.bwct.de
[EMAIL PROTECTED] [EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Low umass performance with USB 2.0 ports
> Yes, it also works and does even better work: FAT 32 and FAT 16 permormance > are just the same and there is no additional load as been with the Scott's > patch. > So I definitely would vote for this fix. Oops, it seems that this patch also does not work as expected: after some time of playing with flash card and working with the system it started to stall as unpatched system, but it freezes the system -- even IP stack was frozen (I am using DEVICE_POLLING), so I were to remove the flash from the port -- system was unfrozen and continued to work. So something is still bad with the USB. I'll try to do some long testing with USB 1.1 -- maybe it will show the same behaviour after some more time. -- rea ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Low umass performance with USB 2.0 ports
On Tue, Aug 30, 2005 at 04:50:31PM +0400, Eygene A. Ryabinkin wrote: > > FreeBSD 4.x had very low performance with FAT filesystem, > > writing process spent lots of time in the wdrain state too. > Yes, it has. Did you try mtools? I get much better performance with mtools compared to msdosfs. Gunther ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Low umass performance with USB 2.0 ports
> If Scott's patch doesn't work, could you have tried to install the following > (compiles on FreeBSD 5/6/7): Yes, it also works and does even better work: FAT 32 and FAT 16 permormance are just the same and there is no additional load as been with the Scott's patch. So I definitely would vote for this fix. > > Download the three files below into a new directory and type > "make install" (to uninstall type "make deinstall") > http://home.c2i.net/hselasky/isdn4bsd/privat/usb/Makefile > http://home.c2i.net/hselasky/isdn4bsd/privat/usb/new_usb_1_5_4.diff.bz2 > http://home.c2i.net/hselasky/isdn4bsd/privat/usb/new_usb_1_5_4.tar.bz2 Can this fix be transformed into the patch? It will be very helpful to the committers to have in the form of patch. Are there any reasons to make it in the way you did? Thank you for your work! -- rea ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Low umass performance with USB 2.0 ports
> Actually, I just peeked inside the Linux EHCI code and it does a dummy
> read immediately after writing to the status register:
>
> /* clear (just) interrupts */
> writel (status, &ehci->regs->status);
> readl (&ehci->regs->command); /* unblock posted write */
>
> I wonder if that's the whole trick here. Would someone be willing to
> try the attached patch instead of the one that Ian posted?
Yes, that solved my problem. But the patch (for 5.x) uses different line
numbers:
-
--- /sys/dev/usb/ehci.c.origThu Sep 1 10:59:51 2005
+++ /sys/dev/usb/ehci.c Thu Sep 1 10:48:59 2005
@@ -580,6 +580,7 @@
return (0);
EOWRITE4(sc, EHCI_USBSTS, intrs); /* Acknowledge */
+ EOREAD4(sc, EHCI_USBCMD); /* Flush posted writes on PCI */
sc->sc_bus.intr_context++;
sc->sc_bus.no_intrs++;
if (eintrs & EHCI_STS_IAA) {
-
Apart from this the patch works: the writing process still spends much time
in the wdrain state, but no stalls occurs.
Just a remark: my USB 2.0 controller chip is made by NEC, not VIA.
For a FAT curiosity: FAT 32 gives 700K/sec and FAT 16 -- 3 Mb/sec.
--
rea
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Low umass performance with USB 2.0 ports
Eygene A. Ryabinkin wrote: I had exactly this problem with Kingston Data Traveler II+, and apparently completely solved it by adding a kludge to disallow Cache Syncronization. Try it yourself. And the kludge is? It's on my home machine, and I'm travelling now. But it's easy. Look at /sys/cam/scsi/scsi_da.c, look for the da_quirk_table array, and add the flag DA_Q_NO_SYNC_CACHE to your pen drive specs. There are lots of quirks for pen drives there, just copy one of then and edit the string identifiers. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Low umass performance with USB 2.0 ports
On Wednesday 31 August 2005 23:21, Scott Long wrote: > >> > >>Actually, I just peeked inside the Linux EHCI code and it does a dummy > >>read immediately after writing to the status register: > >> > >> /* clear (just) interrupts */ > >> writel (status, &ehci->regs->status); > >> readl (&ehci->regs->command); /* unblock posted write */ > >> > >>I wonder if that's the whole trick here. Would someone be willing to > >>try the attached patch instead of the one that Ian posted? > >> > >>Scott > > > > This is not documented in the EHCI chip specification. > > Flushing posted writes is something that all programmers of PCI devices > should understand, so it usually isn't documented in device manuals. > > > There exists the > > doorbell to ensure that the EHCI controller is finished with data > > structures. Also I have noticed that the existing EHCI driver does not > > always dequeue structures from the controller before accessing them. > > Can you point to an example here? In the official USB system, when an endpoint is opened, a QH structure is allocated and inserted into the USB controller's schedule. After that the EHCI driver will just write new values to that structure, while it is still scheduled. In my opinion you should unqueue this structure and wait for doorbell, before touching it. > > > If Scott's patch doesn't work, could you have tried to install the > > following (compiles on FreeBSD 5/6/7): > > Yeah, looks like my guess was wrong. > > Scott --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Low umass performance with USB 2.0 ports
On Wednesday 31 August 2005 23:21, Rojer wrote: > Hans Petter Selasky wrote: > > If Scott's patch doesn't work, could you have tried to install the > > following (compiles on FreeBSD 5/6/7): > > > > Download the three files below into a new directory and type > > "make install" (to uninstall type "make deinstall") > > http://home.c2i.net/hselasky/isdn4bsd/privat/usb/Makefile > > http://home.c2i.net/hselasky/isdn4bsd/privat/usb/new_usb_1_5_4.diff.bz2 > > http://home.c2i.net/hselasky/isdn4bsd/privat/usb/new_usb_1_5_4.tar.bz2 > > > > Then recompile all USB modules and/or kernel, depending on your > > configuration. > > doesn't apply to freshly cvsupped RELENG_6: Just ignore those failing patches. The driver will compile regardless of that. > > [skip] > x sys/dev/usb2/usb_quirks.h > x sys/dev/usb2/usb_subr.h > (bzcat new_usb_1_5_4.diff.bz2 | patch -N -l -d /usr/src) || echo -n > Hmm... Looks like a new-style context diff to me... > The text leading up to this was: > -- > > |*** sys/i386/include/bus_at386.h.ref Wed Oct 20 21:32:58 2004 > |--- sys/i386/include/bus_at386.h Sat Nov 11 11:11:00 2000 > > -- > File to patch: ^C --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Low umass performance with USB 2.0 ports
Hans Petter Selasky wrote: On Wednesday 31 August 2005 21:47, Scott Long wrote: Scott Long wrote: Ian Dowse wrote: In message <[EMAIL PROTECTED]>, "Eygene A. Ryabinkin" wri tes: What is filesystem has your USB drive? The one I was extensively testing has FAT, but I've checked the UFS2 -- just a bit better -- 1.8 Mb/second. But you're right -- no wdrains at all. FreeBSD 4.x had very low performance with FAT filesystem, writing process spent lots of time in the wdrain state too. Yes, it has. But here the same flash drive gives different results for ehci and uhci devices, and the total speed of echi is lower due to wdrains: 300 Kb/sec versus 500 Kb/sec. And I sometimes write my data to the Windows partition with FAT to my home HDD -- it has no wdrains. At least, I've not noticed them. For flash I can. The patch in from the email below may help with the wdrain state - can you see if it makes any difference? Is the problem that the interrupt gets fired but not all of the status information has made it's way back to host memory when the driver gets there? Would it make a difference to instead read back the EHCI_USBSTS register after writing to it in ehci_intr1? That way all transactions down to the controller would be guaranteed to be flushed before you continue on. I wonder if this is a remnant of the famous problems with VIA chipsets doing bad things under medium-to-high PCI contention. I don't see any obvious workarounds for this in the Linux EHCI code, so I wonder if it's a case of them not encountering it, or doing something different that avoids the problem. Scott Actually, I just peeked inside the Linux EHCI code and it does a dummy read immediately after writing to the status register: /* clear (just) interrupts */ writel (status, &ehci->regs->status); readl (&ehci->regs->command); /* unblock posted write */ I wonder if that's the whole trick here. Would someone be willing to try the attached patch instead of the one that Ian posted? Scott This is not documented in the EHCI chip specification. Flushing posted writes is something that all programmers of PCI devices should understand, so it usually isn't documented in device manuals. There exists the doorbell to ensure that the EHCI controller is finished with data structures. Also I have noticed that the existing EHCI driver does not always dequeue structures from the controller before accessing them. Can you point to an example here? If Scott's patch doesn't work, could you have tried to install the following (compiles on FreeBSD 5/6/7): Yeah, looks like my guess was wrong. Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Low umass performance with USB 2.0 ports
Hans Petter Selasky wrote: If Scott's patch doesn't work, could you have tried to install the following (compiles on FreeBSD 5/6/7): Download the three files below into a new directory and type "make install" (to uninstall type "make deinstall") http://home.c2i.net/hselasky/isdn4bsd/privat/usb/Makefile http://home.c2i.net/hselasky/isdn4bsd/privat/usb/new_usb_1_5_4.diff.bz2 http://home.c2i.net/hselasky/isdn4bsd/privat/usb/new_usb_1_5_4.tar.bz2 Then recompile all USB modules and/or kernel, depending on your configuration. doesn't apply to freshly cvsupped RELENG_6: [skip] x sys/dev/usb2/usb_quirks.h x sys/dev/usb2/usb_subr.h (bzcat new_usb_1_5_4.diff.bz2 | patch -N -l -d /usr/src) || echo -n Hmm... Looks like a new-style context diff to me... The text leading up to this was: -- |*** sys/i386/include/bus_at386.h.ref Wed Oct 20 21:32:58 2004 |--- sys/i386/include/bus_at386.h Sat Nov 11 11:11:00 2000 -- File to patch: ^C -- Deomid Ryabkov aka Rojer [EMAIL PROTECTED] [EMAIL PROTECTED] ICQ: 8025844 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Low umass performance with USB 2.0 ports
Scott Long wrote: I wonder if that's the whole trick here. Would someone be willing to try the attached patch instead of the one that Ian posted? just tried the patch... no, it doesn't help. stalls still happen when reading large files from the device. -- Deomid Ryabkov aka Rojer [EMAIL PROTECTED] [EMAIL PROTECTED] ICQ: 8025844 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Low umass performance with USB 2.0 ports
On Wednesday 31 August 2005 21:47, Scott Long wrote: > Scott Long wrote: > > Ian Dowse wrote: > >> In message <[EMAIL PROTECTED]>, "Eygene A. > >> Ryabinkin" wri > >> > >> tes: > What is filesystem has your USB drive? > >>> > >>> The one I was extensively testing has FAT, but I've checked the UFS2 -- > >>> just a bit better -- 1.8 Mb/second. But you're right -- no wdrains at > >>> all. > >>> > FreeBSD 4.x had very low performance with FAT filesystem, > writing process spent lots of time in the wdrain state too. > >>> > >>> Yes, it has. But here the same flash drive gives different results for > >>> ehci and uhci devices, and the total speed of echi is lower due to > >>> wdrains: > >>> 300 Kb/sec versus 500 Kb/sec. And I sometimes write my data to the > >>> Windows > >>> partition with FAT to my home HDD -- it has no wdrains. At least, > >>> I've not > >>> noticed them. For flash I can. > >> > >> The patch in from the email below may help with the wdrain state - > >> can you see if it makes any difference? > > > > Is the problem that the interrupt gets fired but not all of the status > > information has made it's way back to host memory when the driver gets > > there? Would it make a difference to instead read back the EHCI_USBSTS > > register after writing to it in ehci_intr1? That way all transactions > > down to the controller would be guaranteed to be flushed before you > > continue on. I wonder if this is a remnant of the famous problems with > > VIA chipsets doing bad things under medium-to-high PCI contention. I > > don't see any obvious workarounds for this in the Linux EHCI code, so > > I wonder if it's a case of them not encountering it, or doing something > > different that avoids the problem. > > > > Scott > > Actually, I just peeked inside the Linux EHCI code and it does a dummy > read immediately after writing to the status register: > > /* clear (just) interrupts */ > writel (status, &ehci->regs->status); > readl (&ehci->regs->command); /* unblock posted write */ > > I wonder if that's the whole trick here. Would someone be willing to > try the attached patch instead of the one that Ian posted? > > Scott This is not documented in the EHCI chip specification. There exists the doorbell to ensure that the EHCI controller is finished with data structures. Also I have noticed that the existing EHCI driver does not always dequeue structures from the controller before accessing them. If Scott's patch doesn't work, could you have tried to install the following (compiles on FreeBSD 5/6/7): Download the three files below into a new directory and type "make install" (to uninstall type "make deinstall") http://home.c2i.net/hselasky/isdn4bsd/privat/usb/Makefile http://home.c2i.net/hselasky/isdn4bsd/privat/usb/new_usb_1_5_4.diff.bz2 http://home.c2i.net/hselasky/isdn4bsd/privat/usb/new_usb_1_5_4.tar.bz2 Then recompile all USB modules and/or kernel, depending on your configuration. Here is a quick USB-module compile script: #!/bin/sh cd /sys/modules/aue && make depend all install clean cd /sys/modules/axe && make depend all install clean cd /sys/modules/cdce && make depend all install clean cd /sys/modules/cue && make depend all install clean cd /sys/modules/if_ndis && make depend all install clean cd /sys/modules/kue && make depend all install clean cd /sys/modules/ndis && make depend all install clean cd /sys/modules/netgraph/bluetooth/ubtbcmfw && make depend all install clean cd /sys/modules/netgraph/bluetooth/ubt && make depend all install clean cd /sys/modules/rue && make depend all install clean cd /sys/modules/sound/driver/uaudio && make depend all install clean cd /sys/modules/ubsa && make depend all install clean cd /sys/modules/ubser && make depend all install clean cd /sys/modules/ucom && make depend all install clean cd /sys/modules/ucycom && make depend all install clean cd /sys/modules/udav && make depend all install clean cd /sys/modules/udbp && make depend all install clean cd /sys/modules/ufm && make depend all install clean cd /sys/modules/uftdi && make depend all install clean cd /sys/modules/ugen && make depend all install clean cd /sys/modules/uhid && make depend all install clean cd /sys/modules/ukbd && make depend all install clean cd /sys/modules/ulpt && make depend all install clean cd /sys/modules/umass && make depend all install clean cd /sys/modules/umct && make depend all install clean cd /sys/modules/umodem && make depend all install clean cd /sys/modules/ums && make depend all install clean cd /sys/modules/uplcom && make depend all install clean cd /sys/modules/ural && make depend all install clean cd /sys/modules/urio && make depend all install clean cd /sys/modules/usb && make depend all install clean cd /sys/modules/uscanner && make depend all install clean cd /sys/modules/uvisor && make depend all install clean cd /sys/modules/uvscom && make depend all install clean --HPS __
Re: Low umass performance with USB 2.0 ports
Scott Long wrote:
Ian Dowse wrote:
In message <[EMAIL PROTECTED]>, "Eygene A.
Ryabinkin" wri
tes:
What is filesystem has your USB drive?
The one I was extensively testing has FAT, but I've checked the UFS2 --
just a bit better -- 1.8 Mb/second. But you're right -- no wdrains at
all.
FreeBSD 4.x had very low performance with FAT filesystem,
writing process spent lots of time in the wdrain state too.
Yes, it has. But here the same flash drive gives different results for
ehci and uhci devices, and the total speed of echi is lower due to
wdrains:
300 Kb/sec versus 500 Kb/sec. And I sometimes write my data to the
Windows
partition with FAT to my home HDD -- it has no wdrains. At least,
I've not
noticed them. For flash I can.
The patch in from the email below may help with the wdrain state -
can you see if it makes any difference?
Is the problem that the interrupt gets fired but not all of the status
information has made it's way back to host memory when the driver gets
there? Would it make a difference to instead read back the EHCI_USBSTS
register after writing to it in ehci_intr1? That way all transactions
down to the controller would be guaranteed to be flushed before you
continue on. I wonder if this is a remnant of the famous problems with
VIA chipsets doing bad things under medium-to-high PCI contention. I
don't see any obvious workarounds for this in the Linux EHCI code, so
I wonder if it's a case of them not encountering it, or doing something
different that avoids the problem.
Scott
Actually, I just peeked inside the Linux EHCI code and it does a dummy
read immediately after writing to the status register:
/* clear (just) interrupts */
writel (status, &ehci->regs->status);
readl (&ehci->regs->command); /* unblock posted write */
I wonder if that's the whole trick here. Would someone be willing to
try the attached patch instead of the one that Ian posted?
Scott
Index: ehci.c
===
RCS file: /usr/ncvs/src/sys/dev/usb/ehci.c,v
retrieving revision 1.36
diff -u -r1.36 ehci.c
--- ehci.c 29 May 2005 04:42:27 - 1.36
+++ ehci.c 31 Aug 2005 19:44:14 -
@@ -578,6 +578,7 @@
return (0);
EOWRITE4(sc, EHCI_USBSTS, intrs); /* Acknowledge */
+ EOREAD4(sc, EHCI_USBCMD); /* Flush posted writes on PCI */
sc->sc_bus.intr_context++;
sc->sc_bus.no_intrs++;
if (eintrs & EHCI_STS_IAA) {
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Low umass performance with USB 2.0 ports
Ian Dowse wrote: In message <[EMAIL PROTECTED]>, "Eygene A. Ryabinkin" wri tes: What is filesystem has your USB drive? The one I was extensively testing has FAT, but I've checked the UFS2 -- just a bit better -- 1.8 Mb/second. But you're right -- no wdrains at all. FreeBSD 4.x had very low performance with FAT filesystem, writing process spent lots of time in the wdrain state too. Yes, it has. But here the same flash drive gives different results for ehci and uhci devices, and the total speed of echi is lower due to wdrains: 300 Kb/sec versus 500 Kb/sec. And I sometimes write my data to the Windows partition with FAT to my home HDD -- it has no wdrains. At least, I've not noticed them. For flash I can. The patch in from the email below may help with the wdrain state - can you see if it makes any difference? Is the problem that the interrupt gets fired but not all of the status information has made it's way back to host memory when the driver gets there? Would it make a difference to instead read back the EHCI_USBSTS register after writing to it in ehci_intr1? That way all transactions down to the controller would be guaranteed to be flushed before you continue on. I wonder if this is a remnant of the famous problems with VIA chipsets doing bad things under medium-to-high PCI contention. I don't see any obvious workarounds for this in the Linux EHCI code, so I wonder if it's a case of them not encountering it, or doing something different that avoids the problem. Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Low umass performance with USB 2.0 ports
Ian Dowse wrote: The patch in from the email below may help with the wdrain state - can you see if it makes any difference? this solved the problem i had with umass devices on VIA controller. works fine, thanks a lot! the problem i hade is described in the followup to usb/81621 (http://www.freebsd.org/cgi/query-pr.cgi?pr=usb/81621) the original submitter seems to have VIA controller too. -- Deomid Ryabkov aka Rojer [EMAIL PROTECTED] [EMAIL PROTECTED] ICQ: 8025844 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Low umass performance with USB 2.0 ports
As Ian Dowse wrote to me at Tue, Aug 30, 2005 at 08:08:57PM +0100: > The patch in from the email below may help with the wdrain state - > can you see if it makes any difference? > No, it does not make any. Mainly because my USB 2.0 controller is NEC-based (not VIA), so LOSTINTRBUG flag is not set. Anyway, thanks for your help! -- rea ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Low umass performance with USB 2.0 ports
> I had exactly this problem with Kingston Data Traveler II+, and > apparently completely solved it by adding a kludge to disallow Cache > Syncronization. Try it yourself. And the kludge is? -- rea ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Low umass performance with USB 2.0 ports
Eygene A. Ryabinkin wrote: Good day. I am observing very low umass performance: when I am trying to move a large file from/to my USB 2.0 flash that is plugged into the USB 2.0 port: transfer starts fine at 3.5 Mb/sec, but after some 20 Mbytes it hangs and the process (dd) stay in the wdrain state. The activity LED on the flash shows no activity. Operations do continue, but very slow and the most time of the copying process spends in the wdrain state. All attempts to invoke `sync` or to see the file state via `ls` are hanging until `dd` leaves the wdrain state. It does not matter what flash is used: I tried Apacer and the Kingmax ones -- the result is the same. If I plug the flash into the USB 1.1 port and trying to move some data -- it works fine, no hangs. Speed is 500 Kb/sec. Seems like others do have this problem: http://lists.freebsd.org/pipermail/freebsd-usb/2005-May/001052.html USB 2.0 controller is Promise PCI (NEC chipset), USB 1.1 chipset is onboard VIA. My dmesg output is: ... umass0: Phase Error, residue = 0 (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi status == 0x0 umass0: Phase Error, residue = 0 (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi status == 0x0 umass0: Phase Error, residue = 0 (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi status == 0x0 umass0: Phase Error, residue = 0 (da0:umass-sim0:0:0:0): Synchronize cache failed, status == 0x4, scsi status == 0x0 Mounting root from ufs:/dev/ad0s1a em0: Link is up 100 Mbps Full Duplex info: [drm] Loading R200 Microcode I had exactly this problem with Kingston Data Traveler II+, and apparently completely solved it by adding a kludge to disallow Cache Syncronization. Try it yourself. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Low umass performance with USB 2.0 ports
In message <[EMAIL PROTECTED]>, "Eygene A. Ryabinkin" wri
tes:
>>
>> What is filesystem has your USB drive?
> The one I was extensively testing has FAT, but I've checked the UFS2 --
>just a bit better -- 1.8 Mb/second. But you're right -- no wdrains at all.
>> FreeBSD 4.x had very low performance with FAT filesystem,
>> writing process spent lots of time in the wdrain state too.
> Yes, it has. But here the same flash drive gives different results for
>ehci and uhci devices, and the total speed of echi is lower due to wdrains:
>300 Kb/sec versus 500 Kb/sec. And I sometimes write my data to the Windows
>partition with FAT to my home HDD -- it has no wdrains. At least, I've not
>noticed them. For flash I can.
The patch in from the email below may help with the wdrain state -
can you see if it makes any difference?
Ian
Date:Sun, 26 Jun 2005 17:42:44 BST
To: Stefan Walter <[EMAIL PROTECTED]>
cc: freebsd-stable@freebsd.org
From:Ian Dowse <[EMAIL PROTECTED]>
Subject: Re: EHCI: mtools stuck in state 'physrd' or panic
OpenBSD have a workaround for problems with VIA EHCI controllers
that can cause the hanging symptoms you describe. Below is a patch
that implements their change in FreeBSD's driver. Could you try it
to see if it helps?
Thanks,
Ian
Index: sys/dev/usb/ehci.c
===
RCS file: /dump/FreeBSD-CVS/src/sys/dev/usb/ehci.c,v
retrieving revision 1.14.2.9
diff -u -r1.14.2.9 ehci.c
--- sys/dev/usb/ehci.c 31 Mar 2005 19:47:11 - 1.14.2.9
+++ sys/dev/usb/ehci.c 26 Jun 2005 16:21:11 -
@@ -155,6 +155,7 @@
Static voidehci_idone(struct ehci_xfer *);
Static voidehci_timeout(void *);
Static voidehci_timeout_task(void *);
+Static voidehci_intrlist_timeout(void *);
Static usbd_status ehci_allocm(struct usbd_bus *, usb_dma_t *, u_int32_t);
Static voidehci_freem(struct usbd_bus *, usb_dma_t *);
@@ -491,6 +492,7 @@
EOWRITE4(sc, EHCI_ASYNCLISTADDR, sqh->physaddr | EHCI_LINK_QH);
usb_callout_init(sc->sc_tmo_pcd);
+ usb_callout_init(sc->sc_tmo_intrlist);
lockinit(&sc->sc_doorbell_lock, PZERO, "ehcidb", 0, 0);
@@ -694,6 +696,11 @@
ehci_check_intr(sc, ex);
}
+ /* Schedule a callout to catch any dropped transactions. */
+ if ((sc->sc_flags & EHCI_SCFLG_LOSTINTRBUG) &&
+ !LIST_EMPTY(&sc->sc_intrhead))
+ usb_callout(sc->sc_tmo_intrlist, hz, ehci_intrlist_timeout, sc);
+
#ifdef USB_USE_SOFTINTR
if (sc->sc_softwake) {
sc->sc_softwake = 0;
@@ -942,6 +949,7 @@
EOWRITE4(sc, EHCI_USBINTR, sc->sc_eintrs);
EOWRITE4(sc, EHCI_USBCMD, 0);
EOWRITE4(sc, EHCI_USBCMD, EHCI_CMD_HCRESET);
+ usb_uncallout(sc->sc_tmo_intrlist, ehci_intrlist_timeout, sc);
usb_uncallout(sc->sc_tmo_pcd, ehci_pcd_enable, sc);
#if defined(__NetBSD__) || defined(__OpenBSD__)
@@ -2701,6 +2708,30 @@
splx(s);
}
+
+/*
+ * Some EHCI chips from VIA seem to trigger interrupts before writing back the
+ * qTD status, or miss signalling occasionally under heavy load. If the host
+ * machine is too fast, we we can miss transaction completion - when we scan
+ * the active list the transaction still seems to be active. This generally
+ * exhibits itself as a umass stall that never recovers.
+ *
+ * We work around this behaviour by setting up this callback after any softintr
+ * that completes with transactions still pending, giving us another chance to
+ * check for completion after the writeback has taken place.
+ */
+void
+ehci_intrlist_timeout(void *arg)
+{
+ ehci_softc_t *sc = arg;
+ int s = splusb();
+
+ DPRINTFN(3, ("ehci_intrlist_timeout\n"));
+ usb_schedsoftintr(&sc->sc_bus);
+
+ splx(s);
+}
+
//
Static usbd_status
Index: sys/dev/usb/ehci_pci.c
===
RCS file: /dump/FreeBSD-CVS/src/sys/dev/usb/ehci_pci.c,v
retrieving revision 1.14.2.2
diff -u -r1.14.2.2 ehci_pci.c
--- sys/dev/usb/ehci_pci.c 13 Jun 2005 09:00:19 - 1.14.2.2
+++ sys/dev/usb/ehci_pci.c 26 Jun 2005 16:21:11 -
@@ -303,6 +303,10 @@
return ENXIO;
}
+ /* Enable workaround for dropped interrupts as required */
+ if (pci_get_vendor(self) == PCI_EHCI_VENDORID_VIA)
+ sc->sc_flags |= EHCI_SCFLG_LOSTINTRBUG;
+
/*
* Find companion controllers. According to the spec they always
* have lower function numbers so they should be enumerated already.
Index: sys/dev/usb/ehcivar.h
===
RCS file: /dump/FreeBSD-CVS/src/sys/dev/usb/ehcivar.h,v
retrieving revision 1.4.2.4
diff -u -r1.4.2.4 ehcivar.h
--- sys/dev/usb/ehcivar.h 22 Mar 2005 00:56:54 - 1.4.2.4
+++ sys/dev/usb/ehcivar.h 26 Jun 2005 16:2
Re: Low umass performance with USB 2.0 ports
"Eygene A. Ryabinkin" wrote: > > Good day. > I am observing very low umass performance: when I am trying to move a large > file from/to my USB 2.0 flash that is plugged into the USB 2.0 port: transfer > starts fine at 3.5 Mb/sec, but after some 20 Mbytes it hangs and the process > (dd) stay in the wdrain state. The activity LED on the flash shows no > activity. > Operations do continue, but very slow and the most time of the copying process > spends in the wdrain state. All attempts to invoke `sync` or to see the > file state via `ls` are hanging until `dd` leaves the wdrain state. > It does not matter what flash is used: I tried Apacer and the Kingmax ones -- > the result is the same. > If I plug the flash into the USB 1.1 port and trying to move some data -- it > works fine, no hangs. Speed is 500 Kb/sec. What is filesystem has your USB drive? FreeBSD 4.x had very low performance with FAT filesystem, writing process spent lots of time in the wdrain state too. Eugene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Low umass performance with USB 2.0 ports
> > What is filesystem has your USB drive? The one I was extensively testing has FAT, but I've checked the UFS2 -- just a bit better -- 1.8 Mb/second. But you're right -- no wdrains at all. > FreeBSD 4.x had very low performance with FAT filesystem, > writing process spent lots of time in the wdrain state too. Yes, it has. But here the same flash drive gives different results for ehci and uhci devices, and the total speed of echi is lower due to wdrains: 300 Kb/sec versus 500 Kb/sec. And I sometimes write my data to the Windows partition with FAT to my home HDD -- it has no wdrains. At least, I've not noticed them. For flash I can. -- rea ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Low umass performance with USB 2.0 ports
Good day. I am observing very low umass performance: when I am trying to move a large file from/to my USB 2.0 flash that is plugged into the USB 2.0 port: transfer starts fine at 3.5 Mb/sec, but after some 20 Mbytes it hangs and the process (dd) stay in the wdrain state. The activity LED on the flash shows no activity. Operations do continue, but very slow and the most time of the copying process spends in the wdrain state. All attempts to invoke `sync` or to see the file state via `ls` are hanging until `dd` leaves the wdrain state. It does not matter what flash is used: I tried Apacer and the Kingmax ones -- the result is the same. If I plug the flash into the USB 1.1 port and trying to move some data -- it works fine, no hangs. Speed is 500 Kb/sec. Seems like others do have this problem: http://lists.freebsd.org/pipermail/freebsd-usb/2005-May/001052.html USB 2.0 controller is Promise PCI (NEC chipset), USB 1.1 chipset is onboard VIA. My dmesg output is: - Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.4-STABLE #2: Tue Aug 30 11:34:26 MSD 2005 :/usr/src/sys/i386/compile/GENERIC ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel Pentium III (1004.52-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x686 Stepping = 6 Features=0x383fbff real memory = 2147467264 (2047 MB) avail memory = 2096017408 (1998 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 3 cpu1 (AP): APIC ID: 0 ioapic0 irqs 0-23 on motherboard acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xfe00-0xfe7f at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 drm0: port 0xd800-0xd8ff mem 0xdf00-0xdf00,0xf000-0xf7ff irq 16 at device 0.0 on pci1 info: [drm] AGP at 0xfe00 8MB info: [drm] Initialized radeon 1.11.0 20020828 on minor 0 pci1: at device 0.1 (no driver attached) isab0: at device 4.0 on pci0 isa0: on isab0 atapci0: port 0xb800-0xb80f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 4.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 uhci0: port 0xb400-0xb41f irq 5 at device 4.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xb000-0xb01f irq 5 at device 4.3 on pci0 usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pcm0: port 0xa800-0xa83f irq 19 at device 9.0 on pci0 pcm0: pci0: at device 9.2 (no driver attached) pci0: at device 10.0 (no driver attached) pci0: at device 10.1 (no driver attached) ehci0: mem 0xdc00-0xdcff irq 16 at device 10.2 on pci0 usb2: EHCI version 1.0 usb2: wrong number of companions (2 != 0) usb2: on ehci0 usb2: USB revision 2.0 uhub2: NEC EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub2: 5 ports with 5 removable, self powered umass0: vendor 0x1005 USB FLASH DRIVE, rev 2.00/0.84, addr 2 em0: port 0xa000-0xa03f mem 0xdb00-0xdb01,0xdb80-0xdb81 irq 17 at device 11.0 on pci0 em0: Ethernet address: 00:07:e9:09:5a:82 em0: Speed:N/A Duplex:N/A atapci1: port 0x9000-0x907f,0x9400-0x940f,0x9800-0x983f mem 0xda00-0xda01,0xda80-0xda800fff irq 19 at device 13.0 on pci0 atapci1: failed: rid 0x20 is memory, requested 4 ata2: channel #0 on atapci1 ata3: channel #1 on atapci1 ata4: channel #2 on atapci1 fdc0: port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 npx0: on motherboard npx0: INT 16 interface orm0: at iomem 0xcc000-0xcd7ff,0xc-0xcafff on isa0 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 fb0 at vga0 ulpt0: Xerox Corporation Xerox Phaser 3130, rev 2.00/1.00, addr 2, iclass 7/1 ulpt0: using bi-directional mode Timecounters tick every 1.000 msec ipfw2 initialized, divert disabled, rule-based forwarding disabled, default to deny, logging limited to 1000 packets/entry by default ad0: 76319MB [155061/16/63] at ata0-master UDMA100 acd0: DVDR at ata0-slave PIO4 ad2: 114498MB [232632/16/63] at ata1-master UDMA100 ad4: 114498MB [232632/16/63] at ata2-m
