Re: FreeBSD panics possibly caused by nfs clients

[Zaphod Beeblebrox]

Just in case it's relevant, I'm carrying around this patch on my fairly
busy little RISC-V machine.

diff --git a/sys/fs/nfsclient/nfs_clvnops.c b/sys/fs/nfsclient/nfs_clvnops.c
index 0b8c587a542c..85c0ebd7a10f 100644
--- a/sys/fs/nfsclient/nfs_clvnops.c
+++ b/sys/fs/nfsclient/nfs_clvnops.c
@@ -2459,6 +2459,16 @@ nfs_readdir(struct vop_readdir_args *ap)
return (EINVAL);
uio->uio_resid -= left;

+   /*
+* For readdirplus, if starting to read the directory,
+* purge the name cache, since it will be reloaded by
+* this directory read.
+* This removes potentially stale name cache entries.
+*/
+   if (uio->uio_offset == 0 &&
+   (VFSTONFS(vp->v_mount)->nm_flag & NFSMNT_RDIRPLUS) != 0)
+   cache_purge(vp);
+
/*
 * Call ncl_bioread() to do the real work.
 */
.. without it, I can panic.


On Fri, Feb 9, 2024 at 4:18 PM Mark Johnston  wrote:

> On Fri, Feb 09, 2024 at 06:23:08PM +, Matthew L. Dailey wrote:
> > I had my first kernel panic with a KASAN kernel after only 01:27. This
> > first panic was a "double fault," which isn't anything we've seen
> > previously - usually we've seen trap 9 or trap 12, but sometimes others.
> > Based on the backtrace, it definitely looks like KASAN caught something,
> > but I don't have the expertise to know if this points to anything
> > specific. From the backtrace, it looks like this might have originated
> > in ipfw code.
>
> A double fault is rather unexpected.  I presume you're running
> releng/14.0?  Is it at all possible to test with FreeBSD-CURRENT?
>
> Did you add INVARIANTS etc. to the kernel configuration used here, or
> just KASAN?
>
> > Please let me know what other info I can provide or what I can do to dig
> > deeper.
>
> If you could repeat the test several times, I'd be interested in seeing
> if you always get the same result.  If you're willing to share the
> vmcore (or several), I'd be willing to take a look at it.
>
> > Thanks!!
> >
> > Panic message:
> > [5674] Fatal double fault
> > [5674] rip 0x812f6e32 rsp 0xfe014677afe0 rbp
> 0xfe014677b430
> > [5674] rax 0x1fc028cef620 rdx 0xf2f2f2f8f2f2f2f2 rbx 0x1
> > [5674] rcx 0xd7c0 rsi 0xfe004086a4a0 rdi
> 0xf8f8f8f8f2f2f2f8
> > [5674] r8 0xf8f8f8f8f8f8f8f8 r9 0x162a r10 0x835003002d3a64e1
> > [5674] r11 0 r12 0xf78028cef620 r13 0xfe004086a440
> > [5674] r14 0xfe01488c0560 r15 0x26f40 rflags 0x10006
> > [5674] cs 0x20 ss 0x28 ds 0x3b es 0x3b fs 0x13 gs 0x1b
> > [5674] fsbase 0x95d1d81a130 gsbase 0x84a14000 kgsbase 0
> > [5674] cpuid = 4; apic id = 08
> > [5674] panic: double fault
> > [5674] cpuid = 4
> > [5674] time = 1707498420
> > [5674] KDB: stack backtrace:
> > [5674] Uptime: 1h34m34s
> >
> > Backtrace:
> > #0  __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:57
> > #1  doadump (textdump=) at
> > /usr/src/sys/kern/kern_shutdown.c:405
> > #2  0x8128b7dc in kern_reboot (howto=howto@entry=260)
> >  at /usr/src/sys/kern/kern_shutdown.c:526
> > #3  0x8128c000 in vpanic (
> >  fmt=fmt@entry=0x82589a00  "double fault",
> >  ap=ap@entry=0xfe0040866de0) at
> > /usr/src/sys/kern/kern_shutdown.c:970
> > #4  0x8128bd75 in panic (fmt=0x82589a00  "double
> > fault")
> >  at /usr/src/sys/kern/kern_shutdown.c:894
> > #5  0x81c4b335 in dblfault_handler (frame=)
> >  at /usr/src/sys/amd64/amd64/trap.c:1012
> > #6  
> > #7  0x812f6e32 in sched_clock (td=td@entry=0xfe01488c0560,
> >  cnt=cnt@entry=1) at /usr/src/sys/kern/sched_ule.c:2601
> > #8  0x8119e2a7 in statclock (cnt=cnt@entry=1,
> >  usermode=usermode@entry=0) at /usr/src/sys/kern/kern_clock.c:760
> > #9  0x8119fb67 in handleevents (now=now@entry=24371855699832,
> >  fake=fake@entry=0) at /usr/src/sys/kern/kern_clocksource.c:195
> > #10 0x811a10cc in timercb (et=, arg= out>)
> >  at /usr/src/sys/kern/kern_clocksource.c:353
> > #11 0x81dcd280 in lapic_handle_timer (frame=0xfe014677b750)
> >  at /usr/src/sys/x86/x86/local_apic.c:1343
> > #12 
> > #13 __asan_load8_noabort (addr=18446741880219689232)
> >  at /usr/src/sys/kern/subr_asan.c:1113
> > #14 0x851488b8 in ?? () from /boot/thayer/ipfw.ko
> > #15 0xfe01 in ?? ()
> > #16 0x8134dcd5 in pcpu_find (cpuid=1238425856)
> >  at /usr/src/sys/kern/subr_pcpu.c:286
> > #17 0x85151f6f in ?? () from /boot/thayer/ipfw.ko
> > #18 0x in ?? ()
>
>

Re: Writing large build logs to NFS extremely slow?

[Zaphod Beeblebrox]

Is the NFS mounted filesystem NFS?  I've found NFS mounted ZFS has several
pathologies like this when there is no SSD cache and/or log vdevs attached.

On Wed, Oct 6, 2021 at 10:18 PM Felix Palmen  wrote:

> Hi all,
>
> I use a -CURRENT bhyve vm for testing port builds with poudriere. As
> this vm is only running when needed, but I want to always have access to
> the build logs, I use NFS to mount /usr/local/poudriere/data/logs from
> the host.
>
> I noticed some few ports take ridiculously long to build while barely
> using any CPU time at all. On a closer look, that's all ports producing
> a lot of compiler (warning) output, e.g. gcc, gnutls, gtk2, …
>
> So I assume appending to a large file via NFS gets slower and slower. Is
> there any mount option I could try to fix this? Right now I only have
> `nolockd`, I also tried `noncontigwr` which didn't change anything.
>
> Thinking about alternatives to NFS, are there any news for client-side
> 9p virtfs? I found  which
> still builds with a few minor adaptions, but trying to mount a 9p share
> freezes the machine.
>
> Would you suggest a different mailing list to ask?
>
> BR, Felix
>
> --
>  Dipl.-Inform. Felix Palmen ,.//..
>  {web}  http://palmen-it.de  {jabber} [see email]   ,//palmen-it.de
>  {pgp public key} http://palmen-it.de/pub.txt   //   """
>  {pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A
>

Re: databases/postgresl13-server issue: micsompilation on IvyBridge arch?

[Zaphod Beeblebrox]

IIRC, isn't the postgresql-server's default install on FreeBSD, from ports,
have TCP turned off?  IE: try editing the config (in the database
directory) to uncomment the listen directive?

On Sun, Aug 8, 2021 at 5:21 AM FreeBSD User  wrote:

> Hello,
>
> on all(!) of my home systems based on Intel's IvyBridge CPU architecture
>
> a) CPU microcode: updated from 0x1f to 0x21
>CPU: Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz (3200.09-MHz K8-class CPU)
>
> b) CPU microcode: updated from 0x1f to 0x21
>CPU: Intel(R) Xeon(R) CPU E3-1245 V2 @ 3.40GHz (3400.09-MHz K8-class
> CPU)
>
> I face a severe and nasty problem:
>
> database/postgresql12-server, database/postgresql13-server,
> database/postgresql14-server, when
> installed, do not allow any kind of tcp/ip connections, even on ::1 or
> 127.0.0.1 (localhost).
> All systems in question are dual stack and fully configured using IPv6.
> Firewall is FreeBSD
> standard IPFW running from /etc/rc.conf (port 5432/tcp is open and
> listening as one can check
> via sockstat -4 or sockstat -6).
>
> The hosts in question do run 14-CURRENT (with customized kernels).
>
> Phenomenon:
>
> Login locally via "psql -U postgres -d postgres" via socket works for ALL
> DB users on all
> configured to access databases as expected. Login via "psql -U postgres -d
> postgres -h
> localhost" (or any form of an IP if access tried from another remote host,
> even locally via
> 127.0.0.1 or ::1) does result in:
>
> : psql -U postgres -d postgres -h localhost
> psql: error: server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
>
> On the server's postgresql log I always see connection attempts like:
>
> [...]
> 2021-08-08 08:56:57.601 GMT [42987] LOG:  connection received:
> host=localhost port=12340
>
> but nothing more, no error message or any kind of timeout message.
>
> I tried to raise the log level to debug, but it is always nothing shown
> execept the initial
> connection attempt.
>
> What I tried so far:
> I used either self compiled ports or packages taken via pkg fetch from the
> official FreeBSD
> pkg repos. I had LLVM suspected to miscompile something on IvyBridge. No
> different result so
> far. Postgres 12, 13 14 fail the same way.
>
> I installed with the above strategy vanilla databases. That includes a
> pg_hba.conf with the
> follwoing lines (as anybody can proof):
>
> [...]
> # TYPE  DATABASEUSERADDRESS METHOD
>
> # "local" is for Unix domain socket connections only
> local   all all trust
> # IPv4 local connections:
> hostall all 127.0.0.1/32trust
> # IPv6 local connections:
> hostall all ::1/128 trust
> hostall all 0.0.0.0/32  trust
> hostall all ::/128  trust
>
>
> That should grant access via "localhost" and, for test purposes, access
> from any other machine
> in our LAN for any user to any database.
>
> Also, I configured postgresql13-server's postgresql.conf with following
> additions:
>
> log_destination = 'syslog,stderr'
> log_min_messages = debug5
> log_min_error_statement = debug5
>
> debug_print_parse = on
> debug_print_rewritten = on
> debug_print_plan = on
> debug_pretty_print = on
> log_checkpoints = on
> log_connections = on
> log_disconnections = on
> log_duration = on
> log_error_verbosity = verbose   # terse, default, or verbose messages
> log_hostname = on
>
> Trying again a login from localhost via the psql command show above, gives
> this :
>
>
> [...]
> 2021-08-08 09:12:12.999 GMT [55664] DEBUG:  0: forked new backend,
> pid=55673 socket=12
>
> 2021-08-08 09:12:12.999 GMT [55664] LOCATION:  BackendStartup,
> postmaster.c:4232
>
> 2021-08-08 09:12:13.000 GMT [55673] LOG:  0: connection received:
> host=localhost
> port=42708
>
> 2021-08-08 09:12:13.000 GMT [55673] LOCATION:  BackendInitialize,
> postmaster.c:4385
>
> 2021-08-08 09:12:19.994 GMT [55667] DEBUG:  0: snapshot of 0+0 running
> transaction ids
> (lsn 0/15FF178 oldest xid 487 latest complete 486 next xid 487)
> 2021-08-08 09:12:19.994 GMT [55667] LOCATION:  LogCurrentRunningXacts,
> standby.c:1124
> 2021-08-08 09:13:04.988 GMT [55669] DEBUG:  0: StartTransaction(1)
> name: unnamed;
> blockState: DEFAULT; state: INPROGRESS, xid/subid/cid: 0/1/0
> 2021-08-08 09:13:04.988 GMT [55669] LOCATION:  ShowTransactionStateRec,
> xact.c:5358
> 2021-08-08 09:13:04.988 GMT [55669] DEBUG:  0: CommitTransaction(1)
> name: unnamed;
> blockState: STARTED; state: INPROGRESS, xid/subid/cid: 0/1/0
> 2021-08-08 09:13:04.988 GMT [55669] LOCATION:  ShowTransactionStateRec,
> xact.c:5358
> 2021-08-08 09:13:04.988 GMT [55670] DEBUG:  0: received inquiry for
> database 0
> 2021-08-08 09:13:04.988 GMT [55670] LOCATION:  pgstat_recv_inquiry,

Re: nvme(4) losing control, and subsequent use of fsck_ffs(8) with UFS

[Zaphod Beeblebrox]

One thing, that I'm sure the developers know, but that might be
underappreciated at the user level:

These things are little computers ... with their own little operating
systems and as such, their own little bugs.  This means that the quality
can swing very wildly between different examples of cheap dodgy hardware.
I mean... it's also true that disk drives have been run by microcontrollers
for 20-odd-years (or more), but the sheer number of vendors who can
contract with PCBwy (favorite utuber in my head, sorry) and get an NVMe
drive completely manufactured and onto Amazon is somewhat unprecedented.

Dodgy hardware doesn't need a factory anymore.

On Sat, Jul 17, 2021 at 11:48 AM Warner Losh  wrote:

> On Sat, Jul 17, 2021 at 6:33 AM Graham Perrin 
> wrote:
>
> > When the file system is stress-tested, it seems that the device (an
> > internal drive) is lost.
> >
>
> This is most likely a drive problem. Netflix pushes half a dozen different
> lower-end
> models of NVMe drives to their physical limits w/o seeing issues like this.
>
> That said, our screening process screens out several low-quality drives
> that just
> lose their minds from time to time.
>
>
> > A recent photograph:
> >
> > 
> >
> > Transcribed manually:
> >
> > nvme0: Resetting controller due to a timeout.
> > nvme0: resetting controller
> > nvme0: controller ready did not become 0 within 5500 ms
> >
>
> Here the controller failed hard. We were unable to reset it within 5
> seconds. One might
> be able to tweak the timeouts to cope with the drive better. Do you have to
> power cycle
> to get it to respond again?
>
>
> > nvme0: failing outstanding i/o
> > nvme0: WRITE sqid:2 cid:115 nsid:1 lba:296178856 len:64
> > nvme0: ABORTED - BY REQUEST (00/07) sqid:2 cid:115 cdw0:0
> > g_vfs_done():nvd0p2[WRITE(offset=151370924032, length=32768)]error = 6
> > UFS: forcibly unmounting /dev/nvd0p2 from /
> > nvme0: failing outstanding i/o
> >
> > … et cetera.
> >
> > Is this a sure sign of a hardware problem? Or must I do something
> > special to gain reliability under stress?
> >
>
> It's most likely a hardware problem. that said, I've been working on
> patches to
> make the recovery when errors like this happen better.
>
>
> > I don't how to interpret parts of the manual page for nvme(4). There's
> > direction to include this line in loader.conf(5):
> >
> > nvme_load="YES"
> >
> > – however when I used kldload(8), it seemed that the module was already
> > loaded, or in kernel.
> >
>
> Yes. If you are using it at all, you have the driver.
>
>
> > Using StressDisk:
> >
> > 
> >
> > – failures typically occur after around six minutes of testing.
> >
>
> Do you have a number of these drives, or is it just this one bad apple?
>
>
> > The drive is very new, less than 2 TB written:
> >
> > 
> >
> > I do suspect a hardware problem, because two prior installations of
> > Windows 10 became non-bootable.
> >
>
> That's likely a huge red flag.
>
>
> > Also: I find peculiarities with use of fsck_ffs(8), which I can describe
> > later. Maybe to be expected, if there's a problem with the drive.
> >
>
> You can ask Kirk, but if data isn't written to the drive when the firmware
> crashes, then there may be data loss.
>
> Warner
>

Re: AMNESIA:33 and FreeBSD TCP/IP stack involvement

[Zaphod Beeblebrox]

I'm not posting as someone in-the-know about the state of the FreeBSD stack
--- I trust the security team to divulge things as required,

BUT ...

... the examples of vulnerable things in that article to reference lead me
to conclude that the stacks in question are "libraries" ... likely, but not
necessarily, written in C for systems running in an operating system-less
environment.  The easiest way to think about this is to look at the "at
mega" line (also known as arduino).  This is an 8-bit processor and the C
development kit allows you to link in all kinds of stuff --- from
filesystems and micro-sd card support to wifi and IP/IPv6 support.  The
same libraries are used when the target is a more powerful ARM chip --- but
one similarly running without something as full-fledged as an OS --- or
even when a very small vestige of an OS includes these libraries.

You could think of these libraries like "what if someone wrote an IP stack
for the commodore 64 and then also ported it to the Amiga" ... as a
computer without an operating system and then a port to a computer with an
operating system with no concept of networking.

At any rate, these, in general, do not even resemble the network stack in
FreeBSD... or indeed any other full fledged operating system.

Hopfully this tidbit helps in some small way.


On Wed, Dec 9, 2020 at 12:59 AM Hartmann, O.  wrote:

> Hello,
> I've got a question about recently discovered serious vulnerabilities
> in certain TCP stack implementations, designated as AMNESIA:33 (as far
> as I could follow the recently made announcements and statements,
> please see, for instance,
>
> https://www.zdnet.com/article/amnesia33-vulnerabilities-impact-millions-of-smart-and-industrial-devices/
> ).
>
> All mentioned open-source TCP stacks seem not to be related in any way
> with freeBSD or any derivative of the FreeBSD project, but I do not
> dare to make a statement about that.
>
> My question is very simple and aimes towards calming down my employees
> requests: is FreeBSD potentially vulnerable to this newly discovered
> flaw (we use mainly 12.1-RELENG, 12.2-RELENG, 12-STABLE and 13-CURRENT,
> latest incarnations, of course, should be least vulnerable ...).
>
> Thanks in advance,
>
> O. Hartmann
>
___
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: Plans for git

[Zaphod Beeblebrox]

Actually, frankly, yes.  Nearly the first cogent summary I've found so far.

On Sat, Sep 19, 2020 at 2:22 AM Warner Losh  wrote:

>
>
> On Fri, Sep 18, 2020, 11:31 PM Zaphod Beeblebrox 
> wrote:
>
>> Hrm.  Maybe what I hear others saying, tho, and not entirely being
>> replied to is just a nice concise document of the why.  What I hear you
>> saying is that GIT has momentum and that it's popular... (and I accept that
>> --- it is evidently true), but then I hear handwaving about features, but
>> no list of features that are a clear win/loose.
>>
>
> Apache has switched to git from subversion. They are the current
> caretakers of subversion so it's future is very much in doubt.
>
> Git have more support for newer CI tools than subversion. This will allow
> us, once things are fully phased in, to increase the quality of the code
> going into the tree, as well as greatly reduce build breakages and
> accidental regressions.
>
> Gits merging facilities are much better than subversion. You can more
> easily curate patches as well since git supports a rebase workflow. This
> allows cleaner patches that are logical bits for larger submissions.
> Subversion can't do this.
>
> Git can easily and robustly be mirrored. Subversion can be mirrored, but
> that mirroring is far from robust. One of the snags in the git migration is
> that different svn mirrors have different data than the main repo or each
> other. Git can cryptographically sign tags and commits. Subversion cannot.
>
> Mirroring also opens up more 3rd party plug ins. Gitlab can do some
> things, Github others, in terms of automated testing and continuous
> integration. Tests can be run when branches are pushed. Both these
> platforms have significant collaboration tools as well, which will support
> groups going off and creating new features for FreeBSD.  While one can use
> these things to a limited degree, with subversion mirrored to github, the
> full power of these tools isn't fully realized without a conversion to git.
>
> All of this is before the skillset arguments are made about kids today
> just knowing git, but needing to learn subversion and how that has had
> increasing been a source of friction.  This argument is the closest one to
> being handwavy since I've not voted the data showing the growing proportion
> of projects using git (iirc, it's 85% or 90%).
>
> These are the main ones. The three down sides are lack of $FreeBSD$
> support and tags in general. Git has a weaker count of commits than
> subversion. And the BSDL git clients are less mature than the GPL'd ones.
>
> Certainly the only clear things a quick search turns up that seem relevant
>> is that GIT is GPL2.0 and SVN is Apache2.0.  This was enough for LLVM vs
>> GCC and the repository is a core function, but I suppose not a necessary
>> function for forked projects that can't abide, so...
>>
>
> OPENBSD has got, which is being ported in earnest. It has an agreeable
> license.
>
> Anyways... some concise record of thoughts might calm the gnawing
>> sensation in my gut...
>>
>
> Yes. I've started doing a series of short videos explaining the change,
> why we are doing it and what to do in the new world order. I'll be doing
> blog entries as well as turning that material into handbook entries. I have
> some of those written.
>
> Does this help?
>
> Warner
>
> On Thu, Sep 3, 2020 at 4:19 PM Warner Losh  wrote:
>>
>>> On Thu, Sep 3, 2020 at 1:32 PM Chris  wrote:
>>>
>>> > On 2020-09-03 11:33, Kristof Provost wrote:
>>> > > On 3 Sep 2020, at 19:56, Chris wrote:
>>> > >> Why was the intention to switch NOT announced as such MUCH sooner?
>>> > >>
>>> > > There was discussion about a possible switch to git on the
>>> freebsd-git
>>> > > mailing
>>> > > list as early as February 2017:
>>> > >
>>> >
>>> https://lists.freebsd.org/pipermail/freebsd-git/2017-February/92.html
>>> > >
>>> > > Ed gave a talk about FreeBSD and git back in 2018:
>>> > > https://www.youtube.com/watch?v=G8wQ88d85s4
>>> > >
>>> > > The Git Transition Working group was mentioned in the quarterly
>>> status
>>> > > reports a
>>> > > year ago:
>>> > https://www.freebsd.org/news/status/report-2019-07-2019-09.html
>>> > > and
>>> > > https://www.freebsd.org/news/status/report-2019-04-2019-06.html
>>> > It appears to me that the references you make here all allude to
>>> > _investigation_
>>> > of a _possibi

Re: Plans for git

[Zaphod Beeblebrox]

Hrm.  Maybe what I hear others saying, tho, and not entirely being replied
to is just a nice concise document of the why.  What I hear you saying is
that GIT has momentum and that it's popular... (and I accept that --- it is
evidently true), but then I hear handwaving about features, but no list of
features that are a clear win/loose.

Certainly the only clear things a quick search turns up that seem relevant
is that GIT is GPL2.0 and SVN is Apache2.0.  This was enough for LLVM vs
GCC and the repository is a core function, but I suppose not a necessary
function for forked projects that can't abide, so...

Anyways... some concise record of thoughts might calm the gnawing sensation
in my gut...

On Thu, Sep 3, 2020 at 4:19 PM Warner Losh  wrote:

> On Thu, Sep 3, 2020 at 1:32 PM Chris  wrote:
>
> > On 2020-09-03 11:33, Kristof Provost wrote:
> > > On 3 Sep 2020, at 19:56, Chris wrote:
> > >> Why was the intention to switch NOT announced as such MUCH sooner?
> > >>
> > > There was discussion about a possible switch to git on the freebsd-git
> > > mailing
> > > list as early as February 2017:
> > >
> >
> https://lists.freebsd.org/pipermail/freebsd-git/2017-February/92.html
> > >
> > > Ed gave a talk about FreeBSD and git back in 2018:
> > > https://www.youtube.com/watch?v=G8wQ88d85s4
> > >
> > > The Git Transition Working group was mentioned in the quarterly status
> > > reports a
> > > year ago:
> > https://www.freebsd.org/news/status/report-2019-07-2019-09.html
> > > and
> > > https://www.freebsd.org/news/status/report-2019-04-2019-06.html
> > It appears to me that the references you make here all allude to
> > _investigation_
> > of a _possibility_ as opposed to a _likelihood_, or an _inevitable_.
> > IMHO a change as significant as this, which will require tossing years of
> > tooling
> > out the window, and an untold amount of _re_tooling. Should have created
> an
> > announcement at _least_ as significant as a new release gets on the
> mailing
> > lists.
> >
>
> Yes. We've been working on this for years. We've been working on the
> retooling in earnest for the last 6 months. We didn't make an announcement
> because we wanted to have most of the pieces in place before we did that.
> We've been doing the multi-year process for multiple years now. I'll also
> point out that only the 'git' people showed. A number of other ideas were
> suggested, but nothing else was stood up in a serious way (hg came the
> closest to setting up an exporter). Since there was really no alternatives
> being proposed to git, the process was less visible than if we'd had to
> have had a hg vs git bake off. One step has lead to the next, with much
> status reporting done for years.
>
> Subversion, btw, is not viable in the long run. The Apache foundation has
> moved all its projects from svn to git. The velocity of features with svn
> has diminished, and the number of CI/CT/etc tool sets that supported svn
> well has been dropping over time. It's also been identified as a barrier to
> entry for the project. Sure, some people climb the learning curve to learn
> and understand it, but our survey data has shown that for every one that
> did take the time, many others did not and simply didn't contribute.
>
> All of these issues have been discussed at length at conferences for the
> last 5 years at least, with increasing levels of sophistication. Had there
> been a BSDcan this year, I'd hoped to do a talk / BOF on this to help
> socialize the ideas and to get people's feedback in real time (rather than
> the slow and difficult process of getting it just in email).
>
> We've also talked about this in the BSD office hours and core election
> forums over the past year.
>
> We've been rolling out the beta git repo now for 3 months. People have
> found issues and we've been correcting them. We've heard from people that
> their automated tooling needs a bit of transition time, so we'll be
> exporting the stable/11 and stable/12 branches back into subversion (and
> the release branches) after the conversion for the life of those
> branches, though we don't plan on doing it for the current nor stable/13
> branches (due to the inefficiencies of git-svn, we need separate trees for
> each, and each tree takes over a day to setup). We know we need some better
> docs (we have some decent preliminary ones, but there's some missing bits
> in them, and they are too long for more casual users). We need to spell out
> different commit policies, how we're going to have to shift our "MFC"
> terminology because that's very CVS/SVN centric (in git a merge means a
> more specific thing than it does in svn. A cherry-pick in git is also
> called a merge in svn, for example). We need to document to the developers
> how to make the shift (this doc is mostly complete and was posted earlier,
> though it could use some TLC). We'd hoped to have the documents done, the
> policies written and vetted and have a good test system before making an
> announcement. 

Re: ipv6/ppp: FreeBSD obtains linklocal on tun0 only

[Zaphod Beeblebrox]

As someone who controls both ends of the link (runs the ISP, has service
from the ISP), so far (a bit out of laziness) I have the following
solution...

Now... of note is that we statically assign addresses.  This is not just
being nice, but being practical.  We deal out IPv4 addresses vi IPCP, but
they are, in fact, statically assigned.  In radius we assign IPv6
addresses.  On the servers, we run this ifaceup script:

#!/bin/bash
#
# Add a route to the interface, if appropriate.

PATH=/sbin:/usr/local/bin:$PATH
date=`date`

interface="$1"
authname="$5"

route=`psql -tA --user mpd5 --host postgres.host.com -c "select value from
radreply where username = '$authname' and attribute = 'Framed-IPv6-Route'"
radius`

if [ -n "$route" ]; then
route -n6 add $route -iface $interface
fi

echo $interface $authname $route $date >>/tmp/mpd5-if-up

It may be prudent to note here that OSPF keeps track of these routes, so we
don't need to.  There's no ifdown script because mpd5 destroys the ngX
interface which deletes the route (99 out of 100 times).

On the client side, we enable ipv6cp (for link local stuff).  Then we add
an ifup script:

/sbin/route -n add -inet6 default -iface ng0 >/tmp/ipv6routeup.log 2>&1

... it might be useful to note that non-BSD endpoints (we use the
linux-based SmartRG modems) seem to add the IPv6 default route
automatically.  We then set the first address statically to the ethernet
device.  This, so far, has been enough to make things work smoothly.

(obPitch: if you're in Canada and can get DSL where you are, hit me up for
a FreeBSD-only (no Cisco) connection)
___
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"

AMD RAID support?

[Zaphod Beeblebrox]

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"

Re: Call for Testing: UEFI Changes

[Zaphod Beeblebrox]

As I said I would, I put the contents of /boot onto the FAT-formated EFI
partition.  This is suboptimal.  The default is to use "kernel.old" ...
etc  ... which cannot be done on a FAT partition... at least not with our
filesystem driver ...

... but with all of /boot on the EFI partition, simply starting loader.efi
works.

On Wed, Apr 4, 2018 at 11:57 AM, Kyle Evans  wrote:

> On Wed, Mar 21, 2018 at 7:45 PM, Kyle Evans  wrote:
> > Hello!
> >
> > A number of changes have gone in recently pertaining to UEFI booting
> > and UEFI runtime services. The changes with the most damaging
> > potential are:
> >
> > We now put UEFI runtime services into virtual address mode, fixing
> > runtime services with U-Boot/UEFI as well as the firmware
> > implementation in many Lenovos. The previously observed behavior was a
> > kernel panic upon invocation of efibootmgr/efivar, or a kernel panic
> > just loading efirt.ko or compiling EFIRT into the kernel.
> >
> > Graphics mode selection is now done differently to avoid regression
> > caused by r327058 while still achieving the same effect. The observed
> > regression was that the kernel would usually end up drawing
> > incorrectly at the old resolution on a subset of the screen, due to
> > incorrect framebuffer information.
> >
> > Explicit testing of these changes, the latest of which happened in
> > r331326, and any feedback from this testing would be greatly
> > appreciated. Testing should be done with either `options EFIRT` in
> > your kernel config or efirt.ko loaded along with updated bootloader
> > bits.
> >
> > I otherwise plan to MFC commits involved with the above-mentioned
> > changes by sometime in the first week of April, likely no earlier than
> > two (2) weeks from now on April 4th.
> >
> > Thanks,
> >
> > Kyle Evans
>
> As partially promised, the non-graphics related changes have been
> MFC'd to stable/11 today as r332028.
>
> The graphics related changes are going to simmer longer and probably
> get ripped out, because we're bad at this.
>
> Thanks,
>
> Kyle Evans
> ___
> 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"

Re: Call for Testing: UEFI Changes

[Zaphod Beeblebrox]

If you're thinking on it,  you should know that the DVD version works.  The
difference, AFAICT, is that it simply calls loader.efi directly.  Ie:
bootx64.efi is loader.efi, not boot1.efi.

Loader.efi doesn't seem to change the screen mode when it starts.  When the
kernel starts afterwards, this all just works.

I assume loader.efi works here because CD9660 is a format supported by
EFI.  Thus loader.efi can directly read it.  That and/or loader can work
with the device is was started from.

When I start boot1.efi on this system, it changes mode, then it continues.

... so if you've got a boot1.efi that doesn't change mode, can you post
that binary for me to try ... ?

On Tue, Apr 3, 2018 at 4:48 PM, Kyle Evans  wrote:

> On Tue, Apr 3, 2018 at 3:17 PM, Kyle Evans  wrote:
> > Hi,
> >
> > Right- so, `gop set 0` should've immediately cleared your screen and
> > put it into 1920x1080, full stop. If it did not, I think that's
> > indicative of some kind of interestingly broken firmware...
> >
> > Regardless! We're clearly bad at trying to set a mode before the
> > kernel starts, so r331904 sets the default max resolution in such a
> > way that we just don't change the resolution by default anymore and
> > interested parties can bump that up if they want to try it. This
> > Thursday's snapshots should have this included.
>
> After reviewing the video again and discussing it with manu, I don't
> think that commit's going to solve your problem at all... we'll need
> to re-think this one a bit more.
>
> > I think if we're going to change modes as a default, we should have
> > some way for vt/efifb to use EFIRT or be notified by EFIRT of
> > supported resolutions so that vt/efifb can hopefully just handle it
> > all and do it properly. This approach would be more similar I guess to
> > how KMS drivers operate, and less fragile than what we're seeing with
> > these different approaches we've taken.
> >
>
___
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: Call for Testing: UEFI Changes

[Zaphod Beeblebrox]

I did as you asked.  You can see the result at:
https://owncloud.towernet.ca/s/6K3pGknCyGTi7du

... but the long and short of it is that even though the loader is printing
in the center of the screen (text mode?), it sees the 1920x1080 mode as the
"mode 0" ... I even tried "gop set 0" ... which it accepted, but then
continuing to boot produced what you see in the video.

I think, since it's in the cetner of the screen, that we're looking at
80x25 text... which is ... 800 x 600 -ish?  The kernel definately wants
graphics again ... but ... I dunno ... is it getting it?  Is the 80x25 text
mode emulated on a bitmapped screen?


On Mon, Apr 2, 2018 at 9:07 PM, Kyle Evans <kev...@freebsd.org> wrote:

> On Mon, Apr 2, 2018 at 5:51 PM, Zaphod Beeblebrox <zbee...@gmail.com>
> wrote:
> > On Sun, Apr 1, 2018 at 7:41 PM, David NewHamlet <wheelcomp...@gmail.com>
> > wrote:
> >>
> >> Fixed in: FreeBSD-12.0-CURRENT-amd64-20180329-r331740-disc1.iso
> >>
> >>
> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176694
> >>
> >> On Mon, Apr 2, 2018 at 12:38 AM, Tomoaki AOKI <
> junch...@dec.sakura.ne.jp>
> >> wrote:
> >>
> >> > Confirmed both loader (with boot1) part and efirt.ko part.
> >> > Working OK on my ThinkPad420 (with nvidia GPU) at r331864.
> >> >
> >> > No benefit (VGA resolution) but no new harm (no panic nor silent
> >> > reboot).
> >> >
> >> >  *Maybe gracefully falling back to mode 0.
> >> >
> >> > As I'm on x11/nvidia-driver, completely no test is done with
> >> > drm-next.
> >> >
> >> > One more to mention.
> >> > I've cherry-picked r330868, r331241 and r331361 on stable/11 after
> >> > r331114, amd64 and works OK as on head.
> >> > Additional cherry-picking of r331365 is OK, too.
> >> >
> >> > Without r330868, my ThinkPad silently reboots within about 10-60
> >> > minutes range, maybe by actual access to UEFI RS.
> >> > With r331241 without r331361 causes instant panic on loading efirt.ko.
> >> > So all 3 (4) revs should be MFC'ed together.
> >> >
> >> > Sorry for delay.
> >> >
> >> >
> >> > On Thu, 22 Mar 2018 10:34:33 -0500
> >> > Kyle Evans <kev...@freebsd.org> wrote:
> >> >
> >> > > On Thu, Mar 22, 2018 at 10:18 AM, Kyle Evans <kev...@freebsd.org>
> >> > > wrote:
> >> > > > On Thu, Mar 22, 2018 at 10:16 AM, Peter Lei <peter@ieee.org>
> >> > wrote:
> >> > > >> On 3/22/18 8:56 AM, Tomoaki AOKI wrote:
> >> > > >>> Hi.
> >> > > >>> For problem 2, try reverting r331241 alone.
> >> > > >>> This worked for my ThinkPad T420.
> >> > > >>
> >> > > >>
> >> > > >> I also hit this after updating to latest and was about to post
> when
> >> > > >> I
> >> > > >> saw this thread -
> >> > > >>
> >> > > >> I build efirt into the kernel and it's now doing a panic on boot.
> >> > > >> It
> >> > > >> appears to be due to this recent addition in dev/efidev/efirt.c
> by
> >> > r331241:
> >> > > >>
> >> > > >>> if (!efi_is_in_map(map, efihdr->memory_size /
> >> > efihdr->descriptor_size,
> >> > > >>> efihdr->descriptor_size,
> >> > > >>> (vm_offset_t)efi_runtime->rt_gettime))
> >> > {
> >> > > >>
> >> > > >> The faulting address is for "efi_runtime->rt_gettime" (and is
> still
> >> > > >> a
> >> > > >> phys addr here).
> >> > > >>
> >> > > >
> >> > > > The following patch [1] (I can't guarantee how long he'll keep it
> >> > > > available there) should fix this class of problems.
> >> > > >
> >> > > > [1] https://people.freebsd.org/~andrew/0001-Enter-into-the-
> >> > EFI-environment-before-check-the-GetT.patch
> >> > >
> >> > > Now committed as of r331361.
> >> > > ___
> >> > > freebsd-current@freebsd.org mailing list
> >> > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> >> &g

Re: Call for Testing: UEFI Changes

[Zaphod Beeblebrox]

I've booted that image on my zbook 15.  I show in the boot that I can
deliberately load efirt.ko ... and it doesn't help.  I also show that I can
"type blind" after the system boots ... so everything but the screen is
working.

In case you can't quite make it out, I hit right cursor twice (move to the
"live cd" choice) and hit enter.  Then I type "root" enter and then
"reboot" ...

https://youtu.be/tlmaVJ-3aq0

(The rock sound track is just free audio to mask a barking dog and a radio
in the background.)


On Sun, Apr 1, 2018 at 7:41 PM, David NewHamlet 
wrote:

> Fixed in: FreeBSD-12.0-CURRENT-amd64-20180329-r331740-disc1.iso
>
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176694
>
> On Mon, Apr 2, 2018 at 12:38 AM, Tomoaki AOKI 
> wrote:
>
> > Confirmed both loader (with boot1) part and efirt.ko part.
> > Working OK on my ThinkPad420 (with nvidia GPU) at r331864.
> >
> > No benefit (VGA resolution) but no new harm (no panic nor silent
> > reboot).
> >
> >  *Maybe gracefully falling back to mode 0.
> >
> > As I'm on x11/nvidia-driver, completely no test is done with
> > drm-next.
> >
> > One more to mention.
> > I've cherry-picked r330868, r331241 and r331361 on stable/11 after
> > r331114, amd64 and works OK as on head.
> > Additional cherry-picking of r331365 is OK, too.
> >
> > Without r330868, my ThinkPad silently reboots within about 10-60
> > minutes range, maybe by actual access to UEFI RS.
> > With r331241 without r331361 causes instant panic on loading efirt.ko.
> > So all 3 (4) revs should be MFC'ed together.
> >
> > Sorry for delay.
> >
> >
> > On Thu, 22 Mar 2018 10:34:33 -0500
> > Kyle Evans  wrote:
> >
> > > On Thu, Mar 22, 2018 at 10:18 AM, Kyle Evans 
> wrote:
> > > > On Thu, Mar 22, 2018 at 10:16 AM, Peter Lei 
> > wrote:
> > > >> On 3/22/18 8:56 AM, Tomoaki AOKI wrote:
> > > >>> Hi.
> > > >>> For problem 2, try reverting r331241 alone.
> > > >>> This worked for my ThinkPad T420.
> > > >>
> > > >>
> > > >> I also hit this after updating to latest and was about to post when
> I
> > > >> saw this thread -
> > > >>
> > > >> I build efirt into the kernel and it's now doing a panic on boot. It
> > > >> appears to be due to this recent addition in dev/efidev/efirt.c by
> > r331241:
> > > >>
> > > >>> if (!efi_is_in_map(map, efihdr->memory_size /
> > efihdr->descriptor_size,
> > > >>> efihdr->descriptor_size, (vm_offset_t)efi_runtime->rt_
> gettime))
> > {
> > > >>
> > > >> The faulting address is for "efi_runtime->rt_gettime" (and is still
> a
> > > >> phys addr here).
> > > >>
> > > >
> > > > The following patch [1] (I can't guarantee how long he'll keep it
> > > > available there) should fix this class of problems.
> > > >
> > > > [1] https://people.freebsd.org/~andrew/0001-Enter-into-the-
> > EFI-environment-before-check-the-GetT.patch
> > >
> > > Now committed as of r331361.
> > > ___
> > > 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"
> > >
> >
> >
> > --
> > Tomoaki AOKI
> > ___
> > 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"
> >
> ___
> 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"

Re: Intel CPU design flaw - FreeBSD affected?

[Zaphod Beeblebrox]

>From the information that was leaked by AMD claiming that their processors
didn't have the flaws, it would seem any OS in which the kernel occupies
the same address space as the userland would be vulnerable.  The AMD post
implied that Intel's speculative execution of code did not check the
validity of the operands before speculatively executing the code.  I
suppose the implication is that the security check "catches up" with the
speculative execution at some point ... and that their (AMD's) microcode
did check.

Anyways... for those keeping score at home, this is a privilege escalation
bug... so it's only really useful in concert with other bugs ... but still
pretty huge.

Some estimate that between 5% and 30% performance degradation may be
unavoidable.  Some say it's worse or can't be fully fixed.

Certainly, the sunk cost of current CPUs is a huge issue for server farm
vendors like Amazon and/or google.

On Tue, Jan 2, 2018 at 6:13 PM, Michael Butler 
wrote:

> Has any impact assessment been made as to FreeBSD's exposure or
> mitigation strategies?
>
> 'Kernel memory leaking' Intel processor design flaw forces Linux,
> Windows redesign - The Register
>
> https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
>
>
___
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: Trying to read linux-lvm on 11.0-RC2 using geom, bhyve, fail.

[Zaphod Beeblebrox]

On Fri, Sep 16, 2016 at 1:06 AM, Allan Jude <allanj...@freebsd.org> wrote:

> 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
>
> I get where you're going here, but it doesn't apply because at this point
> I'm not even booting from ada1.
>
___
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: Trying to read linux-lvm on 11.0-RC2 using geom, bhyve, fail.

[Zaphod Beeblebrox]

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

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

[Zaphod Beeblebrox]

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"

Re: HEADS UP: Merging projects/bhyve_svm to HEAD

[Zaphod Beeblebrox]

I would be using such a patch as soon as it was available.  On a friend's
advice, I upgraded a ZFS server here at home with an AMD 9590 and 32Gig of
RAM.  I'd dearly like to use it to track down the netgraph bug (see my
other recent posts), but it doesn't currently qualify.

On Sat, Oct 25, 2014 at 8:20 PM, Neel Natu neeln...@gmail.com wrote:

 Hi,

 On Sat, Oct 25, 2014 at 3:50 PM, Zaphod Beeblebrox zbee...@gmail.com
 wrote:
  I tried to integrate this patch into 10.1_RC3 and I failed.  Is there a
  timeframe to MFC this to 10.1 or 10-STABLE?
 

 It will be MFCed to 10-STABLE but I don't have a specific time frame in
 mind.

 I'll guess that it'll be towards the end of November but can be
 accelerated if someone has a need for this in 10-STABLE sooner.

 best
 Neel

  On Sun, Oct 19, 2014 at 4:04 PM, Benjamin Perrault 
 ben.perra...@gmail.com
  wrote:
 
  After a few days of extensive testing and abuse, i’ve run into no new
  issues or unknowns what so ever. Everything that worked before still
 works
  now ( and a few bugs from fixed from HEAD ).
 
  Thus, I have gone ahead and pushed r273182 w/ Neel’s patch out to about
 80
  of the assorted AMD boxes in the production and dev pods that I care
 for. If
  end users see something, I’ll let you know, but I have a feeling they
 won’t.
 
  Again - Excellent work.
 
  cheers,
  -bp
 
   On Oct 19, 2014, at 5:03 AM, Willem Jan Withagen w...@digiware.nl
   wrote:
  
   On 16-10-2014 5:00, Anish Gupta wrote:
   Hi all,
  
   The projects/bhyve_svm branch is ready to be merged to HEAD.
  
   This branch contains patches to bhyve to enable it to work on AMD
   processors with SVM/AMD-V hardware extensions[1]. Pretty much any AMD
   processor since 2010 will have the features required by bhyve.
  
   bhyve on AMD supports (almost) all the features available with Intel
   [2]. All guest OSes supported on Intel are supported on AMD. All the
   bhyve-related utilities function similarly on both Intel and AMD
   platforms [3].
  
   The patch against HEAD revision 273066 is available for review and
   testing:
   https://people.freebsd.org/~neel/bhyve/bhyve_svm.diff [Neel’s web
   directory]
  
   [1]: http://en.wikipedia.org/wiki/X86_virtualization
   [2]: bhyve doesn't support PCI passthru on AMD at this time
   [3]: bhyvectl has grown some processor-specific options
  
   Fetched the patch and compiled.
   Now running: HEAD r273066M and I was able to throw at it all the tests
   and images that in the past works. And perhaps even better.
  
   Great work.
   --WjW
  
  
   ___
   freebsd-virtualizat...@freebsd.org mailing list
   http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
   To unsubscribe, send any mail to
   freebsd-virtualization-unsubscr...@freebsd.org
 
  ___
  freebsd-current@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-current
  To unsubscribe, send any mail to 
 freebsd-current-unsubscr...@freebsd.org
 
 

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

Re: HEADS UP: Merging projects/bhyve_svm to HEAD

[Zaphod Beeblebrox]

I tried to integrate this patch into 10.1_RC3 and I failed.  Is there a
timeframe to MFC this to 10.1 or 10-STABLE?

On Sun, Oct 19, 2014 at 4:04 PM, Benjamin Perrault ben.perra...@gmail.com
wrote:

 After a few days of extensive testing and abuse, i’ve run into no new
 issues or unknowns what so ever. Everything that worked before still works
 now ( and a few bugs from fixed from HEAD ).

 Thus, I have gone ahead and pushed r273182 w/ Neel’s patch out to about 80
 of the assorted AMD boxes in the production and dev pods that I care for.
 If end users see something, I’ll let you know, but I have a feeling they
 won’t.

 Again - Excellent work.

 cheers,
 -bp

  On Oct 19, 2014, at 5:03 AM, Willem Jan Withagen w...@digiware.nl
 wrote:
 
  On 16-10-2014 5:00, Anish Gupta wrote:
  Hi all,
 
  The projects/bhyve_svm branch is ready to be merged to HEAD.
 
  This branch contains patches to bhyve to enable it to work on AMD
  processors with SVM/AMD-V hardware extensions[1]. Pretty much any AMD
  processor since 2010 will have the features required by bhyve.
 
  bhyve on AMD supports (almost) all the features available with Intel
  [2]. All guest OSes supported on Intel are supported on AMD. All the
  bhyve-related utilities function similarly on both Intel and AMD
  platforms [3].
 
  The patch against HEAD revision 273066 is available for review and
 testing:
  https://people.freebsd.org/~neel/bhyve/bhyve_svm.diff [Neel’s web
 directory]
 
  [1]: http://en.wikipedia.org/wiki/X86_virtualization
  [2]: bhyve doesn't support PCI passthru on AMD at this time
  [3]: bhyvectl has grown some processor-specific options
 
  Fetched the patch and compiled.
  Now running: HEAD r273066M and I was able to throw at it all the tests
  and images that in the past works. And perhaps even better.
 
  Great work.
  --WjW
 
 
  ___
  freebsd-virtualizat...@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
  To unsubscribe, send any mail to 
 freebsd-virtualization-unsubscr...@freebsd.org

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

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

iSCSI boot ... root?

[Zaphod Beeblebrox]

Is it now possible to boot from iSCSI?  I'm not talking about an iSCSI
controller, but with

pxe - dhcp - tftp (loads loader) - (something) - boot (mounts root from
iSCSI)

... now I recall getting stuck on both something and boot last time.
AFAICR, loader doesn't understand iSCSI ... so if your ethernet card
doesn't make something look like a BIOS disk, you're sunk there.  Obviously
the kernel can handle nfs and the loader can handle nfs or tftp, but it's
expected that the root is the same root that you're accessing at the
something point.

I was going to try to work around something when I realized that the
previous iSCSI control stuff wouldn't allow boot parameters to be passed in
any logical way, so I gave up.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: No UDP/TCP IPv6 connectivity (only) to router using gif interface - maybe ARM related

[Zaphod Beeblebrox]

Whether you feel it right, or not, net.inet.ip.forwarding must be 1 for gif
to work (even for IPv6).


On Mon, Sep 2, 2013 at 2:42 AM, Martin Laabs mailingli...@martinlaabs.dewrote:

 Hi,

 I tried to set up my raspberry PI as an ipv6 router. As a tunnel broker I
 use sixxs. Now I observed an interesting behavior:

 Every host from my network can reach the ipv6 world. The ipv6 world can
 also reach every host in my network. However - the router itself is unable
 to make udp or tcp connection to the world and is also unable to accept
 connections form the world
 ICMP however works properly.
 I had a look to the tcpdump and when trying to connect i.e. to
 www.kame.net
 the rasperry router sends a syn packet and get a syn/ack packet back. The
 rest of the handshake is missing.
 I tried also some udp with netcat (nc -6 -u -l  on the server and nc -6
 -u server  on the client)
 This works great for internal (ethernet) traffic but when the data should
 go through the tunnel if fails.

 The last test is maybe the most significant to describe the bug:

 Start netcat to listen for UDP packages on an external host:

 external host nc -6 -u -l 

 Connect from the RPI-Router to that host

 RPI nc -6 -u 2001:4dd0::::2 

 Now it is possible to send data from the RPI router to the external host
 but the opposite direction does not work. Tcpdump however shows that the
 udp package arrives but it is not forwarded to the application.
 So for me it seems to be a problem with the handling of the receiving data
 in the gif interface.

 This behavior is independent from net.inet6.ip6.forwarding or
 net.inet6.ip6.redirect status.

 The router system: FreeBSD raspberry-pi.xxx 10.0-CURRENT FreeBSD
 10.0-CURRENT #2 r254984

 Best regards,
  Martin Laabs

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

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

Re: No SD card Reader support

[Zaphod Beeblebrox]

On Tue, Jul 2, 2013 at 9:24 PM, Mike C. miguelmcl...@gmail.com wrote:

 On 07/03/13 00:18, John Hixson wrote:
  On Wed, Jul 03, 2013 at 01:16:19AM +, Mike C. wrote:
 
  According to the windows drivers info on Acer's page, my laptop internal
  SD card reader vendor is Realtek.
 
  I'm not being able to use the card reader but I'm not sure how to debug
  this...
 
  I see nothing in dmesg related to the sh card reader, when inserting a
  SDHC card or a SD card I see nothing...
 
  usbconfig show's this:


[deleted]


  mmc_load=YES
  mmcsd_load=YES
  sdhci_load=YES
  sdhci_pci_load=YES


  Do you have these modules loaded?

 I don't have the last, in any case:
 kldload: can't load sdhci_pci: File exists

 I do have the other lines in /boot/loader.conf


What he's getting at there is that you should look at the output of pciconf
-lv (not usb) for the card reader.  The PCI devices are different animals
than the USB ones.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: copyin+copyout in one step ?

[Zaphod Beeblebrox]

On Mon, May 27, 2013 at 7:38 PM, Luigi Rizzo ri...@iet.unipi.it wrote:


 say a process P1 wants to use the kernel to copy the content of a
 buffer SRC (in its user address space) to a buffer DST (in the
 address space of another process P2), and assume that P1 issues the
 request to the kernel when P2 has already told the kernel where the
 data should go:


Urm... Isn't the use of shared memory the more obvious way to transfer data
between processes?  Am I missing some nuance?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Audio Hints, T520? [restating the problem]

[Zaphod Beeblebrox]

On Mon, May 6, 2013 at 11:27 AM, Sean Bruno sean_br...@yahoo.com wrote:


 Using a 4 position (combined headphone/mic) head set with the T520 and
 *no* device hints WORKS for recording and playback.

 Its the onboard microphone that is not working for me.  No device hints
 provided in this thread have solved the onboard mic issue.  Audio
 playback through the laptop speakers works just fine.


This would be a question for the hardware hacks among us ... is this one of
the onboard microphones that isn't?  By that I mean ... one where it uses
the existing builtin speakers and some fancy DSP work to construct a
microphone?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: multi-homing in freebsd

[Zaphod Beeblebrox]

On Sat, Mar 9, 2013 at 2:55 AM, Yasir hussan kolya...@gmail.com wrote:


 Does anyone know usage of multi-homing in freebsd, if YES kindly guid me
 how i can test it on my own PC.


This question seems almost so simple as to be a trick question.  By
definition, put two ethernet cards in your FreeBSD computer, give each
different IP addresses and connectivity to different networks ... and
congratulations: you're multi-homed.

By definition, any FreeBSD router is multihomed.  My BGP core router (which
is FreeBSD) is multihomed and has no default route... but that's really
just bragging :)

Maybe you need to ask a better question.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: multi-homing in freebsd

[Zaphod Beeblebrox]

On Sat, Mar 9, 2013 at 3:04 AM, Yasir hussan kolya...@gmail.com wrote:

 i just want to run multiple IPs for single network card in freebsd


OK.  A better question.  About the only caution I can give here (assuming
you don't mean something more interesting like vlans and whatnot) is that
if both IP addresses are on the SAME network, use a /32 as the netmask (it
works better).  If they are on different networks, specify the netmask as
normal.

You may, at this point,  need a method to choose which IP address to use
for any particular connection.  There's a pile of documentation waiting for
you.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: multi-homing in freebsd

[Zaphod Beeblebrox]

On Sat, Mar 9, 2013 at 8:57 AM, Yasir hussan kolya...@gmail.com wrote:

 i want to have differnet ips`s and each should have different interface,
 it could be a virtual interface. like u can made it like

 *ifconfig arge0.1 create*

 but each ip should able to access from differnet machine


This is linux-specific.  We don't create sub interfaces.  If you want the
equivalent on FreeBSD, you would just:

ifconfig arge0 192.168.0.1/24
ifconfig arge0 192.168.1.1/24 alias

... and so on for as many addresses as you require.  Replace alias with
delete to remove an alias from an interface (including the first one).
In retrospect, it might be good for us to harmonize the meanings there...


 On Sat, Mar 9, 2013 at 7:29 AM, Daniel Nebdal dneb...@gmail.com wrote:

 Going by Zaphod's recommendation of using a /32 for each IP, how about
 this?

 ifconfig arge0 inet 192.168.1.100/32
 ifconfig arge0 alias 192.169.1.100/32


Nope, you miss an important point.  If you were going to add
192.168.0.[123] you might:

ifconfig em0 192.168.0.1/24
ifconfig em0 192.168.0.2/32 alias
ifconfig em0 192.168.0.3/32 alias

... these three addresses are on the _same_ network.  In your example
above, you would require the correct netmask for each network _unless_ you
did something like the following:

ifconfig em0 192.168.1.1/15
ifconfig em0 192.168.1.100/32 alias
ifconfig em0 192.169.1.100/32 alias

... ie: you're in effect saying the network goes from 192.168.1.0 to
192.169.255.255.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org