[Bug 163048] normal user cant mount ntfs-3g due to bug in mac_stub module

[bugzilla-noreply]

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

Mark Linimon  changed:

   What|Removed |Added

   Assignee|am...@freebsd.org   |b...@freebsd.org
 CC||lini...@freebsd.org
Summary|normal user cant mount  |normal user cant mount
   |ntfs-3g |ntfs-3g due to bug in
   ||mac_stub module
 Status|In Progress |Open

--- Comment #9 from Mark Linimon  ---
^Triage: mark as not amd64-specific (most likely), and unmark In Progress (no
work seems to have been done).

To submitters/commenters: was this problem ever fixed?

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

[Bug 183823] error when system start

[bugzilla-noreply]

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

Mark Linimon  changed:

   What|Removed |Added

 Status|Open|Closed
 Resolution|--- |Feedback Timeout
   Assignee|am...@freebsd.org   |bugmeis...@freebsd.org

--- Comment #3 from Mark Linimon  ---
^Triage: feedback timeout ( > 4 months).

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

[Bug 207940] stand/efi/boot1: Add boot partition selection

[bugzilla-noreply]

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

--- Comment #50 from Tomoaki AOKI  ---
(In reply to Mark Millard from comment #48)

Yes. So I (and maybe the original author, too) am maintaining patch here for
anyone others who needs this functionality with best-effort basis until
loader.efi gets equivalent (or even better) boot partition seceltion
functionality.

There's no assurance fot updating patches here, as it's not in-tree and updates
are provided just a best-effort basis.

For me, maintained src are latest stable branch (currently stable/14) and main
only and no more considerations for older branches possible.

I update my version of the patch (if possible, Naomich's one, too) only when...
  *build of boot1.efi somehow failes, or
  *even worse, `git stash && git pull --ff-only && git stash apply` failed
   on /usr/src/stand/*.

Once loader.efi comes to get functionality to boot FreeBSD on any partition on
any drive and treat the actual boot partition/drive as primary (use loader.conf
etc. there), I'll stop maintaining my patch here. But it doesn't yet happened.

I had no objection for DEPRECATING boot1.efi, and actually deprecated, but
unless loader.efi get the functionality, I strongly object for DELETION of
boot1.efi sources.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 207940] stand/efi/boot1: Add boot partition selection

[bugzilla-noreply]

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

--- Comment #49 from Mark Millard  ---
Sorry: the deprecated status was already covered by comment #42

( And the page I referenced says it is from 13.2, so: 13.2+ .)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 207940] stand/efi/boot1: Add boot partition selection

[bugzilla-noreply]

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

Mark Millard  changed:

   What|Removed |Added

 CC||marklmi26-f...@yahoo.com

--- Comment #48 from Mark Millard  ---
https://man.freebsd.org/cgi/man.cgi?query=boot1.efi=0=8=FreeBSD+14.0-RELEASE=default=html

reports:

QUOTE
boot1.efi  has  been  deprecated and will be removed from a future re-
   lease.  loader.efi(8) handles all its former use cases with more flexi-
   bility.
END QUOTE

Adding new/adjusted functionality for 14.x+ to something
deprecated for 14.x+ seems unlikely.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 207940] stand/efi/boot1: Add boot partition selection

[bugzilla-noreply]

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

--- Comment #47 from Nicolas  ---
I don't understand why the partition menu display using boot1.efifat (so
FreeBSD 12 way) but not using boot1.efi + manual partition setup (so FreeBSD 13
and newer way).

Since FreeBSD 13.0 and newer, boot1.efifat didn't exist anymore, so I use the
following to write EFI partition of my disk:
# newfs_msdos -F 12 -L EFISYS /dev/p1 ;
# mount -t msdosfs /dev/p1 /mnt
# mkdir -p /mnt/efi/boot
# cp /boot/loader.efi /mnt/efi/boot/BOOTx64.efi
# echo "BOOTx64.efi" > /mnt/efi/boot/startup.nsh
# umount /mnt
But the partition menu is not shown.
I use the same newfs_msdos paramaters than
https://cgit.freebsd.org/src/plain/stand/efi/boot1/generate-fat.sh?h=releng/12.3
used to create boot1.efifat.

If I put /boot/boot1.efi from FreeBSD 14.0 into FreeBSD 12.3 system, the
partition menu is shown.

If I create manually a boot1.efifat on FreeBSD 14.0 (using FreeBSD 12 method
from
https://cgit.freebsd.org/src/plain/stand/efi/boot1/generate-fat.sh?h=releng/12.3
& https://cgit.freebsd.org/src/tree/stand/efi/boot1/Makefile?h=releng/12.3),
partition menu works.

mkdir /temp/boot1
cd /temp/boot1
dd if=/dev/zero of=fat-x64.tmpl bs=512 count=1600
mdconfig -a -f fat-x64.tmpl
newfs_msdos -F 12 -L EFISYS md0
mkdir stub
mount -t msdosfs /dev/md0 stub
mkdir -p stub/efi/boot
echo 'Boot1 START' | dd of=stub/efi/boot/BOOTx64.efi cbs=384k count=1
conv=block
echo BOOTx64.efi > stub/efi/boot/startup.nsh
umount stub
mdconfig -d -u md0
rmdir stub
xz -f fat-x64.tmpl
xz -d -c fat-x64.tmpl.xz > boot1.efifat
dd if=/boot/boot1.efi of=boot1.efifat seek=0x2d conv=notrunc
cp boot1.efifat /boot/boot1.efifat
dd if=/boot/boot1.efifat of=/dev/p1 ;

Did you know how get the partition menu working on FreeBSD 14.0 without using
boot1.efifat ?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 207940] stand/efi/boot1: Add boot partition selection

[bugzilla-noreply]

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

Tomoaki AOKI  changed:

   What|Removed |Added

 Attachment #212457|0   |1
is obsolete||

--- Comment #46 from Tomoaki AOKI  ---
Created attachment 246766
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=246766=edit
Patch for stable13 and later proto.c

Patch for proto.c, stable/13 and later.

This is a forgotten-to-upload patch after Nomichi Nonaka updated his patch.

After my previous patch,
  *Copied Naomichi Nonaka's mygetchar() to proto.c and use it
   instead of getchar() to leave boot1.c untouched.

This modified patch adds disk info in conjunction with partition No.,
instead of partition raw UUID used by Naomichi's latest patch.
CHOOSE WHICHEVER YOU LIKE. DO NOT ATTEMPT TO APPLY BOTH AT ONCE!

This should be applicable both head and stable/13 with some offsets or fuzzes.

Ideally, disk and patrition info 100% matches just as running FreeBSD does like
ada0p3, da1s1, but it's not implemented.

Beware! NVMe drives would be shown up like drive(??), as proper DEVICE_PATH
info is not yet defined on FreeBSD (U)EFI implementation.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 207940] stand/efi/boot1: Add boot partition selection

[bugzilla-noreply]

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

--- Comment #45 from Tomoaki AOKI  ---
(In reply to Nicolas from comment #44)

If you applied BOTH PATCHES AT ONCE, DO NOT DO SO.
Choose whichebver you want, just one.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 207940] stand/efi/boot1: Add boot partition selection

[bugzilla-noreply]

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

--- Comment #44 from Nicolas  ---
Can't compile on FreeBSD 14.0:

--- gptboot.sym.full ---
cc -O2 -pipe -fno-common -I/usr/src/stand/efi/boot1
-I/usr/src/stand/efi/gptboot -DBOOTPROG=\"gptboot.efi\" -DHAVE_MEMCPY
-I/usr/src/sys/contrib/zlib -Wformat -fshort-wchar -mno-red-zone -nostdinc
-I/usr/obj/usr/src/amd64.amd64/stand/libsa -I/usr/src/stand/libsa -D_STANDALONE
-I/usr/src/sys -Ddouble=jagged-little-pill -Dfloat=floaty-mcfloatface
-ffunction-sections -fdata-sections -DLOADER_GELI_SUPPORT
-I/usr/src/stand/libsa/geli -DLOADER_DISK_SUPPORT -ffreestanding -mno-mmx
-mno-sse -mno-avx -mno-avx2 -msoft-float -fPIC -mno-red-zone -mno-relax -I.
-Iinclude -DEFI_BOOT1 -I/usr/src/stand/efi/include
-I/usr/src/stand/efi/include/amd64 -I/usr/src/sys/contrib/dev/acpica/include
-DEFI_UFS_BOOT -DEFI_DEBUG -I/usr/src/stand/common -fPIC -g -gz=zlib -std=gnu99
-Wno-format-zero-length -Wsystem-headers -Werror -Wall -Wno-format-y2k -W
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter
-Wcast-align -Wchar-subscripts -Wnested-externs -Wold-style-definition
-Wno-pointer-sign -Wdate-time -Wmissing-variable-declarations -Wthread-safety
-Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable
-Wno-error=unused-but-set-parameter -Oz -Qunused-arguments  -nostdlib
-Wl,-T/usr/src/stand/efi/loader/arch/amd64/ldscript.amd64,-Bsymbolic,-znotext
-pie -Wl,-znocombreloc -Wl,-zrelro   -o gptboot.sym.full gpt.o boot1.o proto.o
self_reloc.o start.o ufs_module.o devpath.o 
/usr/obj/usr/src/amd64.amd64/stand/efi/libefi/libefi.a
/usr/obj/usr/src/amd64.amd64/stand/libsa/libsa.a 
ld: error: undefined symbol: getchar
>>> referenced by panic.c:48 (/usr/src/stand/libsa/panic.c:48)
>>>   panic.o:(panic_action) in archive 
>>> /usr/obj/usr/src/amd64.amd64/stand/libsa/libsa.a
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** [gptboot.sym.full] Error code 1

make[2]: stopped in /usr/src/stand/efi/gptboot
1 error

make[2]: stopped in /usr/src/stand/efi/gptboot

make[1]: stopped in /usr/src/stand/efi
--- all_subdir_efi/boot1 ---

Both patch fully applied:
1. Patch for boot1.c and proto.c
2020-03-17 12:10 UTC, Tomoaki AOKI
2. patch for head r350654 proto.c
2020-03-23 16:02 UTC, Naomichi Nonaka (require manual application of the patch
for the second part).

Any idea on how to fix to make it works on FreeBSD 14.0 RELEASE ?

Thanks

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 188504] system is overheating

[bugzilla-noreply]

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

chris.long...@gmail.com  changed:

   What|Removed |Added

 CC||chris.long...@gmail.com

--- Comment #2 from chris.long...@gmail.com  ---
Read the following articles: 
https://wiki.freebsd.org/TuningPowerConsumption
https://www.neelc.org/posts/optimize-freebsd-for-intel-tigerlake/

and try setting in /etc/sysctl.conf::

dev.hwpstate_intel.0.epp=100
dev.hwpstate_intel.1.epp=100
dev.hwpstate_intel.2.epp=100
dev.hwpstate_intel.3.epp=100
...
...
...

and machdep.hwpstate_pkg_ctrl=0 in /boot/loader.conf:

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

[Bug 208414] 10.3-RELEASE: *ERROR* Power management discrepancy: GEN6_RP_INTERRUPT_LIMITS expected 1a0d0000, was 1a000000

[bugzilla-noreply]

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

Mark Linimon  changed:

   What|Removed |Added

   Assignee|b...@freebsd.org|lini...@freebsd.org
 CC|am...@freebsd.org   |

--- Comment #1 from Mark Linimon  ---
To submitter: was this problem ever addressed?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 210986] Conflict ZFS with GEOM ?

[bugzilla-noreply]

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

Graham Perrin  changed:

   What|Removed |Added

 CC||grahamper...@gmail.com
 Status|New |Open

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209441] SSHd in FreeBSD 10.3 complains about PrintLastLog

[bugzilla-noreply]

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

--- Comment #25 from commit-h...@freebsd.org ---
A commit in branch main references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=d5e2d0f140cef6d09c4ddeb594cee027642366a7

commit d5e2d0f140cef6d09c4ddeb594cee027642366a7
Author: Ed Maste 
AuthorDate: 2023-07-18 16:23:31 +
Commit: Ed Maste 
CommitDate: 2023-07-18 16:27:02 +

openssh: document a locally-applied workaround

We have a local hacky workaround for an issue caused by a hacky
upstream autoconf test.  Reported upstream on the OpenSSH mailing list:
https://lists.mindrot.org/pipermail/openssh-unix-dev/2022-May/040242.html

PR: 209441
Sponsored by:   The FreeBSD Foundation

 crypto/openssh/FREEBSD-upgrade | 8 
 1 file changed, 8 insertions(+)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 183823] error when system start

[bugzilla-noreply]

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

Joseph Mingrone  changed:

   What|Removed |Added

 CC||j...@freebsd.org

--- Comment #2 from Joseph Mingrone  ---
Unfortunately no action was taken on this bug report for almost a decade, so it
may be 'overcome by events'.  Rabih, can you give us an update?

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

[Bug 162489] After some time X blanks the screen and does not respone to mouse or keyboard

[bugzilla-noreply]

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

Joseph Mingrone  changed:

   What|Removed |Added

 CC||j...@freebsd.org

--- Comment #3 from Joseph Mingrone  ---
Unfortunately, no action was taken on this bug for over a decade, so it likely
has been 'overcome by events'.  DPMS doesn't suspend the laptop, but affects
power management related to the display.

User &, do you know if this is still a problem with recent FreeBSD and Xorg
versions?

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

[Bug 209473] There is no /dev/psm0 device for my synaptics touchpad when I load FreeBSD 10.3-RELEASE

[bugzilla-noreply]

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

Oleg  changed:

   What|Removed |Added

 Status|New |Closed
 Resolution|--- |Feedback Timeout

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209441] SSHd in FreeBSD 10.3 complains about PrintLastLog

[bugzilla-noreply]

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

--- Comment #24 from commit-h...@freebsd.org ---
A commit in branch stable/12 references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=545163d9bc9c807cad78577bfe3346efb2d02482

commit 545163d9bc9c807cad78577bfe3346efb2d02482
Author: Ed Maste 
AuthorDate: 2023-04-20 00:09:13 +
Commit: Ed Maste 
CommitDate: 2023-04-27 16:48:33 +

openssh: restore PrintLastLog option

Upstream's autoconf sets DISABLE_LASTLOG if lastlog.ll_line does not
exist, but PrintLastLog also works with utmpx and other mechanisms.

Reported upstream at
https://lists.mindrot.org/pipermail/openssh-unix-dev/2022-May/040242.html

PR: 209441
Sponsored by:   The FreeBSD Foundation

(cherry picked from commit 43c6b7a60aff069da7e0ba6c87d3d7a532e812f6)
(cherry picked from commit 170511589e4d15a27ee92979691cfc1b26929bb7)
(cherry picked from commit 170520f882297617eaee7665a6813d03243e87a4)

 crypto/openssh/config.h | 2 +-
 crypto/openssh/configure.ac | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209441] SSHd in FreeBSD 10.3 complains about PrintLastLog

[bugzilla-noreply]

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

Ed Maste  changed:

   What|Removed |Added

 Status|In Progress |Closed
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209441] SSHd in FreeBSD 10.3 complains about PrintLastLog

[bugzilla-noreply]

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

--- Comment #23 from commit-h...@freebsd.org ---
A commit in branch stable/13 references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=170520f882297617eaee7665a6813d03243e87a4

commit 170520f882297617eaee7665a6813d03243e87a4
Author: Ed Maste 
AuthorDate: 2023-04-20 00:09:13 +
Commit: Ed Maste 
CommitDate: 2023-04-27 16:45:37 +

openssh: restore PrintLastLog option

Upstream's autoconf sets DISABLE_LASTLOG if lastlog.ll_line does not
exist, but PrintLastLog also works with utmpx and other mechanisms.

Reported upstream at
https://lists.mindrot.org/pipermail/openssh-unix-dev/2022-May/040242.html

PR: 209441
Sponsored by:   The FreeBSD Foundation

(cherry picked from commit 43c6b7a60aff069da7e0ba6c87d3d7a532e812f6)
(cherry picked from commit 170511589e4d15a27ee92979691cfc1b26929bb7)

 crypto/openssh/config.h | 2 +-
 crypto/openssh/configure.ac | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209441] SSHd in FreeBSD 10.3 complains about PrintLastLog

[bugzilla-noreply]

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

--- Comment #22 from commit-h...@freebsd.org ---
A commit in branch main references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=170511589e4d15a27ee92979691cfc1b26929bb7

commit 170511589e4d15a27ee92979691cfc1b26929bb7
Author: Ed Maste 
AuthorDate: 2023-04-20 00:03:26 +
Commit: Ed Maste 
CommitDate: 2023-04-20 22:08:16 +

openssh: Update configure for DISABLE_LASTLOG

PR: 209441
Sponsored by:   The FreeBSD Foundation

 crypto/openssh/configure.ac | 1 +
 1 file changed, 1 insertion(+)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209441] SSHd in FreeBSD 10.3 complains about PrintLastLog

[bugzilla-noreply]

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

--- Comment #21 from commit-h...@freebsd.org ---
A commit in branch main references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=43c6b7a60aff069da7e0ba6c87d3d7a532e812f6

commit 43c6b7a60aff069da7e0ba6c87d3d7a532e812f6
Author: Ed Maste 
AuthorDate: 2023-04-20 00:09:13 +
Commit: Ed Maste 
CommitDate: 2023-04-20 01:17:59 +

openssh: restore PrintLastLog option

Upstream's autoconf sets DISABLE_LASTLOG if lastlog.ll_line does not
exist, but PrintLastLog also works with utmpx and other mechanisms.

Reported upstream at
https://lists.mindrot.org/pipermail/openssh-unix-dev/2022-May/040242.html

PR: 209441
Sponsored by:   The FreeBSD Foundation

 crypto/openssh/config.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209441] SSHd in FreeBSD 10.3 complains about PrintLastLog

[bugzilla-noreply]

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

Ed Maste  changed:

   What|Removed |Added

 Status|Open|In Progress

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209441] SSHd in FreeBSD 10.3 complains about PrintLastLog

[bugzilla-noreply]

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

Ed Maste  changed:

   What|Removed |Added

   Assignee|d...@freebsd.org |ema...@freebsd.org

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209441] SSHd in FreeBSD 10.3 complains about PrintLastLog

[bugzilla-noreply]

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

--- Comment #20 from Ed Maste  ---
(In reply to Yuri Pankov from comment #19)
Actually after a little more thought I believe the right fix is:

 /* Define if you don't want to use lastlog */
-#define DISABLE_LASTLOG 1
+/* #undef DISABLE_LASTLOG */

and should be addressed upstream by fixing configure

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209441] SSHd in FreeBSD 10.3 complains about PrintLastLog

[bugzilla-noreply]

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

Yuri Pankov  changed:

   What|Removed |Added

 CC||yur...@freebsd.org

--- Comment #19 from Yuri Pankov  ---
(In reply to Ed Maste from comment #18)
Just noticed this as well, and the patch takes care of the problem.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 248659] Specific intel chips lock up with P-states active

[bugzilla-noreply]

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

Dries Michiels  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|New |Closed

--- Comment #41 from Dries Michiels  ---


*** This bug has been marked as a duplicate of bug 253288 ***

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

[Bug 207940] stand/efi/boot1: Add boot partition selection

[bugzilla-noreply]

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

--- Comment #43 from Tomoaki AOKI  ---
(In reply to Warner Losh from comment #42)

Glad to know the plan!
Once it is completed, I have no objection to retire boot1.efi.

I should mention that...
  *When selected non-default partition, boot should be done
   as if selected partition is the default partition.
   Currently, as boot1.efi kickes loader.efi and /boot/loader.conf
   is handled by loader.efi, this is naturally achieved.

  *If possible (I know it would be difficult), partitions would be
   better shown just as booted FreeBSD, like ada0s1, da2p5,...
   Maybe, nvd* and nda case would be impossible, as it depends on
   /boot/loader.conf settings.

BTW, current default partition (pool) selection order is different
between boot1.efi and loader.efi. Is this intentional?
Current default boot1.efi behaves like
  1. ZFS has always higher priority than UFS in the same physical drive.
  2. First, sniff the drive UEFI loaded boot1.efi itself.
  3. If neither ZFS pools nor UFS partitions have /boot/loader.conf,
 seek for next drive.
  4. Drives are sniffed the order UEFI firmware finds.
  5. Boot from first pool/partition found.

The 1. seems to be different on loader.efi, IIUC.

1. would be because Non-Root-on-ZFS pool wouldn't have /boot/loader.efi
and admins would want ZFS pool over UFS if installed as Root-on-ZFS.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 207940] stand/efi/boot1: Add boot partition selection

[bugzilla-noreply]

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

Warner Losh  changed:

   What|Removed |Added

   Assignee|b...@freebsd.org|i...@freebsd.org

--- Comment #42 from Warner Losh  ---
my preference is to put this functionality in loader.efi. boot1.efi is in the
process of being deprecated because of the limited number of supported boot
scenarios it can cover relative to loader.efi and that boot1.efi duplicates
much of the selection process loader.efi does.

However, gptboot.efi shows that there's a good case to be made for exceptions
to the rule, and this might be OK until the functionality can be migrated to
loader.efi.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 207940] stand/efi/boot1: Add boot partition selection

[bugzilla-noreply]

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

Graham Perrin  changed:

   What|Removed |Added

 CC||grahamper...@freebsd.org
  Flags|mfc-stable12?,  |
   |mfc-stable11?   |

--- Comment #41 from Graham Perrin  ---
Triage: 

* outdated flags
* assign to kern@ ?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 207940] stand/efi/boot1: Add boot partition selection

[bugzilla-noreply]

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

Graham Perrin  changed:

   What|Removed |Added

   See Also||https://bugs.freebsd.org/bu
   ||gzilla/show_bug.cgi?id=2046
   ||74

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 174679] Intel i5 laptop overheats and shuts down [regression]

[bugzilla-noreply]

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

b...@area536.com changed:

   What|Removed |Added

 Resolution|--- |Overcome By Events
 Status|Open|Closed

--- Comment #3 from b...@area536.com ---
As the reporter: I don't have this laptop anymore so I cannot verify anymore if
this is still relevant. Closing it.

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

[Bug 207677] atrtc Warning: Couldn't map I/O on Skylake Supermicro X11SSH-LN4F

[bugzilla-noreply]

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

Vladislav V. Prodan  changed:

   What|Removed |Added

 CC||ad...@support.od.ua

--- Comment #10 from Vladislav V. Prodan  ---

Up.

FreeBSD 12.4-STABLE a841c0c24 SUPPORT-12-3-0  amd64
CPU: Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz (3600.15-MHz K8-class CPU)
Motherboard: FUJITSU D3401-H2

...
hpet0:  iomem 0xfed0-0xfed003ff on acpi0
Timecounter "HPET" frequency 2400 Hz quality 950
Event timer "HPET" frequency 2400 Hz quality 550
atrtc0:  port 0x70-0x77 irq 8 on acpi0
atrtc0: Warning: Couldn't map I/O.
atrtc0: registered as a time-of-day clock, resolution 1.00s
Event timer "RTC" frequency 32768 Hz quality 0
attimer0:  port 0x40-0x43,0x50-0x53 irq 0 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0
...

# sysctl kern.eventtimer
kern.eventtimer.periodic: 0
kern.eventtimer.timer: LAPIC
kern.eventtimer.idletick: 0
kern.eventtimer.singlemul: 2
kern.eventtimer.choice: LAPIC(600) HPET(550) i8254(100) RTC(0)
kern.eventtimer.et.i8254.quality: 100
kern.eventtimer.et.i8254.frequency: 1193182
kern.eventtimer.et.i8254.flags: 1
kern.eventtimer.et.RTC.quality: 0
kern.eventtimer.et.RTC.frequency: 32768
kern.eventtimer.et.RTC.flags: 17
kern.eventtimer.et.HPET.quality: 550
kern.eventtimer.et.HPET.frequency: 2400
kern.eventtimer.et.HPET.flags: 7
kern.eventtimer.et.LAPIC.quality: 600
kern.eventtimer.et.LAPIC.frequency: 3600153594
kern.eventtimer.et.LAPIC.flags: 7

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 186038] [panic] FreeBSD 10/AMD64 panics on HP Proliant Microserver

[bugzilla-noreply]

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

Graham Perrin  changed:

   What|Removed |Added

   Keywords||crash

--- Comment #4 from Graham Perrin  ---
Keyword: 

crash

– in lieu of summary line prefix: 

[panic]

* bulk change for the keyword
* summary lines may be edited manually (not in bulk). 

Keyword descriptions and search interface: 



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

[Bug 210466] Page fault in vmxnet3_txq_mq_start_locked -> m_defrag on 10.2-RELEASE-p18 (VMWare ESX 5.5)

[bugzilla-noreply]

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

Kubilay Kocak  changed:

   What|Removed |Added

   Keywords||crash

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 205678] [panic] Fatal trap 12: page fault while in kernel mode (in function rtsock_addrmsg)

[bugzilla-noreply]

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

Graham Perrin  changed:

   What|Removed |Added

   Keywords||crash

--- Comment #2 from Graham Perrin  ---
Keyword: 

crash

– in lieu of summary line prefix: 

[panic]

* bulk change for the keyword
* summary lines may be edited manually (not in bulk). 

Keyword descriptions and search interface: 



-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 171814] [panic] bioq_init or bioq_remove (unsure which)

[bugzilla-noreply]

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

Graham Perrin  changed:

   What|Removed |Added

   Keywords||crash

--- Comment #5 from Graham Perrin  ---
Keyword: 

crash

– in lieu of summary line prefix: 

[panic]

* bulk change for the keyword
* summary lines may be edited manually (not in bulk). 

Keyword descriptions and search interface: 



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

[Bug 205806] [patch] bsdinstall(8): partedit can hang/crash on read/lseek/malloc failures

[bugzilla-noreply]

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

Graham Perrin  changed:

   What|Removed |Added

   Keywords||install

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209099] ata2: already running! panic: bad link elm 0xfffff80003b7e6a0 prev->next != elm

[bugzilla-noreply]

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

hhktya  changed:

   What|Removed |Added

 CC||odobasica...@gmail.com

--- Comment #7 from hhktya  ---
If it occurs at a consistent time in the state run, the trigger may be one of
the underlying OS commands that salt is using. 
https://driftboss.io

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 170351] setrlimit(2): 64-bit children of 32-bit processes cannot have an unlimited rlimit

[bugzilla-noreply]

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

Kubilay Kocak  changed:

   What|Removed |Added

   Severity|Affects Only Me |Affects Some People
 CC||mq...@juniper.net
Summary|[kernel] amd64: 64-bit  |setrlimit(2): 64-bit
   |process can't always get|children of 32-bit
   |unlimited rlimit|processes cannot have an
   ||unlimited rlimit
  Flags||maintainer-feedback?(mqiao@
   ||juniper.net)
   Assignee|am...@freebsd.org   |b...@freebsd.org
  Component|amd64   |kern
   Keywords|patch   |needs-patch, needs-qa
   Hardware|Any |amd64

--- Comment #6 from Kubilay Kocak  ---
^Triage: Update issue to reflect latest (2012) state.

- Clarify summary to reflect problem as reported
- Reporter aimed to submit an updated patch (needs-patch)
- kib@ suggested two approaches (one a workaround, one a non trivial change for
a minor case)

Request feedback from (hopefully still available reporter)

@Konstantin If your second non-trivial code change is unlikely to be accepted,
we also have the option of closing Not Accepted based on what we have so far (a
not accepted initial patch)

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

[Bug 170351] [kernel] amd64: 64-bit process can't always get unlimited rlimit

[bugzilla-noreply]

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

Konstantin Belousov  changed:

   What|Removed |Added

Summary|[kernel] [patch] amd64: |[kernel] amd64: 64-bit
   |64-bit process can't always |process can't always get
   |get unlimited rlimit|unlimited rlimit
 CC||k...@freebsd.org

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

[Bug 170351] [kernel] [patch] amd64: 64-bit process can't always get unlimited rlimit

[bugzilla-noreply]

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

Graham Perrin  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #5 from Graham Perrin  ---
Keyword: 

patch
or  patch-ready

– in lieu of summary line prefix: 

[patch]

* bulk change for the keyword
* summary lines may be edited manually (not in bulk). 

Keyword descriptions and search interface: 



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

[Bug 248659] Specific intel chips lock up with P-states active

[bugzilla-noreply]

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

Jonathan Vasquez  changed:

   What|Removed |Added

 CC||j...@xyinn.org

--- Comment #40 from Jonathan Vasquez  ---
This crash/lock up also happens on my Thinkpad X260 on FreeBSD 13.1-RELEASE
amd64. If I close the lid on AC power, everything works fine. If I close the
lid on battery power, the system immediately locks up when I close it.

Adding "hint.hwpstate_intel.0.disabled=1" to /boot/loader.conf was the only
thing that "fixed" it.

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

[Bug 209275] Cannot utilize both serial and efi console with UEFI booting

[bugzilla-noreply]

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

Daniel O'Connor  changed:

   What|Removed |Added

 CC||dar...@dons.net.au

--- Comment #3 from Daniel O'Connor  ---
As a note to future gogglers that find this. I had to add:
comconsole_port="0x2f8"

to loader.conf otherwise it would not work, eg dmesg would show:
uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 on acpi0
uart0: console (115200,n,8,1)
uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 flags 0x10 on acpi0

(Seemingly ignoring the flags and making uart0 a console..)

This is on a Supermicro X11SRM-F running FreeBSD 13.1-RELEASE.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209441] SSHd in FreeBSD 10.3 complains about PrintLastLog

[bugzilla-noreply]

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

--- Comment #18 from Ed Maste  ---
This is a bug in OpenSSH upstream and I've sent mail to the openssh-unix-devel
mailing list about it.

This patch is probably closer to the proper fix; please give it a try:

diff --git a/crypto/openssh/servconf.c b/crypto/openssh/servconf.c
index 6eaf9c2876ff..45587631cb8b 100644
--- a/crypto/openssh/servconf.c
+++ b/crypto/openssh/servconf.c
@@ -611,7 +611,7 @@ static struct {
{ "listenaddress", sListenAddress, SSHCFG_GLOBAL },
{ "addressfamily", sAddressFamily, SSHCFG_GLOBAL },
{ "printmotd", sPrintMotd, SSHCFG_GLOBAL },
-#ifdef DISABLE_LASTLOG
+#if defined(DISABLE_LASTLOG) && defined(DISABLE_UTMPX)
{ "printlastlog", sUnsupported, SSHCFG_GLOBAL },
 #else
{ "printlastlog", sPrintLastLog, SSHCFG_GLOBAL },
@@ -2915,7 +2915,7 @@ dump_config(ServerOptions *o)
dump_cfg_fmtint(sKbdInteractiveAuthentication,
o->kbd_interactive_authentication);
dump_cfg_fmtint(sPrintMotd, o->print_motd);
-#ifndef DISABLE_LASTLOG
+#if !defined(DISABLE_LASTLOG) || !defined(DISABLE_UTMPX)
dump_cfg_fmtint(sPrintLastLog, o->print_lastlog);
 #endif
dump_cfg_fmtint(sX11Forwarding, o->x11_forwarding);

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209441] SSHd in FreeBSD 10.3 complains about PrintLastLog

[bugzilla-noreply]

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

--- Comment #17 from Ed Maste  ---
It looks like this originated in

commit a2438bbd28eb35a8968d193ac89b30a90e96f719
Author: Damien Miller 
Date:   Fri Mar 15 10:23:07 2013 +1100

 - (djm) [configure.ac] Disable utmp, wtmp and/or lastlog if the platform
is unable to successfully compile them. Based on patch from des AT
des.no

which added

+AC_CHECK_MEMBER([struct lastlog.ll_line], [], [
+   AC_DEFINE([DISABLE_LASTLOG])   <---
+   ], [
+#ifdef HAVE_SYS_TYPES_H
+#include 
+#endif
+#ifdef HAVE_UTMP_H
+#include 
+#endif
+#ifdef HAVE_UTMPX_H
+#include 
+#endif
+#ifdef HAVE_LASTLOG_H
+#include 
+#endif
+   ])


this defines DISABLE_LASTLOG if we don't have lastlog.ll_line, but this is used
only in (the two implementations of) lastlog_get_entry; utmpx_get_entry is
still functional.

Can you try building with this change?

diff --git a/crypto/openssh/config.h b/crypto/openssh/config.h
index 943f8c6e4b6e..4e0261b6a60a 100644
--- a/crypto/openssh/config.h
+++ b/crypto/openssh/config.h
@@ -113,7 +113,7 @@
 /* #undef DISABLE_FD_PASSING */

 /* Define if you don't want to use lastlog */
-#define DISABLE_LASTLOG 1
+/* #undef DISABLE_LASTLOG */

 /* Define if you don't want to use your system's login() call */
 /* #undef DISABLE_LOGIN */

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 185003] [panic] Random kernel panics

[bugzilla-noreply]

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

Ed Maste  changed:

   What|Removed |Added

 Status|Open|Closed
 CC||ema...@freebsd.org
 Resolution|--- |Unable to Reproduce

--- Comment #4 from Ed Maste  ---
I am sorry that nobody was able to investigate this issue at the time that you
reported it. As any version of FreeBSD available in 2013 is now long past EOL I
am going to close this as not reproducible.

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

[Bug 248659] Specific intel chips lock up with P-states active

[bugzilla-noreply]

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

--- Comment #39 from Sergei Masharov  ---
My bad, the issue still exist in the 13.1-BETA1

I completely forgot about hint.hwpstate_intel.0.disabled=1 in /boot/loader.conf

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

[Bug 248659] Specific intel chips lock up with P-states active

[bugzilla-noreply]

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

--- Comment #38 from Sergei Masharov  ---
(In reply to Dries Michiels from comment #36)
I have commented two lines below from device.hints and the system is running as
it should.
also the dev.cpu.0.freq_levels shows the sane values

#hint.acpi_throttle.0.disabled="1"
#hint.p4tcc.0.disabled="1"

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

[Bug 248659] Specific intel chips lock up with P-states active

[bugzilla-noreply]

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

--- Comment #37 from rkober...@gmail.com ---
(In reply to Sergei Masharov from comment #35)
Is this just a case of "Now it works" or is there some indication of a fix?

In any case, I'll update to BETA-1 and give it a go.

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

[Bug 248659] Specific intel chips lock up with P-states active

[bugzilla-noreply]

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

--- Comment #36 from Dries Michiels  ---
How did you verify this?

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

[Bug 248659] Specific intel chips lock up with P-states active

[bugzilla-noreply]

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

--- Comment #35 from Sergei Masharov  ---
it looks like the issue was fixed in 13.1-BETA1

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

[Bug 207940] stand/efi/boot1: Add boot partition selection

[bugzilla-noreply]

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

--- Comment #40 from Tomoaki AOKI  ---
(In reply to Nicolas from comment #39)

At least the latest (Naomichi's) patch should be applicable with some offsets
and builds/runs fine.

As the patch was created against current (now called main after git transition)
before stable/13 was branched, all 13.x should be OK.

I always build world/kernel with the patch applied both on main and stable/13
(without committing locally, but `git stash`/`git stash apply` for every `git
up`), and give the patched boot1.efi a try whether it's still working or not
when some suspicious commits are done on src/stand/*.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 207940] stand/efi/boot1: Add boot partition selection

[bugzilla-noreply]

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

--- Comment #39 from Nicolas  ---
What's the status of the patch for stable/13, 13.1-RELEASE branches ? Thanks.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209821] UEFI - installation media hangs when booting on ASUS P6P67 DELUXE

[bugzilla-noreply]

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

--- Comment #79 from David Sebek  ---
(In reply to Riccardo Robecchi from comment #78)

It looks like a different problem to me. In your case, the UEFI framebuffer is
probably not recognized by the bootloader (the dimensions are all zero). So the
kernel doesn't know where to print the output.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 115194] LCD screen remains blank after Dell XPS M1210 lid is closed and reopened.

[bugzilla-noreply]

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

Stefan B.  changed:

   What|Removed |Added

 CC||sblachm...@gmail.com

--- Comment #7 from Stefan B.  ---
Can probably be closed, because in the now-supported releases the correct
i915kms.ko gets loaded.

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

[Bug 181358] [suspend/resume] Suspend to RAM not working correctly on Lenovo X121e (ACPI issue?)

[bugzilla-noreply]

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

Stefan B.  changed:

   What|Removed |Added

 CC||sblachm...@gmail.com

--- Comment #4 from Stefan B.  ---
Close this PR, please.
Has been fixed, see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253733#c6

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

[Bug 207431] graphics/sane-backends: scanimage triggers ata2: FAILURE - odd-sized DMA transfer attempt

[bugzilla-noreply]

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

VVD  changed:

   What|Removed |Added

 CC||v...@unislabs.com

--- Comment #8 from VVD  ---
Try 1.1.1: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261433

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209821] UEFI - installation media hangs when booting on ASUS P6P67 DELUXE

[bugzilla-noreply]

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

Riccardo Robecchi  changed:

   What|Removed |Added

 CC||sephiroth...@hotmail.it

--- Comment #78 from Riccardo Robecchi  ---
I am running in the same issue on an Apple iMac 7,1 (Core 2 Duo, 2.0 GHz, 4 GB
RAM). The device simply hangs while booting with the following text:

EFI framebuffer information:
addr, size  0x0, 0x0
dimensions  0 x 0
stride  0
masks   0x, 0x, 0x, 0x

I have tried booting 13.0-RELEASE, 13.0-STABLE (build
20220113-972796d007c-248936) as well as 12.2-STABLE. All of those builds result
in a hang.
This message follows a similar one I've posted on the helloSystem bug tracker
(https://github.com/helloSystem/ISO/issues/362), but I'm reporting it here as
the issue is present with the "pure" FreeBSD images. Please do let me know if
opening a new bug report, instead of continuing the discussion here, would be
better.
Thank you!

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209821] UEFI - installation media hangs when booting on ASUS P6P67 DELUXE

[bugzilla-noreply]

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

--- Comment #77 from David Sebek  ---
(In reply to Dani from comment #76)

Hello Dani,

The patch doesn't address all scenarios that may result in a system freeze. The
proper fix is in 13.0-STABLE and 14.0-CURRENT. See comment #66 for a short
explanation.

There is one thing that came to my mind after seeing your results. I remember
that when I was debugging the problem, I created a KVM virtual machine with
multiple serial consoles connected to it. I found that:

- The boot loader uses the existing UEFI frame buffer to print all its output
until the "EFI framebuffer information" ending with the "masks ..." line. This
information was printed to all serial consoles.

- The boot loader then gives control over to the kernel, which uses its own
serial console configuration. It uses COM1 by default for the serial console.
The kernel's serial console output was therefore printed only to COM1.

In the case of my virtual machine, all information until the "EFI framebuffer
information" block was printed to all serial consoles, and the kernel output
that followed was printed only to COM1. Consoles other than COM1 didn't advance
past the "EFI framebuffer information", even though the system was running.

In your case, is the video/serial output properly set in the boot loader when
you boot the system? It may be possible that the kernel prints the output to a
wrong serial console or stops booting because it could not detect a serial
console on COM1? Did you try FreeBSD 13-STABLE to see if it boots?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209821] UEFI - installation media hangs when booting on ASUS P6P67 DELUXE

[bugzilla-noreply]

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

--- Comment #76 from Dani  ---
Hey David & Konstantin

First of all thanks a lot for your work and also for taking a look at 12.3 and
providing a patch for it! That is really much appreciated.

I've patched our FBSD 12.3, rebuilt and installed everything. Sadly it didn't
fix the problem for us. But while testing we found out the following behavior:

Our Hardware: HPE ProLiant BL460c Gen10

We did the following steps:
1) Install the patched version of 12.3 and shutdown afterwards
2) Attach to the virtual serial port (COM1) via "Integrated LightsOut" to
monitor boot process
3) "Cold Boot" the server
-> Boot OK, no hang / error
2) Normal Reboot with "shutdown -r now"
-> Boot OK, no Hang / Error
3) Detach from virtual serial port (COM1)
4) Normal Reboot with "shutdown -r now" 
-> Broken. Hangs after "EFI Framebuffer" is printed (see below)
5) "Cold Boot" the server
-> Still Broken.
6) Reatach to virtual serial port (COM1)
7) Reset the server via "ILO"
-> Boot OK, no hang / error

This only happens when using the "loader.efi" from 12.3 (or 12.2). When we copy
the loader.efi from 12.1 to the EFI-Partition (/efi/boot/BOOTx64.efi) the
server boots and works totally fine in any configuration.

Here's the last printed output befor the hang:
EFI framebuffer information:
addr, size 0xd800, 0x30
dimensions 1024 x 768
stride 1024
masks  0x00ff, 0xff00, 0x00ff, 0xff00


To be honest: I'm not sure if this has the same root cause. Also i'm not quite
sure on how to debug this any further.. If you have any input or idea - we'd be
very happy for your reply!

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 207431] graphics/sane-backends: scanimage triggers ata2: FAILURE - odd-sized DMA transfer attempt

[bugzilla-noreply]

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

--- Comment #7 from tech-li...@zyxst.net ---
(In reply to Charles Ziegler from comment #1)

I've commented out all but epson2 backend but it made no difference in my case.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 207431] graphics/sane-backends: scanimage triggers ata2: FAILURE - odd-sized DMA transfer attempt

[bugzilla-noreply]

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

--- Comment #6 from tech-li...@zyxst.net ---
maybe this PR needs to be closed and a new one opened? as it was originally
logged against releng/10.2 but am seeing it on stable/13

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 207431] graphics/sane-backends: scanimage triggers ata2: FAILURE - odd-sized DMA transfer attempt

[bugzilla-noreply]

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

tech-li...@zyxst.net changed:

   What|Removed |Added

 CC||tech-li...@zyxst.net

--- Comment #5 from tech-li...@zyxst.net ---
(In reply to Nathan from comment #4)

I'm seeing this exact same error

1. zfs-on-root

2. hardware: https://bsd-hardware.info/?probe=d914e4c500

3. stable/13-n248872-2c7441c86ef: Thu Jan  6 02:34:00 UTC 2022
   r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64

packages were installed from pkg.freebsd.org

if I run sane-find-scanner -q

this happens:

Jan 10 00:41:29 kernel: ugen4.2:  at usbus4

as expected, but a few seconds later, this happens:

Jan 10 00:50:33 kernel: ata2: FAILURE - odd-sized DMA transfer attempt 5 % 2
Jan 10 00:50:33 kernel: ata2: setting up DMA failed
Jan 10 00:53:36 syslogd: kernel boot file is /boot/kernel/kernel
Jan 10 00:53:36 kernel: ata3: already running!
Jan 10 00:53:36 kernel: ata2: already running!
Jan 10 00:53:36 kernel: spin lock 0x81cac3c0 (callout) held by 
0xfe000f91f3a0 (tid 13) too long

resulting in a lockup at next write then drops to console, press any key to
reboot.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209821] UEFI - installation media hangs when booting on ASUS P6P67 DELUXE

[bugzilla-noreply]

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

--- Comment #75 from Graham Perrin  ---
*** Bug 255073 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209821] UEFI - installation media hangs when booting on ASUS P6P67 DELUXE

[bugzilla-noreply]

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

Konstantin Belousov  changed:

   What|Removed |Added

 Status|In Progress |Closed
 Resolution|--- |FIXED

--- Comment #74 from Konstantin Belousov  ---
I am closing this because we cannot do more for stable/12.  For HEAD and
stable/13,
the proper fix was implemented some time ago.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209821] UEFI - installation media hangs when booting on ASUS P6P67 DELUXE

[bugzilla-noreply]

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

--- Comment #73 from commit-h...@freebsd.org ---
A commit in branch stable/12 references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=f131d68e21fc360f5c8e63377f25cf60706d9afa

commit f131d68e21fc360f5c8e63377f25cf60706d9afa
Author: David Sebek 
AuthorDate: 2022-01-07 20:18:49 +
Commit: Konstantin Belousov 
CommitDate: 2022-01-09 01:28:01 +

efi: loader: Inline copy_finish function in amd64 trampoline

Instead of calling the efi_copy_finish function from amd64_tramp,
include the copy instructions in the trampoline code itself.
This avoids boot hangs and restarts in the cases when
the efi_copy_finish code happens to be located at a memory
location that is overwritten during the copy process.

This is a direct commit to stable/12 since no-copy loader mode requires
the kernel update not suitable for the branch.

PR: 209821

 stand/efi/loader/arch/amd64/amd64_tramp.S   | 59 +++--
 stand/efi/loader/arch/amd64/elf64_freebsd.c | 18 +
 stand/efi/loader/copy.c |  8 
 stand/efi/loader/loader_efi.h   |  1 +
 4 files changed, 60 insertions(+), 26 deletions(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209821] UEFI - installation media hangs when booting on ASUS P6P67 DELUXE

[bugzilla-noreply]

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

--- Comment #72 from David Sebek  ---
Created attachment 230823
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=230823=edit
Updated edited version of the David's patch

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209821] UEFI - installation media hangs when booting on ASUS P6P67 DELUXE

[bugzilla-noreply]

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

--- Comment #71 from David Sebek  ---
(In reply to Konstantin Belousov from comment #69)

I tested the updated patch on my system, and it works. I made some minor
modifications to the patch:
- Corrected the copyright year
- Fixed one comment
- Fixed indentation of one comment

I think the efi_copy_finish function is also no longer needed besides the fact
that I referenced it in a comment in the trampoline code.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209821] UEFI - installation media hangs when booting on ASUS P6P67 DELUXE

[bugzilla-noreply]

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

Konstantin Belousov  changed:

   What|Removed |Added

 Attachment #225480|0   |1
is obsolete||
 Attachment #230798|0   |1
is obsolete||

--- Comment #70 from Konstantin Belousov  ---
Created attachment 230812
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=230812=edit
Edited version of the David' patch

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209821] UEFI - installation media hangs when booting on ASUS P6P67 DELUXE

[bugzilla-noreply]

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

--- Comment #69 from Konstantin Belousov  ---
(In reply to David Sebek from comment #68)
It looks fine to me.  I did some minimal editings, mostly:
- added your (David) copyright to the file
- removed old trampoline code, I do not see why it is needed
- reorganized registers usage mostly to avoid confusing arg renames
- minimal style update for comments

Can anybody test this and confirm that everything works fine?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209821] UEFI - installation media hangs when booting on ASUS P6P67 DELUXE

[bugzilla-noreply]

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

--- Comment #68 from David Sebek  ---
(In reply to Dani from comment #65)

See patch in comment #67. It is a reduced version of the patch from comment #41
rebased against FreeBSD 12.3. I tested the patch with FreeBSD 12.3, and it
fixes the boot freeze problem on my old laptop.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209821] UEFI - installation media hangs when booting on ASUS P6P67 DELUXE

[bugzilla-noreply]

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

--- Comment #66 from David Sebek  ---
(In reply to Dani from comment #65)
I think there were two reasons why UEFI boot froze on some systems. Before the
changes in 13-STABLE and 14-CURRENT, the kernel needed to be loaded to a
specific physical memory location. Copying the kernel to a specific location in
memory could cause problems:

1. The target location could contain the boot loader code. When the boot loader
was copying the kernel to the expected address in memory, it accidentally
overwrote the boot loader’s code that was responsible for the copy operation,
which resulted in a freeze of the system.

2. The target location could contain hardware-reserved addresses. Copying the
kernel over those memory addresses could freeze the system.

The patch from #41 fixes only the problem (1.) by not using the boot loader
code that may get overwritten.

FreeBSD 14-CURRENT and 13-STABLE fix both problems (1.) and (2.) by not
requiring the kernel to be copied to a specific memory address.

The patch #41 needed some minor modifications in order to be applied to FreeBSD
12. I can take a look at it and update for FreeBSD 12.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209821] UEFI - installation media hangs when booting on ASUS P6P67 DELUXE

[bugzilla-noreply]

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

--- Comment #65 from Dani  ---
(In reply to Ed Maste from comment #64)

Hey Ed, thanks for the hint. I guess you mean the patches from comment #38 or
comment #41 ? Both don't apply against a clean 12.3 src, so i'm not sure how
much sense that makes?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209821] UEFI - installation media hangs when booting on ASUS P6P67 DELUXE

[bugzilla-noreply]

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

--- Comment #64 from Ed Maste  ---
(In reply to Dani from comment #63)
Note that David Sebek's patch in comment #37 may be a feasible way to address
this in stable/12.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 210906] [lor] lock order reversal in vfs_mount/vfs_subr under ZFS

[bugzilla-noreply]

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

Mateusz Guzik  changed:

   What|Removed |Added

 CC||m...@freebsd.org
 Resolution|--- |FIXED
 Status|New |Closed

--- Comment #2 from Mateusz Guzik  ---
fixed in
https://cgit.freebsd.org/src/commit?id=dbc689cdef0cc8ff11171642cdcf107dfbc3fb41

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209821] UEFI - installation media hangs when booting on ASUS P6P67 DELUXE

[bugzilla-noreply]

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

--- Comment #63 from Dani  ---
Thanks for your answers - highly appreciated.

I can see the points in your answers. Well for us FBSD 12 isn't stable, because
we can't even boot our hardware with it. So if there is no way to get this into
12, we'll see what we are going to do. Thanks anyway.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209821] UEFI - installation media hangs when booting on ASUS P6P67 DELUXE

[bugzilla-noreply]

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

--- Comment #62 from Konstantin Belousov  ---
There is obvious contradiction in the request to port this thing to stable/12
branch: the backport is high-risk [*] but the reason that it is asked for is
because stable/12 is perceived as more stable.  In other words, you are asking
to destabilize more stable branch.

* Reason for high-risk is that code in stable/12 diverged enough that I need
to re-read at least the pmap bootstrap code anew and identify all places that
depend on the fixed kernel physical load address from scratch.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209821] UEFI - installation media hangs when booting on ASUS P6P67 DELUXE

[bugzilla-noreply]

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

--- Comment #61 from Ed Maste  ---
(In reply to Dani from comment #60)

It's a significant amount of work to port this to 12.x -- it would basically be
a reimplementation.  Unfortunately we don't expect to have time to look at this
in the near future.

I would highly recommend that affected users plan to migrate to 13.x, and
ideally test workloads on stable/13 snapshots to ensure that 13.1 will meet
their needs.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 248659] Specific intel chips lock up with P-states active

[bugzilla-noreply]

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

--- Comment #34 from Oclair  ---
I've recently purchased a T490 

the system will crash without 
hint.hwpstate_intel.0.disabled=1
added to /boot/loader.conf

fortunately somehow I made it through the install of 13.0 release!

I've been able to get KDE5 to wake up, sleep, auto connect to Wlan, even played
a bit with and connected to some bluetooth devices.  I've switched away from
quarterly to current pkg repo and via using boot environments, I've done
several pkg upgrades without any issues.

Local package database:
Installed packages: 1175
Disk space occupied: 11 GiB

I am a bit confused as this very new hardware has such unbelievable support
added over the last few releases that some strange issue has not yet been
addressed in 13.x

Thank You everyone hopefully this issue will soon be tracked down.
Kind Regards!



FreeBSD t490 13.0-RELEASE-p4 FreeBSD 13.0-RELEASE-p4 #0: Tue Aug 24 07:33:27
UTC 2021
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/amd64.amd64/sys/GENERIC 
amd64

CPU: Intel(R) Core(TM) i7-8665U CPU @ 1.90GHz (2112.11-MHz K8-class CPU)
CPU microcode: updated from 0xd6 to 0xea
FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs
real memory  = 34359738368 (32768 MB)
hostb0@pci0:0:0:0:  class=0x06 rev=0x0c hdr=0x00 vendor=0x8086
device=0x3e34 subvendor=0x17aa subdevice=0x2279
vendor = 'Intel Corporation'
device = 'Coffee Lake HOST and DRAM Controller'
class  = bridge
subclass   = HOST-PCI
vgapci0@pci0:0:2:0: class=0x03 rev=0x02 hdr=0x00 vendor=0x8086
device=0x3ea0 subvendor=0x17aa subdevice=0x2279
vendor = 'Intel Corporation'
device = 'WhiskeyLake-U GT2 [UHD Graphics 620]'
class  = display
subclass   = VGA
none0@pci0:0:4:0:   class=0x118000 rev=0x0c hdr=0x00 vendor=0x8086
device=0x1903 subvendor=0x17aa subdevice=0x2279
vendor = 'Intel Corporation'
device = 'Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal
Subsystem'
class  = dasp
none1@pci0:0:8:0:   class=0x088000 rev=0x00 hdr=0x00 vendor=0x8086
device=0x1911 subvendor=0x17aa subdevice=0x2279
vendor = 'Intel Corporation'
device = 'Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th/8th Gen Core
Processor Gaussian Mixture Model'
class  = base peripheral
pchtherm0@pci0:0:18:0:  class=0x118000 rev=0x30 hdr=0x00 vendor=0x8086
device=0x9df9 subvendor=0x17aa subdevice=0x2279
vendor = 'Intel Corporation'
device = 'Cannon Point-LP Thermal Controller'
class  = dasp
xhci0@pci0:0:20:0:  class=0x0c0330 rev=0x30 hdr=0x00 vendor=0x8086
device=0x9ded subvendor=0x17aa subdevice=0x2279
vendor = 'Intel Corporation'
device = 'Cannon Point-LP USB 3.1 xHCI Controller'
class  = serial bus
subclass   = USB
none2@pci0:0:20:2:  class=0x05 rev=0x30 hdr=0x00 vendor=0x8086
device=0x9def subvendor=0x17aa subdevice=0x2279
vendor = 'Intel Corporation'
device = 'Cannon Point-LP Shared SRAM'
class  = memory
subclass   = RAM
iwm0@pci0:0:20:3:   class=0x028000 rev=0x30 hdr=0x00 vendor=0x8086
device=0x9df0 subvendor=0x8086 subdevice=0x0030
vendor = 'Intel Corporation'
device = 'Cannon Point-LP CNVi [Wireless-AC]'
class  = network
ig4iic0@pci0:0:21:0:class=0x0c8000 rev=0x30 hdr=0x00 vendor=0x8086
device=0x9de8 subvendor=0x17aa subdevice=0x2279
vendor = 'Intel Corporation'
device = 'Cannon Point-LP Serial IO I2C Controller'
class  = serial bus
none3@pci0:0:22:0:  class=0x078000 rev=0x30 hdr=0x00 vendor=0x8086
device=0x9de0 subvendor=0x17aa subdevice=0x2279
vendor = 'Intel Corporation'
device = 'Cannon Point-LP MEI Controller'
class  = simple comms
pcib1@pci0:0:28:0:  class=0x060400 rev=0xf0 hdr=0x01 vendor=0x8086
device=0x9db8 subvendor=0x subdevice=0x
vendor = 'Intel Corporation'
device = 'Cannon Point-LP PCI Express Root Port'
class  = bridge
subclass   = PCI-PCI
pcib2@pci0:0:28:4:  class=0x060400 rev=0xf0 hdr=0x01 vendor=0x8086
device=0x9dbc subvendor=0x17aa subdevice=0x2279
vendor = 'Intel Corporation'
device = 'Cannon Point-LP PCI Express Root Port'
class  = bridge
subclass   = PCI-PCI
pcib7@pci0:0:29:0:  class=0x060400 rev=0xf0 hdr=0x01 vendor=0x8086
device=0x9db0 subvendor=0x17aa subdevice=0x2279
vendor = 'Intel Corporation'
device = 'Cannon Point-LP PCI Express Root Port'
class  = bridge
subclass   = PCI-PCI
pcib8@pci0:0:29:4:  class=0x060400 rev=0xf0 hdr=0x01 vendor=0x8086
device=0x9db4 subvendor=0x17aa subdevice=0x2279
vendor = 'Intel Corporation'
device = 'Cannon Point-LP PCI Express Root Port'
class  = bridge
subclass   = PCI-PCI
isab0@pci0:0:31:0:  class=0x060100 rev=0x30 hdr=0x00 vendor=0x8086
device=0x9d84 subvendor=0x17aa subdevice=0x2279
vendor 

[Bug 209821] UEFI - installation media hangs when booting on ASUS P6P67 DELUXE

[bugzilla-noreply]

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

--- Comment #60 from Dani  ---
@kib @emaste Hey guys :) First of all thanks for your work. Ed, i highlight you
because you commented on bug #209821 and bug #256722, also tagging Konstantin
as author.

I saw that you merged the patches to stable/13 and aren't planning to merge
them to stable/12. We currently use 12.2 and don't plan to upgrade to 13 soon,
since we have a policy to always wait for at least a .2- or even better a
.3-release for stability reasons.

We currently use the 12.1 efi-bootloader as a workaround to have our hardware
(HPE Blades) working with 12.2 (debugged back then with @tsoome). Sadly we
can't use that fix for our network-boot-images. Is there any chance to get the
fixes in stable/12 and maybe even in the 12.3 release? I think there are quite
a bunch of users that would be happy if this would be possible. Thanks for
taking a look at it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209821] UEFI - installation media hangs when booting on ASUS P6P67 DELUXE

[bugzilla-noreply]

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

Ed Maste  changed:

   What|Removed |Added

 Status|New |In Progress

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209821] UEFI - installation media hangs when booting on ASUS P6P67 DELUXE

[bugzilla-noreply]

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

--- Comment #58 from rdun...@smallcatbrain.com ---
I can confirm this is now working on Asus P8P67 LE systemboard.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209821] UEFI - installation media hangs when booting on ASUS P6P67 DELUXE

[bugzilla-noreply]

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

--- Comment #59 from Ed Maste  ---
(In reply to rdunkle from comment #58)
> I can confirm this is now working on Asus P8P67 LE systemboard.

Thank you!

Kostik's change is now in stable/13 and will be in FreeBSD 13.0. The patch does
not apply (without significant additional work) to stable/12, and a merge there
is not currently planned.

If anyone encounters a similar issue in the future please submit a new PR with
details.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209821] UEFI - installation media hangs when booting on ASUS P6P67 DELUXE

[bugzilla-noreply]

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

--- Comment #57 from Ed Maste  ---
It would be great if someone with an Asus P8P67 can confirm that this now
works.

It was merged to stable/13 in:

commit 1b33aa1f5f99e1270d526ffa5b652250ec80a7ef
Author: Konstantin Belousov 
Date:   Sat Jul 10 22:55:56 2021 +0300

amd64 UEFI loader: stop copying staging area to 2M physical

(cherry picked from commit f75caed644a5c8c342a1ea5e7a6d5251f82ed0b1)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209821] UEFI - installation media hangs when booting on ASUS P6P67 DELUXE

[bugzilla-noreply]

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

--- Comment #56 from rdun...@smallcatbrain.com ---
This works for me... Shuttle XH61V.  This is good work. Thank you!

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209821] UEFI - installation media hangs when booting on ASUS P6P67 DELUXE

[bugzilla-noreply]

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

--- Comment #55 from Mikael Urankar  ---
(In reply to Ed Maste from comment #54)
It works for me on a gigabyte motherboard (it failed to boot prior this work).
Thanks everyone involved.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209821] UEFI - installation media hangs when booting on ASUS P6P67 DELUXE

[bugzilla-noreply]

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

--- Comment #54 from Ed Maste  ---
This issue should be resolved by kib's commit. Anyone who was able to reproduce
this, can you please test with a -CURRENT snapshot (20210930 or later) and
report whether it works for you?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 207677] atrtc Warning: Couldn't map I/O on Skylake Supermicro X11SSH-LN4F

[bugzilla-noreply]

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

Poul-Henning Kamp  changed:

   What|Removed |Added

 CC||p...@freebsd.org

--- Comment #9 from Poul-Henning Kamp  ---
pstef@ ping'ed me on this one.

I have nothing much to add over the comment I put in atrtc_attach() in the
original commit (294643529963), but which has subsequently been lost:

   /*
* Not that we need them or anything, but grab our resources
* so they show up, correctly attributed, in the big picture.
*/

I wanted to make the RTC resources show up in the accounting, for instance
devinfo -rv

For what it is worth, I get the warning also on my laptop (T480):

atrtc0:  port 0x70-0x77 irq 8 on acpi0
atrtc0: Warning: Couldn't map I/O.
atrtc0: registered as a time-of-day clock, resolution 1.00s

I suspect the reason for the message is that acpi0 already claimed some of
those ports:

  acpi0
  Interrupt request lines:
  0x9
  I/O ports:
  […]
  0x70
  0x72-0x77
  […]

I guess, if somebody want to fix this, the ATRTC needs to be picked up through
ACPI rather than PNP ?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 162043] dev.cpu.0.freq is missing [regression]

[bugzilla-noreply]

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

Felix Johnson  changed:

   What|Removed |Added

 Resolution|--- |Unable to Reproduce
 Status|Open|Closed
 CC||felix.the@gmail.com

--- Comment #7 from Felix Johnson  ---
I think the key information is the error returned during device_attach.
A return value of 6 is ENXIO (device not configured).

est0:  on cpu0
est: CPU supports Enhanced Speedstep, but is not recognized.
est: cpu_vendor GenuineIntel, msr 6160f2506000925
device_attach: est0 attach returned 6

The reporter also noted SpeedStep was disabled by the BIOS.

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

[Bug 210412] UEFI boot and console problems on 2008 Mac Pro w/ 10.3-RELEASE

[bugzilla-noreply]

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

--- Comment #3 from maxj...@gmail.com ---
(In reply to maxj.cn from comment #2)
I mean it happens to 11 and 12

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 210412] UEFI boot and console problems on 2008 Mac Pro w/ 10.3-RELEASE

[bugzilla-noreply]

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

maxj...@gmail.com changed:

   What|Removed |Added

 CC||maxj...@gmail.com

--- Comment #2 from maxj...@gmail.com ---
This issue happens to 10 and 11 also.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 184718] bge(4): HP MicroServer N40L, Wake-on-LAN (WoL) packet doesn't wake up the computer

[bugzilla-noreply]

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

Kubilay Kocak  changed:

   What|Removed |Added

   Assignee|am...@freebsd.org   |ko...@freebsd.org
Summary|HP MicroServer N40L, WOL|bge(4): HP MicroServer
   |packet doesn't wake up the  |N40L, Wake-on-LAN (WoL)
   |computer|packet doesn't wake up the
   ||computer
 Status|Open|Closed
 Resolution|--- |DUPLICATE

--- Comment #8 from Kubilay Kocak  ---
^Triage: stable/9 is now EoL. Addressing known Wake-on-Lan issues in bge is
being tracked in bug 218579

*** This bug has been marked as a duplicate of bug 218579 ***

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

[Bug 210671] 'du' may report smaller than expected size(s) when using zfs

[bugzilla-noreply]

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

cornelius.m...@gmail.com changed:

   What|Removed |Added

 CC||cornelius.m...@gmail.com

--- Comment #2 from cornelius.m...@gmail.com ---
I can confirm this behavior on ubuntu 20.04.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209821] UEFI - installation media hangs when booting on ASUS P6P67 DELUXE

[bugzilla-noreply]

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

--- Comment #53 from Graham Perrin  ---
(In reply to Konstantin Belousov from comment #52)

> … https://reviews.freebsd.org/D31121 …

▶


-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209275] Cannot utilize both serial and efi console with UEFI booting

[bugzilla-noreply]

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

Li-Wen Hsu  changed:

   What|Removed |Added

 Status|New |Closed
 Resolution|--- |FIXED

--- Comment #2 from Li-Wen Hsu  ---
This should be fixed, I've tested 13.0 with following settings:

boot_multicons="YES"
boot_serial="YES"
console="comconsole efi"
comconsole_speed="115200"

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209821] UEFI - installation media hangs when booting on ASUS P6P67 DELUXE

[bugzilla-noreply]

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

--- Comment #52 from Konstantin Belousov  ---
Early version of the patch to avoid staging copy is available at
https://reviews.freebsd.org/D31121

You need to have a plan to restore both loader and kernel if you decided to
test and the patch causes problems for you.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 209830] Installkernel fails: ioat.ko: No such file or directory

[bugzilla-noreply]

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

Mark Linimon  changed:

   What|Removed |Added

   Assignee|b...@freebsd.org|lini...@freebsd.org
 Resolution|--- |Overcome By Events
 Status|New |Closed

--- Comment #3 from Mark Linimon  ---
^Triage: close as OBE.

I'm sorry that this PR did not get addressed in a timely fashion.  Please let
us know if this still occurs on a supported OSVERSION.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 211186] Cannot boot mirrored zpool under 11.0 BETA1

[bugzilla-noreply]

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

Mark Linimon  changed:

   What|Removed |Added

   Assignee|b...@freebsd.org|lini...@freebsd.org
 Resolution|--- |Overcome By Events
 Status|New |Closed

--- Comment #11 from Mark Linimon  ---
^Triage: close as OBE.

I'm sorry that this PR did not get addressed in a timely fashion.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 207602] 11.0-RELEASE-p2 doesn't boot with VT-d enabled and vmm in loader.conf for Skylake CPUs

[bugzilla-noreply]

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

Mark Linimon  changed:

   What|Removed |Added

 Resolution|--- |Overcome By Events
 Status|New |Closed
   Assignee|b...@freebsd.org|lini...@freebsd.org

--- Comment #9 from Mark Linimon  ---
^Triage: close as OBE.

I'm sorry that this PR did not get addressed in a timely fashion.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 248659] Specific intel chips lock up with P-states active

[bugzilla-noreply]

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

Mark Linimon  changed:

   What|Removed |Added

   Hardware|Any |amd64
   Keywords||regression
   Assignee|b...@freebsd.org|am...@freebsd.org

--- Comment #33 from Mark Linimon  ---
^Triage: reclassify to see if this gathers more attention this way.

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