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]"
