|Summary:||reiserfs blocked for more than 120secs|
|Product:||File System||Reporter:||Rafael J. Wysocki (rjw)|
|Component:||ReiserFS||Assignee:||Jeff Mahoney (jeffm)|
|Bug Depends on:|
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 <email@example.com> 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 <firstname.lastname@example.org> > > 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 22.214.171.124 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.