Re: [PATCH 1/7] [RFC] ARM: remove Intel iop33x and iop13xx support
* Dan Williams [2019-08-09 11:34]: > > Earlier versions of OpenWRT and Debian both had support for iop32x > > but not the others, and they both dropped iop32x as well in their 2015 > > releases. > > > > Signed-off-by: Arnd Bergmann > > --- > > I'm just guessing that iop32x is still needed, and the other two are > > not. If anyone disagrees with that assessment, let me know so we > > can come up with an alternative approach. > > I'm not sure who would scream if iop32x support went away as well, but > I have not followed this space in years hence copying Martin. I believe iop13xx were mostly Intel dev boards. I'm not aware of any major devices based on iop33x. As Arnd points out, Debian used to have support for various iop32x devices. While Debian hasn't supported iop32x in a number of years, these devices are still usable and in use (RMK being a prime example). So I think it's safe to drop iop33x/iop13xx while retaining support for iop32x. As I was looking at my email archives, I saw an email from Peter Teichmann who was working on an iop33x based platform (around 2009) so I've copied him as well. > In any event: > > Acked-by: Dan Williams Acked-by: Martin Michlmayr -- Martin Michlmayr https://www.cyrius.com/
Re: [PATCH 01/13] MAINTAINERS: Adding Maintainers for AMD Seattle Device Tree
* Suravee Suthikulpanit [2016-01-27 15:11]: > +AMD SEATTLE DEVICE TREE SUPPORT > +M: Brijesh Singh > +M: Suravee Suthikulpanit > +S: Supported > +M: Tom Lendacky > +S: Supported Just a minor comment, but you have a duplicate "S: Supported" line. -- Martin Michlmayr http://www.cyrius.com/
Re: [PATCH 01/13] MAINTAINERS: Adding Maintainers for AMD Seattle Device Tree
* Suravee Suthikulpanit <suravee.suthikulpa...@amd.com> [2016-01-27 15:11]: > +AMD SEATTLE DEVICE TREE SUPPORT > +M: Brijesh Singh <brijeshkumar.si...@amd.com> > +M: Suravee Suthikulpanit <suravee.suthikulpa...@amd.com> > +S: Supported > +M: Tom Lendacky <thomas.lenda...@amd.com> > +S: Supported Just a minor comment, but you have a duplicate "S: Supported" line. -- Martin Michlmayr http://www.cyrius.com/
Re: [2.6.25 patch] drivers/crypto/hifn_795x.c: fix 64bit division
* Adrian Bunk <[EMAIL PROTECTED]> [2008-02-26 17:34]: > > MODPOST 759 modules > > ERROR: "__divdi3" [drivers/crypto/hifn_795x.ko] undefined! > > Fix below. Tested-by: Martin Michlmayr <[EMAIL PROTECTED]> -- Martin Michlmayr http://www.cyrius.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc3: "__divdi3" [drivers/crypto/hifn_795x.ko] undefined!
* Patrick McHardy <[EMAIL PROTECTED]> [2008-02-26 13:28]: >> I get the following build error on at least ARM and MIPS: >> Building modules, stage 2. >> MODPOST 759 modules >> ERROR: "__divdi3" [drivers/crypto/hifn_795x.ko] undefined! > > Does this patch fix it? Nope. -- Martin Michlmayr http://www.cyrius.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.25-rc3: "__divdi3" [drivers/crypto/hifn_795x.ko] undefined!
With 2.6.25-rc3 and a config file with CONFIG_CRYPTO_DEV_HIFN_795X=m CONFIG_CRYPTO_DEV_HIFN_795X_RNG=y I get the following build error on at least ARM and MIPS: Building modules, stage 2. MODPOST 759 modules ERROR: "__divdi3" [drivers/crypto/hifn_795x.ko] undefined! -- Martin Michlmayr http://www.cyrius.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.25-rc3: __divdi3 [drivers/crypto/hifn_795x.ko] undefined!
With 2.6.25-rc3 and a config file with CONFIG_CRYPTO_DEV_HIFN_795X=m CONFIG_CRYPTO_DEV_HIFN_795X_RNG=y I get the following build error on at least ARM and MIPS: Building modules, stage 2. MODPOST 759 modules ERROR: __divdi3 [drivers/crypto/hifn_795x.ko] undefined! -- Martin Michlmayr http://www.cyrius.com/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc3: __divdi3 [drivers/crypto/hifn_795x.ko] undefined!
* Patrick McHardy [EMAIL PROTECTED] [2008-02-26 13:28]: I get the following build error on at least ARM and MIPS: Building modules, stage 2. MODPOST 759 modules ERROR: __divdi3 [drivers/crypto/hifn_795x.ko] undefined! Does this patch fix it? Nope. -- Martin Michlmayr http://www.cyrius.com/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.25 patch] drivers/crypto/hifn_795x.c: fix 64bit division
* Adrian Bunk [EMAIL PROTECTED] [2008-02-26 17:34]: MODPOST 759 modules ERROR: __divdi3 [drivers/crypto/hifn_795x.ko] undefined! Fix below. Tested-by: Martin Michlmayr [EMAIL PROTECTED] -- Martin Michlmayr http://www.cyrius.com/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] scsi fixes for 2.6.25-rc2
* Linus Torvalds <[EMAIL PROTECTED]> [2008-02-23 12:31]: > I'm personally of the opinion that a new driver that doesn't add > anything but itself (ie no infrastructure changes etc) is fine. I'd > rather have a new, rough driver that might work, than no driver at > all, and it's not like it can cause a regression if you don't enable > it. Maybe we can still get the new S-35390A RTC driver in then. It has been acked by Jean Delvare and David Brownell. Byron or Jean, can you try to submit it again? It's needed by the QNAP TS-109/TS-209, a NAS device for which support has been added in 2.6.25-rc1. -- Martin Michlmayr http://www.cyrius.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] scsi fixes for 2.6.25-rc2
* Linus Torvalds [EMAIL PROTECTED] [2008-02-23 12:31]: I'm personally of the opinion that a new driver that doesn't add anything but itself (ie no infrastructure changes etc) is fine. I'd rather have a new, rough driver that might work, than no driver at all, and it's not like it can cause a regression if you don't enable it. Maybe we can still get the new S-35390A RTC driver in then. It has been acked by Jean Delvare and David Brownell. Byron or Jean, can you try to submit it again? It's needed by the QNAP TS-109/TS-209, a NAS device for which support has been added in 2.6.25-rc1. -- Martin Michlmayr http://www.cyrius.com/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][resend] PCI: fix IDE legacy mode resources
* Jeff Garzik <[EMAIL PROTECTED]> [2007-09-28 06:23]: >>>> Yoichi's original patch and explanation can be found at >>>> http://lkml.org/lkml/2007/8/23/411 >>> I've no idea why it hasn't been applied unless nobody is quite sure who >>> owns it. As a PCI fix I guess Greg does (and drop it into -mm for >>> testing) ? >> I was also hoping Jeff would comment on the patch. > > What sort of comment were you seeking? :) A comment whether this is the right approach. You asked for a rationale when Yoichi originally submitted the patch in July but then never responded to his explanation: http://marc.info/?l=linux-kernel=118564639820460=2 -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][resend] PCI: fix IDE legacy mode resources
* Alan Cox <[EMAIL PROTECTED]> [2007-09-28 11:14]: > > I need this patch for IDE and PATA to work on my MIPS Cobalt. > > Yoichi's original patch and explanation can be found at > > http://lkml.org/lkml/2007/8/23/411 > > I've no idea why it hasn't been applied unless nobody is quite sure who > owns it. As a PCI fix I guess Greg does (and drop it into -mm for > testing) ? I was also hoping Jeff would comment on the patch. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][resend] fix IDE legacy mode resources
* Alan Cox <[EMAIL PROTECTED]> [2007-08-24 17:37]: > >> PCI: Unable to reserve I/O region #1:[EMAIL PROTECTED] for device > >> :00:09.1 > > > In some architectures, PCI bus regions have the offset from PCI resources. > > > For this reason, pci_setup_device() should set PCI bus regions to > > > dev->resource[]. > > > > I thought this patch was rejected in the past as it broke other > > machines. > > News to me. > > Ths one looks sane and is different to the one Andrew has been fiddling > with to stop broken X servers from crashing. Can this patch be added now or does there have to be more discussion? I need this patch for IDE and PATA to work on my MIPS Cobalt. Yoichi's original patch and explanation can be found at http://lkml.org/lkml/2007/8/23/411 -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][resend] fix IDE legacy mode resources
* Alan Cox [EMAIL PROTECTED] [2007-08-24 17:37]: PCI: Unable to reserve I/O region #1:[EMAIL PROTECTED] for device :00:09.1 In some architectures, PCI bus regions have the offset from PCI resources. For this reason, pci_setup_device() should set PCI bus regions to dev-resource[]. I thought this patch was rejected in the past as it broke other machines. News to me. Ths one looks sane and is different to the one Andrew has been fiddling with to stop broken X servers from crashing. Can this patch be added now or does there have to be more discussion? I need this patch for IDE and PATA to work on my MIPS Cobalt. Yoichi's original patch and explanation can be found at http://lkml.org/lkml/2007/8/23/411 -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][resend] PCI: fix IDE legacy mode resources
* Alan Cox [EMAIL PROTECTED] [2007-09-28 11:14]: I need this patch for IDE and PATA to work on my MIPS Cobalt. Yoichi's original patch and explanation can be found at http://lkml.org/lkml/2007/8/23/411 I've no idea why it hasn't been applied unless nobody is quite sure who owns it. As a PCI fix I guess Greg does (and drop it into -mm for testing) ? I was also hoping Jeff would comment on the patch. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][resend] PCI: fix IDE legacy mode resources
* Jeff Garzik [EMAIL PROTECTED] [2007-09-28 06:23]: Yoichi's original patch and explanation can be found at http://lkml.org/lkml/2007/8/23/411 I've no idea why it hasn't been applied unless nobody is quite sure who owns it. As a PCI fix I guess Greg does (and drop it into -mm for testing) ? I was also hoping Jeff would comment on the patch. What sort of comment were you seeking? :) A comment whether this is the right approach. You asked for a rationale when Yoichi originally submitted the patch in July but then never responded to his explanation: http://marc.info/?l=linux-kernelm=118564639820460w=2 -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network slowdown due to CFS
* Ingo Molnar <[EMAIL PROTECTED]> [2007-09-27 12:56]: > i'm curious by how much does CPU go down, and what's the output of > iperf? (does it saturate full 100mbit network bandwidth) I get about 94-95 Mbits/sec and CPU drops from 99% to about 82% (this is with a 600 MHz ARM CPU). -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network slowdown due to CFS
* Ingo Molnar <[EMAIL PROTECTED]> [2007-09-27 11:49]: > Martin, could you check the iperf patch below instead of the yield > patch - does it solve the iperf performance problem equally well, > and does CPU utilization drop for you too? Yes, it works and CPU goes down too. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Updating include/asm symlink when $ARCH changes
I cross compile arm and mips kernels from the same kernel tree. When I build a kernel the first time with a fresh kernel tree, the include/asm symlink is set properly. However, when I compile for a different $ARCH, the include/asm is not changed and the build fails. Would it be possible for the build system to update the include/asm symlink when it doesn't correspond to the architecture you're currently trying to build for? -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Updating include/asm symlink when $ARCH changes
I cross compile arm and mips kernels from the same kernel tree. When I build a kernel the first time with a fresh kernel tree, the include/asm symlink is set properly. However, when I compile for a different $ARCH, the include/asm is not changed and the build fails. Would it be possible for the build system to update the include/asm symlink when it doesn't correspond to the architecture you're currently trying to build for? -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network slowdown due to CFS
* Ingo Molnar [EMAIL PROTECTED] [2007-09-27 11:49]: Martin, could you check the iperf patch below instead of the yield patch - does it solve the iperf performance problem equally well, and does CPU utilization drop for you too? Yes, it works and CPU goes down too. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network slowdown due to CFS
* Ingo Molnar [EMAIL PROTECTED] [2007-09-27 12:56]: i'm curious by how much does CPU go down, and what's the output of iperf? (does it saturate full 100mbit network bandwidth) I get about 94-95 Mbits/sec and CPU drops from 99% to about 82% (this is with a 600 MHz ARM CPU). -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network slowdown due to CFS
* Ingo Molnar <[EMAIL PROTECTED]> [2007-09-26 13:21]: > > > I noticed on the iperf website a patch which contains sched_yield(). > > > http://dast.nlanr.net/Projects/Iperf2.0/patch-iperf-linux-2.6.21.txt > > great! Could you try this too: >echo 1 > /proc/sys/kernel/sched_compat_yield > > does it fix iperf performance too (with the yield patch applied to > iperf)? Yes, this gives me good performance too. > I think the real fix would be for iperf to use blocking network IO > though, or maybe to use a POSIX mutex or POSIX semaphores. So it's definitely not a bug in the kernel, only in iperf? (CCing Stephen Hemminger who wrote the iperf patch.) -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network slowdown due to CFS
* Mike Galbraith <[EMAIL PROTECTED]> [2007-09-26 12:23]: > I noticed on the iperf website a patch which contains sched_yield(). > http://dast.nlanr.net/Projects/Iperf2.0/patch-iperf-linux-2.6.21.txt > > Do you have that patch applied by any chance? If so, it might be a > worth while to try it without it. Yes, this patch was applied. When I revert it, I get the same (high) performance with both kernels. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network slowdown due to CFS
* Ingo Molnar <[EMAIL PROTECTED]> [2007-09-26 11:47]: > > this will gather a good deal of info about the workload in question. > > Please send me the resulting debug file. > Another thing: please also do the same with the vanilla v2.6.22 kernel, > and send me that file too. (so that the two cases can be compared) I put the log files here: http://www.cyrius.com/tmp/2.6.22 http://www.cyrius.com/tmp/2.6.23-rc8-sched-devel I increased the time ipfer ran to 30 secs since your script runs for over 15 secs. I got: [ 3] 0.0-30.0 sec331 MBytes 92.6 Mbits/sec 2.6.22 vs [ 3] 0.0-30.0 sec222 MBytes 62.1 Mbits/sec 2.6.23-rc8-sched-devel -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Network slowdown due to CFS
I noticed that my network performance has gone down from 2.6.22
from [ 3] 0.0-10.0 sec113 MBytes 95.0 Mbits/sec
to [ 3] 0.0-10.0 sec 75.7 MBytes 63.3 Mbits/sec
with 2.6.23-rc1 (and 2.6.23-rc8), as measured with iperf.
I did a git bisect today and tracked it back to the commit where CFS
was enabled ("sched: cfs core code; apply the CFS core code",
commit dd41f596cda0d7d6e4a8b139ffdfabcefdd46528). I also compiled a
kernel from
git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched-devel.git
but things don't improve.
This is on a Thecus N2100, an ARM (Intel IOP32x) based storage device
with a r8169 card, SATA disks and 512 MB RAM. My config is attached.
What kind of information can I supply so you can track this down?
--
Martin Michlmayr
http://www.cyrius.com/
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.22
# Wed Sep 26 07:56:08 2007
#
CONFIG_ARM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
# CONFIG_GENERIC_GPIO is not set
# CONFIG_GENERIC_TIME is not set
# CONFIG_GENERIC_CLOCKEVENTS is not set
CONFIG_MMU=y
# CONFIG_NO_IOPORT is not set
CONFIG_GENERIC_HARDIRQS=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ZONE_DMA=y
CONFIG_VECTORS_BASE=0x
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_IPC_NS is not set
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
# CONFIG_TASKSTATS is not set
# CONFIG_UTS_NS is not set
# CONFIG_AUDIT is not set
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=14
CONFIG_SYSFS_DEPRECATED=y
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
#
# Block layer
#
CONFIG_BLOCK=y
# CONFIG_LBD is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
#
# System Type
#
# CONFIG_ARCH_AAEC2000 is not set
# CONFIG_ARCH_INTEGRATOR is not set
# CONFIG_ARCH_REALVIEW is not set
# CONFIG_ARCH_VERSATILE is not set
# CONFIG_ARCH_AT91 is not set
# CONFIG_ARCH_CLPS7500 is not set
# CONFIG_ARCH_CLPS711X is not set
# CONFIG_ARCH_CO285 is not set
# CONFIG_ARCH_EBSA110 is not set
# CONFIG_ARCH_EP93XX is not set
# CONFIG_ARCH_FOOTBRIDGE is not set
# CONFIG_ARCH_NETX is not set
# CONFIG_ARCH_H720X is not set
# CONFIG_ARCH_IMX is not set
# CONFIG_ARCH_IOP13XX is not set
CONFIG_ARCH_IOP32X=y
# CONFIG_ARCH_IOP33X is not set
# CONFIG_ARCH_IXP23XX is not set
# CONFIG_ARCH_IXP2000 is not set
# CONFIG_ARCH_IXP4XX is not set
# CONFIG_ARCH_L7200 is not set
# CONFIG_ARCH_KS8695 is not set
# CONFIG_ARCH_NS9XXX is not set
# CONFIG_ARCH_PNX4008 is not set
# CONFIG_ARCH_PXA is not set
# CONFIG_ARCH_RPC is not set
# CONFIG_ARCH_SA1100 is not set
# CONFIG_ARCH_S3C2410 is not set
# CONFIG_ARCH_SHARK is not set
# CONFIG_ARCH_LH7A40X is not set
# CONFIG_ARCH_DAVINCI is not set
# CONFIG_ARCH_OMAP is not set
#
# IOP32x Implementation Options
#
#
# IOP32x Platform Types
#
CONFIG_MACH_EP80219=y
CONFIG_MACH_GLANTANK=y
CONFIG_ARCH_IQ80321=y
CONFIG_ARCH_IQ31244=y
CONFIG_MACH_N2100=y
CONFIG_IOP3XX_ATU=y
CONFIG_PLAT_IOP=y
#
# Processor Type
#
CONFIG_CPU_32=y
CONFIG_CPU_XSCALE=y
CONFIG_CPU_32v5=y
CONFIG_CPU_ABRT_EV5T=y
CONFIG_CPU_CACHE_VIVT=y
CONFIG_CPU_TLB_V4WBI=y
CONFIG_CPU_CP15=y
CONFIG_CPU_CP15_MMU=y
#
# Processor Features
#
# CONFIG_ARM_THUMB is not set
# CONFIG_CPU_DCACHE_DISABLE is not set
# CONFIG_OUTER_CACHE is not set
# CONFIG_IWMMXT is not set
CONFIG_XSCALE_PMU=y
#
# Bus support
#
CONFIG_PCI=y
# CONF
Network slowdown due to CFS
I noticed that my network performance has gone down from 2.6.22 from [ 3] 0.0-10.0 sec113 MBytes 95.0 Mbits/sec to [ 3] 0.0-10.0 sec 75.7 MBytes 63.3 Mbits/sec with 2.6.23-rc1 (and 2.6.23-rc8), as measured with iperf. I did a git bisect today and tracked it back to the commit where CFS was enabled (sched: cfs core code; apply the CFS core code, commit dd41f596cda0d7d6e4a8b139ffdfabcefdd46528). I also compiled a kernel from git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched-devel.git but things don't improve. This is on a Thecus N2100, an ARM (Intel IOP32x) based storage device with a r8169 card, SATA disks and 512 MB RAM. My config is attached. What kind of information can I supply so you can track this down? -- Martin Michlmayr http://www.cyrius.com/ # # Automatically generated make config: don't edit # Linux kernel version: 2.6.22 # Wed Sep 26 07:56:08 2007 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y # CONFIG_GENERIC_GPIO is not set # CONFIG_GENERIC_TIME is not set # CONFIG_GENERIC_CLOCKEVENTS is not set CONFIG_MMU=y # CONFIG_NO_IOPORT is not set CONFIG_GENERIC_HARDIRQS=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ZONE_DMA=y CONFIG_VECTORS_BASE=0x CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=14 CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Block layer # CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq # # System Type # # CONFIG_ARCH_AAEC2000 is not set # CONFIG_ARCH_INTEGRATOR is not set # CONFIG_ARCH_REALVIEW is not set # CONFIG_ARCH_VERSATILE is not set # CONFIG_ARCH_AT91 is not set # CONFIG_ARCH_CLPS7500 is not set # CONFIG_ARCH_CLPS711X is not set # CONFIG_ARCH_CO285 is not set # CONFIG_ARCH_EBSA110 is not set # CONFIG_ARCH_EP93XX is not set # CONFIG_ARCH_FOOTBRIDGE is not set # CONFIG_ARCH_NETX is not set # CONFIG_ARCH_H720X is not set # CONFIG_ARCH_IMX is not set # CONFIG_ARCH_IOP13XX is not set CONFIG_ARCH_IOP32X=y # CONFIG_ARCH_IOP33X is not set # CONFIG_ARCH_IXP23XX is not set # CONFIG_ARCH_IXP2000 is not set # CONFIG_ARCH_IXP4XX is not set # CONFIG_ARCH_L7200 is not set # CONFIG_ARCH_KS8695 is not set # CONFIG_ARCH_NS9XXX is not set # CONFIG_ARCH_PNX4008 is not set # CONFIG_ARCH_PXA is not set # CONFIG_ARCH_RPC is not set # CONFIG_ARCH_SA1100 is not set # CONFIG_ARCH_S3C2410 is not set # CONFIG_ARCH_SHARK is not set # CONFIG_ARCH_LH7A40X is not set # CONFIG_ARCH_DAVINCI is not set # CONFIG_ARCH_OMAP is not set # # IOP32x Implementation Options # # # IOP32x Platform Types # CONFIG_MACH_EP80219=y CONFIG_MACH_GLANTANK=y CONFIG_ARCH_IQ80321=y CONFIG_ARCH_IQ31244=y CONFIG_MACH_N2100=y CONFIG_IOP3XX_ATU=y CONFIG_PLAT_IOP=y # # Processor Type # CONFIG_CPU_32=y CONFIG_CPU_XSCALE=y CONFIG_CPU_32v5=y CONFIG_CPU_ABRT_EV5T=y CONFIG_CPU_CACHE_VIVT=y CONFIG_CPU_TLB_V4WBI=y CONFIG_CPU_CP15=y CONFIG_CPU_CP15_MMU=y # # Processor Features # # CONFIG_ARM_THUMB is not set # CONFIG_CPU_DCACHE_DISABLE is not set # CONFIG_OUTER_CACHE is not set # CONFIG_IWMMXT is not set CONFIG_XSCALE_PMU=y # # Bus support # CONFIG_PCI=y # CONFIG_ARCH_SUPPORTS_MSI is not set # CONFIG_PCI_DEBUG is not set
Re: Network slowdown due to CFS
* Ingo Molnar [EMAIL PROTECTED] [2007-09-26 11:47]: this will gather a good deal of info about the workload in question. Please send me the resulting debug file. Another thing: please also do the same with the vanilla v2.6.22 kernel, and send me that file too. (so that the two cases can be compared) I put the log files here: http://www.cyrius.com/tmp/2.6.22 http://www.cyrius.com/tmp/2.6.23-rc8-sched-devel I increased the time ipfer ran to 30 secs since your script runs for over 15 secs. I got: [ 3] 0.0-30.0 sec331 MBytes 92.6 Mbits/sec 2.6.22 vs [ 3] 0.0-30.0 sec222 MBytes 62.1 Mbits/sec 2.6.23-rc8-sched-devel -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network slowdown due to CFS
* Mike Galbraith [EMAIL PROTECTED] [2007-09-26 12:23]: I noticed on the iperf website a patch which contains sched_yield(). http://dast.nlanr.net/Projects/Iperf2.0/patch-iperf-linux-2.6.21.txt Do you have that patch applied by any chance? If so, it might be a worth while to try it without it. Yes, this patch was applied. When I revert it, I get the same (high) performance with both kernels. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Network slowdown due to CFS
* Ingo Molnar [EMAIL PROTECTED] [2007-09-26 13:21]: I noticed on the iperf website a patch which contains sched_yield(). http://dast.nlanr.net/Projects/Iperf2.0/patch-iperf-linux-2.6.21.txt great! Could you try this too: echo 1 /proc/sys/kernel/sched_compat_yield does it fix iperf performance too (with the yield patch applied to iperf)? Yes, this gives me good performance too. I think the real fix would be for iperf to use blocking network IO though, or maybe to use a POSIX mutex or POSIX semaphores. So it's definitely not a bug in the kernel, only in iperf? (CCing Stephen Hemminger who wrote the iperf patch.) -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers/video/pmag-ba-fb.c: Improve diagnostics
* Andrew Morton <[EMAIL PROTECTED]> [2007-09-19 17:24]: > I made that change, but am too stupid to be able to work out how to create > a config which will let me compile this thing. > > akpm:/usr/src/25> grep PMAG arch/arm/configs/* > akpm:/usr/src/25> It's a driver for mips. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers/video/pmag-ba-fb.c: Improve diagnostics
* Andrew Morton [EMAIL PROTECTED] [2007-09-19 17:24]: I made that change, but am too stupid to be able to work out how to create a config which will let me compile this thing. akpm:/usr/src/25 grep PMAG arch/arm/configs/* akpm:/usr/src/25 It's a driver for mips. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DM_MULTIPATH_RDAC: "scsi_normalize_sense" undefined
* Randy Dunlap <[EMAIL PROTECTED]> [2007-08-24 15:00]: > From: Randy Dunlap <[EMAIL PROTECTED]> > > DM_MULTIPATH_RDAC uses SCSI API(s) and is for a SCSI device, > so add SCSI to its depends on to prevent build errors. > > Not tested. > > Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> Tested-by: Martin Michlmayr <[EMAIL PROTECTED]> This works for me. Please make sure it'll go into 2.6.23. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DM_MULTIPATH_RDAC: "scsi_normalize_sense" undefined
* Chandra Seetharaman <[EMAIL PROTECTED]> [2007-08-24 14:33]: > It does, but "rdac" _is_ for a SCSI device. > > What device are you using it with ? I'm not using it at all. I merely compiled a kernel where DM_MULTIPATH_RDAC was activated by chance without SCSI. Randy's patch looks good. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DM_MULTIPATH_RDAC: scsi_normalize_sense undefined
* Chandra Seetharaman [EMAIL PROTECTED] [2007-08-24 14:33]: It does, but rdac _is_ for a SCSI device. What device are you using it with ? I'm not using it at all. I merely compiled a kernel where DM_MULTIPATH_RDAC was activated by chance without SCSI. Randy's patch looks good. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DM_MULTIPATH_RDAC: scsi_normalize_sense undefined
* Randy Dunlap [EMAIL PROTECTED] [2007-08-24 15:00]: From: Randy Dunlap [EMAIL PROTECTED] DM_MULTIPATH_RDAC uses SCSI API(s) and is for a SCSI device, so add SCSI to its depends on to prevent build errors. Not tested. Signed-off-by: Randy Dunlap [EMAIL PROTECTED] Tested-by: Martin Michlmayr [EMAIL PROTECTED] This works for me. Please make sure it'll go into 2.6.23. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
DM_MULTIPATH_RDAC: "scsi_normalize_sense" undefined
I just got: Building modules, stage 2. MODPOST 414 modules ERROR: "scsi_normalize_sense" [drivers/md/dm-rdac.ko] undefined! make[1]: *** [__modpost] Error 1 Presumably DM_MULTIPATH_RDAC needs to depend on SCSI (not enabled here) since it uses scsi_normalize_sense. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
DM_MULTIPATH_RDAC: scsi_normalize_sense undefined
I just got: Building modules, stage 2. MODPOST 414 modules ERROR: scsi_normalize_sense [drivers/md/dm-rdac.ko] undefined! make[1]: *** [__modpost] Error 1 Presumably DM_MULTIPATH_RDAC needs to depend on SCSI (not enabled here) since it uses scsi_normalize_sense. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: drop support for gcc < 4.0
* Jan Engelhardt <[EMAIL PROTECTED]> [2007-08-22 09:57]: > >I think it's bad idea, when removing support for gcc3.x, while some > >people using debian 3.1 at now and under debian 3.1 the default > >comiler is 3.3.5, when I good know or not!? > They always lag behind. Debian 4.0 has GCC 4.1 as the default compiler, and we use 4.1 to compile our kernels on all architectures except of m68k. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: drop support for gcc 4.0
* Jan Engelhardt [EMAIL PROTECTED] [2007-08-22 09:57]: I think it's bad idea, when removing support for gcc3.x, while some people using debian 3.1 at now and under debian 3.1 the default comiler is 3.3.5, when I good know or not!? They always lag behind. Debian 4.0 has GCC 4.1 as the default compiler, and we use 4.1 to compile our kernels on all architectures except of m68k. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [38/2many] MAINTAINERS - ALPHA PORT
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2007-08-12 23:22]: > S: Maintained for 2.4; PCI support for 2.6. > +F: arch/alfa/ Typo, this should be arch/alpha/ -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [38/2many] MAINTAINERS - ALPHA PORT
* [EMAIL PROTECTED] [EMAIL PROTECTED] [2007-08-12 23:22]: S: Maintained for 2.4; PCI support for 2.6. +F: arch/alfa/ Typo, this should be arch/alpha/ -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Fix section conflict of current_io_context
Building with GCC 4.2, I get the following error:
CC block/ll_rw_blk.o
block/ll_rw_blk.c:3751: error: __ksymtab_current_io_context causes a section
type conflict
This is because current_io_context is both declared static and exported.
Signed-off-by: Martin Michlmayr <[EMAIL PROTECTED]>
--- a/block/ll_rw_blk.c
+++ b/block/ll_rw_blk.c
@@ -41,7 +41,7 @@ static void blk_unplug_timeout(unsigned long data);
static void drive_stat_acct(struct request *rq, int nr_sectors, int new_io);
static void init_request_from_bio(struct request *req, struct bio *bio);
static int __make_request(request_queue_t *q, struct bio *bio);
-static struct io_context *current_io_context(gfp_t gfp_flags, int node);
+struct io_context *current_io_context(gfp_t gfp_flags, int node);
/*
* For the allocated request tables
@@ -3723,7 +3723,7 @@ void exit_io_context(void)
* but since the current task itself holds a reference, the context can be
* used in general code, so long as it stays within `current` context.
*/
-static struct io_context *current_io_context(gfp_t gfp_flags, int node)
+struct io_context *current_io_context(gfp_t gfp_flags, int node)
{
struct task_struct *tsk = current;
struct io_context *ret;
--
Martin Michlmayr
http://www.cyrius.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Fix section conflict of current_io_context
Building with GCC 4.2, I get the following error:
CC block/ll_rw_blk.o
block/ll_rw_blk.c:3751: error: __ksymtab_current_io_context causes a section
type conflict
This is because current_io_context is both declared static and exported.
Signed-off-by: Martin Michlmayr [EMAIL PROTECTED]
--- a/block/ll_rw_blk.c
+++ b/block/ll_rw_blk.c
@@ -41,7 +41,7 @@ static void blk_unplug_timeout(unsigned long data);
static void drive_stat_acct(struct request *rq, int nr_sectors, int new_io);
static void init_request_from_bio(struct request *req, struct bio *bio);
static int __make_request(request_queue_t *q, struct bio *bio);
-static struct io_context *current_io_context(gfp_t gfp_flags, int node);
+struct io_context *current_io_context(gfp_t gfp_flags, int node);
/*
* For the allocated request tables
@@ -3723,7 +3723,7 @@ void exit_io_context(void)
* but since the current task itself holds a reference, the context can be
* used in general code, so long as it stays within `current` context.
*/
-static struct io_context *current_io_context(gfp_t gfp_flags, int node)
+struct io_context *current_io_context(gfp_t gfp_flags, int node)
{
struct task_struct *tsk = current;
struct io_context *ret;
--
Martin Michlmayr
http://www.cyrius.com/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Ok, explained.. (was Re: [PATCH] mm: fix page_mkclean_one)
* Stephen Clark <[EMAIL PROTECTED]> [2006-12-29 10:17]:
> >It works for me now, both your testcase as well as an installation of
> >Debian on this ARM device. I manually applied the patch to 2.6.19.
>
> Can you post a diff against 2.6.19?
--- a/mm/page-writeback.c 2006-11-29 21:57:37.0 +
+++ b/mm/page-writeback.c 2006-12-29 11:02:55.555147896 +
@@ -893,16 +893,45 @@
{
struct address_space *mapping = page_mapping(page);
- if (mapping) {
+ if (mapping && mapping_cap_account_dirty(mapping)) {
+ /*
+* Yes, Virginia, this is indeed insane.
+*
+* We use this sequence to make sure that
+* (a) we account for dirty stats properly
+* (b) we tell the low-level filesystem to
+* mark the whole page dirty if it was
+* dirty in a pagetable. Only to then
+* (c) clean the page again and return 1 to
+* cause the writeback.
+*
+* This way we avoid all nasty races with the
+* dirty bit in multiple places and clearing
+* them concurrently from different threads.
+*
+* Note! Normally the "set_page_dirty(page)"
+* has no effect on the actual dirty bit - since
+* that will already usually be set. But we
+* need the side effects, and it can help us
+* avoid races.
+*
+* We basically use the page "master dirty bit"
+* as a serialization point for all the different
+* threds doing their things.
+*
+* FIXME! We still have a race here: if somebody
+* adds the page back to the page tables in
+* between the "page_mkclean()" and the "TestClearPageDirty()",
+* we might have it mapped without the dirty bit set.
+*/
+ if (page_mkclean(page))
+ set_page_dirty(page);
if (TestClearPageDirty(page)) {
- if (mapping_cap_account_dirty(mapping)) {
- page_mkclean(page);
- dec_zone_page_state(page, NR_FILE_DIRTY);
- }
+ dec_zone_page_state(page, NR_FILE_DIRTY);
return 1;
}
return 0;
- }
+ }
return TestClearPageDirty(page);
}
EXPORT_SYMBOL(clear_page_dirty_for_io);
--
Martin Michlmayr
http://www.cyrius.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Ok, explained.. (was Re: [PATCH] mm: fix page_mkclean_one)
* Linus Torvalds <[EMAIL PROTECTED]> [2006-12-29 02:48]: > Can anybody get corruption with this thing applied? It goes on top > of plain v2.6.20-rc2. It works for me now, both your testcase as well as an installation of Debian on this ARM device. I manually applied the patch to 2.6.19. Thanks. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alternative msync() fix for 2.6.18?
CCing linux-kernel since Hugh's patch might be of interest to
non-Debian people too. This message concerns a problem with msync()
in 2.6.17 and 2.6.18 that can be found with the LSB test suite.
* Hugh Dickins <[EMAIL PROTECTED]> [2006-12-27 01:04]:
> On Tue, 26 Dec 2006, Hugh Dickins wrote:
> > On Tue, 26 Dec 2006, Martin Michlmayr wrote:
> > >
> > > The first message at http://bugs.debian.org/394392 contains some
> > > information about it, but I'm sure Jeff Licquia (CCed) can provide
> > > more information if necessary.
> >
> > I've given that a quick look, and I'll bet it's something very
> > easily and safely fixed by a much simpler patch, to mm/msync.c alone,
> > than by all the dirty pages rework and attendant unresolved problems.
>
> How quickly I forget! It wasn't until I looked into the git history
> that I remembered how I'd discovered this already, just before 2.6.17
> went out; but thought myself likely to introduce a more serious bug
> if I tried to fix it in a hurry. (Then forgot to send in a fix for
> 2.6.18, expecting Linus to put in Peter's more significant mods.)
>
> So beware of the fix below, which I'll confess to not even having
> tested in practice: please review carefully, it's a confusing loop
> (rather like the mincore one which Linus has just cleaned up in
> 2.6.20-rc); and it took me a while to decide which of our many
> versions of that loop to start from in fixing it - chose to
> rely on what I'd worked out earlier when redoing it for 2.6.19.
>
> Material for -stable? Well, my judgement was, and is, not really:
> the 2.6.17/2.6.18 behaviour isn't quite right, but though it doesn't
> match the man page and that testsuite, what it does isn't actually
> harmful at all. If this patch is more acceptable to Debian if it
> does appear in -stable, I can try sending it to Chris and Greg:
> but I won't be able to argue for it very forcefully.
I think it would make sense to have it in an -stable update because
it's a regression from 2.6.16 after all and it means that 2.6.17 and
2.6.18 are not LSB 3.1 compliant. However, I don't have a strong
opinion about it and I'm not sure another update for 2.6.18 is
planned.
> Maybe better for you to consider it as just a subpatch of what went
> into 2.6.19, which I was wrong to have mixed in with Peter's work.
>
> I certainly think that this patch below (if it satisfies your review
> and testing) is much more suitable for Debian's 2.6.18 than Peter's
> suite of patches. Not to put those down at all: the reverse, they're
> a significant contribution to 2.6.19, which just wouldn't be expected
> in any 2.6.18 kernel (and sadly, as you've found, are exposing still
> unexplained problems there). Anyway, the patch and its comment...
Yes, I agree. I'm CCing the linux-mm list in hope that someone can
review your patch. In the meantime, I've asked the Debian LSB folks to
verify that your patch fixes the LSB problem.
From: Hugh Dickins <[EMAIL PROTECTED]>
Fix 2.6.18 (or 2.6.17) sys_msync to report -ENOMEM as before when an
unmapped area falls within its range, and not to overshoot: to satisfy
LSB 3.1 tests and to fix Debian Bug#394392. Took the 2.6.19 sys_msync
as starting point (including its cleanup of repeated "current->mm"s),
reintroducing the msync_interval and balance_dirty_pages_ratelimited_nr
previously needed.
Signed-off-by: Hugh Dickins <[EMAIL PROTECTED]>
---
mm/msync.c | 66 +++--
1 file changed, 30 insertions(+), 36 deletions(-)
--- 2.6.18/mm/msync.c 2006-09-20 04:42:06.0 +0100
+++ linux/mm/msync.c2006-12-26 23:52:58.0 +
@@ -146,10 +146,10 @@ static int msync_interval(struct vm_area
asmlinkage long sys_msync(unsigned long start, size_t len, int flags)
{
unsigned long end;
+ struct mm_struct *mm = current->mm;
struct vm_area_struct *vma;
int unmapped_error = 0;
int error = -EINVAL;
- int done = 0;
if (flags & ~(MS_ASYNC | MS_INVALIDATE | MS_SYNC))
goto out;
@@ -169,64 +169,58 @@ asmlinkage long sys_msync(unsigned long
* If the interval [start,end) covers some unmapped address ranges,
* just ignore them, but return -ENOMEM at the end.
*/
- down_read(>mm->mmap_sem);
- vma = find_vma(current->mm, start);
- if (!vma) {
- error = -ENOMEM;
- goto out_unlock;
- }
- do {
+ down_read(>mmap_sem);
+ vma = find_vma(mm, start);
+ for (;;) {
unsigned long nr_pages_dirtied = 0;
struct file *file;
+ /* Still start < end. */
+ error = -ENOMEM;
+ if (!vma)
+
Re: Alternative msync() fix for 2.6.18?
CCing linux-kernel since Hugh's patch might be of interest to
non-Debian people too. This message concerns a problem with msync()
in 2.6.17 and 2.6.18 that can be found with the LSB test suite.
* Hugh Dickins [EMAIL PROTECTED] [2006-12-27 01:04]:
On Tue, 26 Dec 2006, Hugh Dickins wrote:
On Tue, 26 Dec 2006, Martin Michlmayr wrote:
The first message at http://bugs.debian.org/394392 contains some
information about it, but I'm sure Jeff Licquia (CCed) can provide
more information if necessary.
I've given that a quick look, and I'll bet it's something very
easily and safely fixed by a much simpler patch, to mm/msync.c alone,
than by all the dirty pages rework and attendant unresolved problems.
How quickly I forget! It wasn't until I looked into the git history
that I remembered how I'd discovered this already, just before 2.6.17
went out; but thought myself likely to introduce a more serious bug
if I tried to fix it in a hurry. (Then forgot to send in a fix for
2.6.18, expecting Linus to put in Peter's more significant mods.)
So beware of the fix below, which I'll confess to not even having
tested in practice: please review carefully, it's a confusing loop
(rather like the mincore one which Linus has just cleaned up in
2.6.20-rc); and it took me a while to decide which of our many
versions of that loop to start from in fixing it - chose to
rely on what I'd worked out earlier when redoing it for 2.6.19.
Material for -stable? Well, my judgement was, and is, not really:
the 2.6.17/2.6.18 behaviour isn't quite right, but though it doesn't
match the man page and that testsuite, what it does isn't actually
harmful at all. If this patch is more acceptable to Debian if it
does appear in -stable, I can try sending it to Chris and Greg:
but I won't be able to argue for it very forcefully.
I think it would make sense to have it in an -stable update because
it's a regression from 2.6.16 after all and it means that 2.6.17 and
2.6.18 are not LSB 3.1 compliant. However, I don't have a strong
opinion about it and I'm not sure another update for 2.6.18 is
planned.
Maybe better for you to consider it as just a subpatch of what went
into 2.6.19, which I was wrong to have mixed in with Peter's work.
I certainly think that this patch below (if it satisfies your review
and testing) is much more suitable for Debian's 2.6.18 than Peter's
suite of patches. Not to put those down at all: the reverse, they're
a significant contribution to 2.6.19, which just wouldn't be expected
in any 2.6.18 kernel (and sadly, as you've found, are exposing still
unexplained problems there). Anyway, the patch and its comment...
Yes, I agree. I'm CCing the linux-mm list in hope that someone can
review your patch. In the meantime, I've asked the Debian LSB folks to
verify that your patch fixes the LSB problem.
From: Hugh Dickins [EMAIL PROTECTED]
Fix 2.6.18 (or 2.6.17) sys_msync to report -ENOMEM as before when an
unmapped area falls within its range, and not to overshoot: to satisfy
LSB 3.1 tests and to fix Debian Bug#394392. Took the 2.6.19 sys_msync
as starting point (including its cleanup of repeated current-mms),
reintroducing the msync_interval and balance_dirty_pages_ratelimited_nr
previously needed.
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
---
mm/msync.c | 66 +++--
1 file changed, 30 insertions(+), 36 deletions(-)
--- 2.6.18/mm/msync.c 2006-09-20 04:42:06.0 +0100
+++ linux/mm/msync.c2006-12-26 23:52:58.0 +
@@ -146,10 +146,10 @@ static int msync_interval(struct vm_area
asmlinkage long sys_msync(unsigned long start, size_t len, int flags)
{
unsigned long end;
+ struct mm_struct *mm = current-mm;
struct vm_area_struct *vma;
int unmapped_error = 0;
int error = -EINVAL;
- int done = 0;
if (flags ~(MS_ASYNC | MS_INVALIDATE | MS_SYNC))
goto out;
@@ -169,64 +169,58 @@ asmlinkage long sys_msync(unsigned long
* If the interval [start,end) covers some unmapped address ranges,
* just ignore them, but return -ENOMEM at the end.
*/
- down_read(current-mm-mmap_sem);
- vma = find_vma(current-mm, start);
- if (!vma) {
- error = -ENOMEM;
- goto out_unlock;
- }
- do {
+ down_read(mm-mmap_sem);
+ vma = find_vma(mm, start);
+ for (;;) {
unsigned long nr_pages_dirtied = 0;
struct file *file;
+ /* Still start end. */
+ error = -ENOMEM;
+ if (!vma)
+ goto out_unlock;
/* Here start vma-vm_end. */
if (start vma-vm_start) {
- unmapped_error = -ENOMEM;
start = vma-vm_start;
- }
- /* Here vma-vm_start = start vma-vm_end
Re: Ok, explained.. (was Re: [PATCH] mm: fix page_mkclean_one)
* Linus Torvalds [EMAIL PROTECTED] [2006-12-29 02:48]: Can anybody get corruption with this thing applied? It goes on top of plain v2.6.20-rc2. It works for me now, both your testcase as well as an installation of Debian on this ARM device. I manually applied the patch to 2.6.19. Thanks. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Ok, explained.. (was Re: [PATCH] mm: fix page_mkclean_one)
* Stephen Clark [EMAIL PROTECTED] [2006-12-29 10:17]:
It works for me now, both your testcase as well as an installation of
Debian on this ARM device. I manually applied the patch to 2.6.19.
Can you post a diff against 2.6.19?
--- a/mm/page-writeback.c 2006-11-29 21:57:37.0 +
+++ b/mm/page-writeback.c 2006-12-29 11:02:55.555147896 +
@@ -893,16 +893,45 @@
{
struct address_space *mapping = page_mapping(page);
- if (mapping) {
+ if (mapping mapping_cap_account_dirty(mapping)) {
+ /*
+* Yes, Virginia, this is indeed insane.
+*
+* We use this sequence to make sure that
+* (a) we account for dirty stats properly
+* (b) we tell the low-level filesystem to
+* mark the whole page dirty if it was
+* dirty in a pagetable. Only to then
+* (c) clean the page again and return 1 to
+* cause the writeback.
+*
+* This way we avoid all nasty races with the
+* dirty bit in multiple places and clearing
+* them concurrently from different threads.
+*
+* Note! Normally the set_page_dirty(page)
+* has no effect on the actual dirty bit - since
+* that will already usually be set. But we
+* need the side effects, and it can help us
+* avoid races.
+*
+* We basically use the page master dirty bit
+* as a serialization point for all the different
+* threds doing their things.
+*
+* FIXME! We still have a race here: if somebody
+* adds the page back to the page tables in
+* between the page_mkclean() and the TestClearPageDirty(),
+* we might have it mapped without the dirty bit set.
+*/
+ if (page_mkclean(page))
+ set_page_dirty(page);
if (TestClearPageDirty(page)) {
- if (mapping_cap_account_dirty(mapping)) {
- page_mkclean(page);
- dec_zone_page_state(page, NR_FILE_DIRTY);
- }
+ dec_zone_page_state(page, NR_FILE_DIRTY);
return 1;
}
return 0;
- }
+ }
return TestClearPageDirty(page);
}
EXPORT_SYMBOL(clear_page_dirty_for_io);
--
Martin Michlmayr
http://www.cyrius.com/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one
* Gordon Farquharson <[EMAIL PROTECTED]> [2006-12-28 07:15]: > Thanks for the fix, Russell. > > I can now trigger the (real) problem by using a 25 MB file (100 << 18) > and the Linksys NSLU2 (ARM, IXP420 processor, 32 MB RAM). Me too (using 100 << 18). Interestingly, I don't seem to get any corruption on a different ARM board, an IOP32x based machine with 128 MB RAM. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one
* Russell King <[EMAIL PROTECTED]> [2006-12-28 10:49]: > > By the way, I just tried it with TARGETSIZE (100 << 12) on a different > > ARM machine (a Thecus N2100 based on an IOP32x chip with 128 MB of > > memory) and I see similar results to that from Gordon: > > Work around the glibc memset() problem by passing nr & 255, and re-run > the test. You're getting false positives. Yeah, I saw your message about this problem after I sent mine. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one
* Gordon Farquharson <[EMAIL PROTECTED]> [2006-12-27 22:38]: > >> #define TARGETSIZE (100 << 12) > > > >That's just 400kB! > > > >There's no way you should see corruption with that kind of value. It > >should all stay solidly in the cache. > > > >Is this perhaps with ARM nommu or something else strange? It may be that > >the program just doesn't work at all if mmap() is faked out with a malloc > >or similar. > > Definitely a question for the ARM gurus. I'm out of my depth. By the way, I just tried it with TARGETSIZE (100 << 12) on a different ARM machine (a Thecus N2100 based on an IOP32x chip with 128 MB of memory) and I see similar results to that from Gordon: Writing chunk 279/280 (99%) Chunk 256 corrupted (1-1455) (1025-2479) Expected 0, got 1 Written as (199)43(184) Chunk 258 corrupted (1-1455) (3945-1303) Expected 2, got 3 Written as (184)74(145) Chunk 260 corrupted (1-1455) (2769-127) Expected 4, got 5 Written as (145)89(237) Chunk 262 corrupted (1-1455) (1593-3047) Expected 6, got 7 Written as (237)168(174) Chunk 264 corrupted (1-1455) (417-1871) Expected 8, got 9 Written as (174)135(161) Chunk 266 corrupted (1-1455) (3337-695) Expected 10, got 11 Written as (161)123(180) Chunk 268 corrupted (1-1455) (2161-3615) Expected 12, got 13 Written as (180)13(19) Chunk 270 corrupted (1-1455) (985-2439) Expected 14, got 15 Written as (19)172(106) Chunk 272 corrupted (1-1455) (3905-1263) Expected 16, got 17 Written as (106)212(140) Chunk 274 corrupted (1-1455) (2729-87) Expected 18, got 19 Written as (140)124(73) Chunk 276 corrupted (1-1455) (1553-3007) Expected 20, got 21 Written as (73)151(52) Chunk 278 corrupted (1-1455) (377-1831) Expected 22, got 23 Written as (52)215(99) Checking chunk 279/280 (99%) -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one
* Gordon Farquharson <[EMAIL PROTECTED]> [2006-12-27 22:38]: > >That's just 400kB! > > > >There's no way you should see corruption with that kind of value. It > >should all stay solidly in the cache. > > > >Is this perhaps with ARM nommu or something else strange? It may be that > >the program just doesn't work at all if mmap() is faked out with a malloc > >or similar. > > Definitely a question for the ARM gurus. I'm out of my depth. The CPU has a MMU. For reference, it's a IXP4xx based device with 32 MB of memory. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one
* Gordon Farquharson [EMAIL PROTECTED] [2006-12-27 22:38]: That's just 400kB! There's no way you should see corruption with that kind of value. It should all stay solidly in the cache. Is this perhaps with ARM nommu or something else strange? It may be that the program just doesn't work at all if mmap() is faked out with a malloc or similar. Definitely a question for the ARM gurus. I'm out of my depth. The CPU has a MMU. For reference, it's a IXP4xx based device with 32 MB of memory. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one
* Gordon Farquharson [EMAIL PROTECTED] [2006-12-27 22:38]: #define TARGETSIZE (100 12) That's just 400kB! There's no way you should see corruption with that kind of value. It should all stay solidly in the cache. Is this perhaps with ARM nommu or something else strange? It may be that the program just doesn't work at all if mmap() is faked out with a malloc or similar. Definitely a question for the ARM gurus. I'm out of my depth. By the way, I just tried it with TARGETSIZE (100 12) on a different ARM machine (a Thecus N2100 based on an IOP32x chip with 128 MB of memory) and I see similar results to that from Gordon: Writing chunk 279/280 (99%) Chunk 256 corrupted (1-1455) (1025-2479) Expected 0, got 1 Written as (199)43(184) Chunk 258 corrupted (1-1455) (3945-1303) Expected 2, got 3 Written as (184)74(145) Chunk 260 corrupted (1-1455) (2769-127) Expected 4, got 5 Written as (145)89(237) Chunk 262 corrupted (1-1455) (1593-3047) Expected 6, got 7 Written as (237)168(174) Chunk 264 corrupted (1-1455) (417-1871) Expected 8, got 9 Written as (174)135(161) Chunk 266 corrupted (1-1455) (3337-695) Expected 10, got 11 Written as (161)123(180) Chunk 268 corrupted (1-1455) (2161-3615) Expected 12, got 13 Written as (180)13(19) Chunk 270 corrupted (1-1455) (985-2439) Expected 14, got 15 Written as (19)172(106) Chunk 272 corrupted (1-1455) (3905-1263) Expected 16, got 17 Written as (106)212(140) Chunk 274 corrupted (1-1455) (2729-87) Expected 18, got 19 Written as (140)124(73) Chunk 276 corrupted (1-1455) (1553-3007) Expected 20, got 21 Written as (73)151(52) Chunk 278 corrupted (1-1455) (377-1831) Expected 22, got 23 Written as (52)215(99) Checking chunk 279/280 (99%) -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one
* Russell King [EMAIL PROTECTED] [2006-12-28 10:49]: By the way, I just tried it with TARGETSIZE (100 12) on a different ARM machine (a Thecus N2100 based on an IOP32x chip with 128 MB of memory) and I see similar results to that from Gordon: Work around the glibc memset() problem by passing nr 255, and re-run the test. You're getting false positives. Yeah, I saw your message about this problem after I sent mine. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one
* Gordon Farquharson [EMAIL PROTECTED] [2006-12-28 07:15]: Thanks for the fix, Russell. I can now trigger the (real) problem by using a 25 MB file (100 18) and the Linksys NSLU2 (ARM, IXP420 processor, 32 MB RAM). Me too (using 100 18). Interestingly, I don't seem to get any corruption on a different ARM board, an IOP32x based machine with 128 MB RAM. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
* Linus Torvalds <[EMAIL PROTECTED]> [2006-12-24 11:35]: > And if this doesn't fix it, I don't know what will.. Sorry, but it still fails (on top of plain 2.6.19). -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
* Andrew Morton <[EMAIL PROTECTED]> [2006-12-24 00:57]: > /etc/fstab: ext2 nobh > /etc/fstab: ext3 data=writeback,nobh It seems that busybox mount ignores the nobh option but both ext2 and ext3 data=writeback work for me. This is with plain 2.6.19 which normally always fails. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
* Andrew Morton [EMAIL PROTECTED] [2006-12-24 00:57]: /etc/fstab: ext2 nobh /etc/fstab: ext3 data=writeback,nobh It seems that busybox mount ignores the nobh option but both ext2 and ext3 data=writeback work for me. This is with plain 2.6.19 which normally always fails. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
* Linus Torvalds [EMAIL PROTECTED] [2006-12-24 11:35]: And if this doesn't fix it, I don't know what will.. Sorry, but it still fails (on top of plain 2.6.19). -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
* Peter Zijlstra <[EMAIL PROTECTED]> [2006-12-22 14:25]:
> > and it failed.
> Since you are on ARM you might want to try with the page_mkclean_one
> cleanup patch too.
I've already tried it and it didn't work. I just tried it again
together with Linus' patch and the two from Andrew and it still fails.
(For reference, the patch is attached.)
--
Martin Michlmayr
http://www.cyrius.com/
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -2834,7 +2834,7 @@ int try_to_free_buffers(struct page *pag
int ret = 0;
BUG_ON(!PageLocked(page));
- if (PageWriteback(page))
+ if (PageDirty(page) || PageWriteback(page))
return 0;
if (mapping == NULL) { /* can this still happen? */
@@ -2845,22 +2845,6 @@ int try_to_free_buffers(struct page *pag
spin_lock(>private_lock);
ret = drop_buffers(page, _to_free);
spin_unlock(>private_lock);
- if (ret) {
- /*
-* If the filesystem writes its buffers by hand (eg ext3)
-* then we can have clean buffers against a dirty page. We
-* clean the page here; otherwise later reattachment of buffers
-* could encounter a non-uptodate page, which is unresolvable.
-* This only applies in the rare case where try_to_free_buffers
-* succeeds but the page is not freed.
-*
-* Also, during truncate, discard_buffer will have marked all
-* the page's buffers clean. We discover that here and clean
-* the page also.
-*/
- if (test_clear_page_dirty(page))
- task_io_account_cancelled_write(PAGE_CACHE_SIZE);
- }
out:
if (buffers_to_free) {
struct buffer_head *bh = buffers_to_free;
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index ed2c223..4f4cd13 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -176,7 +176,7 @@ static int hugetlbfs_commit_write(struct
static void truncate_huge_page(struct page *page)
{
- clear_page_dirty(page);
+ cancel_dirty_page(page, /* No IO accounting for huge pages? */0);
ClearPageUptodate(page);
remove_from_page_cache(page);
put_page(page);
diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
index 4830a3b..350878a 100644
--- a/include/linux/page-flags.h
+++ b/include/linux/page-flags.h
@@ -253,15 +253,11 @@ #define ClearPageUncached(page) clear_bi
struct page; /* forward declaration */
-int test_clear_page_dirty(struct page *page);
+extern void cancel_dirty_page(struct page *page, unsigned int account_size);
+
int test_clear_page_writeback(struct page *page);
int test_set_page_writeback(struct page *page);
-static inline void clear_page_dirty(struct page *page)
-{
- test_clear_page_dirty(page);
-}
-
static inline void set_page_writeback(struct page *page)
{
test_set_page_writeback(page);
diff --git a/mm/memory.c b/mm/memory.c
index c00bac6..79cecab 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1842,6 +1842,33 @@ void unmap_mapping_range(struct address_
}
EXPORT_SYMBOL(unmap_mapping_range);
+static void check_last_page(struct address_space *mapping, loff_t size)
+{
+ pgoff_t index;
+ unsigned int offset;
+ struct page *page;
+
+ if (!mapping)
+ return;
+ offset = size & ~PAGE_MASK;
+ if (!offset)
+ return;
+ index = size >> PAGE_SHIFT;
+ page = find_lock_page(mapping, index);
+ if (page) {
+ unsigned int check = 0;
+ unsigned char *kaddr = kmap_atomic(page, KM_USER0);
+ do {
+ check += kaddr[offset++];
+ } while (offset < PAGE_SIZE);
+ kunmap_atomic(kaddr,KM_USER0);
+ unlock_page(page);
+ page_cache_release(page);
+ if (check)
+ printk("%s: BADNESS: truncate check %u\n",
current->comm, check);
+ }
+}
+
/**
* vmtruncate - unmap mappings "freed" by truncate() syscall
* @inode: inode of the file used
@@ -1875,6 +1902,7 @@ do_expand:
goto out_sig;
if (offset > inode->i_sb->s_maxbytes)
goto out_big;
+ check_last_page(mapping, inode->i_size);
i_size_write(inode, offset);
out_truncate:
diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index 237107c..b3a198c 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -845,38 +845,6 @@ int set_page_dirty_lock(struct page *pag
EXPORT_SYMBOL(set_page_dirty_lock);
/*
- * Clear a page's dirty flag, while caring for dirty memory accounting.
- * Returns true if the page was previously dirty.
- */
-int test_clear_page_dirty(struct page *page)
-{
- struct address_space *mapping = page_mapping(page);
-
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
* Gordon Farquharson <[EMAIL PROTECTED]> [2006-12-22 08:30]: > Based on the kernel gurus current knowledge of the problem, would > you expect the corruption to occur at the same point in a file, or > is it possible that the corruption could occur at different points > on successive Debian installer attempts on a UP, non PREEMPT system? Seems like it can occur anywhere. In fact, some people see apt problems because of filesystem corruption on the NSLU2 after they have already installe Debian. I've only seen this once myself and failed many times to find a reproducible situation. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
* Martin Michlmayr <[EMAIL PROTECTED]> [2006-12-22 13:32]: > I've completed one installation with Linus' patch plus the two from > Andrew successfully, but I'm currently trying again... ... and it failed. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
* Andrei Popa <[EMAIL PROTECTED]> [2006-12-22 14:24]: > With all three patches I have corruption I've completed one installation with Linus' patch plus the two from Andrew successfully, but I'm currently trying again... but I really need a better testcase since an installation takes about an hour. Andrei, which torrent do you download as a testcase? It would be good if someone could suggest a torrent which is legal and not too large. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
* Andrew Morton <[EMAIL PROTECTED]> [2006-12-22 02:17]: > > This hunk (on top of git from about 2 days ago and your latest patch) > > results in the installer hanging right at the start. > > You'll need this also: It starts again, thanks. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
* Martin Michlmayr <[EMAIL PROTECTED]> [2006-12-22 11:10]: > > immediately when I started wget, the hanging apt-get process > > continued. > ... and now that we've completed this step, the apt cache has suddenly > been reduced (see Gordon's mail for an explanation) and it segfaults: One of my questions was why apt-get worked to install the initramfs-tools, the kernel and some other packages but later hung while it was building the cache (which clearly it had built already to install some packages): before the installer offers to install additional packages, it changes the apt sources, which leads to apt rebuilding the cache, and here it hangs. Remember how I said that downloading a file with wget prompts apt to work again? Apparently any filesystem access will do (I just ran find / > /dev/null). Gordon, can you confirm this? -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
* Martin Michlmayr <[EMAIL PROTECTED]> [2006-12-22 11:06]: > Okay, it's really weird. So apt-get just hangs doing nothing and I > cannot even kill it. I just tried to download strace via wget and > immediately when I started wget, the hanging apt-get process > continued. ... and now that we've completed this step, the apt cache has suddenly been reduced (see Gordon's mail for an explanation) and it segfaults: sh-3.1# ls -l /var/cache/apt/ total 12524 drwxr-xr-x 3 root root 12288 Dec 22 04:41 archives -rw-r--r-- 1 root root 6426885 Dec 22 05:03 pkgcache.bin -rw-r--r-- 1 root root 6426835 Dec 22 05:03 srcpkgcache.bin sh-3.1# apt-get -f install Reading package lists... Done Segmentation faulty tree... 50% -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
* Martin Michlmayr <[EMAIL PROTECTED]> [2006-12-22 11:00]: > This time, however, I let the installer continue and it seems that > with your patch apt now works where it failed in the past, but it > hangs later on. It's pretty weird because I cannot even kill the > process: Okay, it's really weird. So apt-get just hangs doing nothing and I cannot even kill it. I just tried to download strace via wget and immediately when I started wget, the hanging apt-get process continued. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
* Gordon Farquharson <[EMAIL PROTECTED]> [2006-12-21 21:20]: > generating these files, pkgcache.bin grows to 12582912 bytes, and when > apt-get finishes, pkgcache.bin is 6425533 bytes and srcpkgcache.bin is > 64254483 bytes. This time, when apt-get exited, it had only created > pkgcache.bin which was still 12582912 bytes. Yes, same here: sh-3.1# ls -l /var/cache/apt/ total 5252 drwxr-xr-x 3 root root12288 Dec 22 04:41 archives -rw-r--r-- 1 root root 12582912 Dec 22 04:45 pkgcache.bin -rw-r--r-- 1 root root 8554 Dec 22 04:45 srcpkgcache.bin Gordon, does it fail for you where it normally does (installing initramfs-tools) or much later? For me, the installer was able to install initramfs-tools and the kernel, but apt now hangs at "Select and install software". -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
* Linus Torvalds <[EMAIL PROTECTED]> [2006-12-21 20:54]:
> But it sounds like I probably misunderstood something, because I thought
> that Martin had acknowledged that this patch actually worked for him.
That's what I thought too but now I can confirm what Gordon sees. But
it's pretty weird. Our testcase is to run Debian installer on the
NSLU2 arm device and apt-get would either segfault or hang at this
particular spot in the installation (when apt is first run). With
your patch, apt works correctly where it normally fails (at least for
me). I stopped the installation at this point and repeated it several
more times to make sure it's really working. And, yes, I can repeat
this result.
This time, however, I let the installer continue and it seems that
with your patch apt now works where it failed in the past, but it
hangs later on. It's pretty weird because I cannot even kill the
process:
sh-3.1# ps aux | grep 31126
root 31126 5.7 20.6 16240 6076 ?R+ 04:45 0:21 apt-get -o
APT::Status-Fd=4 -o APT::Keep-Fds::=5 -o APT::Keep-Fds::=6 -q -y -f install
popularity-contest
root 31157 0.0 1.6 1516 492 ttyS0S+ 04:51 0:00 grep 31126
sh-3.1# kill -9 31126
sh-3.1# kill -9 31126
sh-3.1# ps aux | grep 31126
root 31126 5.6 20.6 16240 6076 ?R+ 04:45 0:21 apt-get -o
APT::Status-Fd=4 -o APT::Keep-Fds::=5 -o APT::Keep-Fds::=6 -q -y -f install
popularity-contest
root 31159 0.0 1.6 1516 492 ttyS0S+ 04:51 0:00 grep 31126
sh-3.1#
> Which sounded very similar to your setup (he has a 32M ARM box too, no?)
It's the same device, a Linksys NSLU2.
> Author: Andrew Morton <[EMAIL PROTECTED]>
This patch makes it even worse for me.
> - if (TestClearPageDirty(page) && account_size)
> + if (TestClearPageDirty(page) && account_size) {
> + dec_zone_page_state(page, NR_FILE_DIRTY);
> task_io_account_cancelled_write(account_size);
> + }
This hunk (on top of git from about 2 days ago and your latest patch)
results in the installer hanging right at the start. The Linux kernel
boots fine, the debian-installer is loaded into a ramdisk but when
ncurses is being started it just hangs. Reverting this hunk makes it
start again.
Does that help or confuse you even more?
--
Martin Michlmayr
http://www.cyrius.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
* Linus Torvalds [EMAIL PROTECTED] [2006-12-21 20:54]:
But it sounds like I probably misunderstood something, because I thought
that Martin had acknowledged that this patch actually worked for him.
That's what I thought too but now I can confirm what Gordon sees. But
it's pretty weird. Our testcase is to run Debian installer on the
NSLU2 arm device and apt-get would either segfault or hang at this
particular spot in the installation (when apt is first run). With
your patch, apt works correctly where it normally fails (at least for
me). I stopped the installation at this point and repeated it several
more times to make sure it's really working. And, yes, I can repeat
this result.
This time, however, I let the installer continue and it seems that
with your patch apt now works where it failed in the past, but it
hangs later on. It's pretty weird because I cannot even kill the
process:
sh-3.1# ps aux | grep 31126
root 31126 5.7 20.6 16240 6076 ?R+ 04:45 0:21 apt-get -o
APT::Status-Fd=4 -o APT::Keep-Fds::=5 -o APT::Keep-Fds::=6 -q -y -f install
popularity-contest
root 31157 0.0 1.6 1516 492 ttyS0S+ 04:51 0:00 grep 31126
sh-3.1# kill -9 31126
sh-3.1# kill -9 31126
sh-3.1# ps aux | grep 31126
root 31126 5.6 20.6 16240 6076 ?R+ 04:45 0:21 apt-get -o
APT::Status-Fd=4 -o APT::Keep-Fds::=5 -o APT::Keep-Fds::=6 -q -y -f install
popularity-contest
root 31159 0.0 1.6 1516 492 ttyS0S+ 04:51 0:00 grep 31126
sh-3.1#
Which sounded very similar to your setup (he has a 32M ARM box too, no?)
It's the same device, a Linksys NSLU2.
Author: Andrew Morton [EMAIL PROTECTED]
This patch makes it even worse for me.
- if (TestClearPageDirty(page) account_size)
+ if (TestClearPageDirty(page) account_size) {
+ dec_zone_page_state(page, NR_FILE_DIRTY);
task_io_account_cancelled_write(account_size);
+ }
This hunk (on top of git from about 2 days ago and your latest patch)
results in the installer hanging right at the start. The Linux kernel
boots fine, the debian-installer is loaded into a ramdisk but when
ncurses is being started it just hangs. Reverting this hunk makes it
start again.
Does that help or confuse you even more?
--
Martin Michlmayr
http://www.cyrius.com/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
* Gordon Farquharson [EMAIL PROTECTED] [2006-12-21 21:20]: generating these files, pkgcache.bin grows to 12582912 bytes, and when apt-get finishes, pkgcache.bin is 6425533 bytes and srcpkgcache.bin is 64254483 bytes. This time, when apt-get exited, it had only created pkgcache.bin which was still 12582912 bytes. Yes, same here: sh-3.1# ls -l /var/cache/apt/ total 5252 drwxr-xr-x 3 root root12288 Dec 22 04:41 archives -rw-r--r-- 1 root root 12582912 Dec 22 04:45 pkgcache.bin -rw-r--r-- 1 root root 8554 Dec 22 04:45 srcpkgcache.bin Gordon, does it fail for you where it normally does (installing initramfs-tools) or much later? For me, the installer was able to install initramfs-tools and the kernel, but apt now hangs at Select and install software. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
* Martin Michlmayr [EMAIL PROTECTED] [2006-12-22 11:00]: This time, however, I let the installer continue and it seems that with your patch apt now works where it failed in the past, but it hangs later on. It's pretty weird because I cannot even kill the process: Okay, it's really weird. So apt-get just hangs doing nothing and I cannot even kill it. I just tried to download strace via wget and immediately when I started wget, the hanging apt-get process continued. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
* Martin Michlmayr [EMAIL PROTECTED] [2006-12-22 11:06]: Okay, it's really weird. So apt-get just hangs doing nothing and I cannot even kill it. I just tried to download strace via wget and immediately when I started wget, the hanging apt-get process continued. ... and now that we've completed this step, the apt cache has suddenly been reduced (see Gordon's mail for an explanation) and it segfaults: sh-3.1# ls -l /var/cache/apt/ total 12524 drwxr-xr-x 3 root root 12288 Dec 22 04:41 archives -rw-r--r-- 1 root root 6426885 Dec 22 05:03 pkgcache.bin -rw-r--r-- 1 root root 6426835 Dec 22 05:03 srcpkgcache.bin sh-3.1# apt-get -f install Reading package lists... Done Segmentation faulty tree... 50% -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
* Martin Michlmayr [EMAIL PROTECTED] [2006-12-22 11:10]: immediately when I started wget, the hanging apt-get process continued. ... and now that we've completed this step, the apt cache has suddenly been reduced (see Gordon's mail for an explanation) and it segfaults: One of my questions was why apt-get worked to install the initramfs-tools, the kernel and some other packages but later hung while it was building the cache (which clearly it had built already to install some packages): before the installer offers to install additional packages, it changes the apt sources, which leads to apt rebuilding the cache, and here it hangs. Remember how I said that downloading a file with wget prompts apt to work again? Apparently any filesystem access will do (I just ran find / /dev/null). Gordon, can you confirm this? -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
* Andrew Morton [EMAIL PROTECTED] [2006-12-22 02:17]: This hunk (on top of git from about 2 days ago and your latest patch) results in the installer hanging right at the start. You'll need this also: It starts again, thanks. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
* Andrei Popa [EMAIL PROTECTED] [2006-12-22 14:24]: With all three patches I have corruption I've completed one installation with Linus' patch plus the two from Andrew successfully, but I'm currently trying again... but I really need a better testcase since an installation takes about an hour. Andrei, which torrent do you download as a testcase? It would be good if someone could suggest a torrent which is legal and not too large. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
* Martin Michlmayr [EMAIL PROTECTED] [2006-12-22 13:32]: I've completed one installation with Linus' patch plus the two from Andrew successfully, but I'm currently trying again... ... and it failed. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
* Gordon Farquharson [EMAIL PROTECTED] [2006-12-22 08:30]: Based on the kernel gurus current knowledge of the problem, would you expect the corruption to occur at the same point in a file, or is it possible that the corruption could occur at different points on successive Debian installer attempts on a UP, non PREEMPT system? Seems like it can occur anywhere. In fact, some people see apt problems because of filesystem corruption on the NSLU2 after they have already installe Debian. I've only seen this once myself and failed many times to find a reproducible situation. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
* Peter Zijlstra [EMAIL PROTECTED] [2006-12-22 14:25]:
and it failed.
Since you are on ARM you might want to try with the page_mkclean_one
cleanup patch too.
I've already tried it and it didn't work. I just tried it again
together with Linus' patch and the two from Andrew and it still fails.
(For reference, the patch is attached.)
--
Martin Michlmayr
http://www.cyrius.com/
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -2834,7 +2834,7 @@ int try_to_free_buffers(struct page *pag
int ret = 0;
BUG_ON(!PageLocked(page));
- if (PageWriteback(page))
+ if (PageDirty(page) || PageWriteback(page))
return 0;
if (mapping == NULL) { /* can this still happen? */
@@ -2845,22 +2845,6 @@ int try_to_free_buffers(struct page *pag
spin_lock(mapping-private_lock);
ret = drop_buffers(page, buffers_to_free);
spin_unlock(mapping-private_lock);
- if (ret) {
- /*
-* If the filesystem writes its buffers by hand (eg ext3)
-* then we can have clean buffers against a dirty page. We
-* clean the page here; otherwise later reattachment of buffers
-* could encounter a non-uptodate page, which is unresolvable.
-* This only applies in the rare case where try_to_free_buffers
-* succeeds but the page is not freed.
-*
-* Also, during truncate, discard_buffer will have marked all
-* the page's buffers clean. We discover that here and clean
-* the page also.
-*/
- if (test_clear_page_dirty(page))
- task_io_account_cancelled_write(PAGE_CACHE_SIZE);
- }
out:
if (buffers_to_free) {
struct buffer_head *bh = buffers_to_free;
diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
index ed2c223..4f4cd13 100644
--- a/fs/hugetlbfs/inode.c
+++ b/fs/hugetlbfs/inode.c
@@ -176,7 +176,7 @@ static int hugetlbfs_commit_write(struct
static void truncate_huge_page(struct page *page)
{
- clear_page_dirty(page);
+ cancel_dirty_page(page, /* No IO accounting for huge pages? */0);
ClearPageUptodate(page);
remove_from_page_cache(page);
put_page(page);
diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
index 4830a3b..350878a 100644
--- a/include/linux/page-flags.h
+++ b/include/linux/page-flags.h
@@ -253,15 +253,11 @@ #define ClearPageUncached(page) clear_bi
struct page; /* forward declaration */
-int test_clear_page_dirty(struct page *page);
+extern void cancel_dirty_page(struct page *page, unsigned int account_size);
+
int test_clear_page_writeback(struct page *page);
int test_set_page_writeback(struct page *page);
-static inline void clear_page_dirty(struct page *page)
-{
- test_clear_page_dirty(page);
-}
-
static inline void set_page_writeback(struct page *page)
{
test_set_page_writeback(page);
diff --git a/mm/memory.c b/mm/memory.c
index c00bac6..79cecab 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1842,6 +1842,33 @@ void unmap_mapping_range(struct address_
}
EXPORT_SYMBOL(unmap_mapping_range);
+static void check_last_page(struct address_space *mapping, loff_t size)
+{
+ pgoff_t index;
+ unsigned int offset;
+ struct page *page;
+
+ if (!mapping)
+ return;
+ offset = size ~PAGE_MASK;
+ if (!offset)
+ return;
+ index = size PAGE_SHIFT;
+ page = find_lock_page(mapping, index);
+ if (page) {
+ unsigned int check = 0;
+ unsigned char *kaddr = kmap_atomic(page, KM_USER0);
+ do {
+ check += kaddr[offset++];
+ } while (offset PAGE_SIZE);
+ kunmap_atomic(kaddr,KM_USER0);
+ unlock_page(page);
+ page_cache_release(page);
+ if (check)
+ printk(%s: BADNESS: truncate check %u\n,
current-comm, check);
+ }
+}
+
/**
* vmtruncate - unmap mappings freed by truncate() syscall
* @inode: inode of the file used
@@ -1875,6 +1902,7 @@ do_expand:
goto out_sig;
if (offset inode-i_sb-s_maxbytes)
goto out_big;
+ check_last_page(mapping, inode-i_size);
i_size_write(inode, offset);
out_truncate:
diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index 237107c..b3a198c 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -845,38 +845,6 @@ int set_page_dirty_lock(struct page *pag
EXPORT_SYMBOL(set_page_dirty_lock);
/*
- * Clear a page's dirty flag, while caring for dirty memory accounting.
- * Returns true if the page was previously dirty.
- */
-int test_clear_page_dirty(struct page *page)
-{
- struct address_space *mapping = page_mapping(page);
- unsigned long flags;
-
- if (!mapping)
- return
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
* Linus Torvalds <[EMAIL PROTECTED]> [2006-12-20 11:50]: > Martin, Andrei, does this make any difference for your corruption > cases? Works for me. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
* Linus Torvalds <[EMAIL PROTECTED]> [2006-12-20 23:53]: > > Unfortunately, I cannot get the latest git version of the kernel to > > boot on the ARM machine on which Martin and I are experiencing the apt > > segfault. > > Ouch. > > That's obviously a bug worth fixing on its own. Do you know when it > started? This is a known issue. The following patch has been proposed http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=4030/1 although I just notice that it has been marked as "discarded". Apparently Russell King commited a better patch so this should be fixed in git when he sends his next pull request. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
* Russell King <[EMAIL PROTECTED]> [2006-12-20 22:11]: > > This patch doesn't fix my problem (apt segfaults on ARM because its > > database is corrupted). > > Are you using IDE in PIO mode? If so, the bug probably lies there. I'm using usb-storage. It's used to access an external IDE drive in an USB enclosure but I don't think it matters that it's IDE since we're using the SCSI layer to talk to it, right? -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
* Russell King [EMAIL PROTECTED] [2006-12-20 22:11]: This patch doesn't fix my problem (apt segfaults on ARM because its database is corrupted). Are you using IDE in PIO mode? If so, the bug probably lies there. I'm using usb-storage. It's used to access an external IDE drive in an USB enclosure but I don't think it matters that it's IDE since we're using the SCSI layer to talk to it, right? -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
* Linus Torvalds [EMAIL PROTECTED] [2006-12-20 23:53]: Unfortunately, I cannot get the latest git version of the kernel to boot on the ARM machine on which Martin and I are experiencing the apt segfault. Ouch. That's obviously a bug worth fixing on its own. Do you know when it started? This is a known issue. The following patch has been proposed http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=4030/1 although I just notice that it has been marked as discarded. Apparently Russell King commited a better patch so this should be fixed in git when he sends his next pull request. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
* Linus Torvalds [EMAIL PROTECTED] [2006-12-20 11:50]: Martin, Andrei, does this make any difference for your corruption cases? Works for me. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
* Linus Torvalds <[EMAIL PROTECTED]> [2006-12-20 09:35]: > Can you remind us: > - your ARM is UP, right? Do you have PREEMPT on? It's UP and PREEMPT is not set. I used 2.6.19 plus the patch that has been posted. > - This is probably a stupid question, but you did make sure that the >database was ok (with some rebuild command) and that you didn't have >preexisting corruption? Yes, my test case is to install Debian on the ARM machine so the database is created fresh. While the corruption always triggers during a fresh installation, it's much harder to see in a running system. Some people see it on their system but I haven't found a 100% working recipe to reproduce it yet given a working system; doing a new installation seems to trigger it all the time though. > Anyway, the page_mkclean_one() fixes (along with _most_ things we've > looked at) shouldn't matter on UP, at least certainly not without > PREEMPT. Hmm. So what about UP without PREEMPT then... Maybe the following information is helpful in some way: remember how I said that we have applied 6 mm patches to 2.6.18 in Debian? According to Gordon Farquharson, who's helping me a great deal with testing installation on this ARM machine (Linksys NSLU2), the corruption doesn't always show up when you only apply mm-tracking-shared-dirty-pages.patch to 2.6.18 but it shows up all the time with all six patches applied. As a reminder, the 6 patches we apply are: mm-tracking-shared-dirty-pages.patch mm-balance-dirty-pages.patch mm-optimize-mprotect.patch mm-install_page-cleanup.patch mm-do_wp_page-fixup.patch mm-msync-cleanup.patch -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
* Peter Zijlstra <[EMAIL PROTECTED]> [2006-12-20 14:56]: > page_mkclean_one() fix This patch doesn't fix my problem (apt segfaults on ARM because its database is corrupted). -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
* Peter Zijlstra [EMAIL PROTECTED] [2006-12-20 14:56]: page_mkclean_one() fix This patch doesn't fix my problem (apt segfaults on ARM because its database is corrupted). -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
* Linus Torvalds [EMAIL PROTECTED] [2006-12-20 09:35]: Can you remind us: - your ARM is UP, right? Do you have PREEMPT on? It's UP and PREEMPT is not set. I used 2.6.19 plus the patch that has been posted. - This is probably a stupid question, but you did make sure that the database was ok (with some rebuild command) and that you didn't have preexisting corruption? Yes, my test case is to install Debian on the ARM machine so the database is created fresh. While the corruption always triggers during a fresh installation, it's much harder to see in a running system. Some people see it on their system but I haven't found a 100% working recipe to reproduce it yet given a working system; doing a new installation seems to trigger it all the time though. Anyway, the page_mkclean_one() fixes (along with _most_ things we've looked at) shouldn't matter on UP, at least certainly not without PREEMPT. Hmm. So what about UP without PREEMPT then... Maybe the following information is helpful in some way: remember how I said that we have applied 6 mm patches to 2.6.18 in Debian? According to Gordon Farquharson, who's helping me a great deal with testing installation on this ARM machine (Linksys NSLU2), the corruption doesn't always show up when you only apply mm-tracking-shared-dirty-pages.patch to 2.6.18 but it shows up all the time with all six patches applied. As a reminder, the 6 patches we apply are: mm-tracking-shared-dirty-pages.patch mm-balance-dirty-pages.patch mm-optimize-mprotect.patch mm-install_page-cleanup.patch mm-do_wp_page-fixup.patch mm-msync-cleanup.patch -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19 file content corruption on ext3
* Marc Haber <[EMAIL PROTECTED]> [2006-12-19 09:51]: > I do not have a clue about memory management at all, but is it > possible that you're testing on a box with too much memory? My box has > only 256 MB, and I used to use mutt with a _huge_ inbox with mutt > taking somewhat 150 MB. Add spamassassin and a reasonably busy mail > server, and the box used to be like 150 MB in swap. FWIW, the ARM box I see this on has only 32 MB memory (and a 133 or 266 MHz CPU). I don't see it on another ARM box (different ARM sub-arch) with 128 MB memory and a 600 MHz CPU. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19 file content corruption on ext3
* Marc Haber [EMAIL PROTECTED] [2006-12-19 09:51]: I do not have a clue about memory management at all, but is it possible that you're testing on a box with too much memory? My box has only 256 MB, and I used to use mutt with a _huge_ inbox with mutt taking somewhat 150 MB. Add spamassassin and a reasonably busy mail server, and the box used to be like 150 MB in swap. FWIW, the ARM box I see this on has only 32 MB memory (and a 133 or 266 MHz CPU). I don't see it on another ARM box (different ARM sub-arch) with 128 MB memory and a 600 MHz CPU. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: r8169 on n2100 (was Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions))
* Francois Romieu <[EMAIL PROTECTED]> [2006-12-17 22:48]: > > Francois, if you submit the r8169.c half of that patch, I'll do my half. > Ok, I'll do it now. Thanks to everyone who was involved in coming up with this elegant solution! -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: r8169 on n2100 (was Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions))
* Lennert Buytenhek <[EMAIL PROTECTED]> [2006-12-17 00:52]: > Martin/Riku, I'm pretty busy with other stuff at the moment, can you > give this (on top of 2.6.20-rc1) a spin? I'm currently travelling but I'll try in a few days. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: r8169 on n2100 (was Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions))
* Lennert Buytenhek [EMAIL PROTECTED] [2006-12-17 00:52]: Martin/Riku, I'm pretty busy with other stuff at the moment, can you give this (on top of 2.6.20-rc1) a spin? I'm currently travelling but I'll try in a few days. -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: r8169 on n2100 (was Re: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions))
* Francois Romieu [EMAIL PROTECTED] [2006-12-17 22:48]: Francois, if you submit the r8169.c half of that patch, I'll do my half. Ok, I'll do it now. Thanks to everyone who was involved in coming up with this elegant solution! -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent mm changes leading to filesystem corruption?
* Peter Zijlstra <[EMAIL PROTECTED]> [2006-12-16 21:55]: > What is not clear from all these reports is what architectures this is > seen on. I suspect some of them are i686, which together with the > explicit mention of ARM make it a cross platform issue. Problems have been seen at least on x86, x86_64 and arm. -- Martin Michlmayr [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
