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 <[email protected]> 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 >
