Paul Kranenburg <pk@cs.few.eur.nl> writes:
> 
> > I was trying to read something from near the end of /dev/mem yesterday with
> > 
> > # dd if=/dev/mem bs=32768 skip=65536 count=1
> > 
> > (I wanted a copy of the eprom image from my pc532...)
> > the response I got was:
> > 
> > dd: seek offsets cannot be larger than 2147483647
> 
> dd is probably easily fixed to allow larger offsets.
> 
> But you might be in for other surprises if you use dd to read /dev/mem
> this way. Representing physical memory, /dev/mem might contain holes
> that dd will stumble on. On character devices, dd doesn't use lseek(),
> but rather just reads blocks until it gets where it wants to be; not always
> pleasant. Also, you might run over mapped devices on some architectures,
> reading their registers etc., and making some of them unhappy..

Well, that would explain why dd chewed up about a minute of CPU
time and then stopped the machine dead in it's tracks when I tried
count=2 skip=65535...  I was thinking it might be a bug in the
/dev/mem driver.  Guess not, but that brings up another problem.
The dd(1) man page says:

     skip=n   Skip n blocks from the beginning of the input before copying.
              On input which supports seeks, a lseek(2) operation is used.
              Otherwise, input data is read and discarded.  For pipes, the
              correct number of bytes is read.  For all other devices, the
              correct number of blocks is read without distinguishing between
              a partial or complete block being read.

I *hope* that the /dev/mem driver implements lseek, if not, I don't
see how it could be of much use.  If it does, it makes the dd man
page look like it's incorrect about saying it will seek if it can.
Perhaps another thing to send-pr?

Jon