Re: 2.6.19-mm1: gotemp: memset(..., 0) error
On Wed, Dec 13, 2006 at 02:05:59PM +0100, Adrian Bunk wrote: > <-- snip --> > > ... > NOT FOR MAINLINE! > > This is for the driver tutorial I give. It will not be included in the > mainline kernel tree ever. Use the ldusb driver that is already there > instead for this device. > > This is only a teaching tool. > ... > + pkt = kmalloc(sizeof(*pkt), GFP_ATOMIC); > + if (!pkt) > + return -ENOMEM; > + memset(pkt, sizeof(*pkt), 0x00); > ... > > <-- snip --> > > > Lesson 1: > Write an USB driver. > > Lesson 2: > Correct the memset() argument order or use kzalloc(). Heh, thanks, I've now fixed that up in my tree. greg k-h - 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-mm1: gotemp: memset(..., 0) error
On Wed, Dec 13, 2006 at 02:05:59PM +0100, Adrian Bunk wrote: -- snip -- ... NOT FOR MAINLINE! This is for the driver tutorial I give. It will not be included in the mainline kernel tree ever. Use the ldusb driver that is already there instead for this device. This is only a teaching tool. ... + pkt = kmalloc(sizeof(*pkt), GFP_ATOMIC); + if (!pkt) + return -ENOMEM; + memset(pkt, sizeof(*pkt), 0x00); ... -- snip -- Lesson 1: Write an USB driver. Lesson 2: Correct the memset() argument order or use kzalloc(). Heh, thanks, I've now fixed that up in my tree. greg k-h - 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-mm1: missing MTD_UBI* help texts
On Mon, 2006-12-11 at 17:42 +0100, Adrian Bunk wrote: > The MTD_UBI and the MTD_UBI_DEBUG_PARANOID_* options lack help texts. thanks, fixed in our GIT tree. -- Best regards, Artem Bityutskiy (Битюцкий Артём) - 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-mm1: drivers/mtd/ubi/debug.c: unused variable
On Mon, 2006-12-11 at 21:46 +0100, Adrian Bunk wrote: > It doesn't seem to be intended that in ubi_dbg_vprint_nolock() the > variable "caller" is never assigned any value different from 0. > thanks, fixed in our GIT tree. -- Best regards, Artem Bityutskiy (Битюцкий Артём) - 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-mm1 (md/raid1 randomly drops partitions - possible sata_uli problem)
On Wednesday, 13 December 2006 01:53, Neil Brown wrote: > On Tuesday December 12, [EMAIL PROTECTED] wrote: > > > > > > So when md writes to write out the superblock, to gets EIO... Odd that > > > you aren't getting errors for normal writes. > > > > > > What devices are the md/raid1 built on? > > > > Sata drives, on sata_uli. > > > > > > > > > > I'll try to reproduce it tomorrow and collect some more information. > > > > > > Thanks. More information is definitely better than less, so send over > > > anything you can find. > > > > Okay, seems to be readily reproducible, dmesg output from the failing kernel > > attached. > > Weird. You are getting silent write errors... > > Can you write to these drives are all? e.g. > > dd if=/dev/sdb3 of=/tmp/tmp count=1 > dd if=/tmp/tmp of=/dev/sdb3 oflag=direct > > (hopefully 'direct' will cause write errors to be passed up). Unfortunately I have no access to the machine right now. > I really think this looks like a sata problem, not an md problem. That's possible, but everything except for the md RAID seems to work. Strange. I think I'll wait until the next -mm is out and check if the problem goes away. ;-) Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King - 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-mm1 (md/raid1 randomly drops partitions - possible sata_uli problem)
On Wednesday, 13 December 2006 01:53, Neil Brown wrote: On Tuesday December 12, [EMAIL PROTECTED] wrote: So when md writes to write out the superblock, to gets EIO... Odd that you aren't getting errors for normal writes. What devices are the md/raid1 built on? Sata drives, on sata_uli. I'll try to reproduce it tomorrow and collect some more information. Thanks. More information is definitely better than less, so send over anything you can find. Okay, seems to be readily reproducible, dmesg output from the failing kernel attached. Weird. You are getting silent write errors... Can you write to these drives are all? e.g. dd if=/dev/sdb3 of=/tmp/tmp count=1 dd if=/tmp/tmp of=/dev/sdb3 oflag=direct (hopefully 'direct' will cause write errors to be passed up). Unfortunately I have no access to the machine right now. I really think this looks like a sata problem, not an md problem. That's possible, but everything except for the md RAID seems to work. Strange. I think I'll wait until the next -mm is out and check if the problem goes away. ;-) Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King - 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-mm1: drivers/mtd/ubi/debug.c: unused variable
On Mon, 2006-12-11 at 21:46 +0100, Adrian Bunk wrote: It doesn't seem to be intended that in ubi_dbg_vprint_nolock() the variable caller is never assigned any value different from 0. thanks, fixed in our GIT tree. -- Best regards, Artem Bityutskiy (Битюцкий Артём) - 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-mm1: missing MTD_UBI* help texts
On Mon, 2006-12-11 at 17:42 +0100, Adrian Bunk wrote: The MTD_UBI and the MTD_UBI_DEBUG_PARANOID_* options lack help texts. thanks, fixed in our GIT tree. -- Best regards, Artem Bityutskiy (Битюцкий Артём) - 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-mm1
On Wed, 13 Dec 2006 09:17:42 +0800
Conke Hu <[EMAIL PROTECTED]> wrote:
> Thank you for applying ATI SB600 SATA patch!
> But it seems the patch file name should be
> "ati"-sb600-sata-quirk.patch, not "via"-sb600-sata-quirk.patch, type
> error? :)
That's the sort of thing which happens when people send me patches titled
"Re: -mm merge plans for 2.6.20". I guess, and I don't spend a lot of time
over it, either.
> BTW, the following line in ide/pci/atiixp.c had better be removed
> since there would be no legacy ide mode any more after this patch is
> applied.
> "{ PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_IXP600_SATA, PCI_ANY_ID,
> PCI_ANY_ID, (PCI_CLASS_STORAGE_IDE<<8)|0x8a, 0x05, 1},"
please send a patch to fix this.
-
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-mm1 (md/raid1 randomly drops partitions - possible sata_uli problem)
On Tuesday December 12, [EMAIL PROTECTED] wrote: > > > > So when md writes to write out the superblock, to gets EIO... Odd that > > you aren't getting errors for normal writes. > > > > What devices are the md/raid1 built on? > > Sata drives, on sata_uli. > > > > > > > I'll try to reproduce it tomorrow and collect some more information. > > > > Thanks. More information is definitely better than less, so send over > > anything you can find. > > Okay, seems to be readily reproducible, dmesg output from the failing kernel > attached. Weird. You are getting silent write errors... Can you write to these drives are all? e.g. dd if=/dev/sdb3 of=/tmp/tmp count=1 dd if=/tmp/tmp of=/dev/sdb3 oflag=direct (hopefully 'direct' will cause write errors to be passed up). I really think this looks like a sata problem, not an md problem. NeilBrown - 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-mm1 (md/raid1 randomly drops partitions)
On Tuesday, 12 December 2006 00:54, Neil Brown wrote: > On Tuesday December 12, [EMAIL PROTECTED] wrote: > > On Monday, 11 December 2006 23:52, Neil Brown wrote: > > > On Monday December 11, [EMAIL PROTECTED] wrote: > > > > Hi, > > > > > > > > On Monday, 11 December 2006 09:58, Andrew Morton wrote: > > > > > > > > > > Temporarily at > > > > > > > > > > http://userweb.kernel.org/~akpm/2.6.19-mm1/ > > > > > > > > > > Will appear later at > > > > > > > > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19/2.6.19-mm1/ > > > > > > > > It caused all of the md RAID1s on my test box to drop one of their > > > > partitions, > > > > apparently at random. > > > > > > That's clever > > > > > > Do you have any kernel logs of this happening? My guess would be the > > > underlying device driver is returned more errors than before, but we > > > need the logs to be sure. > > > > I've only found lots of messages like this: > > > > md: super_written gets error=-5, uptodate=0 > > So when md writes to write out the superblock, to gets EIO... Odd that > you aren't getting errors for normal writes. > > What devices are the md/raid1 built on? Sata drives, on sata_uli. > > > > I'll try to reproduce it tomorrow and collect some more information. > > Thanks. More information is definitely better than less, so send over > anything you can find. Okay, seems to be readily reproducible, dmesg output from the failing kernel attached. Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King dmesg.log.gz Description: GNU Zip compressed data
Re: 2.6.19-mm1: drivers/mtd/ubi/debug.c: unused variable
On 12/11/06, Adrian Bunk <[EMAIL PROTECTED]> wrote: On Mon, Dec 11, 2006 at 12:58:07AM -0800, Andrew Morton wrote: >... > Changes since 2.6.19-rc6-mm2: >... > git-ubi.patch >... > git trees. >... It doesn't seem to be intended that in ubi_dbg_vprint_nolock() the variable "caller" is never assigned any value different from 0. Hm.. we'll take a look. Thanks for pointing that out. FYI, if you CC the linux-mtd list for things related to UBI, a few more people that can fix things will get the emails. josh - 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-mm1
On Tue, 12 Dec 2006 15:43:54 +0900 KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote: > On Mon, 11 Dec 2006 22:06:17 -0800 > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > When I use ftp on 2.6.19-mm1, transfered file is always broken. > > > like this: > > > == > > > [EMAIL PROTECTED] ~]$ file ./linux-2.6.19.tar.bz2 (got on 2.6.19-mm1) > > > ./linux-2.6.19.tar.bz2: data > > > (I confirmed original file was not broken.) > > > > Yes, a couple of people have reported things like this. Strange. > > test.kernel.org is showing mostly-green. There's one fsx-linux failure (for > > unclear reasons) on one of the x86_64 machines, all the rest are happy. > > > > Which filesystem were you using? > > > using ext3. > > Can you investigate it a bit further please?? reboot, re-download, work > > out how the data differs, etc? > > > Hmm, this is summary of broken linux-2.6.19.tar.bz2 file (used od and diff) On 1k blocksize ext3, fsx-linux -r 512 -w 512 foo fails immediately. It works OK with blocksize==pagesize, which ia64 doesn't do. It's the pagecache-deadlock-avoidance patchset. I'll drop it again, and shall nuke 2.6.19-mm1 somehow, thanks. - 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-mm1
On Tue, 12 Dec 2006 15:43:54 +0900 KAMEZAWA Hiroyuki [EMAIL PROTECTED] wrote: On Mon, 11 Dec 2006 22:06:17 -0800 Andrew Morton [EMAIL PROTECTED] wrote: When I use ftp on 2.6.19-mm1, transfered file is always broken. like this: == [EMAIL PROTECTED] ~]$ file ./linux-2.6.19.tar.bz2 (got on 2.6.19-mm1) ./linux-2.6.19.tar.bz2: data (I confirmed original file was not broken.) Yes, a couple of people have reported things like this. Strange. test.kernel.org is showing mostly-green. There's one fsx-linux failure (for unclear reasons) on one of the x86_64 machines, all the rest are happy. Which filesystem were you using? using ext3. Can you investigate it a bit further please?? reboot, re-download, work out how the data differs, etc? Hmm, this is summary of broken linux-2.6.19.tar.bz2 file (used od and diff) On 1k blocksize ext3, fsx-linux -r 512 -w 512 foo fails immediately. It works OK with blocksize==pagesize, which ia64 doesn't do. It's the pagecache-deadlock-avoidance patchset. I'll drop it again, and shall nuke 2.6.19-mm1 somehow, thanks. - 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-mm1: drivers/mtd/ubi/debug.c: unused variable
On 12/11/06, Adrian Bunk [EMAIL PROTECTED] wrote: On Mon, Dec 11, 2006 at 12:58:07AM -0800, Andrew Morton wrote: ... Changes since 2.6.19-rc6-mm2: ... git-ubi.patch ... git trees. ... It doesn't seem to be intended that in ubi_dbg_vprint_nolock() the variable caller is never assigned any value different from 0. Hm.. we'll take a look. Thanks for pointing that out. FYI, if you CC the linux-mtd list for things related to UBI, a few more people that can fix things will get the emails. josh - 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-mm1 (md/raid1 randomly drops partitions)
On Tuesday, 12 December 2006 00:54, Neil Brown wrote: On Tuesday December 12, [EMAIL PROTECTED] wrote: On Monday, 11 December 2006 23:52, Neil Brown wrote: On Monday December 11, [EMAIL PROTECTED] wrote: Hi, On Monday, 11 December 2006 09:58, Andrew Morton wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.19-mm1/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19/2.6.19-mm1/ It caused all of the md RAID1s on my test box to drop one of their partitions, apparently at random. That's clever Do you have any kernel logs of this happening? My guess would be the underlying device driver is returned more errors than before, but we need the logs to be sure. I've only found lots of messages like this: md: super_written gets error=-5, uptodate=0 So when md writes to write out the superblock, to gets EIO... Odd that you aren't getting errors for normal writes. What devices are the md/raid1 built on? Sata drives, on sata_uli. I'll try to reproduce it tomorrow and collect some more information. Thanks. More information is definitely better than less, so send over anything you can find. Okay, seems to be readily reproducible, dmesg output from the failing kernel attached. Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King dmesg.log.gz Description: GNU Zip compressed data
Re: 2.6.19-mm1 (md/raid1 randomly drops partitions - possible sata_uli problem)
On Tuesday December 12, [EMAIL PROTECTED] wrote: So when md writes to write out the superblock, to gets EIO... Odd that you aren't getting errors for normal writes. What devices are the md/raid1 built on? Sata drives, on sata_uli. I'll try to reproduce it tomorrow and collect some more information. Thanks. More information is definitely better than less, so send over anything you can find. Okay, seems to be readily reproducible, dmesg output from the failing kernel attached. Weird. You are getting silent write errors... Can you write to these drives are all? e.g. dd if=/dev/sdb3 of=/tmp/tmp count=1 dd if=/tmp/tmp of=/dev/sdb3 oflag=direct (hopefully 'direct' will cause write errors to be passed up). I really think this looks like a sata problem, not an md problem. NeilBrown - 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-mm1
On Wed, 13 Dec 2006 09:17:42 +0800
Conke Hu [EMAIL PROTECTED] wrote:
Thank you for applying ATI SB600 SATA patch!
But it seems the patch file name should be
ati-sb600-sata-quirk.patch, not via-sb600-sata-quirk.patch, type
error? :)
That's the sort of thing which happens when people send me patches titled
Re: -mm merge plans for 2.6.20. I guess, and I don't spend a lot of time
over it, either.
BTW, the following line in ide/pci/atiixp.c had better be removed
since there would be no legacy ide mode any more after this patch is
applied.
{ PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_IXP600_SATA, PCI_ANY_ID,
PCI_ANY_ID, (PCI_CLASS_STORAGE_IDE8)|0x8a, 0x05, 1},
please send a patch to fix this.
-
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-mm1
On Mon, 11 Dec 2006 22:06:17 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote: > > When I use ftp on 2.6.19-mm1, transfered file is always broken. > > like this: > > == > > [EMAIL PROTECTED] ~]$ file ./linux-2.6.19.tar.bz2 (got on 2.6.19-mm1) > > ./linux-2.6.19.tar.bz2: data > > (I confirmed original file was not broken.) > > Yes, a couple of people have reported things like this. Strange. > test.kernel.org is showing mostly-green. There's one fsx-linux failure (for > unclear reasons) on one of the x86_64 machines, all the rest are happy. > > Which filesystem were you using? > using ext3. > Can you investigate it a bit further please?? reboot, re-download, work > out how the data differs, etc? > Hmm, this is summary of broken linux-2.6.19.tar.bz2 file (used od and diff) offset 00 -> 000b4f zero cleared. offset 000b50 -> 000fff not broken offset 001000 -> 001c47 zero cleared offset 001c48 -> 001fff not broken offset 002000 -> 002d39 zero cleared offset 002d40 -> 003fff not broken. offset 004000 -> 004f2f zero cleared offset 004f30 -> 004fff not broken offset 005000 -> 005a79 zero cleared offset 005a80 -> 005fff not broken offset 006000 -> 006b7f zero cleared offset 006b80 -> 007fff not broken ... All broken parts are always zero-cleared and start from offset aligned to 0x1000. (note: broken kernel's PAGE_SIZE is 16384) I'll do AMAP. -Kame - 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-mm1
On Tue, 12 Dec 2006 14:53:41 +0900 KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote: > > On Mon, 11 Dec 2006 00:58:07 -0800 > Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > Temporarily at > > > > http://userweb.kernel.org/~akpm/2.6.19-mm1/ > > > > Will appear later at > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19/2.6.19-mm1/ > > > > When I use ftp on 2.6.19-mm1, transfered file is always broken. > like this: > == > [EMAIL PROTECTED] ~]$ file ./linux-2.6.19.tar.bz2 (got on 2.6.19-mm1) > ./linux-2.6.19.tar.bz2: data > (I confirmed original file was not broken.) Yes, a couple of people have reported things like this. Strange. test.kernel.org is showing mostly-green. There's one fsx-linux failure (for unclear reasons) on one of the x86_64 machines, all the rest are happy. Which filesystem were you using? Can you investigate it a bit further please?? reboot, re-download, work out how the data differs, etc? - 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-mm1
On Mon, 11 Dec 2006 00:58:07 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote: > > Temporarily at > > http://userweb.kernel.org/~akpm/2.6.19-mm1/ > > Will appear later at > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19/2.6.19-mm1/ > When I use ftp on 2.6.19-mm1, transfered file is always broken. like this: == [EMAIL PROTECTED] ~]$ file ./linux-2.6.19.tar.bz2 (got on 2.6.19-mm1) ./linux-2.6.19.tar.bz2: data (I confirmed original file was not broken.) == It seems that file systems work well. So I doubts network...but no idea. I attaches my .config. hardware config is: Itanium2 1.3GHz x2, SMP, e1000 network card as eth0 Thanks, -Kame == # # Automatically generated make config: don't edit # Linux kernel version: 2.6.19-mm1 # Tue Dec 12 10:44:08 2006 # CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SWAP_PREFETCH=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_CPUSETS is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set 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_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_STOP_MACHINE=y # # Block layer # CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" # # Processor type and features # CONFIG_IA64=y CONFIG_64BIT=y CONFIG_ZONE_DMA=y CONFIG_MMU=y CONFIG_SWIOTLB=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_TIME_INTERPOLATION=y CONFIG_DMI=y CONFIG_EFI=y CONFIG_GENERIC_IOMAP=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_AUDIT_ARCH=y # CONFIG_IA64_GENERIC is not set CONFIG_IA64_DIG=y # CONFIG_IA64_HP_ZX1 is not set # CONFIG_IA64_HP_ZX1_SWIOTLB is not set # CONFIG_IA64_SGI_SN2 is not set # CONFIG_IA64_HP_SIM is not set # CONFIG_ITANIUM is not set CONFIG_MCKINLEY=y # CONFIG_IA64_PAGE_SIZE_4KB is not set # CONFIG_IA64_PAGE_SIZE_8KB is not set CONFIG_IA64_PAGE_SIZE_16KB=y # CONFIG_IA64_PAGE_SIZE_64KB is not set CONFIG_PGTABLE_3=y # CONFIG_PGTABLE_4 is not set # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_300 is not set # CONFIG_HZ_1000 is not set CONFIG_HZ=250 CONFIG_IA64_L1_CACHE_SHIFT=7 CONFIG_IA64_CYCLONE=y CONFIG_IOSAPIC=y CONFIG_FORCE_MAX_ZONEORDER=17 CONFIG_SMP=y CONFIG_NR_CPUS=16 CONFIG_HOTPLUG_CPU=y CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y # CONFIG_SCHED_SMT is not set CONFIG_PERMIT_BSP_REMOVE=y CONFIG_FORCE_CPEI_RETARGET=y # CONFIG_PREEMPT is not set CONFIG_SELECT_MEMORY_MODEL=y # CONFIG_FLATMEM_MANUAL is not set # CONFIG_DISCONTIGMEM_MANUAL is not set CONFIG_SPARSEMEM_MANUAL=y CONFIG_SPARSEMEM=y CONFIG_NEED_MULTIPLE_NODES=y CONFIG_HAVE_MEMORY_PRESENT=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPARSEMEM_EXTREME=y CONFIG_SPARSEMEM_VMEMMAP=y CONFIG_SPARSEMEM_VMEMMAP_STATIC=y CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_MIGRATION=y CONFIG_RESOURCES_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_ADAPTIVE_READAHEAD=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_ARCH_DISCONTIGMEM_ENABLE=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SPARSEMEM_VMEMMAP=y CONFIG_ARCH_SPARSEMEM_VMEMMAP_STATIC=y CONFIG_NUMA=y CONFIG_NODES_SHIFT=10 CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID=y CONFIG_HAVE_ARCH_NODEDATA_EXTENSION=y CONFIG_IA32_SUPPORT=y CONFIG_COMPAT=y CONFIG_IA64_MCA_RECOVERY=y CONFIG_PERFMON=y CONFIG_IA64_PALINFO=y # CONFIG_IA64_ESI is not set # CONFIG_KEXEC is not set # CONFIG_CRASH_DUMP is not set # # Firmware Drivers # CONFIG_EFI_VARS=y CONFIG_EFI_PCDP=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=m # # Power management and ACPI # CONFIG_PM=y CONFIG_PM_LEGACY=y # CONFIG_PM_DEBUG is not set # CONFIG_PM_SYSFS_DEPRECATED is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BUTTON=m
Re: 2.6.19-mm1 (md/raid1 randomly drops partitions)
On Tuesday December 12, [EMAIL PROTECTED] wrote: > On Monday, 11 December 2006 23:52, Neil Brown wrote: > > On Monday December 11, [EMAIL PROTECTED] wrote: > > > Hi, > > > > > > On Monday, 11 December 2006 09:58, Andrew Morton wrote: > > > > > > > > Temporarily at > > > > > > > > http://userweb.kernel.org/~akpm/2.6.19-mm1/ > > > > > > > > Will appear later at > > > > > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19/2.6.19-mm1/ > > > > > > It caused all of the md RAID1s on my test box to drop one of their > > > partitions, > > > apparently at random. > > > > That's clever > > > > Do you have any kernel logs of this happening? My guess would be the > > underlying device driver is returned more errors than before, but we > > need the logs to be sure. > > I've only found lots of messages like this: > > md: super_written gets error=-5, uptodate=0 So when md writes to write out the superblock, to gets EIO... Odd that you aren't getting errors for normal writes. What devices are the md/raid1 built on? > > I'll try to reproduce it tomorrow and collect some more information. Thanks. More information is definitely better than less, so send over anything you can find. NeilBrown - 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-mm1 (md/raid1 randomly drops partitions)
On Monday, 11 December 2006 23:52, Neil Brown wrote: > On Monday December 11, [EMAIL PROTECTED] wrote: > > Hi, > > > > On Monday, 11 December 2006 09:58, Andrew Morton wrote: > > > > > > Temporarily at > > > > > > http://userweb.kernel.org/~akpm/2.6.19-mm1/ > > > > > > Will appear later at > > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19/2.6.19-mm1/ > > > > It caused all of the md RAID1s on my test box to drop one of their > > partitions, > > apparently at random. > > That's clever > > Do you have any kernel logs of this happening? My guess would be the > underlying device driver is returned more errors than before, but we > need the logs to be sure. I've only found lots of messages like this: md: super_written gets error=-5, uptodate=0 I'll try to reproduce it tomorrow and collect some more information. Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King - 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-mm1 (md/raid1 randomly drops partitions)
On Monday December 11, [EMAIL PROTECTED] wrote: > Hi, > > On Monday, 11 December 2006 09:58, Andrew Morton wrote: > > > > Temporarily at > > > > http://userweb.kernel.org/~akpm/2.6.19-mm1/ > > > > Will appear later at > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19/2.6.19-mm1/ > > It caused all of the md RAID1s on my test box to drop one of their partitions, > apparently at random. That's clever Do you have any kernel logs of this happening? My guess would be the underlying device driver is returned more errors than before, but we need the logs to be sure. Thanks, NeilBrown - 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-mm1
Hi, On Monday, 11 December 2006 09:58, Andrew Morton wrote: > > Temporarily at > > http://userweb.kernel.org/~akpm/2.6.19-mm1/ > > Will appear later at > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19/2.6.19-mm1/ It caused all of the md RAID1s on my test box to drop one of their partitions, apparently at random. Greetings, Rafael - 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-mm1
On Tue, 12 Dec 2006, Nick Piggin wrote: > > >Do you have CONFIG_DEBUG_VM turned on? I think we miss clearning > > >BH_New in some places, thus causing an error path to zero the block > > >incorrectly if we hit an error that CONFIG_DEBUG_VM makes much more > > >likely. > > Yes, I have. Will retry without it and let you know if the problem goes > > away. > Thanks. OK, seems like CONFIG_DEBUG_VM doesn't influence the bug much -- I can't see any difference in behavior without CONFIG_DEBUG_VM - resolv.conf gets corrupted upon boot, ctags -R is still very reliable command to produce the corruption, etc. Neither 2.6.19 nor 2.6.19-rc6-mm2 did this. .config is at http://www.jikos.cz/jikos/junk/.config -- Jiri Kosina - 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-mm1
Jiri Kosina wrote: On Tue, 12 Dec 2006, Nick Piggin wrote: Am I the only one seeing something strange on ext3 with this kernel? For example /etc/resolv.conf gets corrupted during the dhclient run. It looks like this, after dhclient finishes: Do you have CONFIG_DEBUG_VM turned on? I think we miss clearning BH_New in some places, thus causing an error path to zero the block incorrectly if we hit an error that CONFIG_DEBUG_VM makes much more likely. Yes, I have. Will retry without it and let you know if the problem goes away. Thanks. Seems quite dangerous, a few minutes with 2.6.19-mm1 corrupted quite a lot of files on my fs. Sorry. -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.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-mm1
On Tue, 12 Dec 2006, Nick Piggin wrote: > > Am I the only one seeing something strange on ext3 with this kernel? > > For example /etc/resolv.conf gets corrupted during the dhclient run. > > It looks like this, after dhclient finishes: > Do you have CONFIG_DEBUG_VM turned on? I think we miss clearning BH_New > in some places, thus causing an error path to zero the block incorrectly > if we hit an error that CONFIG_DEBUG_VM makes much more likely. Yes, I have. Will retry without it and let you know if the problem goes away. Seems quite dangerous, a few minutes with 2.6.19-mm1 corrupted quite a lot of files on my fs. -- Jiri Kosina - 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-mm1
Jiri Kosina wrote: On Mon, 11 Dec 2006, Andrew Morton wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.19-mm1/ Am I the only one seeing something strange on ext3 with this kernel? For example /etc/resolv.conf gets corrupted during the dhclient run. It looks like this, after dhclient finishes: Do you have CONFIG_DEBUG_VM turned on? I think we miss clearning BH_New in some places, thus causing an error path to zero the block incorrectly if we hit an error that CONFIG_DEBUG_VM makes much more likely. -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.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-mm1
On Mon, 11 Dec 2006, Andrew Morton wrote: > Temporarily at > http://userweb.kernel.org/~akpm/2.6.19-mm1/ Am I the only one seeing something strange on ext3 with this kernel? For example /etc/resolv.conf gets corrupted during the dhclient run. It looks like this, after dhclient finishes: 000 * 3f0 2300 2020 2020 2020 400 * 510 6e00 520 6d61 7365 7265 6576 2072 3031 322e 2e30 530 2e30 0a38 534 ctags -R also produces invalid tags file (also lots of padding with zero bytes). Will try to track down what causes it. -- Jiri Kosina - 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-mm1
Andrew Morton wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.19-mm1/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19/2.6.19-mm1/ - There's some new runtime debugging in kmap_atomic(). It catches one buglet in in ata_scsi_rbuf_get() - there may be others. If it gets too noisy, please revert kmap_atomic-debugging.patch. - The reiser4 build is broken by some VFS changes I made. - New git tree git-ubi.patch (Artem Bityutskiy <[EMAIL PROTECTED]>): It is a kind of LVM layer but for flash (MTD) devices which hides flash devices complexities like bad eraseblocks (on NANDs) and wear. The documentation is available at the MTD web site: http://www.linux-mtd.infradead.org/doc/ubi.html http://www.linux-mtd.infradead.org/faq/ubi.html - The x86_64 tree here is a few days old - the server is down. - Brought back the write()-deadlock-fix-and-writev-speedup patches. Note that these still look like they have a couple of problems (you are _very_ unlikely to hit them unless you are running with CONFIG_DEBUG_VM, or actually have any useful data). We're just looking at how to fix them now. Stress testing would be appreciated, but not your production database. Thanks, Nick -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.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-mm1
Andrew Morton wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.19-mm1/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19/2.6.19-mm1/ - There's some new runtime debugging in kmap_atomic(). It catches one buglet in in ata_scsi_rbuf_get() - there may be others. If it gets too noisy, please revert kmap_atomic-debugging.patch. - The reiser4 build is broken by some VFS changes I made. - New git tree git-ubi.patch (Artem Bityutskiy [EMAIL PROTECTED]): It is a kind of LVM layer but for flash (MTD) devices which hides flash devices complexities like bad eraseblocks (on NANDs) and wear. The documentation is available at the MTD web site: http://www.linux-mtd.infradead.org/doc/ubi.html http://www.linux-mtd.infradead.org/faq/ubi.html - The x86_64 tree here is a few days old - the server is down. - Brought back the write()-deadlock-fix-and-writev-speedup patches. Note that these still look like they have a couple of problems (you are _very_ unlikely to hit them unless you are running with CONFIG_DEBUG_VM, or actually have any useful data). We're just looking at how to fix them now. Stress testing would be appreciated, but not your production database. Thanks, Nick -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.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-mm1
On Mon, 11 Dec 2006, Andrew Morton wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.19-mm1/ Am I the only one seeing something strange on ext3 with this kernel? For example /etc/resolv.conf gets corrupted during the dhclient run. It looks like this, after dhclient finishes: 000 * 3f0 2300 2020 2020 2020 400 * 510 6e00 520 6d61 7365 7265 6576 2072 3031 322e 2e30 530 2e30 0a38 534 ctags -R also produces invalid tags file (also lots of padding with zero bytes). Will try to track down what causes it. -- Jiri Kosina - 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-mm1
Jiri Kosina wrote: On Mon, 11 Dec 2006, Andrew Morton wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.19-mm1/ Am I the only one seeing something strange on ext3 with this kernel? For example /etc/resolv.conf gets corrupted during the dhclient run. It looks like this, after dhclient finishes: Do you have CONFIG_DEBUG_VM turned on? I think we miss clearning BH_New in some places, thus causing an error path to zero the block incorrectly if we hit an error that CONFIG_DEBUG_VM makes much more likely. -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.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-mm1
On Tue, 12 Dec 2006, Nick Piggin wrote: Am I the only one seeing something strange on ext3 with this kernel? For example /etc/resolv.conf gets corrupted during the dhclient run. It looks like this, after dhclient finishes: Do you have CONFIG_DEBUG_VM turned on? I think we miss clearning BH_New in some places, thus causing an error path to zero the block incorrectly if we hit an error that CONFIG_DEBUG_VM makes much more likely. Yes, I have. Will retry without it and let you know if the problem goes away. Seems quite dangerous, a few minutes with 2.6.19-mm1 corrupted quite a lot of files on my fs. -- Jiri Kosina - 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-mm1
Jiri Kosina wrote: On Tue, 12 Dec 2006, Nick Piggin wrote: Am I the only one seeing something strange on ext3 with this kernel? For example /etc/resolv.conf gets corrupted during the dhclient run. It looks like this, after dhclient finishes: Do you have CONFIG_DEBUG_VM turned on? I think we miss clearning BH_New in some places, thus causing an error path to zero the block incorrectly if we hit an error that CONFIG_DEBUG_VM makes much more likely. Yes, I have. Will retry without it and let you know if the problem goes away. Thanks. Seems quite dangerous, a few minutes with 2.6.19-mm1 corrupted quite a lot of files on my fs. Sorry. -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.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-mm1
On Tue, 12 Dec 2006, Nick Piggin wrote: Do you have CONFIG_DEBUG_VM turned on? I think we miss clearning BH_New in some places, thus causing an error path to zero the block incorrectly if we hit an error that CONFIG_DEBUG_VM makes much more likely. Yes, I have. Will retry without it and let you know if the problem goes away. Thanks. OK, seems like CONFIG_DEBUG_VM doesn't influence the bug much -- I can't see any difference in behavior without CONFIG_DEBUG_VM - resolv.conf gets corrupted upon boot, ctags -R is still very reliable command to produce the corruption, etc. Neither 2.6.19 nor 2.6.19-rc6-mm2 did this. .config is at http://www.jikos.cz/jikos/junk/.config -- Jiri Kosina - 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-mm1
Hi, On Monday, 11 December 2006 09:58, Andrew Morton wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.19-mm1/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19/2.6.19-mm1/ It caused all of the md RAID1s on my test box to drop one of their partitions, apparently at random. Greetings, Rafael - 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-mm1 (md/raid1 randomly drops partitions)
On Monday December 11, [EMAIL PROTECTED] wrote: Hi, On Monday, 11 December 2006 09:58, Andrew Morton wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.19-mm1/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19/2.6.19-mm1/ It caused all of the md RAID1s on my test box to drop one of their partitions, apparently at random. That's clever Do you have any kernel logs of this happening? My guess would be the underlying device driver is returned more errors than before, but we need the logs to be sure. Thanks, NeilBrown - 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-mm1 (md/raid1 randomly drops partitions)
On Monday, 11 December 2006 23:52, Neil Brown wrote: On Monday December 11, [EMAIL PROTECTED] wrote: Hi, On Monday, 11 December 2006 09:58, Andrew Morton wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.19-mm1/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19/2.6.19-mm1/ It caused all of the md RAID1s on my test box to drop one of their partitions, apparently at random. That's clever Do you have any kernel logs of this happening? My guess would be the underlying device driver is returned more errors than before, but we need the logs to be sure. I've only found lots of messages like this: md: super_written gets error=-5, uptodate=0 I'll try to reproduce it tomorrow and collect some more information. Greetings, Rafael -- If you don't have the time to read, you don't have the time or the tools to write. - Stephen King - 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-mm1 (md/raid1 randomly drops partitions)
On Tuesday December 12, [EMAIL PROTECTED] wrote: On Monday, 11 December 2006 23:52, Neil Brown wrote: On Monday December 11, [EMAIL PROTECTED] wrote: Hi, On Monday, 11 December 2006 09:58, Andrew Morton wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.19-mm1/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19/2.6.19-mm1/ It caused all of the md RAID1s on my test box to drop one of their partitions, apparently at random. That's clever Do you have any kernel logs of this happening? My guess would be the underlying device driver is returned more errors than before, but we need the logs to be sure. I've only found lots of messages like this: md: super_written gets error=-5, uptodate=0 So when md writes to write out the superblock, to gets EIO... Odd that you aren't getting errors for normal writes. What devices are the md/raid1 built on? I'll try to reproduce it tomorrow and collect some more information. Thanks. More information is definitely better than less, so send over anything you can find. NeilBrown - 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-mm1
On Mon, 11 Dec 2006 00:58:07 -0800 Andrew Morton [EMAIL PROTECTED] wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.19-mm1/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19/2.6.19-mm1/ When I use ftp on 2.6.19-mm1, transfered file is always broken. like this: == [EMAIL PROTECTED] ~]$ file ./linux-2.6.19.tar.bz2 (got on 2.6.19-mm1) ./linux-2.6.19.tar.bz2: data (I confirmed original file was not broken.) == It seems that file systems work well. So I doubts network...but no idea. I attaches my .config. hardware config is: Itanium2 1.3GHz x2, SMP, e1000 network card as eth0 Thanks, -Kame == # # Automatically generated make config: don't edit # Linux kernel version: 2.6.19-mm1 # Tue Dec 12 10:44:08 2006 # CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SWAP_PREFETCH=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_CPUSETS is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_INITRAMFS_SOURCE= CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set 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_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_STOP_MACHINE=y # # Block layer # CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=anticipatory # # Processor type and features # CONFIG_IA64=y CONFIG_64BIT=y CONFIG_ZONE_DMA=y CONFIG_MMU=y CONFIG_SWIOTLB=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_TIME_INTERPOLATION=y CONFIG_DMI=y CONFIG_EFI=y CONFIG_GENERIC_IOMAP=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_AUDIT_ARCH=y # CONFIG_IA64_GENERIC is not set CONFIG_IA64_DIG=y # CONFIG_IA64_HP_ZX1 is not set # CONFIG_IA64_HP_ZX1_SWIOTLB is not set # CONFIG_IA64_SGI_SN2 is not set # CONFIG_IA64_HP_SIM is not set # CONFIG_ITANIUM is not set CONFIG_MCKINLEY=y # CONFIG_IA64_PAGE_SIZE_4KB is not set # CONFIG_IA64_PAGE_SIZE_8KB is not set CONFIG_IA64_PAGE_SIZE_16KB=y # CONFIG_IA64_PAGE_SIZE_64KB is not set CONFIG_PGTABLE_3=y # CONFIG_PGTABLE_4 is not set # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_300 is not set # CONFIG_HZ_1000 is not set CONFIG_HZ=250 CONFIG_IA64_L1_CACHE_SHIFT=7 CONFIG_IA64_CYCLONE=y CONFIG_IOSAPIC=y CONFIG_FORCE_MAX_ZONEORDER=17 CONFIG_SMP=y CONFIG_NR_CPUS=16 CONFIG_HOTPLUG_CPU=y CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y # CONFIG_SCHED_SMT is not set CONFIG_PERMIT_BSP_REMOVE=y CONFIG_FORCE_CPEI_RETARGET=y # CONFIG_PREEMPT is not set CONFIG_SELECT_MEMORY_MODEL=y # CONFIG_FLATMEM_MANUAL is not set # CONFIG_DISCONTIGMEM_MANUAL is not set CONFIG_SPARSEMEM_MANUAL=y CONFIG_SPARSEMEM=y CONFIG_NEED_MULTIPLE_NODES=y CONFIG_HAVE_MEMORY_PRESENT=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPARSEMEM_EXTREME=y CONFIG_SPARSEMEM_VMEMMAP=y CONFIG_SPARSEMEM_VMEMMAP_STATIC=y CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_MIGRATION=y CONFIG_RESOURCES_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_ADAPTIVE_READAHEAD=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_ARCH_DISCONTIGMEM_ENABLE=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SPARSEMEM_VMEMMAP=y CONFIG_ARCH_SPARSEMEM_VMEMMAP_STATIC=y CONFIG_NUMA=y CONFIG_NODES_SHIFT=10 CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID=y CONFIG_HAVE_ARCH_NODEDATA_EXTENSION=y CONFIG_IA32_SUPPORT=y CONFIG_COMPAT=y CONFIG_IA64_MCA_RECOVERY=y CONFIG_PERFMON=y CONFIG_IA64_PALINFO=y # CONFIG_IA64_ESI is not set # CONFIG_KEXEC is not set # CONFIG_CRASH_DUMP is not set # # Firmware Drivers # CONFIG_EFI_VARS=y CONFIG_EFI_PCDP=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=m # # Power management and ACPI # CONFIG_PM=y CONFIG_PM_LEGACY=y # CONFIG_PM_DEBUG is not set # CONFIG_PM_SYSFS_DEPRECATED is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BUTTON=m CONFIG_ACPI_FAN=m #
Re: 2.6.19-mm1
On Tue, 12 Dec 2006 14:53:41 +0900 KAMEZAWA Hiroyuki [EMAIL PROTECTED] wrote: On Mon, 11 Dec 2006 00:58:07 -0800 Andrew Morton [EMAIL PROTECTED] wrote: Temporarily at http://userweb.kernel.org/~akpm/2.6.19-mm1/ Will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.19/2.6.19-mm1/ When I use ftp on 2.6.19-mm1, transfered file is always broken. like this: == [EMAIL PROTECTED] ~]$ file ./linux-2.6.19.tar.bz2 (got on 2.6.19-mm1) ./linux-2.6.19.tar.bz2: data (I confirmed original file was not broken.) Yes, a couple of people have reported things like this. Strange. test.kernel.org is showing mostly-green. There's one fsx-linux failure (for unclear reasons) on one of the x86_64 machines, all the rest are happy. Which filesystem were you using? Can you investigate it a bit further please?? reboot, re-download, work out how the data differs, etc? - 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-mm1
On Mon, 11 Dec 2006 22:06:17 -0800 Andrew Morton [EMAIL PROTECTED] wrote: When I use ftp on 2.6.19-mm1, transfered file is always broken. like this: == [EMAIL PROTECTED] ~]$ file ./linux-2.6.19.tar.bz2 (got on 2.6.19-mm1) ./linux-2.6.19.tar.bz2: data (I confirmed original file was not broken.) Yes, a couple of people have reported things like this. Strange. test.kernel.org is showing mostly-green. There's one fsx-linux failure (for unclear reasons) on one of the x86_64 machines, all the rest are happy. Which filesystem were you using? using ext3. Can you investigate it a bit further please?? reboot, re-download, work out how the data differs, etc? Hmm, this is summary of broken linux-2.6.19.tar.bz2 file (used od and diff) offset 00 - 000b4f zero cleared. offset 000b50 - 000fff not broken offset 001000 - 001c47 zero cleared offset 001c48 - 001fff not broken offset 002000 - 002d39 zero cleared offset 002d40 - 003fff not broken. offset 004000 - 004f2f zero cleared offset 004f30 - 004fff not broken offset 005000 - 005a79 zero cleared offset 005a80 - 005fff not broken offset 006000 - 006b7f zero cleared offset 006b80 - 007fff not broken ... All broken parts are always zero-cleared and start from offset aligned to 0x1000. (note: broken kernel's PAGE_SIZE is 16384) I'll do AMAP. -Kame - 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/
