date:20170316

How to automount an internal ntfs partition ?

2017-03-16 Thread Masachika ISHIZUKA

  Hi.

  I want to automount an ntfs partition on internal SSD.
  I did following on FreeBSD 12.0-CURRENT #0 r315059.
  
(1) install sysutils/fusefs-ntfs
(2) add fuse_load="YES" to /boot/loader.conf
(3) add '/- -noauto' to /etc/auto_master
(4) add '/dev/ada0p4  /windows  ntfs  
rw,noauto,uid=XXX,gid=XXX,dmask=022,fmask=133,locale=ja_JP.UTF-8,mountprog=/usr/local/bin/ntfs-3g,nosuid
 0 0' to /etc/fstab
(5) reboot

  At startup, the ntfs partition is on map as follows.
% mount | grep windows
map -noauto on /windows (autofs)
%

And it is automounted if I accessed it.
% ls /windows
/windows:
$GetCurrent/ProgramData/
$Recycle.Bin/   Recovery/
$WINRE_BACKUP_PARTITION.MARKER  System Volume Information/
Android/Users/
BOOTNXT Windows/
Documents and Settings@ Windows10Upgrade/
ESD/bootmgr
Intel/  pagefile.sys
Logs/   remixos_install.log
PerfLogs/   swapfile.sys
Program Files (x86)/tmp/
Program Files/
%

And the map is corrent.
% mount | grep windows
map -noauto on /windows (autofs)
/dev/fuse on /windows (fusefs, local, nosuid, synchronous, automounted)
%

But I don't access for 10 minutes, /windows is unmounted by autounmountd.
Then map is disappear.
% mount | grep windows
%

So /windows is no longer automounted.
% ls /windows
%

  How can I configure automountd for an internal ntfs partition.
  It is working well for ufs partitions and fat partitions.

# I want to automatic unmount partitions that are not accessed for a
  long time because it prevent from damage if some panic occurred.

# 11.0-RELEASE-p8 is the same result.
-- 
Masachika ISHIZUKA
___
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: process killed: text file modification

2017-03-16 Thread Rick Macklem

Hope you don't mind a top post...
Attached is a little patch you could test maybe?

rick

From: owner-freebsd-curr...@freebsd.org  on 
behalf of Rick Macklem 
Sent: Thursday, March 16, 2017 9:57:23 PM
To: Dimitry Andric; Ian Lepore
Cc: Gergely Czuczy; FreeBSD Current
Subject: Re: process killed: text file modification

Dimitry Andric wrote:
[lots of stuff snipped]
> I'm also running into this problem, but while using lld.  I must set
> vfs.timestamp_precision to 1 (e.g. sec + ns accurate to 1/HZ) on both
> the client and the server, to make it work.
>
> Instead of GNU ld, lld uses mmap to write to the output executable.  If
> this executable is more than one page, and resides on an NFS share,
> running it will almost always result in "text file modification", if
> vfs_timestamp_precision >= 2.
>
> A small test case: http://www.andric.com/freebsd/test-mmap-write.c,
> which writes a simple "hello world" i386-freebsd executable file, using
> the sequence: open() -> ftruncate() -> mmap() -> memcpy() -> munmap() ->
> close().
Hopefully Kostik will correct me if I have this wrong, but I don't believe any
of the above syscalls guarantee that dirty pages have been flushed.
At least for cases without munmap(), the writes of dirty pages can occur after
the file descriptor is closed. I run into this in NFSv4, where there is a Close 
(NFSv4 one)
that can't be done until VOP_INACTIVE().
If you look in the NFS VOP_INACTIVE() { called ncl_inactive() } you'll see:
if (NFS_ISV4(vp) && vp->v_type == VREG) {
237 /*
238  * Since mmap()'d files do I/O after VOP_CLOSE(), the 
NFSv4
239  * Close operations are delayed until now. Any dirty
240  * buffers/pages must be flushed before the close, so 
that the
241  * stateid is available for the writes.
242  */
243 if (vp->v_object != NULL) {
244 VM_OBJECT_WLOCK(vp->v_object);
245 retv = vm_object_page_clean(vp->v_object, 0, 0,
246 OBJPC_SYNC);
247 VM_OBJECT_WUNLOCK(vp->v_object);
248 } else
249 retv = TRUE;
250 if (retv == TRUE) {
251 (void)ncl_flush(vp, MNT_WAIT, NULL, ap->a_td, 
1, 0);
252 (void)nfsrpc_close(vp, 1, ap->a_td);
253 }
254 }
Note that nothing like this is done for NFSv3.
What might work is implementing a VOP_SET_TEXT() vnode op for the NFS
client that does most of the above (except for nfsrpc_close()) and then sets
VV_TEXT.
--> That way, all the dirty pages will be flushed to the server before the 
executable
 starts executing.

> Running this on an NFS share, and then attempting to run the resulting
> 'helloworld' executable will result in the "text file modification"
> error, and it will be killed.  But if you simply copy the executable to
> something else, then it runs fine, even if you use -p to retain the
> properties!
>
> IMHO this is a rather surprising problem with the NFS code, and Kostik
> remarked that the problem seems to be that the VV_TEXT flag is set too
> early, before the nfs cache is invalidated.  Rick, do you have any ideas
> about this?
I don't think it is the "nfs cache" that needs invalidation, but the dirty
pages written by the mmap'd file need to be flushed, before the VV_TEXT
is set, I think?

If Kostik meant "attribute cache" when he said "nfs cache", I'll note that the
cached attributes (including mtime) are updated by the reply to every write.
(As such, I think it is the writes that must be done before setting VV_TEXT
  that is needed.)

It is a fairly simple patch to create. I'll post one to this thread in a day or 
so
unless Kostik thinks this isn't correct and not worth trying.

rick


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


textmod.patch
Description: textmod.patch
___
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: process killed: text file modification

2017-03-16 Thread Rick Macklem

Dimitry Andric wrote:
[lots of stuff snipped]
> I'm also running into this problem, but while using lld.  I must set
> vfs.timestamp_precision to 1 (e.g. sec + ns accurate to 1/HZ) on both
> the client and the server, to make it work.
> 
> Instead of GNU ld, lld uses mmap to write to the output executable.  If
> this executable is more than one page, and resides on an NFS share,
> running it will almost always result in "text file modification", if
> vfs_timestamp_precision >= 2.
> 
> A small test case: http://www.andric.com/freebsd/test-mmap-write.c,
> which writes a simple "hello world" i386-freebsd executable file, using
> the sequence: open() -> ftruncate() -> mmap() -> memcpy() -> munmap() ->
> close().
Hopefully Kostik will correct me if I have this wrong, but I don't believe any
of the above syscalls guarantee that dirty pages have been flushed.
At least for cases without munmap(), the writes of dirty pages can occur after
the file descriptor is closed. I run into this in NFSv4, where there is a Close 
(NFSv4 one)
that can't be done until VOP_INACTIVE().
If you look in the NFS VOP_INACTIVE() { called ncl_inactive() } you'll see:
if (NFS_ISV4(vp) && vp->v_type == VREG) {
237 /*
238  * Since mmap()'d files do I/O after VOP_CLOSE(), the 
NFSv4
239  * Close operations are delayed until now. Any dirty
240  * buffers/pages must be flushed before the close, so 
that the
241  * stateid is available for the writes.
242  */
243 if (vp->v_object != NULL) {
244 VM_OBJECT_WLOCK(vp->v_object);
245 retv = vm_object_page_clean(vp->v_object, 0, 0,
246 OBJPC_SYNC);
247 VM_OBJECT_WUNLOCK(vp->v_object);
248 } else
249 retv = TRUE;
250 if (retv == TRUE) {
251 (void)ncl_flush(vp, MNT_WAIT, NULL, ap->a_td, 
1, 0);
252 (void)nfsrpc_close(vp, 1, ap->a_td);
253 }
254 }
Note that nothing like this is done for NFSv3.
What might work is implementing a VOP_SET_TEXT() vnode op for the NFS
client that does most of the above (except for nfsrpc_close()) and then sets
VV_TEXT.
--> That way, all the dirty pages will be flushed to the server before the 
executable
 starts executing.

> Running this on an NFS share, and then attempting to run the resulting
> 'helloworld' executable will result in the "text file modification"
> error, and it will be killed.  But if you simply copy the executable to
> something else, then it runs fine, even if you use -p to retain the
> properties!
>
> IMHO this is a rather surprising problem with the NFS code, and Kostik
> remarked that the problem seems to be that the VV_TEXT flag is set too
> early, before the nfs cache is invalidated.  Rick, do you have any ideas
> about this?
I don't think it is the "nfs cache" that needs invalidation, but the dirty
pages written by the mmap'd file need to be flushed, before the VV_TEXT
is set, I think?

If Kostik meant "attribute cache" when he said "nfs cache", I'll note that the
cached attributes (including mtime) are updated by the reply to every write.
(As such, I think it is the writes that must be done before setting VV_TEXT
  that is needed.)

It is a fairly simple patch to create. I'll post one to this thread in a day or 
so
unless Kostik thinks this isn't correct and not worth trying.

rick


___
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: fail world build

2017-03-16 Thread Roberto Rodriguez Jr

Using r315340 I simply commented out those 3 lines and buildworld and
kernel succesfuly compiled and installed.

--- pciconf.o ---
/usr/src/head/usr.sbin/pciconf/pciconf.c:703:3: error: use of
undeclared identifier 'PCIC_ACCEL'
{PCIC_ACCEL,-1, "processing
accelerators"},
 ^
/usr/src/head/usr.sbin/pciconf/pciconf.c:704:3: error: use of
undeclared identifier 'PCIC_ACCEL'
{PCIC_ACCEL,PCIS_ACCEL_PROCESSING,  "processing
accelerators"},
 ^
/usr/src/head/usr.sbin/pciconf/pciconf.c:704:16: error: use of
undeclared identifier 'PCIS_ACCEL_PROCESSING'
{PCIC_ACCEL,PCIS_ACCEL_PROCESSING,  "processing
accelerators"},
^
/usr/src/head/usr.sbin/pciconf/pciconf.c:705:3: error: use of
undeclared identifier 'PCIC_INSTRUMENT'
{PCIC_INSTRUMENT,


Im sure there is fixes on the way since I have yet to update my src tree
today :)
Its been 15 days of fails and finally a fresh native world  ;)

Thank You

Roberto
___
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: crash: umount_nfs: Current

2017-03-16 Thread Larry Rosenman

Err, I’m at  r315289….


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

On 3/16/17, 5:51 PM, "Rick Macklem"  wrote:

I believe the cause of this crash was fixed by a recent commit
to head r313735 (which was MFC'd to stable/11 and stable/10).

rick

From: owner-freebsd-curr...@freebsd.org  
on behalf of Larry Rosenman 
Sent: Wednesday, March 15, 2017 10:44:33 PM
To: freebsd...@freebsd.org
Cc: freebsd-current@FreeBSD.org
Subject: crash: umount_nfs: Current

Recent current, playing with new FreeNAS Corral, client is FreeBSD -CURRENT.

Lovely crash:

borg.lerctr.org dumped core - see /var/crash/vmcore.1

Wed Mar 15 21:38:53 CDT 2017

FreeBSD borg.lerctr.org 12.0-CURRENT FreeBSD 12.0-CURRENT #11 r315289: Tue 
Mar 14 20:55:36 CDT 2017 r...@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER  
amd64

panic: general protection fault

GNU gdb (GDB) 7.12.1 [GDB v7.12.1 for FreeBSD]
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd12.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/kernel/kernel...Reading symbols from 
/usr/lib/debug//boot/kernel/kernel.debug...done.
done.

Unread portion of the kernel message buffer:


Fatal trap 9: general protection fault while in kernel mode
cpuid = 1; apic id = 21
instruction pointer = 0x20:0x80a327ae
stack pointer   = 0x28:0xfe535ebb2800
frame pointer   = 0x28:0xfe535ebb2830
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 3172 (umount)
trap number = 9
panic: general protection fault
cpuid = 1
time = 1489631515
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
0xfe535ebb2440
vpanic() at vpanic+0x19c/frame 0xfe535ebb24c0
panic() at panic+0x43/frame 0xfe535ebb2520
trap_fatal() at trap_fatal+0x322/frame 0xfe535ebb2570
trap() at trap+0x5e/frame 0xfe535ebb2730
calltrap() at calltrap+0x8/frame 0xfe535ebb2730
--- trap 0x9, rip = 0x80a327ae, rsp = 0xfe535ebb2800, rbp = 
0xfe535ebb2830 ---
__mtx_lock_flags() at __mtx_lock_flags+0x3e/frame 0xfe535ebb2830
xprt_unregister() at xprt_unregister+0x28/frame 0xfe535ebb2850
clnt_reconnect_destroy() at clnt_reconnect_destroy+0x38/frame 
0xfe535ebb2880
nfs_unmount() at nfs_unmount+0x182/frame 0xfe535ebb28d0
dounmount() at dounmount+0x5c1/frame 0xfe535ebb2950
sys_unmount() at sys_unmount+0x30f/frame 0xfe535ebb2a70
amd64_syscall() at amd64_syscall+0x55a/frame 0xfe535ebb2bf0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe535ebb2bf0
--- syscall (22, FreeBSD ELF64, sys_unmount), rip = 0x800872b9a, rsp = 
0x7fffde88, rbp = 0x7fffe3c0 ---
Uptime: 2h43m8s
Dumping 5744 out of 131005 
MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%

Reading symbols from /boot/kernel/zfs.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/zfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/opensolaris.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/linux.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux_common.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/linux_common.ko.debug...done.
done.
Reading symbols from /boot/kernel/if_lagg.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/if_lagg.ko.debug...done.
done.
Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/coretemp.ko.debug...done.
done.
Reading symbols from /boot/kernel/aesni.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/aesni.ko.debug...done.
done.
Reading symbols from /boot/kernel/filemon.ko...Reading symbols from 
/usr

Re: crash: umount_nfs: Current

2017-03-16 Thread Rick Macklem

I believe the cause of this crash was fixed by a recent commit
to head r313735 (which was MFC'd to stable/11 and stable/10).

rick

From: owner-freebsd-curr...@freebsd.org  on 
behalf of Larry Rosenman 
Sent: Wednesday, March 15, 2017 10:44:33 PM
To: freebsd...@freebsd.org
Cc: freebsd-current@FreeBSD.org
Subject: crash: umount_nfs: Current

Recent current, playing with new FreeNAS Corral, client is FreeBSD -CURRENT.

Lovely crash:

borg.lerctr.org dumped core - see /var/crash/vmcore.1

Wed Mar 15 21:38:53 CDT 2017

FreeBSD borg.lerctr.org 12.0-CURRENT FreeBSD 12.0-CURRENT #11 r315289: Tue Mar 
14 20:55:36 CDT 2017 r...@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER  amd64

panic: general protection fault

GNU gdb (GDB) 7.12.1 [GDB v7.12.1 for FreeBSD]
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd12.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/kernel/kernel...Reading symbols from 
/usr/lib/debug//boot/kernel/kernel.debug...done.
done.

Unread portion of the kernel message buffer:

Fatal trap 9: general protection fault while in kernel mode
cpuid = 1; apic id = 21
instruction pointer = 0x20:0x80a327ae
stack pointer   = 0x28:0xfe535ebb2800
frame pointer   = 0x28:0xfe535ebb2830
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 3172 (umount)
trap number = 9
panic: general protection fault
cpuid = 1
time = 1489631515
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe535ebb2440
vpanic() at vpanic+0x19c/frame 0xfe535ebb24c0
panic() at panic+0x43/frame 0xfe535ebb2520
trap_fatal() at trap_fatal+0x322/frame 0xfe535ebb2570
trap() at trap+0x5e/frame 0xfe535ebb2730
calltrap() at calltrap+0x8/frame 0xfe535ebb2730
--- trap 0x9, rip = 0x80a327ae, rsp = 0xfe535ebb2800, rbp = 
0xfe535ebb2830 ---
__mtx_lock_flags() at __mtx_lock_flags+0x3e/frame 0xfe535ebb2830
xprt_unregister() at xprt_unregister+0x28/frame 0xfe535ebb2850
clnt_reconnect_destroy() at clnt_reconnect_destroy+0x38/frame 0xfe535ebb2880
nfs_unmount() at nfs_unmount+0x182/frame 0xfe535ebb28d0
dounmount() at dounmount+0x5c1/frame 0xfe535ebb2950
sys_unmount() at sys_unmount+0x30f/frame 0xfe535ebb2a70
amd64_syscall() at amd64_syscall+0x55a/frame 0xfe535ebb2bf0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe535ebb2bf0
--- syscall (22, FreeBSD ELF64, sys_unmount), rip = 0x800872b9a, rsp = 
0x7fffde88, rbp = 0x7fffe3c0 ---
Uptime: 2h43m8s
Dumping 5744 out of 131005 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%

Reading symbols from /boot/kernel/zfs.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/zfs.ko.debug...done.
done.
Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/opensolaris.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/linux.ko.debug...done.
done.
Reading symbols from /boot/kernel/linux_common.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/linux_common.ko.debug...done.
done.
Reading symbols from /boot/kernel/if_lagg.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/if_lagg.ko.debug...done.
done.
Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/coretemp.ko.debug...done.
done.
Reading symbols from /boot/kernel/aesni.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/aesni.ko.debug...done.
done.
Reading symbols from /boot/kernel/filemon.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/filemon.ko.debug...done.
done.
Reading symbols from /boot/kernel/fuse.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/fuse.ko.debug...done.
done.
Reading symbols from /boot/kernel/ichsmb.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/ichsmb.ko.debug...done.
done.
Reading symbols from /boot/kernel/smbus.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/smbus.ko.debug...done.
done.
Reading symbols from /boot/kernel/ichwd.ko...Reading symbols from 
/usr/lib/debug//boot/kernel/ichwd.ko.debug...done.
done.
Reading symbols from /boot/kernel/cpuctl.ko...Reading symbols from 
/usr/li

Re: process killed: text file modification

2017-03-16 Thread Dimitry Andric


> On 12 Mar 2017, at 18:47, Ian Lepore  wrote:
> 
> On Thu, 2017-03-09 at 21:07 +0100, Gergely Czuczy wrote:
>> 
>> On 2017. 03. 09. 20:47, Gergely Czuczy wrote:
>>> 
>>> 
>>> 
>>> On 2017. 03. 09. 19:44, John Baldwin wrote:
 
 On Thursday, March 09, 2017 03:31:56 PM Gergely Czuczy wrote:
> 
> [+freebsd-fs]
> 
> 
> On 2017. 03. 09. 14:20, Gergely Czuczy wrote:
>> 
>> On 2017. 03. 09. 11:27, Gergely Czuczy wrote:
>>> 
>>> Hello,
>>> 
>>> I'm trying to build a few things from ports on an rpi3, the
>>> ports
>>> collection is mounted over NFS from another machine. When
>>> it's trying
>>> to build pkg i'm getting the error message in syslog:
>>> 
>>> rpi3 kernel: pid 4451 (sh), uid 0, was killed: text file
>>> modification
>>> 
>>> The report to pkg@:
>>> https://lists.freebsd.org/pipermail/freebsd-pkg/2017-March/
>>> 002048.html
>>> 
>>> 
>>> In ports-mgmt/pkg's config.log It fails at the following
>>> entry:
>>> configure:3726: checking whether we are cross compiling
>>> configure:3734: cc -o conftest -O2 -pipe  -Wno-error
>>> -fno-strict-aliasing   conftest.c  >&5
>>> configure:3738: $? = 0
>>> configure:3745: ./conftest
>>> configure:3749: $? = 137
>>> configure:3756: error: in
>>> `/usr/ports/ports-mgmt/pkg/work/pkg-1.10.0':
>>> configure:3760: error: cannot run C compiled programs.
>>> If you meant to cross compile, use `--host'.
>>> See `config.log' for more details
>>> 
>>> # uname -a
>>> FreeBSD rpi3 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r314949:
>>> Thu Mar 9
>>> 08:58:46 CET 2017
>>> ae...@marvin.harmless.hu:/tank/rpi3/crochet/work/obj/arm64.
>>> aarch64/tank/rpi3/src/sys/AEGIR
>>> 
>>> arm64
>> So far, a few additions:
>> Time is synced between the NFS server and the client.
>> it's an open() call which is getting the kill, and it's not
>> the file
>> what's being opened, but the process executing it.
>> Here's a simple code that reproduces it:
>> #include 
>> 
>> int main() {
>> 
>>FILE *f = fopen ("/bar", "w");
>> 
>>fclose(f);
>>return 0;
>> }
>> 
>> Conditions to reproduce it:
>>   - The resulting binary must be executed from the nfs mount
>>   - The binary must be built after mounting the NFS share.
>> 
>> I haven't tried building it on a different host, I don't have
>> access
>> to multiple RPis. Also, if I build the binary, umount/remount
>> the NFS
>> mount point, which has the binary, execute it, then it works.
>> 
>> I've also tried this with the raspbsd.org's image, I could
>> reproduce
>> it as well.
>> 
>> Another interesting thing is, when I first booted the RPi up,
>> the NFS
>> server was a 10.2-STABLE, and later got updated to 11-STABLE.
>> While it
>> was 10.2 I've tried to build some port, and I don't remember
>> having
>> this issue.
>> 
>> So, could someone please help me figure this out and fix it?
>> This
>> stuff should work pretty much.
>> 
> So, this error message comes from here:
> https://svnweb.freebsd.org/base/head/sys/fs/nfsclient/nfs_clbio
> .c?revision=314436&view=markup#l1674
> 
> 
> It's the NFS_TIMESPEC_COMPARE(&np->n_mtime, &np-
>> n_vattr.na_mtime)
> comparision that fails, np should be the NFS node structure,
> from the
> vnode's v_data, and n_vattr is the attribute cache. As I've
> seen these
> two are being updated together, so I don't really see by the
> code why
> they might differ. Could someone please take a look at it, with
> more
> experience in the NFS code? -czg
 Can you print out the two mtimes?  I wonder if what's happening
 is that
 your server uses different granularity (for example just seconds)
 than
 your client, so on the client we generate a timestamp with a non-
 zero
 nanoseconds but when the server receives that timestamp it
 "truncates"
 it.  During open() we forcefully re-fetch the timestamp (for CTO
 consistency) and then notice it doesn't match.  For now I would
 start
 with comparing the timestamps and maybe the
 vfs.timestamp_precision
 sysctls on client and server (if server is a FreeBSD box).
>>> Here are the time values:
>>> Mar  9 19:46:01 rpi3 kernel: np->n_mtime: -3298114786344 +
>>> -3298114786336  &np->n_vattr.na_mtime: -3298114786616 +
>>> -3298114786608
>>> Mar  9 19:46:01 rpi3 kernel: pid 912 (csh), uid 0, was killed:
>>> text
>>> file modification
>>> Mar  9 19:46:01 rpi3 kernel: np->n_mtime: -3298114786344 +
>>> -3298114786336  &np->n_vattr.na_mtime: -3298114786616 +
>>> -3298114786608
>>> Mar  9 19:46:01 rpi3 kernel: pid 912 (csh), uid 0, was killed:
>>> text
>>> file modification
>>> 
>>> Printed this way:
>>>

Re: info.0 dump good

2017-03-16 Thread Jeffrey Bouquet



On Mon, 13 Mar 2017 14:04:23 -0700, John Baldwin  wrote:

> On Monday, March 13, 2017 12:28:44 PM Jeffrey Bouquet wrote:
> > Seems to happen when Xorg has a large webpage or a page idle for a time
> > 
> > Dump header from device: /dev/gpt/WDswap
> >   Architecture: i386
> >   Architecture Version: 2
> >   Dump Length: 285376512
> >   Blocksize: 512
> >   Dumptime: Mon Mar 13 12:12:37 2017
> >   Hostname: [redacted]com
> >   Magic: FreeBSD Kernel Dump
> >   Version String: FreeBSD 12.0-CURRENT #5 r313487: Thu Feb  9 17:32:03 PST 
> > 2017
> > com:/usr/obj/usr/src/sys/[custom kernel]
> >   Panic String: page fault
> >   Dump Parity: 1127850006
> >   Bounds: 0
> >   Dump Status: good
> > 
> > Viable to send the bounds, info.0 and vmcore.0 to somewhere where someone 
> > not
> > a comlete novice can find a bug somewhere?Unsure what email attachment 
> > allows
> > a 273MB file, an ftp server upstream ??  No time  to use kdbg for a few 
> > months anyway...
> 
> Do you have a core.txt.0 file?  If so it should contain a stack trace from
> kgdb which is the first thing that would be useful to obtain.
> 
> -- 
> John Baldwin


Sent the core.text.8 question, 
as not a kgbd expert, pending, earlier today, not to the list:


Now to the list, one of several daily backtraces, 
and/or lock order reversals, in dmesg, starting X, 
mounting or unmounting 2nd disks... this
from /var/log/messages...


kernel: lock order reversal:  
kernel: 1st 0xc21ebd84 ufs (ufs) @
kernel: 2nd 0xc2ca126c syncer (syncer) @
kernel: stack backtrace:   
kernel: #0 0xb5c22421 at witness_debugger+0x81 
kernel: #1 0xb5c22342 at witness_checkorder+0xd12 
kernel: #2 0xb5b9b5d4 at __lockmgr_args+0xa64 
kernel: #3 0xb5c784ad at vop_stdlock+0x4d 
kernel: #4 0xb618e7f7 at VOP_LOCK1_APV+0xd7 
kernel: #5 0xb5c9c137 at _vn_lock+0xb7 
kernel: #6 0xb5c8b00a at vputx+0x16a 
kernel: #7 0xb5c8286c at dounmount+0x5 
kernel: dc
kernel: #8 0xb5c82185 at sys_unmount+0x315 
kernel: #9 0xb6155fa5 at syscall+0x3b5 
kernel: #10 0xb6140ede at Xint0x80_syscall+0x2e 
kernel: lock order reversal:  
kernel: 1st 0xc21ebd84 ufs (ufs) @
kernel: 2nd 0xc0175150 devfs (devfs) @
kernel: stack backtrace:   
kernel: #0 0xb5c22421 at witness_debugger+0x81 
kernel: #1 0xb5c22342 at witnes 
kernel: s_checkorder+0xd12
kernel: #2 0xb5b9b5d4 at __lockmgr_args+0xa64 
kernel: #3 0x   
kernel: b5c784ad at vop_stdlock+0x4d  
kernel: #4 0xb618e7f7 at VOP_LOCK1_APV+0xd7 
kernel: #5 0xb5c9c137 at _vn_lock+0x 
kernel: b7
kernel: #6 0xb5eb9617 at ffs_flushfiles+0x157 
kernel: #7 0xb5e9d9aa at soft 
kernel: dep_flushfiles+0x17a
kernel: #8 0xb5ebc04c at ffs_unmount+0x7c 
kernel: #9 0xb5   
kernel: c8299b at dounmount+0x70b  
kernel: #10 0   
kernel: xb5c82185 at sys_unmount+0x315  
kernel: #11 0xb6155fa5 at syscall+0x3b5 
kernel: 
kernel: #12 0xb6140ede at Xint0x80_syscall+0x2e 
 
from the following two files:

1st 0xc21ebd84 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1277
2nd 0xc2ca126c syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2762


___
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: ntpd dies nightly on a server with jails

2017-03-16 Thread Don Lewis

On 16 Mar, O. Hartmann wrote:
> Am Wed, 15 Mar 2017 13:12:37 -0700
> Cy Schubert  schrieb:

>> > 
>> > When the clock is floating that wild, in all cases ntpd isn't
>> > running any mor e.
>> > I try to restart with options -g and -G to adjust the time quickly
>> > at the beginning, which works fine.
>> 
>> This is disconcerting. If your clock is floating wildly without ntpd 
>> running there are other issues that might be at play here. At most
>> the clock might drift a little, maybe a minute or two a day but not
>> by a lot. Does the drift cause your clocks to run fast or slow?
> 
> Today, I switched off ntpd on the jail-bearing host. After an hour or
> so the gain of the clock wasn't apart from my DCF77 clock - at least
> not within the granularity of the minutes. So I switched on ntpd
> again. After a while, I checked status via "service ntpd status", and
> I would bet off my ass that the result was "is running with PID XXX".
> The next minute I did the same, the clock was off by almost half an
> hour (always behind real time, never before!) and ntpd wasn't running.
> A coincidence? I can not tell, I did a "clear" on the terminal :-( But
> that was strange.

I think that ntp might exit if it sees time going insane.  According to
this old discussion, the exit is silent:
https://forum.pfsense.org/index.php?topic=53906.0

___
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: ntpd dies nightly on a server with jails

2017-03-16 Thread O. Hartmann

Am Wed, 15 Mar 2017 13:12:37 -0700
Cy Schubert  schrieb:


Thank you very much for responding.

> Hi O.Hartmann,
> 
> I'll try to answer as much as I can in the noon hour I have left.
> 
> In message <20170315071724.78bb0...@freyja.zeit4.iv.bundesimmobilien.de>, 
> "O. H
> artmann" writes:
> > Running a host with several jails on recent CURRENT (12.0-CURRENT #8 
> > r315187:
> > Sun Mar 12 11:22:38 CET 2017 amd64) makes me trouble on a daily basis.
> > 
> > The box is an older two-socket Fujitsu server equipted with two four-core
> > Intel(R) Xeon(R) CPU L5420  @ 2.50GHz.
> > 
> > The box has several jails, each jail does NOT run service ntpd. Each jail 
> > has
> > its dedicated loopback, lo1 throughout lo5 (for the moment) with dedicated 
> > IP
> > :
> > 127.0.1.1 - 127.0.5.1 (if this matter, I believe not).
> > 
> > The host itself has two main NICs, broadcom based. bcm0 is dedicated to the
> > host, bcm1 is shared amongst the jails: each jail has an IP bound to bcm1 
> > via
> > whihc the jails communicate with the network.
> > 
> > I try to capture log informations via syslog, but FreeBSD's ntpd seems to be
> > very, very sparse with such informations, coverging to null - I can't see
> > anything suiatble in the logs why NTPD dies almost every night leaving the
> > system with a wild reset of time. Sometimes it is a gain of 6 hours, 
> > sometime
> > s
> > it is only half an hour. I leave the box at 16:00 local time usually and 
> > take
> > care again at ~ 7 o'clock in the morning local time.  
> 
> We will need to turn on debugging. Unfortunately debug code is not compiled 
> into the binary. We have two options. You can either update 
> src/usr.sbin/ntp/config.h to enable DEBUG or build the port (it's the exact 
> same ntp) with the DEBUG option -- this is probably simpler. Then enable 
> debug with -d and -D. -D increases verbosity. I just committed a debug 
> option to both ntp ports to assist here.

I realised that this wasn't the case when I turned the switch on ntpd simply on 
- the
output was the same as before. So I feared that I have to recompile with 
debugging
explicitely switched on ...

> 
> Next question: Do you see any indication of a core dump? I'd be interested 
> in looking at it if possible.

I have, intentionally, switched off core dumping. I will switch that on. But in 
all
messages being logged and searched for "ntp", I never saw any error resulting 
in a crash,
but I'll look tomorrow closer.

> 
> > 
> > When the clock is floating that wild, in all cases ntpd isn't running any 
> > mor
> > e.
> > I try to restart with options -g and -G to adjust the time quickly at the
> > beginning, which works fine.  
> 
> This is disconcerting. If your clock is floating wildly without ntpd 
> running there are other issues that might be at play here. At most the 
> clock might drift a little, maybe a minute or two a day but not by a lot. 
> Does the drift cause your clocks to run fast or slow?

Today, I switched off ntpd on the jail-bearing host. After an hour or so the 
gain of the
clock wasn't apart from my DCF77 clock - at least not within the granularity of 
the
minutes. So I switched on ntpd again. After a while, I checked status via 
"service ntpd
status", and I would bet off my ass that the result was "is running with PID 
XXX". The
next minute I did the same, the clock was off by almost half an hour (always 
behind real
time, never before!) and ntpd wasn't running. A coincidence? I can not tell, I 
did a
"clear" on the terminal :-( But that was strange.

> 
> > 
> > Apart from possible misconfigurations of the jails (I'm quite new to jails 
> > an
> > d
> > their pitfalls), I was wondering what causes ntpd to die. i can't determine
> > exactly the time of its death, so it might be related to diurnal/periodic
> > processes (I use only the most vanilla configurations on periodic, except 
> > for
> > checking ZFS's scrubbing enabled).  
> 
> As I'm a little rushed for time, I didn't catch whether the jails 
> themselves were also running ntpd... just thought I'd ask. I don't see how 
> zfs scrubbing or any other periodic scripts could cause this.

The jails do not have ntpd running since all the docs I read tell, that the 
jail-bearing
host provides the time. So I checked/ double-checked, that they do not have 
ntpd running.

By mentioning ZFS and scrubbing I was more thinking about time-adjusting 
periodic jobs
like adjkerntz or friends - if there are any I'm not aware of. I see, it's more 
confusing.

> 
> > 
> > I'ven't had the chance to check whether the hardware is completely all 
> > right,
> > but from a superficial point of view there is no issue with high gain of the
> > internal clock or other hardware issues.  
> 
> It's probably a good idea to check. I don't think that would cause ntpd any 
> gas. I've seen RTC battery messages on my gear which haven't caused ntpd 
> any problem. I have two machines which complain about RTC battery being 
> dead, where in fact I have repla

Re: update an older i386 CURRENT system to amd64 CURRENT

2017-03-16 Thread Matthias Apitz

On Thursday, 16 March 2017 15:25:10 CET, Allan Jude  
wrote:




The problem is that the build system has built a cross compiler in
/usr/obj that it uses to do the building etc, and it is 64bit. Your
32bit OS cannot run it (gives Exec format error).



Thanks for all the replies I got.

Meanwhile I booted from a r314251 memstick, and all is installed fine.

matthias





--
Sent from my Ubuntu phone
http://www.unixarea.de/
___
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: update an older i386 CURRENT system to amd64 CURRENT

2017-03-16 Thread Allan Jude

On 2017-03-16 07:41, Matthias Apitz wrote:
> 
> 
> Hello,
> 
> I have an older FreeBSD 9.0-CURRENT system which I want to update to
> 12-CURRENT:
> 
> # uname -a
> FreeBSD vm-9Current 9.0-CURRENT FreeBSD 9.0-CURRENT #2 r220692: Sun Apr 17 
> 03:28:12 CEST 2011 guru@tinyCurrent:/usr/obj/usr/src/sys/GENERIC i386
> 
> To do so without compiling everything from scratch, I transferred
> /usr/src (r314251) and /usr/obj to this server, the compilation of
> /usr/obj was done on an amd64 server and the same procedure (transfer
> of /usr/src and /usr/obj) was also used to update my C720 netbook; the
> difference is here that the host which should be update is i386.
> 
> The 'make installkernel' did not work:
>  
> # pwd
> /usr/src
> # file ../obj/usr/src/sys/GENERIC/kernel
> ../obj/usr/src/sys/GENERIC/kernel: ELF 64-bit LSB executable, x86-64, version 
> 1 (FreeBSD), dynamically linked (uses shared libs), not stripped
> 
> # make installkernel
> 
> --
 Building an up-to-date bmake(1)
> --
> sh /usr/src/tools/install.sh -s -o root -g wheel -m 555   make
> /usr/obj/usr/src/make.i386/bmake
> --
 Installing kernel GENERIC
> --
> cd /usr/obj/usr/src/sys/GENERIC;  MAKEOBJDIRPREFIX=/usr/obj
> MACHINE_ARCH=i386  MACHINE=i386  CPUTYPE=
> GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin
> GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font
> GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac CC="cc
> -isystem /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib
> -B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp
> -B/usr/obj/usr/src/tmp/usr/bin" CXX="c++  -isystem
> /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib
> -B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp
> -B/usr/obj/usr/src/tmp/usr/bin"  CPP="cpp -isystem
> /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib
> -B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp
> -B/usr/obj/usr/src/tmp/usr/bin"  AS="as" AR="ar" LD="ld" LLVM_LINK=""
> NM=nm OBJCOPY="objcopy"  RANLIB=ranlib STRINGS=  SIZE="size"
> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin
> /usr/obj/usr/src/make.i386/bmake  KERNEL=kernel install
> cc: Exec format error
> bmake[1]: "/usr/src/share/mk/bsd.compiler.mk" line 145: Unable to
> determine compiler type for CC=cc -isystem
> /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib
> -B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp
> -B/usr/obj/usr/src/tmp/usr/bin.  Consider setting COMPILER_TYPE.
> *** Error code 1
> 
> 
> Also the following did not work:
> 
> # make installkernel MACHINE_ARCH=amd64 MACHINE=amd64
> 
> --
 Building an up-to-date bmake(1)
> --
> sh /usr/src/tools/install.sh -s -o root -g wheel -m 555   make
> /usr/obj/usr/src/make.amd64/bmake
> --
 Installing kernel GENERIC
> --
> cd /usr/obj/usr/src/sys/GENERIC;  MAKEOBJDIRPREFIX=/usr/obj
> MACHINE_ARCH=amd64  MACHINE=amd64  CPUTYPE=
> GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin
> GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font
> GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac CC="cc
> -isystem /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib
> -B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp
> -B/usr/obj/usr/src/tmp/usr/bin" CXX="c++  -isystem
> /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib
> -B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp
> -B/usr/obj/usr/src/tmp/usr/bin"  CPP="cpp -isystem
> /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib
> -B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp
> -B/usr/obj/usr/src/tmp/usr/bin"  AS="as" AR="ar" LD="ld" LLVM_LINK=""
> NM=nm OBJCOPY="objcopy"  RANLIB=ranlib STRINGS=  SIZE="size"
> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin
> /usr/obj/usr/src/make.i386/bmake  KERNEL=kernel install
> cc: Exec format error
> bmake[1]: "/usr/src/share/mk/bsd.compiler.mk" line 145: Unable to
> determine compiler type for CC=cc -isystem
> /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib
> -B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp
> -B/usr/obj/usr/src/tmp/usr/bin.  Consider setting COMPILER_TYPE.
> *** Err

Re: update an older i386 CURRENT system to amd64 CURRENT

2017-03-16 Thread Trond Endrestøl

On Thu, 16 Mar 2017 12:41+0100, Matthias Apitz wrote:

> 
> 
> Hello,
> 
> I have an older FreeBSD 9.0-CURRENT system which I want to update to
> 12-CURRENT:
> 
> # uname -a
> FreeBSD vm-9Current 9.0-CURRENT FreeBSD 9.0-CURRENT #2 r220692: Sun Apr 17 
> 03:28:12 CEST 2011 guru@tinyCurrent:/usr/obj/usr/src/sys/GENERIC i386
> 
> To do so without compiling everything from scratch, I transferred
> /usr/src (r314251) and /usr/obj to this server, the compilation of
> /usr/obj was done on an amd64 server and the same procedure (transfer
> of /usr/src and /usr/obj) was also used to update my C720 netbook; the
> difference is here that the host which should be update is i386.
> 
> The 'make installkernel' did not work:
>  
> # pwd
> /usr/src
> # file ../obj/usr/src/sys/GENERIC/kernel
> ../obj/usr/src/sys/GENERIC/kernel: ELF 64-bit LSB executable, x86-64, version 
> 1 (FreeBSD), dynamically linked (uses shared libs), not stripped
> 
> # make installkernel
> 
> --
> >>> Building an up-to-date bmake(1)
> --
> sh /usr/src/tools/install.sh -s -o root -g wheel -m 555   make
> /usr/obj/usr/src/make.i386/bmake
> --
> >>> Installing kernel GENERIC
> --
> cd /usr/obj/usr/src/sys/GENERIC;  MAKEOBJDIRPREFIX=/usr/obj
> MACHINE_ARCH=i386  MACHINE=i386  CPUTYPE=
> GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin
> GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font
> GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac CC="cc
> -isystem /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib
> -B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp
> -B/usr/obj/usr/src/tmp/usr/bin" CXX="c++  -isystem
> /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib
> -B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp
> -B/usr/obj/usr/src/tmp/usr/bin"  CPP="cpp -isystem
> /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib
> -B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp
> -B/usr/obj/usr/src/tmp/usr/bin"  AS="as" AR="ar" LD="ld" LLVM_LINK=""
> NM=nm OBJCOPY="objcopy"  RANLIB=ranlib STRINGS=  SIZE="size"
> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin
> /usr/obj/usr/src/make.i386/bmake  KERNEL=kernel install
> cc: Exec format error
> bmake[1]: "/usr/src/share/mk/bsd.compiler.mk" line 145: Unable to
> determine compiler type for CC=cc -isystem
> /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib
> -B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp
> -B/usr/obj/usr/src/tmp/usr/bin.  Consider setting COMPILER_TYPE.
> *** Error code 1
> 
> 
> Also the following did not work:
> 
> # make installkernel MACHINE_ARCH=amd64 MACHINE=amd64
> 
> --
> >>> Building an up-to-date bmake(1)
> --
> sh /usr/src/tools/install.sh -s -o root -g wheel -m 555   make
> /usr/obj/usr/src/make.amd64/bmake
> --
> >>> Installing kernel GENERIC
> --
> cd /usr/obj/usr/src/sys/GENERIC;  MAKEOBJDIRPREFIX=/usr/obj
> MACHINE_ARCH=amd64  MACHINE=amd64  CPUTYPE=
> GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin
> GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font
> GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac CC="cc
> -isystem /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib
> -B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp
> -B/usr/obj/usr/src/tmp/usr/bin" CXX="c++  -isystem
> /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib
> -B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp
> -B/usr/obj/usr/src/tmp/usr/bin"  CPP="cpp -isystem
> /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib
> -B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp
> -B/usr/obj/usr/src/tmp/usr/bin"  AS="as" AR="ar" LD="ld" LLVM_LINK=""
> NM=nm OBJCOPY="objcopy"  RANLIB=ranlib STRINGS=  SIZE="size"
> PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin
> /usr/obj/usr/src/make.i386/bmake  KERNEL=kernel install
> cc: Exec format error
> bmake[1]: "/usr/src/share/mk/bsd.compiler.mk" line 145: Unable to
> determine compiler type for CC=cc -isystem
> /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib
> -B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp
> -B/usr/obj/usr/src/tmp/usr/bin.  Consider setting COMPILER

update an older i386 CURRENT system to amd64 CURRENT

2017-03-16 Thread Matthias Apitz



Hello,

I have an older FreeBSD 9.0-CURRENT system which I want to update to
12-CURRENT:

# uname -a
FreeBSD vm-9Current 9.0-CURRENT FreeBSD 9.0-CURRENT #2 r220692: Sun Apr 17 
03:28:12 CEST 2011 guru@tinyCurrent:/usr/obj/usr/src/sys/GENERIC i386

To do so without compiling everything from scratch, I transferred
/usr/src (r314251) and /usr/obj to this server, the compilation of
/usr/obj was done on an amd64 server and the same procedure (transfer
of /usr/src and /usr/obj) was also used to update my C720 netbook; the
difference is here that the host which should be update is i386.

The 'make installkernel' did not work:
 
# pwd
/usr/src
# file ../obj/usr/src/sys/GENERIC/kernel
../obj/usr/src/sys/GENERIC/kernel: ELF 64-bit LSB executable, x86-64, version 1 
(FreeBSD), dynamically linked (uses shared libs), not stripped

# make installkernel

--
>>> Building an up-to-date bmake(1)
--
sh /usr/src/tools/install.sh -s -o root -g wheel -m 555   make
/usr/obj/usr/src/make.i386/bmake
--
>>> Installing kernel GENERIC
--
cd /usr/obj/usr/src/sys/GENERIC;  MAKEOBJDIRPREFIX=/usr/obj
MACHINE_ARCH=i386  MACHINE=i386  CPUTYPE=
GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin
GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font
GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac CC="cc
-isystem /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib
-B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp
-B/usr/obj/usr/src/tmp/usr/bin" CXX="c++  -isystem
/usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib
-B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp
-B/usr/obj/usr/src/tmp/usr/bin"  CPP="cpp -isystem
/usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib
-B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp
-B/usr/obj/usr/src/tmp/usr/bin"  AS="as" AR="ar" LD="ld" LLVM_LINK=""
NM=nm OBJCOPY="objcopy"  RANLIB=ranlib STRINGS=  SIZE="size"
PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin
/usr/obj/usr/src/make.i386/bmake  KERNEL=kernel install
cc: Exec format error
bmake[1]: "/usr/src/share/mk/bsd.compiler.mk" line 145: Unable to
determine compiler type for CC=cc -isystem
/usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib
-B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp
-B/usr/obj/usr/src/tmp/usr/bin.  Consider setting COMPILER_TYPE.
*** Error code 1


Also the following did not work:

# make installkernel MACHINE_ARCH=amd64 MACHINE=amd64

--
>>> Building an up-to-date bmake(1)
--
sh /usr/src/tools/install.sh -s -o root -g wheel -m 555   make
/usr/obj/usr/src/make.amd64/bmake
--
>>> Installing kernel GENERIC
--
cd /usr/obj/usr/src/sys/GENERIC;  MAKEOBJDIRPREFIX=/usr/obj
MACHINE_ARCH=amd64  MACHINE=amd64  CPUTYPE=
GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin
GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font
GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac CC="cc
-isystem /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib
-B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp
-B/usr/obj/usr/src/tmp/usr/bin" CXX="c++  -isystem
/usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib
-B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp
-B/usr/obj/usr/src/tmp/usr/bin"  CPP="cpp -isystem
/usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib
-B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp
-B/usr/obj/usr/src/tmp/usr/bin"  AS="as" AR="ar" LD="ld" LLVM_LINK=""
NM=nm OBJCOPY="objcopy"  RANLIB=ranlib STRINGS=  SIZE="size"
PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin
/usr/obj/usr/src/make.i386/bmake  KERNEL=kernel install
cc: Exec format error
bmake[1]: "/usr/src/share/mk/bsd.compiler.mk" line 145: Unable to
determine compiler type for CC=cc -isystem
/usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib
-B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp
-B/usr/obj/usr/src/tmp/usr/bin.  Consider setting COMPILER_TYPE.
*** Error code 1


Is there a way to use this /usr/src and pre-compiled /usr/obj on an i386
host for update? Or do I have to use a complete recompile or even
reinstall, based on a 64-bit memstick system?

Thanks

matthias


-- 
Matt

Re: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!]

2017-03-16 Thread Scott Bennett

Mark Millard  wrote:

> [Something strange happened to the automatic CC: fill-in for my original
> reply. Also I should have mentioned that for my test program if a
> variant is made that does not fork the swapping works fine.]
>
> On 2017-Mar-15, at 9:37 AM, Mark Millard  wrote:
>
> > On 2017-Mar-15, at 6:15 AM, Scott Bennett  wrote:
> > 
> >>On Tue, 14 Mar 2017 18:18:56 -0700 Mark Millard
> >>  wrote:
> >>> On 2017-Mar-14, at 4:44 PM, Bernd Walter  wrote:
> >>> 
>  On Tue, Mar 14, 2017 at 03:28:53PM -0700, Mark Millard wrote:
> > [test_check() between the fork and the wait/sleep prevents the
> > failure from occurring. Even a small access to the memory at
> > that stage prevents the failure. Details follow.]
>  
>  Maybe a stupid question, since you might have written it somewhere.
>  What medium do you swap to?
>  I've seen broken firmware on microSD cards doing silent data
>  corruption for some access patterns.
> >>> 
> >>> The root filesystem is on a USB SSD on a powered hub.
> >>> 
> >>> Only the kernel is from the microSD card.
> >>> 
> >>> I have several examples of the USB SSD model and have
> >>> never observed such problems in any other context.
> >>> 
> >>> [remainder of irrelevant material deleted  --SB]
> >> 
> >>You gave a very long-winded non-answer to Bernd's question, so I'll
> >> repeat it here.  What medium do you swap to?
> > 
> > My wording of:
> > 
> > The root filesystem is on a USB SSD on a powered hub.
> > 
> > was definitely poor. It should have explicitly mentioned the
> > swap partition too:
> > 
> > The root filesystem and swap partition are both on the same
> > USB SSD on a powered hub.
> > 
> > More detail from dmesg -a for usb:
> > 
> > usbus0: 12Mbps Full Speed USB v1.0
> > usbus1: 480Mbps High Speed USB v2.0
> > usbus2: 12Mbps Full Speed USB v1.0
> > usbus3: 480Mbps High Speed USB v2.0
> > ugen0.1:  at usbus0
> > uhub0:  on usbus0
> > ugen1.1:  at usbus1
> > uhub1:  on usbus1
> > ugen2.1:  at usbus2
> > uhub2:  on usbus2
> > ugen3.1:  at usbus3
> > uhub3:  on usbus3
> > . . .
> > uhub0: 1 port with 1 removable, self powered
> > uhub2: 1 port with 1 removable, self powered
> > uhub1: 1 port with 1 removable, self powered
> > uhub3: 1 port with 1 removable, self powered
> > ugen3.2:  at usbus3
> > uhub4 on uhub3
> > uhub4:  on 
> > usbus3
> > uhub4: MTT enabled
> > uhub4: 4 ports with 4 removable, self powered
> > ugen3.3:  at usbus3
> > umass0 on uhub4
> > umass0:  on usbus3
> > umass0:  SCSI over Bulk-Only; quirks = 0x0100
> > umass0:0:0: Attached to scbus0
> > . . .
> > da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
> > da0:  Fixed Direct Access SPC-4 SCSI device
> > da0: Serial Number 
> > da0: 40.000MB/s transfers
> > 
> > (Edited a bit because there is other material interlaced, even
> > internal to some lines. Also: I removed the serial number of the
> > specific example device.)

 Thank you.  That presents a much clearer picture.
> > 
> >>I will further note that any kind of USB device cannot automatically
> >> be trusted to behave properly.  USB devices are notorious, for example,
> >> 
> >>   [reasons why deleted  --SB]
> >> 
> >>You should identify where you page/swap to and then try substituting
> >> a different device for that function as a test to eliminate the possibility
> >> of a bad storage device/controller.  If the problem still occurs, that
> >> means there still remains the possibility that another controller or its
> >> firmware is defective instead.  It could be a kernel bug, it is true, but
> >> making sure there is no hardware or firmware error occurring is important,
> >> and as I say, USB devices should always be considered suspect unless and
> >> until proven innocent.
> > 
> > [FYI: This is a ufs context, not a zfs one.]

 Right.  It's only a Pi, after all. :-)
> > 
> > I'm aware of such  things. There is no evidence that has resulted in
> > suggesting the USB devices that I can replace are a problem. Otherwise
> > I'd not be going down this path. I only have access to the one arm64
> > device (a Pine64+ 2GB) so I've no ability to substitution-test what
> > is on that board.

 There isn't even one open port on that hub that you could plug a
flash drive into temporarily to be the paging device?  You could then
try your tests before returning to the normal configuration.  If there
isn't an open port, then how about plugging a second hub into one of
the first hub's ports and moving the displaced device to the second
hub?  A flash drive could then be plugged in.  That kind of configuration
is obviously a bad idea for the long run, but just to try your tests it
ought to work well enough.  (BTW, if a USB storage device containing a
paging area drops off=line even momentarily and the system needs to use
it, that is the beginning of the end, even though it may take up to a few
minutes for everything to lock up.  You probably won't be able to do an
orderly shutdown, but will instead have to

Re: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!]

2017-03-16 Thread Mark Millard

On 2017-Mar-15, at 11:07 PM, Scott Bennett  wrote:

> Mark Millard  wrote:
> 
>> [Something strange happened to the automatic CC: fill-in for my original
>> reply. Also I should have mentioned that for my test program if a
>> variant is made that does not fork the swapping works fine.]
>> 
>> On 2017-Mar-15, at 9:37 AM, Mark Millard  wrote:
>> 
>>> On 2017-Mar-15, at 6:15 AM, Scott Bennett  wrote:
>>> 
   On Tue, 14 Mar 2017 18:18:56 -0700 Mark Millard
  wrote:
> On 2017-Mar-14, at 4:44 PM, Bernd Walter  wrote:
> 
>> On Tue, Mar 14, 2017 at 03:28:53PM -0700, Mark Millard wrote:
>>> [test_check() between the fork and the wait/sleep prevents the
>>> failure from occurring. Even a small access to the memory at
>>> that stage prevents the failure. Details follow.]
>> 
>> Maybe a stupid question, since you might have written it somewhere.
>> What medium do you swap to?
>> I've seen broken firmware on microSD cards doing silent data
>> corruption for some access patterns.
> 
> The root filesystem is on a USB SSD on a powered hub.
> 
> Only the kernel is from the microSD card.
> 
> I have several examples of the USB SSD model and have
> never observed such problems in any other context.
> 
> [remainder of irrelevant material deleted  --SB]
 
   You gave a very long-winded non-answer to Bernd's question, so I'll
 repeat it here.  What medium do you swap to?
>>> 
>>> My wording of:
>>> 
>>> The root filesystem is on a USB SSD on a powered hub.
>>> 
>>> was definitely poor. It should have explicitly mentioned the
>>> swap partition too:
>>> 
>>> The root filesystem and swap partition are both on the same
>>> USB SSD on a powered hub.
>>> 
>>> More detail from dmesg -a for usb:
>>> 
>>> usbus0: 12Mbps Full Speed USB v1.0
>>> usbus1: 480Mbps High Speed USB v2.0
>>> usbus2: 12Mbps Full Speed USB v1.0
>>> usbus3: 480Mbps High Speed USB v2.0
>>> ugen0.1:  at usbus0
>>> uhub0:  on usbus0
>>> ugen1.1:  at usbus1
>>> uhub1:  on usbus1
>>> ugen2.1:  at usbus2
>>> uhub2:  on usbus2
>>> ugen3.1:  at usbus3
>>> uhub3:  on usbus3
>>> . . .
>>> uhub0: 1 port with 1 removable, self powered
>>> uhub2: 1 port with 1 removable, self powered
>>> uhub1: 1 port with 1 removable, self powered
>>> uhub3: 1 port with 1 removable, self powered
>>> ugen3.2:  at usbus3
>>> uhub4 on uhub3
>>> uhub4:  on 
>>> usbus3
>>> uhub4: MTT enabled
>>> uhub4: 4 ports with 4 removable, self powered
>>> ugen3.3:  at usbus3
>>> umass0 on uhub4
>>> umass0:  on usbus3
>>> umass0:  SCSI over Bulk-Only; quirks = 0x0100
>>> umass0:0:0: Attached to scbus0
>>> . . .
>>> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
>>> da0:  Fixed Direct Access SPC-4 SCSI device
>>> da0: Serial Number 
>>> da0: 40.000MB/s transfers
>>> 
>>> (Edited a bit because there is other material interlaced, even
>>> internal to some lines. Also: I removed the serial number of the
>>> specific example device.)
> 
> Thank you.  That presents a much clearer picture.
>>> 
   I will further note that any kind of USB device cannot automatically
 be trusted to behave properly.  USB devices are notorious, for example,
 
  [reasons why deleted  --SB]
 
   You should identify where you page/swap to and then try substituting
 a different device for that function as a test to eliminate the possibility
 of a bad storage device/controller.  If the problem still occurs, that
 means there still remains the possibility that another controller or its
 firmware is defective instead.  It could be a kernel bug, it is true, but
 making sure there is no hardware or firmware error occurring is important,
 and as I say, USB devices should always be considered suspect unless and
 until proven innocent.
>>> 
>>> [FYI: This is a ufs context, not a zfs one.]
> 
> Right.  It's only a Pi, after all. :-)

It is a Pine64+ 2GB, not an rpi3.

>>> 
>>> I'm aware of such  things. There is no evidence that has resulted in
>>> suggesting the USB devices that I can replace are a problem. Otherwise
>>> I'd not be going down this path. I only have access to the one arm64
>>> device (a Pine64+ 2GB) so I've no ability to substitution-test what
>>> is on that board.
> 
> There isn't even one open port on that hub that you could plug a
> flash drive into temporarily to be the paging device?

Why do you think that I've never tried alternative devices? It
is just that the result was no evidence that my usually-in-use
SSD is having a special/local problem: the behavior continues
across all such contexts when the Pine64+ 2GB is involved. (Again
I have not had access to an alternate to the one arm64 board.
That limits my substitution testing possibilities.)

Why would you expect a Flash drive to be better than another SSD
for such testing? (The SSD that I usually use even happens to be
a USB 3.0 SSD, capable of USB 3.0 speeds in USB 3.0 contexts. So
is the hub that I usually use

How to automount an internal ntfs partition ?

Re: process killed: text file modification

Re: process killed: text file modification

Re: fail world build

Re: crash: umount_nfs: Current

Re: crash: umount_nfs: Current

Re: process killed: text file modification

Re: info.0 dump good

Re: ntpd dies nightly on a server with jails

Re: ntpd dies nightly on a server with jails

Re: update an older i386 CURRENT system to amd64 CURRENT

Re: update an older i386 CURRENT system to amd64 CURRENT

Re: update an older i386 CURRENT system to amd64 CURRENT

update an older i386 CURRENT system to amd64 CURRENT

Re: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!]

Re: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!]

16 matches

Site Navigation

Mail list logo

Footer information