Subject: Linux-Development Digest #253
From: Digestifier <[email-masked]>
To: [email-masked]
Date: Sat, 1 Oct 94 21:13:11 EDT

Linux-Development Digest #253, Volume #2          Sat, 1 Oct 94 21:13:11 EDT

Contents:
  Re: PPC (PowerMac) port status? ([email-masked])
  Re: Try this IPX bridging code ... (Steve Kneizys)
  Re: SMail security hole? (Lee J. Silverman)
  Problem with ncr53c810 and network (Frank Westheider)
  Re: Adaptec 1542/SCSI under Linux (Nick Kralevich)
  Where's my corefile? (Todd Klaus)
  Re: Driver support for PS/2 (MCA) version of SMC/WD? (James F. Morris)
  Re: Cant mount /dev/mitsumi_cd with kernel 1.1.45 (Heiko Schlittermann)
  Re: 1+ Gig SCSI Drives (Daniel Rogers)
  Re: Shared Libs: working toward a permanent solution? (Richard Krehbiel)
  Re: IBM Token Ring Support? (Alen Tihi)
  Re: Could TCP/IP be implemented over SCSI? (Thomas E Zerucha)
  hda: read_intr: error (Pierre Belanger)
  Re: TMC-850 on IRQ 11 no workee... (MORIYAMA Takao)

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

From: [email-masked]
Subject: Re: PPC (PowerMac) port status?
Date: 29 Sep 1994 23:12:53 GMT

>    Reply to: Zack T. Smith
>    
>                          PPC (POWERMAC) PORT STATUS?
>                                       
>    NETCOM On-line Communication Services (408 261-4700 guest)
>    Thu, 29 Sep 1994 04:27:36 GMT
>   Newsgroups:
>          comp.os.linux.development
>   Reply to newsgroup(s)
>Hi,
>
>I'm looking for PPC status. Is it getting anywhere? Is the Apple
>PowerMac going to be supported or will there be the same trouble
>getting hardware info as with the 68k Mac?
>
>TIA
>
>Zack Smith

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

Subject: Re: Try this IPX bridging code ...
From: [email-masked] (Steve Kneizys)
Date: 1 Oct 94 12:53:07 EST

Rob Janssen ([email-masked]) wrote:
: In <[email-masked]> [email-masked] (Steve Kneizys) writes:

: >Alan Cox ([email-masked]) wrote:
: >: In article <[email-masked]> [email-masked] (Steve Kneizys) writes:
: >: >If somebody wanted to isolate an IPX net/server from the main net
: >: >in terms of packet density but did not want to change the net 
: >: >numbers, well, bridging would be an option!  I may decide to add
: >: >it to my above bridge, as bridging is faster than routing.

: >: No bridging is normally slower than routing as you process more packets
: >: at the software level. 

: >Nah...depends on the speed of your algorithms!  Has nothing to do with
: >packet density, unless your algorithms are so slow that packets come 
: >in faster than you can filter them.  Think about it for a second...the
: >CPU overhead may be different, but network throughput depends on how
: >much time you spend processing the packet.  If I can lookup an
: >Ethernet address and determine what interface, if any, to send out
: >faster than looking up in a table, changing the hop count and
: >checksum, net number, then sending out then bridging is faster.

: The point probably is that bridging is practical to be implemented on
: dedicated hardware (possibly with some microcode), while routing usually
: isn't.   So, a dedicated bridge could be faster than a router.

: Of course, this no longer holds once you build your bridge using two
: normal ethernet cards and a PC.  In that case, the disadvantage of having
: to look at all packets becomes the deciding factor.

If you say so..but I wrote both bridging and TCP/IP routing code
designed to run on a PC and my bridging code was faster!

Steve...

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

From: [email-masked] (Lee J. Silverman)
Crossposted-To: comp.os.linux.help
Subject: Re: SMail security hole?
Date: 28 Sep 1994 06:47:09 GMT

        If your version of smail is writing files as root then you
have smail configured incorrectly, and should fix it IMMEDIATELY.  If
user xxx has a .forward file that sends output to a file, then smail
should write to that file as user xxx.  In order to make sure that
this is true, make sure your /usr/lib/smail/transports file has these
entry:

# pipe - deliver mail to shell commands
#
# This is used implicitly when smail encounters addresses which begin with
# a vertical bar character, such as "|/usr/lib/news/recnews talk.bizarre".
# The vertical bar is removed from the address before being given to the
# transport.
pipe:   driver = pipe,                  # pipe message to another program
        return_path, -local, from, -unix_from_hack;

        cmd = "/bin/sh -c $user",       # use Bourne shell to execute
        parent_env,                     # environment info from parent addr
        user=nobody,
        group=mail,
        -pipe_as_user,                  # not user-id associated with address
        umask=0022,
        log_output,                     # do not log stdout/stderr
        ignore_status,                  # exit status may be bogus, ignore it
        ignore_write_errors,            # ignore broken pipes

# file - deliver mail to files
#
# This is used implicitly when smail encounters addresses which begin with
# a slash or squiggle character, such as "/usr/info/list_messages" or
# perhaps "~/Mail/inbox".
file:   driver = appendfile,
        return_path, local, -from, unix_from_hack;

        file = $user,                   # file is taken from address
        append_as_user,                 # use user-id associated with address
        expand_user,                    # expand ~ and $ within address
        suffix = "\n",
        mode = 0644,

With the drivers set up this way, mail written to a file is written as
user xxx, but mail sent to a pipe is sent as user nobody.  It's a
little bit more secure that way.

--
Lee Silverman, Brown class of '94, Brown GeoPhysics ScM '95
Email to: [email-masked]
Phish-Net Archivist: [email-masked]
"Nonsense - you only say it's impossible because nobody's ever done it."

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

From: [email-masked] (Frank Westheider)
Subject: Problem with ncr53c810 and network
Date: 28 Sep 1994 06:58:40 GMT

HI Folks !

At the last linux-meeting in paderborn, germany, we established a server
with the following configuration :

  486DX2/66 PCI  24MB Ram (Elitegroup-board)
  Onboard NCR
  NE2000 Network-Card
  2 x 1GB ST31200N SCSI-HD

After about 20 Minutes of NFS-Serving, this server dies without message.
The HD-LED was not on, nothing goes.

Now i'm looking for the cause of the fault. Is it the network-code or
the ncr-code ?

Any suggestions or similar behaviour ?

--
Frank Westheider

higgins@uni-paderborn   [email-masked]  higgins@paderborn (MAGICNET)

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

From: [email-masked] (Nick Kralevich)
Subject: Re: Adaptec 1542/SCSI under Linux
Date: 28 Sep 1994 07:13:12 GMT

In article <[email-masked]>,
James E. McNalley <[email-masked]> wrote:

>       I've got a 1542B which is a truely awsome card.  I  havn't tried
>the A oro C/CF, but I'm happy with the B.  The A is no longer supported,
>and the only car I've heard that had trouble was older C's when the  SCSI

I have been working on getting the 1542CF working.  So far, it works
good for occasional use.  However, when I do somthing like
cp /dev/full /usr2 (where my SCSI drive is mounted), I get about
20-25 error messages over the course of the hard drive filling up
that say "interrupt received, but no mail found" or somthing like
that.  I've had a lot of problems with the 1.1.51 kernel, and much
less with the 1.1.50 kernel.  In fact, the 1.1.51 kernel won't
even boot.  I can't figure out why there should be any problems,
because none of the 1542 source code was changed.

This is with 1.1.51:

Sep 27 23:16:33 hercules kernel: aha1542.c: interrupt received, but no mail.
Sep 27 23:16:35 hercules kernel: scsi : aborting command due to timeout 
: pid 167, scsi0, id 6, lun 0 Write (6) 00 58 02 02 00
Sep 27 23:16:35 hercules kernel: scsi : aborting command due to timeout 
: pid 166, scsi0, id 0, lun 0 Write (6) 00 80 02 02 00
Sep 27 23:16:41 hercules kernel: scsi : aborting command due to timeout 
: pid 167, scsi0, id 6, lun 0 Write (6) 00 58 02 02 00
Sep 27 23:16:41 hercules kernel: SCSI host 0 abort() timed out - reseting
Sep 27 23:16:41 hercules kernel: scsi : aborting command due to timeout 
: pid 166, scsi0, id 0, lun 0 Write (6) 00 80 02 02 00
Sep 27 23:16:41 hercules kernel: SCSI host 0 abort() timed out - reseting
Sep 27 23:16:41 hercules kernel: Sent BUS DEVICE RESET to target 0
Sep 27 23:16:41 hercules kernel: Sending DID_RESET for target 0
Sep 27 23:16:41 hercules last message repeated 2 times
Sep 27 23:16:41 hercules kernel: aha1542_intr_handle: Unexpected interrupt
Sep 27 23:16:41 hercules kernel: tarstat=0, hastat=0 idlun=10 ccb#=3
Sep 27 23:16:41 hercules kernel: aha1542_intr_handle: Unexpected interrupt
Sep 27 23:16:41 hercules kernel: tarstat=0, hastat=0 idlun=10 ccb#=6
Sep 27 23:16:41 hercules kernel: aha1542_intr_handle: Unexpected interrupt
Sep 27 23:16:41 hercules kernel: tarstat=0, hastat=0 idlun=10 ccb#=7

The SCSI devices are at location #0, #6, and #7 (the controller).  
Anyone know the problem?

Right now I am running principally off of an IDE hard drive, with
nothing really on my 2 SCSI drives.  I still don't feel confortable
with the performance under Linux.  I just made some changes today,
including adding a terminator to the SCSI bus, but it doesn't
seem to have made any difference. 

Take care,
-- Nick Kralevich
   [email-masked]

-- 
Nick Kralevich                        [email-masked]
"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: [email-masked] (Todd Klaus)
Subject: Where's my corefile?
Date: 28 Sep 1994 07:24:03 GMT

I'm getting segmentation faults, but no (core dumped)!  I looked in 
/etc/profile and ~/.profile thinking this was a shell thing, but found 
nothing.  How do I enable corefiles?  I'm using the Yggdrasil summer '94 CD.

Thanks
Todd Klaus
[email-masked]

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

Crossposted-To: comp.os.linux.misc
From: [email-masked] (James F. Morris)
Subject: Re: Driver support for PS/2 (MCA) version of SMC/WD?
Date: Wed, 28 Sep 1994 02:49:33 GMT

Donald,

Thanks for the response!

In article <[email-masked]>,
Donald Becker <[email-masked]> wrote:
>In article <[email-masked]>,
>The WD80*3 and SMC Ultra use different methods of enabling memory.
>Do you know which one this card is similar to?

Good question.  More delving into the Crynwr (Assembler!) source should 
turn up the answer.  I do know that the memory address range for the NIC 
is configured with the PS/2 "Reference Disk".  I have it setup for 16KB 
access from C8000-CBFFF, and 8KB ROM from CC000-CDFFF.  It seems that the 
Linux SMC and WD drivers have yet to put it there...

>Please include the exact message -- is that the Tx status register or the
>general status register?

I am pretty sure it was the TX register.  I will nab the message out of 
the syslog/debug files tomorrow, and post it here.

>Those delays shouldn't be necessary with the UltraChip.  They were for
>earlier chips that needed a recovery period between accesses.  That was a
>bug, not a feature.

Glad to hear that.  Further delving into the Crynwr driver shows that it 
has code to read one of the NIC registers, which has a bit indicating 
that it is on an MCA machine.  The Crynwr code then proceeds to program a 
bit in configuration register 5 (0x04 I think) that somehow enables NIC 
interrupts onto the MCA bus.  Without doing so, the MCA bus will 
apparently not see IRQ's from the board.

>Is the ethernet address correctly detected?

Unsure.

>Are you receiving any packets at all?  Even errors?  Check /proc/net/dev.

No packets are seen at all to date.  However, I am going to switch from 
the 1.0.9 kernel to 1.1.xx tomorrow, and start over with this 
debugging.  I have *tried* defining EI_DEBUG to > 2, but do not see any 
messages in /var/adm/syslog or debug...

>What addresses can the board end up at?

The usual - C0000, CC000, D0000, etc.  IT is configured through PS/2 setup.

/--------------------------------------------------\
| Jim Morris   |    Internet:  [email-masked] |
|              |  CompuServe:  73670,762           |
\--------------------------------------------------/

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

From: [email-masked] (Heiko Schlittermann)
Subject: Re: Cant mount /dev/mitsumi_cd with kernel 1.1.45
Date: Fri, 30 Sep 1994 12:58:22 GMT

In article <[email-masked]>, Bob Ashmore <[email-masked]> wrote:
>I have a Gateway 2000 4DX2 66V with a mitsumi cd
>which works OK with Kernel 1.1.0 but when I installed 
>kernel 1.1.45 it will not mount. It gives the error on 
>boot;
>/dev/mitsumi_cd is not a valid block device.
>and if I try to mount it manually it gives the error;
>/dev/mitsumi_cd no such device or address.

My Mitsumi is on /dev/mcd, nowhere else.
-- heiko

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

Subject: Re: 1+ Gig SCSI Drives
From: [email-masked] (Daniel Rogers)
Date: 28 Sep 1994 19:48:07 -0700

In article <[email-masked]>,
Bill Heiser <[email-masked]> wrote:
>
>This is something I've been wondering about.  It appears to depend
>on which SCSI HA you are using.  In looking for a solution to my 
>instability problems with Buslogic BT445S/DEC DSP3107LS, I noticed
>a comment in the buslogic driver that seemed to indicate it expects
>the extended Translation to be switched ON.
>
>Mine is OFF and I wonder if this is causing my instability problmes
>(various crashes and kernel panics, different symptoms all the time).
>I've been considering trying to turn the Translation ON, but this
>(according to the Buslogic manual) means I need to reformat the
>disk, and I haven't had time to do that kind of job (reformat, reinstall,etc).

Well, I have a 1.7gig Maxtor on a Buslogic 445S, and I had problems when I
went from using the Adaptec 1542 driver (which didn't want translation) to
the Buslogic (which did).

What I ended up with was two partitions which overlapped, and when my 1 gig
news partition filled up to my swap space, all hell broke loose.  So, I
turned on translation, re-partitioned, and re-formatted the drive.

But the other system, also running a 445S, but with only a 1 gig drive
didn't have any problems when I switched from one to the other.

In hindsight, I should have formatted the 1.7gig initially with extended
translation on, and then I wouldn't have had any of these problems.

Oh, well...

Dan.
-- 
Daniel Rogers                   |  "Good tea, nice house." - Worf
([email-masked])      |  Linux - The choice of a GNU generation.

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

From: [email-masked] (Richard Krehbiel)
Subject: Re: Shared Libs: working toward a permanent solution?
Date: Wed, 28 Sep 1994 04:14:44 GMT

In article <[email-masked]> [email-masked] (Michael O'Reilly) writes:

> Richard Krehbiel ([email-masked]) wrote:
> 
> : Why is everyone hung up on PIC for shared libraries?
> 
> : Why not this way: Take a fairly large chunk of process virtual address
> : space, say 64M or so, and reserve it for shared library code and data.
> : When a shared library is loaded, find an available spot in that range,
> : load it, and then fix up self-relative code and data references with
> : the library's relocation dictionary.  This way you don't pay the
> : performance penalty of PIC, and you still avoid library load address
> : conflicts.  You have to worry about whether all libraries loaded by
> : all processes will fit into 64M, of course, and someone will have to
> : write a relocating loader.
> 
> The problem is 'sharing'. When you load the library, you write all
> over it, so you lose badly in terms of shared the library pages
> between processes.

So, share it.  (I do understand that's what shared libraries are for.)
The library image is loaded and relocated so that it exists at a
single virtual address, and it's the same virtual address for all
programs that link with it (as is currently the case).  The difference
is that the load address was chosen at load time, not at link time.
-- 
Richard Krehbiel                                [email-masked]
Picture a clever one-liner here...

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

From: [email-masked] (Alen Tihi)
Subject: Re: IBM Token Ring Support?
Date: 1 Oct 1994 17:39:25 GMT

Clarence Chu ([email-masked]) wrote:
: Hi netter,
:  
: I would like to know whether IBM Token Ring Adaptor is
: being supported by Linux.  I don't find it in FreeBSD, and
: in hope that the device driver is in Linux.
:  
: Thanks for any information.
:  
: Clarence Chu
:  * Origin:  (6:700/132)

On sunsite.unc.edu in /pub/linux/kernel/patches/network is a Token Ring
driver (very ALPHA !) .
I think the name is something like linux-1.1.47-TR-patch.gz .

much fun,
alen

--
========================================================================
Papernet:       Alen Tihi
                Universitaet Konstanz
                D-78456 Konstanz

Internet:       [email-masked]
========================================================================
The above posting is my opinion and if my boss has the same opinion...
... hey, it's not my fault !
========================================================================

" I'm glad to be a user,
  I'm glad to be free,
  but I wish I were a little dog
  and my Computer were a tree ! " - The Unknown User

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

From: [email-masked] (Thomas E Zerucha)
Subject: Re: Could TCP/IP be implemented over SCSI?
Date: 1 Oct 1994 18:00:40 GMT

It would require one of the SCSI ends to be a target, and many chips can do
this.  Then you could implement a messaging get/put protocol (there is one
in the SCSI 2 spec).  Then you would have to create a media driver that
the inet drivers could talk to (like ethernet or ppp).

In short, it is doable, but would need a lot of parts fabricated.
---
[email-masked] - main email address

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

From: [email-masked] (Pierre Belanger)
Subject: hda: read_intr: error
Date: 28 Sep 1994 00:06:48 GMT

Hello everybody,

I just received my P90/Intel Premiere Motherboard, before I had a 486 with
no problem at all.  I first switch the motherboards and Linux did not
want to boot (1.1.51).  It says: hda: read_intr: status = 0x59 and the
error = 0x10.  It was saying this when it was ready to mount the partitions.

So, since I have 2 drives, I made a bootable partition on tmy second drive,
and now it is working properly.

The question is: Why was it working fine with my 486 and I get this error with 
                 my p90?  

I am using 1.1.41 now...with the same problem!

Pierre B.

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

From: [email-masked] (MORIYAMA Takao)
Subject: Re: TMC-850 on IRQ 11 no workee...
Date: 29 Sep 1994 20:14:41 GMT

> The kernel booted, recognized the card as an ST-0X, but recognized my
> Maxtor as not only LUN 0, but also LUN4 and 7!  Then it proceeded to
> delete some entries (bogus, but it didn't say which ones it was deleting),
> and go on. 

I encontered the same type of symptom on my ThinkPad-750 + I/O expansion
box which contains almost TMC-950 compatible SCSI adapter.
I inserted "#define DEBUG" at the top of seagate.c. It generated many
messages to syslog (into /usr/adm/messages), but worked well.
It was also important that "#define DEBUG" was inserted BEFORE
"#include <linux/sched.h>". sched.h contains some "#ifdef DEBUG"
codes. I don't know why it was essential.

One more point. There is a blacklist checking in scsc.c.
If the card is listed in the backlist, scsi.c does not poll for
lun != 0.

Does this help you ?
--
Takao Moriyama                        Internet:   [email-masked] 
IBM Japan, Tokyo Research Laboratory  JUNET:      [email-masked]
Advanced Graphics Systems             IBM IP-net: [email-masked]
Voice: +81-462-73-4927                IBM VNET:   MORIYAMA at TRLVM     
                                      IBMMAIL:    JPIBMRS8 at IBMMAIL

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

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