Re: suggestions for SATA RAID cards
Jo Rhett wrote: On Sep 7, 2006, at 2:23 PM, Steven Hartland wrote: I did have a little bother getting through to the dev's for support with a disk compatibility issue but once I located the right person highpoint support was very good. How did you locate them? Highpoint support told us that a third party did the freebsd driver and that they had no intention of supporting it. Just going through their support email. I believe Scott did the original FreeBSD 1820a port but they where more than helpful in fixing the issue I had which was a quite nasty compat issue with seagate 400GB disks. FYI, several people have claimed that the 1820a is hardware -- this is untrue. It's hardware accelerated, but all of the raid logic is in the driver. It's sludgeware, not hardware raid. Performance tests against a real hardware raid adapter will demonstrate what I mean. I believe you are wrong here and my own performance tests here backs this up, showing it keeps up with the more expensive areca in a number of areas notably, providing 180MB/s in sequential read tests from a 5 disk array. Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
reenable tagged queueing of VMware virtual disk.
Hi,
Tagged queueing feature of a VMware virtual disk connected with SCSI
has been disabled since the cam quirk was added.
# this quirk is needed to find the drive by SCSI HA.
I modified this quirk to allow tagged queueing while finding out causes
of low disk performance.
This modification improve the throughput of the disk I/O on VMware ESX
Server 3, at least. (4MBps - 18Mbps, by some easy measurements using dd).
I think following modification to be applicable to RELENG_[456] and MAIN.
I applied this patch to my RELENG_5 (virtual) box and do 'make -j4
buildworld' now and at present, the problem has not occurred.
--- sys/cam/cam_xpt.c.orig Fri Sep 8 18:10:14 2006
+++ sys/cam/cam_xpt.c Fri Sep 8 17:43:57 2006
@@ -359,7 +359,7 @@
{
/* Does not support other than LUN 0 */
{ T_DIRECT, SIP_MEDIA_FIXED, VMware*, *, * },
- CAM_QUIRK_NOLUNS, /*mintags*/0, /*maxtags*/0
+ CAM_QUIRK_NOLUNS, /*mintags*/2, /*maxtags*/255
},
thank you.
--
Shunsuke SHINOMIYA [EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
bpf issue with sis driver
hi all, The problem is the following: Using tcpdump -i sis0, whatever other arguments, I am loosing more or less (UDP) packets depending on the bitrate when starting AND stopping tcpdump. At least at the application level as reported by my client program. No such problem with the rl driver, not tested on others yet but that is possible if needed. I am using FreeBSD 6.1-STABLE #0: Thu Sep 7 13:06:10 CEST 2006 but it was the same with a 6.1RC. from dmesg: sis0: NatSemi DP8381[56] 10/100BaseTX port 0xbc00-0xbcff mem 0xdfffe000-0xdfffefff irq 7 at device 15.0 on pci0 sis0: Silicon Revision: DP83815D Please let me know if I can help with some other test/info. Regards, Roman. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Where is the maximum of hw.ath.txbuf and rxbuf ? (former: atheros driver under high load, panics and even more freezes)
Hi Sam, thank you for your answer. I think it is connected to this problem somehow, but not fully. I increased txbuf and rxbuf twice to 200 and 80, I saw some betterment in less of no buffers space ..., but latency went up to 2000 ms. Now I ended at txbuf=800 and rxbuf=320 on both sides R1 and R2. But still, there is the same problem: It was tested after the rebooting R2 almost at once. --- R1 ping statistics --- 1 packets transmitted, 8752 packets received, 12% packet loss round-trip min/avg/max/stddev = 1.324/920.480/6323.454/766.399 ms up to 6k ms R2# athstats -i ath0 11309 data frames received 11384 data frames transmit 12508 long on-chip tx retries 769 tx failed 'cuz too many retries 24M current transmit rate 2 tx management frames 6 tx frames discarded prior to association 31 tx stopped 'cuz no xmit buffer 38 tx frames with no ack marked 3 rx failed 'cuz of bad CRC 4464 rx failed 'cuz of PHY err 4464 OFDM timing 24 periodic calibrations 27 rssi of last ack 27 avg recv rssi -96 rx noise floor 1 switched default/rx antenna Antenna profile: [1] tx10614 rx11449 Where is the maximum of txbuf and rxbuf ? I would like to test it. Thank you for your attention. Daniel -Original Message- From: Sam Leffler [mailto:[EMAIL PROTECTED] Sent: Friday, September 08, 2006 6:30 AM To: [EMAIL PROTECTED] Cc: freebsd-stable@freebsd.org Subject: Re: atheros driver under high load, panics and even more freezes Daniel Dvoøák wrote: Hi Sam and all, I am not sure if I understand your answer, but I try it. When I use start my test, athstats shows this: athstats -i ath0 19308912 data frames received 15723536 data frames transmit 6536 tx frames with an alternate rate 2188280 long on-chip tx retries 62583 tx failed 'cuz too many retries 348 tx linearized to cluster 24M current transmit rate 6 tx management frames 6 tx frames discarded prior to association 27129 tx stopped 'cuz no xmit buffer 23057 tx frames with no ack marked 1182 rx failed 'cuz of bad CRC 761604 rx failed 'cuz of PHY err 761604 OFDM timing 4829 periodic calibrations 28 rssi of last ack 27 avg recv rssi -96 rx noise floor 1 switched default/rx antenna Antenna profile: [1] tx 15660942 rx 19451935 [2] tx2 rx0 ... I use this ping command from R2: ping -i .002 -c 1 -s 1472 opposite side R1 --- R1 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.316/1.442/49.391/1.757 ms You can see nice average latency about 1,4 ms and no one packet was lost. athstats almost wasn´t changed. 19309465 data frames received 15724079 data frames transmit 6536 tx frames with an alternate rate 2188281 long on-chip tx retries 62583 tx failed 'cuz too many retries 348 tx linearized to cluster 24M current transmit rate 6 tx management frames 6 tx frames discarded prior to association 27129 tx stopped 'cuz no xmit buffer 23075 tx frames with no ack marked 1182 rx failed 'cuz of bad CRC 761605 rx failed 'cuz of PHY err 761605 OFDM timing 4834 periodic calibrations 29 rssi of last ack 27 avg recv rssi -96 rx noise floor 1 switched default/rx antenna Antenna profile: [1] tx 15661485 rx 19452488 [2] tx2 rx0 For compare with flood ping at once: --- R1 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.319/1.516/5.594/0.120 ms Almost the same, yes max is even better. -- -- -- If I use interval 1/1000 s to send the echo request, the situation is rapidly changed. ping -i .001 -c 1 -s 1472 opposite side R1 --- R1 ping statistics --- 1 packets transmitted, 9681 packets received, 3% packet loss round-trip min/avg/max/stddev = 1.319/335.806/564.946/170.691 ms R2# ifconfig -v ath0 ath0: flags=8c43UP,BROADCAST,RUNNING,OACTIVE,SIMPLEX,MULTICAST mtu 1500 -- ??? OACTIVE FLAG ? inet6 fe80::20b:6bff:fe2a:c78e%ath0 prefixlen 64 scopeid 0x2 inet 10.XX.YY.ZZ netmask 0xfffc broadcast 10.40.64.19 ether media: IEEE 802.11 Wireless Ethernet OFDM/24Mbps mode 11a flag0,adhoc (OFDM/24Mbps) status: associated 19350739 data frames received 15765446 data frames transmit 6536 tx frames with an alternate rate 2194842 long on-chip tx retries 62590 tx failed 'cuz too many retries 348 tx linearized to cluster 24M current transmit rate 6 tx management frames 6 tx frames discarded prior to association 29242 tx stopped 'cuz no xmit buffer 23155 tx frames with no ack marked 1182 rx failed 'cuz of bad CRC 764641 rx failed 'cuz of PHY err 764641 OFDM timing
Re: Patch for GBDE rc-script
On Thu, Sep 07, 2006 at 08:13:11PM +0200, Daniel Bond wrote: Hi, I just setup GBDE on my laptop, encrypting my 512M cf-card. This works like a charm, but I felt the need to enchance the rc-script a little to automatically mount the encrypted drive(s), if you have the following in /etc/rc.conf: [snip] How is this better/different from just adding the gbde device to /etc/fstab and have it mounted along with all other filesystems? Thanks, Tobias ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Polar IR-USB: setting configuration index 0 failed
[this has been sent to freebsd-usb before, sorry if you see it twice but maybe someone on this list can help?] I'm trying to get a Polar IR-USB interface working with FreeBSD 6.1, but it fails with the error: setting configuration index 0 failed I enabled USB_DEBUG and added some more printf statements to see what's going on. The (annotated) output looks like this: ! When the IR interface is plugged it it properly shows up: ugen0: vendor 0x413c product 0x8000, rev 2.00/12.66, addr 2 ! vendor DELL 0x413c Dell usbd_get_string: getting lang failed, using 0 ugen1: vendor 0x0da4 product 0x0001, rev 1.00/1.19, addr 2 ! This is the Polar IR interface. However, the next message is: ugen1: setting configuration index 0 failed ! Turning debugging on and starting at the recognition of the interface: ugen1: vendor 0x0da4 product 0x0001, rev 1.00/1.19, addr 3 usbd_set_config_index: dev=0xc52cdc00 index=0 usbd_set_config_index: free old config usbd_get_config_desc: confidx=0 usbd_get_desc: type=2, index=0, len=9 usbd_alloc_xfer() = 0xc4b97800 usbd_transfer: xfer=0xc4b97800, flags=2, pipe=0xc52e3800, running=0 usbd_dump_queue: pipe=0xc52e3800 usb_allocmem: use frag=0xc4bd4d00 size=9 usb_insert_transfer: pipe=0xc52e3800 running=0 timeout=5000 usb_event_thread: woke up usb_discover usb_add_task: task=0xc4b97888 usb_task_thread: woke up task=0xc4b97888 usb_transfer_complete: pipe=0xc52e3800 xfer=0xc4b97800 status=15 actlen=0 ! This seems to be a timeout error; ! usbdi.h:USBD_TIMEOUT, /* 15 */ usb_freemem: frag=0xc4bd4d00 usb_transfer_complete: repeat=0 new head=0 usbd_start_next: pipe=0xc52e3800, xfer=0 usbd_free_xfer: 0xc4b97800 ! and here's the erorr again: usbd_set_config_index: dev=0xc52cdc00, usbd_get_config_desc=15 ugen1: setting configuration index 0 failed device_attach: ugen1 attach returned 6 The software that is used to read data (http://daveb.net/s710/) uses libusb. It works under some Linux version (e.g., SuSE 9.3 but not 10.1). Is there some way to get this working under FreeBSD too? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: suggestions for SATA RAID cards
Jo Rhett wrote: FYI, several people have claimed that the 1820a is hardware -- this is untrue. It's hardware accelerated, but all of the raid logic is in the driver. It's sludgeware, not hardware raid. Performance tests against a real hardware raid adapter will demonstrate what I mean. On Fri, Sep 08, 2006 at 06:16:09AM +0100, Steven Hartland wrote: I believe you are wrong here and my own performance tests here backs this up, showing it keeps up with the more expensive areca in a number of areas notably, providing 180MB/s in sequential read tests from a 5 disk array. It seems clear you don't understand the difference between driver-based raid support and hardware-based raid. Unless you just forgot to mention the CPU load level you had artificially added prior to starting this test... -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em watchdog timeout on UP, 6-stable
Barney, On Tue, Sep 05, 2006 at 02:33:52PM -0400, Barney Wolff wrote: B Updated my Athlon-xp 6-stable system last night, got an em watchdog B timeout for the first time a few hours later, during a fairly B high-traffic period. System is UP but does have device apic in B the config. Any chance this is the recent race condition? B Workaround? ifconfig em0 down, ifconfig em0 up seemed to cure it, B at least for the moment. Not clear from your mail whether interface was working after the event occured. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Several issues on Dell 1950/2950 servers (6-STABLE and 7-CURRENT)
I've update to the latest 7-CURRENT (last night, 10pm CST) and now the previous error message mpt0: Unhandled Event Notify Frame. Event 0xe (ACK not required). (http://www.bsd.org.mx/~alex/logs/messages.CURRENT.0902) is gone, but a new error message appears as often as the former, and under the same circumstances: mpt0: QUEUE_FULL: Bus 0x00 Target 0x00 Depth 128 Probe errors are still there, but, as I said before, they do not delay the boot process as in 6-STABLE (probe0:mpt0:0:n:n): error 22 (probe0:mpt0:0:n:n): Unretryable Error /var/run/dmesg.boot (verbose) http://www.bsd.org.mx/~alex/logs/dmesg.boot.CURRENT.0907 /var/log/messages http://www.bsd.org.mx/~alex/logs/messages.CURRENT.0907 -- Alex ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
openldap/pam/nss issues on 6.1
I've tried to search for these answers, so I apologize if I've missed them in previous posts in various lists: I'm setting up FreeBSD 6.1/i386 (soon amd64, I hope) for LDAP login and I've had some minor issues with it: 1) I can get it to work as a server and client but with the default startup timeout and bind hard, the slapd startup hangs for quite awhile on service startup. I've seen the suggestion to set the bind to soft and lower the timeout value and this helps, but then sshd has problems querying the ldap service and so one can't login via ssh. 2) My FreeBSD client system can authenticate to it OK, but I'd like to restrict the unencrypted connect (port 389) to be only for localhost connection and clients must connect with ssl (port 636). I've started slapd on the server with flags -h ldap://127.0.0.1/ ldaps:/// and local server logins work great but the client hangs on login and whenever commands like id or whoami are issued but the logins and command results ultimately work. I monitored the net connections with netstat and I see syn connections to the server's ldap (389) port as well as ldaps (636). I suspect that even though I set the client's /usr/local/etc/ldap.conf (and symlinked /etc/ldap.conf and nss_ldap.conf to it) file with ssl on and port 636, it still is trying 389 first. If I start the server with -h ldap:/// ldaps:/// then the 389 connections succeed and everything is fast. A linux client did not try the 389 port and was fast login in and returning results with id or whoami. On the FreeBSD client, if I do: ldapsearch -H ldaps://hostname -bdc= -LL -x (uid=testuser) this immediately gives me the result. It is something with the pam or nss that is insisting on doing the port 389 first. 3) My freebsd client sshd when configured for ldap does signal 11 crashes. My freebsd server has no problem with sshd and ldap. If I turn off ldap and use NIS on the client, it works great. Any help with these ? I can deal with the slow startup, that's relatively minor, but 2 and 3 are more problematic for me. Thanks, Dirk ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em watchdog timeout on UP, 6-stable
On Friday 08 September 2006 10:25, Gleb Smirnoff wrote: Barney, On Tue, Sep 05, 2006 at 02:33:52PM -0400, Barney Wolff wrote: B Updated my Athlon-xp 6-stable system last night, got an em watchdog B timeout for the first time a few hours later, during a fairly B high-traffic period. System is UP but does have device apic in B the config. Any chance this is the recent race condition? B Workaround? ifconfig em0 down, ifconfig em0 up seemed to cure it, B at least for the moment. Not clear from your mail whether interface was working after the event occured. In my system, you get the timeout, then the state is downed and then uped. Your transfer session is basically dead at that point. On Tuesday, Klop had an email with a copy of what you see in the message log. Kent -- Kent Stewart Richland, WA http://www.soyandina.com/ I am Andean project. http://users.owt.com/kstewart/index.html ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em watchdog timeout on UP, 6-stable
On Friday 08 September 2006 11:17, Kent Stewart wrote: On Friday 08 September 2006 10:25, Gleb Smirnoff wrote: Barney, On Tue, Sep 05, 2006 at 02:33:52PM -0400, Barney Wolff wrote: B Updated my Athlon-xp 6-stable system last night, got an em watchdog B timeout for the first time a few hours later, during a fairly B high-traffic period. System is UP but does have device apic in B the config. Any chance this is the recent race condition? B Workaround? ifconfig em0 down, ifconfig em0 up seemed to cure it, B at least for the moment. Not clear from your mail whether interface was working after the event occured. In my system, you get the timeout, then the state is downed and then uped. Your transfer session is basically dead at that point. On Tuesday, Klop had an email with a copy of what you see in the message log. Ignore part of what I said. I am getting the same errors on re0. All I have to do to force the error is ftp a GB or 2 to the destination machine using 1000baseT NICs. My host machine is XP and I use the destination machine as a backup for photos and mp3 files. A photo session is usually on the order of 1-2 GBs. Kent -- Kent Stewart Richland, WA http://www.soyandina.com/ I am Andean project. http://users.owt.com/kstewart/index.html ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
6.1-R-p6 USB related kernel panic?
Hi,
I was disconnecting my smart card reader from my USB hub, when
the kernel panicked.
Btw kernel and world have been built with ccache.
make any difference.
Here's backtrace from kgdb.
% kgdb kernel.debug vmcore.347
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol ps_pglobal_lookup]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-marcel-freebsd.
Unread portion of the kernel message buffer:
ugen0: at uhub3 port 5 (addr 4) disconnected
All threads purged from ugen0.3
All threads purged from ugen0.2
All threads purged from ugen0.1
All threads purged from ugen0
ugen0: detached
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xc4fb1674
fault code = supervisor write, page not present
instruction pointer = 0x20:0xc050e010
stack pointer = 0x28:0xe786db9c
frame pointer = 0x28:0xe786db9c
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 565 (ifdhandler)
trap number = 12
panic: page fault
Uptime: 56m45s
Dumping 1023 MB (2 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 1023MB (261872 pages) 1007 991 975 959 943 927 911 895 879 863 847
831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527
511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 (CTRL-C
to abort) 223 (CTRL-C to abort) 207 191 (CTRL-C to abort) (CTRL-C to abort)
(CTRL-C to abort) 175 159 143 127 111 95 79 63 47 31 15
#0 doadump () at pcpu.h:165
165 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) backtrace
#0 doadump () at pcpu.h:165
#1 0xc04eb025 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:402
#2 0xc04eb2bc in panic (fmt=0xc066cfb6 %s)
at /usr/src/sys/kern/kern_shutdown.c:558
#3 0xc0651410 in trap_fatal (frame=0xe786db5c, eva=3304789620)
at /usr/src/sys/i386/i386/trap.c:836
#4 0xc0651177 in trap_pfault (frame=0xe786db5c, usermode=0, eva=3304789620)
at /usr/src/sys/i386/i386/trap.c:744
#5 0xc0650dd5 in trap (frame=
{tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -985174656, tf_esi = 0,
tf_ebp = -410592356, tf_isp = -410592376, tf_ebx = 35, tf_edx = -985174656,
tf_ecx = -1066602208, tf_eax = -990177684, tf_trapno = 12, tf_err = 2, tf_eip =
-1068441584, tf_cs = 32, tf_eflags = 590470, tf_esp = -410592036, tf_ss =
-1068442298})
at /usr/src/sys/i386/i386/trap.c:434
#6 0xc0643bca in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc050e010 in clear_selinfo_list (td=0xc5476d80)
at /usr/src/sys/kern/sys_generic.c:1078
#8 0xc050dd46 in poll (td=0xc5476d80, uap=0xe786dd04)
at /usr/src/sys/kern/sys_generic.c:977
#9 0xc0651727 in syscall (frame=
{tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 134692864, tf_esi = 0,
tf_ebp = -1077946616, tf_isp = -410591900, tf_ebx = 671950004, tf_edx = 0,
tf_ecx = 134664592, tf_eax = 209, tf_trapno = 0, tf_err = 2, tf_eip =
672453131, tf_cs = 51, tf_eflags = 642, tf_esp = -1077946660, tf_ss = 59})
at /usr/src/sys/i386/i386/trap.c:981
#10 0xc0643c1f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200
#11 0x0033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb)
--
In the beginning the Universe was created. This has made a lot of
people very angry and been widely regarded as a bad move.
-- Douglas Adams 1952 - 2001
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: openldap/pam/nss issues on 6.1
Dirk Kleinhesselink wrote: this immediately gives me the result. It is something with the pam or nss that is insisting on doing the port 389 first. Have you edited the right configuration files? There are /usr/local/etc/openldap/ldap.conf, /usr/local/etc/ldap.conf and /usr/local/etc/nss_ldap.conf. I had trouble with ldaps until I provided the whole certificate chain on the client side. 3) My freebsd client sshd when configured for ldap does signal 11 crashes. My freebsd server has no problem with sshd and ldap. If I turn off ldap and use NIS on the client, it works great. Same here, but resolved after reinstalling everything. My guess is that I've done something wrong when updating openldap-client to newest version, including problems with compat libraries. Any help with these ? I can deal with the slow startup, that's relatively minor, but 2 and 3 are more problematic for me. The slow startup is really annoying. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
gmirror problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The back-out of the last set of changes to gmirror don't seem to have solved the problem .. I get .. [EMAIL PROTECTED]:/home/imb iostat 5 ~ tty da0 da1pass0 cpu ~ tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id ~ 1 130 0.23 1 0.00 99.48 220 21.35 0.02 0 0.00 27 0 14 1 58 ~ 0 46 0.00 0 0.00 125.41 686 84.07 0.00 0 0.00 2 0 6 2 90 ~ 0 16 0.00 0 0.00 127.93 708 88.42 0.00 0 0.00 1 0 6 4 89 ~ 0 16 0.00 0 0.00 127.86 709 88.55 0.00 0 0.00 5 0 5 3 87 ~ 0 16 0.00 0 0.00 127.97 710 88.70 0.00 0 0.00 1 0 9 4 86 ~ 0 16 0.00 0 0.00 127.96 707 88.35 0.00 0 0.00 1 0 7 4 88 ~ 0 16 0.00 0 0.00 127.60 705 87.83 0.00 0 0.00 1 0 6 2 91 ^C [EMAIL PROTECTED]:/home/imb sudo gmirror deactivate gm0s2 da0s2 [EMAIL PROTECTED]:/home/imb iostat 5 ~ tty da0 da1pass0 cpu ~ tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id ~ 1 104 0.24 1 0.00 113.45 336 37.18 0.02 0 0.00 21 0 12 2 65 ~ 0 46 0.00 0 0.00 127.28 710 88.24 0.00 0 0.00 1 0 6 3 90 ^C I'm going to try going further back to see where it started .. Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFAe8YQv9rrgRC1JIRAudfAJ0ZC53LQkYpqqiW4UCnWfj+WO5MmwCeJmHB ebjsc6OrPuQBG3nER25jBt0= =I0qd -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em watchdog timeout on UP, 6-stable
On Fri, Sep 08, 2006 at 09:25:43PM +0400, Gleb Smirnoff wrote: Barney, On Tue, Sep 05, 2006 at 02:33:52PM -0400, Barney Wolff wrote: B Updated my Athlon-xp 6-stable system last night, got an em watchdog B timeout for the first time a few hours later, during a fairly B high-traffic period. System is UP but does have device apic in B the config. Any chance this is the recent race condition? B Workaround? ifconfig em0 down, ifconfig em0 up seemed to cure it, B at least for the moment. Not clear from your mail whether interface was working after the event occured. In the watchdog timer case it was not. Looking further, I had several cases where nfs-over-tcp failed under heavy load, but the interface did not report failure and continued to work. The system sending nfs writes logged nfs send error 35 and gzip died with resource temporarily unavailable. (I haven't looked at the code - EAGAIN?) In the watchdog timer case the cpu was very busy with portbuilding and the system was receiving nfs writes. But the nfs failures happened in both directions (I have two systems which back up each other, at different times). Before updating from a 6/14/06 6-stable to 9/04/06, such nfs failures were unknown unless I tried to run both backups simultaneously. Systems are on a cheap netgear gb switch, other system is current but a couple of months old. After the watchdog timer, the link was unidirectional - sending worked (packets were correctly received on the other system) but receiving did not work. Then, after another 9 minutes, it seemed to stop working in either direction, until manually down/up'd hours later. I can put logs on a webserver if that would be useful. -- Barney Wolff I never met a computer I didn't like. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: suggestions for SATA RAID cards
Steven Hartland wrote: I believe you are wrong here and my own performance tests here backs this up, showing it keeps up with the more expensive areca in a number of areas notably, providing 180MB/s in sequential read tests from a 5 disk array. Steve, Just out of interest what RAID level was the 5 disk array? - as 180Mb/s from an Areca 5 disk RAID0 or RAID5 array is not that good - my old 3Ware 7506 with 4 Maxtor IDE RAID0 gets 175Mb/s. Obviously if your array is RAID10, the 180MB/s is very good! If you are using RAID0|5, then something is slowing you down (possible clash between disk firmware and the Areca, or unfortunate choice of strip chunk size). Cheers Mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Broken loader in STABLE
CFLAGS= -O2 -pipe -funroll-loops -ffast-math I had used similar optimizations soon after going from 6.1-RELEASE to 6-STABLE and discovered it was a bad idea. Using -O -pipe has since stood me in good stead. The system is by no means sluggish, even on a cut-rate build-on-a-budget machine. I experienced that tuning for FS bottlenecks has a far greater performance impact. Splitting cache across different drives can have a positive effect similar to putting /usr/src and /usr/obj on different drives. After finding out where my needs were and partitioning appropriately, I have few complaints even with minimal optimization. That also holds for NetBSD on my dodgy old ACPI plus early AGP box that causes FreeBSD to panic unless I yank the s3 Trio for a couple of older cards and disable ACPI (1997 Microstar EISA/PCI/AGP K6 transitional hardware). Even when I just slap on an extra 2 gig drive for cache and /usr/obj, Net runs noticeably faster. Charles ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
