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 -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
