From: Digestifier 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 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 jkaidor@synoptics.com writes: >In article 94Mar25210418@first.cs.nyu.edu, fox@graphics.cs.nyu.edu (David Fox) writes: >>In article 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 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 wrote: > > >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: >»kevin@frobozz.sccsi.com (Kevin Brown) writes: >»>The "." and ".." restriction is a bit tougher to get around, however... >»Er, what? Linux isn't like DOS, and those aren't special reserved names. Those >»are links created when you make the directory: "." is a link to the directory >»containing it, and ".." is a link to the parent directory, unless you're in / >»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 skip@metronet.com (Christopher Key) writes: >In article , >Kevin Brown 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 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 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 #include @@ -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<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 ******************************