Re: boot loader blank screen

[Johan Hendriks]

On 16/01/2021 21:15, Alan Somers wrote:

On Sat, Jan 16, 2021 at 8:39 AM John Kennedy  wrote:


On Fri, Jan 15, 2021 at 03:51:38PM +0200, Toomas Soome wrote:

Could you please check latest current now?:)

   Success!  With main-c255999-g0bc776f3da70, I've been able to comment out
the
screen.textmode=0 (so, back to the default like I originally was).

I needed to set vbe_max_resolution="800x600" to get the non text version 
of the boot loader.

___
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: boot loader blank screen

[Alan Somers]

On Mon, Jan 18, 2021 at 7:16 AM Johan Hendriks 
wrote:

>
> On 16/01/2021 21:15, Alan Somers wrote:
> > On Sat, Jan 16, 2021 at 8:39 AM John Kennedy  wrote:
> >
> >> On Fri, Jan 15, 2021 at 03:51:38PM +0200, Toomas Soome wrote:
> >>> Could you please check latest current now?:)
> >>Success!  With main-c255999-g0bc776f3da70, I've been able to comment
> out
> >> the
> >> screen.textmode=0 (so, back to the default like I originally was).
> >>
> I needed to set vbe_max_resolution="800x600" to get the non text version
> of the boot loader.
>

Oh, I see.  "hw.vga.textmode" got renamed to "screen.textmode".  And it
works both ways now.  No need to set vbe_max_resolution.
-Alan
___
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"

bus_dmamem_alloc failed to align memory properly

[Steve Kargl]

I've used a SCHED_BSD for a long time on my i586-*-freebsd
laptop.  Recently, FreeBSD just locks up on this system.  No
panic.  No screen.  No keyboard. Nothing.  So, yesterday, while
trying to deal with the blank console problem, I switch to
SCHED_ULE to see if solved this lock-up issue.  It doesn't. :-(

I now have a number of messages during boot.

% dmesg | grep align
bus_dmamem_alloc failed to align memory properly.
bus_dmamem_alloc failed to align memory properly.
bus_dmamem_alloc failed to align memory properly.
bus_dmamem_alloc failed to align memory properly.
bus_dmamem_alloc failed to align memory properly.

I never seen these messages, so is this normal for SCHED_ULE.

In addition, to the mystrey lock-up.  It now seems that
wpa_supplicant is broken.  The initial instances, started
at boot, is using 100% CPU.  I need to kill that instance
along with openvpn (which of course needs the network).
The D-Link cardbud ath NIC is ejected, re-insert it, and
the network start up as normal.

-- 
Steve
___
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"

shutting down jails gives Lost 1 pages of memory error on console.

[Johan Hendriks]

I have just update my system to FreeBSD srv-01.thuis.local 13.0-ALPHA1 
FreeBSD 13.0-ALPHA1 #28 main-c256051-g7c7c231c1424: Mon Jan 18 14:12:01 
CET 2021 root@srv-01.thuis.local:/usr/obj/usr/src/amd64.amd64/sys/KRNL amd64


Now when i shutdown a jail i see the following appear on the console.

Stopping jails: haproxy Freed UMA keg (rtentry) was not empty (1 items). 
Lost 1 pages of memory.


regards,
Johan


___
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: bus_dmamem_alloc failed to align memory properly

[Hans Petter Selasky]

On 1/18/21 6:51 PM, Steve Kargl wrote:

I've used a SCHED_BSD for a long time on my i586-*-freebsd
laptop.  Recently, FreeBSD just locks up on this system.  No
panic.  No screen.  No keyboard. Nothing.  So, yesterday, while
trying to deal with the blank console problem, I switch to
SCHED_ULE to see if solved this lock-up issue.  It doesn't. :-(

I now have a number of messages during boot.

% dmesg | grep align
bus_dmamem_alloc failed to align memory properly.
bus_dmamem_alloc failed to align memory properly.
bus_dmamem_alloc failed to align memory properly.
bus_dmamem_alloc failed to align memory properly.
bus_dmamem_alloc failed to align memory properly.

I never seen these messages, so is this normal for SCHED_ULE.

In addition, to the mystrey lock-up.  It now seems that
wpa_supplicant is broken.  The initial instances, started
at boot, is using 100% CPU.  I need to kill that instance
along with openvpn (which of course needs the network).
The D-Link cardbud ath NIC is ejected, re-insert it, and
the network start up as normal.



Hi,

This appears to be a known issue.

I think kib@ is working on it.

--HPS
___
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: Silent hang in buildworld, was Re: Invoking -v for clang during buildworld

[Mark Millard]

On 2021-Jan-17, at 19:19, Mark Millard  wrote:

> On 2021-Jan-17, at 17:50, bob prohaska  wrote:
> 
>> On Sun, Jan 17, 2021 at 12:30:51PM -0800, Mark Millard wrote:
>>> 
>>> 
>>> On 2021-Jan-17, at 09:40, bob prohaska  wrote:
>>> 
 On Sat, Jan 16, 2021 at 03:04:04PM -0800, Mark Millard wrote:
> 
> Other than -j1 style builds (or equivalent), one pretty much
> always needs to go looking around for a non-panic failure. It
> is uncommon for all the material to be together in the build
> log in such contexts.
 
 Running make cleandir twice and restarting -j4 buildworld brought
 the process full circle: A silent hang, no debugger response, no
 console warnings. That's what sent me down the rabbit hole of make
 without clean, which worked at least once...
>>> 
>>> Unfortunately, such a hang tends to mean that log files and such
>>> were not completely written out to media. We do not get to see
>>> evidence of the actual failure time frame, just somewhat before.
>>> (compiler/linker output and such can have the same issues of
>>> ending up with incomplete updates.)
>>> 
>>> So, pretty much my notes are unlikely to be strongly tied to
>>> any solid evidence: more like alternatives to possibly explore
>>> that could be far off the mark.
>>> 
>>> It is not clear if you were using:
>>> 
>>> LDFLAGS.lld+= -Wl,--threads=1
>>> 
>>> or some such to limit the multi-thread linking and its memory.
>> No, I wasn't trying to limit ld.lld thread number.
> 
> You might want to try a significant change in the memory use
> just to see if it makes a difference or not --despite the
> extra time. This could included limiting lld thread usage
> and limiting to a smaller -jN .
> 
>>> I'll note that if -j4 gets 4 links running in parallel it used
>>> to be each could have something like 5 threads active on a 4
>>> core machine, so 20 or so threads. (I've not checked llvm11's
>>> lld behavior. It might avoid such for defaults.)
>>> 
>>> You have not reported any testing of -j2 or -j3 so far, just
>>> -j4 . (Another way of limiting memory use, power use, temperature,
>>> etc. .)
>>> 
>> Not recently, simply because it's so slow to build. On my "production"
>> armv7 machines running stable/12 I do use -j2. But, they get updated
>> only a couple times per year, when there's a security issue. 
> 
> See the earlier note about possibly deliberate test of
> using less memory space. (And more later, below.)
> 
>>> You have not reported if your boot complained about the swap
>>> space size or if you have adjusted related settings to make
>>> non-default tradeoffs for swap amanagment for these specific
>>> tests. I recommend not tailoring and using a swap size total
>>> that is somewhat under what starts to complain when there is
>>> no tailoring.
>>> 
>> Both Pi2 and Pi3 have been complaining about too much swap
>> since I first got them. Near as can be told it's never been
>> a demonstrated problem, thus far. Now, as things like LLVM
>> get bigger and bigger, it seems possible excess swap might
>> cause, or obscure, other problems. For the Pi2 I picked 2
>> GB from the old "2x physical RAM" rule. 
> 
> I'd take those warnings as FreeSD reporting that the system is
> expected to be in a mistuned configuration by "normal" criteria.
> Doing the tuning to allow more swap has the documented tradeoffs:
> 
>  kern.maxswzone
> . . .
> 
>Note that swap metadata can be fragmented, which means that
>the system can run out of space before it reaches the
>theoretical limit.  Therefore, care should be taken to not
>configure more swap than approximately half of the
>theoretical maximum.
> 
> (The above is what the warning is about. But then there is . . .)
> 
>Running out of space for swap metadata can leave the system
>in an unrecoverable state.  Therefore, you should only
>change this parameter if you need to greatly extend the KVM
>reservation for other resources such as the buffer cache or
>kern.ipc.nmbclusters.  Modifies kernel option
>VM_SWZONE_SIZE_MAX.
> 
> (NOTE: That last paragraph is talking about *decreasing* kern.maxswzone
> to get more room for non-swap-managment things in KVM. [Too bad the
> wording says "change".] But increasing kern.maxswzone to allow more swap
> leaves less space for the buffer cache or like, making for tradeoffs
> being involved.)

FYI: I re-established my access to a RPi2B V1.1 and made
it report: "maximum recommended amount (468832 pages)"

(The figure can vary some from release to release.)

468832*4096 == 1920335872 or a little over 1831 MiBytes

For the 4096 Byte pages, that means that the following from
gpart fits without complaint (size is in blocks, not pages):

  4131409923686400  da0p2  freebsd-swap  (1.8G)

3686400*512 is a little over 1.75 GiByte or 1800 MiByte. So
I've left some room below 

Re: boot loader blank screen

[Toomas Soome]

> On 18. Jan 2021, at 19:27, Alan Somers  wrote:
> 
> On Mon, Jan 18, 2021 at 7:16 AM Johan Hendriks  >
> wrote:
> 
>> 
>> On 16/01/2021 21:15, Alan Somers wrote:
>>> On Sat, Jan 16, 2021 at 8:39 AM John Kennedy  wrote:
>>> 
 On Fri, Jan 15, 2021 at 03:51:38PM +0200, Toomas Soome wrote:
> Could you please check latest current now?:)
   Success!  With main-c255999-g0bc776f3da70, I've been able to comment
>> out
 the
 screen.textmode=0 (so, back to the default like I originally was).
 
>> I needed to set vbe_max_resolution="800x600" to get the non text version
>> of the boot loader.
>> 
> 
> Oh, I see.  "hw.vga.textmode" got renamed to "screen.textmode".  And it
> works both ways now.  No need to set vbe_max_resolution.
> -Alan

That is good. and btw, hw.vga.textmode is still there, it is doing what it has 
been done before — controlling VGA gfx or text mode when you are starting 
kernel with text mode.

rgds,
toomas


___
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: Silent hang in buildworld, was Re: Invoking -v for clang during buildworld

[Mark Millard]

> . . .
> FYI: I re-established my access to a RPi2B V1.1 and made
> it report: "maximum recommended amount (468832 pages)"
> 
> (The figure can vary some from release to release.)
> 
> 468832*4096 == 1920335872 or a little over 1831 MiBytes
> 
> For the 4096 Byte pages, that means that the following from
> gpart fits without complaint (size is in blocks, not pages):
> 
>  4131409923686400  da0p2  freebsd-swap  (1.8G)
> 
> 3686400*512 is a little over 1.75 GiByte or 1800 MiByte. So
> I've left some room below 1831 MiBytes, but not a lot.
> 
> FYI about my build experiment that is running:
> 
> # sysctl hw.physmem
> hw.physmem: 979042304
> 
> which, in recent times for armv7, I can (and did) set in
> /boot/loader.conf on a faster cortex-A7 SBC (that can boot
> the same media but has more RAM).
> 
> So I tried a -j4 build, but with LDFLAGS.lld+= -Wl,--threads=1
> in use and my other particular src.conf/make.conf like content
> (so the builds do likely differ from yours in various ways).
> My build is producing a non-debug build (but with -g symbols).
> Somewhat after where your buildworld.log stops, my odd variant
> of top was reporting:
> 
> Mem:  . . . , 753672Ki MaxObsActive, 200412Ki MaxObsWired, 892732Ki 
> MaxObs(Act+Wir)
> Swap: . . . , 145832Ki MaxObsUsed
> 
> and top was also showing lots of processes as having "0B" RES
> in STATE "wait" or "nanslp" (so, apparently swapped out, not paging).
> ("MaxObs" is short for "maximum observed".)
> 
> For comparison, your swapscript.log reported a maximum total of
> 346192 KiBytes "Used" for swap, about 98% into the log file.
> 
> (Time goes by . . .)
> 
> It finished with building libllvm and is part way into building
> libclang. This is probably well past where your hangup happened,
> given that your published buildworldlog file stopped with
> libllvm's Target/ARM/ARMMCInstLower.o . My odd top now shows:
> 
> Mem:  . . . , 753672Ki MaxObsActive, 200412Ki MaxObsWired, 892732Ki 
> MaxObs(Act+Wir)
> Swap: . . . , 392328Ki MaxObsUsed
> 
> The build continues to run. I'll let you know how it goes.
> . . .

Just after libclang finished my odd top showed:

Mem:  . . . , 753672Ki MaxObsActive, 200412Ki MaxObsWired, 892736Ki 
MaxObs(Act+Wir)
Swap: . . . , 537588Ki MaxObsUsed

After liblldb:

Mem:  . . . , 753672Ki MaxObsActive, 200412Ki MaxObsWired, 899276Ki 
MaxObs(Act+Wir)
Swap: . . . , 537588Ki MaxObsUsed

Much later, after the lldb program had been built:

Mem:  . . . , 765700Ki MaxObsActive, 200412Ki MaxObsWired, 954116Ki 
MaxObs(Act+Wir)
Swap: . . . , 537588Ki MaxObsUsed

>>> World build completed on Mon Jan 18 19:10:08 PST 2021
>>> World built in 72960 seconds, ncpu: 4, make -j4

This was building from scratch what was already installed:

# ~/fbsd-based-on-what-freebsd-main.sh 
merge-base: 818390ce0ca539300dd15d7a817784f1e3f7a9b8
merge-base: CommitDate: 2021-01-13 21:27:44 +
4180404713ec (HEAD -> mm-src) mm-src snapshot for mm's patched build in git 
context.
818390ce0ca5 (freebsd/main, freebsd/HEAD, pure-src, main) arm64: fix early 
devmap assertion
FreeBSD OPiP2E_RPi2v11 13.0-CURRENT FreeBSD 13.0-CURRENT 
mm-src-c255938-g4180404713ec GENERIC-NODBG  arm armv7 1300135 1300135

This suggests that you should be able to build on the RPi2B v1.1,
using -j4, with appropriate configuration for what and how to build.


It is now building the matching kernel, my GENERIC-NODBG style.



===
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"