No Subject
subscribe freebsd-current To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fixing -pthreads (Re: ports and -current)
> > On Wed, 24 Sep 2003, Scott Long wrote: > >> I'm a big advocate of using libmap to deal with this. > > Ditto. > > Based on the results seen thus far, my preference would really be for: > > (1) Keep -pthread, make it imply -lpthread, saving a lot of hassle. > > (2) Ship all packages and binaries using threading with -lpthread -- > i.e., > a dynamic library dependency on libpthread. This will mean that > administrators don't have to list each possible threading library in > /etc/libmap.conf in order to be sure they caught all of them. > > (3) Use libmap to perform the necessary substitution on a > per-application > or per-system basis. If libpthread isn't available on an > architecture, default ship libmap.conf to substitute libthr for > libpthread on the platform for all applications. Or libc_r, or > whatever. > > This will result in all applications we ship having a consistent thread > library name so that administrators can substitute more easily. > libpthread would give you M:N threading by default, but it would be easy > to perform local changes to improve performance for applications that > specifically benefit from 1:1 threading, cothreads, etc. Or if a > serious compatibility bug is found between libpthread and an > application, they can substitute easily as well. I suppose this case > might imply (4): > > (4) If an application is known to be compatible only with a specific > threading model, do hard-code that in the application build somehow. This sounds to me like the best solution I've seen so far. We have libmap, so why not use it? Only expert users will probably want to play with different thread libraries, and they can find out about libmap.conf themselves. Arjan _______ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Machine panics when mount_smb fs is run
Trying to mount a cdrom from my XP box using
mount_smbfs //jason@desktop/cdrom /cdrom
Causes my machine to panic and die. Below is hopefully some info that
will help resolve the problem
Included as an attachment in plain text format the boot sequence showing
my hardware. The motherboard itself is
An Asus CUV4X
I will keep the core file itself for a few days under the name
smbfs.smp-kernel.core (I seem to generate a boatload
Of core files, and even on a 40 gig drive I'm running outa space fast)
if anyone needs more info.
grim# gdb -k /boot/kernel/kernel.debug
af4e67719bcbc259bfe24101757d16e8.core
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-unknown-freebsd"...
IdlePTD at phsyical address 0x0043a000
initial pcb at physical address 0x00343ca0
panicstr: bremfree: bp 0xc85c52d8 not locked
panic messages:
---
Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic.id =
fault virtual address = 0x0
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc01d2b00
stack pointer = 0x10:0xcfe82bbc
frame pointer = 0x10:0xcfe82bc4
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 280 (smbiod0)
trap number = 12
panic: page fault
cpuid = 1; lapic.id =
boot() called on cpu#1
syncing disks... panic: bremfree: bp 0xc85c52d8 not locked
cpuid = 1; lapic.id =
boot() called on cpu#1
Uptime: 1m22s
Dumping 287 MB
ata0: resetting devices .. done
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213
213 dumping++;
(kgdb) where
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213
#1 0xc01b9088 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:346
#2 0xc01b9299 in panic (fmt=0xc02d9e9d "bremfree: bp %p not locked") at
/usr/src/sys/kern/kern_shutdown.c:490
#3 0xc01e8fa1 in bremfree (bp=0xc85c52d8) at
/usr/src/sys/kern/vfs_bio.c:619
#4 0xc01ea697 in vfs_bio_awrite (bp=0xc85c52d8) at
/usr/src/sys/kern/vfs_bio.c:1593
#5 0xc0195198 in spec_fsync (ap=0xcfe82a70) at
/usr/src/sys/fs/specfs/spec_vnops.c:403
#6 0xc0194d85 in spec_vnoperate (ap=0xcfe82a70) at
/usr/src/sys/fs/specfs/spec_vnops.c:121
#7 0xc0253c2d in ffs_sync (mp=0xcf2c6200, waitfor=2, cred=0xc8571300,
td=0xc0309220) at vnode_if.h:441
#8 0xc01f7257 in sync (td=0xc0309220, uap=0x0) at
/usr/src/sys/kern/vfs_syscalls.c:1217
#9 0xc01b8cda in boot (howto=256) at
/usr/src/sys/kern/kern_shutdown.c:254
#10 0xc01b9299 in panic (fmt=0xc02f413e "%s") at
/usr/src/sys/kern/kern_shutdown.c:490
#11 0xc02a4b83 in trap_fatal (frame=0xcfe82b7c, eva=0) at
/usr/src/sys/i386/i386/trap.c:841
#12 0xc02a48a1 in trap_pfault (frame=0xcfe82b7c, usermode=0, eva=0) at
/usr/src/sys/i386/i386/trap.c:755
#13 0xc02a442b in trap (frame={tf_fs = -806485992, tf_es = -806879216,
tf_ds = -1071972336, tf_edi = 0,
tf_esi = -806910956, tf_ebp = -806868028, tf_isp = -806868056,
tf_ebx = -806466332, tf_edx = 1,
tf_ecx = -1070532736, tf_eax = 0, tf_trapno = 12, tf_err = 2,
tf_eip = -1071830272, tf_cs = 8,
tf_eflags = 66118, tf_esp = -806466432, tf_ss = 1}) at
/usr/src/sys/i386/i386/trap.c:426
#14 0xc01d2b00 in selrecord (selector=0xcfe78414, sip=0xcfee4ce4) at
/usr/src/sys/kern/sys_generic.c:1173
#15 0xc01e347b in sopoll (so=0xcfee4c80, events=1, cred=0x0,
td=0xcfe78414) at /usr/src/sys/kern/uipc_socket.c:1562
#16 0xd01c8d55 in ?? ()
#17 0xd01c919a in ?? ()
#18 0xd01c9773 in ?? ()
#19 0xd01ccc1f in ?? ()
#20 0xd01cd9dd in ?? ()
#21 0xc01aab0c in fork_exit (callout=0xd01cd934, arg=0xcfe09b00,
frame=0xcfe82d48) at /usr/src/sys/kern/kern_fork.c:808
Copyright (c) 1992-2002 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #16: Mon Apr 15 02:25:55 EDT 2002
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/GRIM
Preloaded elf kernel "/boot/kernel/kernel" at 0xc041b000.
Preloaded elf module "/boot/kernel/acpi.ko" at 0xc041b0a8.
Timecounter "i8254" frequency 1193182 Hz
CPU: Pentium III/Pentium III Xeon/Celeron (870.58-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0x686 Stepping = 6
Features=0x387fbff
real memory = 301973504 (294896K bytes)
avail memory = 288686080 (281920K bytes)
Programming 24 pins in IOAPIC #0
IOAPIC #0 intpin 2 -> irq 0
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
cpu0 (BSP): apic id: 3, version: 0x00040011, at 0xfee0
cpu1 (AP): apic id: 0, version:
RE: new /usr/src/share/mk changes breaks install on ports
I got this as well, setting the ENV variable however seems to resolve it temporarily export INFODIR="/usr/share/info" setenv INFODIR /usr/share/info Whichever shell you use, chose the appropriate one, atleast it seemed to work for me, and I have not noticed any problems. Jason -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Manfred Antar Sent: Thursday, April 18, 2002 3:05 AM To: [EMAIL PROTECTED] Subject: new /usr/src/share/mk changes breaks install on ports The recent changes to the /usr/src/share/mk files have made installing ports broken , also doing a make install world stops at /usr/src/share/info: (info)518}make install Warning: the directory /usr/share/info does not exist! Perhaps the variable INFODIR is set incorrectly or your mtree database files are broken. As a workaround you can create the directory by hand, e.g.: install -d -o root -g wheel -m 0755 /usr/share/info *** Error code 3 Stop in /usr/src/share/info. /usr/share/info does exist When trying to install a port ; example libxine: install: invalid file mode: ./version_group.3 install -o -g -m ./vo_driver_t.3 /usr/X11R6/man/man3/vo_driver_t.3 install: invalid file mode: ./vo_driver_t.3 install -o -g -m ./xine_t.3 /usr/X11R6/man/man3/xine_t.3 install: invalid file mode: ./xine_t.3 install -o -g -m ./browse_group.3 /usr/X11R6/man/man3/browse_group.3 install: invalid file mode: ./browse_group.3 install -o -g -m ./event_group.3 /usr/X11R6/man/man3/event_group.3 install: invalid file mode: ./event_group.3 install -o -g -m ./video_cap.3 /usr/X11R6/man/man3/video_cap.3 install: invalid file mode: ./video_cap.3 install -o -g -m ./vo_frame_t.3 /usr/X11R6/man/man3/vo_frame_t.3 install: invalid file mode: ./vo_frame_t.3 install -o -g -m ./xine_version.3 /usr/X11R6/man/man3/xine_version.3 install: invalid file mode: ./xine_version.3 gmake[6]: *** [install-man3] Error 64 gmake[6]: Leaving directory `/usr/ports/graphics/libxine/work/xine-lib-0.9.8/doc/man/en/man3' gmake[5]: *** [install-man] Error 2 gmake[5]: Leaving directory `/usr/ports/graphics/libxine/work/xine-lib-0.9.8/doc/man/en/man3' gmake[4]: *** [install-am] Error 2 gmake[4]: Leaving directory `/usr/ports/graphics/libxine/work/xine-lib-0.9.8/doc/man/en/man3' gmake[3]: *** [install-recursive] Error 1 gmake[3]: Leaving directory `/usr/ports/graphics/libxine/work/xine-lib-0.9.8/doc/man/en' gmake[2]: *** [install-recursive] Error 1 gmake[2]: Leaving directory `/usr/ports/graphics/libxine/work/xine-lib-0.9.8/doc/man' gmake[1]: *** [install-recursive] Error 1 gmake[1]: Leaving directory `/usr/ports/graphics/libxine/work/xine-lib-0.9.8/doc' gmake: *** [install-recursive] Error 1 *** Error code 2 Stop in /usr/ports/graphics/libxine. Every thing worked last night I think the changes happened earlier today. Manfred == || [EMAIL PROTECTED] || || Ph. (415) 681-6235 || == To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: i386 ATA is very broken after sparc64 ATA mega-commit (April 5)
This won't help people using similair drives (in one of my machines) that I am using, I have the same problem in current that I have in RELENG_4, It times out and drops to PIO4 mode after a few min. I dropped "atacontrol mode 0 pio4 none" (I only have the 1 drive on the chain) before the fsck check in /etc/rc to avoid the timeouts and boot normally). I'm sure there is probably a better way to do it, but I'm lazy :) Anyways, its a maxtor drive, I can send someone the drive info if that will help. I don't have the problem though on my Western Digital ata100 drive in another machine. Jason -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Søren Schmidt Sent: Thursday, April 18, 2002 5:18 AM To: Alexander Leidinger Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: i386 ATA is very broken after sparc64 ATA mega-commit (April 5) It seems Alexander Leidinger wrote: > On 18 Apr, Doug Barton wrote: > > Given the impending 4.6-release, might it make sense to back off ata > > in -stable to the last known-good state? > > We have some time until the code freeze, so give him some days to > track it down. If he is able to fix it: fine, else he can still back > it out. I'll see what I can do, but my time is VERY limitted for the next 2-3 weeks, if I get any spare time at all... However, if its decided to back out whats in -stable, remember that it will bring ATA support back to what was in 4.5, which will severely reduce our chipset support etc, which is alot worse IMNHO. The right solution would be to just disable tagged queing, and state that in the docs, but I'm not the RE@ :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Offtopic, but hilarious
Okay, this was pointed out to me on linpeople irc network. Basically if your in the US, and you know who Jerry Fallwell is (spelling??), the story is something you would expect from him. http://members.truepath.com/objective/propaganda.html I apologise in advance if I offended anyone with this, but its too funny to pass up. Heres a sample quote from said story. Apparently the Darwin OS is not the original creation of Apple Computers but is instead based off of an older, obsolete OS called "BSD Unix". The child-indoctrinatingly-cute cartoon mascot of this OS is a devil holding a pitchfork (pictured above). This OS -- and its Darwin offspring -- extensively use what are called "daemons" (which is how Pagans write "demon" -- they are notoriously poor spellers: magick, vampyre, etc.) which is a program that hides in the background, doing things without the user's notice. If you are using a new Macintosh running OS X then you probably have these "daemons" on your computer, hardly something a good Christian would want! This clearly illustrates that not only is Macintosh based on Darwinism, but Darwinism is based on Satanism. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Offtopic, but hilarious
I posted it for its amusement value, nothing else :) -Original Message- From: Igor Roboul [mailto:[EMAIL PROTECTED]] Sent: Monday, April 22, 2002 1:50 AM To: [EMAIL PROTECTED] Subject: Re: Offtopic, but hilarious On Mon, Apr 22, 2002 at 12:55:36AM -0400, [EMAIL PROTECTED] wrote: > Okay, this was pointed out to me on linpeople irc network. Basically > if your in the US, and you know who Jerry Fallwell is (spelling??), > the story is something you would expect from him. > > http://members.truepath.com/objective/propaganda.html > > > I apologise in advance if I offended anyone with this, but its too > funny to pass up. There are so many crazy people, so if we'll worry about every of them, then we'll be so crazy as they are. -- Igor Roboul, System administrator at Speech Technology Center http://www.speechpro.com http://www.speechpro.ru To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS-UP: OpenSSL 1.1.1 in 12.0
On 2018-10-10 06:14, Michael Butler wrote: On 10/9/18 5:34 PM, Glen Barber wrote: OpenSSL has been updated to version 1.1.1 as of r339270. It is important to rebuild third-party packages before running: # make -C /usr/src delete-old && make -C /usr/src delete-old-libs Thank you for your patience while this work was in progress, and thank you to all involved for their hard work in getting things ready for this update. So far, I've found two ports that will no longer build. They are: net-mgmt/net-snmp security/opencryptoki I simply chose those that were linked to /usr/lib/libssl.so.8 where the openssl update creates libssl.so.9. There may be more I haven't found yet, imb You always can add DEFAULT_VERSIONS+=ssl=openssl to /etc/make.conf to use openssl from ports. Anyway, I think apps from ports need to use openssl from ports. ___________ 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: HEADS-UP: OpenSSL 1.1.1 in 12.0
On 2018-10-11 18:02, Jamie Landeg-Jones wrote: freebsd.curr...@clogic.com.ua wrote: Anyway, I think apps from ports need to use openssl from ports. No. Only if it's installed. If not, it's perfectly normal for a port to use the base openssl - it's not a private-lib install. cheers, Jamie I mean it is good idea to use openssl from ports to build other ports that depend on openssl. _______ 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: OpenSSL 1.1.1 libssl.so version number
On 2018-10-13 02:56, Don Lewis wrote:
Prior to the OpenSSL 1.1.1 import, the base OpenSSL library was
/usr/lib/libssl.so.8. The security/openssl port (1.0.2p) installed
${LOCALBASE}/lib/ilbssl.so.9 and the security/openssl-devel port
(1.1.0i) installed ${LOCALBASE}/lib/libssl.so.11. After the import,
the
base OpenSSL library is /usr/lib/libssl.so.9. Now if you build ports
with DEFAULT_VERSIONS+=ssl=openssl, the library that actually gets used
is ambiguous because there are now two different versions of libssl.so
(1.0.2p and 1.1.1) with the same shared library version number.
I stumbled across this when debugging a virtualbox-ose configure
failure. The test executable was linked to the ports version of
libssl.so but rtld chose the base libssl.so at run time.
I see the same issue with ports-mgmt/pkg when security/openssl
installed. Have DEFAULT_VERSIONS+=ssl=openssl in /etc/make.conf
After rebuild pkg on 12-ALPHA9 system:
# pkg
ld-elf.so.1: /usr/local/lib/libcrypto.so.9: version OPENSSL_1_1_0
required by /usr/local/lib/libpkg.so.4 not defined
___
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"
pcmcia cdrom/irq sharing problem?
Hi all,
I've just upgraded my system to today's -CURRENT (I was running a
-CURRENT from April 2001). Although I encountered some problems, the
UPDATING file got me through (I love the way FreeBSD documents stuff)
and my system is running fine (background fsck, great!) except for my
PCMCIA CDROM player. I have a Sony VAIO Z600 laptop by the way.
I was hoping somebody can point me in the right direction (searching
the web/mailinglist archives didn't help).
My CDROM player was always correctly identified with my previous install
as NinjaATA on irq 3 (slot 0 on pccard0). After the upgrade, it is
recognised, but assigned irq 9 (which is not in pccard.conf) after which
the system hangs until the card is removed. This irq is (and was) shared
with fxp0, pcm0.
I've turned off PnP in the BIOS to no avail. I've tried a NEWCARD
kernel, which does not even recognise the card. My PCMCIA wireless card
works fine (also on irq 9).
Attached are kernel messages when inserting the card (with the april
2001 -CURRENT, today's -CURRENT with oldcard and today's -CURRENT with
newcard), dmesg output and kernel config file.
Regards,
Walter.
--
Walter Belgers "Si hoc signum legere potes, operis boni in rebus
[EMAIL PROTECTED] Latinis alacribus et fructuosis potiri potes!"
kernel messages with April 2001 kernel
Sep 19 20:18:32 bwerk /boot/kernel/kernel: pccard: card inserted, slot 0
Sep 19 20:18:31 bwerk pccardd[178]: Card " "("NinjaATA-") [V1.0] [AP00 ] matched " "
("NinjaATA-") [(null)] [(null)]
Sep 19 20:18:37 bwerk /boot/kernel/kernel: ata4 at port 0x180-0x187,0x386 iomem
0xd4000-0xd4fff irq 3 slot 0 on pccard0
Sep 19 20:18:37 bwerk /boot/kernel/kernel: ata4-slave: identify retries exceeded
Sep 19 20:18:37 bwerk /boot/kernel/kernel: acd0: CDROM at
ata4-master BIOSPIO
Sep 19 20:18:37 bwerk pccardd[178]: ata4: NinjaATA inserted.
Oct 16 10:59:37 bwerk /boot/kernel/kernel: pccbb0: card inserted: event=0x,
state=3510
Oct 16 10:59:37 bwerk /boot/kernel/kernel: pccard0: chip_socket_enable
Oct 16 10:59:37 bwerk /boot/kernel/kernel: pccbb_pcic_socket_enable:
Oct 16 10:59:37 bwerk /boot/kernel/kernel: pccbb0: pccbb_power: CARD_VCC_0V and
CARD_VPP_0V [44]
Oct 16 10:59:37 bwerk /boot/kernel/kernel: pccbb0: pccbb_power: CARD_VCC_5V and
CARD_VPP_VCC [15]
Oct 16 10:59:37 bwerk /boot/kernel/kernel: pccbb0: pccbb_pcic_wait_ready: status 0x7f
Oct 16 10:59:37 bwerk /boot/kernel/kernel: pccbb0: card type is mem
Oct 16 10:59:37 bwerk /boot/kernel/kernel: pccard0: read_cis
Oct 16 10:59:37 bwerk /boot/kernel/kernel: pccbb_pcic_mem_map window 0 bus
10001000+400+e000 card addr 0
Oct 16 10:59:37 bwerk /boot/kernel/kernel: pccbb_pcic_do_mem_map window 0: 8001 8001
3fff 10 (10001000+0400.1000*e000)
Oct 16 10:59:37 bwerk /boot/kernel/kernel: pccbb_pcic_do_mem_map window 0: 8001 8001
7fff 10 (10001000+0400.1000*e000)
Oct 16 10:59:37 bwerk /boot/kernel/kernel: cis mem map c8569000
Oct 16 10:59:37 bwerk /boot/kernel/kernel: pccard0: CIS tuple chain:
Oct 16 10:59:37 bwerk /boot/kernel/kernel: CISTPL_DEVICE type=funcspec speed=100ns
Oct 16 10:59:37 bwerk /boot/kernel/kernel: 01 03 dc 00 ff
Oct 16 10:59:37 bwerk /boot/kernel/kernel: CISTPL_VERS_1
Oct 16 10:59:37 bwerk /boot/kernel/kernel: 15 1a 04 01 20 00 4e 69 6e 6a 61 41 54 41
2d 00
Oct 16 10:59:37 bwerk /boot/kernel/kernel: 56 31 2e 30 00 41 50 30 30 20 00 ff
Oct 16 10:59:37 bwerk /boot/kernel/kernel: CISTPL_CONFIG
Oct 16 10:59:37 bwerk /boot/kernel/kernel: 1a 05 01 23 00 02 03
Oct 16 10:59:37 bwerk /boot/kernel/kernel: CISTPL_CFTABLE_ENTRY
Oct 16 10:59:37 bwerk /boot/kernel/kernel: 1b 15 e1 01 3d 11 55 1e fc 23 f0 61 80 01
07 86
Oct 16 10:59:37 bwerk /boot/kernel/kernel: 03 01 30 68 d0 10 00
Oct 16 10:59:37 bwerk /boot/kernel/kernel: CISTPL_CFTABLE_ENTRY
Oct 16 10:59:37 bwerk /boot/kernel/kernel: 1b 0f 22 38 f0 61 90 01 07 96 03 01 30 68
d0 10
Oct 16 10:59:37 bwerk /boot/kernel/kernel: 00
Oct 16 10:59:37 bwerk /boot/kernel/kernel: CISTPL_CFTABLE_ENTRY
Oct 16 10:59:37 bwerk /boot/kernel/kernel: 1b 0f 23 38 f0 61 a0 01 07 a6 03 01 30 68
d0 10
Oct 16 10:59:38 bwerk /boot/kernel/kernel: 00
Oct 16 10:59:38 bwerk /boot/kernel/kernel: CISTPL_NO_LINK
Oct 16 10:59:38 bwerk /boot/kernel/kernel: 14 00
Oct 16 10:59:38 bwerk /boot/kernel/kernel: CISTPL_END
Oct 16 10:59:38 bwerk /boot/kernel/kernel: ff
Oct 16 10:59:38 bwerk /boot/kernel/kernel: pccard0: check_cis_quirks
Oct 16 10:59:38 bwerk /boot/kernel/kernel: pccard0: CIS version PCCARD 2.0 or 2.1
Oct 16 10:59:38 bwerk /boot/kernel/kernel: pccard0: CIS info: , NinjaATA-, V1.0, AP00
Oct 16 10:59:38 bwerk /boot/kernel/kernel: pccard0: Manufacturer code 0x,
product 0x
Oct 16 10:59:38 bwerk /boot/kernel/kernel: pccard0: function 0: unspecified, ccr addr
200 mask 3
Oct 16 10:59:38 bwerk /boot/kernel/kernel: pccard0: function 0, config table entry 33:
I/O card; irq mask d068; iomask 10, iospace 180-187 386-387; memspace 0-fff;
rdybsy_active wp_active bvd_active io8 io16 ir
VIRUS WARNING
WARNING! This mail is generated automatically by virus-scanning software. There was virus found in one or more attachment in e-mail sent by: Peter Wagner <[EMAIL PROTECTED]> at date: Thu, 2 Nov 2000 09:34:34 - , with subject "US PRESIDENT AND FBI SECRETS =PLEASE VISIT => (http://WWW.2600.CO M)<=". There is list of infected files: Found virus "VBS/LoveLetter.worm" in DOMEO.JPG.vbs Please clean files and resend Your message, Your message was dropped. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
can't build CURRENT/amd64 using 9.3?
/i386-elf && /usr/obj/usr/src/make.i386/bmake MK_TESTS=no
DIRPRFX=lib/csu/i386-elf/ obj && /usr/obj/usr/src/make.i386/bmake MK_TESTS=no
DIRPRFX=lib/csu/i386-elf/ depend && /usr/obj/usr/src/make.i386/bmake
MK_TESTS=no DIRPRFX=lib/csu/i386-elf/ all && /usr/obj/usr/src/make.i386/bmake
MK_TESTS=no DIRPRFX=lib/csu/i386-elf/ install
===> lib/csu/i386-elf (obj,depend,all,install)
if ! test -d /usr/obj/usr/src/lib/csu/i386-elf/; then mkdir -p
/usr/obj/usr/src/lib/csu/i386-elf; if ! test -d
/usr/obj/usr/src/lib/csu/i386-elf/; then echo "Unable to create
/usr/obj/usr/src/lib/csu/i386-elf."; exit 1; fi; echo
"/usr/obj/usr/src/lib/csu/i386-elf created for /usr/src/lib/csu/i386-elf"; fi
rm -f .depend
CC='cc ' mkdep -f .depend -a-I/usr/src/lib/csu/i386-elf/../common
-I/usr/src/lib/csu/i386-elf/../../libc/include -std=gnu99
/usr/src/lib/csu/i386-elf/crti.S /usr/src/lib/csu/i386-elf/crtn.S
TMP=_depend$$; sed -e 's/^\([^\.]*\).o[ ]*:/\1.o \1.po \1.So:/' < .depend >
$TMP; mv $TMP .depend
cc -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common
-I/usr/src/lib/csu/i386-elf/../../libc/include -std=gnu99 -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 -Winline
-Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign
-Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable
-Qunused-arguments -c /usr/src/lib/csu/i386-elf/crti.S
cc -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common
-I/usr/src/lib/csu/i386-elf/../../libc/include -std=gnu99 -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 -Winline
-Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign
-Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable
-Qunused-arguments -c /usr/src/lib/csu/i386-elf/crtn.S
cc -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common
-I/usr/src/lib/csu/i386-elf/../../libc/include -std=gnu99 -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 -Winline
-Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign
-Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable
-Qunused-arguments -DGCRT -S -o gcrt1_c.s /usr/src/lib/csu/i386-elf/crt1_c.c
sed -i "" -e '/\.note\.tag/s/progbits/note/' gcrt1_c.s
cc -c -o gcrt1_c.o gcrt1_c.s
cc -O2 -pipe -I/usr/src/lib/csu/i386-elf/../common
-I/usr/src/lib/csu/i386-elf/../../libc/include -std=gnu99 -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 -Winline
-Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign
-Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable
-Qunused-arguments -c /usr/src/lib/csu/i386-elf/crt1_s.S
ld -o gcrt1.o -r crt1_s.o gcrt1_c.o
crt1_s.o: file not recognized: File format not recognized
*** Error code 1
Stop.
bmake[3]: stopped in /usr/src/lib/csu/i386-elf
*** Error code 1
Am I trying something that cannot be done?
If not: what's going on? I googled this and found answers for
Linux+gcc that don't seem to apply.
Respectfully,
Robert Huff
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: can't build CURRENT/amd64 using 9.3?
Ian Lepore writes:
> >I have a system running
> >
> > FreeBSD 9.3-RELEASE #0 r268512: Fri Jul 11 03:13:02 UTC 2014 i386
> >
> >I have updated the source tree to CURRENT r273542.
> >If I build "make buildworld" for the GENERIC kernel and no
> > make.conf or src.conf, it succeeds.
> >If I use an empty make.conf and src.conf of
> >
> > TARGET=amd64
> > TARGET_ARCH=amd64
> >
> >it dies with
> >
> > ld -o gcrt1.o -r crt1_s.o gcrt1_c.o
> > crt1_s.o: file not recognized: File format not recognized
> > *** Error code 1
>
> Try putting the TARGET= and TARGET_ARCH= on the make command line rather
> than in src.conf. I know the manpage says you can put them in src.conf,
> but I wonder if we've broken that and you're the first person to try
> since then.
When I do this, I get instead:
echo special chroot buildopts DIRPRFX=rescue/rescue/chroot/ >>rescue.conf
echo progs chown >>rescue.conf
echo special chown srcdir /usr/src/rescue/rescue/../../usr.sbin/chown
>>rescue.conf
echo special chown buildopts DIRPRFX=rescue/rescue/chown/ >>rescue.conf
echo ln chown chgrp >>rescue.conf
MAKE=/usr/obj/usr/src/make.i386/bmake
MAKEOBJDIRPREFIX=/usr/obj/amd64.amd64/usr/src/rescue/rescue crunchgen -fq -m
rescue.mk -c rescue.c rescue.conf
crunchgen: make error: cd /usr/src/rescue/rescue/../../bin/cat &&
/usr/obj/usr/src/make.i386/bmake -f /tmp//crunchgen_rescueH6FUZJ -DRESCUE
CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/cat/ loop
crunchgen: make error: echo 'OBJS= 'cat.o
crunchgen: make error: cd /usr/src/rescue/rescue/../../bin/chflags &&
/usr/obj/usr/src/make.i386/bmake -f /tmp//crunchgen_rescueH6FUZJ -DRESCUE
CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/chflags/ loop
crunchgen: make error: echo 'OBJS= 'chflags.o
... and so on for another 400+ lines before it again dies.
Respectfully,
Robert Huff
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: can't build CURRENT/amd64 using 9.3?
Putting TARGET/TARGET_ARCH on the command line didn't help. Adding " -j 1 " to make - did. I am now doing "make buildkernel" with TARGET/TARGET_ARCH on the command line. For installkernel, do I need to use them also, or will it magically know where to look? Respectfully, Robert Huff ___________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: can't build CURRENT/amd64 using 9.3?
roberth...@rcn.com writes: > I am now doing "make buildkernel" with TARGET/TARGET_ARCH on > the command line. For installkernel, do I need to use them also, > or will it magically know where to look? Kernel built. However: huff@>> make installkernel ERROR: No kernel "GENERIC" to install. *** Error code 1 Stop. bmake: stopped in /usr/src *** [installkernel] Error code 1 Stop in /usr/src. huff@>> make TARGET=amd64 TARGET_ARCH=amd64 installkernel ERROR: Please set DESTDIR! *** Error code 1 Stop. bmake: stopped in /usr/src *** [installkernel] Error code 1 Stop in /usr/src. I believe there is a kernel in /usr/obj/amd64.amd64/usr/src/sys/GENERIC, and world in /usr/obj/amd64.amd64/usr/src. How do I make sure these get installed in the right place(s)? Respectfully, Robert Huff ___________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: can't build CURRENT/amd64 using 9.3?
David Wolfskill writes:
> >Kernel built.
> >However:
> >
> > huff@>> make installkernel
> > ERROR: No kernel "GENERIC" to install.
> > *** Error code 1
> > ...
> >I believe there is a kernel in
> > /usr/obj/amd64.amd64/usr/src/sys/GENERIC, and world in
> > /usr/obj/amd64.amd64/usr/src.
> >
> > ...
>
> I believe that the cited message refers to the kernel configuration
> file, which is expected to be in sys/amd64/conf/GENERIC within the
> src hierarchy.
Like this:
huff@>> pwd
/usr/src
huff@>> dir sys/amd64/conf/GENERIC
-rw-rw-r-- 1 root wheel 14594 Oct 23 07:28 sys/amd64/conf/GENERIC
?
Respectfully,
Robert Huff
___________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: can't build CURRENT/amd64 using 9.3?
David Wolfskill writes: > > > I believe that the cited message refers to the kernel configuration > > > file, which is expected to be in sys/amd64/conf/GENERIC within the > > > src hierarchy. > > > >Like this: > > > > huff@>> pwd > > /usr/src > > huff@>> dir sys/amd64/conf/GENERIC > > -rw-rw-r-- 1 root wheel 14594 Oct 23 07:28 sys/amd64/conf/GENERIC > > > >? > > If the "make installkernel" is being done from /usr/src, yes. > > Contents of /etc/make.conf and/or /etc/src.conf may have bearing > on this, as well. No make.conf. src.conf= #KERNCONF="JERUSALEM" KERNCONF="GENERIC" #WITH_LIBICONV_COMPAT="yes" #TARGET=amd64 #TARGET_ARCH=amd64 Robert Huff _______ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: can't build CURRENT/amd64 using 9.3?
Garrett Cooper writes: > The message is telling you (indirectly) that you need to run make > buildworld successfully first? Recapping: Current system: FreeBSD 9.3-RELEASE #0 r268512: Fri Jul 11 03:13:02 UTC 2014 i386 Source tree at CURRENT/r273626. No make.conf. src.conf: KERNCONF=GENERIC TARGET=amd64 TARGET_ARCH=amd64 Build uses this script: #! /bin/sh cd /usr/src if [ -f buildworld.log ] then rm buildworld.log fi chflags -R noschg /usr/obj/* rm -rf /usr/obj make cleandir date > ./buildworld.time make -j 1 TARGET=amd64 TARGET_ARCH=amd64 buildworld > ./buildworld.log 2>&1 tail -n 50 /usr/src/buildworld.log | sendmail huff Build log at "http://users.rcn.com/roberthuff/bl.gz"; So: is that or is it not a valid world build? Respectfully, Robert Huff ___________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: can't build CURRENT/amd64 using 9.3?
Fixed by scrubbing 9.3 and installing 10.1-RC3, which solved a couple of other issues. Respectfully, Robert Huff ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
What is xmmintrin.h, and why aren't ports finding it?
Chris H writes: > Working on a recent 11-CURRENT install > (11-CURRENT #1 amd64 r274134 Nov 5 12:56:14 PST 2014) > svn info /usr/ports Revision: 372176 > > Given the above, and the fact that I have installed lang/gcc-48. > Is there any reason that any port wanting to include xmmintrin.h > fails to find it? Even though dmesg && messages reflects the fact > that gcc48 is included within my $PATH? Start by looking at: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190669 Respectfully, Robert Huff _______ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFT: Please help testing the llvm/clang 3.5.0 import
Dimitry Andric writes:
> >- Could a "MK_CLANG_ALL_TARGETS" or something similar option be
> > added to src.opts.mk to fine tune this process for those of us who
> > don't want to build a cross-compile toolchain every iteration for our
> > target MACHINE/MACHINE_ARCH?
>
> I would be fine with something like this, as long as it is turned off by
> default, or if it is only used for the bootstrap stages. It is actually
> an extremely useful feature of clang that you can target multiple
> architectures with one compiler binary.
Point of information: this seems useful for developers, and
(almost entirely) useless for everyone else. Are there other
cohorts that want this badly?
If that's correct, and there's a simple switch for
configuration ... why should this default to what's useful for the
(much?) smaller number of people? About what am I ignorant?
Curiously,
Robert Huff
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
questions re updating to -CURRENT
Hello: I finally get to update a system from: FreeBSD 11.0-RC2 #0 r304729: Wed Aug 24 06:59:03 UTC 2016 amd64 to -CURRENT. After reading src/UPDATING, I understand everything (I think) _except_: 20170311: The old drm (sys/dev/drm/) drivers for i915 and radeon have been removed as the userland we provide cannot use them. The KMS version (sys/dev/drm2) supports the same hardware. I assume the new kernel bits will be automatically built and installed. Are there any changes I need to make elsewhere, e.g. loader,conf or ports? Also: as part of the "safest in-place upgrade" ... how do rm -rf /usr/obj/* and make cleanworld differ? Respectfully, Robert Huff _______ 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: questions re updating to -CURRENT
Jakub Lach writes: > Are you sure you are not using drm2 already? I would check > with kldstat. Ckecked; it's there. > The message in UPDATING is about removing > old code from the tree. Maybe ... but this is one of those things that (in my experience) either Just Work or Go Horribly Wrong. The latter is not nearly as much fun as it says in the brochure. Respectfully, Robert Huff ___________ 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"
buildkernel fails for rev 326557
# Packet tunnel. device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device firmware# firmware assist module # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support options USB_DEBUG # enable debug msgs device uhci# UHCI PCI->USB interface device ohci# OHCI PCI->USB interface device ehci# EHCI PCI->USB interface (USB 2.0) device xhci# XHCI PCI->USB interface (USB 3.0) device usb # USB Bus (required) device ukbd# Keyboard device umass # Disks/Mass storage - Requires scbus and da # Sound support device sound # Generic sound driver (required) device snd_cmi # CMedia CMI8338/CMI8738 device snd_csa # Crystal Semiconductor CS461x/428x device snd_emu10kx # Creative SoundBlaster Live! and Audigy device snd_es137x # Ensoniq AudioPCI ES137x device snd_hda # Intel High Definition Audio device snd_ich # Intel, NVidia and other ICH AC'97 Audio device snd_via8233 # VIA VT8233x Audio # MMC/SD device mmc # MMC/SD bus device mmcsd # MMC/SD memory card device sdhci # Generic PCI SD Host Controller # VirtIO support device virtio # Generic VirtIO bus (required) device virtio_pci # VirtIO PCI device device vtnet # VirtIO Ethernet device device virtio_blk # VirtIO Block device device virtio_scsi # VirtIO SCSI device device virtio_balloon # VirtIO Memory Balloon device # HyperV drivers and enhancement support device hyperv # HyperV drivers # Xen HVM Guest Optimizations # NOTE: XENHVM depends on xenpci. They must be added or removed together. options XENHVM # Xen HVM kernel infrastructure device xenpci # Xen HVM Hypervisor services driver # VMware support device vmx # VMware VMXNET3 Ethernet # Netmap provides direct access to TX/RX rings on supported NICs device netmap # netmap(4) support # The crypto framework is required by IPSEC device crypto # Required by IPSEC ___ 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"
/usr/obj is 11GB huge on FreeBSD 12-current
Wolfram Schneider writes: > I upgraded a machine from 11-stable to 12-current. The /usr/obj tree > is now 11GB huge: > > FreeBSD 12-current > $ du -hs /usr/obj > 11G /usr/obj > > on FreeBSD 11-stable it was less the size: > $ du -hs /usr/obj > 5.6G /usr/obj Mine - also 12-current - reports 7.6G. May we see your kernel config file, src.conf, and make.conf? Respectfully, Robert Huff ___________ 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: evdev broken
Shawn Webb writes:
> > > > It looks like evdev support in the kernel is broken.
> > > > sys/dev/kbdmux/kbdmux.c contains various unresolved symbols to
> > > > different evdev-related symbols.
> > > >
> > > > I have the following options in my kernel config:
> > > >
> > > > options EVDEV_SUPPORT
> > > > options EVDEV_DEBUG
> > > > options UINPUT_DEBUG
> > >
> > > Did you add "device evdev"?
> >
> > Good catch! I did not. Adding now and I'll report back when
> > buildkernel finishes.
>
> That did the trick. Thanks!
>
> Seems like evdev doesn't have a manpage, which is why I didn't
> know to include it in my kernel config.
On a system running:
FreeBSD 12.0-CURRENT #0 r326723: Sat Dec 9 12:30:04 EST 2017 amd64
there is a man page, in section 4x.
That's the good news.
The bad news is I see no mention of needing to add anything to
the kernel; it's presented as a Xorg input device.
Reported as
"https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224793";.
Respectfully,
Robert Huff
___
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"
Unable to unsubscribe from freebsd-current@FreeBSD.org
Hi, this is the Mlmmj program managing the mailing list. You were unable to be unsubscribed from the list because you are not subscribed. If you are receiving messages, perhaps a different email address is subscribed. To find out which address you are subscribed with, refer to the message welcoming you to the list, or look at the envelope "Return-Path" header of a message you receive from the list.
Information for freebsd-current@FreeBSD.org
Hi, this is the Mlmmj program managing the mailing list. Here is some information about the list. You can subscribe to the following versions: - The normal version: Every time a post is sent to the list, subscribers receive a copy of it. Subscribe by emailing . - The digest version: Subscribers receive multiple posts in a single mail message, at regular intervals, or when a lot of posts have accumulated. Subscribe by emailing . - The no-mail version: Subscribers do not receive any posts to the list. This means, though, they are able to post to a list which only subscribers may post to, while they follow the list using a web archive or another subscribed email address. Subscribe by emailing . Unsubscribe by emailing . Posts are made by emailing . However, only subscribers may post to the list. The list also has access rules which may affect who can post and which posts are moderated. Subscribers can retrieve message number N from the list's archive by sending a message to (change the N to the number of the desired message). You can retrieve the frequently asked questions document for the list by sending a message to . To contact the list owner, send a message to .
FreeBSD 13-RC1 PVSCSI install error with VMware
Hello, A quick feedback related to VMware install of FreeBSD 13-RC1 with PVSCSI drive. At the end of the install it fails with the following error: https://e.pcloud.link/publink/show?code=XZBzIkZS2Sx31RK3k0L91Hz4I8p70F82iHV Is it planned to be fixed before release ? Regards, Fabien ___ 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: PAM module for loading ZFS keys on login
On September 5, 2021 4:54:26 PM GMT+03:00, Eric McCorkle wrote: >All, > >This patch creates a new PAM module that will load a ZFS key upon a >successful login: https://reviews.freebsd.org/D31844. It will use the >user's auth token as the key argument to loading a ZFS encryption key on >a user-specific ZFS data set. There's already an upstream module which I've attached to the build in https://reviews.freebsd.org/D28018 Any particular reason to write a custom one?
Re: Files in /usr/share/misc
On 2021-01-24 21:35:40 (+0800), mj-mailingl...@gmx.de wrote: - some FreeBSD project related files, like: bsd-family-tree.dot, committers-*.dot, organization.dot These would better be part of the documentation. BTW, on 12.x they are out of date: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251701 I think we've never bothered merging those to older stable branches because there's not really any point. It might be worth doing so just before a release or something but there's very little benefit. - development(?) related files, like: pci_vendors, scsi_modes, usb_hid_usages, usbdevs, windrv_stub.c I don't know if these files are used during build-/runtime E.g. pci_vendors is used by pciconf(8) and windrv_stub.c is used by ndiscvt(8). I'm sure the others are used by similar utilities that escape my memory. - some files which are used during (build-?/)runtime: magic, magic.mgc, termcap, termcap.db Shouldn't these be in a more specific place? They are pretty static, so the "var" part in /var/db does not fit, but services.db is located there, too. The magic* files are used by file(1). See termcap(5) for the others. - is the fonts folder in base, or did some port create it? I'm not sure. Hah. I like the comment in hier(7) about this directory. :-) Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises ___________ 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: Getting /usr/src to match specific git hash?
> How cat one track multiple branches with git without keeping entirely > separate trees? There are multiple possibilities here and it is not clear which you are hoping for. A) You could be trying to avoid having two separate .git copies around, each also with checked-out material. (2 separate deep clones.) B) You could be trying to avoid having 1 .git with two directories trees for checkouts. (One deep clone with an added worktree, for example.) C) You could be trying to have one .git copy and only one directory tree with only one checkout at a time. (In some contexts, this sort of thing might involve considerable time and I/O for switching the content of the directory tree to be the checkout of a different branch. main vs. stable/13 now vs. 3 years from now might be different.) (One deep clone and no additional worktrees.) D) Sort of like (A) but using 2 Shallow Clones, one per branch. (This uses somewhat more space than (C), but not a lot more.) (2 separate shallow clones in separate directories, one for each branch.) My guess from your wording is that you are after (C). I presume no local modifications/patches and do not cover how to handle having such. The command sequences shown would destroy local changes. It is not clear if such matches what you are after or not. I presume below /usr/src/ use for where the clone was put. It also presumes the fetch status is recent enough to contain the commit that you want to use. For building main : # cd /usr/src # git switch --discard-changes main # git fetch freebsd# if advancing # git merge --ff-only freebsd/main # if advancing # . . . vs. for building stable/13 : # cd /usr/src # git switch --discard-changes stable/13 # git fetch freebsd # if advancing # git merge --ff-only freebsd/stable/13 # if advancing # . . . In the above the commit is implicit as the HEAD for the branch named. There is also being more explicit about the commit that you want (branch implicit): # cd /usr/src # git fetch freebsd # if advancing # git reset --hard 08b8197a74 # use appropriate hashid # . . . This "reset --hard" command produces a "detached HEAD" notice that you can either ignore --or you can then create a local branch that uses that HEAD: # git checkout -b NEW_BRANCH_NAME For reference, from my context: # du -sAm /usr/fbsd/main-src/ /usr/fbsd/main-src/.git 2487/usr/fbsd/main-src/ 1379/usr/fbsd/main-src/.git So 2487 would estimate (C) as things are now for main or stable/13 . 2487-1379==1108 for the implicit, primary worktree that goes with the clone. A additional worktree tied to the above: # du -sAm /usr/fbsd/mm-src/ 1108/usr/fbsd/mm-src/ So 2487+1108 == 3595 total using the additional worktree, i.e., (B). Just for reference for how much space (D) takes: # git clone -o freebsd --depth 1 -b main https://git.freebsd.org/src.git /usr/fbsd/main-shallow Cloning into '/usr/fbsd/main-shallow'... remote: Enumerating objects: 88695, done. remote: Counting objects: 100% (88695/88695), done. remote: Compressing objects: 100% (76042/76042), done. remote: Total 88695 (delta 18867), reused 51008 (delta 9483), pack-reused 0 Receiving objects: 100% (88695/88695), 258.57 MiB | 9.14 MiB/s, done. Resolving deltas: 100% (18867/18867), done. Updating files: 100% (85161/85161), done. # du -sAm /usr/fbsd/main-shallow/ /usr/fbsd/main-shallow/.git 1378/usr/fbsd/main-shallow/ 271 /usr/fbsd/main-shallow/.git (The .git is branch specific only.) So about 2*1378 == 2756 total to also have a separate one for stable/13 in, say, /usr/fbsd/stable-13-shallow/ . === 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: Getting /usr/src to match specific git hash?
On 2021-Jan-24, at 23:37, Mark Millard wrote: > >> How cat one track multiple branches with git without keeping entirely >> separate trees? > > There are multiple possibilities here and it is not > clear which you are hoping for. > > A) You could be trying to avoid having two separate .git > copies around, each also with checked-out material. > > (2 separate deep clones.) > > B) You could be trying to avoid having 1 .git with > two directories trees for checkouts. > > (One deep clone with an added worktree, for example.) > > C) You could be trying to have one .git copy and only > one directory tree with only one checkout at a time. > (In some contexts, this sort of thing might involve > considerable time and I/O for switching the content > of the directory tree to be the checkout of a > different branch. main vs. stable/13 now vs. > 3 years from now might be different.) > > (One deep clone and no additional worktrees.) > > D) Sort of like (A) but using 2 Shallow Clones, one per > branch. (This uses somewhat more space than (C), > but not a lot more.) > > (2 separate shallow clones in separate directories, > one for each branch.) > > My guess from your wording is that you are after (C). > > I presume no local modifications/patches and do not > cover how to handle having such. The command sequences > shown would destroy local changes. It is not clear if > such matches what you are after or not. > > I presume below /usr/src/ use for where the clone was > put. It also presumes the fetch status is recent enough > to contain the commit that you want to use. > > For building main : > > # cd /usr/src > # git switch --discard-changes main > # git fetch freebsd# if advancing > # git merge --ff-only freebsd/main # if advancing > # . . . > > vs. for building stable/13 : > > # cd /usr/src > # git switch --discard-changes stable/13 > # git fetch freebsd # if advancing > # git merge --ff-only freebsd/stable/13 # if advancing > # . . . > > In the above the commit is implicit as the > HEAD for the branch named. > > There is also being more explicit about the > commit that you want (branch implicit): > > # cd /usr/src > # git fetch freebsd # if advancing > # git reset --hard 08b8197a74 # use appropriate hashid > # . . . On review, I forgot that git reset --hard can create untracked files and such. So I add a git clean -f -d to the sequence: # cd /usr/src # git fetch freebsd # if advancing # git reset --hard 08b8197a74 # use appropriate hashid # git clean -f -d # . . . > This "reset --hard" command produces a "detached HEAD" > notice that you can either ignore --or you can then > create a local branch that uses that HEAD: > > # git checkout -b NEW_BRANCH_NAME > > > For reference, from my context: > > # du -sAm /usr/fbsd/main-src/ /usr/fbsd/main-src/.git > 2487 /usr/fbsd/main-src/ > 1379 /usr/fbsd/main-src/.git > > So 2487 would estimate (C) as things > are now for main or stable/13 . > > 2487-1379==1108 for the implicit, primary > worktree that goes with the clone. > > A additional worktree tied to the above: > > # du -sAm /usr/fbsd/mm-src/ > 1108 /usr/fbsd/mm-src/ > > So 2487+1108 == 3595 total using the additional > worktree, i.e., (B). > > Just for reference for how much space (D) takes: > > # git clone -o freebsd --depth 1 -b main https://git.freebsd.org/src.git > /usr/fbsd/main-shallow > Cloning into '/usr/fbsd/main-shallow'... > remote: Enumerating objects: 88695, done. > remote: Counting objects: 100% (88695/88695), done. > remote: Compressing objects: 100% (76042/76042), done. > remote: Total 88695 (delta 18867), reused 51008 (delta 9483), pack-reused 0 > Receiving objects: 100% (88695/88695), 258.57 MiB | 9.14 MiB/s, done. > Resolving deltas: 100% (18867/18867), done. > Updating files: 100% (85161/85161), done. > > # du -sAm /usr/fbsd/main-shallow/ /usr/fbsd/main-shallow/.git > 1378 /usr/fbsd/main-shallow/ > 271 /usr/fbsd/main-shallow/.git > > (The .git is branch specific only.) > > So about 2*1378 == 2756 total to also have a separate one for > stable/13 in, say, /usr/fbsd/stable-13-shallow/ . === 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"
ZFS feature compatibility?
I have a few machines on which I've been hesitant to run 'zpool upgrade' as I'm not sure of the (boot?) implications. They report like this .. imb@toshi:/home/imb> uname -a FreeBSD toshi.auburn.protected-networks.net 14.0-CURRENT FreeBSD 14.0-CURRENT #25 main-eb61de5b78: Fri Jan 22 10:03:02 EST 2021 r...@toshi.auburn.protected-networks.net:/usr/obj/usr/src/amd64.amd64/sys/TOSHI amd64 imb@toshi:/home/imb> zpool status pool: zroot state: ONLINE status: Some supported features are not enabled on the pool. The pool can still be used, but some features are unavailable. action: Enable all features using 'zpool upgrade'. Once this is done, the pool may no longer be accessible by software that does not support the features. See zpool-features(5) for details. Is it safe to upgrade the root pool? imb _______ 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: ZFS feature compatibility?
> On 25. Jan 2021, at 21:31, Michael Butler via freebsd-current > wrote: > > I have a few machines on which I've been hesitant to run 'zpool upgrade' as > I'm not sure of the (boot?) implications. They report like this .. > > imb@toshi:/home/imb> uname -a > FreeBSD toshi.auburn.protected-networks.net 14.0-CURRENT FreeBSD 14.0-CURRENT > #25 main-eb61de5b78: Fri Jan 22 10:03:02 EST 2021 > r...@toshi.auburn.protected-networks.net:/usr/obj/usr/src/amd64.amd64/sys/TOSHI > amd64 > > imb@toshi:/home/imb> zpool status > pool: zroot > state: ONLINE > status: Some supported features are not enabled on the pool. The pool can >still be used, but some features are unavailable. > action: Enable all features using 'zpool upgrade'. Once this is done, >the pool may no longer be accessible by software that does not support >the features. See zpool-features(5) for details. > > Is it safe to upgrade the root pool? > > imb We can not boot from encrypted pool and draid. Rest is all ok. Please note, you may need to update the bootblocks. 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: 13-alpha2 libncurses removal breaks ports build
Builds OK from inside clean install. Which is all I needed this far. Thank you. With kindest regards, Kostya Berger On Sunday, 24 January 2021, 17:53:41 GMT+3, Kostya Berger wrote: OK, building ports against a clean installation of 13.0-ALPHA2 has no problem with ncurses. But devel/glib20 fails for no obvious reason closer to the end of building process... I just wonder: do I need to report this to port maintainers or wait till it settles up somehow? A good deal of ports depend on it. With kindest regards, Kostya Berger On Sunday, 24 January 2021, 01:40:57 GMT+3, Kostya Berger wrote: Hi everyone,I don't seem to find any mentioning in the /usr/ports/UPDATING about how one should handle the removal of libncurses.so.9 from base. Source UPDATING only says:ncurses installation has been modified to only keep the widechar enabled version. Incremental build is broken for that change, so it requires a clean build. If that means to just build all ports anew, then it doesn't work as ports don't seem to incorporate any change related to this one. It would seem default configuration should take into account this, but it doesn't. The ports just use --with-libncurses-prefix=/usr, and there is no ncurses libs found there. This make it skip MOST of the ports I'm using. Working Copy Root Path: /usr/ports URL: https://svn.freebsd.org/ports/head Relative URL: ^/head Repository Root: https://svn.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 562417 Node Kind: directory Schedule: normal Last Changed Author: 0mp Last Changed Rev: 562417 Last Changed Date: 2021-01-23 23:01:38 +0300 (Sat, 23 Jan 2021) With kindest regards, Kostya Berger ___________ 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: ZFS feature compatibility?
> On 25. Jan 2021, at 22:15, mike tancsa wrote:
>
> On 1/25/2021 2:37 PM, Toomas Soome via freebsd-current wrote:
>>
>>> On 25. Jan 2021, at 21:31, Michael Butler via freebsd-current
>>> wrote:
>>>
>>> I have a few machines on which I've been hesitant to run 'zpool upgrade' as
>>> I'm not sure of the (boot?) implications. They report like this ..
>>>
>>> imb@toshi:/home/imb> uname -a
>>> FreeBSD toshi.auburn.protected-networks.net 14.0-CURRENT FreeBSD
>>> 14.0-CURRENT #25 main-eb61de5b78: Fri Jan 22 10:03:02 EST 2021
>>> r...@toshi.auburn.protected-networks.net:/usr/obj/usr/src/amd64.amd64/sys/TOSHI
>>> amd64
>>>
>>> imb@toshi:/home/imb> zpool status
>>> pool: zroot
>>> state: ONLINE
>>> status: Some supported features are not enabled on the pool. The pool can
>>> still be used, but some features are unavailable.
>>> action: Enable all features using 'zpool upgrade'. Once this is done,
>>> the pool may no longer be accessible by software that does not support
>>> the features. See zpool-features(5) for details.
>>>
>>> Is it safe to upgrade the root pool?
>>>
>>> imb
>> We can not boot from encrypted pool and draid. Rest is all ok. Please note,
>> you may need to update the bootblocks.
>>
> last Friday on zoo.freebsd.org <http://zoo.freebsd.org/>, m...@freebsd.org
> <mailto:m...@freebsd.org> and I could not boot
> again because v2 bookmarks were on the boot pool. I had to boot from
> another disk, remove the bookmarks and then boot. This was on RELENG_13
> (stable/13-c256203-g51d73a3e46c)
>
> —Mike
/*
* List of ZFS features supported for read
*/
static const char *features_for_read[] = {
"org.illumos:lz4_compress",
"com.delphix:hole_birth",
"com.delphix:extensible_dataset",
"com.delphix:embedded_data",
"org.open-zfs:large_blocks",
"org.illumos:sha512",
"org.illumos:skein",
"org.zfsonlinux:large_dnode",
"com.joyent:multi_vdev_crash_dump",
"com.delphix:spacemap_histogram",
"com.delphix:zpool_checkpoint",
"com.delphix:spacemap_v2",
"com.datto:encryption",
"com.datto:bookmark_v2",
"org.zfsonlinux:allocation_classes",
"com.datto:resilver_defer",
"com.delphix:device_removal",
"com.delphix:obsolete_counts",
"com.intel:allocation_classes",
"org.freebsd:zstd_compress",
"com.delphix:bookmark_written",
NULL
};
Are you sure you have bootblocks updated? ESP for UEFI boot and freebsd-boot
for BIOS boot.
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: ZFS feature compatibility?
> On 25. Jan 2021, at 23:08, Allan Jude wrote:
>
> On 2021-01-25 16:03, Toomas Soome via freebsd-current wrote:
>>
>>
>>> On 25. Jan 2021, at 22:15, mike tancsa wrote:
>>>
>>> On 1/25/2021 2:37 PM, Toomas Soome via freebsd-current wrote:
>>>>
>>>>> On 25. Jan 2021, at 21:31, Michael Butler via freebsd-current
>>>>> wrote:
>>>>>
>>>>> I have a few machines on which I've been hesitant to run 'zpool upgrade'
>>>>> as I'm not sure of the (boot?) implications. They report like this ..
>>>>>
>>>>> imb@toshi:/home/imb> uname -a
>>>>> FreeBSD toshi.auburn.protected-networks.net 14.0-CURRENT FreeBSD
>>>>> 14.0-CURRENT #25 main-eb61de5b78: Fri Jan 22 10:03:02 EST 2021
>>>>> r...@toshi.auburn.protected-networks.net:/usr/obj/usr/src/amd64.amd64/sys/TOSHI
>>>>> amd64
>>>>>
>>>>> imb@toshi:/home/imb> zpool status
>>>>> pool: zroot
>>>>> state: ONLINE
>>>>> status: Some supported features are not enabled on the pool. The pool can
>>>>> still be used, but some features are unavailable.
>>>>> action: Enable all features using 'zpool upgrade'. Once this is done,
>>>>> the pool may no longer be accessible by software that does not
>>>>> support
>>>>> the features. See zpool-features(5) for details.
>>>>>
>>>>> Is it safe to upgrade the root pool?
>>>>>
>>>>> imb
>>>> We can not boot from encrypted pool and draid. Rest is all ok. Please
>>>> note, you may need to update the bootblocks.
>>>>
>>> last Friday on zoo.freebsd.org <http://zoo.freebsd.org/>
>>> <http://zoo.freebsd.org/ <http://zoo.freebsd.org/>>, m...@freebsd.org
>>> <mailto:m...@freebsd.org> <mailto:m...@freebsd.org
>>> <mailto:m...@freebsd.org>> and I could not boot
>>> again because v2 bookmarks were on the boot pool. I had to boot from
>>> another disk, remove the bookmarks and then boot. This was on RELENG_13
>>> (stable/13-c256203-g51d73a3e46c)
>>>
>>>—Mike
>>
>> /*
>> * List of ZFS features supported for read
>> */
>> static const char *features_for_read[] = {
>>"org.illumos:lz4_compress",
>>"com.delphix:hole_birth",
>>"com.delphix:extensible_dataset",
>>"com.delphix:embedded_data",
>>"org.open-zfs:large_blocks",
>>"org.illumos:sha512",
>>"org.illumos:skein",
>> "org.zfsonlinux:large_dnode",
>>"com.joyent:multi_vdev_crash_dump",
>> "com.delphix:spacemap_histogram",
>>"com.delphix:zpool_checkpoint",
>> "com.delphix:spacemap_v2",
>>"com.datto:encryption",
>>"com.datto:bookmark_v2",
>>"org.zfsonlinux:allocation_classes",
>>"com.datto:resilver_defer",
>>"com.delphix:device_removal",
>>"com.delphix:obsolete_counts",
>>"com.intel:allocation_classes",
>>"org.freebsd:zstd_compress",
>> "com.delphix:bookmark_written",
>>NULL
>> };
>>
>> Are you sure you have bootblocks updated? ESP for UEFI boot and freebsd-boot
>> for BIOS boot.
>>
>> rgds,
>> toomas
>> ___
>> freebsd-current@freebsd.org <mailto:freebsd-current@freebsd.org> mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> <https://lists.freebsd.org/mailman/listinfo/freebsd-current>
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org
>> <mailto:freebsd-current-unsubscr...@freebsd.org>"
>>
>
> Toomas: how difficult do we think it would be to make a ports version of
> the updated boot code, especially for the case of people using the
> openzfs-kmod on 12.2?
>
>
zstd would be interesting…
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: ZFS feature compatibility?
> On 26. Jan 2021, at 00:23, John Kennedy wrote: > >> Thanks, I am new to the EFI world. Does the name now have to be >> BOOTx64.efi ? >> >> root@zoo2:/boot # ls -l /mnt/EFI/freebsd/ >> total 824 >> -rwxr-xr-x 1 root wheel 843776 Nov 21 10:50 loader.efi >> root@zoo2:/boot # > if there is no UEFI bootmanager configured (see man efibootmgr), then (ESP) efi/boot/bootx64.efi is default. with efibootmgr(8), you can configure custom path, such as (ESP) efi/freebsd/loader.efi rgds, toomas > I don't know. This came out of an email thread I had a while ago: > > Date: Thu, 9 Jul 2020 14:18:54 -0700 > From: John Kennedy > To: Kyle Evans > Cc: FreeBSD-STABLE Mailing List > Subject: Re: 12.1p7 no longer boots after doing zpool upgrade -a > > The "new" documentation was here: > > https://wiki.freebsd.org/UEFI > > The older stuff is still mentioned here: > > https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot > > ___________ > 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" ___________ 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: pkg for 14-current
Philip Paeps philip at freebsd.org wrote on Mon Jan 25 21:40:03 UTC 2021 : > The first package build for 14-CURRENT is visible on the mirrors now (as > of a couple of minutes ago). It has been a bit so I tried and it failed for what I tried so I looked at http://pkg.freebsd.org . It reported: QUOTE This is pkg0.tuk.FreeBSD.org - a West Coast, USA mirror for FreeBSD downloads. END QUOTE But nothing with FreeBSD:14 was listed on the page. So I explicitly tried: http://pkg.freebsd.org/FreeBSD:14:i386/ http://pkg.freebsd.org/FreeBSD:14:amd64/ http://pkg.freebsd.org/FreeBSD:14:aarch64/ http://pkg.freebsd.org/FreeBSD:14:powerpc64/ and only the first two were found. I checked those 4 because of previously having looked at https://pkg-status.freebsd.org and what it then reported as building or having been built with a main- prefixed Jail name: main-amd64 , main-i386 , main-arm64 , main-powerpc64 . It looks like the main-arm64 build that is active started before stable/13 was created. It looks like the main-powerpc64 build is older (and it finished) and there will not be powerpc64 materials until a new build is started and it completes. I did not see evidence of Jail names like main-armv7 , main-armv6 , main-mips , or main-mip64 . So I assume that those are not being experimented with yet. === 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: problem building virtualbox-ose-kmod
monochrome monochrome at twcny.rr.com wrote on Tue Jan 26 06:34:23 UTC 2021 : > . . . for quite a while now, maybe over a month . . . > --- memobj-r0drv-freebsd.o --- > /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-5.2.44/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/memobj-r0drv-freebsd.c:887:80: > > error: too few arguments to function call, expected 6, have 5 > int krc = vm_map_protect(pVmMap, AddrStart, AddrEnd, > ProtectionFlags, FALSE); >~~ > ^ > /usr/src/sys/vm/vm_map.h:517:5: note: 'vm_map_protect' declared here > int vm_map_protect(vm_map_t map, vm_offset_t start, vm_offset_t end, > ^ > 1 error generated. > *** [memobj-r0drv-freebsd.o] Error code 1 The change from 5 parameters to 6 parameters is recent: main's 0659df6faddf as of 2021-01-12 23:35:22 + (commit). Its one line description is: QUOTE vm_map_protect: allow to set prot and max_prot in one go END QUOTE It added a "int flags" parameter. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252952 is about: vm_map_protect manual page requires an update after 0659df6faddf . . . (So if there was a problem about a month ago, there may be another problem as well as the above that was something else, the above just happens first now.) Looks like emulators/virtualbox-ose-kmod needs to track the kernel change(s). === 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: problem building virtualbox-ose-kmod
On 1/26/21 9:13 AM, Mark Millard via freebsd-current wrote: monochrome monochrome at twcny.rr.com wrote on Tue Jan 26 06:34:23 UTC 2021 : . . . for quite a while now, maybe over a month . . . --- memobj-r0drv-freebsd.o --- /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-5.2.44/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/memobj-r0drv-freebsd.c:887:80: error: too few arguments to function call, expected 6, have 5 int krc = vm_map_protect(pVmMap, AddrStart, AddrEnd, ProtectionFlags, FALSE); ~~ ^ /usr/src/sys/vm/vm_map.h:517:5: note: 'vm_map_protect' declared here int vm_map_protect(vm_map_t map, vm_offset_t start, vm_offset_t end, ^ 1 error generated. *** [memobj-r0drv-freebsd.o] Error code 1 The change from 5 parameters to 6 parameters is recent: main's 0659df6faddf as of 2021-01-12 23:35:22 + (commit). Its one line description is: QUOTE vm_map_protect: allow to set prot and max_prot in one go END QUOTE It added a "int flags" parameter. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252952 is about: vm_map_protect manual page requires an update after 0659df6faddf . . . (So if there was a problem about a month ago, there may be another problem as well as the above that was something else, the above just happens first now.) Looks like emulators/virtualbox-ose-kmod needs to track the kernel change(s). See solution in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252675 Henri ___________ 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: fsck strange output
Rozhuk Ivan rozhuk.im at gmail.com wrote on Tue Jan 26 00:58:07 UTC 2021 : > This happen on 4 different systems, that: > - based on Ryzen zen/zen+ > - FreeBSD 13 > > 2 systems have ECC that works and show no errors. This is just a example-contexts note: I've seen what appears to be the same type of "UNEXPECTED SOFT UPDATE INCONSISTENCY" issue on an old 2-socket/2-cores-each PowerMac G5 powerpc64 configuration that was running main from after 5cc52631b3b8 . So, in this case, I do not expect that the problem is special to Ryzen or related CPUs. === 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: DRM and Radeon
> On 26. Jan 2021, at 10:18, Marek Zarychta > wrote: > > W dniu 26.01.2021 o 08:58, Graham Perrin pisze: >> On 26/01/2021 07:02, Alexey Dokuchaev wrote: >> > Re: loading drm crashes system >> > … There are known issues with Radeon cards, they were quite well >> > supported a year ago, then something got broken. I've promised to >> > bisect this and find the cause, but there were several >> > syscall-related changes in -CURRENT though the course of the last >> > year, so bisecting just the kernel is not enough (machine won't get >> > to login prompt if the userland does not match), which cripples the >> > process. >> > >> > I still intend to take this quest, just not sure when. :( >> > >> > ./danfe >> Any cards in particular? >> <https://old.reddit.com/r/freebsd/comments/kyoxmc/freebsd_quarterly_status_report_fourth_quarter/gjiw3y3/> >> – whilst I didn't mention Radeon there, for me it _was_ the Radeon story >> that seemed to improve a few months ago. >> <https://bsd-hardware.info/?id=pci:1002-6841-103c-17a9> AMD Thames [Radeon >> HD 7550M/7570M/7650M] > > > > For example old RS880 [Radeon HD 4200]. After deprecation of > graphics/drm-fbsd12.0-kmod I found that it is still supported fine on > 12-STABLE with legacy /boot/kernel/radeonkms.ko from the base. While trying > the driver from graphics/drm-fbsd12.0-kmod I was not able to use this card > with gdm, only startx or x11/slim worked. On 13-ALPHA this card still works > fine with deprecated graphics/drm-legacy-kmod. > > Does gdm start X in specific way? I mean, afaik, gdm is X11 client as any other, so the question would be, how does gdm get Xorg started, what is different compared to startx etc? Might it be about gdm user permissions to access drm devices? my 2cents.. 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: problem building virtualbox-ose-kmod
On 26/01/21 13:29, Dima Panov wrote: Moin! Stefan, please add check for __FreeBSD_version and fill PR or commit it directly with ports-secteam approval. There's a bug report for this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252675 And another one which is marked as a duplicate of this. In the duplicate I posted a patch including the __FreeBSD_version check. Since you just gave approval for that I'll go ahead and commit, it should also be merged to 2021Q1, since it affects 13. -- 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: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes)
get... >> file >> '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/truncate' >> is newer than the target... >> file >> '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/uudecode' >> is newer than the target... >> file >> '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/uuencode' >> is newer than the target... >> file >> '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/xargs' >> is newer than the target... >> >> The lines with these lead to more files being updated and so causing more >> indirect rebuild activity (that cascades). >> >> Many/most/all(?) of these seem to me to be unlikely to actually need to >> contribute to what needs to be rebuilt (just based on being newer). So >> the option to ignore (some of?) them could be useful in making META_MODE >> builds quicker. > > The following from one of the .meta files makes the point that rm use > in the example is unlikely to be important to needing to rebuild, > despite it actually causing a file rebuild. Nor is the specific echo > command listed relevant. Only the "ar" command is: > > # Meta data file > /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/lib/libc++/libc++.a.meta > CMD @echo building static c++ library > CMD @rm -f libc++.a > CMD ar -crsD libc++.a algorithm.o any.o atomic.o barrier.o bind.o charconv.o > chrono.o condition_variable.o condition_variable_destructor.o debug.o > exception.o filesystem/directory_iterator.o filesyste > m/int128_builtins.o filesystem/operations.o functional.o future.o hash.o > ios.o iostream.o locale.o memory.o mutex.o mutex_destructor.o new.o > optional.o random.o random_shuffle.o regex.o shared_mutex.o > stdexcept.o string.o strstream.o system_error.o thread.o typeinfo.o utility.o > valarray.o variant.o vector.o cxxrt_auxhelper.o cxxrt_dynamic_cast.o > cxxrt_exception.o cxxrt_guard.o cxxrt_libelftc_dem_g > nu3.o cxxrt_memory.o cxxrt_stdexcept.o cxxrt_terminate.o cxxrt_typeinfo.o > CWD /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/lib/libc++ > TARGET libc++.a > -- command output -- > building static c++ library > > -- filemon acquired metadata -- > # filemon version 5 > # Target pid 22471 > # Start 1611359217.214996 > V 5 > E 22961 /bin/sh > R 22961 /etc/libmap.conf > R 22961 /var/run/ld-elf.so.hints > R 22961 /lib/libedit.so.7 > R 22961 /lib/libc.so.7 > R 22961 /lib/libncursesw.so.9 > R 22961 /usr/share/locale/C.UTF-8/LC_CTYPE > F 22961 22962 > E 22962 > /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/rm > R 22962 /etc/libmap.conf > R 22962 /var/run/ld-elf.so.hints > R 22962 /lib/libc.so.7 > R 22962 /usr/share/locale/C.UTF-8/LC_CTYPE > D 22962 libc++.a > X 22962 0 0 > . . . > > The timestamp on . . ./tmp/legacy/usr/sbin/rm is not > actually relevant to if libc++.a needs to be rebuilt. > > Of course, the structure also point out the judgment > is specific to understanding the sequence of CMD's > listed above. Only a hack of ignoring, not recording, > or commenting out the filemon lines ending in > /tmp/legacy/usr/sbin/rm would seem to avoid the @rm > handling issue. Such might well have its own risks. > > Some other /tmp/legacy/usr/sbin/* filemon line endings > likely would have a similar status of being a reference > to a file that could(/should?) have its timestamp > relationship not checked. Just for reference for more about the sequencing involved: Looks like in my example various . . ./tmp/legacy/. . ./*bin/ actually are links to files in: /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/bin/ and the later after-install buildworld "Rebuilding the temporary build tree" step leads to the updated dates for files in that area, updated via the code that reports: Linking host tools into /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/bin So the prior installworld leaves updated dates and the linking to those installed files makes . . ./tmp/legacy/. . ./*bin/* have the newer dates show up for the legacy paths as well. In turn the dependency tracking via META_MODE uses the new dates on . . ./tmp/legacy/. . ./*bin/* files to cause rebuilds of more materials than if installworld had not been done. It is not obvious if Bryan D. would find the effort to avoid this worthwhile for the contexts that drive FreeBSD's build environment choices. === 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: FreeBSD-provided .vhd with VirtualBox: gpart I/O errors after resizing the virtual hard disk
Graham Perrin grahamperrin at gmail.com wrote on Mon Jan 25 22:08:53 UTC 2021 : . . . omitted material, including steps 01..13 . . . Your steps 01..13 make no mention of involving growfs as indicated in "man 8 growfs". I'd guess that the growfs step would be after step 8 (recover) and before 10 (show). (FYI: There is also a "man 7 growfs".) > With FreeBSD-provided 'FreeBSD-12.1-RELEASE-amd64.vhd', things seem even > worse. Please see, for example, this screen recording: > > <https://photos.app.goo.gl/4xE6w5uPmwWGPNxD9> > > What's going wrong? > > Is it necessary to boot first from something _other_ than the resized > disk, for things such as gpart recover to proceed without I/O error for > the resized disk? I looked at the screen recording's playback and . . . You have made no mention of the cylinder checksum failure notices or at what stage they first occurred. That might be important. I've no clue if they might be an initial cause of issues vs. them being an effect that might also contribute to later issues when the checksums fail. Unfortunately, it does not look like "man fsck_ffs" covers its cylinder checksum failure handling: ** Phase 5 - Check Cyl groups (At least I presume that phase is related to what the failure notices are reporting.) I'm afraid I'm of no general help but it looked like some extra information might be appropriate --or the man 8 or 7 growfs related activity being involved might avoid later getting cylinder checksum failure notices. I hope this proves of some help, but, if it is not, I'm unlikely to have more information, sorry. === 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: vidcontrol < /dev/console -i active ioctl error
> On 28. Jan 2021, at 01:35, Jesper Schmitz Mouridsen wrote: > > FreeBSD build.freebsd.lan 13.0-ALPHA1 FreeBSD 13.0-ALPHA1 #0 > main-c255938-g7ae27c2d6c4: Thu Jan 14 06:29:55 UTC 2021 > r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 > jesper@build:~ $ su > Password: > root@build:~ # vidcontrol < /dev/console -i active > vidcontrol: getting active vty: Inappropriate ioctl for device > > build is virtualized in bhyve, it happens as well on my pinebook pro. > > This is annoying to sysutils/consolekit2 > > on 12.2 it works (not tested on same HW) > it should work for local console: root@freebsd:/usr/src # vidcontrol -i active < /dev/console 1 may it be your “primary” is actually serial console? 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: zpool upgrade to draid feature: does it require updated zfs boot code ?
On 1/28/21 11:00, Kurt Jaeger wrote: > 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? > 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 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. On my personal laptop, old bootcode would boot pool with draid enabled but not activated just fine (note that the loader.efi on -CURRENT won't boot my P51, which I will start a separate discussion; I used FreeBSD-13.0-CURRENT-amd64-20201231-282381aa53a-255460-memstick.img and fixed my EFI loader and it worked fine with the draid-enabled boot ZFS pool). Hope this helps. Cheers, OpenPGP_signature Description: OpenPGP digital signature
Re: (n244517-f17fc5439f5) svn stuck forever in /usr/ports?
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"
UEFI boot hangs after loading kernel with efi_max_resolution="4k"
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?
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: (n244517-f17fc5439f5) svn stuck forever in /usr/ports?
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"
gcc bootstrap or such outdated references in src.conf and make.conf for 13 and 14
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"
Re: UEFI boot hangs after loading kernel with efi_max_resolution="4k"
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: (n244517-f17fc5439f5) svn stuck forever in /usr/ports?
On 31/01/21 10:35, Hartmann, O. wrote: On Sat, 30 Jan 2021 16:22:50 +0100 Guido Falsi via freebsd-current wrote: 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. We also have running a 14-CURRENT-based webserver with www/apach24. After upgrading from an earlier (working) 14-CURRENT (FreeBSD 14.0-CURRENT #40 main-c256208-geb61de5b787: Fri Jan 22 16:28:09 CET 2021 amd64), the reported phenomenon took place. I also have to admit that after main-c256208-geb61de5b787, the whole system has been rebuilt from a clean /usr/src (otherwise we use -DNO_CLEAN or its WITHOUT_CLEAN equivalent). Hopefully that helps. Performed a full bisect. Tracked it down to commit aa906e2a4957, adding KTLS support to embedded OpenSSL. I filed a bug report about this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253135 Apart from switching to svn:// scheme, another workaround is to build base using WITHOUT_OPENSSL_KTLS. -- 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?
On 01/02/21 04:24, Rick Macklem wrote: Rick Macklem wrote: Guido Falsi wrote: [good stuff snipped] Performed a full bisect. Tracked it down to commit aa906e2a4957, adding KTLS support to embedded OpenSSL. I filed a bug report about this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253135 Apart from switching to svn:// scheme, another workaround is to build base using WITHOUT_OPENSSL_KTLS. Just fyi, when I tested the daemons I have for nfs-over-tls (which use ktls), they acted like things were ok (no handshake problems), but the data ended up on the wire unencrypted (nfs-over-tls doesn't do a SSL_write(), so it depends on ktls to do the encryption). Since these daemons work fine with openssl3 in ports/security/openssl-devel, I suspect the ktls backport is not quite right. I've sent jhb@ email. I was wrong on the above. I did a full buildworld/installworld and the daemons now seem to work with the openssl in head/main. Btw, did anyone try rebuilding svn from sources after doing the system upgrade? (The openssl library calls and .h files definitely changed.) The problem happens with svnlite from base, which should have been rebuilt and reinstalled with the system upgrade. I also tested with ports svn which I did rebuild in poudriere and force reinstalled. So, actually yes I did rebuild it, but I could force a new rebuild just to be sure. -- 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: Setting for displaying utf8 characters on all vt consoles results in panic on 14-CURRENT and 13.0-ALPHA3
> On 1. Feb 2021, at 05:35, Yasuhiro Kimura wrote: > > From: Yasuhiro Kimura mailto:y...@utahime.org>> > Subject: Setting for displaying utf8 characters on all vt consoles results in > panic on 14-CURRENT and 13.0-ALPHA3 > Date: Mon, 01 Feb 2021 11:41:35 +0900 (JST) > >> To display utf8 characters on all vt console I did following settings. >> >> 1. Download GNU Unifont BDF file >> >> (http://unifoundry.com/pub/unifont/unifont-13.0.05/font-builds/unifont-13.0.05.bdf.gz) >> 2. gunzip unifont-13.0.05.bdf.gz >> 3. vtfontcvt unifont-13.0.05.bdf unifont.fnt >> 4. cp unifont.fnt /usr/share/vt/fonts >> 5. Add 'allscreens_flags="-f 8x16 unifont.fnt"' to /etc/rc.conf >> 6. Add 'hw.vga.textmode=0' to /boot/loader.conf.local >> 7. shutdown -r now >> >> On 12.2-RELEASE and 11.4-RELEASE it works as is expected. But on >> 14-CURRENT(man) and 13.0-ALPHA3(stable/13) it result in kernel panic. >> >> Screen shot of 14-CURRENT. >> https://www.utahime.org/FreeBSD/panic.20210201.14-CURRENT.png >> >> 14-CURRENT(main): >> yasu@rolling-vm-freebsd1[1006]% uname -a >> FreeBSD rolling-vm-freebsd1.home.utahime.org 14.0-CURRENT FreeBSD >> 14.0-CURRENT #0 main-n244517-f17fc5439f5: Mon Feb 1 10:55:51 JST 2021 >> ro...@rolling-vm-freebsd1.home.utahime.org:/usr0/freebsd/src/obj/usr0/freebsd/src/git/amd64.amd64/sys/GENERIC >> amd64 >> >> 13.0-ALPHA3(stable/13): >> yasu@rolling-vm-freebsd5[1005]% uname -a >> FreeBSD rolling-vm-freebsd5.home.utahime.org 13.0-ALPHA3 FreeBSD 13.0-ALPHA3 >> #0 stable/13-c256214-g40cb0344eb2: Mon Feb 1 11:30:28 JST 2021 >> ro...@rolling-vm-freebsd5.home.utahime.org:/usr0/freebsd/src/obj/usr0/freebsd/src/git/amd64.amd64/sys/GENERIC >> amd64 > > I submitted this problem to Bugzilla. > > Bug 253147 - Setting for displaying utf8 characters on all vt consoles > results in panic on 14-CURRENT and 13.0-ALPHA3 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253147 > <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253147> > > --- > Yasuhiro Kimura Should be fixed on current now. 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: (n244517-f17fc5439f5) svn stuck forever in /usr/ports?
On 03/02/21 07:16, Hartmann, O. wrote: On Mon, 1 Feb 2021 03:24:45 + Rick Macklem wrote: Rick Macklem wrote: Guido Falsi wrote: [good stuff snipped] Performed a full bisect. Tracked it down to commit aa906e2a4957, adding KTLS support to embedded OpenSSL. I filed a bug report about this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253135 Apart from switching to svn:// scheme, another workaround is to build base using WITHOUT_OPENSSL_KTLS. Just fyi, when I tested the daemons I have for nfs-over-tls (which use ktls), they acted like things were ok (no handshake problems), but the data ended up on the wire unencrypted (nfs-over-tls doesn't do a SSL_write(), so it depends on ktls to do the encryption). Since these daemons work fine with openssl3 in ports/security/openssl-devel, I suspect the ktls backport is not quite right. I've sent jhb@ email. I was wrong on the above. I did a full buildworld/installworld and the daemons now seem to work with the openssl in head/main. Btw, did anyone try rebuilding svn from sources after doing the system upgrade? (The openssl library calls and .h files definitely changed.) Yes, I did, on all boxes and its a pain in the a..., we had to rebuild EVERY port (at least, I did, to avoid further problem). Yesterday, on of our fastes boxes got ready and even with a full rebuild of the system AND a full rebuild of the ports (no poudriere, traditional way via make), the Apache 2.4 webservice doesn't work, and so does subversion not (Firefox reports problems with SSL handshake, subversion is stuck/frozen forever). I will run today another full world build today, hopefully finishing on friday (portmaster -dfR doesn't get everything in line on some ports, I assume). Ass I said a confirmed woraround is building world with WITHOUT_OPENSSL_KTLS defined. -- 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?
On 03/02/21 17:02, John Baldwin wrote: On 2/2/21 10:16 PM, Hartmann, O. wrote: On Mon, 1 Feb 2021 03:24:45 + Rick Macklem wrote: Rick Macklem wrote: Guido Falsi wrote: [good stuff snipped] Performed a full bisect. Tracked it down to commit aa906e2a4957, adding KTLS support to embedded OpenSSL. I filed a bug report about this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253135 Apart from switching to svn:// scheme, another workaround is to build base using WITHOUT_OPENSSL_KTLS. Just fyi, when I tested the daemons I have for nfs-over-tls (which use ktls), they acted like things were ok (no handshake problems), but the data ended up on the wire unencrypted (nfs-over-tls doesn't do a SSL_write(), so it depends on ktls to do the encryption). Since these daemons work fine with openssl3 in ports/security/openssl-devel, I suspect the ktls backport is not quite right. I've sent jhb@ email. I was wrong on the above. I did a full buildworld/installworld and the daemons now seem to work with the openssl in head/main. Btw, did anyone try rebuilding svn from sources after doing the system upgrade? (The openssl library calls and .h files definitely changed.) Yes, I did, on all boxes and its a pain in the a..., we had to rebuild EVERY port (at least, I did, to avoid further problem). Yesterday, on of our fastes boxes got ready and even with a full rebuild of the system AND a full rebuild of the ports (no poudriere, traditional way via make), the Apache 2.4 webservice doesn't work, and so does subversion not (Firefox reports problems with SSL handshake, subversion is stuck/frozen forever). I will run today another full world build today, hopefully finishing on friday (portmaster -dfR doesn't get everything in line on some ports, I assume). oh I tracked the subversion hang down to a bug in serf (an Apache library used by subversion). It would also affect any other software using serf. The serf in ports will also have to be patched. I submitted your patch as a bug report to the serf port: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253214 -- 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: any images for freebsd-current?
On 2/6/21 2:59 PM, Steve Kargl wrote: > Any one aware of where images from freebsd-current? > freebsd.org appears to offer no images. > try https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/13.0/ Also .. have you tried RISC-V ?? -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional _______ 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: any images for freebsd-current?
On 2/6/21 4:02 PM, Steve Kargl wrote: > On Sat, Feb 06, 2021 at 03:33:48PM -0500, Dennis Clarke via freebsd-current > wrote: >> On 2/6/21 2:59 PM, Steve Kargl wrote: >>> Any one aware of where images from freebsd-current? >>> freebsd.org appears to offer no images. >>> >> >> try >> https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/13.0/ >> >> Also .. have you tried RISC-V ?? >> > > 13.0 does not equal 14.0. On my Dell Latitude D530 laptop, > i386-freebsd current ran well up to about Dec 2, 2020. Since > an attempted update in early Jan 2021, I've had nothing but > daily panics and other issues. There are two possibilities: > (1) failing hardware and/or (2) recently introduced i386-freebsd > kernel issues. Installing amd64-freebsd may eliminate one > of the two possibilities. > so install the latest there and then do a buildworld and buildkernel. easy. Dennis ___________ 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"
FYI for main (14: 847dfd2803f6 based) on arm64 (cortex-a72): 2 odd g_vfs_done failures happened
? yes UNALLOCATED I=80660717 OWNER=root MODE=0 SIZE=0 MTIME=Dec 31 16:00 1969 NAME=/usr/fbsd/main-src/contrib/pjdfstest/tests/mkfifo/04.t UNEXPECTED SOFT UPDATE INCONSISTENCY REMOVE? yes UNALLOCATED I=80660718 OWNER=root MODE=0 SIZE=0 MTIME=Dec 31 16:00 1969 NAME=/usr/fbsd/main-src/contrib/pjdfstest/tests/mkfifo/05.t UNEXPECTED SOFT UPDATE INCONSISTENCY REMOVE? yes UNALLOCATED I=80660719 OWNER=root MODE=0 SIZE=0 MTIME=Dec 31 16:00 1969 NAME=/usr/fbsd/main-src/contrib/pjdfstest/tests/mkfifo/06.t UNEXPECTED SOFT UPDATE INCONSISTENCY REMOVE? yes ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? yes SUMMARY INFORMATION BAD SALVAGE? yes BLK(S) MISSING IN BIT MAPS SALVAGE? yes 1484690 files, 32501714 used, 178244320 free (270032 frags, 22246786 blocks, 0.1% fragmentation) * FILE SYSTEM MARKED DIRTY * * FILE SYSTEM WAS MODIFIED * * PLEASE RERUN FSCK * # fsck_ffs -y / ** /dev/gpt/FBSDmacchroot ** Last Mounted on / ** Root file system ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 1484690 files, 32501714 used, 178244320 free (270032 frags, 22246786 blocks, 0.1% fragmentation) * FILE SYSTEM MARKED CLEAN * The context at the time of failure was: # ~/fbsd-based-on-what-freebsd-main.sh merge-base: 847dfd2803f6c8b077e3ebc68e35adff2c79a65f merge-base: CommitDate: 2021-02-03 21:24:22 + 325d7069b027 (HEAD -> mm-src) mm-src snapshot for mm's patched build in git context. 847dfd2803f6 (freebsd/main, freebsd/HEAD, pure-src, main) readelf: do not trucate section name with -W (So based on 847dfd2803f6 from 2021-Feb-03.) The system was built based on -mcpu=cortex-a72 usage and was a non-debug build. I'll also note that I've reported a couple of apparently random powerpc64 non-repeatable problems from a build based on the same 847dfd2803f6 source code. This is the first oddity noted outside that context. # gpart show -pl =>40 2000409184ada0 GPT (954G) 40 409600 ada0p1 (null) (200M) 409640 1740636160 ada0p2 FBSDmacchroot (830G) 174104580058720256 ada0p3 FBSDmacchswp0 (28G) 1799766056 176160768 ada0p4 FBSDmacchswp1 (84G) 197592682424482400 - free - (12G) Note: I have since updated the machine to . . . # ~/fbsd-based-on-what-freebsd-main.sh merge-base: 3acea07c1873b1e4042f4a4fa8668745ee59f15b merge-base: CommitDate: 2021-02-08 19:15:21 + c1845d00f818 (HEAD -> mm-src) mm-src snapshot for mm's patched build in git context. 3acea07c1873 (pure-src) Restore the augmented strlen commentary FreeBSD FBSDmacch 14.0-CURRENT FreeBSD 14.0-CURRENT mm-src-n244686-c1845d00f818 GENERIC-NODBG arm64 aarch64 144 144 and had no troubles doing so. The other systems will all be updated to be based on the 3acea07c1873 source code vintage. === 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"
make release broken?
Any ideas what broke this?
--
>>> Kernel build for GENERIC completed on Tue Feb 9 20:48:05 UTC 2021
--
>>> Kernel(s) GENERIC built in 465 seconds, ncpu: 8, make -j8
--
make -C /usr/src/release obj
make -C /usr/src/release ftp cdrom dvdrom memstick.img mini-memstick.img
`ftp' is up to date.
sh /usr/src/release/i386/mkisoimages.sh -b 14_0_CURRENT_i386_CD
disc1.iso disc1
makefs: cd9660_add_boot_disk: lstat("disc1/boot/cdboot"): No such file
or directory
*** Error code 1
Stop.
make[1]: stopped in /usr/src/release
*** Error code 1
imb
___________
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: cgit: orientation
On 2021-Feb-10, at 12:19, Graham Perrin wrote: > On 10/02/2021 15:46, Rodney W. Grimes wrote: >>> On Tue, Feb 9, 2021 at 5:52 PM Warner Losh wrote: >>> >>>> >>>> On Tue, Feb 9, 2021 at 5:47 PM Graham Perrin >>>> wrote: >>>> >>>>> Given this, for example: >>>>> >>>>> < >>>>> https://cgit.freebsd.org/src/commit/?id=174a7e578a33c01401e33f9bfcc077fc3155251c&h=stable%2F12 >> This link probably came from someone copying it out of the address bar >> from some browswer, the better way to get a link out of a cgit page >> is to copy it from the commit: hash line that looks like: >> >> commit 174a7e578a33c01401e33f9bfcc077fc3155251c (patch) >> >> Right click on the hash and select copy link location. >> > Thanks, I already tried that. Result: again, 'stable' in the URL and > 'stable/12' visible in the page. > > (It was me who originally copied the URL, to demonstrate what can happen if > someone else does so.) > > Please check my sanity. Is it true that this particular commit is _not_ in > stable/12? It is in main. My exploration was as follows but the general behavior is odd to me. Finding where the commit is from for sure . . . Using the id in a range search still says main and lists: Commit message (Expand) Author Age Files Lines * ZFS: fix assertions with INVARIANTS Alan Somers 45 hours 1 -0/+2 * Revert "SO_RERROR indicates that receive buffer overflows should be handled a...Alexander V. Chernikov 47 hours21 -100/+35 * hid: bump HID_ITEM_MAXUSAGES to 8 Warner Losh 47 hours 1 -1/+1 * Don't check compat.linux.emul_path before loading linux(4) Edward Tomasz Napierala 47 hours1 -1/+3 * acpi: limit the AMDI0020/AMDI0010 workaround to an option Warner Losh 47 hours2 -0/+4 * Turn off forgotten multipath debug messages Alexander V. Chernikov 47 hours1 -1/+0 Going to https://cgit.freebsd.org/src/log/?h=stable/12 does not list those. Going to https://cgit.freebsd.org/src/log/?h=stable/13 does not list those. Going to https://cgit.freebsd.org/src/log/ does list those. So: main. Exploring using search to find the commit . . . If one starts at: https://cgit.freebsd.org/src/ and does a rnage search for the id of a stable/12 commit the URL ends up being: https://cgit.freebsd.org/src/log/?qt=range&q=2ac71adb4026c4faade5ac824c6a1b92e2504faf The upper right ends up showing main , not stable/12 . The commit message links also do not specify the branch, for example (copy/pasted): https://cgit.freebsd.org/src/commit/?id=2ac71adb4026c4faade5ac824c6a1b92e2504faf The next link is (copy/pasted): https://cgit.freebsd.org/src/log/?qt=range&q=2ac71adb4026c4faade5ac824c6a1b92e2504faf&ofs=50 Using it again leaves main in the upper right. It appears that first going to https://cgit.freebsd.org/src/log/?h=stable/12 and using links there or using a stable/12 link that happens to be on the page for https://cgit.freebsd.org/src/ is required to get the branch tracking started --and you have to avoid operations like range search that drop that tracking (in what is explicitly displayed). Just having an id and trying to use it is insufficient context for cgit.freebsd.org to identify branches overall. (I do not claim that the "?h=stable/12" notation is completely unique to the purpose. For example the original reports' "&h=stable%2F12" can be generated. I'll ignore the variable notation generally, just showing what I did got as text.) I also explored some what URL's to a stable/12 commit would do https://cgit.freebsd.org/src/commit/?h=stable/12&id=2ac71adb4026c4faade5ac824c6a1b92e2504faf vs. https://cgit.freebsd.org/src/commit/?id=2ac71adb4026c4faade5ac824c6a1b92e2504faf The one without "?h=stable/12&" indicates main in the upper right and copy/paste of the commit link shown also does *not* include "?h=stable/12&" text. Further activity from there continues to not have the text. Of course, if one goes back through one of, say, https://cgit.freebsd.org/src/log/?h=stable/12 or: https://cgit.freebsd.org/src/ one ends up in a context that supplies the "?h=stable/12&". Repeating with the one that has "?h=stable/12&" shows stable/12 in the upper right and copy/ptase of the commit link show does include "?h=stable/12&" text. Further activity from there continues to have the text. Of course if one does a range search for the id, the context is lost. Summary: if you want do see what branch via cgit.freebsd.org use you have to use cgit.freebsd.org in very specific ways. === 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: cgit: orientation
> On 2021-Feb-10, at 07:46, Rodney W. Grimes > wrote: > >> On Tue, Feb 9, 2021 at 5:52 PM Warner Losh wrote: >> >>> >>> >>> On Tue, Feb 9, 2021 at 5:47 PM Graham Perrin >>> wrote: >>> >>>> Given this, for example: >>>> >>>> < >>>> https://cgit.freebsd.org/src/commit/?id=174a7e578a33c01401e33f9bfcc077fc3155251c&h=stable%2F12 > > This link probably came from someone copying it out of the address bar > from some browswer, the better way to get a link out of a cgit page > is to copy it from the commit: hash line that looks like: > > commit 174a7e578a33c01401e33f9bfcc077fc3155251c (patch) > > Right click on the hash and select copy link location. Unfortunately, it turns out to not be that simple. For example, starting from the page for: https://cgit.freebsd.org/src/ Try a range search for: 2ac71adb4026c4faade5ac824c6a1b92e2504faf (which is from stable/12). Then click on the link in the line on the resultant page: * readelf: decode LA48 and ASG_DISABLE feature flags Ed Maste 28 hours1 -0/+2 Then copy the link in the line of the type that you reference: commit 2ac71adb4026c4faade5ac824c6a1b92e2504faf (patch) Result? No indication of which branch: https://cgit.freebsd.org/src/commit/?id=2ac71adb4026c4faade5ac824c6a1b92e2504faf Using the link does not change anything for what is shown in the upper right. All the steps reported "main" in the upper right. What happens depends on which path through got you to that point. Some places do generate URLs that have branch references. Other places do not. Some places preserve branch references in a URL. But some activities do not. >>>>> >>>> >>>> ? with 'stable' in the URL and 'stable/12' visible in the page ? how >>>> would a reader know that the commit was to main (not stable/12)? >>>> >>>> Is there scope to make improved use of cgit, or is this a limitation of >>>> cgit? >>>> >>> >>> There's a pulldown in the upper right corner that says 'stable/12' though >>> it took me a while to find it as my eyes glided over it a couple of times. >>> >> >> But that is due to the stable%2F12 in the URL... W/o it, it's no good. >^^ extra word? > I think you meant to say "It is good". I expect Warner was referring to with "no good" was it saying "main" in the upper right when what was being looked at was from stable/12 after it was branched (or some other such mis-matched example) and that he was indicating that the mismatches are misleading, especially if one does not know to expect them. Part of the issue is that nothing else on the commit page indicates which branch(es) the commit is on, so it is easy to read too much into the only branch name shown. === 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: loader/boot fonts are painfully small (again)
> On 11. Feb 2021, at 23:21, Yuri Pankov wrote: > > Lenovo P51 laptop, 15'' 4k (3840x2160) display. > > Booting from the latest available current snapshot (20210107), fonts > were at least readable; updating to the latest bits (manually installing > new loader as well) made them really small -- terminal size reported by > stty is 480x135. > It is a issue about not so good automatic font size setup. The original code was using 80x24 terminal as base, it was complained it did end up with too large fonts, so I did pick uefi terminal size as base (see output from mode command), but thats also not perfect. Till better solution, right now the option is to set font manually (screen.font variable). > I have also noticed large delays between different loader screens, > probably caused by very slow screen blanking given the terminal size? yes, it definitely needs boost.There are few things we can do about it. 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: upgrade stable/12 -> stable/13 zfs + boot partition Mediasize 64K
On 2/11/21 8:57 PM, Gary Palmer wrote: > On Thu, Feb 11, 2021 at 05:34:40PM -0700, Russell L. Carter wrote: >> Greetings, >> >> I really want to jump from stable/12 to stable/13 but one thing is >> causing a hesitancy. And that is, my main raidz2 system has >> a system boot zfs mirror pair that has boot partition size >> (Mediasize) of 64K, and when I tried to zpool upgrade that pool a >> year or 2 ago I got some scary message something like "boot >> partition size is not large enough". I asked about this on the >> lists but never received an answer. So, laziness required me >> to ignore the problem and not zpool upgrade any of my 15 or so >> zpools in the interim. >> >> A few weeks ago I tried to make buildworld/installworld upgrade >> 12->13 but the boot failed in the mounting filesystems phase with it >> couldn't find a bootable target. So after restoring 12 I decided >> to wait a bit. In the interim I have upgraded every zpool but that >> one system pool. All the other freebsd-boot partitions have a size >> of 512K. >> >> So what is the current advice? Is a freebsd-boot partition size >> of 64K laughably obsolete, and I should get with the program and >> repartition those disks, or can I march blindly into the upgrade? >> >> I guess I just want to understand where these sizes are going in >> the future. > > Most layouts put a swap partition after the boot partition. If > that is the case for you also, if you can disable the swapping to the > swap partition you can probably increase boot and reduce swap size > pretty easily. Otherwise you're probably going to have to split > the mirror, repartition one drive, rebuild the mirror, reboot onto > that drive and then do the same to the other drive. I've done it > before on a headless system in a remote DC. With planning it's > perfectly doable. I think I built a test vm in VirtualBox and > made sure it all worked on that before trying it for real. > The process is trivial with ZFS and a mirror setup. No need to reboot. Think of the mirror as a "left" and "right" side. If you have a three way mirror than you are singing in the rain. Regardless just break the mirror. Do whatever you want with the disks that are now free and clear of the previous mirror config. Use gpart and set them up with whatever you need. Then attach the disk(s) back onto the mirror and wait for the thing to re-silver. Run a scrub if you want. Depends on the size. Just know that a large amount of storage ( more than 64T ) will take a long time to scrub and for that matter a long time to re-silver. Maybe a day. Once everything is re-synced as a mirror just repeat the process on the other side of the mirror. No need to reboot until you feel like testing the whole show. This sort of situation is also a good reason to use three way mirrors with a hot spare pool. When possible. Makes the whole process entirely worry free and nothing more than a cup of coffee to ponder it. For the sake of details what does "gpart show" report? Dennis Clarke ___ 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"
New Optane AIC does not show up in FreeBSD until . . . ?
I plugged in a new Optane and booted FreeBSD on the ThreadRipper 1950X system but FreeBSD did not show the drive in gpart show. (It is unique by size in the context and so would be hard to miss for anything that listed sizes. Lack of listing a size would also stand out.) So I did what I've done in the past: shutdown FreeBSD, boot Windows 10, go to its disk management utility, answer its prompt for MBR vs. GPT for the new device (picking GPT), shutdown Windows 10. Then boot FreeBSD again --and the new drive shows up. Is there a way to avoid the round trip through Windows 10 (or any other such round trip going outside FreeBSD)? I'm just curious if I've missed something: My work around enables my activity. FYI, FreeBSD based on main 3acea07c1873 : # ~/fbsd-based-on-what-freebsd-main.sh merge-base: 3acea07c1873b1e4042f4a4fa8668745ee59f15b merge-base: CommitDate: 2021-02-08 19:15:21 + c1845d00f818 (HEAD -> mm-src) mm-src snapshot for mm's patched build in git context. 3acea07c1873 (pure-src) Restore the augmented strlen commentary FreeBSD FBSDFHUGE 14.0-CURRENT FreeBSD 14.0-CURRENT mm-src-n244686-c1845d00f818 GENERIC-NODBG amd64 amd64 144 144 But this is not a new thing, more of a "still true" thing. === 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: New Optane AIC does not show up in FreeBSD until . . . ?
On 2021-Feb-13, at 16:40, Warner Losh wrote: > Are you aware of gpart create? > > Warner >From which I derive that I had an implicit, incorrect assumption that gpart show would in some way list everything available that gpart could manipulate (including for use in creation). So I need to find such a drive another way, something I was not even trying to do. That answers my question. Thanks. Mark >> On Sat, Feb 13, 2021, 4:41 PM Mark Millard via freebsd-current >> wrote: >> I plugged in a new Optane and booted FreeBSD on the >> ThreadRipper 1950X system but FreeBSD did not show >> the drive in gpart show. (It is unique by size in the >> context and so would be hard to miss for anything >> that listed sizes. Lack of listing a size would also >> stand out.) >> >> So I did what I've done in the past: shutdown FreeBSD, >> boot Windows 10, go to its disk management utility, >> answer its prompt for MBR vs. GPT for the new device >> (picking GPT), shutdown Windows 10. Then boot FreeBSD >> again --and the new drive shows up. >> >> Is there a way to avoid the round trip through >> Windows 10 (or any other such round trip going >> outside FreeBSD)? I'm just curious if I've missed >> something: My work around enables my activity. >> >> >> FYI, FreeBSD based on main 3acea07c1873 : >> >> # ~/fbsd-based-on-what-freebsd-main.sh >> merge-base: 3acea07c1873b1e4042f4a4fa8668745ee59f15b >> merge-base: CommitDate: 2021-02-08 19:15:21 + >> c1845d00f818 (HEAD -> mm-src) mm-src snapshot for mm's patched build in git >> context. >> 3acea07c1873 (pure-src) Restore the augmented strlen commentary >> FreeBSD FBSDFHUGE 14.0-CURRENT FreeBSD 14.0-CURRENT >> mm-src-n244686-c1845d00f818 GENERIC-NODBG amd64 amd64 144 144 >> >> But this is not a new thing, more of a "still true" >> thing. > === 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: New Optane AIC does not show up in FreeBSD until . . . ?
On 2021-Feb-13, at 17:38, Warner Losh wrote: > On Sat, Feb 13, 2021, 6:36 PM Mark Millard wrote: > > On 2021-Feb-13, at 16:40, Warner Losh wrote: > > > Are you aware of gpart create? > > > > Warner > > From which I derive that I had an implicit, incorrect > assumption that gpart show would in some way list > everything available that gpart could manipulate > (including for use in creation). > > So I need to find such a drive another way, something > I was not even trying to do. > > That answers my question. Thanks. > > Nvmecontrol devlist is a good place to start. Or sysctl kern.disks > Turns out that sysctl kern.disks would not have directly helped on its own because the drive was replacing another: the set of names listed would be unchanged: # sysctl kern.disks kern.disks: da6 da5 cd0 da4 da3 da2 da1 da0 ada2 ada1 ada0 nvd5 nvd4 nvd3 nvd2 nvd1 nvd0 (I'd know it was one of the nvd*'s.) So for sysctl kern.disks use I'd need to look for a name (a nvd*) that gpart show had not listed and that would be the new one. So: use both commands. Good to know. nmvecontrol devlist does get into nvmeN/nvmeNns1 vs. the nvdN names listed in gpart show, and so for more complicated name matching. But, again, involves finding an unmatched name. In the actual context, the type and size happened to be unique and that would have made identification easy from nmvecontrol devlist output. Thanks for the notes, Mark > > >> On Sat, Feb 13, 2021, 4:41 PM Mark Millard via freebsd-current > >> wrote: > >> I plugged in a new Optane and booted FreeBSD on the > >> ThreadRipper 1950X system but FreeBSD did not show > >> the drive in gpart show. (It is unique by size in the > >> context and so would be hard to miss for anything > >> that listed sizes. Lack of listing a size would also > >> stand out.) > >> > >> So I did what I've done in the past: shutdown FreeBSD, > >> boot Windows 10, go to its disk management utility, > >> answer its prompt for MBR vs. GPT for the new device > >> (picking GPT), shutdown Windows 10. Then boot FreeBSD > >> again --and the new drive shows up. > >> > >> Is there a way to avoid the round trip through > >> Windows 10 (or any other such round trip going > >> outside FreeBSD)? I'm just curious if I've missed > >> something: My work around enables my activity. > >> > >> > >> FYI, FreeBSD based on main 3acea07c1873 : > >> > >> # ~/fbsd-based-on-what-freebsd-main.sh > >> merge-base: 3acea07c1873b1e4042f4a4fa8668745ee59f15b > >> merge-base: CommitDate: 2021-02-08 19:15:21 + > >> c1845d00f818 (HEAD -> mm-src) mm-src snapshot for mm's patched build in > >> git context. > >> 3acea07c1873 (pure-src) Restore the augmented strlen commentary > >> FreeBSD FBSDFHUGE 14.0-CURRENT FreeBSD 14.0-CURRENT > >> mm-src-n244686-c1845d00f818 GENERIC-NODBG amd64 amd64 144 144 > >> > >> But this is not a new thing, more of a "still true" > >> thing. > > === 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: HEADSUP: math is broken with clang and optimization
> On Mon, Feb 15, 2021 at 01:03:36PM -0800, Steve Kargl wrote: > > On Mon, Feb 15, 2021 at 12:49:13PM -0800, Steve Kargl wrote: > > > On Sun, Feb 14, 2021 at 01:59:58PM -0800, Steve Kargl wrote: > > > > Just a headsup for anyone doing numerical work with > > > > FreeBSD-current. clang with optimization of -O1 or > > > > higher produces wrong results. Testing 1 million > > > > complex values of ccoshf and limiting |z| < 20, > > > > shows > > > > > > > > > > This is either an in-ling bug or discarding a cast issue. > > > With everything in the same file so clang has dp_ccosh > > > available to it when compiling main. > > > > > > > Code builds and works as expected with gcc 10.2and > > gcc 11.0.0. > > > > Can't find a list of options that is equivalent to -O1, > so cannot test various optimizations. > > Notice that -march=i686 gives the wrong results and > -march=core2 gives the correct result. Trying -march=i686 > -msse -msse2 gives the correct result. It seems that > clang does not understand how the x87 (on i585-freebsd). I tried looking around some and got the following that might be contributing: variations in __FLT_EVAL_METHOD__ used . . . # cc -target i386-unknown-freebsd14.0 -march=i686 -O2 -x c /dev/null -dM -E | egrep "(FLT_EVAL_METHOD|ILP32|LP64)" #define _ILP32 1 #define __FLT_EVAL_METHOD__ 2 #define __ILP32__ 1 # cc -target i386-unknown-freebsd14.0 -march=core2 -O2 -x c /dev/null -dM -E | egrep "(FLT_EVAL_METHOD|ILP32|LP64)" #define _ILP32 1 #define __FLT_EVAL_METHOD__ 0 #define __ILP32__ 1 # cc -target x86_64-unknown-freebsd14.0 -march=core2 -O2 -x c /dev/null -dM -E | egrep "(FLT_EVAL_METHOD|ILP32|LP64)" #define _LP64 1 #define __FLT_EVAL_METHOD__ 0 #define __LP64__ 1 FYI: It does not look like FreeBSD's /usr/include/x86/float.h matches all the detail: #if __ISO_C_VISIBLE >= 1999 #ifdef __LP64__ #define FLT_EVAL_METHOD 0 /* no promotions */ #else #define FLT_EVAL_METHOD (-1)/* i387 semantics are...interesting */ #endif . . . #endif For reference: # cc -target i386-unknown-freebsd14.0 -O2 -x c /dev/null -dM -E | egrep "(FLT_EVAL_METHOD|ILP32|LP64)" #define _ILP32 1 #define __FLT_EVAL_METHOD__ 2 #define __ILP32__ 1 # cc -target x86_64-unknown-freebsd14.0 -O2 -x c /dev/null -dM -E | egrep "(FLT_EVAL_METHOD|ILP32|LP64)" #define _LP64 1 #define __FLT_EVAL_METHOD__ 0 #define __LP64__ 1 # cc -target x86_64-unknown-freebsd14.0 -march=i686 -O2 -x c /dev/null -dM -E | grep FLT_EVAL_METHOD | sort error: unknown target CPU 'i686' note: valid target CPU values are: nocona, core2, penryn, bonnell, atom, silvermont, slm, goldmont, goldmont-plus, tremont, nehalem, corei7, westmere, sandybridge, corei7-avx, ivybridge, core-avx-i, haswell, core-avx2, broadwell, skylake, skylake-avx512, skx, cascadelake, cooperlake, cannonlake, icelake-client, icelake-server, tigerlake, knl, knm, k8, athlon64, athlon-fx, opteron, k8-sse3, athlon64-sse3, opteron-sse3, amdfam10, barcelona, btver1, btver2, bdver1, bdver2, bdver3, bdver4, znver1, znver2, x86-64 # cc -v FreeBSD clang version 11.0.1 (g...@github.com:llvm/llvm-project.git llvmorg-11.0.1-0-g43ff75f2c3fe) Target: x86_64-unknown-freebsd14.0 Thread model: posix InstalledDir: /usr/bin === 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: New Optane AIC does not show up in FreeBSD until . . . ?
On 2021-Feb-16, at 00:48, Harry Schmalzbauer wrote: > Am 14.02.2021 um 02:36 schrieb Mark Millard via freebsd-current: >> On 2021-Feb-13, at 16:40, Warner Losh wrote: >> >>> Are you aware of gpart create? >>> >>> Warner >> From which I derive that I had an implicit, incorrect >> assumption that gpart show would in some way list >> everything available that gpart could manipulate >> (including for use in creation). > > 'geom disk status' is my first choice for such a case. > Even nvd(4) should show up I think, nda(4) just changes the access path, not > geom(8) integration, afaik. Looks like "geom disk status" and "geom disk list" both list "disks" that do not have a partition scheme and spans the nvd* disks. (I only tested destroying a partition scheme on an ada* and then seeing what was displayed. I do not want to destroy such on any nvd* as stands.) "geom disk list" shows Mediasize and descr, which at times could be handy for identification, at least when the pair are unique in the system. Thanks for the alternatives to sysctl kern.disks and to nvmecontrol devlist for making a list to compare to gpart show output in order to find what gpart show does not list (but can manipulate). === 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"
make installworld crashes the system in g_slice_access geom_slice.c:127
Hello, While upgrading from source my 13-CURRENT box from ALPHA1 to BETA1, I got the following crash on make installworld. Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x30 fault code = supervisor read data, page not present instruction pointer = 0x20:0x8034d5b0 stack pointer = 0x28:0xfe00c8204600 frame pointer = 0x28:0xfe00c8204640 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 65294 (fsck_ufs) trap number = 12 panic: page fault cpuid = 1 time = 1613467739 #16 0x8034d5b0 in g_slice_access (pp=0xf80003ca5100, dr=1, dw=0, de=0) at /usr/src/sys/geom/geom_slice.c:127 #17 0x8034e6e4 in g_access (cp=0xf80003c82e00, dcr=, dcr@entry=1, dcw=, dcw@entry=0, dce=dce@entry=0) at /usr/src/sys/geom/geom_subr.c:1042 #18 0x8034698f in g_dev_open (dev=, flags=, fmt=, td=) at /usr/src/sys/geom/geom_dev.c:442 #19 0x80342e46 in devfs_open (ap=0xfe00c82047a0) at /usr/src/sys/fs/devfs/devfs_vnops.c:1290 #20 0x806bb05c in VOP_OPEN_APV (vop=0x80863e20 , a=a@entry=0xfe00c82047a0) at vnode_if.c:436 #21 0x804bef1e in VOP_OPEN (vp=0xf80003cdc000, mode=1, cred=0xf800029d4420, td=0x0, fp=0xf802a7208140) at ./vnode_if.h:220 #22 vn_open_vnode (vp=vp@entry=0xf80003cdc000, fmode=fmode@entry=1, cred=, cred@entry=0xf80002993700, td=, td@entry=0xfe00c8149300, fp=) at /usr/src/sys/kern/vfs_vnops.c:411 #23 0x804bead0 in vn_open_cred (ndp=ndp@entry=0xfe00c8204970, flagp=, flagp@entry=0xfe00c8204a94, cmode=, vn_open_flags=vn_open_flags@entry=0, cred=, fp=0x7) at /usr/src/sys/kern/vfs_vnops.c:318 #24 0x804be6ad in vn_open (ndp=0xf80003ca5100, ndp@entry=0xfe00c8204970, flagp=0xf800029d43c0, flagp@entry=0xfe00c8204a94, cmode=0, fp=0xf800029d4420) at /usr/src/sys/kern/vfs_vnops.c:193 #25 0x804b4983 in kern_openat (td=0xfe00c8149300, fd=, path=, pathseg=, flags=1, mode=) at /usr/src/sys/kern/vfs_syscalls.c:1143 #26 0x8068ea5c in syscallenter (td=0xfe00c8149300) at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:189 (kgdb) frame 16 #16 0x8034d5b0 in g_slice_access (pp=0xf80003ca5100, dr=1, dw=0, de=0) at /usr/src/sys/geom/geom_slice.c:127 127 if ((pp->acw + dw) > 0 && pp2->ace > 0) (kgdb) p pp2 $2 = (struct g_provider *) 0x0 pp2 is null, and pp2->ace crashes the system. Does the above crash pattern rings any bell? My system uses UFS SU+trim on GELI. On reboot, I had to manually run fsck. At the end I did reinstall successfully world from my poudriere server through NFS, since I wasn't sure about the state of the files in /usr/obj... Regards, Ali _______ 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: New Optane AIC does not show up in FreeBSD until . . . ?
On 2021-Feb-16, at 02:22, Harry Schmalzbauer wrote: > Am 16.02.2021 um 11:08 schrieb Mark Millard: >> On 2021-Feb-16, at 00:48, Harry Schmalzbauer wrote: >>> Am 14.02.2021 um 02:36 schrieb Mark Millard via freebsd-current: >>>> On 2021-Feb-13, at 16:40, Warner Losh wrote: >>>> >>>>> Are you aware of gpart create? >>>>> >>>>> Warner >>>> From which I derive that I had an implicit, incorrect >>>> assumption that gpart show would in some way list >>>> everything available that gpart could manipulate >>>> (including for use in creation). >>> >>> 'geom disk status' is my first choice for such a case. >>> Even nvd(4) should show up I think, nda(4) just changes the access path, >>> not geom(8) integration, afaik. > > ... >> Thanks for the alternatives to sysctl kern.disks >> and to nvmecontrol devlist for making a list to >> compare to gpart show output in order to find >> what gpart show does not list (but can manipulate). > > gpart(8) doesn't enumerate disks without any supported partition scheme > present. > You can create new partition schemes with the help of gpart(8), but it's imho > correct not to show them, because 'gpart show' is meant to give information > about (existing) partition schemes - no scheme no info; thus your vanilla > disk is "unknown" to gpart(8). > > I remember that I always thought the geom(8) disk class is kind of hidden - > especially since the man page misses listing DISK in the > "Currently available classes which are aware of geom(8)" section! > > The "show" command was enriched to contain valuable details, such as NAA. > So 'geom disk' turned into one of the most useful mass storage admin > commands. imho. > Maybe somebody should correct the aforementioned man page section and add add > any hint in the SEE ALSO section, because there is no gdisk(8) aequivalent, > like for all other geom classes... > > -harry > > P.S. Put it on my loger-term todo to file a bug report with a proposed man > page diff... Looks like "geom -t" output avoids me having to compare two outputs to find mismatches in the list of names: its output is sufficient to identify the name(s) for drives that do not have the scheme information (and the names of those that do). This at least helps cut down what I have to coordinate, especially when only one device is in question. For example, ada2 in the below has only DISK and one DEV line, not multiple DEV's, no PART line, nor other such: . . . ada0 DISK ada0 ada0 PART ada0s1 ada0s1 DEV ada0 PART ada0s2 ada0s2 DEV ada0 DEV ada1 DISK ada1 ada1 PART ada1p1 ada1p1 DEV ada1 DEV ada2 DISK ada2 ada2 DEV da0DISK da0 da0 PART da0p1 da0p1 DEV da0 PART da0p2 da0p2 LABEL ntfs/VirtMachs ntfs/VirtMachs DEV da0p2 DEV da0 DEV . . . So I can infer that I need a gpart create on ada2 . (Presumes I know from the naming that the device is not analogous to a cd-drive with no media in the drive.) The output does span the nvd* devices. === 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: pkg vs uname troubles after upgrade to 14
Brandon Bergren bdragon at FreeBSD.org wrote on Tue Feb 16 17:29:45 UTC 2021 : > On Tue, Feb 16, 2021, at 10:38 AM, Ronald Klop wrote: > > I normally compile WITHOUT_CLEAN. What is the shortcut to recompile > > uname with the proper version nr and not having to recompiling clang? > > Cleaning and rebuilding only uname does not help. > > Uh, I would drop into a buildenv with "make buildenv" and do the build there > to ensure it's using the toolchain from your world build. > > the kernel version and the base system version are not the same thing. pkg > attempts to install binaries compatible with the base system. > > Are you *sure* you did installworld after rebooting into the new kernel? For > that matter, are you *sure* you have the correct branch checked out in the > first place? Because it's acting as if you are on the wrong branch. There are other reports of a: pkg: Warning: Major OS version upgrade detected. Running "pkg bootstrap -f" recommended problem. The ones that I'm aware of are: Xavier Humbert: https://lists.freebsd.org/pipermail/freebsd-ports/2021-January/120144.html https://lists.freebsd.org/pipermail/freebsd-ports/2021-February/120156.html (It was split across the month boundary for "solved".) Rainer Hurling: https://lists.freebsd.org/pipermail/freebsd-ports/2021-January/120151.html Dewayne Geraghty: https://lists.freebsd.org/pipermail/freebsd-ports/2021-February/120154.html Steve Kargl: https://lists.freebsd.org/pipermail/freebsd-ports/2021-February/120298.html https://lists.freebsd.org/pipermail/freebsd-ports/2021-February/120314.html (The last for Steve K. is about how solved.) But I cannot not tell if there is a common cause or a common solution. === 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: pkg vs uname troubles after upgrade to 14
On 2021-Feb-16, at 11:49, Brandon Bergren wrote: > It looks like there were recently some fixes to release.sh, that just got > backported to 13. I wonder if the problem is the packages themselves being > misbuilt. > > https://cgit.freebsd.org/src/commit/release?h=releng/13.0&id=4689ab1eab624d1a551a5a8f109383ea18eeba20 release/release.sh and release/tools/arm.subr are not used for self-building ports as far as I know. Steve Kargl's example was: self-built pkg, then portmaster, then used portmaster to build the rest of his ports, and not in/for an arm context. release/release.sh would have to contribute as a side effect of its prior use in some way for that sequence, if I understand right. > > On Tue, Feb 16, 2021, at 12:20 PM, Mark Millard wrote: >> There are other reports of a: >> >> pkg: Warning: Major OS version upgrade detected. Running "pkg >> bootstrap -f" recommended === 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"
Is stand/kshim/bsd_kernel.h 's __FreeBSD_version supposed to track main's 13->14 change?
stand/kshim/bsd_kernel.h has its own define of __FreeBSD_version and seems to have last had it changed in the main branch as shown below. Is it as it should be for main 14? It does seem to have skipped being updated for HEAD 12. Last change . . . author Hans Petter Selasky 2020-11-18 13:22:22 + committer Hans Petter Selasky 2020-11-18 13:22:22 + commit a2dd1caade2f9cb829261a42812431781c685d46 (patch) tree466a86138a99f5f6c73c54cd531dbdb9884678c0 /stand/kshim/bsd_kernel.h parent ac8c4a61af5007487eabf882e969dd9768549078 (diff) downloadsrc-a2dd1caade2f9cb829261a42812431781c685d46.tar.gz src-a2dd1caade2f9cb829261a42812431781c685d46.zip Fix build of USB bootloader code by adding checks for _STANDALONE being defined. Currently the USB bootloader code is not part of buildworld. MFC after: 1 week Sponsored by: Mellanox Technologies // NVIDIA Networking Notes Notes: svn path=/head/; revision=367787 Diffstat (limited to 'stand/kshim/bsd_kernel.h') -rw-r--r-- stand/kshim/bsd_kernel.h7 1 files changed, 5 insertions, 2 deletions diff --git a/stand/kshim/bsd_kernel.h b/stand/kshim/bsd_kernel.h index 4dfe307fef0c..89d87121c63e 100644 --- a/stand/kshim/bsd_kernel.h +++ b/stand/kshim/bsd_kernel.h @@ -27,9 +27,12 @@ #ifndef _BSD_KERNEL_H_ #define_BSD_KERNEL_H_ -#define_KERNEL +#if !defined(_STANDALONE) +#error "_STANDALONE is not defined!" +#endif + #undef __FreeBSD_version -#define__FreeBSD_version 110 +#define__FreeBSD_version 130 #include #include === 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"
"grep -rI ... /" vs. processing of /dev/ : should "--exclude-dir /dev" be required in order to avoid /dev/?
I historically on occasion have done something like: # grep -rI ... / in order to find all instances of a text, including in build trees and such. I now find that I need to do something more like (using a more specific example): # grep -rI --exclude-dir /dev '#define.*__FreeBSD_version' otherwise the grep ends up reading from the tty and waits for it. Top shows, for example, 13470 root 220 12848Ki2692Ki ttyin 11 0:00 0.00% grep -rI #define.*__FreeBSD_version / Is this expected? Should I have always been using "--exclude-dir /dev"? What lead to the behavior change? (FYI: The activity is normally as root.) I'll note that I also got a couple of other messages first: grep: /dev/log: Operation not supported grep: /dev/reroot/reroot: Operation not supported by device I do not remember getting these in the past. The issue happens with or without the -I part of the grep command. The context for the above is based on main 3acea07c1873 , or, in more detail, # ~/fbsd-based-on-what-freebsd-main.sh merge-base: 3acea07c1873b1e4042f4a4fa8668745ee59f15b merge-base: CommitDate: 2021-02-08 19:15:21 + c1845d00f818 (HEAD -> mm-src) mm-src snapshot for mm's patched build in git context. 3acea07c1873 (pure-src) Restore the augmented strlen commentary FreeBSD FBSDFHUGE 14.0-CURRENT FreeBSD 14.0-CURRENT mm-src-n244686-c1845d00f818 GENERIC-NODBG amd64 amd64 144 144 === 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: pkg vs uname troubles after upgrade to 14 (lld not rebuilt issue? (X_)LINKER_FREEBSD_VERSION still 13 based?)
On 2021-Feb-16, at 15:37, Mark Millard wrote: > On 2021-Feb-16, at 11:49, Brandon Bergren wrote: > >> It looks like there were recently some fixes to release.sh, that just got >> backported to 13. I wonder if the problem is the packages themselves being >> misbuilt. >> >> https://cgit.freebsd.org/src/commit/release?h=releng/13.0&id=4689ab1eab624d1a551a5a8f109383ea18eeba20 > > release/release.sh and release/tools/arm.subr are not used > for self-building ports as far as I know. Steve Kargl's > example was: self-built pkg, then portmaster, then used > portmaster to build the rest of his ports, and not in/for > an arm context. release/release.sh would have to contribute > as a side effect of its prior use in some way for that > sequence, if I understand right. > >> >> On Tue, Feb 16, 2021, at 12:20 PM, Mark Millard wrote: >>> There are other reports of a: >>> >>> pkg: Warning: Major OS version upgrade detected. Running "pkg >>> bootstrap -f" recommended I think that I found something that might contribute, shown here for my META_MODE build context . . . Builds that do nor force being from scratch tend to: make[1]: "/usr/fbsd/mm-src/Makefile.inc1" line 339: SYSTEM_COMPILER: Determined that CC=cc matches the source tree. Not bootstrapping a cross-compiler. make[1]: "/usr/fbsd/mm-src/Makefile.inc1" line 344: SYSTEM_LINKER: Determined that LD=ld matches the source tree. Not bootstrapping a cross-linker. But in my build environment, after upgrading to 14 and doing multiple updates as 14 has progressed, I find: # ld -v LLD 11.0.1 (FreeBSD llvmorg-11.0.1-0-g43ff75f2c3fe-137) (compatible with GNU linkers) Note the "137". This goes along with: # Meta data file /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/toolchain-metadata.mk.meta CMD @: > toolchain-metadata.mk CMD @echo ".info Using cached toolchain metadata from build at $(hostname) on $(date)" > toolchain-metadata.mk CMD @echo "_LOADED_TOOLCHAIN_METADATA=t" >> toolchain-metadata.mk CMD @echo "COMPILER_VERSION=110001" >> toolchain-metadata.mk CMD @echo "X_COMPILER_VERSION=110001" >> toolchain-metadata.mk CMD @echo "COMPILER_TYPE=clang" >> toolchain-metadata.mk CMD @echo "X_COMPILER_TYPE=clang" >> toolchain-metadata.mk CMD @echo "COMPILER_FEATURES=c++11 c++14 c++17 retpoline init-all" >> toolchain-metadata.mk CMD @echo "X_COMPILER_FEATURES=c++11 c++14 c++17 retpoline init-all" >> toolchain-metadata.mk CMD @echo "COMPILER_FREEBSD_VERSION=140" >> toolchain-metadata.mk CMD @echo "X_COMPILER_FREEBSD_VERSION=140" >> toolchain-metadata.mk CMD @echo "COMPILER_RESOURCE_DIR=/usr/lib/clang/11.0.1" >> toolchain-metadata.mk CMD @echo "X_COMPILER_RESOURCE_DIR=/usr/lib/clang/11.0.1" >> toolchain-metadata.mk CMD @echo "LINKER_VERSION=110001" >> toolchain-metadata.mk CMD @echo "X_LINKER_VERSION=110001" >> toolchain-metadata.mk CMD @echo "LINKER_FEATURES= build-id ifunc retpoline ifunc-noplt" >> toolchain-metadata.mk CMD @echo "X_LINKER_FEATURES= build-id ifunc retpoline ifunc-noplt" >> toolchain-metadata.mk CMD @echo "LINKER_TYPE=lld" >> toolchain-metadata.mk CMD @echo "X_LINKER_TYPE=lld" >> toolchain-metadata.mk CMD @echo "LINKER_FREEBSD_VERSION=137" >> toolchain-metadata.mk CMD @echo "X_LINKER_FREEBSD_VERSION=137" >> toolchain-metadata.mk CMD @echo ".export COMPILER_VERSION COMPILER_TYPE COMPILER_FEATURES COMPILER_FREEBSD_VERSION COMPILER_RESOURCE_DIR LINKER_VERSION LINKER_FEATURES LINKER_TYPE LINKER_FREEBSD_VERSION" >> toolchain-metadata.mk CMD @echo ".export X_COMPILER_VERSION X_COMPILER_TYPE X_COMPILER_FEATURES X_COMPILER_FREEBSD_VERSION X_COMPILER_RESOURCE_DIR X_LINKER_VERSION X_LINKER_FEATURES X_LINKER_TYPE X_LINKER_FREEBSD_VERSION" >> toolchain-metadata.mk CWD /usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64 TARGET toolchain-metadata.mk -- command output -- . . . So (X_)COMPILER_FREEBSD_VERSION were updated to be 14 based but (X_)LINKER_FREEBSD_VERSION still are based on 13: not automatically updated. I do not know what the various consequences might be but sticking at a 13 based figure seems odd. === 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: Is stand/kshim/bsd_kernel.h 's __FreeBSD_version supposed to track main's 13->14 change?
On 2021-Feb-17, at 01:29, Hans Petter Selasky wrote: > On 2/17/21 1:58 AM, Mark Millard via freebsd-current wrote: >> stand/kshim/bsd_kernel.h has its own define of __FreeBSD_version and >> seems to have last had it changed in the main branch as shown below. >> Is it as it should be for main 14? It does seem to have skipped >> being updated for HEAD 12. >> Last change . . . >> author Hans Petter Selasky 2020-11-18 >> 13:22:22 + >> committerHans Petter Selasky 2020-11-18 >> 13:22:22 + >> commit a2dd1caade2f9cb829261a42812431781c685d46 (patch) >> tree 466a86138a99f5f6c73c54cd531dbdb9884678c0 /stand/kshim/bsd_kernel.h >> parent ac8c4a61af5007487eabf882e969dd9768549078 (diff) >> download src-a2dd1caade2f9cb829261a42812431781c685d46.tar.gz >> src-a2dd1caade2f9cb829261a42812431781c685d46.zip >> Fix build of USB bootloader code by adding checks for _STANDALONE being >> defined. >> Currently the USB bootloader code is not part of buildworld. >> MFC after: 1 week >> Sponsored by:Mellanox Technologies // NVIDIA Networking >> Notes >> Notes: >> svn path=/head/; revision=367787 >> Diffstat (limited to 'stand/kshim/bsd_kernel.h') >> -rw-r--r-- stand/kshim/bsd_kernel.h7 >> 1 files changed, 5 insertions, 2 deletions >> diff --git a/stand/kshim/bsd_kernel.h b/stand/kshim/bsd_kernel.h >> index 4dfe307fef0c..89d87121c63e 100644 >> --- a/stand/kshim/bsd_kernel.h >> +++ b/stand/kshim/bsd_kernel.h >> @@ -27,9 +27,12 @@ >> #ifndef _BSD_KERNEL_H_ >> #define _BSD_KERNEL_H_ >> -#define_KERNEL >> +#if !defined(_STANDALONE) >> +#error "_STANDALONE is not defined!" >> +#endif >> + >> #undef __FreeBSD_version >> -#define __FreeBSD_version 110 >> +#define __FreeBSD_version 130 >>#include >> #include > > Yes, please bump, though not critical. I'm not a committer. === 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: "grep -rI ... /" vs. processing of /dev/ : should "--exclude-dir /dev" be required in order to avoid /dev/?
On 2021-Feb-17, at 11:44, Kyle Evans wrote: > On Tue, Feb 16, 2021 at 7:29 PM Kyle Evans wrote: >> >> On Tue, Feb 16, 2021 at 7:23 PM Mark Millard via freebsd-current >> wrote: >>> >>> I historically on occasion have done something like: >>> >>> # grep -rI ... / >>> >>> in order to find all instances of a text, including >>> in build trees and such. I now find that I need to >>> do something more like (using a more specific >>> example): >>> >>> # grep -rI --exclude-dir /dev '#define.*__FreeBSD_version' >>> >>> otherwise the grep ends up reading from the tty and waits >>> for it. Top shows, for example, >>> >>> 13470 root 220 12848Ki2692Ki ttyin 11 0:00 0.00% >>> grep -rI #define.*__FreeBSD_version / >>> >>> Is this expected? Should I have always been using >>> "--exclude-dir /dev"? What lead to the behavior >>> change? >>> >> >> I can't seem to find any evidence that gnugrep in base handled this >> any differently. Experimentation seems to reveal that modern gnugrep >> will skip devices unless they're explicitly named for searching >> (unless supplied a different --devices option), which does feel like a >> good idea. > > Here's my proposal: https://people.freebsd.org/~kevans/grep-rdev.diff wget, git apply, buildworld, installworld, and some quick testing: Seems to work as described in the updated man page and avoids my needing "--exclude-dir /dev" (or other alternatives) by default with the -r . I did try some explicit /dev and /dev/tty and /dev/random use, and some "no -r" variations of the -r testing. While it was just quick testing, I did not notice anything odd happening. I did do one -r for / that I let run to completion. FYI: this is based on main 3acea07c1873 as a context. In more detail: # ~/fbsd-based-on-what-freebsd-main.sh merge-base: 3acea07c1873b1e4042f4a4fa8668745ee59f15b merge-base: CommitDate: 2021-02-08 19:15:21 + c1845d00f818 (HEAD -> mm-src) mm-src snapshot for mm's patched build in git context. 3acea07c1873 (pure-src) Restore the augmented strlen commentary FreeBSD FBSDFHUGE 14.0-CURRENT FreeBSD 14.0-CURRENT mm-src-n244686-c1845d00f818 GENERIC-NODBG amd64 amd64 144 144 === 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"
kern_jail.c w/o INVARIANTS
Seems there's a typo in this when INVARIANTS is not turned on ..
diff --git a/sys/kern/kern_jail.c b/sys/kern/kern_jail.c
index 48c91a95bf..342af50462 100644
--- a/sys/kern/kern_jail.c
+++ b/sys/kern/kern_jail.c
@@ -2671,7 +2671,7 @@ prison_free_not_last(struct prison *pr)
("prison_free_not_last freed last ref on prison %p (jid=%d).",
pr, pr->pr_id));
#else
- refcount_release(&pr>pr_ref);
+ refcount_release(&pr->pr_ref);
#endif
}
_______
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"
testers needed: loader: use display pixel density for font autoselection
hi! I have done some work to make font pickup a bit smarter (hopefully better;), but my own ability to test is limited to one bugged supermicro and one MBP with retina display… The phab link is https://reviews.freebsd.org/D28849 <https://reviews.freebsd.org/D28849> I have built loader binaries as well (bios and uefi): loader_lua <http://148-52-235-80.sta.estpak.ee/loader_lua> loader_lua.efi <http://148-52-235-80.sta.estpak.ee/loader_lua.efi> To test, you should remove screen.font= line from loader.conf and test with different resolutions. 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: testers needed: loader: use display pixel density for font autoselection
> On 23. Feb 2021, at 17:53, Jakob Alvermark wrote: > > On 2/23/21 12:27 PM, Toomas Soome via freebsd-current wrote: >> hi! >> >> I have done some work to make font pickup a bit smarter (hopefully better;), >> but my own ability to test is limited to one bugged supermicro and one MBP >> with retina display… >> >> The phab link ishttps://reviews.freebsd.org/D28849 >> <https://reviews.freebsd.org/D28849> >> >> I have built loader binaries as well (bios and uefi): >> loader_lua<http://148-52-235-80.sta.estpak.ee/loader_lua> >> loader_lua.efi<http://148-52-235-80.sta.estpak.ee/loader_lua.efi> >> >> To test, you should remove screen.font= line from loader.conf and test with >> different resolutions. >> >> thanks, >> toomas > > > > Hi Toomas, > > > I tested on five different setups. > > Surface Pro 10.6"@1920x1080: > > The loader menu looks different, the "FreeBSD" text is on the right side of > the screen. I think, this was the lua script bug we did fix not too long time ago. > > Otherwise, the font size is what I would call a normal size. > > > Acer laptop 11.6"@1366x768: > > Menu looks fine. Almost fills the entire screen. > > The font feels a little too big. The laptop built in displays usually do not give out EDID (we get physical dimensions from EDID), so there we fall back to try to get 80x25 terminal method. > > > Thinkpad built in 13"@1920x1080: > > Menu looks fine, but a little slow. > > The font size is a little to big for my liking. When drm loads and mirrors > the screen to my external 27" it looks comically large. > There is another issue - once DRM will kick in, we should re-consider the console attributes, like fonts, but at this time, the kernel itself only can use what was built in (8x16), or what loader was offering (default if present). So it is up to user to act there. > > Thinkpad external 24"@1920x1200: > > Menu looks OK, uses about a quarter of the screen. > > Font size is fine, but once drm loads it looks a bit squeezed (like thin and > tall), but I guess that's drm detecting the built in 1920x1080, and the > external display is stretched. > > > Thinkpad external 27"@3840x2160: > > Menu looks OK, uses about a quarter of the screen. > > Font size is fine. > > Looking at the dmesg though, it says: VT(efifb): resolution 1920x1080 > > > Jakob > Those cases .. I suppose the menu was still at left side, not in middle? The thing there is, our menu is designed for 80x25 screen, with respective constants. many thanks for testing, 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: testers needed: loader: use display pixel density for font autoselection
> On 26. Feb 2021, at 05:42, Rodney W. Grimes wrote: > >>> On 23. Feb 2021, at 17:53, Jakob Alvermark wrote: >>> >>> On 2/23/21 12:27 PM, Toomas Soome via freebsd-current wrote: >>>> hi! >>>> >>>> I have done some work to make font pickup a bit smarter (hopefully >>>> better;), but my own ability to test is limited to one bugged supermicro >>>> and one MBP with retina display? >>>> >>>> The phab link ishttps://reviews.freebsd.org/D28849 >>>> <https://reviews.freebsd.org/D28849> >>>> >>>> I have built loader binaries as well (bios and uefi): >>>> loader_lua<http://148-52-235-80.sta.estpak.ee/loader_lua> >>>> loader_lua.efi<http://148-52-235-80.sta.estpak.ee/loader_lua.efi> >>>> >>>> To test, you should remove screen.font= line from loader.conf and test >>>> with different resolutions. >>>> >>>> thanks, >>>> toomas >>> >>> >>> >>> Hi Toomas, >>> >>> >>> I tested on five different setups. >>> >>> Surface Pro 10.6"@1920x1080: >>> >>> The loader menu looks different, the "FreeBSD" text is on the right side of >>> the screen. >> >> >> I think, this was the lua script bug we did fix not too long time ago. >> >>> >>> Otherwise, the font size is what I would call a normal size. >>> >>> >>> Acer laptop 11.6"@1366x768: >>> >>> Menu looks fine. Almost fills the entire screen. >>> >>> The font feels a little too big. >> >> >> The laptop built in displays usually do not give out EDID (we get physical >> dimensions from EDID), so there we fall back to try to get 80x25 terminal >> method. > > I am having a hard time with that statement. EDID is very common on laptop > screens, infact I can not recall ever not seeing EDID on a laptops builtin > screen. > My 11" acer 1400 has EDID in it. > > If there is EDID, then it is all good. I have seen cases we do not get it with available API. >>> >>> Thinkpad built in 13"@1920x1080: >>> >>> Menu looks fine, but a little slow. >>> >>> The font size is a little to big for my liking. When drm loads and mirrors >>> the screen to my external 27" it looks comically large. >>> >> >> There is another issue - once DRM will kick in, we should re-consider the >> console attributes, like fonts, but at this time, the kernel itself only can >> use what was built in (8x16), or what loader was offering (default if >> present). So it is up to user to act there. > > It would be really nice if DRM could pick up what the resolution and font was > when it loaded! it should do more, my supermicro X10SAE is ony doing 800x600 with UEFI, it has dell 27” 4k monitor connected. VBE can get 1600x1200 from the same set. What I would like to see is, once KMS is attached (i915), I’d like to get bets possible resolution and appropriate font. But thats something for future work. > >> >>> >>> Thinkpad external 24"@1920x1200: >>> >>> Menu looks OK, uses about a quarter of the screen. >>> >>> Font size is fine, but once drm loads it looks a bit squeezed (like thin >>> and tall), but I guess that's drm detecting the built in 1920x1080, and the >>> external display is stretched. >>> >>> >>> Thinkpad external 27"@3840x2160: >>> >>> Menu looks OK, uses about a quarter of the screen. >>> >>> Font size is fine. >>> >>> Looking at the dmesg though, it says: VT(efifb): resolution 1920x1080 >>> >>> >>> Jakob >>> >> >> >> Those cases .. I suppose the menu was still at left side, not in middle? The >> thing there is, our menu is designed for 80x25 screen, with respective >> constants. > > SO again... why are we deviating from that causing us issues? You have misunderstood - the current menu code *is* built for 80x25 - the menu frame size is fixed, logo/brand locations are constants and so on. > >> >> many thanks for testing, > > I have downloaded your modified loader, and put it in place, it shall get > tested on my next reboot, which should be soon as 13-BETA4 should be popping > out soon. > thank you! 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: freebsd-current Digest, Vol 904, Issue 5
Thanks for that work. Is there any plan to enable PIE for ports by default? On my workstation I've been building ports with PIE for some time. Most ports seem to build fine. Piotr Kubaj. signature.asc Description: PGP signature
Re: testers needed: loader: use display pixel density for font autoselection
> On 26. Feb 2021, at 17:56, Rodney W. Grimes > wrote: > >>> On 26. Feb 2021, at 05:42, Rodney W. Grimes >>> wrote: >>> >>>>> On 23. Feb 2021, at 17:53, Jakob Alvermark wrote: >>>>> >>>>> On 2/23/21 12:27 PM, Toomas Soome via freebsd-current wrote: >>>>>> hi! >>>>>> >>>>>> I have done some work to make font pickup a bit smarter (hopefully >>>>>> better;), but my own ability to test is limited to one bugged supermicro >>>>>> and one MBP with retina display? >>>>>> >>>>>> The phab link ishttps://reviews.freebsd.org/D28849 >>>>>> <https://reviews.freebsd.org/D28849> >>>>>> >>>>>> I have built loader binaries as well (bios and uefi): >>>>>> loader_lua<http://148-52-235-80.sta.estpak.ee/loader_lua> >>>>>> loader_lua.efi<http://148-52-235-80.sta.estpak.ee/loader_lua.efi> >>>>>> >>>>>> To test, you should remove screen.font= line from loader.conf and test >>>>>> with different resolutions. >>>>>> >>>>>> thanks, >>>>>> toomas >>>>> >>>>> >>>>> >>>>> Hi Toomas, >>>>> >>>>> >>>>> I tested on five different setups. >>>>> >>>>> Surface Pro 10.6"@1920x1080: >>>>> >>>>> The loader menu looks different, the "FreeBSD" text is on the right side >>>>> of the screen. >>>> >>>> >>>> I think, this was the lua script bug we did fix not too long time ago. >>>> >>>>> >>>>> Otherwise, the font size is what I would call a normal size. >>>>> >>>>> >>>>> Acer laptop 11.6"@1366x768: >>>>> >>>>> Menu looks fine. Almost fills the entire screen. >>>>> >>>>> The font feels a little too big. >>>> >>>> >>>> The laptop built in displays usually do not give out EDID (we get physical >>>> dimensions from EDID), so there we fall back to try to get 80x25 terminal >>>> method. >>> >>> I am having a hard time with that statement. EDID is very common on laptop >>> screens, infact I can not recall ever not seeing EDID on a laptops builtin >>> screen. >>> My 11" acer 1400 has EDID in it. >>> >>> >> >> >> If there is EDID, then it is all good. I have seen cases we do not get it >> with available API. > > Is there a way for me to know if the laoder found EDID data or not? > It might be that the issue is that what ever loader is using for an API is > not working. > I based my "EDID is very common on laptop screens" on the fact that X11 > almost always finds EDID. > Yes, gop get / vbe list — yes, it is inconsistent, should fix at some point… :) we do use gop get active edid/get discovered edid protocol and vbe function 0x4f15. 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: No serial console: VBE not available
> On 26. Feb 2021, at 18:54, O. Hartmann wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > hello, > > running a FreeBSD appliance on top of a PCengines APU2C4 with the latest > seabios > (apu2_v4.13.0.3.rom). The PCengines boot image layout is based on > pmbr/gptboot (GPT patition > scheme), via nanoBSD the latest pmbr/gptboot binaries are applied taken from > the 13-STABLE > tree (or 14-CURRENT). > > It doesn't matter whether I put these lines into /boot/loader.conf: > > boot_serial="YES" > comconsole_speed="115200" > console="comconsole" > > autoboot_delay="0" > > and in the kernel config file: > > options CONSPEED=115200 > > while having alos in both cases > > /boot/config > - -h -S115200 > > following strict the handbook's suggestions. > > After booting, I face always forever this screen: > > SeaBIOS (version rel-1.12.1.3-0-g300e8b70) > > Press F10 key now for boot menu > > Select boot device: > > 1. SD card SN64G 60906MiB > 2. USB MSC Drive USB DISK 3.0 PMAP > 3. AHCI/0: Samsung SSD 860 EVO mSATA 250GB ATA-11 Hard-Disk (232 GiBytes) > 4. Payload [setup] > 5. Payload [memtest] > > Booting from Hard Disk... > /boot/config: -h -S115200 > Consoles: serial port > BIOS drive C: is disk0 > BIOS drive D: is disk1 > BIOS drive E: is disk2 > BIOS 639kB/3405336kB available memory > > FreeBSD/x86 bootstrap loader, Revision 1.1 > (Mon Feb 22 18:17:30 CET 2021 root@thor) > | > > VBE not available > > > > ... and its stuck forever ... > > What is wrong here? > > Thanks for your help, > > kind regards > > Oliver > You are missing this one: commit 61c50cbc096d28e44cb8b627e524ae58158c423a Author: Toomas Soome Date: Sun Feb 21 12:32:18 2021 +0200 loader: autoload_font will hung loader when there is no local console If we start with console set to comconsole, the local console (vidconsole, efi) is never initialized and attempt to use the data can render the loader hung. Reported by:Kamigishi Rei MFC after: 3 days The temporary workaround is to add -D, this will trigger call to vidc_init() and will prevent the hung. 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: HEADS-UP: PIE enabled by default on main
> On 28. Feb 2021, at 13:27, dmilith . wrote: > > First of all - ALSR is designed as mitigation for external attacks, > not internal ones (logged in user). > Second - Linux and FreeBSD both have weak implementations in > comparison to PAX-driven ones. Try attacking the system with > Grsecurity or HardenedBSD (both use the strongest ASLR available > AFAIK). > > Saying that security mitigation features that affect no performance > are "meaningless", is just ridiculous or at least just irresponsible. > It's like telling C programmers that stack protection or out of bounds > checks are bad, cause there's nothing wrong with random SEGFAULTS from > time to time… > You seem to forget that those mechanisms are there exactly because programmers are not caring about random faults from time to time:D With correct code, one would not need mechanisms like ALSR. rgds, toomas > > On 28/02/2021, Ihor Antonov wrote: >> On 2021-02-27 22:29, Warner Losh wrote: >>> On Sat, Feb 27, 2021 at 9:34 PM Ihor Antonov >>> wrote: >>> >>>>> >>>>> But isn't it well-known that ASLR/ASR/any-related-buzzwork does not >>>>> add >>>>> any security, except imaginary? The only purpose of it is to have a >>>>> check-list item ticked green. >>>> >>>> I don't know if I should parse this as sarcasm (or any other form of >>>> "humor") or is a serious statement? But this does leave me with a whole >>>> bunch of questions.. >>>> >>>> If this is really how Konstantin is describing it then is it OK to say >>>> about this to the whole Internet? Why FreeBSD Foundation is paying for >>>> meaningless work then? Why members of the Core team do this work? Does >>>> this mean that FreeBSD is working to satisfy the silly needs of some >>>> fat >>>> customer? What about project independence and not being controlled by >>>> big money? >>>> >>>> Where can I read about ASLR and security myths? >>> >>> Why not spend time and explain why this does not work? >>>> >>> >>> Not to rise to the baitiness of all these leading questions (they really >>> are quite contrary to how our community usually comports itself, but for >>> the sake of civil discourse, I'll ignore) >>> >>> I'll bet it has something to do with the many known ASLR attacks. One is >>> chronicled in https://www.vusec.net/projects/anc/ and elsewhere, which >>> show >>> how MMU side channels can defeat ASLR. Or maybe he's familiar with the >>> offset2lib attack against Linux 64-bit ASLR documented in this paper >>> https://cybersecurity.upv.es/attacks/offset2lib/offset2lib-paper.pdf. >>> There's many others as well that show the shortcomings of ASLR and >>> disclose >>> ways to defeat it using various clever means. >> >> Warner, thanks for the links. They are indeed interesting. >> >>>> You clearly should mean something useful and much more important than >>>> that, >>> >>> Maybe he'd like to understand how PIE accomplishes better security give >>> the >>> known ASLR weaknesses. And rather than take a sarcastic tone, he asked >>> for >>> more details that back up the earlier claims of improved security so we >>> could all learn something. >> >> The conclusion of the paper in the second link clearly says: >> >>We present a new weakness on the current implementationof the ASLR >>Linux systems which affects PIE compiled ex-ecutables. Applications >>compiled with PIE are consideredto be more robust since it makes >>attacks more difficult. >> >> Which I read as ASLR and PIE work better together. This is the same what >> Gordon was saying. >> >> The whole situation is wrong on 2 different levels. >> >> First: saying that ASLR is not perfect and can be broken is not the same >> thing as saying "The only purpose of it is to have a check-list item ticked >> green" >> >> There are no perfect security measures, and you guys (kernel and OS >> developers) should know that better than us (users). Hackers find new >> exploits, developers find ways to mitigate them and cycle repeats. Just >> the fact that ASLR can be broken is not the reason to not have it. >> >> Second: look at this exchange from a distance >> >> Ed: we are enabling security feature X, please rebui
Re: No serial console: VBE not available
> On 1. Mar 2021, at 12:34, Harry Schmalzbauer wrote: > > Am 26.02.2021 um 17:58 schrieb Toomas Soome via freebsd-current: >>> On 26. Feb 2021, at 18:54, O. Hartmann wrote: >>> >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA256 >>> >>> hello, >>> >>> running a FreeBSD appliance on top of a PCengines APU2C4 with the latest >>> seabios >>> (apu2_v4.13.0.3.rom). The PCengines boot image layout is based on >>> pmbr/gptboot (GPT patition >>> scheme), via nanoBSD the latest pmbr/gptboot binaries are applied taken >>> from the 13-STABLE >>> tree (or 14-CURRENT). >>> >>> It doesn't matter whether I put these lines into /boot/loader.conf: >>> >>> boot_serial="YES" >>> comconsole_speed="115200" > : > : > : >> >> You are missing this one: >> commit 61c50cbc096d28e44cb8b627e524ae58158c423a > > Actually stable/13 is missing this. > It was merged to releng/13.0, but not to stable/13 as far as my git skills > last: > https://cgit.freebsd.org/src/log/stand/i386/libi386/vidconsole.c?h=stable%2F13 > > <https://cgit.freebsd.org/src/log/stand/i386/libi386/vidconsole.c?h=stable%2F13> > .oO totally my bad, I have missed push… fixed, sorry. 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: testers needed: loader: use display pixel density for font autoselection
> On 2. Mar 2021, at 20:32, Rodney W. Grimes > wrote: > >>> On 26. Feb 2021, at 17:56, Rodney W. Grimes >>> wrote: >>> >>>>> On 26. Feb 2021, at 05:42, Rodney W. Grimes >>>>> wrote: >>>>> >>>>>>> On 23. Feb 2021, at 17:53, Jakob Alvermark wrote: >>>>>>> >>>>>>> On 2/23/21 12:27 PM, Toomas Soome via freebsd-current wrote: >>>>>>>> hi! >>>>>>>> >>>>>>>> I have done some work to make font pickup a bit smarter (hopefully >>>>>>>> better;), but my own ability to test is limited to one bugged >>>>>>>> supermicro and one MBP with retina display? >>>>>>>> >>>>>>>> The phab link ishttps://reviews.freebsd.org/D28849 >>>>>>>> <https://reviews.freebsd.org/D28849> >>>>>>>> >>>>>>>> I have built loader binaries as well (bios and uefi): >>>>>>>> loader_lua<http://148-52-235-80.sta.estpak.ee/loader_lua> >>>>>>>> loader_lua.efi<http://148-52-235-80.sta.estpak.ee/loader_lua.efi> > > I have tested this on: > Lenovo W530 > Dell E5470 > Acer Aspire 1410 > > all work fine with resonable display resolution. > > One more comment below... > >>>>>>>> >>>>>>>> To test, you should remove screen.font= line from loader.conf and test >>>>>>>> with different resolutions. >>>>>>>> >>>>>>>> thanks, >>>>>>>> toomas >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi Toomas, >>>>>>> >>>>>>> >>>>>>> I tested on five different setups. >>>>>>> >>>>>>> Surface Pro 10.6"@1920x1080: >>>>>>> >>>>>>> The loader menu looks different, the "FreeBSD" text is on the right >>>>>>> side of the screen. >>>>>> >>>>>> >>>>>> I think, this was the lua script bug we did fix not too long time ago. >>>>>> >>>>>>> >>>>>>> Otherwise, the font size is what I would call a normal size. >>>>>>> >>>>>>> >>>>>>> Acer laptop 11.6"@1366x768: >>>>>>> >>>>>>> Menu looks fine. Almost fills the entire screen. >>>>>>> >>>>>>> The font feels a little too big. >>>>>> >>>>>> >>>>>> The laptop built in displays usually do not give out EDID (we get >>>>>> physical dimensions from EDID), so there we fall back to try to get >>>>>> 80x25 terminal method. >>>>> >>>>> I am having a hard time with that statement. EDID is very common on >>>>> laptop screens, infact I can not recall ever not seeing EDID on a laptops >>>>> builtin screen. >>>>> My 11" acer 1400 has EDID in it. >>>>> >>>>> >>>> >>>> >>>> If there is EDID, then it is all good. I have seen cases we do not get it >>>> with available API. >>> >>> Is there a way for me to know if the laoder found EDID data or not? >>> It might be that the issue is that what ever loader is using for an API is >>> not working. >>> I based my "EDID is very common on laptop screens" on the fact that X11 >>> almost always finds EDID. >>> >> >> Yes, gop get / vbe list ? yes, it is inconsistent, should fix at some >> point? :) >> >> we do use gop get active edid/get discovered edid protocol and vbe function >> 0x4f15. > > On all my handy laptops, E5470, T400, W530, Acer 1410 edid is present and seen > by the loader. > > Thank You! 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: xfig menu on xfce
On 04/03/21 20:56, Antonio Olivares wrote:
On Thu, Mar 4, 2021 at 1:55 PM Antonio Olivares wrote:
On Thu, Mar 4, 2021 at 1:51 PM David Wolfskill wrote:
On Thu, Mar 04, 2021 at 01:47:03PM -0600, Antonio Olivares wrote:
xfig installed from pkg
on the menu click on xfce we get error message
Failed to execute command "/usr/bin/xfig".
Failed to execute child process "/usr/bin/xfig" (No such file or directory)
x Close
running from command line does work. which xfig reports
/usr/local/bin/xfig
olivares@deepcool:~ $ which xfig
/usr/local/bin/xfig
olivares@deepcool:~ $ uname -a
FreeBSD deepcool 13.0-BETA4 FreeBSD 13.0-BETA4 #0
releng/13.0-n244592-e32bc253629: Fri Feb 26 06:17:34 UTC 2021
r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
amd64
olivares@deepcool:~ $
Best Regards,
I am unfamiliar with xfce, but that seems like a bug in the menu entry
itself. Not sure whose responsibility that is
Peace,
david
I do not know how to edit the link, but it is not a big deal. It runs
from comand line.
Menu entries are created fort all desktop environments creating files
defined by common standards. Each installed software is responsible for
creating the correct file. (".desktop" files)
Looking at xfig port the desktop entry provided by upstream has that
patch coded in. The port is not patching it. The error you see would
happen with any desktop environment in FreeBSD. I'll provide a patch to
fix this.
Thanks for reporting it!
BTW to edit desktop menu entries in xfce you can use x11/menulibre.
The icedtea-web start/openjdk issue is more important for me. Just
writing to see if someone else has encountered this.
Don't know much about java, but I can't find information about this
problem in this thread.
--
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: xfig menu on xfce
On 04/03/21 21:16, Guido Falsi via freebsd-current wrote:
On 04/03/21 20:56, Antonio Olivares wrote:
On Thu, Mar 4, 2021 at 1:55 PM Antonio Olivares
wrote:
On Thu, Mar 4, 2021 at 1:51 PM David Wolfskill
wrote:
On Thu, Mar 04, 2021 at 01:47:03PM -0600, Antonio Olivares wrote:
xfig installed from pkg
on the menu click on xfce we get error message
Failed to execute command "/usr/bin/xfig".
Failed to execute child process "/usr/bin/xfig" (No such file or
directory)
x Close
running from command line does work. which xfig reports
/usr/local/bin/xfig
olivares@deepcool:~ $ which xfig
/usr/local/bin/xfig
olivares@deepcool:~ $ uname -a
FreeBSD deepcool 13.0-BETA4 FreeBSD 13.0-BETA4 #0
releng/13.0-n244592-e32bc253629: Fri Feb 26 06:17:34 UTC 2021
r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
amd64
olivares@deepcool:~ $
Best Regards,
I am unfamiliar with xfce, but that seems like a bug in the menu entry
itself. Not sure whose responsibility that is
Peace,
david
I do not know how to edit the link, but it is not a big deal. It runs
from comand line.
Menu entries are created fort all desktop environments creating files
defined by common standards. Each installed software is responsible for
creating the correct file. (".desktop" files)
Looking at xfig port the desktop entry provided by upstream has that
patch coded in. The port is not patching it. The error you see would
happen with any desktop environment in FreeBSD. I'll provide a patch to
fix this.
Thanks for reporting it!
Filed bug report with patch:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254031
--
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"
Problem compiling gcc10
The following is the error while compiling on: [root@sting /usr/ports]# uname -aFreeBSD sting 14.0-CURRENT FreeBSD 14.0-CURRENT #32 main-n245104-dfff1de729b: Fri Feb 26 12:08:40 CET 2021 root@sting:/usr/obj/usr/src/amd64.amd64/sys/STING amd64 gmake[6]: *** [Makefile:1212: multi-do] Error 1gmake[6]: Leaving directory '/usr/ports/lang/gcc10/work/.build/x86_64-portbld-fr eebsd14.0/libgcc'gmake[5]: *** [Makefile:127: all-multi] Error 2gmake[5]: *** Waiting for unfinished jobsgmake[5]: Leaving directory '/usr/ports/lang/gcc10/work/.build/x86_64-portbld-fr eebsd14.0/libgcc'gmake[4]: *** [Makefile:17599: all-stage1-target-libgcc] Error 2gmake[4]: Leaving directory '/usr/ports/lang/gcc10/work/.build'gmake[3]: *** [Makefile:22903: stage1-bubble] Error 2gmake[3]: Leaving directory '/usr/ports/lang/gcc10/work/.build'gmake[2]: *** [Makefile:23235: bootstrap-lean] Error 2gmake[2]: Leaving directory '/usr/ports/lang/gcc10/work/.build'===> Compilation failed unexpectedly.Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure tothe maintainer.*** Error code 1Stop.make[1]: stopped in /usr/ports/lang/gcc10*** Error code 1 _______ 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: Waiting for bufdaemon
.frequency: timecounter frequency kern.timecounter.tc.HPET.counter: current timecounter value kern.timecounter.tc.HPET.mask: mask for implemented bits kern.timecounter.tc.TSC-low: timecounter description kern.timecounter.tc.TSC-low.quality: goodness of time counter kern.timecounter.tc.TSC-low.frequency: timecounter frequency kern.timecounter.tc.TSC-low.counter: current timecounter value kern.timecounter.tc.TSC-low.mask: mask for implemented bits Looking at both can tend to narrow things down. Not exactly direct, but useful. It might have been harder before having kib's wording that used terminology (notation) involved in the use of the systctl commands. I'll note that in the context I'm using for this: # sysctl -ad | wc 11153 57922 604736 # sysctl -a | wc 13080 29457 449667 So: not a trivial amount of material. === 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: geli broken in 13.0-BETA4 and later
On 2021-Mar-06 19:18:37 +1100, Peter Jeremy via freebsd-stable wrote: >Somewhere between 13.0-ALPHA2 (c256201-g02611ef8ee9) and 13.0-BETA4 >(releng/13.0-n244592-e32bc253629), geli (at least on my RockPro64 - >RK3399, arm64) has changed so that a geli-encrypted partition (using >AES-XTS 128) that was readable on 13.0-ALPHA2 becomes garbage on >13.0-BETA4. I've confirmed that the problem is f76393a6305b - reverting that commit fixes the problem in releng/13.0. I've further verified that the bug is still present in main (14.x) at 028616d0dd69. -- Peter Jeremy signature.asc Description: PGP signature
Re: Problem compiling gcc10
This is the output from MAKE_JOBS_UNSAFE=yes checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... configure: error: in `/usr/ports/lang/gcc10/work/.build/x86_64-portbld-freebsd14.0/32/libgcc': configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details gmake[4]: *** [Makefile:17191: configure-stage1-target-libgcc] Error 1 gmake[4]: Leaving directory '/usr/ports/lang/gcc10/work/.build' gmake[3]: *** [Makefile:22903: stage1-bubble] Error 2 gmake[3]: Leaving directory '/usr/ports/lang/gcc10/work/.build' gmake[2]: *** [Makefile:23235: bootstrap-lean] Error 2 gmake[2]: Leaving directory '/usr/ports/lang/gcc10/work/.build' *** Error code 1 Stop. On Friday, March 5, 2021, 9:28:52 PM GMT+1, Dimitry Andric wrote: On 5 Mar 2021, at 18:19, Filippo Moretti via freebsd-current wrote: > > The following is the error while compiling on: > [root@sting /usr/ports]# uname -aFreeBSD sting 14.0-CURRENT FreeBSD > 14.0-CURRENT #32 main-n245104-dfff1de729b: Fri Feb 26 12:08:40 CET 2021 > root@sting:/usr/obj/usr/src/amd64.amd64/sys/STING amd64 > > gmake[6]: *** [Makefile:1212: multi-do] Error 1gmake[6]: Leaving directory > '/usr/ports/lang/gcc10/work/.build/x86_64-portbld-fr > eebsd14.0/libgcc'gmake[5]: *** [Makefile:127: all-multi] Error 2gmake[5]: *** > Waiting for unfinished jobsgmake[5]: Leaving directory > '/usr/ports/lang/gcc10/work/.build/x86_64-portbld-fr > eebsd14.0/libgcc'gmake[4]: *** [Makefile:17599: all-stage1-target-libgcc] > Error 2gmake[4]: Leaving directory > '/usr/ports/lang/gcc10/work/.build'gmake[3]: *** [Makefile:22903: > stage1-bubble] Error 2gmake[3]: Leaving directory > '/usr/ports/lang/gcc10/work/.build'gmake[2]: *** [Makefile:23235: > bootstrap-lean] Error 2gmake[2]: Leaving directory > '/usr/ports/lang/gcc10/work/.build'===> Compilation failed unexpectedly.Try > to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure tothe > maintainer.*** Error code 1Stop.make[1]: stopped in /usr/ports/lang/gcc10*** > Error code 1 Hi Filippo, Unfortunately the actual error is earlier in the build, so it is not shown, and your log is wrapped very strangely. Can you run the build under script(1) and upload a full build log somewhere? Alternatively, you can set MAKE_JOBS_UNSAFE=yes so it would use a single job make, and it should then show the error more clearly at the end. But this is likely to take a bit longer to build. -Dimitry signature.asc Description: PGP signature ___________ 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: Waiting for bufdaemon
Quoting Konstantin Belousov (from Fri, 5 Mar 2021 22:43:58 +0200): On Fri, Mar 05, 2021 at 04:03:11PM +0900, Yasuhiro Kimura wrote: Dear src committers, From: Yasuhiro Kimura Subject: Re: Waiting for bufdaemon Date: Thu, 28 Jan 2021 05:02:42 +0900 (JST) >>> I have been experiencing same problem with my 13-CURRENT amd64 >>> VirtualBox VM for about a month. The conditions that the problem >>> happens are unclear and all what I can say is >>> >>> * It happens only after I login in the VM and do something for a >>> while. If I boot the VM and shut it down immediately, it never >>> happens. >>> * When the problem happens, one or more unkillable processes seem to >>> be left. >> >> CPU of my host is not AMD but Intel. According to the >> /var/run/dmesg.boot of VM, information of CPU is as following. >> >> CPU: Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz (3000.09-MHz K8-class CPU) >> Origin="GenuineIntel" Id=0x906ed Family=0x6 Model=0x9e Stepping=13 >> Features=0x1783fbff >> Features2=0x5eda2203 >> AMD Features=0x28100800 >> AMD Features2=0x121 >> Structured Extended Features=0x842421 >> Structured Extended Features3=0x3400 >> IA32_ARCH_CAPS=0x29 >> TSC: P-state invariant >> >> Just FYI. > > It took for a while to investigate, but according to the result of > bisect following commit is the source of problem in my case. > > -- > commit 84eaf2ccc6a > Author: Konstantin Belousov > Date: Mon Dec 21 19:02:31 2020 +0200 > > x86: stop punishing VMs with low priority for TSC timecounter > > I suspect that virtualization techniques improved from the time when we > have to effectively disable TSC use in VM. For instance, it was reported > (complained) in https://github.com/JuliaLang/julia/issues/38877 that > FreeBSD is groundlessly slow on AWS with some loads. > > Remove the check and start watching for complaints. > > Reviewed by:emaste, grehan > Discussed with: cperciva > Sponsored by: The FreeBSD Foundation > Differential Revision: https://reviews.freebsd.org/D27629 > -- > > I confirmed the problem still happens with 5c325977b11 but reverting > above commit fixes it. Would someone please revert above commit from main, stable/13 and releng/13.0? As I wrote previous mail I submitted this problem to Bugzilla as bug 253087 and added the committer to Cc. But there is no response for 34 days. I confirmed the problem still happens with 37cd6c20dbc of main and 13.0-RC1. My belief is that this commit helps more users than it hurts. Namely, the VMWare and KVM users, which are majority, use fast timecounter, comparing to the more niche hypervisors like VirtualBox. For you, a simple but manual workaround, setting the timecounter to ACPI (?) or might be HPET, with a loader tunable, should do it. Do you propose this to him as a test if this solves the issue with the intend to change the code to use a more suitable TC if VirtualBox is detected? Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF pgpZtn2nb4T4U.pgp Description: Digitale PGP-Signatur
