review: kernel GDB: do not reboot the target

[Eric van Gyzen]

I would like to call attention to this change to prevent accidentally 
rebooting the target of remote kernel GDB.  The code is mundane, but the 
default could be controversial.


https://reviews.freebsd.org/D35473

Please comment on the review, not on this thread.  If you need an 
account on Phabricator, see:


https://wiki.freebsd.org/Phabricator

Cheers,

Eric

Re: Alternate Screen

[Eric van Gyzen]

On 5/17/21 9:53 AM, Baptiste Daroussin wrote:

On Mon, May 17, 2021 at 09:46:49AM -0500, Eric van Gyzen wrote:

On 5/17/21 5:19 AM, Gary Jennejohn wrote:

On Sun, 16 May 2021 19:03:07 +0200
Baptiste Daroussin  wrote:


On Thu, May 13, 2021 at 09:01:53AM -0500, Eric van Gyzen wrote:

There was a recent discussion about a terminal database update and the new
Alternate Screen behavior.  I'm curious about the resolution, but I can't
find that discussion.  Would someone kindly send a clue-by-four via
overnight express?

Ultimately, I'd like to know how to get the old behavior back, with no
alternate screen, and thereby reduce my blood pressure.

Alternatively yours,


The replies you are receiving are interesting as none of them are right...

What has been done, it now ncurses from base reads both terminfo and termcap DB.
It is looking up for terminfo db from localbase as well.

Base only provides termcap (the old termcap definition, nothing new in there).
if one want the terminfo database which supports alternate screen definition,
he/shre can just pkg install terminfo-db.



But in March terminfo was being built and installed.  Maybe he failed to
delete /usr/share/terminfo after the change.  Or was simply not aware that
he had to do that.


Thanks for the help, everyone.  Deleting /usr/share/terminfo fixed the
problem.  (I don't have the terminfo-db package installed.)

Bapt, was this intentionally omitted from ObsoleteFiles.inc, or was that an
oversight?

Cheers,

Eric


It is in ObsoleteFiles.inc

# 20210318: remove the terminfo database


:facepalm:  I was looking at the wrong branch.  And I apparently forgot 
to delete-old.


Thanks again for wasting your time on me.

Eric
___
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: Alternate Screen

[Eric van Gyzen]

On 5/17/21 5:19 AM, Gary Jennejohn wrote:

On Sun, 16 May 2021 19:03:07 +0200
Baptiste Daroussin  wrote:


On Thu, May 13, 2021 at 09:01:53AM -0500, Eric van Gyzen wrote:

There was a recent discussion about a terminal database update and the new
Alternate Screen behavior.  I'm curious about the resolution, but I can't
find that discussion.  Would someone kindly send a clue-by-four via
overnight express?

Ultimately, I'd like to know how to get the old behavior back, with no
alternate screen, and thereby reduce my blood pressure.

Alternatively yours,


The replies you are receiving are interesting as none of them are right...

What has been done, it now ncurses from base reads both terminfo and termcap DB.
It is looking up for terminfo db from localbase as well.

Base only provides termcap (the old termcap definition, nothing new in there).
if one want the terminfo database which supports alternate screen definition,
he/shre can just pkg install terminfo-db.



But in March terminfo was being built and installed.  Maybe he failed to
delete /usr/share/terminfo after the change.  Or was simply not aware that
he had to do that.


Thanks for the help, everyone.  Deleting /usr/share/terminfo fixed the 
problem.  (I don't have the terminfo-db package installed.)


Bapt, was this intentionally omitted from ObsoleteFiles.inc, or was that 
an oversight?


Cheers,

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

Alternate Screen

[Eric van Gyzen]

There was a recent discussion about a terminal database update and the 
new Alternate Screen behavior.  I'm curious about the resolution, but I 
can't find that discussion.  Would someone kindly send a clue-by-four 
via overnight express?


Ultimately, I'd like to know how to get the old behavior back, with no 
alternate screen, and thereby reduce my blood pressure.


Alternatively yours,

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

top ARC stats are wrong

[Eric van Gyzen]

I would love to have 2 TB of RAM, but alas, I have a paltry 32 GB, and 
only 200 GB of disk used by ZFS:


ARC: 1860M Total, 612G MFU, K MRU, 1921G Anon, 12M Header, 157M Other

NAME SIZE  ALLOC   FREE
..   230G   178G  51.7G
..   298G  12.6G   285G

This is on r366500+84ccaf49083c-c272054.

I'll look into it when I have time, but that won't be soon.

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

Re: ZFS crash -- zvol_geom_bio_getattr called when volmode=dev

[Eric van Gyzen]

On 10/9/20 7:54 PM, Eric van Gyzen wrote:

On 10/9/20 6:27 PM, Ryan Moeller wrote:


On 10/9/20 6:22 PM, Alan Somers wrote:
This sounds like it might be a regression introduced by the OpenZFS 
merge.

Have you compared vdev_geom.c in OpenZFS vs the old version?
-Alan



I don't think vdev_geom.c is involved, we're taking a wrong path in 
zvol_os.c because
it seems the volume is created using the default volmode and later 
changed to volmode=dev.


Yes, you're on the right track.  I tried this several times on a VM and 
it eventually hit the window:


# zfs create -s -V 20G -o primarycache=none -o volmode=dev 
head_root/testvol

zvol_create_minor_impl:1250[1]: Creating ZVOL head_root/testvol...
zvol_create_minor_impl:1371[1]: ZVOL head_root/testvol created.


Fatal trap 12: page fault while in kernel mode


Let's track this in

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

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

Re: ZFS crash -- zvol_geom_bio_getattr called when volmode=dev

[Eric van Gyzen]

On 10/9/20 6:27 PM, Ryan Moeller wrote:


On 10/9/20 6:22 PM, Alan Somers wrote:
This sounds like it might be a regression introduced by the OpenZFS 
merge.

Have you compared vdev_geom.c in OpenZFS vs the old version?
-Alan



I don't think vdev_geom.c is involved, we're taking a wrong path in 
zvol_os.c because
it seems the volume is created using the default volmode and later 
changed to volmode=dev.


Yes, you're on the right track.  I tried this several times on a VM and 
it eventually hit the window:


# zfs create -s -V 20G -o primarycache=none -o volmode=dev head_root/testvol
zvol_create_minor_impl:1250[1]: Creating ZVOL head_root/testvol...
zvol_create_minor_impl:1371[1]: ZVOL head_root/testvol created.


Fatal trap 12: page fault while in kernel mode
cpuid = 7; apic id = 07
fault virtual address   = 0x110
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x82167fca
stack pointer   = 0x28:0xfe000edcdb30
frame pointer   = 0x28:0xfe000edcdb70
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 = 13 (g_down)
trap number = 12

db> acttrace

Tracing command zfskern pid 21 tid 100478 td 0xfe00610c9800 (CPU 6)
cpustop_handler() at cpustop_handler+0x28/frame 0xfe0011880e00
ipi_nmi_handler() at ipi_nmi_handler+0x39/frame 0xfe0011880e10
trap() at trap+0x56/frame 0xfe0011880f20
nmi_calltrap() at nmi_calltrap+0x8/frame 0xfe0011880f20
--- trap 0x13, rip = 0x80c25fb2, rsp = 0xfe006168c820, rbp = 
0xfe006168c830 ---

lock_delay() at lock_delay+0x42/frame 0xfe006168c830
_mtx_lock_spin_cookie() at _mtx_lock_spin_cookie+0xc1/frame 
0xfe006168c8a0
__mtx_lock_spin_flags() at __mtx_lock_spin_flags+0xd5/frame 
0xfe006168c8e0

cnputs() at cnputs+0x58/frame 0xfe006168c910
vprintf() at vprintf+0xcd/frame 0xfe006168c9e0
printf() at printf+0x43/frame 0xfe006168ca40
zvol_free() at zvol_free+0x53/frame 0xfe006168ca80
zvol_task_cb() at zvol_task_cb+0x271/frame 0xfe006168cae0
taskq_run() at taskq_run+0x1f/frame 0xfe006168cb00
taskqueue_run_locked() at taskqueue_run_locked+0xaa/frame 0xfe006168cb80
taskqueue_thread_loop() at taskqueue_thread_loop+0x94/frame 
0xfe006168cbb0

fork_exit() at fork_exit+0x80/frame 0xfe006168cbf0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe006168cbf0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---

Tracing command geom pid 13 tid 100049 td 0xfe0011862700 (CPU 7)
kdb_enter() at kdb_enter+0x37/frame 0xfe000edcd7e0
vpanic() at vpanic+0x19e/frame 0xfe000edcd830
panic() at panic+0x43/frame 0xfe000edcd890
trap_fatal() at trap_fatal+0x387/frame 0xfe000edcd8f0
trap_pfault() at trap_pfault+0x97/frame 0xfe000edcd950
trap() at trap+0x2ab/frame 0xfe000edcda60
calltrap() at calltrap+0x8/frame 0xfe000edcda60
--- trap 0xc, rip = 0x82167fca, rsp = 0xfe000edcdb30, rbp = 
0xfe000edcdb70 ---

zvol_geom_bio_start() at zvol_geom_bio_start+0x2a/frame 0xfe000edcdb70
g_io_schedule_down() at g_io_schedule_down+0x134/frame 0xfe000edcdba0
g_down_procbody() at g_down_procbody+0x5c/frame 0xfe000edcdbb0
fork_exit() at fork_exit+0x80/frame 0xfe000edcdbf0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe000edcdbf0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---

(The other CPUs were idle.)


On Fri, Oct 9, 2020 at 3:48 PM Eric van Gyzen  wrote:


On 10/9/20 4:39 PM, Eric van Gyzen wrote:
Does this look familiar?  I'm creating a zvol with volmode=dev, but 
some

geom code paths were taken.  If this looks new, I'll provide more

details.

primarycache=none also seems to be a factor.  I can easily repro with:

zfs create -s -V 10G -o primarycache=none -o volmode=dev .../testvol



I don't think primarycache is a factor, I can easily repro with 
primarycache left at the default.
The volmode property is being set asynchronously and losing the race 
with the initial creation of
the minors. When volmode is changed the minor is supposed to be 
destroyed and then recreated
in the correct mode, but that does not seem to be working correctly. 
Setting vfs.zfs.debug=1 you
can see in dmesg the zvol is created once in volmode=geom and then a 
second attempt to create

the zvol fails, because zvol_free did not occur.

zvol_create_minor_impl:1250[1]: Creating ZVOL p0/testvol...
name=p0/testvol error=0 volmode=1
zvol_create_minor_impl:1372[1]: ZVOL p0/testvol created.
zvol_create_minor_impl:1250[1]: Creating ZVOL p0/testvol...

So something is preventing zv_free from being called by 
zvol_remove_minors_impl.


-Ryan





13.0-CURRENT r366500+84ccaf49083c-c272054 GENERIC

#8  
#9  zvol_geom_bio_getattr (bp=0xf80376132900)
  at 
/usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/zvol_os.c:545

#10 zvol_geom_bio_start (bp=0xf80376132

Re: ZFS crash -- zvol_geom_bio_getattr called when volmode=dev

[Eric van Gyzen]

On 10/9/20 4:39 PM, Eric van Gyzen wrote:
Does this look familiar?  I'm creating a zvol with volmode=dev, but some 
geom code paths were taken.  If this looks new, I'll provide more details.


primarycache=none also seems to be a factor.  I can easily repro with:

zfs create -s -V 10G -o primarycache=none -o volmode=dev .../testvol


13.0-CURRENT r366500+84ccaf49083c-c272054 GENERIC

#8  
#9  zvol_geom_bio_getattr (bp=0xf80376132900)
     at /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/zvol_os.c:545
#10 zvol_geom_bio_start (bp=0xf80376132900)
     at /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/zvol_os.c:519
#11 0x80b1c684 in g_io_schedule_down (tp=)
     at /usr/src/sys/geom/geom_io.c:848
#12 0x80b1cfcc in g_down_procbody (arg=)
     at /usr/src/sys/geom/geom_kern.c:111

(kgdb) f 9
#9  zvol_geom_bio_getattr (bp=0xf80376132900)
     at /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/zvol_os.c:545
545    spa_t *spa = dmu_objset_spa(zv->zv_objset);

(kgdb) l
540    zvol_state_t *zv;
541
542    zv = bp->bio_to->private;
543    ASSERT(zv != NULL);
544
545    spa_t *spa = dmu_objset_spa(zv->zv_objset);
546    uint64_t refd, avail, usedobjs, availobjs;
547
548    if (g_handleattr_int(bp, "GEOM::candelete", 1))
549    return (0);

(kgdb) p zv
$1 = (zvol_state_t *) 0x0

(kgdb) p *bp
$3 = {
   bio_cmd = 4,
   bio_flags = 0,
   bio_cflags = 0,
   bio_pflags = 0,
   bio_dev = 0x0,
   bio_disk = 0x0,
   bio_offset = 0,
   bio_bcount = 0,
   bio_data = 0xf801fa687c00 "",
   bio_ma = 0x0,
   bio_ma_offset = 0,
   bio_ma_n = 0,
   bio_error = 0,
   bio_resid = 0,
   bio_done = 0x0,
   bio_driver1 = 0x0,
   bio_driver2 = 0x0,
   bio_caller1 = 0x0,
   bio_caller2 = 0x0,
   bio_queue = {
     tqe_next = 0x,
     tqe_prev = 0x
   },
   bio_attribute = 0x81223c03 "GEOM::physpath",
   bio_zone = {
     zone_cmd = 0 '\000',
     zone_params = {
   disk_params = {
     zone_mode = 0,
     flags = 0,
     optimal_seq_zones = 0,
     optimal_nonseq_zones = 0,
     max_seq_zones = 0
   },
   rwp = {
     id = 0,
     flags = 0 '\000'
   },
   report = {
     starting_id = 0,
     rep_options = 0 '\000',
     header = {
   same = 0 '\000',
   maximum_lba = 0,
   reserved = '\000' 
     },
     entries_allocated = 0,
     entries_filled = 0,
     entries_available = 0,
     entries = 0x0
   }
     }
   },
   bio_from = 0xf80006b92880,
   bio_to = 0xf80006972500,
   bio_length = 1024,
   bio_completed = 0,
   bio_children = 0,
   bio_inbed = 0,
   bio_parent = 0x0,
   bio_t0 = {
     sec = 50,
     frac = 10248368299661698441
   },
   bio_task = 0x0,
   bio_task_arg = 0x0,
   bio_spare1 = 0x0,
   bio_spare2 = 0x0,
   bio_track_bp = 0x0,
   bio_pblkno = 0
}

(kgdb) p *bp->bio_to
$4 = {
   name = 0xf80006972598 "zvol/disco_fast/vm/onefs1-1/disk7",
   provider = {
     le_next = 0x0,
     le_prev = 0xf80006972428
   },
   geom = 0xf80006972400,
   consumers = {
     lh_first = 0xf80006b92880
   },
   acr = 1,
   acw = 0,
   ace = 0,
   error = 0,
   orphan = {
     tqe_next = 0x0,
     tqe_prev = 0x0
   },
   mediasize = 5368709120,
   sectorsize = 512,
   stripesize = 8192,
   stripeoffset = 0,
   stat = 0xf80006d3d120,
   spare1 = 0,
   spare2 = 0,
   flags = 48,
   aliases = {
     lh_first = 0x0
   },
   private = 0x0,
   index = 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"

ZFS crash -- zvol_geom_bio_getattr called when volmode=dev

[Eric van Gyzen]

Does this look familiar?  I'm creating a zvol with volmode=dev, but some 
geom code paths were taken.  If this looks new, I'll provide more details.


Thanks in advance,

Eric


13.0-CURRENT r366500+84ccaf49083c-c272054 GENERIC

#8  
#9  zvol_geom_bio_getattr (bp=0xf80376132900)
at /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/zvol_os.c:545
#10 zvol_geom_bio_start (bp=0xf80376132900)
at /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/zvol_os.c:519
#11 0x80b1c684 in g_io_schedule_down (tp=)
at /usr/src/sys/geom/geom_io.c:848
#12 0x80b1cfcc in g_down_procbody (arg=)
at /usr/src/sys/geom/geom_kern.c:111

(kgdb) f 9
#9  zvol_geom_bio_getattr (bp=0xf80376132900)
at /usr/src/sys/contrib/openzfs/module/os/freebsd/zfs/zvol_os.c:545
545 spa_t *spa = dmu_objset_spa(zv->zv_objset);

(kgdb) l
540 zvol_state_t *zv;
541 
542 zv = bp->bio_to->private;
543 ASSERT(zv != NULL);
544 
545 spa_t *spa = dmu_objset_spa(zv->zv_objset);
546 uint64_t refd, avail, usedobjs, availobjs;
547 
548 if (g_handleattr_int(bp, "GEOM::candelete", 1))
549 return (0);

(kgdb) p zv
$1 = (zvol_state_t *) 0x0

(kgdb) p *bp
$3 = {
  bio_cmd = 4,
  bio_flags = 0,
  bio_cflags = 0,
  bio_pflags = 0,
  bio_dev = 0x0,
  bio_disk = 0x0,
  bio_offset = 0,
  bio_bcount = 0,
  bio_data = 0xf801fa687c00 "",
  bio_ma = 0x0,
  bio_ma_offset = 0,
  bio_ma_n = 0,
  bio_error = 0,
  bio_resid = 0,
  bio_done = 0x0,
  bio_driver1 = 0x0,
  bio_driver2 = 0x0,
  bio_caller1 = 0x0,
  bio_caller2 = 0x0,
  bio_queue = {
tqe_next = 0x,
tqe_prev = 0x
  },
  bio_attribute = 0x81223c03 "GEOM::physpath",
  bio_zone = {
zone_cmd = 0 '\000',
zone_params = {
  disk_params = {
zone_mode = 0,
flags = 0,
optimal_seq_zones = 0,
optimal_nonseq_zones = 0,
max_seq_zones = 0
  },
  rwp = {
id = 0,
flags = 0 '\000'
  },
  report = {
starting_id = 0,
rep_options = 0 '\000',
header = {
  same = 0 '\000',
  maximum_lba = 0,
  reserved = '\000' 
},
entries_allocated = 0,
entries_filled = 0,
entries_available = 0,
entries = 0x0
  }
}
  },
  bio_from = 0xf80006b92880,
  bio_to = 0xf80006972500,
  bio_length = 1024,
  bio_completed = 0,
  bio_children = 0,
  bio_inbed = 0,
  bio_parent = 0x0,
  bio_t0 = {
sec = 50,
frac = 10248368299661698441
  },
  bio_task = 0x0,
  bio_task_arg = 0x0,
  bio_spare1 = 0x0,
  bio_spare2 = 0x0,
  bio_track_bp = 0x0,
  bio_pblkno = 0
}

(kgdb) p *bp->bio_to
$4 = {
  name = 0xf80006972598 "zvol/disco_fast/vm/onefs1-1/disk7",
  provider = {
le_next = 0x0,
le_prev = 0xf80006972428
  },
  geom = 0xf80006972400,
  consumers = {
lh_first = 0xf80006b92880
  },
  acr = 1,
  acw = 0,
  ace = 0,
  error = 0,
  orphan = {
tqe_next = 0x0,
tqe_prev = 0x0
  },
  mediasize = 5368709120,
  sectorsize = 512,
  stripesize = 8192,
  stripeoffset = 0,
  stat = 0xf80006d3d120,
  spare1 = 0,
  spare2 = 0,
  flags = 48,
  aliases = {
lh_first = 0x0
  },
  private = 0x0,
  index = 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"

LOR: tun_ioctl after tun_mtx

[Eric van Gyzen]

I see this LOR on head r364364 while running the tcptestsuite 
(ports/net/tcptestsuite).  In fact, I interrupted a test with Ctrl-C, 
and got a panic.  I assume it's the same, since the test was twiddling 
the MTU, but I haven't looked closely.


Eric

lock order reversal: (sleepable after non-sleepable)
 1st 0xf802238ea690 tun_mtx (tun_mtx, sleep mutex) @ 
/usr/src/sys/net/if_tuntap.c:1628
 2nd 0x81d99d28 tun_ioctl (tun_ioctl, sx) @ 
/usr/src/sys/net/if_tuntap.c:1326

lock order tun_ioctl -> tun_mtx established at:
#0 0x80c432dd at witness_checkorder+0x46d
#1 0x80bb38e4 at __mtx_lock_flags+0x94
#2 0x80cfad2b at tuninit+0x4b
#3 0x80cfa44f at tunifioctl+0x6f
#4 0x80dc398f at in6_update_ifa+0xa8f
#5 0x80dc96f0 at in6_ifattach+0x5b0
#6 0x80dc577e at in6_if_up+0x7e
#7 0x80ceb289 at if_up+0x69
#8 0x80cec2f7 at ifhwioctl+0xd07
#9 0x80ced475 at ifioctl+0x395
#10 0x80c490ae at kern_ioctl+0x28e
#11 0x80c48d77 at sys_ioctl+0x127
#12 0x81015820 at amd64_syscall+0x140
#13 0x80febb3e at fast_syscall_common+0xf8
lock order tun_mtx -> tun_ioctl attempted at:
#0 0x80c43c3c at witness_checkorder+0xdcc
#1 0x80be0247 at _sx_xlock+0x67
#2 0x80cfa411 at tunifioctl+0x31
#3 0x80ceba5b at ifhwioctl+0x46b
#4 0x80cf9101 at tunioctl+0x5b1
#5 0x80a7b0fc at devfs_ioctl+0xcc
#6 0x80cc9bf2 at vn_ioctl+0x132
#7 0x80a7b76e at devfs_ioctl_f+0x1e
#8 0x80c490ae at kern_ioctl+0x28e
#9 0x80c48d77 at sys_ioctl+0x127
#10 0x81015820 at amd64_syscall+0x140
#11 0x80febb3e at fast_syscall_common+0xf8

local/tcptestsuite/tcptestsuite_atf_test:snd_syn_mss_inherited_from_mtu_72_ipv4 
 ->  ^C[-- Signal caught; please wait for cleanup --]


Sleeping thread (tid 100505, pid 61414) owns a non-sleepable lock
KDB: stack backtrace of thread 100505:
sched_switch() at sched_switch+0x5b2/frame 0xfe00627165a0
mi_switch() at mi_switch+0x155/frame 0xfe00627165c0
sleepq_switch() at sleepq_switch+0x109/frame 0xfe0062716600
_sx_xlock_hard() at _sx_xlock_hard+0x42e/frame 0xfe00627166a0
_sx_xlock() at _sx_xlock+0xba/frame 0xfe00627166e0
tunifioctl() at tunifioctl+0x31/frame 0xfe0062716720
ifhwioctl() at ifhwioctl+0x46b/frame 0xfe00627167a0
tunioctl() at tunioctl+0x5b1/frame 0xfe0062716810
devfs_ioctl() at devfs_ioctl+0xcc/frame 0xfe0062716860
vn_ioctl() at vn_ioctl+0x132/frame 0xfe0062716970
devfs_ioctl_f() at devfs_ioctl_f+0x1e/frame 0xfe0062716990
kern_ioctl() at kern_ioctl+0x28e/frame 0xfe0062716a00
sys_ioctl() at sys_ioctl+0x127/frame 0xfe0062716ad0
amd64_syscall() at amd64_syscall+0x140/frame 0xfe0062716bf0
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe0062716bf0
--- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8005818fa, rsp = 
0x7fffd408, rbp = 0x7fffd540 ---

panic: sleeping thread
cpuid = 4
time = 1597942792
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
0xfe00652545e0

vpanic() at vpanic+0x182/frame 0xfe0065254630
panic() at panic+0x43/frame 0xfe0065254690
propagate_priority() at propagate_priority+0x219/frame 0xfe00652546d0
turnstile_wait() at turnstile_wait+0x380/frame 0xfe0065254720
__mtx_lock_sleep() at __mtx_lock_sleep+0x1cc/frame 0xfe00652547b0
__mtx_lock_flags() at __mtx_lock_flags+0xe5/frame 0xfe0065254800
tunifioctl() at tunifioctl+0xdc/frame 0xfe0065254840
ifhwioctl() at ifhwioctl+0x2b1/frame 0xfe00652548c0
ifioctl() at ifioctl+0x395/frame 0xfe0065254990
kern_ioctl() at kern_ioctl+0x28e/frame 0xfe0065254a00
sys_ioctl() at sys_ioctl+0x127/frame 0xfe0065254ad0
amd64_syscall() at amd64_syscall+0x140/frame 0xfe0065254bf0
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe0065254bf0
--- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8004b48fa, rsp = 
0x7fffd428, rbp = 0x7fffdc50 ---

KDB: enter: panic
[ thread pid 61418 tid 100573 ]
Stopped at  kdb_enter+0x37: movq$0,0x10b70b6(%rip)
___
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: ${COMPILER_VERSION} < 40300

[Eric van Gyzen]

If I were to clean up obsolete ${COMPILER_VERSION} tests in the tree, 
which ones should I keep?  I would probably confine it to head, so I 
could prune quite a few.


Thanks for the feedback, everyone.  If you're interested:

https://reviews.freebsd.org/D24802

Eric
___
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: ${COMPILER_VERSION} < 40300

[Eric van Gyzen]

On 5/8/20 1:22 PM, John Baldwin wrote:

I think Eric though was asking about  and the like.


Actually, I was asking about makefile conditions, but this is still a 
good discussion to have.  I'm in a cleanup mood.



(BTW, it would be good to know if it's at all useful to keep any of the
icc bits around.)


Intel made a FreeBSD version of their 2016 compiler.

https://software.intel.com/content/www/us/en/develop/articles/intel-system-studio-2016-for-freebsd.html

That uses Clang as a front-end, so maybe some of the old icc bits can 
still go away.  I still have a copy of that compiler, so I can test 
things as needed.


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

${COMPILER_VERSION} < 40300

[Eric van Gyzen]

If I were to clean up obsolete ${COMPILER_VERSION} tests in the tree, 
which ones should I keep?  I would probably confine it to head, so I 
could prune quite a few.


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

toolchain status

[Eric van Gyzen]

Which architectures are still often built with an external toolchain? 
I'd like to re-commit jemalloc 5.2.1.  It was reverted because 
"compilation fails for non-llvm-based platforms."  I just built 
tinderbox worlds with 5.2.1 with no problems, albeit with llvm.


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

spurious(?) userland malloc/mmap failure

[Eric van Gyzen]

While running head r356494, my buildworld just failed due to an 
apparently spurious userland malloc/mmap failure.


===> usr.bin/finger (all)
objcopy: elf_update() failed: I/O error: Cannot allocate memory
--- all_subdir_usr.bin/finger ---
*** [all_subdir_usr.bin/finger] Error code 2

I ran 'make' in usr.bin/finger, and objcopy succeeded.  I then ran "make 
buildenv" followed by "make clean" and "make" in usr.bin/finger, which 
also worked.


buildworld was running with -j8, and a few C++ things were building 
concurrently, such as googletest and usr.bin/clang/llvm-objdump, so 
maybe the machine was under memory pressure.  It's a bhyve VM with 8 
CPUs and 8 GB RAM.


The full build log is:

https://people.freebsd.org/~vangyzen/2010-01-13-buildworld.txt

Eric
___
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: ffs_fhtovp: inode overflow?

[Eric van Gyzen]

On 12/11/19 3:55 PM, Konstantin Belousov wrote:

On Wed, Dec 11, 2019 at 10:26:41AM -0600, Eric van Gyzen wrote:

Since ino64 went in, Coverity complains that the two "ino >= foo"
comparisons in ffs_fhtovp() compare a 64-bit value to a 32-bit.  Is this
a problem in practice?


I do not think that this a problem, and Coverity could be a bit smarter
there.

The ino variable is 64bit, but why is it worrysome to compare it with a
32 bit value ?   We want to limit the value to the max possible inode
number but still keep it type-correct.


I incorrectly thought that UFS supported 64-bit inodes.  Thanks for 
correcting me, Kostik.


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

ffs_fhtovp: inode overflow?

[Eric van Gyzen]

Since ino64 went in, Coverity complains that the two "ino >= foo" 
comparisons in ffs_fhtovp() compare a 64-bit value to a 32-bit.  Is this 
a problem in practice?


Eric
___
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: dtrace not working on bhyve VM without invariant_tsc

[Eric van Gyzen]

> On Dec 9, 2019, at 8:27 PM, Ryan Stone  wrote:
> 
> I have a bhyve VM guest on my laptop where dtrace just constantly
> aborts whenever I try to use it:
> 
> [rstone@ebpf dtrace]sudo dtrace -s fdcopy.d
> Assertion failed: (buf->dtbd_timestamp >= first_timestamp), file
> /usr/home/rstone/git/bsd-worktree/ebpf-import/cddl/contrib/opensolaris/lib/libdtrace/common/dt_consume.c,
> line 3026.
> Abort trap
> 
> I believe that the problem is caused by dtrace unconditionally using
> rdtsc() to implement dtrace_gethrtime(), assuming that the values will
> be stable for a given CPU.  The VM's vcpus seem to be getting migrated
> frequently.
> 
> Should dtrace instead be using the system timecounter?  That should
> stand a much better chance of being monotonically increasing.

I’ve seen TSC issues with OneFS under bhyve on certain CPUs.  Pinning the VM to 
CPUs 1-N (i.e. avoiding CPU 0) worked around it.  You might try that as a 
workaround.

Eric
___
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: Networking panic on 12 - found the cause

[Eric van Gyzen]

On 2/12/19 8:53 AM, Pete French wrote:
> I found my panic. If I take everything out of rc.conf and loader.conf
> and sysctl.conf and boot the system it works fine when I add an IP
> address. If I add this one line to sysctl.conf
> 
> net.link.ether.inet.garp_rexmit_count=2
> 
> Then I get a panic when I configure the interface:
> 
> root@serpentine-passive:~ #  ifconfig igb0 inet 10.32.10.4/16 up
> 
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address   = 0x28
> fault code  = supervisor read data, page not present
> instruction pointer = 0x20:0x80c987f1
> stack pointer   = 0x28:0xfe4d5730
> frame pointer   = 0x28:0xfe4d5750
> 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 = 12 (swi4: clock (0))
> trap number = 12
> panic: page fault
> cpuid = 0
> time = 1549981620
> KDB: stack backtrace:
> #0 0x80bdfdc7 at kdb_backtrace+0x67
> #1 0x80b93fa3 at vpanic+0x1a3
> #2 0x80b93df3 at panic+0x43
> #3 0x8106a7bf at trap_fatal+0x35f
> #4 0x8106a819 at trap_pfault+0x49
> #5 0x81069e3e at trap+0x29e
> #6 0x810450c5 at calltrap+0x8
> #7 0x80c986f6 at ether_output+0x6b6
> #8 0x80d03354 at arprequest+0x4c4
> #9 0x80d0515c at garp_rexmit+0xbc
> #10 0x80bade19 at softclock_call_cc+0x129
> #11 0x80bae2f9 at softclock+0x79
> #12 0x80b57c57 at ithread_loop+0x1a7
> #13 0x80b54da2 at fork_exit+0x82
> #14 0x810460be at fork_trampoline+0xe

I see the same behavior on head (and stable/12).

(kgdb) f
#16 0x80ce5331 in ether_output_frame (ifp=0xf80003672800,
m=0xf8000c88b100) at /usr/src/sys/net/if_ethersubr.c:468
468 switch (pfil_run_hooks(V_link_pfil_head, , ifp, 
PFIL_OUT,

   0x80ce5321 <+81>:mov%gs:0x0,%rax
   0x80ce532a <+90>:mov0x500(%rax),%rax
=> 0x80ce5331 <+97>:mov0x28(%rax),%rax

I think this is part of the V_link_pfil_head.  I'm not very familiar
with vnet.  Does this need a CURVNET_SET(), maybe in garp_rexmit()?

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

toolchain(s) for universe kernels

[Eric van Gyzen]

I want to

make MAKE_JUST_KERNELS=1 universe

but it seems that I need a toolchain first.  There are multiple
toolchain-ish make targets.  If I start with an empty obj, which
toolchain target(s) should I build?

Eric
___
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: 12-BETA1 contains warning about non-PNP ISA device

[Eric van Gyzen]

On 10/25/18 6:57 AM, Rodney W. Grimes wrote:

I noticed a warning on a new AMD system running 12-BETA1:

non-PNP ISA device will be removed from GENERIC in FreeBSD 12.

Can you please reply with the specific device.
If you have seen one it may be an issue to removing it,
especially if this is on a "new AMD" system.


Further investigation shows me that this comes from
generic code in sys/isa/isa_common.c, and does not
come from any specific driver markings.


My new Ryzen says:

atkbdc0: non-PNP ISA device will be removed from GENERIC in FreeBSD 12.

Believe it or not, my motherboard has a PS/2 connector, so I could 
actually use this driver someday.


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

iflib_timer hits hung label; never recovers

[Eric van Gyzen]

My firewall is running head at r338402 (30 Aug).  It has three I211 NICs 
(PCI dev 0x1539).  About 24 hours ago, it said:


Oct 11 22:29:03 asbestos kernel: igb1: TX(1) desc avail = 42, pidx = 524
Oct 11 22:29:03 asbestos kernel: Link state changed to down
Oct 11 22:29:03 asbestos kernel: core: link state changed to DOWN

It keeps saying this periodically:

Oct 12 09:46:05 asbestos kernel: igb1: TX(1) desc avail = 1024, pidx = 0

$ dmesg | uniq -c
2455 igb1: TX(1) desc avail = 1024, pidx = 0

I can panic the box and get a vmcore, but what other information should 
I get before then?  I tried to attach kgdb to the running kernel, but it 
failed.  :(


I grabbed sysctl dev.igb.1 and dropped it here:

http://vangyzen.net/FreeBSD/igb.hang/

I haven't tried manually recovering with ifconfig because I want to 
diagnose why the driver couldn't do it automatically.  I imagine it's 
hard to test this code path.  :)


Eric
___
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: Good motherboard for Ryzen (first-gen)

[Eric van Gyzen]

On 9/21/18 9:53 PM, Eric van Gyzen wrote:
I would like to build a Ryzen desktop.  Can anyone recommend a good 
motherboard?


I'm planning on a first-gen, because the second-gen has similar 
stability problems as the first-gen had, and AMD hasn't released errata 
for the second-gen yet (as far as I know...I would love to be wrong).


I would like to be a cool kid with a Threadripper, but I can't justify 
the cost, so I'm thinking maybe a Ryzen 7 with /only/ 8 cores.  :)


Ideally, I want an Intel NIC, ECC memory support, and a 3-year warranty.


Thanks for all the responses.  They were very helpful.  Here is what I 
ended up building:


Mobo:  ASUS Prime X470-Pro
CPU:   Ryzen 7 2700X 3.7GHz 8-Core
RAM:   Corsair Vengeance LPX 2 x 16GB DDR4-2666 PC4-21300 C16
Video: ASUS GeForce GTX 1060 6GB
Disk:  Samsung 970 EVO 500GB TLC NAND M.2 2280 PCIe NVMe 3.0 x4
PSU:   EVGA SuperNOVA G3 750 Watt 80 Plus Gold ATX
Fan:   Cooler Master Hyper 212 EVO Universal CPU Cooler

It's running FreeBSD head.  BIOS version is 4018 (2018-07-12).  So far, 
it has been perfectly stable.  No crashes, no lockups.  It has been my 
work-from-home desktop for just over a week now.  I'm overclocking the 
memory a little, but nothing else.  The NIC works.  The sound works, 
though I've only tested the rear analog output.  The video card works 
with the nvidia-driver, currently 390.87.  It's driving two 2560x1440 
monitors over HDMI.


The only problem so far:  I can't get NUMA enabled.  I've set Memory 
Interleave to "off", but the BIOS still doesn't generate an ACPI SRAT 
table.  I'm still working on this.


Eric
___
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: Sound issues with Dell Latitude 7490 (kabylake)

[Eric van Gyzen]

Thanks. So if you try this:

sysctl dev.hdaa.0.nid24_config="as=4 seq=15"
sysctl dev.hdaa.0.nid21_config="as=1 seq=15"
sysctl dev.hdaa.0.reconfig=1


Works, thank you!


  Dude that's some serious shit !
  Jacob, is this documented somewhere ?
  I haven't read the driver code but what does as/seq etc represent
there ?


snd_hda(4) is very helpful.


  What could we do to make this
easier for users ?


We can commit similar changes to the kernel driver.  kstaring on github 
has ported many such changes from Linux to FreeBSD:


https://github.com/freebsd/freebsd/pull/139
https://github.com/freebsd/freebsd/pull/144

I don't know if his port includes the changes Rod needs.

I was planning to commit these when life calms down enough to test them. 
 If anyone beats me to it, I would be delighted.  I was also waiting 
until after 12.0, but in hindsight, I wish I had just committed them.


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

Good motherboard for Ryzen (first-gen)

[Eric van Gyzen]

I would like to build a Ryzen desktop.  Can anyone recommend a good 
motherboard?


I'm planning on a first-gen, because the second-gen has similar 
stability problems as the first-gen had, and AMD hasn't released errata 
for the second-gen yet (as far as I know...I would love to be wrong).


I would like to be a cool kid with a Threadripper, but I can't justify 
the cost, so I'm thinking maybe a Ryzen 7 with /only/ 8 cores.  :)


Ideally, I want an Intel NIC, ECC memory support, and a 3-year warranty.

Thanks in advance,

Eric

___
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: Bad DHCP Checksums over VLANs

[Eric van Gyzen]

On 9/15/18 1:06 AM, Kurt Jaeger wrote:

Can you disable all the options of the NIC ?

ifconfig igb0 -rxcsum -txcsum -wol -tso4 -vlanmtu -vlanhwtag -vlanhwcsum 
-vlanhwtso

Try to disable everything that can be disabled, e.g. LRO etc.


Disabling vlanhwtag works around the problem.

Also note that only DHCP traffic has this problem.  If I assign an 
address manually, all traffic flows normally.  Maybe the problem is in 
the BPF send path.


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

Bad DHCP Checksums over VLANs

[Eric van Gyzen]

Folks,

I'm running head (ALPHA4-ish) on a DHCP server and a client.  DHCP works 
fine on the physical interfaces, but when I run it on a VLAN, I get


5 bad udp checksums in 5 packets

from dhclient.  Full details here:

https://people.freebsd.org/~vangyzen/dhcp_vlan/

This happens for /all/ clients.

This is a new setup, so I don't know when it got broken, and I can't bisect.

The server NIC is common (I211), so maybe it's easy to reproduce.  I'll 
help as much as I can, of course.


Eric
___
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 user and group missing when upgrading from sources from 11-stable to 12-current

[Eric van Gyzen]

On 9/13/18 4:07 PM, Marek Zarychta wrote:

Dear subscribers,

stable/12 hasn't been branched yet, so it could be not a bug. Since
r336525 make installworld fails on 11-stable when installing world for
12-current without ntpd user/group added. Of course, as a workaround
user and group could be added manually. Mergemeaster also fails when it
is run before installworld, what is IMHO predictable and expected
behaviour. So mergemaster will not help with this issue.

So the question arises, is it a feature or should a PR be submitted?


Did you run mergemaster with the -p flag before installworld?

Eric
___
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: arc_reclaim_thread running hot

[Eric van Gyzen]

On 9/13/18 8:18 AM, Eric van Gyzen wrote:
This morning, I found the arc_reclaim_thread running hot on my laptop 
running 12.0-ALPHA5 r338572.


vfs.zfs.arc_max="4294967296"  <-- 4 GiB

last pid: 13288;  load averages:  1.32,  1.26,  1.16
Mem: 456M Active, 3837M Inact, 743M Laundry, 2563M Wired, 167M Free
ARC: 1131M Total, 304M MFU, 145M MRU, 1344K Anon, 9116K Header, 671M Other
  89M Compressed, 361M Uncompressed, 4.03:1 Ratio

    22 root -8    -  0   256K CPU2 2 309:20  99.75% 
zfskern{arc_reclaim_thread}


zfs_arc_meta_strategy is still the default of 1.

I sampled the thread's stacks with

for N in `jot 1000`; do procstat -kk 100101; done | grep 100101

and put the results here:

https://people.freebsd.org/~vangyzen/arc_reclaim_thread_stacks.txt

I'm happy to help debug this.  Just let me know what you need.


The thread eventually returned to normal, and I've rebooted the system 
since then, so I no longer have any state.  The thread started running 
hot at 03:00, so maybe the daily periodic run triggered it.  I have to 
work now, but I'll try running the periodic stuff manually when I have time.


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

arc_reclaim_thread running hot

[Eric van Gyzen]

This morning, I found the arc_reclaim_thread running hot on my laptop 
running 12.0-ALPHA5 r338572.


vfs.zfs.arc_max="4294967296"  <-- 4 GiB

last pid: 13288;  load averages:  1.32,  1.26,  1.16 


Mem: 456M Active, 3837M Inact, 743M Laundry, 2563M Wired, 167M Free
ARC: 1131M Total, 304M MFU, 145M MRU, 1344K Anon, 9116K Header, 671M Other
 89M Compressed, 361M Uncompressed, 4.03:1 Ratio

   22 root -8-  0   256K CPU2 2 309:20  99.75% 
zfskern{arc_reclaim_thread}


zfs_arc_meta_strategy is still the default of 1.

I sampled the thread's stacks with

for N in `jot 1000`; do procstat -kk 100101; done | grep 100101

and put the results here:

https://people.freebsd.org/~vangyzen/arc_reclaim_thread_stacks.txt

I'm happy to help debug this.  Just let me know what you need.

Eric
___
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: Request for Review: Generate /etc/services from the IANA registry

[Eric van Gyzen]

On 9/11/18 10:04 AM, Steffen Nurpmeso wrote:

Alan Somers wrote in :
  |Don't worry Steffen.  Python won't be a build requirement for FreeBSD \
  |even after Eric's patch.  His Python script will only need to be run \
  |whenever IANA
  |updates its database, and the results will be checked into source contro\
  |l.  So for a normal user, there is no change to "make buildworld && make
  |installworld".

I cannot, unfortunately.  I use binary updates and even
preinstalled VM images (thanks for that, by the way).


So there will be no impact on you at all, except that /etc/services will 
have a lot more services.  As Alan said, Python and XML will only be 
added to the developer workflow.



  |As for Python vs Awk, I too tried to do this with Awk.  However, Awk \
  |can't easily handle things like IANA's representation of aliases, and \
  |it can't
  |easily format the list in the same order as our current list.  Python \
  |is truly a better choice.

I absolutely fail to see what you mean.  The script (which is in
actual use, mind you) generates the desired output except that
comments get lost, but this could be added upon interest, of
course.  It (or a derivative) would have been a good candidate for
/usr/share/misc/ in elder times i guess, too.


That awk script depends on the formatting of the XML file.  It will 
break if the IANA decides to format it differently.  Granted, this is 
unlikely, but it's possible.


Also, that script would become much more complex if it supported local 
additions and overrides, which are unfortunately necessary in our case.


Eric
___
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: Request for Review: Generate /etc/services from the IANA registry

[Eric van Gyzen]

On 9/10/18 12:04 PM, Eric van Gyzen wrote:
Would anyone like to review this change to generate /etc/services from 
the IANA registry?


 https://reviews.freebsd.org/D17106


If that review made your browser unhappy, try this one instead:

https://reviews.freebsd.org/D17115

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

Request for Review: Generate /etc/services from the IANA registry

[Eric van Gyzen]

Would anyone like to review this change to generate /etc/services from 
the IANA registry?


https://reviews.freebsd.org/D17106

Thanks,

Eric
___
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: Celeron J3160 with enabled Turbo mode stays at 480MHz (lowestsetting) forever and can not lower frequency without Tuebo mode

[Eric van Gyzen]

On 9/5/18 4:35 AM, Lev Serebryakov wrote:

  BTW, these four settings in rc.conf(5)

   performance_cx_lowest
   performance_cpu_freq
   economy_cx_lowest
   economy_cpu_freq

do NOTHING. They are not used ANYWHERE but rc.conf and rc.conf.5!


They are used by /etc/rc.d/power_profile, but not in a way that grep can 
find.



  BTW, "Turbo mode enabled + dev.cpu.X.cx_lowset=C3 + powerd" works, but
gives only 1601 Mhz, not 2240MHz max:

TURBO ON:
dev.cpu.0.freq_levels: 1601/2000 1600/2000 1520/1900 1440/1800 1360/1700 
1280/1600 1200/1500 1120/1400 1040/1300 960/1200 880/1100 800/1000 720/900 
640/800 560/700 480/600 420/525 360/450 300/375 240/300 180/225 120/150 60/75

TURBO OFF:
dev.cpu.0.freq_levels: 1600/2000 1520/1900 1440/1800 1360/1700 1280/1600 
1200/1500 1120/1400 1040/1300 960/1200 880/1100 800/1000 720/900 640/800 
560/700 480/600 420/525 360/450 300/375 240/300 180/225 120/150 60/75


1601 is not the actual frequency.  That is just how it is reported.  It 
is almost certainly running much higher than 1601.


Eric
___
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: Make drm drivers use MTRR write-combine

[Eric van Gyzen]

On 8/14/18 4:12 AM, Johannes Lundberg wrote:

Hi

Something that we have seen for a long time on FreeBSD is the boot message

Failed to add WC MTRR for [0xd000-0xdfff]: -22; performance may
suffer

Taking a closer look at this with memcontrol I can see that the 256 MB
region that DRM wants to set as WC is already covered by this entry
0xc000/0x4000 BIOS uncacheable set-by-firmware active

Similar on both my Skylake and Broadwell systems.

I see something similar on my Dell XPS 13 with a Kaby Lake R:

Failed to add WC MTRR for [0x9000-0x9fff]: -22; performance may 
suffer


0x8000/0x8000 BIOS uncacheable set-by-firmware active

The only mappings in this range are MMIO:

machdep.efi_map:
  Type Physical  Virtual   #Pages Attr
[snip]
MemoryMappedIO e000   0xe000 0001 RUNTIME
MemoryMappedIO fe00   0xfe00 0011 UC RUNTIME
MemoryMappedIO fec0   0xfec0 0001 UC RUNTIME
MemoryMappedIO fee0   0xfee0 0001 UC WT WB WP RUNTIME
MemoryMappedIO ff00   0xff00 1000 UC WT WB WP RUNTIME

Eric
___
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: Ryzen public erratas

[Eric van Gyzen]

On 06/13/2018 05:35, Konstantin Belousov wrote:
> Today I noted that AMD published the public errata document for Ryzens,
> https://developer.amd.com/wp-content/resources/55449_1.12.pdf
> 
> Some of the issues listed there looks quite relevant to the potential
> hangs that some people still experience with the machines.  I wrote
> a script which should apply the recommended workarounds to the erratas
> that I find interesting.
> 
> To run it, kldload cpuctl, then apply the latest firmware update to your
> CPU, then run the following shell script.  Comments indicate the errata
> number for the workarounds.
> 
> Please report the results.  If the script helps, I will code the kernel
> change to apply the workarounds.
Kostik:  This thread on the -stable list has a lot of positive feedback:

https://lists.freebsd.org/pipermail/freebsd-stable/2018-June/089110.html

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

Realtek RTS525A SD card reader

[Eric van Gyzen]

Is anyone working on a FreeBSD driver for the Realtek RTS525A SD card
reader?  My new Dell XPS 13 has one:

none7@pci0:59:0:0: class=0xff card=0x075b1028 chip=0x525a10ec
rev=0x01 hdr=0x00
vendor = 'Realtek Semiconductor Co., Ltd.'
device = 'RTS525A PCI Express Card Reader'

I see that the OpenBSD rtsx driver supports it:

https://github.com/openbsd/src/commit/2c295edd2d779a7f5269c2ae901559edbf040016

I don't know anything about SD/MMC devices and standards, and I'm not
familiar with FreeBSD's current SD/MMC code, but I think it would be fun
to learn.  Does it make sense to try porting this driver, or would
someone recommend a different approach?

Thanks in advance for any advice.

Eric

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

System76 Galago Pro with 8th gen CPU

[Eric van Gyzen]

Has anyone tried -CURRENT on the latest System76 Galago Pro with an 8th
gen Kaby Lake R?  All the reports I've heard, including the Laptops page
on the wiki, concern systems with a 7th gen Kaby Lake.

Eric

___
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: td_swvoltick

[Eric van Gyzen]

On 01/12/2018 13:36, Konstantin Belousov wrote:
> On Fri, Jan 12, 2018 at 01:31:41PM -0600, Eric van Gyzen wrote:
>> should_yield() compares thread::td_swvoltick to 'ticks' to determine
>> whether a thread is hogging and should yield.  Since td_swvoltick
>> records 'ticks' /before/ the actual context switch, the calculation in
>> should_yield() includes any time that the thread was switched out.  It
>> seems that should_yield() wants to know how long the thread has actually
>> been running.  Therefore, td_swvoltick should record 'ticks' /after/
>> sched_switch() returns.
>>
>> Does this make sense, or am I missing something?
> Yes, it does make sense to me.

Thanks, Kostik.

If anyone else is interested:  https://reviews.freebsd.org/D13892

>>
>> If this makes sense, I would probably keep the current assignment in
>> mi_switch() and simply add a second assignment after the call to
>> sched_switch().  That way, db_show_thread will still show useful data
>> for sleeping threads.  I would do the same for td_swinvolticks.
>>
>> I'll be happy to make the change myself.  I just want a sanity check
>> before I bother.
>>
>> Thanks in advance,
>>
>> Eric
___
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"

td_swvoltick

[Eric van Gyzen]

should_yield() compares thread::td_swvoltick to 'ticks' to determine
whether a thread is hogging and should yield.  Since td_swvoltick
records 'ticks' /before/ the actual context switch, the calculation in
should_yield() includes any time that the thread was switched out.  It
seems that should_yield() wants to know how long the thread has actually
been running.  Therefore, td_swvoltick should record 'ticks' /after/
sched_switch() returns.

Does this make sense, or am I missing something?

If this makes sense, I would probably keep the current assignment in
mi_switch() and simply add a second assignment after the call to
sched_switch().  That way, db_show_thread will still show useful data
for sleeping threads.  I would do the same for td_swinvolticks.

I'll be happy to make the change myself.  I just want a sanity check
before I bother.

Thanks in advance,

Eric
___
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: r320358 panics immediately on boot / AMD64-GENERIC kernel

[Eric van Gyzen]

On 06/27/2017 11:09, Michael Jung wrote:
> Screen image with backtrace
> 
> https://pasteboard.co/dZRVG5Uo.jpg
> 
> 
> After upgrading from 318959 to 320358 I immediately get the attached panic.
> 
> This is AMD64 / GENERIC kernel.
> 
> /boot/loader.conf is empty.
> 
> The system boots off a UFS2 partition.
> 
> This is a virtual guest and I do currently have a serial cable.
> 
> Short of figuring out how to virtualize a serial console from a ESXi
> guest is
> there any more information I can provide?

Someone else hit this.  Removing the contents of /usr/obj and rebuilding
fixed it for him.  Apparently, some of the objects didn't get rebuilt,
as needed.

Eric
___
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: The futur of the roff toolchain

[Eric van Gyzen]

I like all of this.  Thanks for your very thorough research and effort.

Eric


On 05/21/2017 07:57, Baptiste Daroussin wrote:
> Hi all,
>
> I have been working for a while to try to import a modern roff toolchain into
> base.
>
> I didn't like the initial approach that consisted in simply removing all roff
> toolchain in base.
>
> Recap of the situation in base:
> * We have GNU roff version 1.19.2 in base (latest GPLv2 version). Lots of bug
>   fixes has been made upstream in newer version (GPLv3) in particular 
> regarding
>   unicode but not only. (and we cannot update it anymore)
> * GNU roff is now only used to generate the documentation in share/doc and as 
> a
>   fallback for manpages which mandoc does not support.
>
> On the manpages front:
> * No manpages in base are not supported by mandoc except groff manpages
>   themselves
> * man(1) can fallback on ports version of groff if installed (for ports not
>   providing manpages not compatible with mandoc)
>
> Alternatives to GNU roff:
> * Heirloom doctools (which I tried to import) licensed both CDDL/BSD (in C)
> * neartoff http://litcave.rudi.ir/ BSD licensed (in C)
>
> I went the road of using heirloom doctools it is 90% compatible with GNU roff,
> good enough for all our base roff based documents.
>
> After getting down that road for a while, including lots of patches sent
> upstream (thanks them for being so reactive and integrating them quickly as 
> well
> as fixing the issues I wasn't able to fix myself quickly).
>
> The problem is there are lot of corner small corner cases where heirloom is
> different from GNU roff and hard to make it compatible. While this is corner
> cases, it breaks document generation for some large documents people are
> writing. Those users could use (and actually would benefit a lot from it) GNU
> roff from the ports tree, but have to be careful about the path of the tool 
> they
> call to ensure only calling the one from GNU roff and not the one (with the 
> same
> name) from heirloom doctools.
>
> Concerning neatroff it is barely compatible with GNU roff, so not an option
> (last I tested at least).
>
> I would like to change this approach and get back to the initial approach 
> taken
> by others before I jumped in and I would like just entirely remove the roff
> toolchain from base and let people rely on GNU roff from ports.
>
> man(1) is already asking the user to install groff from ports if the manpage
> cannot be read with mandoc.
>
> No the problem left is documentations available in share/doc.
>
> I would like to push them elsewhere. Those documents are mostly useful for
> historical reason (hence we want to keep them) but not really for daily use of
> modern FreeBSD.
> Another issue with those documentation, they are installed as text/ascii 
> version
> in base, which makes most of them not really readable (as the documents has 
> not
> be written for a ascii/text target but more for a PDF/html view - using pic(1)
> for example)
>
> A plan was to push as sources in the svn doc repository and continue to build
> them. This approach also have an issue: over the time roff evolved a bit and
> while working on heirloom doctools import I had to fix a bunch of markup to 
> make
> the rendering of those documents clean (also meaning almost noone should read
> them considering some were not really readable).
>
> What I want to propose now, it to render them as PDF (html?) once and push 
> them
> somewhere (to be defined) as static document on our documentation website.
> Please doceng@ provide me a location where to push them.
>
> And then remove bsd.doc.mk from FreeBSD 12.0 along with the removal of groff.
> I also want to remove most of roff related tools (the one provided by 
> toolchains
> available in ports) for which we kept a BSD version (not really maintained in
> base):
> namely:
> - checknr
> - vgrind
> - colcrt
>
> Only keeping:
> - col (useful in other places than roff)
> - soelim (also used for manpages and we have a clean BSD licensed version 
> which
>   is also now parts of mandoc)
>
> Best regards,
> Bapt

___
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: more default uid/gid for NFS in mountd

[Eric van Gyzen]

On 05/08/2017 06:45, Rick Macklem wrote:
> Hi,
> 
> Five years ago (yea, it slipped through a crack;-), Slawa reported that files
> created by root would end up owned by uid 2**32-2 (-2 as uint32_t).
> This happens if there is no "-maproot=" in the /etc/exports line.
> 
> The cause is obvious. The value is set to -2 by default.
> 
> The question is... Should this be changed to 65534 (ie "nobody")?
> - It would seem more consistent to make it the uid of nobody, but I can also 
> see
>   the argument that since it has been like this *forever*, that changing it 
> would be
>   a POLA violation.
> What do others think?

Since the change is easily communicated in the release notes, I think it seems
quite reasonable, especially if you limit it to 12.0.

> It is also the case that mountd.c doesn't look "nobody" up in the password 
> database
> to set the default. It would be nice to do this, but it could result in the 
> mountd daemon
> getting "stuck" during a boot waiting for an unresponsive LDAP service or 
> similar.
> Does doing this sound like a good idea?

I imagine the lookup could be useful in heterogeneous networks.

You might consider adding a CLI flag to mountd to let the admin choose the user
by UID/GID, and possibly by username/groupname.  That would be a reasonable
workaround for networks that often hit the lookup problem.

Eric
___
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: PCI slot and function number for ARI enabled devices

[Eric van Gyzen]

On 03/14/2017 01:37, Mu Lichao wrote:

Hi,

I am trying to enable Intel 82599 10GbE SR-IOV VFs on FreeBSD 12-CURRENT, and 
after enabled, the SR-IOV VFs can be seen by pciconf(1), but can not be seen by 
lspci(1), which is installed from ports/sysutils/pciutils:
# pciconf -l | tail -2
ixv0@pci0:1:0:128:  class=0x02 card=0x002a1fc1 chip=0x10ed8086 rev=0x01 
hdr=0x00
ixv1@pci0:1:0:130:  class=0x02 card=0x002a1fc1 chip=0x10ed8086 rev=0x01 
hdr=0x00

# lspci | grep 82599
01:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ 
Network Connection (rev 01)
01:00.1 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ 
Network Connection (rev 01)

After some debugging, I found that it is because of ARI. After ARI is enabled, 
the slot number is always 0 and the function number can be range between 0 and 
255 when reading from /dev/pci, and this breaks lspci(1).

Is it a behavior by design or not?


It is by design.  See section 6.13 of the PCIe specification.  I imagine lspci 
will need to be fixed.


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

[Eric van Gyzen]

On 03/04/2017 11:44, Oleksandr Tymoshenko wrote:

Adrian Chadd (adrian.ch...@gmail.com) wrote:

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.


cem@ posted this patch:

http://dpaste.com/1K2W05E

If someone can test it, I'll gladly commit it.  The real-time clock will 
likely be wrong, but it won't panic with INVARIANTS.


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

[Eric van Gyzen]

On 02/28/2017 16:57, Conrad Meyer wrote:

On Tue, Feb 28, 2017 at 2:31 PM, Eric van Gyzen <vangy...@freebsd.org> wrote:

Your system's real-time clock is returning garbage.  r312702 added some
input validation a few weeks ago.  Previously, the kernel was reading beyond
the end of an array and either complaining about the clock or setting it to
the wrong time based on whatever was in the memory beyond the array.

The added validation shouldn't be an assertion because it operates on data
beyond the kernel's control.  Try this:

--- sys/libkern.h   (revision 314424)
+++ sys/libkern.h   (working copy)
@@ -57,8 +57,10 @@
 bcd2bin(int bcd)
 {

-   KASSERT(bcd >= 0 && bcd < LIBKERN_LEN_BCD2BIN,
-   ("invalid bcd %d", bcd));
+   if (bcd < 0 || bcd >= LIBKERN_LEN_BCD2BIN) {
+   printf("invalid bcd %d\n", bcd);
+   return (0);
+   }
return (bcd2bin_data[bcd]);
 }


I don't think removing this assertion and truncating to zero is the
right thing to do.  Adding an error return to this routine is a little
much, though.  I think probably the caller should perform input
validation between the broken device and this routine.


Either of those would be a much better solution.  This was just a quick 
hack to get the memstick to boot.


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

[Eric van Gyzen]

On 02/28/2017 15:47, Michael Gmelin wrote:

Booting r313561[0] I get the following panic:

mountroot: waiting for device /dev/ufs/FreeBSD_install
panic: invalid bcd 177 (also 254, 255 etc.)
cpuid = 1
KDB: stack backtrace:
db_trace_self_wrapper...
vpanic()...
kassert_panic()...
atrtc_gettime()...
inittodr()...
vfs_mountroot()...
start_init()...
fork_exit()...
fork_trampoline()...
(copied from a screenshot, hence the ellipsis)

This is on an Acer C720 Chromebook, confirmed on two devices (one with
cyapa touchpad, one with elan touchpad). Same problem happened with a
CURRENT checked out about 10 hours ago. Previous versions of 12-CURRENT
worked ok (last version I tested personally was back in
November/December though).


Your system's real-time clock is returning garbage.  r312702 added some 
input validation a few weeks ago.  Previously, the kernel was reading 
beyond the end of an array and either complaining about the clock or 
setting it to the wrong time based on whatever was in the memory beyond 
the array.


The added validation shouldn't be an assertion because it operates on 
data beyond the kernel's control.  Try this:


--- sys/libkern.h   (revision 314424)
+++ sys/libkern.h   (working copy)
@@ -57,8 +57,10 @@
 bcd2bin(int bcd)
 {

-   KASSERT(bcd >= 0 && bcd < LIBKERN_LEN_BCD2BIN,
-   ("invalid bcd %d", bcd));
+   if (bcd < 0 || bcd >= LIBKERN_LEN_BCD2BIN) {
+   printf("invalid bcd %d\n", bcd);
+   return (0);
+   }
return (bcd2bin_data[bcd]);
 }

Eric
___
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: Log spam: Limiting * response from 1 to 200 packets/sec

[Eric van Gyzen]

On 12/13/2016 09:24, Michael Butler wrote:
> Any hints as to why all of my -current equipment is complaining like below. Is
> there a sysctl to moderate/turn this off?
> 
> Dec 13 10:00:01 archive kernel: Limiting icmp unreach response from 1 to 200
> packets/sec
> Dec 13 10:00:21 archive last message repeated 13 times
> Dec 13 10:02:21 archive last message repeated 18 times
> Dec 13 10:06:21 archive last message repeated 36 times
> Dec 13 10:07:11 archive kernel: Limiting icmp ping response from 1 to 200
> packets/sec
> Dec 13 10:07:55 archive kernel: Limiting icmp unreach response from 1 to 200
> packets/sec
> Dec 13 10:08:21 archive last message repeated 17 times
> Dec 13 10:08:37 archive kernel: Limiting closed port RST response from 4 to 
> 200
> packets/sec
> Dec 13 10:09:55 archive kernel: Limiting icmp unreach response from 1 to 200
> packets/sec
> Dec 13 10:10:21 archive last message repeated 17 times
> Dec 13 10:12:21 archive last message repeated 18 times
> Dec 13 10:12:28 archive kernel: Limiting icmp ping response from 1 to 200
> packets/sec
> Dec 13 10:13:55 archive kernel: Limiting icmp unreach response from 1 to 200
> packets/sec

What Subversion revision are you running?  Did this start happening after a
recent update?  I ask because r309745 was committed a few days ago and might
have changed the behavior.

Eric
___
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: Import rcorder-visualize.sh from NetBSD?

[Eric van Gyzen]

On 12/05/2016 15:13, Brooks Davis wrote:
> On Mon, Dec 05, 2016 at 01:16:49PM -0600, Eric van Gyzen wrote:
>> Would anyone object to me importing this script from NetBSD?
>>
>> http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/sbin/rcorder/rcorder-visualize.sh?rev=1.5=text/plain
>>
>> I ask in particular because of the non-BSD license.  This seems like a
>> no-brainer, but I'm going to play it safe and ask first.
> 
> It seems pointless as something in the base system given that it
> required graphviz.

If it had been in the base system last week, I would have found it
instead of wasting my time reinventing it.  I suppose the same could be
said of the ports tree, but src/sbin/rcorder is a good first place to look.

> Having it in the source tree seems mostly fine, but
> Joerg should really put a proper license on it.

I agree.  In fact, I just asked him to apply a 2-clause BSD license, and
he agreed.

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

Import rcorder-visualize.sh from NetBSD?

[Eric van Gyzen]

Would anyone object to me importing this script from NetBSD?

http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/sbin/rcorder/rcorder-visualize.sh?rev=1.5=text/plain

I ask in particular because of the non-BSD license.  This seems like a
no-brainer, but I'm going to play it safe and ask first.

Eric
___
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: copyinstr and ENAMETOOLONG

[Eric van Gyzen]

On 11/02/2016 15:33, Jilles Tjoelker wrote:
> On Wed, Nov 02, 2016 at 02:24:43PM -0500, Eric van Gyzen wrote:
>> Does copyinstr guarantee that it has filled the output buffer when it
>> returns ENAMETOOLONG?  I usually try to answer my own questions, but I
>> don't speak many dialects of assembly.  :)
> 
> The few I checked appear to work by checking the length while copying,
> but the man page copy(9) does not guarantee that, and similar code in
> sys/compat/linux/linux_misc.c linux_prctl() LINUX_PR_SET_NAME performs a
> copyin() if copyinstr() fails with [ENAMETOOLONG].

Thanks.

> In implementing copyinstr(), checking the length first may make sense
> for economy of code: a user-strnlen() using an algorithm like
> lib/libc/string/strlen.c and a copyin() connected together with a C
> copyinstr(). This would probably be faster than the current amd64 code
> (which uses lods and stos, meh). With that implementation, filling the
> buffer in the [ENAMETOOLONG] case requires a small piece of additional
> code.
> 
>> I ask because I'd like to make the following change, and I'd like to
>> know whether I should zero the buffer before calling copyinstr to ensure
>> that I don't set the thread's name to the garbage that was on the stack.
> 
>> Index: kern_thr.c
>> ===
>> --- kern_thr.c   (revision 308217)
>> +++ kern_thr.c   (working copy)
>> @@ -580,8 +580,13 @@ sys_thr_set_name(struct thread *td, struct thr_set
>>  if (uap->name != NULL) {
>>  error = copyinstr(uap->name, name, sizeof(name),
>>  NULL);
>> -if (error)
>> -return (error);
>> +if (error) {
>> +if (error == ENAMETOOLONG) {
>> +name[sizeof(name) - 1] = '\0';
>> +} else {
>> +return (error);
>> +}
>> +}
>>  }
>>  p = td->td_proc;
>>  ttd = tdfind((lwpid_t)uap->id, p->p_pid);
> 
> For API design, it makes more sense to set error = 0 if a truncated name
> is being set anyway. This preserves the property that the name remains
> unchanged if the call fails.

That makes sense.

> A change to the man page thr_set_name(2) is needed in any case.

Of course.

Would you like to review the following?

Index: lib/libc/sys/thr_set_name.2
===
--- lib/libc/sys/thr_set_name.2 (revision 309300)
+++ lib/libc/sys/thr_set_name.2 (working copy)
@@ -28,7 +28,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd June 1, 2016
+.Dd December 2, 2016
 .Dt THR_SET_NAME 2
 .Os
 .Sh NAME
@@ -43,37 +43,34 @@
 .Sh DESCRIPTION
 The
 .Fn thr_set_name
-sets the user-visible name for the kernel thread with the identifier
+system call sets the user-visible name for the thread with the identifier
 .Va id
-in the current process, to the NUL-terminated string
+in the current process to the NUL-terminated string
 .Va name .
+The name will be silently truncated to fit into a buffer of
+.Dv MAXCOMLEN + 1
+bytes.
 The thread name can be seen in the output of the
 .Xr ps 1
 and
 .Xr top 1
 commands, in the kernel debuggers and kernel tracing facility outputs,
-also in userland debuggers and program core files, as notes.
+and in userland debuggers and program core files, as notes.
 .Sh RETURN VALUES
 If successful,
 .Fn thr_set_name
-will return zero, otherwise \-1 is returned, and
+returns zero; otherwise, \-1 is returned, and
 .Va errno
 is set to indicate the error.
 .Sh ERRORS
 The
 .Fn thr_set_name
-operation may return the following errors:
+system call may return the following errors:
 .Bl -tag -width Er
 .It Bq Er EFAULT
 The memory pointed to by the
 .Fa name
 argument is not valid.
-.It Bq Er ENAMETOOLONG
-The string pointed to by the
-.Fa name
-argument exceeds
-.Dv MAXCOMLEN + 1
-bytes in length.
 .It Bq Er ESRCH
 The thread with the identifier
 .Fa id
@@ -92,6 +89,6 @@ does not exist in the current process.
 .Xr ktr 9
 .Sh STANDARDS
 The
-.Fn thr_new
-system call is non-standard and is used by
+.Fn thr_set_name
+system call is non-standard and is used by the
 .Lb libthr .
Index: share/man/man3/pthread_set_name_np.3
===
--- share/man/man3/pthread_set_name_np.3(revision 309300)
+++ share/man/man3/pthread_set_name_np.3(working copy)
@@ -24,7 +24,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd February 13, 2003
+.Dd December 2, 2016
 .Dt PTHREAD_SET_NAME_NP 3
 .Os
 .Sh NAME
@@ -39,14 +39,15 @@
 .Sh DESCRIPTION
 The
 .Fn pthread_set_name_np
-function sets internal name for thread specified by
-.Fa tid
-argument to string valu

Re: Some locale data are broken

[Eric van Gyzen]

On 11/18/2016 02:35, Jean-Sébastien Pédron wrote:
> On 17.11.2016 23:33, Eric van Gyzen wrote:
>> $ LANG=fr_FR.UTF-8 locale -k thousands_sep
>> thousands_sep=" "
>>
>> lrwxr-xr-x  1 root  wheel  25 Nov  2 13:41
>> /usr/share/locale/fr_FR.UTF-8/LC_NUMERIC -> ../uk_UA.UTF-8/LC_NUMERIC
>>
>> $ cat /usr/share/locale/uk_UA.UTF-8/LC_NUMERIC
>> ,
>>  
>> 3
>>
>> I'm not sure what Ukraine uses for a thousands separator, but this is
>> definitely wrong for France.
> 
> Hi!
> 
> What do you find broken exactly?
> 
> In fr_FR (I don't know for other french-speaking countries), numbers are
> formatted like this:
> 12 345,67
> 
> Where the English equivalent would be:
> 12,345.67
> 
> Thus, this fr_FR LC_NUMERIC looks correct to me:
> decimal_point=","
> thousands_sep=" "
> grouping=3

Oh!  I had thought France used '.' as a thousands separator.  Thanks for
correcting me, Jean-Sébastien.  Now I'm /certain/ that the libc++ unit tests are
wrong, since they think France uses a ','.  :)

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

Some locale data are broken

[Eric van Gyzen]

Some locale data seem to be broken on stable/11 and head (r308418 and
r308217, respectively).

$ LANG=fr_FR.UTF-8 locale -k thousands_sep
thousands_sep=" "

$ ll /usr/share/locale/fr_FR*/LC_NUMERIC
lrwxr-xr-x  1 root  wheel  29 Nov  2 13:41
/usr/share/locale/fr_FR.ISO8859-1/LC_NUMERIC ->
../uk_UA.ISO8859-5/LC_NUMERIC
lrwxr-xr-x  1 root  wheel  29 Nov  2 13:41
/usr/share/locale/fr_FR.ISO8859-15/LC_NUMERIC ->
../uk_UA.ISO8859-5/LC_NUMERIC
lrwxr-xr-x  1 root  wheel  25 Nov  2 13:41
/usr/share/locale/fr_FR.UTF-8/LC_NUMERIC -> ../uk_UA.UTF-8/LC_NUMERIC

$ cat /usr/share/locale/uk_UA.UTF-8/LC_NUMERIC
,
 
3

I'm not sure what Ukraine uses for a thousands separator, but this is
definitely wrong for France.

Eric

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

copyinstr and ENAMETOOLONG

[Eric van Gyzen]

Does copyinstr guarantee that it has filled the output buffer when it
returns ENAMETOOLONG?  I usually try to answer my own questions, but I
don't speak many dialects of assembly.  :)

I ask because I'd like to make the following change, and I'd like to
know whether I should zero the buffer before calling copyinstr to ensure
that I don't set the thread's name to the garbage that was on the stack.

Eric

Index: kern_thr.c
===
--- kern_thr.c  (revision 308217)
+++ kern_thr.c  (working copy)
@@ -580,8 +580,13 @@ sys_thr_set_name(struct thread *td, struct thr_set
if (uap->name != NULL) {
error = copyinstr(uap->name, name, sizeof(name),
NULL);
-   if (error)
-   return (error);
+   if (error) {
+   if (error == ENAMETOOLONG) {
+   name[sizeof(name) - 1] = '\0';
+   } else {
+   return (error);
+   }
+   }
}
p = td->td_proc;
ttd = tdfind((lwpid_t)uap->id, p->p_pid);
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

make universe fails with MAKEOBJDIRPREFIX

[Eric van Gyzen]

"make universe" consistently fails in buildworld when I set MAKEOBJDIRPREFIX.
I'm running head r306046 on amd64 and building head r306380.  There are only
comments in /etc/make.conf.  My complete command is:

make universe JFLAG=-j16 MAKEOBJDIRPREFIX=/work/universe \
> /usr/obj/build-logs/universe.log 2>&1  init_keytry.h
--- lib/libpam/libpam__L ---
cc -isystem /work/universe/mips.mips/usr/src/tmp/usr/include -L/work/universe/mi
ps.mips/usr/src/tmp/usr/lib -B/work/universe/mips.mips/usr/src/tmp/usr/lib --sys
root=/work/universe/mips.mips/usr/src/tmp -B/work/universe/mips.mips/usr/src/tmp
/usr/bin -fpic -DPIC -g -O -pipe -I/usr/src/lib/libpam/libpam/../../../contrib/o
penpam/include -DLIB_MAJ=6 -DHAVE_DLFUNC=1 -DHAVE_FDLOPEN=1 -DHAVE_FPURGE=1 -DHA
VE_STRLCAT=1 -DHAVE_STRLCPY=1 -G0   -DOPENPAM_DEBUG -MD  -MF.depend.openpam_strl
cpy.pico -MTopenpam_strlcpy.pico -std=iso9899:1999 -Wsystem-headers -Werror -Wal
l -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototy
pes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow
-Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wre
dundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/src/lib/libpa
m/libpam/../../../contrib/openpam/lib/libpam/openpam_strlcpy.c -o openpam_strlcp
y.pico
--- lib/libthr__L ---
--- thr_detach.o ---
--- lib/ncurses/ncurses__L ---
sh: ./make_keys: Exec format error
*** [init_keytry.h] Error code 126

make[5]: stopped in /usr/src/lib/ncurses/ncurses
--- lib/libthr__L ---
cc -isystem /work/universe/mips.mips/usr/src/tmp/usr/include -L/work/universe/mi
ps.mips/usr/src/tmp/usr/lib -B/work/universe/mips.mips/usr/src/tmp/usr/lib --sys
root=/work/universe/mips.mips/usr/src/tmp -B/work/universe/mips.mips/usr/src/tmp
/usr/bin  -O -pipe -G0   -DPTHREAD_KERNEL -I/usr/src/lib/libthr/../libc/include
-I/usr/src/lib/libthr/thread  -I/usr/src/lib/libthr/../../include -I/usr/src/lib
/libthr/arch/mips/include -I/usr/src/lib/libthr/sys -I/usr/src/lib/libthr/../../
libexec/rtld-elf -I/usr/src/lib/libthr/../../libexec/rtld-elf/mips -I/usr/src/li
b/libthr/../libthread_db -Winline -fexceptions -D_PTHREAD_FORCED_UNWIND -D_PTHRE
ADS_INVARIANTS -MD  -MF.depend.thr_detach.o -MTthr_detach.o -std=gnu99 -Wsystem-
headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototyp
es -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign
 -c /usr/src/lib/libthr/thread/thr_detach.c -o thr_detach.o
--- lib/ncurses/ncurses__L ---
1 error

make[5]: stopped in /usr/src/lib/ncurses/ncurses
*** [lib/ncurses/ncurses__L] Error code 2
==
___
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: make universe and /etc/src.conf

[Eric van Gyzen]

On 08/22/2016 17:15, Poul-Henning Kamp wrote:
> 
> In message <ad2f7a3b-21c5-2e2a-2f1b-0625a70e0...@freebsd.org>, Eric van Gyzen 
> w
> rites:
>> I just tried a "make universe", and all the kernels failed because they 
>> couldn't
>> find the config files.  I had forgotten that I have this in /etc/src.conf:
>>
>>  KERNCONF=NUMA
>>  KERNCONFDIR=/etc
>>
>> Since "make universe" is primarily used for build-testing changes in src,
>> shouldn't it ignore /etc/src.conf (and possibly /etc/src-env.conf), like the
>> following?  Or is "make universe" used for other purposes for which it really
>> should read /etc/src*.conf?
> 
> I frankly don't remember why universe ignores make.conf but not src.conf,
> but I do remeber it was a deliberate decision.

Okay, good to know.  Thanks for the input.

Eric
___
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: make universe and /etc/src.conf

[Eric van Gyzen]

On 08/22/2016 11:00, Ngie Cooper wrote:
> 
>> On Aug 22, 2016, at 08:24, Eric van Gyzen <vangy...@freebsd.org> wrote:
>> 
>> I just tried a "make universe", and all the kernels failed because they
>> couldn't find the config files.  I had forgotten that I have this in
>> /etc/src.conf:
>> 
>> KERNCONF=NUMA KERNCONFDIR=/etc
> 
> Alternatively, use KERNCONF?= and KERNCONFDIR?=..
> 
> A conditional will be needed to deal with MODULES_OVERRIDE, but it's
> trivial.. I'll dig up my old src.conf a bit later on today if needed. It's
> how I dealt with that caveat before I switched to GENERIC*.

Thanks for the suggestion.  Moving these to /etc/make.conf seems easiest, so
I'll just do that.

Eric
___
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: make universe and /etc/src.conf

[Eric van Gyzen]

On 08/22/2016 10:47, Bryan Drewery wrote:
> On 8/22/2016 8:27 AM, Glen Barber wrote:
>> On Mon, Aug 22, 2016 at 10:24:25AM -0500, Eric van Gyzen wrote:
>>> I just tried a "make universe", and all the kernels failed because they 
>>> couldn't
>>> find the config files.  I had forgotten that I have this in /etc/src.conf:
>>>
>>> KERNCONF=NUMA
>>> KERNCONFDIR=/etc
>>>
>>> Since "make universe" is primarily used for build-testing changes in src,
>>> shouldn't it ignore /etc/src.conf (and possibly /etc/src-env.conf), like the
>>> following?  Or is "make universe" used for other purposes for which it 
>>> really
>>> should read /etc/src*.conf?
> 
> I disagree. Universe has read src.conf for a long time, and not
> make.conf which is more system-specific.  Perhaps you should move your
> KERNCONF* to make.conf.

I'm okay with that.  Thanks for the help.

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

make universe and /etc/src.conf

[Eric van Gyzen]

I just tried a "make universe", and all the kernels failed because they couldn't
find the config files.  I had forgotten that I have this in /etc/src.conf:

KERNCONF=NUMA
KERNCONFDIR=/etc

Since "make universe" is primarily used for build-testing changes in src,
shouldn't it ignore /etc/src.conf (and possibly /etc/src-env.conf), like the
following?  Or is "make universe" used for other purposes for which it really
should read /etc/src*.conf?

--- Makefile(revision 304226)
+++ Makefile(working copy)
@@ -479,6 +479,7 @@
 universe_${target}_${target_arch}: universe_${target}_prologue .MAKE .PHONY
@echo ">> ${target}.${target_arch} ${UNIVERSE_TARGET} started on 
`LC_ALL=C date`"
@(cd ${.CURDIR} && env __MAKE_CONF=/dev/null \
+   SRCCONF=/dev/null SRC_ENV_CONF=/dev/null \
${SUB_MAKE} ${JFLAG} ${UNIVERSE_TARGET} \
TARGET=${target} \
TARGET_ARCH=${target_arch} \

Thanks,

Eric
___
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: seldom crashes on Dell E6330 with 12-CURRENT

[Eric van Gyzen]

On 07/23/16 02:21 AM, Matthias Apitz wrote:
> 
> Hello,
> 
> I own since July 15 a new laptop and faced 3 crashes, details see below.
> What can I do to gather more information? Thanks
> 
> 
> notes in general:
> - hardware: Dell E6330, amd64, 4 cores i5-3360M, 8 GByte RAM, 250 GByte SSD 
> w/ TRIM
> - WLAN: urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R
> - kernel: GENERIC r302904 (July 15)
> - poudriere 3.2-pre: compiling ~1800 ports in 4 builders
> - swap as plain file in /usr/swap01, 8 GByte
> - apart of the crashes below, no crash during buildworld, buildkernel and
>   ~48 hours of poudriere fetching distfiles and making ~1800 ports
> - no errors on 'memtest 1G'
> 
> crashes/observations:
> 
> 16.07.2016 07:12 
> - on shutdown swap device (plain file in /usr) could not be detached
> - drop to kdb
> - nothing in /var/log/messages
> 
> 17.07.2016 19:41
> - hard locked, had to power-off
> - last command issued on console (no X11): cp -p * /usr/PKGDIR (around 1700 
> files, 2 GByte)
> - nothing in /var/log/messages
> 
> 20.07.2016 19:27
> - hard locked, had to power-off
> - last command issued in xterm: fgrep mra... ~/*
> - nothing in /var/log/messages

What file system are you using?

Do a full fsck (or zfs scrub).

Try moving swap to a raw (freebsd-swap) partition so that you might get
a kernel core dump.  That will be the essential next step.

Without more details from a core dump or debugger, your best option is
to try a release or an older build.  If that works, try to find the
commit that introduced the behavior.  This will be very tedious and
time-consuming for your scenario, so definitely try getting a core dump
first.

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

Re: Setting sysctl vfs.zfs.arc_max failed: 22

[Eric van Gyzen]

On 07/06/16 03:35 PM, Steven Hartland wrote:
> The ARC settings and kmem aren't initialised when tunables are loaded
> so the tests fail.
>
> I've fixed this locally by blindly setting if ARC is not configured.
> Request to commit the fix is with re@
>
> In the mean time the patch is attached.
>
> Thanks for the report and sorry about the breakage.

No worries.  Thanks for the quick fix.

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

Setting sysctl vfs.zfs.arc_max failed: 22

[Eric van Gyzen]

Steven and -current:

I just updated to r302350 with a GENERIC kernel config.  I see this in
dmesg:

VT(efifb): resolution 1024x768
Setting sysctl vfs.zfs.arc_max failed: 22
CPU: Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz (3491.98-MHz K8-class
CPU)

The relevant parts of /boot/loader.conf are:

zfs_load="YES"
vfs.zfs.arc_max="6442450944"

Let me know what other information you need.

Cheers,

Eric

___
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: Date formatting with en_US locale

[Eric van Gyzen]

On 06/18/16 04:10 AM, Hajimu UMEMOTO wrote:
> Does the attached patch fix your issue?
> Though there are many locales it should be fixed, I've included only
> en_US one, in this time.

Yes, it fixes my issue with en_US.  Thank you, Umemoto-san.

Eric
___
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: Date formatting with en_US locale

[Eric van Gyzen]

On 05/26/16 10:15 AM, Baptiste Daroussin wrote:
> On Thu, May 26, 2016 at 11:55:08AM -0300, Otacílio wrote:
>> Em 26/05/2016 11:49, Baptiste Daroussin escreveu:
>>> On Thu, May 26, 2016 at 09:44:25AM -0500, Eric van Gyzen wrote:
>>>> Baptiste and -current,
>>>>
>>>> I noticed two annoyances with date formatting on head, and I wonder how
>>>> we can fix them.
>>>>
>>>> I have these settings:
>>>>
>>>>  LC_ALL=en_US.ISO8859-1
>>>>  LANG=en_US.ISO8859-1
>>>>
>>>> First, Thunderbird displays the date as, for example:
>>>>
>>>>  03/ 6/16 ...
>>>>
>>>> The leading space on the day (6) looks weird.  I might even say it's
>>>> simply wrong.  Zero-padding would better.  (/No/ padding would be best,
>>>> but I don't think strftime supports that.)
>>>>
>>>> Second, date(1) no longer shows the day-of-week:
>>>>
>>>>  $ date
>>>>  March 26, 2016 at 09:21:55 AM CDT
>>>>
>>>> For many years, I have been typing "date" to see the day-of-week (and
>>>> other things).  I like the new human-friendly format, but I miss the
>>>> day-of-week.
>>>>
>>>> Of course, I can fix these locally, but I wonder how we can fix them for
>>>> everyone.  I see that the formats come from CLDR.  I also see that ume@
>>>> restored the day-of-week for ja_JP in r292512.  Is this the best
>>>> approach, or should we try to get them changed upstream (CLDR)?
>>>>
>>>> Thanks for your input,
>>> I can hack cldr2def.pl to readd the week of day as it was before for 11.0 
>>> still
>>> the best approach is to push the change upstream.
>>>
>>> I will have a look at the cldr2def.pl hack this week end.
>>>
>>> Best regards,
>>> Bapt
>> LANG=pt_BR.UTF-8
>>
>> MM_CHARSET=UTF-8
>>
> By adding the hack I mean to do it for all locales not cherry picking

Thank you for fixing this!

Above, I mentioned two issues.  The other one is, the date format for
en_US pads the month with a zero, but the day with a space.  So, June 7 is:

06/ 7/16

That looks weird.  It should pad both with zeros.  I'd be happy to fix
it, but I don't see how:  There isn't an "xformat" callback in the
cldr2def.pl script, and it's not clear how to add one.  If you can
explain, I'll do it.  If you can fix it, I'll be grateful.  ;)

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

Re: [CFT] ypldap testing against OpenLDAP and Microsoft Active Directory

[Eric van Gyzen]

On 06/ 9/16 05:49 PM, Matthew Seaman wrote:
> On 09/06/2016 18:34, Craig Rodrigues wrote:
>> There is still value to ypldap as it is now, and getting feedback from
>> users (especially Active Directory) would be very useful.
>> If someone could document a configuration which uses IPSEC or OpenSSH
>> forwarding, that would be nice.
>>
>> In future, maybe someone in OpenBSD or FreeBSD will implement things like
>> LDAP over SSL.
> What advantages does ypldap offer over nss-pam-ldapd (in ports) ?
> nss-pam-ldapd can use both ldap+STARTTLS or ldaps to encrypt data in
> transit, and I find it works very well for using OpenLDAP as a central
> account database.  I believe it works with AD, but haven't tried that
> myself.

nss-pam-ldapd works very well with Active Directory.  At work, dozens of
people use it on their workstations and hundreds of people use it on the
build servers.  We've been doing this for years with no issues.  Well,
we've caused some issues for ourselves, of course...  ;)

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

buildworld: /usr/bin/ar segfault

[Eric van Gyzen]

My buildworld just failed very early with a segfault from /usr/bin/ar:

--
>>> stage 1.1: legacy release compatibility shims
--
...
--- libegacy.a ---
building static egacy library
ar -crD libegacy.a `NM='nm' NMFLAGS='' lorder dummy.o  | tsort -q`
Segmentation fault (core dumped)
*** [libegacy.a] Error code 139


In __archive_write_allocate_filter(), a->filter_last was pointing to
archive_write_ar_header().  a->format_write_header should have pointed
to this function.  The offset between these two fields in struct archive
is 48 bytes.  Sure enough, that structure recently grew by 48 bytes.

This would seem to indicate that ar (or libarchive.a) was built with
mismatched objects.  Unfortunately, I don't have good records of what
build options and flags I used.  I /think/ I used either
-DWITH_SYSTEM_COMPILER or no options at all.  Well, I always use -j4. 
The "ar" that segfaulted seems to be /usr/bin/ar, so it's from r300692. 
Thanks to my list of Boot Environments (yay), I'm pretty sure I was
running r298525 when I built r300692 (and I was running r297692 when I
built r298525).  I installed r297692 from the snapshot memstick.img.

I recovered by restoring ar (and ranlib) from an old BE (yay again!). 
I'm reporting this in case there is a bug in the build and someone is
willing to go hunting for it based on this vague report.  :)

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

No debug info for statically linked stuff

[Eric van Gyzen]

I'm running head from Tuesday (r301045).  I just noticed that "ar" is
missing the debuginfo for libarchive:

$ /usr/local/bin/gdb /usr/bin/ar
GNU gdb (GDB) 7.11 [GDB v7.11 for FreeBSD]
[...]
Reading symbols from /usr/bin/ar...Reading symbols from
/usr/lib/debug//usr/bin/ar.debug...done.
done.
(gdb) ptype struct archive
No struct type named archive.
(gdb) p archive_write_open_filename
$1 = {} 0x406be0


Is this a known issue?

Has libarchive.a already been stripped when ar is linked?

Eric

___
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: [PATCH] microoptimize locking primitives by avoiding unnecessary atomic ops

[Eric van Gyzen]

On 05/27/16 02:17 PM, Mateusz Guzik wrote:
> Hello there,
>
> quite some time ago I posted a trivial patch to locking primitives. What
> they do is the inline part tries an atomic op and if that fails the
> actual function is called, which immediately tries the same op.
>
> The obvious optimisation checks for the availability of the lock first.
>
> There concerns about the way it was done previously by relying on
> volatile behaving in a specific way.
>
> Later a simplified version was posted which should not have the concern,
> but the thread died.
>
> I refer you to 
> https://lists.freebsd.org/pipermail/freebsd-current/2015-November/058100.html
> for simple benchmark results.
>
> I would like to get the patch in before 11 freeze.

This makes sense to me, and the patch looks good.

Please consider adding a comment to each location that explains why the
extra condition is tested before the atomic op.  Without such a comment,
I am concerned that your changes will be garbage collected later,
because the extra condition would seem superfluous to someone less
familiar with the code.

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

Date formatting with en_US locale

[Eric van Gyzen]

Baptiste and -current,

I noticed two annoyances with date formatting on head, and I wonder how
we can fix them.

I have these settings:

LC_ALL=en_US.ISO8859-1
LANG=en_US.ISO8859-1

First, Thunderbird displays the date as, for example:

03/ 6/16 ...

The leading space on the day (6) looks weird.  I might even say it's
simply wrong.  Zero-padding would better.  (/No/ padding would be best,
but I don't think strftime supports that.)

Second, date(1) no longer shows the day-of-week:

$ date
March 26, 2016 at 09:21:55 AM CDT

For many years, I have been typing "date" to see the day-of-week (and
other things).  I like the new human-friendly format, but I miss the
day-of-week.

Of course, I can fix these locally, but I wonder how we can fix them for
everyone.  I see that the formats come from CLDR.  I also see that ume@
restored the day-of-week for ja_JP in r292512.  Is this the best
approach, or should we try to get them changed upstream (CLDR)?

Thanks for your input,

Eric

___
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: Strange text on two computers with AMD processors

[Eric van Gyzen]

On 05/20/16 10:41 PM, Alex V. Petrov wrote:
> Strange text on two computers with AMD
> CPU: AMD FX-8370 Eight-Core Processor (4018.42-MHz K8-class CPU)
> and
> CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4600+ (2412.41-MHz
> K8-class CPU)
>
> Copyright (c) 1992-2016 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 11.0-CURRENT #6 r300310: Sat May 21 01:38:41 KRAT 2016
> alex@alex.super:/usr/obj/usr/src/sys/ALEX amd64
> FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on
> LLVM 3.8.0)
> can't re-use a leaf (ixl_rx_miss_bufs)!
>
> And PC with Athlon 4600+ dont't boot.
> Frezed on detect wireless keyboard.

The message is from sysctl.  It happens because two files try to declare
the same sysctl node:

./net/iflib.c:SYSCTL_INT(_dev_netmap, OID_AUTO, ixl_rx_miss_bufs,

./dev/netmap/if_ixl_netmap.h:SYSCTL_INT(_dev_netmap, OID_AUTO,
ixl_rx_miss_bufs,

I've copied the folks who are working in this area.

However, I don't think this is related to your boot failure.  I have no
idea about that.

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

Re: HEADS-UP: installworld on r299292 through r299317 will replace master.passwd, passwd, and group files

[Eric van Gyzen]

On 05/10/2016 01:25, Thomas Zander wrote:
> On 10 May 2016 at 08:18, O. Hartmann  wrote:
>
>> I haven't figured out so far how far this goes. Lucky for those having
>> recent /etc/ backups. A pity FreeBSD doens't backup this by default.
> After having shot myself in the foot some time ago, "zfs snapshot" has
> become a part of my standard upgrade procedures :-)

Similarly, "beadm create" has become a part of my standard upgrade
procedures.  If the new world is hosed, I just boot an old Boot Environment.

I'm grateful to all the people who made this possible.  I would call you
by name, but I would probably miss some people.

Making this part of installworld (or similar) would be interesting.

Eric

$ beadm list
BE  Active Mountpoint  Space Created
r295605 -  -9.2G 2016-03-12 14:07
r296766 -  -7.1G 2016-03-24 15:19
r297219 -  -  788.0M 2016-04-11 07:04
r297684 -  -  781.0M 2016-04-28 09:00
default NR /   50.9G 2016-05-04 20:19
r298743 -  -5.4G 2016-05-07 09:37
___
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 panic from recent build

[Eric van Gyzen]

I intend it as a workaround to be committed, not as debugging.

Eric

On 05/02/2016 18:51, Ryan Stone wrote:
> Do we need this debug output?  It's quite clear from the acpidump output
> that there is an entry for APIC ID 0 in memory domain 0 and memory
> domain 1.  Not sure if that's legal by the spec.
> 
> On Mon, May 2, 2016 at 6:17 PM, Eric van Gyzen <vangy...@freebsd.org
> <mailto:vangy...@freebsd.org>> wrote:
> 
> On 05/02/2016 16:14, Bill O'Hanlon wrote:
> > On Mon, May 2, 2016 at 3:55 PM, John Baldwin <j...@freebsd.org 
> <mailto:j...@freebsd.org>> wrote:
> >
> >> On Monday, May 02, 2016 01:35:54 PM Bill O'Hanlon wrote:
> >>> ​
> >>>  IMG_20160502_130335.jpg
> >>> <
> >> 
> https://drive.google.com/file/d/1dtJxTwWXfhXVUUtn1Vvpzh3laJt7AILyCg/view?usp=drive_web
> >>> ​
> >>> I'm getting the following panic from a recent (May 2, 2016) build.
> >>> panic: Duplicate local APIC ID 0
> >>>
> >>> The system is a Dell Precision T5500 with generic factory BIOS 
> settings.
> >>> It has run previous builds without event for several years.
> >>>
> >>> I'm attaching a link to a photo of the screen for added details.
> >> Try setting 'hint.srat.0.disabled=1' at the loader prompt and then grab
> >> the output of 'acpidump -t' on your next boot.  The SRAT table used by
> >> the NUMA code appears to be corrupted by your BIOS.
> >>
> >> --
> >> John Baldwin
> >>
> >
> > That allowed me to boot.  I'm attaching the output of 'acpidump -t'.
> > Thanks!
> 
> Bill,
> 
> Do you have the time and interest to test this patch?  If so, remove the
> line that you added to /boot/loader.conf so the patch actually gets
> exercised.
> 
> Eric
> 
> 
> diff --git a/sys/x86/acpica/srat.c b/sys/x86/acpica/srat.c
> index 85f1922..1d0f73d 100644
> --- a/sys/x86/acpica/srat.c
> +++ b/sys/x86/acpica/srat.c
> @@ -201,8 +201,12 @@ srat_parse_entry(ACPI_SUBTABLE_HEADER *entry, void
> *arg)
>  "enabled" : "disabled");
>  if (!(cpu->Flags & ACPI_SRAT_CPU_ENABLED))
>  break;
> -KASSERT(!cpus[cpu->ApicId].enabled,
> -("Duplicate local APIC ID %u", cpu->ApicId));
> +if (cpus[cpu->ApicId].enabled) {
> +printf("SRAT: Duplicate local APIC ID %u\n",
> +cpu->ApicId);
> +*(int *)arg = ENXIO;
> +break;
> +}
>  cpus[cpu->ApicId].domain = domain;
>  cpus[cpu->ApicId].enabled = 1;
>  break;
> 
> ___
> freebsd-current@freebsd.org <mailto: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
> <mailto: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 panic from recent build

[Eric van Gyzen]

On 05/02/2016 16:14, Bill O'Hanlon wrote:
> On Mon, May 2, 2016 at 3:55 PM, John Baldwin  wrote:
>
>> On Monday, May 02, 2016 01:35:54 PM Bill O'Hanlon wrote:
>>> ​
>>>  IMG_20160502_130335.jpg
>>> <
>> https://drive.google.com/file/d/1dtJxTwWXfhXVUUtn1Vvpzh3laJt7AILyCg/view?usp=drive_web
>>> ​
>>> I'm getting the following panic from a recent (May 2, 2016) build.
>>> panic: Duplicate local APIC ID 0
>>>
>>> The system is a Dell Precision T5500 with generic factory BIOS settings.
>>> It has run previous builds without event for several years.
>>>
>>> I'm attaching a link to a photo of the screen for added details.
>> Try setting 'hint.srat.0.disabled=1' at the loader prompt and then grab
>> the output of 'acpidump -t' on your next boot.  The SRAT table used by
>> the NUMA code appears to be corrupted by your BIOS.
>>
>> --
>> John Baldwin
>>
>
> That allowed me to boot.  I'm attaching the output of 'acpidump -t'.
> Thanks!

Bill,

Do you have the time and interest to test this patch?  If so, remove the
line that you added to /boot/loader.conf so the patch actually gets
exercised.

Eric


diff --git a/sys/x86/acpica/srat.c b/sys/x86/acpica/srat.c
index 85f1922..1d0f73d 100644
--- a/sys/x86/acpica/srat.c
+++ b/sys/x86/acpica/srat.c
@@ -201,8 +201,12 @@ srat_parse_entry(ACPI_SUBTABLE_HEADER *entry, void
*arg)
 "enabled" : "disabled");
 if (!(cpu->Flags & ACPI_SRAT_CPU_ENABLED))
 break;
-KASSERT(!cpus[cpu->ApicId].enabled,
-("Duplicate local APIC ID %u", cpu->ApicId));
+if (cpus[cpu->ApicId].enabled) {
+printf("SRAT: Duplicate local APIC ID %u\n",
+cpu->ApicId);
+*(int *)arg = ENXIO;
+break;
+}
 cpus[cpu->ApicId].domain = domain;
 cpus[cpu->ApicId].enabled = 1;
 break;

___
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: limits: setrlimit umtxp: Invalid argument

[Eric van Gyzen]

On 03/09/2016 09:49, Brendan Sechter wrote:
> I am running an 11.0-CURRENT VM.
> After recently updating, the following appears on startup and dhclient fails 
> to start.
>
> Starting dhclient.
> limits: setrlimit umtxp: Invalid argument
> /etc/rc.d/dhclient: WARNING: failed to start dhclient
>
> Similar messages appear for the following.
>
> devd pflog syslogd ntpd powerd sshd sendmail_submit sendmail_msp_queue cron
>
> Reverting to the previous kernel did not resolve the issue.
> I can manually start dhclient and ntp, but not sshd.
>
> I do not trust that my uname information is being updated with with build, 
> but here
> it is.
>
> $ uname -vm
> FreeBSD 11.0-CURRENT #0 r287598: Thu Sep 10 14:45:48 JST 2015 
> root@:/usr/obj/usr/src/sys/MIRAGE_KERNEL  amd64

This information comes directly from the running kernel, so it looks
like your kernel is not getting updated.  This seems consistent with the
above error messages, although I haven't tested this case.  The userland
tools are aware of the newly added umtxp limit, but the kernel is not aware.

Eric
___
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: EFI zfs loader and beadm?

[Eric van Gyzen]

On 03/09/2016 09:40, Andrey Fesenko wrote:
> Hello,
> I'm test EFI boot ZFSroot with BE, this not support now?
> svn 2965489
>
> If i build simplest system
> http://blog.multiplay.co.uk/2015/12/freebsd-10-2-release-efi-zfs-root-boot/
>
> # zfs get -r mountpoint efifpool
> NAME  PROPERTYVALUE  SOURCE
> efifpool  mountpoint  /mnt/efifpool  default
>
> =>  40  30712240  da0  GPT  (15G)
> 40  16001  efi  (800K)
>   1640  307106322  freebsd-zfs  (15G)
>   30712272 8   - free -  (4.0K)
>
> system boot nice
>
> If make BE env
>
> # zfs get -r mountpoint efiwpool
> NAME  PROPERTYVALUE  SOURCE
> efiwpool  mountpoint  none   local
> efiwpool/ROOT mountpoint  none
> inherited from efiwpool
> efiwpool/ROOT/initmountpoint  legacy local
> efiwpool/ROOT/init@init   mountpoint  -  -
> efiwpool/ROOT/init/boot   mountpoint  /media/bootlocal
> efiwpool/ROOT/init/tmpmountpoint  /media/tmp local
> efiwpool/ROOT/init/usrmountpoint  /media/usr local
> efiwpool/ROOT/init/usr@init   mountpoint  -  -
> efiwpool/ROOT/init/usr/home   mountpoint  /media/usr/home
> inherited from efiwpool/ROOT/init/usr
> efiwpool/ROOT/init/usr/home@init  mountpoint  -  -
> efiwpool/ROOT/init/varmountpoint  /media/var local
> efiwpool/ROOT/init/var@init   mountpoint  -  -
> efiwpool/ROOT/init/var/crash  mountpoint  /media/var/crash
> inherited from efiwpool/ROOT/init/var
> efiwpool/ROOT/init/var/db mountpoint  /media/var/db
> inherited from efiwpool/ROOT/init/var
> efiwpool/ROOT/init/var/db/pkg mountpoint  /media/var/db/pkg
> inherited from efiwpool/ROOT/init/var
> efiwpool/ROOT/init/var/empty  mountpoint  /media/var/empty
> inherited from efiwpool/ROOT/init/var
> efiwpool/ROOT/init/var/logmountpoint  /media/var/log
> inherited from efiwpool/ROOT/init/var
> efiwpool/ROOT/init/var/mail   mountpoint  /media/var/mail
> inherited from efiwpool/ROOT/init/var
> efiwpool/ROOT/init/var/runmountpoint  /media/var/run
> inherited from efiwpool/ROOT/init/var
> efiwpool/ROOT/init/var/tmpmountpoint  /media/var/tmp
> inherited from efiwpool/ROOT/init/var
>
> system not boot.
>
> Not found /boot/loader.efi (in BE system real path
> efiwpool/ROOT/init/boot/loader.efi) if copy this efiwpool/ROOT/init
> (blank in BE system) loader found this (but not found /boot/kernel) I
> can copy this and get a similar system
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192184#c15 (with out
> msdos kernel part), but this ruin BE update mechanism

Your dataset hierarchy is not what beadm expects.  Specifically, you
have /boot separate from /, which I imagine is causing your problem. 
/boot should be part of /.  Also, you have several file systems in the
BE that are usually not in it; I doubt this is part of your boot
failure, though.

For reference, here is my layout, which is mostly the same as the
default installation:

NAME  USED  AVAIL  REFER  MOUNTPOINT
zroot 117G   108G96K  none
zroot/ROOT   14.8G   108G96K  none
zroot/ROOT/10.2   444K   108G  6.35G  /
zroot/ROOT/103beta   14.8G   108G  8.75G  /
zroot/ROOT/103beta1 8K   108G  8.17G  /
zroot/ROOT/103beta3 8K   108G  8.75G  /
zroot/home   97.8G   108G  94.9G  /home
zroot/usr3.36G   108G96K  /usr
zroot/usr/ports   985M   108G   736M  /usr/ports
zroot/usr/src2.40G   108G  2.19G  /usr/src
zroot/var2.19M   108G96K  /var
zroot/var/audit96K   108G96K  /var/audit
zroot/var/crash96K   108G96K  /var/crash
zroot/var/log1.15M   108G   420K  /var/log
zroot/var/mail360K   108G   120K  /var/mail
zroot/var/tmp 416K   108G   144K  /var/tmp

Eric
___
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: continuous stream of writes?

[Eric van Gyzen]

On 03/01/2016 08:45, Michael Butler wrote:
> On 03/01/16 09:41, Eric van Gyzen wrote:
>> On 03/01/2016 08:22, Michael Butler wrote:
>>> On an otherwise idle machine, I now see a continuous stream of writes to
>>> disk. I've only noted this over the last couple of weeks but this will
>>> not be welcome behaviour on an SSD ..
>>>
>>> How do I find the source of these writes?
>>>
>>>
>>> imb@toshi:/home/imb> iostat 10
>>>ttyada0  cd0pass0 cpu
>>>  tin  tout  KB/t tps  MB/s   KB/t tps  MB/s   KB/t tps  MB/s  us ni sy in id
>>>0   992 58.53 229 13.10   0.00   0  0.00   0.37   0  0.00  13  2  7  1 78
>>>023 30.82  12  0.36   0.00   0  0.00   0.00   0  0.00   2  0  4  0 94
>>>0 8 31.38  12  0.37   0.00   0  0.00   0.00   0  0.00   0  0  4  0 96
>>>0 8 31.75  11  0.34   0.00   0  0.00   0.00   0  0.00   3  0  3  0 94
>>>0 8 31.82  11  0.35   0.00   0  0.00   0.00   0  0.00   1  0  3  0 96
>>>0 8 31.76  12  0.36   0.00   0  0.00   0.00   0  0.00   0  0  3  0 96
>>>0 8 31.75  11  0.35   0.00   0  0.00   0.00   0  0.00   1  0  4  0 95
>>>0 8 31.55  12  0.38   0.00   0  0.00   0.00   0  0.00   1  0  3  0 96
>>>
>>
>> The I/O mode of "top" might be useful:
>>
>> top -m io
> 
> Well that's different .. KDE konsole .. why on earth .. ?

Now try ktrace, fstat, and procstat.  See the man pages for usage.

Eric
___
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: continuous stream of writes?

[Eric van Gyzen]

On 03/01/2016 08:22, Michael Butler wrote:
> On an otherwise idle machine, I now see a continuous stream of writes to
> disk. I've only noted this over the last couple of weeks but this will
> not be welcome behaviour on an SSD ..
>
> How do I find the source of these writes?
>
>
> imb@toshi:/home/imb> iostat 10
>ttyada0  cd0pass0 cpu
>  tin  tout  KB/t tps  MB/s   KB/t tps  MB/s   KB/t tps  MB/s  us ni sy in id
>0   992 58.53 229 13.10   0.00   0  0.00   0.37   0  0.00  13  2  7  1 78
>023 30.82  12  0.36   0.00   0  0.00   0.00   0  0.00   2  0  4  0 94
>0 8 31.38  12  0.37   0.00   0  0.00   0.00   0  0.00   0  0  4  0 96
>0 8 31.75  11  0.34   0.00   0  0.00   0.00   0  0.00   3  0  3  0 94
>0 8 31.82  11  0.35   0.00   0  0.00   0.00   0  0.00   1  0  3  0 96
>0 8 31.76  12  0.36   0.00   0  0.00   0.00   0  0.00   0  0  3  0 96
>0 8 31.75  11  0.35   0.00   0  0.00   0.00   0  0.00   1  0  4  0 95
>0 8 31.55  12  0.38   0.00   0  0.00   0.00   0  0.00   1  0  3  0 96
>

The I/O mode of "top" might be useful:

top -m io

Eric
___
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: CVE-2015-7547: critical bug in libc

[Eric van Gyzen]

On 02/17/2016 08:19, Warren Block wrote:
> On Wed, 17 Feb 2016, Kurt Jaeger wrote:
>
>> A short note on the www.freebsd.org website would probably be helpful,
>> as this case will produce a lot of noise.
>
> Maybe a short article like we did for leap seconds?
> https://www.freebsd.org/doc/en_US.ISO8859-1/articles/leap-seconds/article.html
>

Articles are permanent, which makes sense for the recurring issue of
leap seconds.  This vulnerability is transient, so I would suggest a
news item.

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

/etc/periodic/weekly/320.whatis: /usr/libexec/makewhatis.local: not found

[Eric van Gyzen]

I just set up a workstation running head.  The weekly 320.whatis script always
reports:

/usr/libexec/makewhatis.local: not found

Indeed, it doesn't exist.  Does the 320.whatis script need to be updated for
r283777?

Cheers,

Eric
___
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 memory leak with x11/nvidia-driver

[Eric van Gyzen]

On 02/ 4/16 08:05 PM, Mark Johnston wrote:

On Thu, Feb 04, 2016 at 05:37:24PM -0600, Eric van Gyzen wrote:

On 02/ 3/16 10:54 AM, Eric van Gyzen wrote:

I just set up a new desktop running head with x11/nvidia-driver.  I've
discovered a memory leak where pages disappear from the queues, never to
return.  Specifically, the total of
  v_active_count
  v_inactive_count
  v_wire_count
  v_cache_count
  v_free_count
drops, eventually becoming /much/ less than v_page_count.  After leaving
xscreensaver running overnight, cycling the saver every 10 minutes, the
system was unusable, because it only had a few MB of memory.  (It has 8
GB physical.)

In case anyone is curious, /usr/local/bin/xscreensaver-hacks/glmatrix
triggers a fairly fast leak--around 600 pages per second.

I'm able to repro this on my workstation. With DTrace I can see that
glmatrix is allocating pages for an SG object at roughly the rate
they're being leaked. I took a look at r292373 (based on the history of
sg_pager.c) and noticed a vm_page_free() call was lost when
sg_pager_getpages() was simplified.

The patch below seems to do the trick for me. Could you give it a try
and confirm that it fixes the problem? I run current+nvidia-driver on
multiple workstations but hadn't observed a leak until now, so maybe
there's something additional going on in your case. Then again, I just
use i3lock. :)

diff --git a/sys/vm/sg_pager.c b/sys/vm/sg_pager.c
index 84bfa49..2cccb7ea 100644
--- a/sys/vm/sg_pager.c
+++ b/sys/vm/sg_pager.c
@@ -189,6 +189,9 @@ sg_pager_getpages(vm_object_t object, vm_page_t *m, int 
count, int *rbehind,
VM_OBJECT_WLOCK(object);
TAILQ_INSERT_TAIL(>un_pager.sgp.sgp_pglist, page, plinks.q);
vm_page_replace_checked(page, object, offset, m[0]);
+   vm_page_lock(m[0]);
+   vm_page_free(m[0]);
+   vm_page_unlock(m[0]);
m[0] = page;
page->valid = VM_PAGE_BITS_ALL;
  


Your patch fixes the leak completely.  Nice work, Mark!

I didn't notice the leak until I unknowingly left the screensaver 
cycling all overnight.  In my normal workflow, I open the windows I need 
and pretty much leave them there.  This doesn't seem to trigger the 
leak, at least not at a noticeable rate.


Thanks for your help!

Eric
___
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 memory leak with x11/nvidia-driver

[Eric van Gyzen]

On 02/ 3/16 10:54 AM, Eric van Gyzen wrote:

I just set up a new desktop running head with x11/nvidia-driver.  I've
discovered a memory leak where pages disappear from the queues, never to
return.  Specifically, the total of
 v_active_count
 v_inactive_count
 v_wire_count
 v_cache_count
 v_free_count
drops, eventually becoming /much/ less than v_page_count.  After leaving
xscreensaver running overnight, cycling the saver every 10 minutes, the
system was unusable, because it only had a few MB of memory.  (It has 8
GB physical.)


In case anyone is curious, /usr/local/bin/xscreensaver-hacks/glmatrix 
triggers a fairly fast leak--around 600 pages per second.


Eric
___
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 memory leak with x11/nvidia-driver

[Eric van Gyzen]

I just set up a new desktop running head with x11/nvidia-driver.  I've
discovered a memory leak where pages disappear from the queues, never to
return.  Specifically, the total of
v_active_count
v_inactive_count
v_wire_count
v_cache_count
v_free_count
drops, eventually becoming /much/ less than v_page_count.  After leaving
xscreensaver running overnight, cycling the saver every 10 minutes, the
system was unusable, because it only had a few MB of memory.  (It has 8
GB physical.)

I see this on head from a few days ago.  I do /not/ see it on stable/10
from a few days ago.

Just starting and stopping Xorg eats pages.  Starting and stopping X
apps also eats pages, some more than others.  Some screensavers ate a
lot more memory than others.  This is why I suspect the nvidia driver is
the trigger.  I rebuilt the x11/nvidia-driver port, but that didn't help.

I would love to bisect to find the offending commit, but that would take
a /lot/ of time, partly because I don't have a lower bound other than
the stable/10 branch point (since this is a new installation).

Does anyone know of any specific commits that could be suspicious? 
There have been several big changes in VM (e.g. more NUMA support, cache
page elimination).  Do any of those changes seem more likely?  I'll take
even a hunch at this point.  :)  Are there other areas I should look at?

Is anyone running an older revision of head with the nvidia driver and
doesn't see this problem?  That would narrow the range for bisection.

I should mention that I'm running with D3162* in my tree for NIC
support, but there is no relationship between the leak and network
activity, and I don't see the leak on stable/10+D3162.

Thanks in advance,

Eric

* https://reviews.freebsd.org/D3162
___
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 memory leak with x11/nvidia-driver

[Eric van Gyzen]

On 02/03/2016 10:54, Eric van Gyzen wrote:
> I just set up a new desktop running head with x11/nvidia-driver.  I've
> discovered a memory leak where pages disappear from the queues, never to
> return.  Specifically, the total of
> v_active_count
> v_inactive_count
> v_wire_count
> v_cache_count
> v_free_count
> drops, eventually becoming /much/ less than v_page_count.

Here is a script to log the data:

#!/bin/sh

readonly QUEUES="active inactive wire cache free total"
readonly FORMAT="%s\t%s\t%s\t%s\t%s\t%s\n"

vm_page_counts() {
for queue in $QUEUES; do
if [ "$queue" != "total" ]; then
sysctl -n vm.stats.vm.v_${queue}_count
fi
done
}

sum() {
s=0
while [ $# -gt 0 ]; do
s=$((s + $1))
shift
done
echo $s
}

print_counts() {
counts="`vm_page_counts`"
printf "$FORMAT" $counts `sum $counts`
}

printf "$FORMAT" $QUEUES
print_counts
while sleep 60; do
print_counts
done

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

Hot-Plug PCIe Support

[Eric van Gyzen]

FreeBSD Folks:

I am currently scoping the effort to add hot-plug PCIe support to
FreeBSD.  Is anyone else currently working on this or aware of any
design, code, or other effort available outside the tree?

FYI, here are perhaps the most interesting references I could find:

https://wiki.freebsd.org/PCIHotplug

https://wiki.freebsd.org/IdeasPage#Implementing_PCI-Hotplug_and_ExpressCard_support

https://lists.freebsd.org/pipermail/freebsd-current/2015-April/055290.html

https://lists.freebsd.org/pipermail/freebsd-ia32/2010-February/date.html

Please reply on freebsd-hack...@freebsd.org to minimize cross-posting.

Thanks in advance.

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

Re: [HEADSUP] OpenSSL updated to 1.0.2d

[Eric van Gyzen]

On 10/31/15 5:25 AM, O. Hartmann wrote:

Am Fri, 30 Oct 2015 16:57:45 -0400
Jung-uk Kim  schrieb:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

OpenSSL on head has been updated to 1.0.2d.  Please make sure to
recompile all binaries depending on libcrypto.so.7 or libssl.so.7.


That is good news.

Could you provide, please, some hints how one could check all installed ports 
for the
usage of those specific libraries? Or could you provide a hint towards an 
existing port
already providing those tools? It would be great for those "from the set of 
ordinary
people" using FreeBSD.

I ask for that because I recall that there were a couple of ports which 
explicitely asks
for a selection of what SSL lib should be used and in my case, I use the base 
system's
one.


I expect there's a port, but I'm not aware of one.

This should work:

find /usr/local/*bin /usr/local/lib* -type f | \
while read F; do \
objdump -x $F 2>&1 | grep -Eq 'NEEDED  *lib(crypto|ssl).so.7' && \
echo $F; \
done

This is in /bin/sh (or bash).  You could change "echo" to "pkg which"
to show the package names.

Cheers,

Eric
___
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: r288951: ifconfig -alias, arp not removed

[Eric van Gyzen]

On 10/29/2015 16:56, Bryan Drewery wrote:
> On 10/29/2015 9:46 AM, Bryan Drewery wrote:
>> On 10/29/15 9:42 AM, Eric van Gyzen wrote:
>>> On 10/29/2015 11:25, Bryan Drewery wrote:
>>>> # ifconfig
>>>> igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>>>>
>>>> options=403bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,VLAN_HWTSO>
>>>> ether c8:0a:a9:04:39:78
>>>> inet 10.10.0.7 netmask 0x broadcast 10.10.255.255
>>>> inet 10.10.7.2 netmask 0x broadcast 10.10.255.255
>>>> inet 10.10.0.9 netmask 0x broadcast 10.10.255.255
>>>> nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
>>>> media: Ethernet autoselect (1000baseT )
>>>> status: active
>>>>
>>>> # ifconfig igb0 inet 10.10.0.9 -alias
>>>> # arp -an|grep 10.10.0.9
>>>> ? (10.10.0.9) at c8:0a:a9:04:39:78 on igb0 permanent [ethernet]
>>>> # arp -d 10.10.0.9
>>>> arp: writing to routing socket: Operation not permitted
>>>>
>>>> I swear this is not normal. I'm on an older build as well, r288951.
>>>
>>> That definitely looks abnormal.  See what "route get" says.  I think
>>> that's the error you get when there is a route for that address.
>>>
>>
>> # netstat -rn|grep 10.10.0.9
>> # route get 10.10.0.9
>>route to: lapbox
>> destination: 10.10.0.0
>>mask: 255.255.0.0
>> fib: 0
>>   interface: igb0
>>   flags: <UP,DONE,PINNED>
>>  recvpipe  sendpipe  ssthresh  rtt,msecmtuweightexpire
>>0 0 0 0  1500 1 0
>> # route get 5.5.5.5
>>route to: 5.5.5.5
>> destination: default
>>mask: default
>> gateway: router.asus.com
>> fib: 0
>>   interface: igb0
>>   flags: <UP,GATEWAY,DONE,STATIC>
>>  recvpipe  sendpipe  ssthresh  rtt,msecmtuweightexpire
>>0 0 0 0  1500 1 0
>>
>> For more context, this current system had 10.10.0.9 added to it. I
>> started up a VM which also started using 10.10.0.9 and managed to "win"
>> on the local network for owning it. (I don't know arp and this stuff
>> well). I then came to this system to remove the alias and the arp entry
>> to allow me to connect from it and have gotten into this situation.
>>
> 
> Just saw this in dmesg, which is what I described:
> 
> arp: 08:00:27:12:c1:a5 is using my IP address 10.10.0.9 on igb0!
> arp: 08:00:27:12:c1:a5 is using my IP address 10.10.0.9 on igb0!
> arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
> on igb0
> arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
> on igb0
> arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
> on igb0
> arp: 08:00:27:12:c1:a5 attempts to modify permanent entry for 10.10.0.9
> on igb0

The kernel should have removed the arp entry when you removed the alias.
 I just played with this on r289837 (one week old), and I could not
reproduce the failure.  In particular, r289501 sounds interesting, even
though your interface is up.

Eric
___
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: r288951: ifconfig -alias, arp not removed

[Eric van Gyzen]

On 10/29/2015 11:25, Bryan Drewery wrote:
> # ifconfig
> igb0: flags=8843 metric 0 mtu 1500
> 
> options=403bb
> ether c8:0a:a9:04:39:78
> inet 10.10.0.7 netmask 0x broadcast 10.10.255.255
> inet 10.10.7.2 netmask 0x broadcast 10.10.255.255
> inet 10.10.0.9 netmask 0x broadcast 10.10.255.255
> nd6 options=23
> media: Ethernet autoselect (1000baseT )
> status: active
> 
> # ifconfig igb0 inet 10.10.0.9 -alias
> # arp -an|grep 10.10.0.9
> ? (10.10.0.9) at c8:0a:a9:04:39:78 on igb0 permanent [ethernet]
> # arp -d 10.10.0.9
> arp: writing to routing socket: Operation not permitted
> 
> I swear this is not normal. I'm on an older build as well, r288951.

That definitely looks abnormal.  See what "route get" says.  I think
that's the error you get when there is a route for that address.

Eric
___
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: 11-CURRENT build fail with base gcc

[Eric van Gyzen]

On 08/20/2015 14:21, Warner Losh wrote:
 
 On Aug 20, 2015, at 10:32 AM, Dimitry Andric d...@freebsd.org wrote:

 Ah, this should be replaced with the recently introduced CFLAGS_NO_SIMD
 variable, then?
 
 Perhaps. Didn’t know this was a thing. That could use useful many places, 
 though
 there were two clang specific args I needed to move, not just the one that’s 
 in this
 flag. Maybe things are over-specified?
 
 Not sure I like bsd.cpu.mk growing more name-space pollution, especially 
 stuff that
 isn’t documented somewhere (bsd.cpu.mk is included from sys.mk, which is 
 automaticallyed
 globally included).

I couldn't find any _good_ place for it, so I stuck it in the least bad place.  
I also didn't know where to document it.  I'll gladly move it and document it 
if someone can suggest good locations.

 All these hacks being stashed hither and yon are starting to get
 very hard to keep straight for someone who looks at this code every day, let 
 alone
 somebody who invested CFLAGS_NO_SIMD independently for their code and finds
 that breaks in an upgrade...
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: freebsd-head: suddenly NMI panics lead to ddb being unable to stop CPUs?

[Eric van Gyzen]

On 08/21/2015 10:30, Julian Elischer wrote:
 On 8/21/15 11:25 PM, Adrian Chadd wrote:
 Ah, cool. I'll give it a whirl.

 I'm a little worried about having all of the other cores spinning in
 this case (mostly thermal; the machines get VERY LOUD when the CPUs
 are spinning..)

 make each spin with the pause instruction.. and for N seconds (N being the 
 CPU ID) or something

The patch (at the link below) does use the pause instruction.  The CPU has to 
spin as long as any CPU is in the debugger.

 On 21 August 2015 at 08:19, Eric van Gyzen vangy...@freebsd.org wrote:
 I mentioned this to Adrian, but I'll mention here for everyone else's 
 benefit.

 Ryan is exactly right.  There was a thread a while ago, with a proposed 
 patch from Kostik:

 https://lists.freebsd.org/pipermail/freebsd-arch/2014-July/015584.html

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

Re: freebsd-head: suddenly NMI panics lead to ddb being unable to stop CPUs?

[Eric van Gyzen]

Spinning is probably the only safe option in NMI context, since the NMI could 
have arrived at literally any time in any context (e.g. holding a spin lock, 
interrupts disabled).  :-/

Eric

On 08/21/2015 10:25, Adrian Chadd wrote:
 Ah, cool. I'll give it a whirl.
 
 I'm a little worried about having all of the other cores spinning in
 this case (mostly thermal; the machines get VERY LOUD when the CPUs
 are spinning..)
 
 
 -a
 
 
 On 21 August 2015 at 08:19, Eric van Gyzen vangy...@freebsd.org wrote:
 I mentioned this to Adrian, but I'll mention here for everyone else's 
 benefit.

 Ryan is exactly right.  There was a thread a while ago, with a proposed 
 patch from Kostik:

 https://lists.freebsd.org/pipermail/freebsd-arch/2014-July/015584.html

 As I recall, Scott Long also ran into this a few months ago.

 It happens for any NMI:  entering the debugger, a PCI Parity or System 
 Error, a hardware watchdog timeout, and probably other sources I'm not 
 remembering.

 Eric

 On 08/21/2015 09:23, Ryan Stone wrote:
 I have seen similar behaviour before.  The problem is that every CPU
 receives an NMI concurrently.  As I recall, one of them gets some kind of
 pseudo-spinlock and tries to stop the other CPUs with an NMI.  However,
 because they are already in an NMI handler, they don't get the second NMI
 and don't stop properly.

 The case that I saw actually had to do with a panic triggered by an NMI,
 not entering the debugger, but I believe that both cases use
 stop_cpus_hard() under the hood and have a similar issue.

 (I also recall seeing the exact situation that you describe while
 originally developing SR-IOV on an alpha version of the Fortville hardware
 and firmware with a very buggy SR-IOV implementation.  I've never seen it
 on ixgbe before, although I haven't used SR-IOV there very much at all)


 On Thu, Aug 20, 2015 at 6:15 PM, Adrian Chadd adr...@freebsd.org wrote:

 Hi!

 This has started happening on -HEAD recently. No, I don't have any
 more details yet than recently.

 Whenever I get an NMI panic (and getting an NMI is a separate issue,
 sigh) I get a slew of failed to stop cpu messages, and all CPUs
 enter ddb. This is .. sub-optimal. Has anyone seen this? Does anyone
 have any ideas?


 -adrian

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

Re: freebsd-head: suddenly NMI panics lead to ddb being unable to stop CPUs?

[Eric van Gyzen]

I mentioned this to Adrian, but I'll mention here for everyone else's benefit.

Ryan is exactly right.  There was a thread a while ago, with a proposed patch 
from Kostik:

https://lists.freebsd.org/pipermail/freebsd-arch/2014-July/015584.html

As I recall, Scott Long also ran into this a few months ago.

It happens for any NMI:  entering the debugger, a PCI Parity or System Error, a 
hardware watchdog timeout, and probably other sources I'm not remembering.

Eric

On 08/21/2015 09:23, Ryan Stone wrote:
 I have seen similar behaviour before.  The problem is that every CPU
 receives an NMI concurrently.  As I recall, one of them gets some kind of
 pseudo-spinlock and tries to stop the other CPUs with an NMI.  However,
 because they are already in an NMI handler, they don't get the second NMI
 and don't stop properly.

 The case that I saw actually had to do with a panic triggered by an NMI,
 not entering the debugger, but I believe that both cases use
 stop_cpus_hard() under the hood and have a similar issue.

 (I also recall seeing the exact situation that you describe while
 originally developing SR-IOV on an alpha version of the Fortville hardware
 and firmware with a very buggy SR-IOV implementation.  I've never seen it
 on ixgbe before, although I haven't used SR-IOV there very much at all)


 On Thu, Aug 20, 2015 at 6:15 PM, Adrian Chadd adr...@freebsd.org wrote:

 Hi!

 This has started happening on -HEAD recently. No, I don't have any
 more details yet than recently.

 Whenever I get an NMI panic (and getting an NMI is a separate issue,
 sigh) I get a slew of failed to stop cpu messages, and all CPUs
 enter ddb. This is .. sub-optimal. Has anyone seen this? Does anyone
 have any ideas?


 -adrian

___
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: 11-CURRENT build fail with base gcc

[Eric van Gyzen]

On 08/20/2015 11:32, Dimitry Andric wrote:
 On 20 Aug 2015, at 18:24, Warner Losh i...@bsdimp.com wrote:

 I think you are wrong about the cause. -mno-avx is bogusly listed 
 unconditionally
 in efi/Makefile.inc. I’m working on a patch now…
 
 Ah, this should be replaced with the recently introduced CFLAGS_NO_SIMD
 variable, then?

Yes, probably so.

Eric
___
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: Segmentation fault running ntpd

[Eric van Gyzen]

WITH_DEBUG_FILES=1  (IIRC)

On 7/28/15 6:35 PM, Adrian Chadd wrote:

There's some way in stable/10 and -head to get it to install debug
symbols for things. Maybe it's only libraries, but you'll at least
want that in there so you can get stack traces through libc.



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



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

Re: panic: witness_warn head/amd64 @r285741 on 1 of 2 machines

[Eric van Gyzen]

On 07/21/2015 15:05, David Wolfskill wrote:
 On Tue, Jul 21, 2015 at 10:28:32PM +0300, Konstantin Belousov wrote:
 ...
 Indeed, thank you.
 ithread_loop() at ithread_loop+0xa6/frame 0xfe083b9c0a70
 fork_exit() at fork_exit+0x84/frame 0xfe083b9c0ab0
 fork_trampoline() at fork_trampoline+0xe/frame 0xfe083b9c0ab0
 --- trap 0, rip = 0, rsp = 0xfe083b9c0b70, rbp = 0 ---
 suspending ithread with the following locks held:
 shared rw udpinp (udpinp) r = 3 (0xf80010c7d7b0) locked @ 
 /usr/src/sys/netinet6/in6_pcb.c:1174
 panic: witness_warn
 cpuid = 3

 So it looks like net swi, leaking some udp6 lock.
 Curiouser and curiouser...  While I'm not taking any special pains to
 avoid building IPv6, I'm not actively actually doing anything with it
 (IPv6), either (for both the failing machine and my laptop).

 Once I'm back home, I should be able to poke around in ddb after
 re-creating the panic, if that would be a useful thing for me to do (and
 given some hints as to what to poke).

 Naturally, I'm also happy to change bits of sources, rebuild, and
 smoke-test.

 A quick check from the SVN update output only shows r285710, r285711, and
 r285740 in the range from (r285685,r285741] -- as the kernel running
 r285685 had no known issues -- that touched sys/netinet6/*.

It's a multicast destination.  Maybe something is using mDNS?

Randall, does the test on line 406 of udp6_usrreq.c need to be inverted?

Eric



signature.asc
Description: OpenPGP digital signature

Re: panic: witness_warn head/amd64 @r285741 on 1 of 2 machines

[Eric van Gyzen]

On 07/21/2015 15:21, Eric van Gyzen wrote:
 On 07/21/2015 15:05, David Wolfskill wrote:
 On Tue, Jul 21, 2015 at 10:28:32PM +0300, Konstantin Belousov wrote:
 ...
 Indeed, thank you.
 ithread_loop() at ithread_loop+0xa6/frame 0xfe083b9c0a70
 fork_exit() at fork_exit+0x84/frame 0xfe083b9c0ab0
 fork_trampoline() at fork_trampoline+0xe/frame 0xfe083b9c0ab0
 --- trap 0, rip = 0, rsp = 0xfe083b9c0b70, rbp = 0 ---
 suspending ithread with the following locks held:
 shared rw udpinp (udpinp) r = 3 (0xf80010c7d7b0) locked @ 
 /usr/src/sys/netinet6/in6_pcb.c:1174
 panic: witness_warn
 cpuid = 3

 So it looks like net swi, leaking some udp6 lock.
 Curiouser and curiouser...  While I'm not taking any special pains to
 avoid building IPv6, I'm not actively actually doing anything with it
 (IPv6), either (for both the failing machine and my laptop).

 Once I'm back home, I should be able to poke around in ddb after
 re-creating the panic, if that would be a useful thing for me to do (and
 given some hints as to what to poke).

 Naturally, I'm also happy to change bits of sources, rebuild, and
 smoke-test.

 A quick check from the SVN update output only shows r285710, r285711, and
 r285740 in the range from (r285685,r285741] -- as the kernel running
 r285685 had no known issues -- that touched sys/netinet6/*.
 It's a multicast destination.  Maybe something is using mDNS?

Blurf.  I wonder if it's a multicast destination.  (I need more chocolate.)

 Randall, does the test on line 406 of udp6_usrreq.c need to be inverted?

 Eric





signature.asc
Description: OpenPGP digital signature

Re: pedantic compiler warnings: double semicolons, function to data pointers

[Eric van Gyzen]

On 05/19/2015 14:42, Luigi Rizzo wrote:
 While trying to compile some of my (kernel) code in different environments,
 i noticed a couple of errors that perhaps might be worth fixing

 - extra semicolons. These come either from explicit repetitions in the code
   (see the output of a grep at the end of this message),
   or sometimes from the epansion of macros such as BITSET_DEFINE()


 - conversion between function and data pointers. One is in mbuf.h

   m-m_ext.ext_free = m-m_ext.ext_arg1 = m-m_ext.ext_arg2 = NULL;


 Shuold we care/bother to fix these as we step through them ?

I would say yes, since that would reduce the noise in the compiler warning 
output.  I realize the warning could be disabled, but cleaning up the ~50 
occurrences [of ;;] seems like the better way.

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

Re: SSE in libthr

[Eric van Gyzen]

Below is an updated patch to incorporate everyone's feedback so far.

I recognize all of the counter-arguments, and I agree with them in general.
Indeed, as applications use more SIMD, this kind of patch goes in the wrong
direction.  However, there are applications that do not use enough SSE to offset
the extra context-switch cost.  SSE does not provide a clear benefit in the
current libthr code with the current compiler, but it does provide a clear loss
in some cases.  Therefore, disabling SSE in libthr is a non-loss for most, and a
gain for some.

I refrained from disabling SSE in libc--as was suggested--because I can't make
the above argument for libc.  It provides such a variety of code that SSE might
be a net win in some cases.  I wish I had time to identify and benchmark the
interesting cases.

Thanks in advance for your further review and comments.

Eric



Index: head/lib/libthr/arch/amd64/Makefile.inc
===
--- head/lib/libthr/arch/amd64/Makefile.inc (revision 281473)
+++ head/lib/libthr/arch/amd64/Makefile.inc (working copy)
@@ -1,3 +1,9 @@
 #$FreeBSD$

 SRCS+= _umtx_op_err.S
+
+# With the current compiler and libthr code, using SSE in libthr
+# does not provide enough performance improvement to outweigh
+# the extra context switch cost.  This can measurably impact
+# performance when the application also does not use enough SSE.
+CFLAGS+=${CFLAGS_NO_SIMD}
Index: head/lib/libthr/arch/i386/Makefile.inc
===
--- head/lib/libthr/arch/i386/Makefile.inc  (revision 281473)
+++ head/lib/libthr/arch/i386/Makefile.inc  (working copy)
@@ -1,3 +1,9 @@
 # $FreeBSD$

 SRCS+= _umtx_op_err.S
+
+# With the current compiler and libthr code, using SSE in libthr
+# does not provide enough performance improvement to outweigh
+# the extra context switch cost.  This can measurably impact
+# performance when the application also does not use enough SSE.
+CFLAGS+=${CFLAGS_NO_SIMD}
Index: head/libexec/rtld-elf/amd64/Makefile.inc
===
--- head/libexec/rtld-elf/amd64/Makefile.inc(revision 281473)
+++ head/libexec/rtld-elf/amd64/Makefile.inc(working copy)
@@ -1,6 +1,6 @@
 # $FreeBSD$

-CFLAGS+=   -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float
+CFLAGS+=   ${CFLAGS_NO_SIMD} -msoft-float
 # Uncomment this to build the dynamic linker as an executable instead
 # of a shared library:
 #LDSCRIPT= ${.CURDIR}/${MACHINE_CPUARCH}/elf_rtld.x
Index: head/libexec/rtld-elf/i386/Makefile.inc
===
--- head/libexec/rtld-elf/i386/Makefile.inc (revision 281473)
+++ head/libexec/rtld-elf/i386/Makefile.inc (working copy)
@@ -1,6 +1,6 @@
 # $FreeBSD$

-CFLAGS+=   -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float
+CFLAGS+=   ${CFLAGS_NO_SIMD} -msoft-float
 # Uncomment this to build the dynamic linker as an executable instead
 # of a shared library:
 #LDSCRIPT= ${.CURDIR}/${MACHINE_CPUARCH}/elf_rtld.x
Index: head/share/mk/bsd.sys.mk
===
--- head/share/mk/bsd.sys.mk(revision 281473)
+++ head/share/mk/bsd.sys.mk(working copy)
@@ -153,6 +153,26 @@ SSP_CFLAGS?=   -fstack-protector
 CFLAGS+=   ${SSP_CFLAGS}
 .endif # SSP  !ARM  !MIPS

+#
+# Prohibit the compiler from emitting SIMD instructions.
+# These flags are added to CFLAGS in areas where the extra context-switch
+# cost outweighs the advantages of SIMD instructions.
+#
+# gcc:
+# Setting -mno-mmx implies -mno-3dnow
+# Setting -mno-sse implies -mno-sse2, -mno-sse3, -mno-ssse3 and -mfpmath=387
+#
+# clang:
+# Setting -mno-mmx implies -mno-3dnow and -mno-3dnowa
+# Setting -mno-sse implies -mno-sse2, -mno-sse3, -mno-ssse3, -mno-sse41 and
+# -mno-sse42
+# (-mfpmath= is not supported)
+#
+.if ${MACHINE_CPUARCH} == i386 || ${MACHINE_CPUARCH} == amd64
+CFLAGS_NO_SIMD.clang=  -mno-avx
+CFLAGS_NO_SIMD=-mno-mmx -mno-sse ${CFLAGS_NO_SIMD.${COMPILER_TYPE}}
+.endif
+
 # Allow user-specified additional warning flags, plus compiler specific flag
overrides.
 # Unless we've overriden this...
 .if ${MK_WARNS} != no
Index: head/sys/conf/kern.mk
===
--- head/sys/conf/kern.mk   (revision 281473)
+++ head/sys/conf/kern.mk   (working copy)
@@ -75,18 +75,10 @@ FORMAT_EXTENSIONS=  -fformat-extensions
 # operations inside the kernel itself.  These operations are exclusively
 # reserved for user applications.
 #
-# gcc:
-# Setting -mno-mmx implies -mno-3dnow
-# Setting -mno-sse implies -mno-sse2, -mno-sse3 and -mno-ssse3
-#
-# clang:
-# Setting -mno-mmx implies -mno-3dnow and -mno-3dnowa
-# Setting -mno-sse implies -mno-sse2, -mno-sse3, -mno-ssse3, -mno-sse41 and
-mno-sse42
-#
 .if ${MACHINE_CPUARCH} == i386
 CFLAGS.gcc+=   

Re: [RFC] Add GELI Passphrase: prompt to boot loader

[Eric van Gyzen]

On 04/06/2015 13:39, Devin Teske wrote:
 
 On Apr 6, 2015, at 10:24 AM, Eric van Gyzen e...@vangyzen.net wrote:

 On 04/06/2015 12:58, Devin Teske wrote:
 Hi -current,

 I have a pending enhancement to the boot loader that Colin P. and I
 have been working on together.

 URL: https://reviews.freebsd.org/D2105 https://reviews.freebsd.org/D2105

 The nature of the patch is to cause the boot loader to prompt for the
 GELI passphrase and then pass that on (through a kenv(1) variable)
 to Colin’s code in geom_eli.ko where it will be:

 (a) picked up for-use as the initial passphrase attempt(s)
 (b) zeroed after being picked-up so “kenv kern.geom.eli.passphrase”
 returns nothing

 NB: Actually, “kenv kern.geom.eli.passphrase” generates the error
 “kenv: unable to get kern.geom.eli.passphrase”

 The problem that I (we) need help in solving is:

 If the geom_eli.ko module doesn’t get loaded, then the variable
 (kern.geom.eli.passphrase) is not zeroed.

 While I do think that this is of minimal concern (not loading the GELI
 module means you won’t be able to get past the mountroot prompt in
 the case where GELI is required to boot), I discussed with Colin and
 I think we are in consensus that the resetting of the variable should
 perhaps be moved to another section of the kernel to prevent leakage
 of this sensitive information being passed through kenv(1) variable(s).

 Issue for me is, I’m not sure where the best place to move this to.
 Here’s the code that needs to be moved (Lines 108-109 of g_eli.c):

 https://svnweb.freebsd.org/base?view=revisionrevision=273489 
 https://svnweb.freebsd.org/base?view=revisionrevision=273489


 108 
 https://svnweb.freebsd.org/base/head/sys/geom/eli/g_eli.c?annotate=273489pathrev=273489#l108
   /* Wipe the passphrase from the environment. */
 109 
 https://svnweb.freebsd.org/base/head/sys/geom/eli/g_eli.c?annotate=273489pathrev=273489#l109
   kern_unsetenv(kern.geom.eli.passphrase);

 Need to move that preferably to some place in the kernel that is NOT
 optional in the compilation process. Suggestions?

 How about putting it right after a successful mount of the root file system? 
 (I've never used GELI, so this could be as right out as five.)

 
 I think that’s an excellent idea.
 
 /me rummages through source
 
 I’m thinking that the best place might be where we deal with the registered
 event handler for mountroot.
 
 
 One place that I crawled upon that looks particularly sexy is in start_init()
 of sys/kern/init_main.c:
 
 ### BEGIN SNIPPET ###
 /*
  * Start the initial user process; try exec’ing each pathname in init_path.
  * The program is invoked with one argument containing the boot flags.
  */
 static void
 start_init(void *dummy)
 {
   vm_offset_t addr;
   struct execve_args args;
   int options, error;
   char *var, *path, *next, *s;
   char *ucp, **uap, *arg0, *arg1;
   struct thread *td;
   struct proc *p;
 
   mtx_lock(Giant);
 
   GIANT_REQUIRED;
 
   td = furthered;
   p = td-td_proc;
 
   vfs_mountroot();
 
   ### RFC for code placement ###
   /* XXX Put reset of kern.geom.eli.passphrase here XXX */
   ##
 
   /*
* Need just enough stack to hold the faked-up “execve()” arguments.
*/
   // snip rest //
 ### END SNIPPET ###
 
 Or can you think of a better place?

That looks good to me, although I'm no expert in this area, so you might wait
for more opinions.

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

Re: [RFC] Add GELI Passphrase: prompt to boot loader

[Eric van Gyzen]

On 04/06/2015 12:58, Devin Teske wrote:
 Hi -current,

 I have a pending enhancement to the boot loader that Colin P. and I
 have been working on together.

 URL: https://reviews.freebsd.org/D2105 https://reviews.freebsd.org/D2105

 The nature of the patch is to cause the boot loader to prompt for the
 GELI passphrase and then pass that on (through a kenv(1) variable)
 to Colin’s code in geom_eli.ko where it will be:

 (a) picked up for-use as the initial passphrase attempt(s)
 (b) zeroed after being picked-up so “kenv kern.geom.eli.passphrase”
 returns nothing

 NB: Actually, “kenv kern.geom.eli.passphrase” generates the error
 “kenv: unable to get kern.geom.eli.passphrase”

 The problem that I (we) need help in solving is:

 If the geom_eli.ko module doesn’t get loaded, then the variable
 (kern.geom.eli.passphrase) is not zeroed.

 While I do think that this is of minimal concern (not loading the GELI
 module means you won’t be able to get past the mountroot prompt in
 the case where GELI is required to boot), I discussed with Colin and
 I think we are in consensus that the resetting of the variable should
 perhaps be moved to another section of the kernel to prevent leakage
 of this sensitive information being passed through kenv(1) variable(s).

 Issue for me is, I’m not sure where the best place to move this to.
 Here’s the code that needs to be moved (Lines 108-109 of g_eli.c):

 https://svnweb.freebsd.org/base?view=revisionrevision=273489 
 https://svnweb.freebsd.org/base?view=revisionrevision=273489


 108 
 https://svnweb.freebsd.org/base/head/sys/geom/eli/g_eli.c?annotate=273489pathrev=273489#l108
 /* Wipe the passphrase from the environment. */
 109 
 https://svnweb.freebsd.org/base/head/sys/geom/eli/g_eli.c?annotate=273489pathrev=273489#l109
 kern_unsetenv(kern.geom.eli.passphrase);

 Need to move that preferably to some place in the kernel that is NOT
 optional in the compilation process. Suggestions?

How about putting it right after a successful mount of the root file system? 
(I've never used GELI, so this could be as right out as five.)

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

Re: Early use of log() does not end up in kernel msg buffer

[Eric van Gyzen]

On 03/26/2015 23:20, Eric Badger wrote:
 Using log(9) when no process is reading the log results in the message
 going only to the console (contrast with printf(9), which goes to the
 console and to the kernel message buffer in this case). I believe it is
 truer to the semantics of logging for messages to *always* go to the
 message buffer (where they can eventually be collected and in fact put
 into a logfile). I therefore propose the attached patch, which sends
 log(9) to the message buffer always, and to the console only if no one
 has yet opened the log.

This makes sense to me.  Since I'm new here, I'll wait for others to
comment.

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