I've had several of these is the past few days. They all seem related to /sys/devices/platform/coretemp.1/temp1_input, but my machine isn't running particularly hot (at least according to ksensors). It's around 60 on both cpus.
Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz on an Intel 965 mobo. Fedora 2.6.31.12-174.2.3.fc12.x86_64 x86_64 (kernel updated 2 weeks ago) KDE 4.3.4
Any thoughts?
Message from syslogd@bree at Feb 5 10:43:24 ... kernel:general protection fault: 0000 [#1] SMP
Message from syslogd@bree at Feb 5 10:43:24 ... kernel:last sysfs file: /sys/devices/platform/coretemp.1/temp1_input
Message from syslogd@bree at Feb 5 10:43:24 ... kernel:Stack:
Message from syslogd@bree at Feb 5 10:43:24 ... kernel:Call Trace:
Message from syslogd@bree at Feb 5 10:43:24 ... kernel:Code: eb ce 66 ff 05 e7 af 56 00 31 c0 5e 5b 41 5c 41 5d c9 c3 55 48 89 e5 41 54 53 0f 1f 44 00 00 48 89 fb 48 85 db 0f 84 12 01 00 00 <8b> 03 ff c8 75 16 be dd 00 00 00 48 c7 c7 4d cc 57 81 e8 32 31
poc
On Fri, 2010-02-05 at 11:45 -0430, Patrick O'Callaghan wrote:
I've had several of these is the past few days. They all seem related to /sys/devices/platform/coretemp.1/temp1_input, but my machine isn't running particularly hot (at least according to ksensors). It's around 60 on both cpus.
Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz on an Intel 965 mobo. Fedora 2.6.31.12-174.2.3.fc12.x86_64 x86_64 (kernel updated 2 weeks ago) KDE 4.3.4
Any thoughts?
Message from syslogd@bree at Feb 5 10:43:24 ... kernel:general protection fault: 0000 [#1] SMP
Message from syslogd@bree at Feb 5 10:43:24 ... kernel:last sysfs file: /sys/devices/platform/coretemp.1/temp1_input
Message from syslogd@bree at Feb 5 10:43:24 ... kernel:Stack:
Message from syslogd@bree at Feb 5 10:43:24 ... kernel:Call Trace:
Message from syslogd@bree at Feb 5 10:43:24 ... kernel:Code: eb ce 66 ff 05 e7 af 56 00 31 c0 5e 5b 41 5c 41 5d c9 c3 55 48 89 e5 41 54 53 0f 1f 44 00 00 48 89 fb 48 85 db 0f 84 12 01 00 00 <8b> 03 ff c8 75 16 be dd 00 00 00 48 c7 c7 4d cc 57 81 e8 32 31
poc
Please post the output of $ dmesg
- Gilboa
On Fri, 2010-02-05 at 19:12 +0200, Gilboa Davara wrote:
On Fri, 2010-02-05 at 11:45 -0430, Patrick O'Callaghan wrote:
I've had several of these is the past few days. They all seem related to /sys/devices/platform/coretemp.1/temp1_input, but my machine isn't running particularly hot (at least according to ksensors). It's around 60 on both cpus.
Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz on an Intel 965 mobo. Fedora 2.6.31.12-174.2.3.fc12.x86_64 x86_64 (kernel updated 2 weeks ago) KDE 4.3.4
Any thoughts?
Message from syslogd@bree at Feb 5 10:43:24 ... kernel:general protection fault: 0000 [#1] SMP
Message from syslogd@bree at Feb 5 10:43:24 ... kernel:last sysfs file: /sys/devices/platform/coretemp.1/temp1_input
Message from syslogd@bree at Feb 5 10:43:24 ... kernel:Stack:
Message from syslogd@bree at Feb 5 10:43:24 ... kernel:Call Trace:
Message from syslogd@bree at Feb 5 10:43:24 ... kernel:Code: eb ce 66 ff 05 e7 af 56 00 31 c0 5e 5b 41 5c 41 5d c9 c3 55 48 89 e5 41 54 53 0f 1f 44 00 00 48 89 fb 48 85 db 0f 84 12 01 00 00 <8b> 03 ff c8 75 16 be dd 00 00 00 48 c7 c7 4d cc 57 81 e8 32 31
poc
Please post the output of $ dmesg
Here goes. Looks like PA may be involved (I've had it crash a lot lately).
general protection fault: 0000 [#1] SMP last sysfs file: /sys/devices/platform/coretemp.1/temp1_input CPU 1 Modules linked in: fuse nfs lockd fscache nfs_acl auth_rpcgss vboxnetadp vboxnetflt vboxdrv autofs4 coretemp sunrpc cpufreq_ondemand acpi_cpufreq freq_table nf_conntrack_netbios_ns ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 dm_multipath kvm_intel kvm uinput snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device firewire_ohci snd_pcm firewire_core snd_timer ppdev snd parport_pc soundcore e1000e iTCO_wdt parport crc_itu_t i2c_i801 snd_page_alloc iTCO_vendor_support ata_generic pata_acpi usb_storage pata_marvell i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: microcode] Pid: 2623, comm: pulseaudio Not tainted 2.6.31.12-174.2.3.fc12.x86_64 #1 RIP: 0010:[<ffffffff8110d03b>] [<ffffffff8110d03b>] dput+0x18/0x12f RSP: 0018:ffff8800a1479ee8 EFLAGS: 00010206 RAX: 0000000000000000 RBX: 1000000000000000 RCX: ffff8800a1478000 RDX: 0000000000000001 RSI: 0000000000000001 RDI: 1000000000000000 RBP: ffff8800a1479ef8 R08: ffffea0003cd48c8 R09: 0000000000000004 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8800880b1800 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000001302a80 FS: 00007f88a09f1780(0000) GS:ffff880028040000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00007f97876cf000 CR3: 000000009f93f000 CR4: 00000000000026e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process pulseaudio (pid: 2623, threadinfo ffff8800a1478000, task ffff8801247e4680) Stack: ffff8800880b1eb8 ffff8800880b1800 ffff8800a1479f18 ffffffff8110456d <0> 000000000000c221 ffff8800880b1800 ffff8800a1479f48 ffffffff81095ba9 <0> ffff8800880b1800 ffff8801247e4680 ffff8800880b1800 0000000000000000 Call Trace: [<ffffffff8110456d>] path_put+0x1a/0x27 [<ffffffff81095ba9>] audit_free_names+0x5b/0x7a [<ffffffff81095da1>] audit_syscall_exit+0xb3/0x14c [<ffffffff81011ea8>] sysret_audit+0x14/0x1e Code: eb ce 66 ff 05 e7 af 56 00 31 c0 5e 5b 41 5c 41 5d c9 c3 55 48 89 e5 41 54 53 0f 1f 44 00 00 48 89 fb 48 85 db 0f 84 12 01 00 00 <8b> 03 ff c8 75 16 be dd 00 00 00 48 c7 c7 4d cc 57 81 e8 32 31 RIP [<ffffffff8110d03b>] dput+0x18/0x12f RSP <ffff8800a1479ee8> ---[ end trace 8dfaacc6f2901eda ]---
poc
On Fri, 2010-02-05 at 13:01 -0430, Patrick O'Callaghan wrote:
On Fri, 2010-02-05 at 19:12 +0200, Gilboa Davara wrote:
On Fri, 2010-02-05 at 11:45 -0430, Patrick O'Callaghan wrote:
I've had several of these is the past few days. They all seem related to /sys/devices/platform/coretemp.1/temp1_input, but my machine isn't
I wouldn't read too much into that - that's just the last file from sysfs that's been touched. Unless you've some other reason to suspect sysfs is related I'd doubt there's anything to connect the two.
Here goes. Looks like PA may be involved (I've had it crash a lot lately).
PA looks like an innocent victim (or if it is in any direct way implicated it is just triggering a kernel bug that was already there - userspace should not be able to make the kernel GPF).
general protection fault: 0000 [#1] SMP last sysfs file: /sys/devices/platform/coretemp.1/temp1_input CPU 1
Modules linked in: fuse nfs lockd fscache nfs_acl auth_rpcgss vboxnetadp vboxnetflt vboxdrv autofs4 coretemp sunrpc cpufreq_ondemand acpi_cpufreq freq_table nf_conntrack_netbios_ns ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 dm_multipath kvm_intel kvm uinput snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device firewire_ohci snd_pcm firewire_core snd_timer ppdev snd parport_pc soundcore e1000e iTCO_wdt parport crc_itu_t i2c_i801 snd_page_alloc iTCO_vendor_support ata_generic pata_acpi usb_storage pata_marvell i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: microcode]
Pid: 2623, comm: pulseaudio Not tainted 2.6.31.12-174.2.3.fc12.x86_64 #1 RIP: 0010:[<ffffffff8110d03b>] [<ffffffff8110d03b>] dput+0x18/0x12f RSP: 0018:ffff8800a1479ee8 EFLAGS: 00010206 RAX: 0000000000000000 RBX: 1000000000000000 RCX: ffff8800a1478000 RDX: 0000000000000001 RSI: 0000000000000001 RDI: 1000000000000000 RBP: ffff8800a1479ef8 R08: ffffea0003cd48c8 R09: 0000000000000004 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8800880b1800 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000001302a80 FS: 00007f88a09f1780(0000) GS:ffff880028040000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00007f97876cf000 CR3: 000000009f93f000 CR4: 00000000000026e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process pulseaudio (pid: 2623, threadinfo ffff8800a1478000, task ffff8801247e4680) Stack: ffff8800880b1eb8 ffff8800880b1800 ffff8800a1479f18 ffffffff8110456d <0> 000000000000c221 ffff8800880b1800 ffff8800a1479f48 ffffffff81095ba9 <0> ffff8800880b1800 ffff8801247e4680 ffff8800880b1800 0000000000000000 Call Trace: [<ffffffff8110456d>] path_put+0x1a/0x27 [<ffffffff81095ba9>] audit_free_names+0x5b/0x7a [<ffffffff81095da1>] audit_syscall_exit+0xb3/0x14c [<ffffffff81011ea8>] sysret_audit+0x14/0x1e
Are the crashes you're seeing always in this set of functions (same backtrace) or are you getting variations?
Regards, Bryn.
On Fri, 2010-02-05 at 17:51 +0000, Bryn M. Reeves wrote:
On Fri, 2010-02-05 at 13:01 -0430, Patrick O'Callaghan wrote:
On Fri, 2010-02-05 at 19:12 +0200, Gilboa Davara wrote:
On Fri, 2010-02-05 at 11:45 -0430, Patrick O'Callaghan wrote:
I've had several of these is the past few days. They all seem related to /sys/devices/platform/coretemp.1/temp1_input, but my machine isn't
I wouldn't read too much into that - that's just the last file from sysfs that's been touched. Unless you've some other reason to suspect sysfs is related I'd doubt there's anything to connect the two.
Here goes. Looks like PA may be involved (I've had it crash a lot lately).
PA looks like an innocent victim (or if it is in any direct way implicated it is just triggering a kernel bug that was already there - userspace should not be able to make the kernel GPF).
general protection fault: 0000 [#1] SMP last sysfs file: /sys/devices/platform/coretemp.1/temp1_input CPU 1
Modules linked in: fuse nfs lockd fscache nfs_acl auth_rpcgss vboxnetadp vboxnetflt vboxdrv autofs4 coretemp sunrpc cpufreq_ondemand acpi_cpufreq freq_table nf_conntrack_netbios_ns ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 dm_multipath kvm_intel kvm uinput snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device firewire_ohci snd_pcm firewire_core snd_timer ppdev snd parport_pc soundcore e1000e iTCO_wdt parport crc_itu_t i2c_i801 snd_page_alloc iTCO_vendor_support ata_generic pata_acpi usb_storage pata_marvell i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: microcode]
Pid: 2623, comm: pulseaudio Not tainted 2.6.31.12-174.2.3.fc12.x86_64 #1 RIP: 0010:[<ffffffff8110d03b>] [<ffffffff8110d03b>] dput+0x18/0x12f RSP: 0018:ffff8800a1479ee8 EFLAGS: 00010206 RAX: 0000000000000000 RBX: 1000000000000000 RCX: ffff8800a1478000 RDX: 0000000000000001 RSI: 0000000000000001 RDI: 1000000000000000 RBP: ffff8800a1479ef8 R08: ffffea0003cd48c8 R09: 0000000000000004 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8800880b1800 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000001302a80 FS: 00007f88a09f1780(0000) GS:ffff880028040000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00007f97876cf000 CR3: 000000009f93f000 CR4: 00000000000026e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process pulseaudio (pid: 2623, threadinfo ffff8800a1478000, task ffff8801247e4680) Stack: ffff8800880b1eb8 ffff8800880b1800 ffff8800a1479f18 ffffffff8110456d <0> 000000000000c221 ffff8800880b1800 ffff8800a1479f48 ffffffff81095ba9 <0> ffff8800880b1800 ffff8801247e4680 ffff8800880b1800 0000000000000000 Call Trace: [<ffffffff8110456d>] path_put+0x1a/0x27 [<ffffffff81095ba9>] audit_free_names+0x5b/0x7a [<ffffffff81095da1>] audit_syscall_exit+0xb3/0x14c [<ffffffff81011ea8>] sysret_audit+0x14/0x1e
Are the crashes you're seeing always in this set of functions (same backtrace) or are you getting variations?
I haven't bothered recording them, my bad. I'll follow up when I get more crashes.
poc
On Fri, 2010-02-05 at 17:51 +0000, Bryn M. Reeves wrote:
[<ffffffff8110456d>] path_put+0x1a/0x27 [<ffffffff81095ba9>] audit_free_names+0x5b/0x7a [<ffffffff81095da1>] audit_syscall_exit+0xb3/0x14c [<ffffffff81011ea8>] sysret_audit+0x14/0x1e
Are the crashes you're seeing always in this set of functions (same backtrace) or are you getting variations?
I started seeing wierd behaviour (NFS failures, sudden crash of KDE etc.) so I ran memtest and discovered some bad RAM in the 3-4Gb range.
I've rebooted using mem=2000M and we'll see what happens.
poc
On Fri, 2010-02-05 at 19:30 -0430, Patrick O'Callaghan wrote:
On Fri, 2010-02-05 at 17:51 +0000, Bryn M. Reeves wrote:
[<ffffffff8110456d>] path_put+0x1a/0x27 [<ffffffff81095ba9>] audit_free_names+0x5b/0x7a [<ffffffff81095da1>] audit_syscall_exit+0xb3/0x14c [<ffffffff81011ea8>] sysret_audit+0x14/0x1e
Are the crashes you're seeing always in this set of functions (same backtrace) or are you getting variations?
I started seeing wierd behaviour (NFS failures, sudden crash of KDE etc.) so I ran memtest and discovered some bad RAM in the 3-4Gb range.
I've rebooted using mem=2000M and we'll see what happens.
poc
poc,
mem=2000m may not help, as your BIOS/chipset might be interleaving memory from multiple banks. I'd know more if you post your hardware configuration. (CPU, Motherboard, number of DIMMs, etc.)
In general, you should disable interleaving in BIOS (if you chipset/bios/CPU supports it) and fire up memtest (found on the Fedora ISO's and at http://www.memtest.org/) Let it run for ~12-24h. If it find a bad DIMMs (usually in pairs), remove it and run memtest again.
- Gilboa
On 02/07/2010 03:42 AM, Gilboa Davara wrote:
poc,
mem=2000m may not help, as your BIOS/chipset might be interleaving memory from multiple banks. I'd know more if you post your hardware configuration. (CPU, Motherboard, number of DIMMs, etc.)
In general, you should disable interleaving in BIOS (if you chipset/bios/CPU supports it) and fire up memtest (found on the Fedora ISO's and at http://www.memtest.org/) Let it run for ~12-24h. If it find a bad DIMMs (usually in pairs), remove it and run memtest again.
- Gilboa
You may also want to use some of the optional menus once you have an error. Memtest has this handy option that will tell you what DIM socket the memory that generated the error is in, so you know what one to pull. (It man not work with all setups.)
Mikkel
On Sun, 2010-02-07 at 11:42 +0200, Gilboa Davara wrote:
On Fri, 2010-02-05 at 19:30 -0430, Patrick O'Callaghan wrote:
On Fri, 2010-02-05 at 17:51 +0000, Bryn M. Reeves wrote:
[<ffffffff8110456d>] path_put+0x1a/0x27 [<ffffffff81095ba9>] audit_free_names+0x5b/0x7a [<ffffffff81095da1>] audit_syscall_exit+0xb3/0x14c [<ffffffff81011ea8>] sysret_audit+0x14/0x1e
Are the crashes you're seeing always in this set of functions (same backtrace) or are you getting variations?
I started seeing wierd behaviour (NFS failures, sudden crash of KDE etc.) so I ran memtest and discovered some bad RAM in the 3-4Gb range.
I've rebooted using mem=2000M and we'll see what happens.
poc
poc,
mem=2000m may not help, as your BIOS/chipset might be interleaving memory from multiple banks.
Of course, but if so the interleaving would also apply when running memtest. IOW if memtest tells me the lower and upper addresses for errors are (say) 2200M and 3600M, and marks banks 3 and 4 as being the origin of these, then setting mem=2000M will avoid them, no matter what the interleaving is. Identifying which DIMMS they are is of course another matter, which is why I did it this way before starting to pull DIMMs (it's very easy to confuse yourself doing that).
I'd know more if you post your hardware configuration. (CPU, Motherboard, number of DIMMs, etc.)
Intel D865GLC, Core 2 Duo 6400 @ 2.13GHz. There are 4x1GB DDR-2 sticks.
In general, you should disable interleaving in BIOS (if you chipset/bios/CPU supports it) and fire up memtest (found on the Fedora ISO's and at http://www.memtest.org/)
I ran memtest (several passes) limited to 2000M and it found no errors.
poc
On Sun, 2010-02-07 at 10:07 -0600, Mikkel wrote:
On 02/07/2010 03:42 AM, Gilboa Davara wrote:
poc,
mem=2000m may not help, as your BIOS/chipset might be interleaving memory from multiple banks. I'd know more if you post your hardware configuration. (CPU, Motherboard, number of DIMMs, etc.)
In general, you should disable interleaving in BIOS (if you chipset/bios/CPU supports it) and fire up memtest (found on the Fedora ISO's and at http://www.memtest.org/) Let it run for ~12-24h. If it find a bad DIMMs (usually in pairs), remove it and run memtest again.
- Gilboa
You may also want to use some of the optional menus once you have an error. Memtest has this handy option that will tell you what DIM socket the memory that generated the error is in, so you know what one to pull. (It man not work with all setups.)
Yes, it tells me banks 3 and 4.
poc
On Fri, 2010-02-05 at 17:51 +0000, Bryn M. Reeves wrote:
On Fri, 2010-02-05 at 13:01 -0430, Patrick O'Callaghan wrote:
On Fri, 2010-02-05 at 19:12 +0200, Gilboa Davara wrote:
On Fri, 2010-02-05 at 11:45 -0430, Patrick O'Callaghan wrote:
I've had several of these is the past few days. They all seem related to /sys/devices/platform/coretemp.1/temp1_input, but my machine isn't
I wouldn't read too much into that - that's just the last file from sysfs that's been touched. Unless you've some other reason to suspect sysfs is related I'd doubt there's anything to connect the two.
Here goes. Looks like PA may be involved (I've had it crash a lot lately).
PA looks like an innocent victim (or if it is in any direct way implicated it is just triggering a kernel bug that was already there - userspace should not be able to make the kernel GPF).
general protection fault: 0000 [#1] SMP last sysfs file: /sys/devices/platform/coretemp.1/temp1_input CPU 1
Modules linked in: fuse nfs lockd fscache nfs_acl auth_rpcgss vboxnetadp vboxnetflt vboxdrv autofs4 coretemp sunrpc cpufreq_ondemand acpi_cpufreq freq_table nf_conntrack_netbios_ns ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 dm_multipath kvm_intel kvm uinput snd_hda_codec_idt snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device firewire_ohci snd_pcm firewire_core snd_timer ppdev snd parport_pc soundcore e1000e iTCO_wdt parport crc_itu_t i2c_i801 snd_page_alloc iTCO_vendor_support ata_generic pata_acpi usb_storage pata_marvell i915 drm_kms_helper drm i2c_algo_bit i2c_core video output [last unloaded: microcode]
Pid: 2623, comm: pulseaudio Not tainted 2.6.31.12-174.2.3.fc12.x86_64 #1 RIP: 0010:[<ffffffff8110d03b>] [<ffffffff8110d03b>] dput+0x18/0x12f RSP: 0018:ffff8800a1479ee8 EFLAGS: 00010206 RAX: 0000000000000000 RBX: 1000000000000000 RCX: ffff8800a1478000 RDX: 0000000000000001 RSI: 0000000000000001 RDI: 1000000000000000 RBP: ffff8800a1479ef8 R08: ffffea0003cd48c8 R09: 0000000000000004 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8800880b1800 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000001302a80 FS: 00007f88a09f1780(0000) GS:ffff880028040000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00007f97876cf000 CR3: 000000009f93f000 CR4: 00000000000026e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process pulseaudio (pid: 2623, threadinfo ffff8800a1478000, task ffff8801247e4680) Stack: ffff8800880b1eb8 ffff8800880b1800 ffff8800a1479f18 ffffffff8110456d <0> 000000000000c221 ffff8800880b1800 ffff8800a1479f48 ffffffff81095ba9 <0> ffff8800880b1800 ffff8801247e4680 ffff8800880b1800 0000000000000000 Call Trace: [<ffffffff8110456d>] path_put+0x1a/0x27 [<ffffffff81095ba9>] audit_free_names+0x5b/0x7a [<ffffffff81095da1>] audit_syscall_exit+0xb3/0x14c [<ffffffff81011ea8>] sysret_audit+0x14/0x1e
Are the crashes you're seeing always in this set of functions (same backtrace) or are you getting variations?
After reducing my RAM to 2GB via the mem= boot option (see parallel branch of this thread) I don't seem to be getting memory errors, but I still have problems, apparently with NFS. I've posted a trace from dmesg to http://fpaste.org/eEh6/
The scenario is that I'm using rsync to an NFS-mounted directory as a backup method. I had previously tried rsyncing directly to the server (an Iomega ix2-200 desktop NAS), but it's unbelievably slow in this configuration. I measured 100-300Kbps doing it this way -- which would take well over a day to run my initial full backup job), versus at least an order of magnitude faster running rsync over NFS. I conjecture that the NAS cpu just isn't up to calculating the rsync checksums fast enough to keep up with a 100Mbps LAN.
poc
On Sun, 2010-02-07 at 17:32 -0430, Patrick O'Callaghan wrote: [...]
After reducing my RAM to 2GB via the mem= boot option (see parallel branch of this thread) I don't seem to be getting memory errors, but I still have problems, apparently with NFS. I've posted a trace from dmesg to http://fpaste.org/eEh6/
The scenario is that I'm using rsync to an NFS-mounted directory as a backup method. I had previously tried rsyncing directly to the server (an Iomega ix2-200 desktop NAS), but it's unbelievably slow in this configuration. I measured 100-300Kbps doing it this way -- which would take well over a day to run my initial full backup job), versus at least an order of magnitude faster running rsync over NFS. I conjecture that the NAS cpu just isn't up to calculating the rsync checksums fast enough to keep up with a 100Mbps LAN.
Reported at https://bugzilla.redhat.com/show_bug.cgi?id=562680
poc
On Sun, 2010-02-07 at 17:32 -0430, Patrick O'Callaghan wrote:
After reducing my RAM to 2GB via the mem= boot option (see parallel branch of this thread) I don't seem to be getting memory errors, but I still have problems, apparently with NFS. I've posted a trace from dmesg to http://fpaste.org/eEh6/
That sounds a bit like:
http://article.gmane.org/gmane.linux.nfs/30419
and:
http://article.gmane.org/gmane.linux.nfs/30437
There's a patch in the first link which I don't think is in the kernel you're running; could be worth a look if you are seeing this regularly.
The scenario is that I'm using rsync to an NFS-mounted directory as a backup method. I had previously tried rsyncing directly to the server (an Iomega ix2-200 desktop NAS), but it's unbelievably slow in this configuration. I measured 100-300Kbps doing it this way -- which would take well over a day to run my initial full backup job), versus at least an order of magnitude faster running rsync over NFS. I conjecture that the NAS cpu just isn't up to calculating the rsync checksums fast enough to keep up with a 100Mbps LAN.
Is the box under memory pressure while doing this workload with mem=2g? That would tend to support the idea that you're seeing the above problem since it's been reported to occur under low memory conditions.
Regards, Bryn.
On Tue, 2010-02-09 at 12:19 +0000, Bryn M. Reeves wrote:
On Sun, 2010-02-07 at 17:32 -0430, Patrick O'Callaghan wrote:
After reducing my RAM to 2GB via the mem= boot option (see parallel branch of this thread) I don't seem to be getting memory errors, but I still have problems, apparently with NFS. I've posted a trace from dmesg to http://fpaste.org/eEh6/
That sounds a bit like:
http://article.gmane.org/gmane.linux.nfs/30419
and:
http://article.gmane.org/gmane.linux.nfs/30437
There's a patch in the first link which I don't think is in the kernel you're running; could be worth a look if you are seeing this regularly.
Only a couple of times, but of course I'll keep an eye on it.
The scenario is that I'm using rsync to an NFS-mounted directory as a backup method. I had previously tried rsyncing directly to the server (an Iomega ix2-200 desktop NAS), but it's unbelievably slow in this configuration. I measured 100-300Kbps doing it this way -- which would take well over a day to run my initial full backup job), versus at least an order of magnitude faster running rsync over NFS. I conjecture that the NAS cpu just isn't up to calculating the rsync checksums fast enough to keep up with a 100Mbps LAN.
Is the box under memory pressure while doing this workload with mem=2g? That would tend to support the idea that you're seeing the above problem since it's been reported to occur under low memory conditions.
Very possibly. I was (rashly) trying to run a VBox VM at the same time and I could see more than 50% of swap was committed. Load average was over 20!
poc