Question mark on Lua menu box

[Juan Ramón Molina Menor]

On 02/03/18 12:31, Kyle Evans wrote:

On Fri, Mar 2, 2018 at 6:06 AM, Renato Botelho  wrote:

Kyle,

I've moved to Lua loader to help testing and it worked fine. The only
odd thing I noted is the menu box with odd chars as you can see at [1].

My laptop is running a recent current (r330275) with ZFS and UEFI.

[1] https://imgur.com/a/kIQ0O
--
Renato Botelho



Hi,

Thanks for testing! =) Can you give it a shot with EFI boot after
r330281 (just committed), please?

I think our working theory is that we were printing newlines along
with our box-drawing characters, and that could be problematic. The
new version handles all of that a little better and respects
loader_menu_frame to boot.


Hi!

The drawing issue was still there after updating to r330281, but pushing 
it up to r330287 has solved it.


Thanks!
___
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: ACPI panic on boot with new Lua loader and other minor issues

[Juan Ramón Molina Menor]

Le 20/02/2018 à 22:45, Kyle Evans a écrit :

On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor <lis...@club.fr> wrote:

[... snip ...]

Moreover, the "boot [kernel]" loader command does not work:

OK ls /boot/kernel.old/kernel
 /boot/kernel.old/kernel
OK boot kernel.old
Command failed
OK boot /boot/kernel.old/kernel
Command failed
OK boot kernel
Command failed

On the other hand, just "boot" works.



This part should work as expected as of r329674, so please give that a
shot. I'm still trying to see if I can reproduce your box drawing
problem.

Thanks,

Kyle Evans



Thanks Kyle.

boot command works now. There is though a somewhat strangely formulated 
messages when trying to load an non-existent kernel:


OK boot fake
Failed to load kernel ’fake’
Failed to load any kernel
can’t load ’kernel’

The two last lines are odd: Did the loader try to load a fallback kernel 
and failed? That would explain the ’kernel’ name in quotes, but I have 
such a kernel… Also, just nitpicking, but "can’t" should be capitalized.


Then, I have just remembered why I was seeing a higher resolution menu 
before: I had set 'gop set 0' in /boot/loader.rc.local. It seems the new 
loader is not implementing the inclusion of this file, because I can 
change the gop mode in the loader with 'gop set [0-3]'.


This has thus nothing to do with the drawing lines, I guess.

Best regards.
___
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: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork

[Juan Ramón Molina Menor]

Le 20/02/2018 à 21:20, Mateusz Guzik a écrit :

Committed in https://svnweb.freebsd.org/base?view=revision=329660

thanks for reporting


Thanks Mateusz, Konstantin, issue solved.
___
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: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork

[Juan Ramón Molina Menor]

I committed the fix in
https://svnweb.freebsd.org/base?view=revision=329542

i.e. should be stable from this point on.


Hi!

It is maybe unrelated, but recent commits have broken my system with a 
similar error. I did not have panics with a system built around 
December, but since updating first to r329555 then today to r329641 I’m 
getting a reproducible panic when logging out from a Lumina desktop session:


Unread portion of the kernel message buffer:
spin lock 0xf8000d440020 (process slock) held by 0xf8000daed560 
(tid 100111) too long

panic: spin lock held too long
cpuid = 1
time = 1519143505
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
0xfe5c15e0

vpanic() at vpanic+0x18d/frame 0xfe5c1640
panic() at panic+0x43/frame 0xfe5c16a0
_mtx_lock_indefinite_check() at _mtx_lock_indefinite_check+0x71/frame 
0xfe5c16b0
mtx_spin_wait_unlocked() at mtx_spin_wait_unlocked+0x59/frame 
0xfe5c16e0

proc_reap() at proc_reap+0x24/frame 0xfe5c1720
procdesc_close() at procdesc_close+0x125/frame 0xfe5c1760
closef() at closef+0x251/frame 0xfe5c17f0
fdescfree_fds() at fdescfree_fds+0x90/frame 0xfe5c1840
fdescfree() at fdescfree+0x4df/frame 0xfe5c1900
exit1() at exit1+0x508/frame 0xfe5c1970
sys_sys_exit() at sys_sys_exit+0xd/frame 0xfe5c1980
amd64_syscall() at amd64_syscall+0xa48/frame 0xfe5c1ab0
fast_syscall_common() at fast_syscall_common+0x101/frame 0x7fffea90
Uptime: 17m45s
Dumping 327 out of 3990 MB:..5%..15%..25%..35%..44%..54%..64%..74%..84%..93%

Reading symbols from /boot/kernel/linux.ko...done.
Loaded symbols for /boot/kernel/linux.ko
Reading symbols from /boot/kernel/linux_common.ko...done.
Loaded symbols for /boot/kernel/linux_common.ko
Reading symbols from /boot/kernel/acpi_ibm.ko...done.
Loaded symbols for /boot/kernel/acpi_ibm.ko
Reading symbols from /boot/kernel/iwm7260fw.ko...done.
Loaded symbols for /boot/kernel/iwm7260fw.ko
Reading symbols from /boot/kernel/coretemp.ko...done.
Loaded symbols for /boot/kernel/coretemp.ko
Reading symbols from /boot/kernel/if_iwm.ko...done.
Loaded symbols for /boot/kernel/if_iwm.ko
Reading symbols from /boot/kernel/acpi_video.ko...done.
Loaded symbols for /boot/kernel/acpi_video.ko
Reading symbols from /boot/kernel/nullfs.ko...done.
Loaded symbols for /boot/kernel/nullfs.ko
Reading symbols from /boot/kernel/fdescfs.ko...done.
Loaded symbols for /boot/kernel/fdescfs.ko
Reading symbols from /boot/kernel/i915kms.ko...done.
Loaded symbols for /boot/kernel/i915kms.ko
Reading symbols from /boot/kernel/drm2.ko...done.
Loaded symbols for /boot/kernel/drm2.ko
Reading symbols from /boot/kernel/iicbus.ko...done.
Loaded symbols for /boot/kernel/iicbus.ko
Reading symbols from /boot/kernel/iic.ko...done.
Loaded symbols for /boot/kernel/iic.ko
Reading symbols from /boot/kernel/iicbb.ko...done.
Loaded symbols for /boot/kernel/iicbb.ko
#0  cpustop_handler () at /usr/src/sys/x86/x86/mp_x86.c:1324
1324    CPU_SET_ATOMIC(cpu, _cpus);
(kgdb) bt
#0  cpustop_handler () at /usr/src/sys/x86/x86/mp_x86.c:1324
#1  0x80e29fb4 in ipi_nmi_handler () at 
/usr/src/sys/x86/x86/mp_x86.c:1280

#2  0x80d09a79 in trap (frame=0x8158bef0)
    at /usr/src/sys/amd64/amd64/trap.c:188
#3  0x80cec054 in nmi_calltrap () at 
/usr/src/sys/amd64/amd64/exception.S:633
#4  0x80e1aaef in acpi_cpu_idle_mwait (mwait_hint=0) at 
cpufunc.h:611

Previous frame inner to this frame (corrupt stack?)
Current language:  auto; currently minimal

kgdb is over my head, but I can provide more details under some guidance.

Hope it helps,
Juan

___
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: ACPI panic on boot with new Lua loader and other minor issues

[Juan Ramón Molina Menor]

Le 19/02/2018 à 21:21, Kyle Evans a écrit :> Hello!


On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor <lis...@club.fr> wrote:

I have done a full build of r329555 to test the new Lua boot loader.

Both the new and the old kernels panic after being loaded with:

panic: running without device atpic requires a local APIC

For reasons unknown, ACPI is off, as shown by David Wolfskill in a previous
message:
https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html

OK show hint.acpi.0.disabled
1

Setting ACPI to On resolves the issue.



Hi Kyle.


As David noted, this should actually Just Work (TM) now. Can you break
into a loader prompt with just the forth loader and tell me what "show
hint.acpi.0.rsdp" looks like?

OK show hint.acpi.0.rsdp
Command error

I tested both with hint.acpi.0.disabled= 1 and 0.





Also, I can not stop boot2 to try to use the copy of the Forth loader: the
keyboard only becomes responsive at the loader stage.


Hmm...

In fact, I don’t think this has ever worked here… I’ve found a very old (July 
2016) FreeBSD 12 memstick and neither can I stop the boot2 stage.



There is an error during this stage:

Loading /boot/defaults/loader.conf
Failed to open config: ’/boot/loader.conf.local’


David's diagnosis of this is right- this is more of an informational
message that you don't need to worry about.

Thanks.



Moreover, the "boot [kernel]" loader command does not work:

OK ls /boot/kernel.old/kernel
 /boot/kernel.old/kernel
OK boot kernel.old
Command failed
OK boot /boot/kernel.old/kernel
Command failed
OK boot kernel
Command failed

On the other hand, just "boot" works.


It seems that the Forth loader might be doing something sneaky and
replacing the standard common "boot" with a Forth boot that handles
this a lot better. CC'ing dteske@ so they can confirm.


Finally, the double lines drawing a frame around the loader menu do not work
with the new loader and are replaced by ? characters in a box.


Interesting, I'll look into that... anything interesting/unique about
your setup? r329387 should have addressed one potential cause of this,
but I see you're past that.

I’m using a memory stick to boot a Lenovo ThinkPad S440 (i3-4030U processor, 
4GB RAM). The only thing I can think of is that the ACPI of this model is not 
well supported, but the errors I have are related to thermal zones…:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201678

To build the memstick I’m using a 11.1-RELEASE VM under Hyper-V, with ccache 
and WITH_META_MODE, but this build process has been working nicely for months.

The kernel is based on GENERIC-NODEBUG and has been also working reliably:

juan@Server ~ % cat /root/kernels/MEMSTICK
include GENERIC-NODEBUG

ident   MEMSTICK

nodevicefdc

nodevicech
nodevicesa
nodeviceses

nodeviceamr
nodevicearcmsr
nodeviceciss
nodevicedpt
nodevicehptmv
nodevicehptnr
nodevicehptrr
nodevicehpt27xx
nodeviceiir
nodeviceips
nodevicemly
nodevicetwa
nodevicetws

nodeviceaac
nodeviceaacp
nodeviceaacraid
nodeviceida
nodevicemfi
nodevicemlx
nodevicemrsas
nodevicepmspcv
nodevicetwe

nodevicenvme
nodevicenvd

nodevicevirtio
nodevicevirtio_pci
nodevicevtnet
nodevicevirtio_blk
nodevicevirtio_scsi
nodevicevirtio_balloon

nooptions   HYPERV
nodevicehyperv

nooptions   XENHVM
nodevicexenpci

nodevicevmx


There is maybe something fishy in my src.conf, where I disable a lot of things 
to slim down the memstick, but still, it has been stable till now:

juan@Server ~ % cat /etc/src.conf
# For memory sticks

WITH_CCACHE_BUILD=

WITHOUT_ACCT=
WITHOUT_AMD=
WITHOUT_ATM=
WITHOUT_AUTHPF=
WITHOUT_AUTOFS=
WITHOUT_BHYVE=
WITHOUT_BLACKLIST=
# iwm does not support Bluetooth
WITHOUT_BLUETOOTH=
WITHOUT_BOOTPARAMD=
WITHOUT_BOOTPD=
# WITHOUT_BSDINSTALL enforced by WITHOUT_DIALOG
WITHOUT_BSNMP=
WITHOUT_CALENDAR=
# Don't set this when building HEAD from RELENG
# WITHOUT_CROSS_COMPILER=
WITHOUT_CTM=
WITHOUT_DEBUG_FILES=
#WITHOUT_DIALOG=
WITHOUT_DICT=
WITHOUT_EE=
WITHOUT_EXAMPLES=
WITHOUT_FDT=
WITHOUT_FINGER=
WITHOUT_FLOPPY=
# For testing the Lua loader (WITH_LOADER_LUA)
WITHOUT_FORTH=
WITHOUT_FREEBSD_UPDATE=
WITHOUT_GAMES=
WITHOUT_GCOV=
WITHOUT_GPIO=
# You disable Kerberos later, but try to keep GSSAPI for curl > pkg
# But this does not work, base Kerberos is required
#WITH_GSSAPI=
WITHOUT_GSSAPI=
WITHOUT_HAST=
WITHOUT_HESIOD=
WITHOUT_HTML=
WITHOUT_HYPERV=
WITHOUT_IPFILTER=
WITHOUT_IPFW=
WITHOUT_ISCSI=
WITHOUT_JAIL=
WITHOUT_KERBEROS=
WITHOUT_KERNEL_SYMBOLS=
WITHOUT_KVM=
WITHOUT_LDNS=
# This disables moused
#WITHOUT_LEGACY_CONSOLE=
WITHOUT_LLDB=
# This requires WITHOUT_FORTH
WITH_LOADER_LUA=
# This breaks settin

Re: ACPI panic on boot with new Lua loader and other minor issues

[Juan Ramón Molina Menor]

Le 19/02/2018 à 21:21, Kyle Evans a écrit :

Hello!

On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor <lis...@club.fr> wrote:

I have done a full build of r329555 to test the new Lua boot loader.

Both the new and the old kernels panic after being loaded with:

panic: running without device atpic requires a local APIC

For reasons unknown, ACPI is off, as shown by David Wolfskill in a previous
message:
https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html

OK show hint.acpi.0.disabled
1

Setting ACPI to On resolves the issue.




Hi Kyle.


As David noted, this should actually Just Work (TM) now. Can you break
into a loader prompt with just the forth loader and tell me what "show
hint.acpi.0.rsdp" looks like?


OK show hint.acpi.0.rsdp
Command error

I tested both with hint.acpi.0.disabled= 1 and 0.





Also, I can not stop boot2 to try to use the copy of the Forth loader: the
keyboard only becomes responsive at the loader stage.


Hmm...


In fact, I don’t think this has ever worked here… I’ve found a very old 
(July 2016) FreeBSD 12 memstick and neither can I stop the boot2 stage.




There is an error during this stage:

Loading /boot/defaults/loader.conf
Failed to open config: ’/boot/loader.conf.local’


David's diagnosis of this is right- this is more of an informational
message that you don't need to worry about.


Thanks.



Moreover, the "boot [kernel]" loader command does not work:

OK ls /boot/kernel.old/kernel
 /boot/kernel.old/kernel
OK boot kernel.old
Command failed
OK boot /boot/kernel.old/kernel
Command failed
OK boot kernel
Command failed

On the other hand, just "boot" works.


It seems that the Forth loader might be doing something sneaky and
replacing the standard common "boot" with a Forth boot that handles
this a lot better. CC'ing dteske@ so they can confirm.


Finally, the double lines drawing a frame around the loader menu do not work
with the new loader and are replaced by ? characters in a box.


Interesting, I'll look into that... anything interesting/unique about
your setup? r329387 should have addressed one potential cause of this,
but I see you're past that.


I’m using a memory stick to boot a Lenovo ThinkPad S440 (i3-4030U 
processor, 4GB RAM). The only thing I can think of is that the ACPI of 
this model is not well supported, but the errors I have are related to 
thermal zones…:

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

To build the memstick I’m using a 11.1-RELEASE VM under Hyper-V, with 
ccache and WITH_META_MODE, but this build process has been working 
nicely for months.


The kernel is based on GENERIC-NODEBUG and has been also working reliably:

juan@Server ~ % cat /root/kernels/MEMSTICK
include GENERIC-NODEBUG

ident   MEMSTICK

nodevicefdc

nodevicech
nodevicesa
nodeviceses

nodeviceamr
nodevicearcmsr
nodeviceciss
nodevicedpt
nodevicehptmv
nodevicehptnr
nodevicehptrr
nodevicehpt27xx
nodeviceiir
nodeviceips
nodevicemly
nodevicetwa
nodevicetws

nodeviceaac
nodeviceaacp
nodeviceaacraid
nodeviceida
nodevicemfi
nodevicemlx
nodevicemrsas
nodevicepmspcv
nodevicetwe

nodevicenvme
nodevicenvd

nodevicevirtio
nodevicevirtio_pci
nodevicevtnet
nodevicevirtio_blk
nodevicevirtio_scsi
nodevicevirtio_balloon

nooptions   HYPERV
nodevicehyperv

nooptions   XENHVM
nodevicexenpci

nodevicevmx


There is maybe something fishy in my src.conf, where I disable a lot of 
things to slim down the memstick, but still, it has been stable till now:


juan@Server ~ % cat /etc/src.conf
# For memory sticks

WITH_CCACHE_BUILD=

WITHOUT_ACCT=
WITHOUT_AMD=
WITHOUT_ATM=
WITHOUT_AUTHPF=
WITHOUT_AUTOFS=
WITHOUT_BHYVE=
WITHOUT_BLACKLIST=
# iwm does not support Bluetooth
WITHOUT_BLUETOOTH=
WITHOUT_BOOTPARAMD=
WITHOUT_BOOTPD=
# WITHOUT_BSDINSTALL enforced by WITHOUT_DIALOG
WITHOUT_BSNMP=
WITHOUT_CALENDAR=
# Don't set this when building HEAD from RELENG
# WITHOUT_CROSS_COMPILER=
WITHOUT_CTM=
WITHOUT_DEBUG_FILES=
#WITHOUT_DIALOG=
WITHOUT_DICT=
WITHOUT_EE=
WITHOUT_EXAMPLES=
WITHOUT_FDT=
WITHOUT_FINGER=
WITHOUT_FLOPPY=
# For testing the Lua loader (WITH_LOADER_LUA)
WITHOUT_FORTH=
WITHOUT_FREEBSD_UPDATE=
WITHOUT_GAMES=
WITHOUT_GCOV=
WITHOUT_GPIO=
# You disable Kerberos later, but try to keep GSSAPI for curl > pkg
# But this does not work, base Kerberos is required
#WITH_GSSAPI=
WITHOUT_GSSAPI=
WITHOUT_HAST=
WITHOUT_HESIOD=
WITHOUT_HTML=
WITHOUT_HYPERV=
WITHOUT_IPFILTER=
WITHOUT_IPFW=
WITHOUT_ISCSI=
WITHOUT_JAIL=
WITHOUT_KERBEROS=
WITHOUT_KERNEL_SYMBOLS=
WITHOUT_KVM=
WITHOUT_LDNS=
# This disables moused
#WITHOUT_LEGACY_CONSOLE=
WITHOUT_LLDB=
# This requires WITHOUT_FORTH
WITH_LOADER_LUA=
# This bre

Re: ACPI panic on boot with new Lua loader and other minor issues

[Juan Ramón Molina Menor]

Le 19/02/2018 à 15:39, David Wolfskill a écrit :

On Mon, Feb 19, 2018 at 03:21:50PM +0100, Juan Ramón Molina Menor wrote:

I have done a full build of r329555 to test the new Lua boot loader.

Both the new and the old kernels panic after being loaded with:

panic: running without device atpic requires a local APIC

For reasons unknown, ACPI is off, as shown by David Wolfskill in a
previous message:
https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html


That has been fixed (for me, at least).  My last two build/smoke-tests
were at r329517 and r329561; I believe that r329366 was the fix for ACPI
detection/setting.


OK show hint.acpi.0.disabled
1

Setting ACPI to On resolves the issue.

Also, I can not stop boot2 to try to use the copy of the Forth loader:
the keyboard only becomes responsive at the loader stage.



There is an error during this stage:

Loading /boot/defaults/loader.conf
Failed to open config: ’/boot/loader.conf.local’


IIUC, that's merely an informational message, not an error.  (None of my
systems have a /boot/loader.conf.local, either.)


Moreover, the "boot [kernel]" loader command does not work:

OK ls /boot/kernel.old/kernel
  /boot/kernel.old/kernel
OK boot kernel.old
Command failed
OK boot /boot/kernel.old/kernel
Command failed
OK boot kernel
Command failed

On the other hand, just "boot" works.


And the Lua loader permits kernel selection, as well (as the Forth
laoder has).


Finally, the double lines drawing a frame around the loader menu do not
work with the new loader and are replaced by ? characters in a box.


That has also been fixed for me (as of r329517).


Hope it helps,
Juan



Peace,
david


Thanks David. It’s strange I’m having issues resolved for you in commits 
older than the one I used here…


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

ACPI panic on boot with new Lua loader and other minor issues

[Juan Ramón Molina Menor]

Moreover, the "boot [kernel]" loader command does not work:

OK ls /boot/kernel.old/kernel
 /boot/kernel.old/kernel
OK boot kernel.old
Command failed
OK boot /boot/kernel.old/kernel
Command failed
OK boot kernel
Command failed



I forgot that I tried starting with "unload", which seems to work, but 
does not correct the issue:


OK unload
OK boot kernel.old
Command failed
___
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"

ACPI panic on boot with new Lua loader and other minor issues

[Juan Ramón Molina Menor]

I have done a full build of r329555 to test the new Lua boot loader.

Both the new and the old kernels panic after being loaded with:

panic: running without device atpic requires a local APIC

For reasons unknown, ACPI is off, as shown by David Wolfskill in a 
previous message:

https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html

OK show hint.acpi.0.disabled
1

Setting ACPI to On resolves the issue.

Also, I can not stop boot2 to try to use the copy of the Forth loader: 
the keyboard only becomes responsive at the loader stage.


There is an error during this stage:

Loading /boot/defaults/loader.conf
Failed to open config: ’/boot/loader.conf.local’

Moreover, the "boot [kernel]" loader command does not work:

OK ls /boot/kernel.old/kernel
/boot/kernel.old/kernel
OK boot kernel.old
Command failed
OK boot /boot/kernel.old/kernel
Command failed
OK boot kernel
Command failed

On the other hand, just "boot" works.

Finally, the double lines drawing a frame around the loader menu do not 
work with the new loader and are replaced by ? characters in a box.


Hope it helps,
Juan
___
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"

Panic on Boot - Current AMD64

[Juan Ramón Molina Menor]

On Wed, Feb 07, 2018 at 12:18:26PM +0100, Juan Ramón Molina Menor wrote:
J> > Same panic here with HEAD from this afternoon in a Lenovo ThinkPad S440 
J> > with 4 GB.
J> > 
J> > Workaround: break into the loader prompt and:
J> > 
J> > set vm.boot_pages=120

J> > boot
J> > 
J> > When booting kernel.old, vm.boot_pages is 64.
J> > 
J> > There is something wrong with r328916.
J> 
J> Recent commits 328955, 328953 and 328952 by glebius@ do not resolve the 
J> issue here.


r328982 should fix the boot without specifing vm.boot_pages.

I'm sorry for problems.

--
Gleb Smirnoff


Yes, it is fixed, thanks!
___
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"

Panic on Boot - Current AMD64

[Juan Ramón Molina Menor]

I get panic on boot from current kernel.
Since last night - changes to vm system ?
World is Current as of this morning

FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.0-CURRENT #0 r328948: Tue Feb  6 11:30:57 PST 2018
 root at pozo.com 
:/usr/src/sys/amd64/compile/pozo amd64

FreeBSD clang version 6.0.0 (branches/release_60 324090) (based on LLVM 6.0.0)
Table 'FACP' at 0xdfbc57e8
Table 'APIC' at 0xdfbc585c
Table 'ASF!' at 0xdfbc58e0
Table 'MCFG' at 0xdfbc5943
Table 'TCPA' at 0xdfbc597f
Table 'SLIC' at 0xdfbc59b1
Table 'HPET' at 0xdfbc5b27
ACPI: No SRAT table found
panic: UMA: Increase vm.boot_pages
cpuid = 0
time = 1
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0x820bc820
vpanic() at vpanic+0x18d/frame 0x820bc880
panic() at panic+0x43/frame 0x820bc8e0
startup_alloc() at startup_alloc+0x19c/frame 0x820bc940
keg_alloc_slab() at keg_alloc_slab+0xef/frame 0x820bc9c0
keg_fetch_slab() at keg_fetch_slab+0x128/frame 0x820bca20
zone_fetch_slab() at zone_fetch_slab+0x69/frame 0x820bca50
zone_import() at zone_import+0x5a/frame 0x820bcaa0
zone_alloc_item() at zone_alloc_item+0x3b/frame 0x820bcae0
uma_startup() at uma_startup+0x3d3/frame 0x820bcbd0
vm_page_startup() at vm_page_startup+0x338/frame 0x820bcc20
vm_mem_init() at vm_mem_init+0x1d/frame 0x820bcc50
mi_startup() at mi_startup+0x118/frame 0x820bcc70
btext() at btext+0x2c
KDB: enter: panic
[ thread pid 0 tid 0 ]
Stopped at  kdb_enter+0x3b: movq$0,kdb_why
db> bt
Tracing pid 0 tid 0 td 0x80ff1240
kdb_enter() at kdb_enter+0x3b/frame 0x820bc820
vpanic() at vpanic+0x1aa/frame 0x820bc880
panic() at panic+0x43/frame 0x820bc8e0
startup_alloc() at startup_alloc+0x19c/frame 0x820bc940
keg_alloc_slab() at keg_alloc_slab+0xef/frame 0x820bc9c0
keg_fetch_slab() at keg_fetch_slab+0x128/frame 0x820bca20
zone_fetch_slab() at zone_fetch_slab+0x69/frame 0x820bca50
zone_import() at zone_import+0x5a/frame 0x820bcaa0
zone_alloc_item() at zone_alloc_item+0x3b/frame 0x820bcae0
uma_startup() at uma_startup+0x3d3/frame 0x820bcbd0
vm_page_startup() at vm_page_startup+0x338/frame 0x820bcc20
vm_mem_init() at vm_mem_init+0x1d/frame 0x820bcc50
mi_startup() at mi_startup+0x118/frame 0x820bcc70
btext() at btext+0x2c
db>



Same panic here with HEAD from this afternoon in a Lenovo ThinkPad S440 
with 4 GB.


Workaround: break into the loader prompt and:

set vm.boot_pages=120
boot

When booting kernel.old, vm.boot_pages is 64.

There is something wrong with r328916.

Hope it helps,
Juan


Hi!

Recent commits 328955, 328953 and 328952 by glebius@ do not resolve the 
issue here.


Hope it helps,
Juan
___
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"

Panic on Boot - Current AMD64

[Juan Ramón Molina Menor]

I get panic on boot from current kernel.
Since last night - changes to vm system ?
World is Current as of this morning

FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.0-CURRENT #0 r328948: Tue Feb  6 11:30:57 PST 2018
 root at pozo.com 
:/usr/src/sys/amd64/compile/pozo amd64

FreeBSD clang version 6.0.0 (branches/release_60 324090) (based on LLVM 6.0.0)
Table 'FACP' at 0xdfbc57e8
Table 'APIC' at 0xdfbc585c
Table 'ASF!' at 0xdfbc58e0
Table 'MCFG' at 0xdfbc5943
Table 'TCPA' at 0xdfbc597f
Table 'SLIC' at 0xdfbc59b1
Table 'HPET' at 0xdfbc5b27
ACPI: No SRAT table found
panic: UMA: Increase vm.boot_pages
cpuid = 0
time = 1
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0x820bc820
vpanic() at vpanic+0x18d/frame 0x820bc880
panic() at panic+0x43/frame 0x820bc8e0
startup_alloc() at startup_alloc+0x19c/frame 0x820bc940
keg_alloc_slab() at keg_alloc_slab+0xef/frame 0x820bc9c0
keg_fetch_slab() at keg_fetch_slab+0x128/frame 0x820bca20
zone_fetch_slab() at zone_fetch_slab+0x69/frame 0x820bca50
zone_import() at zone_import+0x5a/frame 0x820bcaa0
zone_alloc_item() at zone_alloc_item+0x3b/frame 0x820bcae0
uma_startup() at uma_startup+0x3d3/frame 0x820bcbd0
vm_page_startup() at vm_page_startup+0x338/frame 0x820bcc20
vm_mem_init() at vm_mem_init+0x1d/frame 0x820bcc50
mi_startup() at mi_startup+0x118/frame 0x820bcc70
btext() at btext+0x2c
KDB: enter: panic
[ thread pid 0 tid 0 ]
Stopped at  kdb_enter+0x3b: movq$0,kdb_why
db> bt
Tracing pid 0 tid 0 td 0x80ff1240
kdb_enter() at kdb_enter+0x3b/frame 0x820bc820
vpanic() at vpanic+0x1aa/frame 0x820bc880
panic() at panic+0x43/frame 0x820bc8e0
startup_alloc() at startup_alloc+0x19c/frame 0x820bc940
keg_alloc_slab() at keg_alloc_slab+0xef/frame 0x820bc9c0
keg_fetch_slab() at keg_fetch_slab+0x128/frame 0x820bca20
zone_fetch_slab() at zone_fetch_slab+0x69/frame 0x820bca50
zone_import() at zone_import+0x5a/frame 0x820bcaa0
zone_alloc_item() at zone_alloc_item+0x3b/frame 0x820bcae0
uma_startup() at uma_startup+0x3d3/frame 0x820bcbd0
vm_page_startup() at vm_page_startup+0x338/frame 0x820bcc20
vm_mem_init() at vm_mem_init+0x1d/frame 0x820bcc50
mi_startup() at mi_startup+0x118/frame 0x820bcc70
btext() at btext+0x2c
db>



Same panic here with HEAD from this afternoon in a Lenovo ThinkPad S440 
with 4 GB.


Workaround: break into the loader prompt and:

set vm.boot_pages=120
boot

When booting kernel.old, vm.boot_pages is 64.

There is something wrong with r328916.

Hope it helps,
Juan


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

r314131: link_elf_obj: symbol iwm7265_cfg undefined

[Juan Ramón Molina Menor]

On Thu, Feb 23, 2017 at 1:56 PM, Andreas Nilsson > wrote:


>//>//>/On Thu, Feb 23, 2017 at 1:29 PM, Jakob Alvermark alvermark.net 
> />/wrote: />//>>/Hi, />>//>>/Updated to r314131 and my iwm no longer works. (It is a 7265) />>/Dmesg says: />>/link_elf_obj: symbol iwm7265_cfg undefined />>/linker_load_file: Unsupported file type />>//>>/Jakob />>//>>/___ />>/freebsd-current at freebsd.org 
 mailing 
list />>/https://lists.freebsd.org/mailman/listinfo/freebsd-current />>/To unsubscribe, send any mail to "freebsd-current-unsubscribe at 
freebsd.org  />>/" />>//>//>/Hello, />//>/I can second that, although I'm on FreeBSD 12.0-CURRENT #3 />/bb6561e09c3(drm-next) with an ac8260. />//>/Best regards />/Andreas />//

It would seem a simple mistake in  a Makefile: see attached diff.

The module loads for me with that patch applied.

Best regards
Andreas
-- next part --
diff --git a/sys/modules/iwm/Makefile b/sys/modules/iwm/Makefile
index 2d076906ce9..f8ae70650cb 100644
--- a/sys/modules/iwm/Makefile
+++ b/sys/modules/iwm/Makefile
@@ -7,6 +7,7 @@ KMOD=   if_iwm
  SRCS= if_iwm.c if_iwm_binding.c if_iwm_util.c if_iwm_phy_db.c
  SRCS+=if_iwm_mac_ctxt.c if_iwm_phy_ctxt.c if_iwm_time_event.c
  SRCS+=if_iwm_power.c if_iwm_scan.c if_iwm_led.c if_iwm_notif_wait.c
+SRCS+=  if_iwm_7000.c if_iwm_8000.c
  # bus layer
  SRCS+=if_iwm_pcie_trans.c
  SRCS+=device_if.h bus_if.h pci_if.h opt_wlan.h


Hi! Please add your findings to the PR:

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

___
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: dmesg: can't reuse a leaf (ixl_rx_miss_bufs)!

[Juan Ramón Molina Menor]

Le 26/05/2016 11:06, K. Macy a écrit :

It will be fixed in the next iflib update.



Nice, thank you.

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

dmesg: can't reuse a leaf (ixl_rx_miss_bufs)!

[Juan Ramón Molina Menor]

Hi!

In three different machines running HEAD I have this message in the very 
first lines of the dmesg output:


can't reuse a leaf (ixl_rx_miss_bufs)!

I don’t remember seeing it before and I have not configured any ixl 
device. It seems harmless, but I wonder if it’s a sign of a bug somewhere.


Cheers,
Juan
___
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: newcons splash screen

[Juan Ramón Molina Menor]

Hello,
is it possible to use a splash screen yet with newcons? I've been looking at 
the source code for VT, and it would appear there has been some work done 
towards this?

https://github.com/freebsd/freebsd/blob/master/sys/dev/vt/vt.h  


Also the wiki page shows limited support:

https://wiki.freebsd.org/Newcons  


I've tried the standard method of enabling a splash screen but it of course 
does not work. I don't think I was able to get it to work with syscons either 
whereas it used to work.

https://www.freebsd.org/doc/handbook/boot-splash.html  


Is there another way? Or is it still not ready yet?

Joe Maloney

Hi!

Maybe you are already aware of it, but in 2014 there was a Google Summer 
of Code project on improving the bootsplash:

https://wiki.freebsd.org/SummerOfCode2014/Bootsplash

It worked well with sc(4), but I don’t know wether it applies to vt(4)…

Juan
___
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 compile with clang & ccache

[Juan Ramón Molina Menor]

Le 25/11/2015 19:09, Juan Molina a écrit :

On 11/24/2015 1:31 AM, M - Krasznai András wrote:
>/What can I do to eliminate the ccache error during installworld 
apart from not using ccache? /

I would recommend not setting CC or CCACHE_PATH in make.conf and using
the new WITH_CCACHE_BUILD=yes option instead.

--
Regards,
Bryan Drewery


Hi.

I’m seeing the same ccache errors and I do not have CC or CCACHE_PATH 
defined anywhere. Only WITH_CCACHE_BUILD and WITH_FAST_DEPEND in 
src.conf.


Best regards,
Juan


I have an update on this. In fact, I was wrong concerning the content of 
my src.conf: there was other lines, notably:


WITHOUT_CROSS_COMPILER=

As soon as I commented it out, make installworld stopped emitting the 
ccache errors and requiring COMPILER_TYPE="clang" to work. I made 
another build with the line enabled and again both errors returned. A 
third build without this line confirmed the solution. I will try again 
to ensure I’m not following a false track, after updating sources, as I 
see a lot of recent commits related to the build system.


I hope it rings a bell somewhere…

Best regards,
Juan
___
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 compile with clang & ccache

[Juan Ramón Molina Menor]

Le 25/11/2015 22:11, Bryan Drewery a écrit :

On 11/25/2015 12:59 PM, Juan Ramón Molina Menor wrote:

Le 25/11/2015 19:50, Bryan Drewery a écrit :

On 11/25/2015 10:09 AM, Juan Molina wrote:

On 11/24/2015 1:31 AM, M - Krasznai András wrote:

/What can I do to eliminate the ccache error during installworld

apart from not using ccache? /
I would recommend not setting CC or CCACHE_PATH in make.conf and using
the new WITH_CCACHE_BUILD=yes option instead.

--
Regards,
Bryan Drewery

Hi.

I’m seeing the same ccache errors and I do not have CC or CCACHE_PATH
defined anywhere. Only WITH_CCACHE_BUILD and WITH_FAST_DEPEND in
src.conf.


WITH_FAST_DEPEND is not related.

OK, thanks. I was referring to the content of /etc/src.conf. By the way,
there is no /etc/make.conf in this system.


Are you building and installing as a different user? Using a different
MAKEOBJDIRPREFIX in build and install?

Not at all, just following the /etc/src/UPDATING instructions, as root:

# cd /usr/src
# svn up
# make -j2 buildworld
# make -j2 kernel

# mergemaster -Fp
# make installworld COMPILER_TYPE="clang"

# mergemaster -Fi
# make delete-old


Do you have CCACHE_PATH in your environment?

Yes, it is set in /etc/csh.cshrc as indicate the ccache instructions:

# echo $CCACHE_PATH
/usr/bin:/usr/local/bin


Run 'make ccache-print-options|grep path'. It should have no value.

# make ccache-print-options | grep path
(environment) path =



Which branch and revision is this?


 11.0-CURRENT r291280 (yesterday).
___
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 compile with clang & ccache

[Juan Ramón Molina Menor]

Le 25/11/2015 19:50, Bryan Drewery a écrit :

On 11/25/2015 10:09 AM, Juan Molina wrote:

On 11/24/2015 1:31 AM, M - Krasznai András wrote:

/What can I do to eliminate the ccache error during installworld

apart from not using ccache? /
I would recommend not setting CC or CCACHE_PATH in make.conf and using
the new WITH_CCACHE_BUILD=yes option instead.

--
Regards,
Bryan Drewery

Hi.

I’m seeing the same ccache errors and I do not have CC or CCACHE_PATH
defined anywhere. Only WITH_CCACHE_BUILD and WITH_FAST_DEPEND in src.conf.


WITH_FAST_DEPEND is not related.
OK, thanks. I was referring to the content of /etc/src.conf. By the way, 
there is no /etc/make.conf in this system.



Are you building and installing as a different user? Using a different
MAKEOBJDIRPREFIX in build and install?

Not at all, just following the /etc/src/UPDATING instructions, as root:

# cd /usr/src
# svn up
# make -j2 buildworld
# make -j2 kernel

# mergemaster -Fp
# make installworld COMPILER_TYPE="clang"

# mergemaster -Fi
# make delete-old


Do you have CCACHE_PATH in your environment?

Yes, it is set in /etc/csh.cshrc as indicate the ccache instructions:

# echo $CCACHE_PATH
/usr/bin:/usr/local/bin


Run 'make ccache-print-options|grep path'. It should have no value.

# make ccache-print-options | grep path
(environment) path =

Best regards,
Juan
___
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: [CFT] Buildworld ccache support

[Juan Ramón Molina Menor]

Hi Bryan.

Since ccache support was added to base in r290526 I’m not seeing the 
issues I had previously reported. I have now WITH_CCACHE_BUILD in 
src.conf and no make.conf and ccache is working as expected.


Thank you!
Juan
___
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: [CFT] Buildworld ccache support

[Juan Ramón Molina Menor]

Hi Bryan.


Why not cc me or even send this re: to the original thread?


I’m not used to mailing lists etiquette, sorry. I thought receiving two 
copies of the same message would bother you. Now I realize there are 
digests and maybe other less direct methods for message delivery.


Best regards,
Juan
___
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: [CFT] Buildworld ccache support

[Juan Ramón Molina Menor]

Why not cc me or even send this re: to the original thread?


On 10/20/2015 6:32 AM, Juan Ramón Molina Menor wrote:

Hi!

I’m certainly doing it wrong, because CCACHE does not kick in after
applying the patch and modifying make.conf. CCACHE stats ('ccache -z'
followed by 'ccache -s') remain at zero during buildworld while they
used to reflect the cache miss/hits before.

# cat /etc/make.conf
WITH_CCACHE_BUILD=

 # svn diff /usr/src/share/mk/local.init.mk
Index: /usr/src/share/mk/local.init.mk
===
--- /usr/src/share/mk/local.init.mk (revision 289627)
+++ /usr/src/share/mk/local.init.mk (working copy)
@@ -38,3 +38,37 @@
 HOST_CFLAGS+= -DHOSTPROG
 CFLAGS+= ${HOST_CFLAGS}
 .endif
+
+# Handle ccache after CC is determined.  If CC is at some specific path
then
+# we must prepend the ccache wrapper.  Otherwise we can just prepend
PATH with
+# the wrapper location, which is a more safe solution since it avoids
spaces
+# and compiler type guessing based on filename.
+LOCALBASE?=/usr/local
+CCACHE_WRAPPER_PATH?=  ${LOCALBASE}/libexec/ccache
+CCACHE_PATH?=  ${LOCALBASE}/bin/ccache
+.if defined(WITH_CCACHE_BUILD) && !defined(NOCCACHE) && \
+${CC:M*ccache*} == "" && exists(${CCACHE_PATH})
+# Handle compiler changes properly.  This avoids needing to use the
'world'
+# wrappers.
+CCACHE_COMPILERCHECK?= content
+.export CCACHE_COMPILERCHECK
+.if ${CC:M/*} == ""
+# Can use PATH.
+PATH:= ${CCACHE_WRAPPER_PATH}:${PATH}
+.export PATH
+.else
+# Must prepend CC.
+CC:=   ${CCACHE_PATH} ${CC}
+CXX:=  ${CCACHE_PATH} ${CXX}
+CPP:=  ${CCACHE_PATH} ${CPP}
+.if defined(HOST_CC)
+HOST_CC:=  ${CCACHE_PATH} ${HOST_CC}
+.endif
+.if defined(HOST_CXX)
+HOST_CXX:= ${CCACHE_PATH} ${HOST_CXX}
+.endif
+.if defined(HOST_CPP)
+HOST_CPP:= ${CCACHE_PATH} ${HOST_CPP}
+.endif
+.endif
+.endif # WITH_CCACHE_BUILD

If I recover the old make.conf, CCACHE works again for a buildworld.

# cat /etc/make.conf.old
.if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*))
.if !defined(NOCCACHE) && exists(/usr/local/libexec/ccache/world/cc)
CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/cc,1}
CXX:=${CXX:C,^c\+\+,/usr/local/libexec/ccache/world/c++,1}
.endif
.endif

Maybe I misconfigured CCACHE when I first installed it?



This doesn't check for a value of WITH_CCACHE_BUILD, just being defined
is enough.

I've been fixing some subtle bugs such as in the lib32 build, but
overall I've had ccache -s growing while using the patch.  If you
already have ccache in CC it won't apply it.

Are you building head from head or some other configuration?


HEAD from HEAD, updated regularly in /usr/src with SVN. Following the 
standard procedure for updating described in /usr/src/UPDATING. ccache 
installed as explained by the package message. Nothing special, really.


I’ll take some time when possible to recheck all the settings and be 
back to you.


Best regards,
Juan
___
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: [CFT] Buildworld ccache support

[Juan Ramón Molina Menor]

Le 20/10/2015 17:50, Freddie Cash a écrit :

On Tue, Oct 20, 2015 at 6:32 AM, Juan Ramón Molina Menor <lis...@club.fr
<mailto:lis...@club.fr>>wrote:

Hi!

I’m certainly doing it wrong, because CCACHE does not kick in after
applying the patch and modifying make.conf. CCACHE stats ('ccache
-z' followed by 'ccache -s') remain at zero during buildworld while
they used to reflect the cache miss/hits before.

# cat /etc/make.conf
WITH_CCACHE_BUILD=


​You need to actually set this to a value, in order for the variable to
be defined.

WITH_CCACHE_BUILD=yes
WITH_CCACHE_BUILD=something
WITH_CCACHE_BUILD=whatever

It doesn't matter what it's set to, but it has to be set to something.​


Thanks for the tip, but I had already tried. Unfortunately there is 
something else which escapes me…


Best regards,
Juan
___
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"

[CFT] Buildworld ccache support

[Juan Ramón Molina Menor]

Hi!

I’m certainly doing it wrong, because CCACHE does not kick in after 
applying the patch and modifying make.conf. CCACHE stats ('ccache -z' 
followed by 'ccache -s') remain at zero during buildworld while they 
used to reflect the cache miss/hits before.


# cat /etc/make.conf
WITH_CCACHE_BUILD=

 # svn diff /usr/src/share/mk/local.init.mk
Index: /usr/src/share/mk/local.init.mk
===
--- /usr/src/share/mk/local.init.mk (revision 289627)
+++ /usr/src/share/mk/local.init.mk (working copy)
@@ -38,3 +38,37 @@
 HOST_CFLAGS+= -DHOSTPROG
 CFLAGS+= ${HOST_CFLAGS}
 .endif
+
+# Handle ccache after CC is determined.  If CC is at some specific path 
then
+# we must prepend the ccache wrapper.  Otherwise we can just prepend 
PATH with
+# the wrapper location, which is a more safe solution since it avoids 
spaces

+# and compiler type guessing based on filename.
+LOCALBASE?=/usr/local
+CCACHE_WRAPPER_PATH?=  ${LOCALBASE}/libexec/ccache
+CCACHE_PATH?=  ${LOCALBASE}/bin/ccache
+.if defined(WITH_CCACHE_BUILD) && !defined(NOCCACHE) && \
+${CC:M*ccache*} == "" && exists(${CCACHE_PATH})
+# Handle compiler changes properly.  This avoids needing to use the 'world'
+# wrappers.
+CCACHE_COMPILERCHECK?= content
+.export CCACHE_COMPILERCHECK
+.if ${CC:M/*} == ""
+# Can use PATH.
+PATH:= ${CCACHE_WRAPPER_PATH}:${PATH}
+.export PATH
+.else
+# Must prepend CC.
+CC:=   ${CCACHE_PATH} ${CC}
+CXX:=  ${CCACHE_PATH} ${CXX}
+CPP:=  ${CCACHE_PATH} ${CPP}
+.if defined(HOST_CC)
+HOST_CC:=  ${CCACHE_PATH} ${HOST_CC}
+.endif
+.if defined(HOST_CXX)
+HOST_CXX:= ${CCACHE_PATH} ${HOST_CXX}
+.endif
+.if defined(HOST_CPP)
+HOST_CPP:= ${CCACHE_PATH} ${HOST_CPP}
+.endif
+.endif
+.endif # WITH_CCACHE_BUILD

If I recover the old make.conf, CCACHE works again for a buildworld.

# cat /etc/make.conf.old
.if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*))
.if !defined(NOCCACHE) && exists(/usr/local/libexec/ccache/world/cc)
CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/cc,1}
CXX:=${CXX:C,^c\+\+,/usr/local/libexec/ccache/world/c++,1}
.endif
.endif

Maybe I misconfigured CCACHE when I first installed it?

Best regards,
Juan
___
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"

Intel Haswell support - Any updates?

[Juan Ramón Molina Menor]

Hello!

I'm just curious about how Intel Haswell GPU support in FreeBSD is
coming along?
What's the ETA of when the driver can be tested?

Anders


Jean Sébastien-Pédron is actively working on it:
https://github.com/freebsd/freebsd-base-graphics/commits/drm-i915-update-38
___
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: Laptops that will not boot

[Juan Ramón Molina Menor]

Does anyone else have a machine that won't boot from GPT without the
active flag set?

bsdinstall now has a blacklist for these models, and can apply the fix
as part of the installation (ufs or zfs).

If you are also suffering from this, please post your machine's details
to get it added to the blacklist:

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


--
Allan Jude


Hi Allan. It seems that this problem affects some recent ThinkPads, but 
I’m not seeing it with a S440: the latest CURRENT memstick boots fine 
both in 'UEFI Only' and 'Legacy' modes.


So, don’t blacklist it, please! ;-)

Best regards,
Juan
___
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