Hi Chris,
On Sun, Jul 7, 2013 at 11:42 PM, Chris Torek wrote:
> Here is a final (I hope) version of the patch. I dropped the
> config option, but I added code to limit the "real" size of the
> direct map PDEs. The end result is that on small systems, this
> ties up 14 more pages (15 from increa
On Wed, Jul 10, 2013 at 02:04:17PM -0600, asom...@gmail.com wrote:
> On Wed, Jul 10, 2013 at 12:57 PM, Jordan Hubbard
> wrote:
> >
> > On Jul 10, 2013, at 11:16 AM, Julian Elischer wrote:
> >
> >> My first candidates are:
> >
> > Those sound useful. Just out of curiosity, however, since we're
On 7/11/13 6:09 AM, Kevin Day wrote:
Those sound useful. Just out of curiosity, however, since we're on the topic
of kernel dumps: Has anyone even looked into the notion of an emergency
fall-back network stack to enable remote kernel panic (or system hang)
debugging, the way OS X lets you
So recently I was trying to transfer a root-on-ZFS zpool from one pair of
disks to a single, larger disk. As I am wont to do, I botched the transfer
up and decided to destroy the ZFS filesystems on the destination and start
again. Naturally I was up late working on this, being sloppy and drowsy
wit
"zpool export" does not wipe the transaction history. It does,
however, write new labels and some metadata, so there is a very slight
chance that it might overwrite some of the blocks that you're trying
to recover. But it's probably safe. An alternative, much more
complicated, solution would be
On Thu, Jul 11, 2013 at 9:04 AM, Alan Somers wrote:
> "zpool export" does not wipe the transaction history. It does,
> however, write new labels and some metadata, so there is a very slight
> chance that it might overwrite some of the blocks that you're trying
> to recover. But it's probably saf
Will,
Thanks, that makes sense. I know this is all a crap shoot, but I've really
got nothing to lose at this point, so this is just a good opportunity to
rummage around the internals of ZFS and learn a few things. I might even
get lucky and recover some data!
On Thu, Jul 11, 2013 at 10:59 AM, Wi
On Sunday, June 30, 2013 1:24:27 pm Robert Ames wrote:
> I just picked up an Intel D2500CCE motherboard and was disappointed
> to find the serial ports didn't work. There has been discussion
> about this problem here:
>
> http://lists.freebsd.org/pipermail/freebsd-current/2013-April/040897.html
>
On Sunday, July 07, 2013 7:41:43 am mangesh chitnis wrote:
> Hi,
>
> What is the memmap equivalent of Linux in FreeBSD?
>
> In Linux memmap is used to reserve a portion of physical memory. This is
used as a kernel boot argument. E.g.: memmap=2G$1G will reserve 1GB memory
above 2GB, incase I ha
> Speaking of Apple solutions, I've recently used Apple's kgdb with the
> kernel debug kit & kdp remote debugging, to debug a panic'd OS X host.
> It's really quite nice, because the debug kit comes with a ton of
> macros, similar to kdb, and you also get the benefit of source
> debugging. I thin
On Jul 11, 2013, at 7:27 AM, Julian Elischer wrote:
> I could imagine that we could stash away a vimage stack just for this purpose.
> yould set it up on boot and leave it detached until you need it.
>
> you just need to switch the interfaces over to the new stack on panic and put
> them into
On Thu, Jul 11, 2013 at 12:52 PM, Jordan K. Hubbard <
jordan.hubb...@gmail.com> wrote:
>
> On Jul 11, 2013, at 7:27 AM, Julian Elischer wrote:
>
> > I could imagine that we could stash away a vimage stack just for this
> purpose.
> > yould set it up on boot and leave it detached until you need it
On Jul 11, 2013, at 4:05 PM, Artem Belevich wrote:
>
> It would probably work for most of the crashes, but will not work in few
> interesting classes of failure. Using in-kernel stack implicitly assumes that
> your memory allocator still works as both the stack and the interface driver
> wil
Dears
I'm tryning to build cross-gcc with this command line
make TGTARCH=arm TGTABI=freebsd10
or
make TGTARCH=arm TGTABI=freebsd8
on a
FreeBSD squitch 8.4-RELEASE FreeBSD 8.4-RELEASE #27: Mon Jun 10 08:52:47
BRT 2013 ota@squitch:/usr/obj/usr/src/sys/SQUITCH i386
but all times I got
/
On Jul 11, 2013, at 2:05 PM, Artem Belevich wrote:
> It would probably work for most of the crashes, but will not work in few
> interesting classes of failure. Using in-kernel stack implicitly assumes
> that your memory allocator still works as both the stack and the interface
> driver will need
15 matches
Mail list logo
