FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora User

 
 
LinkBack Thread Tools
 
Old 02-05-2010, 04:12 PM
Gilboa Davara
 
Default Kernel GPF

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


--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
 
Old 02-05-2010, 04:31 PM
Patrick O'Callaghan
 
Default Kernel GPF

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

--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
 
Old 02-05-2010, 04:51 PM
"Bryn M. Reeves"
 
Default Kernel GPF

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.


--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
 
Old 02-05-2010, 05:32 PM
Patrick O'Callaghan
 
Default Kernel GPF

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


--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
 
Old 02-05-2010, 11:00 PM
Patrick O'Callaghan
 
Default Kernel GPF

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

--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
 
Old 02-07-2010, 08:42 AM
Gilboa Davara
 
Default Kernel GPF

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

--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
 
Old 02-07-2010, 03:07 PM
Mikkel
 
Default Kernel GPF

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
--

Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!

--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
 
Old 02-07-2010, 03:08 PM
Patrick O'Callaghan
 
Default Kernel GPF

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

--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
 
Old 02-07-2010, 05:48 PM
Patrick O'Callaghan
 
Default Kernel GPF

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

--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
 
Old 02-07-2010, 09:02 PM
Patrick O'Callaghan
 
Default Kernel GPF

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

Thread Tools




All times are GMT. The time now is 05:11 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org