HDTenEightyP/NetNews huggingface dataset:
From: gram@aim1.aztec.co.za (Graham Wheeler)
Subject: Re: The STREAMS scheduler
Organization: Aztec Information Management
Date: Fri, 4 Sep 1992 09:37:41 GMT

gram@aim1.aztec.co.za (Graham Wheeler) writes:

>Anyway, the trick was that there is a service request value in the
>dual port memory as well, which is set by the card to hex FF when it
>has handled the last request. So I now check this as well, and everything
>seems to be fine.

It turned out that this was *not* the case. Even though this fix worked,
it shouldn't have! In the end, I scrapped the write-side service, put all
the messages on my own singly linked list, and do the write side service
from within the interrupt handler. So the interrupt handler looks like:

	ipibintr() {
		ind = dualPort->ind;
		status = dualPort->status;
		switch (ind) {
			/* Interrupt type-specific processing */
		}
		if (data waiting to be retrieved from card)
			retrieve data;
		if (card RPC not busy and message on list) 
			remove message from list and do RPC;
	}

It still locks up now and then, but I think that is a timing problem due
to the use of spinlocks when retrieving data from the card. The RPC interface
to the card is being redesigned to remove the spinlocks, and I will see what
happens after that. I have removed the calls to splstr, as the consensys
seems to be that this is not a Good Thing.

-- 
Graham Wheeler                     | "That which is weak conquers the strong,
Software Systems Engineer/Student  | that which is soft conquers the hard."
Aztec Information Management/UCT   | 		Lao Tzu - Tao Te Ching Ch. 78
gram@aim1.aztec.co.za / gram@cs.uct.ac.za 
From: aakash@hpcupt3.cup.hp.com (Aakash Sahai)
Date: Wed, 26 Aug 1992 18:14:19 GMT
Subject: Re: How to sleep in device driver with a time out
Organization: Hewlett Packard, Cupertino
Newsgroups: comp.unix.internals

> I assume you call timeout(function_address, int_parameter, time_in_ms)
> and then go to sleep().  If the timeout period expires, the function
> gets called with your parameter and you can return to user mode normally.
> Is this correct?  Do I have the parameters correct?

The last argument to timeout is generally specified in terms of HZ parameter.
where HZ = number of ticks per second generated by timer. For example, if HZ
equals 100 and you specify the last parameter as 7 then the timeout will occur
after 7/100 th of a second ( 70 ms ).

Normally, in such condition when an operation has to be aborted mid-way because
of timeout, a code sequence of the following form can be used -

/* Routine called by timeout.  */

int	ErrorOccurred;

OpnTimedOut(SleepAddr)
caddr_t	SleepAddr;
{
	ErrorOccurred++;
	wakeup (SleepAddr);
}

	...
/* Routine doing actual I/O and setting the timeout */
{
	...

	/* Start the actual I/O */
	/* Block device interrupts */
	if ( ! I/O Done ) {	/* No need to sleep if we have already got */
				/* an interrupt quick enough */
		ErrorOccurred = 0;
		/* Block Clock interrupts */
		id = timeout ( OpnTimedOut, SleepAddr, timeout_value );
		sleep ( SleepAddr, priority );
		if ( ! ErrorOcurred ) { /* Device responded and we were */
					/* woken up by ISR */
			untimeout ( id );
			/* Unblock clock and device interrupts */
			/* Do the normal processing */
		} else {
			ErrorOcurred = 0;
			/* Unblock clock interrupt */
			/* Code to reset the controller etc. */
			/* Unblock device interrupt */
			/* Return error etc.*/
		}
	}
		....
}

NOTE :	This is just a skeleton and actual code may vary depending on the
	capability of the controller and/or driver design style. 
	
> 
> Also, how do I return a status to a C program from a device driver
> ioctl function?
> 

Probably, you can declare a structure and pass a pointer to this structure
from the user level program as the third argument to ioctl. Then in your
driver you can do a "copyout()" of the status to the area pointed to by
this pointer.

That is -

/* User program */
struct	status	ret_status;

		....
		....

	ret = ioctl ( fd, cmd, &ret_status );

		...

/* Kernel code in the driver */

dev_ioctl ( dev, cmd, arg )
{
struct	status	dev_status;
		....
		....

	copyout (dev_status, (struct status *)arg, sizeof(struct status));
		
		....
}


-- Aakash Sahai

/*
 * Yeah, you are right - HP is not responsible for what I write.
 */
Newsgroups: comp.unix.internals
From: boyd@prl.dec.com (Boyd Roberts)
Subject: Re: The STREAMS scheduler
Organization: Digital Equipment Corporation - Paris Research Laboratory
Date: Tue, 25 Aug 1992 20:18:36 GMT

As a general rule, do not spl() inside an interrupt routine.

Trying to enable a write side queue from an interrupt routine
smacks of bad design.  Just what are you trying to communicate
to the the write queue?


Boyd Roberts			boyd@prl.dec.com

``When the going gets wierd, the weird turn pro...''
Newsgroups: comp.unix.internals
From: gram@aim1.aztec.co.za (Graham Wheeler)
Subject: Re: The STREAMS scheduler
Organization: Aztec Information Management
Date: Wed, 26 Aug 1992 14:36:06 GMT

I have had a few responses to my previous article and thought I would 
at least announce that I have found a solution. It was obvious in some
ways, but not at all in others.

My original posting (shortened):

>I have been having problems with a STREAMS device driver which deadlocks.
>The interface to the hardware is via an RPC mechanism, with every request
>being followed by a confirmation. Only one request may be made at a time,
>so communication is synchronous. The exception is data arriving from the
>hardware, which is async. The RPC mechanism is based on interrupts (I
>interrupt the card to make a request, it interrupts me to send a confirm).
>The async indication is just an interrupt from the card.

>At first I thought the problem could be nested interrupts making me lose
>a confirm when an indication comes in. My interrupt handler thus begins:

>s = splstr();
>ind = dualport->indication;
>status = dualport->status;
>splx(s);

The whole problem lies herein - although I was blocking interrupts here,
it was already too late! I forgot that there is some OS overhead before
my handler gets called; not like DOS where you have to enable interrupts
again yourself. The net result was that my synchronous handshake interrupt
was being interrupted by an asynch one, which trashed the `ind' value 
(more specifically, I saw two data indications rather than a confirm and
an indication). I had a busy flag which would get cleared when a confirm
came in, and this wasn't happening. What screwed me around quite a bit
was that I was printing this flag out when things got stuck (retrieved
with an IOCTL) and it *was* clear. I eventually decided that this must be
the problem anyway, and that once things went wrong everything became
convoluted, with the end result that somehow the flag was cleared without
service being rescheduled. I still don't understand it all.
works.

Anyway, the trick was that there is a service request value in the
dual port memory as well, which is set by the card to hex FF when it
has handled the last request. So I now check this as well, and everything
seems to be fine.

One respondent criticised the use of splstr in an interrupt handler,
saying that this would possibly lower the priority rather than 
raise it. The DDI/DKI manual says that splstr sets the priority high
enough to block the highest priority STREAMS device, so I don't think
this criticism is valid. If anyone has any comments about this, lets
hear them.

-- 
Graham Wheeler                     | "That which is weak conquers the strong,
Software Systems Engineer/Student  | that which is soft conquers the hard."
Aztec Information Management/UCT   | 		Lao Tzu - Tao Te Ching Ch. 78
gram@aim1.aztec.co.za / gram@cs.uct.ac.za 
Newsgroups: comp.unix.internals,comp.unix.sysv386
From: woods@robohack.UUCP (Greg A. Woods)
Subject: Re: SIGKILL problem with Interactive
Organization: Elegant Communications Inc.
Keywords: SIGKILL Interactive
Date: Wed, 26 Aug 92 04:27:55 GMT

In article <1992Aug17.110710.20862@virtech.uucp> cpcahil@virtech.uucp (Conor P. Cahill) writes:
> This is easy to re-generate.  Just run "ls -lR /" and when the output 
> starts, enter <Ctrl>-s.   After a few moments the output buffer will fill
> and the program will be put to sleep pending the receipt of a ctrl-q.
> At this point, signals are almost always disabled and if you send a kill -9,

I'd consider any tty driver that did that to be badly broken....
-- 
						Greg A. Woods

woods@robohack.UUCP woods@Elegant.COM  VE3TCP	UniForum Canada & ECI
+1 416 443-1734 [home] +1 416 595-5425 [work]	Toronto, Ontario; CANADA
Newsgroups: comp.unix.internals
From: am815@cleveland.Freenet.Edu (Joel Peter Anderson)
Subject: STREAMS M_ERROR Message problem
Reply-To: am815@cleveland.Freenet.Edu (Joel Peter Anderson)
Organization: Case Western Reserve University, Cleveland, OH (USA)
Date: Wed, 26 Aug 92 13:03:06 GMT

I am running UHC's System V.4 Unix on a 486.

I have a serial communications card which has loaded on it a
protocol stack.  A user application interacts with the protocol
stack through a device driver whose head is a STREAM.  To get and
put data to the driver, a user application would use read() and
write().

Currently, if the protocol stack encounters an error on a user
application write, it sends back to the driver a negative status
code.  The driver then converts this into a M_ERROR message which
is put on the read queue using putq.  To make turn the message into
an M_ERROR message the following is done:

make_error_msg(mblk_t *mp, int status_code) {
    
    mp->b_datap->db_type = M_ERROR;
    mp->b_rptr = mp->b_datap->db_base;
    *mp->b_rptr = status_code;
    mp->b_wptr = mp->b_rptr + sizeof(char);
    ....
} 

The result is the next read or write returns with a -1 and errno is
set to 256 - status_code.  The PROBLEM is that the only way to
clear the error condition is to close the device.  Typically, the
error does not warrent a close.

The man pages on STREAMS error message types indicate that there
are two forms of the M_ERROR message - one byte and two byte.  The
one byte form is suppose to lock out all system calls to the device
except close and poll.  However, the two byte form is set up so
that "the first byte [of the status code] is the read error and the
second byte is the write error.  This allows for modules to set a
different error on the read-side and write-side.  This allows a
module to set an error on just one side of the STREAM."  When I
change the code to construct a two-byte M_ERROR msg...

make_error_msg(mblk_t *mp,char status_code) {
    
    mp->b_datap->db_type = M_ERROR;
    mp->b_rptr = mp->b_datap->db_base;
    *mp->b_rptr = status_code;
    *(mp->b_rptr + 1) = NOERROR;
    mp->b_wptr = mp->b_rptr + ( 2 * sizeof(char));
}

the result is the same as with the one byte M_ERROR message.  Both
read and writes return a -1 with errno = status_code.  What am I
doing wrong?
-------------------------------------------------------------------------
"We know only the strong will survive, But the meek will inherit.
 So if you've got a coat of arms, oh friend, I suggest we wear it."
                                        John Mellencamp.
-------------------------------------------------------------------------
  joela@Apertus.COM  s/w engneer |Freenet: am815@cleveland.freenet.edu
    Joel Peter Anderson          |PNET: jpa@pnet51.orbit.mn.org
    Apertus Technologies         |GEnie:J.ANDERSON71
-------------------------------------------------------------------------
-- 
-------------------------------------------------------------------- 
<Joel Peter Anderson>               |     
Freenet: am815@cleveland.freenet.edu|    Signature under 
 GEnie:J.ANDERSON71                 |      construction.
Newsgroups: comp.unix.internals
From: hoang1@litwin.com (Dave Jackson)
Subject: ioctl request fail in SCO (ARP protocol)
Organization: Litwin Process Automation
Date: Fri, 28 Aug 1992 13:29:06 GMT

Hi,
I'm writing a program to read the ARP cache.
But I have the problem when using SIOCGARP in SCO/ODT ver 2.0:
  
  .
  .
  .
  int soc;
  struct arpreq ar;
  .
  .
  .
  /*
  **  Execute the IOCTL to read the ARP cache, if the host is not
  **  currently in the cache, this ioctl will fail.
  */
  if ((i = ioctl( soc, SIOCGARP, &ar )) != 0)

  It's always failed and return:
    errno == ENXIO
    ioctl: No such device or address

But if I test in DEC5000/200 Ultrix 4.2 or SUN/sparc OS 4.1.1 is ok.

Do I miss anything in SCO env.

I will post or mail my source code if you request.

Thanks in advance,

Ted Hoang
Litwin Process Automation
Email:hoang1@dynsim1.litwin.com

Newsgroups: comp.unix.internals
From: gram@aim1.aztec.co.za (Graham Wheeler)
Subject: The STREAMS scheduler
Organization: Aztec Information Management
Date: Tue, 25 Aug 1992 10:39:29 GMT

Hi all

I have been having problems with a STREAMS device driver which deadlocks.
The interface to the hardware is via an RPC mechanism, with every request
being followed by a confirmation. Only one request may be made at a time,
so communication is synchronous. The exception is data arriving from the
hardware, which is async. The RPC mechanism is based on interrupts (I
interrupt the card to make a request, it interrupts me to send a confirm).
The async indication is just an interrupt from the card.

At first I thought the problem could be nested interrupts making me lose
a confirm when an indication comes in. My interrupt handler thus begins:

s = splstr();
ind = dualport->indication;
status = dualport->status;
splx(s);

the idea being to save the important info before another interrupt messes
with it. This didn't help. In the end, I changed the data indication 
interrupt to increment a counter, and put the data dequeueing (which was
previously in the interrupt handler) into the write service routine.
So I have something like:

intr() {
	...
	switch (ind) {
	case DATA_INDICATION:
		queuedData++;
		break;
	...
	}
	if (queuedData) qenable(writeQ);
}

wsrv() {
	if (queuedData) dequeueData();
	while (mp=getq()) {
		...
	}
}

This was also motivated by trying to keep the interrupt handler as simple
and short as possible.

It still locks up on occasions, and I have noticed that the interrupt handler
is being called, and it is calling qenable, BUT THE WRITE SERVICE ROUTINE
IS NOT BEING CALLED AS A RESULT. Both of these routines have cmn_err
statements at the start, and, when viewing the console after a lockup, I
can see things like:

	IN INTERRUPT
	IN WSRV
	IN INTERRUPT
	IN INTERRUPT
	IN INTERRUPT

After which nothing happens (the card cannot receive more data until the
existing data is dequeued, so no further interrupts are generated).

It thus seems that calling qenable is not sufficient to schedule a
queue. Note that I never call noenable. 

Does anyone know the details of how qenable works, and why my service
routine is not getting scheduled?

-- 
Graham Wheeler                     | "That which is weak conquers the strong,
Software Systems Engineer/Student  | that which is soft conquers the hard."
Aztec Information Management/UCT   | 		Lao Tzu - Tao Te Ching Ch. 78
gram@aim1.aztec.co.za / gram@cs.uct.ac.za 
Newsgroups: comp.unix.wizards
From: etxmesa@eos.ericsson.se (Michael Salmon)
Subject: Re: nroff, troff
Reply-To: etxmesa@eos.ericsson.se (Michael Salmon)
Organization: Ericsson Telecom AB
Date: Wed, 2 Sep 1992 07:52:11 GMT

In article <1992Sep1.212608.17434@umbc3.umbc.edu>, grabenst@umbc4.umbc.edu (Mr. Michael Grabenstein; ACS (GUEST)) writes:
|> 	I am tring to get nroff or troff to paginate a textfile.
|> I just need to center a few things, indent under the headings.
|> Simple stuff, I have looked into the macros me and ms, but have
|> not had any luck. The commands I am getting in the man don't seem
|> to do the same thing on the screen (or printer). I know O'Riely
|> makes a a book about this, but I did not want to have to buy it
|> (or read it). The man page I get on nroff says nothing about its
|> text commands, just its command line arguments. I am using a Sun
|> (SunOS 4.1.1) and printing to a DecScript laser printer. The Dec
|> 5000 is also my print spooler. any suggestions anyone?
|> 	Thanks!

You should have a document entitled "Formatting documents" in your Sun
documentation or AnswerBook. There you will find descriptions of the
various macro packages along with tbl and eqn. There are also man
pages for the macro packages. The reason why you don't get info on
{n,t}roff in the man pages is that it's not really intended for users
to use, it is the assembly language of formatting.

-- 

Michael Salmon

#include	<standard.disclaimer>
#include	<witty.saying>
#include	<fancy.pseudo.graphics>

Ericsson Telecom AB
Stockholm
From: sweh@spuddy.uucp (Stephen Harris)
Newsgroups: comp.unix.wizards
Subject: Re: 'cat'ting 8 bit data to the terminal.....
Date: 31 Aug 92 18:01:36 GMT
Organization: Spuddy's Public Usenet Domain

In article <14372@auspex-gw.auspex.com> guy@Auspex.COM (Guy Harris) writes:
>output to 7 bits - but also passes through:
>	whatever "telnet" or "rlogin" client software you're using
>	whatever "telnet" or "rlogin" *server* software is running on
>
>Furthermore, as I noted, it's *output* that never gets stripped to 7

Ok, in the Sun case (SunOS4.1.1), does the telnet/rlogin client strip data?
Its definitely output that is stripped - even if I rlogin from the machine to
itself with the -8 flag.  Otherwise cat'ting an ELOT928 file to the screen
gets stripped.

Thanks.
-- 
                               Stephen Harris
               sweh@spuddy.uucp    ...!uknet!axion!spuddy!sweh

 * Meeeeow ! Call Spud the Cat on > +44 203 638780 < for free Usenet access *
Newsgroups: comp.unix.wizards,comp.unix.questions
From: terry@thisbe.Eng.Sandy.Novell.COM (Terry Lambert)
Subject: Re: reliable signals under BSD / SVR4
Keywords: signals, reliable, software interrupts
Organization: Novell NPD -- Sandy, UT
Date: Fri, 4 Sep 1992 00:44:36 GMT

In article <acourtny.715556934@unix1.tcd.ie> acourtny@unix1.tcd.ie (Antony A. Courtney) writes:
>There are some "hacks" to get around this, if you're environment lets you
>write the centralized control loop for the program.  But usually SIGIO is
>useful in cases where that isn't possible, e.g. when using an X toolkit.

	Wrong.  In XTMainAppLoop() in the X toolkit, there are hooks for
adding input sources to be "select()"ed on.  Since this is the toolkit used
to build most other toolkits (ie: Motif), this works there also.  The
routines of interest are:

	XtAddInput()
	XtAppAddInput()
	XtRemoveInput()
	XtRemoveAllInputs()

	Read the fine manual.


					Terry Lambert
					terry_lambert@gateway.novell.com
					terry@icarus.weber.edu

---
Disclaimer:  Any opinions in this posting are my own and not those of
my present or previous employers.
Newsgroups: comp.unix.wizards
From: grabenst@umbc4.umbc.edu (Mr. Michael Grabenstein; ACS (GUEST))
Subject: nroff, troff
Organization: Univ. of MD, Baltimore County
Date: Tue, 1 Sep 1992 21:26:08 GMT

	I am tring to get nroff or troff to paginate a textfile.
I just need to center a few things, indent under the headings.
Simple stuff, I have looked into the macros me and ms, but have
not had any luck. The commands I am getting in the man don't seem
to do the same thing on the screen (or printer). I know O'Riely
makes a a book about this, but I did not want to have to buy it
(or read it). The man page I get on nroff says nothing about its
text commands, just its command line arguments. I am using a Sun
(SunOS 4.1.1) and printing to a DecScript laser printer. The Dec
5000 is also my print spooler. any suggestions anyone?
	Thanks!

Later,
	Mike
	ZMEG@AACC.bitnet
	or grabenst@umbc3.umbc.edu
}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{}{
The universe -- The ultimate fractal. 
	--Personal theroy
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: 'cat'ting 8 bit data to the terminal.....
Date: 30 Aug 92 01:38:13 GMT
Organization: Auspex Systems, Santa Clara

>On a machine I admin in Greece, we use the ELOT928 character set to enable
>Greek characters to appear on the screen.  But to allow this to work we
>need to login with telnet -8 or rlogin -8, or (and?) stty pass8, otherwise
>the high bit seems to be stripped....

The characters pass not only through the pseudo-tty driver and "line
discipline" STREAMS module code - which, as I said, do *not* strip
output to 7 bits - but also passes through:

	whatever "telnet" or "rlogin" client software you're using
	(whether it's on a UNIX box, or a DOS box, or an Annex, or
	whatever);

	whatever "telnet" or "rlogin" *server* software is running on
	the machine to which you're logging in;

and *that* software may well be stripping stuff to 7 bits.

Furthermore, as I noted, it's *output* that never gets stripped to 7
bits by the tty driver; *input* gets stripped to 7 bits if "istrip" is
set.

Thus, if the "telnet"/"rlogin" client and server software aren't
stripping anything to 7 bits, *printing* a file should work OK with
8-bit character sets, regardless of whether you've done "stty pass8" or
not, as long as your output device (terminal, window system terminal
emulator window, whatever) properly handles 8-bit character sets.

However, unless you've arranged that "istrip" isn't set (e.g., by doing
"stty pass8", which, among other things, turns "istrip" off), *typing*
8-bit characters at the machine won't necessarily work.
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: A few UNIX questions
Date: 28 Aug 92 01:15:13 GMT
Organization: Auspex Systems, Santa Clara

>That's why SVR4 expanded stat to return a generic stat structure
>with provisions for reporting file size (in blocks), block size,
>and offset to last byte.

Actually, the "block size", "st_blksize", isn't supposed to be the size
of the blocks that are the units of the file size; it's supposed to be
"a hint as to the 'best' unit size for I/O operations," to quote my SVR4
manuals.  (Yes, that's the same thing "st_blksize" is in BSD.  Yes,
that's whence SVR4 got it, via SunOS.)

"st_blocks", the file size in blocks, is, to quote my SVR4 manuals, "the
total number of physical blocks of size 512 bytes actually allocated on
disk"; this is intended to include file system overhead such as indirect
blocks.  (Yes, that's the same thing "st_blocks" is in BSD.  Yes, that's
whence SVR4 got it, via SunOS.)

Yes, the comment on the "st_blocks" field in the description of the
contents of "struct stat", at least in the SVR4 manuals I have, is
wrong; it lies and claims that "st_blocks" is in units of
"st_blksize"-size blocks.  That's bogus.  (Yes, there may well be UNIX
systems in which "st_blocks" is in units of "st_blksize"-size blocks. 
"st_blocks", in those UNIX systems, is bogus, and the vendors of those
systems should go fix them ASAP.)
Xref: sparky comp.unix.wizards:3783 comp.unix.programmer:4531 comp.unix.internals:1767