Date: Mon, 11 Feb 2013 12:05:04 +0100 From: Mats Mellstrand <mats@exmandato.se> To: Daisuke Aoyama <aoyama@peach.ne.jp> Cc: freebsd-arm@freebsd.org, ticso@cicely.de Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) Message-ID: <016DDBBF-D502-4C76-96B5-BEE2D46FC6CC@exmandato.se> In-Reply-To: <E614FD5C-4177-4628-BAB7-9BF4D3A6DF52@exmandato.se> References: <B5F827FF91C94FF2AFEE00194A2BB2C5@ad.peach.ne.jp> <B508111FCE534B2CBA61F4D1EC1078D3@ad.peach.ne.jp> <D3ABE3919EA74D668DB060952B5CD8C0@ad.peach.ne.jp> <2659960079254C38ACD2F1DCBB7A1A19@ad.peach.ne.jp> <E48DEAF481F74C69A1BC7A01F2B8E74A@ad.peach.ne.jp> <D867259F89CF44409C2359527D0263D4@ad.peach.ne.jp> <722ED669-A682-4F25-A65B-1E2FF8CFAA4D@exmandato.se> <C46F868CE2644D8AA6F608A41D806128@ad.peach.ne.jp> <DCCE15D5-9AAD-4249-8EBA-29F22B04288F@exmandato.se> <20130131001553.GC67562@cicely7.cicely.de> <9E78813F3BF946A4A2FCEA2C363A847E@ad.peach.ne.jp> <E614FD5C-4177-4628-BAB7-9BF4D3A6DF52@exmandato.se>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,=20 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 On 31 jan 2013, at 16:17, Mats Mellstrand <mats@exmandato.se> wrote: > Hi >=20 > Thanks!=20 >=20 > Your patch works fine! >=20 > /mm >=20 > On 31 jan 2013, at 16:07, Daisuke Aoyama <aoyama@peach.ne.jp> wrote: >=20 >> Hi, >>=20 >> I found a solution. When disabling hardware check sum offload, it = works. >> (# ifconfig ue0 -rxcsum) >>=20 >> Please check new kernel or apply the patch attached this mail. >> http://www.peach.ne.jp/archives/rpi/kernel/kernel-20130131.gz >>=20 >> Thanks, >> --=20 >> Daisuke Aoyama >>=20 >> -------------------------------------------------- >> From: "Bernd Walter" <ticso@cicely7.cicely.de> >> Sent: Thursday, January 31, 2013 9:15 AM >> To: "Mats Mellstrand" <mats@exmandato.se> >> Cc: "Daisuke Aoyama" <aoyama@peach.ne.jp>; <freebsd-arm@freebsd.org> >> Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot = + ubldr) >>=20 >>> On Wed, Jan 30, 2013 at 06:28:12PM +0100, Mats Mellstrand wrote: >>>> Hi >>>>=20 >>>>=20 >>>> On 30 jan 2013, at 17:28, Daisuke Aoyama <aoyama@peach.ne.jp> = wrote: >>>>=20 >>>>>> 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. >>>>>=20 >>>>> Sorry, I didn't check with ue0. >>>>> It seems if_smsc is buggy. >>>>> I'm using axe for testing. It works IPv6. >>>>>=20 >>>>>> 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=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric = 0 mtu 1500 >>>>>> options=3D80008<VLAN_MTU,LINKSTATE> >>>>>> 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=3D21<PERFORMNUD,AUTO_LINKLOCAL> >>>>>> media: Ethernet autoselect (100baseTX <full-duplex>) >>>>>> status: active >>>>>=20 >>>>> If possible, please try other ether device (include wireless LAN). >>>>=20 >>>>=20 >>>> Thanks! The interface run0/wlan0 works fine with IPv6 >>>=20 >>> 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. >>>=20 >>> 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... >>>=20 >>> 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. >>>=20 >>>=20 >>> --=20 >>> B.Walter <bernd@bwct.de> http://www.bwct.de >>> Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner = uvm. >> <smsc.patch> >=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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?016DDBBF-D502-4C76-96B5-BEE2D46FC6CC>