Wonderful, Mike. I just rebuilt kernels and am running some largish jobs
and everything seems to be surviving. Thanks for turning around a fix so
quickly!

On Tue, Jun 6, 2017 at 5:26 PM, Mike Belopuhov <m...@belopuhov.com> wrote:

> Hi,
>
> I've checked in a slightly amended version of the diff.
>
> Regards,
> Mike
>
> On Sat, Jun 03, 2017 at 19:03 +0200, Mike Belopuhov wrote:
> > Hi Dan,
> >
> > That's good news, thanks for testing!  I've updated the diff
> > slightly.  Unfortunately I couldn't figure out what's causing
> > "boot dump" to crash.  I've exercised coredump, physio and
> > read-ahead codepaths.  I'll commit the diff next week unless
> > there's going to be reports of some breakage.
> >
> > The diff is available from the same location as previously:
> > http://gir.theapt.org/~mike/xbf.diff
> >
> > Thanks for testing!
> >
> > On 27 May 2017 at 03:33, Dan Cross <cro...@gmail.com> wrote:
> >
> > > Thanks for this latest patch; it seems to help. At least, I was able to
> > > put a fairly significant amount of load on the machine with out a
> panic.
> > > I'll try and load it up more and see where we get, but so far this is
> > > positive.
> > >
> > > On Wed, May 24, 2017 at 7:37 PM, Mike Belopuhov <m...@belopuhov.com>
> > > wrote:
> > >
> > >> On Wed, May 24, 2017 at 12:27 -0400, Dan Cross wrote:
> > >> > Thanks for the patch; I just got a few minutes today and I applied
> it,
> > >> > rebuilt and installed the kernel and rebooted. Sadly, I get a
> similar
> > >> > panic. Attached is a screenshot of console output. Note that, 'boot
> > >> sync'
> > >> > from ddb hangs forever.
> > >> >
> > >> >         - Dan C.
> > >>
> > >> That's OK. I've discovered more problems related to 64k transfers.
> > >> The reason why we didn't notice anything bad when aborting sleep
> > >> was because sleep has a small memory footprint, but if you dump
> > >> core of a larger (> 64k) program, you'd notice the issue because
> > >> core dump routine like some other places in the kernel assumes
> > >> that 64k transfers always work.
> > >>
> > >> I've attempted to attack this problem from a different angle:
> > >> ensure that xbf(4) can handle 64k transfers.  Solutions to this
> > >> problem are notoriously messy and complicated and so far this
> > >> one is no exception. Today I got to the point where the system
> > >> boots multiuser but couldn't test further. I've noticed however
> > >> that "boot dump" from ddb still crashes so I know it's not 100%
> > >> right just yet, but since I won't get around doing anything
> > >> about this until early next week, I'd appreciate a quick test
> > >> if possible.
> > >>
> > >> I'm not attaching the diff since it's rather large:
> > >>
> > >> http://gir.theapt.org/~mike/xbf.diff
> > >>
> > >> Cheers,
> > >> Mike
> > >>
> > >
> > >
>

Reply via email to