[Bug 265980] memstick image defaults to serial console on Asus PRIME Z690-P D4 / i7-12700 system - EFI FW has no ConOut
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265980
--- Comment #8 from Ed Maste ---
Related commit:
commit 14fb9485a4dc9c8212bfae6c2049cb4930f4b8e5
Author: Emmanuel Vadot
Date: Fri Nov 8 20:08:44 2019 +
loader.efi: Default to serial if we don't have a ConOut variable
In the EFI implementation in U-Boot no ConOut efi variable is created,
this cause loader to fallback to TERM_EMU implementation which is very
very very slow (and uses the ConOut device in the system table anyway).
The UEFI spec aren't clear as if this variable needs to exists or not.
Reviewed by:imp, kevans
Notes:
svn path=/head/; revision=354559
diff --git a/stand/efi/loader/main.c b/stand/efi/loader/main.c
index c5d664dce65e..641cc7154f13 100644
--- a/stand/efi/loader/main.c
+++ b/stand/efi/loader/main.c
@@ -703,8 +703,11 @@ parse_uefi_con_out(void)
how = 0;
sz = sizeof(buf);
rv = efi_global_getenv("ConOut", buf, );
- if (rv != EFI_SUCCESS)
+ if (rv != EFI_SUCCESS) {
+ /* If we don't have any ConOut default to serial */
+ how = RB_SERIAL;
goto out;
+ }
ep = buf + sz;
node = (EFI_DEVICE_PATH *)buf;
while ((char *)node < ep) {
--
You are receiving this mail because:
You are the assignee for the bug.
Problem reports for b...@freebsd.org that need special attention
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 |235085 | [PATCH] Option to make rc.d/sysctl more verbose ( New |252123 | fetch(3): Fix wrong usage of proxy when request i Open|177821 | sysctl: Some security.jail nodes are funky, dupli Open|182466 | [headers] [patch] make self-contained Open|183618 | [panic] Dell PowerEdge R620 -- PERC H710 Mini (mf Open|187015 | agpgart: Panic make_dev_credv: bad si_name (error 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 47 problems total for which you should take action.
[Bug 265980] memstick image defaults to serial console on Asus PRIME Z690-P D4 / i7-12700 system - EFI FW has no ConOut
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265980 Ed Maste changed: What|Removed |Added CC||m...@freebsd.org --- Comment #7 from Ed Maste --- Discussed with manu on IRC, suggested path forward is to look for GOP modes and default to serial only in the case that there is no ConOut and the mode list is empty. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 265980] memstick image defaults to serial console on Asus PRIME Z690-P D4 / i7-12700 system - EFI FW has no ConOut
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265980 Ed Maste changed: What|Removed |Added Summary|memstick image defaults to |memstick image defaults to |serial console on Asus |serial console on Asus |PRIME Z690-P D4 / i7-12700 |PRIME Z690-P D4 / i7-12700 |system |system - EFI FW has no ||ConOut -- You are receiving this mail because: You are the assignee for the bug.
[Bug 265980] memstick image defaults to serial console on Asus PRIME Z690-P D4 / i7-12700 system
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265980 --- Comment #6 from Ed Maste --- If I disable the UART in the firmware settings the kernel output is visible on the monitor, but the system hangs after (boot -v): pcib0: allocated type 4 (0x3f8-0x3f8) for rid 0 of uart0 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 265980] memstick image defaults to serial console on Asus PRIME Z690-P D4 / i7-12700 system
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265980 --- Comment #5 from Ed Maste --- # efivar | grep -- -Con | xargs efivar --device-path 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConIn : PciRoot(0x0)/Pci(0x1f,0x0)/Acpi(PNP0303,0x0),/PciRoot(0x0)/Pci(0x14,0x0)/USB(0x5,0x1),/PciRoot(0x0)/Pci(0x14,0x0)/USB(0x8,0x0),/PciRoot(0x0)/Pci(0x14,0x0)/USB(0x8,0x1) 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConInDev : PciRoot(0x0)/Pci(0x1f,0x0)/Acpi(PNP0303,0x0),/PciRoot(0x0)/Pci(0x14,0x0)/USB(0x5,0x1),/PciRoot(0x0)/Pci(0x14,0x0)/USB(0x8,0x0),/PciRoot(0x0)/Pci(0x14,0x0)/USB(0x8,0x1) # -- You are receiving this mail because: You are the assignee for the bug.
[Bug 265980] memstick image defaults to serial console on Asus PRIME Z690-P D4 / i7-12700 system
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265980 --- Comment #4 from Ed Maste --- Similar issue was reported on the mailing list last year: https://lists.freebsd.org/archives/freebsd-stable/2021-October/000249.html -- You are receiving this mail because: You are the assignee for the bug.
[Bug 265980] memstick image defaults to serial console on Asus PRIME Z690-P D4 / i7-12700 system
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265980 --- Comment #3 from Ed Maste --- kenv | grep cons shows: comconsole_pcidev="" comconsole_port="1016" comconsole_speed="9600" console="efi" -- You are receiving this mail because: You are the assignee for the bug.
[Bug 265980] memstick image defaults to serial console on Asus PRIME Z690-P D4 / i7-12700 system
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265980 Ed Maste changed: What|Removed |Added Version|CURRENT |13.1-RELEASE --- Comment #2 from Ed Maste --- FreeBSD-13.1-RELEASE-amd64-memstick.img.xz behaves the same way. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 265980] memstick image defaults to serial console on Asus PRIME Z690-P D4 / i7-12700 system
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265980 --- Comment #1 from Ed Maste --- Also, if I manually run "console=comconsole" from the loader I get a console at 9600 baud, for both the loader and kernel. If I don't interact with the loader at all the serial port has no activity until the kernel starts, and the serial console is at 115200. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 265980] memstick image defaults to serial console on Asus PRIME Z690-P D4 / i7-12700 system
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265980 Bug ID: 265980 Summary: memstick image defaults to serial console on Asus PRIME Z690-P D4 / i7-12700 system Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: misc Assignee: b...@freebsd.org Reporter: ema...@freebsd.org I acquired a Intel i7-12700 and Asus PRIME Z690-P D4 motherboard for P/E core experimentation, and tried installing from a memstick snapshot image FreeBSD-14.0-CURRENT-amd64-20220819-545db925c3d-257513-memstick.img.xz On my first attempt I see the screen blank after the loader, and then a short while later a block cursor appear in the upper left hand corner. Nothing else happens. The port has an onboard COM header but I had no cable. After acquiring one I see that the system defaulted to a primary serial console at 115200. The video console was unresponsive because the serial console was waiting at: Welcome to FreeBSD! Please choose the appropriate terminal type for your system. Common console types are: ansi Standard ANSI terminal vt100VT100 or compatible terminal xtermxterm terminal emulator (or compatible) cons25w cons25w terminal Console type [vt100]: -- You are receiving this mail because: You are the assignee for the bug.
[Bug 265974] SMR has several missing barriers
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265974 --- Comment #2 from Pierre Habouzit --- Created attachment 236040 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=236040=edit proper litmus test -- You are receiving this mail because: You are the assignee for the bug.
[Bug 265974] SMR has several missing barriers
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265974
--- Comment #1 from Pierre Habouzit ---
whoops the `smr_enter-bad.litmus` has a dmb sy that isn't there today, it
should be:
```
AArch64 MP
{
global = 0;
wr_seq = 123;
p1_rd_seq = 0;
0:x0 = global; 0:x1 = wr_seq; 0:x2 = p1_rd_seq;
1:x0 = global; 1:x1 = wr_seq; 1:x2 = p1_rd_seq;
}
P0 | P1 ;
MOV X8, #2| LDRX8, [X1];
STR X8, [X0] |;
LDADDL X8, X9, [X1] | LDADDA X8, X9, [X2];
| LDRX10, [X0] ;
LDR X10, [X2] |;
exists (0:X10 = 0 /\ 1:X8 = 123 /\ 1:X10 = 0)
```
I'll update the tarball
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 265974] SMR has several missing barriers
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265974
Bug ID: 265974
Summary: SMR has several missing barriers
Product: Base System
Version: CURRENT
Hardware: arm64
OS: Any
Status: New
Severity: Affects Many People
Priority: ---
Component: kern
Assignee: b...@freebsd.org
Reporter: pie...@habouzit.net
Created attachment 236039
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=236039=edit
tarball of litmus tests and pdfs
1. smr_enter() ordering is incorrect on arm64 (and probably other weak memory
order systems)
```C
static inline void
smr_enter(smr_t smr)
{
[...]
/* This is an add because we do not have atomic_store_acq_int */
atomic_add_acq_int(>c_seq, smr_shared_current(smr->c_shared));
}
```
the comment here has a point, there's no atomic_store_acq_int because that
would be a StoreLoad barrier which `atomic_add_acq_int` isn't sufficient for.
Here is a litmus test that proves why this code above isn't correct. Let's
assume 2 threads running something akin to this:
start:
global = 0
rd_seq = 123
wr_seq = 123
thread 0:
store(, 2);
smr_synchronize();
thread 1:
smr_enter();
load();
it should NOT be possible for thread 2 to load `0` and for smr_synchronize() to
think thread 1 was not in a critical section pinning `123`
Moreover, smr_poll() absolutely needs a full memory barrier on entry, the
`atomic_load_acq_int` performed by `smr_poll` aren't sufficient.
```
AArch64 MP
{
global = 0;
wr_seq = 123;
p1_rd_seq = 0;
0:x0 = global; 0:x1 = wr_seq; 0:x2 = p1_rd_seq;
1:x0 = global; 1:x1 = wr_seq; 1:x2 = p1_rd_seq;
}
P0 | P1 ;
MOV X8, #2| LDRX8, [X1];
STR X8, [X0] | STRX8, [X2];
LDADDL X8, X9, [X1] | DMBSY ;
DMB SY| LDRX10, [X0] ;
LDR X10, [X2] |;
exists (0:X10 = 0 /\ 1:X8 = 123 /\ 1:X10 = 0)
```
This litmus test above shows that the condition is unfortunately reachable, the
one below passes (adding a full barrier in smr_scan() and adding a full barrier
in smr_enter()):
```
AArch64 MP
{
global = 0;
wr_seq = 123;
p1_rd_seq = 0;
0:x0 = global; 0:x1 = wr_seq; 0:x2 = p1_rd_seq;
1:x0 = global; 1:x1 = wr_seq; 1:x2 = p1_rd_seq;
}
P0 | P1 ;
MOV X8, #2| LDRX8, [X1];
STR X8, [X0] | STRX8, [X2];
LDADDL X8, X9, [X1] | DMBSY ;
DMB SY| LDRX10, [X0] ;
LDR X10, [X2] |;
exists (0:X10 = 0 /\ 1:X8 = 123 /\ 1:X10 = 0)
```
Note that I think the code works on Intel today.
2. similarly smr_poll_scan() needs a full barrier after the scan _before_ it
updates the global rd_seq, this is about serializing the fast path of smr_poll
with CPUs that weren't in a critical section (while the one on entry of
smr_poll() is about synchronizing with the CPUs inside an active SMR critical
section and was demonstrated in (1)).
I confess that litmus test is much more painful to write and is left as an
exercise to the reader ;)
3. smr_deferred_advance() is similarly incorrect as it doesn't guarantee proper
visibility in this case:
start:
global = 0
rd_seq = 123
wr_seq = 123
thread 0:
store(, 2);
smr_deferred_advance(); // returns 125 but didn't update wr_seq
thread 1:
smr_synchronize(); // 123 -> 125
load();
We should never hit a case when thread1 didn't observe the global being 2 but
thread 1 returned 125.
Here is a modelization of this sequence with the added `dmb sy` from (1) in
smr_poll:
```
AArch64 MP
{
global = 0;
wr_seq = 123;
0:x0 = global; 0:x1 = wr_seq; 0:x2 = 2;
1:x0 = global; 1:x1 = wr_seq; 1:x2 = 2;
}
P0 | P1 ;
STR X2, [X0] | LDADDL X2, X9, [X1];
| DMBSY ;
LDR X9, [X1] | LDRX10, [X0] ;
ADD X9, X9, X2|;
exists (0:X9 = 125 /\ 1:X9 = 123 /\ 1:X10 = 0)
```
this unfortunately tells us that the condition is reachable, and intuitively it
makes sense because there's nothing in "P0" ordering anything. The fix is that
when a deferred advance is made, a full barrier must be issued (it has to be a
StoreLoad between the store to the global and the load of the write sequence),
and indeed this litmus test passes:
```
AArch64 MP
{
global = 0;
wr_seq = 123;
0:x0 = global; 0:x1 = wr_seq; 0:x2 = 2;
1:x0 = global; 1:x1 = wr_seq; 1:x2 = 2;
}
P0 | P1 ;
STR X2, [X0] | LDADDL X2, X9, [X1];
DMB SY| DMBSY
[Bug 263478] awk: syntax error in regular expression $^
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263478 pproca...@gmail.com changed: What|Removed |Added CC||pproca...@gmail.com --- Comment #1 from pproca...@gmail.com --- The syntax you provided is syntactically correct, however the result of such a match is undefined. An argument could be made that '$^' should parse without error, to which I actually agree as that follows the grammar as posted by you, but I don't see how '$^' is useful. If it's working elsewhere, it's working within that 'undefined behavior' realm which could change the moment POSIX actually defines $^ as having an actual meaning. As of right now, it doesn't. Perhaps you could say, it means 'end of line' then 'newline' but that doesn't really make sense because you could anchor on either just a newline or end of line. Those are my thoughts anyways. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 243299] fetch(1) fails to handle redirects on a valid URL
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243299 pproca...@gmail.com changed: What|Removed |Added Attachment #236031|0 |1 is obsolete|| --- Comment #3 from pproca...@gmail.com --- Created attachment 236032 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=236032=edit Updated patch to support redirected relative urls to fetch. Just added the check to the return of the function Hey it's 3am ... sheesh! -- You are receiving this mail because: You are the assignee for the bug.
[Bug 243299] fetch(1) fails to handle redirects on a valid URL
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243299 pproca...@gmail.com changed: What|Removed |Added CC||pproca...@gmail.com --- Comment #2 from pproca...@gmail.com --- Created attachment 236031 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=236031=edit Add support for relative urls in redirect responses RFC 7231 has support for relative urls. I saw this bug report and had to check. I didn't believe it. The attach patch fixes the op's issue, but truly it needs to be tested with all kinds of responses. Additionally, I program in C in a much much different way than the source file's layout. Safe to apply, sure, but it'd be wise for someone else to give it a once over to ensure it conforms to your standards; something someone else can do if they so choose. -- You are receiving this mail because: You are the assignee for the bug.
