xfs
[Top] [All Lists]

REASSIGN 799238 - RAM disk driver breaks locking hierarchy

To: dxm@xxxxxxxxxxxx
Subject: REASSIGN 799238 - RAM disk driver breaks locking hierarchy
From: pv@xxxxxxxxxxxxx (dxm@xxxxxxxxxxxx)
Date: Thu, 17 Aug 2000 15:51:55 -0700 (PDT)
Cc: linux-xfs@xxxxxxxxxxx
Reply-to: sgi.bugs.xfs@xxxxxxxxxxxxxxxxx
Sender: owner-linux-xfs@xxxxxxxxxxx
Webexec: webpvupdate,pvincident
Webpv: clouds.melbourne.sgi.com
View Incident: 
http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=799238

 Status : open                         Priority : 2                         
*Assigned Engineer : dxm              *Assigned Domain : engr               
 Submitter : dxm                       Project : xfs-linux                  
 Assigned Group : xfs-linux            Opened Date : 08/15/00               
*Modified User : dxm                  *Modified User Domain : engr          
*Description :
OK, so this one is repeatable now, and it looks like an
interraction between the ramdisk driver and XFS.

        2 way SMP 1400 with 1Gb memory, 
        SCSI disk. 
        t-o-t kernel, kio _not_ enabled.
        
setup:

        mkfs -t xfs -f /dev/sdc5

.....


==========================
ADDITIONAL INFORMATION (REASSIGN)
From: dxm@engr (BugWorks)
Date: Aug 17 2000 03:51:54PM
==========================


 => XFS is not really part of the problem here, it is just triggering lots of
 => I/O.

That's just about where I got to yesterday. At first I was assuming it
was at fault, then I thought involved, now I suspect it's just a catalyst.

 => There appears to be a deadlock between the lru_list_lock and the
 => io_request_lock.

Under the circumstances, it's probably the ramdisk. I'll chase 
this up with some relevant Linux people...

<Prev in Thread] Current Thread [Next in Thread>
  • REASSIGN 799238 - RAM disk driver breaks locking hierarchy, dxm@xxxxxxxxxxxx <=