Re: Some issue in dsm-g600 using netbsd 6.0 release

[Frank Wille <frank%phoenix.owl.de@localhost>]

On Sun, 11 Nov 2012 14:57:14 +0100
Charles Brown <obigiankenobi%gmail.com@localhost> wrote:

> I'm trying to use netbsd 6.0 in dsm-g600.
> I have some issue:
> 1) I Can't install packages available in:
> 
> ftp://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/sandpoint/6.0_2012Q1/All/
> 
> Installation of Samba3.6 was ok, but when I try to start daemons, I
> have problems with missing libraries (libcrypto 7.0).

Those package are old. NetBSD6 comes with libctypto 8.0.
Seems that the 2012Q3 packages have not yet been built.


> 2) When I try to build from scratch Samba 3.6.9 the system hangs
> after a few hours: CTRL+T and DDB are available, but seems that under
> heavy disk activity netbsd hangs with a missing interrupt (?).

I had the same problem on my Synology DS-101g+ with late 5.99.x versions
and the 6.0RCs. But the released 6.0 version works rock-solid for me!

I have compiled a Gigabyte of pkgsrc over the last three weeks, on this
poor little machine, without any problem.

Maybe it has something to do with the mutex problems in all PowerPC
ports (refer to PR #44387,
http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=44387).

A workaround is to use real spin-mutexes in the kernel, either by defining
the option "LOCKDEBUG" or "FULL". I used "options FULL" for my DS101g+,
because I don't want the whole LOCKDEBUG code. Since then I had no such
instabilities anymore. Maybe it is related.

Trying to build samba 3.6.6 from pkgsrc-2012Q3 now.


> 3) When I use static ip addresses, everything is ok, but enabling
> DHCLIENT in rc.conf, a crash dump happens on FTP file transfert

It is hard to believe that receiving your IP-address with DHCP or not
makes a difference for the actual FTP transfer. This is always reproducible?


> trap: kernel read DSI trap @ 0xe0c5195b by 0x9b9f4
> (DSISR 0x40000000, err=14), lr 0x9bd78
> panic: trap
> cpu0: Begin traceback...
> 0x00688770: at panic+0x4c
> 0x006887b0: at trap+0x104
> 0x00688840: kernel DSI read trap @ 0xe0c5195b by m_xhalf+0x9c:
> srr1=0x9030 r1=0x688910 cr=0x40002048 xer=0 ctr=0x9bc50
> dsisr=0x40000000 0x00688910: at 0x1a1055c
> 0x006889a0: at _bpf_mtap+0x118
> 0x006889f0: at stge_intr+0x53c
> [...]

Hmm... it happens while the receive-interrupt feeds the new packet mbuf
into BPF. Maybe disable "pseudo-device bpfilter" in the kernel for a test?

But I guess the mbuf address is pointing to partly unmapped memory, so it
will crash sooner or later.


-- 
Frank Wille