From: Anders Karlsson <anders@trudheim.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: kernel oops
Date: 07 Jul 2003 14:56:45 +0100 [thread overview]
Message-ID: <1057586205.2039.3.camel@tor.trudheim.com> (raw)
In-Reply-To: <1057585054.2743.40.camel@dhcp22.swansea.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 6550 bytes --]
On Mon, 2003-07-07 at 14:37, Alan Cox wrote:
> On Llu, 2003-07-07 at 14:32, Anders Karlsson wrote:
> > The running kernel is 2.4.21-rc7-ac1, I was trying to compile
> > 2.4.22-pre3 with the freeswan patches applied. I can try and
> > compile the plain 2.4.22-pre3 a few times to provoke an oops.
> > The system is presently still running 2.4.21-rc7-ac1.
>
> Ah I misunderstood - is the 2.4.21-rc7-ac1 with or without
> freeswan patches ?
2.4.21-rc7-ac1 only has the CPUFreq patches applied, courtesy of Bill
Nottingham. There is no FreeS/WAN patches applied to it.
I have just run another compile of 2.4.22-pre3, this time nothing else
applied. The oopses is as follows.
ksymoops 2.4.8 on i686 2.4.21-rc7-ac1. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.21-rc7-ac1/ (default)
-m /boot/System.map-2.4.21-rc7-ac1 (default)
Warning: You did not tell me where to find symbol information. I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.
kernel BUG at page_alloc.c:231!
invalid operand: 0000
CPU: 0
EIP: 0010:[<c0139296>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202
eax: 01000072 ebx: c16cbc30 ecx: 000243eb edx: 00001000
esi: c02f3e70 edi: c02f3e84 ebp: c02f3e70 esp: e42f1e74
ds: 0018 es: 0018 ss: 0018
Process cc1 (pid: 10269, stackpage=e42f1000)
Stack: 00001000 00000000 000233eb 00000286 00000000 c02f3e70 c02f3ff4
000001ff
00000000 000001d2 c01394e2 d2de7280 c02f3e70 c02f3ff0 d22f294c
00000000
c10030e0 00104025 d2dd9580 c012e250 c10030e0 00000000 00001000
410f1000
Call Trace: [<c01394e2>] [<c012e250>] [<c012ebf5>] [<c012fb49>]
[<c011a0d4>]
[<c010ebd0>] [<c0119f94>] [<c0108e78>]
Code: 0f 0b e7 00 f0 39 2b c0 8b 43 18 a9 80 00 00 00 74 08 0f 0b
>>EIP; c0139296 <rmqueue+1f9/21d> <=====
>>ebx; c16cbc30 <_end+132396c/3146ad9c>
>>esi; c02f3e70 <contig_page_data+b0/340>
>>edi; c02f3e84 <contig_page_data+c4/340>
>>ebp; c02f3e70 <contig_page_data+b0/340>
>>esp; e42f1e74 <_end+23f49bb0/3146ad9c>
Trace; c01394e2 <__alloc_pages+3f/180>
Trace; c012e250 <do_wp_page+51/25e>
Trace; c012ebf5 <handle_mm_fault+122/124>
Trace; c012fb49 <get_unmapped_area+86/115>
Trace; c011a0d4 <do_page_fault+140/472>
Trace; c010ebd0 <old_mmap+de/11d>
Trace; c0119f94 <do_page_fault+0/472>
Trace; c0108e78 <error_code+34/3c>
Code; c0139296 <rmqueue+1f9/21d>
00000000 <_EIP>:
Code; c0139296 <rmqueue+1f9/21d> <=====
0: 0f 0b ud2a <=====
Code; c0139298 <rmqueue+1fb/21d>
2: e7 00 out %eax,$0x0
Code; c013929a <rmqueue+1fd/21d>
4: f0 39 2b lock cmp %ebp,(%ebx)
Code; c013929d <rmqueue+200/21d>
7: c0 8b 43 18 a9 80 00 rorb $0x0,0x80a91843(%ebx)
Code; c01392a4 <rmqueue+207/21d>
e: 00 00 add %al,(%eax)
Code; c01392a6 <rmqueue+209/21d>
10: 74 08 je 1a <_EIP+0x1a>
Code; c01392a8 <rmqueue+20b/21d>
12: 0f 0b ud2a
kernel BUG at page_alloc.c:100!
invalid operand: 0000
CPU: 0
EIP: 0010:[<c0138e47>] Not tainted
EFLAGS: 00010206
eax: 0100003d ebx: c16cbcc0 ecx: 000000a3 edx: 00000000
esi: d22f7090 edi: 00000000 ebp: 00000010 esp: e42f1ca8
ds: 0018 es: 0018 ss: 0018
Process cc1 (pid: 10269, stackpage=e42f1000)
Stack: c02f3efc c1000020 c16a59b0 c02f3e70 c1030020 00000203 ffffffff
00010e8a
0000f000 d22f7090 00012000 00000010 c012f0a2 c16cbcc0 e42f1cec
c0127315
edb9f134 40415000 ea6e8404 40027000 00000000 c012d83a dce4b680
ea6e8400
Call Trace: [<c012f0a2>] [<c0127315>] [<c012d83a>] [<c01306e2>]
[<c011c692>]
[<c01215f4>] [<c0109572>] [<c010943b>] [<c01095d9>] [<c0139296>]
[<f1d8e857>]
[<f1d8db1d>] [<f1da2b06>] [<c0108e78>] [<c0139296>] [<c01394e2>]
[<c012e250>]
[<c012ebf5>] [<c012fb49>] [<c011a0d4>] [<c010ebd0>] [<c0119f94>]
[<c0108e78>]
Code: 0f 0b 64 00 f0 39 2b c0 8b 53 08 85 d2 74 08 0f 0b 66 00 f0
>>EIP; c0138e47 <__free_pages_ok+33/289> <=====
>>ebx; c16cbcc0 <_end+13239fc/3146ad9c>
>>esi; d22f7090 <_end+11f4edcc/3146ad9c>
>>esp; e42f1ca8 <_end+23f499e4/3146ad9c>
Trace; c012f0a2 <zap_pte_range+108/13e>
Trace; c0127315 <run_timer_list+137/15e>
Trace; c012d83a <zap_page_range+83/f9>
Trace; c01306e2 <exit_mmap+a5/17a>
Trace; c011c692 <mmput+45/96>
Trace; c01215f4 <do_exit+ca/262>
Trace; c0109572 <do_invalid_op+0/6e>
Trace; c010943b <do_divide_error+0/6e>
Trace; c01095d9 <do_invalid_op+67/6e>
Trace; c0139296 <rmqueue+1f9/21d>
Trace; f1d8e857 <[jbd]__journal_file_buffer+df/23c>
Trace; f1d8db1d <[jbd]journal_dirty_metadata+16f/222>
Trace; f1da2b06 <[ext3]ext3_do_update_inode+168/402>
Trace; c0108e78 <error_code+34/3c>
Trace; c0139296 <rmqueue+1f9/21d>
Trace; c01394e2 <__alloc_pages+3f/180>
Trace; c012e250 <do_wp_page+51/25e>
Trace; c012ebf5 <handle_mm_fault+122/124>
Trace; c012fb49 <get_unmapped_area+86/115>
Trace; c011a0d4 <do_page_fault+140/472>
Trace; c010ebd0 <old_mmap+de/11d>
Trace; c0119f94 <do_page_fault+0/472>
Trace; c0108e78 <error_code+34/3c>
Code; c0138e47 <__free_pages_ok+33/289>
00000000 <_EIP>:
Code; c0138e47 <__free_pages_ok+33/289> <=====
0: 0f 0b ud2a <=====
Code; c0138e49 <__free_pages_ok+35/289>
2: 64 fs
Code; c0138e4a <__free_pages_ok+36/289>
3: 00 f0 add %dh,%al
Code; c0138e4c <__free_pages_ok+38/289>
5: 39 2b cmp %ebp,(%ebx)
Code; c0138e4e <__free_pages_ok+3a/289>
7: c0 8b 53 08 85 d2 74 rorb $0x74,0xd2850853(%ebx)
Code; c0138e55 <__free_pages_ok+41/289>
e: 08 0f or %cl,(%edi)
Code; c0138e57 <__free_pages_ok+43/289>
10: 0b 66 00 or 0x0(%esi),%esp
Code; c0138e5a <__free_pages_ok+46/289>
13: f0 00 00 lock add %al,(%eax)
1 warning issued. Results may not be reliable.
If there is anything I can do to assist debugging, let me know.
--
Anders Karlsson <anders@trudheim.com>
Trudheim Technology Limited
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2003-07-07 13:42 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-07 12:53 kernel oops Anders Karlsson
2003-07-07 13:14 ` Alan Cox
2003-07-07 13:32 ` Anders Karlsson
2003-07-07 13:37 ` Alan Cox
2003-07-07 13:56 ` Anders Karlsson [this message]
2003-07-08 9:39 ` Marcelo Tosatti
[not found] ` <200307072009.50677.bernd-schubert@web.de>
2003-07-08 5:13 ` Anders Karlsson
-- strict thread matches above, loose matches on Subject: below --
2008-07-23 12:52 Andrei Popa
2008-07-23 17:11 ` Vegard Nossum
2008-08-18 16:33 ` Vegard Nossum
2008-08-18 16:39 ` Greg KH
[not found] <e8eb01770803120245x7690e6a9te8ad04296aa3fc4d@mail.gmail.com>
2008-03-12 9:49 ` Zbynek Drlik
2008-03-12 10:33 ` Al Viro
2008-03-12 13:12 ` Zbynek Drlik
2008-02-05 12:57 Andrej Hocevar
2008-02-06 17:55 ` Len Brown
2006-09-12 10:21 Kernel Oops Marcin Prączko
2006-09-13 3:43 ` Andrew Morton
2005-10-15 1:03 Marc Perkel
2005-10-15 1:21 ` Randy.Dunlap
2005-10-15 1:43 ` Marc Perkel
2005-10-15 1:52 ` Randy.Dunlap
2005-01-03 21:10 Kernel oops Marat BN
2005-01-05 10:13 ` Andrew Morton
2004-06-11 7:27 tmp
2004-05-24 20:19 tmp
2004-05-16 12:08 Kernel OOPS tmp
2004-05-16 23:27 ` Andrew Morton
2004-05-17 0:33 ` tmp
2004-03-09 22:13 Kernel oops Philipp Baer
2004-03-09 23:11 ` Andrew Morton
2004-03-12 7:46 ` Philipp Baer
2004-02-08 11:05 Kernel Oops Mathieu LESNIAK
2004-02-08 16:35 ` Greg KH
2004-02-09 7:06 ` Mathieu LESNIAK
2003-11-28 23:15 Kernel oops Ville Jutvik
2003-11-28 5:45 Anderson Levi
2003-08-09 12:39 kernel oops Jean-Yves LENHOF
2003-08-09 20:37 ` Jean-Yves LENHOF
2003-08-09 9:28 Jean-Yves LENHOF
2003-07-18 19:44 Kernel OOPS Robert Scussel
2003-07-18 21:31 ` Alan Cox
2003-05-31 1:32 kernel oops Nadeem Riaz
2003-03-26 15:52 Steve Terrell
2003-02-03 1:18 Kernel Oops Daniel Espinoza
2003-02-03 3:23 ` vishwas
2002-08-09 5:25 sanket rathi
2002-06-23 19:39 Dirk Schmidt
2002-06-10 8:46 kernel oops Robert Litwiniec
2002-02-26 18:26 Suporte RedeBonja
2002-02-27 13:35 ` Erik Mouw
2001-11-13 13:23 Kernel oops Anthony
2001-11-14 6:02 ` Thiago Rondon
2001-10-08 12:59 kernel oops Terry Kendal
2001-09-27 9:49 kewl
2001-06-01 15:13 Kernel oops David Harris
2001-06-01 15:12 David Harris
2001-04-19 18:32 kernel oops Ronald Bultje
2001-04-19 19:04 ` Alan Cox
2001-04-19 19:08 ` Ronald Bultje
2001-02-19 14:44 Kernel Oops Alberto Bertogli
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=1057586205.2039.3.camel@tor.trudheim.com \
--to=anders@trudheim.com \
--cc=alan@lxorguk.ukuu.org.uk \
--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