10/01/02 21:10, Stephen Lord wrote:
> Pascal Haakmat wrote:
> >10/01/02 16:36, Steve Lord wrote:
> >>On Thu, 2002-01-10 at 15:57, Pascal Haakmat wrote:
> >>> ASSERT(ipointer_in == B_FALSE);
> >>> ip = ip->i_mnext;
> >>>c01ccb34: 8b 4c 24 70 mov 0x70(%esp,1),%ecx
> >>>c01ccb38: 8b 76 08 mov 0x8(%esi),%esi
> >>>c01ccb3b: 8b 91 14 01 00 00 mov 0x114(%ecx),%edx
> >>> } while (ip->i_mnext != mp->m_inodes);
> >>>[*ksymoops disassembly matches here*]
> >>ip->i_mnext is NULL which is never supposed to happen, next question is
> >FWIW, this happened just after rebooting using the XFS 1.01/RedHat boot CD
> >and running xfs_repair on the filesystem, which hopefully rules out an
> >inconsistent filesystem/filesystem errors.
> I don't think fs corruption would have much to do with this one, it is a
> purely in memory
> circular list. So far as I can see it is always manipulated under the
> correct locking. I have
> a box running a debug kernel sitting in a loop doing the test which
> Adrian says makes
> this happen for him. It has been going for a few hours, so far no problems.
Well, I've been doing the same, and after 68 iterations of his script I got
this pair of messages, repeating every three seconds or so (no Oops or
ide_dmaproc: chipset supported ide_dma_lostirq func only: 13
hdc: lost interrupt
Looks like a kernel problem or bad hardware?
> Would you be willing turn on kdb? It only really makes sense if you are
> able to setup
> a serial console. There is a debugger command which will walk the
> complete list of
> inodes in the filesystem.
The serial console won't happen, but I think it's no longer necessary
either. This is probably not an XFS bug, right?