The disk and controllers are doing almost nothing regarding suspend. that's a bug. we'll have to go again over it to add the bits needed to handle suspend/resume of usb ports and devices in the right way.
regarding the error I don't know what it could be. but in any case it shouldn't be %r as Erik said. On Thu, Aug 27, 2009 at 5:29 AM, erik quanstrom<[email protected]> wrote: >> wrenread: error on w0(1691022): %r > > something's wrong here. %r never prints "%r" > unless errstr is literaly "%r". does your source > match sources? > >> where w0 is the disk itself. Note that the final message >> states 89805 blocks were copied, whereas initially >> 89806 blocks were queued - was the error on just this one >> block? If so, what could possibly be the reason? I doubt >> my USB drive would be acting up. > > why couldn't your usb drive have a bad sector or some > other problem? you could even get less than the requested > number of bytes without an error. read(2) says that it's > perfectly fine for pread to return less than the requested > number of bytes. to be really safe, wrenread should use > something like preadn. > > i would think that usb would be a bit antisocial if pread > returned less than the requested number of bytes if > RBUFSIZE <= 64k. but otoh, if it really is a hardware > limit, it would make sense. we'd just call the hardware > antisocial in that case. ☺ > > - erik > >
