Re: What is a good choice of sata-ii raid controller for freebsd?
On Mon, Feb 12, 2007 at 12:11:42PM +0300, Artem Kuchin wrote: > >On 2007-Feb-12 16:07:03 +1030, Daniel O'Connor <[EMAIL PROTECTED]> > >wrote: > >>I regularly ship systems overseas where the power fails frequently. The > >>inability to boot because one disk got hosed is Bad News (tm). > > >A decent UPS can help here. > > No, i can't. I have seen UPS (even APC) fail in some cases. Computers > got frozen. Also, i've seen many cases when power failes for more than 4 > hours > and nobody want to buy UPS which hold 4 hours of power for a dual xeon > with 5 hdds. > sysutils/nut is a good work-around for this. --Geoff ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: What is a good choice of sata-ii raid controller for freebsd?
On Thu, Feb 08, 2007 at 04:34:57PM -0500, Charles Sprickman wrote: > -They added a moving part (2-wire fan, no tach) to a "mission-critical" > part. That seems real stupid. After the bearings die in 2-3 years, what > happens to your card? Does it melt or just start acting weird? If the > engineers didn't consider that, what other failure modes did their limited > creativity miss? :) > The fan does have a tachometer which you can monitor from the card BIOS or using the cli binary. You can also disable the tachometer so you can swap the heatsink+fan for the larger heatsink (w/o fan) that comes in the box. You can find all of this out by *gasp* reading the manual. --Geoff ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kernel panic on 6.2-RC2 with GENERIC.
On Mon, Jan 08, 2007 at 08:03:50AM +1030, Ian West wrote: > On Sun, Jan 07, 2007 at 02:25:02PM -0500, Mike Tancsa wrote: > > At 11:43 AM 1/7/2007, Craig Rodrigues wrote: > > >On Fri, Jan 05, 2007 at 06:59:10PM +0200, Nikolay Pavlov wrote: > > > > > I have seen this identical fault with the new areca driver, my machine > is opteron hardware, but running a regular i386/SMP kernel/world. With > everything at 6.2RC2 (as of 29th of December) except the areca driver > the machine is rock solid, with the 29th of december version of the > areca driver the box will crash on extract of a large tar file, removal > of a large directory structure, or pretty much anything that does a lot > of disk io to different files/locations. There is no error log prior to > seeing the following messages.. > > Dec 29 14:26:44 aleph kernel: g_vfs_done():da0s1g[WRITE(offset=433078272, > length=8192)]error = 5 > Dec 29 14:26:44 aleph kernel: g_vfs_done():da0s1g[WRITE(offset=433111040, > length=16384)]error = 5 > Dec 29 14:26:44 aleph kernel: g_vfs_done():da0s1g[WRITE(offset=433209344, > length=16384)]error = 5 > Dec 29 14:26:44 aleph kernel: g_vfs_done():da0s1g[WRITE(offset=433242112, > length=32768)]error = 5 > Dec 29 14:26:44 aleph kernel: g_vfs_done():da0s1g[WRITE(offset=437612544, > length=4096)]error = 5 > Dec 29 14:26:44 aleph kernel: g_vfs_done():da0s1g[WRITE(offset=437616640, > length=12288)]error = 5 > Dec 29 14:26:44 aleph kernel: g_vfs_done():da0s1g[WRITE(offset=437633024, > length=6144)]error = 5 > Dec 29 14:26:44 aleph kernel: g_vfs_done():da0s1g[WRITE(offset=437639168, > length=2048)]error = 5 > Dec 29 14:26:44 aleph kernel: g_vfs_done():da0s1g[WRITE(offset=437641216, > length=6144)]error = 5 > > There are a string of these, followed by a crash and reboot. The file system > state can be left very dirty to the point where background fsck seems unable > to recover it. > > The areca card in question is running the latest firmware/boot and > has shown no problems either before, or since backing out the areca > driver. > > The volume is ran the tests on was a 250G on a raid6 raid set. > I've had exactly the same issue on my arcmsr in a i386/SMP box. The card is in a 64bit/66Mhz slot running the lastest firmware and the kernel is recent. I triggered it by creating a large number of files (~10^3 to 10^4) using Samba. This caused similar errors on two volumes on a ~800GB RAID5 array. Turning off soft-updates cured the crash, but not the write errors. --Geoff ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Background fsck causes kernel panic
Running a fairly recent RELENG_6 SMP kernel, I had a nasty experience
where filesystem corruption on a pair of RAID5 volumes on an arcmsr
would cause the machine to panic during the background fsck. This
resulted in a merry crash-reboot-crash cycle until I booted on to an
install CD, ran a foreground fsck and fixed the errors.
Given that this machine *is* a file server I'm rather eager to make sure
the problem doesn't happen again.
I'm not familiar with the code at all, but all three panics look like they're
happening in soft-update sections:
Unread portion of the kernel message buffer:
panic: softdep_setup_freeblocks: inode busy
cpuid = 0
Uptime: 4h58m59s
Dumping 1023 MB (2 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 1023MB (261872 pages) 1007 991 975 959 943 927 911 895 879 863 847
831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527
511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207
191 175 159 143 127 111 95 79 63 47 31 15
#0 doadump () at pcpu.h:165
165 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) where
#0 doadump () at pcpu.h:165
#1 0xc061e541 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
#2 0xc061e934 in panic (fmt=0xc0905fc5 "softdep_setup_freeblocks: inode busy")
at /usr/src/sys/kern/kern_shutdown.c:565
#3 0xc07bb7f9 in softdep_setup_freeblocks (ip=0xc6002c60, length=Unhandled
dwarf expression opcode 0x93
) at /usr/src/sys/ufs/ffs/ffs_softdep.c:2271
#4 0xc07ae85d in ffs_truncate (vp=0xc5fff000, length=0, flags=3072, cred=0x0,
td=0xc531b180) at /usr/src/sys/ufs/ffs/ffs_inode.c:278
#5 0xc07d0abe in ufs_inactive (ap=0x0) at /usr/src/sys/ufs/ufs/ufs_inode.c:126
#6 0xc08b364e in VOP_INACTIVE_APV (vop=0x0, a=0x0) at vnode_if.c:1535
#7 0xc068faf2 in vinactive (vp=0xc5fff000, td=0x0) at vnode_if.h:795
#8 0xc068f81c in vput (vp=0xc5fff000) at /usr/src/sys/kern/vfs_subr.c:2158
#9 0xc0697539 in kern_unlink (td=0xc531b180, path=0xbfbfe4b0 , pathseg=UIO_USERSPACE) at
/usr/src/sys/kern/vfs_syscalls.c:1722
#10 0xc0697322 in unlink (td=0x0, uap=0x0) at
/usr/src/sys/kern/vfs_syscalls.c:1658
#11 0xc089d6f0 in syscall (frame=
{tf_fs = -1078001605, tf_es = 135528507, tf_ds = -1078001605, tf_edi = 1,
tf_esi = 135534336, tf_ebp = -1077942072, tf_isp = -412762780, tf_ebx =
135461640, tf_edx = 0, tf_ecx = 5, tf_eax = 10, tf_trapno = 0, tf_err = 2,
tf_eip = 674363207, tf_cs = 51, tf_eflags = 642, tf_esp = -1077944196, tf_ss =
59}) at /usr/src/sys/i386/i386/trap.c:983
#12 0xc088501f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200
#13 0x0033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
I've filed a PR about it (which has two more backtraces):
http://www.freebsd.org/cgi/query-pr.cgi?pr=107206
Can anyone suggest further action?
--Geoff
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Resolver Issues (non valid hostname characters)
On Tue, 25 Mar 2003, Kevin Oberman wrote: > It should be noted that this limitation was in RFC952 which is not a DNS > specification. See RFC2181. I think our implementation is simply > broken. > >The DNS itself places only one restriction on the particular labels >that can be used to identify resource records. That one restriction >relates to the length of the label and the full name. >[...] >Those restrictions >aside, any binary string whatever can be used as the label of any >resource record. Similarly, any binary string can serve as the value >of any record that includes a domain name as some or all of its value >(SOA, NS, MX, PTR, CNAME, and any others that may be added). >Implementations of the DNS protocols must not place any restrictions >on the labels that can be used. In particular, DNS servers must not >refuse to serve a zone because it contains labels that might not be >acceptable to some DNS client programs. A DNS server may be >configurable to issue warnings when loading, or even to refuse to >load, a primary zone containing labels that might be considered >questionable, however this should not happen by default. > Before anyone considers removing restrictions, I hope consideration is given to the very real probability of vulnerabilities in bind which may have much more interesting implications as a result of the same. Test, test, fix, probe, fix and test some more before considering this please. At least then when the vulns happen (and they will), there will at least be a starting point to implement a fix. "You cannot deftly manipulate the control stick if you are suffering from diarrhoea"- [from a manual for Japanese Kamikaze pilots] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: FreeBSD: Server or Desktop OS?
On Sat, 16 Nov 2002, Marc G. Fournier wrote:
> Over the past couple of months, I've been starting to wonder if the
> Quality of FreeBSD's -STABLE branch has been deteriorating, to the point
> that trusting it for any sort of "loaded server" environment is coming
> into question ...
[snip]
> Am I expecting too much from FreeBSD-STABLE? Would I fair better if I
> moved down into RELENG_4_7 and avoided -STABLE altogether?
I think you're expecting too much from -stable. -stable is kind of a
misnomer; read the Handbook section 21.2.2.1 ("What Is FreeBSD-STABLE?")
for more. Your conclusion above is addressed there (spoiler: don't use
-stable in production unless your test environment convinces you that it
will work).
Geoff
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
Re: Kylix
On Wed, 20 Feb 2002, W. Wayne Liauh wrote: > Hi, I am toying around the idea of whether I should try fbsd. Among the > many questions, I am wondering whether you can run Borland's Kylix under > fbsd? Thanks. I downloaded the Kylix demo and ran the test script that determines whether the target system is up to snuff for Kylix requirements. Here's what it tells me: Borland Kylix System Compatibility Test Checking loaderFAILED Checking kernel >= 2.2OK Checking libc >= 2.1.2OK Stat: No such file or directory Checking libjpeg >= 6.2.0FAILED This system is not compatible with Borland Kylix. Please see the documents in this directory for information on how to upgrade your system. This is with linux_base-6.1, however. I'm upgrading to linux_base-7.1_1 as we speak, and will report back my findings. For the curious, the accompanying documents say the following with regard to the two failures above: -- A bug in some versions of the glibc loader can cause data corruption during the dynamic loading and unloading of shared objects. The result can be spontaneous segmentation faults in unrelated programs. Kylix is particularly sensitive to this bug, and will not install if the bug is present. The loader bug has been reported to glibc's maintainers, who have incorporated a fix in glibc 2.2. Systems which cannot upgrade to glibc 2.2 require a patched version of glibc 2.1.2 or later. -- Kylix requires libjpeg 6.2 or higher. (Some, but not all, Kylix applications also have this requirement.) An RPM package for this version is provided. I don't know what the stat error is from. Maybe I'll truss to check that out too. For the record, even if Kylix doesn't work, you should try out FreeBSD. Geoff To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: hard read error
On Thu, Dec 21, 2000 at 03:51:02PM -0600, Jim King wrote: > "Geoffrey Crompton (RMIT Guest)" <[EMAIL PROTECTED]> wrote: > > fwiw, I was getting similar errors under 4.2-stable on an old Conner 1 GB > drive. Going back to 4.1.1-RELEASE made the error messages disappear. > > Jim > Well, I was seeing the same errors back in 4.1.1. In fact, I think that may have caused a problem I had when trying to update to 4.2. After doing the build world, I couldn't compile the kernel, and the backup of the system got corrupted. In the end the machine was un-useable, and I had to install from scratch. Geoff Crompton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
SCSI Speed
I recently upgraded from 3.4 STABLE to 4.1.1. Not without a number of unsolved (yet) problems. One I think I need some help with is this SMP: AP CPU #1 Launched! sa0 at ahc0 bus 0 target 2 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 5.000MB/s transfers (5.000MHz, offset 15) Mounting root from ufs:/dev/da1s1a da0 at ahc0 bus 0 target 5 lun 0 da0: Removable Direct Access SCSI-2 device da0: 3.300MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present da3 at ahc1 bus 0 target 6 lun 0 da3: Fixed Direct Access SCSI-3 device da3: 20.000MB/s transfers (10.000MHz, offset 8, 16bit), Tagged Queueing Enabled da3: 8748MB (17916240 512 byte sectors: 64H 32S/T 8748C) da1 at ahc1 bus 0 target 0 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 20.000MB/s transfers (10.000MHz, offset 8, 16bit), Tagged Queueing Enabled da1: 4357MB (8925000 512 byte sectors: 64H 32S/T 4357C) da2 at ahc1 bus 0 target 1 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 20.000MB/s transfers (10.000MHz, offset 8, 16bit), Tagged Queueing Enabled da2: 4357MB (8925000 512 byte sectors: 64H 32S/T 4357C) cd1 at ahc0 bus 0 target 6 lun 0 cd1: Removable CD-ROM SCSI-2 device cd1: 20.000MB/s transfers (20.000MHz, offset 15) cd1: cd present [323214 x 2048 byte records] cd0 at ahc0 bus 0 target 3 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 8.333MB/s transfers (8.333MHz, offset 15) cd0: cd present [1331440 x 512 byte records] The SCSI disks are on Channel B of an Adaptec 2940UW (on board). The other devices (incliding zipdisk) are on Channel A. The disks used to show: da1: Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled Why has the bus speed dropped in the upgrade? What did I miss about changes for Adaptec Controllers? What information do I need to procure to diagnose this problem? Secondly, If the ARCHIVE Python is a SCSI-2 device, why is it operating at SCSI speeds? Geoff -- [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
