2.6.22-rc1: known regressions v2

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

Timers/NOHZ

Subject : 2.6.21-git4 BUG: soft lockup detected on CPU#1!
References : http://lkml.org/lkml/2007/5/2/511
Submitter : Michal Piotrowski <[email protected]>

Status : problem is being debugged

USB

Subject : usb hotplug/udev cannot correctly register usb/scanners
References : http://lkml.org/lkml/2007/5/15/205
Submitter : [email protected] <[email protected]>
Status : Unknown

V4L

Subject : V4L ABI breakage
References : http://lkml.org/lkml/2007/5/14/42
Submitter : Robert Fitzsimons <[email protected]>

Mauro Carvalho Chehab <[email protected]> commit 206ebaf32795cf1582b1e2ff2ec6a560c9e986b8
Status : Unknown

Networking

Subject : panic with e1000 driver on HP Integrity servers
References : http://bugzilla.kernel.org/show_bug.cgi?id=8455
Submitter : Doug Chapman <[email protected]>

             commit e0aac5a289b1dacbc94bd9ae8c449bcdf9ab508c

Status : problem is being debugged

Regards,
Michal

--
Michal K. K. Piotrowski
Kernel Monkeys
(http://kernel.wikidot.com/start)

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

Hi Michal,

We are currently working on it. I expect to have a patch fixing the issue until next week.

Cheers,
Mauro.

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]>

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]>

             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]>

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)

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

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

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

Good to here. I think the problem is fixed, then.

There aren't any that I can see - if more come up we'll deal with them then.

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