Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
Bernd Walter [EMAIL PROTECTED] wrote: On Fri, Nov 21, 2003 at 12:35:50PM -0500, Brian F. Feldman wrote: Doug White [EMAIL PROTECTED] wrote: The OHCI driver is largely synced with NetBSD so you might see if they have the same bug. I'll look around for a bootable NetBSD CD. NetBSD is different in that point. This might be the underlying wierdness we were seeing in gtetlow's microdrive with transfers over 8k. The one-page-crossing ohci limitation is really annoying. Is there a way to add a quirk for max 8k transfers or anything? Even though that would be patently lame, I'd like to get some sort of workaround here. I don't even know what is supposed to be the problem here -- the fact that it's an ohci controller, an ohci+ehci controller, or that it's some specific controller issue... We never did any page crossing on ohci/ehci bevor the newbus change took place. Found it!!! Definitely a problem created then... --- ohci.c 12 Nov 2003 01:40:11 - 1.138 +++ ohci.c 22 Nov 2003 03:28:42 - @@ -569,7 +569,7 @@ cur-td.td_cbp = htole32(dataphys); cur-nexttd = next; cur-td.td_nexttd = htole32(next-physaddr); - cur-td.td_be = htole32(DMAADDR(dma, curlen - 1)); + cur-td.td_be = htole32(DMAADDR(dma, offset + curlen - 1)); cur-len = curlen; cur-flags = OHCI_ADD_LEN; cur-xfer = xfer; I'm a lot happier now :-) Let's start trying to get this stuff merged in! -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
On Sat, Nov 22, 2003 at 08:08:29AM -0500, Brian F. Feldman wrote: Found it!!! Definitely a problem created then... --- ohci.c 12 Nov 2003 01:40:11 - 1.138 +++ ohci.c 22 Nov 2003 03:28:42 - @@ -569,7 +569,7 @@ cur-td.td_cbp = htole32(dataphys); cur-nexttd = next; cur-td.td_nexttd = htole32(next-physaddr); - cur-td.td_be = htole32(DMAADDR(dma, curlen - 1)); + cur-td.td_be = htole32(DMAADDR(dma, offset + curlen - 1)); cur-len = curlen; cur-flags = OHCI_ADD_LEN; cur-xfer = xfer; I'm a lot happier now :-) Let's start trying to get this stuff merged in! Great news! -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
On Sat, Nov 22, 2003 at 08:08:29AM -0500, Brian F. Feldman wrote: We never did any page crossing on ohci/ehci bevor the newbus change took place. Found it!!! Definitely a problem created then... --- ohci.c 12 Nov 2003 01:40:11 - 1.138 +++ ohci.c 22 Nov 2003 03:28:42 - @@ -569,7 +569,7 @@ cur-td.td_cbp = htole32(dataphys); cur-nexttd = next; cur-td.td_nexttd = htole32(next-physaddr); - cur-td.td_be = htole32(DMAADDR(dma, curlen - 1)); + cur-td.td_be = htole32(DMAADDR(dma, offset + curlen - 1)); cur-len = curlen; cur-flags = OHCI_ADD_LEN; cur-xfer = xfer; I'm a lot happier now :-) Let's start trying to get this stuff merged in! Cool as!!! Good call. Joe -- Josef Karthauser ([EMAIL PROTECTED]) http://www.josef-k.net/ FreeBSD (cvs meister, admin and hacker) http://www.uk.FreeBSD.org/ Physics Particle Theory (student) http://www.pact.cpes.sussex.ac.uk/ An eclectic mix of fact and theory. = pgp0.pgp Description: PGP signature
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
The OHCI driver is largely synced with NetBSD so you might see if they have the same bug. This might be the underlying wierdness we were seeing in gtetlow's microdrive with transfers over 8k. The one-page-crossing ohci limitation is really annoying. On Thu, 20 Nov 2003, Brian F. Feldman wrote: Thanks for the patches to try! They unfortunately didn't fix the crash I have, but I found out why it's occurring. See ohci.c:1389: if (std-td.td_cbp != 0) len -= le32toh(std-td.td_be) - le32toh(std-td.td_cbp) + 1; In one of my transfers (look in my log for the 2560 byte one) that statement actually adds 8192 to len, which is utterly bogus because you can see it only allocates 2560 -- hence when it tries to finish the transfer it memcpy()'s way too much memory and my kernel segfaults. If I #if 0 this out, I'm left only with umass0: BBB reset failed, STALLED messages... which is a lot better than before! I don't know under what situations that bit of code makes sense, but it definitely needs more reviewing! Stalls usually come from the device receiving bad data. Rather than return errors, usb generally just hangs the endpoint. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
Doug White [EMAIL PROTECTED] wrote: The OHCI driver is largely synced with NetBSD so you might see if they have the same bug. I'll look around for a bootable NetBSD CD. This might be the underlying wierdness we were seeing in gtetlow's microdrive with transfers over 8k. The one-page-crossing ohci limitation is really annoying. Is there a way to add a quirk for max 8k transfers or anything? Even though that would be patently lame, I'd like to get some sort of workaround here. I don't even know what is supposed to be the problem here -- the fact that it's an ohci controller, an ohci+ehci controller, or that it's some specific controller issue... On Thu, 20 Nov 2003, Brian F. Feldman wrote: Thanks for the patches to try! They unfortunately didn't fix the crash I have, but I found out why it's occurring. See ohci.c:1389: if (std-td.td_cbp != 0) len -= le32toh(std-td.td_be) - le32toh(std-td.td_cbp) + 1; In one of my transfers (look in my log for the 2560 byte one) that statement actually adds 8192 to len, which is utterly bogus because you can see it only allocates 2560 -- hence when it tries to finish the transfer it memcpy()'s way too much memory and my kernel segfaults. If I #if 0 this out, I'm left only with umass0: BBB reset failed, STALLED messages... which is a lot better than before! I don't know under what situations that bit of code makes sense, but it definitely needs more reviewing! Stalls usually come from the device receiving bad data. Rather than return errors, usb generally just hangs the endpoint. Hmm :-/ I wonder if anyone could interpret the debugging info enough to have an idea what it's disliking for certain. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
Whoops. http://damien.bergamini.free.fr/ueagle/download.html. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
On Fri, Nov 21, 2003 at 09:11:33AM -0800, Doug White wrote: The OHCI driver is largely synced with NetBSD so you might see if they have the same bug. This might be the underlying wierdness we were seeing in gtetlow's microdrive with transfers over 8k. The one-page-crossing ohci limitation is really annoying. There are a number of OHCI patches at:- http://damien.bergamini.free.fr/ueagle/ BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
On Fri, Nov 21, 2003 at 12:35:50PM -0500, Brian F. Feldman wrote: Doug White [EMAIL PROTECTED] wrote: The OHCI driver is largely synced with NetBSD so you might see if they have the same bug. I'll look around for a bootable NetBSD CD. NetBSD is different in that point. This might be the underlying wierdness we were seeing in gtetlow's microdrive with transfers over 8k. The one-page-crossing ohci limitation is really annoying. Is there a way to add a quirk for max 8k transfers or anything? Even though that would be patently lame, I'd like to get some sort of workaround here. I don't even know what is supposed to be the problem here -- the fact that it's an ohci controller, an ohci+ehci controller, or that it's some specific controller issue... We never did any page crossing on ohci/ehci bevor the newbus change took place. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
Bernd Walter [EMAIL PROTECTED] wrote: On Fri, Nov 21, 2003 at 12:35:50PM -0500, Brian F. Feldman wrote: Doug White [EMAIL PROTECTED] wrote: The OHCI driver is largely synced with NetBSD so you might see if they have the same bug. I'll look around for a bootable NetBSD CD. NetBSD is different in that point. This might be the underlying wierdness we were seeing in gtetlow's microdrive with transfers over 8k. The one-page-crossing ohci limitation is really annoying. Is there a way to add a quirk for max 8k transfers or anything? Even though that would be patently lame, I'd like to get some sort of workaround here. I don't even know what is supposed to be the problem here -- the fact that it's an ohci controller, an ohci+ehci controller, or that it's some specific controller issue... We never did any page crossing on ohci/ehci bevor the newbus change took place. Are you hinting that I need to find some way to defragment the DMA buffers I'm getting back? -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
Brian F. Feldman [EMAIL PROTECTED] writes: Jeez, it's been broken a year and it's almost 5.2-RELEASE now. Does anyone have ANY leads on these problems? I know precisely nothing about how my USB hardware is supposed to work, but this OHCI+EHCI stuff definitely doesn't, and it's really not uncommon at all. Is it unbroken in NetBSD currently? *shrug* I have never been able to get my USB printer to work with FreeBSD, and I gave up writing drivers for USB crypto tokens because the USB drivers were too broken (reading any amount of data from the ugen device returns garbage with no error message and no indication of the actual amount of data obtained from the device). Neither could I get anybody with USB clue interested in the problem long enough to actually try to fix it. In conclusion, I simply don't consider FreeBSD's USB support usable for anything more complex than mice and keyboards. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
In message [EMAIL PROTECTED], Brian F. Feldman
writes:
Jeez, it's been broken a year and it's almost 5.2-RELEASE now. Does anyone
have ANY leads on these problems? I know precisely nothing about how my USB
hardware is supposed to work, but this OHCI+EHCI stuff definitely doesn't,
and it's really not uncommon at all. Is it unbroken in NetBSD currently?
I had some success with this patch:
Index: usb_mem.c
===
RCS file: /dump/FreeBSD-CVS/src/sys/dev/usb/usb_mem.c,v
retrieving revision 1.5
diff -u -r1.5 usb_mem.c
--- usb_mem.c 4 Oct 2003 22:13:21 - 1.5
+++ usb_mem.c 27 Oct 2003 15:39:03 -
@@ -142,7 +142,8 @@
s = splusb();
/* First check the free list. */
for (p = LIST_FIRST(usb_blk_freelist); p; p = LIST_NEXT(p, next)) {
- if (p-tag == tag p-size = size p-align = align) {
+ if (p-tag == tag p-size = size p-size size * 2
+ p-align = align) {
LIST_REMOVE(p, next);
usb_blk_nfree--;
splx(s);
It seems that since the conversion to busdma, the USB code can end
up attempting to use contigmalloc() to allocate multi-page regions
from an interrupt thread(!). The above doesn't fix that; it just
prevents successful large (e.g 64k) contiguous allocations from
being wasted when a much smaller amount of space is needed.
With the above, I was able to use ohci+ehci fairly reliably on a
Soekris box with a large USB2 disk attached via a cardbus USB2
adaptor. I also have a few other local patches that may help too -
some of them are below:
Ian
Index: ohci.c
===
RCS file: /dump/FreeBSD-CVS/src/sys/dev/usb/ohci.c,v
retrieving revision 1.132
diff -u -r1.132 ohci.c
--- ohci.c 24 Aug 2003 17:55:54 - 1.132
+++ ohci.c 21 Sep 2003 15:28:27 -
@@ -1405,12 +1405,13 @@
if (std-flags OHCI_ADD_LEN)
xfer-actlen += len;
if (std-flags OHCI_CALL_DONE) {
+ ohci_free_std(sc, std); /* XXX */
xfer-status = USBD_NORMAL_COMPLETION;
s = splusb();
usb_transfer_complete(xfer);
splx(s);
- }
- ohci_free_std(sc, std);
+ } else
+ ohci_free_std(sc, std);
} else {
/*
* Endpoint is halted. First unlink all the TDs
@@ -2246,6 +2247,7 @@
usb_uncallout(xfer-timeout_handle, ohci_timeout, xfer);
usb_transfer_complete(xfer);
splx(s);
+ return;
}
if (xfer-device-bus-intr_context || !curproc)
Index: usbdi.c
===
RCS file: /dump/FreeBSD-CVS/src/sys/dev/usb/usbdi.c,v
retrieving revision 1.82
diff -u -r1.82 usbdi.c
--- usbdi.c 24 Aug 2003 17:55:55 - 1.82
+++ usbdi.c 21 Sep 2003 15:28:29 -
@@ -751,6 +751,7 @@
pipe, xfer, pipe-methods));
/* Make the HC abort it (and invoke the callback). */
pipe-methods-abort(xfer);
+ KASSERT(SIMPLEQ_FIRST(pipe-queue) != xfer, (usbd_ar_pipe));
/* XXX only for non-0 usbd_clear_endpoint_stall(pipe); */
}
pipe-aborting = 0;
@@ -763,8 +764,9 @@
{
usbd_pipe_handle pipe = xfer-pipe;
usb_dma_t *dmap = xfer-dmabuf;
+ usbd_status status;
int repeat = pipe-repeat;
- int polling;
+ int polling, xfer_flags;
SPLUSBCHECK;
@@ -835,30 +837,33 @@
xfer-status = USBD_SHORT_XFER;
}
- if (xfer-callback)
- xfer-callback(xfer, xfer-priv, xfer-status);
-
-#ifdef DIAGNOSTIC
- if (pipe-methods-done != NULL)
+ /* Copy any xfer fields in case the xfer goes away in the callback. */
+ status = xfer-status;
+ xfer_flags = xfer-flags;
+ /*
+* For repeat operations, call the callback first, as the xfer
+* will not go away and the done method may modify it. Otherwise
+* reverse the order in case the callback wants to free or reuse
+* the xfer.
+*/
+ if (repeat) {
+ if (xfer-callback)
+ xfer-callback(xfer, xfer-priv, status);
pipe-methods-done(xfer);
- else
- printf(usb_transfer_complete: pipe-methods-done == NULL\n);
-#else
- pipe-methods-done(xfer);
-#endif
-
- if ((xfer-flags USBD_SYNCHRONOUS) !polling)
- wakeup(xfer);
+ } else {
+ pipe-methods-done(xfer);
+ if (xfer-callback)
+
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
Jeez, it's been broken a year and it's almost 5.2-RELEASE now. See for example the page for the FreeBSD eagle driver: http://damien.bergamini.free.fr/ueagle/ end notably the OHCI patches in http://damien.bergamini.free.fr/ueagle/download.html At least for the eagle USB ADSL modem, these patches solve the ohci problems. -- Michel TALON ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
Alexander Leidinger [EMAIL PROTECTED] writes: I have no problem using my printer: [...] ulpt0: Hewlett-Packard DeskJet 895C, rev 1.00/1.00, addr 4, iclass 7/1 ulpt0: using uni-directional mode Sure, I can do that: ulpt0: Hewlett-Packard officejet d series, rev 1.10/1.00, addr 3, iclass 7/1 ulpt0: using bi-directional mode but it still won't print. Sometimes it works (albeit very, very slowly) but most of the time the process writing to ulpt0 just hangs. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 20 Nov 2003 10:20, Dag-Erling Smørgrav wrote: Sure, I can do that: ulpt0: Hewlett-Packard officejet d series, rev 1.10/1.00, addr 3, iclass 7/1 ulpt0: using bi-directional mode but it still won't print. Sometimes it works (albeit very, very slowly) but most of the time the process writing to ulpt0 just hangs. When it works, is that when you have been using it in another operating system, and then reboot into FreeBSD and try it? IIRC, some of these multi-function devices require a code sending to them by the printer driver to tell them to behave like printers (instead of being a fax machine or a scanner or whatever). Unfortunately, finding out what that code is and sending it can be tricky. Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/vKlcLqgJ90OcaiARAhB9AKCnTINKAW5tZ7t9EVZQlEr7GujSvgCfbx+u e2bNUtyWQgFIKXcMDGFCjZI= =gx+R -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
Mark Dixon [EMAIL PROTECTED] writes: When it works, is that when you have been using it in another operating system, and then reboot into FreeBSD and try it? I don't think so. BTW, I just reinstalled cups to give the printer another try, and it now seems to work in -CURRENT (knock on wood). It didn't work in -STABLE when I tried a couple of weeks ago, nor did it work in -CURRENT when I tried to use it to print wedding invitations this summer. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
On Thu, Nov 20, 2003 at 11:20:18AM +0100, Dag-Erling Smørgrav wrote: Alexander Leidinger [EMAIL PROTECTED] writes: I have no problem using my printer: [...] ulpt0: Hewlett-Packard DeskJet 895C, rev 1.00/1.00, addr 4, iclass 7/1 ulpt0: using uni-directional mode Sure, I can do that: ulpt0: Hewlett-Packard officejet d series, rev 1.10/1.00, addr 3, iclass 7/1 ulpt0: using bi-directional mode but it still won't print. Sometimes it works (albeit very, very slowly) but most of the time the process writing to ulpt0 just hangs. My OfficeJet 6110 works great with FreeBSD 5 as of a month ago. I don't print very often. It is prints quickly. My only problem with installation was because apsfilter' setup script didn't know about the 6110 driver parameter for the hpijs driver. Apsfilter seemed to have missed a couple of newer revs of the hpijs drivers. Unfortunately, the box isn't reachable from here or I'd post configs. -- Scott LambertKC5MLE Unix SysAdmin [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
Thanks for the patches to try! They unfortunately didn't fix the crash I have, but I found out why it's occurring. See ohci.c:1389: if (std-td.td_cbp != 0) len -= le32toh(std-td.td_be) - le32toh(std-td.td_cbp) + 1; In one of my transfers (look in my log for the 2560 byte one) that statement actually adds 8192 to len, which is utterly bogus because you can see it only allocates 2560 -- hence when it tries to finish the transfer it memcpy()'s way too much memory and my kernel segfaults. If I #if 0 this out, I'm left only with umass0: BBB reset failed, STALLED messages... which is a lot better than before! I don't know under what situations that bit of code makes sense, but it definitely needs more reviewing! Please check out my debugging messages and tell me if you see any hints as to why the transfers are getting stalled. I should have looked at the debugging messages long ago, I guess. Thanks! http://green.homeunix.org/~green/ohci-debugging.txt.gz -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
Brian F. Feldman [EMAIL PROTECTED] wrote: Thanks for the patches to try! They unfortunately didn't fix the crash I have, but I found out why it's occurring. See ohci.c:1389: if (std-td.td_cbp != 0) len -= le32toh(std-td.td_be) - le32toh(std-td.td_cbp) + 1; In one of my transfers (look in my log for the 2560 byte one) that statement actually adds 8192 to len, which is utterly bogus because you can see it only allocates 2560 -- hence when it tries to finish the transfer it memcpy()'s way too much memory and my kernel segfaults. If I #if 0 this out, I'm left only with umass0: BBB reset failed, STALLED messages... which is a lot better than before! I don't know under what situations that bit of code makes sense, but it definitely needs more reviewing! Please check out my debugging messages and tell me if you see any hints as to why the transfers are getting stalled. I should have looked at the debugging messages long ago, I guess. Thanks! http://green.homeunix.org/~green/ohci-debugging.txt.gz BTW, replying to myself -- it seems to be something missing from the multi-allocation transfers (8KB), because I can do up to 8KB transfers perfectly fine now, but 10KB ones, for example, like mdir(8) does are the ones that give me BBB stalls. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
Josef Karthauser [EMAIL PROTECTED] wrote: On Sun, Nov 17, 2002 at 01:18:00PM -0500, Brian F. Feldman wrote: ohci_alloc_std_chain+0xf5 (calling a DMAADDR() function, I believe) ohci_device_bulk_start+0x0d ohci_device_bulk_transfer+0x27 usbd_transfer+0xc0 umass_setup_transfer+0x4f umass_bbb_state usb_transfer_complete ohci_softintr Can anyone confirm if this is normal or I have an exceptional system? I have two completely unrelated OHCI-based controllers in my system and neither works. Anyone? I kinda want to use my CF reader. There are rumours that OHCI is borked in NetBSD too and this is a bug that we've inherited. Me, I've not got an OHCI system to test just UHCI. Did it used to work, and got broken, or has it never worked? Jeez, it's been broken a year and it's almost 5.2-RELEASE now. Does anyone have ANY leads on these problems? I know precisely nothing about how my USB hardware is supposed to work, but this OHCI+EHCI stuff definitely doesn't, and it's really not uncommon at all. Is it unbroken in NetBSD currently? -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
I fixed a serious DMA physical address translation bug in OHCI today.
Look on the lists today for this message. Message and patch enclosed.
Note that this fixes one bug in FreeBSD's implementation and a second
bug that is NetBSD/OpenBSD specific. I would appreciate it if someone
would forward this information to the NetBSD/OpenBSD folks.
These were very serious bugs.
-Matt
:Date: Thu, 19 Dec 2002 17:11:32 -0800 (PST)
:From: Matthew Dillon [EMAIL PROTECTED]
:Message-Id: [EMAIL PROTECTED]
:To: Nate Lawson [EMAIL PROTECTED]
:Cc: [EMAIL PROTECTED]
:Subject: Re: UMASS USB bug? (getting the Sony disk-on-key device working)
:References: [EMAIL PROTECTED]
:Sender: [EMAIL PROTECTED]
:List-ID: freebsd-current.FreeBSD.ORG
:List-Archive: http://docs.freebsd.org/mail/ (Web Archive)
:List-Help: mailto:[EMAIL PROTECTED]?subject=help (List Instructions)
:List-Subscribe: mailto:[EMAIL PROTECTED]?subject=subscribe%20freebsd-current
:List-Unsubscribe: mailto:[EMAIL PROTECTED]?subject=unsubscribe%20freebsd-current
:X-Loop: FreeBSD.ORG
:Precedence: bulk
:...
:
Index: ohci.c
===
RCS file: /home/ncvs/src/sys/dev/usb/ohci.c,v
retrieving revision 1.116
diff -u -r1.116 ohci.c
--- ohci.c 9 Dec 2002 01:41:24 - 1.116
+++ ohci.c 20 Dec 2002 01:02:11 -
@@ -493,17 +493,17 @@
u_int32_t intr, tdflags;
int offset = 0;
int len, curlen;
+ int orig_len;
usb_dma_t *dma = xfer-dmabuf;
u_int16_t flags = xfer-flags;
DPRINTFN(alen 4096,(ohci_alloc_std_chain: start len=%d\n, alen));
- len = alen;
+ orig_len = len = alen;
cur = sp;
-
dataphys = DMAADDR(dma, 0);
- dataphysend = OHCI_PAGE(dataphys + len - 1);
+ dataphysend = OHCI_PAGE(DMAADDR(dma, len - 1));
tdflags = htole32(
(rd ? OHCI_TD_IN : OHCI_TD_OUT) |
(flags USBD_SHORT_XFER_OK ? OHCI_TD_R : 0) |
@@ -518,8 +518,8 @@
/* The OHCI hardware can handle at most one page crossing. */
#if defined(__NetBSD__) || defined(__OpenBSD__)
- if (OHCI_PAGE(dataphys) == OHCI_PAGE(dataphysend) ||
- OHCI_PAGE(dataphys) + OHCI_PAGE_SIZE == OHCI_PAGE(dataphysend))
+ if (OHCI_PAGE(dataphys) == dataphysend ||
+ OHCI_PAGE(dataphys) + OHCI_PAGE_SIZE == dataphysend)
#elif defined(__FreeBSD__)
/* XXX This is pretty broken: Because we do not allocate
* a contiguous buffer (contiguous in physical pages) we
@@ -527,7 +527,7 @@
* So check whether the start and end of the buffer are on
* the same page.
*/
- if (OHCI_PAGE(dataphys) == OHCI_PAGE(dataphysend))
+ if (OHCI_PAGE(dataphys) == dataphysend)
#endif
{
/* we can handle it in this TD */
@@ -544,6 +544,8 @@
/* must use multiple TDs, fill as much as possible. */
curlen = 2 * OHCI_PAGE_SIZE -
OHCI_PAGE_MASK(dataphys);
+ if (curlen len) /* may have fit in one page */
+ curlen = len;
#elif defined(__FreeBSD__)
/* See comment above (XXX) */
curlen = OHCI_PAGE_SIZE -
@@ -568,6 +570,9 @@
dataphys, dataphys + curlen - 1));
if (len == 0)
break;
+ if (len 0)
+ panic(Length went negative: %d curlen %d (dma %p offset %08x
+dataphysend %p currentdataphysend %p, len, curlen, *dma, (int)offset, (void
+*)dataphysend, (void *)OHCI_PAGE(DMAADDR(dma,0) + orig_len - 1));
+
DPRINTFN(10,(ohci_alloc_std_chain: extend chain\n));
offset += curlen;
cur = next;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
Brian Fundakowski Feldman [EMAIL PROTECTED] wrote: I can't get more info because crash dumps don't work when this happens, but for what it's worth, here's a traceback which shows what happens when I attempt to use my da0: SanDisk ImageMate II 1.30 Removable Direct Access SCSI-2 device on an OHCI-based controller. This was working just a few days ago with a UHCI controller, so ... The crash is from an invalid read at 0xbff3e000, which is PTmap plus some offset. The trace as far as I can get it, from a kernel with USB but no options enabled, would be: ohci_alloc_std_chain+0xf5 (calling a DMAADDR() function, I believe) ohci_device_bulk_start+0x0d ohci_device_bulk_transfer+0x27 usbd_transfer+0xc0 umass_setup_transfer+0x4f umass_bbb_state usb_transfer_complete ohci_softintr Can anyone confirm if this is normal or I have an exceptional system? I have two completely unrelated OHCI-based controllers in my system and neither works. Anyone? I kinda want to use my CF reader. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
On Sun, Nov 17, 2002 at 01:18:00PM -0500, Brian F. Feldman wrote: ohci_alloc_std_chain+0xf5 (calling a DMAADDR() function, I believe) ohci_device_bulk_start+0x0d ohci_device_bulk_transfer+0x27 usbd_transfer+0xc0 umass_setup_transfer+0x4f umass_bbb_state usb_transfer_complete ohci_softintr Can anyone confirm if this is normal or I have an exceptional system? I have two completely unrelated OHCI-based controllers in my system and neither works. Anyone? I kinda want to use my CF reader. There are rumours that OHCI is borked in NetBSD too and this is a bug that we've inherited. Me, I've not got an OHCI system to test just UHCI. Did it used to work, and got broken, or has it never worked? Joe -- Josef Karthauser ([EMAIL PROTECTED]) http://www.josef-k.net/ FreeBSD (cvs meister, admin and hacker) http://www.uk.FreeBSD.org/ Physics Particle Theory (student) http://www.pact.cpes.sussex.ac.uk/ An eclectic mix of fact and theory. = msg46816/pgp0.pgp Description: PGP signature
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
Does this happen on a current with this patch applied too? Index: usb_port.h === RCS file: /home/ncvs/src/sys/dev/usb/usb_port.h,v retrieving revision 1.58 diff -u -r1.58 usb_port.h --- usb_port.h 2 Oct 2002 07:44:20 - 1.58 +++ usb_port.h 18 Oct 2002 15:14:23 - @@ -339,10 +339,7 @@ #define USBVERBOSE -/* We don't use the soft interrupt code in FreeBSD. */ -#if 0 #define USB_USE_SOFTINTR -#endif #define Static static Joe On Sun, Oct 06, 2002 at 07:42:18PM -0400, Brian Fundakowski Feldman wrote: I can't get more info because crash dumps don't work when this happens, but for what it's worth, here's a traceback which shows what happens when I attempt to use my da0: SanDisk ImageMate II 1.30 Removable Direct Access SCSI-2 device on an OHCI-based controller. This was working just a few days ago with a UHCI controller, so ... The crash is from an invalid read at 0xbff3e000, which is PTmap plus some offset. The trace as far as I can get it, from a kernel with USB but no options enabled, would be: ohci_alloc_std_chain+0xf5 (calling a DMAADDR() function, I believe) ohci_device_bulk_start+0x0d ohci_device_bulk_transfer+0x27 usbd_transfer+0xc0 umass_setup_transfer+0x4f umass_bbb_state usb_transfer_complete ohci_softintr Can anyone confirm if this is normal or I have an exceptional system? I have two completely unrelated OHCI-based controllers in my system and neither works. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality. - Albert Einstein, 1921 msg44888/pgp0.pgp Description: PGP signature
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
Josef Karthauser [EMAIL PROTECTED] wrote: Does this happen on a current with this patch applied too? I'm certain I tried this already :( -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
