Re: Fuse on FreeBSD 9.2
On Tue, Oct 8, 2013, at 5:21, Łukasz P wrote: Hello, Please let me know if anyone is up to fix fuse on FreeBSD 9.x ? Particularly this bug: http://www.freebsd.org/cgi/query-pr.cgi?pr=182739 http://www.freebsd.org/cgi/query-pr.cgi?pr=182739 I'm willing to pay for the fix. I think the fix is the new from-scratch fuse module in FreeBSD 10, which in my experience works flawlessly. Perhaps you should instead see if someone is willing to backport that fuse module to 9.x? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Fuse on FreeBSD 9.2
On Tue, Oct 8, 2013, at 6:34, Mark Felder wrote: I think the fix is the new from-scratch fuse module in FreeBSD 10, which in my experience works flawlessly. Perhaps you should instead see if someone is willing to backport that fuse module to 9.x? Well actually the description on the WhatsNew/FreeBSD10 page has me on the fence about whether or not the port and the new module in FreeBSD 10 share the same source. You could diff it to find out. I'm a bit short on time this morning to dig into that. :-) The FreeBSD port (including the clean-room BSD-licenced reimplementation of the kernel module) was created during 2 summer of code mandates and being revived by gnn recently. The functionality in this commit matches the content of fusefs-kmod port, which doesn't need to be installed anymore for -CURRENT setups. https://wiki.freebsd.org/WhatsNew/FreeBSD10 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Fuse on FreeBSD 9.2
On Tue, Oct 8, 2013, at 7:08, Łukasz P wrote: Thank you - I'll give it a try today. Can you confirm that doing rsync with this fuse version is stable? Can you please tell us which fuse-based file system have you used? My main use case these days is ntfs-3g, and I no longer get panics when doing mass file operations including rsync. :-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Discussing ideas or wish list
On Thu, Aug 8, 2013, at 9:54, Patrick Dung wrote: 1) Perl version change within Major release If I remembered correctly, FreeBSD 9.0 shipped with perl 5.12 packages in the DVD. But in FreeBSD 9.1, Perl 5.14 is shipped. I think Perl version should be consistent in the FreeBSD 9 series. The change of Perl version may make user difficult to upgrade other perl packages due to dependency issues. The ports tree is a rolling release and decides what the default perl version is, not the FreeBSD release. Let's ignore that though and take a peek into history using FreeBSD 8 series as an example because it's closer to EoL. Perl 5.8.0 is officially released July 18, 2002. Perl 5.8.9 is officially EoL on Nov 6, 2008. FreeBSD 8.0 released Nov 25, 2009. The ports tree's default Perl version at that point in time is Perl 5.8.9. Both Perl 5.8.9 and 5.10.1 are available as packages at that time. FreeBSD 8.4 released June 7, 2013. The ports tree's default Perl version at that point in time is 5.14.2. FreeBSD 8.4 could be the last release in the FreeBSD 8.x series. Its estimated EoL is June 30, 2015. Do you see the problem with having to support an ancient Perl version that is 13 years old? I'd suspect many modern Perl applications to not even work on Perl 5.8.9. I know pkgng should replaced the old package management tools in FreeBSD 10, I hope the situation would improve. After the EoL of FreeBSD 8 (estimated June 30, 2015) the old package tools are scheduled to be removed from FreeBSD. This change will be MFC'd back to 9-STABLE and the release at that time (perhaps 9.4-RELEASE?) will not have the old pkg_* tools. This seems a bit odd to happen in the middle of a series because of POLA, but we can't support the old package tools forever and FreeBSD 9.1-9.3 will have given you plenty of opportunity to migrate to the new package format and ease the upgrade to FreeBSD 10.x. 2) pkgng I think it has checksum checking on the files in the packages. Could pkgng detect the packages was being tampered? man pkg-check pkg check -s is used to find invalid checksums for installed packages. Or how can user authenticate that the package is build by FreeBSD? I don't think packages are signed yet, but this is permitted by the new pkg design and will hopefully happen before too long. 3) FreeBSD's own systat Yes. there is bsdsar in the ports, but I would like to see improvement. For example, stat for multiple CPU, number of open files/context switches, one statistics file per day, etc... I think systat is great, too. We could probably import some functionality from OpenBSD as I recall their systat has more features. Thank you for your feedback and I hope I've answered a couple of your questions. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Discussing ideas or wish list
On Thu, Aug 8, 2013, at 10:34, Mark Felder wrote: After the EoL of FreeBSD 8 (estimated June 30, 2015) the old package tools are scheduled to be removed from FreeBSD. This change will be MFC'd back to 9-STABLE and the release at that time (perhaps 9.4-RELEASE?) will not have the old pkg_* tools. This seems a bit odd to happen in the middle of a series because of POLA, but we can't support the old package tools forever and FreeBSD 9.1-9.3 will have given you plenty of opportunity to migrate to the new package format and ease the upgrade to FreeBSD 10.x. Note this isn't set in stone. Watch the Roadmap on this page: https://wiki.freebsd.org/pkgng/CharterAndRoadMap ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: After the FreeBSD VM crash, file system in VM got rolled back to some old previous state causing data loss
Virtualbox is very aggressive about caching writes. This is how it achieves its perceived speed. I wouldn't expect to see this happen on real hardware. I might have to try this out though and see if I can reproduce it reliably. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: panic: kmem_map too small at heavy packet traffic
I've been under the impression that synproxy was broken for quite some time, but I know there has been a lot of work on pf in HEAD so I can't be sure where it might stand there. Can anyone confirm/deny this? And not to discourage you, but the pf documentation does say Routine use of this option is not recommended, however, as it breaks expected TCP protocol behavior when the server can't process the request... However, panics are never good and hopefully someone can help you figure it out. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: writing a rc.d script
On Sun, 07 Jul 2013 06:45:46 -0500, Aryeh Friedman aryeh.fried...@gmail.com wrote: I have a program I am making a port for that also requires a /usr/local/etc/rc.d script is there anywhere I can find documentation on how write one and/or a template file to follow? Start with another similar port if possible. Make sure you use rclint to verify its correctness. There is a ton of information inside /etc/rc.subr and /usr/ports/Mk/* which may help you write your port where the documentation falls short. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: ZFS regimen: scrub, scrub, scrub and scrub again.
On Wed, 23 Jan 2013 14:26:43 -0600, Chris Rees utis...@gmail.com wrote: So we have to take your word for it? Provide a link if you're going to make assertions, or they're no more than your own opinion. I've heard this same thing -- every vdev == 1 drive in performance. I've never seen any proof/papers on it though. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
ipv6 equivalent to ipv4_addr_IF in network.subr?
Hi all,
At work we have several standalone webservers with lots of IPs... let's
say x.x.x.100 - 200. That's a LOT of ifconfig_IF_alias0, alias1,
alias2... to maintain, and it's also painful when we need to move an IP
to a different server which happens occasionally. The right solution for
this is to use ranges with ipvr_addr_IF=x.x.x.100-200/24 and if you need
to move an IP you just create a gap.For example, if we needed to move the
IP .126 we'd just change it to:
ipv4_addr_IF=x.x.x.100-125/24 x.x.x.127-200/32
This works great! But what about IPv6? We use corresponding IPv6 IPs so if
a customer actually wants IPv6 enabled it's as easy as adding the
record. So this leaves us with having to maintain 100 aliases again, and
when you create a gap you have to renumber all of those alias numbers or
leave things like ifconfig_IF_alias67=inet6 up strewn throughout the
config to fill the gaps. It's just not something worth maintaining long
term and I'd like a way to do ranges for IPv6 as well.
I've been playing with adding ipv6_addr_IF support to network.subr and it
certainly works but the main problem is that I'm only dealing with decimal
ranges. This would *not* work with any IPv6 hex ranges unless someone more
clever than I can think of a good way to code that up.
Mostly a blatant ripoff of ipv4_addrs_common() we come up with this:
# ipv6_addrs_common if action
# Evaluate the ifconfig_if_ipv6 arguments for interface $if and
# use $action to add or remove ipv6 addresses from $if.
ipv6_addrs_common()
{
local _ret _if _action _cidr _cidr_addr
local _ipaddr _prefixlen _range _ipnet _iplow _iphigh _ipcount
_ret=1
_if=$1
_action=$2
# get ipv6-addresses
cidr_addr=`get_if_var $_if ipv6_addrs_IF`
for _cidr in ${cidr_addr}; do
_ipaddr=${_cidr%%/*}
_prefixlen=/${_cidr##*/}
_range=${_ipaddr##*:}
_ipnet=${_ipaddr%:*}
_iplow=${_range%-*}
_iphigh=${_range#*-}
# clear prefixlen when removing aliases
if [ ${_action} = -alias ]; then
_prefixlen=
fi
_ipcount=${_iplow}
while [ ${_ipcount} -le ${_iphigh} ]; do
eval ifconfig ${_if} inet6 ${_action}
${_ipnet}:${_ipcount}${_prefixlen}
_ipcount=$((${_ipcount}+1))
_ret=0
# only the first ipaddr in a subnet need the
real prefixlen
if [ ${_action} != -alias ]; then
_prefixlen=/128
fi
done
done
return $_ret
}
But again, has no concept of any non-decimal ranges. However, this would
still be invaluable to us and perhaps anyone else out there managing large
numbers of IPs on a server.
So two questions:
1) With its current limitations (decimal ranges only) would this ever be
accepted into network.subr?
2) Can anyone assist me with correctly modifying ipv6if() so this works
standalone? Without ipv6if() modification it will always return 1 and skip
setting up any ipv6 addresses on the interface because it doesn't find any
ifconfig_IF_ipv6 or ipv6_ifconfig_IF in rc.conf.
Thanks!
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: IBM blade server abysmal disk write performances
On Thu, 17 Jan 2013 16:12:17 -0600, Karim Fodil-Lemelin fodillemlinka...@gmail.com wrote: SAS controllers may connect to SATA devices, either directly connected using native SATA protocol or through SAS expanders using SATA Tunneled Protocol (STP). The systems is currently put in place using SATA instead of SAS although its using the same interface and backplane connectors and the drives (SATA) show as da0 in BSD _but_ with the SATA drive we get *much* better performances. I am thinking that something fancy in that SAS drive is not being handled correctly by the FreeBSD driver. I am planning to revisit the SAS drive issue at a later point (sometimes next week). Your SATA drives are connected directly not with an interposer such as the LSISS9252, correct? If so, this might be the cause of your problems. Mixing SAS and SATA drives is known to cause serious performance issues for almost every JBOD/controller/expander/what-have-you. Change your configuration so there is only one protocol being spoken on the bus (SAS) by putting your SATA drives behind interposers which translate SAS to SATA just before the disk. This will solve many problems. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: IBM blade server abysmal disk write performances
On Tue, 15 Jan 2013 08:12:14 -0600, Karim Fodil-Lemelin fodillemlinka...@gmail.com wrote: Hi, I'm struggling getting FreeBSD 9.1 properly work on an IBM blade server (HS22). Here is a dd output from Linux CentOS vs FreeBSD 9.1. GNU dd is heavily buffered unless you tell it not to be. There really is no reason why you should want dd to be buffered by default. How can you trust that your attempt at writing raw data to a device actually completed if it's buffered? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On Mon, 01 Oct 2012 15:00:40 -0500, guy.hel...@gmail.com wrote: Sep 21 02:14:55 backups kernel: (da1:mpt0:0:1:0): WRITE(10). CDB: 2a 0 5 ee 60 16 0 1 0 0 Sep 21 02:14:55 backups kernel: (da1:mpt0:0:1:0): CAM status: SCSI Status Error Sep 21 02:14:55 backups kernel: (da1:mpt0:0:1:0): SCSI status: Busy Sep 21 02:14:55 backups kernel: (da1:mpt0:0:1:0): Retrying command Sep 21 02:18:44 backups kernel: (da1:mpt0:0:1:0): WRITE(10). CDB: 2a 0 3 ef 42 51 0 1 0 0 Sep 21 02:18:44 backups kernel: (da1:mpt0:0:1:0): CAM status: SCSI Status Error Sep 21 02:18:44 backups kernel: (da1:mpt0:0:1:0): SCSI status: Busy Sep 21 02:18:44 backups kernel: (da1:mpt0:0:1:0): Retrying command Sep 21 02:18:48 backups kernel: (da1:mpt0:0:1:0): WRITE(10). CDB: 2a 0 3 ef 64 51 0 1 0 0 Sep 21 02:18:48 backups kernel: (da1:mpt0:0:1:0): CAM status: SCSI Status Error Sep 21 02:18:48 backups kernel: (da1:mpt0:0:1:0): SCSI status: Busy Sep 21 02:18:48 backups kernel: (da1:mpt0:0:1:0): Retrying command Sep 21 02:18:49 backups kernel: (da1:mpt0:0:1:0): WRITE(10). CDB: 2a 0 3 ef 66 51 0 1 0 0 Sep 21 02:18:49 backups kernel: (da1:mpt0:0:1:0): CAM status: SCSI Status Error Sep 21 02:18:49 backups kernel: (da1:mpt0:0:1:0): SCSI status: Busy ... Sep 21 05:06:18 backups kernel: (da1:mpt0:0:1:0): WRITE(10). CDB: 2a 0 41 f3 94 99 0 1 0 0 Sep 21 05:06:18 backups kernel: (da1:mpt0:0:1:0): CAM status: SCSI Status Error Sep 21 05:06:18 backups kernel: (da1:mpt0:0:1:0): SCSI status: Busy Sep 21 05:06:18 backups kernel: (da1:mpt0:0:1:0): Retrying command Sometimes you'll see this before a crash, but not every time. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On Fri, 14 Sep 2012 20:37:40 -0500, Mark Saad nones...@longcount.org wrote: How do you have suj on 8.3 ? Are you using a patch ? I don't have suj on 8.3 Also can you retest 9 with the following sysctlkern.timecounter.hardware=Acpi-fast Yes, I'll attempt that as soon as possible. We're under a tight deadline to migrate critical resources off of VMWare now so I don't know how soon I can test. Also in esxi what setup options do you have for the vm's ? I'm not sure what ones I have off the top of my head, but VMWare support has previously poured over ever option to make sure nothing was misconfigured. Lastly do you have esxi setup to talk to a ntp server ? If so can you confirm that it's working ? I mean the esxi host not the vm . Yes, and yes. We've got a reliable NTP infrastructure at work and ESXi is definitely using it. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
Hi Mark, Here's the output of our VMs running on ESXi 4.1u1 FreeBSD 7.4: # sysctl kern.timecounter.choice kern.timecounter.choice: TSC(800) ACPI-safe(850) i8254(0) dummy(-100) # sysctl kern.timecounter.hardware kern.timecounter.hardware: ACPI-safe FreeBSD 8.3: # sysctl kern.timecounter.choice kern.timecounter.choice: TSC(800) ACPI-safe(850) i8254(0) dummy(-100) # sysctl kern.timecounter.hardware kern.timecounter.hardware: ACPI-safe FreeBSD 9.0: # sysctl kern.timecounter.choice kern.timecounter.choice: TSC(1000) i8254(0) ACPI-fast(900) dummy(-100) # sysctl kern.timecounter.hardware kern.timecounter.hardware: TSC Note that both 8.3 and 9.0 crash, while 7.4 does not. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On Wed, 12 Sep 2012 14:20:26 -0500, John Baldwin j...@freebsd.org wrote: Are you still seeing this, and if so can you get a crashdump? Also, I'm curious if you only see this with SUJ or if plain UFS+SU works fine? The crash on demand right now is producable on 8.x and 9.x, so SUJ isn't a requirement. Also, there is no crashdump available. The OS just hangs and stops taking input. There's no panic or coredump or anything of the like. You just have to nuke the VM and re-boot it back up. And for the record we can't reproduce this crash in Xen... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On Thu, 13 Sep 2012 10:11:28 -0500, Andriy Gapon a...@freebsd.org wrote: Just curious - does VMWare provide a remote debugger support (gdb stub)? I'm not aware of one. What I have been able to successfully do is break into the debugger during the hang but the info I've posted so far has not been relevant to anyone. I'm hoping someone on the core team will eventually be able to follow my guide and figure out what went wrong. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On Thu, 13 Sep 2012 11:28:15 -0500, Kurt Lidl l...@pix.net wrote: Isn't this what you want? http://stackframe.blogspot.com/2007/04/debugging-linux-kernels-with.html -Kurt Interesting -- it looks like that's an option on ESX as well. The only question is: what do I do with that? It's going to give me the debugging entire VM, not the kernel inside. Without being a VMWare developer I imagine its data will be a bit useless :-( ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
Changing timer source has not been tested. It doesn't crash in 7.x, so did something timer related change in 8.x? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Pull in upstream before 9.1 code freeze?
On Thu, 05 Jul 2012 11:05:42 -0500, Damien Fleuriot m...@my.gd wrote: Using a third-party's name servers is not an option And how can you trust that your port 53 TCP/UDP traffic isn't being redirected and you're talking to the real root servers? I think you're being a bit too paranoid... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Pull in upstream before 9.1 code freeze?
On Thu, 05 Jul 2012 13:51:25 -0500, Matthew Seaman m.sea...@infracaninophile.co.uk wrote: AFAIK, no operating system has a stub resolver the capability to validate DNSSEC. Yeah, I was sort of hinting at that :-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Pull in upstream before 9.1 code freeze?
On Tue, 03 Jul 2012 07:39:34 -0500, Dag-Erling Smørgrav d...@des.no wrote: I don't think there will be as much whinging as you expect. Times have changed. Agreed; if we need DNS in base (really, why?) then unbound+nsd are prime candidates, but they're healthily maintained in ports...soo... no real advantage. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Pull in upstream before 9.1 code freeze?
On Tue, 03 Jul 2012 07:39:34 -0500, Dag-Erling Smørgrav d...@des.no wrote: I'm willing to import and maintain unbound (BSD-licensed validating, recursive, and caching DNS resolver) if you remove BIND. My only issue is that unbound is still a relatively young project (released 2007) and rapidly evolving. Unless the FreeBSD releases really pick up the pace it might be worse to have an older version in base. Just read the changelogs for the last year and you'll see what I mean. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [CFC/CFT] large changes in the loader(8) code
On Tue, 26 Jun 2012 12:37:11 -0500, John Baldwin j...@freebsd.org wrote: I'm hesitant to encourage the use of this as I do think putting GPT inside of a gmirror violates the GPT spec. I personally think this use case is a bit ... odd, anyway. I have only request to those that manage GPT/GEOM/etc -- as I'm used to doing multiple mdadm RAID components on Linux for maximum flexibility, using gmirror upon multiple GPT partitions upon the same physical device is OK with me. My only complaint is that recovery is very, very stupid. We should by default detect and only rebuild ONE gmirror device at a time on the same physical provider. You get nothing but a smokin' angry head if you allow multiple to rebuild at the same time because it's fighting over sequential writes all the way across the platters. It would also be nice if gmirror rebuild could also be detected by fsck and fsck could either hold off or gmirror could be paused until a consistent filesystem state exists. It's probably best for the background fsck to go first so you can get the system up and running, but then when it's finished gmirror should continue. Otherwise I have no issues with gmirror -- it does exactly the job I need it to. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: MAGIC with HP KVM - someone will help?
On Mon, 25 Jun 2012 09:38:01 -0500, Atte Peltomäki atte.peltom...@iki.fi wrote: If it's any consolation, I've used other brand KVM switches as well and the only one I've found quite reliable were Raritan and those cost an arm and a leg. raritan userstation $65.00 http://www.ebay.com/itm/Raritan-Paragon-II-P2-UST-IP-CAT5-KVM-Keyboard-Video-Mouse-User-Station-/150743344570?pt=US_KVM_Switches_KVM_Cableshash=item231900e5ba 10 dongles $50.00 http://www.ebay.com/itm/LOT-of-10-NEW-Raritan-Paragon-II-KVM-CIM-P2CIM-PS2-Computer-Interface-Module-/221042459695?pt=COMP_EN_Hubshash=item337728442f We use these at work, as well as the daisy-chain versions of this line and they work quite well. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: reason for magic crashes.
Have you proven beyond reasonable doubt that there is no filesystem corruption or silent filesystem corruption due to bad hardware? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: MAGIC with HP KVM - someone will help?
On Wed, 20 Jun 2012 01:14:09 -0500, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: As this KVM have PS/2 connectors to keyboard and mouse i added USB to dual-PS/2 converter. http://geekhack.org/showwiki.php?title=PS2-to-USB+adapters You probably have a ps/2 converter that's known to be super buggy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Replacing rc(8) (Was: FreeBSD Boot Times)
On Wed, 20 Jun 2012 04:27:09 -0500, Fernando Apesteguía fernando.apesteg...@gmail.com wrote: Also, in embedded systems, boot time is an important factor. If you're designing a very specific embedded product based on FreeBSD why aren't you writing your own startup system? Why would anyone expect a general purpose out of the box OS to excel in a highly optimized embedded environment? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Upcoming release schedule - 8.4 ?
On Wed, 13 Jun 2012 16:49:18 -0500, Damien Fleuriot m...@my.gd wrote: I for one, as a fbsd admin on corporate servers ( read not commiter), would dearly like less releases but a more aggressive MFC approach. Less releases such as less frequent MAJOR releases (7.0, 8.0, 9.0...) or less MINOR releases as well? (8.4, 8.5, 9.1...) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Solving the great resource problem
On Thu, 14 Jun 2012 15:23:11 -0500, Dieter BSD dieter...@engineer.com wrote: Replacing perfectly good components simply because they are GPL. The purpose of BSD is supposed to be creating a great OS, not providing software hoarders with a supply of free code to abuse. You realize that companies like Juniper have a huge investment in FreeBSD and the less GPL code they have to deal with the better. FYI they give back to us with things like code drops and paid developers. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD Boot Times
They have a lot of manpower and can spend a lot of time replacing the boot subsystems and all startup scripts every 2 releases. For FreeBSD it's not a big issue as most people don't reboot often. If it's an itch you want to scratch you're more than welcome to look into it; that seems to be the way a lot of little things get worked on around here. Unfortunately the new systemd rc system (which is pretty awful) has issues of its own including the inability to handle /usr on a separate filesystem under certain situations.[1] I honestly prefer the freebsd startup system and rc.conf. Speed isn't an issue for me right now. It's even less obvious if you just use an SSD for /. [1] http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
Hi guys I'm excitedly posting this from my phone. Good news for you guys, bad news for us -- we were building HA storage on vmware for a client and can now replicate the crash on demand. I'll be posting details when I get home to my PC tonight, but this hopefully is enough to replicate the crash for any curious followers: ESXi 5 9 or 9-STABLE HAST 1 cpu is fine 1GB of ram UFS SUJ on HAST device No special loader.conf, sysctl, etc No need for VMWare tools Run Bonnie++ on the HAST device We can get the crash to happen on the first run of bonnie++ right now. I'll post the exact specs and precise command run in the PR. We found an old post from 2004 when we looked up the process state obtained from CTRL+T -- flswai -- which describes the symptoms nearly perfectly. http://unix.derkeiler.com/Mailing-Lists/FreeBSD/stable/2004-02/0250.html Hopefully this gets us closer to a fix... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: SuperPages utilization survey
On Sat, 02 Jun 2012 06:49:18 -0500, Florian Smeets f...@freebsd.org wrote: As far as i understand it does at least enable usage of pages up to 4MB, perhaps someone should teach mysql about the FreeBSD's limits? If you look at the output i sent, it certainly changes from using no superpage mappings at all to using them to some degree, if you script can be trusted Wow, this is a nice find. If someone were to add a patch for FreeBSD's superpages we might be able to get a nice little performance boost with little effort. Even the increase to 4MB for now is a welcome improvement. I'll make sure to put this in my toolbox ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: reverse USB driver - is it possible?
On Mon, 04 Jun 2012 18:51:50 -0500, Daniel O'Connor docon...@gsoft.com.au wrote: ISTR someone on the lists was talking about a device by http://i-odd.com which does what you want. I found http://renosite.com/ which is a home brew version of the same basic idea. Zalman ZM-VE200 and ZM-VE300 are also what you want. Kind of nice to have ISOs on a drive and be able to make it fake a CDROM/DVDROM/BDROM at your leisure. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: SuperPages utilization survey
[/usr/home/feld]# python spsurvey.py last pid: 54743; load averages: 0.28, 0.26, 0.24 up 18+07:41:02 16:22:45 145 processes: 1 running, 144 sleeping Mem: 828M Active, 845M Inact, 8517M Wired, 174M Cache, 725M Buf, 265M Free Swap: 4096M Total, 88M Used, 4008M Free, 2% Inuse Total accounted memory mappings: 23968 MB (6136043 pages) Memory in superpages: 12941 MB (14 mappings) + pid: 26349 (postgres) start: 80280 stop: 8452c6000 (1066 MB) tp: ph path: + pid: 26351 (postgres) start: 80280 stop: 8452c6000 (1066 MB) tp: ph path: + pid: 26352 (postgres) start: 80280 stop: 8452c6000 (1066 MB) tp: ph path: + pid: 26353 (postgres) start: 80280 stop: 8452c6000 (1066 MB) tp: ph path: + pid: 26374 (postgres) start: 80280 stop: 8452c6000 (1066 MB) tp: ph path: + pid: 26382 (postgres) start: 80280 stop: 8452c6000 (1066 MB) tp: ph path: + pid: 26387 (postgres) start: 80280 stop: 8452c6000 (1066 MB) tp: ph path: + pid: 26388 (postgres) start: 80280 stop: 8452c6000 (1066 MB) tp: ph path: + pid: 26398 (postgres) start: 80280 stop: 8452c6000 (1066 MB) tp: ph path: + pid: 44306 (odasrv) start: 80180 stop: 80600 (72 MB) tp: df path: + pid: 44318 (odasrv) start: 80180 stop: 805c0 (68 MB) tp: df path: + pid: 53549 (postgres) start: 80280 stop: 8452c6000 (1066 MB) tp: ph path: + pid: 53932 (postgres) start: 80280 stop: 8452c6000 (1066 MB) tp: ph path: + pid: 54515 (postgres) start: 80280 stop: 8452c6000 (1066 MB) tp: ph path: Eligible mappings not promoted: 413 Yup, seems like Postgres does a good job of using superpages ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
So when this hang happens, there never is a real panic. It just sits in a state which I describe as like being in a deadlock. How would I go about getting a crashdump if it never panics? Is it possible to do the dump over a network or something because I don't believe it can write through the controller at all. Also, thank you for the KTR_SCHED tip. This is the type of info I was looking for. Unfortunately I've only ever seen this crash once on a kernel with debugging enabled. The machine which is currently prepared to do this work used to crash a few times a week and now it has 70 days uptime... however, it is an example of a machine with mpt0 and em0 sharing an IRQ so I might be able to trigger it using Dane's method. $ vmstat -i interrupt total rate irq1: atkbd0 392 0 irq6: fdc0 9 0 irq14: ata0 34 0 irq18: em0 mpt0 1189748491218 cpu0: timer 2174263198400 Total 3364012124619 I'm doing my best to get you guys the info you need, but this is one heck of a Heisenbug... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On Wed, 30 May 2012 10:06:13 -0500, John Baldwin j...@freebsd.org wrote: Do you only have one CPU in this VM? If not, do you know which threads the other CPUs were running (e.g. do you have ps7.png, etc.)? correct, only one CPU in the VM ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On Wed, 30 May 2012 12:17:07 -0500, John Baldwin j...@freebsd.org wrote: Humm, can you test it with 2 CPUs? We primarily only run with 1 CPU. We have seen it crash on multiple CPU VMs. Also, Dane Foster appeared to have been using multiple CPUs in his video transcoding VMs. Unfortunately I can't give you more information at the moment. I'm working with Dane to compile easy to follow steps that recreate this failure. I have not been successful in getting this to crash on demand in my environment, but Dane has so we're trying to recreate his. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: nvidia-driver-295.49 is highly unstable
On Sun, 27 May 2012 11:46:23 -0500, y...@rawbw.com wrote: After the recent system upgrade that brought nvidia-driver-295.49 my system began to malfunction. Xorg randomly freezes and gets to 100% CPU (in kde4), switching back from the black terminal takes 30 seconds, some windows don't repaint while windows effects are on, etc. Switching back to 295.05.09 from Feb 11, 2012 fixed the problem. 9400GT I can't believe this is only my problem. I think the version should be rolled back until the problem is fixed. Hmmm I think this is exactly my problem. My desktop at home is working fine, but it's a 4xx and my work machine is a 9xxx. I honestly thought it was a flash problem because it seems to happen most on pages that have flash content. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On Wed, 23 May 2012 17:30:40 -0500, Adrian Chadd adr...@freebsd.org wrote: Hi, can you please, -please- file a PR? And place all of the above information in it so we don't lose it? I'd be glad to post a PR and assist in helping to get it permanently fixed. I certainly don't want this data to get lost and honestly our business uses FreeBSD on VMWare so much that we really need a permanent fix as much as anyone else :-) The reason I've hesitated to post a PR so far is that I didn't have any truly useful or concrete evidence of where the problem lies. After Dane Foster contacted me and told me he could recreate the crash on demand with his workload it was easier to narrow things down. The suggestion that it was an interrupts issue (by possibly Bjoern Zeeb?) and Dane's discovery that his crashes ceased when em0 and mpt0 share an IRQ, but em0 is completely unused was starting to prove there is some strong evidence here in favor of the interrupts issue. Dane, what's the status on your end? Has your fix still been successful? Is it also stable if you simply set hint.mpt.0.msi_enable=1 ? Thanks! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
OK guys I've been talking with another user who can recreate this crash and the last bit of information we've learned seems to be leaning towards interrupts/IRQ issues like someone (bz@ perhaps?) suggested. I'm still trying to test this myself, but the other user was able to recreate my crash pretty much on demand. The fix was to not use the first NIC in the VM because it will always share an IRQ with mpt0. Once mpt0 is on its own the crash does not seem to be reproducible anymore. Before: $ vmstat -i interrupt total rate irq1: atkbd0 378 0 irq6: fdc0 9 0 irq15: ata1 34 0 irq16: em1687237 1 irq18: em0 mpt0319094024539 cpu0: timer236770821400 Total 556552503940 After: $ vmstat -i interrupt total rate irq1: atkbd0 38 0 irq6: fdc0 9 0 irq15: ata1 34 0 irq16: em1 2811 15 irq17: em2 5 0 cpu0: timer71013398 irq256: mpt0 12163 68 Total 86073483 Is there any other way we can make mpt0 get its own dedicated IRQ without having to do this? The problem is that it causes us to have to make rc.conf changes, pf.conf changes, and who knows what other software could be on these machines that is trying to bind to a specific NIC... Thanks! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On Mon, 21 May 2012 12:01:19 -0500, Andrew Boyer abo...@averesystems.com wrote: You could try switching mpt to MSI. MSI interrupts are never shared. Add this to /boot/device.hints: hint.mpt.0.msi_enable=1 Currently implementing this on the known crashy servers. I've been looking around and all of our VM's that do NOT crash also do not share interrupts between em0/mpt0. Thank you very much if this is the fix we will be SO grateful. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
Quick update: I have received word last night that this crash has been consistently happening to someone on FreeBSD 9 and they're looking for more ideas. I changed the following 41 days ago: - Video memory to auto if it wasn't already - SCSI controller changed from LSI Logic Parallel to LSI Logic SAS It uses the same driver (da) but so far has been holding steady for us. As far as the video memory -- many of our servers somehow had video memory set to 1MB which seemed strange; newer builds of FreeBSD on ESXi do not show this option. Perhaps there was a build of ESXi in the past that had a different setting for video memory when you selected FreeBSD? Another change people might want to do as suggested to us by VMWare Support: - Change CPU/MMU Virtualization to the bottom option -- Use Intel VTx/AMD-V for instruction set virtualization and Intel EPT / AMD RVI for MMU virtualization Supposedly there are autodetection issues here with some OSes -- they named some BSDs and Netware. I'll provide further updates if anything changes, but this seems to be working well so far. We won't begin to trust it until we can hit at least 100 days of uptime, though. Unfortunately I was hoping to upgrade these servers to 8.3 before then... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: time stops in vmware
On Tue, 10 Apr 2012 03:04:10 -0500, Daniel Braniss da...@cs.huji.ac.il wrote: no, I can't recreate it, could you? We haven't seen this problem since FreeBSD 6.x. I can't recall how reproducible it was. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: time stops in vmware
On Sun, 08 Apr 2012 02:11:25 -0500, Daniel Braniss da...@cs.huji.ac.il wrote: Hi All There was some mention before that time stops under vmware, and now it's happened to me :-) the clock stopped now, the system is responsive, but eg sleep 1 never finishes. Is there a solution? btw, I'm running 8.2-stable, i'll try 8.3 soon. Can you recreate it? Does it go away if you use kern.hz=200 in loader.conf? We used to have to do that. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
Guys, The crash on my machine with debugging has evaded me for a few days. I'm still looking for further suggestions of things I should grab from the DDB when it happens again. Thanks for the help everyone! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On Fri, 30 Mar 2012 19:49:54 -0500, Adrian Chadd adr...@freebsd.org wrote: There's no guarantee that upgarding a VM or rebooting it won't change the config of said VM. Don't forget to diff the vm config file.. I'm not sure how this would be accomplished Am I supposed to be running backup software (rsync, etc?) on my ESX nodes now so I can capture these VM config files? How would I ever know what changed the VM files when? I'm sure if I called up VMWare and said HEY YOU GUYS YOU BROKE THIS BY CHANGING THESE FILES and then when they asked how I figured it out I told them I installed software that is definitely unsupported on their ESXi server to track it that they would certainly tell me to go pound sand. Working in a black box environment is never fun. :( ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On Fri, 30 Mar 2012 09:44:47 -0500, Joe Greco jgr...@ns.sol.net wrote: Have you migrated these hosts, or were they installed in-place and never moved? fwiw the apparent integrity of things on the VM is consistent with our experience too. VMMotion and StorageVMMotion does not seem to affect the stability. Even deleting the VM, rebuilding from scratch, re-installing all packages from scratch, copying over a few configs and then copying in any other data (perhaps website data) does not solve the problem. However, our two most notorious for crashing happen to be webservers. We moved one to hardware. We simply rsync'd the exact data (entire OS and files) off the VM onto hardware, made a few config changes (fstab, network interface) and it's been running for 4+ months now with zero crashes. I don't think it's corruption :/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On Fri, 30 Mar 2012 11:53:10 -0500, Joe Greco jgr...@ns.sol.net wrote: On the same vmdk files? Deleting the VM makes it sound like not. Fresh new VMDK files every time, and always thick provisioned. None of the other VM's, even the VM's that had been abused in this horribly insensitive manner of being placed on intolerably slow iSCSI, developed this condition. We've seen similar results. Baffling how VMs you know are worse off never develop this condition. There are dozens of other VM's running on these hosts, alongside the one that was exhibiting this behaviour. The VM continued to exhibit this behaviour even after having been moved onto a different ESXi platform and architecture (Opteron-Xeon). For the problem to follow the VM in this manner, and afflict *only* the one VM, strongly suggests that it is something that is contained within the VM files that constitute this VM. That is consistent with the observation that the problem arose at a point where the VM is known to have had all those files moved from one location to a dodgy location. We were hoping that was the explanation as well, but rebuilding the VM entirely from scratch on a new host and seeing the crash come back was a big blow to morale. :( That's why I believe the evidence points to corruption of some sort. Of course, your case makes this all interesting. For the last year I've been convinced it's something hidden inside ESXi's I/O virtualization layer that happens to trigger on only certain VMs. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On Wed, 28 Mar 2012 18:31:38 -0500, Adrian Chadd adr...@freebsd.org wrote: * have you filed a PR? No * is the crash easily reproducable? Unfortunately not. It's totally random. Some servers will get the bug and crash daily, some will crash weekly, some might seem to be fine but 3 months later hit this crash. * are you able to boot some ramdisk-only FreeBSD-8.2 images (eg create a ramdisk image using nanobsd?) and do some stress testing inside that? That's a plan I'd like to execute but my free time for building that environment is rather short at the moment :( I'm not that cluey on ESXi, but there may be some PIC/APIC/ACPI change between 7.x and 8.0 which has caused this to surface. Was there a setting to revert ACPI behavior from 8.x to 7.x? I thought I read about that at one point or perhaps this was something available back in the dev cycle when 8 was -CURRENT. *shrug* I know 9.0 and onward has even more ACPI changes so assuming it truly is an ACPI bug I guess we could cross our fingers and hope that the bug has mysteriously vanished? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On Thu, 29 Mar 2012 02:36:49 -0500, Doug Barton do...@freebsd.org wrote: As much as I'm sensitive to your production requirements, realistically it's not likely that you'll get a helpful result without testing a newer version. 8.2 came out over a year ago, many many things have changed since then. The sad part is that VMWare's supported FreeBSD versions are a joke, and we've been trying to keep VMWare happy by only running supported versions. I honestly don't think they even test. It's so stupid. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
Alright, new data. It happened to crash about 10 minutes after I came in this morning and I ran some stuff in the DDB. I have no idea what information is useful, but perhaps someone will see something out of the ordinary? http://feld.me/freebsd/esx_crash/ Thanks... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On Thu, 29 Mar 2012 09:58:16 -0500, Hans Petter Selasky hsela...@c2i.net wrote: Do both 32- and 64-bit versions of FreeBSD crash? Correct, we see both i386 and amd64 flavors crash in the same way. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On Thu, 29 Mar 2012 10:31:24 -0500, Eduardo Morras nec...@retena.com wrote: Don't know about ESXi but on others VM Managers i can change the chipset emulation from ICH10 to ICH4. Can you change it to an older chipset too? Unfortunately there's no setting in the GUI for that but I'll keep looking to see if there's a hidden option -- perhaps in the VM's config file. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On Thu, 29 Mar 2012 10:55:36 -0500, Hans Petter Selasky hsela...@c2i.net wrote: It almost sounds like the lost interrupt issue I've seen with USB EHCI devices, though disk I/O should have a retry timeout? What does wmstat -i output? --HPS Here's a server that has a week uptime and is due for a crash any hour now: root@server:/# vmstat -i interrupt total rate irq1: atkbd0 34 0 irq6: fdc0 9 0 irq15: ata1 34 0 irq16: em1778061 1 irq17: mpt0 19217711 31 irq18: em0 283674769460 cpu0: timer246571507400 Total 550242125892 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On Thu, 29 Mar 2012 10:49:30 -0500, Joe Greco jgr...@ns.sol.net wrote: I explained it at the time to one of my VMware friends: This is 100% identical to what we see, Joe! And we're so unlucky that we have this happen on probably a dozen servers, but a handful are the really bad ones. We've rebuilt them from scratch many times with no improvement. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On Thu, 29 Mar 2012 12:05:30 -0500, Mark Atkinson atkin...@gmail.com wrote: If this is an interrupt problem with disk i/o, then you might want to look into (DDB(4)) show intr show intrcount maybe show allrman Thank you! I really don't know what things we should be running in DDB to diagnose this and we will try this upon the next crash. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On Thu, 29 Mar 2012 12:24:30 -0500, je...@seibercom.net wrote: I just started reading this tread, but I am wondering if I missed something here. What does this have to do with Windows 7? I emailed him off-list but I'm guessing he thought this was on VMWare Workstation or another product that would virtualize FreeBSD on top of Windows as the host OS. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On Thu, 29 Mar 2012 11:53:02 -0500, Alan Cox alan.l@gmail.com wrote: Not so long ago, VMware implemented a clever scheme for reducing the overhead of virtualized interrupts that must be delivered by at least some (if not all) of their emulated storage controllers: http://static.usenix.org/events/atc11/tech/techAbstracts.html#Ahmad Perhaps, there is a bad interaction between this scheme and FreeBSD's mpt driver. Alan If we assume mpt is the culprit how can I go about diagnosing this more accurately? Is there something I should be looking for in vmstat -i? Too many interrupts? Not enough? Rate too high or too low? Or is this something that is much harder to track down because we're dealing with emulated hardware? If any BSD devs are interested in access to our environment I think we could comply. I might even be able to get authorization to give you an account on the most crash-prone server which doesn't have any sensitive customer data on it. I think at this point we'd even be willing to pay someone to look at a server in this state just so we (and hopefully others) can benefit and hopefully we end up with a more reliable FreeBSD-on-VMWare for everyone. I know Doug mentioned running newer OS versions and that is definitely tempting but because it's not 100% reproducible on demand it's hard to prove it fixes it without waiting 6 months. We're fighting internally here with trust 9.0 fixes it vs jump back to 7.4 because we KNOW it doesn't happen there. Having someone look at this and say oh, yes, that's a deficiency in mpt that appears to be fixed in the newer driver that was MFC'd to 8-STABLE and you'll find in 8.3-RELEASE and 9.0-RELEASE would be more comforting. Thanks to everyone for their time on this! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On Thu, 29 Mar 2012 12:53:49 -0500, Dieter BSD dieter...@engineer.com wrote: FreeBSD ?? - 7.4 never crash FreeBSD 8.0 - 8.2 crashes Obvious short term workaround is to run production on 7.4 (assuming you can) until you figure out what is wrong with 8.x. We're moving our most critical servers to 7.4 this weekend. After finally seeing the crash on ESXi 5.0 we have run out of viable options and we haven't had time to test FreeBSD 9.0 or 8.3 pre-release code. What filesystem(s) are you running? UFS? ZFS? other? Only UFS. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On Thu, 29 Mar 2012 15:53:52 -0500, Adam Vande More amvandem...@gmail.com wrote: Doesn't VMWare offer different types of emulated disk controllers? If so, that might be the easiest way to narrow the field. Another thing maybe to try would be to backport the mpt Yes, they offer Paravirtual (not applicable for FreeBSD), LSI Parallel (default option), LSI SAS, and Buslogic (not available for 64bit). Both LSI SAS and LSI Parallel use the mpt driver. Also, it's not VMWare's place to claim not our problem when you are paying for support. If this doesn't happen on bare metal, it's a VMWare issue, or they need to demonstrate it's not their issue. At least that would be the expectation I have. You're right, but we've thrown a ton of money at their support and had direct phone access to their engineers. The best we can get out of them is no indication this is a VMWare problem. It's easy for them to blow people off when they're as big as they've grown to be. There is also a comment on this post indicating someone else with the issue and who has received unofficial vmware feedback. http://www.hailang.me/tech/virtual/freebsd-vmware-esx-a-weird-error-with-san-storage/ I found that post ages ago and that's me, mf, as the only person to comment on it. Unfortunately our problem does not align with what he's describing. And then there is this one with similar symptoms and a workaround: http://forums.freebsd.org/showthread.php?t=27899 I'm now investigating those loader.conf options. I have my crashy machine set to use them on next boot so we'll see if it crashes now that I'm using LSI SAS emulated controller. If it still crashes, we'll see what happens after that with those loader.conf options enabled. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On Thu, 29 Mar 2012 19:27:31 -0500, Joe Greco jgr...@ns.sol.net wrote: It also doesn't explain the experience here, where one VM basically crapped out but only after a migration - and then stayed crapped out. It would be interesting to hear about your datastore, how busy it is, what technology, whether you're using thin, etc. I just have this real strong feeling that it's some sort of corruption with the vmfs3 and thin provisioned disk format, but it'd be interesting to know if that's totally off-track. We've ruled out SAN, but we haven't ruled out VMFS. Even FreeBSD Guests on standalone ESXi servers with no SAN exhibit this crash. For the record, we only use thick provisioning and if it was corruption I'm not sure what layer the corruption could be at. The crashy servers show no abnormalities when I run either `freebsd-update IPS` or `pkg_libchk` to confirm checksums of all installed programs. Now the other data on there... it's not exactly verified, but our backups via rsnapshot seem to prove there is no issue there or we'd have lots of new files each run. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
Alright guys, I'm at the end of my rope here. For those that haven't seen my previous emails here's the (not so) quick breakdown: Overview: FreeBSD ?? - 7.4 never crash FreeBSD 8.0 - 8.2 crashes FreeBSD 8-STABLE, 8.3, and 9.0 are untested (Sorry, not possible in our production at this time, and we were hoping we could base some stuff on 8.3 for long term stability...) ESXi: Confirmed ESXi 4.0 - 5.0 has this problem. Haven't tested on others. History: Over the course of the last 2 years we've been banging our heads on the wall. VMWare is done debugging this. They claim it's not a VMWare issue. They can't identify what the heck happens. We had a glimmer of hope with ESXi 5.0 fixing it because we never saw any crashes in the handful of deployments, but our dreams were crushed today -- two days before an outage to begin migration to ESXi 5.0 -- when a customer's ESXi 5.0 server and FreeBSD 8.2 guest crashed. Crash Details: The keyboard/mouse usually stops responding for input on the console; normally we can't type in a username or password. However, we can switch VTs. If there's a shell on the console and we can type, we can only run things in memory. Any time we try to access the disk it will hang indefinitely. The server still has network access. We can ping it without issue. SSH of course kicks you out because it can't do any I/O. If we were to serve a lightweight http server off a memory backed filesystem I'm confident it would run just fine as long as it wasn't logging or anything. On ESXi you see that there is a CPU spike of 100% that goes on indefinitely. No idea what the FreeBSD OS itself thinks it is doing because we can't run top during the crash. This crash can affect a server and happen multiple times a week. It can also not show up for 180 days or more. But it does happen. The server can be 100% idle and crash. We have servers that do more I/O than the ones that crash could ever attempt to do and these don't crash at all. Completely inexplicable. Things we've looked into: Nothing about the installed software matters. We've tried cross referencing the crashed servers by the programs they run but the base OS is the only common denominator due to the wide variety of servers it has affected. Storage doesn't matter. We've tried different iSCSI SANs, we've tried different switches, we've tried local datastores on the ESXi servers themselves. HP servers, Dell servers -- doesn't seem to matter either. (All with latest firmwares, BIOSes, etc) VMWare gave us a ton of debugging tasks, and we've given them gigabytes of debugging info and data; they can't find anything. VMWare tools -- with, without, using open-vm-tools makes no difference. I think we've done a fair job ruling out VMWare. I think we've finally found enough data that this is definitely something in the FreeBSD world. I'm going to begin prepping some of the known crashy servers with more debugging. Any suggestions on what I should build the kernel with? They never do a proper panic, but I definitely want to at least *try* to get into the debugger the next time it crashes. And when it crashes, what the heck should I be running? I've never played with the KDB before... Thank you for any suggestions and help you can give me ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: iso2flash img
As an alternative I recently purchased a Zalman ZM-VE200 device (there's also a USB3.0 flavor) that lets you copy ISOs to it and it will emulate a CDROM/DVDROM/BDROM for you so you never have to deal with this mess again. It works amazingly well. I was tired of fighting this problem and this is an amazing solution -- I can keep every ISO I ever need on a single drive. http://www.zalman.com/eng/product/Product_Read.asp?idx=431 http://www.zalman.com/eng/product/Product_Read.asp?idx=459 http://www.rmprepusb.com/tutorials/ve200 Hope that helps someone ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Wed, 18 Jan 2012 13:46:45 -0600, John Kozubik j...@kozubik.com wrote: And as long as we're repeating ... :) Since 9.0 is already out of the bag, I think a decent approach would be to fizzle out 8.x on the current timeline/trajectory (maybe 8.4 in 6-8 months, and maybe 8.5 in a year or so), then: - EOL 7 - mark 8 as legacy - mark 9 as the _only_ production release - release 10.0 in January 2017 And in the meantime, begin the every 4-6 month minor releases that we all agree can occur with 9. By Jan 2017, you get to 9.12 or 9.14 or so. This is nice because no upheaval needs to happen with 7 and 8, and interested developers do not get kneecapped vis a vis 9 - they can just keep going where they were going with it, and the only real change is that 10 is pushed out a long ways, and people[1] get to really sink their teeth into 9. What are the policies for changes though? Are we stuck with 9.0's feature set for 5 years? Will we have to wait 5 years to get a stable release of FreeBSD with KMS/GEM? That work is unfinished and didn't make 9.0; it's also a huge changeset. How will things like this be dealt with? Five years is a long time for the next stable release if we have a policy to not import major changes from -CURRENT. It would be devastating to so many users. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
Why is everyone so afraid of running -STABLE? Plenty of stuff gets MFC'd. Yeah, I agree -- running -RELEASE is difficult. Hell, it's frustrating to us that VMWare only supports -RELEASE and it took until ESX 5 to officially support 8.2! More releases / snapshots of -STABLE helps people on physical servers, but anyone who runs VMs on Xen or VMWare won't get any support for those versions because they didn't go through the QA process yet. FreeBSD is increasingly becoming a third world citizen thanks to virtualization efforts being focused on Linux, so I feel that more frequent releases won't help as many people as you think. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tue, 17 Jan 2012 14:30:20 -0600, Atom Smasher a...@smasher.org wrote: linux is, in fact, an operating system. debian, red hat, ubuntu, gentoo, etc are distributions of that OS. It's not really worth getting into this argument, but I'll reiterate that no, it's not an OS -- it's a kernel. Without the userland utilities the distros provide it's not very usable. Linus and co don't maintain the shell or the rc subsystem or anything like that. They only work on the kernel and in-tree drivers. We need to be comparing FreeBSD to a full blown distro. Cheers ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tue, 17 Jan 2012 12:59:44 -0600, Julian Elischer jul...@freebsd.org wrote: On 1/17/12 9:36 AM, Damien Fleuriot wrote: having run -stable on production systems, the way to do it is: * follow -stable.. * pick a time that IN RETROSPECT (from 1 month later) looks as though it was good. * take a snapshot from that time and test it. * if it has problems MOVE FORWARD (not back) to the next candidate snapshot time. * repeat until you have one that works for you This is also the way I've had it explained to me. Note, I'm currently not running anything -STABLE in production right now simply because I don't have that need. I did for a while last year, but not now. I'm deploying two ZFS SANs based on 9 early February. It might be on -RELEASE with manual backports of the gmultipath rewrite (required) and also I am considering the fixes for CDROM access (CAM stuff). I've seen several other things hit -STABLE right after the freeze ended early January which surprise me that they weren't included in -RELEASE and we didn't have another RC. I definitely see the frustration being expressed here, but I personally am comfortable running -STABLE. Many people are not and it is unfortunate that they will be left waiting until 9.1-RELEASE (probably late summer?). I hope a compromise will be found. I'm clearly in the minority that is OK with the current situation. To be fair, it could be worse -- OpenBSD secretly wants you to run snapshots and CURRENT as the RELEASEs are mostly unmaintained outside of the most extreme security concerns. Even the packages are kept at the exact version of the time of release. Well to be honest, Theo doesn't want me running OpenBSD at all. :-) -Previously Flamed User ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tue, 17 Jan 2012 16:25:12 -0600, Matthew D. Fuller fulle...@over-yonder.net wrote: On Tue, Jan 17, 2012 at 02:50:08PM -0600 I heard the voice of Mark Felder, and lo! it spake thus: I've seen several other things hit -STABLE right after the freeze ended early January which surprise me that they weren't included in -RELEASE and we didn't have another RC. You mean the 9.0-RELEASE that's scheduled to be done (after having already slipped a month) at the beginning of Sept 2011? At some point (well before those add'l patches you're talking about, IMO) you have to STOP and release the damn thing already. Yeah, but how much sense does it make to do a -RELEASE with critical bugs? For example, gmultipath guarantees a panic on various hardware just by breaking a path. This was fixed in a full rewrite discussed this summer and publicized in November. Now anyone with shiny 9.0 (or even 8.2) running gmultipath risks a panic. The fix IS the rewrite. But it's s total rewrite and so patching that onto 9.0 as errata doesn't really make sense (rewrite adds features too), so now the choices for a stable gmultipath is -STABLE or patiently waiting for 9.1. So yeah, 9.0 slipped hard. Perhaps it should have slipped a bit further until blockers like gmultipath and the cdrom/CAM stuff were fully addressed. But it's impossible to release 100% bug free software where exactly *do* you draw the line? :-/ I certainly would not be better than anyone else at managing any portion of this project. I'm just glad I have the ability to find and apply fixes myself when necessary. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD has serious problems with focus, longevity, and lifecycle
On Tue, 17 Jan 2012 15:07:56 -0600, Atom Smasher a...@smasher.org wrote: and how many corps are running openBSD? Works amazingly well as an edge router. You get pf, openbgpd, openspfd much higher performance that 50K cisco gear. The bugs we've hit have been fixed promptly as well. Pretty decent little setup for a budget. But yeah, not many do what we do. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: accepting rtadv broken on 9-STABLE, re driver?
On Sat, 07 Jan 2012 14:23:46 -0600, Hiroki Sato h...@freebsd.org wrote: It is an unexpected behavior and the flag should be set on all interfaces. Can you send me your /etc/rc.conf, /etc/sysctl.conf, and the result of ifconfig -a? Back at work so I have access to the machine again: rc.conf: hostname=tech304.office.xxx.net ifconfig_re0=inet 192.168.93.23/24 defaultrouter=192.168.93.1 ipv6_activate_all_interfaces=YES ipv6_ifconfig_re0=inet6 accept_rtadv sshd_enable=YES linux_enable=YES ntpd_enable=YES ntpdate_enable=YES vboxnet_enable=YES tcp_drop_synfin=YES icmp_log_redirect=YES update_motd=NO dbus_enable=YES hald_enable=YES moused_enable=NO moused_nondefault_enable=NO oss_enable=NO #nginx nginx_enable=YES fcgiwrap_enable=YES fcgiwrap_user=www samba_enable=YES #samba_config=/usr/local/etc/samba34/smb.conf lpd_enable=YES #slim_enable=YES exim_enable=YES sendmail_enable=NONE nfs_client_enable=YES smartd_enable=YES zfs_enable=YES sysctl.conf: # Uncomment this to prevent users from seeing information about processes that # are being run under another UID. #security.bsd.see_other_uids=0 net.inet.tcp.drop_synfin=1 net.inet.icmp.log_redirect=1 vfs.usermount=1 net.inet6.ip6.accept_rtadv=1 # ifconfig -a 11:43:29 tech304:~ ifconfig -a re0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=209bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC ether d0:67:e5:17:e1:32 inet6 fe80::d267:e5ff:fe17:e132%re0 prefixlen 64 scopeid 0x2 inet 192.168.93.23 netmask 0xff00 broadcast 192.168.93.255 inet6 2607:f4e0:100:104:d267:e5ff:fe17:e132 prefixlen 64 autoconf nd6 options=23PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL media: Ethernet autoselect (100baseTX full-duplex) status: active lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 options=3RXCSUM,TXCSUM inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet 127.0.0.1 netmask 0xff00 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL vboxnet0: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 1500 ether 0a:00:27:00:00:00 nd6 options=23PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL Regards, Mark ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: accepting rtadv broken on 9-STABLE, re driver?
On Mon, 09 Jan 2012 13:02:24 -0600, Hiroki Sato h...@freebsd.org wrote: re0 seems to have ACCEPT_RTADV. What is the problem? That's because I haven't rebooted Let's start fresh. The normal ipv6 configuration anyone would use: -ipv6_activate_all_interfaces=YES in rc.conf -NO mention of net.inet6.ip6.accept_rtadv in sysctl.conf I boot up, re0 *does not* have ACCEPT_RTADV. I try forcing via the sysctl: net.inet6.ip6.accept_rtadv=1 Still doesn't work! I finally have to result to: ifconfig re0 inet6 accept_rtadv Why? What makes this machine different? All the other machines I run do not require this to get ACCEPT_RTADV. Is it the re driver? My other machines have em and ath interfaces. Thanks, Mark ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: accepting rtadv broken on 9-STABLE, re driver?
On Mon, 09 Jan 2012 19:56:47 -0600, Hiroki Sato h...@freebsd.org wrote: This is an expected behavior. ACCEPT_RTADV is disabled by default on 9.X. Thanks for clarifying. I'll make sure I update our documentation at work regarding how exactly to get ACCEPT_RTADV working so this is clarified. Regards, Mark ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: accepting rtadv broken on 9-STABLE, re driver?
Hiroki Sato h...@freebsd.org wrote: Is it correct that ACCEPT_RTADV option was enabled on the vboxnet0 and not on re0, even after setting net.inet6.ip6.accept_rtadv to 1 at boot time and ipv6_activate_all_interfaces=YES? -- Hiroki Yes, that is the behavior I witnessed. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
accepting rtadv broken on 9-STABLE, re driver?
Hi guys, I upgraded my desktop at work just around christmas to 9-PRERELEASE builds and ipv6 has been broken since then. I've been too busy at work to fix it but today I finally had the chance to figure it out. Currently I'm running: 12:11:15 tech304:~ uname -a FreeBSD tech304.office.supranet.net 9.0-STABLE FreeBSD 9.0-STABLE #2 r229703M: Fri Jan 6 11:01:58 CST 2012 r...@tech304.office.supranet.net:/usr/obj/tank/svn/sys/GENERIC amd64 and my ipv6 is not working. In rc.conf I have ipv6_enable_all_interfaces=YES which sets the link local and I had net.inet6.ip6.accept_rtadv=1 in sysctl.conf. I can confirm that it was indeed activated in sysctl, but ifconfig didn't think so: re0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=209bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC ether d0:67:e5:17:e1:32 inet6 fe80::d267:e5ff:fe17:e132%re0 prefixlen 64 scopeid 0x2 inet 192.168.93.23 netmask 0xff00 broadcast 192.168.93.255 nd6 options=23PERFORMNUD,AUTO_LINKLOCAL## Where's the ACCEPT_RTADV??? media: Ethernet autoselect (100baseTX full-duplex) status: active I have to manually do # ifconfig re0 inet6 accept_rtadv to get it to work. Am I missing something? Grepping /etc/rc.d/ for rtadv finds no clues. Is this broken for everyone, for the re driver, or am I just crazy? Here's pciconf for the device -- let me know if any further info would be useful: re0@pci0:4:0:0: class=0x02 card=0x04f51028 chip=0x816810ec rev=0x06 hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' class = network subclass = ethernet Thanks, Mark ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: accepting rtadv broken on 9-STABLE, re driver?
On Fri, 06 Jan 2012 12:49:45 -0600, Sergey Kandaurov pluk...@gmail.com wrote: You mean ipv6_activate_all_interfaces=YES ? Yes... Unfortunately that's what I get for typing it manually and being distracted at the time. :-) What is in your rc.conf? Do you have inet6 accept_rtadv keyword in it? IIRC it should be enough to specify ifconfig_re0_ipv6=inet6 accept_rtadv without additional tweaks. Consult with rc.conf(5). I figured I would end up putting that in rc.conf as a temporary fix, but maybe that's just the long term solution. It seems so odd to me that the sysctl change doesn't automatically cause the ACCEPT_RTADV option to show up for re0, but it does for vboxnet0. Perhaps there should be a cleaner way to do this in rc.conf like how we do ifconfig_re0=DHCP ? Thanks, Mark ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Using underlying adX devices as well as ar0?
On Thu, 01 Sep 2011 07:28:37 -0500, Karl Pielorz kpielorz_...@tdx.co.uk wrote: Is it OK to run smartmontools / smartd / smartctl against the underlying adX devices, whilst ar0 is in use? Yes. :-) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: usertime and systime
On Wed, 16 Mar 2011 14:42:22 -0500, Devin Teske dte...@vicor.com wrote: +1 useful. I'd like to see this committed. Agreed. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: rtld optimizations
On Tue, 25 Jan 2011 22:49:11 -0600, Alexander Kabaev kab...@gmail.com wrote: The only extra quirk that said commit does is an optimization of a dlsym() call, which is hardly ever in critical performance path. It's really not my place to say, but it seems strange that if an optimization is available people would ignore it because they don't think it's important enough. I don't understand this mentality; if it's not going to break anything and it obviously can improve performance in certain use cases, why not merge it and make FreeBSD even better? Regards, Mark ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Summary: Re: Spin down HDD after disk sync or before power off
On Wed, 17 Nov 2010 09:37:00 -0600, Alexander Best arun...@freebsd.org wrote: 1) switching to a differnt tty worked, but i couldn't log in (input was simply ignored) I don't mean to derail this thread if this is completely unrelated, but we've been having issues with FreeBSD 8.0 and 8.1 dying on our ESX 4.0 cluster. The usual result is that the machine stops responding to all network activity and at the console you can switch ttys but it doesn't accept any input. We can't find any absolute hard evidence yet, but we think it might have to do with the preferred path changing to the SAN and FreeBSD freaking out. Could this possibly be boiling down to the same core issue? Regards, Mark ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
