Updating src tree:
P src/doc/3RDPARTY
P src/external/public-domain/sqlite/dist/sqlite3.c
P src/sys/arch/amd64/amd64/locore.S
P src/sys/arch/arm/omap/files.omap2
P src/sys/arch/arm/omap/omap3_sdhc.c
P src/sys/arch/arm/omap/omap3_sdmmcreg.h
P src/sys/arch/arm/omap/omap_edma.c
P src/sys/arch/arm/omap
On Mon, Jul 04, 2016 at 09:40:44AM +0200, Maxime Villard wrote:
> I didn't touch anything that is module-related.
Yes, I just saw you clarify comments on the module memory allocation
stuff recently, and the "out of range" was just a wild guess (which
turned out to be wrong).
Martin
Le 04/07/2016 à 08:51, Martin Husemann a écrit :
On Mon, Jul 04, 2016 at 09:53:21AM +0800, Paul Goyette wrote:
vapnic + 0x140
cd_play_msf +0x0
kauth_cred_geteuid + 0x50
There is something wrong here: kauth_cred_geteuid can't ever call cd_play_msf.
Maybe a bogus module loader fixup? Module VA
This is an automatically generated notice of a NetBSD-current/i386
build failure.
The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
using sources from CVS date 2016.07.04.06.48.14.
An extract from the build.sh output follows:
--- ns_netint.o ---
at/../stdlib -D__BUILD_LEG
Problem solved!
It seems that when Christos committed Charles Cui's GSoC code earlier,
it included an update to lwp.h with several new fields. Unfortunately,
the lwp structure is fairly critical to the operation of the OS, and
there are places where an lwp is passed from in-kernel code to cod
On Mon, Jul 04, 2016 at 03:14:51PM +0800, Paul Goyette wrote:
> So, cd_play_msf the same as the last+1 byte of kassert. :)
Heh, I see. So which of the three KASSERT is it?
Martin
On Mon, 4 Jul 2016, Martin Husemann wrote:
On Mon, Jul 04, 2016 at 09:53:21AM +0800, Paul Goyette wrote:
vapnic + 0x140
cd_play_msf +0x0
kauth_cred_geteuid + 0x50
There is something wrong here: kauth_cred_geteuid can't ever call
cd_play_msf.
Well, it's also unlikely for the return address
