This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Anyone know about interaction of 'dd' with memory cards?


----Original Message----
>From: Corinna Vinschen
>Sent: 23 September 2005 10:28

> On Sep 22 18:54, Eric Blake wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> 
>> According to Dave Korn on 9/22/2005 11:22 AM:

>> Have you tried it on Linux, for comparison?  

  Not yet.  Then again, since it seems like a 'doze system-level problem,
all that would tell us is that linux has a better driver...

>> If anything, it is cygwin
>> and not dd that is at fault here (your analysis about dd stopping at EOF
>> is correct), although I don't know if Windows provides enough hooks for
>> cygwin to detect end of disk to turn that into EOF.
> 
> Dunno if that helps, but AFAICS, there's Windows at fault, not Cygwin.
> I tried running dd as Dave did, reading from Compact Flash and Memory
> Stick. 
> 
> I got a very different result, but it's still weird.  For instance,
> reading from an 8 Megs Memory Stick:
> 
>   $ strace -o dd.out dd if=/dev/hdc of=ms.img bs=1024
> 
>   [Time passes, somewhat more than a minute...]
> 
>   dd: reading `/dev/sdc': Permission denied

  Hey, what's with the hdc/sdc thing?

>   7920+0 records in
>   7920+0 records out
>   8110080 bytes (8.1 MB) copied, 63.66 seconds, 127 kB/s
> 
> Ok, let's have a look into the strace output.  This is the interesting
> point (slightly rearranged for better readability):
> 
>     20 10560402 [main] dd 1428 fhandler_dev_raw::raw_read: read 61440
>                          bytes from file into buffer
> 52702874 63263276 [main] dd 1428 fhandler_dev_raw::read_file: 0 (err 121)
>                          = ReadFile (1584, 268508024, to_read 61440, read
>    0, 0) 95 63263371 [main] dd 1428 seterrno_from_win_error:
>                          /src/cygwin/winsup/cygwin/fhandler_raw.cc:206
>                          windows error 121
>    27 63263398 [main] dd 1428 geterrno_from_win_error: unknown windows
>                          error 121, setting errno to 13
> 
> So what we have here is the last call to ReadFile on the raw device.
> The previous call has read exactly the last 61440 bytes from the medium.
> The above call is the one which is supposed to return 0 bytes, EOF.
> 
> But it doesn't.  Instead, it *times out* after about 52 seconds (Huh?)
> with Windows error 121.  So, what's that, Windows error 121:
> 
>   $ net helpmsg 121
> 
>   The semaphore timeout period has expired.
> 
> Er... am I in the wrong movie or what?  What semaphore, please?

  Beats me.  If I cat /dev/sdb, once it goes past the end of the card, it
just starts returning '<' chars forever.

> Dave, you will have to debug this on your machine.  

  Can do.

> What does ReadFile
> in fhandler_dev_raw::read_file() do on your machine?  When it reads
> beyond the physical EOF, how many bytes does ReadFile return?  What
> does it actually copy to the buffer?

  Will get back to you on this.

> And then the interesting question occurs... why is it different on
> your machine than it is on mine?  Do differences between card readers
> influence what happens?  Is that another driver?

  USB2.0 CF CardReader USB Device
  USBSTOR\DISK&VEN_USB2.0&PROD_CF__CARDREADER&REV_\1234609_&0

which I presume is mounted on

  USB Mass Storage Device
  USB\VID_07CC&PID_0501\1234609_

and

  Generic volume
  STORAGE\REMOVABLEMEDIA\7&388FF7C9&0&RM


- all the drivers are standard M$ stuff like usbstor.sys, volsnap.sys,
disk.sys, partmgr.sys.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]