Files
oldlinux-files/ftp-archives/tsx-11.mit.edu/1996-10-07/mail-archive/linux-devel/Volume2/digest199
2024-02-19 00:24:15 -05:00

554 lines
21 KiB
Plaintext
Raw Blame History

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: Wed, 21 Sep 94 00:13:07 EDT
Subject: Linux-Development Digest #199
Linux-Development Digest #199, Volume #2 Wed, 21 Sep 94 00:13:07 EDT
Contents:
Linux Floptical Disk Driver? (Oliver Borowiak)
Re: 1.1.51 seg fault on shutdown in _floppy_release (Rob Janssen)
Re: AX25 & KISS Amateur Radio Protocols in Linux?? (Rob Janssen)
Re: Alpha Linux (Dan Pop)
Wanted: binary only gcc with pentium optimizations (Erann Gat)
Re: TCP incoming services hang with 1.1.5x (Harald T. Alvestrand)
Re: X.25 support ....exist ? (Mark Evans)
Buslogic BT946C Supported by Linux? (wang_x@sis.bms.com)
Re: Kernel Goals? (Rob Janssen)
Re: Alpha Linux (David Hinds)
Re: What user interface to use??? (Corey Brenner)
1.1.51 Adaptec 1542 SCSI problems (Nick Kralevich)
Re: Looking for a Fax daemon (Gert Doering)
Re: Extending the IP Protocol? (Gert Doering)
Re: 1.1.51 seg fault on shutdown in _floppy_release (David Miller)
----------------------------------------------------------------------------
From: root@develop1.psych.nat.tu-bs.de (Oliver Borowiak)
Subject: Linux Floptical Disk Driver?
Date: 20 Sep 1994 11:24:39 GMT
Hi,
a few days ago my 3.5" FDD died, so if have to buy a new one.
My thought was why not a Floptical Disk Drive?
As I know, the were produced by IOMEGA. These drives can read
standard 3.5" 720k, 1.44M, 2.88M disks and the Floptical format
of about 21 MB.
The r/w head is controlled by a laser beam, I think.
I think these drives are a good compromize between the standard
FDDs which we need for compatibility reasons and an improvement
of disk space. Of course, a MO-Drive has a even higher storage
capacity (128MB), but you can't read standard disks.
Have anyone out there any informations or experiences about these
drives? Are they suported by Linux or have a device driver to be
developed? do they require a special controller?
Regards,
Oliver.
+------------------------------------------------------------------+
| Oliver Borowiak |
| private: |
| Kalandstrasse 12 Phone : +49-(0)531-895984 |
| D-38118 Braunschweig Fax : +49-(0)531-72069 (company) |
| Germany Email : root@develop1.psych.nat.tu-bs.de |
+------------------------------------------------------------------+
------------------------------
From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: 1.1.51 seg fault on shutdown in _floppy_release
Reply-To: pe1chl@rabo.nl
Date: Tue, 20 Sep 1994 07:30:58 GMT
In <1994Sep19.211220.240@acad.ursinus.edu> STEVO@acad.ursinus.edu (Steve Kneizys) writes:
>Vincent Fatica (vefatica@cockpit.syr.edu) wrote:
>: According to zSystem, the error occurs in _floppy_release.
>: It also occurs on dismounting /b (an ext2 floppy). Thereafter, mount says
>: it's still mounted (which it's not).
>: Vince Fatica
>Got a similar error with a 'umount -t msdos /dev/fd0 ', but I could not
>reproduce it. All I did was try and use pico on files from my 3C579
>driver disk from 3Com...nothing fancy :)
True, it happens here as well (1.1.51), but only one time after a reboot...
(I did only a mount, ls, umount and it faulted in _floppy_release)
Rob
--
=========================================================================
| Rob Janssen | AMPRnet: rob@pe1chl.ampr.org |
| e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU |
=========================================================================
------------------------------
From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: AX25 & KISS Amateur Radio Protocols in Linux??
Reply-To: pe1chl@rabo.nl
Date: Tue, 20 Sep 1994 07:58:31 GMT
In comp.os.linux.development you write:
>Rob Janssen (rob@pe1chl.ampr.org) wrote:
>: >newsgroups for example, just nasty users elsewhere... But every true
>: >hacker might find a lot of use in the HAM radio though I believe....
>: >Vassili.
>: The above is a complete misrepresentation of Amateur Radio, at least as
>: it is regulated in this part of the world (Netherlands, Europe).
>I don't think that the above is a mispresentation - simply I have an
>opinion that is different from yours... still this deosn't automatically
>mean that it's wrong...
What I expressed in my article was not my opinion (although it is similar),
but the way things are regulated over here and in many other countries.
(at least in Europe)
>: Amateur radio is a way for individuals to experiment with radio transmissions,
>: mainly for self-education and research. The exchange of information is
>The main accent in self-education and research is in the field of
>computing. The radio itself is rather obsolete and is not of much intrest
>and value these days...
A true HAM won't agree with that!
There are a lot of things in radio that are not fully understood, especially
in the area of propagation. And there is a lot still to experiment, e.g.
when you want to have a better receiver than those Japanese boxes you find
on the shelf of your HAM-radio dealer...
>: This is not at all related to "the right for free exchange of information".
>: For that purpose, there is CB radio. In that area there are no limitations
>Can you build a high speed data network wusing CB? Sure you can't...
I don't think I seggested that!
>: Ever since the inception of "packet radio" there have been greedy looks
>: from the "networking" people on the amateur radio spectrum. They see it
>: as a way to carry their traffic without having to pay excessive fees
>: to communications providers.
>Yes! It would be GREAT and would benefit the whole human race, if the
>thing like Internet can be trully free and available to individuals and
>"without having to pay excessive fees" - I think it would be very
>much along the lines under which the HAM radio was founded. It's just
>that there were NO computer networks these days....
This has nothing to do with using the Amateur radio bands for the purpose.
In fact, it can be clearly shown that there is not enough allocation for
any serious wide-use of high-speed network, and it needs to be solved
using cable/fiber technology.
>: it will be ever more difficult to keep the parts of the spectrum that
>: the commercial communications providers are interested in, because they
>: can easily point at this "unfair competition".
>Competition should serve the humanity - not vice verse. Competition
>is just a vehicle - not an aim in itself. In my opinion - commericial
>providers have unfair advantage of being able to use a spectrum - to
>no benefit of mine...
That is a nice opinion, but the commercial providers will not be happy
to abide it.
You know, the business plan of telecom providers is to "maximize the profit",
and they will not like the idea of a "competitor" that does not have a
cost factor that they do.
>If you look at HAM radio you'll see that it's
>not a technical problem to implement a high speed backbone for a packet
>network, will not take any existing spectrum (how much is spectrum
>above 1GHZ used really - if there is almost no commercial HAM equipement
>on the market for higher then 1.2 GHZ)
In Europe *there already exists* a packet backbone on 1.2 GHz. I can tell
you that it requires a lot of planning to get allocations that are not used
by the commercial guys, and even then we see ATC RADAR or Wind Profilers
appear on our frequencies. It just shows ignorance to claim that
"spectrum above 1 GHz isn't used really".
Remember that all this spectrum is only available to us on a secondary
basis, and there are others who are secondary as well or even primary.
I.e. we must accept intererence from them, or we may not even cause interference
to them.
This is not a problem when running SHF-DX on these bands, but I can tell
you it becomes a problem once you start to use the bands for permanent
links.
>: So, the limitations on information exchange via amateur radio are a good
>: thing. Don't view them as censorship, but as the regulations that make
>: amateur radio a possibility.
>Something - "let's thatnk the autorities and big companies that
>they let us mice exist" approach. I don't like this. Internet should be
>free and should be based on the free backbones. HAM radio spectrum is
>good for that. Don't use it for commericial purposes - but Linux is
>a free projet anyway. The main idea is that free software combined
>with a free backbone can really change the world. Sure there are
>always opponets to these kind of things...
Once again, you may have this opinion but it is not in line with the
definition of amateur radio by the authorities.
Also there is still another problem with the packet backbone: there
are too many free-riders. People that think that by getting an amateur
radio license they are automatically entitled to have and use a perfect
packet radio network, without helping to build or fund it.
This is the factor that prevents expansion and improvement right now.
(lack of funds, and lack of people that want to invest spare time into
improving and expanding the network)
I think that by allowing the use as a "free internet" and advertising
such use, the situation will only become worse.
Remember that a lot of the network is *hardware*, and that it does not
come for free.
Rob
--
=========================================================================
| Rob Janssen | AMPRnet: rob@pe1chl.ampr.org |
| e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU |
=========================================================================
------------------------------
From: danpop@cernapo.cern.ch (Dan Pop)
Subject: Re: Alpha Linux
Date: Tue, 20 Sep 1994 11:37:45 GMT
In <35m70t$ehe@galaxy.ucr.edu> datadec@corsa.ucr.edu (Kevin Marcus) writes:
>Actually, the Alpha suffers significant performance penalties when dealing
>with 32 bit vs. 64 bit quantities. (Yet another reason NT is slow on
>the lower end Alpha's).
Which explains why all the machine code instructions on Alpha are 32
bits :-)
Before posting nonsense, please check your facts. Alpha supports both
32 and 64 bit memory access. It doesn't support byte access, however.
Dan
--
Dan Pop
CERN, CN Division
Email: danpop@cernapo.cern.ch
Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland
------------------------------
From: gat@robotics.jpl.nasa.gov (Erann Gat)
Subject: Wanted: binary only gcc with pentium optimizations
Date: Tue, 20 Sep 1994 14:58:16 -0800
Does anyone have the Intel gcc with P5 optimizations in a binary-only
distribution that I could snarf? I don't have enough disk space to
compile it myself.
Many thanks!
E.
--
Erann Gat
gat@robotics.jpl.nasa.gov
------------------------------
From: hta@uninett.no (Harald T. Alvestrand)
Subject: Re: TCP incoming services hang with 1.1.5x
Date: 20 Sep 1994 11:56:41 GMT
Watch your logs....
once I broke something similar on a SUN.
Turned out that I had added a BLANK LINE to the end of /etc/inetd.conf,
which resulted in inetd being unable to parse its config file, which
resulted in *all* incoming services going down.
Only symptom was a message in /var/adm/messages.
Boy, was I glad that I hadn't logged out yet....
--
Harald Tveit Alvestrand
Harald.T.Alvestrand@uninett.no
G=Harald;I=T;S=Alvestrand;O=uninett;P=uninett;C=no
+47 73 59 70 94
My son's name is Torbj<62>rn. The letter between "j" and "r" is o with a slash.
------------------------------
From: evansmp@mb4715.aston.ac.uk (Mark Evans)
Subject: Re: X.25 support ....exist ?
Date: Tue, 20 Sep 1994 14:34:01 GMT
paolo bertona (bertop@c700-1.sm.dsi.unimi.it) wrote:
: I am searching for some support for X.25 cards
: under Linux, can somebody help me ?
The only X25 support is the AX25 written by Alan Cox,
You might like to look at this code for ideas, I
suspect you will find that things like the HDLC
management you can leave to the hardware.
------------------------------
From: wang_x@sis.bms.com
Subject: Buslogic BT946C Supported by Linux?
Date: Tue, 20 Sep 94 05:13:23 GMT
Hello,
Could someone please tell me if the Buslogic BT946C PCI/SCSI card is now
supported by Linux?
Thanks very much in advance,
Xuebao Wang
------------------------------
From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: Kernel Goals?
Reply-To: pe1chl@rabo.nl
Date: Tue, 20 Sep 1994 22:20:00 GMT
In <35mdh3$4rd@gate.noris.de> urlichs@smurf.noris.de (Matthias Urlichs) writes:
>Maybe the best way to do this is to just ignore the patchlevel if the minor
>version number is even. There'd be still a 1.1.47 driver, but the 1.2
>driver would work regardless of whether you have 1.2.0 or 1.2.34.
>On the other hand, people with development kernels can be expected to
>recompile their modules. But this isn't necessary for "stable" kernels,
>as persumably their patches fix bugs instead of fiddling with data
>structures.
>Opinions?
I still think it is better to go for a program-generated signature which
is (by convention) stored as the first member of every kernel data structure,
and which is guaranteed to change whenever something is changed in the
structure. (it could, for example, be generated from compiler debug info)
This provides a safe check for everyone who wants to check, not only
modules. I.e. any kernel routine can check if there is really a
valid "struct xx" at the "struct xx *p" it is manipulating.
Something like this was done in the new serial routines, but it uses
manually-generated signatures. Automatic ones would have the advantage
of guaranteed, non-ambiguous change. (even in the presence of multiple
patches to the same datastructure)
The disadvantage can be that sometimes a module is declared incompatible
because of a change unimportant to that module...
Rob
--
=========================================================================
| Rob Janssen | AMPRnet: rob@pe1chl.ampr.org |
| e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU |
=========================================================================
------------------------------
From: dhinds@allegro.stanford.edu (David Hinds)
Subject: Re: Alpha Linux
Date: 20 Sep 1994 23:03:38 GMT
Kevin Marcus (datadec@corsa.ucr.edu) wrote:
: Actually, the Alpha suffers significant performance penalties when dealing
: with 32 bit vs. 64 bit quantities. (Yet another reason NT is slow on
: the lower end Alpha's).
Are you sure about this? In my experience, on 64 bit architectures
(like MIPS R4x00, IBM POWER, Alpha, etc) using 32 bit quantities is
often significantly faster than going with the full 64 bits, probably
due to better cache utilization.
-- David Hinds
dhinds@allegro.stanford.edu
------------------------------
Crossposted-To: comp.os.linux.admin
From: brennerc@saucer.cc.umr.edu (Corey Brenner)
Subject: Re: What user interface to use???
Date: Tue, 20 Sep 1994 23:23:57 GMT
Tony Schwartz (tony@teleport.com) wrote:
: When do dial into your local ISP using a standard terminal connection, what
: software is used to providet the menuing, ability to do internet functions
: like telnet, ftp, gopher, etc???
: Recommendations please and locations on obtaining these....
: Thanks
: Tony Schwartz
I would go the dip route. It provides SLIP which is, in my experience, a bit
more stable than ppp in the later kernels. This will work only if your
Internet Service Provider allows slip connections. Menuing is handled by some
funky DOS client ( :) ). Using your system as just another node on the 'net
will make you very happy.
Corey Brenner
------------------------------
From: nickkral@po.EECS.Berkeley.EDU (Nick Kralevich)
Subject: 1.1.51 Adaptec 1542 SCSI problems
Date: 19 Sep 1994 08:40:54 GMT
I just tried compiling 1.1.51 for my computer. There was no problem
compiling, but when I tried using my system, the SCSI subsystem
became unstable, causing lots of "interrupt received, but no mail"
messages, with other messages regarding problems with
delay timeouts, etc. None of these problems occured with 1.1.50,
so I'm guessing that there is a problem in 1.1.51.
Of course, I've only had the SCSI adaptor for a week now, so
I don't have a lot of experience with this. But 1.1.50 worked
great, 1.1.51 locks up.
A downgrade to 1.1.50 solved my problems.
Anyone else having problems?
Take care,
-- Nick Kralevich
nickkral@cory.eecs.berkeley.edu
--
Nick Kralevich nickkral@cory.eecs.berkeley.edu
"A man sits with a pretty girl for an hour and it seems shorter than
a minute. But tell that same man to sit on a hot stove for a minute,
it is longer than any hour. That's relativity." -- Einstein
------------------------------
From: gert@greenie.muc.de (Gert Doering)
Subject: Re: Looking for a Fax daemon
Date: Tue, 20 Sep 1994 14:26:47 GMT
rjl@davinci.renaissoft.com (Robert J. LeBlanc) writes:
>>>I was just wondering if somebody had already either started or had completed
>>>a fax server for linux and, of course, if so, would you know the location
>>>of where it might be?
>>Try "efax". It's a simple fax program for one machine.
>>It runs as a daemon, and upon receiving an incoming call,
>>if it is a fax, it receives it (and prints it if you want)
>>and saves it as a file. If the call is a data call, it
>>can call another program to handle it.
>If it's a fax SERVER you're looking for, both FlexFAX (at sgi.com) and
>efax can do the job, though if you opt for efax you should add the
>Qfax utility suite (both can be found on sunsite.unc.edu), which turns
>efax into a server. Try /pub/Linux/apps/comm, or /pub/Linux/Incoming
>on sunsite, for qfax1.0.tar.gz and efax06a.tar.gz.
Well, if you list all those, you should not omit mgetty+sendfax, which is
very well suited for LOTS of incoming traffic, and moderate to medium
outgoing traffic.
BUT: mgetty+sendfax is not meant to be used as a network fax sender, that
is, there is no remote spooling mechanism (yet). But then, Efax doesn't
have one either...
gert
--
Yield to temptation ... it may not pass your way again! -- Lazarus Long
//www.muc.de/~gert
Gert Doering - Munich, Germany gert@greenie.muc.de
fax: +49-89-3243328 gert.doering@physik.tu-muenchen.de
------------------------------
Crossposted-To: comp.protocols.tcp-ip
From: gert@greenie.muc.de (Gert Doering)
Subject: Re: Extending the IP Protocol?
Date: Tue, 20 Sep 1994 14:32:16 GMT
slouken@cs.ucdavis.edu (Sam Oscar Lantinga) writes:
> Complex, I admit, but I'm not sure of any other way
>to acomplish having my machine on the SLIP connection also appearing
>on the network at work.
Why not simply using Proxy ARP on the SLIP server? Sounds a lot easier +
faster.
gert
--
Yield to temptation ... it may not pass your way again! -- Lazarus Long
//www.muc.de/~gert
Gert Doering - Munich, Germany gert@greenie.muc.de
fax: +49-89-3243328 gert.doering@physik.tu-muenchen.de
------------------------------
From: davem@er4.rutgers.edu (David Miller)
Subject: Re: 1.1.51 seg fault on shutdown in _floppy_release
Date: 20 Sep 1994 10:40:52 -0400
Andries Brouwer (aeb@cwi.nl) wrote:
: rob@pe1chl.ampr.org (Rob Janssen) writes:
: : STEVO@acad.ursinus.edu (Steve Kneizys) writes:
: ::Vincent Fatica (vefatica@cockpit.syr.edu) wrote:
: ::: According to zSystem, the error occurs in _floppy_release.
: ::: It also occurs on dismounting /b (an ext2 floppy). Thereafter, mount says
: ::: it's still mounted (which it's not).
: ::Got a similar error with a 'umount -t msdos /dev/fd0 ', but I could not
: ::reproduce it. All I did was try and use pico on files from my 3C579
: ::driver disk from 3Com...nothing fancy :)
: :True, it happens here as well (1.1.51), but only one time after a reboot...
: :(I did only a mount, ls, umount and it faulted in _floppy_release)
: I got the same error yesterday evening. The routine floppy_release
: is called by the umount code with NULL as second argument (filp)
: and dereferences that. I posted a fix yesterday evening on the Kernel
: channel (something like: if(!filp || (filp->f_mode & 2)) ...).
If you look in your /var/adm/kernlog, you'll see a nice "OOPS" there
also, the code is referenceing a kernel NULL pointer :-) Thank god for
qmagic!
Later,
David S. Miller
davem@eden.rutgers.edu
------------------------------
** 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
******************************