Still working this problem I've previously mentioned on the list, and my
working theory now is a race between catchpacket() and this code in bpfread():
/*
* At this point, we know we have something in the hold slot.
*/
BPFD_UNLOCK(d);
/*
* Move
Still working this problem I've previously mentioned, and my working theory now
is a race between catchpacket() and this code in bpfread():
/*
* At this point, we know we have something in the hold slot.
*/
BPFD_UNLOCK(d);
/*
* Move data from ho
On Oct 17, 2012, at 8:58 AM, Guy Helmer wrote:
> On Oct 12, 2012, at 8:54 AM, Guy Helmer wrote:
>
>>
>> On Oct 10, 2012, at 1:37 PM, Alexander V. Chernikov
>> wrote:
>>
>>> On 10.10.2012 00:36, Guy Helmer wrote:
On Oct 8, 2012, at 8:09 AM, Guy Helmer wrote:
> I'm seein
On Oct 12, 2012, at 8:54 AM, Guy Helmer wrote:
>
> On Oct 10, 2012, at 1:37 PM, Alexander V. Chernikov
> wrote:
>
>> On 10.10.2012 00:36, Guy Helmer wrote:
>>>
>>> On Oct 8, 2012, at 8:09 AM, Guy Helmer wrote:
>>>
I'm seeing a consistent new kernel panic in FreeBSD 8.3:
I'm not s
On Oct 10, 2012, at 1:37 PM, Alexander V. Chernikov
wrote:
> On 10.10.2012 00:36, Guy Helmer wrote:
>>
>> On Oct 8, 2012, at 8:09 AM, Guy Helmer wrote:
>>
>>> I'm seeing a consistent new kernel panic in FreeBSD 8.3:
>>> I'm not seeing how bd_sbuf would be NULL here. Any ideas?
>>
>> Since I
On 10.10.2012 00:36, Guy Helmer wrote:
On Oct 8, 2012, at 8:09 AM, Guy Helmer wrote:
I'm seeing a consistent new kernel panic in FreeBSD 8.3:
I'm not seeing how bd_sbuf would be NULL here. Any ideas?
Since I've not had any replies, I hope nobody minds if I reply with more
information.
Thi
On Oct 8, 2012, at 8:09 AM, Guy Helmer wrote:
> I'm seeing a consistent new kernel panic in FreeBSD 8.3:
>
> #0 doadump () at pcpu.h:224
> 224 __asm("movq %%gs:0,%0" : "=r" (td));
> (kgdb) #0 doadump () at pcpu.h:224
> #1 0x804c82e0 in boot (howto=260) at
> ../../../kern/k
