FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr)

Mon Feb 11 11:05:13 UTC 2013

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 at 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 at exmandato.se> wrote:

> Hi
> 
> Thanks! 
> 
> Your patch works fine!
> 
> /mm
> 
> On 31 jan 2013, at 16:07, Daisuke Aoyama <aoyama at peach.ne.jp> 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" <ticso at cicely7.cicely.de>
>> Sent: Thursday, January 31, 2013 9:15 AM
>> To: "Mats Mellstrand" <mats at exmandato.se>
>> Cc: "Daisuke Aoyama" <aoyama at peach.ne.jp>; <freebsd-arm at freebsd.org>
>> 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 <aoyama at peach.ne.jp> 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 at 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 at raspberry-pi:~ % ifconfig ue1
>>>>>> ue1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>>>>>>      options=80008<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=21<PERFORMNUD,AUTO_LINKLOCAL>
>>>>>>      media: Ethernet autoselect (100baseTX <full-duplex>)
>>>>>>      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 <bernd at bwct.de> http://www.bwct.de
>>> Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
>> <smsc.patch>
> 
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"