Subject : 2.6.33-rc2 allergic to amanda? Submitter : Gene Heskett <gene.heskett@verizon.net> Date : 2009-12-26 14:13 References : http://marc.info/?l=linux-kernel&m=126183682330809&w=4 Notify-Also : okias <d.okias@gmail.com> Notify-Also : Dmitry Torokhov <dmitry.torokhov@gmail.com> This entry is being used for tracking a regression from 2.6.32. Please don't close it until the problem is fixed in the mainline.
References : http://marc.info/?l=linux-kernel&m=126169372613898&w=4
On Tuesday 29 December 2009, Gene Heskett wrote: > On Tuesday 29 December 2009, 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.32. Please verify if it still should be listed and let me know > >(either way). > > > > > >Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14936 > >Subject : kernel BUG at fs/ext4/inode.c:1063 if attempted to > use non-ext4 > > partition with ext4 Submitter : Gene Heskett > <gene.heskett@verizon.net> > >Date : 2009-12-26 14:13 (4 days old) > >References : http://marc.info/?l=linux-kernel&m=126183682330809&w=4 > > http://marc.info/?l=linux-kernel&m=126169372613898&w=4 > > > I would assume its still valid. Even though I have rebuilt 2.6.33-rc2 3 > times now, it is so unstable, and so much stuff doesn't "Just Work" that I > haven't rebooted to it, or to 2.6.32.2 in about a week now. USB and > bluetooth are somewhat busted in 2.6.32.2. 2.6.32 final seems bulletproof > here. The first thing that pops its ugly head up during either a 2.6.32.2, > or a 2.6.33-rc2 boot is that it cannot find the firmware patch that is > sitting in /lib/firmware for my phenom X4 cpu. The load attempt, it looks > like, has been moved forward in the boot cycle, before it has actually able > to access a file by the /lib/firmware path known after the filesystems are > mounted. And a make xconfig no longer has the ability to edit the firmware > inclusions in the kernel, so that is 2 bugs even before we get to the > numerous oopsen that will bring it down in 15 minutes or so.
*** Bug 14911 has been marked as a duplicate of this bug. ***
On Tuesday 29 December 2009, tytso@mit.edu wrote: > On Tue, Dec 29, 2009 at 04:10:01PM +0100, Rafael J. Wysocki wrote: > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14936 > > Subject : kernel BUG at fs/ext4/inode.c:1063 if attempted to > use non-ext4 partition with ext4 > > Submitter : Gene Heskett <gene.heskett@verizon.net> > > Date : 2009-12-26 14:13 (4 days old) > > References : http://marc.info/?l=linux-kernel&m=126183682330809&w=4 > > http://marc.info/?l=linux-kernel&m=126169372613898&w=4 > > Bisected to commit d21cd8, and reverting this commit seems to fix the > problem. The problem appeared between -rc1 and -rc2. It was a fix > that was pushed as part of a quota/ext4 fixes. For more information: > > http://marc.info/?l=linux-ext4&m=126197233225936&w=2 > > I will take a look at this to see if I can find an easy fix; > otherwise, we'll probably want to revert commit d21cd8 before -rc3.
Handled-By : Theodore Ts'o <tytso@mit.edu> Patch : http://patchwork.kernel.org/patch/70282/
On Wednesday 30 December 2009, tytso@mit.edu wrote: > On Tue, Dec 29, 2009 at 11:57:12AM -0500, tytso@MIT.EDU wrote: > > On Tue, Dec 29, 2009 at 04:10:01PM +0100, Rafael J. Wysocki wrote: > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14936 > > > Subject : kernel BUG at fs/ext4/inode.c:1063 if attempted to > use non-ext4 partition with ext4 > > > Submitter : Gene Heskett <gene.heskett@verizon.net> > > > Date : 2009-12-26 14:13 (4 days old) > > > References : > http://marc.info/?l=linux-kernel&m=126183682330809&w=4 > > > http://marc.info/?l=linux-kernel&m=126169372613898&w=4 > > > > Bisected to commit d21cd8, and reverting this commit seems to fix the > > problem. The problem appeared between -rc1 and -rc2. It was a fix > > that was pushed as part of a quota/ext4 fixes. For more information: > > > > http://marc.info/?l=linux-ext4&m=126197233225936&w=2 > > > > I will take a look at this to see if I can find an easy fix; > > otherwise, we'll probably want to revert commit d21cd8 before -rc3. > > I'm working on a fix, and have a proposed patch. See the thread on > linux-ext4 here: > > http://marc.info/?l=linux-kernel&m=126219515024315&w=2 > > This patch also fixes the dq_claim_space kerneloops problem as > well....
On Thursday 31 December 2009, tytso@mit.edu wrote: > On Wed, Dec 30, 2009 at 10:52:12PM +0100, Rafael J. Wysocki wrote: > > > I'm working on a fix, and have a proposed patch. See the thread on > > > linux-ext4 here: > > > > > > http://marc.info/?l=linux-kernel&m=126219515024315&w=2 > > > > > > This patch also fixes the dq_claim_space kerneloops problem as > > > well.... > > > > Thanks, I've added your patch to the Bugzilla entry. > > This patch has been merged to mainline. I'm working on improving > things so that we don't lose performance by unnecessarily forcing > delalloc blocks out to disk when the (wildly overestimated) number of > required metadata blocks approaches the user's remaining quota or > remaining free space on disk, but the fundamental fix is in mainline. > > (The performance hit was something I knew about when I pushed the > patch to Linus, but after discussing things with Eric Sandeen, we > figured that for users who were converting from ext3, which didn't > have delayed allocation support at all, even with the performance hit > when the user approached the quota limit, ext4 with delalloc+quota was > still better than ext3 --- and I wanted a fix in mainline ASAP. > Fortunately, it's not going to be that hard make the required metadata > much more accurate.)
Fixed by commit 0637c6f4135f592f094207c7c21e7c0fc5557834 .