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

671 lines
27 KiB
Plaintext
Raw Blame History

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: Wed, 12 Oct 94 22:13:11 EDT
Subject: Linux-Development Digest #298
Linux-Development Digest #298, Volume #2 Wed, 12 Oct 94 22:13:11 EDT
Contents:
Re: Telnet & ftp freeze! - AND UNFREEZE KLUDGE (Steve Kneizys)
Re: 3Com 509 Driver Problems - Any fixes - Help (Donald Becker)
Re: Suggestion: comp.os.linux.channelecho.* (Matthias Urlichs)
Re: mounting > 32 drives (Matthias Urlichs)
Re: Filesystem idea (Tim Morley)
Re: Improving SLIP latency under Linux (Matthias Urlichs)
Re: [Q] SLIP/PPP and modems with large internal buffers (Matthias Urlichs)
Re: Compiling progs using port I/O (Matthias Urlichs)
Practical experience with Gravis Ultrasound Max? (Jon Lasser)
Linux's future support for ATA/IDE development thoughts... (George Shin)
Re: Lilo problems > 1GB (Jeff Kesselman)
Re: A badly missed feature in gcc (Jeff Kesselman)
Re: Any threads package ? (David Engberg)
Re: New Motif lib's for use with XFree 3.1 ? (Adam J. Richter)
Re: New Motif lib's for use with XFree 3.1 ? (Adam J. Richter)
Re: 3c503 problem (Greg Bruell)
Re: Question about ext2fs ("Eric Jeschke")
----------------------------------------------------------------------------
Crossposted-To: comp.os.linux.help,comp.os.linux.misc
Subject: Re: Telnet & ftp freeze! - AND UNFREEZE KLUDGE
From: STEVO@acad.ursinus.edu (Steve Kneizys)
Date: 7 Oct 94 22:11:57 EST
Yuri Trifanov (yuri@shimari.cmf.nrl.navy.mil) wrote:
: > We are using SLIP! And the problems we see are not *after* a connection
: > is successfully opened, it is one of the system *refusing* connections
: > (apparently). Nearly all functions handled by inetd seem affected:
: > telnet logins, rlogins, ftp attempts, smail connections, attemps to do
: > zone transfers from named by our provider's router, you name it. Things
: > work fine *most* of the time, but the login problems are the most
: > persistant and visible. In those cases, the system log *usually* shows
: > 'connect from...' but the user never gets a prompt, or never gets a
: > password prompt after entering username. Netd entries in the log are
: > 'connection refused' mostly.
: you could be having problems with the resolver and tcpd, which comes
: turned on by default in at least some distributions. if it can't
: resolve the inaddr of the connecting host it will refuse the
: connection.
I see the freeze and I only use Etherlink III 3c579 cards on the same
wire as 3 VAXes, including our domain's name resolver. Telnets from
the domain resolver VAX to the Linux freeze, as does FTP, finger,
smtp, rlogin.
Steve...
------------------------------
From: becker@cesdis.gsfc.nasa.gov (Donald Becker)
Crossposted-To: comp.os.linux.help
Subject: Re: 3Com 509 Driver Problems - Any fixes - Help
Date: 11 Oct 1994 23:26:33 -0400
In article <36uros$3oc@news.compulink.com>,
Derek Snider <derek@cid.compulink.com> wrote:
>Brian Kramer (bjkramer@pluto.njcc.com) wrote:
>: 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.
These messages represent harmless events which shouldn't impact your system.
>: Sep 27 21:56:01 pluto kernel: eth0: Transmitter access conflict.
Now this is a bad message. It should never happen. What kernel are you
using?
--
Donald Becker becker@cesdis.gsfc.nasa.gov
USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771
301-286-0882 http://cesdis.gsfc.nasa.gov/pub/people/becker/whoiam.html
------------------------------
From: urlichs@smurf.noris.de (Matthias Urlichs)
Subject: Re: Suggestion: comp.os.linux.channelecho.*
Date: 9 Oct 1994 16:19:22 +0100
In comp.os.linux.development, article <hpa.06140000.Heja.Sverige@ahab.eecs.nwu.edu>,
hpa@nwu.edu (H. Peter Anvin) writes:
> >
> > There are linux.act.* groups but you have to ask your News administrator
> > to establish a feed. Ask him to contact hpa@nwu.edu. I think they are
> > read-write but I haven't tried yet. Maybe next week (:
>
> They sure are, if your news administrator has set up your moderators
> file correctly.
>
Grumble.
(a) What's the correct entry in the moderators file?
(b) Why the *censored* are they using moderated newsgroups instead of a
reasonable bidirectional gateway?
(c) Has there been any announcement in c.o.l.a, and if so why haven't I
seen it? ;-)
--
There is no pillow as soft as a clear conscience.
--
Matthias Urlichs \ XLink-POP N<>rnberg | EMail: urlichs@smurf.noris.de
Schleiermacherstra<EFBFBD>e 12 \ Unix+Linux+Mac | Phone: ...please use email.
90491 N<>rnberg (Germany) \ Consulting+Networking+Programming+etc'ing 42
PGP: 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE
Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.
------------------------------
From: urlichs@smurf.noris.de (Matthias Urlichs)
Subject: Re: mounting > 32 drives
Date: 9 Oct 1994 17:28:47 +0100
In comp.os.linux.development, article <HARE.94Oct5233240@zarquon.mathi.uni-heidelberg.de>,
hare@zarquon.mathi.uni-heidelberg.de (Hannes Reinecke) writes:
> taylor@pollux.cs.uga.edu (john taylor) schrieb:
>
> I would like to mount more than 32 drives, but the mount program will
>
> AEHMM .... How do you actually _connect_ 32 drives ???
> 4 SCSI-Adapters or what ?
>
NFS, for instance.
In some environments, it's _very_ easy to get a multi-page mount list.
(Ever heard of AMD?)
--
Concentrate on security.
--
Matthias Urlichs \ XLink-POP N<>rnberg | EMail: urlichs@smurf.noris.de
Schleiermacherstra<EFBFBD>e 12 \ Unix+Linux+Mac | Phone: ...please use email.
90491 N<>rnberg (Germany) \ Consulting+Networking+Programming+etc'ing 42
PGP: 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE
Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.
------------------------------
From: tim@morgoth.derwent.co.uk. (Tim Morley)
Subject: Re: Filesystem idea
Date: 12 Oct 1994 16:28:48 +0100
In article <37d4la$g54@news.doit.wisc.edu>,
Jeffrey Charles Schave <schave@PROBLEM_WITH_INEWS_GATEWAY_FILE> wrote:
>Riku Saikkonen (riku.saikkonen@compart.fi) wrote:
>> [Filesystem with temporary file type..]
>
>I don't think that a new file system is necessary for this. An easy
>way to accomplish this is to write a shell script run every night,day
>,whatever(via cron). This script could check the amount of free space
>left on the drive, and if necessary, destroy any .o files.
You have to be a bit careful about this, I know of a system where
someone implemented this, and it was fine until a reboot was required,
with some strange and insignificant .o file the system refused to
boot....
Tim M
------------------------------
From: urlichs@smurf.noris.de (Matthias Urlichs)
Subject: Re: Improving SLIP latency under Linux
Date: 9 Oct 1994 18:08:06 +0100
In comp.os.linux.development, article <377ijq$96@ulowell.uml.edu>,
jrichard@cs.uml.edu (John Richardson) writes:
>
> >2- use IP header compression
> I don't have this option.
Then kick whoever is at the other end. Header compression _helps_.
>
> >3- turn off error correction in the modems
> I tried this to no avail.
Modems should have a configuration option to also turn off (or tune) the
RTS threshold values for the modem's send buffer. Unfortunately, in most
modems there is no such thing. We could see more sensible modems if more
people would complain.
> >If you use SLIP instead of PPP, decide on one of -3- and -4-.
> >
Oops, I meant "-2- or -3-". (Rationale: There should be a link-level
checksum. The modem error correction isn't end-to-end, but it's better than
no error correction at all.)
--
How many nihilists does it take to change a light bulb?
Fuck off.
--
Matthias Urlichs \ XLink-POP N<>rnberg | EMail: urlichs@smurf.noris.de
Schleiermacherstra<EFBFBD>e 12 \ Unix+Linux+Mac | Phone: ...please use email.
90491 N<>rnberg (Germany) \ Consulting+Networking+Programming+etc'ing 42
PGP: 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE
Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.
------------------------------
From: urlichs@smurf.noris.de (Matthias Urlichs)
Crossposted-To: comp.dcom.modems,comp.protocols.tcp-ip,comp.protocols.tcp-ip.ibmpc
Subject: Re: [Q] SLIP/PPP and modems with large internal buffers
Date: 9 Oct 1994 18:14:48 +0100
In comp.os.linux.development, article <3724gl$9vt@news.onramp.net>,
jgray@onramp.net (Joe Gray) writes:
> >
> >Also, does anyone have a modem which has a configuration to
> > reduce the send buffer size
> > lower the flow-control bit sooner (when the send buffer
> > reaches x bytes)
>
> The ZyXEL modems have a data throughput averaging mode which can be disabled.
> With averaging off, you could get very high data bursts at times from the
> modem. [...]
Grumble. We're talking about the _send_ buffer size here, i.e. the buffer
to the modem. Thruput averaging affects the rate which is used to empty
the buffer _from_ the modem, which is a totally different kettle of fish.
Averaging won't slow down a background transfer, but it'll delay
interactive stuff. (Unless your system is too slow and the serial port gets
overruns without averaging, of course.)
--
Anarchy begins at home, but it doesn't have to end there
--
Matthias Urlichs \ XLink-POP N<>rnberg | EMail: urlichs@smurf.noris.de
Schleiermacherstra<EFBFBD>e 12 \ Unix+Linux+Mac | Phone: ...please use email.
90491 N<>rnberg (Germany) \ Consulting+Networking+Programming+etc'ing 42
PGP: 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE
Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.
------------------------------
From: urlichs@smurf.noris.de (Matthias Urlichs)
Subject: Re: Compiling progs using port I/O
Date: 9 Oct 1994 18:28:25 +0100
In comp.os.linux.development, article <1994Oct7.162235.9369@kf8nh.wariat.org>,
bsa@kf8nh.wariat.org (Brandon S. Allbery) writes:
>
> People are forgetting that user mode programs should not be using direct port
> I./O in most cases; that belongs in the kernel. Linux is not MS-DOS. The
> current behavior makes a good warning that the person using direct port I/O
> shoulod be thinking twice about what they are doing.
>
The current behavior depends on the -O flag. IMHO, that's a VERY stupid way
to "warn" people.
It reminds me of Micros*** Weird, which could (can?) not enter Formula mode
when the "full menus" option was turned off. Since formula mode was entered
via an arcane way which I have since forgotten, and _not_ via any menus,
this feature^h^h^h^h^h^h^h^h bug caused much headscratching when first
encountered at the help desk.
--
People who won't learn from past mistakes are condemned to repeat them.
--
Matthias Urlichs \ XLink-POP N<>rnberg | EMail: urlichs@smurf.noris.de
Schleiermacherstra<EFBFBD>e 12 \ Unix+Linux+Mac | Phone: ...please use email.
90491 N<>rnberg (Germany) \ Consulting+Networking+Programming+etc'ing 42
PGP: 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE
Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.
------------------------------
From: jon.lasser%goucher@wb3ffv.ampr.org (Jon Lasser)
Subject: Practical experience with Gravis Ultrasound Max?
Date: 7 Oct 94 11:28:00 GMT
Reply-To: jon.lasser%goucher@wb3ffv.ampr.org (Jon Lasser)
Does anyone have practical experience with the Gravis Ultrasound Max
under Linux?
I have three primary questions:
(1) Does the CD-ROM interface for the Panasonic drive work
properly under Linux (I have a Panasonic 563b drive, which currently
runs with my Sound Blaster 16).
(2) Are there any general incompatibilities between the board
and Linux? Any specific known problems?
(3) I'm currently using a Sound Blaster 16. IsGravis
Ultrasound Max considered an upgrade from the Sound Blaster? I mean, I
know that the digital audio is about the same, but is the WaveTable that
much better?
Frankly, I'm lusting over the board, but I want to make sure that it
works before I buy it, because I don't know enough to hack the kernel.
(yet).
Replies by e-mail are appreciated, although I do try to keep up with
this group.
Thanks in advance,
Jon Lasser
------------------------------
Crossposted-To: comp.os.linux.help,comp.os.linux.misc
From: gshin@netcom.com (George Shin)
Subject: Linux's future support for ATA/IDE development thoughts...
Date: Tue, 11 Oct 1994 04:52:34 GMT
Hello Linux net-folks,
I've been following pretty closely on some of the discussions relating
to Enhenced IDE/Fast ATA topic and would like to maybe continue on
to see how it's and will effect Linux support for ATA drives. I don't
intend to do all at one shot so here goes the first two attempts...
But first some base-line terminology so we start out at the same ground:
I would like to use the term ATA rather than IDE since to me even SCSI
drives are candidate for IDE. Also, i tend to talk register mode
versus BIOS support when interfacing to the drive, i.e. direct I/O port
programming against BIOS ISR provider. Finally, if i may i would like
to include DIOW-/DIOR- interface signals when discussing various PIO
timing modes. Oh, BTW at the host-end i tend to call the drive card,
host adapter card (HAC) whereas most people use the terminlogy of
controller card. Most ATA HAC's are pretty much "brainless" and does
nothing but data buffering in between the host and the target drive.
Well, i'm not an expert in ATA drive land, however getting lot's of
practice at the work so maybe share some information with fellow
Linux'ers and get plenty of feedbacks hopefully. I've been funning
Linux for quite some time starting with ATA drives then with all
the advantage with SCSI, now am running Linux entirely from 1GB SCSI
drive. However following thoughts come to me when thinking about
ATA drives + Linux:
1. Since ATA-2 spec is on its way of being finallized we'll expect to
see more drives with support for fast PIO timing modes especially
PIO mode 3 and yes, PIO mode 4. For user to take advantage of these
high speed data transfer rate one would need local-bus (VLB or PCI)
ATA HAC that can strobe DIOW-/DIOR- at that frequencies. Most if
not all have special on-board ATA interface chip that's capable of
interfacing at that high speed as well as BIOS extension or
installable device drivers. At very minimum these BIOS or device
drivers will initialize various timing registers of interface chip
to talk at that high data rate of ATA interface. My concern is that
since Linux is doing all ATA talking at non-BIOS, register level
will this have to be changed later when supporting specific high-speed
ATA HAC's? I've done some measurement at work and having these
cards power up and doing all register level drive access there after
will NOT produce fast transfer.
Looks as though these BIOS/driver routines have some special code
besides your average "rep outsw" and "rep insw" instructions. So does
this mean Linux now has to support specific ATA HAC's??? I guess
days of generic ATA interface talking is over then...
2. ATA-2 has announced additional I/O ports for 2 more HAC's besides your
current primary and secondary. This results to total of 8 ATA drives
under PC. Any interest in supporting this under Linux... Hmmm, maybe
i should get involved in this... I can't recall whether IRQ's are also
defined or suggested...
- george
PS How do you REALLY know that your high-speed 1GB ATA drive is doing PIO3 or
PIO4??? You REALLY don't unless...
PSS BTW, check out ftp://fission.dt.wdc.com's /pub/ata and /pub/standards for
ATA/SCSI papers... These really make very good bed-time readings... :-)
------------------------------
From: jeffpk@netcom.com (Jeff Kesselman)
Subject: Re: Lilo problems > 1GB
Date: Sun, 9 Oct 1994 05:55:52 GMT
In article <373d3p$6ov@liberator.et.tudelft.nl>,
Jean-Paul van de Plasse <jp@brinta.ptf.hro.nl> wrote:
>I'm having some problems when I install lilo from
>my Fujitsu M2694ESA 1.01 GB HD,
>
>Lilo just prints LILOLILOLILO .
>
>When I install lilo from my 300MB SCSI drive it al seems to work.
>
>I have set the params in /etc/"forgot the name".
>
>Does anybody have a clue ????
>
There is a known problem with BIOS and trying to boot off of a parition
with more then 1024 cylindres. I'm afraid I don't know if this coudl
cause your particualr problewm or not. Maybe someone with alittle more
specific knowledge will chime in, but if that boot parition has more then
1024 cylinders, you might try repartioning and see if the problem goes
away...
------------------------------
From: jeffpk@netcom.com (Jeff Kesselman)
Subject: Re: A badly missed feature in gcc
Date: Sun, 9 Oct 1994 05:59:00 GMT
In article <wcreator.781655152@kaiwan009>,
Steven M. Doyle <wcreator@kaiwan.com> wrote:
>In <CxCJx3.ELF@pe1chl.ampr.org> rob@pe1chl.ampr.org (Rob Janssen) writes:
>
>>It has always amazed me how many people try to remove pieces of coding for
>>debugging purposes using "comment" constructs...
>>This may be required in other languages, but is not in C. C compilers
>>traditionally have had the luxury of the pre-processor, so you can just
>>use:
>>#if 0
>>#endif
>
> To each his own. I personally use both in debugging my programs,
>for one reason. I see no reason to add the #if/#endif when one or three
>lines of code is being commented out. It's much simpler just to use /**/ or
>//.
>
I also use both, and I've been programming in C for man yyears
professionally. The // construct in c++ is particularly useful
(I tend to avoid using /* */ just because they don't nest and other
comments within the commented block can cause unwanted effects. Ofcourse
if you never comment, its not a problem... (yechhh!)
------------------------------
From: dave_engberg@taligent.com (David Engberg)
Subject: Re: Any threads package ?
Date: Wed, 5 Oct 1994 19:41:13 GMT
In article <36ujao$v8@mark.ucdavis.edu>
leb@cs.ucdavis.edu (Bich-Cau Le) writes:
> I'm doing real-time OS simulations under Unix. Is there something
> similar to Sun's lightweight process library for Linux?
An implementation of Posix threads (pthreads) is available via
ftp from bloom-picayune.mit.edu ... the author has information
available: http://www.mit.edu:8001/people/proven/home_page.html
Has anyone used this on Linux? I would like to write some software
that would be greatly simplified with a threads library, and I'd
love to hear your experiences with this one...
------------------------------
From: adam@yggdrasil.com (Adam J. Richter)
Crossposted-To: comp.windows.x.i386unix
Subject: Re: New Motif lib's for use with XFree 3.1 ?
Date: 12 Oct 1994 19:47:43 GMT
In article <37c1gb$lo@tartan.metrolink.com>,
Craig Groeschel <craig@metrolink.com> wrote:
>In article <374nup$aap@freya.yggdrasil.com>,
>Adam J. Richter <adam@yggdrasil.com> wrote:
>>We had an X11R6
>>beta release that used a downward compatible version version number for
>>its shared libraries and seemed to work fine with the R5 binaries that
>>we tried.
>
>"Seemed to work fine" or "was binary compatible"? Big difference.
Any program that could statically link against both R5 and R6
would run perfectly with our R6 shared libraries, even if the binary
had been compiled against the R5 stubs. In addition, programs that
used functions that had been renamed in R6 would also work. (The
functions that the X consortium renamed were also renamed in our
jump files.)
It is true that some obscure R5 calls do not exist in R6,
but that would only effect programs that would not successfully
relink against R6 anyhow. If a program called one of these deleted
entries, the undefined routine acted as a no-op. Deleting jump table
entries from new versions of shared libraries is nothing new. For
example, there are now numerous __DUMMY__ entries in jump.vars for the
Linux C library.
A program that referenced a routine that was no longer
supported by X11R6 would fail to relink, so it was quite simple for a
software developer to test if his or her program was effected. In
other words, everything that could work would work.
For whatever reason, XFree86 chose to ignore our jump tables
(which were publicly announced and anonymously FTPable), and instead
decided to build incompatible jump tables. Perhaps XFree86 had some
technical reason for doing this, but I have yet to hear one. If
XFree86 had had a more open beta testing process, this problem would
have been exposed and fixed long ago.
There must be at least a couple of thousand people out there
using Motif (Metrolink, SWiM, X-Inside, etc.) right now. I hope that
most of these people are on the internet, because the media costs
alone of sending all of these people new floppy sets would be about
ten thousand dollars, and that money has to come from somewhere.
There are problems on the business Motif packages will have to have
twice as much media or stores will have to stock two different
versions of Motif packages. And that's only after the new libraries
become available. In the meantime, in order to use the Motif shared
libraries, you have to keep the R5 shared libraries around, and you
may have other problems in recompiling, since the "-lX11" in a "-lXm
-lXt -lX11" will bring in the R6 libraries, and you'll probably have
the R6 #include files already installed too.
I've already seen one poster on this newsgroup who was angry
at his Motif vendor and wanted to sell his copy of Motif. That blame
is misplaced. What is really needed is a statement from XFree86
explaining what technical benefits they saw that outweighed the
substantial costs of unnecessarily breaking binary compatability.
--
Adam J. Richter Yggdrasil Computing, Incorporated
(408) 261-6630 "Free Software For The Rest of Us."
------------------------------
From: adam@yggdrasil.com (Adam J. Richter)
Crossposted-To: comp.windows.x.i386unix
Subject: Re: New Motif lib's for use with XFree 3.1 ?
Date: 12 Oct 1994 19:55:22 GMT
I wrote:
> For whatever reason, XFree86 chose to ignore our jump tables
>(which were publicly announced and anonymously FTPable), and instead
>decided to build incompatible jump tables. Perhaps XFree86 had some
>technical reason for doing this, but I have yet to hear one.
I meant to say:
"Perhaps XFree86 had some good technical reason for doing
this [...]" ^^^^
I did get a message from one XFree86 memeber who didn't
do the linux shared library support who said that his recoolection was
that it was because "there were no guarantees about binary
compatability."
--
Adam J. Richter Yggdrasil Computing, Incorporated
(408) 261-6630 "Free Software For The Rest of Us."
------------------------------
From: gbruell@wellfleet.com (Greg Bruell)
Crossposted-To: comp.os.linux.help
Subject: Re: 3c503 problem
Date: 12 Oct 1994 02:52:30 GMT
Thank you very much for the pointers. I was able to get things working
by shadowing the card memory. I don't know how to disable caching
on that region. I made 64k starting at 0xC8000 shadowed via the bios.
I appologize if this was all in a HOWTO. I did try to read up before
posting although this does seem like a subtle configuration issue.
Gregory Bruell
Wellfleet Communications, Inc.
Donald Becker (becker@cesdis.gsfc.nasa.gov) wrote:
: In article <37bnah$77l@paperboy.wellfleet.com>,
: Greg Bruell <gbruell@wellfleet.com> wrote:
: >OK. I've done some more homework. Based on looking at net/inet/dev.c
: >to find where /proc/net/dev is created I found the stat rx_errors.
: >I grepped for that and found it in several places but the only place
: >in the 3c503 driver was actually in the file 8390.c. Here's the code:
: >
: [omitted]
: ...
: >Based on a suggestion someone sent me I tried programmed IO mode.
: >This worked better but not reliably. I'm not shadowing memory
: >according to my BIOS setup but the idea that this is related to
: >memory/IO conflicts seems plausible.
: If programmed-I/O mode works and shared memory doesn't, you have a hardware
: conflict. The shared memory memory region 1) must not conflict with other
: adaptors RAM *or* ROM 2) must not be shadowed and 3) must not be cached.
: You've ruled out #2, but have you checked your BIOS setup for #3?
: (BTW, programmed-I/O on the 3c503 is, uhmmm, "rather low performance" to put
: it kindly.)
: >One last thing is that ARP works even though nothing else does.
: ARP on the remote machine because it looks at the address of the packet you
: transmitted. You don't need bidirectional traffic! (I've used this as a
: debugging data point -- if the remote machine knows the ethernet address,
: the Tx packets are getting through.
: --
: Donald Becker becker@cesdis.gsfc.nasa.gov
: USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
: Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771
: 301-286-0882 http://cesdis.gsfc.nasa.gov/pub/people/becker/whoiam.html
------------------------------
Crossposted-To: comp.os.linux.help
From: "Eric Jeschke" <jeschke@cs.indiana.edu>
Subject: Re: Question about ext2fs
Date: Tue, 11 Oct 1994 16:36:24 -0500
"Eric Jeschke" <jeschke@cs.indiana.edu> writes:
:latest victim is the superblock on the root partition. I am able
:to e2fsck the partition using the -b 8193 option and averything seems
:fine, however the system fails to mount it at bootup even though
:I added sb=8193 to the mount options in /etc/fstab for /.
:How can I successfully boot from this partition now?
I realize that / has to be mounted read-only before init will
spawn the rc that eventually mounts things from /etc/fstab...
My question is: do I have to specify the mount option sb=8193
(or something else) to lilo? Or is there some way to flag
an alternate (default) superblock in the ext2fs itself.
I mapped out block 1 (superblock?) of the partition using the -L
option in e2fsck. I thought that maybe if the bad block list showed
block 1 to be bad ext2fs would automatically try 8193, then ...
I guess not?
Sorry about the cross-post, but regardless of the problem I am
interested in finding out how heavily ext2fs is hitting on disk
"hot spots". I work out my disks pretty heavily under Linux;
my last disk (a Maxtor) gave out still under warranty and they
sent me this Seagate, which seems to be even crummier, it is
developing bad blocks at an alarming rate...
--
Eric Jeschke | Indiana University
jeschke@cs.indiana.edu | Computer Science Department
------------------------------
** 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
******************************