Subject: Linux-Development Digest #972
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:     Mon, 1 Aug 94 12:13:11 EDT

Linux-Development Digest #972, Volume #1          Mon, 1 Aug 94 12:13:11 EDT

Contents:
  Re: mounting DOS diskette fails under 1.1.36 (S.G. de Bruijn)
  Re: Park Routine for old RLL/MFM drives (Gary Paul Gortmaker)
  1.1.37 won't boot! (multiple sector prob?) (Mike Dowling)
  OS/2's FAT partition under Linux (Chris Lo)
  Re: threads in kernel (Rob Janssen)
  Re: Linux backup of MSDOS? (Rob Janssen)
  Re: patching scsi (Rob Janssen)
  Re: Fatal Signal 11 - reproduceable ! (Rob Janssen)
  Re: Does the Adaptec 2940 SCSI driver exists ? (Rob Janssen)
  Re: kernel stupidity... (Rob Janssen)
  Re: 1.1.37 won't boot! False alarm! (Mike Dowling)
  Re: Fatal Signal 11  - reproduceable ! (Ian Jackson)
  Re: Windows swap/bdflush/1.1.3x (Rex Dieter)
  Re: [hd] Do you recognize this error message? (David Monro)
  Re: console driver does not reset char table with "stty sane" (David Monro)
  SEGV, but no core dumped. Why? (Stuart Cunningham)
  Re: Large malloc problems (nick leroy)
  PLIP problems solved! (mostly...) (ddelsig@uoft02.utoledo.edu)
  SA400 format floppies possible? (David Monro)

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

From: debruijn@cs.utwente.nl (S.G. de Bruijn)
Subject: Re: mounting DOS diskette fails under 1.1.36
Date: Mon, 1 Aug 1994 11:08:47 GMT

Joe George (jgeorge@nbi.com) wrote:
: urlichs@smurf.noris.de (Matthias Urlichs) writes:

: >In comp.os.linux.development, article <1994Jul28.111458.147@hhdo.ping.de>,
: >  hh@hhdo.ping.de (Henning Holtschneider) writes:
: >> 
: >>        mount: block device /dev/fd0 is not permitted on its filesystem

: >Bah. Linus (plus whoever is responsible for mount), please fix that message,
: >if for no other reason than to stop all these questions rolling in..!

: It's not Linus's message, that's the response that mount gives to the
: -EACCES error the kernel returns to mount. I would guess (or hope?) that the
: next version of mount in Rik Faith's utilities will change that message.

I think your floppy is read-only, and mount tries read-write
mode. This is--of course--not permitted, resulting in a very
non-understandable error message. I has precisely this message
when trying to mount a cdrom filesystem, until I fed mount the 
'-o ro' option (readonly mount)

Cheers,
Steef
==============
S.G. de Bruijn              E-Mail: debruijn@cs.utwente.nl
Twente University of Technology, Dept. of Computer Science 
Enschede                                   The Netherlands
Phone: Work: +53 894191                   Home: +53 334812
=========================== @@ ===========================
signature: file not found

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

From: gpg109@huxley.anu.edu.au (Gary Paul Gortmaker)
Crossposted-To: comp.lang.c
Subject: Re: Park Routine for old RLL/MFM drives
Date: 29 Jul 1994 16:40:58 +1000

robinson@ichips.intel.com (David Lyle Robinson) writes:


>Does anyone know how to do this in C under Linux?

...look at the program Donald wrote to spin down IDE drives, as this
would be a good start.

Paul.

=======================================================================

/*
 *  diskdown.c: Shut down a IDE disk if there is no activity.
 *  Written by Donald Becker (becker@cesdis.gsfc.nasa.gov) for Linux.
 */

#include <unistd.h>
#include <stdio.h>
#include <asm/io.h>

#define IDE_BASE        0x1f0
#define IDE_SECTOR_CNT  0x1f2
#define IDE_CMD         0x1f7
#define PORTIO_ON       1

enum ide_cmd {StandbyImmediate=0xe0, IdleImmediate=0xe1, StandbyTimer=0xe2,
          IdleTimer=0xe3,};

main(int argc, char *argv[])
{
    int timeout;

    if (ioperm(IDE_BASE, 8, PORTIO_ON)) {
        perror("diskdown:ioperm()");
        fprintf(stderr, "diskdown: You must run this program as root.\n");
        return 1;
    }

    if (argc > 1) {
        timeout = atoi(argv[1]);
        if (timeout < 10)
            timeout = 10;
    }
    
    {
        int old_cnt = inb(IDE_SECTOR_CNT);
        printf("Old sector count: %d.\n", old_cnt);
        outb((timeout + 4)/5,IDE_SECTOR_CNT);
        outb(StandbyTimer, IDE_CMD);
        outb(old_cnt,IDE_SECTOR_CNT);
    }

    return 0;
}

/*
 * Local variables:
 * compile-command: "gcc -O6 -o diskdown diskdown.c"
 * comment-column: 32
 * End:
 */

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

From: mike@MooCow.math.nat.tu-bs.de (Mike Dowling)
Subject: 1.1.37 won't boot! (multiple sector prob?)
Reply-To: on.dowling@zib-berlin.de
Date: Mon, 1 Aug 1994 11:34:39 GMT

For the first time in God knows how long I've finally had a problem booting a
new kernel.

I have an IDE disk and have enabled the multiple sector facility as is
described in /usr/src/linux/drivers/block/README.hd.  I also told the kernel to
print the extra info about the disk on booting.  Immediately after this info
appears on the screen, I get the single line,

insert_vm_struct: ins area 0-3000 in area 0-30000

and the systen hangs.

                
--
                        Mike Dowling

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

From: cklo@hkucs92.air.org (Chris Lo)
Subject: OS/2's FAT partition under Linux
Date: Mon, 1 Aug 1994 00:22:15 GMT
Reply-To: cklo@hkucs92.air.org

Hello,

I get the weird output from ls on the dos partition, which has OS/2 installed.
My kernel version is 1.1.37...

ls: eadata.sfp: No such file or directory
ls: wproot.sf#: No such file or directory
4dos/          desktop/       nowhere/       os2ver*        spool/
4dos.com*      dirinfo.gcd*   os2/           os?siodt*      startup.cmd*
acd.idx*       dos/           os2bin/        pctools/       tape/
acllock.lst*   elm/           os2boot*       psfonts/       telix/
autoexec.bat*  io.sys*        os2dump*       qemm/          tmp/
bin/           mmos2/         os2krnl*       readme*        wpsbkup/
config.sys*    msdos.sys*     os2ldr*        readme.s3*
delete/        newvga.cmd*    os2ldr.msg*    sio/

So the "ea data. sf" is not read correctly...


-- 
Chris Lo                    
cklo@hkucs92.air.org       
chris@air.org             
mrc@hk.net                 
#include <std/disclaimer.h> 
 

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

From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: threads in kernel
Reply-To: pe1chl@rabo.nl
Date: Mon, 1 Aug 1994 08:48:08 GMT

In <31ec4n$og7@Times.Stanford.EDU> lm@stanford.edu (Larry McVoy) writes:

>Yes, that is true, but I don't think that you should be putting stuff on the
>stack and passing a pointer to it anyway.  That seems inherently dangerous
>to me.

>I like being able to keep programming the way that I do now.  I want to
>be able to just say

>       if (tfork()) {
>               /* parent thread */
>       } else {
>               /* child thread */
>       }

>and have everything work.  I've actually implemented such a beast in 
>user level a long, long time ago.  But I did not have OS support so
>I had to copy the stack and then walk all the stack frames and 
>rethread them.  Yuck.

I wrote user-level thread support as well.  I did not need to copy or
re-thread any stack frames, only to set up a new 'root' stack frame for
each new child.  Of course the child thread could not return from
function all the way up to main(), but it could return up to the point
where it was created.  That is resonable, IMHO.

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: Linux backup of MSDOS?
Reply-To: pe1chl@rabo.nl
Date: Mon, 1 Aug 1994 09:15:41 GMT

In <31gkfi$21q@sun.cais.com> toehser@cais2.cais.com (Tom Oehser) writes:

> >: I am considering using "dd" to get a binary image of the disc, and then
> >: compressing it, then putting that on tape.  But this may have problems?
>>that you restore to a partition of the same size, however, and that is 
>>why "image" backups are not popular under DOS (plus, it would probably 

>I am trying "dd if=/dev/hda | gzip --fast | dd of=/dev/nrmt0"
>(Why compress?  420mb/hda + 120mb/hdb > 525mb/mt0.  Besides, why not?)  

Because your entire backup will be worthless when there is even a single
bit error somewhere early on the tape...

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: patching scsi
Reply-To: pe1chl@rabo.nl
Date: Mon, 1 Aug 1994 10:26:50 GMT

In <31cclg$406@master.cs.rose-hulman.edu> zdenekjs@malachi.Rose-Hulman.Edu (Jerry S. Zdenek) writes:

>HELP!!!
>I have 3.2 gigs of space available in the form of 8 ESDI drives attached
>to 2 emulex MD23 ESDI-SCSI bridgeboards.  I am attempting to patch the
>SCSI drivers to recognize the 4 logical units on each emulex board. 

It should work as-is.  What is the kernel reporting during boot?

>When this happens I will be attempting to write a striping driver for them
>I am trying to get rid of a Windows NT server by putting linux on the 
>pentium machine.  NT will stripe it would be nice to make linux stripe  
>these ancient drives.

Yes, that would be a nice project I guess...

> But first I must get access to them....

But that should be no problem...

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: Fatal Signal 11 - reproduceable !
Reply-To: pe1chl@rabo.nl
Date: Mon, 1 Aug 1994 10:31:56 GMT

In <31foqf$osh@gap.cco.caltech.edu> nyet@linuxftp.caltech.edu (nye) writes:

>dcflood@u.washington.edu (David Flood) writes:

>>wosch@rbg.informatik.th-darmstadt.de (olav woelfelschneider) writes:

>>>So you can not be absolutely sure wether this is a compiler bug or a linux bug.

>>Or a hardware bug.  I had a bad swap partition that neither re-lowleveling
>>(MFM) or mkswap -c would find the bug but by spliting the partition in 1/2
>>eliminated the consistant signal 11's when compiling the kernel.  It also
>>eliminated some serious disk thrashing.

>Or a harder hardware bug. I had a bad SIMM that checked ok on my machine's POST
>but gcc was barfing with sig 11's. Then put the simm in another machine
>and it failed the POST. I got another good simm and the sig 11's went away
>completely.

Errors in SIMM memory should be reported as parity errors, at least some
of the time.  Make sure you have parity enabled in the system setup (CMOS).
If it won't run with parity enabled, and there are 9-bit SIMMs in the machine,
you better get rid of it...  (or complain with the supplier when that is
still possible)

Normally the memory corruption that is causing the GCC problems will be
taking place in the cache memory, I think.

>On another note, it looks like AMD dx2/66's don't like ghostscript - anybody
>else see this?

There have been reports of broken AMD DX2's.  It seems that recent chips
don't have this problem.

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: Does the Adaptec 2940 SCSI driver exists ?
Reply-To: pe1chl@rabo.nl
Date: Mon, 1 Aug 1994 10:35:38 GMT

In <31dphf$pri@infoserv.rug.ac.be> baekelan@intec.intec.rug.ac.be (Bart Baekelandt) writes:

>Could anyone answer the following question:

Probably yes.  But please note that it is a constant load on the developers
and other people in the newsgroup to ask this question over and over again.

It is better to look in the projects-FAQ and other FAQ documents first
to get your question answered.  You will probably learn a lot more at
the same time.

You find these documents in the comp.os.linux.announce newsgroup

>Does the Adaptec 2940 (PCI) SCSI driver exists for Linux ?
>(And so, where do I find him ?)

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: kernel stupidity...
Reply-To: pe1chl@rabo.nl
Date: Mon, 1 Aug 1994 10:38:40 GMT

In <31e3n6$gp9@rs18.hrz.th-darmstadt.de> wosch@rbg.informatik.th-darmstadt.de (olav woelfelschneider) writes:

>I think this is really nasty...

>Nowadays, if one tries to mount a write protected floppy without explicitely
>specifying it to be mounted read-only, an error occurs.

>I think this is really nasty, wouldn't it be possible to change the floppy
>driver again, so that it automatically mounts the drive read only if its
>protected?

No, this cannot be done in the floppy driver.
It could be changes in the "mount" program, though...

>It would be just enough to simply make all files write protected by setting
>the protection bits appropriately. This won't stop root from trying to
>write though, this should be handled in some way...

It is handled by the read-only mounting.

>Im feeling very uncomfortable with the current operation.

Why?
It is much more stable than it was before the change, where it would
just foul up the system when trying to write to that floppy...
(lots of errors in the log, inconsistent buffer cache, etc)

Rob
-- 
=========================================================================
| Rob Janssen                | AMPRnet:   rob@pe1chl.ampr.org           |
| e-mail: pe1chl@rabo.nl     | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU     |
=========================================================================

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

From: mike@MooCow.math.nat.tu-bs.de (Mike Dowling)
Subject: Re: 1.1.37 won't boot! False alarm!
Reply-To: on.dowling@zib-berlin.de
Date: Mon, 1 Aug 1994 12:30:00 GMT

False alarm!

I neglected to use the -p0 option to patch when patching 1.1.36.  A mmap.c was
left in /usr/src and I moved it into the wrong location.

                Sorry to waste bandwith
--
P.D. Dr. Michael L. Dowling               (__)       on.dowling@zib-berlin.de
Abteilung fuer Mathematische Optimierung  (oo)
Institut fuer Angewandte Mathematik        \/-------\
TU Braunschweig                             ||     | \
Pockelsstr. 14                              ||---W||  *
38106 Braunschweig, Germany                 ^^    ^^    Ph.: +49 (531) 391-7553


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

From: iwj10@cus.cam.ac.uk (Ian Jackson)
Subject: Re: Fatal Signal 11  - reproduceable !
Date: Sun, 31 Jul 1994 11:37:53 GMT

In article <31e3t7$gp9@rs18.hrz.th-darmstadt.de>,
olav woelfelschneider <wosch@rbg.informatik.th-darmstadt.de> wrote:
[quoting normalised, lines reformatted to <75 characters - iwj]
>Ian Jackson (iwj10@cus.cam.ac.uk) wrote:
>>In article <1994Jul7.193105.20509@kbbs.kiel.sub.org>,
>>Holger Petersen <hp@kbbs.kiel.sub.org> wrote:
>>> The following small C-program gives the Message "Fatal signal 11"
>>> [ further description and listing deleted ]
>>> cc: Internal compiler error: program cc1 got fatal signal 11
>>
>> 1. This is answered in the FAQ.
>> 2. You're posting to completely the wrong group.
>
>[stuff deleted]
>
>This is not neccessarily the wrong group, since I have lots of cases
>when I got this signal 11 (SIGSEGV, btw.) under kernel 1.1.37 (my
>hackers paradise), while everything runs fine with 1.1.9(which I
>think is very stable).

You've had *repeatable* fatal signals (ie, ones that always happen at
the same point) appear just by changing kernel version ?  That sounds
unlikely to me.  Perhaps you should have read what you deleted.

>So you can not be absolutely sure wether this is a compiler bug or a
>linux bug.

You can't be absolutely sure of anything.  However, the entry in the
FAQ, which you deleted, is correct.  It says:
 If the fault is repeatable (ie, it always happens at the same place in the
 same file) you have discovered a bug in GCC.
This is almost certainly true.  Furthermore, it also says what to do
if the problem isn't repeatable:
 If the problem is not repeatable you are very probably experiencing memory
 corruption --- see Q7.7 `make says Error 139'.

Anybody using a kernel that's so unstable that it repeatably causes
GCC to fall over should know what they're doing, and in particular
make sure that the problem occurs with a known good kernel.

The point of the FAQ is precisely to tell people like Holger Petersen
where to get assistance for their problem.  This is of course defeated
if they don't bother to read it.

It's also defeated if people post misinformation.

-- 
Ian Jackson, at home.         ijackson@nyx.cs.du.edu or iwj10@cus.cam.ac.uk
+44 223 575512    Escoerea on IRC.    http://www.cl.cam.ac.uk/users/iwj10/
2 Lexington Close, Cambridge, CB4 3LS, England.   Urgent: iwj@cam-orl.co.uk

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

From: rdieter@mathlab23 (Rex Dieter)
Subject: Re: Windows swap/bdflush/1.1.3x
Date: 1 Aug 1994 12:43:33 GMT

Paul Sitz (psitz@empros.com) wrote:
: I am sharing a swap partition between linux and Windows. Something
: in a recent upgrade has broken the restoration of the Windows
: information on a shutdown.  Specifically, I am running Slackware
: 1.2, and kernel 1.1.36 (the problem was evident at earlier levels).
: My /etc/rc.d/rc.0 is

I've been having a similar problem, but slightly different.  My drive
gets restored... kind of.  When I boot into DOS, only 1 copy of the FAT
gets updated... the others copy is not.  This is easily fixed with my
Norton Disk Doctor which has cleaned the problem up every time, but I 
shouldn't have to do that.

: This appears to me to be some kind of caching problem.  I don't
: like either of my workarounds.  Any suggestions for a reliable
: method to force the write to get flushed to disk in /etc/rc.d/rc.0?

I thought as much too.  After doing the restore and sync, I've tried  putting
in wait/sleeps afterwards to give it time to catch up... and this solution
has had SOME success, but not all.

Note:  I've been getting this problem periodically, but I have several 
versions of the kernel that I use.  Hence, I haven't been able to associate 
the problem with any particular one.

Anyone know what's going on here?

--
|Rex A. Dieter                  |      University of Nebraska        |
|rdieter@mathlab01.unl.edu      |      Math / Computer Science       |
======================================================================
| #include <have_a_nice_day.h>  |      Nuthin but InterNet           |

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

From: davidm@syd.dms.CSIRO.AU (David Monro)
Subject: Re: [hd] Do you recognize this error message?
Date: Mon, 1 Aug 1994 12:18:37 GMT

> Might some hd.c guru tell me a possible cause for the following errors?
> 
> Here I was running 1.0.9:
> 
>       Jul 20 02:27:18 crash kernel: HD: write_intr: status = 0x51
>       Jul 20 02:27:19 crash kernel: HD: write_intr: error = 0x04
>       [repeats 10 times]
> 
[stuff deleted]

Well, according to <linux/hdreg.h>, the status, is error + seek + ready,
which is normal except for the error, and the error is ABRT_ERR, or command
aborted. I have no idea what could cause this - I have only ever gotten
ECC_ERR, meaning a bad block.
> 
> Both of these resulted in a filesystem crash with lockup.
> In both occasions I was abusing the system pretty bad: Kernel compile
> + X + PPP + FTP + rlogin + xv.
> 
> Hardware:
> 386-DX/33, 6 MB RAM, 210 MB Maxtor IDE drive.
That really was thrashing the system - I wouldn't do that with my 8Mb of
memory, let alone 6..
> 
> Thanks
> --
> Alex Ramos (ramos@engr.latech.edu) * http://info.latech.edu/~ramos/
> Louisiana Tech University, BSEE/Sr * These opinions are probably mine

Good luck,
        David Monro

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

From: davidm@syd.dms.CSIRO.AU (David Monro)
Subject: Re: console driver does not reset char table with "stty sane"
Date: Mon, 1 Aug 1994 12:47:26 GMT

> 
> I don't know if this is a bug in stty or in the console driver. Or
> maybe it isn't a bug at all, or one of those "compatibility" or 
> "historical" bugs?
> 
> The problem can be replicated like this:
> 
>       echo ^N
> 
> (To get a ^N, hit Control-V followed by Control-N)
> 
> This switches the console driver to an alternate character set.  On a
> monochrome card (the one I have) the effect is drastic -- all lowercase
> characters get mapped to high-ascii graphics.
> 
> Unfortunately, closing the device or even "stty sane" does not switch
> you back to the original character table. 

stty is not resposible for dealing with the character set of the terminal
you are working on. It is the terminal's problem.

> 
> An "echo ^O" puts the driver back to its sane state, but I had to look
> at kernel sources to find that...

The linux console emulates a VT102. This is what a VT102 does, so this is
the correct behavior. After all, the system doesn't know everything about
your terminal (for instance, on a VT102 you can use double height chars
etc, but as far as I know there aren't any *nix operating systems
that can use this feature) and the console is really just another terminal.
A list of VT100 escape codes might be very useful..
There used to be a program called setterm which I think would do this with
setterm -reset, but this was way back in 0.97 kernel versions (mid 1992?),
so I don't know if it still exists. Oh, it still seems to be in utils-1.9,
so I guess it still works then. Try it and see!

> 
> --
> Alex Ramos (ramos@engr.latech.edu) * http://info.latech.edu/~ramos/
> Louisiana Tech University, BSEE/Sr * These opinions are probably mine


David Monro

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

From: shcun1@lindblat.cc.monash.edu.au (Stuart Cunningham)
Subject: SEGV, but no core dumped. Why?
Date: 1 Aug 1994 13:23:07 GMT

  I'm trying to debug some software that uses X with Motif and Uil
calls.  Occasionally, I'll get the familar "Segmentation Fault" error as
the program crashes.  To my surprise, sometimes there is no core dumped.
I'm forced to run it from gdb which takes a long time since many user
inputs are required to reproduce the bug.  Under gdb, it SEG faults at
the same place and I can then investigate as the stack remains intact.
Why won't it dump core when running on its own?  There is always half
the disk free.  I'm always root, and the directorys always have write
permission.
  The problem also occurs when there is a "Floating point exceptions":
the program stops prematurely, but with no core dumped.
I'm running Linux 1.0.8 on a 486DX66 if that's any help.

  Stuart Cunningham


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

From: nick leroy <nick.leroy@mixcom.mixcom.com>
Subject: Re: Large malloc problems
Date: Mon, 1 Aug 1994 12:49:28 GMT

>Anyone know why I can malloc 1000000 byte of memory but accessing it at
>indexes greater than about 250800 causes a Memory fault, I have 12 MEGS of
>ram.

>Test program

>    int *p;
>    int i;

>    if ( !( p = ( int * ) malloc( ( size_t ) 1000000 ) ) )
>       exit( 1 );

>    setbuf( stdout, NULL );
>    for ( i = 0; i < 1000000; i++ ) {
>       if ( i % 100 == 0 )
>           printf( "%d\n", i );
>       p[ i ] = 255;
>    }

An int* is a pointer to a 4 BYTE quantity.  Accessing p+1000000 is the
same as ((char *)p) + 4000000.  If you want to really alloc 1000000 ints,
you must 
p = malloc (1000000 * sizeof (int) ) /* 4000000 bytes */
+--------------------------------------+-------------------------------------+
| /`-_     Nicholas R LeRoy            | Linux -- What *nix was meant to be. |
|{     }/  nick.leroy@mixcom.com       | gcc   -- What C was meant to be.    |
| \   */   Camtronics, LTD, PO Box 950 |  Escape the Gates of Hell with      |
| |___|    Hartland, WI 53029          |   The choice of a GNU generation... |
+--------------------------------------+-------------------------------------+
-- 
+--------------------------------------+-------------------------------------+
| /`-_     Nicholas R LeRoy            | Linux -- What *nix was meant to be. |
|{     }/  nick.leroy@mixcom.com       | gcc   -- What C was meant to be.    |
| \   */   Camtronics, LTD, PO Box 950 |  Escape the Gates of Hell with      |
| |___|    Hartland, WI 53029          |   The choice of a GNU generation... |
+--------------------------------------+-------------------------------------+

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

Crossposted-To: comp.os.linux.help
From: ddelsig@uoft02.utoledo.edu
Subject: PLIP problems solved! (mostly...)
Date: Mon, 1 Aug 1994 03:48:46 GMT

Hi all,

     Good news!  I finally got PLIP working on my machine.  I'm posting this
mostly for the sake of the few other guys who futilely posted for help with
me on this subject.  Here are my experiences:

First of all, the only kernel I've gotten things to go on successfully is
1.0.9.  I got connections under 1.1.3x, but they were extremely slow and
subject to timeouts.  For example, under 1.0.9 ping returns a consistent
time of 3-4 ms with no packets lost.  Under 1.1.36 ping returns times in the 
70-80 ms range, with a scattering of others down to around 45 ms, and a
packet loss of around 50%.  I'm not sure why this is, perhaps the cable
design has changed for the newer kernels?  Read on...

I had a great deal of confusion about what the exact pin configuration of the
cable was supposed to be.  Some people said to connect 16, some said not to. 
everybody seemed to say that the diagram that they had was the standard
laplink cable.  Here's what I've gotten to work under 1.0.9.  I found it
using veronica, in the file plip.doc.  I'm including the whole document for
the sake of others who want to be further confused.

\begin{plip.doc}

  This is the wiring diagram for the cable necessary to link two
  machines together by their parallel ports.  This is the same wiring
  diagram used by a Turbo LapLink cable, available for sale from many
  PC parts outlets.

  1 - 1
  2 - 15
  3 - 13
  4 - 12
  5 - 10
  6 - 11
  7 nc
  8 nc
  9 nc
  10 - 5
  11 - 6
  12 - 4
  13 - 3
  14 - 14
  15 - 2
  16 - 16
  17 - 17
  18 nc
  19 nc
  20 nc
  21 nc
  22 nc
  23 nc
  24 nc
  25 - 25 (ground)

\end{plip.doc}

Here are the relevant portions of my rc.inet1 files.  
On my desktop [ hostname WonderLand ]

  /sbin/ifconfig lo loopback
  /sbin/ifconfig plip1 WonderLand pointopoint Ishmael up
  
  /sbin/route add loopback
  /sbin/route add WonderLand lo
  /sbin/route add Ishmael

On my laptop [ hostname Ishmael ]

  /sbin/ifconfig lo loopback
  /sbin/ifconfig plip1 Ishmael pointopoint WonderLand up

  /sbin/route add Ishmael.Narnia lo
  /sbin/route add loopback
  /sbin/route add default plip1

My last problem was with my laptop (a Compaq Concerto).  The way it was 
configured was that it had one parallel port on IRQ 7 at address 3BC.  Linux
recognized the fact that it was on 3BC, but assigned IRQ 5 to it, which is 
probably the standard IRQ for that address.  Luckily, I was able to fiddle 
with the configurations of my laptop via config utilities that came with
the thing, and was able to set the IRQ to 7 and the address to 378, which
is the standard place for plip1, lp1, and LPT1.  I determined that this was
a problem by observing the dump of messages linux gives when starting up,
and comparing it to what I found with the DOS tool MSD.EXE.  You can
probably use any benchmark/diagnostic tool that gives an accurate read of
device IRQs and addresses to see if you've got this problem too.

One other thing that I did was to move my soundcard to IRQ 5 to avoid any
device contention with the parallel port.  I don't know if this was
necessary, but I know it won't hurt anything.

Anyway, good luck to all you others out there trying to get PLIP running. 
If anyone has any hints on why PLIP would be working for me on 1.0.9 and
not on 1.1.3x, please let me (us) know.

See ya,

Dave

,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
```````````````````````````````````````````````````````````````````````````````
     _/_/_/_/     _/_/        _/_/   _/_/_/_/       David M. Del Signore
      _/    _/     _/_/    _/_/       _/    _/      University of Toledo
     _/     _/    _/ _/  _/ _/       _/     _/          Toledo, Ohio
    _/     _/    _/  _/_/  _/       _/     _/
   _/    _/     _/   _/   _/       _/    _/      ddelsig@uoft02.utoledo.edu
_/_/_/_/     _/_/        _/_/   _/_/_/_/      suprdave@esserv01.eng.utoledo.edu
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,


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

From: davidm@syd.dms.CSIRO.AU (David Monro)
Subject: SA400 format floppies possible?
Date: Mon, 1 Aug 1994 13:15:51 GMT

This is probably madness, but - does anybody know if it would be possible
to read and write a SysV/68k r2v3.0 filesystem on an IBM SA400 5.25"
floppy by juggling with the fdpatch code and using the SysV filesystem?
I don't know in what what the sector and track numbers are on the SA400
format but I can find out. From what I read in the SysV filesystem README,
I _may_ be able to mount the filesystem if I can talk to the floppy, and
maybe hack where the filesystem code looks for the superblock.

I am prepared to do a bit of hacking to get this to work, I just want to
know if someone knows if it would be 1) impossible or 2) nearly so, or 
3) think it should be very easy.

(The reason I want to do this is that the only other way I have of
transferring information to a 68020 VME bus machine is a 9600 baud line to
an IBM XT with 360K floppy drives - the SA400 MFM format supposedly holds
around 645K (I think) and is also a helluva lot quicker than 9600baud :-)

Thanks for any ideas you may have on this one,
        David Monro

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


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