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:
- References:
- sym53x8xx.c
- From: Michael Stroucken <stroucki@master.debian.org>