Re: what do jails map 127.0.0.1 to?

2019-02-12 Thread Allan Jude
On 2019-02-10 19:50, Rick Macklem wrote:
> I am finally back to looking at an old PR#205193.
> 
> The problem is that the nfsuserd daemon expects upcalls from the kernel
> that are from localhost (127.0.0.1) and when jails are running on the system,
> 127.0.0.1 is mapped to some other IP#. (I think it might be the address of the
> first net interface on the machine, but I'm not sure?)
> 
> Is there a way that nfsuserd.c can find out what this IP# is?
> (I have a patch that converts nfsuserd.c to using an AF_LOCAL socket, but that
>  breaks for some setups. I think it was when the directory the socket was 
> being
>  created in is NFSv4 mounted, but I can't remember exactly how it fails.)
> 
> Thanks for any help with this, rick
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

normal Jails map 127.0.0.1 to the first IP in the jail.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: The future of ZFS in FreeBSD

2018-12-20 Thread Allan Jude

On 12/19/2018 13:32, Allan Jude wrote:

Today, the OpenZFS repo is just a fork of the illumos-gate repo, but
where pull requests are accepted, and where previous Delphix employees


This should say 'previously', Prakash Surya and Matt Ahrens still work 
at Delphix.



would deal with the process of trying to upstream patches to illumos.
This process has not worked well recently, as things have gotten stuck
waiting for 'merge advocates' in illumos.



The major stumbling block was the lack of modern test infrastructure.
Obviously depending on one or two people to merge stuff was a bottleneck 
as those people inevitably get busy.




Anyway, the point is that this doesn't make FreeBSD any more dependent 
on Linux. The goal is this project is to continue to make it easier and 
easier to port OpenZFS and its new features to all platforms (illumos, 
FreeBSD, Linux, OS X, Windows, NetBSD, etc), and to ensure that new 
features arrive in a timely fashion in all of the platforms.


Unifying on a single CI setup saves duplication of effort, and ensures 
that changes can easily be tested on all of the platforms.


This is a project is a good thing, it ensures that FreeBSD will keep 
current on OpenZFS going forward, and helps improve the entire OpenZFS 
ecosystem.


I am to give a big thanks to Matt Ahrens for organizing the monthly 
OpenZFS Leadership meeting, and the OpenZFS developer summit, and to 
Brian Behlendorf for being so helpful, and willing to work to make 
OpenZFS better for everyone.


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


Re: The future of ZFS in FreeBSD

2018-12-19 Thread Allan Jude
 just a fork of the illumos-gate repo, but
where pull requests are accepted, and where previous Delphix employees
would deal with the process of trying to upstream patches to illumos.
This process has not worked well recently, as things have gotten stuck
waiting for 'merge advocates' in illumos.

The ZoF effort will move us closer to the goal of a common repo. The
general idea will be to have 'OS Dependent' and 'OS Independent' code,
similar to the MI/MD split we do in other kernel code. So the upstream
repo will contain OpenZFS, and directories for linux and freebsd. We
will leverage the CI work that has already been done, and this will mean
that all proposed changes will have to pass CI on FreeBSD as well as
Linux before they are merged.

Even illumos will begin pulling changes from the ZoL repo, but their
timelines are much longer, and more vague than will be acceptable for
FreeBSD.

There is a monthly ZFS call with leaders from all of the projects
(FreeBSD, illumos, ZoL, ZFS on OSX, ZFS on Windows, various vendors),
where the need for this change, and some other parts of the plan are
discussed:

https://www.youtube.com/channel/UC0IK6Y4Go2KtRueHDiQcxow/videos


The way that things have evolved over the last few years means it would
be much more difficult to just import changes from ZoL. ZoL was
originally far behind the OpenZFS repo, but as they were catching up,
they were also fixing bugs and adding features. So there is not really a
common point in the source we could start from to import ZoL commit by
commit. My recent attempts to import a single ZoL feature were also
fraught with issues, as the original feature was imported before the
zpool import rewrite, but many improvements and bug fixes were done
after the rewrite. So the code just doesn't apply cleanly to FreeBSD,
since it already has the zpool import rewrite applied.

Of paramount importance will be the stability and reliability of the
FreeBSD implementation of ZFS. However, for the future, we are going to
need to make this switch, so it is better to start sooner rather than
later.

The biggest thing to remember is that this is still OpenZFS, and still
run by the same developers as it has been. We are just commonizing on
the repo that has the most features integrated into it.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: Graphics open-source-friendliness, AMD Ryzen vs. Intel

2018-11-11 Thread Allan Jude
On 2018-11-11 12:54, Greg V wrote:
> 
> 
> On Sun, Nov 11, 2018 at 3:42 PM, Thomas Mueller 
> wrote:
>> I may need to buy parts for a new computer because of malfunctions on
>> current motherboard and CPU (Intel Sandy Bridge dating to May 2011).
>>
>> Question is whether I am better off, regarding
>> open-source-friendliness of graphics chips for running Xorg, with AMD
>> Ryzen or the newer Intel chipsets.  I know to avoid NVIDIA.
> 

My FreeBSD workstation use an nVidia Quadro K1200 and it works very well
under FreeBSD with the nVidia kernel driver from ports.

> Both are great for open source friendliness in general.
> 
> Onboard Vega GPUs on the Ryzen APUs should work fine on FreeBSD with
> kms-drm 4.16.
> 
> If you're looking for high performance though, don't get an APU, get an
> 8-core (R7 2700X/2700/1700X/1700) and a discrete GPU (Radeon RX
> 550/560/570/580 depending on how much you care about graphics performance).
> 
>> I am inclined to run FreeBSD-current and build Xorg from FreeBSD ports.
>>
>> When I boot into UEFI setup, I see the CPU temperature is or quickly
>> goes to 97 C and stays there.
>>
>> I tried replacing the thermal paste and installing a new case fan to
>> replace one that had quit, but CPU temperature still shows and stays
>> at 97 C.
>>
>> Now I have a replacement Arctic Cooler heatsink and fan on order to
>> replace the original Intel heatsink and fan whose connectors were
>> damaged in taking out and struggling to get back in.
>>
>> Currently, I boot into UEFI Setup, but after a couple minutes, the
>> computer powers off and then tries to power back on, then off again a
>> few seconds later, until I end the loop by turning off the power
>> supply switch.  I can guess CPU overheating.
> 
> Yeah, a new CPU cooler should help.
> 
>> I could transplant the current hard drive (Seagate NAS 4 TB) to get a
>> quicker start software-wise.
> 
> An SSD might provide a quicker start too ;)
> 
> _______
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: UEFI: How to go about updating the ESP with loader.efi during installworld

2018-11-04 Thread Allan Jude
On 2018-11-04 16:20, Rebecca Cran wrote:
> I'm currently working on creating and updating the ESP (EFI System Partition) 
> for UEFI booting during installation and installworld. 
> 
> During installation, with my changes it gets mounted on /boot/efi and 
> loader.efi 
> copied into /boot/efi/EFI/FreeBSD and /boot/efi/EFI/BOOT. An entry gets added 
> to 
> /etc/fstab as noauto.
> 
> The issue comes during installworld, where we'll need to update the loader, 
> and I'm not sure how we should handle that. 
> If NO_ROOT isn't defined, do we just "mount /boot/efi", overwrite the files 
> then 
> unmount it? What should we do if NO_ROOT _is_ defined?
> 

Previous to now, installworld has not updated the boot blocks. You've
had to manually run 'gpart bootcode' to change the boot blocks.

However, those boot blocks mostly just loaded /boot/loader, which was
updated by installworld.

So I can see how this is not directly analogous.

I wouldn't depend on the /etc/fstab entry existing. I am not sure I want
installworld randomly fobbing around in my EFI partition. Especially if,
for example, my EFI/BOOT is not FreeBSD, but rEFInd or something.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: Strange panic at boot with vmm in loader.conf vs manually loading it

2018-10-13 Thread Allan Jude

On 10/12/2018 11:52, Mike Tancsa wrote:

I am guessing this does not have anything to do with vmm being loaded,
but hardware being initialized in a particular order? If I load vmm in
loader.conf, the box panics at boot up.  However, manually loading it
all seems to work.  Hardware is PRIME X370-PRO, AMD Ryzen 5 1600X 32G
RAM.  FreeBSD 12.0-ALPHA9 r339328 GENERIC-NODEBUG


Leading up to the crash, I see


ugen0.1: <0x1022 XHCI root HUB> at usbus0
ugen1.1: <0x1b21 XHCI root HUB> at usbus1
Trying to mount root from zfs:zroot/ROOT/default []...
uhub0: ugen2.1: <0x1022 XHCI root HUB> at usbus2
Root mount waiting for: usbus2<0x1022 XHCI root HUB, class 9/0, rev
3.00/1.00, addr 1> on usbus0
  usbus1 usbus0
uhub1: <0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus2
uhub2: <0x1b21 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus1
uhub2: 4 ports with 4 removable, self powered
uhub1: 8 ports with 8 removable, self powered
uhub0: 22 ports with 22 removable, self powered

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x398
fault code  = supervisor write data, page not present
instruction pointer = 0x20:0x8273d776
stack pointer   = 0x28:0xfe0075d55230
frame pointer   = 0x28:0xfe0075d55270
code segment    = base 0x0, limit 0xf, type 0x1b
     = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags    = interrupt enabled, resume, IOPL = 0
current process = 1 (kernel)
[ thread pid 1 tid 12 ]
Stopped at  rrw_enter_read_impl+0x36:   lock cmpxchgq
%r14,0x18(%rbx)
db> bt
Tracing pid 1 tid 12 td 0xf8000567d580
rrw_enter_read_impl() at rrw_enter_read_impl+0x36/frame 0xfe0075d55270
zfs_mount() at zfs_mount+0x7b2/frame 0xfe0075d55400
vfs_domount() at vfs_domount+0x5b2/frame 0xfe0075d55630
vfs_donmount() at vfs_donmount+0x930/frame 0xfe0075d556d0
kernel_mount() at kernel_mount+0x3d/frame 0xfe0075d55720
parse_mount() at parse_mount+0x451/frame 0xfe0075d55860
vfs_mountroot() at vfs_mountroot+0x7a0/frame 0xfe0075d559f0
start_init() at start_init+0x27/frame 0xfe0075d55a70
fork_exit() at fork_exit+0x83/frame 0xfe0075d55ab0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe0075d55ab0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
db>


Strange that your crash is in ZFS here...

Can you take a crash dump?

It looks like something is trying to write to uninitialized memory here.



On a normal boot, the next line would be atrtc0

uhub0: Root mount waiting for: usbus2ugen2.1: <0x1022 XHCI root HUB> at usbus2
<0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
  usbus1 usbus0uhub1: <0x1b21 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> 
on usbus1

uhub2: <0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus2
uhub1: 4 ports with 4 removable, self powered
uhub2: 8 ports with 8 removable, self powered
uhub0: 22 ports with 22 removable, self powered
atrtc0: providing initial system time
start_init: trying /sbin/init
Setting hostuuid: c3297ba0-3f01-11e7-8725-6045cba08a84.
Setting hostid: 0x094fa67e.
Starting file system checks:
Mounting local filesystems:.


snip




---Mike






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


Re: AMD RAID support?

2018-10-04 Thread Allan Jude
On 2018-10-04 12:29, Zaphod Beeblebrox wrote:
> Are there any plans to support AMD RAID?
> 
> AMD RAID is _like_ Intel RAID, but has a number of differences.  One is
> that it requires UEFI (without UEFI it does not boot, at least).  It comes
> on/with AMD motherboards for Zen and Threadripper processors.  It also only
> supports RAID 0/1/10, that is: no support for 5/50.
> 
> Also, unlike Intel RAID, at least initially, the raw disks don't seem to
> show up.  That's not entirely true: On some motherboards, NVME RAID is
> supported and the NVME "disks" show up, but the SATA disks do not.
> 
> Obviously this is all in the service of mounting the dual-boot windows
> drive.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

Do you have any details on the metadata location and format?

GEOM Support for Intel RAID mostly consists of the ability to understand
the metadata on the drives and present the same RAID configuration to
the OS.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: 12.0-ALPHA5 - ZFS default ARC max apparently forcing system to run out of memory

2018-09-27 Thread Allan Jude
On 2018-09-27 18:01, Rebecca Cran wrote:
> I'm running 12.0-ALPHA5 on a laptop which has 32GB RAM and 2GB swap.
> I've found it running out of memory when building ports via synth: I
> think I've also seen it when running a buildworld. Johannes on
> FreeBSDDesktop suggested it might be related to ZFS, and setting
> vfs.zfs.arc_max to 8GB *does* appear to have resolved the problem.
> 
> 
> Shortly after running out of memory (with |"swap_pager_getswapspace(32):
> failed" messages)|, the first few lines of 'top' were:
> 
> 
> Mem: 4335M Active, 4854M Inact, 7751M Laundry, 9410M Wired, 48K Buf,
> 5332M Free
> 
> ARC: 5235M Total, 4169M MFU, 497M MRU, 172K Anon, 97M Header, 471M Other
> 
>  3479M Compressed, 5930M Uncompressed, 1.70:1 Ratio
> 
> Swap: 2048M Total, 2009M Used, 39M Free, 98% Inuse
> 
> 
> 
> I've not seen this happen before on ZFS systems, so is it a regression
> in 12?
> 
> 

It doesn't appear like ZFS is dominating memory usage there. Using less
than the 8GB you indicated that setting the max to solved the problem...

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: UEFI layout includes a freebsd-boot?

2018-09-23 Thread Allan Jude
On September 24, 2018 12:58:40 AM GMT+03:00, Sean Bruno  
wrote:
>
>
>On 9/23/18 3:57 PM, David P. Discher wrote:
>> This is correct for a EFI+BIOS map. If the installer did this for an
>EFI
>> only map, then that is a bug.
>> 
>
>Is it supposed to "Detect" BIOS vs UEFI booting in the installer?
>
>sean
>
>> My 12-Alpha7 install I just did, with BIOS only:
>> 
>> dpd@amd:~ % gpart show
>> =>       40  234441568  ada0  GPT  (112G)
>>          40       1024     1  freebsd-boot  (512K)
>>        1064        984        - free -  (492K)
>>        2048    4194304     2  freebsd-swap  (2.0G)
>>     4196352  230244352     3  freebsd-zfs  (110G)
>>   234440704        904        - free -  (452K)
>> 
>> 
>> 
>> The “free” section seems a bit aggressive (large) … assuming for
>sector
>> alignment.  ( Would be cool for future feature if freebsd-boot can be
>> encapsulated in the EFI partition. ) 
>> 
>> 
>> --
>> David P. Discher 
>> https://davidpdischer.com/
>> d...@dpdtech.com
>> 
>>> On Sep 23, 2018, at 1:57 PM, Sean Bruno >> <mailto:sbr...@freebsd.org>> wrote:
>>>
>>> I don't think this layout from the installer is correct, but I could
>be
>>> wrong.  Is there any reason to have a freebsd-boot in this layout
>>> created by the installer when using UEFI?
>>>
>>> % gpart show
>>> =>   40  537234688  ada0  GPT  (256G)
>>> 40 409600 1  efi  (200M)
>>> 409640   1024 2  freebsd-boot  (512K)
>>> 410664    984    - free -  (492K)
>>> 411648   67108864 3  freebsd-swap  (32G)
>>>   67520512  469712896     4  freebsd-zfs  (224G)
>>>  537233408   1320    - free -  (660K)
>>>
>>>
>> 

I made the default (for both UEFI and legacy iirc) be both, so you can flip 
back and forth at will. Especially since UEFI is going to be 200mb or more now, 
better to reserve the same and not need it than the other way around.
-- 
Allan Jude
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: ZFS perfomance regression in FreeBSD 12 APLHA3->ALPHA4

2018-09-05 Thread Allan Jude
On 2018-09-05 10:04, Subbsd wrote:
> Hi,
> 
> I'm seeing a huge loss in performance ZFS after upgrading FreeBSD 12
> to latest revision (r338466 the moment) and related to ARC.
> 
> I can not say which revision was before except that the newver.sh
> pointed to ALPHA3.
> 
> Problems are observed if you try to limit ARC. In my case:
> 
> vfs.zfs.arc_max="128M"
> 
> I know that this is very small. However, for two years with this there
> were no problems.
> 
> When i send SIGINFO to process which is currently working with ZFS, i
> see "arc_reclaim_waiters_cv":
> 
> e.g when i type:
> 
> /bin/csh
> 
> I have time (~5 seconds) to press several times 'ctrl+t' before csh is 
> executed:
> 
> load: 0.70  cmd: csh 5935 [arc_reclaim_waiters_cv] 1.41r 0.00u 0.00s 0% 3512k
> load: 0.70  cmd: csh 5935 [zio->io_cv] 1.69r 0.00u 0.00s 0% 3512k
> load: 0.70  cmd: csh 5935 [arc_reclaim_waiters_cv] 1.98r 0.00u 0.01s 0% 3512k
> load: 0.73  cmd: csh 5935 [arc_reclaim_waiters_cv] 2.19r 0.00u 0.01s 0% 4156k
> 
> same story with find or any other commans:
> 
> load: 0.34  cmd: find 5993 [zio->io_cv] 0.99r 0.00u 0.00s 0% 2676k
> load: 0.34  cmd: find 5993 [arc_reclaim_waiters_cv] 1.13r 0.00u 0.00s 0% 2676k
> load: 0.34  cmd: find 5993 [arc_reclaim_waiters_cv] 1.25r 0.00u 0.00s 0% 2680k
> load: 0.34  cmd: find 5993 [arc_reclaim_waiters_cv] 1.38r 0.00u 0.00s 0% 2684k
> load: 0.34  cmd: find 5993 [arc_reclaim_waiters_cv] 1.51r 0.00u 0.00s 0% 2704k
> load: 0.34  cmd: find 5993 [arc_reclaim_waiters_cv] 1.64r 0.00u 0.00s 0% 2716k
> load: 0.34  cmd: find 5993 [arc_reclaim_waiters_cv] 1.78r 0.00u 0.00s 0% 2760k
> 
> this problem goes away after increasing vfs.zfs.arc_max
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

Previously, ZFS was not actually able to evict enough dnodes to keep
your arc_max under 128MB, it would have been much higher based on the
number of open files you had. A recent improvement from upstream ZFS
(r337653 and r337660) was pulled in that fixed this, so setting an
arc_max of 128MB is much more effective now, and that is causing the
side effect of "actually doing what you asked it to do", in this case,
what you are asking is a bit silly. If you have a working set that is
greater than 128MB, and you ask ZFS to use less than that, it'll have to
constantly try to reclaim memory to keep under that very low bar.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: old top and new -current: missing arcstat sysctl

2018-08-29 Thread Allan Jude
On 2018-08-29 11:18, Mark Johnston wrote:
> On Wed, Aug 29, 2018 at 07:44:31AM +0200, Alexander Leidinger wrote:
>>
>> Quoting Mark Johnston  (from Tue, 28 Aug 2018  
>> 10:48:42 -0400):
>>
>>> On Tue, Aug 28, 2018 at 10:25:39AM -0400, Allan Jude wrote:
>>>> On 2018-08-28 02:40, Alexander Leidinger wrote:
>>>>> Hi,
>>>>>
>>>>> top reports missing sysctl kstat.zfs.misc.arcstats.other_size for
>>>>> 12.0-alpha3 with a top from an old-ish -current.
>>>>>
>>>>> Is/will this be handled via a compat-11 sysctl (my kernel is without
>>>>> compat-xx), or did this slip through?
>>
>>>> That is not something that a compat-xx package can handle.
>>>
>>> s/package/kernel option/?
>>
>> Sorry, the COMPAT_FREEBSDx kernel options was what I had in mind when  
>> I wrote this.
>>
>>>> That arcstat was broken up into 3 individual stats, which the
>>>> 12.0-alpha3 version of top will sum together for you.
>>>>
>>>> I don't think we've had compat shims like this for previous versions of
>>>> top, I recall having similar issues when the 'laundry' counter was
>>>> introduced.
>>>
>>> IIRC that would have been the inverted case of running a newer top(1)
>>> with an older kernel lacking the v_laundry_pages sysctl.  In general I'd
>>> expect us to support running an older top(1) with newer kernels if we
>>> don't have to bend over backwards to provide compatibility.
>>
>> If the new top is summing the 3 up anyway, it sounds like we could  
>> provide the old one as backwards compatibility, even if it is  
>> redundant. I rather have an redundant counter and an old top working  
>> (in the generic case of what we promise to our users; in this specific  
>> case for me I just need to get around to update the jails on the  
>> corresponding systems), than bailing out without displaying anything.
> 
> I'm inclined to agree, especially since this (running older top(1)s) has
> come up before when I removed some VM sysctls:
> https://reviews.freebsd.org/D16943
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

I misunderstood previously (COMPAT_FREEBSDxx vs the compat-xx package).
I am in agreement with Mark about fixing this for 12.0

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: old top and new -current: missing arcstat sysctl

2018-08-28 Thread Allan Jude
On 2018-08-28 02:40, Alexander Leidinger wrote:
> Hi,
> 
> top reports missing sysctl kstat.zfs.misc.arcstats.other_size for
> 12.0-alpha3 with a top from an old-ish -current.
> 
> Is/will this be handled via a compat-11 sysctl (my kernel is without
> compat-xx), or did this slip through?
> 
> Bye,
> Alexander.
> 

That is not something that a compat-xx package can handle.

That arcstat was broken up into 3 individual stats, which the
12.0-alpha3 version of top will sum together for you.

I don't think we've had compat shims like this for previous versions of
top, I recall having similar issues when the 'laundry' counter was
introduced.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: beadm vs bectl

2018-08-27 Thread Allan Jude
On 2018-08-27 14:50, Pete Wright wrote:
> hi there - i have a zfs based system where /boot is on its own pool. 
> beadm seems happy enough with this setup but bectl errors out like so:
> 
> $ sudo bectl list
> / and /boot not on same device, quitting
> $
> 
> $ beadm list
> BE Active Mountpoint  Space Created
> default    NR /   47.6G 2018-03-02 20:30
> snapshot_02262018  -  -    1.5G 2018-03-03 14:38
> badresume_05122018 -  -    4.4G 2018-05-12 19:45
> 11_2_beta  -  -    2.6G 2018-05-13 18:26
> resume_works   -  -   12.6G 2018-06-01 16:45
> $
> 
> reading the manpage for bectl it doesn't mention this being an issue. 
> so i guess i have two questions:
> 1) is it a bad thing(tm) to have /boot on its own pool?
> 2) assuming that having /boot on its  own pool, why does bectl not work
> with this configuration?
> 
> thanks!
> -pete
> 

Your /boot being on a separate pool can never work, since you can't take
a consistent snapshot of / and have it include your kernel (which is
under /boot/kernel which is a separate pool)

Do you know why you have 2 separate pools? If it was for GELI support,
FreeBSD 12.0 will not require two separate pools anymore, and there will
be migration instructions shortly.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: drm / drm2 removal in 12

2018-08-25 Thread Allan Jude
>> ---
>>>>>
>>>>> Now you guys who claim to only be hobbyist doing this in their free
>> time
>>>>> expect to maintain this when those companies with all their resources
>>>>> cannot?
>>>>>
>>>>> Those 30,000 ports many of them bring bugs with them because of this
>>>>> Linuxkpi stuff. Just recently there was a user who said google earth
>>>>> doesn't work the answer was it doesn't work and that's that.
>>>>>
>>>>> They get ported and then get dropped so while the ports tree is large,
>> if
>>>>> you actually try to use some of those programs they are broken,
>>>>> maintenance
>>>>> hell for the developers and confusion for the users.
>>>>>
>>>>> Johannes Lundberg I know that you are one of the main working on this
>>>>> linuxkpi stuff but anyone else is free to answer as well.
>>>>>
>>>>> Let's have an open discussion why do you need to remove the current
>>>>> graphics stack to continue with your work?
>>>>
>>>> This has been discussed over and over on the mailing list and I don’t
>>>> think anyone wants to do it over again so please feel free to search the
>>>> archives.
>>>>
>>>> You’re misinformed. We are not removing anything for anyone. We are
>> moving
>>>> it to ports.
>>>> “pkg install drm-legacy-kmod” will install those drivers for you that
>> were
>>>> earlier in base. I thought we have been clear about this but maybe we
>>>> haven’t been clear enough.
>>>>
>>>>
>>>>
>>>>> ___
>>>>> freebsd-current@freebsd.org mailing list
>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>>>> To unsubscribe, send any mail to "
>> freebsd-current-unsubscr...@freebsd.org
>>>>> "
>>>>>
>>>> Have you or anyone working on this drm-legacy-kmod stuff done any
>> testings
>>> of how this will affect current users?
>>>
>>> 1) Take a [test] system with the current graphics stack installed and
>>> working.
>>> 2) Apply your patches to remove the drm from base to create a port
>>> 3) update the working [test] system after applying your changes
>>>
>>> How does your changes affect a [test] system that is already up and
>> running?
>>>
>>> Have any of you guys tried that? Do you have any documentation on how
>> it'll
>>> affect users.
>>>
>>> You guys want to remove things from the current system but you come with;
>>> it works for us hobbyists.
>>> Where do users go to get steps to do all of this stuff?
>>>
>>> You've repeatedly said what you want to do sure, but have you tested it?
>>> ___
>>> freebsd-sta...@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
>>> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org
>> "
>>
>>
> I'll just post this again to try and keep the focus on the issue at hand.
> =
> Have you or anyone working on this drm-legacy-kmod stuff done any testings
> of how this will affect current users?
> 
> 1) Take a [test] system with the current graphics stack installed and
> working.
> 2) Apply your patches to remove the drm from base to create a port
> 3) update the working [test] system after applying your changes
> 
> How does your changes affect a [test] system that is already up and running?
> 
> Have any of you guys tried that? Do you have any documentation on how it'll
> affect users.
> 
> You guys want to remove things from the current system but you come with;
> it works for us hobbyists.
> Where do users go to get steps to do all of this stuff?
> 
> You've repeatedly said what you want to do sure, but have you tested it?
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

You have obviously not been paying attention.

The patch will result in your upgraded system giving you an deprecation
warning message, with instructions on installing the port.


-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: Native Encryption for ZFS on FreeBSD CFT

2018-08-21 Thread Allan Jude
On 2018-08-21 23:16, Alan Somers wrote:
> On Tue, Aug 21, 2018 at 9:13 PM Sean Fagan  wrote:
> 
>> On Aug 21, 2018, at 8:11 PM, Alan Somers  wrote:
>>> The last time I looked (which was a long time ago), Oracle's ZFS
>> encryption looked extremely vulnerable to watermarking attacks.  Did
>> anybody ever fix that?
>>
>> This isn’t Oracle’s implementation, but I don’t know how compatible or not
>> it is with it.
>>
>> Sean.
>>
> 
> It wasn't just an implementation problem, it was in the design.  IIRC,
> Oracle's encryption allowed encrypted blocks to be deduplicated.  There's
> pretty much no way to defend against watermarking attacks with such a
> design.  Does the new encryption design have the same flaw?
> 
> -Alan
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

There is a presentation from the OpenZFS developers summit that walks
through the design. It is not the same as the Oracle version, although
relatively similar.

Video: https://youtu.be/frnLiXclAMo
Slides:
https://drive.google.com/file/d/0B5hUzsxe4cdmU3ZTRXNxa2JIaDQ/view?usp=sharing

It says dedup only works within the same 'clone family', and uses a
unique IV for every block, except when the data is identical (when it
gets deduped)

It isn't clear to me from the presentation if this issue is mitigated or
not. Slide #26 suggests they have done more than Oracle did.


-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: IPMI SOL seems to not accept characters after getty starts

2018-08-08 Thread Allan Jude
On 2018-08-08 19:21, Sean Bruno wrote:
> 
> 
> On 08/08/18 17:13, Warner Losh wrote:
>>
>>
>> On Wed, Aug 8, 2018 at 4:39 PM, Sean Bruno > <mailto:sbr...@freebsd.org>> wrote:
>>
>> tl;dr pxeboot new x86 host, ipmi sol works in loader, not after
>> multiuser.
>>
>> The FreeBSD cluster just acquired 4x Supermicro X11DDW-L and I am having
>> the hardest time with the IPMI SOL interface.
>>
>> I have configured "COM2" as the IPMI SOL interface and enabled console
>> redirection.  Netbooting via pxeboot works well and the loader menu is
>> interactive and responds.
>>
>> After NFS booting into freebsd (current or stable/11), getty fires up
>> and attaches to ttyu0.  It prompts me correctly, but it does not accept
>> my keystrokes.
>>
>> If I do not configure /etc/ttys to enable a tty unconditionally (on vs
>> onifconsole), I see dmesg/kernel boot messages but never get a tty.
>>
>> Its as though FreeBSD does *not* recognize the IPMI SOL port as the
>> console or something and I'm super confused.  Any thoughts here?
>>
>>
>> Works fine for me.
>>
>> So, let's start with your /boot.config (or /boot/config) loader.conf and
>> device,hints settings. Also BIOS or UEFI?
>>
>> Warner
>>  
> 
> Works for you on this exact Supermicro?
> 
> I am using the defaults all around.  This is booting BIOS mode PXE, all
> console output appears on the IPMI SOL interface.  Driving the beastie
> menu in pxeboot/loader works fine.  When the loader hands the uart off
> to the kernel, I see all boot output and "everything is fine"
> 
> The problem arises when trying to login.  I see the amnesiac login
> prompt, but no key strokes are registered.
> 
> loader.conf:
> console="comconsole"
> comconsole_speed="115200"
> 
> boot.config:
> 
> 
> sean
> 
> 

If it is COM2, don't you also need:
comconsole_port="0x2f8"

And possibly device.hints:
hint.uart.1.flags="0x10"

to mark it as a serial console?

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: programs like gdb core dump

2018-08-06 Thread Allan Jude
On 2018-08-06 23:11, Erich Dollansky wrote:
> Hi,
> 
> On Mon, 6 Aug 2018 15:57:53 -0700
> John Baldwin  wrote:
> 
>> On 8/4/18 4:38 PM, Erich Dollansky wrote:
>>> Hi,
>>>
>>> I compiled me yesterday this system:
>>>
>>> 12.0-CURRENT FreeBSD 12.0-CURRENT #1 r337285:
>>>
>>> When restarting fortune core dumps. When trying to load the core
>>> dump, gdb core dumps.
>>>
>>> The message is always:
>>>
>>> Bad system call (core dumped)
>>>
>>> Trying to install ports results in the same effect.
>>>
>>> Erich  
>>
>> Did you upgrade from stable/11 with a world that is still stable/11?
>> If so, did you make sure your kernel config includes COMPAT_FREEBSD11?
>> (GENERIC should include this)
>>
> 
> I never have had a machine running 11. This machine is on 12 since 2 or
> 3 years. I will check if this configuration was properly set on that
> machine.
> 
> Thanks!
> 
> Erich
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

compare the output of: `uname -K` and `uname -U`

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: [UEFI] Boot issues on some UEFI implementations

2018-07-24 Thread Allan Jude
On 2018-07-13 07:00, O. Hartmann wrote:
> The problem is some kind of weird. I face UEFI boot problems on GPT drives
> where the first partition begins at block 40 of the hdd/ssd.
> 
> I have two host in private use based on an
> outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard (IvyBridge, Socket LGA1155).
> Both boards are equipted with the lates official available AMI firmware
> revision, dating to 2013. This is for the Z77-Pro4-M revision 2.0 (2013/7/23)
> and for the Z77 Pro4 revision 1.8 (2013/7/17). For both boards a BETA revision
> for the Spectre/Meltdown mitigation is available, but I didn't test that. But
> please read.
> 
> The third box I realised this problem is a brand new Fujitsu Esprimo Q956, 
> also
> AMI firmware, at V5.0.0.11 R 1.26.0 for 3413-A1x, date 05/25/2018 (or 
> 20180525).
> 
> Installing on any kind of HDD or SSD manually or via bsdinstall the OS using
> UEFI-only boot method on a GPT partitioned device fails. The ASRock boards 
> jump
> immediately into the firmware, the Fujitsu offers some kind of CPU/Memory/HDD
> test facility.
> 
> If on both type of vendor/boards CSM is disabled and UEFI boot only is 
> implied,
> the MBR partitioned FreeBSD installation USB flash device does boot in UEFI! I
> guess I can assume this when the well known clumsy 80x25 char console suddenly
> gets bright and shiny with a much higher resoltion as long the GPU supports
> EFI GOP. Looking with gpart at the USB flash drives reveals that the EFI
> partition starts at block 1 of the device and the device has a MBR layout. I
> haven't found a way to force the GPT scheme, when initialised via gpart, to 
> let
> the partitions start at block 1. This might be a naiv thinking, so please be
> patient with me.
> 
> I do not know whether this is a well-known issue. On the ASRock boards, I
> tried years ago some LinuxRed Hat and Suse with UEFI and that worked - FreeBSD
> not. I gave up on that that time. Now, having the very same issues with a new
> Fujitsu system, leaves me with the impression that FreeBSD's UEFI
> implementation might have problems I'm not aware of.
> 
> Can someone shed some light onto this? 
> 
> Thanks in advance,
> 
> Oliver 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

If you are up for experimenting, see if either of these results in your
system booting:
gpart set -a active ada0
gpart set -a lenovofix ada0

Although both of these should only impact BIOS boot, not UEFI, you never
know.

The other option is to try an ESP (EFI System Partition) that is
formatted FAT32 instead of FAT12/FAT16)

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: GELI with UEFI supporting Boot Environments goes to HEAD when?

2018-07-09 Thread Allan Jude
rt driver
 > >>>> >> c) boot crypto
 > >>>> >> d) GELI partition types (not strictly
necessary)
 > >>>> >>
 > >>>> >> Then there's the GELI driver itself.  (a)
and (c)

are


 > good to
 > >>>> land, (b)
 > >>>> >> needs some more work after Toomas Soome
pointed

out a


 > >>legitimate
 > >>>> >> problem, and (d) actually needs a good bit
more
 code (but
 > >>again,
 > >>>> it's
 > >>>> >> more cosmetic).  Additionally, the GELI
driver
 will need
 > >>further
 > >>>> mods to
 > >>>> >> efipart to be written (nothing too
big).  But we
 could go
 > >>ahead
 > >>>> with (a)
 > >>>> >> and (c), as they've already been proven to
work.
 > >>>> >>
 > >>>> >> I'd wanted to have this stuff shaped up
sooner,
 but I'm
 > >>>> preoccupied with
 > >>>> >> the 7th RISC-V workshop at the end of the
month.
 > >>>> >>
 > >>>> >> Once this stuff is all in, loader should
handle
 any GELI
 > >>volumes it
 > >>>> >> finds, and it should Just Work once boot1
is gone.
 > >>>> >>
 > >>>> >>
 > >>>> > ___
 > >>>> > freebsd-current@freebsd.org
 <mailto:freebsd-current@freebsd.org>
 > <mailto:freebsd-current@freebsd.org
 <mailto:freebsd-current@freebsd.org>> mailing list
 > >>>> > https://lists.freebsd.org/mailman/listinfo/freeb
sd-

current


 <https://lists.freebsd.org/mailman/listinfo/freebsd-current>
 > <https://lists.freebsd.org/mailman/listinfo/freebsd-cur
rent
 <https://lists.freebsd.org/mailman/listinfo/freebsd-current>>
 > >>>> > To unsubscribe, send any mail to

"freebsd-current-unsubscribe@


 > >>>> freebsd.org <http://freebsd.org>
<http://freebsd.org>"
 > >>>> >
 > >>>>
 > >>>
 > >
 > > --
 > > Sent from my Android device with K-9 Mail. Please
excuse my

brevity.


 > > ___
 > > freebsd-current@freebsd.org
 <mailto:freebsd-current@freebsd.org>
 <mailto:freebsd-current@freebsd.org
 <mailto:freebsd-current@freebsd.org>>
 > mailing list
 > > https://lists.freebsd.org/mailman/listinfo/freebsd-cu
rrent
 <https://lists.freebsd.org/mailman/listinfo/freebsd-current>
 > <https://lists.freebsd.org/mailman/listinfo/freebsd-cur
rent
 <https://lists.freebsd.org/mailman/listinfo/freebsd-current>>
 > > To unsubscribe, send any mail to
 > "freebsd-current-unsubscr...@freebsd.org
 <mailto:freebsd-current-unsubscr...@freebsd.org>
 > <mailto:freebsd-current-unsubscr...@freebsd.org
 <mailto:freebsd-current-unsubscr...@freebsd.org>>"
 > >
 >
 >





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


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


Re: Boot freezing after kernel load - root on zfs

2018-06-23 Thread Allan Jude
On 2018-06-23 00:37, Warner Losh wrote:
> There were some issues with legacy geely booting recently. What version?
> UEFI or legacy BIOS booting?
> 
> Warner 
> 
> On Fri, Jun 22, 2018, 10:26 PM Ben Woods  <mailto:woods...@gmail.com>> wrote:
> 
>     On 23 June 2018 at 12:08, Allan Jude  <mailto:allanj...@freebsd.org>> wrote:
> 
> > If you just press shift a bunch of times, does it print the Mount root
> > prompt?
> > --
> > Allan Jude
> >
> 
> 
> No, unfortunately not. But please keep any troubleshooting suggestions
> coming!
> 
> I have tried booting with the KVM monitor and USB disconnected, with the
> same result.
> 
> It is also worth noting I can successfully boot from a USB stick running
> the latest 12-current snapshot
> FreeBSD-12.0-CURRENT-amd64-20180618-r335317-memstick.img. From there
> I can
> import both of my zpools (zroot and zstore), and then export them again
> before rebooting - still can't boot from disk.
> 
> --
> From: Benjamin Woods
> woods...@gmail.com <mailto:woods...@gmail.com>
> ___
> freebsd-current@freebsd.org <mailto:freebsd-current@freebsd.org>
> mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
> "freebsd-current-unsubscr...@freebsd.org
> <mailto:freebsd-current-unsubscr...@freebsd.org>"
> 

Warner: it is not that in this case, the screenshots show it getting
just past mountroot, so it is well into the kernel when it is stopping.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: Boot freezing after kernel load - root on zfs

2018-06-22 Thread Allan Jude
On June 22, 2018 10:13:31 PM EDT, Ben Woods  wrote:
>Hi everyone,
>
>After shutting down to connect a new IP KVM switch (VGA and USB), my
>FreeNAS mini hardware is no longer booting FreeBSD with root in zfs (no
>encryption) - it is getting stuck after the kernel finishes loading and
>it
>tries to mount root and start_init. It just stops printing any more
>output
>to the screen, but I know the keyboard is working as ctrl+alt+delete
>works.
>
>I wonder if this could be due to hard drives names being re-ordered
>(e.g.
>what was ada0 is now ada1). I have 2 SATA3 SSDs in a zfs mirror for
>root
>(showing as ada4 and ada5 during boot), and 4 SATA3 HDDs in a raidz2
>with
>geli for further storage (showing as ada0-3, but these are only mounted
>during rc init - after the point the boot process is getting stuck). I
>have
>no USB storage, although the IP KVM may present a virtual disk for
>loading
>media remotely.
>
>I am running 12-CURRENT, but know the recent upgrade is not the issue
>because I can’t load from the previous boot environment either.
>
>Is anyone able to recommend a fix or a way to troubleshoot further?
>Please
>see below a link with screenshots at the end of the boot where it gets
>stuck.
>
>https://imgur.com/gallery/vhn7ScC
>
>Thanks in advance for any help!
>
>Regards,
>Ben
>
>--
>From: Benjamin Woods
>woods...@gmail.com
>___
>freebsd-current@freebsd.org mailing list
>https://lists.freebsd.org/mailman/listinfo/freebsd-current
>To unsubscribe, send any mail to
>"freebsd-current-unsubscr...@freebsd.org"

If you just press shift a bunch of times, does it print the Mount root prompt?
-- 
Allan Jude
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: ZFS: I/O error - blocks larger than 16777216 are not supported

2018-06-20 Thread Allan Jude
   local
> zroot  feature@embedded_data active   
>  local
> zroot  feature@bookmarks enabled  
>  local
> zroot  feature@filesystem_limits enabled  
>  local
> zroot  feature@large_blocks  enabled  
>  local
> zroot  feature@sha512enabled  
>  local
> zroot  feature@skein enabled  
>  local
> zroot  unsupported@com.delphix:device_removalinactive 
>  local
> zroot  unsupported@com.delphix:obsolete_counts   inactive 
>  local
> zroot  unsupported@com.delphix:zpool_checkpoint  inactive 
>  local
> # 
> 
> Regards
> 
> [1] https://lists.freebsd.org/pipermail/freebsd-current/2018-March/068886.html
> [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=151910
> 
> ---
> KIRIYAMA Kazuhiko
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

I am guessing it means something is corrupt, as 16MB is the maximum size
of a record in ZFS. Also, the 'large_blocks' feature is 'enabled', not
'active', so this suggest you do not have any records larger than 128kb
on your pool.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: Current @ r335314 not bootable with Geli and ZFS

2018-06-19 Thread Allan Jude
On 2018-06-18 12:42, Thomas Laus wrote:
> Something changed in /boot/gptzfsboot between r334610 and r335314.  I
> built current this morning and my system is un-bootable.  I am using
> redundant ZFS disks and only copied the updated /boot/gptzfsboot file to
> my ada0 drive.  I was able to boot the ada1 drive that still had the
> gptzfsboot file from r334610.
> 
> I had a similar issue a few months ago with the upgrades to the Geli +
> ZFS booting process.  These were resolved and operation has been fine
> since the last 'hick-up' in the testing process.  I might not be the
> only person running the combination of Geli encryption and using a ZFS
> filesystem, but it should not be that much uncommon setup that I am the
> first to report the problem.
> 
> Let me know far back I need to revert my sources to identify the commit
> that broke gptzfsboot.  My system goes into a continuous reboot loop
> before presenting the password prompt.  It is very early in the startup
> process.
> 
> Tom
> 

We tested all of the changes with the setup in tools/boot/rootgen.sh, it
will be interesting to figure out what went wrong with your setup, and
add it as a test case to prevent this in the future.

The recent changes are:

r335245 (reading the size of the disk)
r335254 (reading past the end of the disk)
r335276 (enable the serial console sooner so the password prompt can be
used over serial)

There is also one outstanding fix: https://reviews.freebsd.org/D15847

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


Re: Proper way to remove never used ioctls

2018-06-02 Thread Allan Jude
On 2018-06-02 11:03, Warner Losh wrote:
> On Sat, Jun 2, 2018 at 7:33 AM, Vladimir Kondratyev 
> wrote:
> 
>> Hi,
>>
>> Our sys/mouse.h header has a definition of MOUSE_GETVARS and MOUSE_SETVARS
>> ioctls which are not documented and only stubbed in a few drivers: mse(4),
>> psm(4) and syscon's sysmouse(4). The only exception is MOUSE_GETVARS
>> implemented in psm(4)
>>
>> Given the fact that they were introduced 20 years ago, implementation was
>> never completed and googling on them shows no traces of usage in indexed
>> universe, is it acceptable to just drop both defines and implementation
>> w.o. leaving any COMPAT_FREEBSD shims?
> 
> 
> I'd prepare a patch just removing them. I'd then send that patch to the
> ports mgr team and request a exp-run. Details for that can be found in
> https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/ports.html
> 
> Once that's done, submit a Phabricator review and send me email. I'll make
> sure it gets pushed in if there's no objections.
> 
> Warner
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

This indeed seems to be the correct approach. The exp-run will compile
the entire ports tree against the patched base system, and identify any
3rd party software that fails to compile because of the change.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: Odd ZFS boot module issue on r332158

2018-04-09 Thread Allan Jude
On 2018-04-09 19:11, Andrew Gallatin wrote:
> I updated my main amd64 workstation to r332158 from something much
> earlier (mid Jan).
> 
> Upon reboot, all seemed well.  However, I later realized that the vmm.ko
> module was not loaded at boot, because bhyve PCI passthru did not
> work.  My loader.conf looks like (I'm passing a USB interface through):
> 
> ###
> vmm_load="YES"
> opensolaris_load="YES"
> zfs_load="YES"
> nvidia_load="YES"
> nvidia-modeset_load="YES"
> 
> # Tune ZFS Arc Size - Change to adjust memory used for disk cache
> vfs.zfs.arc_max="4096M"
> hint.xhci.2.disabled="1"
> pptdevs="8/0/0"
> hw.dmar.enable="0"
> cuse_load="YES"
> ###
> 
> The problem seems "random".  I rebooted into single-user to
> see if somehow, vmm.ko was loaded at boot and something
> was unloading vmm.ko.  However, on this boot it was loaded.  I then
> ^D'ed and continued to multi-user, where X failed to start because
> this time, the nvidia modules were not loaded.  (but nvidia had
> been loaded on the 1st boot).
> 
> So it *seems* like different modules are randomly not loaded by the
> loader, at boot.   The ZFS config is:
> 
> config:
> 
>     NAME    STATE READ WRITE CKSUM
>     tank    ONLINE   0 0 0
>   mirror-0  ONLINE   0 0 0
>     ada0p2  ONLINE   0 0 0
>     da3p2   ONLINE   0 0 0
>   mirror-1  ONLINE   0 0 0
>     ada1p2  ONLINE   0 0 0
>     da0p2   ONLINE   0 0 0
>     cache
>   da2s1d    ONLINE   0 0 0
> 
> The data drives in the pool are all exactly like this:
> 
> =>    34  9767541101  ada0  GPT  (4.5T)
>   34   6    - free -  (3.0K)
>   40  204800 1  efi  (100M)
>   204840  9763209216 2  freebsd-zfs  (4.5T)
>   9763414056 4096000 3  freebsd-swap  (2.0G)
>   9767510056   31079    - free -  (15M)
> 
> 
> There is about 1.44T used in the pool.  I have no idea
> how ZFS mirrors work, but I'm wondering if somehow this
> is a 2T problem, and there are issues with blocks on
> difference sides of the mirror being across the 2T boundary.
> 
> Sorry to be so vague.. but this is the one machine I *don't* have
> a serial console on, so I don't have good logs.
> 
> Drew
> 
> _______
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

What makes you think it is related to ZFS?

Are there any error messages when the nvidia module did not load?

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: ZFS i/o error in recent 12.0

2018-03-20 Thread Allan Jude
On 2018-03-20 10:29, Andriy Gapon wrote:
> On 20/03/2018 09:09, Trond Endrestøl wrote:
>> This step has been big no-no in the past. Never leave your 
>> bootpool/rootpool in an exported state if you intend to boot from it. 
>> For all I know, this advice might be superstition for the present 
>> versions of FreeBSD.
> 
> Yes, it is.  That does not matter at all now.
> 
>> From what I can tell from the above, you never created a new 
>> zpool.cache and copied it to its rightful place.
> 
> For the _rooot_ pool zpool.cache does not matter as well.
> It matters only for auto-import of additional pools, if any.
> 

As I mentioned previously, the error reported by the user is before it
is even possible to read zpool.cache, so it is definitely not the source
of the problem.

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


Re: ZFS i/o error in recent 12.0

2018-03-19 Thread Allan Jude
  4.33G  13.9T  2.75G  /mnt/vm
> zroot/vm/tbedfc   1.58G  13.9T  1.58G  /mnt/vm/tbedfc
> # zfs mount zroot/ROOT/default
> # cd /mnt/mnt/
> # mv boot boot.bak
> # cp -RPp boot.bak boot
> # gpart show /dev/mfid0
> => 40  31247564720  mfid0  GPT  (15T)
>40   409600  1  efi  (200M)
>409640 1024  2  freebsd-boot  (512K)
>410664  984 - free -  (492K)
>411648268435456  3  freebsd-swap  (128G)
> 268847104  30978715648  4  freebsd-zfs  (14T)
>   31247562752 2008 - free -  (1.0M)
> 
> # gpart bootcode -b /mnt/mnt/boot/pmbr -p /boot/gptzfsboot -i 2 mfid0
> partcode written to mfid0p2
> bootcode written to mfid0
> # cd
> # zpool export zroot
> # 
> 
> But can not boot:
> 
> ZFS: i/o error - all block copies unavailable
> ZFS: can't read MOS of pool zroot
> gptzfsboot: failed to mount default pool zroot
> 
> FreeBSD/x86 boot
> 
> Any idea?
> 
> Best regards
> 
> [1] http://ds.truefc.org/~kiri/freebsd/current/zfs/messages
> [2] 
> https://lists.freebsd.org/pipermail/freebsd-questions/2016-February/270505.html
> [3] 
> https://forums.freebsd.org/threads/zfs-i-o-error-all-block-copies-unavailable-invalid-format.55227/#post-312830
> 
> ---
> KIRIYAMA Kazuhiko
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

Since you were about to 'zpool import' on the USB stick, this suggests
the problem is with the boot blocks, not ZFS.

The early boot phase (gptzfsboot) does not read zpool.cache, since that
only lives ON the pool, and the pool has not been imported yet.

Maybe kevans@ or imp@ who have been working on the boot code have some
insight.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: Panic on shutdown @r328436: "Unholding 6 with cnt = -559038242"

2018-01-28 Thread Allan Jude
On 2018-01-28 21:29, Warner Losh wrote:
> 
> I've been seeing this today while working on my laptop.
> 
> 1) insert USB stick.
> 2) mount UFS partition to /mnt
> 3) copy a file off
> 4) umount /mnt
> 5) remove usb stick
> 6) instant panic
> 
> Oddly, it is the same negative number every time (-559038242), so it
> isn't random/memory corruption.
> 
> 
> 
> Is mount required?
> 
> Warner 
> 
> 
No, I just plugged the USB stick in, and then removed it 10 seconds
later, panic.

I've also seen it in VirtualBox when removing a virtual CD (.iso)


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


Re: Panic on shutdown @r328436: "Unholding 6 with cnt = -559038242"

2018-01-28 Thread Allan Jude
 0x80a112da in g_run_events ()
>> at /usr/src/sys/geom/geom_event.c:297
>> #18 0x80a89444 in fork_exit (
>> callout=0x80a138c0 , arg=0x0,
>> frame=0xfe0059383ac0) at /usr/src/sys/kern/kern_fork.c:1039
>> #19 
>> (kgdb)
>>
>>
>> uname -a
>> FreeBSD laptopW530.tommyBSD.org 12.0-CURRENT FreeBSD 12.0-CURRENT #13
>> r328509M: Sun Jan 28 15:38:35 CET 2018
>> to...@laptopw530.tommybsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
>> amd64
>>
>> Regards,
>> thomas
>>
>>
>> On Fri, Jan 26, 2018 at 4:07 PM, David Wolfskill <da...@catwhisker.org>
>> wrote:
>>
>>> On Fri, Jan 26, 2018 at 07:47:48AM -0700, Warner Losh wrote:
>>>> On Fri, Jan 26, 2018 at 5:29 AM, David Wolfskill <da...@catwhisker.org
>>>
>>>> wrote:
>>>>
>>>>> This is on my "build machine" (laptop is still building updated ports
>>>>> for today, so I don't know yet whether or not it encounters this.)
>>>>>
>>>>
>>>> Running a kernel with INVARIANTS, right?
>>>
>>> Yes -- GENERIC.
>>>
>>>>> I had performed a source-based update from r328393 to r328436,
>>>>> rebooted, performed "make delete-old-libs", and all seemed well.
>>>>>
>>>>
>>>> This has my change 328415 in it.
>>>
>>> :-)
>>>
>>>>> I then issued "sudo shutdown -p now", and serial console shows:
>>>>> panic: Unholding 6 with cnt = -559038242
>>>>> cpuid = 3
>>>>> time = 1516968697
>>>>> KDB: stack backtrace:
>>>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
>>>>> 0xfe4288c0
>>>>> vpanic() at vpanic+0x18d/frame 0xfe428920
>>>>> panic() at panic+0x43/frame 0xfe428980
>>>>> dadiskgonecb() at dadiskgonecb+0x42/frame 0xfe4289a0
>>>>> g_disk_providergone() at g_disk_providergone+0x25/frame
>>> 0xfe4289d0
>>>>> g_destroy_provider() at g_destroy_provider+0xae/frame
>>> 0xfe4289f0
>>>>> g_wither_washer() at g_wither_washer+0x87/frame 0xfe428a30
>>>>> g_run_events() at g_run_events+0x3ca/frame 0xfe428a70
>>>>> fork_exit() at fork_exit+0x84/frame 0xfe428ab0
>>>>> fork_trampoline() at fork_trampoline+0xe/frame 0xfe428ab0
>>>>> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
>>>>> KDB: enter: panic
>>>>> [ thread pid 13 tid 100044 ]
>>>>> Stopped at  kdb_enter+0x3b: movq$0,kdb_why
>>>>> db>
>>>>>
>>>>
>>>> That's no good. We're releasing a reference to the da peripheral
>> because
>>>> geom has finished with the disk and is giving us a final callback so we
>>> can
>>>> drop the reference we took when we created the geom. Trouble is, cnt
>>> should
>>>> be like 1 always for this code, but it's not. It looks like it may be
>>> bytes
>>>> to a pointer :(
>>>>
>>>>
>>>>> As noted, this is a build machine, and it was to be powered off for
>>>>> the rest of the day anyway, so I don't need to get it up & running
>>>>> immediately: I can poke at the ddb prompt, given some clues.
>>>>>
>>>>
>>>> I don't suppose you can attach kgdb to this machine? I'd be interested
>> to
>>>> see what the contents of the softc are...a
>>>
>>> Pointer to how to do that?
>>>
>>> I do have ddb right now
>>>
>>>> 
>>>> Thanks for the report. This is quite troubling.
>>>
>>> Well, let's get it fixed, then! :-)
>>>
>>>> Warner
>>>> 
>>>
>>> I should still have access to the serial console after I get in to the
>>> office (heading out shortly).
>>>
>>> Peace,
>>> david
>>> --
>>> David H. Wolfskill  da...@catwhisker.org
>>> "unfortunately, no trust!” -- well, of course!  You reap what you sow.
>>>
>>> See http://www.catwhisker.org/~david/publickey.gpg for my public key.
>>>
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

I've been seeing this today while working on my laptop.

1) insert USB stick.
2) mount UFS partition to /mnt
3) copy a file off
4) umount /mnt
5) remove usb stick
6) instant panic

Oddly, it is the same negative number every time (-559038242), so it
isn't random/memory corruption.


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


Re: ZFS: alignment/boundary for partition type freebsd-zfs

2017-12-26 Thread Allan Jude
On 2017-12-26 11:24, O. Hartmann wrote:
> Running recent CURRENT on most of our lab's boxes, I was in need to replace 
> and restore a
> ZFS RAIDZ pool. Doing so, I was in need to partition the disks I was about to 
> replace.
> Well, the drives in question are 4k block size drives with 512b emulation - 
> as most of
> them today. I've created the only and sole partiton on each 4 TB drive via 
> the command
> sequence
> 
> gpart create -s GPT adaX
> gpart add -t freebsd-zfs -a 4k -l nameXX adaX
> 
> After doing this on all drives I was about to replace, something drove me to 
> check on
> the net and I found a lot of websites giving "advices", how to prepare large, 
> modern
> drives for ZFS. I think the GNOP trick is not necessary any more, but many 
> blogs
> recommend to perform
> 
> gpart add -t freebsd-zfs -b 1m -a 4k -l nameXX adaX
> 
> to put the partition boundary at the 1 Megabytes boundary. I didn't do that. 
> My
> partitions all start now at block 40.
> 
> My question is: will this have severe performance consequences or is that 
> negligible?
> 
> Since most of those websites I found via "zfs freebsd alignement" are from 
> years ago, I'm
> a bit confused now an consideration performing all this days-taking 
> resilvering process
> let me loose some more hair as the usual "fallout" ...
> 
> Thanks in advance,
> 
> Oliver
> 

The 1mb alignment is not required. It is just what I do to leave room
for the other partition types before the ZFS partition.

However, the replacement for the GNOP hack, is separate. In addition to
aligning the partitions to 4k, you have to tell ZFS that the drive is 4k:

sysctl vfs.zfs.min_auto_ashift=12

(2^12 = 4096)

Before you create the pool, or add additional vdevs.

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


Re: ZFS RAIDZ1: resilvering at <17.3M/s => abyssal slow ...

2017-12-14 Thread Allan Jude
On 2017-12-14 09:52, O. Hartmann wrote:
> Am Thu, 14 Dec 2017 15:46:17 +0100
> Dimitry Andric <d...@freebsd.org> schrieb:
> 
>> On 14 Dec 2017, at 14:43, O. Hartmann <ohartm...@walstatt.org> wrote:
>>>
>>> Am Thu, 14 Dec 2017 14:09:39 +0100
>>> Daniel Nebdal <dneb...@gmail.com> schrieb:  
>>>> On Thu, Dec 14, 2017 at 12:48 PM, O. Hartmann <ohartm...@walstatt.org> 
>>>> wrote:  
>>>>> I just started the rebuild/resilvering process and watch the pool 
>>>>> crwaling at ~ 18
>>>>> MB/s. At the moment, there is no load on the array, the host is a 
>>>>> IvyBridge XEON
>>>>> with 4 core/8 threads and 3,4 GHz and 16 GB of RAM. The HDDs are attached 
>>>>> to a
>>>>> on-board SATA II (300 MB/s max) Intel chip - this just for the record.
>>>>>
>>>>> Recently, I switch on the "sync" attribute on most of the defined pools's 
>>>>> zfs
>>>>> filesystems
>>>>> - I also use a SSD for ZIL/L2ARC caching, but it seems to be unused 
>>>>> recently in
>>>>> FreeBSD CURRENT's ZFS - this from a observers perspective only.
>>>>>
>>>>> When scrubbing, I see recently also reduced performance on the pool, so 
>>>>> I'm
>>>>> wondering about the low throughput at the very moment when resilvering is 
>>>>> in
>>>>> progress.
>>>>>
>>>>> If the "perspective" of "zpool status" is correct, then I have to wait 
>>>>> after two
>>>>> hours for another 100 hours - ~ 4 days? Ups ... I think there is 
>>>>> something badly
>>>>> misconfigured or missing.  
>> ...
>>>> This is kind of to be expected - for whatever reason, resilvers seem
>>>> to go super slow at first and then speed up significantly. Just don't
>>>> ask me how long "at first" is - I'd give it several (more) hours.  
>>
>> Hopefully this will get better in the future, please read:
>>
>> http://open-zfs.org/wiki/Scrub/Resilver_Performance
>>
>> -Dimitry
>>
> 
> It has already been started to become better ;-)
> 
> After a while now, the throughput is at 128 MBytes/s and the estimated time 
> decreased to
> ~ 8 h now - that is much more appreciable than 4 days ;-)
> 
> Kind regards,
> Oliver
> 
> 

The time estimate is a pure average over the entire length of the scrub
or resilver operation. The very start of the operation is quite slow,
because it involves a lot of random seeks, and the read-ahead is not
very smart (patches are in progress). And yes, after you adjust the
resilver_delay, it will take time for its impact to be visible in 'zpool
status'.

At times, you are better off looking at 'gstat', to see how busy the
disks actually are. You will likely notice the bottleneck is IOPS, you
will be at the limit of at least one the entire duration of the
resilver, unless your resilver_delay is high enough to leave some
available IOPS.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: kernel names

2017-12-13 Thread Allan Jude
On 12/14/2017 00:47, blubee blubeeme wrote:
> When you boot into FreeBSD and you can select kernels, there's only 2
> options:
> default and kernel.old
> 
> Is there a way to have better output and support multiple kernels without
> having to login to the system and running uname -v or something like that?
> 
> Would it be possible to add options for more kernels from that boot menu?
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

The list is controlled by the /boot/loader.conf variable kernels=
which defaults to "kernel kernel.old"

I have a patch almost ready to land that will search all subdirectories
of /boot for a file named 'kernel' and add the names of those
directories to the list, such that the list will basically be autogenerated.

It currently contains too much copy/pasted code, and I just need to
clean it up a bit: https://reviews.freebsd.org/D11886

It was originally designed as part of my contributions towards packaged
base, where pkg will keep the last N (default to 5 I think) kernel
packages you have installed around, incase an upgrade goes bad.

This feature will work on any filesystem supported by the loader.

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


Re: [HEADS UP] posix_fallocate support removed from ZFS, lld affected

2017-11-06 Thread Allan Jude
On 2017-11-06 12:26, Ian Lepore wrote:
> On Mon, 2017-11-06 at 17:40 +0200, Andriy Gapon wrote:
>> From UPDATING:
>> The naive and non-compliant support of posix_fallocate(2) in ZFS
>> has been removed as of r325320.  The system call now returns EINVAL
>> when used on a ZFS file.  Although the new behavior complies with the
>> standard, some consumers are not prepared to cope with it.
>> One known victim is lld prior to r325420.
>>
> 
> It just popped into my head... does this mean that kernels running
> r325320+ on systems using ZFS will be unable to host build jails for
> earlier versions / branches because lld will fail in the jail?
> 
> I think that will be a big problem for the ports team's package
> building process, and for anyone using poudriere.
> 
> -- Ian
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

lld is not the default on amd64 yet. So only people who have set the
src.conf knob, or are building a platform like aarch64 that uses lld by
default, would be impacted.

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

Re: FreeBSD Documentation

2017-10-29 Thread Allan Jude
On 2017-10-29 11:00, Kurt Jaeger wrote:
> Hi!
> 
>> How can we suggest edits for the docs?
> 
> Checkout the docs repo:
> 
>   svn checkout https://svnweb.freebsd.org/doc/head/ .
> 
> Change the relevant files, create a new problem report on
> 
>   https://bugs.freebsd.org/
> 
> and attach the svn diff to that problem report.
> 

Since the document in question is a man page, it actually lives in the
src tree.

svn checkout https://svn.freebsd.org/base/head/ .

cd usr.sbin/jail

vi jail.8

svn diff > jail_manpage.patch

And then attach that patch to a bugzilla, or upload it to
reviews.freebsd.org


-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: /sys/boot compile broken

2017-10-21 Thread Allan Jude
On 2017-10-21 02:41, Gary Jennejohn wrote:
> SVN for HEAD source at 324810.
> 
> Compiling /sys/boot is totally screwed up.  The failure is that
> geliboot.c cannot be found.
> 
> This prevents a successful ``make buildworld''.
> 
> This error occurs despite the fact that I have LOADER_NO_GELI_SUPPORT
> set to yes in src.conf.
> 
> Looking at the various Makefiles this option is supposed to prevent
> using GELI.
> 
> Even if the user wanted to use GELI the compile of the boot code
> would probably fail.
> 
> imp@ has had his fingers in the boot code lately.
> 

Some of the boot code has been changed over to LOADER_GELI_SUPPORT=no

And so you ended up with some code not guarded. Add the additional
src.conf knob for now, and Warner will get it fixed up shortly.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: cve-2017-13077 - WPA2 security vulni

2017-10-17 Thread Allan Jude
On 2017-10-17 08:58, David Wolfskill wrote:
> On Mon, Oct 16, 2017 at 11:27:00PM -0700, Cy Schubert wrote:
>> In message <fe754a9e-be47-4843-ab3a-2619665f1...@lastsummer.de>, Franco 
>> Fichtne
>> r writes:
>> ...
>>> wpa_supplicant  2.6_2
>>>
>>> No apparent issues with the ports, preliminary connectivity
>>> checks work as expected.  Started a public CFT over at OPNsense
>>> to gather more feedback.
>>
>> Agreed.
>> 
> 
> First: Thank you for doing this, Cy.
> 
> I am now (also) running wpa_supplicant-2.6_2 successfully on my laptop
> (when it's running stable/11).
> 
> I did have one mild surprise: I had rebooted my laptop to verify that
> the ports version of wpa_supplicant would work, and as the screen went
> dark, I recalled that I had failed to copy /etc/wpa_supplicant.conf to
> /usr/local/etc -- but my concern proved to be unfounded: the
> wpa_supplicant.conf in /etc/ was used (successfully).
> 
> Question:  Should one expect a wpa_supplicant-2.6_2 executable built
> under FreeBSD stable/11 (amd64) to work on the same hardware, but
> running head?

Did you run the version from ports, or did you run the base /etc/rc.d
script with your rc.conf set to point to the ports binary? This will run
the command with -c /etc/wpa_supplicant.conf overriding the ports default.

So this is expected to work in this way.

> 
> For reasons that are (at best) tangential to this topic, I track,
> build, and smoke-test both stable/11 and head daily, but only build
> the ports (daily) under (the just-built/booted) stable/11 -- depending
> on misc/compat11 to handle things as necessary for head.  This works
> (well, IMO)... except that when I had configured my "head slice"
> to use the ports version of wpa_supplicant, the latter was apparently
> not happy:
> 
> ...
> Oct 17 11:06:13 localhost kernel: wlan0: Ethernet address: 00:24:d6:7a:03:ce
> Oct 17 11:06:13 localhost wpa_supplicant[1279]: Successfully initialized 
> wpa_supplicant
> Oct 17 11:06:14 localhost wpa_supplicant[1279]: ioctl[SIOCS80211, op=98, 
> arg_len=32]: Invalid argument
> Oct 17 11:06:14 localhost wpa_supplicant[1279]: failed to 
> IEEE80211_IOC_DEVCAPS: Invalid argument
> Oct 17 11:06:14 localhost wpa_supplicant[1279]: wlan0: Failed to initialize 
> driver interface
> Oct 17 11:06:14 localhost root: /etc/rc.d/wpa_supplicant: WARNING: failed to 
> start wpa_supplicant
> 
> 
> The laptop spends the vast bulk of its time running stable/11, so
> the threat is somewhat mitigated
> 
> Peace,
> david
> 


-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: Encrypted Swap Problem with 12.0-CURRENT r324427

2017-10-10 Thread Allan Jude
On 10/10/2017 16:15, Thomas Laus wrote:
> I have been having some boot issues after upgrading to r324427 this
> week.  It gets to the step of accessing my Geli encrypted swap partition
> and then drops to the ddb> prompt.  Sometimes it works but mostly it
> does not.  Booting with r323984 is flawless.  Has anything been changed
> between these 2 revisions that would affect me?  Booting in single
> usermode works fine on r324427 but immediately goes to the ddb> prompt
> when terminating with a 'ctrl-d' to go into multi-user mode.
> 
> Is there anything that I might have missed in the UPDATING instruction
> that might cause this.  I don't have any errors on this partition that
> gpart status finds.
> 
> Tom
> 
> 

Before the ddb> prompt there should be a message explaining what has
gone wrong to make it drops into the debugger. If it has scrolled off
the top of the screen, press scroll-lock and then you can use the arrow
keys to navigate back up into the buffer.

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


Re: Booting native 4K SSD disk from FreeBSD ?

2017-10-04 Thread Allan Jude
On 2017-10-04 05:27, Thomas Mueller wrote:
> from Allan Jude:
> 
>>> Anyone has any recommendations or experience about how to use native 4K
>>> disks with FreeBSD?
> 
>>> --HPS
> 
>> It is not possible in legacy/BIOS mode, because the BIOS calls do not
>> let you specify a sector size.
>  
>> However, you SHOULD be able to boot from the 4k device using UEFI.
>> I am trying to debug a problem I am having with this on my new Mac,
>> which has a 4k NVMe disk.
> 
> I've been trying to figure how to boot a FreeBSD system with UEFI as opposed 
> to BIOS-style.
> 
> I read the documentation, but want to boot a partition that might not be the 
> first BSD partition on the hard disk.
> 
> For instance, some UFS partitions might have a NetBSD installation, a 
> different FreeBSD installation, or no OS installation.
> 
> I read the man page (uefi) and looked at the files in /boot; have an EFI 
> partition set up with more than enough space.
> 
> I would also want to be able to boot other UEFI-capable OSes including Linux, 
> NetBSD (if that works), and Haiku when and if possible. 
> 
> Tom
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

In this case, You likely want to install a tool like rEFInd, which will
draw a menu of all of the installed OSes and let you pick.

I use this in two of my laptops, one dual boots freebsd and windows, and
the other OS X and FreeBSD on my macbook pro

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


Re: Booting native 4K SSD disk from FreeBSD ?

2017-10-03 Thread Allan Jude
On 10/03/2017 17:18, Hans Petter Selasky wrote:
> Hi,
> 
> I accidentially ordered a Sata SSD disk which diskinfo reports a
> sector-size 4K instead of 512 bytes. Trying to get it to boot under
> FreeBSD appeared impossible. Then I started looking into the boot0,1,2
> and loader and the assumptions they make about 512 byte sector size LBA :-(
> 
> Anyone has any recommendations or experience about how to use native 4K
> disks with FreeBSD?
> 
> --HPS
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

It is not possible in legacy/BIOS mode, because the BIOS calls do not
let you specify a sector size.

However, you SHOULD be able to boot from the 4k device using UEFI.
I am trying to debug a problem I am having with this on my new Mac,
which has a 4k NVMe disk.

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


Re: Extra Clang Tools

2017-09-15 Thread Allan Jude
On 2017-09-15 22:29, blubee blubeeme wrote:
> FreeBSD switched to clang as it's compiler some time ago; was clang extra
> tools: http://clang.llvm.org/extra/index.html ever ported over?
> 
> If yes, where is it located?
> Best
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

I think you can enable most of them by adding WITH_CLANG_EXTRAS=yes to
/etc/src.conf and recompiling.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: beadm activate, cp: /tmp/BE-.../boot/zfs/zpool.cache: No such file or directory

2017-07-11 Thread Allan Jude
70p/poudriere/data/cache on /usr/local/poudriere/data/cache
> (zfs, local, noatime, nfsv4acls)
> hpelitebook8570p/poudriere/data/logs on /usr/local/poudriere/data/logs
> (zfs, local, noatime, nfsv4acls)
> hpelitebook8570p/poudriere/data/packages on
> /usr/local/poudriere/data/packages (zfs, local, noatime, nfsv4acls)
> hpelitebook8570p/poudriere/data/wrkdirs on
> /usr/local/poudriere/data/wrkdirs (zfs, local, noatime, nfsv4acls)
> hpelitebook8570p/poudriere/jails/current on
> /usr/local/poudriere/jails/current (zfs, local, noatime, nfsv4acls)
> hpelitebook8570p/poudriere/ports/freebsd-ports-kde on
> /usr/local/poudriere/ports/freebsd-ports-kde (zfs, local, noatime,
> nfsv4acls)
> hpelitebook8570p/usr/ports on /usr/ports (zfs, local, noatime, nosuid,
> nfsv4acls)
> hpelitebook8570p/usr/src on /usr/src (zfs, local, noatime, nfsv4acls)
> hpelitebook8570p/var/VirtualBox on /var/VirtualBox (zfs, local, noatime,
> nfsv4acls)
> hpelitebook8570p/var/audit on /var/audit (zfs, local, noatime, noexec,
> nosuid, nfsv4acls)
> hpelitebook8570p/var/crash on /var/crash (zfs, local, noatime, noexec,
> nosuid, nfsv4acls)
> hpelitebook8570p/var/log on /var/log (zfs, local, noatime, noexec,
> nosuid, nfsv4acls)
> hpelitebook8570p/var/mail on /var/mail (zfs, local, nfsv4acls)
> hpelitebook8570p/var/tmp on /var/tmp (zfs, local, noatime, nosuid,
> nfsv4acls)
> linprocfs on /compat/linux/proc (linprocfs, local)
> tmpfs on /compat/linux/dev/shm (tmpfs, local)
> fdescfs on /dev/fd (fdescfs)
> hpelitebook8570p/ROOT/2017-07-11-09 on /tmp/BE-2017-07-11-09.H0k1WFYJ
> (zfs, local, noatime, nfsv4acls)
> # zfs list
> NAME USED  AVAIL REFER 
> MOUNTPOINT
> bootpool 135M  1.73G 133M 
> /bootpool
> hpelitebook8570p78.2G   352G 88K 
> /hpelitebook8570p
> hpelitebook8570p/ROOT   8.27G   352G 88K  none
> hpelitebook8570p/ROOT/2017-07-11-098K   352G 8.27G 
> /tmp/BE-2017-07-11-09.H0k1WFYJ
> hpelitebook8570p/ROOT/default   8.27G   352G 8.27G  /
> hpelitebook8570p/poudriere  3.62G   352G 88K 
> /hpelitebook8570p/poudriere
> hpelitebook8570p/poudriere/data  732M   352G 96K 
> /usr/local/poudriere/data
> hpelitebook8570p/poudriere/data/.m88K   352G 88K 
> /usr/local/poudriere/data/.m
> hpelitebook8570p/poudriere/data/cache   12.6M   352G 12.6M 
> /usr/local/poudriere/data/cache
> hpelitebook8570p/poudriere/data/logs42.8M   352G 42.8M 
> /usr/local/poudriere/data/logs
> hpelitebook8570p/poudriere/data/packages 676M   352G 676M 
> /usr/local/poudriere/data/packages
> hpelitebook8570p/poudriere/data/wrkdirs   88K   352G 88K 
> /usr/local/poudriere/data/wrkdirs
> hpelitebook8570p/poudriere/jails 949M   352G 88K 
> /hpelitebook8570p/poudriere/jails
> hpelitebook8570p/poudriere/jails/current 948M   352G 948M 
> /usr/local/poudriere/jails/current
> hpelitebook8570p/poudriere/ports1.98G   352G 88K 
> /hpelitebook8570p/poudriere/ports
> hpelitebook8570p/poudriere/ports/freebsd-ports-kde  1.98G   352G 1.98G 
> /usr/local/poudriere/ports/freebsd-ports-kde
> hpelitebook8570p/tmp15.9M   352G 15.9M 
> /tmp
> hpelitebook8570p/usr66.2G   352G 88K  /usr
> hpelitebook8570p/usr/home   64.3G   352G 547M 
> /usr/home
> hpelitebook8570p/usr/home/grahamperrin  63.7G   352G 58.2G 
> /usr/home/grahamperrin
> hpelitebook8570p/usr/ports  1.34G   352G 1.34G 
> /usr/ports
> hpelitebook8570p/usr/src 638M   352G 638M 
> /usr/src
> hpelitebook8570p/var1.25M   352G 88K  /var
> hpelitebook8570p/var/VirtualBox   88K   352G 88K 
> /var/VirtualBox
> hpelitebook8570p/var/audit88K   352G 88K 
> /var/audit
> hpelitebook8570p/var/crash88K   352G 88K 
> /var/crash
> hpelitebook8570p/var/log 684K   352G 684K 
> /var/log
> hpelitebook8570p/var/mail152K   352G 152K 
> /var/mail
> hpelitebook8570p/var/tmp  88K   352G 88K 
> /var/tmp
> #
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Boot environments with a bootpool do not work. Support for GELI with
UEFI is coming soon. This will allow you to move /boot into the GELI
encrypted pool, and get rid of the bootpool, and properly use boot
environments.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: [SOLVED] [memstick install] auto-zfs error

2017-07-10 Thread Allan Jude
On 2017-07-09 14:40, Boris Samorodov wrote:
> 08.07.2017 18:56, Boris Samorodov пишет:
>> Hi All,
>>
>> I tied to install a new FreeBSD-amd-12 system from official USB
>> installation memstick.img. Auto-UFS (GPT) installs fine and the system
>> boots fine. However, ZFS-Auto install succeeds, but is not loaded.
>> At the very beginning it gives something like "gpt sector  error,
>> gpt sector 1 error, can't find zroot..."
>>
>> Is it a known error / should I give more (precise) errors?
>>
>> I tried two recent images with the same result:
>> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20170703-r320599-memstick.img
>> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20170626-r320360-memstick.img
> 
> It turned out GPT and zfs are not usable at this machine.
> MBR / ZFS works fine.
> 
> I'll stick with that.
> 

What type of machine is it?

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: Crash in base/head in abd_put() after r320156

2017-06-20 Thread Allan Jude
On 2017-06-20 17:45, Trond Endrestøl wrote:
> On Tue, 20 Jun 2017 17:31-0400, Allan Jude wrote:
> 
>> On 2017-06-20 17:27, Trond Endrestøl wrote:
>>> Has anyone else seen a crash in base/head in abd_put() after r320156?
>>>
>>> One of my experimental VMs at home crashed spectacularly after 
>>> upgrading to r320156. I even wiped my /usr/obj, recompiled everything 
>>> and got the same result. Everything's back to normal when I boot 
>>> r320146.
>>>
>>> Here's the backtrace:
>>>
>>> Fatal trap 12: page fault while in kernel mode
>>> cpuid = 3; apic id = 03
>>>
>>> fault virtual address   = 0x8
>>>
>>> Fatal trap 12: page fault while in kernel mode
>>>
>>> cpuid = 2; 
>>> Fatal trap 12: page fault while in kernel mode
>>> apic id = 02
>>> fault virtual address   = 0x8
>>> cpuid = 0; apic id = 00
>>> fault virtual address   = 0x8
>>> fault code  = supervisor read data, page not present
>>> fault code  = supervisor read data, page not present
>>> instruction pointer = 0x20:0x803260fa
>>> stack pointer   = 0x28:0xfe01b0231860
>>> frame pointer   = 0x28:0xfe01b0231870
>>> code segment= base 0x0, limit 0xf, type 0x1b
>>>
>>> = DPL 0, pres 1, long 1, def32 0, gran 1
>>>
>>> Fatal trap 12: page fault while in kernel mode
>>> fault code  = supervisor read data, page not present
>>> processor eflags= interrupt enabled, resume, IOPL = 0
>>> current process = 0 (zio_free_issue_5_2)
>>> trap number = 12
>>> instruction pointer = 0x20:0x803260fa
>>> stack pointer   = 0x28:0xfe01b022c860
>>> frame pointer   = 0x28:0xfe01b022c870
>>> panic: page fault
>>> cpuid = 0
>>> time = 4
>>> KDB: stack backtrace:
>>> db_trace_self_wrapper() at 0x8044f93b = 
>>> db_trace_self_wrapper+0x2b/frame 0xfe01b0231440
>>> vpanic() at 0x8067ec0c = vpanic+0x19c/frame 0xfe01b02314c0
>>> panic() at 0x8067ea63 = panic+0x43/frame 0xfe01b0231520
>>> trap_fatal() at 0x80983b32 = trap_fatal+0x322/frame 
>>> 0xfe01b0231570
>>> trap_pfault() at 0x80983b89 = trap_pfault+0x49/frame 
>>> 0xfe01b02315d0
>>> trap() at 0x809833c5 = trap+0x295/frame 0xfe01b0231790
>>> calltrap() at 0x80968c21 = calltrap+0x8/frame 0xfe01b0231790
>>> --- trap 0xc, rip = 0x803260fa, rsp = 0xfe01b0231860, rbp = 
>>> 0xfe01b0231870 ---
>>> abd_put() at 0x803260fa = abd_put+0xa/frame 0xfe01b0231870
>>> vdev_raidz_map_free() at 0x803aa7c2 = 
>>> vdev_raidz_map_free+0x82/frame 0xfe01b02318a0
>>> zio_vdev_io_assess() at 0x803ecc04 = zio_vdev_io_assess+0x74/frame 
>>> 0xfe01b02318e0
>>> zio_execute() at 0x803e913c = zio_execute+0xac/frame 
>>> 0xfe01b0231930
>>> zio_vdev_io_start() at 0x803ec894 = zio_vdev_io_start+0x2b4/frame 
>>> 0xfe01b0231990
>>> zio_execute() at 0x803e913c = zio_execute+0xac/frame 
>>> 0xfe01b02319e0
>>> zio_nowait() at 0x803e8a8b = zio_nowait+0xcb/frame 
>>> 0xfe01b0231a20
>>> vdev_mirror_io_start() at 0x803a744c = 
>>> vdev_mirror_io_start+0x35c/frame 0xfe01b0231a70
>>> zio_vdev_io_start() at 0x803ec86c = zio_vdev_io_start+0x28c/frame 
>>> 0xfe01b0231ad0
>>> zio_execute() at 0x803e913c = zio_execute+0xac/frame 
>>> 0xfe01b0231b20
>>> taskqueue_run_locked() at 0x806d3d27 = 
>>> taskqueue_run_locked+0x127/frame 0xfe01b0231b80
>>> taskqueue_thread_loop() at 0x806d4ee8 = 
>>> taskqueue_thread_loop+0xc8/frame 0xfe01b0231bb0
>>> fork_exit() at 0x80640df5 = fork_exit+0x85/frame 0xfe01b0231bf0
>>> fork_trampoline() at 0x8096915e = fork_trampoline+0xe/frame 
>>> 0xfe01b0231bf0
>>> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
>>> Uptime: 4s
>>>
>>
>> This seems to be an unintended consequence of some code that was pulled
>> in from upstream today.
>>
>> Try adding: vfs.zfs.trim.enabled=0
>> to /boot/loader.conf
>>
>> (you can set it manually from the boot loader menu with the set command
>> to get the system to boot)
> 
> That worked. Thanks.
> 
> BTW, the call to abd_put() was given a NULL pointer.
> 

Yeah, if you want more detail, there is a thread on
svn-src-h...@freebsd.org that discusses it. Should be fixed tomorrow.

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

Re: Crash in base/head in abd_put() after r320156

2017-06-20 Thread Allan Jude
On 2017-06-20 17:27, Trond Endrestøl wrote:
> Has anyone else seen a crash in base/head in abd_put() after r320156?
> 
> One of my experimental VMs at home crashed spectacularly after 
> upgrading to r320156. I even wiped my /usr/obj, recompiled everything 
> and got the same result. Everything's back to normal when I boot 
> r320146.
> 
> Here's the backtrace:
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 3; apic id = 03
> 
> fault virtual address = 0x8
> 
> Fatal trap 12: page fault while in kernel mode
> 
> cpuid = 2; 
> Fatal trap 12: page fault while in kernel mode
> apic id = 02
> fault virtual address = 0x8
> cpuid = 0; apic id = 00
> fault virtual address = 0x8
> fault code= supervisor read data, page not present
> fault code= supervisor read data, page not present
> instruction pointer   = 0x20:0x803260fa
> stack pointer = 0x28:0xfe01b0231860
> frame pointer = 0x28:0xfe01b0231870
> code segment  = base 0x0, limit 0xf, type 0x1b
> 
>   = DPL 0, pres 1, long 1, def32 0, gran 1
> 
> Fatal trap 12: page fault while in kernel mode
> fault code= supervisor read data, page not present
> processor eflags  = interrupt enabled, resume, IOPL = 0
> current process   = 0 (zio_free_issue_5_2)
> trap number   = 12
> instruction pointer   = 0x20:0x803260fa
> stack pointer = 0x28:0xfe01b022c860
> frame pointer = 0x28:0xfe01b022c870
> panic: page fault
> cpuid = 0
> time = 4
> KDB: stack backtrace:
> db_trace_self_wrapper() at 0x8044f93b = 
> db_trace_self_wrapper+0x2b/frame 0xfe01b0231440
> vpanic() at 0x8067ec0c = vpanic+0x19c/frame 0xfe01b02314c0
> panic() at 0x8067ea63 = panic+0x43/frame 0xfe01b0231520
> trap_fatal() at 0x80983b32 = trap_fatal+0x322/frame 0xfe01b0231570
> trap_pfault() at 0x80983b89 = trap_pfault+0x49/frame 
> 0xfe01b02315d0
> trap() at 0x809833c5 = trap+0x295/frame 0xfe01b0231790
> calltrap() at 0x80968c21 = calltrap+0x8/frame 0xfe01b0231790
> --- trap 0xc, rip = 0x803260fa, rsp = 0xfe01b0231860, rbp = 
> 0xfe01b0231870 ---
> abd_put() at 0x803260fa = abd_put+0xa/frame 0xfe01b0231870
> vdev_raidz_map_free() at 0x803aa7c2 = vdev_raidz_map_free+0x82/frame 
> 0xfe01b02318a0
> zio_vdev_io_assess() at 0x803ecc04 = zio_vdev_io_assess+0x74/frame 
> 0xfe01b02318e0
> zio_execute() at 0x803e913c = zio_execute+0xac/frame 
> 0xfe01b0231930
> zio_vdev_io_start() at 0x803ec894 = zio_vdev_io_start+0x2b4/frame 
> 0xfe01b0231990
> zio_execute() at 0x803e913c = zio_execute+0xac/frame 
> 0xfe01b02319e0
> zio_nowait() at 0x803e8a8b = zio_nowait+0xcb/frame 0xfe01b0231a20
> vdev_mirror_io_start() at 0x803a744c = 
> vdev_mirror_io_start+0x35c/frame 0xfe01b0231a70
> zio_vdev_io_start() at 0x803ec86c = zio_vdev_io_start+0x28c/frame 
> 0xfe01b0231ad0
> zio_execute() at 0x803e913c = zio_execute+0xac/frame 
> 0xfe01b0231b20
> taskqueue_run_locked() at 0x806d3d27 = 
> taskqueue_run_locked+0x127/frame 0xfe01b0231b80
> taskqueue_thread_loop() at 0x806d4ee8 = 
> taskqueue_thread_loop+0xc8/frame 0xfe01b0231bb0
> fork_exit() at 0x80640df5 = fork_exit+0x85/frame 0xfe01b0231bf0
> fork_trampoline() at 0x8096915e = fork_trampoline+0xe/frame 
> 0xfe01b0231bf0
> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> Uptime: 4s
> 

This seems to be an unintended consequence of some code that was pulled
in from upstream today.

Try adding: vfs.zfs.trim.enabled=0
to /boot/loader.conf

(you can set it manually from the boot loader menu with the set command
to get the system to boot)

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: Boot CURRENT without efi

2017-06-05 Thread Allan Jude
On 2017-06-05 13:31, Andy Neustadter wrote:
> Hi:
> 
> I have an older HP desktop that does not support USB boot or UEFI.  Is
> it possible to use this machine with 12-current using GPT?  Any help
> or pointers to info would be greatly appreciated.  Thanks in advance.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

If your BIOS does not actively interfere, then yes, you can boot from a
GPT partitioned disk in legacy mode, without UEFI.

If it doesn't work, the installer still supports MBR.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: Time to increase MAXPHYS?

2017-06-03 Thread Allan Jude
On 2017-06-03 22:35, Julian Elischer wrote:
> On 4/6/17 4:59 am, Colin Percival wrote:
>> On January 24, 1998, in what was later renumbered to SVN r32724, dyson@
>> wrote:
>>> Add better support for larger I/O clusters, including larger physical
>>> I/O.  The support is not mature yet, and some of the underlying
>>> implementation
>>> needs help.  However, support does exist for IDE devices now.
>> and increased MAXPHYS from 64 kB to 128 kB.  Is it time to increase it
>> again,
>> or do we need to wait at least two decades between changes?
>>
>> This is hurting performance on some systems; in particular, EC2 "io1"
>> disks
>> are optimized for 256 kB I/Os, EC2 "st1" (throughput optimized
>> spinning rust)
>> disks are optimized for 1 MB I/Os, and Amazon's NFS service (EFS)
>> recommends
>> using a maximum I/O size of 1 MB (and despite NFS not being *physical*
>> I/O it
>> seems to still be limited by MAXPHYS).
>>
> We increase it in freebsd 8 and 10.3 on our systems,  Only good results.
> 
> sys/sys/param.h:#define MAXPHYS (1024 * 1024)   /* max raw I/O
> transfer size */
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

At some point Warner and I discussed how hard it might be to make this a
boot time tunable, so that big amd64 machines can have a larger value
without causing problems for smaller machines.

ZFS supports a block size of 1mb, and doing I/Os in 128kb negates some
of the benefit.

I am preparing some benchmarks and other data along with a patch to
increase the maximum size of pipe I/O's as well, because using 1MB
offers a relatively large performance gain there as well.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: undefined symbol 'stat'

2017-06-03 Thread Allan Jude
On 2017-06-03 19:28, Jeffrey Bouquet wrote:
>   The latest pkg updates broke firefox here, which won't build  [ patches 
> fail to apply ]
>   Also seamonkey, but building sqlite3 locally fixed that.
>   
>   [ not that I'd expect firefox to build anyway, not been that lucky 
> recently... ] 
> 
>   Web search turns up no 'undefined symbol stat' on 12.0-CURRENT that I can 
> find.
> 
>   Subject give the entirety of the error. 
>   Building webkit-gtk2 locally as of now to try to fix it in a third round of 
> ports. ... 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

The ino64 change that went into -current recently changed a lot of stuff
related to stat(), and versioned the symbol. You are trying to run apps
compiled for a newer version of -current than you are running. You need
to update your kernel and userland to patch what pkg is built against.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: Ssh.. can we please have HPN back?

2017-05-22 Thread Allan Jude
On 2017-05-22 03:50, Julian Elischer wrote:
> On 22/5/17 2:20 pm, Allan Jude wrote:
>> On 2017-05-18 22:28, Julian Elischer wrote:
>>> So after stripping out the HPN version of ssh from our product becasue
>>> "it was no longer needed" we dicovered that we were premature in
>>> doing so.
>>> Apparently ssh still really needs HPN to get any throughput at all when
>>> there are latencies involved.
>>>
>>>
>>> For example, with HPN we get 13MB/sec between the Azure US west
>>> Data center and the Azure East data center.But the standard ssh in 10.3
>>> (with HPN stripped out) can barely manage 2MB/sec transfers.
>>>
>>> I did ask at the time whether it was proved that the new ssh didn't
>>> require the HPN changes,
>>> and was assured, "no" but it would appear that the picture isn't as
>>> clear.
>>> tht seems silly to have to import the port when we have what would
>>> otherwise be a
>>> perfectly good ssh as part of hte system, and it's really annoying
>>> having to specify
>>> /usr/local/bin/scp  or /usr/local/bin/ssh in every script.
>>>
>>> So can we please have the latest version of the HPN changes back in the
>>> default system please?
>>> It seem rather odd that the upstream openssh has had this problem for SO
>>> LONG and not fixed it.
>>>
>>> Julian
>>>
>>>
>>> ___
>>> freebsd-current@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> To unsubscribe, send any mail to
>>> "freebsd-current-unsubscr...@freebsd.org"
>> I have this stand-alone patch ready now:
>>
>> https://github.com/openssh/openssh-portable/compare/master...allanjude:V_7_5_dynamic_window
>>
>>
>> In my benchmarks with 100ms of latency (from dummynet) is increases SSH
>> send throughput from 1 megabyte/sec to 225 megabytes/sec provided a
>> large enough socket buffer.
>>
>> Still seeing lesser performance on the recv case, working on it.
> 
> We have two patches of our own that upstream have ignored   an option to
> set NoDelay   and a pushwindow setting option
> (though I'm not sure the second is operational in the current code, it
> does apply with no errors...)
> 
> The NoDelay options massively speeds up the case where you have chatty
> back and forth traffic (client/server) through a ssh tunnel.
> 
> Are your changes against the sources in current?  what about stable/10?
> 
>>
> 

That change is against upstream's latest release, but should apply
cleanly to any version of OpenSSH from the past 10 years that does not
have the HPN patches applied already.

However, the function channel_check_window() in stable/10 is currently
the same as the latest upstream since the commit that removed HPN. The
function is actually unchanged from upstream if you go back far enough
to before we added HPN as well.

If you revert both HPN commits, the most recent change to that function
is Aug 2008, when upstream introduced the 'move the window forward every
3 packets' thing that seams to be the main cause of the window scaling
problem in the first place. I think the nodelay option might be what
mitigates that, as it causes rapid back and forth and never allows the
window to grow to even the 2mb allowed by SSH since version 4.7


-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: Ssh.. can we please have HPN back?

2017-05-22 Thread Allan Jude
On 2017-05-18 22:28, Julian Elischer wrote:
> So after stripping out the HPN version of ssh from our product becasue
> "it was no longer needed" we dicovered that we were premature in doing so.
> Apparently ssh still really needs HPN to get any throughput at all when
> there are latencies involved.
> 
> 
> For example, with HPN we get 13MB/sec between the Azure US west
> Data center and the Azure East data center.But the standard ssh in 10.3
> (with HPN stripped out) can barely manage 2MB/sec transfers.
> 
> I did ask at the time whether it was proved that the new ssh didn't
> require the HPN changes,
> and was assured, "no" but it would appear that the picture isn't as clear.
> tht seems silly to have to import the port when we have what would
> otherwise be a
> perfectly good ssh as part of hte system, and it's really annoying
> having to specify
> /usr/local/bin/scp  or /usr/local/bin/ssh in every script.
> 
> So can we please have the latest version of the HPN changes back in the
> default system please?
> It seem rather odd that the upstream openssh has had this problem for SO
> LONG and not fixed it.
> 
> Julian
> 
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

I have this stand-alone patch ready now:

https://github.com/openssh/openssh-portable/compare/master...allanjude:V_7_5_dynamic_window

In my benchmarks with 100ms of latency (from dummynet) is increases SSH
send throughput from 1 megabyte/sec to 225 megabytes/sec provided a
large enough socket buffer.

Still seeing lesser performance on the recv case, working on it.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: Ssh.. can we please have HPN back?

2017-05-19 Thread Allan Jude
On 2017-05-19 00:01, Rodney W. Grimes wrote:
>> So after stripping out the HPN version of ssh from our product becasue
>> "it was no longer needed" we dicovered that we were premature in doing so.
>> Apparently ssh still really needs HPN to get any throughput at all when
>> there are latencies involved.
>>
>>
>> For example, with HPN we get 13MB/sec between the Azure US west
>> Data center and the Azure East data center.But the standard ssh in 10.3
>> (with HPN stripped out) can barely manage 2MB/sec transfers.
>>
>> I did ask at the time whether it was proved that the new ssh didn't 
>> require the HPN changes,
>> and was assured, "no" but it would appear that the picture isn't as clear.
>> tht seems silly to have to import the port when we have what would 
>> otherwise be a
>> perfectly good ssh as part of hte system, and it's really annoying 
>> having to specify
>> /usr/local/bin/scp  or /usr/local/bin/ssh in every script.
>>
>> So can we please have the latest version of the HPN changes back in 
>> the default system please?
>> It seem rather odd that the upstream openssh has had this problem for 
>> SO LONG and not fixed it.
> 
> Allan Jude has recently done a bunch of work on this though I do
> not know its current status of being either upstreamed (I know
> some of it well not be accepted from conversations with Allan)
> or commited to the tree.
> 

I hope to have the most important part of the patch rebased on the
latest upstream version of OpenSSH by the end of this weekend.

The versions I built and benchmarked for AsiaBSDCon were based on the
HPN patched openssh-portable from ports, but I think the change required
to actually make ssh not suck will only be a few lines, and will be
acceptable by upstream.

The big issue is in the channel_check_window()

The condition for growing the SSH window is if we have received 3 times
the max packet size. For some reason this constant small growth of the
SSH window never lets the TCP socket buffer grow.

This behaviour was added in OpenSSH 4.7 (Jun 2007), and makes sense for
interactive ssh sessions.

More detail in my paper, see the 'Broken Windows' chapter:
http://allanjude.com/bsd/AsiaBSDCon2017_-_SSH_Performance.pdf

Anyway, my fix was to only allow that condition to result in moving the
SSH window forward if packet_is_interactive(). In the bulk transfer
case, it falls back to using the other (original) condition of 'half of
the local window max has been consumed'.

The other condition is a modified version of one of the HPN patches. We
do a getsockopt SO_RCVBUF to check the size of the tcp socket buffer,
and if the remaining part of the SSH window has fall below the size of
the socket buffer, we grow the SSH window by 150%, up to SSHBUF_SIZE_MAX

https://github.com/rapier1/openssh-portable/compare/master...allanjude:dynamic_window_fix.diff

I just need to rejigger it a bit so it doesn't depend on the HPN support
functions and becomes an independent patch.

Figure 3 and Figure 4 show what difference HPN makes when you add
latency, but also show without my patch, HPN only solves the recv case,
not the send case.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: r316958: booting a server takes >10 minutes!

2017-04-15 Thread Allan Jude
On 2017-04-15 07:53, O. Hartmann wrote:
> Recent CURRENT running on a server makes the system booting in multiuser mode 
> booting
> incredibly slow! On a machine, before I interrupted the booting process 
> hanging in
> starting postgresql 9.6.2 server, it took > 10 minutes.
> 
> Due to a serious bug in CURRENT, I had to disable BPF_JITTER via sysctl
> net.bpf_jitter.enable=0
> 
> The box also is a syslog "receiving" server for other hosts, syslogd's option 
> "-s" isn't
> used (just for the record).
> 
> I'm back to r316717 now which boots the box fine.
> 
> Booting in single-user mode is also quick as expected.
> 
> oh
> 

Is it stalled in a specific place?

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: problem with ls, not show a correct list

2017-04-06 Thread Allan Jude
On 2017-04-06 23:12, Nilton José Rizzo wrote:
>   Hi all 
> 
>   Look this command on a FreeBSD -current 
> 
> % ls -d /usr/ports/[a-z]*
> /usr/ports/accessibility /usr/ports/math
> /usr/ports/arabic /usr/ports/misc
> /usr/ports/archivers /usr/ports/Mk
> /usr/ports/astro /usr/ports/MOVED
> /usr/ports/audio /usr/ports/multimedia
> % echo /usr/ports/[a-z]*
> /usr/ports/accessibility /usr/ports/arabic /usr/ports/archivers
> /usr/ports/astro /usr/ports/audio /usr/ports/base /usr/ports/benchmarks
> /usr/ports/biology /usr/ports/cad /usr/ports/CHANGES /usr/ports/chinese
> /usr/ports/comms /usr/ports/CONT
> alguém sabe o motivo desse erro?
> % ls -d /usr/src/[a-z]*
> /usr/src/bin /usr/src/Makefile.libcompat
> /usr/src/cddl /usr/src/ObsoleteFiles.inc
> /usr/src/contrib /usr/src/README
> /usr/src/COPYRIGHT /usr/src/release 
> 
> What's I do wrong? 
> 
> % set 
> 
> addsuffix 
> anyerror 
> argv ()
> csubstnonl 
> cwd /home2/rizzo/src/repositorio/bsdday-2017
> dirstack /home2/rizzo/src/repositorio/bsdday-2017
> echo_style bsd
> edit 
> euid 1000
> euser rizzo
> gid 0
> group wheel
> history 100
> home /home2/rizzo
> killring 30
> loginsh 
> owd /home2/rizzo/src/repositorio/Rural
> path (/sbin /bin /usr/sbin /usr/bin /usr/local/sbin /usr/local/bin
> /home2/rizzo/bin)
> prompt %# 
> prompt2 %R? 
> prompt3 CORRECT>%R (y|n|e|a)? 
> shell /bin/csh
> shlvl 1
> status 0
> tcsh 6.18.01
> term screen
> tty pts/4
> uid 1000
> user rizzoversion tcsh 6.18.01 (Astron) 2012-02-14 (x86_64-amd-FreeBSD)
> options wide,nls,dl,al,kan,sm,rh,color,filec
> % uname -a
> FreeBSD valfenda 12.0-CURRENT FreeBSD 12.0-CURRENT #2 r313684: Sun Feb
> 12 20:52:19 BRST 2017 rizzo@valfenda:/usr/obj/usr/src/sys/VALFENDA amd64
> % 
> 

Maybe I am missing something. What is the problem with the output?
ls just appears to be doing columns.

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

Re: CURRENT: slow like crap! ZFS scrubbing and ports update > 25 min

2017-03-22 Thread Allan Jude
On 2017-03-22 16:02, O. Hartmann wrote:
> CURRENT (FreeBSD 12.0-CURRENT #82 r315720: Wed Mar 22 18:49:28 CET 2017 
> amd64) is
> annoyingly slow! While scrubbing is working on my 12 GB ZFS volume, updating 
> /usr/ports
> takes >25 min(!). That is an absolute record now.
> 
> I do an almost  daily update of world and ports tree and have periodic 
> scrubbing ZFS
> volumes every 35 days, as it is defined in /etc/defaults. Prts tree hasn't 
> grown much,
> the content of the ZFS volume hasn't changed much (~ 100 GB, its fill is 
> about 4 TB now)
> and this is now for ~ 2 years constant. 
> 
> I've experienced before that while scrubbing the ZFS volume, some operations, 
> even the
> update of /usr/ports which resides on that ZFS RAIDZ volume, takes a bit 
> longer than
> usual - but never that long like now!
> 
> Another box is quite unusable while it is scrubbing and it has been usable 
> times before.
> The change is dramatic ...
> 
> Regards,
> 
> Oliver
> 

Due to differences in the kern.hz setting between IllumOS and FreeBSD,
the result is FreeBSD doesn't de-prioritize scrub I/O as much as IllumOS
does.

try:
sysctl vfs.zfs.scrub_delay=40

This will speed for 40 ticks (40ms on FreeBSD), between each scrub I/O,
allowing your ports update to proceed more quickly.

'zpool list' will show how fragmented your pool is, and how full it is,
these may also provide insight.

If you run 'top -S' while it is performing badly, what is the CPU load like?

Is your /usr/ports dataset compressed?

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: CURRENT: FreeBSD not reporting AES-NI on Intel(R) Xeon(R) CPU E5-1650 v3

2017-03-17 Thread Allan Jude
and the set bits from
> the result are printed.
> 
> Based on some poking around in open source bits (tianocore, coreboot), it
> appears that AES-NI is something the BIOS can irreversibly
> disable-until-next-reset by twiddling bits in the appropriate MSR
> register.  There is no code that does this in FreeBSD on purpose, so there
> would have to be a bug introduced in -CURRENT that somehow clobbers those
> MSR bits early on - a bug that was also not merged to 11-STABLE (since
> Slawa shows AESNI enabled on the same processor under 11-STABLE).
> 
> I will also say that I have dealt with a manufacturer of Xeon hardware in
> Europe who will not provide a stock BIOS that allows you to enable AES-NI,
> out of concerns over violating export/import rules governing encryption
> technology.  With that vendor, you have to pass an end-user verification
> and then they will make you a custom BIOS that gives you the option to
> enable AES-NI.  It took quite some time working through the outer layers of
> their support organization to even determine that this was the underlying
> (bureaucratic) issue.
> 
> Here is another data point: 11.0-RELEASE-p1 running on E5-1650 v3 with
> AESNI recognized as enabled.  You could install that stock FreeBSD release
> and if it does not show AESNI as enabled on your system, you will clearly
> know it is not a FreeBSD problem without any question as to whether there
> is a bug in CURRENT or having to build and install the exact rev of
> 11-STABLE that Slawa is using.
> 
> uname:
> FreeBSD ttest2 11.0-RELEASE-p1 FreeBSD 11.0-RELEASE-p1 #0 r306420: Thu Sep
> 29 01:43:23 UTC 2016
> r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC
>  amd64
> 
> dmesg:
> CPU: Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz (3500.08-MHz K8-class CPU)
>   Origin="GenuineIntel"  Id=0x306f2  Family=0x6  Model=0x3f  Stepping=2
> 
> Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
>  
> Features2=0x7ffefbff<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND>
> 
> 
> -Patrick
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

I can also confirm it works fine on FreeBSD 11.0-RELEASE-p1 on the
E5-1650 v3, as I did all of the testing for my recent AsiaBSDCon paper
of SSH performance, on a pair of identical E5-1650 v3's in the FreeBSD
Test Cluster @ Sentex.

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


Re: CURRENT: FreeBSD not reporting AES-NI on Intel(R) Xeon(R) CPU E5-1650 v3

2017-03-17 Thread Allan Jude
On 2017-03-17 12:53, O. Hartmann wrote:
> Am Fri, 17 Mar 2017 15:04:29 +0300
> Slawa Olhovchenkov <s...@zxy.spb.ru> schrieb:
> 
>> On Fri, Mar 17, 2017 at 12:36:25PM +0100, O. Hartmann wrote:
>>
>>> Running recent CURRENT on a Fujitsu Celsius M740 equipted with an Intel(R)
>>> Xeon(R) CPU E5-1650 v3 @ 3.50GHz CPU makes me some trouble.
>>>
>>> FreeBSD does not report the existence or availability of AES-NI feature, 
>>> which
>>> is supposed to be a feature of this type of CPU:  
>>
>> What reassons to detect AES-NI by FreeBSD?
> 
> What do you mean? I do not understand! FreeBSD is supposed to read the CPUID 
> and
> therefore the capabilities as every other OS, too. But there may some 
> circumstances why
> FBSD won't. I do not know, that is the reason why I'm asking here.
> 
>> Other OS detect AES-NI on this server?
> 
> I havn't ried so far, the box is in heavy use. I'd like to check with some 
> live USB drive
> versions and report later.
> 
>>
>> AES-NI may be disabled by BIOS/vendor/BIOS settings
> 
> There is no option for that, I'm looking for several time for that right now. 
> Even with
> TPM enabled - which is considered to be necessary on several firmwares - 
> there is no
> change.
> 
>>
>> https://forums.lenovo.com/t5/ThinkPad-11e-Windows-13-E-and/AES-NI-is-disabled-on-my-13-New-S2/td-p/3498468
>> http://h17007.www1.hpe.com/docs/iss/proliant_uefi/UEFI_Gen9_060216/s_enable_AES-NI.html
>> http://en.community.dell.com/support-forums/servers/f/956/t/19509653
> 
> As I said, even with the brand new firmware from January of this year (2017) 
> there is no
> change - the firmware prior to that showed the same non-existing AES-NI 
> feature.
> 

I have used the E5-1650 v3 in the FreeBSD test cluster, and AES-NI works
fine.

I had to enable it in the BIOS though. It is on the CPU features page,
and may have an odd name, rather than "AES-NI"

AES-NI is unrelated to TPM.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: update an older i386 CURRENT system to amd64 CURRENT

2017-03-16 Thread Allan Jude
mp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin
> /usr/obj/usr/src/make.i386/bmake  KERNEL=kernel install
> cc: Exec format error
> bmake[1]: "/usr/src/share/mk/bsd.compiler.mk" line 145: Unable to
> determine compiler type for CC=cc -isystem
> /usr/obj/usr/src/tmp/usr/include -L/usr/obj/usr/src/tmp/usr/lib
> -B/usr/obj/usr/src/tmp/usr/lib --sysroot=/usr/obj/usr/src/tmp
> -B/usr/obj/usr/src/tmp/usr/bin.  Consider setting COMPILER_TYPE.
> *** Error code 1
> 
> 
> Is there a way to use this /usr/src and pre-compiled /usr/obj on an i386
> host for update? Or do I have to use a complete recompile or even
> reinstall, based on a 64-bit memstick system?
> 
> Thanks
> 
>   matthias
> 
> 

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

You could try (untested, might eat your lunch, and kick your dog)
On the AMD64 host:

mkdir /tmp/amd64
make installkernel DESTDIR=/tmp/amd64

Then manually copy that kernel & modules into /boot/kernel on the i386
system, and reboot into it.

Then you'll have a 64bit kernel, and your old i386 world.

Then you should be able to do the make installkernel / installworld from
the /usr/src and /usr/obj you transferred

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: two recent snapshot installer problems

2017-03-08 Thread Allan Jude

I wOn 03/08/2017 14:56, Michael W. Lucas wrote:

Thanks for the hint, Toomas. But...

I updated my custom ZFS install/partition script, at:

http://www-old.michaelwlucas.com/zm.sh

I used this script at the command line partitioner in the installer,
then exited and let the installer take over.

The machine installs. After a "sysrc zfs_enable=yes" it boots.

So: bsdinstall doesn't like this box.

If anyone's willing to work on the installer in the next few days, I'm
willing to wait to work on this box. I will have to put it to work
before long, though.

Thanks,
==ml



I wouldn't be able to look at this until Tuesday the 14th. I am in Japan 
until then.


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


Re: effect of strip(1) on du(1)

2017-03-03 Thread Allan Jude
On March 3, 2017 9:11:30 AM EST, "Rodney W. Grimes" 
<freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
>-- Start of PGP signed section.
>[ Charset ISO-8859-1 unsupported, converting... ]
>> On 2017-Mar-02 22:19:10 -0800, "Rodney W. Grimes"
><freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
>> >> du(1) is using fts_read(3), which is based on the stat(2)
>information.
>> >> The OpenGroup defines st_blocksize as "Number of blocks allocated
>for
>> >> this object."  In the case of ZFS, a write(2) may return before
>any
>> >> blocks are actually allocated.  And thanks to compression, gang
>> ...
>> >My gut tells me that this is gona cause problems, is it ONLY
>> >the st_blocksize data that is incorrect then not such a big
>> >problem, or are we returning other meta data that is wrong?
>> 
>> Note that it's st_blocks, not st_blocksize.
>Yes, I just ignore that digretion, as well as the digretion into
>fts_read
>being anything special about this, as it just ends up calling stat(2)
>in
>the end anyway.
>
>> 
>> I did an experiment, writing a (roughly) 113MB file (some data I had
>> lying around), close()ing it and then stat()ing it in a loop.  This
>is
>> FreeBSD 10.3 with ZFS and lz4 compression.  Over the 26ms following
>the
>> close(), st_blocks gradually rose from 24169 to 51231.  It then
>stayed
>> stable until 4.968s after the close, when st_blocks again started
>> increasing until it stabilized after a total of 5.031s at 87483. 
>Based
>> on this, st_blocks reflects the actual number of blocks physically
>> written to disk.  None of the other fields in the struct stat vary.
> ^^^
>Thank you for doing the proper regression test, that satisfies me that
>we dont have a lattent bug sitting here and infact what we have is
>exposure of the kernel caching, which I might be too thrilled about,
>is just how its gona have to be.
>
>> 
>> The 5s delay is presumably the TXG delay (since this system is
>basically
>> unloaded).  I'm not sure why it writes roughly ? the data immediately
>> and the rest as part of the next TXG write.
>> 
>> >My expectactions of executing a stat(2) call on a file would
>> >be that the data returned is valid and stable.  I think almost
>> >any program would expect that.
>> 
>> I think a case could be made that st_blocks is a valid representation
>> of "the number of blocks allocated for this object" - with the number
>> increasing as the data is physically written to disk.  As for it
>being
>> stable, consider a (hypothetical) filesystem that can transparently
>> migrate data between different storage media, with different
>compression
>> algorithms etc (ZFS will be able to do this once the mythical block
>> rewrite code is written).
>
>I could counter argue that st_blocks is:
>st_blocks   The actual number of blocks allocated for the file in
> 512-byte units.
>
>Nothing in that says anything about "on disk".  So while this thing
>is sitting in memory on the TXG queue we should return the number of
>512 byte blocks used by the memory holding the data.
>I think that would be the more correct thing than exposing the
>fact this thing is setting in a write back cache to userland.

Can we compare the results of du with du -A?

Du will show compression savings, and -A wont

ZFS compresses between the write cache and the disk, so the final size may not 
be know for 5+ seconds
-- 
Allan Jude
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: r313938 breaks portsnap

2017-02-22 Thread Allan Jude
On 2017-02-21 09:43, Vladimir Zakharov wrote:
> Hello
> 
> After recent upgrade portsnap doesn't work anymore:
> 
> # portsnap fetch update
> Looking up portsnap.FreeBSD.org mirrors... 6 mirrors found.
> Fetching snapshot tag from ec2-eu-west-1.portsnap.freebsd.org... done.
> Fetching snapshot metadata... done.
> Updating from Tue Feb 21 16:05:39 MSK 2017 to Tue Feb 21 16:59:30 MSK 2017.
> Fetching 5 metadata patches.lam: unable to limit stdio: Capabilities 
> insufficient
>  done.
> Applying metadata patches... done.
> Fetching 5 metadata files... lam: unable to limit stdio: Capabilities 
> insufficient
> /usr/sbin/portsnap: cannot open 
> 8c94d2c3f8fcea20eb1fd82021566c99c63a010e6b3702ee11e7a491795bcfb8.gz: No such 
> file or directory
> metadata is corrupt.
> 
> Reverting r313938 fixes the problem.
> 

Fixed in r314098.

Thank you for the report, sorry for the breakage.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: 12-CURRENT won't configure to download packagesite.txz yet

2017-02-06 Thread Allan Jude
On February 7, 2017 2:35:16 AM GMT+01:00, Jeffrey Bouquet 
<jbt...@iherebuywisely.com> wrote:
>All the files
>
>/etc/FreeBSD.conf
>/usr/local/etc/pkg/repos/FreeBSD.conf
>/usr/local/etc/pkg.conf
>
>I edit time after time for
>{$ABI}  which gives FreeBSD:11:i386  but I am on 12-CURRENT i386
>Anytime I try to attune to
>freebsd:12:x86:32or
>FreeBSD:12:i386   ...
>it downloads the packagesite again, as it does in the ABI example, but
>a terse
>error of wrong architecture, etc, and a fail to do anything to upgrade
>to  Pkg-12.
>
>Can the proper file be rename upstream to what its architecture in
>simpler terms:
>like packagesite-i386-12.txz and a message printed upon de-TXZ the file
>so that
>the proper nomenclature is given to put into each of those three files
>above
>so that the generic packagesite.txz will not error out upon download?
>Or, put the instructions in /usr/src/UPDATING ?? since it is part of
>base? 
>
>
>Or some other way to de-showstopper this v11 April 2016 CURRENT to v12
>Feb 2017 CURRENT
>upgrade which still has failed to enable seamonkey-2.46_5 to run
>non-segfault [ ie cannot run ]
>vs seamonkey-2.46_4 which four days ago ran without EVER segfaulting?? 
>And cannot build
>from ports for obscure .h clang-header file related reasons? 
>___
>freebsd-current@freebsd.org mailing list
>https://lists.freebsd.org/mailman/listinfo/freebsd-current
>To unsubscribe, send any mail to
>"freebsd-current-unsubscr...@freebsd.org"

Please provide the output of:
uname -a
uname -K
uname -U

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


Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

2017-01-28 Thread Allan Jude
On 2017-01-28 15:17, Ngie Cooper wrote:
> On Sat, Jan 28, 2017 at 11:22 AM, Ngie Cooper <yaneurab...@gmail.com> wrote:
>>> What created a partition that small?
>>
>> Me.
>>
>> gpart up until last summer said that users should create 44kB
>> freebsd-boot partitions -- des@ corrected that in r303289:
>>
>> -This example uses 88 blocks (44 kB) so the next partition will be
>> -aligned on a 64 kB boundary without the need to specify an explicit
>> -offset or alignment.
>> -The boot partition itself is aligned on a 4 kB boundary.
>> +We create a 472-block (236 kB) boot partition at offset 40, which is
>> +the size of the partition table (34 blocks or 17 kB) rounded up to the
>> +nearest 4 kB boundary.
>>  .Bd -literal -offset indent
>> -/sbin/gpart add -b 40 -s 88 -t freebsd-boot ada0
>> +/sbin/gpart add -b 40 -s 472 -t freebsd-boot ada0
> 
> After some creative hacking... tada!
> 
> # find /usr/obj/usr/src/sys/boot/ -type f -name \*zfsboot -exec ls -l {} \;
> -rw-r--r--  1 root  wheel  131584 Jan 28 12:07
> /usr/obj/usr/src/sys/boot/i386/zfsboot/zfsboot
> -rw-r--r--  1 root  wheel  47527 Jan 28 12:07
> /usr/obj/usr/src/sys/boot/i386/gptzfsboot/gptzfsboot
> 
> -- wait, why is the size of zfsboot vs gptzfsboot so different? Oh,
> r304321 added that as `BOOT2SIZE`. Still, it seems a bit silly to only
> increase the size of one bootloader and not the other 4 instances of
> the bootloader :/. I don't understand the point in the size
> restriction 100%, but I'll leave it be.
> 
> Patch will be available sometime next week if my testing goes well.
> 
> Cheers,
> -Ngie
> 

The 'zfsboot' version, is dd's into the zfs boot code area. It is read
by the assembly code there. It is important the file be the size that
will be read, so it is padded out. That file is currently only used for
MBR booting from ZFS.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

2017-01-28 Thread Allan Jude
On 2017-01-28 14:04, Ngie Cooper wrote:
> On Sat, Jan 28, 2017 at 10:57 AM, Allan Jude <allanj...@freebsd.org> wrote:
>> On 2017-01-28 13:56, Ngie Cooper wrote:
>>> On Sat, Jan 28, 2017 at 8:56 AM, Warner Losh <i...@bsdimp.com> wrote:
>>>
>>> ...
>>>
>>>> So? It literally doesn't matter where the freebsd-boot partition
>>>> lives, or what it's number is. You can put it at the start or end of
>>>> the swap partition after adjusting its size. I've done this on several
>>>> systems...  NanoBSD plays games with this stuff as well to be bootable
>>>> on old / new systems.
>>>
>>> True. Hopefully my BIOS/disk controller isn't dumb enough to not
>>> support large disks properly.
>>>
>>> *sigh* Unfortunately, in my infinity cleverness I only put 2
>>> partitions on the drive -- freebsd-boot and freebsd-zfs. I guess I'll
>>> need to make backups of my workstation so I don't lose anything
>>> critical.
>>
>> Did gptzfsboot not fall below 64kb when you used the
>> LOADER_NO_GELI_SUPPORT knob?
> 
> It did, but unfortunately that's still way too small for my
> freebsd-boot partition (which apparently is only 44kB large :/..):
> 
> Before:
> 
> $ ls -l `make -V.OBJDIR`/gptzfsboot
> -rw-r--r--  1 ngie  wheel  111662 Jan 28 11:00
> /usr/obj/usr/src/sys/boot/i386/gptzfsboot/gptzfsboot
> 
> After:
> 
> $ ls -l `make -V.OBJDIR`/gptzfsboot
> -rw-r--r--  1 ngie  wheel  65371 Jan 28 11:05
> /usr/obj/usr/src/sys/boot/i386/gptzfsboot/gptzfsboot
> 
> Time to do some more tricks to pare down the bootloader size.
> 
> Sidenote to the folks who drive the release notes and upgrade
> instructions for FreeBSD 12.x -- it needs to be clearly explained that
> gptzfsboot has grown considerably in size and mitigation instructions
> should be provided for updating gptzfsboot -- in particular with folks
> who might be using freebsd-update, so don't have the luxury of the
> choice of bootloader build options when upgrading.
> 
> Thanks,
> -Ngie
> 
> $ gpart list da0
> Geom name: da0
> modified: false
> state: OK
> fwheads: 255
> fwsectors: 63
> last: 250069646
> first: 34
> entries: 128
> scheme: GPT
> Providers:
> 1. Name: da0p1
>Mediasize: 45056 (44K)
>Sectorsize: 512
>Stripesize: 0
>Stripeoffset: 20480
>Mode: r0w0e0
>rawuuid: 29a79300-48b1-11e4-97ff-fc4dd43f2de9
>rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f
>label: (null)
>length: 45056
>offset: 20480
>type: freebsd-boot
>index: 1
>end: 127
>start: 40
> 2. Name: da0p2
>Mediasize: 128035593728 (119G)
>Sectorsize: 512
>Stripesize: 0
>Stripeoffset: 65536
>Mode: r1w1e1
>rawuuid: 4416180d-48b1-11e4-97ff-fc4dd43f2de9
>rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b
>label: (null)
>length: 128035593728
>offset: 65536
>type: freebsd-zfs
>index: 2
>    end: 250069646
>start: 128
> Consumers:
> 1. Name: da0
>Mediasize: 128035676160 (119G)
>Sectorsize: 512
>Mode: r1w1e2
> 

What created a partition that small?

Even the FreeBSD 9.3 or 10.3 ZFS boot loaders would struggle to fit in
that space:

9.3:
-r--r--r--  1 root  wheel  42083 Jul 30  2015 /boot/gptzfsboot

10.3:
-r--r--r--  1 root  wheel  42143 Mar 25  2016 /boot/gptzfsboot


-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

2017-01-28 Thread Allan Jude
On 2017-01-28 13:56, Ngie Cooper wrote:
> On Sat, Jan 28, 2017 at 8:56 AM, Warner Losh <i...@bsdimp.com> wrote:
> 
> ...
> 
>> So? It literally doesn't matter where the freebsd-boot partition
>> lives, or what it's number is. You can put it at the start or end of
>> the swap partition after adjusting its size. I've done this on several
>> systems...  NanoBSD plays games with this stuff as well to be bootable
>> on old / new systems.
> 
> True. Hopefully my BIOS/disk controller isn't dumb enough to not
> support large disks properly.
> 
> *sigh* Unfortunately, in my infinity cleverness I only put 2
> partitions on the drive -- freebsd-boot and freebsd-zfs. I guess I'll
> need to make backups of my workstation so I don't lose anything
> critical.
> 
> -Ngie
> 

Did gptzfsboot not fall below 64kb when you used the
LOADER_NO_GELI_SUPPORT knob?

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

2017-01-27 Thread Allan Jude
On 2017-01-27 12:05, Warner Losh wrote:
> On Fri, Jan 27, 2017 at 12:34 AM, Toomas Soome <tso...@me.com> wrote:
>>
>>> On 27. jaan 2017, at 1:40, Ngie Cooper (yaneurabeya) 
>>> <yaneurab...@gmail.com> wrote:
>>>
>>> Hi,
>>>   I tried upgrading one of my workstations and unfortunately the 
>>> freebsd-boot partition is too small (I follow manpage directions, exactly, 
>>> and those seem to be too small as of 10.3-RELEASE timeframe), and I don’t 
>>> have enough space or ability to resize the partition and make it bigger. 
>>> So, I’m in need of a build knob to control the bloat, and/or having an 
>>> alternative boot loader without geli/skein/crypto support compiled in. 
>>> Would you be opposed to the work?
>>> Thanks,
>>> -Ngie
>>
>>
>> I do agree that since the geli knob is already there, it may do. Of course 
>> we also can think of additional knobs, but there is an issue - it wont help 
>> just to exclude some files, the additional features also do sit in the code, 
>> so the replacement stubs will be needed, also testing them all over will 
>> take some time. And the preprocessor spaghetti really is nasty thing to deal 
>> with;)
>>
>> And then there is another issue (partly why I did the feature support in 
>> first place) - as the kernel does not block user from enabling the features, 
>> the user can end up facing non-bootable setup which is also not good, as 
>> user is using perfectly legal options, and still the whole thing is just 
>> rendered unusable…
> 
> I'm curious why you can't find the space for a bigger partition?
> Almost all drives these days are partitioned with a little wasted
> space, and that wasted space should be more than enough to cover us
> here. Also, most drives have a swap partition that can be shrunk a
> trivial amount to get space for this...
> 
> Warner
> 

I need to do some testing to make a recipe that works for it, but the
other option is to use the ZFS bootcode area.

ZFS it self, reserves something like 3.5 mb of space in the ZFS
partition, for boot code. This is how we boot ZFS on MBR.

It should be possible to use this on GPT as well, we just don't.


-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

2017-01-27 Thread Allan Jude
On 2017-01-27 12:33, Shawn Webb wrote:
> On Fri, Jan 27, 2017 at 12:30:17PM -0500, Allan Jude wrote:
>> On 2017-01-27 12:05, Warner Losh wrote:
>>> On Fri, Jan 27, 2017 at 12:34 AM, Toomas Soome <tso...@me.com> wrote:
>>>>
>>>>> On 27. jaan 2017, at 1:40, Ngie Cooper (yaneurabeya) 
>>>>> <yaneurab...@gmail.com> wrote:
>>>>>
>>>>> Hi,
>>>>>   I tried upgrading one of my workstations and unfortunately the 
>>>>> freebsd-boot partition is too small (I follow manpage directions, 
>>>>> exactly, and those seem to be too small as of 10.3-RELEASE timeframe), 
>>>>> and I don???t have enough space or ability to resize the partition and 
>>>>> make it bigger. So, I???m in need of a build knob to control the bloat, 
>>>>> and/or having an alternative boot loader without geli/skein/crypto 
>>>>> support compiled in. Would you be opposed to the work?
>>>>> Thanks,
>>>>> -Ngie
>>>>
>>>>
>>>> I do agree that since the geli knob is already there, it may do. Of course 
>>>> we also can think of additional knobs, but there is an issue - it wont 
>>>> help just to exclude some files, the additional features also do sit in 
>>>> the code, so the replacement stubs will be needed, also testing them all 
>>>> over will take some time. And the preprocessor spaghetti really is nasty 
>>>> thing to deal with;)
>>>>
>>>> And then there is another issue (partly why I did the feature support in 
>>>> first place) - as the kernel does not block user from enabling the 
>>>> features, the user can end up facing non-bootable setup which is also not 
>>>> good, as user is using perfectly legal options, and still the whole thing 
>>>> is just rendered unusable???
>>>
>>> I'm curious why you can't find the space for a bigger partition?
>>> Almost all drives these days are partitioned with a little wasted
>>> space, and that wasted space should be more than enough to cover us
>>> here. Also, most drives have a swap partition that can be shrunk a
>>> trivial amount to get space for this...
>>>
>>> Warner
>>>
>>
>> I need to do some testing to make a recipe that works for it, but the
>> other option is to use the ZFS bootcode area.
>>
>> ZFS it self, reserves something like 3.5 mb of space in the ZFS
>> partition, for boot code. This is how we boot ZFS on MBR.
>>
>> It should be possible to use this on GPT as well, we just don't.
> 
> In the future, maybe it'd be a good idea for the installer to leave
> more space (a few MB, perhaps?) between the freebsd-boot and
> freebsd-swap partitions? At least, for ZFS installs.
> 
> Thanks,
> 

The PMBR code has a limitation for 536kb, and it all has to fit under
the 640k barrier, so the current 512kb size is plenty. The issue is some
people are upgrading from systems that were isntalled long ago, when
64kb or less was the default.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: gptzfsboot grew a lot after skein support was added; need knob to control bloat

2017-01-26 Thread Allan Jude
On 2017-01-26 18:50, Alan Somers wrote:
> On Thu, Jan 26, 2017 at 4:40 PM, Ngie Cooper (yaneurabeya)
> <yaneurab...@gmail.com> wrote:
>> Hi,
>> I tried upgrading one of my workstations and unfortunately the 
>> freebsd-boot partition is too small (I follow manpage directions, exactly, 
>> and those seem to be too small as of 10.3-RELEASE timeframe), and I don’t 
>> have enough space or ability to resize the partition and make it bigger. So, 
>> I’m in need of a build knob to control the bloat, and/or having an 
>> alternative boot loader without geli/skein/crypto support compiled in. Would 
>> you be opposed to the work?
>> Thanks,
>> -Ngie
> 
> We have this problem at work too.  We deal with it by defining the
> following in src.conf.  The build system already knows about this
> variable, though it isn't in src.conf's manpage.
> 
> LOADER_NO_GELI_SUPPORT=1
> 
> -Alan
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

Yeah, most of the size is from the GELI support, not Skein, so that is
your best starting place.

I also have some work in progress with tsoome@ to further shrink things
for you.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: ISO image: where is the CLANG compiler?

2017-01-18 Thread Allan Jude
On 2017-01-18 14:37, O. Hartmann wrote:
> Am Wed, 18 Jan 2017 16:38:32 +0100
> Matthias Apitz <g...@unixarea.de> schrieb:
> 
>> Why you do not just boot from USB some mem stick image, mount some disk
>> space to /mnt, svn checkout CURRENT to /mnt and build a booteable system
>> (world and kernel) and install to DESTDIR=/mnt ?
>>
>> I do not understand all this hassle?
>>
>>  matthias
>>
> 
> Wow!
> 
> As I initially stated, that is EXACTLY what I was inclined to do except the 
> fact that I
> had already an intact /usr/obj and usr/src with a complete compiled system.
> 
> I booted from mem stick and I was lost due to no cc!
> 
> Even for "make installworld" it seems I have to rely on the compiler. And the 
> images
> (ISO, memstick et cetera) provided these days do not contain any clang.
> 
> So, I tried /usr/src/release ... for the first time. The image does also not 
> contain the
> necessary tools for a full "make installworld installkernel" - not to speak of
> "compiling" world. I dodn't work (at least for me). 
> 
> I try to figure out how to avoid this crazy and useless shrinking of the ISO 
> images -
> somehow when building NanoBSD, there are knobs with which we can prevent the 
> build and/or
> installation of subsets like compiler, toolchain et cetera. The way such 
> thing is
> provided via src.conf and make.conf is fine and sophisticated. But "RELEASE" 
> seems to
> handle things different, and the standard is useless for a rescue mission.
> 
> So far.
> 
> It might be that I have overlooked something ...
> 
> Regards,
> 
> oh
> 

The DVD should still contain clang. Only the smaller images (bootonly,
disc1) should have clang removed.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: zfs zvol's inaccessible after reboot

2017-01-16 Thread Allan Jude
On 2017-01-16 12:59, Ultima wrote:
> Currently there is a bug with zvols. I have a few Bhyve containers that
> startup at boot. I'v noticed in middle December of last year that after a
> restart the zvols become inaccessible to the container. Nothing can be done
> to the zvol, other than rename. It cannot even be destroyed in this state.
> The only way to make it accessible again is to renaming the zvol, after
> this occurs, functionality is restored.
> 
> The bug is still present in head r312232.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

Is this because they are being used by GEOM?

Try: zfs set volmode=2 

Reboot, and see if that solves it

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

2017-01-11 Thread Allan Jude
On 2017-01-11 15:37, Matthew Macy wrote:
> You can still explicitly set the number of descriptors. It is now reported 
> under the dev sysctl tree. dev...
> 
> -M
> 
> 
>   On Wed, 11 Jan 2017 12:34:23 -0800 Olivier Cochard-Labbé 
> <oliv...@freebsd.org> wrote  
>  > 
>  > On Wed, Jan 11, 2017 at 9:13 PM, Matthew Macy <mm...@nextbsd.org> wrote:
>  > 
>  >   > Hmmm ... did your old tests do 4 or 8 queues on this hardware?
>  >   >
>  >   > Did the old tests run 1024 tx/rx slots or the max 4096?
>  >  
>  >  That's a great point, only having one thread per core could easily 
> account for this. I'm hoping Sean can make txq != rxq work so that you can 
> have 8txqs and 4 rxqs.
>  >  
>  > 
>  > ​The netgate RCC-VE 4860 is a 4 cores atom C2558E, and I'm using 2 of the 
> 4 Gigabit Intel i350 ports.
>  > Lab detail:
>  > 
> https://bsdrp.net/documentation/examples/forwarding_performance_lab_of_a_netgate_rcc-ve_4860
>  > 
>  > My tunning are (same for both test):
>  > hw.igb.rxd="2048" (it should be useless now)
>  > hw.igb.txd="2048" (it should be useless now)

Matt: I think he meant "useless now" because there is no igb, and the
below hw.em version covers it.

>  > hw.em.rxd="2048"
>  > hw.em.txd="2048"
>  > hw.igb.rx_process_limit="-1" (It should be useless now too)
>  > hw.em.rx_process_limit="-1"
>  > 
>  > dev.igb.2.fc=0
>  > dev.igb.3.fc=0
>  > 
>  > I can generate profiling data for you: what kind of data do you want ?
>  >  
> 
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 


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

Re: Log spam: Limiting * response from 1 to 200 packets/sec

2016-12-13 Thread Allan Jude
On 2016-12-13 10:24, Michael Butler wrote:
> Any hints as to why all of my -current equipment is complaining like
> below. Is there a sysctl to moderate/turn this off?
> 
> Dec 13 10:00:01 archive kernel: Limiting icmp unreach response from 1 to
> 200 packets/sec
> Dec 13 10:00:21 archive last message repeated 13 times
> Dec 13 10:02:21 archive last message repeated 18 times
> Dec 13 10:06:21 archive last message repeated 36 times
> Dec 13 10:07:11 archive kernel: Limiting icmp ping response from 1 to
> 200 packets/sec
> Dec 13 10:07:55 archive kernel: Limiting icmp unreach response from 1 to
> 200 packets/sec
> Dec 13 10:08:21 archive last message repeated 17 times
> Dec 13 10:08:37 archive kernel: Limiting closed port RST response from 4
> to 200 packets/sec
> Dec 13 10:09:55 archive kernel: Limiting icmp unreach response from 1 to
> 200 packets/sec
> Dec 13 10:10:21 archive last message repeated 17 times
> Dec 13 10:12:21 archive last message repeated 18 times
> Dec 13 10:12:28 archive kernel: Limiting icmp ping response from 1 to
> 200 packets/sec
> Dec 13 10:13:55 archive kernel: Limiting icmp unreach response from 1 to
> 200 packets/sec
> Dec 13 10:14:21 archive last message repeated 17 times
> Dec 13 10:16:21 archive last message repeated 18 times
> 
> Michael
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Yeah, this is a bug. When working as intended, the message would read:

kernel: Limiting closed port RST response from 201 to 200 packets/sec

The first value would be higher than the 2nd value
(net.inet.icmp.icmplim). It should only alert if it is actually limiting
the response rate.

You can mute it by setting: net.inet.icmp.icmplim_output=0

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


Re: r308432: Capsicumized `basename` make zsh prompt broken

2016-11-27 Thread Allan Jude
On 2016-11-27 23:55, Conrad Meyer wrote:
> Hi Iblis,
> 
> I see no such problem running 'basename $HOME' in a normal shell environment:
> 
>> $ basename $HOME
>> cmeyer
> 
> I suppose in your use, perhaps stdin is already closed?  I think this
> is a limitation of caph_limit_stdio() in general.
> 
> Can you try instead:
> 
> function set_prompt {
> prompt="$(basename $HOME < /dev/null) >"
> }
> 
> And see if it resolves the issue?
> 
> Thanks,
> Conrad
> 
> On Sun, Nov 27, 2016 at 8:33 PM, iblis <ib...@hs.ntnu.edu.tw> wrote:
>> Hi,
>> Here is a minimal config of zsh prompt invoking `basename`:
>> ```
>> └─[iblis@abeing]% cat /home/ib-test/.zshenv
>>
>> function set_prompt {
>> prompt="$(basename $HOME) >"
>> }
>>
>> function zle-line-init zle-keymap-select {
>> set_prompt
>> zle reset-prompt
>> }
>>
>> zle -N zle-line-init
>> zle -N zle-keymap-select
>>
>> set_prompt
>> ```
>>
>> and launching zsh will get something like this:
>>
>> ```
>> └─[iblis@abeing]% sudo su ib-test
>>
>> ib-test >basename: capsicum: Bad file descriptor
>>>
>>> basename: capsicum: Bad file descriptor
>>>
>> ```
>>
>>
>> To be honest, I have no idea about what casper/caspicum is. I just changed
>> the `basename.c` and zsh work again.
>>
>> Index: basename.c
>> ===
>> --- basename.c (revision 309213)
>> +++ basename.c (working copy)
>> @@ -65,7 +65,7 @@
>>
>> setlocale(LC_ALL, "");
>>
>> - if (caph_limit_stdio() < 0 || (cap_enter() < 0 && errno != ENOSYS))
>> + if (cap_enter() < 0 && errno != ENOSYS)
>> err(1, "capsicum");
>>
>> aflag = 0;
>>
>>
>> Any idea?
>>
>> --
>> Iblis Lin
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

IIRC, bapt@ specifically mentioned this case in the review for
caph_limit_stdio() or one of the reviews that lead to the creation of
the helpers.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: fatal: Fssh_packet_write_poll: Connection from xxx.xxx.xx.xx port yyyyy: Permission denied

2016-11-22 Thread Allan Jude
On 2016-11-22 02:37, KIRIYAMA Kazuhiko wrote:
> Hi, all
> 
> I've updated to HEAD(r308871) at 2 days ago, and also ports
> too(r426562). Then all stuffs including applications have
> been updated and tried to slogin to this host,but can't
> connect with the message `userauth_pubkey: key type ssh-dss
> not in PubkeyAcceptedKeyTypes [preauth]' in
> /var/log/auth.log. I found new OpenSSH-7.* has not been
> supported DSA and to connect from client with old ssh(lower
> than OpenSSH-7.0),set `ssh-dss' or some values set to
> relevant variables in /etc/ssh/sshd_config. According to [1]
> and [2] I've set these variables as below:
> 
> PubkeyAcceptedKeyTypes=+ssh-dss
> HostKeyAlgorithms=+ssh-dss
> KexAlgorithms=+diffie-hellman-group-exchange-sha256
> 
> and successfully slogined:
> 

snip

> 
> And with the message `fatal: Fssh_packet_write_poll:
> Connection from xxx.xxx.xx.xx port y: Permission denied'
> in /var/log/auth.log:
> 
> 
> Nov 22 16:07:51 kx sshd[73878]: Accepted publickey for admin from 
> xxx.xxx.xx.xx port 64147 ssh2: DSA 
> SHA256:6uPsONRWeNkYjlj9BU4GZYUUeH60ZbUCB25jolvrvj8
> Nov 22 16:07:51 kx sshd[73880]: fatal: Fssh_packet_write_poll: Connection 
> from xxx.xxx.xx.xx port 64147: Permission denied
> 
> 
> Is there any suggesions?
> My environments are as follows:
> 
> - Server:
> 
> admin@kx:~ % uname -a
> FreeBSD kx.truefc.org 12.0-CURRENT FreeBSD 12.0-CURRENT #13 r308871M: Sun Nov 
> 20 15:51:21 JST 2016 ad...@kx.truefc.org:/usr/obj/usr/src/sys/XIJ  amd64
> admin@kx:~ % ssh -V
> OpenSSH_7.2p2, OpenSSL 1.0.2j-freebsd  26 Sep 2016
> admin@kx:~ % 
> 
> - Client:
> 
> kiri@kazu:~[995]% uname -a
> FreeBSD kazu.pis 9.2-STABLE FreeBSD 9.2-STABLE #5 r259404M: Mon Dec 16 
> 00:12:52 JST 2013 ad...@kazu.pis:/usr/obj/usr/src/sys/GENERIC  amd64
> kiri@kazu:~[996]% ssh -V
> OpenSSH_6.2p2, OpenSSL 0.9.8y 5 Feb 2013
> kiri@kazu:~[997]% 
> 
> 
> Best regards.
> 
> 
> [1] 
> https://www.gentoo.org/support/news-items/2015-08-13-openssh-weak-keys.html
> [2] 
> https://lists.freebsd.org/pipermail/freebsd-current/2016-August/062853.html
> 
> ---
> KIRIYAMA Kazuhiko
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 


Newer versions of OpenSSH, like the one shipped in 11.0 and 12-current,
do not accept DSA keys anymore. You will need to use RSA keys, or the
newer ECDSA or ED25519 key types.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: http://pkg.freebsd.org only has freebsd:11:aarch64:64 for aaarch64? How to boostrap aarch64 pkg for head (12-CURRENT)?

2016-11-07 Thread Allan Jude
On 2016-11-07 15:19, Mark Millard wrote:
> It looks like http://pkg.freebsd.org is still back as of head being 
> 11-CURRENT: http://pkg.freebsd.org shows only
> 
>   • freebsd:11:aarch64:64
> 
> (as http://pkg.freebsd.org/freebsd%3A11%3Aaarch64%3A64 ).
> 
> So on 12-CURRENT pkg bootstrapping gets:
> 
>> # pkg
>> The package management tool is not yet installed on your system.
>> Do you want to fetch and install it now? [y/N]: y
>> Bootstrapping pkg from pkg+http://pkg.FreeBSD.org/FreeBSD:12:aarch64/latest, 
>> please wait...
>> pkg: Error fetching 
>> http://pkg.FreeBSD.org/FreeBSD:12:aarch64/latest/Latest/pkg.txz: Not Found
>> A pre-built version of pkg could not be found for your system.
>> Consider changing PACKAGESITE or installing it from ports: 'ports-mgmt/pkg'.
> 
> but ld is also missing at this stage so one cannot link anything --and pkg is 
> not a route to make an ld available.
> 
> So how does one currently bootstrap a 12-CURRENT pkg for aarch64 (context: 
> pine64+ 2GB)?
> 
> Create a /usr/local/etc/pkg/repos/FreeBSD.conf to reference 
> FreeBSD:11:aarch64 ? That just reports the wrong architecture is being 
> attempted:
> 
>> # pkg
>> The package management tool is not yet installed on your system.
>> Do you want to fetch and install it now? [y/N]: y
>> Bootstrapping pkg from pkg+http://pkg.FreeBSD.org/FreeBSD:11:aarch64/latest, 
>> please wait...
>> Verifying signature with trusted certificate pkg.freebsd.org.2013102301... 
>> done
>> pkg-static: Warning: Major OS version upgrade detected.  Running "pkg-static 
>> install -f pkg" recommended
>> Installing pkg-1.9.2...
>> pkg-static: wrong architecture: FreeBSD:11:aarch64 instead of 
>> FreeBSD:12:aarch64
>>
>> Failed to install the following 1 package(s): /tmp//pkg.txz.zkdHp2
> 
> 
> pkg-static install -f pkg fetches meta.txz and packagesite.txz first but then 
> also reports "wrong architecture":
> 
>> # pkg-static install -f pkg
>> pkg-static: Warning: Major OS version upgrade detected.  Running "pkg-static 
>> install -f pkg" recommended
>> Updating FreeBSD repository catalogue...
>> Fetching meta.txz: 100%944 B   0.9kB/s00:01
>> Fetching packagesite.txz: 100%4 MiB   4.3MB/s00:01
>> Processing entries:   0%
>> pkg-static: wrong architecture: freebsd:11:aarch64:64 instead of 
>> FreeBSD:12:aarch64
>> pkg-static: repository FreeBSD contains packages with wrong ABI: 
>> freebsd:11:aarch64:64
>> Processing entries: 100%
>> Unable to update repository FreeBSD
>> All repositories are up-to-date.
>> pkg-static: Repository FreeBSD cannot be opened. 'pkg update' required
>> pkg-static: No packages available to install matching 'pkg' have been found 
>> in the repositories
> 
> 
> 
> 
> Context details (was cross built from amd64 head -r308247):
> 
>> # uname -apKU
>> FreeBSD pine64 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r308247M: Thu Nov  3 
>> 07:10:44 PDT 2016 
>> markmi@FreeBSDx64:/usr/local/src/crochet/work/obj/arm64.aarch64/usr/src/sys/GENERIC-NODBG
>>   arm64 aarch64 1200014 1200014
> 
> 
>> # svnlite info /usr/ports | grep "Re[lv]"
>> Relative URL: ^/head
>> Revision: 424540
>> Last Changed Rev: 424540
> 
> 
> 
> ===
> Mark Millard
> markmi at dsl-only.net
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

Until the 12 packages are built, you can cheat:

env ABI=freebsd:11:aarch64:64 pkg bootstrap


-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: CURRENT: "service netif restart" looses default route

2016-10-05 Thread Allan Jude
On 2016-10-05 12:47, O. Hartmann wrote:
> 
> Today, I checked on two servers of ours running both a recent CURRENT (i.e. 
> FreeBSD
> 12.0-CURRENT #43 r306701: Wed Oct  5 06:40:40 CEST 2016) via "service netif 
> restart" the
> upcoming network and realised that the default route is lost then!
> 
> I'm able to config the route via "service routing restart" - or manually as I 
> did
> otherwise. But I recall that I did a simple "service netif restart" in 
> 11-CURRENT
> recently and that worked.
> 
> Has there been a change? What is now the official way to restart network?
> 
> Kind regards,
> Oliver
> 

As far as I am aware, this has always been this way, at least with
FreeBSD 6.0 and later. When you delete the interfaces, the route goes
away, then you recreate the interfaces but not the routes.

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


Re: ZFS - Abyssal slow on copying

2016-10-02 Thread Allan Jude
On 2016-10-02 15:25, O. Hartmann wrote:
> 
> Running 12-CURRENT (FreeBSD 12.0-CURRENT #32 r306579: Sun Oct  2 09:34:50 
> CEST 2016 ), I
> have a NanoBSD setup which creates an image for a router device.
> 
> The problem I face is related to ZFS. The system has a system's SSD (Samsung 
> 850 Pro,
> 256GB) which has an UFS filesystem. Aditionally, I have also a backup and a 
> data HDD,
> both WD, one 3 TB WD RED Pro, on 4 TB WD RED (the backup device). Both the 
> sources for
> the NanoBSD and the object tree as well as the NANO_WORLDDIR are residing on 
> the 3 TB
> data drive. 
> 
> The box itself has 8 GB RAM. When it comes to create the memory disk, which 
> is ~ 1,3 GB
> in size, the NanoBSD script starts creating the memory disk and then 
> installing world
> into this memory disk. And this part is a kind of abyssal in terms of the 
> speed.
> 
> The drive sounds like hell, the heads are moving rapidly. The copy speed is 
> incredibly
> slow compared to another box I usually use in the lab with UFS filesystem 
> only (different
> type of HDD).
> 
> The whole stuff the nanbsd is installed from and to is on a separate ZFS 
> partition, but
> in the same pool as everything else. When I first setup the new partitions, I 
> switched on
> deduplication, but I quickly deactivated it, because it had a tremendous 
> impact on the
> working speed and memory consumption on that box. But something seems not 
> right since
> then - as I initially described, the copy/initialisation speed/bandwith is 
> abyssal. Well,
> I also fear that I did something wrong when I firt initialised the HDD - 
> there is this
> 125bytes/4k block discussion and I do not know how to check whether I'm 
> affected to that
> or not (or even causing the problems) and how to check whether DEDUPLICATION 
> is
> definitely OFF (apart from the usual stuff list features via "zfs get all").
> 
> As an example: the nanbosd script takes ~ 1 minute to copy /boot/loader from 
> source to
> memory disk and the HDD makes sounds like hell and close to loosing the r/w 
> heads. On
> other boxes this task is done in a blink of an eye ...
> 
> Thanks for your patience,
> 
> Regards,
> oh
> 

Turning deduplication off, only stops new blocks from being
deduplicated. Any data written while deduplication was on, are still
deduplicated. You would need to zfs send | zfs recv, or
backup/destroy/restore to get the data back to normal.

If the drive is making that much noise, have you considered that the
drive might be failing?

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


Re: Destroy GPT partition scheme absolutely, how?

2016-09-28 Thread Allan Jude
On 2016-09-27 01:58, Warner Losh wrote:
> On Mon, Sep 26, 2016 at 11:06 PM, O'Connor, Daniel <dar...@dons.net.au> wrote:
>>
>>> On 27 Sep 2016, at 14:28, Warner Losh <i...@bsdimp.com> wrote:
>>> dd of 2MB of zeros to the start and end of the disk. That will destroy
>>> pretty much everything. For SSDs, sometimes you can do the same with
>>> TRIMs only faster (other times they are slower or unreliable).
>>
>> Yeah, but it would be nicer to not have to know that particular magic 
>> incarnation :)
> 
> Disk formatting has always been 3 parts magic, 2 parts luck and 1 part skill 
> :)
> 
> It doesn't fit nicely into geom because metadata can live elsewhere.
> 
> I forgot to add the caveat not to try this on a disk that is part of a
> RAID volume.
> 
> Warner
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

I wonder if this issue is related at all to the new 'auto resize' gpart
bits. That leaves the 'uncommitted' transaction pending, and may require
a 'gpart undo' before the other commands will work correctly.

I wonder if something like 'zpool labelclear', but for gpart would be
useful, that just nukes the first and last few MB of the disk. I know in
the installer we jump through a number of hoops to try to clear out old
stuff, and having one command would be better.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: zpool (online|replace|labelclear) issues, -f option also failing

2016-09-28 Thread Allan Jude
gt; above. I also wiped the first & last 2MB of the disk without success. Is
> they're a known issue or perhaps I'm missing something obvious? zpool
> labelclear is also providing a similar error. The -f options are not
> helping.
> 
> 
> Any ideas what my issue maybe? The error suggests it is currently active on
> the pool, however the offline should have changed that status correct?
> 
> Ultima
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 


-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: Trying to read linux-lvm on 11.0-RC2 using geom, bhyve, fail.

2016-09-15 Thread Allan Jude
On 2016-09-16 01:04, Zaphod Beeblebrox wrote:
> 
> 
> 
> Are you using zvols to back the VMs? Make sure they are in 'volmode=dev'
> not 'geom' (the default), or GEOM will lock the device when it detects a
> partition table being written to the zvol (from the installer inside
> the VM)
> 
> Note that this setting requires you to export/import the pool or reboot
> to apply.
> 
> 
> No, no.  The whole point here is that I was booting the raw disk. 
> "ada1" as it were.
>  

You might try the dangerous 'shoot yourself in the foot mode' for geom:

man 4 geom:
0x10 (allow foot shooting)
Allow writing to Rank 1 providers.  This would, for example,
allow the super-user to overwrite the MBR on the root disk or
write random sectors elsewhere to a mounted disk.  The
implications are obvious.


sysctl kern.geom.debugflags=16

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: Trying to read linux-lvm on 11.0-RC2 using geom, bhyve, fail.

2016-09-15 Thread Allan Jude
On 2016-09-15 01:10, Zaphod Beeblebrox wrote:
> I'm converting some Xen/Debian/Windows domain servers to
> FreeBSD/Bhyve/Samba domain servers. Windows is still required for a couple
> of applications, but I've recently had enough success with Samba4 to try
> this.  Not the problem.
> 
> The machines have two disks (was RAID-1 before, will be RAID-1 after) and
> I've run the FreeBSD install on one disk leaving the other alone.  I'd like
> to copy off some of what's on the other disk, so I set about trying to read
> it.
> 
> BHYVE ATTEMPT
> 
> Believe-it-or-not, I tried bhyve first.  Being the more complex solution,
> of course.  I tried booting the other disk in bhyve.  I chalked that
> failure up to it still being a Xen config... wasn't sure how that would
> boot for fail under bhyve... so I grabbed a debian live CD from the net and
> tried to boot it.
> 
> Now, I'm following the directions from
> https://www.freebsd.org/doc/handbook/virtualization-host-bhyve.html ...
> 
> And the error both times was failing to find init.  Both booting the CD
> _and_ booting the disk.
> 
> I can't seem to find any further documentation on my problem.  Linux boots
> to it's initrd filesystem state and fails to leave it because it (claims
> it) can't find /sbin/init (even though in the CD case, it's there)
> 
> GEOM ATTEMPT
> 
> After this fail, I decided I didn't really _need_ to run linux here and I
> discovered 'geom_linux_lvm.ko' ... cool.  But fail, too.  Doesn't emit any
> messages.  I even enabled the debug messages for it.
> 
> The linux disk is partitioned thusly:
> 
> =>63  1953525105  ada1  MBR  (932G)
>   631985- free -  (993K)
> 2048  1953523120 1  linux-data  [active]  (932G)
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

Are you using zvols to back the VMs? Make sure they are in 'volmode=dev'
not 'geom' (the default), or GEOM will lock the device when it detects a
partition table being written to the zvol (from the installer inside the VM)

Note that this setting requires you to export/import the pool or reboot
to apply.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: The state of UEFI support in the Kernel and installer

2016-09-06 Thread Allan Jude
On 2016-09-06 12:16, fpqc ?? wrote:
> I was reading this article from the 2013 Dev summit on UEFI:
> 
> https://wiki.freebsd.org/201305DevSummit/UEFI
> 
> In particular, I wanted to ask what is the status on these two goals (from 
> the article):
> 
> The following issues exist:
> - The installer needs to be taught about creating EFI System Partitions (if 
> needed) or selecting an EFI System Partition to install our first- and 
> second-stage boot code.

The installer (both partedit and zfs auto mode), creates and EFI system
partition as required. Currently, this is an 800kb partition that has
/boot/boot1.efifat written to it as an image.

We would like to change this to a larger partition and deal with it as a
filesystem rather than as a slot for a small bootcode file to be written to.

> - The installer needs to be taught about creating EFI boot entries for our 
> boot code once the kernel has an API for this.
> 
> Right now, as of the latest -Current image, the installer does not ask if an 
> EFI System partition already exists, which is rather scary.  When doing a 
> manual (expert) partitioning scheme, the installer should ask for the 
> location of the ESP if it exists, and if no ESP is specified for mounting, 
> the installer should warn that no bootloader will be installed.  

This is rather complicated for the FreeBSD installer. If there is no ESP
on the current drive, it is left to the user to install boot1.efi manually.

The same goes for if the user wishes to reuse an existing ESP.

If bsdinstall creates the ESP for you (it does if you boot the installer
under UEFI and do not tell it otherwise), then it will install the
proper bootcode to the ESP.

> 
> The other problem is that as far as I can tell, there is no code that creates 
> the EFI boot entry in any case.  By default, the installer just moves either 
> boot1.efi or loader.efi (not sure) to:
> (ESP)/EFI/bootx64.efi,
> which is the default location for EFI firmware.  I was wondering if the 
> kernel has the requisite API/driver for adding EFI boot entries yet.  On 
> (Arch) Linux, you can add an entry to the NVRAM with a tool called bootctl, 
> which is part of the sd-boot package.  
> 
> Also, wondering if FreeBSD has any plan to add something like 
> initramfs/EFIStub booting, which allows for much easier bootloader 
> configuration with sd-boot than the current FreeBSD EFI bootloader, which 
> must be chainloaded and has its configuration stored off of the ESP.  
> 

For historic reasons, users expect to configure the loader via
/boot/loader.conf not by modifying files on the ESP.

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


-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: Possible zpool online, resilvering issue

2016-08-10 Thread Allan Jude
On 2016-08-10 12:53, Ultima wrote:
> Hello,
> 
>> I didn't see any reply on the list, so I thought I might let you know
> 
> Sorry, never received this reply (till now) xD
> 
>> what I assume is happening:
> 
>> ZFS never updates data in place, which affects inode updates, e.g. if
>> a file has been read and access times must be updated. (For that reason,
>> many ZFS file systems are configured to ignore access time updates).
> 
>> Even if there were only R/O accesses to files in the pool, there will
>> have been updates to the inodes, which were missed by the offlined
>> drives (unless you ignore atime updates).
> 
>> But even if there are no access time updates, ZFS might have written
>> new uberblocks and other meta information. Check the POOL history and
>> see if there were any TXGs created during the scrub.
> 
>> If you scrub the pooll while it is off-line, it should stay stable
>> (but if any information about the scrub, the offlining of drives etc.
>> is recorded in the pool's history log, differences are to be expected).
> 
>> Just my $.02 ...
> 
>> Regards, STefan
> 
> Thanks for the reply, I'm not completely sure what would be considered a
> TXG. Maintained normal operations during most this noise and this pool has
> quite a bit of activity during normal operations. My zpool history looks
> like it gos on forever and the last scrub is showing it repaired 9.48G.
> That was for all these access time updates? I guess that would be a little
> less then 2.5G per disk worth.
> 
> The zpool history looks like it gos on forever (733373 lines). This pool
> has much of this activity with poudriere. All the entries I see are clone,
> destroy, rollback and snapshotting. I can't really say how much but at
> least 500 (prob much more than that) entries between the last two scrubs.
> Atime is off on all datasets.
> 
>  So to be clear, this is expected behavior with atime=off + TXGs during
> offline time? I had thought that the resilver after onlining the disk would
> bring that disk up-to-date with the pool. I guess my understanding was a
> bit off.
> 
> Ultima
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

A new transaction group (TXG) is created at LEAST every
vfs.zfs.txg.timeout (defaults to 5) seconds.

If you offline a drive for hours or more, it must have all blocks with a
'birth time' newer than the last transaction that was recorded on the
offlined drive replayed to catch that drive up to the other drives in
the pool.

As long as you have enough redundancy, the checksum errors can be
corrected without concern.

In the end, the checksum errors can be written off as being caused by
the bad hardware. After you finish the scrub and everything is OK, do:
'zpool clear poolname', and it will reset all of the error and checksum
counts to 0, so you can track if any more ever show up.


-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: [FreeBSD-Announce] HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0

2016-08-08 Thread Allan Jude
On 2016-08-08 14:17, Conrad Meyer wrote:
> The OpenSSH defaults are intentionally sane.  RSA 2048 is anticipated
> to be fine for the next 10 years.  It would not be a bad choice.  I'm
> not aware of any reason not to use EC keys, and presumably the openssh
> authors wouldn't ship them as an option if they knew of any reason to
> believe they were compromised.
> 
> Best,
> Conrad
> 
> On Mon, Aug 8, 2016 at 10:56 AM, Devin Teske <dte...@freebsd.org> wrote:
>> Which would you use?
>>
>> ECDSA?
>>
>> https://en.wikipedia.org/wiki/Elliptic_curve_cryptography 
>> <https://en.wikipedia.org/wiki/Elliptic_curve_cryptography>
>>
>> "" In the wake of the exposure of Dual_EC_DRBG as "an NSA undercover 
>> operation", cryptography experts have also expressed concern over the 
>> security of the NIST recommended elliptic curves,[31] 
>> <https://en.wikipedia.org/wiki/Elliptic_curve_cryptography#cite_note-31> 
>> suggesting a return to encryption based on non-elliptic-curve groups. ""
>>
>> Or perhaps RSA? (as des@ recommends)
>>
>> (not necessarily to Glen but anyone that wants to answer)
>> --
>> Devin
>>
>>
>>> On Aug 4, 2016, at 6:59 PM, Glen Barber <g...@freebsd.org> wrote:
>>>
> This is a heads-up that OpenSSH keys are deprecated upstream by OpenSSH,
> and will be deprecated effective 11.0-RELEASE (and preceeding RCs).
> 
> Please see r303716 for details on the relevant commit, but upstream no
> longer considers them secure.  Please replace DSA keys with ECDSA or RSA
> keys as soon as possible, otherwise there will be issues when upgrading
> from 11.0-BETA4 to the subsequent 11.0 build, but most definitely the
> 11.0-RELEASE build.
> 
> Glen
> On behalf of: re@ and secteam@
> 

As far as I know, the "advantage" to ED25519 keys, is that you can build
openssh without openssl, if you forgo supporting RSA etc.


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


Re: CURRENT: memory leak?

2016-07-29 Thread Allan Jude

On 2016-07-29 14:04, O. Hartmann wrote:


I realise an exorbitant memory usage of FreeBSD CURRENT ( FreeBSD 12.0-CURRENT 
#16
r303470: Fri Jul 29 05:58:42 CEST 2016 ). Swap space gets eaten up while 
building
world/kernel and/or ports very quickly.

I see this phenomenon on different CURRENT systems with different RAM (but all 
ZFS!). No
box is less than 8 GB RAM: one 8GB, another 16, two 32 GB. An older XEON 
Core2Duo server
with postgresql 9.5/postgis acting on some OSM data etas up all of its 32 GB and
additional 48GB swap - never seen before with 11-CURRENT.

I didn't investigate the problem so far since I realized this memory hunger of 
12-CURRENT
just today on several boxes compiling world, eating up all the memory, staring 
swapping
and never relax even after hours from the swapped memory.

Is this a known phenomenon or am I seeing something mystique?

Regards,

Oliver



Do you have the output of 'top', the first few lines

Specifically, is there very high 'Other' usage, on the ZFS ARC line?

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


Re: Boot environments and zfs canmount=noauto

2016-07-27 Thread Allan Jude
On 2016-07-27 22:05, Randy Westlund wrote:
> I'm trying to follow Michael Dexter's post about using bhyve with boot
> environments.  It involves moving all child datasets under
> zroot/ROOT/default, so that you can have entirely independent systems.
> 
> http://callfortesting.org/bhyve-boot-environments/
> 
>> Let's change the datasets with "canmount on" to "canmount noauto":
>> [snip]
>> Considering that this setting is harmless to a system with a single
>> boot environment, I would not object to it being the default. Hint
>> hint. 
> 
> When I set all the datasets with canmount=on to canmount=noauto, only
> zroot/ROOT/default gets mounted on next boot.  It's my understanding
> that 'zfs mount -a' doesn't mount datasets with canmount=noauto, but if
> I leave them with canmount=on, they will try to mount regardless of
> which BE is active.
> 
> I'm trying this with 11.0-BETA2.  Can sometime tell me what I'm missing?
> 

You are not missing anything. This is why the default is to have all
files that are specific to a BE be in the root dataset, and only files
that are global (like home directory, etc) be outside of the BE.

In order to do it the way Dexter is proposing, you can set them
canmount=noauto or with mountpoint=legacy, and then mount them via fstab
(defined differently in each BE), but that kind of defeats a lot of the
purpose of ZFS.


-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: Fwd: Failed to boot -Current snapshot memstick img with EFI

2016-07-26 Thread Allan Jude
On 2016-07-26 23:33, Howard Su wrote:
> The same issue is still there in 11-BETA2. I tried the memstick image for
> amd64. I got the exact same error (with boot -v).
> ​GEOM_PART: last LBA is below first LBA: 0 < 32
> GEOM_PART: integrity check failed (da0, MBR)
> 
> This make mem stick image totally useless. Anyone take a look? I am happy
> to provide more information.
> 
> Thanks,
> 
> Howard
> 
> -- Forwarded message --
> From: Howard Su <howard...@gmail.com>
> Date: Sat, Apr 23, 2016 at 10:40 PM
> Subject: Failed to boot -Current snapshot memstick img with EFI
> To: "freebsd-current@freebsd.org" <freebsd-current@freebsd.org>
> 
> 
> The issue is partition table in img is wrong so that GEOM cannot discover
> the partitions.
> 
> Detailed error:
> ​​
> GEOM_PART: last LBA is below first LBA: 0 < 32
> GEOM_PART: integrity check failed (da0, MBR)
> 
> I tried this month and last month memstick img. both has same problem. Any
> idea on the issue?
> 
> -Howard
> 

The last LBA is being reported as 0, which is obviously bogus.

How big is the USB device you have written the memstick to?

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: CURRENT: frequent crashes if mpd5 is running

2016-07-14 Thread Allan Jude
On 2016-07-14 13:13, Oleg V. Nauman wrote:
>  I'm experiencing frequent CURRENT ( 12.0-CURRENT r302535 amd64 ) crashes 
> triggered by mpd5:
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address   = 0x10
> fault code  = supervisor read data, page not present
> instruction pointer = 0x20:0x814f6162
> stack pointer   = 0x28:0xfe011b06d640
> frame pointer   = 0x28:0xfe011b06d670
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags= interrupt enabled, resume, IOPL = 0
> current process = 901 (mpd5)
> trap number = 12
> panic: page fault
> cpuid = 0
> 
> #0  doadump (textdump=) at pcpu.h:221
> 221 pcpu.h: No such file or directory.
> in pcpu.h
> (kgdb) #0  doadump (textdump=) at pcpu.h:221
> #1  0x80749169 in kern_reboot (howto=260)
> at ../../../kern/kern_shutdown.c:366
> #2  0x807496e1 in vpanic (fmt=,
> ap=) at ../../../kern/kern_shutdown.c:759
> #3  0x80749553 in panic (fmt=0x0) at ../../../kern/kern_shutdown.c:690
> #4  0x80a5aca1 in trap_fatal (frame=0xfe011b06d590, eva=16)
> at ../../../amd64/amd64/trap.c:841
> #5  0x80a5af51 in trap_pfault (frame=0x0, usermode=0)
> at ../../../amd64/amd64/trap.c:716
> #6  0x80a5a430 in trap (frame=0xfe011b06d590)
> at ../../../amd64/amd64/trap.c:442
> #7  0x80a3e161 in calltrap () at ../../../amd64/amd64/exception.S:236
> #8  0x814f6162 in ng_uncallout (c=0xf80004842460,
> node=0xf80004c79a00)
> at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:3815
> #9  0x8151bbab in ng_pptpgre_disconnect (hook=)
> at 
> /usr/src/sys/modules/netgraph/pptpgre/../../../netgraph/ng_pptpgre.c:966
> #10 0x814f2928 in ng_destroy_hook (hook=0xf8000487ad80)
> at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:1219
> #11 0x814f2635 in ng_rmnode (node=,
> dummy1=, dummy2=,
> dummy3=)
> at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:744
> #12 0x814f4832 in ng_apply_item (node=0xf80004c79a00,
> item=0xf80004e72600, rw=1)
> at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2523
> #13 0x814f41a3 in ng_snd_item (item=,
> flags=)
> at /usr/src/sys/modules/netgraph/netgraph/../../../netgraph/ng_base.c:2320
> #14 0x814eec4e in ngc_send (so=,
> flags=, m=,
> addr=, control=,
> td=)
> at /usr/src/sys/modules/netgraph/socket/../../../netgraph/ng_socket.c:338
> #15 0x807dee17 in sosend_generic (so=,
> addr=, uio=,
> top=, control=,
> flags=, td=)
> at ../../../kern/uipc_socket.c:1359
> #16 0x807e66b8 in kern_sendit (td=,
> s=, mp=, flags=0, control=0x0,
> segflg=) at ../../../kern/uipc_syscalls.c:848
> #17 0x807e6abf in sendit (td=0xf800047caa00,
> s=, mp=0xfe011b06da60,
> flags=) at ../../../kern/uipc_syscalls.c:775
> #18 0x807e690d in sys_sendto (td=0x0, uap=)
> at ../../../kern/uipc_syscalls.c:899
> #19 0x80a5b618 in amd64_syscall (td=, traced=0)
> at subr_syscall.c:135
> #20 0x80a3e44b in Xfast_syscall ()
> at ../../../amd64/amd64/exception.S:396
> #21 0x0008025d284a in ?? ()
> Previous frame inner to this frame (corrupt stack?)
> Current language:  auto; currently minimal
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

There is a patch for this issue:

https://reviews.freebsd.org/D7209

You might try seeing if it solves your problem, and reporting that to
the author

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

2016-07-12 Thread Allan Jude
On 2016-07-12 11:15, Ngie Cooper (yaneurabeya) wrote:
> 
>> On Jul 12, 2016, at 06:20, Miroslav Lachman <000.f...@quip.cz> wrote:
>>
>> Paweł Tyll wrote on 07/12/2016 01:22:
>>
>>> Those 3 things should shave off about 130MB of the 173MB needed to fit
>>> on  80-min CD-R. But... why this abstract number anyway? Why not 650MB
>>> CD-R?  Why  not  overburnable  800MB  90-min CD-R or even 870MB 99-min
>>> CD-R? :)
>>
>> It is not only about the target media size. The size matters when you need 
>> to boot some recovery media from you desktop on remote server via KVM.
>>
>> And there is one thing I don't understand - why is the bootonly so large? I 
>> remember days when this fits to 50MB and now it is almost 235MB which 
>> renders it almost useless. For recoveries and remote installs I always use 
>> mfsbsd images (about 45MB).
> 
> I wholeheartedly agree.
> 
> It sucks having to transfer more than 50 MB over our work link across a few 
> thousand miles with IPMI remote KVM redirection.
> 
> Thanks,
> -Ngie
> 

With IPMI virtual media, you usually do not transfer the entire image,
only read the blocks used by files that you load. Some IPMI clients
provide stats, usually only about 40mb is read from the bootonly cd.
More if you do things like invoke an editor to write a custom /etc/fstab
etc.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: Oversight in /etc/defaults/rc.conf

2016-07-12 Thread Allan Jude
On 2016-07-12 08:27, Glen Barber wrote:
> On Tue, Jul 12, 2016 at 07:17:19AM +0100, Matthew Seaman wrote:
>> I just upgraded my main machine to 11-STABLE.  Things are mostly working
>> fine -- however I did notice that the new iovctl rc script is apparently
>> enabled by default.  That seems like a trivial omission:
>>
>> Index: etc/defaults/rc.conf
>> ===
>> --- etc/defaults/rc.conf (revision 302482)
>> +++ etc/defaults/rc.conf (working copy)
>> @@ -695,6 +695,7 @@
>>  rctl_enable="YES"   # Load rctl(8) rules on boot
>>  rctl_rules="/etc/rctl.conf" # rctl(8) ruleset. See rctl.conf(5).
>>
>> +iovctl_enable="NO"
>>  iovctl_files="" # Config files for iovctl(8)
>>
>>  ##
>>
> 
> I'm not sure I understand.  Is there a functional and/or performance
> impact with it enabled by default?  (Note, I don't disable it in my
> rc.conf, and there is no /dev/iov/* on my system.)
> 
> Glen
> 

If the service should be on by default, then it should have
iovctl_enable="YES" in etc/defaults/rc.conf

One way or the other, a default should be set.

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


Re: FreeBSD-11.0-BETA1-amd64-disc1.iso is too big for my 700MB CD-r

2016-07-11 Thread Allan Jude

On 2016-07-11 18:33, Chris H wrote:

On Tue, 12 Jul 2016 00:46:04 +0300 Slawa Olhovchenkov <s...@zxy.spb.ru> wrote


On Mon, Jul 11, 2016 at 09:41:44PM +, Glen Barber wrote:


On Mon, Jul 11, 2016 at 03:32:34PM -0600, Alan Somers wrote:

On Mon, Jul 11, 2016 at 2:01 PM, Ronald Klop <ronald-li...@klop.ws>

wrote: >> Hi,


Just downloaded the amd64 BETA1 ISO (873MB) and tried to burn a CD on
Windows 10. It complained that the ISO is too big for my 700 MB CD-r.

The bootonly iso (281MB) burns and runs ok.

Regards,
Ronald.


Please open a PR.  Those images should be able to fit on a CD.


This was actually a known "going to be problem" thing for 11.0.  I'm
looking into how to fix this for 11.0-RELEASE, but right now, there is
not much more we can exclude from it. :(

Can't it use the compressed iso format, or is it already using that
format. Sorry haven't checked.


Reduce GENERIC to MINIMAL?


--Chris


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



380MB of the data on disc1 is the distsets, which are already .txz (max 
compression). That doesn't leave much room for the live OS on the disk.


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


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

2016-07-05 Thread Allan Jude
On 2016-07-05 21:32, Nathan Bosley wrote:
> I think in about 4 - 5 hours I can show what values I'm using in
> loader.conf under, say, r302264 and r302265 for comparison. I'm not 100%
> sure that the problem arose for me in r302265; I merely suspect it.
> 
> On Tue, Jul 5, 2016 at 9:25 PM, Allan Jude <allanj...@freebsd.org
> <mailto:allanj...@freebsd.org>> wrote:
> 
> On 2016-07-05 20:27, Steven Hartland wrote:
> > Ahh right, let me check that.
> >
> > On 06/07/2016 00:51, Nathan Bosley wrote:
> >> I actually have this same problem.
> >> I'll send more details when I get home later.
> >>
> >> I think the problem started for me after r302265.
> >> Before that, I can set vfs.zfs.arc_max and vfs.zfs.arc_min in
> >> loader.conf.
> >> After r302265, setting either vfs.zfs.arc_max or vfs.zfs.arc_min in
> >> loader.conf results in the EINVAL errors in 'dmesg':
> >>
> >> Setting sysctl vfs.zfs.arc_max failed: 22
> >> Setting sysctl vfs.zfs.arc_min failed: 22
> >>
> >> But setting vfs.zfs.arc_meta_limit in loader.conf works fine.
> >>
> >> But I did notice that using 'sysct' or sysctl.conf for vfs.zfs.arc_max
> >> and vfs.zfs.arc_min works.
> >> I only have problems with setting them now in loader.conf.
> >>
> >> Like I said, I'll try to send output from my setup later.
> >>
> >> Thanks.
> >>
> >> On Tue, Jul 5, 2016 at 6:10 PM, Steven Hartland
> >> <ste...@multiplay.co.uk <mailto:ste...@multiplay.co.uk>
> <mailto:ste...@multiplay.co.uk <mailto:ste...@multiplay.co.uk>>> wrote:
> >>
> >> What is it currently?
> >>
> >> Just had a quick play here:
> >> sysctl vfs.zfs.arc_max
> >> vfs.zfs.arc_max: 32283127808
> >> sysctl vfs.zfs.arc_max=32283127807
> >> vfs.zfs.arc_max: 32283127808 -> 32283127807
> >> sysctl vfs.zfs.arc_max=32283127808
> >> vfs.zfs.arc_max: 32283127807 -> 32283127808
> >>
> >> Error 22 = EINVAL so I suspect you're requesting a value
> which one
> >> of the following:
> >> * < arc_abs_min
> >> * > kmem_size
> >> * < arc_c_min
> >> * < zfs_arc_meta_limit
> >>
> >> Regards
> >> Steve
> >>
> >> On 05/07/2016 22:56, Eric van Gyzen wrote:
> >>
> >> Steven and -current:
> >>
> >> I just updated to r302350 with a GENERIC kernel config. 
> I see
> >> this in
> >> dmesg:
> >>
> >>  VT(efifb): resolution 1024x768
> >>  Setting sysctl vfs.zfs.arc_max failed: 22
> >>  CPU: Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz
> >> (3491.98-MHz K8-class
> >>  CPU)
> >>
> >> The relevant parts of /boot/loader.conf are:
> >>
> >>  zfs_load="YES"
> >>  vfs.zfs.arc_max="6442450944"
> >>
> >> Let me know what other information you need.
> >>
> >> Cheers,
> >>
> >> Eric
> >>
> >>
> >> ___
> >> freebsd-current@freebsd.org
> <mailto:freebsd-current@freebsd.org>
> <mailto:freebsd-current@freebsd.org
> <mailto:freebsd-current@freebsd.org>>
> >> mailing list
> >> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> >> To unsubscribe, send any mail to
> >> "freebsd-current-unsubscr...@freebsd.org
> <mailto:freebsd-current-unsubscr...@freebsd.org>
> >> <mailto:freebsd-current-unsubscr...@freebsd.org
> <mailto:freebsd-current-unsubscr...@freebsd.org>>"
> >>
> >>
> >
> > ___
> > freebsd-current@freebsd.org <mailto:freebsd-current@freebsd.org>
> mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to 
> "freebsd-current-unsub

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

2016-07-05 Thread Allan Jude
On 2016-07-05 20:27, Steven Hartland wrote:
> Ahh right, let me check that.
> 
> On 06/07/2016 00:51, Nathan Bosley wrote:
>> I actually have this same problem.
>> I'll send more details when I get home later.
>>
>> I think the problem started for me after r302265.
>> Before that, I can set vfs.zfs.arc_max and vfs.zfs.arc_min in
>> loader.conf.
>> After r302265, setting either vfs.zfs.arc_max or vfs.zfs.arc_min in
>> loader.conf results in the EINVAL errors in 'dmesg':
>>
>> Setting sysctl vfs.zfs.arc_max failed: 22
>> Setting sysctl vfs.zfs.arc_min failed: 22
>>
>> But setting vfs.zfs.arc_meta_limit in loader.conf works fine.
>>
>> But I did notice that using 'sysct' or sysctl.conf for vfs.zfs.arc_max
>> and vfs.zfs.arc_min works.
>> I only have problems with setting them now in loader.conf.
>>
>> Like I said, I'll try to send output from my setup later.
>>
>> Thanks.
>>
>> On Tue, Jul 5, 2016 at 6:10 PM, Steven Hartland
>> <ste...@multiplay.co.uk <mailto:ste...@multiplay.co.uk>> wrote:
>>
>> What is it currently?
>>
>> Just had a quick play here:
>> sysctl vfs.zfs.arc_max
>> vfs.zfs.arc_max: 32283127808
>> sysctl vfs.zfs.arc_max=32283127807
>> vfs.zfs.arc_max: 32283127808 -> 32283127807
>> sysctl vfs.zfs.arc_max=32283127808
>> vfs.zfs.arc_max: 32283127807 -> 32283127808
>>
>> Error 22 = EINVAL so I suspect you're requesting a value which one
>> of the following:
>> * < arc_abs_min
>> * > kmem_size
>> * < arc_c_min
>> * < zfs_arc_meta_limit
>>
>> Regards
>> Steve
>>
>> On 05/07/2016 22:56, Eric van Gyzen wrote:
>>
>> Steven and -current:
>>
>> I just updated to r302350 with a GENERIC kernel config.  I see
>> this in
>> dmesg:
>>
>>  VT(efifb): resolution 1024x768
>>  Setting sysctl vfs.zfs.arc_max failed: 22
>>  CPU: Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz
>> (3491.98-MHz K8-class
>>  CPU)
>>
>> The relevant parts of /boot/loader.conf are:
>>
>>  zfs_load="YES"
>>  vfs.zfs.arc_max="6442450944"
>>
>> Let me know what other information you need.
>>
>> Cheers,
>>
>> Eric
>>
>>
>> ___
>> freebsd-current@freebsd.org <mailto:freebsd-current@freebsd.org>
>> mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to
>> "freebsd-current-unsubscr...@freebsd.org
>> <mailto:freebsd-current-unsubscr...@freebsd.org>"
>>
>>
> 
> _______
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


I think the issue might be that the default value of arc_min is higher
than when the user is trying to set arc_max to. In that case we might
want sysctl to lower arc_min instead of giving an error?

It would definitely be a POLA violation to have to set arc_min lower to
be able to have existing lines that set arc_max in loader.conf work
correctly.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: FreeBSD 11-ALPHA6 bsdinstall(8) fails with root on ZFS + GELI

2016-07-05 Thread Allan Jude
On 2016-07-05 10:10, Jonathan Anderson wrote:
> On 5 Jul 2016, at 6:35, Marin BERNARD wrote:
> 
>> Hi all,
>>
>> I’ve been trying to install  FreeBSD Current (11.0 ALPHA5 & ALPHA6) with
>> encrypted root on ZFS, and was unable to complete the setup process. The
>> installation stops just after the GELI volume is initialized, and
>> bsdinstall(8) reports : mkdir : /mnt/boot : No such file or directory.
>> The
>> debug log file is attached. Note that this is from an Hyper-V VM, but the
>> same error also happens on real hardware.
>>
>> Any idea ?
>>
>> Thanks !
>>
>> Marin BERNARD
> 
> I've done some speculating in
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210815, but no answers
> there yet. I think the problem might be that the bootpool hasn't
> actually been mounted yet, so the /mnt/boot symlink points to a
> non-existent directory (/mnt/bootpool/boot).
> 
> 
> Jon
> -- 
> Jonathan Anderson
> jonat...@freebsd.org
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Indeed, the bootpool was not being remounted. This was fallout from a
change to avoid exporting and reimporting the pool unnecessarily. The
export/import step is only required for MBR formatted disks, in order to
write the bootcode into the secret slot in the ZFS disk label.

The problem was fixed in r302319 and was recorded in PR 210717

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: Unable to 'make config' ports under FreeBSD current

2016-07-01 Thread Allan Jude
On 2016-07-01 10:56, Larry Baird wrote:
> I recently installed FreebSD current using a snapshot ISO. I then used svnlite
> to bring FreeBSD source up to date. I then used portsnap fetch extract to
> bring my ports tree up todate. I was surprised I got errors doing 'make 
> config'
> for a port. I assumed it was a transitory problem. I have brought my system
> and ports up to date several times over the last few weeks, but the issue
> remains. The fix to the Makefile for the port to fix the issue is pretty
> simple. I figured I would soon see other people complainging about the issue.
> Since nobody has, I wonder if it is something in my environment.  Is anybody
> else having this issue?
> 
> uname -a shows I am running 
> 
> FreeBSD snake32.gta.com 11.0-ALPHA6 FreeBSD 11.0-ALPHA6 #0 r302305: Fri Jul  
> 1 03:45:06 EDT 2016 
> r...@snake32.gta.com:/usr/obj/usr/src/sys/GENERIC-NODEBUG  i386
> 
> 
> make config
> ===> Building/installing dialog4ports as it is required for the config dialog
> ===>  Cleaning for dialog4ports-0.1.5_2
> ===>  License BSD2CLAUSE accepted by the user
> ===>   dialog4ports-0.1.5_2 depends on file: /usr/local/sbin/pkg - found
> ===> Fetching all distfiles required by dialog4ports-0.1.5_2 for building
> ===>  Extracting for dialog4ports-0.1.5_2
> => SHA256 Checksum OK for dialog4ports-0.1.5.tar.gz.
> ===>  Patching for dialog4ports-0.1.5_2
> ===>  Configuring for dialog4ports-0.1.5_2
> ===>  Building for dialog4ports-0.1.5_2
> make[3]: "/usr/src/share/mk/src.libnames.mk" line 390: 
> /usr/ports/ports-mgmt/dialog4ports/work/dialog4ports-0.1.5: These libraries 
> should be LIBADD+=foo rather than DPADD/LDADD+=-lfoo:  ncursesw m dialog
> ===> Compilation failed unexpectedly.
> Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
> the maintainer.
> *** Error code 1
> 
> Stop.
> make[2]: stopped in /usr/ports/ports-mgmt/dialog4ports
> *** Error code 1
> 
> Stop.
> make[1]: stopped in /usr/ports/ports-mgmt/dialog4ports
> ===> Options unchanged
> 
> 

Are you sure the portsnap process finished successfully? It appears to
be trying to use the FreeBSD 9.x/10.x syntax for adding the dependencies
of dialog4ports, rather than the 11.x method.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


Re: Reproducible igb related panic 11.0-ALPHA4

2016-06-20 Thread Allan Jude

On 2016-06-20 18:18, Richard Perini wrote:

On Mon, Jun 20, 2016 at 02:54:30PM +1000, Richard Perini wrote:


Reproducible igb related panic 11.0-ALPHA4

OS: FreeBSD 11.0-ALPHA4 #6 r302022
Hardware: Asus P9D C224
(integrated <Intel(R) PRO/1000 Network Connection, Version - 2.5.3-k)


Hi,

Kernel panics within a few seconds with heavy network load. Using
"iperf -c another_host" is sufficient to induce the problem.  Setting
hw.igb.enable_msix=0 in loader.conf "solves" the problem.  Below is the
first few pages of crashinfo, + dmesg.  The problem occurs on 2 instances
of similar hardware (with same motherboards).


Submitted as PR 210417

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



I was not able to reproduce this on my hardware. Can you use 'pciconf 
-lv' to find your card and get more specifics on which model of igb(4) 
it is?


I am guessing by the C224 chipset, that it is haswell-ish

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


Re: memstick && Invalid partition table

2016-06-07 Thread Allan Jude
On 2016-06-07 04:56, Matthias Apitz wrote:
> 
> Hello,
> 
> To move a compiled system and kernel to other, smaller device I produce
> so called memsticks which are made with the script
> /usr/src/release/amd64/make-memstick.sh
> 
> They do, i.e. booting fine and showing for example on a netbook Acer C720 in
> /var/log/messages on attach:
> 
> Jun  7 10:35:43 c720-r292778-amd64 kernel: da0 at umass-sim0 bus 0 scbus1 
> target 0 lun 0
> Jun  7 10:35:43 c720-r292778-amd64 kernel: da0:  
> Removable Direct Access SCSI-2 device
> Jun  7 10:35:43 c720-r292778-amd64 kernel: da0: Serial Number 0902213131
> Jun  7 10:35:43 c720-r292778-amd64 kernel: da0: 40.000MB/s transfers
> Jun  7 10:35:43 c720-r292778-amd64 kernel: da0: 7712MB (15794176 512 byte 
> sectors)
> Jun  7 10:35:43 c720-r292778-amd64 kernel: da0: quirks=0x2
> 
> wnd with FDISK:
> 
> $ fdisk da0
> *** Working on device /dev/da0 ***
> parameters extracted from in-core disklabel are:
> cylinders=983 heads=255 sectors/track=63 (16065 blks/cyl)
> 
> parameters to be used for BIOS calculations are:
> cylinders=983 heads=255 sectors/track=63 (16065 blks/cyl)
> 
> Media sector size is 512
> Warning: BIOS sector numbering starts with sector 1
> Information from DOS bootblock is:
> The data for partition 1 is:
> sysid 238 (0xee),(EFI GPT)
> start 1, size 14683749 (7169 Meg), flag 0
>   beg: cyl 0/ head 0/ sector 2;
>   end: cyl 1023/ head 255/ sector 63
> The data for partition 2 is:
> 
> The data for partition 3 is:
> 
> The data for partition 4 is:
> 
> 
> 
> If I use the fine memstick on some other laptop, in this case a Dell
> Latitude E6330, it just says 'Invalid partition table!'
> 
> What could be wrong with it?
> 
>   matthias
> 

To fix the partition table to be the size of your memstick do:

gpart recover da0


If this does not work, try this (specific to some models of Dell
Latitude and some HPs):

gpart set -a active da0


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


Re: Streaming live tv over the udp protocol causes problems

2016-06-02 Thread Allan Jude
On 2016-06-01 23:03, Oleg Lelchuk wrote:
> Hi. On 11-ALPHA1, when I use vlc to stream live tv over the udp protocol, I
> see a garbled and choppy video. This issue doesn't occur on 10.3-STABLE. I
> am puzzled as to the cause of this problem.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

Are both machines FreeBSD?

Can you try running iperf in udp mode, something like this:

pkg install iperf

client: iperf -f m -i 1 -s -u
server: iperf -f m -i 1 -t 20 -c  -u -b 100m

And give us the results

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


Re: What builds go to snapshots?

2016-05-23 Thread Allan Jude
On 2016-05-23 10:10, Sergey Manucharian wrote:
> Excerpts from Allan Jude's message from Sun 22-May-16 23:55:
>> On 2016-05-22 23:33, Sergey Manucharian wrote:
>>> Is there any materialistic definition of those builds, which
>>> become snapshots at [0]?
>>>
>>> - Sergey
>>>
>>> [0] ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/11.0/
>>>
>> The snapshots are built with the scripts/makefiles in the 'release'
>> subdirectory of the source tree.
>  
> Thanks, Alan! But how is it determined/decided which particular build
> goes to "snapshots"? E.g. the latest builds are of May 18, why not of
> May 15 or 16?
> 
> S.
> 

That is just whenever the release engineers have time to build a
snapshot. There are not usually any special considerations.

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


Re: What builds go to snapshots?

2016-05-22 Thread Allan Jude
On 2016-05-22 23:33, Sergey Manucharian wrote:
> Is there any materialistic definition of those builds, which
> become snapshots at [0]?
> 
> - Sergey
> 
> [0] ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/11.0/
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

The snapshots are built with the scripts/makefiles in the 'release'
subdirectory of the source tree.

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


Re: ZFS on root, beadm, and the /boot symlink

2016-05-22 Thread Allan Jude
On 2016-05-22 14:41, Randy Westlund wrote:
> My system was installed from 10.1 or 10.2 with root on ZFS and geli, but
> now it tracks current.  It is not an EFI system.  I'm trying to get boot
> environments to work, but the /boot symlink is throwing me off.
> 
> I have two pools from the installer's layout; a small bootpool and
> zroot.  The bootpool mounts at /bootpool and /boot is a symlink to it.
> 
>> randy@mako /> zfs get mountpoint bootpool
>> NAME  PROPERTYVALUE   SOURCE
>> bootpool  mountpoint  /bootpool   local
>>
>> randy@mako /> ls -al /boot
>> lrwxr-xr-x  1 root  wheel  13 Aug 12  2015 /boot -> bootpool/boot
> 
> When I try to activate a boot environment, I get this error:
> 
>> root@mako:/ # beadm activate r300358
>> cp: /tmp/BE-r300358.FS6Xo6ot/boot/zfs/zpool.cache: No such file or directory
> 
> Because the new boot environment has a symlink to an empty directory:
> 
>> randy@mako /> ls -al /tmp/BE-r300358.FS6Xo6ot/boot
>> lrwxr-xr-x  1 root  wheel  13 Aug 12  2015 /tmp/BE-r300358.FS6Xo6ot/boot -> 
>> bootpool/boot
>>
>> randy@mako /> ls -al /tmp/BE-r300358.FS6Xo6ot/bootpool
>> total 9
>> drwxr-xr-x   2 root  wheel   2 Aug 18  2015 .
>> drwxr-xr-x  21 root  wheel  29 May 21 16:23 ..
> 
> Mergemaster complains about the /boot symlink as well.
> 
> I'm not sure what the cachefile does or why it's there.  It has a recent
> modification time, but neither pool seems to reference it.
> 
>> randy@mako /> zpool get cachefile zroot
>> NAME   PROPERTY   VALUE  SOURCE
>> zroot  cachefile  -  default
> 
>> randy@mako /> zpool get cachefile bootpool
>> NAME  PROPERTY   VALUE  SOURCE
>> bootpool  cachefile  -  default
> 
>> randy@mako /> ls -al /boot/zfs/zpool.cache
>> -rw-r--r--  1 root  wheel  2512 May 21 16:23 /boot/zfs/zpool.cache
> 
> What's the proper way to handle the /boot symlink with beadm?
> 
> Randy
> 

It is not possible to use boot environments when you have a separate
bootpool. This is the motivation for my recent work to implement GELI in
boot2 and loader, to allow you to combine GELI encryption with ZFS boot
environments, which previously required a second unencrypted pool for
the loader and kernel.

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


Re: UEFI root on ZFS (encrypted?)

2016-05-15 Thread Allan Jude
On 2016-05-15 11:38, Ben Woods wrote:
> On Sunday, 15 May 2016, Allan Jude <allanj...@freebsd.org
> <mailto:allanj...@freebsd.org>> wrote:
> 
> On 2016-05-15 05:19, Ben Woods wrote:
> > Hi everyone,
> >
> > I would like to reinstall my laptop to get root on ZFS with UEFI.
> I will
> > use a recent snapshot image to install FreeBSD 11 current.
> >
> > There has been a lot of good work on this lately, and I have
> fallen out
> > of touch with the status. A couple of questions:
> >
> > 1. Can the UEFI loader now boot root on ZFS without a freebsd-boot
> > partition?
> 
> Yes, you just need the EFI partition
> 
> >
> > 2. Can it do it with geli encryption?
> >
> 
> Not yet
> 
> --
> Allan Jude
> 
> 
> Ok, thanks for that. Is there a review on phabricator (or multiple) that
> I can build a release iso with and help test for this setup (with or
> without it being in the installer)?
> 
> A search of phabricator shows there are a number that could be related.
> 
> Thanks,
> Ben
> 
> 
> -- 
> 
> --
> From: Benjamin Woods
> woods...@gmail.com <mailto:woods...@gmail.com>

None of my work GELI touches EFI yet.

Eric McCorkle (who did most of the original EFI ZFS work) is doing that,
he just posted an update on his work about 90 minutes ago on
freebsd-hackers@:

https://lists.freebsd.org/pipermail/freebsd-hackers/2016-May/049435.html

I am not sure if he has posted the GELI patches yet, but he'd be the
person to contact about testing.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature


  1   2   3   4   5   >