Re: Really odd "BTX halted" problem booting FreeBSD on VALinux
Robert Nordier <[EMAIL PROTECTED]> writes:
>> > o Don't use dangerously dedicated mode.
>>
>> I'd love to but the tools for automated installs in non-dedicated mode
>> dont really exist in a supported way. One of the things that was pointed
>> out in the thread is that disklabel doesn't work inside an fdisk slice.
>
>Disklabel really needs to be rewritten.
Few truer statements have ever been made...
>> I could use expect to manipulate sysinstall? So, for now, I use
>> dangerously dedicated installs with a hacked fake partition table to work
>> around the broken bioses I use. I just might start using program posted
>> in this thread that lets you do labels right in lieu of anything else, or
>> perhaps I'll fix disklabel to work right as was suggeseted elsewhere.
>
>Don't sysinstall work in a script mode? I've never used it, but I
>thought it did.
It does work in a scripted mode, however the documentation on it is
close to non-existant; arguments are case-sensitive, etc. I was working to
migrate data to disks/partitions of different sizes, and had to read lots
of the sysinstall/disklabel source, and on top of that had to hack
sysinstall in order to get it to work at all for my purpose. Ugh.
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Portable way to compare struct stat's?
Robert Watson <[EMAIL PROTECTED]> writes:
>> On a single system, if st_dev and st_ino are equal, you must be referring
>> to the same object. If not, I'd like to hear about it.
>
>This assumption has always caused lots of pain and suffering for
>distributed file system people -- in a distributed file system, the
>requirement that you can generate a unique 32 bit number for each file or
>directory visible in the FS is a fairly arduous one. Either the number is
Quite true, and a real performance problem for some FS designs.
Read some SigOS papers for examples (or below).
Allowing the application to decide if something is the same or not
directly is not a Good Idea. Allowing the OS/FS to determine that for the
application is a Good Idea. Witness the SameLock(lock1,lock2) call in some
OS's (AmigaOS in particular - SameFileHandle(fh1,fh2) or
SameFile(filename1,filename2) are simple derivatives of SameLock()).
re: AFS, CODA
>each file/directory, only it's 96-bit, which in my book doesn't guarantee
>unique mapping onto the 16 bit dev number and 32 bit inode. This means a
>hash is required, and collisions are possibly. When a collision occurs on
>the hash under Linux, all hell breaks loose :-).
Hell breaking loose can be a real pain
>Rant rant rant.
And a darn good rant at that.
Too bad that the "that's the way it's always been done"/"inodes
were handed down by God" arguments are so hard to overcome. 1/2 :-)
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: writing to an mmap()'ed region requires read access?
Matthew Dillon <[EMAIL PROTECTED]> writes:
>:I was just playing with mmap() really for the first time, and I noticed
>:something a bit odd. When you mmap() a file for writing, it also appears
>:to require that you give it read permissions, else it dies on a signal 10.
>
>I've got a few hundred terrabytes of WOM to sell ya!
I'll sell you a few petabytes!
>This is just a byproduct of the MMU implementation. Most MMU's do
>not support write-only maps because most do not implement separate
>read and write bits. You get a valid and a write-enable bit instead,
>or you just get a valid bit and have to use the dirty bit to make the
>page writable (no write-enable bit at all).
Makes sense.
Shouldn't the mmap() return MAP_FAILED, probably with EACCES,
instead of causing a signal 10?
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Portable way to compare struct stat's?
Wes Peters <[EMAIL PROTECTED]> writes:
>Randell Jesup wrote:
>> >> On a single system, if st_dev and st_ino are equal, you must be referring
>> >> to the same object. If not, I'd like to hear about it.
>> >
>> >This assumption has always caused lots of pain and suffering for
>> >distributed file system people -- in a distributed file system, the
>> >requirement that you can generate a unique 32 bit number for each file or
>> >directory visible in the FS is a fairly arduous one. Either the number is
>>
>> Too bad that the "that's the way it's always been done"/"inodes
>> were handed down by God" arguments are so hard to overcome. 1/2 :-)
>
>Perhaps we simply need to expand the size of ino_t and carefully convert
>smaller types to it in the stat call?
It's the paradigm that's the problem here, not the implementation,
IMHO. While expanding ino_t might allow us to kludge around the problem,
the real issue is that not all filesystems have an easy way to associate
a (semi)permanent, unique number of any size with a specific file.
If it were long enough to store a path, that might solve some FS's
problems, except that directories in the path might get renamed.
Quite honestly, the application should not be determining whether
two files are the same directly. The OS/FS should do that. ino_t in
stat() should be deprecated and and alternative system call created.
Programs that reference the inode field should be modified to use the
new interface.
Of course, if I were to believe this would happen just because it's
the right design, I'd also believe in the tooth fairy. :-( There's lots
of ancient cruft in the design of *nix systems that's very hard to get
people to consider even touching, let alone deprecating or removing. Sigh.
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Portable way to compare struct stat's?
Assar Westerlund <[EMAIL PROTECTED]> writes:
>> we should start by creating an "fcompare()" routine, which you'd
>> pass two file descriptors to and it would say if they're the same
>> file. Initially that routine could just do two fstat()'s, and
>> compare st_dev and st_ino. We could then expand it to do better
>> comparisons for other file-systems.
>
>In solaris there's a vnode operation vop_cmp that does exactly that.
>But it's not exported to userland in any way.
Sounds like what we'd want to build it upon. If the FS doesn't
support it, use st_dev/st_ino. The real problem is getting people to
switch.
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Portable way to compare struct stat's?
Assar Westerlund <[EMAIL PROTECTED]> writes:
>Randell Jesup <[EMAIL PROTECTED]> writes:
>> Sounds like what we'd want to build it upon. If the FS doesn't
>> support it, use st_dev/st_ino.
>
>Actually, since it's in the kernel, the default implementation of the
>vnode operation might be:
>
>int
>vop_default_cmp (struct vnode *v1, struct vnode *v2)
>{
> return v1 == v2;
>}
Sure, depending on what's in a vnode (I haven't looked).
I was really thinking of the kernel; I don't know how much of the
interior filesystem structure is exposed to the kernel; I was assuming
that vnodes are something that's opaque (or mostly so) to the kernel,
and are interpreted by the filesystem that created them.
>Or did you mean a fallback in the library function for when the kernel
>doesn't provide the fdcmp (or whatever) system call? That could be
>something like:
That's what I was thinking of, partially. It makes binaries
more transportable, and source if we can get Linux/etc to add it to
their libraries.
>> The real problem is getting people to switch.
>
>You mean application programs? Sure, but the only thing we can do
>about that is implementing support for it, right?
Right; that's where to start.
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: cdrom speed adjustment ioctl
Egervary Gergely <[EMAIL PROTECTED]> writes:
>> I've just hacked a new ioctl into the ATAPI cdrom driver, which
>> lets the user to specify (pronounce: ``slow down'' :) the speed
>> of todays' extremely high speed drives.
>
>ok, so i see you like the idea - so the question is: should we implement a
>new ioctl for it, or - as like scsi - should we use a program like
>camcontrol for it?
One solution I used in the past (Amiga) was to implement the
ATA (and ATAPI) support by writing the equivalent of SCSI CAM SIM;
that is a SIM that actually controlled IDE hardware instead of SCSI
hardware. This is quite easy, in fact, especially since ATAPI is
basically SCSI-over-IDE with a few twists.
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
[EMAIL PROTECTED]
CDA II has been passed and signed, sigh. The lawsuit has been filed. Please
support the organizations fighting it - ACLU, EFF, CDT, etc.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: ELF & putting inode at the front of a file
Matthew Dillon <[EMAIL PROTECTED]> writes:
>:On Mon, 6 Dec 1999, Zhihui Zhang wrote:
>:> I have modified FFS filesystem code to put the disk inode at the beginning
>:> of a file, i.e, the logical block #0 of each file begins with 128 bytes of
>:> its disk inode and the rest of it are file data.
>:
>:first question I have is, why?
>
>Good god, is he joking? Offsetting the entire file by 128 bytes will
>break mmap() and make I/O extremely inefficient.
Very true; though providing locality of the metadata and the
beginning of the file has obvious benefits (and is used by many filesystems
and experiments). (See below.)
>Many filesystems over the years have mixed meta-data in the file data
>blocks on disk only to remove it later on when it was found to destroy
>performance. A good example of this is the Amiga's filesystem. The
>Amiga's old filesystem was emminently recoverable because each data
>block had a backpointer, but it was so inefficient due to all the copying
>required that the updated filesystem removed the metadata so disk blocks
>could be DMA'd directory into the buffer.
Each block in OFS had a backpointer and a checksum; it was designed
(apparently) for mass-storage systems that had no lower-level data
integrity mechanisms. Amiga FFS (no relation to Unix FFS) removed all the
data-block checksums and pointers, and as a result sequential file reads
were able to run at close to raw disk bandwidth. (Direct destination DMA
of reads/writes helps a lot here, and was used whenever possible -
sector-unaligned IO's would commonly have only the head and tail go through
the buffer cache; the middle portion would go direct to the user memory.)
The big benefits to locality of meta & file data are to allow
drive/driver caching to do sequential (or close to) reads in as large
blocks as possible. There was a recent SigOS paper on a modified Unix
filesystem that was designed to take advantage of modern disk systems,
reduced the number of inode indirection levels, and changed the allocation
patterns of data within cylinder groups. Looked nice.
Ah, the days of multi-threaded (with co-routines) filesystems
written in ultra-tight (for space) assembler, complete with co-routine-
semaphores, and a built-in automatic fsck-equivalent. Not to mention
file-locking and notification on file-modification (pretty cool, actually).
Shudder.
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: ELF & putting inode at the front of a file
Matthew Dillon <[EMAIL PROTECTED]> writes:
>:> distribute the inodes all over the cylinder group rather then concentrate
>:> all the inodes in one place.
>:
>:Yes. I have implemented most of the code. I noticed the "ls -al" is slow
>:but "ls" is OK.
>
>Yes, ls (without any options) is ok because the file type is now being
>stuffed in the directory entry, allowing ls (without any options) to
>avoid stat()ing the file.
Interesting - I made a similar mechanism in a hash-chain-based
filesystem to speed up directory listings; by storing all the commonly
accessed information about a file in the directory in a compressed format,
thus avoiding fetching the fileheader (inode) block for every file. The
speedup was impressive; I think I was getting 7-25 entries per 512-byte
sector; including just all ls -l information. The downside was increased
overhead on file-close-after-modify and create/delete, but not a lot. As a
side-benefit, recovery after a trashed FS is slightly easier since there's
more redundant information available (if the main directory sector/inode
gets whacked).
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Oh my god, Google has a USENET archive going back to 1981!
Nils Holland <[EMAIL PROTECTED]> writes: >A few years ago I tried hard to get a look at a real C65, you know, these >things that Commodore never really finsished, but which showed up in a few >units after Commodore went bankrupt. However, I have never been able to >pick up or only look at such a machine. Since only very few of them are >available (and they are all very buggy), they are traded at very *high* >prices between CBM fans... Really. I have a few of them in my basement. Along with various other beta and never-produced hardware, including a fabled AAA Amiga chip (Mary) (no board, though), and evil things like Plus-4's and C-16's. Lots of interesting stuff came out of the C64, including PlayNet, which was renamed Quantumlink and then ported to the PC as AmericaOnline. The frightening thing is that AOL still uses the old C64 windowed error-correction protocol I designed to correct bit errors in the modem traffic _when connecting to AOL over TCP/IP_. I was shocked. (article about this somewhere on slashdot recently). (my apologies for the off-topic-ness of this whole thread) -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team, ex-PlayNet [EMAIL PROTECTED] "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania, 1759. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD Floppy driver needs enhancement...
Terry Lambert <[EMAIL PROTECTED]> writes: >Julian Stacey wrote: >> Doubtless some will have bad sectors by now. Here's a rescue tool: >> http://bim.bsn.com/~jhs/src/bsd/jhs/bin/public/valid/valid.c & valid.1 >> >> `Valid' runs on FreeBSD, but only rescues when running on MSDOS ! >> (because read() on DOS3.2 returns the intact buffer even if the >> CRC fails, so I can then average each bit of each byte in each >> sector for all reads). `Valid' works at sector level, no knowledge >> of file systems, so it can rescue/ manipulate BSD FS sectors on >> floppy, tar images, DOS or Minix file systems etc. > >Sounds like the FreeBSD floppy driver needs to be modified to >return the full buffer, even if there is a CRC error. > >This implies a descriptor being passed, so that the CRC and >the data are seperate. > >You could probably just wadd an ioctl that expected the >descriptor to be at the front of a data buffer, so that >you passed the address of the descriptor + buffer, after >the ioctl(). > >This seems a useful feature... Yes (if anyone still cares about floppies). The old Amiga trackdisk (floppy driver) could do that, since all the decoding was in software (and via the graphics bitblitter(!)). Do the integrated disk controllers in PC's (still) allow direct raw bit access, or only after MFM decoding? Also, I seem to remember PC's can't recover from bad sector ID's. If I remember correctly, you can read uncorrected sectors off of ATA (maybe) and SCSI (I think), at least using CAM. Quite honestly, I can see some use for this in HD's; I don't see much use for it in floppies, except maybe for HD-less servers like gnat boxes. -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team [EMAIL PROTECTED] "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania, 1759. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD Floppy driver needs enhancement...
Oliver Fromme <[EMAIL PROTECTED]> writes: >Randell Jesup <[EMAIL PROTECTED]> wrote: > > Yes (if anyone still cares about floppies). The old Amiga > > trackdisk (floppy driver) could do that, since all the decoding was in > > software (and via the graphics bitblitter(!)). Do the integrated disk > > controllers in PC's (still) allow direct raw bit access, or only after MFM > > decoding? > >No, it can't. The FDC in a PC (a NEC µPD765 or a clone of >it, nowadays usually embeded within a multi-I/O-controller >or the mainboard chipset) is severely limited in what it >can do. Basically, it can only read MFM-encoded sectors of >several fixed sizes, with a fixed header. Sounds like what I remember; you tell it to find a sector (sectors?) with this header, and it returns it to you. No control over the inter-sector gap, mark, or header directly. It's amazing how codified the OLD PC hardware spec has become, including all the quirks and stupidities. >In contrast, the FDC of the Amiga was like heaven. You can >read the floppies at bitlevel with that beast. The actual >data encoding (MFM or GCR) was done by a coprozessor. >That's why you can read PC-formatted floppies with the >Amiga, but not vice versa. I think that the native Amiga >floppies use MFM2 encoding. Amiga native uses MFM, but because there are no inter-sector gaps (just marks), it packs more onto a track (880K/disk to 720K with normal PC formatting) - 11 sectors instead of 9. You could also use them for GCR or RLL but then decoding had to be entirely in software. MFM could be done by a few passes of the graphics bit-blitter. (I did a major rewrite of the Amiga trackdisk at Commodore to improve bad-sector recovery and speed.) If you could guarantee that drives were close to spec (not the 5%(?) tolerance we assumed), you could pack in 12 sectors I think. I forget, all my math was in comments in the include files (assembler). The next generation chipset from Amiga (AAA) had an improved disk controller on Mary that could handle 2.88MB (3.4MB in Amiga format) floppies, not that they ever took off, as well as do direct CDROM bitstream decode. Never got past a few sample boards in the lab, though. Back to the original question: do people care about floppies and bad-sector recovery anymore? Aren't floppies on the very verge of disappearing for good, replaced by CDRW's? -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team [EMAIL PROTECTED] "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania, 1759. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: HOW to debug memory corruption efficiently?
Darryl Okahata <[EMAIL PROTECTED]> writes: > Purify's nearest (commercial) competitor is ParaSoft's "Insure++". >Perhaps things have improved but, when we last evaluated it a year or >two back, it was a LOT slower than purify (unusably slow for our >applications). I seem to recall 5-10X slower than purify (maybe more). >It can detect a few problems that purify does not, however (e.g., bad >arguments to printf()). Insure++ needs access to source code for best >results. I believe a Linux version is available. > > There is no open-source equivalent to purify (and probably won't >be, due to patent issues). The closest thing is "GNU checker", but >that's a pale, feeble dust speck compared to purify (assuming that you >even manage to get checker working). I'd also give the latest version of dmalloc a try. It also works fairly well, and includes protecting freed memory blocks to catch free-memory reads (I think) and writes. C++ may need minor source mods to track source file/lines for new'd objects. Overall it works pretty well. See ports and also dmalloc.com. -- Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team [EMAIL PROTECTED] "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania, 1759. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Apple's planned appoach to permissions on movable filesystems
Kris Kennaway <[EMAIL PROTECTED]> writes:
>Make uids randomly assigned. This solves the problem of collision between
>uids on an introduced medium and the ones on the local system by making it
>statistical (if the uid space is large enough). In order to manage this
>among multiple machines, you'd probably need a synchronisation facility,
>both online (connect to some network database), and by an "export/import"
>facility which lets you dump a DB and import (parts of) it on another
>machine. Storing the large uid in the inode is probably not feasible w/o
>breaking compatability, but you could indirect it through a mapping table
>loaded from elsewhere on disk when the FS is mounted.
>
>The downside to this is not being able to assign the uids according to
>your own numbering scheme. Perhaps what could be done is to have a lookup
>table which maps between in-system uids and on-disk ones, such that the
>kernel presents the translated uid to the system, and remaps the unknown
>ones.
This is a form of the "how do I know who is?"
Other interesting ideas (some related to the above):
Store on the disk a (small) UID to user-name/identifier mapping. When
mounting a disk, use those mappings to provide the (super)user with
the option to map the UID's of users who match the users of files on
the disk. There are some issues with identifying whether "joe" is the
same "joe" on the other system, but when combined with information
that's currently in passwd, it shouldn't be hard. You can also provide
this info to the person mounting the disk in a nice form that they
can accept, modify, or reject (and mount as totally foreign). For the
case of shared user databases, this should always come up with a
1:1 complete mapping.
You could extend this to use some form of public-key signature to
distinguish between users with similar names, and/or query the original
machine for more info/permission if possible.
When you mount a disk with UID translation going on, you could also
change the UID of new/modified files to be that of the user on the
new system (and update the user database on the partition), so when the
disk was moved back the original owner could filter out modifications
if he so wishes, or 'vet' them. Note: this includes root; or root can
be handled specially.
Much of what's going on here is that the decisions need to be in user
space, and this allows the software to present the user with a likely
set of mappings that they can accept, modify or reject.
If a (non-priviledged) user wants to mount a disk, they should not
be given any other than "other" access to anything (if that(?)), unless
they can identify themselves as the same user as one of the users
on the mounted disk (see above) - depending on how draconian you want
to be, and what level of security you've configured the disk for.
(Note: that last may be an important aspect. When a disk is set up
in a physically somewhat insecure setup (disk outside box, firewire,
etc as is being contemplated) you should be able to decide if you want
the disk to be "movable" or not. (And change that decision later if
you want to move it.)
Please excuse the rambling; I was just throwing out some ideas to see
if any stick to the wall.
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: CAM-ification - documentation
This discussion should probably move to the freebsd-scsi list...
"Kenneth D. Merry" <[EMAIL PROTECTED]> writes:
>Nick Hibma wrote...
>> Especially some help on the topic of polling would be appreciated.
>> Otherwise I'll have to resort to figuring out how to do things in
>> interrupt context, and that is going to be dirty.
>If you're talking about polling for transaction completion in a device
>driver, my guess is that you're going to have to do things in an interrupt
>context. (Unless you use a kernel process to do it.)
>
>The thing to remember is that when you get CCBs down in a CAM device
>driver, it may well be in an interrupt context. You have to be able to
>deal with that. My guess is that it might be easiest to just use a timeout
>handler to poll the device for completion every so often. A kernel process
>may also be an option, depending on how nasty the device is.
Ick. Polling == bad. Interrupts == good. This isn't a single-
tasking OS ala Win9x. This goes double for SCSI drivers, which are
inherently async and overlapped.
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Single character errors in source files, stop kernel compile!
tom brown <[EMAIL PROTECTED]> writes:
>I'm running FreebSD 3.3 on a AMD-K6 box thats totally SCSI.
>This is where I start to get failures. The compiler will stop with code 1
>and will claim that the reason is a single character error in the source
>code. A typical example would be the word "struct" spelt "strwct".
>Any ideas? I'm tempted to think it's some kind of a problem with the
>drive, but I haven't had any real hard failures.
It sounds like a classic case of incorrect cabling or bad
cable/termination; or possibly bad memory, or overclocking/overheating.
Check your cable; make sure it's tight, make sure you're running _good_
terminators and not violating any specs (did you know the maximum stub
length is ~3 inches, and that there's a _minimum_ distance between
connectors? (I think it's ~12 inches.)) You are using a good terminator,
yes? Are any drives outside the box? Termination at both ends of the bus?
Another check may be to use camcontrol to lower the speed or
width the SCSI bus is using for transfers. (camcontrol negotiate). NOTE:
you can screw things up royally with camcontrol if you don't know what
you're doing.
Try something like:
camcontrol negotiate -v
to find out about the device negotiation parameters, and
camcontrol negotiate -R 5.0 -a
to set the max sync transfer rate to 5MHz (slow). You could add a "-W 8"
to limit it to 8-bit-wide transfers. You could even try lower rates.
WARNING: you can screw up your filesystems playing with camcontrol -
easily. Also, while I know SCSI and CAM, I don't have SCSI on my current
FreeBSD system and haven't actually used camcontrol. Read the manpage and
be cautious.
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team ('88-94)
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
