Bug 13374

Summary: reiserfs blocked for more than 120secs
Product: File System Reporter: Rafael J. Wysocki (rjw)
Component: ReiserFSAssignee: Jeff Mahoney (jeffm)
Status: CLOSED UNREPRODUCIBLE    
Severity: normal CC: jeffm
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.30-rc6 Subsystem:
Regression: Yes Bisected commit-id:
Bug Depends on:    
Bug Blocks: 13070    

Description Rafael J. Wysocki 2009-05-24 21:22:31 UTC
Subject    : 2.6.30-rc6: reiserfs blocked for more than 120secs
Submitter  : Harald Dunkel <harald.dunkel@t-online.de>
Date       : 2009-05-23 8:52
References : http://marc.info/?l=linux-kernel&m=124306880410811&w=4

This entry is being used for tracking a regression from 2.6.29.  Please don't
close it until the problem is fixed in the mainline.
Comment 1 Rafael J. Wysocki 2009-06-01 20:35:12 UTC
On Sunday 31 May 2009, Frederic Weisbecker wrote:
> On Sat, May 30, 2009 at 09:37:36PM +0200, Rafael J. Wysocki wrote:
> > This message has been generated automatically as a part of a report
> > of recent regressions.
> > 
> > The following bug entry is on the current list of known regressions
> > from 2.6.29.  Please verify if it still should be listed and let me know
> > (either way).
> > 
> > 
> > Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=13374
> > Subject             : reiserfs blocked for more than 120secs
> > Submitter   : Harald Dunkel <harald.dunkel@t-online.de>
> > Date                : 2009-05-23 8:52 (8 days old)
> > References  : http://marc.info/?l=linux-kernel&m=124306880410811&w=4
> > 
> 
> Trenton D. Adams has reported something very similar for -rc3:
> 
> http://lkml.org/lkml/2009/5/29/389
> 
> Someone holds the j_commit_mutex but never release it...

References : http://lkml.org/lkml/2009/5/29/389
Comment 2 Jeff Mahoney 2009-06-05 18:25:47 UTC
Can you capture a sysrq+t when this is occuring? The lock is properly released, but I have a hunch that another thread is waiting on ordered writeback.
Comment 3 Jeff Mahoney 2009-06-05 18:30:02 UTC
(posted same question to the mail thread after noticing that neither of the involved people have bko accounts)
Comment 4 Rafael J. Wysocki 2009-08-12 21:11:51 UTC
On Wednesday 12 August 2009, Harald Dunkel wrote:
> Rafael J. Wysocki wrote:
> > 
> > Please let us know either way.
> > 
> 
> I am running 2.6.31-rc5 for amd64 on 2 systems. By now I haven't
> seen this problem on the new kernel yet, but since I saw it only
> once for an older kernel I cannot say whether it is really gone.
Comment 5 Rafael J. Wysocki 2009-08-12 21:12:37 UTC
Closing as "unreproducible".
Comment 6 Rafael J. Wysocki 2009-08-18 19:10:54 UTC
On Tuesday 18 August 2009, Harald Dunkel wrote:
> Hi Rafael,
> 
> I haven't seen the 120secs timeout yet, but using 2.6.31-rc5 there _are_
> some delays that I am not sure of. Sometimes it takes about 30 secs till
> the XWindow server comes up, for example. (I use xinit on the command line
> at login. / and /home are both reiserfs.) For 2.6.30.4 and older I haven't
> seen this delay yet, AFAIR.
> 
> Most recent event: I tried to format a 4 GByte USB stick with reiserfs.
> Here is the screen output:
> 
>       # device=/dev/sdf
>       # parted $device mklabel gpt
>       Warning: The existing disk label on /dev/sdf will be destroyed and
>       all data on this disk will be lost. Do you want to continue?
>       Yes/No? Yes
>       Information: You may need to update /etc/fstab.
> 
>       # parted -- $device mkpart primary 0s -1s
>       Warning: You requested a partition from 0.00B to 4127MB.
>       The closest location we can manage is 17.4kB to 4127MB.
>       Is this still acceptable to you?
>       Yes/No? Yes
>       Information: You may need to update /etc/fstab.
> 
>       # mkreiserfs -l usbstick /dev/sdf1
>       mkreiserfs 3.6.21 (2009 www.namesys.com)
>       :
>       :
>       UUID: 154d66cc-02ac-4979-9a39-163e3cf80623
>       LABEL: usbstick
>       ATTENTION: YOU SHOULD REBOOT AFTER FDISK!
>               ALL DATA WILL BE LOST ON '/dev/sdf1'!
>       Continue (y/n):y
>       Initializing journal - 0%....20%....40%....60%....80%....100%
>       Syncing..ok
>       ReiserFS is successfully created on /dev/sdf1.
> 
> It took about 2 to 3 minutes till the "ok" in the "Syncing" line
> was shown. /var/log/messages was silent. When I tried to reproduce
> the delay it was gone, of course.