Re: Kernel GPF

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux