Oops in cgsixfb.c, SparcStation 20/SMP [2.2.12]

Chris Noe (stiker@northlink.com)
Fri, 17 Sep 1999 19:01:44 -0400 (EDT)


Linux sparky 2.2.12 #5 SMP Sun Sep 12 17:39:56 MST 1999 sparc unknown

SparcStation 20 SMP, 32MB

/proc/cpuinfo:

cpu : Texas Instruments, Inc. - SuperSparc 50
fpu : SuperSparc on-chip FPU
promlib : Version 3 Revision 2
prom : 2.15
type : sun4m
ncpus probed : 2
ncpus active : 2
Cpu0Bogo : 49.86
Cpu1Bogo : 49.97
MMU type : TI Viking
invall : 0
invmm : 0
invrnge : 0
invpg : 0
contexts : 65536
CPU0 : online
CPU1 : online

Easily repeatable by holding down 'return' to scroll through a kernel
'make config' (these two oopsen did not occur at the same time; just
including the second to assist debugging).

Options used: -v /boot/vmlinux-2.2.12+smp (specified)
-o /lib/modules/2.2.12/ (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-m /boot/System.map-2.2.12+smp (specified)
-c 1 (default)

Unable to handle kernel paging request at virtual address fd014000
tsk->mm->context = 00000175
tsk->mm->pgd = f0138400
\|/ ____ \|/
"@'/ ,. \`@"
/_| \__/ |_\
\__U_/
make(378): Oops
PSR: 409010c7 PC: f00f82c8 NPC: f00f82cc Y: 00000000
g0: f00b6d68 g1: f0168000 g2: 00000006 g3: f00f82b8 g4: 07200720 g5: 07200720 g6: fc844000 g7: 00000000
o0: 10000000 o1: 00000010 o2: 00000004 o3: 00000010 o4: 00000690 o5: f032a800 sp: fc845a58 o7: f0014700
l0: 404010c0 l1: f0130228 l2: f00f1950 l3: 00000010 l4: fd014000 l5: f0130248 l6: 000000a0 l7: 00000352
i0: fcb37c00 i1: f0178b48 i2: fc9df51a i3: 00000001 i4: 00000034 i5: 0000000d fp: fc845ac0 i7: f00f1934
Caller[f00f1934]
Caller[f00f20d4]
Caller[f00c119c]
Caller[f00c2bc8]
Caller[f00c45a4]
Caller[f00c5d38]
Caller[f00c65bc]
Caller[f00cc724]
Caller[f00ce9e4]
Caller[f00c9ab4]
Caller[f004b824]
Caller[f00154e4]
Caller[5007d768]
Instruction DUMP: da0660e0 11040000 e80362cc <d6052010> 808ac008 12bffffe 19000500 d20e6110 d0168000

>>PC: f00f82c8 <cg6_putcs+10/2d0>
>>O7: f0014700 <smp4m_ticker+28/48>
>>I7: f00f1934 <fbcon_redraw+fc/1b0>
Trace: f00f1934 <fbcon_redraw+fc/1b0>
Trace: f00f20d4 <fbcon_scroll+55c/a4c>
Trace: f00c119c <scrup+70/134>
Trace: f00c2bc8 <lf+34/88>
Trace: f00c45a4 <do_con_trol+1ec/122c>
Trace: f00c5d38 <do_con_write+754/834>
Trace: f00c65bc <con_put_char+14/24>
Trace: f00cc724 <opost+1cc/1e0>
Trace: f00ce9e4 <write_chan+1b4/2dc>
Trace: f00c9ab4 <tty_write+1e8/26c>
Trace: f004b824 <sys_write+148/1a4>
Trace: f00154e4 <syscall_is_too_hard+34/40>
Trace: 5007d768 Before first symbol
Code: f00f82bc <cg6_putcs+4/2d0> 0000000000000000 <_PC>:
Code: f00f82bc <cg6_putcs+4/2d0> 0: da 06 60 e0 ld [ %i1 + 0xe0 ], %o5
Code: f00f82c0 <cg6_putcs+8/2d0> 4: 11 04 00 00 sethi %hi(0x10000000), %o0
Code: f00f82c4 <cg6_putcs+c/2d0> 8: e8 03 62 cc ld [ %o5 + 0x2cc ], %l4
Code: f00f82c8 <cg6_putcs+10/2d0> c: d6 05 20 10 ld [ %l4 + 0x10 ], %o3 <===
Code: f00f82cc <cg6_putcs+14/2d0> 10: 80 8a c0 08 btst %o3, %o0
Code: f00f82d0 <cg6_putcs+18/2d0> 14: 12 bf ff fe bne f00f82c8 <cg6_putcs+10/2d0>
Code: f00f82d4 <cg6_putcs+1c/2d0> 18: 19 00 05 00 sethi %hi(0x140000), %o4
Code: f00f82d8 <cg6_putcs+20/2d0> 1c: d2 0e 61 10 ldub [ %i1 + 0x110 ], %o1
Code: f00f82dc <cg6_putcs+24/2d0> 20: d0 16 80 00 lduh [ %i2 ], %o0

Unable to handle kernel paging request at virtual address fd014000
tsk->mm->context = 00000171
tsk->mm->pgd = f0dd5000
\|/ ____ \|/
"@'/ ,. \`@"
/_| \__/ |_\
\__U_/
sh(374): Oops
PSR: 409000c0 PC: f00f82c8 NPC: f00f82cc Y: 00000000
g0: 00000000 g1: f0168000 g2: 0000000a g3: f00f82b8 g4: 07200720 g5: 07200720 g6: fc932000 g7: 00000000
o0: 10000000 o1: 00000000 o2: 00000000 o3: 00000010 o4: 00000740 o5: f032a800 sp: fc933a58 o7: f00f6f9c
l0: 409000c1 l1: f01301b8 l2: f00f6f58 l3: 00000010 l4: fd014000 l5: f0130288 l6: 000000a8 l7: 000002b2
i0: f050c000 i1: f0178a34 i2: f033eb1c i3: 00000019 i4: 0000002a i5: 0000000e fp: fc933ac0 i7: f00f1934
Caller[f00f1934]
Caller[f00f20d4]
Caller[f00c119c]
Caller[f00c2bc8]
Caller[f00c45a4]
Caller[f00c5d38]
Caller[f00c65bc]
Caller[f00cc724]
Caller[f00ce9e4]
Caller[f00c9ab4]
Caller[f004b824]
Caller[f00154e4]
Caller[50090768]
Instruction DUMP: da0660e0 11040000 e80362cc <d6052010> 808ac008 12bffffe 19000500 d20e6110 d0168000

>>PC: f00f82c8 <cg6_putcs+10/2d0>
>>O7: f00f6f9c <sbusfb_cursor+48/160>
>>I7: f00f1934 <fbcon_redraw+fc/1b0>
Trace: f00f1934 <fbcon_redraw+fc/1b0>
Trace: f00f20d4 <fbcon_scroll+55c/a4c>
Trace: f00c119c <scrup+70/134>
Trace: f00c2bc8 <lf+34/88>
Trace: f00c45a4 <do_con_trol+1ec/122c>
Trace: f00c5d38 <do_con_write+754/834>
Trace: f00c65bc <con_put_char+14/24>
Trace: f00cc724 <opost+1cc/1e0>
Trace: f00ce9e4 <write_chan+1b4/2dc>
Trace: f00c9ab4 <tty_write+1e8/26c>
Trace: f004b824 <sys_write+148/1a4>
Trace: f00154e4 <syscall_is_too_hard+34/40>
Trace: 50090768 Before first symbol
Code: f00f82bc <cg6_putcs+4/2d0> 0000000000000000 <_PC>:
Code: f00f82bc <cg6_putcs+4/2d0> 0: da 06 60 e0 ld [ %i1 + 0xe0 ], %o5
Code: f00f82c0 <cg6_putcs+8/2d0> 4: 11 04 00 00 sethi %hi(0x10000000), %o0
Code: f00f82c4 <cg6_putcs+c/2d0> 8: e8 03 62 cc ld [ %o5 + 0x2cc ], %l4
Code: f00f82c8 <cg6_putcs+10/2d0> c: d6 05 20 10 ld [ %l4 + 0x10 ], %o3 <===
Code: f00f82cc <cg6_putcs+14/2d0> 10: 80 8a c0 08 btst %o3, %o0
Code: f00f82d0 <cg6_putcs+18/2d0> 14: 12 bf ff fe bne f00f82c8 <cg6_putcs+10/2d0>
Code: f00f82d4 <cg6_putcs+1c/2d0> 18: 19 00 05 00 sethi %hi(0x140000), %o4
Code: f00f82d8 <cg6_putcs+20/2d0> 1c: d2 0e 61 10 ldub [ %i1 + 0x110 ], %o1
Code: f00f82dc <cg6_putcs+24/2d0> 20: d0 16 80 00 lduh [ %i2 ], %o0

I'm just starting to really play with this box and I've never had any
experience with Sparc assembly before. I am very curious though...

I know 'ld' is the ubiq. 'load' inst. and I see that (using the first
line of dissassembly as an example) it tries to put the loaded word in %o5
but is the %i1 + 0xe0 expression calculated as an absolute address, which
is then put into %o5 -- or are the contents of [%i1 + 0x30] put into %o5
(akin to the brackets in ix86/intel assembly)?

Here's what I've managed to (hopefully) find out:
%i1 = f0178a34 (fb_display)

ld [%i1 + 0xe0 ] -> %o5 (my guess is that this is the offset to fb_info?)
%i1 + 0xe0 = f0178b14
ld [%o5 + 0x2cc] -> %l4 (and this must be loading %l4 with fb->s.cg6.fbc)
%o5 + 0x2cc = f0178de0

I'm guessing from this that my second idea is probably true: the ld inst.
loads %l4 with fd014000 because that is what's held in memory at f0178de0.
Maybe? :)

Here's a quick look at the first few lines of drivers/video/cgsixfb.c:cg6_putcs()

[...]

static void cg6_putcs(struct vc_data *conp, struct display *p, const unsigned short *s,
int count, int yy, int xx)
{
struct fb_info_sbusfb *fb = (struct fb_info_sbusfb *)p->fb_info;
register struct cg6_fbc *fbc = fb->s.cg6.fbc;
int i, x, y;
u8 *fd1, *fd2, *fd3, *fd4;

do {
i = fbc->s;
} while (i & 0x10000000);

[...]

I'm guessing this is an SMP related bug/race, since fbc doesn't look like it'd do anything
this nasty on a UP system.

Chris Noe
(stiker@northlink.com)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/