2.4.4 del_timer_sync oops in schedule_timeout

2.4.4 del_timer_sync oops in schedule_timeout

[Jacob Luna Lundberg]

This is 2.4.4 with the aic7xxx driver version 6.1.13 dropped in.
The oops got eaten by klogd, my apologies, but it seems sane even so.
I haven't tried newer -ac or -pre kernels so I'm sure it's probably
already fixed there but just in case it isn't...


kdm[350]: Server for display :0 terminated unexpectedly: 2816
Unable to handle kernel paging request at virtual address 78626970
printing eip:
c011bf13
*pde = 00000000
Oops: 0002
CPU:    0
EIP:    0010:[del_timer_sync+47/132]
EFLAGS: 00010006
eax: 732e7872   ebx: 00000246   ecx: c651ff28   edx: 7862696c
esi: 00000000   edi: 00100000   ebp: c651df3c   esp: c651df0c
ds: 0018   es: 0018   ss: 0018
Process XFree86 (pid: 356, stackpage=c651d000)
Stack: c651ff28 0007edbb c0112b54 c651ff28 c651df28 00000000 c3b45260 c02ec12c
       c02ec12c 0007edbb c651c000 c0112a80 c651df70 c0140b7c 00000008 00000020
       c7aea140 00000000 00000304 c651c000 00002d24 00000015 00000000 00000000
Call Trace: [schedule_timeout+120/144] [process_timeout+0/92]
[do_select+456/512] [sys_select+816/1136] [system_call+55/64]
Code: 89 42 04 89 10 b8 01 00 00 00 01 c6 a1 68 20 30 c0 c7 41 04

Re: 2.4.4 del_timer_sync oops in schedule_timeout

[Ingo Molnar]

On Sat, 19 May 2001, Jacob Luna Lundberg wrote:

> This is 2.4.4 with the aic7xxx driver version 6.1.13 dropped in.

> Unable to handle kernel paging request at virtual address 78626970

this appears to be some sort of DMA-corruption or other memory scribble
problem. hexa 78626970 is ASCII "pibx", which shows in the direction of
some sort of disk-related DMA corruption.

we havent had any similar crash in del_timer_sync() for ages.

	Ingo

Re: 2.4.4 del_timer_sync oops in schedule_timeout

[Jacob Luna Lundberg]

On Sun, 20 May 2001, Ingo Molnar wrote:
> > Unable to handle kernel paging request at virtual address 78626970
> this appears to be some sort of DMA-corruption or other memory scribble
> problem. hexa 78626970 is ASCII "pibx", which shows in the direction of
> some sort of disk-related DMA corruption.
> we havent had any similar crash in del_timer_sync() for ages.

Ahh.  Thanks then, I'll go look hard at the disk in that box.  :)

-Jacob

-- 

Only when work uses up all energy and people are too tired to
enjoy the persuit of their passions are they ready to be reduced
to the passively receptive state suitable for television.

 - ``The Hacker Ethic'' by Pekka Himanen

Re: 2.4.4 del_timer_sync oops in schedule_timeout

[Ingo Molnar]

On Sun, 20 May 2001, Jacob Luna Lundberg wrote:

> > > Unable to handle kernel paging request at virtual address 78626970
> > this appears to be some sort of DMA-corruption or other memory scribble
> > problem. hexa 78626970 is ASCII "pibx", which shows in the direction of
> > some sort of disk-related DMA corruption.
> > we havent had any similar crash in del_timer_sync() for ages.
>
> Ahh.  Thanks then, I'll go look hard at the disk in that box.  :)

not necesserily the disk. it can be any sort of overheating or other
thermal noise (unlikely), or SCSI/IDE cable problem (likely), or driver
problem (likely too). Disk faults typically show very different symptoms.

	Ingo

Re: 2.4.4 del_timer_sync oops in schedule_timeout

[Andrew Morton]

Ingo Molnar wrote:
> 
> On Sat, 19 May 2001, Jacob Luna Lundberg wrote:
> 
> > This is 2.4.4 with the aic7xxx driver version 6.1.13 dropped in.
> 
> > Unable to handle kernel paging request at virtual address 78626970
> 
> this appears to be some sort of DMA-corruption or other memory scribble
> problem. hexa 78626970 is ASCII "pibx", which shows in the direction of
> some sort of disk-related DMA corruption.

It could be timer-list corruption.  Someone released some memory
which had a live timer in it.  The memory got recycled and then
the timer list traversal fell over it.

There was a convincing report of this a few weeks back on a
system which didn't have any unusual drivers in it.  It was
inconclusive.  That system was SMP, so it could have been a
timer deletion race.

This bug is so damn hard to track down that it may be worth
putting some special walk-the-timer-lists code inside
kfree()+SLAB_POISON.

-

Re: 2.4.4 del_timer_sync oops in schedule_timeout

[Jacob Luna Lundberg]

On Mon, 21 May 2001, Andrew Morton wrote:
> It could be timer-list corruption.  Someone released some memory
> which had a live timer in it.  The memory got recycled and then
> the timer list traversal fell over it.

Well I do have another oops now (artsd this time).  Once again it's in
del_timer_sync in 2.4.4, same computer after a reboot, same kernel.  It is
a UP system (SMP kernel) btw.

Could it be that the aic7xxx driver is improperly destroying a timer?  I
am having some problems with a scanner attached to the SCSI card in
question that usually result in the driver setting the scanner inactive
until I reset the scanner and rmmod/insmod the driver again.

Unable to handle kernel paging request at virtual address 2d5ca71f
 printing eip:
c011bf13
*pde  = 00000000
Oops: 0002
CPU:    0
EIP:    0010:[del_timer_sync+47/132]
EFLAGS: 00013006
eax: a2e17a6a   ebx: 00003246   ecx: c4047f28   edx: 2d5ca71b
esi: 00000000   edi: 00000010   ebp: c4045f3c   esp: c4045f0c
ds: 0018   es: 0018   ss: 0018
Process artsd (pid: 2873, stackpage=c4045000)
Stack: c4047f28 0061afd0 c0112b54 c4047f28 c4045f28 00000000 c78143e0 00000000
       00000000 0061afd0 c4044000 c0112a80 c4045f70 c0140b7c 00000001 00000004
       c305c9d8 00000000 00000304 c4044000 00000014 00000005 00000000 00000000
Call Trace: [schedule_timeout+120/144] [process_timeout+0/92]
[do_select+456/512] [sys_select+816/1136] [system_call+55/64]

Code: 89 42 04 89 10 b8 01 00 00 00 01 c6 a1 68 20 30 c0 c7 41 04

-Jacob

-- 

At a global level, the most developed countries "stabilize" the wars
among the outcasts depending on how important each conflict is to the
global economy.

 - ``The Hacker Ethic'' by Pekka Himanen