HDTenEightyP/NetNews huggingface dataset:
From: mayfield@saffron.cs.ucdavis.edu (Doug Mayfield)
Newsgroups: comp.os.linux
Subject: Problem with strip?!?!?
Date: 10 Sep 92 21:27:51 GMT
Organization: Department of Computer Science, University of California, Davis

What is the problem with the `strip` utility that some people keep
talking about???  I have had some problems with it also and was
wondering if they were the same.

Doug M.

------------------------------------------------------------
Douglas B. Mayfield
mayfield@cs.ucdavis.edu
   	(Computer Science Dept.)
   	(University of California at Davis)
Newsgroups: comp.os.linux
From: klode@syslab.csd.uwo.ca (Claude Morin)
Subject: Re: offered for your approval
Organization: Department of Computer Science, University of Western Ontario, London
Date: Sat, 12 Sep 1992 00:07:36 GMT
Keywords: review

Quick question: is anyone working on EISA or MicroChannel support?  I have a
hazy idea, but I don't wish to mislead our readers.

Thanks.
---
Claude Morin
(that's "klode", NOT "clod"...French :-)
London, Ontario, Canada
Newsgroups: comp.os.linux
From: david@prism.demon.co.uk (David Metcalfe)
ReplyTo: david@prism.demon.co.uk
Subject: Re: 0.97pl4 breaks SCSI extended partition code
Distribution: world
X-Mailer: cppnews $Revision: 1.15 $
Organization: ** none **
Date: Thu, 10 Sep 1992 19:43:03 +0000


In article <3555@ra.nrl.navy.mil> eric@tantalus.dell.com (Eric Youngdale) writes:

> 	OK, I think I see what the problem is, and why this is not working.
> I suggest the following patch.  I already gave this patch to Chris Newbold,
> and it looks correct enough for me to release to the public.
> 
> 	Basically this corrects a problem where linux has difficulty reading
> the partition table for an extended partition.  If you are not having this
> problem, I do not see much point in trying this.
> 
> 	Basically the problem is that the sd_sizes array is normally
> initialized after the partition tables have been read.  Normally
> blk_size[MAJOR] should be 0 until  the sizes array is ready, but for
> scsi disks blk_size[8] was being initialized prematurely, leading to the
> problem in make_request  (As long as blk_size[MAJOR] == 0, testing
> of sd_sizes is inhibited).
> 
> -Eric
> 
 < patch deleted >

I've tried the patch out and it also cures my problem.  It's
interesting that the extended partition could be read first time with
0.97pl2 but not with pl4.  There must have been a small change in the
timing.

David

-----------------------------------------------------
David Metcalfe          david@prism.demon.co.uk     
+44 81 361 3327         dmetcalf@cix.compulink.co.uk
From: mal11@po.CWRU.Edu (Matthew A. Lewis)
Newsgroups: comp.os.linux
Subject: missing libraries for xload, xgames, and xv
Date: 7 Sep 1992 16:50:12 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)
Reply-To: mal11@po.CWRU.Edu (Matthew A. Lewis)
NNTP-Posting-Host: thor.ins.cwru.edu




i grabbed the binaries for the above off of tsx-11 but i was unable
to get any of them working.

When I ran xload, I got an error message:

can't load library '/lib/libc_v2_11c'

and then when trying to make xv and xgames it had a problem with
libX11.a

Are these libraries out-dated or perhaps included in newer library releases?

Thanx in advance.

-- 
MaThiEu a. LeWis      "There is no middle ground/Or that's how it seems/For 
Thieves Like Us        us to walk or to take/Instead we tumble down/Either
mal11@po.cwru.edu      side left or right/To love or to hate."
					-A Strange Kind of Love
From: tytso@athena.mit.edu (Theodore Y. Ts'o)
Newsgroups: comp.os.linux
Subject: Re: 57.6Kbps under Linux -- some results...
Date: 12 Sep 92 16:54:59 GMT
Organization: Massachusetts Institute of Technology

In article <!nwn!6h.harp@netcom.com> harp@netcom.com (Gregory O. Harp) writes:

   First, I had to hack the kernel serial code to handle that speed.
   Linux currently only supports 38.4Kbps as "shipped."  

I've been working on a heavily revised version of the serial driver,
that supports more boards (including the AST FourPort boards) as well
some other neat features.  One of the neat features is a way 
to control what speed "38400" baud means when you specify it
to the kernel, using setserial.  You can set it to mean 38400, 57600,
115200, or "custom divsor".  With custom divisor, you basically get to
specify "div" in the equation 

			baud = 1843200 / (div * 16)

I'll be shipping my new serial driver to Linus soon, so look for it in a
Linux release near you.  Some of the other fixes which should be popular
is that I've managed to use over 100k less memory in the tty drivers,
which means 100k more memory for user programs.  I figure that should be
nice for people who have 2 or 4 meg machines.  :-)

   BTW, the reason I keep saying 16550A and not just 16550 is because a
   glance at the code tells me that Linux is only enabling the FIFO if
   the UART is the 16550A (refer to lines 265-272 of serial.c).  Linus,
   can you tell us why you don't use the FIFO on the 16550?  I've
   personally never used the FIFO because my projects were for 16450
   UARTs, but I'm not aware of any problems.

The initial version of the 16550 which were shipped by National
Semiconductor had a bug, so that their FIFO's where *not* reliable.  The
spec sheets from National specific state that if you have a 16550, you
should not attempt to use the FIFO's.  Fortunately, relatively few
16550's were actually shipped before the problem was discovered, and
most of those ended up in PS/2's.  These days, when people talk about
16550's, they generally mean recent versions of the chips that have the
working FIFO's.  These chips will be labelled: "NS16550A", "NS16550AF",
"PC16550C", or "PC16550CF", (apparently PC16550CF is the most recent
chip version; although I've been assured by National Semiconductor that
most of the bugs which were fixed in the PC16550CF's shouldn't give me
any trouble if I only have a NS16550A).

In any case, because the original 16550's had such a serious bug,
National thoughtfully gave us a software way of detecting whether or not
the chip was one of the chips with the FIFO bug, or not.  All of the
more recent chips will ID themselves as a 16550A; it is only the
original buggy chips that will ID themselves as a 16550.

You generally don't need to worry about this.  Although it might be
prudent to check a serial board that you're thinking about to see
whether it has one of the newer chips, it is very unlikely that if you
were buying a serial board that you would actually run into one that had
one of the original 16550 chips.

							- Ted
Newsgroups: comp.os.linux
From: cmenser@nyx.cs.du.edu (Charles Menser)
Subject: Feeling good about it (Was Re: Progress report?)
X-Disclaimer: Nyx is a public access Unix system run by the University
	of Denver for the Denver community.  The University has neither
	control over nor responsibility for the opinions of users.
Organization: Nyx, Public Access Unix at U. of Denver Math/CS dept.
Date: Mon, 7 Sep 92 21:20:31 GMT

Let me get this straight... :) :) :)

The Linux system is not yet at rev 1.0, BUT it has X, suppport for 3(+ ?) FSs
[minix, efs, DOS, CD?], fantastic mm, DOS (only ;) ) emulation, etc. etc...

Linus feels good about the kernel...

Hey, life is good!

KUDOS Linus!

Cheers everyone,
Charles
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Charles D. Menser               !  "... and even if you choose not to decide,
cmenser@vyonous.kennesaw.edu    !           you still have made a choice."
From: eoakes@ruacad.ac.runet.edu (Ed Oakes)
Newsgroups: comp.os.linux
Subject: Data Technology DTC3180 SCSI Controller (Will it work)
Date: 3 Sep 92 23:21:51 GMT
Organization: Radford University

I guess the subject about sums it up.  

I am trying to help a friend install Linux on his new 486.  He was told he
was getting an Adaptec board, but it showed up with a DTC instead.  Is 
there any way to get this thing to work, or should he send it back and 
demand an Adaptec? 

Any comments would be appreciated.
-- 
##############################-----------------------------------------------
#  Ed Oakes                  #        Phone   (703) 831-6238
#  Radford University        #        Office  McConnell G-15
#  Academic Computing        #        email   eoakes@ruacad.ac.runet.edu
From: badger@phylo.life.uiuc.edu (Jonathan Badger)
Newsgroups: comp.os.linux
Subject: MicroGnu "Terminal too stupid" Error
Keywords: Micrognu Error mg
Date: 12 Sep 92 01:50:35 GMT
Organization: University of Illinois at Urbana

I've just installed the (excellent, by the way) MCC Interm Release of Linux
version 0.97p2. Unfortunately this now causes my copy of mg to abort when
started, claiming that "my terminal is too stupid" to run Micrognu. Any
ideas?

Jonathan Badger
From: youki@rd.ecip.osaka-u.ac.jp (Youki Kadobayashi)
Newsgroups: comp.os.linux
Subject: cross compiling from Sun?
Date: 5 Sep 92 23:22:46 GMT
Distribution: comp
Organization: R&D, Edu Center for Info Processing, Japan


Have anybody succeeded to build cross-compiler for Linux, on Sun or
MIPS?

--
			Youki Kadobayashi <youki@rd.ecip.osaka-u.ac.jp>
			Information Network Architecture Lab.
			Department of Information and Computer Sciences
			Osaka University, Japan
From: card@masi.ibp.fr (Remy CARD)
Newsgroups: comp.os.linux
Subject: Re: GNU shell utils 1.7: date(1) dumps core (with easy solution:)
Date: 7 Sep 92 13:09:42 GMT
Organization: Laboratoire MASI - Universite Pierre et Marie Curie - Paris - France

In article <147770001@hplsla.hp.com> ericb@hplsla.hp.com (Eric Backus) writes:
>>	In fact, the fix to configure is pretty small.  configure tries
>>to compile a program defining 'extern char **tzname' and gcc complains
>>because tzname is declared as 'extern char *tzname[]' so configure assumes
>>that tzname does not exist in Linux.
>>
>>	You can apply this patch to correct configure :
>
>
>I hope you mailed a copy of this patch to the FSF so next time it
>won't be a problem.

	Ooops !  I didn't...  I will send this patch to FSF now (in fact,
not really this patch since configure is automatically generated by autoconf,
but a patch for autoconf 1.1).

>--
>				Eric Backus
>				ericb@hplsla.hp.com


--

	Remy Card
	card@masi.ibp.fr
Newsgroups: comp.os.linux
From: genie@netcom.com (The Genie)
Subject: X386 and Serial Logitech mouse
Date: Tue, 08 Sep 92 05:06:47 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 


Hi.

I've installed X11v1.1 into my Linux .97p4 system.  I've
also got the troublesome Logitech Serial C7 mouse, that
moves the cursor irradically around the screen.

I think someone actually made a fix for this, or solved
this problem?  I remember reading it a while back, yet
didn't pay much attention to it since I didn't have X
installed?  Can someone who found the cure send me some
mail regarding this?  Thanks ina advance.

Gene
Xref: sparky comp.os.linux:10547 comp.unix.bsd:5595
From: eric@tantalus.dell.com (Eric Youngdale)
Newsgroups: comp.os.linux,comp.unix.bsd
Subject: Re: Shared libraries - info for 386BSD porting wanted
Keywords: shared 386bsd
Date: 12 Sep 92 13:22:17 GMT
Organization: Naval Research Laboratory

In article <veit.716293407@du9ds3> veit@du9ds3.uni-duisburg.de writes:
>Another thread has been just started about that. Don't look at the Linux
>sources, the type of implementation is for a hacker's OS ;-), but not for the 
>future. Linux uses (as most SysV systems) fixed addresses for shared 
>libraries, which is, with one simple word *unacceptable*.

	Huh? Let me see, BSD does not have shared libraries, and Linux, like
SysV uses fixed addresses...  Exactly what OS does have acceptable sharable
libraries?   When you say "unacceptable", it almost sounds like you will
refuse to use them under linux.  Is this really the case?

	Now that the user address space has been increased to 3 Gb, what
possible difference could it make to you whether the shared library has
fixed addresses or not?  The only drawback that I know of is that some
minor deity needs to decide which libraries get what addresses.  

--
Eric Youngdale
eric@tantalus.nrl.navy.mil
Newsgroups: comp.os.linux
From: pdc@temple.demon.co.uk.demon.co.uk (Piers Cawley)
Distribution: world
Subject: Can't get 0.97pl3 to boot
X-Mailer: cppnews $Revision: 1.14 $
Organization: NoOrg
Date: Sun, 6 Sep 1992 21:45:11 +0000

First, the usual thanks to Linus and all the people involved in getting
Linux this far.

But: I just pulled the new 0.97pl3 sources down from nic.funet.fi, hacked
keyboard.c so that # and @ are in the right place and compiled. Thus far, no
problems. However, when I copied /usr/src/linux/Image to /etc, did the rdev
incantation over it and rebooted, I got the following message:

linux version 0.97pl3-1 (root@Iest)09/06/92 20:53:22
general protection: 0000
EIP: 0008:0000DA25
EFLAGS: 00010006
fs: 0017
pid: 3, process nr: 3
39 78 04 74 06 83 78 04 00 75

BTW, I compiled the kernel using gcc 2.2.2d from the mcc-interim set (which I
can't recommend highly enough).


+-----------------------------+------------------------------+
|Piers Cawley                 |  You think you're the last   |
|pdcawley@cix.compulink.co.uk |  word on everything Ibid.    |
|pdc@temple.demon.co.uk       |       -Small Gods            |
+------------------------------------------------------------+
From: steve@Nyongwa.CAM.ORG (Steve M. Robbins)
Newsgroups: comp.os.linux
Subject: Re: High Speed Modems and getty
Keywords: getty, modems, SIGHUP, IOCTL
Date: 14 Sep 92 03:03:56 GMT
Organization: Chiral Symmetry Breaking, Inc.

In article <-qwn96l.james@netcom.com> james@netcom.com (James L. Paul) writes:
>I'm using 0.97.2 and uugetty from the getty_ps203 package. I've never
>turned on the debugging, and it answers the ring fine, and sets speeds
>properly. However, I'm still struggling with 2 problems...
[ ... ]
>3. Now, a final tack-on question...
>
>   Where is an accurate source of IOCTL info, so I can examine all the
>   possible flags for my /etc/gettydefs? I suspect some of my problems
>   might be fixable with flags, but have been unable to find the right
>   set of man pages. (For example, I have no idea what CLOCAL does, but
>   removing it from the first entry half-solved a problem! Perhaps adding
>   some flag may solve the other half! ;)

The manpage for stty is pretty good.  
(It comes with stty.c in the GNU shellutils package)
-- 
Steve Robbins  --  steve@nyongwa.cam.org
He had a lot of tatoos that were covered up in blood.
One said "Make it Whiskey", one said "Elmer Fudd".
Newsgroups: comp.os.linux
From: vince@halcyon.com (Vince Skahan)
Subject: Re: smail3.1.25 (or above) under linux?
Organization: Northwest Nexus Inc. (206) 455-3505
Date: Mon, 14 Sep 1992 19:25:07 GMT

s_baumgn@irau26 (Fred Baumgarten) writes:

>Vincent D. Skahan (vds7789@aw2.fsl.ca.boeing.com) wrote:
>: [...]
>: 
>: Has anybody gotten smail3.1.25 (or above) to compile
>: under linux ? If so, would you be willing to either

>yup - 3.1.25 works - but only up to 0.97pl2 - at 0.97pl4 it cores

nice piece of information...thanks

>: clue me in or kick me the config files for compiling
>: it (and the transport config files for making it work) ?

>humpf - an smail introduction ? would be too hard here...

that's not what I was looking for.

There are linux-isms that need to be identified and dealt with
(maybe a conf/os/linux file and/or a linux-specific EDITME file)
that I was looking to see if anybody had already solved it.

of course, if you *want* to kick all your config files and
a 'here's how it all plays together under linux' document,
I won't say no :-)
-- 
          Vince Skahan				vince@halcyon.com (here)
    vince@atc.boeing.com (work)		    vince@victrola.sea.wa.us (home)

Newsgroups: comp.os.linux
From: trussell@cwis.unomaha.edu (Tim Russell)
Subject: Re: 0.97pl4 breaks SCSI extended partition code
Organization: University of Nebraska at Omaha
Date: Wed, 9 Sep 1992 03:14:54 GMT

ctne_ltd@uhura.cc.rochester.edu (Chris Newbold) writes:

>Maybe Drew would like to look into this as a generic SCSI problem? I don;t
>know how far off the much-awaited version 2 of the SCSI drivers are, but
>maybe this is a quick-fix.

    Tonight I did lots of printk()'ing and #define DEBUG'ing and came up
with the reason my system at least won't read extended partitions.

    The problem is in kernel/blk_drv/ll_rw_block.c, in function make_request().
The chain of execution is: extended_partition() calls bread() with the dev#
of the extended partition, block 0, size 1024.  bread() calls ll_rw_block()
with READ, which calls make_request().

    On about line 155 of ll_rw_block.c (in 0.97pl4 anyway), this if statement
gets executed:

	if (blk_size[major])
	  if (blk_size[major][MINOR(bh->b_dev)] < (sector + count)>>1) {
		bh->b_dirt = bh->b_uptodate = 0;
		return;
	  }

and that's all she wrote, bread ends up falling through to returning an error.

    Being new to Linux kernel hacking, I'm not exactly positive what's going
on here, but it doesn't seem to have anything to do with the SCSI code per
se to me.  I enabled DEBUG in sd.c and never got any messages at all during
the extended_partition processing, so it isn't even getting down to issuing
a request to the SCSI driver, the problem is up in the buffer code.

    Is this code to deal with variable block sizes that was added recently?
That would explain some things.  I'm going to grab plain 0.97 if I can find
it and see, since I believe that's nearly the last version I got to work on
my system.

--
    Tim Russell                 Omaha, NE              trussell@unomaha.edu
One of the richest men in the world made his billions selling a toy "operating
system" that is more accurately described as a glorified bootstrap loader.
                                                  -- Phil Karn
Newsgroups: comp.os.linux
From: jonathan@nova.next.nd.edu (Jonathan Bradshaw)
Subject: Re: thanks for the help...questions regarding getty_ps
Organization: University of Notre Dame, Notre Dame
Date: Fri, 11 Sep 1992 22:59:53 GMT

In article <6087@pdxgate.UUCP> moyerg@rigel.cs.pdx.edu (gary a moyer) writes:
>
>Now I am in the progress of trying to get the getty_ps package to
>work.  The problem:  no connection using either getty (on a virtual
>console) or uugetty (to my modem).  I compiled them with the debug
>mode on and ran using debug mode 0377 (show _all_ debug info).
>Everything appears okay here, but the process just dies.

I installed the GETTY_PS package and have been able to dial in from remote
(2400bps) using UUGETTY and run it for all my ttys. I found that setting the
debug to full on causes dialins to get screwed up. What I found was the other
modem connects at 1200bps instead of 2400bps but uugetty is talking at 2400bps!
I know its wierd but the problem goes away when turning off debug information!
Obviously this is a timing problem.  However, the process has never "died" on
me but the package does work.

--
 Jonathan Bradshaw | jonathan@nova.decio.nd.edu | HAM: N9OXE | Prodigy XMSN02B
  WNDU-AM/FM/TV South Bend, IN | Disclaimer "My opinions are not my employers"
  - "Busy life, not enough time to look in the mirror." - Deborah Ann Gibson -
Newsgroups: comp.os.linux
From: joel@wam.umd.edu (Joel M. Hoffman)
Subject: Progress report?
Organization: University of Maryland, College Park
Date: Mon, 7 Sep 1992 12:53:12 GMT

I've been away for the Summer, and have missed most of c.o.l.  Could
someone who's been following it for the the Summer please let me know
what I've missed.  My last kernel is 0.96.

Specifically, is there a DOS emulator yet?  Have the VM86 patches at
least made it into the standard distribution?  Have my code-page
patches made it into the standard distribution?

My GCC library is marked lib92.04.06.  Is there a new one?  If I get
the new one, do I have to recompile all of my programs?  Do we have
jump-tables yet so that when a newer library comes out programs won't
have to be recompiled?

Is there anything else I would want to know about?

Many thanks.  Please reply by e-mail.  I'll post a summary, as I'm
sure there are many people returning after being away for the Summer.

-Joel
(joel@wam.umd.edu)
From: baron@clifton.hobby.nl (Wim `Blue Baron' van Dorst)
Newsgroups: comp.os.linux
Distribution: world
Subject: Re: problems getting 800x600 out off an ET-4000
Organization: Minix Hobbynet Host
Date: Sun,  6 Sep 1992 21:54:31 MDT

stud07@cc4.kuleuven.ac.be (Dirk Dussart) writes:
>   I'm having serious trouble getting 800x600 ( or any other SVGA resolution )
> out off my Tseng Labs ET-4000. 

I have a Tseng Labs ET4000, and and EMC 14'' monitor. It is very small, so
I prefer the 640x480 size, which is perfect. Yet as there can be better I
just kept on twiddling the Xconfig file, and now I have a 800x600 working
fine (be it very small letters). The pertinent information from Xconfig:

  Modes         "640x480" "800x600" 
  Clocks        25 28 32 33 36 38 40 45 51 57 63 66 72 76 80 90 
 "800x600"      33      872 884 1052 1076     600 600 605 625
 "640x480"      25      640 672 768 800       480 490 492 525

Met vriendelijke groeten, Wim `Blue Baron' van Dorst
---------------------------------------------------------------------
Blue Baron = Wim van Dorst, Voice (+31) 074-443937, (+31) 02152-42319
(-:       baron@clifton.hobby.nl          tgcpwd@urc.tue.nl       :-)
---------------------------------------------------------------------
From: beers@acsu.buffalo.edu (Andrew Beers)
Newsgroups: comp.os.linux
Subject: stderr buffering
Date: 4 Sep 92 22:49:51 GMT
Organization: UB


I just got the sc package from tsx-11.  I press '?' for help, and the help
screen does not appear.  After a few more keypresses, the help screen appears
and then quickly disappears.

I have also noticed that when I press <ESC> to exit edit mode in vi, it can
take several seconds before the cursor will move back one space.

I compiled the unit conversion program units, and noted that fprintf's not
ending with a carriage return were not immediately sent to the screen.  All of
the fprintf's printed to stderr.

It is my understanding that stderr should not be buffered at all.  These three
cases lead me to believe that it is being buffered under Linux.

System:  386sx/25, 4Meg, 0.96pl2 (have noticed it with earlier kernels, also).

Any ideas on this problem?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Andrew C. Beers, N2LUH             beers@cs.buffalo.edu  
SUNY Buffalo, Computer Science     {rutgers,uunet}!cs.buffalo.edu!beers
From: tree@midget.towson.edu (Denise Tree)
Newsgroups: comp.os.linux
Subject: Re: How to boot a SCSI drive (WD7000 FASST)
Date: 16 Sep 92 03:17:49 GMT
Article-I.D.: athena.1992Sep16.031749.26982
Reply-To: tree@midget.towson.edu (Denise Tree)
Organization: The Internet


sdawson@sbgrad8.cs.sunysb.edu (Steven Dawson) writes:

| suggestions of alternatives to BOOT.SYS

The PC magazine utility MBOOT works fine and is free,
though it only allows four boot choices. It has a 
timeout default and requires no rebooting.

Get it from oak.oakland.edu, my favorite simtel20 mir-
ror.
 
_____________________________________________________________________
_______________ Denise Tree
____________________________tree@midget.towson.edu
_________________________________________.... . . .   .   .    .     .
                                                                     .
                                                                     .
                                                                     *
    
Newsgroups: comp.os.linux