em0 watchdog timeouts on 8-STABLE
I recently updated my server to the latest 8-STABLE, and upgraded to v28 ZFS. I have not had these problems on any other version of 8-STABLE or 7-STABLE, which this box was upgraded from some time ago. Now, during my weekly scrub, I get the following messages and em0 is unresponsive: Jun 12 03:07:58 foghornleghorn kernel: em0: Watchdog timeout -- resetting Jun 12 03:07:58 foghornleghorn kernel: em0: link state changed to DOWN Jun 12 03:08:01 foghornleghorn kernel: em0: link state changed to UP Jun 12 03:08:47 foghornleghorn kernel: em0: Watchdog timeout -- resetting Jun 12 03:08:47 foghornleghorn kernel: em0: link state changed to DOWN Jun 12 03:08:50 foghornleghorn kernel: em0: link state changed to UP My scrub is scheduled to start at 03:00:00, so it looks like watchdog timeouts start occurring pretty quickly once I/O ramps up. Here's some possibly relevant information, let me know if anything else would be helpful to troubleshoot. FreeBSD foghornleghorn.res.openband.net 8.2-STABLE FreeBSD 8.2-STABLE #17: Mon Jun 6 19:40:19 EDT 2011 r...@foghornleghorn.res.openband.net:/usr/obj/usr/src/sys/FOGHORNLEGHORN amd64 em0: port 0xe800-0xe83f mem 0xfebe-0xfebf,0xfebc-0xfebd irq 20 at device 5.0 on pci7 em0@pci0:7:5:0: class=0x02 card=0x13768086 chip=0x107c8086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)' class = network subclass = ethernet And, the SAS cards: dev.mpt.0.%desc: LSILogic SAS/SATA Adapter dev.mpt.0.%driver: mpt dev.mpt.0.%location: slot=0 function=0 dev.mpt.0.%pnpinfo: vendor=0x1000 device=0x0058 subvendor=0x15d9 subdevice=0xa580 class=0x01 dev.mpt.0.%parent: pci1 dev.mpt.0.debug: 3 dev.mpt.0.role: 1 dev.mpt.1.%desc: LSILogic SAS/SATA Adapter dev.mpt.1.%driver: mpt dev.mpt.1.%location: slot=0 function=0 dev.mpt.1.%pnpinfo: vendor=0x1000 device=0x0058 subvendor=0x15d9 subdevice=0xa580 class=0x01 dev.mpt.1.%parent: pci2 dev.mpt.1.debug: 3 dev.mpt.1.role: 1 dev.mpt.2.%desc: LSILogic SAS/SATA Adapter dev.mpt.2.%driver: mpt dev.mpt.2.%location: slot=0 function=0 dev.mpt.2.%pnpinfo: vendor=0x1000 device=0x0058 subvendor=0x1000 subdevice=0x30a0 class=0x01 dev.mpt.2.%parent: pci6 dev.mpt.2.debug: 3 dev.mpt.2.role: 1 -- Joshua Boyd JBipNet E-mail: boy...@jbip.net Cell: (513) 375-0157 http://www.jbip.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: em0 watchdog timeouts on 8-STABLE
On Wed, Jun 15, 2011 at 3:57 AM, Jeremy Chadwick wrote: > On Wed, Jun 15, 2011 at 03:14:43AM -0400, Joshua Boyd wrote: > > I recently updated my server to the latest 8-STABLE, and upgraded to v28 > > ZFS. I have not had these problems on any other version of 8-STABLE or > > 7-STABLE, which this box was upgraded from some time ago. > > > > Now, during my weekly scrub, I get the following messages and em0 is > > unresponsive: > > > > Jun 12 03:07:58 foghornleghorn kernel: em0: Watchdog timeout -- resetting > > Jun 12 03:07:58 foghornleghorn kernel: em0: link state changed to DOWN > > Jun 12 03:08:01 foghornleghorn kernel: em0: link state changed to UP > > Jun 12 03:08:47 foghornleghorn kernel: em0: Watchdog timeout -- resetting > > Jun 12 03:08:47 foghornleghorn kernel: em0: link state changed to DOWN > > Jun 12 03:08:50 foghornleghorn kernel: em0: link state changed to UP > > > > My scrub is scheduled to start at 03:00:00, so it looks like watchdog > > timeouts start occurring pretty quickly once I/O ramps up. > > > > Here's some possibly relevant information, let me know if anything else > > would be helpful to troubleshoot. > > > > FreeBSD foghornleghorn.res.openband.net 8.2-STABLE FreeBSD 8.2-STABLE > #17: > > Mon Jun 6 19:40:19 EDT 2011 > > r...@foghornleghorn.res.openband.net:/usr/obj/usr/src/sys/FOGHORNLEGHORN > > amd64 > > > > em0: port > 0xe800-0xe83f > > mem 0xfebe-0xfebf,0xfebc-0xfebd irq 20 at device 5.0 on > pci7 > > > > em0@pci0:7:5:0: class=0x02 card=0x13768086 chip=0x107c8086 rev=0x05 > > hdr=0x00 > > vendor = 'Intel Corporation' > > device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)' > > class = network > > subclass = ethernet > > > > And, the SAS cards: > > > > dev.mpt.0.%desc: LSILogic SAS/SATA Adapter > > dev.mpt.0.%driver: mpt > > dev.mpt.0.%location: slot=0 function=0 > > dev.mpt.0.%pnpinfo: vendor=0x1000 device=0x0058 subvendor=0x15d9 > > subdevice=0xa580 class=0x01 > > dev.mpt.0.%parent: pci1 > > dev.mpt.0.debug: 3 > > dev.mpt.0.role: 1 > > dev.mpt.1.%desc: LSILogic SAS/SATA Adapter > > dev.mpt.1.%driver: mpt > > dev.mpt.1.%location: slot=0 function=0 > > dev.mpt.1.%pnpinfo: vendor=0x1000 device=0x0058 subvendor=0x15d9 > > subdevice=0xa580 class=0x01 > > dev.mpt.1.%parent: pci2 > > dev.mpt.1.debug: 3 > > dev.mpt.1.role: 1 > > dev.mpt.2.%desc: LSILogic SAS/SATA Adapter > > dev.mpt.2.%driver: mpt > > dev.mpt.2.%location: slot=0 function=0 > > dev.mpt.2.%pnpinfo: vendor=0x1000 device=0x0058 subvendor=0x1000 > > subdevice=0x30a0 class=0x01 > > dev.mpt.2.%parent: pci6 > > dev.mpt.2.debug: 3 > > dev.mpt.2.role: 1 > > Please provide output from the following commands (as root): > > # pciconf -lvcb > hostb0@pci0:0:0:0: class=0x06 card=0x59561002 chip=0x59561002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'RD790 GFX Dual Slot' class = bridge subclass = HOST-PCI pcib1@pci0:0:2:0: class=0x060400 card=0x59561002 chip=0x59781002 rev=0x00 hdr=0x01 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'RD790 PCI to PCI bridge (external gfx0 port A)' class = bridge subclass = PCI-PCI pcib2@pci0:0:3:0: class=0x060400 card=0x59561002 chip=0x59791002 rev=0x00 hdr=0x01 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'RD790 PCI to PCI bridge (external gfx0 port B)' class = bridge subclass = PCI-PCI pcib3@pci0:0:4:0: class=0x060400 card=0x59561002 chip=0x597a1002 rev=0x00 hdr=0x01 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'RD790 PCI to PCI bridge (PCIe gpp port A)' class = bridge subclass = PCI-PCI pcib4@pci0:0:6:0: class=0x060400 card=0x59561002 chip=0x597c1002 rev=0x00 hdr=0x01 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'RD790 PCI to PCI bridge (PCIe gpp port C)' class = bridge subclass = PCI-PCI pcib5@pci0:0:7:0: class=0x060400 card=0x59561002 chip=0x597d1002 rev=0x00 hdr=0x01 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'RD790 PCI to PCI bridge (PCIe gpp port D)' class = bridge subclass = PCI-PCI pcib6@pci0:0:11:0: class=0x060400 card=0x59561002 chip=0x59801002 rev=0x00 hdr=0x01 vendor = 'ATI Technologies Inc. / Ad
Re: em0 watchdog timeouts on 8-STABLE
In the kernel. Here's my kernel configuration: http://pastebin.com/raw.php?i=4JL814m3 On Wed, Jun 15, 2011 at 8:20 PM, Jack Vogel wrote: > I have hardware now, am working on reproducing this. Just curious, do you > have > the em driver defined in the kernel, or as a module? > > Jack > > > On Wed, Jun 15, 2011 at 2:09 AM, Joshua Boyd wrote: > >> On Wed, Jun 15, 2011 at 3:57 AM, Jeremy Chadwick >> wrote: >> >> > On Wed, Jun 15, 2011 at 03:14:43AM -0400, Joshua Boyd wrote: >> > > I recently updated my server to the latest 8-STABLE, and upgraded to >> v28 >> > > ZFS. I have not had these problems on any other version of 8-STABLE or >> > > 7-STABLE, which this box was upgraded from some time ago. >> > > >> > > Now, during my weekly scrub, I get the following messages and em0 is >> > > unresponsive: >> > > >> > > Jun 12 03:07:58 foghornleghorn kernel: em0: Watchdog timeout -- >> resetting >> > > Jun 12 03:07:58 foghornleghorn kernel: em0: link state changed to DOWN >> > > Jun 12 03:08:01 foghornleghorn kernel: em0: link state changed to UP >> > > Jun 12 03:08:47 foghornleghorn kernel: em0: Watchdog timeout -- >> resetting >> > > Jun 12 03:08:47 foghornleghorn kernel: em0: link state changed to DOWN >> > > Jun 12 03:08:50 foghornleghorn kernel: em0: link state changed to UP >> > > >> > > My scrub is scheduled to start at 03:00:00, so it looks like watchdog >> > > timeouts start occurring pretty quickly once I/O ramps up. >> > > >> > > Here's some possibly relevant information, let me know if anything >> else >> > > would be helpful to troubleshoot. >> > > >> > > FreeBSD foghornleghorn.res.openband.net 8.2-STABLE FreeBSD 8.2-STABLE >> > #17: >> > > Mon Jun 6 19:40:19 EDT 2011 >> > > r...@foghornleghorn.res.openband.net: >> /usr/obj/usr/src/sys/FOGHORNLEGHORN >> > > amd64 >> > > >> > > em0: port >> > 0xe800-0xe83f >> > > mem 0xfebe-0xfebf,0xfebc-0xfebd irq 20 at device 5.0 >> on >> > pci7 >> > > >> > > em0@pci0:7:5:0: class=0x02 card=0x13768086 chip=0x107c8086 >> rev=0x05 >> > > hdr=0x00 >> > > vendor = 'Intel Corporation' >> > > device = 'Gigabit Ethernet Controller (Copper) rev 5 >> (82541PI)' >> > > class = network >> > > subclass = ethernet >> > > >> > > And, the SAS cards: >> > > >> > > dev.mpt.0.%desc: LSILogic SAS/SATA Adapter >> > > dev.mpt.0.%driver: mpt >> > > dev.mpt.0.%location: slot=0 function=0 >> > > dev.mpt.0.%pnpinfo: vendor=0x1000 device=0x0058 subvendor=0x15d9 >> > > subdevice=0xa580 class=0x01 >> > > dev.mpt.0.%parent: pci1 >> > > dev.mpt.0.debug: 3 >> > > dev.mpt.0.role: 1 >> > > dev.mpt.1.%desc: LSILogic SAS/SATA Adapter >> > > dev.mpt.1.%driver: mpt >> > > dev.mpt.1.%location: slot=0 function=0 >> > > dev.mpt.1.%pnpinfo: vendor=0x1000 device=0x0058 subvendor=0x15d9 >> > > subdevice=0xa580 class=0x01 >> > > dev.mpt.1.%parent: pci2 >> > > dev.mpt.1.debug: 3 >> > > dev.mpt.1.role: 1 >> > > dev.mpt.2.%desc: LSILogic SAS/SATA Adapter >> > > dev.mpt.2.%driver: mpt >> > > dev.mpt.2.%location: slot=0 function=0 >> > > dev.mpt.2.%pnpinfo: vendor=0x1000 device=0x0058 subvendor=0x1000 >> > > subdevice=0x30a0 class=0x01 >> > > dev.mpt.2.%parent: pci6 >> > > dev.mpt.2.debug: 3 >> > > dev.mpt.2.role: 1 >> > >> > Please provide output from the following commands (as root): >> > >> > # pciconf -lvcb >> > >> >> hostb0@pci0:0:0:0: class=0x06 card=0x59561002 chip=0x59561002 >> rev=0x00 >> hdr=0x00 >>vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>device = 'RD790 GFX Dual Slot' >>class = bridge >>subclass = HOST-PCI >> pcib1@pci0:0:2:0: class=0x060400 card=0x59561002 chip=0x59781002 rev=0x00 >> hdr=0x01 >>vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>device = 'RD790 PCI to PCI bridge (external gfx0 port A)' >>class = bridge >>subclass = PCI-PCI >> pcib2@pci0:0:3:0: class=0x060400 card=0x5956100
Re: em0 watchdog timeouts on 8-STABLE
If needed, I can reproduce this on demand. Just need to know what sort of statistics are needed when the problem is occurring. I've had to turn off my weekly scrubs until I can figure out how to fix this problem. On Wed, Jun 15, 2011 at 8:37 PM, Joshua Boyd wrote: > In the kernel. Here's my kernel configuration: > > http://pastebin.com/raw.php?i=4JL814m3 > > On Wed, Jun 15, 2011 at 8:20 PM, Jack Vogel wrote: > >> I have hardware now, am working on reproducing this. Just curious, do you >> have >> the em driver defined in the kernel, or as a module? >> >> Jack >> >> >> On Wed, Jun 15, 2011 at 2:09 AM, Joshua Boyd wrote: >> >>> On Wed, Jun 15, 2011 at 3:57 AM, Jeremy Chadwick >>> wrote: >>> >>> > On Wed, Jun 15, 2011 at 03:14:43AM -0400, Joshua Boyd wrote: >>> > > I recently updated my server to the latest 8-STABLE, and upgraded to >>> v28 >>> > > ZFS. I have not had these problems on any other version of 8-STABLE >>> or >>> > > 7-STABLE, which this box was upgraded from some time ago. >>> > > >>> > > Now, during my weekly scrub, I get the following messages and em0 is >>> > > unresponsive: >>> > > >>> > > Jun 12 03:07:58 foghornleghorn kernel: em0: Watchdog timeout -- >>> resetting >>> > > Jun 12 03:07:58 foghornleghorn kernel: em0: link state changed to >>> DOWN >>> > > Jun 12 03:08:01 foghornleghorn kernel: em0: link state changed to UP >>> > > Jun 12 03:08:47 foghornleghorn kernel: em0: Watchdog timeout -- >>> resetting >>> > > Jun 12 03:08:47 foghornleghorn kernel: em0: link state changed to >>> DOWN >>> > > Jun 12 03:08:50 foghornleghorn kernel: em0: link state changed to UP >>> > > >>> > > My scrub is scheduled to start at 03:00:00, so it looks like watchdog >>> > > timeouts start occurring pretty quickly once I/O ramps up. >>> > > >>> > > Here's some possibly relevant information, let me know if anything >>> else >>> > > would be helpful to troubleshoot. >>> > > >>> > > FreeBSD foghornleghorn.res.openband.net 8.2-STABLE FreeBSD >>> 8.2-STABLE >>> > #17: >>> > > Mon Jun 6 19:40:19 EDT 2011 >>> > > r...@foghornleghorn.res.openband.net: >>> /usr/obj/usr/src/sys/FOGHORNLEGHORN >>> > > amd64 >>> > > >>> > > em0: port >>> > 0xe800-0xe83f >>> > > mem 0xfebe-0xfebf,0xfebc-0xfebd irq 20 at device 5.0 >>> on >>> > pci7 >>> > > >>> > > em0@pci0:7:5:0: class=0x02 card=0x13768086 chip=0x107c8086 >>> rev=0x05 >>> > > hdr=0x00 >>> > > vendor = 'Intel Corporation' >>> > > device = 'Gigabit Ethernet Controller (Copper) rev 5 >>> (82541PI)' >>> > > class = network >>> > > subclass = ethernet >>> > > >>> > > And, the SAS cards: >>> > > >>> > > dev.mpt.0.%desc: LSILogic SAS/SATA Adapter >>> > > dev.mpt.0.%driver: mpt >>> > > dev.mpt.0.%location: slot=0 function=0 >>> > > dev.mpt.0.%pnpinfo: vendor=0x1000 device=0x0058 subvendor=0x15d9 >>> > > subdevice=0xa580 class=0x01 >>> > > dev.mpt.0.%parent: pci1 >>> > > dev.mpt.0.debug: 3 >>> > > dev.mpt.0.role: 1 >>> > > dev.mpt.1.%desc: LSILogic SAS/SATA Adapter >>> > > dev.mpt.1.%driver: mpt >>> > > dev.mpt.1.%location: slot=0 function=0 >>> > > dev.mpt.1.%pnpinfo: vendor=0x1000 device=0x0058 subvendor=0x15d9 >>> > > subdevice=0xa580 class=0x01 >>> > > dev.mpt.1.%parent: pci2 >>> > > dev.mpt.1.debug: 3 >>> > > dev.mpt.1.role: 1 >>> > > dev.mpt.2.%desc: LSILogic SAS/SATA Adapter >>> > > dev.mpt.2.%driver: mpt >>> > > dev.mpt.2.%location: slot=0 function=0 >>> > > dev.mpt.2.%pnpinfo: vendor=0x1000 device=0x0058 subvendor=0x1000 >>> > > subdevice=0x30a0 class=0x01 >>> > > dev.mpt.2.%parent: pci6 >>> > > dev.mpt.2.debug: 3 >>> > > dev.mpt.2.role: 1 >>> > >>> > Please provide output from the following commands (as root): >>> > >>> > # pciconf -lvcb >>> > >>> >
Re: Dell PowerEdge 1950: MPT0 doesn't recogniz hard drive > 2TB
2011/6/29 O. Hartmann > Questions: > a) Is this an issue of FreeBSD 8.2-STABLE or is it a firmware/BIOS issue > which can be solved? > Hi Oliver, Neither, unfortunately. The 1068E based cards do not support drives over 2TB. See here: http://kb.lsi.com/KnowledgebaseArticle16399.aspx -- Joshua Boyd E-mail: boy...@jbip.net http://www.jbip.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Dell PowerEdge 1950: MPT0 doesn't recogniz hard drive > 2TB
2011/6/30 O. Hartmann > It's a pitty. > Indeed, it is. I have 3 1068s for 45 bays, I'm gonna have to buy new cards :(. -- Joshua Boyd E-mail: boy...@jbip.net http://www.jbip.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 9.0-BETA3 Available...
On Tue, Oct 4, 2011 at 4:56 PM, Arnaud Lacombe wrote: > Had you loved so much to have this information, you would have given > me credential. > > I may have filled in all the date from publicly available material, > might it be from mailing list, or from FTP server's timestamp, or SVN > revision date. If I had not been able to determine a date, I may just > have left it blank and asked for details, eventually. > > Unfortunately, we will never know. > It's nice that you want to help, but could you be less of a jerk about it to the people who devote a huge amount of time to the project? -- Joshua Boyd E-mail: boy...@jbip.net http://www.jbip.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: em0 watchdog timeout
On Thu, Nov 10, 2011 at 6:51 AM, Willem Jan Withagen wrote: > em0@pci0:0:25:0:class=0x02 card=0x10bd15d9 chip=0x10bd8086 > rev=0x02 hdr=0x00 >vendor = 'Intel Corporation' >device = 'Intel 82566DM Gigabit Ethernet Adapter (82566DM)' >class = network >subclass = ethernet >bar [10] = type Memory, range 32, base 0xdf90, size 131072, > enabled >bar [14] = type Memory, range 32, base 0xdf924000, size 4096, enabled >bar [18] = type I/O Port, range 32, base 0x1820, size 32, enabled >cap 01[c8] = powerspec 2 supports D0 D3 current D0 >cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message >cap 13[e0] = PCI Advanced Features: FLR TP > > > And note that this problem only raises it nasty head very few weeks... I have had the same problem, as shown here: http://lists.freebsd.org/pipermail/freebsd-stable/2011-June/063092.html According to your pciconf output, your card either doesn't support MSI-X, or you have MSI-X disabled. Check the hw.pci.enable_msix sysctl and make sure that it is set to 1. Also check to make sure there aren't any BIOS settings blocking MSI-X. Apparently the older Intel gigabit cards don't support MSI-X, and as such get starved. However, I haven't had the problem rear it's ugly head in quite a while, but that's with the newest 8.2-STABLE tree. No idea if it's just chance or if something was actually fixed. When it was happening to me, it would also happen about every week or two and I'd have to reboot the server. -- Joshua Boyd E-mail: boy...@jbip.net http://www.jbip.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 9 RC3 and VirtualBox
On Wed, Dec 21, 2011 at 2:22 PM, Joshua Boyd wrote: > Thanks. > Nevermind. This "new" work computer is 64 bit but doesn't have the right chipset features to support 64bit guests. Lame. Sorry for the noise. -- Joshua Boyd E-mail: boy...@jbip.net http://www.jbip.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
FreeBSD 9 RC3 and VirtualBox
I'm unable to install RC3 on VirtualBox, I receive the following error: CPU doesn't support long mode > > Consoles: internal video/keyboard > BIOS drive C: is disk0 > BIOS 639kB/1047552kB available memory > > FreeBSD/x86 bootstrap loader, Revision 1.1 > (r...@farrell.cse.buffalo.edu, Sun Dec 4 07:50:52 UTC 2011) > Can't work out which disk we are booting from. > Guess BIOS device 0x not found by probes, defaulting to disk0: > FATAL: int13_harddisk: function 42. Can't use 64bits lba > I've tried a few different controller combinations (SAS/SATA/IDE), but none seem to fix the problem. Any help would be cool. Thanks. -- Joshua Boyd E-mail: boy...@jbip.net http://www.jbip.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 9 RC3 and VirtualBox
On Wed, Dec 21, 2011 at 11:56 PM, Adam Vande More wrote: > VT-x(or the AMD equiv) is a CPU feature and is necessary to run 64-bit > guests. VT-d(or the AMD equiv)/IOMMU is the what is done in the chipset > however it isn't necessary to run 64-bit guests. Both of these features > are only found on CPU's supporting long mode. > Exactly. The E7300 lacks the VT-x bits. -- Joshua Boyd E-mail: boy...@jbip.net http://www.jbip.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Problems replacing failing drive in ZFS pool
On Wed, Jul 21, 2010 at 1:57 AM, alan bryan wrote: > > > --- On Mon, 7/19/10, Dan Langille wrote: > > > From: Dan Langille > > Subject: Re: Problems replacing failing drive in ZFS pool > > To: "Freddie Cash" > > Cc: "freebsd-stable" > > Date: Monday, July 19, 2010, 7:07 PM > > On 7/19/2010 12:15 PM, Freddie Cash > > wrote: > > > On Mon, Jul 19, 2010 at 8:56 AM, Garrett Moore > > > wrote: > > >> So you think it's because when I switch from the > > old disk to the new disk, > > >> ZFS doesn't realize the disk has changed, and > > thinks the data is just > > >> corrupt now? Even if that happens, shouldn't the > > pool still be available, > > >> since it's RAIDZ1 and only one disk has gone > > away? > > > > > > I think it's because you pull the old drive, boot with > > the new drive, > > > the controller re-numbers all the devices (ie da3 is > > now da2, da2 is > > > now da1, da1 is now da0, da0 is now da6, etc), and ZFS > > thinks that all > > > the drives have changed, thus corrupting the > > pool. I've had this > > > happen on our storage servers a couple of times before > > I started using > > > glabel(8) on all our drives (dead drive on RAID > > controller, remove > > > drive, reboot for whatever reason, all device nodes > > are renumbered, > > > everything goes kablooey). > > > > Can you explain a bit about how you use glabel(8) in > > conjunction with ZFS? If I can retrofit this into an > > exist ZFS array to make things easier in the future... > > > > 8.0-STABLE #0: Fri Mar 5 00:46:11 EST 2010 > > > > ]# zpool status > > pool: storage > > state: ONLINE > > scrub: none requested > > config: > > > > NAME > > STATE READ WRITE CKSUM > > storage > >ONLINE > >0 0 > >0 > > raidz1 > > ONLINE 0 > >0 0 > > ad8 > >ONLINE > >0 0 > >0 > > ad10 > > ONLINE 0 > >0 0 > > ad12 > > ONLINE 0 > >0 0 > > ad14 > > ONLINE 0 > >0 0 > > ad16 > > ONLINE 0 > >0 0 > > > > > Of course, always have good backups. ;) > > > > In my case, this ZFS array is the backup. ;) > > > > But I'm setting up a tape library, real soon now > > > > -- Dan Langille - http://langille.org/ > > ___ > > freebsd-stable@freebsd.org > > mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org > " > > > > Dan, > > Here's how to do it after the fact: > > > http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2009-07/msg00623.html > > --Alan Bryan > [r...@foghornleghorn ~]# glabel label disk01 /dev/da0 glabel: Can't store metadata on /dev/da0: Operation not permitted. Hrmph. > > > > > > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > -- Joshua Boyd JBipNet E-mail: boy...@jbip.net http://www.jbip.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Problems replacing failing drive in ZFS pool
On Wed, Jul 21, 2010 at 2:09 AM, Joshua Boyd wrote: > On Wed, Jul 21, 2010 at 1:57 AM, alan bryan wrote: > >> >> >> --- On Mon, 7/19/10, Dan Langille wrote: >> >> > From: Dan Langille >> > Subject: Re: Problems replacing failing drive in ZFS pool >> > To: "Freddie Cash" >> > Cc: "freebsd-stable" >> > Date: Monday, July 19, 2010, 7:07 PM >> > On 7/19/2010 12:15 PM, Freddie Cash >> > wrote: >> > > On Mon, Jul 19, 2010 at 8:56 AM, Garrett Moore> > >> > wrote: >> > >> So you think it's because when I switch from the >> > old disk to the new disk, >> > >> ZFS doesn't realize the disk has changed, and >> > thinks the data is just >> > >> corrupt now? Even if that happens, shouldn't the >> > pool still be available, >> > >> since it's RAIDZ1 and only one disk has gone >> > away? >> > > >> > > I think it's because you pull the old drive, boot with >> > the new drive, >> > > the controller re-numbers all the devices (ie da3 is >> > now da2, da2 is >> > > now da1, da1 is now da0, da0 is now da6, etc), and ZFS >> > thinks that all >> > > the drives have changed, thus corrupting the >> > pool. I've had this >> > > happen on our storage servers a couple of times before >> > I started using >> > > glabel(8) on all our drives (dead drive on RAID >> > controller, remove >> > > drive, reboot for whatever reason, all device nodes >> > are renumbered, >> > > everything goes kablooey). >> > >> > Can you explain a bit about how you use glabel(8) in >> > conjunction with ZFS? If I can retrofit this into an >> > exist ZFS array to make things easier in the future... >> > >> > 8.0-STABLE #0: Fri Mar 5 00:46:11 EST 2010 >> > >> > ]# zpool status >> > pool: storage >> > state: ONLINE >> > scrub: none requested >> > config: >> > >> > NAME >> > STATE READ WRITE CKSUM >> > storage >> >ONLINE >> >0 0 >> >0 >> > raidz1 >> > ONLINE 0 >> >0 0 >> > ad8 >> >ONLINE >> >0 0 >> >0 >> > ad10 >> > ONLINE 0 >> >0 0 >> > ad12 >> > ONLINE 0 >> >0 0 >> > ad14 >> > ONLINE 0 >> >0 0 >> > ad16 >> > ONLINE 0 >> >0 0 >> > >> > > Of course, always have good backups. ;) >> > >> > In my case, this ZFS array is the backup. ;) >> > >> > But I'm setting up a tape library, real soon now >> > >> > -- Dan Langille - http://langille.org/ >> > ___ >> > freebsd-stable@freebsd.org >> > mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> > To unsubscribe, send any mail to " >> freebsd-stable-unsubscr...@freebsd.org" >> > >> >> Dan, >> >> Here's how to do it after the fact: >> >> >> http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2009-07/msg00623.html >> >> --Alan Bryan >> > > [r...@foghornleghorn ~]# glabel label disk01 /dev/da0 > glabel: Can't store metadata on /dev/da0: Operation not permitted. > > Hrmph. > Nevermind, sysctl kern.geom.debugflags=16 solves that problem, but then you get this: [r...@foghornleghorn ~]# zpool replace tank da0 label/disk01 cannot open 'label/disk01': no such GEOM provider must be a full path or shorthand device name > > >> >> >> >> >> >> >> ___ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" >> > > > > -- > Joshua Boyd > JBipNet > > E-mail: boy...@jbip.net > > http://www.jbip.net > -- Joshua Boyd JBipNet E-mail: boy...@jbip.net http://www.jbip.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: PCI AP card recommendations
On Sun, Jul 25, 2010 at 5:10 PM, Beach Geek wrote: > Looking for feedback from people using FreeBSD v8.x as access points. > We will be using Pentium 3 boxes with 8-STABLE as APs. > Each box will have a unique SSID and use WPA2-PSK. > Each AP will be linked back to 2 gateways. > > I'm looking for AP card suggestions and any helpful hints as far as the > APs. Looking for card models, not chipsets. > > Looking forward to hearing your experiences. > Thanks, > RJ > > PS. We're looking for info beyond the FreeBSD documentation, and related > to > the 8.x branch. > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > I can't recommend a card, but I can recommend that you don't use a ral card. The encryption support is poor, since most of the current cards don't have on-board encryption and it gets offloaded to the server, resulting in drops (for me, atleast). Due to this, I'm using a standalone AP, plugged into an ethernet card on my server. -- Joshua Boyd JBipNet E-mail: boy...@jbip.net http://www.jbip.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: zpool - low speed write
On Wed, Aug 4, 2010 at 10:13 AM, Alex V. Petrov wrote: > interesting results: > > From single-UDF-disk to pool: > $ dd if=petrovs-disk1.iso of=/tank/petrovs-disk1.iso bs=1M > 3545+1 records in > 3545+1 records out > 3718002688 bytes transferred in 438.770195 secs (8473690 bytes/sec) > > From single-UDF-disk to null: > $ dd if=petrovs-disk1.iso of=/dev/null bs=1M > 3545+1 records in > 3545+1 records out > 3718002688 bytes transferred in 83.304575 secs (44631435 bytes/sec) > -- > Alex V. Petrov > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > What controllers are you using? What's the results of dd if=/dev/ada4 of=/dev/null bs=1M count=100 ? Have you tried switching to the ad driver? Maybe ada is buggy on your hardware. -- Joshua Boyd JBipNet E-mail: boy...@jbip.net http://www.jbip.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
8-STABLE Slow Write Speeds on ESXI 4.0
pci22: on pcib22
pcib23: at device 23.4 on pci0
pci23: on pcib23
pcib24: at device 23.5 on pci0
pci24: on pcib24
pcib25: at device 23.6 on pci0
pci25: on pcib25
pcib26: at device 23.7 on pci0
pci26: on pcib26
pcib27: at device 24.0 on pci0
pci27: on pcib27
pcib28: at device 24.1 on pci0
pci28: on pcib28
pcib29: at device 24.2 on pci0
pci29: on pcib29
pcib30: at device 24.3 on pci0
pci30: on pcib30
pcib31: at device 24.4 on pci0
pci31: on pcib31
pcib32: at device 24.5 on pci0
pci32: on pcib32
pcib33: at device 24.6 on pci0
pci33: on pcib33
pcib34: at device 24.7 on pci0
pci34: on pcib34
acpi_acad0: on acpi0
acpi_button0: on acpi0
atrtc0: port 0x70-0x71 irq 8 on acpi0
atkbdc0: port 0x60,0x64 irq 1 on acpi0
atkbd0: irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
psm0: irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
psm0: [ITHREAD]
psm0: model IntelliMouse, device ID 3
ppc0: port 0x378-0x37f irq 7 on acpi0
ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode
ppc0: [ITHREAD]
ppbus0: on ppc0
plip0: on ppbus0
plip0: [ITHREAD]
lpt0: on ppbus0
lpt0: [ITHREAD]
lpt0: Interrupt-driven port
ppi0: on ppbus0
uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
uart0: [FILTER]
uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0
uart1: [FILTER]
fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0
fdc0: [FILTER]
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
orm0: at iomem
0xc-0xc7fff,0xc8000-0xc8fff,0xdc000-0xd,0xe-0xe3fff on isa0
sc0: at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0
acpi_throttle0: on cpu0
acpi_throttle1: on cpu1
acpi_throttle1: failed to attach P_CNT
device_attach: acpi_throttle1 attach returned 6
acpi_throttle2: on cpu2
acpi_throttle2: failed to attach P_CNT
device_attach: acpi_throttle2 attach returned 6
acpi_throttle3: on cpu3
acpi_throttle3: failed to attach P_CNT
device_attach: acpi_throttle3 attach returned 6
Timecounters tick every 10.000 msec
acd0: CDROM at ata1-master UDMA33
da0 at mpt0 bus 0 scbus0 target 0 lun 0
da0: Fixed Direct Access SCSI-2 device
da0: 300.000MB/s transfers
da0: Command Queueing enabled
da0: 40960MB (83886080 512 byte sectors: 255H 63S/T 5221C)
SMP: AP CPU #3 Launched!
SMP: AP CPU #1 Launched!
SMP: AP CPU #2 Launched!
Trying to mount root from ufs:/dev/da0s1a
VMware memory control driver initialized
[r...@git /var/log]# mptutil show adapter
mpt0 Adapter:
Board Name: SAS3444
Board Assembly:
Chip Name: C1068E
Chip Revision: UNUSED
RAID Levels: none
--
Joshua Boyd
JBipNet
E-mail: boy...@jbip.net
http://www.jbip.net
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8-STABLE Slow Write Speeds on ESXI 4.0
On Sat, Aug 7, 2010 at 1:58 PM, Ivan Voras wrote: > On 7 August 2010 19:03, Joshua Boyd wrote: > > On Sat, Aug 7, 2010 at 7:57 AM, Ivan Voras wrote: > > >> It's unlikely they will help, but try: > >> > >> vfs.read_max=32 > >> > >> for read speeds (but test using the UFS file system, not as a raw device > >> like above), and: > >> > >> vfs.hirunningspace=8388608 > >> vfs.lorunningspace=4194304 > >> > >> for writes. Again, it's unlikely but I'm interested in results you > >> achieve. > >> > > > > This is interesting. Write speeds went up to 40MBish. Still slow, but 4x > > faster than before. > > [r...@git ~]# dd if=/dev/zero of=/var/testfile bs=1M count=250 > > 250+0 records in > > 250+0 records out > > 262144000 bytes transferred in 6.185955 secs (42377288 bytes/sec) > > [r...@git ~]# dd if=/var/testfile of=/dev/null > > 512000+0 records in > > 512000+0 records out > > 262144000 bytes transferred in 0.811397 secs (323077424 bytes/sec) > > So read speeds are up to what they should be, but write speeds are still > > significantly below what they should be. > > Well, you *could* double the size of "runningspace" tunables and try that > :) > > Basically, in tuning these two settings we are cheating: increasing > read-ahead (read_max) and write in-flight buffering (runningspace) in > order to offload as much IO to the controller (in this case vmware) as > soon as possible, so to reschedule horrible IO-caused context switches > vmware has. It will help sequential performance, but nothing can help > random IOs. > Hmm. So what you're saying is that FreeBSD doesn't properly support the ESXI controller? I'm going to try 7.3-RELEASE today, just to make sure that this isn't a regression of some kind. It seems from reading other posts that this used to work properly and satisfactorily. -- Joshua Boyd JBipNet E-mail: boy...@jbip.net http://www.jbip.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8-STABLE Slow Write Speeds on ESXI 4.0
On Mon, Aug 9, 2010 at 12:11 PM, Jeremy Chadwick wrote: > On Mon, Aug 09, 2010 at 05:12:21PM +0200, Ivan Voras wrote: > > On 9 August 2010 16:55, Joshua Boyd wrote: > > > On Sat, Aug 7, 2010 at 1:58 PM, Ivan Voras wrote: > > >> > > >> On 7 August 2010 19:03, Joshua Boyd wrote: > > >> > On Sat, Aug 7, 2010 at 7:57 AM, Ivan Voras > wrote: > > >> > > >> >> It's unlikely they will help, but try: > > >> >> > > >> >> vfs.read_max=32 > > >> >> > > >> >> for read speeds (but test using the UFS file system, not as a raw > > >> >> device > > >> >> like above), and: > > >> >> > > >> >> vfs.hirunningspace=8388608 > > >> >> vfs.lorunningspace=4194304 > > >> >> > > >> >> for writes. Again, it's unlikely but I'm interested in results you > > >> >> achieve. > > >> >> > > >> > > > >> > This is interesting. Write speeds went up to 40MBish. Still slow, > but 4x > > >> > faster than before. > > >> > [r...@git ~]# dd if=/dev/zero of=/var/testfile bs=1M count=250 > > >> > 250+0 records in > > >> > 250+0 records out > > >> > 262144000 bytes transferred in 6.185955 secs (42377288 bytes/sec) > > >> > [r...@git ~]# dd if=/var/testfile of=/dev/null > > >> > 512000+0 records in > > >> > 512000+0 records out > > >> > 262144000 bytes transferred in 0.811397 secs (323077424 bytes/sec) > > >> > So read speeds are up to what they should be, but write speeds are > still > > >> > significantly below what they should be. > > >> > > >> Well, you *could* double the size of "runningspace" tunables and try > that > > >> :) > > >> > > >> Basically, in tuning these two settings we are cheating: increasing > > >> read-ahead (read_max) and write in-flight buffering (runningspace) in > > >> order to offload as much IO to the controller (in this case vmware) as > > >> soon as possible, so to reschedule horrible IO-caused context switches > > >> vmware has. It will help sequential performance, but nothing can help > > >> random IOs. > > > > > > Hmm. So what you're saying is that FreeBSD doesn't properly support the > ESXI > > > controller? > > > > Nope, I'm saying you will never get raw disk-like performance with any > > "full" virtualization product, regardless of specifics. If you want > > performance, go OS-level (like jails) or some example of > > paravirtualization. > > > > > I'm going to try 7.3-RELEASE today, just to make sure that this isn't a > > > regression of some kind. It seems from reading other posts that this > used to > > > work properly and satisfactorily. > > > > Nope, I've been messing around with VMWare for a long time and the > > performance penalty was always there. > > I thought Intel VT-d was supposed to help address things like this? > Our ESXI boxes are AMD rigs, so VT-d doesn't help here. > > I can confirm on VMware Workstation 7.1, not ESXi, that disk I/O > performance isn't that great. I only test with a Host OS of Windows XP > SP3, and for the Guest OS's hard disk driver use the LSI SATA/SAS > option. I can't imagine IDE/ATA being faster, since (at least > Workstation) emulates an Intel ICH2. > > I was under the impression that ESXi provided native access to the > hardware in the system (vs. Workstation which emulates everything)? > The controller seen by FreeBSD in the OP's system is: > > mpt0: port 0x4000-0x40ff mem > 0xd9c04000-0xd9c07fff,0xd9c1-0xd9c1 irq 18 at device 0.0 on pci3 > mpt0: [ITHREAD] > mpt0: MPI Version=1.5.0.0 > > Which looks an awful lot like what I see on Workstation 7.1. > > FWIW, Workstation 7.1 is fairly adamant about stating "if you want > faster disk I/O, pre-allocate the disk space rather than let disk use > grow dynamically". I've never tested this however. > All disks on the test system are pre-allocated as stated in my original post. > > How does Linux's I/O perform with the same setup? > Linux performs significantly better, I'd have to run the tests again for exact numbers though. > > -- > | Jeremy Chadwick j...@parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > -- Joshua Boyd JBipNet E-mail: boy...@jbip.net http://www.jbip.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8-STABLE Slow Write Speeds on ESXI 4.0
On Mon, Aug 9, 2010 at 12:38 PM, Ivan Voras wrote: > On 9 August 2010 18:11, Jeremy Chadwick wrote: > > > I thought Intel VT-d was supposed to help address things like this? > > Probably - > http://www.intel.com/technology/itj/2006/v10i3/2-io/7-conclusion.htm > says it should help unmodified guests, but I don't know for sure. I do > know that Nehalems run faster on VMWare, probably because "nested > paging" or whatever it's called helps context switches on syscalls. > > > I can confirm on VMware Workstation 7.1, not ESXi, that disk I/O > > performance isn't that great. I only test with a Host OS of Windows XP > > SP3, and for the Guest OS's hard disk driver use the LSI SATA/SAS > > option. I can't imagine IDE/ATA being faster, since (at least > > Workstation) emulates an Intel ICH2. > > Yes, disk IO was always slow with VMWare. VirtualBox cheats by > emulating ATA controllers (ICH6) instead of SCSI and turning on disk > cache - it's noticably faster than VMWare. > I've only tried the SAS/SCSI controllers in ESXI. Perhaps I should try ATA... > > > I was under the impression that ESXi provided native access to the > > hardware in the system (vs. Workstation which emulates everything)? > > I think it can be configured this way, but then you'd need a separate > LUN for the VM drive, bypassing vmware's usual storage (vmfs) and all > the goodies that come with it. OTOH, there are paravirtualized drivers > for Linux and Windows in 4.0 which should help, but I haven't tried > them yet. > It can be configured this way, but then you'd have to pre-allocate LUNs for each of your VMs ... not all that convenient. > > > The controller seen by FreeBSD in the OP's system is: > > > > mpt0: port 0x4000-0x40ff mem > 0xd9c04000-0xd9c07fff,0xd9c1-0xd9c1 irq 18 at device 0.0 on pci3 > > mpt0: [ITHREAD] > > mpt0: MPI Version=1.5.0.0 > > > > Which looks an awful lot like what I see on Workstation 7.1. > > > > FWIW, Workstation 7.1 is fairly adamant about stating "if you want > > faster disk I/O, pre-allocate the disk space rather than let disk use > > grow dynamically". I've never tested this however. > > Yes, this statement has always been true. > > > How does Linux's I/O perform with the same setup? > > I've tested Linux, Windows and FreeBSD on VMWare 3.5 last year and the > results (IOPS) were: > > ESXi-FreeBSD174 > ESXi-Linux 221 > ESXI-Windows98 > Xen-FreeBSD 72 > Xen-Linux 148 > Xen-Linux-PV244 > HyperV-FreeBSD 61 > HyperV-Linux69 > HyperV-Windows 58 > > (I couldn't get Windows to run on Xen; "Linux-PV" is Linux as > paravirtualized Xen guest). > -- Joshua Boyd JBipNet E-mail: boy...@jbip.net http://www.jbip.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8-STABLE Slow Write Speeds on ESXI 4.0
On Mon, Aug 9, 2010 at 11:24 AM, Ivan Voras wrote: > On 9.8.2010 17:12, Ivan Voras wrote: > > On 9 August 2010 16:55, Joshua Boyd wrote: > >> On Sat, Aug 7, 2010 at 1:58 PM, Ivan Voras wrote: > > >> I'm going to try 7.3-RELEASE today, just to make sure that this isn't a > >> regression of some kind. It seems from reading other posts that this > used to > >> work properly and satisfactorily. > > > > Nope, I've been messing around with VMWare for a long time and the > > performance penalty was always there. > > Hmmm, I've been thinking a little and after retesting one of my guests > on a 12-drive RAID-6 HP FC enclosure, and your 40 MB/s writes actually > do seam slow. I'm getting around 110 MB/s sequential reads and writes > (untuned) and the guest controller is recognized as: > > mpt0: port 0x1400-0x14ff mem > 0xd882-0xd883,0xd880-0xd881 irq 17 at device 16.0 on pci0 > mpt0: [ITHREAD] > mpt0: MPI Version=1.2.0.0 > > on 7.3-release, i386, ESXi 4.0. > > Are you sure you are testing when no others guests generate IO? > There was definitely IO, but nothing signicant. I'd have to schedule a maintenance period to shut down all other guests, and the second ESXI box, since they both use the same MD3000 as DAS. > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > -- Joshua Boyd JBipNet E-mail: boy...@jbip.net http://www.jbip.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8-STABLE Slow Write Speeds on ESXI 4.0
On Tue, Aug 10, 2010 at 12:05 AM, Jeremy Chadwick wrote: > On Mon, Aug 09, 2010 at 11:59:46PM -0400, Joshua Boyd wrote: > > On Mon, Aug 9, 2010 at 12:11 PM, Jeremy Chadwick > > wrote: > > > > > On Mon, Aug 09, 2010 at 05:12:21PM +0200, Ivan Voras wrote: > > > > On 9 August 2010 16:55, Joshua Boyd wrote: > > > > > On Sat, Aug 7, 2010 at 1:58 PM, Ivan Voras > wrote: > > > > >> > > > > >> On 7 August 2010 19:03, Joshua Boyd wrote: > > > > >> > On Sat, Aug 7, 2010 at 7:57 AM, Ivan Voras > > > wrote: > > > > >> > > > > >> >> It's unlikely they will help, but try: > > > > >> >> > > > > >> >> vfs.read_max=32 > > > > >> >> > > > > >> >> for read speeds (but test using the UFS file system, not as a > raw > > > > >> >> device > > > > >> >> like above), and: > > > > >> >> > > > > >> >> vfs.hirunningspace=8388608 > > > > >> >> vfs.lorunningspace=4194304 > > > > >> >> > > > > >> >> for writes. Again, it's unlikely but I'm interested in results > you > > > > >> >> achieve. > > > > >> >> > > > > >> > > > > > >> > This is interesting. Write speeds went up to 40MBish. Still > slow, > > > but 4x > > > > >> > faster than before. > > > > >> > [r...@git ~]# dd if=/dev/zero of=/var/testfile bs=1M count=250 > > > > >> > 250+0 records in > > > > >> > 250+0 records out > > > > >> > 262144000 bytes transferred in 6.185955 secs (42377288 > bytes/sec) > > > > >> > [r...@git ~]# dd if=/var/testfile of=/dev/null > > > > >> > 512000+0 records in > > > > >> > 512000+0 records out > > > > >> > 262144000 bytes transferred in 0.811397 secs (323077424 > bytes/sec) > > > > >> > So read speeds are up to what they should be, but write speeds > are > > > still > > > > >> > significantly below what they should be. > > > > >> > > > > >> Well, you *could* double the size of "runningspace" tunables and > try > > > that > > > > >> :) > > > > >> > > > > >> Basically, in tuning these two settings we are cheating: > increasing > > > > >> read-ahead (read_max) and write in-flight buffering (runningspace) > in > > > > >> order to offload as much IO to the controller (in this case > vmware) as > > > > >> soon as possible, so to reschedule horrible IO-caused context > switches > > > > >> vmware has. It will help sequential performance, but nothing can > help > > > > >> random IOs. > > > > > > > > > > Hmm. So what you're saying is that FreeBSD doesn't properly support > the > > > ESXI > > > > > controller? > > > > > > > > Nope, I'm saying you will never get raw disk-like performance with > any > > > > "full" virtualization product, regardless of specifics. If you want > > > > performance, go OS-level (like jails) or some example of > > > > paravirtualization. > > > > > > > > > I'm going to try 7.3-RELEASE today, just to make sure that this > isn't a > > > > > regression of some kind. It seems from reading other posts that > this > > > used to > > > > > work properly and satisfactorily. > > > > > > > > Nope, I've been messing around with VMWare for a long time and the > > > > performance penalty was always there. > > > > > > I thought Intel VT-d was supposed to help address things like this? > > > > > > > Our ESXI boxes are AMD rigs, so VT-d doesn't help here. > > AMD offers the same technology; it's called AMD-Vi these days, and was > previously known as IOMMU. I don't have any familiarity with it. > As far as I know, all it gets you is passthrough. > > -- > | Jeremy Chadwick j...@parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > -- Joshua Boyd JBipNet E-mail: boy...@jbip.net http://www.jbip.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Extending your zfs pool with multiple devices
You need an HP SAS expander card in the new box, and an HBA in your primary box with external ports to hook it into. Then the drives in the other box will show up as local drives on your primary box. You don't even need an operating system on the second box, it just needs enough hardware in it to supply power to the SAS expander. On Thu, Sep 2, 2010 at 9:22 AM, Michal wrote: > I have a small problem that I am trying to work out a solution for. Imagine > you create a NAS box. Fill a small server with 5 hard drives, zfs them with > raidz or whatever, create your pools and then shear this to the network > using samba. Simple NAS box for your network to put their files and they > just connenct to \\nas1 > > This box is now full, my problem is that I could create a 2nd NAS box and > people use \\nas1 and \\nas2 but it's not very use friendly. Can I somehow > build a 2nd box which is identicle, but extend my pools into nas2. I was > thinking something like exporting the nas2 drives via iscsi and then nas1 > add's the drives to the pool...or something similar. I find that with any > NAS whether its home build or shop bought you will eventually run out of > space, and sure you can replace the HDD's with bigger ones but you will see > run out of space, and having multiple locations, in my mind, is not very > elegant. I cannot simply add more HDD's to the box as well as it's at full > capacity > > Thanks > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > -- Joshua Boyd JBipNet E-mail: boy...@jbip.net http://www.jbip.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
sysutils/py-zfs won't compile with lang/python27
I've upgraded to Python27, following directions in /usr/ports/UPDATING. Running cd /usr/ports/lang/python && make upgrade-site-packages results in the following output: http://pastebin.com/45wUteS9 My ports tree is current as of 5 minutes ago. Looking at the CVS logs, it seems like this is a supported configuration: http://www.mail-archive.com/cvs-...@freebsd.org/msg181293.html Any help would be appreciated. -- Joshua Boyd JBipNet E-mail: boy...@jbip.net http://www.jbip.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: sysutils/py-zfs won't compile with lang/python27
An update, I was able to make this work by reconfiguring the lang/python27 to not "Use GNU Pth for threading/multiprocessing". On Wed, Nov 24, 2010 at 2:20 AM, Joshua Boyd wrote: > I've upgraded to Python27, following directions in /usr/ports/UPDATING. > > Running cd /usr/ports/lang/python && make upgrade-site-packages results in > the following output: > > http://pastebin.com/45wUteS9 > > My ports tree is current as of 5 minutes ago. > > Looking at the CVS logs, it seems like this is a supported configuration: > > http://www.mail-archive.com/cvs-...@freebsd.org/msg181293.html > > Any help would be appreciated. > > -- > Joshua Boyd > JBipNet > > E-mail: boy...@jbip.net > > http://www.jbip.net > -- Joshua Boyd JBipNet E-mail: boy...@jbip.net http://www.jbip.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
mpt(4) iuCRC errors
Hello all, I'm receiving iuCRC errors pretty constantly after rebuilding from a December kernel/world to yesterday's source, like the following: mpt1: EvtLogData: IOCLogInfo: 0x31181000 mpt1: EvtLogData: Event Data: 0006 mpt1: mpt_cam_event: 0x1 (da6:mpt1:0:6:0): READ(10). CDB: 28 0 8 20 ae d7 0 0 40 0 (da6:mpt1:0:6:0): CAM status: SCSI Status Error (da6:mpt1:0:6:0): SCSI status: Check Condition (da6:mpt1:0:6:0): SCSI sense: ABORTED COMMAND asc:47,3 (Information unit iuCRC error detected) I was not receiving these errors previously. I recompiled to newest sources only to add support for mps(4) since I've got a supported card on the way. I also received these errors on boot for every drive (across 2 controllers), but that may have been related to enabling smartd at boot. Feb 20 00:12:37 foghornleghorn kernel: (da9:mpt0:0:1:0): READ(10). CDB: 28 0 60 48 52 80 0 0 80 0 Feb 20 00:12:37 foghornleghorn kernel: (da9:mpt0:0:1:0): CAM status: SCSI Status Error Feb 20 00:12:37 foghornleghorn kernel: (da9:mpt0:0:1:0): SCSI status: Check Condition Feb 20 00:12:37 foghornleghorn kernel: (da9:mpt0:0:1:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset, or bus device reset occurred) Feb 20 00:12:56 foghornleghorn kernel: mpt0: request 0xff80002a6f80:23060 timed out for ccb 0xff00062fe000 (req->ccb 0xff00062fe000) Feb 20 00:12:56 foghornleghorn kernel: mpt0: attempting to abort req 0xff80002a6f80:23060 function 0 Feb 20 00:12:56 foghornleghorn kernel: mpt0: completing timedout/aborted req 0xff80002a6f80:23060 Feb 20 00:12:56 foghornleghorn kernel: mpt0: abort of req 0xff80002a6f80:0 completed Feb 20 00:12:58 foghornleghorn kernel: mpt0: mpt_cam_event: 0x16 Feb 20 00:12:58 foghornleghorn kernel: mpt0: mpt_cam_event: 0x16 foghornleghorn# uname -ar FreeBSD foghornleghorn.res.openband.net 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #12: Sat Feb 19 23:51:05 EST 2011 r...@foghornleghorn.res.openband.net:/usr/obj/usr/src/sys/FOGHORNLEGHORN amd64 Thanks for any insight. -- Joshua Boyd JBipNet E-mail: boy...@jbip.net http://www.jbip.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: mpt(4) iuCRC errors
This doesn't look good. A scrub is showing some data being repaired on da6. I may try swapping out the drive for a cold spare. foghornleghorn# smartctl -a /dev/da6 smartctl 5.40 2010-10-16 r3189 [FreeBSD 8.2-PRERELEASE amd64] (local build) Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net (pass13:mpt1:0:6:0): INQUIRY. CDB: 12 0 0 0 24 0 (pass13:mpt1:0:6:0): CAM status: Command timeout (pass13:mpt1:0:6:0): INQUIRY. CDB: 12 0 0 0 24 0 (pass13:mpt1:0:6:0): CAM status: Command timeout Short INQUIRY response, skip product id A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options. On Sun, Feb 20, 2011 at 1:41 PM, Joshua Boyd wrote: > Hello all, > > I'm receiving iuCRC errors pretty constantly after rebuilding from a > December kernel/world to yesterday's source, like the following: > > mpt1: EvtLogData: IOCLogInfo: 0x31181000 > mpt1: EvtLogData: Event Data: 0006 > mpt1: mpt_cam_event: 0x1 > (da6:mpt1:0:6:0): READ(10). CDB: 28 0 8 20 ae d7 0 0 40 0 > (da6:mpt1:0:6:0): CAM status: SCSI Status Error > (da6:mpt1:0:6:0): SCSI status: Check Condition > (da6:mpt1:0:6:0): SCSI sense: ABORTED COMMAND asc:47,3 (Information > unit iuCRC error detected) > > I was not receiving these errors previously. I recompiled to newest > sources only to add support for mps(4) since I've got a supported card > on the way. > > I also received these errors on boot for every drive (across 2 > controllers), but that may have been related to enabling smartd at > boot. > > Feb 20 00:12:37 foghornleghorn kernel: (da9:mpt0:0:1:0): READ(10). > CDB: 28 0 60 48 52 80 0 0 80 0 > Feb 20 00:12:37 foghornleghorn kernel: (da9:mpt0:0:1:0): CAM status: > SCSI Status Error > Feb 20 00:12:37 foghornleghorn kernel: (da9:mpt0:0:1:0): SCSI status: > Check Condition > Feb 20 00:12:37 foghornleghorn kernel: (da9:mpt0:0:1:0): SCSI sense: > UNIT ATTENTION asc:29,0 (Power on, reset, or bus device reset > occurred) > Feb 20 00:12:56 foghornleghorn kernel: mpt0: request > 0xff80002a6f80:23060 timed out for ccb 0xff00062fe000 > (req->ccb 0xff00062fe000) > Feb 20 00:12:56 foghornleghorn kernel: mpt0: attempting to abort req > 0xff80002a6f80:23060 function 0 > Feb 20 00:12:56 foghornleghorn kernel: mpt0: completing > timedout/aborted req 0xff80002a6f80:23060 > Feb 20 00:12:56 foghornleghorn kernel: mpt0: abort of req > 0xff80002a6f80:0 completed > Feb 20 00:12:58 foghornleghorn kernel: mpt0: mpt_cam_event: 0x16 > Feb 20 00:12:58 foghornleghorn kernel: mpt0: mpt_cam_event: 0x16 > > foghornleghorn# uname -ar > FreeBSD foghornleghorn.res.openband.net 8.2-PRERELEASE FreeBSD > 8.2-PRERELEASE #12: Sat Feb 19 23:51:05 EST 2011 > r...@foghornleghorn.res.openband.net:/usr/obj/usr/src/sys/FOGHORNLEGHORN > amd64 > > Thanks for any insight. > > -- > Joshua Boyd > JBipNet > > E-mail: boy...@jbip.net > > http://www.jbip.net > -- Joshua Boyd JBipNet E-mail: boy...@jbip.net http://www.jbip.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: mpt(4) iuCRC errors
Just an update. I replaced the drive, and continued to see the same errors. I reseated the cable for that drive into the backplane, and it appears that the errors have gone away. ZFS is resilvering the drive now, so we'll see. I really should hotglue all of these connectors into the backplane! On Sun, Feb 20, 2011 at 2:06 PM, Joshua Boyd wrote: > This doesn't look good. A scrub is showing some data being repaired on > da6. I may try swapping out the drive for a cold spare. > > foghornleghorn# smartctl -a /dev/da6 > smartctl 5.40 2010-10-16 r3189 [FreeBSD 8.2-PRERELEASE amd64] (local build) > Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net > > (pass13:mpt1:0:6:0): INQUIRY. CDB: 12 0 0 0 24 0 > (pass13:mpt1:0:6:0): CAM status: Command timeout > (pass13:mpt1:0:6:0): INQUIRY. CDB: 12 0 0 0 24 0 > (pass13:mpt1:0:6:0): CAM status: Command timeout > Short INQUIRY response, skip product id > A mandatory SMART command failed: exiting. To continue, add one or > more '-T permissive' options. > > > On Sun, Feb 20, 2011 at 1:41 PM, Joshua Boyd wrote: >> Hello all, >> >> I'm receiving iuCRC errors pretty constantly after rebuilding from a >> December kernel/world to yesterday's source, like the following: >> >> mpt1: EvtLogData: IOCLogInfo: 0x31181000 >> mpt1: EvtLogData: Event Data: 0006 >> mpt1: mpt_cam_event: 0x1 >> (da6:mpt1:0:6:0): READ(10). CDB: 28 0 8 20 ae d7 0 0 40 0 >> (da6:mpt1:0:6:0): CAM status: SCSI Status Error >> (da6:mpt1:0:6:0): SCSI status: Check Condition >> (da6:mpt1:0:6:0): SCSI sense: ABORTED COMMAND asc:47,3 (Information >> unit iuCRC error detected) >> >> I was not receiving these errors previously. I recompiled to newest >> sources only to add support for mps(4) since I've got a supported card >> on the way. >> >> I also received these errors on boot for every drive (across 2 >> controllers), but that may have been related to enabling smartd at >> boot. >> >> Feb 20 00:12:37 foghornleghorn kernel: (da9:mpt0:0:1:0): READ(10). >> CDB: 28 0 60 48 52 80 0 0 80 0 >> Feb 20 00:12:37 foghornleghorn kernel: (da9:mpt0:0:1:0): CAM status: >> SCSI Status Error >> Feb 20 00:12:37 foghornleghorn kernel: (da9:mpt0:0:1:0): SCSI status: >> Check Condition >> Feb 20 00:12:37 foghornleghorn kernel: (da9:mpt0:0:1:0): SCSI sense: >> UNIT ATTENTION asc:29,0 (Power on, reset, or bus device reset >> occurred) >> Feb 20 00:12:56 foghornleghorn kernel: mpt0: request >> 0xff80002a6f80:23060 timed out for ccb 0xff00062fe000 >> (req->ccb 0xff00062fe000) >> Feb 20 00:12:56 foghornleghorn kernel: mpt0: attempting to abort req >> 0xff80002a6f80:23060 function 0 >> Feb 20 00:12:56 foghornleghorn kernel: mpt0: completing >> timedout/aborted req 0xff80002a6f80:23060 >> Feb 20 00:12:56 foghornleghorn kernel: mpt0: abort of req >> 0xff80002a6f80:0 completed >> Feb 20 00:12:58 foghornleghorn kernel: mpt0: mpt_cam_event: 0x16 >> Feb 20 00:12:58 foghornleghorn kernel: mpt0: mpt_cam_event: 0x16 >> >> foghornleghorn# uname -ar >> FreeBSD foghornleghorn.res.openband.net 8.2-PRERELEASE FreeBSD >> 8.2-PRERELEASE #12: Sat Feb 19 23:51:05 EST 2011 >> r...@foghornleghorn.res.openband.net:/usr/obj/usr/src/sys/FOGHORNLEGHORN >> amd64 >> >> Thanks for any insight. >> >> -- >> Joshua Boyd >> JBipNet >> >> E-mail: boy...@jbip.net >> >> http://www.jbip.net >> > > > > -- > Joshua Boyd > JBipNet > > E-mail: boy...@jbip.net > > http://www.jbip.net > -- Joshua Boyd JBipNet E-mail: boy...@jbip.net http://www.jbip.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS - abysmal performance with samba since upgrade to 8.2-RELEASE
On Thu, Feb 24, 2011 at 2:55 AM, Jeremy Chadwick wrote: > On Thu, Feb 24, 2011 at 08:30:17AM +0100, Damien Fleuriot wrote: >> Hello list, >> >> I've recently upgraded my home box from 8.2-PRE to 8.2-RELEASE and since >> then I've been experiencing *abysmal* performance with samba. >> >> We're talking transfer rates of say 50kbytes/s here, and I'm the only >> client on the box. > > I have a similar system with significantly less disks (two pools, one > disk each; yes, no redundancy). The system can push, via SMB/CIFS > across the network about 65-70MBytes/sec, and 80-90MByte/sec via FTP. > I'll share with you my tunings for Samba, ZFS, and the system. I spent > quite some time messing with different values in Samba and FreeBSD to > find out what got me the "best" performance without destroying the > system horribly. > Hey Jeremy, Thanks for this post. These settings seem to have fixed my Samba configuration. I had configured with AIO previously, but apparently my tunings weren't spot on. I'd get buffering over 100Mbit with 1080p video, but 720p video would work just fine. Looks like this is what I needed to be able to ditch using DLNA for streaming to my Popbox! -- Joshua Boyd JBipNet E-mail: boy...@jbip.net http://www.jbip.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.2-RELEASE pf rules not loading
My pf related lines in rc.conf look like the following: pf_enable="YES" pf_rules="/etc/pf.conf" pflog_enable="YES" pflog_logfile="/var/log/pflog" pflog_flags="" I do have a problem from time to time where the rules won't load, but that's usually because a DHCP interface has failed to come up and my rules aren't written exactly properly to allow for that. On Fri, Feb 25, 2011 at 12:11 PM, Vincent Hoffman wrote: > Hi All, > Just upgraded my home machine to 8.2-RELEASE via > freebsd-update remotely (spare time at work.) and on reboot my pf > ruleset isnt being loaded. running '/etc/rc.d/pf start' once its booted > does start it fine though. Any suggestions on debugging or shall i just > try a verbose boot and watch the console when I get home? > I still have > > pf_enable="YES" # Set to YES to enable packet filter (pf) > pflog_enable="YES" # Set to YES to enable packet filter > logging > > in /etc/rc.conf > > > Regards, > Vince > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > -- Joshua Boyd JBipNet E-mail: boy...@jbip.net http://www.jbip.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
install: amdsbwd.ko: No such file or directory
make buildkernel KERNCONF=CUSTOM fails on latest 8-STABLE. Here's the diff between GENERIC and CUSTOM: $ diff GENERIC CUSTOM 323a324,343 > > # pf support > device mem > device pf > device pflog > device pfsync > > # altq support > options ALTQ > options ALTQ_CBQ > options ALTQ_RED > options ALTQ_RIO > options ALTQ_HFSC > options ALTQ_PRIQ > options ALTQ_NOPCC > > # other optimizations > deviceamdsbwd #Only added to see if this would help > options HZ=1000 > options DEVICE_POLLING buildkernel fails out with: install: amdsbwd.ko: No such file or directory Any help would be appreciated. cvsup was done last night. Let me know if any additional info is needed. -- Joshua Boyd JBipNet E-mail: boy...@jbip.net http://www.jbip.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: install: amdsbwd.ko: No such file or directory
I'm sorry, it's installkernel that fails. I'll provide more details tonight when I get home from work. On Thu, Jan 21, 2010 at 12:52 PM, Andriy Gapon wrote: > on 21/01/2010 19:16 Joshua Boyd said the following: > > make buildkernel KERNCONF=CUSTOM fails on latest 8-STABLE. > > > > Here's the diff between GENERIC and CUSTOM: > > $ diff GENERIC CUSTOM > > 323a324,343 > >> # pf support > >> device mem > >> device pf > >> device pflog > >> device pfsync > >> > >> # altq support > >> options ALTQ > >> options ALTQ_CBQ > >> options ALTQ_RED > >> options ALTQ_RIO > >> options ALTQ_HFSC > >> options ALTQ_PRIQ > >> options ALTQ_NOPCC > >> > >> # other optimizations > >> deviceamdsbwd #Only added to see if this would help > >> options HZ=1000 > >> options DEVICE_POLLING > > > > buildkernel fails out with: > > > > install: amdsbwd.ko: No such file or directory > > > > Any help would be appreciated. cvsup was done last night. Let me know if > any > > additional info is needed. > > Hmm, I didn't think that buildkernel executes install.. > Could you provide a little bit more context from the build? > > -- > Andriy Gapon > -- Joshua Boyd JBipNet E-mail: boy...@jbip.net Cell: (513) 375-0157 http://www.jbip.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: install: amdsbwd.ko: No such file or directory
Well, I have good news and bad news. I was able to get the kernel installed, reboot, and do a mergemaster -p. When I went to do installworld, it failed on me. I tried to do buildworld again, and get this: cc -O2 -pipe -DNEED_SOLARIS_BOOLEAN -I/usr/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/compat/opensolaris -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/compat/opensolaris/include -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris -I/usr/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/contrib/opensolaris -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/head -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/common -I/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt -I/usr/src/cddl/usr.bin/ctfconvert/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -g -Wno-unknown-pragmas -I/usr/obj/usr/src/tmp/legacy/usr/include -static -L/usr/obj/usr/src/tmp/legacy/usr/lib -o ctfconvert alist.o ctf.o ctfconvert.o dwarf.o fixup_tdescs.o hash.o iidesc.o input.o list.o memory.o merge.o output.o st_parse.o stabs.o stack.o strtab.o symbol.o tdata.o traverse.o util.o -lctf -ldwarf -lelf -lz -lthr -legacy /usr/lib/libthr.a(thr_syscalls.o)(.text+0x87a): In function `___pselect': : undefined reference to `__pselect' *** Error code 1 Stop in /usr/src/cddl/usr.bin/ctfconvert. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. I tried to re cvsup, make cleanworld && make cleandir, and moved my make.conf and src.conf out of the way. Build dies at the same place. Googling found this other fellow with the same problem, but no solution: http://forums.freebsd.org/showthread.php?p=63531 Any help would be appreciated. Thanks. On Thu, Jan 21, 2010 at 12:54 PM, Joshua Boyd wrote: > I'm sorry, it's installkernel that fails. > > I'll provide more details tonight when I get home from work. > > On Thu, Jan 21, 2010 at 12:52 PM, Andriy Gapon wrote: > >> on 21/01/2010 19:16 Joshua Boyd said the following: >> > make buildkernel KERNCONF=CUSTOM fails on latest 8-STABLE. >> > >> > Here's the diff between GENERIC and CUSTOM: >> > $ diff GENERIC CUSTOM >> > 323a324,343 >> >> # pf support >> >> device mem >> >> device pf >> >> device pflog >> >> device pfsync >> >> >> >> # altq support >> >> options ALTQ >> >> options ALTQ_CBQ >> >> options ALTQ_RED >> >> options ALTQ_RIO >> >> options ALTQ_HFSC >> >> options ALTQ_PRIQ >> >> options ALTQ_NOPCC >> >> >> >> # other optimizations >> >> deviceamdsbwd #Only added to see if this would help >> >> options HZ=1000 >> >> options DEVICE_POLLING >> > >> > buildkernel fails out with: >> > >> > install: amdsbwd.ko: No such file or directory >> > >> > Any help would be appreciated. cvsup was done last night. Let me know if >> any >> > additional info is needed. >> >> Hmm, I didn't think that buildkernel executes install.. >> Could you provide a little bit more context from the build? >> >> -- >> Andriy Gapon >> > > > > -- > Joshua Boyd > JBipNet > > E-mail: boy...@jbip.net > > http://www.jbip.net > -- Joshua Boyd JBipNet E-mail: boy...@jbip.net http://www.jbip.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: em interface slow down on 8.0R
I've been having a similar problem with my network dropping completely on my 8-STABLE gateway/firewall/fileserver. My setup is a little different, as I have re0 and ral0 bridged for LAN, and em0 for WAN. I've just turned off TX checksum offloading to see if that makes any difference. On Mon, Jan 25, 2010 at 1:49 PM, Lars Eggert wrote: > Hi, > > On 2010-1-25, at 19:38, Nick Rogers wrote: > >> On Mon, Jan 25, 2010 at 10:22 AM, Pyun YongHyeon > wrote: > >> I'm not sure you're seeing a checksum offload bug of em(4) but the > >> bug is easily reproducible in VLAN environments. If the issue is > >> gone when you disable TX checksum offloading, see kern/141843 for > >> for more detailed information as well as fix. > >> > > Good to know, but I am having a similar problem on another em(4) > interface that has no VLAN interfaces. > > FYI, I also have these issues without using VLANs, and turning off TSO > fixed them. > > Lars -- Joshua Boyd JBipNet E-mail: boy...@jbip.net http://www.jbip.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: More zfs benchmarks
Repeated the same tests on my AMD64 dual core 4GB system with 5 HD103SI 1T drives in raidz1 on a Supermicro PCI-E controller, running 8-STABLE. foghornleghorn# dd if=/dev/zero of=/usr/zerofile.000 bs=1M count=200 200+0 records in 200+0 records out 209715200 bytes transferred in 4.246402 secs (49386563 bytes/sec) foghornleghorn# dd if=/dev/zero of=/usr/zerofile.000 bs=1M count=200 200+0 records in 200+0 records out 209715200 bytes transferred in 3.913826 secs (53583169 bytes/sec) foghornleghorn# dd if=/dev/zero of=/usr/zerofile.000 bs=1M count=200 200+0 records in 200+0 records out 209715200 bytes transferred in 4.436917 secs (47265975 bytes/sec) foghornleghorn# dd if=/dev/zero of=/tank/zerofile.000 bs=1M count=200 200+0 records in 200+0 records out 209715200 bytes transferred in 0.377800 secs (555095486 bytes/sec) foghornleghorn# dd if=/dev/zero of=/tank/zerofile.000 bs=1M count=200 200+0 records in 200+0 records out 209715200 bytes transferred in 0.140478 secs (1492869742 bytes/sec) foghornleghorn# dd if=/dev/zero of=/tank/zerofile.000 bs=1M count=200 200+0 records in 200+0 records out 209715200 bytes transferred in 0.140452 secs (1493143431 bytes/sec) foghornleghorn# dd if=/dev/zero of=/tank/zerofile.000 bs=1M count=2000 2000+0 records in 2000+0 records out 2097152000 bytes transferred in 8.117563 secs (258347487 bytes/sec) foghornleghorn# dd if=/dev/zero of=/tank/zerofile.000 bs=1M count=2000 2000+0 records in 2000+0 records out 2097152000 bytes transferred in 8.251862 secs (254142882 bytes/sec) foghornleghorn# dd if=/dev/zero of=/tank/zerofile.000 bs=1M count=2000 2000+0 records in 2000+0 records out 2097152000 bytes transferred in 8.307188 secs (252450287 bytes/sec) foghornleghorn# dd if=/dev/da0 of=/dev/null bs=1M count=2000 2000+0 records in 2000+0 records out 2097152000 bytes transferred in 18.958791 secs (110616336 bytes/sec) foghornleghorn# dd if=/dev/da0 of=/dev/null bs=1M count=2000 2000+0 records in 2000+0 records out 2097152000 bytes transferred in 18.924833 secs (110814822 bytes/sec) foghornleghorn# dd if=/dev/da0 of=/dev/null bs=1M count=2000 2000+0 records in 2000+0 records out 2097152000 bytes transferred in 18.893001 secs (111001529 bytes/sec) foghornleghorn# dd if=/tank/zerofile.000 of=/dev/null bs=1M 2000+0 records in 2000+0 records out 2097152000 bytes transferred in 5.156406 secs (406708089 bytes/sec) foghornleghorn# dd if=/tank/zerofile.000 of=/dev/null bs=1M 2000+0 records in 2000+0 records out 2097152000 bytes transferred in 5.126920 secs (409047148 bytes/sec) foghornleghorn# dd if=/tank/zerofile.000 of=/dev/null bs=1M 2000+0 records in 2000+0 records out 2097152000 bytes transferred in 5.145461 secs (407573211 bytes/sec) Here are my relevant settings: vfs.zfs.prefetch_disable=0 vfs.zfs.zil_disable="1" Other than that, I'm trusting FreeBSD's default settings, and they seem to be working pretty well. On Sun, Feb 14, 2010 at 3:34 PM, Michael Loftis wrote: > > > --On Sunday, February 14, 2010 5:28 PM + Jonathan Belson < > j...@witchspace.com> wrote: > > Hiya >> >> After reading some earlier threads about zfs performance, I decided to >> test my own server. I found the results rather surprising... >> >> > You really need to test with at least 4GB of data, else you're just testing > caching speeds on writing. Use a test suite like bonnie++ and you'll see > just how poor the ZFS performance is, especially with multiple readers on > the same file, atleast in 8.0. > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > -- Joshua Boyd JBipNet E-mail: boy...@jbip.net http://www.jbip.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: More zfs benchmarks
On Sun, Feb 14, 2010 at 6:12 PM, Joshua Boyd wrote: > > > On Sun, Feb 14, 2010 at 5:58 PM, Jonathan Belson wrote: > >> On 14 Feb 2010, at 21:15, Joshua Boyd wrote: >> >> > Repeated the same tests on my AMD64 dual core 4GB system with 5 HD103SI >> 1T >> > drives in raidz1 on a Supermicro PCI-E controller, running 8-STABLE. >> >> [ snip results ] >> >> I was hoping I'd get something closer to these figures... >> >> > Here are my relevant settings: >> > >> > vfs.zfs.prefetch_disable=0 >> > vfs.zfs.zil_disable="1" >> >> I already had prefetch disabled, but retrying with zil disabled made no >> difference. >> > > That setting actually enables prefetch ... I have 4GB of RAM, so I felt > safe turning it on. > > >> >> What is your arc_min and arc_max set to? >> > > System Memory: > Physical RAM: 4015 MB > Free Memory : 2130 MB > > ARC Size: > Current Size: 783 MB (arcsize) > Target Size (Adaptive): 783 MB (c) > Min Size (Hard Limit):101 MB (zfs_arc_min) > Max Size (Hard Limit):808 MB (zfs_arc_max) > > ARC Size Breakdown: > Most Recently Used Cache Size: 97% 764 MB (p) > Most Frequently Used Cache Size: 2% 18 MB (c-p) > > ARC Efficency: > Cache Access Total: 148383 > Cache Hit Ratio: 66% 98434 [Defined State for buffer] > Cache Miss Ratio: 33% 49949 [Undefined State for Buffer] > REAL Hit Ratio: 65% 96744 [MRU/MFU Hits Only] > > Data Demand Efficiency:99% > Data Prefetch Efficiency: 0% > > CACHE HITS BY CACHE LIST: > Anon:1% 1515[ New > Customer, First Cache Hit ] > Most Recently Used: 28% 27931 (mru) [ Return > Customer ] > Most Frequently Used: 69% 68813 (mfu) [ Frequent > Customer ] > Most Recently Used Ghost:0% 175 (mru_ghost)[ Return > Customer Evicted, Now Back ] > Most Frequently Used Ghost: 0% 0 (mfu_ghost)[ Frequent > Customer Evicted, Now Back ] > CACHE HITS BY DATA TYPE: > Demand Data:12% 12369 > Prefetch Data: 0% 0 > Demand Metadata:85% 84375 > Prefetch Metadata: 1% 1690 > CACHE MISSES BY DATA TYPE: > Demand Data: 0% 6 > Prefetch Data: 96% 47994 > Demand Metadata: 3% 1580 > Prefetch Metadata: 0% 369 > - > > > >> >> > >> > On Sun, Feb 14, 2010 at 3:34 PM, Michael Loftis >> wrote: >> >>> >> >> You really need to test with at least 4GB of data, else you're just >> testing >> >> caching speeds on writing. Use a test suite like bonnie++ and you'll >> see >> >> I'd expect to get more than 4MB/s if I was just measuring cache speed :-) >> >> Cheers, >> >> --Jon >> >> > > > -- > Joshua Boyd > JBipNet > > E-mail: boy...@jbip.net > > http://www.jbip.net > -- Joshua Boyd JBipNet E-mail: boy...@jbip.net http://www.jbip.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: More zfs benchmarks
Here's my bonnie++ results: foghornleghorn# bonnie++ -s 8192 -d. -n64 -uroot Using uid:0, gid:0. Writing a byte at a time...done Writing intelligently...done Rewriting...done Reading a byte at a time...done Reading intelligently...done start 'em...done...done...done...done...done... Create files in sequential order...done. Stat files in sequential order...done. Delete files in sequential order...done. Create files in random order...done. Stat files in random order...done. Delete files in random order...done. Version 1.96 --Sequential Output-- --Sequential Input- --Random- Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- MachineSize K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP foghornleghorn.r 8G 184 99 191627 43 150484 35 416 98 388853 49 103.3 3 Latency 47480us1645ms1545ms 53943us 186ms 2449ms Version 1.96 --Sequential Create-- Random Create foghornleghorn.res. -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 64 22256 80 37111 99 17478 88 22686 81 37208 99 15053 90 Latency 28364us 336us 274us 27001us 321us 80123us 1.96,1.96,foghornleghorn.res.openband.net ,1,1266194600,8G,,184,99,191627,43,150484,35,416,98,388853,49,103.3,3,64,22256,80,37111,99,17478,88,22686,81,37208,99,15053,90,47480us,1645ms,1545ms,53943us,186ms,2449ms,28364us,336us,274us,27001us,321us,80123us On Sun, Feb 14, 2010 at 6:23 PM, Joshua Boyd wrote: > > > On Sun, Feb 14, 2010 at 6:12 PM, Joshua Boyd wrote: > >> >> >> On Sun, Feb 14, 2010 at 5:58 PM, Jonathan Belson wrote: >> >>> On 14 Feb 2010, at 21:15, Joshua Boyd wrote: >>> >>> > Repeated the same tests on my AMD64 dual core 4GB system with 5 HD103SI >>> 1T >>> > drives in raidz1 on a Supermicro PCI-E controller, running 8-STABLE. >>> >>> [ snip results ] >>> >>> I was hoping I'd get something closer to these figures... >>> >>> > Here are my relevant settings: >>> > >>> > vfs.zfs.prefetch_disable=0 >>> > vfs.zfs.zil_disable="1" >>> >>> I already had prefetch disabled, but retrying with zil disabled made no >>> difference. >>> >> >> That setting actually enables prefetch ... I have 4GB of RAM, so I felt >> safe turning it on. >> >> >>> >>> What is your arc_min and arc_max set to? >>> >> >> System Memory: >> Physical RAM: 4015 MB >> Free Memory : 2130 MB >> >> ARC Size: >> Current Size: 783 MB (arcsize) >> Target Size (Adaptive): 783 MB (c) >> Min Size (Hard Limit):101 MB (zfs_arc_min) >> Max Size (Hard Limit):808 MB (zfs_arc_max) >> >> ARC Size Breakdown: >> Most Recently Used Cache Size: 97% 764 MB (p) >> Most Frequently Used Cache Size: 2% 18 MB (c-p) >> >> ARC Efficency: >> Cache Access Total: 148383 >> Cache Hit Ratio: 66% 98434 [Defined State for buffer] >> Cache Miss Ratio: 33% 49949 [Undefined State for >> Buffer] >> REAL Hit Ratio: 65% 96744 [MRU/MFU Hits Only] >> >> Data Demand Efficiency:99% >> Data Prefetch Efficiency: 0% >> >> CACHE HITS BY CACHE LIST: >> Anon:1% 1515[ New >> Customer, First Cache Hit ] >> Most Recently Used: 28% 27931 (mru) [ Return >> Customer ] >> Most Frequently Used: 69% 68813 (mfu) [ Frequent >> Customer ] >> Most Recently Used Ghost:0% 175 (mru_ghost)[ Return >> Customer Evicted, Now Back ] >> Most Frequently Used Ghost: 0% 0 (mfu_ghost)[ Frequent >> Customer Evicted, Now Back ] >> CACHE HITS BY DATA TYPE: >> Demand Data:12% 12369 >> Prefetch Data: 0% 0 >> Demand Metadata:85% 84375 >> Prefetch Metadata: 1% 1690 >> CACHE MISSES BY DATA TYPE: >> Demand Data: 0% 6 >> Prefetch Data: 96% 47994 >> Demand Metadata: 3% 1580 >> Prefetch Metadata: 0% 369 >> - >> >> >> >>> >>> > >>> > On Sun,
Re: raidz/2 stripe widths
http://blogs.sun.com/ahl/entry/double_parity_raid_z Looks like raidz2 is recommended for better protection against failures than 2 stripes. On Tue, Feb 16, 2010 at 2:47 PM, Peter C. Lai wrote: > Which one might be "better" on pool that will consist of 6 disks: > > 6x raidz2 > > or > > 2 stripes of 3 disks in raidz? > > It should provide slightly less reliability (still allows for 2 disks to be > off the array at a time) but the latter should improve reads since a given > read only has to touch 3 spindles at a time instead of 5? > -- > === > Peter C. Lai | Bard College at Simon's Rock > Systems Administrator| 84 Alford Rd. > Information Technology Svcs. | Gt. Barrington, MA 01230 USA > peter AT simons-rock.edu | (413) 528-7428 > === > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > -- Joshua Boyd JBipNet E-mail: boy...@jbip.net http://www.jbip.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: fault tolerant web servers on freebsd
On Wed, Apr 7, 2010 at 3:00 AM, Andriy Gapon wrote: > on 07/04/2010 09:05 Aristedes Maniatis said the following: > > Until we get to 'database' everything is HA and quite easy to build and > > manage. Having a clustered database solution is expensive and beyond > > most smallish budgets. mysql and postgresql don't have anything > > available that is quite ready yet (IMO), so you'll need to be talking to > > the bigger (expensive) players about their clustered offerings. > Master-master circular replication in mySQL probably fits the bill. Master-slave requires a slave to promote itself to master, which can get tricky. > > Out of curiosity: have you considered MySQL Cluster: > http://en.wikipedia.org/wiki/MySQL_Cluster > http://www.mysql.com/products/database/cluster/faq.html > > If yes, can you share your evaluation results? > Thanks! > > -- > Andriy Gapon > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > -- Joshua Boyd JBipNet E-mail: boy...@jbip.net Cell: (513) 375-0157 http://www.jbip.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
