Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 17 Apr 2013 17:33:11 -0600
From:      Warner Losh <imp@bsdimp.com>
To:        Damjan Marion <damjan.marion@gmail.com>
Cc:        "freebsd-arm@FreeBSD.org" <freebsd-arm@freebsd.org>
Subject:   Re: __rw_wlock_hard panic on 1st malloc
Message-ID:  <D8BD1A3D-BBDC-4B8F-98DD-8C16DFE2732D@bsdimp.com>
In-Reply-To: <8550022A-E05B-4CEA-B899-3D81DDCC9B57@gmail.com>
References:  <DB4E4AA0-91D8-4253-8044-9C33B60E1A3A@gmail.com> <8DE83B01-4508-41C5-B2BD-95A72D0AD963@bsdimp.com> <BD1AE699-31B2-4F13-8222-BEB90EE0E57E@gmail.com> <B94DB19B-7940-4376-B38B-369FD0E45282@bsdimp.com> <92C60946-8FFB-46A1-9400-9E0F7B11FC23@gmail.com> <9A3C042F-3765-4791-AB51-63EA82488743@bsdimp.com> <8550022A-E05B-4CEA-B899-3D81DDCC9B57@gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Also, I'm able to get to mountroot> on my allwinner board if I disable =
WITNESS, but have all kinds of problems if I don't.

And the goofy stack traceback is totally busted for me, so finding out =
where I am has been an exercise in frustration.

Warner

On Apr 17, 2013, at 4:45 PM, Damjan Marion wrote:

>=20
> yes, thanks for the hint. After moving back to gcc everything works =
fine.
>=20
> Damjan
>=20
> On Apr 17, 2013, at 5:37 PM, Warner Losh <imp@bsdimp.com> wrote:
>=20
>> I don't think it is, at least not with clang compiled code. Ian was =
saying on IRC that he saw this and went back to gcc and life was good.
>>=20
>> Warner
>>=20
>> On Apr 16, 2013, at 5:44 PM, Damjan Marion wrote:
>>=20
>>>=20
>>> When I apply your patch I'm getting the same error but this time in =
busdma_init().
>>> Again it is 1st malloc() inside busdma_bufalloc_create().
>>>=20
>>> Can anybody confirm that latest HEAD is working on other Cortex-A =
CPUs?
>>>=20
>>> Damjan
>>>=20
>>> On Apr 17, 2013, at 12:43 AM, Warner Losh <imp@bsdimp.com> wrote:
>>>=20
>>>> The problem here is a double fault. The first fault is in =
init_dynamic_kenv when we try to read the kernel environment. The second =
fault happens because we don't wind up in the debugger (I think due to =
reading the stack goes awry).
>>>>=20
>>>> I've fixed the first problem in r249570.
>>>>=20
>>>> Not sure what's going on beyond that, since after fixing that I hit =
a similar issue in stack_copy() but without a traceback, it is kinda =
hard.
>>>>=20
>>>> This is on my MarsBoard with an allwinner tech's A10 CPU.
>>>>=20
>>>> Warner
>>>>=20
>>>>=20
>>>> On Apr 14, 2013, at 12:51 PM, Damjan Marion wrote:
>>>>=20
>>>>>=20
>>>>> I doubt. init_dynamic_kenv() is called by sysinit as part of =
standard sysinit sequence and=20
>>>>> it is called after kmeminit().
>>>>>=20
>>>>> There is no my custom code except standard parts of initarm =
initialisation.
>>>>>=20
>>>>> Damjan
>>>>>=20
>>>>> On Apr 14, 2013, at 7:19 PM, Warner Losh <imp@bsdimp.com> wrote:
>>>>>=20
>>>>>> Maybe you are calling malloc before these locks are initialized?
>>>>>>=20
>>>>>> Warner
>>>>>>=20
>>>>>> On Apr 14, 2013, at 5:03 AM, Damjan Marion wrote:
>>>>>>=20
>>>>>>>=20
>>>>>>> Hi,
>>>>>>>=20
>>>>>>> I'm playing a bit with i.MX6 based board (wandboard) and I have =
serial console working but
>>>>>>> now it panics in init_dynamic_kenv() with the following error:
>>>>>>>=20
>>>>>>> panic: __rw_wlock_hard: recursing but non-recursive rw pmap pv =
global @ /usr/src/sys/arm/arm/pmap-v6.c:1187
>>>>>>>=20
>>>>>>> It looks like this is the 1st place where malloc() is called, an =
malloc returns valid VA
>>>>>>> but 1st attempt to access that address produces panic above.
>>>>>>>=20
>>>>>>> Any idea what can be the reason for this or any other hint?
>>>>>>>=20
>>>>>>> Thanks,
>>>>>>>=20
>>>>>>> Damjan
>>>>>>> _______________________________________________
>>>>>>> freebsd-arm@freebsd.org mailing list
>>>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
>>>>>>> To unsubscribe, send any mail to =
"freebsd-arm-unsubscribe@freebsd.org"
>>>>>>=20
>>>>>=20
>>>>=20
>>>=20
>>=20
>=20




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D8BD1A3D-BBDC-4B8F-98DD-8C16DFE2732D>