Bug 13374
| Summary: | reiserfs blocked for more than 120secs | ||
|---|---|---|---|
| Product: | File System | Reporter: | Rafael J. Wysocki (rjw) |
| Component: | ReiserFS | Assignee: | 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
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 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. (posted same question to the mail thread after noticing that neither of the involved people have bko accounts) 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.
Closing as "unreproducible". 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.
|