Date: Tue, 3 Jun 2014 16:43:38 +0300 From: Aleksandr Rybalko <ray@freebsd.org> To: Michael Tuexen <tuexen@freebsd.org> Cc: "freebsd-arm@freebsd.org" <arm@freebsd.org>, src-committers@freebsd.org Subject: Re: svn commit: r265927 - head/sys/dev/vt Message-ID: <20140603164338.bbcf323f6e1d1edd83db56fc@freebsd.org> In-Reply-To: <17B3391B-BCE3-4B0D-93AE-D2B377FD9038@freebsd.org> References: <201405121929.s4CJTcBx010967@svn.freebsd.org> <2899E6ED-712E-46BC-960B-9847FD99431C@freebsd.org> <20140514142252.8fe1742f90a28e534532b1d5@freebsd.org> <17B3391B-BCE3-4B0D-93AE-D2B377FD9038@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 14 May 2014 18:37:15 +0200 Michael Tuexen <tuexen@freebsd.org> wrote: > On 14 May 2014, at 13:22, Aleksandr Rybalko <ray@freebsd.org> wrote: > > > On Tue, 13 May 2014 18:20:32 +0200 > > Michael Tuexen <tuexen@freebsd.org> wrote: > > > >> Hi Aleksandr, > > > > Hi Michael, > > > >> > >> could it be that this commit results in the following panic when booting > >> a Raspberry Pi: > >> > >> fb0: 656x416(0x0@0,0) 16bpp > >> fb0: pitch 1312, base 0x5e006000, screen_size 545792 > >> fbd0 on fb0 > >> VT: initialize with new VT driver "fb". > >> panic: mtx_lock() of spin mutex (null) @ /usr/home/tuexen/head/sys/dev/vt/vt_core.c:2035 > >> KDB: enter: panic > > > > > > Hmm, looks like here is some memory corruption. It is possible happen > > due some issue of vt(4), but panic and bt show problem with lock which > > was used right before that place: > > vt_upgrade() call VT_LOCK(vd), VT_UNLOCK(vd), then vt_resize(vd) > > vt_resize(vd) try to VT_LOCK(vd) and fail. > OK, I tested this. > > the first time vt_upgrade() is called, it calls vt_resize() from line 2024, > and this is not a problem. The second time vt_upgrade is called, it calls > vt_resize from line 1987. This results in the panic. > > Does this help? Michael, many thanks for your investigation. I think it is fixed with r267007. > > Best regards > Michael > > > > Can you please try to do clean rebuild (in case you use incremental > > build)? > > > >> [ thread pid 0 tid 100000 ] > >> Stopped at $d: ldrb r15, [r15, r15, ror r15]! > >> db> where > >> Tracing pid 0 tid 100000 td 0xc06648a0 > >> db_trace_self() at db_trace_self > >> pc = 0xc0495760 lr = 0xc0130fdc (db_stack_trace+0xf4) > >> sp = 0xc075ea68 fp = 0xc075ea80 > >> r10 = 0xc0663930 > >> db_stack_trace() at db_stack_trace+0xf4 > >> pc = 0xc0130fdc lr = 0xc013094c (db_command+0x270) > >> sp = 0xc075ea88 fp = 0xc075eb28 > >> r4 = 0x00000000 r5 = 0x00000000 > >> r6 = 0x00000072 > >> db_command() at db_command+0x270 > >> pc = 0xc013094c lr = 0xc01306b0 (db_command_loop+0x60) > >> sp = 0xc075eb30 fp = 0xc075eb40 > >> r4 = 0xc04d5176 r5 = 0xc04ef7ba > >> r6 = 0xc066391c r7 = 0xc0590b40 > >> r8 = 0xc065a294 r9 = 0xc065a290 > >> r10 = 0xc075ed10 > >> db_command_loop() at db_command_loop+0x60 > >> pc = 0xc01306b0 lr = 0xc0133078 (db_trap+0xd8) > >> sp = 0xc075eb48 fp = 0xc075ec68 > >> r4 = 0x00000000 r5 = 0xc0663928 > >> r6 = 0xc065a2c0 > >> db_trap() at db_trap+0xd8 > >> pc = 0xc0133078 lr = 0xc028de10 (kdb_trap+0xbc) > >> sp = 0xc075ec70 fp = 0xc075ec90 > >> r4 = 0x00000000 r5 = 0x00000001 > >> r6 = 0xc065a2c0 r7 = 0xc0590b40 > >> kdb_trap() at kdb_trap+0xbc > >> pc = 0xc028de10 lr = 0xc04a90e0 (undefinedinstruction+0x298) > >> sp = 0xc075ec98 fp = 0xc075ed08 > >> r4 = 0x00000000 r5 = 0x00000000 > >> r6 = 0xc04a8d98 r7 = 0xe7ffffff > >> r8 = 0xc06648a0 r9 = 0xc028d6e0 > >> r10 = 0xc075ed10 > >> undefinedinstruction() at undefinedinstruction+0x298 > >> pc = 0xc04a90e0 lr = 0xc04972dc (exception_exit) > >> sp = 0xc075ed10 fp = 0xc075ed68 > >> r4 = 0xc04ef814 r5 = 0xc075edbc > >> r6 = 0xc04ed1f1 r7 = 0xc064c7d0 > >> r8 = 0xc06648a0 r9 = 0xc066537c > >> r10 = 0xc064c630 > >> exception_exit() at exception_exit > >> pc = 0xc04972dc lr = 0xc028d6d4 (kdb_enter+0x40) > >> sp = 0xc075ed60 fp = 0xc075ed68 > >> r0 = 0xc065a2a4 r1 = 0x00000000 > >> r2 = 0xc04f328a r3 = 0x000000ab > >> r4 = 0xc04ef814 r5 = 0xc075edbc > >> r6 = 0xc04ed1f1 r7 = 0xc064c7d0 > >> r8 = 0xc06648a0 r9 = 0xc066537c > >> r10 = 0xc064c630 r12 = 0x00000000 > >> $a() at $a > >> pc = 0xc028d6e4 lr = 0xc0256eb8 (vpanic+0xb4) > >> sp = 0xc075ed70 fp = 0xc075ed90 > >> r4 = 0x00000100 > >> vpanic() at vpanic+0xb4 > >> pc = 0xc0256eb8 lr = 0xc0256df4 ($d) > >> sp = 0xc075ed98 fp = 0xc075edb0 > >> r4 = 0xc064c6d0 r5 = 0xc04ed1f1 > >> r6 = 0xc075edbc r7 = 0xc064c630 > >> r8 = 0x00000000 r9 = 0x000007f3 > >> r10 = 0x000007f7 > >> $d() at $d > >> pc = 0xc0256df4 lr = 0xc0243240 (__mtx_lock_flags+0x134) > >> sp = 0xc075edc8 fp = 0xc075edf0 > >> r4 = 0xc04df462 r5 = 0xc05a0f00 > >> r6 = 0x000007f3 r7 = 0xc05a0f00 > >> __mtx_lock_flags() at __mtx_lock_flags+0x134 > >> pc = 0xc0243240 lr = 0xc0192008 (vt_resize+0x44) > >> sp = 0xc075edf8 fp = 0xc075ee18 > >> r4 = 0xc05a0e90 r5 = 0xc05a0f00 > >> r6 = 0xc04df462 r7 = 0xc05a0f50 > >> r8 = 0x00000000 > >> vt_resize() at vt_resize+0x44 > >> pc = 0xc0192008 lr = 0xc0191f7c (vt_upgrade+0x38c) > >> sp = 0xc075ee20 fp = 0xc075ee88 > >> r4 = 0x00000001 r5 = 0xc0664898 > >> r6 = 0xc05a0e90 r7 = 0xc0523148 > >> r8 = 0xc06650a4 r9 = 0xc06650a0 > >> r10 = 0x00001bd6 > >> vt_upgrade() at vt_upgrade+0x38c > >> pc = 0xc0191f7c lr = 0xc0205e14 (mi_startup+0x11c) > >> sp = 0xc075ee90 fp = 0xc075eea8 > >> r4 = 0x00000001 r5 = 0xc0664898 > >> r6 = 0x00000000 r7 = 0xc0523148 > >> r8 = 0xc06650a4 r9 = 0xc06650a0 > >> r10 = 0x00001bd6 > >> mi_startup() at mi_startup+0x11c > >> pc = 0xc0205e14 lr = 0xc0100238 (virt_done+0x44) > >> sp = 0xc075eeb0 fp = 0x00000000 > >> r4 = 0xc0100268 r5 = 0xc066c000 > >> r6 = 0x02048740 r7 = 0x0010014c > >> r8 = 0x00000000 r9 = 0xc074d000 > >> virt_done() at virt_done+0x44 > >> pc = 0xc0100238 lr = 0xc0100238 (virt_done+0x44) > >> sp = 0xc075eeb0 fp = 0x00000000 > >> Unable to unwind further > >> db> > >> On 12 May 2014, at 21:29, Aleksandr Rybalko <ray@freebsd.org> wrote: > >> > >>> Author: ray > >>> Date: Mon May 12 19:29:38 2014 > >>> New Revision: 265927 > >>> URL: http://svnweb.freebsd.org/changeset/base/265927 > >>> > >>> Log: > >>> Update terminal sizes in any case when new vt(4) driver arrive. > >>> (Plus remove one unused newline) > >>> > >>> Sponsored by: The FreeBSD Foundation > >>> > >>> Modified: > >>> head/sys/dev/vt/vt_core.c > >>> > >>> Modified: head/sys/dev/vt/vt_core.c > >>> ============================================================================== > >>> --- head/sys/dev/vt/vt_core.c Mon May 12 19:11:39 2014 (r265926) > >>> +++ head/sys/dev/vt/vt_core.c Mon May 12 19:29:38 2014 (r265927) > >>> @@ -1981,8 +1981,11 @@ vt_upgrade(struct vt_device *vd) > >>> unsigned int i; > >>> > >>> /* Device didn't pass vd_init() or already upgraded. */ > >>> - if (vd->vd_flags & (VDF_ASYNC|VDF_DEAD)) > >>> + if (vd->vd_flags & (VDF_ASYNC|VDF_DEAD)) { > >>> + /* Refill settings with new sizes anyway. */ > >>> + vt_resize(vd); > >>> return; > >>> + } > >>> vd->vd_flags |= VDF_ASYNC; > >>> > >>> for (i = 0; i < VT_MAXWINDOWS; i++) { > >>> @@ -2019,7 +2022,6 @@ vt_upgrade(struct vt_device *vd) > >>> > >>> /* Refill settings with new sizes. */ > >>> vt_resize(vd); > >>> - > >>> } > >>> > >>> static void > >>> > >>> > >> > > > > Thanks! > > > > WBW > > -- > > Aleksandr Rybalko <ray@freebsd.org> > > > Thanks! WBW -- Aleksandr Rybalko <ray@freebsd.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140603164338.bbcf323f6e1d1edd83db56fc>