HP Q200 FC HBA
Dear all, i would like to know if HP Q200 FC HBA bus adapter is supported by FreBSD. It's sold with HP storageworks MSA1000 SAN kit . It could be a qlogic card renamed ... or not ? Best regards, Paolo Tealdi Ing. Paolo Tealdi Servizi Informatici per le Biblioteche Politecnico Torino Phone : +39-011-5646714 , FAX : +39-011-5646799 C.so Duca degli Abruzzi, 24 - 10129 Torino - ITALY Email : [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HP Q200 FC HBA
Paolo Tealdi wrote: Dear all, i would like to know if HP Q200 FC HBA bus adapter is supported by FreBSD. It's sold with HP storageworks MSA1000 SAN kit . It could be a qlogic card renamed ... or not ? It probably is. From http://www.freebsd.org/releases/6.2R/hardware-i386.html : Cards supported by the isp(4) driver include: * ISP1000 * ISP1020 * ISP1040 * Qlogic 1240 * Qlogic 1020 * Qlogic 1040 * Qlogic 1080 * Qlogic 1280 * Qlogic 12160 * Qlogic 210X * Qlogic 220X * Qlogic 2300 * Qlogic 2312 * Qlogic 234X * Qlogic 2322 * Qlogic 200 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Binary upgrade script problem
On Thu, Mar 22, 2007 at 04:44:42PM +0100, Harald Weis wrote: I've run Colin Percival's binary upgrade scripts on my spare machine. It worked fine from 6.0 t0 6.1. For 6.1 to 6.2 the script stops during the ``The following files will be removed ...'' phase. Exactly same stop for three fresh trials which look alright up to the stop: /usr/share/doc/en_US.ISO8859-1/books/porters-handbook/x1950.html byte 3107 Sorry, Colin, for asking you directly. Is there nothing I could do to find out the reason for this stop ? The output of ``uname -a'' of that spare box is: FreeBSD castor.local.hawei.net2.nerim.net 6.1-SECURITY FreeBSD 6.1-SECURITY #0: Wed Feb 14 15:33:28 UTC 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 Harald Weis -- FreeBSD 6.1-RELEASE #0: Sun May 7 04:42:56 UTC 2006 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Amd64 Unstable Areca
On 3/25/07, Scott Long [EMAIL PROTECTED] wrote: Nikolas Britton wrote: Yeah are hardware is nearly identical. I don't remember what I did to my custom driver, I know I fixed some syntax errors and merged in changes that were made on top of the 1.20.00.02 code base. I'm not sure but I think most of those changes were thrown out with the import of 1.20.00.13 and 14. Yes ..0.13 is the driver from 6.2-RELEASE-p2 and no I don't see any g_vfs errors, I do see a crap load of httpd errors that someone needs to investigate, lucky me. :-/ It's not likely I'd see them anyhow because the business slows way down during this time of year: Please try the following patch against the latest 6-STABLE driver sources: http://people.freebsd.org/~scottl/arcmsr.simq.diff. Thanks Scott... Unfortunately, or fortunately depending on your outlook, spring break ends today and I've got a crap load of studying to do, so no time to play guinea pig... But because I'm such a nice guy I've compiled i386 and amd64 binaries so the others can play along. I compiled everything against 6.2-RELEASE-p2... Download them here: http://www.nbritton.org/uploads/areca/fb62/ Do you have any testing scripts so the group can do repeatable comparison tests using the old and new kernel modules? Thanks. Oh and here's a file list but gmail is probably going to mutilate it: arcmsr.c.1824: ASCII C program text arcmsr.h.1142: ISO-8859 C program text arcmsr.kld.fb62.i386.032607: ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD), not stripped arcmsr.ko.debug.fb62.amd64.032607: ELF 64-bit LSB relocatable, AMD x86-64, version 1 (FreeBSD), not stripped arcmsr.ko.fb62.amd64.032607: ELF 64-bit LSB relocatable, AMD x86-64, version 1 (FreeBSD), not stripped arcmsr.ko.fb62.i386.032607:ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped arcmsr.o.fb62.amd64.032607:ELF 64-bit LSB relocatable, AMD x86-64, version 1 (FreeBSD), not stripped arcmsr.o.fb62.i386.032607: ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD), not stripped i386_build_log.txt:ASCII text, with very long lines ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gmirror Issues
On 12/23/-58 20:59, Joe Kelsey wrote: I am having a real hard time with gmirror. I recently bought two new 400G SATA disks and I want to mirror them. I think I am following the directions, but I am not sure. I generally do the following steps: edit /boot/loader.conf to add geom_mirror_load. reboot into single-user gmirror label -v -b round-robin gm0 ad4s1 ad6s1 bsdlabel -w mirror/gm0 bsdlabel -e mirror/gm0 newfs mirror/gm0a Joe, check what `bsdlabel mirror/gm0' gives right after editing the partitioning information and re-check that info after a reboot. There might be an issue... Check if bsdlabel complains about partition c not being sized well. Could you please try to `gmirror unload' before doing anything and a `gmirror load' right after labeling the mirror? Or just try a reboot after labeling the mirror. If that does make a difference, it's a sign I've been right with my last week's experience. If you're still getting into trouble, you may want to zero out the first sectors of the disk using `dd'. When creating a 400 gig mirror, it will take a long time for the mirror to complete and you're mirroring waste in the first step. I would recommend to create the mirror with just one consumer, create the partitions, newfs and then insert the 2nd consumer into the mirror. Just to make sure, I would check the status of the mirror using `gmirror status' and wait until its state is COMPLETE before doing anything else. BTW, do you really want to use a dangerously dedicated disk (by using gm0X) without any slices? HTH, Volker ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Amd64 Unstable Areca
El dom, 25-03-2007 a las 10:11 -0600, Scott Long escribió:
Nikolas Britton wrote:
Yeah are hardware is nearly identical. I don't remember what I did to
my custom driver, I know I fixed some syntax errors and merged in
changes that were made on top of the 1.20.00.02 code base. I'm not
sure but I think most of those changes were thrown out with the import
of 1.20.00.13 and 14.
Yes ..0.13 is the driver from 6.2-RELEASE-p2 and no I don't see any
g_vfs errors, I do see a crap load of httpd errors that someone needs
to investigate, lucky me. :-/ It's not likely I'd see them anyhow
because the business slows way down during this time of year:
Please try the following patch against the latest 6-STABLE driver
sources: http://people.freebsd.org/~scottl/arcmsr.simq.diff.
Scott
Scott unfortunatly, yesterday the box crashed again, with your patches
dont know if the problem is FS related tho.
I still didnt do what Jan sudgested, i.e. reformat the partitions. i may
do this tonight.
thanks!
Unread portion of the kernel message buffer:
6pid 94219 (sh), uid 0: exited on signal 11
6pid 94241 (sh), uid 0: exited on signal 11
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x38
fault code = supervisor write data, page not present
instruction pointer = 0x8:0x805bda49
stack pointer = 0x10:0xb7aab9a0
frame pointer = 0x10:0x4
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 94245 (sh)
trap number = 12
panic: page fault
cpuid = 0
Uptime: 5h19m40s
Dumping 2047 MB (2 chunks)
chunk 0: 1MB (156 pages) ... ok
chunk 1: 2047MB (524016 pages) 2031 2015 1999 1983 1967 1951 1935 1919 1903
1887 1871 1855 1839 1823 1807 1791 1775 1759 1743 1727 1711 1695 1679 1663 1647
1631 1615 1599 1583 1567 1551 1535 1519 1503 1487 1471 1455 1439 1423 1407 1391
1375 1359 1343 1327 1311 1295 1279 1263 1247 1231 1215 1199 1183 1167 1151 1135
1119 1103 1087 1071 1055 1039 1023 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:172
172 __asm __volatile(movq %%gs:0,%0 : =r (td));
(kgdb) bt
#0 doadump () at pcpu.h:172
#1 0x0004 in ?? ()
#2 0x80409447 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:409
#3 0x80409ae1 in panic (fmt=0xff003b32e260 �\226�A)
at /usr/src/sys/kern/kern_shutdown.c:565
#4 0x8062b17f in trap_fatal (frame=0xff003b32e260,
eva=18446742975299032752)
at /usr/src/sys/amd64/amd64/trap.c:668
#5 0x8062b4fc in trap_pfault (frame=0xb7aab8f0, usermode=0)
at /usr/src/sys/amd64/amd64/trap.c:580
#6 0x8062b7b3 in trap (frame=
{tf_rdi = -1097399663144, tf_rsi = 130, tf_rdx = -2140101835, tf_rcx =
-1099185419872, tf_r8 = -2137937120, tf_r9 = -1098518437280, tf_rax =
-1098518437280, tf_rbx = 0, tf_rbp = 4, tf_r10 = -2137799976, tf_r11 =
-1098518437280, tf_r12 = -1097399663144, tf_r13 = -2140101835, tf_r14 =
-1213547824, tf_r15 = -1097492989984, tf_trapno = 12, tf_addr = 56, tf_flags =
-1098518437280, tf_err = 2, tf_rip = -2141463991, tf_cs = 8, tf_rflags = 66050,
tf_rsp = -1213548112, tf_ss = 0})
at /usr/src/sys/amd64/amd64/trap.c:353
#7 0x806167eb in calltrap () at
/usr/src/sys/amd64/amd64/exception.S:168
#8 0x805bda49 in vm_page_sleep_if_busy (m=0xff007de205d8,
also_m_busy=130,
msg=0x8070a335 vmpfw) at atomic.h:139
#9 0x805b09e7 in vm_fault (map=0xff0013532440,
vaddr=140737488338944,
fault_type=2 '\002', fault_flags=8) at /usr/src/sys/vm/vm_fault.c:397
#10 0x8062b3b7 in trap_pfault (frame=0xb7aabc40, usermode=1)
at /usr/src/sys/amd64/amd64/trap.c:557
#11 0x8062b943 in trap (frame=
{tf_rdi = 5358048, tf_rsi = 0, tf_rdx = 1, tf_rcx = 34369249980, tf_r8 =
-1098728259232, tf_r9 = 140737488343064, tf_rax = 0, tf_rbx = 140737488343408,
tf_rbp = 5423104, tf_r10 = -2035732464, tf_r11 = 0, tf_r12 = 0, tf_r13 = 2,
tf_r14 = 1, tf_r15 = 5399624, tf_trapno = 12, tf_addr = 140737488343016,
tf_flags = 12, tf_err = 7, tf_rip = 4254692, tf_cs = 43, tf_rflags = 66118,
tf_rsp = 140737488343024, tf_ss = 35}) at /usr/src/sys/amd64/amd64/trap.c:283
---Type return to continue, or q return to quit---
#12 0x806167eb in calltrap () at
/usr/src/sys/amd64/amd64/exception.S:168
#13 0x0040ebe4 in ?? ()
Previous frame inner to this frame (corrupt stack?)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To
Re: gmirror Issues
On Mar 25, 2007, at 11:59 PM, Christopher Schulte wrote: As I understand it now, the user has to manually account for this at OS install, and adjust the disk layout accordingly... yes? when was the last time you ran fdisk and it didn't leave some spare sectors at the end? i don't think you have to do anything special when this happens. at least we don't :-)
Re: HP Q200 FC HBA
On Mon, Mar 26, 2007 at 11:30:10AM +0200, Paolo Tealdi wrote.. Dear all, i would like to know if HP Q200 FC HBA bus adapter is supported by FreBSD. It's sold with HP storageworks MSA1000 SAN kit . It could be Q200?? In general, most of our adapters are OEM-ed from QLogic. Or from Emulex. The Qlogics are generally supported by the isp(4) driver. If this MSA1000 SAN kit was originally sold for Linux deployment you have a Qlogic. A close look at the chip on the adapter will quickly enlighten you. -- Wilko Bulte [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pitiful performance of an SATA150 drive
Over a year later this remains a problem -- exactly as described below... No other SATA devices are present -- the only other IDE device is the DVD drive. My main disks are SCSI. What's MUCH worse is that the (slowly) written data is also often corrupted... I use the drive to store our vast collection of photos and the backups. Every once in a while I encounter a corrupt JPEG file, and the backups are _always_ corrupt somewhere. Doing something like: dump 0auChf 16 0 - /home | bzip2 -9 /store/home.0.bz2 always produces a corrupt file (as per ``bzip2 -t''). I used to blame the drive's temperature, but it now sits in its own enclosure and stays under 40 Celsius. When the drive is accessed, there are (according to `systat -vm') many thousands of interrupts 17 -- on my system these are shared between pcm0 and ehci0. Why are these triggered by accessing SATA is unclear, but the Intr's share of the CPU time is often above 80% of one processor's total (I have 4 processors). As I mentioned a year ago, Knoppix was accessing the same drive at much higher speeds, so I don't believe, the problem is with the hardware... Please, advise. Thanks! -mi On Wednesday 01 March 2006 11:07, Mikhail Teterin wrote: = On Wednesday 01 March 2006, SЬren Schmidt wrote: = = dd if=/dev/ad8 of=/dev/null bs=1m = = Well, as I said, there is no obvious problems with _reading_. The above = command reads at well over 60Mb/s: = = 1638924288 bytes transferred in 25.374856 secs (64588516 bytes/sec) = = _Writing_, however, remains pathetic: = = dd of=/dev/ad8 if=/dev/zero bs=1m = 631242752 bytes transferred in 91.039066 secs (6933757 bytes/sec) = = = The problem is the blocksize that gets in the way of utilizing full = = transfer speed. = = Did you really expect the blocksize to make an order of (decimal) magnitude = difference? :-) It made no difference at all :-( = = Brian Candler asked: = = Just to be clear: this is Knoppix running on the *same* machine as you've = = been testing FreeBSD? = = Correct. = = = Aside: why are you using cat under FreeBSD, but dd under Knoppix? I'd use dd = = everywhere for consistency. = = Cat was slightly faster in my tests on FreeBSD. I used dd under Knoppix for = dd's throughput reporting -- I'm not aware of a monitoring tool like `systat' = under Linux. = = Yours, = = -mi = ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gmirror Issues
On Sun, 2007-03-25 at 13:53 -0700, Joe Kelsey wrote: I am having a real hard time with gmirror. I recently bought two new 400G SATA disks and I want to mirror them. I think I am following the directions, but I am not sure. I have seen lockups, spontaneous reboots, corrupt filsystems on 6.0 and 6.2 trigger: 1.a disk io with rsync / scp say coping 100Gb 1.b making backup with tar 2. full filesystems setup: -ata controller card -two ata disks (250Gb) system is now in via itxboard. but was the same in inter p2 board I 've tested mem with memtest I 've replaced ata controller card I 've replaced disk If I can provide more debug info pls let me know. kind regards, Marten dmesg %cat /var/run/dmesg.boot Copyright (c) 1992-2007 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-STABLE #5: Sat Mar 3 10:47:32 CET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/henk Timecounter i8254 frequency 1193182 Hz quality 0 CPU: VIA C3 Samuel 2 (597.07-MHz 686-class CPU) Origin = CentaurHauls Id = 0x673 Stepping = 3 Features=0x803035FPU,DE,TSC,MSR,MTRR,PGE,MMX real memory = 201261056 (191 MB) avail memory = 187387904 (178 MB) acpi0: VT9174 AWRDACPI on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 cpu0: ACPI CPU on acpi0 acpi_throttle0: ACPI CPU Throttling on cpu0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: VIA 862x (CLE266) host to PCI bridge mem 0xc000-0xcfff at device 0.0 on pci0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) pci0: bridge, PCI-CardBus at device 10.0 (no driver attached) pci0: bridge, PCI-CardBus at device 10.1 (no driver attached) uhci0: VIA 83C572 USB controller port 0xc000-0xc01f irq 5 at device 16.0 on pci0 uhci0: [GIANT-LOCKED] usb0: VIA 83C572 USB controller 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: VIA 83C572 USB controller port 0xc400-0xc41f irq 12 at device 16.1 on pci0 uhci1: [GIANT-LOCKED] usb1: VIA 83C572 USB controller 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: VIA 83C572 USB controller port 0xc800-0xc81f irq 9 at device 16.2 on pci0 uhci2: [GIANT-LOCKED] usb2: VIA 83C572 USB controller 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 ehci0: VIA VT6202 USB 2.0 controller mem 0xd700c000-0xd700c0ff irq 12 at device 16.3 on pci0 ehci0: [GIANT-LOCKED] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: VIA VT6202 USB 2.0 controller on ehci0 usb3: USB revision 2.0 uhub3: VIA EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub3: 6 ports with 6 removable, self powered isab0: PCI-ISA bridge at device 17.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 8235 UDMA133 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xcc00-0xcc0f at device 17.1 on pci0 ata0: ATA channel 0 on atapci0 ata1: ATA channel 1 on atapci0 pci0: multimedia, audio at device 17.5 (no driver attached) vr0: VIA VT6102 Rhine II 10/100BaseTX port 0xd800-0xd8ff mem 0xd700d000-0xd700d0ff irq 5 at device 18.0 on pci0 miibus0: MII bus on vr0 ukphy0: Generic IEEE 802.3u media interface on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: Ethernet address: 00:40:63:d5:e5:f5 atapci1: Promise PDC20269 UDMA133 controller port 0xdc00-0xdc07,0xe000-0xe003,0xe400-0xe407,0xe800-0xe803,0xec00-0xec0f mem 0xd700-0xd7003fff irq 12 at device 20.0 on pci0 ata2: ATA channel 0 on atapci1 ata3: ATA channel 1 on atapci1 sio0: 16550A-compatible COM port port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: 16550A-compatible COM port port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: Keyboard controller (i8042) port 0x60,0x64 irq 1 on acpi0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] pmtimer0 on isa0 orm0: ISA Option ROMs at iomem 0xc-0xcdfff,0xd8000-0xda7ff on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounter TSC frequency 597071185 Hz quality 800 Timecounters tick every 1.000 msec ad4: 238475MB Seagate ST3250823A 3.02 at ata2-master UDMA100 GEOM_MIRROR: Device gm0 created (id=222343067). GEOM_MIRROR: Device gm0: provider ad4 detected. ad6: 238475MB WDC WD2500JB-00GVA0 08.02D08 at ata3-master UDMA100 GEOM_MIRROR: Device gm0: provider ad6
Re: gmirror Issues
On Mar 26, 2007, at 11:19 AM, Marten wrote: On Sun, 2007-03-25 at 13:53 -0700, Joe Kelsey wrote: I am having a real hard time with gmirror. I recently bought two new 400G SATA disks and I want to mirror them. I think I am following the directions, but I am not sure. I have seen lockups, spontaneous reboots, corrupt filsystems on 6.0 and 6.2 trigger: 1.a disk io with rsync / scp say coping 100Gb 1.b making backup with tar 2. full filesystems setup: -ata controller card -two ata disks (250Gb) Try hunting around for the latest VIA test BIOS for the ITX M-series miniboards (check the viaarea.com web-forums, IIRC)...before updating to it, I tended to see fairly reproducible data corruption whenever accessing two or more IDE devices at the same time on a 600MHz VIA C3 ITX system. -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pitiful performance of an SATA150 drive
On Mon, Mar 26, 2007 at 02:36:27PM -0400, Mikhail Teterin wrote: Over a year later this remains a problem -- exactly as described below... No other SATA devices are present -- the only other IDE device is the DVD drive. My main disks are SCSI. What's MUCH worse is that the (slowly) written data is also often corrupted... I use the drive to store our vast collection of photos and the backups. Every once in a while I encounter a corrupt JPEG file, and the backups are _always_ corrupt somewhere. Doing something like: dump 0auChf 16 0 - /home | bzip2 -9 /store/home.0.bz2 always produces a corrupt file (as per ``bzip2 -t''). I used to blame the drive's temperature, but it now sits in its own enclosure and stays under 40 Celsius. I can't reproduce the corruption you report. I run massive backups (7 levels; level 0 on Sunday, 1-6 on Mon-Sat) in our co-location facility and have always had success with restore(8). We use gzip -2 not bzip2, for what it's worth. The dumps are done over SSH. When the drive is accessed, there are (according to `systat -vm') many thousands of interrupts 17 -- on my system these are shared between pcm0 and ehci0. Why are these triggered by accessing SATA is unclear, but the Intr's share of the CPU time is often above 80% of one processor's total (I have 4 processors). See below for some of my stats for comparison. As I mentioned a year ago, Knoppix was accessing the same drive at much higher speeds, so I don't believe, the problem is with the hardware... Please, advise. Thanks! Let's compare numbers and devices, since I use SATA devices exclusively on my own home network, as well as in both of my production co-los. I'll use my home network for the below tests. Here's the SATA controller I'm using (on-board nVidia): atapci2: nVidia nForce CK804 SATA300 controller port 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xc400-0xc40f mem 0xd3001000-0xd3001fff irq 21 at device 8.0 on pci0 ata4: ATA channel 0 on atapci2 ata5: ATA channel 1 on atapci2 ad8: 190782MB WDC WD2000JD-00HBB0 08.02D08 at ata4-master SATA150 ad10: 476940MB Seagate ST3500630AS 3.AAD at ata5-master SATA300 The motherboard itself is an Asus A8N-E with an AMD Athlon 64 X2 3800+ in it. Kernel is built with SMP. No overclocking. Data taken from smartctl (ports/sysutils/smartmontools); I'm including this because it shows general information about the drives. === START OF INFORMATION SECTION === Model Family: Western Digital Caviar SE (Serial ATA) family Device Model: WDC WD2000JD-00HBB0 Serial Number:WD-WCAL73023909 Firmware Version: 08.02D08 User Capacity:200,049,647,616 bytes Device is:In smartctl database [for details use: -P show] ATA Version is: 6 ATA Standard is: Exact ATA specification draft version not indicated Local Time is:Mon Mar 26 11:47:50 2007 PDT SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF INFORMATION SECTION === Model Family: Seagate Barracuda 7200.10 family Device Model: ST3500630AS Serial Number:3QG00GQ7 Firmware Version: 3.AAD User Capacity:500,107,862,016 bytes Device is:In smartctl database [for details use: -P show] ATA Version is: 7 ATA Standard is: Exact ATA specification draft version not indicated Local Time is:Mon Mar 26 11:48:09 2007 PDT SMART support is: Available - device has SMART capability. SMART support is: Enabled Filesystems: icarus# df -k Filesystem 1024-blocks Used Avail Capacity Mounted on /dev/ad8s1a 507630 6015040687013%/ devfs 1 1 0 100%/dev /dev/ad8s1d 16244334 45706 14899082 0%/var /dev/ad8s1e 16244334 920 14943868 0%/tmp /dev/ad8s1f 32494668 1307402 28587694 4%/usr /dev/ad8s1g115577350 1793544 104537618 2%/home procfs 4 4 0 100%/proc /dev/ad10s1d 473015558 121726480 31344783428%/storage devfs 1 1 0 100%/var/named/dev Pseudo-benchmarks: icarus# time dd if=/dev/ad8s1a of=/dev/null bs=1m 512+0 records in 512+0 records out 536870912 bytes transferred in 11.292704 secs (47541396 bytes/sec) icarus# time dd if=/dev/ad10s1d of=/dev/null bs=1m ^C6798+0 records in 6798+0 records out 7128219648 bytes transferred in 92.150703 secs (77353937 bytes/sec) 0.007u 1.319s 1:32.15 1.4% 27+2956k 0+0io 0pf+0w I consider these numbers pretty decent. The WD drive isn't performing as nice as I'd expect, but the Seagate drive definitely does. Adjusting the block size in dd doesn't make any difference; I've tried 16k, 32k, 64k, and 1m. There have been discussions in the past about using dd as a disk I/O tester on FreeBSD (vs. Linux), compared to a utility like bonnie++. Those may apply here, but I think your problem is elsewhere and not with dd on Linux vs. FreeBSD. :) Regarding interrupt
Re: pitiful performance of an SATA150 drive
Mikhail Teterin wrote: Over a year later this remains a problem -- exactly as described below... No other SATA devices are present -- the only other IDE device is the DVD drive. My main disks are SCSI. What's MUCH worse is that the (slowly) written data is also often corrupted... I use the drive to store our vast collection of photos and the backups. Every once in a while I encounter a corrupt JPEG file, and the backups are _always_ corrupt somewhere. Doing something like: dump 0auChf 16 0 - /home | bzip2 -9 /store/home.0.bz2 always produces a corrupt file (as per ``bzip2 -t''). I used to blame the drive's temperature, but it now sits in its own enclosure and stays under 40 Celsius. When the drive is accessed, there are (according to `systat -vm') many thousands of interrupts 17 -- on my system these are shared between pcm0 and ehci0. Why are these triggered by accessing SATA is unclear, but the Intr's share of the CPU time is often above 80% of one processor's total (I have 4 processors). As I mentioned a year ago, Knoppix was accessing the same drive at much higher speeds, so I don't believe, the problem is with the hardware... What HW was this again, there has been alot of updates/changes over the last year ? Could you try an up to date -current kernel on this, at least to get me a decent dmesg from ? If thats impossible take ATA from current modulus the busdma changes and use that on an up to date 6-stable. I cant tell what interrupts go where without a dmesg... Other than that, single bit/byte corruption are normally HW troubles of some kind, usually involving bad/incompatible memory or bad chipsets. However, if your drive has been overheated the media might have taken permanent damage that makes it loose data. What does SMART say on corrected errors etc (if the drive has that info). -Søren Please, advise. Thanks! -mi On Wednesday 01 March 2006 11:07, Mikhail Teterin wrote: = On Wednesday 01 March 2006, Søren Schmidt wrote: = = dd if=/dev/ad8 of=/dev/null bs=1m = = Well, as I said, there is no obvious problems with _reading_. The above = command reads at well over 60Mb/s: = = 1638924288 bytes transferred in 25.374856 secs (64588516 bytes/sec) = = _Writing_, however, remains pathetic: = = dd of=/dev/ad8 if=/dev/zero bs=1m = 631242752 bytes transferred in 91.039066 secs (6933757 bytes/sec) = = = The problem is the blocksize that gets in the way of utilizing full = = transfer speed. = = Did you really expect the blocksize to make an order of (decimal) magnitude = difference? :-) It made no difference at all :-( = = Brian Candler asked: = = Just to be clear: this is Knoppix running on the *same* machine as you've = = been testing FreeBSD? = = Correct. = = = Aside: why are you using cat under FreeBSD, but dd under Knoppix? I'd use dd = = everywhere for consistency. = = Cat was slightly faster in my tests on FreeBSD. I used dd under Knoppix for = dd's throughput reporting -- I'm not aware of a monitoring tool like `systat' = under Linux. = = Yours, = = -mi = . ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
possible bug in pxeboot with TFTP support
Hi all, I compiled pxeboot with TFTP support by doing: cd /usr/src/sys/boot make -DLOADER_TFTP_SUPPORT I have clients booting via PXE and grabbing their root filesystem from a memory disk. However, there was a long delay in the boot sequence. tcpdump revealed that after downloading pxeboot, the client was sending RPC traffic, presumably looking for NFS. This caused the boot to stall for 30 seconds or so until the loader spit out NFS MOUNT RPC error: 60 and then continued booting via tftp. I traced the error string back to /usr/src/sys/boot/i386/libi386/pxe.c and came up with a hack that skips the RPC probes and speeds the boot for me. pxe-server# diff -u sys/boot/i386/libi386/pxe.c.orig sys/boot/i386/libi386/pxe.c --- sys/boot/i386/libi386/pxe.c.origMon Mar 26 14:50:19 2007 +++ sys/boot/i386/libi386/pxe.c Mon Mar 26 14:46:02 2007 @@ -443,9 +443,10 @@ * ourselves. Use nfs_root_node.iodesc as flag indicating * previous NFS usage. */ - if (nfs_root_node.iodesc == NULL) - pxe_rpcmountcall(); - +/* XXX + * if (nfs_root_node.iodesc == NULL) + * pxe_rpcmountcall(); + */ fh = nfs_root_node.fh[0]; buf[0] = 'X'; cp = buf[1]; I'm wondering if someone with a clue can take a peek and confirm that things ought to behave differently. What I've stumbled across doesn't break PXE booting with a TFTP root filesystem, it just makes it much slower. Maybe I'm doing something wrong? Regards, RJ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pitiful performance of an SATA150 drive
On Monday 26 March 2007 15:21, Søren Schmidt wrote: = What HW was this again, there has been alot of updates/changes over the = last year ? It is now a quad core (dual CPU) Opteron-275 using IWill's DK8X motherboard. http://www.google.com/search?q=iwill+dk8x The SATA controller(s) are by LSI, not NVidia's (unlike in Jeremy's case). = Could you try an up to date -current kernel on this, at least to get me = a decent dmesg from ? Not easily -- this is my main machine... But _you_ have an account here :-). Try ssh-ing to [EMAIL PROTECTED] Your ssh key (same one you use on freefall) should work... = If thats impossible take ATA from current modulus the busdma changes and = use that on an up to date 6-stable. If you create a patch, I'll apply it, and rebuild/reboot, but I'm afraid to mess it up... Since I'm not using the drive most of the time (my regular work lives on the SCSI disks), I can even build ata and atadisk as modules, so you can try different changes without rebooting (umount, kldunload, kldload, mount). = I cant tell what interrupts go where without a dmesg... Attached. = Other than that, single bit/byte corruption are normally HW troubles of = some kind, usually involving bad/incompatible memory or bad chipsets. The system uses 4Gb of registered ECC memory and is quite stable in other respects... = However, if your drive has been overheated the media might have taken = permanent damage that makes it loose data. The highest temperature the drive has recorded is 63 Celsius. = What does SMART say on corrected errors etc (if the drive has that info). Attached. Thanks! Yours, -mi Copyright (c) 1992-2007 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-STABLE #1: Fri Mar 2 02:11:01 EST 2007 [EMAIL PROTECTED]:/meow/obj/var/src/sys/SILVER Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Dual Core AMD Opteron(tm) Processor 275 (2205.01-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x20f12 Stepping = 2 Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT Features2=0x1SSE3 AMD Features=0xe2500800SYSCALL,NX,MMX+,FFXSR,LM,3DNow!+,3DNow! AMD Features2=0x3LAHF,CMP Cores per package: 2 real memory = 4865392640 (4640 MB) avail memory = 4133154816 (3941 MB) ACPI APIC Table: A M I OEMAPIC FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 Version 1.1 irqs 0-23 on motherboard ioapic1 Version 1.1 irqs 24-27 on motherboard ioapic2 Version 1.1 irqs 28-31 on motherboard acpi0: A M I OEMXSDT on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x5008-0x500b on acpi0 cpu0: ACPI CPU on acpi0 acpi_throttle0: ACPI CPU Throttling on cpu0 cpu1: ACPI CPU on acpi0 cpu2: ACPI CPU on acpi0 cpu3: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: AMD 8151 AGP graphics tunnel at device 0.0 on pci0 agp0: 0x8000 bytes of rid 0x10 res 3 failed (0, 0x). device_attach: agp0 attach returned 12 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 drm0: ATI Radeon NG R300 FireGL X1 port 0x8000-0x80ff mem 0xf000-0xf7ff,0xde2f-0xde2f irq 16 at device 0.0 on pci1 info: [drm] Initialized radeon 1.25.0 20060524 pci1: display at device 0.1 (no driver attached) pcib2: ACPI PCI-PCI bridge at device 6.0 on pci0 pci2: ACPI PCI bus on pcib2 ohci0: OHCI (generic) USB controller mem 0xde3fd000-0xde3fdfff irq 19 at device 0.0 on pci2 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: OHCI (generic) USB controller on ohci0 usb0: USB revision 1.0 uhub0: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1: OHCI (generic) USB controller mem 0xde3fe000-0xde3fefff irq 19 at device 0.1 on pci2 ohci1: [GIANT-LOCKED] usb1: OHCI version 1.0, legacy support usb1: OHCI (generic) USB controller on ohci1 usb1: USB revision 1.0 uhub1: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 3 ports with 3 removable, self powered ahc0: Adaptec 2940 Ultra SCSI adapter port 0x9800-0x98ff mem 0xde3ff000-0xde3f irq 16 at device 4.0 on pci2 ahc0: [GIANT-LOCKED] aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs fwohci0: Texas Instruments TSB43AB22/A mem 0xde3fc800-0xde3fcfff,0xde3f8000-0xde3fbfff irq 18 at device 6.0 on pci2 fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:00:00:00:00:00:f0:12 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link
Re: pitiful performance of an SATA150 drive
Mikhail Teterin wrote: On Monday 26 March 2007 15:21, Søren Schmidt wrote: = What HW was this again, there has been alot of updates/changes over the = last year ? It is now a quad core (dual CPU) Opteron-275 using IWill's DK8X motherboard. http://www.google.com/search?q=iwill+dk8x The SATA controller(s) are by LSI, not NVidia's (unlike in Jeremy's case). Nopes its the stock AMD and a SiI chip.. Anyhow there has been some changes in that area that actually might fix an interrupt routing bogon. Please try the attached patch against an up to date 6-stable source and let me know if that helps... -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: installation issue 6.2 AMD64-bit 3ware 9550SX
adam radford wrote: Jon, This issue should be fixed in the FreeBSD 6.X driver on the 3ware web-site (9.4.1 codeset). We need to send a kernel patch to update the in-kernel 6.X driver to the latest version. I submitted kern/106488 back in December when the first 9650SE compatible driver was posted. I just tried to submit a followup with a patch to the new driver. (I may not have submitted it right, though.) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pitiful performance of an SATA150 drive
On Monday 26 March 2007 17:35, Søren Schmidt wrote: = Nopes its the stock AMD and a SiI chip.. Yes, that's correct. Sorry for the confusion. = Anyhow there has been some changes in that area that actually might fix = an interrupt routing bogon. Please try the attached patch against an up = to date 6-stable source and let me know if that helps... Ok, I'm certainly seeing improvement. The amount of ehci interrupts is down to hundreds (although still very high, considering, there is not USB activity). The disk's write throughput increased a little from 7.5Mb/s, and even spikes to 10Mb/s occasionally now, while averaging at about 8.3Mb/s. Curiously, the bandwidth appears BETTER (9Mb/s), when boinc (setiathome) IS RUNNING on all four cores... I'm running a compressed dump now to see, if the data corruption is still here. That said, it still sucks... The drive can read at the healthy 60Mb/s (and higher) -- I'd expect writing to average at least 20Mb/s, when recording a single stream. BTW, when I just got the drive 15 months ago, reading sucked too. But it improved over the period -- not sure, with which revision... Thanks! -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gmirror Issues
Joe Kelsey wrote: I am having a real hard time with gmirror. I recently bought two new 400G SATA disks and I want to mirror them. I think I am following the directions, but I am not sure. I generally do the following steps: edit /boot/loader.conf to add geom_mirror_load. reboot into single-user gmirror label -v -b round-robin gm0 ad4s1 ad6s1 bsdlabel -w mirror/gm0 bsdlabel -e mirror/gm0 newfs mirror/gm0a When I attempt to perform the newfs, it generally goes through all of the backup super blocks and hangs the system at the end of the newfs. At that point, my only recourse is pushing the reset button. When the system comes up, GEOM_MIRROR tries to rebuild one of the providers (usually ad4s1), but never seems to succeed. Anyway, the first problem I had was not having geom_mirror loaded. The only solution seems to be adding the load to /boot/loader.conf. None of the manual pages or handbook pages says anything about this except when discusssing making your system disk mirrored. I am not doing that. So, after loading the mirror stuff, I regularly lock up the system by trying to perform simple activities on the mirror. What do I need to do differently? Here are the relevant dmesg lines: atapci0: SiI 3512 SATA150 controller port 0xa000-0xa007,0x9800-0x9803,0x9400-0x9407,0x9000-0x9003,0x8800-0x880f mem 0xfba0-0xfba001ff irq 18 at device 13.0 on pci0 ata2: ATA channel 0 on atapci0 ata3: ATA channel 1 on atapci0 ad4: 381554MB Seagate ST3400620AS 3.AAC at ata2-master SATA150 ad6: 381554MB Seagate ST3400620AS 3.AAC at ata3-master SATA150 OK. I did some more testing and found a bug in the SII3512 controller. If I mount just one of the drives just as a single disk and attempt to move a 250G drive over using tar, sometime during the copying the system simply hangs. No errors, no messages, the system stops and my only recourse is jto press the reset button. For that reason, I have decided that the SII3512 is unreliable and will replace it with a Promise controller, basically the cheapest one (TX2). I hope it works better. Thank you everyone for the links to other pages. /Joe ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pitiful performance of an SATA150 drive
On Monday 26 March 2007 18:38, Mikhail Teterin wrote: = I'm running a compressed dump now to see, if the data corruption is still = here. Yes, it is still here. Although the dump/compression finished cleanly, the result is broken: # gzip -t /store/home.0.gz gzip: data stream error gzip: /store/home.0.gz: uncompress failed Yours, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gmirror Issues
On Mon, Mar 26, 2007 at 04:44:05PM -0700, Joe Kelsey wrote: For that reason, I have decided that the SII3512 is unreliable and will replace it with a Promise controller, basically the cheapest one (TX2). I hope it works better. I've been using cheap Promise controllers for years, more recently with gmirror / gstripe. They work fine. -- Adrian Wontroba ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
kern/94669
Any update on kern/94669? Thanks, Jason ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
