When doing a backup to a SCSI tape I found myself starring, all of sudden,
at the followin oops:
Unable to handle kernel paging request at virtual address ffffffffffff8b48
swapper(0): Oops 0
pc = [<fffffc0000313098>] ps = 0000
rp = [<fffffc00003130a0>] sp = fffffc0000303fb0
r0=7 r1=1 r2=fffffc000041d7f8 r3=fffffc000041d7f8
r8=1201219c8
r16=0 r17=2 r18=1201222a0 r19=2800
r20=2800 r21=11ffff330 r22=0 r23=18272f96f2
r24=3000000000000000 r25=a r26=fffffc00003130a0 r27=fffffc000031a560
r28=1 r29=0 r30=fffffc0000303fb0
Code: c3e00008 203fff9c b4220008 <a77d8b48> 6b5b5d30 27ba0013 23bdcc10
c3fffffb 47ff041f
kfree of non-kmalloced memory:
fffffc000041cb28, next= 0000000000000000, order=0
kfree of non-kmalloced memory:
fffffc000041cb10, next= 0000000000000000, order=0
kfree of non-kmalloced memory:
fffffc000041d430, next= 0000000000000000, order=0
idle task may not sleep
idle task may not sleep
idle task may not sleep
idle task may not sleep
idle task may not sleep
Program counter indeed sits between these two symbols:
fffffc0000313068 T sys_idle
fffffc00003130c0 t swap_context
After that the machine was continuing merrily (good for Linux :-) and the
backup did not stop - so I am not even exactly sure what was the other
state of the machine when this happened as I catched that a while later.
Does that say anything to anybody?
The problem could have been possibly triggered by a fact that 8-bit
SCSI tape was sitting on 16-bit SCSI controller (Diamond Fireport) with
default settings. After adjusting on a controller settings for that
particular ID I wrote over 3 Gig to a tape without any further incidents.
Michal
p.s. unfortunately I do not have this machine right now, so I cannot
provide more info; maybe in a few days
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu