Date: Thu, 11 Jul 2013 23:18:08 -0700 From: Hubbard Jordan <jordan.hubbard@gmail.com> To: Artem Belevich <art@freebsd.org> Cc: hackers@freebsd.org, Kevin Day <toasty@dragondata.com> Subject: Re: Kernel dumps [was Re: possible changes from Panzura] Message-ID: <90871AB4-6615-4571-A0F6-B605141497FA@gmail.com> In-Reply-To: <CAFqOu6j299gbsWh22fTnbKZUFZBVuwwV6M5bcJdH%2Bm%2BCWDin9g@mail.gmail.com> References: <FDEEB55D-823B-4899-8EEC-7F5306D91F5B@elischer.org> <9890DFF1-892A-4DCA-9E33-B70681154F43@mail.turbofuzz.com> <4F0DFAB7-D6D5-4068-A543-C9DF885D1A7D@dragondata.com> <51DEC0E8.7010305@freebsd.org> <EC032F13-AF97-4A1D-8772-02EF92613DA7@turbofuzz.com> <CAFqOu6j299gbsWh22fTnbKZUFZBVuwwV6M5bcJdH%2Bm%2BCWDin9g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 11, 2013, at 2:05 PM, Artem Belevich <art@freebsd.org> 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 to get their mbufs and other data somewhere. Alas = it's > those unusual cases that are hardest to debug and where you really do = want > debugger or coredump to work. This is all true, though I think Julian was also suggesting that this = "fall-back vimage" would be somehow preallocated, perhaps not from the = kernel allocator pool, ahead of time. The mbufs needed for it a = "connection time" would also presumably come from a special pool, though = I don't know how much conditional logic in the existing stack would be = necessary to make sure it didn't try to allocate any data from the = generic allocator. It might indeed be easier to simply bake-in a much simpler, UDP-only = stack and polled device driver combo. - Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?90871AB4-6615-4571-A0F6-B605141497FA>