Failure of release build with release.sh on 14-CURRENT amd64

[Yasuhiro Kimura]

Hello,

I tried release build with /usr/src/release/release.sh on 14-CURRENT
amd64 under followin conditions.

* 14-CURRENT amd64
* f17fc5439f5 + revert of 84eaf2ccc6a (Workaroud of the problem
  reported as bug 253087 on Bugzilla)
* No release.conf, everithing is default
* /scratch is empty when build starts
* /scratch/usr/doc is ba0831043d of main
* /scratch/usr/ports is r563439 of head
* /scratch/usr/src is 151ec796a23 of main
* devel/git is installed but devel/subversion isn't

And the result is failure with following error messages.

--
cd /usr/doc/en_US.ISO8859-1/htdocs/releases/14.0R &&  env 
MAN4DIR=/usr/src/release/../share/man/man4  _BRANCH=CURRENT  make all install 
clean "FORMATS=html txt"  INSTALL_COMPRESSED='' URLS_ABSOLUTE=YES 
DOCDIR=/usr/obj/usr/src/amd64.amd64/
release/rdoc  WEBDIR=/usr/doc DESTDIR=/usr/obj/usr/src/amd64.amd64/release/rdoc
cd: /usr/doc/en_US.ISO8859-1/htdocs/releases/14.0R: No such file or directory
*** Error code 2

Stop.
make[1]: stopped in /usr/src/release
*** Error code 1

Stop.
make: stopped in /usr/src/release
--

Full buld log is

https://www.utahime.org/FreeBSD/release.sh.2021-01-31-09-10-35.log

(Caution: Size of the file is about 75MB)

Does this mean that release.sh is simply broken right now or I did
something wrong?

Best Regards.

---
Yasuhiro Kimura
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: UEFI boot hangs after loading kernel with efi_max_resolution="4k"

[Xin Li via freebsd-current]

With Toomas's help (thanks!), I was able to partially resolve the hang
and blank screen at boot issue, for the record, for now this can be
solved by adding:

screen.font="16x32"

in /boot/loader.conf; no more efi_max_resolution setting is needed.

Setting allscreen_flags to load font still panics the system, but at
least the screen is now in a readable state, and kernel loads fine.
I'll update this thread if I found something new.

Cheers,
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Best way to submit patches for -current

[Graham Perrin]

Answered at 
 
with reference to Phabricator at 

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

gcc bootstrap or such outdated references in src.conf and make.conf for 13 and 14

[Mark Millard via freebsd-current]

QUOTE from man src.conf :
 To be able to build the system, either gcc
 or clang bootstrap must be enabled unless an alternate compiler
 is provided via XCC.
END QUOTE

QUOTE from man src.conf :
The CCACHE_COMPILERCHECK
 option defaults to content when using the in-tree bootstrap
 compiler, and mtime when using an external compiler.  The
 CCACHE_CPP2 option is used for Clang but not GCC.
END QUOTE

With clang/clang++ 11's change to what -O means, I'm not sure about
the following from man make.conf :

QUOTE from man make.conf
 CFLAGS(str) Controls the compiler setting when compiling C code.
   Optimization levels other than -O and -O2 are not
   supported.
END QUOTE

Same here:

QUOTE from man make.conf
 COPTFLAGS (str) Controls the compiler settings when building the
   kernel.  Optimization levels above [-O (-O2, ...)] are not
   guaranteed to work.
END QUOTE


Context man outputs are from:

# ~/fbsd-based-on-what-freebsd-main.sh 
merge-base: 3f43ada98c89bce5ae416e203ba0e81595a5cd88
merge-base: CommitDate: 2021-01-29 19:46:24 +
e124d7d5fc88 (HEAD -> mm-src) mm-src snapshot for mm's patched build in git 
context.
3f43ada98c89 (freebsd/main, freebsd/HEAD, pure-src, main) Catch up with 
6edfd179c86: mechanically rename IFCAP_NOMAP to IFCAP_MEXTPG.
FreeBSD FBSDFHUGE 14.0-CURRENT FreeBSD 14.0-CURRENT mm-src-n244523-e124d7d5fc88 
GENERIC-NODBG  amd64 amd64 143 143


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

trying to make release with git-derived 14-current

[tech-lists]

Hi,

I'm trying to make release with -current on a rpi4b/8GB. Basically, I
have a working rpi4B/8GB with a no-debug kernel running -current.
However, release(7) says a lot about svn and nothing about git.

What's the method with git?

thanks,
--
J.


signature.asc
Description: PGP signature

Re: (n244517-f17fc5439f5) svn stuck forever in /usr/ports?

[Guido Falsi via freebsd-current]

On 30/01/21 12:34, Guido Falsi via freebsd-current wrote:

On 30/01/21 11:25, Tomoaki AOKI wrote:

On Sat, 30 Jan 2021 07:39:23 +0100
"Hartmann, O."  wrote:

We recently updated to FreeBSD 14.0-CURRENT #9 
main-n244517-f17fc5439f5: Fri Jan 29
16:29:50 CET 2021  amd64. After make delete-oldfiles/delete-old-libs, 
the command


make update

issued in /usr/ports on those 14-CURRENT boxes remains stuck forever 
or it is working

like a snail!
Hitting Ctrl-t on the console gives:

load: 0.06  cmd: svn 96552 [kqread] 2530.57r 270.92u 5.68s 10% 10584k
mi_switch+0xbe sleepq_catch_signals+0x324 sleepq_timedwait_sig+0x12 
_sleep+0x188
kqueue_kevent+0x2d0 kern_kevent_fp+0x51 kern_kevent_generic+0xdd 
sys_kevent+0x61
amd64_syscall+0x10c fast_syscall_common+0xf8 make: Working in: 
/usr/ports



The system is idle otherwise.

How can this be resolved? Is this phenomenon known?

Kind regards and thank you very much in advance,

O. Hartmann



+1.
IIRC, d6327ae8c11b was OK, but ebc61c86b556 is not.

Unfortunately, I currently don't have enough time to bisect
further. :-(


I'm running 07d218f70c2f and it is affected, this restricts the range 
slightly more.




I tried bisecting the kernel only between d6327ae8c11b and 07d218f70c2f, 
but got no results.


Looks like the problem is not in the kernel but somewhere else (libc? ssl?)

Bisecting the whole system is going to take longer. I'll try to find the 
time.


--
Guido Falsi 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: (n244517-f17fc5439f5) svn stuck forever in /usr/ports?

[Guido Falsi via freebsd-current]

On 30/01/21 11:25, Tomoaki AOKI wrote:

On Sat, 30 Jan 2021 07:39:23 +0100
"Hartmann, O."  wrote:


We recently updated to FreeBSD 14.0-CURRENT #9 main-n244517-f17fc5439f5: Fri 
Jan 29
16:29:50 CET 2021  amd64. After make delete-oldfiles/delete-old-libs, the 
command

make update

issued in /usr/ports on those 14-CURRENT boxes remains stuck forever or it is 
working
like a snail!
Hitting Ctrl-t on the console gives:

load: 0.06  cmd: svn 96552 [kqread] 2530.57r 270.92u 5.68s 10% 10584k
mi_switch+0xbe sleepq_catch_signals+0x324 sleepq_timedwait_sig+0x12 _sleep+0x188
kqueue_kevent+0x2d0 kern_kevent_fp+0x51 kern_kevent_generic+0xdd sys_kevent+0x61
amd64_syscall+0x10c fast_syscall_common+0xf8 make: Working in: /usr/ports


The system is idle otherwise.

How can this be resolved? Is this phenomenon known?

Kind regards and thank you very much in advance,

O. Hartmann



+1.
IIRC, d6327ae8c11b was OK, but ebc61c86b556 is not.

Unfortunately, I currently don't have enough time to bisect
further. :-(


I'm running 07d218f70c2f and it is affected, this restricts the range 
slightly more.


--
Guido Falsi 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: zpool upgrade to draid feature: does it require updated zfs boot code ?

[Kurt Jaeger]

Hi!

> > Short question:
> > Does a zpool upgrade on 14.0 (current) for the draid feature
> > require a boot code update ?

> > Long version of the same question:
> > With the draid update, no message was displayed.
> > 
> > Does it require the bootcode update anyway or, if not, why not ?
> 
> This sounded like a bug.  Is it your boot pool, or just a regular data pool?

Its my boot pool.

> >  gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 nvd0
> >  gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 nvd1
> 
> To answer your short question: do I need to update bootcode?  No if
> draid is the only feature that you have enabled on an existing pool, but
> personally I don't recommend upgrading boot pool right now.

The boot pool shows:

zroot  feature@draid  enabledlocal

> The reason for that "No" answer is 1) the boot code do not currently
> support draid, and 2) enabling the feature won't activate it until draid
> vdev is added to the pool, which is quite unlikely in your case; note
> that if you do add draid vdev, your bootcode won't be able to boot from
> it anymore.

Ok.

-- 
p...@opsec.eu+49 171 3101372Now what ?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Fwd: Best way to submit patches for -current

[Graham Perrin]

 Forwarded Message 
Subject:Best way to submit patches for -current
Date:   Fri, 29 Jan 2021 13:48:21 +0100
From:   Marc Veldman 
To: freebsd-hack...@freebsd.org



Hello,

now that FreeBSD has moved to Git, what is the recommended way to 
provide patches?

A GitHub or GitLab Merge Request against the FreeBSD main branch?
Or a (set of) patches generated with git format-patch, the output of 
gitt diff

Or any other way?

Best regards,

Marc
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

drm-fbsd13-kmod and drm-current-kmod package descriptions

[Graham Perrin]

On 29/01/2021 10:05, Emmanuel Vadot wrote:

On Fri, 29 Jan 2021 04:59:27 -0500
monochrome  wrote:


correct me if I'm wrong, but shouldn't it say:

Currently corresponding to Linux 5.4.62 DRM.

instead of:

Currently corresponding to Linux 4.16 DRM.

got caught by this while trying to update drm-devel-kmod from ports on
stable/13, and took a chance that it was just an oversight :)

  Indeed, just fixed this.

  Thanks,


Also:

253092 – graphics/drm-current-kmod and graphics/drm-fbsd13-kmod package 
messages are wrong



___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: (n244517-f17fc5439f5) svn stuck forever in /usr/ports?

[Tomoaki AOKI]

On Sat, 30 Jan 2021 07:39:23 +0100
"Hartmann, O."  wrote:

> We recently updated to FreeBSD 14.0-CURRENT #9 main-n244517-f17fc5439f5: Fri 
> Jan 29
> 16:29:50 CET 2021  amd64. After make delete-oldfiles/delete-old-libs, the 
> command 
> 
> make update
> 
> issued in /usr/ports on those 14-CURRENT boxes remains stuck forever or it is 
> working
> like a snail!
> Hitting Ctrl-t on the console gives:
> 
> load: 0.06  cmd: svn 96552 [kqread] 2530.57r 270.92u 5.68s 10% 10584k
> mi_switch+0xbe sleepq_catch_signals+0x324 sleepq_timedwait_sig+0x12 
> _sleep+0x188
> kqueue_kevent+0x2d0 kern_kevent_fp+0x51 kern_kevent_generic+0xdd 
> sys_kevent+0x61
> amd64_syscall+0x10c fast_syscall_common+0xf8 make: Working in: /usr/ports
> 
> 
> The system is idle otherwise.
> 
> How can this be resolved? Is this phenomenon known?
> 
> Kind regards and thank you very much in advance,
> 
> O. Hartmann
> 

+1.
IIRC, d6327ae8c11b was OK, but ebc61c86b556 is not.

Unfortunately, I currently don't have enough time to bisect
further. :-( 

As stable/13 is OK via https at 76dd854f47f4, so it wouldn't be
a server-side problem.

Regards.

-- 
Tomoaki AOKI
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

UEFI boot hangs after loading kernel with efi_max_resolution="4k"

[Xin Li via freebsd-current]

Hi,

It seems that some recent change after 282381aa53a would prevent my
laptop (Lenovo P51, with 4k LCD) from booting.

I have made some attempt to find out why, so far, it seems that setting
efi_max_resolution="480p" or efi_max_resolution="720p" would allow it to
boot to single user mode.

Unfortunately, with KMS modules loaded, the screen would enter high
resolution mode, and the screen output would be garbled.  To make the
situation worse, because I have the following configuration set in
/etc/rc.conf:

allscreens_flags="-f /usr/share/vt/fonts/terminus-b32.fnt"

the kernel would panic shortly after loading the font:

===
Unread portion of the kernel message buffer:
<118>Configuring vt: blanktime allscreens
panic: free: address 0x81c6ee00(0x81c6e000) has not been
allocated.

cpuid = 3
time = 1611996927
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe0141dbc490
vpanic() at vpanic+0x181/frame 0xfe0141dbc4e0
panic() at panic+0x43/frame 0xfe0141dbc540
free() at free+0xf8/frame 0xfe0141dbc570
vt_change_font() at vt_change_font+0x16f/frame 0xfe0141dbc5c0
vtterm_ioctl() at vtterm_ioctl+0xef6/frame 0xfe0141dbc610
termtty_ioctl() at termtty_ioctl+0xc3/frame 0xfe0141dbc660
tty_ioctl() at tty_ioctl+0x8e/frame 0xfe0141dbc6b0
ttydev_ioctl() at ttydev_ioctl+0x247/frame 0xfe0141dbc700
devfs_ioctl() at devfs_ioctl+0xcb/frame 0xfe0141dbc750
vn_ioctl() at vn_ioctl+0x131/frame 0xfe0141dbc860
devfs_ioctl_f() at devfs_ioctl_f+0x1e/frame 0xfe0141dbc880
kern_ioctl() at kern_ioctl+0x289/frame 0xfe0141dbc8f0
sys_ioctl() at sys_ioctl+0x12a/frame 0xfe0141dbc9c0
amd64_syscall() at amd64_syscall+0x12e/frame 0xfe0141dbcaf0
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe0141dbcaf0
--- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x80038bc9a, rsp =
0x7fffe938, rbp = 0x7fffebf0 ---
Uptime: 28s
Dumping 1421 out of 32433
MB:..2%..11%..21%..31%..41%..51%..61%..71%..82%..91%


I thought the panic was fixed (bug 252833), but it's probably a
different corner case, which can happen when loader/EFI provided
resolution is different from the current KMS-enabled resolution (haven't
took a closer look yet).

But it's still unclear to me why the screen would go blank when
efi_max_resolution is set to "4k" or unset.  I thought it's probably
panicked somewhere, but it's hard to confirm as I don't have a serial
console with this laptop.

If I replace the loader taken from the 20201231 snapshot (from
282381aa53a), then the laptop would boot just fine.

In summary, what I know so far was:

Old loader: everything would work just fine.

New loader:

efi_max_resolution="4k" in /boot/loader.conf:
Screen goes blank after "boot" in loader prompt

No efi_max_resolution in /boot/loader.conf:
'show' gives me efi_max_resolution="1x1" and screen goes blank after
"boot" in loader prompt

efi_max_resolution="720p" or 480p in /boot/loader.conf:
Kernel boots fine up to single user mode.
Panic immediately when loading font.

Any suggestion on what this could be?  It's hard to debug boot loader
issues on this laptop as I don't have an usable serial console and blank
screen would make me blind :)

Cheers,
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: (n244517-f17fc5439f5) svn stuck forever in /usr/ports?

[Guido Falsi via freebsd-current]

On 30/01/21 07:39, Hartmann, O. wrote:

We recently updated to FreeBSD 14.0-CURRENT #9 main-n244517-f17fc5439f5: Fri 
Jan 29
16:29:50 CET 2021  amd64. After make delete-oldfiles/delete-old-libs, the 
command

make update

issued in /usr/ports on those 14-CURRENT boxes remains stuck forever or it is 
working
like a snail!
Hitting Ctrl-t on the console gives:

load: 0.06  cmd: svn 96552 [kqread] 2530.57r 270.92u 5.68s 10% 10584k
mi_switch+0xbe sleepq_catch_signals+0x324 sleepq_timedwait_sig+0x12 _sleep+0x188
kqueue_kevent+0x2d0 kern_kevent_fp+0x51 kern_kevent_generic+0xdd sys_kevent+0x61
amd64_syscall+0x10c fast_syscall_common+0xf8 make: Working in: /usr/ports


The system is idle otherwise.

How can this be resolved? Is this phenomenon known?


I'm seeing similar behaviour. Switching to the svn:// scheme was a 
successful workaround.


--
Guido Falsi 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"