Martin Pieuchot wrote:
> Sure I can do that, I still want to add a comment since it might bite us
> later.
>
> So a counter diff is like an ok?
sure.
>> In that case could you print the trace of all the threads in the bind
>> process? In ddb it should be:
>> ddb{3}> tr /p 0t$tidofathread
>> I don't know a better way to find the tid than using "ps /w" beforehand.
ps /w
TID
411673 named
462825 named
263841 named
309002 named
*198978 named
On 23/01/17(Mon) 23:53, cheek...@gmx.com wrote:
> I tried Martin's first patch with a newly-cvsup source and have not
> been able to cause another crash after more than 20 reboots, and
> rebooting into the bsd.rd.
Good to know.
> I do still have the panicd vm console.
In that case could you
On Mon, Jan 23, 2017 at 08:42:07PM +1000, Martin Pieuchot wrote:
> On 17/01/17(Tue) 00:24, Alexander Bluhm wrote:
> > On Mon, Jan 16, 2017 at 08:36:46PM +0100, cheek...@gmx.com wrote:
> > > kernel: protection fault trap, code=0
> > > Stopped at fd_getfile+0x20: testb
I tried Martin's first patch with a newly-cvsup source and have not
been able to cause another crash after more than 20 reboots, and
rebooting into the bsd.rd.
I do still have the panicd vm console.
Is showing one of the isc bind named threads with thrsleep tell you anything?
ddb{3}> ps
PID
>On 23/01/17(Mon) 17:03, Ted Unangst wrote:
>> Martin Pieuchot wrote:
>> > On 17/01/17(Tue) 00:24, Alexander Bluhm wrote:
>> > > On Mon, Jan 16, 2017 at 08:36:46PM +0100, cheek...@gmx.com wrote:
>> > > > kernel: protection fault trap, code=0
>> > > > Stopped at fd_getfile+0x20: testb
On 23/01/17(Mon) 17:03, Ted Unangst wrote:
> Martin Pieuchot wrote:
> > On 17/01/17(Tue) 00:24, Alexander Bluhm wrote:
> > > On Mon, Jan 16, 2017 at 08:36:46PM +0100, cheek...@gmx.com wrote:
> > > > kernel: protection fault trap, code=0
> > > > Stopped at fd_getfile+0x20: testb
Martin Pieuchot wrote:
> On 17/01/17(Tue) 00:24, Alexander Bluhm wrote:
> > On Mon, Jan 16, 2017 at 08:36:46PM +0100, cheek...@gmx.com wrote:
> > > kernel: protection fault trap, code=0
> > > Stopped at fd_getfile+0x20: testb $0x2,mptramp_gdt32_desc+0x1e(%r
> > > ax)
> > > ddb{3}> fd_getfile() at
On 17/01/17(Tue) 00:24, Alexander Bluhm wrote:
> On Mon, Jan 16, 2017 at 08:36:46PM +0100, cheek...@gmx.com wrote:
> > kernel: protection fault trap, code=0
> > Stopped at fd_getfile+0x20: testb $0x2,mptramp_gdt32_desc+0x1e(%r
> > ax)
> > ddb{3}> fd_getfile() at fd_getfile+0x20
> > sys_fstat() at
On 17/01/17(Tue) 00:24, Alexander Bluhm wrote:
> On Mon, Jan 16, 2017 at 08:36:46PM +0100, cheek...@gmx.com wrote:
> > kernel: protection fault trap, code=0
> > Stopped at fd_getfile+0x20: testb $0x2,mptramp_gdt32_desc+0x1e(%r
> > ax)
> > ddb{3}> fd_getfile() at fd_getfile+0x20
> > sys_fstat() at
Alexander Bluhm wrote:
> On Mon, Jan 16, 2017 at 08:36:46PM +0100, cheek...@gmx.com wrote:
> > kernel: protection fault trap, code=0
> > Stopped at fd_getfile+0x20: testb $0x2,mptramp_gdt32_desc+0x1e(%r
> > ax)
> > ddb{3}> fd_getfile() at fd_getfile+0x20
> > sys_fstat() at sys_fstat+0x43
> >
> cheeky.m: How often does it crash? Can you test wether this fixes
> your problem?
It crashed after rebooting from the bsd.rd upgrade almost every time.
I built a new kernel with your patch and rebooted more than 15 times
from the bsd.rd, old kernel, and new kernel, and I have not seen the
On Mon, Jan 16, 2017 at 08:36:46PM +0100, cheek...@gmx.com wrote:
> kernel: protection fault trap, code=0
> Stopped at fd_getfile+0x20: testb $0x2,mptramp_gdt32_desc+0x1e(%r
> ax)
> ddb{3}> fd_getfile() at fd_getfile+0x20
> sys_fstat() at sys_fstat+0x43
> syscall() at syscall+0x27b
It crashes in
13 matches
Mail list logo
