From: jes@grendel.demon.co.uk (Jim Segrave) Subject: Re: Defrag'ers and SZ prob's Date: Sun, 12 Sep 1993 22:31:38 +0000
In article <270383$l8k@usenet.rpi.edu> ryanm4@rpi.edu writes:
>
>|> Also, sometimes when uses try to use sz and download, they encounter
>|> lots off errors. I am gettying the port the modem is on at
>|> 19.2 baud [using a HS 14.4k]. I have CTS/RTS one, but regardless
>|> of the callers speed, I still encounter problems. Actually, I
>|> have had this same problem on other Unix machines as well
>|> [SunOS, Ultrix, etc].... Thank!
>|>
>
> I have experienced the same problem - I have noticed that the error occurs
>when the comm program writes what it has to disk. it may be just a
>coincidence, but wouldn't that mean that the incoming data is overflowing?
>I dunno....just a wild stab. I would appreciate a real answer, though, if
>anyone knows whats going on.
>
The hard disc driver disables interrupts while it transfers a sector's
worth of data to the disc controller, using a rep outsb instruction. If
your hard disc controller is on the ISA bus (as most of them are), this
can cause overruns on machines without 16550 serial chips. The best fix
is to replace your serial chip with a 16550. If you can't do this (I can't
since my machine is a notebook with no expansion slots and an VLSI do-it-all
chip that emulates 16450s).
Disc writes, particularly sync calls, seem to cause overruns more than
reads do. If you are feeling brave, you can modify the source of hd.c
to enable interrupts during the transfer (further disc interrupts are
already disabled in the 8259). Find the occurences of port_read() and
port_write() in linux/kernel/blk_drv/hd.c. Add an sti() call before
each one, and for those calls which are not immediately followed by
an sti(), add a cli() call just after the port_read/port_write.
Warning:
I've been using these patches for a few months now without incident.
However, Linus posted the following comment in re. these patches:
> Yes, interrupts are disabled in hd.c a bit too much, but there is
> actually a reason for this: anything else seems to result in corruption
> on some machines. I was playing around with interrupt latency a year
> ago (how time flies), and there were terrible problems for some people
> when I enabled interrupts a bit more in the actual transfer routines.
> It worked for almost everybody, but the people it broke for got fs
> corruption almost constantly, so... The solution for speeds over 9600
> bps is probably still to get a 16550, I'm afraid, although you can try
> to enable interrupts in your personal kernel, of course.
>
> Linus
So if you want to try this, *back up your system* and be sure you
are running e2fsck on bootup, using bootutils etc.
-- Jim Segrave (Segrave Software Services jes@grendel.demon.co.uk)