SCO UNIX SysV device driver (is the manual correct?)

michael k finegan mfinegan at uceng.UC.EDU
Sun Jun 10 07:29:28 AEST 1990


    I have written a device driver for a graphics board. It PANICS the
system on the first access to graphics board memory. I have followed
the suggestions of the SCO Device Driver Writer's Guide, and suspect
that some of the info. is incorrect. No, I can't call SCO, as I am
waiting for authorization to get software support (~$500).

    For those with familiarity: I check to see if the physical address
is being used with a call to vasmapped(). It isn't. I then allocate
virtual address space using vasmalloc(). This returns fine. I then
bind the physical address to the virtual address using vasbind(). This
also returns successfully. On access to the physical memory via
bcopy(vaddr,caddr_t,number), I get a panic, with vaddr being the contents
of one of the registers (esi?) displayed by the panic (actually a trap 0x...E).

    I have tried sptalloc(), with provisions for not swapping page (PG_P), ...
I have also tried every other possible way to access physical memory with no
success. I/O accesses (outb) work fine, and I suspect that the 'memory' access
described in the Device Driver Writer's Guide may actually refer to memory
mapped I/O, which means that my memory accesses are being converted to outb's ?

    The device driver examples in the book, or on disk (in the directory
/usr/lib/samples/pack.d/*), have zero examples of physical memory access.
A previous device driver (for another graphics board, but same O.S)
worked for one type of physical memory access: copyio(paddr,caddr,number,R_?UD).
Did this work because the board allowed I/O access to memory ? I know the
current board's memory is not accessible via I/O.

    Any ideas would be appreciated. It is probably a misunderstanding, on my
part, of the manual - but it really shouldn't be so difficult ...

					Thanks,
						Michael K. Finegan, Jr.
						mfinegan at uceng.UC.EDU

Please reply via EMAIL {as well as | instead of} any post.



More information about the Comp.unix.wizards mailing list