Re: clocked speed not showing in dev.cpu.[0-7].freq

[Ian Lepore]

On Tue, 2021-04-27 at 19:22 +0100, tech-lists wrote:
> Hi,
> 
> Not sure where to put this. system is amd64/stable/13. It's running
> powerd but with no additional flags.
> 
> CPU is Intel(R) Core(TM) i7-4770K CPU. Has 32GB RAM
> 
> The system is clocked in the bios at 4.251 GHz. I never see this
> value
> in sysctl dev.cpu.[0-7].freq though. Here's the output:
> 
> [...]
> sysctl dev.cpu.0
> dev.cpu.0.cx_method: C1/hlt
> dev.cpu.0.cx_usage_counters: 100878534
> dev.cpu.0.cx_usage: 100.00% last 185us
> dev.cpu.0.cx_lowest: C1
> dev.cpu.0.cx_supported: C1/1/0
> dev.cpu.0.freq_levels: 3400/84000 3200/77169 3100/73848 2900/67388
> 2700/61182 2500/55201 2400/52298 2200/46677 2000/41272 1800/36091
> 1700/34277 1500/29407 1300/24752 1100/20312 1000/18167 800/14031
> dev.cpu.0.freq: 3400
> dev.cpu.0.temperature: 68.0C
> dev.cpu.0.coretemp.throttle_log: 0
> dev.cpu.0.coretemp.tjmax: 100.0C
> dev.cpu.0.coretemp.resolution: 1
> dev.cpu.0.coretemp.delta: 32
> dev.cpu.0.%parent: acpi0
> dev.cpu.0.%pnpinfo: _HID=none _UID=0 _CID=none
> dev.cpu.0.%location: handle=\_PR_.CPU0
> dev.cpu.0.%driver: cpu
> dev.cpu.0.%desc: ACPI CPU
> 
> Here's the cpu string on boot:
> 
> CPU: Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz (4251.32-MHz K8-class
> CPU)
> 
> So, is it really clocked? or does the sysctl show what is right?
> 
> thanks,

The same is true on my system:

CPU: Intel(R) Xeon(R) CPU  W3680  @ 3.33GHz (4250.09-MHz K8-class CPU)

dev.cpu.0.freq_levels: 3334/143000 /13 3200/117000 3067/105000
2933/94000 2800/85000 2667/76000 2533/68000 2400/61000 2267/54000
2133/48000 2000/43000 1867/39000 1733/35000 1600/32000

I've clocked this cpu at various speeds between 4.25 - 5.0 ghz over the
years (faster when it was younger, more conservative now that it's
old).  The value in parens (4250.09) changes accordingly, but the
values in the sysctl never do.  I'm sure this is running at the
overclocked speed (various benchmark values change as they should when
changing the OC values in the bios).

-- Ian


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

Re: Deprecating base system ftpd?

[Ian Lepore]

On Sat, 2021-04-03 at 16:39 -0400, Ed Maste wrote:
> I propose deprecating the ftpd currently included in the base system
> before FreeBSD 14, and opened review D26447
> (https://reviews.freebsd.org/D26447) to add a notice to the man page.
> I had originally planned to try to do this before 13.0, but it
> dropped
> off my list. FTP is not nearly as relevant now as it once was, and it
> had a security vulnerability that secteam had to address.
> 
> I'm happy to make a port for it if anyone needs it. Comments?
> 

I would find the removal of ftpd to be very inconvenient unless there
was a port/pkg to install it from.

If there is a port, it would only be useful if I could set PREFIX=/usr
when building/installing it, so that its behavior when installed as a
port/pkg would be identical to how it was when it was part of base (in
terms of where its config files are located).

-- Ian

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

Re: Drastic slowdown for geli attach

[Ian Lepore]

On Wed, 2021-02-24 at 21:34 -0800, Kevin Oberman wrote:
> Sometime around the first week of this month (February) the time to
> do a
> geli attach on my 13.0-ALPHA3 amd64 system sharply increased. It
> started
> taking about 10 seconds. Prior to this, it took about 3-4 seconds. I
> have
> not seen any issues with the disc after it attaches, I am simply
> concerned
> that the longer time may be indicative of a deeper issue.
> 
> The system is a ThinkPad L15 with a CometLake i5-10210U and a Seagate
> ST2000LM007-1R8174 2T HDD.
> --
> Kevin Oberman, Part time kid herder and retired Network Engineer
> E-mail: rkober...@gmail.com
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "
> freebsd-stable-unsubscr...@freebsd.org"

In my experience, the thing that takes the most time in a geli attach
is the iterations of PKCS#5v2 it performs.  When you setup geli on a
partition it calculates how many iterations take about 2 seconds to
perform (unless you provide a specific value with the -i flag).

If you set up geli on a very fast machine then move the storage to a
slower machine, it may take much longer than 2 seconds.  (And if you
have 10 drives to attach, 2 seconds each becomes annoying, so I tend to
use -i with a small-ish number like 5000).

Or, in your case, maybe something has changed like it used to use aesni
accellerated instructions and now it doesn't for some reason, like
different default flags got used on the build, or something changed in
the crypto and/or driver framework.  That's the kind of thing I'd be
looking for.

-- Ian

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

Re: NTP, UTC, and (negative) leap seconds

[Ian Lepore]

On Thu, 2020-11-19 at 19:50 -0500, David Magda wrote:
> Hello,
> 
> So there was a recent weblog post on a timekeeping observation:
> 
>   https://fanf.dreamwidth.org/133823.html
>   https://news.ycombinator.com/item?id=251458700  (via)
>   https://en.wikipedia.org/wiki/Leap_second
> 
> In all circumstances in the past, leap seconds were added:
> 
>   23:59:57Z
>   23:59:58
>   23:59:59
>   23:59:60
>   00:00:00
>   00:00:01
> 
> The post brings up the possibility of a “negative” leap second, i.e.,
> a skip:
> 
>   23:59:57Z
>   23:59:58
>   00:00:00
>   00:00:01
> 
> Has anyone tested this scenario on FreeBSD?
> 
> Thanks for any info.
> 
> 

I run the freebsd kernel and ntpd through "negative" leap second events
usually a couple times a year as part of testing our timekeeping
products at $work.  I'm skeptical that we'll ever see a negative leap,
but we have some customers who insist on having it demonstrated to them
as working correctly.

The kernel and ntpd handle it just fine.  No telling what any given
application might do in reaction to a skipped second.  

I just did it now on one of our products.  I scheduled a negative leap
(from offset 37 to 36) to happen at the end of the day 2020-12-31, then
I used a debugging command to manually force the date/time on the unit
to 2020-12-31-23:58:00 and let it run.  In a terminal window I had a
bourne shell on that unit running 

  while true; do sleep 1; ntptime; echo; done

The output (trimmed to the range 23:59:55 - 00:00:10) looks like:

ntp_gettime() returns code 2 (DEL)
  time e398e47b.82ebd4d0  Thu, Dec 31 2020 23:59:55.511, (.511411404),
  maximum error 4000 us, estimated error 5 us, TAI offset 37
ntp_adjtime() returns code 2 (DEL)
  modes 0x0 (),
  offset 4.976 us, frequency 29.182 ppm, interval 128 s,
  maximum error 4000 us, estimated error 5 us,
  status 0x2121 (PLL,DEL,PPSSIGNAL,NANO),
  time constant 4, precision 0.001 us, tolerance 496 ppm,
  pps frequency 29.089 ppm, stability 0.128 ppm, jitter 0.937 us,
  intervals 23, jitter exceeded 6, stability exceeded 0, errors 2.

ntp_gettime() returns code 2 (DEL)
  time e398e47c.8d714b9c  Thu, Dec 31 2020 23:59:56.552, (.552510729),
  maximum error 4500 us, estimated error 5 us, TAI offset 37
ntp_adjtime() returns code 2 (DEL)
  modes 0x0 (),
  offset 4.957 us, frequency 29.182 ppm, interval 128 s,
  maximum error 4500 us, estimated error 5 us,
  status 0x2121 (PLL,DEL,PPSSIGNAL,NANO),
  time constant 4, precision 0.001 us, tolerance 496 ppm,
  pps frequency 29.089 ppm, stability 0.128 ppm, jitter 0.988 us,
  intervals 23, jitter exceeded 6, stability exceeded 0, errors 2.

ntp_gettime() returns code 2 (DEL)
  time e398e47d.92dbb5a0  Thu, Dec 31 2020 23:59:57.573, (.573665426),
  maximum error 5000 us, estimated error 5 us, TAI offset 37
ntp_adjtime() returns code 2 (DEL)
  modes 0x0 (),
  offset 4.937 us, frequency 29.182 ppm, interval 128 s,
  maximum error 5000 us, estimated error 5 us,
  status 0x2121 (PLL,DEL,PPSSIGNAL,NANO),
  time constant 4, precision 0.001 us, tolerance 496 ppm,
  pps frequency 29.089 ppm, stability 0.128 ppm, jitter 0.855 us,
  intervals 23, jitter exceeded 6, stability exceeded 0, errors 2.

ntp_gettime() returns code 2 (DEL)
  time e398e47e.9878316c  Thu, Dec 31 2020 23:59:58.595, (.595584418),
  maximum error 5500 us, estimated error 5 us, TAI offset 37
ntp_adjtime() returns code 2 (DEL)
  modes 0x0 (),
  offset 4.918 us, frequency 29.182 ppm, interval 128 s,
  maximum error 5500 us, estimated error 5 us,
  status 0x2121 (PLL,DEL,PPSSIGNAL,NANO),
  time constant 4, precision 0.001 us, tolerance 496 ppm,
  pps frequency 29.089 ppm, stability 0.128 ppm, jitter 1.006 us,
  intervals 23, jitter exceeded 6, stability exceeded 0, errors 2.

ntp_gettime() returns code 4 (WAIT)
  time e398e480.9dd6cf84  Fri, Jan  1 2021  0:00:00.616, (.616559624),
  maximum error 6000 us, estimated error 5 us, TAI offset 36
ntp_adjtime() returns code 4 (WAIT)
  modes 0x0 (),
  offset 4.899 us, frequency 29.182 ppm, interval 128 s,
  maximum error 6000 us, estimated error 5 us,
  status 0x2121 (PLL,DEL,PPSSIGNAL,NANO),
  time constant 4, precision 0.001 us, tolerance 496 ppm,
  pps frequency 29.089 ppm, stability 0.128 ppm, jitter 1.010 us,
  intervals 23, jitter exceeded 6, stability exceeded 0, errors 2.

ntp_gettime() returns code 4 (WAIT)
  time e398e481.a323571c  Fri, Jan  1 2021  0:00:01.637, (.637258156),
  maximum error 6500 us, estimated error 5 us, TAI offset 36
ntp_adjtime() returns code 4 (WAIT)
  modes 0x0 (),
  offset 4.880 us, frequency 29.182 ppm, interval 128 s,
  maximum error 6500 us, estimated error 5 us,
  status 0x2121 (PLL,DEL,PPSSIGNAL,NANO),
  time constant 4, precision 0.001 us, tolerance 496 ppm,
  pps frequency 29.089 ppm, stability 0.128 ppm, jitter 1.025 us,
  intervals 23, jitter exceeded 6, stability exceeded 0, errors 2.

ntp_gettime() returns code 4 (WAIT)
  time e398e482.a8977424  Fri, Jan  1 2021  0:00:02.658, 

Re: make kernel ignore broken SATA disk

[Ian Lepore]

On Sun, 2020-04-12 at 16:37 +0200, Stefan Bethke wrote:
> I have a server I don't have physical access to right now, which has
> a broken SATA disk that produces mostly errors (but not entirely).
> 
> The disk has two partitions that are part of a zpool each. I can't
> bring the system up with this disk being online, because ZFS is
> trying its darndest to use it.
> 
> I already renamed the GPT partitions in the hope that ZFS would not
> find them anymore, but it does.
> 
> I can't gpart destroy -f ada1 because "device busy".
> 
> Is there a way, ideally in the loader, to tell the kernel to ignore
> ada1 and/or ahcich5? Or can I force ZFS some other way to ignore the
> disk? I do have a spare disk I can use to replace the failed one, but
> I can't get the machine into a state where I could even issue the
> zpool replace command.
> 
> 

The the loader prompt (or in loader.conf without 'set'):

set hint.ada.1.disabled=1 

-- Ian


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

Re: ntp problems stratum 2 to 14?

[Ian Lepore]

On Fri, 2020-03-06 at 07:49 +1100, Dewayne Geraghty wrote:
> Ian,  Good points.  I did remove the fudge and 127.127.1.1 lines from the
> config with the same result as below.  Interestingly the clock at 10.0.7.6
> isn't really unreliable, as its been my time source since 2005, and serves
> clients, so it is pretty ok. Without a local clock, named fails (its linked
> with kerberos).  Yes I'd never seen my clock server become st 14, which
> prompted me to seek help. I haven't repeated that scenario, but I
> continuously get "interrupted system call" and I haven't been able to sync
> while running debug or ktrace - so I dont have "what good looks like".
> 
> Thanks Peter. I've rebuilt net/ntpd in various ways including all
> defaults.  Rebuilt the kernel (& world), to the latest 12 stable.
> Reset almost all sysctl's (I change 91 of them).  I keep getting
> interrupted system call at 1 sec intervals, which I suspect is a problem
> 
> For the reader: a stratum 2 clocks 10.0.7.6 syncs with some atomic clocks
> within city; a server 10.0.7.91 running ntpd 4.2.8p14 on FreeBSD 12.1
> r358565M irregularly and usually wont sync, and experiences "interrupted
> system calls".
> 
> The jump to stratum 14 was a surprise, but not repeatable.  Sometimes the
> ntpd port starts and uses the next hop time server, but usually within 20
> minutes returns to LOCL though more often goes straight to LOCL.  During
> ktrace's I've observed:
> 
>  66894 ntpd CALL  write(0x1,0x80078e000,0x2e)
>  66894 ntpd GIO   fd 1 wrote 46 bytes
>"select() returned -1: Interrupted system call
> ...
>"poll_update: at 1 10.0.7.6 poll 4 burst 0 retry 2 head 14 early 2
> next 16
>"
>  66894 ntpd RET   write 74/0x4a
>  66894 ntpd CALL  select(0x19,0x7fffde50,0,0,0)
>  66894 ntpd RET   select -1 errno 4 Interrupted system call
>  66894 ntpd PSIG  SIGALRM caught handler=0x80072f600 mask=0x0
> code=SI_KERNEL
>  66894 ntpd CALL  sigprocmask(SIG_SETMASK,0x7fffd7a4,0)
>  66894 ntpd RET   sigprocmask 0
>  66894 ntpd CALL  sigreturn(0x7fffd3d0)
>  66894 ntpd RET   sigreturn JUSTRETURN
>  66894 ntpd CALL  write(0x1,0x80078e000,0x2e)
>  66894 ntpd GIO   fd 1 wrote 46 bytes
>"select() returned -1: Interrupted system call
> ...
>"select() returned -1: Interrupted system call
>"
>  66894 ntpd RET   write 46/0x2e
>  66894 ntpd CALL  select(0x19,0x7fffde50,0,0,0)
>  66894 ntpd RET   select -1 errno 4 Interrupted system call
>  66894 ntpd PSIG  SIGALRM caught handler=0x80072f600 mask=0x0
> code=SI_KERNEL
>  66894 ntpd CALL  sigprocmask(SIG_SETMASK,0x7fffd7a4,0)
>  66894 ntpd RET   sigprocmask 0
>  66894 ntpd CALL  sigreturn(0x7fffd3d0)
>  66894 ntpd RET   sigreturn JUSTRETURN
>  66894 ntpd CALL  write(0x1,0x80078e000,0x2e)
>  66894 ntpd GIO   fd 1 wrote 46 bytes
>"select() returned -1: Interrupted system call
> but I have no idea whether or not these interrupted system calls are normal
> or not.
> 
> and with debug (-D5) this is what I see
> 
>  5 Mar 18:26:50 ntpd[86274]: select(): nfound=-1, error: Interrupted system
> call
> alarming: normal
>  5 Mar 18:26:51 ntpd[86274]: select(): nfound=-1, error: Interrupted system
> call
> poll_update: at 17 10.0.7.6 poll 4 burst 0 retry 0 head 0 early 2 next 16
> sendpkt(21, dst=10.0.7.6, src=10.0.7.91, ttl=0, len=72)
> peer_xmit: at 17 10.0.7.91->10.0.7.6 mode 3 keyid 232f len 72 index 0
> read_network_packet: fd=21 length 72 from 10.0.7.6
> fetch_timestamp: system bintime network time stamp: 1583393211.408612992
> restrictions: looking up 10.0.7.6
> match_restrict4_addr: Checking 127.0.0.1, port 123 ... doesn't match:
> ippeerlimit -4
> match_restrict4_addr: Checking 127.0.0.1, port 123 ... doesn't match:
> ippeerlimit -1
> match_restrict4_addr: Checking 10.0.7.91, port 123 ... doesn't match:
> ippeerlimit -4
> match_restrict4_addr: Checking 10.0.7.6, port 123 ... MATCH: ippeerlimit -1
> receive: at 17 10.0.7.91<-10.0.7.6 ippeerlimit -1 mode 4 iflags
> up,broadcast,multicast restrict nomodify,nopeer,noquery,notrap org
> 0xe20b283b.687ad7f6 xmt 0xe20b2838.2001aa5b
> MRU: interval 16 headway 8 limit 64
> receive: at 17 10.0.7.91<-10.0.7.6 mode 4/server:AM_PROCPKT keyid 232f
> len 72 auth 1 org 0xe20b283b.687ad7f6 xmt 0xe20b2838.2001aa5b MAC
> receive: MATCH_ASSOC dispatch: mode 4/server:AM_PROCPKT
> poll_update: at 17 10.0.7.6 poll 4 burst 0 retry 0 head 14 early 2 next 16
> clock_filter: n 2 off -3.283397 del 0.000382 dsp 3.937561 jit 0.000551
> alarming: normal
>  5 Mar 18:26:52 ntpd[86274]: select(): nfound=-1, error: Interrupted system
> call
> alarming: normal
>  5 Mar 18:26:53 ntpd[86274]: select(): nfound=-1, error: Interrupted system
> call
> alarming: normal
> 
> I have rebuild with ntp-4.2.8p14 and with no additional compile rules and
> the port's defaults. I keep getting
> 
>  6 Mar 07:05:16 ntpd[98682]: select(): nfound=-1, error: 

Re: ntp problems stratum 2 to 14?

[Ian Lepore]

On Wed, 2020-02-26 at 16:37 +1100, Dewayne Geraghty wrote:
> I usually run ntpd with both aslr and as user ntpd.  While testing I
> noticed that my server with a direct network cable to my main time keeper,
> jumped from the expected stratum 2 to 14 as follows (I record the date so I
> can synch with the debug log, also below):
> 
> vm.loadavg={ 0.09 0.10 0.18 }
> 
> Wed 26 Feb 2020 15:16:38 AEDT
>  remote   refid  st t when poll reach   delay   offset
>  jitter
> ==
>  10.0.7.6203.35.83.2422 u   44   64  3770.147  -227.12
>  33.560
> *127.127.1.1 .LOCL.  14 l   59  128  3770.0000.000
> 0.000
> Wed 26 Feb 2020 15:18:46 AEDT
>  remote   refid  st t when poll reach   delay   offset
>  jitter
> ==
>  10.0.7.6LOCAL(1)14 u   42   64  3770.147  -227.12
>  44.529
> *127.127.1.1 .LOCL.  14 l   59  128  3770.0000.000
> 0.000
> Wed 26 Feb 2020 15:20:54 AEDT
>  remote   refid  st t when poll reach   delay   offset
>  jitter
> ==
>  10.0.7.6LOCAL(1)14 u   42   64  3770.147  -227.12
>  73.969
> *127.127.1.1 .LOCL.  14 l   59  128  3770.0000.000
> 0.000
> Wed 26 Feb 2020 15:23:02 AEDT
>  remote   refid  st t when poll reach   delay   offset
>  jitter
> ==
> *10.0.7.6LOCAL(1)14 u   37   64  3770.164  -370.64
>  74.119
>  127.127.1.1 .LOCL.  14 l   59  128  3770.0000.000
> 0.000
> Time marches on
> Wed 26 Feb 2020 16:03:35 AEDT
>  remote   refid  st t when poll reach   delay   offset
>  jitter
> ==
> *10.0.7.6LOCAL(1)14 u   11   64  1770.133   -3.148
>  72.295
>  127.127.1.1 .LOCL.  14 l  406  128   100.0000.000
> 0.000
> Wed 26 Feb 2020 16:05:43 AEDT
>  remote   refid  st t when poll reach   delay   offset
>  jitter
> ==
> *10.0.7.6203.35.83.2422 u7   64  3770.164  -42.789
>  73.762
>  127.127.1.1 .LOCL.  14 l  534  128   200.0000.000
> 0.000
> 
> The debug for the above is:
> 26 Feb 14:58:33 ntpd[8772]: Command line: /usr/local/sbin/ntpd -c
> /etc/ntp.conf -g -g -u ntpd --nofork
> ...
> 26 Feb 14:58:34 ntpd[8772]: 10.0.7.6 e014 84 reachable
> 26 Feb 14:58:35 ntpd[8772]: LOCAL(1) 8014 84 reachable
> 26 Feb 15:03:40 ntpd[8772]: LOCAL(1) 901a 8a sys_peer <== bad
> 26 Feb 15:03:40 ntpd[8772]: 0.0.0.0 c515 05 clock_sync
> 26 Feb 15:22:25 ntpd[8772]: 10.0.7.6 f01a 8a sys_peer  <=== Good!
> 26 Feb 15:22:25 ntpd[8772]: 0.0.0.0 0613 03 spike_detect -0.370644 s
> 26 Feb 15:30:03 ntpd[8772]: 0.0.0.0 061c 0c clock_step -0.536289 s
> 26 Feb 15:30:02 ntpd[8772]: 0.0.0.0 0615 05 clock_sync
> 26 Feb 15:30:03 ntpd[8772]: 0.0.0.0 c618 08 no_sys_peer
> 26 Feb 15:30:03 ntpd[8772]: 10.0.7.6 e014 84 reachable
> 26 Feb 15:30:07 ntpd[8772]: LOCAL(1) 8014 84 reachable
> 26 Feb 15:30:21 ntpd[8772]: 10.0.7.6 f01a 8a sys_peer
> ...
> 26 Feb 15:46:49 ntpd[8772]: 0.0.0.0 c618 08 no_sys_peer
> 26 Feb 15:46:57 ntpd[8772]: 10.0.7.6 f01a 8a sys_peer
> 
> ...
> 26 Feb 15:56:58 ntpd[8772]: 10.0.7.6 f01a 8a sys_peer
> ...
> 26 Feb 16:24:33 ntpd[8772]: LOCAL(1) 901a 8a sys_peer <== and stays LOCAL
> which is now normal for this box  :(
> 
> Should the jump to stratum 14 be expected?  Anything obviously wrong with
> the ntp.conf?
> 
> I've had a few days of testing on what is usually a very stable (time-wise
> system), seems that running at prio 20 is required.
> 
> /etc/ntp.conf contains
> rlimit memlock -1
> rlimit filenum 32
> driftfile /var/db/ntp/drift
> disable bclient
> server 10.0.7.6 iburst minpoll 4 maxpoll 6 version 4 key 23057 prefer
> 
> server 127.127.1.1 minpoll 7 maxpoll 7
> fudge  127.127.1.1 stratum 14
> 
> restrict -4 default ignore
> restrict -6 default ignore
> restrict 127.0.0.1  nomodify nopeer notrap
> restrict -6 ::1 nomodify nopeer notrap
> restrict 0.0.0.0 ignore
> 
> restrict 10.0.7.6 nomodify nopeer noquery notrap ntpport
> restrict 10.169.168.91 mask 255.255.255.0 nomodify nopeer noquery notrap
> ntpport kod limited
> 
> 
> I'm also very surprised that the jitter on the server (under testing) is so
> poor.  The internet facing time server is
> *x.y.z.t   .ATOM.   1 u   73  5127   23.776   34.905  95.961
> but its very old and not running aslr.
> 
> Any ideas or pointers would be appreciated.  This is very, time consuming.
> :)
> 
> I'm using the following command sequence as these are all being changed
> sysctl kern.elf64.aslr.enable=1 

Re: [FreeBSD-Announce] FreeBSD 12.0 end-of-life

[Ian Lepore]

On Mon, 2020-02-24 at 19:01 -0600, Mike Karels wrote:
> > From mike  Sun Feb 23 17:24:54 2020
>   
> 
> Gerard E. Seibert wrote:
> > On Sun, 23 Feb 2020 16:27:40 -0600, Mike Karels stated:
> > > In this case (a USB failure), I bisected the problem some months ago.
> > > The offending commit was an ACPI update.  I have not yet "downgraded"
> > > to 11.3, but I will when I have enough time.
> > Obviously, I am not an expert here, but why can't the update to ACPI be
> > reversed and why is it only affecting some systems. And why do you have
> > to downgrade to 11.3? What are you running now?
> 
> The update to ACPI was pulled from upstream, and IIRC it included multiple
> changes.  There have been many updates to ACPI since.  I don't have any
> idea which part of the change caused the problem, or what it does; no idea
> how it affects USB on some systems.  I'm running 12.1 now, but USB is
> problematical (produces an error message once a second, and my UPS control
> doesn't seem to work).
> 
>   Mike
> 

There may have been two changes working together to create the problem.
At some time last year, changes were made to the usb drivers to be
sensitive to acpi data of some sort (maybe something about hubs, I
forget the details).  That alone may have been fine on most systems,
but then a later update of acpi code started causing problems which in
the past might not have affected usb but now does.

It's just a vague theory, based on my memory of some change happening
last year that injected awareness of acpi data into the usb driver
subsystem.  I wonder if it would be possible to add some sort of
tunable to disable that awareness, if nothing else just to see if it's
the cause of any usb trouble.

-- Ian


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

Re: ntpd doesn't like ASLR on stable/12 post-r350672

[Ian Lepore]

On Sun, 2019-08-25 at 15:03 +0300, Konstantin Belousov wrote:
> On Sun, Aug 25, 2019 at 12:40:22AM +0200, Trond Endrestøl wrote:
> > On Sun, 25 Aug 2019 01:28+0300, Konstantin Belousov wrote:
> > 
> > > On Sun, Aug 25, 2019 at 12:19:43AM +0200, Trond Endrestøl wrote:
> > > > On Sat, 24 Aug 2019 23:41+0300, Konstantin Belousov wrote:
> > > > > > I tried changing command="/usr/sbin/${name}" to 
> > > > > > command="/usr/bin/proccontrol -m aslr -s disable /usr/sbin/${name}" 
> > > > > > in 
> > > > > > /etc/rc.d/ntpd, but that didn't go well.
> > > > > 
> > > > > If you set kern.elf64.aslr.stack_gap to zero, does it help ?
> > > > 
> > > > That helped. Thank you again.
> > > 
> > > Can you verify is ntpd sets new rlimit(RLIMIT_STACK) for the main thread,
> > > and if yes, what this new limit is ?
> > 
> > (gdb)
> > 5265if (-1 == setrlimit(RLIMIT_STACK, )) {
> > (gdb) print rl
> > $1 = {rlim_cur = 204800, rlim_max = 536870912}
> 
> So they set the stack limit to 200K, am I right ?  I suspect they do
> that because ntpd wires entire process address space, so 512M blows off
> all limits on wiring.
> 
> I do not have a good idea how to make this behaviour compatible with
> the gap.  Might be we can change the gap sizing parameter to KBs instead
> of percentage, and set the defaults in 64KB range.
> 
> > 
> > > aslr.stack_gap is the percentage for the gap on that stack, and since
> > > default size of the main stack limit is quite large 512M, even 3%
> > > (default gap upper limit) are whole 15M. If the new limit is less than
> > > 15M, there is a likely probability that only the gap is left after the
> > > rlimit(2) call, leaving no space for the program frames.
> > > 
> > > At least this looks like a nice theory.

So is the problem here that before ntpd is running and has the chance
to call setrlimit(), aslr has already created a large stack gap?  If
so, it seems to me that aslr and setrlimit(RLIMIT_STACK, ...) are never
going to work right together.  Even if the default stack gap were much
smaller, code using RLIMIT_STACK is going to end up with a stack
smaller than it asked for because the gap it has no way of knowing
about uses up some part (or all of) the limited space.

If the default gap were 64K or less, things would be much more likely
to work accidentally (and we might never have noticed this situtation),
but they still wouldn't be working correctly.  Is it possible for the
code on the kernel side to add the requested limit to the gap size to
generate a result that gives the caller the usable stack size they
asked for?

-- Ian

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

Re: Geli prompts on gptzfsboot (Was:: Serious ZFS Bootcode Problem (GPT NON-UEFI -- RESOLVED)

[Ian Lepore]

On Sun, 2019-02-10 at 12:35 -0600, Karl Denninger wrote:
> On 2/10/2019 12:01, Ian Lepore wrote:
> > On Sun, 2019-02-10 at 11:54 -0600, Karl Denninger wrote:
> > > On 2/10/2019 11:50, Ian Lepore wrote:
> > > > On Sun, 2019-02-10 at 11:37 -0600, Karl Denninger wrote:
> > > > 
> > > > > [...]
> > > > > 
> > > > > BTW am I correct that gptzfsboot did *not* get the ability to
> > > > > read
> > > > > geli-encrypted pools in 12.0?  The UEFI loader does know how
> > > > > (which I'm
> > > > > using on my laptop) but I was under the impression that for
> > > > > non-
> > > > > UEFI
> > > > > systems you still needed the unencrypted boot partition from
> > > > > which to
> > > > > load the kernel.
> > > > > 
> > > > 
> > > > Nope, that's not correct. GELI support was added to the boot
> > > > and
> > > > loader
> > > > programs for both ufs and zfs in freebsd 12. You must set the
> > > > geli
> > > > '-g' 
> > > > option to be prompted for the passphrase while booting (this is
> > > > separate from the '-b' flag that enables mounting the encrypted
> > > > partition as the rootfs). You can use "geli configure -g" to
> > > > turn
> > > > on
> > > > the flag on any existing geli partition.
> > > > 
> > > > -- Ian
> > > 
> > > Excellent - this will eliminate the need for me to run down the
> > > foot-shooting that occurred in my update script since the
> > > unencrypted
> > > kernel partition is no longer needed at all.  That also
> > > significantly
> > > reduces the attack surface on such a machine (although you could
> > > still
> > > tamper with the contents of freebsd-boot of course.)
> > > 
> > > The "-g" flag I knew about from experience in putting 12 on my X1
> > > Carbon
> > > (which works really well incidentally; the only issue I'm aware
> > > of is
> > > that there's no 5Ghz WiFi support.)
> > > 
> > 
> > One thing that is rather unfortunate... if you have multiple geli
> > encrypted partitions that all have the same passphrase, you will be
> > required to enter that passphrase twice while booting -- once in
> > gpt[zfs]boot, then again during kernel startup when the rest of the
> > drives/partitions get tasted by geom. This is because APIs within
> > the
> > boot process got changed to pass keys instead of the passphrase
> > itself
> > from one stage of booting to the next, and the fallout of that is
> > the
> > key for the rootfs is available to the kernel for mountroot, but
> > the
> > passphrase is not available to the system when geom is probing all
> > the
> > devices, so you get prompted for it again.
> > 
> > -- Ian
> 
> Let me see if I understand this before I do it then... :-)
> 
> I have the following layout:
> 
> 1. Two SSDs that contain the OS as a two-provider ZFS pool, which has
> "-b" set on both members; I get the "GELI Passphrase:" prompt from
> the
> loader and those two providers (along with encrypted swap) attach
> early
> in the boot process.  The same SSDs contain a mirrored non-encrypted
> pool that has /boot (and only /boot) on it because previously you
> couldn't boot from an EFI-encrypted pool at all.
> 
> Thus:
> 
> [\u@NewFS /root]# gpart show da1
> =>   34  468862061  da1  GPT  (224G)
>  34   2014   - free -  (1.0M)
>2048   10241  freebsd-boot  (512K)
>3072   1024   - free -  (512K)
>4096   209715202  freebsd-zfs  [bootme]  (10G)
>20975616  1342177283  freebsd-swap  (64G)
>   155193344  3136675844  freebsd-zfs  (150G)
>   468860928   1167   - free -  (584K)
> 
> There is of course a "da2" that is identical.  The actual encrypted
> root
> pool is on partition 4 with "-b" set at present.  I get prompted from
> loader as a result after the unencrypted partition (#2) boots.
> 
> 2. Multiple additional "user space" pools on a bunch of other disks.
> 
> Right now #2 is using geli groups.  Prior to 12.0 they were handled
> using a custom /etc/rc.d script I wrote that did basically the same
> thing that geli groups does because all use the same passphrase and
> entering the same thing over and over on a boot was a pain in the
> butt. 
> It prompted 

Re: Fwd: Serious ZFS Bootcode Problem (GPT NON-UEFI)

[Ian Lepore]

On Sun, 2019-02-10 at 11:37 -0600, Karl Denninger wrote:
> On 2/10/2019 09:28, Allan Jude wrote:
> > Are you sure it is non-UEFI? As the instructions you followed,
> > overwriting da0p1 with gptzfsboot, will make quite a mess if that
> > happens to be the EFI system partition, rather than the freebsd-
> > boot
> > partition.
> 
> [...]
> 
> BTW am I correct that gptzfsboot did *not* get the ability to read
> geli-encrypted pools in 12.0?  The UEFI loader does know how (which I'm
> using on my laptop) but I was under the impression that for non-UEFI
> systems you still needed the unencrypted boot partition from which to
> load the kernel.
> 

Nope, that's not correct. GELI support was added to the boot and loader
programs for both ufs and zfs in freebsd 12. You must set the geli '-g' 
option to be prompted for the passphrase while booting (this is
separate from the '-b' flag that enables mounting the encrypted
partition as the rootfs). You can use "geli configure -g" to turn on
the flag on any existing geli partition.

-- Ian

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

Re: Fwd: Serious ZFS Bootcode Problem (GPT NON-UEFI)

[Ian Lepore]

On Sun, 2019-02-10 at 11:54 -0600, Karl Denninger wrote:
> On 2/10/2019 11:50, Ian Lepore wrote:
> > On Sun, 2019-02-10 at 11:37 -0600, Karl Denninger wrote:
> > > On 2/10/2019 09:28, Allan Jude wrote:
> > > > Are you sure it is non-UEFI? As the instructions you followed,
> > > > overwriting da0p1 with gptzfsboot, will make quite a mess if
> > > > that
> > > > happens to be the EFI system partition, rather than the
> > > > freebsd-
> > > > boot
> > > > partition.
> > > 
> > > [...]
> > > 
> > > BTW am I correct that gptzfsboot did *not* get the ability to
> > > read
> > > geli-encrypted pools in 12.0?  The UEFI loader does know how
> > > (which I'm
> > > using on my laptop) but I was under the impression that for non-
> > > UEFI
> > > systems you still needed the unencrypted boot partition from
> > > which to
> > > load the kernel.
> > > 
> > 
> > Nope, that's not correct. GELI support was added to the boot and
> > loader
> > programs for both ufs and zfs in freebsd 12. You must set the geli
> > '-g' 
> > option to be prompted for the passphrase while booting (this is
> > separate from the '-b' flag that enables mounting the encrypted
> > partition as the rootfs). You can use "geli configure -g" to turn
> > on
> > the flag on any existing geli partition.
> > 
> > -- Ian
> 
> Excellent - this will eliminate the need for me to run down the
> foot-shooting that occurred in my update script since the unencrypted
> kernel partition is no longer needed at all.  That also significantly
> reduces the attack surface on such a machine (although you could
> still
> tamper with the contents of freebsd-boot of course.)
> 
> The "-g" flag I knew about from experience in putting 12 on my X1
> Carbon
> (which works really well incidentally; the only issue I'm aware of is
> that there's no 5Ghz WiFi support.)
> 

One thing that is rather unfortunate... if you have multiple geli
encrypted partitions that all have the same passphrase, you will be
required to enter that passphrase twice while booting -- once in
gpt[zfs]boot, then again during kernel startup when the rest of the
drives/partitions get tasted by geom. This is because APIs within the
boot process got changed to pass keys instead of the passphrase itself
from one stage of booting to the next, and the fallout of that is the
key for the rootfs is available to the kernel for mountroot, but the
passphrase is not available to the system when geom is probing all the
devices, so you get prompted for it again.

-- Ian

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

Re: [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-19:05.kqueue

[Ian Lepore]

On Wed, 2019-02-06 at 03:46 +0700, Eugene Grosbein wrote:
> 06.02.2019 3:18, Ian Lepore wrote:
> 
> > > 2019, of course.  re@ does NOT make mistakes.  What you fail to
> > > realize is that NIST was using kqueue to check their atomic
> > > clock, and
> > > they lost the race.  Enjoy the rest of 2020.
> > > -Alan
> > > 
> > 
> > I think you meant that as a joke, but the reality is that NIST
> > measures
> > their atomic clocks using gear that runs FreeBSD (made by the
> > company I
> > work for). :)
> 
> I do not know if it is related or not: some months ago my FreeBSD
> 11.2-STABLE box
> having GPS received attached at /dev/cuau0 for my local ntpd stratum
> 1 server
> went to late of 2020 insanely. I was forced to comment GPS out of
> ntpd config to revive it
> but I lost all data in hundreds of local RRD databases and
> I found a race in libarchive being a reason why my backups had not
> most part of databases.
> 
> I still do not know exact reason and use Internet time source instead
> of local GPS.

The GPS week number rolls over in April 2019. At $work we have already
been seeing glitches in gps receivers as early as last June that were
caused by errors in the receivers' firmware that didn't handle the
upcoming rollover properly.

When a receiver first powers on, it has no real idea what gps era it's
in (right now we're in the 2nd, about to roll over to the 3rd). It has
to guess, which it mostly does the same way as software does that has
to deal with 2-digit years: make a decision based on the current date
being before/after some cutoff (like > 70 means 2070), and assume
everyone will be running newer firmware before that date arrives.

So your problem was most likely the gps receiver making a bad choice
before it had enough info to make a good choice. It's one of many
reasons why an ntp server should have at least 3 (really, at least 5)
peers, so it can reject obviously-insane data from a single source.
Even when you use a gps to get really accurate local time, you should
have a handful of network peers that can serve as sanity-checkers.

-- Ian

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

Re: [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-19:05.kqueue

[Ian Lepore]

On Tue, 2019-02-05 at 13:00 -0700, Alan Somers wrote:
> On Tue, Feb 5, 2019 at 12:55 PM Shawn Webb  wrote:
> > 
> > On Wed, Jan 09, 2019 at 07:40:30PM +, FreeBSD Errata Notices wrote:
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA512
> > > 
> > > =
> > > FreeBSD-EN-19:05.kqueue Errata 
> > > Notice
> > >   The FreeBSD 
> > > Project
> > > 
> > > Topic:  kqueue race condition and kernel panic
> > > 
> > > Category:   core
> > > Module: kqueue
> > > Announced:  2019-01-09
> > > Credits:Mark Johnston
> > > Affects:FreeBSD 11.2
> > > Corrected:  2019-11-24 17:11:47 UTC (stable/11, 11.2-STABLE)
> > 
> > Corrected November of 2018 or 2019? ;)
> 
> 2019, of course.  re@ does NOT make mistakes.  What you fail to
> realize is that NIST was using kqueue to check their atomic clock, and
> they lost the race.  Enjoy the rest of 2020.
> -Alan
> 

I think you meant that as a joke, but the reality is that NIST measures
their atomic clocks using gear that runs FreeBSD (made by the company I
work for). :)

-- Ian


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

Re: Success updating stable/11 to /12; a couple things to note

[Ian Lepore]

On Thu, 2018-12-27 at 08:30 -0800, David Wolfskill wrote:
> On Thu, Dec 27, 2018 at 09:13:09AM -0700, Ian Lepore wrote:
> > 
> > On Thu, 2018-12-27 at 05:53 -0800, David Wolfskill wrote:
> > > 
> > > * I found that I actually needed to create the ntpd user on the
> > >   running system prior to "make installworld" -- having run
> > >   "mergemaster -U" against the target (DESTDIF) was insufficient.
> > The correct update sequence involves running mergemaster twice,
> > once
> > with the -p option, then again later without it. It's detailed at
> > the
> > bottom of UPDATING. People get in the habit of skipping the -p step
> > because it's only really needed once every few years, such as when
> > a
> > new user is added to the base system.
> > 
> > -- Ian
> > 
> Yes, but the one after "make installworld" isn't likely to affect the
> "make installworld".  :-)
> 
> The sequence of events:
> 
> mount -u -r /
> mount -u -r /usr
> mount /dev/ada0s1a /S1
> mount /dev/ada0s1d /S1/usr
> mount -u -w /S1
> mount -u -w /S1/usr
> ln -fhs /var /S1/var
> mount -o ro freebeast:/usr/src /usr/src
> mount -o ro freebeast:/usr/obj /usr/obj
> id
> mount
> cd /usr/src
> uname -a
> date
> make LD=ld.lld installkernel DESTDIR=/S1
> date
> mergemaster -U -u 0022 -p -D /S1
> date
> rm -fr /S1/usr/include.old
> date
> mv -f /S1/usr/include /S1/usr/include.old
> date
> rm -fr /S1/usr/share/man
> date
> make installworld DESTDIR=/S1
> date
> mergemaster -F -U -u 0022 -i -D /S1
> date
> make delete-old DESTDIR=/S1
> date
> date
> df -k
> date
> 
> 
> My point was that running "mergemaster -U" against the new image
> (/S1,
> in the case above) is not sufficient for "make installworld
> DESTDIR=/S!"
> to work: it is necessary that the *running* system be aware of the
> "ntpd" user (I presume, to allow ownership of files to be set by the
> "ntpd" name, vs. the numeric "123").
> 
> Peace,
> david


I must have missed the part where you were using DESTDIR= during the
install. In that case, the right magic is to add DB_FROM_SRC=yes to the
make installworld command. There were a couple proposals to automate
that somehow, but I didn't see anything proposed that didn't basically
subvert the entire purpose of that check for whether the user exists.

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

Re: Success updating stable/11 to /12; a couple things to note

[Ian Lepore]

On Thu, 2018-12-27 at 05:53 -0800, David Wolfskill wrote:
> * I found that I actually needed to create the ntpd user on the
>   running system prior to "make installworld" -- having run
>   "mergemaster -U" against the target (DESTDIF) was insufficient.

The correct update sequence involves running mergemaster twice, once
with the -p option, then again later without it. It's detailed at the
bottom of UPDATING. People get in the habit of skipping the -p step
because it's only really needed once every few years, such as when a
new user is added to the base system.

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

Re: zfsboot@12.0: Shortening read at xxxx from 16 to -479991569

[Ian Lepore]

On Thu, 2018-12-13 at 08:59 -0700, Warner Losh wrote:
> On Thu, Dec 13, 2018, 6:19 AM Mark Martinec  s.si
> wrote:
> 
> > 
> > On one of my hosts (now running 12.0-RELEASE) the zfsboot shows
> > this weird negative number, which sounds suspicious:
> > 
> >    Verifying DMI pool Data .
> >    Shortening read at 3907029152 from 16 to 15
> >    Shortening read at 7435283708 from 16 to -479991569
> > 
> >    BTX loader 1.0  BTX version is 1.02
> >    Consoles: ...
> >    BIOS drive C: is disk0
> >    ...
> > 
> > The machine boots up normally and is fine, zpool scrub is happy,
> > so, should I worry? Anything fishy there?
> > 
> > Searching through sources, the message seems to come from
> > stand/i386/zfsboot/zfsboot.c :
> > 
> >    printf("Shortening read at %lld from %d to %lld\n",
> >  alignlba, alignnb, (zdsk->dsk.size + zdsk->dsk.start) -
> > alignlba);
> > 
> 
> Do you have any encrypted disks?
> 
> Warner

I ran into something like this once before, and tracked it down to
using the roundup2() and rounddown2() macros from sys/param.h. In
particular, a mix of 32 and 64 bit types of different signedness
resulted in zero-extension instead of sign-extension of one of the
values, and that masked off significant bits, then a later subtraction
turned a result into a negative number.

-- Ian

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

Re: /dev/crypto not being used in 12-STABLE

[Ian Lepore]

On Fri, 2018-12-07 at 18:38 -0500, Jung-uk Kim wrote:
> > So while OpenSSL now uses more of its own native C and assembly code
> > (e.g. for AES-NI support), and that's certainly faster than all the
> > overhead that cryptodev(4) brings with it (see jhb@'s post), I wonder:
> > 
> > 1. What happens to people using crypto hardware accelerators, ex.
> > hifn(4), padlock(4), ubsec(4), and safe(4)?  How exactly would OpenSSL
> > utilise these H/W accelerators if the devcrypto engine is disabled?
> 
> padlock has a dynamic engine, i.e., /usr/lib/engines/padlock.so.  I
> believe glxsb, hifn(4), safe(4), and ubsec(4) users are very rare
> nowadays.  If we have significant number of users and they show
> reasonable performance, then I will reconsider my decision.

What about non-x86 hardware? Most 32-bit ARM chips have crypto
accelleration hardware which is not implemenented as cpu instructions
(or accessible in any way from userland).

-- Ian

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

Re: Boot loader stuck after first stage upgrading 11.2 to 12.0-RC2

[Ian Lepore]

On Tue, 2018-12-04 at 21:51 +0200, Toomas Soome via freebsd-stable
wrote:
> 
> > 
> > On 4 Dec 2018, at 19:59, Mark Martinec  > i> wrote:
> > 
> > > 
> > > > 
> > > > 2018-11-29 18:43, Toomas Soome wrote:
> > > > > 
> > > > > I just did push biosdisk updates to stable/12, I wonder if
> > > > > you could
> > > > > test those bits…
> > Myself wrote:
> > > 
> > > > 
> > > > Thank you!  I haven't tried it yet, but I wonder whether this
> > > > fix was
> > > > already incorporated into 12.0-RC3, which would make my rescue
> > > > easier.
> > > > Otherwise I can build a stable/12 on another host and
> > > > transplant
> > > > the problematic file(s) to the affected host - if I knew which
> > > > files
> > > > to copy.
> > 2018-12-02 18:59, Toomas wrote:
> > > 
> > > The files are /boot/loader* binaries - to be exact, check which
> > > one is
> > > linked to /boot/loader. I can provide binaries if needed.
> > > [...]
> > > rgds,
> > > toomas
> > I got a maintenance window today so I tried with the new loader,
> > and it did not help.
> > 
> > More specifically:
> > 
> > As it comes with 12-RC2, the /boot/loader was hard linked with
> > loader_lua.
> > Its size is 421888 bytes. So I concentrated on this loader.
> > 
> > I build a fresh stable/12 on another host, and copied the newly
> > built loader_lua (425984 bytes) to the /boot directory of the
> > affected
> > host, deleted the file 'loader', and hard-linked loader_lua to
> > loader.
> > 
> > The situation has not changed: the BTX loader lists all BIOS drives
> > C..J (disk0..disk7), then a spinner starts and gets stuck forever.
> > It never reaches the 'BIOS 635kB/3537856kB available memory' line.
> > 
> > While trying to restore the old /boot from 11.2, I tried booting
> > a live image from a 12.0-RC3 memory stick - and the loader got
> > stuck again, same as when booting from a disk.
> > 
> > So I had to boot from an 11.2 memstick to be able to regain
> > control.
> > 
> >  Mark
> > 
> > 
> ok, if you could perform 2 tests:
> 
> 1. from loader prompt enter 0x413 0xa000 - @w . cr
> 
> 2. on first spinner, press space and type on boot: prompt:
> /boot/loader_4th and see if that will do better
> thanks,
> toomas
> 

I don't think that will be an option.  If it hasn't gotten to the point
of saying how much BIOS available memory there is, it's only halfway
through loader main() and has hung before getting to interact().

In fact, if that line hasn't printed, but some disk drives have been
listed, it pretty much has to be hung in the "March through the device
switch probing for things" loop. If all the disks are listed, then it
got through that entry in the devsw, and is likely hanging in the
dv_init calls for either the pxedisk or zfsdev devices.

-- Ian

> 
> > 
> > 
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > On 29 Nov 2018, at 17:01, Mark Martinec  > > > > > b...@ijs.si> wrote:
> > > > > > After successfully upgraded three hosts from 11.2-p4 to
> > > > > > 12.0-RC2 (amd64,
> > > > > > zfs, bios), I tried my luck with one of our production
> > > > > > hosts, and ended up
> > > > > > with a stuck loader after rebooting with a new kernel
> > > > > > (after the first
> > > > > > stage of upgrade).
> > > > > > These were the steps, and all went smoothly and normally
> > > > > > until a reboot:
> > > > > > freebsd-update upgrade -r 12.0-RC2
> > > > > > freebsd-update install
> > > > > > shutdown -r now
> > > > > > While booting, the 'BTX loader' comes up, lists the BIOS
> > > > > > drives,
> > > > > > then the spinner below the list comes up and begins
> > > > > > turning,
> > > > > > stuttering, and after a couple of seconds it grinds to a
> > > > > > standstill
> > > > > > and nothing happens afterwards.
> > > > > > At this point the ZFS and the bootstrap loader is supposed
> > > > > > to
> > > > > > come up, but it doesn't.
> > > > > > This host has too zfs pools, the system pool consists of
> > > > > > two SSDs
> > > > > > in a zfs mirror (also holding a freebsd-boot partition
> > > > > > each), the
> > > > > > other pool is a raidz2 with six JBOD disks on an LSI
> > > > > > controller.
> > > > > > The gptzfsboot in both freebsd-boot partitions is fresh
> > > > > > from 11.2,
> > > > > > both zpool versions are up-to-date with 11.2. The 'zpool
> > > > > > status -v'
> > > > > > is happy with both pools.
> > > > > > After rebooting from an USB drive and reverting the /boot
> > > > > > directory
> > > > > > to a previous version, the machine comes up normally again
> > > > > > with the 11.2-RELEASE-p4.
> > > > > > I found a file init.core in the / directory, slightly
> > > > > > predating the
> > > > > > last reboot with a salvaged system - although it was
> > > > > > probably not
> > > > > > a cause of the problem, but a consequence of the rescue
> > > > > > operation.
> > > > > > It is unfortunate that this is a production host, so I
> > > > > > can't play
> > > > > > much with it. One or two more quick experiments I can
> > > > > > probably
> > > > > 

Re: sudo not available after configuring ipmi serial over lan

[Ian Lepore]

On Thu, 2018-11-08 at 12:47 -0500, Jordan Caraballo wrote:
> Hi Ian,
> Changing the line following line from std.115200 to 3wire.115200
> worked.
> Can you explain the why? I am not entirely sure of the difference
> between
> 3wire and std there.
> 
> ttyu0   "/usr/libexec/getty 3wire.115200" vt100   on  secure
> 
> Thanks,
> - Jordan
> 

The standard setting honors the modem control lines on the serial port,
so any attempt to open that serial device will block until the carrier-
detect line on the port is asserted.

The 3wire setting indicates that only RX, TX, and GND are connected,
and modem-control signals should be ignored. An open of such a device
will return immediately whether anything is actually connected to the
serial port or not.

A /dev/ttyN device is assumed to be a "call-in" device and has the
blocking behavior by default. A /dev/cuaN device is assumed to be a
"call-out" device that doesn't wait for modem carrier by blocking.
Using the std vs 3wire designations in /etc/ttys causes init(1) to set
termios(4) flags to implement blocking-open or immediate-open behavior
without needing to change the device name as well.

-- Ian

> El jue., 8 nov. 2018 a las 10:39, Ian Lepore ()
> escribió:
> 
> > 
> > On Thu, 2018-11-08 at 06:10 +0700, Eugene Grosbein wrote:
> > > 
> > > 08.11.2018 5:56, Jordan Caraballo wrote:
> > > 
> > > > 
> > > > 
> > > > Hi guys,
> > > > 
> > > > After configuring ipmi serial over lan console, I am not being
> > > > able
> > > > to
> > > > execute any command related to sudo; not even "sudo su -". I am
> > > > using ttyu0
> > > > and COM1 on a Dell R530. Everything regarding receiving output
> > > > and
> > > > typing
> > > > at the serial console is fine; the only command not working is
> > > > sudo.
> > > > 
> > > > Any ideas? Below are the configurations.
> > > > 
> > > > /etc/ttys
> > > > 
> > > > # Serial terminals
> > > > # The 'dialup' keyword identifies dialin lines to login,
> > > > fingerd
> > > > etc.
> > > > #ttyu0  "/usr/libexec/getty 3wire"  vt100   onifconsole
> > > > secure
> > > > ttyu0   "/usr/libexec/getty std.115200"
> > > > vt100   on  secure
> > > Use network access to perform the following:
> > > 
> > > 1) Change "on" to "off" for ttyu0 then run "init q" to apply
> > > changes.
> > > 2) Replace "ttyu0" with "cuau0" within same line then run "init
> > > q"
> > > again.
> > > 
> > > Then retry using console and sudo.
> > The easy way to accomplish the same thing is to change std.115200
> > to
> > 3wire.115200 (and then do 'init q').
> > 
> > -- Ian
> > 
> 
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: sudo not available after configuring ipmi serial over lan

[Ian Lepore]

On Thu, 2018-11-08 at 06:10 +0700, Eugene Grosbein wrote:
> 08.11.2018 5:56, Jordan Caraballo wrote:
> 
> > 
> > Hi guys,
> > 
> > After configuring ipmi serial over lan console, I am not being able
> > to
> > execute any command related to sudo; not even "sudo su -". I am
> > using ttyu0
> > and COM1 on a Dell R530. Everything regarding receiving output and
> > typing
> > at the serial console is fine; the only command not working is
> > sudo.
> > 
> > Any ideas? Below are the configurations.
> > 
> > /etc/ttys
> > 
> > # Serial terminals
> > # The 'dialup' keyword identifies dialin lines to login, fingerd
> > etc.
> > #ttyu0  "/usr/libexec/getty 3wire"  vt100   onifconsole secure
> > ttyu0   "/usr/libexec/getty std.115200" vt100   on  secure
> Use network access to perform the following:
> 
> 1) Change "on" to "off" for ttyu0 then run "init q" to apply changes.
> 2) Replace "ttyu0" with "cuau0" within same line then run "init q"
> again.
> 
> Then retry using console and sudo.

The easy way to accomplish the same thing is to change std.115200 to
3wire.115200 (and then do 'init q').

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

Re: How to boot from GPT partition without "bootme" attribute?

[Ian Lepore]

On Tue, 2018-10-30 at 21:37 +0300, Lev Serebryakov wrote:
>  I have disk with GPT scheme and three partitions:
> 
> p1 - freebsd-boot
> p2 - freebsd-ufs
> p3 - freebsd-ufs
> 
>  pmbr is installed on this disk, and gptboot is installed on p1. Both
> p2
> and p3 contains valid FreeBSD installation, with /boot/loader,
> kernel,
> and everything.
> 
>  I have attribute "bootme" set on p3, but not on p2.
> 
>  What should I do to boot from p2?
> 
>  I've tried to interrupt gptboot and override its choice:
> 
>  0:ad(0p3)/boot/loader
> 
>  with
> 
>  0:ad(0p2)/boot/loader
> 
>  After that loader, loaded from p2, loads kernel from p3 and boots
> system from p3!
> 
>  If I have MBR, I could override "active" slice in boot0 MBR loader
> interactively.
> 
>  Is it analogous feature for GPT?
> 

While loader(8) is loading the kernel, interrupt it to get the console
prompt (or ask the menu to give the prompt if you use menus) and do:

 unload
 set currdev=disk0p2
 boot

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

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

[Ian Lepore]

On Thu, 2018-10-04 at 11:58 -0600, Warner Losh wrote:
> On Thu, Oct 4, 2018 at 11:47 AM Ian Lepore  wrote:
> 
> > 
> > On Thu, 2018-10-04 at 11:38 -0600, Warner Losh wrote:
> > > 
> > > On Thu, Oct 4, 2018 at 11:26 AM Ian Lepore 
> > > wrote:
> > > 
> > > > 
> > > > 
> > > > On Thu, 2018-10-04 at 10:21 -0600, Warner Losh wrote:
> > > > > 
> > > > > 
> > > > > On Thu, Oct 4, 2018 at 10:15 AM Michelle Sullivan
> > > > > wrote:
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > tech-lists wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > I'm astonished you're considering removing rl given how
> > > > > > > common
> > it is.
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > I'll second that comment - though no disrespect to
> > > > > > Brooks.  Brooks
> > as
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > far as I can see is just the messenger.
> > > > > > 
> > > > > Absent good data, one has to make one's best guesses. I
> > > > > guessed wrong
> > > > here
> > > > > 
> > > > > 
> > > > > in my comments to Brooks about which ones were must keeps. I
> > > > > knew it
> > was
> > > 
> > > > 
> > > > > 
> > > > > popular back in the day (~2000), but had thought it's
> > > > > popularity had
> > > > waned
> > > > > 
> > > > > 
> > > > > much more than it apparently has. I last deployed systems
> > > > > with rl in
> > them
> > > 
> > > > 
> > > > > 
> > > > > around 2007, and at the time it was trailing edge gear (the
> > > > > SBCs we
> > used
> > > 
> > > > 
> > > > at
> > > > > 
> > > > > 
> > > > > Timing Solutions tended to use popular, but ~5-year-old
> > > > > technology
> > > > because
> > > > > 
> > > > > 
> > > > > that market segment wanted longevity of spare
> > > > > availability...).
> > > > > 
> > > > > Warner
> > > > 11 years later, we (Timing Solutions, now a division of
> > > > Microchip) are
> > > > still using SBCs with rl(4) hardware and still shipping
> > > > software
> > > > updates with that driver built into the kernel. We build
> > > > systems with a
> > > > lifespan in the field of 20 years or more, and the stability
> > > > and
> > > > compatibility across OS upgrades over that kind of span is a
> > > > BIG reason
> > > > to use freebsd rather than linux for such things.
> > > > 
> > > OK. I'd have thought those SBCs would have gone out of production
> > > years
> > > ago It's a good datapoint to know that there's multiple users
> > > of
> > > FreeBSD using these parts in products that are still shipping.
> > > That's a
> > > clear and compelling benefit to the project that offsets the
> > > efforts that
> > > it's taken them to keep things current with rl.
> > > 
> > > In this case, though, rl is off the list, so that hardware should
> > > still
> > be
> > > 
> > > good. The only other SBC I was aware of at Timing Solutions was
> > > one that
> > > had an 'ed' chip on it (an ISA realtek part IIRC) that was used
> > > in around
> > > 2001, but in a 'one off' custom setup that I don't think will
> > > ever be
> > > upgraded But I have to ask since I know how things worked
> > > during my
> > > time there and systems that 'would never be upgraded' often times
> > > were
> > > later...
> > > 
> > > I'd also suggest that rl stands in stark contrast to the cs, wb,
> > > sn, smc,
> > > sf, tl, tx and vr drivers, which nobody has mentioned in this
> > > thread, and
> > > which I doubt are in use in any FreeBSD system of any age today.
> > > 
> > > Warner
> > I checked all our various kernel configs, and the only one on the
> > list
> > we still use appears to be rl.
> > 
> > One driver I was surprised to see was not on the list was vte. So
> > I'll
> > just preemptively mention that we do use that one too.
> > 
> I'll assume that you've deployed more than 5 of these systems and
> that you
> may someday upgrade them as well?  Which of the Vortex86 processors
> are you
> using, if you can answer that...
> 
> Warner

It's a DM Vortex86DX on a PCA-6743 board, which you can still buy.

32-bit only, BTW, which is why I hate hearing recent mumblings about
discarding 32-bit x86 support in freebsd.

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

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

[Ian Lepore]

On Thu, 2018-10-04 at 11:38 -0600, Warner Losh wrote:
> On Thu, Oct 4, 2018 at 11:26 AM Ian Lepore  wrote:
> 
> > 
> > On Thu, 2018-10-04 at 10:21 -0600, Warner Losh wrote:
> > > 
> > > On Thu, Oct 4, 2018 at 10:15 AM Michelle Sullivan 
> > > wrote:
> > > 
> > > > 
> > > > 
> > > > tech-lists wrote:
> > > > > 
> > > > > 
> > > > > 
> > > > > I'm astonished you're considering removing rl given how common it is.
> > > > > 
> > > > I'll second that comment - though no disrespect to Brooks.  Brooks as
> > > > far as I can see is just the messenger.
> > > > 
> > > Absent good data, one has to make one's best guesses. I guessed wrong
> > here
> > > 
> > > in my comments to Brooks about which ones were must keeps. I knew it was
> > > popular back in the day (~2000), but had thought it's popularity had
> > waned
> > > 
> > > much more than it apparently has. I last deployed systems with rl in them
> > > around 2007, and at the time it was trailing edge gear (the SBCs we used
> > at
> > > 
> > > Timing Solutions tended to use popular, but ~5-year-old technology
> > because
> > > 
> > > that market segment wanted longevity of spare availability...).
> > > 
> > > Warner
> > 11 years later, we (Timing Solutions, now a division of Microchip) are
> > still using SBCs with rl(4) hardware and still shipping software
> > updates with that driver built into the kernel. We build systems with a
> > lifespan in the field of 20 years or more, and the stability and
> > compatibility across OS upgrades over that kind of span is a BIG reason
> > to use freebsd rather than linux for such things.
> > 
> OK. I'd have thought those SBCs would have gone out of production years
> ago It's a good datapoint to know that there's multiple users of
> FreeBSD using these parts in products that are still shipping. That's a
> clear and compelling benefit to the project that offsets the efforts that
> it's taken them to keep things current with rl.
> 
> In this case, though, rl is off the list, so that hardware should still be
> good. The only other SBC I was aware of at Timing Solutions was one that
> had an 'ed' chip on it (an ISA realtek part IIRC) that was used in around
> 2001, but in a 'one off' custom setup that I don't think will ever be
> upgraded But I have to ask since I know how things worked during my
> time there and systems that 'would never be upgraded' often times were
> later...
> 
> I'd also suggest that rl stands in stark contrast to the cs, wb, sn, smc,
> sf, tl, tx and vr drivers, which nobody has mentioned in this thread, and
> which I doubt are in use in any FreeBSD system of any age today.
> 
> Warner

I checked all our various kernel configs, and the only one on the list
we still use appears to be rl.

One driver I was surprised to see was not on the list was vte. So I'll
just preemptively mention that we do use that one too.

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

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

[Ian Lepore]

On Thu, 2018-10-04 at 10:21 -0600, Warner Losh wrote:
> On Thu, Oct 4, 2018 at 10:15 AM Michelle Sullivan 
> wrote:
> 
> > 
> > tech-lists wrote:
> > > 
> > > 
> > > I'm astonished you're considering removing rl given how common it is.
> > > 
> > I'll second that comment - though no disrespect to Brooks.  Brooks as
> > far as I can see is just the messenger.
> > 
> Absent good data, one has to make one's best guesses. I guessed wrong here
> in my comments to Brooks about which ones were must keeps. I knew it was
> popular back in the day (~2000), but had thought it's popularity had waned
> much more than it apparently has. I last deployed systems with rl in them
> around 2007, and at the time it was trailing edge gear (the SBCs we used at
> Timing Solutions tended to use popular, but ~5-year-old technology because
> that market segment wanted longevity of spare availability...).
> 
> Warner

11 years later, we (Timing Solutions, now a division of Microchip) are
still using SBCs with rl(4) hardware and still shipping software
updates with that driver built into the kernel. We build systems with a
lifespan in the field of 20 years or more, and the stability and
compatibility across OS upgrades over that kind of span is a BIG reason
to use freebsd rather than linux for such things.

-- Ian

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

Re: Bind to port <1024 in jail

[Ian Lepore]

On Mon, 2018-08-20 at 17:02 +0200, Stefan Bethke wrote:
> Am 20.08.2018 um 16:59 schrieb Eugene Grosbein :
> > 
> > 
> > 20.08.2018 21:47, Stefan Bethke wrote:
> > 
> > > 
> > > I have a Go program (acme-dns) that wants to bind 53, 80, and
> > > 443, and I’d rather have it run as a non-privileged user.  The
> > > program doesn’t provide a facility to drop privs after binding
> > > the ports. I’m planning to run it in a jail.
> > > 
> > > After some googling, it appears that a couple of years ago I
> > > should have been able to do:
> > > sysctl net.inet.ip.portrange.reservedhigh=0
> > > and allow all processes to bind to „low“ ports. This does not
> > > work in my jails on a 11-stable host.
> > > 
> > > $ sudo sysctl net.inet.ip.portrange.reservedhigh=0
> > > net.inet.ip.portrange.reservedhigh: 1023
> > > sysctl: net.inet.ip.portrange.reservedhigh=0: Operation not
> > > permitted
> > > 
> > > Securelevel should not interfere:
> > > $ sysctl kern.securelevel
> > > kern.securelevel: -1
> > > 
> > > Is there a way to allow regular processes to bind to low ports?
> > Yes. Just use mac_portacl kernel module: kldload mac_portacl
> > 
> > Once loaded, it duplicates net.inet.ip.portrange.reservedhigh
> > protection
> > with its own security.mac.portacl.port_high, so it's safe to
> > disable
> > "reservedhigh" for whole system by running sysctl
> > net.inet.ip.portrange.reservedhigh=0
> > for host.
> > 
> > The trick is that mac_portacl provides a way to selectively give
> > permission for non-root UID
> > to bind low ports:
> > 
> > security.mac.portacl.rules=uid:88:tcp:80,uid:88:tcp:443,uid:53:tcp:
> > 53,uid:53:udp:53
> > 
> > It works just fine for a host and I use it for name servers
> > utilizing port 53
> > for a box with dynamically created interfaces, so it may bind the
> > port for distinct IP addresses
> > after it dropped privilegies when new interface is created and get
> > new IP assigned.
> > 
> > I have not tried it for a jails, though. Please try and respond.
> Thanks, but do I understand correctly that the
> security.mac.portacl.rules are system-wide and not per-jail?
> 
> I’m running ~10 jails on this host, and I don’t want to allow all of
> them to bind to low ports.
> 

Portacls are configure by userid. Just create a local userid that is
dedicated to this one process that runs in the one jail, and only it
(and root of course) would be able to bind to those ports.

-- Ian

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

Re: Bind to port <1024 in jail

[Ian Lepore]

On Mon, 2018-08-20 at 16:47 +0200, Stefan Bethke wrote:
> I have a Go program (acme-dns) that wants to bind 53, 80, and 443,
> and I’d rather have it run as a non-privileged user.  The program
> doesn’t provide a facility to drop privs after binding the ports. I’m
> planning to run it in a jail.
> 
> After some googling, it appears that a couple of years ago I should
> have been able to do:
> sysctl net.inet.ip.portrange.reservedhigh=0
> and allow all processes to bind to „low“ ports. This does not work in
> my jails on a 11-stable host.
> 
> $ sudo sysctl net.inet.ip.portrange.reservedhigh=0
> net.inet.ip.portrange.reservedhigh: 1023
> sysctl: net.inet.ip.portrange.reservedhigh=0: Operation not permitted
> 
> Securelevel should not interfere:
> $ sysctl kern.securelevel
> kern.securelevel: -1
> 
> Is there a way to allow regular processes to bind to low ports?
> 
> 
> Stefan
> 

You might be able to set up a specific local userid for this process,
then use mac_portacl(4) to allow it to bind to those ports. I'm not
certain that works inside a jail, however.

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

Re: How do I stop using local_unbound ?

[Ian Lepore]

On Tue, 2018-08-07 at 15:35 +0100, Pete French wrote:
> > 
> > Hmm.  First, make sure that it isn't running (service local_unbound
> > stop, etc).
> > Then look at your /etc/resolv.conf -- unbound tends to rewrite that
> > on initial
> > startup, taking some of it's settings and inserting itself into the
> > middle as a
> > caching DNS server.  At the very least, you want something like this:
> > 
> >          nameserver 8.8.8.8
> > 
> > I think the default DHCP client stomps all over /etc/resolv.conf
> > fairly well,
> Thats my problem - it doesnt rewrite it :-( I ended up taking one of my 
> machines with a working unboudn setup, rysncing the files to the non 
> working ones, re-enabling unbound and lettign it get on with its life. 
> Have given up on removing it!
> 
> Thanks for the advice though, I will dig into it on more detail when I 
> have a moment.
> 
> cheers,
> 
> -pete.

I wonder if OpenResolve is involved in rewriting the config. Do you
have an /etc/resolvconf.conf file, and if so, does it contain
configuration related to updating unbound?

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

Re: -STABLE can no longer build -CURRENT kernel, linker missing ifunc

[Ian Lepore]

On Wed, 2018-07-25 at 15:55 -0600, Alan Somers wrote:
> On Wed, Jul 25, 2018 at 9:04 AM, Kyle Evans 
> wrote:
> 
> > 
> > On Wed, Jul 25, 2018 at 9:52 AM, Alan Somers 
> > wrote:
> > > 
> > > On Wed, Jul 25, 2018 at 8:49 AM, Ian Lepore 
> > > wrote:
> > > 
> > > > 
> > > > On Wed, 2018-07-25 at 14:35 +0200, Ulrich Spörlein wrote:
> > > > > 
> > > > > Hey all, as of a couple of weeks ago, neither 11.2-RELEASE
> > > > > nor a
> > > > > recent
> > > > > 11-STABLE can buildkernel from head.
> > > > > 
> > > > > This has stopped the Coverity Scan runs dead in its track and
> > > > > I
> > > > > wonder how
> > > > > anyone would boostrap a move from 11.x to 12.0 then.
> > > > > 
> > > > > % env __MAKE_CONF=/dev/null make buildkernel
> > > > > make[1]: "/data/freebsd.work/Makefile.inc1" line 343:
> > > > > SYSTEM_COMPILER:
> > > > > libclang will be built for bootstrapping a cross-compiler.
> > > > > make[1]: "/data/freebsd.work/Makefile.inc1" line 348:
> > > > > SYSTEM_LINKER:
> > > > > libclang will be built for bootstrapping a cross-linker.
> > > > > 
> > > > > ---
> > > > > ---
> > > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Kernel build for GENERIC started on Wed Jul 25 14:34:46
> > > > > > > > CEST
> > > > > > > > 2018
> > > > > ---
> > > > > ---
> > > > > ===> GENERIC
> > > > > mkdir -p /usr/obj/data/freebsd.work/amd64.amd64/sys
> > > > > 
> > > > > ---
> > > > > ---
> > > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > stage 1: configuring the kernel
> > > > > ---
> > > > > ---
> > > > > cd /data/freebsd.work/sys/amd64/conf;  PATH=/usr/obj/data/
> > > > > freebsd.work/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/data/fr
> > > > > eebsd.wo
> > > > > rk/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/data/freebsd.work/
> > > > > amd64.am
> > > > > d64/tmp/legacy/bin:/usr/obj/data/freebsd.work/amd64.amd64/tmp
> > > > > /usr/sbi
> > > > > n:/usr/obj/data/freebsd.work/amd64.amd64/tmp/usr/bin:/sbin:/b
> > > > > in:/usr/
> > > > > sbin:/usr/bin
> > > > > config  -d
> > > > > /usr/obj/data/freebsd.work/amd64.amd64/sys/GENERIC  -I
> > > > > '/data/
> > > > > freebsd.work/sys/amd64/conf'
> > > > > '/data/freebsd.work/sys/amd64/conf/GENERIC'
> > > > > Kernel build directory is
> > > > > /usr/obj/data/freebsd.work/amd64.amd64/sys/GENERIC
> > > > > Don't forget to do ``make cleandepend && make depend''
> > > > > 
> > > > > ---
> > > > > ---
> > > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > stage 2.1: cleaning up the object tree
> > > > > ---
> > > > > ---
> > > > > cd /usr/obj/data/freebsd.work/amd64.amd64/sys/GENERIC;
> > > > > MACHINE_ARCH=amd64
> > > > > MACHINE=amd64 CPUTYPE= CC="cc -target x86_64-unknown-
> > > > > freebsd12.0
> > > > > --sysroot=/usr/obj/data/freebsd.work/amd64.amd64/tmp
> > > > > -B/usr/obj/data/
> > > > > freebsd.work/amd64.amd64/tmp/usr/bin" CXX="c++  -target
> > > > > x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/data/
> > > > > freebsd.work/amd64.amd64/tmp -B/usr/obj/data/
> 

Re: -STABLE can no longer build -CURRENT kernel, linker missing ifunc

[Ian Lepore]

On Wed, 2018-07-25 at 14:35 +0200, Ulrich Spörlein wrote:
> Hey all, as of a couple of weeks ago, neither 11.2-RELEASE nor a
> recent
> 11-STABLE can buildkernel from head.
> 
> This has stopped the Coverity Scan runs dead in its track and I
> wonder how
> anyone would boostrap a move from 11.x to 12.0 then.
> 
> % env __MAKE_CONF=/dev/null make buildkernel
> make[1]: "/data/freebsd.work/Makefile.inc1" line 343:
> SYSTEM_COMPILER:
> libclang will be built for bootstrapping a cross-compiler.
> make[1]: "/data/freebsd.work/Makefile.inc1" line 348: SYSTEM_LINKER:
> libclang will be built for bootstrapping a cross-linker.
> 
> --
> > 
> > > 
> > > > 
> > > > Kernel build for GENERIC started on Wed Jul 25 14:34:46 CEST
> > > > 2018
> --
> ===> GENERIC
> mkdir -p /usr/obj/data/freebsd.work/amd64.amd64/sys
> 
> --
> > 
> > > 
> > > > 
> > > > stage 1: configuring the kernel
> --
> cd /data/freebsd.work/sys/amd64/conf;  PATH=/usr/obj/data/
> freebsd.work/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/data/freebsd.wo
> rk/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/data/freebsd.work/amd64.am
> d64/tmp/legacy/bin:/usr/obj/data/freebsd.work/amd64.amd64/tmp/usr/sbi
> n:/usr/obj/data/freebsd.work/amd64.amd64/tmp/usr/bin:/sbin:/bin:/usr/
> sbin:/usr/bin
> config  -d /usr/obj/data/freebsd.work/amd64.amd64/sys/GENERIC  -I
> '/data/
> freebsd.work/sys/amd64/conf'
> '/data/freebsd.work/sys/amd64/conf/GENERIC'
> Kernel build directory is
> /usr/obj/data/freebsd.work/amd64.amd64/sys/GENERIC
> Don't forget to do ``make cleandepend && make depend''
> 
> --
> > 
> > > 
> > > > 
> > > > stage 2.1: cleaning up the object tree
> --
> cd /usr/obj/data/freebsd.work/amd64.amd64/sys/GENERIC;
> MACHINE_ARCH=amd64
> MACHINE=amd64 CPUTYPE= CC="cc -target x86_64-unknown-freebsd12.0
> --sysroot=/usr/obj/data/freebsd.work/amd64.amd64/tmp -B/usr/obj/data/
> freebsd.work/amd64.amd64/tmp/usr/bin" CXX="c++  -target
> x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/data/
> freebsd.work/amd64.amd64/tmp -B/usr/obj/data/
> freebsd.work/amd64.amd64/tmp/usr/bin" CPP="cpp -target
> x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/data/
> freebsd.work/amd64.amd64/tmp -B/usr/obj/data/
> freebsd.work/amd64.amd64/tmp/usr/bin" AS="as" AR="ar" LD="ld"
> LLVM_LINK=""
> NM=nm OBJCOPY="objcopy" RANLIB=ranlib STRINGS= SIZE="size"
> INSTALL="sh
> /data/freebsd.work/tools/install.sh" PATH=/usr/obj/data/
> freebsd.work/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/data/freebsd.wo
> rk/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/data/freebsd.work/amd64.am
> d64/tmp/legacy/bin:/usr/obj/data/freebsd.work/amd64.amd64/tmp/usr/sbi
> n:/usr/obj/data/freebsd.work/amd64.amd64/tmp/usr/bin:/sbin:/bin:/usr/
> sbin:/usr/bin
> make  -m /data/freebsd.work/share/mk  KERNEL=kernel cleandir
> make[2]: "/data/freebsd.work/sys/conf/kern.pre.mk" line 125: amd64
> kernel
> requires linker ifunc support
> *** Error code 1
> 
> Stop.
> make[1]: stopped in /data/freebsd.work
> *** Error code 1
> 
> Stop.
> make: stopped in /data/freebsd.work
> ___

I think you may need to do "make kernel-toolchain" first.

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

Re: lint errors in stable/11

[Ian Lepore]

On Thu, 2018-05-10 at 14:40 +, Rick Miller wrote:
> On Thu, May 10, 2018 at 8:23 AM Dimitry Andric  wrote:
> 
> > 
> > On 10 May 2018, at 12:47, Rick Miller  wrote:
> > > 
> > > 
> > > On Thu, May 10, 2018 at 6:35 AM Rick Miller  wrote:
> > ...
> > > 
> > > > 
> > > > Performing a release build via release/release.sh in r331337 of
> > stable/11
> > > 
> > > > 
> > > > errors citing the lack of lint. It’s understood lint was removed from
> > > > stable/11 so src.conf includes WITHOUT_LINT, but errors persist. As the
> > > > code review alludes to[1], lint is irrelevant here. It seems
> > WITHOUT_LINT
> > > 
> > > > 
> > > > may not be the only thing I’m looking for. What is the best approach for
> > > > mitigating these errors?
> > > > 
> > > > 
> > > Here’s the error w/o email munging:
> > > 
> > > ===> usr.bin/xlint/xlint (all)
> > > /data/dists/11.1.9.0-amd64-md/usr/src/contrib/apr/atomic/uni
> > > x/builtins.c:71:53:
> > > warning: passing 'const void *' to parameter of type 'volatile void *'
> > > discards
> > > qualifiers [-Wincompatible-pointer-types-discards-qualifiers]
> > > 
> > >    return (void*) __sync_val_compare_and_swap(mem, cmp, with);
> > > 
> > >    ^~~
> > > 
> > > 1 warning generated.
> > > 
> > > ===> usr.bin/xlint/llib (all)
> > > 
> > > sh: lint: not found
> > Are you building on a -CURRENT host?  If so, see the previous mail
> > thread about this:
> > 
> > 
> > https://lists.freebsd.org/pipermail/freebsd-stable/2017-November/088092.html
> > 
> > and https://bugs.freebsd.org/223892.
> > 
> > No, the build system is stable/11 r331337 building releng/11.1. The build
> system doesn’t include ‘lint’:
> 
> # echo $PATH
> /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin
> # which lint
> lint: Command not found.
> 
> The mail thread and bug refer to building stable/11 on current where this
> case is building releng/11.1 on stable/11. They also do not appear to
> provide actionable information on mitigating errors though the code
> commit[1] suggests installing a lint will resolve. Ports doesn’t seem to
> contain a suitable replacement however. Can lint still be installed on the
> build system from the stable/11 source? If so, how is that accomplished?
> 
> Do WITH/WITHOUT_LINT have any impact here? The source has been built with
> WITH_LINT and WITHOUT_LINT to the same result except that xlint either
> builds or doesn’t depending on the option.
> 
> This all seems to originate with llib’s dependency on lint as described in
> the email thread. It is in building llib where the error occurs.
> 
> [1] https://reviews.freebsd.org/D13799
> 
> -Rick

Releng/11.1 is cast in stone; as I understand it, only security fixes
can get merged into release branches, so the fix I did that added
WITH/WITHOUT_LINT isn't on that branch and never will be. That means
lint has to exist on the build system. If your build system is 11-
stable, then add WITH_LINT=yes to your /etc/src.conf, build and install
world, then that 11-stable system should be able to build the releng
branch. Unfortunately, no such option exists for people trying to build
on 12, because lint was removed completely (although it might be
possible to install a lint port, I'm not sure about that).

-- Ian

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

Re: [Bug 227323] [patch] [spi] sys/modules/spi/mx25l cannot be built outside of kernel build environment

[Ian Lepore]

On Fri, 2018-04-06 at 13:09 +, bugzilla-nore...@freebsd.org wrote:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227323
> 
> Bug ID: 227323
>    Summary: [patch] [spi] sys/modules/spi/mx25l cannot be
> built
> outside of kernel build environment
>    Product: Base System
>    Version: 11.1-STABLE
>   Hardware: Any
> OS: Any
> Status: New
>   Keywords: easy, patch-ready
>   Severity: Affects Some People
>   Priority: ---
>  Component: kern
>   Assignee: l...@freebsd.org
>   Reporter: eu...@freebsd.org
> CC: ead...@freebsd.org, i...@freebsd.org,
> sta...@freebsd.org
> 
> Created attachment 192286
>   --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=192286
> on=edit
> The fix
> 
> # cd /usr/src/sys/modules/spi/mx25l && make
> cc -O2 -pipe  -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE
> -nostdinc  
> -I. -I/home/src/sys -fno-common  -fno-omit-frame-pointer
> -mno-omit-leaf-frame-pointer   -MD  -MF.depend.mx25l.o -MTmx25l.o
> -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float 
> -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-
> protector -Wall
> -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-
> prototypes
> -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign
> -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs
> -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-
> tautological-compare
> -Wno-error-empty-body -Wno-error-parentheses-equality
> -Wno-error-unused-function -Wno-error-pointer-sign
> -Wno-error-shift-negative-value -Wno-error-address-of-packed-
> member  -mno-aes
> -mno-avx  -std=iso9899:1999 -c /home/src/sys/dev/flash/mx25l.c -o
> mx25l.o
> /home/src/sys/dev/flash/mx25l.c:30:10: fatal error: 'opt_platform.h'
> file not
> found
> #include "opt_platform.h"
>  ^~~~
> 1 error generated.
> *** Error code 1
> 

Does anybody know why mailing lists have recently started being spammed
with bug reports?  Using the list to point out a bug that's been
languishing without attention for a while might be appropriate, but
spamming the list with every action on every bug, IMO, is not.

-- Ian

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

Re: KBI unexpexted change in stable/11 ?

[Ian Lepore]

On Wed, 2018-03-28 at 16:30 +0100, John wrote:
> On Wed, 28 Mar 2018, at 15:20, Greg Byshenk wrote:
> > 
> > On Wed, Mar 28, 2018 at 03:11:50PM +0100, tech-lists wrote:
> > > 
> > > On 28/03/2018 14:39, Gregory Byshenk wrote:
> > > > 
> > > > You can do this manually, or by adding a PORTS_MODULES line to
> > > > /etc/make.conf. This will rebuild the listed modules from ports
> > > > when you build a new kernel.
> > > Are you sure it's in /etc/make.conf and not /etc/src.conf?
> > No. But it is in the man page for make.conf and not src.conf.
> yeah. That is... confusing! at least to me, because [I thought it would be] 
> src.conf that's consulted when src is built. So I ran a couple of tests and 
> found that it would work in either file HOWEVER if one ports module statement 
> was in src.conf and another, different ports module statement was in 
> make.conf, 
> that the one in src.conf would get built but the one in make.conf would not. 
> 
> how confusing is that. This is on 11.1-stable.
> 

Make.conf is for building anything that uses make(1) and the build
infrastructure in /usr/share/mk.  Src.conf is for building the freebsd
sources only.  According to build(7), the freebsd sources include
/usr/src, /usr/doc, and /usr/ports.  So settings in both make.conf and
src.conf affect ports builds.

The difference appears when you use make to build your own software
that isn't part of freebsd.  For that, make.conf settings are applied,
but not src.conf.  At least, that's what the docs say.  When I look at
the .mk files in /usr/share/mk, it appears to me that src.conf gets
used even for non-freebsd-source builds.

When both files exist, variables set in src.conf will override same-
named variables set in make.conf.  Using VAR += value in both files
will accumulate values into VAR rather than replacing them.

-- Ian

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

Re: Stability of 11.1S

[Ian Lepore]

On Tue, 2018-03-20 at 10:50 +, Pete French wrote:
> 
> On 20/03/2018 01:05, Dewayne Geraghty wrote:
> > 
> > We rebuild 11.1-Stable at least every two weeks.  Our build on the 7th
> > Feb is in use on our development boxes, however the rebuild on 22nd
> > resulted in frequent crashes and our reverting to FreeBSD 11.1-STABLE
> > r329008.  Is anyone actually running a Stable that was built after 22nd
> > Feb?  Could you please share the revision number?
> r330769 works fine for me. I usually upgrade on a Monday, though
> am holding off this week as am waiting for r330745 to land in STABLE,
> but it works fine for me always.
> 
> 
> > 
> > Because the churn in
> > https://lists.freebsd.org/pipermail/svn-src-stable-11/2018-March/ is
> > high we haven't been able to sight if a problem was identified and
> > fixed; so we're really looking for a functioning stable that we can
> > resume tracking.
> I use this to eyeball whats gone into STABLE, its a daily read for me as 
> I find keeping up with the mailing list tricky too.
> 
> 
> http://www.freshbsd.org/?branch=RELENG_11=freebsd;;
> 
> -pete.

I meant to get that done over the weekend but didn't actually get to it
until today.  I've MFC'd it to 11 as r331262, and I'm checking to see
whether it should go back to 10-stable as well.

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

Re: zfs problems after rebuilding system [SOLVED]

[Ian Lepore]

On Mon, 2018-03-12 at 17:21 +, Pete French wrote:
> 
> On 10/03/2018 23:48, Ian Lepore wrote:
> > 
> > I based my fix heavily on that patch from the PR, but I rewrote it
> > enough that I might've made any number of mistakes, so it needs fresh
> > testing.  The main change I made was to make it a lot less noisy while
> > waiting (it only mentions the wait once, unless bootverbose is set, in
> > which case it's once per second).  I also removed the logic that
> > limited the retries to nfs and zfs, because I think we can remove all
> > the old code related to waiting that only worked for ufs and let this
> > new retry be the way it waits for all filesystems.  But that's a bigger
> > change we can do separately; I didn't want to hold up this fix any
> > longer.
> TThansk for the patch, its is very much appercaited! I applied this 
> earlier today, and have been continuously rebooting the machine in Azure 
> ever since (every ten minutes). This has worked flawlessly, so I am very 
> happy that this fixes the issue for me. I am going to leave it running 
> though, just to see if anything happens. I havent examined dmesg, but I 
> thould be able to see the output from the patch there to verify that its 
> waiting, yes ?
> 
> cheers,
> 
> -pete.

Yes, if the root filesystem isn't available on the first attempt, it
should emit a single line saying it will wait for up to N seconds for
it to arrive, where N is the vfs.mountroot.timeout value (3 seconds if
not set in loader.conf).

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

Re: zfs problems after rebuilding system [SOLVED]

[Ian Lepore]

On Sat, 2018-03-10 at 23:42 +, Pete French wrote:
> > 
> > It looks like r330745 applies fine to stable-11 without any changes,
> > and there's plenty of value in testing that as well, if you're already
> > set up for that world.
> > 
> 
> Ive been running the patch from the PR in production since the original 
> bug report and it works fine. I havent looked at r330745 yes, but can 
> replace the PR patch with that and give it a whirl will take a look 
> Monday at whats possible.
> 
> -pete.
> 

I based my fix heavily on that patch from the PR, but I rewrote it
enough that I might've made any number of mistakes, so it needs fresh
testing.  The main change I made was to make it a lot less noisy while
waiting (it only mentions the wait once, unless bootverbose is set, in
which case it's once per second).  I also removed the logic that
limited the retries to nfs and zfs, because I think we can remove all
the old code related to waiting that only worked for ufs and let this
new retry be the way it waits for all filesystems.  But that's a bigger
change we can do separately; I didn't want to hold up this fix any
longer.

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

Re: zfs problems after rebuilding system [SOLVED]

[Ian Lepore]

On Sat, 2018-03-10 at 23:08 +, Pete French wrote:
> Ah, thankyou! I haven;t run current before, but as this is such an issue 
> for us I;ll setup an Azure machine running it and have it reboot every 
> five minutes or so to check it works OK. Unfortunately the error doesnt 
> show up consisntently, as its a race condition. Will let you know if it
> fails for any reason.
> 
> -pete. [time to take a dive into the exiting world of current]

It looks like r330745 applies fine to stable-11 without any changes,
and there's plenty of value in testing that as well, if you're already
set up for that world.

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

Re: zfs problems after rebuilding system [SOLVED]

[Ian Lepore]

On Sat, 2018-03-03 at 16:19 +, Pete French wrote:
> 
> > 
> > That won't work for the boot drive.
> > 
> > When no boot drive is detected early enough, the kernel goes to the
> > mountroot prompt.  That seems to hold a Giant lock which inhibits
> > further progress being made.  Sometimes progress can be made by
> > trying
> > to mount unmountable partitions on other drives, but this usually
> > goes
> > too fast, especially if the USB drive often times out.
> 
> 
> We have this problem in Azure with a ZFS root, was fixed by the pacth
> in 
> this bug report, which actually starts off being about USB.
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208882
> 
> You can then set the mountroot timeout as normal and it works.
> 
> I wold really like this patch to be applied, but it seems to have 
> languished since last summer. We use this as standard on all our
> cloud 
> machines now, and it works very nicely.
> 
> -pete.

I've committed a fix to -current (r330745) based on that patch.  It
would be good if people running -current who've had this problem could
give it some testing.  I'd like to get it merged back to 11 before the
11.1 release (and back to 10-stable as well).

With r330745 in place, the only setting that should be needed if your
rootfs is on a device that is slow to arrive is vfs.mountroot.timeout=
in loader.conf; the value is the number of seconds to wait before
giving up and going to the mountroot prompt.

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

Re: [CFT] [X11] graphics/drm-next-kmod now builds, loads and works on FreeBSD-11-stable

[Ian Lepore]

On Sun, 2018-02-18 at 14:27 -0800, Kevin Oberman wrote:
> On Sun, Feb 18, 2018 at 12:35 PM, Hans Petter Selasky 
> wrote:
> 
> > 
> > Hi FreeBSD desktop users!
> > 
> > During the past week and over the weekend all parts needed for building,
> > loading and using graphics/drm-next-kmod on FreeBSD-11-stable have been
> > completed!
> > 
> > A big thanks to all the people contributing to graphics support under
> > FreeBSD in both kernel and user-space! You'll find their names in the
> > commit logs including myself :-)
> > 
> > Links:
> > https://www.freshports.org/graphics/drm-next-kmod
> > https://svnweb.freebsd.org/changeset/base/329527
> > 
> > Issues are reported here:
> > https://github.com/FreeBSDDesktop/kms-drm/issues
> > 
> > --HPS
> > 
> Wow! That is awesome. Thanks to all of the contributors.
> 
> Any instructions? Am I right that the mod setting driver should generally
> be used. None of the links above really covers implementation.

+1.  I have the vague notion that drm-next has something to do with
supporting newer graphics hardware.  Since I just bought a new x86 box
whose builtin radeon R6 isn't supported by -current that sounds
interesting to me, where do I find out more about drm-next and how to
try it?

-- Ian 

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

Re: Clock occasionally jumps backwards on 11.1-RELEASE

[Ian Lepore]

On Mon, 2018-02-12 at 17:29 -0700, Alan Somers wrote:
> On Tue, Jan 23, 2018 at 8:40 AM, Alan Somers  wrote:
> 
> > 
> > On Tue, Jan 23, 2018 at 3:48 AM, Mike Pumford 
> > wrote:
> > 
> > > 
> > > On 22/01/2018 17:07, Alan Somers wrote:
> > > 
> > > > 
> > > > Since upgrading my jail server to 11.1-RELEASE, the clock occasionally
> > > > jumps backwards by 5-35 minutes for no apparent reason.  Has anybody 
> > > > seen
> > > > something like this?
> > > > 
> > > > Details
> > > > =
> > > > 
> > > > * Happens about once a day on my jail server, and has happened at least
> > > > once on a separate bhyve server.
> > > > 
> > > > * The jumps almost always happen between 1 and 3 AM, but I've also seen
> > > > them happen at 06:30 and 20:15.
> > > > 
> > > > That's the window when the period scripts are run which if you have a
> > > default configuration and a lot of jails will put the system under a lot 
> > > of
> > > stress.
> > > 
> > That did not fail to escape my notice.  However, none of the jails'
> > periodic jobs involve the clock in any way.  And I wouldn't think that a
> > high CPU load could cause clock drift, could it?  This isn't Windows XP,
> > after all.
> > 
> > 
> > > 
> > > * I'm using the default ntp.conf file.
> > > > 
> > > > 
> > > > Are you running ntpd inside the jail or on the jail host? On my jail
> > > systems (which are 10.3 and 11.1) I run ntpd out the jail host (outside 
> > > all
> > > jails) and not inside the jails and the jails then get the accurate time 
> > > as
> > > the underlying host has accurate time.
> > > 
> > Only on the host.
> > 
> > New info: there is a possibility that my NFS server is hanging for
> > awhile.  That would explain my problem's timing.  However, ntpd shouldn't
> > be accessing any NFS shares, and I wouldn't think that a hung NFS server
> > should be able to pause the clock.  I'm doing a new experiment that should
> > be more informative.  But I'll have to wait until the problem recurs to
> > learn anything.
> > 
> I have a little more data now.  The problem happens much more frequently
> than I originally realized, but usually for just a few seconds at a time.
> It looks like the system is hanging for awhile and then recovering.  Or at
> least, the clocks are hanging.  The only other possibility would be for
> both the realtime _and_ monotonic clocks to jump backwards.  In any case,
> the problem is not ntpd's fault.  I don't know what could cause a system to
> hang for up to 30 minutes without crashing, and I'm not sure how to tell
> unless it happens during working hours.  I'll send another update if I
> learn more.
> 
> -Alan

Under the hood, CLOCK_REALTIME and CLOCK_MONOTONIC are the same
hardware; if one stops, both do.  CLOCK_REALTIME is simply offset
somewhat from MONOTONIC, and the offset can change (which is why
REALTIME isn't monotonic).

If you want to take a snapshot of some independently-running clocks,
you can use sysctl kern.timecounter.tc..counter, but that is
a snapshot of the raw hardware counter for the clock, which usually
rolls over pretty quickly (.mask tells you how many bits the counter
has, that and .frequency can be used to figure out how fast it rolls
over).

-- Ian

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

Re: FreeBSD on 64MB memory

[Ian Lepore]

On Tue, 2018-02-13 at 01:40 +0700, Eugene Grosbein wrote:
> 13.02.2018 1:30, Ian Lepore wrote:
> 
> > 
> > > 
> > > > 
> > > >   PID USERNAME  THR PRI NICE   SIZERES STATETIMEWCPU COMMAND
> > > >   911 root1  220  8816K  8844K select   0:39   4.20% ntpd
> > > Your Soekris system can live without bloated ntpd, use ntpdate or try sntp
> > > to periodically check your clock with cron, unless you need to 
> > > re-distribute
> > > NTP to your LAN.
> > > 
> > Heh.  I think 1) you don't realize you're saying "you don't need ntpd"
> > to, and 2) you didn't notice the hostname of the system in some of the
> > debugging output (ntp1.us.grundclock.com).  :)
> You are partialy right :-) I skipped hostname.
> 
> Btw, is Soektris system has good enough hardware clock and/or
> enough horsepower to provide quality public NTP service?
> Also thinking of lots of garbage traffic these days UDP/123 suffers from...

Should be plenty of horsepower.  For years I ran a pool.ntp.org server
using a 60mhz armv4 system with 64MB ram.

You don't need anything special in the way of a clock to run a public
ntp server at stratum 2 or lower and achieve millisecond accuracy (or
sub-millisecond at stratum 1, with a PPS input).  I've never seen a
system whose kernel timekeeping was so bad that ntpd couldn't steer the
clock and provide accurate time.

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

Re: FreeBSD on 64MB memory

[Ian Lepore]

On Tue, 2018-02-13 at 01:04 +0700, Eugene Grosbein wrote:
> 13.02.2018 0:38, Ask Bjørn Hansen wrote:
> 
> > 
> > > 
> > > > 
> > > > I have an old Soekris system with 64MB memory that I upgraded from 10.3 
> > > > to 11.1 recently. Since then it’s started hanging every few days.
> > > Please show output of commands:
> > > 
> > > grep memory /var/run/dmesg.boot
> > real memory  = 67108864 (64 MB)
> > avail memory = 42098688 (40 MB)
> > 
> > The 24MB are for the kernel?  I wonder my 11.1 kernel is less 
> > discriminating with what I compiled in...
> You should be running custom kernel with absolute minimum.
> For example, use "options NO_SWAPPING" to compile out swapping code if your 
> system
> cannot have any swap area.
> 
> > 
> > > 
> > > top -ores -d1
> > Shortly after boot:
> > 
> > last pid:  1008;  load averages:  0.57,  0.62,  0.53up 0+00:19:31  
> > 06:24:50
> > 8 processes:   1 running, 7 sleeping
> > CPU: % user, % nice, % system, % interrupt, % idle
> > Mem: 9084K Active, 3644K Inact, 29M Wired, 4862K Buf, 492K Free
> > Swap:
> > 
> >   PID USERNAME  THR PRI NICE   SIZERES STATETIMEWCPU COMMAND
> >   911 root1  220  8816K  8844K select   0:39   4.20% ntpd
> Your Soekris system can live without bloated ntpd, use ntpdate or try sntp
> to periodically check your clock with cron, unless you need to re-distribute
> NTP to your LAN.
> 

Heh.  I think 1) you don't realize you're saying "you don't need ntpd"
to, and 2) you didn't notice the hostname of the system in some of the
debugging output (ntp1.us.grundclock.com).  :)

24MB physmem gone before the kernel even starts seems a little much.  I
wonder if some amount of that is being eaten up by a video frame buffer
that maybe isn't needed on a headless system?

-- Ian

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

Re: why does buildworld fail on stable/11 ?

[Ian Lepore]

On Fri, 2018-01-26 at 09:52 +, Holger Kipp wrote:
> Dear Scott,
> 
> Am 26.01.2018 um 09:07 schrieb Scott Bennett 
> >:
> 
> cd /usr/src; PATH=/sbin:/bin:/usr/sbin:/usr/bin MAKE_CMD=make 
> /usr/obj/usr/src/make.amd64/bmake -m /usr/src/share/mk -f Makefile.inc1 
> TARGET=amd64 TARGET_ARCH=amd64 MK_META_MODE=no cleandir
> bmake: illegal argument to d option -- p
> usage: make [-BPSXeiknpqrstv] [-C directory] [-D variable]
> [-d flags] [-E variable] [-f makefile] [-I directory]
> [-j max_jobs] [-m directory] [-V variable]
> [variable=value] [target ...]
> *** Error code 2
> 
> Stop.
> make: stopped in /usr/src
> hellas# exit
> exit
> 
> Script done on Fri Jan 26 01:33:18 2018
> 
> 
>  Scott Bennett, Comm. ASMELG, CFIAG
> 
> This sound similar to an issue with make in 2013:
> 
> 20130613:
> Some people report the following error after the switch to bmake:
> 
> make: illegal option -- J
> usage: make [-BPSXeiknpqrstv] [-C directory] [-D variable]
> ...
> *** [buildworld] Error code 2
> 
> this likely due to an old instance of make in
> ${MAKEPATH} (${MAKEOBJDIRPREFIX}${.CURDIR}/make.${MACHINE})
> which src/Makefile will use that blindly, if it exists, so if
> you see the above error:
> 
> rm -rf `make -V MAKEPATH`
> 
> should resolve it.
> 
> Can you check if you have an older version of make in your makepath and 
> delete / rename it?
> 

Yep, it's definitely running a bad old version of make, and the thought
that it's using /usr/obj/usr/src/make.amd64/bmake even though it's not
up to date fits the symptoms.  I'm a bit confused by the "rm -rf"
command at the end... when I do make -V MAKEPATH I get nothing, so the
rm command would just be an error -- since that's from UPDATING in
2013, I'm thinking it may be out of date advice now.

I think the right fix here is probably "rm -rf /usr/obj/*" followed by
a make buildworld.

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

Re: why does buildworld fail on stable/11 ?

[Ian Lepore]

On Thu, 2018-01-25 at 12:40 +, tech-lists wrote:
> 2. I don't know the difference between svnlite and svn. All I know is
> that svnlite is in base and it will be in base for reasons and one of
> those reasons will be that it works reliably. I think svn in ports might
> be more featureful, but maybe it's more buggy because of it, maybe it
> does more - I don't know. In your position I'd like fewer unknowns. I
> mean, even make cleandir fails. In circumstances like that, the first
> thing I'd do is get fresh sources.

The svn in ports is what freebsd committers use.  It works fine.  

svnlite is basically the full svn without the support for things like
perl and python plugins so that base freebsd doesn't have dependencies
on those things.

-- Ian

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

Re: why does buildworld fail on stable/11 ?

[Ian Lepore]

On Thu, 2018-01-25 at 00:25 -0600, Scott Bennett wrote:
> Ian Lepore <i...@freebsd.org> wrote:
> 
> > 
> > On Wed, 2018-01-24 at 12:39 +0100, Dimitry Andric wrote:
> > > 
> > > On 24 Jan 2018, at 09:51, Scott Bennett <benn...@sdf.org> wrote:
> > > > 
> > > > 
> > > > 
> > > > Subject: Re: why does buildworld fail on stable/11 ?
> > > > 
> > > > I wrote:
> > > > > 
> > > > > 
> > > > > ???On Mon, 22 Jan 2018 12:42:58 + lists  wrote:
> > > > > > 
> > > > > > 
> > > > > > On 22/01/2018 09:17, Scott Bennett wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > ???Anyway, I'm stuck.??Can someone please tell me what is going 
> > > > > > > wrong and
> > > > > > > how to fix it???I'd really like to be able to update my system, 
> > > > > > > not only to
> > > > > > > keep it reasonably current, but also to be able to customize a 
> > > > > > > kernel.??Thanks
> > > > > > > in advance for any suggestions/solutions.
> > > > [much deleted??--SB]
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > then
> > > > > > 
> > > > > > [/usr/src #] make cleandir && make clean && make buildworld && make
> > > > > > buildkernel && make installkernel && mergemaster -p
> > > > > ???At this point, that looks very optimistic, to say the least. 
> > > > > :-)??I've
> > > > > tried "make cleanworld" (with /etc/make.conf still in place), and it 
> > > > > failed
> > > > > exactly like the buildworld example I posted before.
> > > > Okay.??Here's what happened.
> > > > 
> > > > Script started on Wed Jan 24 02:17:30 2018
> > > > hellas# mv /etc/make.conf{,.save}
> > > > hellas# mv /etc/src.conf{,.save}
> > > > hellas# cd /usr/src
> > > > hellas# make cleandir
> > > > "/usr/src/share/mk/local.sys.mk", line 51: Malformed conditional 
> > > > (${.MAKE.MODE:Mmeta*} != "")
> > > > "/usr/src/share/mk/local.sys.mk", line 58: Malformed conditional 
> > > > (${.MAKE.MODE:Mnofilemon} == "")
> > > > "/usr/src/share/mk/local.sys.mk", line 76: if-less else
> > > > "/usr/src/share/mk/local.sys.mk", line 79: if-less endif
> > > > "/usr/src/share/mk/sys.mk", line 476: if-less endif
> > > > bmake: fatal errors encountered -- cannot continue
> > > Looks like your make is broken.??What is the output of "which make"?
> > > 
> > > -Dimitry
> > > 
> > And also the output of "make -V MAKE_VERSION". ?To me, this looks a lot
> > like what happens when you try to use old fmake from freebsd 8 to build
> > modern freebsd source.
> > 
> hellas# make -V MAKE_VERSION
> 20170720
> hellas#

Well, that kills the wrong-version theory.  The thing I would try next
is setting some make debug flags, but it'll generate a ton of output.

I'd start with "make -dlp cleandir" that should list everything it's
doing while reading makefiles, and list any commands it executes.
 Capture that output (stdout and stderr), then a good first-look at the
file might be something like "grep -v ParseReadLine make.log", that
should show us what files it's reading from which directories.  My
theory is maybe it's picking up a wrong include file somehow which
leads it astray.  If that's not it, we may need to also examine all the
ParseReadLine stuff, or add some other debug flags.

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

Re: why does buildworld fail on stable/11 ?

[Ian Lepore]

On Wed, 2018-01-24 at 12:39 +0100, Dimitry Andric wrote:
> On 24 Jan 2018, at 09:51, Scott Bennett  wrote:
> > 
> > 
> > Subject: Re: why does buildworld fail on stable/11 ?
> > 
> > I wrote:
> > > 
> > >    On Mon, 22 Jan 2018 12:42:58 + lists  wrote:
> > > > 
> > > > On 22/01/2018 09:17, Scott Bennett wrote:
> > > > > 
> > > > >    Anyway, I'm stuck.  Can someone please tell me what is going wrong 
> > > > > and
> > > > > how to fix it?  I'd really like to be able to update my system, not 
> > > > > only to
> > > > > keep it reasonably current, but also to be able to customize a 
> > > > > kernel.  Thanks
> > > > > in advance for any suggestions/solutions.
> > [much deleted  --SB]
> > > 
> > > > 
> > > > then
> > > > 
> > > > [/usr/src #] make cleandir && make clean && make buildworld && make
> > > > buildkernel && make installkernel && mergemaster -p
> > >    At this point, that looks very optimistic, to say the least. :-)  I've
> > > tried "make cleanworld" (with /etc/make.conf still in place), and it 
> > > failed
> > > exactly like the buildworld example I posted before.
> > Okay.  Here's what happened.
> > 
> > Script started on Wed Jan 24 02:17:30 2018
> > hellas# mv /etc/make.conf{,.save}
> > hellas# mv /etc/src.conf{,.save}
> > hellas# cd /usr/src
> > hellas# make cleandir
> > "/usr/src/share/mk/local.sys.mk", line 51: Malformed conditional 
> > (${.MAKE.MODE:Mmeta*} != "")
> > "/usr/src/share/mk/local.sys.mk", line 58: Malformed conditional 
> > (${.MAKE.MODE:Mnofilemon} == "")
> > "/usr/src/share/mk/local.sys.mk", line 76: if-less else
> > "/usr/src/share/mk/local.sys.mk", line 79: if-less endif
> > "/usr/src/share/mk/sys.mk", line 476: if-less endif
> > bmake: fatal errors encountered -- cannot continue
> Looks like your make is broken.  What is the output of "which make"?
> 
> -Dimitry
> 

And also the output of "make -V MAKE_VERSION".  To me, this looks a lot
like what happens when you try to use old fmake from freebsd 8 to build
modern freebsd source.

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

Re: Freebsd 10 to 11 sendmail compile issues..

[Ian Lepore]

On Sat, 2017-10-21 at 19:22 -0400, Howard Leadmon wrote:
>   Hopefully someone can help or give me a pointer to a solution to this 
> one.   Running FreeBSD 10.3 and figured I would do a source build and 
> jump to FreeBSD 11.1.  For the most part this seemed to be going well, 
> but when it goes to compile sendmail, it spits out the following error:
> 
> bmake[4]: "/usr/src/share/mk/src.libnames.mk" line 391: 
> /usr/src/libexec/mail.local: These libraries should be LIBADD+=foo 
> rather than DPADD/LDADD+=-lfoo:  ssl crypto
> 
> 
> I have the following flags in /etc/make.conf:
> 
> SENDMAIL_CFLAGS= -I/usr/local/include -DSASL=2 -DDNSMAP -DSTARTTLS
> SENDMAIL_LDFLAGS= -L/usr/local/lib
> SENDMAIL_LDADD= -lsasl2 -lssl -lcrypto
> 
> 
>   So I trhought OK, simple enough looking at the error and changed this 
> over to the following:
> 
> SENDMAIL_CFLAGS= -I/usr/local/include -DSASL=2 -DDNSMAP -DSTARTTLS
> SENDMAIL_LDFLAGS= -L/usr/local/lib
> SENDMAIL_LIBADD+= sasl2 ssl crypto
> 
>   After that the error received was that I didn't has sasl2:
> 
> --- ELF/Arch/AMDGPU.o ---
> c++   -O2 -pipe -march=nocona -I/usr/src/contrib/llvm/tools/lld/ELF 
> -I/usr/src/contrib/llvm/tools/lld/include 
> -I/usr/obj/usr/src/usr.bin/clang/lld 
> -I/usr/obj/usr/src/lib/clang/libllvm -I/usr/src/lib/clang/include 
> -I/usr/src/contrib/llvm/include -DLLVM_BUILD_GLOBAL_ISEL 
> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG 
> -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.1\" 
> -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.1\" -DDEFAULT_SYSROOT=\"\" 
> -ffunction-sections -fdata-sections -g -MD -MF.depend.ELF_Arch_AMDGPU.o 
> -MTELF/Arch/AMDGPU.o -fstack-protector-strong -Wno-empty-body 
> -Wno-string-plus-int -Wno-unused-const-variable 
> -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality 
> -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef 
> -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum 
> -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments 
> -std=c++11 -fno-exceptions -fno-rtti -stdlib=libc++ 
> -Wno-c++11-extensions  -c 
> /usr/src/contrib/llvm/tools/lld/ELF/Arch/AMDGPU.cpp -o ELF/Arch/AMDGPU.o
> --- all_subdir_usr.sbin ---
> deliver.o: In function `endmailer':
> /usr/src/contrib/sendmail/src/deliver.c:3874: undefined reference to 
> `sasl_dispose'
> deliver.o: In function `deliver':
> /usr/src/contrib/sendmail/src/deliver.c:3137: undefined reference to 
> `sasl_getprop'
> main.o: In function `main':
> /usr/src/contrib/sendmail/src/main.c:2303: undefined reference to 
> `sasl_server_init'
> /usr/src/contrib/sendmail/src/main.c:2305: undefined reference to 
> `sasl_errstring'
> sasl.o: In function `sm_sasl_init':
> /usr/src/contrib/sendmail/src/sasl.c:146: undefined reference to 
> `sasl_set_alloc'
> sfsasl.o: In function `sasl_read':
> /usr/src/contrib/sendmail/src/sfsasl.c:224: undefined reference to 
> `sasl_decode'
> sfsasl.o: In function `sasl_write':
> /usr/src/contrib/sendmail/src/sfsasl.c:311: undefined reference to 
> `sasl_getprop'
> /usr/src/contrib/sendmail/src/sfsasl.c:316: undefined reference to 
> `sasl_encode'
> srvrsmtp.o: In function `smtp':
> /usr/src/contrib/sendmail/src/srvrsmtp.c:951: undefined reference to 
> `sasl_server_new'
> /usr/src/contrib/sendmail/src/srvrsmtp.c:1004: undefined reference to 
> `sasl_setprop'
> /usr/src/contrib/sendmail/src/srvrsmtp.c:1018: undefined reference to 
> `sasl_setprop'
> /usr/src/contrib/sendmail/src/srvrsmtp.c:1069: undefined reference to 
> `sasl_setprop'
> /usr/src/contrib/sendmail/src/srvrsmtp.c:1081: undefined reference to 
> `sasl_setprop'
> /usr/src/contrib/sendmail/src/srvrsmtp.c:1083: undefined reference to 
> `sasl_setprop'
> srvrsmtp.o:/usr/src/contrib/sendmail/src/srvrsmtp.c:2254: more undefined 
> references to `sasl_setprop' follow
> 
> 
> 
>   So apparently that change seems to be including ssl and crypto but not 
> sasl2 for some reason.    I have googled looking for examples of how to 
> correct it, but everything I find shows the original way I had it to 
> start with, and clearly that is no longer working.  Any ideas on how I 
> need to define this would be most appreciated..
> 
> ---
> Howard Leadmon
> PBW Communications, LLC
> http://www.pbwcomm.com
> 

>From looking at the sendmail makefile, it looks like the ssl and crypto
libraries are now added automatically unless you use the
WITHOUT_OPENSSL build option, it contains this:

.if ${MK_OPENSSL} != "no"
# STARTTLS support
CFLAGS+=-DSTARTTLS -D_FFR_TLS_1
LIBADD+=ssl crypto
.endif

I think that means you can now reduce the settings in your make.conf to

SENDMAIL_CFLAGS= -I/usr/local/include -DSASL=2 -DDNSMAP
SENDMAIL_LDFLAGS= -L/usr/local/lib
SENDMAIL_LDADD= -lsasl2

and I think you won't get the LIBADD warning for -lsasl2 because it's
not a standard base library (but I'm not sure of that).

-- Ian
___

Re: [Asterisk-bsd] Asterisk13 coredump on freebsd 11.1

[Ian Lepore]

On Thu, 2017-09-28 at 01:17 +0200, Hans Petter Selasky wrote:
> Hi,
> 
> I just upgraded and hit these SEGFAULTs too. First of all you need
> to 
> install GDB 8.0 from ports to get the right backtrace (important).
> This 
> leads straight into LibUnwind in libgcc:
> 
> (gdb) bt
> #0  uw_frame_state_for (context=context@entry=0x7fffdf3bbe20, 
> fs=fs@entry=0x7fffdf3bbb70)
>  at /wrkdirs/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/unwind-
> dw2.c:1249
> #1  0x000802cc8ffb in _Unwind_ForcedUnwind_Phase2 
> (exc=exc@entry=0x804427230,
>  context=context@entry=0x7fffdf3bbe20) at 
> /wrkdirs/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/unwind.inc:155
> #2  0x000802cc9334 in _Unwind_ForcedUnwind (exc=0x804427230, 
> stop=0x8024d5450 ,
>  stop_argument=) at 
> /wrkdirs/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/unwind.inc:207
> #3  0x0008024d52b3 in _Unwind_ForcedUnwind (ex=, 
> stop_func=0x7fffdf3bb948, stop_arg=0x804427000)
>  at /usr/img/freebsd.11/lib/libthr/thread/thr_exit.c:106
> #4  thread_unwind () at
> /usr/img/freebsd.11/lib/libthr/thread/thr_exit.c:172
> #5  _pthread_exit_mask (status=, mask=)
>  at /usr/img/freebsd.11/lib/libthr/thread/thr_exit.c:257
> #6  0x0008024d50db in _pthread_exit (status=0x804427000) at 
> /usr/img/freebsd.11/lib/libthr/thread/thr_exit.c:206
> #7  0x0008024c7c0d in thread_start (curthread=0x804427000)
>  at /usr/img/freebsd.11/lib/libthr/thread/thr_create.c:289
> #8  0x7fffdf34 in ?? ()
> Backtrace stopped: Cannot access memory at address 0x7fffdf3bc000
> 
> libgcc uses this format which is OK:
> 
> (gdb) ptype struct _Unwind_Context
> type = struct _Unwind_Context {
>  _Unwind_Context_Reg_Val reg[18];
>  void *cfa;
>  void *ra;
>  void *lsda;
>  struct dwarf_eh_bases bases;
>  _Unwind_Word flags;
>  _Unwind_Word version;
>  _Unwind_Word args_size;
>  char by_value[18];
> }
> 
> > 
> > x86_64_freebsd_fallback_frame_state
> > (struct _Unwind_Context *context, _Unwind_FrameState *fs)
> > {
> >   struct sigframe *sf;
> >   long new_cfa;
> > 
> >   /* Prior to FreeBSD 9, the signal trampoline was located
> > immediately
> >  before the ps_strings.  To support non-executable stacks on
> > AMD64,
> >  the sigtramp was moved to a shared page for FreeBSD
> > 9.  Unfortunately
> >  this means looking frame patterns again
> > (sys/amd64/amd64/sigtramp.S)
> >  rather than using the robust and convenient KERN_PS_STRINGS
> > trick.
> > 
> >  :  lea 0x10(%rsp),%rdi
> >  :  pushq   $0x0
> >  :  mov $0x1a1,%rax
> >  :  syscall
> > 
> >  If we can't find this pattern, we're at the end of the stack.
> >   */
> > 
> >   if (!(   *(unsigned int *)(context->ra)  == 0x247c8d48
>    fault is triggered by this read access on the
> stack
> > 
> > && *(unsigned int *)(context->ra +  4) == 0x48006a10
> > && *(unsigned int *)(context->ra +  8) == 0x01a1c0c7
> > && *(unsigned int *)(context->ra + 12) == 0x050f ))
> > return _URC_END_OF_STACK;
> > 
> The code in question is trying to access the return address of the 
> caller on the stack which apparently I think is caught by the
> recently 
> added MAP_GUARD feature:
> 
> https://svnweb.freebsd.org/changeset/base/320763
> 
> I think this feature can be disabled by setting:
> sysctl security.bsd.stack_guard_page=0
> 
> And then restart Asterisk. Not sure if it helps, currently testing.
> This my best guess why Asterisk started segfaulting when upgrading to
> 11.1.
> 
> --HPS

In 12-current we've switched to the unwind code from the llvm project.
 I wonder if that can be MFC'd to 11?

There are other problems in the contrib/gcc unwind code in 11 right
now.  For example, I've been chasing what appears to be a clang codegen
bug that prevents returning a value from a function that contains a
call to __builtin_eh_return().  That leads to a bogus return value
getting misinterpretted and eventually abort() gets called when
std::terminate() should be called instead due to an uncaught exception.

-- Ian


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

Re: entropy lockup

[Ian Lepore]

On Tue, 2017-09-12 at 09:20 +1000, Morgan Reed wrote:
> In all likelihood the process wasn't "hung" per-se, more likely
> random
> hadn't been seeded yet and as such you *can't* get 4096b of entropy
> out of
> it (so the process was attempting to do its job, just nothing on the
> device).
> 
> The issue is basically that there are very few "good" entropy sources
> in a
> VM environment, and as such (particularly on a machine which is only
> running SSH) there's not enough data available to seed random.
> 
> Check 'man 4 random' for some discussion.
> 

The save-entropy files get written from a crontab entry.  That means
the system is already up and running, which means it's well past the
point of hanging because it needs to be seeded.  Once it is seeded, it
can never "run out of entropy".

So all in all, this is a genuine problem of some sort.  The fact that
the save-entropy process has accumulated 48+ minutes of cpu time is
another problem indicator.  The process state is RL, runnable and
waiting to acquire a lock, which seems contradictory (unless that means
it's waiting for a spinlock maybe).

-- Ian

> On Tue, Sep 12, 2017 at 12:02 AM, Vick Khera  wrote:
> 
> > 
> > I just had a VM running in Google's cloud become totally useless,
> > and I
> > tracked it down to the save-entropy operation.
> > 
> > Basically this process was sucking up all CPU, even when nothing
> > else
> > running other than my ssh shell:
> > 
> > % ps axuw803
> > USER PID  %CPU %MEM  VSZ  RSS TT  STAT STARTED TIME COMMAND
> > operator 803 100.0  0.1 8336 2096  -  RL   08:55   48:20.14 dd
> > if=/dev/random of=saved-entropy.1 bs=4096 count=1
> > 
> > 
> > The process is unkillable, and I cannot even get the system to shut
> > down.
> > That has been hanging for about 10 minutes so far, with the last
> > output
> > being
> > 
> > System shutdown time has arrive90 second watchdSep 11 09:50:02
> > yertle init:
> > /bin/sh on /etc/rc.shutdown terminated abnormally, going to single
> > user
> > mode
> > Sep 11 09:50:47 init: some processes would not die; ps axl advised
> > Waiting (max 60 seconds) for system process `vnlru' to stop... done
> > Waiting (max 60 seconds) for system process `bufdaemon' to stop...
> > done
> > Waiting (max 60 seconds) for system process `syncer' to stop...
> > Syncing disks, vnodes remaining... 4 4 4 4 4 4 4 timed out
> > 2 2 2 2 2 2 2
> > 
> > 
> > Running FreeBSD 11.1-p1 on a 1CPU standard machine in GCE.
> > 
> > What's the proper recovery from this kind of lockup, or how to
> > prevent it?
> > I've never encountered this on a bare metal system, or other KVM
> > based
> > machines.
> > ___
> > freebsd-stable@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebs
> > d.org"
> > 
> 
> 
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Error in /usr/src/release/release.sh

[Ian Lepore]

On Mon, 2017-08-14 at 14:34 +, Glen Barber wrote:
> On Mon, Aug 14, 2017 at 08:26:59AM -0600, Ian Lepore wrote:
> > 
> > On Mon, 2017-08-14 at 13:23 +, Glen Barber wrote:
> > > 
> > > On Mon, Aug 14, 2017 at 01:18:14PM +, Glen Barber wrote:
> > > > 
> > > > 
> > > > On Sat, Aug 12, 2017 at 05:12:02PM +, Bryce Edwards wrote:
> > > > > 
> > > > > 
> > > > > When trying to build a set of RELENG/11.1 release files, I'm
> > > > > getting the
> > > > > following error (tail end of output) in the release.sh run:
> > > > > ---
> > > > > ---
> > > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Kernel build for ALLWINNER completed on Fri Aug 11
> > > > > > > > 22:24:02
> > > > > > > > UTC 2017
> > > > > ---
> > > > > ---
> > > > > make -C /usr/src/release  obj
> > > > > make -C /usr/src/release  ftp
> > > > > `ftp' is up to date.
> > > > This makes me think a populated release directory within
> > > > ${.OBJDIR}
> > > > (i.e., /usr/obj/usr/src/release) already existed (perhaps from
> > > > a previous 11.1-RELEASE build?).
> > > > 
> > > > Could you retry after moving the release directory in the obj
> > > > tree
> > > > out
> > > > of the way?  Everything from your release.conf looks sane
> > > > otherwise.
> > > > 
> > > Actually, at second look, it seems you are missing
> > > EMBEDDEDBUILD=1 in
> > > your release.conf.  arm/armv6 targets should not create the 'ftp'
> > > directory - the SoC u-boot loader address is baked in during the
> > > world
> > > build, making it infeasible to create the ftp bits.
> > > 
> > > Glen
> > > 
> > Except the u-boot loader address hasn't actually been used for
> > about 2
> > years in arm builds.  I don't know anything about this ftp stuff or
> > what this thread is about, but I do know that UBLDR_LOADADDR is no
> > longer used in arm builds, and thus should not be preventing
> > anything
> > else from working.
> > 
> Hmm, I thought UBLDR_LOADADDR was still used.  Good to know.
> 
> Regarding ftp, the "big-iron" builds create a ftp directory as part
> of
> the release target, which contains the distribution sets used by
> various
> things such as bootonly.iso and poudriere.
> 
> That said, should we now expect that a userland build between all
> arm/armv6 SoCs to be identical (modulo any baked-in timestamps)?
> 
> Glen
> 

Hrm.  Well apparently, UBLDR_LOADADDR is no longer needed, but it is
still used when building ubldr (not ubldr.bin), and some old uboot
scripts still refer to ubldr.  So we've got to clean those up before we
can finish eliminating UBLDR_LOADADDR.

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

Re: Error in /usr/src/release/release.sh

[Ian Lepore]

On Mon, 2017-08-14 at 13:23 +, Glen Barber wrote:
> On Mon, Aug 14, 2017 at 01:18:14PM +, Glen Barber wrote:
> > 
> > On Sat, Aug 12, 2017 at 05:12:02PM +, Bryce Edwards wrote:
> > > 
> > > When trying to build a set of RELENG/11.1 release files, I'm
> > > getting the
> > > following error (tail end of output) in the release.sh run:
> > > --
> > > > 
> > > > > 
> > > > > > 
> > > > > > Kernel build for ALLWINNER completed on Fri Aug 11 22:24:02
> > > > > > UTC 2017
> > > --
> > > make -C /usr/src/release  obj
> > > make -C /usr/src/release  ftp
> > > `ftp' is up to date.
> > This makes me think a populated release directory within ${.OBJDIR}
> > (i.e., /usr/obj/usr/src/release) already existed (perhaps from
> > a previous 11.1-RELEASE build?).
> > 
> > Could you retry after moving the release directory in the obj tree
> > out
> > of the way?  Everything from your release.conf looks sane
> > otherwise.
> > 
> Actually, at second look, it seems you are missing EMBEDDEDBUILD=1 in
> your release.conf.  arm/armv6 targets should not create the 'ftp'
> directory - the SoC u-boot loader address is baked in during the
> world
> build, making it infeasible to create the ftp bits.
> 
> Glen
> 

Except the u-boot loader address hasn't actually been used for about 2
years in arm builds.  I don't know anything about this ftp stuff or
what this thread is about, but I do know that UBLDR_LOADADDR is no
longer used in arm builds, and thus should not be preventing anything
else from working.

-- Ian

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

Re: Unable to boot 11.0-release on Unisurf Notebook

[Ian Lepore]

On Sun, 2017-03-26 at 19:30 +1100, Peter Jeremy wrote:
> On 2017-Mar-25 10:19:57 +1100, Peter Jeremy 
> wrote:
> > 
> > I've just bought a Unisurf Notebook[1] and am trying to boot it
> > from a
> > FreeBSD-11.0-RELEASE-amd64-memstick.img.  The boot starts OK but
> > hangs
> > whilst probing devices.  With safe and verbose enabled, it hangs
> > after
> > complaining about ppc0 (see https://goo.gl/photos/3e7tLWygjsQ6ayBT9
> > ).
> > At this point neither Ctrl-Alt-Del nor Ctrl-Alt-Esc have any effect
> > and
> > the only option is to hold the power button down until it powers
> > off.
> For the record, I have both good and bad news:
> The good news is that setting hint.uart.1.disabled="1" let it boot.
> The bad news is that FreeBSD-11 (I didn't try head) can't see the
> eMMC
> flash.  The worse news is that the WiFi adapter is attached to the
> SDIO.
> I've given up and returned it.
> 
> If anyone's interested, I've posted dmesg and similar information
> from both
> FreeBSD-11 and xubuntu 16.04.2 at https://www.rulingia.com/~peter/uni
> surf/
> 

Marius is currently updating our mmc/sd stack for better support of
modern emmc, there's a good chance that support will hit 11-stable in a
while.

There is also work in progress on sdio, but that's still focused on the
lower level support.  Once that infrastructure is in place, another
round of work will be needed to create the wifi drivers.

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

Re: Booting Raspberry Pi with input on serial console

[Ian Lepore]

On Fri, 2017-03-10 at 11:40 +0100, Peter Ankerstål wrote:
> Hi!
> 
> I have a problem that should (?) have a simple solution but I havent
> found one. 
> 
> I have a raspberry pi with a NMEA-GPS constantly hooked up to the
> serial console of the Pi. 
> 
> My problem is that when booting the Pi it will interpet the output
> from the GPS as input to the boot process and the boot will fail. How
> can I have the serial interface of the GPS permanently hooked up to
> the pi without preventing the system to boot?
> 
> Thanks!
> 
> /Peter.

Ideally, the fix for this would be to "setenv stdin nulldev; saveenv",
but unfortunately our copy of uboot is missing the option to include
nulldev in uboot.

I think a viable workaround for your case is probably to create a
uEnv.txt file on the fat partition of the sdcard and put in it:

 bootdelay=0
 stderr=lcd
 stdout=lcd

That will prevent uboot from stopping if the gps receiver sends some
text, and prevent uboot from sending most of its text output to the
serial port, which may confuse the gps receiver (the uboot startup
banner text still appears on the serial port tho).

-- Ian

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

Re: make buildkernel does not respect KERNCONF or JOBS in /etc/make.conf

[Ian Lepore]

On Tue, 2016-12-13 at 10:13 -0700, Ian Lepore wrote:
> On Tue, 2016-12-13 at 10:00 +, tech-lists wrote:
> > 
> > On 12/12/2016 23:40, Herbert J. Skuhra wrote:
> > > 
> > > 
> > > PORTS_MODULES does not work if KERNCONF contains multiple
> > > kernels:
> > > 
> > > The problem is obviously in /usr/src/sys/conf/kern.post.mk (line
> > > 66):
> > > 
> > > WRKDIRPREFIX?=  ${MAKEOBJDIRPREFIX}${SRC_BASE}/sys/${KERNCONF}
> > hmm! I didn't know that.
> > 
> > I can't confirm exactly when the old way stopped working and when
> > I 
> > started defining modules in src.conf.
> > 
> > If I wanted to install a known, good kernel as /boot/workingkernel
> > with 
> > all of its modules, so that I can avoid kernel.old being a bad
> > kernel 
> > and kernel being non-bootable, how would I go about doing it?
> > 
> > many thanks,
> > 
> I think the problem might have started with some changes to the
> kernel
> build infrastructure that result in reading make.conf and/or src.conf
> when they didn't used to, so now KERNCONF with multiple entries is
> defined differently in kern.post.mk than it used to be.
> 
> I wonder if this patch might fix it (I'm not in a position to test it
> myself right now -- this is purely a shot in the dark)...
> 
> iIndex: sys/conf/kern.post.mk
> ===
> --- sys/conf/kern.post.mk (revision 302505)
> +++ sys/conf/kern.post.mk (working copy)
> @@ -63,7 +63,7 @@ OSRELDATE!= awk
> '/^\#define[[:space:]]*__FreeBSD_v
>   ${MAKEOBJDIRPREFIX}${SRC_BASE}/include/osreldate
> .h
>  .endif
>  # Keep the related ports builds in the obj directory so that they
> are only rebuilt once per kernel build
> -WRKDIRPREFIX?=   ${MAKEOBJDIRPREFIX}${SRC_BASE}/sys/${KERNCONF}
> +WRKDIRPREFIX?=   ${MAKEOBJDIRPREFIX}${SRC_BASE}/sys/${.OBJDIR}
>  PORTSMODULESENV=\
>   PATH=${PATH}:${LOCALBASE}/bin:${LOCALBASE}/sbin \
>   SRC_BASE=${SRC_BASE} \
> 
> -- Ian

Actually, now that I look at it again, I wonder if it should be just:

+WRKDIRPREFIX?= ${.OBJDIR}

-- Ian

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

Re: make buildkernel does not respect KERNCONF or JOBS in /etc/make.conf

[Ian Lepore]

On Tue, 2016-12-13 at 10:00 +, tech-lists wrote:
> On 12/12/2016 23:40, Herbert J. Skuhra wrote:
> > 
> > PORTS_MODULES does not work if KERNCONF contains multiple kernels:
> > 
> > The problem is obviously in /usr/src/sys/conf/kern.post.mk (line
> > 66):
> > 
> > WRKDIRPREFIX?=  ${MAKEOBJDIRPREFIX}${SRC_BASE}/sys/${KERNCONF}
> hmm! I didn't know that.
> 
> I can't confirm exactly when the old way stopped working and when I 
> started defining modules in src.conf.
> 
> If I wanted to install a known, good kernel as /boot/workingkernel
> with 
> all of its modules, so that I can avoid kernel.old being a bad
> kernel 
> and kernel being non-bootable, how would I go about doing it?
> 
> many thanks,
> 

I think the problem might have started with some changes to the kernel
build infrastructure that result in reading make.conf and/or src.conf
when they didn't used to, so now KERNCONF with multiple entries is
defined differently in kern.post.mk than it used to be.

I wonder if this patch might fix it (I'm not in a position to test it
myself right now -- this is purely a shot in the dark)...

iIndex: sys/conf/kern.post.mk
===
--- sys/conf/kern.post.mk   (revision 302505)
+++ sys/conf/kern.post.mk   (working copy)
@@ -63,7 +63,7 @@ OSRELDATE!=   awk '/^\#define[[:space:]]*__FreeBSD_v
    ${MAKEOBJDIRPREFIX}${SRC_BASE}/include/osreldate.h
 .endif
 # Keep the related ports builds in the obj directory so that they are only 
rebuilt once per kernel build
-WRKDIRPREFIX?= ${MAKEOBJDIRPREFIX}${SRC_BASE}/sys/${KERNCONF}
+WRKDIRPREFIX?= ${MAKEOBJDIRPREFIX}${SRC_BASE}/sys/${.OBJDIR}
 PORTSMODULESENV=\
    PATH=${PATH}:${LOCALBASE}/bin:${LOCALBASE}/sbin \
    SRC_BASE=${SRC_BASE} \

-- Ian

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

Re: make buildkernel does not respect KERNCONF or JOBS in /etc/make.conf

[Ian Lepore]

On Mon, 2016-12-12 at 20:22 -0800, Kevin Oberman wrote:
> On Mon, Dec 12, 2016 at 4:20 PM, Herbert J. Skuhra  rg>
> wrote:
> 
> > 
> > Kevin Oberman skrev:
> > > 
> > > 
> > > Clearly the documentation is a bit behind the times. For some
> > > time people
> > > have used KERNCONF to build multiple kernels, but that was a
> > > lucky things
> > > that was not officially supported. It just happened to work.
> > > Then, with
> > > 11.0, it no longer did in many cases sue to changes in the kernel
> > > build
> > > system. When people complained, there did not seem to be a way to
> > > fix
> > this
> > > 
> > > without blocking future goals in speeding up and enhancinghte
> > > standard
> > > kernel build.
> > > 
> > > The result was BUILDKERNELS. It was specifically designed to
> > > allow the
> > > building of multiple kernels and the appropriate modules. This
> > > would
> > always
> > > 
> > > take longer and use more disk space, but it would work reliably.
> > > Now, bit
> > > building a single, local kernel, KERNCONF is the best way, though
> > > I
> > suspect
> > > 
> > > that it make only a small difference until new capabilities are
> > > added
> > later
> > > 
> > > in the life of 11.
> > > 
> > > So, while it seems the man pages need to catch up, building
> > > multiple
> > > kernels should be done with KERNCONF in either make.conf or
> > > src.conf and
> > > multiple kernels with BUILDKERNELS.
> > > 
> > > This is from my recollection of the discussion thread. I'll admit
> > > to
> > being
> > > 
> > > too lazy to go find and read all of it. I suspect it was on
> > > current@,
> > but
> > > 
> > > I'm not even sure of that.
> > ???
> > 
> > From /usr/src/Makefile.inc1:
> > 
> >    1137 .if ${TARGET_ARCH} == "powerpc64"
> >    1138 KERNCONF?=  GENERIC64
> >    1139 .else
> >    1140 KERNCONF?=  GENERIC
> >    1141 .endif
> >    [...]
> >    1149 BUILDKERNELS=
> >    1150 INSTALLKERNEL=
> >    1151 .if defined(NO_INSTALLKERNEL)
> >    1152 # All of the BUILDKERNELS loops start at index 1.
> >    1153 BUILDKERNELS+= dummy
> >    1154 .endif
> >    1155 .for _kernel in ${KERNCONF}
> >    1156 .if exists(${KERNCONFDIR}/${_kernel})
> >    1157 BUILDKERNELS+=  ${_kernel}
> >    1158 .if empty(INSTALLKERNEL) && !defined(NO_INSTALLKERNEL)
> >    1159 INSTALLKERNEL= ${_kernel}
> >    1160 .endif
> >    1161 .endif
> >    1162 .endfor
> > 
> > So setting BUILDKERNELS has no effect.
> > 
> > --
> > Herbert
> > 
> I think you miss the significance. BUILDKERNELS only is used to build
> the
> kernels. It is not used by installkernel as installing two kernels
> does not
> make sense. It is ONLY used to build multiple kernels. KERNCONF is
> still
> used to specify the kernel, with attendant modules, to be installed.
> 
> I should also mention that, if you want to install a new kernel
> without
> overwriting the old kernel and modules (/boot/kernel.old/), "make
> reinstallkernel". It replaces the existing kernel instead of renaming
> the
> kernel directory to kernel.old. I find this very handy, but it is
> poorly
> documented. So, if you want to install GENERIC and not lose your last
> working kernel, "make reinstallkernel KERNCONF=GENERIC". That will
> blow
> away the bad kernel and modules and install GENERIC. Note that it
> does not
> touch the /usr/obj directory that PUMPKIN is built in, so PUMPKIN and
> similarly be reinstalled.
> 
> The man page for src.conf is automatically generated and only lists
> those
> values which are specific to src.conf (WITH_ and WITHOUT_) and
> describes
> its use. It is used as input for system builds and installs but
> should not
> be accessed for any other purpose. make.conf is always read by make
> with no
> regard to what is being made. (N.B. I believe that some people have
> ignored
> this in some ports stuff.) Anything that is put into make.conf may be
> placed in src,conf if you only want to have it used when
> building/installing the kernel and world.
> 
> I'm probably forgetting something, but I hope this explains it a bit.

The BUILDKERNELS variable is part of the build system's internal
machinery for building multiple kernels when the user has set KERNCONF=
to more than one name.  It's not a thing that a user can set.

-- Ian

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

Re: leapsecond file

[Ian Lepore]

On Tue, 2016-08-23 at 22:40 -0700, Andreas Ott wrote:
> On Sun, Aug 07, 2016 at 09:44:55PM -0700, Kevin Oberman wrote:
> > On 11.0-BETA4 I have:
> > > grep expires /var/db/ntpd.leap-seconds.list
> > #File expires on:  1 Jun 2017
> > 
> > But I see what you do on 10.3-RELEASE.  Looks like the update has
> > not made
> > it into 10 (an I would guess 9).
> 
> The flaw is in the internal versioning of files, it does fetch the
> newer
> file from IETF and puts it into /var/run/ntpd.leap-seconds.list, but
> although the expiry is newer, the FreeBSD onboard source version
> claims
> to be newer in the 'last update date in NTP timestamp format' line
> ...
> 
> FreeBSD 10.3-RELEASE-p7 onboard source is in /etc/ntp/leap-seconds,
> which gets copied to /var/db/ntpd.leap-seconds.list. The fetch
> IETF file downloads to /var/run/ntpd.leap-seconds.list .
> 
> 
> [root@mon ~]# egrep -e Update\|expires\|^'#\$' /etc/ntp/leap-seconds
> #   Last Update of leap second values:  31 Dec 2015
> #$   3660508800
> #   Updated through IERS Bulletin C 50
> #   File expires on:  1 Jun 2016
> [root@mon ~]# egrep -e Update\|expires\|^'#\$' /var/db/ntpd.leap
> -seconds.list
> #   Last Update of leap second values:  31 Dec 2015
> #$   3660508800
> #   Updated through IERS Bulletin C 50
> #   File expires on:  1 Jun 2016
> [root@mon ~]# egrep -e Update\|expires\|^'#\$' /var/run/ntpd.leap
> -seconds.list
> #   Last Update of leap second values:   5 January 2015
> #$   3629404800
> #   Updated through IERS Bulletin C51
> #   File expires on:  28 December 2016
> [root@mon ~]#
> 
> with the end result that the file from /var/run/ never gets moved to
> /var/db/ .
> The 480.leapfile-ntpd used by periodic calls the same rc file fetch
> and
> comparison.
> 
> -andreas

The Last Update value reflects only additions of leap seconds to the
file, and it is specifically documented that Last Update does NOT
change when the file's expiration date is extended without changing the
other contents.

It looks like part of the problem here is that the Last Update value IS
changing when the leap data itself is not.  Our commit logs say the
files have been obtained from USNO.  Either USNO is violating the
standard in their files, or the value is getting modified before it's
commited to the freebsd repos.  (I'm adding Cy to the CC list, since he
committed them.)

It looks like the fetch/install decisions in rc.d/ntpd are not quite
right either.  Both Last Update and Expiration date have to be taken
into account.  To allow for these broken files that incorrectly change
the Last Update, workable logic would be to keep the file with the
highest Expiration date, and if the expirations are equal, then keep
the one with the highest Last Update.  (I think it would be better to
test Last Update first, then use Expiration as the tie-breaker, but
that fails with these broken files.)  Testing both Expiration and Last
Update will allow for a corrected file to be published after
accidentally publishing bad data, and we'd take the corrected file.

-- Ian

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

Re: Call for testing: VM bugs in 10.3

[Ian Lepore]

On Tue, 2016-08-02 at 22:25 +0300, Konstantin Belousov wrote:
> Below is the merge of some high-profile virtual memory subsystem bug
> fixes from stable/10 to 10.3. I merged fixes for bugs reported by
> users, issues which are even theoretically unlikely to occur in real
> world loads, are not included into the patch set. The later is mostly
> corrections for the handling of radix insertion failures. Included
> fixes
> are for random SIGSEGV delivered to processes, hangs on "vodead"
> state
> on filesystem operations, and several others.
> 
> List of the merged revisions:
> r301184 prevent parallel object collapses, fixes object lifecycle
> r301436 do not leak the vm object lock, fixes overcommit disable
> r302243 avoid the active object marking for vm.vmtotal sysctl, fixes
>   "vodead" hangs
> r302513 vm_fault() race with the vm_object_collapse(), fixes spurious
> SIGSEGV
> r303291 postpone BO_DEAD, fixes panic on fast vnode reclaim
> 
> I am asking for some testing, it is not necessary for your system to
> exhibit the problematic behaviour for your testing to be useful. I am
> more looking for smoke-testing kind of confirmation that patch is
> fine.
> Neither I nor people who usually help me with testing,  run 10.3
> systems.
> 
> If everything appear to be fine, my intent is to ask re/so to issue
> Errata Notice with these changes in about a week from now.
> 
> Index: sys/kern/vfs_subr.c
> [...]

I run 10-stable on my everyday desktop/build machine, but my mail
client ruined the format of the patches.  Can I just 'svn up' on the 10
-stable branch and then MFC the revs you list above, or are there hand
-tweaks to the patches you attached?

-- Ian

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

Re: FreeBSD 10.3 slow boot on Supermicro X11SSW-F

[Ian Lepore]

On Thu, 2016-07-14 at 20:42 +0200, Kurt Jaeger wrote:
> Hi!
> 
> > > Before: ca. 660 seconds to reboot, now 77 seconds to reboot.
> > > Now, if someone could explain, why...
> 
> > https://lists.freebsd.org/pipermail/freebsd-stable/2016-June/084865
> > .html
> 
> Any pointer to a commit or three that fixed it ?
> 

I think this is the one...

https://svnweb.freebsd.org/base?view=revision=298230

-- Ian

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

Re: Not-so stable if you take a CAM error....

[Ian Lepore]

On Mon, 2016-07-11 at 12:44 -0500, Karl Denninger wrote:
> On 7/11/2016 12:39, Ian Lepore wrote:
> > On Mon, 2016-07-11 at 12:30 -0500, Karl Denninger wrote:
> > > On 7/11/2016 11:32, Ian Lepore wrote:
> > > > On Mon, 2016-07-11 at 09:50 -0400, Brandon Allbery wrote:
> > > > > On Mon, Jul 11, 2016 at 9:46 AM, Karl Denninger <
> > > > > k...@denninger.net>
> > > > > wrote:
> > > > > 
> > > > > > Here's the backtrace ... sounds like expected behavior,
> > > > > > which
> > > > > > is
> > > > > > not-so
> > > > > > good all-in for a situation like this.  I guess the
> > > > > > strategy is
> > > > > > to
> > > > > > turn
> > > > > > off softupdates before attempting such an update so as not
> > > > > > to
> > > > > > crash
> > > > > > the
> > > > > > host machine if there's a problem with the card.
> > > > > > 
> > > > > I would tend to assume that removable media should not have
> > > > > softupdates
> > > > > enabled. Even with properly working media, it's practically
> > > > > begging
> > > > > for
> > > > > corruption.
> > > > > 
> > > > Writing to an sdcard without softupdates enabled will be an
> > > > exercise in
> > > > patience.  Like, come back next week and maybe it'll be done.
> > > > 
> > > > The only thing that comes to mind with this is maybe some sort
> > > > of
> > > > mount
> > > > flag to say you're willing to live with any amount of
> > > > filesystem
> > > > corruption in lieu of panicking.  I'm not sure how
> > > > easy/practical
> > > > that
> > > > would be to implement, though.
> > > > 
> > > > -- Ian
> > > Why not force-detach the volume that takes the error instead of a
> > > panic()?
> > > 
> > Patches welcome.
> > 
> > -- Ian
> Any hints on where the routine(s) live that would forcibly detach a
> volume?  (I'll go digging as well but shortening the time would help
> :))
> 

Your question assumes the existance of code that I don't know actually
exists.  Plug in any removable drive (like a usb thumb drive) and mount
a ufs filesystem with softupdates enabled, then remove the drive while
writing to it.  Panic.

I've always assumed that if this was easily fixable it would have been
fixed long ago, and if it was fixable at all it would have been fixed
by now.  (Although increasingly it seems that ufs has transitioned to
second-class citizenship, and lately I've even seen people mocked for
using it instead of zfs).

-- Ian

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

Re: Not-so stable if you take a CAM error....

[Ian Lepore]

On Mon, 2016-07-11 at 12:30 -0500, Karl Denninger wrote:
> On 7/11/2016 11:32, Ian Lepore wrote:
> > On Mon, 2016-07-11 at 09:50 -0400, Brandon Allbery wrote:
> > > On Mon, Jul 11, 2016 at 9:46 AM, Karl Denninger <
> > > k...@denninger.net>
> > > wrote:
> > > 
> > > > Here's the backtrace ... sounds like expected behavior, which
> > > > is
> > > > not-so
> > > > good all-in for a situation like this.  I guess the strategy is
> > > > to
> > > > turn
> > > > off softupdates before attempting such an update so as not to
> > > > crash
> > > > the
> > > > host machine if there's a problem with the card.
> > > > 
> > > I would tend to assume that removable media should not have
> > > softupdates
> > > enabled. Even with properly working media, it's practically
> > > begging
> > > for
> > > corruption.
> > > 
> > Writing to an sdcard without softupdates enabled will be an
> > exercise in
> > patience.  Like, come back next week and maybe it'll be done.
> > 
> > The only thing that comes to mind with this is maybe some sort of
> > mount
> > flag to say you're willing to live with any amount of filesystem
> > corruption in lieu of panicking.  I'm not sure how easy/practical
> > that
> > would be to implement, though.
> > 
> > -- Ian
> Why not force-detach the volume that takes the error instead of a
> panic()?
> 

Patches welcome.

-- Ian

> That would lead to a panic if the detached volume was the system
> volume
> (obviously) but for a data volume it would simply result in it being
> forcibly unmounted (and dirty, so if it's corrupt it will get caught
> when reattached.)
> 
> It seems that the current paradigm of saying "screw you, panic the
> machine" violates the principle of least astonishment and is overly
> punitive vis-a-vis necessity.  Refusing further I/O because the
> volume
> may now have a corrupt filesystem appears to be facially reasonable,
> but
> that doesn't necessarily wind up being fatal the system itself -- it
> is
> if that's the system volume and is not covered by some sort of
> redundancy, obviously, but it's not in all cases.
> 
> (Note that you can't just unmount the filesystem involved in the
> error;
> it has to be the volume that gets forcibly detached and whatever
> flows
> through from that you have to live with.  The reason is that on any
> sort
> of solid-state media the OS has zero control over zoning and write
> amplification means far more the data you were actually modifying may
> have been lost -- it's entirely possible that *several megabytes* of
> data just got trashed by the write error, and it's even possible that
> the block(s) involved cross a filesystem boundary!)
> 
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Not-so stable if you take a CAM error....

[Ian Lepore]

On Mon, 2016-07-11 at 09:50 -0400, Brandon Allbery wrote:
> On Mon, Jul 11, 2016 at 9:46 AM, Karl Denninger 
> wrote:
> 
> > Here's the backtrace ... sounds like expected behavior, which is
> > not-so
> > good all-in for a situation like this.  I guess the strategy is to
> > turn
> > off softupdates before attempting such an update so as not to crash
> > the
> > host machine if there's a problem with the card.
> > 
> 
> I would tend to assume that removable media should not have
> softupdates
> enabled. Even with properly working media, it's practically begging
> for
> corruption.
> 

Writing to an sdcard without softupdates enabled will be an exercise in
patience.  Like, come back next week and maybe it'll be done.

The only thing that comes to mind with this is maybe some sort of mount
flag to say you're willing to live with any amount of filesystem
corruption in lieu of panicking.  I'm not sure how easy/practical that
would be to implement, though.

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

Re: Not-so stable if you take a CAM error....

[Ian Lepore]

On Mon, 2016-07-11 at 06:30 -0500, Karl Denninger wrote:
> On 7/11/2016 02:57, Ronald Klop wrote:
> > On Mon, 11 Jul 2016 02:54:38 +0200, Karl Denninger
> >  wrote:
> > 
> > > Got a (nasty) surprise this afternoon on my sandbox machine.
> > > 
> > > I was updating some Raspberry Pi2 machines which involved taking
> > > the sd
> > > card out, sticking it in an adapter and plugging it into the
> > > sandbox,
> > > then mounting the partition and using rsync.
> > > 
> > > Unfortunately one of the cards was, unknown to me, bad and
> > > returned a
> > > write error during the update.
> > > 
> > > The machine panic'd immediately after the CAM write error popped
> > > up.
> > > 
> > > I was quite surprised by this, since (1) the SD card was (of
> > > course)
> > > mounted as a UFS filesystem; it shows up as a CAM device, (2) the
> > > machine itself is running off a ZFS root on a normal host-adapter
> > > and
> > > thus there is no comingling of the buffer cache and (3) there
> > > were no
> > > images being run from (can't, wrong architecture!) nor any system
> > > I/O
> > > (e.g. pagefile) going to the SD card.
> > > 
> > > I certainly understand that under some circumstances (maybe even
> > > most
> > > circumstances) taking a hard I/O error to a system device is
> > > going to
> > > hose you and a panic() is arguably "least astonishment" when the
> > > price
> > > of being wrong might be a corrupted system file or worse (e.g.
> > > corrupted
> > > paged-out RSS, etc.)  But I didn't expect a panic out a failed
> > > write to
> > > a device that is mounted and being used purely for data.
> > > 
> > > I don't have a crash dump but can almost-certainly reproduce this
> > > if
> > > it's something that shouldn't happen and thus merits
> > > investigation.
> > > 
> > 
> > Hi,
> > 
> > I understand you are surprised by this. I don't think it is the way
> > it
> > should work.
> > Is there _any_ debugging information for people to use and try to
> > help
> > you? Like which FreeBSD version are you running? Which FreeBSD
> > version
> > was used to create the UFS fs? Does it use softupdates (SU) or also
> > journaling (SU+J)?
> > Maybe some output of dmesg? Or type of SD-card and reader. Other
> > people might have similar problems with similar hardware.
> > 
> > Regards,
> > Ronald.
> > 
> FreeBSD 11.0-BETA1 #0 r302489: Sat Jul  9 10:15:24 CDT 2016
> k...@newfs.denninger.net:/usr/obj/usr/src/sys/KSD-SMP
> 
> and
> 
> FreeBSD 11.0-BETA1 #0 r302526: Sun Jul 10 10:39:31 CDT 2016
> k...@newfs.denninger.net:/pics/CrossBuild/obj/arm.armv6/pics/CrossBui
> ld/src/sys/RPI2
> 
> Both blew up in the same way when stimulated with same I/O error.
> 
> The filesystem in question does have softupdates enabled (the RPI
> images
> have it turned on by default) but no journaling.  It's not
> card/reader
> dependent no architecture dependent; when it occurred the first time
> I
> stuck the card and reader into one of my Pis and attempted to update
> it
> there (thinking that perhaps my sandbox machine's USB port was wonky)
> and it blew up the Pi2 in the exact same way.
> 
> This isn't (obviously, given both Intel-style and ARM machines being
> involved) architecture dependent.
> 
> It's been a good long while since I took an actual hard I/O error
> that
> was 'visible' at the OS level (I've had plenty of disks die on ZFS
> over
> last few years but no "double failures" on a mirror or similar, and I
> on
> my servers I haven't had a UFS-based system for a while.  This
> definitely looks like some sort of regression in the code; I've run
> FreeBSD for a hell of a long time and have had plenty of instances
> where
> disks have failed without having the machine go out from under me.
> 

Unfortunately, this is "just the way it works".  A hard IO error while
writing to a ufs filesystem with softupdates enabled will cause a
panic, because the softupdates code doesn't handle that sort of
failure, and the failure means that filesystem integrity is lost.  The
code has no idea how important the data is to the functioning of the
system, no basis on which to decide whether to panic or not.

-- Ian

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

Re: unbound and ntp issuse

[Ian Lepore]

On Tue, 2016-06-07 at 12:10 +0100, krad wrote:
> whops that should be
> 
> ntpdate_hosts not servers
> 

These suggestions are essentially insane because they're ignoring the
basic fact that the freebsd installer creates a non-working system.  If
unbound requires DNSSEC, and DNSSEC requires good time, and good time
requires hostname resolution, then that circular dependency is a
problem that the freebsd project needs to fix, not something to be
hacked around by each individual sysadmin.

It is a bit disturbing to me that the project members who created this
situation have been silent in the face of *months* of reporting of it
by several different users.

-- Ian

> 
> On 7 June 2016 at 12:09, krad  wrote:
> 
> > something as simple as this thrown in /etc/periodic/daily/ would
> > probably
> > do it.
> > 
> > #!/bin/sh
> > ip=`dig pool.ntp.org +short | head -1'
> > cp /etc/hosts /etc/hosts.old &&
> >  sed -e "s/.*ntp-server/$ip ntp-server/"  /etc/hosts.old >
> > /etc/hosts
> > 
> > 
> > with these lines in rc.conf
> > ntpdate_enable=yes
> > ntpdate_servers="ntp-server"
> > 
> > 
> > 
> > 
> > 
> > On 7 June 2016 at 11:43, Slawa Olhovchenkov  wrote:
> > 
> > > On Tue, Jun 07, 2016 at 11:35:59AM +0100, krad wrote:
> > > 
> > > > Like i said you could configure ntpdate as well as ntpd, but
> > > > give it a
> > > > known good ip. It will only run once at boot, and ntpd will
> > > > start after
> > > so
> > > > that can use the nice pool names.
> > > > 
> > > > A slightly better way maybe to give ntpdate a server hostname
> > > > like
> > > > ntp-server and populated the hosts file with one of the ips
> > > > from
> > > > pool.ntp.org. You could then have a periodic script to check
> > > > and
> > > update the
> > > > ip in the hosts every day, so it works over a reboot. The ip
> > > > would
> > > > obviously have to have an initial seed value, but you could
> > > > work this
> > > out
> > > > progmatically at system configuration time with tools like
> > > > ansible.
> > > 
> > > What purpose don't do it by standart scripts from base systems?
> > > Enforcing DNSSEC must be prevent this strange works on all
> > > systems
> > > lack CMOS time.
> > > 
> > > I am not expert in sh scripting for this automation.
> > > 
> > > > On 7 June 2016 at 09:47, Slawa Olhovchenkov 
> > > > wrote:
> > > > 
> > > > > On Tue, Jun 07, 2016 at 09:00:29AM +0100, krad wrote:
> > > > > 
> > > > > > Well there is a deadlock situation there so you have to
> > > > > > relax one
> > > of the
> > > > > > conditions, for one time at least.
> > > > > > 
> > > > > > Your best bet is to do a manual ntpdate against a fixed ip
> > > > > > of known
> > > > > > goodness. If you have a lot of machines you need to do this
> > > > > > on, use
> > > > > ansible
> > > > > > or similar to do the heavy lifting for you. Ansible is best
> > > > > > in my
> > > opinion
> > > > > > if you dont have anything setup as its quick to get going.
> > > > > > It does
> > > > > require
> > > > > > python on the target machines so you would need to install
> > > > > > that
> > > first.
> > > > > > Something like the following should get it working (as you
> > > > > > dont
> > > have dns
> > > > > on
> > > > > > the target machine, package fetches wont work, so i would
> > > > > > tunnel a
> > > squid
> > > > > > proxy and let that handle all the internet stuff.
> > > > > > 
> > > > > > add something like the following to your ssh_config
> > > > > > 
> > > > > > Host *
> > > > > > RemoteForward 31280 squid_server:3128
> > > > > > 
> > > > > > then run some stuff like this (after installing ansible on
> > > > > > your
> > > > > > desktop/bastion host)
> > > > > > 
> > > > > > ansible  -b -m raw -a '/usr/bin/env ASSUME_ALWAYS_YES=1
> > > > > > http_proxy=
> > > > > > http://127.0.0.1:31280 /usr/sbin/pkg bootstrap -f' -u root 
> > > > > > -i
> > > > > >  -kS --ask-su-pass
> > > > > > 
> > > > > > ansible  -b -m raw -a 'env ASSUME_ALWAYS_YES=YES
> > > > > > http_proxy=
> > > > > > http://127.0.0.1:31280 pkg install python' -u root -i
> > > 
> > > > > > -kS --ask-su-pass
> > > > > > 
> > > > > > ansible -m shell -a "ntpdate "  -kS
> > > --ask-su-pass -i
> > > > > > 
> > > > > > 
> > > > > > from here on you should be able to start unbound and then
> > > > > > ntpd eg
> > > > > > 
> > > > > > ansible -m service -a "name=local_unbound state=restarted"
> > > > > >  -kS --ask-su-pass -i 
> > > > > > ansible -m service -a "name=ntpd state=restarted"  -kS
> > > --ask-su-pass -i
> > > > > >  > > > > > 
> > > > > > Alternatively you could just relax your dnssec rules on
> > > > > > first boot
> > > to
> > > > > give
> > > > > > ntp a chance. Probably much easier 8)
> > > > > 
> > > > > How I am do it? I am don't touch dnssec rules and don't know
> > > > > unbound.
> > > > > May be this is posible by startup scripts?
> > > > > Also, some platforms lack of CMOS time, RPi, for example.
> > > > > 
> > > > > > Also make sure you are 

Re: DISPLAY not set inside jails after update to 10.3-PRERELEASE FreeBSD 10.3-PRERELEASE #4 r297043

[Ian Lepore]

On Sat, 2016-03-19 at 13:48 +0800, Erich Dollansky wrote:
> Hi,
> 
> nothing else was changed on the machine except the update. I could
> use
> 
> ssh 192.168.12.12
> 
> to connect to a jail running under that IP address before the update
> without problems.
> 
> It works now only with
> 
> ssh -Y 192.168.12.12
> 
> The /etc/ssh/ssh_config file says:
> 
> Host *
> ForwardX11 yes
> 
> So, it should allow to connect to all machines providing ssh and
> forward X11.
> 
> What did I miss?
> 
> Erich

If -Y works, the ssh config file option that corresponds to that is
ForwardX11Trusted.  ForwardX11 corresponds to -X.  (Not sure what
changed, just throwing out the one little crumb of info I've got.)

-- Ian

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

Re: releng/10.3 rc netwait disabled by ipfw dependency

[Ian Lepore]

On Sat, 2016-03-12 at 16:46 +1100, John Marshall wrote:
> I recently upgraded a server from 10.2-RELEASE to 10.3-RC2.  The
> server
> has ipfw configured and also has netwait enabled in rc.conf.  All was
> good in 10.2-RELEASE.
> 
> Now, rc pauses during netwait for the full ${netwait_timeout} failing
> to
> ping ${netwait_ip}, prints a WARNING about the network likely not
> being
> properly up, then proceeds to enable the firewall and start other
> components with varying degrees of success (now that the interfaces
> can
> pass packets and has started configuring itself - think IPv6 SLAAC).
> The netwait rc script used to "REQUIRE: NETWORKING", until r294680
> when
> (among other things) this happened...
> 
>  # PROVIDE: netwait
> -# REQUIRE: NETWORKING
> +# REQUIRE: devd routing
>  # KEYWORD: nojail
> 
> Adding ipfw to the netwait REQUIRE list makes things work for me (see
> Bug 207916) but I am sure there is more that ought to be taken into
> account and perhaps the dependency ought to be resolved in a
> different
> way.
> 

Just a quick followup for the archives, this was turned into PR 207916
and a workaround was committed as r296807.  A better fix, I think,
would be to separate waiting for the network interfaces to appear from
waiting for network connectivity to be functional (ping test), but I
ran into some circular-dependency problems, so I committed a "good
enough for now" workaround.

-- Ian

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

Re: [Solved] Problems with ucom/uftdi and sendfax on 10.2 p12 (works like a charm with 7.4)

[Ian Lepore]

On Wed, 2016-03-09 at 21:21 +, Holger Kipp wrote:
> Dear Ian,
> 
> > On 02.03.2016, at 11:45, Holger Kipp <holger.k...@alogis.com>
> > wrote:
> > 
> > 
> > Am 01.03.2016 um 23:08 schrieb Ian Lepore <i...@freebsd.org > i...@freebsd.org>>:
> > 
> > On Tue, 2016-03-01 at 19:58 +, Holger Kipp wrote:
> > Hi all,
> > 
> > I currently encounter a problem with sending faxes with new server
> > and FreeBSD 10.2-RELEASE p12
> > using mgetty+sendfax and RS232-Modems via USB to RS232-Adapter
> > (com,
> > uftdi).
> > 
> > Problem is that _after_ sending the first page, the reply of modem
> > is
> > not read correctly.
> > 
> > In Error case, Faxlog says:
> > 
> > 02/29 18:46:10 aU4read 64, write 64
> > 02/29 18:46:10 aU4read 52, write 52
> > 02/29 18:46:10 aU4  page complete, 40900 bytes sent
> > 02/29 18:46:10 aU4  sending DLE ','
> > 02/29 18:46:10 aU4got:[0a][0d][0a]OK[0d]
> > 02/29 18:46:18 aU4  got response: 'OK'
> > 02/29 18:46:18 aU4   fax_send_page("f2.g3") started...
> > 02/29 18:46:18 aU4   tio_set_flow_control( HARD )
> > 02/29 18:46:18 aU4  fax_send: 'AT+FDT'
> > 02/29 18:46:18 aU4  fax_wait_for(CONNECT)
> > 02/29 18:46:18 aU4got:[0a]
> > 02/29 18:48:18 aU4  Warning: got alarm signal!
> > 
> > So I run into timeout because the modem does not reply as expected
> > after AT+FDT-command (maybe even after sending DLE ',‘ because the
> > OK
> > response seems to take some more time than under FreeBSD 7.4).
> > 
> > 
> > if I issue "tip modem4" (which is /dev/cuaU4), I get the missing
> > replies including CONNECT from the modem (then leaving tip with
> > "~.“)
> > 
> > root@faxserver:/usr/local/etc/mgetty+sendfax # tip modem4
> > connected
> > AT+FDT
> > CONNECT
> > 
> > +FHS:43
> > 
> > OK
> > AT+FCLASS=0
> > OK
> > ~
> > [EOT]
> > root@faxserver:/usr/local/etc/mgetty+sendfax #
> > 
> > 
> > This works correctly with same modems and USB to RS232-Adapter
> > (uftdi) under FreeBSD 7.4.
> > 
> > 02/29 12:18:26 aU4  receiver cap.: '+FIS:1,5,0,2,1,1,0,3' -> fine
> > 144
> > 2D/MR ECM** found **
> > 02/29 12:18:26 aU4  sendfax: IGNORE DCD (carrier) status
> > 02/29 12:18:26 aU4  fax_send: 'AT+FDT'
> > 02/29 12:18:26 aU4  fax_wait_for(CONNECT)
> > 02/29 12:18:33 aU4  transmission par.: '+FCS:1,5,0,2,0,0,0,3'**
> > found
> > **
> > 02/29 12:18:33 aU4  sending f1.g3...
> > 02/29 12:19:04 aU4  page complete, 34495 bytes sent
> > 02/29 12:19:04 aU4  sending DLE ','
> > 02/29 12:19:10 aU4  got response: 'OK'
> > 02/29 12:19:10 aU4  fax_send: 'AT+FDT'
> > 02/29 12:19:10 aU4  fax_wait_for(CONNECT)** found **
> > 02/29 12:19:11 aU4  sending f2.g3...
> > 02/29 12:19:55 aU4  page complete, 60064 bytes sent
> > 02/29 12:19:55 aU4  sending DLE ','
> > 02/29 12:20:01 aU4  got response: 'OK'
> > 02/29 12:20:01 aU4  fax_send: 'AT+FDT'
> > 02/29 12:20:01 aU4  fax_wait_for(CONNECT)** found **
> > 02/29 12:20:01 aU4  sending f3.g3...
> > 02/29 12:20:52 aU4  page complete, 71335 bytes sent
> > 02/29 12:20:52 aU4  sending DLE ','
> > 02/29 12:20:57 aU4  got response: 'OK'
> > 02/29 12:20:57 aU4  fax_send: 'AT+FDT'
> > 02/29 12:20:57 aU4  fax_wait_for(CONNECT)** found **
> > 02/29 12:20:58 aU4  sending f4.g3...
> > 02/29 12:21:40 aU4  page complete, 58628 bytes sent
> > 02/29 12:21:40 aU4  sending DLE '.'
> > 02/29 12:21:49 aU4  connection hangup: '+FHS:00'
> > 02/29 12:21:49 aU4  got response: 'OK'
> > 02/29 12:21:49 aU4  fax_send: 'AT+FCLASS=0'
> > 
> > This is with devolo 56k i ISDN-modems, but it looks more like a USB
> > interface communication issue to me.
> > 
> > Modems and USB-to-RS232 are the same - connected to FreeBSD 7.4
> > servers works (sends all pages), connected to 10.2 server does not
> > work (sends first page only).
> > 
> > I can also provide dmesg.boot details on request but didn’t want to
> > pollute the list.
> > 
> > Difference with stty -a /dev/cuaU4 seems to be clocal instead of
> > -clocal which I can’t set for cuaU4, only for .init and .lock.
> > which
> > does not help.
> > 7.4 Kernel comes with uftdi and ucom compiled in.
> > 10.2 Kernel has the same issues with ucom and uftdi loaded as
> > kernel
> > modules or compiled in.
> > 
> > mgetty+sendfax is version 1.1.35_1 on FreeBSD 7.4 and version
> > 1.1.37
> > on FreeBSD 10.2-RELEASE

Re: PPS input on a generic GPIO pin on Raspberry Pi.

[Ian Lepore]

On Fri, 2016-03-04 at 10:54 -0600, Karl Denninger wrote:
> On 3/3/2016 12:57, Peter Ankerstål wrote:
> > Hi!
> > 
> > I have sort of exactly the same question as Erik:
> > http://lists.freebsd.org/pipermail/freebsd-questions/2014-July/2590
> > 55.html
> > 
> > I have bought a https://learn.adafruit.com/adafruit-ultimate-gps an
> > d want to use the PPS output to discipline my clock.
> > 
> > But the only source of information on how PPS works in FreeBSD I
> > could find is this: 
> > https://docs.freebsd.org/doc/8.0-RELEASE/usr/share/doc/ntp/pps.html
> >  and it clearly states the two ways to provide a PPS signal. "The
> > PPS signal can be connected in either of two ways: via the data
> > carrier detector (DCD) pin of a serial port or via the acknowledge
> > (ACK) pin of a parallel port”
> > 
> > Since the Pi doesn’t have any DCD pin i would like to use a generic
> > GPIO for this. There is a linux kernel module for this: http://lxr.
> > free-electrons.com/source/drivers/pps/clients/pps-gpio.c?v=3.6
> GPIO is supported on the Pi, I'm using it on 11-Current on my home
> control software to drive relays on my pool hardware (e.g. valves,
> heater, VFD motor drive, etc) and it is working very well.  I don't
> believe tapping into that at the kernel level to expose a pps signal
> (e.g. on /dev/pps or something of the like) would be very difficult
> at
> all, since the low-level driver capability is already present.
> 
> If I get some free time I'll dig around a bit and see if I can cobble
> something up.  It's of some interest to me as well since I have a GPS
> clock here that currently talks to a serial port on an Intel-based
> machine and being able to move that to a $35 "appliance" for NTP
> using
> the Adafruit setup looks sort of attractive given that the Pi plus
> the
> module would be under $100 all-in.
> 

Don't "cobble something up" just yet... there is "a right way" to fix
this, which is a generic gpio-pps driver.  The problem is that it
requires support from the new INTRNG, and the rpi hasn't been converted
to that yet.  I'm checking around to see if someone has done the
conversion for rpi and it just hasn't been reveiwed/committed yet; if
not, I guess I'll try to do it myself.

Writing the actual gpio-pps driver will be pretty quick and easy once
we have the intrng support, I think it'll take me a couple hours.

Also, FYI, another option with PPS is to use a usb-serial adapter and
feed the PPS in on the CTS or DCD pin.  I tested that on rpi a few
months ago and it worked fine.  There's surpisingly little jitter even
when the usb bus is heavily loaded with other traffic such as disk or
network IO.

-- Ian

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

Re: Problems with ucom/uftdi and sendfax on 10.2 p12 (works like a charm with 7.4)

[Ian Lepore]

On Tue, 2016-03-01 at 19:58 +, Holger Kipp wrote:
> Hi all,
> 
> I currently encounter a problem with sending faxes with new server
> and FreeBSD 10.2-RELEASE p12
> using mgetty+sendfax and RS232-Modems via USB to RS232-Adapter (com,
> uftdi).
> 
> Problem is that _after_ sending the first page, the reply of modem is
> not read correctly.
> 
> In Error case, Faxlog says:
> 
> 02/29 18:46:10 aU4read 64, write 64
> 02/29 18:46:10 aU4read 52, write 52
> 02/29 18:46:10 aU4  page complete, 40900 bytes sent
> 02/29 18:46:10 aU4  sending DLE ','
> 02/29 18:46:10 aU4got:[0a][0d][0a]OK[0d]
> 02/29 18:46:18 aU4  got response: 'OK'
> 02/29 18:46:18 aU4   fax_send_page("f2.g3") started...
> 02/29 18:46:18 aU4   tio_set_flow_control( HARD )
> 02/29 18:46:18 aU4  fax_send: 'AT+FDT'
> 02/29 18:46:18 aU4  fax_wait_for(CONNECT)
> 02/29 18:46:18 aU4got:[0a]
> 02/29 18:48:18 aU4  Warning: got alarm signal!
> 
> So I run into timeout because the modem does not reply as expected
> after AT+FDT-command (maybe even after sending DLE ',‘ because the OK
> response seems to take some more time than under FreeBSD 7.4).
> 
> 
> if I issue "tip modem4" (which is /dev/cuaU4), I get the missing
> replies including CONNECT from the modem (then leaving tip with "~.“)
> 
> root@faxserver:/usr/local/etc/mgetty+sendfax # tip modem4
> connected
> AT+FDT
> CONNECT
> 
> +FHS:43
> 
> OK
> AT+FCLASS=0
> OK
> ~
> [EOT]
> root@faxserver:/usr/local/etc/mgetty+sendfax #
> 
> 
> This works correctly with same modems and USB to RS232-Adapter
> (uftdi) under FreeBSD 7.4.
> 
> 02/29 12:18:26 aU4  receiver cap.: '+FIS:1,5,0,2,1,1,0,3' -> fine 144
> 2D/MR ECM** found **
> 02/29 12:18:26 aU4  sendfax: IGNORE DCD (carrier) status
> 02/29 12:18:26 aU4  fax_send: 'AT+FDT'
> 02/29 12:18:26 aU4  fax_wait_for(CONNECT)
> 02/29 12:18:33 aU4  transmission par.: '+FCS:1,5,0,2,0,0,0,3'** found
> **
> 02/29 12:18:33 aU4  sending f1.g3...
> 02/29 12:19:04 aU4  page complete, 34495 bytes sent
> 02/29 12:19:04 aU4  sending DLE ','
> 02/29 12:19:10 aU4  got response: 'OK'
> 02/29 12:19:10 aU4  fax_send: 'AT+FDT'
> 02/29 12:19:10 aU4  fax_wait_for(CONNECT)** found **
> 02/29 12:19:11 aU4  sending f2.g3...
> 02/29 12:19:55 aU4  page complete, 60064 bytes sent
> 02/29 12:19:55 aU4  sending DLE ','
> 02/29 12:20:01 aU4  got response: 'OK'
> 02/29 12:20:01 aU4  fax_send: 'AT+FDT'
> 02/29 12:20:01 aU4  fax_wait_for(CONNECT)** found **
> 02/29 12:20:01 aU4  sending f3.g3...
> 02/29 12:20:52 aU4  page complete, 71335 bytes sent
> 02/29 12:20:52 aU4  sending DLE ','
> 02/29 12:20:57 aU4  got response: 'OK'
> 02/29 12:20:57 aU4  fax_send: 'AT+FDT'
> 02/29 12:20:57 aU4  fax_wait_for(CONNECT)** found **
> 02/29 12:20:58 aU4  sending f4.g3...
> 02/29 12:21:40 aU4  page complete, 58628 bytes sent
> 02/29 12:21:40 aU4  sending DLE '.'
> 02/29 12:21:49 aU4  connection hangup: '+FHS:00'
> 02/29 12:21:49 aU4  got response: 'OK'
> 02/29 12:21:49 aU4  fax_send: 'AT+FCLASS=0'
> 
> This is with devolo 56k i ISDN-modems, but it looks more like a USB
> interface communication issue to me.
> 
> Modems and USB-to-RS232 are the same - connected to FreeBSD 7.4
> servers works (sends all pages), connected to 10.2 server does not
> work (sends first page only).
> 
> I can also provide dmesg.boot details on request but didn’t want to
> pollute the list.
> 
> Difference with stty -a /dev/cuaU4 seems to be clocal instead of 
> -clocal which I can’t set for cuaU4, only for .init and .lock. which
> does not help.
> 7.4 Kernel comes with uftdi and ucom compiled in.
> 10.2 Kernel has the same issues with ucom and uftdi loaded as kernel
> modules or compiled in.
> 
> mgetty+sendfax is version 1.1.35_1 on FreeBSD 7.4 and version 1.1.37
> on FreeBSD 10.2-RELEASE p12.
> 
> Any other ideas where to look further or what to investigate?
> 
> Many thanks and best regards,
> Holger

Seeing "tio_set_flow_control( HARD )>" in your output, along with the
fact that you said the expected output finally appeared after you
connected with tip, makes me suspect that flow control is at the root
of this problem.

The biggest ftdi driver difference before/after freebsd 8 is that the
driver used to automatically re-intialize the chip on every open to set
up some arbitrary combination of comms parameters (baud, flow control,
etc) -- I forget all the details now, I'd have to do some digging
through logs to find exactly what it used to set.  Now the driver
leaves the chip alone at open time, and the contents of the
/dev/cuaU#.init and cuaU#.lock files should be completely in control of
the serial parameters.

Is it possible that you set up the .init and/or .lock devices in some
rc script in freebsd 7 and forgot about it?  If not, then maybe the
driver init changes are enough to explain the glitch.

I wonder if this would fix it:

  stty -f /dev/cuaU4.init crtscts

If so, then put that command into an rc script, or maybe into a devd
rule that runs whenever that usb-serial is attached.

If not... then I guess we'll 

Re: Segmentation fault running ntpd

[Ian Lepore]

On Wed, 2015-11-04 at 17:49 -0800, Doug Hardie wrote:
> > On 4 November 2015, at 08:15, Mark Martinec <
> > mark.martinec+free...@ijs.si> wrote:
> > 
> > Upgrading 10.2-RELEASE-p6 to 10.2-RELEASE-p7 now solved ntpd
> > crashes
> > (apparently fixed by: FreeBSD Errata Notice FreeBSD-EN-15:20.vm).
> > 
> > Thanks!!!
> > 
> >  Mark
> > 
> 
> ntpdc hangs when you do a peers command on 9.3.  Eventually it
> returns a no response from the server.  However, ntpq works just fine
> and nagios is able to get the status without problems.  Both of those
> did not work properly before.
> 
> — Doug

The protocol used by ntpdc is no longer supported by ntpd, and that
change came along for the ride with the security and bugfixes that were
recently merged back to the 9 and 10 branches.

Everything that can be done with ntpdc on older releases can now be
done using ntpq with the new release.  The ntpdc program itself is
still present so that you can still administer remote servers running
older code, since they won't be able to do everything via ntpq.

-- Ian

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

Re: ntpd and router with a *lot* of addresses

[Ian Lepore]

On Wed, 2015-10-21 at 01:47 +0300, Dmitry Morozovsky wrote:
> Dear colleagues,
> 
> Yesterday we'd found/stepped on a bit of trouble: on some of our
> FreeBSD-based 
> routers (hundreds of vlans, etc):
> 
> Oct 20 22:12:46  gwn4 ntpd[86421]: ntpd 4.2.4p5-a (1)
> Oct 20 22:12:46  gwn4 ntpd[86422]: Too many sockets in use,
> FD_SETSIZE 1024 exceeded
> 
> Actually, machine has to listen on 123 on just 2-3 interfaces (two
> upstream 
> vlans and lo0), but googling leads me just to -L option which is not
> described 
> in the manual page nor seams to work (I did not look at the sources
> yet 
> though).
> 
> Is there any way to restrict interfaces on which ntpd is listening
> (modulo 
> jail, which has another/orthogonal set of restrictions)?
> 
> As usual -- thanks in advance! :)
> 
> 

The -L option is in the manpage.  Looking at the code, the way ntp
4.2.4p5 decides whether an interface is virtual is by looking for a
colon in the name (a comment in the 4.2.8 source uses "eth0:1" as an
example).

An option that is not in the manpage but should work with 4.2.4p5 is to
allow it to listen on only one interface with -I, such as "-I re0". 
 But that doesn't help your needs much because it appears you can only
list one interface in 4.2.4p5.

If you update to ntp 4.2.8 (the version in ports and standard now in
freebsd 10.2 and later) you can use the -I option multiple times to
make it listen on some exact set of interfaces.

-- Ian

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

Re: Will 10.2 also ship with a very stale NTP?

[Ian Lepore]

On Fri, 2015-08-21 at 08:51 +0200, Harald Schmalzbauer wrote:
  Bezüglich Ian Lepore's Nachricht vom 21.08.2015 00:34 (localtime):
  On Fri, 2015-07-24 at 15:19 +0200, Harald Schmalzbauer wrote:
   Bezglich Ian Lepore's Nachricht vom 12.07.2015 17:41 (localtime):
  And let's all just hope that a week or two of testing is enough when
  jumping a major piece of software forward several years in its
  independent evolution.
  …
  I wonder how many other such things could be lurking in 4.2.8, waiting
  to be triggered by other peoples' non-stock configurations?  We've
  …
 
  I'd like to report one, most likely an upstream problem:
 
  'restrict' definitions in ntp.conf(5) no longer work with unqualified DNS 
  names.
  A line like
  restrict time1 nomodify nopeer noquery notrap
  results in:
  ntpd[1913]: line 7 column 7 syntax error, unexpected T_Time1
  ntpd[1913]: syntax error in /etc/ntp.conf line 7, column 7
 
  I've always been using unqualified hostnames with 'restrict', and since 
  defining 'server' with unqualified hostname still works, this seems to be 
  a significant bug to me. People are forced to change 'restrict' 
  definitions, but not to also change other unqualified definitions, which 
  potentially leads to misconfigurations, since intentionally matching 
  definitions can now differ easily.
 
  Has anybody already noticed this problem? And any idea if upstream is 
  aware?
  I had a quick look at this today.  It appears that the problem isn't
  unqualified names exactly, but rather an unqualified name that exactly
  matches an ntp.conf keyword will be mistaken by the ntpd config parser
  as a misplaced keyword token.  So most unqualified names should work,
  but there are about 200 words that won't, many of them very sensible
  names for ntp servers such as ntp and time1 and time2.
 
  When I look at the ntp_parser.y grammar file it's not clear to me why
  server time1 works and restrict time1 doesn't.  I couldn't find any
  way to trick it into taking a keyword as a hostname following restrict
  (like using quotes).
 
 Thank you very much! This is very interesting and exactly matches my
 tested host names.
 I wish I had better C skills to find such things myself. Out of
 curiosity: How much time took it to find the ntp_parser.y route? (and
 with what “IDE”  I'm stuck with vim)
 
 One additional observation was that the reserved-name-collision only
 happens with CNAME records.
 I hope I'll find some time to actually do look into sources - which I
 didn't at first hand because of my lousy C skills :-( But that's the
 place where to find hints :-)
 
 Thanks,
 

I started out pretty sure what I was going to discover, based on the
error you reported syntax error, unexpected T_Time1.  That 'T_Time1'
just said to me that's a yacc/bison token constant, this is going to be
an error in their grammar (.y) file.  The tricky part is that the .y
file isn't in the base source code, I had to go find it in the vendor
branch.

I don't think the CNAME part matters.  I tried changing my 'ntp' CNAME
to a regular A record and the error still happens if I use it as an
unqualified name with restrict.

The IDE I use is SlickEdit, running on freebsd under the linuxulator.
It's a commercial product worth every penny I've paid for various
versions since the 90s. It gets the credit for a lot of my productivity.

-- Ian


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

Re: Will 10.2 also ship with a very stale NTP?

[Ian Lepore]

On Fri, 2015-07-24 at 15:19 +0200, Harald Schmalzbauer wrote:
  Bezglich Ian Lepore's Nachricht vom 12.07.2015 17:41 (localtime):
  And let's all just hope that a week or two of testing is enough when
  jumping a major piece of software forward several years in its
  independent evolution.
 …
  I wonder how many other such things could be lurking in 4.2.8, waiting
  to be triggered by other peoples' non-stock configurations?  We've
 …
 
 I'd like to report one, most likely an upstream problem:
 
 'restrict' definitions in ntp.conf(5) no longer work with unqualified DNS 
 names.
 A line like
 restrict time1 nomodify nopeer noquery notrap
 results in:
 ntpd[1913]: line 7 column 7 syntax error, unexpected T_Time1
 ntpd[1913]: syntax error in /etc/ntp.conf line 7, column 7
 
 I've always been using unqualified hostnames with 'restrict', and since 
 defining 'server' with unqualified hostname still works, this seems to be a 
 significant bug to me. People are forced to change 'restrict' definitions, 
 but not to also change other unqualified definitions, which potentially leads 
 to misconfigurations, since intentionally matching definitions can now differ 
 easily.
 
 Has anybody already noticed this problem? And any idea if upstream is aware?

I had a quick look at this today.  It appears that the problem isn't
unqualified names exactly, but rather an unqualified name that exactly
matches an ntp.conf keyword will be mistaken by the ntpd config parser
as a misplaced keyword token.  So most unqualified names should work,
but there are about 200 words that won't, many of them very sensible
names for ntp servers such as ntp and time1 and time2.

When I look at the ntp_parser.y grammar file it's not clear to me why
server time1 works and restrict time1 doesn't.  I couldn't find any
way to trick it into taking a keyword as a hostname following restrict
(like using quotes).

You might be able to work around it using the new restrict source
syntax that applies the restrictions to every server association that
doesn't have a more-explicit matching restrict line.

-- Ian


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

Re: 10.2: ntp update breaks DCF77 clock

[Ian Lepore]

On Sun, 2015-08-16 at 08:10 +0100, Matthew Seaman wrote:
 On 15/08/2015 16:46, Christian Weisgerber wrote:
  The ntp code is not very transparent, but I think the root cause
  are the ntp/config.h changes that came with the 4.2.8p3 update.  A
  number of previously disabled obscure clock drivers were enabled,
  but crucially CLOCK_RAWDCF was disabled, and this is the PARSE
  subdriver needed to use the popular DCF77 serial receivers.
  
  Frankly, it looks like we used to have a carefully considered
  selection of clock drivers which has been blindly splattered with
  the upstream defaults in the last update.
 
 Hmmm I suggest raising a PR with patches to revert the changes in
 the set of enabled clock drivers (or merge with the current list).  It's
 not going to get you a working DCF77 receiver in a -RELEASE version any
 time soon, I'm afraid, as you'll have to wait until the next release for
 the changes to percolate down, but having a sensible list of enabled
 clock drivers in base is definitely a good move.
 

I wonder: is there a reason to not enable all (or most of) the refclocks
in base and in ports?  Well, at least all the ones that build on
freebsd... a disturbing number of them fail to compile because they
include linux-specific header files.  Hmm, I just noticed that we
actually compile most of the refclocks, but we don't enable them in the
config.

It looks like the cost of enabling all the refclocks that compile
properly is pretty small... doing so increased the size of ntpd from
745K to 801K for me.  I'll attach the diff just to save someone else the
trouble of iteratively figuring out which ones won't build, but I think
there may be a more-proper way to generate this config by tweaking the
autotools stuff.

-- Ian

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

Re: 8-stable crashing recently in ufsdirhash

[Ian Lepore]

On Tue, 2015-08-04 at 23:54 -1000, parv wrote:
 Please CC me as I cannot properly use my laptop, Thinkpad X200 (i386).
 
 8-stable has been crashing a lot since source update of Jul 2015[0]. After 
 building debug kernel, kgdb shows lock reversal order  in ufsdirhash. File 
 systems (/, var, misc) are all UFS, with var  misc having soft updates 
 enabled.
 
 Crash had happened just after boot (during mktemp); when I tried to delete a 
 directory (/misc/obj); when I tried to edit (vi /etc/fstab) so that / would 
 be mounted readonly. Most recent crash ...
 
 http://imagebin.ca/v/2B50NARvIHsH
 
 Any clue would be appreciated.
 
   - parv
 
 
 [0] crash also happened while svn was trying to update source of 8. Now svn 
 log wants to connect to the remote repo instead of showing the current 
 revision.
 

When you say you built a debug kernel, does that include option
WITNESS_KDB?  If so, remove that so you can find the real error.  LORs
related to ufs_dirhash have been reported for years, and nobody with the
appropriate skills seems to be interested in fixing them; they just get
declared to be harmless.  (IMO the spewage related to this makes witness
essentially useless.)

-- Ian

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

Re: struct timehands: th_generation field

[Ian Lepore]

On Thu, 2015-07-23 at 10:59 -0400, Brandon Allbery wrote:
 On Thu, Jul 23, 2015 at 10:38 AM, deco33...@yandex.com wrote:
 
  Is the maximum value for th_generation equal to 10 ?
  http://fxr.watson.org/fxr/source/kern/kern_tc.c?v=FREEBSD10#L77
 
 
 I don't think those relate to generations. Generations change on every
 clock tick; the multiple timehands structs relate to forcibly setting the
 time, as opposed to the clock moving forward normally. It does appear serve
 a similar purpose, since forcibly setting the time is even more violent
 (to anything currently reading the clock) than advancing the clock on a
 clock tick, since that's when other adjustments including possibly
 switching the clock source will be applied.
 

Ummm, no.  The multiple timehands and related generation count are all
about time moving forward normally, and doing so without needing mutxes
or other locking primitives to obtain the current time.  I think you
guys need to read this...

  http://phk.freebsd.dk/pubs/timecounter.pdf

Especially the section named Locking, lack of...

-- Ian


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

Re: Will 10.2 also ship with a very stale NTP?

[Ian Lepore]

On Mon, 2015-07-13 at 04:31 +1000, Peter Jeremy wrote:
 On 2015-Jul-12 09:41:43 -0600, Ian Lepore i...@freebsd.org wrote:
 And let's all just hope that a week or two of testing is enough when
 jumping a major piece of software forward several years in its
 independent evolution.
 
 Whilst I support John's desire for NTP to be updated, I also do not
 think this is the appropriate time to do so.  That said, the final
 decision is up to re@.
 
 The import of 4.2.8p2 several months ago resulted in complete failure of
 timekeeping on all my arm systems.  Just last week I tracked it down to
 a kernel bug (which I haven't committed the fix for yet).  While the bug
 has been in the kernel for years, it tooks a small change in ntpd
 behavior to trigger it.
 
 Granted it's an odd corner-case problem that won't affect most users
 because they just use the stock ntp.conf file (and it only affects
 systems that have a large time step due to no battery-backed clock).
 But it took me weeks to find enough time to track down the cause of the
 problem.
 
 I'm not using the stock ntp.conf on my RPis and didn't notice any NTP
 issues.  Are you able to provide more details of either the ntp.conf
 options that trigger the bug or the kernel bug itself?  A quick search
 failed to find anything.
 

I just committed the kernel fix as r285424; the commit message has some
info on why the new ntpd made the problem visible.

I should have said stock rc.conf and ntp.conf... To get the problem to
happen you've got to set rc.conf ntpd_sync_on_start=NO and allow ntpd to
make a large step (-g without -q, or tinker panic 0).  I don't remember
why I had sync on start disabled on most of my arm systems (probably a
one-time experiment that I forgot to undo and it got copied around), but
I suspect most people who don't have battery clocks will have it set to
yes, and that's why nobody else saw this problem.

To me, the problem was mainly illustrative of how a tiny innocuous
change (ntpd making a series of ntp_adjtime() calls in a different, but
still correct, order than it used to) can expose a completely unexpected
longstanding bug in our code.  Gotta wonder if any more of those are
lurking. :/

-- Ian




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

Re: Will 10.2 also ship with a very stale NTP?

[Ian Lepore]

And let's all just hope that a week or two of testing is enough when
jumping a major piece of software forward several years in its
independent evolution.

The import of 4.2.8p2 several months ago resulted in complete failure of
timekeeping on all my arm systems.  Just last week I tracked it down to
a kernel bug (which I haven't committed the fix for yet).  While the bug
has been in the kernel for years, it tooks a small change in ntpd
behavior to trigger it.

Granted it's an odd corner-case problem that won't affect most users
because they just use the stock ntp.conf file (and it only affects
systems that have a large time step due to no battery-backed clock).
But it took me weeks to find enough time to track down the cause of the
problem.

I wonder how many other such things could be lurking in 4.2.8, waiting
to be triggered by other peoples' non-stock configurations?  We've
already had one report for 4.2.8p3 of someone's GPS refclock not working
after the update.

-- Ian

On Sun, 2015-07-12 at 18:49 +0900, Tomoaki AOKI wrote:
 Wow! Thanks for your time and quick response.
 I'm looking forward to seeing it MFCed. :-)
 
 On Sun, 12 Jul 2015 08:56:26 +
 Xin LI delp...@gmail.com wrote:
 
  I've spent some time on the MFC, the testing would still take some time
  (likely a day or two) and once that's finished I'll ask re@ for approval.
  On Sat, Jul 11, 2015 at 11:44 PM Tomoaki AOKI junch...@dec.sakura.ne.jp
  wrote:
  
   As I already mentioned in another post, head has 4.2.8 p3 in-tree.
  
   So the answer should be MFC before creation of releng/10.2 is planned
   or not.
  
  
   On Sun, 12 Jul 2015 15:04:43 +1000
   Peter Jeremy pe...@rulingia.com wrote:
  
On 2015-Jul-11 23:22:56 -0400, Chris Nehren 
   cnehren+freebsd-sta...@pobox.com wrote:
On Sat, Jul 11, 2015 at 09:58:11 +1000, John Marshall wrote:
 It's me again with my annual NTP whinge.

The answer to the perennial will release $foo ship with old / insecure
/ otherwise deficient $bar? is still install $bar from ports.
   
That's a non-answer.  It just changes the question to why bother to
include $bar in base when I need to install the port anyway.
   
--
Peter Jeremy
  
  
   --
   Tomoaki AOKIjunch...@dec.sakura.ne.jp
   ___
   freebsd-stable@freebsd.org mailing list
   http://lists.freebsd.org/mailman/listinfo/freebsd-stable
   To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
  
  ___
  freebsd-stable@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-stable
  To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
  
 
 


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

Re: How do I build a brand new /etc?

[Ian Lepore]

On Tue, 2015-05-26 at 22:20 -0400, kpn...@pobox.com wrote:
 So, I built a new 9.3-p14 with these commands:
 
 #! /bin/sh
 
 set -x
 export DESTDIR=/ROOT/in_progress/
 export MAKEOBJDIRPREFIX=$DESTDIR/usr/obj
 
 cd $DESTDIR/usr/src
 
 make buildworld 
 make buildkernel
 
 
 Then as root I:
make installkernel 
make installworld
 
 ... with DESTDIR and MAKEOBJDIRPREFIX set in the environment.
 
 This gave me a nearly full install. The only thing lacking is the new
 /etc. The /etc in the $DESTDIR contains the usual 20+ subdirectories,
 but no files. 
 
 How do I populate an empty /etc?
 

make distribution

-- Ian


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

Re: Adaptec 7805H drivers

[Ian Lepore]

On Mon, 2015-04-20 at 09:53 +1200, Phil Murray wrote:
 Hi,
 
 I have a few Adaptec 7805H HBA cards which FreeBSD doesn’t support natively. 
 However Adaptec have provided binary drivers for FreeBSD 9.2 (9.3 and 10.x 
 support sadly absent).
 
 The problem I have is with the GENERIC kernel the compiled in ahd driver 
 tries to attach to the controller and fails. This prevents the pmspcv 
 (Adaptec binary) driver from working.
 
 I’d like to keep using GENERIC for freebsd-update etc., so is there a way I 
 can stop the ahd driver from trying to attach without rebuilding the kernel? 
 Perhaps change their priority or precedence somehow?
 
 Is porting the open source Linux driver to FreeBSD a possibility? 
 
 Cheers
 
 Phil

Try setting hw.ahd.0.disabled=1 in /boot/loader.conf.

-- Ian


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

Re: umcs (4-Port-USB-serial) triggering way too much ehci IRQs

[Ian Lepore]

On Tue, 2013-09-17 at 17:38 +0200, Harald Schmalzbauer wrote:
 Bezüglich Hans Petter Selasky's Nachricht vom 17.09.2013 11:24
 (localtime):
  On 09/17/13 11:06, Harald Schmalzbauer wrote:
  ...
  Shall we switch to non-list-comm?
 
  Hi,
 
  That's OK.
 
  Hmm, in my case, this 4-port-serial-USB-hub will be used as console
  concentrator. So most time it's doing nothing, just feeding tmux with
  consoles output. What latency are we talking about? Less than a some
  milliseconds should be fine.
  What I'm curious about is why my prolific USB-serial converter doesn't
  generate these high irqs.
 
  Try this patch and see what happens:
 
  ==
  --- umcs.c(revision 255492)
  +++ umcs.c(local)
  @@ -230,6 +230,7 @@
   .bufsize = 0,/* use wMaxPacketSize */
   .callback = umcs7840_intr_callback,
   .if_index = 0,
  +.interval = 20, /* ms */
   },
   };
 
 
  BTW: I see that the umcs driver shouldn't do synchronous control
  transfers from the USB interrupt transfer callback. This should be
  postponed into some worker thread, for example the USB explore thread.
  See USB audio driver for an example.
 
  --HPS
 
 I tried your patch and it works as expected: IRQs decreased to ~64/s
 when idle/disconnected.
 
 One interesting thing I never measured before:
 Console connection with 115k2 via umcs and 'while ( 21 ) echo ---...
 end' results in 8000 irqs/s :-( But that's also true for the prolific
 (uplcom). The latter just goes down to 0.0 irqs/s when idle.
 
 Doing the same with uart0 results in 1444irqs/s.
 Is it by design/unavoidable that transfering the same via USB multiplies
 by factor 5-6?
 
 Thanks,
 
 -Harry
 

I don't know about that chipset, but with the FTDI chips it does xfers
in 64 byte chunks and high speed bulk data results in an astronomical
number of interrupts (and if you go fast enough, lost data).  I have
some patches that assemble lots of the little chip-size buffers into
bigger xfers that the ohci/ehci controller can handle without
interrupting the processor; that helps the problem a bunch.

-- Ian


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

Re: umcs (4-Port-USB-serial) triggering way too much ehci IRQs

[Ian Lepore]

On Tue, 2013-09-17 at 19:32 +0200, Harald Schmalzbauer wrote:
 Bezüglich Ian Lepore's Nachricht vom 17.09.2013 18:16 (localtime):
  On Tue, 2013-09-17 at 17:38 +0200, Harald Schmalzbauer wrote:
  ...
  Try this patch and see what happens:
 
  ==
  --- umcs.c(revision 255492)
  +++ umcs.c(local)
  @@ -230,6 +230,7 @@
   .bufsize = 0,/* use wMaxPacketSize */
   .callback = umcs7840_intr_callback,
   .if_index = 0,
  +.interval = 20, /* ms */
   },
   };
 
 
  BTW: I see that the umcs driver shouldn't do synchronous control
  transfers from the USB interrupt transfer callback. This should be
  postponed into some worker thread, for example the USB explore thread.
  See USB audio driver for an example.
 
  --HPS
  I tried your patch and it works as expected: IRQs decreased to ~64/s
  when idle/disconnected.
 
  One interesting thing I never measured before:
  Console connection with 115k2 via umcs and 'while ( 21 ) echo ---...
  end' results in 8000 irqs/s :-( But that's also true for the prolific
  (uplcom). The latter just goes down to 0.0 irqs/s when idle.
 
  Doing the same with uart0 results in 1444irqs/s.
  Is it by design/unavoidable that transfering the same via USB multiplies
  by factor 5-6?
 
  Thanks,
 
  -Harry
 
  I don't know about that chipset, but with the FTDI chips it does xfers
  in 64 byte chunks and high speed bulk data results in an astronomical
  number of interrupts (and if you go fast enough, lost data).  I have
 
 According to ASIX product brief, MCS7840 has 512 byte buffer. Pretty
 much for an UART I think, which should make 115k2 baud connections  with
 less than 30 transfers/s work, or am I missing something?

That's the internal buffer, it still does usb transfers in smaller
chunks.  Some ftdi chips have 4k onboard buffers but do 64-byte usb
transfers.

-- Ian


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

Re: umcs (4-Port-USB-serial) triggering way too much ehci IRQs

[Ian Lepore]

On Tue, 2013-09-17 at 23:08 +0400, Lev Serebryakov wrote:
 Hello, Harald.
 You wrote 17 сентября 2013 г., 21:43:17:
 
 HS Is that worth a try?
 HS 
 http://www.asix.com.tw/FrootAttach/driver/MCS7840_7820_FreeBSD_driver_v1.1.zip
   Nope. I've started from this driver, and it even doesn't support BREAK
  signal (it is was first reason why I start to write new one -- I needed
  BREAK to enter kernel debugger).
 
 HS At least, it seems to be possible to enable RS485-mode :-) :-)
   I could easily add RS485 mode, BUT! FreeBSD doesn;'t have any userland API
  for it, and the same is true for higher and non-standard baud rates.

There's no API needed for higher baud rates.  I've used cfsetspeed() to
set 3mbps on ftdi chips.   I've also used it for completely arbitrary
speeds like 554000bps (happens to be the fastest I can run an ftdi chip
on a 180mhz arm without dropping chars, but going that fast requires
other changes to the driver.).

-- Ian




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

Re: gmirror crash writing to disk? Or is it su+j crash?

[Ian Lepore]

On Fri, 2013-08-30 at 21:50 +0200, Edward Tomasz Napierała wrote:
 Wiadomość napisana przez Zaphod Beeblebrox zbee...@gmail.com w dniu 29 sie 
 2013, o godz. 23:35:
  So I have a system running:
  
  FreeBSD walk.dclg.ca 9.2-RC3 FreeBSD 9.2-RC3 # r254952: Wed Aug 28 03:02:55
  EDT 2013 r...@walk.dclg.ca:/usr/obj/usr/src/sys/STRIKE  i386
  
  and it has two 2T SATA disks.  To keep this post short, the crash.txt is
  here.
  
  https://uk.eicat.ca/owncloud/public.php?service=filest=fea9d25579fe0c4afb808859e80e1493
 
 Login error.
 
  now curiously, while running a make -j4 buildkernel ... almost every time
  ... it crashes with:
  
  g_vfs_done():mirror/walke[WRITE(offset=516764794880, length=65536)]error =
  11
  /usr: got error 11 while accessing filesystem
  panic: softdep_deallocate_dependencies: unrecovered I/O error
 
 This is softupdates panic caused by write operation returning error 11, which,
 according to 'man errno', is EDEADLK.
 
 To be honest, I have no idea why gmirror might be returning this error.
 
  ... no error report from the hard drives, simply an error report from the
  mirror.
 
 Note that ahci(4) does not log errors unless you're running with bootverbose.
 
  The filesystem is ufs with su+j... but I'm not sure this matters here.
 
 It does, kind of - without soft updates/SUJ, the error would be non-fatal - it
 wouldn't panic the box, but it would (probably) cause data corruption.

One of the few places in the kernel that uses EDEADLK is in geom_io.c
(line 642 in -current) in g_io_transient_map_bio()...

g_io_deliver(bp, EDEADLK/* XXXKIB */);

-- Ian


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

Re: system sporadically hangs on shutdown after switching to WITH_NEW_XORG

[Ian Lepore]

On Sun, 2013-06-16 at 09:07 -0700, Jeremy Chadwick wrote:
 On Sun, Jun 16, 2013 at 06:01:49PM +0200, Michiel Boland wrote:
  On 06/16/2013 17:55, Jeremy Chadwick wrote:
  [...]
  
  Are you running moused(8)?  Actually, I can see quite clearly that you
  are in your core.txt:
  
  Starting ums0 moused.
  
  Try turning that off.  Don't ask me how, because devd(8) / devd.conf(5)
  might be involved.
  
  
  The moused is started by devd - I don't see a quick way of turning that off.
 
 Comment out the relevant crap in devd.conf(5).  Search for ums
 and comment out the two notify sections.

I don't understand why people treat devd as if it's some sort of evil
virus that they're forced to live with (using phrases like crap in
devd.conf).  In general, the standard devd rules tend to fall into 3
categories:  
  * use logger(1) to record some anomaly
  * kldload a module
  * invoke a standard /etc/rc.d script

For moused, the devd rules invoke /etc/rc.d/moused, which implies that
setting moused_enable=NO in rc.conf would be all that's needed to
disable it.

-- Ian


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

Re: 9.1-stable: ATI IXP600 AHCI: CAM timeout

[Ian Lepore]

On Wed, 2013-05-29 at 16:21 +0200, Oliver Fromme wrote:
 Steven Hartland wrote:
   Have you checked your sata cables and psu outputs?
   
   Both of these could be the underlying cause of poor signalling.
 
 I can't easily check that because it is a cheap rented
 server in a remote location.
 
 But I don't believe it is bad cabling or PSU anyway, or
 otherwise the problem would occur intermittently all the
 time if the load on the disks is sufficiently high.
 But it only occurs at tags=3 and above.  At tags=2 it does
 not occur at all, no matter how hard I hammer on the disks.
 
 At the moment I'm inclined to believe that it is either
 a bug in the HDD firmware or in the controller.  The disks
 aren't exactly new, they're 400 GB Samsung ones that are
 several years old.  I think it's not uncommon to have bugs
 in the NCQ implementation in such disks.
 
 The only thing that puzzles me is the fact that the problem
 also disappears completely when I reduce the SATA rev from
 II to I, even at tags=32.
 

It seems to me that you dismiss signaling problems too quickly.
Consider the possibilities... A bad cable leads to intermittant errors
at higher speeds.  When NCQ is disabled or limited the software handles
these errors pretty much transparently.  When NCQ is not limitted and
there are many outstanding requests, suddenly the error handling in the
software breaks down somehow and a minor recoverable problem becomes an
in-your-face error.

I'm not saying any of the foregoing is true, just that you should
consider the possibility that you're dealing with multiple problems
which are only loosely coupled, but together can seem like a single more
serious problem.  You don't know enough yet to casually dismiss
anything.

-- Ian


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

Re: ada(4) and ahci(4) quirk printing

[Ian Lepore]

On Wed, 2013-04-24 at 11:59 -0700, Adrian Chadd wrote:
 I think this just outlines the problem - bootverbose is too verbose.
 
 eg, what the audio code outputs. And yes, net80211 when you're doing 11n.
 

I agree that the sound driver(s) output Too Much Stuff with bootverbose,
so much so that it makes bootverbose kind of useless for other things.
It would be nice if its output could be trimmed, and the fully-verbose
spewage we see now would need some extra knob turned.

More directly on-point to the overall thread, I think printing an extra
line of info that gives more detail about how drives and controllers are
being handled is a Good Idea.  It's one extra line, one-time during
boot.

-- Ian


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

Re: 9-STABLE buildworld compile error

[Ian Lepore]

On Tue, 2013-04-02 at 14:28 +0300, Dmitry Luhtionov wrote:
 When I put MALLOC_PRODUCTION=yes in /etc/make/conf, make buildworld hangs
 with error
 /usr/src/lib/libc/stdlib/
 malloc.c:126:1: error: MALLOC_PRODUCTION redefined
 command-line: error: this is the location of the previous definition
 
 This is a patch, which avoid this error
 
 --- /usr/src/lib/libc/stdlib/Makefile.inc.orig2012-12-04
 11:53:28.0 +0200
 +++ /usr/src/lib/libc/stdlib/Makefile.inc2013-04-02 14:14:35.0
 +0300
 @@ -51,7 +51,3 @@
  malloc.3 realloc.3 malloc.3 reallocf.3 malloc.3 malloc_usable_size.3
  MLINKS+=tsearch.3 tdelete.3 tsearch.3 tfind.3 tsearch.3 twalk.3
 
 -.if defined(MALLOC_PRODUCTION)
 -CFLAGS+=-DMALLOC_PRODUCTION
 -.endif
 -

That's because MALLOC_PRODUCTION is already defined in -stable.  

The right fix would be to remove it from your make.conf, because it's no
longer necessary in -current either -- the performance problems that
originally led to the advice to put MALLOC_PRODUCTION in make.conf for
-current have been fixed.

-- Ian


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

Re: Any objections/comments on axing out old ATA stack?

[Ian Lepore]

On Thu, 2013-03-28 at 09:17 +0200, Alexander Motin wrote:
 On 28.03.2013 02:43, Adrian Chadd wrote:
  My main concern with the new stuff is that it requires CAM and that's
  reasonably big compared to the standalone ATA code.
 
  It'd be nice if we could slim down the CAM stack a bit first; it makes
  embedding it on the smaller devices really freaking painful.
 
 Are there many boards now with ATA, but without USB? But I agree, it 
 should be checked.
 

It's not necessarily what the boards have but how they're used.  We use
industrial SBCs at work that have ata compact flash sockets on the board
which we do use, and usb interfaces which we don't use.

I've never tested the new ata+cam stuff on some of these boards, most
based on Cyrix, Via, Geode, and VortexD86 chipsets.  The older ata code
works, but not always very well -- for example, we usually have to set
hw.ata.ata_dma=0 for absolutely no reason we've ever been able to figure
out except that if we leave it enabled we get DMA errors and panics on
some CF cards and not on others.  I have no idea whether to expect such
things to be better, worse, or no different by changing to the ata+cam
way of doing things (but I don't really have time to do extensive
testing right now either).

-- Ian


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

Re: FreeBSD 9.1 excessive memory allocations

[Ian Lepore]

On Tue, 2013-03-26 at 11:35 -0700, Unga wrote:
 Hi all
 
 
 I have a heavily threaded C application, developed on an Intel Core i5 laptop 
 (2 cores) running FreeBSD 8.1-RELEASE.
 
 When this application compile and run on another Intel Core i7 laptop (4 
 cores) running FreeBSD 9.1-RELEASE, this application immediately starts 
 grabbing memory by over 100MB per second and soon exit with not enough RAM.
 
 
 Both laptops having 4GB RAM.
 
 All malloc and free are mutex locked.
 
 Very rarely this problem happens on the i5 (2 cores) laptop too, but on the 
 i7 laptop, it happens every time.
 
 Appreciate any feedback to identify and fix this issue.
 
 Best regards
 Unga
 

Too many moving parts, you need to partition the problem.  Is it the
change in OS (and especially libraries) that causes the problem, or the
change in the number of cores (more concurrent threads) is exposing some
sort of application-side race condition?  Given the fact that it does
occur on 2 cores + freebsd 8.1, even if more rarely, it's almost surely
an application problem.  

Perhaps you could use a tool such as valgrind to help track down the
runaway allocations?

Another way to expose thread race problems is to force more thread
context switches.  A blunt tool for doing so is to set hz=5000 or even
higher in /boot/loader.conf.  I've never done that on a desktop or
laptop system, only on embedded systems, but it should still work okay.
If changing the application code is easier, you can get a similar effect
by creating a thread whose only job is to preempt other threads, by
using rtprio_thread() to set it to real time priority, then just have it
sleep for short random intervals (microseconds), all it does is wakes up
and goes right back to sleep.

Also, FYI, there's no need to use a mutex in your application to protect
allocations.  The memory allocator in libc is thread-safe, and in fact
is particularly designed for efficient multi-threaded allocation.

-- Ian


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

Re: FreeBSD 9.1 excessive memory allocations [SOLVED]

[Ian Lepore]

On Wed, 2013-03-27 at 11:33 -0700, Unga wrote:
 
 - Original Message -
 
  From: Ian Lepore i...@freebsd.org
  To: Unga unga...@yahoo.com
  Cc: freebsd-stable@freebsd.org freebsd-stable@FreeBSD.org
  Sent: Wednesday, March 27, 2013 2:06 PM
  Subject: Re: FreeBSD 9.1 excessive memory allocations
  
  On Tue, 2013-03-26 at 11:35 -0700, Unga wrote:
   Hi all
  
  
   I have a heavily threaded C application, developed on an Intel Core i5 
  laptop (2 cores) running FreeBSD 8.1-RELEASE.
  
   When this application compile and run on another Intel Core i7 laptop (4 
  cores) running FreeBSD 9.1-RELEASE, this application immediately starts 
  grabbing 
  memory by over 100MB per second and soon exit with not enough RAM.
  
  
   Both laptops having 4GB RAM.
  
   All malloc and free are mutex locked.
  
   Very rarely this problem happens on the i5 (2 cores) laptop too, but on 
  the 
  i7 laptop, it happens every time.
  
   Appreciate any feedback to identify and fix this issue.
  
   Best regards
   Unga
  
  
  Too many moving parts, you need to partition the problem.  Is it the
  change in OS (and especially libraries) that causes the problem, or the
  change in the number of cores (more concurrent threads) is exposing some
  sort of application-side race condition?  Given the fact that it does
  occur on 2 cores + freebsd 8.1, even if more rarely, it's almost surely
  an application problem.  
  
  Perhaps you could use a tool such as valgrind to help track down the
  runaway allocations?
  
  Another way to expose thread race problems is to force more thread
  context switches.  A blunt tool for doing so is to set hz=5000 or even
  higher in /boot/loader.conf.  I've never done that on a desktop or
  laptop system, only on embedded systems, but it should still work okay.
  If changing the application code is easier, you can get a similar effect
  by creating a thread whose only job is to preempt other threads, by
  using rtprio_thread() to set it to real time priority, then just have it
  sleep for short random intervals (microseconds), all it does is wakes up
  and goes right back to sleep.
  
  Also, FYI, there's no need to use a mutex in your application to protect
  allocations.  The memory allocator in libc is thread-safe, and in fact
  is particularly designed for efficient multi-threaded allocation.
  
  -- Ian
 
 
 Dear Tony, Alexander, Jan, Ian and Jeremy
 
 Thank you very much for your very valuable comments.
 
 Problem seems to be solved. But require more testing.
 
 1. Fixed an application-level crucial bug. This is nearly a 7000 lines C app. 
 It was really hard to see as the application is designed with 8 dedicated 
 threads.
 
 2. At run-time, this application shoots up to about 400 dynamic threads on 
 the i7 machine, whereas on the i5 machine, it only shoots up 57 dynamic 
 threads. It was bit scaring, therefore, made a hard limit on total number of 
 threads to 64.
 
 Regarding mutex locks on allocations, as per the malloc(3), it says small and 
 medium size allocations are done from per thread caches, therefore, 
 thread-safe. My allocations are large in nature, about 5-7MB.
 
 Best regards
 Unga

I think you may be reading too much into the malloc manpage.  When it
mentions the use of per-thread small-object caches to avoid locking it's
talking about performance, not thread safety.  Allocations of all sizes
are thread-safe, the library just assumes that huge allocations are rare
enough that it doesn't use extra per-thread resources to avoid locking
for them, it just uses locking for huge blocks.

-- Ian


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

Re: svn commit: r247485 - in stable/9: crypto/openssh crypto/openssh/openbsd-compat secure/lib/libssh secure/usr.sbin/sshd

[Ian Lepore]

On Sat, 2013-03-02 at 17:02 +0100, Dag-Erling Smørgrav wrote:
 Mike Tancsa m...@sentex.net writes:
  The pcaps and basic wireshark output at
 
  http://tancsa.com/openssh/
 
 This is 6.1 with aesni vs 6.1 without aesni; what I wanted was 6.1 vs
 5.8, both with aesni loaded.
 
 Could you also ktrace the server in both cases?
 
 An easy workaround is to change the list of ciphers the server will
 offer to clients by adding a Ciphers line in /etc/ssh/sshd_config.
 The default is:
 
 Ciphers 
 aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour
 
 Either remove the AES entries or move them further down the list.  The
 client will normally pick the first supported cipher.  As far as I can
 tell, SecureCRT supports all the same ciphers that OpenSSH does, so just
 moving arcfour{256,128} to the front of the list should work.
 
 (AFAIK, arcfour is also much faster than aes)

The last time I tried to affect the chosen cypher by manipulating the
order of the list items in the config files was a couple years ago, but
I found then that you just can't do that.  The client side, not the
server, decides on the order, and it's based on compiled-in ordering
within the client code (not the client config).  From the server side
the only thing you can do to affect the order is leave items out of the
list (it will still try the remaining list items in the client-requested
order).

All of this was with OpenSSH_5.4p1_hpn13v11 FreeBSD-20100308, OpenSSL
0.9.8q 2 Dec 2010 and may be completely out of date now.

-- Ian


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

Re: svn - but smaller?

[Ian Lepore]

On Sun, 2013-02-24 at 16:04 -0800, Jeremy Chadwick wrote:
 On Sun, Feb 24, 2013 at 04:43:33PM -0700, Ian Lepore wrote:
  On Sun, 2013-02-24 at 13:24 -0800, Jeremy Chadwick wrote:
   On Sun, Feb 24, 2013 at 10:19:57AM -0700, Ian Lepore wrote:
On Sat, 2013-02-23 at 22:31 -0800, Jeremy Chadwick wrote:
 
 Also, John, please consider using malloc(3) instead of heap-allocated
 buffers like file_buffer[6][] (196608 bytes) and command[] (32769
 bytes).  I'm referring to this: 

Why?  I absolutely do not understand why people are always objecting to
large stack-allocated arrays in userland code (sometimes with the
definition of large being as small as 2k for some folks).
   
   This is incredibly off-topic, but I'll bite.
   
   I should not have said heap-allocated, I was actually referring to
   statically-allocated.
   
   The issues as I see them:
   
   1. Such buffers exist during the entire program's lifetime even if they
   aren't actively used/needed by the program.  With malloc(3) and friends,
   you're allocating memory dynamically, and you can free(3) when done with
   it, rather than just having a gigantic portion of memory allocated
   sitting around potentially doing nothing.
   
   2. If the length of the buffer exceeds the amount of stack space
   available at the time, the program will run but the behaviour is unknown
   (I know that on FreeBSD if it exceeds stacksize per resource limits,
   the program segfaults at runtime).  With malloc and friends you can
   gracefully handle allocation failures.
   
   3. Statically-allocated buffers can't grow; meaning what you've
   requested size-wise is all you get.  Compare this to something that's
   dynamic -- think a linked list containing pointers to malloc'd memory,
   which can even be realloc(3)'d if needed.
   
   The definition of what's too large is up to the individual and the
   limits of the underlying application.  For some people, sure, anything
   larger than 2048 might warrant use of malloc.  I tend to use malloc for
   anything larger than 4096.  That magic number comes from some piece of
   information I was told long ago about what size pages malloc internally
   uses, but looking at the IMPLEMENTATION NOTES section in malloc(3) it
   appears to be a lot more complex than that.
   
   If you want me to break down #1 for you with some real-world output and
   a very small C program, showing you the effects on RES/RSS and SIZE/VIRT
   of static vs. dynamic allocation, just ask.
   
  
  Actually, after seeing that the userland limit for an unpriveleged user
  on freebsd is a mere 64k, I'd say the only valid reason to not allocate
  big things on the stack is because freebsd has completely broken
  defaults.
 
 The limits (i.e. what's shown via limits(1)) differs per architecture
 (ex. i386 vs. amd64) and may adjust based on amount of physical memory
 available (not sure on the latter part).  The 64k value you're talking
 about, I think, is memorylocked -- I'm referring to stacksize.
 
  I see no reason why there should even be a distinction
  between stack size and memory use limits in general.  Pages are pages,
  it really doesn't matter what part of your virtual address space they
  live in.
 
 You're thinking purely of SIZE/VIRT.
 
 I guess I'd best break the C program out.  Apologise in advance for the
 crappy code (system(3)!), but I wanted something that made the task
 easy.
 
 $ limits -a
 Resource limits (current):
   cputime  infinity secs
   filesize infinity kB
   datasize  2621440 kB
   stacksize  262144 kB
   coredumpsize infinity kB
   memoryuseinfinity kB
   memorylocked   64 kB
   maxprocesses 5547
   openfiles   11095
   sbsize   infinity bytes
   vmemoryuse   infinity kB
   pseudo-terminals infinity
   swapuse  infinity kB
 
 $ cat x.c
 #include stdio.h
 #include stdlib.h
 #include sys/types.h
 #include unistd.h
 #include string.h
 
 #define SIZE_MFATTY   512*1024*1024   /* 512MB */
 #define SIZE_SFATTY   128*1024*1024   /* 128MB; must be smaller than limits 
 stacksize! */
 
 int main(int argc, char *argv[]) {
   char procstat[BUFSIZ];
   char topgrep[BUFSIZ];
   pid_t mypid;
   char *mfatty;
   char sfatty[SIZE_SFATTY];
 
   sfatty[0] = '\0';   /* squelch gcc unused var warning */
 
   mypid = getpid();
 
   snprintf(procstat, sizeof(procstat),
   procstat -v %u, mypid);
   snprintf(topgrep, sizeof(topgrep),
   top -b 9 | egrep '^(Mem:|[ ]+PID|[ ]*%u)', mypid);
 
   printf(at startup\n);
   printf(\n);
   system(topgrep);
   printf(-\n);
   system(procstat);
   sleep(5);
 
   mfatty = malloc(SIZE_MFATTY);
   printf(\n);
   printf(after malloc mfatty\n);
   printf(=\n);
   system(topgrep

Re: svn - but smaller?

[Ian Lepore]

On Sat, 2013-02-23 at 22:31 -0800, Jeremy Chadwick wrote:
 
 Also, John, please consider using malloc(3) instead of heap-allocated
 buffers like file_buffer[6][] (196608 bytes) and command[] (32769
 bytes).  I'm referring to this: 

Why?  I absolutely do not understand why people are always objecting to
large stack-allocated arrays in userland code (sometimes with the
definition of large being as small as 2k for some folks).

-- Ian


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

Re: svn - but smaller?

[Ian Lepore]

On Sun, 2013-02-24 at 13:24 -0800, Jeremy Chadwick wrote:
 On Sun, Feb 24, 2013 at 10:19:57AM -0700, Ian Lepore wrote:
  On Sat, 2013-02-23 at 22:31 -0800, Jeremy Chadwick wrote:
   
   Also, John, please consider using malloc(3) instead of heap-allocated
   buffers like file_buffer[6][] (196608 bytes) and command[] (32769
   bytes).  I'm referring to this: 
  
  Why?  I absolutely do not understand why people are always objecting to
  large stack-allocated arrays in userland code (sometimes with the
  definition of large being as small as 2k for some folks).
 
 This is incredibly off-topic, but I'll bite.
 
 I should not have said heap-allocated, I was actually referring to
 statically-allocated.
 
 The issues as I see them:
 
 1. Such buffers exist during the entire program's lifetime even if they
 aren't actively used/needed by the program.  With malloc(3) and friends,
 you're allocating memory dynamically, and you can free(3) when done with
 it, rather than just having a gigantic portion of memory allocated
 sitting around potentially doing nothing.
 
 2. If the length of the buffer exceeds the amount of stack space
 available at the time, the program will run but the behaviour is unknown
 (I know that on FreeBSD if it exceeds stacksize per resource limits,
 the program segfaults at runtime).  With malloc and friends you can
 gracefully handle allocation failures.
 
 3. Statically-allocated buffers can't grow; meaning what you've
 requested size-wise is all you get.  Compare this to something that's
 dynamic -- think a linked list containing pointers to malloc'd memory,
 which can even be realloc(3)'d if needed.
 
 The definition of what's too large is up to the individual and the
 limits of the underlying application.  For some people, sure, anything
 larger than 2048 might warrant use of malloc.  I tend to use malloc for
 anything larger than 4096.  That magic number comes from some piece of
 information I was told long ago about what size pages malloc internally
 uses, but looking at the IMPLEMENTATION NOTES section in malloc(3) it
 appears to be a lot more complex than that.
 
 If you want me to break down #1 for you with some real-world output and
 a very small C program, showing you the effects on RES/RSS and SIZE/VIRT
 of static vs. dynamic allocation, just ask.
 

Actually, after seeing that the userland limit for an unpriveleged user
on freebsd is a mere 64k, I'd say the only valid reason to not allocate
big things on the stack is because freebsd has completely broken
defaults.  I see no reason why there should even be a distinction
between stack size and memory use limits in general.  Pages are pages,
it really doesn't matter what part of your virtual address space they
live in.

Almost everything I've ever done with freebsd runs as root on an
embedded system, so I'm not used to thinking in terms of limits at all.

-- Ian

[P.S. Having mail troubles today, sorry if this gets duplicated.]


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

Re: Why can't gcc-4.2.1 build usable libreoffice?

[Ian Lepore]

On Tue, 2013-02-19 at 09:23 -0800, Adrian Chadd wrote:
 Hi,
 
 The base compiler is supposed to compile base and bootstrap whatever
 else you need to compile other software.
 
 It's not supposed to be continuously updated to new, major versions. :-)
 
 I bet *office just uses a bunch of either horrible syntax that breaks
 things, or newer C/C++ features that are buggy in older compilers.
 They could've made their code compile on older compilers.. they just
 haven't bothered.
 
 In any case, why hasn't that port been blessed with the requires gcc
 4.6+ port option/dependency? I thought that's why we _have_ that.

It has been.  The OP stated the he disabled that and forced use of gcc
4.2.1, and is now complaining that it doesn't work after specifically
taking steps to make it not-work.

-- Ian


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

Re: Why can't gcc-4.2.1 build usable libreoffice?

[Ian Lepore]

On Tue, 2013-02-19 at 13:03 -0500, Mikhail T. wrote:
 On 19.02.2013 12:23, Adrian Chadd wrote:
  I bet *office just uses a bunch of either horrible syntax that breaks
  things, or newer C/C++ features that are buggy in older compilers.
 Well, yes, this is, what I wanted to find out -- which case is it. There was 
 a 
 point, when we had a special compiler-port just for OpenOffice.org:
 
 http://www.freshports.org/lang/gcc-ooo
 
 That port was building gcc-3.4.1, which was NOT too old for the office only 
 a 
 few years ago (when gcc-4.2.1 already existed).
 
 I'd love to see a comment from people, who /know/ what is going on. Then we 
 may 
 be able to either patch-up the base compiler, or the office, code or both. 
 And 
 let the healing begin[TM].
 
 I'm afraid, though, the compiler-people are too cool to use an office suit -- 
 finding vi (and, perhaps, TeX) sufficient for their documents, while the 
 office@ 
 maintainers prefer the easy way of just adding the newer compiler to the 
 requirements. Getting these two distinct groups to meet in one thread was the 
 point of this topic...
 
 On 19.02.2013 12:35, Ian Lepore wrote:
  In any case, why hasn't that port been blessed with the requires gcc
  4.6+ port option/dependency? I thought that's why we_have_  that.
  It has been.  The OP stated the he disabled that and forced use of gcc
  4.2.1, and is now complaining that it doesn't work after specifically
  taking steps to make it not-work.
 Ian, contrary to your accusation, I never complained that the port does not 
 work. Moreover, to prevent that suspicion from entering sincere minds, I 
 explicitly said: I do not blame the office@ team -- the port did not want to 
 use gcc-4.2.1, I forced it to. Did you not see that sentence, or do 
 deliberately misrepresent my original post?
 
 -mi

Comments such as compiler people are too cool... as well as things
such as

 Upstream gcc? They may not be very interested, indeed, but it is
 FreeBSD, that 
 delivered this compiler to me -- in the most recent stable version of
 the OS. 
 
and
 
 But I agree, that it is insane, that the base compiler can not compile
 one of 
 the most popular open-source application-suits...

All strike me as being complaints, but if that seems like a
mis-characterization to you, then I apologize.

Licensing prevents us from updating gcc in the base.  Maintainers of
large opensource suites are likely to have little interest in supporting
a buggy old compiler years after it has been obsoleted by newer
versions.  The reasonable solution is to use a newer compiler to compile
newer ports, and put ongoing maintenance efforts into solidifying the
replacement compiler rather than propping up the buggy old one.

-- Ian


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

Re: Why can't gcc-4.2.1 build usable libreoffice?

[Ian Lepore]

On Tue, 2013-02-19 at 13:54 -0500, Mikhail T. wrote:
  Licensing prevents us from updating gcc in the base.
 Licensing? Could you elaborate, which aspect of licensing you have in
 mind? 

Versions of gcc after the 4.2.1 version we use are licensed under GPLv3.
I'm not a lawyer, so I don't understand all the fine details of why
GPLv3 is bad for the freebsd project, but I accept the analysis and
decisions the project made on that subject some time ago.  

As you might imagine, switching to a new compiler isn't something you
decide to do this afternoon and finish up tomorrow with a big checkin.
It takes many months of testing and iteratively fixing bugs... bugs
found in the new compiler, and bugs the new compiler exposes in the
existing source base.

I think we've been able to cherry-pick a few specific fixes from gcc
upstream that weren't encumbered by GPLv3, but for the most part I think
nobody is actively maintaining the GPLv2 code anymore.

-- Ian


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

Re: So I whip out a FTDI-based multiport Serial USB Adapter....

[Ian Lepore]

On Mon, 2013-02-04 at 12:57 -0600, Karl Denninger wrote:
 ... and plug it into FreeBSD 9.1-Stable with the rev ID FreeBSD
 9.1-STABLE #16 r244942
 
 and it returns
 
 ugen4.4: vendor 0x0409 at usbus4
 uhub6: vendor 0x0409 product 0x0050, class 9/0, rev 2.00/1.00, addr 4
 on usbus4
 uhub_attach: port 1 power on failed, USB_ERR_STALLED
 uhub_attach: port 2 power on failed, USB_ERR_STALLED
 uhub_attach: port 3 power on failed, USB_ERR_STALLED
 uhub_attach: port 4 power on failed, USB_ERR_STALLED
 uhub_attach: port 5 power on failed, USB_ERR_STALLED
 uhub_attach: port 6 power on failed, USB_ERR_STALLED
 uhub_attach: port 7 power on failed, USB_ERR_STALLED
 uhub6: 7 ports with 7 removable, self powered
 
 Yuck.
 
 The last time it was working was on a FreeBSD 7 box (yeah, I know,
 rather old) but I never had problems there.  And it appears that all of
 the device declarations that I used to have to put in the kernel as
 non-standard stuff are now in GENERIC, so I would expect it to work.
 
 Ideas as to what may have gotten hosed up here?
 

Those messages all seem to be related to a hub. Vendor ID 0x0409 is NEC.

FTDI's vendor ID is 0x0403, and FTDI stuff works fine in FreeBSD 9 and
10; I use it all the time.  Sometimes aftermarket vendors who use FTDI's
parts program different vendor/product info and IDs have to be added to
code to recognize them, that's the only trouble one usually encounters.

-- Ian


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

Re: So I whip out a FTDI-based multiport Serial USB Adapter....

[Ian Lepore]

On Mon, 2013-02-04 at 14:58 -0600, Karl Denninger wrote:
 On 2/4/2013 2:06 PM, Ian Lepore wrote:
  On Mon, 2013-02-04 at 12:57 -0600, Karl Denninger wrote:
  ... and plug it into FreeBSD 9.1-Stable with the rev ID FreeBSD
  9.1-STABLE #16 r244942
 
  and it returns
 
  ugen4.4: vendor 0x0409 at usbus4
  uhub6: vendor 0x0409 product 0x0050, class 9/0, rev 2.00/1.00, addr 4
  on usbus4
  uhub_attach: port 1 power on failed, USB_ERR_STALLED
  uhub_attach: port 2 power on failed, USB_ERR_STALLED
  uhub_attach: port 3 power on failed, USB_ERR_STALLED
  uhub_attach: port 4 power on failed, USB_ERR_STALLED
  uhub_attach: port 5 power on failed, USB_ERR_STALLED
  uhub_attach: port 6 power on failed, USB_ERR_STALLED
  uhub_attach: port 7 power on failed, USB_ERR_STALLED
  uhub6: 7 ports with 7 removable, self powered
 
  Yuck.
 
  The last time it was working was on a FreeBSD 7 box (yeah, I know,
  rather old) but I never had problems there.  And it appears that all of
  the device declarations that I used to have to put in the kernel as
  non-standard stuff are now in GENERIC, so I would expect it to work.
 
  Ideas as to what may have gotten hosed up here?
 
  Those messages all seem to be related to a hub. Vendor ID 0x0409 is NEC.
 
  FTDI's vendor ID is 0x0403, and FTDI stuff works fine in FreeBSD 9 and
  10; I use it all the time.  Sometimes aftermarket vendors who use FTDI's
  parts program different vendor/product info and IDs have to be added to
  code to recognize them, that's the only trouble one usually encounters.
 
  -- Ian
 Well, that sorta kinda worked. 
 
 Except that it still is identifying it as a hub too, and the two collide
 and crash the stack.
 
 But I can't find anything that is looking at the PID (0x0050) or the
 definition (HUB_0050) anywhere in the code. 
 
 I'll go pull the NEC defs and set up something else instead of simply
 adding it to the FTDI probe list.
 

It seems to me you have a problem with a hub (perhaps the root hub or a
motherboard hub if you don't have an external one) and this has nothing
to do with the ftdi device at all.  Or the usb serial device is damaged
somehow so that the vendor and product ID are reading as garbage and
being mistaken for a hub.

Have you tried the ftdi adapter on another port/hub/computer?  Have you
tried plugging something else into the port you're trying to use for the
ftdi adapter, like a thumb drive or something?

-- Ian


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