Re: UEFI using loader.env currdev limited to only disks 3-5 on 6 disk server using 13.1 with UFS file systems

[Abner Gershon]

I would like to retract this email. Problem was that the root partition I
was trying to point to was full and I did not realize it. Once I made room
on the new target root file system UEFI boot was successful and currdev was
set from loader.env.

On Sun, Oct 23, 2022 at 9:31 PM Abner Gershon <6731...@gmail.com> wrote:

> UFS file systems only ( ZFS kernel module not loaded ) (and msdos fat-32
> for ESP partitions )
>
> OS: 13.1-RELEASE
>
> Hardware: Dell r710, H200 HBA in IT mode (  SAS2008 PCI-Express Fusion-MPT
> SAS-2  )
>
>
>
> I have created ESP partitions with /EFI/freeBSD/loader.efi and
> /EFI/FreeBSD/loader.env on each of my 6 HDDs.
>
>
>
> I also have a root partition copied from full install on disk /dev/da0 to
> the other disks with minor adjustments to /etc/fstab to set
>
> Root directory to self, eg for /dev/da3 fstab entry is “/dev/da3pn   /
> rw   1  1”.
>
>
>
> I used efibootmgr to create EFI entries to boot each disk.
>
>
>
> Currdev=disk3pn:, currdev=disk4pn:, and currdev=5pn: ( n=root partition)
> works for /dev/da0,/dev/da2, and /dev/da1 respectively.
>
> I have experimented with currdev=disk0,disk1,disk2,disk6,and disk7 in
> trying to use esp partitions on dev/da3-5 but none of these values are
> acted upon. Rather currdev defaults to disk2p1 for each of these other
> values.
>
>
>
> root@server:/usr/home/me # pciconf -lv
>
> hostb0@pci0:0:0:0:  class=0x06 rev=0x13 hdr=0x00 vendor=0x8086
> device=0x3406 subvendor=0x1028 subdevice=0x0235
>
> vendor = 'Intel Corporation'
>
> device = '5520 I/O Hub to ESI Port'
>
> class  = bridge
>
> subclass   = HOST-PCI
>
> pcib1@pci0:0:1:0:   class=0x060400 rev=0x13 hdr=0x01 vendor=0x8086
> device=0x3408 subvendor=0x1028 subdevice=0x0235
>
> vendor = 'Intel Corporation'
>
> device = '5520/5500/X58 I/O Hub PCI Express Root Port 1'
>
> class  = bridge
>
> subclass   = PCI-PCI
>
> pcib2@pci0:0:3:0:   class=0x060400 rev=0x13 hdr=0x01 vendor=0x8086
> device=0x340a subvendor=0x1028 subdevice=0x0235
>
> vendor = 'Intel Corporation'
>
> device = '5520/5500/X58 I/O Hub PCI Express Root Port 3'
>
> class  = bridge
>
> subclass   = PCI-PCI
>
> pcib3@pci0:0:4:0:   class=0x060400 rev=0x13 hdr=0x01 vendor=0x8086
> device=0x340b subvendor=0x1028 subdevice=0x0235
>
> vendor = 'Intel Corporation'
>
> device = '5520/X58 I/O Hub PCI Express Root Port 4'
>
> class  = bridge
>
> subclass   = PCI-PCI
>
> pcib4@pci0:0:5:0:   class=0x060400 rev=0x13 hdr=0x01 vendor=0x8086
> device=0x340c subvendor=0x1028 subdevice=0x0235
>
> vendor = 'Intel Corporation'
>
> device = '5520/X58 I/O Hub PCI Express Root Port 5'
>
> class  = bridge
>
> subclass   = PCI-PCI
>
> pcib5@pci0:0:6:0:   class=0x060400 rev=0x13 hdr=0x01 vendor=0x8086
> device=0x340d subvendor=0x1028 subdevice=0x0235
>
> vendor = 'Intel Corporation'
>
> device = '5520/X58 I/O Hub PCI Express Root Port 6'
>
> class  = bridge
>
> subclass   = PCI-PCI
>
> pcib6@pci0:0:7:0:   class=0x060400 rev=0x13 hdr=0x01 vendor=0x8086
> device=0x340e subvendor=0x1028 subdevice=0x0235
>
> vendor = 'Intel Corporation'
>
> device = '5520/5500/X58 I/O Hub PCI Express Root Port 7'
>
> class  = bridge
>
> subclass   = PCI-PCI
>
> pcib7@pci0:0:9:0:   class=0x060400 rev=0x13 hdr=0x01 vendor=0x8086
> device=0x3410 subvendor=0x1028 subdevice=0x0235
>
> vendor = 'Intel Corporation'
>
> device = '7500/5520/5500/X58 I/O Hub PCI Express Root Port 9'
>
> class  = bridge
>
> subclass   = PCI-PCI
>
> none0@pci0:0:20:0:  class=0x08 rev=0x13 hdr=0x00 vendor=0x8086
> device=0x342e subvendor=0x subdevice=0x
>
> vendor = 'Intel Corporation'
>
> device = '7500/5520/5500/X58 I/O Hub System Management Registers'
>
> class  = base peripheral
>
> subclass   = interrupt controller
>
> none1@pci0:0:20:1:  class=0x08 rev=0x13 hdr=0x00 vendor=0x8086
> device=0x3422 subvendor=0x subdevice=0x
>
> vendor = 'Intel Corporation'
>
> device = '7500/5520/5500/X58 I/O Hub GPIO and Scratch Pad
> Registers'
>
> class  = base peripheral
>
> subclass   = interrupt controller
>
> none2@pci0:0:20:2:  class=0x08 rev=0x13 hdr=0x00 vendor=0x8086
> device=0x3423 subvendor=0x subdevice=0x
>
> vendor = 'Intel Corporation'
>
> device = '7500/5520/5500/X58 I/O Hub Control Status and RAS
> Registers'
>
> class  = base peripheral
>
> subclass   = interrupt controller
>
> uhci0@pci0:0:26:0:  class=0x0c0300 rev=0x02 hdr=0x00 vendor=0x8086
> device=0x2937 subvendor=0x1028 subdevice=0x0235
>
> vendor = 'Intel Corporation'
>
> device = '82801I (ICH9 Family) USB UHCI Controller'
>
> class  = serial bus
>
> subclass   = USB
>
> uhci1@pci0:0:26:1:  class=0x0c0300 rev=0x02 

UEFI using loader.env currdev limited to only disks 3-5 on 6 disk server using 13.1 with UFS file systems

[Abner Gershon]

UFS file systems only ( ZFS kernel module not loaded ) (and msdos fat-32 for ESP partitions )OS: 13.1-RELEASEHardware: Dell r710, H200 HBA in IT mode (  SAS2008 PCI-Express Fusion-MPT SAS-2  ) I have created ESP partitions with /EFI/freeBSD/loader.efi and /EFI/FreeBSD/loader.env on each of my 6 HDDs. I also have a root partition copied from full install on disk /dev/da0 to the other disks with minor adjustments to /etc/fstab to setRoot directory to self, eg for /dev/da3 fstab entry is “/dev/da3pn   /   rw   1  1”. I used efibootmgr to create EFI entries to boot each disk. Currdev=disk3pn:, currdev=disk4pn:, and currdev=5pn: ( n=root partition) works for /dev/da0,/dev/da2, and /dev/da1 respectively.I have experimented with currdev=disk0,disk1,disk2,disk6,and disk7 in trying to use esp partitions on dev/da3-5 but none of these values are acted upon. Rather currdev defaults to disk2p1 for each of these other values. root@server:/usr/home/me # pciconf -lvhostb0@pci0:0:0:0:  class=0x06 rev=0x13 hdr=0x00 vendor=0x8086 device=0x3406 subvendor=0x1028 subdevice=0x0235    vendor = 'Intel Corporation'    device = '5520 I/O Hub to ESI Port'    class  = bridge    subclass   = HOST-PCIpcib1@pci0:0:1:0:   class=0x060400 rev=0x13 hdr=0x01 vendor=0x8086 device=0x3408 subvendor=0x1028 subdevice=0x0235    vendor = 'Intel Corporation'    device = '5520/5500/X58 I/O Hub PCI Express Root Port 1'    class  = bridge    subclass   = PCI-PCIpcib2@pci0:0:3:0:   class=0x060400 rev=0x13 hdr=0x01 vendor=0x8086 device=0x340a subvendor=0x1028 subdevice=0x0235    vendor = 'Intel Corporation'    device = '5520/5500/X58 I/O Hub PCI Express Root Port 3'    class  = bridge    subclass   = PCI-PCIpcib3@pci0:0:4:0:   class=0x060400 rev=0x13 hdr=0x01 vendor=0x8086 device=0x340b subvendor=0x1028 subdevice=0x0235    vendor = 'Intel Corporation'    device = '5520/X58 I/O Hub PCI Express Root Port 4'    class  = bridge    subclass   = PCI-PCIpcib4@pci0:0:5:0:   class=0x060400 rev=0x13 hdr=0x01 vendor=0x8086 device=0x340c subvendor=0x1028 subdevice=0x0235    vendor = 'Intel Corporation'    device = '5520/X58 I/O Hub PCI Express Root Port 5'    class  = bridge    subclass   = PCI-PCIpcib5@pci0:0:6:0:   class=0x060400 rev=0x13 hdr=0x01 vendor=0x8086 device=0x340d subvendor=0x1028 subdevice=0x0235    vendor = 'Intel Corporation'    device = '5520/X58 I/O Hub PCI Express Root Port 6'    class  = bridge    subclass   = PCI-PCIpcib6@pci0:0:7:0:   class=0x060400 rev=0x13 hdr=0x01 vendor=0x8086 device=0x340e subvendor=0x1028 subdevice=0x0235    vendor = 'Intel Corporation'    device = '5520/5500/X58 I/O Hub PCI Express Root Port 7'    class  = bridge    subclass   = PCI-PCIpcib7@pci0:0:9:0:   class=0x060400 rev=0x13 hdr=0x01 vendor=0x8086 device=0x3410 subvendor=0x1028 subdevice=0x0235    vendor     = 'Intel Corporation'    device = '7500/5520/5500/X58 I/O Hub PCI Express Root Port 9'    class  = bridge    subclass   = PCI-PCInone0@pci0:0:20:0:  class=0x08 rev=0x13 hdr=0x00 vendor=0x8086 device=0x342e subvendor=0x subdevice=0x    vendor = 'Intel Corporation'    device = '7500/5520/5500/X58 I/O Hub System Management Registers'    class  = base peripheral    subclass   = interrupt controllernone1@pci0:0:20:1:  class=0x08 rev=0x13 hdr=0x00 vendor=0x8086 device=0x3422 subvendor=0x subdevice=0x    vendor = 'Intel Corporation'    device = '7500/5520/5500/X58 I/O Hub GPIO and Scratch Pad Registers'    class  = base peripheral    subclass   = interrupt controllernone2@pci0:0:20:2:      class=0x08 rev=0x13 hdr=0x00 vendor=0x8086 device=0x3423 subvendor=0x subdevice=0x    vendor = 'Intel Corporation'    device = '7500/5520/5500/X58 I/O Hub Control Status and RAS Registers'    class  = base peripheral    subclass   = interrupt controlleruhci0@pci0:0:26:0:  class=0x0c0300 rev=0x02 hdr=0x00 vendor=0x8086 device=0x2937 subvendor=0x1028 subdevice=0x0235    vendor = 'Intel Corporation'    device = '82801I (ICH9 Family) USB UHCI Controller'    class  = serial bus    subclass   = USBuhci1@pci0:0:26:1:  class=0x0c0300 rev=0x02 hdr=0x00 vendor=0x8086 device=0x2938 subvendor=0x1028 subdevice=0x0235    vendor = 'Intel Corporation'    device = '82801I (ICH9 Family) USB UHCI Controller'    class  = serial bus    subclass   = USBehci0@pci0:0:26:7:  class=0x0c0320 rev=0x02 hdr=0x00 vendor=0x8086 device=0x293c subvendor=0x1028 subdevice=0x0235    vendor = 'Intel Corporation'    device = '82801I (ICH9 Family) USB2 EHCI Controller'    class  = serial bus    subclass   = USBuhci2@pci0:0:29:0:  class=0x0c0300 rev=0x02 hdr=0x00 vendor=0x8086 device=0x2934 subvendor=0x1028 subdevice=0x0235    vendor = 'Intel Corporation'    device = '82801I (ICH9 Family) USB UHCI Controller'    class      = serial bus    subclass   = 

[Bug 267301] nfs uses udp for portmapper even when proto=tcp specified

[bugzilla-noreply]

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

Bug ID: 267301
   Summary: nfs uses udp for portmapper even when proto=tcp
specified
   Product: Base System
   Version: 13.1-STABLE
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: b...@facefault.org

When attempting to mount a remote file share using NFSv3, portmapper calls use
UDP even when TCP is explicitly specified. Using the port= option would be a
satisfactory workaround but that doesn't eliminate portmapper calls.

Expected behavior: TCP explicitly specified means TCP everywhere.

Repro:

1. Start tcpdump with capture filter "port 111".
2. Attempt to mount an NFS share with proto=tcp.
3. The tcpdump contains UDP traffic to the remote portmapper when TCP is
expected.
4. Block outgoing UDP/111 from the client. (I guess this one's not strictly
necessary.)
5. Repeat #2 but add port=2049 to the mount options.
6. The tcpdump contains a successful NULL call but the client immediately tried
contacting the portmapper on UDP to get the mount port.

This prevents using Azure Blob Storage NFS, and I suspect there are some bad
and hard-to-get-fixed firewall configurations out there since Linux's behavior
is to use TCP for portmapper in this case.

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

Problem reports for b...@freebsd.org that need special attention

[bugzilla-noreply]

To view an individual PR, use:
  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id).

The following is a listing of current problems submitted by FreeBSD users,
which need special attention. These represent problem reports covering
all versions including experimental development code and obsolete releases.

Status  |Bug Id | Description
+---+---
New |197876 | [devfs] an error in devfs leads to data loss and  
New |198797 | [PATCH] Added an option to install BSDstats to bs 
New |202362 | ntp: restore refclocks selection (10.2-RELEASE re 
New |202740 | vi/ex string substitution problem when there is m 
New |204097 | witness_initialize() does not perform bound check 
New |206336 | [patch] usr.sbin/freebsd-update allow proxy confi 
New |209213 | UEFI Loader shows only black screen with Nvidia G 
New |210804 | installerconfig - using ZFS create in custom scri 
New |223470 | freebsd-update: Cannot identify running kernel (/ 
New |230620 | "install -d" issue
New |252123 | fetch(3): Fix wrong usage of proxy when request i 
Open|177821 | sysctl: Some security.jail nodes are funky, dupli 
Open|183618 | [panic] Dell PowerEdge R620 -- PERC H710 Mini (mf 
Open|192573 | Add ps(1) option: Print process start time in sec 
Open|194925 | [pf] [ifconfig] interface group keywords do not w 
Open|197921 | scheduler: Allow non-migratable threads to bind t 
Open|206528 | Emulex LPe 16002 FC HBA Not Recognized by oce(4)  
Open|206649 | cyapa(4): Add common gestures for Cypress APA I2C 
Open|207940 | stand/efi/boot1: Add boot partition selection 
Open|212608 | sockstat(1) and lsof(8) can not identity the owne 
Open|220246 | syslogd does not send RFC3164-conformant messages 
Open|221305 | Mouse cursor loss when moving cursor while loadin 
Open|221550 | kern.bootfile returns only /kernel on mips64 (ERL 
Open|221854 | makefs: Reject UFS labels that are too long to fi 
Open|226893 | freebsd-update: Support patchlevel argument for f 
Open|231810 | [build] release always fails with "mkimg: partiti 
Open|233578 | Unprivileged local user can prevent other users l 
Open|233988 | freebsd-update: Improve progress output on termin 
Open|236718 | system panics with message: vm_fault_hold: fault  
Open|237287 | moused(8) ignores button release events in virtua 
Open|237924 | Possible infinite loop in function empty_aux_buff 
Open|238183 | cam/scsi/scsi_sa.c: warnings issued by static ana 
Open|238486 | Possible buffer overflow bug in sc_allocate_keybo 
Open|238550 | Touchpad (via SMBus) not working: Synaptics (SYN1 
Open|238638 | mfi: Remove unnecessary pointer printing in mfi.c 
Open|238837 | init: Remove P_SYSTEM flag from PID 1 to allow ea 
Open|241697 | i915kms: Kernel panic loading module on custom ke 
Open|247132 | Fix build error: use of undeclared identifier 'cp 
Open|248352 | mfi(4): Remove RAID map sync functionality
Open|257149 | CFLAGS not passed to whole build  
New |260138 | TPM2 Support in bootloader / kernel in order to r 
New |261306 | Geli rc.d script does not support insertion of US 
New |262957 | mpr(4), mps(4): change formally to formerly   
Open|179832 | manual page of mac_from_text suggests incorrect f 

44 problems total for which you should take action.

Re: [Bug 206165] resolv.conf(5) is missing documentation on options

[Andy Farkas]

--- Comment #9 from Graham Perrin (non-committing)  ---
Re: comment #7


aim for the #bugs channel.

Correcting myself:

the #freebsd-bugs channel.

Apologies for the noise.



The #bugs channel on irc.oz.org is fairly quiet


-andyf

[Bug 267294] inquiry_result() in ng_hci_event.c ought to check before calling m_copydata()

[bugzilla-noreply]

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

Bug ID: 267294
   Summary: inquiry_result() in ng_hci_event.c ought to check
before calling m_copydata()
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: r...@lcs.mit.edu
 Attachment #237561 text/plain
 mime type:

Created attachment 237561
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=237561=edit
trigger an m_copydata() panic in ng_hci_event.c

If a netgraph data message arriving on a bluetooth hci drv hook is short,
inquiry_result() can trigger a panic in m_copydata():

inquiry_result(ng_hci_unit_p unit, struct mbuf *event)
{
ng_hci_inquiry_result_ep*ep = NULL;
...;
ep = mtod(event, ng_hci_inquiry_result_ep *);
...;
for (; ep->num_responses > 0; ep->num_responses --) {
m_copydata(event, 0, sizeof(bdaddr), (caddr_t) );

And (as noted in a comment in the code) later in this function there
are some more uses of the mbuf that are invalid if the message is too
short.

I've attached a demo:

# cc ng13a.c -lnetgraph
# ./a.out
panic: m_copydata, length > size of mbuf chain
cpuid = 2
time = 1666543254
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0049bb6910
vpanic() at vpanic+0x151/frame 0xfe0049bb6960
panic() at panic+0x43/frame 0xfe0049bb69c0
m_copydata() at m_copydata+0x1ca/frame 0xfe0049bb6a40
ng_hci_process_event() at ng_hci_process_event+0x923/frame 0xfe0049bb6a90
ng_apply_item() at ng_apply_item+0x166/frame 0xfe0049bb6b20
ng_snd_item() at ng_snd_item+0x2e1/frame 0xfe0049bb6b60
ngd_send() at ngd_send+0x10b/frame 0xfe0049bb6be0
sosend_generic() at sosend_generic+0x61a/frame 0xfe0049bb6ca0
sosend() at sosend+0x49/frame 0xfe0049bb6cd0
kern_sendit() at kern_sendit+0x1b3/frame 0xfe0049bb6d60
sendit() at sendit+0xba/frame 0xfe0049bb6db0
sys_sendto() at sys_sendto+0x4d/frame 0xfe0049bb6e00
amd64_syscall() at amd64_syscall+0x12e/frame 0xfe0049bb6f30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe0049bb6f30
--- syscall (133, FreeBSD ELF64, sys_sendto), rip = 0x8229075ca, rsp =
0x820a21068, rbp = 0x820a210d0 ---

FreeBSD stock14 14.0-CURRENT FreeBSD 14.0-CURRENT #3 main-n258027-c9baa974717a:
Thu Sep 15 20:02:51 AST 2022
root@stock14:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64

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

[Bug 267293] Support Qualcomm Snapdragon 888 SoC and Qualcomm SDX55 5G modem.

[bugzilla-noreply]

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

Marek Zarychta  changed:

   What|Removed |Added

 CC||zarych...@plan-b.pwste.edu.
   ||pl

--- Comment #1 from Marek Zarychta  ---
If still unsupported, please submit a patch to make it work under FreeBSD.

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

[Bug 267293] Support Qualcomm Snapdragon 888 SoC and Qualcomm SDX55 5G modem.

[bugzilla-noreply]

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

Bug ID: 267293
   Summary: Support Qualcomm Snapdragon 888 SoC and Qualcomm SDX55
5G modem.
   Product: Base System
   Version: Unspecified
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: zoujiaq...@gmail.com

Snapdragon 888 SoC support for that new Qualcomm addition that was announced
last year. The Qualcomm SDX55 5G modem is also supported by the mainline Linux
5.12 kernel.

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

[Bug 206165] resolv.conf(5) is missing documentation on options

[bugzilla-noreply]

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

--- Comment #9 from Graham Perrin (non-committing)  ---
Re: comment #7

> aim for the #bugs channel. 

Correcting myself: 

   the #freebsd-bugs channel. 

Apologies for the noise.

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

[Bug 206165] resolv.conf(5) is missing documentation on options

[bugzilla-noreply]

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

--- Comment #8 from Graham Perrin (non-committing)  ---
> … add the URL of the review to the See also: field. …

For clarity, I mean: 

 * your   D37096
 * not my D37086

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

[Bug 206165] resolv.conf(5) is missing documentation on options

[bugzilla-noreply]

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

Graham Perrin (non-committing)  changed:

   What|Removed |Added

 CC||grahamper...@gmail.com

--- Comment #7 from Graham Perrin (non-committing)  ---
Re: , the 'patch' keyword (above)
can/should be removed. 

Bug 227147 will gain a hint of: 

* how to seek bug reports where an attachment is definitely a patch. 

bcr@ would you like to make yourself the assignee? Also, add the URL of the
review to the See also: field. 

Thanks.


(In reply to O. Hartmann from comment #5)

This Bugzilla includes more than a thousand non-resolved reports that use the
(deprecated) patch keyword. For each such report that is relatively old, there
might be any number of reasons for lack of progress. 

I think, it'll be useful to discuss generally – without singling out this bug
206165 – can I suggest the freebsd-questions mailing list? Or IRC, if you
prefer: aim for the #bugs channel. 

Thanks.

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

[Bug 206165] resolv.conf(5) is missing documentation on options

[bugzilla-noreply]

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

Benedict Reuschling  changed:

   What|Removed |Added

 CC||b...@freebsd.org
 Status|Open|In Progress

--- Comment #6 from Benedict Reuschling  ---
I just opened a review for it here:
https://reviews.freebsd.org/D37096

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

[Bug 206165] resolv.conf(5) is missing documentation on options

[bugzilla-noreply]

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

O. Hartmann  changed:

   What|Removed |Added

 CC||ohartm...@walstatt.org

--- Comment #5 from O. Hartmann  ---
Is anyone taking care of this issue? I stumbled over it today and find it very
disturbing, that a simple documentary issue takes over six years to be fixed
...

MfG
oh

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

[Bug 266901] Backup gpart script runs even it is disabled in periodic.conf inside jails

[bugzilla-noreply]

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

--- Comment #2 from sgubdsbe...@asmco.de ---
(In reply to John Grafton from comment #1)

I removed daily_backup_gpart_enable="NO" but the behavior is still the same.
That /etc/defaults/periodic.conf checks if it is inside a jail would explain
that I didn't have this before. I checked also if something went wrong with the
jail creation but everything seems to be right.

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

[Bug 267225] Panic in pcpu

[bugzilla-noreply]

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

--- Comment #3 from Meng Zhuo  ---
(In reply to Mitchell Horne from comment #2)

It happened on runtime.
I can only find "Fatal" in daemon.log

```
savecore[722]: reboot after panic: Fatal page fault at 0xffc0005df184:
0xffcf8318
```

Nothing in the dmesg.log or debug.log

more kgdb info
```
   
Unread portion of the kernel message buffer:   
   
t[0] ==
0xffc0009d2818
t[1] == 0xffc0009da940
t[2] == 0xffc214f96640
t[3] == 0xffc000347a04
t[4] == 0x0001
t[5] == 0xffd202b7e2e8
t[6] == 0x0036 
   
s[0] == 0xffc214f96aa0 
   
s[1] ==
0xfffe
s[2] == 0x3ccb3001
s[3] == 0x0001
s[4] == 0xffd00ae66c50
s[5] == 0xffd21a247000
s[6] == 0x0ff8
s[7] == 0x
s[8] == 0x00fff000
s[9] == 0x0001
s[10] == 0xffd0732ccff8
s[11] == 0x
a[0] == 0x
a[1] == 0x0084
a[2] == 0x00ff
a[3] == 0x
a[4] == 0x0021
a[5] == 0x0021
a[6] == 0xffc0009daaa0
a[7] == 0x
ra == 0xffc0005df220
sp == 0xffc214f969c0
gp == 0x0001
tp == 0xffd202b7e2e8
sepc == 0xffc0005df25c
sstatus == 0x00020120
panic: Fatal page fault at 0xffc0005df25c: 0x30
cpuid = 1
time = 1666311525
KDB: stack backtrace:
#0 0xffc00039447e at kdb_backtrace+0x56
#1 0xffc00034d208 at vpanic+0x154
#2 0xffc00034d0b0 at panic+0x2a
#3 0xffc0005e3e5a at page_fault_handler+0x1ee
#4 0xffc0005e39b6 at do_trap_supervisor+0x5a
#5 0xffc0005d4fd0 at cpu_exception_handler_supervisor+0x70
#6 0xffc00059ed4e at vmspace_exit+0xdc
#7 0xffc000305b3a at exit1+0x6a6
#8 0xffc000305490 at sys_sys_exit+0x10
#9 0xffc0005e4038 at do_trap_user+0x1da
#10 0xffc0005d50a2 at cpu_exception_handler_user+0x72
Uptime: 41m32s
Dumping 780 out of 16354 MB:..1%..11%..21%
```

```
(kgdb) x/16 0xffc0005df184
0xffc0005df184 : 867715  1183139329 
10918323-408301
0xffc0005df194 : 269350547   -960656151 
-657879886  815236390
0xffc0005df1a4 : -2132279297 360536544  
24446395-2051848607
0xffc0005df1b4 : 906166981   179566596  
-1241317194 -2049833974
```

```
info threads

  Id   Target Id  Frame
  1Thread 10 (PID=0: kernel/swapper)  get_pcpu () at
/usr/src/sys/riscv/include/pcpu.h:63
  2Thread 17 (PID=0: kernel/softirq_0)get_pcpu () at
/usr/src/sys/riscv/include/pcpu.h:63
  3Thread 18 (PID=0: kernel/softirq_1)get_pcpu () at
/usr/src/sys/riscv/include/pcpu.h:63
  4Thread 19 (PID=0: kernel/softirq_2)get_pcpu () at
/usr/src/sys/riscv/include/pcpu.h:63
  5Thread 100010 (PID=0: kernel/softirq_3)get_pcpu () at
/usr/src/sys/riscv/include/pcpu.h:63
  6Thread 100011 (PID=0: kernel/inm_free taskq)   get_pcpu () at
/usr/src/sys/riscv/include/pcpu.h:63
  7Thread 100014 (PID=0: kernel/thread taskq) get_pcpu () at
/usr/src/sys/riscv/include/pcpu.h:63
  8Thread 100016 (PID=0: kernel/in6m_free taskq)  get_pcpu () at
/usr/src/sys/riscv/include/pcpu.h:63
  9Thread 100017 (PID=0: kernel/kqueue_ctx taskq) get_pcpu () at
/usr/src/sys/riscv/include/pcpu.h:63
  10   Thread 100018 (PID=0: kernel/aiod_kick taskq)  get_pcpu () at
/usr/src/sys/riscv/include/pcpu.h:63
  11   Thread 100025 (PID=0: kernel/firmware taskq)   get_pcpu () at
/usr/src/sys/riscv/include/pcpu.h:63
  12   Thread 100029 (PID=0: kernel/crypto_0) get_pcpu () at
/usr/src/sys/riscv/include/pcpu.h:63
  13   Thread 100030 (PID=0: kernel/crypto_1) get_pcpu () at
/usr/src/sys/riscv/include/pcpu.h:63
  14   Thread 100031 (PID=0: kernel/crypto_2) get_pcpu () at
/usr/src/sys/riscv/include/pcpu.h:63
  15   Thread 100032 (PID=0: kernel/crypto_3) get_pcpu () at
/usr/src/sys/riscv/include/pcpu.h:63
  16   Thread 100048 (PID=0: kernel/nvme taskq_0) get_pcpu () at
/usr/src/sys/riscv/include/pcpu.h:63
  17   Thread 100049 (PID=0: kernel/nvme taskq_1) get_pcpu () at
/usr/src/sys/riscv/include/pcpu.h:63
  18   Thread 100050 (PID=0: kernel/system_taskq_0)