Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 26 Aug 2013 11:51:43 -0700
From:      Thomas Skibo <ThomasSkibo@sbcglobal.net>
To:        freebsd-arm@freebsd.org
Subject:   Re: My BB-Black boot failure
Message-ID:  <521BA3BF.10002@sbcglobal.net>
In-Reply-To: <1377526174.1111.138.camel@revolution.hippie.lan>
References:  <CAKrd9eUKjc6sDJBB9hx34PeWHP-B6cnSLv0GCOjKzvsJagZZgw@mail.gmail.com> <1377262426.1111.50.camel@revolution.hippie.lan> <CAKrd9eVBwztNqju=MD8dPxuqwyKQBTMJcoKF6fJiSN7vmsKt_Q@mail.gmail.com> <1377526174.1111.138.camel@revolution.hippie.lan>

next in thread | previous in thread | raw e-mail | index | archive | help

I've been experiencing this too on the Zedboard and I spent some time 
looking into it.

In my case, arprequest() is overwriting past the end of an mbuf into the 
m_next field of the next one.  Later, something tries to reference 
address 0x6401a8c0 which is actually the machine's IP address in network 
order.  It looks like MH_ALIGN() used in arprequest() isn't working 
properly after the recent mbuf header changes.

Here's the mbuf just after arprequest() has performed MH_ALIGN().  The 
m_data pointer is 0xc2c41de8 and the length is 0x1c.  That puts the data 
over the edge into the next mbuf.  The m_pkthdr appears to have been 
placed at 0xc2c41d18 (I think).  It looks like the compiler inserted 
padding at 1d14 so MHLEN isn't correct.

--Thomas

XMD% mrd 0xc2c41d00 32
C2C41D00:   00000000
C2C41D04:   00000000
C2C41D08:   C2C41DE8 (m_data)
C2C41D0C:   0000001C (m_len)
C2C41D10:   00000201 (m_type,m_flags)
C2C41D14:   00000000  (?)
C2C41D18:   00000000 (pkthdr.rcvif)
C2C41D1C:   00000000 (pkthdr.tags)
C2C41D20:   0000001C (pkthdr.len)
C2C41D24:   00000000
C2C41D28:   00000000
C2C41D2C:   00000000




On 8/26/13 7:09 AM, Ian Lepore wrote:
> On Mon, 2013-08-26 at 19:14 +0800, XiaoQI Ge wrote:
>> I'm using the latest source code compiled kernel (r254898)
>> Kernel panic after start
>>
>> Kernel entry at 0x80200100...
>> Kernel args: (null)
>> KDB: debugger backends: ddb
>> KDB: current backend: ddb
>> Copyright (c) 1992-2013 The FreeBSD Project.
>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>>          The Regents of the University of California. All rights reserved.
>> FreeBSD is a registered trademark of The FreeBSD Foundation.
>> FreeBSD 10.0-CURRENT #2 r254898: Tue Aug 27 00:44:45 CST 2013
>>      root@7axu.com:/crochet-freebsd/work/obj/arm.armv6/usr/src/sys/BB-Black arm
>> FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
>> WARNING: WITNESS option enabled, expect reduced performance.
>> WARNING: DIAGNOSTIC option enabled, expect reduced performance.
>
>> [snip]
>
>
> Several people are experiencing this address fault or similar ones,
> sometimes in in_cksum() instead of so_receivegeneric().
>
> It looks like the latest revision that I can build and boot the BB
> without any trouble is r254777.
>
> The revision that actually breaks things appears to be r254807 (kudos to
> Zbyszek Bodek for tracking it down to this rev), so you can boot using
> r254806 but to get that rev to build you have to also apply the changes
> from r254814.
>
> There was a large flurry of checkins over the past few days to get
> things in before the cutoff for the 10.0 release.  I have a feeling it
> will be a few days before the dust settles and we get some fixes.
>
> -- Ian
>
>
> _______________________________________________
> 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"
>

-- 
--------
Thomas Skibo
ThomasSkibo@sbcglobal.net




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?521BA3BF.10002>