On Sat, Nov 19, 2005 at 11:52:33PM -0800, Lawrence Walton wrote:
> This is the second report of this error.
Please CC linux-xfs if you want to be sure XFS people see your
> It's reproducible in 2.6.15-rc1, 2.6.15-rc1-mm1, 2.6.15-rc1-mm2 and
> It does not occur in 2.6.14.
> Most easily triggered by "make clean" in the Linux source, for those of
> you without access to dpkg. But both clean and dpkg will trigger it.
So far I've not been able to reproduce this; I'm using "make clean"
and it works just fine for me (I'm using the current git tree).
> There are no oops.
No, it looks like XFS is stuck waiting for an IO to complete.
> I'm not sure what to report next, though If I were to guess it is a
> interaction between XFS file system and SCSI. I've got another SCSI box
> that is very similar that runs rc1, rc1-mm1 and rc1-mm2 just fine, the
> only real difference being it has a ext3 file system instead.
> The driver for the SCSI card (aic7xxx) did not appear change.
> lspi says it's a Adaptec AIC-7892A U160/m (rev 2) card.
From your earlier report with the stack traces included, it looks
like XFS is waiting for a log write to complete, but it never
does (which is not valid driver behaviour). I'm using the sym53c8xx
driver in my testing BTW, which is different to you, so maybe see if
this still happens for you with different hardware? (if you can).
> Questions, patches, flames are welcome.
You could also try to drop the XFS (fs/xfs) code from 2.6.14 into
2.6.15-rc2 and see if your problem persists. There isn't anything
I can see from scanning though everything we committed into .15 so
far that would explain this. Oh, an easier test you could do would
be to try XFS CVS from oss.sgi.com - that has 2.6.14 + all the XFS
changes since then, so that should confirm/deny an XFS regression