Excessive delays due to syncer kthread
I am trying to do some video capture and have been losing occasional fields. After adding some debugging code to the kernel, I've found that the problem is excessive latency between the hardware interrupt and the driver interrupt - the hardware can handle about 1.5msec of latency. Most of the time, the latency is less than 20µsec but but I'm seeing up to 8 msec occasionally. In virtually all cases where there is a problem, curproc at the time of the hardware interrupt is syncer. (I had one case where there was another process, but it had died by the time I went looking for it). The interrupt is marked INTR_TYPE_AV so it shouldn't be being delayed by other threads. (I can't easily make it INTR_FAST because it needs to call psignal(9)). The system is an Athlon XP-1800 with 512MB RAM and 2 ATA-100 disks running 5.3-RELEASE-p5. It has a couple of NFS exports but doesn't import anything. There's nothing much running apart from ffmpeg capturing the video and a process capturing my kernel debugging output. Apart from 4 files being sequentially written as part of my capture and cron regularly waking up to go back to sleep, there shouldn't be any filesystem activity. I tried copying a couple of large files and touching lots of files but that didn't cause any problems. Can anyone suggest why syncer would be occasionally running for up to 8 msec at a time? Overall, it's not clocking up a great deal of CPU time, it just seems to grab it in large chunks. Peter ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SATA RAID Support
> On Fri, Feb 25, 2005 at 12:18:51PM -0800, David G. Lawrence wrote: > > Answer > > Problem: > > WD EIDE drives are dropped from an IDE RAID array or system after several > > days or weeks of error-free operation. > > Of course I looked at 3ware, at WD and in google to find to find an > answer. I found both the articles you posted. > > One applies to PATA drives, which we don't have. It gives no hint about > software versions for SATA drives and I did not find a firmware upgrade > at WD either. All SATA drives prior to a few months ago are PATA with a serializer on the front end. It is likely that the firmware for the PATA Raptor is the same as the SATA Raptor, so any problem affecting one would likely affect the other. > The other one applies to SATA drives. When I found this, I checked with > smartctl in another machine (smartctl does not see single drives on the > 3ware) all the RAID drives. Acoustic management was disabled on all > disks. This does not really surprise me, though. 10 krpm disks are > probably meant for servers and to deliver high performance - switching > on acoustic management by default on these drives would not be very > smart. Perhaps, but I found these problem descriptions by doing a search on 3ware controllers with Raptor drives. In any case, my point is that the problem you described appears to be a problem with the drive, not the controller. The fact that you don't see the problem with the ICP Vortex controller is not proof that the 3ware controller is at fault. -DG David G. Lawrence President Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500 TeraSolutions, Inc. - http://www.terasolutions.com - (888) 346 7175 The FreeBSD Project - http://www.freebsd.org Pave the road of life with opportunities. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: netipx mega-MFC (1/2)
On Friday 25 February 2005 08:55 am, Robert Watson wrote: > I've just merged a fairly large set of changes to the netipx tree from > HEAD to RELENG_5. These primarily consist of structural changes required > for the locking of the netipx protocol, but excludes the locking changes > themselves. The theory is we'll let these changes settle for a few days, > then bring the locking changes in in time for 5.4-RELEASE. While these > changes have been tested in HEAD, and have been in the tree generally for > at least a month, netipx doesn't get a lot of exercise so there may be > problems. Please let me know if you experience any. I updated to 5.3-stable this afternoon. Attempting to boot ended in a panic (IIRC it was a signal 18). I could boot to single user mode so I removed all the Netware stuff from /boot/loader.conf and from /etc/rc.conf and tried again, I then had no problems. I didn't have time for further investigation, but it appears that something in the Netware support is extremely not right. I expect to have more time to investigate this on Monday, because after upgrading a Netware server, its NFS server is not playing nice with the BSD NFS client, and I've got to get something working to allow us to get our FreeBSD web server talking to the Netware file server again. I'm wasn't planning to be near that system again until Monday, although if you need details about my configuration I can dig them out remotely and send them to you. I'm not brave enough to risk another panic when I'm not physically there to reset the system, but if you are willing to work on it this weekend I'm willing to drive over there and test it. I would REALLY like to see the Netware stuff working in 5.4R. A few weeks ago I had the same panic when I tried to set up Netware support on 5.3-Release. It went away when I updated to -stable then (I believe it was around Jan 24), but the packets going out on the wire were not quite right, so I couldn't actually use it for networking. - Bob ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
sandisk cruzer mini quirks [failure] on RELENG_4
I have a 512mb version of the SanDisk Cruzer Mini keychain drive.
ProductId = 0x5150 (VendorID=0x0781). I am unable to correctly get it to
stop crashing the system when using cp(1) to copy large files to it.
I patched /usr/src/sys/dev/usb/umass.c as:
if (UGETW(dd->idVendor) == USB_VENDOR_SANDISK &&
(UGETW(dd->idProduct) == 0x5150) {
sc->proto = UMASS_PROTO_SCSI | UMASS_PROTO_BBB;
sc->quirks |= IGNORE_RESIDUE;
}
which is the same quirks patch that USB_PRODUCT_SANDISK_SDCZ2_256 (the
cruzer mini 256mb) uses. However, this fails to rectify the problem.
Notably dd(1) transfers files fine. This is on a RELENG_4 system, cvsup
yesterday. Any ideas?
thanks,
pete
--
Peter C. Lai
University of Connecticut
Dept. of Molecular and Cell Biology
Yale University School of Medicine
SenseLab | Research Assistant
http://cowbert.2y.net/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Scsi errors
On Thu, 24 Feb 2005, Valery Masiutsin wrote: > Hi! > > I am experiencing, problems with freebsd 4.8-STABLE, > and the ahc driver. The harddisk and adapter seems to be in > a working state, harddrive is a brand new Maxtor Fireball, and > adapter used to work on another machine, without any problems > for quite long time. > I'll appreciate any comments and suggestions. > Attaching the kernel config file and log with errors. Check cabling and termination, particularly if this is a new setup. Then check them again :-) -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SATA RAID Support
On Fri, 25 Feb 2005, Oliver Brandmueller wrote: > Under heavy load (I/O load on the disks constantly over 200 tps, average > at about 250 tps, peaks over 600 tps) a random drive disconnects from > the RAID 10. After removing the drive from the config and rescanning the > bus, the drive does not show up anymore. The only way to get the drive > back is to unplug the drive (or switch the computer off, so that power > is removed). After that there is no problem to rebuild the RAID with > the drive. We were having problems with this even under light load, with Western Digital SATA disks (not Raptors I don't think). In some cases all of the disks would drop off the array. It was determined to be an incompatibility between the controller (8506, I believe) and the motherboard (Tyan S2721). We have many other systems with 3ware cards, but not that motherboard, that function normally and the vendor was unable to resolve the issue after repeated system/controller/disk/cable replacements. We eventually returned the affected systems to the manufacturer. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5.3-R-p5: frequent kernel panics
On Wed, 23 Feb 2005, Piotr Gnyp wrote: > Hi. > > First - some details: > > uname -pr > 5.3-RELEASE-p5 i386 > > kernel: > http://discordia.pl/~toread/OBLIVION > > dmesg: > http://discordia.pl/~toread/dmesg.txt > > mptable: > http://discordia.pl/~toread/mptable.txt > > System frequently crashes with kernel panic - some examples: > http://discordia.pl/~toread/crash4.txt > http://discordia.pl/~toread/crash5.txt Please capture the panic messages and relevant kernel output along with your traces. It helps to know what the system was doing when it tanked, and the trap info decodes the frame in an easy-to-digest format for humans. :) Your traces are quite bizarre... somehow ttwakeup() jumps off into space. Line 2370 of ttwakeup() is ttecho() which implies your system is suffering from severe memory corruption, or your kernel binary is damaged. I'd suggest doing a fresh buildworld+kernel and running memtest86. Also the mpt driver in 5.3 is known to react badly to SCSI errors but I don't think it runs off and randomly corrupts memory. Also check the system event log for any errors logged from hardware, such as ECC corrections, power problems, or temperature alarms. The ProLiants (this is a DL380 or something of that nature?) have sophisticated internal monitoring and can log events even if the OS is damaged. What were your kernel compile flags? -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Panics with 5-stable - vinum? raid5?
On Tue, 22 Feb 2005 [EMAIL PROTECTED] wrote: > Hi there, > > I have random, non-reproducable panics every so often (roughly averaging > once a week) with my Intel server running FreeBSD- 5-stable and I am > running out of options trying to track down the issue. > > Error details: > Definitely not consistent, generally something like: > "panic: vm_fault fault on naofault entry, addr:d6f68000" > > Turned to debugging kernel, unattended reboot and crash dumping via swap, > however this doesn't work at all. Kernel options added to GENERIC: > "makeoptions DEBUG=-g" > "options KDB, GDB, DDB, KDB_UNATTENDED" This is not the correct syntax. The options need to be on their own lines. > dumpdev specified correctly in rc.conf (swap parition > mem) and rights > set correctly and existing /var/crash. Recently cvsed /usr/src, no > optimizations in /etc/make.conf and world/kernel made in accordance with > the handbook. [...] > kldstat: > Id Refs AddressSize Name > 13 0xc040 3b05c8 kernel > 21 0xc189c000 dd000vinum.ko > 31 0xc1a0a000 7000 nullfs.ko I'd strongly, strongly suggest migrating to gvinum if you can. My experience has found it vastly more stable on 5.X and seems free of the odd config problems that have plagued vinum in the 4.X days. > vinum dumpconfig: > Drive vinumdrive0: Device /dev/ad0s1e > Drive vinumdrive1: Device /dev/ad2s1e > Drive vinumdrive2: Device /dev/ad4s1e > Drive vinumdrive3: Device /dev/ad6s1e This is ok, but: disklabel /dev/ad0s1: # /dev/ad0s1: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 7707551904.2BSD 2048 16384 28552 b: 1048576 77075519 swap c: 3982834170unused0 0 e: 320159322 78124095 vinum Unfortnately since you've elected to share vinumdrive0 with your root partition you can't do the gvinum migration. I'd strongly suggest finding a separate root disk, migrate to it, then convert the remaining 4 disks to gvinum. If you switched to gvinum now your root partition (ad0s1a) would be masked (and quite possibly destroyed) by the gvinum conversion. gvinum generally expects to have the whole disk (or slice?) to itself. le may be able to expound on the exact reasons for this and if your setup is actually supported. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD 5-STABLE, APIC and SCB timeouts (was Re: FreeBSD 5-STABLE, MSI KT880 , fxp and SCB timeouts)
On Thu, Feb 24, 2005 at 09:52:52AM -0600, Jon Noack wrote: > Mario Sergio Fujikawa Ferreira wrote: > >On Wed, Feb 23, 2005 at 09:33:41PM -0600, Jon Noack wrote: > >>On 02/23/05 21:30, Dan Nelson wrote: > >>>In the last episode (Feb 23), Jon Noack said: > On 02/23/05 20:06, Mario Sergio Fujikawa Ferreira wrote: > >My last motherboard burned down to ashes so I got myself a brand > >(after 2 weeks) new MSI KT880. I am getting some weird results. > > > >1) fxp intel etherxpress 10/100 network cards report SCB timeout > >as well as achieving ridiculously low transfer rates of 600 > >Bytes/second. Well, I got 10 KBytes/sec once but that does not count > >since a side box gets more than 50KB/s ;-) on the same hub. Oh, I've > >already switched hub ports, rj45 cables and fxp cards. > After some research, it seems John Baldwin has found the reason for the SCB timeouts. It is related to APIC being enabled on the motherboard. It is optional for single processor systems but required for multiprocessor systems. The message regarding the patch is contained in the following URL http://lists.freebsd.org/pipermail/freebsd-smp/2005-January/000751.html I have been using the aforementioned patch for the past 24 hours. It is not perfect but I am getting some real speed (over 10KB/s though I should be getting close to 50KB/s). However, I am losing lots of packets when performing ping tests. Does anyone know anything further about it? I am willing to test trial patches as long as I do not lose my HDD data ;-D Regards, -- Mario S F Ferreira - DF - Brazil - "I guess this is a signature." feature, n: a documented bug | bug, n: an undocumented feature ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SATA RAID Support
Hi. On Fri, Feb 25, 2005 at 12:18:51PM -0800, David G. Lawrence wrote: > Answer > Problem: > WD EIDE drives are dropped from an IDE RAID array or system after several > days or weeks of error-free operation. Of course I looked at 3ware, at WD and in google to find to find an answer. I found both the articles you posted. One applies to PATA drives, which we don't have. It gives no hint about software versions for SATA drives and I did not find a firmware upgrade at WD either. The other one applies to SATA drives. When I found this, I checked with smartctl in another machine (smartctl does not see single drives on the 3ware) all the RAID drives. Acoustic management was disabled on all disks. This does not really surprise me, though. 10 krpm disks are probably meant for servers and to deliver high performance - switching on acoustic management by default on these drives would not be very smart. Thanx anyway, Oliver -- | Oliver Brandmueller | Offenbacher Str. 1 | Germany D-14197 Berlin | | Fon +49-172-3130856 | Fax +49-172-3145027 | WWW: http://the.addict.de/ | | Ich bin das Internet. Sowahr ich Gott helfe. | | Eine gewerbliche Nutzung aller enthaltenen Adressen ist nicht gestattet! | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[releng_5 tinderbox] failure on sparc64/sparc64
TB --- 2005-02-25 21:30:03 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-02-25 21:30:03 - starting RELENG_5 tinderbox run for sparc64/sparc64 TB --- 2005-02-25 21:30:03 - checking out the source tree TB --- 2005-02-25 21:30:03 - cd /home/tinderbox/RELENG_5/sparc64/sparc64 TB --- 2005-02-25 21:30:03 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -rRELENG_5 src TB --- 2005-02-25 21:38:27 - building world (CFLAGS=-O -pipe) TB --- 2005-02-25 21:38:27 - cd /home/tinderbox/RELENG_5/sparc64/sparc64/src TB --- 2005-02-25 21:38:27 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2005-02-25 22:28:43 - building generic kernel (COPTFLAGS=-O -pipe) TB --- 2005-02-25 22:28:43 - cd /home/tinderbox/RELENG_5/sparc64/sparc64/src TB --- 2005-02-25 22:28:43 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Feb 25 22:28:43 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/RELENG_5/sparc64/sparc64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcmodel=medlow -msoft-float -ffreestanding -Werror /tinderbox/RELENG_5/sparc64/sparc64/src/sys/sparc64/sparc64/bus_machdep.c /tinderbox/RELENG_5/sparc64/sparc64/src/sys/sparc64/sparc64/bus_machdep.c:687: warning: initialization from incompatible pointer type /tinderbox/RELENG_5/sparc64/sparc64/src/sys/sparc64/sparc64/bus_machdep.c:688: warning: initialization from incompatible pointer type /tinderbox/RELENG_5/sparc64/sparc64/src/sys/sparc64/sparc64/bus_machdep.c:689: warning: initialization from incompatible pointer type /tinderbox/RELENG_5/sparc64/sparc64/src/sys/sparc64/sparc64/bus_machdep.c:690: warning: initialization from incompatible pointer type /tinderbox/RELENG_5/sparc64/sparc64/src/sys/sparc64/sparc64/bus_machdep.c:691: warning: initialization from incompatible pointer type /tinderbox/RELENG_5/sparc64/sparc64/src/sys/sparc64/sparc64/bus_machdep.c:692: warning: excess elements in struct initializer /tinderbox/RELENG_5/sparc64/sparc64/src/sys/sparc64/sparc64/bus_machdep.c:692: warning: (near initialization for `nexus_dma_methods') *** Error code 1 Stop in /tinderbox/RELENG_5/sparc64/sparc64/obj/sparc64/tinderbox/RELENG_5/sparc64/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/RELENG_5/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/RELENG_5/sparc64/sparc64/src. TB --- 2005-02-25 22:32:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-02-25 22:32:59 - ERROR: failed to build generic kernel TB --- 2005-02-25 22:32:59 - tinderbox aborted ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: discarded oversize frames
On Fri, Feb 25, 2005 at 10:00:34AM -0500, Jonathan Pater wrote: > fxp0: discard oversize frame (ether type 800 flags 3 len 1515 > max > 1514) > > Is this something I should be > worried about, or is it indicative of something else faulty in the local > network setup? This message is produced if the ethernet card receives a packet that is bigger than permitted by the MTU + the size of the ethernet header. For normal ethernet this means that packets should be <= 1514 bytes. So, there are three ways to eliminate the the message: 1) Find the machine sending oversize packets and stop it. 2) Change the MTU on your interface using ifconfig, this will only work if the other machines on the network expect larget frames. 3) You could edit /usr/src/sys/net/if_ethersubr.c and remove the code that prints this error and then recompile your kernel. David. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SATA RAID Support
> > > Under heavy load (I/O load on the disks constantly over 200 tps, average > > > at about 250 tps, peaks over 600 tps) a random drive disconnects from > > > the RAID 10. After removing the drive from the config and rescanning the > > > bus, the drive does not show up anymore. The only way to get the drive > > > back is to unplug the drive (or switch the computer off, so that power > > > is removed). After that there is no problem to rebuild the RAID with > > > the drive. > > > > Interesting. AFAIR the same sort of errors occured with some older WD > > drives and 3Ware 750x controllers. > > The solution was to flash the drives firmware. > > > > A quick googling found some reference to the problem on this document: > > http://japan.3ware.com/products/pdf/Drive_compatibility_list.pdf ...and here is even more information about the problem: Question Why do EIDE drives disappear from the IDE RAID array or system after a short period of error-free operation? Affected drives: WD EIDE drives with capacities between 40GB & 120GB WD EIDE drives with greater than 120GB capacity with a date earlier than 3/25/03. Answer Problem: WD EIDE drives are dropped from an IDE RAID array or system after several days or weeks of error-free operation. Solution: The problem is a result of a feature that reduces idle acoustic noise in desktop drives. This feature may cause a timeout likely (though not exclusively) in an IDE RAID environment. To disable the feature, you can run a simple Western Digital utility to turn off a single bit in the drives run-time configuration. Disabling of this feature will NOT impact normal system operations. No firmware or hardware changes are required. IDE Upgrade Utility (Non-3Ware controller cards) For all configurations other than 3Ware controller cards, download the IDE Upgrade Utility for the Desktop PC. 3Ware controller cards If you are using one or more 3Ware controller cards in an IDE RAID configuration, download the IDE RAID Compatibility Upgrade Utility for 3Ware 7500-X controllers cards. -DG David G. Lawrence President Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500 TeraSolutions, Inc. - http://www.terasolutions.com - (888) 346 7175 The FreeBSD Project - http://www.freebsd.org Pave the road of life with opportunities. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SATA RAID Support
> > Under heavy load (I/O load on the disks constantly over 200 tps, average > > at about 250 tps, peaks over 600 tps) a random drive disconnects from > > the RAID 10. After removing the drive from the config and rescanning the > > bus, the drive does not show up anymore. The only way to get the drive > > back is to unplug the drive (or switch the computer off, so that power > > is removed). After that there is no problem to rebuild the RAID with > > the drive. > > Interesting. AFAIR the same sort of errors occured with some older WD > drives and 3Ware 750x controllers. > The solution was to flash the drives firmware. > > A quick googling found some reference to the problem on this document: > http://japan.3ware.com/products/pdf/Drive_compatibility_list.pdf Here is what I dug up from Western Digital: IDE RAID Compatibility Upgrade - 3Ware Cards Version Version 1.07 Publish DateApr, 2003 Description This utility runs within DOS and is used to update WD drives that are connected to one or more 3Ware 7500-X IDE (Parallel ATA) RAID controllers. Affected drives: WD drives with capacities between 40GB and 120GB. WD drives with greater than 120GB capacity with Mfg. date codes earlier than 3/25/03. Download Wdc_upd.zip(140 KB) Operating System Windows 2000 Windows XP Windows ME Windows 98SE Windows 98 Instructions Download the wdc_upd.zip file. Extract the file onto bootable medium (floppy, CD-RW, network drive, etc.). Boot the system to be updated to the medium where the update files were unzipped to. Run wdcfgupd.bat The utility will proceed to update all the drives on that controller. This process takes approximately 1 min. per drive. Once the update completes, re-boot the system. The update is complete. Related Resources Technical information, FAQ, and related answers from the knowledge base Upload Date 04/01/2004 -DG David G. Lawrence President Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500 TeraSolutions, Inc. - http://www.terasolutions.com - (888) 346 7175 The FreeBSD Project - http://www.freebsd.org Pave the road of life with opportunities. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: discarded oversize frames
I hope your issue is solved I get the same on a rl0 and have had no response. On Fri, 25 Feb 2005 10:00:34 -0500, Jonathan Pater <[EMAIL PROTECTED]> wrote: > I installed 5.3-STABLE a couple weeks back onto what is to become an > office mail server, and after cvsupping to RELENG_5, I began to notice > the following in dmesg: > > vr0: discard oversize frame (ether type 800 flags 3 len 1515 > max 1514) > > It happens several times after booting, and then about once a minute > after that. At first I suspected the network card itself, so I added an > eepro100 that's always worked fine for me, and then got: > > fxp0: discard oversize frame (ether type 800 flags 3 len 1515 > max > 1514) > > after I had rebooted. Yesterday I cvsupped again (to 5.4-PRERELEASE) and > the warnings still persisted. It doesn't noticeably impact stability or > performance, but it does fill up dmesg rather quickly, and makes the > nightly status emails rather large. Is this something I should be > worried about, or is it indicative of something else faulty in the local > network setup? > > I've attached output from dmesg and pciconf, the kernel config is > GENERIC. Please forgive the "eth0" device name, as I have to migrate > several Linux users and it's easier for me to change the interface name > than peruse everyone's homedirs and update their scripts. :) > > best, > > -- > Jonathan "CowboyNeal" Pater | [EMAIL PROTECTED] > http://cowboyneal.org/ | http://slashdot.org/ >"Don't worry about the world coming to an end today. It's already >tomorrow in Australia." -- Charles Schultz > > > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SATA RAID Support
On Fri, Feb 25, 2005 at 12:05:43PM +0100, Oliver Brandmueller wrote: > > On Fri, Feb 25, 2005 at 09:33:39AM +0100, Francois Tigeot wrote: > > On Fri, Feb 25, 2005 at 12:31:22AM +0100, Oliver Brandmueller wrote: > > > We had problems here with 3ware + 72GB Raptors (10 krpm), so we moved to > > > > What sort of problems ? > > I was planning to use some sort of 3Ware/Raptor combination with amd64 > > -STABLE machines in the near future, and I am very interested by your > > experience... > > Under heavy load (I/O load on the disks constantly over 200 tps, average > at about 250 tps, peaks over 600 tps) a random drive disconnects from > the RAID 10. After removing the drive from the config and rescanning the > bus, the drive does not show up anymore. The only way to get the drive > back is to unplug the drive (or switch the computer off, so that power > is removed). After that there is no problem to rebuild the RAID with > the drive. Interesting. AFAIR the same sort of errors occured with some older WD drives and 3Ware 750x controllers. The solution was to flash the drives firmware. A quick googling found some reference to the problem on this document: http://japan.3ware.com/products/pdf/Drive_compatibility_list.pdf -- Francois Tigeot ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
gmirror over ggate{d,c}
Hi! I trying create distributed mirror. Machines interconnect 1Gbit. I exporting slice /dev/ar0s1g via ggated on first node. Import them via ggatec on second node. Include ggate0 in gmirrored slice data and run "gmirror rebuild". After some time I get messages on console: GEOM_MIRROR: Synchronization request failed (error=5). ggate0[WRITE(offse t=511442944, length=131072)] GEOM_MIRROR: Device data: provider ggate0 disconnected. GEOM_MIRROR: Device data: rebuilding provider ggate0 stopped. First node -- 5.3-STABLE. Second -- 5.3-RELEASE. Any ideas? May be some enhanced information needed? By. Dmitriy By. Dmitriy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Smartmontools strange error
I have a disk array on a machine: ... atapci3: port 0xc000-0xc0ff,0xbc00-0xbc03,0xb800-0xb807,0xb400-0xb403,0xb000-0xb007 irq 10 at device 15.0 on pci0 ata6: channel #0 on atapci3 ata7: channel #1 on atapci3 atapci4: port 0xd400-0xd4ff,0xd000-0xd003,0xcc00-0xcc07,0xc800-0xc803,0xc400-0xc407 irq 10 at device 15.1 on pci0 ata8: channel #0 on atapci4 ata9: channel #1 on atapci4 atapci5: port 0xe800-0xe80f,0xe400-0xe403,0xe000-0xe007,0xdc00-0xdc03,0xd800-0xd807 mem 0xdf001000-0xdf0010ff irq 11 at device 17.0 on pci0 ata10: channel #0 on atapci5 ata11: channel #1 on atapci5 ... ad4: 78167MB [158816/16/63] at ata2-master UDMA133 ad6: 76319MB [155061/16/63] at ata3-master UDMA100 ad8: 76319MB [155061/16/63] at ata4-master UDMA100 ad10: 76319MB [155061/16/63] at ata5-master UDMA100 ad12: 76319MB [155061/16/63] at ata6-master UDMA100 ad14: 76319MB [155061/16/63] at ata7-master UDMA100 ad16: 76319MB [155061/16/63] at ata8-master UDMA100 ad18: 76319MB [155061/16/63] at ata9-master UDMA100 ad20: 76319MB [155061/16/63] at ata10-master UDMA100 ad22: 76319MB [155061/16/63] at ata11-master UDMA100 And I'm having some odd behavior with Smartmontools. Most of the drives work fine, however ad20 returns what looks like corrupted data: smartctl version 5.32 Copyright (C) 2002-4 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Device Model: 00MAXTOR 4K080H4 Serial Number:QT674131022929 Firmware Version: [No Information Found] Device is:Not in smartctl database [for details use: -P showall] ATA Version is: 1 ATA Standard is: Not recognized. Minor revision code: 0x3e Local Time is:Fri Feb 25 10:44:26 2005 EST SMART is only available in ATA Version 3 Revision 3 or greater. We will try to proceed in spite of this. SMART support is: Ambiguous - ATA IDENTIFY DEVICE words 82-83 don't show if SMART supported. A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options. Of course smartctl refuses to work with this drive (it works with all of the other ones). My first thought was that the firmware on the drive was somehow corrupt, but the drive otherwise appears to work fine. It even works pefectly if I use the DOS based disk manager that came with the drives (MaxBlast I think it was called). For comparision, a normal drive returns something like: smartctl version 5.32 Copyright (C) 2002-4 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Device Model: MAXTOR 4K080H4 Serial Number:674131125634 Firmware Version: A08.1500 Device is:In smartctl database [for details use: -P show] ATA Version is: 5 ATA Standard is: ATA/ATAPI-5 T13 1321D revision 1 Local Time is:Fri Feb 25 10:46:14 2005 EST SMART support is: Available - device has SMART capability. SMART support is: Enabled Is there something I can do to make that drive happier? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
discarded oversize frames
I installed 5.3-STABLE a couple weeks back onto what is to become an office mail server, and after cvsupping to RELENG_5, I began to notice the following in dmesg: vr0: discard oversize frame (ether type 800 flags 3 len 1515 > max 1514) It happens several times after booting, and then about once a minute after that. At first I suspected the network card itself, so I added an eepro100 that's always worked fine for me, and then got: fxp0: discard oversize frame (ether type 800 flags 3 len 1515 > max 1514) after I had rebooted. Yesterday I cvsupped again (to 5.4-PRERELEASE) and the warnings still persisted. It doesn't noticeably impact stability or performance, but it does fill up dmesg rather quickly, and makes the nightly status emails rather large. Is this something I should be worried about, or is it indicative of something else faulty in the local network setup? I've attached output from dmesg and pciconf, the kernel config is GENERIC. Please forgive the "eth0" device name, as I have to migrate several Linux users and it's easier for me to change the interface name than peruse everyone's homedirs and update their scripts. :) best, -- Jonathan "CowboyNeal" Pater | [EMAIL PROTECTED] http://cowboyneal.org/ | http://slashdot.org/ "Don't worry about the world coming to an end today. It's already tomorrow in Australia." -- Charles Schultz Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...2 2 1 1 0 1 1 1 0 0 done No buffers busy after final sync Uptime: 4m19s Waiting (max 60 seconds) for system process `hpt_wt' to stop...done ukphy0: detached miibus1: detached Shutting down ACPI Rebooting... Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.4-PRERELEASE #0: Thu Feb 24 12:00:24 EST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) XP 2000+ (1666.74-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x662 Stepping = 2 Features=0x383fbff AMD Features=0xc040 real memory = 805240832 (767 MB) avail memory = 778219520 (742 MB) ioapic0 irqs 0-23 on motherboard npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xe000-0xe3ff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci0: at device 8.0 (no driver attached) fxp0: port 0xd400-0xd43f mem 0xdfe0-0xdfef,0xdfff7000-0xdfff7fff irq 18 at device 10.0 on pci0 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:d0:b7:5d:80:b8 atapci0: port 0xd800-0xd8ff,0xdc00-0xdc0f,0xe000-0xe003,0xe400-0xe407,0xe800-0xe803,0xec00-0xec07 irq 20 at device 15.0 on pci0 ata2: channel #0 on atapci0 ata3: channel #1 on atapci0 atapci1: port 0xfc00-0xfc0f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 15.1 on pci0 ata0: channel #0 on atapci1 ata1: channel #1 on atapci1 uhci0: port 0xc400-0xc41f irq 21 at device 16.0 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xc800-0xc81f irq 21 at device 16.1 on pci0 usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xcc00-0xcc1f irq 21 at device 16.2 on pci0 usb2: on uhci2 usb2: USB revision 1.0 uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xd000-0xd01f irq 21 at device 16.3 on pci0 usb3: on uhci3 usb3: USB revision 1.0 uhub3: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered pci0: at device 16.4 (no driver attached) isab0: at device 17.0 on pci0 isa0: on isab0 pci0: at device 17.5 (no driver attached) vr0: port 0xbc00-0xbcff mem 0xdfff6d00-0xdfff6dff irq 23 at device 18.0 on pci0 miibus1: on vr0 ukphy0: on miibus1 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: Ethernet address: 00:50:2c:a6:ac:ed acpi_button1: on acpi0 fdc0: port 0x3f7,0x3f4-0x3f5,0x3f2-0x3f3 irq 6 drq 2 on acpi0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A ppc0: port
Re: SATA RAID Support
Hi. On Fri, Feb 25, 2005 at 03:29:35AM -0800, David G. Lawrence wrote: >This sounds like a bug in the drive firmware. Did you look into any > firmware updates from Western Digital? It's possible that the 3ware > controllers push the drives a bit harder and expose problems that wouldn't > show up at slightly lower TPS rates. We suspect an incompatibility between controller and drive: The drive totally locks up at that point. But with another controller (and th ICP isn't really slower) we don't see the behaviour. I have no per disk statistics on the 3ware, so I cannot tell about the tps on a single disk compared to the ICP. We saw no firmware upgrade from WD and mail sent to them was only answered by a bot, that sent a totally useless FAQ. >We (TeraSolutions and Download Technologies) have deployed the 3ware > 9500S controllers extensively and haven't seen any problems with the 7k250 > and 7k400 series Hitachi drives that we use with them. We have the 7506 with 7200 PATA drives and have no problem at all with them. The only time a disk failed in that setup, that was really a failing disk. Rebuild worked as expected in the prod system; of course we check every new system for a working rebuild by removing a disk or even sometimes by building a RAID on a known bad disk. - Oliver -- | Oliver Brandmueller | Offenbacher Str. 1 | Germany D-14197 Berlin | | Fon +49-172-3130856 | Fax +49-172-3145027 | WWW: http://the.addict.de/ | | Ich bin das Internet. Sowahr ich Gott helfe. | | Eine gewerbliche Nutzung aller enthaltenen Adressen ist nicht gestattet! | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
HEADS UP: netipx mega-MFC (1/2)
I've just merged a fairly large set of changes to the netipx tree from HEAD to RELENG_5. These primarily consist of structural changes required for the locking of the netipx protocol, but excludes the locking changes themselves. The theory is we'll let these changes settle for a few days, then bring the locking changes in in time for 5.4-RELEASE. While these changes have been tested in HEAD, and have been in the tree generally for at least a month, netipx doesn't get a lot of exercise so there may be problems. Please let me know if you experience any. I have received at least one report that netipx is still not working with Mars in RELENG_5. I hope to follow up on that report shortly. Unfortunately, I don't have a significant local IPX setup to test with, so have to release on third party reports. In general, when reporting netipx issues, it would be very helpful if you could indicate whether whatever problem you're experiencing occurs in the 4.x tree, in 5.x before my recent changes, and 5.x after my recent changes. Thanks, Robert N M Watson ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SATA RAID Support
> Under heavy load (I/O load on the disks constantly over 200 tps, average > at about 250 tps, peaks over 600 tps) a random drive disconnects from > the RAID 10. After removing the drive from the config and rescanning the > bus, the drive does not show up anymore. The only way to get the drive > back is to unplug the drive (or switch the computer off, so that power > is removed). After that there is no problem to rebuild the RAID with > the drive. > > -> It's not reproducable. The error occurs under high load, sometimes >three times a week, sometimes it does not happen in 3 months. > > -> It happens only with the Raptors. > > -> It's always a random drive, there's no drive, that disconnects more >often This sounds like a bug in the drive firmware. Did you look into any firmware updates from Western Digital? It's possible that the 3ware controllers push the drives a bit harder and expose problems that wouldn't show up at slightly lower TPS rates. We (TeraSolutions and Download Technologies) have deployed the 3ware 9500S controllers extensively and haven't seen any problems with the 7k250 and 7k400 series Hitachi drives that we use with them. One of the cool things about the 3ware controllers is that they will automatically do bad block reassignment by first recovering the data from the redundancy, issuing a block reassignment to the drive, and then writing the recovered block back out to the new (reassigned) block. This may seem pretty basic for RAID, but many controllers we've tested actually don't do this. -DG David G. Lawrence President Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500 TeraSolutions, Inc. - http://www.terasolutions.com - (888) 346 7175 The FreeBSD Project - http://www.freebsd.org Pave the road of life with opportunities. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Booting from GPT on i386 [Re: Hardcoding gmirror provider]
Am Mittwoch, 23. Februar 2005 11:24 schrieb Poul-Henning Kamp: > >+> The c partition is a problem you have to address anyway (and it is > >+> best addressed by removing the magicness of the c partition > >+> altogether). [...] > > > >It is not going to be removed. We're going to wait for MBR to die. > > s/MBR/BSDlabel/ My servers boot from CF-Card so all my hard disks are GPT sliced only. Will it be possible to boot from GPT disks on i386(amd64)? Is anyone currently working on that?. That's what I'm really missing. Thanks, -Harry pgpJ2MtMetZEE.pgp Description: PGP signature
Re: acpi_bus_number: can't get _ADR issue on Intel D923XCV Motherboard.
John Baldwin wrote: On Thursday 24 February 2005 05:30 am, Mateusz JÄdrasik wrote: Hi, I have a D925XCV Intel motherboard, with if_sk on it as a builtin ethernet adapter. on bootup of 5.3-RELEASE i recieve some acpi_bus_number: can't get _ADR issues and errors /dmesg follows/. I tried changing pnp os on/off, updated my bios to the most recent release, disabled all integrated devices but the ethernet, im pretty much out of ideas now. If there is any suggestion on what i could perhaphs do, it would be more than welcome, and I gladly would supply any debug information required in the process of the eventual tracking down of the error. I will plug a pci card in there for now, but this is not quite the solution i would be looking for. Also, I presume the audio card is not supported yet? It's to be some realtek chipset, also integrated, afaik. Your network device just isn't supported yet: Okay sorry about the email before, i stand corrected ;) I tried stable from 20050224, the last 5.3 /next is 5.4-PRERELEASE/ and i recieve the same errors, with _ADR acpi, and also the device seems not supported. pcib3: at device 28.1 on pci0 pci4: on pcib3 pci4: at device 0.0 (no driver attached) It may be very trivial to add support for it. Can you get the output of 'pciconf -lv' for the pci4:0:0 device? Also, do you know if this network adapter is supposed to be a 10/100 adapter or a 10/100/1000 (Gigabit)? Yes, as i believe the if_sk would simply require some kind of identity lift? Anywho, here follows the pciconf -vl of the machine, hope that clears things up somehow. cheers. [EMAIL PROTECTED]:0:0: class=0x06 card=0x43568086 chip=0x25848086 rev=0x04 hdr=0x00 vendor = 'Intel Corporation' device = '925x Memory Controller Hub' class= bridge subclass = HOST-PCI [EMAIL PROTECTED]:1:0: class=0x060400 card=0x0088 chip=0x25858086 rev=0x04 hdr=0x01 vendor = 'Intel Corporation' device = '925x PCI Express Root Port' class= bridge subclass = PCI-PCI [EMAIL PROTECTED]:27:0: class=0x040300 card=0xe4008086 chip=0x26688086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801FB/FR/FW/FRW Intel High Deficition Audio Controller' class= multimedia [EMAIL PROTECTED]:28:0: class=0x060400 card=0x0040 chip=0x26608086 rev=0x03 hdr=0x01 vendor = 'Intel Corporation' device = '82801FB/FR/FW/FRW PCI Express Port 1' class= bridge subclass = PCI-PCI [EMAIL PROTECTED]:28:1: class=0x060400 card=0x0040 chip=0x26628086 rev=0x03 hdr=0x01 vendor = 'Intel Corporation' device = '82801FB/FR/FW/FRW PCI Express Port 2' class= bridge subclass = PCI-PCI [EMAIL PROTECTED]:28:2: class=0x060400 card=0x0040 chip=0x26648086 rev=0x03 hdr=0x01 vendor = 'Intel Corporation' device = '82801FB/FR/FW/FRW PCI Express Port 3' class= bridge subclass = PCI-PCI [EMAIL PROTECTED]:28:3: class=0x060400 card=0x0040 chip=0x26668086 rev=0x03 hdr=0x01 vendor = 'Intel Corporation' device = '82801FB/FR/FW/FRW PCI Express Port 4' class= bridge subclass = PCI-PCI [EMAIL PROTECTED]:29:0: class=0x0c0300 card=0x43568086 chip=0x26588086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801FB/FR/FW/FRW USB UHCI Controller' class= serial bus subclass = USB [EMAIL PROTECTED]:29:1: class=0x0c0300 card=0x43568086 chip=0x26598086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801FB/FR/FW/FRW USB UHCI Controller' class= serial bus subclass = USB [EMAIL PROTECTED]:29:2: class=0x0c0300 card=0x43568086 chip=0x265a8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801FB/FR/FW/FRW USB UHCI Controller' class= serial bus subclass = USB [EMAIL PROTECTED]:29:3: class=0x0c0300 card=0x43568086 chip=0x265b8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801FB/FR/FW/FRW USB UHCI Controller' class= serial bus subclass = USB [EMAIL PROTECTED]:29:7: class=0x0c0320 card=0x43568086 chip=0x265c8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801FB/FR/FW/FRW USB 2.0 EHCI Controller' class= serial bus subclass = USB [EMAIL PROTECTED]:30:0: class=0x060401 card=0x0050 chip=0x244e8086 rev=0xd3 hdr=0x01 vendor = 'Intel Corporation' device = '82801BA/CA/DB/DBL/EB/ER (ICH2/3/4/4-L/5/5R), 6300ESB Hub Interface to PCI Bridge' class= bridge subclass = PCI-PCI [EMAIL PROTECTED]:31:0: class=0x060100 card=0x43568086 chip=0x26408086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801FB/FR ICH6/ICH6R LPC Controller' class= bridge subclass = PCI-ISA [EMAIL PROTECTED]:31:1: class=0x01018a card=0x43568086 chip=0x266f8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801FB ICH6 Ultra ATA Storage Controller' class= mass storage subclass = AT
Re: SATA RAID Support
Hi.
On Fri, Feb 25, 2005 at 09:33:39AM +0100, Francois Tigeot wrote:
> On Fri, Feb 25, 2005 at 12:31:22AM +0100, Oliver Brandmueller wrote:
> > We had problems here with 3ware + 72GB Raptors (10 krpm), so we moved to
>
> What sort of problems ?
> I was planning to use some sort of 3Ware/Raptor combination with amd64
> -STABLE machines in the near future, and I am very interested by your
> experience...
Under heavy load (I/O load on the disks constantly over 200 tps, average
at about 250 tps, peaks over 600 tps) a random drive disconnects from
the RAID 10. After removing the drive from the config and rescanning the
bus, the drive does not show up anymore. The only way to get the drive
back is to unplug the drive (or switch the computer off, so that power
is removed). After that there is no problem to rebuild the RAID with
the drive.
-> It's not reproducable. The error occurs under high load, sometimes
three times a week, sometimes it does not happen in 3 months.
-> It happens only with the Raptors.
-> It's always a random drive, there's no drive, that disconnects more
often
-> It happens with 8506 and 9500 type of SATA 3ware Escalade
-> It does not depend on the firmware of the controller, we tried
different versions
-> With the same drives, same OS, same motherboard, same drive bays
but an ICP controller we never saw the error.
-> FBSD 5.1-CURRENT up to 5-STABLE as of mid january
What we did not yet try:
- other OS
- other drives (in fact, the raptors are the only SATA drives with
10 krpm available - or at least were when we bought the machines).
slower drives are not an options here.
We did not see this dureing testing, but the testing phase was very
short (only 2 weeks). During the tests we let dd's run, bonnie++ and
different other things, but none of the usual tools obviously put enough
load constantly on the disks. The machines are spamfilters. As long as
we have more machines working (meaning lower workload for each machine)
or the load goes down due to other reasons, the errors don't occur
anymore (we almost never see a failed drive on a weekend, but during the
week between 10 and 12 local time we see it more often). So I guess,
that most people won't see this error in their setups, especially when
they need the disk performance only during peaks.
My experience with the ICP Vortex controllers is very well up to now.
They are fast and the management software is very comfortable. The only
thing I'm missing is the simplicity of tw_cli (the management tool for
the 3wares), which allowed to request status of the RAID by a simple
script. The ICP software ("srcd") is more flexible, but only gives you
the opportunity to execute a program on an event or send an SNMP trap.
Both is fine, but is a little bit more complicated to include in nagios
for example.
- Oliver
--
| Oliver Brandmueller | Offenbacher Str. 1 | Germany D-14197 Berlin |
| Fon +49-172-3130856 | Fax +49-172-3145027 | WWW: http://the.addict.de/ |
| Ich bin das Internet. Sowahr ich Gott helfe. |
| Eine gewerbliche Nutzung aller enthaltenen Adressen ist nicht gestattet! |
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SATA RAID Support
On Fri, Feb 25, 2005 at 12:31:22AM +0100, Oliver Brandmueller wrote: > > We had problems here with 3ware + 72GB Raptors (10 krpm), so we moved to What sort of problems ? I was planning to use some sort of 3Ware/Raptor combination with amd64 -STABLE machines in the near future, and I am very interested by your experience... -- Francois Tigeot ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
