From: Camm Maguire <camm@enhanced.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: linux-kernel@vger.kernel.org, nfs-devel@linux.kernel.org,
autofs@linux.kernel.org, hpa@zytor.com, gam3@acm.org
Subject: Re: PROBLEM: 2.2.18 oops leaves umount hung in disk sleep
Date: 27 Mar 2001 10:15:11 -0500 [thread overview]
Message-ID: <54puf35jls.fsf@intech19.enhanced.com> (raw)
In-Reply-To: <E14g8eP-0006k5-00@intech19.enhanced.com> <shs1yrpabky.fsf@charged.uio.no> <54hf0l8ug1.fsf@intech19.enhanced.com> <shspuf98nhy.fsf@charged.uio.no> <541yrpgsze.fsf@intech19.enhanced.com> <shs7l1gae5a.fsf@charged.uio.no>
In-Reply-To: Trond Myklebust's message of "23 Mar 2001 13:00:33 +0100"
Hello again! We're in luck! The oops happened again, and this time,
the full oops dump appeared on the screen, which I have copied below:
=============================================================================
Unable to handle kernel paging request at virtual address 6e617274
current->tss.c3 = 03d06000, %cr3 = 03d06000
*pde = 00000000
Oops = 0
CPU = 0
EIP = 0010:[<c012facf>]
EFLAGS = 00010a87
eax = 00000000 ebx = 6e617274 ecx = 6e617274 edx = 00000006
esi = 00000006 edi = c3bda800 ebp = 00000006 esp = c2381f5c
ds = 0018 es = 0018 ss = 0018
Process umount (pid:6942, process nr:58,stackpage = c2381000)
Stack: fffffffe c01281a2 c3bda800 00000006 c25db80c 00000006 fffffffa c01282e8
00000006 00000000 00000000 00000000 08050006 c0b176e0 08054208 00000000
c01283e3 00000006 00000000 c2380000 08054209 0804fa20 c01283fc 08054208
Call Trace: [<c01281a2>][<c01282e8>][<c01283e3>][<c01283fc>][<c01094fc>]
code: 8b 1b 39 79 34 75 ef 8b 41 04 8b 11 89 42 04 89 10 a1 e4 4d
=============================================================================
and through ksymoops:
=============================================================================
intech9# ksymoops</home/camm/oops
ksymoops</home/camm/oops
ksymoops 2.3.4 on i586 2.2.18-i586tsc. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.2.18-i586tsc/ (default)
-m /boot/System.map-2.2.18-i586tsc (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.
Warning (compare_maps): ksyms_base symbol module_list_R__ver_module_list not found in System.map. Ignoring ksyms_base entry
Unable to handle kernel paging request at virtual address 6e617274
current->tss.c3 = 03d06000, %cr3 = 03d06000
*pde = 00000000
Stack: fffffffe c01281a2 c3bda800 00000006 c25db80c 00000006 fffffffa c01282e8
00000006 00000000 00000000 00000000 08050006 c0b176e0 08054208 00000000
c01283e3 00000006 00000000 c2380000 08054209 0804fa20 c01283fc 08054208
Call Trace: [<c01281a2>][<c01282e8>][<c01283e3>][<c01283fc>][<c01094fc>]
code: 8b 1b 39 79 34 75 ef 8b 41 04 8b 11 89 42 04 89 10 a1 e4 4d
Using defaults from ksymoops -t elf32-i386 -a i386
Trace; c01281a2 <do_umount+5a/144>
Trace; c01282e8 <umount_dev+5c/ac>
Trace; c01283e3 <sys_umount+ab/b8>
Trace; c01283fc <sys_oldumount+c/10>
Trace; c01094fc <system_call+34/38>
Code; 00000000 Before first symbol
00000000 <_EIP>:
Code; 00000000 Before first symbol
0: 8b 1b mov (%ebx),%ebx
Code; 00000002 Before first symbol
2: 39 79 34 cmp %edi,0x34(%ecx)
Code; 00000005 Before first symbol
5: 75 ef jne fffffff6 <_EIP+0xfffffff6> fffffff6 <END_OF_CODE+3b764797/????>
Code; 00000007 Before first symbol
7: 8b 41 04 mov 0x4(%ecx),%eax
Code; 0000000a Before first symbol
a: 8b 11 mov (%ecx),%edx
Code; 0000000c Before first symbol
c: 89 42 04 mov %eax,0x4(%edx)
Code; 0000000f Before first symbol
f: 89 10 mov %edx,(%eax)
Code; 00000011 Before first symbol
11: a1 e4 4d 00 00 mov 0x4de4,%eax
2 warnings issued. Results may not be reliable.
=============================================================================
As before, the oops was truncated in the log.
I received two eth0 (ne2k-pci,using 8390) errors before this oops:
eth0: next frame inconsistency, 0xf2
eth0: next frame inconsistency, 0xb8
And then one eth0 error after the oops before the machine died:
eth0: bogus packet: status=0x80 nxpg=0x7b size=1518
I will be trying to recompile with gcc272 to see if anything changes.
In the meantime, I'd greatly appreciate any insights!
Take care,
Trond Myklebust <trond.myklebust@fys.uio.no> writes:
> >>>>> " " == Camm Maguire <camm@enhanced.com> writes:
>
> > Greetings! Here are the contiguous lines from kern.log: Mar 21
> > 01:14:47 intech9 kernel: eth0: bogus packet: status=0x80
> > nxpg=0x57 size=1270 Mar 21 01:14:49 intech9 kernel: Unable to
> > handle kernel NULL pointer dereference at virtual address
> > 00000000 Mar 21 01:14:49 intech9 kernel: current->tss.cr3 =
> > 02872000, %%cr3 = 02872000 Mar 21 01:14:49 intech9 kernel: *pde
> > = 00000000 Mar 21 01:14:49 intech9 kernel: Oops: 0000 Mar 21
> > 01:14:49 intech9 kernel: CPU: 0 Mar 22 12:30:08 intech9 kernel:
> > klogd 1.3-3#33.1, log source = /proc/kmsg started.
>
> > Why would this have not been included, would you happen to
> > know? In any case, I understand that its pretty much
>
> I've no idea why it wasn't logged. Did you possibly reboot without
> syncing the disk?
>
> > impossible to debug now, right? dmesg wrapped around by the
> > time I got to it (I seem to be having a lot of ethernet bogus
> > packet messages, as shown above. I've chalked this up to the
> > heavy traffic during the amanda backup, but maybe something is
> > wrong here too/instead?)
>
> Have you tried to use an older version of gcc? AFAIK gcc-2.95.2 has a
> lot of bugs that are known to cause problems with the kernel. If you
> are having additional problems such as the bogus ethernet packets,
> then it might be worth your while to experiment a bit to see whether
> this might be some corruption problem.
>
> Cheers,
> Trond
>
>
--
Camm Maguire camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
next prev parent reply other threads:[~2001-03-27 15:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-22 17:13 PROBLEM: 2.2.18 oops leaves umount hung in disk sleep Camm Maguire
2001-03-22 17:44 ` 4GB -> no boot Giuliano Pochini
2001-03-22 18:43 ` PROBLEM: 2.2.18 oops leaves umount hung in disk sleep Trond Myklebust
2001-03-22 19:39 ` Camm Maguire
2001-03-22 22:09 ` Trond Myklebust
2001-03-23 1:43 ` Camm Maguire
[not found] ` <shs7l1gae5a.fsf@charged.uio.no>
2001-03-27 15:15 ` Camm Maguire [this message]
2001-03-28 23:19 ` Camm Maguire
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=54puf35jls.fsf@intech19.enhanced.com \
--to=camm@enhanced.com \
--cc=autofs@linux.kernel.org \
--cc=gam3@acm.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nfs-devel@linux.kernel.org \
--cc=trond.myklebust@fys.uio.no \
/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