From owner-freebsd-hardware Sun Dec 29 06:13:07 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id GAA00753 for hardware-outgoing; Sun, 29 Dec 1996 06:13:07 -0800 (PST) Received: from minas_tirith.aha.ru (tarkhil@p150.dialup.aha.ru [194.220.185.150]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id GAA00744 for ; Sun, 29 Dec 1996 06:13:00 -0800 (PST) Received: (from tarkhil@localhost) by minas_tirith.aha.ru (8.6.12/8.6.9) id RAA00217 for hardware@freebsd.org; Sun, 29 Dec 1996 17:12:00 +0300 From: Alex Povolotsky Message-Id: <199612291412.RAA00217@minas_tirith.aha.ru> Subject: Tseng VGA problem To: hardware@freebsd.org Date: Sun, 29 Dec 1996 17:12:00 +0300 (MSK) Reply-to: tarkhil@aha.ru X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello! I'm trying to put Tseng VLB SVGA to work in X-Windows, without any success. In DOS or Windows 3.1 in works fine in 800x600x32k colors (exactly what I need), but fails with X-Windows. It has the following inscriprions: MACHSPEED VGA GUI 2401 Model ET4W32VL-2.1 MACHSPEED 9343 It's main chip is covered by a heatsink, with a small window revealing "ET4000/W32l". It has Winbond W82C490 RAMDAC, and SuperProbe tells that chipset is Tseng ET4000/W32i Rev B. Did anyone work with this card? Alex. From owner-freebsd-hardware Sun Dec 29 09:30:10 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id JAA05837 for hardware-outgoing; Sun, 29 Dec 1996 09:30:10 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id JAA05830 for ; Sun, 29 Dec 1996 09:30:08 -0800 (PST) From: BRETT_GLASS@infoworld.com Received: from ccgate.infoworld.com (ccgate.infoworld.com [192.216.49.101]) by lserver.infoworld.com (8.8.4/8.8.4/GNAC-GW-2.1) with SMTP id JAA24582; Sun, 29 Dec 1996 09:29:55 -0800 (PST) Received: from ccMail by ccgate.infoworld.com (SMTPLINK V2.11) id AA851880339; Sun, 29 Dec 96 10:20:22 PST Date: Sun, 29 Dec 96 10:20:22 PST Message-Id: <9611298518.AA851880339@ccgate.infoworld.com> To: "Rodney W. Grimes" , brandon@glacier.cold.org Cc: freebsd-hardware@freebsd.org Subject: Re: AHA 2940UW? Linux works.. Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > You didn't saymuch else about the hardware, and ``it'll run Linux'' > doesn't tell me much, as Linux does not do a lot of the performance > enhancements in FreeBSD that requires _CORRECTLY_ designed boards. You're right, of course. However, it would be nice if FreeBSD were able to adapt to some common problems it doesn't handle yet -- such as the bug in some RZ1000 chips. (I've been lucky so far, in that most of the motherboards I've worked with have let me disable the part of the chip that poses the problem. But FreeBSD really should handle this one.) --Brett From owner-freebsd-hardware Sun Dec 29 11:15:41 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA08494 for hardware-outgoing; Sun, 29 Dec 1996 11:15:41 -0800 (PST) Received: from saturn.apana.org.au (root@saturn.apana.org.au [202.12.90.3]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id LAA08471; Sun, 29 Dec 1996 11:15:29 -0800 (PST) Received: by saturn.apana.org.au id m0veQhe-0000XjC (Debian /\oo/\ Smail3.1.29.1 #29.37); Mon, 30 Dec 96 06:15 EST Received: (from andymac@localhost) by bullseye.apana.org.au (8.6.12/8.6.12) id XAA00266; Sun, 29 Dec 1996 23:30:29 +1100 Date: Sun, 29 Dec 1996 23:30:28 +1100 (EST) From: Andrew MacIntyre To: dwhite@resnet.uoregon.edu cc: freebsd-questions@freebsd.org, freebsd-hardware@freebsd.org Subject: UPDATE: Re: Problems with HP T4000s tape drive In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have succeeded in getting this device to work (AFAICT), and now have a backup of the system. Don't yet know whether what I think went on to the tape is what will come off it though ... :-| Two parts to the solution:- a) patch st.c and scsi_tape.h to treat the reported density code (0x45) as a QIC_3095, and behave the same as a QIC_3080 (based on 2.1.5's st.c/scsi_tape.h). b) update the drive's FLASH ROM to firmware v1.06. Fortunately, HP has posted the updated firmware on their web/ftp site and provide a DOS utility to install it (requires ASPI drivers). Item a) on its own made little difference, however item b) really clicked things together! There are two wrinkles left to irritate me. The first is that the drive is being reported as being empty on bootup, when it does contain a tape. It seems to me that this might a timing issue, as the drive is fiddle-farting around while the probe is under way. I guess I should try extending the settling time from 15s to 30-45s and see if it has any effect. The other wrinkle is that the driver is reporting an unrecognised SCSI command. If someone recognises it as a "quirk" from the following transcript (SCSI_DEBUG enabled, date/time removed for brevity), could they please let me know so that I can deal with it (from memory, this was triggered by an "mt status"). TIA and all the best for the new year. ---8<---<8---8<--- bullseye /kernel: st0(ncr0:4:0): scsi_cmd bullseye /kernel: st0(ncr0:4:0): scsi_done bullseye /kernel: st0(ncr0:4:0): command: 0,0,0,0,0,0-[0 bytes] bullseye /kernel: code70 valid0 seg0 key6 ili0 eom0 fmark0 bullseye /kernel: info: 0 0 0 0 followed by 16 extra bytes bullseye /kernel: extra: 0 0 0 0 28 0 0 0 0 0 1 12 0 0 0 0 bullseye /kernel: st0(ncr0:4:0): calling private err_handler() bullseye /kernel: st0(ncr0:4:0): private err_handler() returned -1 bullseye /kernel: st0(ncr0:4:0): calling private start() bullseye /kernel: st0(ncr0:4:0): ststart st0(ncr0:4:0): scsi_cmd bullseye /kernel: st0(ncr0:4:0): scsi_done bullseye /kernel: st0(ncr0:4:0): command: 0,0,0,0,0,0-[0 bytes] bullseye /kernel: st0(ncr0:4:0): calling private start() bullseye /kernel: st0(ncr0:4:0): ststart st0(ncr0:4:0): mounting bullseye /kernel: st0(ncr0:4:0): scsi_cmd bullseye /kernel: st0(ncr0:4:0): scsi_done bullseye /kernel: st0(ncr0:4:0): command: 1b,0,0,0,1,0-[0 bytes] bullseye /kernel: st0(ncr0:4:0): calling private start() bullseye /kernel: st0(ncr0:4:0): ststart st0(ncr0:4:0): scsi_cmd bullseye /kernel: st0(ncr0:4:0): scsi_done bullseye /kernel: st0(ncr0:4:0): command: 0,0,0,0,0,0-[0 bytes] bullseye /kernel: st0(ncr0:4:0): calling private start() bullseye /kernel: st0(ncr0:4:0): ststart st0(ncr0:4:0): scsi_cmd bullseye /kernel: st0(ncr0:4:0): scsi_done bullseye /kernel: st0(ncr0:4:0): command: 5,0,0,0,0,0-[6 bytes] bullseye /kernel: ------------------------------ bullseye /kernel: 000: 00 00 02 00 02 00 bullseye /kernel: ------------------------------ bullseye /kernel: st0(ncr0:4:0): calling private start() bullseye /kernel: st0(ncr0:4:0): ststart st0(ncr0:4:0): scsi_cmd bullseye /kernel: st0(ncr0:4:0): scsi_done bullseye /kernel: st0(ncr0:4:0): command: 1a,0,0,0,c,0-[12 bytes] bullseye /kernel: ------------------------------ bullseye /kernel: 000: 0b b6 10 08 45 00 00 00 00 00 02 00 bullseye /kernel: ------------------------------ bullseye /kernel: st0(ncr0:4:0): calling private start() bullseye /kernel: st0(ncr0:4:0): ststart st0(ncr0:4:0): starting block mode decision bullseye /kernel: st0(ncr0:4:0): scsi_cmd bullseye /kernel: st0(ncr0:4:0): scsi_done bullseye /kernel: st0(ncr0:4:0): command: 15,0,0,0,c,0-[12 bytes] bullseye /kernel: ------------------------------ bullseye /kernel: 000: 00 00 10 08 45 00 00 00 00 00 02 00 bullseye /kernel: ------------------------------ bullseye /kernel: st0(ncr0:4:0): calling private start() bullseye /kernel: st0(ncr0:4:0): ststart st0(ncr0:4:0): scsi_cmd bullseye /kernel: st0(ncr0:4:0): scsi_done bullseye /kernel: st0(ncr0:4:0): command: 1e,0,0,0,1,0-[0 bytes] bullseye /kernel: code70 valid0 seg0 key5 ili0 eom0 fmark0 bullseye /kernel: info: 0 0 0 0 followed by 16 extra bytes bullseye /kernel: extra: 0 0 0 0 20 0 0 0 0 0 1 5 0 0 0 0 bullseye /kernel: st0(ncr0:4:0): calling private err_handler() bullseye /kernel: st0(ncr0:4:0): private err_handler() returned -1 bullseye /kernel: st0(ncr0:4:0): ILLEGAL REQUEST asc:20,0 Invalid command operation code bullseye /kernel: st0(ncr0:4:0): calling private start() bullseye /kernel: st0(ncr0:4:0): ststart st0(ncr0:4:0): Open complete bullseye /kernel: st0(ncr0:4:0): stopen: dev=0xe01 (unit 0) result 0 bullseye /kernel: st0(ncr0:4:0): [ioctl: get status] bullseye /kernel: st0(ncr0:4:0): stclose: Closing device ---8<---8<---8<--- -- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andrew.macintyre@aba.gov.au (work) | Snail: PO Box 370 andymac@bullseye.apana.org.au (play) | Belconnen ACT 2616 Fido: Andrew MacIntyre, 3:620/243.18 | Australia From owner-freebsd-hardware Sun Dec 29 13:11:17 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id NAA12457 for hardware-outgoing; Sun, 29 Dec 1996 13:11:17 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id NAA12451 for ; Sun, 29 Dec 1996 13:11:13 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id IAA03059; Mon, 30 Dec 1996 08:07:00 +1100 Date: Mon, 30 Dec 1996 08:07:00 +1100 From: Bruce Evans Message-Id: <199612292107.IAA03059@godzilla.zeta.org.au> To: brandon@glacier.cold.org, BRETT_GLASS@infoworld.com, rgrimes@GndRsh.aac.dev.com Subject: Re: AHA 2940UW? Linux works.. Cc: freebsd-hardware@freebsd.org Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >You're right, of course. However, it would be nice if FreeBSD were able to >adapt to some common problems it doesn't handle yet -- such as the bug in >some RZ1000 chips. (I've been lucky so far, in that most of the >motherboards I've worked with have let me disable the part of the chip that >poses the problem. But FreeBSD really should handle this one.) Hasn't FreeBSD always handled it without doing anything special? Bruce From owner-freebsd-hardware Sun Dec 29 18:30:15 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id SAA25756 for hardware-outgoing; Sun, 29 Dec 1996 18:30:15 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id SAA25736; Sun, 29 Dec 1996 18:30:06 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id MAA05081; Mon, 30 Dec 1996 12:59:53 +1030 (CST) From: Michael Smith Message-Id: <199612300229.MAA05081@genesis.atrad.adelaide.edu.au> Subject: Re: DAT reliability In-Reply-To: <3.0.32.19961224150632.00691884@pop.dial.pipex.com> from Simon Reading at "Dec 24, 96 03:08:04 pm" To: aat81@dial.pipex.com (Simon Reading) Date: Mon, 30 Dec 1996 12:59:51 +1030 (CST) Cc: grog@lemis.de, msmith@atrad.adelaide.edu.au, se@freebsd.org, freebsd-hardware@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Simon Reading stands accused of saying: > > >Are you sure you're conditioning your DATs correctly? You will find > >that a tape that's been in storage should retensioned (wind to end of > >media, rewind), and must be at room temperature for best results. > >Instructions on this sort of thing are included with most decent > >blank tapes. > The tapes I have used were at 21C, normal pressure and humidity. > I did not retension the tape (unless this was done as part of the Adaptec > Backup 'format' action), but I had used them successfully on the HP C1533, > no problems. I will retension new tapes in future. No instructions were > provided with HP or Sony DDS cartridges. The biggest issue with tape condition and the Sonys is that we will get really poor read performance (lots of soft errors and retrying) ending with a read error on a tape that has been sitting on the shelf for months or has been shipped (vibration causing settling?). A quick wind-to-end and back seems to help immensely. > I doubt whether my problems were to do with conditioning, I am sure that my > SDT-7000 was faulty. I'm not going to argue with this 8) > Do you have any experience of the SDT-7000? Not directly, no. > The SDT-7000 has a drum rotational speed twice that of the SDT-5200 > (as Greg noted, to enhance performance). Running a drive at a > higher speed can only make it more susceptible to mechanical > failure. That presumes that everything else is the same, which isn't even close to valid. The SDT-7000, as has been observed, has a completely different head assembly design. The transport, insofar as any helical-scan transport can be, is pretty good. You can whine all you like about consumer-grade product, but TBH your average consumer-grade transport is pretty bloody good. Sony are going to hurt a lot more with 5% returns on a consumer product than on a computer product. > I would guess that the 5200 has been > out for longer and that any bugs/problems would be more likely to be > observed/sorted out than any with the 7000. The small price difference > between the two models make me think that there has been little change in > the funamental mechanism design and that 8000rpm may be too fast to > transport the tape using the existing mechanism. The price of the unit has little or nothing to do with its cost, design or taste when deep-fried. I've observed over the last few years that as a general rule, most DAT units "just work". I've only met a few "persistent plaintifs" who seem never to be able to get a working unit. > Simon -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-hardware Mon Dec 30 02:51:35 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id CAA19675 for hardware-outgoing; Mon, 30 Dec 1996 02:51:35 -0800 (PST) Received: from maelstrom.dial.pipex.net (maelstrom.dial.pipex.net [158.43.128.52]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id CAA19661; Mon, 30 Dec 1996 02:50:08 -0800 (PST) Received: from solaat81.dial.pipex.com by maelstrom.dial.pipex.net (8.8.3/) id KAA20321; Mon, 30 Dec 1996 10:50:02 GMT Message-Id: <3.0.32.19961230104539.00695500@pop.dial.pipex.com> X-Sender: aat81@pop.dial.pipex.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 30 Dec 1996 10:48:48 +0000 To: grog@lemis.de, se@freebsd.org From: Simon Reading Subject: Are HP DAT drives more unreliable than others? Cc: freebsd-hardware@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, In the freebsd-hardware mailing list, there has been an ongoing thread wrt DDS reliability. I think we may gain some useful info from posting to comp.sys.hp.hardware. Questions which we are trying to answer include: - How reliable is DDS/DDS-2 (DAT) technology? - Is any one brand of DDS drive better or worse than another? (or 'Do the HP drives warrant their Freebsd warnings?') - Can anything be done to extend DDS drive life? - Is there a common failure mode for DDS? This was prompted by the following warning, reported in http://www.freebsd.com/handbook/handbook125.html#267: >Hewlett-Packard HP C1533A . . >Warning: Quality control on these drives varies greatly. One FreeBSD core-team member has returned 2 of these drives. Neither lasted more than 5 months. >From mail that I have received I believe that the DDS mechanism, or more precisely the head, wears out and break down. The questions we're particularly concerned with are 1. How does the head wear out? and 2. Are HP DDS2 drives any worse / better than other DDS2 drives (eg. Sony SDT 7000)? Greg wrote: >Stephen Esser wrote: >>> Greg wrote: >>> My DAT worked fine >>> initially and then gradually faded, getting more and more read/write >>> errors as time went on. >> >> But the head drum is generally not covered by warranty, since >> its useful life is typically in the 1000 to 2000 hours range. >> (Some 1000 8GB (compressed) backups at full speed, or 300 at >> 33% of the nominal streaming data rate !!!) > >This, again, is interesting information for a number of reasons: > >1. I haven't seen any information that the drum isn't covered. Maybe > I just forgot it. Unfortunately, I can't find any warranty > information. > >2. The time you quote is *horribly* short. How can this compare with > the documented MTBF. According to HP, the MTBF for the 35470A is > 50,000 power-on hours, and the MTBF for the C1533A is 200,000 > power-on hours. In each case, they're assuming a duty cycle of > 12% (which I exceed), so the real MTBFs would be 6,000 operating > hours for the 35470A or 24,000 operating hours for the C1533A. > > My backups typically write a whole tape and take about 8 hours per > day. Tonight's backup started at 9 pm and finished (after a > verification read) at 5:07. That's a 33% duty cycle, which would > have the 35470A die after about 2 years. > > If we took your figures, they should die after about 4 to 8 > months, which is pretty much my experience. The only thing is, > this is the first I have heard of the figures. There's nothing in > any documentation I've seen which suggests that the drum is a > high-wear component. Laser printer documentation does indicate > that the print drum requires frequent replacement, for example. Q. can anyone confirm the life of the head drum? (Please state the source of this info). Q. Typically, how expensive is it to replace an HP head drum? Q. How does the reliability of HP compare to other makes of drive? It would be useful if replies regarding drive experiences include: 1. Make, model 2. Date of purchase (or manufacture) 3. Reliability and duration of ownership. 4. How heavy usage the drive gets. Simon PS. We've elimated cables, termination, tape conditioning (operating temperature, retensioning, ..), tape type etc. as a source of our problems. From owner-freebsd-hardware Mon Dec 30 04:56:28 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id EAA24074 for hardware-outgoing; Mon, 30 Dec 1996 04:56:28 -0800 (PST) Received: from maelstrom.dial.pipex.net (maelstrom.dial.pipex.net [158.43.128.52]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id EAA24022; Mon, 30 Dec 1996 04:54:40 -0800 (PST) Received: from solaat81.dial.pipex.com by maelstrom.dial.pipex.net (8.8.3/) id MAA19903; Mon, 30 Dec 1996 12:54:21 GMT Message-Id: <3.0.32.19961230125151.0068a21c@pop.dial.pipex.com> X-Sender: aat81@pop.dial.pipex.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 30 Dec 1996 12:53:06 +0000 To: Michael Smith From: Simon Reading Subject: Re: DAT reliability Cc: freebsd-hardware@freebsd.org, grog@lemis.de, se@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk At 12:59 30/12/96 +1030, Michael Smith wrote: >Simon Reading stands accused of saying: >> >> Do you have any experience of the SDT-7000? > >Not directly, no. > >> The SDT-7000 has a drum rotational speed twice that of the SDT-5200 >> (as Greg noted, to enhance performance). Running a drive at a >> higher speed can only make it more susceptible to mechanical >> failure. > >That presumes that everything else is the same, which isn't even close >to valid. This is precisely why I asked the question 'Do you have any experience of the SDT-7000?'. > The SDT-7000, as has been observed, has a completely >different head assembly design. The transport, insofar as any >helical-scan transport can be, is pretty good. You can whine all you >like about consumer-grade product, but TBH your average consumer-grade >transport is pretty bloody good. Sony are going to hurt a lot more >with 5% returns on a consumer product than on a computer product. 1. As you say, the SDT-7000 is a new design. Like ANY new product, I would expect more teething troubles than one which has been out in the market for longer. (NB. I'm not saying this was the cause of my problems). 2. The comment about consumer grade product was Paul Rubin's, not mine. 3. How many people listen to their DAT player four hours _every day_? How long would it last if they did? >> I would guess that the 5200 has been >> out for longer and that any bugs/problems would be more likely to be >> observed/sorted out than any with the 7000. The small price difference >> between the two models make me think that there has been little change in >> the funamental mechanism design and that 8000rpm may be too fast to >> transport the tape using the existing mechanism. > >The price of the unit has little or nothing to do with its cost, >design or taste when deep-fried. I've observed over the last few >years that as a general rule, most DAT units "just work". I've only >met a few "persistent plaintifs" who seem never to be able to get a >working unit. There are two separate issues here. 1. Infant mortality. The reason why I returned my SDT-7000 was because it didn't work. The reason why I have not exchanged for another SDT-7000, is in case it is a problem with the batch. (I can't afford to waste time with another dud). Fait accompli. 2. Expected Lifetime. As stated before, I'm much more interested in how long I could expect a DDS-2 to last. From correspondence I've received I'd guess 18 months+ light usage, six months or so heavy usage (I'm happy to be corrected on this). Does one DDS-2 manufacturer produce more reliable drives than another? I don't think we're much closer to an answer on this question. Regards Simon From owner-freebsd-hardware Mon Dec 30 06:42:09 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id GAA28368 for hardware-outgoing; Mon, 30 Dec 1996 06:42:09 -0800 (PST) Received: from diablo.ppp.de (diablo.ppp.de [193.141.101.34]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id GAA28353 for ; Mon, 30 Dec 1996 06:42:04 -0800 (PST) Received: from freebie.lemis.de by diablo.ppp.de with smtp (Smail3.1.28.1 #1) id m0veiuU-000QXsC; Mon, 30 Dec 96 15:41 MET Received: (grog@localhost) by freebie.lemis.de (8.8.4/8.6.12) id OAA02928; Mon, 30 Dec 1996 14:48:48 +0100 (MET) From: grog@lemis.de Message-Id: <199612301348.OAA02928@freebie.lemis.de> Subject: Re: DAT reliability In-Reply-To: <3.0.32.19961230125151.0068a21c@pop.dial.pipex.com> from Simon Reading at "Dec 30, 96 12:53:06 pm" To: aat81@dial.pipex.com (Simon Reading) Date: Mon, 30 Dec 1996 14:48:48 +0100 (MET) Cc: freebsd-hardware@FreeBSD.org (FreeBSD hardware Users) Organisation: LEMIS, Schellnhausen 2, 36325 Feldatal, Germany Phone: +49-6637-919123 Fax: +49-6637-919122 Reply-to: grog@lemis.de (Greg Lehey) X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Simon Reading writes: > At 12:59 30/12/96 +1030, Michael Smith wrote: >> Simon Reading stands accused of saying: >> The SDT-7000, as has been observed, has a completely >> different head assembly design. The transport, insofar as any >> helical-scan transport can be, is pretty good. You can whine all you >> like about consumer-grade product, but TBH your average consumer-grade >> transport is pretty bloody good. Sony are going to hurt a lot more >> with 5% returns on a consumer product than on a computer product. > > 1. As you say, the SDT-7000 is a new design. Like ANY new product, I would > expect more teething troubles than one which has been out in the market for > longer. (NB. I'm not saying this was the cause of my problems). I don't think that *any* is valid. Many new products have teething troubles; many others don't. During this discussion I have come to the conclusion that the HP C1533A is a whole lot more reliable than the 35480A, for example. > 3. How many people listen to their DAT player four hours _every day_? How > long would it last if they did? I listen to my CD player for hours every day. It's about 7 years old now. I don't have a DAT player, but I would guess that the typical duty cycle for hi fi equipment could be higher than for tape backup devices. >> I would guess that the 5200 has been >> out for longer and that any bugs/problems would be more likely to be >> observed/sorted out than any with the 7000. The small price difference >> between the two models make me think that there has been little change in >> the funamental mechanism design and that 8000rpm may be too fast to >> transport the tape using the existing mechanism. >> >> The price of the unit has little or nothing to do with its cost, >> design or taste when deep-fried. I've observed over the last few >> years that as a general rule, most DAT units "just work". I've only >> met a few "persistent plaintifs" who seem never to be able to get a >> working unit. > > There are two separate issues here. > 1. Infant mortality. The reason why I returned my SDT-7000 was because it > didn't work. Agreed. But there was evidence in your case that the device had already been installed somewhere and returned for some reason. > The reason why I have not exchanged for another SDT-7000, is in case > it is a problem with the batch. (I can't afford to waste time with > another dud). Fait accompli. You're assuming that you would be better off with another brand. I don't think that these problems extend to whole batches. > 2. Expected Lifetime. As stated before, I'm much more interested in how > long I could expect a DDS-2 to last. From correspondence I've received I'd > guess 18 months+ light usage, six months or so heavy usage (I'm happy to be > corrected on this). I suspect you're (mis)quoting me here. I was talking about the 35480A when I mentioned 6 months. I'm pretty sure I've had the C1533 for well over a year, and it has had well beyond the expected 12% duty cycle in that time. > Does one DDS-2 manufacturer produce more reliable drives than > another? I don't think we're much closer to an answer on this > question. There are bound to be differences in reliability. It's just the question whether they are statistically relevant. My feeling is that the technology has matured considerably in the last 5 years, and that it will continue to mature. As a result, I would prefer a new model over an old model, even if other factors (capacity, speed) remain the same. Greg From owner-freebsd-hardware Mon Dec 30 08:52:40 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id IAA05332 for hardware-outgoing; Mon, 30 Dec 1996 08:52:40 -0800 (PST) Received: from gw.rinet.ru (gw.rinet.ru [194.87.171.65]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id IAA05323 for ; Mon, 30 Dec 1996 08:52:36 -0800 (PST) Received: by gw.rinet.ru id TAA12719; (8.6.11/vak/1.9) Mon, 30 Dec 1996 19:52:20 +0300 From: marck@gw.rinet.ru (Dmitry Morozovsky) Message-Id: <199612301652.TAA12719@gw.rinet.ru> Subject: 2.1.6-RELEASE & Fujitsu M2513A2 optical 640M To: freebsd-hardware@freebsd.org Date: Mon, 30 Dec 1996 19:52:19 +0300 (MSK) X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi there, Is 640M Fujitsu M2513A2 supported by FreeBSD? I've got debug message like "od0: can't deal with 2048 bytes sectors" Is there workaround applicable? Please CC your answers to my email 'cause I'm not subscribed to this mailing list. Thanx for cooperation and happy New Year! :) Sincerely, D.Marck ======================================================================== === D.Marck --- Dmitry Morozovsky --- marck@rinet.ru --- Wild Woozle === ======================================================================== From owner-freebsd-hardware Mon Dec 30 11:29:42 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA12809 for hardware-outgoing; Mon, 30 Dec 1996 11:29:42 -0800 (PST) Received: from maelstrom.dial.pipex.net (maelstrom.dial.pipex.net [158.43.128.52]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id LAA12803 for ; Mon, 30 Dec 1996 11:29:40 -0800 (PST) Received: from solaat81.dial.pipex.com by maelstrom.dial.pipex.net (8.8.3/) id TAA19020; Mon, 30 Dec 1996 19:29:23 GMT Message-Id: <3.0.32.19961230192648.0068db48@pop.dial.pipex.com> X-Sender: aat81@pop.dial.pipex.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 30 Dec 1996 19:28:09 +0000 To: grog@lemis.de (Greg Lehey) From: Simon Reading Subject: Re: DAT reliability Cc: freebsd-hardware@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Greg, Thanks for the mail. Apologies if this reply is a little long. At 14:48 30/12/96 +0100, Greg Lehey wrote: >Simon Reading writes: >> 1. As you say, the SDT-7000 is a new design. Like ANY new product, I would >> expect more teething troubles than one which has been out in the market for >> longer. (NB. I'm not saying this was the cause of my problems). > >I don't think that *any* is valid. Many new products have teething >troubles; many others don't. During this discussion I have come to >the conclusion that the HP C1533A is a whole lot more reliable than >the 35480A, for example. Maybe ANY was a rash generalization ;-) >> 3. How many people listen to their DAT player four hours _every day_? How >> long would it last if they did? > >I listen to my CD player for hours every day. It's about 7 years old >now. I don't have a DAT player, but I would guess that the typical >duty cycle for hi fi equipment could be higher than for tape backup >devices. I've used personal cassette players (cheap, expensive, different brands) for three hours a day, on average, they lasted about a year. I have a personal CD now, so this is no longer a problem. I don't know about the duty cycle of DAT or HIFI. >>> I would guess that the 5200 has been >>> out for longer and that any bugs/problems would be more likely to be >>> observed/sorted out than any with the 7000. The small price difference >>> between the two models make me think that there has been little change in >>> the funamental mechanism design and that 8000rpm may be too fast to >>> transport the tape using the existing mechanism. >>> >>> The price of the unit has little or nothing to do with its cost, >>> design or taste when deep-fried. I've observed over the last few >>> years that as a general rule, most DAT units "just work". I've only >>> met a few "persistent plaintifs" who seem never to be able to get a >>> working unit. >> >> There are two separate issues here. >> 1. Infant mortality. The reason why I returned my SDT-7000 was because it >> didn't work. > >Agreed. But there was evidence in your case that the device had >already been installed somewhere and returned for some reason. True. >> The reason why I have not exchanged for another SDT-7000, is in case >> it is a problem with the batch. (I can't afford to waste time with >> another dud). Fait accompli. > >You're assuming that you would be better off with another brand. I >don't think that these problems extend to whole batches. >> 2. Expected Lifetime. As stated before, I'm much more interested in how >> long I could expect a DDS-2 to last. From correspondence I've received I'd >> guess 18 months+ light usage, six months or so heavy usage (I'm happy to be >> corrected on this). > >I suspect you're (mis)quoting me here. I was talking about the 35480A >when I mentioned 6 months. I'm pretty sure I've had the C1533 for >well over a year, and it has had well beyond the expected 12% duty >cycle in that time. These were intended to be ball park figures rather than direct quotes. In the interests of accuracy, and for reference, I have quoted mails which have been sent to me, below. David Dawes writes: >I've had a 35470A for about 3.5 years now, and haven't had any >real problems. I've had a few I/O errors recently, but nothing that >a pass of a cleaning tape doesn't fix. phr@netcom.com (Paul Rubin) writes: >I have a C1533a now a little over 1 year old. I've had no problems >with it but my usage has been pretty light. Any DAT drive will >wear out after a year or so of heavy usage. Al Dykes writes: >I run a shop that has 7 tape drives, 4 are HP-DAT and three are >Exabyte 8mm. The exabyte systems backup about 4GB every night. The >DAT drives do about 3GB. I do 100% verifies on about half my backups. >That of course doubles the # of hours on the drive. All of these >systems are at least 2 years old. The oldest is just about 3 years >old. >Until this week all the DAT drives were HP35480A OEM units. In my >experience DAT drives work for about 2 years of heavy use and die >suddenly of something that is clearly mechanical, generally eating a >tape in the process. I can live with this. Greg Lehey writes: >>> Warning: Quality control on these drives varies greatly. . Neither lasted more than >>> 5 months. > >Well, this sounds very much like a report from me. But two things >don't fit: > . . >2. I was talking about 37480As. These are an older version of DDS-1 > drive. I do have a C1533A, and so far I've had no trouble with it > (more than 6 months, anyway :-) I think, in fact, I've had it > about 15 months, and I do a nightly backup which usually fills a > tape. Rainer Vonsaleski writes: >I bought an HP C1533A in November 1995, and I have been very happy >with it. Initially, there were some problems getting the termination >right (My Micropolis 1G drive *looked* to be terminating the bus, >but it wasn't). None of the problems were the fault of the C1533A. > >The C1533A has a most unusually complete set of error statistic logs >available. The performance with 90-meter tapes (hey, I'm cheap) >is fantastic. I trust this thing! This is from someone who wants >a medium to transfer hundreds of reels of 9-track tapes to for >archival purposes. > >I've spun about 50 full tapes in 13 months. The C1533A has behaved >flawlessly. If I had the choice to make over today, I would choose it >again, even though the Sony is 33% faster (on paper). Why? (1) Most of >my surprises with HP over the years have been pleasant surprises. >(2) Sony is playing catch-up, and their new drive is still much too >new. > >If the Sony is giving your grief, I'd return it for the C1533A. >In a second. There were also been a few comp.periphs.scsi postings (which I have filed. . on a server which has gone down :-( ) Greg writes: > Simon Reading writes: >> Does one DDS-2 manufacturer produce more reliable drives than >> another? I don't think we're much closer to an answer on this >> question. > >There are bound to be differences in reliability. It's just the >question whether they are statistically relevant. True. This is necessarily a problem of considering anecdotal evidence. > My feeling is that >the technology has matured considerably in the last 5 years, and that >it will continue to mature. As a result, I would prefer a new model >over an old model, even if other factors (capacity, speed) remain the >same. Is it not true that existing products continue to be tweaked as problems are observed by users? - For instance on my car, the car locks were replaced with a new design following problems experienced in the cold. - A certain make of car engine had a revised valve gear following (unpublicized) user problems. - TV designs for the same model are updated as better components become available etc. Regards Simon From owner-freebsd-hardware Mon Dec 30 12:21:24 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA16108 for hardware-outgoing; Mon, 30 Dec 1996 12:21:24 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id MAA16101 for ; Mon, 30 Dec 1996 12:21:17 -0800 (PST) From: BRETT_GLASS@infoworld.com Received: from ccgate.infoworld.com (ccgate.infoworld.com [192.216.49.101]) by lserver.infoworld.com (8.8.4/8.8.4/GNAC-GW-2.1) with SMTP id MAA00635; Mon, 30 Dec 1996 12:20:06 -0800 (PST) Received: from ccMail by ccgate.infoworld.com (SMTPLINK V2.11) id AA851976946; Mon, 30 Dec 96 13:12:38 PST Date: Mon, 30 Dec 96 13:12:38 PST Message-Id: <9611308519.AA851976946@ccgate.infoworld.com> To: Bruce Evans , brandon@glacier.cold.org, rgrimes@GndRsh.aac.dev.com Cc: freebsd-hardware@freebsd.org Subject: Re: AHA 2940UW? Linux works.. Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Hasn't FreeBSD always handled [buggy RZ100's] without doing anything > special? Not for me. I've had to shut off read-aheads via the BIOS on all the motherboards with this version of the chip. Red Hat Linux boots with a message warning you about the problem, and shuts off read-aheads itself. --Brett From owner-freebsd-hardware Mon Dec 30 12:46:42 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA17674 for hardware-outgoing; Mon, 30 Dec 1996 12:46:42 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id MAA17612 for ; Mon, 30 Dec 1996 12:46:21 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id HAA08475; Tue, 31 Dec 1996 07:42:11 +1100 Date: Tue, 31 Dec 1996 07:42:11 +1100 From: Bruce Evans Message-Id: <199612302042.HAA08475@godzilla.zeta.org.au> To: bde@zeta.org.au, brandon@glacier.cold.org, BRETT_GLASS@infoworld.com, rgrimes@GndRsh.aac.dev.com Subject: Re: AHA 2940UW? Linux works.. Cc: freebsd-hardware@freebsd.org Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> Hasn't FreeBSD always handled [buggy RZ100's] without doing anything >> special? > >Not for me. I've had to shut off read-aheads via the BIOS on all the >motherboards with this version of the chip. How did you test that this was necessary? >Red Hat Linux boots with a message warning you about the problem, and shuts >off read-aheads itself. FreeBSD never had the problem AFAIK. The Linux driver is more aggressive. Bruce From owner-freebsd-hardware Mon Dec 30 16:36:04 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id QAA02806 for hardware-outgoing; Mon, 30 Dec 1996 16:36:04 -0800 (PST) Received: from lserver.infoworld.com (lserver.infoworld.com [192.216.48.4]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id QAA02766 for ; Mon, 30 Dec 1996 16:36:01 -0800 (PST) From: BRETT_GLASS@infoworld.com Received: from ccgate.infoworld.com (ccgate.infoworld.com [192.216.49.101]) by lserver.infoworld.com (8.8.4/8.8.4/GNAC-GW-2.1) with SMTP id QAA02275; Mon, 30 Dec 1996 16:34:58 -0800 (PST) Received: from ccMail by ccgate.infoworld.com (SMTPLINK V2.11) id AA851992241; Mon, 30 Dec 96 17:26:16 PST Date: Mon, 30 Dec 96 17:26:16 PST Message-Id: <9611308519.AA851992241@ccgate.infoworld.com> To: Bruce Evans , bde@zeta.org.au, brandon@glacier.cold.org, rgrimes@GndRsh.aac.dev.com Cc: freebsd-hardware@freebsd.org Subject: Re: AHA 2940UW? Linux works.. Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > How did you test that this was necessary? I received repeated timeouts from the IDE disk driver until I did it. This happened on different motherboards; the common thread proved to be the older RZ1000. --Brett From owner-freebsd-hardware Mon Dec 30 22:23:20 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id WAA17555 for hardware-outgoing; Mon, 30 Dec 1996 22:23:20 -0800 (PST) Received: from bitflux.kwest.com.au (qmailr@elastic.kwest.com.au [203.58.18.1]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id WAA17549 for ; Mon, 30 Dec 1996 22:23:14 -0800 (PST) Received: (qmail 12492 invoked from smtpd); 31 Dec 1996 06:23:07 -0000 Received: from moog.kwest.com.au (cactoid@203.58.18.5) by bitflux.kwest.com.au with SMTP; 31 Dec 1996 06:23:07 -0000 Message-ID: X-Mailer: XFMail 0.4 [p0] on FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 In-Reply-To: <199612291412.RAA00217@minas_tirith.aha.ru> Date: Tue, 31 Dec 1996 17:18:12 +1100 (EST) Organization: Kwest Internetworks From: cactoid To: hardware@freebsd.org Subject: Intel EtherExpress Flash32 EISA nic. Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi all.. I have an old Acer server which has an EISA bus which I planned to install FreeBSD 2.1.5 onto, then make world to 2.1.6. I had some proprietry Acer EISA network card in there, which works with nothing, so I ditched it. I saw that Intel EtherExpress cards were supported with the ix driver, but I didn't realise at that stage that the eisa bus driver does all the work when it comes to EISA devices. basically what I need to know is whether anyone has got an EISA Flash32 nic to work with FreeBSD, or whether I should just go out and buy some ISA nic and ditch the Intel card as well. I'd like to use the Intel card if I can, but if I can't.. hey.. what can ya do. When I boot FreeBSD with the Intel card in there, it gives me the cards sig and says "Unknown device" or something similiar.. the same message the Acer card had. .is EISA a lost cause with FreeBSD? -- cactoid. /\/-> http://www.kwest.com.au /\/-> cactoid@kwest.com.au From owner-freebsd-hardware Tue Dec 31 06:05:28 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id GAA00231 for hardware-outgoing; Tue, 31 Dec 1996 06:05:28 -0800 (PST) Received: from news1.gtn.com (news1.gtn.com [192.109.159.3]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id GAA00205 for ; Tue, 31 Dec 1996 06:05:25 -0800 (PST) Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) with UUCP id PAA04115; Tue, 31 Dec 1996 15:02:29 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by klemm.gtn.com (8.8.4/8.8.2) with SMTP id OAA23528; Tue, 31 Dec 1996 14:28:31 +0100 (MET) Date: Tue, 31 Dec 1996 14:28:28 +0100 (MET) From: Andreas Klemm To: Simon Reading cc: freebsd-hardware@FreeBSD.org Subject: Re: Are HP DAT drives more unreliable than others? In-Reply-To: <3.0.32.19961230104539.00695500@pop.dial.pipex.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hardware@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 30 Dec 1996, Simon Reading wrote: > In the freebsd-hardware mailing list, there has been an ongoing thread wrt > DDS reliability. I think we may gain some useful info from posting to > comp.sys.hp.hardware. In de.comp.os.unix there is also a thread about unreliability of these drives. So what do you expect from posting into comp.sys.hp.hardware ? I never saw so many voices of unsatisfied users. The unreliability of DAT drives is the main reason in our company, to switch back to good old QIC technology. Now we sell our customers only Tandberg QIC Streamer, which are - fast (~33MB/min.) - reliable - not noisy (direct driven motor) - backward compatible (down to 60 MB read, 150 MB write) > Questions which we are trying to answer include: > - How reliable is DDS/DDS-2 (DAT) technology? As far as I read not much reliable. Another numbers: QIC tapes may be rewritten very often (about 100 times), whereas it's recommended to use DDS cartridges only about 20 times for backup. QIC tapes hold data about 10 years, DDS cartridges only about 2 years. > - Can anything be done to extend DDS drive life? Clean the heads on a regular basis and only with the suggested cleaning cartridges or kits. > Q. can anyone confirm the life of the head drum? (Please state the source > of this info). > > Q. Typically, how expensive is it to replace an HP head drum? > > Q. How does the reliability of HP compare to other makes of drive? > It would be useful if replies regarding drive experiences include: Sorry, can't give you more real numbers or facts. I'd switch to QIC technology if I were you. I think the drives are more robust. Tandberg QIC tapes are really fine. I have a 4222 and am very satisfied. Had no problem to read my old 150 MB cartridges, which were written with an Archive Vipwer 2525 (a 525MB streamer). And this drive is really very silent. An additional plus. Andreas /// -- andreas@klemm.gtn.com /\/\___ Wiechers & Partner Datentechnik GmbH Andreas Klemm ___/\/\/ Support Unix -- andreas.klemm@wup.de pgp p-key http://www-swiss.ai.mit.edu/~bal/pks-toplev.html >>> powered by <<< ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz >>> FreeBSD <<< From owner-freebsd-hardware Tue Dec 31 11:53:04 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id LAA17876 for hardware-outgoing; Tue, 31 Dec 1996 11:53:04 -0800 (PST) Received: from persprog.com (persprog.com [204.215.255.203]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id LAA17867 for ; Tue, 31 Dec 1996 11:52:57 -0800 (PST) Received: by persprog.com (8.7.5/4.10) id OAA30245; Tue, 31 Dec 1996 14:42:49 -0500 Received: from dasa(192.2.2.199) by cerberus.ppi.com via smap (V1.3) id sma030238; Tue Dec 31 14:42:32 1996 Received: from DASA/SpoolDir by dasa.ppi.com (Mercury 1.21); 31 Dec 96 14:42:33 +0500 Received: from SpoolDir by DASA (Mercury 1.30); 31 Dec 96 14:42:10 +0500 From: "David Alderman" Organization: Personalized Programming, Inc To: Andreas Klemm , freebsd-hardware@freebsd.org, aat81@dial.pipex.com Date: Tue, 31 Dec 1996 14:42:09 +0500 Subject: Re: Are HP DAT drives more unreliable than others? Priority: normal X-mailer: Pegasus Mail for Windows (v2.42a) Message-ID: <6C4F94E2D8B@dasa.ppi.com> Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > From: Andreas Klemm > > Sorry, can't give you more real numbers or facts. I'd switch to > QIC technology if I were you. I think the drives are more robust. > Tandberg QIC tapes are really fine. I have a 4222 and am very > satisfied. > > Had no problem to read my old 150 MB cartridges, which were written > with an Archive Vipwer 2525 (a 525MB streamer). > > And this drive is really very silent. An additional plus. > > I think the primary reason few people use the large QIC drives any nore is the relatively low capacity of the drives. 525 meg (or even 1 Gig) is not enough for todays multigigabyte servers. The cost of cartridges is also high relative to DDS or 8mm. I wonder if the new high capacity TR-4 based SCSI backups are any good? Aren't DLT's very reliable? For high capacity applications, I thought DLT's were considered best. ====================================== When philosophy conflicts with reality, choose reality. Dave Alderman -- dave@persprog.com ====================================== From owner-freebsd-hardware Tue Dec 31 14:11:20 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA24533 for hardware-outgoing; Tue, 31 Dec 1996 14:11:20 -0800 (PST) Received: (from jmb@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA24527; Tue, 31 Dec 1996 14:11:11 -0800 (PST) From: "Jonathan M. Bresler" Message-Id: <199612312211.OAA24527@freefall.freebsd.org> Subject: Re: Are HP DAT drives more unreliable than others? To: dave@persprog.com (David Alderman) Date: Tue, 31 Dec 1996 14:11:10 -0800 (PST) Cc: andreas@klemm.gtn.com, freebsd-hardware@freebsd.org, aat81@dial.pipex.com In-Reply-To: <6C4F94E2D8B@dasa.ppi.com> from "David Alderman" at Dec 31, 96 02:42:09 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk David Alderman wrote: > > > I think the primary reason few people use the large QIC drives any > nore is the relatively low capacity of the drives. 525 meg (or even > 1 Gig) is not enough for todays multigigabyte servers. The cost of > cartridges is also high relative to DDS or 8mm. > I wonder if the new high capacity TR-4 based SCSI backups are any > good? who makes high capacity QIC drives anymore? archive made several models. they were bought by conner and that seemed to end their production of high capacity QIC drives. > > Aren't DLT's very reliable? For high capacity applications, I > thought DLT's were considered best. sopposed to be very good. just be careful with the 'hook' that grabs the leader from the cartidge. jmb From owner-freebsd-hardware Tue Dec 31 14:56:26 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id OAA28638 for hardware-outgoing; Tue, 31 Dec 1996 14:56:26 -0800 (PST) Received: from penn.com (root@penn.com [205.146.6.6]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id OAA28633; Tue, 31 Dec 1996 14:56:20 -0800 (PST) Received: from none.Compuserve.com (oport22.penn.com [208.0.122.161]) by penn.com (8.7.3/8.6.12) with SMTP id RAA00661; Tue, 31 Dec 1996 17:55:45 -0500 (EST) Date: Tue, 31 Dec 1996 17:55:45 -0500 (EST) Message-Id: <199612312255.RAA00661@penn.com> X-Sender: jnuytten@pop.penn.com X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: freebsd-questions@freebsd.org, freebsd-hackers@freebsd.org, freebsd-hardware@@freebsd.org From: Jean-Paul Nuytten Subject: Installation Problems Sender: owner-hardware@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I just acquired FreeBSD from Walnut Creek CDROM along with the book "The Complete FreeBSD" by Greg Lehley. I have 2 EIDE hard drives; 1.2 GB (C:) which contains Windows 95 and 2.6 GB (FreeBSD partition, D:, E:). The FreeBSD partition is within the first 1024 cylinders, D: is a primary DOS partition which starts after the FreeBSD partition and E: is an extented DOS partition. To make matters worse, I have a Promise 2300 EIDE controller. I am trying to install using a DOS partition and have a directory on D: called FREEBSD with the distribution directories under it. After making a FreeBSD bootable diskette and booting the FreeBSD installation procedure (using the Novice installation option) I am have problems loading the distribution. I seem to be reading the distribution from the DOS partition OK, but I am getting write errors "Write failure transferring dists". Secondly, I have an IDE 8X CDROM (it came with the Creative Labs Sound Blaster 32PNP). The book says that I should make a boot floppy using the atapi.flp loader but I can't find that file on my distribution CDROM. Where can I get this file so that I can install from CDROM directly. Thanks in advance for your prompt attention to my questions. Regards, J-P Jean-Paul Nuytten Email: jnuytten@penn.com RD #3, Box 359A Tel: 814-641-0198 Huntingdon, PA USA 16652 FAX: 814-641-0199