Oops in iput

Oops in iput

[Florian Lohoff]

Hi,
oops in iput - Kernel 2.2.19/i386 + ide-udma patches + ext3 patches (0.0.7a)

Intel BX chipset, SCSI Disks Symbios chipset - The crashing process
is the master process of "postfix" an MTA.

Just before the crash all processes on that machine started to segfault
in nameserver resolution (remote dns server) and after 2-3 minutes
this oops happened.



ksymoops 2.3.4 on i686 2.2.19.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.2.19/ (default)
     -m /boot/System.map-2.2.19 (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.

Unable to handle kernel paging request at virtual address 4ed90398
current->tss.cr3 = 00101000, %cr3 = 00101000
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0010:[<c0133ca7>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010246
eax: 4ed90330   ebx: 00000000   ecx: 00000000   edx: c01eef0c
esi: 4ed90330   edi: ce27ed00   ebp: 00000002   esp: cf04ddac
ds: 0018   es: 0018   ss: 0018
Process master (pid: 297, process nr: 31, stackpage=cf04d000)
Stack: cf1859a0 00000001 cef7db18 cef7db18 cf1859a0 c015882f 4ed90330 00000000 
       ce27ec80 00000002 ced90330 ced90330 ce27ed00 00000002 ceadc0c0 00000000 
       cfce5860 c0158be3 ced903e0 ceeda140 00000000 00000002 ceeda140 ced90330 
Call Trace: [<c015882f>] [<c0158be3>] [<c011b26c>] [<c01262bd>] [<c011d2b5>] [<c012745c>] [<c0127453>] 
       [<c01139bb>] [<c012634b>] [<c011073e>] [<c0113958>] [<c01184f4>] [<c011847d>] [<c0109fbb>] [<c01111b1>] 
       [<c0109583>] [<c010a100>] 
Code: 8b 46 68 85 c0 74 09 8b 40 18 85 c0 74 02 89 c3 85 db 74 10 

>>EIP; c0133ca7 <iput+13/228>   <=====
Trace; c015882f <sock_release+57/60>
Trace; c0158be3 <sock_close+3f/4c>
Trace; c011b26c <clear_page_tables+ac/b4>
Trace; c01262bd <__fput+25/54>
Trace; c011d2b5 <exit_mmap+115/120>
Trace; c012745c <fput+20/54>
Trace; c0127453 <fput+17/54>
Trace; c01139bb <mmput+3f/48>
Trace; c012634b <filp_close+5f/6c>
Trace; c011073e <send_sig_info+182/2c0>
Trace; c0113958 <mm_release+10/34>
Trace; c01184f4 <do_exit+140/2a0>
Trace; c011847d <do_exit+c9/2a0>
Trace; c0109fbb <do_signal+21f/298>
Trace; c01111b1 <sys_kill+61/70>
Trace; c0109583 <sys_sigreturn+b7/e8>
Trace; c010a100 <signal_return+14/18>
Code;  c0133ca7 <iput+13/228>
00000000 <_EIP>:
Code;  c0133ca7 <iput+13/228>   <=====
   0:   8b 46 68                  mov    0x68(%esi),%eax   <=====
Code;  c0133caa <iput+16/228>
   3:   85 c0                     test   %eax,%eax
Code;  c0133cac <iput+18/228>
   5:   74 09                     je     10 <_EIP+0x10> c0133cb7 <iput+23/228>
Code;  c0133cae <iput+1a/228>
   7:   8b 40 18                  mov    0x18(%eax),%eax
Code;  c0133cb1 <iput+1d/228>
   a:   85 c0                     test   %eax,%eax
Code;  c0133cb3 <iput+1f/228>
   c:   74 02                     je     10 <_EIP+0x10> c0133cb7 <iput+23/228>
Code;  c0133cb5 <iput+21/228>
   e:   89 c3                     mov    %eax,%ebx
Code;  c0133cb7 <iput+23/228>
  10:   85 db                     test   %ebx,%ebx
Code;  c0133cb9 <iput+25/228>
  12:   74 10                     je     24 <_EIP+0x24> c0133ccb <iput+37/228>


1 warning issued.  Results may not be reliable.
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

Re: Oops in iput

[Stephen C. Tweedie]

Hi,

On Mon, Jun 25, 2001 at 08:16:12PM +0200, Florian Lohoff wrote:
> 
> oops in iput - Kernel 2.2.19/i386 + ide-udma patches + ext3 patches (0.0.7a)

The ide-udma patches for 2.2 haven't had nearly the testing of the 2.4
ones, and simply can't be trusted as a baseline for debugging other
code.  Can you reproduce this problem without them applied?  The oops
here is a networking oops on the face of it, and I wouldn't expect to
see that on 2.2 unless something was corrupting memory.

Cheers,
 Stephen

Re: Oops in iput

[Ville Herva]

On Mon, Jun 25, 2001 at 07:42:13PM +0100, you [Stephen C. Tweedie] claimed:
> Hi,
> 
> On Mon, Jun 25, 2001 at 08:16:12PM +0200, Florian Lohoff wrote:
> > 
> > oops in iput - Kernel 2.2.19/i386 + ide-udma patches + ext3 patches (0.0.7a)
> 
> The ide-udma patches for 2.2 haven't had nearly the testing of the 2.4
> ones, and simply can't be trusted as a baseline for debugging other
> code.  Can you reproduce this problem without them applied?  The oops
> here is a networking oops on the face of it, and I wouldn't expect to
> see that on 2.2 unless something was corrupting memory.

Well, I for one use the 2.2 ide patches extensively (on almost all of my
machines, including a heavy-duty backup server), and haven't seen any
problems whatsoever. I see _much_ more problems with scsi (aic7xxx), for
example.

I don't mean to say the ide patches are 100% bug free, but I wouldn't
consider them as the prime suspect for an oops that happened elsewhere
either. It could be hw or any other part of kernel just as well... What
about memtest86?


-- v --

v@iki.fi

Re: Oops in iput

[Stephen C. Tweedie]

Hi,

On Tue, Jun 26, 2001 at 11:09:33AM +0300, Ville Herva wrote:

> Well, I for one use the 2.2 ide patches extensively (on almost all of my
> machines, including a heavy-duty backup server)

It is highly hardware-dependent.  A huge amount of effort was spent
early in 2.4 getting blacklists and hardware tweaks right to work
around problems with specific chipsets with ide udma.  Just because it
works for one person doesn't give you any confidence that it won't
trash data for somebody else.

Cheers,
 Stephen

Re: Oops in iput

[Ville Herva]

On Tue, Jun 26, 2001 at 11:56:51AM +0100, you [Stephen C. Tweedie] claimed:
> Hi,
> 
> On Tue, Jun 26, 2001 at 11:09:33AM +0300, Ville Herva wrote:
> 
> > Well, I for one use the 2.2 ide patches extensively (on almost all of my
> > machines, including a heavy-duty backup server)
> 
> It is highly hardware-dependent.  A huge amount of effort was spent
> early in 2.4 getting blacklists and hardware tweaks right to work
> around problems with specific chipsets with ide udma.  Just because it
> works for one person doesn't give you any confidence that it won't
> trash data for somebody else.

Well, the report said 'Intel BX chipset' - that's as solid as chipsets get
(to loosely quote Alan). Almost all of my boxes are BX (one has HPT366 in
addition, and another one was changed to Via686a recently), and I imagine
that BX gets most testing since it is very common chipset. Moreover, it only
does UDMA33, not any fancy 66 or 100 stuff (although I haven't had problems
with those either on HPT366, HPT370 nor 686a).

As said, it could be the ide patch, but surely there are other just as
likely suspects as well.


-- v --

v@iki.fi

Re: Oops in iput

[Florian Lohoff]

On Tue, Jun 26, 2001 at 11:09:33AM +0300, Ville Herva wrote:
> Well, I for one use the 2.2 ide patches extensively (on almost all of my
> machines, including a heavy-duty backup server), and haven't seen any
> problems whatsoever. I see _much_ more problems with scsi (aic7xxx), for
> example.

I have been using the udma ide patches for a long time and as long as
you stay away from known buggy drives controllers you are fine.

BTW: The machine i reported the bug for is mostly running on SCSI - Only
/var/tmp is an large IDE drive.
 
> I don't mean to say the ide patches are 100% bug free, but I wouldn't
> consider them as the prime suspect for an oops that happened elsewhere
> either. It could be hw or any other part of kernel just as well... What
> about memtest86?

I'll try 

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?