RE: [patch 32/36] XFS: Make xfsbufd threads freezable
> -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] De la part de Greg KH > Envoyé : 13 décembre 2007 01:35 > > 2.6.22-stable review patch. If anyone has any objections, > please let us know. > > -- > From: Rafael J. Wysocki <[EMAIL PROTECTED]> > > patch 978c7b2ff49597ab76ff7529a933bd366941ac25 in mainline > > Fix breakage caused by commit 831441862956fffa17b9801db37e6ea1650b0f69 > that did not introduce the necessary call to set_freezable() > in xfs/linux-2.6/xfs_buf.c . > > SGI-PV: 974224 > SGI-Modid: xfs-linux-melb:xfs-kern:30203a > > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> > Signed-off-by: David Chinner <[EMAIL PROTECTED]> > Signed-off-by: Lachlan McIlroy <[EMAIL PROTECTED]> > Cc: Oliver Pintr <[EMAIL PROTECTED]> > Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> > > --- Hi Greg, Don't know if it is related but I got this while building on Debian Etch 4.0: Building modules, stage 2. MODPOST 1882 modules ERROR: "set_freezable" [fs/xfs/xfs.ko] undefined! make[2]: *** [__modpost] Error 1 make[1]: *** [modules] Error 2 make[1]: Leaving directory `/usr/src/linux-headers-2.6.22.15-rc1-cfs-etch-686-envcan' make: *** [debian/stamp-build-kernel] Error 2 - vin -- 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 32/36] XFS: Make xfsbufd threads freezable
-Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Greg KH Envoyé : 13 décembre 2007 01:35 2.6.22-stable review patch. If anyone has any objections, please let us know. -- From: Rafael J. Wysocki [EMAIL PROTECTED] patch 978c7b2ff49597ab76ff7529a933bd366941ac25 in mainline Fix breakage caused by commit 831441862956fffa17b9801db37e6ea1650b0f69 that did not introduce the necessary call to set_freezable() in xfs/linux-2.6/xfs_buf.c . SGI-PV: 974224 SGI-Modid: xfs-linux-melb:xfs-kern:30203a Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED] Signed-off-by: David Chinner [EMAIL PROTECTED] Signed-off-by: Lachlan McIlroy [EMAIL PROTECTED] Cc: Oliver Pintr [EMAIL PROTECTED] Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED] --- Hi Greg, Don't know if it is related but I got this while building on Debian Etch 4.0: Building modules, stage 2. MODPOST 1882 modules ERROR: set_freezable [fs/xfs/xfs.ko] undefined! make[2]: *** [__modpost] Error 1 make[1]: *** [modules] Error 2 make[1]: Leaving directory `/usr/src/linux-headers-2.6.22.15-rc1-cfs-etch-686-envcan' make: *** [debian/stamp-build-kernel] Error 2 - vin -- 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.22.14 oops msg with commvault galaxy ?
> -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] De la part de Dhaval Giani > > On Wed, Dec 12, 2007 at 07:57:33AM -0500, Fortier,Vincent > [Montreal] wrote: > > > -Message d'origine- > > > De : Dhaval Giani [mailto:[EMAIL PROTECTED] > > > > > > On Tue, Dec 11, 2007 at 10:06:53PM +0100, Ingo Molnar wrote: > > > > > > > > * Fortier,Vincent [Montreal] <[EMAIL PROTECTED]> wrote: > > > > > > > > > > That has changed from /sys/kernel/uids//cpu_share > > > > > > > > > > Here is my config. > > > > > > > > > > Maybie I should give it a shot without CFS at all and see what > > > > > happends ? > > > > It got triggerred also using a 2.6.22.14: Here are my preliminary test results: 2.6.21.7: OK 2.6.22.13/14: Failure 2.6.23.9: OK 2.6.24-rc5-git2: OK It seems to only hang using a 2.6.22 kernel. > > No, not any more. Would it be possible for you to do a > git-bisect? I am not too well versed with sysfs, so it is not > apparent to me what is causing this oops. It seems to be > easily reproducible. I don't still have a reliable method to > reproduce it without the CFS patch. Could sysfs experts > please help debugging? > I seriously doubt I have the time to do a git-bisect at the moment - vin -- 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.22.14 oops msg with commvault galaxy ?
> -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] De la part de > Fortier,Vincent [Montreal] > > > -Message d'origine- > > De : Dhaval Giani [mailto:[EMAIL PROTECTED] > > > > On Tue, Dec 11, 2007 at 10:06:53PM +0100, Ingo Molnar wrote: > > > > > > * Fortier,Vincent [Montreal] <[EMAIL PROTECTED]> wrote: > > > > > > > > That has changed from /sys/kernel/uids//cpu_share > > > > > > > > Here is my config. > > > > > > > > Maybie I should give it a shot without CFS at all and see what > > > > happends ? > > It got triggerred also using a 2.6.22.14: Just to clarify... this is a non CFS kernel oops... > [57560.396000] BUG: unable to handle kernel paging request at > virtual address 8000 [57560.396000] printing eip: > [57560.396000] c01d6c56 > [57560.396000] *pdpt = 08d02001 > [57560.396000] *pde = > [57560.396000] Oops: [#34] > [57560.396000] SMP > [57560.396000] last sysfs file: > /devices/platform/floppy.0/uevent [57560.396000] Modules > linked in: xfs drbd cn nfs nfsd exportfs lockd nfs_acl sunrpc > ppdev parport_pc lp parport button ac battery ipv6 fuse > ide_cd ide_generic usbkbd usbmouse tsdev iTCO_wdt > iTCO_vendor_support psmouse e752x_edac edac_mc serio_raw > evdev pcspkr sg floppy shpchp pci_hotplug sr_mod cdrom ext3 > jbd mbcache dm_mirror dm_snapshot dm_mod generic piix > ide_core tg3 ata_piix ehci_hcd uhci_hcd usbcore thermal > processor fan mptscsih mptbase megaraid_sas megaraid_mbox > megaraid_mm cciss aacraid > [57560.396000] CPU:2 > [57560.396000] EIP:0060:[]Not tainted VLI > [57560.396000] EFLAGS: 00010297 (2.6.22.14-etch-686-envcan #1) > [57560.396000] EIP is at vsnprintf+0x2af/0x48c > [57560.396000] eax: 8000 ebx: ecx: 8000 edx: > fffe > [57560.396000] esi: edf37017 edi: edf09eac ebp: esp: > edf09e4c > [57560.396000] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 > [57560.396000] Process clBackup (pid: 31421, ti=edf08000 task=f7d36530 > task.ti=edf08000) > [57560.396000] Stack: c852b000 1000 c0338c78 f895b56c > c0233bf5 c852b000 120c8fe8 edf37017 > [57560.396000]00c3bd08 > c03354eb 0003 0017 > [57560.396000]c0376dc0 c852b000 c01d6eb4 edf09eac edf09eac > c0233170 edf37017 c03354ea > [57560.396000] Call Trace: > [57560.396000] [] dev_uevent+0x189/0x1e0 > [57560.396000] [] sprintf+0x20/0x23 [57560.396000] > [] show_uevent+0xad/0xd5 [57560.396000] > [] get_page_from_freelist+0x296/0x32d > [57560.396000] [] group_send_sig_info+0x12/0x56 > [57560.396000] [] __alloc_pages+0x52/0x294 > [57560.396000] [] show_uevent+0x0/0xd5 > [57560.396000] [] dev_attr_show+0x15/0x18 > [57560.396000] [] sysfs_read_file+0x87/0xd8 > [57560.396000] [] sys_getxattr+0x46/0x4e > [57560.396000] [] sysfs_read_file+0x0/0xd8 > [57560.396000] [] vfs_read+0xa6/0x128 > [57560.396000] [] sys_read+0x41/0x67 > [57560.396000] [] syscall_call+0x7/0xb > [57560.396000] === [57560.396000] Code: > 74 24 28 73 03 c6 06 20 4d 46 85 ed 7f f1 e9 b9 00 00 00 8b > 0f b8 79 e0 32 c0 8b 54 24 2c 81 f9 ff 0f 00 00 0f 46 c8 89 > c8 eb 06 <80> 38 00 74 07 40 4a 83 fa ff 75 f4 29 c8 f6 44 24 > 30 10 89 c3 [57560.396000] EIP: [] > vsnprintf+0x2af/0x48c SS:ESP 0068:edf09e4c > > > > > > > and also with CFS but without CONFIG_FAIR_GROUP_SCHED. > > > > > Is it still required since it now does not seems to be CFS related? > > > > > Hi Ingo, > > > > I am able to reproduce the oops here on my system with > > 2.6.22.14 + CFS backport. I am not able to reproduce it with > > 2.6.22.13 + CFS backport. I believe the CFS backport is > just exposing > > the bug. Can't find an obvious culprit and am looking into > this issue. > > > > Vincent, could you please confirm if you are able to reproduce this > > with > > 2.6.22.13 + CFS? > > Using 2.6.13 + CFS v24 I was also able to reproduce the bug > (I already had one built in my depot without the > display_most-recently-opened_sysfs_file_name_when_oopsing.patc > h). So it looks like it is at least related to >= 2.6.22.13 > and probably not directly CFS related. Note that to get a > oops on a 2.6.13 it seems to need a full backup since it > usually works with incremental. The backup does start > properly then, in this case, at around 70% it oopsed. Using > 2.6.22.14 it seems to oops right at startup. Here is the > 2.6.22.13 CFS v24 oops: Again, just to clari
RE: 2.6.22.14 oops msg with commvault galaxy ?
> -Message d'origine- > De : Dhaval Giani [mailto:[EMAIL PROTECTED] > > On Tue, Dec 11, 2007 at 10:06:53PM +0100, Ingo Molnar wrote: > > > > * Fortier,Vincent [Montreal] <[EMAIL PROTECTED]> wrote: > > > > > > That has changed from /sys/kernel/uids//cpu_share > > > > > > Here is my config. > > > > > > Maybie I should give it a shot without CFS at all and see what > > > happends ? It got triggerred also using a 2.6.22.14: [57560.396000] BUG: unable to handle kernel paging request at virtual address 8000 [57560.396000] printing eip: [57560.396000] c01d6c56 [57560.396000] *pdpt = 08d02001 [57560.396000] *pde = [57560.396000] Oops: [#34] [57560.396000] SMP [57560.396000] last sysfs file: /devices/platform/floppy.0/uevent [57560.396000] Modules linked in: xfs drbd cn nfs nfsd exportfs lockd nfs_acl sunrpc ppdev parport_pc lp parport button ac battery ipv6 fuse ide_cd ide_generic usbkbd usbmouse tsdev iTCO_wdt iTCO_vendor_support psmouse e752x_edac edac_mc serio_raw evdev pcspkr sg floppy shpchp pci_hotplug sr_mod cdrom ext3 jbd mbcache dm_mirror dm_snapshot dm_mod generic piix ide_core tg3 ata_piix ehci_hcd uhci_hcd usbcore thermal processor fan mptscsih mptbase megaraid_sas megaraid_mbox megaraid_mm cciss aacraid [57560.396000] CPU:2 [57560.396000] EIP:0060:[]Not tainted VLI [57560.396000] EFLAGS: 00010297 (2.6.22.14-etch-686-envcan #1) [57560.396000] EIP is at vsnprintf+0x2af/0x48c [57560.396000] eax: 8000 ebx: ecx: 8000 edx: fffe [57560.396000] esi: edf37017 edi: edf09eac ebp: esp: edf09e4c [57560.396000] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 [57560.396000] Process clBackup (pid: 31421, ti=edf08000 task=f7d36530 task.ti=edf08000) [57560.396000] Stack: c852b000 1000 c0338c78 f895b56c c0233bf5 c852b000 120c8fe8 edf37017 [57560.396000]00c3bd08 c03354eb 0003 0017 [57560.396000]c0376dc0 c852b000 c01d6eb4 edf09eac edf09eac c0233170 edf37017 c03354ea [57560.396000] Call Trace: [57560.396000] [] dev_uevent+0x189/0x1e0 [57560.396000] [] sprintf+0x20/0x23 [57560.396000] [] show_uevent+0xad/0xd5 [57560.396000] [] get_page_from_freelist+0x296/0x32d [57560.396000] [] group_send_sig_info+0x12/0x56 [57560.396000] [] __alloc_pages+0x52/0x294 [57560.396000] [] show_uevent+0x0/0xd5 [57560.396000] [] dev_attr_show+0x15/0x18 [57560.396000] [] sysfs_read_file+0x87/0xd8 [57560.396000] [] sys_getxattr+0x46/0x4e [57560.396000] [] sysfs_read_file+0x0/0xd8 [57560.396000] [] vfs_read+0xa6/0x128 [57560.396000] [] sys_read+0x41/0x67 [57560.396000] [] syscall_call+0x7/0xb [57560.396000] === [57560.396000] Code: 74 24 28 73 03 c6 06 20 4d 46 85 ed 7f f1 e9 b9 00 00 00 8b 0f b8 79 e0 32 c0 8b 54 24 2c 81 f9 ff 0f 00 00 0f 46 c8 89 c8 eb 06 <80> 38 00 74 07 40 4a 83 fa ff 75 f4 29 c8 f6 44 24 30 10 89 c3 [57560.396000] EIP: [] vsnprintf+0x2af/0x48c SS:ESP 0068:edf09e4c > > > > and also with CFS but without CONFIG_FAIR_GROUP_SCHED. > > Is it still required since it now does not seems to be CFS related? > > Hi Ingo, > > I am able to reproduce the oops here on my system with > 2.6.22.14 + CFS backport. I am not able to reproduce it with > 2.6.22.13 + CFS backport. I believe the CFS backport is just > exposing the bug. Can't find an obvious culprit and am > looking into this issue. > > Vincent, could you please confirm if you are able to > reproduce this with > 2.6.22.13 + CFS? Using 2.6.13 + CFS v24 I was also able to reproduce the bug (I already had one built in my depot without the display_most-recently-opened_sysfs_file_name_when_oopsing.patch). So it looks like it is at least related to >= 2.6.22.13 and probably not directly CFS related. Note that to get a oops on a 2.6.13 it seems to need a full backup since it usually works with incremental. The backup does start properly then, in this case, at around 70% it oopsed. Using 2.6.22.14 it seems to oops right at startup. Here is the 2.6.22.13 CFS v24 oops: [ 170.152908] SGI XFS Quota Management subsystem [ 170.168443] Filesystem "drbd0": Disabling barriers, not supported by the underlying device [ 170.174964] XFS mounting filesystem drbd0 [ 170.232455] Ending clean XFS mount for filesystem: drbd0 [ 170.318614] Filesystem "drbd1": Disabling barriers, not supported by the underlying device [ 170.327708] XFS mounting filesystem drbd1 [ 170.380481] Ending clean XFS mount for filesystem: drbd1 [ 947.493764] BUG: unable to handle kernel NULL pointer dereference at virtual address 00c8 [ 947.493797] printing eip: [ 947.493810] c01a922c [ 947.493823] *pdpt = 2a97a001 [ 947.493837] *pde = [ 947.493852] Oops: [#1] [ 947.493865] SMP [ 947.493881]
RE: 2.6.22.14 oops msg with commvault galaxy ?
-Message d'origine- De : Dhaval Giani [mailto:[EMAIL PROTECTED] On Tue, Dec 11, 2007 at 10:06:53PM +0100, Ingo Molnar wrote: * Fortier,Vincent [Montreal] [EMAIL PROTECTED] wrote: That has changed from /sys/kernel/uids/uid/cpu_share Here is my config. Maybie I should give it a shot without CFS at all and see what happends ? It got triggerred also using a 2.6.22.14: [57560.396000] BUG: unable to handle kernel paging request at virtual address 8000 [57560.396000] printing eip: [57560.396000] c01d6c56 [57560.396000] *pdpt = 08d02001 [57560.396000] *pde = [57560.396000] Oops: [#34] [57560.396000] SMP [57560.396000] last sysfs file: /devices/platform/floppy.0/uevent [57560.396000] Modules linked in: xfs drbd cn nfs nfsd exportfs lockd nfs_acl sunrpc ppdev parport_pc lp parport button ac battery ipv6 fuse ide_cd ide_generic usbkbd usbmouse tsdev iTCO_wdt iTCO_vendor_support psmouse e752x_edac edac_mc serio_raw evdev pcspkr sg floppy shpchp pci_hotplug sr_mod cdrom ext3 jbd mbcache dm_mirror dm_snapshot dm_mod generic piix ide_core tg3 ata_piix ehci_hcd uhci_hcd usbcore thermal processor fan mptscsih mptbase megaraid_sas megaraid_mbox megaraid_mm cciss aacraid [57560.396000] CPU:2 [57560.396000] EIP:0060:[c01d6c56]Not tainted VLI [57560.396000] EFLAGS: 00010297 (2.6.22.14-etch-686-envcan #1) [57560.396000] EIP is at vsnprintf+0x2af/0x48c [57560.396000] eax: 8000 ebx: ecx: 8000 edx: fffe [57560.396000] esi: edf37017 edi: edf09eac ebp: esp: edf09e4c [57560.396000] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 [57560.396000] Process clBackup (pid: 31421, ti=edf08000 task=f7d36530 task.ti=edf08000) [57560.396000] Stack: c852b000 1000 c0338c78 f895b56c c0233bf5 c852b000 120c8fe8 edf37017 [57560.396000]00c3bd08 c03354eb 0003 0017 [57560.396000]c0376dc0 c852b000 c01d6eb4 edf09eac edf09eac c0233170 edf37017 c03354ea [57560.396000] Call Trace: [57560.396000] [c0233bf5] dev_uevent+0x189/0x1e0 [57560.396000] [c01d6eb4] sprintf+0x20/0x23 [57560.396000] [c0233170] show_uevent+0xad/0xd5 [57560.396000] [c0154f48] get_page_from_freelist+0x296/0x32d [57560.396000] [c012e6f0] group_send_sig_info+0x12/0x56 [57560.396000] [c0155031] __alloc_pages+0x52/0x294 [57560.396000] [c02330c3] show_uevent+0x0/0xd5 [57560.396000] [c0232c82] dev_attr_show+0x15/0x18 [57560.396000] [c01a6979] sysfs_read_file+0x87/0xd8 [57560.396000] [c0185f04] sys_getxattr+0x46/0x4e [57560.396000] [c01a68f2] sysfs_read_file+0x0/0xd8 [57560.396000] [c016fe03] vfs_read+0xa6/0x128 [57560.396000] [c01701ff] sys_read+0x41/0x67 [57560.396000] [c0103d8a] syscall_call+0x7/0xb [57560.396000] === [57560.396000] Code: 74 24 28 73 03 c6 06 20 4d 46 85 ed 7f f1 e9 b9 00 00 00 8b 0f b8 79 e0 32 c0 8b 54 24 2c 81 f9 ff 0f 00 00 0f 46 c8 89 c8 eb 06 80 38 00 74 07 40 4a 83 fa ff 75 f4 29 c8 f6 44 24 30 10 89 c3 [57560.396000] EIP: [c01d6c56] vsnprintf+0x2af/0x48c SS:ESP 0068:edf09e4c and also with CFS but without CONFIG_FAIR_GROUP_SCHED. Is it still required since it now does not seems to be CFS related? Hi Ingo, I am able to reproduce the oops here on my system with 2.6.22.14 + CFS backport. I am not able to reproduce it with 2.6.22.13 + CFS backport. I believe the CFS backport is just exposing the bug. Can't find an obvious culprit and am looking into this issue. Vincent, could you please confirm if you are able to reproduce this with 2.6.22.13 + CFS? Using 2.6.13 + CFS v24 I was also able to reproduce the bug (I already had one built in my depot without the display_most-recently-opened_sysfs_file_name_when_oopsing.patch). So it looks like it is at least related to = 2.6.22.13 and probably not directly CFS related. Note that to get a oops on a 2.6.13 it seems to need a full backup since it usually works with incremental. The backup does start properly then, in this case, at around 70% it oopsed. Using 2.6.22.14 it seems to oops right at startup. Here is the 2.6.22.13 CFS v24 oops: [ 170.152908] SGI XFS Quota Management subsystem [ 170.168443] Filesystem drbd0: Disabling barriers, not supported by the underlying device [ 170.174964] XFS mounting filesystem drbd0 [ 170.232455] Ending clean XFS mount for filesystem: drbd0 [ 170.318614] Filesystem drbd1: Disabling barriers, not supported by the underlying device [ 170.327708] XFS mounting filesystem drbd1 [ 170.380481] Ending clean XFS mount for filesystem: drbd1 [ 947.493764] BUG: unable to handle kernel NULL pointer dereference at virtual address 00c8 [ 947.493797] printing eip: [ 947.493810] c01a922c [ 947.493823] *pdpt = 2a97a001 [ 947.493837] *pde = [ 947.493852] Oops: [#1] [ 947.493865] SMP [ 947.493881] Modules linked in: xfs drbd cn nfs nfsd exportfs lockd nfs_acl sunrpc ppdev parport_pc lp parport
RE: 2.6.22.14 oops msg with commvault galaxy ?
-Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Fortier,Vincent [Montreal] -Message d'origine- De : Dhaval Giani [mailto:[EMAIL PROTECTED] On Tue, Dec 11, 2007 at 10:06:53PM +0100, Ingo Molnar wrote: * Fortier,Vincent [Montreal] [EMAIL PROTECTED] wrote: That has changed from /sys/kernel/uids/uid/cpu_share Here is my config. Maybie I should give it a shot without CFS at all and see what happends ? It got triggerred also using a 2.6.22.14: Just to clarify... this is a non CFS kernel oops... [57560.396000] BUG: unable to handle kernel paging request at virtual address 8000 [57560.396000] printing eip: [57560.396000] c01d6c56 [57560.396000] *pdpt = 08d02001 [57560.396000] *pde = [57560.396000] Oops: [#34] [57560.396000] SMP [57560.396000] last sysfs file: /devices/platform/floppy.0/uevent [57560.396000] Modules linked in: xfs drbd cn nfs nfsd exportfs lockd nfs_acl sunrpc ppdev parport_pc lp parport button ac battery ipv6 fuse ide_cd ide_generic usbkbd usbmouse tsdev iTCO_wdt iTCO_vendor_support psmouse e752x_edac edac_mc serio_raw evdev pcspkr sg floppy shpchp pci_hotplug sr_mod cdrom ext3 jbd mbcache dm_mirror dm_snapshot dm_mod generic piix ide_core tg3 ata_piix ehci_hcd uhci_hcd usbcore thermal processor fan mptscsih mptbase megaraid_sas megaraid_mbox megaraid_mm cciss aacraid [57560.396000] CPU:2 [57560.396000] EIP:0060:[c01d6c56]Not tainted VLI [57560.396000] EFLAGS: 00010297 (2.6.22.14-etch-686-envcan #1) [57560.396000] EIP is at vsnprintf+0x2af/0x48c [57560.396000] eax: 8000 ebx: ecx: 8000 edx: fffe [57560.396000] esi: edf37017 edi: edf09eac ebp: esp: edf09e4c [57560.396000] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 [57560.396000] Process clBackup (pid: 31421, ti=edf08000 task=f7d36530 task.ti=edf08000) [57560.396000] Stack: c852b000 1000 c0338c78 f895b56c c0233bf5 c852b000 120c8fe8 edf37017 [57560.396000]00c3bd08 c03354eb 0003 0017 [57560.396000]c0376dc0 c852b000 c01d6eb4 edf09eac edf09eac c0233170 edf37017 c03354ea [57560.396000] Call Trace: [57560.396000] [c0233bf5] dev_uevent+0x189/0x1e0 [57560.396000] [c01d6eb4] sprintf+0x20/0x23 [57560.396000] [c0233170] show_uevent+0xad/0xd5 [57560.396000] [c0154f48] get_page_from_freelist+0x296/0x32d [57560.396000] [c012e6f0] group_send_sig_info+0x12/0x56 [57560.396000] [c0155031] __alloc_pages+0x52/0x294 [57560.396000] [c02330c3] show_uevent+0x0/0xd5 [57560.396000] [c0232c82] dev_attr_show+0x15/0x18 [57560.396000] [c01a6979] sysfs_read_file+0x87/0xd8 [57560.396000] [c0185f04] sys_getxattr+0x46/0x4e [57560.396000] [c01a68f2] sysfs_read_file+0x0/0xd8 [57560.396000] [c016fe03] vfs_read+0xa6/0x128 [57560.396000] [c01701ff] sys_read+0x41/0x67 [57560.396000] [c0103d8a] syscall_call+0x7/0xb [57560.396000] === [57560.396000] Code: 74 24 28 73 03 c6 06 20 4d 46 85 ed 7f f1 e9 b9 00 00 00 8b 0f b8 79 e0 32 c0 8b 54 24 2c 81 f9 ff 0f 00 00 0f 46 c8 89 c8 eb 06 80 38 00 74 07 40 4a 83 fa ff 75 f4 29 c8 f6 44 24 30 10 89 c3 [57560.396000] EIP: [c01d6c56] vsnprintf+0x2af/0x48c SS:ESP 0068:edf09e4c and also with CFS but without CONFIG_FAIR_GROUP_SCHED. Is it still required since it now does not seems to be CFS related? Hi Ingo, I am able to reproduce the oops here on my system with 2.6.22.14 + CFS backport. I am not able to reproduce it with 2.6.22.13 + CFS backport. I believe the CFS backport is just exposing the bug. Can't find an obvious culprit and am looking into this issue. Vincent, could you please confirm if you are able to reproduce this with 2.6.22.13 + CFS? Using 2.6.13 + CFS v24 I was also able to reproduce the bug (I already had one built in my depot without the display_most-recently-opened_sysfs_file_name_when_oopsing.patc h). So it looks like it is at least related to = 2.6.22.13 and probably not directly CFS related. Note that to get a oops on a 2.6.13 it seems to need a full backup since it usually works with incremental. The backup does start properly then, in this case, at around 70% it oopsed. Using 2.6.22.14 it seems to oops right at startup. Here is the 2.6.22.13 CFS v24 oops: Again, just to clarify, I'm not even sure the backup worked at all using a 2.6.22.13 CFS v24 since I already had a previous pending full backup at 70% ... so it may simply had tried to finalize that one and crash right at startup? [ 170.152908] SGI XFS Quota Management subsystem [ 170.168443] Filesystem drbd0: Disabling barriers, not supported by the underlying device [ 170.174964] XFS mounting filesystem drbd0 [ 170.232455] Ending clean XFS mount for filesystem: drbd0 [ 170.318614] Filesystem drbd1
RE: 2.6.22.14 oops msg with commvault galaxy ?
-Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Dhaval Giani On Wed, Dec 12, 2007 at 07:57:33AM -0500, Fortier,Vincent [Montreal] wrote: -Message d'origine- De : Dhaval Giani [mailto:[EMAIL PROTECTED] On Tue, Dec 11, 2007 at 10:06:53PM +0100, Ingo Molnar wrote: * Fortier,Vincent [Montreal] [EMAIL PROTECTED] wrote: That has changed from /sys/kernel/uids/uid/cpu_share Here is my config. Maybie I should give it a shot without CFS at all and see what happends ? It got triggerred also using a 2.6.22.14: Here are my preliminary test results: 2.6.21.7: OK 2.6.22.13/14: Failure 2.6.23.9: OK 2.6.24-rc5-git2: OK It seems to only hang using a 2.6.22 kernel. No, not any more. Would it be possible for you to do a git-bisect? I am not too well versed with sysfs, so it is not apparent to me what is causing this oops. It seems to be easily reproducible. I don't still have a reliable method to reproduce it without the CFS patch. Could sysfs experts please help debugging? I seriously doubt I have the time to do a git-bisect at the moment - vin -- 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.22.14 oops msg with commvault galaxy ?
> -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] De la part de Dhaval Giani > > On Tue, Dec 11, 2007 at 09:04:00AM -0800, Greg KH wrote: > > On Tue, Dec 11, 2007 at 10:13:19PM +0530, Dhaval Giani wrote: > > > On Tue, Dec 11, 2007 at 08:24:37PM +0530, Dhaval Giani wrote: > > > > On Mon, Dec 10, 2007 at 09:15:01AM -0800, Randy Dunlap wrote: > > > > > On Mon, 10 Dec 2007 09:03:17 -0500 Fortier,Vincent wrote: > > > > > > > > > > Ingo, can you look at this, please? > > > > > Vincent is getting oopses on 2.6.22.14-cfs-etch. > > > > > > > > > > > > > Hi, > > > > > > > > We are looking into this bug now. I believe that the patch at > > > > http://marc.info/?l=linux-kernel=119404922603293 should help. > > > > > > > > I am working with Kay to get this ported. > > > > > > > > > > Hi Vincent, > > > > > > Does the following patch help? > > > > > > Kay/Greg, could you please review and add your Signed-off-by(s) as > > > required? > > > > Um, why? What is this patch for? Where is it to be sent, to Linus > > for 2.6.24-final? Or to the -stable tree? > > > > Hi Greg, > > This is for 2.26.24-final, since Fair User scheduling is not > yet there in stable. > > > > This is basically a port of the patch at > > > http://marc.info/?l=linux-kernel=119404922603293 > > > > Yeah, but that patch needs some other core kobject changes, right? > > > > Yep, there are some other changes that patch needed. We have > worked around them by using the existing functions in the > current Linus tree. > > > What exactly are you trying to fix here, the fact that this code never > > even worked? > > > > The code was not using the kobject API. Its been cleaned up now (I > hope!) It refused to apply cleanly on a 2.6.22.14 + CFS v24, only one failure occured. So I resolved it manually and attached the resulting diff. My tests with Galaxy 5.9 shows that it still does not work. Although, the error seems to have changed a bit (see attached dmesg) > > And, please, we need some documentation for Documenatation/ABI/ on > > exactly what these sysfs files and tree is for. Please add that now > > for Linus's tree. > > On to it, will send the patch asap. > > > confused, > > hope i helped (in clearing it :) ) Should this patch eventually be included in? 2.6.25 ? 2.6.24 ? (-stable 2.6.23 & 2.6.22) || backport CFS v24 -> v25? Thnx, - vin dmesg.2.6.22.14-CFSv24-FairUserInterfaceBUGfix Description: dmesg.2.6.22.14-CFSv24-FairUserInterfaceBUGfix FairUserInterface-BugFix.patch Description: FairUserInterface-BugFix.patch
RE: 2.6.22.14 oops msg with commvault galaxy ?
-Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Dhaval Giani On Tue, Dec 11, 2007 at 09:04:00AM -0800, Greg KH wrote: On Tue, Dec 11, 2007 at 10:13:19PM +0530, Dhaval Giani wrote: On Tue, Dec 11, 2007 at 08:24:37PM +0530, Dhaval Giani wrote: On Mon, Dec 10, 2007 at 09:15:01AM -0800, Randy Dunlap wrote: On Mon, 10 Dec 2007 09:03:17 -0500 Fortier,Vincent wrote: Ingo, can you look at this, please? Vincent is getting oopses on 2.6.22.14-cfs-etch. Hi, We are looking into this bug now. I believe that the patch at http://marc.info/?l=linux-kernelm=119404922603293 should help. I am working with Kay to get this ported. Hi Vincent, Does the following patch help? Kay/Greg, could you please review and add your Signed-off-by(s) as required? Um, why? What is this patch for? Where is it to be sent, to Linus for 2.6.24-final? Or to the -stable tree? Hi Greg, This is for 2.26.24-final, since Fair User scheduling is not yet there in stable. This is basically a port of the patch at http://marc.info/?l=linux-kernelm=119404922603293 Yeah, but that patch needs some other core kobject changes, right? Yep, there are some other changes that patch needed. We have worked around them by using the existing functions in the current Linus tree. What exactly are you trying to fix here, the fact that this code never even worked? The code was not using the kobject API. Its been cleaned up now (I hope!) It refused to apply cleanly on a 2.6.22.14 + CFS v24, only one failure occured. So I resolved it manually and attached the resulting diff. My tests with Galaxy 5.9 shows that it still does not work. Although, the error seems to have changed a bit (see attached dmesg) And, please, we need some documentation for Documenatation/ABI/ on exactly what these sysfs files and tree is for. Please add that now for Linus's tree. On to it, will send the patch asap. confused, hope i helped (in clearing it :) ) Should this patch eventually be included in? 2.6.25 ? 2.6.24 ? (-stable 2.6.23 2.6.22) || backport CFS v24 - v25? Thnx, - vin dmesg.2.6.22.14-CFSv24-FairUserInterfaceBUGfix Description: dmesg.2.6.22.14-CFSv24-FairUserInterfaceBUGfix FairUserInterface-BugFix.patch Description: FairUserInterface-BugFix.patch
RE: 2.6.22.14 oops msg with commvault galaxy ?
> -Message d'origine- > De : Randy Dunlap [mailto:[EMAIL PROTECTED] > Envoyé : 10 décembre 2007 12:15 > > On Mon, 10 Dec 2007 09:03:17 -0500 Fortier,Vincent [Montreal] wrote: > > Ingo, can you look at this, please? > Vincent is getting oopses on 2.6.22.14-cfs-etch. > > Vincent, did you apply the cfs patch or did Debian etch provide that? I did. http://linux-dev.qc.ec.gc.ca/ > If you applied it, did you use > http://people.redhat.com/mingo/cfs-scheduler/sched-cfs-v2.6.22.13-v24.patch > or a different patch? > I applied exactly that one.. and had already sent that info to ingo this morning since I presumed the CFS patchset could be involved in this by reagarding the more detailed output. Also note that CFS v24 on 2.6.21 does not produce the oops and I can run galaxy backups on the system without any problems. - vin -- 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.22.14 oops msg with commvault galaxy ?
> -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] De la part de > Fortier,Vincent [Montreal] > Envoyé : 10 décembre 2007 08:21 > À : Randy Dunlap; Andrew Morton > Cc : linux-kernel@vger.kernel.org > Objet : RE: 2.6.22.14 oops msg with commvault galaxy ? > > > -Message d'origine- > > De : Randy Dunlap [mailto:[EMAIL PROTECTED] Envoyé : > 7 décembre > > 2007 20:15 > > > > On Fri, 7 Dec 2007 15:11:13 -0800 Andrew Morton wrote: > > > > > On Fri, 7 Dec 2007 14:15:36 -0800 > > > Randy Dunlap <[EMAIL PROTECTED]> wrote: > > > > > > > > Help would really be appreciated. > > > > > > > > Let's try the last_sysfs_file (name) patch. > > > > I've attempted to update it for 2.6.22.14. > > > > Andrew, does this change in fs/sysfs/file.c look OK? > > > > > > umm, yup. > > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-r > > > > > > c6/2.6.21-rc6-mm1/broken-out/gregkh-driver-sysfs-crash-debugging.patch > > > > > > should work. > > > > Thanks. > > I produced a cleanly applying version of it for 2.6.22.14. > > > > Vincent, please apply this patch so we can know which file in sysfs > > these oopses are happening with. > > > > It did not applied cleanly on a 2.6.22.14... copy/paste might > be the issue here... Anyhow, I corrected the patch failure to > apply and here is my version of it... Hoping I got this > (attached patch). > > Compiling at the moment... will try this out with commvault > 5.9 probably in the morning and get back with the results. > > Let me know I got the patch wrong. Here is the resulting trace... hoping this helps...: [ 942.107304] BUG: unable to handle kernel NULL pointer dereference at virtual address 00c8 [ 942.107339] printing eip: [ 942.107354] c01a924c [ 942.107368] *pdpt = 2d6b4001 [ 942.107383] *pde = [ 942.107401] Oops: [#1] [ 942.107414] SMP [ 942.107431] last sysfs file: /kernel/uids/104/cpu_share [ 942.107449] Modules linked in: xfs drbd cn nfs nfsd exportfs lockd nfs_acl sunrpc ppdev parport_pc lp parport button ac battery ipv6 fuse ide_cd ide_generic usbkbd usbmouse tsdev sg iTCO_wdt iTCO_vendor_support e752x_edac edac_mc psmouse floppy shpchp pci_hotplug serio_raw sr_mod pcspkr evdev cdrom ext3 jbd mbcache dm_mirror dm_snapshot dm_mod generic piix ide_core ehci_hcd uhci_hcd usbcore ata_piix tg3 thermal processor fan mptscsih mptbase megaraid_sas megaraid_mbox megaraid_mm cciss aacraid [ 942.107675] CPU:0 [ 942.107676] EIP:0060:[]Not tainted VLI [ 942.107678] EFLAGS: 00010202 (2.6.22.14-cfs-etch-686-envcan #1) [ 942.107730] EIP is at sysfs_open_file+0xae/0x21e [ 942.107749] eax: ebx: f77783b8 ecx: dfb0b280 edx: 00c8 [ 942.107769] esi: f7e0ce8c edi: c03fd5c0 ebp: c01a919e esp: f1257ed8 [ 942.107789] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 [ 942.107810] Process clBackup (pid: 5191, ti=f1256000 task=f71b3290 task.ti=f1256000) [ 942.107831] Stack: 1000 f295d240 ed4f4ac0 f7e0ce48 f295d240 ed4f4ac0 f1257f30 c01a919e [ 942.107878]c0170464 dfe76100 ed4f3880 f295d240 8000 f1257f30 0010 c0170595 [ 942.107921]f295d240 c01705d6 f1257f30 ed4f3880 dfe76100 [ 942.107968] Call Trace: [ 942.107998] [] sysfs_open_file+0x0/0x21e [ 942.108017] [] __dentry_open+0xc1/0x178 [ 942.108039] [] nameidata_to_filp+0x24/0x33 [ 942.108063] [] do_filp_open+0x32/0x39 [ 942.108088] [] get_unused_fd+0x4a/0xaa [ 942.108112] [] do_sys_open+0x42/0xc3 [ 942.108134] [] sys_open+0x1c/0x1e [ 942.108155] [] syscall_call+0x7/0xb [ 942.108179] === [ 942.108194] Code: b8 c0 c5 3f c0 41 e8 e8 06 03 00 83 7c 24 0c 00 0f 84 72 01 00 00 85 f6 0f 84 6a 01 00 00 8b 56 04 85 d2 74 19 64 a1 08 50 3d c0 <83> 3a 02 0f 84 44 01 00 00 c1 e0 05 ff 84 10 20 01 00 00 8b 54 [ 942.108364] EIP: [] sysfs_open_file+0xae/0x21e SS:ESP 0068:f1257ed8 - vin -- 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.22.14 oops msg with commvault galaxy ?
> -Message d'origine- > De : Randy Dunlap [mailto:[EMAIL PROTECTED] > Envoyé : 7 décembre 2007 20:15 > > On Fri, 7 Dec 2007 15:11:13 -0800 Andrew Morton wrote: > > > On Fri, 7 Dec 2007 14:15:36 -0800 > > Randy Dunlap <[EMAIL PROTECTED]> wrote: > > > > > > Help would really be appreciated. > > > > > > Let's try the last_sysfs_file (name) patch. > > > I've attempted to update it for 2.6.22.14. > > > Andrew, does this change in fs/sysfs/file.c look OK? > > > > umm, yup. > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-r > > > c6/2.6.21-rc6-mm1/broken-out/gregkh-driver-sysfs-crash-debugging.patch > > > > should work. > > Thanks. > I produced a cleanly applying version of it for 2.6.22.14. > > Vincent, please apply this patch so we can know which file in > sysfs these oopses are happening with. > It did not applied cleanly on a 2.6.22.14... copy/paste might be the issue here... Anyhow, I corrected the patch failure to apply and here is my version of it... Hoping I got this (attached patch). Compiling at the moment... will try this out with commvault 5.9 probably in the morning and get back with the results. Let me know I got the patch wrong. - vin display_most-recently-opened_sysfs_file_name_when_oopsing.patch Description: display_most-recently-opened_sysfs_file_name_when_oopsing.patch
RE: 2.6.22.14 oops msg with commvault galaxy ?
-Message d'origine- De : Randy Dunlap [mailto:[EMAIL PROTECTED] Envoyé : 7 décembre 2007 20:15 On Fri, 7 Dec 2007 15:11:13 -0800 Andrew Morton wrote: On Fri, 7 Dec 2007 14:15:36 -0800 Randy Dunlap [EMAIL PROTECTED] wrote: Help would really be appreciated. Let's try the last_sysfs_file (name) patch. I've attempted to update it for 2.6.22.14. Andrew, does this change in fs/sysfs/file.c look OK? umm, yup. ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-r c6/2.6.21-rc6-mm1/broken-out/gregkh-driver-sysfs-crash-debugging.patch should work. Thanks. I produced a cleanly applying version of it for 2.6.22.14. Vincent, please apply this patch so we can know which file in sysfs these oopses are happening with. It did not applied cleanly on a 2.6.22.14... copy/paste might be the issue here... Anyhow, I corrected the patch failure to apply and here is my version of it... Hoping I got this (attached patch). Compiling at the moment... will try this out with commvault 5.9 probably in the morning and get back with the results. Let me know I got the patch wrong. - vin display_most-recently-opened_sysfs_file_name_when_oopsing.patch Description: display_most-recently-opened_sysfs_file_name_when_oopsing.patch
RE: 2.6.22.14 oops msg with commvault galaxy ?
-Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Fortier,Vincent [Montreal] Envoyé : 10 décembre 2007 08:21 À : Randy Dunlap; Andrew Morton Cc : linux-kernel@vger.kernel.org Objet : RE: 2.6.22.14 oops msg with commvault galaxy ? -Message d'origine- De : Randy Dunlap [mailto:[EMAIL PROTECTED] Envoyé : 7 décembre 2007 20:15 On Fri, 7 Dec 2007 15:11:13 -0800 Andrew Morton wrote: On Fri, 7 Dec 2007 14:15:36 -0800 Randy Dunlap [EMAIL PROTECTED] wrote: Help would really be appreciated. Let's try the last_sysfs_file (name) patch. I've attempted to update it for 2.6.22.14. Andrew, does this change in fs/sysfs/file.c look OK? umm, yup. ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-r c6/2.6.21-rc6-mm1/broken-out/gregkh-driver-sysfs-crash-debugging.patch should work. Thanks. I produced a cleanly applying version of it for 2.6.22.14. Vincent, please apply this patch so we can know which file in sysfs these oopses are happening with. It did not applied cleanly on a 2.6.22.14... copy/paste might be the issue here... Anyhow, I corrected the patch failure to apply and here is my version of it... Hoping I got this (attached patch). Compiling at the moment... will try this out with commvault 5.9 probably in the morning and get back with the results. Let me know I got the patch wrong. Here is the resulting trace... hoping this helps...: [ 942.107304] BUG: unable to handle kernel NULL pointer dereference at virtual address 00c8 [ 942.107339] printing eip: [ 942.107354] c01a924c [ 942.107368] *pdpt = 2d6b4001 [ 942.107383] *pde = [ 942.107401] Oops: [#1] [ 942.107414] SMP [ 942.107431] last sysfs file: /kernel/uids/104/cpu_share [ 942.107449] Modules linked in: xfs drbd cn nfs nfsd exportfs lockd nfs_acl sunrpc ppdev parport_pc lp parport button ac battery ipv6 fuse ide_cd ide_generic usbkbd usbmouse tsdev sg iTCO_wdt iTCO_vendor_support e752x_edac edac_mc psmouse floppy shpchp pci_hotplug serio_raw sr_mod pcspkr evdev cdrom ext3 jbd mbcache dm_mirror dm_snapshot dm_mod generic piix ide_core ehci_hcd uhci_hcd usbcore ata_piix tg3 thermal processor fan mptscsih mptbase megaraid_sas megaraid_mbox megaraid_mm cciss aacraid [ 942.107675] CPU:0 [ 942.107676] EIP:0060:[c01a924c]Not tainted VLI [ 942.107678] EFLAGS: 00010202 (2.6.22.14-cfs-etch-686-envcan #1) [ 942.107730] EIP is at sysfs_open_file+0xae/0x21e [ 942.107749] eax: ebx: f77783b8 ecx: dfb0b280 edx: 00c8 [ 942.107769] esi: f7e0ce8c edi: c03fd5c0 ebp: c01a919e esp: f1257ed8 [ 942.107789] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 [ 942.107810] Process clBackup (pid: 5191, ti=f1256000 task=f71b3290 task.ti=f1256000) [ 942.107831] Stack: 1000 f295d240 ed4f4ac0 f7e0ce48 f295d240 ed4f4ac0 f1257f30 c01a919e [ 942.107878]c0170464 dfe76100 ed4f3880 f295d240 8000 f1257f30 0010 c0170595 [ 942.107921]f295d240 c01705d6 f1257f30 ed4f3880 dfe76100 [ 942.107968] Call Trace: [ 942.107998] [c01a919e] sysfs_open_file+0x0/0x21e [ 942.108017] [c0170464] __dentry_open+0xc1/0x178 [ 942.108039] [c0170595] nameidata_to_filp+0x24/0x33 [ 942.108063] [c01705d6] do_filp_open+0x32/0x39 [ 942.108088] [c0170343] get_unused_fd+0x4a/0xaa [ 942.108112] [c017061f] do_sys_open+0x42/0xc3 [ 942.108134] [c01706d9] sys_open+0x1c/0x1e [ 942.108155] [c0103d8a] syscall_call+0x7/0xb [ 942.108179] === [ 942.108194] Code: b8 c0 c5 3f c0 41 e8 e8 06 03 00 83 7c 24 0c 00 0f 84 72 01 00 00 85 f6 0f 84 6a 01 00 00 8b 56 04 85 d2 74 19 64 a1 08 50 3d c0 83 3a 02 0f 84 44 01 00 00 c1 e0 05 ff 84 10 20 01 00 00 8b 54 [ 942.108364] EIP: [c01a924c] sysfs_open_file+0xae/0x21e SS:ESP 0068:f1257ed8 - vin -- 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.22.14 oops msg with commvault galaxy ?
-Message d'origine- De : Randy Dunlap [mailto:[EMAIL PROTECTED] Envoyé : 10 décembre 2007 12:15 On Mon, 10 Dec 2007 09:03:17 -0500 Fortier,Vincent [Montreal] wrote: Ingo, can you look at this, please? Vincent is getting oopses on 2.6.22.14-cfs-etch. Vincent, did you apply the cfs patch or did Debian etch provide that? I did. http://linux-dev.qc.ec.gc.ca/ If you applied it, did you use http://people.redhat.com/mingo/cfs-scheduler/sched-cfs-v2.6.22.13-v24.patch or a different patch? I applied exactly that one.. and had already sent that info to ingo this morning since I presumed the CFS patchset could be involved in this by reagarding the more detailed output. Also note that CFS v24 on 2.6.21 does not produce the oops and I can run galaxy backups on the system without any problems. - vin -- 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.22.14 oops msg with commvault galaxy ?
> -Message d'origine- > De : Randy Dunlap [mailto:[EMAIL PROTECTED] > Envoyé : 30 novembre 2007 12:13 > > On Fri, 30 Nov 2007 13:02:54 + Vincent Fortier wrote: > > > Hi all, > > > > I'm using a 2.6.22.14 + CFS v24 and I got theses errors > when starting > > up my commvault galaxy client... Do anybody know what this could mean? > > Can you provide a few lines of syslog before the Oops: line, > which should contain some info about what happened, e.g.: > > Unable to handle kernel paging request at virtual address > e4a85017 printing eip: > c01d915a > *pde = 37d0d067 > *pte = Would this be better? [766535.379600] BUG: unable to handle kernel NULL pointer dereference at virtual address 00c8 [766535.379636] printing eip: [766535.379652] c01a920c [766535.379665] *pdpt = 1cc2c001 [766535.379681] *pde = [766535.379698] Oops: [#1] [766535.379713] SMP [766535.379729] Modules linked in: xfs drbd cn nfs nfsd exportfs lockd nfs_acl sunrpc ppdev parport_pc lp parport button ac battery ipv6 fuse ide_cd ide_generic usbkbd usbmouse tsdev sg iTCO_wdt iTCO_vendor_support psmouse e752x_edac shpchp serio_raw edac_mc pcspkr evdev sr_mod pci_hotplug floppy cdrom ext3 jbd mbcache dm_mirror dm_snapshot dm_mod generic piix ide_core ehci_hcd uhci_hcd ata_piix tg3 usbcore thermal processor fan mptscsih mptbase megaraid_sas megaraid_mbox megaraid_mm cciss aacraid [766535.379956] CPU:0 [766535.379957] EIP:0060:[]Not tainted VLI [766535.379959] EFLAGS: 00010202 (2.6.22.14-cfs-etch-686-envcan #1) [766535.380011] EIP is at sysfs_open_file+0x78/0x1e4 [766535.380028] eax: ebx: f7f02e58 ecx: 000d edx: 00c8 [766535.380049] esi: f7e7ec8c edi: defadf30 ebp: c01a9194 esp: defadedc [766535.380070] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 [766535.380091] Process clBackup (pid: 22085, ti=defac000 task=de01ac60 task.ti=defac000) [766535.380110] Stack: de093300 dd2ce408 f7e7ec48 de093300 dd2ce408 defadf30 c01a9194 c017048c [766535.380155]dfe8a180 dd2cbd48 de093300 8000 defadf30 000d c01705bd de093300 [766535.380202] c01705fe defadf30 dd2cbd48 dfe8a180 e0bd6f00 [766535.380246] Call Trace: [766535.380276] [] sysfs_open_file+0x0/0x1e4 [766535.380296] [] __dentry_open+0xc1/0x178 [766535.380321] [] nameidata_to_filp+0x24/0x33 [766535.380343] [] do_filp_open+0x32/0x39 [766535.380367] [] get_unused_fd+0x4a/0xaa [766535.380390] [] do_sys_open+0x42/0xc3 [766535.380413] [] sys_open+0x1c/0x1e [766535.380434] [] syscall_call+0x7/0xb [766535.380460] === [766535.380476] Code: 14 24 83 7c 24 08 00 8b 42 0c 8b 40 54 8b 70 14 0f 84 70 01 00 00 85 f6 0f 84 68 01 00 00 8b 56 04 85 d2 74 19 64 a1 08 50 3d c0 <83> 3a 02 0f 84 42 01 00 00 c1 e0 05 ff 84 10 20 01 00 00 8b 54 [766535.380644] EIP: [] sysfs_open_file+0x78/0x1e4 SS:ESP 0068:defadedc Again, > > > > thnx very much! > - vin - 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.22.14 oops msg with commvault galaxy ?
-Message d'origine- De : Randy Dunlap [mailto:[EMAIL PROTECTED] Envoyé : 30 novembre 2007 12:13 On Fri, 30 Nov 2007 13:02:54 + Vincent Fortier wrote: Hi all, I'm using a 2.6.22.14 + CFS v24 and I got theses errors when starting up my commvault galaxy client... Do anybody know what this could mean? Can you provide a few lines of syslog before the Oops: line, which should contain some info about what happened, e.g.: Unable to handle kernel paging request at virtual address e4a85017 printing eip: c01d915a *pde = 37d0d067 *pte = Would this be better? [766535.379600] BUG: unable to handle kernel NULL pointer dereference at virtual address 00c8 [766535.379636] printing eip: [766535.379652] c01a920c [766535.379665] *pdpt = 1cc2c001 [766535.379681] *pde = [766535.379698] Oops: [#1] [766535.379713] SMP [766535.379729] Modules linked in: xfs drbd cn nfs nfsd exportfs lockd nfs_acl sunrpc ppdev parport_pc lp parport button ac battery ipv6 fuse ide_cd ide_generic usbkbd usbmouse tsdev sg iTCO_wdt iTCO_vendor_support psmouse e752x_edac shpchp serio_raw edac_mc pcspkr evdev sr_mod pci_hotplug floppy cdrom ext3 jbd mbcache dm_mirror dm_snapshot dm_mod generic piix ide_core ehci_hcd uhci_hcd ata_piix tg3 usbcore thermal processor fan mptscsih mptbase megaraid_sas megaraid_mbox megaraid_mm cciss aacraid [766535.379956] CPU:0 [766535.379957] EIP:0060:[c01a920c]Not tainted VLI [766535.379959] EFLAGS: 00010202 (2.6.22.14-cfs-etch-686-envcan #1) [766535.380011] EIP is at sysfs_open_file+0x78/0x1e4 [766535.380028] eax: ebx: f7f02e58 ecx: 000d edx: 00c8 [766535.380049] esi: f7e7ec8c edi: defadf30 ebp: c01a9194 esp: defadedc [766535.380070] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 [766535.380091] Process clBackup (pid: 22085, ti=defac000 task=de01ac60 task.ti=defac000) [766535.380110] Stack: de093300 dd2ce408 f7e7ec48 de093300 dd2ce408 defadf30 c01a9194 c017048c [766535.380155]dfe8a180 dd2cbd48 de093300 8000 defadf30 000d c01705bd de093300 [766535.380202] c01705fe defadf30 dd2cbd48 dfe8a180 e0bd6f00 [766535.380246] Call Trace: [766535.380276] [c01a9194] sysfs_open_file+0x0/0x1e4 [766535.380296] [c017048c] __dentry_open+0xc1/0x178 [766535.380321] [c01705bd] nameidata_to_filp+0x24/0x33 [766535.380343] [c01705fe] do_filp_open+0x32/0x39 [766535.380367] [c017036b] get_unused_fd+0x4a/0xaa [766535.380390] [c0170647] do_sys_open+0x42/0xc3 [766535.380413] [c0170701] sys_open+0x1c/0x1e [766535.380434] [c0103d8a] syscall_call+0x7/0xb [766535.380460] === [766535.380476] Code: 14 24 83 7c 24 08 00 8b 42 0c 8b 40 54 8b 70 14 0f 84 70 01 00 00 85 f6 0f 84 68 01 00 00 8b 56 04 85 d2 74 19 64 a1 08 50 3d c0 83 3a 02 0f 84 42 01 00 00 c1 e0 05 ff 84 10 20 01 00 00 8b 54 [766535.380644] EIP: [c01a920c] sysfs_open_file+0x78/0x1e4 SS:ESP 0068:defadedc Again, thnx very much! - vin - 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/backport] CFS scheduler, -v24, for v2.6.24-rc3,v2.6.23.8, v2.6.22.13, v2.6.21.7
> -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] De la part de Ingo Molnar > > > * Erik Andersen <[EMAIL PROTECTED]> wrote: > > > On Mon Nov 19, 2007 at 04:17:56PM +0100, Ingo Molnar wrote: > > > > > > By popular demand, here is release -v24 of the CFS > scheduler patch. > > > > > > It is a full backport of the latest & greatest scheduler code to > > > v2.6.24-rc3, v2.6.23.8, v2.6.22.13, v2.6.21.7. The patches can be > > > downloaded from the usual place: > > > > > > http://people.redhat.com/mingo/cfs-scheduler/ > > > > Doesn't compile with 2.6.21.7: > > does the patch below help? > Looks good. Compiling. - vin - 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/backport] CFS scheduler, -v24, for v2.6.24-rc3, v2.6.23.8,v2.6.22.13, v2.6.21.7
> -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] De la part de Ingo Molnar > > By popular demand, here is release -v24 of the CFS scheduler patch. > > It is a full backport of the latest & greatest scheduler code > to v2.6.24-rc3, v2.6.23.8, v2.6.22.13, v2.6.21.7. The patches > can be downloaded from the usual place: > > http://people.redhat.com/mingo/cfs-scheduler/ > > There's tons of changes since v22 was released: > > 36 files changed, 2359 insertions(+), 1082 deletions(-) > > that's 187 individual commits from 32 authors. > > So even if CFS v22 worked well for you, please try this > release too and report regressions (if any). > Hi Ingo, Thnx a lot for theses backports... Ran into this while compiling a 2.6.22.13 with CFS v24 CC kernel/sched.o kernel/sched.c: In function 'cpu_to_core_group': kernel/sched.c:6056: error: 'per_cpu__cpu_sibling_map' undeclared (first use in this function) kernel/sched.c:6056: error: (Each undeclared identifier is reported only once kernel/sched.c:6056: error: for each function it appears in.) kernel/sched.c:6056: warning: type defaults to 'int' in declaration of 'type name' kernel/sched.c:6056: error: invalid type argument of 'unary *' kernel/sched.c: In function 'build_sched_domains': kernel/sched.c:6319: error: 'per_cpu__cpu_sibling_map' undeclared (first use in this function) kernel/sched.c:6319: warning: type defaults to 'int' in declaration of 'type name' kernel/sched.c:6319: error: invalid type argument of 'unary *' kernel/sched.c:6330: warning: type defaults to 'int' in declaration of 'type name' kernel/sched.c:6330: error: invalid type argument of 'unary *' make[2]: *** [kernel/sched.o] Error 1 make[1]: *** [kernel] Error 2 make[1]: Leaving directory `/usr/src/linux-headers-2.6.22.13-cfs-sarge-686-envcan' make: *** [debian/stamp-build-kernel] Error 2 - vin - 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/backport] CFS scheduler, -v24, for v2.6.24-rc3, v2.6.23.8,v2.6.22.13, v2.6.21.7
-Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Ingo Molnar By popular demand, here is release -v24 of the CFS scheduler patch. It is a full backport of the latest greatest scheduler code to v2.6.24-rc3, v2.6.23.8, v2.6.22.13, v2.6.21.7. The patches can be downloaded from the usual place: http://people.redhat.com/mingo/cfs-scheduler/ There's tons of changes since v22 was released: 36 files changed, 2359 insertions(+), 1082 deletions(-) that's 187 individual commits from 32 authors. So even if CFS v22 worked well for you, please try this release too and report regressions (if any). Hi Ingo, Thnx a lot for theses backports... Ran into this while compiling a 2.6.22.13 with CFS v24 CC kernel/sched.o kernel/sched.c: In function 'cpu_to_core_group': kernel/sched.c:6056: error: 'per_cpu__cpu_sibling_map' undeclared (first use in this function) kernel/sched.c:6056: error: (Each undeclared identifier is reported only once kernel/sched.c:6056: error: for each function it appears in.) kernel/sched.c:6056: warning: type defaults to 'int' in declaration of 'type name' kernel/sched.c:6056: error: invalid type argument of 'unary *' kernel/sched.c: In function 'build_sched_domains': kernel/sched.c:6319: error: 'per_cpu__cpu_sibling_map' undeclared (first use in this function) kernel/sched.c:6319: warning: type defaults to 'int' in declaration of 'type name' kernel/sched.c:6319: error: invalid type argument of 'unary *' kernel/sched.c:6330: warning: type defaults to 'int' in declaration of 'type name' kernel/sched.c:6330: error: invalid type argument of 'unary *' make[2]: *** [kernel/sched.o] Error 1 make[1]: *** [kernel] Error 2 make[1]: Leaving directory `/usr/src/linux-headers-2.6.22.13-cfs-sarge-686-envcan' make: *** [debian/stamp-build-kernel] Error 2 - vin - 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/backport] CFS scheduler, -v24, for v2.6.24-rc3,v2.6.23.8, v2.6.22.13, v2.6.21.7
-Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Ingo Molnar * Erik Andersen [EMAIL PROTECTED] wrote: On Mon Nov 19, 2007 at 04:17:56PM +0100, Ingo Molnar wrote: By popular demand, here is release -v24 of the CFS scheduler patch. It is a full backport of the latest greatest scheduler code to v2.6.24-rc3, v2.6.23.8, v2.6.22.13, v2.6.21.7. The patches can be downloaded from the usual place: http://people.redhat.com/mingo/cfs-scheduler/ Doesn't compile with 2.6.21.7: does the patch below help? Looks good. Compiling. - vin - 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: BUG: usb Mouse continual disconnect (2.6.22.10) leading to eventual crash?
> -Message d'origine- > De : Andrew Morton [mailto:[EMAIL PROTECTED] > Envoyé : 7 novembre 2007 15:33 > > (+linux-usb-devel) > > > On Wed, 7 Nov 2007 13:19:47 -0500 "Fortier,Vincent > [Montreal]" <[EMAIL PROTECTED]> wrote: > > > > I'm having a preblem with a few workstations that are hard freezing > > from time to time since about a week. Curiously since then we > > upgraded from > > 2.6.20.6 to 2.6.20.10... > > [.] > > > > Looking at the changes between 2.6.20.6 and 2.6.20.10 I only found > > this USB related: > > > http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.22.y.git;a=commit;h=0e22438a5adfdf32b3bb1c75c81c01a29fba9770 > > > > I'm presuming that maybie eventually it might hit a input max barrier > > (like a max of 1024) and then the kernel would be crashing? > > > > Help very much appreciated! > > People are going to want to know if this is still happening > in 2.6.23 or 2.6.24-rc2, please. I andrew, (logged-in at wrok to make proper reply) It might be tricky to test properly on 2.6.23.1 since theses are all operationnal aviation forecaster workstations 24/7 And sadly the problem only occur on a few of theses workstations AFAIK randomly ??? Actually many of them did not had any problems using the exact same FAI reinstallation using the same hardware..?!?!. If someone thinks that the problem might effectively be the usb patch that I mentionned before (or any other patch that might make suddently thoses stations to freeze dur to a change that occur between 2.6.20.6 and .10) I would then be able to push a new kernel on thoses workstations without the offending patch(es) and have a clear answer within a week. I also need to mention that our 2.6.20.6 build contained CFS v20.5 and the new 2.6.20.10 build contains CFS v22 although I doubt it is the cause of the freezing problem but hey, never know. Although I could probably rebuild and push a new 2.6.20.10 without CFS to be sure. I'm also currently following the problem occurring on a station and I hope it will freeze at an evident input entry. Here where it is now: Nov 7 22:04:44 mammatus kernel: [100926.387652] usb 2-1: USB disconnect, address 118 Nov 7 22:04:44 mammatus kernel: [100926.627502] usb 2-1: new low speed USB device using uhci_hcd and address 119 Nov 7 22:04:45 mammatus kernel: [100926.804006] usb 2-1: configuration #1 chosen from 1 choice Nov 7 22:04:45 mammatus kernel: [100926.820213] input: Logitech USB-PS/2 Optical Mouse as /class/input/input729 Nov 7 22:04:45 mammatus kernel: [100926.820304] input: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-:00:1d.0-1 Nov 7 22:11:55 mammatus kernel: [101356.846746] usb 2-1: USB disconnect, address 119 Nov 7 22:11:56 mammatus kernel: [101357.590408] usb 2-1: new low speed USB device using uhci_hcd and address 120 Nov 7 22:11:56 mammatus kernel: [101357.766609] usb 2-1: configuration #1 chosen from 1 choice Nov 7 22:11:56 mammatus kernel: [101357.782803] input: Logitech USB-PS/2 Optical Mouse as /class/input/input730 Nov 7 22:11:56 mammatus kernel: [101357.782897] input: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-:00:1d.0-1 vin - 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/
BUG: usb Mouse continual disconnect (2.6.22.10) leading to eventual crash?
Hi all, I'm having a preblem with a few workstations that are hard freezing from time to time since about a week. Curiously since then we upgraded from 2.6.20.6 to 2.6.20.10... While investigating I found out that there seems to be a problem, occuring randomly on some workstations after a certain amount time, that the mouse gets disconnected continously (see full log attached): Nov 7 00:09:36 mammatus kernel: [22055.357104] usb 2-1: USB disconnect, address 2 Nov 7 00:09:37 mammatus kernel: [22055.596974] usb 2-1: new low speed USB device using uhci_hcd and address 3 Nov 7 00:09:37 mammatus kernel: [22055.777831] usb 2-1: configuration #1 chosen from 1 choice Nov 7 00:09:37 mammatus kernel: [22055.793905] input: Logitech USB-PS/2 Optical Mouse as /class/input/input5 Nov 7 00:09:37 mammatus kernel: [22055.793994] input: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-:00:1d.0-1 Nov 7 00:10:11 mammatus kernel: [22090.368722] usb 2-1: USB disconnect, address 3 Nov 7 00:10:12 mammatus kernel: [22090.608588] usb 2-1: new low speed USB device using uhci_hcd and address 4 Nov 7 00:10:12 mammatus kernel: [22090.784671] usb 2-1: configuration #1 chosen from 1 choice Nov 7 00:10:12 mammatus kernel: [22090.800881] input: Logitech USB-PS/2 Optical Mouse as /class/input/input6 Nov 7 00:10:12 mammatus kernel: [22090.800982] input: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-:00:1d.0-1 [.] Nov 7 17:57:28 mammatus kernel: [86097.543960] input: Logitech USB-PS/2 Optical Mouse as /class/input/input596 Nov 7 17:57:28 mammatus kernel: [86097.544050] input: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-:00:1d.0-1 Nov 7 17:59:07 mammatus kernel: [86196.161272] usb 2-1: USB disconnect, address 112 Nov 7 17:59:07 mammatus kernel: [86196.401142] usb 2-1: new low speed USB device using uhci_hcd and address 113 Nov 7 17:59:08 mammatus kernel: [86196.577674] usb 2-1: configuration #1 chosen from 1 choice Nov 7 17:59:08 mammatus kernel: [86196.593834] input: Logitech USB-PS/2 Optical Mouse as /class/input/input597 Nov 7 17:59:08 mammatus kernel: [86196.593939] input: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-:00:1d.0-1 Nov 7 17:59:13 mammatus kernel: [86202.206449] usb 2-1: USB disconnect, address 113 Nov 7 17:59:13 mammatus kernel: [86202.446319] usb 2-1: new low speed USB device using uhci_hcd and address 114 Nov 7 17:59:14 mammatus kernel: [86202.623309] usb 2-1: configuration #1 chosen from 1 choice Nov 7 17:59:14 mammatus kernel: [86202.638402] input: Logitech USB-PS/2 Optical Mouse as /class/input/input598 Nov 7 17:59:14 mammatus kernel: [86202.638493] input: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-:00:1d.0-1 There are some occasionnal connect/disconnect due to the fact that we recently bought an ergonomic mouse (Evoluent Vertical Mouse 3 Rev. 2) that some people plug-in the workstation they are working for the duration of their day/night shift... but nothing like 600 disconnect / day / workstations? And actually, the source workstation of this log as not yet got the mouse connected to it since it's last reboot. Looking at the changes between 2.6.20.6 and 2.6.20.10 I only found this USB related: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.22.y.git;a=co mmit;h=0e22438a5adfdf32b3bb1c75c81c01a29fba9770 I'm presuming that maybie eventually it might hit a input max barrier (like a max of 1024) and then the kernel would be crashing? Help very much appreciated! Regards, Vincent Fortier Informatique Environnement Canada kern.log.bz2 Description: kern.log.bz2
BUG: usb Mouse continual disconnect (2.6.22.10) leading to eventual crash?
Hi all, I'm having a preblem with a few workstations that are hard freezing from time to time since about a week. Curiously since then we upgraded from 2.6.20.6 to 2.6.20.10... While investigating I found out that there seems to be a problem, occuring randomly on some workstations after a certain amount time, that the mouse gets disconnected continously (see full log attached): Nov 7 00:09:36 mammatus kernel: [22055.357104] usb 2-1: USB disconnect, address 2 Nov 7 00:09:37 mammatus kernel: [22055.596974] usb 2-1: new low speed USB device using uhci_hcd and address 3 Nov 7 00:09:37 mammatus kernel: [22055.777831] usb 2-1: configuration #1 chosen from 1 choice Nov 7 00:09:37 mammatus kernel: [22055.793905] input: Logitech USB-PS/2 Optical Mouse as /class/input/input5 Nov 7 00:09:37 mammatus kernel: [22055.793994] input: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-:00:1d.0-1 Nov 7 00:10:11 mammatus kernel: [22090.368722] usb 2-1: USB disconnect, address 3 Nov 7 00:10:12 mammatus kernel: [22090.608588] usb 2-1: new low speed USB device using uhci_hcd and address 4 Nov 7 00:10:12 mammatus kernel: [22090.784671] usb 2-1: configuration #1 chosen from 1 choice Nov 7 00:10:12 mammatus kernel: [22090.800881] input: Logitech USB-PS/2 Optical Mouse as /class/input/input6 Nov 7 00:10:12 mammatus kernel: [22090.800982] input: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-:00:1d.0-1 [.] Nov 7 17:57:28 mammatus kernel: [86097.543960] input: Logitech USB-PS/2 Optical Mouse as /class/input/input596 Nov 7 17:57:28 mammatus kernel: [86097.544050] input: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-:00:1d.0-1 Nov 7 17:59:07 mammatus kernel: [86196.161272] usb 2-1: USB disconnect, address 112 Nov 7 17:59:07 mammatus kernel: [86196.401142] usb 2-1: new low speed USB device using uhci_hcd and address 113 Nov 7 17:59:08 mammatus kernel: [86196.577674] usb 2-1: configuration #1 chosen from 1 choice Nov 7 17:59:08 mammatus kernel: [86196.593834] input: Logitech USB-PS/2 Optical Mouse as /class/input/input597 Nov 7 17:59:08 mammatus kernel: [86196.593939] input: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-:00:1d.0-1 Nov 7 17:59:13 mammatus kernel: [86202.206449] usb 2-1: USB disconnect, address 113 Nov 7 17:59:13 mammatus kernel: [86202.446319] usb 2-1: new low speed USB device using uhci_hcd and address 114 Nov 7 17:59:14 mammatus kernel: [86202.623309] usb 2-1: configuration #1 chosen from 1 choice Nov 7 17:59:14 mammatus kernel: [86202.638402] input: Logitech USB-PS/2 Optical Mouse as /class/input/input598 Nov 7 17:59:14 mammatus kernel: [86202.638493] input: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-:00:1d.0-1 There are some occasionnal connect/disconnect due to the fact that we recently bought an ergonomic mouse (Evoluent Vertical Mouse 3 Rev. 2) that some people plug-in the workstation they are working for the duration of their day/night shift... but nothing like 600 disconnect / day / workstations? And actually, the source workstation of this log as not yet got the mouse connected to it since it's last reboot. Looking at the changes between 2.6.20.6 and 2.6.20.10 I only found this USB related: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.22.y.git;a=co mmit;h=0e22438a5adfdf32b3bb1c75c81c01a29fba9770 I'm presuming that maybie eventually it might hit a input max barrier (like a max of 1024) and then the kernel would be crashing? Help very much appreciated! Regards, Vincent Fortier Informatique Environnement Canada kern.log.bz2 Description: kern.log.bz2
RE: BUG: usb Mouse continual disconnect (2.6.22.10) leading to eventual crash?
-Message d'origine- De : Andrew Morton [mailto:[EMAIL PROTECTED] Envoyé : 7 novembre 2007 15:33 (+linux-usb-devel) On Wed, 7 Nov 2007 13:19:47 -0500 Fortier,Vincent [Montreal] [EMAIL PROTECTED] wrote: I'm having a preblem with a few workstations that are hard freezing from time to time since about a week. Curiously since then we upgraded from 2.6.20.6 to 2.6.20.10... [.] Looking at the changes between 2.6.20.6 and 2.6.20.10 I only found this USB related: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.22.y.git;a=commit;h=0e22438a5adfdf32b3bb1c75c81c01a29fba9770 I'm presuming that maybie eventually it might hit a input max barrier (like a max of 1024) and then the kernel would be crashing? Help very much appreciated! People are going to want to know if this is still happening in 2.6.23 or 2.6.24-rc2, please. I andrew, (logged-in at wrok to make proper reply) It might be tricky to test properly on 2.6.23.1 since theses are all operationnal aviation forecaster workstations 24/7 And sadly the problem only occur on a few of theses workstations AFAIK randomly ??? Actually many of them did not had any problems using the exact same FAI reinstallation using the same hardware..?!?!. If someone thinks that the problem might effectively be the usb patch that I mentionned before (or any other patch that might make suddently thoses stations to freeze dur to a change that occur between 2.6.20.6 and .10) I would then be able to push a new kernel on thoses workstations without the offending patch(es) and have a clear answer within a week. I also need to mention that our 2.6.20.6 build contained CFS v20.5 and the new 2.6.20.10 build contains CFS v22 although I doubt it is the cause of the freezing problem but hey, never know. Although I could probably rebuild and push a new 2.6.20.10 without CFS to be sure. I'm also currently following the problem occurring on a station and I hope it will freeze at an evident input entry. Here where it is now: Nov 7 22:04:44 mammatus kernel: [100926.387652] usb 2-1: USB disconnect, address 118 Nov 7 22:04:44 mammatus kernel: [100926.627502] usb 2-1: new low speed USB device using uhci_hcd and address 119 Nov 7 22:04:45 mammatus kernel: [100926.804006] usb 2-1: configuration #1 chosen from 1 choice Nov 7 22:04:45 mammatus kernel: [100926.820213] input: Logitech USB-PS/2 Optical Mouse as /class/input/input729 Nov 7 22:04:45 mammatus kernel: [100926.820304] input: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-:00:1d.0-1 Nov 7 22:11:55 mammatus kernel: [101356.846746] usb 2-1: USB disconnect, address 119 Nov 7 22:11:56 mammatus kernel: [101357.590408] usb 2-1: new low speed USB device using uhci_hcd and address 120 Nov 7 22:11:56 mammatus kernel: [101357.766609] usb 2-1: configuration #1 chosen from 1 choice Nov 7 22:11:56 mammatus kernel: [101357.782803] input: Logitech USB-PS/2 Optical Mouse as /class/input/input730 Nov 7 22:11:56 mammatus kernel: [101357.782897] input: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-:00:1d.0-1 vin - 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/backport] CFS scheduler, -v22, for v2.6.23-rc8, v2.6.22.8,v2.6.21.7, v2.6.20.20
> De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] De la part de Ingo Molnar > Envoyé : 26 septembre 2007 07:14 > > By popular demand, here is release -v22 of the CFS scheduler. > It is a full backport of the latest & greatest > sched-devel.git code to v2.6.23-rc8, v2.6.22.8, v2.6.21.7 and > v2.6.20.20. The patches can be downloaded from the usual place: > > http://people.redhat.com/mingo/cfs-scheduler/ > > This is the first time the development version of the > scheduler has been fed back into the stable backport series, > so there's many changes since > v20.5: > > 15 files changed, 1103 insertions(+), 840 deletions(-) > > Even if CFS v20.5 worked well for you, please try this > release too, with a good focus on interactivity testing - > because, unless some major showstopper is found, this > codebase is intended for a v2.6.24 upstream merge. > > ( Even a quick, subjective report of: "checked this patch, it didnt > crash and it feels like v20.5" or "laggier than v20.5" or "feels > better than v20.5" is useful to us and enables us to judge > the general > direction of interactivity. ) > > The changes in v22 consist of lots of mostly small > enhancements, speedups, interactivity improvements, debug > enhancements and tidy-ups - many of which can be > user-visible. (These enhancements have been contributed by > many people - see the changelog below and the git tree for > detailed credits.) > Better late than never... Hi Ingo & cie., I tested CFS v22 on a 2.6.20.10 and it is working like a charm. I used to have a few lags once in a while with v20.5 on a 2.6.20.6 kernel but they simply vanished with the v22 (although I'm currenctly mostly testing on etch with xorg 7.1 instead of sarge with xfree 4.3 so this might also have an effect...) It seems stable enough to put it in operation by next week on all our workstations. This is great work, thx to all CFS contributors. - vin - 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/backport] CFS scheduler, -v22, for v2.6.23-rc8, v2.6.22.8,v2.6.21.7, v2.6.20.20
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Ingo Molnar Envoyé : 26 septembre 2007 07:14 By popular demand, here is release -v22 of the CFS scheduler. It is a full backport of the latest greatest sched-devel.git code to v2.6.23-rc8, v2.6.22.8, v2.6.21.7 and v2.6.20.20. The patches can be downloaded from the usual place: http://people.redhat.com/mingo/cfs-scheduler/ This is the first time the development version of the scheduler has been fed back into the stable backport series, so there's many changes since v20.5: 15 files changed, 1103 insertions(+), 840 deletions(-) Even if CFS v20.5 worked well for you, please try this release too, with a good focus on interactivity testing - because, unless some major showstopper is found, this codebase is intended for a v2.6.24 upstream merge. ( Even a quick, subjective report of: checked this patch, it didnt crash and it feels like v20.5 or laggier than v20.5 or feels better than v20.5 is useful to us and enables us to judge the general direction of interactivity. ) The changes in v22 consist of lots of mostly small enhancements, speedups, interactivity improvements, debug enhancements and tidy-ups - many of which can be user-visible. (These enhancements have been contributed by many people - see the changelog below and the git tree for detailed credits.) Better late than never... Hi Ingo cie., I tested CFS v22 on a 2.6.20.10 and it is working like a charm. I used to have a few lags once in a while with v20.5 on a 2.6.20.6 kernel but they simply vanished with the v22 (although I'm currenctly mostly testing on etch with xorg 7.1 instead of sarge with xfree 4.3 so this might also have an effect...) It seems stable enough to put it in operation by next week on all our workstations. This is great work, thx to all CFS contributors. - vin - 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 for Apani Nortel VPN Client to build against kernel 2.6.22 help/review
> -Message d'origine-
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] De la part de Nick Bowler
>
> I haven't read too much into the patch, but some quick
> comments. Most applies
> throughout:
>
> > +#if (LINUX_VERSION_CODE >= 0x020616)
> KERNEL_VERSION(2,6,22) is much more readable than 0x020616.
>
> > + return (struct iphdr*) skb->network_header;
> Should be return ip_hdr(skb);
>
> > +skb->network_header = skb->data;
> Should be skb_reset_network_header(skb);
>
> > +iph = skb->network_header.iph;
> Probably meant skb->nh.iph.
>
> > + if ( iph->protocol == 17 )/* if UDP, */
> (snip)
> > + if ( iph->protocol == 6 ) /* if TCP, */
> Could use IPPROTO_UDP and IPPROTO_TCP instead of 17 and 6,
> respectively.
>
> Instead of littering the code with #if blah #else blah, you
> could also simply provide implementations for the 2.6.22
> functions #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,22).
>
(Forwarding info by Samuel to lkml...)
Thanks for your comments, here is a new patch (bowler.patch) reflecting the
changes you suggested. Unfortunately, and unsurprisingly for such cosmetic
changes, the code still hangs.
I have added a great many debugging statements in order to pinpoint the problem
(backtrace.patch); surprisingly, my custom backtraces didn't show up in the
console, but a kernel call trace did (call_trace).
Here is the contents of the offending function. The {enter,exit}_func() calls
are my debugging statements, and I have verified that only the else branch was
compiled. As you can see, there are only function calls here, no memory
manipulation nor dereferencing at all. What could possibly fail in this
function? Shouldn`t the backtrace include one of the subcalls?
void nl_spin_lock_irqsave(spinlock_t *lockptr, DWORD *flagptr)
{
enter_func(__LINE__);
#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,7))
assert(lockptr);
assert(flagptr);
spin_lock_irqsave((spinlock_t *)lockptr, (*flagptr));
#else
spin_lock_irq((spinlock_t *)lockptr);
#endif
exit_func(__LINE__);
}
- Samuel Gélineau
call_trace
Description: call_trace
backtrace.patch
Description: backtrace.patch
bowler.patch
Description: bowler.patch
RE: Patch for Apani Nortel VPN Client to build against kernel 2.6.22 help/review
-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] De la part de Nick Bowler
I haven't read too much into the patch, but some quick
comments. Most applies
throughout:
+#if (LINUX_VERSION_CODE = 0x020616)
KERNEL_VERSION(2,6,22) is much more readable than 0x020616.
+ return (struct iphdr*) skb-network_header;
Should be return ip_hdr(skb);
+skb-network_header = skb-data;
Should be skb_reset_network_header(skb);
+iph = skb-network_header.iph;
Probably meant skb-nh.iph.
+ if ( iph-protocol == 17 )/* if UDP, */
(snip)
+ if ( iph-protocol == 6 ) /* if TCP, */
Could use IPPROTO_UDP and IPPROTO_TCP instead of 17 and 6,
respectively.
Instead of littering the code with #if blah #else blah, you
could also simply provide implementations for the 2.6.22
functions #if LINUX_VERSION_CODE KERNEL_VERSION(2,6,22).
(Forwarding info by Samuel to lkml...)
Thanks for your comments, here is a new patch (bowler.patch) reflecting the
changes you suggested. Unfortunately, and unsurprisingly for such cosmetic
changes, the code still hangs.
I have added a great many debugging statements in order to pinpoint the problem
(backtrace.patch); surprisingly, my custom backtraces didn't show up in the
console, but a kernel call trace did (call_trace).
Here is the contents of the offending function. The {enter,exit}_func() calls
are my debugging statements, and I have verified that only the else branch was
compiled. As you can see, there are only function calls here, no memory
manipulation nor dereferencing at all. What could possibly fail in this
function? Shouldn`t the backtrace include one of the subcalls?
void nl_spin_lock_irqsave(spinlock_t *lockptr, DWORD *flagptr)
{
enter_func(__LINE__);
#if (LINUX_VERSION_CODE KERNEL_VERSION(2,6,7))
assert(lockptr);
assert(flagptr);
spin_lock_irqsave((spinlock_t *)lockptr, (*flagptr));
#else
spin_lock_irq((spinlock_t *)lockptr);
#endif
exit_func(__LINE__);
}
- Samuel Gélineau
call_trace
Description: call_trace
backtrace.patch
Description: backtrace.patch
bowler.patch
Description: bowler.patch
RE: [question] IPC queue filling-up problem?
> -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] De la part de Eric Dumazet > > On Wed, 5 Sep 2007 09:37:50 -0400 > "Fortier,Vincent [Montreal]" <[EMAIL PROTECTED]> wrote: > > > > > Hi all, > > > > We are testing new hardware and planning a switch from our old redhat > > 7.3 to a Debian Etch 4.0 for our radar forecast analysis systems. We > > found out that our main IPC dispatcher software module would use 100% > > of a CPU all the time and that the IPC queues would fill up quickly on a > > 2.6 kernel. We first tought that it would be a problem of > > compatibility between a 2.4 vs 2.6 IPC calls vs our radar analysis > > software but after a lot of work we have been able to test a 2.4 > > kernel on that same hardware and got the exact same problem. > > > > So curiously, on our actual systems (see SYSTEM 1 below) our IPC > > dispatcher module works like a charm and queues gets near 0. On our > > test system which are way more powerfull systems (see SYSTEM 2) our > > IPC dispatcher module queue fills up rapidly (depending of the msgmnb > > queue size it will wimply take a bit longer to fill). > > > > We have tested both our already compiled binaries from rh73 using gcc > > 2.9 and a recompiled version of the modules on a debian sarge system > > and got the exact same problem on either a Debian Sarge 3.1 (running a > > 2.4 or 2.6 kernel) and on a Etch 64bit system (using 32bit compat > > layer) with a 2.6 kernel. In all cases the queues would simply fill-up. > > > > After strac'ing the module I noticed that the time needed to handle > > the signal & ipc calls are way lower on the new system hence I don't > > see why the dispatcher queue does fill-up like that?!?!?! > > > > Does anyone experienced something similar? Could this be a kernel > > issue vs material, kernel option? Might this be related to libc? > > > > Help / Clues very much appreciated. > > Hi Vincent > > top shows that something is eating cpu cycles in User mode on > your new platform, while old platform consumes cycles both in > User and System land. > > This might be related to some programing error, maybe some > spinlock in user mode or bad multi-threading synchronization, > or scheduling assumptions, that break because of the quad > core cpus of your new machine. Actually, could this be worth trying (adding Ingo in CC): http://lkml.org/lkml/2007/9/5/75 > So the thread that is supposed to consume IPC messages is not > scheduled in time, because CPU starves. (beware the four > cores of each CPU compete for ressources) > > You could issue "ps auxm" to check which threads are spining > in User mode and try to trace them ? Effectively in this specific test case I had 5 stuck process using each 100% of a CPU... although 3 other cores where still available so there is (I believe) no reason why it should had starved that much. Anyhow, that did not happend on all the other testing I made during the past 3 weeks (except this one). I restarted the this test (again using a 2.4.35.1 kernel), mde sure no process where stuck :), and grabbed the ps aux + ipcs -q info (attached) Again, the ipcs -q shows that the queue is getting full comparing to SYSTEM 1 which always has a queue of 0. Note: Also attached a top.txt file showing that the dispatcher uses 100% of a CPU on SYSTEM 2. This never occurs on SYSTEM 1. > Eric PS, thnx for replying. - vin > > SYSTEM INFORMATION: > > > > SYSTEM 1: > > - > > HPDL580 G2 > > Quad Intel Xeon 1.90GHz > > 4G ram > > DRBD disks on dual-gigabit adapter > > OS: RedHat 7.3 / kernel: 2.4.33 / libc: 2.2.5 / gcc 2.96 > > > > SYSTEM 2: > > - > > Dell PE2950 > > Dual Intel Quad-Core 2.66GHz > > 16G ram > > local 300G 15000 RPM SCSI. > > OS1: Debian Etch 4.0 / kernels 2.6.18 -> 2.6.22 / libc 2.3.6 / gcc 4.1.2 > > OS2: Debian Sarge 3.1 / kernels 2.4.35, 2.6.18 -> 2.6.22 / libc 2.3.2 / gcc 3.3.5 -- Message Queues keymsqid owner perms used-bytes messages 0x41018018 0 urp66060784748 0x41018024 32769 urp66000 0x4101800b 65538 urp66000 0x41018011 98307 urp66000 0x4101800e 131076 urp66000 0x4101803f 163845 urp66000 0x41018019 196614 urp66000 0x41018026 229383 urp6600
[question] IPC queue filling-up problem?
Hi all,
We are testing new hardware and planning a switch from our old redhat
7.3 to a Debian Etch 4.0 for our radar forecast analysis systems. We
found out that our main IPC dispatcher software module would use 100% of
a CPU all the time and that the IPC queues would fill up quickly on a
2.6 kernel. We first tought that it would be a problem of compatibility
between a 2.4 vs 2.6 IPC calls vs our radar analysis software but after
a lot of work we have been able to test a 2.4 kernel on that same
hardware and got the exact same problem.
So curiously, on our actual systems (see SYSTEM 1 below) our IPC
dispatcher module works like a charm and queues gets near 0. On our
test system which are way more powerfull systems (see SYSTEM 2) our IPC
dispatcher module queue fills up rapidly (depending of the msgmnb queue
size it will wimply take a bit longer to fill).
We have tested both our already compiled binaries from rh73 using gcc
2.9 and a recompiled version of the modules on a debian sarge system and
got the exact same problem on either a Debian Sarge 3.1 (running a 2.4
or 2.6 kernel) and on a Etch 64bit system (using 32bit compat layer)
with a 2.6 kernel. In all cases the queues would simply fill-up.
After strac'ing the module I noticed that the time needed to handle the
signal & ipc calls are way lower on the new system hence I don't see why
the dispatcher queue does fill-up like that?!?!?!
Does anyone experienced something similar? Could this be a kernel issue
vs material, kernel option? Might this be related to libc?
Help / Clues very much appreciated.
Thnx
- vin
Debian Sarge 3.1 kernel 2.4.35 notes:
-
Pre-built 2.4.35.1 kernel + backported mpt fusion & megasas drivers for
Debian Sarge 3.1 available at:
http://linux-dev.qc.ec.gc.ca/kernel/debian/sarge/i386/2.4.35/
Megaraid SAS backport patch for a 2.4.35.1 kernel available at:
http://linux-dev.qc.ec.gc.ca/kernel/patches/megaraid_sas-linux_2.4.35.1-
v00.00.03.09.patch
2.4.35.1 config file:
http://linux-dev.qc.ec.gc.ca/kernel/debian/CONFIG-i686-2.4.35.1-008
RedHat 7.3 kernel 2.4.33 notes:
---
Pre-built 2.4.33 kernel for RH73:
http://linux-dev.qc.ec.gc.ca/kernel/redhat/rh73/
2.4.33 config file:
http://linux-dev.qc.ec.gc.ca/kernel/redhat/rh73/config-2.4.33-01.rh73.en
vcanbigmem
SYSTEM INFORMATION:
SYSTEM 1:
-
HPDL580 G2
Quad Intel Xeon 1.90GHz
4G ram
DRBD disks on dual-gigabit adapter
OS: RedHat 7.3 / kernel: 2.4.33 / libc: 2.2.5 / gcc 2.96
SYSTEM 2:
-
Dell PE2950
Dual Intel Quad-Core 2.66GHz
16G ram
local 300G 15000 RPM SCSI.
OS1: Debian Etch 4.0 / kernels 2.6.18 -> 2.6.22 / libc 2.3.6 / gcc 4.1.2
OS2: Debian Sarge 3.1 / kernels 2.4.35, 2.6.18 -> 2.6.22 / libc 2.3.2 /
gcc 3.3.5
=
SYSTEM 1
=
top
---
12:29pm up 147 days, 15:47, 4 users, load average: 3.00, 1.65, 1.56
229 processes: 227 sleeping, 2 running, 0 zombie, 0 stopped
CPU0 states: 48.0% user, 28.0% system, 0.0% nice, 23.0% idle
CPU1 states: 7.0% user, 3.0% system, 0.0% nice, 88.0% idle
CPU2 states: 71.0% user, 13.0% system, 0.0% nice, 15.0% idle
CPU3 states: 6.0% user, 7.0% system, 0.0% nice, 85.0% idle
CPU4 states: 35.0% user, 3.0% system, 0.0% nice, 60.0% idle
CPU5 states: 18.0% user, 3.0% system, 15.0% nice, 77.0% idle
CPU6 states: 11.0% user, 19.0% system, 0.0% nice, 68.0% idle
CPU7 states: 15.0% user, 9.0% system, 0.0% nice, 75.0% idle
Mem: 5952612K av, 5772232K used, 180380K free, 0K shrd, 145816K
buff
Swap: 2097112K av,7560K used, 2089552K free 4820588K
cached
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
29308 urp 14 5 10920 10M 496 S N 15.0 0.1 0:46
URPDispatcher
ipcs -q
---
[EMAIL PROTECTED] ipcs -q
-- Message Queues
keymsqid owner perms used-bytes messages
0x41008050 1130594304 urp66000
0x370041d6 1132494849 urp66000
0x140041d8 1132396546 urp66000
0xfa0041d6 1133084675 urp66000
...
strace -ss -tt -T -v -e trace=ipc
-
11:51:45.238031 msgsnd(1104543768, {1, ""...}, 91, IPC_NOWAIT) = 0
<0.29>
11:51:45.260221 msgrcv(1100054529, {1, ""...}, 2565, 0, 0) = 82
<0.92>
11:51:45.280938 msgsnd(1103790090, {1, ""...}, 82, IPC_NOWAIT) = 0
<0.34>
11:51:45.368730 msgsnd(1104543768, {1, ""...}, 82, IPC_NOWAIT) = 0
<0.023403>
11:51:45.414185 msgrcv(1100054529, {1, ""...}, 2565, 0, 0) = 84
<0.20>
11:51:45.483523 msgrcv(1100054529, {1, ""...}, 2565, 0, 0) = 84
<0.42>
11:51:45.543332 msgrcv(1100054529, {1, ""...}, 2565, 0, 0) = 89
<0.27>
11:51:45.578211 msgsnd(1104543768, {1, ""...}, 89, IPC_NOWAIT) = 0
<0.57>
11:51:45.592104 msgrcv(1100054529, {1, ""...}, 2565, 0, 0) = 91
<0.32>
11:51:45.596233 msgsnd(1103790090, {1, ""...}, 91, IPC_NOWAIT) = 0
[question] IPC queue filling-up problem?
Hi all,
We are testing new hardware and planning a switch from our old redhat
7.3 to a Debian Etch 4.0 for our radar forecast analysis systems. We
found out that our main IPC dispatcher software module would use 100% of
a CPU all the time and that the IPC queues would fill up quickly on a
2.6 kernel. We first tought that it would be a problem of compatibility
between a 2.4 vs 2.6 IPC calls vs our radar analysis software but after
a lot of work we have been able to test a 2.4 kernel on that same
hardware and got the exact same problem.
So curiously, on our actual systems (see SYSTEM 1 below) our IPC
dispatcher module works like a charm and queues gets near 0. On our
test system which are way more powerfull systems (see SYSTEM 2) our IPC
dispatcher module queue fills up rapidly (depending of the msgmnb queue
size it will wimply take a bit longer to fill).
We have tested both our already compiled binaries from rh73 using gcc
2.9 and a recompiled version of the modules on a debian sarge system and
got the exact same problem on either a Debian Sarge 3.1 (running a 2.4
or 2.6 kernel) and on a Etch 64bit system (using 32bit compat layer)
with a 2.6 kernel. In all cases the queues would simply fill-up.
After strac'ing the module I noticed that the time needed to handle the
signal ipc calls are way lower on the new system hence I don't see why
the dispatcher queue does fill-up like that?!?!?!
Does anyone experienced something similar? Could this be a kernel issue
vs material, kernel option? Might this be related to libc?
Help / Clues very much appreciated.
Thnx
- vin
Debian Sarge 3.1 kernel 2.4.35 notes:
-
Pre-built 2.4.35.1 kernel + backported mpt fusion megasas drivers for
Debian Sarge 3.1 available at:
http://linux-dev.qc.ec.gc.ca/kernel/debian/sarge/i386/2.4.35/
Megaraid SAS backport patch for a 2.4.35.1 kernel available at:
http://linux-dev.qc.ec.gc.ca/kernel/patches/megaraid_sas-linux_2.4.35.1-
v00.00.03.09.patch
2.4.35.1 config file:
http://linux-dev.qc.ec.gc.ca/kernel/debian/CONFIG-i686-2.4.35.1-008
RedHat 7.3 kernel 2.4.33 notes:
---
Pre-built 2.4.33 kernel for RH73:
http://linux-dev.qc.ec.gc.ca/kernel/redhat/rh73/
2.4.33 config file:
http://linux-dev.qc.ec.gc.ca/kernel/redhat/rh73/config-2.4.33-01.rh73.en
vcanbigmem
SYSTEM INFORMATION:
SYSTEM 1:
-
HPDL580 G2
Quad Intel Xeon 1.90GHz
4G ram
DRBD disks on dual-gigabit adapter
OS: RedHat 7.3 / kernel: 2.4.33 / libc: 2.2.5 / gcc 2.96
SYSTEM 2:
-
Dell PE2950
Dual Intel Quad-Core 2.66GHz
16G ram
local 300G 15000 RPM SCSI.
OS1: Debian Etch 4.0 / kernels 2.6.18 - 2.6.22 / libc 2.3.6 / gcc 4.1.2
OS2: Debian Sarge 3.1 / kernels 2.4.35, 2.6.18 - 2.6.22 / libc 2.3.2 /
gcc 3.3.5
=
SYSTEM 1
=
top
---
12:29pm up 147 days, 15:47, 4 users, load average: 3.00, 1.65, 1.56
229 processes: 227 sleeping, 2 running, 0 zombie, 0 stopped
CPU0 states: 48.0% user, 28.0% system, 0.0% nice, 23.0% idle
CPU1 states: 7.0% user, 3.0% system, 0.0% nice, 88.0% idle
CPU2 states: 71.0% user, 13.0% system, 0.0% nice, 15.0% idle
CPU3 states: 6.0% user, 7.0% system, 0.0% nice, 85.0% idle
CPU4 states: 35.0% user, 3.0% system, 0.0% nice, 60.0% idle
CPU5 states: 18.0% user, 3.0% system, 15.0% nice, 77.0% idle
CPU6 states: 11.0% user, 19.0% system, 0.0% nice, 68.0% idle
CPU7 states: 15.0% user, 9.0% system, 0.0% nice, 75.0% idle
Mem: 5952612K av, 5772232K used, 180380K free, 0K shrd, 145816K
buff
Swap: 2097112K av,7560K used, 2089552K free 4820588K
cached
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
29308 urp 14 5 10920 10M 496 S N 15.0 0.1 0:46
URPDispatcher
ipcs -q
---
[EMAIL PROTECTED] ipcs -q
-- Message Queues
keymsqid owner perms used-bytes messages
0x41008050 1130594304 urp66000
0x370041d6 1132494849 urp66000
0x140041d8 1132396546 urp66000
0xfa0041d6 1133084675 urp66000
...
strace -ss -tt -T -v -e trace=ipc
-
11:51:45.238031 msgsnd(1104543768, {1, ...}, 91, IPC_NOWAIT) = 0
0.29
11:51:45.260221 msgrcv(1100054529, {1, ...}, 2565, 0, 0) = 82
0.92
11:51:45.280938 msgsnd(1103790090, {1, ...}, 82, IPC_NOWAIT) = 0
0.34
11:51:45.368730 msgsnd(1104543768, {1, ...}, 82, IPC_NOWAIT) = 0
0.023403
11:51:45.414185 msgrcv(1100054529, {1, ...}, 2565, 0, 0) = 84
0.20
11:51:45.483523 msgrcv(1100054529, {1, ...}, 2565, 0, 0) = 84
0.42
11:51:45.543332 msgrcv(1100054529, {1, ...}, 2565, 0, 0) = 89
0.27
11:51:45.578211 msgsnd(1104543768, {1, ...}, 89, IPC_NOWAIT) = 0
0.57
11:51:45.592104 msgrcv(1100054529, {1, ...}, 2565, 0, 0) = 91
0.32
11:51:45.596233 msgsnd(1103790090, {1, ...}, 91, IPC_NOWAIT) = 0
0.37
11:51:45.660060 msgrcv(1100054529, {1,
RE: [question] IPC queue filling-up problem?
-Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Eric Dumazet On Wed, 5 Sep 2007 09:37:50 -0400 Fortier,Vincent [Montreal] [EMAIL PROTECTED] wrote: Hi all, We are testing new hardware and planning a switch from our old redhat 7.3 to a Debian Etch 4.0 for our radar forecast analysis systems. We found out that our main IPC dispatcher software module would use 100% of a CPU all the time and that the IPC queues would fill up quickly on a 2.6 kernel. We first tought that it would be a problem of compatibility between a 2.4 vs 2.6 IPC calls vs our radar analysis software but after a lot of work we have been able to test a 2.4 kernel on that same hardware and got the exact same problem. So curiously, on our actual systems (see SYSTEM 1 below) our IPC dispatcher module works like a charm and queues gets near 0. On our test system which are way more powerfull systems (see SYSTEM 2) our IPC dispatcher module queue fills up rapidly (depending of the msgmnb queue size it will wimply take a bit longer to fill). We have tested both our already compiled binaries from rh73 using gcc 2.9 and a recompiled version of the modules on a debian sarge system and got the exact same problem on either a Debian Sarge 3.1 (running a 2.4 or 2.6 kernel) and on a Etch 64bit system (using 32bit compat layer) with a 2.6 kernel. In all cases the queues would simply fill-up. After strac'ing the module I noticed that the time needed to handle the signal ipc calls are way lower on the new system hence I don't see why the dispatcher queue does fill-up like that?!?!?! Does anyone experienced something similar? Could this be a kernel issue vs material, kernel option? Might this be related to libc? Help / Clues very much appreciated. Hi Vincent top shows that something is eating cpu cycles in User mode on your new platform, while old platform consumes cycles both in User and System land. This might be related to some programing error, maybe some spinlock in user mode or bad multi-threading synchronization, or scheduling assumptions, that break because of the quad core cpus of your new machine. Actually, could this be worth trying (adding Ingo in CC): http://lkml.org/lkml/2007/9/5/75 So the thread that is supposed to consume IPC messages is not scheduled in time, because CPU starves. (beware the four cores of each CPU compete for ressources) You could issue ps auxm to check which threads are spining in User mode and try to trace them ? Effectively in this specific test case I had 5 stuck process using each 100% of a CPU... although 3 other cores where still available so there is (I believe) no reason why it should had starved that much. Anyhow, that did not happend on all the other testing I made during the past 3 weeks (except this one). I restarted the this test (again using a 2.4.35.1 kernel), mde sure no process where stuck :), and grabbed the ps aux + ipcs -q info (attached) Again, the ipcs -q shows that the queue is getting full comparing to SYSTEM 1 which always has a queue of 0. Note: Also attached a top.txt file showing that the dispatcher uses 100% of a CPU on SYSTEM 2. This never occurs on SYSTEM 1. Eric PS, thnx for replying. - vin SYSTEM INFORMATION: SYSTEM 1: - HPDL580 G2 Quad Intel Xeon 1.90GHz 4G ram DRBD disks on dual-gigabit adapter OS: RedHat 7.3 / kernel: 2.4.33 / libc: 2.2.5 / gcc 2.96 SYSTEM 2: - Dell PE2950 Dual Intel Quad-Core 2.66GHz 16G ram local 300G 15000 RPM SCSI. OS1: Debian Etch 4.0 / kernels 2.6.18 - 2.6.22 / libc 2.3.6 / gcc 4.1.2 OS2: Debian Sarge 3.1 / kernels 2.4.35, 2.6.18 - 2.6.22 / libc 2.3.2 / gcc 3.3.5 -- Message Queues keymsqid owner perms used-bytes messages 0x41018018 0 urp66060784748 0x41018024 32769 urp66000 0x4101800b 65538 urp66000 0x41018011 98307 urp66000 0x4101800e 131076 urp66000 0x4101803f 163845 urp66000 0x41018019 196614 urp66000 0x41018026 229383 urp66000 0x4101802f 262152 urp66000 0x4101803a 294921 urp66000 0x41018036 327690 urp66000 0x4101802b 360459 urp66000 0x41018040 393228 urp66000 0x41018027 425997 urp66000 0x41018028 458766 urp66000 0x41018020 491535 urp660
Patch for Apani Nortel VPN Client to build against kernel 2.6.22 help/review
Hi all,
Sadly I have to use the Apani/Nortel VPN linux client to connect to my office.
The latest version (3.5) stopped being compatible with the latest stable 2.6.22
kernel (how suprising :().
Since
1) I'm stuck using that closed source/proprietary software
2) there will most probably not be a new release from apani until year 2013
3) support from apani is near zero
we got used with previous version (aka 3.3) to hack the linux_wrapper.c file to
try to keep the module compatible
(http://www.fedoraforum.org/forum/showpost.php?p=742619=26)
Based on the horrors that showed up while compiling against a 2.6.22 kernel
(see below), I was wondering if somebody would be kind enough to review our
not-yet-working patch that converts dev_base/skb calls to the new API. A
collegue of mine made all the required changes but when the netlock service
gets fired-up the machine hang.
Are there any ways to debug this black box?
Help very much appreciated.
--
Here is the not-yet-working patch against the linux_wrapper.c file:
--- cvc_linux-rh-gcc3-3.5.orig/src/linux_wrapper.c 2007-02-07
19:10:41.0 +
+++ cvc_linux-rh-gcc3-3.5/src/linux_wrapper.c 2007-08-21 17:42:30.0
+
@@ -136,6 +136,8 @@ int nl_open(struct inode *inode, struct
/* some necessary globals... */
#if ((LINUX_VERSION_CODE >= 0x020200) && (LINUX_VERSION_CODE < 0x020300))
typedef struct device net_device_t;
+#elif (LINUX_VERSION_CODE >= 0x020616)
+typedef struct list_head net_device_t;
#else
typedef struct net_device net_device_t;
#endif
@@ -306,8 +308,11 @@ nl_copy_to_user(void *to, const void *fr
void init_misc(void)
{
-
+#if (LINUX_VERSION_CODE >= 0x020616)
+nl_dev_base = _base_head;
+#else
nl_dev_base = dev_base;
+#endif
}
#if ((LINUX_VERSION_CODE >= 0x020200) && (LINUX_VERSION_CODE < 0x020300))
@@ -430,8 +435,13 @@ void nl_skb_put(struct sk_buff *skb, int
int nl_ip_rcv(struct sk_buff *skb, struct packet_type *pt)
{
#if (LINUX_VERSION_CODE > 0x02060c)
+#if (LINUX_VERSION_CODE >= 0x020616)
+struct net_device *dev = skb->dev;
+struct iphdr *iph = (struct iphdr*) skb->network_header;
+#else
struct net_device *dev = skb->dev;
struct iphdr *iph = skb->nh.iph;
+#endif
if (skb->dst == NULL)
{
@@ -469,28 +479,52 @@ int nl_unregister_netdevice_notifier(str
char *dev_name (net_device_t *dev)
{
+#if (LINUX_VERSION_CODE >= 0x020616)
+ return (net_device_entry(dev)->name);
+#else
return (dev->name);
+#endif
}
int dev_name_len (net_device_t *dev)
{
+#if (LINUX_VERSION_CODE >= 0x020616)
+ return (strlen(net_device_entry(dev)->name));
+#else
return (strlen(dev->name));
+#endif
}
unsigned *dev_mtu_ptr (net_device_t *dev)
{
- return (>mtu);
+#if (LINUX_VERSION_CODE >= 0x020616)
+ return &(net_device_entry(dev)->mtu);
+#else
+ return &(dev->mtu);
+#endif
}
unsigned dev_mtu (net_device_t *dev)
{
+#if (LINUX_VERSION_CODE >= 0x020616)
+ return (net_device_entry(dev)->mtu);
+#else
return (dev->mtu);
+#endif
}
int dev_ifindex (net_device_t *dev)
{
+#if (LINUX_VERSION_CODE >= 0x020616)
+ return (net_device_entry(dev)->ifindex);
+#else
return (dev->ifindex);
+#endif
}
void *dev_ip_ptr (net_device_t *dev)
{
+#if (LINUX_VERSION_CODE >= 0x020616)
+ return (net_device_entry(dev)->ip_ptr);
+#else
return (dev->ip_ptr);
+#endif
}
net_device_t *dev_next (net_device_t *dev)
{
@@ -546,9 +580,15 @@ void nl_skb_dup (struct sk_buff *new_skb
head_offset = new_skb->head - skb->head;
new_skb->dev = skb->dev;
new_skb->dst = dst_clone(skb->dst);
+#if (LINUX_VERSION_CODE >= 0x020616)
+new_skb->transport_header = skb->transport_header+head_offset;
+new_skb->network_header = skb->network_header+head_offset;
+new_skb->mac_header = skb->mac_header+head_offset;
+#else
new_skb->h.raw = skb->h.raw+head_offset;
new_skb->nh.raw = skb->nh.raw+head_offset;
new_skb->mac.raw = skb->mac.raw+head_offset;
+#endif
memcpy(new_skb->cb, skb->cb, sizeof(skb->cb));
new_skb->priority = skb->priority;
new_skb->protocol = skb->protocol;
@@ -573,9 +613,15 @@ void nl_skb_hdr_copy (struct sk_buff *sk
{
skb_to->dev = skb_from->dev;
skb_to->dst = skb_from->dst;
+#if (LINUX_VERSION_CODE >= 0x020616)
+ skb_to->transport_header = skb_from->transport_header;
+ skb_to->network_header = skb_from->network_header;
+ skb_to->mac_header = skb_from->mac_header;
+#else
skb_to->h.raw = skb_from->h.raw;
skb_to->nh.raw = skb_from->nh.raw;
skb_to->mac.raw = skb_from->mac.raw;
+#endif
memcpy(skb_to->cb, skb_from->cb, sizeof(skb_from->cb));
skb_to->priority = skb_from->priority;
skb_to->protocol = skb_from->protocol;
@@ -592,7 +638,11 @@ void nl_skb_hdr_copy (struct sk_buff *sk
struct iphdr * nl_skb_iph (struct sk_buff *skb)
{
+#if (LINUX_VERSION_CODE >= 0x020616)
+ return (struct iphdr*) skb->network_header;
+#else
return skb->nh.iph;
+#endif
}
net_device_t * nl_skb_dev
Patch for Apani Nortel VPN Client to build against kernel 2.6.22 help/review
Hi all,
Sadly I have to use the Apani/Nortel VPN linux client to connect to my office.
The latest version (3.5) stopped being compatible with the latest stable 2.6.22
kernel (how suprising :().
Since
1) I'm stuck using that closed source/proprietary software
2) there will most probably not be a new release from apani until year 2013
3) support from apani is near zero
we got used with previous version (aka 3.3) to hack the linux_wrapper.c file to
try to keep the module compatible
(http://www.fedoraforum.org/forum/showpost.php?p=742619postcount=26)
Based on the horrors that showed up while compiling against a 2.6.22 kernel
(see below), I was wondering if somebody would be kind enough to review our
not-yet-working patch that converts dev_base/skb calls to the new API. A
collegue of mine made all the required changes but when the netlock service
gets fired-up the machine hang.
Are there any ways to debug this black box?
Help very much appreciated.
--
Here is the not-yet-working patch against the linux_wrapper.c file:
--- cvc_linux-rh-gcc3-3.5.orig/src/linux_wrapper.c 2007-02-07
19:10:41.0 +
+++ cvc_linux-rh-gcc3-3.5/src/linux_wrapper.c 2007-08-21 17:42:30.0
+
@@ -136,6 +136,8 @@ int nl_open(struct inode *inode, struct
/* some necessary globals... */
#if ((LINUX_VERSION_CODE = 0x020200) (LINUX_VERSION_CODE 0x020300))
typedef struct device net_device_t;
+#elif (LINUX_VERSION_CODE = 0x020616)
+typedef struct list_head net_device_t;
#else
typedef struct net_device net_device_t;
#endif
@@ -306,8 +308,11 @@ nl_copy_to_user(void *to, const void *fr
void init_misc(void)
{
-
+#if (LINUX_VERSION_CODE = 0x020616)
+nl_dev_base = dev_base_head;
+#else
nl_dev_base = dev_base;
+#endif
}
#if ((LINUX_VERSION_CODE = 0x020200) (LINUX_VERSION_CODE 0x020300))
@@ -430,8 +435,13 @@ void nl_skb_put(struct sk_buff *skb, int
int nl_ip_rcv(struct sk_buff *skb, struct packet_type *pt)
{
#if (LINUX_VERSION_CODE 0x02060c)
+#if (LINUX_VERSION_CODE = 0x020616)
+struct net_device *dev = skb-dev;
+struct iphdr *iph = (struct iphdr*) skb-network_header;
+#else
struct net_device *dev = skb-dev;
struct iphdr *iph = skb-nh.iph;
+#endif
if (skb-dst == NULL)
{
@@ -469,28 +479,52 @@ int nl_unregister_netdevice_notifier(str
char *dev_name (net_device_t *dev)
{
+#if (LINUX_VERSION_CODE = 0x020616)
+ return (net_device_entry(dev)-name);
+#else
return (dev-name);
+#endif
}
int dev_name_len (net_device_t *dev)
{
+#if (LINUX_VERSION_CODE = 0x020616)
+ return (strlen(net_device_entry(dev)-name));
+#else
return (strlen(dev-name));
+#endif
}
unsigned *dev_mtu_ptr (net_device_t *dev)
{
- return (dev-mtu);
+#if (LINUX_VERSION_CODE = 0x020616)
+ return (net_device_entry(dev)-mtu);
+#else
+ return (dev-mtu);
+#endif
}
unsigned dev_mtu (net_device_t *dev)
{
+#if (LINUX_VERSION_CODE = 0x020616)
+ return (net_device_entry(dev)-mtu);
+#else
return (dev-mtu);
+#endif
}
int dev_ifindex (net_device_t *dev)
{
+#if (LINUX_VERSION_CODE = 0x020616)
+ return (net_device_entry(dev)-ifindex);
+#else
return (dev-ifindex);
+#endif
}
void *dev_ip_ptr (net_device_t *dev)
{
+#if (LINUX_VERSION_CODE = 0x020616)
+ return (net_device_entry(dev)-ip_ptr);
+#else
return (dev-ip_ptr);
+#endif
}
net_device_t *dev_next (net_device_t *dev)
{
@@ -546,9 +580,15 @@ void nl_skb_dup (struct sk_buff *new_skb
head_offset = new_skb-head - skb-head;
new_skb-dev = skb-dev;
new_skb-dst = dst_clone(skb-dst);
+#if (LINUX_VERSION_CODE = 0x020616)
+new_skb-transport_header = skb-transport_header+head_offset;
+new_skb-network_header = skb-network_header+head_offset;
+new_skb-mac_header = skb-mac_header+head_offset;
+#else
new_skb-h.raw = skb-h.raw+head_offset;
new_skb-nh.raw = skb-nh.raw+head_offset;
new_skb-mac.raw = skb-mac.raw+head_offset;
+#endif
memcpy(new_skb-cb, skb-cb, sizeof(skb-cb));
new_skb-priority = skb-priority;
new_skb-protocol = skb-protocol;
@@ -573,9 +613,15 @@ void nl_skb_hdr_copy (struct sk_buff *sk
{
skb_to-dev = skb_from-dev;
skb_to-dst = skb_from-dst;
+#if (LINUX_VERSION_CODE = 0x020616)
+ skb_to-transport_header = skb_from-transport_header;
+ skb_to-network_header = skb_from-network_header;
+ skb_to-mac_header = skb_from-mac_header;
+#else
skb_to-h.raw = skb_from-h.raw;
skb_to-nh.raw = skb_from-nh.raw;
skb_to-mac.raw = skb_from-mac.raw;
+#endif
memcpy(skb_to-cb, skb_from-cb, sizeof(skb_from-cb));
skb_to-priority = skb_from-priority;
skb_to-protocol = skb_from-protocol;
@@ -592,7 +638,11 @@ void nl_skb_hdr_copy (struct sk_buff *sk
struct iphdr * nl_skb_iph (struct sk_buff *skb)
{
+#if (LINUX_VERSION_CODE = 0x020616)
+ return (struct iphdr*) skb-network_header;
+#else
return skb-nh.iph;
+#endif
}
net_device_t * nl_skb_dev (struct sk_buff *skb)
@@ -613,10 +663,14 @@ void nl_send_skb (struct sk_buff
RE: 2.6.21.5 june 30th to july 1st date hang?
> -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] De la part de Chuck Ebbert > Envoyé : 3 juillet 2007 17:03 > > On 07/03/2007 03:28 PM, Chris Friesen wrote: > > Arne Georg Gleditsch wrote: > > > >> An interesting exercise might be to > >> code up a small program to call adjtimex with timex.status |= > >> STA_INS, to see if this can trigger the problem. > > > > Setting the date to just before midnight June 30 UTC and then running > > the following as root triggered the crash on a modified 2.6.10. > > Anyone see anything wrong with the code below, or is this a valid > > indication of a bug in the leap second code? > > > > Fixed: > http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2 > .6.git;a=commitdiff;h=746976a301ac9c9aa10d7d42454f8d6cdad8ff2b Thanx a lot! This was fast! (beat that closed source!) - vin - 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.21.5 june 30th to july 1st date hang?
> -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] De la part de > Chris Friesen > > Fortier,Vincent [Montreal] wrote: > > Hi all, > > > > All my servers and workstations running a 2.6.21.5 kernel hanged > > exactly when the date shift from june 30th to july 1st. > > Interesting, I just sent out an email for a similar issue, > but with a pair of 2.6.10 machines. > > I'm wondering if its related to a spurious leap second event... > Just wondering, what is your distribution? - vin - 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.21.5 june 30th to july 1st date hang?
> -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] De la part de > Arne Georg Gleditsch > > Florian Attenberger <[EMAIL PROTECTED]> writes: > > yep, controlled by ntpd. > > You're right according to > > ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.33 > > that event shouldn't have been there. > > I'm not all that versed in ntp-ish, but it appears that the > leap second insertion should be propagated through the ntp protocol. > Whether the leap second in question came from a ntp server > giving out wrong data or from a misinterpretation or bug in > ntpd is of course hard to say, but either way turning the > clock back is unlikely to reconstruct the circumstances. An > interesting exercise might be to code up a small program to > call adjtimex with timex.status |= STA_INS, to see if this > can trigger the problem. (The bogus leap second might be a > red herring entirely, of course...) You are probably right, I did tried to reproduce the problem without success... Although it is wierd that it happend only on 2.6.21 kernels... It did not happend on any of my workstations/servers running either 2.6.18 or 2.6.20. Could dynticks be involved? - vin - 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.21.5 june 30th to july 1st date hang?
> -Message d'origine- > De : Clemens Koller [mailto:[EMAIL PROTECTED] > Envoyé : 3 juillet 2007 09:05 > > Hi, Vincent! > > Fortier,Vincent [Montreal] schrieb: > > Hi all, > > > > All my servers and workstations running a 2.6.21.5 kernel hanged > > exactly when the date shift from june 30th to july 1st. > > > > I could not get anything on any of the 20+ consoles... All the > > systems hanged at around the exact same time... When the date shifted > > from June 30th to July 1st in UTC ...? > > > > Any clue any one? > > No problems over here with plain 2.6.21.5 on x686 > > You could just reset the date back on one of these machines > and check the transition again... and see if it was really > the kernel who crashed and check your cron configuration. I tried reverting to 23:50 June 30th and it did not hanged when switching to July 1st. I've tried it a few times without any problems. So I deactivated all NTP related jobs, switched the date back to June 30th 23:10 and reboot the system. Wait and see. > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] De la part de Uli Luckas > > Same thing here on two machines with plain vanilla > 2.6.21.(3/4), on debian testing & debian unstable. > I am also using Debian... But Sarge 3.1. There might be a relation there unless somebody comes up having the same problem using another dist. At least it's not CFS related. > -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] De la part de > Arne Georg Gleditsch > > Florian Attenberger <[EMAIL PROTECTED]> writes: > > there was one 'special' event at that date: > > syslog.2.gz:Jul 1 01:59:59 master kernel: Clock: inserting leap > > second 23:59:60 UTC > > As far as I can tell, no leap second was due to be inserted > at 1. of July this year. Is the year set correctly for this box? > All my server/workstations are in sync using ntp... And yes, the year is set properly on all of them. Regards, - vin - 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.21.5 june 30th to july 1st date hang?
> -Message d'origine-
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] De la part de
> Fortier,Vincent [Montreal]
> Envoyé : 3 juillet 2007 08:44
>
> Hi all,
>
> All my servers and workstations running a 2.6.21.5 kernel
> hanged exactly when the date shift from june 30th to july 1st.
>
> On my monitoring system every single station running a
> 2.6.21.5 kernel stoped responding exactly after midnight on
> the date shift from June 30th to July 1st. Although,
> stations still running 2.6.18 to 2.6.20.11 worked flawlessly.
>
> I first tought there had been an electricity outage but two
> of my servers (dell PE 2950 dual-quad core) on UPS in our
> server room also
> hanged:
> Jun 30 23:55:01 urpdev1 /USR/SBIN/CRON[31298]: (root) CMD ([ -x
> /usr/lib/sysstat/sa1 ] && { [ -r "$DEFAULT" ] && . "$DEFAULT"
> ; [ "$ENABLED" = "true" ] && exec /usr/lib/sysstat/sa1; })
> Jul 3 11:54:03 urpdev1 syslogd 1.4.1#17: restart.
>
> I could not get anything on any of the 20+ consoles... All
> the systems hanged at around the exact same time... When the
> date shifted from June 30th to July 1st in UTC ...?
>
> Any clue any one?
Forgot to mention:
- All stations that failed where running a 2.6.21 kernel + CFS v18 (I don't
have any stations running a plain 2.6.21 kernel so can't tell)
- Config file can be found at:
http://linux-dev.qc.ec.gc.ca/kernel/debian/CONFIG-i686-2.6.21-005
- kernels can be found at:
http://linux-dev.qc.ec.gc.ca/kernel/debian/sarge/i686/2.6.21/
>
> - vin
>
-
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.21.5 june 30th to july 1st date hang?
Hi all,
All my servers and workstations running a 2.6.21.5 kernel hanged exactly
when the date shift from june 30th to july 1st.
On my monitoring system every single station running a 2.6.21.5 kernel
stoped responding exactly after midnight on the date shift from June
30th to July 1st. Although, stations still running 2.6.18 to 2.6.20.11
worked flawlessly.
I first tought there had been an electricity outage but two of my
servers (dell PE 2950 dual-quad core) on UPS in our server room also
hanged:
Jun 30 23:55:01 urpdev1 /USR/SBIN/CRON[31298]: (root) CMD ([ -x
/usr/lib/sysstat/sa1 ] && { [ -r "$DEFAULT" ] && . "$DEFAULT" ; [
"$ENABLED" = "true" ] && exec /usr/lib/sysstat/sa1; })
Jul 3 11:54:03 urpdev1 syslogd 1.4.1#17: restart.
I could not get anything on any of the 20+ consoles... All the systems
hanged at around the exact same time... When the date shifted from June
30th to July 1st in UTC ...?
Any clue any one?
- vin
-
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.21.5 june 30th to july 1st date hang?
Hi all,
All my servers and workstations running a 2.6.21.5 kernel hanged exactly
when the date shift from june 30th to july 1st.
On my monitoring system every single station running a 2.6.21.5 kernel
stoped responding exactly after midnight on the date shift from June
30th to July 1st. Although, stations still running 2.6.18 to 2.6.20.11
worked flawlessly.
I first tought there had been an electricity outage but two of my
servers (dell PE 2950 dual-quad core) on UPS in our server room also
hanged:
Jun 30 23:55:01 urpdev1 /USR/SBIN/CRON[31298]: (root) CMD ([ -x
/usr/lib/sysstat/sa1 ] { [ -r $DEFAULT ] . $DEFAULT ; [
$ENABLED = true ] exec /usr/lib/sysstat/sa1; })
Jul 3 11:54:03 urpdev1 syslogd 1.4.1#17: restart.
I could not get anything on any of the 20+ consoles... All the systems
hanged at around the exact same time... When the date shifted from June
30th to July 1st in UTC ...?
Any clue any one?
- vin
-
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.21.5 june 30th to july 1st date hang?
-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] De la part de
Fortier,Vincent [Montreal]
Envoyé : 3 juillet 2007 08:44
Hi all,
All my servers and workstations running a 2.6.21.5 kernel
hanged exactly when the date shift from june 30th to july 1st.
On my monitoring system every single station running a
2.6.21.5 kernel stoped responding exactly after midnight on
the date shift from June 30th to July 1st. Although,
stations still running 2.6.18 to 2.6.20.11 worked flawlessly.
I first tought there had been an electricity outage but two
of my servers (dell PE 2950 dual-quad core) on UPS in our
server room also
hanged:
Jun 30 23:55:01 urpdev1 /USR/SBIN/CRON[31298]: (root) CMD ([ -x
/usr/lib/sysstat/sa1 ] { [ -r $DEFAULT ] . $DEFAULT
; [ $ENABLED = true ] exec /usr/lib/sysstat/sa1; })
Jul 3 11:54:03 urpdev1 syslogd 1.4.1#17: restart.
I could not get anything on any of the 20+ consoles... All
the systems hanged at around the exact same time... When the
date shifted from June 30th to July 1st in UTC ...?
Any clue any one?
Forgot to mention:
- All stations that failed where running a 2.6.21 kernel + CFS v18 (I don't
have any stations running a plain 2.6.21 kernel so can't tell)
- Config file can be found at:
http://linux-dev.qc.ec.gc.ca/kernel/debian/CONFIG-i686-2.6.21-005
- kernels can be found at:
http://linux-dev.qc.ec.gc.ca/kernel/debian/sarge/i686/2.6.21/
- vin
-
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.21.5 june 30th to july 1st date hang?
-Message d'origine- De : Clemens Koller [mailto:[EMAIL PROTECTED] Envoyé : 3 juillet 2007 09:05 Hi, Vincent! Fortier,Vincent [Montreal] schrieb: Hi all, All my servers and workstations running a 2.6.21.5 kernel hanged exactly when the date shift from june 30th to july 1st. I could not get anything on any of the 20+ consoles... All the systems hanged at around the exact same time... When the date shifted from June 30th to July 1st in UTC ...? Any clue any one? No problems over here with plain 2.6.21.5 on x686 You could just reset the date back on one of these machines and check the transition again... and see if it was really the kernel who crashed and check your cron configuration. I tried reverting to 23:50 June 30th and it did not hanged when switching to July 1st. I've tried it a few times without any problems. So I deactivated all NTP related jobs, switched the date back to June 30th 23:10 and reboot the system. Wait and see. De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Uli Luckas Same thing here on two machines with plain vanilla 2.6.21.(3/4), on debian testing debian unstable. I am also using Debian... But Sarge 3.1. There might be a relation there unless somebody comes up having the same problem using another dist. At least it's not CFS related. -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Arne Georg Gleditsch Florian Attenberger [EMAIL PROTECTED] writes: there was one 'special' event at that date: syslog.2.gz:Jul 1 01:59:59 master kernel: Clock: inserting leap second 23:59:60 UTC As far as I can tell, no leap second was due to be inserted at 1. of July this year. Is the year set correctly for this box? All my server/workstations are in sync using ntp... And yes, the year is set properly on all of them. Regards, - vin - 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.21.5 june 30th to july 1st date hang?
-Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Arne Georg Gleditsch Florian Attenberger [EMAIL PROTECTED] writes: yep, controlled by ntpd. You're right according to ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.33 that event shouldn't have been there. I'm not all that versed in ntp-ish, but it appears that the leap second insertion should be propagated through the ntp protocol. Whether the leap second in question came from a ntp server giving out wrong data or from a misinterpretation or bug in ntpd is of course hard to say, but either way turning the clock back is unlikely to reconstruct the circumstances. An interesting exercise might be to code up a small program to call adjtimex with timex.status |= STA_INS, to see if this can trigger the problem. (The bogus leap second might be a red herring entirely, of course...) You are probably right, I did tried to reproduce the problem without success... Although it is wierd that it happend only on 2.6.21 kernels... It did not happend on any of my workstations/servers running either 2.6.18 or 2.6.20. Could dynticks be involved? - vin - 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.21.5 june 30th to july 1st date hang?
-Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Chris Friesen Fortier,Vincent [Montreal] wrote: Hi all, All my servers and workstations running a 2.6.21.5 kernel hanged exactly when the date shift from june 30th to july 1st. Interesting, I just sent out an email for a similar issue, but with a pair of 2.6.10 machines. I'm wondering if its related to a spurious leap second event... Just wondering, what is your distribution? - vin - 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.21.5 june 30th to july 1st date hang?
-Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Chuck Ebbert Envoyé : 3 juillet 2007 17:03 On 07/03/2007 03:28 PM, Chris Friesen wrote: Arne Georg Gleditsch wrote: An interesting exercise might be to code up a small program to call adjtimex with timex.status |= STA_INS, to see if this can trigger the problem. Setting the date to just before midnight June 30 UTC and then running the following as root triggered the crash on a modified 2.6.10. Anyone see anything wrong with the code below, or is this a valid indication of a bug in the leap second code? Fixed: http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2 .6.git;a=commitdiff;h=746976a301ac9c9aa10d7d42454f8d6cdad8ff2b Thanx a lot! This was fast! (beat that closed source!) - vin - 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] CFS scheduler, -v18
> -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] De la part de Ingo Molnar > Envoyé : 22 juin 2007 18:02 > > i'm pleased to announce release -v18 of the CFS scheduler patchset. > > The rolled-up CFS patch against today's -git kernel, > v2.6.22-rc5, v2.6.22-rc4-mm2, v2.6.21.5 or v2.6.20.14 can be > downloaded from the usual place: > >http://people.redhat.com/mingo/cfs-scheduler/ > > ... Pre-built kernels for Fedora 7 & Fedora Core 6 (yum reporsitory available) and Debian Sarge/Etch using latest CFS v18 available at http://linux-dev.qc.ec.gc.ca > > As usual, any sort of feedback, bugreport, fix and suggestion > is more than welcome! > > Ingo - vin - 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] CFS scheduler, -v18
-Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Ingo Molnar Envoyé : 22 juin 2007 18:02 i'm pleased to announce release -v18 of the CFS scheduler patchset. The rolled-up CFS patch against today's -git kernel, v2.6.22-rc5, v2.6.22-rc4-mm2, v2.6.21.5 or v2.6.20.14 can be downloaded from the usual place: http://people.redhat.com/mingo/cfs-scheduler/ ... Pre-built kernels for Fedora 7 Fedora Core 6 (yum reporsitory available) and Debian Sarge/Etch using latest CFS v18 available at http://linux-dev.qc.ec.gc.ca As usual, any sort of feedback, bugreport, fix and suggestion is more than welcome! Ingo - vin - 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: Broadcom (bnx2) on PE1950/2950 failure
> Huh? eth0 and eth1 are the e1000 adapters, eth3 (and > presumably eth2) are the bnx2 adapters.. Got it... Almost... There was a confusion between /etc/udev/rules.d/z25_persistent-net.rules, the fact that bnx2 was in the initrd image but not e1000. So I edited /etc/udev/rules.d/z25_persistent-net.rules to set the order I wanted using directly the PCI ID as provided by the lspci -vvv: [EMAIL PROTECTED] /etc]# lspci -vvv | grep Ethernet 05:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12) 09:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12) 0e:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) 0e:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) [EMAIL PROTECTED] rules.d]# cat /etc/udev/rules.d/z25_persistent-net.rules # This file was automatically generated by the /lib/udev/write_net_rules # program, probably run by the persistent-net-generator.rules rules file. # # You can modify it, as long as you keep each rule on a single line. # MAC addresses must be written in lowercase. SUBSYSTEM=="net", DRIVERS=="?*", KERNELS==":05:00.0", NAME="eth0" SUBSYSTEM=="net", DRIVERS=="?*", KERNELS==":09:00.0", NAME="eth1" SUBSYSTEM=="net", DRIVERS=="?*", KERNELS==":0e:00.0", NAME="eth2" SUBSYSTEM=="net", DRIVERS=="?*", KERNELS==":0e:00.1", NAME="eth3" And recreated the initrd image after having set which module not to forget... And it's order: [EMAIL PROTECTED] /etc]# cat /etc/initramfs-tools/modules # List of modules that you want to include in your initramfs. # # Syntax: module_name [args ...] # # You must run update-initramfs(8) to effect this change. # # Examples: # # raid1 # sd_mod bnx2 e1000 Here is the output of the dmesg with now the appropriate order: [EMAIL PROTECTED] /etc]# dmesg | grep -i eth [ 120.685696] Broadcom NetXtreme II Gigabit Ethernet Driver bnx2 v1.5.8.1 (May 7, 2007) [ 120.703846] eth0: Broadcom NetXtreme II BCM5708 1000Base-T (B2) PCI-X 64-bit 133MHz found at mem f800, IRQ 17, node addr 0019b9c8eedc [ 120.735350] eth1: Broadcom NetXtreme II BCM5708 1000Base-T (B2) PCI-X 64-bit 133MHz found at mem f400, IRQ 16, node addr 0019b9c8eede [ 120.921403] e1000: eth2: e1000_probe: Intel(R) PRO/1000 Network Connection [ 121.069025] e1000: eth3: e1000_probe: Intel(R) PRO/1000 Network Connection [ 267.720475] bnx2: eth0: using MSI [ 270.832235] bnx2: eth0 NIC Link is Up, 1000 Mbps full duplex, receive & transmit flow control ON But still, there is a problem with the second Broadcom port (eth1): [EMAIL PROTECTED] /etc]# mii-tool eth0: negotiated 100baseTx-FD flow-control, link ok SIOCGMIIPHY on 'eth1' failed: Resource temporarily unavailable eth2: negotiated 100baseTx-FD flow-control, link ok eth3: negotiated 100baseTx-FD flow-control, link ok I don't get it? Help appreciated. - vin - 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: Broadcom (bnx2) on PE1950/2950 failure
Huh? eth0 and eth1 are the e1000 adapters, eth3 (and presumably eth2) are the bnx2 adapters.. Got it... Almost... There was a confusion between /etc/udev/rules.d/z25_persistent-net.rules, the fact that bnx2 was in the initrd image but not e1000. So I edited /etc/udev/rules.d/z25_persistent-net.rules to set the order I wanted using directly the PCI ID as provided by the lspci -vvv: [EMAIL PROTECTED] /etc]# lspci -vvv | grep Ethernet 05:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12) 09:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12) 0e:00.0 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) 0e:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06) [EMAIL PROTECTED] rules.d]# cat /etc/udev/rules.d/z25_persistent-net.rules # This file was automatically generated by the /lib/udev/write_net_rules # program, probably run by the persistent-net-generator.rules rules file. # # You can modify it, as long as you keep each rule on a single line. # MAC addresses must be written in lowercase. SUBSYSTEM==net, DRIVERS==?*, KERNELS==:05:00.0, NAME=eth0 SUBSYSTEM==net, DRIVERS==?*, KERNELS==:09:00.0, NAME=eth1 SUBSYSTEM==net, DRIVERS==?*, KERNELS==:0e:00.0, NAME=eth2 SUBSYSTEM==net, DRIVERS==?*, KERNELS==:0e:00.1, NAME=eth3 And recreated the initrd image after having set which module not to forget... And it's order: [EMAIL PROTECTED] /etc]# cat /etc/initramfs-tools/modules # List of modules that you want to include in your initramfs. # # Syntax: module_name [args ...] # # You must run update-initramfs(8) to effect this change. # # Examples: # # raid1 # sd_mod bnx2 e1000 Here is the output of the dmesg with now the appropriate order: [EMAIL PROTECTED] /etc]# dmesg | grep -i eth [ 120.685696] Broadcom NetXtreme II Gigabit Ethernet Driver bnx2 v1.5.8.1 (May 7, 2007) [ 120.703846] eth0: Broadcom NetXtreme II BCM5708 1000Base-T (B2) PCI-X 64-bit 133MHz found at mem f800, IRQ 17, node addr 0019b9c8eedc [ 120.735350] eth1: Broadcom NetXtreme II BCM5708 1000Base-T (B2) PCI-X 64-bit 133MHz found at mem f400, IRQ 16, node addr 0019b9c8eede [ 120.921403] e1000: eth2: e1000_probe: Intel(R) PRO/1000 Network Connection [ 121.069025] e1000: eth3: e1000_probe: Intel(R) PRO/1000 Network Connection [ 267.720475] bnx2: eth0: using MSI [ 270.832235] bnx2: eth0 NIC Link is Up, 1000 Mbps full duplex, receive transmit flow control ON But still, there is a problem with the second Broadcom port (eth1): [EMAIL PROTECTED] /etc]# mii-tool eth0: negotiated 100baseTx-FD flow-control, link ok SIOCGMIIPHY on 'eth1' failed: Resource temporarily unavailable eth2: negotiated 100baseTx-FD flow-control, link ok eth3: negotiated 100baseTx-FD flow-control, link ok I don't get it? Help appreciated. - vin - 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/
Broadcom (bnx2) on PE1950/2950 failure
When trying manually to get the on-board broadcom adapter working I get this: Jun 21 16:50:47 urpdev1 kernel: [ 184.528092] Broadcom NetXtreme II Gigabit Ethernet Driver bnx2 v1.4.45 (September 29, 2006) Jun 21 16:50:47 urpdev1 kernel: [ 184.539831] ACPI: PCI Interrupt :05:00.0[A] -> GSI 16 (level, low) -> IRQ 17 Jun 21 16:50:48 urpdev1 kernel: [ 184.551805] eth0: Broadcom NetXtreme II BCM5708 1000Base-T (B2) PCI-X 64-bit 133MHz found at mem f800, IRQ 17, node ad dr 0019b9c8eedc Jun 21 16:50:48 urpdev1 kernel: [ 184.576672] ACPI: PCI Interrupt :09:00.0[A] -> GSI 17 (level, low) -> IRQ 16 Jun 21 16:50:48 urpdev1 kernel: [ 184.590359] eth0: Broadcom NetXtreme II BCM5708 1000Base-T (B2) PCI-X 64-bit 133MHz found at mem f400, IRQ 16, node ad dr 0019b9c8eede Jun 21 16:50:52 urpdev1 dhclient: Internet Systems Consortium DHCP Client V3.0.1 Jun 21 16:50:52 urpdev1 dhclient: Copyright 2004 Internet Systems Consortium. Jun 21 16:50:52 urpdev1 dhclient: All rights reserved. Jun 21 16:50:52 urpdev1 dhclient: For info, please visit http://www.isc.org/products/DHCP Jun 21 16:50:52 urpdev1 dhclient: Jun 21 16:50:53 urpdev1 dhclient: Bind socket to interface: No such device When I invoke "modprobe bnx2" it looks like both adapter fails to initialise properly reason I think both are trying to bind on eth0 instead of eth0 & eth1. I've removed the TOE jumper (has read on a gentoo list) with no effect (except that it really is disabled in the BIOS now). I've also tried loading the driver using disable_msi=1 option without any effect. The problem occurs on all tested kernels (2.6.18.8, 2.6.19.7, 2.6.20.14 & 2.6.21.5) Here is part of the dmesg: [EMAIL PROTECTED] /root]# dmesg | grep -i eth [ 119.196375] Broadcom NetXtreme II Gigabit Ethernet Driver bnx2 v1.5.8.1 (May 7, 2007) [ 119.215023] eth0: Broadcom NetXtreme II BCM5708 1000Base-T (B2) PCI-X 64-bit 133MHz found at mem f800, IRQ 17, node addr 0019b9c8eedc [ 119.246853] eth1: Broadcom NetXtreme II BCM5708 1000Base-T (B2) PCI-X 64-bit 133MHz found at mem f400, IRQ 16, node addr 0019b9c8eede [ 119.458598] e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection [ 119.654095] e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection [ 266.513144] bnx2: eth3: using MSI [ 269.638237] bnx2: eth3 NIC Link is Up, 1000 Mbps full duplex, receive & transmit flow control ON [ 290.242533] eth3: no IPv6 routers present As you can notice it tried to use eth0 & eth1 for both broadcom adapters but it did not worked properly since e1000 used them instead and finally bnx2 got eth3 working using MSI ? Here is the mii-tool output: [EMAIL PROTECTED] /root]# mii-tool eth0: no link eth1: no link SIOCGMIIPHY on 'eth2' failed: Resource temporarily unavailable eth3: negotiated 100baseTx-FD flow-control, link ok So by switching the network config from eth0 to eth3 made the on-board port 1 working ? Here is the lspci output: 05:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12) Subsystem: Dell Unknown device 01b2 Control: I/O- Mem+ BusMaster+ SpecCycle+ MemWINV+ VGASnoop- ParErr+ Stepping- SERR+ FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- http://linux-dev.qc.ec.gc.ca/kernel/debian/dmesg-2.6.21.5-bnx2-error.txt Full lspci -vvv: http://linux-dev.qc.ec.gc.ca/kernel/debian/lspci-2.6.21.5-bnx2-error.txt Config (2.6.21.5): http://linux-dev.qc.ec.gc.ca/kernel/debian/CONFIG-i686-2.6.21-005 Help would greatly be appreciated! - vin - 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/
Broadcom (bnx2) on PE1950/2950 failure
When trying manually to get the on-board broadcom adapter working I get this: Jun 21 16:50:47 urpdev1 kernel: [ 184.528092] Broadcom NetXtreme II Gigabit Ethernet Driver bnx2 v1.4.45 (September 29, 2006) Jun 21 16:50:47 urpdev1 kernel: [ 184.539831] ACPI: PCI Interrupt :05:00.0[A] - GSI 16 (level, low) - IRQ 17 Jun 21 16:50:48 urpdev1 kernel: [ 184.551805] eth0: Broadcom NetXtreme II BCM5708 1000Base-T (B2) PCI-X 64-bit 133MHz found at mem f800, IRQ 17, node ad dr 0019b9c8eedc Jun 21 16:50:48 urpdev1 kernel: [ 184.576672] ACPI: PCI Interrupt :09:00.0[A] - GSI 17 (level, low) - IRQ 16 Jun 21 16:50:48 urpdev1 kernel: [ 184.590359] eth0: Broadcom NetXtreme II BCM5708 1000Base-T (B2) PCI-X 64-bit 133MHz found at mem f400, IRQ 16, node ad dr 0019b9c8eede Jun 21 16:50:52 urpdev1 dhclient: Internet Systems Consortium DHCP Client V3.0.1 Jun 21 16:50:52 urpdev1 dhclient: Copyright 2004 Internet Systems Consortium. Jun 21 16:50:52 urpdev1 dhclient: All rights reserved. Jun 21 16:50:52 urpdev1 dhclient: For info, please visit http://www.isc.org/products/DHCP Jun 21 16:50:52 urpdev1 dhclient: Jun 21 16:50:53 urpdev1 dhclient: Bind socket to interface: No such device When I invoke modprobe bnx2 it looks like both adapter fails to initialise properly reason I think both are trying to bind on eth0 instead of eth0 eth1. I've removed the TOE jumper (has read on a gentoo list) with no effect (except that it really is disabled in the BIOS now). I've also tried loading the driver using disable_msi=1 option without any effect. The problem occurs on all tested kernels (2.6.18.8, 2.6.19.7, 2.6.20.14 2.6.21.5) Here is part of the dmesg: [EMAIL PROTECTED] /root]# dmesg | grep -i eth [ 119.196375] Broadcom NetXtreme II Gigabit Ethernet Driver bnx2 v1.5.8.1 (May 7, 2007) [ 119.215023] eth0: Broadcom NetXtreme II BCM5708 1000Base-T (B2) PCI-X 64-bit 133MHz found at mem f800, IRQ 17, node addr 0019b9c8eedc [ 119.246853] eth1: Broadcom NetXtreme II BCM5708 1000Base-T (B2) PCI-X 64-bit 133MHz found at mem f400, IRQ 16, node addr 0019b9c8eede [ 119.458598] e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection [ 119.654095] e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection [ 266.513144] bnx2: eth3: using MSI [ 269.638237] bnx2: eth3 NIC Link is Up, 1000 Mbps full duplex, receive transmit flow control ON [ 290.242533] eth3: no IPv6 routers present As you can notice it tried to use eth0 eth1 for both broadcom adapters but it did not worked properly since e1000 used them instead and finally bnx2 got eth3 working using MSI ? Here is the mii-tool output: [EMAIL PROTECTED] /root]# mii-tool eth0: no link eth1: no link SIOCGMIIPHY on 'eth2' failed: Resource temporarily unavailable eth3: negotiated 100baseTx-FD flow-control, link ok So by switching the network config from eth0 to eth3 made the on-board port 1 working ? Here is the lspci output: 05:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12) Subsystem: Dell Unknown device 01b2 Control: I/O- Mem+ BusMaster+ SpecCycle+ MemWINV+ VGASnoop- ParErr+ Stepping- SERR+ FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 32 (16000ns min), Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 214 Region 0: Memory at f800 (64-bit, non-prefetchable) [size=32M] Capabilities: [40] PCI-X non-bridge device Command: DPERE- ERO- RBC=512 OST=8 Status: Dev=05:00.0 64bit+ 133MHz+ SCD- USC- DC=simple DMMRBC=512 DMOST=8 DMCRS=32 RSCEM- 266MHz- 533MHz- Capabilities: [48] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=1 PME- Capabilities: [50] Vital Product Data Capabilities: [58] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+ Address: feeff00c Data: 416a 09:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet (rev 12) Subsystem: Dell Unknown device 01b2 Control: I/O- Mem+ BusMaster+ SpecCycle+ MemWINV+ VGASnoop- ParErr+ Stepping- SERR+ FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 64 (16000ns min), Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 16 Region 0: Memory at f400 (64-bit, non-prefetchable) [size=32M] Capabilities: [40] PCI-X non-bridge device Command: DPERE- ERO- RBC=512 OST=8 Status: Dev=09:00.0 64bit+ 133MHz+ SCD- USC- DC=simple DMMRBC=512 DMOST=8 DMCRS=32 RSCEM- 266MHz- 533MHz- Capabilities: [48] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
RE: How to improve the quality of the kernel?
> -Message d'origine- > De : Natalie Protasevich [mailto:[EMAIL PROTECTED] > Envoyé : 18 juin 2007 18:56 > > On 6/18/07, Martin Bligh <[EMAIL PROTECTED]> wrote: > > >> > So if you make changes to random-driver.c you can do `git-log > > >> > random-driver.c|grep Tested-by" to find people who can test your > > >> > changes for you. > > >> > > >> You would'nt even need to search in GIT. Maybie even when ever a > > >> patchset is being proposed a mail could be sent to appropriate > > >> hardware/or feature pseudo-auto-generated mailing-list? > > >> > > >> On lkml I mostly try to follow patches/bugs associated with > > >> hardware I use. Why not try to automate the process and get more > > >> testers in? > > >> > > > > > > I think this is an excellent point. One data point could be a field > > > in bugzilla to input the hardware information. Simple query can > > > select common hardware and platform. So far it's not working when > > > hardware is just mentioned in the text part. > > > > if it's free text it'll be useless for search ... I suppose we could > > do drop-downs for architecture at least? Not sure much beyond that > > would work ... *possibly* the common drivers, but I don't think we'd > > get enough coverage for it to be of use. > > > How about several buckets for model/BIOS version/chipset > etc., at least optional, and some will be relevant some not > for particular cases. But at least people will make an > attempt to collect such data from their system, boards, etc. How about an easy way to send multiple hardware profiles to your bugzilla user account simultaniously linked to an online pciutils database and/or an hardware list database similar to overclocking web sites and why not even with a link to the git repository when possible? A some sort of really usefull "send your profile" of RHN that would link the driver with the discovered hardware and add you to appropriate mailing lists to test patches/help reproducing & solving problems/etc. In the end plenty of statistics and hardware compatibility list could be made. For example, that would make my life easier knowing what level of compatibility Linux can offer for old HP9000 K-boxes that we still have running at the office and presumably get people to contact to get help? - vin - 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: How to improve the quality of the kernel?
> -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] De la part de > Andrew Morton > > On Mon, 18 Jun 2007 01:15:15 +0200 Stefan Richter > <[EMAIL PROTECTED]> wrote: > > > Tested-by > > Tested-by would be good too. Because over time, we will > generate a list of people who own the relevant hardware and > who are prepared to test changes. Why not include a user-space tool that, when invoked, if you agree to send personnal info, sends your hardware vs driver info to a web database + your email address (maybie even you .config, etc..) ... In case of help for testing new patches/finding a bug/etc.. your email could be used by maintainers to ask for help... > So if you make changes to random-driver.c you can do `git-log > random-driver.c|grep Tested-by" to find people who can test > your changes for you. You would'nt even need to search in GIT. Maybie even when ever a patchset is being proposed a mail could be sent to appropriate hardware/or feature pseudo-auto-generated mailing-list? On lkml I mostly try to follow patches/bugs associated with hardware I use. Why not try to automate the process and get more testers in? - vin - 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: How to improve the quality of the kernel?
-Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Andrew Morton On Mon, 18 Jun 2007 01:15:15 +0200 Stefan Richter [EMAIL PROTECTED] wrote: Tested-by Tested-by would be good too. Because over time, we will generate a list of people who own the relevant hardware and who are prepared to test changes. Why not include a user-space tool that, when invoked, if you agree to send personnal info, sends your hardware vs driver info to a web database + your email address (maybie even you .config, etc..) ... In case of help for testing new patches/finding a bug/etc.. your email could be used by maintainers to ask for help... So if you make changes to random-driver.c you can do `git-log random-driver.c|grep Tested-by to find people who can test your changes for you. You would'nt even need to search in GIT. Maybie even when ever a patchset is being proposed a mail could be sent to appropriate hardware/or feature pseudo-auto-generated mailing-list? On lkml I mostly try to follow patches/bugs associated with hardware I use. Why not try to automate the process and get more testers in? - vin - 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: How to improve the quality of the kernel?
-Message d'origine- De : Natalie Protasevich [mailto:[EMAIL PROTECTED] Envoyé : 18 juin 2007 18:56 On 6/18/07, Martin Bligh [EMAIL PROTECTED] wrote: So if you make changes to random-driver.c you can do `git-log random-driver.c|grep Tested-by to find people who can test your changes for you. You would'nt even need to search in GIT. Maybie even when ever a patchset is being proposed a mail could be sent to appropriate hardware/or feature pseudo-auto-generated mailing-list? On lkml I mostly try to follow patches/bugs associated with hardware I use. Why not try to automate the process and get more testers in? I think this is an excellent point. One data point could be a field in bugzilla to input the hardware information. Simple query can select common hardware and platform. So far it's not working when hardware is just mentioned in the text part. if it's free text it'll be useless for search ... I suppose we could do drop-downs for architecture at least? Not sure much beyond that would work ... *possibly* the common drivers, but I don't think we'd get enough coverage for it to be of use. How about several buckets for model/BIOS version/chipset etc., at least optional, and some will be relevant some not for particular cases. But at least people will make an attempt to collect such data from their system, boards, etc. How about an easy way to send multiple hardware profiles to your bugzilla user account simultaniously linked to an online pciutils database and/or an hardware list database similar to overclocking web sites and why not even with a link to the git repository when possible? A some sort of really usefull send your profile of RHN that would link the driver with the discovered hardware and add you to appropriate mailing lists to test patches/help reproducing solving problems/etc. In the end plenty of statistics and hardware compatibility list could be made. For example, that would make my life easier knowing what level of compatibility Linux can offer for old HP9000 K-boxes that we still have running at the office and presumably get people to contact to get help? - vin - 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] CFS scheduler, -v17
> -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] De la part de Ingo Molnar > Envoyé : 14 juin 2007 18:49 > > i'm pleased to announce release -v17 of the CFS scheduler patchset. > > The rolled-up CFS patch against v2.6.22-rc4, v2.6.22-rc4-mm2, > v2.6.21.5 or v2.6.20.13 can be downloaded from the usual place: > >http://people.redhat.com/mingo/cfs-scheduler/ > > -v17 includes a bigger change: the CFS-core changes in > preparation of the group-scheduling feature, written Srivatsa > Vaddagiri. Dmitry Adamushko provided cleanups and further > generalizations to this code and the modularization of CFS > has been further enhanced as a result. To users, these > changes are mostly invisible. > > Changes since -v16: > > - lots of core updates to support group scheduling, and related >cleanups. (Srivatsa Vaddagiri, Dmitry Adamushko) > > - tuned the runtime-limit up a bit, based on relentless > testing done by >Tobias Gerschner. > > - the new, precise load-calculation method for SMP balancing has been >further enhanced, and is now active by default. (Dmitry Adamushko) > > - fix SCHED_IDLEPRIO support (based on feedback from Thomas Sattler) > > - further updates to /proc/sched_debug and /proc/PID/sched > > - more cleanups > > As usual, any sort of feedback, bugreport, fix and suggestion > is more than welcome! Fedora 7 & Debian Sarge 3.1 kernels using latest CFS v17 available at http://linux-dev.qc.ec.gc.ca/ YUM users: http://linux-dev.qc.ec.gc.ca/kernel/fedora/alt-sched.repo Thnx Ingo & cie. > Ingo - vin - 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] CFS scheduler, -v17
-Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Ingo Molnar Envoyé : 14 juin 2007 18:49 i'm pleased to announce release -v17 of the CFS scheduler patchset. The rolled-up CFS patch against v2.6.22-rc4, v2.6.22-rc4-mm2, v2.6.21.5 or v2.6.20.13 can be downloaded from the usual place: http://people.redhat.com/mingo/cfs-scheduler/ -v17 includes a bigger change: the CFS-core changes in preparation of the group-scheduling feature, written Srivatsa Vaddagiri. Dmitry Adamushko provided cleanups and further generalizations to this code and the modularization of CFS has been further enhanced as a result. To users, these changes are mostly invisible. Changes since -v16: - lots of core updates to support group scheduling, and related cleanups. (Srivatsa Vaddagiri, Dmitry Adamushko) - tuned the runtime-limit up a bit, based on relentless testing done by Tobias Gerschner. - the new, precise load-calculation method for SMP balancing has been further enhanced, and is now active by default. (Dmitry Adamushko) - fix SCHED_IDLEPRIO support (based on feedback from Thomas Sattler) - further updates to /proc/sched_debug and /proc/PID/sched - more cleanups As usual, any sort of feedback, bugreport, fix and suggestion is more than welcome! Fedora 7 Debian Sarge 3.1 kernels using latest CFS v17 available at http://linux-dev.qc.ec.gc.ca/ YUM users: http://linux-dev.qc.ec.gc.ca/kernel/fedora/alt-sched.repo Thnx Ingo cie. Ingo - vin - 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: call for more SD versus CFS comparisons (was: Re: [ck] Mainline plans)
> -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] De la part de > Fortier,Vincent [Montreal] > Envoyé : 12 juin 2007 21:36 > À : Miguel Figueiredo; linux kernel mailing list; [EMAIL PROTECTED] > Cc : Con Kolivas; Ingo Molnar > Objet : RE: call for more SD versus CFS comparisons (was: Re: > [ck] Mainline plans) > > > -Message d'origine- > > De : [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] De la part de Miguel > > Figueiredo Envoyé : 11 juin 2007 20:30 > > > > Hi all, > > > > some results based on massing_intr.c by Satoru, can be found on > > http://people.redhat.com/mingo/cfs-scheduler/tools/massive_intr.c > > > > > > I know that other people, who read lkml, also tested the > same way, it > > would be nice if they also post their data. > > > > For the pleasure of comparing CPU schedulers, both CFS v16 & > full CK2 patched pre-built kernels for Fedora 7 using latest > build 3194 are now available at http://linux-dev.qc.ec.gc.ca > > There is also a not yet fully tuned YUM repository > configuration file available at > http://linux-dev.qc.ec.gc.ca/kernel/fedora/alt-sched.repo > Although I suggest you download the rpm's directly from the > web page & install both manually using rpm -ivh --force > > Have fun. > Also, now that I think of it, here are my results: Test: ./massive_intr 20 6000 Hardware: - Athlon 64 4200+ - 2GB ram - nVidia 6600GT using latest Beta driver NVIDIA-Linux-x86_64-100.14.06-pkg2.run - SATA drive - On-board audio (00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio Controller (rev a2)) Kernels: CFS v16 2.6.21 FC7 build 3194 CK2 2.6.21 FC7 build 3194 Here is what the TOP output was looking like for both case: top - 13:36:22 up 38 min, 4 users, load average: 20.41, 13.43, 7.49 Tasks: 172 total, 21 running, 150 sleeping, 0 stopped, 1 zombie Cpu0 : 99.7%us, 0.3%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu1 : 94.7%us, 4.6%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.3%hi, 0.3%si, 0.0%st Mem: 2058860k total, 1217132k used, 841728k free,56456k buffers Swap: 1959888k total,0k used, 1959888k free, 781636k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 6099 megalout 20 0 7860 224 136 R 10 0.0 0:26.12 massive_intr 6102 megalout 20 0 7860 224 136 R 10 0.0 0:26.27 massive_intr 6104 megalout 20 0 7860 224 136 R 10 0.0 0:26.51 massive_intr 6105 megalout 20 0 7860 224 136 R 10 0.0 0:26.32 massive_intr 6107 megalout 20 0 7860 224 136 R 10 0.0 0:26.62 massive_intr 6112 megalout 20 0 7860 224 136 R 10 0.0 0:26.32 massive_intr 6116 megalout 20 0 7860 224 136 R 10 0.0 0:26.26 massive_intr 6109 megalout 20 0 7860 224 136 R 10 0.0 0:26.32 massive_intr 6115 megalout 20 0 7860 224 136 R 10 0.0 0:26.50 massive_intr 6118 megalout 20 0 7860 224 136 R9 0.0 0:26.37 massive_intr 6100 megalout 20 0 7860 224 136 R9 0.0 0:26.51 massive_intr 6103 megalout 20 0 7860 224 136 R9 0.0 0:26.24 massive_intr 6106 megalout 20 0 7860 224 136 R9 0.0 0:26.32 massive_intr 6108 megalout 20 0 7860 224 136 R9 0.0 0:26.32 massive_intr 6110 megalout 20 0 7860 224 136 R9 0.0 0:26.54 massive_intr 6111 megalout 20 0 7860 224 136 R9 0.0 0:26.37 massive_intr 6113 megalout 20 0 7860 224 136 R9 0.0 0:26.56 massive_intr 6114 megalout 20 0 7860 224 136 R9 0.0 0:26.30 massive_intr 6117 megalout 20 0 7860 224 136 R9 0.0 0:26.34 massive_intr 6101 megalout 20 0 7860 224 136 R9 0.0 0:26.31 massive_intr 4681 root 20 0 196m 67m 12m S8 3.4 4:06.00 X 6036 megalout 20 0 694m 53m 32m S2 2.6 0:07.82 amarokapp 4904 megalout 20 0 271m 9.9m 6948 S1 0.5 0:18.16 gkrellm 5054 megalout 20 0 160m 45m 20m S1 2.2 0:10.90 firefox-bin 5201 megalout 20 0 160m 9304 5480 S1 0.5 0:01.42 emerald 5210 megalout 20 0 240m 12m 6284 S1 0.6 0:33.29 beryl CFS v16: - beryl interractivity way too unresponsive.. - window decoration highlight taking around 5-10 secs to switch between windows focus - window movement either impossible or animation laggy enough to not being seen at all. - Cube rotation still possible using mouse scroll although really really really laggy Amarok MP3 music: - No audio skips at all. Playing really well! CK2 patchset: - Beryl interractivity almost totally unresponsive... In fact mouse movement was near-impossible to control. - window movement totally impossible - Cube rotation still possible using mouse scroll although there was no animation at all Amarok MP3 music: -
RE: call for more SD versus CFS comparisons (was: Re: [ck] Mainline plans)
> -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] De la part de > Miguel Figueiredo > Envoyé : 11 juin 2007 20:30 > > Hi all, > > some results based on massing_intr.c by Satoru, can be found > on http://people.redhat.com/mingo/cfs-scheduler/tools/massive_intr.c > > > I know that other people, who read lkml, also tested the same > way, it would be nice if they also post their data. > For the pleasure of comparing CPU schedulers, both CFS v16 & full CK2 patched pre-built kernels for Fedora 7 using latest build 3194 are now available at http://linux-dev.qc.ec.gc.ca There is also a not yet fully tuned YUM repository configuration file available at http://linux-dev.qc.ec.gc.ca/kernel/fedora/alt-sched.repo Although I suggest you download the rpm's directly from the web page & install both manually using rpm -ivh --force Have fun. - vin - 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: call for more SD versus CFS comparisons (was: Re: [ck] Mainline plans)
-Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Miguel Figueiredo Envoyé : 11 juin 2007 20:30 Hi all, some results based on massing_intr.c by Satoru, can be found on http://people.redhat.com/mingo/cfs-scheduler/tools/massive_intr.c I know that other people, who read lkml, also tested the same way, it would be nice if they also post their data. For the pleasure of comparing CPU schedulers, both CFS v16 full CK2 patched pre-built kernels for Fedora 7 using latest build 3194 are now available at http://linux-dev.qc.ec.gc.ca There is also a not yet fully tuned YUM repository configuration file available at http://linux-dev.qc.ec.gc.ca/kernel/fedora/alt-sched.repo Although I suggest you download the rpm's directly from the web page install both manually using rpm -ivh --force Have fun. - vin - 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: call for more SD versus CFS comparisons (was: Re: [ck] Mainline plans)
-Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Fortier,Vincent [Montreal] Envoyé : 12 juin 2007 21:36 À : Miguel Figueiredo; linux kernel mailing list; [EMAIL PROTECTED] Cc : Con Kolivas; Ingo Molnar Objet : RE: call for more SD versus CFS comparisons (was: Re: [ck] Mainline plans) -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Miguel Figueiredo Envoyé : 11 juin 2007 20:30 Hi all, some results based on massing_intr.c by Satoru, can be found on http://people.redhat.com/mingo/cfs-scheduler/tools/massive_intr.c I know that other people, who read lkml, also tested the same way, it would be nice if they also post their data. For the pleasure of comparing CPU schedulers, both CFS v16 full CK2 patched pre-built kernels for Fedora 7 using latest build 3194 are now available at http://linux-dev.qc.ec.gc.ca There is also a not yet fully tuned YUM repository configuration file available at http://linux-dev.qc.ec.gc.ca/kernel/fedora/alt-sched.repo Although I suggest you download the rpm's directly from the web page install both manually using rpm -ivh --force Have fun. Also, now that I think of it, here are my results: Test: ./massive_intr 20 6000 Hardware: - Athlon 64 4200+ - 2GB ram - nVidia 6600GT using latest Beta driver NVIDIA-Linux-x86_64-100.14.06-pkg2.run - SATA drive - On-board audio (00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio Controller (rev a2)) Kernels: CFS v16 2.6.21 FC7 build 3194 CK2 2.6.21 FC7 build 3194 Here is what the TOP output was looking like for both case: top - 13:36:22 up 38 min, 4 users, load average: 20.41, 13.43, 7.49 Tasks: 172 total, 21 running, 150 sleeping, 0 stopped, 1 zombie Cpu0 : 99.7%us, 0.3%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu1 : 94.7%us, 4.6%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.3%hi, 0.3%si, 0.0%st Mem: 2058860k total, 1217132k used, 841728k free,56456k buffers Swap: 1959888k total,0k used, 1959888k free, 781636k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 6099 megalout 20 0 7860 224 136 R 10 0.0 0:26.12 massive_intr 6102 megalout 20 0 7860 224 136 R 10 0.0 0:26.27 massive_intr 6104 megalout 20 0 7860 224 136 R 10 0.0 0:26.51 massive_intr 6105 megalout 20 0 7860 224 136 R 10 0.0 0:26.32 massive_intr 6107 megalout 20 0 7860 224 136 R 10 0.0 0:26.62 massive_intr 6112 megalout 20 0 7860 224 136 R 10 0.0 0:26.32 massive_intr 6116 megalout 20 0 7860 224 136 R 10 0.0 0:26.26 massive_intr 6109 megalout 20 0 7860 224 136 R 10 0.0 0:26.32 massive_intr 6115 megalout 20 0 7860 224 136 R 10 0.0 0:26.50 massive_intr 6118 megalout 20 0 7860 224 136 R9 0.0 0:26.37 massive_intr 6100 megalout 20 0 7860 224 136 R9 0.0 0:26.51 massive_intr 6103 megalout 20 0 7860 224 136 R9 0.0 0:26.24 massive_intr 6106 megalout 20 0 7860 224 136 R9 0.0 0:26.32 massive_intr 6108 megalout 20 0 7860 224 136 R9 0.0 0:26.32 massive_intr 6110 megalout 20 0 7860 224 136 R9 0.0 0:26.54 massive_intr 6111 megalout 20 0 7860 224 136 R9 0.0 0:26.37 massive_intr 6113 megalout 20 0 7860 224 136 R9 0.0 0:26.56 massive_intr 6114 megalout 20 0 7860 224 136 R9 0.0 0:26.30 massive_intr 6117 megalout 20 0 7860 224 136 R9 0.0 0:26.34 massive_intr 6101 megalout 20 0 7860 224 136 R9 0.0 0:26.31 massive_intr 4681 root 20 0 196m 67m 12m S8 3.4 4:06.00 X 6036 megalout 20 0 694m 53m 32m S2 2.6 0:07.82 amarokapp 4904 megalout 20 0 271m 9.9m 6948 S1 0.5 0:18.16 gkrellm 5054 megalout 20 0 160m 45m 20m S1 2.2 0:10.90 firefox-bin 5201 megalout 20 0 160m 9304 5480 S1 0.5 0:01.42 emerald 5210 megalout 20 0 240m 12m 6284 S1 0.6 0:33.29 beryl CFS v16: - beryl interractivity way too unresponsive.. - window decoration highlight taking around 5-10 secs to switch between windows focus - window movement either impossible or animation laggy enough to not being seen at all. - Cube rotation still possible using mouse scroll although really really really laggy Amarok MP3 music: - No audio skips at all. Playing really well! CK2 patchset: - Beryl interractivity almost totally unresponsive... In fact mouse movement was near-impossible to control. - window movement totally impossible - Cube rotation still possible using mouse scroll although there was no animation at all Amarok MP3 music: - Same as CFS, no skips at all. Playing really well! I'll quote Martin on the Ck mailing list: According to Ingo most of the interactivity issues should be fixed by now. Still I do not see how that translates to CFS
RE: [patch 00/32] 2.6.20-stable review
> -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] De la part de Chris Wright > Envoyé : 8 juin 2007 03:15 > > This is the start of the stable review cycle for the > 2.6.20.14 release. > There are 32 patches in this series, all will be posted as a > response to this one. If anyone has any issues with these > being applied, please let us know. If anyone is a maintainer > of the proper subsystem, and wants to add a Signed-off-by: > line to the patch, please respond with it. > > These patches are sent out with a number of different people on the > Cc: line. If you wish to be a reviewer, please email > [EMAIL PROTECTED] to add your name to the list. If you want > to be off the reviewer list, also email us. > > Responses should be made by Sun Jun 10 07:15 UTC. > Anything received after that time might be too late. Hi Chris, I have encoutered a bug using fixdep when compiling the Apani VPN contivity client v3.3 (v3.5 seems fine). The bug started happening with the release of the 2948 build of FC6 kernel (corresponding to a post 2.6.20.7) and caused fixdep to segfault. This has been fixed in 2.6.21. I tried to trigger the bug using the 2.6.21 patch (thnx to the raw ouput option in git.kernel.org) and it really seems to resolve the problem. The original commit: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.20.y.git;a=commit;h=3dedd29b0ef5c7a36ac835ac5524a6a8e22c22ab The fix: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.21.y.git;a=commit;h=1ea6b2418cd2c6a6f31067ed6ece5cd12c69351e Could it be included in this new stable release of 2.6.20 ? thnx > thanks, > > the -stable release team > -- > - > 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/ > - 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 00/32] 2.6.20-stable review
-Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Chris Wright Envoyé : 8 juin 2007 03:15 This is the start of the stable review cycle for the 2.6.20.14 release. There are 32 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let us know. If anyone is a maintainer of the proper subsystem, and wants to add a Signed-off-by: line to the patch, please respond with it. These patches are sent out with a number of different people on the Cc: line. If you wish to be a reviewer, please email [EMAIL PROTECTED] to add your name to the list. If you want to be off the reviewer list, also email us. Responses should be made by Sun Jun 10 07:15 UTC. Anything received after that time might be too late. Hi Chris, I have encoutered a bug using fixdep when compiling the Apani VPN contivity client v3.3 (v3.5 seems fine). The bug started happening with the release of the 2948 build of FC6 kernel (corresponding to a post 2.6.20.7) and caused fixdep to segfault. This has been fixed in 2.6.21. I tried to trigger the bug using the 2.6.21 patch (thnx to the raw ouput option in git.kernel.org) and it really seems to resolve the problem. The original commit: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.20.y.git;a=commit;h=3dedd29b0ef5c7a36ac835ac5524a6a8e22c22ab The fix: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.21.y.git;a=commit;h=1ea6b2418cd2c6a6f31067ed6ece5cd12c69351e Could it be included in this new stable release of 2.6.20 ? thnx thanks, the -stable release team -- - 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/ - 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: [stable] [patch 00/69] -stable review
> -Message d'origine- > De : Greg KH [mailto:[EMAIL PROTECTED] > Envoyé : 22 mai 2007 23:37 > À : Fortier,Vincent [Montreal] > > On Tue, May 22, 2007 at 09:28:34PM -0400, Fortier,Vincent > [Montreal] wrote: > > > -Message d'origine- > > > De : [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] De la part de Chuck > > > Ebbert Envoy? : 21 mai 2007 18:24 > > > > > > Adrian Bunk wrote: > > > > On Mon, May 21, 2007 at 12:31:48PM -0700, Andrew Morton wrote: > > > >> On Mon, 21 May 2007 12:16:12 -0700 Chris Wright > > > >> <[EMAIL PROTECTED]> wrote: > > > >> > > > >>> This is the start of the stable review cycle for the 2.6.21.2 release. > > > >> Gee a lot of these are fixing recently-added regressions :( ... > > > > > > > > If only it would fix all of them... > > > > > > > > Michal's list [1] currently contains 51 different regressions in > > > > 2.6.21 compared to 2.6.20 (12 of them were already reported before > > > > 2.6.21 was released). > > > > > > Yeah, 2.6.21 seems awfully buggy, and patches to fix many of the > > > bugs haven't appeared. > > > > > > Another 2.6.20 update seems to be in order... > > > > Hi, > > > > If there is a new stable 2.6.20 / 2.6.21, would it be > possible that they both contain also this patch to keep the > same behaviour between 2.6.20 -> 2.6.22 kernels regarding > paravirt_ops GPL export? > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=com > > mit;h=21564fd2a3deb48200b595332f9ed4c9f311f2a7 > > Why? Is there an in-kernel use for that export? I sincerely dont know... Although: - * NOTE: CONFIG_PARAVIRT is experimental and the paravirt_ops - * semantics are subject to change. Hence we only do this - * internal-only export of this, until it gets sorted out and - * all lowlevel CPU ops used by modules are separately exported. Makes me think there was a "good enough" reason to export instead of export GPL and that it "could" be usefull to keep the same behaviour for that same experimental feature under 2.6.20 / 2.6.21. Although, the "until it gets sorted out" makes me think it might planned to get removed before the end of 2.6.22 Thnx. - vin - 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: [stable] [patch 00/69] -stable review
-Message d'origine- De : Greg KH [mailto:[EMAIL PROTECTED] Envoyé : 22 mai 2007 23:37 À : Fortier,Vincent [Montreal] On Tue, May 22, 2007 at 09:28:34PM -0400, Fortier,Vincent [Montreal] wrote: -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Chuck Ebbert Envoy? : 21 mai 2007 18:24 Adrian Bunk wrote: On Mon, May 21, 2007 at 12:31:48PM -0700, Andrew Morton wrote: On Mon, 21 May 2007 12:16:12 -0700 Chris Wright [EMAIL PROTECTED] wrote: This is the start of the stable review cycle for the 2.6.21.2 release. Gee a lot of these are fixing recently-added regressions :( ... If only it would fix all of them... Michal's list [1] currently contains 51 different regressions in 2.6.21 compared to 2.6.20 (12 of them were already reported before 2.6.21 was released). Yeah, 2.6.21 seems awfully buggy, and patches to fix many of the bugs haven't appeared. Another 2.6.20 update seems to be in order... Hi, If there is a new stable 2.6.20 / 2.6.21, would it be possible that they both contain also this patch to keep the same behaviour between 2.6.20 - 2.6.22 kernels regarding paravirt_ops GPL export? http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=com mit;h=21564fd2a3deb48200b595332f9ed4c9f311f2a7 Why? Is there an in-kernel use for that export? I sincerely dont know... Although: - * NOTE: CONFIG_PARAVIRT is experimental and the paravirt_ops - * semantics are subject to change. Hence we only do this - * internal-only export of this, until it gets sorted out and - * all lowlevel CPU ops used by modules are separately exported. Makes me think there was a good enough reason to export instead of export GPL and that it could be usefull to keep the same behaviour for that same experimental feature under 2.6.20 / 2.6.21. Although, the until it gets sorted out makes me think it might planned to get removed before the end of 2.6.22 Thnx. - vin - 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 00/69] -stable review
> -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] De la part de Chuck Ebbert > Envoyé : 21 mai 2007 18:24 > > Adrian Bunk wrote: > > On Mon, May 21, 2007 at 12:31:48PM -0700, Andrew Morton wrote: > >> On Mon, 21 May 2007 12:16:12 -0700 > >> Chris Wright <[EMAIL PROTECTED]> wrote: > >> > >>> This is the start of the stable review cycle for the 2.6.21.2 release. > >> Gee a lot of these are fixing recently-added regressions :( ... > > > > If only it would fix all of them... > > > > Michal's list [1] currently contains 51 different regressions in > > 2.6.21 compared to 2.6.20 (12 of them were already reported before > > 2.6.21 was released). > > Yeah, 2.6.21 seems awfully buggy, and patches to fix many of > the bugs haven't appeared. > > Another 2.6.20 update seems to be in order... Hi, If there is a new stable 2.6.20 / 2.6.21, would it be possible that they both contain also this patch to keep the same behaviour between 2.6.20 -> 2.6.22 kernels regarding paravirt_ops GPL export? http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=21564fd2a3deb48200b595332f9ed4c9f311f2a7 Thnx! - vin - 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 00/69] -stable review
-Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Chuck Ebbert Envoyé : 21 mai 2007 18:24 Adrian Bunk wrote: On Mon, May 21, 2007 at 12:31:48PM -0700, Andrew Morton wrote: On Mon, 21 May 2007 12:16:12 -0700 Chris Wright [EMAIL PROTECTED] wrote: This is the start of the stable review cycle for the 2.6.21.2 release. Gee a lot of these are fixing recently-added regressions :( ... If only it would fix all of them... Michal's list [1] currently contains 51 different regressions in 2.6.21 compared to 2.6.20 (12 of them were already reported before 2.6.21 was released). Yeah, 2.6.21 seems awfully buggy, and patches to fix many of the bugs haven't appeared. Another 2.6.20 update seems to be in order... Hi, If there is a new stable 2.6.20 / 2.6.21, would it be possible that they both contain also this patch to keep the same behaviour between 2.6.20 - 2.6.22 kernels regarding paravirt_ops GPL export? http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=21564fd2a3deb48200b595332f9ed4c9f311f2a7 Thnx! - vin - 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] CFS scheduler, -v10
> -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] De la part de Ingo Molnar > Envoyé : 7 mai 2007 12:34 > > > i'm pleased to announce release -v10 of the CFS scheduler patchset. > (The main goal of CFS is to implement "desktop scheduling" > with as high quality as technically possible.) > > The CFS patch against v2.6.21.1 (or against v2.6.20.10) can > be downloaded from the usual place: > > http://people.redhat.com/mingo/cfs-scheduler/ > > -v10 got a bit bigger than usual. One reason for that is that > i couldnt resist the fine enhancements contributed by Peter > Williams and Mike Galbraith. Peter fixed and improved nice > level support and SMP load-balancing, while Mike applied his > "no compromises" interactivity tuning skills to CFS: > > 6 files changed, 247 insertions(+), 110 deletions(-) CFS v10 & SD 0.48 Fedora Core 6 kernels 2.6.20 build 2948 arch x86_64 & i686 are available at http://linux-dev.qc.ec.gc.ca. > Ingo - vin - 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] CFS scheduler, -v10
-Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Ingo Molnar Envoyé : 7 mai 2007 12:34 i'm pleased to announce release -v10 of the CFS scheduler patchset. (The main goal of CFS is to implement desktop scheduling with as high quality as technically possible.) The CFS patch against v2.6.21.1 (or against v2.6.20.10) can be downloaded from the usual place: http://people.redhat.com/mingo/cfs-scheduler/ -v10 got a bit bigger than usual. One reason for that is that i couldnt resist the fine enhancements contributed by Peter Williams and Mike Galbraith. Peter fixed and improved nice level support and SMP load-balancing, while Mike applied his no compromises interactivity tuning skills to CFS: 6 files changed, 247 insertions(+), 110 deletions(-) CFS v10 SD 0.48 Fedora Core 6 kernels 2.6.20 build 2948 arch x86_64 i686 are available at http://linux-dev.qc.ec.gc.ca. Ingo - vin - 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: [ck] Staircase Deadline cpu scheduler version 0.48 - 2.6.18 to 2.6.20 backports patches
> -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] De la part de Con Kolivas > Envoyé : 3 mai 2007 02:30 > > I've done some minor cleanups and microoptimisations to the > code since version > 0.46 in preparation for releasing -ck with SD as its base. > > http://www.kernel.org/pub/linux/kernel/people/ck/patches/stair > case-deadline/2.6.21/2.6.21-sd-0.48.patch Hi all, I made backport patches of SD 0.48 for 2.6.18.8, 2.6.19.7 & 2.6.20.11 kernels and also diff patches 0.46 -> 0.47 -> 0.48. All info & download available at http://linux-dev.qc.ec.gc.ca There are also various versions of SD & CFS kernels for FC6 & Debian Sarge/Etch > -- > -ck - vin - 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: [ck] Staircase Deadline cpu scheduler version 0.48 - 2.6.18 to 2.6.20 backports patches
-Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Con Kolivas Envoyé : 3 mai 2007 02:30 I've done some minor cleanups and microoptimisations to the code since version 0.46 in preparation for releasing -ck with SD as its base. http://www.kernel.org/pub/linux/kernel/people/ck/patches/stair case-deadline/2.6.21/2.6.21-sd-0.48.patch Hi all, I made backport patches of SD 0.48 for 2.6.18.8, 2.6.19.7 2.6.20.11 kernels and also diff patches 0.46 - 0.47 - 0.48. All info download available at http://linux-dev.qc.ec.gc.ca There are also various versions of SD CFS kernels for FC6 Debian Sarge/Etch -- -ck - vin - 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: [ck] [ANNOUNCE] Staircase Deadline cpu scheduler version 0.44
> -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] De la part de Con Kolivas > Envoyé : 21 avril 2007 03:57 > > A significant bugfix for forking tasks was just posted, so > here is an updated version of the staircase deadline cpu > scheduler. This may cause noticeable behavioural improvements > under certain workloads (such as compiling software with make). > > Thanks to Al Boldi for making me check the fork code! > > http://ck.kolivas.org/patches/staircase-deadline/2.6.20.7-sd-0.44.patch > http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc7-sd-0.44.patch > > Incrementals in > http://ck.kolivas.org/patches/staircase-deadline/2.6.20.7/ > http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc7/ > > Renicing X to -10, while not essential, is preferable. > > See the patch just posted called 'sched: implement staircase > scheduler yaf fix' for full changelog. Kernels for FC6 x86_64 & i686 using SD 0.44 and latest source (2944) now available at http://linux-dev.qc.ec.gc.ca Note that backport patches for 2.6.18 & 2.6.19 kernels are also available. > > -- > -ck > Again, nice work CK! -vin - 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: [ck] [ANNOUNCE] Staircase Deadline cpu scheduler version 0.44
-Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Con Kolivas Envoyé : 21 avril 2007 03:57 A significant bugfix for forking tasks was just posted, so here is an updated version of the staircase deadline cpu scheduler. This may cause noticeable behavioural improvements under certain workloads (such as compiling software with make). Thanks to Al Boldi for making me check the fork code! http://ck.kolivas.org/patches/staircase-deadline/2.6.20.7-sd-0.44.patch http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc7-sd-0.44.patch Incrementals in http://ck.kolivas.org/patches/staircase-deadline/2.6.20.7/ http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc7/ Renicing X to -10, while not essential, is preferable. See the patch just posted called 'sched: implement staircase scheduler yaf fix' for full changelog. Kernels for FC6 x86_64 i686 using SD 0.44 and latest source (2944) now available at http://linux-dev.qc.ec.gc.ca Note that backport patches for 2.6.18 2.6.19 kernels are also available. -- -ck Again, nice work CK! -vin - 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: 4GB Physical. Less than 3GB in Linux.
> > I've noticed that with 4GB physical ram, I'm only see 3098000 > MB on the Dell 745, and 3107056MB on the IBM X60s. > > I've tested with CONFIG_HIGHMEM4G=y, CONFIG_HIGHMEM64G=y, > CONFIG_X86_PAE=y, but nothing makes any difference. > > Tested on Linux 2.6.20, Linux 2.6.21-rc7. Got similar problem on a HP XW6200: http://bugzilla.kernel.org/show_bug.cgi?id=7111 Tought I was the only one getting this! > # dmesg > copy_e820_map() start: size: 0009f000 end: > 0009f000 type: 1 > copy_e820_map() type is E820_RAM > copy_e820_map() start: 0009f000 size: 1000 end: > 000a type: 2 > copy_e820_map() start: 000dc000 size: 00024000 end: > 0010 type: 2 > copy_e820_map() start: 0010 size: bf5d end: > bf6d type: 1 > copy_e820_map() type is E820_RAM > copy_e820_map() start: bf6d size: f000 end: > bf6df000 type: 3 > copy_e820_map() start: bf6df000 size: 00021000 end: > bf70 type: 4 > copy_e820_map() start: bf70 size: 0090 end: > c000 type: 2 > copy_e820_map() start: f000 size: 0400 end: > f400 type: 2 > copy_e820_map() start: fec0 size: 0001 end: > fec1 type: 2 > copy_e820_map() start: fed0 size: 0400 end: > fed00400 type: 2 > copy_e820_map() start: fed14000 size: 6000 end: > fed1a000 type: 2 > copy_e820_map() start: fed1c000 size: 00074000 end: > fed9 type: 2 > copy_e820_map() start: fee0 size: 1000 end: > fee01000 type: 2 > copy_e820_map() start: ff80 size: 0080 end: > 0001 type: 2 > BIOS-e820: - 0009f000 (usable) > BIOS-e820: 0009f000 - 000a (reserved) > BIOS-e820: 000dc000 - 0010 (reserved) > BIOS-e820: 0010 - bf6d (usable) > BIOS-e820: bf6d - bf6df000 (ACPI data) > BIOS-e820: bf6df000 - bf70 (ACPI NVS) > BIOS-e820: bf70 - c000 (reserved) > BIOS-e820: f000 - f400 (reserved) > BIOS-e820: fec0 - fec1 (reserved) > BIOS-e820: fed0 - fed00400 (reserved) > BIOS-e820: fed14000 - fed1a000 (reserved) > BIOS-e820: fed1c000 - fed9 (reserved) > BIOS-e820: fee0 - fee01000 (reserved) > BIOS-e820: ff80 - 0001 (reserved) > 2166MB HIGHMEM available. > 896MB LOWMEM available. > > Memory: 3106140k/3136320k available (2225k kernel code, > 29072k reserved, 910k data, 196k init, 2218816k highmem) > virtual kernel memory layout: > fixmap : 0xfff5 - 0xf000 ( 700 kB) > pkmap : 0xff80 - 0xffc0 (4096 kB) > vmalloc : 0xf880 - 0xff7fe000 ( 111 MB) > lowmem : 0xc000 - 0xf800 ( 896 MB) > .init : 0xc0416000 - 0xc0447000 ( 196 kB) > .data : 0xc032c513 - 0xc040ff34 ( 910 kB) > .text : 0xc010 - 0xc032c513 (2225 kB) > > > Thanks, > Jeff. - vin - 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: 4GB Physical. Less than 3GB in Linux.
I've noticed that with 4GB physical ram, I'm only see 3098000 MB on the Dell 745, and 3107056MB on the IBM X60s. I've tested with CONFIG_HIGHMEM4G=y, CONFIG_HIGHMEM64G=y, CONFIG_X86_PAE=y, but nothing makes any difference. Tested on Linux 2.6.20, Linux 2.6.21-rc7. Got similar problem on a HP XW6200: http://bugzilla.kernel.org/show_bug.cgi?id=7111 Tought I was the only one getting this! # dmesg copy_e820_map() start: size: 0009f000 end: 0009f000 type: 1 copy_e820_map() type is E820_RAM copy_e820_map() start: 0009f000 size: 1000 end: 000a type: 2 copy_e820_map() start: 000dc000 size: 00024000 end: 0010 type: 2 copy_e820_map() start: 0010 size: bf5d end: bf6d type: 1 copy_e820_map() type is E820_RAM copy_e820_map() start: bf6d size: f000 end: bf6df000 type: 3 copy_e820_map() start: bf6df000 size: 00021000 end: bf70 type: 4 copy_e820_map() start: bf70 size: 0090 end: c000 type: 2 copy_e820_map() start: f000 size: 0400 end: f400 type: 2 copy_e820_map() start: fec0 size: 0001 end: fec1 type: 2 copy_e820_map() start: fed0 size: 0400 end: fed00400 type: 2 copy_e820_map() start: fed14000 size: 6000 end: fed1a000 type: 2 copy_e820_map() start: fed1c000 size: 00074000 end: fed9 type: 2 copy_e820_map() start: fee0 size: 1000 end: fee01000 type: 2 copy_e820_map() start: ff80 size: 0080 end: 0001 type: 2 BIOS-e820: - 0009f000 (usable) BIOS-e820: 0009f000 - 000a (reserved) BIOS-e820: 000dc000 - 0010 (reserved) BIOS-e820: 0010 - bf6d (usable) BIOS-e820: bf6d - bf6df000 (ACPI data) BIOS-e820: bf6df000 - bf70 (ACPI NVS) BIOS-e820: bf70 - c000 (reserved) BIOS-e820: f000 - f400 (reserved) BIOS-e820: fec0 - fec1 (reserved) BIOS-e820: fed0 - fed00400 (reserved) BIOS-e820: fed14000 - fed1a000 (reserved) BIOS-e820: fed1c000 - fed9 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: ff80 - 0001 (reserved) 2166MB HIGHMEM available. 896MB LOWMEM available. Memory: 3106140k/3136320k available (2225k kernel code, 29072k reserved, 910k data, 196k init, 2218816k highmem) virtual kernel memory layout: fixmap : 0xfff5 - 0xf000 ( 700 kB) pkmap : 0xff80 - 0xffc0 (4096 kB) vmalloc : 0xf880 - 0xff7fe000 ( 111 MB) lowmem : 0xc000 - 0xf800 ( 896 MB) .init : 0xc0416000 - 0xc0447000 ( 196 kB) .data : 0xc032c513 - 0xc040ff34 ( 910 kB) .text : 0xc010 - 0xc032c513 (2225 kB) Thanks, Jeff. - vin - 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/
Questions regarding ACPI vs FADT dump on HP XW6200 using 2.6.16 - 2.6.20 kernels?
Hi all, In reference to this Bugzilla entry: http://bugzilla.kernel.org/show_bug.cgi?id=7110 I'm getting ACPI errors in the dmesg: [7.443482] ACPI Error (evgpe-0711): No handler or method for GPE[ 0], disabling event [20060707] [7.449881] ACPI Error (evgpe-0711): No handler or method for GPE[ 1], disabling event [20060707] [7.456145] ACPI Error (evgpe-0711): No handler or method for GPE[ 2], disabling event [20060707] [7.462271] ACPI Error (evgpe-0711): No handler or method for GPE[ 5], disabling event [20060707] [7.468310] ACPI Error (evgpe-0711): No handler or method for GPE[ 6], disabling event [20060707] [7.474260] ACPI Error (evgpe-0711): No handler or method for GPE[ 7], disabling event [20060707] [7.480124] ACPI Error (evgpe-0711): No handler or method for GPE[ 9], disabling event [20060707] [7.485893] ACPI Error (evgpe-0711): No handler or method for GPE[ A], disabling event [20060707] [7.491473] ACPI Error (evgpe-0711): No handler or method for GPE[ F], disabling event [20060707] [7.491484] ACPI Error (evgpe-0711): No handler or method for GPE[10], disabling event [20060707] [7.491489] ACPI Error (evgpe-0711): No handler or method for GPE[11], disabling event [20060707] [7.491494] ACPI Error (evgpe-0711): No handler or method for GPE[12], disabling event [20060707] [7.491499] ACPI Error (evgpe-0711): No handler or method for GPE[13], disabling event [20060707] [7.491504] ACPI Error (evgpe-0711): No handler or method for GPE[14], disabling event [20060707] [7.491509] ACPI Error (evgpe-0711): No handler or method for GPE[15], disabling event [20060707] [7.491514] ACPI Error (evgpe-0711): No handler or method for GPE[16], disabling event [20060707] [7.491519] ACPI Error (evgpe-0711): No handler or method for GPE[17], disabling event [20060707] [7.491527] ACPI Error (evgpe-0711): No handler or method for GPE[19], disabling event [20060707] [7.491532] ACPI Error (evgpe-0711): No handler or method for GPE[1A], disabling event [20060707] [7.491537] ACPI Error (evgpe-0711): No handler or method for GPE[1B], disabling event [20060707] [7.491542] ACPI Error (evgpe-0711): No handler or method for GPE[1C], disabling event [20060707] [7.491547] ACPI Error (evgpe-0711): No handler or method for GPE[1D], disabling event [20060707] [7.491552] ACPI Error (evgpe-0711): No handler or method for GPE[1E], disabling event [20060707] [7.491557] ACPI Error (evgpe-0711): No handler or method for GPE[1F], disabling event [20060707] The ACPI: FADT dmesg entry is: [0.00] ACPI: RSDP (v002 COMPAQ) @ 0x000e8e10 [0.00] ACPI: XSDT (v001 COMPAQ CPQ0063 0x20051222 0x) @ 0xbfff50ec [0.00] ACPI: FADT (v003 COMPAQ TUMWATER 0x0001 0x) @ 0xbfff52ac [0.00] ACPI: SSDT (v001 COMPAQ PROJECT 0x0001 MSFT 0x010e) @ 0xbfff657a [0.00] ACPI: MADT (v001 COMPAQ TUMWATER 0x0001 0x) @ 0xbfff53b8 [0.00] ACPI: ASF! (v032 COMPAQ TUMWATER 0x0001 0x) @ 0xbfff543c [0.00] ACPI: MCFG (v001 COMPAQ TUMWATER 0x0001 0x) @ 0xbfff54a6 [0.00] ACPI: DSDT (v001 COMPAQ DSDT 0x0001 MSFT 0x010e) @ 0x I've been told to use this command to dump this memory segment: dd if=/dev/mem skip=$[0xbfff52ac] bs=1c count=244 2> /dev/null > fadt.bin But I'm always getting an empty file? My questions are: 1) How can I dump the FADT ? 2) Could this be related to this memory detection bug http://bugzilla.kernel.org/show_bug.cgi?id=7111 ? Thnx! - vin - 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/
Questions regarding ACPI vs FADT dump on HP XW6200 using 2.6.16 - 2.6.20 kernels?
Hi all, In reference to this Bugzilla entry: http://bugzilla.kernel.org/show_bug.cgi?id=7110 I'm getting ACPI errors in the dmesg: [7.443482] ACPI Error (evgpe-0711): No handler or method for GPE[ 0], disabling event [20060707] [7.449881] ACPI Error (evgpe-0711): No handler or method for GPE[ 1], disabling event [20060707] [7.456145] ACPI Error (evgpe-0711): No handler or method for GPE[ 2], disabling event [20060707] [7.462271] ACPI Error (evgpe-0711): No handler or method for GPE[ 5], disabling event [20060707] [7.468310] ACPI Error (evgpe-0711): No handler or method for GPE[ 6], disabling event [20060707] [7.474260] ACPI Error (evgpe-0711): No handler or method for GPE[ 7], disabling event [20060707] [7.480124] ACPI Error (evgpe-0711): No handler or method for GPE[ 9], disabling event [20060707] [7.485893] ACPI Error (evgpe-0711): No handler or method for GPE[ A], disabling event [20060707] [7.491473] ACPI Error (evgpe-0711): No handler or method for GPE[ F], disabling event [20060707] [7.491484] ACPI Error (evgpe-0711): No handler or method for GPE[10], disabling event [20060707] [7.491489] ACPI Error (evgpe-0711): No handler or method for GPE[11], disabling event [20060707] [7.491494] ACPI Error (evgpe-0711): No handler or method for GPE[12], disabling event [20060707] [7.491499] ACPI Error (evgpe-0711): No handler or method for GPE[13], disabling event [20060707] [7.491504] ACPI Error (evgpe-0711): No handler or method for GPE[14], disabling event [20060707] [7.491509] ACPI Error (evgpe-0711): No handler or method for GPE[15], disabling event [20060707] [7.491514] ACPI Error (evgpe-0711): No handler or method for GPE[16], disabling event [20060707] [7.491519] ACPI Error (evgpe-0711): No handler or method for GPE[17], disabling event [20060707] [7.491527] ACPI Error (evgpe-0711): No handler or method for GPE[19], disabling event [20060707] [7.491532] ACPI Error (evgpe-0711): No handler or method for GPE[1A], disabling event [20060707] [7.491537] ACPI Error (evgpe-0711): No handler or method for GPE[1B], disabling event [20060707] [7.491542] ACPI Error (evgpe-0711): No handler or method for GPE[1C], disabling event [20060707] [7.491547] ACPI Error (evgpe-0711): No handler or method for GPE[1D], disabling event [20060707] [7.491552] ACPI Error (evgpe-0711): No handler or method for GPE[1E], disabling event [20060707] [7.491557] ACPI Error (evgpe-0711): No handler or method for GPE[1F], disabling event [20060707] The ACPI: FADT dmesg entry is: [0.00] ACPI: RSDP (v002 COMPAQ) @ 0x000e8e10 [0.00] ACPI: XSDT (v001 COMPAQ CPQ0063 0x20051222 0x) @ 0xbfff50ec [0.00] ACPI: FADT (v003 COMPAQ TUMWATER 0x0001 0x) @ 0xbfff52ac [0.00] ACPI: SSDT (v001 COMPAQ PROJECT 0x0001 MSFT 0x010e) @ 0xbfff657a [0.00] ACPI: MADT (v001 COMPAQ TUMWATER 0x0001 0x) @ 0xbfff53b8 [0.00] ACPI: ASF! (v032 COMPAQ TUMWATER 0x0001 0x) @ 0xbfff543c [0.00] ACPI: MCFG (v001 COMPAQ TUMWATER 0x0001 0x) @ 0xbfff54a6 [0.00] ACPI: DSDT (v001 COMPAQ DSDT 0x0001 MSFT 0x010e) @ 0x I've been told to use this command to dump this memory segment: dd if=/dev/mem skip=$[0xbfff52ac] bs=1c count=244 2 /dev/null fadt.bin But I'm always getting an empty file? My questions are: 1) How can I dump the FADT ? 2) Could this be related to this memory detection bug http://bugzilla.kernel.org/show_bug.cgi?id=7111 ? Thnx! - vin - 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/
staircase deadline 0.37 backport 2.6.18.8 and 2.6.19.7 & debian sarge/etch kernel availability
Hi all, Backports of the staircase deadline cpu scheduler version 0.37 for 2.6.18.8 and 2.6.19.7 kernels are available at http://linux-dev.qc.ec.gc.ca/. Also, Debian Etch 4.0 and Sarge 3.1 kernels for i686 are available (Deb etch amd64 is currently compiling and FC6 will follow). Vincent Fortier Informatique Environnement Canada - 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/
staircase deadline 0.37 backport 2.6.18.8 and 2.6.19.7 debian sarge/etch kernel availability
Hi all, Backports of the staircase deadline cpu scheduler version 0.37 for 2.6.18.8 and 2.6.19.7 kernels are available at http://linux-dev.qc.ec.gc.ca/. Also, Debian Etch 4.0 and Sarge 3.1 kernels for i686 are available (Deb etch amd64 is currently compiling and FC6 will follow). Vincent Fortier Informatique Environnement Canada - 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/
staircase deadline 0.36 backport 2.6.18.8 and 2.6.19.7
Hi all, Backports of the staircase deadline cpu scheduler for 2.6.18.8 and 2.6.19.7 kernels are available at http://linux-dev.qc.ec.gc.ca/. Also, Debian Etch 4.0 kernels for both i686 and x86_64 are available. Fedora Core 6 kernels might also be available later today/tomorrow. Both patches looks quite stable. I've been able to fix the 2.6.19 backport by reversing this patch: "[PATCH] move_task_off_dead_cpu() should be called with disabled ints" (see http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.20.y.git;a=co mmit;h=054b9108e01ef27e2e6b32b4226abb6024626f06). I don't know if this bug (see http://linux-dev.qc.ec.gc.ca/kernel/debian/etch/x86_64/2.6.19/bug-2.6.19 .7-rsdl-033.jpg) can also affect a Vanilla 2.6.19.7 kernel or even the actual mainline? Duno if it would be worth investigating a bit further? Although, here is a top of a 2.6.19.7 + SD 0.36 patch in action while building 3 kernels at once and running a glxgears in foreground: top - 12:39:39 up 17 min, 2 users, load average: 5.84, 4.37, 2.20 Tasks: 162 total, 5 running, 157 sleeping, 0 stopped, 0 zombie Cpu0 : 87.0%us, 13.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu1 : 88.4%us, 11.6%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 2059940k total, 1249476k used, 810464k free, 137112k buffers Swap: 1959888k total,0k used, 1959888k free, 620552k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 15970 root 33 0 45016 36m 4520 R 18 1.8 0:00.54 cc1 16025 root 1 0 40904 32m R 18 1.6 0:00.53 cc1 16015 root 33 0 40620 32m 4496 R 17 1.6 0:00.52 cc1 13401 th0ma7 1 0 42356 9420 6700 R6 0.5 1:16.13 glxgears 16589 root 1 0 3756 400 192 S1 0.0 0:01.04 faked-sysv 5012 root 5 0 91208 46m 7200 S0 2.3 0:11.57 Xorg Note that my KDE session/firefox/kontact/etc. was still pretty responsive! Vincent Fortier Informatique Environnement Canada - 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/
staircase deadline 0.36 backport 2.6.18.8 and 2.6.19.7
Hi all, Backports of the staircase deadline cpu scheduler for 2.6.18.8 and 2.6.19.7 kernels are available at http://linux-dev.qc.ec.gc.ca/. Also, Debian Etch 4.0 kernels for both i686 and x86_64 are available. Fedora Core 6 kernels might also be available later today/tomorrow. Both patches looks quite stable. I've been able to fix the 2.6.19 backport by reversing this patch: [PATCH] move_task_off_dead_cpu() should be called with disabled ints (see http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.20.y.git;a=co mmit;h=054b9108e01ef27e2e6b32b4226abb6024626f06). I don't know if this bug (see http://linux-dev.qc.ec.gc.ca/kernel/debian/etch/x86_64/2.6.19/bug-2.6.19 .7-rsdl-033.jpg) can also affect a Vanilla 2.6.19.7 kernel or even the actual mainline? Duno if it would be worth investigating a bit further? Although, here is a top of a 2.6.19.7 + SD 0.36 patch in action while building 3 kernels at once and running a glxgears in foreground: top - 12:39:39 up 17 min, 2 users, load average: 5.84, 4.37, 2.20 Tasks: 162 total, 5 running, 157 sleeping, 0 stopped, 0 zombie Cpu0 : 87.0%us, 13.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu1 : 88.4%us, 11.6%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 2059940k total, 1249476k used, 810464k free, 137112k buffers Swap: 1959888k total,0k used, 1959888k free, 620552k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 15970 root 33 0 45016 36m 4520 R 18 1.8 0:00.54 cc1 16025 root 1 0 40904 32m R 18 1.6 0:00.53 cc1 16015 root 33 0 40620 32m 4496 R 17 1.6 0:00.52 cc1 13401 th0ma7 1 0 42356 9420 6700 R6 0.5 1:16.13 glxgears 16589 root 1 0 3756 400 192 S1 0.0 0:01.04 faked-sysv 5012 root 5 0 91208 46m 7200 S0 2.3 0:11.57 Xorg Note that my KDE session/firefox/kontact/etc. was still pretty responsive! Vincent Fortier Informatique Environnement Canada - 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/
rsdl 0.33 backport to 2.6.18.8 available & pre-built DebianEtch and Fedora 6 kernels
Hi all, A backported version of the RSDL 0.33 patch is now available at http://linux-dev.qc.ec.gc.ca for a 2.6.18.8 kernel. There are also a few 2.6.18/2.6.20 pre-built kernels available for both Debian Etch (x86_64) and Fedora 6 (x86_64, i686 will follow). Vincent Fortier Informatique Environnement Canada - 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.21-rc4-mm1
> > Andy Whitcroft wrote: > > Con Kolivas wrote: > >> On Friday 23 March 2007 05:17, Andy Whitcroft wrote: > >>> Ok, I have yet a third x86_64 machine is is blowing up with the > >>> latest > >>> 2.6.21-rc4-mm1+hotfixes+rsdl-0.32 but working with > >>> 2.6.21-rc4-mm1+hotfixes-RSDL. I have results on various hotfix > >>> levels so I have just fired off a set of tests across the affected > >>> machines on that latest hotfix stack plus the RSDL backout and the > >>> results should be in in the next hour or two. > >>> > >>> I think there is a strong correlation between RSDL and these hangs. > >>> Any suggestions as to the next step. > >> Found a nasty in requeue_task > >> + if (list_empty(old_array->queue + old_prio)) > >> + __clear_bit(old_prio, p->array->prio_bitmap); > >> > >> see anything wrong there? I do :P > >> > >> I'll queue that up with the other changes pending and hopefully that > >> will fix your bug. > > > > Tests queued with your rdsl-0.33 patch (I am assuming its in there). > > Will let you know how it looks. > > Hmmm, this is good for the original machine (as was 0.32) but > not for either of the other two. I am seeing panics as below > on those two. > > -apw > I don't know if this might help out or even if it is related but I get a "similar" crash every time using my backported rsdl patch on a 2.6.19.7 kernel. "Maybie" this type of BUG might be easier to trigger under that specific kernel? Here is a picture of the output: http://linux-dev.qc.ec.gc.ca/kernel/debian/etch/x86_64/2.6.19/bug-2.6.19 .7-rsdl-033.jpg. - vin - 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.21-rc4-mm1
Andy Whitcroft wrote: Con Kolivas wrote: On Friday 23 March 2007 05:17, Andy Whitcroft wrote: Ok, I have yet a third x86_64 machine is is blowing up with the latest 2.6.21-rc4-mm1+hotfixes+rsdl-0.32 but working with 2.6.21-rc4-mm1+hotfixes-RSDL. I have results on various hotfix levels so I have just fired off a set of tests across the affected machines on that latest hotfix stack plus the RSDL backout and the results should be in in the next hour or two. I think there is a strong correlation between RSDL and these hangs. Any suggestions as to the next step. Found a nasty in requeue_task + if (list_empty(old_array-queue + old_prio)) + __clear_bit(old_prio, p-array-prio_bitmap); see anything wrong there? I do :P I'll queue that up with the other changes pending and hopefully that will fix your bug. Tests queued with your rdsl-0.33 patch (I am assuming its in there). Will let you know how it looks. Hmmm, this is good for the original machine (as was 0.32) but not for either of the other two. I am seeing panics as below on those two. -apw I don't know if this might help out or even if it is related but I get a similar crash every time using my backported rsdl patch on a 2.6.19.7 kernel. Maybie this type of BUG might be easier to trigger under that specific kernel? Here is a picture of the output: http://linux-dev.qc.ec.gc.ca/kernel/debian/etch/x86_64/2.6.19/bug-2.6.19 .7-rsdl-033.jpg. - vin - 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/
rsdl 0.33 backport to 2.6.18.8 available pre-built DebianEtch and Fedora 6 kernels
Hi all, A backported version of the RSDL 0.33 patch is now available at http://linux-dev.qc.ec.gc.ca for a 2.6.18.8 kernel. There are also a few 2.6.18/2.6.20 pre-built kernels available for both Debian Etch (x86_64) and Fedora 6 (x86_64, i686 will follow). Vincent Fortier Informatique Environnement Canada - 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/
rsdl 0.32 backport to 2.6.18.8 available & pre-built Debian Etch and Fedora 6 kernels
Hi all, A backported version of the RSDL 0.32 patch is now available at http://linux-dev.qc.ec.gc.ca for a 2.6.18.8 kernel. There are also a few 2.6.18/2.6.20 pre-built kernels available for both Debian Etch (x86_64) and Fedora 6 (x86_64). Vincent Fortier Informatique Environnement Canada - 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/
rsdl 0.32 backport to 2.6.18.8 available pre-built Debian Etch and Fedora 6 kernels
Hi all, A backported version of the RSDL 0.32 patch is now available at http://linux-dev.qc.ec.gc.ca for a 2.6.18.8 kernel. There are also a few 2.6.18/2.6.20 pre-built kernels available for both Debian Etch (x86_64) and Fedora 6 (x86_64). Vincent Fortier Informatique Environnement Canada - 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: [ck] Re: RSDL v0.30 cpu scheduler for ... 2.6.18.8 kernel
> On Monday 12 March 2007 22:21, Michael Gerdau wrote: > > > > And here are the backported RSDL 0.30 patches in case any of you > > > > would still be running an older 2.6.18.8 kernel ... > > > > The original mail doesn't seem to have made it to the ck-list. > > > > Where would I find the backported RSDL 0.30 patches for 2.6.18.8 ? > > It might have been filtered due to containing attachments, or > because the author wasn't a member of the mailing list, sorry. > I've found a place to put theses patches to: http://linux-dev.qc.ec.gc.ca/kernel/rsdl/2.6.18.8-rsdl-0.30.patch http://linux-dev.qc.ec.gc.ca/kernel/rsdl/2.6.18.8-rsdl-0.29-0.30.patch There is also a Debian Etch x86_64 2.6.18-rsdl-0.30 kernel available at: http://linux-dev.qc.ec.gc.ca/kernel/debian/etch/x86_64/linux-headers-2.6 .18.8-rsdl-0.30-amd64-envcan_2.6.18.8-rsdl-0.30-003_amd64.deb http://linux-dev.qc.ec.gc.ca/kernel/debian/etch/x86_64/linux-image-2.6.1 8.8-rsdl-0.30-amd64-envcan_2.6.18.8-rsdl-0.30-003_amd64.deb Hope this helps! -vin - 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: RSDL v0.30 cpu scheduler for ... 2.6.18.8 kernel
> > Hello Vincent, > > As it seems the 5s net gain is during the early phase of the > boot process, could you please post longer dmesgs, to let us > know where the gain occurs ? Hi Paul, Here is an sdiff between the two dmesg: [0.00] Linux version 2.6.18.8-amd64-envcan-003 (root@ | [ 0.00] Linux version 2.6.18.8-rsdl-0.30-amd64-envcan [0.00] time.c: Detected 2210.220 MHz processor. | [ 0.00] time.c: Detected 2210.215 MHz processor. [ 37.396210] Console: colour dummy device 80x25 | [ 32.320335] Console: colour dummy device 80x25 [ 37.397484] Dentry cache hash table entries: 262144 (order | [ 32.321611] Dentry cache hash table entries: 262144 (order [ 37.399120] Inode-cache hash table entries: 131072 (order: | [ 32.323318] Inode-cache hash table entries: 131072 (order: [ 37.399633] Checking aperture... | [ 32.323869] Checking aperture... [ 37.399641] CPU 0: aperture @ 84 size 32 MB| [ 32.323877] CPU 0: aperture @ 84 size 32 MB [ 37.399645] Aperture too small (32 MB) | [ 32.323881] Aperture too small (32 MB) [ 37.404577] No AGP bridge found| [ 32.328813] No AGP bridge found [ 37.421192] Memory: 2054704k/2096000k available (1934k ker | [ 32.345833] Memory: 2054704k/2096000k available (1935k ker [ 37.498110] Calibrating delay using timer specific routine | [ 32.422230] Calibrating delay using timer specific routine Here is a bit more detailed info: Vanilla Version: [0.00] SMP: Allowing 2 CPUs, 0 hotplug CPUs [0.00] Built 1 zonelists. Total pages: 515848 [0.00] Kernel command line: root=LABEL=DebianEtch_64 ro vga=0x305 [0.00] Initializing CPU#0 [0.00] PID hash table entries: 4096 (order: 12, 32768 bytes) [0.00] Disabling vsyscall due to use of PM timer [0.00] time.c: Using 3.579545 MHz WALL PM GTOD PM timer. [0.00] time.c: Detected 2210.220 MHz processor. [ 37.396210] Console: colour dummy device 80x25 [ 37.397484] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) [ 37.399120] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) [ 37.399633] Checking aperture... [ 37.399641] CPU 0: aperture @ 84 size 32 MB [ 37.399645] Aperture too small (32 MB) [ 37.404577] No AGP bridge found [ 37.421192] Memory: 2054704k/2096000k available (1934k kernel code, 40908k reserved, 868k data, 188k init) RSDL Version: [0.00] Initializing CPU#0 [0.00] PID hash table entries: 4096 (order: 12, 32768 bytes) [0.00] Disabling vsyscall due to use of PM timer [0.00] time.c: Using 3.579545 MHz WALL PM GTOD PM timer. [0.00] time.c: Detected 2210.215 MHz processor. [ 32.320335] Console: colour dummy device 80x25 [ 32.321611] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) [ 32.323318] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) [ 32.323869] Checking aperture... [ 32.323877] CPU 0: aperture @ 84 size 32 MB [ 32.323881] Aperture too small (32 MB) [ 32.328813] No AGP bridge found There seems to be a some sort of lag happening adter the CPU detection... It might simply be the call to vga=0x305 which takes less or more time depending of the kernel? I have attached a gzip full dmesg. > > Regards, > Paul > - vin dmesg.2.6.18.8-rsdl-0.30-amd64-envcan.gz Description: dmesg.2.6.18.8-rsdl-0.30-amd64-envcan.gz
RE: RSDL v0.30 cpu scheduler for ... 2.6.18.8 kernel
Hello Vincent, As it seems the 5s net gain is during the early phase of the boot process, could you please post longer dmesgs, to let us know where the gain occurs ? Hi Paul, Here is an sdiff between the two dmesg: [0.00] Linux version 2.6.18.8-amd64-envcan-003 (root@ | [ 0.00] Linux version 2.6.18.8-rsdl-0.30-amd64-envcan [0.00] time.c: Detected 2210.220 MHz processor. | [ 0.00] time.c: Detected 2210.215 MHz processor. [ 37.396210] Console: colour dummy device 80x25 | [ 32.320335] Console: colour dummy device 80x25 [ 37.397484] Dentry cache hash table entries: 262144 (order | [ 32.321611] Dentry cache hash table entries: 262144 (order [ 37.399120] Inode-cache hash table entries: 131072 (order: | [ 32.323318] Inode-cache hash table entries: 131072 (order: [ 37.399633] Checking aperture... | [ 32.323869] Checking aperture... [ 37.399641] CPU 0: aperture @ 84 size 32 MB| [ 32.323877] CPU 0: aperture @ 84 size 32 MB [ 37.399645] Aperture too small (32 MB) | [ 32.323881] Aperture too small (32 MB) [ 37.404577] No AGP bridge found| [ 32.328813] No AGP bridge found [ 37.421192] Memory: 2054704k/2096000k available (1934k ker | [ 32.345833] Memory: 2054704k/2096000k available (1935k ker [ 37.498110] Calibrating delay using timer specific routine | [ 32.422230] Calibrating delay using timer specific routine Here is a bit more detailed info: Vanilla Version: [0.00] SMP: Allowing 2 CPUs, 0 hotplug CPUs [0.00] Built 1 zonelists. Total pages: 515848 [0.00] Kernel command line: root=LABEL=DebianEtch_64 ro vga=0x305 [0.00] Initializing CPU#0 [0.00] PID hash table entries: 4096 (order: 12, 32768 bytes) [0.00] Disabling vsyscall due to use of PM timer [0.00] time.c: Using 3.579545 MHz WALL PM GTOD PM timer. [0.00] time.c: Detected 2210.220 MHz processor. [ 37.396210] Console: colour dummy device 80x25 [ 37.397484] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) [ 37.399120] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) [ 37.399633] Checking aperture... [ 37.399641] CPU 0: aperture @ 84 size 32 MB [ 37.399645] Aperture too small (32 MB) [ 37.404577] No AGP bridge found [ 37.421192] Memory: 2054704k/2096000k available (1934k kernel code, 40908k reserved, 868k data, 188k init) RSDL Version: [0.00] Initializing CPU#0 [0.00] PID hash table entries: 4096 (order: 12, 32768 bytes) [0.00] Disabling vsyscall due to use of PM timer [0.00] time.c: Using 3.579545 MHz WALL PM GTOD PM timer. [0.00] time.c: Detected 2210.215 MHz processor. [ 32.320335] Console: colour dummy device 80x25 [ 32.321611] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) [ 32.323318] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) [ 32.323869] Checking aperture... [ 32.323877] CPU 0: aperture @ 84 size 32 MB [ 32.323881] Aperture too small (32 MB) [ 32.328813] No AGP bridge found There seems to be a some sort of lag happening adter the CPU detection... It might simply be the call to vga=0x305 which takes less or more time depending of the kernel? I have attached a gzip full dmesg. Regards, Paul - vin dmesg.2.6.18.8-rsdl-0.30-amd64-envcan.gz Description: dmesg.2.6.18.8-rsdl-0.30-amd64-envcan.gz
RE: [ck] Re: RSDL v0.30 cpu scheduler for ... 2.6.18.8 kernel
On Monday 12 March 2007 22:21, Michael Gerdau wrote: And here are the backported RSDL 0.30 patches in case any of you would still be running an older 2.6.18.8 kernel ... The original mail doesn't seem to have made it to the ck-list. Where would I find the backported RSDL 0.30 patches for 2.6.18.8 ? It might have been filtered due to containing attachments, or because the author wasn't a member of the mailing list, sorry. I've found a place to put theses patches to: http://linux-dev.qc.ec.gc.ca/kernel/rsdl/2.6.18.8-rsdl-0.30.patch http://linux-dev.qc.ec.gc.ca/kernel/rsdl/2.6.18.8-rsdl-0.29-0.30.patch There is also a Debian Etch x86_64 2.6.18-rsdl-0.30 kernel available at: http://linux-dev.qc.ec.gc.ca/kernel/debian/etch/x86_64/linux-headers-2.6 .18.8-rsdl-0.30-amd64-envcan_2.6.18.8-rsdl-0.30-003_amd64.deb http://linux-dev.qc.ec.gc.ca/kernel/debian/etch/x86_64/linux-image-2.6.1 8.8-rsdl-0.30-amd64-envcan_2.6.18.8-rsdl-0.30-003_amd64.deb Hope this helps! -vin - 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/
RSDL v0.28 for 2.6.20 -> backport to 2.6.18.8
Hi all, > > Here is an update for RSDL to version 0.28 > > Full patch: > http://ck.kolivas.org/patches/staircase-deadline/2.6.20-sched- > rsdl-0.28.patch > > Series: > http://ck.kolivas.org/patches/staircase-deadline/2.6.20/ > > The patch to get you from 0.26 to 0.28: > http://ck.kolivas.org/patches/staircase-deadline/2.6.20/sched- > rsdl-0.26-0.28.patch > > A similar patch and directories will be made for 2.6.21-rc3 > without further announcement > First of all, thanx Con for this nice piece of code. I've been trying in the last few days to backport this new scheduler to a 2.6.18 kernel. After a lot of efforts I have finally been able to compile and run a RSDL patched 2.6.18.8 kernel on a x86_64 arch and actually my test PC booted 2-3 seconds faster with it compared to a vanilla 2.6.18.8 kernel. This patch includes a few other patches from 2.6.19+ kernel: PATCH 1: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.20.y.git;a=co mmit;h=ece8a684c75df215320b4155944979e3f78c5c93 PATCH 2: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.20.y.git;a=co mmit;h=08c183f31bdbb709f177f6d3110d5f288ea33933 PATCH 3: The patch to get you from 0.26 to 0.28: http://ck.kolivas.org/patches/staircase-deadline/2.6.20/sched-rsdl-0.26- 0.28.patch There might also be other small pieces of code comming from a 2.6.19+ kernel. Due to the project I'm currently working on, this will, in the next few weeks, help me out comparing heavy loads on a Debian Sarge/Etch 32/64 platform. Suggestions on benchmark tools would greatly be appreciated. Duno if this will be helpfull for anybody but I tought it would be nice to give it back to the lkml community. - vin sched-rsdl-0.26-backport-kernel-2.6.18.patch.gz Description: sched-rsdl-0.26-backport-kernel-2.6.18.patch.gz
RSDL v0.28 for 2.6.20 - backport to 2.6.18.8
Hi all, Here is an update for RSDL to version 0.28 Full patch: http://ck.kolivas.org/patches/staircase-deadline/2.6.20-sched- rsdl-0.28.patch Series: http://ck.kolivas.org/patches/staircase-deadline/2.6.20/ The patch to get you from 0.26 to 0.28: http://ck.kolivas.org/patches/staircase-deadline/2.6.20/sched- rsdl-0.26-0.28.patch A similar patch and directories will be made for 2.6.21-rc3 without further announcement First of all, thanx Con for this nice piece of code. I've been trying in the last few days to backport this new scheduler to a 2.6.18 kernel. After a lot of efforts I have finally been able to compile and run a RSDL patched 2.6.18.8 kernel on a x86_64 arch and actually my test PC booted 2-3 seconds faster with it compared to a vanilla 2.6.18.8 kernel. This patch includes a few other patches from 2.6.19+ kernel: PATCH 1: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.20.y.git;a=co mmit;h=ece8a684c75df215320b4155944979e3f78c5c93 PATCH 2: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.20.y.git;a=co mmit;h=08c183f31bdbb709f177f6d3110d5f288ea33933 PATCH 3: The patch to get you from 0.26 to 0.28: http://ck.kolivas.org/patches/staircase-deadline/2.6.20/sched-rsdl-0.26- 0.28.patch There might also be other small pieces of code comming from a 2.6.19+ kernel. Due to the project I'm currently working on, this will, in the next few weeks, help me out comparing heavy loads on a Debian Sarge/Etch 32/64 platform. Suggestions on benchmark tools would greatly be appreciated. Duno if this will be helpfull for anybody but I tought it would be nice to give it back to the lkml community. - vin sched-rsdl-0.26-backport-kernel-2.6.18.patch.gz Description: sched-rsdl-0.26-backport-kernel-2.6.18.patch.gz
RE: Boot time Bluetooth BUG: warning: (value > m) at hid-core.c:793
Hi Jiri, Actually I don't know... Let me test this. Here is the scenario: 1) If I plug my USB dongle after my system has booted, everything works fine (except that the keyboard repeats a few keys somethimes..) 2) If the dongle is already plugged at boot-time, there is a BUG echo in the dmesg when the bluetooth service fires up. This make both the mouse and keyboard unresponsive until I finally unplug / replug the dongle hence going back at state 1) I never run the hid2hci command manually but the bluetooth init script seems to do so. Quick test: 1- unplug/plug back the dongle to get back to state 1) The keyboard and mouse do work has expected... 2- Now run the hid2hci command has root [EMAIL PROTECTED] init.d]# hid2hci Switching device 046d:c70a to HCI mode was successful Switching device 046d:c70e to HCI mode was successful DMESG: input: Logitech Logitech BT Mini-Receiver as /class/input/input15 input,hiddev96: USB HID v1.11 Mouse [Logitech Logitech BT Mini-Receiver] on usb-:00:1d.7-6.2.2.1.2.3 BUG: warning: (value > m) at drivers/usb/input/hid-core.c:793/implement() (Tainted: P ) [] dump_trace+0x69/0x1b6 [] show_trace_log_lvl+0x18/0x2c [] show_trace+0xf/0x11 [] dump_stack+0x15/0x17 [] hid_output_report+0x23c/0x2e7 [] hid_submit_ctrl+0x4c/0x1d9 [] hid_submit_report+0x134/0x15f [] hiddev_ioctl+0x327/0x88a [] do_ioctl+0x4c/0x62 [] vfs_ioctl+0x24a/0x25c [] sys_ioctl+0x4c/0x66 [] syscall_call+0x7/0xb [<001e8402>] 0x1e8402 === BUG: warning: 3) Now repeat step 1): === usb 4-6.2.2.1.2.1: new full speed USB device using ehci_hcd and address 24 usb 4-6.2.2.1.2.1: configuration #1 chosen from 1 choice usb 4-6.2.2.1.2: USB disconnect, address 21 usb 4-6.2.2.1.2.1: USB disconnect, address 24 usb 4-6.2.2.1.2.2: USB disconnect, address 22 usb 4-6.2.2.1.2.3: USB disconnect, address 23 usb 4-6.2.2.1.2: new full speed USB device using ehci_hcd and address 25 usb 4-6.2.2.1.2: configuration #1 chosen from 1 choice hub 4-6.2.2.1.2:1.0: USB hub found hub 4-6.2.2.1.2:1.0: 3 ports detected usb 4-6.2.2.1.2.1: new full speed USB device using ehci_hcd and address 26 usb 4-6.2.2.1.2.1: configuration #1 chosen from 1 choice usb 4-6.2.2.1.2.2: new full speed USB device using ehci_hcd and address 27 usb 4-6.2.2.1.2.2: configuration #1 chosen from 1 choice input: Logitech Logitech BT Mini-Receiver as /class/input/input16 input: USB HID v1.11 Keyboard [Logitech Logitech BT Mini-Receiver] on usb-:00:1d.7-6.2.2.1.2.2 usb 4-6.2.2.1.2.3: new full speed USB device using ehci_hcd and address 28 usb 4-6.2.2.1.2.3: configuration #1 chosen from 1 choice input: Logitech Logitech BT Mini-Receiver as /class/input/input17 input,hiddev96: USB HID v1.11 Mouse [Logitech Logitech BT Mini-Receiver] on usb-:00:1d.7-6.2.2.1.2.3 So yes, it looks like a hid2hci BUG or kernel BUG initiated by the hid2hci command. - vin > -Message d'origine- > De : Jiri Kosina [mailto:[EMAIL PROTECTED] > Envoyé : 27 février 2007 11:15 > À : Fortier,Vincent [Montreal] > Objet : RE: Boot time Bluetooth BUG: warning: (value > m) at > hid-core.c:793 > > On Tue, 27 Feb 2007, Fortier,Vincent [Montreal] wrote: > > > Actually it's the first time I'm trying this keyboard and mouse. > > And I guess when you use it in HID mode (i.e. when the > hid2hci command is not run), then keyboard and mouse work > with no errors reported in the kernel logs, and all the > buttons work correctly, am I right? > > -- > 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: Boot time Bluetooth BUG: warning: (value > m) at hid-core.c:793
> > we understand the original CSR HID proxy dongles, but for the Logitech > ones, it is wild guesses. The current support in hid2hci has been > tested on Logitech diNovo first generation and I have no other > Logitech hardware to verify it with. We might simply need > the full HID report descriptor to see who is at fault. > > As far as I can see from a quick look, the device IDs are > unchanged (0x046d/0xc70e for the keyboard), but the report > descriptor seems to differ from the one you have at > http://www.holtmann.org/linux/bluetooth/logitech.html - that > seems pretty sad. > > What puzzles me a bit is a fact that both the bugreporters > seem to state pretty clearly that this started happening > after some update, am I right? > > Or did the hardware before work all the time in the HID mode, > without even being attempted to switch to HCI (which seems to > cause the bug)? > Actually it's the first time I'm trying this keyboard and mouse. - vin - 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: Boot time Bluetooth BUG: warning: (value m) at hid-core.c:793
we understand the original CSR HID proxy dongles, but for the Logitech ones, it is wild guesses. The current support in hid2hci has been tested on Logitech diNovo first generation and I have no other Logitech hardware to verify it with. We might simply need the full HID report descriptor to see who is at fault. As far as I can see from a quick look, the device IDs are unchanged (0x046d/0xc70e for the keyboard), but the report descriptor seems to differ from the one you have at http://www.holtmann.org/linux/bluetooth/logitech.html - that seems pretty sad. What puzzles me a bit is a fact that both the bugreporters seem to state pretty clearly that this started happening after some update, am I right? Or did the hardware before work all the time in the HID mode, without even being attempted to switch to HCI (which seems to cause the bug)? Actually it's the first time I'm trying this keyboard and mouse. - vin - 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: Boot time Bluetooth BUG: warning: (value m) at hid-core.c:793
Hi Jiri, Actually I don't know... Let me test this. Here is the scenario: 1) If I plug my USB dongle after my system has booted, everything works fine (except that the keyboard repeats a few keys somethimes..) 2) If the dongle is already plugged at boot-time, there is a BUG echo in the dmesg when the bluetooth service fires up. This make both the mouse and keyboard unresponsive until I finally unplug / replug the dongle hence going back at state 1) I never run the hid2hci command manually but the bluetooth init script seems to do so. Quick test: 1- unplug/plug back the dongle to get back to state 1) The keyboard and mouse do work has expected... 2- Now run the hid2hci command has root [EMAIL PROTECTED] init.d]# hid2hci Switching device 046d:c70a to HCI mode was successful Switching device 046d:c70e to HCI mode was successful DMESG: input: Logitech Logitech BT Mini-Receiver as /class/input/input15 input,hiddev96: USB HID v1.11 Mouse [Logitech Logitech BT Mini-Receiver] on usb-:00:1d.7-6.2.2.1.2.3 BUG: warning: (value m) at drivers/usb/input/hid-core.c:793/implement() (Tainted: P ) [c0405018] dump_trace+0x69/0x1b6 [c040517d] show_trace_log_lvl+0x18/0x2c [c0405778] show_trace+0xf/0x11 [c0405875] dump_stack+0x15/0x17 [c05993c0] hid_output_report+0x23c/0x2e7 [c05994b7] hid_submit_ctrl+0x4c/0x1d9 [c05997fd] hid_submit_report+0x134/0x15f [c059bd09] hiddev_ioctl+0x327/0x88a [c04802c8] do_ioctl+0x4c/0x62 [c0480528] vfs_ioctl+0x24a/0x25c [c0480586] sys_ioctl+0x4c/0x66 [c040404b] syscall_call+0x7/0xb [001e8402] 0x1e8402 === BUG: warning: 3) Now repeat step 1): === usb 4-6.2.2.1.2.1: new full speed USB device using ehci_hcd and address 24 usb 4-6.2.2.1.2.1: configuration #1 chosen from 1 choice usb 4-6.2.2.1.2: USB disconnect, address 21 usb 4-6.2.2.1.2.1: USB disconnect, address 24 usb 4-6.2.2.1.2.2: USB disconnect, address 22 usb 4-6.2.2.1.2.3: USB disconnect, address 23 usb 4-6.2.2.1.2: new full speed USB device using ehci_hcd and address 25 usb 4-6.2.2.1.2: configuration #1 chosen from 1 choice hub 4-6.2.2.1.2:1.0: USB hub found hub 4-6.2.2.1.2:1.0: 3 ports detected usb 4-6.2.2.1.2.1: new full speed USB device using ehci_hcd and address 26 usb 4-6.2.2.1.2.1: configuration #1 chosen from 1 choice usb 4-6.2.2.1.2.2: new full speed USB device using ehci_hcd and address 27 usb 4-6.2.2.1.2.2: configuration #1 chosen from 1 choice input: Logitech Logitech BT Mini-Receiver as /class/input/input16 input: USB HID v1.11 Keyboard [Logitech Logitech BT Mini-Receiver] on usb-:00:1d.7-6.2.2.1.2.2 usb 4-6.2.2.1.2.3: new full speed USB device using ehci_hcd and address 28 usb 4-6.2.2.1.2.3: configuration #1 chosen from 1 choice input: Logitech Logitech BT Mini-Receiver as /class/input/input17 input,hiddev96: USB HID v1.11 Mouse [Logitech Logitech BT Mini-Receiver] on usb-:00:1d.7-6.2.2.1.2.3 So yes, it looks like a hid2hci BUG or kernel BUG initiated by the hid2hci command. - vin -Message d'origine- De : Jiri Kosina [mailto:[EMAIL PROTECTED] Envoyé : 27 février 2007 11:15 À : Fortier,Vincent [Montreal] Objet : RE: Boot time Bluetooth BUG: warning: (value m) at hid-core.c:793 On Tue, 27 Feb 2007, Fortier,Vincent [Montreal] wrote: Actually it's the first time I'm trying this keyboard and mouse. And I guess when you use it in HID mode (i.e. when the hid2hci command is not run), then keyboard and mouse work with no errors reported in the kernel logs, and all the buttons work correctly, am I right? -- 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/
