[Bug 252594] netmap pkt-gen verbose output out of bounds
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252594 Li-Wen Hsu changed: What|Removed |Added Status|New |Open CC||lw...@freebsd.org, ||vmaffi...@freebsd.org -- 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 136944] [ffs] [lor] bufwait/snaplk (fsync)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=136944 m...@netfence.it changed: What|Removed |Added CC||m...@netfence.it --- Comment #5 from m...@netfence.it --- Just encountered this on a 12.2/amd64 vm while investigating #244048 (not sure wether this might be part of the cause for that). Of course, after so many years, the stack trace is slightly different. Jan 12 14:05:13 mksnap kernel: lock order reversal: Jan 12 14:05:13 mksnap kernel: 1st 0xfe827230 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:283 Jan 12 14:05:13 mksnap kernel: 2nd 0xf800049661b0 snaplk (snaplk) @ /usr/src/sys/ufs/ffs/ffs_snapshot.c:2314 Jan 12 14:05:13 mksnap kernel: stack backtrace: Jan 12 14:05:13 mksnap kernel: #0 0x80604bb3 at witness_debugger+0x73 Jan 12 14:05:13 mksnap kernel: #1 0x806048fe at witness_checkorder+0xa9e Jan 12 14:05:13 mksnap kernel: #2 0x8056c0ed at lockmgr_xlock_hard+0x6d Jan 12 14:05:13 mksnap kernel: #3 0x8056d0d0 at __lockmgr_args+0x7a0 Jan 12 14:05:13 mksnap kernel: #4 0x807a0df6 at ffs_copyonwrite+0x176 Jan 12 14:05:13 mksnap kernel: #5 0x807c223c at ffs_geom_strategy+0x8c Jan 12 14:05:13 mksnap kernel: #6 0x807d39c3 at ufs_strategy+0x83 Jan 12 14:05:13 mksnap kernel: #7 0x808b9911 at VOP_STRATEGY_APV+0xf1 Jan 12 14:05:13 mksnap kernel: #8 0x80647114 at bufstrategy+0x44 Jan 12 14:05:13 mksnap kernel: #9 0x80646fb0 at bufwrite+0x230 Jan 12 14:05:13 mksnap kernel: #10 0x807c406e at ffs_syncvnode+0x2be Jan 12 14:05:13 mksnap kernel: #11 0x8079bd04 at ffs_snapshot+0x914 Jan 12 14:05:13 mksnap kernel: #12 0x807bfe5a at ffs_mount+0xb3a Jan 12 14:05:13 mksnap kernel: #13 0x80661a54 at vfs_domount+0x8d4 Jan 12 14:05:13 mksnap kernel: #14 0x80660b27 at vfs_donmount+0x7e7 Jan 12 14:05:13 mksnap kernel: #15 0x80660312 at sys_nmount+0xf2 Jan 12 14:05:13 mksnap kernel: #16 0x808418b7 at amd64_syscall+0x2e7 Jan 12 14:05:13 mksnap kernel: #17 0x808193de at fast_syscall_common+0xf8 -- 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 252585] dump partition in /etc/fstab being used as swap
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252585 Ed Maste changed: What|Removed |Added CC||ema...@freebsd.org --- Comment #1 from Ed Maste --- >From rc.conf(5): dumpdev (str) Indicates the device (usually a swap partition) to which a crash dump should be written in the event of a system crash. If the value of this variable is "AUTO", the first suitable swap device listed in /etc/fstab will be used as dump device. Otherwise, the value of this variable is passed as the argument to dumpon(8). To disable crash dumps, set this variable to "NO". Can you confirm that setting dumpdev=/dev/ada0p4 addresses the issue? What we probably need to do is change the logic to: If the value of this variable is "AUTO", the first dump device listed in /etc/fstab will be used, or the first suitable swap device if no dump device is found. -- 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 252614] /usr/bin/diff : BUG: Incorrectly displaying files as duplicates (includes fix)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252614
Bug ID: 252614
Summary: /usr/bin/diff : BUG: Incorrectly displaying files as
duplicates (includes fix)
Product: Base System
Version: CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: bin
Assignee: b...@freebsd.org
Reporter: ja...@catflap.org
Created attachment 221499
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=221499&action=edit
patch to fix diff bug
When diff hits certain access errors, function diffreg() shows the error
message, and then returns to the calling function, which calls print_status()
with the return value.
However, in these cases, the return value isn't changed from the initial
default value of D_SAME.
Normally, print_status() with a value of D_SAME does nothing, so this works out
ok, however, if the "-s" flag is set, a message is displayed showing
identicality:
case D_SAME:
if (sflag)
printf("Files %s%s and %s%s are identical\n",
path1, entry, path2, entry);
break;
This then produces such results as:
% diff -s /COPYRIGHT /var/run/rpcbind.sock
diff: /var/run/rpcbind.sock: Operation not supported
Files /COPYRIGHT and /var/run/rpcbind.sock are identical
% diff -s /COPYRIGHT /etc/master.passwd
diff: /etc/master.passwd: Permission denied
Files /COPYRIGHT and /etc/master.passwd are identical
A quick fix would be to alter the above line:
if (sflag)
to
if (sflag && status & 2)
A less hacky fix is attached as a patch. It creates a D_ERROR status which is
returned in such cases, and print_status() then deals with that status
seperately from D_SAME.
--
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 252575] panic: camq_remove: Attempt to remove out-of-bounds index -2 from queue
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252575 --- Comment #2 from Peter Eriksson --- With FreeBSD 12.2-STABLE I get a gazillion "ciss0: WARNING: completing non-busy request" but no panic (yet). I managed to get some SCSI errors too which probably is related: (da11:ciss0:32:27:0): READ(16). CDB: 88 00 00 00 00 03 10 a6 1a 70 00 00 01 00 00 00 (da11:ciss0:32:27:0): CAM status: SCSI Status Error (da11:ciss0:32:27:0): SCSI status: Check Condition (da11:ciss0:32:27:0): SCSI sense: ABORTED COMMAND asc:44,0 (Internal target failure) (da11:ciss0:32:27:0): Info: 0x310a61b48 (da11:ciss0:32:27:0): Field Replaceable Unit: 67 (da11:ciss0:32:27:0): Descriptor 0x80: f7 43 (da11:ciss0:32:27:0): Descriptor 0x81: 03 cd 21 01 00 d0 (da11:ciss0:32:27:0): Error 5, Unretryable error (da11:ciss0:32:27:0): READ(16). CDB: 88 00 00 00 00 03 11 d2 4d 60 00 00 00 e8 00 00 (da11:ciss0:32:27:0): CAM status: SCSI Status Error (da11:ciss0:32:27:0): SCSI status: Check Condition (da11:ciss0:32:27:0): SCSI sense: ABORTED COMMAND asc:44,0 (Internal target failure) (da11:ciss0:32:27:0): Info: 0x311d24dc0 (da11:ciss0:32:27:0): Field Replaceable Unit: 67 (da11:ciss0:32:27:0): Descriptor 0x80: f7 43 (da11:ciss0:32:27:0): Descriptor 0x81: 03 cf 0f 01 00 21 (da11:ciss0:32:27:0): Error 5, Unretryable error (da11:ciss0:32:27:0): READ(16). CDB: 88 00 00 00 00 03 11 df 48 78 00 00 01 00 00 00 (da11:ciss0:32:27:0): CAM status: SCSI Status Error (da11:ciss0:32:27:0): SCSI status: Check Condition (da11:ciss0:32:27:0): SCSI sense: ABORTED COMMAND asc:11,3 (Multiple read errors) (da11:ciss0:32:27:0): Info: 0x311df4898 (da11:ciss0:32:27:0): Field Replaceable Unit: 66 (da11:ciss0:32:27:0): Descriptor 0x80: f7 42 (da11:ciss0:32:27:0): Descriptor 0x81: 03 ce 0c 01 00 60 (da11:ciss0:32:27:0): Error 5, Unretryable error (da11:ciss0:32:27:0): READ(16). CDB: 88 00 00 00 00 03 11 e4 6e f8 00 00 01 00 00 00 (da11:ciss0:32:27:0): CAM status: SCSI Status Error (da11:ciss0:32:27:0): SCSI status: Check Condition (da11:ciss0:32:27:0): SCSI sense: ABORTED COMMAND asc:11,3 (Multiple read errors) (da11:ciss0:32:27:0): Info: 0x311e46f20 (da11:ciss0:32:27:0): Field Replaceable Unit: 66 (da11:ciss0:32:27:0): Descriptor 0x80: f7 42 (da11:ciss0:32:27:0): Descriptor 0x81: 03 cd a6 01 00 15 (da11:ciss0:32:27:0): Error 5, Unretryable error (da11:ciss0:32:27:0): READ(16). CDB: 88 00 00 00 00 03 13 07 b2 28 00 00 01 00 00 00 (da11:ciss0:32:27:0): CAM status: SCSI Status Error (da11:ciss0:32:27:0): SCSI status: Check Condition (da11:ciss0:32:27:0): SCSI sense: ABORTED COMMAND asc:11,3 (Multiple read errors) (da11:ciss0:32:27:0): Info: 0x31307b2d8 (da11:ciss0:32:27:0): Field Replaceable Unit: 66 (da11:ciss0:32:27:0): Descriptor 0x80: f7 42 (da11:ciss0:32:27:0): Descriptor 0x81: 03 d0 09 01 01 26 (da11:ciss0:32:27:0): Error 5, Unretryable error (da11:ciss0:32:27:0): READ(16). CDB: 88 00 00 00 00 03 13 09 ec 68 00 00 01 00 00 00 (da11:ciss0:32:27:0): CAM status: SCSI Status Error (da11:ciss0:32:27:0): SCSI status: Check Condition (da11:ciss0:32:27:0): SCSI sense: ABORTED COMMAND asc:11,3 (Multiple read errors) (da11:ciss0:32:27:0): Info: 0x31309ec98 (da11:ciss0:32:27:0): Field Replaceable Unit: 66 (da11:ciss0:32:27:0): Descriptor 0x80: f7 42 (da11:ciss0:32:27:0): Descriptor 0x81: 03 cf dd 01 01 5d (da11:ciss0:32:27:0): Error 5, Unretryable error (da11:ciss0:32:27:0): READ(16). CDB: 88 00 00 00 00 03 13 0e dc 80 00 00 01 00 00 00 (da11:ciss0:32:27:0): CAM status: SCSI Status Error (da11:ciss0:32:27:0): SCSI status: Check Condition (da11:ciss0:32:27:0): SCSI sense: ABORTED COMMAND asc:11,3 (Multiple read errors) (da11:ciss0:32:27:0): Info: 0x3130edcd0 (da11:ciss0:32:27:0): Field Replaceable Unit: 66 (da11:ciss0:32:27:0): Descriptor 0x80: f7 42 (da11:ciss0:32:27:0): Descriptor 0x81: 03 cf 7b 01 00 72 (da11:ciss0:32:27:0): Error 5, Unretryable error I've now zpool offline'd that disk from the zpool in question so hopefully this night things will behave better. Still think that panic shouldn't have happened. And perhaps one should have some kind of throttle on the kernel printed WARNINGS - then machine because more or less unusable while it was printing them (was watching them via ipmi/serial). -- 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 252614] /usr/bin/diff : BUG: Incorrectly displaying files as duplicates (includes fix)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252614 Li-Wen Hsu changed: What|Removed |Added CC||lw...@freebsd.org Status|New |Open -- 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 243401] [patch] ahci driver problems with Marvell 88SE9230 (Dell BOSS-S1)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243401 --- Comment #9 from Peter Eriksson --- Sorry, have been busy with another problem (a HP server with a lot of disks panic:ing due to bugs in other parts of the kernel - sigh). I'll get back with a better patch soon. Anyway, the way I changed it was basically to chnage the loop: 1. DELAY(10) instead of DELAY(100) - it takes about 30us for status to change from 0 -> 1, so no need to wait the full 100us :-) 2. Only change the "full timeout" from 100ms to 500ms after ATA_SS_DEV_MASK has changed from ATA_SS_DET_NO_DEVICE. My current version of the patch contains a lot of debuging printouts so probably not really good for production use (it makes it easier to watch what's happening though :-) A sample of the dmesg output: First an ununes ahci channel/controller without devices: ahcich13: AHCI engine: stopping ahcich13: stopping AHCI engine: cr: 1 -> 0 at time 10 us ahcich13: AHCI engine stopped at time 10 us ahcich13: ahci_sata_phy_reset: Start ahcich13: ahci_sata_connect: Start ahcich13: SATA connect timeout status 0x at time=1us ahcich13: ahci_sata_connect: Done (0) ahcich13: ahci_sata_phy_reset: Done (0) ahcich13: AHCI reset: device not found ahcich13: ahci_reset: Done (ahci_sata_phy_reset failed) First port on the BOSS: ahcich14: ahciaction: Calling ahci_reset (XPT_RESET_BUS) ahcich14: ahci_reset: Start ahcich14: AHCI reset... ahcich14: AHCI engine: stopping ahcich14: stopping AHCI engine: cr: 1 -> 0 at time 10 us ahcich14: AHCI engine stopped at time 10 us ahcich14: ahci_sata_phy_reset: Start ahcich14: ahci_sata_connect: Start ahcich14: SATA changed status 0x -> 0x0001 at time=30us ahcich14: SATA changed status 0x0001 -> 0x0133 at time=211790us ahcich14: SATA connect status 0x0133 at time=211790us ahcich14: ahci_sata_connect: Done (1) ahcich14: ahci_sata_phy_reset: Done (1) ahcich14: AHCI reset: device found ahcich14: AHCI reset: device ready after 0ms ahcich14: AHCI engine(fbs=1): starting ahcich14: ahci_start: Done ahcich14: ahci_reset: Done Then it resets the second port/channel (and starts doing stuff on the first port at the same time): ahcich15: ahciaction: Calling ahci_reset (XPT_RESET_BUS) ahcich15: ahci_reset: Start ahcich15: AHCI reset... ahcich15: AHCI engine: stopping ahcich15: stopping AHCI engine: cr: 1 -> 0 at time 10 us ahcich15: AHCI engine stopped at time 10 us ahcich15: ahci_sata_phy_reset: Start ahcich14: ahci_execute_transaction: Kicking controller into sane state ahcich14: AHCI engine: stopping ahcich14: stopping AHCI engine: cr: 1 -> 0 at time 10 us ahcich14: AHCI engine stopped at time 10 us ahcich14: ahci_clo: Start ahcich14: ahci_clo: Done ahcich14: AHCI engine(fbs=0): starting ahcich14: ahci_start: Done ahcich15: ahci_sata_connect: Start ahcich15: SATA changed status 0x -> 0x0001 at time=30us ahcich14: ahci_end_transaction: Reinit port (eslots=0004) ahcich14: AHCI engine: stopping ahcich15: SATA changed status 0x0001 -> 0x0133 at time=220650us ahcich15: SATA connect status 0x0133 at time=220650us ahcich15: ahci_sata_connect: Done (1) ahcich15: ahci_sata_phy_reset: Done (1) ahcich15: AHCI reset: device found ahcich15: AHCI reset: device ready after 0ms ahcich15: AHCI engine(fbs=1): starting ahcich15: ahci_start: Done ahcich15: ahci_reset: Done And then the third (ses?) port - there is only two ports on this controller: ahcich16: ahciaction: Calling ahci_reset (XPT_RESET_BUS) ahcich16: ahci_reset: Start ahcich16: AHCI reset... ahcich16: AHCI engine: stopping ahcich16: stopping AHCI engine: cr: 1 -> 0 at time 10 us ahcich16: AHCI engine stopped at time 10 us ahcich16: ahci_sata_phy_reset: Start ahcich16: ahci_sata_connect: Start ahcich16: SATA changed status 0x -> 0x0113 at time=70us ahcich16: SATA connect status 0x0113 at time=70us ahcich16: ahci_sata_connect: Done (1) ahcich16: ahci_sata_phy_reset: Done (1) ahcich16: AHCI reset: device found ahcich16: AHCI reset: device ready after 0ms ahcich16: AHCI engine(fbs=1): starting ahcich16: ahci_start: Done ahcich16: ahci_reset: Done But then things are a bit strange - notice the 1s timeouts (I increased the max timeout to 1s in this test boot): Root mount waiting for: CAM usbus0 uhub0: 26 ports with 26 removable, self powered ahcich14: stopping AHCI engine: timeout at 100 us (cr=1, ccs=0, ci=0, sact=0) ahcich14: ahci_clo: Start ahcich14: ahci_clo: Done ahcich14: AHCI engine(fbs=1): starting ahcich14: ahci_start: Done ahcich15: ahci_execute_transaction: Kicking controller into sane state ahcich15: AHCI engine: stopping ugen0.2: at usbus0 umass0 numa-domain 0 on uhub0 umass0: on usbus0 umass0: SCSI over Bulk-Only; quirks = 0xc000 umass0:20:0: Attached to scbus20 Root mount waiting for: CAM usbus0 ahcich15: stopping AHCI engine: timeout at 100 us (cr=1, ccs=0, ci=0, sact=0) ahcich15: ahci_clo: Start ahcich15: ahci_clo: Done ahcich15: AHCI engine(fbs=0): starting ahcich15: a
[Bug 243401] [patch] ahci driver problems with Marvell 88SE9230 (Dell BOSS-S1)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243401 --- Comment #10 from Peter Eriksson --- Created attachment 221500 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=221500&action=edit dmesg.boot -- 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 243401] [patch] ahci driver problems with Marvell 88SE9230 (Dell BOSS-S1)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243401 Peter Eriksson changed: What|Removed |Added Attachment #220793|0 |1 is obsolete|| --- Comment #11 from Peter Eriksson --- Created attachment 221502 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=221502&action=edit Version 2 of patch (with debugging printfs) A new version of the patch (still with a lot of debugging printf's - I'll see if I can find time to create a more "clean" version with just the DELAY(10) and "long timeout, but only after state 0 -> 1" fixes. -- 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 252585] dump partition in /etc/fstab being used as swap
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252585 --- Comment #2 from g...@arcor.de --- Im not sure what you mean by "adresses this issue", I did have dumpdev="/dev/ada0p4" in my rc.conf when the dump partition was added as swap during boot. IMO, however, something categorized as dump via fstab should never be added as swap. If you want me to try different settings, I'd prefer to not reboot for a few weeks. (The reason I ran into this was a crash that claimed to be writing a dump on the /dev/mirror/swap, savecore did not find one at boot, though. So I tried to be sure it works next time.) -- 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 252596] ping to 255.255.255.255 does not set broadcast MAC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252596 --- Comment #1 from jcap...@blackberry.com --- Created attachment 221503 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=221503&action=edit proposed patch -- 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 252532] ifconfig incorrectly displays stp roles
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252532 --- Comment #1 from jcap...@blackberry.com --- Created attachment 221504 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=221504&action=edit proposed patch -- 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 252585] dump partition in /etc/fstab being used as swap
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252585 --- Comment #3 from Ed Maste --- Oh, sorry I read your report the wrong way around - I thought you meant the swap device was still being used as dumpdev. I agree that a dump device should not be used for swap. With fstab as in the original report and no explicit dumpdev setting I would currently expect /dev/mirror/swap to (attempt to) be used as the dump device, but this is something that should be fixed. -- 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 252617] pfctl -a '*' -sn does not recursively print nat-anchors
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252617
Bug ID: 252617
Summary: pfctl -a '*' -sn does not recursively print
nat-anchors
Product: Base System
Version: 12.2-RELEASE
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: bin
Assignee: b...@freebsd.org
Reporter: gu...@kollerie.com
According to "man pfctl" one should use "-a '*'" to recursively print the
main ruleset. That does work for filter anchors (eg 'anchor') but not for
NAT anchors (eg 'nat-anchor').
Given the loaded ruleset:
ext_if="lagg0"
set skip on lo0
scrub in
nat-anchor vm
block in
pass out
pass in on $ext_if proto tcp from any to ($ext_if) port { ssh, domain,
http, https }
pass in on $ext_if proto udp to ($ext_if) port domain
pass in on $ext_if inet proto icmp to ($ext_if) icmp-type { unreach, redir,
timex, echoreq }
anchor vm
Running:
pfctl -a vm -f - < (lagg0)
pass in on vm-public
EOT
should load the new NAT and filter rules into the appropriate anchor
positions. When we run:
pfctl -a '*' -sr
The filter ruleset is properly recursively printed:
scrub in all fragment reassemble
block drop in all
pass in on lagg0 proto tcp from any to (lagg0) port = ssh flags S/SA keep
state
pass in on lagg0 proto tcp from any to (lagg0) port = domain flags S/SA
keep state
pass in on lagg0 proto tcp from any to (lagg0) port = http flags S/SA keep
state
pass in on lagg0 proto tcp from any to (lagg0) port = https flags S/SA keep
state
pass in on lagg0 proto udp from any to (lagg0) port = domain keep state
pass in on lagg0 inet proto icmp from any to (lagg0) icmp-type unreach keep
state
pass in on lagg0 inet proto icmp from any to (lagg0) icmp-type redir keep
state
pass in on lagg0 inet proto icmp from any to (lagg0) icmp-type timex keep
state
pass in on lagg0 inet proto icmp from any to (lagg0) icmp-type echoreq keep
state
pass out all flags S/SA keep state
anchor "vm" all {
pass in on vm-public all flags S/SA keep state
}
But the NAT ruleset however is not:
pfctl -a '*' -sn
prints:
nat-anchor "vm" all
Only when we explicitly name the anchor, will the NAT ruleset be printed:
pfctl -a vm -sn
prints:
nat on lagg0 inet from 10.0.128.0/24 to any -> (lagg0) round-robin
I would have expected both "-a '*'" and "-a vm" to produce the same
output.
--
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 252594] netmap pkt-gen verbose output out of bounds
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252594 Vincenzo Maffione changed: What|Removed |Added Assignee|b...@freebsd.org|vmaffi...@freebsd.org -- 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 252624] Sockets stay in CLOSING, FIN_WAIT_X and LAST_ACK indefinitely
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252624 Bug ID: 252624 Summary: Sockets stay in CLOSING, FIN_WAIT_X and LAST_ACK indefinitely Product: Base System Version: Unspecified Hardware: amd64 OS: Any Status: New Severity: Affects Many People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: joha...@freebsd.org We're running head as of March 2017 on a large number of servers. Through recent expansions we have noticed a new problem where a large amount of connections are stuck in CLOSING, FIN_WAIT_1, FIN_WAIT_2 and LAST_ACK indefinitely, until the servers runs out of memory. We don't know what is causing this but it appears that clients are not terminating the TCP connections properly. In any case, these connections should have a timeout and be cleaned up by the kernel within reasonable time. #25986 also mentions this issue and have a suggested patch that deals with all states but CLOSING. https://www.freebsd.org/security/advisories/FreeBSD-SA-15:13.tcp.asc claims to have solved it but it has not. In our case we don't believe it is deliberate but if someone wanted, they could easily take down servers with simple attacks like this so it is a security concern. -- 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 252626] ixl: panic on attach of X722 on-motherboard interfaces
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252626 Bug ID: 252626 Summary: ixl: panic on attach of X722 on-motherboard interfaces Product: Base System Version: 12.2-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: woll...@freebsd.org I upgraded our fleet of ~20 NFS servers today from 12.1 to 12.2-RELEASE-p2. Three of the newest servers, which have X722 interfaces on the motherboard, crash at attach time with the following trace: --- trap 0xc, rip = 0x80757efd, rsp = 0xfe0075dff2d0, rbp = 0xfe0075dff2e0 --- grouptaskqueue_enqueue() at grouptaskqueue_enqueue+0xd/frame 0xfe0075dff2e0 ixl_admin_timer() at ixl_admin_timer+0x11/frame 0xfe0075dff300 softclock_call_cc() at softclock_call_cc+0x141/frame 0xfe0075dff3b0 softclock() at softclock+0x79/frame 0xfe0075dff3d0 ithread_loop() at ithread_loop+0x23c/frame 0xfe0075dff430 fork_exit() at fork_exit+0x7e/frame 0xfe0075dff470 fork_trampoline() at f (There's an omitted frame where ixl_admin_timer() calls iflib_admin_intr_deferred() -- apparently pf->vsi.ctx is not initialized yet, or there's a missing memory barrier?) The problem is not observed on older servers with X710 interfaces. (We don't use the 1G interfaces for anything, and if we didn't have servers that need it, I would just yank ixl(4) from our standard kernel configuration. I might still do that and just load the module on the three servers that need it.) The systems that panic have: ixl0@pci0:26:0:0: class=0x02 card=0x37d115d9 chip=0x37d18086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = 'Ethernet Connection X722 for 1GbE' class = network subclass = ethernet The systems that boot (and operate properly) have: ixl0@pci0:3:0:0:class=0x02 card=0x00088086 chip=0x15728086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'Ethernet Controller X710 for 10GbE SFP+' class = network subclass = ethernet -- 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 232397] ctld does not depend on sysctl.conf being evaluated
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232397 --- Comment #2 from Jeremy Faulkner --- NETWORKING requires netif which requires sysctl -- 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 232397] ctld does not depend on sysctl.conf being evaluated
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232397 --- Comment #3 from Mahmoud Al-Qudsi --- Yup. This should do the trick. -- 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"
Nouvelles nuisettes Marjolaine 👉 Luxe made in France pour toutes les silhouettes
[ Livraison et retour gratuits ]( https://www.glamuse.com/?ref=21371r1 ) [ Version en ligne ]( https://www.glamuse.com/news/20210111-NmYxN-p/?ref=21371r1&pays=73 ) [ ]( https://www.glamuse.com/?ref=21371r1 ) [ Lingerie ]( https://www.glamuse.com/lingerie.html?ref=21371r1 ) [ Homewear ]( https://www.glamuse.com/lingerie-de-nuit-homewear.html?ref=21371r1 ) [ Grandes Tailles ]( https://www.glamuse.com/lingerie-grande-taille.html?ref=21371r1 ) [ SEXY ]( https://www.glamuse.com/lingerie-sexy.html?ref=21371r1 ) [ ]( https://www.glamuse.com/marjolaine.html?ref=21371r1 ) -- Nuisettes raffinées : nouveautés Soie unie -- Luxe et douceur pour toutes les silhouettes [ ]( https://www.glamuse.com/marjolaine.html?csort[]=p-345781&csort[]=copro-2038_98&csort[]=copro-2038_101&csort[]=co-2038&csort[]=discount-asc&ref=21371r1 ) [ ]( https://www.glamuse.com/marjolaine.html?csort[]=p-381211&csort[]=copro-2038_101&csort[]=copro-2038_98&csort[]=co-2038&csort[]=discount-asc&ref=21371r1 ) [ ]( https://www.glamuse.com/marjolaine.html?csort[]=p-372227&csort[]=copro-2038_480&csort[]=copro-2038_98&csort[]=co-2038&csort[]=discount-asc&ref=21371r1 ) [ ]( https://www.glamuse.com/marjolaine.html?csort[]=p-364236&csort[]=copro-2038_897&csort[]=copro-2038_98&csort[]=co-2038&csort[]=discount-asc&ref=21371r1 )[ Toute la collection Soie unie ► ]( https://www.glamuse.com/marjolaine.html?csort[]=p-345781&csort[]=copro-2038_98&csort[]=copro-2038_101&csort[]=co-2038&csort[]=discount-asc&ref=21371r1 )-- Marjolaine, exquises nouveautés Made in France -- Dentelle de Calais et précieux savoir-faire [ ]( https://www.glamuse.com/marjolaine.html?sort=nouvd&csort[]=copro-4239_789&csort[]=p-363282&csort[]=co-4239&csort[]=co-2038&csort[]=discount-asc&ref=21371r1 ) [ ]( https://www.glamuse.com/marjolaine.html?sort=nouvd&csort[]=p-363283&csort[]=copro-4239_789&csort[]=co-4239&csort[]=co-2038&csort[]=discount-asc&ref=21371r1 ) [ ]( https://www.glamuse.com/marjolaine.html?sort=nouvd&csort[]=p-364397&csort[]=p-364418&csort[]=copro-4239_97&csort[]=copro-4239_830&csort[]=copro-4239_431&csort[]=copro-4239_808&csort[]=copro-2437_63&csort[]=copro-3927_381&csort[]=copro-3927_98&ref=21371r1 ) [ ]( https://www.glamuse.com/marjolaine.html?sort=nouvd&csort[]=copro-4239_789&csort[]=co-4239&csort[]=co-2038&csort[]=discount-asc&ref=21371r1 )[ Toutes les nouveautés Marjolaine ► ]( https://www.glamuse.com/marjolaine.html?sort=nouvd&csort[]=copro-4239_789&ref=21371r1 )-- ... et vos privilèges sur le meilleur de la lingerie -- [ ]( https://www.glamuse.com/marjolaine.html?csort[]=vp-desc&csort[]=p-334750&csort[]=p-334731&csort[]=p-335139&csort[]=p-335667&csort[]=p-334632&ref=21371r1 ) [ ]( https://www.glamuse.com/marjolaine.html?csort[]=vp-desc&csort[]=p-334573&csort[]=p-334563&csort[]=p-334750&csort[]=p-334731&csort[]=p-335139&csort[]=p-335667&csort[]=p-334632&ref=21371r1 ) [ ]( https://www.glamuse.com/marjolaine.html?csort[]=vp-desc&csort[]=p-335174&csort[]=p-335168&csort[]=p-334750&csort[]=p-334731&csort[]=p-335139&csort[]=p-335667&csort[]=p-334632&ref=21371r1 ) [ Marjolaine Lia ► ]( https://www.glamuse.com/marjolaine.html?csort[]=vp-desc&csort[]=p-334750&csort[]=p-334731&csort[]=p-335139&csort[]=p-335667&csort[]=p-334632&ref=21371r1 ) [ Marjolaine Gemma ► ]( https://www.glamuse.com/marjolaine.html?csort[]=vp-desc&csort[]=p-334573&csort[]=p-334563&csort[]=p-334750&csort[]=p-334731&csort[]=p-335139&csort[]=p-335667&csort[]=p-334632&ref=21371r1 ) [ Marjolaine Leo ► ]( https://www.glamuse.com/marjolaine.html?csort[]=vp-desc&csort[]=p-335174&csort[]=p-335168&csort[]=p-334750&csort[]=p-334731&csort[]=p-335139&csort[]=p-335667&csort[]=p-334632&ref=21371r1 ) [ ]( https://www.glamuse.com/lingerie-primadonna-mid-102-c-3.html?csort[]=vp-desc&csort[]=copro-2401_98&ref=21371r1 ) [ ]( https://www.glamuse.com/la-perla.html?toggle-display=products&csort[]=vp-desc&csort[]=copro-3788_414&ref=21371r1 ) [ ]( https://www.glamuse.com/aubade.html?toggle-display=products&csort[]=vp-desc&csort[]=copro-3768_341&ref=21371r1 ) [ PrimaDonna Forever ► ]( https://www.glamuse.com/lingerie-primadonna-mid-102-c-3.html?csort[]=vp-desc&csort[]=copro-2401_98&ref=21371r1 ) [ La Perla Dreamcatcher ► ]( https://www.glamuse.com/la-perla.html?toggle-display=products&csort[]=vp-desc&csort[]=copro-3788_414&ref=21371r1 ) [ Aubade Encre de Chine ► ]( https://www.glamuse.com/aubade.html?toggle-display=products&csort[]=vp-desc&csort[]=copro-3768_341&ref=21371r1 ) [ Toutes les offres privées ► ]( https://www.glamuse.com/vente-privee-lingerie.html?ref=21371r1 ) + 10€ OFFERTS sur tout le site avec le code BIENVENUE10 dès 69€ d'achats sur votre première commande [ J'EN PROFITE ► ]( https://www.glamuse.com/?ref=21371r1 )-- Glamuse avec vous ♥ -- . Expédition le jour même (pour toute commande passée avant 16:30, heure de Paris) . Livraison
Приглашение на конференцию
___ 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"
