panic: vm_fault: fault on nofault entry, addr: fffffe00873d8000

I got the following panic while trying to import a ZFS pool from a geli-encrypted memory disk backed by a file located on a msdosfs partition: (kgdb) where #0 doadump (textdump=0) at pcpu.h:221 #1 0x80314c1b in db_dump (dummy=, dummy2=false, dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_

urtwn regression(?) from 10.2 to current r291431

I posted this about a week ago: http://lists.freebsd.org/pipermail/freebsd-current/2015-November/058683.html The problem is that urtwn stopped working in current r291431. I did more testing with the same revision, and sometimes it would work, but extremely slowly, and sometimes seemingly associa

Re: urtwn regression(?) from 10.2 to current r291431

On 12/06/15 15:14, Anton Shterenlikht wrote: I posted this about a week ago: http://lists.freebsd.org/pipermail/freebsd-current/2015-November/058683.html The problem is that urtwn stopped working in current r291431. I did more testing with the same revision, and sometimes it would work, but ex

Re: urtwn regression(?) from 10.2 to current r291431

>From h...@selasky.org Sun Dec 6 14:41:27 2015 > >On 12/06/15 15:14, Anton Shterenlikht wrote: >> I posted this about a week ago: >> >> http://lists.freebsd.org/pipermail/freebsd-current/2015-November/058683.html >> >> The problem is that urtwn stopped >> working in current r291431. >> >> I did mo

Re: urtwn regression(?) from 10.2 to current r291431

i pulled the recent RPI2 r291495 from ftp.freebsd.org, and i also notice that the urtwn usb dongle i typically use is very flakey with -CURRENT on the Raspberry Pi 2. The symptoms sound very similar to those described on this thread. : mdm > On Dec 6, 2015, at 6:44 AM, Anton Shterenlikht wrote

11.0-CURRENT SRC_ENV_CONF file vs. MAKEOBJDIRPREFIX in the file: they do not mix

After successfully using the likes of: env MAKEOBJDIRPREFIX=. . . make . . . from the usual /usr/src starting point. I tried following: > The environment of make(1) for the build can be controlled via the > SRC_ENV_CONF variable, which defaults to /etc/src-env.conf. Some > examples

Re: panic: vm_fault: fault on nofault entry, addr: fffffe00873d8000

On Sun, Dec 06, 2015 at 11:45:32AM +0100, Fabian Keil wrote: > I got the following panic while trying to import a ZFS pool from a > geli-encrypted memory disk backed by a file located on a msdosfs partition: I smiled. > > (kgdb) where > #0 doadump (textdump=0) at pcpu.h:221 > #1 0x80314

Re: urtwn regression(?) from 10.2 to current r291431

hiya, +wireless, +andriy Andriy has been working on adding lots of new things to urtwn and tidying it up. It's possible he's introduced some regressions. Just check in on the wireless list and join #freebsd-wireless on efnet to ask questions. Hopefully it was fixed a couple days ago with the TX

11.0-CURRENT (on powerpc64) WITH_CCACHE_BUILD= : example failure

Mostly just an FYI: This means that for my own purposes I'll tend to avoid WITH_CCACHE_BUILD= for now. . . Context vintage: > # freebsd-version -ku; uname -aKU > 11.0-CURRENT > 11.0-CURRENT > FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #17 r291745M: Sat Dec 5 > 08:20:20 PST 2015 >

Re: panic: vm_fault: fault on nofault entry, addr: fffffe00873d8000

Konstantin Belousov wrote: > On Sun, Dec 06, 2015 at 11:45:32AM +0100, Fabian Keil wrote: > > I got the following panic while trying to import a ZFS pool from a > > geli-encrypted memory disk backed by a file located on a msdosfs partition: > > > I smiled. I occasionally use this somewhat non

Re: panic: vm_fault: fault on nofault entry, addr: fffffe00873d8000

On Sun, Dec 06, 2015 at 06:51:36PM +0100, Fabian Keil wrote: > > > #16 0x80877d5a in bcopy () at > > > /usr/src/sys/amd64/amd64/support.S:118 > > > #17 0x805f64e8 in uiomove_faultflag (cp=, > > > n=, uio=0xfe009444aae0, nofault= > > out>) at /usr/src/sys/kern/subr_uio.c:208 >

Re: 11.0-CURRENT (on powerpc64) WITH_CCACHE_BUILD= : example failure

I'm adding a note about the missing "\" being just an E-mail editing error, not an original command error. . . On 2015-Dec-6, at 8:32 AM, Mark Millard wrote: > Mostly just an FYI: This means that for my own purposes I'll tend to avoid > WITH_CCACHE_BUILD= for now. . . > > Context vintage: >

powerpc64-gcc 5.2 vintages get L". . ." type wrong compared to Char for FreeBSD for lib32 compiling

[I picked the lists that I did because powerpc64-gcc is the external toolchain created to allow modern powerpc64 builds.] For the powerpc64-gcc 5.2 vintages. . . (using my environment's path as an example) /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/gcc-5.2.0/gcc/config/rs6000/freebsd

Re: powerpc64-gcc 5.2 vintages get L". . ." type wrong compared to Char for FreeBSD for lib32 compiling

On 06.12.15 22:34, Mark Millard wrote: [I picked the lists that I did because powerpc64-gcc is the external toolchain created to allow modern powerpc64 builds.] For the powerpc64-gcc 5.2 vintages. . . (using my environment's path as an example) /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/w

seems to be solved in r291907: WAS: Re: urtwn regression(?) from 10.2 to current r291431

>From mexas Sun Dec 6 14:44:25 2015 >To: adr...@freebsd.org, freebsd-current@freebsd.org, >freebsd-sta...@freebsd.org, h...@selasky.org, me...@bris.ac.uk >Subject: Re: urtwn regression(?) from 10.2 to current r291431 >Reply-To: me...@bris.ac.uk >In-Reply-To: <5664472e.3090...@selasky.org> > >>