Bug 13374 - reiserfs blocked for more than 120secs
reiserfs blocked for more than 120secs
Status: CLOSED UNREPRODUCIBLE
Product: File System
Classification: Unclassified
Component: ReiserFS
All Linux
: P1 normal
Assigned To: Jeff Mahoney
:
Depends on:
Blocks: 13070
  Show dependency treegraph
 
Reported: 2009-05-24 21:22 UTC by Rafael J. Wysocki
Modified: 2009-08-18 19:10 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.6.30-rc6
Tree: Mainline
Regression: Yes


Attachments

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.

Note You need to log in before you can comment on or make changes to this bug.