On 8/5/2014 10:19 PM, Konstantin Belousov wrote:
On Tue, Aug 05, 2014 at 09:47:57PM -0500, Bryan Drewery wrote:
Has anyone else encountered this? Got it while running poudriere.
NULL mp in getnewvnode()
[...]
vn_fullpath1() at vn_fullpath1+0x19d/frame 0xfe1247d8e540
vn_fullpath() at vn_ful
On Aug 5, 2014, at 2:29 PM, Michael Butler wrote:
> On 08/05/14 16:56, Michael Butler wrote:
>> On 08/05/14 16:02, John Baldwin wrote:
>>
>>> My guess is that the recent Xen changes tickled something.
>>
>> I can confirm this on a kernel which is otherwise up to date ..
>>
>> FreeBSD toshi.au
On Tue, Aug 05, 2014 at 09:47:57PM -0500, Bryan Drewery wrote:
> Has anyone else encountered this? Got it while running poudriere.
>
> > NULL mp in getnewvnode()
> > [...]
> > vn_fullpath1() at vn_fullpath1+0x19d/frame 0xfe1247d8e540
> > vn_fullpath() at vn_fullpath+0xc1/frame 0xfe1247d8e5
On 8/5/2014 9:47 PM, Bryan Drewery wrote:
Has anyone else encountered this? Got it while running poudriere.
NULL mp in getnewvnode()
[...]
vn_fullpath1() at vn_fullpath1+0x19d/frame 0xfe1247d8e540
vn_fullpath() at vn_fullpath+0xc1/frame 0xfe1247d8e590
export_fd_to_sb() at export_fd_to_s
Has anyone else encountered this? Got it while running poudriere.
NULL mp in getnewvnode()
[...]
vn_fullpath1() at vn_fullpath1+0x19d/frame 0xfe1247d8e540
vn_fullpath() at vn_fullpath+0xc1/frame 0xfe1247d8e590
export_fd_to_sb() at export_fd_to_sb+0x489/frame 0xfe1247d8e7c0
kern_proc_
Kernels with r269580 will panic when loading the radeonkms driver in
pmap_page_set_memattr(). This probably indicates a bug in radeonkms, but
the system is unusable in the meantime.
-Nathan
___
freebsd-current@freebsd.org mailing list
http://lists.free
On 08/05/14 16:56, Michael Butler wrote:
> On 08/05/14 16:02, John Baldwin wrote:
>
>> My guess is that the recent Xen changes tickled something.
>
> I can confirm this on a kernel which is otherwise up to date ..
>
> FreeBSD toshi.auburn.protected-networks.net 11.0-CURRENT FreeBSD
> 11.0-CURREN
On 08/05/14 16:02, John Baldwin wrote:
> My guess is that the recent Xen changes tickled something.
I can confirm this on a kernel which is otherwise up to date ..
FreeBSD toshi.auburn.protected-networks.net 11.0-CURRENT FreeBSD
11.0-CURRENT #2 r269608M: Tue Aug 5 16:48:12 EDT 2014
I backed ou
On 08/05/14 16:02, John Baldwin wrote:
>> Given that my build machine did not exhibit the symptoms, and given the
>> references to atpic, it may be relevant to point out that the machine
>> where I see the panic is a Dell Precision M4400 laptop.
>
> My guess is that the recent Xen changes tickled
On Tue, Aug 05, 2014 at 01:02:25PM -0700, John Baldwin wrote:
...
> My guess is that the recent Xen changes tickled something. However, can you
> capture a verbose dmesg from your working kernel?
That was my current hunch, as well.
I've attached /var/run/dmesg.boot from a verbose boot running:
On Aug 5, 2014, at 7:29 AM, David Wolfskill wrote:
> On Mon, Aug 04, 2014 at 12:47:59PM -0700, David Wolfskill wrote:
>> ...
>> I was unable to get a crash dump, and I only recorded the offsets in the
>> backtrace (no arguments; sorry -- I was expecting the build machine to
>> allow me to invest
On Mon, Aug 04, 2014 at 12:47:59PM -0700, David Wolfskill wrote:
> ...
> I was unable to get a crash dump, and I only recorded the offsets in the
> backtrace (no arguments; sorry -- I was expecting the build machine to
> allow me to investigate on a machine with a serial console):
>
> ...
> SMP: A
On Aug 4, 2014, at 1:07 PM, Michael Tuexen wrote:
> Author: tuexen
> Date: Mon Aug 4 20:07:35 2014
> New Revision: 269527
> URL: http://svnweb.freebsd.org/changeset/base/269527
>
> Log:
> Add support for the SCTP_RECONFIG_SUPPORTED and the corresponding
> sysctl controlling the negotiation of
13 matches
Mail list logo
