SG116j install crashed

2018-01-17 Thread KIRIYAMA Kazuhiko 
Hi, all

I've bought Biccamera's original bland note PC (SG116j)
impulsively because of cheapness($1780). I've installed
12.0-CURRENT(r327788) right away. Booted smoothly but set
loader conf "unset hint.uart.1.at" and configure disk with

mmcsd0  58 GB   GPT
  mmcsd0p1  200MB   efi
  mmcsd0p2  54 GB   freebsd-ufs /
  mmcsd0p3  4.2 GB  freebsd-swapnone

But in "Tetching distribution files" of base.txz, crashed
with:

sdhci_acpi0-slot0: Controller timeout
sdhci_acpi0-slot0: == REGISTER DUMP ==
sdhci_acpi0-slot0: Sys addr: 0x02158000 | Version:  0x1002
sdhci_acpi0-slot0: Blk size: 0x0200 | Blk cnt:  0x00f8
sdhci_acpi0-slot0: Argument: 0x017f57e8 | Trn mode: 0x0027
sdhci_acpi0-slot0: Present:  0x1fff0106 | Host ctl: 0x1025
sdhci_acpi0-slot0: Power:0x000b | Blk gap:  0x0080
sdhci_acpi0-slot0: Wake-up:  0x | Clock:0x0007
sdhci_acpi0-slot0: Timeout:  0x0007 | Int stat: 0x0001
sdhci_acpi0-slot0: Int enab: 0x05ff0033 | Sig enab: 0x05ff003a
sdhci_acpi0-slot0: AC12 err: 0x8000 | Host ctl2:0x008b
sdhci_acpi0-slot0: Caps: 0x446cc8b2 | Caps2:0x0807
sdhci_acpi0-slot0: Max curr: 0x | ADMA err: 0x
sdhci_acpi0-slot0: ADMA addr:0x | Slot int: 0x
sdhci_acpi0-slot0: ===
mmcsd0: Error indicated: 1 Timeout
  :
(snip)
  :
Stopped at kdb_enter+0x3b: movq$0,kdb_why
db>

Detail log has put in [1]. BTW I used [2] so all stuffs are
within it and it should not be fetched to internet.

Is there any idea to go forth?

Best regards.

[1] http://35.200.82.201/~kiri/freebsd/sg116j/crash_in_install.jpeg
[2] FreeBSD-12.0-CURRENT-amd64-20180110-r327788-memstick.img

---
KIRIYAMA Kazuhiko
___
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 NUMA support coming to CURRENT

2018-01-17 Thread Ultima 
Hello Jeff,

Few days ago I upgraded my system firmware, upgraded
base to r327991 and altered snooping to
cluster-on-die. Its hard to say what is making
the server feels like a completely system due
to all these changes (also running llvm 6.0),
but I am betting it is the NUMA optimizations.
It is so responsive! Thanks for the amazing
work!

Best regards,
Richard Gallamore

On Sat, Jan 13, 2018 at 7:39 PM, Jeff Roberson 
wrote:

> Hello,
>
> This work has been committed.  It is governed by a new 'NUMA' config
> option and 'DEVICE_NUMA' and 'VM_NUMA_ALLOC' have both been retired.  This
> option is fairly light weight and I will likely enable it in GENERIC before
> 12.0 release.
>
> I have heard reports that switching from a default policy of first-touch
> to round-robin has caused some performance regression.  You can change the
> default policy at runtime by doing the following:
>
> cpuset -s 1 -n first-touch:all
>
> This is the default set that all others inherit from.  You can query the
> current default with:
> cpuset -g -s 1
>
> I will be investigating the regression and tweaking the default policy
> based on performance feedback from multiple workloads.  This may take some
> time.
>
> numactl is still functional but deprecated.  Man pages will be updated
> soonish.
>
> Thank you for your patience as I work on refining this somewhat involved
> feature.
>
> Thanks,
> Jeff
>
>
> On Tue, 9 Jan 2018, Jeff Roberson wrote:
>
> Hello folks,
>>
>> I am working on merging improved NUMA support with policy implemented by
>> cpuset(2) over the next week.  This work has been supported by Dell/EMC's
>> Isilon product division and Netflix.  You can see some discussion of these
>> changes here:
>>
>> https://reviews.freebsd.org/D13403
>> https://reviews.freebsd.org/D13289
>> https://reviews.freebsd.org/D13545
>>
>> The work has been done in user/jeff/numa if you want to look at svn
>> history or experiment with the branch.  It has been tested by Peter Holm on
>> i386 and amd64 and it has been verified to work on arm at various points.
>>
>> We are working towards compatibility with libnuma and linux mbind.  These
>> commits will bring in improved support for NUMA in the kernel.  There are
>> new domain specific allocation functions available to kernel for UMA,
>> malloc, kmem_, and vm_page*.  busdmamem consumers will automatically be
>> placed in the correct domain, bringing automatic improvements to some
>> device performance.
>>
>> cpuset will be able to constrains processes, groups of processes, jails,
>> etc. to subsets of the system memory domains, just as it can with sets of
>> cpus. It can set default policy for any of the above.  Threads can use
>> cpusets to set policy that specifies a subset of their visible domains.
>>
>> Available policies are first-touch (local in linux terms), round-robin
>> (similar to linux interleave), and preferred.  For now, the default is
>> round-robin.  You can achieve a fixed domain policy by using round-robin
>> with a bitmask of a single domain.  As the scheduler and VM become more
>> sophisticated we may switch the default to first-touch as linux does.
>>
>> Currently these features are enabled with VM_NUMA_ALLOC and MAXMEMDOM.
>> It will eventually be NUMA/MAXMEMDOM to match SMP/MAXCPU.  The current NUMA
>> syscalls and VM_NUMA_ALLOC code was 'experimental' and will be deprecated.
>> numactl will continue to be supported although cpuset should be preferred
>> going forward as it supports the full feature set of the new API.
>>
>> Thank you for your patience as I deal with the inevitable fallout of such
>> sweeping changes.  If you do have bugs, please file them in bugzilla, or
>> reach out to me directly.  I don't always have time to catch up on all of
>> my mailing list mail and regretfully things slip through the cracks when
>> they are not addressed directly to me.
>>
>> Thanks,
>> Jeff
>>
>> ___
> 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: [CFT] sysutils/devcpu-data Intel microcode migration

2018-01-17 Thread Sean Bruno 


On 01/15/18 11:14, Sean Bruno wrote:
> https://reviews.freebsd.org/D13921
> 
> In order to better absorb updates as they appear, I'm proposing that we
> switch from the current model of processing the "microcode.dat" legacy
> file to consuming the pre-digested update files.
> 
> This update should not change the microcode version that you previously
> received, but I'd like for folks to give it a spin before we commit yet
> another update to this port.
> 
> sean
> 


*sigh*

https://reviews.freebsd.org/D13958

Looks like there are some "discrepancies" in the legacy vs current
method of distribution of microcode.

sean



signature.asc
Description: OpenPGP digital signature

Buildworld broken! r328075 broke the world

2018-01-17 Thread O. Hartmann 
Please can someon look after the recent CURRENT, it seems that on all systems I
try to buildworld most recent sources bail out at:

[... WITH_LLD_IS_LD]:
Building /usr/obj/usr/src/amd64.amd64/rescue/rescue/rescue
/usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: cgget
>>> referenced by fsdb.lo:(_$$hide$$ fsdb.lo findblk)
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** Error code 1

at a stage were world has been compiled from scratch (make cleanworld)


or at another point, like

[...]
===> sbin/fsdb (all)  
--- all_subdir_rescue ---
`pkill.o' is up to date.
--- ps_make ---
(cd /usr/src/rescue/rescue/../../bin/ps &&  make -DRESCUE
CRUNCH_CFLAGS=-DRESCUE MK_AUTO_OBJ=yes DIRPRFX=rescue/rescue/ps/ fmt.o
keyword.o nlist.o print.o ps.o) --- all_subdir_sbin ---
Building /usr/obj/usr/src/amd64.amd64/sbin/fsdb/fsdb --- fsdb ---
/usr/obj/usr/src/amd64.amd64/tmp/usr/bin/ld: error: undefined symbol: cgget
>>> referenced by fsdb.c
>>>   fsdb.o:(findblk)  
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** [fsdb] Error code 1


I think this is related to commit r328075.

Thanks in advance,

Oliver
___
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: CLANG6, java/openjdk[7|8] compiler error: atomic.inline.hpp:70 error: unknown token in expression __asm__ volatile

2018-01-17 Thread Boris Samorodov 
Hi Oliver, All!

17.01.2018 14:01, O. Hartmann пишет:
> On recent CURRENT (FreeBSD 12.0-CURRENT #0 r328002: Mon Jan 15 15:28:18 CET
> 2018 amd64) both ports java/openjdk7 and java/openjdk8 fail to compile with
> devel/openjdk8's error as follows:
> 
> [...]
> In file included
> from 
> /usr/ports/java/openjdk8/work/openjdk/hotspot/src/share/vm/runtime/atomic.inline.hpp:70:
>  
> /usr/ports/java/openjdk8/work/openjdk/hotspot/src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp:95:21:
> error: unknown token in expression __asm__ volatile (LOCK_IF_MP(%4) "cmpxchgl
> %1,(%3)"

There is an open PR on the matter:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225054

-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve
___
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: CLANG6, java/openjdk[7|8] compiler error: atomic.inline.hpp:70 error: unknown token in expression __asm__ volatile

2018-01-17 Thread Dimitry Andric 
On 17 Jan 2018, at 12:01, O. Hartmann  wrote:
> 
> On recent CURRENT (FreeBSD 12.0-CURRENT #0 r328002: Mon Jan 15 15:28:18 CET
> 2018 amd64) both ports java/openjdk7 and java/openjdk8 fail to compile with
> devel/openjdk8's error as follows:
> 
> 
> [...]
> In file included
> from 
> /usr/ports/java/openjdk8/work/openjdk/hotspot/src/share/vm/runtime/atomic.inline.hpp:70:
>  
> /usr/ports/java/openjdk8/work/openjdk/hotspot/src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp:95:21:
> error: unknown token in expression __asm__ volatile (LOCK_IF_MP(%4) "cmpxchgl
> %1,(%3)"

I had the idea this was worked around already, but I am planning on
committing an upstream fix for this very soon.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

r328075 appears to break sbin/fsdb

2018-01-17 Thread David Wolfskill 
As O. Hartmann noted (in svn-src-head@), the change to rename cgget to
cglookup also affects fsdb:

--- all_subdir_sbin/fsdb ---
--- fsdb.o ---
/usr/src/sbin/fsdb/fsdb.c:479:9: error: implicit declaration of function 
'cgget' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
cgbp = cgget(c);
   ^
/usr/src/sbin/fsdb/fsdb.c:479:7: error: incompatible integer to pointer 
conversion assigning to 'struct bufarea *' from 'int' [-Werror,-Wint-conversion]
cgbp = cgget(c);
 ^ 
2 errors generated.
--- all_subdir_usr.bin ---


I suspect that replacing "cgget" with "cglookup" in
src/sbin/fsdb/fsdb.c:479 will fix it.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"unfortunately, no trust!” -- well, of course!  You reap what you sow.

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


signature.asc
Description: PGP signature

CLANG6, java/openjdk[7|8] compiler error: atomic.inline.hpp:70 error: unknown token in expression __asm__ volatile

2018-01-17 Thread O. Hartmann 
On recent CURRENT (FreeBSD 12.0-CURRENT #0 r328002: Mon Jan 15 15:28:18 CET
2018 amd64) both ports java/openjdk7 and java/openjdk8 fail to compile with
devel/openjdk8's error as follows:


[...]
In file included
from 
/usr/ports/java/openjdk8/work/openjdk/hotspot/src/share/vm/runtime/atomic.inline.hpp:70:
 
/usr/ports/java/openjdk8/work/openjdk/hotspot/src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp:95:21:
error: unknown token in expression __asm__ volatile (LOCK_IF_MP(%4) "cmpxchgl
%1,(%3)"


Regards,

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

CLANG6, java/openjdk[7|8] compiler error: atomic.inline.hpp:70 error: unknown token in expression __asm__ volatile

2018-01-17 Thread O. Hartmann 
On recent CURRENT (FreeBSD 12.0-CURRENT #0 r328002: Mon Jan 15 15:28:18 CET
2018 amd64) both ports java/openjdk7 and java/openjdk8 fail to compile with
devel/openjdk8's error as follows:


[...]
In file included
from 
/usr/ports/java/openjdk8/work/openjdk/hotspot/src/share/vm/runtime/atomic.inline.hpp:70:
 
/usr/ports/java/openjdk8/work/openjdk/hotspot/src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp:95:21:
error: unknown token in expression __asm__ volatile (LOCK_IF_MP(%4) "cmpxchgl
%1,(%3)"


Regards,

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