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 > > >> > > > > > > >