Re: CFLAGS for certain ports

[Mingo Rrubioer]

Hi :)

On Sat, Mar 4, 2017 at 4:16 AM, Shane Ambler  wrote:
> On 04/03/2017 02:17, Julian Elischer wrote:
>>
>> On 2/3/17 8:58 pm, Dimitry Andric wrote:
>>>
>>> On 2 Mar 2017, at 12:02, Mingo Rrubioer  wrote:

 I would like to see how well FreeBSD does as a workstation OS in the
 HPC world due to its stability and reliability, as well as LLVM/clang.
 I would like to know if FreeBSD has something similar to Gentoo's
 /etc/portage/make.conf file and /etc/portage/package.use/* files in
 order to compile certain ports with certain compiler flags.
>>>
>>> It doesn't, though it would certainly be nice to have something like it
>>> at some point.  The current idiom is to put something similar to the
>>> following in your /etc/make.conf:
>>>
>>> .if ${.CURDIR:M/usr/ports/foo/bar}
>>> CFLAGS+= [... flags for the foo/bar port ...]
>>> .endif
>>>
>>> .if ${.CURDIR:M/usr/ports/what/ever}
>>> CFLAGS+= [... flags for the what/ever port ...]
>>> .endif
>>>
>
> We can also put a Makefile.local in the port directory. There can also
> be arch and system specific makefiles.
>
> See /usr/ports/Mk/bsd.port.mk from about line 1211
>
> https://svnweb.freebsd.org/ports/head/Mk/bsd.port.mk?view=markup#l1211


Thanks to everyone and sorry for the late reply.

Great help and pointers !!!

This is going to be a slow process (you know how users love change ;)
I have to get things well sorted aout, benchmarks, ... before I can
convince anyone ... But, it's worth it ;)

Back to reading man pages ;)
___
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: kernel trap 12 with interrupts disabled

[Andriy Gapon]

On 05/03/2017 08:08, Chris H wrote:
> Thanks for the reply.
> I rebooted to kernel.old, so I could get the exact
> src revision I built this on. It's r314640
> 
> Any news as to whether it's safe to update src, and
> build a usable kernel?

Sorry about the breakage.
The fix is in r314700.

> 
> On Sun, 05 Mar 2017 12:01:29 +0800 Alastair Hogge  wrote
> 
>> Hi *,
>>
>> On Sat, 4 Mar 2017 07:38:55 PM Chris H wrote:
>>
>> [remove 12-CURRENT history & hardware summary]
>>
>>> I finished the
>>> buildworld, and finished the build/install kernel, and
>>> (attempted) to boot to single user. But got a trap
>>> shortly into booting the new kernel;
>>>
>>> kernel trap 12 with interrupts disabled
>>>
>>> Fatal trap 12: page fault in kernel mode
>>
>> I am also experiencing a similar problem.  I believe the error is caused by 
>> r314636[0]; committer CC'd.
>>
>> Verbose boot (r314640):
>>
>> /boot/kernel/kernel text=0x8e13d0 data=0xac880+0x3cd6e8 
>> syms=[0x8+0xd6350+0x8+0xd2864]   
>>  
>>[77/1834]
>> /boot/entropy size=0x1000
>> Booting...
>> [dcons disconnected (wrong magic 0x)]
>> [dcons connected]
>> GDB: debug ports: dcons
>> GDB: current port: dcons
>> KDB: debugger backends: ddb gdb
>> KDB: current backend: ddb
>> Table 'FACP' at 0xbfdd1080
>> Table 'MSDM' at 0xbfdd8800
>> Table 'HPET' at 0xbfdd8880
>> Table 'MCFG' at 0xbfdd88c0
>> Table 'EUDS' at 0xbfdd8940
>> Table 'MATS' at 0xbfdd91a0
>> Table 'TAMG' at 0xbfdd9210
>> Table 'APIC' at 0xbfdd8740
>> APIC: Found table at 0xbfdd8740
>> APIC: Using the MADT enumerator.
>> MADT: Found CPU APIC ID 0 ACPI ID 0: enabled
>> SMP: Added CPU 0 (AP)
>> MADT: Found CPU APIC ID 1 ACPI ID 1: enabled
>> SMP: Added CPU 1 (AP)
>> MADT: Found CPU APIC ID 2 ACPI ID 2: enabled
>> SMP: Added CPU 2 (AP)
>> MADT: Found CPU APIC ID 3 ACPI ID 3: enabled
>> SMP: Added CPU 3 (AP)
>> MADT: Found CPU APIC ID 4 ACPI ID 4: enabled
>> SMP: Added CPU 4 (AP)
>> MADT: Found CPU APIC ID 5 ACPI ID 5: enabled
>> SMP: Added CPU 5 (AP)
>> MADT: Found CPU APIC ID 6 ACPI ID 6: enabled
>> SMP: Added CPU 6 (AP)
>> MADT: Found CPU APIC ID 7 ACPI ID 7: enabled
>> SMP: Added CPU 7 (AP)
>> Copyright (c) 1992-2017 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 is a registered trademark of The FreeBSD Foundation.
>> FreeBSD 12.0-CURRENT #0 r314640: Sat Mar  4 13:10:08 AWST 2017
>> root@direwolf:/tmp/direwolf/usr/src/sys/DIREWOLF amd64
>> FreeBSD clang version 4.0.0 (branches/release_40 296509) (based on LLVM
>> 4.0.0) WARNING: WITNESS option enabled, expect reduced performance.
>> Table 'FACP' at 0xbfdd1080
>> Table 'MSDM' at 0xbfdd8800
>> Table 'HPET' at 0xbfdd8880
>> Table 'MCFG' at 0xbfdd88c0
>> Table 'EUDS' at 0xbfdd8940
>> Table 'MATS' at 0xbfdd91a0
>> Table 'TAMG' at 0xbfdd9210
>> Table 'APIC' at 0xbfdd8740
>> Table 'MATS' at 0xbfdd93c0
>> Table 'SSDT' at 0xbfddfaf0
>> Table 'IVRS' at 0xbfde1280
>> ACPI: No SRAT table found
>> PPIM 0: PA=0xa, VA=0x8141, size=0x1, mode=0
>> VT(vga): resolution 640x480
>> Preloaded elf kernel "/boot/kernel/kernel" at 0x81306000.
>> Preloaded /boot/entropy "/boot/entropy" at 0x81306ae8.
>> Calibrating TSC clock ... TSC clock: 4018024582 Hz
>> CPU: AMD FX(tm)-8350 Eight-Core Processor(4018.02-MHz K8-class 
>> CPU)
>>   Origin="AuthenticAMD"  Id=0x600f20  Family=0x15  Model=0x2  Stepping=0
>>  
>> Features=0x178bfbff> CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>  
>> Features2=0x3e98320b> ESNI,XSAVE,OSXSAVE,AVX,F16C>   AMD
>> Features=0x2e500800   AMD 
>> Features2=0x1ebbfff> XOP,SKINIT,WDT,LWP,FMA4,TCE,NodeId,TBM,Topology,PCXC,PNXC>   Structured
>> Extended Features=0x8   SVM: 
>> Features=0x1cff> Assist,PauseFilter,,PauseFilterThreshold> Revision=1, ASIDs=65536
>>   TSC: P-state invariant, performance statistics
>> L1 2MB data TLB: 64 entries, fully associative
>> L1 2MB instruction TLB: 24 entries, fully associative
>> L1 4KB data TLB: 64 entries, fully associative
>> L1 4KB instruction TLB: 48 entries, fully associative
>> L1 data cache: 16 kbytes, 64 bytes/line, 1 lines/tag, 4-way associative
>> L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way
>> associative L2 2MB data TLB: 1024 entries, 8-way associative
>> L2 4KB data TLB: 1024 entries, 8-way associative
>> L2 4KB instruction TLB: 1024 entries, 8-way associative
>> L2 unified cache: 2048 kbytes, 64 bytes/line, 1 lines/tag, 

Re: kernel trap 12 with interrupts disabled

[Alastair Hogge]

On Sat, 4 Mar 2017 10:34:39 PM Chris H wrote:
> On Sun, 05 Mar 2017 14:26:31 +0800 Alastair Hogge  wrote
> 
> > On Sat, 4 Mar 2017 10:08:45 PM Chris H wrote:
> > > Thanks for the reply.
> > > I rebooted to kernel.old, so I could get the exact
> > > src revision I built this on. It's r314640
> > > 
> > > Any news as to whether it's safe to update src, and
> > > build a usable kernel?
> > 
> > I am not able to boot a kernel > r314627.  I currently have a r314627
> > kernel running with a r314687 world.
> 
> Looking at the output in my trap; I got the impression that
> the commit: r314636, might be to blame --

[removed commit log]

Thanks for the correct.

> I'm thinking to back that commit out, and giving world/kernel
> another shot.

I changed ${src}/sys/x86/x86/mca.c to return immediately:

--- sys/x86/x86/mca.c   (revision 314698)
+++ sys/x86/x86/mca.c   (working copy)
@@ -1016,6 +1016,7 @@
 static void
 _mca_init(int boot)
 {
+return;
uint64_t mcg_cap;
uint64_t ctl, mask;
int i, skip;

I have a working & sync'd kernel + world.
___
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: kernel trap 12 with interrupts disabled

[Chris H]

On Sun, 05 Mar 2017 14:26:31 +0800 Alastair Hogge  wrote

> On Sat, 4 Mar 2017 10:08:45 PM Chris H wrote:
> > Thanks for the reply.
> > I rebooted to kernel.old, so I could get the exact
> > src revision I built this on. It's r314640
> > 
> > Any news as to whether it's safe to update src, and
> > build a usable kernel?
> 
> I am not able to boot a kernel > r314627.  I currently have a r314627 kernel 
> running with a r314687 world.

Looking at the output in my trap; I got the impression that
the commit: r314636, might be to blame --

MCA: add AMD Error Thresholding support

Currently the feature is implemented only for a subset of errors
reported via Bank 4.  The subset includes only DRAM-related errors.

The new code builds upon and reuses the Intel CMC (Correctable MCE
Counters) support code.  However, the AMD feature is quite different
and, unfortunately, much less regular.

Just a guess, tho.

I'm thinking to back that commit out, and giving world/kernel
another shot.

--Chris

> 
> ___
> 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: kernel trap 12 with interrupts disabled

[Alastair Hogge]

On Sat, 4 Mar 2017 10:08:45 PM Chris H wrote:
> Thanks for the reply.
> I rebooted to kernel.old, so I could get the exact
> src revision I built this on. It's r314640
> 
> Any news as to whether it's safe to update src, and
> build a usable kernel?

I am not able to boot a kernel > r314627.  I currently have a r314627 kernel 
running with a r314687 world.

___
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: kernel trap 12 with interrupts disabled

[Chris H]

Thanks for the reply.
I rebooted to kernel.old, so I could get the exact
src revision I built this on. It's r314640

Any news as to whether it's safe to update src, and
build a usable kernel?

Thanks.

--Chris

On Sun, 05 Mar 2017 12:01:29 +0800 Alastair Hogge  wrote

> Hi *,
> 
> On Sat, 4 Mar 2017 07:38:55 PM Chris H wrote:
> 
> [remove 12-CURRENT history & hardware summary]
> 
> > I finished the
> > buildworld, and finished the build/install kernel, and
> > (attempted) to boot to single user. But got a trap
> > shortly into booting the new kernel;
> > 
> > kernel trap 12 with interrupts disabled
> > 
> > Fatal trap 12: page fault in kernel mode
> 
> I am also experiencing a similar problem.  I believe the error is caused by 
> r314636[0]; committer CC'd.
> 
> Verbose boot (r314640):
> 
> /boot/kernel/kernel text=0x8e13d0 data=0xac880+0x3cd6e8 
> syms=[0x8+0xd6350+0x8+0xd2864]   
>  
>[77/1834]
> /boot/entropy size=0x1000
> Booting...
> [dcons disconnected (wrong magic 0x)]
> [dcons connected]
> GDB: debug ports: dcons
> GDB: current port: dcons
> KDB: debugger backends: ddb gdb
> KDB: current backend: ddb
> Table 'FACP' at 0xbfdd1080
> Table 'MSDM' at 0xbfdd8800
> Table 'HPET' at 0xbfdd8880
> Table 'MCFG' at 0xbfdd88c0
> Table 'EUDS' at 0xbfdd8940
> Table 'MATS' at 0xbfdd91a0
> Table 'TAMG' at 0xbfdd9210
> Table 'APIC' at 0xbfdd8740
> APIC: Found table at 0xbfdd8740
> APIC: Using the MADT enumerator.
> MADT: Found CPU APIC ID 0 ACPI ID 0: enabled
> SMP: Added CPU 0 (AP)
> MADT: Found CPU APIC ID 1 ACPI ID 1: enabled
> SMP: Added CPU 1 (AP)
> MADT: Found CPU APIC ID 2 ACPI ID 2: enabled
> SMP: Added CPU 2 (AP)
> MADT: Found CPU APIC ID 3 ACPI ID 3: enabled
> SMP: Added CPU 3 (AP)
> MADT: Found CPU APIC ID 4 ACPI ID 4: enabled
> SMP: Added CPU 4 (AP)
> MADT: Found CPU APIC ID 5 ACPI ID 5: enabled
> SMP: Added CPU 5 (AP)
> MADT: Found CPU APIC ID 6 ACPI ID 6: enabled
> SMP: Added CPU 6 (AP)
> MADT: Found CPU APIC ID 7 ACPI ID 7: enabled
> SMP: Added CPU 7 (AP)
> Copyright (c) 1992-2017 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 is a registered trademark of The FreeBSD Foundation.
> FreeBSD 12.0-CURRENT #0 r314640: Sat Mar  4 13:10:08 AWST 2017
> root@direwolf:/tmp/direwolf/usr/src/sys/DIREWOLF amd64
> FreeBSD clang version 4.0.0 (branches/release_40 296509) (based on LLVM
> 4.0.0) WARNING: WITNESS option enabled, expect reduced performance.
> Table 'FACP' at 0xbfdd1080
> Table 'MSDM' at 0xbfdd8800
> Table 'HPET' at 0xbfdd8880
> Table 'MCFG' at 0xbfdd88c0
> Table 'EUDS' at 0xbfdd8940
> Table 'MATS' at 0xbfdd91a0
> Table 'TAMG' at 0xbfdd9210
> Table 'APIC' at 0xbfdd8740
> Table 'MATS' at 0xbfdd93c0
> Table 'SSDT' at 0xbfddfaf0
> Table 'IVRS' at 0xbfde1280
> ACPI: No SRAT table found
> PPIM 0: PA=0xa, VA=0x8141, size=0x1, mode=0
> VT(vga): resolution 640x480
> Preloaded elf kernel "/boot/kernel/kernel" at 0x81306000.
> Preloaded /boot/entropy "/boot/entropy" at 0x81306ae8.
> Calibrating TSC clock ... TSC clock: 4018024582 Hz
> CPU: AMD FX(tm)-8350 Eight-Core Processor(4018.02-MHz K8-class 
> CPU)
>   Origin="AuthenticAMD"  Id=0x600f20  Family=0x15  Model=0x2  Stepping=0
>  
> Features=0x178bfbff CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>  
> Features2=0x3e98320b ESNI,XSAVE,OSXSAVE,AVX,F16C>   AMD
> Features=0x2e500800   AMD 
> Features2=0x1ebbfff XOP,SKINIT,WDT,LWP,FMA4,TCE,NodeId,TBM,Topology,PCXC,PNXC>   Structured
> Extended Features=0x8   SVM: 
> Features=0x1cff Assist,PauseFilter,,PauseFilterThreshold> Revision=1, ASIDs=65536
>   TSC: P-state invariant, performance statistics
> L1 2MB data TLB: 64 entries, fully associative
> L1 2MB instruction TLB: 24 entries, fully associative
> L1 4KB data TLB: 64 entries, fully associative
> L1 4KB instruction TLB: 48 entries, fully associative
> L1 data cache: 16 kbytes, 64 bytes/line, 1 lines/tag, 4-way associative
> L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way
> associative L2 2MB data TLB: 1024 entries, 8-way associative
> L2 4KB data TLB: 1024 entries, 8-way associative
> L2 4KB instruction TLB: 1024 entries, 8-way associative
> L2 unified cache: 2048 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative
> real memory  = 34359738368 (32768 MB)
> Physical memory chunk(s):
> 0x0001 - 0x0005, 327680 bytes (80 pages)
> 0x0007 - 

Re: Fwd: Re: I/O semantics of pipe and FIFO.

[Alfred Perlstein]

Devin and I found this when we worked together.  I think it was due to 
some situation in dd(1) where short reads would exit pre-maturely, 
however I may be mis-remembering.  Devin, do you recall the specifics?



On 3/4/17 7:44 PM, Julian Elischer wrote:


an interesting point to discuss? is our behaviour in this test right?
   from: "austin-group mailng list (posix standard discussion)"

-- rest of email is quoted ---
On 5/3/17 5:48 am, Stephane Chazelas wrote:

2017-03-04 13:14:08 +, Danny Niu:

Hi all.

I couldn't remember where I saw it saying, that when reading
from a pipe or a FIFO, the read syscall returns the content of
at most one write call. It's a bit similar to the
message-nondiscard semantics of dear old STREAM.

Currently, I'm reading through the text to find out a bit
more, and I appreciate a bit of pointer on this.

[...]

(echo x; echo y) | (sleep 1; dd count=1 2> /dev/null)

outputs both x and y in all of Linux, FreeBSD and Solaris in my
tests.

That a read wouldn't read what's currently in the pipe would be
quite surprising.

I also wouldn't expect pipes to store the writes as individual
separate message but use one buffer.

In:

(
  dd bs=4 count=1 if=/dev/zero 2> /dev/null
  echo first through >&2
  dd bs=4 count=1 if=/dev/zero 2> /dev/null
  echo second through >&2
) | (sleep 1; dd bs=10 count=1 2> /dev/null) | wc -c

That is where the second write blocks because the pipe is full,
the reading dd still reads both writes in Linux and Solaris in
my tests (on Solaris (10 on amd64 at least), reduce to 2
instead of 4 or both writes would block).

On FreeBSD, I get only the first write (using 8000 followed by
1 for instance).

FreeBSD is also the only one of the three where

dd bs=100 count=1 if=/dev/zero | dd bs=100 count=1 | wc -c

Doesn't output 100. The others schedule both processes back
and forth during their write() and read() system call while the
pipe is being filled and emptied several times.



___
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: kernel trap 12 with interrupts disabled

[Alastair Hogge]

Hi *,

On Sat, 4 Mar 2017 07:38:55 PM Chris H wrote:

[remove 12-CURRENT history & hardware summary]

> I finished the
> buildworld, and finished the build/install kernel, and
> (attempted) to boot to single user. But got a trap
> shortly into booting the new kernel;
> 
> kernel trap 12 with interrupts disabled
> 
> Fatal trap 12: page fault in kernel mode

I am also experiencing a similar problem.  I believe the error is caused by 
r314636[0]; committer CC'd.

Verbose boot (r314640):

/boot/kernel/kernel text=0x8e13d0 data=0xac880+0x3cd6e8 
syms=[0x8+0xd6350+0x8+0xd2864]  

  
[77/1834]
/boot/entropy size=0x1000
Booting...
[dcons disconnected (wrong magic 0x)]
[dcons connected]
GDB: debug ports: dcons
GDB: current port: dcons
KDB: debugger backends: ddb gdb
KDB: current backend: ddb
Table 'FACP' at 0xbfdd1080
Table 'MSDM' at 0xbfdd8800
Table 'HPET' at 0xbfdd8880
Table 'MCFG' at 0xbfdd88c0
Table 'EUDS' at 0xbfdd8940
Table 'MATS' at 0xbfdd91a0
Table 'TAMG' at 0xbfdd9210
Table 'APIC' at 0xbfdd8740
APIC: Found table at 0xbfdd8740
APIC: Using the MADT enumerator.
MADT: Found CPU APIC ID 0 ACPI ID 0: enabled
SMP: Added CPU 0 (AP)
MADT: Found CPU APIC ID 1 ACPI ID 1: enabled
SMP: Added CPU 1 (AP)
MADT: Found CPU APIC ID 2 ACPI ID 2: enabled
SMP: Added CPU 2 (AP)
MADT: Found CPU APIC ID 3 ACPI ID 3: enabled
SMP: Added CPU 3 (AP)
MADT: Found CPU APIC ID 4 ACPI ID 4: enabled
SMP: Added CPU 4 (AP)
MADT: Found CPU APIC ID 5 ACPI ID 5: enabled
SMP: Added CPU 5 (AP)
MADT: Found CPU APIC ID 6 ACPI ID 6: enabled
SMP: Added CPU 6 (AP)
MADT: Found CPU APIC ID 7 ACPI ID 7: enabled
SMP: Added CPU 7 (AP)
Copyright (c) 1992-2017 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 is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.0-CURRENT #0 r314640: Sat Mar  4 13:10:08 AWST 2017
root@direwolf:/tmp/direwolf/usr/src/sys/DIREWOLF amd64
FreeBSD clang version 4.0.0 (branches/release_40 296509) (based on LLVM 4.0.0)
WARNING: WITNESS option enabled, expect reduced performance.
Table 'FACP' at 0xbfdd1080
Table 'MSDM' at 0xbfdd8800
Table 'HPET' at 0xbfdd8880
Table 'MCFG' at 0xbfdd88c0
Table 'EUDS' at 0xbfdd8940
Table 'MATS' at 0xbfdd91a0
Table 'TAMG' at 0xbfdd9210
Table 'APIC' at 0xbfdd8740
Table 'MATS' at 0xbfdd93c0
Table 'SSDT' at 0xbfddfaf0
Table 'IVRS' at 0xbfde1280
ACPI: No SRAT table found
PPIM 0: PA=0xa, VA=0x8141, size=0x1, mode=0
VT(vga): resolution 640x480
Preloaded elf kernel "/boot/kernel/kernel" at 0x81306000.
Preloaded /boot/entropy "/boot/entropy" at 0x81306ae8.
Calibrating TSC clock ... TSC clock: 4018024582 Hz
CPU: AMD FX(tm)-8350 Eight-Core Processor(4018.02-MHz K8-class 
CPU)
  Origin="AuthenticAMD"  Id=0x600f20  Family=0x15  Model=0x2  Stepping=0
  
Features=0x178bfbff
  
Features2=0x3e98320b
  AMD Features=0x2e500800
  AMD 
Features2=0x1ebbfff
  Structured Extended Features=0x8
  SVM: 
Features=0x1cff
Revision=1, ASIDs=65536
  TSC: P-state invariant, performance statistics
L1 2MB data TLB: 64 entries, fully associative
L1 2MB instruction TLB: 24 entries, fully associative
L1 4KB data TLB: 64 entries, fully associative
L1 4KB instruction TLB: 48 entries, fully associative
L1 data cache: 16 kbytes, 64 bytes/line, 1 lines/tag, 4-way associative
L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative
L2 2MB data TLB: 1024 entries, 8-way associative
L2 4KB data TLB: 1024 entries, 8-way associative
L2 4KB instruction TLB: 1024 entries, 8-way associative
L2 unified cache: 2048 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative
real memory  = 34359738368 (32768 MB)
Physical memory chunk(s):
0x0001 - 0x0005, 327680 bytes (80 pages)
0x0007 - 0x00098fff, 167936 bytes (41 pages)
0x0010 - 0x001f, 1048576 bytes (256 pages)
0x0134 - 0xbfd9, 3198550016 bytes (780896 pages)
0x0001 - 0x00080a849fff, 30241234944 bytes (7383114 pages)
avail memory = 33272029184 (31730 MB)
Event timer "LAPIC" quality 100
LAPIC: ipi_wait() us multiplier 29 (r 13818693 tsc 4018024582)
ACPI APIC Table: 
Package ID shift: 4
L3 cache ID shift: 3
L2 cache ID shift: 1
L1 cache ID shift: 0
Core ID shift: 0
INTR: 

Fwd: Re: I/O semantics of pipe and FIFO.

[Julian Elischer]

an interesting point to discuss? is our behaviour in this test right?
   from: "austin-group mailng list (posix standard discussion)"

-- rest of email is quoted ---
On 5/3/17 5:48 am, Stephane Chazelas wrote:

2017-03-04 13:14:08 +, Danny Niu:

Hi all.

I couldn't remember where I saw it saying, that when reading
from a pipe or a FIFO, the read syscall returns the content of
at most one write call. It's a bit similar to the
message-nondiscard semantics of dear old STREAM.

Currently, I'm reading through the text to find out a bit
more, and I appreciate a bit of pointer on this.

[...]

(echo x; echo y) | (sleep 1; dd count=1 2> /dev/null)

outputs both x and y in all of Linux, FreeBSD and Solaris in my
tests.

That a read wouldn't read what's currently in the pipe would be
quite surprising.

I also wouldn't expect pipes to store the writes as individual
separate message but use one buffer.

In:

(
  dd bs=4 count=1 if=/dev/zero 2> /dev/null
  echo first through >&2
  dd bs=4 count=1 if=/dev/zero 2> /dev/null
  echo second through >&2
) | (sleep 1; dd bs=10 count=1 2> /dev/null) | wc -c

That is where the second write blocks because the pipe is full,
the reading dd still reads both writes in Linux and Solaris in
my tests (on Solaris (10 on amd64 at least), reduce to 2
instead of 4 or both writes would block).

On FreeBSD, I get only the first write (using 8000 followed by
1 for instance).

FreeBSD is also the only one of the three where

dd bs=100 count=1 if=/dev/zero | dd bs=100 count=1 | wc -c

Doesn't output 100. The others schedule both processes back
and forth during their write() and read() system call while the
pipe is being filled and emptied several times.

--
Stephane

___
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: Building Current

[Ngie Cooper]

> On Mar 4, 2017, at 13:19, Roberto Rodriguez Jr  wrote:
> 
> Would make -DNO_CLEAN=NO also/maybe help as well?

Remove =NO from your invocation above. That would define a variable as: 
${NO_CLEAN=NO}=1
HTH,
-Ngie
___
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"

kernel trap 12 with interrupts disabled

[Chris H]

OK. This is my second world/kernel on 12.
The last, ~3 mos. ago, worked great. But, unfortunately,
the graphics on the APU (AMD/ATI A6 7470K)  aren't
(yet) supported on FreeBSD. So I picked up an nVidia
Geforce GT 730, and performed a fresh install from the
r314495 AMD Disk1 CD. Then checked out a fresh copy
of src && ports, last night (PST) to begin a fresh
buildworld/kernel installworld/kernel. I finished the
buildworld, and finished the build/install kernel, and
(attempted) to boot to single user. But got a trap
shortly into booting the new kernel;

kernel trap 12 with interrupts disabled

Fatal trap 12: page fault in kernel mode

I've placed a screen shot here:
bsdforge.com/12-CURRENT-2017-03-04.jpeg

for better context, and what follows what I've mentioned
above.
I've left it at this point with the db> prompt. In case
I/we can better determine what cause it.

Please advise.

Thanks!

--Chris


___
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: Building Current

[Roberto Rodriguez Jr]

Would make -DNO_CLEAN=NO also/maybe help as well?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Boot failure - svn up from this morning

[Shawn Webb]

On Fri, Mar 03, 2017 at 02:30:08PM +0100, Michael Tuexen wrote:
> > On 3 Mar 2017, at 12:59, Dexuan Cui  wrote:
> > 
> >> From: Dexuan Cui
> >> Sent: Friday, March 3, 2017 19:50
> >>> From: Alex Deiter
> >>> Sent: Friday, March 3, 2017 17:22
> >>> Hello,
> >>> The same issue with FreeBSD 12.0-CURRENT-r314563:
> >>> elf64_loadimage: could not read symbols - skipped!
> >>> 
> >>> I suspect regression after:
> >>> 
> >>> Revision 314547 - Directory Listing
> >>> Modified Thu Mar 2 07:25:50 2017 UTC (25 hours, 54 minutes ago) by dexuan
> >>> loader.efi: reduce the size of the staging area if necessary
> >> 
> >> Yes, I believe the issue is caused by the patch, which is supposed to PR 
> >> 211746:
> >> ...
> >> Can you please try the patch to dump the memory map?
> >> ...
> > 
> > BTW, I understand it's really annoying to boot the host first...
> > I'm really sorry for this.
> > 
> > I suppose you're able to build or find a good 'loader.efi' binary on 
> > another host,
> > and  then manage to replace the bad 'loader.efi' on the host broken by me. 
> > :-)
> This problem also occurred on a Dell R430...

And in bhyve with UEFI mode.

-- 
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

GPG Key ID:  0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89  3D9E 6A84 658F 5245 6EEE


signature.asc
Description: PGP signature

Re: Building Current

[Navdeep Parhar]

On Sat, Mar 04, 2017 at 03:46:20PM -0500, Roberto Rodriguez Jr wrote:
> What tools can I use to make the building a little faster?
> 

The src tree supports incremental builds. You'll need to load the
filemon module and add WITH_META_MODE=yes in /etc/src-env.conf to use
it.  See the WITH_META_MODE bits in src.conf(5), build(7) for some more
details.

It would be nice to have WITH_META_MODE as default but that's a separate
discussion.

Regards,
Navdeep
___
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: Building Current

[Manfred Antar]

> On Mar 4, 2017, at 12:46 PM, Roberto Rodriguez Jr  
> wrote:
> 
> What tools can I use to make the building a little faster?
> 
> I'm using an AMD 64 HP 15 laptop and I update the source tree daily and
> rebuild so if I have any errors I could report. Just curious if there's any
> extra software I could be implementing to make the compiling faster. 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"
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 

You could use /usr/ports/devel/ccache
It will speed things up after a build or two


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

___
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: Building Current

[Manfred Antar]

> On Mar 4, 2017, at 12:46 PM, Roberto Rodriguez Jr  
> wrote:
> 
> What tools can I use to make the building a little faster?
> 
> I'm using an AMD 64 HP 15 laptop and I update the source tree daily and
> rebuild so if I have any errors I could report. Just curious if there's any
> extra software I could be implementing to make the compiling faster. 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"
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 

You could use /usr/ports/devel/ccache
It will speed things up after a build or two


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

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

Building Current

[Roberto Rodriguez Jr]

What tools can I use to make the building a little faster?

I'm using an AMD 64 HP 15 laptop and I update the source tree daily and
rebuild so if I have any errors I could report. Just curious if there's any
extra software I could be implementing to make the compiling faster. 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"

Re: Build Fail: -CURRENT

[Ngie Cooper (yaneurabeya)]

> On Mar 4, 2017, at 11:50, Larry Rosenman  wrote:
> 
> --- all_subdir_usr.sbin/amd ---
> 
> /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x13e): undefined reference 
> to `xdr_symlinkargs'
> 
> /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x14c): undefined reference 
> to `xdr_diropres'
> 
> /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x151): undefined reference 
> to `xdr_createargs'
> 
> /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x15f): undefined reference 
> to `xdr_nfsstat'
> 
> /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x164): undefined reference 
> to `xdr_diropargs'
> 
> /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x172): undefined reference 
> to `xdr_readdirres'
> 
> /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x177): undefined reference 
> to `xdr_readdirargs'
> 
> /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x185): undefined reference 
> to `xdr_statfsres'
> 
> /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x18a): undefined reference 
> to `xdr_nfs_fh'
> 
> stubs.o: In function `nfsproc_readlink_2_svc':
> 
> /usr/src/contrib/amd/hlfsd/stubs.c:356: undefined reference to 
> `xdr_readlinkres'
> 
> --- all_subdir_rescue ---
> 
> Building /usr/obj/usr/src/rescue/rescue/usr/src/sbin/ipf/ipf/printlookup.o
> 
> --- all_subdir_usr.sbin ---
> 
> cc: error: linker command failed with exit code 1 (use -v to see invocation)
> 
> *** [hlfsd.full] Error code 1

Fixed in r314676. Apologies for the breakage :(…
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: r314670: buildworld compile failure: undefined reference to `xdr_attrstat'

[Ngie Cooper (yaneurabeya)]

> On Mar 4, 2017, at 12:12, Ngie Cooper (yaneurabeya)  
> wrote:
> 
> 
>> On Mar 4, 2017, at 09:33, Michael Butler  wrote:
>> 
>> Seems that SVN r314659 broke this :-(
>> 
>>  Michael
> 
> Working on it :(.
> -Ngie

Fixed in r314676. Apologies for the breakage :(…
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: r314670: buildworld compile failure: undefined reference to `xdr_attrstat'

[Bryan Drewery]

On 3/4/2017 8:11 AM, O. Hartmann wrote:
> At revision 314670, buildworld fails on all CURRENT machines with the error 
> shown below.
> 
> 
> Regards,
> 
> oh
> 
> 
> [...]
> ===> usr.sbin/amd/hlfsd (all)
> Building /usr/obj/usr/src/usr.sbin/amd/hlfsd/hlfsd

How has your experience with META_MODE been?

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: r314670: buildworld compile failure: undefined reference to `xdr_attrstat'

[Ngie Cooper (yaneurabeya)]

> On Mar 4, 2017, at 09:33, Michael Butler  wrote:
> 
> Seems that SVN r314659 broke this :-(
> 
>   Michael

Working on it :(.
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail

Build Fail: -CURRENT

[Larry Rosenman]

--- all_subdir_usr.sbin/amd ---

/usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x13e): undefined reference to 
`xdr_symlinkargs'

/usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x14c): undefined reference to 
`xdr_diropres'

/usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x151): undefined reference to 
`xdr_createargs'

/usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x15f): undefined reference to 
`xdr_nfsstat'

/usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x164): undefined reference to 
`xdr_diropargs'

/usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x172): undefined reference to 
`xdr_readdirres'

/usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x177): undefined reference to 
`xdr_readdirargs'

/usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x185): undefined reference to 
`xdr_statfsres'

/usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x18a): undefined reference to 
`xdr_nfs_fh'

stubs.o: In function `nfsproc_readlink_2_svc':

/usr/src/contrib/amd/hlfsd/stubs.c:356: undefined reference to `xdr_readlinkres'

--- all_subdir_rescue ---

Building /usr/obj/usr/src/rescue/rescue/usr/src/sbin/ipf/ipf/printlookup.o

--- all_subdir_usr.sbin ---

cc: error: linker command failed with exit code 1 (use -v to see invocation)

*** [hlfsd.full] Error code 1

 

--

Larry Rosenman http://www.lerctr.org/~ler

Phone: +1 214-642-9640 E-Mail: l...@lerctr.org

US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281

 

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Boot failure - svn up from this morning

[Alex Deiter]

Hello,

Screenshot: boot with patched loader: http://picpaste.com/IMG_1768-PnmZAtBZ.JPG
Video: boot with patched loader: https://youtu.be/thzyRk0D36w

Thank you!

Alex Deiter
alex.dei...@gmail.com



> On 3 Mar 2017, at 16:37, Dexuan Cui  wrote:
> 
>> From: Michael Tuexen
>> Sent: Friday, March 3, 2017 21:30
>>> BTW, I understand it's really annoying to boot the host first...
>>> I'm really sorry for this.
>>> 
>>> I suppose you're able to build or find a good 'loader.efi' binary on 
>>> another host,
>>> and  then manage to replace the bad 'loader.efi' on the host broken by me. 
>>> :-)
>> This problem also occurred on a Dell R430...
>> 
>> Best regards
>> Michael
> 
> Can you please use the patch to dump the

> :
> https://lists.freebsd.org/pipermail/freebsd-current/2017-March/064979.html
> 
> Let's get this fixed ASAP.
> 
> Thanks,
> -- Dexuan

___
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: confusing KTR_SCHED traces

[John Baldwin]

On Friday, February 17, 2017 08:48:57 PM Andriy Gapon wrote:
> 
> First, an example, three consecutive entries for the same thread (from top to
> bottom):
> KTRGRAPH group:"thread", id:"zio_write_intr_3 tid 100260", state:"sleep",
> attributes: prio:84, wmesg:"-", lockname:"(null)"
> KTRGRAPH group:"thread", id:"zio_write_intr_3 tid 100260", state:"spinning",
> attributes: lockname:"sched lock 1"
> KTRGRAPH group:"thread", id:"zio_write_intr_3 tid 100260", state:"running",
> attributes: none
> 
> Any automatic analysis tool including schedgraph.py will assume that the 
> thread
> ends up in the running state.  In reality, of course, the thread is in the
> sleeping state.
> The confusing trace is a result of logging the thread's intention to switch 
> out
> in mi_switch() before calling sched_switch().  In ULE's sched_switch() we
> acquire the "TDQ_LOCK" which could be contested.  In that case the thread 
> spins
> waiting for the lock to be released.  This is reported as "spinning" and then
> "running" states.
> 
> I would like to fix that, but not sure how to do that best.
> One idea is to move the mi_switch() trace closer to the cpu_switch() call
> similarly to DTrace sched:cpu-off and sched:cpu-on probes.

I think this is the right fix.

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: r314670: buildworld compile failure: undefined reference to `xdr_attrstat'

[Cy Schubert]

The reason it's supposed to link in rpcsvc.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX:     Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.


In message <24642190-36ea-45e7-f392-de2b6e224...@protected-networks.net>, 
Micha
el Butler writes:
> Seems that SVN r314659 broke this :-(
> 
>   Michael
> 
> On 03/04/17 11:11, O. Hartmann wrote:
> > At revision 314670, buildworld fails on all CURRENT machines with the error
>  shown below.
> > 
> > 
> > Regards,
> > 
> > oh
> > 
> > 
> > [...]
> > ===> usr.sbin/amd/hlfsd (all)
> > Building /usr/obj/usr/src/usr.sbin/amd/hlfsd/hlfsd
> > --- hlfsd ---
> > nfs_prot_svc.o: In function `nfs_program_2':
> > /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x5f): undefined reference
>  to
> > `xdr_attrstat' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x7d): unde
> fined
> > reference to `xdr_attrstat' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.tex
> t+0x82):
> > undefined reference to
> > `xdr_sattrargs' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0xa2): und
> efined
> > reference to `xdr_diropres' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.tex
> t+0xa7):
> > undefined reference to
> > `xdr_diropargs' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0xb8): und
> efined
> > reference to `xdr_readlinkres' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.
> text+0xc9):
> > undefined reference to
> > `xdr_readres' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0xce): undef
> ined reference
> > to `xdr_readargs' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0xf5): u
> ndefined
> > reference to `xdr_attrstat' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.tex
> t+0xfa):
> > undefined reference to
> > `xdr_writeargs' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x11b): un
> defined
> > reference to `xdr_nfsstat' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text
> +0x120):
> > undefined reference to
> > `xdr_renameargs' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x12e): u
> ndefined
> > reference to `xdr_nfsstat' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text
> +0x133):
> > undefined reference to
> > `xdr_linkargs' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x141): und
> efined
> > reference to `xdr_nfsstat' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text
> +0x146):
> > undefined reference to
> > `xdr_symlinkargs' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x154): 
> undefined
> > reference to `xdr_diropres' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.tex
> t+0x159):
> > undefined reference to
> > `xdr_createargs' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x167): u
> ndefined
> > reference to `xdr_nfsstat' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text
> +0x16c):
> > undefined reference to
> > `xdr_diropargs' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x17a): un
> defined
> > reference to `xdr_readdirres' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.t
> ext+0x17f):
> > undefined reference to
> > `xdr_readdirargs' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x18d): 
> undefined
> > reference to `xdr_statfsres' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.te
> xt+0x192):
> > undefined reference to `xdr_nfs_fh' stubs.o: In function
> > `nfsproc_readlink_2_svc': /usr/src/contrib/amd/hlfsd/stubs.c:(.text+0x6f7):
>  undefined
> > reference to `xdr_readlinkres' cc: error: linker command failed with exit c
> ode 1 (use -v
> > to see invocation) *** [hlfsd] 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"
> 
> 


___
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: panic: invalid bcd xxx

[Oleksandr Tymoshenko]

Adrian Chadd (adrian.ch...@gmail.com) wrote:
> On 2 March 2017 at 01:31, Matthias Apitz  wrote:
> > On Thursday, 2 March 2017 00:37:35 CET, Michael Gmelin 
> > wrote:
> >>
> >>
> >>
> >>> On 2 Mar 2017, at 00:35, Adrian Chadd  wrote:
> >>>
> >>> This is an emulated BIOS though, right?
> >>>
> >>> I don't know if we're going to get the RTC 'bugfixed'...
> >>>
> >>
> >>
> >> It's SeaBIOS, yes. I feel like this might end up in another
> >> quirk/workaround solution.
> >>
> >
> > I'm one of the C720 owners and  apart of Michael, I only know two users more
> > running FreeBSD. The SeaBIOS in our devices. is outdated, mine from 2013
> > IIRC. I dont know if there is an easy way to update this.
> 
> We're not; we need to cope with crappy BIOS emulations and not crash :)
> 
> What's Linux doing instead? Ignoring the RTC?

I believe I saw the same problem on either my NUC or Minnowboard.
I just hacked around it to work on something else and didn't
have time to get back to the device since then. But it's not
just emulation BIOS. I think the right way to go is to perform sanity
check on RTC data and refuse to use it if it's not valid.

-- 
gonzo
___
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: r314670: buildworld compile failure: undefined reference to `xdr_attrstat'

[Michael Butler]

Seems that SVN r314659 broke this :-(

Michael

On 03/04/17 11:11, O. Hartmann wrote:
> At revision 314670, buildworld fails on all CURRENT machines with the error 
> shown below.
> 
> 
> Regards,
> 
> oh
> 
> 
> [...]
> ===> usr.sbin/amd/hlfsd (all)
> Building /usr/obj/usr/src/usr.sbin/amd/hlfsd/hlfsd
> --- hlfsd ---
> nfs_prot_svc.o: In function `nfs_program_2':
> /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x5f): undefined reference to
> `xdr_attrstat' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x7d): 
> undefined
> reference to `xdr_attrstat' 
> /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x82):
> undefined reference to
> `xdr_sattrargs' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0xa2): 
> undefined
> reference to `xdr_diropres' 
> /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0xa7):
> undefined reference to
> `xdr_diropargs' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0xb8): 
> undefined
> reference to `xdr_readlinkres' 
> /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0xc9):
> undefined reference to
> `xdr_readres' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0xce): 
> undefined reference
> to `xdr_readargs' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0xf5): 
> undefined
> reference to `xdr_attrstat' 
> /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0xfa):
> undefined reference to
> `xdr_writeargs' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x11b): 
> undefined
> reference to `xdr_nfsstat' 
> /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x120):
> undefined reference to
> `xdr_renameargs' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x12e): 
> undefined
> reference to `xdr_nfsstat' 
> /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x133):
> undefined reference to
> `xdr_linkargs' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x141): 
> undefined
> reference to `xdr_nfsstat' 
> /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x146):
> undefined reference to
> `xdr_symlinkargs' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x154): 
> undefined
> reference to `xdr_diropres' 
> /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x159):
> undefined reference to
> `xdr_createargs' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x167): 
> undefined
> reference to `xdr_nfsstat' 
> /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x16c):
> undefined reference to
> `xdr_diropargs' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x17a): 
> undefined
> reference to `xdr_readdirres' 
> /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x17f):
> undefined reference to
> `xdr_readdirargs' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x18d): 
> undefined
> reference to `xdr_statfsres' 
> /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x192):
> undefined reference to `xdr_nfs_fh' stubs.o: In function
> `nfsproc_readlink_2_svc': /usr/src/contrib/amd/hlfsd/stubs.c:(.text+0x6f7): 
> undefined
> reference to `xdr_readlinkres' cc: error: linker command failed with exit 
> code 1 (use -v
> to see invocation) *** [hlfsd] 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"

r314670: buildworld compile failure: undefined reference to `xdr_attrstat'

[O. Hartmann]

At revision 314670, buildworld fails on all CURRENT machines with the error 
shown below.


Regards,

oh


[...]
===> usr.sbin/amd/hlfsd (all)
Building /usr/obj/usr/src/usr.sbin/amd/hlfsd/hlfsd
--- hlfsd ---
nfs_prot_svc.o: In function `nfs_program_2':
/usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x5f): undefined reference to
`xdr_attrstat' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x7d): undefined
reference to `xdr_attrstat' 
/usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x82):
undefined reference to
`xdr_sattrargs' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0xa2): 
undefined
reference to `xdr_diropres' 
/usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0xa7):
undefined reference to
`xdr_diropargs' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0xb8): 
undefined
reference to `xdr_readlinkres' 
/usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0xc9):
undefined reference to
`xdr_readres' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0xce): undefined 
reference
to `xdr_readargs' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0xf5): 
undefined
reference to `xdr_attrstat' 
/usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0xfa):
undefined reference to
`xdr_writeargs' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x11b): 
undefined
reference to `xdr_nfsstat' 
/usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x120):
undefined reference to
`xdr_renameargs' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x12e): 
undefined
reference to `xdr_nfsstat' 
/usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x133):
undefined reference to
`xdr_linkargs' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x141): 
undefined
reference to `xdr_nfsstat' 
/usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x146):
undefined reference to
`xdr_symlinkargs' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x154): 
undefined
reference to `xdr_diropres' 
/usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x159):
undefined reference to
`xdr_createargs' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x167): 
undefined
reference to `xdr_nfsstat' 
/usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x16c):
undefined reference to
`xdr_diropargs' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x17a): 
undefined
reference to `xdr_readdirres' 
/usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x17f):
undefined reference to
`xdr_readdirargs' /usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x18d): 
undefined
reference to `xdr_statfsres' 
/usr/src/contrib/amd/hlfsd/nfs_prot_svc.c:(.text+0x192):
undefined reference to `xdr_nfs_fh' stubs.o: In function
`nfsproc_readlink_2_svc': /usr/src/contrib/amd/hlfsd/stubs.c:(.text+0x6f7): 
undefined
reference to `xdr_readlinkres' cc: error: linker command failed with exit code 
1 (use -v
to see invocation) *** [hlfsd] Error code 1

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).


pgpmQsOq1G16d.pgp
Description: OpenPGP digital signature