Date: Thu, 7 May 1998 22:34:27 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: kpielorz@caladan.tdx.co.uk (Karl Pielorz) Cc: tlambert@primenet.com, tom@sdf.com, beng@lcs.mit.edu, dec@phoenix.its.rpi.edu, freebsd-hackers@FreeBSD.ORG Subject: Re: dump/restore problem (was: Network problem with 2.2.6-RELEASE) Message-ID: <199805072234.PAA14231@usr01.primenet.com> In-Reply-To: <Pine.BSF.3.96.980507104329.9704D-100000@caladan.tdx.co.uk> from "Karl Pielorz" at May 7, 98 10:52:37 am
next in thread | previous in thread | raw e-mail | index | archive | help
> Hoping this helps rule out something... > > I have 11.5Gb's of EIDE 'storage' (2 x 4.5Gb EIDE's, and 1 x 2.5Gb EIDE) > all running off a 440FX chipset controller, and I can back them up and > restore them with no problems at all. I'm running the driver in DMA mode - > but I've also had it running in standard PIO mode as well (i.e. flags > 0x0). I have the same SCSI controller as Tom, i.e. a 2940UW. > > The only other thing I can think of is that DLT is a damned site faster > than DAT - my DAT drive manages about 600k/sec to/from tape, I beleive a > DLT is going to run at anything from 1-4Mb/sec, which is going to 'stress' > the SCSI / IDE side an awful lot more (and working under the principal one > of the best ways to break a system is to 'stress' it) maybe were seeing > something like that here? The DLT may do something strange, like write blank blocks in order to keep streaming. A lot of drives tend to do that. The fix, if this were the case, would be to download "team" or "ddd", either of which use multiple processes with interleaved I/O and token passing to make the data really fly off the machine. This tends to work well for sending large GIF's via CGI much faster than an HTTP server would normally stream them out, as well. ;-). However, his last posting had the problem occuring when he dumped to a disk file instead of the DLT. Since you aren't having problems, and he is, it's either the OS version (he is running 2.2.6, are you?), or the raw device driver, or he's running a CMD640B controller or an Intel controller, and has built his own kernel, and removed the: options "CMD640" That work around the known hardware bug in about 60% of all IDE controllers out there (by volume). >From LINT: # # Options for `wdc': # # CMD640 enables serializing access to primary and secondary channel # of the CMD640B IDE Chip. The serializing will only take place # if this option is set *and* the chip is probed by the pci-system. # He may also want to play with the flags on his controller; also from LINT: # # ST-506, ESDI, and IDE hard disks: `wdc' and `wd' # # NB: ``Enhanced IDE'' is NOT supported at this time. # # The flags fields are used to enable the multi-sector I/O and # the 32BIT I/O modes. The flags may be used in either the controller # definition or in the individual disk definitions. The controller # definition is supported for the boot configuration stuff. # # Each drive has a 16 bit flags value defined: # The low 8 bits are the maximum value for the multi-sector I/O, # where 0xff defaults to the maximum that the drive can handle. # The high bit of the 16 bit flags (0x8000) allows probing for # 32 bit transfers. # # The flags field for the drives can be specified in the controller # specification with the low 16 bits for drive 0, and the high 16 bits # for drive 1. # e.g.: #controller wdc0 at isa? port "IO_WD1" bio irq 14 flags 0x00ff8004 vector wdintr # # specifies that drive 0 will be allowed to probe for 32 bit transfers and # a maximum multi-sector transfer of 4 sectors, and drive 1 will not be # allowed to probe for 32 bit transfers, but will allow multi-sector # transfers up to the maximum that the drive supports. # If he has turned these on, he should try turning them *OFF*. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805072234.PAA14231>