Messages in this thread | | | Date | Tue, 4 Nov 2003 08:49:32 +0100 | From | Jens Axboe <> | Subject | Re: [Bug 1412] Copy from USB1 CF/SM reader stalls, no actual content is read (only directory structure) |
| |
On Sat, Nov 01 2003, Alan Stern wrote: > On Fri, 31 Oct 2003, Nicolas Mailhot wrote: > > > Le ven 31/10/2003 à 19:33, bugme-daemon@osdl.org a écrit : > > > ------- Additional Comments From stern@rowland.harvard.edu 2003-10-31 10:33 ------- > > > Created an attachment (id=1303) > > > --> (http://bugme.osdl.org/attachment.cgi?id=1303&action=view) > > > New diagnostic patch > > > > > > Try using this diagnostic patch instead of the one sent earlier by Matt Dharm > > > in attachment #14. It may reveal that the source of the problem is not in the > > > USB system but higher up. > > > > Done. Do you want to be CCed on this bug ? > > There's no need. The output from that diagnostic is definitive -- this > isn't a USB problem. It's got to be a problem higher up, maybe in the > SCSI layer but more likely in the block layer or the file system code. > > Oct 31 21:12:09 rousalka kernel: usb-storage: READ_10: read page 160 pagect 8 > Oct 31 21:12:09 rousalka kernel: usb-storage: sddr09_read_data: use_sg = 1, sg[0].page = c18c5b40, .offset = 0, sg_address = 00000000 > Oct 31 21:12:09 rousalka kernel: usb-storage: Read 8 pages, from PBA 11 (LBA 5) page 0 > Oct 31 21:12:09 rousalka kernel: usb-storage: usb_stor_ctrl_transfer: rq=00 rqtype=41 value=0000 index=00 len=12 > Oct 31 21:12:09 rousalka kernel: usb-storage: Status code 0; transferred 12/12 > Oct 31 21:12:09 rousalka kernel: usb-storage: -- transfer complete > Oct 31 21:12:09 rousalka kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 4096 bytes > Oct 31 21:12:09 rousalka kernel: usb-storage: Status code 0; transferred 4096/4096 > Oct 31 21:12:09 rousalka kernel: usb-storage: -- transfer complete > Oct 31 21:12:09 rousalka kernel: usb-storage: us_copy_to_sgbuf: buffer = f38e6000, len = 4096, content = f7e01e40, *index = 0, *offset = 0, use_sg = 1 > Oct 31 21:12:09 rousalka kernel: usb-storage: in loop, ptr = 00000000 > > The line where it says sg_address = 00000000 indicates that something has > asked us to read data from the device and store it at a virtual address > that isn't mapped to memory! You can see the same thing in the last line, > where ptr = 00000000. No wonder you get an oops.
I don't think your analysis is correct. The sg entry has a page element assigned, it just looks like someone didn't dma map the sg entry yet. I had a quick peek in sddr09, lots of ugliness in there... The sg_address() crap needs to go. And kfree() on ptr + offset, irk. And I hope you are not dma'ing into these pages. Missing checks for kmalloc() failure. Etc.
Someone needs to read up on DMA-mapping.txt and fix it. Clean these bits up and I bet it works.
-- Jens Axboe
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |