From owner-freebsd-arm@FreeBSD.ORG Mon Nov 27 16:27:15 2006 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9CAAB16A50E for ; Mon, 27 Nov 2006 16:27:15 +0000 (UTC) (envelope-from sabelay@backgroundchecks.com) Received: from caritas-graz.at (d01m-213-44-214-53.d4.club-internet.fr [213.44.214.53]) by mx1.FreeBSD.org (Postfix) with SMTP id B7A6643D90 for ; Mon, 27 Nov 2006 16:26:01 +0000 (GMT) (envelope-from sabelay@backgroundchecks.com) Message-ID: <000001c71240$becc3790$d670a8c0@lebh> From: "Cearbhall Arrigo" To: freebsd-arm@freebsd.org Date: Mon, 27 Nov 2006 08:26:09 -0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: underwoo X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Cearbhall Arrigo List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2006 16:27:15 -0000 Hi, =20 VjAGRA_ip_$1,78 CjALiS_tf_$3,00 LEVjTRA_hn_$3,33 =20 www [dot] rx44 [dot] info _____ =20 A quick grrr-grrr reassured me. So I did not have to keep track of From owner-freebsd-arm@FreeBSD.ORG Tue Nov 28 13:29:24 2006 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 19C9F16A415 for ; Tue, 28 Nov 2006 13:29:24 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5115743C9F for ; Tue, 28 Nov 2006 13:29:06 +0000 (GMT) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id E1F0233CB8; Tue, 28 Nov 2006 15:29:02 +0200 (SAST) Date: Tue, 28 Nov 2006 15:29:02 +0200 From: John Hay To: Sam Leffler Message-ID: <20061128132902.GA19150@zibbi.meraka.csir.co.za> References: <4560F437.5060402@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4560F437.5060402@errno.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-arm@freebsd.org Subject: Gateworks 2348 and ath problem X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Nov 2006 13:29:24 -0000 Hi Sam, > 3. If you want to use ath cards in the minipci slots you'll need to use > a newer hal than what is in CVS. I believe the tarball at > http://www.freebsd.org/~sam/ath_hal-20060909.tgz will work but am not > sure. I'm working on getting a known-good version together. I have done this, but it looks like packets (ipv6 and ipv4) are shifted 2 bytes: Here are part of a tcpdump on a wrap (non-arm) board showing packets coming from the arm board: tcpdump -p -i ath0 -n -s 0 -e -X ether src 00:02:6f:34:21:a2 ... 14:41:01.012648 00:02:6f:34:21:a2 > 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 96: 1101:fd9c:6829:597c:10:202:6fff:fe34 > 21a2:ff0e::: [|HBH] 0x0000: 0000 6000 0000 0028 1101 fd9c 6829 597c ..`....(....h)Y| 0x0010: 0010 0202 6fff fe34 21a2 ff0e 0000 0000 ....o..4!....... 0x0020: 0000 0000 0000 0000 0001 02ba 02ba 0028 ...............( 0x0030: cefe 0020 4705 c948 001c fd9c 6829 597c ....G..H....h)Y| 0x0040: 0010 0202 6fff fe34 21a2 0100 7338 0000 ....o..4!...s8.. 0x0050: 0503 .. 14:41:01.162480 00:02:6f:34:21:a2 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 100: IP0 truncated-ip - 17578 bytes missing! 81.110.10.10 > 10.2.10.10: ip 0x0000: 0800 4500 0054 0027 0000 4001 516e 0a0a ..E..T.'..@.Qn.. 0x0010: 0a02 0a0a 0aff 0800 52b4 0203 0026 456c ........R....&El 0x0020: 2e95 0006 4418 0809 0a0b 0c0d 0e0f 1011 ....D........... 0x0030: 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 ...............! 0x0040: 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 "#$%&'()*+,-./01 0x0050: 3233 3435 3637 234567 The first packet is fd9c:6829:597c:10:202:6fff:fe34:21a2 multicasting to ff0e::1 and the second packet is 10.10.10.2 broadcasting to 10.10.10.255. Doing a tcpdump on the arm itself, packets going out seems to be ok, but packets that it receives is shifted 2 bytes in the other direction. The low-level stuff inside the ath driver seems to work though. The cards are in adhoc mode and pick the other up according to "ifconfig ath0 list sta". John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-arm@FreeBSD.ORG Tue Nov 28 14:03:18 2006 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 25DAE16A415 for ; Tue, 28 Nov 2006 14:03:18 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFD4C43DD8 for ; Tue, 28 Nov 2006 14:02:47 +0000 (GMT) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id D6E3A33CBD; Tue, 28 Nov 2006 16:02:37 +0200 (SAST) Date: Tue, 28 Nov 2006 16:02:37 +0200 From: John Hay To: freebsd-arm@freebsd.org Message-ID: <20061128140237.GA21070@zibbi.meraka.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: Gateworks 2348 panics X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Nov 2006 14:03:18 -0000 Hi, I have setup a Gateworks 2348 diskless through the onboard npe0 interface using my pc as the nfs server and it is working ok, except for these panics that I see. It seems to happen "randomly" while the machine is compiling ports. In the time that I compiled perl, olsrd, isc-dhcpserver, quagga, thttpd and php4 it paniced 5 or 6 times and the all looked like this. If there is more that I can do when it happens again, just say what. The kernel and user-level code was cross compiled from -current. John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org ######################################################################### vm_fault(0xc129aa10, 13cc3000, 1, 0) -> 1 Fatal kernel mode data abort: 'Translation Fault (S)' trapframe: 0xc5d6ec40 FSR=000000f5, FAR=13cc3b4c, spsr=20000013 r0 =c00d28a0, r1 =00000000, r2 =13cc3b4c, r3 =c05db460 r4 =13cc3b4c, r5 =00000000, r6 =c129aab8, r7 =c05db4c0 r8 =c0c2a570, r9 =00000000, r10=c5d6eeac, r11=c5d6ecb8 r12=00000000, ssp=c5d6ec8c, slr=00000000, pc =c04b7e70 [thread pid 36319 tid 100069 ] Stopped at xscale_setup_minidata+0xfa4: ldr r3, [r4] db> trace Tracing pid 36319 tid 100069 td 0xc0c2a570 db_trace_thread() at db_trace_thread+0xc scp=0xc04b2d18 rlv=0xc0204690 (db_error+0x66c) rsp=0xc5d6e960 rfp=0xc5d6e97c db_error() at db_error+0x578 scp=0xc020459c rlv=0xc0203ee4 (db_skip_to_eol+0x478) rsp=0xc5d6e980 rfp=0xc5d6ea1c r5=0x00000000 r4=0x00000000 db_skip_to_eol() at db_skip_to_eol+0x230 scp=0xc0203c9c rlv=0xc0203ff0 (db_command_loop+0x58) rsp=0xc5d6ea20 rfp=0xc5d6ea2c r6=0xc05bfe9c r5=0x600000d3 r4=0xc5d6ea38 db_command_loop() at db_command_loop+0xc scp=0xc0203fa4 rlv=0xc02067b0 (X_db_symbol_values+0x200) rsp=0xc5d6ea30 rfp=0xc5d6eb4c X_db_symbol_values() at X_db_symbol_values+0x114 scp=0xc02066c4 rlv=0xc02e905c (kdb_trap+0xbc) rsp=0xc5d6eb50 rfp=0xc5d6eb74 r4=0x000000c0 kdb_trap() at kdb_trap+0xc scp=0xc02e8fac rlv=0xc04c2744 (data_abort_handler+0x804) rsp=0xc5d6eb78 rfp=0xc5d6eb94 r10=0xc5d6ec40 r8=0x00000000 r7=0xc0c2a570 r6=0x13cc3b4c r5=0x000000f5 r4=0xc5d6ec40 data_abort_handler() at data_abort_handler+0x6a0 scp=0xc04c25e0 rlv=0xc04c24ec (data_abort_handler+0x5ac) rsp=0xc5d6eb98 rfp=0xc5d6ec3c r6=0xc5d6eef8 r5=0x13cc3000 r4=0xc0c28d68 data_abort_handler() at data_abort_handler+0xc scp=0xc04c1f4c rlv=0xc04b4878 (address_exception_entry+0x50) rsp=0xc5d6ec40 rfp=0xc5d6ecb8 r10=0xc5d6eeac r9=0x00000000 r8=0xc0c2a570 r7=0xc05db4c0 r6=0xc129aab8 r5=0xe0000004 r4=0x13cc3b4c xscale_setup_minidata() at xscale_setup_minidata+0xf74 scp=0xc04b7e40 rlv=0xc04b8c44 (vector_page_setprot+0x2d0) rsp=0xc5d6ecbc rfp=0xc5d6ecd8 r10=0xc5d6eeac r9=0xc5d6edf0 r8=0xc0c2a570 r7=0xc129aab8 r6=0xc129aab8 r5=0x00000060 r4=0xc00d28a0 vector_page_setprot() at vector_page_setprot+0xc0 scp=0xc04b8a34 rlv=0xc04ba3cc (pmap_remove_pages+0x194) rsp=0xc5d6ecdc rfp=0xc5d6ed08 r6=0xc07eb2bc r5=0xc00d28a0 r4=0xc07f7070 pmap_remove_pages() at pmap_remove_pages+0xc scp=0xc04ba244 rlv=0xc0495d3c (vmspace_exit+0xd8) rsp=0xc5d6ed0c rfp=0xc5d6ed30 r7=0xc0c2a570 r6=0xc0c28d68 r5=0xc129aa10 r4=0x00000001 vmspace_exit() at vmspace_exit+0xc scp=0xc0495c70 rlv=0xc0295b54 (exit1+0x8f4) rsp=0xc5d6ed34 rfp=0xc5d6ed70 r7=0x00000000 r6=0xc0bfcc00 r5=0xc0c28d68 r4=0xc5d6ed5c exit1() at exit1+0xc scp=0xc029526c rlv=0xc0295260 (exit1) rsp=0xc5d6ed74 rfp=0xc5d6ed80 sys_exit() at sys_exit+0xc scp=0xc0295254 rlv=0xc04c3230 (badaddr_read+0x500) rsp=0xc5d6ed84 rfp=0xc5d6ee38 badaddr_read() at badaddr_read+0x110 scp=0xc04c2e40 rlv=0xc04c35f0 (swi_handler+0x104) rsp=0xc5d6ee3c rfp=0xc5d6eea8 r10=0x201614d4 r9=0x00000000 r8=0x000127a4 r7=0x000127ac r6=0xc5d6eeac r5=0xc0c2a570 r4=0x00000000 swi_handler() at swi_handler+0xc scp=0xc04c34f8 rlv=0xc04b4638 (swi_entry+0x28) rsp=0xc5d6eeac rfp=0xbfffe774 r6=0x00000001 r5=0xbfffe7e0 r4=0x00000000 db> ######################################################################### From owner-freebsd-arm@FreeBSD.ORG Tue Nov 28 14:23:34 2006 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8D97216A403 for ; Tue, 28 Nov 2006 14:23:34 +0000 (UTC) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (cognet.ci0.org [80.65.224.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07FF343C9F for ; Tue, 28 Nov 2006 14:23:30 +0000 (GMT) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (localhost.ci0.org [127.0.0.1]) by dong.ci0.org (8.13.7/8.13.4) with ESMTP id kASEfJvX022004; Tue, 28 Nov 2006 15:41:19 +0100 (CET) (envelope-from mlfbsd@dong.ci0.org) Received: (from mlfbsd@localhost) by dong.ci0.org (8.13.7/8.13.4/Submit) id kASEfIOH022003; Tue, 28 Nov 2006 15:41:18 +0100 (CET) (envelope-from mlfbsd) Date: Tue, 28 Nov 2006 15:41:18 +0100 From: Olivier Houchard To: John Hay Message-ID: <20061128144117.GA21879@ci0.org> References: <20061128140237.GA21070@zibbi.meraka.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061128140237.GA21070@zibbi.meraka.csir.co.za> User-Agent: Mutt/1.4.1i Cc: freebsd-arm@freebsd.org Subject: Re: Gateworks 2348 panics X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 28 Nov 2006 14:23:34 -0000 On Tue, Nov 28, 2006 at 04:02:37PM +0200, John Hay wrote: > Hi, > > I have setup a Gateworks 2348 diskless through the onboard npe0 > interface using my pc as the nfs server and it is working ok, except > for these panics that I see. It seems to happen "randomly" while the > machine is compiling ports. In the time that I compiled perl, olsrd, > isc-dhcpserver, quagga, thttpd and php4 it paniced 5 or 6 times and > the all looked like this. If there is more that I can do when it > happens again, just say what. > > The kernel and user-level code was cross compiled from -current. > > John > -- > John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org > > Hi John, Indeed this bug is known, I hope to be able to track it down tonight. In the meanwhile, you may try to compile your kernel with INVARIANTS and INVARIANTS support, but it has been reported that it made the problem disappear. Olivier > ######################################################################### > vm_fault(0xc129aa10, 13cc3000, 1, 0) -> 1 > Fatal kernel mode data abort: 'Translation Fault (S)' > trapframe: 0xc5d6ec40 > FSR=000000f5, FAR=13cc3b4c, spsr=20000013 > r0 =c00d28a0, r1 =00000000, r2 =13cc3b4c, r3 =c05db460 > r4 =13cc3b4c, r5 =00000000, r6 =c129aab8, r7 =c05db4c0 > r8 =c0c2a570, r9 =00000000, r10=c5d6eeac, r11=c5d6ecb8 > r12=00000000, ssp=c5d6ec8c, slr=00000000, pc =c04b7e70 > > [thread pid 36319 tid 100069 ] > Stopped at xscale_setup_minidata+0xfa4: ldr r3, [r4] > db> trace > Tracing pid 36319 tid 100069 td 0xc0c2a570 > db_trace_thread() at db_trace_thread+0xc > scp=0xc04b2d18 rlv=0xc0204690 (db_error+0x66c) > rsp=0xc5d6e960 rfp=0xc5d6e97c > db_error() at db_error+0x578 > scp=0xc020459c rlv=0xc0203ee4 (db_skip_to_eol+0x478) > rsp=0xc5d6e980 rfp=0xc5d6ea1c > r5=0x00000000 r4=0x00000000 > db_skip_to_eol() at db_skip_to_eol+0x230 > scp=0xc0203c9c rlv=0xc0203ff0 (db_command_loop+0x58) > rsp=0xc5d6ea20 rfp=0xc5d6ea2c > r6=0xc05bfe9c r5=0x600000d3 > r4=0xc5d6ea38 > db_command_loop() at db_command_loop+0xc > scp=0xc0203fa4 rlv=0xc02067b0 (X_db_symbol_values+0x200) > rsp=0xc5d6ea30 rfp=0xc5d6eb4c > X_db_symbol_values() at X_db_symbol_values+0x114 > scp=0xc02066c4 rlv=0xc02e905c (kdb_trap+0xbc) > rsp=0xc5d6eb50 rfp=0xc5d6eb74 > r4=0x000000c0 > kdb_trap() at kdb_trap+0xc > scp=0xc02e8fac rlv=0xc04c2744 (data_abort_handler+0x804) > rsp=0xc5d6eb78 rfp=0xc5d6eb94 > r10=0xc5d6ec40 r8=0x00000000 > r7=0xc0c2a570 r6=0x13cc3b4c r5=0x000000f5 r4=0xc5d6ec40 > data_abort_handler() at data_abort_handler+0x6a0 > scp=0xc04c25e0 rlv=0xc04c24ec (data_abort_handler+0x5ac) > rsp=0xc5d6eb98 rfp=0xc5d6ec3c > r6=0xc5d6eef8 r5=0x13cc3000 > r4=0xc0c28d68 > data_abort_handler() at data_abort_handler+0xc > scp=0xc04c1f4c rlv=0xc04b4878 (address_exception_entry+0x50) > rsp=0xc5d6ec40 rfp=0xc5d6ecb8 > r10=0xc5d6eeac r9=0x00000000 > r8=0xc0c2a570 r7=0xc05db4c0 r6=0xc129aab8 r5=0xe0000004 > r4=0x13cc3b4c > xscale_setup_minidata() at xscale_setup_minidata+0xf74 > scp=0xc04b7e40 rlv=0xc04b8c44 (vector_page_setprot+0x2d0) > rsp=0xc5d6ecbc rfp=0xc5d6ecd8 > r10=0xc5d6eeac r9=0xc5d6edf0 > r8=0xc0c2a570 r7=0xc129aab8 r6=0xc129aab8 r5=0x00000060 > r4=0xc00d28a0 > vector_page_setprot() at vector_page_setprot+0xc0 > scp=0xc04b8a34 rlv=0xc04ba3cc (pmap_remove_pages+0x194) > rsp=0xc5d6ecdc rfp=0xc5d6ed08 > r6=0xc07eb2bc r5=0xc00d28a0 > r4=0xc07f7070 > pmap_remove_pages() at pmap_remove_pages+0xc > scp=0xc04ba244 rlv=0xc0495d3c (vmspace_exit+0xd8) > rsp=0xc5d6ed0c rfp=0xc5d6ed30 > r7=0xc0c2a570 r6=0xc0c28d68 > r5=0xc129aa10 r4=0x00000001 > vmspace_exit() at vmspace_exit+0xc > scp=0xc0495c70 rlv=0xc0295b54 (exit1+0x8f4) > rsp=0xc5d6ed34 rfp=0xc5d6ed70 > r7=0x00000000 r6=0xc0bfcc00 > r5=0xc0c28d68 r4=0xc5d6ed5c > exit1() at exit1+0xc > scp=0xc029526c rlv=0xc0295260 (exit1) > rsp=0xc5d6ed74 rfp=0xc5d6ed80 > sys_exit() at sys_exit+0xc > scp=0xc0295254 rlv=0xc04c3230 (badaddr_read+0x500) > rsp=0xc5d6ed84 rfp=0xc5d6ee38 > badaddr_read() at badaddr_read+0x110 > scp=0xc04c2e40 rlv=0xc04c35f0 (swi_handler+0x104) > rsp=0xc5d6ee3c rfp=0xc5d6eea8 > r10=0x201614d4 r9=0x00000000 > r8=0x000127a4 r7=0x000127ac r6=0xc5d6eeac r5=0xc0c2a570 > r4=0x00000000 > swi_handler() at swi_handler+0xc > scp=0xc04c34f8 rlv=0xc04b4638 (swi_entry+0x28) > rsp=0xc5d6eeac rfp=0xbfffe774 > r6=0x00000001 r5=0xbfffe7e0 > r4=0x00000000 > 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 Wed Nov 29 18:48:57 2006 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BE27216A403 for ; Wed, 29 Nov 2006 18:48:57 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C99243C9D for ; Wed, 29 Nov 2006 18:48:54 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id kATImj4g020902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Nov 2006 10:48:57 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <456DD60C.2000208@errno.com> Date: Wed, 29 Nov 2006 10:48:44 -0800 From: Sam Leffler User-Agent: Thunderbird 1.5.0.7 (X11/20060920) MIME-Version: 1.0 To: John Hay References: <4560F437.5060402@errno.com> <20061128132902.GA19150@zibbi.meraka.csir.co.za> In-Reply-To: <20061128132902.GA19150@zibbi.meraka.csir.co.za> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: Gateworks 2348 and ath problem X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Nov 2006 18:48:57 -0000 John Hay wrote: > Hi Sam, > >> 3. If you want to use ath cards in the minipci slots you'll need to use >> a newer hal than what is in CVS. I believe the tarball at >> http://www.freebsd.org/~sam/ath_hal-20060909.tgz will work but am not >> sure. I'm working on getting a known-good version together. > > I have done this, but it looks like packets (ipv6 and ipv4) are shifted > 2 bytes: > > Here are part of a tcpdump on a wrap (non-arm) board showing packets > coming from the arm board: > tcpdump -p -i ath0 -n -s 0 -e -X ether src 00:02:6f:34:21:a2 > ... > 14:41:01.012648 00:02:6f:34:21:a2 > 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 96: 1101:fd9c:6829:597c:10:202:6fff:fe34 > 21a2:ff0e::: [|HBH] > 0x0000: 0000 6000 0000 0028 1101 fd9c 6829 597c ..`....(....h)Y| > 0x0010: 0010 0202 6fff fe34 21a2 ff0e 0000 0000 ....o..4!....... > 0x0020: 0000 0000 0000 0000 0001 02ba 02ba 0028 ...............( > 0x0030: cefe 0020 4705 c948 001c fd9c 6829 597c ....G..H....h)Y| > 0x0040: 0010 0202 6fff fe34 21a2 0100 7338 0000 ....o..4!...s8.. > 0x0050: 0503 .. > 14:41:01.162480 00:02:6f:34:21:a2 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 100: IP0 truncated-ip - 17578 bytes missing! 81.110.10.10 > 10.2.10.10: ip > 0x0000: 0800 4500 0054 0027 0000 4001 516e 0a0a ..E..T.'..@.Qn.. > 0x0010: 0a02 0a0a 0aff 0800 52b4 0203 0026 456c ........R....&El > 0x0020: 2e95 0006 4418 0809 0a0b 0c0d 0e0f 1011 ....D........... > 0x0030: 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 ...............! > 0x0040: 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 "#$%&'()*+,-./01 > 0x0050: 3233 3435 3637 234567 > > The first packet is fd9c:6829:597c:10:202:6fff:fe34:21a2 multicasting > to ff0e::1 and the second packet is 10.10.10.2 broadcasting to > 10.10.10.255. > > Doing a tcpdump on the arm itself, packets going out seems to be ok, > but packets that it receives is shifted 2 bytes in the other direction. > > The low-level stuff inside the ath driver seems to work though. The > cards are in adhoc mode and pick the other up according to "ifconfig ath0 > list sta". Well you're doing better than me. I tried patching the hal.o in CVS to deal with the ELF magic number and hit problems with DMA aborts on rx so went off to do other work. I'm trying to get a new version together for folks to use but am busy with real work. All my successful testing was done w/ a version of the hal that I am not (yet) comfortable distributing. The above looks like something outside the driver. I forced the ethernet header structure to be __packed to deal with a compiler issue; do you have that change (you don't indicate what code you are running or how you built it)? I have not tested adhoc mode. I have done some reasonable tests of sta mode and ap mode and the only anomaly I saw was some sporadic complaints from the tx rate control code about bogus rate indices (that I haven't followed through on). In general operation was as expected. Sam From owner-freebsd-arm@FreeBSD.ORG Wed Nov 29 18:50:33 2006 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7AD3F16A412 for ; Wed, 29 Nov 2006 18:50:33 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2396343CA2 for ; Wed, 29 Nov 2006 18:50:30 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id kATIoUpN020934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Nov 2006 10:50:31 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <456DD676.4010301@errno.com> Date: Wed, 29 Nov 2006 10:50:30 -0800 From: Sam Leffler User-Agent: Thunderbird 1.5.0.7 (X11/20060920) MIME-Version: 1.0 To: John Hay References: <20061128140237.GA21070@zibbi.meraka.csir.co.za> In-Reply-To: <20061128140237.GA21070@zibbi.meraka.csir.co.za> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: Gateworks 2348 panics X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Nov 2006 18:50:33 -0000 John Hay wrote: > Hi, > > I have setup a Gateworks 2348 diskless through the onboard npe0 > interface using my pc as the nfs server and it is working ok, except > for these panics that I see. It seems to happen "randomly" while the > machine is compiling ports. In the time that I compiled perl, olsrd, > isc-dhcpserver, quagga, thttpd and php4 it paniced 5 or 6 times and > the all looked like this. If there is more that I can do when it > happens again, just say what. > > The kernel and user-level code was cross compiled from -current. > > John We've received one other report (privately) that doing buildworld over an NFS-mounted root causes random crashes in the vm code. Olivier seems to think this is different (I believe). Sam From owner-freebsd-arm@FreeBSD.ORG Wed Nov 29 19:39:58 2006 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BF59316A4C9 for ; Wed, 29 Nov 2006 19:39:58 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93BA143D5A for ; Wed, 29 Nov 2006 19:38:49 +0000 (GMT) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 22BE933CB8; Wed, 29 Nov 2006 21:38:42 +0200 (SAST) Date: Wed, 29 Nov 2006 21:38:42 +0200 From: John Hay To: Sam Leffler Message-ID: <20061129193842.GA98569@zibbi.meraka.csir.co.za> References: <4560F437.5060402@errno.com> <20061128132902.GA19150@zibbi.meraka.csir.co.za> <456DD60C.2000208@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <456DD60C.2000208@errno.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-arm@freebsd.org Subject: Re: Gateworks 2348 and ath problem X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Nov 2006 19:39:58 -0000 On Wed, Nov 29, 2006 at 10:48:44AM -0800, Sam Leffler wrote: > John Hay wrote: > > Hi Sam, > > > >> 3. If you want to use ath cards in the minipci slots you'll need to use > >> a newer hal than what is in CVS. I believe the tarball at > >> http://www.freebsd.org/~sam/ath_hal-20060909.tgz will work but am not > >> sure. I'm working on getting a known-good version together. > > > > I have done this, but it looks like packets (ipv6 and ipv4) are shifted > > 2 bytes: > > > > Here are part of a tcpdump on a wrap (non-arm) board showing packets > > coming from the arm board: > > tcpdump -p -i ath0 -n -s 0 -e -X ether src 00:02:6f:34:21:a2 > > ... > > 14:41:01.012648 00:02:6f:34:21:a2 > 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 96: 1101:fd9c:6829:597c:10:202:6fff:fe34 > 21a2:ff0e::: [|HBH] > > 0x0000: 0000 6000 0000 0028 1101 fd9c 6829 597c ..`....(....h)Y| > > 0x0010: 0010 0202 6fff fe34 21a2 ff0e 0000 0000 ....o..4!....... > > 0x0020: 0000 0000 0000 0000 0001 02ba 02ba 0028 ...............( > > 0x0030: cefe 0020 4705 c948 001c fd9c 6829 597c ....G..H....h)Y| > > 0x0040: 0010 0202 6fff fe34 21a2 0100 7338 0000 ....o..4!...s8.. > > 0x0050: 0503 .. > > 14:41:01.162480 00:02:6f:34:21:a2 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 100: IP0 truncated-ip - 17578 bytes missing! 81.110.10.10 > 10.2.10.10: ip > > 0x0000: 0800 4500 0054 0027 0000 4001 516e 0a0a ..E..T.'..@.Qn.. > > 0x0010: 0a02 0a0a 0aff 0800 52b4 0203 0026 456c ........R....&El > > 0x0020: 2e95 0006 4418 0809 0a0b 0c0d 0e0f 1011 ....D........... > > 0x0030: 1213 1415 1617 1819 1a1b 1c1d 1e1f 2021 ...............! > > 0x0040: 2223 2425 2627 2829 2a2b 2c2d 2e2f 3031 "#$%&'()*+,-./01 > > 0x0050: 3233 3435 3637 234567 > > > > The first packet is fd9c:6829:597c:10:202:6fff:fe34:21a2 multicasting > > to ff0e::1 and the second packet is 10.10.10.2 broadcasting to > > 10.10.10.255. > > > > Doing a tcpdump on the arm itself, packets going out seems to be ok, > > but packets that it receives is shifted 2 bytes in the other direction. > > > > The low-level stuff inside the ath driver seems to work though. The > > cards are in adhoc mode and pick the other up according to "ifconfig ath0 > > list sta". > > Well you're doing better than me. I tried patching the hal.o in CVS to > deal with the ELF magic number and hit problems with DMA aborts on rx so > went off to do other work. I'm trying to get a new version together for > folks to use but am busy with real work. All my successful testing was > done w/ a version of the hal that I am not (yet) comfortable distributing. > > The above looks like something outside the driver. I forced the > ethernet header structure to be __packed to deal with a compiler issue; > do you have that change (you don't indicate what code you are running or > how you built it)? Hmmm, I'm doing what my kids do, just assume everyone knows what I do. :-) I have basically followed the instructions you posted when you merged the Gateworks/Avila code into -current. So it was -current build on the day I posted. I tried both with the hal in -current (using wackelf) and the 0909 hal you mentioned in your email. The kernel used the AVILA conf in -current changed to use the CF as root, with nfs and bootp removed and these added: options MROUTING options IPFIREWALL options IPFIREWALL_FORWARD options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_VERBOSE options IPDIVERT options DUMMYNET options IPSEC options IPSEC_ESP Thinking about it, I can remove all of them and try again to make sure it isn't one of them doing it. The version of net/ethernet.h that I use is 1.27 and struct ether_header is marked as __packed. What is strange to me is that according to tcpdump on the arm box itself, the outgoing packets looks ok. > I have not tested adhoc mode. I have done some reasonable tests of sta > mode and ap mode and the only anomaly I saw was some sporadic complaints > from the tx rate control code about bogus rate indices (that I haven't > followed through on). In general operation was as expected. I did the opposite, I haven't even tried sta or ap modes. :-/ We are playing with ipv6 meshes, so my ipv4 test was just to make sure the problem wasn't an ipv6 only one. I'll try them tomorrow and see if they work better. John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-arm@FreeBSD.ORG Wed Nov 29 21:07:19 2006 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D86F516A50A for ; Wed, 29 Nov 2006 21:07:19 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from talk.nabble.com (www.nabble.com [72.21.53.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id A49C543CB0 for ; Wed, 29 Nov 2006 21:07:13 +0000 (GMT) (envelope-from bounces@nabble.com) Received: from [72.21.53.38] (helo=jubjub.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1GpWeC-0006po-E8 for freebsd-arm@freebsd.org; Wed, 29 Nov 2006 13:07:16 -0800 Message-ID: <7607997.post@talk.nabble.com> Date: Wed, 29 Nov 2006 13:07:16 -0800 (PST) From: Zuy To: freebsd-arm@freebsd.org In-Reply-To: <20061118.012659.-1876864065.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: zaitsevbros@mail.ru References: <7380637.post@talk.nabble.com> <20061116.093638.63053940.imp@bsdimp.com> <7395689.post@talk.nabble.com> <20061118.012659.-1876864065.imp@bsdimp.com> Subject: Re: At91rm9200 how to start with FreeBSD X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Nov 2006 21:07:20 -0000 I found bootstrap tools and kernel config files in FreeBSD6.2. So I decided to try to compile kernel for At91RM9200 the same way as I do for I386 configuration. As far as I do not have all source files installed I have to use traditional way for building kernel. zuy_bsd# cd /usr/src/sys/arm/conf zuy_bsd# /usr/sbin/config KB920X Kernel build directory is ../compile/KB920X Don't forget to do ``make cleandepend; make depend'' zuy_bsd# cd ../compile/KB920X zuy-bsd# make cleandepend rm -f .depend zuy-bsd# make depend cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs ....... # I cut option to make my post shorter `-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead. ../../../i386/i386/genassym.c:1: error: bad value (arm9) for -mtune= switch *** Error code 1 Stop in /usr/src/sys/arm/compile/KB920X. I think this error means that by default GCC in FreeBSD6.2 does not support compilation for ARM architecture. I have two ideas how to enable this support. 1. Download lates version of GCC and compile it with cross compiler for ARM. 2. Install /usr/ports/devel/arm-elf-gcc295 I found that a lot of people do not advice to change standart compiler with new one. It can cause problems with future kernel building. That is why I'm not sure that the first way is correct. The second way installs ARM support but for old version of compiler. That I think is not good as well. So I need an advice what is the best way to enable support for ARM in GCC for FreeBSD. Thank you. : You mentioned bootstrap tools such as boot0, boot0iic, boot0spi and boot2. : Where can I get them? : Boot0 and boot2 I found in /usr/src/sys/boot but there is no folder for ARM. : I use FreeBSD 6.0 (6.2 is downloading now) may be that is the reason. In -current, they can be found in /usr/src/sys/boot/arm/at91, as well as on 6.2. I believe that the 6.2 versions are less advanced. : And the last question about compilation process. As you wrote, following : sequence will give the compiled OS for arm architecture: : % setenv TARGET arm : % setenv TARGET_ARCH arm : % make buildworld : % make distribution DESTDIR=/mnt : % make installworld DESTDIR=/mnt : : But how the system will know that I need compilation for ARM9. Where it will : get drivers for basic internal peripherals of AR91RM9200? I think that I : have to prepare configuration file like I do for compiling kernel for I386, : but I cannot find it. It looks like they are in the /usr/src/sys/arm/conf. I : found there two files IQ31244 and SIMICS. Probably they are configuration : files for IQ31244 and SIMICS development boards. So I think I have to make : the same file for AT91RM9200. May be you can give me the idea where to get : such file like an example? You are correct in that you need a config file. In 6.2 and current there is a KB920X file that can be used as a basis for this support. Warner : Best regards, : Ivan Zaitsev. : : -- View this message in context: http://www.nabble.com/At91rm9200-how-to-start-with-FreeBSD-tf2643928.html#a7607997 Sent from the freebsd-arm mailing list archive at Nabble.com. From owner-freebsd-arm@FreeBSD.ORG Wed Nov 29 21:19:49 2006 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7F8B816A40F for ; Wed, 29 Nov 2006 21:19:49 +0000 (UTC) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (cognet.ci0.org [80.65.224.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09F6A43CCC for ; Wed, 29 Nov 2006 21:18:18 +0000 (GMT) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (localhost.ci0.org [127.0.0.1]) by dong.ci0.org (8.13.7/8.13.4) with ESMTP id kATLaTTK035517; Wed, 29 Nov 2006 22:36:29 +0100 (CET) (envelope-from mlfbsd@dong.ci0.org) Received: (from mlfbsd@localhost) by dong.ci0.org (8.13.7/8.13.4/Submit) id kATLaTPM035514; Wed, 29 Nov 2006 22:36:29 +0100 (CET) (envelope-from mlfbsd) Date: Wed, 29 Nov 2006 22:36:28 +0100 From: Olivier Houchard To: Zuy Message-ID: <20061129213628.GA35446@ci0.org> References: <7380637.post@talk.nabble.com> <20061116.093638.63053940.imp@bsdimp.com> <7395689.post@talk.nabble.com> <20061118.012659.-1876864065.imp@bsdimp.com> <7607997.post@talk.nabble.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7607997.post@talk.nabble.com> User-Agent: Mutt/1.4.1i Cc: freebsd-arm@freebsd.org Subject: Re: At91rm9200 how to start with FreeBSD X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Nov 2006 21:19:49 -0000 Hi, On Wed, Nov 29, 2006 at 01:07:16PM -0800, Zuy wrote: > > I found bootstrap tools and kernel config files in FreeBSD6.2. > So I decided to try to compile kernel for At91RM9200 the same way as I do > for I386 configuration. > As far as I do not have all source files installed I have to use traditional > way for building kernel. > > zuy_bsd# cd /usr/src/sys/arm/conf > zuy_bsd# /usr/sbin/config KB920X > Kernel build directory is ../compile/KB920X > Don't forget to do ``make cleandepend; make depend'' > zuy_bsd# cd ../compile/KB920X > zuy-bsd# make cleandepend > rm -f .depend > zuy-bsd# make depend > cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs ....... # I cut > option to make my post shorter > `-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead. > ../../../i386/i386/genassym.c:1: error: bad value (arm9) for -mtune= switch > *** Error code 1 > > Stop in /usr/src/sys/arm/compile/KB920X. > > I think this error means that by default GCC in FreeBSD6.2 does not support > compilation for ARM architecture. > I have two ideas how to enable this support. > 1. Download lates version of GCC and compile it with cross compiler for ARM. > 2. Install /usr/ports/devel/arm-elf-gcc295 > I found that a lot of people do not advice to change standart compiler with > new one. It can cause problems with future kernel building. That is why I'm > not sure that the first way is correct. > The second way installs ARM support but for old version of compiler. That I > think is not good as well. > You can build an arm cross-compiler from the system sources as described here : http://people.FreeBSD.org/~cognet/freebsd_arm.txt Using the new official way to build the kernel, with make buildkernel, should work for cross-compiling too : I think you first need to do make TARGET_ARCH=arm kernel-toolchain and then you should be able to do make TARGET_ARCH=arm KERNCONF=YOURFILE buildkernel But I do not use this method, so I can't swear it's the exact things to do. Cheers, Olivier From owner-freebsd-arm@FreeBSD.ORG Wed Nov 29 21:40:28 2006 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7748616A53B for ; Wed, 29 Nov 2006 21:40:28 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDC2C43E8D for ; Wed, 29 Nov 2006 21:35:48 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id kATLWvfF021087; Wed, 29 Nov 2006 14:32:57 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 29 Nov 2006 14:33:39 -0700 (MST) Message-Id: <20061129.143339.-861030644.imp@bsdimp.com> To: mlfbsd@ci0.Org From: "M. Warner Losh" In-Reply-To: <20061129213628.GA35446@ci0.org> References: <20061118.012659.-1876864065.imp@bsdimp.com> <7607997.post@talk.nabble.com> <20061129213628.GA35446@ci0.org> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Wed, 29 Nov 2006 14:32:58 -0700 (MST) Cc: zaitsevbros@mail.ru, freebsd-arm@freebsd.org Subject: Re: At91rm9200 how to start with FreeBSD X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 29 Nov 2006 21:40:28 -0000 In message: <20061129213628.GA35446@ci0.org> Olivier Houchard writes: : Hi, : : On Wed, Nov 29, 2006 at 01:07:16PM -0800, Zuy wrote: : > : > I found bootstrap tools and kernel config files in FreeBSD6.2. : > So I decided to try to compile kernel for At91RM9200 the same way as I do : > for I386 configuration. : > As far as I do not have all source files installed I have to use traditional : > way for building kernel. : > : > zuy_bsd# cd /usr/src/sys/arm/conf : > zuy_bsd# /usr/sbin/config KB920X : > Kernel build directory is ../compile/KB920X : > Don't forget to do ``make cleandepend; make depend'' : > zuy_bsd# cd ../compile/KB920X : > zuy-bsd# make cleandepend : > rm -f .depend : > zuy-bsd# make depend : > cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs ....... # I cut : > option to make my post shorter : > `-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead. : > ../../../i386/i386/genassym.c:1: error: bad value (arm9) for -mtune= switch : > *** Error code 1 : > : > Stop in /usr/src/sys/arm/compile/KB920X. : > : > I think this error means that by default GCC in FreeBSD6.2 does not support : > compilation for ARM architecture. : > I have two ideas how to enable this support. : > 1. Download lates version of GCC and compile it with cross compiler for ARM. : > 2. Install /usr/ports/devel/arm-elf-gcc295 : > I found that a lot of people do not advice to change standart compiler with : > new one. It can cause problems with future kernel building. That is why I'm : > not sure that the first way is correct. : > The second way installs ARM support but for old version of compiler. That I : > think is not good as well. : > : : You can build an arm cross-compiler from the system sources as described here : : http://people.FreeBSD.org/~cognet/freebsd_arm.txt : Using the new official way to build the kernel, with make buildkernel, : should work for cross-compiling too : : I think you first need to do : make TARGET_ARCH=arm kernel-toolchain : and then you should be able to do make TARGET_ARCH=arm KERNCONF=YOURFILE : buildkernel : But I do not use this method, so I can't swear it's the exact things to do. I've used this method quite recently on -current. I usually add TARGET=arm as well, but that's because there's a difference between current and stable in this area and adding both doesn't hurt and always works... Warner From owner-freebsd-arm@FreeBSD.ORG Thu Nov 30 12:02:21 2006 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D33A016A403 for ; Thu, 30 Nov 2006 12:02:21 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3650B43CAF for ; Thu, 30 Nov 2006 12:02:12 +0000 (GMT) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id B6BAF33CAA; Thu, 30 Nov 2006 14:02:17 +0200 (SAST) Date: Thu, 30 Nov 2006 14:02:17 +0200 From: John Hay To: Sam Leffler Message-ID: <20061130120217.GA41346@zibbi.meraka.csir.co.za> References: <4560F437.5060402@errno.com> <20061128132902.GA19150@zibbi.meraka.csir.co.za> <456DD60C.2000208@errno.com> <20061129193842.GA98569@zibbi.meraka.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061129193842.GA98569@zibbi.meraka.csir.co.za> User-Agent: Mutt/1.4.2.1i Cc: freebsd-arm@freebsd.org Subject: Re: Gateworks 2348 and ath problem X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Nov 2006 12:02:21 -0000 > > Well you're doing better than me. I tried patching the hal.o in CVS to > > deal with the ELF magic number and hit problems with DMA aborts on rx so > > went off to do other work. I'm trying to get a new version together for > > folks to use but am busy with real work. All my successful testing was > > done w/ a version of the hal that I am not (yet) comfortable distributing. > > > > The above looks like something outside the driver. I forced the > > ethernet header structure to be __packed to deal with a compiler issue; > > do you have that change (you don't indicate what code you are running or > > how you built it)? > > Hmmm, I'm doing what my kids do, just assume everyone knows what I do. :-) > > I have basically followed the instructions you posted when you merged > the Gateworks/Avila code into -current. So it was -current build on the > day I posted. I tried both with the hal in -current (using wackelf) and > the 0909 hal you mentioned in your email. The kernel used the AVILA conf > in -current changed to use the CF as root, with nfs and bootp removed > and these added: > > options MROUTING > options IPFIREWALL > options IPFIREWALL_FORWARD > options IPFIREWALL_DEFAULT_TO_ACCEPT > options IPFIREWALL_VERBOSE > options IPDIVERT > options DUMMYNET > > options IPSEC > options IPSEC_ESP > > Thinking about it, I can remove all of them and try again to make sure > it isn't one of them doing it. > > The version of net/ethernet.h that I use is 1.27 and struct ether_header > is marked as __packed. > > What is strange to me is that according to tcpdump on the arm box itself, > the outgoing packets looks ok. Ok, I built a kernel without all those options, but it didn't make a difference. I also tried sta mode and it still looks the same. Some new info that I have is that when I do a tcpdump on the arm box itself, adding -y IEEE802_11_RADIO makes a difference. Without it the outgoing packets looks ok, but with it 2 bytes are added between the ether (802.11) header and the ip(v6) header. Here is a packet without IEEE802_11_RADIO: tcpdump -p -i ath0 -n -s 0 -X -c 5 -e 11:59:06.009123 00:02:6f:34:21:a2 > 33:33:00:00:00:01, ethertype IPv6 (0x86dd), length 94: fd9c:6829:597c:10:202:6fff:fe34:21a2.698 > ff0e::1.698: UDP, length 32 0x0000: 6000 0000 0028 1101 fd9c 6829 597c 0010 `....(....h)Y|.. 0x0010: 0202 6fff fe34 21a2 ff0e 0000 0000 0000 ..o..4!......... 0x0020: 0000 0000 0000 0001 02ba 02ba 0028 2b63 .............(+c 0x0030: 0020 e1db c948 001c fd9c 6829 597c 0010 .....H....h)Y|.. 0x0040: 0202 6fff fe34 21a2 0100 7bfd 0000 0503 ..o..4!...{..... Here is a similar packet with IEEE802_11_RADIO: tcpdump -p -i ath0 -n -s 0 -X -c 5 -e -y IEEE802_11_RADIO 11:59:30.249119 2431813630us tsft short preamble 18.0 Mb/s 2412 MHz (0x0480) 40dBm tx power antenna 0 BSSID:00:02:6f:22:95:47 SA:00:02:6f:34:21:a2 DA:33:33:00:00:00:01 LLC, dsap SNAP (0xaa), ssap SNAP (0xaa), cmd 0x03: oui Ethernet (0x000000), ethertype IPv6 (0x86dd): 1101:fd9c:6829:597c:10:202:6fff:fe34 > 21a2:ff0e::: [|HBH] 0x0000: aaaa 0300 0000 86dd 0000 6000 0000 0028 ..........`....( 0x0010: 1101 fd9c 6829 597c 0010 0202 6fff fe34 ....h)Y|....o..4 0x0020: 21a2 ff0e 0000 0000 0000 0000 0000 0000 !............... 0x0030: 0001 02ba 02ba 0028 2b49 0020 e1e6 c948 .......(+I.....H 0x0040: 001c fd9c 6829 597c 0010 0202 6fff fe34 ....h)Y|....o..4 0x0050: 21a2 0100 7c0c 0000 0503 !...|..... Note the 0000 between 86dd and 6000. On a non-arm box a similar packet looks like this: 12:39:21.640024 17221765257721674776us tsft short preamble 6.0 Mb/s 5785 MHz (0x0140) -69dB signal -96dB noise antenna 1 DA:33:33:00:00:00:01 SA:00:80:48:41:99:86 BSSID:02:02:6f:41:19:1f LLC, dsap SNAP (0xaa), ssap SNAP (0xaa), cmd 0x03: oui Ethernet (0x000000), ethertype IPv6 (0x86dd): fd9c:6829:597c:10:280:48ff:fe41:9986.698 > ff0e::1.698: UDP, length 200 0x0000: aaaa 0300 0000 86dd 6000 0000 00d0 1101 ........`....... 0x0010: fd9c 6829 597c 0010 0280 48ff fe41 9986 ..h)Y|....H..A.. 0x0020: ff0e 0000 0000 0000 0000 0000 0000 0001 ................ 0x0030: 02ba 02ba 00d0 d30c 00c8 d754 cae8 0030 ...........T...0 0x0040: fd9c 6829 597c 0020 0280 48ff fe7e 6005 ..h)Y|....H..~`. ... I have checked that net/ethernet.h is the latest with ether_header marked as __packed. John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-arm@FreeBSD.ORG Thu Nov 30 14:21:51 2006 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9B15616A416 for ; Thu, 30 Nov 2006 14:21:51 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D35843CB3 for ; Thu, 30 Nov 2006 14:21:41 +0000 (GMT) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 4A63333CBE; Thu, 30 Nov 2006 16:21:46 +0200 (SAST) Date: Thu, 30 Nov 2006 16:21:46 +0200 From: John Hay To: Sam Leffler Message-ID: <20061130142146.GA50022@zibbi.meraka.csir.co.za> References: <4560F437.5060402@errno.com> <20061128132902.GA19150@zibbi.meraka.csir.co.za> <456DD60C.2000208@errno.com> <20061129193842.GA98569@zibbi.meraka.csir.co.za> <20061130120217.GA41346@zibbi.meraka.csir.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061130120217.GA41346@zibbi.meraka.csir.co.za> User-Agent: Mutt/1.4.2.1i Cc: freebsd-arm@freebsd.org Subject: Re: Gateworks 2348 and ath problem X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Nov 2006 14:21:51 -0000 > > Ok, I built a kernel without all those options, but it didn't make a > difference. I also tried sta mode and it still looks the same. Some > new info that I have is that when I do a tcpdump on the arm box itself, > adding -y IEEE802_11_RADIO makes a difference. Without it the outgoing > packets looks ok, but with it 2 bytes are added between the ether (802.11) > header and the ip(v6) header. Ok, I found the problem. Using LLC_SNAPFRAMELEN works better than sizeof(struct llc). LLC_SNAPFRAMELEN is defined as 8 and sizeof() returns 10. Doing a grep in net/ if see that LLC_SNAPFRAMELEN is used a lot, so I guess this is the correct way go. I nobody has anything against it, I can commit it. With this patch traffic seems to flow normally over the atheros wifi link. I have not done too much testing, but olsrd works and I can ssh to it. I see a lot of rix packets: Nov 30 15:49:29 arm-tst kernel: rix 2632 (0) bad ratekbps 0 mode 1 Nov 30 15:49:29 arm-tst kernel: rix 2632 (0) bad ratekbps 0 mode 1 Nov 30 15:49:30 arm-tst kernel: rix 2633 (0) bad ratekbps 0 mode 1 Nov 30 15:49:30 arm-tst kernel: rix 2633 (0) bad ratekbps 0 mode 1 Nov 30 15:49:30 arm-tst kernel: rix 2601 (0) bad ratekbps 0 mode 1 I don't see it on our wrap and soekris boxes, but they are running 6-stable... Well I have seen it, but that was if I put the link in 11b mode, not in 11a or 11g mode. I'm using 11a at the moment. Sam, are they related to the rate changes you made recently? John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org --- net80211/ieee80211_input.c.org Fri Nov 24 10:57:10 2006 +++ net80211/ieee80211_input.c Thu Nov 30 15:27:33 2006 @@ -736,8 +736,8 @@ struct ether_header *eh; struct llc *llc; - if (m->m_len < hdrlen + sizeof(*llc) && - (m = m_pullup(m, hdrlen + sizeof(*llc))) == NULL) { + if (m->m_len < hdrlen + LLC_SNAPFRAMELEN && + (m = m_pullup(m, hdrlen + LLC_SNAPFRAMELEN)) == NULL) { /* XXX stat, msg */ return NULL; } @@ -746,7 +746,7 @@ if (llc->llc_dsap == LLC_SNAP_LSAP && llc->llc_ssap == LLC_SNAP_LSAP && llc->llc_control == LLC_UI && llc->llc_snap.org_code[0] == 0 && llc->llc_snap.org_code[1] == 0 && llc->llc_snap.org_code[2] == 0) { - m_adj(m, hdrlen + sizeof(struct llc) - sizeof(*eh)); + m_adj(m, hdrlen + LLC_SNAPFRAMELEN - sizeof(*eh)); llc = NULL; } else { m_adj(m, hdrlen - sizeof(*eh)); --- net80211/ieee80211_output.c.org Fri Nov 24 10:57:10 2006 +++ net80211/ieee80211_output.c Thu Nov 30 15:22:19 2006 @@ -500,7 +500,7 @@ ieee80211_mbuf_adjust(struct ieee80211com *ic, int hdrsize, struct ieee80211_key *key, struct mbuf *m) { -#define TO_BE_RECLAIMED (sizeof(struct ether_header) - sizeof(struct llc)) +#define TO_BE_RECLAIMED (sizeof(struct ether_header) - LLC_SNAPFRAMELEN) int needed_space = hdrsize; if (key != NULL) { @@ -527,7 +527,7 @@ * We know we are called just before stripping an Ethernet * header and prepending an LLC header. This means we know * there will be - * sizeof(struct ether_header) - sizeof(struct llc) + * sizeof(struct ether_header) - LLC_SNAPFRAMELEN * bytes recovered to which we need additional space for the * 802.11 header and any crypto header. */ @@ -675,7 +675,7 @@ } /* NB: this could be optimized because of ieee80211_mbuf_adjust */ - m_adj(m, sizeof(struct ether_header) - sizeof(struct llc)); + m_adj(m, sizeof(struct ether_header) - LLC_SNAPFRAMELEN); llc = mtod(m, struct llc *); llc->llc_dsap = llc->llc_ssap = LLC_SNAP_LSAP; llc->llc_control = LLC_UI; From owner-freebsd-arm@FreeBSD.ORG Thu Nov 30 15:12:06 2006 Return-Path: X-Original-To: freebsd-arm@FreeBSD.ORG Delivered-To: freebsd-arm@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 064CF16A417 for ; Thu, 30 Nov 2006 15:12:06 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41BFD43CA2 for ; Thu, 30 Nov 2006 15:11:57 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id kAUF94pI036935; Thu, 30 Nov 2006 08:09:09 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 30 Nov 2006 08:09:53 -0700 (MST) Message-Id: <20061130.080953.-490996389.imp@bsdimp.com> To: jhay@meraka.org.za From: "M. Warner Losh" In-Reply-To: <20061130142146.GA50022@zibbi.meraka.csir.co.za> References: <20061129193842.GA98569@zibbi.meraka.csir.co.za> <20061130120217.GA41346@zibbi.meraka.csir.co.za> <20061130142146.GA50022@zibbi.meraka.csir.co.za> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 30 Nov 2006 08:09:09 -0700 (MST) Cc: freebsd-arm@FreeBSD.ORG Subject: Re: Gateworks 2348 and ath problem X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Nov 2006 15:12:06 -0000 In message: <20061130142146.GA50022@zibbi.meraka.csir.co.za> John Hay writes: : > : > Ok, I built a kernel without all those options, but it didn't make a : > difference. I also tried sta mode and it still looks the same. Some : > new info that I have is that when I do a tcpdump on the arm box itself, : > adding -y IEEE802_11_RADIO makes a difference. Without it the outgoing : > packets looks ok, but with it 2 bytes are added between the ether (802.11) : > header and the ip(v6) header. : : Ok, I found the problem. Using LLC_SNAPFRAMELEN works better than : sizeof(struct llc). LLC_SNAPFRAMELEN is defined as 8 and sizeof() : returns 10. Doing a grep in net/ if see that LLC_SNAPFRAMELEN is used : a lot, so I guess this is the correct way go. I nobody has anything : against it, I can commit it. NetBSD marks it as __packed. That might be a safer patch. NetBSD only uses LLC_SNAPFRAMELEN in token ring code. It might be even better if we could catch these things at compile time, but doing so may be a bit of a pita to setup (how do you know all the relevant types to check). Warner : With this patch traffic seems to flow normally over the atheros wifi : link. I have not done too much testing, but olsrd works and I can ssh : to it. : : I see a lot of rix packets: : : Nov 30 15:49:29 arm-tst kernel: rix 2632 (0) bad ratekbps 0 mode 1 : Nov 30 15:49:29 arm-tst kernel: rix 2632 (0) bad ratekbps 0 mode 1 : Nov 30 15:49:30 arm-tst kernel: rix 2633 (0) bad ratekbps 0 mode 1 : Nov 30 15:49:30 arm-tst kernel: rix 2633 (0) bad ratekbps 0 mode 1 : Nov 30 15:49:30 arm-tst kernel: rix 2601 (0) bad ratekbps 0 mode 1 : : I don't see it on our wrap and soekris boxes, but they are running : 6-stable... Well I have seen it, but that was if I put the link in : 11b mode, not in 11a or 11g mode. I'm using 11a at the moment. : : Sam, are they related to the rate changes you made recently? : : John : -- : John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org : : : --- net80211/ieee80211_input.c.org Fri Nov 24 10:57:10 2006 : +++ net80211/ieee80211_input.c Thu Nov 30 15:27:33 2006 : @@ -736,8 +736,8 @@ : struct ether_header *eh; : struct llc *llc; : : - if (m->m_len < hdrlen + sizeof(*llc) && : - (m = m_pullup(m, hdrlen + sizeof(*llc))) == NULL) { : + if (m->m_len < hdrlen + LLC_SNAPFRAMELEN && : + (m = m_pullup(m, hdrlen + LLC_SNAPFRAMELEN)) == NULL) { : /* XXX stat, msg */ : return NULL; : } : @@ -746,7 +746,7 @@ : if (llc->llc_dsap == LLC_SNAP_LSAP && llc->llc_ssap == LLC_SNAP_LSAP && : llc->llc_control == LLC_UI && llc->llc_snap.org_code[0] == 0 && : llc->llc_snap.org_code[1] == 0 && llc->llc_snap.org_code[2] == 0) { : - m_adj(m, hdrlen + sizeof(struct llc) - sizeof(*eh)); : + m_adj(m, hdrlen + LLC_SNAPFRAMELEN - sizeof(*eh)); : llc = NULL; : } else { : m_adj(m, hdrlen - sizeof(*eh)); : --- net80211/ieee80211_output.c.org Fri Nov 24 10:57:10 2006 : +++ net80211/ieee80211_output.c Thu Nov 30 15:22:19 2006 : @@ -500,7 +500,7 @@ : ieee80211_mbuf_adjust(struct ieee80211com *ic, int hdrsize, : struct ieee80211_key *key, struct mbuf *m) : { : -#define TO_BE_RECLAIMED (sizeof(struct ether_header) - sizeof(struct llc)) : +#define TO_BE_RECLAIMED (sizeof(struct ether_header) - LLC_SNAPFRAMELEN) : int needed_space = hdrsize; : : if (key != NULL) { : @@ -527,7 +527,7 @@ : * We know we are called just before stripping an Ethernet : * header and prepending an LLC header. This means we know : * there will be : - * sizeof(struct ether_header) - sizeof(struct llc) : + * sizeof(struct ether_header) - LLC_SNAPFRAMELEN : * bytes recovered to which we need additional space for the : * 802.11 header and any crypto header. : */ : @@ -675,7 +675,7 @@ : } : : /* NB: this could be optimized because of ieee80211_mbuf_adjust */ : - m_adj(m, sizeof(struct ether_header) - sizeof(struct llc)); : + m_adj(m, sizeof(struct ether_header) - LLC_SNAPFRAMELEN); : llc = mtod(m, struct llc *); : llc->llc_dsap = llc->llc_ssap = LLC_SNAP_LSAP; : llc->llc_control = LLC_UI; : _______________________________________________ : 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 Nov 30 15:32:00 2006 Return-Path: X-Original-To: freebsd-arm@FreeBSD.ORG Delivered-To: freebsd-arm@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 21BF716A417 for ; Thu, 30 Nov 2006 15:32:00 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [146.64.24.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 778FD43CB1 for ; Thu, 30 Nov 2006 15:31:42 +0000 (GMT) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 3EB6133CBD; Thu, 30 Nov 2006 17:31:49 +0200 (SAST) Date: Thu, 30 Nov 2006 17:31:49 +0200 From: John Hay To: "M. Warner Losh" Message-ID: <20061130153149.GA53172@zibbi.meraka.csir.co.za> References: <20061129193842.GA98569@zibbi.meraka.csir.co.za> <20061130120217.GA41346@zibbi.meraka.csir.co.za> <20061130142146.GA50022@zibbi.meraka.csir.co.za> <20061130.080953.-490996389.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061130.080953.-490996389.imp@bsdimp.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-arm@FreeBSD.ORG Subject: Re: Gateworks 2348 and ath problem X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Nov 2006 15:32:00 -0000 On Thu, Nov 30, 2006 at 08:09:53AM -0700, M. Warner Losh wrote: > In message: <20061130142146.GA50022@zibbi.meraka.csir.co.za> > John Hay writes: > : > > : > Ok, I built a kernel without all those options, but it didn't make a > : > difference. I also tried sta mode and it still looks the same. Some > : > new info that I have is that when I do a tcpdump on the arm box itself, > : > adding -y IEEE802_11_RADIO makes a difference. Without it the outgoing > : > packets looks ok, but with it 2 bytes are added between the ether (802.11) > : > header and the ip(v6) header. > : > : Ok, I found the problem. Using LLC_SNAPFRAMELEN works better than > : sizeof(struct llc). LLC_SNAPFRAMELEN is defined as 8 and sizeof() > : returns 10. Doing a grep in net/ if see that LLC_SNAPFRAMELEN is used > : a lot, so I guess this is the correct way go. I nobody has anything > : against it, I can commit it. > > NetBSD marks it as __packed. That might be a safer patch. NetBSD > only uses LLC_SNAPFRAMELEN in token ring code. Well struct llc is marked as __packed. See sys/net/if_llc.h. There is a union llc_un inside it that isn't and I have tried with it marked as __packed, but it didn't help. > It might be even better if we could catch these things at compile > time, but doing so may be a bit of a pita to setup (how do you know > all the relevant types to check). John -- John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-arm@FreeBSD.ORG Thu Nov 30 16:51:38 2006 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3B66016A4B3 for ; Thu, 30 Nov 2006 16:51:38 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1EA843F41 for ; Thu, 30 Nov 2006 16:41:04 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.248] (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id kAUGfAXq028620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Nov 2006 08:41:13 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <456F09A6.7090609@errno.com> Date: Thu, 30 Nov 2006 08:41:10 -0800 From: Sam Leffler User-Agent: Thunderbird 1.5.0.7 (X11/20060920) MIME-Version: 1.0 To: John Hay References: <4560F437.5060402@errno.com> <20061128132902.GA19150@zibbi.meraka.csir.co.za> <456DD60C.2000208@errno.com> <20061129193842.GA98569@zibbi.meraka.csir.co.za> <20061130120217.GA41346@zibbi.meraka.csir.co.za> <20061130142146.GA50022@zibbi.meraka.csir.co.za> In-Reply-To: <20061130142146.GA50022@zibbi.meraka.csir.co.za> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: Gateworks 2348 and ath problem X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Nov 2006 16:51:38 -0000 John Hay wrote: >> Ok, I built a kernel without all those options, but it didn't make a >> difference. I also tried sta mode and it still looks the same. Some >> new info that I have is that when I do a tcpdump on the arm box itself, >> adding -y IEEE802_11_RADIO makes a difference. Without it the outgoing >> packets looks ok, but with it 2 bytes are added between the ether (802.11) >> header and the ip(v6) header. > > Ok, I found the problem. Using LLC_SNAPFRAMELEN works better than > sizeof(struct llc). LLC_SNAPFRAMELEN is defined as 8 and sizeof() > returns 10. Doing a grep in net/ if see that LLC_SNAPFRAMELEN is used > a lot, so I guess this is the correct way go. I nobody has anything > against it, I can commit it. > > With this patch traffic seems to flow normally over the atheros wifi > link. I have not done too much testing, but olsrd works and I can ssh > to it. Very strange. I did not need this change on my systems and was not seeing the problem. But what you found makes sense. > > I see a lot of rix packets: > > Nov 30 15:49:29 arm-tst kernel: rix 2632 (0) bad ratekbps 0 mode 1 > Nov 30 15:49:29 arm-tst kernel: rix 2632 (0) bad ratekbps 0 mode 1 > Nov 30 15:49:30 arm-tst kernel: rix 2633 (0) bad ratekbps 0 mode 1 > Nov 30 15:49:30 arm-tst kernel: rix 2633 (0) bad ratekbps 0 mode 1 > Nov 30 15:49:30 arm-tst kernel: rix 2601 (0) bad ratekbps 0 mode 1 > > I don't see it on our wrap and soekris boxes, but they are running > 6-stable... Well I have seen it, but that was if I put the link in > 11b mode, not in 11a or 11g mode. I'm using 11a at the moment. > > Sam, are they related to the rate changes you made recently? No they are unrelated. These are the complaints I saw in my testing and hadn't had time to resolve. They appear to be caused by extracting bogus rate codes from the h/w descriptors and then feeding them back into the rate control module. I'm still trying to get a new hal out for testing and that hal will have the descriptor state split into cache+uncached areas so I'd prefer to chase any problems like this w/ that code and not code that's about to be replaced. Sam From owner-freebsd-arm@FreeBSD.ORG Thu Nov 30 18:24:07 2006 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 691CE16A407 for ; Thu, 30 Nov 2006 18:24:07 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7318043CAA for ; Thu, 30 Nov 2006 18:23:57 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id kAUIKnQ0038805; Thu, 30 Nov 2006 11:20:50 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 30 Nov 2006 11:21:37 -0700 (MST) Message-Id: <20061130.112137.-432838078.imp@bsdimp.com> To: jhay@meraka.org.za From: "M. Warner Losh" In-Reply-To: <20061130153149.GA53172@zibbi.meraka.csir.co.za> References: <20061130142146.GA50022@zibbi.meraka.csir.co.za> <20061130.080953.-490996389.imp@bsdimp.com> <20061130153149.GA53172@zibbi.meraka.csir.co.za> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 30 Nov 2006 11:20:51 -0700 (MST) Cc: freebsd-arm@freebsd.org Subject: Re: Gateworks 2348 and ath problem X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 30 Nov 2006 18:24:07 -0000 In message: <20061130153149.GA53172@zibbi.meraka.csir.co.za> John Hay writes: : On Thu, Nov 30, 2006 at 08:09:53AM -0700, M. Warner Losh wrote: : > In message: <20061130142146.GA50022@zibbi.meraka.csir.co.za> : > John Hay writes: : > : > : > : > Ok, I built a kernel without all those options, but it didn't make a : > : > difference. I also tried sta mode and it still looks the same. Some : > : > new info that I have is that when I do a tcpdump on the arm box itself, : > : > adding -y IEEE802_11_RADIO makes a difference. Without it the outgoing : > : > packets looks ok, but with it 2 bytes are added between the ether (802.11) : > : > header and the ip(v6) header. : > : : > : Ok, I found the problem. Using LLC_SNAPFRAMELEN works better than : > : sizeof(struct llc). LLC_SNAPFRAMELEN is defined as 8 and sizeof() : > : returns 10. Doing a grep in net/ if see that LLC_SNAPFRAMELEN is used : > : a lot, so I guess this is the correct way go. I nobody has anything : > : against it, I can commit it. : > : > NetBSD marks it as __packed. That might be a safer patch. NetBSD : > only uses LLC_SNAPFRAMELEN in token ring code. : : Well struct llc is marked as __packed. See sys/net/if_llc.h. There is : a union llc_un inside it that isn't and I have tried with it marked : as __packed, but it didn't help. I noticed that :-(. Counting bytes tells me that it should work. Lemme take a look to see why. It may be the harbinger of bigger issues... Warner : > It might be even better if we could catch these things at compile : > time, but doing so may be a bit of a pita to setup (how do you know : > all the relevant types to check). : : John : -- : John Hay -- John.Hay@meraka.csir.co.za / jhay@FreeBSD.org : :