Re: lock violation in unionfs (9.0-STABLE r230270)
schrieb Attilio Rao am 02.11.2012 15:21 (localtime):
On Wed, Oct 31, 2012 at 11:11 AM, Harald Schmalzbauer
h.schmalzba...@omnilan.de wrote:
schrieb Attilio Rao am 29.10.2012 23:02 (localtime):
On Mon, Oct 29, 2012 at 7:37 PM, Harald Schmalzbauer
h.schmalzba...@omnilan.de wrote:
schrieb Attilio Rao am 27.10.2012 23:07 (localtime):
On Sat, Oct 27, 2012 at 9:46 PM, Attilio Rao atti...@freebsd.org wrote:
On Sat, Sep 8, 2012 at 12:48 AM, Attilio Rao atti...@freebsd.org wrote:
On Thu, Sep 6, 2012 at 4:52 PM, Harald Schmalzbauer
h.schmalzba...@omnilan.de wrote:
schrieb Attilio Rao am 09.08.2012 20:26 (localtime):
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?
Can you and Pavel try the attached patch? Unfortunately I had no time
to test it, I just made in 5 free mins from a non-FreeBSD workstation,
Sorry, couldn't test earlier, but now I did:
With this patch applied the machine hangs without debug kernel and the
latter gives the following panic:
System call nmount returning with the following locks held:
exclusive lockmgr ufs (ufs) r = 0 (0xc5438278) locked @
src/sys/fs/unionfs/union_vnops.c:1938
panic: witness_warn
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper(c0a04f7f,c0c112c4,d1de3bb4,c097aa8c,fc,...) at
db_trace_self_wrapper+0x26
kdb_backtrace(c0a4965f,0,c09c2ede3c1c,0,...) at kdb_backtrace+0x2a
witness_warn(2,0,c0a4ac34,c0a0990a,286,...) at witness_warn+0x1e4
syscall(d1de3d08) ar syscall+0x415
Xint0x80_syscall() at Xint0x80_syscall+0x21
--- syscall (0, FreeBSD ELF32, nosys), eip = 0x280b883f,esp =
0xbfbfe46c, ebp = 0xbfbfede8 ---
KDB: enter: panic
[ thread pid 86 tid 100054 ]
Stopped adkdb_enter+0x3a: movl $0,kdb_why
db bt
Tracing pid 86 tid 100054 td 0xc541b000
kdb_enter(c0a00d16,c0a09130,0,0,0,...) at panix+0x190
witness_warn(2,0,x0a4ac34,c0a0990a,286,...) at witness_warn+0x1e4
syscall(d1de3d08) at syscall+0x415
Xint0x80_syscall() at Xint0x80_syscall+0x21
Hmm, I guess I forgot to install kernel debug symbols...
Coming back if I have more
Unfortunately unionfs does very wrong things with the insmntque()
locking.
It basically expects the vnode to return locked in the same way
requested by the precedent namei() (when that happens) but when you do
insmntque() you can only have an LK_EXCLUSIVE lock on the vnode.
Hello,
the following patch should workout the issues around unionfs_nodeget() a
bit:
http://www.freebsd.org/~attilio/unionfs_nodeget2.patch
Unfortunately unionfs code is rather messy in the lookup path about
locking requirements so follow what it needs to be done there is a bit
difficult.
I have no way to test this patch, so it is just test-compiled at the
moment, but I would need that you also test lookup path (so directory
ls, find(1) on the whole unionfs volume, etc.) to validate it
someway.
On a second thought, I think that locking in lookup (and also other
operations) is so fragile and difficult to follow that it makes all
vnops real locking landmines.
I think that the following patch fixes the insmntque insertion and
follows the old approach well enough to be committed separately:
http://www.freebsd.org/~attilio/unionfs_nodeget3.patch
Unfortunately I have no idea about all those locking strategies and
implementations.
Applying unionfs_nodeget3.patch results in:
sys/fs/unionfs/union_subr.c: In function 'unionfs_nodeget':
sys/fs/unionfs/union_subr.c:332: error: expected statement
before ')' token
*** [union_subr.o] Error code 1
I guess there is a typo in this chunk:
@@ -317,11 +328,11 @@ unionfs_nodeget(struct mount *mp, struct vnode *up
vref(vp);
} else
*vpp = vp;
-
-unionfs_nodeget_out:
- if (lkflags LK_TYPE_MASK)
- vn_lock(vp, lkflags | LK_RETRY);
-
+ if (lkflags LK_TYPE_MASK) {
+ if (lkflags == LK_SHARED))
^
+ vn_lock(vp, LK_DOWNGRADE | LK_RETRY);
+ } else
+ VOP_UNLOCK(vp, LK_RELEASE);
return (0);
}
After removing the second right parenthesis kernel compiles.
But it still crashes:
panic: Lock (lockmgr) ufs not locked @ sys/kern/vfs_default.c:512
freebsd-update and surces of 9.1-RC3
Hi! I'm trying to use freebsd-update for first time. I have 9.0-RELEASE installed without sources and I have read Handbook chapter and manual page for freebsd-update. freebsd-update -r 9.1-RC3 upgrade downloaded updates, its install command installed kernel and after reboot second install invocation installed binaries but not source tree that is needed to add IPSEC support to the kernel. Now it says: # freebsd-update -r 9.1-RC3 upgrade freebsd-update: Cannot upgrade from 9.1-RC3 to itself How do I make freebsd-update to download and install sources for 9.1-RC3 so I could rebuild custom kernel? Eugene Grosbein ___ 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: [patch] Re: SU+J on 9.1-RC2 ISO
On Fri, 2 Nov 2012 20:00:27 +0100 Bas Smeelen b.smee...@ose.nl wrote: Though the last 10 years I have not had the inconvenience of having to deal with long fsck' s or bgfsck' s on servers or workstation installs, so I think this should not be default on new installs. This is one man's opinion. On the other hand, SUJ by default is a godsend for me because of the number of crashes/fscks I've been dealing with. ___ 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: SU+J on 9.1-RC2 ISO
On Fri, 2 Nov 2012 23:13:43 +0100 Bas Smeelen b.smee...@ose.nl wrote: I have submitted a PR with patch, see how it goes Cheers Why aren't we patching the dump utility to error/exit saying it's not compatible with SUJ at this time? Update the descriptions in the installer, but leave SUJ as default and patch dump. ___ 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: SU+J on 9.1-RC2 ISO
On Sat, Nov 3, 2012 at 10:10 AM, Mark Felder f...@feld.me wrote: On Fri, 2 Nov 2012 23:13:43 +0100 Bas Smeelen b.smee...@ose.nl wrote: I have submitted a PR with patch, see how it goes Cheers Why aren't we patching the dump utility to error/exit saying it's not compatible with SUJ at this time? Update the descriptions in the installer, but leave SUJ as default and patch dump. If I understood Mateusz correctly, r230725 already took care of the panic, so there is no need to modify dump. That, however, still doesn't solve all problems: http://lists.freebsd.org/pipermail/freebsd-questions/2012-November/246069.html - Max ___ 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: [patch] Re: SU+J on 9.1-RC2 ISO
On Sat, 2012-11-03 at 09:08 -0500, Mark Felder wrote: On Fri, 2 Nov 2012 20:00:27 +0100 Bas Smeelen b.smee...@ose.nl wrote: Though the last 10 years I have not had the inconvenience of having to deal with long fsck' s or bgfsck' s on servers or workstation installs, so I think this should not be default on new installs. This is one man's opinion. On the other hand, SUJ by default is a godsend for me because of the number of crashes/fscks I've been dealing with. So SUJ has been a godsend for you. I don't see anything in your statement that supports it being the default. Given how much trouble it has been for people in the past, I don't plan to embrace journaling any faster than I embraced softupdates originally. That is to say, it will be years before I use it. I suspect my attitude on this isn't all that uncommon, and is likely the explanation for why things increasingly become the default before their time these days. Developers are motivated to push new features into wide use quickly, because that gets the new features lots of testing. Prudent users aren't interested in being guinea pigs, and will push back. -- Ian ___ 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: SU+J on 9.1-RC2 ISO
On Sat, 3 Nov 2012 10:18:55 -0400 Maxim Khitrov m...@mxcrypt.com wrote: If I understood Mateusz correctly, r230725 already took care of the panic, so there is no need to modify dump. That, however, still doesn't solve all problems: http://lists.freebsd.org/pipermail/freebsd-questions/2012-November/246069.html Interesting... well, a big warning in the installer should be sufficient I'd hope ___ 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.1 stability/robustness?
On Nov 2, 2012, at 3:15 PM, Rainer Duffner rai...@ultra-secure.de wrote: Am Fri, 2 Nov 2012 13:34:20 -0400 schrieb Mark Saad nones...@longcount.org: On Nov 2, 2012, at 4:10 AM, Rainer Duffner rai...@ultra-secure.de wrote: Am Thu, 1 Nov 2012 20:14:51 -0600 (MDT) schrieb Brett Glass br...@lariat.net: I need to build up a few servers and routers, and am wondering how FreeBSD 9.1 is shaping up. Will it be likely to be more stable and robust than 9.0-RELEASE? Are there issues that will have to wait until 9.2-RELEASE to be fixed? Opinions welcome. If I'm not mistaken, the bge-stuff that makes the default NICs ins HP G8 servers (360+380) actually run will not make it back into 9.1. Intel cards work much better anyway... Did you swap out the bge nic daughter card in the g8 servers for an intel one or , do you mean in general the intel nic support is better ? Both, actually. At least, Intel has drivers for FreeBSD on their website and IIRC, it's a Tier 1 OS for them. I don't want to dis the efforts of the people working on the bXe stuff, but from what I have read, they have much less support from the vendor. We have used HP servers even back when they were still Compaq-servers (and came with Intel NICs...) and this is really the first time we had to install Intel NICs with them (with FreeBSD - there was an earlier issue with Solaris, but that does not count...). Are there Intel daughter cards for this server? I thought, all the daugher-cards came with some sort of Broadcom chipset. Hp did a presentation at work 2 weeks ago about the g8 . Hp said you can swap out a daughter card in the 360/380/580 for nic options like broadcom 4 port gigabit nic , melenox infinbabd, intel pro1000 4 port nic , qlogic 8Gb fc-al and others . They said its an FRU but I have not seen the parts yet . --- Mark saad | mark.s...@longcount.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
Re: SU+J on 9.1-RC2 ISO
I still use 8 and plan to install branch 9 on new laptop with ssd. If journaling comes as default on 9.1, I plan to accept defaults on partitioning and use tunefs to remove it with -h disable. Any idea what steps should I take for that? As far as I read, journaling uses it's own partitions. Do I have to remove them, resize them? Branch 8 had option to choose su and j during install. I tried to find proper tutorials/manuals, but lacked to re- solve it in my head. Best regards all Zoran ___ 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-update and surces of 9.1-RC3
Eugene Grosbein eugen at grosbein.net writes: Hi! I'm trying to use freebsd-update for first time. I have 9.0-RELEASE installed without sources and I have read Handbook chapter and manual page for freebsd-update. ... How do I make freebsd-update to download and install sources for 9.1-RC3 so I could rebuild custom kernel? ... You did not get src updated because you did not have it before. Because there was no official announcement, I can give you a link (similar to one for -RC2), from which you can get the sources src.txz: ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/i386/9.1-RC3/ Be sure to check download's signature in MANIFEST file. After that: - make backup of anything you got in /usr/src, and remove that dir # rm -rf /usr/src - unpack downloaded file locally into /usr/src dir (that destination dir is a default) jb ___ 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-update and sources of 9.1-RC3
03.11.2012 22:44, jb пишет: Eugene Grosbein eugen at grosbein.net writes: Hi! I'm trying to use freebsd-update for first time. I have 9.0-RELEASE installed without sources and I have read Handbook chapter and manual page for freebsd-update. ... How do I make freebsd-update to download and install sources for 9.1-RC3 so I could rebuild custom kernel? ... You did not get src updated because you did not have it before. Because there was no official announcement, I can give you a link (similar to one for -RC2), from which you can get the sources src.txz: ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/i386/9.1-RC3/ Be sure to check download's signature in MANIFEST file. After that: - make backup of anything you got in /usr/src, and remove that dir # rm -rf /usr/src - unpack downloaded file locally into /usr/src dir (that destination dir is a default) jb Thanks, I've already done that :-) My real question is how make freebsd-update download sources they are not installed? ___ 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-update and sources of 9.1-RC3
Eugene Grosbein eugen at grosbein.net writes: ... My real question is how make freebsd-update download sources they are not installed? I am not 110% sure, but you can not. When freebsd-update runs, it checks its config file /etc/freebsd-update.conf and then takes inventory of your system (that's why it is called update, and that's why you do not get new src set). FREEBSD-UPDATE(8) does not give any override option. So, here you are. But next time (assuming you keep your src) you will be fine. jb ___ 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: SU+J on 9.1-RC2 ISO
Zoran Kolic zkolic at sbb.rs writes: I still use 8 and plan to install branch 9 on new laptop with ssd. If journaling comes as default on 9.1, I plan to accept defaults on partitioning and use tunefs to remove it with -h disable. Any idea what steps should I take for that? As far as I read, journaling uses it's own partitions. Do I have to remove them, resize them? Branch 8 had option to choose su and j during install. I tried to find proper tutorials/manuals, but lacked to re- solve it in my head. Best regards all If you manage to disable it during install configuration (shell access) but before actual system installation, there is nothing else to do. If you install a partition with su+j, then as tunefs(8) says, you have to have your partition unmounted or ro to disable J. But before doing that, you should run 'fsck' on that partition to have (select) journal played itself empty. Btw, any J partition has .sujournal file, e.g. # ls -al /.sujournal You can get rid of it then. jb ___ 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.1 stability/robustness?
Am Sat, 3 Nov 2012 11:06:26 -0400 schrieb Mark Saad nones...@longcount.org: Hp did a presentation at work 2 weeks ago about the g8 . Hp said you can swap out a daughter card in the 360/380/580 for nic options like broadcom 4 port gigabit nic , melenox infinbabd, intel pro1000 4 port nic , qlogic 8Gb fc-al and others . I've heard that, too (was on holiday when the sales-guy was here) They said its an FRU but I have not seen the parts yet . The quickspecs make no mention of it: http://h18000.www1.hp.com/products/quickspecs/14212_na/14212_na.html Only that 331FLR adapter, with contains that beloved BCM-chip. http://h18000.www1.hp.com/products/quickspecs/14214_div/14214_div.HTML Or one of the 10G adapters. But 10G is probably worse - and we don't have any 10G switch-ports anyway With the infiniband-stuff, they are probably waiting for the first customer to order a couple of thousand so they can do a profitable one-off production run... ___ 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: SU+J on 9.1-RC2 ISO
(Please keep me CC'd, as I'm not subscribed to -stable) I've CC'd Nathan Whitehorn, who according to bsdinstall(8) is the author (not sure if maintainer) of the code. This default has already begun to bite users/SAs in the ass: http://lists.freebsd.org/pipermail/freebsd-questions/2012-November/246069.html SU+J (the journalling part specifically) needs to be disabled by default in the installer. This default was a very bad choice and should not have been done. It either indicates someone was out of touch with the rest of the issues surrounding the feature, or that someone intentionally decided it's the best way to get people using it for testing (I have seen this justification presented in the past, and it is the wrong approach). However, since some people DO want it (and those folks don't use dump), the installer should be modified to make SU+J support toggleable via a a checkbox. The default, obviously, should be unchecked. If the user checks the checkbox, an ominous warning message should be displayed informing the user of the repercussions. The only option at that point should be OK, after which the checkbox is checked. Do not tell me send patches. This issue/problem has gone on long enough, and the community bitched hard/long enough, that the person who committed this default should be responsible for fixing it. We should operate under the assumption that this bug/problem will never be fixed. It probably will be, but again, we must operate with the assumption that Kirk et al will require years to fix it. (It has already been something like 9 months. Or is it a year?) While I'm here -- does anyone remember the exact commit which was done sometime in the past 6-9 months which made the installer work properly with SSDs (re: partition alignment)? I have questions about that; if I remember right, someone set the alignment size to 4KBytes, and that is completely 100% wrong -- it needs to be 1MByte or 2MBytes if you want to be extra cautious, which correlates with NAND erase block size, otherwise we're not really solving jack squat. -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Mountain View, CA, US| | Making life hard for others since 1977. PGP 4BD6C0CB | ___ 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
kvm vlan virtio problem
hi, i have several kvm ubuntu 12.04 and centos 6 hosts with standard bridged network setup. same problem on each server with freebsd 9 amd64 guest and virtio nic: soon after guest start host syslog is filling with this message at very high rate. guest is working without any problem. with e1000 guest driver eveything is ok. does enyone have/had same problem? thanks. kernel: [2337728.094141] [ cut here ] kernel: [2337728.094144] WARNING: at /build/buildd/linux-3.2.0/net/core/dev.c:1955 skb_gso_segment+0x341/0x3b0() kernel: [2337728.094146] Hardware name: System x3550 M3 -[7944K3G]- kernel: [2337728.094148] 802.1Q VLAN Support: caps=(0x30195833, 0x0) len=3196 data_len=0 ip_summed=0 kernel: [2337728.094149] Modules linked in: dm_snapshot ip6table_filter ip6_tables ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp iptable_filter ip_tables x_tables kvm_intel kvm dm_crypt nfsd nfs lockd fscache auth_rpcgss nfs_acl sunrpc nls_iso8859_1 nls_cp437 vfat fat 8021q garp bridge stp serio_raw cdc_ether usbnet vhost_net macvtap i7core_edac macvlan shpchp ioatdma edac_core dca tpm_tis lp parport mac_hid btrfs zlib_deflate libcrc32c usbhid hid megaraid_sas bnx2 kernel: [2337728.094177] Pid: 8685, comm: vhost-8683 Tainted: G W3.2.0-31-generic #50-Ubuntu kernel: [2337728.094179] Call Trace: kernel: [2337728.094180] IRQ [81066d7f] warn_slowpath_common+0x7f/0xc0 kernel: [2337728.094185] [81066e76] warn_slowpath_fmt+0x46/0x50 kernel: [2337728.094188] [8153f581] skb_gso_segment+0x341/0x3b0 kernel: [2337728.094191] [81542ee1] dev_hard_start_xmit+0xc1/0x540 kernel: [2337728.094196] [a01c0150] ? br_flood+0xc0/0xc0 [bridge] kernel: [2337728.094199] [8154360a] dev_queue_xmit+0x2aa/0x420 kernel: [2337728.094203] [a01c01e2] br_dev_queue_push_xmit+0x92/0xd0 [bridge] kernel: [2337728.094208] [a01c0278] br_forward_finish+0x58/0x60 [bridge] kernel: [2337728.094212] [a01c042b] __br_forward+0xab/0xd0 [bridge] kernel: [2337728.094217] [a01c04ed] br_forward+0x5d/0x70 [bridge] kernel: [2337728.094221] [a01c11c2] br_handle_frame_finish+0x182/0x2a0 [bridge] kernel: [2337728.094226] [a01c14a8] br_handle_frame+0x1c8/0x270 [bridge] kernel: [2337728.094231] [a01c12e0] ? br_handle_frame_finish+0x2a0/0x2a0 [bridge] kernel: [2337728.094234] [81540892] __netif_receive_skb+0x1e2/0x520 kernel: [2337728.094237] [81540ff1] process_backlog+0xb1/0x190 kernel: [2337728.094240] [815422e4] net_rx_action+0x134/0x290 kernel: [2337728.094242] [8165a4fe] ? _raw_spin_lock+0xe/0x20 kernel: [2337728.094245] [8106e528] __do_softirq+0xa8/0x210 kernel: [2337728.094248] [81664d6c] call_softirq+0x1c/0x30 kernel: [2337728.094249] EOI [81015305] do_softirq+0x65/0xa0 kernel: [2337728.094254] [815427c8] netif_rx_ni+0x28/0x30 kernel: [2337728.094258] [81478ec6] tun_get_user+0x306/0x4a0 kernel: [2337728.094261] [81479085] tun_sendmsg+0x25/0x30 kernel: [2337728.094265] [a01b09b6] handle_tx+0x296/0x530 [vhost_net] kernel: [2337728.094269] [a01b0c85] handle_tx_kick+0x15/0x20 [vhost_net] kernel: [2337728.094273] [a01ade3d] vhost_worker+0xdd/0x170 [vhost_net] kernel: [2337728.094276] [a01add60] ? vhost_set_memory+0x130/0x130 [vhost_net] kernel: [2337728.094279] [8108a03c] kthread+0x8c/0xa0 kernel: [2337728.094282] [81664c74] kernel_thread_helper+0x4/0x10 kernel: [2337728.094285] [81089fb0] ? flush_kthread_worker+0xa0/0xa0 kernel: [2337728.094287] [81664c70] ? gs_change+0x13/0x13 kernel: [2337728.094289] ---[ end trace a38cf088269411b3 ]--- kernel: [2337728.094731] [ cut here ] ___ 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.1-RC3 Available...
The third release candidate of the 9.1-RELEASE release cycle is now available on the FTP servers for amd64, i386, powerpc64, and sparc64. The MD5/SHA256 checksums are at the bottom of this message. The ISO images and, for architectures that support it, the memory stick images are available here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/9.1/ (or any of the FreeBSD mirror sites). This is expected to be the last Release Candidate. Unless a major show-stopper is discovered within the next few days the final Release Builds will be started. If you notice any problems you can report them through the normal Gnats PR system or here on the -stable mailing list. If you want to do a source-based update to an existing system using SVN the branch to use is releng/9.1. If you would like to use CVS instead use RELENG_9_1. The freebsd-update(8) utility supports binary upgrades of i386 and amd64 systems running earlier FreeBSD releases. Systems running 9.0-RELEASE, 9.1-BETA1, 9.1-RC1, or 9.1-RC2 can upgrade as follows: # freebsd-update upgrade -r 9.1-RC3 During this process, FreeBSD Update may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components, and the system needs to be rebooted again: # freebsd-update install # shutdown -r now Users of earlier FreeBSD releases (FreeBSD 7.X, 8.X) can also use freebsd-update to upgrade to FreeBSD 9.1-RC3, but will be prompted to rebuild all third-party applications (e.g., anything installed from the ports tree) after the second invocation of freebsd-update install, in order to handle differences in the system libraries between FreeBSD 7.X or FreeBSD 8.X and FreeBSD 9.X. Checksums: SHA256 (FreeBSD-9.1-RC3-amd64-bootonly.iso) = 86d57e699ae0e298a420ff168e6abe7b715e6dee8350149ed2f230885b1973ec SHA256 (FreeBSD-9.1-RC3-amd64-disc1.iso) = 11c7e4ab16294794bf950073901f9a4dc8f735de08b02a321b63c4702af60f98 SHA256 (FreeBSD-9.1-RC3-amd64-memstick.img) = ccd983a7e1f37c0bb4b87c6cacc3945d38be8add66ea0689c0b8e0a72c75ad58 MD5 (FreeBSD-9.1-RC3-amd64-bootonly.iso) = 278a0ee9e00dba88068f1ad1c509429c MD5 (FreeBSD-9.1-RC3-amd64-disc1.iso) = 78ea831eaf495e2f713d5cd5ffc5f083 MD5 (FreeBSD-9.1-RC3-amd64-memstick.img) = f37c7ff68025bc065465d3d647b6e7e0 SHA256 (FreeBSD-9.1-RC3-i386-bootonly.iso) = 8b944a3b263de04db2e0cb38b068a4ceca6e2fe4f8af5344567696e09b7df66a SHA256 (FreeBSD-9.1-RC3-i386-disc1.iso) = e7c19e2aadb0c6ce072265511d84fd0d39c6e60628231d8dc31023d410e285d6 SHA256 (FreeBSD-9.1-RC3-i386-memstick.img) = 1ebb2ebf6b20376df7c3719f5b1bbbdd47ae2054e3a23019d8fdc93734f78fe5 MD5 (FreeBSD-9.1-RC3-i386-bootonly.iso) = f14703b350e7f2357d23250c64ef MD5 (FreeBSD-9.1-RC3-i386-disc1.iso) = 13405032579c52182bedfcd84a294871 MD5 (FreeBSD-9.1-RC3-i386-memstick.img) = 515d0866470d2edd1d99867e83387c35 SHA256 (FreeBSD-9.1-RC3-powerpc64-bootonly.iso) = b46212dc2fa3308fc58465bb999b4ec857245826fd1cb122af758e8b340afaf4 SHA256 (FreeBSD-9.1-RC3-powerpc64-memstick) = bfda2bf019eb4c540d280608a81ba9d67402ab0248c38c33badb4548e725f657 SHA256 (FreeBSD-9.1-RC3-powerpc64-release.iso) = b5e0948df8d7f62a7e620647d90c3c47f89ad71cf310277d86ef139c8ba25961 MD5 (FreeBSD-9.1-RC3-powerpc64-bootonly.iso) = d474edb9aac9aa5e9ad226a1e345cbd9 MD5 (FreeBSD-9.1-RC3-powerpc64-memstick) = aa443c1ae88773cc6c0a070ca2c6784f MD5 (FreeBSD-9.1-RC3-powerpc64-release.iso) = 237aaf75f2f6b2192cf0e1f51c190dc8 SHA256 (FreeBSD-9.1-RC3-sparc64-bootonly.iso) = e1d61b01ba8d03c324f0a828527741542fd0b337d3281b1f943658f5f482ae9e SHA256 (FreeBSD-9.1-RC3-sparc64-disc1.iso) = 9b59c368f0572198ef9562c7f52a45ca33aa832d607c6331bd4ca796c5ca4d8f MD5 (FreeBSD-9.1-RC3-sparc64-bootonly.iso) = e3e10bc7ce2a0377053cb2d7eff22538 MD5 (FreeBSD-9.1-RC3-sparc64-disc1.iso) = ab754ee5361a4c9b8d451b0eee080732 -- Ken Smith - From there to here, from here to | kensm...@buffalo.edu there, funny things are everywhere. | - Theodore Geisel | signature.asc Description: This is a digitally signed message part
Re: kvm vlan virtio problem
Hi, - Original Message - From: Bane Ivosev bane.ivo...@pmf.uns.ac.rs To: freebsd-stable@freebsd.org Sent: Saturday, November 3, 2012 2:12:25 PM Subject: kvm vlan virtio problem hi, i have several kvm ubuntu 12.04 and centos 6 hosts with standard bridged network setup. same problem on each server with freebsd 9 amd64 guest and virtio nic: soon after guest start host syslog is filling with this message at very high rate. guest is working without any problem. with e1000 guest driver eveything is ok. does enyone have/had same problem? thanks. I have a vague recollection of looking at something similar last year... Do you have VLAN configured in the guest as well? What is the ifconfig output? Does disabling TSO on the vtnetX device make these messages go away? Bryan kernel: [2337728.094141] [ cut here ] kernel: [2337728.094144] WARNING: at /build/buildd/linux-3.2.0/net/core/dev.c:1955 skb_gso_segment+0x341/0x3b0() kernel: [2337728.094146] Hardware name: System x3550 M3 -[7944K3G]- kernel: [2337728.094148] 802.1Q VLAN Support: caps=(0x30195833, 0x0) len=3196 data_len=0 ip_summed=0 kernel: [2337728.094149] Modules linked in: dm_snapshot ip6table_filter ip6_tables ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp iptable_filter ip_tables x_tables kvm_intel kvm dm_crypt nfsd nfs lockd fscache auth_rpcgss nfs_acl sunrpc nls_iso8859_1 nls_cp437 vfat fat 8021q garp bridge stp serio_raw cdc_ether usbnet vhost_net macvtap i7core_edac macvlan shpchp ioatdma edac_core dca tpm_tis lp parport mac_hid btrfs zlib_deflate libcrc32c usbhid hid megaraid_sas bnx2 kernel: [2337728.094177] Pid: 8685, comm: vhost-8683 Tainted: G W3.2.0-31-generic #50-Ubuntu kernel: [2337728.094179] Call Trace: kernel: [2337728.094180] IRQ [81066d7f] warn_slowpath_common+0x7f/0xc0 kernel: [2337728.094185] [81066e76] warn_slowpath_fmt+0x46/0x50 kernel: [2337728.094188] [8153f581] skb_gso_segment+0x341/0x3b0 kernel: [2337728.094191] [81542ee1] dev_hard_start_xmit+0xc1/0x540 kernel: [2337728.094196] [a01c0150] ? br_flood+0xc0/0xc0 [bridge] kernel: [2337728.094199] [8154360a] dev_queue_xmit+0x2aa/0x420 kernel: [2337728.094203] [a01c01e2] br_dev_queue_push_xmit+0x92/0xd0 [bridge] kernel: [2337728.094208] [a01c0278] br_forward_finish+0x58/0x60 [bridge] kernel: [2337728.094212] [a01c042b] __br_forward+0xab/0xd0 [bridge] kernel: [2337728.094217] [a01c04ed] br_forward+0x5d/0x70 [bridge] kernel: [2337728.094221] [a01c11c2] br_handle_frame_finish+0x182/0x2a0 [bridge] kernel: [2337728.094226] [a01c14a8] br_handle_frame+0x1c8/0x270 [bridge] kernel: [2337728.094231] [a01c12e0] ? br_handle_frame_finish+0x2a0/0x2a0 [bridge] kernel: [2337728.094234] [81540892] __netif_receive_skb+0x1e2/0x520 kernel: [2337728.094237] [81540ff1] process_backlog+0xb1/0x190 kernel: [2337728.094240] [815422e4] net_rx_action+0x134/0x290 kernel: [2337728.094242] [8165a4fe] ? _raw_spin_lock+0xe/0x20 kernel: [2337728.094245] [8106e528] __do_softirq+0xa8/0x210 kernel: [2337728.094248] [81664d6c] call_softirq+0x1c/0x30 kernel: [2337728.094249] EOI [81015305] do_softirq+0x65/0xa0 kernel: [2337728.094254] [815427c8] netif_rx_ni+0x28/0x30 kernel: [2337728.094258] [81478ec6] tun_get_user+0x306/0x4a0 kernel: [2337728.094261] [81479085] tun_sendmsg+0x25/0x30 kernel: [2337728.094265] [a01b09b6] handle_tx+0x296/0x530 [vhost_net] kernel: [2337728.094269] [a01b0c85] handle_tx_kick+0x15/0x20 [vhost_net] kernel: [2337728.094273] [a01ade3d] vhost_worker+0xdd/0x170 [vhost_net] kernel: [2337728.094276] [a01add60] ? vhost_set_memory+0x130/0x130 [vhost_net] kernel: [2337728.094279] [8108a03c] kthread+0x8c/0xa0 kernel: [2337728.094282] [81664c74] kernel_thread_helper+0x4/0x10 kernel: [2337728.094285] [81089fb0] ? flush_kthread_worker+0xa0/0xa0 kernel: [2337728.094287] [81664c70] ? gs_change+0x13/0x13 kernel: [2337728.094289] ---[ end trace a38cf088269411b3 ]--- kernel: [2337728.094731] [ cut here ] ___ 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
Why is SU+J undesirable on SSDs?
Have been following the thread related to SU+J, and am wondering: why is it considered to be undesirable on SSDs (assuming that they have good wear leveling)? I have been enabling it on systems with SSDs, hoping that between the lack of rotating media and the journaling I would have very robust systems. --Brett Glass ___ 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: Why is SU+J undesirable on SSDs?
On Sat, Nov 3, 2012 at 4:30 PM, Brett Glass br...@lariat.net wrote: Have been following the thread related to SU+J, and am wondering: why is it considered to be undesirable on SSDs (assuming that they have good wear leveling)? Superstition -- Adam Vande More ___ 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: Why is SU+J undesirable on SSDs?
On Sat, 3 Nov 2012, Brett Glass wrote: Have been following the thread related to SU+J, and am wondering: why is it considered to be undesirable on SSDs (assuming that they have good wear leveling)? I have been enabling it on systems with SSDs, hoping that between the lack of rotating media and the journaling I would have very robust systems. I know of no reason to support this notion. Although SSDs are so fast you might be happy to wait for the fsck time in exchange for snapshots. Jeff --Brett Glass ___ 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
Re: Why is SU+J undesirable on SSDs?
On Sat, 3 Nov 2012, Karl Denninger wrote: On 11/3/2012 5:25 PM, Jeff Roberson wrote: On Sat, 3 Nov 2012, Brett Glass wrote: Have been following the thread related to SU+J, and am wondering: why is it considered to be undesirable on SSDs (assuming that they have good wear leveling)? I have been enabling it on systems with SSDs, hoping that between the lack of rotating media and the journaling I would have very robust systems. I know of no reason to support this notion. Although SSDs are so fast you might be happy to wait for the fsck time in exchange for snapshots. Jeff It is utter insanity to enable, by default, filesystem options that break the canonical backup solution in the handbook (dump, when used with -L, which it must be to dump a live filesystem SAFELY.) I did not enable it by default but it makes sense for desktop users who are probably not often using dump/restore. I agree that the option should be covered in more detail. IMHO either snapshots with journaling needs to be fixed, some other canonical and reasonably-implemented means of backups that actually works and is as robust as dump must be made available, tested and documented at the level that dump has been (good luck with that!) or +J has to be removed as the default. We are hopefully fixing snapshots in current and I would expect it to be ready for backport in the 9.2 timeframe. It is next on the list after we fix the drive write cache problem for mobile users who may lose power frequently. I love progress as much as the next guy but my first requirement for an operating system is that it not irretrievably lose my data. I hear your frustrations but please try to express it more productively in the future. Thanks, Jeff -- -- Karl Denninger The Market Ticker (R) Cuda Systems LLC ___ 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: Why is SU+J undesirable on SSDs?
On Sat, 2012-11-03 at 17:06 -0500, Adam Vande More wrote: On Sat, Nov 3, 2012 at 4:30 PM, Brett Glass br...@lariat.net wrote: Have been following the thread related to SU+J, and am wondering: why is it considered to be undesirable on SSDs (assuming that they have good wear leveling)? Superstition Yeah, that's what it must be. Or... it could be well-informed choice. Journaling increases the number of writes. That puts wear on any disk, mechanical or SSD, and it takes time. What it buys you is better performance if you get into a crash recovery situation. It's perfectly reasonable for someone to make the decision that their SSD can finish an fsck so fast that there's no point in paying any penalty for the extra writes for journaling. I have a 256G SSD here with about 200G of data on it, and fsck without journaling takes about 3 minutes. I can live with that. With more data or a slower drive I might make a different choice. -- Ian ___ 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: Why is SU+J undesirable on SSDs?
On 11/3/2012 5:25 PM, Jeff Roberson wrote: On Sat, 3 Nov 2012, Brett Glass wrote: Have been following the thread related to SU+J, and am wondering: why is it considered to be undesirable on SSDs (assuming that they have good wear leveling)? I have been enabling it on systems with SSDs, hoping that between the lack of rotating media and the journaling I would have very robust systems. I know of no reason to support this notion. Although SSDs are so fast you might be happy to wait for the fsck time in exchange for snapshots. Jeff It is utter insanity to enable, by default, filesystem options that break _*the canonical backup solution*_ in the handbook (dump, when used with -L, which it must be to dump a live filesystem SAFELY.) IMHO either snapshots with journaling needs to be fixed, some other canonical and reasonably-implemented means of backups that actually works and is as robust as dump must be made available, tested and documented at the level that dump has been (good luck with that!) _*or*_ +J has to be removed as the default. I love progress as much as the next guy but my first requirement for an operating system is that it not irretrievably lose my data. -- -- Karl Denninger /The Market Ticker ®/ http://market-ticker.org Cuda Systems LLC ___ 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: Why is SU+J undesirable on SSDs?
At 04:32 PM 11/3/2012, Karl Denninger wrote: It is utter insanity to enable, by default, filesystem options that break the canonical backup solution in the handbook (dump, when used with -L, which it must be to dump a live filesystem SAFELY.) I have not used dump in many, many years. So, I hope the installer will not make it difficult for me to turn on SU+J despite the problem you mention above. That being said, dump should obviously be fixed to work with SU+J. Perhaps there could be a workaround (e.g. synchronizing the file system and temporarily turning off journaling during a backup) that would eliminate the need to turn SU+J off all the time while a more graceful fix is being readied. --Brett ___ 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: Why is SU+J undesirable on SSDs?
On Sat, 3 Nov 2012, Ian Lepore wrote: On Sat, 2012-11-03 at 17:06 -0500, Adam Vande More wrote: On Sat, Nov 3, 2012 at 4:30 PM, Brett Glass br...@lariat.net wrote: Have been following the thread related to SU+J, and am wondering: why is it considered to be undesirable on SSDs (assuming that they have good wear leveling)? Superstition Yeah, that's what it must be. Or... it could be well-informed choice. Journaling increases the number of writes. That puts wear on any disk, mechanical or SSD, and it takes time. What it buys you is better performance if you get into a crash recovery situation. It's perfectly reasonable for someone to make the decision that their SSD can finish an fsck so fast that there's no point in paying any penalty for the extra writes for journaling. The journal entries are 32 bytes per in SUJ. So the number of extra writes is down in the noise. The journaling also gets you asynchronous partial truncation and a few other asynchronous operations that are sync in SU. It does cost slightly more cpu time and more memory. I'm not saying you're making the wrong choice. I'm just saying that it's not clear that you should or should not use it with SSDs. I have a 256G SSD here with about 200G of data on it, and fsck without journaling takes about 3 minutes. I can live with that. With more data or a slower drive I might make a different choice. If you are happy with 3 minutes this is very reasonable and I assume you turn off bg fsck. Jeff -- Ian ___ 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
Re: WITH_LIBCPLUSPLUS buildworld broken on STABLE-9
On 2012-11-02 19:22, Oleg V. Nauman wrote:
...
/usr/src/lib/libc++/../../contrib/libc++/include/cstdlib:134:9: error:
no member named
'at_quick_exit' in the global namespace
using ::at_quick_exit;
~~^
This was fixed in head by r242472, I will merge it as soon as the MFC
timer expires (Nov 5). Sorry about the breakage, this was my fault.
In the meantime, you can use the attached diff.
Index: lib/libc++/Makefile
===
--- lib/libc++/Makefile (revision 242535)
+++ lib/libc++/Makefile (working copy)
@@ -53,7 +53,7 @@ cxxrt_${_S}:
WARNS= 0
CFLAGS+= -I${HDRDIR} -I${LIBCXXRTDIR} -nostdlib -DLIBCXXRT
-.if !defined(CXXFLAGS) || ${CXXFLAGS:M-std=*} ==
+.if empty(CXXFLAGS:M-std=*)
CXXFLAGS+= -std=c++0x
.endif
___
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: Why is SU+J undesirable on SSDs?
At 05:14 PM 11/3/2012, Jeff Roberson wrote: The journal entries are 32 bytes per in SUJ. So the number of extra writes is down in the noise. The journaling also gets you asynchronous partial truncation and a few other asynchronous operations that are sync in SU. It does cost slightly more cpu time and more memory. I'm not saying you're making the wrong choice. I'm just saying that it's not clear that you should or should not use it with SSDs. This is what I would expect, and with wear leveling it is unlikely that the wear on the SSD would be significant anyway. In my case, the most important thing is not to lose logs in a crash (which could happen with just fsck), so journaling is worth it for me. The only reason I could see not to use SU+J with SSDs (or any disk, for that matter) is if there are bugs which harm stability. A look at http://www.freebsd.org/cgi/query-pr-summary.cgi?category=severity=priority=class=state=opensort=nonetext=responsible=multitext=originator=release= shows several open PRs mentioning panics, corruption, and reboots. Are they still open because problems exist? Or have the committers simply neglected to close them? --Brett Glass ___ 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: kvm vlan virtio problem
thanks bryan, i don't have vlans inside guest. as you suggested i disabled nic tso ifconfig vtnet0 -tso and sysctl net.inet.tcp.tso=0 and so far, so good! everything is ok now. once again, thanks a lot. On 11/03/2012 09:40 PM, Bryan Venteicher wrote: Hi, - Original Message - From: Bane Ivosevbane.ivo...@pmf.uns.ac.rs To: freebsd-stable@freebsd.org Sent: Saturday, November 3, 2012 2:12:25 PM Subject: kvm vlan virtio problem hi, i have several kvm ubuntu 12.04 and centos 6 hosts with standard bridged network setup. same problem on each server with freebsd 9 amd64 guest and virtio nic: soon after guest start host syslog is filling with this message at very high rate. guest is working without any problem. with e1000 guest driver eveything is ok. does enyone have/had same problem? thanks. I have a vague recollection of looking at something similar last year... Do you have VLAN configured in the guest as well? What is the ifconfig output? Does disabling TSO on the vtnetX device make these messages go away? Bryan kernel: [2337728.094141] [ cut here ] kernel: [2337728.094144] WARNING: at /build/buildd/linux-3.2.0/net/core/dev.c:1955 skb_gso_segment+0x341/0x3b0() kernel: [2337728.094146] Hardware name: System x3550 M3 -[7944K3G]- kernel: [2337728.094148] 802.1Q VLAN Support: caps=(0x30195833, 0x0) len=3196 data_len=0 ip_summed=0 kernel: [2337728.094149] Modules linked in: dm_snapshot ip6table_filter ip6_tables ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp iptable_filter ip_tables x_tables kvm_intel kvm dm_crypt nfsd nfs lockd fscache auth_rpcgss nfs_acl sunrpc nls_iso8859_1 nls_cp437 vfat fat 8021q garp bridge stp serio_raw cdc_ether usbnet vhost_net macvtap i7core_edac macvlan shpchp ioatdma edac_core dca tpm_tis lp parport mac_hid btrfs zlib_deflate libcrc32c usbhid hid megaraid_sas bnx2 kernel: [2337728.094177] Pid: 8685, comm: vhost-8683 Tainted: G W3.2.0-31-generic #50-Ubuntu kernel: [2337728.094179] Call Trace: kernel: [2337728.094180]IRQ [81066d7f] warn_slowpath_common+0x7f/0xc0 kernel: [2337728.094185] [81066e76] warn_slowpath_fmt+0x46/0x50 kernel: [2337728.094188] [8153f581] skb_gso_segment+0x341/0x3b0 kernel: [2337728.094191] [81542ee1] dev_hard_start_xmit+0xc1/0x540 kernel: [2337728.094196] [a01c0150] ? br_flood+0xc0/0xc0 [bridge] kernel: [2337728.094199] [8154360a] dev_queue_xmit+0x2aa/0x420 kernel: [2337728.094203] [a01c01e2] br_dev_queue_push_xmit+0x92/0xd0 [bridge] kernel: [2337728.094208] [a01c0278] br_forward_finish+0x58/0x60 [bridge] kernel: [2337728.094212] [a01c042b] __br_forward+0xab/0xd0 [bridge] kernel: [2337728.094217] [a01c04ed] br_forward+0x5d/0x70 [bridge] kernel: [2337728.094221] [a01c11c2] br_handle_frame_finish+0x182/0x2a0 [bridge] kernel: [2337728.094226] [a01c14a8] br_handle_frame+0x1c8/0x270 [bridge] kernel: [2337728.094231] [a01c12e0] ? br_handle_frame_finish+0x2a0/0x2a0 [bridge] kernel: [2337728.094234] [81540892] __netif_receive_skb+0x1e2/0x520 kernel: [2337728.094237] [81540ff1] process_backlog+0xb1/0x190 kernel: [2337728.094240] [815422e4] net_rx_action+0x134/0x290 kernel: [2337728.094242] [8165a4fe] ? _raw_spin_lock+0xe/0x20 kernel: [2337728.094245] [8106e528] __do_softirq+0xa8/0x210 kernel: [2337728.094248] [81664d6c] call_softirq+0x1c/0x30 kernel: [2337728.094249]EOI [81015305] do_softirq+0x65/0xa0 kernel: [2337728.094254] [815427c8] netif_rx_ni+0x28/0x30 kernel: [2337728.094258] [81478ec6] tun_get_user+0x306/0x4a0 kernel: [2337728.094261] [81479085] tun_sendmsg+0x25/0x30 kernel: [2337728.094265] [a01b09b6] handle_tx+0x296/0x530 [vhost_net] kernel: [2337728.094269] [a01b0c85] handle_tx_kick+0x15/0x20 [vhost_net] kernel: [2337728.094273] [a01ade3d] vhost_worker+0xdd/0x170 [vhost_net] kernel: [2337728.094276] [a01add60] ? vhost_set_memory+0x130/0x130 [vhost_net] kernel: [2337728.094279] [8108a03c] kthread+0x8c/0xa0 kernel: [2337728.094282] [81664c74] kernel_thread_helper+0x4/0x10 kernel: [2337728.094285] [81089fb0] ? flush_kthread_worker+0xa0/0xa0 kernel: [2337728.094287] [81664c70] ? gs_change+0x13/0x13 kernel: [2337728.094289] ---[ end trace a38cf088269411b3 ]--- kernel: [2337728.094731] [ cut here ] ___ 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: SU+J on 9.1-RC2 ISO
There's an existing checkbox to disable it. There was substantial consensus for 9.0 that SUJ was something we wanted -- I'd personally be very hesitant to change the defaults without more input from FS people. I think this discussion should be moved to freebsd-fs@ or freebsd-current@ instead of stable@ since it's actually a filesystem issue not an installer issue. -Nathan On 11/03/12 14:09, Jeremy Chadwick wrote: (Please keep me CC'd, as I'm not subscribed to -stable) I've CC'd Nathan Whitehorn, who according to bsdinstall(8) is the author (not sure if maintainer) of the code. This default has already begun to bite users/SAs in the ass: http://lists.freebsd.org/pipermail/freebsd-questions/2012-November/246069.html SU+J (the journalling part specifically) needs to be disabled by default in the installer. This default was a very bad choice and should not have been done. It either indicates someone was out of touch with the rest of the issues surrounding the feature, or that someone intentionally decided it's the best way to get people using it for testing (I have seen this justification presented in the past, and it is the wrong approach). However, since some people DO want it (and those folks don't use dump), the installer should be modified to make SU+J support toggleable via a a checkbox. The default, obviously, should be unchecked. If the user checks the checkbox, an ominous warning message should be displayed informing the user of the repercussions. The only option at that point should be OK, after which the checkbox is checked. Do not tell me send patches. This issue/problem has gone on long enough, and the community bitched hard/long enough, that the person who committed this default should be responsible for fixing it. We should operate under the assumption that this bug/problem will never be fixed. It probably will be, but again, we must operate with the assumption that Kirk et al will require years to fix it. (It has already been something like 9 months. Or is it a year?) While I'm here -- does anyone remember the exact commit which was done sometime in the past 6-9 months which made the installer work properly with SSDs (re: partition alignment)? I have questions about that; if I remember right, someone set the alignment size to 4KBytes, and that is completely 100% wrong -- it needs to be 1MByte or 2MBytes if you want to be extra cautious, which correlates with NAND erase block size, otherwise we're not really solving jack squat. ___ 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: kvm vlan virtio problem
Hi, - Original Message - From: Bane Ivosev bane.ivo...@pmf.uns.ac.rs To: Bryan Venteicher bry...@daemoninthecloset.org, freebsd-stable@freebsd.org Sent: Saturday, November 3, 2012 7:58:57 PM Subject: Re: kvm vlan virtio problem thanks bryan, i don't have vlans inside guest. as you suggested i disabled nic tso ifconfig vtnet0 -tso and sysctl net.inet.tcp.tso=0 and so far, so good! everything is ok now. once again, thanks a lot. No need to disable TSO globally. So it seems if_vtnet sending down TSO frames that don't have the appropriate flags set. I'll look into it more in a next couple of days. Thanks for the quick reply back. Bryan On 11/03/2012 09:40 PM, Bryan Venteicher wrote: Hi, - Original Message - From: Bane Ivosevbane.ivo...@pmf.uns.ac.rs To: freebsd-stable@freebsd.org Sent: Saturday, November 3, 2012 2:12:25 PM Subject: kvm vlan virtio problem hi, i have several kvm ubuntu 12.04 and centos 6 hosts with standard bridged network setup. same problem on each server with freebsd 9 amd64 guest and virtio nic: soon after guest start host syslog is filling with this message at very high rate. guest is working without any problem. with e1000 guest driver eveything is ok. does enyone have/had same problem? thanks. I have a vague recollection of looking at something similar last year... Do you have VLAN configured in the guest as well? What is the ifconfig output? Does disabling TSO on the vtnetX device make these messages go away? Bryan kernel: [2337728.094141] [ cut here ] kernel: [2337728.094144] WARNING: at /build/buildd/linux-3.2.0/net/core/dev.c:1955 skb_gso_segment+0x341/0x3b0() kernel: [2337728.094146] Hardware name: System x3550 M3 -[7944K3G]- kernel: [2337728.094148] 802.1Q VLAN Support: caps=(0x30195833, 0x0) len=3196 data_len=0 ip_summed=0 kernel: [2337728.094149] Modules linked in: dm_snapshot ip6table_filter ip6_tables ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle xt_tcpudp iptable_filter ip_tables x_tables kvm_intel kvm dm_crypt nfsd nfs lockd fscache auth_rpcgss nfs_acl sunrpc nls_iso8859_1 nls_cp437 vfat fat 8021q garp bridge stp serio_raw cdc_ether usbnet vhost_net macvtap i7core_edac macvlan shpchp ioatdma edac_core dca tpm_tis lp parport mac_hid btrfs zlib_deflate libcrc32c usbhid hid megaraid_sas bnx2 kernel: [2337728.094177] Pid: 8685, comm: vhost-8683 Tainted: G W3.2.0-31-generic #50-Ubuntu kernel: [2337728.094179] Call Trace: kernel: [2337728.094180]IRQ [81066d7f] warn_slowpath_common+0x7f/0xc0 kernel: [2337728.094185] [81066e76] warn_slowpath_fmt+0x46/0x50 kernel: [2337728.094188] [8153f581] skb_gso_segment+0x341/0x3b0 kernel: [2337728.094191] [81542ee1] dev_hard_start_xmit+0xc1/0x540 kernel: [2337728.094196] [a01c0150] ? br_flood+0xc0/0xc0 [bridge] kernel: [2337728.094199] [8154360a] dev_queue_xmit+0x2aa/0x420 kernel: [2337728.094203] [a01c01e2] br_dev_queue_push_xmit+0x92/0xd0 [bridge] kernel: [2337728.094208] [a01c0278] br_forward_finish+0x58/0x60 [bridge] kernel: [2337728.094212] [a01c042b] __br_forward+0xab/0xd0 [bridge] kernel: [2337728.094217] [a01c04ed] br_forward+0x5d/0x70 [bridge] kernel: [2337728.094221] [a01c11c2] br_handle_frame_finish+0x182/0x2a0 [bridge] kernel: [2337728.094226] [a01c14a8] br_handle_frame+0x1c8/0x270 [bridge] kernel: [2337728.094231] [a01c12e0] ? br_handle_frame_finish+0x2a0/0x2a0 [bridge] kernel: [2337728.094234] [81540892] __netif_receive_skb+0x1e2/0x520 kernel: [2337728.094237] [81540ff1] process_backlog+0xb1/0x190 kernel: [2337728.094240] [815422e4] net_rx_action+0x134/0x290 kernel: [2337728.094242] [8165a4fe] ? _raw_spin_lock+0xe/0x20 kernel: [2337728.094245] [8106e528] __do_softirq+0xa8/0x210 kernel: [2337728.094248] [81664d6c] call_softirq+0x1c/0x30 kernel: [2337728.094249]EOI [81015305] do_softirq+0x65/0xa0 kernel: [2337728.094254] [815427c8] netif_rx_ni+0x28/0x30 kernel: [2337728.094258] [81478ec6] tun_get_user+0x306/0x4a0 kernel: [2337728.094261] [81479085] tun_sendmsg+0x25/0x30 kernel: [2337728.094265] [a01b09b6] handle_tx+0x296/0x530 [vhost_net] kernel: [2337728.094269] [a01b0c85] handle_tx_kick+0x15/0x20 [vhost_net] kernel: [2337728.094273] [a01ade3d] vhost_worker+0xdd/0x170 [vhost_net] kernel: [2337728.094276] [a01add60] ?
Re: FreeBSD 9.1 stability/robustness?
On Fri, Nov 2, 2012 at 4:10 AM, Rainer Duffner rai...@ultra-secure.de wrote: Am Thu, 1 Nov 2012 20:14:51 -0600 (MDT) schrieb Brett Glass br...@lariat.net: I need to build up a few servers and routers, and am wondering how FreeBSD 9.1 is shaping up. Will it be likely to be more stable and robust than 9.0-RELEASE? Are there issues that will have to wait until 9.2-RELEASE to be fixed? Opinions welcome. If I'm not mistaken, the bge-stuff that makes the default NICs ins HP G8 servers (360+380) actually run will not make it back into 9.1. Intel cards work much better anyway... I have a blog post at http://blog.hostileadmin.com/2012/06/14/freebsd-on-hp-proliant-dl360p-g8-servers/ which touches on this. I heard as recently as today that the fixes for the BCM5719 and 5720 were recently committed to -CURRENT. It's too late for them to be rolled into 9.1. Not sure if they'll be committed to to stable/8 or not, but if so they could make it into 8.4-R. -- Take care Rick Miller ___ 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: SU+J on 9.1-RC2 ISO
There's an existing checkbox to disable it. There was substantial consensus for 9.0 that SUJ was something we wanted Nice to hear. I assume you mean check box during install process? Not mentioned in install guide in handbook. So, after I accept guided partitioning, I should go to modify or else? Sorry to bother again and again, but it is not clear to me at the moment. I'd avoid further tunefs if possible. If not possible, let me clear that branch 8 has no J as default and I found myself wondering. Correct me if I'm wrong. I have to go to single user mode first. Make fsck on partition that contains freebsd-ufs ( / ). Check options for that partition with tunefs -p partition. What exact name that partition would have? Next I have to disable journaling with -j disable and enable trim with -t enable. Reboot and voila? People mention file or partition that has to be deleted. Next few days I will put ssd into laptop and manage install, when release shows up. If there is another point I have to choose for journaling, let me know. Best regards all Zoran ___ 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
