[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: sym53x8xx.c



You're not the only one. I'm seeing the same thing on 2.2.19 in the same
place.
Here's the oops, which I forced. 

 
Scheduling in interrupt
Unable to handle kernel paging request at virtual address
0000000000000000
CPU 0 top(695): Oops 1
pc = [<fffffc000032281c>]  ra = [<fffffc0000322814>]  ps = 0000
v0 = 0000000000000018  t0 = 0000000000000001  t1 = 0000000000000020
t2 = fffffd01fc000000  t3 = 000000000000000d  t4 = 0000000000000000
t5 = 00000000000003f8  t6 = 00000000000f3ffd  t7 = fffffc003cc7c000
s0 = fffffc003cc7c000  s1 = 0000000000000007  s2 = fffffc0000563e98
s3 = 0000000000000000  s4 = fffffc003cc7c000  s5 = fffffc003cc7c600
s6 = fffffc003cc7f808  a0 = fffffc0000563f40  a1 = 0000000000000021
a2 = 0000000000000018  a3 = 0000000000000008  a4 = fffffc0000532000
a5 = fffffc0000564dec  t8 = fffffc00005484e8  t9 = 0000000000000018
t10= 0000000000004240  t11= fffffc0000516f78  pv = fffffc000031df20
at = 000000000000000d  gp = fffffc000055bef0  sp = fffffc003cc7f808
Code:
 c3fffee3  br .-1136
 a61dcd98  ldq a0,-12904(gp)
 a77da278  ldq pv,-23944(gp)
 6b5b52b3  jsr ra,(pv)
 27ba0024  ldah gp,36(ra)
 23bd96dc  lda gp,-26916(gp)
*b3ff0000  stl zero,0(zero)
 45ef041e  or s6,s6,sp
Trace: 32da20 311970 489a58 31f2c4 3105fc 489a58 48825c 31df20 488268
489a58
486660 48b208 317214 31cd2c 3174f8 310d30 456a50 456024 31dc80 456034
323e60
455ea0 32ef4c 310ed4 382728 31df20 38270c 3501c8 383114 38324c 344dd8
310d18
 ...
die_if_kernel recursion detected.
read_write.c:41 spinlock stuck in bonnie++ at fffffc0000344b98(1) owner
top at fffffc0000344cf8(0) read_write.c:41
...
...


Which leads back to the schedule() function in kernel/sched.c ... Falls
all the way through to the last case which explictly sets address 0 to
zero.

Add this code in place of the assert in the symbios file so force an
oops.

/* assert(k != -1); */
if (!k != -1) {
	void *lr = __builtin_return_address(0);
        printk(KERN_CRIT "kernel abort from %p!  BOMBED AGAIN\n",lr);
        panic("K == -1, FAIL");
}


Also. Is your machine SMP? If so is your RTC disabled? 
I suspect this case occurs when the SCSI bus is saturated and a reset
is then  produced. Actually one happend on the machine as I was
unzipping 
the 2.4.6 kernel but it did not get to my panic code... Could be a
timing
issue... 

Peter

Michael Stroucken wrote:
> 
>         I can consistently cause a kernel panic on my box with a 53c875
> based Tekram card running 2.4.6 now. This card has a hard drive and a cd
> burner attached.
> 
>         Whenever I do a full blank of a disk, I get the following panic:-
> 
> sym53c8xx-abort: pid=0 serial_number=39514 serial_number_at_timeout=39514
> kernel panic: assertion "k"!=-1 failed: file "sym53c8xx.c" line 10170
> In interrupt handler - not syncing
> 
>         Anyone else have this problem?
> 
> Greetings,
> Michael.
> 
> "I'm not just a server, but I'm also a client."         Debian GNU/Linux
> Michael Stroucken       stroucki@debian.org      Is your penguin 64 bit?
> 
> --
> To UNSUBSCRIBE, email to debian-alpha-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

-- 
Peter Petrakis
Customer Support Engineer
API Networks
www.api-networks.com



Reply to: