Git: timestamps

[Graham Perrin]

On 06/01/2021 02:32, Jamie Landeg-Jones wrote:


> Re: git non-time-sequential logs


Warner Losh  wrote:


Not having timestamps on files cloned or viewed in cgit.freebsd.org is a
nightmare too.


I just clicked through and saw several time stamps quite trivially. Could
you be more specific in your complaint?

Warner

I wasn't really complaining - If the git transition is better for you guys, I'm 
all for it.

However, this is one such URL: https://cgit.freebsd.org/src/tree/usr.bin/diff

Those files have no dates besides them on my screen..

Cheers, Jamie



Alongside 'tree', click 'log'

Also/alternatively there's the read-only mirror on GitHub so, for example:



– although time stamps there are relative, not absolute.

___
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

[Mark Millard]

On 2021-Jan-5, at 17:54, David Wolfskill  wrote:

> On Wed, Jan 06, 2021 at 12:46:08AM +0200, Toomas Soome wrote:
>> ... 
>>> the 58661b3ba9eb should hopefully fix the loader text mode issue, it would 
>>> be cool if you can verify:)
>>> 
>>> thanks,
>>> toomas
>> 
>> I think, I got it fixed (at least idwer did confirm for his system, thanks). 
>> If you can test this patch: 
>> http://148-52-235-80.sta.estpak.ee/0001-loader-rewrite-font-install.patch 
>>  
>> it would be really nice.
>> 
>> thanks,
>> toomas
> 
> I tested with each of the following "stanzas' in /boot/loader.conf,
> using vt (vs. syscons) in each case (though that breaks video reset
> on resume after suspend):
> 
> . . .

I've done no experiments with an explicit vbe_max_resolution
setting. My context for hw.vga.textmode="0" shows up as
1920x1200. (I do have the font for this set to 8x16, making
for lots of character cells across and down.)


For the below I do not have hw.vga.textmode="0".

> # hw.vga.textmode="0"
> # vbe_max_resolution=1280x800
> 
> (That is, not specifying anything for hw.vga.textmode or
> vbe_max_resolution.)
> 
> This boots OK, but I see no kernel probe messages or single- to
> multi-user mode messages.  I can use (e.g.) Ctl+Alt+F2 to switch to
> vty1, see a "login: " prompt, and that (also) works.  (This is the
> initial symptom I had reported.)

So I tried commenting out hw.vga.textmode="1" and I saw everything
I expected in my context. Whiteish on black background (or at least
something very dark). I did not take videos to do detailed
inspections.


> hw.vga.textmode="1"
> # vbe_max_resolution=1280x800
> 
> This works -- boots OK, and I see kernel probe () messages; this is a
> text console (mostly blue text; some white, against a dark background.
> It's a medium-light blue, so it's easy enough to read (unlike a navy
> blue, for example).

FYI: whiteish on black (or at least something very dark)
in my hw.vga.textmode="1" context. I saw everything here
as well. I did not take videos to do detailed inspections.

I did not notice any way to tell hw.vga.textmode="1" from
having no hw.vga.textmode assignment at all. But, again,
I did not set up for an after-the-fact detailed review of
what is displayed.

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

Re: kldxref: /boot/kernel/kernel: too many segments

[Matthias Apitz]

El día martes, enero 05, 2021 a las 01:11:14p. m. +0100, Herbert J. Skuhra 
escribió:

> On Tue, Jan 05, 2021 at 01:01:33PM +0100, Matthias Apitz wrote:
> > 
> > Hello,
> > 
> > On an amd64 system r314251 a world and kernel built fine from SVN r368166 
> > the
> > installation with
> > 
> > # make installkernel KERNCONF=GENERIC
> > 
> > endet with the following messages
> > 
> > install -T release -o root -g wheel -m 555   zlib.ko /boot/kernel/
> > install -T dbg -o root -g wheel -m 555   zlib.ko.debug 
> > /usr/lib/debug/boot/kernel/
> > kldxref /boot/kernel
> > kldxref: /boot/kernel/kernel: too many segments
> > --
> > >>> Installing kernel GENERIC completed on Tue Jan  5 12:50:59 CET 2021
> > --
> > 
> > What should I do before rebooting to continue with the installation of
> > world?
> 
> 
> 
> Just to be on the safe side (test the kernel):
> 
> 1. rm /boot/kernel and mv /boot/kernel.old /boot/kernel
> 
> If you are using UFS: 
> 
> 2. make installkernel KODIR=/boot/testkernel 
> 3. nextboot -k testkernel
> 
> If you are using ZFS:
> 
> Use bectl and zfsbootcfg.

Thanks. The kernel booted fine. I filed a PR:

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

matthias


-- 
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
¡Con Cuba no te metas!  «»  Don't mess with Cuba!  «»  Leg Dich nicht mit Kuba 
an!
http://www.cubadebate.cu/noticias/2020/12/25/en-video-con-cuba-no-te-metas/
___
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: git non-time-sequential logs

[Theron]

On 1/5/21 2:36 PM, John Baldwin wrote:

On 1/4/21 8:52 AM, John Kennedy wrote:

On Mon, Jan 04, 2021 at 08:22:56AM -0800, John Kennedy wrote:

The git logs in /usr/src aren't time-sequential, so maybe I shouldn't trust
those dates above (I pulled it ~Jan 3rd and let it compile overnight), but
I'm going to repull all the sources and recompile, just in case.  I might
have initiall pulled it during the git conversion and maybe it is confused.

This might be perfectly natural and just new to me, but when I look at the
git logs this morning I see things like this (editing by me):

commit e5df46055add3bcf074c9ba275ceb4481802ba04 (HEAD -> main, 
freebsd/main, freebsd/HEAD)
Author: Emmanuel Vadot 
Date:   Mon Jan 4 17:30:00 2021 +0100

commit f61a3898bb989edef7ca308043224e495ed78f64
Author: Emmanuel Vadot 
Date:   Mon Dec 14 18:56:56 2020 +0100

commit b6cc69322a77fa778b00db873781be04f26bd2ee
Author: Emmanuel Vadot 
Date:   Tue Dec 15 13:50:00 2020 +0100

commit 4401fa9bf1a3f2a7f2ca04fae9291218e1ca56bf
Author: Emmanuel Vadot 
Date:   Mon Jan 4 16:23:10 2021 +0100

   This is a fresh clone+pull off of anon...@git.freebsd.org:src.git.

   I've always assumed that the "Date:" there was when the commit happened,
so they'd be increasing (most recent on top), but I suppose that you might
have developers in branches that are committing to their branch at one
point in time and it's getting merged into current (main) later, but the
original date is preserved?

   I guess I only care because I was trying to use time to bisect the
time I thought the problem might have been introduced.

For commits to gdb (which uses git), the project asks that all series be
rebased via 'git rebase --ignore-date' prior to pushing to master to give
monotonically increasing commit dates.  We could do something similar in
FreeBSD either by asking folks to do that explicitly (though I know I
sometimes forget when pushing to gdb myself), or we could avoid direct
pushes to main.  One option some folks mentioned on IRC was to have a
separate "staging" branch that developers push to and then have a bot that
does a rebase --ignore-date of that branch to main periodically, though
that opens the question of how to deal with cherry-picks to stable (for
which asking developers to do a rebase --ignore-date prior to pushing is
probably the simpler approach).

If we did want monotonically increasing dates without having a staging
branch, we could perhaps use a server-side push hook to reject them and
developers would just have to do a rebase --ignore-date before pushing
again.

In the example above, the commit dates *are* monotonically increasing.  
The author dates aren't however, and that's what the log shows.


Commit dates for direct changes to HEAD (seen in 'git log --first-parent 
--pretty=fuller' among other methods) seem like a direct replacement for 
SVN revisions and their timestamps.  Maybe I'm not understanding the 
problem?


To be extra sure commit dates remain monotonic, it would make sense to 
enforce by rule:

- The commit date must not be earlier than the date of the commit's parent.
- The commit date must not be in the future.
Is there any nonnegligible reason not to impose that as a protection 
against accidental system time misconfigurations?  In any other 
circumstance, it would not come into effect anyway?

___
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

[Mark Millard]

On 2021-Jan-5, at 14:46, Toomas Soome  wrote:

> On 5. Jan 2021, at 00:59, Toomas Soome  wrote:
>> 
>> 
>> 
>>> On 4. Jan 2021, at 18:30, Toomas Soome  wrote:
>>> 
>>> 
>>> 
 On 4. Jan 2021, at 18:22, John Kennedy  wrote:
 
 This is a little weird.
 
 Somewhere between 13.0-g2ff66a915526 (Dec 30th) and -gd03fd8ede2c4 (Dec 
 29th),
 I've lost the screen in the boot loader.  This is really weird because I
 didn't update the boot loader (in quite a while, actually), but I suppose 
 it
 might drag some stuff off of the disk and misbehave.
 
 But the system boots, presumably after the countdown that I can't see, I 
 just
 have to SSH in from a different machine to tweak things.  Just no screen at
 all past the GELI encrypted disk password prompt (and some usual noise as
 it complains about some padding that I've seen forever).
 
 I used to just upgrade the boot loader around ZFS upgrades, and I haven't
 done that since OpenZFS got merged.  I just got overly conservative there
 and may have missed the "all clear" for all combinations of ZFS and the
 bootloader recognizing them.
 
 The git logs in /usr/src aren't time-sequential, so maybe I shouldn't trust
 those dates above (I pulled it ~Jan 3rd and let it compile overnight), but
 I'm going to repull all the sources and recompile, just in case.  I might
 have initiall pulled it during the git conversion and maybe it is confused.
 
>>> 
>>> hi!
>>> 
>>> Yes, it is known defect, and I’m searching for cause; the issue is with 
>>> /boot/loader and BIOS text mode (unfortunately I have the usual ‘but it is 
>>> working for me’ case). For workaround, you can try to either: 1 (blind) 
>>> press esc to get out of boot menu, then enter: vbe on; another option is to 
>>> add hw.vga.textmode=“0” to loader.conf.
>>> 
>>> Sorry for confusion,
>>> toomas
>>> 
>> 
>> the 58661b3ba9eb should hopefully fix the loader text mode issue, it would 
>> be cool if you can verify:)
>> 
>> thanks,
>> toomas
> 
> I think, I got it fixed (at least idwer did confirm for his system, thanks). 
> If you can test this patch: 
> http://148-52-235-80.sta.estpak.ee/0001-loader-rewrite-font-install.patch it 
> would be really nice.
> 

[I got to this sooner than I originally expected.]

With the patch applied, hw.vga.textmode="1" finally displayed
correctly for the ThreadRipper 1950X context that I had originally
reported. (The only amd64 FreeBSD context that I've access to.)

Thanks,
Mark

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

Re: boot loader blank screen

[John Kennedy]

On Wed, Jan 06, 2021 at 12:46:08AM +0200, Toomas Soome wrote:
> I think, I got it fixed (at least idwer did confirm for his system, thanks). 
> If you can test this patch: 
> http://148-52-235-80.sta.estpak.ee/0001-loader-rewrite-font-install.patch 
>  
> it would be really nice.

  I regret to say that it didn't fix my issue.

___
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

[Toomas Soome]

> On 5. Jan 2021, at 00:59, Toomas Soome  wrote:
> 
> 
> 
>> On 4. Jan 2021, at 18:30, Toomas Soome > > wrote:
>> 
>> 
>> 
>>> On 4. Jan 2021, at 18:22, John Kennedy >> > wrote:
>>> 
>>> This is a little weird.
>>> 
>>> Somewhere between 13.0-g2ff66a915526 (Dec 30th) and -gd03fd8ede2c4 (Dec 
>>> 29th),
>>> I've lost the screen in the boot loader.  This is really weird because I
>>> didn't update the boot loader (in quite a while, actually), but I suppose it
>>> might drag some stuff off of the disk and misbehave.
>>> 
>>> But the system boots, presumably after the countdown that I can't see, I 
>>> just
>>> have to SSH in from a different machine to tweak things.  Just no screen at
>>> all past the GELI encrypted disk password prompt (and some usual noise as
>>> it complains about some padding that I've seen forever).
>>> 
>>> I used to just upgrade the boot loader around ZFS upgrades, and I haven't
>>> done that since OpenZFS got merged.  I just got overly conservative there
>>> and may have missed the "all clear" for all combinations of ZFS and the
>>> bootloader recognizing them.
>>> 
>>> The git logs in /usr/src aren't time-sequential, so maybe I shouldn't trust
>>> those dates above (I pulled it ~Jan 3rd and let it compile overnight), but
>>> I'm going to repull all the sources and recompile, just in case.  I might
>>> have initiall pulled it during the git conversion and maybe it is confused.
>>> 
>> 
>> hi!
>> 
>> Yes, it is known defect, and I’m searching for cause; the issue is with 
>> /boot/loader and BIOS text mode (unfortunately I have the usual ‘but it is 
>> working for me’ case). For workaround, you can try to either: 1 (blind) 
>> press esc to get out of boot menu, then enter: vbe on; another option is to 
>> add hw.vga.textmode=“0” to loader.conf.
>> 
>> Sorry for confusion,
>> toomas
>> 
> 
> the 58661b3ba9eb should hopefully fix the loader text mode issue, it would be 
> cool if you can verify:)
> 
> thanks,
> toomas

I think, I got it fixed (at least idwer did confirm for his system, thanks). If 
you can test this patch: 
http://148-52-235-80.sta.estpak.ee/0001-loader-rewrite-font-install.patch 
 it 
would be really nice.

thanks,
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: aarch64 based on main 58661b3ba9eb : panic for "ufs_dirbad: /: bad dir ino 66371814 at offset 106496: mangled entry"

[Mark Millard]

On 2021-Jan-5, at 13:28, Mark Murray  wrote:

>> On 5 Jan 2021, at 20:15, Mark Millard  wrote:
>> 
>> The machine is a MACCHIATOBin Double Shot.
> 
> Thanks for the warning :-)
> 
> I'm using an MBin/DS as my firewall/gateway, and in its Copious Free Time™, 
> an ARM64 build-box.
> 
> How recent is your UEFI SD boot image? Are you maintaining a history and 
> download site?
> 

[Note: This reply has no information related to the problem
report. I'm just answering other questions.]

I was given a UEFI materials to use a fair time ago and they
have worked sufficiently for my use. Absent a FreeBSD port
that I can use to build UEFI updates in a normal, ports-style
way, I've left it alone in this area. The UEFI screen reports:

MARVELL UEFI 18.09.0

The boot sequence reports:

BootROM - 2.03

Starting CP-0 IOROM 1.07

Booting from SD 0 (0x29)

Found valid image at boot postion 0x000

lNOTICE:  Starting binary extension
NOTICE:  SVC: SW Revision 0x0. SVC is not supported
mv_ddr: mv_ddr-armada-18.09.2-g99d7725 (Oct 29 2018 - 23:32:10)
mv_ddr: completed successfully
NOTICE:  Cold boot
NOTICE:  Booting Trusted Firmware
NOTICE:  BL1: v1.5(release):v1.5-219-g711ecd3 (Marvell-armada-18.09.4)
NOTICE:  BL1: Built : 23:32:27, Oct 29 2018
NOTICE:  BL1: Booting BL2
NOTICE:  BL2: v1.5(release):v1.5-219-g711ecd3 (Marvell-armada-18.09.4)
NOTICE:  BL2: Built : 23:32:35, Oct 29 2018
BL2: Initiating SCP_BL2 transfer to SCP
NOTICE:  SCP_BL2 contains 5 concatenated images
NOTICE:  Skipping MSS CP3 related image
NOTICE:  Skipping MSS CP2 related image
NOTICE:  Load image to CP1 MSS AP0
NOTICE:  Loading MSS image from addr. 0x40265f4 Size 0x1ad8 to MSS at 0xf428
NOTICE:  Done
NOTICE:  Load image to CP0 MSS AP0
NOTICE:  Loading MSS image from addr. 0x40280cc Size 0x1ad8 to MSS at 0xf228
NOTICE:  Done
NOTICE:  Load image to AP0 MSS
NOTICE:  Loading MSS image from addr. 0x4029ba4 Size 0x4a40 to MSS at 0xf058
NOTICE:  Done
NOTICE:  BL1: Booting BL31
lNOTICE:  BL31: v1.5(release):v1.5-219-g711ecd3 (Marvell-armada-18.09.4)
NOTICE:  BL31: Built : 23:32:47, Oct 29 2018

Armada 8040 MachiatoBin Platform Init

(I'll stop with that.)

One issue is that between:

Booting [/boot/kernel/kernel]...   
|/-\No valid device tree blob found!
WARNING! Trying to fire up the kernel, but no device tree blob found!

and:

Setting hostuuid: **REPLACED**.
Setting hostid: **REPLACED**.
Starting file system checks:

there is no output to the serial console. If I ever have problems
in that time frame, recovery would be a problem unless I found
a better UEFI variation to put in place, one that outputs
everything to the serial console.


As for my use, no history/download site, nothing externally
visible at all. No use as a firewall or gateway either. But I do
some aarch64 and armv7 builds on it.


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

Re: git non-time-sequential logs

[Jamie Landeg-Jones]

Warner Losh  wrote:

> > Not having timestamps on files cloned or viewed in cgit.freebsd.org is a
> > nightmare too.
> >
>
> I just clicked through and saw several time stamps quite trivially. Could
> you be more specific in your complaint?
>
> Warner

I wasn't really complaining - If the git transition is better for you guys, I'm 
all for it.

However, this is one such URL: https://cgit.freebsd.org/src/tree/usr.bin/diff

Those files have no dates besides them on my screen..

Cheers, Jamie
___
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

[David Wolfskill]

On Wed, Jan 06, 2021 at 12:46:08AM +0200, Toomas Soome wrote:
> ... 
> > the 58661b3ba9eb should hopefully fix the loader text mode issue, it would 
> > be cool if you can verify:)
> > 
> > thanks,
> > toomas
> 
> I think, I got it fixed (at least idwer did confirm for his system, thanks). 
> If you can test this patch: 
> http://148-52-235-80.sta.estpak.ee/0001-loader-rewrite-font-install.patch 
>  
> it would be really nice.
> 
> thanks,
> toomas

I tested with each of the following "stanzas' in /boot/loader.conf,
using vt (vs. syscons) in each case (though that breaks video reset
on resume after suspend):

# hw.vga.textmode="0"
vbe_max_resolution=1280x800

This works, and provides a graphical console (depth 32).


hw.vga.textmode="0"
# vbe_max_resolution=1280x800

This also works, and provides a low-resolution (and depth 16)
graphical console (800x320 or something similar, IIRC).


# hw.vga.textmode="0"
# vbe_max_resolution=1280x800

(That is, not specifying anything for hw.vga.textmode or
vbe_max_resolution.)

This boots OK, but I see no kernel probe messages or single- to
multi-user mode messages.  I can use (e.g.) Ctl+Alt+F2 to switch to
vty1, see a "login: " prompt, and that (also) works.  (This is the
initial symptom I had reported.)


hw.vga.textmode="1"
# vbe_max_resolution=1280x800

This works -- boots OK, and I see kernel probe () messages; this is a
text console (mostly blue text; some white, against a dark background.
It's a medium-light blue, so it's easy enough to read (unlike a navy
blue, for example).


FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #113 
main-c255601-g9fd96b416c45-dirty: Tue Jan  5 17:24:45 PST 2021 
r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY  amd64

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Defense against criminal charges for Trump's call to "find 11,780 votes":
he's delusional.  That must be why he should be making life-or-death decisions.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

aarch64 based on main 58661b3ba9eb : panic for "ufs_dirbad: /: bad dir ino 66371814 at offset 106496: mangled entry"

[Mark Millard]

Later I give notes about the context. The failure reported . . .

# panic: ufs_dirbad: /: bad dir ino 66371814 at offset 106496: mangled entry
cpuid = 0
time = 1609844528
KDB: stack backtrace:
db_trace_self() at db_trace_self_wrapper+0x30
 pc = 0x0081c654  lr = 0x0011ccb4
 sp = 0xac7a9e60  fp = 0xac7aa060

db_trace_self_wrapper() at vpanic+0x198
 pc = 0x0011ccb4  lr = 0x004be678
 sp = 0xac7aa070  fp = 0xac7aa0d0

vpanic() at panic+0x44
 pc = 0x004be678  lr = 0x004be4dc
 sp = 0xac7aa0e0  fp = 0xac7aa190

panic() at ufs_lookup_ino+0xc9c
 pc = 0x004be4dc  lr = 0x00775044
 sp = 0xac7aa1a0  fp = 0xac7aa270

ufs_lookup_ino() at vfs_cache_lookup+0xd0
 pc = 0x00775044  lr = 0x0059a768
 sp = 0xac7aa280  fp = 0xac7aa2f0

vfs_cache_lookup() at cache_fplookup_noentry+0x158
 pc = 0x0059a768  lr = 0x0059f270
 sp = 0xac7aa300  fp = 0xac7aa340

cache_fplookup_noentry() at cache_fplookup+0x440
 pc = 0x0059f270  lr = 0x0059c0f4
 sp = 0xac7aa350  fp = 0xac7aa410

cache_fplookup() at namei+0xd0
 pc = 0x0059c0f4  lr = 0x005a79fc
 sp = 0xac7aa420  fp = 0xac7aa4f0

namei() at kern_statat+0xa4
 pc = 0x005a79fc  lr = 0x005c82d8
 sp = 0xac7aa500  fp = 0xac7aa660

kern_statat() at sys_fstatat+0x2c
 pc = 0x005c82d8  lr = 0x005c888c
 sp = 0xac7aa670  fp = 0xac7aa780

sys_fstatat() at do_el0_sync+0x460
 pc = 0x005c888c  lr = 0x0083e048
 sp = 0xac7aa790  fp = 0xac7aa820

do_el0_sync() at handle_el0_sync+0x90
 pc = 0x0083e048  lr = 0x0081f224
 sp = 0xac7aa830  fp = 0xac7aa980

handle_el0_sync() at 0x403da3e8
 pc = 0x0081f224  lr = 0x403da3e8
 sp = 0xac7aa990  fp = 0xe630

KDB: enter: panic
[ thread pid 58718 tid 100101 ]
Stopped at  0x403dd330
db> 

Unfortunately the db> prompt is not taking any input so all I have
is the backtrace. The machine had been left idle after upgrading
from being head -r368820 based and other activity. The
"~/fbsd-based-on-what-freebsd-main.sh mm-src" and uname below just
happened to be the last things I did before leaving it idle
overnight. I've no clue how long it was idle before the panic
happened.

# ~/fbsd-based-on-what-freebsd-main.sh mm-src
58661b3ba9ebe82f889cbc336afe618ad7f7940a
CommitDate: 2021-01-04 15:12:03 -0800
085d41abe5f1 58661b3ba9eb (HEAD -> mm-src) mm-src snapshot for mm's patched 
build in git context.
# uname -apKU
FreeBSD FBSDmacch 13.0-CURRENT FreeBSD 13.0-CURRENT 
mm-src-c255600-g085d41abe5f1 GENERIC-NODBG  arm64 aarch64 1300133 1300133

I did a fair amount of activity after the upgrade but before leaving
it idle, lots of file system activity being involved.

The machine is a MACCHIATOBin Double Shot. FreeBSD was from a
cross build, using -mcpu=cortex-a72 . (I mention mcpu in part
because I've caught a missing-synchronization issue in the past
from doing this, something a cortex-a53 running the same
build did not show and for which the cortex-a72 did not show
the issue when running a plain aarch64 or cortex-a53 targeted
build. I'm not claiming to know that the wider range of behavior
for the cortex-a72 is involved here.)


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

Re: Unofficial PkgBase Repository

[Goran Mekić]

> p.s.: if it feels slow, blame virtio + vnet
This made it fast for me (rc.conf):

ifconfig_vtnet0="DHCP -tso -lro"


signature.asc
Description: PGP signature

Re: git non-time-sequential logs

[John Baldwin]

On 1/4/21 8:52 AM, John Kennedy wrote:
> On Mon, Jan 04, 2021 at 08:22:56AM -0800, John Kennedy wrote:
>> The git logs in /usr/src aren't time-sequential, so maybe I shouldn't trust
>> those dates above (I pulled it ~Jan 3rd and let it compile overnight), but
>> I'm going to repull all the sources and recompile, just in case.  I might
>> have initiall pulled it during the git conversion and maybe it is confused.
> 
> This might be perfectly natural and just new to me, but when I look at the
> git logs this morning I see things like this (editing by me):
> 
>   commit e5df46055add3bcf074c9ba275ceb4481802ba04 (HEAD -> main, 
> freebsd/main, freebsd/HEAD)
>   Author: Emmanuel Vadot 
>   Date:   Mon Jan 4 17:30:00 2021 +0100
> 
>   commit f61a3898bb989edef7ca308043224e495ed78f64
>   Author: Emmanuel Vadot 
>   Date:   Mon Dec 14 18:56:56 2020 +0100
> 
>   commit b6cc69322a77fa778b00db873781be04f26bd2ee
>   Author: Emmanuel Vadot 
>   Date:   Tue Dec 15 13:50:00 2020 +0100
> 
>   commit 4401fa9bf1a3f2a7f2ca04fae9291218e1ca56bf
>   Author: Emmanuel Vadot 
>   Date:   Mon Jan 4 16:23:10 2021 +0100
> 
>   This is a fresh clone+pull off of anon...@git.freebsd.org:src.git.
> 
>   I've always assumed that the "Date:" there was when the commit happened,
> so they'd be increasing (most recent on top), but I suppose that you might
> have developers in branches that are committing to their branch at one
> point in time and it's getting merged into current (main) later, but the
> original date is preserved?
> 
>   I guess I only care because I was trying to use time to bisect the
> time I thought the problem might have been introduced.

For commits to gdb (which uses git), the project asks that all series be
rebased via 'git rebase --ignore-date' prior to pushing to master to give
monotonically increasing commit dates.  We could do something similar in
FreeBSD either by asking folks to do that explicitly (though I know I
sometimes forget when pushing to gdb myself), or we could avoid direct
pushes to main.  One option some folks mentioned on IRC was to have a
separate "staging" branch that developers push to and then have a bot that
does a rebase --ignore-date of that branch to main periodically, though
that opens the question of how to deal with cherry-picks to stable (for
which asking developers to do a rebase --ignore-date prior to pushing is
probably the simpler approach).

If we did want monotonically increasing dates without having a staging
branch, we could perhaps use a server-side push hook to reject them and
developers would just have to do a rebase --ignore-date before pushing
again.

-- 
John Baldwin
___
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: git non-time-sequential logs

[Warner Losh]

On Tue, Jan 5, 2021 at 6:08 AM Jamie Landeg-Jones  wrote:

> Ryan Libby  wrote:
>
> > On Mon, Jan 4, 2021 at 10:08 AM Warner Losh  wrote:
> > ...
> > > As for date order, we could also add a commit hook that requires the
> date
> > > to be properly set, but that creates friction for developers. Is that
> > > friction worth the benefits? I don't think so, but as you say we could
> also
> > > add notes... but since there's no checkout by date feature, I'm not
> sure
> > > what good it would do.
> >
> > Not a vote one way or the other, but it would at least make
> > git log --since more meaningful.
>
> Not having timestamps on files cloned or viewed in cgit.freebsd.org is a
> nightmare too.
>

I just clicked through and saw several time stamps quite trivially. Could
you be more specific in your complaint?

Warner
___
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: git non-time-sequential logs

[Warner Losh]

On Mon, Jan 4, 2021 at 9:06 PM David G Lawrence  wrote:

> > Yes. Git has never been a true/pure VCS. However, it does offer enough
> > VCS-like features to create a shared distributed versioned tree that's
> > useful to the project.
> >
> > As for date order, we could also add a commit hook that requires the date
> > to be properly set, but that creates friction for developers. Is that
> > friction worth the benefits? I don't think so, but as you say we could
> also
> > add notes... but since there's no checkout by date feature, I'm not sure
> > what good it would do.
>
> Warner,
>
>Why is it that the project can't continue to operate the SVN server in
> addition to Git, gatewaying with -current as is being done with 12-stable?
> As a developer, I definitely need monotonic revision numbers and reliable
> dates when I'm trying to troubleshoot a regression. I understand that you
> want better 'collaboration' in FreeBSD, but why can't we have the best of
> both worlds?
>

Hi David,

We purposely decided not to mirror main -> head. This is a conversion and
git is the source of truth.

Mirroring to head would have created additional demand for the continued
generation of git notes to coordinate the subversion r numbers than
just having it be for stable/12. The script that's been written, but
delayed due to illness just publishes changes to subversion: nothing more.
Even this simple design took more time and effort than anticipated.

Mirroring to stable/12 only gives an effective end date for subversion.

Git does provide you the tools you want to do bisection, they are just a
bit different. Just as subversion provided new tools that CVS didn't, git
does the same. Subversion was also unfamiliar at first and took some time
to understand its paradigms and how they differed from CVS. They also
sounded scary and crazy at the time, but turned out to be more fear of the
unknown rather than actual problems in practice. Git provides a revision
count on a branch (or since inception) that can be used to soften the blow
of r numbers going away that's almost the same (it won't coordinate
between branches, but then we rarely needed that property of r
numbers). Git doesn't provide checkout by date, but we've not needed that
since CVS days when it was the only way to bisect a change (though I will
admit it was handy to be able to do it, one can still do it, but with a
little more effort and fuzziness).

So to do the mirroring back to subversion was hard, created logistical
issues, and was one more thing that needed care and feeding. As such, we
limited its scope to limit the extra work for the project and to time-bound
how long that obligation lasts.

Warner
___
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: git non-time-sequential logs

[Jamie Landeg-Jones]

Ryan Libby  wrote:

> On Mon, Jan 4, 2021 at 10:08 AM Warner Losh  wrote:
> ...
> > As for date order, we could also add a commit hook that requires the date
> > to be properly set, but that creates friction for developers. Is that
> > friction worth the benefits? I don't think so, but as you say we could also
> > add notes... but since there's no checkout by date feature, I'm not sure
> > what good it would do.
>
> Not a vote one way or the other, but it would at least make
> git log --since more meaningful.

Not having timestamps on files cloned or viewed in cgit.freebsd.org is a 
nightmare too.
___
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: kldxref: /boot/kernel/kernel: too many segments

[Herbert J. Skuhra]

On Tue, Jan 05, 2021 at 01:01:33PM +0100, Matthias Apitz wrote:
> 
> Hello,
> 
> On an amd64 system r314251 a world and kernel built fine from SVN r368166 the
> installation with
> 
> # make installkernel KERNCONF=GENERIC
> 
> endet with the following messages
> 
> install -T release -o root -g wheel -m 555   zlib.ko /boot/kernel/
> install -T dbg -o root -g wheel -m 555   zlib.ko.debug 
> /usr/lib/debug/boot/kernel/
> kldxref /boot/kernel
> kldxref: /boot/kernel/kernel: too many segments
> --
> >>> Installing kernel GENERIC completed on Tue Jan  5 12:50:59 CET 2021
> --
> 
> What should I do before rebooting to continue with the installation of
> world?



Just to be on the safe side (test the kernel):

1. rm /boot/kernel and mv /boot/kernel.old /boot/kernel

If you are using UFS: 

2. make installkernel KODIR=/boot/testkernel 
3. nextboot -k testkernel

If you are using ZFS:

Use bectl and zfsbootcfg.

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

kldxref: /boot/kernel/kernel: too many segments

[Matthias Apitz]

Hello,

On an amd64 system r314251 a world and kernel built fine from SVN r368166 the
installation with

# make installkernel KERNCONF=GENERIC

endet with the following messages

install -T release -o root -g wheel -m 555   zlib.ko /boot/kernel/
install -T dbg -o root -g wheel -m 555   zlib.ko.debug 
/usr/lib/debug/boot/kernel/
kldxref /boot/kernel
kldxref: /boot/kernel/kernel: too many segments
--
>>> Installing kernel GENERIC completed on Tue Jan  5 12:50:59 CET 2021
--

What should I do before rebooting to continue with the installation of
world?

Thanks

matthias

-- 
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
___
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: git non-time-sequential logs

[grarpamp]

>Why is it that the project can't continue to operate the SVN server in
> addition to Git, gatewaying with -current as is being done with 12-stable?
> As a developer, I definitely need monotonic revision numbers and reliable
> dates when I'm trying to troubleshoot a regression. I understand that you
> want better 'collaboration' in FreeBSD, but why can't we have the best of
> both worlds?

Unlimited best worlds are already free to exist.

In addition to the internet's good suggestions how to use the
forms of "revision numbers" already in git, and the internet's
many good tutorials on how to learn, use, adopt, adapt
and live breathe git, FreeBSD has chosen git for this time.
It appears unsensible to expect any opensource
project or OS to continue operation and maintenance of
N x different repos and different repo camps in perpetuity
because minor minority seeks some small feature. A feature
in shipped code for users ok, but not in raw project overhead.
Look at the entirety of Linux and Github's thousands of big projects...
who there is leaving git these days to get number feature?
The way forward is to explore how those git projects use git to
"troubleshoot regressions" as obviously they are performing
that function well everyday, without regard to such numbers
or dates. If people find they need numbers or anything else,
they can also get together and offsite host great import "gateway"
services (or on their own locally), publish wrapper script ports,
metainfo db's, etc... those best worlds are really unlimited and
infinitely customizable as needed, so much can be done there :)
Though since FreeBSD (and almost all world of public code
repos) has chosen git and abandoned SVN etc, it's unsensible
to expect a project efficiently on one repo (FreeBSD on git) to
really interact using such N x repos within itself... it's overhead.
The good people running those N x repos will need to speak git
upstream, or at least send up patch format. That is the normal
history of [mass effect] migrations.

For more "best worlds"...
Now can call to deploy RCS too, "because" pretty version
numbers, wastes zero time on security concerns, etc.
And call to pass around tarballs on tape too, "because"
tape is reliable and can hold every revision and iso and pkg
of every OS on one 580TiB raw cart, 2+PiB compressed ;)

And as far as which of N x services to examine offsite,
rather than boring numbers, perhaps it would be more
academically interesting to learn a bit about the crypto primitives,
distribution network, and database behind some things like
https://monotone.ca/

Or anything about any other repos far more novel or
new than any of those above. Since one day people might
have to leave some formerly thought "needed" feature of git
behind in order to be carried by and follow the world into
one of those repos in the future as well. They might
even be the ones abandoning their thoughts first in order
to carry and lead others there.
___
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: git non-time-sequential logs

[Poul-Henning Kamp]

David G Lawrence writes:

>Why is it that the project can't continue to operate the SVN server in
> addition to Git, gatewaying with -current as is being done with 12-stable?

David,

With all due respect:  That question has been asked and answered so many
times now, that it's time to stop asking it and move on.

And mind you:  Nothing prevents you, or any other person who cannot live
without SVN, from providing that service yourself.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
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: git non-time-sequential logs

[David G Lawrence]

> Yes. Git has never been a true/pure VCS. However, it does offer enough
> VCS-like features to create a shared distributed versioned tree that's
> useful to the project.
> 
> As for date order, we could also add a commit hook that requires the date
> to be properly set, but that creates friction for developers. Is that
> friction worth the benefits? I don't think so, but as you say we could also
> add notes... but since there's no checkout by date feature, I'm not sure
> what good it would do.

Warner,

   Why is it that the project can't continue to operate the SVN server in
addition to Git, gatewaying with -current as is being done with 12-stable?
As a developer, I definitely need monotonic revision numbers and reliable
dates when I'm trying to troubleshoot a regression. I understand that you
want better 'collaboration' in FreeBSD, but why can't we have the best of
both worlds?

-DG

 *  David Greenman-Lawrence
* * Pave the road of life with opportunities.
___
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"