ftw@datacube.UUCP (02/12/88)
Attention: Motorola System V R3V3 gurus (please?)
Background:
I've ported character driver from the Sun 3 environment to the Sys V
environment on a Motorola 2616. She seems to work, but there are a few
remaining nits I'd like clarification on:
I need to buy LOTS of VME address space, and map it into a user-addressable
chunk of virtual memory. Of course, I don't want the address space either
cached or paged. Right now, I do this with appropriate calls to Sys V's
shared memory functions, and I use the Motorola extensions that allow one
to buy physical addresses. This is of course done from user space, and
doesn't involve my driver. The scheme has some deficiencies, though. One
must be root to map physical addresses, and worse, the shared memory
descriptors are not released when the user program exits (or dies). I have
a description of a function called sptalloc(), but the constants used in
one of the arguments (PG_P and PG_LOCK) don't exist in any of my headers.
Could someone tell me more about sptalloc()?
As a side note, I have heard from a Motorola FAE that shared memory under
R3V3 is broken in some significant fashion. He was not able to tell me
exactly how; only that it is broken. Funny part is that it seems to work
well for me. Can anyone confirm or deny shared memory bugs in this version?
Interrupt handlers and the infamous sysgen(1M) utility. Does *any* description
of a sysgen "script" exist? It must have taken me about two or three days to
figure out that in order to get a minor device number passed as an argument
to an interrupt handler, I need to say "This is a character device." instead
of "This is an interrupt device." in the driver attributes field. Along
those lines, I read that the actual argument to an interrupt handler is
the minor number, possibly up-shifted and or-ed with some low bits of the
interrupt vector, depending on how many vectors fan in to one handler. This
just doesn't seem to be true on my system however. It is also interesting to
note that if I tell sysgen that such-and-such is a character device, and
I don't specify what the minor number is, the kernel that is generated will
hang after displaying the System V banner.
Farrell T. Woods
Datacube Inc. Systems / Software Group 4 Dearborn Rd. Peabody, Ma 01960
VOICE: 617-535-6644; FAX: (617) 535-5643; TWX: (710) 347-0125
INTERNET: ftw@datacube.COM
UUCP: {rutgers, ihnp4, mirror}!datacube!ftw
"OS/2 -- Half an operating system"ftw@datacube.UUCP (02/12/88)
...one thing I forgot:
I also need to test if a given piece of hardware exists on the bus. There
is a function called bprobe() that does this. It takes two args, the first
is a physical address, the second is a char sized quantity to be *written*
to that address. For my driver, it is unacceptable for the probe to write
to the address. Also, since not all of the hardware I intend to support
will respond to byte-width accesses, I need a 16-bit sized probe as well.
There seems to be an "sprobe" function in my kernel, but I it must not
be what I think it is because it never goes out to the bus (confirmed by
using a VME bus analyzer).
Questions: How do I test for *read* access to hardware? What exactly is
the sprobe() function?
SunOS has peek() and peekc(), which will probe for hardware and return
a 16-bit or 8-bit (resp.) quantity at the address you ask for, or they
returns (int)-1 if there was a bus-error. These are what I need to model
under System V.
Thank You for Your Support.
Farrell T. Woods
Datacube Inc. Systems / Software Group 4 Dearborn Rd. Peabody, Ma 01960
VOICE: 617-535-6644; FAX: (617) 535-5643; TWX: (710) 347-0125
INTERNET: ftw@datacube.COM
UUCP: {rutgers, ihnp4, mirror}!datacube!ftw
"OS/2 -- Half an operating system"heiby@mcdchg.UUCP (Ron Heiby) (02/17/88)
ftw@datacube.UUCP writes: > As a side note, I have heard from a Motorola FAE that shared memory under > R3V3 is broken in some significant fashion. He was not able to tell me > exactly how; only that it is broken. Funny part is that it seems to work > well for me. Can anyone confirm or deny shared memory bugs in this version? The only "shared memory" bug I am aware of is actually in the "ipcs" command. (You know, the one that tells you what ipc facilities are in use.) Under some circumstances, ipcs under System V/68 R3v3 will report shared memory that does not exist any more. This was to be fixed in the next release, but by the time we found out about it, R3v4 was just about out the door. So, I don't know if it's in v4 or not, but it will be fixed in R3v5, for sure. In any event, shared memory works correctly. The only other problem I've heard of was with a customer who created far more shared memory segments than he had physical memory, then wondered why the cpu was spending so much time "doing nothing", when it was actually spending a great deal of time waiting for shared memory segments to move between main memory and the swap device. -- Ron Heiby, heiby@mcdchg.UUCP Moderator: comp.newprod & comp.unix "Intel architectures build character."
love@sems.SE (Love Feuer UniVox Inc.) (02/21/88)
In article <4345@mcdchg.UUCP> heiby@mcdchg.UUCP (Ron Heiby) writes: >ftw@datacube.UUCP writes: >> As a side note, I have heard from a Motorola FAE that shared memory under >> R3V3 is broken in some significant fashion. >> ... > >The only "shared memory" bug I am aware of is actually in the "ipcs" command. > > [ Rest of article deleted ] > I have never got shared memory to work with all its features on the NCR T32 (68020) SysV.2. The problem I had was to get it attached to another place in memory than some kilobytes after the break point of the process. I tried to make the shared segment as an overlay of an array of chars, but the only thing I got was "Illegal address". And then there was the SHMLBA thing. The manual entry for shmop(2) tells that SHMLBA was used if the SHM_RND flag was set in the third argument of shmat(2). If SHM_RND was set, the segment was attached to (char *) (The_address_you_gave_as_an_argument - T_a_y_g_a_a_a modulus SHMLBA). Just one problem. SHMLBA was a macro for ptob(1). A very nice function, which sadly enough was not represented by the C-library, and not mentioned anywhere in programers ref. man. for the T32. The biggest pain with having a shared memory segment attached a few kilos after your break point, is that malloc and similar things raises the break point to obtain more memory. Sooner or later they will run into the shared memory segment and stop due to a check in (s)brk(2) which prevents a nice mixup with other processes' memory. This means that malloc will only be able to use the memory between the break point and the start of a shared mem. seg., which is 16 or 32k if my memory serves me. The solution to this is to move the break point forward a few hundred kilobytes, attach the segment, and then move the break point back to its original point. But you are still limited to a few hundred Kbytes of malloc and not the maxmimum of a process which is defined in config.h This problem might be more specific for NCR than UNIX, but I thought you should know. There is even a chance that NCR have fixed the bug(s) since I encountered them about a year ago. ------------------------------------------------------------------------------ In real life : Love Feuer Phone +46 8 21 62 78 | +46 8 723 10 87 Cyberspace attach : {your problem}!{uunet|cernvax|mcvax|unido}!enea!sems!love Disclaimer : cat laws > /dev/null Famous last words: "Even I can do THAT!" - or - "We are the members of the mighty adventure party. Join us or die."