From: Mark Rustad <mrustad@mac.com>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Linux 2.6.16-rc4 edac oops
Date: Wed, 22 Feb 2006 16:02:48 -0600 [thread overview]
Message-ID: <6B9658D7-1522-4936-9492-FED2DFD38D2A@mac.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0602171438050.916@g5.osdl.org>
I find that I sometimes get a non-fatal oops during boot with the
7520 EDAC stuff in place. It doesn't happen on every boot, but fairly
often. I also saw it on -rc3, but decided to try -rc4 before
reporting it. This is in a nearly monolithic kernel, so don't be
surprised when it shows that there are no modules. Here is the
ksymoops output:
1023MB LOWMEM available.
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
CPU 0 irqstacks, hard=b03ec000 soft=b03ea000
CPU 1 irqstacks, hard=b03ed000 soft=b03eb000
Machine check exception polling timer started.
e1000: 0000:02:03.0: e1000_probe: (PCI-X:133MHz:64-bit)
00:30:48:2e:ff:82
e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
e1000: 0000:02:03.1: e1000_probe: (PCI-X:133MHz:64-bit)
00:30:48:2e:ff:83
e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection
e1000: 0000:04:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x4)
00:15:17:00:21:22
e1000: eth2: e1000_probe: Intel(R) PRO/1000 Network Connection
e1000: 0000:04:00.1: e1000_probe: (PCI Express:2.5Gb/s:Width x4)
00:15:17:00:21:23
e1000: eth3: e1000_probe: Intel(R) PRO/1000 Network Connection
ehci_hcd 0000:00:1d.7: debug port 1
EDAC MC0: Giving out device to "e752x_edac" E7520: PCI 0000:00:00.0
Unable to handle kernel NULL pointer dereference at virtual address
00000020
b0282dc4
*pde = 00000000
Oops: 0000 [#1]
CPU: 0
EIP: 0060:[<b0282dc4>] Not tainted VLI
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010096 (2.6.16-rc4-750-0a #1)
eax: 00000000 ebx: b1950f94 ecx: 00000040 edx: 00000000
esi: b195a6e0 edi: 00000000 ebp: 00000000 esp: b1950f74
ds: 007b es: 007b ss: 0068
Stack: <0>00000001 b195a6e0 00000000 b195a000 b195a000 00000000
00000000 b0283245
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000
00000000 00000000 00000000 b1950fd4 b195a000 00000286
b0282531 b1950000
Call Trace:
[<b0283245>]
[<b0282531>]
[<b0282582>]
[<b028253e>]
[<b0101af9>]
Code: ed fe ff ff 55 b9 0b 00 00 00 57 56 89 c6 53 89 d3 31 d2 83 ec
0c 89 df 89 d0 f3 ab 8b 76 4c b9 40 00 00 00 89 74 24 04 8b 7e 08
<8b> 57 20 8b 47 10 89 1c 24 e8 7c 8f f5 ff 8b 33 85 f6 75 29 8d
>>EIP; b0282dc4 <e752x_check_hub_interface+3c/a3> <=====
>>ebx; b1950f94 <pg0+1536f94/4fbe4400>
>>esi; b195a6e0 <pg0+15406e0/4fbe4400>
>>esp; b1950f74 <pg0+1536f74/4fbe4400>
Trace; b0283245 <e752x_get_error_info+f8/389>
Trace; b0282531 <edac_mc_handle_ue+1e7/20e>
Trace; b0282582 <edac_mc_handle_ue_no_info+2a/5c>
Trace; b028253e <edac_mc_handle_ue+1f4/20e>
Trace; b0101af9 <kernel_thread_helper+5/b>
This architecture has variable length instructions, decoding before eip
is unreliable, take these instructions with a pinch of salt.
Code; b0282d99 <e752x_check_hub_interface+11/a3>
00000000 <_EIP>:
Code; b0282d99 <e752x_check_hub_interface+11/a3>
0: ed in (%dx),%eax
Code; b0282d9a <e752x_check_hub_interface+12/a3>
1: fe (bad)
Code; b0282d9b <e752x_check_hub_interface+13/a3>
2: ff (bad)
Code; b0282d9c <e752x_check_hub_interface+14/a3>
3: ff 55 b9 call *0xffffffb9(%ebp)
Code; b0282d9f <e752x_check_hub_interface+17/a3>
6: 0b 00 or (%eax),%eax
Code; b0282da1 <e752x_check_hub_interface+19/a3>
8: 00 00 add %al,(%eax)
Code; b0282da3 <e752x_check_hub_interface+1b/a3>
a: 57 push %edi
Code; b0282da4 <e752x_check_hub_interface+1c/a3>
b: 56 push %esi
Code; b0282da5 <e752x_check_hub_interface+1d/a3>
c: 89 c6 mov %eax,%esi
Code; b0282da7 <e752x_check_hub_interface+1f/a3>
e: 53 push %ebx
Code; b0282da8 <e752x_check_hub_interface+20/a3>
f: 89 d3 mov %edx,%ebx
Code; b0282daa <e752x_check_hub_interface+22/a3>
11: 31 d2 xor %edx,%edx
Code; b0282dac <e752x_check_hub_interface+24/a3>
13: 83 ec 0c sub $0xc,%esp
Code; b0282daf <e752x_check_hub_interface+27/a3>
16: 89 df mov %ebx,%edi
Code; b0282db1 <e752x_check_hub_interface+29/a3>
18: 89 d0 mov %edx,%eax
Code; b0282db3 <e752x_check_hub_interface+2b/a3>
1a: f3 ab repz stos %eax,%es:(%edi)
Code; b0282db5 <e752x_check_hub_interface+2d/a3>
1c: 8b 76 4c mov 0x4c(%esi),%esi
Code; b0282db8 <e752x_check_hub_interface+30/a3>
1f: b9 40 00 00 00 mov $0x40,%ecx
Code; b0282dbd <e752x_check_hub_interface+35/a3>
24: 89 74 24 04 mov %esi,0x4(%esp)
Code; b0282dc1 <e752x_check_hub_interface+39/a3>
28: 8b 7e 08 mov 0x8(%esi),%edi
This decode from eip onwards should be reliable
Code; b0282dc4 <e752x_check_hub_interface+3c/a3>
00000000 <_EIP>:
Code; b0282dc4 <e752x_check_hub_interface+3c/a3> <=====
0: 8b 57 20 mov 0x20(%edi),%edx <=====
Code; b0282dc7 <e752x_check_hub_interface+3f/a3>
3: 8b 47 10 mov 0x10(%edi),%eax
Code; b0282dca <e752x_check_hub_interface+42/a3>
6: 89 1c 24 mov %ebx,(%esp)
Code; b0282dcd <e752x_check_hub_interface+45/a3>
9: e8 7c 8f f5 ff call fff58f8a <_EIP+0xfff58f8a>
Code; b0282dd2 <e752x_check_hub_interface+4a/a3>
e: 8b 33 mov (%ebx),%esi
Code; b0282dd4 <e752x_check_hub_interface+4c/a3>
10: 85 f6 test %esi,%esi
Code; b0282dd6 <e752x_check_hub_interface+4e/a3>
12: 75 29 jne 3d <_EIP+0x3d>
Code; b0282dd8 <e752x_check_hub_interface+50/a3>
14: 8d .byte 0x8d
e1000: eth0: e1000_watchdog_task: NIC Link is Up 100 Mbps Full Duplex
I have sometimes seen the oops occur in e752x_get_error_info as well.
--
Mark Rustad, MRustad@mac.com
next prev parent reply other threads:[~2006-02-22 22:03 UTC|newest]
Thread overview: 85+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-17 22:45 Linux 2.6.16-rc4 Linus Torvalds
2006-02-17 23:14 ` 2.6.16-rc4: known regressions Adrian Bunk
2006-02-19 11:06 ` Pekka Enberg
2006-02-19 14:54 ` Adrian Bunk
2006-02-19 17:50 ` Pekka Enberg
2006-02-19 21:14 ` Pekka Enberg
2006-02-20 1:02 ` Greg KH
2006-02-20 7:08 ` Pekka J Enberg
2006-02-21 22:51 ` Pekka Enberg
2006-02-21 22:57 ` Kay Sievers
2006-02-21 23:33 ` Andrew Morton
2006-02-22 0:04 ` Kay Sievers
2006-02-22 0:15 ` Mark Lord
2006-02-22 0:21 ` Andrew Morton
2006-02-22 0:34 ` Linus Torvalds
2006-02-22 0:46 ` Con Kolivas
2006-02-22 1:06 ` Linus Torvalds
2006-02-22 11:21 ` Theodore Ts'o
2006-02-22 14:25 ` uswsusp & initrd -- was " Pavel Machek
2006-02-22 15:48 ` Joel Becker
2006-02-22 16:25 ` Theodore Ts'o
2006-02-22 17:33 ` Gabor Gombas
2006-02-22 17:57 ` Linus Torvalds
2006-02-22 18:37 ` Christian Trefzer
2006-02-22 18:59 ` Joel Becker
2006-02-22 19:18 ` Greg KH
2006-02-22 19:29 ` Arjan van de Ven
2006-02-22 19:40 ` Greg KH
2006-02-22 20:45 ` Jens Axboe
2006-02-22 22:51 ` Greg KH
2006-02-23 6:39 ` Jens Axboe
2006-02-23 17:29 ` Martin Bligh
2006-02-23 17:52 ` Greg KH
2006-02-23 18:01 ` Martin Bligh
2006-02-23 18:04 ` Arjan van de Ven
2006-02-23 20:26 ` Benjamin LaHaise
2006-02-24 23:42 ` Eric W. Biederman
2006-02-22 19:39 ` Linus Torvalds
2006-02-22 19:54 ` Andrew Morton
2006-02-22 20:02 ` Arjan van de Ven
2006-02-22 20:12 ` Linus Torvalds
2006-02-22 20:44 ` Andrew Morton
2006-02-22 20:26 ` Greg KH
2006-02-23 5:28 ` Jody McIntyre
2006-02-22 20:57 ` Diego Calleja
2006-02-22 21:19 ` Russell King
2006-02-22 21:30 ` Greg KH
2006-02-22 20:47 ` Bryan O'Sullivan
2006-02-22 19:07 ` Greg KH
2006-02-22 17:06 ` Matthias Andree
2006-02-23 12:36 ` Paulo Marques
2006-02-22 10:49 ` Diego Calleja
2006-02-22 7:06 ` Pekka J Enberg
2006-02-22 15:27 ` Kay Sievers
2006-02-22 15:44 ` Linus Torvalds
2006-02-22 16:03 ` Arjan van de Ven
2006-02-22 16:11 ` Christoph Hellwig
2006-02-22 17:17 ` sysfs regressions (was: 2.6.16-rc4: known regressions) Matthias Andree
2006-02-22 17:47 ` Greg KH
2006-02-22 16:18 ` 2.6.16-rc4: known regressions David Zeuthen
2006-02-22 16:35 ` Christoph Hellwig
2006-02-22 16:46 ` David Zeuthen
2006-02-22 16:51 ` Christoph Hellwig
2006-02-22 17:08 ` Linus Torvalds
2006-02-22 17:31 ` Linus Torvalds
2006-02-22 18:04 ` Al Viro
2006-02-23 3:01 ` John Stoffel
2006-02-22 17:51 ` Al Viro
2006-02-22 17:55 ` Christoph Hellwig
2006-02-22 18:10 ` Al Viro
2006-02-22 19:25 ` David Zeuthen
2006-02-22 17:10 ` Al Viro
2006-02-22 17:10 ` grundig
2006-02-22 17:14 ` Martin Bligh
2006-02-23 4:17 ` Theodore Ts'o
2006-02-22 18:10 ` Pekka Enberg
2006-02-22 8:28 ` Arjan van de Ven
2006-02-17 23:27 ` Linux 2.6.16-rc4 Nigel Cunningham
2006-02-18 8:59 ` Edmondo Tommasina
2006-02-18 9:19 ` Gene Heskett
2006-02-18 10:20 ` Con Kolivas
2006-02-18 11:26 ` Gene Heskett
2006-02-18 16:04 ` Jean Delvare
2006-02-22 22:02 ` Mark Rustad [this message]
2006-02-24 11:09 ` Linux 2.6.16-rc4 edac oops Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6B9658D7-1522-4936-9492-FED2DFD38D2A@mac.com \
--to=mrustad@mac.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®