On Fri, Jan 08, 2016 at 10:42:33AM -0500, Kurt Lidl wrote:
> I recently updated a sparc64 V120 from r291993
> to r293243, and it now traps during the
> autoconfiguration phase of the kernel boot:
>
<...>
> -- data access exception sfar=0xfcf821ca0218 sfsr=0x41029
> %o7=0xc06165e8 --
What
On 08/01/16 15:42, Kurt Lidl wrote:
> I recently updated a sparc64 V120 from r291993
> to r293243, and it now traps during the
> autoconfiguration phase of the kernel boot:
>
> Hit [Enter] to boot immediately, or any other key for command prompt.
> Booting [/boot/kernel/kernel]...
> jumping to
On 1/8/16, 9:05 AM, "David Wolfskill" wrote:
>After the first panic, I rebuilt the kernel without -DNO_CLEAN; the
>crash dump & other diagnostic info is from the clean build.
>
>January 8, 2016 at 05:57:27 AM PST
>
>FreeBSD
On Fri, Jan 08, 2016 at 09:34:23AM -0500, Jonathan T. Looney wrote:
J> The likely suspect here looks like r293405, which changed uipc_send() to
J> use sbappendstream_locked() instead of sbappend_locked().
J>
J> However, I can't explain *why* that change is causing this problem without
J> further
On 1/8/16 1:58 PM, Marius Strobl wrote:
On Fri, Jan 08, 2016 at 10:42:33AM -0500, Kurt Lidl wrote:
I recently updated a sparc64 V120 from r291993
to r293243, and it now traps during the
autoconfiguration phase of the kernel boot:
<...>
-- data access exception sfar=0xfcf821ca0218
Does your i210 now work with the reverted version of igb? I didn't get a
chance to follow up on this earlier.
Also, can you give us the device ID for the device? There are a couple
versions of the i210 hardware.
- Eric
On Sun, Oct 4, 2015 at 10:23 PM O. Hartmann
On 1/8/16 11:57 AM, Mark Cave-Ayland wrote:
On 08/01/16 15:42, Kurt Lidl wrote:
I recently updated a sparc64 V120 from r291993
to r293243, and it now traps during the
autoconfiguration phase of the kernel boot:
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting
On Fri, Jan 08, 2016 at 04:57:58PM +, Mark Cave-Ayland wrote:
> On 08/01/16 15:42, Kurt Lidl wrote:
>
> This looks amazingly similar to what I get trying to boot FreeBSD under
> QEMU, i.e. pointing at sched_clock():
>
<...>
> -- kernel stack fault %o7=0xc011a050 --
> panic: longjmp botch
>
It shouldn't have changed though; you're just requesting memory to use
for x86bios calls.
+jhb - any ideas?
-a
On 8 January 2016 at 20:53, Cy Schubert wrote:
> Cy Schubert writes:
>> In message <201601080107.u0817kdw078...@slippy.cwsent.com>, Cy Schubert
>> writes:
In message <201601080107.u0817kdw078...@slippy.cwsent.com>, Cy Schubert
writes:
> In message om>
> , Adrian Chadd writes:
> > Ok,
> >
> > So try adding this check:
> >
> > vmbuf = x86bios_alloc(, sizeof(*buf), M_WAITOK);
> > if
Cy Schubert writes:
> In message <201601080107.u0817kdw078...@slippy.cwsent.com>, Cy Schubert
> writes:
> > In message c
> > om>
> > , Adrian Chadd writes:
> > > Ok,
> > >
> > > So try adding this check:
> > >
> > > vmbuf =
After the first panic, I rebuilt the kernel without -DNO_CLEAN; the
crash dump & other diagnostic info is from the clean build.
January 8, 2016 at 05:57:27 AM PST
FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD 11.0-CURRENT #1954
r293419M/293420:1100093: Fri Jan 8 05:09:57 PST 2016
On Fri, Jan 08, 2016 at 06:05:18AM -0800, David Wolfskill wrote:
> After the first panic, I rebuilt the kernel without -DNO_CLEAN; the
> crash dump & other diagnostic info is from the clean build.
>
> January 8, 2016 at 05:57:27 AM PST
>
> FreeBSD freebeast.catwhisker.org 11.0-CURRENT FreeBSD
On Fri, Jan 08, 2016 at 06:33:40AM -0800, David Wolfskill wrote:
> ...
> > panic: sbappendstream 1
> >
>
> flo@ suggested reverting r293405; after doing that & rebuilding the
> kernel, the build machine boots to multi-user mode and I'm able to
> login:
>
> FreeBSD freebeast.catwhisker.org
David,
problem confirmed. Will either fix today, or revert the change
by the end of the day.
On Fri, Jan 08, 2016 at 06:05:18AM -0800, David Wolfskill wrote:
D> After the first panic, I rebuilt the kernel without -DNO_CLEAN; the
D> crash dump & other diagnostic info is from the clean build.
I recently updated a sparc64 V120 from r291993
to r293243, and it now traps during the
autoconfiguration phase of the kernel boot:
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
jumping to kernel entry at 0xc00b.
GDB: no debug ports
On Wed, Jan 06, 2016 at 01:24:53PM -0500, Shawn Webb wrote:
S> That's what gets toggled via the sysctl. I think I figured out that I
S> need to call ip_initid() in the SYSINIT. Compiling and testing now.
Right, that's the problem. You actually want VNET_SYSINIT().
Please next time you report a
17 matches
Mail list logo