On 01/12/18 23:34, Rodney W. Grimes wrote:
>
> There is work going on in -current by Warner (imp@) called devmatch that
> makes this issue go away and rips out all the other drivers from GENERIC
> that can be automatically loaded by devmatch in the future.
>
That resolves the problem for Current,
> On Thu, Jan 11, 2018 at 10:14:55AM -0800, Maxim Sobolev wrote:
> > Well, that might work, but I am curious why do we have all other network 40
> > or so drivers in the GENERIC but not this one. Considering significant
> > portion of FreeBSD systems deployed these days are going to be running on
>
On Thu, Jan 11, 2018 at 10:14:55AM -0800, Maxim Sobolev wrote:
> Well, that might work, but I am curious why do we have all other network 40
> or so drivers in the GENERIC but not this one. Considering significant
> portion of FreeBSD systems deployed these days are going to be running on
> the clo
Well, that might work, but I am curious why do we have all other network 40
or so drivers in the GENERIC but not this one. Considering significant
portion of FreeBSD systems deployed these days are going to be running on
the cloud this makes no sense to me. Is there some policy out there which
gove
On 01/10/2018 21:34, Maxim Sobolev wrote:
Hi, today we've migrated one of our FreeBSD EC2 r4.xlarge instances and
painstakingly found that xn(4) interface is no longer provided by the
Amazon "hardware". ena(4) seems to be now default for a newly created VMs,
but it's not part of the GENERIC ker
Hi, today we've migrated one of our FreeBSD EC2 r4.xlarge instances and
painstakingly found that xn(4) interface is no longer provided by the
Amazon "hardware". ena(4) seems to be now default for a newly created VMs,
but it's not part of the GENERIC kernel. This could affect both new users
trying t
