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

626 lines
21 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 13:13:06 EDT
Subject: Linux-Development Digest #255
Linux-Development Digest #255, Volume #2 Sun, 2 Oct 94 13:13:06 EDT
Contents:
Compaq proliant 1000 (cont'd) (Anthony Marriott)
Re: i486 Word length, anyone? (David Fox)
ISDN drivers for Linux/BSD survey (Jason ROOT George)
Re: SOLUTION Re: SMail security hole? (Patrick Schaaf)
X-Windows support Weitek Power 9000? (John Willing)
PROBLEM: Adaptec 1542 with SMC-Ultra (Olaf Jaeger)
Re: Could TCP/IP be implemented over SCSI? (ian_vogt@ACM.ORG)
Improving SLIP latency under Linux (Nick Kralevich)
Re: xpat2 beta announce (Michael Bischoff)
Re: how to install SCSI tape drive (David Fox)
Re: What is "makedepend," and where do I get it? (pp000547@interramp.com)
Re: Is there a memory allocation debugging tool for Linux? (Henrik Juul Hansen)
Re: Could TCP/IP be implemented over SCSI? [New MailList] (jbarrett@onramp.net)
Re: DOS & Linux on 1GB drive (Aaron Wohl)
Suggestion: comp.os.linux.channelecho.* (Thomas E Zerucha)
UMAX flatbed driver, a start (M. K. Shenk)
----------------------------------------------------------------------------
From: anmar@netcom.com (Anthony Marriott)
Subject: Compaq proliant 1000 (cont'd)
Date: Sat, 1 Oct 1994 21:14:36 GMT
Well, I have come to the conclusion that linux will not
currently work on the proliant 1000.
I was told by someone at Compaq that this machine
uses a NCR 53C710 SCSI controller. From reading
the SCSI "how-to" and looking and the SCSI alpha
site it seems that this is not supported at
this time. It looks like only the NCR PCI boards
are supported (e.g. NCR 53C8xx).
Anway, for now I guess I will keep watching for
an announcement of a working NCR 53C710 SCSI driver.
NOTE: Thanks to those who replied to my original post.
-Tony-
Anthony R. Marriott
Anmar, Inc.
Software Consulting Services
------------------------------
From: fox@graphics.cs.nyu.edu (David Fox)
Subject: Re: i486 Word length, anyone?
Date: 30 Sep 1994 17:25:17 GMT
In article <Cwy0rL.L02@news.cern.ch> danpop@cernapo.cern.ch (Dan Pop) writes:
]
] In <36fan0$92c@nz12.rz.uni-karlsruhe.de> ig25@fg70.rz.uni-karlsruhe.de (Thomas Koenig) writes:
]
] >The registers of a 486SX also have 32 bits, it't the external
] >bus that's 16 bits.
]
] Wow, when did they change the size of the 486SX external bus? Last time
] I checked it was 32 bits. Or is the '4' in 486 a typo?
If you check back to when this thread referred to an actual
question, you will find this text:
> I tried setting it to 32 (since the 486 is a 32-bit processor <shrug>),
> and the program seems to compile fine, but it comes up with a floating
> point exception during execution.
So the width of the 486 internal and external bus is not the
issue here, nor are theoretical discussions of the definition
of "word".
--
David Fox xoF divaD
NYU Media Research Lab baL hcraeseR aideM UYN
------------------------------
Crossposted-To: comp.dcom.isdn,comp.os.386bsd.development
From: jbg@infomat.ve6mgs.ampr.ab.ca (Jason ROOT George)
Subject: ISDN drivers for Linux/BSD survey
Date: Sat, 1 Oct 1994 17:02:14 GMT
{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
if the RE will work under 0.99pl12. Requests from relevant, prominent
activists (Welsh, Janssen, Becker, Longyear, et al.) will be accepted as well.
I INFINITELY PREFER MAIL TO USENET REPLIES! MAIL WILL NOT BE OVERLOOKED,
WHILE I ONLY HAVE A FEW MINUTES A DAY TO READ NEWS!
I am extremely busy at school and am also administrating a championship Hybrid
Electric Vehicle Project, so this (the lobby) will be partially performed by
my co-workers, and I must supply both of them will enough information to help
kick this off and to help wade through the usual mess that is Big Business. :)
I am not guaranteeing this will succeed, but if no one else with sufficient
Intel contacts and/or certification will go to bat, I'm "the last, best hope
for mankind." (Sorry, bad Babylon5 quote!:)
Get that mail sent _now_!
--Jason
Jason George jbg@infomat.ve6mgs.ampr.ab.ca
Specialty Installations/Booth Consulting
Intel ANR; MPR/NT/BNR wannabe george@ee.ualberta.ca
UofA Co-op EE IV
------------------------------
From: bof@wg.saar.de (Patrick Schaaf)
Crossposted-To: comp.os.linux.help,comp.os.linux.admin
Subject: Re: SOLUTION Re: SMail security hole?
Date: 30 Sep 1994 12:01:11 -0000
(I wrote)
>Without check_path, smail doesn't allow you to append to files
>not owned by the user (append_as_user does that), but it allows
>creation of new files in inaccessible directories.
OK. After several mails indicating that smail does not have that
problem, I looked more closely. The culprit is in the OS configuration.
The hole doesn't show iff you 'HAVE=...SETEUID...' set in conf/os/linux -
smail then uses seteuid() to play with userids, and neither needs
nor uses check_path.
If you compile without SETEUID, check_path is neccessary.
I just recompiled my smail with SETEUID and can now safely omit check_path.
It doesn't hurt to have it in there, so it is still a good idea to
put check_path in the file transport configuration.
Sorry for any confusion this might have caused, but the problem seems
to exist in some distributions, so I think it is important.
Patrick
(followups set a bit more reasonably than last time)
------------------------------
From: willing@cimage.com (John Willing)
Crossposted-To: comp.os.linux.help
Subject: X-Windows support Weitek Power 9000?
Date: 30 Sep 1994 11:53:35 GMT
To start, I bought my system awhile back before checking the hardware list
and ended up buying a A.I.R Star 2000 Video board. I beleive that this
board is an OEM version of the Weitek 5186/5286 that has a Power 9000 (p9000)
graphic engine. (I would replace the card, but with my budget the way
it is, that will not be possible for sometime.)
I know that the P9000 is the same engine on the Diamond Viper and the
Orchid 9000. I have also read the information in the FAQ about the
problems with Diamond.
I would like to know if the Weitek P9000 is supported under X-Windows and
if so, for what vendors.
If there is any development in progress, I would love to be a Beta tester.
================
John Willing
------------------------------
From: c4289@rphc2.physik.uni-regensburg.de (Olaf Jaeger)
Subject: PROBLEM: Adaptec 1542 with SMC-Ultra
Date: 30 Sep 1994 11:51:36 GMT
Reply-To: olaf.jaeger@rphc1.physik.uni-regensburg.de
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.
Soon after de-taring a great file on a fresh made ext2-fs partition
i get a bunch of error-messages from e2fsck of the kind:
"Duplicate/bad blocks in node ##
#### #### #### ...
.
.
.
File /test.tar (inode ## ...)
has ### duplicate blocks with # file
Clone duplicate/bad block<y>?
.
.
. "
These errors are realy unique on my system and only occur when the
network-card is in my machine. As time goes on, the number of errors is
increasing and, if the partition is the root-device, the system soon comes
to a halt. They do even occur when the network-device isn't used at all.
The sole existence of it is enough. The amount of errors seems to correlate
with write-access on the filesystem, yet even files that are read only are
becoming destroyed.
I was able to reproduce this behaviour on another machine with
an Adaptec 1542b, and even with a different drive. Yet the e2fsck did
pop out other error messages (depending on wether b or c-type of 1542).
My HD without network-card is definitely ok.
What i have tested already:
The distribution of I/O-Ports and IRQ's are definitely unique and ok.
Using others, even if not necessary, gives no improvement.
Care has been taken upon ram-addresses and dis/enabled ROM.
The adaptec as i know, has no memory-area, and BIOS on it is disabled.
The effect is independent of adapter-rom-shadowing.
Apart from that,the SMC-ULTRA works fine.
My system-configuration:
kernels:
v1.0, v1.1.46, v1.1.49
kernel-messages:
"Configuring Adaptec at IO:330, IRQ 11, DMA priority 5"
"eth0: SMC Ultra at 0x240, 00 00 C0 F2 D3 A1, IRQ 10 memory 0xcc000-0xcffff."
"smc-ultra.c:v0.07 3/1/94 Donald Becker (becker@super.org)"
hardware:
80486DX, 33MHz, 12MB RAM, 256kB Cache, ET4000 + 1MB Ram, ISA-Bus
Adaptec 1542c/b, BIOS disabled
Platte: uSCIENCE gigafile, SCSI-2x
SMC-Ultra, Writings on Chip:83C790QF P// B9351// 6M72106-6
Busclock: 33MHz/4
BIOS: AMI
Am I really too stupid to configure my system ok, or am I not the only person
to undergo such a weird behaviour.
Please post any comments or e-mail to:
olaf.jaeger@rphc1.physik.uni-regensburg.de
------------------------------
From: ian_vogt@ACM.ORG
Subject: Re: Could TCP/IP be implemented over SCSI?
Date: 30 Sep 1994 12:26:06 GMT
Reply-To: ian_vogt@ACM.ORG
I worked on an application that had two machines connected to
the same SCSI bus with Adaptec 1542B cards and we ran into one
major problem.
If one of the machines was in the middle of a SCSI operation
(i.e.: disk/tape I/O) when the second machine was powered up
or rebooted, the SCSI card on the second machine would issue
a reset that would hang the first machine's pending operation.
We ended up having to use a watch-dog timer to ensure that
SCSI operations that never returned could be restarted.
Ian
------------------------------
From: nickkral@po.EECS.Berkeley.EDU (Nick Kralevich)
Subject: Improving SLIP latency under Linux
Date: 2 Oct 1994 12:39:08 GMT
Is there any way to improve/derease the latency associated with
SLIP under linux? Specifically, when I am ftping a large file,
I frequently get ping times of 6+ seconds. This murders interactive
traffic. I've tried setting my MTU to 256, but it doesn't make
any difference.
There was a thread a couple of months ago that said the problem
was in the kernel. However, there was never a solution posted.
If anyone can help me, I would appreciate it.
Take care, and thanks,
-- Nick Kralevich
nickkral@cory.eecs.berkeley.edu
--
Nick Kralevich nickkral@cory.eecs.berkeley.edu
"A man sits with a pretty girl for an hour and it seems shorter than
a minute. But tell that same man to sit on a hot stove for a minute,
it is longer than any hour. That's relativity." -- Einstein
------------------------------
From: mbi@math.nat.tu-bs.de (Michael Bischoff)
Subject: Re: xpat2 beta announce
Date: 30 Sep 1994 12:38:46 GMT
Reply-To: mbi@mo.math.nat.tu-bs.de
Hello,
in my announcement for xpat2 beta, I completely forgot a short description.
xpat2 is a solitaire game for X11. It knows the rules of spider, xsol,
klondike, and canfield, and others.
xpat2 can use different card sets without the need to recompile (cards
are in external data files) and the current version is quite customizable
(button labels, key assignments etc)
Where to get it:
mo.math.nat.tu-bs.de:/pub/in (user ftp)
Michael
P.S.: Another point of interest: If anyone has access to a prereliminary
version of X11R6, I'd like to hear if xpat2 compiles / works.
--
EOI
============================================================================
Michael Bischoff e-mail: mbi@mo.math.nat.tu-bs.de
Abt. Mathematische Optimierung or m.bischoff@tu-bs.de
Inst. Angewandte Mathematik or on.bischoff@zib-berlin.de
Pockelsstrasse 14 Tel. +49-531-391-7555, Fax: +49-531-391-4577
38106 Braunschweig Germany
------------------------------
From: fox@graphics.cs.nyu.edu (David Fox)
Crossposted-To: comp.os.linux.admin
Subject: Re: how to install SCSI tape drive
Date: 30 Sep 1994 12:09:10 GMT
In article <36gcaa$6a5@kshome.ruhr.de> karsten@kshome.ruhr.de (Karsten Steffens) writes:
] BTW: the official lists of device-numbers can be found in:
]
] /usr/src/linux/include/linux/major.h
]
] This is official because its the one that the kernel incorporates during
] compilation...
Or use the MAKEDEV script in /dev.
--
David Fox xoF divaD
NYU Media Research Lab baL hcraeseR aideM UYN
------------------------------
From: pp000547@interramp.com
Subject: Re: What is "makedepend," and where do I get it?
Date: 02 Oct 1994 05:14:08 GMT
Reply-To: pp000547@interramp.com (Bill Hogan)
In article <1994Oct1.145310.26970@excaliber.uucp> joel@wam.umd.edu (Joel M. Hoffman) writes:
I thought I'd give Wine a try this weekend, but I can't even get past
./Configure, because that script needs "makedepend," which I don't
have. Where might I find it.
Thanks.
-Joel
(joel@wam.umd.edu)
--
You should have it as part of your X setup:
19 ./usr/X11/bin/makedepend
4 ./usr/man/preformat/cat1/makedepend.1x.gz
You might try `whereis makedepend' and/or `man makedepend'.
Otherwise, maybe re-install the package that contains it -- in
Slackware (last time I looked) that was
|| Package: ./x4/xf_bin.tgz
Bill
--
Bill Hogan <pp000547@interramp.com>
"Show me a wisdom that is greater than kindness." [J-J.Rousseau]
------------------------------
From: hjh@snake8.imsor.dth.dk (Henrik Juul Hansen)
Subject: Re: Is there a memory allocation debugging tool for Linux?
Date: 2 Oct 1994 14:55:20 GMT
Hi again!
To you who have replied to my question. Thanks for your help. It seems like
there are quite a few different debugging tools available for this purpose.
I have made a short list of the different:
=====
Checker:
sunsite.unc.edu:/pub/Linux/devel
It's covered by the GNU licence.
=====
The garbage collector:
parcftp.xerox.com:pub/gc/gc.tar.Z
"The garbage collector in parcftp.xerox.com:pub/gc/gc.tar.Z runs
under Linux. It has a leak detection mode, though it currently doesn't
do a very hood job of describing the leaked objects (no allocation stack trace
except on SPARC). You only get the source file name and line number of
the caller to malloc, which may not be sufficient.
This can also give you rudimentary checking for memory overwrites."
=====
"debug-malloc"
found at:
oak.oakland.edu:/pub2/unix-c/languages/c/debug-malloc.tar.Z
=====
LIBC BUILT-IN MALLOC()/FREE() DEBUGGING CAPABILITIES
To the best of my knowledge (I don't have the best set of the LDP's
manual pages, so I could be wrong here), mtrace() is only documented
in the libc source code. The information I am using comes from
./libc-4.4.4/libc-linux/malloc/mtrace.c.
Synopsis: To use mtrace()
1) place a call to mtrace() at the beginning of main();
2) set (and export) the environment variable MALLOC_TRACE
to a string indicating the file to which the trace
will be written;
3) run the mtrace.awk program on the created trace file.
USE OF MCHECK()
Again, the LDP may have documented mcheck() too, but I've not gotten
around to looking at their manual pages yet. My information comes from
the ./libc-4.4.4/libc-linux/malloc/mcheck.c file.
=====
Another alternative recommended by Jan Newmarch
<jan@pandonia.canberra.edu.au> is a malloc library from
ftp.cs.toronto.edu under the /pub/moraes directory.
=====
Sincerely,
Henrik Juul Hansen
hjh@imm.dtu.dk
------------------------------
From: jbarrett@onramp.net
Subject: Re: Could TCP/IP be implemented over SCSI? [New MailList]
Date: Sun, 02 Oct 94 04:30:28 PDT
<ddj+@pitt.edu> Doug DeJulio writes:
>
> <jbarrett@onramp.net> John Barrett wrote:
> >Drive access conflicts are no problem... the drive will return a busy status
> >until the first access completes and the Linux driver has auto retry on busy
> >(Nice SCSI Driver Code) so the request will complete after the other machine
> >finishes it's access to the device.... small performace hit.. but no huhu
>
> Yes, huhu. Think about how this will interact with disk caches.
>
OK... I'll be specific... No huhu for read only devices... for read/write
devices (HDs esp.) you got problems... You must invalidate the caches (all or
part) on all other machines sharing a drive when your system writes to the disk
DEC (Digital Equipment) implemented a solution to this problem by handling
arbitration and cache control over DECNET... I'm not real sure how this
arbitration was handled, but hanging 10mbps ethernet throughput + TCP/IP
overhead into any part of your disk write routines is bound to slow things down
(As a first guess, I'd figure a token passing scheme, where block allocates and
disk writes can only be performed by the token holder.. and the FS superblock
can never be cached for any reason at all... after allocation and writing have
occured, and the disk is effectively sync'ed again... then cache control
messages can be sent, and token passing can take place) (anyone at DEC care to
reveal a little proprietary info on how this was done ;-) ???)
The current SCSINET proposal includes a lower level TMMP (Target Mode Message
Passing) interface that supports multiple protocols by using the SCSI LUN to
specify the protocol which should recieve a message passed over the SCSI Bus.
This allows many kernel modules to establish communications with other SCSI
hosts... say SCSINET plus 2 or 3 shared filesystems plus any new ideas...
Preliminary discussions are under way to define SCSINET and TMMP... If you want
to add TMMP Based Shared File Systems, then join the mail list!
SCSINET/TMMP discussion is being carried on <scsinet@thepoint.com>.
To subscribe: send mail to <mailserv@thepoint.com>
Message Text: "sub scsinet [Full Name (optional)]"
Many thanks to Arlie Davis for volunteering to carry this Mailing List.
John Barrett <jbarrett@onramp.net>
------------------------------
From: Aaron Wohl <aw0g+@andrew.cmu.edu>
Subject: Re: DOS & Linux on 1GB drive
Date: Sun, 2 Oct 1994 06:32:24 -0400
I just had the same problem... What you need is a disk controller with
it's own BIOS support for a large hard disk. I just got two controllers
from the GSI company. All of there contollers let dos use 8gig drives
on older systems. The cheapest route is to disable your existing
controller and use a GSI model 18 controler as the primary controller.
The model 18 costs around $50 US.
------------------------------
From: zerucha@shell.portal.com (Thomas E Zerucha)
Subject: Suggestion: comp.os.linux.channelecho.*
Date: 2 Oct 1994 15:38:16 GMT
Apparently the only way to communicate with the real developers is via one
of the "channels", e.g. SCSI, LAPTOSP, NET, and others. Is there any easy
way to have the messages echoed in "readonly" newsgroups?
Every time I tried to join a channel, I needed to try several times
(our mailer likes to put a blank line after the header, and doesn't allow
easy editing of the header). Then, I can't simply reply since I need
to add the X-Mn-Key: xxx somewhere and this runs into the same problem.
If the messages were made available over the net, at least I could read them
and identify what is happening.
---
zerucha@shell.portal.com - main email address
------------------------------
From: mkshenk@u.washington.edu (M. K. Shenk)
Subject: UMAX flatbed driver, a start
Date: 1 Oct 1994 00:45:53 GMT
Ok, we have a start. I talked to UMAX today on the phone, and asked about
getting programming info for their SCSI-2 flatbed scanners. Originally
I was told there was a developers kit for $395, but after explaining that
I was a student and the driver was for a free Unix system and I wasn't
going to be making any money, and agreeing to share any code with them (I
mentioned the GPL and that the code would probably be GPL'ed--I assume any
device driver for Linux would automatically be GPL'ed?) they told me they'd
send out a kit on writing Unix device drivers this Monday. No NDA or any
such thing was mentioned.
Looks like a good beginning.
Again, anyone with requests or helpful info, please drop me a line. I have
poked through driver code, but this will be my first. In particular, a
good recommendation as to a book on writing device drivers applicable to
Linux would be nice.
Contact: mkshenk@u.washington.edu
(Craig Johnston posting thru wife's account -- any ethernetted UW'ers want
to give me a shell account for reading/posting news? I won't be enrolled
until next quarter.)
-Craig
------------------------------
** 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
******************************