MPS LSI Driver status FreeBSD9 Beta3?
hi, does anybody use the mps driver (if available) with Release9-Beta3? the mps driver from 8.2 has problems with two paths over a LSI SAS 6160 Switch. eg. timeouts ... . Workaround: poweroff the second switch. So it's interesting how stable/far the mps is from FB 9 Beta3 cu denny signature.asc Description: This is a digitally signed message part
Re: MPS LSI Driver status FreeBSD9 Beta3?
On Thu, Oct 20, 2011 at 3:56 AM, Denny Schierz wrote: > hi, > > does anybody use the mps driver (if available) with Release9-Beta3? > > the mps driver from 8.2 has problems with two paths over a LSI SAS 6160 > Switch. eg. timeouts ... . Workaround: poweroff the second switch. > > So it's interesting how stable/far the mps is from FB 9 Beta3 > > cu denny Denny, I don't have the same hardware so cannot test, but I only see a couple of changes committed to HEAD not MFC'd back to 8-STABLE: http://freshbsd.org/commit/freebsd/r225950 (significant CAM changes) http://freshbsd.org/commit/freebsd/r226118 (zeroing SCSI sense, probably minor) This was only a cursory check; you can spelunk around yourself more here: http://freshbsd.org/search?branch=RELENG_8&project=freebsd&q=mps_sas.c http://freshbsd.org/search?branch=HEAD&project=freebsd&q=mps_sas.c Royce ___ 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: MPS LSI Driver status FreeBSD9 Beta3?
Am 20.10.2011 um 18:14 schrieb Royce Williams: > > Denny, I don't have the same hardware so cannot test, but I only see a > couple of changes committed to HEAD not MFC'd back to 8-STABLE: thanks for the tip. I wrote Ken Smith a mail about the problems. cu denny ___ 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"
zfs parition probing causing long delay at BTX loader
Installing a new machine here which has 10+ disks
we're seeing BTX loader take 50+ seconds to enumerate
the disks.
After doing some digging I found the following thread
on the forums which hinted that r198420 maybe the
cause.
http://forums.freebsd.org/showthread.php?t=12705
A quick change to zfs.c reverting the change to
support 128 partitions back to 4 and BTX completes
instantly like it used to.
svn commit which introduced this delay is:-
http://svnweb.freebsd.org/base?view=revision&revision=198420
the specific file in that changeset:-
http://svnweb.freebsd.org/base/head/sys/boot/zfs/zfs.c?r1=198420&r2=198419&pathrev=198420
So the questions are:-
1. Can this be optimised so it doesn't have to test all
of the possible 128 GPT partitions?
2. If a optimisation isn't possible or is too complex to
achieve would it be better to have the partitions defined
as an option which can be increased if needed as I suspect
99.99% if not 100% of users won't be making use of more
than 4 partitions even with GPT, such as what the attached
patch against 8.2-RELEASE achieves.
Regards
Steve
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.
In the event of misdirection, illegible or incomplete transmission please
telephone +44 845 868 1337
or return the E.mail to postmas...@multiplay.co.uk.
--- sys/boot/zfs/zfs.c.orig 2011-10-20 18:15:29.966685430 +
+++ sys/boot/zfs/zfs.c 2011-10-20 18:18:22.291033636 +
@@ -45,6 +45,12 @@
#include "zfsimpl.c"
+/*
+ * For GPT this should be 128 but leads to 50+ second delay in BTX loader so
+ * we use the original 4 pre r198420 by default for the boot process
+ */
+#define ZFS_MAX_SLICES 4
+
static int zfs_open(const char *path, struct open_file *f);
static int zfs_write(struct open_file *f, void *buf, size_t size, size_t
*resid);
static int zfs_close(struct open_file *f);
@@ -415,7 +421,7 @@
if (vdev_probe(vdev_read, (void*) (uintptr_t) fd, 0))
close(fd);
- for (slice = 1; slice <= 128; slice++) {
+ for (slice = 1; slice <= ZFS_MAX_SLICES; slice++) {
sprintf(devname, "disk%dp%d:", unit, slice);
fd = open(devname, O_RDONLY);
if (fd == -1) {
___
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"
Accessing tun devices from inside a Jail
Hi all, I'm currently attempting to setup, I suppose you'd call it a multi-VPN-tunnel gateway. Basically I have several OpenVPN Servers in different locations, I want to have various tunnels up to them and be able to choose an exit by way of pointing my browser at a particular instance of Squid running in a particular jail which routes via a particular tunnel (HTTP/S traffic is the primary concern at this point, though I might want to extend the concept to all traffic in future). First issue I ran into was routing tables, that was resolved by recompiling my kernel with option ROUTETABLES=10 and pointing each of my jails to their own FIB, however as it's not possible to configure route tables from inside the jail (as far as I'm aware anyway) I need to bring the OpenVPN tunnel up from the host and utilise a route-up script to configure the routing table for the jail (utilising setfib), I run into problems though, as even though the tun device is visible in the jail it does not appear to be configured (no IP addersses, etc) so the jail is unable to route traffic. All the stuff I've been able to find online has been geared to static addresses on each end of the tunnel, this is not the case with my VPN provider, tunnel addresses are dynamically assigned. I think that worst case I can probably use pf on the host to route traffic from a given jail via a particular interface or possibly cobble something up around VIMAGE, but I think I'd rather not have to go down those paths. I'm not sure if what I'm looking for is actually possible, any suggestions would be much appreciated. Thanks, Morgan ___ 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: Accessing tun devices from inside a Jail
On Thu, Oct 20, 2011 at 9:02 PM, Morgan Reed wrote: > > I think that worst case I can probably use pf on the host to route > traffic from a given jail via a particular interface or possibly > cobble something up around VIMAGE, but I think I'd rather not have to > go down those paths. > > I'm not sure if what I'm looking for is actually possible, any > suggestions would be much appreciated. > To me, this seems like one of reasons VIMAGE was created. Here's more of an outline if you're looking to evaluate it further. http://druidbsd.sourceforge.net/vimage.html -- 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"
