Re: posix_fallocate on ZFS

[Patrick Kelsey]

On Mon, Feb 12, 2018 at 12:04 PM, John Baldwin  wrote:

> On Saturday, February 10, 2018 01:46:33 PM Garrett Wollman wrote:
> > In article
> > ,
> > asom...@freebsd.org writes:
> >
> > >On Sat, Feb 10, 2018 at 10:28 AM, Willem Jan Withagen 
> > >wrote:
> >
> > >> Is there any expectation that this is going to fixed in any near
> future?
> >
> > >No.  It's fundamentally impossible to support posix_fallocate on a COW
> > >filesystem like ZFS.  Ceph should be taught to ignore an EINVAL result,
> > >since the system call is merely advisory.
> >
> > I don't think it's true that this is _fundamentally_ impossible.  What
> > the standard requires would in essence be a per-object refreservation.
> > ZFS supports refreservation, obviously, but not on a per-object basis.
> > Furthermore, there are mechanisms to preallocate blocks for things
> > like dumps.  So it *could* be done (as in, the concept is there), but
> > it may not be practical.  (And ultimately, there are ways in which the
> > administrator might manage the system that would defeat the desired
> > effect, but that's out of the standard's scope.)  Given the semantic
> > mismatch, though, I suspect it's unreasonable to expect anyone to
> > prioritize implementation of such a feature.
>
> I don't think posix_fallocate() can be compatible with COW.  Suppose you
> do reserve a fixed set of blocks.  That ensures the first write has a
> place to write, but not if you overwrite one of those blocks.  You'd have
> to reserve another block to maintain the reservation each time you wrote
> to a block, or you'd have to have a way to mark a file as not COW.  The
> first case isn't really any better than not using posix_fallocate() in the
> first place as you are still requiring writes to allocate blocks, and the
> second seems a bit fraught with peril as well if the application is
> expecting the non-COW'd file to be in sync with other files in the system
> since presumably non-COW'd files couldn't be snapshotted, etc.
>
>
I think Garrett's assessment that it is not fundamentally impossible, but
may not be felt to be worth implementing in any given file system for
practical reasons, is correct.  I say this having designed/implemented a
COW file system that was driven by customer pressure to do things that at
first pass one might declare represented an architectural contradiction,
but upon further reflection were entirely possible to do given sufficient
willingness to invest the effort and accept the accompanying trade-offs,
additional knobs to turn, etc.

In this case (posix_fallocate() + COW + snapshots), it could be implemented
with a per-object allocator that normally keeps at least one extra block
beyond the reservation requirement on hand, plus a snapshot operation that
in order to succeed has to be able to provision the local allocators of all
fallocated objects with enough additional blocks to maintain the no-fail
write guarantee post-snapshot.

-Patrick
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: New ACPI Errors

[Claude Buisson]

On 02/13/2018 22:49, Pete Wright wrote:

Hello,
I have started seeing a lot of these messages spam my system log:

ACPI Error: No pointer back to namespace node in package 
0xf8000f79a080 (20180209/dsargs-472)
ACPI Error: Method parse/execution failed \134_SB.AC.ADJP, 
AE_AML_INTERNAL (20180209/psparse-677)
ACPI Error: Method parse/execution failed \134_SB.AC._PSR, 
AE_AML_INTERNAL (20180209/psparse-677)


I noticed this starting from a CURRENT build i installed two weeks ago, 
and still see it from a world/kernel i built last night.  two questions:

1) has anyone else noticed this?
2) is this something to worry about?

i can help debug the issue but am not sure where to start poking.

thanks!
-pete


Here I have

ACPI Error: No pointer back to namespace node in package 
0xf8000171f700 (20180209/dsargs-472)
ACPI Error: AE_AML_INTERNAL, While resolving operands for [OpcodeName 
unavailable] (20180209/dswexec-606)
ACPI Error: Method parse/execution failed 
\134_PR.CPU0._CST,AE_AML_INTERNAL (20180209/psparse-677)


with svn 329142 on a Lenovo ThinkCentre M83
ACPI APIC Table: 

Claude Buisson
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

New ACPI Errors

[Pete Wright]

Hello,
I have started seeing a lot of these messages spam my system log:

ACPI Error: No pointer back to namespace node in package 
0xf8000f79a080 (20180209/dsargs-472)
ACPI Error: Method parse/execution failed \134_SB.AC.ADJP, 
AE_AML_INTERNAL (20180209/psparse-677)
ACPI Error: Method parse/execution failed \134_SB.AC._PSR, 
AE_AML_INTERNAL (20180209/psparse-677)


I noticed this starting from a CURRENT build i installed two weeks ago, 
and still see it from a world/kernel i built last night.  two questions:

1) has anyone else noticed this?
2) is this something to worry about?

i can help debug the issue but am not sure where to start poking.

thanks!
-pete

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: buildkernel with PORTS_MODULES fails: Variable OBJTOP is recursive

[Conrad Meyer]

On Tue, Feb 13, 2018 at 6:02 AM, David Wolfskill  wrote:
> On Tue, Feb 13, 2018 at 12:48:19PM +0300, Vladimir Zakharov wrote:
>> 
>> > > It seems, setting WITH_AUTO_OBJ in /etc/src-env.conf causes an error.
>> > > At least, removing it fixes build for me.
>
> FWIW, I have never specified WITH_AUTO_OBJ -- and I do encounter the
> "Variable OBJTOP is recursive" during the "make install kernel" phase
> unless I take evasive action (patches).

FYI, it is on by default since r325520.

Best,
Conrad
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: buildkernel with PORTS_MODULES fails: Variable OBJTOP is recursive

[Bryan Drewery]

On 2/13/2018 1:48 AM, Vladimir Zakharov wrote:
> On Mon, Feb 12, 2018, Bryan Drewery wrote:
>> On 2/12/2018 6:54 AM, Vladimir Zakharov wrote:
>>> Hello, Bryan!
>>>
>>> On Fri, Feb 09, 2018, Bryan Drewery wrote:
 On 2/1/2018 1:10 AM, Vladimir Zakharov wrote:
> Hello!
>
> For some time (about a week) building and installing kernel fails with
> the error "Variable OBJTOP is recursive." when going to build/install
> module from ports.
>
> Last successful build was at r328426. Next build at r328527 failed and
> still broken at r328649.
>
> Without PORTS_MODULES building and installing kernel succeeds. Another
> workaround: ignore error and build/install module directly from ports.
> ...

 For some reason I cannot recreate this issue.
>>>
>>> It seems, setting WITH_AUTO_OBJ in /etc/src-env.conf causes an error.
>>> At least, removing it fixes build for me.
>>>
>>> Build successful with the following settings:
>>> # cat /etc/src-env.conf
>>> WITH_META_MODE=
>>> #WITH_AUTO_OBJ=
>>>
>>
>> Please try this patch (requires a buildkernel).
>>
>> https://people.freebsd.org/~bdrewery/patches/kernel-portsmodules.diff
>>
> 
> Fixed partly:
> | buildkernel  | installkernel |
> r329196 | OK   | FAIL(*)   |
> r329169 + patch | OK   | OK|
> r329196 + WITH_AUTO_OBJ | FAIL |   |
> r329169 + WITH_AUTO_OBJ + patch | FAIL |   |
> 
> (*) - same error "Variable OBJTOP is recursive".
> 

Thanks, r329232 should fix it.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: devd in r329188M don't start

[Alex V. Petrov]

Yes, for me it works.
Thank you.

13.02.2018 19:50, Hans Petter Selasky пишет:
> On 02/13/18 10:47, Jakob Alvermark wrote:
>> +1
>>
>> My USB mouse was working fine before the switch to devmatch. Now I
>> have to 'kldload ums' manually.
>>
>> Same for USB audio, snd_uaudio.ko was loaded by devd before.
>>
> 
> Hi,
> 
> This is a known issue.
> 
> Can you try the attached patch?
> 
> Rebuild devmatch(8) and reinstall /etc/devd/devmatch.conf and
> /etc/rc.d/devmatch only.
> 
> --HPS
> 
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

-- 
-
Alex.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: buildkernel with PORTS_MODULES fails: Variable OBJTOP is recursive

[David Wolfskill]

On Tue, Feb 13, 2018 at 12:48:19PM +0300, Vladimir Zakharov wrote:
> 
> > > It seems, setting WITH_AUTO_OBJ in /etc/src-env.conf causes an error.
> > > At least, removing it fixes build for me.

FWIW, I have never specified WITH_AUTO_OBJ -- and I do encounter the
"Variable OBJTOP is recursive" during the "make install kernel" phase
unless I take evasive action (patches).

> ...
> > Please try this patch (requires a buildkernel).
> > 
> > https://people.freebsd.org/~bdrewery/patches/kernel-portsmodules.diff
> > 
> 
> Fixed partly:
> | buildkernel  | installkernel |
> r329196 | OK   | FAIL(*)   |
> r329169 + patch | OK   | OK|
> r329196 + WITH_AUTO_OBJ | FAIL |   |
> r329169 + WITH_AUTO_OBJ + patch | FAIL |   |
> 
> (*) - same error "Variable OBJTOP is recursive".
> 

In my case, I started with r329155, updated sources to r329197,
reverted an earlier patch to src/sys/conf/kern.post.mk, applied the
above, and rebuilt with no issues -- both on my headless build machine
(which runs a GENERIC kernel, has no kernel modules from ports, did not
exhibit the problem, and verified that the patch doesn't break the
"vanilla" configuration.

My laptop, which runs a moderately-customized kernel ("CANARY") based on
GENERIC, uses the x11/nvidia-driver-340 kernel module, and has exhibited
the problem in the past, made it through the build/install/smoke test
without issue (with the above patch).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
The circus around that memo helps confirm that Mr. Trump is unfit for office.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: devd in r329188M don't start

[Hans Petter Selasky]

On 02/13/18 10:47, Jakob Alvermark wrote:

+1

My USB mouse was working fine before the switch to devmatch. Now I have 
to 'kldload ums' manually.


Same for USB audio, snd_uaudio.ko was loaded by devd before.



Hi,

This is a known issue.

Can you try the attached patch?

Rebuild devmatch(8) and reinstall /etc/devd/devmatch.conf and 
/etc/rc.d/devmatch only.


--HPS
Index: etc/defaults/rc.conf
===
--- etc/defaults/rc.conf	(revision 329193)
+++ etc/defaults/rc.conf	(working copy)
@@ -41,7 +41,8 @@
 ddb_config="/etc/ddb.conf"	# ddb(8) config file.
 devd_enable="YES" 	# Run devd, to trigger programs on device tree changes.
 devd_flags=""		# Additional flags for devd(8).
-devmatch_enable="YES"	# Demand load kernel modules based on device ids.
+devmatch_enable="YES"	# Demand load kernel modules based on device IDs.
+devmatch_flags=""	# Additional flags for devmatch(8).
 #kld_list="" 		# Kernel modules to load after local disks are mounted
 kldxref_enable="NO"	# Build linker.hints files with kldxref(8).
 kldxref_clobber="NO"	# Overwrite old linker.hints at boot.
Index: etc/devd/devmatch.conf
===
--- etc/devd/devmatch.conf	(revision 329194)
+++ etc/devd/devmatch.conf	(working copy)
@@ -7,14 +7,10 @@
 # loading what modules we can based on nomatch
 # events.
 #
-# Generic NOMATCH event
+
+# USB NOMATCH event
 nomatch 100 {
-	action "service devmatch start";
+	match "bus" "uhub[0-9]+";
+	action "/etc/rc.d/devmatch start 'bus=usb device=$ugen vendor=$vendor product=$product devclass=$devclass devsubclass=$devsubclass devprotocol=$devproto release=$release intclass=$intclass intsubclass=$intsubclass intprotocol=$intprotocol mode=$mode'";
 };
 
-# Add the following to devd.conf to prevent this from running:
-# 	nomatch 1000 {
-#		action "true";
-#	};
-# it replaces the generic event with one of higher priority that
-# does nothing. You can also set 'devmatch_enable=NO' in /etc/rc.conf
Index: etc/rc.d/devmatch
===
--- etc/rc.d/devmatch	(revision 329193)
+++ etc/rc.d/devmatch	(working copy)
@@ -38,17 +38,54 @@
 start_cmd="${name}_start"
 stop_cmd=':'
 
-devmatch_start()
+fixed_pnpinfo=${2}
+
+devmatch_start_default()
 {
 	local x
+	local m
 
-	x=$(devmatch | sort -u)
+	x=$(devmatch $devmatch_flags | sort -u)
 
-	[ -n "$x" ] || return
+	#
+	# Load modules one by one, because
+	# kldload will bail out on the first
+	# failure:
+	#
+	for m in ${x}
+	do
+		echo "Autoloading module: ${m}"
+		kldload -n ${m}
+	done
+}
 
-	echo "Autoloading modules: ${x}"
-	kldload ${x}
+devmatch_start_pnpinfo()
+{
+	local x
+	local m
+
+	x=$(devmatch -p "$fixed_pnpinfo" | sort -u)
+
+	#
+	# Load modules one by one, because
+	# kldload will bail out on the first
+	# failure:
+	#
+	for m in ${x}
+	do
+		echo "Autoloading module: ${m}"
+		kldload -n ${m}
+	done
 }
 
+devmatch_start()
+{
+	if [ "$fixed_pnpinfo" ]; then
+		devmatch_start_pnpinfo
+	else
+		devmatch_start_default
+	fi
+}
+
 load_rc_config $name
 run_rc_command "$1"
Index: sbin/devmatch/devmatch.8
===
--- sbin/devmatch/devmatch.8	(revision 329193)
+++ sbin/devmatch/devmatch.8	(working copy)
@@ -25,7 +25,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd February 12, 2018
+.Dd February 13, 2018
 .Dt DEVMATCH 8
 .Os
 .Sh NAME
@@ -33,9 +33,10 @@
 .Nd print information about unattached devices
 .Sh SYNOPSIS
 .Nm
-.Op Fl aduv
+.Op Fl adpuv
 .Op Fl -all
 .Op Fl -dump
+.Op Fl -pnpinfo
 .Op Fl -unbound
 .Op Fl -verbose
 .Sh DESCRIPTION
@@ -50,6 +51,8 @@
 Produce a human readable dump of the
 .Pa linker.hints
 file.
+.It Fl p Fl -pnpinfo
+Specify plug and play information to be used when matching a driver.
 .It Fl u Fl -unbound
 Attempt to produce a list of those drivers with PNP info whose driver
 tables with that PNP info can't be found.
Index: sbin/devmatch/devmatch.c
===
--- sbin/devmatch/devmatch.c	(revision 329193)
+++ sbin/devmatch/devmatch.c	(working copy)
@@ -47,6 +47,7 @@
 static struct option longopts[] = {
 	{ "all",		no_argument,		NULL,	'a' },
 	{ "dump",		no_argument,		NULL,	'd' },
+	{ "pnpinfo",		required_argument,	NULL,	'p' },
 	{ "unbound",		no_argument,		NULL,	'u' },
 	{ "verbose",		no_argument,		NULL,	'v' },
 	{ NULL,			0,			NULL,	0 }
@@ -59,6 +60,7 @@
 
 static void *hints;
 static void *hints_end;
+static const char *fixed_pnpinfo;
 
 static void
 read_linker_hints(void)
@@ -137,36 +139,83 @@
 }
 
 static int
+extract_key(char *key, const char *val, int size, char end)
+{
+	char *old = key;
+
+	/* prepend a space character */
+	*key++ = ' ';
+	size--;
+
+	/* extract key */
+	while (1) {
+		if (*val == '\0' || *val == ';')
+			break;
+		if (size < 3) {
+			warnx("Key is too long.");
+			return (-1);
+		}
+		*key++ = *val++;
+		size--;
+	}
+
+	/* append end character, if 

Re: devd in r329188M don't start

[Jakob Alvermark]

+1

My USB mouse was working fine before the switch to devmatch. Now I have 
to 'kldload ums' manually.


Same for USB audio, snd_uaudio.ko was loaded by devd before.


Jakob


On 02/13/18 10:34, Alex V. Petrov wrote:

Why is not the driver loaded when the mouse is connected?

13.02.2018 16:19, Hans Petter Selasky пишет:

On 02/13/18 10:20, Alex V. Petrov wrote:

usb.conf is not found anywhere in the system. This is normal?

devmatch is supposed to replace usb.conf . The contents of usb.conf is
now part of the linker hints, /boot/kernel/linker.hints .

--HPS



___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: buildkernel with PORTS_MODULES fails: Variable OBJTOP is recursive

[Vladimir Zakharov]

On Mon, Feb 12, 2018, Bryan Drewery wrote:
> On 2/12/2018 6:54 AM, Vladimir Zakharov wrote:
> > Hello, Bryan!
> > 
> > On Fri, Feb 09, 2018, Bryan Drewery wrote:
> >> On 2/1/2018 1:10 AM, Vladimir Zakharov wrote:
> >>> Hello!
> >>>
> >>> For some time (about a week) building and installing kernel fails with
> >>> the error "Variable OBJTOP is recursive." when going to build/install
> >>> module from ports.
> >>>
> >>> Last successful build was at r328426. Next build at r328527 failed and
> >>> still broken at r328649.
> >>>
> >>> Without PORTS_MODULES building and installing kernel succeeds. Another
> >>> workaround: ignore error and build/install module directly from ports.
> >>> ...
> >>
> >> For some reason I cannot recreate this issue.
> > 
> > It seems, setting WITH_AUTO_OBJ in /etc/src-env.conf causes an error.
> > At least, removing it fixes build for me.
> > 
> > Build successful with the following settings:
> > # cat /etc/src-env.conf
> > WITH_META_MODE=
> > #WITH_AUTO_OBJ=
> > 
> 
> Please try this patch (requires a buildkernel).
> 
> https://people.freebsd.org/~bdrewery/patches/kernel-portsmodules.diff
> 

Fixed partly:
| buildkernel  | installkernel |
r329196 | OK   | FAIL(*)   |
r329169 + patch | OK   | OK|
r329196 + WITH_AUTO_OBJ | FAIL |   |
r329169 + WITH_AUTO_OBJ + patch | FAIL |   |

(*) - same error "Variable OBJTOP is recursive".

-- 
Regards, | "In theory there is no difference between theory
  Vladimir Zakharov  | and practice. In practice there is."- Yogi Berra
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: devd in r329188M don't start

[Alex V. Petrov]

Why is not the driver loaded when the mouse is connected?

13.02.2018 16:19, Hans Petter Selasky пишет:
> On 02/13/18 10:20, Alex V. Petrov wrote:
>> usb.conf is not found anywhere in the system. This is normal?
> 
> devmatch is supposed to replace usb.conf . The contents of usb.conf is
> now part of the linker hints, /boot/kernel/linker.hints .
> 
> --HPS
> 

-- 
-
Alex.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: devd in r329188M don't start

[Hans Petter Selasky]

On 02/13/18 10:20, Alex V. Petrov wrote:

usb.conf is not found anywhere in the system. This is normal?


devmatch is supposed to replace usb.conf . The contents of usb.conf is 
now part of the linker hints, /boot/kernel/linker.hints .


--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: devd in r329188M don't start

[Alex V. Petrov]

Mouse start work only after handly:
kldload ums

usb.conf is not found anywhere in the system. This is normal?


13.02.2018 15:08, Hans Petter Selasky пишет:
> On 02/13/18 09:02, Alex V. Petrov wrote:
>> after update, devd don't starting with:
>> devd: Cannot parse /etc/devd/devmatch.conf at line 13
>>
>> (file default!)
>>
>> If I disable it, don't work mouse in xorg.
>>
> 
> https://svnweb.freebsd.org/changeset/base/329194
> 
> --HPS
> 

-- 
-
Alex.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: devd in r329188M don't start

[Alex V. Petrov]

In /var/log/messages:
devd: line 13: }: syntax error

File /etc/devd/devmatch.conf (11-13 lines):
nomatch 100 {
action "service devmatch start"
};

13.02.2018 15:08, Hans Petter Selasky пишет:
> On 02/13/18 09:02, Alex V. Petrov wrote:
>> after update, devd don't starting with:
>> devd: Cannot parse /etc/devd/devmatch.conf at line 13
>>
>> (file default!)
>>
>> If I disable it, don't work mouse in xorg.
>>
> 
> https://svnweb.freebsd.org/changeset/base/329194
> 
> --HPS
> 

-- 
-
Alex.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: devd in r329188M don't start

[Hans Petter Selasky]

On 02/13/18 09:02, Alex V. Petrov wrote:

after update, devd don't starting with:
devd: Cannot parse /etc/devd/devmatch.conf at line 13

(file default!)

If I disable it, don't work mouse in xorg.



https://svnweb.freebsd.org/changeset/base/329194

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: devd in r329188M don't start

[Hans Petter Selasky]

On 02/13/18 09:02, Alex V. Petrov wrote:

after update, devd don't starting with:
devd: Cannot parse /etc/devd/devmatch.conf at line 13

(file default!)

If I disable it, don't work mouse in xorg.



I think there is a missing ";" at the end of line 13. Try adding one.

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: VIMAGE: vnet, epair and lots of jails on bridgeX - routing

[O. Hartmann]

On Sat, 10 Feb 2018 09:54:49 +0100
Marko Zec  wrote:

> On Sat, 10 Feb 2018 08:52:21 +0100
> "O. Hartmann"  wrote:
> 
> > Am Fri, 09 Feb 2018 16:43:17 +
> > "Bjoern A. Zeeb"  schrieb:
> >   
> > > On 9 Feb 2018, at 16:22, O. Hartmann wrote:
> > > 
> > > > Am Thu, 8 Feb 2018 09:31:15 +0100
> > > > "O. Hartmann"  schrieb:
> > > >
> > > > Is this problem to trivial?  
> > > 
> > > I read through it yesterday and found myself in the position that I
> > > need a whiteboard or paper and pencil or an ASCII art of your
> > > situation.  But by the time I made it to the question I was
> > > basically lost.  Could you massively simplify this and maybe
> > > produce the ASCII art?
> > > 
> > > /bz
> > > ___
> > > freebsd-current@freebsd.org mailing list
> > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > To unsubscribe, send any mail to
> > > "freebsd-current-unsubscr...@freebsd.org"
> > 
> > All right.
> > 
> > I'm not much of an artist and at this very moment, I haven't much
> > experience with neat ASCII art tools. But I'll provide a sketch
> > later, but I also will simplify  the situation.
> > 
> > Consider three "vswitches", basically based on the creation of
> > bridges, bridge0, bridge1, bridge2. Create at least three individual
> > vnet-jails attached to each vbridge. Those jails have epair pseudo
> > devices. The jail itself owns the "a-part" of the epair and the
> > b-part is "member of the bridge". Each jail's epairXXXa has an IP
> > assigned of the network the vswitch is part of. I mention a- and
> > b-part of the epair here, because I thought it could matter, but I
> > think for symmetry reasons it doesn't.
> > 
> > Now consider a further, special jail. This jail is supposed to have
> > three epair devices, each one is reaching into one of the vbridges.
> > This jail is the router/routing jail. Later, this jail should filter
> > via IPFW the traffic between the three vbridges according to rules,
> > but this doesn't matter here, beacuase the basics are not working as
> > expected.
> > 
> > Now the problems. It doesn't matter on which jail of the three
> > vswitches I login, the moment a vbridge has more than two member
> > epairs (one  is alway member of the routing jail, now consider a
> > database jail and a webserver jail), pinging each jail or the routing
> > jail fails. It works sometimes for a couple of ICMP packets and then
> > stops.
> > 
> > If each vbridge has only one member jail, I have NO PROBLEMS
> > traversing accordingly to the static routing rules from one vbridge
> > to any other, say from vbridge1 to vbridge0 or vbridge2 and any
> > permutation of that.
> > 
> > The moment any of the bridges gets an additional member epair
> > interface (so the bridge has at least three members including the on
> > reaching into the virtual router jail) the vbridge seems to operate
> > unpredictable (to me). Pinging jails memeber of that vbridge are
> > unreachable.
> > 
> > Technical information:
> > 
> > The kernel has options IPFIREWALL, VIMAGE. The host's ipfw (kernel)
> > declines packets by default. Each jail is configured to have ipfw
> > "open".
> > 
> > Thanks for the patience.  
> 
> If you could provide a script which sets up the topology you described
> in two lengthy posts then others could reproduce this, and your chances
> of getting useful feedback would certainly increase.
> 
> We also have a graphical tool (https://github.com/imunes/imunes) which
> can set up a topology like you described in a few clicks of a mouse,
> albeit using netgraph and ng_eiface instead of epairs, but I assume this
> is irellevant as long as you are not aiming for maximum packet
> throughputs.  If you attempt to use this tool, note that selecting
> "stpswitch" will create if_bridge instances, whereas "lanswitch"
> creates ng_bridge instances.
> 
> Good luck,
> 
> Marko
> 
> 
> > 
> > Kind regards,
> > 
> > O. Hartmann  
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Hello Marko,

thanks for your response. First of all: I looked at "imunes". From the first
glimpse it looks great! Something really usefull; I regret not having a port
for this tool or the chance to package it via poudriere.

The problems I faced seem to be related to a bug Olivier Cochard-Labbe pointed
me at:

 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176671

Checking the MAC of the epairs created revealed, that either doubles or even
more occur on the host side of the epair (in my case, all the b-parts of an
epair), or, if there is nothing irregular, then the a-parts (owned by the
VIMAGE jail) have same MAC. The more jails I create, the more ambiguous MACs
are present.

It is the 

devd in r329188M don't start

[Alex V. Petrov]

after update, devd don't starting with:
devd: Cannot parse /etc/devd/devmatch.conf at line 13

(file default!)

If I disable it, don't work mouse in xorg.

-- 
-
Alex.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"