Hi
Recent 8-CURRENT
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x14
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc05f7251
stack pointer = 0x28:0xc4a8db8c
frame pointer = 0x28:0xc4a8dc24
code segment
On 13 Mar 2009, at 01:54, Sean C. Farley wrote:
Here is a patch[1] that will allow the MTU to be set higher than
1500 on a tap(4) interface. I ran into the need to do this when I
had em0 set to 9000 and tried to bridge em0 with tap0 (MTU 1500) for
QEMU. A bridge interface will not allow
Hi
Recent 8-CURRENT
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x14
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc05f7251
stack pointer = 0x28:0xc4a8db8c
frame pointer = 0x28:0xc4a8dc24
code segment
On Thu, 12 Mar 2009, Richard Tector wrote:
Robert Watson wrote:
On Tue, 10 Mar 2009, Richard Tector wrote:
Just a me too on 7.1-STABLE amd64 (as of 2009-03-05 at least). Note this
does not happen with a 7.1-RELEASE kernel, so I'm assuming it's not
userland.
This problem is believed fixed a
On Fri, 13 Mar 2009, Rui Paulo wrote:
On 13 Mar 2009, at 01:54, Sean C. Farley wrote:
Here is a patch[1] that will allow the MTU to be set higher than 1500
on a tap(4) interface. I ran into the need to do this when I had em0
set to 9000 and tried to bridge em0 with tap0 (MTU 1500) for QEMU.
The following reply was made to PR kern/122252; it has been noted by GNATS.
From: Robert Healey
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/122252: [ipmi] [bge] IPMI problem with BCM5704 (does not
work after driver loaded)
Date: Fri, 13 Mar 2009 11:33:41 -0400
I am having a similar is
Sean C. Farley wrote:
Yes, this fixes my issue with bridging a tap device to an interface
with an MTU higher than 1500.
I will probably commit this patch this weekend.
I can't think of any reason why not, other than you might want to ensure
that tap's MTU is bounded within reasonable limits
Thanks for this report. Sam has reported wihat I believe is the same issue.
I haven't had a chance to look at this yet, I'm absolutely exhausted
from working on some
other stuff that had to happen right away.
___
freebsd-net@freebsd.org mailing list
ht
On Fri, 13 Mar 2009, Bruce Simpson wrote:
Sean C. Farley wrote:
Yes, this fixes my issue with bridging a tap device to an interface
with an MTU higher than 1500. I will probably commit this patch this
weekend.
I can't think of any reason why not, other than you might want to
ensure that
Sean C. Farley wrote:
...
Exhausting the jumbo cluster pool refers to kern.ipc.nmbjumbo[p|9|16],
yes? em(4) has an upper limit of 16114 for MTU. I could limit the
MTU to TAPMRU (16384) which is the limit for a write to the driver
anyway.
Just waiting for my VFS cache to spool up after a fres
All I have in the kit box is what appears to be a Belkin branded Ralink
cardbus card.
I think it's a Ralikn 25xx.
I have a PCI-Cardbus bridge, so I'm going to leave a NanoBSD image of
SVN HEAD
to cook in the background whilst I sort out my humanity...
__
11 matches
Mail list logo
