pic@uunet.uu.net (Peter Corke) (08/21/89)
I am porting a device driver which worked under SunOS 3.x to Sun4.0.1, and
am having some problems. The driver uses physio() (as per the Guide to
Writing Device Drivers) to lock down the user's i/o buffer and map it into
the kernel.
Under SunOS 4.0.1 it seems that this mapping only exists within the
context of the i/o issuing process ie/ if the interrupt occurs during
execution of another process, the kernel mapping is not there and
references to that i/o buffer cause a trap.
I've checked all the obvious things, critical sections are OK, not using
i/o buffer after iodone() etc.
If you have any clues please mail me,
Peter pic@mimir.oz.au, uunet!munnari!mimir.dmt!pic
------
Peter Corke, PHONE: +61 3 487-9259
CSIRO, Div. Manufacturing Technology, Preston, Victoria, 3072, AUSTRALIA
--
Peter Corke, PHONE: +61 3 487-9259
CSIRO ACSNET: pic@mimir.dmt.oz
Div. Manufacturing Technology INTERNET: pic@mimir.dmt.oz.au
Preston, Victoria, 3072, AUSTRALIA UUCP:{uunet,ukc,mcvax}!munnari!mimir.dmt!picbeau@ultra.com (Beau James {Manager - SW Devel - Ultra Networks}) (09/02/89)
--> I am porting a device driver which worked under SunOS 3.x to Sun4.0.1, and
--> am having some problems. The driver uses physio() (as per the Guide to
--> Writing Device Drivers) to lock down the user's i/o buffer and map it into
--> the kernel.
Physio() does not map the user buffer into kernel virtual address space in
4.0. That's not normally necessary, since you are typically only locking
the buffer down in order to DMA into/out of it. When you call mbsetup()
to map the buffer onto the bus, the buffer does get mapped inot DVMA
space, which is also a valid part of kernel virtual address space.
This has the additional benefit of avoiding double-mapping the pages in
kernel virtual address space. That saves kernel page table entries and
helps avoid cache aliasing problems.
If you also want to examine the contents of the buffer while in the
kernel, the safest thing to do is to look at it at is DVMA-mapped address.
Beau James beau@Ultra.COM
Ultra Network Technologies {sun,ames}!ultra.com!beau