Hi all,
Here is a list of some known regressions in 2.6.22-rc1.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
File systems
Subject : 2.6.21-git10/11: files getting truncated on xfs
References : http://lkml.org/lkml/2007/5/9/410
Submitter : Jeremy Fitzhardinge <[email protected]>
Handled-By : David Chinner <[email protected]>
Patch : http://lkml.org/lkml/2007/5/12/93
Status : patch was suggested
Memory management
Subject : kernel BUG at include/linux/slub_def.h:88 kmalloc_index()
References : http://bugzilla.kernel.org/show_bug.cgi?id=8476
Submitter : Cherwin R. Nooitmeer <[email protected]>
Status : Unknown
SATA/PATA
Subject : libata crash on halt
References : http://marc.info/?l=linux-ide&m=117899827710565&w=2
Submitter : Andrew Morton <[email protected]>
Caused-By : Tejun Heo <[email protected]>
commit 920a4b1038e442700a1cfac77ea7e20bd615a2c3
Status : problem is being debugged
Subject : libata reset-seq merge broke sata_sil on sh
References : http://lkml.org/lkml/2007/5/10/63
Submitter : Paul Mundt <[email protected]>
Handled-By : Tejun Heo <[email protected]>
Caused-By : commit 4750def52cb2c21732dda9aa1d43a07db37b0186
Status : problem is being debugged
Suspend
Subject : Broken suspend on SMP with tifm
References : http://lkml.org/lkml/2007/5/13/161
Submitter : Rafael J. Wysocki <[email protected]>
Status : patch was suggested
Regards,
Michal
--
Michal K. K. Piotrowski
Kernel Monkeys
(http://kernel.wikidot.com/start)
On Wed, 16 May 2007, Michal Piotrowski wrote:
> Memory management
>
> Subject : kernel BUG at include/linux/slub_def.h:88 kmalloc_index()
> References : http://bugzilla.kernel.org/show_bug.cgi?id=8476
> Submitter : Cherwin R. Nooitmeer <[email protected]>
> Status : Unknown
This a kmalloc(0) that needs fixing.
On Wed, 16 May 2007, Christoph Lameter wrote:
> On Wed, 16 May 2007, Michal Piotrowski wrote:
>
> > Memory management
> >
> > Subject : kernel BUG at include/linux/slub_def.h:88 kmalloc_index()
> > References : http://bugzilla.kernel.org/show_bug.cgi?id=8476
> > Submitter : Cherwin R. Nooitmeer <[email protected]>
> > Status : Unknown
>
>
> This a kmalloc(0) that needs fixing.
Well, "needs fixing" is a bit strong.
It's a scary message for something we've always handled, and that we still
handle fine, we just complain about it.
So we'll probably just turn the message off for 2.6.22, but in the
meantime, we leave it on and try to fix as many of these as we can be
bothered to.
Linus
On Wed, May 16, 2007 at 10:31:39PM +0200, Michal Piotrowski wrote:
> Hi all,
>
> Here is a list of some known regressions in 2.6.22-rc1.
>
> Feel free to add new regressions/remove fixed etc.
> http://kernelnewbies.org/known_regressions
>
> File systems
>
> Subject : 2.6.21-git10/11: files getting truncated on xfs
> References : http://lkml.org/lkml/2007/5/9/410
> Submitter : Jeremy Fitzhardinge <[email protected]>
> Handled-By : David Chinner <[email protected]>
> Patch : http://lkml.org/lkml/2007/5/12/93
> Status : patch was suggested
Jeremy has tentatively indicated that the patch has fixed the problem.
Have you seen any more problems since applying the patch, Jeremy?
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
David Chinner wrote:
> Jeremy has tentatively indicated that the patch has fixed the problem.
> Have you seen any more problems since applying the patch, Jeremy?
>
No, it continues to seem sound with casual use; I would have expected to
see the problem reoccur by now. I'd like to rerun the full set of tests
I did before to be sure, but so far so good. No other apparent
regressions either.
Also, the match between the observed symptoms and the bugfix is very
good, which adds confidence (ie, no element of "it works now but we
don't know why"). I guess the only remaining concern is whether there
are any other paths which fail to dirty the inode.
Did you manage to repro the problem?
J
On Wed, May 16, 2007 at 04:40:20PM -0700, Jeremy Fitzhardinge wrote:
> David Chinner wrote:
> > Jeremy has tentatively indicated that the patch has fixed the problem.
> > Have you seen any more problems since applying the patch, Jeremy?
> >
>
> No, it continues to seem sound with casual use; I would have expected to
> see the problem reoccur by now. I'd like to rerun the full set of tests
> I did before to be sure, but so far so good. No other apparent
> regressions either.
Good to here. I think the problem is fixed, then.
> Also, the match between the observed symptoms and the bugfix is very
> good, which adds confidence (ie, no element of "it works now but we
> don't know why"). I guess the only remaining concern is whether there
> are any other paths which fail to dirty the inode.
There aren't any that I can see - if more come up we'll deal with
them then.
> Did you manage to repro the problem?
xfs_io is my friend ;)
Without patch:
# touch /mnt/scratch/fred
# xfs_io -c "pwrite 0 5" -c "s" -c "pwrite 5 5" /mnt/scratch/fred
wrote 5/5 bytes at offset 0
5.000000 bytes, 1 ops; 0.0000 sec (78.755 KiB/sec and 16129.0323 ops/sec)
wrote 5/5 bytes at offset 5
5.000000 bytes, 1 ops; 0.0000 sec (542.535 KiB/sec and 111111.1111 ops/sec)
# umount /mnt/scratch; mount /mnt/scratch; ls -l /mnt/scratch/fred
-rw-r--r-- 1 root root 5 May 17 10:04 fred
#
So the second 5 byte write didn't change the file size.
With patch:
# touch /mnt/scratch/fred
# xfs_io -c "pwrite 0 5" -c "s" -c "pwrite 5 5" /mnt/scratch/fred
wrote 5/5 bytes at offset 0
5.000000 bytes, 1 ops; 0.0000 sec (76 KiB/sec and 15625.0000 ops/sec)
wrote 5/5 bytes at offset 5
5.000000 bytes, 1 ops; 0.0000 sec (610 KiB/sec and 125000.0000 ops/sec)
# umount /mnt/scratch; mount /mnt/scratch; ls -l /mnt/scratch/fred
-rw-r--r-- 1 root root 10 May 17 09:53 fred
#
So yes, I've reproduced it and confirmed the patch fixes the problem.
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group