@Luke, you're probably right, if even a single rm can freeze the system.
I guess some data is always being moved around... When the bug is
fixed, I'll see if I still get freezes.
--
Soft lockups (freezes) when deleting files from ext4 partitions on 2.6.28
https://bugs.launchpad.net/bugs/330824
This problem definitely IS NOT LIMITED to deletion, as most comments
seem to indicate.
First I only had it sometimes when emptying my trash (with a few roughly
1GB files), but after a reboot the trash was empty, so it seems that the
freeze occurred after syncing the disk / completing the
You are correct. I have this problem when my newsreader program MOVES
data from the temporary folder to the download folder.
--
Soft lockups (freezes) when deleting files from ext4 partitions on 2.6.28
https://bugs.launchpad.net/bugs/330824
You received this bug notification because you are a
I think it also happens when resizing files. For instance I get lockups
when running a VM and the disk image changes in size.
I don't know why this is marked as 'importance = medium', since it
renders the system useless.
--
Soft lockups (freezes) when deleting files from ext4 partitions on
Perhaps the VM is growing the image by using temp files?
I noticed lockup on checking out a clean subversion tree, which should
only have involved file creation.
Oh well, changing kernels is a decent workaround.
--
Soft lockups (freezes) when deleting files from ext4 partitions on 2.6.28
@loannis
Probably because ext4 is optional file system. I believe it is noted in
Release Notes for Jaunty that ext4 has been calling problems...it's not
like people are forced to use it.
--
Soft lockups (freezes) when deleting files from ext4 partitions on 2.6.28
@Derek
it probably does create some temporary files in there process, deleting them
shortly after.
@bcrook
good point. That's the price of living on the edge...
I'm a bit stuck here. Karmic has not yet decided what to do with the
'restricted' modules (I have an Nvidia gfx), thus I'm left with
loannis, just install a 2.6.30 kernel. I've been running an rc of 2.6.30 on
jaunty for months now with nvidia, works fine. DKMS will take care of the
restricted modules as necessary.
--
Soft lockups (freezes) when deleting files from ext4 partitions on 2.6.28
yes, thanks Carey
In my case, I had to apply a patch to the default nvidia 96.43.10
source. There is a patch for the 180.44 driver that you can find here:
http://www.nvnews.net/vbulletin/showthread.php?t=131597
I've attached a version made for the 96.43.10 module (actually, I didn't
try out the
FWIW,
on different PCs (desktop and laptop ) where I installed Jaunty + ext4 I'm
having these hangs,
I can trigger them reliably with the hang.py script...
--
Soft lockups (freezes) when deleting files from ext4 partitions on 2.6.28
https://bugs.launchpad.net/bugs/330824
You received this
** Changed in: linux (Ubuntu Karmic)
Status: In Progress = Fix Released
--
Soft lockups (freezes) when deleting files from ext4 partitions on 2.6.28
https://bugs.launchpad.net/bugs/330824
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
So this is probably not terribly helpful, but I'd like to add that like
the person in a duplicate bug (#34312), I also experience lockups
seemingly at random (I'll sit down at my computer which has been idle
for awhile and find everything frozen and the caps lock key flashing).
I'm running Jaunty
@iamringo: I got other frequent random lockups also with the stock
kernels (both 2.6.28-11 and -12), possibly related to ext4 (I suspect
the mlocate update was causing some). But I've not had a single one in
four weeks using the 2.6.30 vanilla kernels and they've been very
stable. IMO it's
@Rocko: just switched, and everything seems fine. I can run hang.py w/o
a problem, and I've got a hunch there won't be any random freezes
anymore. Given this bug report, I've been meaning to switch kernels, but
only just got around to itThanks!
--
Soft lockups (freezes) when deleting files
@Theodore Ts'o
Just run bonnie++. It works for me all the time.
--
Soft lockups (freezes) when deleting files from ext4 partitions on 2.6.28
https://bugs.launchpad.net/bugs/330824
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
I can't duplicate this under karmic's 2.6.30-generic (-4, -5 or -6), I
don't think karmic suffers from this issue.
--
Soft lockups (freezes) when deleting files from ext4 partitions on 2.6.28
https://bugs.launchpad.net/bugs/330824
You received this bug notification because you are a member of
Sorry for not checking in sooner, I've been swamped with upstream issues
with ext4, and this is pretty clearly an Ubuntu specific bug. Maybe
later this weekend I'll have time to try to figure out which ones of the
Ubuntu-backported patches is responsible for the problem.
However, I wanted to
I cannot reproduce the hang with a karmic kernel ( 2.6.30-6-generic ) on
the same machine that can easily reproduce it with a Jaunty kernel (
2.6.28-11-generic ).
--
Soft lockups (freezes) when deleting files from ext4 partitions on 2.6.28
https://bugs.launchpad.net/bugs/330824
You received this
Theodore Ts'o : No 2.6.30-6-generic kernel does not have this bug, this
is only in jaunty. BTW, did you look my last comment, I was giving you
the information you needed concerning which commits cause this bug.
--
Soft lockups (freezes) when deleting files from ext4 partitions on 2.6.28
It's not related to gvfs because I'm having it in KDE too.
--
Soft lockups (freezes) when deleting files from ext4 partitions on 2.6.28
https://bugs.launchpad.net/bugs/330824
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
Maybe I am wrong : so take it just as a suggestion,
Maybe the bug is in gvfs
or Maybe it is a conflict between gvfs and ext4
--
Soft lockups (freezes) when deleting files from ext4 partitions on 2.6.28
https://bugs.launchpad.net/bugs/330824
You received this bug notification because you are a
Theodore Ts'o : As I'm not a expert with git, my previous results were
wrong because I tested the master branch of
git://github.com/tytso/ext4.git instead of the ubuntu-330824-test
branch (shame on me). So I cloned your current git repository, checkout
to branch ubuntu-330824-test, then checkout
Theodore Ts'o : I found that there is not 10 but 9 ubuntu SAUCE commits
in your branch. commit 18fde579ee7e5895a802e9e04a38c26f4c0ed351 is the
one I identified being the bad one earlier. For each 8 others, I built
the kernel with the specific SAUCE patch reverted and tested if the bug
was
I can confirm this.
The easiest way to reproduce it is to run bonnie++ without options on an
ext4 device. It freezes the system every time for me on a laptop and in
a virtual machine.
--
Soft lockups (freezes) when deleting files from ext4 partitions on 2.6.28
Saïvann,
Thanks for your willingness to work on this.
However the good news is that I'm ready to take a lot more time on this. If it
requires me to
git bisect again the whole jaunty kernel and to apply commit dbf8b1c4 each
time I test one
commit, I'm ready to do it. If you can only guide me
Theodore Ts'o : That's excellent, I'm going to start bisecting today.
Thanks!
--
Soft lockups (freezes) when deleting files from ext4 partitions on 2.6.28
https://bugs.launchpad.net/bugs/330824
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Also installed http://kernel.ubuntu.com/~kernel-
ppa/mainline/v2.6.30-rc4/. No freezes so far. At last I can work with my
workstation.
@Derek - THANK YOU for the post!
--
Soft lockups (freezes) when deleting files from ext4 partitions on 2.6.28
https://bugs.launchpad.net/bugs/330824
You
Just increasing the counter of people affected. I have faced system
freeze 4 times since I upgraded my file system to ext4. luckily my /
fs is not on ext4.
--
Soft lockups (freezes) when deleting files from ext4 partitions on 2.6.28
https://bugs.launchpad.net/bugs/330824
You received this bug
This issue is *not* fixed in current jaunty.
Deleting files will not freeze your machine at once or so often anymore.
But it still happens once a day approximately 1-3 seconds after the deleting is
done, system just freezes.
--
Soft lockups (freezes) when deleting files from ext4 partitions on
On Sun, May 03, 2009 at 01:32:13PM -, _dan_ wrote:
This issue is *not* fixed in current jaunty.
No, it is not fixed in Jaunty, as the status of the bug indicates. In
Progress means that someone is working on the bug, but it is not yet fixed.
Fortunately, it looks like we now have a very
@Tim Gardner on 2009-04-30:
@Derek - that patch is already in Jaunty.
static void ext4_mb_add_n_trim(struct ext4_allocation_context *ac)
...
list_for_each_entry_rcu(tmp_pa, lg-lg_prealloc_list[order],
pa_inode_list) {
** Description changed:
+ [
+ Please read *all* previous comments before posting.
+
+ Mainline kernels are known to not experience this bug, although in
+ general are not supported (i.e., using one is a workaround, but if they
+ break other things you're generally out of luck).
+
+ Additional
@Ted - Pauli's observation is correct. I was comparing Jaunty against
2.6.28.9 fs/ext4/mballoc.c. They are indeed the same wrt the code in
ext4_mb_add_n_trim(). However, Linus' tree has commit
e7c9e3e99adf6c49c5d593a51375916acc039d1e which was Cc sta...@kernel.org,
and corrects the spin_unlock()
Test kernels in http:/kernel.ubuntu.com/~rtg/2.6.28-13.44-lp330824
contain stable updates through 2.6.28.10 as well as the aforementioned
missing commit e7c9e3e99adf6c49c5d593a51375916acc039d1e from Linus'
tree.
--
Soft lockups (freezes) when deleting files from ext4 partitions on 2.6.28
@Tim:
I would be delighted if commit e7c9e3e9 fixes this bug. However, this
fix was added after 2.6.29 was released (it was pushed to Linus between
during the 2.6.29..2.6.29-rc1 merge window), and Ubuntu users have
reported that using the 2.6.29 stock kernel was enough to avoid the rm
-rf hang
The bug can be reproduced with Tim Gardner test kernels
http://kernel.ubuntu.com/~rtg/2.6.28-13.44-lp330824
--
Soft lockups (freezes) when deleting files from ext4 partitions on 2.6.28
https://bugs.launchpad.net/bugs/330824
You received this bug notification because you are a member of Ubuntu
@Tim, Theo:
2.6.28-13.44 from http://kernel.ubuntu.com/~rtg/2.6.28-13.44-lp330824
hung partway through boot with BUG: soft locking - CPU#0 stuck for
61s! [rmdir:]
--
Soft lockups (freezes) when deleting files from ext4 partitions on 2.6.28
https://bugs.launchpad.net/bugs/330824
You
Saïvann,
Thank you very much for doing the bisect and confirming Carey's results.
The problem with this is that the commit that you figured as causing the
problem, dbf8b1c4, is identical to commit 82eb4869, which appeared in
2.6.28.7, and commit 920313a7, which appeared in 2.6.29-rc1, and so was
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Confirming the 2.6.28-13.44 kernel from Tim Gardner still has the problem.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
Confirm that 2.6.28-11.42 had the problem. I was able to reproduce the
issue 5 or more times by issuing 'rm -fr dirname' on an 80gb directory
hierarchy of files up to 5gb each. The system soft locked just like the
reported bug symptoms. Booting 2.6.30-020630rc4 resolves the issue for
me and 'rm
Theodore :
I built and tested your branch : git://github.com/tytso/ext4.git and the
bad news is : no crash. I was able to delete my whole filesystem and the
problem was not reproducible when it always takes 2 seconds for the bug
to appear.
However the good news is that I'm ready to take a lot
According to last Theodore Ts'o comment, I am bisecting ubuntu-jaunty
git branch and the result so far are very positive. If everything goes
well, I will be able to reveal exactly which commit caused the bug in a
few. 65 commit left to test. 4 good commits identified, 2 bad commits
identified. The
My git bisect is finished and revealed that commit
dbf8b1c4e8122e705447b69aea9ee6ef3a9caa30 is the faulty one, confirming
Carey Underwood previous results. Bisect log attached and commit diff
attached.
Trying to revert that whole patch in current jaunty kernel makes it
FTBFS so I could not test
** Attachment added: dbf8b1c4e8122e705447b69aea9ee6ef3a9caa30
http://launchpadlibrarian.net/26269859/dbf8b1c4e8122e705447b69aea9ee6ef3a9caa30
--
Soft lockups (freezes) when deleting files from ext4 partitions on 2.6.28
https://bugs.launchpad.net/bugs/330824
You received this bug
I've switched to:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.30-rc4/ (and previously rc3)
So far, so good, on both machines using ext4, despite still plenty of rm
-rf.
here's hoping...
--
Soft lockups (freezes) when deleting files from ext4 partitions on 2.6.28
I also just triggered a crash using the hang.py script from this forum. I just
just switched to ext4 and had to try.
I have two observations someone might find useful.
1) Running as normal user. Ran hang.py and it locked up on the 5th
round. I had to push the reset button. Note that
I think I am bitten by this, too, on AMD64, with a root fs converted
from ext3 to ext4 using
tune2fs -O extents,uninit_bg,dir_index /dev/DEV
linux-image-2. 2.6.28-11.42
I have not found a way yet to trigger, rm -rf on ten thousand files
once did not.
On an irregular basis I can see any app
Just found this report after a number of forced reboots, Chiming in with
another verification.
Running Stock Jaunty: 2.6.28-11-generic (bui...@palmer) (gcc version
4.3.3 (Ubuntu 4.3.3-5ubuntu4) ) #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC
2009
Have a 3TB 4-drive software RAID-5 array with EXT4.
Phil,
The only suggestion I can make at this point is to use a mainline
kernel. This seems to be some kind of interaction between Ubuntu
Sauce patches and the ext4 code. People have reported success with
stock 2.6.28, stock 2.6.29 and a bleeding-edge 2.6.30-rcX kernels.
There have been attempts
A bit more info on my circumstance.
1) I triggered the lockup at one point by running Evolution - no idea what it
was doing in the background
2) I was trying to figure out why subversion was giving me an assertion on a
particular samba mounted file:// repo.
(this has been going on for a while,
I can always get a lock with Back-In-Time (http://backintime.le-
web.org/), which uses rsync.
If try to to backup my home dir (ext4 formatted) to another drive (ext4
formated) during the initial snapshot generation it locks up everytime.
I'm using jaunty with 2.6.28-11-generic.
--
Soft lockups
I have this bug too after I've updated from Ubuntu 8.10 to Ubuntu 9.04.
Here are more info:
- I have relatively small filesystems (30 GB and 80 GB), converted by hand to
ext4
- My kernel version is Linux 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17
01:57:59 UTC 2009 i686 GNU/Linux
- I have an
Hey guys.
Just wondering.
This recent ext4 fix looks hopeful (typo correction).
http://patchwork.kernel.org/patch/19495/
Found while been browsing for potential fixes in ext4.
Does anyone know if it is in a Jaunty backport?
--
Soft lockups (freezes) when deleting files from ext4 partitions on
@Derek - that patch is already in Jaunty.
static void ext4_mb_add_n_trim(struct ext4_allocation_context *ac)
...
list_for_each_entry_rcu(tmp_pa, lg-lg_prealloc_list[order],
pa_inode_list) {
spin_lock(tmp_pa-pa_lock);
Repeatedly triggered trying an rm -rf of a subversion tree.
Intel driver. I guess I'll subscribe and await developments.
A workaround for me was to do following:
find ~/svn/trunk -type f | while read f;do rm -f $f;sleep .1;done
find ~/svn/trunk -depth -type d | while read d;do rmdir $d;sleep
this bug works with final jaunty 2.6.28-11-generic on an amd athlon,
installed hardy which was updated by hand to intrepid which updated to
jaunty, with no gnome nor x server. ext3 filesystem converted to ext4 by
hand, 250gb pata hdd one partition, no swap.
i can reproduce this bug any time with
to be accurate replace 'file' to 'directory', sorry. i would like to
delete more than 13 files because i copied all my data within the
hdd to use extents
--
Soft lockups (freezes) when deleting files from ext4 partitions on 2.6.28
https://bugs.launchpad.net/bugs/330824
You received this bug
I got a kernel panic just now (ie the PC froze completely) and managed
to capture a whole bunch of general protection faults and the panic with
netconsole. The PC actually froze when I opened a new tab in Firefox
rather than when I went to delete a number of files, but there are a
number of ext4
Rocko,
Thanks for your kernel panic log. This doesn't prove anything, but 14
seconds before the oops involving ext4_delete_inode, there was a
recursive fault in the X server, which was apparently running the Nvidia
proproietary driver.
So I hate to ask this but (a) how many other people who
I don't use proprietary software on my system, so Nvidia driver shouldn't
cause this lockup. Maybe it can trigger it like rm -rf but not cause it.
--
Soft lockups (freezes) when deleting files from ext4 partitions on 2.6.28
https://bugs.launchpad.net/bugs/330824
You received this bug
I can trigger the bug without X running, my card is also an ATI running
the driver provided by Xorg
--
Soft lockups (freezes) when deleting files from ext4 partitions on 2.6.28
https://bugs.launchpad.net/bugs/330824
You received this bug notification because you are a member of Ubuntu
Bugs,
I reproduced this bug on 3 computers, running nvidia, intel
(proprietary) and ati (OpenSource) cards. I also reproduced this bug in
the recovery-mode without X started, so definitively not related to
Xorg.
--
Soft lockups (freezes) when deleting files from ext4 partitions on 2.6.28
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I use the Nvidia binary driver however I've been able to reproduce
this from a console without X even running. I logged in from a
console, shut down X, then ran hang.py and it froze after about 3
rounds, that's when I saw the soft lockup on cpu0
Can reliably trigger this on nvidia, nv and vesa.
Theo, did you get my e2image attached above?
--
Soft lockups (freezes) when deleting files from ext4 partitions on 2.6.28
https://bugs.launchpad.net/bugs/330824
You received this bug notification because you are a member of Ubuntu
Bugs, which is
** Also affects: linux (Ubuntu Karmic)
Importance: Medium
Assignee: Tim Gardner (timg-tpi)
Status: In Progress
--
Soft lockups (freezes) when deleting files from ext4 partitions on 2.6.28
https://bugs.launchpad.net/bugs/330824
You received this bug notification because you are a
I reproduced this bug (kernel panic, total freeze) this morning by doing
*two* simultaneous rm -rf commands on folders created by copying /bin
/lib /boot /etc /lib64 /root /srv /usr /opt /sbin /var into two backup
folders on another ext4 partition.
I had netconsole running on another computer,
Alessandro, please make a point of reading all the comments on a bug
before adding your own. :)
--
Soft lockups (freezes) when deleting files from ext4 partitions on 2.6.28
https://bugs.launchpad.net/bugs/330824
You received this bug notification because you are a member of Ubuntu
Bugs, which
It happened really often to me with 2.6.28.x kernel, and now it doesn't happen
at all (tried everything to reproduce, but I couldn't) with a 2.6.29-1 kernel,
and also the 2.6.29 kernel is ok.
So we should just find the right patch that fixed it and apply to the current
kernel.
--
Soft lockups
@Theo
That was easy :p
I've got a 2.5GB ext4 image which reproduced the issue when mounted on
/mnt/test. Attached is the e2image output produced immediately before
deleting the files. The hang itself occurred part way into writing
the files during the next cycle (as it usually does).
**
I plugged my hard drive to another computer with 6GB RAM (instead of
640MB) and was not able to reproduce this bug at all neither with my
usual methods nor with hang.py. I can always easilly reproduce the bug
on 640MB machine in a few seconds.
--
Soft lockups (freezes) when deleting files from
As an idea; for people who can reproduce it easily, preferably one of
you who have been doing this on a relatively small (20-40GB filesystem),
maybe you would be willing to do the following?
(a) Load up the filesystem with the test set of files that, when deleted, will
product the hang.
(b)
@Theo, I originally experienced the crash on an external drive (i.e.,
not the root fs). I'm going to try to reproduce it on a small loop
image.
--
Soft lockups (freezes) when deleting files from ext4 partitions on 2.6.28
https://bugs.launchpad.net/bugs/330824
You received this bug notification
So it's still being worked on then? Not to be critical, but isn't this a
bug that's been known for months?
--
Soft lockups (freezes) when deleting files from ext4 partitions on 2.6.28
https://bugs.launchpad.net/bugs/330824
You received this bug notification because you are a member of Ubuntu
So it's still being worked on then? Not to be critical, but isn't this a
bug that's been known for months?
Yes, the status is still In progress.
Note that the mainline kernel's don't seem to be exhibiting this issue
(or at least orders of magnitude less often), so installing a 2.6.29
kernel
Documented at https://wiki.ubuntu.com/JauntyJackalope/ReleaseNotes
#Lock-ups when deleting files from ext4 filesystems:
In some cases, deleting files from an ext4 filesystem is reported to
cause soft lock-ups in the kernel. Investigation of this problem is
ongoing, and it is expected that a fix
Steve Langasek 18 hours ago
ubuntu-release-notes status:New → Fix Released
That's funny, because it was just about 18 hours ago now that this bug
made itself apparent to me.
I actually had ubuntu freeze when i tried a disk cleaning utility (it
didn't occur to me that it froze because
That would be because ubuntu-release-notes is not Ubuntu. It *just*
refers to the release notes. As Steve said, they are located at
https://wiki.ubuntu.com/JauntyJackalope/ReleaseNotes#Lock-ups. This
issue has been documented in the release notes, and thus, the fix for
the release notes has
On Tue, 2009-04-14 at 23:35 +, Carey Underwood wrote:
The existence of this bug should be noted in the release notes under
known issues as well as in the feature summary for Ext4 filesystem
support.
So basically, the fact that ext4 simply does not work in Ubuntu Jaunty
should be in the
On Wed, 2009-04-15 at 11:46 +, Carey Underwood wrote:
Because it's still being investigated, and 9.04 isn't actually
released yet. There's a perfectly good chance that the culprit is
nailed down and fixed before release, and if it can't, then simply
removing it from the final release
Because it's still being investigated, and 9.04 isn't actually
released yet. There's a perfectly good chance that the culprit is
nailed down and fixed before release, and if it can't, then simply
removing it from the final release notes and installer would suffice.
--
Soft lockups (freezes)
I'll note that part of the problem is that it doesn't seem to be
trivially reproducible even on Ubuntu Jaunty. I was having lunch with a
number of Ubuntu kernel developers at the Linux Foundation Collaboration
summit, and I talked to them specifically about this bug --- a number of
them indicated
Theodore Ts'o : I noticed that this bug is more likely to happen on
partitions that does not have many space left, in case that this give
you some hint. I have a 30 Gb partition which has only 3 Gb left. The
bug can be reproduced immediately each time on that partition. I have a
700 Gb partition
@Saivann,
Thanks, that's a really good tip. I'll see if I can reproduce on a
mostly full filesystem.
--
Soft lockups (freezes) when deleting files from ext4 partitions on 2.6.28
https://bugs.launchpad.net/bugs/330824
You received this bug notification because you are a member of Ubuntu
Bugs,
One other question --- for the people that have managed to reproduce, do
you know if there was any files getting created or otherwise blocks
getting allocated on the filesystem under test, or is an rm -rf of
some hierarchy in the filesystem sufficient on its own to cause the
system to hang?
--
On Wed, 2009-04-15 at 13:42 +, Theodore Ts'o wrote:
I'll note that part of the problem is that it doesn't seem to be
trivially reproducible even on Ubuntu Jaunty.
It seems to reproduce here when two processes are removing files/trees
from the same filesystem. And as another comment
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Saïvann Carignan wrote:
Theodore Ts'o : I noticed that this bug is more likely to happen on
partitions that does not have many space left, in case that this give
you some hint. I have a 30 Gb partition which has only 3 Gb left. The
bug can be
@Theodore - At every hang I was only deleting files, no other activity
was happening. A simple rm -rf on lot of small files or some big files
would do the trick.
I have two systems here running Jaunty, the slowest (Athlon 1000Mhz) can
reproduce the bug very easily. Yet I have to try multiple
Also to add, I can't confirm Saïvann Carignan's experience that it
happens on mostly full filesystems, since I have 150gb free on a 500gb
partition and can reproduce easily.
I feel personally that this is massive showstopper for ext4 and
shouldn't be an option in the final release of jaunty. I
@Ted - Saivann may have a point about a nearly full file system. Perhaps
one of the reasons I've not experienced any issues is that all of my
ext4 file systems are quite large (1.8T in one case) with relatively low
space utilization ( 5%). I continue to use ext4 on a kernel build
server (4 spindle
@yaztromo,
Well, the slowest machine I have is an netbook with an Atom N270 1.6GHz
processor with 1.5gigs of memory (Hmm, I wonder if amount of memory has
any significance; are people who can reproduce easily doing so with an
especially large or small amounts of memory?) and a 5400 rpm drive.
Just wanted to register myself as another user experiencing this bug and
give some details on the conditions under which I have been able to
reproduce it as they do not exactly correlate with some of the comments
above.
Latest kernel in repository - 2.6.28.11.14
4.5TB ext4 partition on top of a
On Wed, 2009-04-15 at 17:46 +, Theodore Ts'o wrote:
are people who can reproduce easily doing so with an
especially large or small amounts of memory?
MemTotal: 2851296 kB
MemFree:164428 kB
Buffers:469320 kB
Cached: 609504 kB
SwapCached: 1780 kB
Active:
@Theodore Ts'o
I can consistently reproduce this bug on my Acer Aspire One AOA150, which also
has an Atom N270 plus 1GB of RAM and a 120GB SATA HD.
It happens even on a clean install of Jaunty, as well as on a fully updated
install, with more than 100GB of HD free.
I can reliably trigger this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Theodore Ts'o wrote:
@yaztromo,
Well, the slowest machine I have is an netbook with an Atom N270 1.6GHz
processor with 1.5gigs of memory (Hmm, I wonder if amount of memory has
any significance; are people who can reproduce easily doing so with an
@Theodore
I can reproduce the bug on a 1.6Ghz Via with 2GB of memory. The
partition is on a 4 drive SATA II 7200rpm RAID 5 array. This box is
running at a console level only. I do not have Gnome or any other
applications, even Apache or MySQL installed. When the problem occurs
for me, I have no
I also confirm the small memory hypothesis. It's easier to reproduce
the bug on two computers which have respectively ~700Mb and 1024Mb of
Ram, but much more difficult to reproduce with my other computer that
has 2048 Mb (and large amount of free space). Might or might not be
related.
--
Soft
I have 640 MB ant svn up, on KDE repository core modules is enough to lockup.
So lockup happens quite easily.
--
Soft lockups (freezes) when deleting files from ext4 partitions on 2.6.28
https://bugs.launchpad.net/bugs/330824
You received this bug notification because you are a member of Ubuntu
Just to throw a wrench in, I have 8 GB of RAM and my volume is currently
52% full at 287 GB/583 GB.
It's interesting that from my count we have two people that haven't
reproduced it yet with the ~lp348836 kernel and two that have. Certainly
something else going on here.
Still going strong with
For those who are following along, the latest Ubuntu kernel (with a
custom config which I can include if anyone is interested) is blowing up
in early boot, in what looks like SATA/SCSI stack on my Lenovo S10.
Standard stock 2.6.28, 2.6.29 and 2.6.30-rc2 works just fine on the
Lenovo S10, using
2.5GB of memory, fairly high disk used (~85%), I can reproduce nearly at
will.
The bisect I performed above may have only found a patch that makes
things significantly worse: when running a kernel from the 'good'
side of the bisect I still get occasional lockups (on the order of 2-4
days),
101 - 200 of 270 matches
Mail list logo
