linux-kernel - Re: regression: 100% io-wait with 2.6.24-rcX

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <E1JCrMj-0001HR-SZ@localhost.localdomain>
Date:	Thu, 10 Jan 2008 14:58:13 +0800
From:	Fengguang Wu <wfg@...l.ustc.edu.cn>
To:	jplatte@...sa.net
Cc:	Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...e.hu>,
	linux-kernel@...r.kernel.org
Subject: Re: regression: 100% io-wait with 2.6.24-rcX

On Wed, Jan 09, 2008 at 02:04:29PM +0100, Joerg Platte wrote:
> Am Mittwoch, 9. Januar 2008 schrieb Fengguang Wu:
> > On Wed, Jan 09, 2008 at 01:22:33PM +0100, Joerg Platte wrote:
> > > Am Mittwoch, 9. Januar 2008 schrieb Fengguang Wu:
> > >
> > > Thank your for the hint with the filesystems!
> > >
> > > > Thank you for the clue. However I cannot reproduce the bug on
> > > > ext2/2.6.24-rc7. Can you provide more details? Thank you.
> > >
> > > I attached some more information. I'm using the ata_piix driver for my
> > > PATA disk and cdrom drive and booted with hpet=force. Kernel 2.6.23.X has
> > > been
> >
> >                                                           ~~~~~~~~
> > 							  not 2.6.24-rc7?
> >
> No, 2.6.23.X was the last working kernel without this problem, the bug shows 
> up with 2.6.24-rcX. I just wanted to emphasis, that I don't think that it has 
> something to do with the hpet stuff. Kernel 2.6.24-rcX is unpatched, because 
> the hrt stuff has been merged.
> 
> > > patched with the -hrt patches to enable the hidden hpet time on the
> > > ICH4-M chipset. I just rebooted the notebook and mounted /tmp again as
> > > ext2 and now the iowait problem is back. Seems to be reproducible on my
> > > computer. What additional information do you need?
> >
> > I mounted an ext2 as tmp and find no problem. My config options are:
> >
> > CONFIG_EXT2_FS=y
> > CONFIG_EXT2_FS_XATTR=y
> > CONFIG_EXT2_FS_POSIX_ACL=y
> > CONFIG_EXT2_FS_SECURITY=y
> > # CONFIG_EXT2_FS_XIP is not set
> >
> > Fengguang
> 
> CONFIG_EXT2_FS=m
> CONFIG_EXT2_FS_XATTR=y
> CONFIG_EXT2_FS_POSIX_ACL=y
> CONFIG_EXT2_FS_SECURITY=y
> CONFIG_EXT2_FS_XIP=y
> 
> Here it is modular and I enabled CONFIG_EXT2_FS_XIP, but the same is enabled 
> on 2.6.23.X. Maybe it is related to libata? I additionally discovered, that 
> the problem disappears for a few seconds when I press the eject button for 
> the ultra bay of my thinkpad. Pressing the button unregisters the cdrom drive 
> to be able to replace it with a hard drive or a battery. Maybe this bug is 
> thinkpad relared?

At last I caught it :-)

[ 1862.219189] requeue_io 301: inode 50948 size 0 at 03:02(hda2)
[ 1862.219199] requeue_io 301: inode 51616 size 0 at 03:02(hda2)
[ 1862.219204] requeue_io 301: inode 51656 size 0 at 03:02(hda2)
[ 1862.219208] requeue_io 301: inode 51655 size 0 at 03:02(hda2)
[ 1862.219216] mm/page-writeback.c 668 wb_kupdate: pdflush(182) 10768 global 3100 0 0 wc _M tw 1024 sk 1
[ 1862.319039] requeue_io 301: inode 50948 size 0 at 03:02(hda2)
[ 1862.319050] requeue_io 301: inode 51616 size 0 at 03:02(hda2)
[ 1862.319055] requeue_io 301: inode 51656 size 0 at 03:02(hda2)
[ 1862.319059] requeue_io 301: inode 51655 size 0 at 03:02(hda2)
[ 1862.319068] mm/page-writeback.c 668 wb_kupdate: pdflush(182) 10768 global 3100 0 0 wc _M tw 1024 sk 1

They are some zero sized files, maybe something goes wrong with the truncate code.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/