On Sat, Nov 01 2003, Alan Stern wrote: > On Fri, 31 Oct 2003, Nicolas Mailhot wrote: > > > Le ven 31/10/2003 � 19:33, [EMAIL PROTECTED] a �crit : > > > ------- Additional Comments From [EMAIL PROTECTED] 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 ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
