lostecho/oldlinux-files
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

add directory mail-archive

Browse Source
This commit is contained in:
gohigh
2024-02-19 00:25:02 -05:00
parent 07129c3397
commit a778c607a4
1056 changed files with 796887 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

819
mail-archive/linux-devel/Volume1/digest5XX/digest597 Normal file
View File

@@ -0,0 +1,819 @@
From: Digestifier <Linux-Development-Request@senator-bedfellow.mit.edu>
To: Linux-Development@senator-bedfellow.mit.edu
Reply-To: Linux-Development@senator-bedfellow.mit.edu
Date: Sat, 2 Apr 94 15:13:09 EST
Subject: Linux-Development Digest #597
Linux-Development Digest #597, Volume #1 Sat, 2 Apr 94 15:13:09 EST
Contents:
Re: IDE Performance Package (Superuser)
dblspace for umsdos using dosemu (Ron Jones)
LINUX port to a trnasputer systemIn article GEp@si.hhs.nl, Antoni.Ba (v922215@si.hhs.nl)
Could someone uuencode and post kernel.tgz from diskd4 of slackware (Phillips, James Glenn, IV)
Re: Kernel compile dying w/SIGSEGV (macleod@adoc.xerox.com)
Re: Async I/O (dave@valhalla.ee.rochester.edu)
Re: unsupported keys (scancode (xx) not in range 00 - 5f) (gt8134b@prism.gatech.edu)
Re: Specialix Driver Round 2 (From specialix) (bof@wg.saar.de)
Re: LINUX port to a transputer system (Arthur)
Re: Specialix Driver Round 2 (From specialix) (iiitac@uk.ac.swan.pyr)
Re: IPX compliancy? (iiitac@uk.ac.swan.pyr)
Bug in TIOCCONS ioctl ? (braun@physik.uni-kl.de)
Re: Slackware as a tar.gz file? (cdent@yod.honors.indiana.edu)
Re: LINUX port to a transputer system (arnold@sienna.dstc.edu.au)
Re: Kernel compile dying w/SIGSEGV (mitchell@mdd.comm.mot.com)
Re: Linux <--> DOS PLIP??? (pbauer@rnivh.rni.sub.org)
ISDN driver sought (leitner@inf.fu-berlin.de)
Linux CD Rom with Wearnes (scornd7@solomon.technet.sg)
----------------------------------------------------------------------------
From: root@fusion.cuc.ab.ca (Superuser)
Subject: Re: IDE Performance Package
Date: Fri, 1 Apr 1994 02:14:56 GMT
mlord@bnr.ca (Mark Lord) writes:
> In article <2ndj10$8gb@levelland.cs.utexas.edu> danielsi@cs.utexas.edu writes:
> >
> >I've installed the ide performance package upon linux 1.0 and have found
> >the following: Whenever I have disk activity, the mouse jumps around under X.
>
> The *only* possible way that the performance patches could cause this
> is if you are using multiple mode *without* allowing the driver to
> unmask interrupts.
I installed the first IDE performance patch, and seeing that the default
was to unmask interrupts, I thought that perhaps the problems associated
with unmasking the interrupts had been solved, so I left the setting as is..
Unfortunately, unmasking interrupts caused my disks to be seriously trashed.
And although e2fsck seemed to repair the damage, there were many files I had
to re-install and many others that I had to re-create... I'm still not 100%
confident that the file system is "back to normal", even though it's been
several weeks now without incident. I think it's a bad idea for the default
to be unmasked interrupts. In any patch/package where there is a significant
risk of data loss, all the settings should be such that the it will not cause
problems for the majority of systems, even at the expense of lost performance.
If you want to take a chance, you can enable these risky features, but they
definitely should not be on by default.
>
> On my system and on many others, the exact opposite behaviour is observed
> when the patches are applied and interrupt unmasking is enabled.. the mouse
> goes from very unresponsive to more responsive.
> --
> mlord@bnr.ca Mark Lord BNR Ottawa,Canada 613-763-7482
c4
--
Christopher Lau- "Mr. Unix" | / Fusion: Playing With Fire!
StarBright Research | / / H + H -> He + 24 MeV
-- | /_/_/_ "Bring back Trudeau!"
root,lauc@fusion.cuc.ab.ca |____________ "This space for rent"
------------------------------
From: ron@pedi.ama.ttu.edu (Ron Jones)
Subject: dblspace for umsdos using dosemu
Date: 2 Apr 1994 04:26:44 -0600
To umsdos and dosemu hackers:
I have been using the ALPHA 0.2 umsdos fs version of Slackware 99.15
and have enjoyed having Linux co-existing my MS-DOS formated HD, without
re-partitioning.
My only wish for umsdos is that it would support dblspaced (compressed)
harddrives; however, I have an idea for a solution:
Besides experimenting with Linux and it's umsdos fs variant, I also have messed
with dosemu. It seems to me that dosemu could be modified/merged
into umsdos to provide the necessary linkage to a doublespaced or stacker
logical hd. This would avoid entirely the problem of trying to come up with
dblspace or stacker compatible routines.
If I understood the docs correctly, umsdos fs was mostly a hack of the dos fs
code. It seems natural that the dosemu code be cannibalized (strip out every-
thing except what is necessary for MS-DOS to boot and load the dblspace.bin
to mount the compressed-volume-file harddisk) so as to add dblspace compression
to umsdos. Some additional interface code may or may not be necessary at this
point.
Basically, the emudos (using it's dos fs code) should now talk to the hacked
dosemu (who is running MS-DOS & dblspace) for it's disk accesses
instead of talking to the hd device driver or dos parition directly.
Regards,
Ron Jones
ron@pedi.ama.ttu.edu
------------------------------
From: v922215@si.hhs.nl (v922215@si.hhs.nl)
Date: 29 Mar 94 07:40:26 +0000
Subject: LINUX port to a trnasputer systemIn article GEp@si.hhs.nl, Antoni.Ba
From: v922215@si.hhs.nl (Baranski, A.S.)
Date: Tue, 29 Mar 1994 07:40:26 GMT
FIRST OF ALL SORRY FOR THE TOOOO LONNNNG LINEESSSSSSS.
Hi world,
So far I have received many reactions from GREAT to shut this guy up in a lunny
bin.
But I think that most people didn't really understand my first message. I said
I
wanted to have the 486 do all the I/O work and thus working as a server with
the
transputer as client.
Well I've been searching high and low in articels concering transputer
hardware. And
found some advertisments about SCSI 1/2 controllers as a T-RAM module. So the
need for ans AFS (Alien file server) might not be so great, or maybe it would
because
I would need a way to boot the transputer (it would be possible to boot from a
EPROM)..
And now let me try to explain the idea again, so simple as possible:
The idea was that it would be possible to open a window under LINUX with X11
and have the Transputer running in there. Doing some number crunching in
parallel
with the 486. And there for a part of the LINUX code would be needed to run
on the
Transputer.
The port wouldn't be written in OCCAM 2 because that would give me a HUGE pain
in the BUM!!!! Because of the way how OCCAM 2 is written. But in C and compiled
with
a 3L-C Compiler. Which I am planning on buying soon. If I can get it for a nice
price.
And not for 600 pounds which is around 1800 Guilders and that's a bit much, for
a
student that has to live of something around 300 guilders a month. So I'll be
looking
at 3L if they don't have a studente version or a student price, for their
compiler.
Or if someone out there in internet land would like to part with his 3L
compiler, I am
interested.!!!
I hope this makes life easyer for you folks out there.
SU
================
Baranski, A. S. | Haagse HogeSchool
e-Mail: | Sector Informtica
Antoni.Baranski@si.hhs.nl | Student Software Engineering
P.S. Sorry to all of you who couldn't read the first posting ........
Keywords:
------------------------------
From: JP8659@CONRAD.APPSTATE.EDU (Phillips, James Glenn, IV )
Subject: Could someone uuencode and post kernel.tgz from diskd4 of slackware
Date: 2 Apr 1994 04:24:52 GMT
I'm in the process of installing Linux via FTP. But I don't have any kind of
direct connection to the internet so I have to ftp everything to my vax account
and then sz it to my box.. But I've got a 2000block limit on my account..
Which means that all the files bigger than about 950k are too big.. thus I
can't get kernel.tgz from diskd4 of the slackware distribution.. could someone
uuencode it and post? Thanx in advance..
Jim Phillips(jp8659@appstate.edu)
------------------------------
From: macleod@adoc.xerox.com (macleod@adoc.xerox.com)
Date: 29 Mar 94 02:21:24 +0000
Subject: Re: Kernel compile dying w/SIGSEGV
From: macleod@adoc.xerox.com (Peter MacLeod)
Date: 29 Mar 1994 02:21:24 GMT
Douglas Donahue (odoncaoa@panix.com) wrote:
: Greetings,
: Over the course of the weekend, I attempted to recompile the kernel. The
first
: attempt was sucessful. However, subsequent attempts failed with what would
: appear to have been segmentation violations. A representative error message
: follows. The strange part of it though, is that the compile failed at a very
: early point in the remake on one attempt, but breazed right through the same
: point in the compile on a subsequent attempt. It's obvious to me that there
: are not any errors in the source that are generating such problems. e.g.
: dividing by zero. Has anyone else had such experiences? How about one of the
: compiler and/or kernel experts speaking up? What would cause the compiler to
: fail with a segmentation violation when one doesn't actually exist? What
: would cause the kernel to generate such a signal and kill the compiler?
[etc]
I used to get this all the time. Then I changed the timing on my motherboard,
and it went away completely--I haven't had a problem since, and I've rebuilt
the kernel many times.
This has been discussed before, and the culprits blamed were ISA<->memory
transfers, motherboard memory itself, and the phases of the moon. It
would appear that simple tests, especially DOS- or Windows-based tests,
don't pound the machine hard enough, so rebuilding the Linux kernel is a
pretty good test. In any case, you can imagine that if gcc started paging,
and one of the paging transfers had an error in it, thus changing the
code, you could get a seg. violation. One problem with the kernel, at
least the last time I looked, is that a lot of the hardware traps
are mapped to one signal, segmentation violation. I'm not sure if that's
a POSIX thing or what, but it does make figuring out what's going on
a bit of a hassle.
Anyway, if your motherboard has lots of settings like mine does, start
changing things like ISA bus speed, DRAM wait states, ISA bus wait states,
etc. If it doesn't, you might be SOL. I think the thing I did that made
the most dramatic difference was slowing the ISA bus down to 8 Mhz.
A lot of motherboards have a 12Mhz setting, and many ISA bus cards
are unreliable at 12Mhz. Others have found that replacing SIMMs cured their
problems.
Also, if you have a 50Mhz DX motherboard, like I do, you might just want to
replace it with a 66Mhz DX2...Oh, another thing I've remembered--when I
first got my motherboard, it crashed a lot, and the problem turned out to be
that I had a 50Mhz motherboard with cache RAM for a 33Mhz motherboard, so
make sure that your cache SRAMs are fast enough.
-- Peter
------------------------------
From: dave@valhalla.ee.rochester.edu (dave@valhalla.ee.rochester.edu)
Date: 28 Mar 94 17:52:03 +0000
Subject: Re: Async I/O
From: dave@valhalla.ee.rochester.edu (David F. Carlson)
Date: 28 Mar 1994 12:52:03 -0500
May I suggest rather than using MVS as a model for your async I/O support,
get a recent draft of the IEEE POSIX1003.4 (nee' 1b) standard. This was
recently ratified by the IEEE real-time POSIX committee and although not
perfect contains much insight into the problems you discuss. The hassle
is that the IEEE has decided to make money on their standards so the documents
are not ftp'able.
Since Linux is already 1003.1 compliant, getting the pieces to 1003.4 in place
seems like the "Portable" thing to do.
dave
------------------------------
From: gt8134b@prism.gatech.edu (gt8134b@prism.gatech.edu)
Date: 27 Mar 94 17:45:58 +0000
Subject: Re: unsupported keys (scancode (xx) not in range 00 - 5f)
From: gt8134b@prism.gatech.edu (Robert Sanders)
Date: 27 Mar 1994 12:45:58 -0500
kaz@lilia.iijnet.or.jp (Kaz Sasayama) writes:
>My keyboard generates scancodes not in range 00 - 5f for some keys.
>How can I use them?
>press any key (program terminates after 10s of last keypress)...
>0x9c
>0x7b
>0xfb
>0x79
>0xf9
>0x70
>0xf0
>0x7d
>0xfd
Are you using one of the newer "programmable" keyboards, such as the
Northgage Omnikey or the Focus 9001? I'm using the latter, and get
similar messages when I press the PF keys. I just got the keyboard,
but I'll look into it when I get the time.
--
_g, '96 --->>>>>>>>>> gt8134b@prism.gatech.edu <<<<<<<<<--- CompSci ,g_
W@@@W__ |-\ ^ | disclaimer: <---> "Bow before ZOD!" __W@@@W
W@@@@**~~~' ro|-<ert s/_\ nders | who am I??? ^ from Superman '~~~**@@@@W
`*MV' hi,ocie! |-/ad! / \ss!! | ooga ooga!! | II (cool)! `VW*'
------------------------------
From: bof@wg.saar.de (bof@wg.saar.de)
Date: 24 Mar 94 13:12:14 +0000
Subject: Re: Specialix Driver Round 2 (From specialix)
From: bof@wg.saar.de (Patrick Schaaf)
Date: Thu, 24 Mar 1994 13:12:14 GMT
hp@kbbs.kiel.sub.org (Holger Petersen) writes:
>Is there any problem in givin "Souce" consisting of some sequence of
>"Define_Byte ##"
>statements in an "xyz.S" - File ??
Speculations about how to circumvent the GPL should go
to gnu.misc.discuss only. Followup-To: is set.
The GPL says:
The source code for a work means the preferred form of the work for
making modifications to it.
I think this explicitly forbids your proposal, and rightly so, because
what you propose is the same as an .o file - I can trivially
convert the .o file to an .s file that will recreate the .o after assembly,
so the two forms are the same.
IMO binary-only driver distributions would clearly violate the GPL,
and it is up to Linus to allow them explicitly. I also think it would
be a Good Thing to do that.
regards
Patrick
------------------------------
From: Arthur%2476-451-99@logo.ka.sub.org (Arthur)
Date: 24 Mar 94 05:05:22 +0000
Subject: Re: LINUX port to a transputer system
From: Arthur Raiskio (arthur@dpi.qld.gov.au)
Date: Thu, 24 Mar 1994 05:05:22 GMT
In article <Cn24EH.I4G@si.hhs.nl> Antoni.Baranski@si.hhs.nl writes:
> I must say that I am new to LINUX and have never ported any software that
realy
>worked after the porting.
>
I am currently doing a port of gcc2.5.8 to a t8000 transputer as part of my
Master of
Computer Science requirements and I can tell you that that is hard enough
without
having to worry about that weird transputer architecture for other things. My
suggestion is try if you want to but prehaps your first port should be
something smaller
unless you are really aware of the subtle details of the compiler, filesystems
etc.
> I under stand that big portions of the LINUX kernel are written in assembly,
and
>that is a point I fear I migth get into a lot of trouble because my knowlegde
of
>assembly isn't that great. And programming the transputer is assembly well, no
>thank you. So I would have to translate all the assembly into C/C++.
The kernel code I have changed has been mostly C anyway. There is possibly some
assembler
still but it is a fairly small amount.
>
> SO, if my idea is crazy please let me know.
From my experience with just gcc so far I would say "commit him he must be
insane!!!"
Regards
Arthur Raiskio
(arthur@dpi.qld.gov.au)
------------------------------
From: iiitac@uk.ac.swan.pyr (iiitac@uk.ac.swan.pyr)
Date: 28 Mar 94 11:45:46 +0000
Subject: Re: Specialix Driver Round 2 (From specialix)
From: iiitac@uk.ac.swan.pyr (Alan Cox)
Date: Mon, 28 Mar 1994 11:45:46 GMT
In article <1994Mar23.182432.20120@kbbs.kiel.sub.org> hp@kbbs.kiel.sub.org
(Holger Petersen) writes:
>rogers@drax.isi.edu (Craig Milo Rogers) writes:
>
>> Revealing that part of the host-side driver, as by publishing
>>its source code, would reveal details of the host-side interface which
>>(at least one) vendor wishes to keep a trade secret.
That's their problem. You can always reverse engineer it.
>
>Is ther any part in the Gnu-licence that says:
>
> "You have to use 'C' as _the_ language " ??
>
No but you are required to give the source in its 'preferred form' so you
can't scramble it up and shield it.
Alan
------------------------------
From: iiitac@uk.ac.swan.pyr (iiitac@uk.ac.swan.pyr)
Date: 28 Mar 94 11:50:49 +0000
Subject: Re: IPX compliancy?
From: iiitac@uk.ac.swan.pyr (Alan Cox)
Date: Mon, 28 Mar 1994 11:50:49 GMT
In article <Cn6C79.6t0@cnsnews.Colorado.EDU> tierney@rintintin.Colorado.EDU
(Craig Tierney) writes:
>Someone has already done the reverse-engineering. In Dr. Dobbs Journal a
>few months back, the NCP (Netware Core Protocol) was documented. The NCP
>is how the Shell(Netx) communicates with the server, on top of IPX.
>There is also a book that is being released about Netware that covers
>many of the undocumented aspects.
If you've tried playing with this you'll find that its not accurate and
it doesn't cover a lot of the 'hard' stuff like mapping a drive. I got a
server hack as far as login then got too busy.
Alan
------------------------------
From: braun@physik.uni-kl.de (braun@physik.uni-kl.de)
Date: 29 Mar 94 15:33:59 +0000
Subject: Bug in TIOCCONS ioctl ?
From: braun@physik.uni-kl.de (Martin Braun)
Date: Tue, 29 Mar 1994 15:33:59 GMT
Hello all,
Yesterday I tried to make xconsole work for normal users and
found that it is not sufficient to set proper permissions for
/dev/console. The method used by xconsole to catch console output
is as follows (xconsole.c:OpenConsole):
.
.
.
struct stat sbuf;
/* must be owner and have read/write permission */
if (!stat("/dev/console", &sbuf) &&
(sbuf.st_uid == getuid()) &&
!access("/dev/console", R_OK|W_OK))
{
.
.
.
#if defined(USE_PTY) && !defined(SOLX86)
int on = 1;
if (get_pty (&pty_fd, &tty_fd, ttydev, ptydev) == 0 &&
ioctl (tty_fd, TIOCCONS, (char *) &on) != -1)
{
input = fdopen (pty_fd, "r");
}
#endif
.
.
.
Even though the permissions for /dev/console are set properly this fails
in the TIOCCONS ioctl (output of strace):
...
stat("/dev/console", {dev 3 2 ino 42 mode 020622 nlink 1 uid 1418 gid 1400 size
0 ...}) = 0
getuid() = 1418
access("/dev/console", 06) = 0
open("/dev/ptyp0", RDWR) = -1 (Try again)
open("/dev/ptyp1", RDWR) = 4
open("/dev/ttyp1", RDWR) = 5
ioctl(5, TIOCCONS, 0xbffffb04) = -1 (Operation not permitted)
...
This happens because under linux this ioctl may only be used by root
(from linux/drivers/char/tty_ioctl.c:tty_ioctl):
.
.
case TIOCCONS:
if (IS_A_CONSOLE(dev)) {
if (!suser())
return -EPERM;
redirect = NULL;
return 0;
}
if (redirect)
return -EBUSY;
if (!suser())
return -EPERM;
if (IS_A_PTY_MASTER(dev))
redirect = other_tty;
else if (IS_A_PTY_SLAVE(dev))
redirect = tty;
else
return -ENOTTY;
return 0;
case FIONBIO:
.
.
IMHO this is a bug which breaks xconsole. I am not a kernel hacker
and can't provide a fix for it. Suggestions and comments are
appreciated.
Best regards,
Martin Braun
(braun@physik.uni-kl.de)
PS: Configuration: Linux-1.0.4, libc-4.5.21, Xfree86-2.1, gcc-2.5.8
------------------------------
From: cdent@yod.honors.indiana.edu (cdent@yod.honors.indiana.edu)
Date: 30 Mar 94 02:32:43 +0000
Subject: Re: Slackware as a tar.gz file?
From: cdent@yod.honors.indiana.edu (NetDog)
Date: Wed, 30 Mar 1994 02:32:43 GMT
>>>>> "Jerome" == Jerome Kaidor <jkaidor@synoptics.com> writes:
Jerome> I dreamt of a script that would activate FTP, tell it
Jerome> to get slackware.tar, and pipe its output straight up to
Jerome> tar on my machine, which would then spew out files and
Jerome> directories. Probably an impossible dream......
One possibility is to use mirror, the package that some archive sites
use to keep up their mirrors. I can be set up to get an entire
director and subdirectories. This is what the config file would look
like for slackware:
package=slackware
comment=The Linux Slackware Distribution
site=ftp.cdrom.com
remote_dir=pub/linux/slackware
local_dir=/foo/bar/slackware
mail_to=foofoo
The mirror package is available at:
src.doc.ic.ac.uk [146.169.2.1]
directory: computing/archiving/mirror
(shortcut packages/mirror)
Although it was originally intended to be used for continuous upkeep
of a collectin it works great for getting files just once. One thing
you have to watch out for (especially if you are doing the ftpping
from a linux box): check the logs when the program has finished for
the files that it timed out on. You will have to go back and get
those; either by hand or just run mirror again (it only gets files it
doesn't already have).
Chris
--
cdent@indiana.edu|"if you're so special why aren't you dead?"-TheBreeders
------------------------------
From: arnold@sienna.dstc.edu.au (arnold@sienna.dstc.edu.au)
Date: 28 Mar 94 23:52:08 +0000
Subject: Re: LINUX port to a transputer system
From: arnold@sienna.dstc.edu.au (David Arnold)
Date: 28 Mar 1994 23:52:08 GMT
In article <wpp.764502256@marie> wpp@marie.physik.tu-berlin.de (Kai Petzke)
writes:
Antoni.Baranski@si.hhs.nl (Baranski, A.S.) writes:
>Hi World,
> I am a student at the Haagse HogeSchool Sector Informatica in
>the Hague, Holland. During my summer holliday I am planning on
>making a port of LINUX onto a T800 transputer subsystem which
>plugs into my PC.
Well, I want to encourage you to do it. It will stop all these
people, who say: "But linux does not run on a multiprocessor", if
it runs on your plug in transputer :-)
While I wouldn't like to discourage your creative efforts, there's a
few things you should know before you start.
From my limited understanding of the internal structure of the Linux
kernel and also based on what it provides to the programmer, I don't
think that it will be possible to port the kernel to the T4/8 series
transputer architecture.
The T4/8 series transputers do not have the hardware to support
virtual memory. Nor do they have the ability to protect areas of
memory from other processes. Since these are the fundamental
assumptions made in the Linux kernel, I think this is where you luck
out ...
My idea was to do as minimal work as possible in the beginning. Is
it possible, that a process on the transputer sends a signal to the
Intel chip? Furthermore, is it possible to map transputer memory
into the Intel address space? In that case, all the system calls
could be processed by the standard Linux kernel, and all you had to
programme was a small transputer kernel, which transfers the system
calls to the Intel.
Yes, it is possible to send signals to the Intel CPU, depending on
what protocol you use between the T80x and the x86. However, assuming
that you are going to be using standard transputer boards, the major
problem is the bandwidth available between the two CPUs. However, it
might be possible to come up with a reasonable way to pass system
calls back to the x86. The difficulty will be that the kernel will not
have access to the memory of the processes. Memory mapping is not
possible with standard hardware.
Not much of the Linux kernel is written in assembler, check with
the header files in /usr/include/asm. Non-assembler versions of
the string routines as found in /usr/include/linux/strings.h are
found in the GNU C-Library for example.
But you may have to learn about your Transputer's assembly to get
things rolling.
Yep - I'd think so too. And once you've done that, you might want to
reconsider. Transputer assembly reflectes the CPU architecture, and
it's a long way from that of the x86 !
Overall, the best approach may be to look at Minix instead. For one
thing, there is already someone working on a port to the T4/8 CPUs
which is always a good thing.
The major advantage though is that Minix does not (in the base 1.6
version) provide virtual memory. It allocates fixed size memory areas
to processes - which should suit the transputer very well. You could
then allocate a guard area at the end of the stack, and check it
sometimes to make sure that the stack hasn't overflowed.
The kernel structure of Minix is also suitable for transputers. It is
composed of a number of independant processes that communicate using
small messages. I would think that with some hacking you should be
able to put a memory manager and scheduler on each processor, and get
them to cooperate in executing processes. The filesystem could run
either on the x86 or the root transputer.
Another thing that might be fun - I think that the original Minix
filesystem is single threaded. It would make sense to rewrite this as
a multi-threaded server.
In my opinion, this project would provide a similar amount of 'fun'
but with a much lower frustration potential that attempting to port
Linux. Who knows, it might even be working by the end of your
holidays ?
davida
--
David Arnold
==================================================================
CRC for Distributed Systems Technology arnold@dstc.edu.au
University of Queensland voice +617 3654367
Australia fax +617 3654311
--
David Arnold
==================================================================
CRC for Distributed Systems Technology arnold@dstc.edu.au
University of Queensland voice +617 3654367
Australia fax +617 3654311
------------------------------
From: mitchell@mdd.comm.mot.com (mitchell@mdd.comm.mot.com)
Date: 28 Mar 94 22:52:21 +0000
Subject: Re: Kernel compile dying w/SIGSEGV
From: mitchell@mdd.comm.mot.com (Bill Mitchell)
Date: 28 Mar 1994 14:52:21 -0800
in comp.os.linux.development, odoncaoa@panix.com (Douglas Donahue) said:
>[...]
>A representative failure message:
>.
>.
>gcc -D__KERNEL__ -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe \
> -m386 -c -o init/main.o init/main.c
>gcc: Internal compiler error: program cc1 got fatal signal 11
>make: ***[init/main.o] Error 1
>cpp: output pipe has been closed
Just a followup to say that at least one other has similar woes.
I started at 0.99pl8, and kernel rebuilds were rock solid for a while.
Somewhere around pl12, I started seeing just exactly what is reported
above. I'm still seeing it with pl15h.
I've commented about it a couple of times in comp.os.linix.whatever, and
responses indicated that it had to be a hardware error. That's reinforced
by rock-solid rebuilds on other linux installations. However, I don't
recall seeing anything like this with anything but cc, and can't localize
it to a hardware problems. Exercising the disks by copying massive amounts
of data works OK, and standalone memory-test programs run overnight report
no problems.
For now, I'm just living with it. I restart "make zImage" as needed, and
reboot if that doesn't work (the problem appears less frequently on a
recently booted system).
--
mitchell@mdd.comm.mot.com (Bill Mitchell)
------------------------------
From: pbauer@rnivh.rni.sub.org (pbauer@rnivh.rni.sub.org)
Date: 28 Mar 94 00:00:53 +0000
Subject: Re: Linux <--> DOS PLIP???
From: pbauer@rnivh.rni.sub.org (Peter Bauer)
Date: Mon, 28 Mar 1994 00:00:53 GMT
I have currently a plip-connection running between a linux-box and
msdos running crynwr plip.com and ncsa-telnet or pcip_pkt. The changes I
made are:
- strobe bit-levels need to be inverted
- throw out plip_type logic: send as ethernet would do
- length byte order inverted
- there was a "bug" in the send_byte: To allow the data-bits to
settle first before they are strobed, they were put without the
strobe bit first, but without masking off the high nibble of the
data, so sometimes (if data's 0x10 bit was set, this settle-logic
failed, and this resulted in receive-errors in dos-plip.com, because
there is only a single asm-in, which is not repeated after the strobe
is seen ...
If someone wants the diffs, send mail ...
Gruss PB
------------------------------
From: leitner@inf.fu-berlin.de (leitner@inf.fu-berlin.de)
Date: 25 Mar 94 18:55:30 +0000
Subject: ISDN driver sought
From: leitner@inf.fu-berlin.de (Felix von Leitner)
Date: Fri, 25 Mar 1994 18:55:30 GMT
Hi !
I Am am looking for ISDN drivers for ILinux.
Please mail me where to find one !
Thanks, Felix
--
(----------------------------------------------------------------)
Felix von Leitner, Gervinusstrasse 22, 10629 Berlin, +49-30-3242987
President of the Council of Ultimate Wisdom
High Druid of the Circle of the Ancient Shrub
------------------------------
From: scornd7@solomon.technet.sg (scornd7@solomon.technet.sg)
Date: 28 Mar 94 08:22:06 +0000
Subject: Linux CD Rom with Wearnes
From: scornd7@solomon.technet.sg (Tang Chang Thai)
Date: 28 Mar 1994 08:22:06 GMT
I am looking for a version of Linux CD Rom that can work with the Wearnes
CD Rom package. Any suggestions?
------------------------------
** 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-Development-Request@NEWS-DIGESTS.MIT.EDU
You can send mail to the entire list (and comp.os.linux.development) via:
Internet: Linux-Development@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
sunsite.unc.edu pub/Linux
End of Linux-Development Digest
******************************