Re: Another twist on WRITE_DMA issues <- ProblemFound

In message <p06200751bddaace59ce2_at_[128.113.24.47]>, Garance A Drosihn writes:
>That isn't it either.  I think the hardware is just mocking me.  I
>had zero problems for more than 24 hours.  I then copied one set of
>partitions to another, booted up to that second set, and immediately
>I was back to having the above warnings/errors, and before long I
>had a system panic.  And when I try to 'call doadump()', that fails
>with an error writing to the disk, so I can't get a core dump of it
>either.

If you don't mind the risk of triggering some asserts, you could try
the patches in

	http://people.freebsd.org/~iedowse/callout/

to see if they make any difference. The aim of callout.diff is to
provide callouts with race-free semantics, and then callout_ata.diff
is an attempt to fix some timeout race conditions in the ATA driver
using the new API. The patches seem to have fixed the ATA timeout
messages I was getting after suspend/resume events, but it's a bit
early to tell for sure as I've only been using them on my laptop
now for a few days.

Depending on what drivers you use (especially ethernet), you may
get panics with those patches. This is because the patched callout
code requires that Giant is held while stopping and starting
non-mpsafe timers. It is safe to #if 0 out the new mtx_assert
conditions in kern_timeout.c for now as a workaround.

Ian