[net.micro.mac] seek limit on /dev/mem with Xenix

steve@tove.UUCP (Steve D. Miller) (07/30/85)

   I've been trying to get an IBM Professional Graphics Controller
working for a few weeks now.  Before I tried writing kernel device
drivers, I decided that I would like to get a skeletal driver working
using lseeks() in /dev/mem to access the card's buffers.  I wrote one,
and it failed in mysterious ways.  Not having done anything with 
/dev/mem before, I decided that I was doing something stupid and
obvious, and got another device driver (that was known to function
and had been used before at another site), figuring, "this'll work,
and I can probably figure out what I was doing wrong by looking at
the source."  No luck.

   The second driver looked very much like the one I had written, so
I started to get the idea that something strange was going on (no
big surprise -- this *is* Xenix we're discussing here).  To make a
long story short, I knocked out a little program that takes one
argument, then lseek()s out that far and tries to read a char.  If
I tried lseeking past location 523776 decimal, I would get the right
return value from lseek, but -1 and ENXIO from read().  The situation
gets more suspicious when you consider that I have a 512K machine.

   I did some poking around in and out of the kernel, and saw things
that looked like the /dev/mem drivers were limiting what addresses
could be accessed.  Sure enough, I got a 512K card (we're talking 1
meg total at this point), plugged it in, and all of my problems went
away.  The buffers for the graphics card start at 811008 decimal --
comfortably below the 1 meg limit.  Furthermore, my seek/read tester
now blows up at 1048064 decimal in exactly the same way that it
did at the lower limit with only 512K RAM.

  Obviously, something unpleasant is going on here.  I suspect that
(in the name of providing more feedback to the user by way of giving
him or her ENXIO if the kernel "knows" that there isn't any memory
out there) the drivers for /dev/mem are making it impossible to
send data where one may want it to go.

   Now for the big question(s):

	(1)  Is this normal behavior for other small Unix implementations?

	(2)  Is this really sensible behavior?

	(3)  Are there hardware considerations that make it impossible
		to handle this in any other way?

   My own idea of /dev/mem is something that interprets seeks and read/
writes as "put this data on the address bus at this spot and assume I
know what I'm doing".  Is this an invalid assumption?

	-Steve

-- 
Spoken: Steve Miller 	ARPA:	steve@maryland	Phone: +1-301-454-4251
CSNet:	steve@umcp-cs 	UUCP:	{seismo,allegra}!umcp-cs!steve
USPS: Computer Science Dept., University of Maryland, College Park, MD 20742

steve@tove.UUCP (Steve D. Miller) (07/31/85)

   I apologize for cluttering up net.micro.mac with (yuck) PC/AT ramblings
(hey, I just use one, I don't *own* one).  I know I typed "net.micro.pc";
my saved copy of the article backs me up.  I'll not post it again until
the software around here looks like it's been fixed...

	-Steve




-- 
Spoken: Steve Miller 	ARPA:	steve@maryland	Phone: +1-301-454-4251
CSNet:	steve@umcp-cs 	UUCP:	{seismo,allegra}!umcp-cs!steve
USPS: Computer Science Dept., University of Maryland, College Park, MD 20742