From owner-freebsd-current Thu Dec 19 17:11:37 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E73FE37B401 for ; Thu, 19 Dec 2002 17:11:32 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 682EB43EE5 for ; Thu, 19 Dec 2002 17:11:32 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.5/8.12.5) with ESMTP id gBK1BWOM026511; Thu, 19 Dec 2002 17:11:32 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.5/8.12.5/Submit) id gBK1BW0h026510; Thu, 19 Dec 2002 17:11:32 -0800 (PST) (envelope-from dillon) Date: Thu, 19 Dec 2002 17:11:32 -0800 (PST) From: Matthew Dillon Message-Id: <200212200111.gBK1BW0h026510@apollo.backplane.com> To: Nate Lawson Cc: freebsd-current@FreeBSD.ORG Subject: Re: UMASS USB bug? (getting the Sony disk-on-key device working) References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :> :> -Current has a quirk table for umass.c and already has a flag which :> disables the residue test. The patch for current thus does not require :> #if 0'ing out that code, only a quirk entry. Since I don't need any :> hacks beyond what is there already I am going to commit the two quirk :> entries for -current now. : :Please respect the maintainer of da(4). There's info about quirk :documentation at: : http://www.root.org/~nate/freebsd/quirks.html : :I still have a broken finger and a job so slow responses do not mean I am :ignoring you. Well, what do you think about the Quirk entry? I tested both stable and current with and without the quirk entry, and with various combinations of options. It doesn't work without thet quirk entry. :> test2 kernel: umass0: Sony USB Storage Media, rev 1.10/2.00, addr 2 :> test2 kernel: umass0: Get Max Lun not supported (IOERROR) :> test2 kernel: da2 at umass-sim0 bus 0 target 0 lun 0 :> test2 kernel: da2: Removable Direct Access SCSI-0 device :> test2 kernel: da2: 1.000MB/s transfers :> test2 kernel: da2: Attempt to query device size failed: UNIT ATTENTION, Medium not present : :Bus scan is probably happening before the device is fully powered up. :One problem I noticed was that umass_cam_rescan() doesn't fill out the ccb :properly, leaving timeout as 0 for instance. This probably won't hurt but :I'm not sure. Another bug available from cursory overview is: I'll take a look at the attach code. It would be cool if there were something easy we could do there, but I am not optimistic considering the fact that the device responds to the control channel queries just fine long, long before it tells us that the media is ready. :> test2 kernel: (da2:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 :> test2 kernel: (da2:umass-sim0:0:0:0): CAM Status: SCSI Status Error :> test2 kernel: (da2:umass-sim0:0:0:0): SCSI Status: Check Condition :> test2 kernel: (da2:umass-sim0:0:0:0): UNIT ATTENTION asc:3a,0 :> test2 kernel: (da2:umass-sim0:0:0:0): Medium not present :> test2 kernel: (da2:umass-sim0:0:0:0): Retrying Command (per Sense Data) : :CAM retries the CCB as requested by scsi_da.c in daopen(). Yes, I know. That wasn't really my question. This is USB we are talking about here after all. :> test2 kernel: (da2:umass-sim0:0:0:0): Not ready to ready change, medium may have changed :> test2 kernel: (da2:umass-sim0:0:0:0): Retrying Command (per Sense Data) :> (no retry occurs) :> :> And if I tell cam to rescan a different Lun it works: : :Because the device has had time to power up. That is my assumption too, but then again the device responds just fine to the control channel commands (getting the device name and all of that rot). I'm hoping it is as simple as a timeout parameter somewhere but where to look... :> I am not sure what is going on but I think in -current CAM is :> exhausting its retries too quickly (the messages are instantanious) :> and not giving the device enough time to boot up. This is because, :> I believe, the usb controller is now a kerneland thread instead of :> a userland usbd and is responding instantly to the device presence. : :No, umass is attaching before the device is ready. Note the difference in :delay between camcontrol rescan on a SPI bus vs. USB. The SPI controller :is taking the appropriate time per device for it to respond to select. :umass_cam_attach attempts to delay the bus scan to have the same effect :but may not be working properly here. I have no idea what the USB spec :says here. Hmm. Any idea where I should look? :> I would have expected 'camcontrol rescan 2:0:0' but it doesn't. :> It just says: :> :> # camcontrol rescan 2:0:0 :> Re-scan of 2:0:0 was successful :> :> But then doesn't do anything. : :umass is not calling the attach code again for some reason. : :-Nate Is it supposed to? I'm looking for guidance. -- I found another couple of bugs, this time in OHCI's DMA buffer chaining code. A patch for this with additional debugging code is included below (for current). There are two bugs. I do not know if -stable is effected. First, the calculation of dataphysend is totally bogus. You can just take the physical address and add (len - 1) to it. You have to take the virtual address, add len - 1 to it, and convert it to a physical address. I can crash my machine simply by doing a 'newfs -f 1024 -b 8192 /dev/da2s1a' On the disk-on-key USB device. Second, I believe the OpenBSD and NetBSD code is broken. The range can be one or two pages, but the remaining bytes may be less then one page and this has to be taken into account. -Matt Matthew Dillon 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 -0000 1.116 +++ ohci.c 20 Dec 2002 01:02:11 -0000 @@ -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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message