Files
oldlinux-files/docs/mail-archive/linux-devel/Volume1/digest5XX/digest527
2024-02-19 00:23:35 -05:00

495 lines
20 KiB
Plaintext

Subject: Linux-Development Digest #527
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, 7 Mar 94 20:13:12 EST
Linux-Development Digest #527, Volume #1 Mon, 7 Mar 94 20:13:12 EST
Contents:
Re: Mac FS, anyone? (Jonathan Magid)
TTY overruns cost money. (Nemosoft Unv.)
Re: Why not put cluster diffs in nominal kernel before 1.0? (Matthias Urlichs)
Re: Amiga FileSystem, Anyone? (Matthias Urlichs)
Re: Screensaver w/ power save ? (Matthias Urlichs)
Re: QUERY: Assembler Code Perversion (Rob Janssen)
Re: Amiga FileSystem, Anyone? (Rob Janssen)
Re: Amiga FileSystem, Anyone? (Rob Janssen)
Re: eth0: transmit timed out in PL15h (Chris Mathes)
Severe installation problems with Slackware 1.1.2 (David Kastrup)
Re: Specialix driver (Jay Denebeim P025)
----------------------------------------------------------------------------
From: jem@sunSITE.unc.edu (Jonathan Magid)
Subject: Re: Mac FS, anyone?
Date: 7 Mar 1994 15:17:12 GMT
In article <KAYVAN.94Mar6231410@satyr.sylvan.com>,
Kayvan Sylvan <kayvan@satyr.Sylvan.COM> wrote:
>Does anyone know a way I can read a Mac 1.4MB floppy on Linux? My Mac
>is an old Mac Plus (720K floppy drive) and it's connected to my Linux
>box. If I can read files onto Linux, I can just suck them over the
>line to the Mac.
There is a program to do this under Linux, you can get it
<a href="ftp://sunsite.unc.edu/pub/Linux/utils/disk-management/xhfs0_3.tgz>
here </a>
jem.
------------------------------
From: nemosoft@void.tdcnet.nl (Nemosoft Unv.)
Subject: TTY overruns cost money.
Date: Mon, 7 Mar 1994 03:15:29 GMT
Since Linux 0.99 pl 15, I've seen these messages about 'tty overruns' with a
number that's the minor of the tty-line.
There were only a few, and caused no harm, until now. Today I was
downloading my mail & news, and in the mean time editing a large file.
Editing was done, I write the file, and then hell breaks loose:
tty67: input overrun
tty67: input overrun
tty67: input overrun
....
Etc. etc. scrolling my console so fast I can't even switch terminals (not
that can I get rid of them 'cause they are on the console). And mind you,
this is at
2400 !!
baud. The significance of that being that even at that low speed, input
overruns make my computer useless. The solution is to pull out the modem and
thus hang up the connection, causing serial communication to stop :-(.
On our central server, things are even worse: when dialing out to our Usenet
provider with our V42bis modem, after a few minutes of communication the
dataflow slows to a crawl (but only a few overruns are being generated),
with lots of pauses, effectively doubling our online time. In other words:
this costs money.
Now I "solved" this, by commenting out the 'printk' line from
drivers/char/tty_io.c, actually to get rid of this junk on the console but
that also had a positive effect on the stalling of the dataflow. Perhaps
because less time is spent in the kernel printing the messages.
First, a few observations:
-overruns seem to be generated when there's heavy diskaccess.
-also when a second serial line (on a different IRQ, yes) some heavy traffic
is going on.
-on my 2400 baud link, the overruns seem to be generated from an endless
loop, rather than on a 'message per byte' rate.
All serial ports are 16450s. Oh yeah: even with overruns, I don't loose
data.
Now my questions:
-What is the significance of the Overrun bit in the UART that it allows for
so much junk on my console ?
-What is this bit actually for ? Is it perhaps something from the 16550A
that has another meaning on 16450 etc. ?
-Why is now payed attention to this bit ?
And a few remarks:
-I saw recently announced patches for the serial driver, that would spend
even more time in the hardware-interrupt handler. The argument of the
writer being that too much copying to and from buffers was done, and could
be handled more effectively then.
I'm afraid this will lead to only more problems, in that you must have a
very fast computer to actually run your modem at a reasonable speed.
Are their any plans on incorporating this code into linux permanently ?
--
I always cry when I have to reboot Linux to return to DOS... *sniff*
------------------------------
From: urlichs@smurf.noris.de (Matthias Urlichs)
Subject: Re: Why not put cluster diffs in nominal kernel before 1.0?
Date: 7 Mar 1994 22:46:43 +0100
In comp.os.linux.development, article <CM0oGy.Ky5@qus102.qld.tne.oz.au>,
pclink@qus102.qld.tne.oz.au (Rick) writes:
>
> Thanks for the fix. Have you come across a fix for a kernel panic that
> says "Free list contains shared buffers"? I got this last night - the
> system was relatively quiet, having finished a fairly large compile
> (lots of swapping) about 15 minutes earlier.
>
Nope. I saw it today, too. :-(
--
Die Struktur einer ambivalenten Beziehung beeintraechtigt das visuelle und
kognitive Wahrnehmungsvermoegen extrem.
--
Matthias Urlichs \ XLink-POP N|rnberg | EMail: urlichs@smurf.noris.de
Schleiermacherstra_e 12 \ Unix+Linux+Mac | Phone: ...please use email.
90491 N|rnberg (Germany) \ Consulting+Networking+Programming+etc'ing 42
Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.
------------------------------
From: urlichs@smurf.noris.de (Matthias Urlichs)
Subject: Re: Amiga FileSystem, Anyone?
Date: 7 Mar 1994 22:51:45 +0100
In comp.os.linux.development, article <CM9o8r.1Fu@usenet.ucs.indiana.edu>,
bdwheele@silver.ucs.indiana.edu (Sprag Johnson) writes:
>
> Um.....if the mac doesn't use a 'standard format' how is it that I can
> read mac (1.44) disks in my pc? Granted, I had to use a shareware reader to
> do it, but the hardware is capable....
The Mac uses the "standard format" for HD disks only. DD floppies are
written in GCR, which is unreadable with MFM controllers.
--
How many people work here?
Oh, about half.
--
Matthias Urlichs \ XLink-POP N|rnberg | EMail: urlichs@smurf.noris.de
Schleiermacherstra_e 12 \ Unix+Linux+Mac | Phone: ...please use email.
90491 N|rnberg (Germany) \ Consulting+Networking+Programming+etc'ing 42
Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.
------------------------------
From: urlichs@smurf.noris.de (Matthias Urlichs)
Subject: Re: Screensaver w/ power save ?
Date: 7 Mar 1994 22:57:58 +0100
In comp.os.linux.development, article <CM8Jz9.ML@seneca.ix.de>,
hm@seneca.ix.de writes:
> A kernel config variable would be good IMHO because I don't know what
> ordinary monitors do without sync pulses (snow?).
>
Ordinary monitors should be blank in that case. After all, no sync pulses
are not distinguishable from a monitor that isn't plugged into the video
card in the first place.
Snow is just noise. No source for the noise (like a tuner between stations,
which is where "normal" TV noise comes from), therefore no snow.
--
The universe is one of God's thoughts.
-- Friedrich Schiller
--
Matthias Urlichs \ XLink-POP N|rnberg | EMail: urlichs@smurf.noris.de
Schleiermacherstra_e 12 \ Unix+Linux+Mac | Phone: ...please use email.
90491 N|rnberg (Germany) \ Consulting+Networking+Programming+etc'ing 42
Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.
------------------------------
From: rob@pe1chl.ampr.org (Rob Janssen)
Subject: Re: QUERY: Assembler Code Perversion
Date: Mon, 7 Mar 1994 20:11:30 GMT
Reply-To: pe1chl@rabo.nl
In <1994Mar6.102501.1965@penrij.UUCP> soup@penrij.UUCP (John R. Campbell) writes:
>I'm willing to bet that this is NOT the right group to post this Question
>(but I will anyway).
>I've been handed a sh*tload of MASM source code for the 386/486 (SCO UNIX)
>and I need to convert it to a _REAL_ assembler (GAS on Linux, of course).
>Anybody have any dirty tricks???
Write a translator using UNIX tools (e.g. sed, awk, yacc/lex or whatever
seems most appropriate)
>It generates that GodForsaken "x.out" format favored by MicroSloth which
>NOBODY can disassemble (If only "sourcer" could generate REAL assembler).
That barely seems to the point when you want to translate the source...
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: Amiga FileSystem, Anyone?
Date: Mon, 7 Mar 1994 20:13:56 GMT
Reply-To: pe1chl@rabo.nl
In <CM9o8r.1Fu@usenet.ucs.indiana.edu> bdwheele@silver.ucs.indiana.edu (Sprag Johnson) writes:
>In <1994Mar6.130716.5368@pe1chl.ampr.org> rob@pe1chl.ampr.org (Rob Janssen) writes:
>>In <DHOLLAND.94Mar5232531@husc7.harvard.edu> dholland@husc7.harvard.edu (David Holland) writes:
>>>The strange stuff the trackdisk.device does should be possible with PC
>>>hardware, unless that hardware is even less capable than I thought. If
>>>the Amiga does something else, like write more tracks than the average
>>>PC drive can access, I don't know about it.
>>The PC has a specialized floppy disk controller that understands and
>>handles the industry-standard MFM format of formatting diskettes.
>>The Amiga does not use that standard format (and neither does the Mac)
> Um.....if the mac doesn't use a 'standard format' how is it that I can
>read mac (1.44) disks in my pc? Granted, I had to use a shareware reader to
>do it, but the hardware is capable....
> Brian
The newer macs (those that can write 1.44 disks) have PC-compatible disk
controller hardware as well. The older (800K) disks cannot be read on a PC.
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: Amiga FileSystem, Anyone?
Date: Mon, 7 Mar 1994 20:21:12 GMT
Reply-To: pe1chl@rabo.nl
In <DHOLLAND.94Mar7045618@husc7.harvard.edu> dholland@husc7.harvard.edu (David Holland) writes:
>rob@pe1chl.ampr.org's message of Sun, 6 Mar 1994 13:07:16 GMT said:
> > Classification of 'more or less capable' is entirely yours. I would say
> > the PC disk controller is more capable, in that it handles tasks that
> > need to be done in software on the Amiga and Mac.
>Hmm, I'd say "capable" means "able to accomplish things". It seems to
>me that drive hardware that can read a wider range of disk formats is
>more capable. This is what the end user sees; only the BIOS or device
>driver writer sees how much internal processing is done. I dunno.
>Meaningless point to argue.
I don't agree with you. But indeed it is meaningless to argue about.
> > >Yes, I have. It's amazing that it can be done at all, however
> > >poorly... :-)
> >
> > Please explain what is poor about it?
> > This seems to be just a general case of DOS-bashing. When you don't
> > know what you are talking about, please don't.
>The network redirector is a mess, not well documented, and notoriously
>difficult to cope with. Why do you think we don't see alternate
>filesystems (such as for Mac floppies) for the PC that use it? All we
>have is a few network packages from big companies with lots of
>resources, like Novell and Sun.
Microsoft's policy is to not give out documentation about programming
interfaces except the most required ones. While I agree that this is
not good, I don't agree that we don't see alternate filesystems.
Linux' dosemu *does* have a filesystem redirector.
>Yes, it does work, mostly. Why do various ordinary tools refuse to
>cooperate with network drives? This problem is not limited to
>low-level disk utilities or anything, you know.
Because they written with bad assumptions. Period.
Programs that do only file I/O have no problems whatsoever with redirected
drives. Those that want to be 'clever' will lose.
E.g: those stupid N***** tools that insist on scanning the entire directory
structure of a disk before even presenting a first user choice. And when
they have scanned part of the 40000-file network disk they run out of memory
and bomb out. lose lose...
> > (I am no DOS fan. not at all, even. but saying things that just plainly
> > aren't true is not the way to handle even DOS)
>Are you absolutely sure I'm the one who doesn't know what he's talking
>about? :-) :-)
I still think so.
Rob
--
=========================================================================
| Rob Janssen | AMPRnet: rob@pe1chl.ampr.org |
| e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU |
=========================================================================
------------------------------
From: chris@metter.fmpmis.metter.com (Chris Mathes)
Subject: Re: eth0: transmit timed out in PL15h
Date: Mon, 7 Mar 1994 21:37:21 GMT
becker@super.org (Donald J. Becker) writes:
>In article <2l58o0$mv7@senator-bedfellow.mit.edu>,
>Erik Nygren <nygren@athena.mit.edu> wrote:
>>I've been getting messages like:
>>
>>Mar 3 11:16:50 foundation kernel: eth0: transmit timed out, tx_status 00 status
>> 2000.
>I think I have a fix for this problem.
>[fix deleted.]
>If anyone still encounters problems after applying this patch please let me
>know.
Yup, transmit timeouts are now a thing of the past. But what does this mean:
"eth0: Missed interrupt, status then 2011 now 2011 Tx 00 Rx 384a."
This happens once after a cold or warm boot; seemingly the first time packets
are sent out after booting.
Linux bravo pre-1.0 #1 Mon Mar 7 11:57:20 GMT 1994 i386
-Chris
--
Chris Mathes, Metters Industries, Inc. UUCP: {..!}uunet!metter!chris
Tel:(703)418-0323 INET: chris@metter.com
"The Tao of Programming flows far away and returns on the wind of morning."-TToP
------------------------------
From: dak@hathi.informatik.rwth-aachen.de (David Kastrup)
Subject: Severe installation problems with Slackware 1.1.2
Date: 7 Mar 1994 23:15:06 GMT
Of course here several factors were at work... At first, the documentation
was lacking any information as to what interrupts and I/O-addresses were
tried for what. (I have a 386SX16 here, TMC885 SCSI controller, WD8003
Network card, 1.2meg boot, 1.4meg second floppy). As a result, I lost one
day, until I found out that changing the default I/O-address of the WD8003
Card to 300h from the default of 280h would allow booting. There is no
conceivable address conflict, but the system hung after displaying the
shared memory address of the Network card (0xd0000, regardless of
I/O address).
Furthermore, tty12 in the 1_2meg directory was simply unsuitable for
bootstrapping. One had to rdev -r the boot disk for a ramdisk size of 1440,
and had to use the boot option of ramdisk root=/dev/fd1, so that one could
boot from the second floppy, where the root image was better.
The boot process (while it is displaying `loading ramdisk' on the boot
disk) is painstakingly slow, as the code does not seem to be able to load
consecutive sectors on my machine in the same disk revolution. Formatting
the boot disk with a skew would help, but alas, neither DOS nor Linux
offers this.
fdisk ing the hard disk was a complicated process. Because of problems with
the real sector/cylinder numbers (1780 cylinders led to lots of warnings)
I decided to enter the BIOS fake numbers (64 heads, 32 sectors, 323
cylinders instead of 7,54,1780). So far, so well.
However, fdisk complained that I had to specify cyl, sec, head in the
special functions menu. That done everything worked.
Unfortunately, however, fdisk -l is called several times in the setup
menu. Not given the cyl, sec, head values, it will list the first line
and then abort with a floating point exception, as it assumes them to
be 0,0,0, and seems to be wanting to calculate something.
This stops the setup short in its tracks.
I am now going to replace fdisk with a shell script which will, when called
with -l, just reproduce the appropriate output, and if called with other
options, will call the original. This is going to be still a bunch of work.
The manual entry to fdisk says that the real info to the command is to
be found in fdisk.README, which should be with every distribution. It
is not (strictly speaking, as I have the system not yet running, this
applies to the older version on the other computer I consulted, I believe
Slackware 1.1.0. Also here are a considerable amount of man pages with
extension .z, which man will probably not find).
This is all particularly frustrating as on the other machine Slackware
1.1.0 installed like a charm (other HD controller). On this machine,
however, I've been fighting for several days now, but will hopefully
get through soon.
I want to especially note that none of all of these problems was properly
treated in any HOWTO or README. Especially hard to conceive was that one
had to set the ramdisk size to 1440 by first mounting the bootdisk,
doing an rdev -r /vmlinuz 1440 ON ITS /vmlinuz FILE, but had to specify
root=/dev/fd1 on the boot prompt instead.
It's been a long time since I have felt that stupid.
--
David Kastrup dak@pool.informatik.rwth-aachen.de
Tel: +49-241-72419 Fax: +49-241-79502
Goethestr. 20, D-52064 Aachen
------------------------------
From: denebeim@bnr.ca (Jay Denebeim P025)
Subject: Re: Specialix driver
Date: Mon, 7 Mar 1994 21:39:31 GMT
In article <1994Mar1.143313.25803@swan.pyr> iiitac@swan.pyr (Alan Cox) writes:
>It would be OK I guess, not ideal and I don't like it - I certainly wouldn't
>buy the card.
Why? Does this mean you've got the source to your BIOS ROM? How
about the ROM on your video card? (hey, if you've got a Diamond, I
bet there's a bunch of people who would like to talk to you) If not,
why is this card any different?
I don't know anything about the card that you ended up with, does it
have an on-board processor? Do you have the source code for that, or
do you just know what its interface is? If its the latter you're
getting exactly what the guy from digiboard is offering.
The fact that they've got eeprom/static ram on their board is a nice
feature IMO. Heck, to get around this whole mess, why doesn't the
original author just ship complete source, all you have to do is
provide a program that takes the files on the disk that Digiboard
products come with and make a .o or .a file out of it. Easy. Now,
all the source applicable to Linux is available. You now won't even
need to give the object code to people who didn't buy the hardware.
Also, I really hope that Digiboard does this, I have to use a
stand-alone IMAC instead of a digiboard card because they don't have
linux drivers for it. An application we have here at work could be
using a Linux box with a bunch of digiboard cards in it rather than a
smaller stack of IMACs if this were the case.
Jay
--
Jay Denebeim Address: UUCP: duke!wolves!deepthot!jay
Internet: jay@deepthot.cary.nc.us
BBS:(919)-233-9937 VOICE:(919)-233-0776
------------------------------
** 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
******************************