> > I use the built-in snapshot capability of dump(8), with the -X option:
> >
> > dump -0au -h 0 -X -f- ${fs} | gzip -9 > $outfile
> Thanks, I wasn't aware of that. I'll see if changes anything.
It just completed one entire dump this way with no crash.
That hadn't happened in 6 days.
> Perhaps you can get it to provide a backtrace rather than just simply
> rebooting?
I'd love to, but how? The machine is set to drop into ddb on panic, but
doesn't, or this isn't a panic.
> I use the built-in snapshot capability of dump(8), with the -X option:
>
> dump -0au -h 0 -X -f-
Timo Buhrmester wrote:
> It happens while dump(8)ing an in-filesystem fss(4)-snapshot of an empty-ish
> FFSv1 (fslevel 4) filesystem sitting on a raid(4)-1 with two components.
I also experience unfrequent crashes with that exact setup. I think it
appeared when I added
On Fri, 11 Mar 2016, Timo Buhrmester wrote:
My 7-stable/amd64 server crashes nearly every night while my backup
routine is in progress. There's no backtrace and no crash dump is saved,
but the console reads:
ohci1: 1 scheduling overruns
ohci1: WARNING: addr 0x01cf not found
ohci1:
My 7-stable/amd64 server crashes nearly every night while my backup
routine is in progress. There's no backtrace and no crash dump is saved,
but the console reads:
> ohci1: 1 scheduling overruns
> ohci1: WARNING: addr 0x01cf not found
> ohci1: WARNING: addr 0x012c not found
> ohci1: