==============================
From: pete@cbnewsl.cb.att.com (peter.j.fillingham)
Subject: 0.97 WORKS with SCSI ! [attn NEWBIES]
Date: Fri, 14 Aug 1992 16:42:55 GMT
Hooray ! Despite the many postings re glitches, features, bugs, etc.,
both 0.97 boot-image and root-image work;
In addition to boot screen announcements of hd0 etc etc the following
graced my screen
sd0 @ scsi0 ID0 lun0
sd1 @ scsi0 ID4 lun0
sd0 p.1 start 32 size 51168 end 51199
p.2 start 51200 size 40960 end 92159
sd1 p.1 start 32 size 20448 end 20479
p.2 start 20480 size 20480 end 4085?
and so with fear and trembling i interpreted sd1 p.1 as sdb1 & used
mkfs -c /dev/sdb1 10000
when asked for /usr in the [excellent] install script.
SO, the guts went on hda1 and the /usr stuff on /dev/sdb1 [AKA /usr].
While this may be OBVIOUS to the cognescenti, perhaps my experience
will be helpful to the less fortunate...
BTW, i KNEW that my first SCSi drive was employed elsewhere as
was the second half of sd1; apparently the size reported is in
blocks of 512 bytes, wheres linux uses 1024 byte/block...
KUDOS to the SCSI freaks at woz etc.
...and KEEP THE ASPIDISTRA FLYING
Peter Fillingham [keeper of the DDEBs] <<fillingham@att.com>>
==============================
From: sakaria@vipunen.hut.fi (Sakari Aaltonen)
Subject: Can't Compile Kernel 0.97
Date: 14 Aug 1992 16:12:57 GMT
Reply-To: sakaria@vipunen.hut.fi (Sakari Aaltonen)
My attempt to build kernel 0.97 with gcc2.2.2 fails (at tools/build) because
the following files are missing::
sys/types.h
fcntl.h
unistd.h
Specifically, they are not in /usr/include, that is, the directory that, as
far as I understand, should be used for tools/build.
I have files with these names among the kernel files. I tried copying them
into /usr/include, which makes the make succeed. However, build then fails
with the message
Can't stat root device
Indeed, it seems that stat() ALWAYS returns -1...??
Does anyone know where I might obtain the missing files?
Out of curiosity: does anyone have an idea WHY the files are missing?
Or why stat() should return -1, no matter what the path,
"/usr/include", say?
-- ============================================================================= Sakari Aaltonen Helsinki University of Technology Email: sakaria@vipunen.hut.fi --- You can't keep a Finn down without him getting all red in the face ----==============================
From: mal11@po.CWRU.Edu (Matthew A. Lewis) Subject: Diamond Speed Star SVGA card Reply-To: mal11@po.CWRU.Edu (Matthew A. Lewis) Date: Fri, 14 Aug 1992 17:18:32 GMT
anyone got this to work with X under Linux????
And also, is it true that the Diamond Stealth card won't work 'cuz it has that new S3 chip???
Thanx in advance.
-- MaThiEu a. LeWis Thieves Like Us mal11@po.cwru.edu
==============================
From: baron@clifton.hobby.nl (Wim `Blue Baron' van Dorst) Subject: Re: FAQ? Date: 14 Aug 1992 02:04:38 GMT
wirzeniu@klaava.Helsinki.FI (Lars Wirzenius) writes: | >I have waded through xxx million posts, and no FAQ! |> Did you see my meta-faq? It has a subject line | Subject: README: Where to find information about Linux (25 July 1992)
Just a suggestion: How about giving the meta-faq a subject including the literal text `faq'? Then it would show up when searching all Subject lines for that very text.
Don't get me wrong: The faq and the meta-faq in itself are quite good things. The complete faq could do with a little updating. I'm trying to get Linux together here, and it doesn't answer all my obvious questions anymore.
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: mal11@po.CWRU.Edu (Matthew A. Lewis) Subject: Re: Pointers to a list of Graphics Cards for X386 Reply-To: mal11@po.CWRU.Edu (Matthew A. Lewis) Date: Fri, 14 Aug 1992 17:21:07 GMT
In a previous article, hasty@netcom.com (Amancio Hasty Jr) says:
|Currently, I am using a Diamond SpeedStar with 1MB (et4000 based). |X386 1.2E 1.0.[12] and the stock X386 server has been able to |work with my card. I am writing a driver for the Diamond Stealth |
I opened a Speed Star and I couldn't find the ET4000 chip. Do all of them have it?
Thanx
-- MaThiEu a. LeWis Thieves Like Us mal11@po.cwru.edu
==============================
From: mal11@po.CWRU.Edu (Matthew A. Lewis) Subject: large caches ona 486 Reply-To: mal11@po.CWRU.Edu (Matthew A. Lewis) Date: Fri, 14 Aug 1992 17:24:21 GMT
I was considering get a 256k cache for my i486-33 and I was wondering if anyone has had any problems with caches on these faster machine. I can't understand why there would be a hardware probelm depeendant upon software. The only problem I've ever had with a machine being TOO fast is playing video games :)
Later
-- MaThiEu a. LeWis Thieves Like Us mal11@po.cwru.edu
==============================
From: almesber@nessie.cs.id.ethz.ch (Werner Almesberger) Subject: Re: Hey! Linux fs on DOS partition! Date: Fri, 14 Aug 1992 17:40:26 GMT
In article <713720748snx@crynwr.com> nelson@crynwr.com (Russell Nelson) writes: | Hey, here's a cool idea I had yesterday: Make a Linux filesystem | driver that puts its filesystem in a file on an MS-LOSS partition.
Sorry to disappoint you, but there are several people, who already had this idea. No shiny new patents .. ;-)
Seriously: half of it is already there. The other half will be missing until the variable block size code is completed. The first half is the loop devices patch, that makes it possible to mount regular files on file systems that support bmap as file systems.
Unfortunately, MS-DOS arranges its clusters in such an odd way, that bmap can't be used on hard disks and on some floppies. But it works with the old 360k (and I think also 1.2MB) format. If you have the loop devices patch installed, you can try something like this:
# mount -t msdos /dev/fd0 /fd # there's a 360kB floppy in /dev/fd0 # dd if=/dev/zero of=/fd/file bs=1k count=350 # mkfs /fd/file 350 # mount /fd/file /mnt
- Werner -- _________________________________________________________________________ / Werner Almesberger, ETH Zuerich, CH almesber@nessie.cs.id.ethz.ch / / IFW A44 Tel. +41 1 254 7213 almesberger@rzvax.ethz.ch / /_BITNET:_ALMESBER@CZHETH5A__HEPNET/CHADNET:_[20579::]57414::ALMESBERGER_/
==============================
From: jmsimon@acsu.buffalo.edu (JMS) Subject: Re: large caches ona 486 Date: 14 Aug 1992 18:11:59 GMT
mal11@po.CWRU.Edu (Matthew A. Lewis) writes: | |I was considering get a 256k cache for my i486-33 and I was wondering |if anyone has had any problems with caches on these faster machine. |I can't understand why there would be a hardware probelm depeendant |upon software. The only problem I've ever had with a machine being TOO |fast is playing video games :)
No problems here. Of course, I can't attest to any spped increase/decrease with Linux, as I haven't bothered disabling the cache. For MS-DOG it is definitely a help, tho.
It might not even be doing anything with Linux - would someone with more info like to shed some light on this? Does the cache make enough of a difference to be worth having? I *can* compile the kernel in about 2-3mins, but that may just speak for the 486-33 and quick (relatively) IDE drives.
As an side, though, I have an opportunity to trade some hardware that I have (a 20mb hardcard, SVGA card and 12-1mbx9 SIMMS) for 4-4mb SIMMS. What kind of a difference will I notice going from 8mb to 16mb (4 of the 1x9's that I have are in a box because I only have 8 memory slots - woops!)?
|MaThiEu a. LeWis |Thieves Like Us |mal11@po.cwru.edu
JMS
-- ******************************************************************************* Jeffrey M. Simon .o o. Computer Science / Business Mgmt. jmsimon@acsu.buffalo.edu ~~v~~ State University of NY at Buffalo ***** "Perspiration = ( Genius - 1% Inspiration ) / .99" -Ein*kinda*stein *****
==============================
From: newbie@dylan.camb.inmet.com (Chris Newbold) Subject: Re: Buffer corruption problems. Date: 14 Aug 1992 14:17:46 GMT
In article <BURLEY.92Aug13153840@geech.gnu.ai.mit.edu> burley@geech.gnu.ai.mit.edu (Craig Burley) writes: |In article <1992Aug13.163854.21617@midway.uchicago.edu> ace3@quads.uchicago.edu (Tony 'LLama' Acero) writes: | | I have no idea what's going on and would appreciate any input! :-) | (The smiley is to indicate I'm not complaining and half-expecting | that I've done something bone-headed) | |I'm not sure about your problem or the person's to whose post you followed up, |but... | |...I believe there is a bug in Linux that has the following behavior: | |- causes Linux to "misread" one 1024KB chunk of data from a disk-based file | so that what your app ends up with is some _other_ 1024KB chunk | (apparently from the same file) | |- occurs only during very heavy disk access, such as megabytes accessed | continually | |- is intermittent, but happens enough to reproduce fairly easily | |- might be SCSI-related (I have a SCSI system) but, based on responses I've | gotten from others saying they've seen the same behavior, probably isn't | |- is still in 0.97 and perhaps happens somewhat more often there (though of | course it's hard to measure this)
Yep. I've seen this too. My system is running off SCSI disks. I'd agree with everthing listed above and add:
- It can happen on WRITES as well.
Occasionally when I'm rebuilding the kernel, make will die with some horrid error like it can no longer find the makefile it was working from. Shorty thereafter, anything which accesses the disk seg. faults and dies.
When I bring the system back up, the filesystem is hosed. Usually the superblock is scrambled so fsck just refuses to look at the drive.
Not good.
-Chris
-- ---- Chris Newbold ---- > "If you fool around with a thing for very long you < Intermetrics, Inc. > will screw it up." < Opinions and statements expressed are MINE and do NOT represent my employer newbie@inmet.camb.inmet.com
==============================
From: callison@uokmax.ecn.uoknor.edu (James P. Callison) Subject: Re: Linux Logo Date: 14 Aug 1992 18:11:15 GMT
In article <1992Aug14.002854.20701@constellation.ecn.uoknor.edu> callison@uokmax.ecn.uoknor.edu (James P. Callison) writes: |BTW-that thar logo jain't under the GNU Copyleft. I hold a copyright |on it. That means that you can copy it, use it on your distribution |of Linux, change it, do whatever you like, but you CANNOT sell the |LOGO for ANY price. I would like to get some credit, though. :-) |(And I mean it--don't sell the LOGO. Use it as you will. Put it |on Linux distributions you're selling for $6,000,000 apiece. |Change the release number. Change the colors. Change the font. |But absolutely DON'T sell the logo at ANY price.) | |Thanks.
Arrogant bastard, ain't I? :-) Hmm...this doesn't seem to have come out right (sorry, I was fighting a whineybaby file server--why can't it just suck it up and ignore those memory errors like a _real_ 486? :-) I just want to make sure that everybody knows that this thing is _freely_ distributable (as in _NO_ cost), and freely editable (come on, the thing was a first draft! :-)
James
James P. Callison Microcomputer Coordinator OU Law Library Callison@aardvark.ucs.uoknor.edu /\ Callison@uokmax.ecn.uoknor constellation!biglaw!callison@mailhost.ecn.uoknor.edu DISCLAIMER: I'm not an engineer, but I play one at work... Here's to all the soldiers who have ever died in vain, The insane locked up in themselves, the homeless down on Main To those who stand on empty shores, and spit against the wind And those who wait forever for ships that don't come in --Joe Diffee, "Ships That Don't Come In"
==============================
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests to be added to or deleted from it should be directed, is:
Internet: Linux-Activists-Request@NEWS-DIGESTS.MIT.EDU
You can send mail to the entire list (and comp.os.linux) via:
Internet: Linux-Activists@NEWS-DIGESTS.MIT.EDU
Linux may be obtained via one of these FTP sites: nic.funet.fi pub/OS/Linux tsx-11.mit.edu pub/linux tupac-amaru.informatik.rwth-aachen.de pub/msdos/replace
The current version of Linux is 0.97 released on August 1, 1992
End of Linux-Activists Digest ******************************