On Sat, 10 Mar 2007, Michael Cook wrote: > Hi, > > I'm trying to understand how the USB Mass Storage Device > works in 2.6. Specifically 2.6.14. I see a fair amount of > churn in this subsystem.
You didn't really ask any specific questions in your email -- you just said you were curious about some things -- and that makes it kind of hard to answer. And exactly what do you mean by "churn"? To me, that word means the subsystem changes a lot from one kernel release to another, which is not true any more (although it was truer at the time 2.6.14 was released). Anyway, 2.6.14 is fairly old. You should try to use a more recent kernel version, if possible. > My principle concern/question is how does data from a file > on the filesystem get transported to a memory stick? I > have dumped info at many stages and see varying URB buffers > sent out. That's how the file data gets transported. :-) > My device is using PIO not DMA. Irrelevant; who cares how the mass-storage device works? Maybe you mean the host controller uses PIO instead of DMA. > ----------------------------- > > As I try to trace through the use of this, I see that the > following flags are changing depending on various SCSI > activity to the memory stick: > > ----------------------------- > > # pehci urb_enqueue: URB:0xef708338 TxFlags:0xc > TxBuff:0xee110000 of 31 bytes [0x55 0x53 0x42 > 0x43...] > pehci urb_enqueue: URB:0xef7084e8 TxFlags:0x5 > TxBuff:0xc240a098 of 36 bytes [0x00 0x00 0x00 > 0x00...] > ..... > > ----------------------------- > > When I actually transfer file contents, I see the buffer > sizes increase dramaitcally: That's what you should expect, since the buffers now have to contain the file contents. > ----------------------------- > > pehci urb_enqueue: URB:0xef7080b0 TxFlags:0x5 > TxBuff:0xc2a40000 of 20480 bytes [0x33 0xcd 0xa9 > 0x71...] > pehci urb_enqueue: URB:0xef708338 TxFlags:0xc > TxBuff:0xee110000 of 13 bytes [0x55 0x53 0x42 > 0x43...] > I'm curious how the TxFlags keep changing... these are > combinations of: > > ----------------------------- > > #define URB_SHORT_NOT_OK 0x0001 /* report short reads as > errors */ > #define URB_ISO_ASAP 0x0002 /* iso-only, urb->start_frame > ignored */ > #define URB_NO_TRANSFER_DMA_MAP 0x0004 /* urb->transfer_dma > valid on submit */ > #define URB_NO_SETUP_DMA_MAP 0x0008 /* urb->setup_dma valid > on submit */ > #define URB_NO_FSBR 0x0020 /* UHCI-specific */ > #define URB_ZERO_PACKET 0x0040 /* Finish bulk OUTs with > short packet */ > #define URB_NO_INTERRUPT 0x0080 /* HINT: no non-error > interrupt needed */ Those aren't TxFlags; they are urb->transfer_flags values. Did you really mean "why the driver sets TxFlags to these changing values"? To understand that, you have to understand what the flags mean and how the driver works. > ----------------------------- > > I only see the flags non-zero once the SCSI system start > discoverying the memorystick. Previous URB enqueues are > all zero for the most part. > > My present situation is that after transfering files I see > file contents that are corrupt, along with system > instability. > > I'm trying to isolate if I'm indeed copying correclty to > and from memory. "if I'm indeed copying correclty to and from memory" Surely _your're_ not doing any copying at all; the drivers are doing it. Do you want to know if the drivers are copying correctly? About the only way to find out is to read the data back from your mass-storage device and see if it is the same as what you wrote. > I see DMA-based HCDs use pools of data. For non DMA based > HCDs I see accomodations have been made in teh hcd.c > allocation system. But wonder if the SCSI USB Mass Storage > device works with this in mind? The device doesn't care where the memory comes from -- or even if there's any memory at all. All it cares about is the data it receives over the USB bus. > I would also like to figure out if/why the flags for DMA > transfers are fluctuating so much... and specifically the > logic behind this snippet: > > ----------------------------- > /* we assume that if transfer_buffer isn't us->iobuf then > it > * hasn't been mapped for DMA. Yes, this is clunky, but > it's > * easier than always having the caller tell us whether > the > * transfer buffer has already been mapped. */ > us->current_urb->transfer_flags = URB_NO_SETUP_DMA_MAP; > if (us->current_urb->transfer_buffer == us->iobuf) > us->current_urb->transfer_flags |= > URB_NO_TRANSFER_DMA_MAP; > us->current_urb->transfer_dma = us->iobuf_dma; > us->current_urb->setup_dma = us->cr_dma; Do you know what the comment means? Do you know what the flag means? If you do, then what part of the logic is unclear? Earlier you implied that your host controller doesn't use DMA. In that case, why do you care about the DMA flag settings? They shouldn't have any effect on your system's operation. > ----------------------------- > > I'm missing something here... I'm just trying to figure out > where I SHOULD be reading & writing from in memory as I'm > presently not and its blowing up whenever the SCSI system > notices my memory stick. I still don't know why you think _you_ should be reading & writing anything in memory. As the computer user, all you do is run programs. As for where the host controller driver should read & write memory, the answer is simple. Since it doesn't use DMA, it should access the memory pointed to by urb->transfer_buffer (and urb->setup_packet for control transfers). Alan Stern ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
