Subject: Linux-Development Digest #149
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Sat, 10 Sep 94 11:13:05 EDT

Linux-Development Digest #149, Volume #2         Sat, 10 Sep 94 11:13:05 EDT

Contents:
  Re: Linux for DEC Alpha platform? (Peter Hahn)
  Re: hdparm.c and/or new fast-IDE won't work now! (R. Andrew Reynolds)
  Error repeated! (was: ext2fs corruption...) (Vesa Vainio)
  atdisk2 and E-IDE (Theo Scott)
  Re: Anyone working on ISDN card drivers ?? (Rob Janssen)
  X-Server for S3 Vision 964 (Helmut Oertel)
  Re: Future of linux -- the sequel (Shannon Hendrix)
  Linux Kernel's and ATDISK-Patches (Michael Knigge)
  Re: [Q] on Linux/MIPS port (Ralf Baechle)
  Re: Future of linux -- the sequel (Ralf Baechle)
  Re: Survey: who wants f77,cc,c++,hpf for linux? (Highlander)
  Re: Alpha Linux (Kjetil Torgrim Homme)
  Re: Alpha Linux (Ralf Baechle)
  Re: Developing Distributed Filesystems for Linux? (Tony Peterman)
  Re: How to use diff (Shawn Hsiao)
  Re: Alpha Linux (James Logajan)
  IP encapsulated in IPX can linux extract IP  (Norm Walker)
  NFSD debug logging error ("Stephen Davies")

----------------------------------------------------------------------------

From: [email-masked] (Peter Hahn)
Subject: Re: Linux for DEC Alpha platform?
Date: Fri, 9 Sep 1994 08:03:39 GMT

[email-masked] (Donald Becker) writes:

>In article <[email-masked]>,
>Hamish Macdonald <[email-masked]> wrote:
>>>>>>> On 29 Aug 1994 08:14:02 EST,
>>>>>>> In message <[email-masked]>,
>>>>>>> [email-masked] (Ralf Baechle) wrote:
>>
>>Ralf> Expect Linux to be available for all major CPU families in the
>>Ralf> near future.
>>
>>Ralf, you and I both know that the big work in a Linux port is not so
>>much the CPU specific stuff, but the device drivers.
>>
>>As such, only expect Linux to work on PC clones (powered by various
>>ALPHA, x86, MIPS chips) in the *near* future.

>Both the PowerPC/PREP and the Alpha are promoted as using the PCI bus.
>Picking the three major devices I consider necessary for a system: disk,
>network, and video controllers, I see that x86 Linux is close to supporting
>PCI bus versions of all three.  I'm only intimately familiar with network
>device driver, but I don't think it would take very long to convert it to a
>different processor once I know I knew a few details, such as the I/O space
>mapping.  Perhaps most of the changes will be just converting the ASM
>in*()/out*() functions to memory operations, and checking for byte-sex
>problems.

>The remaining essential device drivers to be written are for the
>keyboard/mouse port, PCI bus bridge/controller, and perhaps a PCMCIA bus
>bridge.  None are trivial, but getting close to having something working is
>highly motivating...

As I understand the PCI specification you can build a bare motherboard with
a SCSI interface chip, a PCI to isa bridge, some timers/clocks and four PCI
connectors. Slow I/O devices as mouse, keyboard, serial and Ethernet are
linked via the additional isa bus slots as usual. Now we plug in a PCI
graphics card and a CPU module and our system runs. We even have two slots
left.

  This would be the ideal board to give the CPU manufactures good
competition. And porting is as easy as possible, as you only have to port
the parts dependig on the CPU module. I don't want to mention the
upgradability this solution provides.

  I don't know, if someone offers such a board, though :(

Peter
-- 
Peter Hahn                                                         Peterstr. 26
     52062 Aachen                                                Germany
          [email-masked]   [email-masked]
                             Voice: +49 241 37151

------------------------------

From: [email-masked] (R. Andrew Reynolds)
Subject: Re: hdparm.c and/or new fast-IDE won't work now!
Date: Sat, 10 Sep 1994 10:01:07 GMT

Mark Lord ([email-masked]) wrote:
: In article <[email-masked]> [email-masked] writes:
: >
: >I'm having a problem with hdparm as well. I invoke hdparm -m16 /dev/hda,
: >and I get this message:
: >/dev/hda:
: > setting mult-count to 16
: > multcount = 16
: >
: >But when I read /var/adm/messages, I came across this:
: >
: >Sep  6 06:53:05 reynolds kernel:   hda: enabled 16-sector multiple mode
: >Sep  6 06:53:05 reynolds kernel: hda: multwrite_intr: status = 0xd0
: >Sep  6 06:53:05 reynolds last message repeated 7 times
: >Sep  6 06:53:05 reynolds kernel: hda: reset multiple mode to 0
: >
: >I quite sure that my system can do 16-sector multiple mode, because I've had
: >great success with similar shareware programs for Messy-DOS. The hard drive
: >subsystem is a Conner CP3044 IDE drive, hooked up to a generic 16 bit
: >Super I/O card. Any suggestions would be appreciated. (-:

: As noted in the documentation, some CONNER drives have problems.

: Try it with a smaller setting, such as:  hdparm -m8 /dev/hda
: Also, try with irq-unmasking off (default:  hdparm -u0 -m8 /dev/hda

: -- 
: [email-masked]  Mark Lord       BNR Ottawa,Canada       613-763-7482

Thanks, I'll give that a try. (-:

--
Andrew Reynolds | [email-masked] [email-masked] | "400=400"
Dalhousie CS    |  "I'm just a guppy in a sea of sharks."  | -L. Rolston, 1992

------------------------------

From: [email-masked] (Vesa Vainio)
Subject: Error repeated! (was: ext2fs corruption...)
Date: 10 Sep 94 11:02:31 GMT

I succeeded in repeating the error.. (files corrupting mostly during
heavy disk activity. File length not changing, but about 8 bytes
having bit inversions..)
 
So, I have two files of the same length, the other one is uncorrupted
and the other one is corrupted. This IS a real-life example unlike the
one I had improvised, that I posted about a week ago..
 
Now, what do I need to do to get the right people look at the problem?
I might transfer the files somewhere, or I might extract the needed offset
myself, if I get proper instructions on how to do it.

--
  Vesa Vainio        email: [email-masked]       Location: Finland, Espoo

------------------------------

From: [email-masked] (Theo Scott)
Subject: atdisk2 and E-IDE
Date: Sat, 10 Sep 1994 09:55:13 GMT

Hi,

I've got a 2nd IDE controller (with a drive) on IRQ-15. 
I've apllied the patch and it worked but only with a drive with <= 16 heads
The one drive that I want to use is a Conner with 17 heads.
I saw in the "hd.c"  that Mark Lord made some inprovements so that 
1st Controller can use a drive with >16 heads. Does anyone knows of
a patch for "hd1.c" ? The patch for using >16 heads on "hd.c" would
be fine to. Any ftp sites ?

Thanks
Theo
 
:wq   Oops, there's no vi editor for this DOS !
     +-----------------------------------------------------------------+
     |    Theo Scott                      Dept. Computer Science       |
     |    Tel: +27 +148 +99-2531          Potchefstroom University     |
     +-----------------------------------------------------------------+
     |  DOS  = Can't live with it, but can't kill it.                  |
     |  UNIX = DOS - "Can't live with it" + RISC - CISC -64k + TCP +   |
     |         ICMP + NNTP + UDP + C - "System mostly hangs" + NFS +   |
     |         core + ...                                              |
     +-----------------------------------------------------------------+

------------------------------

From: [email-masked] (Rob Janssen)
Subject: Re: Anyone working on ISDN card drivers ??
Reply-To: [email-masked]
Date: Sat, 10 Sep 1994 08:38:42 GMT

In <[email-masked]> [email-masked] (Mihail S. Iotov) writes:

>[email-masked] (Matthew S. Crocker) writes:

>>Only we are using a CISCO 2501 router to handle our IP feed (T1).
>>Putting 64-128k through the ISA bus would be murder on interrupts
>>(even for the P5-90 we have here...)

>Are you sure about this one ? The IDE drive regularly puts 4Mbps on the ISA
>bus. 

It does not do interrupt-per-byte.  Of course, a decent 64-128k serial
card would not do that, either.

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   [email-masked]           |
| e-mail: [email-masked]     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

------------------------------

From: [email-masked] (Helmut Oertel)
Crossposted-To: comp.os.linux.help
Subject: X-Server for S3 Vision 964
Date: 10 Sep 1994 12:40:08 GMT

Hi,

is there an X-Server (or patch of the current S3-Server) for an
S3 Vision 964 based graphics card available?
I am using the Elsa Winner 2000Pro H.

The current S3-Server does not recognize the card's chip-ID,
is it possible to override this check?

bye,

       WWW
      (O O)
--oOO--(_)--OOo--------
Helmut Oertel                   | Technical University of Berlin, Germany
E-Mail: [email-masked] | NeXT-Mail: [email-masked]
Compuserve: 100326,41           | WWW: http://www.cs.tu-berlin.de/~oertelh
Tel.: +49-30-304 33 52          | FAX : +49-30-305 90 89

------------------------------

From: [email-masked] (Shannon Hendrix)
Subject: Re: Future of linux -- the sequel
Date: Thu, 8 Sep 1994 05:06:15 GMT

[email-masked] (Larry Pyeatt) writes:

>|> Yes you can.  The point was that the prices for the individual parts
>|> listed in the Pentium system were far more than what they actually cost.
>|> The $6400 Pentium listed would be more like $2700 to anyone that knows
>|> where to look and I don't mean getting low-quality either.

>In that case I should pay you $300 to buy my next computer for me.
>You already have the specs.  8) Tell me about your $2700 system and
>I will tell you why it does not compare to a typical low-end 
>workstation.

The point is that the listed prices are way over what they really cost.

My little ISA bus 486 has little trouble besting low-end workstations
in anything (Sun 4/110's and Sparcstation 1's).  It will do some integer
ops faster than a Sun 2.  The Sun 2's FPU will eat mine alive but for
$10000 it should beat it on *ALL* counts.  It doesn't.

A typical workstation equal to my 486 box would cost enough for me to
buy two 486's just like mine and I'd have money left over for the latest
Linux Developer's CD.

I'd love to have a workstation but given that by the time I can afford
one there will be little or no difference between a PC and a workstation
(as if there really is one now) so who cares?  Workstations are generally
overpriced still.  Software for them is even worse.
-- 
csh
===========================================================================
[email-masked]      | Linux and BSD

------------------------------

From: [email-masked] (Michael Knigge)
Subject: Linux Kernel's and ATDISK-Patches
Date: Wed, 7 Sep 1994 07:57:57 GMT

Hello....

Will the atdisk-Patch (up to four IDE-Drives) be "standard" in the next
Linux-Releases? I hope so because I need them and the Patch works without
any Problems.....

Bye
  Michael
-- 
    -----------------------------------------------------------------------
   ---  Michael Knigge                         eMail: [email-masked]  ---
    -----------------------------------------------------------------------

------------------------------

From: [email-masked] (Ralf Baechle)
Subject: Re: [Q] on Linux/MIPS port
Date: 9 Sep 1994 13:58:24 GMT

|> While I agree that DECstation 3100s and 5000s would be a nice target for
|> Linux (after all, DEC is dumping their MIPS-based machines in favor of 
|> Alphas so they should be available cheap used, but the 5000s at least
|> are still a good bit faster than 486s), it won't be that easy.  I think
|> the MIPS/Linux project which you heard of is to port to a system with
|> a MIPS CPU but which is otherwise a PC-- ie, EISA or PCI bus, and same
|> old PC peripherals you're used to.  The DECstations, on the other hand,
|> use an entirely different bus (TurboChannel) and different boards which
|> plug into that bus.  So it could be done (of course) but you would end
|> up having to write drivers for the bus, the SCSI adapter, the video
|> board, and so on.  Basically everything, all over again.  For a machine
|> which has been discontinued, perhaps it's not worth it, unless someone who
|> has a _lot_ of them already does it and the rest of us can benefit ;-).

The technical information that I have about the DEC MIPS machines is exactly
nothing except that I know the endianess and the CPU type. However it is
reasonable to make the assumption about the DEC machines/TurboChannel that
they both mostly use chips which are being used in other types of machines,
too. If that assumption is true porting of the board depended part of Linux
should be quite easy. Furthermore I tried not to use R4x00 specials where ever possible without performance penalty. This should make porting to R3000
type machines easier, too. If a MACH or NetBSD port should be available for
the DEC machines this could deliver lots of helpful sources, too.

From the impression that I have there are lots of these DEC machines out
there. Nearly at the same time at which we announced our Linux port users of
DEC machines started asking about support for their machines. But from the
experience that I have with the Linux/68k port from Amiga to Atari I expect that it might take months to find someone to volunteer for some weeks of
work :-(

I hope I could motivate some DEC owners/users/hackers to port Linux to the
DEC architecture!

  Ralf

------------------------------

From: [email-masked] (Ralf Baechle)
Subject: Re: Future of linux -- the sequel
Date: 9 Sep 1994 14:22:56 GMT

In article <[email-masked]>, [email-masked] (Vicky.Barbe) writes:
|> In article [email-masked], [email-masked] (Rob Janssen) writes:
|> > In <[email-masked]> [email-masked] (Erik Fortune) writes:
|> > 
|> > However, this is not what the thread is all about.  The point is that the
|> > original statement that an Indy makes a Pentium feel like a 4.77MHz XT
|> > was a gross exaggeration, and that still stands.  The memo only shows that
|> > SGI has had performance problems as well.  It would be a real feat when
|> > the difference between 5.1 and 5.2 was between something that is too
|> > slow to work with and something that is 50 times as fast as a Pentium,
|> > but I *really doubt* this is the case.

|> No, err, the point actually was that Linux is getting so large it is
|> becoming unhandy : 1.66 megabytes doesn't even fit on one floppy anymore !
|> Cut the bull and throw away all but the most necessary drivers, let the
|> owners get their drivers off the net if they want !  It's okay to put
|> all the drivers into the distributions, but I don't want them when I upgrade
|> my kernel.  Most kernel work isn't kernel but driver work these days.

Yes, and how fortunate - even Linus' biggest patches fit on an old double density disk. But who still uses disks anyway... And since this thread is some how MIPS related I think I should use the oportunity that the MIPS port - at least for the Deskstation Tyne boards - will only blow up the kernel sources by some hundred kilobytes (unpacked). So I don't think that there will be an argument to discuss "kernel bloat" - especially since the efficiency
in both speed and size of the Intel-kernel won't be affected.

|> And I'm not proposing holy wars against Intel architecture, I just said that
|> Linux is perhaps a bit too depending on it.  I know that to build an OS that
|> runs on a lot of different architectures (with or without recompiling), you
|> have got to write a new OS and put Linux on top, so forget about that for
|> a moment.

You can use that way if you have decided to build an portable OS before you actually start to write one. Unfortunately for Linux the other way has been choosen. The final result is just the same.

|>            But all those drivers ...  I don't want to spend 6 megabytes of
|> my hard disk for just the sources of yet another cdrom or scsi or ethernet
|> device.

Many non-Intel systems use either ISA, EISA or PCI cards. This enables them to use nearly the same drivers like Intel bases systems do. Many other use the same chips. So don't expect lots more drivers for the near future. About CDROMs - most systems need only one CDROM driver, the SCSI CDROM driver. Blame the PC soundcard industry for inventing lots of highly driver compatible CDROM "standards".

  Ralf

------------------------------

From: [email-masked] (Highlander)
Crossposted-To: comp.lang.fortran
Subject: Re: Survey: who wants f77,cc,c++,hpf for linux?
Date: 9 Sep 1994 18:41:08 GMT

In article <[email-masked]>, Dan Pop <[email-masked]> wrote:
>In <[email-masked]> [email-masked] (Ray Hann) writes:
>
>>benchmarks by 3 fold.  But then again I have found on some of my own
>>scientific codes that f2c+gcc produces code that actually executes faster
>>than that of the Sun F77 compiler.
>
>Looks like you're comparing apples with oranges here, unless you were
>using the Sun F77 compiler on the same PC, of course (Solaris is available
>for PC hardware).

Uh, it is possible to run f2c+gcc in place of f77 on platforms besides
Linux, just not adviseable except for benchmarking purposes.  He could
have compared the two on a Sun or SGI or RS/6000 or <your favorite
workstation with C and FORTRAN compilers here>...

        --Troy
+--------------------+------------------------------------------------+
|   Troy A. Baer     | "My soul is painted like wings of butterflies, |
| Senior, Aero. Engr.|  Fairy tales of yesterday, grow but never die, |
| DOS?!? Try Linux!! |  I can fly, my friends!"  --Brian May          |
+--------------------+------------------------------------------------+

------------------------------

From: [email-masked] (Kjetil Torgrim Homme)
Crossposted-To: comp.lang.c
Subject: Re: Alpha Linux
Date: 10 Sep 1994 13:38:21 GMT

+--- Richard Coleman:
| I've always thought that C should have some way of letting you
| decided how many bytes to use for your computation.

I once saw someone on Usenet suggest this convention:

  int8, int16, int32, ...:
     Variables that should be exactly this size.
  int8u, int16u, int32u, ...:
     Variables that can be larger to increase speed. Many machines
     would have a 32-bit int16u.

In addition, you'd want unsigned versions like "uint8" etc.

Kjetil T.

------------------------------

From: [email-masked] (Ralf Baechle)
Subject: Re: Alpha Linux
Date: 9 Sep 1994 14:29:44 GMT

|> : Why drop one? 
|> : 16 bits = short int
|> : 32 bits = int
|> : 64 bits = long
|> 
|>  128 bits = long long   :)

Try -mlonglong128 which should be working for MIPS with gcc >= 2.6.0 :-)

  Ralf

------------------------------

Crossposted-To: alt.filesystems.afs
From: [email-masked] (Tony Peterman)
Subject: Re: Developing Distributed Filesystems for Linux?
Date: Sat, 10 Sep 1994 03:46:39 GMT

[email-masked] (Lincoln Myers) writes:

>I've been reading the AFS FAQ and other reports (available from
>grand.central.org:/pub/*) about AFS (formerly the Andrew File System) and
>DFS (the DEcorum File System, part of DCE) both of which are commercially
>available filesystems which are generally faster, more secure, and easier to
>manage than NFS, especially over large networks.

>Is anyone working on a filesystem for Linux or another freely available UN*X
>which will offer the advantages that these do?

>AFS was a project at CMU before it became a commercial product supported by
>Transarc.  Would it be feasable to port an earlier version (pre-3.0?) to
>Linux?  (Is it freely available?  Would it be compatible with current AFS?
>Would one want to use it?)

>If not, would it be possible to make a freely available implementation of
>AFS or DFS for Linux, without infringing on their current owner's
>(Transarc's) rights?  Is there enough information out there?

>I would be willing to help develop something like this if there is any
>demand.

>Lincoln

 I would be willing to work on something like this as well.

 Tony G. Peterman
-- 
_______________________________________________________________________________
Automata Consulting                      | P.O. Box 260798
Specializing in Network Development.     | Plano, Tx. 75023-0798
Unix/C/C++                               | (214)532-6063
Unix Internals                           | [email-masked]
_________________________________________|_____________________________________

------------------------------

From: [email-masked] (Shawn Hsiao)
Subject: Re: How to use diff
Date: 09 Sep 1994 10:05:00 GMT

In article <[email-masked]> [email-masked] (Tracy R. Reed) writes:

   I need to know how to use diff to make a patch. I manually applied the 
   1.1.18 accounting patch to 1.1.49 because the diffs didn't work out quite 
   right. I would now like to make a new diff so I don't have to do it by 
   hand again. I saved the old kernel in /usr/src/linux-old and the new 
   kernel is in /usr/src/linux. Can someone give me the diff command to 
   compare these to directories and make a patch? My installation doesn't 
   have a manual page for diff for some reason. I'll make the patch 
   available to anyone who wants it.

type `diff' in your command line, it'll show you how to use it (at least
mine do). Anyway, I'll quote the message to you.

The simplest way to use diff(the way I do), 

  `diff -ur <from-dir> <to-dir> > <patch-file>'

--
// Shawn

                        E-mail: [email-masked]

------------------------------

From: [email-masked] (James Logajan)
Subject: Re: Alpha Linux
Reply-To: [email-masked]
Date: Sat, 10 Sep 1994 04:36:51 GMT

In article <[email-masked]>, [email-masked] (Richard Coleman) writes:
> I've always thought that C should have some way
> of letting you decided how many bytes to use
> for your computation.  It could be as simple as
> having the types
> 
> int8   ( = char )
> int16  ( = short )
> int24
> int32  ( = int )
> ...

I second that motion. It is time people stopped kidding themselves and
realize that 'C' and 'C++' are really just turbo-charged assembly
languages. It seems absurd that after 20+ years we still deal with
address pointer arithmetic so much in complex applications. The idea that
the "size" of our base types is somehow "configurable" really just adds
an uneeded complexity. And these synonyms could be added into the language
without too much difficulty.

------------------------------

From: [email-masked] (Norm Walker)
Subject: IP encapsulated in IPX can linux extract IP 
Date: Sat, 10 Sep 1994 01:17:07 GMT

I have been setting up a linux machine to act as an internet host
on a novell network and got ip and tcp up sharing the ethernet
now we have several segments on different hardware that we
would also like to have access to the linux box.
the problem is that the packets reach the novell server 
and it does not know that they are for the linux box on the other
network card so it tosses it.
I found a program for novell that will encapsulate the ip packets
in ipx packets. the packets will get to the linux box but
it tosses them because they are not ip packets 
If I knew enough about the network code in linux I would
be able to strip the ipx header and have an IP packet

any sugestions?
-- 
Merritt Secondary School - Computer Support Teacher

------------------------------

From: "Stephen Davies" <[email-masked]>
Subject: NFSD debug logging error
Date: Sat, 10 Sep 94 18:39:46 PDT

I am trying to debug a problem with a PC-based NFS client to NFSD on
Linux and have noticed that the output from log_call in logging.c does
not appear in /var/log as expected.

At line 136 of logging.c is the following:

dprintf(1, "%s]\n\t%s\n", buff, arg);

The output in my log includes the contents of buff but not of arg;
which, of course, is what I wish to see.

I have searched the code but am blind to the reason for this.

The problem I am trying to solve is why some mounts fail the tests
after line 92 in mountd.c and return NFSERR_ACCES or NFSERR_NOTDIR.
(I would also be interseted to know why this code allows one to
mount a file as well as a directory.)

Thanks for any help.

Stephen.

========================================================================
Stephen Davies Consulting                              [email-masked]
Adelaide, South Australia.                           Voice: 61-8-2728863
Computing & Network solutions.                       Fax  : 61-8-2741015

------------------------------

** 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: [email-masked]

You can send mail to the entire list (and comp.os.linux.development) via:

    Internet: [email-masked]

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
******************************