From owner-freebsd-arm@FreeBSD.ORG Sun Jul 28 03:33:20 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 27763563 for ; Sun, 28 Jul 2013 03:33:20 +0000 (UTC) (envelope-from rpaulo@felyko.com) Received: from felyko.com (felyko.com [IPv6:2607:f2f8:a528::3:1337:ca7]) by mx1.freebsd.org (Postfix) with ESMTP id 11A1D2F66 for ; Sun, 28 Jul 2013 03:33:20 +0000 (UTC) Received: from [IPv6:2601:9:4d00:119:c15b:205a:8fbd:2517] (unknown [IPv6:2601:9:4d00:119:c15b:205a:8fbd:2517]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id 3BFD13982B for ; Sat, 27 Jul 2013 20:33:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=felyko.com; s=mail; t=1374982399; bh=igKq3UMUgGEbDtZ6C5QkoZ6ox/qx5EWmEHO8Src5gmc=; h=From:Subject:Date:To; b=XFkQewakSau92VNHRUWNjkl+NnSiL8K5eUYDIzsLTLxXGRSX1YlcdMHbOHbftyh4v ZU1cSlLDvXFcYQ5oJTDhofQ4dsMPWEwxP84NNBe7X1F2jSgUkM6/YR/Oc3PEuO6IP4 67rD63e7ZKQeoULx5ILh8mD3Dv37ZC7d0fdYbzq8= From: Rui Paulo Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: External Non-Linefetch Abort (S) Message-Id: <3C6B0B0D-3F16-44A5-8DF2-A79CBD0D02D3@felyko.com> Date: Sat, 27 Jul 2013 20:33:18 -0700 To: "freebsd-arm@freebsd.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 03:33:20 -0000 On the BeagleBone, I'm trying to access this address 0x4a300000. I know = there is a device there (the PRUSS) and I should be able to access it, = but instead I get this data abort trap: Fatal kernel mode data abort: 'External Non-Linefetch Abort (S)' trapframe: 0xc08c5c84 FSR=3D00001008, FAR=3Dd4a5c000, spsr=3D60000093 r0 =3D00000000, r1 =3Dd4a5c000, r2 =3D00000000, r3 =3Dc062a908 r4 =3D00000000, r5 =3Dc08c5ce4, r6 =3Dc1825500, r7 =3Dc18eb700 r8 =3Dffffffff, r9 =3Dc1825d80, r10=3Dc1825500, r11=3Dc05511e0 r12=3D00000015, ssp=3Dc08c5cd0, slr=3Dc052f1b0, pc =3Dc050bf78 [ thread pid 0 tid 100000 ] Stopped at generic_bs_r_4: ldr r0, [r1, r2] It looks like 0xd4a5c000 is the virtual address that points to = 0x4a300000 (I checked with vtophys()). Does anyone know what this problem could be? I made sure the clock for = this device are running. -- Rui Paulo From owner-freebsd-arm@FreeBSD.ORG Sun Jul 28 03:34:56 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AC9435AB for ; Sun, 28 Jul 2013 03:34:56 +0000 (UTC) (envelope-from ghw@7axu.com) Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2F9B62F6E for ; Sun, 28 Jul 2013 03:34:55 +0000 (UTC) Received: by mail-we0-f176.google.com with SMTP id q56so2985706wes.35 for ; Sat, 27 Jul 2013 20:34:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=VgW1gJSECZYkqjb/gE6knxdo/O98gmTjsqiwN1p7kMc=; b=dzSNYtj1HscAby6wNZKz7Vo/qc85IkvxCKQUnCa7XRAEpfSN2o0crWKVixXH8u/mLQ AfmboF/L8nA9ETIOvMAdx8PGdtfhGYA4+86ur9RibEK5cgFB0rSyUKme3W3E22AWbY6Z WWVnaM0V0k6gkpwWrX2dJGc53/aeJ0kt2gtvE8TFmdm3eNihjSpCP9B02qbtgGjjrcJr dTuK2vBLhwSsXh18n1hWB9BL78+1+fsaBXhb1BkHk80039NabSr/ZWA8UjYRKmyW1ZVa vVCwzs5WOPVBwcF/r45K6Dh6pkfagMDbzv2H+tEzEBevzfyXmwtCmXYLtSB2m2VMKrGQ Ve4A== X-Received: by 10.180.73.103 with SMTP id k7mr3308140wiv.24.1374982487615; Sat, 27 Jul 2013 20:34:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.93.34 with HTTP; Sat, 27 Jul 2013 20:34:07 -0700 (PDT) X-Originating-IP: [54.249.112.206] In-Reply-To: References: <1374573600-2351360719.d37ada5f86@bliksem.vehosting.nl> <201307231220.52817.Daan@vitsch.nl> From: XiaoQI Ge Date: Sun, 28 Jul 2013 11:34:07 +0800 Message-ID: Subject: Re: My WLI-UC-GNM up crash To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnuT5ZPPq5MxFSkTqpmRelZwOlGsIAMXc9Ms2jmE63ltvvFZZjbRiNCyZQRJudrK5ecod40 Cc: freebsd-arm , freebsd-wireless@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 03:34:56 -0000 That should be how to solve it? -- Regards. By: XiaoQI Ge; PGP:8B09D5F7 WWW: https://www.7axu.com/ 2013/7/27 Adrian Chadd : > This is known; there's some alignment issue with the radiotap TX/RX > structures in some of these USB devices. > > > > -adrain > > On 25 July 2013 20:23, XiaoQI Ge wrote: >> =E6=88=91=E6=9B=B4=E6=96=B0=E5=88=B0=E6=9C=80=E6=96=B0=E7=9A=84=E6=BA=90= =E7=A0=81=EF=BC=88r253662=EF=BC=89=EF=BC=8C=E8=BF=99=E6=AC=A1=E9=94=99=E8= =AF=AF=E4=BF=A1=E6=81=AF=E5=8F=98=E6=88=90=E4=BA=860xde9f4d34 >> >> [root@FreeBSD.ttyu0] ~ # Fatal kernel mode data abort: 'Alignment Fault = 1' >> trapframe: 0xde9f4d34 >> FSR=3D00000801, FAR=3Dc284afbb, spsr=3D00000013 >> r0 =3Dc284c000, r1 =3Dc284afbb, r2 =3Dc284c210, r3 =3D0000096c >> r4 =3Dc284c024, r5 =3Dc05f07c5, r6 =3D00000014, r7 =3Dc2844800 >> r8 =3Dc05f07c5, r9 =3Dc284c000, r10=3D000035cb, r11=3Dde9f4e10 >> r12=3D0000002e, ssp=3Dde9f4d80, slr=3D00000000, pc =3Dc046d20c >> >> [ thread pid 0 tid 100053 ] >> Stopped at ieee80211_radiotap_chan_change+0x90: strh r3, [r1] >> db> >> --- >> Kernel wlan related options >> device wlan # 802.11 support >> options IEEE80211_DEBUG # enable debug msgs >> options IEEE80211_AMPDU_AGE # age frames in AMPDU reorder q's >> options IEEE80211_SUPPORT_MESH # enable 802.11s draft support >> device wlan_wep # 802.11 WEP support >> device wlan_ccmp # 802.11 CCMP support >> device wlan_tkip # 802.11 TKIP support >> device wlan_amrr # AMRR transmit rate control algorithm >> device firmware # firmware assist module >> device run #Ralink Technology USB IEEE 802.11a/g/n >> wireless network device >> device runfw #Firmware Module for Ralink driver >> >> --- >> The compiler command >> make TARGET_ARCH=3Darmv6 TARGET_CPUTYPE=3Darmv6 KERNCONF=3DBBB WITH_FDT= =3Dyes >> buildkernel >> -- >> Regards. >> By: XiaoQI Ge; PGP:8B09D5F7 >> WWW: https://www.7axu.com/ >> >> >> >> 2013/7/24 XiaoQI Ge : >>> How do I debug it? Can provide useful information >>> >>> login: root >>> Jul 24 18:27:31 FreeBSD login: ROOT LOGIN (root) ON ttyu0 >>> FreeBSD 10.0-CURRENT (BBB) #4 r253585M: Wed Jul 24 17:07:53 CST 2013 >>> [root@FreeBSD.ttyu0] ~ # ifconfig wlan create wlandev run0 >>> wlan0: Ethernet address: 10:6f:3f:2b:fd:6d >>> wlan0 >>> [root@FreeBSD.ttyu0] ~ # ifconfig wlan0 up >>> run0: firmware RT2870 ver. 0.236 loaded >>> Fatal kernel mode data abort: 'Alignment Fault 1' >>> trapframe: 0xde9e4d5c >>> FSR=3D00000801, FAR=3Dc282ffbb, spsr=3D00000013 >>> r0 =3Dc2831000, r1 =3Dc282ffbb, r2 =3Dc2831210, r3 =3D0000096c >>> r4 =3Dc2831024, r5 =3Dc2831000, r6 =3Dc05d9362, r7 =3Dc2829800 >>> r8 =3D00000014, r9 =3Dc08144d8, r10=3D80001cce, r11=3Dde9e4e10 >>> r12=3D0000002e, ssp=3Dde9e4da8, slr=3D00000000, pc =3Dc045c510 >>> >>> [ thread pid 0 tid 100053 ] >>> Stopped at ieee80211_radiotap_chan_change+0x90: strh r3, [r1= ] >>> db> >>> >>> >>> These two places modified: >>> 2522 } >>> 2523 >>> 2524 ant =3D run_maxrssi_chain(sc, rxwi); >>> 2525 rssi =3D rxwi->rssi[ant]; >>> 2526 nf =3D run_rssi2dbm(sc, rssi, ant); >>> 2527 >>> 2528 m->m_pkthdr.rcvif =3D ifp; >>> 2529 m->m_pkthdr.len =3D m->m_len =3D len; >>> 2530 /* >>> 2531 if (ni !=3D NULL) { >>> 2532 (void)ieee80211_input(ni, m, rssi, nf); >>> 2533 ieee80211_free_node(ni); >>> 2534 } else { >>> 2535 (void)ieee80211_input_all(ic, m, rssi, nf); >>> 2536 } >>> 2537 */ >>> 2538 /* >>> 2539 * DAAN: fill-in tap header BEFORE calling ieee80211_input*() = so the >>> 2540 * user will see the actual data that belongs to THIS packet.. >>> 2541 */ >>> 2542 if (__predict_false(ieee80211_radiotap_active(ic))) { >>> 2543 struct run_rx_radiotap_header *tap =3D &sc->sc_rxtap; >>> 2544 >>> 2545 tap->wr_flags =3D 0; >>> 2546 tap->wr_chan_freq =3D htole16(ic->ic_curchan->ic_freq); >>> 2547 tap->wr_chan_flags =3D htole16(ic->ic_curchan->ic_flags); >>> 2548 tap->wr_antsignal =3D rssi; >>> 2549 tap->wr_antenna =3D ant; >>> 2550 tap->wr_dbm_antsignal =3D run_rssi2dbm(sc, rssi, ant); >>> 2551 tap->wr_rate =3D 2; /* in case it can't be found below *= / >>> 2552 phy =3D le16toh(rxwi->phy); >>> 2553 switch (phy & RT2860_PHY_MODE) { >>> 2554 case RT2860_PHY_CCK: >>> 2555 switch ((phy & RT2860_PHY_MCS) & ~RT2860_PHY_SHPRE) { >>> 2556 case 0: tap->wr_rate =3D 2; break; >>> 2557 case 1: tap->wr_rate =3D 4; break; >>> 2558 case 2: tap->wr_rate =3D 11; break; >>> 2559 case 3: tap->wr_rate =3D 22; break; >>> 2560 } >>> 2561 if (phy & RT2860_PHY_SHPRE) >>> 2562 tap->wr_flags |=3D IEEE80211_RADIOTAP_F_SHORTPRE; >>> 2563 break; >>> 2564 case RT2860_PHY_OFDM: >>> 2565 switch (phy & RT2860_PHY_MCS) { >>> 2566 case 0: tap->wr_rate =3D 12; break; >>> 2567 case 1: tap->wr_rate =3D 18; break; >>> 2568 case 2: tap->wr_rate =3D 24; break; >>> 2569 case 3: tap->wr_rate =3D 36; break; >>> 2570 case 4: tap->wr_rate =3D 48; break; >>> 2571 case 5: tap->wr_rate =3D 72; break; >>> 2572 case 6: tap->wr_rate =3D 96; break; >>> 2573 case 7: tap->wr_rate =3D 108; break; >>> 2574 } >>> 2575 break; >>> 2576 } >>> 2577 } >>> 2578 >>> 2579 if (ni !=3D NULL) { >>> 2580 (void)ieee80211_input(ni, m, rssi, nf); >>> 2581 ieee80211_free_node(ni); >>> 2582 } else { >>> 2583 (void)ieee80211_input_all(ic, m, rssi, nf); >>> 2584 } >>> 2585 >>> 2586 } >>> 2587 >>> 2588 static void >>> >>> >>> Index: sys/vm/vm_map.c >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> --- sys/vm/vm_map.c (revision 253514) >>> +++ sys/vm/vm_map.c (working copy) >>> @@ -239,8 +239,7 @@ >>> vm_map_t map; >>> >>> map =3D (vm_map_t)mem; >>> - map->nentries =3D 0; >>> - map->size =3D 0; >>> + memset(map, 0, sizeof(*map)); >>> mtx_init(&map->system_mtx, "vm map (system)", NULL, MTX_DEF | >>> MTX_DUPOK); >>> sx_init(&map->lock, "vm map (user)"); >>> return (0); >>> >>> -- >>> Regards. >>> By: XiaoQI Ge; PGP:8B09D5F7 >>> WWW: https://www.7axu.com/ >>> >>> >>> >>> 2013/7/24 XiaoQI Ge : >>>> I manually make up, is compiling the kernel >>>> -- >>>> Regards. >>>> By: XiaoQI Ge; PGP:8B09D5F7 >>>> WWW: https://www.7axu.com/ >>>> >>>> >>>> >>>> 2013/7/24 XiaoQI Ge : >>>>> patch < /root/if_run_2013_01_19_radiotap_fix_only.diff appears to be= invalid >>>>> >>>>> ] /usr/src/sys/dev/usb/wlan # patch < >>>>> /root/if_run_2013_01_19_radiotap_fix_only.diff >>>>> Hmm... Looks like a unified diff to me... >>>>> The text leading up to this was: >>>>> -------------------------- >>>>> |--- if_run.c.fix1_vnet 2013-06-14 10:12:49.786774072 +0200 >>>>> |+++ if_run.c.fix2_vnet_plus_radiotap 2013-06-14 10:15:34.890774314= +0200 >>>>> -------------------------- >>>>> File to patch: >>>>> >>>>> >>>>> 2013/7/23 Daan Vreeken : >>>>>> cd /usr/src/sys/dev/usb/wlan >>>>> >>>>> >>>>> >>>>> -- >>>>> Regards. >>>>> By: XiaoQI Ge; PGP:8B09D5F7 >>>>> WWW: https://www.7axu.com/ >> _______________________________________________ >> freebsd-wireless@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-wireless >> To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.o= rg" From owner-freebsd-arm@FreeBSD.ORG Sun Jul 28 04:29:09 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DDEE29C7; Sun, 28 Jul 2013 04:29:09 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2C7422074; Sun, 28 Jul 2013 04:29:09 +0000 (UTC) Received: by mail-wg0-f51.google.com with SMTP id a12so166239wgh.18 for ; Sat, 27 Jul 2013 21:29:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3fbgSisgCmiyIlCRHbhkR7+t0j1GMd0Np8AlAtf9Fqc=; b=aGpEhuXwovZB3cjLg9h78FeSVkdC4BptzNrSkiW1Jcii686oyevKsWLmIFCLayLBs/ taXEow2r6PNxjNOfYcJYO6wgOSZIfQWi5tWM++DEgmo+8wrE/ssqDWCplHi4vRLdW+Eb O6f5opY8/LNnlid56TrIILl1ha08Da/UsIT008PQzjCR0MqqJ6xMipPR8EYLJSnL+eIt yhufzTXLlrdIhfatq8OkJzfLeQy5rN1S6CclnRC0ayeX9eiPfcEYZdC9HPYw5MQF5Z0a Or7B3uP02ytM5YoOrlR2fox4orOFEE9ppPH5NS98eYNvT6kCOMOrVbmzQMUewsnl7wyL LUCg== MIME-Version: 1.0 X-Received: by 10.194.203.73 with SMTP id ko9mr284376wjc.79.1374985747503; Sat, 27 Jul 2013 21:29:07 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Sat, 27 Jul 2013 21:29:07 -0700 (PDT) In-Reply-To: References: <1374573600-2351360719.d37ada5f86@bliksem.vehosting.nl> <201307231220.52817.Daan@vitsch.nl> Date: Sat, 27 Jul 2013 21:29:07 -0700 X-Google-Sender-Auth: ovnjjrr0zOPS-TibZ_pKUS2ID6I Message-ID: Subject: Re: My WLI-UC-GNM up crash From: Adrian Chadd To: XiaoQI Ge Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arm , freebsd-wireless@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 04:29:10 -0000 Not sure, I haven't dug into it. It shouldn't be hard to fix though. I think someone just screwed up in defining the structures in the USB drivers and didn't specify alignment. ath(4) got it right because Sam ran it on MIPS/ARM boards. -adrian On 27 July 2013 20:34, XiaoQI Ge wrote: > That should be how to solve it? > -- > Regards. > By: XiaoQI Ge; PGP:8B09D5F7 > WWW: https://www.7axu.com/ > > > > 2013/7/27 Adrian Chadd : >> This is known; there's some alignment issue with the radiotap TX/RX >> structures in some of these USB devices. >> >> >> >> -adrain >> >> On 25 July 2013 20:23, XiaoQI Ge wrote: >>> =CE=D2=B8=FC=D0=C2=B5=BD=D7=EE=D0=C2=B5=C4=D4=B4=C2=EB=A3=A8r253662=A3= =A9=A3=AC=D5=E2=B4=CE=B4=ED=CE=F3=D0=C5=CF=A2=B1=E4=B3=C9=C1=CB0xde9f4d34 >>> >>> [root@FreeBSD.ttyu0] ~ # Fatal kernel mode data abort: 'Alignment Fault= 1' >>> trapframe: 0xde9f4d34 >>> FSR=3D00000801, FAR=3Dc284afbb, spsr=3D00000013 >>> r0 =3Dc284c000, r1 =3Dc284afbb, r2 =3Dc284c210, r3 =3D0000096c >>> r4 =3Dc284c024, r5 =3Dc05f07c5, r6 =3D00000014, r7 =3Dc2844800 >>> r8 =3Dc05f07c5, r9 =3Dc284c000, r10=3D000035cb, r11=3Dde9f4e10 >>> r12=3D0000002e, ssp=3Dde9f4d80, slr=3D00000000, pc =3Dc046d20c >>> >>> [ thread pid 0 tid 100053 ] >>> Stopped at ieee80211_radiotap_chan_change+0x90: strh r3, [r1= ] >>> db> >>> --- >>> Kernel wlan related options >>> device wlan # 802.11 support >>> options IEEE80211_DEBUG # enable debug msgs >>> options IEEE80211_AMPDU_AGE # age frames in AMPDU reorder q's >>> options IEEE80211_SUPPORT_MESH # enable 802.11s draft support >>> device wlan_wep # 802.11 WEP support >>> device wlan_ccmp # 802.11 CCMP support >>> device wlan_tkip # 802.11 TKIP support >>> device wlan_amrr # AMRR transmit rate control algorithm >>> device firmware # firmware assist module >>> device run #Ralink Technology USB IEEE 802.11a/g/n >>> wireless network device >>> device runfw #Firmware Module for Ralink driver >>> >>> --- >>> The compiler command >>> make TARGET_ARCH=3Darmv6 TARGET_CPUTYPE=3Darmv6 KERNCONF=3DBBB WITH_FDT= =3Dyes >>> buildkernel >>> -- >>> Regards. >>> By: XiaoQI Ge; PGP:8B09D5F7 >>> WWW: https://www.7axu.com/ >>> >>> >>> >>> 2013/7/24 XiaoQI Ge : >>>> How do I debug it? Can provide useful information >>>> >>>> login: root >>>> Jul 24 18:27:31 FreeBSD login: ROOT LOGIN (root) ON ttyu0 >>>> FreeBSD 10.0-CURRENT (BBB) #4 r253585M: Wed Jul 24 17:07:53 CST 2013 >>>> [root@FreeBSD.ttyu0] ~ # ifconfig wlan create wlandev run0 >>>> wlan0: Ethernet address: 10:6f:3f:2b:fd:6d >>>> wlan0 >>>> [root@FreeBSD.ttyu0] ~ # ifconfig wlan0 up >>>> run0: firmware RT2870 ver. 0.236 loaded >>>> Fatal kernel mode data abort: 'Alignment Fault 1' >>>> trapframe: 0xde9e4d5c >>>> FSR=3D00000801, FAR=3Dc282ffbb, spsr=3D00000013 >>>> r0 =3Dc2831000, r1 =3Dc282ffbb, r2 =3Dc2831210, r3 =3D0000096c >>>> r4 =3Dc2831024, r5 =3Dc2831000, r6 =3Dc05d9362, r7 =3Dc2829800 >>>> r8 =3D00000014, r9 =3Dc08144d8, r10=3D80001cce, r11=3Dde9e4e10 >>>> r12=3D0000002e, ssp=3Dde9e4da8, slr=3D00000000, pc =3Dc045c510 >>>> >>>> [ thread pid 0 tid 100053 ] >>>> Stopped at ieee80211_radiotap_chan_change+0x90: strh r3, [r= 1] >>>> db> >>>> >>>> >>>> These two places modified: >>>> 2522 } >>>> 2523 >>>> 2524 ant =3D run_maxrssi_chain(sc, rxwi); >>>> 2525 rssi =3D rxwi->rssi[ant]; >>>> 2526 nf =3D run_rssi2dbm(sc, rssi, ant); >>>> 2527 >>>> 2528 m->m_pkthdr.rcvif =3D ifp; >>>> 2529 m->m_pkthdr.len =3D m->m_len =3D len; >>>> 2530 /* >>>> 2531 if (ni !=3D NULL) { >>>> 2532 (void)ieee80211_input(ni, m, rssi, nf); >>>> 2533 ieee80211_free_node(ni); >>>> 2534 } else { >>>> 2535 (void)ieee80211_input_all(ic, m, rssi, nf); >>>> 2536 } >>>> 2537 */ >>>> 2538 /* >>>> 2539 * DAAN: fill-in tap header BEFORE calling ieee80211_input*()= so the >>>> 2540 * user will see the actual data that belongs to THIS packet.= . >>>> 2541 */ >>>> 2542 if (__predict_false(ieee80211_radiotap_active(ic))) { >>>> 2543 struct run_rx_radiotap_header *tap =3D &sc->sc_rxtap; >>>> 2544 >>>> 2545 tap->wr_flags =3D 0; >>>> 2546 tap->wr_chan_freq =3D htole16(ic->ic_curchan->ic_freq); >>>> 2547 tap->wr_chan_flags =3D htole16(ic->ic_curchan->ic_flags); >>>> 2548 tap->wr_antsignal =3D rssi; >>>> 2549 tap->wr_antenna =3D ant; >>>> 2550 tap->wr_dbm_antsignal =3D run_rssi2dbm(sc, rssi, ant); >>>> 2551 tap->wr_rate =3D 2; /* in case it can't be found below = */ >>>> 2552 phy =3D le16toh(rxwi->phy); >>>> 2553 switch (phy & RT2860_PHY_MODE) { >>>> 2554 case RT2860_PHY_CCK: >>>> 2555 switch ((phy & RT2860_PHY_MCS) & ~RT2860_PHY_SHPRE) { >>>> 2556 case 0: tap->wr_rate =3D 2; break; >>>> 2557 case 1: tap->wr_rate =3D 4; break; >>>> 2558 case 2: tap->wr_rate =3D 11; break; >>>> 2559 case 3: tap->wr_rate =3D 22; break; >>>> 2560 } >>>> 2561 if (phy & RT2860_PHY_SHPRE) >>>> 2562 tap->wr_flags |=3D IEEE80211_RADIOTAP_F_SHORTPRE; >>>> 2563 break; >>>> 2564 case RT2860_PHY_OFDM: >>>> 2565 switch (phy & RT2860_PHY_MCS) { >>>> 2566 case 0: tap->wr_rate =3D 12; break; >>>> 2567 case 1: tap->wr_rate =3D 18; break; >>>> 2568 case 2: tap->wr_rate =3D 24; break; >>>> 2569 case 3: tap->wr_rate =3D 36; break; >>>> 2570 case 4: tap->wr_rate =3D 48; break; >>>> 2571 case 5: tap->wr_rate =3D 72; break; >>>> 2572 case 6: tap->wr_rate =3D 96; break; >>>> 2573 case 7: tap->wr_rate =3D 108; break; >>>> 2574 } >>>> 2575 break; >>>> 2576 } >>>> 2577 } >>>> 2578 >>>> 2579 if (ni !=3D NULL) { >>>> 2580 (void)ieee80211_input(ni, m, rssi, nf); >>>> 2581 ieee80211_free_node(ni); >>>> 2582 } else { >>>> 2583 (void)ieee80211_input_all(ic, m, rssi, nf); >>>> 2584 } >>>> 2585 >>>> 2586 } >>>> 2587 >>>> 2588 static void >>>> >>>> >>>> Index: sys/vm/vm_map.c >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> --- sys/vm/vm_map.c (revision 253514) >>>> +++ sys/vm/vm_map.c (working copy) >>>> @@ -239,8 +239,7 @@ >>>> vm_map_t map; >>>> >>>> map =3D (vm_map_t)mem; >>>> - map->nentries =3D 0; >>>> - map->size =3D 0; >>>> + memset(map, 0, sizeof(*map)); >>>> mtx_init(&map->system_mtx, "vm map (system)", NULL, MTX_DEF | >>>> MTX_DUPOK); >>>> sx_init(&map->lock, "vm map (user)"); >>>> return (0); >>>> >>>> -- >>>> Regards. >>>> By: XiaoQI Ge; PGP:8B09D5F7 >>>> WWW: https://www.7axu.com/ >>>> >>>> >>>> >>>> 2013/7/24 XiaoQI Ge : >>>>> I manually make up, is compiling the kernel >>>>> -- >>>>> Regards. >>>>> By: XiaoQI Ge; PGP:8B09D5F7 >>>>> WWW: https://www.7axu.com/ >>>>> >>>>> >>>>> >>>>> 2013/7/24 XiaoQI Ge : >>>>>> patch < /root/if_run_2013_01_19_radiotap_fix_only.diff appears to b= e invalid >>>>>> >>>>>> ] /usr/src/sys/dev/usb/wlan # patch < >>>>>> /root/if_run_2013_01_19_radiotap_fix_only.diff >>>>>> Hmm... Looks like a unified diff to me... >>>>>> The text leading up to this was: >>>>>> -------------------------- >>>>>> |--- if_run.c.fix1_vnet 2013-06-14 10:12:49.786774072 +0200 >>>>>> |+++ if_run.c.fix2_vnet_plus_radiotap 2013-06-14 10:15:34.89077431= 4 +0200 >>>>>> -------------------------- >>>>>> File to patch: >>>>>> >>>>>> >>>>>> 2013/7/23 Daan Vreeken : >>>>>>> cd /usr/src/sys/dev/usb/wlan >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Regards. >>>>>> By: XiaoQI Ge; PGP:8B09D5F7 >>>>>> WWW: https://www.7axu.com/ >>> _______________________________________________ >>> freebsd-wireless@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-wireless >>> To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.= org" From owner-freebsd-arm@FreeBSD.ORG Sun Jul 28 05:51:33 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2185D96C for ; Sun, 28 Jul 2013 05:51:33 +0000 (UTC) (envelope-from rpaulo@felyko.com) Received: from felyko.com (felyko.com [174.136.100.2]) by mx1.freebsd.org (Postfix) with ESMTP id 065D121BB for ; Sun, 28 Jul 2013 05:51:32 +0000 (UTC) Received: from [IPv6:2601:9:4d00:119:7114:a5a0:cbe8:5309] (unknown [IPv6:2601:9:4d00:119:7114:a5a0:cbe8:5309]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id 3E1503982B for ; Sat, 27 Jul 2013 22:51:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=felyko.com; s=mail; t=1374990692; bh=YSWozDLkZJRkaGbSK8zPnkCbPFDvnRzfwW8UoYG8p7k=; h=Subject:From:In-Reply-To:Date:References:To; b=TLLyNVCPXl0s0grAFdQ67jOtsv7Gdpo3yjo29O50pjF4SA+0jIZE5A9WP1r5H/RhM TvN5KOu279y4Y1YY7bp1eP7ivtXzPy1PHTctNn4w3jsIinYR3EJa2Prs2mvpSkXRuK jvDnzD0rz0sSdPEj04wn9ziy++pKZJH3syej3Zs0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: External Non-Linefetch Abort (S) From: Rui Paulo In-Reply-To: <3C6B0B0D-3F16-44A5-8DF2-A79CBD0D02D3@felyko.com> Date: Sat, 27 Jul 2013 22:51:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3C6B0B0D-3F16-44A5-8DF2-A79CBD0D02D3@felyko.com> To: "freebsd-arm@freebsd.org" X-Mailer: Apple Mail (2.1508) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 05:51:33 -0000 On 27 Jul 2013, at 20:33, Rui Paulo wrote: > On the BeagleBone, I'm trying to access this address 0x4a300000. I = know there is a device there (the PRUSS) and I should be able to access = it, but instead I get this data abort trap: >=20 > Fatal kernel mode data abort: 'External Non-Linefetch Abort (S)' > trapframe: 0xc08c5c84 > FSR=3D00001008, FAR=3Dd4a5c000, spsr=3D60000093 > r0 =3D00000000, r1 =3Dd4a5c000, r2 =3D00000000, r3 =3Dc062a908 > r4 =3D00000000, r5 =3Dc08c5ce4, r6 =3Dc1825500, r7 =3Dc18eb700 > r8 =3Dffffffff, r9 =3Dc1825d80, r10=3Dc1825500, r11=3Dc05511e0 > r12=3D00000015, ssp=3Dc08c5cd0, slr=3Dc052f1b0, pc =3Dc050bf78 >=20 > [ thread pid 0 tid 100000 ] > Stopped at generic_bs_r_4: ldr r0, [r1, r2] >=20 > It looks like 0xd4a5c000 is the virtual address that points to = 0x4a300000 (I checked with vtophys()). >=20 > Does anyone know what this problem could be? I made sure the clock for = this device are running. Nevermind, I missed one PRCM bit... -- Rui Paulo From owner-freebsd-arm@FreeBSD.ORG Sun Jul 28 09:23:01 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 80552FAD; Sun, 28 Jul 2013 09:23:01 +0000 (UTC) (envelope-from hans.petter.selasky@bitfrost.no) Received: from mta.bitpro.no (mta.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id 6422C2688; Sun, 28 Jul 2013 09:22:59 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta.bitpro.no (Postfix) with ESMTP id 438707A26F; Sun, 28 Jul 2013 11:22:59 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id 478288F04D5; Sun, 28 Jul 2013 11:23:04 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no Received: from mail.lockless.no ([127.0.0.1]) by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kf76i5NiuR3I; Sun, 28 Jul 2013 11:23:02 +0200 (CEST) Received: from mail.lockless.no (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id 0C63A8F04D4; Sun, 28 Jul 2013 11:23:02 +0200 (CEST) Subject: RE: My WLI-UC-GNM up crash From: =?utf-8?Q?Hans_Petter_Selasky?= To: =?utf-8?Q?Adrian_Chadd?= , =?utf-8?Q?XiaoQI_Ge?= , =?utf-8?Q?sam=40freebsd=2Eorg?= Date: Sun, 28 Jul 2013 11:23:01 +0200 Mime-Version: 1.0 In-Reply-To: References: X-Priority: 3 (Normal) X-Mailer: Zarafa 7.1.4-41394 Message-Id: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: =?utf-8?Q?freebsd-arm?= , =?utf-8?Q?freebsd-wireless=40freebsd=2Eorg?= X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 09:23:01 -0000 This patch=3F=0D=0A=0D=0Acommit bae4e38c197f464c4bffe7037d5d491e462105b0=0D= =0AAuthor: sam =0D=0ADate: Thu Apr 1 00:38:45 2004 +00= 00=0D=0A=0D=0A radiotap updates:=0D=0A =20=0D=0A o force little-e= ndian byte order for header=0D=0A o pad header to 32-bit boundary to g= uard against applications that assume=0D=0A packet data alignment=0D= =0A=0D=0A--HPS=0D=0A=20=0D=0A=20=0D=0A-----Original message-----=0D=0A> F= rom:Adrian Chadd >=0D=0A>= Sent: Sunday 28th July 2013 6:29=0D=0A> To: XiaoQI Ge >=0D=0A> Cc: freebsd-arm >; freebsd-wireless@freebsd.org =20=0D=0A> Subject: Re: My WLI-UC-GNM up crash=0D= =0A>=20=0D=0A> Not sure, I haven't dug into it. It shouldn't be hard to f= ix though.=0D=0A>=20=0D=0A> I think someone just screwed up in defining t= he structures in the USB=0D=0A> drivers and didn't specify alignment. ath= (4) got it right because Sam=0D=0A> ran it on MIPS/ARM boards.=0D=0A>=20=0D= =0A>=20=0D=0A>=20=0D=0A> -adrian=0D=0A>=20=0D=0A> On 27 July 2013 20:34, = XiaoQI Ge > wrote:=0D=0A> > That shou= ld be how to solve it=3F=0D=0A> > --=0D=0A> > Regards.=0D=0A> > By: XiaoQ= I Ge; PGP:8B09D5F7=0D=0A> > WWW: https://www.7axu.com/=0D=0A> >=0D=0A> >=0D= =0A> >=0D=0A> > 2013/7/27 Adrian Chadd >:=0D=0A> >> This is known; there's some alignment issue wi= th the radiotap TX/RX=0D=0A> >> structures in some of these USB devices.=0D= =0A> >>=0D=0A> >>=0D=0A> >>=0D=0A> >> -adrain=0D=0A> >>=0D=0A> >> On 25 J= uly 2013 20:23, XiaoQI Ge > wrote:=0D= =0A> >>> =E6=88=91=E6=9B=B4=E6=96=B0=E5=88=B0=E6=9C=80=E6=96=B0=E7=9A=84=E6= =BA=90=E7=A0=81=EF=BC=88r253662=EF=BC=89=EF=BC=8C=E8=BF=99=E6=AC=A1=E9=94= =99=E8=AF=AF=E4=BF=A1=E6=81=AF=E5=8F=98=E6=88=90=E4=BA=860xde9f4d34=0D=0A= > >>>=0D=0A> >>> [root@FreeBSD.ttyu0 ] =CB=9C= # Fatal kernel mode data abort: 'Alignment Fault 1'=0D=0A> >>> trapframe= : 0xde9f4d34=0D=0A> >>> FSR=3D00000801, FAR=3Dc284afbb, spsr=3D00000013=0D= =0A> >>> r0 =3Dc284c000, r1 =3Dc284afbb, r2 =3Dc284c210, r3 =3D0000096c=0D= =0A> >>> r4 =3Dc284c024, r5 =3Dc05f07c5, r6 =3D00000014, r7 =3Dc2844800=0D= =0A> >>> r8 =3Dc05f07c5, r9 =3Dc284c000, r10=3D000035cb, r11=3Dde9f4e10=0D= =0A> >>> r12=3D0000002e, ssp=3Dde9f4d80, slr=3D00000000, pc =3Dc046d20c=0D= =0A> >>>=0D=0A> >>> [ thread pid 0 tid 100053 ]=0D=0A> >>> Stopped at = ieee80211_radiotap_chan_change+0x90: strh r3, [r1]=0D=0A> >>> db>= =0D=0A> >>> ---=0D=0A> >>> Kernel wlan related options=0D=0A> >>> device = wlan # 802.11 support=0D=0A> >>> options IEEE= 80211_DEBUG # enable debug msgs=0D=0A> >>> options IEEE80211_AMPD= U_AGE # age frames in AMPDU reorder q's=0D=0A> >>> options IEEE80= 211_SUPPORT_MESH # enable 802.11s draft support=0D=0A> >>> device = wlan_wep # 802.11 WEP support=0D=0A> >>> device wlan_c= cmp # 802.11 CCMP support=0D=0A> >>> device wlan_tkip = # 802.11 TKIP support=0D=0A> >>> device wlan_amrr # AMRR= transmit rate control algorithm=0D=0A> >>> device firmware = # firmware assist module=0D=0A> >>> device run #Ralink Te= chnology USB IEEE 802.11a/g/n=0D=0A> >>> wireless network device=0D=0A> >= >> device runfw #Firmware Module for Ralink driver=0D=0A> >>>=0D= =0A> >>> ---=0D=0A> >>> The compiler command=0D=0A> >>> make TARGET_ARCH=3D= armv6 TARGET_CPUTYPE=3Darmv6 KERNCONF=3DBBB WITH_FDT=3Dyes=0D=0A> >>> bui= ldkernel=0D=0A> >>> --=0D=0A> >>> Regards.=0D=0A> >>> By: XiaoQI Ge; PGP:= 8B09D5F7=0D=0A> >>> WWW: https://www.7axu.com/=0D=0A> >>>=0D=0A> >>>=0D=0A= > >>>=0D=0A> >>> 2013/7/24 XiaoQI Ge = >:=0D=0A> >>>> How do I debug it=3F Can provide useful information=0D=0A>= >>>>=0D=0A> >>>> login: root=0D=0A> >>>> Jul 24 18:27:31 FreeBSD login: = ROOT LOGIN (root) ON ttyu0=0D=0A> >>>> FreeBSD 10.0-CURRENT (BBB) #4 r253= 585M: Wed Jul 24 17:07:53 CST 2013=0D=0A> >>>> [root@FreeBSD.ttyu0 ] =CB=9C # ifconfig wlan create wlandev run0=0D=0A>= >>>> wlan0: Ethernet address: 10:6f:3f:2b:fd:6d=0D=0A> >>>> wlan0=0D=0A>= >>>> [root@FreeBSD.ttyu0 ] =CB=9C # ifconfig= wlan0 up=0D=0A> >>>> run0: firmware RT2870 ver. 0.236 loaded=0D=0A> >>>>= Fatal kernel mode data abort: 'Alignment Fault 1'=0D=0A> >>>> trapframe:= 0xde9e4d5c=0D=0A> >>>> FSR=3D00000801, FAR=3Dc282ffbb, spsr=3D00000013=0D= =0A> >>>> r0 =3Dc2831000, r1 =3Dc282ffbb, r2 =3Dc2831210, r3 =3D0000096c=0D= =0A> >>>> r4 =3Dc2831024, r5 =3Dc2831000, r6 =3Dc05d9362, r7 =3Dc2829800=0D= =0A> >>>> r8 =3D00000014, r9 =3Dc08144d8, r10=3D80001cce, r11=3Dde9e4e10=0D= =0A> >>>> r12=3D0000002e, ssp=3Dde9e4da8, slr=3D00000000, pc =3Dc045c510=0D= =0A> >>>>=0D=0A> >>>> [ thread pid 0 tid 100053 ]=0D=0A> >>>> Stopped at = ieee80211_radiotap_chan_change+0x90: strh r3, [r1]=0D=0A> >>>>= db>=0D=0A> >>>>=0D=0A> >>>>=0D=0A> >>>> These two places modified:=0D=0A= > >>>> 2522 }=0D=0A> >>>> 2523=0D=0A> >>>> 2524 ant =3D run_maxrs= si_chain(sc, rxwi);=0D=0A> >>>> 2525 rssi =3D rxwi->rssi[ant];=0D=0A>= >>>> 2526 nf =3D run_rssi2dbm(sc, rssi, ant);=0D=0A> >>>> 2527=0D=0A= > >>>> 2528 m->m_pkthdr.rcvif =3D ifp;=0D=0A> >>>> 2529 m->m_pkth= dr.len =3D m->m_len =3D len;=0D=0A> >>>> 2530 /*=0D=0A> >>>> 2531 if = (ni !=3D NULL) {=0D=0A> >>>> 2532 (void)ieee80211_input(ni, m, rs= si, nf);=0D=0A> >>>> 2533 ieee80211_free_node(ni);=0D=0A> >>>> 25= 34 } else {=0D=0A> >>>> 2535 (void)ieee80211_input_all(ic, m,= rssi, nf);=0D=0A> >>>> 2536 }=0D=0A> >>>> 2537 */=0D=0A> >>>> 2538 = /*=0D=0A> >>>> 2539 * DAAN: fill-in tap header BEFORE calling iee= e80211_input*() so the=0D=0A> >>>> 2540 * user will see the actual d= ata that belongs to THIS packet..=0D=0A> >>>> 2541 */=0D=0A> >>>> 25= 42 if (__predict_false(ieee80211_radiotap_active(ic))) {=0D=0A> >>>> = 2543 struct run_rx_radiotap_header *tap =3D &sc->sc_rxtap;=0D=0A>= >>>> 2544=0D=0A> >>>> 2545 tap->wr_flags =3D 0;=0D=0A> >>>> 2546= tap->wr_chan_freq =3D htole16(ic->ic_curchan->ic_freq);=0D=0A> >= >>> 2547 tap->wr_chan_flags =3D htole16(ic->ic_curchan->ic_flags)= ;=0D=0A> >>>> 2548 tap->wr_antsignal =3D rssi;=0D=0A> >>>> 2549 = tap->wr_antenna =3D ant;=0D=0A> >>>> 2550 tap->wr_dbm_ants= ignal =3D run_rssi2dbm(sc, rssi, ant);=0D=0A> >>>> 2551 tap->wr_r= ate =3D 2; /* in case it can't be found below */=0D=0A> >>>> 2552 = phy =3D le16toh(rxwi->phy);=0D=0A> >>>> 2553 switch (phy & RT2= 860_PHY_MODE) {=0D=0A> >>>> 2554 case RT2860_PHY_CCK:=0D=0A> >>>>= 2555 switch ((phy & RT2860_PHY_MCS) & =CB=9CRT2860_PHY_SHPRE= ) {=0D=0A> >>>> 2556 case 0: tap->wr_rate =3D 2; break;=0D=0A= > >>>> 2557 case 1: tap->wr_rate =3D 4; break;=0D=0A> >>>> = 2558 case 2: tap->wr_rate =3D 11; break;=0D=0A> >>>> 2559 = case 3: tap->wr_rate =3D 22; break;=0D=0A> >>>> 2560 = }=0D=0A> >>>> 2561 if (phy & RT2860_PHY_SHPRE)=0D=0A> >>>>= 2562 tap->wr_flags |=3D IEEE80211_RADIOTAP_F_SHORTPRE;=0D= =0A> >>>> 2563 break;=0D=0A> >>>> 2564 case RT2860_PH= Y_OFDM:=0D=0A> >>>> 2565 switch (phy & RT2860_PHY_MCS) {=0D=0A= > >>>> 2566 case 0: tap->wr_rate =3D 12; break;=0D=0A> >>>> = 2567 case 1: tap->wr_rate =3D 18; break;=0D=0A> >>>> 2568 = case 2: tap->wr_rate =3D 24; break;=0D=0A> >>>> 2569 = case 3: tap->wr_rate =3D 36; break;=0D=0A> >>>> 2570 case= 4: tap->wr_rate =3D 48; break;=0D=0A> >>>> 2571 case 5: tap= ->wr_rate =3D 72; break;=0D=0A> >>>> 2572 case 6: tap->wr_ra= te =3D 96; break;=0D=0A> >>>> 2573 case 7: tap->wr_rate =3D = 108; break;=0D=0A> >>>> 2574 }=0D=0A> >>>> 2575 b= reak;=0D=0A> >>>> 2576 }=0D=0A> >>>> 2577 }=0D=0A> >>>> 2578=0D= =0A> >>>> 2579 if (ni !=3D NULL) {=0D=0A> >>>> 2580 (void)iee= e80211_input(ni, m, rssi, nf);=0D=0A> >>>> 2581 ieee80211_free_no= de(ni);=0D=0A> >>>> 2582 } else {=0D=0A> >>>> 2583 (void)ieee= 80211_input_all(ic, m, rssi, nf);=0D=0A> >>>> 2584 }=0D=0A> >>>> 2585= =0D=0A> >>>> 2586 }=0D=0A> >>>> 2587=0D=0A> >>>> 2588 static void=0D=0A> = >>>>=0D=0A> >>>>=0D=0A> >>>> Index: sys/vm/vm_map.c=0D=0A> >>>> =3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0D=0A> >>>> --- sys/vm/vm_map.= c (revision 253514)=0D=0A> >>>> +++ sys/vm/vm_map.c (working copy= )=0D=0A> >>>> @@ -239,8 +239,7 @@=0D=0A> >>>> vm_map_t map;=0D=0A= > >>>>=0D=0A> >>>> map =3D (vm_map_t)mem;=0D=0A> >>>> - map= ->nentries =3D 0;=0D=0A> >>>> - map->size =3D 0;=0D=0A> >>>> + = memset(map, 0, sizeof(*map));=0D=0A> >>>> mtx_init(&map->system= _mtx, "vm map (system)", NULL, MTX_DEF |=0D=0A> >>>> MTX_DUPOK);=0D=0A> >= >>> sx_init(&map->lock, "vm map (user)");=0D=0A> >>>> ret= urn (0);=0D=0A> >>>>=0D=0A> >>>> --=0D=0A> >>>> Regards.=0D=0A> >>>> By: = XiaoQI Ge; PGP:8B09D5F7=0D=0A> >>>> WWW: https://www.7axu.com/=0D=0A> >>>= >=0D=0A> >>>>=0D=0A> >>>>=0D=0A> >>>> 2013/7/24 XiaoQI Ge >:=0D=0A> >>>>> I manually make up, is compiling the= kernel=0D=0A> >>>>> --=0D=0A> >>>>> Regards.=0D=0A> >>>>> By: XiaoQI Ge;= PGP:8B09D5F7=0D=0A> >>>>> WWW: https://www.7axu.com/=0D=0A> >>>>>=0D=0A>= >>>>>=0D=0A> >>>>>=0D=0A> >>>>> 2013/7/24 XiaoQI Ge >:=0D=0A> >>>>>> patch < /root/if_run_2013_01_19_radiota= p_fix_only.diff appears to be invalid=0D=0A> >>>>>>=0D=0A> >>>>>> ] /usr/= src/sys/dev/usb/wlan # patch <=0D=0A> >>>>>> /root/if_run_2013_01_19_radi= otap_fix_only.diff=0D=0A> >>>>>> Hmm... Looks like a unified diff to me.= =2E.=0D=0A> >>>>>> The text leading up to this was:=0D=0A> >>>>>> -------= -------------------=0D=0A> >>>>>> |--- if_run.c.fix1_vnet 2013-06-14 10:1= 2:49.786774072 +0200=0D=0A> >>>>>> |+++ if_run.c.fix2_vnet_plus_radiotap = 2013-06-14 10:15:34.890774314 +0200=0D=0A> >>>>>> ---------------------= -----=0D=0A> >>>>>> File to patch:=0D=0A> >>>>>>=0D=0A> >>>>>>=0D=0A> >>>= >>> 2013/7/23 Daan Vreeken >:=0D=0A= > >>>>>>> cd /usr/src/sys/dev/usb/wlan=0D=0A> >>>>>>=0D=0A> >>>>>>=0D=0A>= >>>>>>=0D=0A> >>>>>> --=0D=0A> >>>>>> Regards.=0D=0A> >>>>>> By: XiaoQI = Ge; PGP:8B09D5F7=0D=0A> >>>>>> WWW: https://www.7axu.com/=0D=0A> >>> ____= ___________________________________________=0D=0A> >>> freebsd-wireless@f= reebsd.org mailing list=0D=0A> >>>= http://lists.freebsd.org/mailman/listinfo/freebsd-wireless =20=0D=0A> >>> To unsubs= cribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org "=0D=0A> _____________________= __________________________=0D=0A> freebsd-arm@freebsd.org mailing list=0D=0A> http://lists.freebsd.org/mailman/l= istinfo/freebsd-arm =20=0D=0A> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@fr= eebsd.org "=0D=0A=0D=0A From owner-freebsd-arm@FreeBSD.ORG Sun Jul 28 10:12:12 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9E833695; Sun, 28 Jul 2013 10:12:12 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 218C527C5; Sun, 28 Jul 2013 10:12:11 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6SAC5cf064573; Sun, 28 Jul 2013 06:12:05 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6SAC4eG064567; Sun, 28 Jul 2013 10:12:04 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 28 Jul 2013 10:12:04 GMT Message-Id: <201307281012.r6SAC4eG064567@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 10:12:12 -0000 TB --- 2013-07-28 07:10:24 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-28 07:10:24 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-28 07:10:24 - starting HEAD tinderbox run for arm/arm TB --- 2013-07-28 07:10:24 - cleaning the object tree TB --- 2013-07-28 07:10:24 - /usr/local/bin/svn stat /src TB --- 2013-07-28 07:10:29 - At svn revision 253737 TB --- 2013-07-28 07:10:30 - building world TB --- 2013-07-28 07:10:30 - CROSS_BUILD_TESTING=YES TB --- 2013-07-28 07:10:30 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-28 07:10:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-28 07:10:30 - SRCCONF=/dev/null TB --- 2013-07-28 07:10:30 - TARGET=arm TB --- 2013-07-28 07:10:30 - TARGET_ARCH=arm TB --- 2013-07-28 07:10:30 - TZ=UTC TB --- 2013-07-28 07:10:30 - __MAKE_CONF=/dev/null TB --- 2013-07-28 07:10:30 - cd /src TB --- 2013-07-28 07:10:30 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Jul 28 07:10:38 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -o watch watch.o -ltermcap gzip -cn /src/usr.sbin/watch/watch.8 > watch.8.gz ===> usr.sbin/watchdogd (all) cc -O -pipe -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -c /src/usr.sbin/watchdogd/watchdogd.c /src/usr.sbin/watchdogd/watchdogd.c:236:17: error: format specifies type 'long' but the argument has type 'time_t' (aka 'long long') [-Werror,-Wformat] myoptarg, ts.tv_sec, ts.tv_nsec, ticks); ^~~~~~~~~ 1 error generated. *** Error code 1 Stop. bmake: stopped in /src/usr.sbin/watchdogd *** Error code 1 Stop. bmake: stopped in /src/usr.sbin *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-28 10:12:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-28 10:12:04 - ERROR: failed to build world TB --- 2013-07-28 10:12:04 - 8654.73 user 1520.51 system 10900.89 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sun Jul 28 10:33:51 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AC7D2D5A; Sun, 28 Jul 2013 10:33:51 +0000 (UTC) (envelope-from hps@bitfrost.no) Received: from mta.bitpro.no (mta.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id 207BB289E; Sun, 28 Jul 2013 10:33:50 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta.bitpro.no (Postfix) with ESMTP id 0DC197A270; Sun, 28 Jul 2013 12:33:49 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id 1C4C88F04E2; Sun, 28 Jul 2013 12:33:54 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no Received: from mail.lockless.no ([127.0.0.1]) by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyuxMI1VnXwj; Sun, 28 Jul 2013 12:33:53 +0200 (CEST) Received: from laptop015.hselasky.homeunix.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) by mail.lockless.no (Postfix) with ESMTPSA id D4CAA8F04E1; Sun, 28 Jul 2013 12:33:52 +0200 (CEST) Message-ID: <51F4F3E9.9010605@bitfrost.no> Date: Sun, 28 Jul 2013 12:35:21 +0200 From: Hans Petter Selasky Organization: Bitfrost A/S User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130522 Thunderbird/17.0.6 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: My WLI-UC-GNM up crash References: <1374573600-2351360719.d37ada5f86@bliksem.vehosting.nl> <201307231220.52817.Daan@vitsch.nl> In-Reply-To: Content-Type: multipart/mixed; boundary="------------090509080502000108040303" Cc: freebsd-arm , freebsd-wireless@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 10:33:51 -0000 This is a multi-part message in MIME format. --------------090509080502000108040303 Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Hi, Can you try the attached patch? --HPS --------------090509080502000108040303 Content-Type: text/x-patch; name="radiotap.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="radiotap.diff" === sys/dev/usb/wlan/if_rumvar.h ================================================================== --- sys/dev/usb/wlan/if_rumvar.h (revision 253548) +++ sys/dev/usb/wlan/if_rumvar.h (local) @@ -29,7 +29,7 @@ int8_t wr_antsignal; int8_t wr_antnoise; uint8_t wr_antenna; -}; +} __packed __aligned(8); #define RT2573_RX_RADIOTAP_PRESENT \ ((1 << IEEE80211_RADIOTAP_FLAGS) | \ @@ -47,7 +47,7 @@ uint16_t wt_chan_freq; uint16_t wt_chan_flags; uint8_t wt_antenna; -}; +} __packed __aligned(8); #define RT2573_TX_RADIOTAP_PRESENT \ ((1 << IEEE80211_RADIOTAP_FLAGS) | \ === sys/dev/usb/wlan/if_runvar.h ================================================================== --- sys/dev/usb/wlan/if_runvar.h (revision 253548) +++ sys/dev/usb/wlan/if_runvar.h (local) @@ -58,7 +58,7 @@ int8_t wr_dbm_antsignal; uint8_t wr_antenna; uint8_t wr_antsignal; -} __packed; +} __packed __aligned(8); #define RUN_RX_RADIOTAP_PRESENT \ (1 << IEEE80211_RADIOTAP_FLAGS | \ @@ -75,7 +75,7 @@ uint16_t wt_chan_freq; uint16_t wt_chan_flags; uint8_t wt_hwqueue; -} __packed; +} __packed __aligned(8); #define IEEE80211_RADIOTAP_HWQUEUE 15 === sys/dev/usb/wlan/if_uathvar.h ================================================================== --- sys/dev/usb/wlan/if_uathvar.h (revision 253548) +++ sys/dev/usb/wlan/if_uathvar.h (local) @@ -52,7 +52,7 @@ int8_t wr_antsignal; int8_t wr_antnoise; u_int8_t wr_antenna; -} __packed; +} __packed __aligned(8); #define UATH_RX_RADIOTAP_PRESENT ( \ (1 << IEEE80211_RADIOTAP_TSFT) | \ @@ -69,7 +69,7 @@ uint8_t wt_flags; uint16_t wt_chan_freq; uint16_t wt_chan_flags; -} __packed; +} __packed __aligned(8); #define UATH_TX_RADIOTAP_PRESENT \ ((1 << IEEE80211_RADIOTAP_FLAGS) | \ === sys/dev/usb/wlan/if_upgtvar.h ================================================================== --- sys/dev/usb/wlan/if_upgtvar.h (revision 253548) +++ sys/dev/usb/wlan/if_upgtvar.h (local) @@ -380,7 +380,7 @@ uint16_t wr_chan_freq; uint16_t wr_chan_flags; int8_t wr_antsignal; -} __packed; +} __packed __aligned(8); #define UPGT_RX_RADIOTAP_PRESENT \ ((1 << IEEE80211_RADIOTAP_FLAGS) | \ @@ -394,7 +394,7 @@ uint8_t wt_rate; uint16_t wt_chan_freq; uint16_t wt_chan_flags; -} __packed; +} __packed __aligned(8); #define UPGT_TX_RADIOTAP_PRESENT \ ((1 << IEEE80211_RADIOTAP_FLAGS) | \ === sys/dev/usb/wlan/if_uralvar.h ================================================================== --- sys/dev/usb/wlan/if_uralvar.h (revision 253548) +++ sys/dev/usb/wlan/if_uralvar.h (local) @@ -34,7 +34,7 @@ int8_t wr_antsignal; int8_t wr_antnoise; uint8_t wr_antenna; -}; +} __packed __aligned(8); #define RAL_RX_RADIOTAP_PRESENT \ ((1 << IEEE80211_RADIOTAP_FLAGS) | \ @@ -51,7 +51,7 @@ uint16_t wt_chan_freq; uint16_t wt_chan_flags; uint8_t wt_antenna; -}; +} __packed __aligned(8); #define RAL_TX_RADIOTAP_PRESENT \ ((1 << IEEE80211_RADIOTAP_FLAGS) | \ === sys/dev/usb/wlan/if_urtwnreg.h ================================================================== --- sys/dev/usb/wlan/if_urtwnreg.h (revision 253548) +++ sys/dev/usb/wlan/if_urtwnreg.h (local) @@ -1030,7 +1030,7 @@ uint16_t wr_chan_freq; uint16_t wr_chan_flags; uint8_t wr_dbm_antsignal; -} __packed; +} __packed __aligned(8); #define URTWN_RX_RADIOTAP_PRESENT \ (1 << IEEE80211_RADIOTAP_FLAGS | \ @@ -1043,7 +1043,7 @@ uint8_t wt_flags; uint16_t wt_chan_freq; uint16_t wt_chan_flags; -} __packed; +} __packed __aligned(8); #define URTWN_TX_RADIOTAP_PRESENT \ (1 << IEEE80211_RADIOTAP_FLAGS | \ === sys/dev/usb/wlan/if_urtwvar.h ================================================================== --- sys/dev/usb/wlan/if_urtwvar.h (revision 253548) +++ sys/dev/usb/wlan/if_urtwvar.h (local) @@ -63,7 +63,7 @@ uint16_t wr_chan_freq; uint16_t wr_chan_flags; int8_t wr_dbm_antsignal; -} __packed; +} __packed __aligned(8); #define URTW_RX_RADIOTAP_PRESENT \ ((1 << IEEE80211_RADIOTAP_FLAGS) | \ @@ -75,7 +75,7 @@ uint8_t wt_flags; uint16_t wt_chan_freq; uint16_t wt_chan_flags; -} __packed; +} __packed __aligned(8); #define URTW_TX_RADIOTAP_PRESENT \ ((1 << IEEE80211_RADIOTAP_FLAGS) | \ === sys/dev/usb/wlan/if_zydreg.h ================================================================== --- sys/dev/usb/wlan/if_zydreg.h (revision 253548) +++ sys/dev/usb/wlan/if_zydreg.h (local) @@ -1185,7 +1185,7 @@ uint16_t wr_chan_flags; int8_t wr_antsignal; int8_t wr_antnoise; -} __packed; +} __packed __aligned(8); #define ZYD_RX_RADIOTAP_PRESENT \ ((1 << IEEE80211_RADIOTAP_FLAGS) | \ @@ -1200,7 +1200,7 @@ uint8_t wt_rate; uint16_t wt_chan_freq; uint16_t wt_chan_flags; -} __packed; +} __packed __aligned(8); #define ZYD_TX_RADIOTAP_PRESENT \ ((1 << IEEE80211_RADIOTAP_FLAGS) | \ --------------090509080502000108040303-- From owner-freebsd-arm@FreeBSD.ORG Sun Jul 28 17:50:10 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 109C78DD; Sun, 28 Jul 2013 17:50:10 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6FA632384; Sun, 28 Jul 2013 17:50:09 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id hj13so119647wib.11 for ; Sun, 28 Jul 2013 10:50:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Dr/sF1MucNvTFmyLGpDlnNsfV8i75YDYJMkEok/Jl3g=; b=PMQEsGIwZSlZ8KTuBI9M88AEackxuRD2xfS94/P7B4SnnwFfFUzpF24Ciedx/+D8PG piaSc/EDzX/jMPael6Csf6f0Yb7OeDT3fftFSXq8DuPxJqujzW5MG9eQbtFSqm8B3ZYR SKUorgQJ9b6Y18/H9nnVF7ruyANkE23KshJj6PXHLxHGCIBuLF4gHHfmF/eEwXitaqKa OMWErlYkHWJh7zvzgbU9C5jQBZvlCvajnTvLjt1aq/6H02Li8TfwcoibYMHsk8HJT9bx Wrza7/CbmbcY8ud33PPczK+iRgesP1g7JJzQqCfTDNMH3iq2IwPVRZOGNKPI7kgni4Uy bRWw== MIME-Version: 1.0 X-Received: by 10.180.82.196 with SMTP id k4mr4880924wiy.0.1375033807662; Sun, 28 Jul 2013 10:50:07 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Sun, 28 Jul 2013 10:50:07 -0700 (PDT) In-Reply-To: <51F4F3E9.9010605@bitfrost.no> References: <1374573600-2351360719.d37ada5f86@bliksem.vehosting.nl> <201307231220.52817.Daan@vitsch.nl> <51F4F3E9.9010605@bitfrost.no> Date: Sun, 28 Jul 2013 10:50:07 -0700 X-Google-Sender-Auth: d8iUZNzunBc8Whk2H6Ryla1A5UU Message-ID: Subject: Re: My WLI-UC-GNM up crash From: Adrian Chadd To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arm , freebsd-wireless@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 17:50:10 -0000 As long as that results in the radiotap structures being 4 or 8 byte padded when it's embedded in the softc - then yes, indeed. Xiao, can you try? -adrian On 28 July 2013 03:35, Hans Petter Selasky wrote: > Hi, > > Can you try the attached patch? > > --HPS From owner-freebsd-arm@FreeBSD.ORG Sun Jul 28 18:37:10 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C077496A; Sun, 28 Jul 2013 18:37:10 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 783A2251B; Sun, 28 Jul 2013 18:37:10 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6SIb92t037979; Sun, 28 Jul 2013 14:37:09 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6SIb9X2037971; Sun, 28 Jul 2013 18:37:09 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 28 Jul 2013 18:37:09 GMT Message-Id: <201307281837.r6SIb9X2037971@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 18:37:10 -0000 TB --- 2013-07-28 15:30:19 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-28 15:30:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-28 15:30:19 - starting HEAD tinderbox run for arm/arm TB --- 2013-07-28 15:30:19 - cleaning the object tree TB --- 2013-07-28 15:35:55 - /usr/local/bin/svn stat /src TB --- 2013-07-28 15:35:58 - At svn revision 253742 TB --- 2013-07-28 15:35:59 - building world TB --- 2013-07-28 15:35:59 - CROSS_BUILD_TESTING=YES TB --- 2013-07-28 15:35:59 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-28 15:35:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-28 15:35:59 - SRCCONF=/dev/null TB --- 2013-07-28 15:35:59 - TARGET=arm TB --- 2013-07-28 15:35:59 - TARGET_ARCH=arm TB --- 2013-07-28 15:35:59 - TZ=UTC TB --- 2013-07-28 15:35:59 - __MAKE_CONF=/dev/null TB --- 2013-07-28 15:35:59 - cd /src TB --- 2013-07-28 15:35:59 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sun Jul 28 15:36:06 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -o watch watch.o -ltermcap gzip -cn /src/usr.sbin/watch/watch.8 > watch.8.gz ===> usr.sbin/watchdogd (all) cc -O -pipe -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -c /src/usr.sbin/watchdogd/watchdogd.c /src/usr.sbin/watchdogd/watchdogd.c:236:17: error: format specifies type 'long' but the argument has type 'time_t' (aka 'long long') [-Werror,-Wformat] myoptarg, ts.tv_sec, ts.tv_nsec, ticks); ^~~~~~~~~ 1 error generated. *** Error code 1 Stop. bmake: stopped in /src/usr.sbin/watchdogd *** Error code 1 Stop. bmake: stopped in /src/usr.sbin *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-28 18:37:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-28 18:37:08 - ERROR: failed to build world TB --- 2013-07-28 18:37:08 - 8653.92 user 1520.45 system 11209.13 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sun Jul 28 18:51:38 2013 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2890F33D; Sun, 28 Jul 2013 18:51:38 +0000 (UTC) (envelope-from kientzle@FreeBSD.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id F017025C6; Sun, 28 Jul 2013 18:51:37 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r6SIpaCm092596; Sun, 28 Jul 2013 18:51:36 GMT (envelope-from kientzle@FreeBSD.org) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id 2kjj5gytfzq3peu5vk4i569zp6; Sun, 28 Jul 2013 18:51:36 +0000 (UTC) (envelope-from kientzle@FreeBSD.org) Subject: Re: Adding options to RPI-B Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: <1374961185.45247.11.camel@revolution.hippie.lan> Date: Sun, 28 Jul 2013 11:51:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2C57A72F-0CB3-41DF-B0E5-1509348128BD@freebsd.org> <42C259D6-F652-417A-80B5-536893D6D642@felyko.com> <25D75461-E6FB-43C3-86AE-A513B02FA00D@freebsd.org> <877D7426-64E2-4451-AECC-073664A70AC1@freebsd.org> <1B3F0A21-D982-4D0C-965D-16739DB27003@freebsd.org> <5C14022C-FA7C-444B-83A7-745E8D94FB10@felyko.com> <007139FF-50B3-45A3-905A-3881BAF95F10@freebsd.org> <978DD006-370E-4823-ADCF-A8BB474A18FB@felyko.com> <1374961185.45247.11.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1283) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 18:51:38 -0000 On Jul 27, 2013, at 2:39 PM, Ian Lepore wrote: > On Sat, 2013-07-27 at 11:23 -0700, Tim Kientzle wrote: >>=20 >> On 27 Jul 2013, at 09:17, Tim Kientzle wrote: >>=20 >>> Here's a proposed patch that installs all of the standard Forth >>> files as part of ubldr on ARM. It does not install a loader.rc, >>> however, so it should have no effect per se, other than putting >>> a few more files on the image. >>=20 >> This is committed now. >>=20 >> I've also added the beastie support to loader.rc.sample >> (commented out). >>=20 >> For the record, the beastie menu works just fine on >> BeagleBone over a serial console. >>=20 >> I want to do some more testing before I start enabling >> loader.rc by default for Crochet-built RPi and BeagleBone >> images. Crochet now installs loader.rc for BeagleBone and RaspberryPi. So everything should work there now. > I couldn't find a way to use the fdt command from forth-ish > config files=85. That would be a nice thing to be able to do. Tim From owner-freebsd-arm@FreeBSD.ORG Sun Jul 28 19:00:17 2013 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 98382610 for ; Sun, 28 Jul 2013 19:00:17 +0000 (UTC) (envelope-from kientzle@FreeBSD.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 70CD92603 for ; Sun, 28 Jul 2013 19:00:16 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r6SJ0GAZ092681 for arm@freebsd.org; Sun, 28 Jul 2013 19:00:16 GMT (envelope-from kientzle@FreeBSD.org) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id rw2mye6v4gt7ivtyjv87mmtp7s; for arm@freebsd.org; Sun, 28 Jul 2013 19:00:16 +0000 (UTC) (envelope-from kientzle@FreeBSD.org) From: Tim Kientzle Content-Type: multipart/signed; boundary="Apple-Mail=_90C138D1-3CCC-4360-B151-F604E3C071AB"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: route(8) broken? Date: Sun, 28 Jul 2013 12:00:15 -0700 Message-Id: To: "freebsd-arm@freebsd.org" Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 19:00:17 -0000 --Apple-Mail=_90C138D1-3CCC-4360-B151-F604E3C071AB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 With r253514 on BeagleBone, I'm been consistently seeing the following on every boot: Waiting 30s for default route interface: =85=85=85=85=85=85=85 This seems to be because "route -n get default" is broken. For example, at the moment, I do in fact have a working default route and network, but: # route -n get default route to: 0.0.0.0 destination: 0.0.0.0 mask: 56.18.1.0 gateway: 192.168.2.1 fib: 0 flags: recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1500 1 0=20 In particular, note the garbage mask and the lack of an "interface" line. (The missing "interface" line seems to be the root cause of the "Waitiing=85" message above.) I've started to trace this back but haven't yet gotten very far... Tim --Apple-Mail=_90C138D1-3CCC-4360-B151-F604E3C071AB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) iQEcBAEBAgAGBQJR9WpAAAoJEGMNyGo0rfFBqdEH/3fRCH9BBnxOUnjCuQJvFDNc Z61zGGE66EjtNEoJy3jMBJPNQy0Amk6pebRxFF18KtBgnB/aCQvIKbDX3PhvEPNa Lsh4OzApIARzXFqFtiyGLlk15F9GMYAmJyO0dGOIOQVM0AECYLqAe1Q7qLf3AKYZ g268YTjhiTVk1BDGXbMsy2GNl9OREadPOxmvBRxOx0cYmdlgUM+dyTziVExNUYtO uShNtnWz8t/Eix1A+gG3AzdsTXWXNdC8KhrBC6OwL0nIMVbylTxs1qvZ9xHRXPHE RGt1fkbpltLiRJw6f2CHE/W0CNqhwpAoxRUDWgba5k02e/Mc3lZsQ19kFwrZ3OA= =OgkY -----END PGP SIGNATURE----- --Apple-Mail=_90C138D1-3CCC-4360-B151-F604E3C071AB-- From owner-freebsd-arm@FreeBSD.ORG Sun Jul 28 19:06:19 2013 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 250287C7; Sun, 28 Jul 2013 19:06:19 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EE1A3264C; Sun, 28 Jul 2013 19:06:18 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1V3WIG-000G9s-DA; Sun, 28 Jul 2013 19:06:12 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r6SJ6AdP016243; Sun, 28 Jul 2013 13:06:10 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19/Uj02pUhI+2w2IvYqy7JX Subject: Re: route(8) broken? From: Ian Lepore To: Tim Kientzle In-Reply-To: References: Content-Type: text/plain; charset="windows-1251" Date: Sun, 28 Jul 2013 13:06:09 -0600 Message-ID: <1375038369.45247.19.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id r6SJ6AdP016243 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 19:06:19 -0000 On Sun, 2013-07-28 at 12:00 -0700, Tim Kientzle wrote: > With r253514 on BeagleBone, I'm been consistently > seeing the following on every boot: >=20 > Waiting 30s for default route interface: =85=85=85=85=85=85=85 >=20 > This seems to be because "route -n get default" is broken. >=20 > For example, at the moment, I do in fact have a working default > route and network, but: >=20 > # route -n get default > route to: 0.0.0.0 > destination: 0.0.0.0 > mask: 56.18.1.0 > gateway: 192.168.2.1 > fib: 0 > flags: > recvpipe sendpipe ssthresh rtt,msec mtu weight expire > 0 0 0 0 1500 1 0=20 >=20 > In particular, note the garbage mask and the lack of an > "interface" line. (The missing "interface" line seems to > be the root cause of the "Waitiing=85" message above.) >=20 > I've started to trace this back but haven't yet gotten very far... >=20 > Tim >=20 Looks like the fix you need is in r253589. =20 I'm running r253716 on my RPi and everything is good except the jemalloc assert that sshd triggers (and I hear Jason is looking into that). -- Ian -- Ian From owner-freebsd-arm@FreeBSD.ORG Sun Jul 28 19:07:39 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E31AA7F0; Sun, 28 Jul 2013 19:07:39 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-ea0-x22d.google.com (mail-ea0-x22d.google.com [IPv6:2a00:1450:4013:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 50FE4265C; Sun, 28 Jul 2013 19:07:39 +0000 (UTC) Received: by mail-ea0-f173.google.com with SMTP id g10so2524551eak.32 for ; Sun, 28 Jul 2013 12:07:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=TiE1W4ancDkuLP1R2qka1QfP2Xf8yMlT7Za4d7JnJNY=; b=Q/Sv+QCBURh/K62ooCY8KHcuGw4hi57R/9bFIivOU3q01eq2484oq19A2Kk1FrT9XS jWviue5eVheifTMp3xddYfkK822/PeS5eZQggVDxWbCXoyjDOrTUvLUp49vfFx9pjFd4 HVVT1/W72sS1EMOXr1jhYsXhRJi/thRukAhTR+4sZgjD4En3uCDSVCvn8fH6O5CEbtP0 nxPpSnYx7yqaZrCU++2OfE/FjN3hKk9CB0RbM5516ViYPyIVy2V1C6tuBRlBeaPRBa0a AM1XQj5F71OZvFz0tFu49Gk8WdtOPFW1AbJl/F2HYwfmrW5Slt2SxZ1jZKk+nmAZihK8 xDeA== MIME-Version: 1.0 X-Received: by 10.15.42.129 with SMTP id u1mr56320462eev.116.1375038457720; Sun, 28 Jul 2013 12:07:37 -0700 (PDT) Received: by 10.14.105.137 with HTTP; Sun, 28 Jul 2013 12:07:37 -0700 (PDT) In-Reply-To: References: Date: Sun, 28 Jul 2013 12:07:37 -0700 Message-ID: Subject: Re: route(8) broken? From: hiren panchasara To: Tim Kientzle Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 19:07:40 -0000 On Sun, Jul 28, 2013 at 12:00 PM, Tim Kientzle wrote= : > With r253514 on BeagleBone, I'm been consistently > seeing the following on every boot: > > Waiting 30s for default route interface: =E2=80=A6=E2=80=A6=E2=80=A6= =E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6 > > This seems to be because "route -n get default" is broken. I think hrs@ fixed it in r253589 cheers, Hiren > > For example, at the moment, I do in fact have a working default > route and network, but: > > # route -n get default > route to: 0.0.0.0 > destination: 0.0.0.0 > mask: 56.18.1.0 > gateway: 192.168.2.1 > fib: 0 > flags: > recvpipe sendpipe ssthresh rtt,msec mtu weight expire > 0 0 0 0 1500 1 0 > > In particular, note the garbage mask and the lack of an > "interface" line. (The missing "interface" line seems to > be the root cause of the "Waitiing=E2=80=A6" message above.) > > I've started to trace this back but haven't yet gotten very far... > > Tim > From owner-freebsd-arm@FreeBSD.ORG Sun Jul 28 21:26:25 2013 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D5C20765; Sun, 28 Jul 2013 21:26:25 +0000 (UTC) (envelope-from kientzle@FreeBSD.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 968B82B3E; Sun, 28 Jul 2013 21:26:25 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r6SLQOPg093524; Sun, 28 Jul 2013 21:26:24 GMT (envelope-from kientzle@FreeBSD.org) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id v3tkwjix6zsqrxeappgfkhfn2w; Sun, 28 Jul 2013 21:26:24 +0000 (UTC) (envelope-from kientzle@FreeBSD.org) Subject: Re: route(8) broken? Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1251 From: Tim Kientzle In-Reply-To: <1375038369.45247.19.camel@revolution.hippie.lan> Date: Sun, 28 Jul 2013 14:26:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9F949656-7819-46AF-AC31-CBAE8EE0D39C@FreeBSD.org> References: <1375038369.45247.19.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1283) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 21:26:25 -0000 On Jul 28, 2013, at 12:06 PM, Ian Lepore wrote: > On Sun, 2013-07-28 at 12:00 -0700, Tim Kientzle wrote: >> With r253514 on BeagleBone, I'm been consistently >> seeing the following on every boot: >>=20 >> Waiting 30s for default route interface: =85=85=85=85=85=85=85 >>=20 >> This seems to be because "route -n get default" is broken. >>=20 >> For example, at the moment, I do in fact have a working default >> route and network, but: >>=20 >> # route -n get default >> route to: 0.0.0.0 >> destination: 0.0.0.0 >> mask: 56.18.1.0 >> gateway: 192.168.2.1 >> fib: 0 >> flags: >> recvpipe sendpipe ssthresh rtt,msec mtu weight expire >> 0 0 0 0 1500 1 0=20= >>=20 >> In particular, note the garbage mask and the lack of an >> "interface" line. (The missing "interface" line seems to >> be the root cause of the "Waitiing=85" message above.) >>=20 >> I've started to trace this back but haven't yet gotten very far... >>=20 >> Tim >>=20 >=20 > Looks like the fix you need is in r253589. =20 >=20 > I'm running r253716 on my RPi and everything is good =85 I'll try that. > =85 except the jemalloc > assert that sshd triggers (and I hear Jason is looking into that). Diane started looking into it and made some progress, Jason has given some clues (the assert in question is a debug tripwire that fires when malloc is about to return memory to a caller and notices that the memory is not zeroed, suggesting a write-after-free error or some other kind of stray pointer issue). Unrelated: have you had any luck using native gdb? I started to try to debug the route failure and gdb is acting a little strange. Everytime I hit 'n' it just runs to completion, occasionally with complaints about missing debug information. (Yes, the binary in question does have debug information and when I set a breakpoint it will stop and show the related source.) I suspect it might be related to gdb not recognizing the language: "Current language: auto; currently minimal" Tim From owner-freebsd-arm@FreeBSD.ORG Mon Jul 29 01:15:22 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B0A23ECC for ; Mon, 29 Jul 2013 01:15:22 +0000 (UTC) (envelope-from ghw@7axu.com) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3DDD92338 for ; Mon, 29 Jul 2013 01:15:21 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id k13so4341631wgh.25 for ; Sun, 28 Jul 2013 18:15:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=g73r4cJ+nVL10bsS5+YYK7j757sANU2060WK6R01xjQ=; b=iCRXXhWgrEhYmF/iq3SdyZPS0HKG/FHKCoUVWpJhoc4r+4pV85SrLcswqHmjfeiWzw L1dfgH+HrZ9Nyvg5qweYjCXs5OguFS+HAgbU4MjJ5jgmBuHTszMGOhqZN/XzdcreQNvG SNK8qQ25dLRzAXgwyj0c5fHooMfn67O1A6zLdakKttz8skfwh6toIKTLbNgNsLIxC+gV x7ObPMwKUbpce/WYPiVfpY5kBFmxd33BIDmMElj16IIhyEwS4KFJwtJsGUR6pLlK3/9e dNLThoHd9pi+ZPZAN58tgNEwHN74WtJNSkAwWrStlNMrEDgmgR48DCP7mukLMeU3tTml pm/Q== X-Received: by 10.180.90.240 with SMTP id bz16mr5458282wib.24.1375060514633; Sun, 28 Jul 2013 18:15:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.93.34 with HTTP; Sun, 28 Jul 2013 18:14:34 -0700 (PDT) X-Originating-IP: [54.249.112.206] In-Reply-To: References: <1374573600-2351360719.d37ada5f86@bliksem.vehosting.nl> <201307231220.52817.Daan@vitsch.nl> <51F4F3E9.9010605@bitfrost.no> From: XiaoQI Ge Date: Mon, 29 Jul 2013 09:14:34 +0800 Message-ID: Subject: Re: My WLI-UC-GNM up crash To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlsixqDQxxCriXqIZxigoK/WV/lbaWyF6lZvWODZjJujta/5BV08ngiF5VykmvrqcBMOVEm Cc: freebsd-arm , freebsd-wireless@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 01:15:22 -0000 Patch radiotap.diff ifconfig wlan0 normal execution through wifi wpa also be connected to the But often disconnected: Edit /etc/motd to change this login announcement. root@FreeBSD:~ # uptime 11:13PM up 33 secs, 1 user, load averages: 1.34, 0.37, 0.13 root@FreeBSD:~ # date Thu Jul 25 23:13:43 UTC 2013 root@FreeBSD:~ # ifconfig wlan create wlandev run0 wlan0: Ethernet address: 10:6f:3f:2b:fd:7d wlan0 ugen0.2: at usbus0 run0: <1.0> on usbus0 run0: MAC/BBP RT3070 (rev 0x0201), RF RT3020 (MIMO 1T1R), address 10:6f:3f:2b:fd:7d run0: firmware RT2870 ver. 0.236 loaded root@FreeBSD:~ # date Thu Jul 25 23:15:38 UTC 2013 root@FreeBSD:~ # uname -a FreeBSD FreeBSD.7axu.com 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r253662M: Mon Jul 29 16:39:29 CST 2013 root@FreeBSD.7axu.com:/usr/obj/arm.armv6/usr/src/sys/CUBIEBOARD1G arm root@FreeBSD:~ # ugen0.2: at usbus0 (disconnected) run0: at uhub1, port 1, addr 2 (disconnected) root@FreeBSD:~ # ugen0.2: at usbus0 run0: <1.0> on usbus0 run0: MAC/BBP RT3070 (rev 0x0201), RF RT3020 (MIMO 1T1R), address 10:6f:3f:2b:fd:7d ifconfig run0: firmware RT2870 ver. 0.236 loaded run0 down root@FreeBSD:~ # run0: firmware RT2870 ver. 0.236 loaded root@FreeBSD:~ # -- Regards. By: XiaoQI Ge; PGP:8B09D5F7 WWW: https://www.7axu.com/ 2013/7/29 Adrian Chadd : > As long as that results in the radiotap structures being 4 or 8 byte > padded when it's embedded in the softc - then yes, indeed. > > Xiao, can you try? > > > -adrian > > On 28 July 2013 03:35, Hans Petter Selasky wrote: >> Hi, >> >> Can you try the attached patch? >> >> --HPS From owner-freebsd-arm@FreeBSD.ORG Mon Jul 29 02:31:11 2013 Return-Path: Delivered-To: FreeBSD-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 02F905CC for ; Mon, 29 Jul 2013 02:31:11 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CBCCA2549 for ; Mon, 29 Jul 2013 02:31:10 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1V3dEr-00030R-9Y; Mon, 29 Jul 2013 02:31:09 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r6T2V644016479; Sun, 28 Jul 2013 20:31:06 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/le/2obLvJOVkr791mufRc Subject: Re: Wandboard support? From: Ian Lepore To: Bernd Walter In-Reply-To: <20130724201737.GF44332@cicely7.cicely.de> References: <20130724201737.GF44332@cicely7.cicely.de> Content-Type: text/plain; charset="us-ascii" Date: Sun, 28 Jul 2013 20:31:06 -0600 Message-ID: <1375065066.45247.26.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: FreeBSD-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 02:31:11 -0000 On Wed, 2013-07-24 at 22:17 +0200, Bernd Walter wrote: > I just received a dual core Wandboard (www.wandboard.org) in the > believe it is supported. > There is also a reference about rw_lock panic in april, which sounded > like someone got it running in the end. > But I can't find anything else, also no kernelconfig. > Damjan Marion and I both started working on wandboard bringup a few months ago (independently) and then we both set it aside after having a little success. Now there's interest in it at work again so I resumed my efforts this weekend. Right now I've got it booting to the point of mountroot, but I don't have any working drivers that can be a root device, so that's a pretty small success. (I've got the single-core board right now, I think we'll be using dual core at work.) Hopefully I can get usb working in the next couple days (the controller is almost the same as the imx51 we already support). It looks like we'll need an ethernet driver written from scratch, likewise mmc/sd. -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Jul 29 03:52:19 2013 Return-Path: Delivered-To: FreeBSD-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6E01E421 for ; Mon, 29 Jul 2013 03:52:19 +0000 (UTC) (envelope-from beattidp@gmail.com) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 33E562923 for ; Mon, 29 Jul 2013 03:52:15 +0000 (UTC) Received: by mail-oa0-f49.google.com with SMTP id n16so497441oag.8 for ; Sun, 28 Jul 2013 20:52:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:reply-to :message-id:references:to:x-mailer; bh=HdUqKeIKfj3kgLrk2cVSVPG/P8HdgZYr9+i00Wb5+/Q=; b=kLdPFRbuzoiVHMctIo09eFHAT4/nMYLr/gJEvIcRboIb/CkQXL9F3sEQqScwbqibAE z/EwI0yU4NUAyzIteKUwrHWbtzY+v8JweB08S86GydlXnnp+uDKFh3ved/r/oFerM0bb /pHmWU1/HQJnC6+lyun5Dnad/vjkabBWCtNxUipmC0hj7+AQ5+3rZo5ht4punuL1jzCN s5OgAx8PtFFieqjO/hcvkh2/Y5A1IQmbj5mpSGce3JUFN4hxNBygRNpeuZibq3TS0h8S CkrxAxAvXIV3RXkNDPAWz2BI78gDwfUQXpbqtxYwBtV5/OJrtq4BjPeVZ/UpuWLRfR/S Pgjw== X-Received: by 10.60.47.76 with SMTP id b12mr1664926oen.78.1375069935020; Sun, 28 Jul 2013 20:52:15 -0700 (PDT) Received: from [192.168.0.114] (75-169-4-120.slkc.qwest.net. [75.169.4.120]) by mx.google.com with ESMTPSA id cp7sm36019418obb.0.2013.07.28.20.52.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 28 Jul 2013 20:52:14 -0700 (PDT) Subject: i.MX53 (Re: Wandboard support?) Mime-Version: 1.0 (Apple Message framework v1283) From: Douglas Beattie In-Reply-To: <1375065066.45247.26.camel@revolution.hippie.lan> Date: Sun, 28 Jul 2013 21:52:10 -0600 Message-Id: References: <20130724201737.GF44332@cicely7.cicely.de> <1375065066.45247.26.camel@revolution.hippie.lan> To: FreeBSD-arm@FreeBSD.org X-Mailer: Apple Mail (2.1283) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Douglas Beattie List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 03:52:19 -0000 Speaking of i.MX targets... I have 2 different flavors of i.MX53-based development systems; the i.MX53 Low-cost ("LoCo") board, and actually two complete ConnectCore for i.MX53 JumpStart Kit for Android from Digi (which are fairly high-end kits, retailing for about $500). In fact, I have been waiting for any word on renewed interest or momentum for the i.MX5/6 series. If someone is seriously interested in attempting a port, I would consider sending them one of my i.MX53 ConnectCore kits, which is still unopened, in support of their efforts. This kit is a good platform for porting, since it has just about every = possible peripheral available, including LCD, HDMI, WLAN, and even an SATA drive interface. A few months ago, I dived in deep, looking at some of the NetBSD port code as well, but an ARM port of FreeBSD is still a little over my head. While I have done tons of embedded development over the past 15 years, this looks tough to do alone, or without prior FreeBSD/ARM driver = experience. Information on the boards I have are found at these links; = http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=3DIMX53QSB http://www.digi.com/products/model?mid=3D4124 The i.MX5/6 are some nice ARM controllers -- I see some decent kits and modules in several places; http://devicesolutions.net/Products/OpaliMX53DevelopmentKit.aspx = http://boundarydevices.com/products/nitrogen53-board-imx53-arm-cortex-a8-s= bc/ http://www.embedinfo.com/english/product/sabrelite.asp = http://www.variscite.com/products/system-on-module-som/cortex-a9/var-som-m= x6-cpu-freescale-imx6 Anyway, one interesting thing I noticed about the i.MX53 (and I suppose = other family members of i.MX series) was the boot loader, which is basically a = ROM- based BIOS boot loader, already built in, which can boot from several = different peripheral sources, and which can take certain peripheral configuration = instructions from a properly-structured table in the load record. Maybe it's not too far over my head, if there were some collaboration, = assuming hardware available (which it is). -- Douglas Beattie http://www.linkedin.com/in/beattidp On Jul 28, 2013, at 8:31 PM, Ian Lepore wrote: > On Wed, 2013-07-24 at 22:17 +0200, Bernd Walter wrote: >> I just received a dual core Wandboard (www.wandboard.org) in the >> believe it is supported. >> There is also a reference about rw_lock panic in april, which sounded >> like someone got it running in the end. >> But I can't find anything else, also no kernelconfig. >>=20 >=20 > Damjan Marion and I both started working on wandboard bringup a few > months ago (independently) and then we both set it aside after having = a > little success. Now there's interest in it at work again so I resumed > my efforts this weekend. Right now I've got it booting to the point = of > mountroot, but I don't have any working drivers that can be a root > device, so that's a pretty small success. (I've got the single-core > board right now, I think we'll be using dual core at work.) >=20 > Hopefully I can get usb working in the next couple days (the = controller > is almost the same as the imx51 we already support). It looks like > we'll need an ethernet driver written from scratch, likewise mmc/sd. >=20 > -- Ian >=20 > _______________________________________________ > 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 From owner-freebsd-arm@FreeBSD.ORG Mon Jul 29 11:06:41 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DD2F5184 for ; Mon, 29 Jul 2013 11:06:41 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B21282DC7 for ; Mon, 29 Jul 2013 11:06:41 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r6TB6fai061701 for ; Mon, 29 Jul 2013 11:06:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r6TB6fuT061699 for freebsd-arm@FreeBSD.org; Mon, 29 Jul 2013 11:06:41 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 29 Jul 2013 11:06:41 GMT Message-Id: <201307291106.r6TB6fuT061699@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arm@FreeBSD.org Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 11:06:41 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o arm/180080 arm Unmapped buffers on ARMv7 big-RAM boards o arm/179688 arm [patch] [rpi] serial console eats some characters at m o arm/179561 arm Compilation issue for lighttpd on raspberry pi o arm/179532 arm wireless networking on ARM o arm/178495 arm buildworld fail on arm/raspberry pi o arm/177687 arm gdb gets installed but does not know the EABI version o arm/177686 arm assertion failed in ld-elf.so.1 when invoking telnet w o arm/177685 arm [kernel] [patch] Correct return type and usage of at91 o arm/177538 arm tunefs(8) and mount(8) can not access a newfs(8)'d fil o arm/176424 arm Compiler warning, TARGET_ARCH=armv6, make MALLOC_PRODU o arm/175803 arm building xdev for arm failing o arm/175605 arm please fix build binutils-2.23.1 in raspberry pi o arm/174461 arm [patch] Fix off-by-one in arm9/arm10 cache maintenance o arm/173617 arm Dreamplug exhibits eSATA file corruption using network o kern/171096 arm [arm][xscale][ixp]Allow 16bit access on PCI bus o arm/166256 arm build fail in pmap.c o arm/162159 arm [panic] USB errors leading to panic on DockStar 9.0-RC o arm/161110 arm /usr/src/sys/arm/include/signal.h is bad o arm/161044 arm devel/icu does not build on arm o arm/158950 arm arm/sheevaplug fails fsx when mmap operations are enab o arm/155894 arm [patch] Enable at91 booting from SDHC (high capacity) p arm/155214 arm [patch] MMC/SD IO slow on Atmel ARM with modern large o arm/154227 arm [geli] using GELI leads to panic on ARM o arm/153380 arm Panic / translation fault with wlan on ARM o arm/150581 arm [irq] Unknown error generates IRQ address decoding err o arm/134368 arm [new driver] [patch] nslu2_led driver for the LEDs on p arm/134338 arm [patch] Lock GPIO accesses on ixp425 27 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Jul 29 11:10:14 2013 Return-Path: Delivered-To: FreeBSD-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id EDBB5AC5 for ; Mon, 29 Jul 2013 11:10:13 +0000 (UTC) (envelope-from ray@ddteam.net) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 632912F5B for ; Mon, 29 Jul 2013 11:10:13 +0000 (UTC) Received: from terran (unknown [192.168.99.1]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id 748B6C492D; Mon, 29 Jul 2013 14:04:28 +0300 (EEST) Date: Mon, 29 Jul 2013 14:04:46 +0300 From: Aleksandr Rybalko To: Douglas Beattie Subject: Re: i.MX53 (Re: Wandboard support?) Message-Id: <20130729140446.47a76c23a95b9480dd87410c@ddteam.net> In-Reply-To: References: <20130724201737.GF44332@cicely7.cicely.de> <1375065066.45247.26.camel@revolution.hippie.lan> X-Mailer: Sylpheed 3.2.0 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD-arm@FreeBSD.org, Douglas Beattie X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 11:10:14 -0000 On Sun, 28 Jul 2013 21:52:10 -0600 Douglas Beattie wrote: > Speaking of i.MX targets... > > I have 2 different flavors of i.MX53-based development systems; > the i.MX53 Low-cost ("LoCo") board, and actually two complete > ConnectCore for i.MX53 JumpStart Kit for Android from Digi (which > are fairly high-end kits, retailing for about $500). > > In fact, I have been waiting for any word on renewed interest or > momentum for the i.MX5/6 series. If someone is seriously interested > in attempting a port, I would consider sending them one of my i.MX53 > ConnectCore kits, which is still unopened, in support of their efforts. > This kit is a good platform for porting, since it has just about every possible > peripheral available, including LCD, HDMI, WLAN, and even an SATA > drive interface. > > A few months ago, I dived in deep, looking at some of the NetBSD port > code as well, but an ARM port of FreeBSD is still a little over my head. > While I have done tons of embedded development over the past 15 years, > this looks tough to do alone, or without prior FreeBSD/ARM driver experience. > > Information on the boards I have are found at these links; > http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=IMX53QSB > http://www.digi.com/products/model?mid=4124 > > The i.MX5/6 are some nice ARM controllers -- I see some decent kits and > modules in several places; > http://devicesolutions.net/Products/OpaliMX53DevelopmentKit.aspx > http://boundarydevices.com/products/nitrogen53-board-imx53-arm-cortex-a8-sbc/ > http://www.embedinfo.com/english/product/sabrelite.asp > http://www.variscite.com/products/system-on-module-som/cortex-a9/var-som-mx6-cpu-freescale-imx6 > > Anyway, one interesting thing I noticed about the i.MX53 (and I suppose other > family members of i.MX series) was the boot loader, which is basically a ROM- > based BIOS boot loader, already built in, which can boot from several different > peripheral sources, and which can take certain peripheral configuration instructions > from a properly-structured table in the load record. > > Maybe it's not too far over my head, if there were some collaboration, assuming > hardware available (which it is). > > -- > Douglas Beattie > http://www.linkedin.com/in/beattidp > > > > On Jul 28, 2013, at 8:31 PM, Ian Lepore wrote: > > > On Wed, 2013-07-24 at 22:17 +0200, Bernd Walter wrote: > >> I just received a dual core Wandboard (www.wandboard.org) in the > >> believe it is supported. > >> There is also a reference about rw_lock panic in april, which sounded > >> like someone got it running in the end. > >> But I can't find anything else, also no kernelconfig. > >> > > > > Damjan Marion and I both started working on wandboard bringup a few > > months ago (independently) and then we both set it aside after having a > > little success. Now there's interest in it at work again so I resumed > > my efforts this weekend. Right now I've got it booting to the point of > > mountroot, but I don't have any working drivers that can be a root > > device, so that's a pretty small success. (I've got the single-core > > board right now, I think we'll be using dual core at work.) > > > > Hopefully I can get usb working in the next couple days (the controller > > is almost the same as the imx51 we already support). It looks like > > we'll need an ethernet driver written from scratch, likewise mmc/sd. > > > > -- 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" > > > > _______________________________________________ > 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" Hello Douglas, as I know, most of FreeBSD ARM guys too busy to help now. But since you have some knowledge in that area, I want to suggest you to join us on #bsdmips irc channel (EFnet irc network), and we would help you to do it yourself. At least I am ready to help. Thanks! WBW -- Aleksandr Rybalko From owner-freebsd-arm@FreeBSD.ORG Mon Jul 29 14:08:34 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2FDB019E; Mon, 29 Jul 2013 14:08:34 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 007DD2898; Mon, 29 Jul 2013 14:08:33 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6TE8XDu068822; Mon, 29 Jul 2013 10:08:33 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6TE8XUo068814; Mon, 29 Jul 2013 14:08:33 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 29 Jul 2013 14:08:33 GMT Message-Id: <201307291408.r6TE8XUo068814@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 14:08:34 -0000 TB --- 2013-07-29 11:00:17 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-29 11:00:17 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-29 11:00:17 - starting HEAD tinderbox run for arm/arm TB --- 2013-07-29 11:00:17 - cleaning the object tree TB --- 2013-07-29 11:00:17 - /usr/local/bin/svn stat /src TB --- 2013-07-29 11:00:21 - At svn revision 253765 TB --- 2013-07-29 11:00:22 - building world TB --- 2013-07-29 11:00:22 - CROSS_BUILD_TESTING=YES TB --- 2013-07-29 11:00:22 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-29 11:00:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-29 11:00:22 - SRCCONF=/dev/null TB --- 2013-07-29 11:00:22 - TARGET=arm TB --- 2013-07-29 11:00:22 - TARGET_ARCH=arm TB --- 2013-07-29 11:00:22 - TZ=UTC TB --- 2013-07-29 11:00:22 - __MAKE_CONF=/dev/null TB --- 2013-07-29 11:00:22 - cd /src TB --- 2013-07-29 11:00:22 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Jul 29 11:00:30 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Jul 29 14:01:48 UTC 2013 TB --- 2013-07-29 14:01:48 - generating LINT kernel config TB --- 2013-07-29 14:01:48 - cd /src/sys/arm/conf TB --- 2013-07-29 14:01:48 - /usr/bin/make -B LINT TB --- 2013-07-29 14:01:48 - cd /src/sys/arm/conf TB --- 2013-07-29 14:01:48 - /usr/sbin/config -m LINT TB --- 2013-07-29 14:01:48 - building LINT kernel TB --- 2013-07-29 14:01:48 - CROSS_BUILD_TESTING=YES TB --- 2013-07-29 14:01:48 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-29 14:01:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-29 14:01:48 - SRCCONF=/dev/null TB --- 2013-07-29 14:01:48 - TARGET=arm TB --- 2013-07-29 14:01:48 - TARGET_ARCH=arm TB --- 2013-07-29 14:01:48 - TZ=UTC TB --- 2013-07-29 14:01:48 - __MAKE_CONF=/dev/null TB --- 2013-07-29 14:01:48 - cd /src TB --- 2013-07-29 14:01:48 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 29 14:01:48 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] In file included from /src/sys/dev/e1000/if_igb.c:64: ./machine/smp.h:36:41: error: array has incomplete element type 'struct pcb' extern struct pcb stoppcbs[]; ^ ./machine/pcpu.h:60:8: note: forward declaration of 'struct pcb' struct pcb; ^ 1 error generated. *** Error code 1 Stop. bmake: stopped in /obj/arm.arm/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-29 14:08:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-29 14:08:33 - ERROR: failed to build LINT kernel TB --- 2013-07-29 14:08:33 - 8916.39 user 1608.92 system 11295.31 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Mon Jul 29 15:00:08 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9073BBD1 for ; Mon, 29 Jul 2013 15:00:08 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5B75B2C51 for ; Mon, 29 Jul 2013 15:00:08 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id kx1so5700537pab.27 for ; Mon, 29 Jul 2013 08:00:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=/2GrrONhHpRxqzZJzTZ3b8Zgtqq5e6SITrAppwxThDo=; b=Q13dJgcpOliv7KT7yFIb4iQ70HuZN8SN6e9Uv1iHsCvBdJdYt1zViQVAzxcKFESKUj pe7W8fjzFCNod1/LNH410mo51mp/qBQWQToCsxssUtGic3c1wM9Q+MHw6aVRlJrcGFhR q92aBy6qbMpjZRRhNnn5dWZKKwanEl3c4vZmfeB9NPkEdqbz5tWwn/PCzXpqvj4HIU+u 8faZPWcVi5j3PQej7WSYwbk3bxCkta6rFXI+1YaqPe3LUE2Q4glDey+eLTm4dR4CPLET BFhM8q3s4+u24DXadgA3SbU6b4x3SoqiYhZPS5petNDWiES/wJAdVt7qlENiC8tHkY8+ osOg== X-Received: by 10.68.232.225 with SMTP id tr1mr67434098pbc.143.1375110001910; Mon, 29 Jul 2013 08:00:01 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id qf7sm335819pac.14.2013.07.29.07.59.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 08:00:00 -0700 (PDT) Sender: Warner Losh Subject: Re: My WLI-UC-GNM up crash Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <51F4F3E9.9010605@bitfrost.no> Date: Mon, 29 Jul 2013 08:59:58 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1374573600-2351360719.d37ada5f86@bliksem.vehosting.nl> <201307231220.52817.Daan@vitsch.nl> <51F4F3E9.9010605@bitfrost.no> To: Hans Petter Selasky X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQltf84xOhq5QaPoYX9ssX4aXLNRdK4I7mvRGRTJLo6KJSNJyaiaKd6sThIUyShHcy1yCbbw Cc: freebsd-wireless@freebsd.org, freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 15:00:08 -0000 The __aligned(8) likely isn't going to do anything. It says that you are = guaranteeing to the compiler that you'll only ever allocate / cast = pointers to this data type on a 8-byte boundary. __packed might help, = but likely won't because that's for on-wire things and anything thing = that wasn't already not marked packed that should be would already be = broken, but broken giving bad data, not broken segfaulting. __aligned(1) is what you want. But that has other performance = problems... Warner On Jul 28, 2013, at 4:35 AM, Hans Petter Selasky wrote: > Hi, >=20 > Can you try the attached patch? >=20 > --HPS > _______________________________________________ > 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" From owner-freebsd-arm@FreeBSD.ORG Mon Jul 29 15:03:59 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 95B8FC77 for ; Mon, 29 Jul 2013 15:03:59 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 64F9A2C81 for ; Mon, 29 Jul 2013 15:03:59 +0000 (UTC) Received: by mail-pb0-f46.google.com with SMTP id rq2so1038481pbb.33 for ; Mon, 29 Jul 2013 08:03:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=xVhn9v4RdYHjQypyzbGU/JLoRZ4aa2B2fCcf9I8I7VY=; b=BX3jhEStudQxRppuXWFlqLAuHWRGP8XvRRrc2OkdyGADt3tECXORHkkRbWNBFjiqGU AZJT2nrot3RXNJJhg4sYdfqt6ENOGKsfGjZfUQ7dxa85Ty75VXdBLIkpUxNza2HJ2dRm mMVuBZ9G2Mgu1WiFB7OSnyj4twBb8oBnpKJj6LG/zbQFdjhWUOgUmBFgWNk0yXhZDrWK 75pUh+nL7jbmI25iBsrHCfMrPL9Kp0zBh7Z2BVygPxPrtWeq1A1WTN3ad4FuiwoIYISr SIYTDoP1eXKv9rxEeJQPKZvara2UyA2iCkQ/JXHki7F8aeNms3F5iYulB/Gtin/GrlHc v3lw== X-Received: by 10.66.162.195 with SMTP id yc3mr23076862pab.64.1375110231467; Mon, 29 Jul 2013 08:03:51 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id py4sm77477752pbc.14.2013.07.29.08.03.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 08:03:50 -0700 (PDT) Sender: Warner Losh Subject: Re: My WLI-UC-GNM up crash Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Mon, 29 Jul 2013 09:03:48 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <8AFE4FCA-BCAA-460C-ABFE-EC7FC2991B8C@bsdimp.com> References: <1374573600-2351360719.d37ada5f86@bliksem.vehosting.nl> <201307231220.52817.Daan@vitsch.nl> <51F4F3E9.9010605@bitfrost.no> To: Adrian Chadd X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlELi9lK7yWvryyVgzd+vPDDBe5ZDxpNbnsfMeU015hXXNuhKSCo8JMBYoUZLqVhDnCZi6X Cc: freebsd-arm , freebsd-wireless@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 15:03:59 -0000 Aren't structures already aligned to 4 bytes when placed inside other = structures (unless marked __packed)? Warner On Jul 28, 2013, at 11:50 AM, Adrian Chadd wrote: > As long as that results in the radiotap structures being 4 or 8 byte > padded when it's embedded in the softc - then yes, indeed. >=20 > Xiao, can you try? >=20 >=20 > -adrian >=20 > On 28 July 2013 03:35, Hans Petter Selasky wrote: >> Hi, >>=20 >> Can you try the attached patch? >>=20 >> --HPS > _______________________________________________ > 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" From owner-freebsd-arm@FreeBSD.ORG Mon Jul 29 15:07:49 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3CA5FEBB for ; Mon, 29 Jul 2013 15:07:49 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0167E2CA5 for ; Mon, 29 Jul 2013 15:07:48 +0000 (UTC) Received: by mail-ob0-f171.google.com with SMTP id tb18so9609806obb.16 for ; Mon, 29 Jul 2013 08:07:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=X3LLg1wDb/bCDcQBHIrhwn/nC1Yces0gGNc5b5IUjyA=; b=Lmvryjc6QpNebdMvf48XxsN2k14rwPJdk/hwr+gMbYKv2GBpqqZtnk9XunPCPtZaRi mLOi3qdQm6zerC8Tdz+tgRzwh1YgTrEBAsXVzDWQNtDW/YBuE/YQyMabdeX6CZip3aKW HhayItu/tRckztt4Syp7JdswrG0WvvONZ1aIg98x6y8i/Ji22K5frqhsJQRe4BwC8oBR gtRdy6hMrMs8JJO1HR47zX/wzRGW983MlAU0HaOU/d34d/IPkFWQEHD+y1WwCRtzaaki 6kxdbmB7iPwsjUImMqKufryZsGPdtZcjcfyhtP2lxdET7Vh84Yl6+lEdRvoWJ3+riZSz ZNug== X-Received: by 10.182.72.170 with SMTP id e10mr53026320obv.62.1375110468097; Mon, 29 Jul 2013 08:07:48 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id tv3sm87889530obb.8.2013.07.29.08.07.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 08:07:47 -0700 (PDT) Sender: Warner Losh Subject: Re: route(8) broken? Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <9F949656-7819-46AF-AC31-CBAE8EE0D39C@FreeBSD.org> Date: Mon, 29 Jul 2013 09:07:45 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <75A1D99D-2E0F-435C-AAF4-A881AC68B04C@bsdimp.com> References: <1375038369.45247.19.camel@revolution.hippie.lan> <9F949656-7819-46AF-AC31-CBAE8EE0D39C@FreeBSD.org> To: Tim Kientzle X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnFXDVXqyS95isxN9egcmb5KQXUbmSH6pd5xXKsIFeGwYZ1AICaVJuwN49Z1WnsrSbj3boC Cc: "freebsd-arm@freebsd.org" , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 15:07:49 -0000 On Jul 28, 2013, at 3:26 PM, Tim Kientzle wrote: > Unrelated: have you had any luck using native gdb? >=20 > I started to try to debug the route failure and gdb > is acting a little strange. Everytime I hit 'n' it just > runs to completion, occasionally with complaints about > missing debug information. (Yes, the binary in > question does have debug information and when > I set a breakpoint it will stop and show the related > source.) >=20 > I suspect it might be related to gdb not recognizing > the language: >=20 > "Current language: auto; currently minimal" -O2 fallout? I've had to remove -O anything at times when debugging on = arm because our tools don't generate good debugging info when things are = highly optimized. Warner From owner-freebsd-arm@FreeBSD.ORG Mon Jul 29 15:51:00 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1BF916BD for ; Mon, 29 Jul 2013 15:51:00 +0000 (UTC) (envelope-from zbb@semihalf.com) Received: from mail-ee0-f46.google.com (mail-ee0-f46.google.com [74.125.83.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 88A122E65 for ; Mon, 29 Jul 2013 15:50:59 +0000 (UTC) Received: by mail-ee0-f46.google.com with SMTP id c13so432995eek.19 for ; Mon, 29 Jul 2013 08:50:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type:x-gm-message-state; bh=NanEunskL1o3YlJ/pgYJUcPU/nPtIlkru0I6sLibdFs=; b=AP+1Xp4sI1OYXrmfEJmFRnrF3MzrYlW2JHFJprKNCkkgKqFsvY2+/kdnEOBlEUyx3u gdYYseCisqU3nK6mTLlb0t5zI+B+aQoHlpOyouuhPHMdFLqNOje/NmJe0cDEsu7CmRVu gUQKaLdPmn3F4BmKRl6RXwoXZn4ZOd0yxbtW/pXCrFGUQYdEV1rdBaKHKwoCA36NiwaP A47S64THJu+Tnfy4tmSQlPy0wfCNnAWfhxXrgjKRMkMPBVAkLEfFywWZxO5qMvYUeFM3 Bn31jT/4cMSjT+BSpFqbRYZWQaSD95V6msFOG7SkkF2azyF48eEbsBjgJO0k9Gx3tDz8 bl3g== X-Received: by 10.15.98.3 with SMTP id bi3mr59231376eeb.124.1375113052366; Mon, 29 Jul 2013 08:50:52 -0700 (PDT) Received: from [10.0.2.117] (cardhu.semihalf.com. [213.17.239.108]) by mx.google.com with ESMTPSA id a4sm103073174eez.0.2013.07.29.08.50.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 08:50:51 -0700 (PDT) Message-ID: <51F68F58.8060600@semihalf.com> Date: Mon, 29 Jul 2013 17:50:48 +0200 From: Zbyszek Bodek Organization: Semihalf User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: "freebsd-arm@freebsd.org" Subject: Re: New pmap-v6.c features and improvements References: <519B6B1C.9060008@semihalf.com> <20130522184232.GA437@jail.io> <519E0D62.5030708@semihalf.com> <51CC4CC1.4020509@semihalf.com> <51D57456.9080504@semihalf.com> In-Reply-To: Content-Type: multipart/mixed; boundary="------------040509090706030205070508" X-Gm-Message-State: ALoCoQkebL+KmXfvI1ZMJ+zKDF59hqxcUmyI4/L3pvdZpgRfaIuG0lCiSekW7O/ZeqCBhCwx3XuR Cc: ray@freebsd.org, Alan Cox X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 15:51:00 -0000 This is a multi-part message in MIME format. --------------040509090706030205070508 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 04.07.2013 19:34, Warner Losh wrote: > > On Jul 4, 2013, at 7:10 AM, Zbyszek Bodek wrote: > >> On 27.06.2013 16:31, Zbyszek Bodek wrote: >>> On 23.05.2013 14:36, Zbyszek Bodek wrote: >>>> On 22.05.2013 20:42, Ruslan Bukin wrote: >>>>> On Tue, May 21, 2013 at 02:39:56PM +0200, Zbyszek Bodek wrote: >>>>>> Hello Everyone, >>>>>> >>>>>> I would like to introduce another pack of patches for pmap-v6.c and >>>>>> related, that we created as a part of Semihalf work on Superpages >>>>>> support. >>>>>> >>>>>> The patches include some major changes like: >>>>>> >>>>>> - Switch to AP[1:0] access permissions model >>>>>> - Transition of the mapping related flags to PTE (stop using PVF_ flags >>>>>> in pv_entry) >>>>>> - Rework of the pmap_enter_locked() function >>>>>> - pmap code optimizations >>>>>> >>>>>> And some minor clean-ups: >>>>>> >>>>>> - Get rid of the VERBOSE_INIT_ARM option >>>>>> - Clean-ups, style and naming improvements to pmap >>>>>> >>>>>> Please check out the attachment for details. >>>>>> >>>>>> I will be happy to answer your questions and doubts if any. >>>>>> >>>>>> Best regards >>>>>> Zbyszek Bodek >>>>> >>>>> I tested new patches with exynos5 and everything is OK. >>>>> (I mean all works as usual) >>>>> >>>> >>>> Hello. >>>> >>>> I'm happy to announce that code has been integrated to the FreeBSD HEAD. >>>> Great thanks your help! >>>> >>> >>> Hello Everyone, >>> >>> We have two micro patches for pmap-v6.c containing fix for 'modified' >>> bit emulation and removal of the redundant PGA_WRITEABLE clearing. >>> >>> Please check out the attachment. >>> >>> These two are minimal changes and we would like to commit them soon, so >>> we would be grateful if you could test them on your ARMv6/v7 platforms >>> and give us your remarks. >>> >> >> Hello, >> >> Because there were no objections, we've integrated the patches: >> >> http://svnweb.freebsd.org/base?view=revision&revision=252694 >> http://svnweb.freebsd.org/base?view=revision&revision=252695 > Hello Everyone, I'm sending another set of fixes for pmap-v6.c Please see attachment. 0012 - Removal of the costly, frequent sweeping through the pv_entries whenever pmap_nuke_pv(), pmap_modify_pv(), etc. are called. This also makes order with clearing PGA_WRITEABLE aflag as well as with the pmap_statistics related to the wired_count. 0013 - Fix for pamp_set_prot() where not all of the protection bits were cleared before the actual configuration. L2_XN is not icluded to the L2_S_PROT mask to maintain consistency between PROT_MASKS for L2 and L1 descriptors - contain only kernel/user and read/write permissions bits. 0014 - Fix for pmap_change_wiring() where "wired" indicator of type boolean was being used as a "wired flag" passed to pmap_modify_pv() which was obviously not a valid PVF_WIRED flag. Please test those patches on your ARM-based machines and send your feedback. We will also appreciate your reviews and remarks. Thank you in advance for your help. Best regards Zbyszek Bodek --------------040509090706030205070508 Content-Type: text/x-patch; name="0012-Clarify-pv_entry-removal-in-respect-to-pmap-statisti.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="0012-Clarify-pv_entry-removal-in-respect-to-pmap-statisti.pa"; filename*1="tch" >From 39cd0d193105e3417f7251c6faa127042808af2f Mon Sep 17 00:00:00 2001 From: Zbigniew Bodek Date: Wed, 24 Jul 2013 20:19:38 +0200 Subject: [PATCH 1/3] Clarify pv_entry removal in respect to pmap statistics and PGA_ flags for ARMv6/v7 platforms - PGA_WRITEABLE indicates that there *might be* a writable mapping for the particular page so to avoid frequent sweeping of the pv_entries whenever pmap_nuke_pv(), pmap_modify_pv(), etc. is called it is sufficient to clear that flag if there are no managed mappings for that page anymore (notice that only pmap_enter is authorized to set this flag). - Avoid redundant checking for PVF_WIRED flag when this flag cannot be set anyway. - Clear PGA_WRITEABLE only once for each vm_page instead of multiple, redundant clearing it in loop when there are no writeable mappings to that page anymore. Submitted by: Zbigniew Bodek Sponsored by: The FreeBSD Foundation, Semihalf --- sys/arm/arm/pmap-v6.c | 54 +++++++++++++++++---------------------------------- 1 file changed, 18 insertions(+), 36 deletions(-) diff --git a/sys/arm/arm/pmap-v6.c b/sys/arm/arm/pmap-v6.c index 73b899c..15eb5e1 100644 --- a/sys/arm/arm/pmap-v6.c +++ b/sys/arm/arm/pmap-v6.c @@ -1072,39 +1072,22 @@ pmap_set_prot(pt_entry_t *ptep, vm_prot_t prot, uint8_t user) * => caller should NOT adjust pmap's wire_count * => we return the removed pve */ - -static void -pmap_nuke_pv(struct vm_page *m, pmap_t pmap, struct pv_entry *pve) -{ - - rw_assert(&pvh_global_lock, RA_WLOCKED); - PMAP_ASSERT_LOCKED(pmap); - - TAILQ_REMOVE(&m->md.pv_list, pve, pv_list); - - if (pve->pv_flags & PVF_WIRED) - --pmap->pm_stats.wired_count; - - if (pve->pv_flags & PVF_WRITE) { - TAILQ_FOREACH(pve, &m->md.pv_list, pv_list) - if (pve->pv_flags & PVF_WRITE) - break; - if (!pve) { - vm_page_aflag_clear(m, PGA_WRITEABLE); - } - } -} - static struct pv_entry * pmap_remove_pv(struct vm_page *m, pmap_t pmap, vm_offset_t va) { struct pv_entry *pve; rw_assert(&pvh_global_lock, RA_WLOCKED); + PMAP_ASSERT_LOCKED(pmap); pve = pmap_find_pv(m, pmap, va); /* find corresponding pve */ - if (pve != NULL) - pmap_nuke_pv(m, pmap, pve); + if (pve != NULL) { + TAILQ_REMOVE(&m->md.pv_list, pve, pv_list); + if (pve->pv_flags & PVF_WIRED) + --pmap->pm_stats.wired_count; + } + if (TAILQ_EMPTY(&m->md.pv_list)) + vm_page_aflag_clear(m, PGA_WRITEABLE); return(pve); /* return removed pve */ } @@ -1143,14 +1126,6 @@ pmap_modify_pv(struct vm_page *m, pmap_t pmap, vm_offset_t va, else --pmap->pm_stats.wired_count; } - if ((oflags & PVF_WRITE) && !(flags & PVF_WRITE)) { - TAILQ_FOREACH(npv, &m->md.pv_list, pv_list) { - if (npv->pv_flags & PVF_WRITE) - break; - } - if (!npv) - vm_page_aflag_clear(m, PGA_WRITEABLE); - } return (oflags); } @@ -2063,7 +2038,9 @@ pmap_remove_pages(pmap_t pmap) pv_entry_count--; pmap->pm_stats.resident_count--; pc->pc_map[field] |= bitmask; - pmap_nuke_pv(m, pmap, pv); + TAILQ_REMOVE(&m->md.pv_list, pv, pv_list); + if (TAILQ_EMPTY(&m->md.pv_list)) + vm_page_aflag_clear(m, PGA_WRITEABLE); pmap_free_l2_bucket(pmap, l2b, 1); } } @@ -2459,7 +2436,9 @@ pmap_remove_all(vm_page_t m) PTE_SYNC(ptep); pmap_free_l2_bucket(pmap, l2b, 1); pmap->pm_stats.resident_count--; - pmap_nuke_pv(m, pmap, pv); + TAILQ_REMOVE(&m->md.pv_list, pv, pv_list); + if (pv->pv_flags & PVF_WIRED) + pmap->pm_stats.wired_count--; pmap_free_pv_entry(pmap, pv); PMAP_UNLOCK(pmap); } @@ -2470,6 +2449,7 @@ pmap_remove_all(vm_page_t m) else cpu_tlb_flushD(); } + vm_page_aflag_clear(m, PGA_WRITEABLE); rw_wunlock(&pvh_global_lock); } @@ -3339,7 +3319,9 @@ pmap_pv_reclaim(pmap_t locked_pmap) "va %x pte %x", va, *ptep)); *ptep = 0; PTE_SYNC(ptep); - pmap_nuke_pv(m, pmap, pv); + TAILQ_REMOVE(&m->md.pv_list, pv, pv_list); + if (TAILQ_EMPTY(&m->md.pv_list)) + vm_page_aflag_clear(m, PGA_WRITEABLE); pc->pc_map[field] |= 1UL << bit; freed++; } -- 1.8.2 --------------040509090706030205070508 Content-Type: text/x-patch; name="0013-Clear-all-of-the-protection-bits-in-L2-PTE-before-th.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="0013-Clear-all-of-the-protection-bits-in-L2-PTE-before-th.pa"; filename*1="tch" >From 0f1e316cd5ce2fe60d06cbd4e3a9d3f96aa79561 Mon Sep 17 00:00:00 2001 From: Zbigniew Bodek Date: Mon, 29 Jul 2013 00:06:10 +0200 Subject: [PATCH 2/3] Clear all of the protection bits in L2 PTE before their configuration. Revise L2_S_PROT_MASK to include all of the protection bits. Notice that clearing those bits does not always take away the corresponding permissions (in example the permission is granted when the bit is cleared). The bits are cleared but are to be set or left cleared accordingly in pmap_set_prot(), pmap_enter_locked(), etc. Clear L2_XN along with L2_S_PROT_MASK in pmap_set_prot() so that all permissions related bits are cleared before the actual configuration. Submitted by: Zbigniew Bodek Sponsored by: The FreeBSD Foundation, Semihalf --- sys/arm/arm/pmap-v6.c | 2 +- sys/arm/include/pmap.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sys/arm/arm/pmap-v6.c b/sys/arm/arm/pmap-v6.c index 15eb5e1..cbcecb8 100644 --- a/sys/arm/arm/pmap-v6.c +++ b/sys/arm/arm/pmap-v6.c @@ -1046,7 +1046,7 @@ static void pmap_set_prot(pt_entry_t *ptep, vm_prot_t prot, uint8_t user) { - *ptep &= ~L2_S_PROT_MASK; + *ptep &= ~(L2_S_PROT_MASK | L2_XN); if (!(prot & VM_PROT_EXECUTE)) *ptep |= L2_XN; diff --git a/sys/arm/include/pmap.h b/sys/arm/include/pmap.h index ec40682..b416169 100644 --- a/sys/arm/include/pmap.h +++ b/sys/arm/include/pmap.h @@ -390,7 +390,7 @@ extern int pmap_needs_pte_sync; #define L2_S_PROT_U (L2_AP0(2)) /* user read */ #define L2_S_REF (L2_AP0(1)) /* reference flag */ -#define L2_S_PROT_MASK (L2_S_PROT_U|L2_S_PROT_R) +#define L2_S_PROT_MASK (L2_S_PROT_U|L2_S_PROT_R|L2_APX) #define L2_S_EXECUTABLE(pte) (!(pte & L2_XN)) #define L2_S_WRITABLE(pte) (!(pte & L2_APX)) #define L2_S_REFERENCED(pte) (!!(pte & L2_S_REF)) -- 1.8.2 --------------040509090706030205070508 Content-Type: text/x-patch; name="0014-Fix-ARMv6-v7-mapping-s-wired-status-configuration-in.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="0014-Fix-ARMv6-v7-mapping-s-wired-status-configuration-in.pa"; filename*1="tch" >From f11e954a428e0909192e5754591ab0a3cc494630 Mon Sep 17 00:00:00 2001 From: Zbigniew Bodek Date: Mon, 29 Jul 2013 13:23:57 +0200 Subject: [PATCH 3/3] Fix ARMv6/v7 mapping's wired status configuration in pmap_change_wiring() Last input argument in pmap_modify_pv() should be a mask of flags to be set. In pmap_change_wiring() however, the wired status has been used for that purposes which is not representing any of the valid flags and is of type boolean. This commit fixes that issue so that wired flag is passed to pmap_modify_pv() properly. Submitted by: Zbigniew Bodek Sponsored by: The FreeBSD Foundation, Semihalf --- sys/arm/arm/pmap-v6.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sys/arm/arm/pmap-v6.c b/sys/arm/arm/pmap-v6.c index cbcecb8..3142f56 100644 --- a/sys/arm/arm/pmap-v6.c +++ b/sys/arm/arm/pmap-v6.c @@ -2933,7 +2933,8 @@ pmap_change_wiring(pmap_t pmap, vm_offset_t va, boolean_t wired) pte = *ptep; m = PHYS_TO_VM_PAGE(l2pte_pa(pte)); if (m != NULL) - pmap_modify_pv(m, pmap, va, PVF_WIRED, wired); + pmap_modify_pv(m, pmap, va, PVF_WIRED, + wired == TRUE ? PVF_WIRED : 0); rw_wunlock(&pvh_global_lock); PMAP_UNLOCK(pmap); } -- 1.8.2 --------------040509090706030205070508-- From owner-freebsd-arm@FreeBSD.ORG Mon Jul 29 17:58:27 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B774CF35; Mon, 29 Jul 2013 17:58:27 +0000 (UTC) (envelope-from hans.petter.selasky@bitfrost.no) Received: from mta.bitpro.no (mta.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id 420F625B9; Mon, 29 Jul 2013 17:58:27 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta.bitpro.no (Postfix) with ESMTP id 311BD7A10F; Mon, 29 Jul 2013 19:58:25 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id 7D6388F08E9; Mon, 29 Jul 2013 19:58:30 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no Received: from mail.lockless.no ([127.0.0.1]) by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHqor4BVr9Hw; Mon, 29 Jul 2013 19:58:29 +0200 (CEST) Received: from mail.lockless.no (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id 73D1A8F08E8; Mon, 29 Jul 2013 19:58:29 +0200 (CEST) Subject: RE: My WLI-UC-GNM up crash From: =?utf-8?Q?Hans_Petter_Selasky?= To: =?utf-8?Q?Warner_Losh?= , =?utf-8?Q?Adrian_Chadd?= Date: Mon, 29 Jul 2013 19:58:29 +0200 Mime-Version: 1.0 In-Reply-To: <8AFE4FCA-BCAA-460C-ABFE-EC7FC2991B8C@bsdimp.com> References: X-Priority: 3 (Normal) X-Mailer: Zarafa 7.1.4-41394 Message-Id: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: =?utf-8?Q?freebsd-arm?= , =?utf-8?Q?freebsd-wireless=40freebsd=2Eorg?= X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 17:58:27 -0000 Hi,=0D=0A=0D=0AThe aligned will make sure that the structure gets padded = properly to the size specified. Only on ARM/MIPS etc, structures get auto= matically aligned according to the element in the structure requiring the= greatest alignment. I've test-compiled the USB WLAN drivers, and the ali= gned makes a difference. The problem is that the radiotap header skews so= me following elements, so that they are no longer aligned. The radiotap h= eader itself is packed, and this is not a problem.=0D=0A=0D=0A--HPS=0D=0A= =0D=0A=20=0D=0A-----Original message-----=0D=0A> From:Warner Losh >=0D=0A> Sent: Monday 29th July 2013 17:= 04=0D=0A> To: Adrian Chadd >=0D=0A> Cc: Hans Petter Selasky >; freebsd-arm >; freebsd-wireless@freebsd.org =20=0D=0A> Subject: Re: My WLI-UC-GNM up = crash=0D=0A>=20=0D=0A> Aren't structures already aligned to 4 bytes when = placed inside other structures (unless marked __packed)=3F=0D=0A>=20=0D=0A= > Warner=0D=0A>=20=0D=0A> On Jul 28, 2013, at 11:50 AM, Adrian Chadd wrot= e:=0D=0A>=20=0D=0A> > As long as that results in the radiotap structures = being 4 or 8 byte=0D=0A> > padded when it's embedded in the softc - then = yes, indeed.=0D=0A> >=20=0D=0A> > Xiao, can you try=3F=0D=0A> >=20=0D=0A>= >=20=0D=0A> > -adrian=0D=0A> >=20=0D=0A> > On 28 July 2013 03:35, Hans P= etter Selasky > wrote:=0D=0A> >= > Hi,=0D=0A> >>=20=0D=0A> >> Can you try the attached patch=3F=0D=0A> >>=20= =0D=0A> >> --HPS=0D=0A> > _______________________________________________= =0D=0A> > freebsd-arm@freebsd.org maili= ng list=0D=0A> > http://lists.freebsd.org/mailman/listinfo/freebsd-arm =20=0D=0A> > To unsu= bscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org "=0D=0A>=20=0D=0A>=20=0D=0A=0D=0A From owner-freebsd-arm@FreeBSD.ORG Mon Jul 29 18:19:16 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B75BB4A3 for ; Mon, 29 Jul 2013 18:19:16 +0000 (UTC) (envelope-from hans.stimer@gmail.com) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8FCD926B5 for ; Mon, 29 Jul 2013 18:19:16 +0000 (UTC) Received: by mail-pd0-f169.google.com with SMTP id y11so227576pdj.14 for ; Mon, 29 Jul 2013 11:19:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type; bh=dO4c3+0/zj/eZbkq65YpKV6LQeVnY4HBu2bdOTH7GNo=; b=a8qnu9hTt+D2RNk71WcIBudACVjg6wB8pVFvibLY5oZ5GYdTb4uRz4FQjA7V8yLhMn UFfCc0nkurXKGmCE7rARi70DMrTPQUvzTI9AS3n0/dOYG7RSVbvx7hLr6aLcVTFbLEfx YOrc4N8GZplsEkIUnuMvP7vdsMzhXeAMNIPPzHBwhiZgQSAzQhVSeGftqKmZ52K+ccvQ g/1KveQ5Hqc0LB+1iuUU8qgVlOatwhFq2tZrWlXWIDqOvdmSt5DLBnSpHM4Ue9+0plFt RorZqoaa7L9taeNzLVqCS1SWMDyAlxlrOStHahw1qC6PQW2zotIO4NpeHbSXw2SEyC7t TbUQ== X-Received: by 10.68.29.2 with SMTP id f2mr69623033pbh.184.1375121956161; Mon, 29 Jul 2013 11:19:16 -0700 (PDT) Received: from oli-mp51.local (70-90-170-37-ca.sfba.hfc.comcastbusiness.net. [70.90.170.37]) by mx.google.com with ESMTPSA id eq5sm78303612pbc.15.2013.07.29.11.19.14 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 29 Jul 2013 11:19:15 -0700 (PDT) Date: Mon, 29 Jul 2013 11:19:14 -0700 From: Hans Stimer To: Cc: Message-ID: In-Reply-To: References: Subject: freebsd-arm-tools vs. crochet-freebsd X-Mailer: Airmail (183) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="51f6b222_19495cff_2b7" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 18:19:16 -0000 --51f6b222_19495cff_2b7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What is the difference between freebsd-arm-tools and=C2=A0crochet-freebsd= =3F * Which one is becoming the standard solution for crossbuilding to ARM an= d creating images=3F * Is one =22blessed=22 to become part of the standard freebsd distributio= n=3F * Do they serve different needs=3F --51f6b222_19495cff_2b7-- From owner-freebsd-arm@FreeBSD.ORG Mon Jul 29 18:40:04 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 73D1ACD8 for ; Mon, 29 Jul 2013 18:40:04 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3A98727F6 for ; Mon, 29 Jul 2013 18:40:03 +0000 (UTC) Received: by mail-oa0-f51.google.com with SMTP id h2so1709628oag.10 for ; Mon, 29 Jul 2013 11:39:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:x-priority :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=bmz94YyDrTpr9oVE2lz+bEsdSfVB/dcjpy11m+d8Eic=; b=pw+oMvSGCAg2rScrUvZND28vw9Sv/EZeVKNKp5rLTtraFapg2NsRF2vmD/PS2JQi6R 0lSNWpyMjJAI6MUgH3B8+cnMwpa6LNoZrJLOhCYHObxApmq7CqK9kZt7RLegnyKH4/I8 atdQCW8mUn0/x4YQWUgmTv0l3JxUb8EVwXtxeCGR544v//owX5yANKh8ojF0lILq2tdp oP2L4o+GGRqMFGdAfgkBfjJ0trpGGS1i6XoA79sFKZdC3dExPB8gEOLLBFw3KAW0pM61 hIWBCtpsKVjKec6b8Bk10bO6E3i73szElwl+t16RmPwsMacgTj9xL0OmoIqlKzT/ib9E 0h4g== X-Received: by 10.182.142.129 with SMTP id rw1mr4554697obb.67.1375122844546; Mon, 29 Jul 2013 11:34:04 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id fk3sm89036646obb.2.2013.07.29.11.34.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 11:34:03 -0700 (PDT) Sender: Warner Losh Subject: Re: My WLI-UC-GNM up crash Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh X-Priority: 3 (Normal) In-Reply-To: Date: Mon, 29 Jul 2013 12:34:00 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <3571E4A7-D153-448E-A234-302C9C5603E9@bsdimp.com> References: To: Hans Petter Selasky X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnlTlSj5chI3JHIiezKOCwXgwOKo7GGZPOotBFt5fv6HPFo5QQV9YNgGPiwHXU5Pb4BIYo7 Cc: freebsd-wireless@freebsd.org, freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 18:40:04 -0000 On Jul 29, 2013, at 11:58 AM, Hans Petter Selasky wrote: > The aligned will make sure that the structure gets padded properly to = the size specified. Only on ARM/MIPS etc, structures get automatically = aligned according to the element in the structure requiring the greatest = alignment. I'd turn this around and say only on x86 do structures not get aligned = this way. On any riscy architecture, unaligned accesses are expensive, = which is why the ABI there mandates this. > I've test-compiled the USB WLAN drivers, and the aligned makes a = difference. The problem is that the radiotap header skews some following = elements, so that they are no longer aligned. The radiotap header itself = is packed, and this is not a problem. This suggests a bigger problem. How is the radiotap header being = popualted? Is it by DMA or programmatically? If by DMA then we have = cache line sharing, which is bad. If by program, why is it packed to = start with? Warner > --HPS >=20 > =20 > -----Original message----- > > From:Warner Losh > > Sent: Monday 29th July 2013 17:04 > > To: Adrian Chadd > > Cc: Hans Petter Selasky ; = freebsd-arm ; freebsd-wireless@freebsd.org > > Subject: Re: My WLI-UC-GNM up crash > >=20 > > Aren't structures already aligned to 4 bytes when placed inside = other structures (unless marked __packed)? > >=20 > > Warner > >=20 > > On Jul 28, 2013, at 11:50 AM, Adrian Chadd wrote: > >=20 > > > As long as that results in the radiotap structures being 4 or 8 = byte > > > padded when it's embedded in the softc - then yes, indeed. > > >=20 > > > Xiao, can you try? > > >=20 > > >=20 > > > -adrian > > >=20 > > > On 28 July 2013 03:35, Hans Petter Selasky = wrote: > > >> Hi, > > >>=20 > > >> Can you try the attached patch? > > >>=20 > > >> --HPS > > > _______________________________________________ > > > 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 From owner-freebsd-arm@FreeBSD.ORG Mon Jul 29 19:00:12 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E0299599; Mon, 29 Jul 2013 19:00:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 36BA328F8; Mon, 29 Jul 2013 19:00:12 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r6TJ03MF075661; Mon, 29 Jul 2013 22:00:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r6TJ03MF075661 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r6TJ03UL075657; Mon, 29 Jul 2013 22:00:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 29 Jul 2013 22:00:03 +0300 From: Konstantin Belousov To: Warner Losh Subject: Re: My WLI-UC-GNM up crash Message-ID: <20130729190003.GP4972@kib.kiev.ua> References: <3571E4A7-D153-448E-A234-302C9C5603E9@bsdimp.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9DptZICXTlJ7FQ09" Content-Disposition: inline In-Reply-To: <3571E4A7-D153-448E-A234-302C9C5603E9@bsdimp.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-arm , freebsd-wireless@freebsd.org, Hans Petter Selasky X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 19:00:13 -0000 --9DptZICXTlJ7FQ09 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 29, 2013 at 12:34:00PM -0600, Warner Losh wrote: >=20 > On Jul 29, 2013, at 11:58 AM, Hans Petter Selasky wrote: >=20 > > The aligned will make sure that the structure gets padded properly to t= he size specified. Only on ARM/MIPS etc, structures get automatically align= ed according to the element in the structure requiring the greatest alignme= nt. >=20 > I'd turn this around and say only on x86 do structures not get aligned th= is way. On any riscy architecture, unaligned accesses are expensive, which = is why the ABI there mandates this. >=20 The alignment of the structure to the largest alignment of the member is required by the ABIs on i386 and amd64 as well. --9DptZICXTlJ7FQ09 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR9ruyAAoJEJDCuSvBvK1B2OUQAKYEH7zcCVXK+9U4FBXwJHJc qvtKSL3WGoevcYmf3YWSJ0nlQahEv5eP+q5VHQXdoKykHzhhVhNuKAOSZ3Eyv6Lj Pr/05y0f6uiF9lrbDDjv7g2+dqBP+oWFkLl5bmRESyAaivEtDmn9ST3Xun+YUyEA Qqxg4ye/fU83juWIHPifY6VHp/BZ7TqSIn9HGWXu38Rdi7QkZFgXrWXmWrKJ+59X IvmUdT6UF0BxGiqnYrKRMxKEHYHeNbU+MgUL1r+6AuzT2yG8rMaONm1UADjvMm6d jq77QSc20W1sbm5pYv1ZnwUi3QgttywDJqIXOB8o4J04XUt6fybVnubCHr1PzrHL TKV038Zc5EUZBhfEZQDdUvrJf38VRNr2AFdjgqMRu//Wz9KPTCmvxKPLMsL+DEPL y+qXcY3VCyYtbnE5aJIg5bW1LvSAjbXVUzMFho0AZlChIrXxG0VBwR0guPVITzBu A6/XBAd6idMlz4Umg8QffXkaQv0rU23EZXoAo7J7IJsUqPb+Z04lC4S0/dohqFJW kvYvSHBc210d3ufmQoUY/5gpH4Be+cOgW4xnbLL73LkH+GhywyY4Cg+cbwuKd6kl QhW3rzFs7TTMn0a9hILTOxAmooDu3S93EqSQ4+lGTrHTD4TEdjDq/9PbXPsb6WP6 CQTfviFDirW97Cnp9Xx0 =Rrlz -----END PGP SIGNATURE----- --9DptZICXTlJ7FQ09-- From owner-freebsd-arm@FreeBSD.ORG Mon Jul 29 21:15:54 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 21437F1; Mon, 29 Jul 2013 21:15:54 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E8E7D2141; Mon, 29 Jul 2013 21:15:53 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r6TLFeV2037401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Jul 2013 14:15:40 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r6TLFe26037400; Mon, 29 Jul 2013 14:15:40 -0700 (PDT) (envelope-from jmg) Date: Mon, 29 Jul 2013 14:15:40 -0700 From: John-Mark Gurney To: Hans Petter Selasky Subject: Re: My WLI-UC-GNM up crash Message-ID: <20130729211540.GZ26412@funkthat.com> Mail-Followup-To: Hans Petter Selasky , Warner Losh , Adrian Chadd , freebsd-arm , "freebsd-wireless@freebsd.org" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 29 Jul 2013 14:15:40 -0700 (PDT) Cc: "freebsd-wireless@freebsd.org" , freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 21:15:54 -0000 Hans Petter Selasky wrote this message on Mon, Jul 29, 2013 at 19:58 +0200: > The aligned will make sure that the structure gets padded properly to the size specified. Only on ARM/MIPS etc, structures get automatically aligned according to the element in the structure requiring the greatest alignment. I've test-compiled the USB WLAN drivers, and the aligned makes a difference. The problem is that the radiotap header skews some following elements, so that they are no longer aligned. The radiotap header itself is packed, and this is not a problem. Ouch, has anyone looked at the code that caused this? in ieee80211_radiotap.c, it looks like the original fault was in either set_channel, or set_xchannel, and both do (the equivalent of): struct { uint16_t freq; uint16_t flags; } *rc = p; rc->freq = htole16(c->ic_freq); rc->flags = htole16(c->ic_flags); And then there is complicated code that calculates offsets, etc, in radiotap_offset.. What we probably really need is to mark the above as __packed or equiv so that we don't assume that the passed in pointer is aligned... The whole management of this radiochan and radiotap_offset is pretty nasty... If marking the structures __packed works, it's probably because two bugs are offsetting, and magicly making things align again... > -----Original message----- > > From:Warner Losh > > > Sent: Monday 29th July 2013 17:04 > > To: Adrian Chadd > > > Cc: Hans Petter Selasky >; freebsd-arm >; freebsd-wireless@freebsd.org > > Subject: Re: My WLI-UC-GNM up crash > > > > Aren't structures already aligned to 4 bytes when placed inside other structures (unless marked __packed)? > > > > Warner > > > > On Jul 28, 2013, at 11:50 AM, Adrian Chadd wrote: > > > > > As long as that results in the radiotap structures being 4 or 8 byte > > > padded when it's embedded in the softc - then yes, indeed. > > > > > > Xiao, can you try? > > > > > > > > > -adrian > > > > > > On 28 July 2013 03:35, Hans Petter Selasky > wrote: > > >> Hi, > > >> > > >> Can you try the attached patch? > > >> > > >> --HPS > > > _______________________________________________ > > > 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 " > > > > > > _______________________________________________ > 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" -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Mon Jul 29 22:07:44 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2BBC9469 for ; Mon, 29 Jul 2013 22:07:44 +0000 (UTC) (envelope-from weiss@uni-mainz.de) Received: from mailgate-02.zdv.uni-mainz.de (mailgate-02.zdv.Uni-Mainz.DE [IPv6:2001:4c80:40:62d:203:ffff:fe5d:b2f6]) by mx1.freebsd.org (Postfix) with ESMTP id B87CF2397 for ; Mon, 29 Jul 2013 22:07:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uni-mainz.de; i=@uni-mainz.de; q=dns/txt; s=ironport; t=1375135664; x=1406671664; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=D9crHIen7Va9+rkl1eI6rzKZ2xHff0r51g6Mz2nS+38=; b=aQmNhq7KcWfdNycqyMRWgf9hO7Y6uI4HIkDv+l2mx3A5yLvfCPG/99m4 5uaqIq8otO56n3pd1njpl8+T/0oViSbpclZ7HrzVu96LnYltAXIcrXc38 sdw8QYMZmGCHrvdrBMVsZi1i24geAiEZjUljKjRCipFnjbHH4Fej4tfd8 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAJ7m9lEKXgZY/2dsb2JhbABbgwaBBb1hgRwWdIImBYELAQUDIlYmAQQTCIgImBOgXo9KAoNQbwOIcqA5gxQ8gW4 X-IPAS-Result: AgcFAJ7m9lEKXgZY/2dsb2JhbABbgwaBBb1hgRwWdIImBYELAQUDIlYmAQQTCIgImBOgXo9KAoNQbwOIcqA5gxQ8gW4 Received: from e14hub-02.zdv.uni-mainz.de ([10.94.6.88]) by mailgate-02.zdv.uni-mainz.de with ESMTP; 30 Jul 2013 00:07:42 +0200 Received: from E14MDB-02.zdv.Uni-Mainz.DE ([fe80::1b:21ff:fe65:4560]) by E14HUB-02.zdv.Uni-Mainz.DE ([fe80::21d:d8ff:feb7:1c60%9]) with mapi id 14.03.0146.000; Tue, 30 Jul 2013 00:07:41 +0200 From: =?iso-8859-1?B?V2Vp3ywgSvxyZ2Vu?= To: "'freebsd-arm@freebsd.org'" Subject: Re: Wandboard support? Thread-Topic: Re: Wandboard support? Thread-Index: Ac6MmYVaznSYbZ86TrWow29MGvIYnQ== Date: Mon, 29 Jul 2013 22:07:40 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.93.178.81] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 22:07:44 -0000 Hallo, I have been playing with a Wandboard Dual for some time. Serial and USB host ports work. Non SMP kernel boots single user to memory disk and as of tonight multiuser to USB flash.=20 Regards Juergen Juergen Weiss |Universitaet Mainz, Zentrum fuer Datenverarbeitung, weiss@uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361, FAX: +49(6131)39-2= 6407 From owner-freebsd-arm@FreeBSD.ORG Mon Jul 29 23:53:58 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8121D9A3; Mon, 29 Jul 2013 23:53:58 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 534512774; Mon, 29 Jul 2013 23:53:57 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6TNruDT030806; Mon, 29 Jul 2013 19:53:56 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6TNrucv030801; Mon, 29 Jul 2013 23:53:56 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 29 Jul 2013 23:53:56 GMT Message-Id: <201307292353.r6TNrucv030801@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 23:53:58 -0000 TB --- 2013-07-29 20:50:20 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-29 20:50:20 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-29 20:50:20 - starting HEAD tinderbox run for arm/arm TB --- 2013-07-29 20:50:20 - cleaning the object tree TB --- 2013-07-29 20:54:21 - /usr/local/bin/svn stat /src TB --- 2013-07-29 20:54:24 - At svn revision 253785 TB --- 2013-07-29 20:54:25 - building world TB --- 2013-07-29 20:54:25 - CROSS_BUILD_TESTING=YES TB --- 2013-07-29 20:54:25 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-29 20:54:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-29 20:54:25 - SRCCONF=/dev/null TB --- 2013-07-29 20:54:25 - TARGET=arm TB --- 2013-07-29 20:54:25 - TARGET_ARCH=arm TB --- 2013-07-29 20:54:25 - TZ=UTC TB --- 2013-07-29 20:54:25 - __MAKE_CONF=/dev/null TB --- 2013-07-29 20:54:25 - cd /src TB --- 2013-07-29 20:54:25 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Jul 29 20:54:31 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Jul 29 23:53:34 UTC 2013 TB --- 2013-07-29 23:53:34 - generating LINT kernel config TB --- 2013-07-29 23:53:34 - cd /src/sys/arm/conf TB --- 2013-07-29 23:53:34 - /usr/bin/make -B LINT TB --- 2013-07-29 23:53:35 - cd /src/sys/arm/conf TB --- 2013-07-29 23:53:35 - /usr/sbin/config -m LINT TB --- 2013-07-29 23:53:35 - building LINT kernel TB --- 2013-07-29 23:53:35 - CROSS_BUILD_TESTING=YES TB --- 2013-07-29 23:53:35 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-29 23:53:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-29 23:53:35 - SRCCONF=/dev/null TB --- 2013-07-29 23:53:35 - TARGET=arm TB --- 2013-07-29 23:53:35 - TARGET_ARCH=arm TB --- 2013-07-29 23:53:35 - TZ=UTC TB --- 2013-07-29 23:53:35 - __MAKE_CONF=/dev/null TB --- 2013-07-29 23:53:35 - cd /src TB --- 2013-07-29 23:53:35 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jul 29 23:53:35 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree [...] rm -f @ machine rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> xl (cleandir) rm -f export_syms if_xl.ko if_xl.kld if_xl.o xlphy.o miibus_if.h pci_if.h bus_if.h device_if.h miidevs.h rm -f @ machine rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> yarrow_rng (cleandir) cd: can't cd to /src/sys/modules/yarrow_rng *** Error code 2 Stop. bmake: stopped in /src/sys/modules *** Error code 1 Stop. bmake: stopped in /obj/arm.arm/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-29 23:53:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-29 23:53:56 - ERROR: failed to build LINT kernel TB --- 2013-07-29 23:53:56 - 8695.03 user 1486.25 system 11016.02 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue Jul 30 00:03:39 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0942ECBE for ; Tue, 30 Jul 2013 00:03:39 +0000 (UTC) (envelope-from dan@langille.org) Received: from nyi.unixathome.org (nyi.unixathome.org [64.147.113.42]) by mx1.freebsd.org (Postfix) with ESMTP id D6E4827E5 for ; Tue, 30 Jul 2013 00:03:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by nyi.unixathome.org (Postfix) with ESMTP id 3BB6F50A0C for ; Tue, 30 Jul 2013 00:03:37 +0000 (UTC) X-Virus-Scanned: amavisd-new at unixathome.org Received: from nyi.unixathome.org ([127.0.0.1]) by localhost (nyi.unixathome.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4RsTaPmYsVK for ; Tue, 30 Jul 2013 00:03:29 +0000 (UTC) Received: from smtp-auth.unixathome.org (smtp-auth.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) by nyi.unixathome.org (Postfix) with ESMTPSA id 5DD235092C for ; Tue, 30 Jul 2013 00:03:24 +0000 (UTC) From: Dan Langille Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Raspberry Pi as portable WAP / hotspot Date: Mon, 29 Jul 2013 20:03:16 -0400 Message-Id: <7A5E7171-F473-414F-95DC-C21444C96DFF@langille.org> To: freebsd-arm@freebsd.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 00:03:39 -0000 Hello, I'm looking into setting up a Raspberry Pi as a portable hot-spot. The idea is to rent / buy a USB air card, and use that as the internet = access. Then the unit will supply wifi for phone, tablet, printer=85 Or would it make more sense to use a purpose built airplay unit from the = same ISP=85 Probably=85 --=20 Dan Langille - http://langille.org From owner-freebsd-arm@FreeBSD.ORG Tue Jul 30 00:38:25 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 93AC1263 for ; Tue, 30 Jul 2013 00:38:25 +0000 (UTC) (envelope-from dave@dogwood.com) Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4E8E02929 for ; Tue, 30 Jul 2013 00:38:25 +0000 (UTC) Received: by mail-ve0-f170.google.com with SMTP id 15so856292vea.15 for ; Mon, 29 Jul 2013 17:38:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dogwood.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=18TWCTylOpe94CXMNwwyQYKpNo0dxgkW5pl4l/wZKBw=; b=MqKxyfMNBwlUZWA1dQcCoMrFC/GmYVFMhIeViXI5/KRK4IeqeycWL4b5LJikaPpnic aP1OMj9e5lShknuiMJu+msprwpD2h5CDfy4KbdoS8Iaj+1D28SDrFUdyRsm287tckd17 FaOWNOZ1oa1msZQQoF1nlVl7p0AuJg46dFODo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=18TWCTylOpe94CXMNwwyQYKpNo0dxgkW5pl4l/wZKBw=; b=XewLoR66md1HUCe/PKDiCzfuBPJdUxE9NlORpIQPRdTzCZ7v1eGTJfPTAd5GzAApaK QqnrUTb9PONXBT+p+wDJ+D8J3JFbc9AEBy7pk518GPkqufywu6/hzxyCYBqtX271SuHo /XQnhy3L//XJqgtcYGqyY40OsqdX7jzEro5Xa1LDhfhPIcPSy05uMbY431Sy3UcF9H9M qoWEdqckE/3srFRbIaV+QqtiCAZY7m/Lnk5Di+zPV/w7kvw3DVsNCee4Tdy+aEFy7hDc p9FparLc1y/9E0XHq9JB+x6R1ZVVeDGk2oAA/rMdAaOAnVqQiEt1vq0p1q6weFbg6le1 V1rA== MIME-Version: 1.0 X-Received: by 10.58.119.233 with SMTP id kx9mr26851870veb.3.1375144704448; Mon, 29 Jul 2013 17:38:24 -0700 (PDT) Received: by 10.52.156.131 with HTTP; Mon, 29 Jul 2013 17:38:24 -0700 (PDT) In-Reply-To: <7A5E7171-F473-414F-95DC-C21444C96DFF@langille.org> References: <7A5E7171-F473-414F-95DC-C21444C96DFF@langille.org> Date: Mon, 29 Jul 2013 14:38:24 -1000 Message-ID: Subject: Re: Raspberry Pi as portable WAP / hotspot From: David Cornejo To: Dan Langille X-Gm-Message-State: ALoCoQmTOFmc0AyqW5BgFoO7SEdm3hKj3qwqGojecyhgUxSVjla0n/gwDR/fXgGiJFCnK/RjLFKB Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 00:38:25 -0000 On Mon, Jul 29, 2013 at 2:03 PM, Dan Langille wrote: > Hello, > > I'm looking into setting up a Raspberry Pi as a portable hot-spot. > > The idea is to rent / buy a USB air card, and use that as the internet > access. Then the unit will supply wifi for phone, tablet, printer=85 > > Or would it make more sense to use a purpose built airplay unit from the > same ISP=85 Probably=85 > > -- > Dan Langille - http://langille.org > > _______________________________________________ > 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" > I've been underwhelmed by the performance of my Raspberry Pi w/FreeBSD - WiFi and the Broadband adapter both run over USB and that seems to be a bottleneck. I ended up buying a mobile hotspot which probably cost me less than my rpi after case, power, cabling, usb broadband adapter, SD card, etc= . Building your own does have a certain appeal though... dave c From owner-freebsd-arm@FreeBSD.ORG Tue Jul 30 01:16:30 2013 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8B8D7814; Tue, 30 Jul 2013 01:16:30 +0000 (UTC) (envelope-from db@db.net) Received: from diana.db.net (unknown [IPv6:2620:64:0:1:223:7dff:fea2:c8f2]) by mx1.freebsd.org (Postfix) with ESMTP id 713D62AAC; Tue, 30 Jul 2013 01:16:30 +0000 (UTC) Received: from night.db.net (localhost [127.0.0.1]) by diana.db.net (Postfix) with ESMTP id 43E8D2AA4C6; Mon, 29 Jul 2013 19:16:29 -0600 (MDT) Received: by night.db.net (Postfix, from userid 1000) id 6F5621CC0E; Mon, 29 Jul 2013 20:16:19 -0500 (EST) Date: Mon, 29 Jul 2013 20:16:19 -0500 From: Diane Bruce To: Warner Losh Subject: Re: route(8) broken? Message-ID: <20130730011619.GA85930@night.db.net> References: <1375038369.45247.19.camel@revolution.hippie.lan> <9F949656-7819-46AF-AC31-CBAE8EE0D39C@FreeBSD.org> <75A1D99D-2E0F-435C-AAF4-A881AC68B04C@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <75A1D99D-2E0F-435C-AAF4-A881AC68B04C@bsdimp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-arm@freebsd.org" , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 01:16:30 -0000 On Mon, Jul 29, 2013 at 09:07:45AM -0600, Warner Losh wrote: > > On Jul 28, 2013, at 3:26 PM, Tim Kientzle wrote: > > Unrelated: have you had any luck using native gdb? > > > > I started to try to debug the route failure and gdb > > is acting a little strange. Everytime I hit 'n' it just > > runs to completion, occasionally with complaints about > > missing debug information. (Yes, the binary in > > question does have debug information and when > > I set a breakpoint it will stop and show the related > > source.) > > > > I suspect it might be related to gdb not recognizing > > the language: > > > > "Current language: auto; currently minimal" > > -O2 fallout? I've had to remove -O anything at times when debugging on arm because our tools don't generate good debugging info when things are highly optimized. > > Warner > Not had problems with gdb. What I have done is compile a version of libc.a with my jemalloc hacks compiled with -g and linked sshd against only that version of libc.a Works like a charm. Tim I have a few more notes about jemalloc I'll email directly. - Diane -- - db@FreeBSD.org db@db.net http://www.db.net/~db From owner-freebsd-arm@FreeBSD.ORG Tue Jul 30 02:25:06 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 618EC74C; Tue, 30 Jul 2013 02:25:06 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 24A8D2D3A; Tue, 30 Jul 2013 02:25:05 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1V3zcQ-0003qn-LO; Tue, 30 Jul 2013 02:24:58 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r6U2Otlr017693; Mon, 29 Jul 2013 20:24:55 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+E1uPtrsStc5/oJSWS8JDY Subject: Re: My WLI-UC-GNM up crash From: Ian Lepore To: John-Mark Gurney In-Reply-To: <20130729211540.GZ26412@funkthat.com> References: <20130729211540.GZ26412@funkthat.com> Content-Type: text/plain; charset="us-ascii" Date: Mon, 29 Jul 2013 20:24:55 -0600 Message-ID: <1375151095.45247.54.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm , "freebsd-wireless@freebsd.org" , Hans Petter Selasky X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 02:25:06 -0000 On Mon, 2013-07-29 at 14:15 -0700, John-Mark Gurney wrote: > Hans Petter Selasky wrote this message on Mon, Jul 29, 2013 at 19:58 +0200: > > The aligned will make sure that the structure gets padded properly to the size specified. Only on ARM/MIPS etc, structures get automatically aligned according to the element in the structure requiring the greatest alignment. I've test-compiled the USB WLAN drivers, and the aligned makes a difference. The problem is that the radiotap header skews some following elements, so that they are no longer aligned. The radiotap header itself is packed, and this is not a problem. > > Ouch, has anyone looked at the code that caused this? > > in ieee80211_radiotap.c, it looks like the original fault was in either > set_channel, or set_xchannel, and both do (the equivalent of): > struct { > uint16_t freq; > uint16_t flags; > } *rc = p; > > rc->freq = htole16(c->ic_freq); > rc->flags = htole16(c->ic_flags); > If there's any chance the pointer isn't aligned in code like this, then htole16() is the wrong function, it should be using le16enc() such as le16enc(&rc->freq, c->ic_freq); le16enc(&rc->flags, c->ic_flags); With any luck, an x86 compiler can optimize the inline code for the endian enc/dec functions to take advantage of the platform's ability to do unaligned accesses. But that's a side issue to code correctness -- portable code has to get these things right even when it's inefficient. -- Ian > And then there is complicated code that calculates offsets, etc, in > radiotap_offset.. What we probably really need is to mark the above > as __packed or equiv so that we don't assume that the passed in pointer > is aligned... > > The whole management of this radiochan and radiotap_offset is pretty > nasty... If marking the structures __packed works, it's probably > because two bugs are offsetting, and magicly making things align > again... > > > -----Original message----- > > > From:Warner Losh > > > > Sent: Monday 29th July 2013 17:04 > > > To: Adrian Chadd > > > > Cc: Hans Petter Selasky >; freebsd-arm >; freebsd-wireless@freebsd.org > > > Subject: Re: My WLI-UC-GNM up crash > > > > > > Aren't structures already aligned to 4 bytes when placed inside other structures (unless marked __packed)? > > > > > > Warner > > > > > > On Jul 28, 2013, at 11:50 AM, Adrian Chadd wrote: > > > > > > > As long as that results in the radiotap structures being 4 or 8 byte > > > > padded when it's embedded in the softc - then yes, indeed. > > > > > > > > Xiao, can you try? > > > > > > > > > > > > -adrian > > > > > > > > On 28 July 2013 03:35, Hans Petter Selasky > wrote: > > > >> Hi, > > > >> > > > >> Can you try the attached patch? > > > >> > > > >> --HPS > > > > _______________________________________________ > > > > 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 " > > > > > > > > > > _______________________________________________ > > 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" > From owner-freebsd-arm@FreeBSD.ORG Tue Jul 30 03:01:24 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 54FE7109 for ; Tue, 30 Jul 2013 03:01:24 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2B15C2EF6 for ; Tue, 30 Jul 2013 03:01:23 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1V40Be-000KTO-Tu; Tue, 30 Jul 2013 03:01:23 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r6U31JrZ017755; Mon, 29 Jul 2013 21:01:19 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18p0AIoK5thbAJT6D0qJ5N7 Subject: Re: Wandboard support? From: Ian Lepore To: =?ISO-8859-1?Q?Wei=DF=2C_J=FCrgen?= In-Reply-To: References: Content-Type: text/plain; charset="ISO-8859-1" Date: Mon, 29 Jul 2013 21:01:19 -0600 Message-ID: <1375153279.45247.61.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id r6U31JrZ017755 Cc: "'freebsd-arm@freebsd.org'" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 03:01:24 -0000 On Mon, 2013-07-29 at 22:07 +0000, Wei=DF, J=FCrgen wrote: > Hallo, >=20 > I have been playing with a Wandboard Dual for some time. > Serial and USB host ports work. Non SMP kernel boots single > user to memory disk and as of tonight multiuser to USB flash.=20 >=20 > Regards >=20 > Juergen >=20 > Juergen Weiss |Universitaet Mainz, Zentrum fuer Datenverarbeitung, > weiss@uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361, FAX: +49(6131)= 39-26407 >=20 If you'd like to share patches for that I'd be happy to commit them. Once we have even a minimally bootable system, it becomes easier for others to contribute more functionality. I've been playing with my Wandboard Solo for a couple days, but I can't seem to get through ehci_init() without hanging right now. -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Jul 30 08:14:45 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4DD49178; Tue, 30 Jul 2013 08:14:45 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2167C2BE0; Tue, 30 Jul 2013 08:14:44 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6U8Ei7f021744; Tue, 30 Jul 2013 04:14:44 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6U8EiE6021743; Tue, 30 Jul 2013 08:14:44 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 30 Jul 2013 08:14:44 GMT Message-Id: <201307300814.r6U8EiE6021743@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 08:14:45 -0000 TB --- 2013-07-30 04:40:20 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-30 04:40:20 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-30 04:40:20 - starting HEAD tinderbox run for arm/arm TB --- 2013-07-30 04:40:20 - cleaning the object tree TB --- 2013-07-30 04:45:27 - /usr/local/bin/svn stat /src TB --- 2013-07-30 04:45:30 - At svn revision 253790 TB --- 2013-07-30 04:45:31 - building world TB --- 2013-07-30 04:45:31 - CROSS_BUILD_TESTING=YES TB --- 2013-07-30 04:45:31 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-30 04:45:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-30 04:45:31 - SRCCONF=/dev/null TB --- 2013-07-30 04:45:31 - TARGET=arm TB --- 2013-07-30 04:45:31 - TARGET_ARCH=arm TB --- 2013-07-30 04:45:31 - TZ=UTC TB --- 2013-07-30 04:45:31 - __MAKE_CONF=/dev/null TB --- 2013-07-30 04:45:31 - cd /src TB --- 2013-07-30 04:45:31 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Jul 30 04:45:39 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Jul 30 07:51:42 UTC 2013 TB --- 2013-07-30 07:51:42 - generating LINT kernel config TB --- 2013-07-30 07:51:42 - cd /src/sys/arm/conf TB --- 2013-07-30 07:51:42 - /usr/bin/make -B LINT TB --- 2013-07-30 07:51:42 - cd /src/sys/arm/conf TB --- 2013-07-30 07:51:42 - /usr/sbin/config -m LINT TB --- 2013-07-30 07:51:42 - building LINT kernel TB --- 2013-07-30 07:51:42 - CROSS_BUILD_TESTING=YES TB --- 2013-07-30 07:51:42 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-30 07:51:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-30 07:51:42 - SRCCONF=/dev/null TB --- 2013-07-30 07:51:42 - TARGET=arm TB --- 2013-07-30 07:51:42 - TARGET_ARCH=arm TB --- 2013-07-30 07:51:42 - TZ=UTC TB --- 2013-07-30 07:51:42 - __MAKE_CONF=/dev/null TB --- 2013-07-30 07:51:42 - cd /src TB --- 2013-07-30 07:51:42 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jul 30 07:51:42 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] :> export_syms awk -f /src/sys/conf/kmod_syms.awk if_run.kld export_syms | xargs -J% objcopy % if_run.kld ld -Bshareable -d -warn-common -o if_run.ko if_run.kld objcopy --strip-debug if_run.ko ===> usb/runfw (all) bmake: don't know how to make /src/sys/modules/usb/runfw/../../contrib/dev/run/rt2870.fw.uu. Stop bmake: stopped in /src/sys/modules/usb/runfw *** Error code 2 Stop. bmake: stopped in /src/sys/modules/usb *** Error code 1 Stop. bmake: stopped in /src/sys/modules *** Error code 1 Stop. bmake: stopped in /obj/arm.arm/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-30 08:14:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-30 08:14:44 - ERROR: failed to build LINT kernel TB --- 2013-07-30 08:14:44 - 9654.21 user 1788.18 system 12863.36 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue Jul 30 09:51:55 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CAF40117 for ; Tue, 30 Jul 2013 09:51:55 +0000 (UTC) (envelope-from taguchi.ch@gmail.com) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A4651229D for ; Tue, 30 Jul 2013 09:51:55 +0000 (UTC) Received: by mail-pa0-f46.google.com with SMTP id fa1so6945205pad.5 for ; Tue, 30 Jul 2013 02:51:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=PIGW8OnXTebJwEwHk0fNYr5ZpZjS5TSyND45uhi/fso=; b=g/7FF6FwZzKHzno6XptdtbSUDPsZu1vdXuA5eSnLCiYA0LEwtzWvDPPJ9Xzpm7pelp uWbmZAXXbExA36TUDIczhB4q9N4jxW4kseLaTpmAYBRxwcZXL0FTKGMx4NXp31mVsuJ/ DdzEunWk4kgOD+yLxjd8bVhkgiqHOMuvB1PbxIXqXonXwlDpzn/0W/daJ2sVBRE9Rdui hJV3UfR56XHvUdjYVrNFC5L2hxYSKIkjSoWZkm60vx7LfcInhYYb5P4rx1Mm8PRM09jj rTqaD4Rq2iopjMt9lUg2Jpfx34lm76p7XHpbE9XKxmatQ32Bc86Kl+9VuL+d+/8tZH5p Dajw== X-Received: by 10.66.159.132 with SMTP id xc4mr40015366pab.27.1375177915319; Tue, 30 Jul 2013 02:51:55 -0700 (PDT) Received: from [10.0.1.131] (48.178.30.125.dy.iij4u.or.jp. [125.30.178.48]) by mx.google.com with ESMTPSA id dc5sm82035818pbc.37.2013.07.30.02.51.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Jul 2013 02:51:54 -0700 (PDT) From: Chie Taguchi Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: libgcrypt issue Date: Tue, 30 Jul 2013 18:51:51 +0900 Message-Id: To: freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 09:51:56 -0000 hi all, i want to build security/libgcrypt on my raspberrypi. uname -a FreeBSD raspberry-pi 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r253638: Fri = Jul 26 17:24:33 JST 2013 but compiling was failed with many errors. i had added my Makefike 'MAKE_JOBS_UNSAFE=3Dyes' and commented out = 'MAKE_JOBS_SAFE=3Dyes', but got same errors. and i searched for the solutions, but i could find only to use package. i want to know how to fix this ports. does anyone know where is the patch files or ports skelton to make the = package? Regards, C.Taguchi ------ error messages: =3D=3D=3D> Building for libgcrypt-1.5.2 make all-recursive Making all in compat Making all in mpi /bin/sh /usr/local/bin/libtool --tag=3DCC --mode=3Dcompile cc = -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/usr/local/include -O = -pipe -std=3Dgnu89 -fvisibility=3Dhidden -Wall -MT mpih-div.lo -MD -MP = -MF .deps/mpih-div.Tpo -c -o mpih-div.lo mpih-div.c libtool: compile: cc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src = -I/usr/local/include -O -pipe -std=3Dgnu89 -fvisibility=3Dhidden -Wall = -MT mpih-div.lo -MD -MP -MF .deps/mpih-div.Tpo -c mpih-div.c -fPIC = -DPIC -o .libs/mpih-div.o mpih-div.c:98:3: error: invalid use of a cast in a inline asm context = requiring an l-value: remove the cast or build with = -fheinous-gnu-extensions UDIV_QRNND_PREINV(dummy, r, r, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./mpi-internal.h:150:13: note: expanded from macro 'UDIV_QRNND_PREINV' umul_ppmm (_q, _ql, (nh), (di)); \ ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~ ./longlong.h:230:25: note: expanded from macro 'umul_ppmm' : "=3D&r" ((USItype)(xh)), = \ ^ mpih-div.c:98:3: error: invalid use of a cast in a inline asm context = requiring an l-value: remove the cast or build with = -fheinous-gnu-extensions UDIV_QRNND_PREINV(dummy, r, r, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./mpi-internal.h:150:17: note: expanded from macro 'UDIV_QRNND_PREINV' umul_ppmm (_q, _ql, (nh), (di)); \ ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~ ./longlong.h:231:24: note: expanded from macro 'umul_ppmm' "=3Dr" ((USItype)(xl)) = \ ^ mpih-div.c:98:3: error: invalid % escape in inline assembly string UDIV_QRNND_PREINV(dummy, r, r, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./mpi-internal.h:150:2: note: expanded from macro 'UDIV_QRNND_PREINV' umul_ppmm (_q, _ql, (nh), (di)); \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./longlong.h:228:14: note: expanded from macro 'umul_ppmm' __asm__ ("%@ Inlined umul_ppmm\n" = \ = ~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ mpih-div.c:98:3: error: invalid use of a cast in a inline asm context = requiring an l-value: remove the cast or build with = -fheinous-gnu-extensions UDIV_QRNND_PREINV(dummy, r, r, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./mpi-internal.h:152:13: note: expanded from macro 'UDIV_QRNND_PREINV' umul_ppmm (_xh, _xl, _q, (d)); \ ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~ ./longlong.h:230:25: note: expanded from macro 'umul_ppmm' : "=3D&r" ((USItype)(xh)), = \ ^ mpih-div.c:98:3: error: invalid use of a cast in a inline asm context = requiring an l-value: remove the cast or build with = -fheinous-gnu-extensions UDIV_QRNND_PREINV(dummy, r, r, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./mpi-internal.h:152:18: note: expanded from macro 'UDIV_QRNND_PREINV' umul_ppmm (_xh, _xl, _q, (d)); \ ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~ ./longlong.h:231:24: note: expanded from macro 'umul_ppmm' "=3Dr" ((USItype)(xl)) = \ ^ mpih-div.c:98:3: error: invalid % escape in inline assembly string UDIV_QRNND_PREINV(dummy, r, r, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./mpi-internal.h:152:2: note: expanded from macro 'UDIV_QRNND_PREINV' umul_ppmm (_xh, _xl, _q, (d)); \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./longlong.h:228:14: note: expanded from macro 'umul_ppmm' __asm__ ("%@ Inlined umul_ppmm\n" = \ = ~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ mpih-div.c:98:3: error: invalid use of a cast in a inline asm context = requiring an l-value: remove the cast or build with = -fheinous-gnu-extensions UDIV_QRNND_PREINV(dummy, r, r, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./mpi-internal.h:153:14: note: expanded from macro 'UDIV_QRNND_PREINV' sub_ddmmss (_xh, _r, (nh), (nl), _xh, _xl); \ ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./longlong.h:200:23: note: expanded from macro 'sub_ddmmss' : "=3Dr" ((USItype)(sh)), = \ ^ mpih-div.c:98:3: error: invalid use of a cast in a inline asm context = requiring an l-value: remove the cast or build with = -fheinous-gnu-extensions UDIV_QRNND_PREINV(dummy, r, r, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./mpi-internal.h:153:19: note: expanded from macro 'UDIV_QRNND_PREINV' sub_ddmmss (_xh, _r, (nh), (nl), _xh, _xl); \ ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~ ./longlong.h:201:24: note: expanded from macro 'sub_ddmmss' "=3D&r" ((USItype)(sl)) = \ ^ mpih-div.c:98:3: error: invalid use of a cast in a inline asm context = requiring an l-value: remove the cast or build with = -fheinous-gnu-extensions UDIV_QRNND_PREINV(dummy, r, r, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./mpi-internal.h:155:18: note: expanded from macro 'UDIV_QRNND_PREINV' sub_ddmmss (_xh, _r, _xh, _r, 0, (d)); \ ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~ ./longlong.h:200:23: note: expanded from macro 'sub_ddmmss' : "=3Dr" ((USItype)(sh)), = \ ^ mpih-div.c:98:3: error: invalid use of a cast in a inline asm context = requiring an l-value: remove the cast or build with = -fheinous-gnu-extensions UDIV_QRNND_PREINV(dummy, r, r, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./mpi-internal.h:155:23: note: expanded from macro 'UDIV_QRNND_PREINV' sub_ddmmss (_xh, _r, _xh, _r, 0, (d)); \ ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~ ./longlong.h:201:24: note: expanded from macro 'sub_ddmmss' "=3D&r" ((USItype)(sl)) = \ ^ mpih-div.c:98:3: error: invalid use of a cast in a inline asm context = requiring an l-value: remove the cast or build with = -fheinous-gnu-extensions UDIV_QRNND_PREINV(dummy, r, r, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./mpi-internal.h:158:15: note: expanded from macro 'UDIV_QRNND_PREINV' sub_ddmmss (_xh, _r, _xh, _r, 0, (d)); \ ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~ ./longlong.h:200:23: note: expanded from macro 'sub_ddmmss' : "=3Dr" ((USItype)(sh)), = \ ^ mpih-div.c:98:3: error: invalid use of a cast in a inline asm context = requiring an l-value: remove the cast or build with = -fheinous-gnu-extensions UDIV_QRNND_PREINV(dummy, r, r, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./mpi-internal.h:158:20: note: expanded from macro 'UDIV_QRNND_PREINV' sub_ddmmss (_xh, _r, _xh, _r, 0, (d)); \ ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~ ./longlong.h:201:24: note: expanded from macro 'sub_ddmmss' "=3D&r" ((USItype)(sl)) = \ ^ mpih-div.c:104:6: error: invalid use of a cast in a inline asm context = requiring an l-value: remove the cast or build with = -fheinous-gnu-extensions UDIV_QRNND_PREINV(dummy, r, r, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./mpi-internal.h:150:13: note: expanded from macro 'UDIV_QRNND_PREINV' umul_ppmm (_q, _ql, (nh), (di)); \ ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~ ./longlong.h:230:25: note: expanded from macro 'umul_ppmm' : "=3D&r" ((USItype)(xh)), = \ ^ mpih-div.c:104:6: error: invalid use of a cast in a inline asm context = requiring an l-value: remove the cast or build with = -fheinous-gnu-extensions UDIV_QRNND_PREINV(dummy, r, r, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./mpi-internal.h:150:17: note: expanded from macro 'UDIV_QRNND_PREINV' umul_ppmm (_q, _ql, (nh), (di)); \ ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~ ./longlong.h:231:24: note: expanded from macro 'umul_ppmm' "=3Dr" ((USItype)(xl)) = \ ^ mpih-div.c:104:6: error: invalid % escape in inline assembly string UDIV_QRNND_PREINV(dummy, r, r, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./mpi-internal.h:150:2: note: expanded from macro 'UDIV_QRNND_PREINV' umul_ppmm (_q, _ql, (nh), (di)); \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./longlong.h:228:14: note: expanded from macro 'umul_ppmm' __asm__ ("%@ Inlined umul_ppmm\n" = \ = ~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ mpih-div.c:104:6: error: invalid use of a cast in a inline asm context = requiring an l-value: remove the cast or build with = -fheinous-gnu-extensions UDIV_QRNND_PREINV(dummy, r, r, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./mpi-internal.h:152:13: note: expanded from macro 'UDIV_QRNND_PREINV' umul_ppmm (_xh, _xl, _q, (d)); \ ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~ ./longlong.h:230:25: note: expanded from macro 'umul_ppmm' : "=3D&r" ((USItype)(xh)), = \ ^ mpih-div.c:104:6: error: invalid use of a cast in a inline asm context = requiring an l-value: remove the cast or build with = -fheinous-gnu-extensions UDIV_QRNND_PREINV(dummy, r, r, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./mpi-internal.h:152:18: note: expanded from macro 'UDIV_QRNND_PREINV' umul_ppmm (_xh, _xl, _q, (d)); \ ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~ ./longlong.h:231:24: note: expanded from macro 'umul_ppmm' "=3Dr" ((USItype)(xl)) = \ ^ mpih-div.c:104:6: error: invalid % escape in inline assembly string UDIV_QRNND_PREINV(dummy, r, r, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./mpi-internal.h:152:2: note: expanded from macro 'UDIV_QRNND_PREINV' umul_ppmm (_xh, _xl, _q, (d)); \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./longlong.h:228:14: note: expanded from macro 'umul_ppmm' __asm__ ("%@ Inlined umul_ppmm\n" = \ = ~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ mpih-div.c:104:6: error: invalid use of a cast in a inline asm context = requiring an l-value: remove the cast or build with = -fheinous-gnu-extensions UDIV_QRNND_PREINV(dummy, r, r, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./mpi-internal.h:153:14: note: expanded from macro 'UDIV_QRNND_PREINV' sub_ddmmss (_xh, _r, (nh), (nl), _xh, _xl); \ ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./longlong.h:200:23: note: expanded from macro 'sub_ddmmss' : "=3Dr" ((USItype)(sh)), = \ ^ fatal error: too many errors emitted, stopping now [-ferror-limit=3D] 20 errors generated. *** [mpih-div.lo] Error code 1 make: stopped in /usr/ports/security/libgcrypt/work/libgcrypt-1.5.2/mpi 1 error make: stopped in /usr/ports/security/libgcrypt/work/libgcrypt-1.5.2/mpi *** [all-recursive] Error code 1 make: stopped in /usr/ports/security/libgcrypt/work/libgcrypt-1.5.2 1 error make: stopped in /usr/ports/security/libgcrypt/work/libgcrypt-1.5.2 *** [all] Error code 2 make: stopped in /usr/ports/security/libgcrypt/work/libgcrypt-1.5.2 1 error make: stopped in /usr/ports/security/libgcrypt/work/libgcrypt-1.5.2 =3D=3D=3D> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=3Dyes and rebuild before reporting the = failure to the maintainer. *** Error code 1 Stop. make: stopped in /usr/ports/security/libgcrypt *** Error code 1 From owner-freebsd-arm@FreeBSD.ORG Tue Jul 30 12:34:53 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A7051C19 for ; Tue, 30 Jul 2013 12:34:53 +0000 (UTC) (envelope-from taguchi.ch@gmail.com) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 742B42E3A for ; Tue, 30 Jul 2013 12:34:53 +0000 (UTC) Received: by mail-oa0-f51.google.com with SMTP id h2so3797733oag.10 for ; Tue, 30 Jul 2013 05:34:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CqSjLfbRuTOqn8dZTlX9D5Ht7eBb0DxIf/JIQEylxI8=; b=zX0QrorsOmF+EJQrZr9Ku2/cDyRnGLMv4iSt2MRIm1gygRyPdL9yfmopVMRlmUuE8p qb4Q5V3EbxB9M5Nn0ptc4XWMr7ZeBncs2wOBz5oN8pWQ4bRJf6B06djlRa2SelNoD71o nAwwicWYPM6x0q6BoS+aO1eO+u4/cPXnfmC0lWqavi2WT5NqyfhwiKdd2p5NTcg6q4FD u2/NDqXPJtUwsSAH4L6ej/abD9fQcChfUqvYdOJz36mprC/heYXZQ6MklCdO2Wrx5wZB x81ajFsQogvlsvNsicQG+m6ygQT/0Wg7oTLwv7O+AO5LvjCIs4Hc6crGOmTTVnCZk1ZW 93cQ== MIME-Version: 1.0 X-Received: by 10.60.37.74 with SMTP id w10mr62556383oej.30.1375187692776; Tue, 30 Jul 2013 05:34:52 -0700 (PDT) Received: by 10.76.153.2 with HTTP; Tue, 30 Jul 2013 05:34:52 -0700 (PDT) In-Reply-To: References: Date: Tue, 30 Jul 2013 21:34:52 +0900 Message-ID: Subject: Re: libgcrypt issue From: Taguchi To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 12:34:53 -0000 i tried to add option "USE_GCC=4.2", and compile successed. Thx. C. Taguchi From owner-freebsd-arm@FreeBSD.ORG Tue Jul 30 20:01:42 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 460C13B8; Tue, 30 Jul 2013 20:01:42 +0000 (UTC) (envelope-from weiss@uni-mainz.de) Received: from mailgate-01.zdv.uni-mainz.de (mailgate-01.zdv.Uni-Mainz.DE [IPv6:2001:4c80:40:62d:203:ffff:fe5d:b2f1]) by mx1.freebsd.org (Postfix) with ESMTP id 7B37C283E; Tue, 30 Jul 2013 20:01:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uni-mainz.de; i=@uni-mainz.de; q=dns/txt; s=ironport; t=1375214502; x=1406750502; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zvFDK3pSyale21eoQ+dOPzi6LXjHaCIabPj3Lf0U52o=; b=Vljj7m7k3mNamvDO0bKJrZMukn6jABKzakpbPdmInSDA5EWjv52sM0vz TMqWi8Y7oS5uacW5LpUbfX1hlKiNIGD29HmjcKgAcDzLCyFr9QUabwdC/ qOF8qSpfQYWvRaMbYBsI8KHzmsf9QneYisUCXQeTC2LGQ9ip2kZf+HWW+ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAFMb+FEKXgZQ/2dsb2JhbABbgwY1UL4ZgR8WdIIkAQEBBHkMBAIBBQMRBAEBAQodBzIUCQgCBA4FCIgIDLhXj00xBwaDEnEDiHKgOYMUPIFu X-IPAS-Result: AiEFAFMb+FEKXgZQ/2dsb2JhbABbgwY1UL4ZgR8WdIIkAQEBBHkMBAIBBQMRBAEBAQodBzIUCQgCBA4FCIgIDLhXj00xBwaDEnEDiHKgOYMUPIFu Received: from e14hub-01.zdv.uni-mainz.de ([10.94.6.80]) by mailgate-01.zdv.uni-mainz.de with ESMTP; 30 Jul 2013 22:01:39 +0200 Received: from E14MDB-02.zdv.Uni-Mainz.DE ([fe80::1b:21ff:fe65:4560]) by e14hub-01.zdv.Uni-Mainz.DE ([fe80::21d:d8ff:feb7:1c5f%10]) with mapi id 14.03.0146.000; Tue, 30 Jul 2013 22:01:38 +0200 From: =?iso-8859-1?B?V2Vp3ywgSvxyZ2Vu?= To: 'Ian Lepore' Subject: RE: Wandboard support? Thread-Topic: Wandboard support? Thread-Index: AQHOjNET9PGUM7pwt063n/XsPm3o55l9lvSQ Date: Tue, 30 Jul 2013 20:01:38 +0000 Message-ID: References: <1375153279.45247.61.camel@revolution.hippie.lan> In-Reply-To: <1375153279.45247.61.camel@revolution.hippie.lan> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.93.178.81] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'freebsd-arm@freebsd.org'" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 20:01:42 -0000 Hello Ian, I don't think the patches are ready for committing them. They contain some changes to common code for debugging purposes and some changes are probably not really necessary at all, but have not been undone. But because I think I will not have enough time to clean them up properly, I put them there for reference. The diff is against yesterday's FreeBSD current: http://www.staff.uni-mainz.de/weiss/freebsd.wandboard.20130730 /etc/src.conf is WITHOUT_CLANG_IS_CC=3D1 WITHOUT_ARM_EABI=3D1 that is I used gcc and old abi. Have not tested with other settings. As I started a while ago, ddb=20 backtrace did not work with CLANG at that time. I used a version of u-boot which initializes the USB host port on the wandboard. An explicit "usb start" command may be needed. To enable USB for u-boot the following additional config in=20 ./include/configs/wandboard.h may be needed: /* USB Configs */ #define CONFIG_CMD_USB #define CONFIG_CMD_FAT #define CONFIG_USB_EHCI #define CONFIG_USB_EHCI_MX6 #define CONFIG_USB_STORAGE #define CONFIG_MXC_USB_PORT 1 #define CONFIG_MXC_USB_PORTSC (PORT_PTS_UTMI | PORT_PTS_PTW) #define CONFIG_MXC_USB_FLAGS 0 A copy of the wandboard dual u-boot is under=20 http://www.staff.uni-mainz.de/weiss/u-boot.imx It defaults to loading a kernel over the builtin ethernet interface. A copy of the FreeBSD kernel is under http://www.staff.uni-mainz.de/weiss/uImage Root device is sd0 (no mbr, no disklabel). Regards=20 Juergen=20 Juergen Weiss |Universitaet Mainz, Zentrum fuer Datenverarbeitung, weiss@uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361, FAX: +49(6131)39-2= 6407 -----Original Message----- From: Ian Lepore [mailto:ian@FreeBSD.org]=20 Sent: Tuesday, July 30, 2013 5:01 AM To: Wei=DF, J=FCrgen Cc: 'freebsd-arm@freebsd.org' Subject: Re: Wandboard support? On Mon, 2013-07-29 at 22:07 +0000, Wei=DF, J=FCrgen wrote: > Hallo, >=20 > I have been playing with a Wandboard Dual for some time. > Serial and USB host ports work. Non SMP kernel boots single > user to memory disk and as of tonight multiuser to USB flash.=20 >=20 > Regards >=20 > Juergen >=20 > Juergen Weiss |Universitaet Mainz, Zentrum fuer Datenverarbeitung, > weiss@uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361, FAX: +49(6131)39= -26407 >=20 If you'd like to share patches for that I'd be happy to commit them. Once we have even a minimally bootable system, it becomes easier for others to contribute more functionality. I've been playing with my Wandboard Solo for a couple days, but I can't seem to get through ehci_init() without hanging right now. -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Jul 31 02:44:23 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3F571921; Wed, 31 Jul 2013 02:44:23 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0652E253B; Wed, 31 Jul 2013 02:44:22 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r6V2iLYH020880; Tue, 30 Jul 2013 22:44:21 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r6V2iLw8020872; Wed, 31 Jul 2013 02:44:21 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 31 Jul 2013 02:44:21 GMT Message-Id: <201307310244.r6V2iLw8020872@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 02:44:23 -0000 TB --- 2013-07-30 23:30:18 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-07-30 23:30:18 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-07-30 23:30:18 - starting HEAD tinderbox run for arm/arm TB --- 2013-07-30 23:30:18 - cleaning the object tree TB --- 2013-07-30 23:30:18 - /usr/local/bin/svn stat /src TB --- 2013-07-30 23:30:23 - At svn revision 253823 TB --- 2013-07-30 23:30:24 - building world TB --- 2013-07-30 23:30:24 - CROSS_BUILD_TESTING=YES TB --- 2013-07-30 23:30:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-30 23:30:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-30 23:30:24 - SRCCONF=/dev/null TB --- 2013-07-30 23:30:24 - TARGET=arm TB --- 2013-07-30 23:30:24 - TARGET_ARCH=arm TB --- 2013-07-30 23:30:24 - TZ=UTC TB --- 2013-07-30 23:30:24 - __MAKE_CONF=/dev/null TB --- 2013-07-30 23:30:24 - cd /src TB --- 2013-07-30 23:30:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Jul 30 23:30:33 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Jul 31 02:32:45 UTC 2013 TB --- 2013-07-31 02:32:45 - generating LINT kernel config TB --- 2013-07-31 02:32:45 - cd /src/sys/arm/conf TB --- 2013-07-31 02:32:45 - /usr/bin/make -B LINT TB --- 2013-07-31 02:32:45 - cd /src/sys/arm/conf TB --- 2013-07-31 02:32:45 - /usr/sbin/config -m LINT TB --- 2013-07-31 02:32:45 - building LINT kernel TB --- 2013-07-31 02:32:45 - CROSS_BUILD_TESTING=YES TB --- 2013-07-31 02:32:45 - MAKEOBJDIRPREFIX=/obj TB --- 2013-07-31 02:32:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-07-31 02:32:45 - SRCCONF=/dev/null TB --- 2013-07-31 02:32:45 - TARGET=arm TB --- 2013-07-31 02:32:45 - TARGET_ARCH=arm TB --- 2013-07-31 02:32:45 - TZ=UTC TB --- 2013-07-31 02:32:45 - __MAKE_CONF=/dev/null TB --- 2013-07-31 02:32:45 - cd /src TB --- 2013-07-31 02:32:45 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 31 02:32:45 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/kern/subr_taskqueue.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/kern/subr_trap.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/kern/subr_turnstile.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-builtin -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror /src/sys/kern/subr_uio.c /src/sys/kern/subr_uio.c:126:2: error: statement requires expression of scalar type ('void' invalid) if (vm_page_insert(kern_pg, uobject, upindex)) { ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated. *** Error code 1 Stop. bmake: stopped in /obj/arm.arm/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-07-31 02:44:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-07-31 02:44:21 - ERROR: failed to build LINT kernel TB --- 2013-07-31 02:44:21 - 9158.12 user 1654.54 system 11642.80 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Wed Jul 31 08:29:06 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 907956B for ; Wed, 31 Jul 2013 08:29:06 +0000 (UTC) (envelope-from ghw@7axu.com) Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 239DC214D for ; Wed, 31 Jul 2013 08:29:05 +0000 (UTC) Received: by mail-we0-f171.google.com with SMTP id q55so331403wes.2 for ; Wed, 31 Jul 2013 01:28:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=CvzjtvkqZyAc5cgn6ZqHgcdiB3Bi2xhpAPPvhJBbz7I=; b=HCRaXGPJ84VtDB9qeUbmTdwwcZgpC3Vhmb/XHZF6g1zawXWGfAi92eGiKcPgtJhdY1 HLV7phmBv8U5neg6E283Wt+WzRruuMlGQwyZGciiiJwZf9fPVVzUjggSOA0gxMe1Gyy5 C/PFVNvre+E5tx/2p16Qo/qx93F0huzM5IFkVvWpvA4iEB5ZH+YWsraSG/kenRzSPLkt UZnWuP08LdLz/ml8BRp0rVwFGFME0mJ9J+BS0qJ/3YCrTFWvCgZpB67BGrKDn89KM1v2 JugwG1yaApvyxEsvZHEOwxNADG27s7tA64xWq0M1uevbpqmHR83Pw9mDxPsmTTDUd6FH s09A== X-Received: by 10.194.20.163 with SMTP id o3mr7951350wje.53.1375259337809; Wed, 31 Jul 2013 01:28:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.93.34 with HTTP; Wed, 31 Jul 2013 01:28:17 -0700 (PDT) X-Originating-IP: [54.249.112.206] In-Reply-To: <1375151095.45247.54.camel@revolution.hippie.lan> References: <20130729211540.GZ26412@funkthat.com> <1375151095.45247.54.camel@revolution.hippie.lan> From: XiaoQI Ge Date: Wed, 31 Jul 2013 16:28:17 +0800 Message-ID: Subject: Re: My WLI-UC-GNM up crash To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkJduq6xDLkLzqlMYX0N6SHbdbRKUmfIV+oOMSvTd4mkdJCBTEz6obOgN+zkTa3BaHM78JT Cc: "freebsd-wireless@freebsd.org" , freebsd-arm , Hans Petter Selasky X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 08:29:06 -0000 Last night, I use the latest FreeBSD source (r253827) and crochet-freebsd compile img My WLI-UC-GNM will be disconnected after a period of operation run0: device timeout run0: at uhub0, port 1, addr 2 (disconnected) Another log prompted ti_mmchs0: Error: current cmd NULL, already done? My BB-Black broken? -- Regards. By: XiaoQI Ge; PGP:8B09D5F7 WWW: https://www.7axu.com/ 2013/7/30 Ian Lepore : > On Mon, 2013-07-29 at 14:15 -0700, John-Mark Gurney wrote: >> Hans Petter Selasky wrote this message on Mon, Jul 29, 2013 at 19:58 +02= 00: >> > The aligned will make sure that the structure gets padded properly to = the size specified. Only on ARM/MIPS etc, structures get automatically alig= ned according to the element in the structure requiring the greatest alignm= ent. I've test-compiled the USB WLAN drivers, and the aligned makes a diffe= rence. The problem is that the radiotap header skews some following element= s, so that they are no longer aligned. The radiotap header itself is packed= , and this is not a problem. >> >> Ouch, has anyone looked at the code that caused this? >> >> in ieee80211_radiotap.c, it looks like the original fault was in either >> set_channel, or set_xchannel, and both do (the equivalent of): >> struct { >> uint16_t freq; >> uint16_t flags; >> } *rc =3D p; >> >> rc->freq =3D htole16(c->ic_freq); >> rc->flags =3D htole16(c->ic_flags); >> > > If there's any chance the pointer isn't aligned in code like this, then > htole16() is the wrong function, it should be using le16enc() such as > > le16enc(&rc->freq, c->ic_freq); > le16enc(&rc->flags, c->ic_flags); > > With any luck, an x86 compiler can optimize the inline code for the > endian enc/dec functions to take advantage of the platform's ability to > do unaligned accesses. But that's a side issue to code correctness -- > portable code has to get these things right even when it's inefficient. > > -- Ian > >> And then there is complicated code that calculates offsets, etc, in >> radiotap_offset.. What we probably really need is to mark the above >> as __packed or equiv so that we don't assume that the passed in pointer >> is aligned... >> >> The whole management of this radiochan and radiotap_offset is pretty >> nasty... If marking the structures __packed works, it's probably >> because two bugs are offsetting, and magicly making things align >> again... >> >> > -----Original message----- >> > > From:Warner Losh > >> > > Sent: Monday 29th July 2013 17:04 >> > > To: Adrian Chadd > >> > > Cc: Hans Petter Selasky >; freebsd-arm >; freebsd-wireless@freebsd.org >> > > Subject: Re: My WLI-UC-GNM up crash >> > > >> > > Aren't structures already aligned to 4 bytes when placed inside othe= r structures (unless marked __packed)? >> > > >> > > Warner >> > > >> > > On Jul 28, 2013, at 11:50 AM, Adrian Chadd wrote: >> > > >> > > > As long as that results in the radiotap structures being 4 or 8 by= te >> > > > padded when it's embedded in the softc - then yes, indeed. >> > > > >> > > > Xiao, can you try? >> > > > >> > > > >> > > > -adrian >> > > > >> > > > On 28 July 2013 03:35, Hans Petter Selasky > wrote: >> > > >> Hi, >> > > >> >> > > >> Can you try the attached patch? >> > > >> >> > > >> --HPS >> > > > _______________________________________________ >> > > > 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 " >> > > >> > > >> > >> > _______________________________________________ >> > 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" >> > > > _______________________________________________ > 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" From owner-freebsd-arm@FreeBSD.ORG Wed Jul 31 13:41:24 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0C2D5262; Wed, 31 Jul 2013 13:41:24 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D4D7522B1; Wed, 31 Jul 2013 13:41:23 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1V4WeT-000JlP-IZ; Wed, 31 Jul 2013 13:41:17 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r6VDfCUP020048; Wed, 31 Jul 2013 07:41:12 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19sf/dPQ27yttnY07OIdUyK Subject: Re: My WLI-UC-GNM up crash From: Ian Lepore To: XiaoQI Ge In-Reply-To: References: <20130729211540.GZ26412@funkthat.com> <1375151095.45247.54.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Wed, 31 Jul 2013 07:41:11 -0600 Message-ID: <1375278071.45247.144.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm , "freebsd-wireless@freebsd.org" , Hans Petter Selasky X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 13:41:24 -0000 On Wed, 2013-07-31 at 16:28 +0800, XiaoQI Ge wrote: > Last night, I use the latest FreeBSD source (r253827) and > crochet-freebsd compile img > My WLI-UC-GNM will be disconnected after a period of operation > > run0: device timeout > run0: at uhub0, port 1, addr 2 (disconnected) > > Another log prompted > ti_mmchs0: Error: current cmd NULL, already done? > > My BB-Black broken? The ti_mmchs0 error is not new. My old BBW has done that for months. I'm not sure it's totally harmless, but it's not related to the run0 timeouts. -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Jul 31 18:03:23 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E149E597; Wed, 31 Jul 2013 18:03:23 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1EF10204D; Wed, 31 Jul 2013 18:03:22 +0000 (UTC) Received: by mail-wg0-f49.google.com with SMTP id y10so904002wgg.16 for ; Wed, 31 Jul 2013 11:03:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=yYBXG42RQYfpzSrl9PPjVM0Wine8nq6tRX4KVjSX1A4=; b=tyIxBipfRANqKz8i3ayQa6QX5ffqgcN/HAGhYAkrGzuXfVTjXc6GhGyRdkacbe1ERr UFp4Ef7ssgaP0dyE8L+58ExFZ0sm1AxwbNiMrJN3O8dBX8TCT2gsZSETn1EzQ436aKwb fb0ZoRcLqhuUEREJoHIOnwKon1bxQBf3Z1qwXwVrQTRsBosjJebIFXeNe+x2NjDY7lbt gXIZV/6PW5SpE2L9V63Dup0iUITBXBjXi6p0q7TnmdRLyDsQRPOLL/GKLtkyVJLzQ9BY KxEtElRESTtWSN9BBeE06mf25QJjYFUNrQizX1zEdF5hqWmRpeLtwl64+BD60/o63g9L kwbQ== MIME-Version: 1.0 X-Received: by 10.180.160.165 with SMTP id xl5mr5075937wib.46.1375293801214; Wed, 31 Jul 2013 11:03:21 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.94.132 with HTTP; Wed, 31 Jul 2013 11:03:21 -0700 (PDT) In-Reply-To: <1375278071.45247.144.camel@revolution.hippie.lan> References: <20130729211540.GZ26412@funkthat.com> <1375151095.45247.54.camel@revolution.hippie.lan> <1375278071.45247.144.camel@revolution.hippie.lan> Date: Wed, 31 Jul 2013 11:03:21 -0700 X-Google-Sender-Auth: dnxYblXgcInRIP13JuLr74Of5rw Message-ID: Subject: Re: My WLI-UC-GNM up crash From: Adrian Chadd To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arm , "freebsd-wireless@freebsd.org" , Hans Petter Selasky X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 18:03:24 -0000 No idea about the device disconnect, sorry. is it a power draw problem? -adrian On 31 July 2013 06:41, Ian Lepore wrote: > On Wed, 2013-07-31 at 16:28 +0800, XiaoQI Ge wrote: >> Last night, I use the latest FreeBSD source (r253827) and >> crochet-freebsd compile img >> My WLI-UC-GNM will be disconnected after a period of operation >> >> run0: device timeout >> run0: at uhub0, port 1, addr 2 (disconnected) >> >> Another log prompted >> ti_mmchs0: Error: current cmd NULL, already done? >> >> My BB-Black broken? > > The ti_mmchs0 error is not new. My old BBW has done that for months. > I'm not sure it's totally harmless, but it's not related to the run0 > timeouts. > > -- 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" From owner-freebsd-arm@FreeBSD.ORG Wed Jul 31 18:55:11 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 178CFB28 for ; Wed, 31 Jul 2013 18:55:11 +0000 (UTC) (envelope-from ziprandom@googlemail.com) Received: from mail-ea0-x229.google.com (mail-ea0-x229.google.com [IPv6:2a00:1450:4013:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5DF02229E for ; Wed, 31 Jul 2013 18:55:10 +0000 (UTC) Received: by mail-ea0-f169.google.com with SMTP id z7so542272eaf.0 for ; Wed, 31 Jul 2013 11:55:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=date:message-id:from:to:subject:user-agent:mime-version :content-type; bh=wGXIyp3tGaerT9UFObEi3xwXwTAqHTWGcG5FAO6waPY=; b=aYDO1S3uWeCzscXxmYahyWWpSSsYAIEFR6cM7eQNDFESKShY9+PXuVxQe6gpJdJuqb BAech5f5nDtdw4w25/yNH15oZAhnelY6D90x+6cz7D//gM7FEooLEWAmQClX5GN3WFJX 6CwSUm+/pRFsgA2X32ru2UFeImdyhyQe5tGNvJJgT/siUHcJmZB/q6ocelVbhSa8vlzL YbeBP7sXbDmumi9F1+C+aY7onocvXPgqeTZr7rtu7NTndQJbZF2dONUC5CsWwzEcxChn 5u+H7OEWKiz6aHVpmP85FKq1Ozpqk+OvqJdcvW2FQ5HQpT6YnGaTtFRl7K6C7uJfP1vm 3xXA== X-Received: by 10.14.106.195 with SMTP id m43mr70480844eeg.60.1375296908575; Wed, 31 Jul 2013 11:55:08 -0700 (PDT) Received: from runnerboat.googlemail.com (g224221018.adsl.alicedsl.de. [92.224.221.18]) by mx.google.com with ESMTPSA id cg12sm4597071eeb.7.2013.07.31.11.55.06 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 31 Jul 2013 11:55:07 -0700 (PDT) Date: Wed, 31 Jul 2013 20:51:54 +0200 Message-ID: <87txja8svp.wl%ziprandom@googlemail.com> From: Zip Random To: freebsd-arm@freebsd.org Subject: Building lang/gcc (4.6) on freebsd-arm User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/24.3.50 (i686-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 18:55:11 -0000 Hi All, I'm trying to build gcc from the ports tree on a sheevaplug running freebsd 9.1 and I get an error [1]: [...] /usr/local/bin/ld: /usr/ports/lang/gcc/work/build/./gcc/be/crti.o: compiled for a big endian system and target is little endian/usr/local/bin/ld: failed to merge target specific data of file /usr/ports/lang/gcc/work/build/./gcc/be/crti.o /usr/local/bin/ld: /usr/ports/lang/gcc/work/build/./gcc/be/crtbeginS.o: compiled for a big endian system and target is little endian [...] about endianness. How can I get around that ? and can someone tell me how far away is EABI support? thanks for any replies, zip [1] The complete Error: /usr/local/bin/ld: /usr/ports/lang/gcc/work/build/./gcc/be/crti.o: compiled for a big endian system and target is little endian/usr/local/bin/ld: failed to merge target specific data of file /usr/ports/lang/gcc/work/build/./gcc/be/crti.o /usr/local/bin/ld: /usr/ports/lang/gcc/work/build/./gcc/be/crtbeginS.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file /usr/ports/lang/gcc/work/build/./gcc/be/crtbeginS.o /usr/local/bin/ld: _thumb1_case_sqi_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _thumb1_case_sqi_s.o /usr/local/bin/ld: _thumb1_case_uqi_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _thumb1_case_uqi_s.o /usr/local/bin/ld: _thumb1_case_shi_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _thumb1_case_shi_s.o /usr/local/bin/ld: _thumb1_case_uhi_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _thumb1_case_uhi_s.o /usr/local/bin/ld: _thumb1_case_si_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _thumb1_case_si_s.o /usr/local/bin/ld: _udivsi3_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _udivsi3_s.o /usr/local/bin/ld: _divsi3_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _divsi3_s.o /usr/local/bin/ld: _umodsi3_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _umodsi3_s.o /usr/local/bin/ld: _modsi3_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _modsi3_s.o /usr/local/bin/ld: _dvmd_tls_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _dvmd_tls_s.o /usr/local/bin/ld: _bb_init_func_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _bb_init_func_s.o /usr/local/bin/ld: _clzsi2_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _clzsi2_s.o /usr/local/bin/ld: _clzdi2_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _clzdi2_s.o /usr/local/bin/ld: _muldi3_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _muldi3_s.o /usr/local/bin/ld: _negdi2_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _negdi2_s.o /usr/local/bin/ld: _lshrdi3_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _lshrdi3_s.o /usr/local/bin/ld: _ashldi3_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _ashldi3_s.o /usr/local/bin/ld: _ashrdi3_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _ashrdi3_s.o /usr/local/bin/ld: _cmpdi2_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _cmpdi2_s.o /usr/local/bin/ld: _ucmpdi2_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _ucmpdi2_s.o /usr/local/bin/ld: _clear_cache_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _clear_cache_s.o /usr/local/bin/ld: _enable_execute_stack_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _enable_execute_stack_s.o /usr/local/bin/ld: _trampoline_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _trampoline_s.o /usr/local/bin/ld: __main_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file __main_s.o /usr/local/bin/ld: _absvsi2_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _absvsi2_s.o /usr/local/bin/ld: _absvdi2_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _absvdi2_s.o /usr/local/bin/ld: _addvsi3_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _addvsi3_s.o /usr/local/bin/ld: _addvdi3_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _addvdi3_s.o /usr/local/bin/ld: _subvsi3_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _subvsi3_s.o /usr/local/bin/ld: _subvdi3_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _subvdi3_s.o /usr/local/bin/ld: _mulvsi3_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _mulvsi3_s.o /usr/local/bin/ld: _mulvdi3_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _mulvdi3_s.o /usr/local/bin/ld: _negvsi2_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _negvsi2_s.o /usr/local/bin/ld: _negvdi2_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _negvdi2_s.o /usr/local/bin/ld: _ctors_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _ctors_s.o /usr/local/bin/ld: _ffssi2_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _ffssi2_s.o /usr/local/bin/ld: _ffsdi2_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _ffsdi2_s.o /usr/local/bin/ld: _clz_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _clz_s.o /usr/local/bin/ld: _ctzsi2_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _ctzsi2_s.o /usr/local/bin/ld: _ctzdi2_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _ctzdi2_s.o /usr/local/bin/ld: _popcount_tab_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _popcount_tab_s.o /usr/local/bin/ld: _popcountsi2_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _popcountsi2_s.o /usr/local/bin/ld: _popcountdi2_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _popcountdi2_s.o /usr/local/bin/ld: _paritysi2_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _paritysi2_s.o /usr/local/bin/ld: _paritydi2_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _paritydi2_s.o /usr/local/bin/ld: _powisf2_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _powisf2_s.o /usr/local/bin/ld: _powidf2_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _powidf2_s.o /usr/local/bin/ld: _powixf2_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _powixf2_s.o /usr/local/bin/ld: _powitf2_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _powitf2_s.o /usr/local/bin/ld: _mulsc3_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _mulsc3_s.o /usr/local/bin/ld: _muldc3_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _muldc3_s.o /usr/local/bin/ld: _mulxc3_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _mulxc3_s.o /usr/local/bin/ld: _multc3_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _multc3_s.o /usr/local/bin/ld: _divsc3_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _divsc3_s.o /usr/local/bin/ld: _divdc3_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _divdc3_s.o /usr/local/bin/ld: _divxc3_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _divxc3_s.o /usr/local/bin/ld: _divtc3_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _divtc3_s.o /usr/local/bin/ld: _bswapsi2_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _bswapsi2_s.o /usr/local/bin/ld: _bswapdi2_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _bswapdi2_s.o /usr/local/bin/ld: _fixunssfsi_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _fixunssfsi_s.o /usr/local/bin/ld: _fixunsdfsi_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _fixunsdfsi_s.o /usr/local/bin/ld: _fixunsxfsi_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _fixunsxfsi_s.o /usr/local/bin/ld: _fixsfdi_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _fixsfdi_s.o /usr/local/bin/ld: _fixdfdi_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _fixdfdi_s.o /usr/local/bin/ld: _fixxfdi_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _fixxfdi_s.o /usr/local/bin/ld: _fixtfdi_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _fixtfdi_s.o /usr/local/bin/ld: _fixunssfdi_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _fixunssfdi_s.o /usr/local/bin/ld: _fixunsdfdi_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _fixunsdfdi_s.o /usr/local/bin/ld: _fixunsxfdi_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _fixunsxfdi_s.o /usr/local/bin/ld: _fixunstfdi_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _fixunstfdi_s.o /usr/local/bin/ld: _floatdisf_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _floatdisf_s.o /usr/local/bin/ld: _floatdidf_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _floatdidf_s.o /usr/local/bin/ld: _floatdixf_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _floatdixf_s.o /usr/local/bin/ld: _floatditf_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _floatditf_s.o /usr/local/bin/ld: _floatundisf_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _floatundisf_s.o /usr/local/bin/ld: _floatundidf_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _floatundidf_s.o /usr/local/bin/ld: _floatundixf_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _floatundixf_s.o /usr/local/bin/ld: _floatunditf_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _floatunditf_s.o /usr/local/bin/ld: _divdi3_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _divdi3_s.o /usr/local/bin/ld: _moddi3_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _moddi3_s.o /usr/local/bin/ld: _udivdi3_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _udivdi3_s.o /usr/local/bin/ld: _umoddi3_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _umoddi3_s.o /usr/local/bin/ld: _udiv_w_sdiv_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _udiv_w_sdiv_s.o /usr/local/bin/ld: _udivmoddi4_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _udivmoddi4_s.o /usr/local/bin/ld: _pack_sf_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _pack_sf_s.o /usr/local/bin/ld: _unpack_sf_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _unpack_sf_s.o /usr/local/bin/ld: _addsub_sf_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _addsub_sf_s.o /usr/local/bin/ld: _mul_sf_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _mul_sf_s.o /usr/local/bin/ld: _div_sf_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _div_sf_s.o /usr/local/bin/ld: _fpcmp_parts_sf_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _fpcmp_parts_sf_s.o /usr/local/bin/ld: _compare_sf_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _compare_sf_s.o /usr/local/bin/ld: _eq_sf_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _eq_sf_s.o /usr/local/bin/ld: _ne_sf_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _ne_sf_s.o /usr/local/bin/ld: _gt_sf_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _gt_sf_s.o /usr/local/bin/ld: _ge_sf_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _ge_sf_s.o /usr/local/bin/ld: _lt_sf_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _lt_sf_s.o /usr/local/bin/ld: _le_sf_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _le_sf_s.o /usr/local/bin/ld: _unord_sf_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _unord_sf_s.o /usr/local/bin/ld: _si_to_sf_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _si_to_sf_s.o /usr/local/bin/ld: _sf_to_si_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _sf_to_si_s.o /usr/local/bin/ld: _negate_sf_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _negate_sf_s.o /usr/local/bin/ld: _make_sf_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _make_sf_s.o /usr/local/bin/ld: _sf_to_df_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _sf_to_df_s.o /usr/local/bin/ld: _thenan_sf_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _thenan_sf_s.o /usr/local/bin/ld: _sf_to_usi_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _sf_to_usi_s.o /usr/local/bin/ld: _usi_to_sf_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _usi_to_sf_s.o /usr/local/bin/ld: _pack_df_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _pack_df_s.o /usr/local/bin/ld: _unpack_df_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _unpack_df_s.o /usr/local/bin/ld: _addsub_df_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _addsub_df_s.o /usr/local/bin/ld: _mul_df_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _mul_df_s.o /usr/local/bin/ld: _div_df_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _div_df_s.o /usr/local/bin/ld: _fpcmp_parts_df_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _fpcmp_parts_df_s.o /usr/local/bin/ld: _compare_df_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _compare_df_s.o /usr/local/bin/ld: _eq_df_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _eq_df_s.o /usr/local/bin/ld: _ne_df_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _ne_df_s.o /usr/local/bin/ld: _gt_df_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _gt_df_s.o /usr/local/bin/ld: _ge_df_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _ge_df_s.o /usr/local/bin/ld: _lt_df_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _lt_df_s.o /usr/local/bin/ld: _le_df_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _le_df_s.o /usr/local/bin/ld: _unord_df_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _unord_df_s.o /usr/local/bin/ld: _si_to_df_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _si_to_df_s.o /usr/local/bin/ld: _df_to_si_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _df_to_si_s.o /usr/local/bin/ld: _negate_df_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _negate_df_s.o /usr/local/bin/ld: _make_df_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _make_df_s.o /usr/local/bin/ld: _df_to_sf_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _df_to_sf_s.o /usr/local/bin/ld: _thenan_df_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _thenan_df_s.o /usr/local/bin/ld: _df_to_usi_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _df_to_usi_s.o /usr/local/bin/ld: _usi_to_df_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file _usi_to_df_s.o /usr/local/bin/ld: unwind-dw2_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file unwind-dw2_s.o /usr/local/bin/ld: unwind-dw2-fde-glibc_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file unwind-dw2-fde-glibc_s.o /usr/local/bin/ld: unwind-sjlj_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file unwind-sjlj_s.o /usr/local/bin/ld: gthr-gnat_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file gthr-gnat_s.o /usr/local/bin/ld: unwind-c_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file unwind-c_s.o /usr/local/bin/ld: emutls_s.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file emutls_s.o /usr/local/bin/ld: /usr/ports/lang/gcc/work/build/./gcc/be/crtendS.o: compiled for a big endian system and target is little endian /usr/local/bin/ld: failed to merge target specific data of file /usr/ports/lang/gcc/work/build/./gcc/be/crtendS.o /usr/local/bin/ld: /usr/ports/lang/gcc/work/build/./gcc/be/crtn.o: compiled for a big endian system and target is little endian/usr/local/bin/ld: failed to merge target specific data of file /usr/ports/lang/gcc/work/build/./gcc/be/crtn.o /usr/local/bin/ld: /usr/ports/lang/gcc/work/build/./gcc/be/crtbeginS.o(.text+0x40): unresolvable R_ARM_PLT32 relocation against symbol `__cxa_finalize@@FBSD_1.0' /usr/local/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status gmake[4]: *** [libgcc_s.so] Error 1 gmake[4]: Leaving directory `/usr/ports/lang/gcc/work/build/arm-portbld-freebsd9.1/be/libgcc' gmake[3]: *** [multi-do] Error 1 gmake[3]: Leaving directory `/usr/ports/lang/gcc/work/build/arm-portbld-freebsd9.1/libgcc' gmake[2]: *** [all-multi] Error 2 gmake[2]: Leaving directory `/usr/ports/lang/gcc/work/build/arm-portbld-freebsd9.1/libgcc' gmake[1]: *** [all-target-libgcc] Error 2 gmake[1]: Leaving directory `/usr/ports/lang/gcc/work/build' gmake: *** [all] Error 2 *** [do-build] Error code 1 Stop in /usr/ports/lang/gcc. *** [build] Error code 1 Stop in /usr/ports/lang/gcc. ===>>> make failed for lang/gcc ===>>> Aborting update ===>>> Update for lang/gcc failed ===>>> Aborting update ===>>> Update for archivers/hs-zlib failed ===>>> Aborting update ===>>> Killing background jobs Terminated From owner-freebsd-arm@FreeBSD.ORG Wed Jul 31 19:38:39 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F29B98D9 for ; Wed, 31 Jul 2013 19:38:39 +0000 (UTC) (envelope-from mattia.rossi.mate@gmail.com) Received: from mail-bk0-x22d.google.com (mail-bk0-x22d.google.com [IPv6:2a00:1450:4008:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 682AD2461 for ; Wed, 31 Jul 2013 19:38:39 +0000 (UTC) Received: by mail-bk0-f45.google.com with SMTP id je2so388634bkc.18 for ; Wed, 31 Jul 2013 12:38:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=ZbsONdxtDCcU0Bc9XRDqllu7uScCGgbnmMoCP7V1C5g=; b=ulHtxC7bS/wGnfwjqE1RMJNrXOR86M2CI2Z2WT0zyM0NzAYrLakx7oWgWtZ0JqyS85 FGlCXKBgst0r/gDUJJGt+MKXjeyYwA0EMUHvGfVboJJyjYnymBcP6qy9KWj4/J9hk1ou yN5OP/Q3diD2hES/MYZ01V7lpb6HeFVAUFMUhO3Y6Bmlob9evJsoc1Jh+/0PixCi8LT3 eFeM9AAnXBUmbZq++3l9JfPlz1BxonHeDUpfwuoNQFeVwgeVwmnAofEhE0CMR93SI09k wNPWYyT7+QnSRQ9rPCo5Zd6NvMCuTsFS9AXJquz3ffOs7PHjuMtSFDyihds8GOjH146s Mp4w== X-Received: by 10.204.60.202 with SMTP id q10mr9961765bkh.85.1375299516414; Wed, 31 Jul 2013 12:38:36 -0700 (PDT) Received: from [10.185.11.70] ([46.189.28.44]) by mx.google.com with ESMTPSA id jh13sm880070bkb.13.2013.07.31.12.38.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 31 Jul 2013 12:38:35 -0700 (PDT) Message-ID: <51F92F79.9010809@gmail.com> Date: Wed, 31 Jul 2013 17:38:33 +0200 From: Mattia Rossi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Kernel Panic on DREAMPLUG: Alignment Fault 1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 19:38:40 -0000 Hi all, this might be related to the WLI-UC-GNM Alignment Fault, but definitely has nothing to do with Wireless LAN. It rather seems that there's a problem with the USB subsystem. See dmesg an backtrace below. ## Starting application at 0x00900000 ... 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 #9 r253846M: Wed Jul 31 17:24:31 CEST 2013 root@freebsd9.1-base:/usr/obj/arm.arm/usr/devel/dreamplug/sys/DREAMPLUG-100m FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 WARNING: DIAGNOSTIC option enabled, expect reduced performance. CPU: Feroceon 88FR131 rev 1 (Marvell core) Little-endian DC enabled IC enabled WA disabled DC streaming enabled BTB disabled L2 enabled L2 prefetch enabled WB enabled EABT branch prediction enabled 16KB/32B 4-way instruction cache 16KB/32B 4-way write-back-locking-C data cache real memory = 536870912 (512 MB) avail memory = 510828544 (487 MB) SOC: Marvell 88F6281 rev A1, TClock 200MHz Instruction cache prefetch disabled, data cache prefetch disabled 256KB 4-way set-associative write-through unified L2 cache random device not loaded; using insecure entropy localbus0: on fdtbus0 simplebus0: on fdtbus0 ic0: mem 0xf1020200-0xf102023b on sim0 timer0: mem 0xf1020300-0xf102032f irq 1 on simplebus0 Event timer "CPUTimer0" frequency 200000000 Hz quality 1000 Timecounter "CPUTimer1" frequency 200000000 Hz quality 1000 gpio0: mem 0xf1010100-0xf101011f irq 35,360 rtc0: mem 0xf1010300-0xf1010307 on simplebus0 twsi0: mem 0xf1011000-0xf101101f irq 430 iicbus0: on twsi0 iic0: on iicbus0 mge0: mem 0xf1072000-0xf1073fff irq 12,130 mge0: Ethernet address: f0:ad:4e:00:84:c7 miibus0: on mge0 e1000phy0: PHY 0 on miibus0 e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 10o mge1: mem 0xf1076000-0xf1077fff irq 16,170 mge1: Ethernet address: f0:ad:4e:00:84:c8 miibus1: on mge1 e1000phy1: PHY 1 on miibus1 e1000phy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 10o uart0: <16550 or compatible> mem 0xf1012000-0xf101201f irq 33 on simplebus0 uart0: console (1056,n,8,1) uart1: <16550 or compatible> mem 0xf1012100-0xf101211f irq 34 on simplebus0 cesa0: mem 0xf1030000-00 ehci0: mem 0xf1050000-0xf1050fff irq 480 usbus0: EHCI version 1.0 usbus0: set host controller mode usbus0 on ehci0 mvs0: mem 0xf1080000-0xf1085fff irq 21 on sim0 mvs0: Gen-IIe, 2 3Gbps ports, Port Multiplier supported with FBS mvsch0: at channel 0 on mvs0 mvsch1: at channel 1 on mvs0 cryptosoft0: Timecounters tick every 10.000 msec IPsec: Initialized Security Association Processing. ipfw2 (+ipv6) initialized, divert enabled, nat enabled, default to accept, loggd DUMMYNET 0 with IPv6 initialized (100409) load_dn_sched dn_sched FIFO loaded load_dn_sched dn_sched PRIO loaded load_dn_sched dn_sched QFQ loaded load_dn_sched dn_sched RR loaded load_dn_sched dn_sched WF2Q+ loaded usbus0: 480Mbps High Speed USB v2.0 Fatal kernel mode data abort: 'Alignment Fault 1' trapframe: 0xde472b48 FSR=00000001, FAR=de472bc4, spsr=60000093 r0 =001e48e5, r1 =ffffffff, r2 =0000001c, r3 =001e48e5 r4 =de472bbc, r5 =de472bc4, r6 =c3598c80, r7 =c0e7c830 r8 =798ee230, r9 =00000015, r10=00000001, r11=de472bb4 r12=c0d240e8, ssp=de472b94, slr=c0d44c6c, pc =c0ab8264 [ thread pid 5 tid 100036 ] Stopped at binuptime+0x70: und 0xe1c500d0 db> bt Tracing pid 5 tid 100036 td 0xc3598c80 db_trace_self() at db_trace_self pc = 0xc0d2807c lr = 0xc0941d84 (db_hex2dec+0x4d8) sp = 0xde472840 fp = 0xde472858 r10 = 0xc0e59e60 db_hex2dec() at db_hex2dec+0x4d8 pc = 0xc0941d84 lr = 0xc09416f4 (db_command_loop+0x2f4) sp = 0xde472860 fp = 0xde472900 r4 = 0x00000000 r5 = 0x00000000 r6 = 0xc0d9e9fc db_command_loop() at db_command_loop+0x2f4 pc = 0xc09416f4 lr = 0xc0941450 (db_command_loop+0x50) sp = 0xde472908 fp = 0xde472918 r4 = 0xc0d7bae3 r5 = 0xc0d98378 r6 = 0xc0ebbdb8 r7 = 0xde472b48 r8 = 0xde472b48 r9 = 0xc0eb0614 r10 = 0xc0e5a0d0 db_command_loop() at db_command_loop+0x50 pc = 0xc0941450 lr = 0xc0943e68 (X_db_symbol_values+0x254) sp = 0xde472920 fp = 0xde472a40 r4 = 0x00000000 r5 = 0xde472928 r6 = 0xc0eb0638 X_db_symbol_values() at X_db_symbol_values+0x254 pc = 0xc0943e68 lr = 0xc0adf580 (kdb_trap+0xd4) sp = 0xde472a48 fp = 0xde472a68 r4 = 0x00000000 r5 = 0x00000001 r6 = 0xc0eb0638 r7 = 0xde472b48 kdb_trap() at kdb_trap+0xd4 pc = 0xc0adf580 lr = 0xc0d38810 (data_abort_handler+0x640) sp = 0xde472a70 fp = 0xde472a88 r4 = 0xde472b48 r5 = 0x600000d3 r6 = 0xde472bc4 r7 = 0x00000001 r8 = 0xde472b48 r9 = 0xde472bc4 r10 = 0x00000001 data_abort_handler() at data_abort_handler+0x640 pc = 0xc0d38810 lr = 0xc0d39208 (swi_handler+0x548) sp = 0xde472a90 fp = 0xde472a98 r4 = 0x00000001 r5 = 0xc3598c80 r6 = 0xc3598c80 r7 = 0xc0d39194 swi_handler() at swi_handler+0x548 pc = 0xc0d39208 lr = 0xc0d3854c (data_abort_handler+0x37c) sp = 0xde472aa0 fp = 0xde472b40 data_abort_handler() at data_abort_handler+0x37c pc = 0xc0d3854c lr = 0xc0d29924 (exception_exit) sp = 0xde472b48 fp = 0xde472bb4 r4 = 0xffffffff r5 = 0xffff1004 r6 = 0xc3598c80 r7 = 0xc0e7c830 r8 = 0x798ee230 r9 = 0x00000015 r10 = 0x00000001 exception_exit() at exception_exit pc = 0xc0d29924 lr = 0xc0d44c6c (DELAY+0x764) sp = 0xde472b94 fp = 0xde472bb4 r0 = 0x001e48e5 r1 = 0xffffffff r2 = 0x0000001c r3 = 0x001e48e5 r4 = 0xde472bbc r5 = 0xde472bc4 r6 = 0xc3598c80 r7 = 0xc0e7c830 r8 = 0x798ee230 r9 = 0x00000015 r10 = 0x00000001 r12 = 0xc0d240e8 binuptime() at binuptime+0x74 pc = 0xc0ab8268 lr = 0xc0d503ec (cpu_initclocks_bsp+0x41c) sp = 0xde472bbc fp = 0xde472bd4 r4 = 0x00000003 r5 = 0x00033940 r6 = 0xc3598c80 r7 = 0xc0d92761 r8 = 0xc0d9273a r9 = 0x00000000 r10 = 0xc3586ac0 cpu_initclocks_bsp() at cpu_initclocks_bsp+0x41c pc = 0xc0d503ec lr = 0xc0d44af8 (DELAY+0x5f0) sp = 0xde472bdc fp = 0xde472be4 r4 = 0xc352d400 r5 = 0xde472c34 DELAY() at DELAY+0x5f0 pc = 0xc0d44af8 lr = 0xc0a82468 (intr_event_handle+0x88) sp = 0xde472bec fp = 0xde472c14 r4 = 0xc341e400 intr_event_handle() at intr_event_handle+0x88 pc = 0xc0a82468 lr = 0xc0d2acac (arm_handler_execute+0x54) sp = 0xde472c1c fp = 0xde472c2c r4 = 0xde472c34 r5 = 0x00000001 r6 = 0xc0e97c40 r7 = 0xc0eb90d8 r8 = 0xc352c200 r9 = 0xc37a1000 r10 = 0xc37a1000 arm_handler_execute() at arm_handler_execute+0x54 pc = 0xc0d2acac lr = 0xc0d3e2dc (irq_entry+0x94) sp = 0xde472c34 fp = 0xde472c90 r4 = 0x00000000 r5 = 0xffff1004 r6 = 0xc0ebbc50 r7 = 0x00004c5f irq_entry() at irq_entry+0x94 pc = 0xc0d3e2dc lr = 0xc0d3e2dc (irq_entry+0x94) sp = 0xde472c34 fp = 0xde472c90 Unwind failure (no registers changed) db> Usually this is the USB bit that follows the usbus0 line: ugen0.1: at usbus0 uhub0: on usbus0 WARNING: DIAGNOSTIC option enabled, expect reduced performance. uhub0: 1 port with 1 removable, self powered Root mount waiting for: usbus0 ugen0.2: at usbus0 uhub1: on usbus0 Root mount waiting for: usbus0 uhub1: 4 ports with 4 removable, self powered Root mount waiting for: usbus0 Root mount waiting for: usbus0 ugen0.3: at usbus0 umass0: on usbus0 da0 at umass-sim0 bus 0 scbus2 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 1876MB (3842048 512 byte sectors: 255H 63S/T 239C) da0: quirks=0x3 da1 at umass-sim0 bus 0 scbus2 target 0 lun 1 da1: Removable Direct Access SCSI-0 device da1: 40.000MB/s transfers da1: 974MB (1995264 512 byte sectors: 64H 32S/T 974C) da1: quirks=0x3 Root mount waiting for: usbus0 ugen0.4: at usbus0 umass1: Removable Direct Access SCSI-2 device da2: 40.000MB/s transfers da2: 1967MB (4030463 512 byte sectors: 255H 63S/T 250C) da2: quirks=0x2 ugen0.5: at usbus0 Currently trying to find where the issue could be. Mat From owner-freebsd-arm@FreeBSD.ORG Wed Jul 31 19:41:23 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E2303957 for ; Wed, 31 Jul 2013 19:41:23 +0000 (UTC) (envelope-from mattia.rossi.mate@gmail.com) Received: from mail-bk0-x229.google.com (mail-bk0-x229.google.com [IPv6:2a00:1450:4008:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 58D3C2484 for ; Wed, 31 Jul 2013 19:41:23 +0000 (UTC) Received: by mail-bk0-f41.google.com with SMTP id jc10so401320bkc.28 for ; Wed, 31 Jul 2013 12:41:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=1OpRba86FXLa0mmufLL9nJbOgiFInJ5aCtenCfqzNVk=; b=h05K3Gs1orKN8qDU3rYzMOnw8gv9CWoqMWP0dqRyByTtWIQWJ6EkiYg1YrPBZye9b1 YTUg+zyEH/TIGWeu9iNDsjG6VBTmU3Q0v0HPavDNcqB6EnEpfXUayLzKlo3VddB7J9lQ OEf6un+tZg80urC9h799JBz1mFI/7hUmMqP7kJhDnVSVwuHDXxrPE+LTJWrjtisW1jq+ 0K5UyULT5dLA88j2D2KTG75gUW+6UTCIed/ACtWPTEL+FRe+8P/A/858ZXai0YNxjopr TUpFBrL0aAnedn1aAbpPm35QM+kq/koV0XX6Xh7OQxGmjZs1vqymndg2PlaTwXWX8LvZ JhtA== X-Received: by 10.205.4.197 with SMTP id od5mr9967615bkb.1.1375299681357; Wed, 31 Jul 2013 12:41:21 -0700 (PDT) Received: from [10.185.11.70] ([46.189.28.44]) by mx.google.com with ESMTPSA id px7sm878896bkb.9.2013.07.31.12.41.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 31 Jul 2013 12:41:20 -0700 (PDT) Message-ID: <51F9301E.3040506@gmail.com> Date: Wed, 31 Jul 2013 17:41:18 +0200 From: Mattia Rossi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: arm@freebsd.org Subject: Kernel Panic on DREAMPLUG: Alignment Fault 1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 19:41:23 -0000 Hi all, this might be related to the WLI-UC-GNM Alignment Fault, but definitely has nothing to do with Wireless LAN. It rather seems that there's a problem with the USB subsystem. See dmesg an backtrace below. ## Starting application at 0x00900000 ... 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 #9 r253846M: Wed Jul 31 17:24:31 CEST 2013 root@freebsd9.1-base:/usr/obj/arm.arm/usr/devel/dreamplug/sys/DREAMPLUG-100m FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 WARNING: DIAGNOSTIC option enabled, expect reduced performance. CPU: Feroceon 88FR131 rev 1 (Marvell core) Little-endian DC enabled IC enabled WA disabled DC streaming enabled BTB disabled L2 enabled L2 prefetch enabled WB enabled EABT branch prediction enabled 16KB/32B 4-way instruction cache 16KB/32B 4-way write-back-locking-C data cache real memory = 536870912 (512 MB) avail memory = 510828544 (487 MB) SOC: Marvell 88F6281 rev A1, TClock 200MHz Instruction cache prefetch disabled, data cache prefetch disabled 256KB 4-way set-associative write-through unified L2 cache random device not loaded; using insecure entropy localbus0: on fdtbus0 simplebus0: on fdtbus0 ic0: mem 0xf1020200-0xf102023b on sim0 timer0: mem 0xf1020300-0xf102032f irq 1 on simplebus0 Event timer "CPUTimer0" frequency 200000000 Hz quality 1000 Timecounter "CPUTimer1" frequency 200000000 Hz quality 1000 gpio0: mem 0xf1010100-0xf101011f irq 35,360 rtc0: mem 0xf1010300-0xf1010307 on simplebus0 twsi0: mem 0xf1011000-0xf101101f irq 430 iicbus0: on twsi0 iic0: on iicbus0 mge0: mem 0xf1072000-0xf1073fff irq 12,130 mge0: Ethernet address: f0:ad:4e:00:84:c7 miibus0: on mge0 e1000phy0: PHY 0 on miibus0 e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 10o mge1: mem 0xf1076000-0xf1077fff irq 16,170 mge1: Ethernet address: f0:ad:4e:00:84:c8 miibus1: on mge1 e1000phy1: PHY 1 on miibus1 e1000phy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 10o uart0: <16550 or compatible> mem 0xf1012000-0xf101201f irq 33 on simplebus0 uart0: console (1056,n,8,1) uart1: <16550 or compatible> mem 0xf1012100-0xf101211f irq 34 on simplebus0 cesa0: mem 0xf1030000-00 ehci0: mem 0xf1050000-0xf1050fff irq 480 usbus0: EHCI version 1.0 usbus0: set host controller mode usbus0 on ehci0 mvs0: mem 0xf1080000-0xf1085fff irq 21 on sim0 mvs0: Gen-IIe, 2 3Gbps ports, Port Multiplier supported with FBS mvsch0: at channel 0 on mvs0 mvsch1: at channel 1 on mvs0 cryptosoft0: Timecounters tick every 10.000 msec IPsec: Initialized Security Association Processing. ipfw2 (+ipv6) initialized, divert enabled, nat enabled, default to accept, loggd DUMMYNET 0 with IPv6 initialized (100409) load_dn_sched dn_sched FIFO loaded load_dn_sched dn_sched PRIO loaded load_dn_sched dn_sched QFQ loaded load_dn_sched dn_sched RR loaded load_dn_sched dn_sched WF2Q+ loaded usbus0: 480Mbps High Speed USB v2.0 Fatal kernel mode data abort: 'Alignment Fault 1' trapframe: 0xde472b48 FSR=00000001, FAR=de472bc4, spsr=60000093 r0 =001e48e5, r1 =ffffffff, r2 =0000001c, r3 =001e48e5 r4 =de472bbc, r5 =de472bc4, r6 =c3598c80, r7 =c0e7c830 r8 =798ee230, r9 =00000015, r10=00000001, r11=de472bb4 r12=c0d240e8, ssp=de472b94, slr=c0d44c6c, pc =c0ab8264 [ thread pid 5 tid 100036 ] Stopped at binuptime+0x70: und 0xe1c500d0 db> bt Tracing pid 5 tid 100036 td 0xc3598c80 db_trace_self() at db_trace_self pc = 0xc0d2807c lr = 0xc0941d84 (db_hex2dec+0x4d8) sp = 0xde472840 fp = 0xde472858 r10 = 0xc0e59e60 db_hex2dec() at db_hex2dec+0x4d8 pc = 0xc0941d84 lr = 0xc09416f4 (db_command_loop+0x2f4) sp = 0xde472860 fp = 0xde472900 r4 = 0x00000000 r5 = 0x00000000 r6 = 0xc0d9e9fc db_command_loop() at db_command_loop+0x2f4 pc = 0xc09416f4 lr = 0xc0941450 (db_command_loop+0x50) sp = 0xde472908 fp = 0xde472918 r4 = 0xc0d7bae3 r5 = 0xc0d98378 r6 = 0xc0ebbdb8 r7 = 0xde472b48 r8 = 0xde472b48 r9 = 0xc0eb0614 r10 = 0xc0e5a0d0 db_command_loop() at db_command_loop+0x50 pc = 0xc0941450 lr = 0xc0943e68 (X_db_symbol_values+0x254) sp = 0xde472920 fp = 0xde472a40 r4 = 0x00000000 r5 = 0xde472928 r6 = 0xc0eb0638 X_db_symbol_values() at X_db_symbol_values+0x254 pc = 0xc0943e68 lr = 0xc0adf580 (kdb_trap+0xd4) sp = 0xde472a48 fp = 0xde472a68 r4 = 0x00000000 r5 = 0x00000001 r6 = 0xc0eb0638 r7 = 0xde472b48 kdb_trap() at kdb_trap+0xd4 pc = 0xc0adf580 lr = 0xc0d38810 (data_abort_handler+0x640) sp = 0xde472a70 fp = 0xde472a88 r4 = 0xde472b48 r5 = 0x600000d3 r6 = 0xde472bc4 r7 = 0x00000001 r8 = 0xde472b48 r9 = 0xde472bc4 r10 = 0x00000001 data_abort_handler() at data_abort_handler+0x640 pc = 0xc0d38810 lr = 0xc0d39208 (swi_handler+0x548) sp = 0xde472a90 fp = 0xde472a98 r4 = 0x00000001 r5 = 0xc3598c80 r6 = 0xc3598c80 r7 = 0xc0d39194 swi_handler() at swi_handler+0x548 pc = 0xc0d39208 lr = 0xc0d3854c (data_abort_handler+0x37c) sp = 0xde472aa0 fp = 0xde472b40 data_abort_handler() at data_abort_handler+0x37c pc = 0xc0d3854c lr = 0xc0d29924 (exception_exit) sp = 0xde472b48 fp = 0xde472bb4 r4 = 0xffffffff r5 = 0xffff1004 r6 = 0xc3598c80 r7 = 0xc0e7c830 r8 = 0x798ee230 r9 = 0x00000015 r10 = 0x00000001 exception_exit() at exception_exit pc = 0xc0d29924 lr = 0xc0d44c6c (DELAY+0x764) sp = 0xde472b94 fp = 0xde472bb4 r0 = 0x001e48e5 r1 = 0xffffffff r2 = 0x0000001c r3 = 0x001e48e5 r4 = 0xde472bbc r5 = 0xde472bc4 r6 = 0xc3598c80 r7 = 0xc0e7c830 r8 = 0x798ee230 r9 = 0x00000015 r10 = 0x00000001 r12 = 0xc0d240e8 binuptime() at binuptime+0x74 pc = 0xc0ab8268 lr = 0xc0d503ec (cpu_initclocks_bsp+0x41c) sp = 0xde472bbc fp = 0xde472bd4 r4 = 0x00000003 r5 = 0x00033940 r6 = 0xc3598c80 r7 = 0xc0d92761 r8 = 0xc0d9273a r9 = 0x00000000 r10 = 0xc3586ac0 cpu_initclocks_bsp() at cpu_initclocks_bsp+0x41c pc = 0xc0d503ec lr = 0xc0d44af8 (DELAY+0x5f0) sp = 0xde472bdc fp = 0xde472be4 r4 = 0xc352d400 r5 = 0xde472c34 DELAY() at DELAY+0x5f0 pc = 0xc0d44af8 lr = 0xc0a82468 (intr_event_handle+0x88) sp = 0xde472bec fp = 0xde472c14 r4 = 0xc341e400 intr_event_handle() at intr_event_handle+0x88 pc = 0xc0a82468 lr = 0xc0d2acac (arm_handler_execute+0x54) sp = 0xde472c1c fp = 0xde472c2c r4 = 0xde472c34 r5 = 0x00000001 r6 = 0xc0e97c40 r7 = 0xc0eb90d8 r8 = 0xc352c200 r9 = 0xc37a1000 r10 = 0xc37a1000 arm_handler_execute() at arm_handler_execute+0x54 pc = 0xc0d2acac lr = 0xc0d3e2dc (irq_entry+0x94) sp = 0xde472c34 fp = 0xde472c90 r4 = 0x00000000 r5 = 0xffff1004 r6 = 0xc0ebbc50 r7 = 0x00004c5f irq_entry() at irq_entry+0x94 pc = 0xc0d3e2dc lr = 0xc0d3e2dc (irq_entry+0x94) sp = 0xde472c34 fp = 0xde472c90 Unwind failure (no registers changed) db> Usually this is the USB bit that follows the usbus0 line: ugen0.1: at usbus0 uhub0: on usbus0 WARNING: DIAGNOSTIC option enabled, expect reduced performance. uhub0: 1 port with 1 removable, self powered Root mount waiting for: usbus0 ugen0.2: at usbus0 uhub1: on usbus0 Root mount waiting for: usbus0 uhub1: 4 ports with 4 removable, self powered Root mount waiting for: usbus0 Root mount waiting for: usbus0 ugen0.3: at usbus0 umass0: on usbus0 da0 at umass-sim0 bus 0 scbus2 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 1876MB (3842048 512 byte sectors: 255H 63S/T 239C) da0: quirks=0x3 da1 at umass-sim0 bus 0 scbus2 target 0 lun 1 da1: Removable Direct Access SCSI-0 device da1: 40.000MB/s transfers da1: 974MB (1995264 512 byte sectors: 64H 32S/T 974C) da1: quirks=0x3 Root mount waiting for: usbus0 ugen0.4: at usbus0 umass1: Removable Direct Access SCSI-2 device da2: 40.000MB/s transfers da2: 1967MB (4030463 512 byte sectors: 255H 63S/T 250C) da2: quirks=0x2 ugen0.5: at usbus0 Currently trying to find where the issue could be. Mat From owner-freebsd-arm@FreeBSD.ORG Wed Jul 31 19:46:08 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 94CD29E1; Wed, 31 Jul 2013 19:46:08 +0000 (UTC) (envelope-from hans.petter.selasky@bitfrost.no) Received: from mta.bitpro.no (mta.bitpro.no [92.42.64.202]) by mx1.freebsd.org (Postfix) with ESMTP id 16CE024AA; Wed, 31 Jul 2013 19:46:07 +0000 (UTC) Received: from mail.lockless.no (mail.lockless.no [46.29.221.38]) by mta.bitpro.no (Postfix) with ESMTP id 3B7477A13E; Wed, 31 Jul 2013 21:46:07 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id 0129C8F0EC1; Wed, 31 Jul 2013 21:46:13 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at lockless.no Received: from mail.lockless.no ([127.0.0.1]) by localhost (mail.lockless.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VuCmYRxCY3fA; Wed, 31 Jul 2013 21:46:12 +0200 (CEST) Received: from mail.lockless.no (localhost [127.0.0.1]) by mail.lockless.no (Postfix) with ESMTP id 0DCD88F0EC0; Wed, 31 Jul 2013 21:46:12 +0200 (CEST) Subject: RE: My WLI-UC-GNM up crash From: =?utf-8?Q?Hans_Petter_Selasky?= To: =?utf-8?Q?Adrian_Chadd?= , =?utf-8?Q?Ian_Lepore?= Date: Wed, 31 Jul 2013 21:46:11 +0200 Mime-Version: 1.0 In-Reply-To: References: X-Priority: 3 (Normal) X-Mailer: Zarafa 7.1.4-41394 Message-Id: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: =?utf-8?Q?freebsd-arm?= , =?utf-8?Q?freebsd-wireless=40freebsd=2Eorg?= X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 19:46:08 -0000 Hi,=0D=0A=0D=0ATypically this means the USB firmware died, or some comman= d needs to be re-transmitted.=0D=0A=0D=0ASee:=0D=0A=0D=0Ausbdump -i usbus= X -s 65536=0D=0A=0D=0AWhat is really going on.=0D=0A=0D=0A--HPS=0D=0A=20=0D= =0A=20=0D=0A-----Original message-----=0D=0A> From:Adrian Chadd >=0D=0A> Sent: Wednesday 31st July= 2013 20:03=0D=0A> To: Ian Lepore >=0D=0A> Cc: freebsd-arm >; freebsd-wireless@freebsd.org ; Hans Petter Selasky >=0D=0A> Subject: Re: My WLI-UC-GNM up c= rash=0D=0A>=20=0D=0A> No idea about the device disconnect, sorry. is it a= power draw problem=3F=0D=0A>=20=0D=0A>=20=0D=0A> -adrian=0D=0A>=20=0D=0A= > On 31 July 2013 06:41, Ian Lepore > wrote:=0D=0A> > On Wed, 2013-07-31 at 16:28 +0800, XiaoQI Ge wrote= :=0D=0A> >> Last night, I use the latest FreeBSD source (r253827) and=0D=0A= > >> crochet-freebsd compile img=0D=0A> >> My WLI-UC-GNM will be disconne= cted after a period of operation=0D=0A> >>=0D=0A> >> run0: device timeout= =0D=0A> >> run0: at uhub0, port 1, addr 2 (disconnected)=0D=0A> >>=0D=0A>= >> Another log prompted=0D=0A> >> ti_mmchs0: Error: current cmd NULL, al= ready done=3F=0D=0A> >>=0D=0A> >> My BB-Black broken=3F=0D=0A> >=0D=0A> >= The ti_mmchs0 error is not new. My old BBW has done that for months.=0D= =0A> > I'm not sure it's totally harmless, but it's not related to the ru= n0=0D=0A> > timeouts.=0D=0A> >=0D=0A> > -- Ian=0D=0A> >=0D=0A> > ________= _______________________________________=0D=0A> > freebsd-arm@freebsd.org = mailing list=0D=0A> > http://lists.free= bsd.org/mailman/listinfo/freebsd-arm =20=0D=0A> > To unsubscribe, send any mail to "freebsd= -arm-unsubscribe@freebsd.org = "=0D=0A> _______________________________________________=0D=0A> freebsd-= arm@freebsd.org mailing list=0D=0A> htt= p://lists.freebsd.org/mailman/listinfo/freebsd-arm =20=0D=0A> To unsubscribe, send any mail= to "freebsd-arm-unsubscribe@freebsd.org "=0D=0A>=20=0D=0A=0D=0A From owner-freebsd-arm@FreeBSD.ORG Wed Jul 31 22:31:58 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AAFB0285 for ; Wed, 31 Jul 2013 22:31:58 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6D5BA2A7A for ; Wed, 31 Jul 2013 22:31:57 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1V4evu-0003aQ-Iv; Wed, 31 Jul 2013 22:31:51 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r6VMVluu020476; Wed, 31 Jul 2013 16:31:47 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19h+xsOjdxGvlD2UeNw/jjw Subject: Re: Kernel Panic on DREAMPLUG: Alignment Fault 1 From: Ian Lepore To: Mattia Rossi In-Reply-To: <51F92F79.9010809@gmail.com> References: <51F92F79.9010809@gmail.com> Content-Type: text/plain; charset="us-ascii" Date: Wed, 31 Jul 2013 16:31:47 -0600 Message-ID: <1375309907.45247.185.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 22:31:58 -0000 On Wed, 2013-07-31 at 17:38 +0200, Mattia Rossi wrote: > Hi all, > > this might be related to the WLI-UC-GNM Alignment Fault, but definitely > has nothing to do with Wireless LAN. > It rather seems that there's a problem with the USB subsystem. > > See dmesg an backtrace below. > > ## Starting application at 0x00900000 ... > 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 #9 r253846M: Wed Jul 31 17:24:31 CEST 2013 > root@freebsd9.1-base:/usr/obj/arm.arm/usr/devel/dreamplug/sys/DREAMPLUG-100m > FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 > WARNING: DIAGNOSTIC option enabled, expect reduced performance. > CPU: Feroceon 88FR131 rev 1 (Marvell core) > Little-endian DC enabled IC enabled WA disabled DC streaming enabled > BTB disabled L2 enabled L2 prefetch enabled > WB enabled EABT branch prediction enabled > 16KB/32B 4-way instruction cache > 16KB/32B 4-way write-back-locking-C data cache > real memory = 536870912 (512 MB) > avail memory = 510828544 (487 MB) > SOC: Marvell 88F6281 rev A1, TClock 200MHz > Instruction cache prefetch disabled, data cache prefetch disabled > 256KB 4-way set-associative write-through unified L2 cache > random device not loaded; using insecure entropy > localbus0: on fdtbus0 > simplebus0: on fdtbus0 > ic0: mem 0xf1020200-0xf102023b > on sim0 > timer0: mem 0xf1020300-0xf102032f irq 1 on simplebus0 > Event timer "CPUTimer0" frequency 200000000 Hz quality 1000 > Timecounter "CPUTimer1" frequency 200000000 Hz quality 1000 > gpio0: mem 0xf1010100-0xf101011f > irq 35,360 > rtc0: mem 0xf1010300-0xf1010307 on simplebus0 > twsi0: mem 0xf1011000-0xf101101f > irq 430 > iicbus0: on twsi0 > iic0: on iicbus0 > mge0: mem 0xf1072000-0xf1073fff > irq 12,130 > mge0: Ethernet address: f0:ad:4e:00:84:c7 > miibus0: on mge0 > e1000phy0: PHY 0 on miibus0 > e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > 1000baseT, 10o > mge1: mem 0xf1076000-0xf1077fff > irq 16,170 > mge1: Ethernet address: f0:ad:4e:00:84:c8 > miibus1: on mge1 > e1000phy1: PHY 1 on miibus1 > e1000phy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > 1000baseT, 10o > uart0: <16550 or compatible> mem 0xf1012000-0xf101201f irq 33 on simplebus0 > uart0: console (1056,n,8,1) > uart1: <16550 or compatible> mem 0xf1012100-0xf101211f irq 34 on simplebus0 > cesa0: mem > 0xf1030000-00 > ehci0: mem 0xf1050000-0xf1050fff > irq 480 > usbus0: EHCI version 1.0 > usbus0: set host controller mode > usbus0 on ehci0 > mvs0: mem 0xf1080000-0xf1085fff irq 21 > on sim0 > mvs0: Gen-IIe, 2 3Gbps ports, Port Multiplier supported with FBS > mvsch0: at channel 0 on mvs0 > mvsch1: at channel 1 on mvs0 > cryptosoft0: > Timecounters tick every 10.000 msec > IPsec: Initialized Security Association Processing. > ipfw2 (+ipv6) initialized, divert enabled, nat enabled, default to > accept, loggd > DUMMYNET 0 with IPv6 initialized (100409) > load_dn_sched dn_sched FIFO loaded > load_dn_sched dn_sched PRIO loaded > load_dn_sched dn_sched QFQ loaded > load_dn_sched dn_sched RR loaded > load_dn_sched dn_sched WF2Q+ loaded > usbus0: 480Mbps High Speed USB v2.0 > Fatal kernel mode data abort: 'Alignment Fault 1' > trapframe: 0xde472b48 > FSR=00000001, FAR=de472bc4, spsr=60000093 > r0 =001e48e5, r1 =ffffffff, r2 =0000001c, r3 =001e48e5 > r4 =de472bbc, r5 =de472bc4, r6 =c3598c80, r7 =c0e7c830 > r8 =798ee230, r9 =00000015, r10=00000001, r11=de472bb4 > r12=c0d240e8, ssp=de472b94, slr=c0d44c6c, pc =c0ab8264 > > [ thread pid 5 tid 100036 ] > Stopped at binuptime+0x70: und 0xe1c500d0 > db> bt > Tracing pid 5 tid 100036 td 0xc3598c80 > db_trace_self() at db_trace_self > pc = 0xc0d2807c lr = 0xc0941d84 (db_hex2dec+0x4d8) > sp = 0xde472840 fp = 0xde472858 > r10 = 0xc0e59e60 > db_hex2dec() at db_hex2dec+0x4d8 > pc = 0xc0941d84 lr = 0xc09416f4 (db_command_loop+0x2f4) > sp = 0xde472860 fp = 0xde472900 > r4 = 0x00000000 r5 = 0x00000000 > r6 = 0xc0d9e9fc > db_command_loop() at db_command_loop+0x2f4 > pc = 0xc09416f4 lr = 0xc0941450 (db_command_loop+0x50) > sp = 0xde472908 fp = 0xde472918 > r4 = 0xc0d7bae3 r5 = 0xc0d98378 > r6 = 0xc0ebbdb8 r7 = 0xde472b48 > r8 = 0xde472b48 r9 = 0xc0eb0614 > r10 = 0xc0e5a0d0 > db_command_loop() at db_command_loop+0x50 > pc = 0xc0941450 lr = 0xc0943e68 (X_db_symbol_values+0x254) > sp = 0xde472920 fp = 0xde472a40 > r4 = 0x00000000 r5 = 0xde472928 > r6 = 0xc0eb0638 > X_db_symbol_values() at X_db_symbol_values+0x254 > pc = 0xc0943e68 lr = 0xc0adf580 (kdb_trap+0xd4) > sp = 0xde472a48 fp = 0xde472a68 > r4 = 0x00000000 r5 = 0x00000001 > r6 = 0xc0eb0638 r7 = 0xde472b48 > kdb_trap() at kdb_trap+0xd4 > pc = 0xc0adf580 lr = 0xc0d38810 (data_abort_handler+0x640) > sp = 0xde472a70 fp = 0xde472a88 > r4 = 0xde472b48 r5 = 0x600000d3 > r6 = 0xde472bc4 r7 = 0x00000001 > r8 = 0xde472b48 r9 = 0xde472bc4 > r10 = 0x00000001 > data_abort_handler() at data_abort_handler+0x640 > pc = 0xc0d38810 lr = 0xc0d39208 (swi_handler+0x548) > sp = 0xde472a90 fp = 0xde472a98 > r4 = 0x00000001 r5 = 0xc3598c80 > r6 = 0xc3598c80 r7 = 0xc0d39194 > swi_handler() at swi_handler+0x548 > pc = 0xc0d39208 lr = 0xc0d3854c (data_abort_handler+0x37c) > sp = 0xde472aa0 fp = 0xde472b40 > data_abort_handler() at data_abort_handler+0x37c > pc = 0xc0d3854c lr = 0xc0d29924 (exception_exit) > sp = 0xde472b48 fp = 0xde472bb4 > r4 = 0xffffffff r5 = 0xffff1004 > r6 = 0xc3598c80 r7 = 0xc0e7c830 > r8 = 0x798ee230 r9 = 0x00000015 > r10 = 0x00000001 > exception_exit() at exception_exit > pc = 0xc0d29924 lr = 0xc0d44c6c (DELAY+0x764) > sp = 0xde472b94 fp = 0xde472bb4 > r0 = 0x001e48e5 r1 = 0xffffffff > r2 = 0x0000001c r3 = 0x001e48e5 > r4 = 0xde472bbc r5 = 0xde472bc4 > r6 = 0xc3598c80 r7 = 0xc0e7c830 > r8 = 0x798ee230 r9 = 0x00000015 > r10 = 0x00000001 r12 = 0xc0d240e8 > binuptime() at binuptime+0x74 > pc = 0xc0ab8268 lr = 0xc0d503ec (cpu_initclocks_bsp+0x41c) > sp = 0xde472bbc fp = 0xde472bd4 > r4 = 0x00000003 r5 = 0x00033940 > r6 = 0xc3598c80 r7 = 0xc0d92761 > r8 = 0xc0d9273a r9 = 0x00000000 > r10 = 0xc3586ac0 > cpu_initclocks_bsp() at cpu_initclocks_bsp+0x41c > pc = 0xc0d503ec lr = 0xc0d44af8 (DELAY+0x5f0) > sp = 0xde472bdc fp = 0xde472be4 > r4 = 0xc352d400 r5 = 0xde472c34 > DELAY() at DELAY+0x5f0 > pc = 0xc0d44af8 lr = 0xc0a82468 (intr_event_handle+0x88) > sp = 0xde472bec fp = 0xde472c14 > r4 = 0xc341e400 > intr_event_handle() at intr_event_handle+0x88 > pc = 0xc0a82468 lr = 0xc0d2acac (arm_handler_execute+0x54) > sp = 0xde472c1c fp = 0xde472c2c > r4 = 0xde472c34 r5 = 0x00000001 > r6 = 0xc0e97c40 r7 = 0xc0eb90d8 > r8 = 0xc352c200 r9 = 0xc37a1000 > r10 = 0xc37a1000 > arm_handler_execute() at arm_handler_execute+0x54 > pc = 0xc0d2acac lr = 0xc0d3e2dc (irq_entry+0x94) > sp = 0xde472c34 fp = 0xde472c90 > r4 = 0x00000000 r5 = 0xffff1004 > r6 = 0xc0ebbc50 r7 = 0x00004c5f > irq_entry() at irq_entry+0x94 > pc = 0xc0d3e2dc lr = 0xc0d3e2dc (irq_entry+0x94) > sp = 0xde472c34 fp = 0xde472c90 > Unwind failure (no registers changed) > db> > > > Usually this is the USB bit that follows the usbus0 line: > > ugen0.1: at usbus0 > uhub0: on usbus0 > WARNING: DIAGNOSTIC option enabled, expect reduced performance. > uhub0: 1 port with 1 removable, self powered > Root mount waiting for: usbus0 > ugen0.2: at usbus0 > uhub1: on > usbus0 > Root mount waiting for: usbus0 > uhub1: 4 ports with 4 removable, self powered > Root mount waiting for: usbus0 > Root mount waiting for: usbus0 > ugen0.3: at usbus0 > umass0: > on usbus0 > da0 at umass-sim0 bus 0 scbus2 target 0 lun 0 > da0: Removable Direct Access SCSI-0 device > da0: 40.000MB/s transfers > da0: 1876MB (3842048 512 byte sectors: 255H 63S/T 239C) > da0: quirks=0x3 > da1 at umass-sim0 bus 0 scbus2 target 0 lun 1 > da1: Removable Direct Access SCSI-0 device > da1: 40.000MB/s transfers > da1: 974MB (1995264 512 byte sectors: 64H 32S/T 974C) > da1: quirks=0x3 > Root mount waiting for: usbus0 > ugen0.4: at usbus0 > umass1: 2.00/1.00, a0 > da2 at umass-sim1 bus 1 scbus3 target 0 lun 0 > da2: Removable Direct Access SCSI-2 device > da2: 40.000MB/s transfers > da2: 1967MB (4030463 512 byte sectors: 255H 63S/T 250C) > da2: quirks=0x2 > ugen0.5: at usbus0 > > Currently trying to find where the issue could be. > > Mat This is a strange abort, and if it's usb-related that's only accidental I think. It says it's an alignment fault, but the fault address reg has a 32-bit aligned value in it. That makes me think it must be an ldrd/strd instruction (requires 64-bit alignment) that's faulting. Is this compiled with clang? I think it emits such instructions and gcc doesn't. Except I don't think clang should use those instructions on armv5, because of the alignment requirements. -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Aug 1 02:05:33 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6AAF17EB for ; Thu, 1 Aug 2013 02:05:33 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C764720D4 for ; Thu, 1 Aug 2013 02:05:32 +0000 (UTC) Received: by mail-ob0-f175.google.com with SMTP id xn12so2731233obc.6 for ; Wed, 31 Jul 2013 19:05:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Z8aP81aHuvXNJJVnpVAG99aLnN7Z5cjIFQun/uxybpk=; b=OPbDl/PZHI1oMi8Kg6EDYn+dUla6Xl7gbWqfgIjIKZoDPEJKJM2dABzyf9fk4SPCjD ytE2yy+FOriIwPggNnIg3ClRWt1RV3YMkkXlwrjwl4OE4hXvBsggLux3N3YCWBWVSAzJ Bwlre8vZM7o79VEQixcN60UMhGlsW5ygl05+iGan1NanKXDoD0SXcvcoPMgrqWFnK2LI pnb0mvTqr7Wcy+4GuBgWVRFS5YmV2Rde55FZ40NP3h1msYiGofVb40yK6h4udxpTk8Gt fI1Y6QkUUtXV6m6qh0x7dh8meJp7EErZBOjcrU7ni0ErqOGcYod3zqhfNz0NUqrUpk/6 hWHg== MIME-Version: 1.0 X-Received: by 10.50.128.36 with SMTP id nl4mr1010695igb.38.1375322732159; Wed, 31 Jul 2013 19:05:32 -0700 (PDT) Received: by 10.64.235.239 with HTTP; Wed, 31 Jul 2013 19:05:32 -0700 (PDT) Date: Thu, 1 Aug 2013 10:05:32 +0800 Message-ID: Subject: Allwinner A20 (dual core Cortex A7) From: Ganbold Tsagaankhuu To: "freebsd-arm@freebsd.org" , Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 02:05:33 -0000 Hi Hans and all, Just tried to run freebsd on Cubieboard2 with some minor modification to timer code for A10. However after detecting usb it just stops near "Root mount waiting for: usbus1". I see light on usb stick. System supposed to mount rootfs from usb stick and usb stick was prepared by using Tim's crochet script. Dmesg: http://pastebin.com/7WkkExN2 What problem it could be? Any suggestions? thanks a lot, Ganbold From owner-freebsd-arm@FreeBSD.ORG Thu Aug 1 02:10:10 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D61B684E for ; Thu, 1 Aug 2013 02:10:10 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AC6F820EF for ; Thu, 1 Aug 2013 02:10:10 +0000 (UTC) Received: by mail-pa0-f43.google.com with SMTP id hz10so1550544pad.30 for ; Wed, 31 Jul 2013 19:10:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=ELxEN6qdrtzDJymJyhEILH109A6YjD2JBzW3H6kjNZg=; b=jWskWxGlBljhqggNAIPa0rKEr3TewZrcvjJ0emaxEMD1AG/OOBfSuimOs5RbZpjgwm PTOS8rV+pw2bNYywuca/3JSe3LQzbEAJ5NQu68o0IqTVL+ncpefgTZmhdIhtpMS48I/h nREVY98RycIZ1hPHH7H5ZQ6J+7VhLUzcEOwmWcXzEbhNE/ww7FzIBQzj8Ox/Sjrfk5Zi 9eqze4axBXr4+qnPPrFxmSRiiJmDn2GHTmpkPHA24ANBSXKwIeZjnYsQYRy/eC/BBjJ2 HYarII6vzWeY/GGtrTisV2S1Shvd9l3ZRraj3didncNPGfD8Jkn7zk9fv6xeb6cG4n5Y SHXA== X-Received: by 10.68.106.36 with SMTP id gr4mr10610562pbb.0.1375323004764; Wed, 31 Jul 2013 19:10:04 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id ai6sm849274pad.15.2013.07.31.19.10.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 31 Jul 2013 19:10:03 -0700 (PDT) Sender: Warner Losh Subject: Re: Allwinner A20 (dual core Cortex A7) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Wed, 31 Jul 2013 20:09:59 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <00B715B9-CC2F-4660-8987-448FD1AA9E5E@bsdimp.com> References: To: Ganbold Tsagaankhuu X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQkc+gLNwmMVgKQZ5x8s/1Oy2G/iyEvihGrjSVH3nHEyPm7kb5wwjmjszShTZpXPawLFVo1G Cc: "freebsd-arm@freebsd.org" , Hans Petter Selasky X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 02:10:10 -0000 On Jul 31, 2013, at 8:05 PM, Ganbold Tsagaankhuu wrote: > Hi Hans and all, >=20 > Just tried to run freebsd on Cubieboard2 with some minor modification = to > timer code for A10. > However after detecting usb it just stops near "Root mount waiting = for: > usbus1". I see light on usb stick. System supposed to mount rootfs = from usb > stick and usb stick was prepared by using Tim's crochet script. >=20 > Dmesg: http://pastebin.com/7WkkExN2 >=20 > What problem it could be? Any suggestions? Clocks. I'd make sure that all the clocks are spun up correctly. On = other ARM cores if you do this wrong (and it tends to be different for = different SoCs), then you get weird usb behavior. Interrupts. When interrupts aren't routed correctly, usb misbehaves = (although not that badly). Cache. Maybe the cache lines are bigger (though doubtful, since the A10 = has an A7 inside, iirc). If so, then USB_DMA_ALIGNMENT may need to be = bumped. Warner From owner-freebsd-arm@FreeBSD.ORG Thu Aug 1 03:45:30 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 318E4124 for ; Thu, 1 Aug 2013 03:45:30 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E65D2257C for ; Thu, 1 Aug 2013 03:45:29 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r713jMsY021330 for arm@freebsd.org; Thu, 1 Aug 2013 03:45:22 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id tsvx3nmsmrpuytpvpymk5kk752; for arm@freebsd.org; Thu, 01 Aug 2013 03:45:22 +0000 (UTC) (envelope-from kientzle@freebsd.org) From: Tim Kientzle Content-Type: multipart/signed; boundary="Apple-Mail=_8A099A6C-45B2-41B1-BB58-C8329D337275"; protocol="application/pgp-signature"; micalg=pgp-sha1 Subject: RFC: sysutils/u-boot-beaglebone-eabi Date: Wed, 31 Jul 2013 20:45:19 -0700 Message-Id: To: "freebsd-arm@freebsd.org" Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 03:45:30 -0000 --Apple-Mail=_8A099A6C-45B2-41B1-BB58-C8329D337275 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii I (finally) got this port committed and would appreciate feedback. Especially if you're building BeagleBone (White or Black) images *without* Crochet, please take a look and let me know what needs to be changed so this is useful for you. Goals: 1) Build U-Boot as a port with correct dependencies. $ cd /usr/ports/sysutils/u-boot-beaglebone-eabi $ make $ make install This uses the arm-eabi-gcc cross-compiler so it can build on any FreeBSD architecture and properly spit out an ARM executable. 2) Make it unnecessary for most people to actually build U-Boot. The port installs the binary bits into /usr/local/share/u-boot/beaglebone-eabi. From there, system builders such as Crochet can just copy the bits onto target images. This also means that the FreeBSD package-building clusters can build this so that people can get a usable pre-built U-Boot by installing a binary package. 3) Provide a full-featured U-Boot for BeagleBone that can be used for a variety of purposes. This port is currently based on the patches I developed while working on Crochet, and I hope to soon switch Crochet to use this instead of building U-Boot itself. But it should be useful to anyone trying to run FreeBSD on BeagleBone, regardless of how you're building or booting the system. If it's not useful to you, please let me know why so I can try to make it more general. (Rui has already suggested some changes to better support netbooting.) 4) Provide a template for other U-Boot ports. Once this is stable, I intend to use the same approach to add ports for U-Boot on RPi, U-Boot on PandaBoard, etc. Tim P.S. By the way, to make this work, I had to add real ARM cross-compiler ports. We now have devel/arm-eabi-binutils and devel/arm-eabi-gcc --Apple-Mail=_8A099A6C-45B2-41B1-BB58-C8329D337275 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) iQEcBAEBAgAGBQJR+dnRAAoJEGMNyGo0rfFBmmMH/0KTreKcuJsbE2cmpwzpbR7/ 4Eo43+cJhRHipKJF09ZcuxvsD6CddQNvSlv+hRq5jz/kqfkrah4iKBwMney2iLWX fcLqKHkkwADhzOpZT9FBPqbEt/0OWt3FyeCnjhEwqxiVCCZsB1l7UFYQJWtcTdXF ziKAEFlK+g1Z0pPaibXpqFoJ+d0uP6ekt1G55I2BU/MXI3e5VbqtOGUPCYJENsCq DSz81DoCjdOfGP1K28fyd3SSNSrJSoJzONGlhXkFupRK0hDEMZ9hFQg6hzf7hUHF pGLELv+TXSUaRj6/AXqhKgxkbvNGEKlVwD4kaSlaCLqnZeRowpIFfJG+XNs48bs= =8ICy -----END PGP SIGNATURE----- --Apple-Mail=_8A099A6C-45B2-41B1-BB58-C8329D337275-- From owner-freebsd-arm@FreeBSD.ORG Thu Aug 1 06:24:10 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CF4A220C for ; Thu, 1 Aug 2013 06:24:10 +0000 (UTC) (envelope-from andrew@wafaa.eu) Received: from wafaa.eu (wafaa.eu [93.97.238.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 87F102B8F for ; Thu, 1 Aug 2013 06:24:10 +0000 (UTC) Received: from fveusrv01.wafaa.eu (localhost [127.0.0.1]) by wafaa.eu (Postfix) with ESMTP id C5A72282501 for ; Thu, 1 Aug 2013 07:14:49 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by wafaa.eu (Postfix) with ESMTP id 4888B2823FE for ; Thu, 1 Aug 2013 07:14:49 +0100 (BST) X-Virus-Scanned: amavisd-new at wafaa.eu Received: from wafaa.eu ([127.0.0.1]) by localhost (fveusrv01.wafaa.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DusGtfxAq4Qc for ; Thu, 1 Aug 2013 07:14:47 +0100 (BST) Received: from mail.wafaa.eu (localhost [127.0.0.1]) (Authenticated sender: andrew.wafaa@wafaa.eu) by wafaa.eu (Postfix) with ESMTPSA id 61FA22824FF for ; Thu, 1 Aug 2013 07:14:46 +0100 (BST) Received: from Qk3qn9veKhE7S3WX9BFGTzTHZdqRFfqf by mail.wafaa.eu with HTTP (HTTP/1.1 POST); Thu, 01 Aug 2013 06:14:46 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 01 Aug 2013 07:14:46 +0100 From: Andrew Wafaa To: freebsd-arm@freebsd.org Subject: Re: Allwinner A20 (dual core Cortex A7) In-Reply-To: <00B715B9-CC2F-4660-8987-448FD1AA9E5E@bsdimp.com> References: <00B715B9-CC2F-4660-8987-448FD1AA9E5E@bsdimp.com> Message-ID: <305aab98f554d14590e9768e2f676372@wafaa.eu> X-Sender: andrew@wafaa.eu User-Agent: Roundcube Webmail/0.9.2-5.1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 06:24:10 -0000 On 01-08-2013 03:09, Warner Losh wrote: > On Jul 31, 2013, at 8:05 PM, Ganbold Tsagaankhuu wrote: > >> Hi Hans and all, >> >> Just tried to run freebsd on Cubieboard2 with some minor modification >> to >> timer code for A10. >> However after detecting usb it just stops near "Root mount waiting >> for: >> usbus1". I see light on usb stick. System supposed to mount rootfs >> from usb >> stick and usb stick was prepared by using Tim's crochet script. >> >> Dmesg: http://pastebin.com/7WkkExN2 >> >> What problem it could be? Any suggestions? > > Clocks. I'd make sure that all the clocks are spun up correctly. On > other ARM cores if you do this wrong (and it tends to be different for > different SoCs), then you get weird usb behavior. > > Interrupts. When interrupts aren't routed correctly, usb misbehaves > (although not that badly). > > Cache. Maybe the cache lines are bigger (though doubtful, since the > A10 has an A7 inside, iirc). If so, then USB_DMA_ALIGNMENT may need to > be bumped. > One of the big differences with the A20 vs the A10 is the Interrupt Controller, as the new Cortex-A7 based devices are now connected to a standard ARM GIC rather than some home grown thing on the older Cortex-A8s. There's a strong chance that it could be causing you issues if not supported properly, this is certainly the case on other OSes. Regards, Andy From owner-freebsd-arm@FreeBSD.ORG Thu Aug 1 06:27:32 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9A984391; Thu, 1 Aug 2013 06:27:32 +0000 (UTC) (envelope-from rpaulo@felyko.com) Received: from felyko.com (felyko.com [174.136.100.2]) by mx1.freebsd.org (Postfix) with ESMTP id 7E4632BBC; Thu, 1 Aug 2013 06:27:32 +0000 (UTC) Received: from [IPv6:2601:9:4d00:119:c060:f1df:12a7:d6c4] (unknown [IPv6:2601:9:4d00:119:c060:f1df:12a7:d6c4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id D1F9B3982B; Wed, 31 Jul 2013 23:27:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=felyko.com; s=mail; t=1375338446; bh=kBxnkNzrv6vJgjU0JHtW/yLZv1s1bjllwBHhUqB/+nU=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=FW782fvPcutsGqDGmqg+uH5kqXR/PIhQOFSar9p3fMJ5QPJQioh0jCBKyZzxGjrp3 Q9L/XbocQBCN3at+j9Xxx0Kbxg2NteCLYArcvYnjTBZXRZCv6Aty/IMdf/Y168x7AK Z1ivoZx0gB/G9d0x9Dc0l9vFfgu+kaym2BjZxHdk= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: My WLI-UC-GNM up crash From: Rui Paulo In-Reply-To: Date: Wed, 31 Jul 2013 23:27:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4A2B91AC-286D-4D13-8C1B-DA4822FEDE98@felyko.com> References: <20130729211540.GZ26412@funkthat.com> <1375151095.45247.54.camel@revolution.hippie.lan> To: XiaoQI Ge X-Mailer: Apple Mail (2.1508) Cc: freebsd-arm , "freebsd-wireless@freebsd.org" , Ian Lepore , Hans Petter Selasky X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 06:27:32 -0000 On 31 Jul 2013, at 01:28, XiaoQI Ge wrote: > Last night, I use the latest FreeBSD source (r253827) and > crochet-freebsd compile img > My WLI-UC-GNM will be disconnected after a period of operation >=20 > run0: device timeout > run0: at uhub0, port 1, addr 2 (disconnected) If you are using the USB cable to power the BBB, then that's your = problem. You need a 5V 1A+ power adapter to be able to use USB WiFi = cards with the BeagleBone. -- Rui Paulo From owner-freebsd-arm@FreeBSD.ORG Thu Aug 1 06:29:51 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 599B03F7; Thu, 1 Aug 2013 06:29:51 +0000 (UTC) (envelope-from mattia.rossi.mate@gmail.com) Received: from mail-bk0-x22c.google.com (mail-bk0-x22c.google.com [IPv6:2a00:1450:4008:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 984932BCA; Thu, 1 Aug 2013 06:29:50 +0000 (UTC) Received: by mail-bk0-f44.google.com with SMTP id mz10so533926bkb.31 for ; Wed, 31 Jul 2013 23:29:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Tw3H45IJv2f0yxAvBhAc+cnwmSV9vsYchlFT4dWP8xQ=; b=R7AH8u1E7t8XMlIOLSO7VLmsD59ZT5gpX5w74czHTtTbmLzeyUKvvu5KLkG1mJM689 W0HkRsTG9Fmn4o0D/OKSNlMIHC/EpywlWR+Iv0hdZ/+PMDCHrWTR+2K9uQ+rWGwSV/1O uHTXau3A/nh1Le2RkwnBbTgA9Xch1QRgNhHInJMnwTus/KDOq4R5/E8sHnEaJvnspsj3 t+kNg0a7b5AvOJfKAcdS4e37fj6lXPDDyMpMmUQfkbauGde17AMCU4SUuseufqyn4m/6 2nq7QtVyZsCTVZTdza8w+9l/ylN9WKfrBtJnG5xhBt3DrkzH0/KygYBrtRbIIODGy3mJ lFlQ== X-Received: by 10.205.114.207 with SMTP id fb15mr9824577bkc.140.1375338588080; Wed, 31 Jul 2013 23:29:48 -0700 (PDT) Received: from [10.185.11.70] ([46.189.28.44]) by mx.google.com with ESMTPSA id hn4sm145782bkc.2.2013.07.31.23.29.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 31 Jul 2013 23:29:47 -0700 (PDT) Message-ID: <51F9C81A.7000106@gmail.com> Date: Thu, 01 Aug 2013 04:29:46 +0200 From: Mattia Rossi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Ian Lepore Subject: Re: Kernel Panic on DREAMPLUG: Alignment Fault 1 References: <51F92F79.9010809@gmail.com> <1375309907.45247.185.camel@revolution.hippie.lan> In-Reply-To: <1375309907.45247.185.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 06:29:51 -0000 On 01/08/13 00:31, Ian Lepore wrote: > On Wed, 2013-07-31 at 17:38 +0200, Mattia Rossi wrote: >> Hi all, >> >> this might be related to the WLI-UC-GNM Alignment Fault, but definitely >> has nothing to do with Wireless LAN. >> It rather seems that there's a problem with the USB subsystem. >> >> See dmesg an backtrace below. >> >> ## Starting application at 0x00900000 ... >> 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 #9 r253846M: Wed Jul 31 17:24:31 CEST 2013 >> root@freebsd9.1-base:/usr/obj/arm.arm/usr/devel/dreamplug/sys/DREAMPLUG-100m >> FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 >> WARNING: DIAGNOSTIC option enabled, expect reduced performance. >> CPU: Feroceon 88FR131 rev 1 (Marvell core) >> Little-endian DC enabled IC enabled WA disabled DC streaming enabled >> BTB disabled L2 enabled L2 prefetch enabled >> WB enabled EABT branch prediction enabled >> 16KB/32B 4-way instruction cache >> 16KB/32B 4-way write-back-locking-C data cache >> real memory = 536870912 (512 MB) >> avail memory = 510828544 (487 MB) >> SOC: Marvell 88F6281 rev A1, TClock 200MHz >> Instruction cache prefetch disabled, data cache prefetch disabled >> 256KB 4-way set-associative write-through unified L2 cache >> random device not loaded; using insecure entropy >> localbus0: on fdtbus0 >> simplebus0: on fdtbus0 >> ic0: mem 0xf1020200-0xf102023b >> on sim0 >> timer0: mem 0xf1020300-0xf102032f irq 1 on simplebus0 >> Event timer "CPUTimer0" frequency 200000000 Hz quality 1000 >> Timecounter "CPUTimer1" frequency 200000000 Hz quality 1000 >> gpio0: mem 0xf1010100-0xf101011f >> irq 35,360 >> rtc0: mem 0xf1010300-0xf1010307 on simplebus0 >> twsi0: mem 0xf1011000-0xf101101f >> irq 430 >> iicbus0: on twsi0 >> iic0: on iicbus0 >> mge0: mem 0xf1072000-0xf1073fff >> irq 12,130 >> mge0: Ethernet address: f0:ad:4e:00:84:c7 >> miibus0: on mge0 >> e1000phy0: PHY 0 on miibus0 >> e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, >> 1000baseT, 10o >> mge1: mem 0xf1076000-0xf1077fff >> irq 16,170 >> mge1: Ethernet address: f0:ad:4e:00:84:c8 >> miibus1: on mge1 >> e1000phy1: PHY 1 on miibus1 >> e1000phy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, >> 1000baseT, 10o >> uart0: <16550 or compatible> mem 0xf1012000-0xf101201f irq 33 on simplebus0 >> uart0: console (1056,n,8,1) >> uart1: <16550 or compatible> mem 0xf1012100-0xf101211f irq 34 on simplebus0 >> cesa0: mem >> 0xf1030000-00 >> ehci0: mem 0xf1050000-0xf1050fff >> irq 480 >> usbus0: EHCI version 1.0 >> usbus0: set host controller mode >> usbus0 on ehci0 >> mvs0: mem 0xf1080000-0xf1085fff irq 21 >> on sim0 >> mvs0: Gen-IIe, 2 3Gbps ports, Port Multiplier supported with FBS >> mvsch0: at channel 0 on mvs0 >> mvsch1: at channel 1 on mvs0 >> cryptosoft0: >> Timecounters tick every 10.000 msec >> IPsec: Initialized Security Association Processing. >> ipfw2 (+ipv6) initialized, divert enabled, nat enabled, default to >> accept, loggd >> DUMMYNET 0 with IPv6 initialized (100409) >> load_dn_sched dn_sched FIFO loaded >> load_dn_sched dn_sched PRIO loaded >> load_dn_sched dn_sched QFQ loaded >> load_dn_sched dn_sched RR loaded >> load_dn_sched dn_sched WF2Q+ loaded >> usbus0: 480Mbps High Speed USB v2.0 >> Fatal kernel mode data abort: 'Alignment Fault 1' >> trapframe: 0xde472b48 >> FSR=00000001, FAR=de472bc4, spsr=60000093 >> r0 =001e48e5, r1 =ffffffff, r2 =0000001c, r3 =001e48e5 >> r4 =de472bbc, r5 =de472bc4, r6 =c3598c80, r7 =c0e7c830 >> r8 =798ee230, r9 =00000015, r10=00000001, r11=de472bb4 >> r12=c0d240e8, ssp=de472b94, slr=c0d44c6c, pc =c0ab8264 >> >> [ thread pid 5 tid 100036 ] >> Stopped at binuptime+0x70: und 0xe1c500d0 >> db> bt >> Tracing pid 5 tid 100036 td 0xc3598c80 >> db_trace_self() at db_trace_self >> pc = 0xc0d2807c lr = 0xc0941d84 (db_hex2dec+0x4d8) >> sp = 0xde472840 fp = 0xde472858 >> r10 = 0xc0e59e60 >> db_hex2dec() at db_hex2dec+0x4d8 >> pc = 0xc0941d84 lr = 0xc09416f4 (db_command_loop+0x2f4) >> sp = 0xde472860 fp = 0xde472900 >> r4 = 0x00000000 r5 = 0x00000000 >> r6 = 0xc0d9e9fc >> db_command_loop() at db_command_loop+0x2f4 >> pc = 0xc09416f4 lr = 0xc0941450 (db_command_loop+0x50) >> sp = 0xde472908 fp = 0xde472918 >> r4 = 0xc0d7bae3 r5 = 0xc0d98378 >> r6 = 0xc0ebbdb8 r7 = 0xde472b48 >> r8 = 0xde472b48 r9 = 0xc0eb0614 >> r10 = 0xc0e5a0d0 >> db_command_loop() at db_command_loop+0x50 >> pc = 0xc0941450 lr = 0xc0943e68 (X_db_symbol_values+0x254) >> sp = 0xde472920 fp = 0xde472a40 >> r4 = 0x00000000 r5 = 0xde472928 >> r6 = 0xc0eb0638 >> X_db_symbol_values() at X_db_symbol_values+0x254 >> pc = 0xc0943e68 lr = 0xc0adf580 (kdb_trap+0xd4) >> sp = 0xde472a48 fp = 0xde472a68 >> r4 = 0x00000000 r5 = 0x00000001 >> r6 = 0xc0eb0638 r7 = 0xde472b48 >> kdb_trap() at kdb_trap+0xd4 >> pc = 0xc0adf580 lr = 0xc0d38810 (data_abort_handler+0x640) >> sp = 0xde472a70 fp = 0xde472a88 >> r4 = 0xde472b48 r5 = 0x600000d3 >> r6 = 0xde472bc4 r7 = 0x00000001 >> r8 = 0xde472b48 r9 = 0xde472bc4 >> r10 = 0x00000001 >> data_abort_handler() at data_abort_handler+0x640 >> pc = 0xc0d38810 lr = 0xc0d39208 (swi_handler+0x548) >> sp = 0xde472a90 fp = 0xde472a98 >> r4 = 0x00000001 r5 = 0xc3598c80 >> r6 = 0xc3598c80 r7 = 0xc0d39194 >> swi_handler() at swi_handler+0x548 >> pc = 0xc0d39208 lr = 0xc0d3854c (data_abort_handler+0x37c) >> sp = 0xde472aa0 fp = 0xde472b40 >> data_abort_handler() at data_abort_handler+0x37c >> pc = 0xc0d3854c lr = 0xc0d29924 (exception_exit) >> sp = 0xde472b48 fp = 0xde472bb4 >> r4 = 0xffffffff r5 = 0xffff1004 >> r6 = 0xc3598c80 r7 = 0xc0e7c830 >> r8 = 0x798ee230 r9 = 0x00000015 >> r10 = 0x00000001 >> exception_exit() at exception_exit >> pc = 0xc0d29924 lr = 0xc0d44c6c (DELAY+0x764) >> sp = 0xde472b94 fp = 0xde472bb4 >> r0 = 0x001e48e5 r1 = 0xffffffff >> r2 = 0x0000001c r3 = 0x001e48e5 >> r4 = 0xde472bbc r5 = 0xde472bc4 >> r6 = 0xc3598c80 r7 = 0xc0e7c830 >> r8 = 0x798ee230 r9 = 0x00000015 >> r10 = 0x00000001 r12 = 0xc0d240e8 >> binuptime() at binuptime+0x74 >> pc = 0xc0ab8268 lr = 0xc0d503ec (cpu_initclocks_bsp+0x41c) >> sp = 0xde472bbc fp = 0xde472bd4 >> r4 = 0x00000003 r5 = 0x00033940 >> r6 = 0xc3598c80 r7 = 0xc0d92761 >> r8 = 0xc0d9273a r9 = 0x00000000 >> r10 = 0xc3586ac0 >> cpu_initclocks_bsp() at cpu_initclocks_bsp+0x41c >> pc = 0xc0d503ec lr = 0xc0d44af8 (DELAY+0x5f0) >> sp = 0xde472bdc fp = 0xde472be4 >> r4 = 0xc352d400 r5 = 0xde472c34 >> DELAY() at DELAY+0x5f0 >> pc = 0xc0d44af8 lr = 0xc0a82468 (intr_event_handle+0x88) >> sp = 0xde472bec fp = 0xde472c14 >> r4 = 0xc341e400 >> intr_event_handle() at intr_event_handle+0x88 >> pc = 0xc0a82468 lr = 0xc0d2acac (arm_handler_execute+0x54) >> sp = 0xde472c1c fp = 0xde472c2c >> r4 = 0xde472c34 r5 = 0x00000001 >> r6 = 0xc0e97c40 r7 = 0xc0eb90d8 >> r8 = 0xc352c200 r9 = 0xc37a1000 >> r10 = 0xc37a1000 >> arm_handler_execute() at arm_handler_execute+0x54 >> pc = 0xc0d2acac lr = 0xc0d3e2dc (irq_entry+0x94) >> sp = 0xde472c34 fp = 0xde472c90 >> r4 = 0x00000000 r5 = 0xffff1004 >> r6 = 0xc0ebbc50 r7 = 0x00004c5f >> irq_entry() at irq_entry+0x94 >> pc = 0xc0d3e2dc lr = 0xc0d3e2dc (irq_entry+0x94) >> sp = 0xde472c34 fp = 0xde472c90 >> Unwind failure (no registers changed) >> db> >> >> >> Usually this is the USB bit that follows the usbus0 line: >> >> ugen0.1: at usbus0 >> uhub0: on usbus0 >> WARNING: DIAGNOSTIC option enabled, expect reduced performance. >> uhub0: 1 port with 1 removable, self powered >> Root mount waiting for: usbus0 >> ugen0.2: at usbus0 >> uhub1: on >> usbus0 >> Root mount waiting for: usbus0 >> uhub1: 4 ports with 4 removable, self powered >> Root mount waiting for: usbus0 >> Root mount waiting for: usbus0 >> ugen0.3: at usbus0 >> umass0: >> on usbus0 >> da0 at umass-sim0 bus 0 scbus2 target 0 lun 0 >> da0: Removable Direct Access SCSI-0 device >> da0: 40.000MB/s transfers >> da0: 1876MB (3842048 512 byte sectors: 255H 63S/T 239C) >> da0: quirks=0x3 >> da1 at umass-sim0 bus 0 scbus2 target 0 lun 1 >> da1: Removable Direct Access SCSI-0 device >> da1: 40.000MB/s transfers >> da1: 974MB (1995264 512 byte sectors: 64H 32S/T 974C) >> da1: quirks=0x3 >> Root mount waiting for: usbus0 >> ugen0.4: at usbus0 >> umass1: > 2.00/1.00, a0 >> da2 at umass-sim1 bus 1 scbus3 target 0 lun 0 >> da2: Removable Direct Access SCSI-2 device >> da2: 40.000MB/s transfers >> da2: 1967MB (4030463 512 byte sectors: 255H 63S/T 250C) >> da2: quirks=0x2 >> ugen0.5: at usbus0 >> >> Currently trying to find where the issue could be. >> >> Mat > This is a strange abort, and if it's usb-related that's only accidental > I think. It says it's an alignment fault, but the fault address reg has > a 32-bit aligned value in it. That makes me think it must be an > ldrd/strd instruction (requires 64-bit alignment) that's faulting. > > Is this compiled with clang? I think it emits such instructions and gcc > doesn't. Except I don't think clang should use those instructions on > armv5, because of the alignment requirements. > > -- Ian Hi Ian, sorry, forgot to add that contrary to the WLI-UC-GNM problem, I'm still compiling using gcc on FreeBSD 9.1 The abort is completely reproducible each time at the same place... I've tried to recompile the kernel a few times, also changing the root device, but it gets stuck there and aborts.. I actually have no clue on what's going on here. Any hints on how to get more information about this? Cheers, Mat From owner-freebsd-arm@FreeBSD.ORG Thu Aug 1 07:14:08 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D0D149D9; Thu, 1 Aug 2013 07:14:08 +0000 (UTC) (envelope-from mark@grondar.org) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 967C52DE2; Thu, 1 Aug 2013 07:14:08 +0000 (UTC) Received: from graveyard.grondar.org ([88.96.155.33] helo=gronkulator.grondar.org) by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1V4n5J-0006D9-NK; Thu, 01 Aug 2013 08:14:07 +0100 Subject: Re: RFC: sysutils/u-boot-beaglebone-eabi Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: multipart/signed; boundary="Apple-Mail=_AEC046D9-FE32-4010-9269-8FAC762B470D"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark R V Murray In-Reply-To: Date: Thu, 1 Aug 2013 08:14:04 +0100 Message-Id: <1D89CA5C-4C52-4669-8239-935CE3904469@grondar.org> References: To: Tim Kientzle X-Mailer: Apple Mail (2.1508) X-SA-Score: -2.2 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 07:14:08 -0000 --Apple-Mail=_AEC046D9-FE32-4010-9269-8FAC762B470D Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 1 Aug 2013, at 04:45, Tim Kientzle wrote: > P.S. By the way, to make this work, I had to add real ARM cross-compiler > ports. We now have devel/arm-eabi-binutils and devel/arm-eabi-gcc Hi Tim, Does Clang/LLVM still not do this properly? What is wrong there? Thanks M -- Mark R V Murray --Apple-Mail=_AEC046D9-FE32-4010-9269-8FAC762B470D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUfoKvN58vKOKE6LNAQrK0QP5ASEysuh18r0Tyjw45TFNH95lwR3iLqgj nZyGxnGy81lS8K6aYJmoUp2leFXqw+I3b76+sTSJ6+FpFeWZFofUCdGwpN/Ut7pA PYUyutkxmskLhpO5ty2R5gZWwxRj+lbZgcWscSkt0MoDVjVUPHbiFO91ibfw71O+ YvxQWCptE4s= =140c -----END PGP SIGNATURE----- --Apple-Mail=_AEC046D9-FE32-4010-9269-8FAC762B470D-- From owner-freebsd-arm@FreeBSD.ORG Thu Aug 1 07:24:06 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5D016DE2 for ; Thu, 1 Aug 2013 07:24:06 +0000 (UTC) (envelope-from ghw@7axu.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E1B172E6E for ; Thu, 1 Aug 2013 07:24:05 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id u55so1368586wes.41 for ; Thu, 01 Aug 2013 00:24:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=VM7yR0DWGXlbFynaqR3BSbSt/cFA8UnhP/kx1QUEMtw=; b=pEdAMnaLUSGZAkIUOP+I/4IvjGLPGFNEzEUlYRxs0CR/2jKlPVJ/UWql4rd0ePAXPx oMSnM8RWTXWkhz7SBPw4WTk9cr0lrgRYXYGYTs9l3SY8DXoZrUZXJUQDaYngz0gPmVBF OD2WjT20Rr/4R5F3441ASVveNPMXGtdMvEAuB3KnGSTd1uUi9doERM8NSIlQc3GOXg8B BQ2fLrxcbYA9c//36rXhsEzcneANEbNe3WgEj8ggGgmq+L8LlbexPjXqq51wbm9jMXP4 /Q1ASXTiO12uMgQLNvxGHKNcGE6UhT6MaLeE7Mm4hwZm/2kPpw3G/HfGTPyjhGY0W3aU e+UA== X-Received: by 10.180.82.196 with SMTP id k4mr6897981wiy.0.1375341537274; Thu, 01 Aug 2013 00:18:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.93.34 with HTTP; Thu, 1 Aug 2013 00:18:17 -0700 (PDT) X-Originating-IP: [54.249.112.206] In-Reply-To: <4A2B91AC-286D-4D13-8C1B-DA4822FEDE98@felyko.com> References: <20130729211540.GZ26412@funkthat.com> <1375151095.45247.54.camel@revolution.hippie.lan> <4A2B91AC-286D-4D13-8C1B-DA4822FEDE98@felyko.com> From: XiaoQI Ge Date: Thu, 1 Aug 2013 15:18:17 +0800 Message-ID: Subject: Re: My WLI-UC-GNM up crash To: Rui Paulo Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlexZQYnSeVw+x/i7DMUH3RtLql3pa9htX/8L5FtpZCj8Nv4wngbyPQ2cZwpJOZ83yiCgpw Cc: freebsd-arm , "freebsd-wireless@freebsd.org" , Ian Lepore , Hans Petter Selasky X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 07:24:06 -0000 Before using the computer USB power supply, the implementation of usbdump, the kernel Panic Some log: http://pastebin.com/wPURnAg5 http://img.vim-cn.com/5f/576bc22abaadb1014dae4c4e73b07f48579e8e.bmp addr2line information: http://pastebin.com/sE5C7bqi 1A is used after the power supply Enter no response, TTL did not show additional information -- Regards. By: XiaoQI Ge; PGP:8B09D5F7 WWW: https://www.7axu.com/ 2013/8/1 Rui Paulo : > On 31 Jul 2013, at 01:28, XiaoQI Ge wrote: > >> Last night, I use the latest FreeBSD source (r253827) and >> crochet-freebsd compile img >> My WLI-UC-GNM will be disconnected after a period of operation >> >> run0: device timeout >> run0: at uhub0, port 1, addr 2 (disconnected) > > If you are using the USB cable to power the BBB, then that's your problem. You need a 5V 1A+ power adapter to be able to use USB WiFi cards with the BeagleBone. > > -- > Rui Paulo > From owner-freebsd-arm@FreeBSD.ORG Thu Aug 1 08:45:19 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B34B6DE6 for ; Thu, 1 Aug 2013 08:45:19 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7D982228B for ; Thu, 1 Aug 2013 08:45:19 +0000 (UTC) Received: by mail-ob0-f173.google.com with SMTP id ta17so3291594obb.4 for ; Thu, 01 Aug 2013 01:45:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vbHvEokFmAosLez1XZlRpCYQBVNx8qXJRxud+Aae5GU=; b=xNrq05j87UaUPp55cwSlowbcyx5Bhjz1nnPN+iyxttK8wFleor6Sti6v0gxubBDGzi r0hNOxv6CluyImx/iYp9dlTaNXRdi5k6m58Oq2+mYJDdXFKVxDQ0M6OIjSMqlA13NLOW JAZJaFOkGK5tb3JwUXHJMaio/zaLi/Beg3amEd1RnDw2nfeFjN3jqxcz4Yix8LQC0PBb Lsh4psgcNx5R+Ri4k4zz/W3omCBbE9eDZG/gieNRyE12IUuqWN8Yg1IFh2VE6mZtSgUu RR39G5ItUO0R8mSRvyDJafJI5nz4SOcNIufuRrJNhX6zzSjUWD6D8UuiZVtGUxw1kREX KXYg== MIME-Version: 1.0 X-Received: by 10.43.74.74 with SMTP id yv10mr51758icb.67.1375346718853; Thu, 01 Aug 2013 01:45:18 -0700 (PDT) Received: by 10.64.235.239 with HTTP; Thu, 1 Aug 2013 01:45:18 -0700 (PDT) In-Reply-To: <305aab98f554d14590e9768e2f676372@wafaa.eu> References: <00B715B9-CC2F-4660-8987-448FD1AA9E5E@bsdimp.com> <305aab98f554d14590e9768e2f676372@wafaa.eu> Date: Thu, 1 Aug 2013 16:45:18 +0800 Message-ID: Subject: Re: Allwinner A20 (dual core Cortex A7) From: Ganbold Tsagaankhuu To: Andrew Wafaa Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 08:45:19 -0000 On Thu, Aug 1, 2013 at 2:14 PM, Andrew Wafaa wrote: > On 01-08-2013 03:09, Warner Losh wrote: > >> On Jul 31, 2013, at 8:05 PM, Ganbold Tsagaankhuu wrote: >> >> Hi Hans and all, >>> >>> Just tried to run freebsd on Cubieboard2 with some minor modification to >>> timer code for A10. >>> However after detecting usb it just stops near "Root mount waiting for: >>> usbus1". I see light on usb stick. System supposed to mount rootfs from >>> usb >>> stick and usb stick was prepared by using Tim's crochet script. >>> >>> Dmesg: http://pastebin.com/7WkkExN2 >>> >>> What problem it could be? Any suggestions? >>> >> >> Clocks. I'd make sure that all the clocks are spun up correctly. On >> other ARM cores if you do this wrong (and it tends to be different for >> different SoCs), then you get weird usb behavior. >> >> Interrupts. When interrupts aren't routed correctly, usb misbehaves >> (although not that badly). >> >> Cache. Maybe the cache lines are bigger (though doubtful, since the >> A10 has an A7 inside, iirc). If so, then USB_DMA_ALIGNMENT may need to >> be bumped. >> >> > One of the big differences with the A20 vs the A10 is the Interrupt > Controller, as the new Cortex-A7 based devices are now connected to a > standard ARM GIC rather than some home grown thing on the older Cortex-A8s. > There's a strong chance that it could be causing you issues if not > supported properly, this is certainly the case on other OSes. > That was the problem, I thought I updated interrupts of devices in dts accordingly, however it wasn't. After updating interrupts to correct ones in dts, freebsd boots and works fine. thanks a lot, Ganbold > > Regards, > > Andy > ______________________________**_________________ > 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 > " > From owner-freebsd-arm@FreeBSD.ORG Thu Aug 1 12:03:49 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1BC89666 for ; Thu, 1 Aug 2013 12:03:49 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E5F482DAD for ; Thu, 1 Aug 2013 12:03:48 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1V4rbe-000Dz5-V6; Thu, 01 Aug 2013 12:03:47 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r71C3igU021339; Thu, 1 Aug 2013 06:03:44 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+fp0TyMzXueX/0vbd6i1TR Subject: Re: Kernel Panic on DREAMPLUG: Alignment Fault 1 From: Ian Lepore To: Mattia Rossi In-Reply-To: <51F9C81A.7000106@gmail.com> References: <51F92F79.9010809@gmail.com> <1375309907.45247.185.camel@revolution.hippie.lan> <51F9C81A.7000106@gmail.com> Content-Type: text/plain; charset="us-ascii" Date: Thu, 01 Aug 2013 06:03:43 -0600 Message-ID: <1375358623.45247.189.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 12:03:49 -0000 On Thu, 2013-08-01 at 04:29 +0200, Mattia Rossi wrote: > On 01/08/13 00:31, Ian Lepore wrote: > > On Wed, 2013-07-31 at 17:38 +0200, Mattia Rossi wrote: > >> Hi all, > >> > >> this might be related to the WLI-UC-GNM Alignment Fault, but definitely > >> has nothing to do with Wireless LAN. > >> It rather seems that there's a problem with the USB subsystem. > >> > >> See dmesg an backtrace below. > >>[snip] > >> > >> Currently trying to find where the issue could be. > >> > >> Mat > > This is a strange abort, and if it's usb-related that's only accidental > > I think. It says it's an alignment fault, but the fault address reg has > > a 32-bit aligned value in it. That makes me think it must be an > > ldrd/strd instruction (requires 64-bit alignment) that's faulting. > > > > Is this compiled with clang? I think it emits such instructions and gcc > > doesn't. Except I don't think clang should use those instructions on > > armv5, because of the alignment requirements. > > > > -- Ian > Hi Ian, > > sorry, forgot to add that contrary to the WLI-UC-GNM problem, I'm still > compiling using gcc on FreeBSD 9.1 > > The abort is completely reproducible each time at the same place... > I've tried to recompile the kernel a few times, also changing the root > device, but it gets stuck there and aborts.. > > I actually have no clue on what's going on here. Any hints on how to get > more information about this? > > Cheers, > > Mat Actually, it looks like you're using clang (I keep forgetting this comes out in dmesg now): >> FreeBSD 10.0-CURRENT #9 r253846M: Wed Jul 31 17:24:31 CEST 2013 >> root@freebsd9.1-base:/usr/obj/arm.arm/usr/devel/dreamplug/sys/DREAMPLUG-100m >> FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 Is the 'M' in r253846M anything significant? I haven't built for dreamplug in a long time (I haven't done much of anything with computers for several months). I'll get a build going and see if I get the same kind of problems. -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Aug 1 12:32:48 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 99EE1EC; Thu, 1 Aug 2013 12:32:48 +0000 (UTC) (envelope-from mattia.rossi.mate@gmail.com) Received: from mail-bk0-x22c.google.com (mail-bk0-x22c.google.com [IPv6:2a00:1450:4008:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ED1362F17; Thu, 1 Aug 2013 12:32:47 +0000 (UTC) Received: by mail-bk0-f44.google.com with SMTP id mz10so660691bkb.31 for ; Thu, 01 Aug 2013 05:32:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=36wOea+Z005uiuSYLT8pnXKl97132iUC7iDcWJqdp2Y=; b=hw+1toryFBvZ/SMgvfSP5i5fHKtdf/2beUYfzSY/KAme4eu4Gqn4NCWJntlT3FDR9L NmFfzWjNOogzwFXmvozv3Qc84NwEm1BBfvWaYNVQhIWtppvRF+SFj3TAxPeyyx/ApM3H RgSy002v4sw3dG7A+Y0Qd4SC2YeN4xwjGVpzT1sclLWRWCdA4L4kQzZpNMflz88zyyRn kMvptzYuEIZrz0e9GI8/fTM5ixiFYgi3Y3qhmjSyzjeC5F7wYbQ2vkVTQ6QHEeajcwsn sG/5v5E/5zCw3ZJYmUH3l/KiqE363vTjf2vWHVxwrJzZ2+y4fzpxEcIlFbjzUYoywdep /PfQ== X-Received: by 10.205.36.194 with SMTP id tb2mr340109bkb.174.1375360366106; Thu, 01 Aug 2013 05:32:46 -0700 (PDT) Received: from [10.185.11.70] ([46.189.28.44]) by mx.google.com with ESMTPSA id m6sm650904bki.7.2013.08.01.05.32.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 01 Aug 2013 05:32:45 -0700 (PDT) Message-ID: <51FA1D2B.9090009@gmail.com> Date: Thu, 01 Aug 2013 10:32:43 +0200 From: Mattia Rossi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Ian Lepore Subject: Re: Kernel Panic on DREAMPLUG: Alignment Fault 1 References: <51F92F79.9010809@gmail.com> <1375309907.45247.185.camel@revolution.hippie.lan> <51F9C81A.7000106@gmail.com> <1375358623.45247.189.camel@revolution.hippie.lan> In-Reply-To: <1375358623.45247.189.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 12:32:48 -0000 On 01/08/13 14:03, Ian Lepore wrote: > On Thu, 2013-08-01 at 04:29 +0200, Mattia Rossi wrote: >> On 01/08/13 00:31, Ian Lepore wrote: >>> On Wed, 2013-07-31 at 17:38 +0200, Mattia Rossi wrote: >>>> Hi all, >>>> >>>> this might be related to the WLI-UC-GNM Alignment Fault, but definitely >>>> has nothing to do with Wireless LAN. >>>> It rather seems that there's a problem with the USB subsystem. >>>> >>>> See dmesg an backtrace below. >>>> [snip] >>>> >>>> Currently trying to find where the issue could be. >>>> >>>> Mat >>> This is a strange abort, and if it's usb-related that's only accidental >>> I think. It says it's an alignment fault, but the fault address reg has >>> a 32-bit aligned value in it. That makes me think it must be an >>> ldrd/strd instruction (requires 64-bit alignment) that's faulting. >>> >>> Is this compiled with clang? I think it emits such instructions and gcc >>> doesn't. Except I don't think clang should use those instructions on >>> armv5, because of the alignment requirements. >>> >>> -- Ian >> Hi Ian, >> >> sorry, forgot to add that contrary to the WLI-UC-GNM problem, I'm still >> compiling using gcc on FreeBSD 9.1 >> >> The abort is completely reproducible each time at the same place... >> I've tried to recompile the kernel a few times, also changing the root >> device, but it gets stuck there and aborts.. >> >> I actually have no clue on what's going on here. Any hints on how to get >> more information about this? >> >> Cheers, >> >> Mat > Actually, it looks like you're using clang (I keep forgetting this comes > out in dmesg now): > >>> FreeBSD 10.0-CURRENT #9 r253846M: Wed Jul 31 17:24:31 CEST 2013 >>> root@freebsd9.1-base:/usr/obj/arm.arm/usr/devel/dreamplug/sys/DREAMPLUG-100m >>> FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 > Is the 'M' in r253846M anything significant? > > I haven't built for dreamplug in a long time (I haven't done much of > anything with computers for several months). I'll get a build going and > see if I get the same kind of problems. > > -- Ian > Gee... I guess I'm using CLANG then... So, this messes a bit with my understanding of the relation of host and guest... I always thought, that the host system decides which compiler gets used for cross-compiling, and not the guest (which means the source tree) So If my default compiler is gcc on the host, everything should be compiled with gcc. Given that I haven't changed anything of that, how comes that the kernel is compiled using clang? Especially given that the clang version on the host will not be a very up-to-date version? Or does clang get built during the make process, and then used as the compiler? Anyhow, I'll try to compile with gcc, and see what happens. Cheers, Mat From owner-freebsd-arm@FreeBSD.ORG Thu Aug 1 13:28:37 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1DF5F9F8 for ; Thu, 1 Aug 2013 13:28:37 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D40D122D8 for ; Thu, 1 Aug 2013 13:28:36 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1V4svj-000LeB-Qg; Thu, 01 Aug 2013 13:28:35 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r71DSXNA021384; Thu, 1 Aug 2013 07:28:33 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19JP1tVjxH66LMUfTUqxMYi Subject: Re: Kernel Panic on DREAMPLUG: Alignment Fault 1 From: Ian Lepore To: Mattia Rossi In-Reply-To: <51FA1D2B.9090009@gmail.com> References: <51F92F79.9010809@gmail.com> <1375309907.45247.185.camel@revolution.hippie.lan> <51F9C81A.7000106@gmail.com> <1375358623.45247.189.camel@revolution.hippie.lan> <51FA1D2B.9090009@gmail.com> Content-Type: text/plain; charset="us-ascii" Date: Thu, 01 Aug 2013 07:28:33 -0600 Message-ID: <1375363713.45247.193.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 13:28:37 -0000 On Thu, 2013-08-01 at 10:32 +0200, Mattia Rossi wrote: > On 01/08/13 14:03, Ian Lepore wrote: > > On Thu, 2013-08-01 at 04:29 +0200, Mattia Rossi wrote: > >> On 01/08/13 00:31, Ian Lepore wrote: > >>> On Wed, 2013-07-31 at 17:38 +0200, Mattia Rossi wrote: > >>>> Hi all, > >>>> > >>>> this might be related to the WLI-UC-GNM Alignment Fault, but definitely > >>>> has nothing to do with Wireless LAN. > >>>> It rather seems that there's a problem with the USB subsystem. > >>>> > >>>> See dmesg an backtrace below. > >>>> [snip] > >>>> > >>>> Currently trying to find where the issue could be. > >>>> > >>>> Mat > >>> This is a strange abort, and if it's usb-related that's only accidental > >>> I think. It says it's an alignment fault, but the fault address reg has > >>> a 32-bit aligned value in it. That makes me think it must be an > >>> ldrd/strd instruction (requires 64-bit alignment) that's faulting. > >>> > >>> Is this compiled with clang? I think it emits such instructions and gcc > >>> doesn't. Except I don't think clang should use those instructions on > >>> armv5, because of the alignment requirements. > >>> > >>> -- Ian > >> Hi Ian, > >> > >> sorry, forgot to add that contrary to the WLI-UC-GNM problem, I'm still > >> compiling using gcc on FreeBSD 9.1 > >> > >> The abort is completely reproducible each time at the same place... > >> I've tried to recompile the kernel a few times, also changing the root > >> device, but it gets stuck there and aborts.. > >> > >> I actually have no clue on what's going on here. Any hints on how to get > >> more information about this? > >> > >> Cheers, > >> > >> Mat > > Actually, it looks like you're using clang (I keep forgetting this comes > > out in dmesg now): > > > >>> FreeBSD 10.0-CURRENT #9 r253846M: Wed Jul 31 17:24:31 CEST 2013 > >>> root@freebsd9.1-base:/usr/obj/arm.arm/usr/devel/dreamplug/sys/DREAMPLUG-100m > >>> FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 > > Is the 'M' in r253846M anything significant? > > > > I haven't built for dreamplug in a long time (I haven't done much of > > anything with computers for several months). I'll get a build going and > > see if I get the same kind of problems. > > > > -- Ian > > > Gee... I guess I'm using CLANG then... > So, this messes a bit with my understanding of the relation of host and > guest... > I always thought, that the host system decides which compiler gets used > for cross-compiling, and not the guest (which means the source tree) > So If my default compiler is gcc on the host, everything should be > compiled with gcc. > Given that I haven't changed anything of that, how comes that the kernel > is compiled using clang? > Especially given that the clang version on the host will not be a very > up-to-date version? > Or does clang get built during the make process, and then used as the > compiler? > > Anyhow, I'll try to compile with gcc, and see what happens. The host system's compiler (gcc in your case) is used to build the selected compiler from src/, then that new compiler is used to build the rest of src/ into a runnable system. You can define WITHOUT_CLANG_IS_CC and WITHOUT_EABI to use gcc, and you should probably add WITHOUT_CLANG to avoid building it since it won't be used (and it takes forever to build). After rebuilding with clang/eabi I get exactly the same crash in the same spot (even the same fault address). I'll see if I can figure out what the actual problem is. -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Aug 1 14:20:00 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AC5DF9DC for ; Thu, 1 Aug 2013 14:20:00 +0000 (UTC) (envelope-from zbb@semihalf.com) Received: from mail-qe0-f46.google.com (mail-qe0-f46.google.com [209.85.128.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 61AED25BD for ; Thu, 1 Aug 2013 14:20:00 +0000 (UTC) Received: by mail-qe0-f46.google.com with SMTP id i11so1143066qej.33 for ; Thu, 01 Aug 2013 07:19:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=N7aqLEQhpjXMBGamK2PKgHPkbLDx+X0KYwkPXgq4xh8=; b=BD156R5R0kdBLwCHFXFcJ7wmCR6qWHeAyMXnDh0Hoo9nMUsrDt5FYb319GWrZzOdVn xkIzTGS+ogYhYm8PACAwoCN6ZcU29JzwygdErc88N/ihVXmTodIFNvTNVquEAFEs3XlR /FW+EofX/4bY5ZucVcCXshtFSb9Bj/et1Rs2wT8uG4RbNrexZNJ9Jz7JITOcsqx04U9Y 0wcPQoAnFb5kTwKswyr0YxsvJX6NCk4lfP7Pnxw5X1kYFsnf/1kSX/gHsc6d0XCSTWoi gzseGRhAyc+eV2L6vVCVaLshRpG3kNbB4qbya9vboCwz6F+LKkm5jlyUSWxXVIPALpcr 2zbw== MIME-Version: 1.0 X-Received: by 10.49.12.114 with SMTP id x18mr2502043qeb.25.1375366793092; Thu, 01 Aug 2013 07:19:53 -0700 (PDT) Received: by 10.49.82.34 with HTTP; Thu, 1 Aug 2013 07:19:52 -0700 (PDT) In-Reply-To: <51F68F58.8060600@semihalf.com> References: <519B6B1C.9060008@semihalf.com> <20130522184232.GA437@jail.io> <519E0D62.5030708@semihalf.com> <51CC4CC1.4020509@semihalf.com> <51D57456.9080504@semihalf.com> <51F68F58.8060600@semihalf.com> Date: Thu, 1 Aug 2013 16:19:52 +0200 Message-ID: Subject: Re: New pmap-v6.c features and improvements From: Zbigniew Bodek To: "freebsd-arm@freebsd.org" Content-Type: multipart/mixed; boundary=047d7b6d817c23711004e2e389b7 X-Gm-Message-State: ALoCoQmt9OynHG/1fZatD91v0V/OmZtQvWIJpF/1Q/cYqWGkT/fnjEZAybrHe+UWMtLnwxa01nUF X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: ray@freebsd.org, Alan Cox X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 14:20:00 -0000 --047d7b6d817c23711004e2e389b7 Content-Type: text/plain; charset=ISO-8859-1 2013/7/29 Zbyszek Bodek > On 04.07.2013 19:34, Warner Losh wrote: > > > > On Jul 4, 2013, at 7:10 AM, Zbyszek Bodek wrote: > > > >> On 27.06.2013 16:31, Zbyszek Bodek wrote: > >>> On 23.05.2013 14:36, Zbyszek Bodek wrote: > >>>> On 22.05.2013 20:42, Ruslan Bukin wrote: > >>>>> On Tue, May 21, 2013 at 02:39:56PM +0200, Zbyszek Bodek wrote: > >>>>>> Hello Everyone, > >>>>>> > >>>>>> I would like to introduce another pack of patches for pmap-v6.c and > >>>>>> related, that we created as a part of Semihalf work on Superpages > >>>>>> support. > >>>>>> > >>>>>> The patches include some major changes like: > >>>>>> > >>>>>> - Switch to AP[1:0] access permissions model > >>>>>> - Transition of the mapping related flags to PTE (stop using PVF_ > flags > >>>>>> in pv_entry) > >>>>>> - Rework of the pmap_enter_locked() function > >>>>>> - pmap code optimizations > >>>>>> > >>>>>> And some minor clean-ups: > >>>>>> > >>>>>> - Get rid of the VERBOSE_INIT_ARM option > >>>>>> - Clean-ups, style and naming improvements to pmap > >>>>>> > >>>>>> Please check out the attachment for details. > >>>>>> > >>>>>> I will be happy to answer your questions and doubts if any. > >>>>>> > >>>>>> Best regards > >>>>>> Zbyszek Bodek > >>>>> > >>>>> I tested new patches with exynos5 and everything is OK. > >>>>> (I mean all works as usual) > >>>>> > >>>> > >>>> Hello. > >>>> > >>>> I'm happy to announce that code has been integrated to the FreeBSD > HEAD. > >>>> Great thanks your help! > >>>> > >>> > >>> Hello Everyone, > >>> > >>> We have two micro patches for pmap-v6.c containing fix for 'modified' > >>> bit emulation and removal of the redundant PGA_WRITEABLE clearing. > >>> > >>> Please check out the attachment. > >>> > >>> These two are minimal changes and we would like to commit them soon, so > >>> we would be grateful if you could test them on your ARMv6/v7 platforms > >>> and give us your remarks. > >>> > >> > >> Hello, > >> > >> Because there were no objections, we've integrated the patches: > >> > >> http://svnweb.freebsd.org/base?view=revision&revision=252694 > >> http://svnweb.freebsd.org/base?view=revision&revision=252695 > > > Hello Everyone, > > I'm sending another set of fixes for pmap-v6.c > Please see attachment. > > 0012 - Removal of the costly, frequent sweeping through the > pv_entries whenever pmap_nuke_pv(), pmap_modify_pv(), etc. > are called. This also makes order with clearing PGA_WRITEABLE > aflag as well as with the pmap_statistics related to the > wired_count. > 0013 - Fix for pamp_set_prot() where not all of the protection bits were > cleared before the actual configuration. L2_XN is not icluded to > the L2_S_PROT mask to maintain consistency between PROT_MASKS for > L2 and L1 descriptors - contain only kernel/user and > read/write permissions bits. > 0014 - Fix for pmap_change_wiring() where "wired" indicator of type > boolean was being used as a "wired flag" passed to > pmap_modify_pv() which was obviously not a valid PVF_WIRED flag. > > Please test those patches on your ARM-based machines and send your > feedback. We will also appreciate your reviews and remarks. > > Thank you in advance for your help. > > Hello, Are there any updates in this topic? In addition, I'm attaching two more minor improvements, this time: 0015 - small clean-ups in pmap_clearbit() that in general gives one relevant improvement which is to skip redundant "dirty" setting for a page. 0016 - removal of the unused pv_kva field from the md_page structure If there are no objections to that and earlier presented changes we would like to integrate them to the HEAD soon. Best regards Zbyszek Bodek --047d7b6d817c23711004e2e389b7 Content-Type: application/octet-stream; name="0015-Simplify-and-clean-up-redundant-statements-from-ARMv.patch" Content-Disposition: attachment; filename="0015-Simplify-and-clean-up-redundant-statements-from-ARMv.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hju1ukq03 RnJvbSBmOTJmNjgyMDJkNmRhZTRiMzBkNmJkODhjYTc5YjNiMjI2ZWEwY2RhIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBaYmlnbmlldyBCb2RlayA8emJiQHNlbWloYWxmLmNvbT4KRGF0 ZTogTW9uLCAyOSBKdWwgMjAxMyAxOToxODoyMiArMDIwMApTdWJqZWN0OiBbUEFUQ0ggMS8yXSBT aW1wbGlmeSBhbmQgY2xlYW4tdXAgcmVkdW5kYW50IHN0YXRlbWVudHMgZnJvbSBBUk12Ni92Nwog cG1hcF9jbGVhcmJpdCgpCgpQVkZfTU9EIGlzIGFuIHVudXNlZCBmbGFnIGtlcHQganVzdCB0byBp bmRpY2F0ZSB3aGF0IGlzIHRvIGJlIGNsZWFyZWQKc2luY2UgUFRFJ3MgTDJfQVBYIHNob3dzIG1v ZGlmaWNhdGlvbiBzdGF0dXMuIFdoYXQgbW9yZSwgdGhlcmUgaXMgbm8gbmVlZApmb3IgY2FsbGlu ZyB2bV9wYWdlX2RpcnR5KCkgd2hlbiBjbGVhcmluZyAibW9kaWZpZWQiIGZsYWcgYXMgaXQgaXMg YWxyZWFkeQpzZXQgZm9yIHRoYXQgcGFnZSBpbiBwbWFwX2ZhdWx0X2ZpeHVwKCkgb3IgcG1hcF9l bnRlcigpIHRoYW5rcyB0bwoibW9kaWZpZWQiIGJpdCBlbXVsYXRpb24uClRoZXJlIGlzIGFsc28g bm8gbmVlZCBmb3IgY2hlY2tpbmcgUFRFJ3MgInJlZmVyZW5jZWQiIG9yICJ3cml0ZWFibGUiIGZs YWdzLgpJZiB0aGVyZSBpcyBhIHJlcXVlc3QgdG8gY2xlYXIgYSBwYXJ0aWN1bGFyIGZsYWcsIGp1 c3QgZG8gaXQuCgpTdWJtaXR0ZWQgYnk6ICAgWmJpZ25pZXcgQm9kZWsgPHpiYkBzZW1paGFsZi5j b20+ClNwb25zb3JlZCBieTogICBUaGUgRnJlZUJTRCBGb3VuZGF0aW9uLCBTZW1paGFsZgotLS0K IHN5cy9hcm0vYXJtL3BtYXAtdjYuYyB8IDkgKystLS0tLS0tCiAxIGZpbGUgY2hhbmdlZCwgMiBp bnNlcnRpb25zKCspLCA3IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL3N5cy9hcm0vYXJtL3Bt YXAtdjYuYyBiL3N5cy9hcm0vYXJtL3BtYXAtdjYuYwppbmRleCAzMTQyZjU2Li4yODUyZjEyIDEw MDY0NAotLS0gYS9zeXMvYXJtL2FybS9wbWFwLXY2LmMKKysrIGIvc3lzL2FybS9hcm0vcG1hcC12 Ni5jCkBAIC05MDAsOSArOTAwLDYgQEAgcG1hcF9jbGVhcmJpdChzdHJ1Y3Qgdm1fcGFnZSAqbSwg dV9pbnQgbWFza2JpdHMpCiAKIAlyd193bG9jaygmcHZoX2dsb2JhbF9sb2NrKTsKIAotCWlmICht YXNrYml0cyAmIFBWRl9XUklURSkKLQkJbWFza2JpdHMgfD0gUFZGX01PRDsKLQogCWlmIChUQUlM UV9FTVBUWSgmbS0+bWQucHZfbGlzdCkpIHsKIAkJcndfd3VubG9jaygmcHZoX2dsb2JhbF9sb2Nr KTsKIAkJcmV0dXJuICgwKTsKQEAgLTkyNCwxNCArOTIxLDEyIEBAIHBtYXBfY2xlYXJiaXQoc3Ry dWN0IHZtX3BhZ2UgKm0sIHVfaW50IG1hc2tiaXRzKQogCQlwdGVwID0gJmwyYi0+bDJiX2t2YVts MnB0ZV9pbmRleCh2YSldOwogCQlucHRlID0gb3B0ZSA9ICpwdGVwOwogCi0JCWlmICgobWFza2Jp dHMgJiAoUFZGX1dSSVRFfFBWRl9NT0QpKSAmJiBMMl9TX1dSSVRBQkxFKG9wdGUpKSB7Ci0JCQl2 bV9wYWdlX2RpcnR5KG0pOwotCisJCWlmIChtYXNrYml0cyAmIChQVkZfV1JJVEUgfCBQVkZfTU9E KSkgewogCQkJLyogbWFrZSB0aGUgcHRlIHJlYWQgb25seSAqLwogCQkJbnB0ZSB8PSBMMl9BUFg7 CiAJCX0KIAotCQlpZiAoKG1hc2tiaXRzICYgUFZGX1JFRikgJiYgTDJfU19SRUZFUkVOQ0VEKG9w dGUpKSB7CisJCWlmIChtYXNrYml0cyAmIFBWRl9SRUYpIHsKIAkJCS8qCiAJCQkgKiBDbGVhciBy ZWZlcmVuY2VkIGZsYWcgaW4gUFRFIHNvIHRoYXQgd2UKIAkJCSAqIHdpbGwgdGFrZSBhIGZsYWcg ZmF1bHQgdGhlIG5leHQgdGltZSB0aGUgbWFwcGluZwotLSAKMS44LjIKCg== --047d7b6d817c23711004e2e389b7 Content-Type: application/octet-stream; name="0016-Stop-using-redundant-pv_kva-field-in-md_page-structu.patch" Content-Disposition: attachment; filename="0016-Stop-using-redundant-pv_kva-field-in-md_page-structu.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hju1urxm4 RnJvbSAyNzhkNThjNDFkMjQxNDc0MjhlMWE5YjkxYWY0OGRlOTJkMDA3MWE2IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBaYmlnbmlldyBCb2RlayA8emJiQHNlbWloYWxmLmNvbT4KRGF0 ZTogV2VkLCAzMSBKdWwgMjAxMyAxOToxOToyOCArMDIwMApTdWJqZWN0OiBbUEFUQ0ggMi8yXSBT dG9wIHVzaW5nIHJlZHVuZGFudCBwdl9rdmEgZmllbGQgaW4gbWRfcGFnZSBzdHJ1Y3R1cmUKIGZv ciBBUk12Ni92NwoKVGhpcyB2YXJpYWJsZSBpcyBjb21wbGl0ZWx5IHVzZWxlc3MgaW4gY3VycmVu dCBwbWFwLXY2LmMgaW1wbGVtZW50YXRpb24sCmhlbmNlIGRlbGV0ZSBpdCB0byBzYXZlIHNvbWUg c3BhY2Ugb24gZWFjaCB2bV9wYWdlLgoKU3VibWl0dGVkIGJ5OiAgIFpiaWduaWV3IEJvZGVrIDx6 YmJAc2VtaWhhbGYuY29tPgpTcG9uc29yZWQgYnk6ICAgVGhlIEZyZWVCU0QgRm91bmRhdGlvbiwg U2VtaWhhbGYKLS0tCiBzeXMvYXJtL2FybS9wbWFwLXY2LmMgIHwgMiArLQogc3lzL2FybS9pbmNs dWRlL3BtYXAuaCB8IDIgKysKIDIgZmlsZXMgY2hhbmdlZCwgMyBpbnNlcnRpb25zKCspLCAxIGRl bGV0aW9uKC0pCgpkaWZmIC0tZ2l0IGEvc3lzL2FybS9hcm0vcG1hcC12Ni5jIGIvc3lzL2FybS9h cm0vcG1hcC12Ni5jCmluZGV4IDI4NTJmMTIuLmFlZjRjZTMgMTAwNjQ0Ci0tLSBhL3N5cy9hcm0v YXJtL3BtYXAtdjYuYworKysgYi9zeXMvYXJtL2FybS9wbWFwLXY2LmMKQEAgLTQzNjgsNiArNDM2 OCw2IEBAIHBtYXBfcGFnZV9zZXRfbWVtYXR0cih2bV9wYWdlX3QgbSwgdm1fbWVtYXR0cl90IG1h KQogCSAqIHVuY2FjaGVhYmxlLCBiZWluZyBjYXJlZnVsIHRvIHN5bmMgY2FjaGVzIGFuZCBQVEVz IChhbmQgbWF5YmUKIAkgKiBpbnZhbGlkYXRlIFRMQj8pIGZvciBhbnkgY3VycmVudCBtYXBwaW5n IGl0IG1vZGlmaWVzLgogCSAqLwotCWlmIChtLT5tZC5wdl9rdmEgIT0gMCB8fCBUQUlMUV9GSVJT VCgmbS0+bWQucHZfbGlzdCkgIT0gTlVMTCkKKwlpZiAoVEFJTFFfRklSU1QoJm0tPm1kLnB2X2xp c3QpICE9IE5VTEwpCiAJCXBhbmljKCJDYW4ndCBjaGFuZ2UgbWVtYXR0ciBvbiBwYWdlIHdpdGgg ZXhpc3RpbmcgbWFwcGluZ3MiKTsKIH0KZGlmZiAtLWdpdCBhL3N5cy9hcm0vaW5jbHVkZS9wbWFw LmggYi9zeXMvYXJtL2luY2x1ZGUvcG1hcC5oCmluZGV4IGI0MTYxNjkuLjc4MGVkOWIgMTAwNjQ0 Ci0tLSBhL3N5cy9hcm0vaW5jbHVkZS9wbWFwLmgKKysrIGIvc3lzL2FybS9pbmNsdWRlL3BtYXAu aApAQCAtMTIxLDcgKzEyMSw5IEBAIHN0cnVjdAlwdl9jaHVuazsKIHN0cnVjdAltZF9wYWdlIHsK IAlpbnQgcHZoX2F0dHJzOwogCXZtX21lbWF0dHJfdAkgcHZfbWVtYXR0cjsKKyNpZiAoQVJNX01N VV9WNiArIEFSTV9NTVVfVjcpID09IDAKIAl2bV9vZmZzZXRfdCBwdl9rdmE7CQkvKiBmaXJzdCBr ZXJuZWwgVkEgbWFwcGluZyAqLworI2VuZGlmCiAJVEFJTFFfSEVBRCgscHZfZW50cnkpCXB2X2xp c3Q7CiB9OwogCi0tIAoxLjguMgoK --047d7b6d817c23711004e2e389b7-- From owner-freebsd-arm@FreeBSD.ORG Thu Aug 1 15:34:49 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CB099356 for ; Thu, 1 Aug 2013 15:34:49 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 95B622AAE for ; Thu, 1 Aug 2013 15:34:49 +0000 (UTC) Received: by mail-oa0-f50.google.com with SMTP id i4so4739887oah.9 for ; Thu, 01 Aug 2013 08:34:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2e8xs+ol2KF7azkDxWEP0Bbn/wlRlnZ70vVRQuqON58=; b=P3Y9CS9ZMci1Y2CdwzEjFozlrZsK0Kjaqt6F3ctUVuxzUS4+V9fqD5ALj+7OnkGsOf 5RU6D0+j59npSxpy2mTwWYQhCPI+mDbu2pkAUjXdsGQc1XmrngvcIX38Ymmfz91zjqk4 EWfYcrAoEqX8cNCVlN7IA9MzZQVLENRSFnxlNgdZuOcKdphGCMfXu86m4WNzA6RKYD53 qqfJHqXYdHEZdrlev82irfF7z4s6N17LDdQKOFLXZ6qmQG1HYuXj7nXZERmWPcW64+p8 gB7DVNKDAKD4wOEQw5aZh1+clZrQZ8Mc3YYk9YxIGvB12PCZxTxVxoSsaR85A/gPsWQQ 4t/Q== MIME-Version: 1.0 X-Received: by 10.43.74.74 with SMTP id yv10mr209304icb.67.1375371288589; Thu, 01 Aug 2013 08:34:48 -0700 (PDT) Received: by 10.64.235.239 with HTTP; Thu, 1 Aug 2013 08:34:48 -0700 (PDT) In-Reply-To: References: Date: Thu, 1 Aug 2013 23:34:48 +0800 Message-ID: Subject: Re: Cubieboard2 and FreeBSD From: Ganbold Tsagaankhuu To: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 15:34:49 -0000 Hi, On Thu, Aug 1, 2013 at 11:14 PM, Roger Pau Monn=E9 wrote: > Hello, > > I saw your email on freebsd-arm mailing lists and I was wondering if > you could share how did you manage to get FreeBSD running on it. I > also have one of this boards, but I'm not really familiar with the arm > world so I'm a little bit lost about were to start (without using a > pre-made img). > For now you can follow instructions at https://wiki.freebsd.org/FreeBSD/arm/Cubieboard to build kernel and image for cubieboard2. Replace CUBIEBOARD to CUBIEBOARD2 there. You should use sunxi-spl.bin and u-boot.bin different from cubieboard, you can get them from http://androtab.info/cubieboard2/ For necessary A20 src, copy https://github.com/tsgan/allwinner_a10/tree/master/a20 files to appropriate places: CUBIEBOARD2 to /usr/src/sys/arm/conf/, cubieboard2.dts to /usr/src/sys/boot/fdt/dts/, rest of files (except dmesg.txt) to /usr/src/sys/arm/allwinner/a20/ You have to have src tree in order to build kernel and image. hth, Ganbold > > Thanks, Roger. > From owner-freebsd-arm@FreeBSD.ORG Thu Aug 1 16:14:09 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1B2BE4B0; Thu, 1 Aug 2013 16:14:09 +0000 (UTC) (envelope-from mattia.rossi.mate@gmail.com) Received: from mail-bk0-x232.google.com (mail-bk0-x232.google.com [IPv6:2a00:1450:4008:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 592C12CF1; Thu, 1 Aug 2013 16:14:08 +0000 (UTC) Received: by mail-bk0-f50.google.com with SMTP id ik8so755654bkc.37 for ; Thu, 01 Aug 2013 09:14:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=PueRKxLnd59rjuyj6dpzgc7gvnpI9r8j+EU2BcFrHBE=; b=0lDuafiDXw8ZIYvPAo2yq4XtXwKQ4gr1FJd5fN/AA3rtSO1uUqdj9pIiEVXjW5O8B2 8xfyuwUhTTy3D9fUDVwiQ11KwQPHH5O4ltGznhj0vz1eKSKjq/eSdGJ+7jnf2ct8nQa4 2s+7G3NRzJ92/sF085C7O8/Pp3/niPqaTpKPRYDNMn5SYO4KvoY6793Cv0ViAHfAvWM2 hL+0WYe+g0sxvhNghF+Z7y9zcIzEJr3zJMvGaayeTxjEBdiESnCFg6h9hPJEQQ/HjXUd +/NAn491EBTLyKm8iQWnDeUxKLMa5kONOeXMNt0Ahs/jYtkrw7qqoQiKR6ApZJ9Q4oTO V9Zg== X-Received: by 10.204.183.16 with SMTP id ce16mr522971bkb.172.1375373646377; Thu, 01 Aug 2013 09:14:06 -0700 (PDT) Received: from [10.185.11.70] ([46.189.28.44]) by mx.google.com with ESMTPSA id if11sm948818bkc.15.2013.08.01.09.13.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 01 Aug 2013 09:14:05 -0700 (PDT) Message-ID: <51FA8946.8030301@gmail.com> Date: Thu, 01 Aug 2013 18:13:58 +0200 From: Mattia Rossi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Ian Lepore Subject: Re: Kernel Panic on DREAMPLUG: Alignment Fault 1 References: <51F92F79.9010809@gmail.com> <1375309907.45247.185.camel@revolution.hippie.lan> <51F9C81A.7000106@gmail.com> <1375358623.45247.189.camel@revolution.hippie.lan> <51FA1D2B.9090009@gmail.com> <1375363713.45247.193.camel@revolution.hippie.lan> In-Reply-To: <1375363713.45247.193.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mattia.rossi.mate@gmail.com List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 16:14:09 -0000 On 01/08/13 15:28, Ian Lepore wrote: > On Thu, 2013-08-01 at 10:32 +0200, Mattia Rossi wrote: >> >> >> Anyhow, I'll try to compile with gcc, and see what happens. > The host system's compiler (gcc in your case) is used to build the > selected compiler from src/, then that new compiler is used to build the > rest of src/ into a runnable system. You can define WITHOUT_CLANG_IS_CC > and WITHOUT_EABI to use gcc, and you should probably add WITHOUT_CLANG > to avoid building it since it won't be used (and it takes forever to > build). Kernel built with gcc: ## Starting application at 0x00900000 ... 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 #0 r253858M: Thu Aug 1 12:49:56 CEST 2013 root@freebsd9.1-base:/usr/obj/arm.arm/usr/devel/dreamplug/sys/DREAMPLUG-100m gcc version 4.2.1 20070831 patched [FreeBSD] WARNING: DIAGNOSTIC option enabled, expect reduced performance. CPU: Feroceon 88FR131 rev 1 (Marvell core) Little-endian DC enabled IC enabled WA disabled DC streaming enabled BTB disabled L2 enabled L2 prefetch enabled WB enabled EABT branch prediction enabled 16KB/32B 4-way instruction cache 16KB/32B 4-way write-back-locking-C data cache real memory = 536870912 (512 MB) avail memory = 511025152 (487 MB) SOC: Marvell 88F6281 rev A1, TClock 200MHz Instruction cache prefetch disabled, data cache prefetch disabled 256KB 4-way set-associative write-through unified L2 cache random device not loaded; using insecure entropy localbus0: on fdtbus0 simplebus0: on fdtbus0 ic0: mem 0xf1020200-0xf102023b on sim0 timer0: mem 0xf1020300-0xf102032f irq 1 on simplebus0 Event timer "CPUTimer0" frequency 200000000 Hz quality 1000 Timecounter "CPUTimer1" frequency 200000000 Hz quality 1000 gpio0: mem 0xf1010100-0xf101011f irq 35,360 rtc0: mem 0xf1010300-0xf1010307 on simplebus0 twsi0: mem 0xf1011000-0xf101101f irq 430 iicbus0: on twsi0 iic0: on iicbus0 mge0: mem 0xf1072000-0xf1073fff irq 12,130 mge0: Ethernet address: f0:ad:4e:00:84:c7 miibus0: on mge0 e1000phy0: PHY 0 on miibus0 e1000phy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 10o mge1: mem 0xf1076000-0xf1077fff irq 16,170 mge1: Ethernet address: f0:ad:4e:00:84:c8 miibus1: on mge1 e1000phy1: PHY 1 on miibus1 e1000phy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 10o uart0: <16550 or compatible> mem 0xf1012000-0xf101201f irq 33 on simplebus0 uart0: console (1056,n,8,1) uart1: <16550 or compatible> mem 0xf1012100-0xf101211f irq 34 on simplebus0 cesa0: mem 0xf1030000-00 ehci0: mem 0xf1050000-0xf1050fff irq 480 usbus0: EHCI version 1.0 usbus0: stop timeout usbus0: set host controller mode usbus0 on ehci0 mvs0: mem 0xf1080000-0xf1085fff irq 21 on sim0 mvs0: Gen-IIe, 2 3Gbps ports, Port Multiplier supported with FBS mvsch0: at channel 0 on mvs0 mvsch1: at channel 1 on mvs0 cryptosoft0: Timecounters tick every 10.000 msec IPsec: Initialized Security Association Processing. ipfw2 (+ipv6) initialized, divert enabled, nat enabled, default to accept, loggd DUMMYNET 0 with IPv6 initialized (100409) load_dn_sched dn_sched FIFO loaded load_dn_sched dn_sched PRIO loaded load_dn_sched dn_sched QFQ loaded load_dn_sched dn_sched RR loaded load_dn_sched dn_sched WF2Q+ loaded Fatal kernel mode data abort: 'Alignment Fault 1' trapframe: 0xde450d68 FSR=00000001, FAR=de450de4, spsr=60000093 r0 =10bec341, r1 =f1020300, r2 =0000001c, r3 =c34fe400 r4 =c0e68fe8, r5 =de450ddc, r6 =798ee230, r7 =00000015 r8 =c33ef400, r9 =00000000, r10=c0e4db78, r11=00000001 r12=c0e68bd4, ssp=de450db4, slr=c0d1bbd4, pc =c0aad40c [ thread pid 0 tid 100035 ] Stopped at binuptime+0x38: und 0xe1c580d8 db> bt Tracing pid 0 tid 100035 td 0xc376f000 db_trace_self() at db_trace_self pc = 0xc0d00484 lr = 0xc0d00510 (db_trace_thread+0x50) sp = 0xde450a40 fp = 0x00000001 db_trace_thread() at db_trace_thread+0x50 pc = 0xc0d00510 lr = 0xc093f88c (db_command_init+0x618) sp = 0xde450aa0 fp = 0x00000001 db_command_init() at db_command_init+0x618 pc = 0xc093f88c lr = 0xc093ef6c (db_skip_to_eol+0x484) sp = 0xde450ab8 fp = 0x00000001 r4 = 0xc0e2b3f8 r5 = 0x00000000 db_skip_to_eol() at db_skip_to_eol+0x484 pc = 0xc093ef6c lr = 0xc093f0d4 (db_command_loop+0x5c) sp = 0xde450b58 fp = 0x00000001 r4 = 0xde450b6c r5 = 0xc0e2b6c0 r6 = 0xde450de4 r7 = 0x00000000 r8 = 0x00000001 r10 = 0x600000d3 db_command_loop() at db_command_loop+0x5c pc = 0xc093f0d4 lr = 0xc09414f8 (X_db_sym_numargs+0xec) sp = 0xde450b60 fp = 0x00000001 X_db_sym_numargs() at X_db_sym_numargs+0xec pc = 0xc09414f8 lr = 0xc0ad430c (kdb_trap+0xa4) sp = 0xde450c78 fp = 0x00000001 r4 = 0xde450d68 kdb_trap() at kdb_trap+0xa4 pc = 0xc0ad430c lr = 0xc0d113c8 (badaddr_read+0x274) sp = 0xde450c98 fp = 0x00000001 r4 = 0xde450d68 r5 = 0x00000001 r6 = 0xde450de4 r7 = 0xc376f000 r8 = 0xc33ef400 r10 = 0xde450d68 badaddr_read() at badaddr_read+0x274 pc = 0xc0d113c8 lr = 0xc0d11794 (prefetch_abort_handler+0x374) sp = 0xde450cb0 fp = 0x00000001 r4 = 0xc376f000 r5 = 0xde450d68 r6 = 0x798ee230 prefetch_abort_handler() at prefetch_abort_handler+0x374 pc = 0xc0d11794 lr = 0xc0d118e4 (data_abort_handler+0x110) sp = 0xde450cc8 fp = 0x00000001 r4 = 0xc0e8fb3c r5 = 0xffff1004 data_abort_handler() at data_abort_handler+0x110 pc = 0xc0d118e4 lr = 0xc0d01cc0 (exception_exit) sp = 0xde450d68 fp = 0x00000001 r4 = 0xffffffff r5 = 0xffff1004 r6 = 0x798ee230 r7 = 0x00000015 r8 = 0xc33ef400 r9 = 0x00000000 r10 = 0xc0e4db78 exception_exit() at exception_exit pc = 0xc0d01cc0 lr = 0xc0d1bbd4 (initarm_lastaddr+0x320) sp = 0xde450db4 fp = 0x00000001 r0 = 0x10bec341 r1 = 0xf1020300 r2 = 0x0000001c r3 = 0xc34fe400 r4 = 0xc0e68fe8 r5 = 0xde450ddc r6 = 0x798ee230 r7 = 0x00000015 r8 = 0xc33ef400 r9 = 0x00000000 r10 = 0xc0e4db78 r12 = 0xc0e68bd4 binuptime() at binuptime+0x3c pc = 0xc0aad410 lr = 0xc0d26ac4 (cpu_initclocks+0xa8d8) sp = 0xde450ddc fp = 0x00000000 r4 = 0xc0e9dc80 r5 = 0xc0e93518 r6 = 0x00000000 r7 = 0xc376f000 r8 = 0xc33ef400 r9 = 0x00000000 r10 = 0xde450e34 cpu_initclocks() at cpu_initclocks+0xa8d8 pc = 0xc0d26ac4 lr = 0xc0d1bdb8 (initarm_lastaddr+0x504) sp = 0xde450dfc fp = 0x00000000 r4 = 0xc34fe400 r5 = 0xde450e34 initarm_lastaddr() at initarm_lastaddr+0x504 pc = 0xc0d1bdb8 lr = 0xc0a7ab5c (intr_event_handle+0x7c) sp = 0xde450e04 fp = 0x00000000 r4 = 0xc3556ac0 intr_event_handle() at intr_event_handle+0x7c pc = 0xc0a7ab5c lr = 0xc0d02f24 (arm_handler_execute+0x48) sp = 0xde450e24 fp = 0x00000000 r4 = 0x00000001 r5 = 0xde450e34 r6 = 0x000003d7 r7 = 0xc0e8c8d0 r8 = 0xde450ea8 r9 = 0x00000000 r10 = 0x00000000 arm_handler_execute() at arm_handler_execute+0x48 pc = 0xc0d02f24 lr = 0xc0d173a0 (irq_entry+0x94) sp = 0xde450e34 fp = 0x00000000 r4 = 0x00000000 r5 = 0xffff1004 irq_entry() at irq_entry+0x94 pc = 0xc0d173a0 lr = 0xc0d173a0 (irq_entry+0x94) sp = 0xde450e34 fp = 0x00000000 From owner-freebsd-arm@FreeBSD.ORG Thu Aug 1 16:28:45 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9773CB2A for ; Thu, 1 Aug 2013 16:28:45 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6BFD82DD0 for ; Thu, 1 Aug 2013 16:28:45 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1V4vk4-000PKD-2e; Thu, 01 Aug 2013 16:28:44 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r71GSfcs021592; Thu, 1 Aug 2013 10:28:41 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+X0I/ciJGOitdsNyppmq8P Subject: Re: Kernel Panic on DREAMPLUG: Alignment Fault 1 From: Ian Lepore To: mattia.rossi.mate@gmail.com In-Reply-To: <51FA8946.8030301@gmail.com> References: <51F92F79.9010809@gmail.com> <1375309907.45247.185.camel@revolution.hippie.lan> <51F9C81A.7000106@gmail.com> <1375358623.45247.189.camel@revolution.hippie.lan> <51FA1D2B.9090009@gmail.com> <1375363713.45247.193.camel@revolution.hippie.lan> <51FA8946.8030301@gmail.com> Content-Type: text/plain; charset="us-ascii" Date: Thu, 01 Aug 2013 10:28:41 -0600 Message-ID: <1375374521.45247.211.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 16:28:45 -0000 On Thu, 2013-08-01 at 18:13 +0200, Mattia Rossi wrote: > On 01/08/13 15:28, Ian Lepore wrote: > > On Thu, 2013-08-01 at 10:32 +0200, Mattia Rossi wrote: > >> > >> > >> Anyhow, I'll try to compile with gcc, and see what happens. > > The host system's compiler (gcc in your case) is used to build the > > selected compiler from src/, then that new compiler is used to build the > > rest of src/ into a runnable system. You can define WITHOUT_CLANG_IS_CC > > and WITHOUT_EABI to use gcc, and you should probably add WITHOUT_CLANG > > to avoid building it since it won't be used (and it takes forever to > > build). > Kernel built with gcc: > [snip... same fault as with clang] Yep, I just had the same experience -- same fault, same place, addresses differ by a few bytes which is to be expected with a different compiler. I've just confirmed that gcc and WITHOUT_ARM_EABI=yes works fine, so the problem seems to be that we're somehow not maintaining stack alignment correctly for EABI on architectures prior to armv6. I have a feeling somewhere in the code is something conditional on ARMV6 that really needs to include armv5te (which has the ldrd/strd instructions). -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Aug 1 23:16:57 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5C65BC29 for ; Thu, 1 Aug 2013 23:16:57 +0000 (UTC) (envelope-from fun@naobsd.org) Received: from mail.naobsd.org (7c294571.i-revonet.jp [124.41.69.113]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EA715207F for ; Thu, 1 Aug 2013 23:16:53 +0000 (UTC) Received: from [192.168.1.149] ([192.168.1.149]) (authenticated bits=0) by mail.naobsd.org (8.13.6.20060614/8.13.6) with ESMTP id r71Mox71015975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 2 Aug 2013 07:51:03 +0900 (JST) Message-ID: <51FAE653.5080005@naobsd.org> Date: Fri, 02 Aug 2013 07:50:59 +0900 From: FUKAUMI Naoki User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: Cubieboard2 and FreeBSD References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 23:16:57 -0000 hi thank you for your hard work. On 08/02/2013 12:34 AM, Ganbold Tsagaankhuu wrote: > You should use sunxi-spl.bin and u-boot.bin different from cubieboard, you > can get them from http://androtab.info/cubieboard2/ these files should work, but it's already bit old ;) instruction to make spl/u-boot should be generally same as cb1. (of course source/config for cb2 is necessary) I'll update my site. (I'm owner of androtab.info) From owner-freebsd-arm@FreeBSD.ORG Fri Aug 2 04:55:25 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7877882F for ; Fri, 2 Aug 2013 04:55:25 +0000 (UTC) (envelope-from ghw@7axu.com) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0F789243F for ; Fri, 2 Aug 2013 04:55:24 +0000 (UTC) Received: by mail-wg0-f54.google.com with SMTP id n11so137187wgh.33 for ; Thu, 01 Aug 2013 21:55:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=HUC2qF0f+GHBAcNKu3NnCnvcspnDozrSYAJt2kalLJ0=; b=nRor4BA/06SdPwFWHAAWmbgFIYkcvGRNt96Hu6C2ggr7USNtWbpmQ/tI2IZi4Z2UnV caPNquyO+HwAT15AgVj85uQfqahq8z5XPvVp578p9McXUHiMyC6foV7C9JcCo4Podqmf uSSWn7ESh+t4grB0igC5MweDQ/FZ6xjRs/z8+jdsdSEcWJ0WYtPHVl1yGEVAeZ18SAE4 e6Ruc6bi6ToRwevz3/TQ4PpcXKf7yDqVk3+JM6Y3qpNfL9nBbAhcUT+uLNU2YyX/lWEV E8DN8qKc4KqcS7FocEsXZKOqBAe8aKY5WN/3/xjNMoTRazrKjL066JhMjxLomh5ziVDU h12Q== X-Received: by 10.194.7.137 with SMTP id j9mr3651470wja.11.1375419317149; Thu, 01 Aug 2013 21:55:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.93.34 with HTTP; Thu, 1 Aug 2013 21:54:36 -0700 (PDT) X-Originating-IP: [54.249.112.206] From: XiaoQI Ge Date: Fri, 2 Aug 2013 12:54:36 +0800 Message-ID: Subject: What makes the CubieBoard 1G recognition memory To: freebsd-arm Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlxWwYG/8RnZ1N6/E+t9PNiyQjHzkWKNV1Lxy73BqNbs4PcWMgm58y1vpgPSXEyQFpQJ2Es X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 04:55:25 -0000 What makes the CubieBoard 1G recognition memory I have changed it to 1G, the startup panic memory { device_type = "memory"; reg = < 0x40000000 0x40000000 >; /* 1GB RAM */ sun4i#go 0x40200100 ## Starting application at 0x40200100 ... 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 #3 r253878M: Fri Aug 2 20:40:12 CST 2013 root@FreeBSD.7axu.com:/usr/obj/arm.armv6/usr/src/sys/CBOARD arm FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 WARNING: WITNESS option enabled, expect reduced performance. CPU: Cortex A8-r3 rev 2 (Cortex-A core) Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext WB disabled EABT branch prediction enabled LoUU:2 LoC:2 LoUIS:1 Cache level 1: 32KB/64B 4-way data cache WT WB Read-Alloc 32KB/64B 4-way instruction cache Read-Alloc Cache level 2: 256KB/64B 8-way unified cache WT WB Read-Alloc Write-Alloc real memory = 1073741824 (1024 MB) panic: kmem_suballoc: bad status return of 3 KDB: enter: panic [ thread pid 0 tid 0 ] Stopped at kdb_enter+0x4c: ldrb r15, [r15, r15, ror r15]! db> bt Tracing pid 0 tid 0 td 0xc0809280 db_trace_self() at db_trace_self pc = 0xc0569ce4 lr = 0xc022c954 (db_hex2dec+0x4dc) sp = 0xc0820ae4 fp = 0xc0820afc r10 = 0xc065d670 db_hex2dec() at db_hex2dec+0x4dc pc = 0xc022c954 lr = 0xc022c2c0 (db_command_loop+0x2f0) sp = 0xc0820b04 fp = 0xc0820ba4 r4 = 0x00000000 r5 = 0x00000000 r6 = 0xc05c0331 db_command_loop() at db_command_loop+0x2f0 pc = 0xc022c2c0 lr = 0xc022c030 (db_command_loop+0x60) sp = 0xc0820bac fp = 0xc0820bbc r4 = 0xc059fddc r5 = 0xc05b9c6e r6 = 0xc0808308 r7 = 0xc0820d8c r8 = 0xc0809280 r9 = 0xc06a5c24 r10 = 0xc065d8e0 db_command_loop() at db_command_loop+0x60 pc = 0xc022c030 lr = 0xc022ea30 (X_db_symbol_values+0x254) sp = 0xc0820bc4 fp = 0xc0820ce4 r4 = 0x00000000 r5 = 0xc0820bcc r6 = 0xc06a5c4c X_db_symbol_values() at X_db_symbol_values+0x254 pc = 0xc022ea30 lr = 0xc038d9a8 (kdb_trap+0xd4) sp = 0xc0820cec fp = 0xc0820d0c r4 = 0x00000000 r5 = 0x00000001 r6 = 0xc06a5c4c r7 = 0xc0820d8c kdb_trap() at kdb_trap+0xd4 pc = 0xc038d9a8 lr = 0xc057a1e4 (undefinedinstruction+0x274) sp = 0xc0820d14 fp = 0xc0820d84 r4 = 0x00000000 r5 = 0xc0579ecc r6 = 0x00000000 r7 = 0xe7ffffff r8 = 0xc0809280 r9 = 0xc0820d8c r10 = 0xc038d29c undefinedinstruction() at undefinedinstruction+0x274 pc = 0xc057a1e4 lr = 0xc056b510 (exception_exit) sp = 0xc0820d8c fp = 0xc0820de0 r4 = 0xc05b9cc8 r5 = 0xc0820e24 r6 = 0xc05e5c3b r7 = 0xc0697b30 r8 = 0xc0809280 r9 = 0xc0697990 r10 = 0xc0809d5c exception_exit() at exception_exit pc = 0xc056b510 lr = 0xc038d290 (kdb_enter+0x40) sp = 0xc0820dd8 fp = 0xc0820de0 r0 = 0xc06a5c34 r1 = 0x00000000 r2 = 0xc05bd67d r3 = 0x000000ab r4 = 0xc05b9cc8 r5 = 0xc0820e24 r6 = 0xc05e5c3b r7 = 0xc0697b30 r8 = 0xc0809280 r9 = 0xc0697990 r10 = 0xc0809d5c r12 = 0x00000000 kdb_enter() at kdb_enter+0x50 pc = 0xc038d2a0 lr = 0xc035776c (kassert_panic+0x1c8) sp = 0xc0820de8 fp = 0xc0820e08 r4 = 0x00000100 kassert_panic() at kassert_panic+0x1c8 pc = 0xc035776c lr = 0xc03577d0 (kproc_shutdown) sp = 0xc0820e10 fp = 0xc0820e18 r4 = 0xc08ff000 r5 = 0xc0820e70 r6 = 0xc0820e6c r7 = 0x007c0000 r8 = 0xc080c268 r9 = 0xc0809ff4 r10 = 0xc080c784 kproc_shutdown() at kproc_shutdown pc = 0xc03577d0 lr = 0xc0545df0 (kmem_suballoc+0xd4) sp = 0xc0820e20 fp = 0xc0820e58 r4 = 0xc0820e24 r5 = 0xc0820e6c kmem_suballoc() at kmem_suballoc+0xd4 pc = 0xc0545df0 lr = 0xc05453c4 (vm_ksubmap_init+0x1dc) sp = 0xc0820e60 fp = 0xc0820e90 r4 = 0xc0820e70 r5 = 0xc0820e6c r6 = 0x00000000 r7 = 0x00000efe vm_ksubmap_init() at vm_ksubmap_init+0x1dc pc = 0xc05453c4 lr = 0xc056e344 (initarm+0xb98) sp = 0xc0820e98 fp = 0xc0820ed0 r4 = 0x00000001 r5 = 0xc080c264 r6 = 0x00000000 r7 = 0xc05ed988 r8 = 0x00000000 r9 = 0xc0809280 r10 = 0xc0820ef8 initarm() at initarm+0xb98 pc = 0xc056e344 lr = 0xc0308a28 (mi_startup+0x11c) sp = 0xc0820ed8 fp = 0xc0820ef0 r4 = 0x00000001 r5 = 0xc0809278 r6 = 0x00000000 r7 = 0xc05ed988 r8 = 0xc0809a84 r9 = 0xc0809a80 r10 = 0x7fe61408 mi_startup() at mi_startup+0x11c pc = 0xc0308a28 lr = 0xc0200224 (btext+0x124) sp = 0xc0820ef8 fp = 0x00000000 r4 = 0x40200264 r5 = 0x40200158 r6 = 0x00000001 r7 = 0x4020014c r8 = 0x7fe6140c r9 = 0x00000001 btext() at btext+0x124 pc = 0xc0200224 lr = 0xc0200224 (btext+0x124) sp = 0xc0820ef8 fp = 0x00000000 Unable to unwind further db> From owner-freebsd-arm@FreeBSD.ORG Fri Aug 2 05:07:48 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 384F09B9 for ; Fri, 2 Aug 2013 05:07:48 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 046D7247D for ; Fri, 2 Aug 2013 05:07:47 +0000 (UTC) Received: by mail-ob0-f170.google.com with SMTP id eh20so410183obb.1 for ; Thu, 01 Aug 2013 22:07:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ReS/oRMktOvmFiw3QrZhKkcEgrVbbSbQsALcmV4j3J0=; b=yFfxMuo17kKGrYuUK5VRMv0wHcn/Edpy0w9j9ouio8eGSjfH6ZKlzILbDM+jfEo2YH UHDaqArI65tL+QukDMuyCCsEBiLQMNFVR7/C6SwrDOoIwWLeaBh2zEdlWAgdcAajVM5O vhyZPLPq68sWNlLOKEJAv2tJyVokvxUCyIfrLc1NtWFQiRom1SOkx5VX80EDgIMTD2ux RLoGofuP+XvWYle0/dXfVjzqZu2T9FB0l1IPyrgs8F9JgfY9b0oWJotbdiLSfl3rTdOG Ar+8lAKV02dWurGpLJFU9gY3FSlS6Gp5SVU3Dzu0+u3t219zNxqgte1AkxWCuIhm4RkH 5E1A== MIME-Version: 1.0 X-Received: by 10.50.50.202 with SMTP id e10mr87578igo.54.1375420067155; Thu, 01 Aug 2013 22:07:47 -0700 (PDT) Received: by 10.64.235.239 with HTTP; Thu, 1 Aug 2013 22:07:47 -0700 (PDT) In-Reply-To: References: Date: Fri, 2 Aug 2013 13:07:47 +0800 Message-ID: Subject: Re: What makes the CubieBoard 1G recognition memory From: Ganbold Tsagaankhuu To: XiaoQI Ge Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 05:07:48 -0000 On Fri, Aug 2, 2013 at 12:54 PM, XiaoQI Ge wrote: > What makes the CubieBoard 1G recognition memory > > I have changed it to 1G, the startup panic > > memory { > device_type = "memory"; > reg = < 0x40000000 0x40000000 >; /* 1GB RAM */ > You can add following line in initarm_late_init() of a10_machdep.c: unmapped_buf_allowed = 0; as in exynos5_machdep.c. Ganbold > > sun4i#go 0x40200100 > ## Starting application at 0x40200100 ... > 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 #3 r253878M: Fri Aug 2 20:40:12 CST 2013 > root@FreeBSD.7axu.com:/usr/obj/arm.armv6/usr/src/sys/CBOARD arm > FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 > WARNING: WITNESS option enabled, expect reduced performance. > CPU: Cortex A8-r3 rev 2 (Cortex-A core) > Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext > WB disabled EABT branch prediction enabled > LoUU:2 LoC:2 LoUIS:1 > Cache level 1: > 32KB/64B 4-way data cache WT WB Read-Alloc > 32KB/64B 4-way instruction cache Read-Alloc > Cache level 2: > 256KB/64B 8-way unified cache WT WB Read-Alloc Write-Alloc > real memory = 1073741824 (1024 MB) > panic: kmem_suballoc: bad status return of 3 > KDB: enter: panic > [ thread pid 0 tid 0 ] > Stopped at kdb_enter+0x4c: ldrb r15, [r15, r15, ror r15]! > db> bt > Tracing pid 0 tid 0 td 0xc0809280 > db_trace_self() at db_trace_self > pc = 0xc0569ce4 lr = 0xc022c954 (db_hex2dec+0x4dc) > sp = 0xc0820ae4 fp = 0xc0820afc > r10 = 0xc065d670 > db_hex2dec() at db_hex2dec+0x4dc > pc = 0xc022c954 lr = 0xc022c2c0 (db_command_loop+0x2f0) > sp = 0xc0820b04 fp = 0xc0820ba4 > r4 = 0x00000000 r5 = 0x00000000 > r6 = 0xc05c0331 > db_command_loop() at db_command_loop+0x2f0 > pc = 0xc022c2c0 lr = 0xc022c030 (db_command_loop+0x60) > sp = 0xc0820bac fp = 0xc0820bbc > r4 = 0xc059fddc r5 = 0xc05b9c6e > r6 = 0xc0808308 r7 = 0xc0820d8c > r8 = 0xc0809280 r9 = 0xc06a5c24 > r10 = 0xc065d8e0 > db_command_loop() at db_command_loop+0x60 > pc = 0xc022c030 lr = 0xc022ea30 (X_db_symbol_values+0x254) > sp = 0xc0820bc4 fp = 0xc0820ce4 > r4 = 0x00000000 r5 = 0xc0820bcc > r6 = 0xc06a5c4c > X_db_symbol_values() at X_db_symbol_values+0x254 > pc = 0xc022ea30 lr = 0xc038d9a8 (kdb_trap+0xd4) > sp = 0xc0820cec fp = 0xc0820d0c > r4 = 0x00000000 r5 = 0x00000001 > r6 = 0xc06a5c4c r7 = 0xc0820d8c > kdb_trap() at kdb_trap+0xd4 > pc = 0xc038d9a8 lr = 0xc057a1e4 (undefinedinstruction+0x274) > sp = 0xc0820d14 fp = 0xc0820d84 > r4 = 0x00000000 r5 = 0xc0579ecc > r6 = 0x00000000 r7 = 0xe7ffffff > r8 = 0xc0809280 r9 = 0xc0820d8c > r10 = 0xc038d29c > undefinedinstruction() at undefinedinstruction+0x274 > pc = 0xc057a1e4 lr = 0xc056b510 (exception_exit) > sp = 0xc0820d8c fp = 0xc0820de0 > r4 = 0xc05b9cc8 r5 = 0xc0820e24 > r6 = 0xc05e5c3b r7 = 0xc0697b30 > r8 = 0xc0809280 r9 = 0xc0697990 > r10 = 0xc0809d5c > exception_exit() at exception_exit > pc = 0xc056b510 lr = 0xc038d290 (kdb_enter+0x40) > sp = 0xc0820dd8 fp = 0xc0820de0 > r0 = 0xc06a5c34 r1 = 0x00000000 > r2 = 0xc05bd67d r3 = 0x000000ab > r4 = 0xc05b9cc8 r5 = 0xc0820e24 > r6 = 0xc05e5c3b r7 = 0xc0697b30 > r8 = 0xc0809280 r9 = 0xc0697990 > r10 = 0xc0809d5c r12 = 0x00000000 > kdb_enter() at kdb_enter+0x50 > pc = 0xc038d2a0 lr = 0xc035776c (kassert_panic+0x1c8) > sp = 0xc0820de8 fp = 0xc0820e08 > r4 = 0x00000100 > kassert_panic() at kassert_panic+0x1c8 > pc = 0xc035776c lr = 0xc03577d0 (kproc_shutdown) > sp = 0xc0820e10 fp = 0xc0820e18 > r4 = 0xc08ff000 r5 = 0xc0820e70 > r6 = 0xc0820e6c r7 = 0x007c0000 > r8 = 0xc080c268 r9 = 0xc0809ff4 > r10 = 0xc080c784 > kproc_shutdown() at kproc_shutdown > pc = 0xc03577d0 lr = 0xc0545df0 (kmem_suballoc+0xd4) > sp = 0xc0820e20 fp = 0xc0820e58 > r4 = 0xc0820e24 r5 = 0xc0820e6c > kmem_suballoc() at kmem_suballoc+0xd4 > pc = 0xc0545df0 lr = 0xc05453c4 (vm_ksubmap_init+0x1dc) > sp = 0xc0820e60 fp = 0xc0820e90 > r4 = 0xc0820e70 r5 = 0xc0820e6c > r6 = 0x00000000 r7 = 0x00000efe > vm_ksubmap_init() at vm_ksubmap_init+0x1dc > pc = 0xc05453c4 lr = 0xc056e344 (initarm+0xb98) > sp = 0xc0820e98 fp = 0xc0820ed0 > r4 = 0x00000001 r5 = 0xc080c264 > r6 = 0x00000000 r7 = 0xc05ed988 > r8 = 0x00000000 r9 = 0xc0809280 > r10 = 0xc0820ef8 > initarm() at initarm+0xb98 > pc = 0xc056e344 lr = 0xc0308a28 (mi_startup+0x11c) > sp = 0xc0820ed8 fp = 0xc0820ef0 > r4 = 0x00000001 r5 = 0xc0809278 > r6 = 0x00000000 r7 = 0xc05ed988 > r8 = 0xc0809a84 r9 = 0xc0809a80 > r10 = 0x7fe61408 > mi_startup() at mi_startup+0x11c > pc = 0xc0308a28 lr = 0xc0200224 (btext+0x124) > sp = 0xc0820ef8 fp = 0x00000000 > r4 = 0x40200264 r5 = 0x40200158 > r6 = 0x00000001 r7 = 0x4020014c > r8 = 0x7fe6140c r9 = 0x00000001 > btext() at btext+0x124 > pc = 0xc0200224 lr = 0xc0200224 (btext+0x124) > sp = 0xc0820ef8 fp = 0x00000000 > Unable to unwind further > db> > _______________________________________________ > 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" > From owner-freebsd-arm@FreeBSD.ORG Fri Aug 2 06:19:15 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 02ACB83A for ; Fri, 2 Aug 2013 06:19:15 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AD3962643 for ; Fri, 2 Aug 2013 06:19:14 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r726J4bg030019; Fri, 2 Aug 2013 06:19:04 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id kpmzexjvy42qvkqfzjj8uvi2u2; Fri, 02 Aug 2013 06:19:04 +0000 (UTC) (envelope-from kientzle@freebsd.org) Subject: Re: RFC: sysutils/u-boot-beaglebone-eabi Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/signed; boundary="Apple-Mail=_5222E83A-AA62-44D2-A20A-92F681234C86"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: Tim Kientzle In-Reply-To: <1D89CA5C-4C52-4669-8239-935CE3904469@grondar.org> Date: Thu, 1 Aug 2013 23:19:03 -0700 Message-Id: References: <1D89CA5C-4C52-4669-8239-935CE3904469@grondar.org> To: Mark R V Murray X-Mailer: Apple Mail (2.1283) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 06:19:15 -0000 --Apple-Mail=_5222E83A-AA62-44D2-A20A-92F681234C86 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Aug 1, 2013, at 12:14 AM, Mark R V Murray wrote: > > On 1 Aug 2013, at 04:45, Tim Kientzle wrote: > >> P.S. By the way, to make this work, I had to add real ARM cross-compiler >> ports. We now have devel/arm-eabi-binutils and devel/arm-eabi-gcc > > Hi Tim, > > Does Clang/LLVM still not do this properly? Nothing wrong. Clang/LLVM compiles U-Boot just fine as far as I can tell. That's what I've been doing for months. But I couldn't figure out how to make that work for the U-Boot port: 1) I need a cross-compiler the u-boot port can depend on. I don't know a particularly clean way to depend on the xdev tools that I was using before. It seemed much easier to depend on another port. 2) Our port tree already had some basic framework for cross-GCC. (Remember this is typically being cross-compiled for ARM on i386 or amd64.) I had to fix that support a little to make it work correctly, but the outline was already there. 3) I didn't see anything already in ports for cross-clang. 4) The base clang has some cross-build abilities, but it's not really useful without ARM libc or binutils. Is there some other approach that I overlooked? Tim --Apple-Mail=_5222E83A-AA62-44D2-A20A-92F681234C86 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) iQEcBAEBAgAGBQJR+09YAAoJEGMNyGo0rfFBAgMH/3ZiRepufzuhtDMOrfSbQoDn ZsNzl8tIaMfKX/nhc5ExGDXP5jLR3rxgc/4styJgVQF5PSEzIErlyGAQG6uqWrhv twGYP52OIFfKLVWunounTbX81wny3OPpGJpbTfEih9tyGg6lgcTvzDOpVPRpVuDy iz1VvTzxMD7dluFszBN9XMl4fjo3XBxNOi0wQPxl7P85IQV+3Gf6ru2oQJ6jGGdQ aTcXtAqmyuE2mnaAiutpH+HEUjnlSJ9jzwBBTfP4iva1zVij8flgSmVFXQM4ZusR Q3v6nTVraFY51cw9OzuvsvvZgYlKfyTlbuNP6ivVa0SPI/e/ZBUVIhNoCywyUL4= =at/I -----END PGP SIGNATURE----- --Apple-Mail=_5222E83A-AA62-44D2-A20A-92F681234C86-- From owner-freebsd-arm@FreeBSD.ORG Fri Aug 2 06:51:48 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CEDF7FC1; Fri, 2 Aug 2013 06:51:48 +0000 (UTC) (envelope-from mark@grondar.org) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 94E592734; Fri, 2 Aug 2013 06:51:48 +0000 (UTC) Received: from graveyard.grondar.org ([88.96.155.33] helo=gronkulator.grondar.org) by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1V59DF-00093M-T5; Fri, 02 Aug 2013 07:51:47 +0100 Subject: Re: RFC: sysutils/u-boot-beaglebone-eabi Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: multipart/signed; boundary="Apple-Mail=_F319B2D2-0736-4D8D-B6A5-56FB5FE8EBCF"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark R V Murray In-Reply-To: Date: Fri, 2 Aug 2013 07:51:45 +0100 Message-Id: <9E21A020-8522-4ADB-A1ED-FD8675267FFF@grondar.org> References: <1D89CA5C-4C52-4669-8239-935CE3904469@grondar.org> To: Tim Kientzle X-Mailer: Apple Mail (2.1508) X-SA-Score: -2.2 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 06:51:48 -0000 --Apple-Mail=_F319B2D2-0736-4D8D-B6A5-56FB5FE8EBCF Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 2 Aug 2013, at 07:19, Tim Kientzle wrote: > Nothing wrong. Clang/LLVM compiles U-Boot just fine > as far as I can tell. That's what I've been doing for months. > > But I couldn't figure out how to make that work for the U-Boot port: : : > Is there some other approach that I overlooked? No, no! I was just interested, and your explanation further enlightened me. I'm getting back into FreeBSD, particularly from an imbedded perspective, and finding very little time to actually do stuff. The ARM platform is starting to do useful stuff for me, and I am trying to find out more about it. Thanks! M -- Mark R V Murray --Apple-Mail=_F319B2D2-0736-4D8D-B6A5-56FB5FE8EBCF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUftXAd58vKOKE6LNAQoJaQP/Yxgu6fny9+4VzynGnMB2FKQn1xcxCMTJ dPt2+QsMIfi6ZaryPPaScZYPVDCDOyet7xlh45YOoN3uOroT8fg7V600Tul4ZGaE 8R+Z4X/GoKphXyblvYOOHe3HCcoSIPRUyoNBh//LmXEiqPa5VYoTFQjPCuYrUOng tC+P4MeezxM= =KGVu -----END PGP SIGNATURE----- --Apple-Mail=_F319B2D2-0736-4D8D-B6A5-56FB5FE8EBCF-- From owner-freebsd-arm@FreeBSD.ORG Fri Aug 2 08:17:46 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6D8C918B for ; Fri, 2 Aug 2013 08:17:46 +0000 (UTC) (envelope-from ghw@7axu.com) Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DF7EE2AA7 for ; Fri, 2 Aug 2013 08:17:45 +0000 (UTC) Received: by mail-we0-f173.google.com with SMTP id x55so262026wes.4 for ; Fri, 02 Aug 2013 01:17:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=h0hvjx/E/m3tlYhE1rHxK2E3n3UI87+2zjQ3OJL7Wv8=; b=Hx/CuETlPX4GOBedxNfmoULvdsVhvKyxYkN72cpIW3jy726kMDabjYNJFMJ7eCwxC8 3lVg8+QMkk/wx2hrINbWuLSmrzOWWSKStdOngnzO/1+2ykWCE7sAVZrfrarRqVX6kfxx GEXF1nhcd4LtPASyNrTEc6/TuRmzPUfLwErjAkroeB34OXX8iCDr8UoUDWjOPU0dnpdV XSSG2QPvZPGx5h11MkywJhP9GEjmAP5afXZ053XEjye19MXHTKR7gA19WcX38+2oahq7 jY/BCcDU8SfNfdabjNXLxdewf4G+PEV1VOV2LbjkNDRnS9Lt3pS0/KKPFmZYgb0INcOB 67jQ== X-Received: by 10.194.20.163 with SMTP id o3mr3967079wje.53.1375428193279; Fri, 02 Aug 2013 00:23:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.93.34 with HTTP; Fri, 2 Aug 2013 00:22:33 -0700 (PDT) X-Originating-IP: [54.249.112.206] In-Reply-To: References: From: XiaoQI Ge Date: Fri, 2 Aug 2013 15:22:33 +0800 Message-ID: Subject: Re: What makes the CubieBoard 1G recognition memory To: Ganbold Tsagaankhuu Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlcBxywV9CfizLyA6gNqJm4Fs6V8bzYm1q77f6c1FXQFbF7OGJn1v37Xyv1Wq/GO0iw7/D1 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 08:17:46 -0000 Get, thank you last pid: 975; load averages: 0.42, 0.29, 0.15 up 0+00:05:57 15:21:18 14 processes: 2 running, 12 sleeping CPU: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle Mem: 17M Active, 13M Inact, 32M Wired, 13M Buf, 935M Free Swap: -- Regards. By: XiaoQI Ge; PGP:8B09D5F7 WWW: https://www.7axu.com/ 2013/8/2 Ganbold Tsagaankhuu : > On Fri, Aug 2, 2013 at 12:54 PM, XiaoQI Ge wrote: >> >> What makes the CubieBoard 1G recognition memory >> >> I have changed it to 1G, the startup panic >> >> memory { >> device_type = "memory"; >> reg = < 0x40000000 0x40000000 >; /* 1GB RAM */ > > > > You can add following line in initarm_late_init() of a10_machdep.c: > > unmapped_buf_allowed = 0; > > as in exynos5_machdep.c. > > Ganbold > > > >> >> >> sun4i#go 0x40200100 >> ## Starting application at 0x40200100 ... >> 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 #3 r253878M: Fri Aug 2 20:40:12 CST 2013 >> root@FreeBSD.7axu.com:/usr/obj/arm.armv6/usr/src/sys/CBOARD arm >> FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 >> WARNING: WITNESS option enabled, expect reduced performance. >> CPU: Cortex A8-r3 rev 2 (Cortex-A core) >> Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext >> WB disabled EABT branch prediction enabled >> LoUU:2 LoC:2 LoUIS:1 >> Cache level 1: >> 32KB/64B 4-way data cache WT WB Read-Alloc >> 32KB/64B 4-way instruction cache Read-Alloc >> Cache level 2: >> 256KB/64B 8-way unified cache WT WB Read-Alloc Write-Alloc >> real memory = 1073741824 (1024 MB) >> panic: kmem_suballoc: bad status return of 3 >> KDB: enter: panic >> [ thread pid 0 tid 0 ] >> Stopped at kdb_enter+0x4c: ldrb r15, [r15, r15, ror r15]! >> db> bt >> Tracing pid 0 tid 0 td 0xc0809280 >> db_trace_self() at db_trace_self >> pc = 0xc0569ce4 lr = 0xc022c954 (db_hex2dec+0x4dc) >> sp = 0xc0820ae4 fp = 0xc0820afc >> r10 = 0xc065d670 >> db_hex2dec() at db_hex2dec+0x4dc >> pc = 0xc022c954 lr = 0xc022c2c0 (db_command_loop+0x2f0) >> sp = 0xc0820b04 fp = 0xc0820ba4 >> r4 = 0x00000000 r5 = 0x00000000 >> r6 = 0xc05c0331 >> db_command_loop() at db_command_loop+0x2f0 >> pc = 0xc022c2c0 lr = 0xc022c030 (db_command_loop+0x60) >> sp = 0xc0820bac fp = 0xc0820bbc >> r4 = 0xc059fddc r5 = 0xc05b9c6e >> r6 = 0xc0808308 r7 = 0xc0820d8c >> r8 = 0xc0809280 r9 = 0xc06a5c24 >> r10 = 0xc065d8e0 >> db_command_loop() at db_command_loop+0x60 >> pc = 0xc022c030 lr = 0xc022ea30 (X_db_symbol_values+0x254) >> sp = 0xc0820bc4 fp = 0xc0820ce4 >> r4 = 0x00000000 r5 = 0xc0820bcc >> r6 = 0xc06a5c4c >> X_db_symbol_values() at X_db_symbol_values+0x254 >> pc = 0xc022ea30 lr = 0xc038d9a8 (kdb_trap+0xd4) >> sp = 0xc0820cec fp = 0xc0820d0c >> r4 = 0x00000000 r5 = 0x00000001 >> r6 = 0xc06a5c4c r7 = 0xc0820d8c >> kdb_trap() at kdb_trap+0xd4 >> pc = 0xc038d9a8 lr = 0xc057a1e4 (undefinedinstruction+0x274) >> sp = 0xc0820d14 fp = 0xc0820d84 >> r4 = 0x00000000 r5 = 0xc0579ecc >> r6 = 0x00000000 r7 = 0xe7ffffff >> r8 = 0xc0809280 r9 = 0xc0820d8c >> r10 = 0xc038d29c >> undefinedinstruction() at undefinedinstruction+0x274 >> pc = 0xc057a1e4 lr = 0xc056b510 (exception_exit) >> sp = 0xc0820d8c fp = 0xc0820de0 >> r4 = 0xc05b9cc8 r5 = 0xc0820e24 >> r6 = 0xc05e5c3b r7 = 0xc0697b30 >> r8 = 0xc0809280 r9 = 0xc0697990 >> r10 = 0xc0809d5c >> exception_exit() at exception_exit >> pc = 0xc056b510 lr = 0xc038d290 (kdb_enter+0x40) >> sp = 0xc0820dd8 fp = 0xc0820de0 >> r0 = 0xc06a5c34 r1 = 0x00000000 >> r2 = 0xc05bd67d r3 = 0x000000ab >> r4 = 0xc05b9cc8 r5 = 0xc0820e24 >> r6 = 0xc05e5c3b r7 = 0xc0697b30 >> r8 = 0xc0809280 r9 = 0xc0697990 >> r10 = 0xc0809d5c r12 = 0x00000000 >> kdb_enter() at kdb_enter+0x50 >> pc = 0xc038d2a0 lr = 0xc035776c (kassert_panic+0x1c8) >> sp = 0xc0820de8 fp = 0xc0820e08 >> r4 = 0x00000100 >> kassert_panic() at kassert_panic+0x1c8 >> pc = 0xc035776c lr = 0xc03577d0 (kproc_shutdown) >> sp = 0xc0820e10 fp = 0xc0820e18 >> r4 = 0xc08ff000 r5 = 0xc0820e70 >> r6 = 0xc0820e6c r7 = 0x007c0000 >> r8 = 0xc080c268 r9 = 0xc0809ff4 >> r10 = 0xc080c784 >> kproc_shutdown() at kproc_shutdown >> pc = 0xc03577d0 lr = 0xc0545df0 (kmem_suballoc+0xd4) >> sp = 0xc0820e20 fp = 0xc0820e58 >> r4 = 0xc0820e24 r5 = 0xc0820e6c >> kmem_suballoc() at kmem_suballoc+0xd4 >> pc = 0xc0545df0 lr = 0xc05453c4 (vm_ksubmap_init+0x1dc) >> sp = 0xc0820e60 fp = 0xc0820e90 >> r4 = 0xc0820e70 r5 = 0xc0820e6c >> r6 = 0x00000000 r7 = 0x00000efe >> vm_ksubmap_init() at vm_ksubmap_init+0x1dc >> pc = 0xc05453c4 lr = 0xc056e344 (initarm+0xb98) >> sp = 0xc0820e98 fp = 0xc0820ed0 >> r4 = 0x00000001 r5 = 0xc080c264 >> r6 = 0x00000000 r7 = 0xc05ed988 >> r8 = 0x00000000 r9 = 0xc0809280 >> r10 = 0xc0820ef8 >> initarm() at initarm+0xb98 >> pc = 0xc056e344 lr = 0xc0308a28 (mi_startup+0x11c) >> sp = 0xc0820ed8 fp = 0xc0820ef0 >> r4 = 0x00000001 r5 = 0xc0809278 >> r6 = 0x00000000 r7 = 0xc05ed988 >> r8 = 0xc0809a84 r9 = 0xc0809a80 >> r10 = 0x7fe61408 >> mi_startup() at mi_startup+0x11c >> pc = 0xc0308a28 lr = 0xc0200224 (btext+0x124) >> sp = 0xc0820ef8 fp = 0x00000000 >> r4 = 0x40200264 r5 = 0x40200158 >> r6 = 0x00000001 r7 = 0x4020014c >> r8 = 0x7fe6140c r9 = 0x00000001 >> btext() at btext+0x124 >> pc = 0xc0200224 lr = 0xc0200224 (btext+0x124) >> sp = 0xc0820ef8 fp = 0x00000000 >> Unable to unwind further >> db> >> _______________________________________________ >> 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" > > From owner-freebsd-arm@FreeBSD.ORG Fri Aug 2 08:38:00 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D7C4362C for ; Fri, 2 Aug 2013 08:38:00 +0000 (UTC) (envelope-from leaf-sapporo@www2865.sakura.ne.jp) Received: from www2865.sakura.ne.jp (www2865.sakura.ne.jp [IPv6:2403:3a00:201:1c:49:212:198:75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 87DAF2B44 for ; Fri, 2 Aug 2013 08:38:00 +0000 (UTC) Received: from www2865.sakura.ne.jp (localhost [127.0.0.1]) by www2865.sakura.ne.jp (8.14.4/8.14.4) with ESMTP id r728bx0N033960 for ; Fri, 2 Aug 2013 17:37:59 +0900 (JST) (envelope-from leaf-sapporo@www2865.sakura.ne.jp) Received: (from leaf-sapporo@localhost) by www2865.sakura.ne.jp (8.14.4/8.14.4/Submit) id r728bwp0033957; Fri, 2 Aug 2013 17:37:59 +0900 (JST) (envelope-from leaf-sapporo) Date: Fri, 2 Aug 2013 17:37:59 +0900 (JST) To: freebsd-arm@freebsd.org Subject: =?utf-8?B?0J/RgNC10LTQu9C+0LbQtdC90LjQtSDQv9C+INGD0LLQtdC70LjRh9C10L3QuNGOINC/0L7RgdC10YnQsNC10LzQvtGB0YLQuCDRgdCw0LnRgtCw?= From: =?utf-8?B?0JLRj9GH0LXRgdC70LDQsg==?= Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 08:38:00 -0000 Здравствуйте! Хотел бы предложить для Вашего сайта целевых посетителей. Источником служат e-mail рассылки. Наши преимущества: - Возможность таргетинга по любому городу; - Просмотр статистики в личном кабинете; - Цена перехода гораздо ниже Яндекс.Директа; - Объем объявления до 200 символов без темы и ссылки. Обращайтесь по любым вопросам по телефону: 7 (4 95 )5 Ч5~1 Ч - 9 2 From owner-freebsd-arm@FreeBSD.ORG Fri Aug 2 13:09:07 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 344BC534; Fri, 2 Aug 2013 13:09:07 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9C0DB2645; Fri, 2 Aug 2013 13:09:06 +0000 (UTC) Received: by mail-we0-f170.google.com with SMTP id w60so507188wes.15 for ; Fri, 02 Aug 2013 06:09:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=TF0eTXw0fTb6USxrHiMfp7xcbM614qs6ahXlS6fofQw=; b=Sxb9rc2t2KaFryYxfd91fzZ4cDxsf5l46CSms5cUrZOFH9+MYBeOFfly8btiajU+V+ kjIgki2bvhM0SOnNZnCDU+btX5Wch64izjLhWBDcwoxCvjYjLcGOWI5L3+Gr1rSCI7vc YR3uAaivIKWBRec9MwsQwjeb3adY+XIr79JQ+k55+OuE691ZWm4+DjKVj6kOKi2ggMAO 1ngP8TiTmzrtHG1lzCl1odnsPOAKT2icRL099gmuKzbj+zyLG7UjbORm3f2+YoBHx5LP H3apiRj72iH5Ib4suM20qa5WQFPTD7rMp6ZTeDU7YNt1If0mBz8PmYl1drkOQWxUysyM 6a/Q== MIME-Version: 1.0 X-Received: by 10.194.123.8 with SMTP id lw8mr4885454wjb.60.1375448944456; Fri, 02 Aug 2013 06:09:04 -0700 (PDT) Received: by 10.194.240.132 with HTTP; Fri, 2 Aug 2013 06:09:04 -0700 (PDT) Date: Fri, 2 Aug 2013 17:09:04 +0400 Message-ID: Subject: RaspberryPi crash/freez random time after ~r253751 From: Andrey Fesenko To: freebsd-current , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 13:09:07 -0000 Hello, System work stable after migration EABI ~r20130716 (+fix build perl port) after make new images r253751 and r253847 system (RPi) freez after random time building ports. got to collect a backtrace log http://pastebin.com/Bbn9ka4N > uname -a FreeBSD raspberry-pi 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r253847M: Thu Aug 1 03:54:07 MSK 2013 andrey@my_book.local:/home/andrey/obj/arm.armv6/usr/src/sys/RPI-B-IPv6 arm From owner-freebsd-arm@FreeBSD.ORG Fri Aug 2 13:42:35 2013 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 04FD9E19; Fri, 2 Aug 2013 13:42:35 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CEB9D2792; Fri, 2 Aug 2013 13:42:34 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1V5Fch-000NgP-1k; Fri, 02 Aug 2013 13:42:27 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r72DgNAi022694; Fri, 2 Aug 2013 07:42:23 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/jvSwmzSijw9VmTg+w14Uc Subject: Re: RFC: sysutils/u-boot-beaglebone-eabi From: Ian Lepore To: Tim Kientzle In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Fri, 02 Aug 2013 07:42:23 -0600 Message-ID: <1375450943.45247.240.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 13:42:35 -0000 On Wed, 2013-07-31 at 20:45 -0700, Tim Kientzle wrote: > I (finally) got this port committed and would appreciate feedback. > > Especially if you're building BeagleBone (White or Black) > images *without* Crochet, please take a look and let me know > what needs to be changed so this is useful for you. > > Goals: > > 1) Build U-Boot as a port with correct dependencies. > > $ cd /usr/ports/sysutils/u-boot-beaglebone-eabi > $ make > $ make install > > This uses the arm-eabi-gcc cross-compiler so it can build on > any FreeBSD architecture and properly spit out an ARM executable. > > 2) Make it unnecessary for most people to actually build U-Boot. > > The port installs the binary bits into > /usr/local/share/u-boot/beaglebone-eabi. From there, system > builders such as Crochet can just copy the bits onto target images. > This also means that the FreeBSD package-building clusters > can build this so that people can get a usable pre-built > U-Boot by installing a binary package. > > 3) Provide a full-featured U-Boot for BeagleBone that can be used > for a variety of purposes. > > This port is currently based on the patches I developed while > working on Crochet, and I hope to soon switch Crochet to use > this instead of building U-Boot itself. But it should be useful to > anyone trying to run FreeBSD on BeagleBone, regardless of how > you're building or booting the system. If it's not useful to you, > please let me know why so I can try to make it more general. > (Rui has already suggested some changes to better support > netbooting.) > > 4) Provide a template for other U-Boot ports. > > Once this is stable, I intend to use the same approach to add > ports for U-Boot on RPi, U-Boot on PandaBoard, etc. > > Tim > > P.S. By the way, to make this work, I had to add real ARM cross-compiler > ports. We now have devel/arm-eabi-binutils and devel/arm-eabi-gcc > I took this out for a test drive yesterday, and it works great, thanks. I was able to adapt it pretty quickly to build myself a custom u-boot for the wandboard. About the only thing I had to change was to put the api_net stuff back in. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Aug 2 23:40:21 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 82ECC980; Fri, 2 Aug 2013 23:40:21 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E939C2F47; Fri, 2 Aug 2013 23:40:20 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id n11so928330wgh.4 for ; Fri, 02 Aug 2013 16:40:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=tGGh34ts6HMyQgvtEP3IpIT2CI65NPDRjmh2Tai1Bfc=; b=vQSKUCvB6gfse01zSjHneQpJaJnSeqFbmSOoT7ubRm/8epbM5Vj7LVnvV5t6FaVNoP 9r7u4SZ+mKiR+TcQZjDmJ39EhnqQb3LmhpnwQ50SlYqdPZFVFU1ctlK9p9HY51RIkPYH O+qk5n8fmheW7m8Bjctzdq23G0lPa7KfD+ufIU8ne1RQ4P+bRWJWE2l8hhNB35BGd/rk 7JyDgtk4YStIk9ktEqJ5rHCTtyesYNcKqpkIVQGp5suM0SCJmn1vnS+gdagJgXl25pRk nQYiyEggTBp3/BMtrCM9L7bwIPBx8Hby+cug8jZLnhqjJjW/0Q9/6+Ngtki8LVXyFA2t rNYQ== MIME-Version: 1.0 X-Received: by 10.194.123.8 with SMTP id lw8mr6487615wjb.60.1375486819297; Fri, 02 Aug 2013 16:40:19 -0700 (PDT) Received: by 10.194.240.132 with HTTP; Fri, 2 Aug 2013 16:40:19 -0700 (PDT) In-Reply-To: References: Date: Sat, 3 Aug 2013 03:40:19 +0400 Message-ID: Subject: Re: RaspberryPi crash/freez random time after ~r253751 From: Andrey Fesenko To: freebsd-current , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 23:40:21 -0000 On Fri, Aug 2, 2013 at 5:09 PM, Andrey Fesenko wrote: > Hello, > > System work stable after migration EABI ~r20130716 (+fix build perl port) > after make new images r253751 and r253847 system (RPi) freez after > random time building ports. > > got to collect a backtrace log http://pastebin.com/Bbn9ka4N > >> uname -a > FreeBSD raspberry-pi 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r253847M: > Thu Aug 1 03:54:07 MSK 2013 > andrey@my_book.local:/home/andrey/obj/arm.armv6/usr/src/sys/RPI-B-IPv6 > arm after patch http://people.freebsd.org/~andrew/trapframe_align.diff system boot, random time building ports crash system bt log http://pastebin.com/jBJFf8Zt From owner-freebsd-arm@FreeBSD.ORG Sat Aug 3 02:29:15 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A8832A14; Sat, 3 Aug 2013 02:29:15 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7E51A2370; Sat, 3 Aug 2013 02:29:14 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1V5Rae-0003dq-3p; Sat, 03 Aug 2013 02:29:08 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r732T5iK023247; Fri, 2 Aug 2013 20:29:05 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/WGV6rYohN1jXa5HtVyTGb Subject: Re: RaspberryPi crash/freez random time after ~r253751 From: Ian Lepore To: Andrey Fesenko In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Fri, 02 Aug 2013 20:29:05 -0600 Message-ID: <1375496945.45247.270.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" , freebsd-current X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2013 02:29:15 -0000 On Sat, 2013-08-03 at 03:40 +0400, Andrey Fesenko wrote: > On Fri, Aug 2, 2013 at 5:09 PM, Andrey Fesenko wrote: > > Hello, > > > > System work stable after migration EABI ~r20130716 (+fix build perl port) > > after make new images r253751 and r253847 system (RPi) freez after > > random time building ports. > > > > got to collect a backtrace log http://pastebin.com/Bbn9ka4N > > > >> uname -a > > FreeBSD raspberry-pi 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r253847M: > > Thu Aug 1 03:54:07 MSK 2013 > > andrey@my_book.local:/home/andrey/obj/arm.armv6/usr/src/sys/RPI-B-IPv6 > > arm > > after patch http://people.freebsd.org/~andrew/trapframe_align.diff > system boot, random time building ports crash system > bt log http://pastebin.com/jBJFf8Zt That is a very strange backtrace. login: panic: vm_fault: fault on nofault entry, addr: db02d000 The page that faulted was db02d000. The stack on entry to the exception handler was db02d008. The exception handling was able to use the stack in the previous page without double-faulting -- it counts down into db02cfxx and lower just fine as the exception handling proceeds. I don't know what to make of it, but I thought I'd mention the oddity in case it triggers ideas for someone else. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Aug 3 07:42:46 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5D690834; Sat, 3 Aug 2013 07:42:46 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id 3CF7C2A88; Sat, 3 Aug 2013 07:42:46 +0000 (UTC) Received: from bender.Home (97e5e46b.skybroadband.com [151.229.228.107]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 5DD165E200; Sat, 3 Aug 2013 07:32:55 +0000 (UTC) Date: Sat, 3 Aug 2013 08:32:48 +0100 From: Andrew Turner To: Ian Lepore Subject: Re: Kernel Panic on DREAMPLUG: Alignment Fault 1 Message-ID: <20130803083248.342108c2@bender.Home> In-Reply-To: <1375374521.45247.211.camel@revolution.hippie.lan> References: <51F92F79.9010809@gmail.com> <1375309907.45247.185.camel@revolution.hippie.lan> <51F9C81A.7000106@gmail.com> <1375358623.45247.189.camel@revolution.hippie.lan> <51FA1D2B.9090009@gmail.com> <1375363713.45247.193.camel@revolution.hippie.lan> <51FA8946.8030301@gmail.com> <1375374521.45247.211.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org, mattia.rossi.mate@gmail.com X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2013 07:42:46 -0000 On Thu, 01 Aug 2013 10:28:41 -0600 Ian Lepore wrote: > On Thu, 2013-08-01 at 18:13 +0200, Mattia Rossi wrote: > > On 01/08/13 15:28, Ian Lepore wrote: > > > On Thu, 2013-08-01 at 10:32 +0200, Mattia Rossi wrote: > > >> > > >> > > >> Anyhow, I'll try to compile with gcc, and see what happens. > > > The host system's compiler (gcc in your case) is used to build the > > > selected compiler from src/, then that new compiler is used to > > > build the rest of src/ into a runnable system. You can define > > > WITHOUT_CLANG_IS_CC and WITHOUT_EABI to use gcc, and you should > > > probably add WITHOUT_CLANG to avoid building it since it won't be > > > used (and it takes forever to build). > > Kernel built with gcc: > > [snip... same fault as with clang] > > Yep, I just had the same experience -- same fault, same place, > addresses differ by a few bytes which is to be expected with a > different compiler. > > I've just confirmed that gcc and WITHOUT_ARM_EABI=yes works fine, so > the problem seems to be that we're somehow not maintaining stack > alignment correctly for EABI on architectures prior to armv6. I have > a feeling somewhere in the code is something conditional on ARMV6 > that really needs to include armv5te (which has the ldrd/strd > instructions). Can you try the patch at [1]. It should fix the stack alignment in exceptions. I suspect gcc is working in this case because it doesn't generate any instructions that rely on the stack alignment, where clang does. Andrew [1] http://people.freebsd.org/~andrew/trapframe_align2.diff From owner-freebsd-arm@FreeBSD.ORG Sat Aug 3 09:24:51 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6E648470 for ; Sat, 3 Aug 2013 09:24:51 +0000 (UTC) (envelope-from mark@grondar.org) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 36A9F2CE6 for ; Sat, 3 Aug 2013 09:24:51 +0000 (UTC) Received: from graveyard.grondar.org ([88.96.155.33] helo=gronkulator.grondar.org) by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1V5Y4t-000Bdt-Cl; Sat, 03 Aug 2013 10:24:48 +0100 From: Mark R V Murray Content-Type: multipart/signed; boundary="Apple-Mail=_D171F5B6-526F-4EE1-99BD-6BDA85945958"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Sat, 3 Aug 2013 10:24:40 +0100 Subject: PATCH: get_cyclecount() on ARMv6 and better To: "freebsd-arm@freebsd.org" Message-Id: <78D22A66-86E5-43B1-ABCA-7BF14F8061AB@grondar.org> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-SA-Score: -2.2 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2013 09:24:51 -0000 --Apple-Mail=_D171F5B6-526F-4EE1-99BD-6BDA85945958 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi folks The CSPRNG used to drive /dev/random is Yarrow, and it needs good timing = jitter to produce decent numbers. The i86_32 and i86_64 platforms both have the TSC register, wrapped in = the get_cyclecount() inline function, but the ARM platform doesn't use = its equivalent, the CCNT register. The alternative, using system time, = loses LOTS of low-bit jitter, and is certainly worth improving upon. I'm at the early stages of testing the patch below (I only have RPi), = and would like to get some comments and reviews, please. I am very = doubtful indeed that I got the #ifdefs right - they are a bit of a = minefield! ;-) The patch returns the 32-bit CCNT register as the 64-bit quantity that = get_cyclecount() provides on all platforms; this is a very minor = problem, but I suppose I could figure out some kind of crude carry = mechanism and force the number to increment beyond 32 bits; I doubt its = worth it though, as its the low bits that provide the jitter. Thanks in advance! M --=20 Mark R V Murray Index: cpu.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- cpu.h (revision 253832) +++ cpu.h (working copy) @@ -5,6 +5,9 @@ #define MACHINE_CPU_H =20 #include +#ifndef _KERNEL +#include +#endif =20 void cpu_halt(void); void swi_vm(void *); @@ -13,11 +16,26 @@ static __inline uint64_t get_cyclecount(void) { +#if defined (__ARM_ARCH_7__) || \ + defined (__ARM_ARCH_7A__) || \ + defined (__ARM_ARCH_6__) || \ + defined (__ARM_ARCH_6J__) || \ + defined (__ARM_ARCH_6K__) || \ + defined (__ARM_ARCH_6T2__) || \ + defined (__ARM_ARCH_6Z__) || \ + defined (__ARM_ARCH_6ZK__) + + uint32_t ccnt; + + /* Read CCNT. Darn; its only 32 bits. */ + __asm __volatile("mrc p15, 0, %0, c9, c13, 0": "=3Dr" (ccnt)); + return ((uint64_t)ccnt); +#else struct bintime bt; =20 binuptime(&bt); return ((uint64_t)bt.sec << 56 | bt.frac >> 8); - =09 +#endif } #endif --Apple-Mail=_D171F5B6-526F-4EE1-99BD-6BDA85945958 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUfzMXt58vKOKE6LNAQoPHQQAqTiNIzalyHsXM2OnsOS+L84Ye8zeULy1 8UGin+/GBov8o50bfsxKKtNRsc32vmDdHR8kUZ6WIq+QzduGXGusHDGJZqE3dAs/ n7e2KXWzb4Oq6Rtr8LcQmLYrUsUypMrtPvn5OPaQc+IkYjoSTDgd0Hkt6xsYnl7n JCajRgHnSlg= =xwZi -----END PGP SIGNATURE----- --Apple-Mail=_D171F5B6-526F-4EE1-99BD-6BDA85945958-- From owner-freebsd-arm@FreeBSD.ORG Sat Aug 3 11:51:48 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 52AF387B for ; Sat, 3 Aug 2013 11:51:48 +0000 (UTC) (envelope-from ray@freebsd.org) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 0C29B2046 for ; Sat, 3 Aug 2013 11:51:47 +0000 (UTC) Received: from rnote.ddteam.net (215-174-133-95.pool.ukrtel.net [95.133.174.215]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id B9D10C4958; Sat, 3 Aug 2013 14:51:39 +0300 (EEST) Date: Sat, 3 Aug 2013 14:51:35 +0300 From: Aleksandr Rybalko To: Mark R V Murray Subject: Re: PATCH: get_cyclecount() on ARMv6 and better Message-Id: <20130803145135.38196156.ray@freebsd.org> In-Reply-To: <78D22A66-86E5-43B1-ABCA-7BF14F8061AB@grondar.org> References: <78D22A66-86E5-43B1-ABCA-7BF14F8061AB@grondar.org> Organization: FreeBSD.ORG X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) X-Operating-System: FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2013 11:51:48 -0000 On Sat, 3 Aug 2013 10:24:40 +0100 Mark R V Murray wrote: > Hi folks > > The CSPRNG used to drive /dev/random is Yarrow, and it needs good > timing jitter to produce decent numbers. > > The i86_32 and i86_64 platforms both have the TSC register, wrapped > in the get_cyclecount() inline function, but the ARM platform doesn't > use its equivalent, the CCNT register. The alternative, using system > time, loses LOTS of low-bit jitter, and is certainly worth improving > upon. > > I'm at the early stages of testing the patch below (I only have RPi), > and would like to get some comments and reviews, please. I am very > doubtful indeed that I got the #ifdefs right - they are a bit of a > minefield! ;-) > > The patch returns the 32-bit CCNT register as the 64-bit quantity > that get_cyclecount() provides on all platforms; this is a very minor > problem, but I suppose I could figure out some kind of crude carry > mechanism and force the number to increment beyond 32 bits; I doubt > its worth it though, as its the low bits that provide the jitter. > > Thanks in advance! > > M > -- > Mark R V Murray > > Index: cpu.h > =================================================================== > --- cpu.h (revision 253832) > +++ cpu.h (working copy) > @@ -5,6 +5,9 @@ > #define MACHINE_CPU_H > > #include > +#ifndef _KERNEL > +#include > +#endif > > void cpu_halt(void); > void swi_vm(void *); > @@ -13,11 +16,26 @@ > static __inline uint64_t > get_cyclecount(void) > { > +#if defined (__ARM_ARCH_7__) || \ > + defined (__ARM_ARCH_7A__) || \ > + defined (__ARM_ARCH_6__) || \ > + defined (__ARM_ARCH_6J__) || \ > + defined (__ARM_ARCH_6K__) || \ > + defined (__ARM_ARCH_6T2__) || \ > + defined (__ARM_ARCH_6Z__) || \ > + defined (__ARM_ARCH_6ZK__) > + > + uint32_t ccnt; > + > + /* Read CCNT. Darn; its only 32 bits. */ > + __asm __volatile("mrc p15, 0, %0, c9, c13, 0": "=r" (ccnt)); > + return ((uint64_t)ccnt); > +#else > struct bintime bt; > > binuptime(&bt); > return ((uint64_t)bt.sec << 56 | bt.frac >> 8); > - > +#endif > } > #endif > > Hi Mark! Do we setup Performance Monitor Control Register before use that counter? WBW -- Aleksandr Rybalko From owner-freebsd-arm@FreeBSD.ORG Sat Aug 3 11:55:25 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 874948F2; Sat, 3 Aug 2013 11:55:25 +0000 (UTC) (envelope-from mark@grondar.org) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4E9DA205B; Sat, 3 Aug 2013 11:55:25 +0000 (UTC) Received: from graveyard.grondar.org ([88.96.155.33] helo=gronkulator.grondar.org) by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1V5aQc-000Bmi-Il; Sat, 03 Aug 2013 12:55:23 +0100 Subject: Re: PATCH: get_cyclecount() on ARMv6 and better Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: multipart/signed; boundary="Apple-Mail=_2BFAB957-1A57-4F35-8394-07A684EFBFFD"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark R V Murray In-Reply-To: <20130803145135.38196156.ray@freebsd.org> Date: Sat, 3 Aug 2013 12:55:10 +0100 Message-Id: References: <78D22A66-86E5-43B1-ABCA-7BF14F8061AB@grondar.org> <20130803145135.38196156.ray@freebsd.org> To: Aleksandr Rybalko X-Mailer: Apple Mail (2.1508) X-SA-Score: -2.2 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2013 11:55:25 -0000 --Apple-Mail=_2BFAB957-1A57-4F35-8394-07A684EFBFFD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 3 Aug 2013, at 12:51, Aleksandr Rybalko wrote: > Hi Mark! >=20 > Do we setup Performance Monitor Control Register before use that > counter? I don't; all I did was that patch. As I understand it, unless userland = needs to change it, there is nothing to set up? I could be making a huge mistake, which I'll no doubt notice soon :-( M --=20 Mark R V Murray --Apple-Mail=_2BFAB957-1A57-4F35-8394-07A684EFBFFD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUfzvqd58vKOKE6LNAQqnZwP/apEJl1zjHEY2w0B6T75xBdtDa8PZHD2u XiDs9wo1jkwwELS6kzfPl/0CzJFdc4w+Sr+qKXp5KO6DBppLhzxEccHY1kUZe9Sy z3ZLrOO8FxV/N6+o7jkAaNUCE/uNGi45gpeDsFYdOdDjxnXAysnqgkgWLxTEooDI lc4gPtMPm7g= =0RfP -----END PGP SIGNATURE----- --Apple-Mail=_2BFAB957-1A57-4F35-8394-07A684EFBFFD-- From owner-freebsd-arm@FreeBSD.ORG Sat Aug 3 12:26:10 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A8FAAE07; Sat, 3 Aug 2013 12:26:10 +0000 (UTC) (envelope-from mark@grondar.org) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6E274215A; Sat, 3 Aug 2013 12:26:10 +0000 (UTC) Received: from graveyard.grondar.org ([88.96.155.33] helo=gronkulator.grondar.org) by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1V5auN-000BoY-Ci; Sat, 03 Aug 2013 13:26:08 +0100 Subject: Re: PATCH: get_cyclecount() on ARMv6 and better Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: multipart/signed; boundary="Apple-Mail=_D3BDEA4A-F751-4FCB-A3E5-5CF45179B341"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark R V Murray In-Reply-To: <20130803145135.38196156.ray@freebsd.org> Date: Sat, 3 Aug 2013 13:26:02 +0100 Message-Id: References: <78D22A66-86E5-43B1-ABCA-7BF14F8061AB@grondar.org> <20130803145135.38196156.ray@freebsd.org> To: Aleksandr Rybalko X-Mailer: Apple Mail (2.1508) X-SA-Score: -2.2 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2013 12:26:10 -0000 --Apple-Mail=_D3BDEA4A-F751-4FCB-A3E5-5CF45179B341 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 3 Aug 2013, at 12:51, Aleksandr Rybalko wrote: > Hi Mark! > > Do we setup Performance Monitor Control Register before use that > counter? I've read up on PNMC register now, an looked for it in the code, and unless it is very well hidden, then NO, we don't set it up. I've read now what I need to do; where is the best place do do it? I suspect it should be in start-up code right when the ARM is starting up; is that a good guess? M -- Mark R V Murray --Apple-Mail=_D3BDEA4A-F751-4FCB-A3E5-5CF45179B341 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUfz23t58vKOKE6LNAQpbdgQAm4GonEIP6K8SX7QgSjYImd26m28Lx6C6 /L9lAzsiey+jtOezkwye2N1yVL7nM9PcoYuzgo6dNThGvvS30+qsPSIbd7OY86U3 LoRAU3E2YdEADCFcQpFND6IW3lwhuvjdaMTXU8P2HrElSUA56LsTkLOd9h67IUo9 1Kz2pDi6ucQ= =RPQ5 -----END PGP SIGNATURE----- --Apple-Mail=_D3BDEA4A-F751-4FCB-A3E5-5CF45179B341-- From owner-freebsd-arm@FreeBSD.ORG Sat Aug 3 14:04:48 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DD6D453E for ; Sat, 3 Aug 2013 14:04:47 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B069D23A8 for ; Sat, 3 Aug 2013 14:04:47 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1V5cRp-000Ov6-Td; Sat, 03 Aug 2013 14:04:46 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r73E4gAC023953; Sat, 3 Aug 2013 08:04:42 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/e5KEpC/1a6OovdlVp19e0 Subject: Re: Kernel Panic on DREAMPLUG: Alignment Fault 1 From: Ian Lepore To: Andrew Turner In-Reply-To: <20130803083248.342108c2@bender.Home> References: <51F92F79.9010809@gmail.com> <1375309907.45247.185.camel@revolution.hippie.lan> <51F9C81A.7000106@gmail.com> <1375358623.45247.189.camel@revolution.hippie.lan> <51FA1D2B.9090009@gmail.com> <1375363713.45247.193.camel@revolution.hippie.lan> <51FA8946.8030301@gmail.com> <1375374521.45247.211.camel@revolution.hippie.lan> <20130803083248.342108c2@bender.Home> Content-Type: text/plain; charset="us-ascii" Date: Sat, 03 Aug 2013 08:04:41 -0600 Message-ID: <1375538681.45247.273.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org, mattia.rossi.mate@gmail.com X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2013 14:04:48 -0000 On Sat, 2013-08-03 at 08:32 +0100, Andrew Turner wrote: > On Thu, 01 Aug 2013 10:28:41 -0600 > Ian Lepore wrote: > > > On Thu, 2013-08-01 at 18:13 +0200, Mattia Rossi wrote: > > > On 01/08/13 15:28, Ian Lepore wrote: > > > > On Thu, 2013-08-01 at 10:32 +0200, Mattia Rossi wrote: > > > >> > > > >> > > > >> Anyhow, I'll try to compile with gcc, and see what happens. > > > > The host system's compiler (gcc in your case) is used to build the > > > > selected compiler from src/, then that new compiler is used to > > > > build the rest of src/ into a runnable system. You can define > > > > WITHOUT_CLANG_IS_CC and WITHOUT_EABI to use gcc, and you should > > > > probably add WITHOUT_CLANG to avoid building it since it won't be > > > > used (and it takes forever to build). > > > Kernel built with gcc: > > > [snip... same fault as with clang] > > > > Yep, I just had the same experience -- same fault, same place, > > addresses differ by a few bytes which is to be expected with a > > different compiler. > > > > I've just confirmed that gcc and WITHOUT_ARM_EABI=yes works fine, so > > the problem seems to be that we're somehow not maintaining stack > > alignment correctly for EABI on architectures prior to armv6. I have > > a feeling somewhere in the code is something conditional on ARMV6 > > that really needs to include armv5te (which has the ldrd/strd > > instructions). > > Can you try the patch at [1]. It should fix the stack alignment in > exceptions. I suspect gcc is working in this case because it doesn't > generate any instructions that rely on the stack alignment, where clang > does. > > Andrew > > [1] http://people.freebsd.org/~andrew/trapframe_align2.diff It's actually not clang vs gcc, it's EABI vs OABI on armv5te. EABI fails the same with clang and gcc. With your patch and gcc EABI I get: ... da1: 40.000MB/s transfers da1: 15193MB (31116288 512 byte sectors: 255H 63S/T 1936C) da1: quirks=0x3 Fatal kernel mode data abort: 'Alignment Fault 1' trapframe: Fatal kernel mode data abort: 'Alignment Fault 1' trapframe: Fatal kernel mode data abort: 'Alignment Fault 1' trapframe: Fatal kernel mode data abort: 'Alignment Fault 1' [lots more lines of that] trapframe: Fatal kernel mode data abort: 'Alignment Fault 1' trapframe: Fatal kernel mode data abort: 'Alignment Fault 1' Fatal kernel mode prefetch abort at 0xFatal kernel mode data abort: 'Alignment Fault 1' trapframe: Fatal kernel mode data abort: 'Alignment Fault 1' trapframe: Fatal kernel mode data abort: 'Alignment Fault 1' And it just continued like that for quite a while, mostly data abort with the occasional prefetch abort thrown in. Eventually it locked hard. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Aug 3 16:31:44 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B89CBB26; Sat, 3 Aug 2013 16:31:44 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id 98108271A; Sat, 3 Aug 2013 16:31:44 +0000 (UTC) Received: from bender.Home (97e5e46b.skybroadband.com [151.229.228.107]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id B8BFB5E200; Sat, 3 Aug 2013 16:31:42 +0000 (UTC) Date: Sat, 3 Aug 2013 17:31:35 +0100 From: Andrew Turner To: Ian Lepore Subject: Re: Kernel Panic on DREAMPLUG: Alignment Fault 1 Message-ID: <20130803173135.76566eeb@bender.Home> In-Reply-To: <1375538681.45247.273.camel@revolution.hippie.lan> References: <51F92F79.9010809@gmail.com> <1375309907.45247.185.camel@revolution.hippie.lan> <51F9C81A.7000106@gmail.com> <1375358623.45247.189.camel@revolution.hippie.lan> <51FA1D2B.9090009@gmail.com> <1375363713.45247.193.camel@revolution.hippie.lan> <51FA8946.8030301@gmail.com> <1375374521.45247.211.camel@revolution.hippie.lan> <20130803083248.342108c2@bender.Home> <1375538681.45247.273.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org, mattia.rossi.mate@gmail.com X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2013 16:31:44 -0000 On Sat, 03 Aug 2013 08:04:41 -0600 Ian Lepore wrote: > On Sat, 2013-08-03 at 08:32 +0100, Andrew Turner wrote: > > Can you try the patch at [1]. It should fix the stack alignment in > > exceptions. I suspect gcc is working in this case because it doesn't > > generate any instructions that rely on the stack alignment, where > > clang does. > > > > Andrew > > > > [1] http://people.freebsd.org/~andrew/trapframe_align2.diff > > It's actually not clang vs gcc, it's EABI vs OABI on armv5te. EABI > fails the same with clang and gcc. > > With your patch and gcc EABI I get: > > ... > da1: 40.000MB/s transfers > da1: 15193MB (31116288 512 byte sectors: 255H 63S/T 1936C) > da1: quirks=0x3 > Fatal kernel mode data abort: 'Alignment Fault 1' > trapframe: Fatal kernel mode data abort: 'Alignment Fault 1' > trapframe: Fatal kernel mode data abort: 'Alignment Fault 1' > trapframe: Fatal kernel mode data abort: 'Alignment Fault 1' > [lots more lines of that] > trapframe: Fatal kernel mode data abort: 'Alignment Fault 1' > trapframe: Fatal kernel mode data abort: 'Alignment Fault 1' > Fatal kernel mode prefetch abort at 0xFatal kernel mode data abort: > 'Alignment Fault 1' trapframe: Fatal kernel mode data abort: > 'Alignment Fault 1' trapframe: Fatal kernel mode data abort: > 'Alignment Fault 1' > > And it just continued like that for quite a while, mostly data abort > with the occasional prefetch abort thrown in. Eventually it locked > hard. It looks like I missed setting the alignment in one of the ARMv4/5 macros. I have an updated patch at [1]. [1] http://people.freebsd.org/~andrew/trapframe_align3.diff From owner-freebsd-arm@FreeBSD.ORG Sat Aug 3 18:01:25 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 14374432 for ; Sat, 3 Aug 2013 18:01:25 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CF8932900 for ; Sat, 3 Aug 2013 18:01:24 +0000 (UTC) Received: by mail-oa0-f45.google.com with SMTP id m1so3550250oag.4 for ; Sat, 03 Aug 2013 11:01:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=GcAex6oxj5CadOgDRL3mkl1mv2ztrMcGYMIgKJ/1VTQ=; b=Bg5/BJScdU1wVuatvj4UVAOd5On9dI8Itt0A4hiO8YxeHR8SpbnOT6ko35NknrEuae 0kq9hopeF/uQ2G4K3JENz6AG+2WPzgFne9B0/z2gwLbYiKvKgectRjadaNSbJtyKTJNT qIlzI4WWtjPHPmQAnl9/mRjQFysjgZWaAPmScAKv8pVAPQ7MrhB2H6lsk5HFX/gyWKg4 WPdGzEXmTE/bLk17oxs8kDZy8rRRFHvHYaBQT8yMFSJ6XCgOjUpRzH4pIUrD2Yenvjl/ JguiROYixwKpphLFh/Dk2412iB8GEPOgBiGyInI6hHYX+G9UoozD32YVQDNTweJfm/iV YE7Q== X-Received: by 10.60.93.41 with SMTP id cr9mr9308484oeb.20.1375552877725; Sat, 03 Aug 2013 11:01:17 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id o4sm14681317obl.7.2013.08.03.11.01.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 03 Aug 2013 11:01:16 -0700 (PDT) Sender: Warner Losh Subject: Re: PATCH: get_cyclecount() on ARMv6 and better Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sat, 3 Aug 2013 12:01:14 -0600 Content-Transfer-Encoding: 7bit Message-Id: <9342F2DA-2A30-4209-B8C6-A43F194852DA@bsdimp.com> References: <78D22A66-86E5-43B1-ABCA-7BF14F8061AB@grondar.org> <20130803145135.38196156.ray@freebsd.org> To: Mark R V Murray X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmH4kE/vZpBwJ7IEUbwQMI3ob2I66wP30GloAK6iUw1sBpeYgFhtj6Tq+fx26/rLUaO2+/G Cc: "freebsd-arm@freebsd.org" , Aleksandr Rybalko X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2013 18:01:25 -0000 On Aug 3, 2013, at 6:26 AM, Mark R V Murray wrote: > > On 3 Aug 2013, at 12:51, Aleksandr Rybalko wrote: >> Hi Mark! >> >> Do we setup Performance Monitor Control Register before use that >> counter? > > I've read up on PNMC register now, an looked for it in the code, > and unless it is very well hidden, then NO, we don't set it up. > > I've read now what I need to do; where is the best place do do it? > I suspect it should be in start-up code right when the ARM is starting > up; is that a good guess? I'd make a timecounter for this, and put that in its initialization code. Warner From owner-freebsd-arm@FreeBSD.ORG Sat Aug 3 22:15:42 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 21F699A6 for ; Sat, 3 Aug 2013 22:15:42 +0000 (UTC) (envelope-from ray@freebsd.org) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id CFBC92F9A for ; Sat, 3 Aug 2013 22:15:41 +0000 (UTC) Received: from rnote.ddteam.net (33-33-135-95.pool.ukrtel.net [95.135.33.33]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id D8AA9C4936; Sun, 4 Aug 2013 01:15:39 +0300 (EEST) Date: Sun, 4 Aug 2013 01:15:35 +0300 From: Aleksandr Rybalko To: Warner Losh Subject: Re: PATCH: get_cyclecount() on ARMv6 and better Message-Id: <20130804011535.b87e1f39.ray@freebsd.org> In-Reply-To: <9342F2DA-2A30-4209-B8C6-A43F194852DA@bsdimp.com> References: <78D22A66-86E5-43B1-ABCA-7BF14F8061AB@grondar.org> <20130803145135.38196156.ray@freebsd.org> <9342F2DA-2A30-4209-B8C6-A43F194852DA@bsdimp.com> Organization: FreeBSD.ORG X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) X-Operating-System: FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" , Mark R V Murray X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2013 22:15:42 -0000 On Sat, 3 Aug 2013 12:01:14 -0600 Warner Losh wrote: > > On Aug 3, 2013, at 6:26 AM, Mark R V Murray wrote: > > > > > On 3 Aug 2013, at 12:51, Aleksandr Rybalko wrote: > >> Hi Mark! > >> > >> Do we setup Performance Monitor Control Register before use that > >> counter? > > > > I've read up on PNMC register now, an looked for it in the code, > > and unless it is very well hidden, then NO, we don't set it up. > > > > I've read now what I need to do; where is the best place do do it? > > I suspect it should be in start-up code right when the ARM is > > starting up; is that a good guess? > > I'd make a timecounter for this, and put that in its initialization > code. > > Warner Since it's PMU register, then better to do PMU driver for it, even if it will have only one feature - read counter. Otherwise you can't depend on it, because you can't guarantee that nobody not disable PMU after use. Another potential useful thing, not to close it under #ifdef ARMv6, but check ARM processor Feature registers. MRC p15, 0, , c0, c1, 2; Read Debug Feature Register 0 Here is [27:24] bits - Performance monitor model, zero - lack of PMU. But unfortunately, Cortex-A8 have no such bits, but have CCNT reg. :) WBW -- Aleksandr Rybalko