From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 16:14:09 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 362BC2DA for ; Mon, 11 Feb 2013 16:14:09 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 0E73FC0F for ; Mon, 11 Feb 2013 16:14:00 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r1BGE0FW066200 for ; Mon, 11 Feb 2013 09:14:00 -0700 (MST) (envelope-from ian@FreeBSD.org) 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 r1BGDvPo039730; Mon, 11 Feb 2013 09:13:57 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) From: Ian Lepore To: Mats Mellstrand In-Reply-To: <016DDBBF-D502-4C76-96B5-BEE2D46FC6CC@exmandato.se> References: <2659960079254C38ACD2F1DCBB7A1A19@ad.peach.ne.jp> <722ED669-A682-4F25-A65B-1E2FF8CFAA4D@exmandato.se> <20130131001553.GC67562@cicely7.cicely.de> <9E78813F3BF946A4A2FCEA2C363A847E@ad.peach.ne.jp> <016DDBBF-D502-4C76-96B5-BEE2D46FC6CC@exmandato.se> Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Feb 2013 09:13:57 -0700 Message-ID: <1360599237.4545.94.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, ticso@cicely.de 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, 11 Feb 2013 16:14:09 -0000 On Mon, 2013-02-11 at 12:05 +0100, Mats Mellstrand wrote: > Hi, > > In trying to install the ports collection on my RPi, the following happens: > > kmem_malloc(4096): kmem_map too small: 12582912 total allocated > KDB: enter: panic > [ thread pid 27505 tid 100053 ] > Stopped at $d: ldrb r15, [r15, r15, ror r15]! > > Suggestions? (more than not installing the ports collection) > > I'm running: > > FreeBSD 10.0-CURRENT #0 r246066M: Thu Jan 31 23:24:06 JST 2013 aoyama@fbs.local:/usr/obj-rpi-clang/arm.armv6/usr/src/sys/RPI-B-test16 arm > > /mm > You need fresher kernel sources, specifically the change in r246204 (which can be applied without updating everything else, if need be). -- Ian > > On 31 jan 2013, at 16:17, Mats Mellstrand wrote: > > > Hi > > > > Thanks! > > > > Your patch works fine! > > > > /mm > > > > On 31 jan 2013, at 16:07, Daisuke Aoyama wrote: > > > >> Hi, > >> > >> I found a solution. When disabling hardware check sum offload, it works. > >> (# ifconfig ue0 -rxcsum) > >> > >> Please check new kernel or apply the patch attached this mail. > >> http://www.peach.ne.jp/archives/rpi/kernel/kernel-20130131.gz > >> > >> Thanks, > >> -- > >> Daisuke Aoyama > >> > >> -------------------------------------------------- > >> From: "Bernd Walter" > >> Sent: Thursday, January 31, 2013 9:15 AM > >> To: "Mats Mellstrand" > >> Cc: "Daisuke Aoyama" ; > >> Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) > >> > >>> On Wed, Jan 30, 2013 at 06:28:12PM +0100, Mats Mellstrand wrote: > >>>> Hi > >>>> > >>>> > >>>> On 30 jan 2013, at 17:28, Daisuke Aoyama wrote: > >>>> > >>>>>> The image works, but I can't get IPv6 to work as expected. > >>>>>> I can ping6 to and from my Raspberry but trying to ssh in to RPIs IPv6 address just hangs. > >>>>>> The same happens when I try to ssh out from RPI to a IPv6 address. > >>>>>> IPv4 works. > >>>>> > >>>>> Sorry, I didn't check with ue0. > >>>>> It seems if_smsc is buggy. > >>>>> I'm using axe for testing. It works IPv6. > >>>>> > >>>>>> pi@raspberry-pi:~ % w > >>>>>> 4:19PM up 2:50, 3 users, load averages: 0.00, 0.00, 0.00 > >>>>>> USER TTY FROM LOGIN@ IDLE WHAT > >>>>>> root u0 - 4:11PM - -csh (csh) > >>>>>> pi pts/0 172.18.0.20 4:12PM - _su (csh) > >>>>>> pi pts/1 2001:3e0:6cf:18:20c:29ff 4:19PM - w > >>>>>> pi@raspberry-pi:~ % ifconfig ue1 > >>>>>> ue1: flags=8843 metric 0 mtu 1500 > >>>>>> options=80008 > >>>>>> ether 10:6f:3f:66:75:1d > >>>>>> inet6 fe80::126f:3fff:fe66:751d%ue1 prefixlen 64 scopeid 0x3 > >>>>>> inet 172.18.0.99 netmask 0xffff0000 broadcast 172.18.255.255 > >>>>>> inet6 2001:3e0:6cf:18:126f:3fff:fe66:751d prefixlen 64 > >>>>>> nd6 options=21 > >>>>>> media: Ethernet autoselect (100baseTX ) > >>>>>> status: active > >>>>> > >>>>> If possible, please try other ether device (include wireless LAN). > >>>> > >>>> > >>>> Thanks! The interface run0/wlan0 works fine with IPv6 > >>> > >>> If IPv4 works, then usually multicast hash support is broken in driver. > >>> It is hard to debug if you are unaware of the undelying protocol details. > >>> Assuming machine B is the one with the brokmen driver. > >>> You can't ping6 from A to B until B sends anything to A. > >>> This way A learns MAC address from B without needing the neighbor > >>> discovery packet (ARP replacement, although ND6 has other purpose as well), > >>> which is send via multicast, to be received by machine B. > >>> Putting an interface into promiscuous helps as workaround, because then > >>> the interface won't filter anything and all multicast frames are received > >>> as well, unless promiscuous support is broken too. > >>> If ping6 works both sides than ssh should do as well, but only if you > >>> try before the nd6 entries expire. > >>> A simple ping6 test might look as if it works if you started ping6 from > >>> B to A before trying from A to B, so A already has nd6 entry for B. > >>> You can lookup nd6 table by issuing ndp -an command. > >>> > >>> Some low level details. > >>> A system has an IPv6 adress configured on it's interface. > >>> It also joins a multicast group for that IP address. > >>> There is a formular to calculate the multicast address from the unicast(*) > >>> address. > >>> (*) when I write unicast I also mean link local and anycast as well. > >>> You can lookup all IP addresses including multicast by netstat -ia. > >>> A system, which wants to send an IPv6 packet to an IPv6 address at the > >>> same LAN needs the MAC address of the machine, which has the IPv6 address > >>> configured. > >>> Unless it has the address in his neighbor address cache already it > >>> sends an inquiry (Neighbor Discovery ND) to the multicast address - with > >>> IPv4 it was send via broadcast. > >>> It knows the multicast address by using the same formular from the > >>> targeting unicast address as the host owning that address. > >>> This way the inquiry packet won't disturb every host allowing larger LANs. > >>> Some IPv6 unicast addresses share the same multicast, so there are some > >>> collisions, but less than with broadcast. > >>> Multicast however also needs to be transfered using target MAC addresses. > >>> There is a formular which translates an IPv6 multicast address to an > >>> ethernet MAC address, giving more address collisions. > >>> Network interfaces can't filter countless individual MAC addresses, so > >>> there is a filter layer as well, usually containg 64 bits, with each > >>> bit allowing a given set of multicast MAC addresses. > >>> The formular from MAC address to filter bit is hardware dependend, > >>> although most use the plain old NE2000 formular, there are exeptions > >>> with other formular and chips using more bits allowing finer filters. > >>> This point is often done wrong in drivers - some forgot to take care > >>> about multicast bits completely, some use the standard NE2000 filter > >>> with hardware using something different, etc... > >>> > >>> PS: > >>> In the end there are many collisions, only to be avoided by using > >>> multicast aware switches in large LANs and a few multicast addresses. > >>> Therefor also wise to avoid some unicast addresses as they collide > >>> with anyhost or other popular multicast addresses. > >>> > >>> > >>> -- > >>> B.Walter http://www.bwct.de > >>> Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. > >> > > > > _______________________________________________ > > 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"