Re: LSI 9240-4i 4K alignment
Hi, Works fine for me with 9.0-p3 with the same controller, slight firmware differences: mfi0: 2709 (boot + 4s/0x0020/info) - Firmware version 2.120.244-1482 mfi0: 2710 (boot + 5s/0x0020/info) - Package version 20.10.1-0077 mfi0: 2711 (boot + 5s/0x0020/info) - Board Revision 04A I will be trying out 9.1-BETA on a new batch of machines next week ... Regards, Jan. On 08/08/2012, at 7:25 AM, George Kontostanos gkontos.m...@gmail.com wrote: Hi all, We have a server with a LSI 9240-4i controller configured in JBOD with 4 SATA disks. Running FreeBSD 9.1-Beta1: Relevant dmesg: FreeBSD 9.1-BETA1 #0: Thu Jul 12 09:38:51 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 CPU: Intel(R) Xeon(R) CPU E31230 @ 3.20GHz (3200.09-MHz K8-class CPU) Origin = GenuineIntel Id = 0x206a7 Family = 6 Model = 2a Stepping = 7 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x1fbae3ffSSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX AMD Features=0x28100800SYSCALL,NX,RDTSCP,LM AMD Features2=0x1LAHF TSC: P-state invariant, performance statistics real memory = 17179869184 (16384 MB) avail memory = 16471670784 (15708 MB) ... mfi0: Drake Skinny port 0xe000-0xe0ff mem 0xf7a6-0xf7a63fff,0xf7a0-0xf7a3 irq 16 at device 0.0 on pci1 mfi0: Using MSI mfi0: Megaraid SAS driver Ver 4.23 ... mfi0: 321 (397672301s/0x0020/info) - Shutdown command received from host mfi0: 322 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/9241/1000) mfi0: 323 (boot + 3s/0x0020/info) - Firmware version 2.130.354-1664 mfi0: 324 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0073/1000/9241/1000) mfi0: 325 (boot + 3s/0x0020/info) - Firmware version 2.130.354-1664 mfi0: 326 (boot + 5s/0x0020/info) - Package version 20.10.1-0107 mfi0: 327 (boot + 5s/0x0020/info) - Board Revision 03A mfi0: 328 (boot + 25s/0x0002/info) - Inserted: PD 04(e0xff/s3) ... mfisyspd0 on mfi0 mfisyspd0: 1907729MB (3907029168 sectors) SYSPD volume mfisyspd0: SYSPD volume attached mfisyspd1 on mfi0 mfisyspd1: 1907729MB (3907029168 sectors) SYSPD volume mfisyspd1: SYSPD volume attached mfisyspd2 on mfi0 mfisyspd2: 1907729MB (3907029168 sectors) SYSPD volume mfisyspd2: SYSPD volume attached mfisyspd3 on mfi0 mfisyspd3: 1907729MB (3907029168 sectors) SYSPD volume mfisyspd3: SYSPD volume attached ... mfi0: 329 (boot + 25s/0x0002/info) - Inserted: PD 04(e0xff/s3) Info: enclPd=, scsiType=0, portMap=00, sasAddr=44332211, mfi0: 330 (boot + 25s/0x0002/info) - Inserted: PD 05(e0xff/s1) mfi0: 331 (boot + 25s/0x0002/info) - Inserted: PD 05(e0xff/s1) Info: enclPd=, scsiType=0, portMap=02, sasAddr=443322110200, mfi0: 332 (boot + 25s/0x0002/info) - Inserted: PD 06(e0xff/s2) mfi0: 333 (boot + 25s/0x0002/info) - Inserted: PD 06(e0xff/s2) Info: enclPd=, scsiType=0, portMap=03, sasAddr=443322110100, mfi0: 334 (boot + 25s/0x0002/info) - Inserted: PD 07(e0xff/s0) mfi0: 335 (boot + 25s/0x0002/info) - Inserted: PD 07(e0xff/s0) Info: enclPd=, scsiType=0, portMap=01, sasAddr=443322110300, mfi0: 336 (397672376s/0x0020/info) - Time established as 08/07/12 16:32:56; (28 seconds since power on) The problem: When trying to create a RaidZ pool using gpart and perform a 4K alignment using gnop, we get the follwoing error immediately after exporting the pool and destroying the .nop devices: id: 8043746387654554958 state: FAULTED status: One or more devices contains corrupted data. action: The pool cannot be imported due to damaged devices or data. The pool may be active on another system, but can be imported using the '-f' flag. see: http://illumos.org/msg/ZFS-8000-5E config: Pool FAULTED corrupted data raidz1-0ONLINE 13283347160590042564 UNAVAIL corrupted data 16981727992215676534 UNAVAIL corrupted data 6607570030658834339 UNAVAIL corrupted data 3435463242860701988 UNAVAIL corrupted data When we use glabel for the same purpose with the combination of gnop, the pool imports fine. Any suggestions? -- George Kontostanos Aicom telecoms ltd http://www.aisecure.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-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
pf nat fails on msk0 from packets deriving from a jail interface
Hi all, Suddenly I am facing a problem on a new PC, using a configuration that I have been using on more than 10 servers for the last few years. The only thing that I find that differs from my other configuratinos is the NIC of the PC. If not, I must be missing something very trivial. I have built a jail on this PC, following the handbook's guidelines (section: application of jails). The PC has one NIC, msk0, where I run pf on (built on my kernel; I have already tried using the module). My pf.conf is as simple as possible: # cat /etc/pf.conf nat on msk0 from any to any - 10.0.3.6 pass quick all when I jexec inside the jail, and pf is running, I am unable to reach any machine except my jail (not even the host). If pf is off, the network works just fine (of course my router knows where to find my jail's subnet). What is strange is that if I tcpdump on msk0, then after a few seconds that I request something from within the jail, I see the packets going and coming on msk0 using the correct IP (the NAT IP), but it seems that the machine fails to route them back inside the jail. My configuration is as follows: #uname -a FreeBSD filesrv.svr.noca 9.0-STABLE FreeBSD 9.0-STABLE #1: Fri Jul 27 15:40:48 EEST 2012 r...@filesrv.svr.noca:/usr/obj/usr/src/sys/MAMALOPYRINO amd64 #ifconfig -a msk0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=c011bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4,VLAN_HWTSO,LINKSTATE ether 80:ee:73:10:a3:58 inet 10.0.3.6 netmask 0xff00 broadcast 10.0.3.255 inet6 fe80::82ee:73ff:fe10:a358%msk0 prefixlen 64 scopeid 0x1 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (1000baseT full-duplex,flowcontrol,rxpause,txpause) status: active pflog0: flags=0 metric 0 mtu 33152 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL pfsync0: flags=0 metric 0 mtu 1500 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL syncpeer: 0.0.0.0 maxupd: 128 lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 options=3RXCSUM,TXCSUM inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x9 inet 127.0.0.1 netmask 0xff00 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL lo1: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 options=3RXCSUM,TXCSUM inet 10.3.2.1 netmask 0xff00 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL tap1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8LINKSTATE ether 00:bd:7b:c3:0c:01 inet6 fe80::2bd:7bff:fec3:c01%tap1 prefixlen 64 scopeid 0xb inet 10.3.2.2 netmask 0xff00 broadcast 10.3.2.255 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL tap2: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8LINKSTATE ether 00:bd:7f:c3:0c:02 inet6 fe80::2bd:7fff:fec3:c02%tap2 prefixlen 64 scopeid 0xc nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL lo3: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 options=3RXCSUM,TXCSUM inet 10.3.2.3 netmask 0xff00 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL lo3 is used as my jail interface, msk0 is my lan interface. # pciconf -v mskc0@pci0:3:0:0: class=0x02 card=0x40011297 chip=0x438011ab rev=0x10 hdr=0x00 vendor = 'Marvell Technology Group Ltd.' device = '88E8057 PCI-E Gigabit Ethernet Controller' class = network subclass = ethernet excerpt of /etc/rc.conf: jail_test_hostname=test.svr.noca jail_test_rootdir=/jails/j/test jail_test_devfs_enable=YES jail_test_ip=10.3.2.3/24 jail_test_interface=lo3 I have even enabled forwarding and fast forwarding (just in case that this had been the case) with non results. # netstat -rn Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire default10.0.3.1 UGS 0 290 msk0 10.0.3.0/24link#1 U 018825 msk0 10.0.3.6 link#1 UHS 01lo0 10.3.2.0/24link#11U 00 tap1 10.3.2.1 link#10UH 00lo1 10.3.2.2 link#11UHS 0 61lo0 10.3.2.3 link#13UH 00lo3 127.0.0.1 link#9 UH 0 64lo0 Since I don't need NAT on my configuration, I will use simple routing instead, so there won't be a problem for me. I am just sending this info in case this is a bug with pf-msk driver (for the specific card?) and before I send a bug report, I'd like a second opinion in case I am missing something fundamental. Thanx all in advance. -- George Mamalakis IT and Security Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering
Re: lock violation in unionfs (9.0-STABLE r230270)
schrieb Pavel Polyakov am 06.03.2012 11:20 (localtime): mount -t unionfs -o noatime /usr /mnt insmntque: mp-safe fs and non-locked vp: 0xfe01d96704f0 is not exclusive locked but should be KDB: enter: lock violation Pavel, can you give a spin to this patch?: http://www.freebsd.org/~attilio/unionfs_missing_insmntque_lock.patch I think that the unlocking is due at that point as the vnode lock can be switch later on. Let me know what you think about it and what the test does. Thanks! This patch fixes the problem with lock violation. Sorry I've tested it so late. Hello, this patch still applies cleanly to RELENG_9_1. Was there another fix for the issue or has it just not been PR-sent and thus forgotten? Thanks, -Harry signature.asc Description: OpenPGP digital signature
Re: lock violation in unionfs (9.0-STABLE r230270)
On 8/8/12, Harald Schmalzbauer h.schmalzba...@omnilan.de wrote: schrieb Pavel Polyakov am 06.03.2012 11:20 (localtime): mount -t unionfs -o noatime /usr /mnt insmntque: mp-safe fs and non-locked vp: 0xfe01d96704f0 is not exclusive locked but should be KDB: enter: lock violation Pavel, can you give a spin to this patch?: http://www.freebsd.org/~attilio/unionfs_missing_insmntque_lock.patch I think that the unlocking is due at that point as the vnode lock can be switch later on. Let me know what you think about it and what the test does. Thanks! This patch fixes the problem with lock violation. Sorry I've tested it so late. Hello, this patch still applies cleanly to RELENG_9_1. Was there another fix for the issue or has it just not been PR-sent and thus forgotten? There are more things to fix in inode instantiation for unionfs. I hope to make a comprehensive patch for tests in a couple of days. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein ___ 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: LSI 9240-4i 4K alignment
On Wed, Aug 8, 2012 at 10:05 AM, Jan Mikkelsen j...@transactionware.com wrote: Hi, Works fine for me with 9.0-p3 with the same controller, slight firmware differences: mfi0: 2709 (boot + 4s/0x0020/info) - Firmware version 2.120.244-1482 mfi0: 2710 (boot + 5s/0x0020/info) - Package version 20.10.1-0077 mfi0: 2711 (boot + 5s/0x0020/info) - Board Revision 04A I will be trying out 9.1-BETA on a new batch of machines next week ... Regards, Jan. Hi can you clarify if this was done using gpart and gnop? 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
freebsd 9 + zabbix 2.0
Good afternoon friends, I wanna install zabbix 2.0 on a Freebsd 9 but using ports. I read about that the ports (1.8.3) would be updated to 2.0 any news? Any one install from source without problems? tks ___ 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: LSI 9240-4i 4K alignment
Hi, On 09/08/2012, at 4:18 AM, George Kontostanos gkontos.m...@gmail.com wrote: On Wed, Aug 8, 2012 at 10:05 AM, Jan Mikkelsen j...@transactionware.com wrote: Hi, Works fine for me with 9.0-p3 with the same controller, slight firmware differences: ... Hi can you clarify if this was done using gpart and gnop? gnop on the raw disks. Before doing the gnop, there is a gpart destroy -F in the script, and dd'ing a bunch of zeros. Regards, Jan. ___ 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: Kernel panic at early boot time
I finally have some time to take a closer look at this issue. Yes, it is caused by SMI#. DragonflyBSD has tried to fix the similar problem (see http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/bb467734fc407e2c2de7f8314c63dd9f708f4df4) But Windows and Linux don't cause such problem on my machine. I compared MP initialization code between FreeBSD, Linux and NetBSD. I believe the problem is FreeBSD doesn't wait for 10ms between IPI_INIT assert and IPI_INIT deassert (though FreeBSD waits for 10ms after IPI_INIT deassert). After inserting 10ms wait time, the issue is solved. BTW, Intel's MP spec 1.4 doesn't explain very well either. Patch for AMD64 (similar change for i386 as well) Index: mp_machdep.c === --- mp_machdep.c(revision 239120) +++ mp_machdep.c(working copy) @@ -993,6 +993,8 @@ lapic_ipi_raw(APIC_DEST_DESTFLD | APIC_TRIGMOD_EDGE | APIC_LEVEL_ASSERT | APIC_DESTMODE_PHY | APIC_DELMODE_INIT, apic_id); + DELAY(1); /* wait ~10mS */ + /* wait for pending status end */ lapic_ipi_wait(-1); For comparison, 1. FreeBSD's ap_start() method: http://fxr.watson.org/fxr/source/amd64/amd64/mp_machdep.c?v=FREEBSD9#L977 2. Linux's wakeup_secondary_cpu_via_init() method: http://lxr.linux.no/linux+v3.5/arch/x86/kernel/smpboot.c#L527 3. NetBSD's x86_ipi_init() method: http://fxr.watson.org/fxr/source/arch/x86/x86/lapic.c?v=NETBSD5#L507, http://fxr.watson.org/fxr/source/arch/xen/x86/cpu.c?v=NETBSD5;im=bigexcerpts#L858 Best, On Fri, Jun 22, 2012 at 6:55 PM, mnln.l4 mnln...@gmail.com wrote: Thanks for explaining the cause! On Tue, Jun 19, 2012 at 4:54 AM, John Baldwin j...@freebsd.org wrote: On Sunday, June 17, 2012 2:35:14 pm mnln.l4 wrote: I get a kernel panic at early boot time on 9.0-stable (r237150), GENERIC, AMD64. Repro step: 1. Boot, wait for welcome screen. 2. Repeat pressing Enter key rapidly (so kernel is loading, don't stop pressing Enter key). 3. See the following message at early boot So don't do that. All your key presses are triggering SMI# events that are interfering with the AP's ability to respond to its startup IPI. There is nothing we can do about this in the OS. -- John Baldwin ___ 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: pf nat fails on msk0 from packets deriving from a jail interface
On Wed, Aug 08, 2012 at 02:33:25PM +0300, George Mamalakis wrote: Hi all, Suddenly I am facing a problem on a new PC, using a configuration that I have been using on more than 10 servers for the last few years. The only thing that I find that differs from my other configuratinos is the NIC of the PC. If not, I must be missing something very trivial. I have built a jail on this PC, following the handbook's guidelines (section: application of jails). The PC has one NIC, msk0, where I run pf on (built on my kernel; I have already tried using the module). My pf.conf is as simple as possible: # cat /etc/pf.conf nat on msk0 from any to any - 10.0.3.6 pass quick all when I jexec inside the jail, and pf is running, I am unable to reach any machine except my jail (not even the host). If pf is off, the network works just fine (of course my router knows where to find my jail's subnet). What is strange is that if I tcpdump on msk0, then after a few seconds that I request something from within the jail, I see the packets going and coming on msk0 using the correct IP (the NAT IP), but it seems that the machine fails to route them back inside the jail. I guess this is the same issue reported in kern/170081. Some msk(4) controllers lack full hardware checksum offloading capability such that pseudo checksum should be computed by upper layer. It seems pf(4) NAT was broken for controllers that lack pseudo checksumming. This indicates the following ethernet controller do not work with pf(4) NAT. sk(4), msk(4), fxp(4), hme(4) and gem(4) Try disabling RX checksum offloading as a work-around. #ifconfig msk0 -rxcsum ___ 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
