Daniel O'Connor wrote:
On 06/08/2010, at 2:38, Oliver Fromme wrote:
I think this is the main reason / has had to grow - the actual kernel
is relatively small so even a 256Mb / could hold several, but with
the symbol files it is not possible.
I think a very simple solution
On 06/08/2010, at 16:59, Oliver Fromme wrote:
Yeah, I don't think it's hard to move them, however I'm worried what
it will break :)
The only thing I can see that would have to change would be kgdb so
it tells gdb where to find the symbols.
That's why I suggested to place symlinks in the
Daniel O'Connor wrote:
On 06/08/2010, at 16:59, Oliver Fromme wrote:
Yeah, I don't think it's hard to move them, however I'm worried what
it will break :)
The only thing I can see that would have to change would be kgdb so
it tells gdb where to find the symbols.
On Mon, Aug 2, 2010 at 4:27 PM, Dan Langille d...@langille.org wrote:
On 8/2/2010 7:11 PM, Dan Langille wrote:
I recently altered an existing raidz2 pool from using 7 vdevs of about
931G to 1.81TB. In fact, the existing pool used half of each HDD. I then
wanted to go to using [almost] all of
On Fri, Aug 06, 2010 at 09:29:31AM +0200, Oliver Fromme wrote:
Daniel O'Connor wrote:
On 06/08/2010, at 2:38, Oliver Fromme wrote:
I think this is the main reason / has had to grow - the actual kernel
is relatively small so even a 256Mb / could hold several, but with
the symbol
Kostik Belousov kostik...@gmail.com wrote:
If you keep /usr/obj around, you do not need symbol files at all,
and INSTALL_NODEBUG?=true in make.conf is enough. You can always
use kernel.debug and modules with debugging symbols from build
directory for kgdb.
OK ... But that won't work for
It's in V16 afaik
On Fri, Aug 6, 2010 at 11:36 AM, Freddie Cash fjwc...@gmail.com wrote:
On Mon, Aug 2, 2010 at 4:27 PM, Dan Langille d...@langille.org wrote:
On 8/2/2010 7:11 PM, Dan Langille wrote:
I recently altered an existing raidz2 pool from using 7 vdevs of about
931G to 1.81TB. In
If you have this adapter and have been getting watchdogs you need to pick up
the small
update I checked into HEAD today. When I added the SR-IOV support for the
82576
adapter I removed a call to set the MAC type in an early routine, thinking
it was unnecessary,
since a slightly later shared code
Hello Stable
I have an issue with a kernel panic on bootup where the dumpdev loader
variable is ignored.
I rebuilt my 6.4-STABLE amd64 kernel with the following options to try an track
down an issue with a patch.
options KDB
options DDB
options GDB
options BREAK_TO_DEBUGGER
options
On 08/06/2010 02:24 PM, Mark Saad wrote:
I then set in /boot/loader.conf
dumpdev=/dev/da0s1b
On 8-STABLE dumpdev should be defined in rc.conf(5). Not sure about
6-STABLE offhand.
--
Benjamin Lee
http://www.b1c1l1.com/
signature.asc
Description: OpenPGP digital signature
wrote:
I then set in /boot/loader.conf
dumpdev=/dev/da0s1b
On 8-STABLE dumpdev should be defined in rc.conf(5).
Not sure about
6-STABLE offhand.
The box dies before init is started so dumpdev in rc.conf is pointless.
--
Benjamin Lee
http://www.b1c1l1.com/
--
Mark
Mark Saad wrote:
wrote:
I then set in /boot/loader.conf
dumpdev=/dev/da0s1b
On 8-STABLE dumpdev should be defined in rc.conf(5).
Not sure about
6-STABLE offhand.
The box dies before init is started so dumpdev in rc.conf is pointless.
I'm afraid you can't
Mark Saad wrote:
wrote:
I then set in /boot/loader.conf
dumpdev=/dev/da0s1b
On 8-STABLE dumpdev should be defined in
rc.conf(5).
Not sure about
6-STABLE offhand.
The box dies before init is started so dumpdev in
rc.conf is pointless.
I'm
Mark,
Perhaps remote GDB via serial console...
http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-online-gdb.html
This explain it in very good detail.
~Paul
On Fri, Aug 06, 2010 at 06:37:37PM -0400, Mark Saad wrote:
Mark Saad wrote:
wrote:
I then set in
On Fri, Aug 06, 2010 at 03:37:37PM -0700, Mark Saad wrote:
Mark Saad wrote:
wrote:
I then set in /boot/loader.conf
dumpdev=/dev/da0s1b
On 8-STABLE dumpdev should be defined in rc.conf(5).
Not sure about
6-STABLE offhand.
The box dies before
Hello,
I'm experiencing slow write speeds on 8-STABLE running on an ESXI 4.0
server, despite whatever tunables I've thrown at it. Read speeds are slower
than they should be, but acceptable. Note, this is a thick provisioned disk,
not thin.
Speeds on Windows hosts are as expected for an MD3000
On 06/08/2010, at 17:45, Oliver Fromme wrote:
Daniel O'Connor wrote:
On 06/08/2010, at 16:59, Oliver Fromme wrote:
Yeah, I don't think it's hard to move them, however I'm worried what
it will break :)
The only thing I can see that would have to change would be kgdb so
it tells gdb where
17 matches
Mail list logo
