HDTenEightyP/NetNews huggingface dataset:
From: sms@WLV.IIPO.GTEGSC.COM (Steven M. Schultz)
Subject: tftp symbol clash with resolver routines (#79)
Organization: GTE Government Systems
Date: Thu, 10 Sep 92 03:56:19 GMT

Subject: tftp symbol clash with resolver routines (#79)
Index:	ucb/tftp/main.c 2.11BSD

Description:
	The symbol 'connected' conflicts with the external routine "connect(2)"
	called by the resolver routines.

Repeat-By:
	Build 'tftp' with the resolver routines rather than the host file
	routines.  Observe the crash as the first call to 'connect(2)' goes
	to 'connected's address instead.

Fix:
	Apply the following patch and recompile/install 'tftp'.

	Yes, i _know_ the correct solution is longer names in the compiler,
	assembler, linker, archiver, etc, etc.  For now this will have to do.

=======================================cut here================================
*** /usr/src/ucb/tftp/main.c.old	Wed May 15 21:08:00 1991
--- /usr/src/ucb/tftp/main.c	Wed Sep  9 10:22:44 1992
***************
*** 52,57 ****
--- 52,60 ----
  short   port;
  int	trace;
  int	verbose;
+ #ifdef	pdp11
+ #define	connected Xconnected
+ #endif
  int	connected;
  char	mode[32];
  char	line[200];
Newsgroups: comp.bugs.4bsd
From: luik@isa.de (Andreas Luik)
Subject: is rdist security patch integrated in Net/2 release?
Organization: ISA Gmbh, Stuttgart, FRG
Date: Fri, 11 Sep 1992 16:22:16 GMT


Sun distributes a security patch for rdist with the following
description:
    
    Patch-ID# 100383-04
    Keywords:  security rdist setuid client remote distfile
    Synopsis: SunOS 4.0.3;4.1;4.1.1;4.1.2: rdist security enhancement
    Date: 05-Feb-92
     
    SunOS release: 4.0.3, 4.1, 4.1.1, 4.1.2
     
    Topic: rdist security enhancement
     
    Problem Description:  /usr/ucb/rdist under some conditions can be forced
			  to create setuid root programs thus causing a 
			  security problem


I assume that this bug originates from a BSD release? Is this bug
fixed in the BSD4.3 Net/2 release? If not, is a patch available?

Thanks,
-- 
Andreas Luik                E-Mail: luik@isa.de
(postmaster@isa.de)         UUCP:   ...!{uunet!unido,pyramid}!isaak!luik
Newsgroups: comp.bugs.4bsd
From: julian@tfs.com (Julian Elischer)
Subject: fsync bug on indirect blocks (probably known) got a fix?
Organization: Trw Financial Systems
Date: Tue, 15 Sep 1992 23:34:20 GMT

systems: all 4.3 systems (including ISI and MACH) that I have seen.

This has got to be a known bug.
I'm wondering if there is a known fix for it?

fsync in the ufs works in 2 different ways depending on the size of the file:

if it is < 1/2 of the size of the buffercache, it walks along the file
and checks if each block is in the cache, and if it is, and dirty, it
writes it to disk.

If the file is greated than 1/2 of the size of the buffer cache, it simply
examines every block in the buffer cache to see if it belongs to
that file, and if it does, it flushes it. (if dirty)

The problem occurs when the file is > N where N is the maximum size of a file
that can be stored without using the indirect blocks in the inode, 
If it is less than 1/2 the buffer cache, but greater than N in length, then
while all the DATA blocks get written out, dirty INDIRECTION blocks
are left until the next sync() before they are written out.

result: if there is a growing file, > 10 blocks long, but less than
1/2 the buffer cache in size, a crash will result in a file in which
the indirection blocks have not been written out correctly, making the 
file corrupt. If you are checkpointing with a log file, and using fsync,
Your checkpoints become useless as soon as the 10 direct blocks are used up.


I can't believe we are the first to see this, and I think it has been fixed
in the net2 release by the new dirty linked list associated with mountpoints and
file inodes, but does anybody know of a fix in 4.3 systems with the old
style of buffer management.?

julian
+----------------------------------+       ______ _  __
|   __--_|\  Julian Elischer       |       \     U \/ / On assignment
|  /       \ julian@tfs.com        +------>x   USA    \ in a very strange
| (   OZ    ) 2118 Milvia st. Berkeley CA. \___   ___ | country !
+- X_.---._/  USA+(510) 704-3137(wk)           \_/   \\            
          v


Newsgroups: comp.bugs.4bsd
From: raeburn@athena.mit.edu (Ken Raeburn)
Subject: Re: syslogd problem
Organization: Cygnus Support, Cambridge MA
Date: Sat, 12 Sep 1992 02:55:14 GMT

In article <1992Sep8.144857.22346@awdprime.austin.ibm.com> eric@austin.ibm.com (Eric Carpenter) writes:

   If machineA has the following syslog.conf file:

   user.alert	/tmp/alert
   user.info	/tmp/info

... so an alert-level message gets logged to both files ...

   user.alert	@machineB
   user.info	@machineB

... and gets sent twice to machine B ...

   and machineB has the following syslog.conf file:

   user.info	/tmp/info
   user.alert	/tmp/alert

... so each copy gets logged to both files ...

   Then when machineA does a syslog of an alert priority, 2 alert entries
   are put in the /tmp/alert file of machineB.  Shouldn't there only be 1?
   There is also 2 entries in the /tmp/info file of machineB, but this I 
   can understand (one for the alert and one for the info).  When I comment 
   out the .info entries from machineA's syslog.conf file, the problem goes 
   away.

Right.  I think you'll get the "right" results by commenting out just
the "user.alert @machineB" entry alone on machineA.  Then all messages
of level "info" or above (including "alert") will be sent to machineB
once, there logged to the appropriate file(s) as determined by the
syslog.conf file there.

~ Ken Raeburn		work: raeburn@cygnus.com	play: raeburn@mit.edu ~
~ Cygnus Support, One Kendall Square, Cambridge MA 02139 USA  ~ 617-494-1040  ~
--
~ Ken Raeburn		work: raeburn@cygnus.com	play: raeburn@mit.edu ~
~ Cygnus Support, One Kendall Square, Cambridge MA 02139 USA ~  617-494-1040  ~
From: eric@austin.ibm.com (Eric Carpenter)
Newsgroups: comp.bugs.4bsd
Subject: syslogd problem
Date: 8 Sep 92 14:48:57 GMT
Reply-To: eric@thelake.austin.ibm.com
Organization: IBM Austin
Originator: eric@thelake.austin.ibm.com


Can anyone give me some insight into this situation?

If machineA has the following syslog.conf file:

user.alert	/tmp/alert
user.info	/tmp/info
user.alert	@machineB
user.info	@machineB

and machineB has the following syslog.conf file:

user.info	/tmp/info
user.alert	/tmp/alert

Then when machineA does a syslog of an alert priority, 2 alert entries
are put in the /tmp/alert file of machineB.  Shouldn't there only be 1?
There is also 2 entries in the /tmp/info file of machineB, but this I 
can understand (one for the alert and one for the info).  When I comment 
out the .info entries from machineA's syslog.conf file, the problem goes 
away.

user.alert	/tmp/alert
#user.info	/tmp/info
user.alert	@machineB
#user.info	@machineB

The same thing occurs on every platform that I tried it on.

Thanks for any help..

   


-- 
 ___________________________________________________________________
| Eric Carpenter              | inet:   eric@thelake.austin.ibm.com |  
| PSP, Austin                 | vnet:   ECARP at AUSTIN             |
| Dept. D54 3b-17/905         | phone:  (512)838-3277  -- T/L 678   |
From: dom@dsbc.icl.co.uk (Dominic Alston)
Newsgroups: comp.bugs.sys5
Subject: CURSES: libpanel bug with libpanel
Keywords: libpanel,curses
Date: 7 Sep 92 17:05:40 GMT
Organization: ICL, Bracknell, Berkshire, RG12 4SN, UK

PANEL's with derived windows does not work with 3 panels active.

libpanel does not cope with derived windows properly.
If you create 3 PANELs, one of them containing a 
derived WINDOW, libpanel seems to think parts of the
derived WINDOW need refreshing on a update_panels()
call. 

This appears to be a problem with all System V libpanels. (SVR3.2 SVR4.0,..)

The following code demonstrates this problem.

Compile and run the following program (cc bug.c -lpanel -lcurses -o bug)
Once run, use the arrow keys to move the first window.
You will then notice that the bottom window (the PANEL with the derived
WINDOW) seems to get refreshed wrongly.

#include <curses.h>
#include <panel.h>

int main(void)
{
 PANEL *p1,*p2,*p3;
 WINDOW *a_wn;
 int x=11,y=11,c,lx,ly;

 initscr();
 noecho(); cbreak(); keypad(stdscr,1);
 a_wn = newwin(0,0,0,0);
 p1 = new_panel(derwin(a_wn,10,40,10,10));
 p2 = new_panel(newwin(10,40,11,11));
 p3 = new_panel(newwin(10,40,12,12));
 for (ly=0; ly < getmaxy(a_wn); ly++)
  for (lx=0; lx < getmaxx(a_wn); lx++)
   mvwaddch(a_wn,ly,lx,'%');
 box(panel_window(p1),0,0);
 box(panel_window(p2),0,0);
 box(panel_window(p3),0,0);
 update_panels();
 doupdate();
 while ((c = getch()) != '\033') {
  switch (c) {
   case KEY_UP: y--; break;
   case KEY_DOWN: y++; break;
   case KEY_LEFT: x--; break;
   case KEY_RIGHT: x++; break;
  }
  move_panel(p3,y,x);
  update_panels();
  doupdate();
 }
 endwin();
 return (0);
}


I have an application that relies heavily on the use of derived windows,
can anyone suggest a solution ???

If anyone has a rewritten libpanel library, that has the same optimisation
that libplanel gives, then please send it to me!!


--
Dominic Alston
International Computers Ltd.               
Lovelace Road.                              dom@oasis.icl.co.uk ||
Bracknell RG12 4SN                          ..!uunet!mcvax!ukc!stc!iclbra!dom ||
Berks, England.                             da16@unix.brighton.ac.uk ||
                                            da16@vms.brighton.ac.uk
Tel: +44 344 424842 x3695 
Fax: +44 344 487832

Disclaimer: class myDisclaimer : public stdDisclaimer {
		myDisclaimer() : stdDisclaimer() { }
	}
From: andys@flatline.sbi.com (Andy Sherman)
Newsgroups: comp.bugs.sys5
Subject: Packaging Tools Woes
Summary: does compver *ever* get checked
Date: 4 Sep 92 19:05:09 GMT
Organization: Salomon Inc

I am trying to get the "compver" file in the software packaging tools
to work.  I've checked several versions, including the SVr4 version
that comes with Solaris 2.0 (SunOS 5.0).

Here's the situation:

Package <foo1> version 1.1 is installed.  It has a "compver"
file containing the lines

1.1
1.0

According to TFM, this says that version 1.1 should satisfy
dependencies in packages looking for version 1.0.

Package <foo2> has in its depend file

P foo1 Foo1 package description
	(sun4)1.0

When I go to install foo2, it still complains that it needs <foo1>
version 1.0.

Any ideas?  It seems to me there is a bug in either TFTools or TFM.
--
Andy Sherman
Salomon Inc  -  Unix Systems Support  -  Rutherford, NJ
(201) 896-7018  -  andys@flatline.sbi.com or asherman@mhnj.sbi.com
"These opinions are mine, all *MINE*.  My employer can't have them."
Newsgroups: comp.realtime
From: faught@berserk.ssc.gov (Ed Faught)
Newsgroups: comp.realtime
Subject: Re: bash on LynxOS ?
Date: 14 Sep 92 17:40:58 GMT
Reply-To: faught@berserk.ssc.gov
Organization: Superconducting Super Collider Laboratory

In article <1992Sep14.084537.130673@rrz.uni-koeln.de> rw@IKP.Uni-Koeln.DE (Ralf  
Wirowski) writes:
>Has someone ported the bash with full job-control to LynxOS ?
>In my opinion, only the jobs.c file must be adapted.

bash was included in the 2.1 beta release, but it's broken. tcsh works, though.
--
Ed Faught  WA9WDM  faught@berserk.ssc.gov
 Superconducting Super Collider Laboratory
Newsgroups: comp.realtime
From: vera@ready.ops.ready.com (Vera Dunlap)
Subject: Breakfast/lunch invitation
Organization: Ready Systems
Distribution: usa
Date: Mon, 14 Sep 92 21:49:27 GMT

For the first time Ready Systems is presenting publicly Spectra, and
VRTX/OS 3.0, its new Software backplane and runtime environment.

Please RSVP by calling 800 321-2636 if you are interested in
attending either of the following presentations.

* Breakfast at Buscon 92-East
  Hynes Convention Center, Boston, Mass.
  Wednesday, September 16, 7:30 a.m. to 8:45 a.m.

           or

* Lunch at Embedded Systems Conference
  Santa Clara Convention Center, Santa Clara, CA.
  Wednesday, September 23, 12:00 p.m. to 1:15 p.m.

If you have any problems in reaching the 800 number,
or would like to talk to me, please call 408 522-7325.

Thank you,
Vera Dunlap

-- 
Glenn Kasten
Ready Systems 470 Potrero Ave. Sunnyvale CA 94086 
glenn@ready.com (408) 522-7357
From: kang@saul.cis.upenn.edu (Inhye Kang)
Newsgroups: comp.realtime
Subject: Euro Micro Workshop on Realtime?
Date: 8 Sep 92 18:38:37 GMT
Organization: University of Pennsylvania

Hello, I'd like to know the due date of submission for 
"Euro Micro Workshop on Realtime". If anyone knows,
please email me. 
Thank you very much,
Inhye Kang (kang@saul.cis.upenn.edu)

Newsgroups: comp.realtime
From: eepjm@wombat.newcastle.edu.au (Peter Moylan)
Subject: Re: Where to stick the watchdog ?
Organization: University of Newcastle, AUSTRALIA
Date: Tue, 8 Sep 1992 01:11:39 GMT

In article <1992Sep03.034229.13095@crs-sys.uucp>, crs@crs-sys.uucp (Chris Gregors) writes:
> Recently I had an argument (discussion) with some co-workers regarding where
> is an appropriate place to kick a watchdog timer inside an application program.
> 
> Their side was 'stick it in the lowest level routine in a non-kernal based
> application, or stick it in the null task in a real-time kernal.'

My own experiences have left me wondering whether a watchdog is ever
worth using.  As one might have predicted from Murphy's law, the usual
failure mode seems to be that one or more tasks misbehave, but the
watchdog-kicker never crashes.

In particular, the null task tends to be the most stable task in the
entire system.  Everything else can fall in a heap, and the null task
merrily keeps running.

One solution I like, but which is rather complicated, is as follows.
Choose a low-level, high-priority, periodic task as the one which
kicks the watchdog, but also adopt the rule that every other task in
the system - or, at least, every periodic task - must periodically
kick the watchdog-kicker.  The watchdog-kicker can keep an array of
flags showing who has kicked it lately, and it should refrain from
kicking the watchdog if any of these flags is not set.

Still, I've never bothered to implement this approach.  When you get
right down to it, the only thing a watchdog is good for is watching
the integrity of the OS scheduler; and that's not such an important
thing to watch, because:
 (a) the OS kernel tends to be the most-exercised part of the software,
     so it's the least likely place for bugs to appear.
 (b) if there really are problems in the kernel, then you'd better get
     in and fix them rather than rely on an automatic re-boot, because
     otherwise those problems will come back to plague you in a whole
     variety of ways.
This assumes that the main job of the watchdog is to handle rare
conditions which expose software bugs.  I know that most people think
of watchdogs as things to look out for hardware bugs, but in practice
the hardware is likely to be far more reliable than the software.
In any case, hardware problems are just as likely to be caused by
the watchdog circuitry itself (Murphy's law again).

-- 
Peter Moylan                      eepjm@wombat.newcastle.edu.au
From: salerno@ast.dsd.northrop.com (Peter Salerno)
Newsgroups: comp.realtime
Subject: Re: VxWorks vs. pSOS
Date: 4 Sep 92 18:04:30 GMT
Distribution: na
Organization: Northrop Corp - ESD, Rolling Meadows, IL

In article <ddjn5sa.dbander@netcom.com> dbander@netcom.com (David B. Andersen) writes:
>I have extensive experience using both pSOS and VxWorks, however not on the
>same archetectures.  I have used pSOS on Intel X86 based systems, and VxWorks
>on Moto 680X0 systems.
>...development environment for VxWorks is very familiar to Unix developers,
>whereas pSOS seems to have an MS-DOS based development heritage.
>But the think I like best of all about VxWorks is the shell!  This is so useful
>for testing and debugging that you will wonder how you ever got along
>without it.  It puts pROBE (the pSOS debugger) to shame.
  I am currently using pSOS for the 88K and have seen the 68K devel.
environment for pSOS development. I saw nothing MS-DOSy about it. Maybe
your pSOS devel. platform was an MS_DOS machine and not a UNIX box like
a Sun. And maybe it appeared close to MS-DOS because of the processor.
  I also use the XRAY+ debugger which overlays pROBE. XRAY provides more
functionality than any other debugger I have seen. It is parsects beyond
the VAX debugger.
  We chose pSOS after looking at VxWorks, VRTX, M-TOS, OS-9, and others
I forgot. 

  This are just my opinions. 
#include "std_disclaimer"
                               pete
From: dkb@doc.ic.ac.uk (D K Bannister)
Newsgroups: comp.realtime
Subject: Real Time Operating Systems on PC's
Date: 9 Sep 92 12:09:25 GMT
Organization: Department of Computing, Imperial College, University of London, UK.
NNTP-Posting-Host: swan.doc.ic.ac.uk

We are in the process of revamping our real time laboratory and would
welcome comments from any educational institute that has experience of
running PC based real time operating systems such as FlexOS, iRMX111,
pSos+ etc. Any suggestions as to suppliers of suitable equipment to con-
trol would also be appreciated.

Please email me direct at:	dkb@doc.ic.ac.uk

Thanks in advance

Dave 

+-------------------------------------------------------------+
| David Bannister                                             | 
| Dept of Computing,            Phone: +44 71 589 5111  x7539 |
| Imperial College,             Fax:   +44 71 581 8024        |
| 180 Queen's Gate,             Email: dkb@doc.ic.ac.uk       |
| London, SW7 2BZ, UK.                                        |
+-------------------------------------------------------------+
From: bdl@cruiser.uucp (Bob Lombard)
Newsgroups: comp.realtime
Subject: Re: Booting dos from ROM
Keywords: DOS ROM BOOT
Date: Sat, 05 Sep 92 08:20:41 PDT
Distribution: usa
Organization: what? me organized? no way!

hansen@deci.cs.umn.edu (David M. Hansen) writes:

> In article <peter.715502243@citr.uq.oz.au>, peter@citr.uq.oz.au (Peter Klavin

> |> cole@noao.edu (Lonnie Cole) writes:
> |> >Does anyone know of instructions and or source in the public domain to
> |> >allow booting dos from a battery backed RAM disk or ROM disk. Any
> |> >pointers to code or docs would be greatly appreciated.
 
> I know of two companies which provide customizable BIOS's which could be
> used in embedded systems.  Unfortunately, I don't have their addresses or
> phone numbers handy.
> 
> One source is Annabooks.  Their phone number was posted in this group a coupl
> weeks ago.

Annabooks phone # is: 800-462-1042 or 619-673-0870
                                                
> The other is General Software (I think... I hope...).  The latest issue of
> Embedded Systems Programming plugs their new BIOS.  This same company also 
> sells a re-entrant embeddable DOS clone.

General Software # is : 206-391-4285

A company called Datalight also sells a Rom-Dos compatible with MSDOS 3.31
their number is: 800-221-6630 or 206-435-8086
 
> Disclaimer: I haven't used any of this stuff, so I don't really know how good
> it is, let alone features and limitations.

Neither have I, its just from my files.  anyone else ??

 
> Hope this helps.
> 
> 						-=Dave

Me too.  Good Luck !



*****************************************************************
* Bob Lombard ||  bdl@cruiser.uucp  || 418 Village Center Drive *
*             ||                    || Encinitas, Ca. 92024     *
*  |~~|_                                                        *
*  |    :           "If it ain't green and it ain't old,        *
*  '0-0-''..../\..   .. it ain't my truck                       *
*****************************************************************
From: dhd@exnet.co.uk (Damon)
Newsgroups: comp.realtime
Subject: Re: Where to stick the watchdog ?
Date: 11 Sep 92 17:21:50 GMT
Organization: ExNet Systems Ltd Public Access News, London, UK

In article <Bu9two.2DA@hatch.socal.com> mike@hatch.socal.com (Mike Bernadett) writes:
>In article <1992Sep8.111139.1@wombat.newcastle.edu.au> eepjm@wombat.newcastle.edu.au (Peter Moylan) writes:
>>My own experiences have left me wondering whether a watchdog is ever
>>worth using.  As one might have predicted from Murphy's law, the usual
>>failure mode seems to be that one or more tasks misbehave, but the
>>watchdog-kicker never crashes.
>>
>>In particular, the null task tends to be the most stable task in the
>>entire system.  Everything else can fall in a heap, and the null task
>>merrily keeps running.
>>
>>One solution I like, but which is rather complicated, is as follows.
>>Choose a low-level, high-priority, periodic task as the one which
>>kicks the watchdog, but also adopt the rule that every other task in
>>the system - or, at least, every periodic task - must periodically
>>kick the watchdog-kicker.  The watchdog-kicker can keep an array of
>>flags showing who has kicked it lately, and it should refrain from
>>kicking the watchdog if any of these flags is not set.
>>
>
>We are taking the above approach and adding a little more complexity
>at the task level.  The watchdog kicker is periodic at a high
>priority and keeps an array of flags (timestamps) of who's kicked
>it lately.  The added complexity is that the kicker
>actively solicits (via message queue) those kicks from every task in
>the system periodically, and has a worst case response time defined
>for every task.  If the kick from a task doesn't come back within
>its assigned response time, that task is warm-started.
>
>So the kicker evolves into a 'task management' executive task.
>This task-by-task monitoring lets the system continue in a degraded
>mode if a non-critical task dies.  When the task that died is
>warm-started (immediately), it will dump its previous
>data area to non-volatile media and stand by idly.  By default we'll
>assume this task is now useless, but an override command could put
>it back in service, whereby it would re-initialize its data area,
>listen to the control message stream for a 'synchronizing' type of 
>message, and sync up with the rest of the system.

Hmm.  Sounds like you add a whole lot more bugs to the s/w this way.

When I wrote my 2K real-time robotics OS, every process that did not
explicitly reset its timer within 2.55 secconds (clue there) got sent a
wakeup message (well, actually a normal timer message).  Saved us on
more than one occasion I believe where some complex bit of code managed
to drop its thread deep in some string of message-passing activity...

Damon
-- 
Damon Hart-Davis | Tel/Fax: +44 81 755 0077 |1.24|| Cheap Sun eqpt available.
Internet: dhd@exnet.co.uk | Also: Damon@ed.ac.uk || US high-perf motor groups.
--------------------------+----------------------++ >12 mail&news polls / day.
Public access UNIX (Suns), news and mail for #5 per month.  FIRST MONTH FREE.
Newsgroups: comp.realtime