lostecho/oldlinux-files
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
master
oldlinux-files/mail-archive/linux-devel/Volume1/digest5XX/digest595
gohigh a778c607a4 add directory mail-archive
2024-02-19 00:25:02 -05:00

813 lines
31 KiB
Plaintext
Raw Permalink 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: Fri, 1 Apr 94 17:13:07 EST
Subject: Linux-Development Digest #595
Linux-Development Digest #595, Volume #1 Fri, 1 Apr 94 17:13:07 EST
Contents:
Re: Are ADDTRON AE-200LC/JL network cards supported? (Byron A Jeff)
Re: Slackware as a tar.gz file? (Carlos Y. Villalpando)
mt commands that won't work (Wolfgang Feldmann)
Re: PC as C64 file server (Mark A. Davis)
Sparc Audio API for Linux's /dev/audio (Jon Cardwell)
Re: 486DLC support anyone? (spu@delphi.com)
Re: PC as C64 file server (SLADIC DANIEL)
Re: Magic of .. (Re: Amiga FileSystem, Anyone?) (Kevin Brown)
Re: Amiga FileSystem, Anyone? (Kevin Brown)
Question about WD420 with IDE performance package (Glenn Koh)
Re: cluster-patches lead to error on fsync (Clayton Haapala)
Re: Raw parallel port device? (Michael K. Johnson)
Re: IDE Performance Package (Mark Lord)
Patch for IDE performance on second AT controller (David Monro)
----------------------------------------------------------------------------
Crossposted-To: comp.os.linux.admin
From: byron@cc.gatech.edu (Byron A Jeff)
Subject: Re: Are ADDTRON AE-200LC/JL network cards supported?
Date: Fri, 1 Apr 1994 03:36:14 GMT
In article <1994Mar29.204159.13138@mksol.dseg.ti.com>,
Bob Myers <bmyers@dseg.ti.com> wrote:
>I've just seen the ad for getting these cards at $19/29 respectively (limited 2 cards per customer).
>Would they both work with the .99p15 and above kernels, since they are NE2000 clones? Likewise,
Tyr to keep it under 78 character please. Real head to edit otherwise.
They most definitely work.I get upwards to 500 kB/sec with them.
>since the AE-200JL is software configurable vs the AE-200LC's hardware jumpered, is there a utility
>to configure it (or others that are software configurable)?
Get the jumpered ones. You won't regret it.
BAJ
>
>thanks
>
>bob
>p.s. ad was in March '94 edition of LAN magazine, page 77
>
>
>
---
Another random extraction from the mental bit stream of...
Byron A. Jeff - PhD student operating in parallel!
Georgia Tech, Atlanta GA 30332 Internet: byron@cc.gatech.edu
------------------------------
From: unbelver@brain.jpl.nasa.gov (Carlos Y. Villalpando)
Subject: Re: Slackware as a tar.gz file?
Date: 30 Mar 94 03:44:08 GMT
In article <CnG7Ew.4z9@synoptics.com> jkaidor@synoptics.com writes:
>In article 94Mar25210418@first.cs.nyu.edu, fox@graphics.cs.nyu.edu (David Fox) writes:
>>In article <gat-240394180427@137.79.107.114> gat@robotics.jpl.nasa.gov (Erann Gat) writes:
>>
>>] Does anyone have the Slackware 1.2.0 distribution assembled into a
>>] tar file? It would be nice to be able to snarf the whole thing without
>>] having to do fifty cds, lcds, and mgets.
>>
>>cd to ftp.cdrom.com:pub/linux and do a "get slackware.tar".
>>The resulting file is 75 meg...
>
> I dreamt of a script that would activate FTP, tell it to get
>slackware.tar, and pipe its
>output straight up to tar on my machine, which would then spew out files
>and directories.
>Probably an impossible dream......
>
get slackware.tar "|tar xvf -"
Oh, and uh, your post is greater than 80 columns wide. Emily Postnews
wouldn't be happy.
--Carlos V.
--
========================================================================
Carlos Y. Villalpando | Don't even think I speak for the Gov't
unbelver@brain.jpl.nasa.gov | I also didn't screw up the Mars Observer
unbelver@ccwf.cc.utexas.edu | (There was that button I sat on......)
------------------------------
From: wolle@ancient.trillium.se (Wolfgang Feldmann)
Subject: mt commands that won't work
Date: Wed, 30 Mar 1994 21:49:44 GMT
I wonder if it's supposed to be so that mt commands others than erase,
reten, rewind or weof won't work. I'm using linux 1.0, the newest
ftape and slackware's mt.
I'm longing for beeing able to back up more than one tar file to a tape.
Wolfgang
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Wolfgang Feldmann email: wolle@ancient.trillium.se
wolle@cd.chalmers.se
fidonet: 2:203/311.11 wolle@solace.mh.se
------------------------------
From: mark@taylor.wyvern.com (Mark A. Davis)
Subject: Re: PC as C64 file server
Date: 30 Mar 94 03:47:09 GMT
k-garner@ux4.cso.uiuc.edu (Garner Keith Thomas) writes:
>acbul1@lindblat.cc.monash.edu.au (Andrew Bulhak) writes:
>>Sven Goldt (goldt@math.tu-berlin.de) wrote:
>>: paul (paul@dino.eng.monash.edu.au) wrote:
>>: : Ok,
>>: : It seems quite clear that there is a need for a device that allows
>>: : a standard ibm pc to be used as a file server for our humble ol' Commodore
>>: : 64's. Is anyone working on such a device? What do people think about the idea?
>>: : Is it possible ??
It seems like it would be a lot easier to use a better obsolete system, like
the Tandy COCO's running a real OS; one which is semi-multi-user, fully
multitasking, re-entrant, kernel/driver designed, multi-windowing, etc
...... OS-9 :) Hard to believe, isn't it! It was my start before I jumped
into Unix. It is still impressive, even today.
--
/--------------------------------------------------------------------------\
| Mark A. Davis | Lake Taylor Hospital | Norfolk, VA (804)-461-5001x431 |
| Sys.Administrator| Computer Services | mark@taylor.wyvern.com .uucp |
\--------------------------------------------------------------------------/
------------------------------
From: jdc@inca.cs.wayne.edu (Jon Cardwell)
Crossposted-To: comp.os.linux.misc
Subject: Sparc Audio API for Linux's /dev/audio
Date: 31 Mar 1994 01:15:06 GMT
I'm currently 'porting a program that wants to run
on a Sun Sparc's native sound hardware. This program
wants to be linked with libaudio.a, which is commonly
found in /usr/demo on sparc's. Anyways, since there's
a /dev/audio device under Linux, and I can play .au
sound files simply by doing "% cat foobar.au > /dev/audio".
Since I'm using Linux v1.0 and have the Sound Driver v2.4
linked into the kernel, I was wondering if anybody has
bothered to 'port the sun's libaudio.a library to
interface with the linux /dev/audio.
Well???
--Jon Cardwell
Wayne State University.
------------------------------
From: spu@delphi.com
Subject: Re: 486DLC support anyone?
Date: Fri, 1 Apr 94 01:26:39 -0500
Raymond E. Rogers <rrogers@netcom.com> writes:
> Funny you should mention this. It might be out of place but I
>have a UMC386 ISA BUS motherboard, with 486 DLC-33, 128k external
>cache, and no co-proc. I must disable the internal cache to work
>reliably at all! Otherwise I get random disasters. Is there a magic
>formula for this?
Okay, this is getting spooky... that is the same motherboard I am using...
I am beginning to suspect that the problem may be the motherboard after all..
Other people don't seem to be having the same problems with the same chip set
on other boards...
I was also getting random instances of the bios reporting a co-proc when there
was none....
Time to swap mom-board out I believe...
Sean
------------------------------
Crossposted-To: comp.sys.cbm
From: sladic@ecf.toronto.edu (SLADIC DANIEL)
Subject: Re: PC as C64 file server
Date: Fri, 1 Apr 1994 10:39:08 GMT
In article <1994Mar31.005200.23783@mnemosyne.cs.du.edu>,
Roloc <mparson@nyx10.cs.du.edu> wrote:
><lots of stuff about linux deleted>
>
>Ok, I think you guys are making this entirely too complicated. When I
>started this thread a few weeks back,I was talking about turning my XT,
>which is serving as a dust holder right now, into a simple file-server or
>hard-drive controller for the 64/128 which I use all the time. I dont
>have, and dont think it would work if I did have it, Linux. I was just
>thinking that it would be nifty if you could write an app for the dos
>environment that would take a disk image (.d64?), then you could type
>LOAD "$",8 on the C= and boom, you would get a dir. Then you could load
>and play the games off the XT's HD like it was a 15X1 drive. All this
>stuff would be entirely transparent to the C=, I think this is important
>as to aloow for maximum compatibility.
>
Now I don't know anything about PC architecture but what would seem like the
easiest things to do is hook the ATN lines from the serial bus to some
interrrupt pin on the PC, and hook the other lines to some data in/out pins.
I've actually wrote some routines to load/save usin solely serial line
manipulation but I think for full compatability with the 64 you'd have to
rewrite the drive rom is 80X86 (or less) assembly.
I could be wrong, but this doesn't seem too dificult. (Oh also, after the
drive/file server has responded to ATN, it can take as long as it wants to
reply to other signals, so it may even be possible under an OS like Linux.)
Dan Sladic
sladic@ecf.toronto.edu
------------------------------
From: kevin@frobozz.sccsi.com (Kevin Brown)
Subject: Re: Magic of .. (Re: Amiga FileSystem, Anyone?)
Date: Wed, 30 Mar 1994 18:08:35 GMT
In article <2n278k$p2u@hera.fmi.fi> hurtta@dionysos.fmi.fi (Kari E. Hurtta) writes:
>gt8134b@prism.gatech.edu (Robert Sanders) writes:
><3E>kevin@frobozz.sccsi.com (Kevin Brown) writes:
><3E>>The "." and ".." restriction is a bit tougher to get around, however...
><3E>Er, what? Linux isn't like DOS, and those aren't special reserved names. Those
><3E>are links created when you make the directory: "." is a link to the directory
><3E>containing it, and ".." is a link to the parent directory, unless you're in /
><3E>when it's a link to ".".
>
>No. There must be special interpreting of ".." because kernel must keep
>track of chrooted environments. Another point, where special interpreting
>of ".." is required, is mountpoints.
This is true in terms of how it does it now, but it needn't be that
way, since the code can (in principle) inquire of the filesystem what
it considers to be the equivalent of "..".
It would be pretty interesting to use a filesystem that didn't have
any concept of directories...
--
Kevin Brown kevin@frobozz.sccsi.com
This is your .signature virus: < begin 644 .signature (9V]T8VAA(0K0z end >
This is your .signature virus on drugs: <>
Any questions?
------------------------------
From: kevin@frobozz.sccsi.com (Kevin Brown)
Subject: Re: Amiga FileSystem, Anyone?
Date: Thu, 31 Mar 1994 21:56:58 GMT
In article <CnApJJ.B0w@metronet.com> skip@metronet.com (Christopher Key) writes:
>In article <Cn6yFA.2uy@frobozz.sccsi.com>,
>Kevin Brown <kevin@frobozz.sccsi.com> wrote:
>>
>>However, DOS supports *no* variability at all in filenames. It *insists* on
>>the 8+3 rule, period.
>>
>Well, I normally don't get into these OS-religious flames, but you
>obviously haven't thought this through very much. The problem isn't so
>much that the operating system forces 8.3 but that non 8.3 filenames break
>the existing _applications_. I use both dos and linux, and writing a
>device driver for DOS that would hook the various dos services interrupts
>and provide bigger filenames would probably only be a long weekend hack.
>But too many applications would break for it to be useful. DOS isn't
>perfect (far from it), but it is fairly extendable.
Sigh. I'd better quit while I'm not too far behind. :-)
What I remember when dealing with DOS was that the call interfaces
expected filenames that followed the 8+3 convention.
If the system call interfaces don't have any expectations on what
the filenames are supposed to look like (I don't have access to
any good references anymore, so I can't look it up), then I completely
agree with you (though I would then have to wonder exactly why
applications would break as badly as you seem to imply, notwithstanding
the fact that they would be optimized around an essentially
12-character filename length limit).
But if the system call interface itself has such a restriction,
then replacing the services wouldn't do much good: you'd still have
to adhere, in the interface, to the restriction.
What *could* be done, without breaking existing applications, is
to implement an alternate set of DOS services that explicitly allow
long filenames. Since existing applications wouldn't even use this
interface, you wouldn't break any of them, though they might not
be able to access files created with the new interface. The old
interface would, of course, still be there, and would filter out
any files that didn't meet the 8+3 spec, just as they do now with
things like NFS.
>Skip
--
Kevin Brown kevin@frobozz.sccsi.com
This is your .signature virus: < begin 644 .signature (9V]T8VAA(0K0z end >
This is your .signature virus on drugs: <>
Any questions?
------------------------------
From: gkoh@ATHENA.MIT.EDU (Glenn Koh)
Subject: Question about WD420 with IDE performance package
Date: 1 Apr 1994 17:16:42 GMT
I got the uuencoded form of IDE Performance Package off this group yesterday, and was wondering if it was missing some info or readme files. I'm running off a Western Digital 420 megger and when I try to compile using: cc -O -o etc..
error messages appear.
greenmouse:/ide# cc -O -o /usr/bin/hdparm hdparm.c
hdparm.c: In function `main':
hdparm.c:28: `HDIO_SETMULTIPLE_OFF' undeclared (first use this function)
hdparm.c:28: (Each undeclared identifier is reported only once
hdparm.c:28: for each function it appears in.)
hdparm.c:31: `HDIO_UNMASKINTR' undeclared (first use this function)
hdparm.c:31: `HDIO_MASKINTR' undeclared (first use this function)
Obviously (I think), I have to set these on... what format? Thanks.
------------------------------
From: clay@haapi.mn.org (Clayton Haapala)
Subject: Re: cluster-patches lead to error on fsync
Date: Thu, 31 Mar 1994 22:34:22 GMT
In article <1994Mar29.211140.13880@cetz.rhein-main.de>,
Christopher Etz <cetz@cetz.rhein-main.de> wrote:
>When I use the cluster patches with Linux 1.0, some fsync() calls return
>EIO (unix error 5, "I/O error"). This behavior is the same since several
>releases of Linux and the cluster pathches. The same binaries run well,
>as long as I don't use these patches.
>
>Did anybody encounter this problem? And does this one know of any workaround?
>
I'm sure I told Cnews that fsync() was available, so this is what is causing
relaynews to issue I/O error messages, as I posted previously.
--
Clay Haapala "Well, there was the process of sitting around
clay@haapi.mn.org and wishing I had more computer stuff."
-- Dilbert
------------------------------
From: johnsonm@ladybird.oit.unc.edu (Michael K. Johnson)
Subject: Re: Raw parallel port device?
Date: 01 Apr 1994 13:36:57 GMT
In article <2n77g1$csk@jaws.cs.hmc.edu> bgribble@jarthur.cs.hmc.edu (Bill Gribble) writes:
The only existing drivers using the parallel port (that I have seen) are
PLIP and lp. I need raw parallel output with no handshaking and these
devices don't seem to provide it. Should I just kludge up an output-only
driver or is there enough general interest to write a decent bidirectional
i/o driver?
I recommend editing the lp.c driver and adding an ioctl() which
puts the driver in "raw" mode, or in some other partially cooked
mode. That is something that could be generally useful, from the
messages I have seen relatively recently from people wanting raw
parallel port access.
michaelkjohnson
------------------------------
From: mlord@bnr.ca (Mark Lord)
Subject: Re: IDE Performance Package
Date: 1 Apr 1994 14:12:02 GMT
In article <Apr1.021456.17921@acs.ucalgary.ca> root@fusion.cuc.ab.ca writes:
>mlord@bnr.ca (Mark Lord) writes:
>several weeks now without incident. I think it's a bad idea for the default
>to be unmasked interrupts. In any patch/package where there is a significant
The latest package defaults to "no unmasking" and "no multmode".
--
mlord@bnr.ca Mark Lord BNR Ottawa,Canada 613-763-7482
------------------------------
From: davem@extro.ucc.su.OZ.AU (David Monro)
Subject: Patch for IDE performance on second AT controller
Date: Wed, 30 Mar 1994 17:49:15 GMT
Here is a patch to apply the multimode ide patches to the second harddrive
controller driver created by applying the atdisk2 patches. The patch
is for atdisk2-0.9 patches applied to a v1.0.4 kernel, but should work
for any kernel from pre-1.0 to v1.0.5.
NOTE - for those with Western Digital and recent Conner drives, change
line 327 of the resulting hd1.c from
if ((i = ib[47] & 0xff) >= 32)
to
if ((i = ib[47] & 0xff) >= 16)
Otherwise it will decide that these drives are "older drives" and won't
enable multi mode. This applies to the original patch for hd.c as well
as to this patch for hd1.c
For those with other drives, define VERBOSE_DRIVEID as 1 at the top of
the file and see what the MaxMultSect field is when you boot. If it is
16, you can probably use the same trick, but some drives are known to
have problems, I don;t know which ones though.
Thanks very much to Mark Lord for the original IDE performance package,
and to Delman Lee for the atdisk2 package.
David Monro
--- hd.c.orig Fri Jan 21 12:50:11 1994
+++ hd1.c Sat Mar 12 14:47:45 1994
@@ -14,8 +14,14 @@
*
* Thanks to Branko Lankester, lankeste@fwi.uva.nl, who found a bug
* in the early extended-partition checks and added DM partitions
+ *
+ * IDE IRQ-unmask & drive-id & multiple-mode code added by Mark Lord.
*/
+#define HD_UNMASK_INTR 1 /* set to 0 to mask other IRQs during hd I/O */
+#define VERBOSE_DRIVEID 0 /* set to 1 for more drive info at boot time */
+#define MAX_MULTIPLE 8 /* set to 1 to disable multiple mode support */
#include <linux/errno.h>
#include <linux/signal.h>
@@ -208,6 +213,133 @@
outb_p(cmd,++port);
}
+#define WIN_MULTREAD 0xC4 /* read multiple sectors */
+#define WIN_MULTWRITE 0xC5 /* write multiple sectors */
+#define WIN_SETMULT 0xC6 /* enable read multiple */
+#define WIN_IDENTIFY 0xEC /* ask drive to identify itself */
+
+static int mult_count[MAX_HD] = {0,}, writing_mult;
+
+#if VERBOSE_DRIVEID
+
+char *cfg_str[] =
+{ "", " HardSect", " SoftSect", " NotMFM", " HdSw>15uSec", " SpinMotCtl",
+ " Fixed", " Removeable", " DTR<=5Mbs", " DTR>5Mbs", " DTR>10Mbs",
+ " RotSpdTol>.5%", " dStbOff", " TrkOff", " FmtGapReq", "",
+};
+
+char *SlowMedFast[] = {"slow", "medium", "fast"};
+char *BuffType[] = {"?", "1Sect", "DualPort", "DualPortCache"};
+
+#define YN(b) (((b)==0)?"no":"yes")
+
+static void rawstring (char *prefix, char *s, int n)
+{
+ printk(prefix);
+ if (*s) {
+ int i;
+ for (i=0; i < n && s[i^1] == ' '; ++i); /* strip blanks */
+ for (; i < n && s[i^1]; ++i)
+ if (s[i^1] != ' ' || ((i+1) < n && s[(i+1)^1] != ' '))
+ printk("%c",s[i^1]);
+ }
+}
+
+static void dmpstr (char *prefix, unsigned int i, char *s[], unsigned int maxi)
+{
+ printk(prefix);
+ printk( (i > maxi) ? "?" : s[i] );
+}
+
+static void dump_identity (unsigned int dev, unsigned short ib[])
+{
+ int i;
+ char dashes[] = "\n+-------------------------------------------------------------------+\n";
+ printk (dashes);
+ printk ("hd1%c: Drive Identification Info:\n", dev+'a');
+ rawstring (" Model=",(char *)&ib[27],40);
+ rawstring (", FwRev=",(char *)&ib[23],8);
+ rawstring (", SerialNo=",(char *)&ib[10],20);
+ printk ("\n Config={");
+ for (i=0; i<=15; i++) if (ib[0] & (1<<i)) printk (cfg_str[i]);
+ printk (" }\n");
+ printk (" Default c/h/s=%d/%d/%d, TrkSize=%d, SectSize=%d, ECCbytes=%d\n",
+ ib[1],ib[3],ib[6],ib[4],ib[5], ib[22]);
+ dmpstr (" BuffType=",ib[20],BuffType,3);
+ ib[47] &= 0xFF;
+ printk (", BuffSize=%dKB, MaxMultSect=%d\n", ib[21]/2, ib[47]);
+ printk (" Features: DblWordIO=%s, LBA=%s, DMA=%s",
+ YN(ib[48]&1),YN(ib[49]&0x20),YN(ib[49]&0x10));
+ dmpstr (", tPIO=",ib[51]>>8,SlowMedFast,2);
+ if (ib[49]&0x10 && (ib[53]&1)==0)
+ dmpstr (", tDMA=",ib[52]>>8,SlowMedFast,2);
+ printk ("\n (%s): Current c/h/s=%d/%d/%d, TotSect=%d",
+ (((ib[53]&1)==0)?"maybe":"valid"),
+ ib[54],ib[55],ib[56],*(int *)&ib[57]);
+ if (ib[49]&0x20)
+ printk (", LBAsect=%d", *(int *)&ib[60]);
+ printk ("\n (%s): CurMultSect=%d", ((ib[53]&1)==0)?"maybe":"valid",
+ (ib[59]&0x10)?ib[59]&0xFF:0);
+ if (ib[49]&0x10)
+ printk (", DMA-1w=%04X, DMA-mw=%04X", ib[62], ib[63]);
+ printk ("%s\n",dashes);
+}
+#endif /* VERBOSE_DRIVEID */
+
+static void set_multiple_intr(void)
+{
+ unsigned int dev = DEVICE_NR(CURRENT->dev);
+
+ if (inb_p(HD1_STATUS)&(BUSY_STAT|ERR_STAT)) {
+ mult_count[dev] = 1; /* disable multiple mode */
+ printk (" hd1%c: set multiple mode failed\n", dev+'a');
+ } else {
+ printk (" hd1%c: enabled %d-sector multiple mode\n",
+ dev+'a', mult_count[dev]);
+ }
+ do_hd_request();
+ return;
+}
+
+static void identify_intr(void)
+{
+ unsigned short ib[64];
+ unsigned int dev = DEVICE_NR(CURRENT->dev);
+
+ if (inb_p(HD1_STATUS)&(BUSY_STAT|ERR_STAT))
+ printk (" hd1%c: multiple mode not supported\n", dev+'a');
+ else {
+ insw(HD1_DATA,(char *)ib,64); /* get first 128 ID bytes */
+ sti();
+#if VERBOSE_DRIVEID
+ dump_identity(dev, ib);
+#endif /* VERBOSE_DRIVEID */
+ if (ib[27]) {
+ int i;
+ for (i=27; i<= 46; i++)
+ ib[i] = (ib[i]>>8) | (ib[i]<<8);
+ printk (" hd1%c: %-.40s (%dMB IDE w/%dKB Cache)\n",
+ dev+'a', (char *)&ib[27], ib[1]*ib[3]*ib[6] / 2048, ib[21]>>1);
+ /* skip troublesome older drives with (MaxMult < 32) */
+ if ((i = ib[47] & 0xff) >= 32)
+ mult_count[dev] = MAX_MULTIPLE;
+ else
+ printk (" hd1%c: older drive, multiple mode not enabled\n", dev+'a');
+ }
+ insw(HD1_DATA,(char *)ib,64); /* flush remaining 384 ID bytes */
+ insw(HD1_DATA,(char *)ib,64);
+ cli();
+ insw(HD1_DATA,(char *)ib,64);
+ if (mult_count[dev] > 1) { /* try to enable multiple mode */
+ hd_out(dev,mult_count[dev],0,0,0,WIN_SETMULT,&set_multiple_intr);
+ if (!reset)
+ return;
+ }
+ }
+ do_hd_request();
+ return;
+}
+
static int drive_busy(void)
{
unsigned int i;
@@ -243,6 +375,11 @@
repeat:
if (reset) {
+ for (i=0; i < NR_HD; i++) {
+ if (mult_count[i] > 1)
+ printk (" hd1%c: multiple mode disabled\n", i+'a');
+ mult_count[i] = 1; /* disable multiple mode */
+ }
reset = 0;
i = -1;
#ifndef HD1_DontReset
@@ -310,8 +447,8 @@
static void read_intr(void)
{
- int i;
- int retries = 100000;
+ unsigned int dev = DEVICE_NR(CURRENT->dev);
+ int i, retries = 100000, msect = mult_count[dev];
do {
i = (unsigned) inb_p(HD1_STATUS);
@@ -333,22 +470,33 @@
do_hd_request();
return;
ok_to_read:
- insw(HD1_DATA,CURRENT->buffer,256);
- CURRENT->errors = 0;
- CURRENT->buffer += 512;
- CURRENT->sector++;
- i = --CURRENT->nr_sectors;
- --CURRENT->current_nr_sectors;
+#if HD_UNMASK_INTR
+ sti(); /* permit other IRQs during xfer */
+#endif
+ if ((i = CURRENT->current_nr_sectors) > msect)
+ i = msect;
+ msect -= i;
+ CURRENT->sector += i;
+ CURRENT->current_nr_sectors -= i;
+ insw(HD1_DATA,CURRENT->buffer,(i<<8)-1); /* xfer all but final word */
+ CURRENT->buffer += i<<9; /* incr buffer ptr by byte count */
+ cli(); /* mask IRQs before completing xfer */
+ *((short *)(CURRENT->buffer-2)) = inw(HD1_DATA); /* xfer final word */
+
#ifdef DEBUG
- printk("hd1%d : sector = %d, %d remaining to buffer = %08x\n",
- MINOR(CURRENT->dev), CURRENT->sector, i, CURRENT->
- buffer);
+ printk("hd1%c: read: %d sectors(%d-%d), remaining=%d, buffer=%08x\n",
+ dev+'a', i, CURRENT->sector-i, CURRENT->sector-1,
+ CURRENT->nr_sectors, (int) CURRENT->buffer);
#endif
- if (!i || (CURRENT->bh && !SUBSECTOR(i)))
+ CURRENT->nr_sectors -= i;
+ i = CURRENT->nr_sectors; /* in case it's freed by end_request */
+ if (!CURRENT->current_nr_sectors)
end_request(1);
if (i > 0) {
+ CURRENT->errors = 0;
+ if (msect)
+ goto ok_to_read;
SET_INTR(&read_intr);
- sti();
return;
}
(void) inb_p(HD1_STATUS);
@@ -370,8 +518,19 @@
continue;
if ((i & STAT_MASK) != STAT_OK)
break;
- if ((CURRENT->nr_sectors <= 1) || (i & DRQ_STAT))
- goto ok_to_write;
+ if (!(i & DRQ_STAT)) {
+ if (writing_mult || CURRENT->nr_sectors <= 1) {
+ end_request(1);
+#if (HD_DELAY > 0)
+ last_req = read_timer();
+#endif
+ do_hd_request();
+ return;
+ }
+ } else {
+ if (CURRENT->nr_sectors > 1)
+ goto ok_to_write;
+ }
} while (--retries > 0);
sti();
printk("HD1: write_intr: status = 0x%02x\n",i);
@@ -384,23 +543,19 @@
do_hd_request();
return;
ok_to_write:
- CURRENT->sector++;
- i = --CURRENT->nr_sectors;
- --CURRENT->current_nr_sectors;
+ CURRENT->errors = 0;
CURRENT->buffer += 512;
- if (!i || (CURRENT->bh && !SUBSECTOR(i)))
+ CURRENT->sector++;
+ CURRENT->nr_sectors--;
+ if (!--CURRENT->current_nr_sectors)
end_request(1);
- if (i > 0) {
- SET_INTR(&write_intr);
- outsw(HD1_DATA,CURRENT->buffer,256);
- sti();
- } else {
-#if (HD_DELAY > 0)
- last_req = read_timer();
+#if HD_UNMASK_INTR
+ sti();
#endif
- do_hd_request();
- }
- return;
+ outsw(HD1_DATA,CURRENT->buffer,255);
+ cli();
+ SET_INTR(&write_intr);
+ outw(((short *)CURRENT->buffer)[255],HD1_DATA);
}
static void recal_intr(void)
@@ -482,7 +637,6 @@
for (i=0; i < NR_HD; i++)
recalibrate[i] = 1;
reset_hd();
- sti();
return;
}
if (recalibrate[dev]) {
@@ -490,11 +644,41 @@
hd_out(dev,hd1_info[dev].sect,0,0,0,WIN_RESTORE,&recal_intr);
if (reset)
goto repeat;
- sti();
return;
}
+ if (!mult_count[dev]) {
+ mult_count[dev] = 1; /* as default, disable multiple mode */
+ hd_out(dev,0,0,0,0,WIN_IDENTIFY,identify_intr);
+ if (reset)
+ goto repeat;
+ return;
+ }
+ if (CURRENT->cmd == READ) {
+ unsigned int cmd = mult_count[dev] > 1 ? WIN_MULTREAD : WIN_READ;
+ hd_out(dev,nsect,sec,head,cyl,cmd,&read_intr);
+ if (reset)
+ goto repeat;
+ return;
+ }
if (CURRENT->cmd == WRITE) {
- hd_out(dev,nsect,sec,head,cyl,WIN_WRITE,&write_intr);
+ unsigned int cmd, wcnt;
+ if ((wcnt = mult_count[dev]) > 1
+ && nsect <= wcnt
+ && nsect == CURRENT->current_nr_sectors) {
+ wcnt = (nsect<<8) - 1;
+ writing_mult = 1;
+ cmd = WIN_MULTWRITE;
+ } else {
+ wcnt = 255;
+ writing_mult = 0;
+ cmd = WIN_WRITE;
+ }
+#ifdef DEBUG
+ printk("hd1%c: writing %d sectors(%d-%d), buffer=%08x\n",
+ dev+'a', (wcnt+1)>>8, CURRENT->sector,
+ CURRENT->sector+nsect-1, (int) CURRENT->buffer);
+#endif
+ hd_out(dev,nsect,sec,head,cyl,cmd,NULL);
if (reset)
goto repeat;
if (wait_DRQ()) {
@@ -502,15 +686,13 @@
bad_rw_intr();
goto repeat;
}
- outsw(HD1_DATA,CURRENT->buffer,256);
- sti();
- return;
- }
- if (CURRENT->cmd == READ) {
- hd_out(dev,nsect,sec,head,cyl,WIN_READ,&read_intr);
- if (reset)
- goto repeat;
+#if HD_UNMASK_INTR
sti();
+#endif
+ outsw(HD1_DATA,CURRENT->buffer,wcnt);
+ cli();
+ SET_INTR(&write_intr);
+ outw(((short *)CURRENT->buffer)[wcnt],HD1_DATA);
return;
}
panic("unknown hd1-command");
--
mlord@bnr.ca Mark Lord BNR Ottawa,Canada 613-763-7482
------------------------------
** 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
******************************
Reference in New Issue View Git Blame Copy Permalink