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

572 lines
23 KiB
Plaintext

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: Sun, 2 Oct 94 18:13:15 EDT
Subject: Linux-Development Digest #256
Linux-Development Digest #256, Volume #2 Sun, 2 Oct 94 18:13:15 EDT
Contents:
Linux Device Driver info needed (William Shubert)
Re: linux+slip+bootp. How? (Jon Peatfield)
TMC-850 on IRQ 11 no workee... (ecarp@netcom.com)
3Com 509 Driver Problems - Any fixes - Help (Brian Kramer)
Re: [Wine] "Can't build if1632.o" Now what? (C. Engelmann)
Re: Does Linux require an IRQ for SCSI (John Shifflett)
Re: Linux on CD (Phil Hughes)
Re: Does linux implement semaphores? (Vassili Leonov)
Re: Linux and streams (Vassili Leonov)
Linux Mud (Scott Francis)
Re: SMail security hole? (SOLVED) (William Beckner)
Re: ISDN drivers for Linux/BSD survey (Andy Puchrik)
Re: Telnet & ftp freeze! (System Administrator)
Re: PROBLEM: Adaptec 1542 with SMC-Ultra (Robert A. Tiller)
----------------------------------------------------------------------------
From: wms@ssd.intel.com (William Shubert)
Subject: Linux Device Driver info needed
Date: Sun, 2 Oct 1994 16:25:51 GMT
This is probably a FAQ, but I couldn't find this newsgroup's FAQ on rtfm
or anywhere else, so here goes...
I need to write a device driver for Linux. I looked through the
src/linux/drivers directory, and found some good examples but no
documentation. Is there any documentation on the linux kernel anywhere?
If there isn't, could somebody point me to a device driver that accesses
a device on the memory bus by doing memory accesses instead of using the
outb/inb calls? All the standard drivers seemed to use the I/O bus. I
suppose that the hardware I'll be using could be modified to look for I/O
accesses instead of memory accesses (it'll be a custom card), but I'd
prefer to access it as memory.
Thanks! Please email me responses. I'm not sure that I can keep up
with the bandwidth of this newsgroup.
-Bill (wms@ssd.intel.com)
------------------------------
From: J.S.Peatfield@amtp.cam.ac.uk (Jon Peatfield)
Crossposted-To: comp.os.linux.admin
Subject: Re: linux+slip+bootp. How?
Date: 02 Oct 1994 17:10:18 GMT
> tried it and couldn't do it, think that was because the slip
> connection doesn't have an ethernet address (ie in the form
> xx:xx:xx:xx:xx:xx). the reason i was trying it was to get a computer
> to telnet in, the computer was local so I tried it with plip which
> does have an ethernet address type setup but still couldn't get it
> working. I did end up getting it working using rarp tho and maybe that
> would work over slip???
The lack of a MAC address shouldn't stop it working assuming that the
bootp server "knows" who you are by some other means (e.g. it knows
what physical port you are on or who you logged in as.)
However in all versions of bootpc I've released so far it didn't work,
'cos I always put the ARPHRD_ETHER type in the htype bootp field.
On NET3 (1.1.14+ I think) based kernels you can extract the correct
hardware type from any interface using SIOCGIFHWADDR so it should just
work correctly with that fix to the bootpc code.
However I've not got a SLIP (or PPP etc) line to test this on so I'm
on rather shakey ground where this is concerned.
Could someone with a SLIP line and a new(ish) kernel run the bootpc
(0.31) code thus:
bootpc --dev sl0 --verbose --debug
andmail me all the output?
-- Jon
--
Jon Peatfield, Computer Officer, the DAMTP, University of Cambridge
Telephone: (+44 223) 3-37852 Mail: J.S.Peatfield@amtp.cam.ac.uk
Friends don't let friends use PP. PP: Just say NO.
------------------------------
From: ecarp@netcom.com
Subject: TMC-850 on IRQ 11 no workee...
Reply-To: ecarp@netcom.com
Date: Wed, 28 Sep 1994 13:45:42 GMT
I have this really flaky Adaptec 1542B, so I decided to dust off a TMC-850
compatible card and use it. Since I have a four-port comm card, I decided
to switch the TMC-850 over to IRQ 11. I changed the IRQ #define in
seagate.c to 11, rebuilt the kernel, and rebooted. (1.1.51).
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.
The kernel read the partition table OK, but right after it did, it gave me
the message "SCSI error ... id 4 lun 0 rc=27010000", then "I/O error 0810
sector 0, unable to read partition table of dev 0810". Then the kernel
panicked: "kernel panic: no device passed to allocate_device()". The root
device is /dev/sda3 (0803). I have six partitions on this SCSI drive. The
drive itself is a Maxtor 1.2GB HD.
This same card worked on a pre-1.0 kernel, and it works with the Summer
1994 Yggdrasil kernel.
The machine is basically down for the moment, since the Adaptec card is
pretty flaky, and I don't have the spare cash to replace it. Help??
--
Ed Carp, N7EKG Ed.Carp@linux.org, ecarp@netcom.com
Finger ecarp@netcom.com for PGP 2.5 public key an88744@anon.penet.fi
** PGP encrypted email preferred! **
"What's the use of distant travel if only to discover - you're homeless in
your heart." --Basia, "Yearning"
------------------------------
From: bjkramer@pluto.njcc.com (Brian Kramer)
Crossposted-To: comp.os.linux.help
Subject: 3Com 509 Driver Problems - Any fixes - Help
Date: 30 Sep 1994 21:17:52 -0400
I get the following error which pretty much disables my system. Is there
a fix? Or can someone recommend a ethernet card that works flawlessly
with linux?
Sep 27 20:11:56 pluto kernel: eth0: Missed interrupt, status then 2011 now 2000 Tx 00 Rx 8000.
Sep 27 21:56:01 pluto kernel: eth0: Transmitter access conflict.
Sep 27 22:07:24 pluto kernel: eth0: transmit timed out, tx_status 00 status 2000.
Sep 27 22:07:25 pluto kernel: eth0: transmit timed out, tx_status 00 status 2000.
Sep 27 22:33:54 pluto kernel: eth0: Missed interrupt, status then 2011 now 2000 Tx 00 Rx 8000.
Sep 28 01:10:52 pluto kernel: eth0: Missed interrupt, status then 2011 now 2000 Tx 00 Rx 8000.
Sep 28 12:32:12 pluto kernel: eth0: Missed interrupt, status then 2011 now 2000 Tx 00 Rx 8000.
Sep 28 15:39:43 pluto kernel: eth0: Missed interrupt, status then 2011 now 2000 Tx 00 Rx 8000.
--
Brian Kramer - Owner/Systems Administrator - bjkramer@pluto.njcc.com
New Jersey Computer Connection - Public Access Unix Site - pluto.njcc.com
Voice: 609-896-2799 - Fax: 609-896-2994 - Dialups: 609-896-3191
Dialup or Telnet to pluto.njcc.com and log in as guest for more information.
------------------------------
From: engel@yacc.central.de (C. Engelmann)
Subject: Re: [Wine] "Can't build if1632.o" Now what?
Date: Sun, 2 Oct 1994 10:17:00 GMT
joel@wam.umd.edu (Joel M. Hoffman) writes:
>I found a copy of makedepend, which doesn't quite work right but seems
>to work well enough, and now I'm trying to build a copy of Wine,
>specifically, wine940912. But the make keeps dying on if1632.o:
> make: *** No rule to make target `if1632.o'. Stop.
>Indeed, I can find no if1632 source file. The README mentions a small
>change to if1632.S, but I can't find that file anywhere.
>Now what?
I had the same problem patching wine to the september edition -
but I couldn't solve it.
So I got the full source tree and it works.
There is a subdirectory named if1632, but there is only
a file called 'call.S'.
Good luck
Carsten
------------------------------
From: jshiffle@netcom.com (John Shifflett)
Subject: Re: Does Linux require an IRQ for SCSI
Date: Sun, 2 Oct 1994 17:29:26 GMT
jeffpk@netcom.com (Jeff Kesselman) writes:
>In article <36l7p8$ruc@carbon.denver.colorado.edu>,
>George <ghharrac@ouray.Denver.Colorado.EDU> wrote:
>>Does linux require that SCSI devices use an IRQ. The seagate
>>SCSI driver finds my adapter and drive, but times out. The
>>interrupt selector is disabled on my card!
The seagate driver *Absolutely Requires* an IRQ!!!!
>>I can set the IRQ to 3|5, Chance the Wait state to 0, and modify
>>the Memory range.
You typically select IRQ 5.
------------------------------
From: fyl@eskimo.com (Phil Hughes)
Subject: Re: Linux on CD
Date: Sat, 1 Oct 1994 03:34:13 GMT
Jeff Kesselman (jeffpk@netcom.com) wrote:
: In article <butler.780613856@bert.cs.byu.edu>,
: Kevin J. Butler <butler@bert.cs.byu.edu> wrote:
: >pc@dale.dircon.co.uk (Pete Chown) writes:
: >>If you have an IBM mainframe to spare, and run MVS on it, you can set
: >>it up to move files to slower discs or to tape if they haven't been
: >>used for a while. But they remain in the catalogue and are moved back
: >>invisibly when you next use them.
: >Exactly.
: >
: >A multi-tiered (secondary) storage sol'n:
: >disk
: >compressed disk
: >cd (if avail)
: >tape (if avail)
: >
: >complications arise w/ cd/tape, because they are removable--you end up
: >interrupting to tell the operator "Insert [media] volume X..."
: >But hey--its cheaper than robot mounted tapes, etc. ;-)
: >
: >Anyone working on anything like this???
: Lets go one step further... I'ld like such a system to keep a catalog of
: my CDs, so if I want t access something that is out on CD, and not
: currently mounted, itll ask me to mount the proper CD by name.
Funny thing about this is that the operating system I working on in 1970
(I was doing systems testing) did exactly this. (Well, not CDs as they
didn't exist). It was a commercial system (and still is -- CSTS on Univac
mainframes). Customers paid more for faster storage (drum, disk, tape).
All they had to do was change the storage class of a file (with a simple
command sort of like chmod) and the system would asynchronously move the
file.
Then, if they executed a file (just entered it's name) and it was on tape
they would have to wait and the operator would get a tape mount message.
The user never really knew what tape the file was on -- that was up to the
system. Worked really slick and certainly could work in a similar fashion
with Linux.
--
Phil Hughes, Publisher, Linux Journal (206) 527-3385
usually phil@ssc.com, sometimes fyl@eskimo.com
------------------------------
From: vassili@cs.sunysb.edu (Vassili Leonov)
Subject: Re: Does linux implement semaphores?
Date: 29 Sep 1994 23:19:23 GMT
Neal Patrick Howland (nhowland@ksu.ksu.edu) wrote:
: I was wondering in the standard linux develpment packages implemented
: a semaphore synchronization call. If not, how do you synchronize two
: processes to keep them from entering their critical sections at the same
: time?
System V IPC are in Linux. They do work...
Vassili.
------------------------------
From: vassili@cs.sunysb.edu (Vassili Leonov)
Subject: Re: Linux and streams
Date: 29 Sep 1994 23:24:59 GMT
dlc (dlc@gate.net) wrote:
: I am wanting to do some software testing in a Linux environment, but to do so I
: have to port some streams drivers over. Does Linux support streams? If so,
: where are they? If Linux doesn't do streams, why not?
In the stock version of the Linux there are no streams. Looks like
people don't think it's needed. For portability reasons it's definately
needed though I believe. There is one version of the kernel which has
streams support - but I don't know how well it goes with the current
release of the Linux. And how complete it is. Maybe author of it will
comment what's new with streams. And maybe it's the time to put streams
into the kernel permanantly. I personally have to run somwhat crap
Unix named Interactive on the machine that uses streams device driver.
Anyway - streams are quite usefull - and combined with loadable modules
are very practical.
Vassili.
p.s. Too much of kernel space programmi8ng is a HUGE security hole though...
------------------------------
From: francis@VIOLET.uthscsa.edu (Scott Francis)
Subject: Linux Mud
Date: 2 Oct 1994 13:09:55 -0500
Is there a mud developed for Linux and if so is it possible for me to get
the source or compiler version of it?
Please respond to francis@violet.uthscsa.edu
Thanks is advance
Scott
//////////////////////////////////////////////////////
// //
// Scott Francis - UT Health Science Center //
// San Antonio, Texas //
// //
// e-mail: francis@violet.uthscsa.edu //
// sfrancis@janus1.cs.trinity.edu //
// //
// voice: (210)829-5501 //
// //
//////////////////////////////////////////////////////
------------------------------
From: wbeckner@darkstar.rsa.lib.il.us (William Beckner)
Crossposted-To: comp.os.linux.help
Subject: Re: SMail security hole? (SOLVED)
Date: 30 Sep 1994 08:47:16 -0500
Patrick Schaaf (bof@wg.saar.de) wrote:
>jhenders@jonh.wimsey.com (John Henders) writes:
[ snip! ]
>Your conclusion (smail must be misconfigured) is correct, your proof
>is not; the hole mentioned allows unwanted _creation_ of files in
>inaccessible directories, with the file being owned by the user
>(when append_as_user is set). Checking the source of transports/appendfile.c
>you'll find that the attribute to set in the transport is called
>'check_path'. The bug is gone now. I have no idea why that isn't the
>default setting - does anybody know?
>Patrick
Thanks Patrick! Our defualt transports file did _NOT_ have the
'check_path' attribute. I put it in yesterday, and now (it seems) the
hole is plugged! The interesting thing is that smail doesn't complain to
the sender of the .forward mail message that the post failed, but the
smail log file does report 'permission denied' if the owner of the
.forward file does not have write permission to the directory the
.forward file is pointing to [ I hope that last sentence made sense! :) ]
Thanks again for everyones help. BTW, our Linux OS was a Slackware
installation. Maybe someone from Slackware (?) could answer your question?
--
Have fun!
=============================================================================
William Beckner - System Manager/SysAdmin wbeckner@darkstar.rsa.lib.il.us
Ph : (309) 694-5513
FAX: (309) 694-5297
Resource Sharing Alliance of West Central Illinois, Inc.
East Peoria, IL (USA) "Off of Route 24 on the Information Highway"
=============================================================================
System Administration -
It's a dirty job, but somebody said I had to do it.
------------------------------
Crossposted-To: comp.dcom.isdn,comp.os.386bsd.development
From: asp@puck.assabet.com (Andy Puchrik)
Subject: Re: ISDN drivers for Linux/BSD survey
Date: Sun, 2 Oct 1994 17:32:17 GMT
In article <1994Oct1.170214.30779@infomat.ve6mgs.ampr.ab.ca>,
Jason ROOT George <jbg@infomat.ve6mgs.ampr.ab.ca> wrote:
>{posted to comp.dcom.isdn, comp.os.linux.development,
> comp.os.386bsd.development}
>
>Next week, time permitting, I am going to get in touch with the appropriate
>people at Intel to attempt to secure the release of RemoteExpress programming
>specs. To aid in my quest, I ask that any interested parties send me a note
>detailing their "plans" for this ISDN card. I am only interested in receiving
>mail from programmer/driver hack-types, not from Joe User who wants to know
You might be interested in an ISDN board that Digiboard will be
coming out with. Digiboard seems to be a lot more interested in the
Linux market.
rgds,
asp
--
Andy Puchrik Internet: asp@puck.Assabet.COM
UUCP: transfer!charis!puck!asp
------------------------------
From: root@jaguar.tigerden.com (System Administrator)
Crossposted-To: comp.os.linux.help,comp.os.linux.misc,comp.os.linux.admin
Subject: Re: Telnet & ftp freeze!
Date: 2 Oct 1994 18:21:24 GMT
Trevor Lampre (trevor@xanax.apana.org.au) wrote:
[Text describing and lamenting problem my myself and others deleted.]
: Many have. I have posted twice myself about it and seen at least 5 other
: posts not including this thread. I have never seen a response and my emails
: to other posters has never been answered. It's pissing me off that nobody
: seems to know the answer or have a fix. I've been patching my kernel up
: to 1.1.51 (I think it got worse at .51) as well as rebuilding my daemons.
: As the admin of a public access system it is of great concern to me, I've
: had sendmail die for about 2 days before I noticed as well as the other
: problems described. I spend more time now checking/killing/rebooting
: my network stuff than I do giving more value to my users. I might just
: switch to *BSD, at least the network code works.
Thank WHATEVER that others are seeing this problem! And thanks to
Trevor Lampre (trevor@xanax.apna.ort.au)
Michael Haardt ((michael)u31b3hs@pool.informatik.rwth-aachen.de)
Thomas E Zerucha (zerucha@shell.portal.com)
and Steve Kneizys (STEVO@acad.ursinus.edu)
for confirming what we've been seeing! I suggest we keep this thread
open and fill it with additional information until the problem gets the
attention it needs. I'm not a programmer, much less a kernel hacker, so
I can only voice frustration with the situation.
Some additional information gleened from observations:
First, the original problem as I originally mentioned it:
We are running slip to our internet provider, and intermittantly
experience telnet lockups during logins. The system either 1) refuses
connections 2) accepts the connection, but just sits 3) provides a login
prompt, takes input, and never gives the password prompt (ususally
creating a login zombie in the process).
Additional information/trends noticed:
If the lockup occurs, allowing the telnet session with the locked
connection to sit while starting another is *always* successful. It
*appears* that a particular ttyp# gets buggered somehow, and forcing the
system to seek another one will get you in. I.E. We've had *tons* of
complaints about ttyp1 and ttyp4 lately (although I've seen the problem
also on ttyp3 in the past).
In the event 'refused connections' are the symptom to those telnetting in
over the SLIP connection, logging in by adding an x-term *on the console*
that grabs the offending ttyp port will suddenly allow SLIP telnet
accesses.
I thought that once a user was successfully logged in, everything was
fine. However, I have had complaints of 'gradual slowing' or 'gradual
slowing then locking' from a couple of users. I intiially dismissed this
as 'net problems', but after hearing Michael Haardt's comment, I'm
beginning to think that's what's happening to us as well. I also suspect
that other 'general' user complaints about our 'slowness' at times would
turn out to be the same thing as well.
I have been experimenting with MTU sizes with ifconfig, but have no feel
for whether or not this has any effect. I *have* noticed that MTU gets
reset to 1500 by *something* some random time after I've changed it (note
this is without system reboots).
Here's a sample of what we have:
yiffy:~# ifconfig
lo Link encap Local Loopback
inet addr 127.0.0.1 Bcast 127.255.255.255 Mask 255.255.255.0
UP BROADCAST LOOPBACK RUNNING MTU 2000 Metric 0
RX packets 0 errors 0 dropped 0 overrun 0
TX packets 39754 errors 7 dropped 0 overrun 0
sl0 Link encap AMPR AX.25 HWaddr
inet addr 198.30.162.1 P-t-P 199.18.108.11 Mask 255.255.255.0
UP POINTOPOINT RUNNING MTU 1500 Metric 0
RX packets 1583360 errors 0 dropped 0 overrun 0
TX packets 1995660 errors 0 dropped 16514 overrun 0
eth0 Link encap 10Mbps Ethernet HWaddr 00:20:AF:16:4C:3E
inet addr 198.30.162.1 Bcast 198.30.162.255 Mask 255.255.255.0
UP BROADCAST RUNNING MTU 1500 Metric 0
RX packets 293959 errors 0 dropped 0 overrun 0
TX packets 285447 errors 0 dropped 0 overrun 0
Note that a few moments prior to running this, I had set sl0 MTU to 2000,
and confirmed that the value was accepted. Now it is 1500 again without
any action on my part.
One last observartion. When we first started with kernel 0.99.15, telnet
sessions were locking up when large amounts of data was to be sent *out*.
That is, if someone did a large directory listing or other function with
lots of output, their session would hang. The send buffer information in
'netstat' showed several thousand characters waiting to be sent, and the
session would be effectively frozen. This problem was acknoledged by
others at the time, but as in this case, no answers were provided. The
problem went away when moving to the 1.0 kernel. So *something* was done
bye *someone* for that one.
I'm new to all this, and don't know all the avenues to pursue. I'd
appreciate any help in getting this problem hilighted and information
flowing to the *someone* who understands how the net interfaces really
work and who can really and *finally* *fix* it! How do we proceed?
George Nemeyer (root@tigerden.com)
System Administrator
Tigerden.com
------------------------------
From: rat@stimpy.uams.edu (Robert A. Tiller)
Subject: Re: PROBLEM: Adaptec 1542 with SMC-Ultra
Date: 2 Oct 1994 18:04:11 GMT
Rob Janssen (rob@pe1chl.ampr.org) wrote:
: In <C4289.94Sep30125136@rphc2.physik.uni-regensburg.de> c4289@rphc2.physik.uni-regensburg.de (Olaf Jaeger) writes:
: >problem:
: > I am using an ISA-Adaptec-1542c and a SCSI-2-HD with an
: >ext2-filesystem V. 0.5a on it. From the time that i put a
: >SMC-Ultra into the machine, the filesystem on the HD begins to vanish.
: I think there is a hardware problem in the ethernet card that causes
: it to be incompatible with busmastering controllers.
: This has been mentioned some times before, but I don't exactly remember
: which version of the card fixed it.
I have been running Linux on a 486/33 with a WD8003 and a Buslogic
542b scsi controller connected to a sony 128MB MO drive. The MO
drive will give CRC errors on gziped files but not on tar files. Plus
the errors are intermitent. The ide drive if fine. Someone else
has mentioned that there are certain irq's and shared memory areas
on the ethernet cards that will not work with scsi controllers.
As an aside, when I looked at the system map in the middle
of the 8390.o area was a scsi command! I must confess that I
know nothing about the system map and am not sure if this
is a problem or not. I have not tried to change anything on
the ethercard to test this yet.
Robert Tiller
------------------------------
** 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
******************************