[Bug 260859] freebsd-update feedback/messages should be more broadly understandable, when patch levels differ for kernel and userland

[bugzilla-noreply]

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

Bug ID: 260859
   Summary: freebsd-update feedback/messages should be more
broadly understandable, when patch levels differ for
kernel and userland
   Product: Base System
   Version: Unspecified
  Hardware: Any
   URL: https://cgit.freebsd.org/src/tree/usr.sbin/freebsd-upd
ate/freebsd-update.sh?id=48ffe56ac5b7adb5b851d32be12b2
ec0f13705a4#n1448
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: bin
  Assignee: b...@freebsd.org
  Reporter: grahamper...@gmail.com

Messages such as this are sometimes a source of confusion: 

> No updates needed to update system to 12.2-RELEASE-p11.
> WARNING: FreeBSD 12.2-RELEASE-p7 is approaching its End-of-Life date.
> It is strongly recommended that you upgrade to a newer
> release within the next 1 month.

-- , 
   in context :

>> I've noticed that when I run a freebsd-version -ku command it 
>> says that my kernel and userland have different patch level version, 
>> kernel is p7, userland is p11.
>> 
>> Tried to run freebsd-update fetch but it says: "No updates needed 
>> to update system to 12.2-RELEASE-p11".
>> 
>> Is that normal?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 258918] "freebsd-update fetch install" skips the install phase without a clear warning

[bugzilla-noreply]

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

--- Comment #2 from Graham Perrin  ---
(In reply to Ed Maste from comment #1)

> … I think the install should proceed despite the warning. …

+1

* in a context of e.g.fetch install 

* but not in a context of -r newrelease

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 214254] Freebsd-update does not request a reboot in all cases where it is needed

[bugzilla-noreply]

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

Graham Perrin  changed:

   What|Removed |Added

 CC||grahamper...@gmail.com

--- Comment #1 from Graham Perrin  ---
(In reply to bc979 from comment #0)

> … were running 11.0-p1 (RELEASE) …

> freebsd-version -ku
> 11.0-RELEASE-p2
> 11.0-RELEASE-p3

Non-official  shows: 

* reboot required for one of the three patches to reach p2

* no such _requirement_ for the one patch between p2 and p3. 

For the latter, more specifically: 

> … The sshd(8) service has to be restarted after the update.  
> A reboot is recommended but not required. …

– 

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 260867] [pf][patch] divert-to packets infinitely loop when written back to divert socket

[bugzilla-noreply]

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

Bug ID: 260867
   Summary: [pf][patch] divert-to packets infinitely loop when
written back to divert socket
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: damjan@gmail.com
 Attachment #230608 text/plain
 mime type:

Created attachment 230608
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=230608&action=edit
Divert socket test code

On https://forums.freebsd.org/threads/pf-divert-to-loop-problem.81508 the
poster describes how the "divert-to" rule creates packet loops on FreeBSD 12.2,
and I also independently reproduced this bug on 13.0 and 14-CURRENT too.

It can be reproduced with this pf rule:

pass out on em0 divert-to 0.0.0.0 port 2000

while running the attached C code, which binds a divert socket to 0.0.0.0:2000
and reads packets and writes them back unchanged.

Adding some logging to the pf kernel module, I noticed that the
PF_PACKET_LOOPED flag never gets set in the pf_test() function. Checking for
conditions that set it which aren't being met, I think I found out why.

The following one line change fixes the issue for me:

---snip---
diff --git a/sys/netpfil/pf/pf.c b/sys/netpfil/pf/pf.c
index 1686def4626..bd71d338517 100644
--- a/sys/netpfil/pf/pf.c
+++ b/sys/netpfil/pf/pf.c
@@ -6496,7 +6496,7 @@ pf_test(int dir, int pflags, struct ifnet *ifp, struct
mbuf **m0, struct inpcb *
if (__predict_false(ip_divert_ptr != NULL) &&
((ipfwtag = m_tag_locate(m, MTAG_IPFW_RULE, 0, NULL)) != NULL)) {
struct ipfw_rule_ref *rr = (struct ipfw_rule_ref *)(ipfwtag+1);
-   if (rr->info & IPFW_IS_DIVERT && rr->rulenum == 0) {
+   if (rr->info & IPFW_IS_DIVERT /*&& rr->rulenum == 0*/) {
if (pd.pf_mtag == NULL &&
((pd.pf_mtag = pf_get_mtag(m)) == NULL)) {
action = PF_DROP;
---snip---


Why does that work?

It appears that the "rulenum" field is only written to in this one place:
((struct ipfw_rule_ref *)(ipfwtag+1))->rulenum = dir;

and if "dir" is what I think it is, then as per /usr/include/netpfil/pf/pf.h:

enum{ PF_INOUT, PF_IN, PF_OUT };

the 0 in "rr->rulenum == 0" would be PF_INOUT, which packets never are. However
checking for values 1 and 2 instead, didn't seem to fix the issue either. Only
deleting the entire rr->rulenum check seems to fix it.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 260257] CAM_IO_STATS does not track MEDIUM ERRORs

[bugzilla-noreply]

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

--- Comment #6 from Alan Somers  ---
I saw this again.  A drive returned a lot of "Head select fault"s, but the
errors counter is still 0, even though errors got reported to ZFS.

(da292:mpr2:0:214:0): READ(6). CDB: 08 00 00 00 08 00 
(da292:mpr2:0:214:0): CAM status: SCSI Status Error
(da292:mpr2:0:214:0): SCSI status: Check Condition
(da292:mpr2:0:214:0): SCSI sense: ABORTED COMMAND asc:9,4 (Head select fault)
(da292:mpr2:0:214:0): Descriptor 0x80: 00 00 00 00 00 00 00 00 00 00 00 00 00
00
(da292:mpr2:0:214:0): Retrying command (per sense data)

$ sysctl kern.cam.da.292.stats
kern.cam.da.292.stats.pack_invalidations: 0
kern.cam.da.292.stats.timeouts: 10461
kern.cam.da.292.stats.errors: 0

$ zpool status | grep mp_JB1_S15
  multipath/mp_JB1_S15.eli  FAULTED  7.90K 11.0K35  too many
errors

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 260868] possible i386 regression after ce35a3bc852d25cb989bc1f3dc4ddb723d7d5117

[bugzilla-noreply]

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

Bug ID: 260868
   Summary: possible i386 regression after
ce35a3bc852d25cb989bc1f3dc4ddb723d7d5117
   Product: Base System
   Version: 13.0-STABLE
  Hardware: Any
OS: Any
Status: New
  Keywords: regression
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: m...@sentex.net

Created attachment 230609
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=230609&action=edit
sysctl -A | grep -i timer and dmesg for working and non working images

For some deployments, we are still using some legacy PC Engine's Alix devices.
These are GEODE processors, running i386 FreeBSD 13.  I noticed on a latest
build as of Jan 1, boot times because impossibly slow (approx 10x times the
normal amount to boot) and I cant seem to run the watchdog with an interval
below 10 seconds as it does not get processed fast enough. 

If I rewind to a commit just prior to 
https://cgit.freebsd.org/src/commit/?h=stable/13&id=1e40acb545391169b8e13fd27724e3699d6824c3
all works as normal


Also seemingly related is that I had been using a kernel definition that did
not include SMP nor APIC.  If I checkout to 
1a305490732cdd30d19627b49847ebe09009a8f7 

I can no longer compile said kernel as it fails with 

--- vers.c ---
MAKE="make" sh /usr/src/sys/conf/newvers.sh  ALIX_DSK
--- vers.o ---
cc -target i386-unknown-freebsd13.0
--sysroot=/usr/obj/nanobsd.alix2b/usr/src/i386.i386/tmp
-B/usr/obj/nanobsd.alix2b/usr/src/i386.i386/tmp/usr/bin -c -O2 -pipe 
-fno-strict-aliasing   -nostdinc  -I. -I/usr/src/sys
-I/usr/src/sys/contrib/ck/include -I/usr/src/sys/contrib/libfdt -D_KERNEL
-DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common
-fdebug-prefix-map=./machine=/usr/src/sys/i386/include
-fdebug-prefix-map=./x86=/usr/src/sys/x86/include -mno-mmx -mno-sse
-msoft-float -ffreestanding -fwrapv -fstack-protector -Wall -Wredundant-decls
-Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__
-Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas
-Wno-error=tautological-compare -Wno-error=empty-body
-Wno-error=parentheses-equality -Wno-error=unused-function
-Wno-error=pointer-sign -Wno-error=shift-negative-value
-Wno-address-of-packed-member -Wno-error=unused-but-set-variable
-Wno-format-zero-length   -mno-aes -mno-avx  -std=iso9899:1999 -Werror  vers.c
ctfconvert -L VERSION vers.o
ERROR: ctfconvert: vers.o doesn't have type data to convert
--- kernel ---
linking kernel
ld: error: undefined symbol: apic_ops
>>> referenced by clock.c
>>>   clock.o:(cpu_initclocks)
*** [kernel] Error code 1

make[2]: stopped in /usr/obj/nanobsd.alix2b/usr/src/i386.i386/sys/alix
1 error

make[2]: stopped in /usr/obj/nanobsd.alix2b/usr/src/i386.i386/sys/alix

make[1]: stopped in /usr/src

make: stopped in /usr/src


Adding in 
device  apic
to the kernel config allows me to compile, but the resultant kernel is dead
slow / unusable. 

Attached is a working and non working dmesg and output of sysctl -A | grep time
(in case that helps)

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 260868] possible i386 regression after ce35a3bc852d25cb989bc1f3dc4ddb723d7d5117

[bugzilla-noreply]

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

Mark Johnston  changed:

   What|Removed |Added

 CC||ma...@freebsd.org
 Status|New |Open

--- Comment #1 from Mark Johnston  ---
I think I see the problem.  We're calibrating using the i8254 timer, and the
corresponding timecounter has a pretty narrow mask so wraparound can occur
multiple times.  I wonder if we should just skip late calibration if the i8254
is the only reference clock.

Could you please show a verbose dmesg from the broken kernel?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 260868] possible i386 regression after ce35a3bc852d25cb989bc1f3dc4ddb723d7d5117

[bugzilla-noreply]

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

m...@sentex.net changed:

   What|Removed |Added

 CC||m...@sentex.net

--- Comment #2 from m...@sentex.net ---
Created attachment 230612
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=230612&action=edit
boot -v and pciconf

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 260764] nfs: Add control over bg timeout

[bugzilla-noreply]

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

Rick Macklem  changed:

   What|Removed |Added

   Assignee|b...@freebsd.org|rmack...@freebsd.org

--- Comment #3 from Rick Macklem  ---
Created attachment 230613
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=230613&action=edit
Add a "bgnow" option that backgounds the NFS mount immediately

This patch adds a "bgnow" option to mount_nfs, so that
it goes into background immediately instead of waiting
for the first mount attempt to fail.

I have not yet done a patch for the man page, but all
you need to do to test this is replace "bg" with "bgnow".

Could the reporter please test this to see if it fixes
the problem fo them?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 214254] Freebsd-update does not request a reboot in all cases where it is needed

[bugzilla-noreply]

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

--- Comment #2 from bc...@lafn.org ---
The reboot recommendation/requirement issue continues on to the latest
versions.  The current approach appears to be that a reboot is recommended
somewhere in the documentations and then leave it up to the administrator to
determine if there is anything running that needs to be restarted.

It would seem to me that it would be better to require the reboot and then show
the kinds of processes that would not get updated if a reboot was not
performed.

The best approach would be for the system to examine itself and determine which
running processes require a reboot and make the recommendation based on that. 
I suspect that would be much more difficult to implement though.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 260871] [patch] /usr/bin/touch enhancement

[bugzilla-noreply]

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

Bug ID: 260871
   Summary: [patch] /usr/bin/touch enhancement
   Product: Base System
   Version: Unspecified
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: bin
  Assignee: b...@freebsd.org
  Reporter: ja...@catflap.org

Created attachment 230614
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=230614&action=edit
patch to add "-R" to touch(1)

I'm not quite sure how you deal with "non-standard" additions to standard
commands, so please be gentle!

Incidentally, I have no preference for actual implementation, this is just what
I've been using for a while. Comments welcome!

Basically, touch(1) has:

-h  If the file is a symbolic link, change the times of the link itself
rather than the file that the link points to.

and:

 -r  Use the access and modifications times from the specified file instead
of the current time of day.

If "-r" points to a link, the link is always followed to retrieve the datetime
information.

I have a program that needs to "-r" the datetime of the link itself if the file
is a link.

Up to now, I've been doing a stat of the file, and then forming the date to
add, but recently thought to add this option:

-R  As -r , but if the file is a symbolic link, return the times of the
link itself rather than the file that the link points to.

Patch attached. Comments?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 260871] [patch] touch(1) enhancement

[bugzilla-noreply]

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

Jamie Landeg-Jones  changed:

   What|Removed |Added

Summary|[patch] /usr/bin/touch  |[patch] touch(1)
   |enhancement |enhancement
 CC||ja...@catflap.org

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 260868] possible i386 regression after ce35a3bc852d25cb989bc1f3dc4ddb723d7d5117

[bugzilla-noreply]

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

--- Comment #3 from m...@sentex.net ---
Even though the box is up 2hrs, the uptime shows 2 min


Type '?' for a list of commands, 'help' for more detailed help.
OK boot -v
---<>---
Copyright (c) 1992-2021 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 13.0-STABLE #0 stable/13-1a3054907: Sat Jan  1 15:35:26 EST 2022
   
mdtan...@nano13-i386.sentex.ca:/usr/obj/nanobsd.alix2b/usr/src/i386.i386/sys/alix
i386
FreeBSD clang version 13.0.0 (g...@github.com:llvm/llvm-project.git
llvmorg-13.0.0-0-gd7b669b3a303)
VT(vga): resolution 640x480
Preloaded elf kernel "/boot/kernel/kernel" at 0x12a3000.
Preloaded elf module "/boot/kernel/u3g.ko" at 0x12ab8ac.
Preloaded boot_entropy_cache "/boot/entropy" at 0x12abcf4.
Early TSC frequency 498072600Hz calibrated from 8254 PIT
CPU: Geode(TM) Integrated Processor by AMD PCS (498.07-MHz 586-class CPU)
  Origin="AuthenticAMD"  Id=0x5a2  Family=0x5  Model=0xa  Stepping=2
  Features=0x88a93d
  AMD Features=0xc040
L1 2MB data TLB: 0 entries, 0-way associative
L1 2MB instruction TLB: 0 entries, 0-way associative
L1 4KB data TLB: 16 entries, fully associative
L1 4KB instruction TLB: 16 entries, fully associative
L1 data cache: 64 kbytes, 32 bytes/line, 1 lines/tag, 16-way associative
L1 instruction cache: 64 kbytes, 32 bytes/line, 1 lines/tag, 16-way associative
L2 2MB unified TLB: 4 entries, disabled/not present
L2 4KB unified TLB: 0 entries, disabled/not present
L2 unified cache: 128 kbytes, 32 bytes/line, 1 lines/tag, 4-way associative
Write Allocate Disable
real memory  = 268435456 (256 MB)
Physical memory chunk(s):
0x1000 - 0x0009, 651264 bytes (159 pages)
0x0010 - 0x007f, 7340032 bytes (1792 pages)
0x01429000 - 0x0fbb4fff, 242794496 bytes (59276 pages)
avail memory = 249569280 (238 MB)
bios32: Found BIOS32 Service Directory header at 0x4fd110
bios32: Entry = 0xfd0e4 (4fd0e4)  Rev = 0  Len = 1
pcibios: PCI BIOS entry at 0xf+0xcf35
pnpbios: Bad PnP BIOS data checksum
Other BIOS signatures found:
random: read 4096 bytes from preloaded cache
random: unblocking device.
hostuuid: using ----
ULE: setup cpu 0
random: entropy device external interface
null: 
io: 
crypto: 
kbd0 at kbdmux0
mem: 
K6-family MTRR support enabled (2 registers)
vtvga0: 
crypto: assign cryptosoft0 driver id 0, flags 0x600
pci_open(1):mode 1 addr port (0x0cf8) is 0x
pci_open(1a):   mode1res=0x8000 (0x8000)
pci_cfgcheck:   device 0 1 [class=06] [hdr=80] is there (id=20801022)
pcibios: BIOS version 2.10
pcib0 pcibus 0
pci0:  on pcib0
pci0: domain=0, physical bus=0
found-> vendor=0x1022, dev=0x2080, revid=0x33
domain=0, bus=0, slot=1, func=0
class=06-00-00, hdrtype=0x00, mfdev=1
cmdreg=0x0005, statreg=0x0220, cachelnsz=8 (dwords)
lattimer=0xf8 (7440 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
map[10]: type I/O Port, range 32, base 0xac1c, size  2, enabled
found-> vendor=0x1022, dev=0x2082, revid=0x00
domain=0, bus=0, slot=1, func=2
class=10-10-00, hdrtype=0x00, mfdev=0
cmdreg=0x0006, statreg=0x02a0, cachelnsz=8 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=a, irq=9
map[10]: type Memory, range 32, base 0xefff4000, size 14, enabled
found-> vendor=0x1106, dev=0x3053, revid=0x96
domain=0, bus=0, slot=9, func=0
class=02-00-00, hdrtype=0x00, mfdev=0
cmdreg=0x0097, statreg=0x0210, cachelnsz=8 (dwords)
lattimer=0x20 (960 ns), mingnt=0x03 (750 ns), maxlat=0x08 (2000 ns)
intpin=a, irq=10
powerspec 2  supports D0 D1 D2 D3  current D0
map[10]: type I/O Port, range 32, base 0x1000, size  8, enabled
map[14]: type Memory, range 32, base 0xe000, size  8, enabled
found-> vendor=0x1106, dev=0x3053, revid=0x96
domain=0, bus=0, slot=10, func=0
class=02-00-00, hdrtype=0x00, mfdev=0
cmdreg=0x0097, statreg=0x0210, cachelnsz=8 (dwords)
lattimer=0x20 (960 ns), mingnt=0x03 (750 ns), maxlat=0x08 (2000 ns)
intpin=a, irq=11
powerspec 2  supports D0 D1 D2 D3  current D0
map[10]: type I/O Port, range 32, base 0x1400, size  8, enabled
map[14]: type Memory, range 32, base 0xe004, size  8, enabled
found-> vendor=0x1106, dev=0x3053, revid=0x96
domain=0, bus=0, slot=11, func=0
class=02-00-00, hdrtype=0x00, mfdev=0
cmdreg=0x0097, statreg=0x0210, cachelnsz=8 (dwords)
lattimer=0x20 (960 ns), mingnt=0x03 (750 ns), maxlat=0x08 (2000 ns)
intpin=a, irq=15
powerspec 2  supports D0 D1 D2 D3  current D0
map[10]: type I/O Port, range 32, base 0x1800, size  8, enabled
map[14]: t