| Summary: | [scsi] tape driver can't drive devs that can't do SCSI-2 MODEs | ||
|---|---|---|---|
| Product: | Base System | Reporter: | mjacob <mjacob> |
| Component: | kern | Assignee: | Matt Jacob <mjacob> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 4.0-CURRENT | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
mjacob
2000-02-28 22:40:01 UTC
Responsible Changed From-To: freebsd-bugs->mjacob@freebsd.org Responsible Changed From-To: mjacob@freebsd.org->mjacob No need to have '@freebsd.org' in the responsible field. Under FreeBSD 4.9 I have a system with the following: . . Waiting 15 seconds for SCSI devices to settle sa0 at trm0 bus 0 target 2 lun 0 sa0: <ARCHIVE VIPER 150 21247 -005> Removable Sequential Access SCSI-CCS device sa0: 536874.496MB/s transfers sa1 at trm0 bus 0 target 4 lun 0 sa1: <TANDBERG TDC 3800 =07:> Removable Sequential Access SCSI-2 device sa1: 3224108.528MB/s transfers The second Tandberg tapedrive works fine. The first Archive 150MB streamer does not. I can read it and copy files off of it just fine. However, when writing to the drive I get the following error: nat-rtr# tar c ker* tar: /dev/sa0: Wrote only 0 of 10240 bytes tar: Error is not recoverable: exiting now nat-rtr# I'm guessing this is the same problem? The same drive worked under FreeBSD 2.2.8 Ted Mittelstaedt State Changed From-To: open->feedback With bugmeister hat on, reassign from inactive committer. Responsible Changed From-To: mjacob->freebsd-bugs Is this still a problem with modern versions of FreeBSD? Responsible Changed From-To: freebsd-bugs->mjacob mjacob has reactived his commit bit. mea culpa for the bogus reassignment. I have the same problem with the Archive Viper 150 reported by Ted Mittelstaedt: Reading works, writing fails. Running RELENG_4_10_0_RELEASE from cvs. -- Martin Birgmeier Vienna Austria O.k. I am taking back my previous feedback... on RELENG_4_10_0_RELEASE, I can indeed write to an ARCHIVE VIPER 150 21531 -004. (I seems the reason I could not previously was because the write protect on the test cartridge was on ;-)). However, the drives (I have 2 of them) do not get into proper streaming while writing: On average, they will write about four consecutive 32k blocks with 'dd ... bs=32k' before re-seeking. They seem to be streaming better while reading. It looks like a timing issue. But even this poor streaming might be a non-issue due to old tapes and/or heads. Even the temperature of the drives seems to have some influence. -- Martin Birgmeier Vienna Austria Well, I'm glad you're able to write. I do have an Archive 150, but I haven't tried it in a while. I presume that you've made sure that the blocksize is set at 512? __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com State Changed From-To: feedback->closed In feedback long enough. |