[Bug 240685] netgraph/ng_vlan_rotate: IEEE 802.1ad VLAN manipulation netgraph node type (new type)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240685 Bug ID: 240685 Summary: netgraph/ng_vlan_rotate: IEEE 802.1ad VLAN manipulation netgraph node type (new type) Product: Base System Version: 12.0-STABLE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: l...@donnerhacke.de Created attachment 207625 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=207625&action=edit Patch for netgraph/ng_vlan_rotate module I need to deal with carrier ethernet solutions which stack a couple of VLANs in transport. In order to deal with the packets, the VLAN stack needs to be manipulated. This new netgragh node will handle such issues. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 240685] netgraph/ng_vlan_rotate: IEEE 802.1ad VLAN manipulation netgraph node type (new type)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240685 --- Comment #1 from l...@donnerhacke.de --- For the sake of reasoning I'll provide the formatted man page as a comment: NG_VLAN_ROTATE(4) FreeBSD Kernel Interfaces Manual NG_VLAN_ROTATE(4) NAME ng_vlan_rotate - IEEE 802.1ad VLAN manipulation netgraph node type SYNOPSIS #include #include #include DESCRIPTION The vlan_rotate node type manipulates the order of VLAN tags of frames tagged according to the IEEE 802.1ad (an extension of IEEE 802.1Q) standard between different hooks. Each node has four special hooks, original, ordered, excessive, and incomplete. A frame tagged with an arbitrary number of ETHERTYPE_VLAN, ETHERTYPE_QINQ, and 0x9100 tags received on the original hook will be rearranged to a new order of those tags and is sent out the "ordered" hook. After successful processing the histogram counter for the observed stack size increments. If it contains fewer VLANs in the stack, than the configured min limit, the frame is send out to the incomplete hook and the incomplete counter increments. If it contains more VLANs in the stack, than the configured max limit, the frame is send out to the excessive hook and the excessive counter increments. If any destination hook is not connected, the frame is dropped and the drops counter increments. For Ethernet frames received on the ordered hook, the transformation is reversed and is passed to the original hook. Please note, that this process is identical to the one described above, besides the ordered/original hooks and the transformation are swapped. An Ethernet frame received on incomplede or excessive hook is forwarded to the original hook without any modification. This node supports only one operation at the moment: Rotation of the VLANs in the stack. Setting the configuration parameter rot to a positive value, the stack will roll up by this amount. Negative values will roll down. A typical scenario is setting the value to 1 in order to bring the innermost VLAN tag to the outmost level. Rotation includes the VLAN id and the ethertype, but the QOS paramenters pcp and cfi stay in place. Typical QOS handling refers to the outmost setting, so this scheme keeps QOS intact. HOOKS This node type supports the following hooks: originalTypically this hook would be connected to a ng_ether(4) node, using the lower hook connected to a carrier network. ordered Typically this hook would be connected to a ng_vlan(4) type node using the downstream hook in order to seperate services. excessive see below. incomplete Typically those hooks would be attached to an ng_eiface(4) type node using the ether hook for anomaly monitoring purposes. CONTROL MESSAGES This node type supports the generic control messages, plus the following: NGM_VLANROTATE_GET_CONF (getconf) Read the current configuration. NGM_VLANROTATE_SET_CONF (setconf) Set the current configuration. NGM_VLANROTATE_GET_STAT (getstat) Read the current statistics. NGM_VLANROTATE_CLR_STAT (clrstat) Zeroize the statistics. NGM_VLANROTATE_GETCLR_STAT (getclrstat) Read the current statistics and zeroize it in one step. EXAMPLES The first example demonstrates how to rotate double or triple tagged frames so, that the innermost C-VLAN can be used as service discriminator. The single or double tagged frames (C-VLAN removed) are send out the an interface pointing to different infrastucture. #!/bin/sh BNG_IF=ixl3 VOIP_IF=bge2 ngctl -f- < 00:01:02:03:04:05, ethertype 802.1Q-9100 (0x9100), length 110: vlan 2, p 1, ethertype 802.1Q-QinQ, vlan 101, p 0, ethertype 802.1Q, vlan 123, p 7, ethertype IPv4, (tos 0x0, ttl 64, id 15994, offset 0, flags [none], proto ICMP (1), length 84) 192.168.140.101 > 192.168.140.1: ICMP echo request, id 40234, seq 0, length 64 The frame ejected on the ordered hook will look like this: 00:00:00:00:01:01 > 00:01:02:03:04:05, ethertype 802.1Q (0x8100), length 110: vlan 123, p 1, ethertype 802.1Q-9100, vlan 2, p 0, ethertype 802.1Q-QinQ, vlan 101, p 7, ethertype IPv4, (tos 0x0, ttl 64, id 15994, offset 0, flags [none], proto ICMP (1), length 84) 192.168.140.101 > 192.168.140.1: ICMP echo request, id 40234, seq 0, length 64 Hence the frame pushed out to the VOIP_IF will have this form: 00:00:00:00:01:01 > 00:01:02:03:04:05, ethertype 802.1Q-9100, vlan 2, p 0, ethertype 802.1Q-QinQ, vlan 101, p 7, ethertype IPv4, (tos 0x0, ttl 64, id 15994, offset 0, flags [none], proto ICMP (1), length 84) 192.16
[Bug 240687] jail cpuset masks cannot be expanded
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240687 Bug ID: 240687 Summary: jail cpuset masks cannot be expanded Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: j...@freebsd.org Suppose one creates a simple jail: jail -c name=foo command=/bin/sh It will inherit the default cpuset from the parent jail. You can use cpuset -j to shrink this set: % cpuset -g -j 1 jail 1 mask: 0, 1, 2, 3, 4, 5, 6, 7 % cpuset -g -j 1 -r jail 1 mask: 0, 1, 2, 3, 4, 5, 6, 7 % cpuset -j 1 -l 0-3 % cpuset -g -j 1 jail 1 mask: 0, 1, 2, 3 However, once you've shrunk the set, you can never expand it. The reason is that the jail set is its own root, so the check against the 'root' mask in cpuset_modify() fails with EINVAL. I think this is perhaps not the intended behavior. I think that when setting the cpuset of a jail you want to apply the check against the parent jail's mask, not the jail's own mask. In particular, this prevents using cpuset -j to dynamically manage the CPUs available to jails. The alternative is to leave the jails unrestricted and manage the processes in the jail (or create dedicated, named cpusets for each jail and manage those) which is not as convenient for tools operating at the abstraction level of a jail. One possibility might be to have cpuset_getroot() always skip over the passed in set to its parent at least once before checking for the ROOT flag (or fix callers to pass set->cs_parent instead of set), but I haven't looked at what other implications that might have. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 240689] usr.sbin/ngctl: Generate more compact GraphWiz output
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240689 Bug ID: 240689 Summary: usr.sbin/ngctl: Generate more compact GraphWiz output Product: Base System Version: 12.0-STABLE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: l...@donnerhacke.de Created attachment 207627 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=207627&action=edit Patch for usr.sbin/ngctl/dot.c The output of "ngctl dot" is suitable for small netgraph networks. Even moderate complex netgraph setups (about a dozen nodes) are hard to understand from the .dot output, because each node and each hook are shown as a full blown structure. This patch allows to generate much more compact output and graphs by omitting the extra structures for the individual hooks. Instead the names of the hooks are labels to the edges. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 240572] libefi: FreeBSD cannot boot with U-Boot patch efi_loader: parameter checks BLOCK_IO_PROTOCOL
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240572
--- Comment #2 from Heinrich Schuchardt ---
Commit 16ef880ce6ee ("loader.efi: efipart needs to use ioalign") was merged
into FreeBSD on Sep 17th, 2019.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: [BUG] FreeBSD cannot boot with U-Boot patch efi_loader: parameter checks BLOCK_IO_PROTOCOL
On 9/13/19 11:48 PM, Heinrich Schuchardt wrote:
Hello Emmanuel,
booting current FreeBSD fails since patch
f59f0825e8b9fdeb8abe43ffd10c5119ca1a032f
efi_loader: parameter checks BLOCK_IO_PROTOCOL
The reason is that the buffer used by FreeBSD to read is not block aligned.
The UEFI spec requires that EFI_BLOCK_IO_PROTOCOL.ReadBlocks() returns
EFI_INVALID_PARAMETER if the buffer is not properly aligned (i.e. is not
a multiple of EFI_BLOCK_IO_MEDIA.IoAlign)
FreeBSD does not guarantee this alignment, e.g. efi_disk_read_blocks()
is called with buffer 995b08d0 which is not aligned to a
multiple of 512.
FreeBSD function efipart_readwrite writes this error message:
efipart_readwrite: rw=1, blk=62333952 size=1 status=2
The problem can be traced back to the FreeBSD line:
stand/efi/libefi/efipart.c(1043) efipart_realstrategy():
blkbuf = malloc(blkio->Media->BlockSize);
U-Boot does not yet implement the EFI_DISK_IO_PROTOCOL which is a
wrapper for the EFI_BLOCK_IO_PROTOCOL allowing unaligned access.
malloc() could be replaced in FreeBSD by AllocatePages() which returns a
4096 byte aligned memory block.
Best regards
Heinrich
Commit 16ef880ce6ee ("loader.efi: efipart needs to use ioalign") was
merged into FreeBSD on Sep 17th, 2019.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 240700] [META] FreeBSD 12.1-RELEASE blockers
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240700 Bug ID: 240700 Summary: [META] FreeBSD 12.1-RELEASE blockers Product: Base System Version: CURRENT Hardware: Any URL: https://www.freebsd.org/releases/12.1R/schedule.html OS: Any Status: New Severity: Affects Only Me Priority: --- Component: misc Assignee: r...@freebsd.org Reporter: ko...@freebsd.org CC: b...@freebsd.org The 12.1-RELEASE process has begun [1]. This is a tracking bug for coodinating resolution of 12.1-RELEASE blockers. Bugzilla issues that are (or should be) potential release blockers, should: - Add their issue ID's to their "Blocks:" field - Set patches (attachments) maintainer-approval flags to request (?) approval from re@f.o re@ can then accept (+), or not-accept (-) approval according to their policies/guidelines, and leave/remove the issue from this bugs "Depends on" field, respectively. [1] https://www.freebsd.org/releases/12.1R/schedule.html -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 240700] [META] FreeBSD 12.1-RELEASE blockers
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240700 Kubilay Kocak changed: What|Removed |Added Status|New |Open -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 240700] [META] FreeBSD 12.1-RELEASE blockers
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240700 Andriy Gapon changed: What|Removed |Added Depends on||240640 Referenced Bugs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240640 [Bug 240640] zfs send -n -P -i is broken after r344601 -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
