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
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 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
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 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
> 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 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
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
>
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 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
"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
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
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
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
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
15 matches
Mail list logo
