Messages in this thread | | | Date | Fri, 17 Sep 1999 19:01:44 -0400 (EDT) | From | Chris Noe <> | Subject | Oops in cgsixfb.c, SparcStation 20/SMP [2.2.12] |
| |
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/
| |