9.0-RELEASE, SPARC64, Ultra10, dummynet hard hang

[David Cross]

Ok.. to follow up on my own question, I have tracked it down!

So, the problem is an unalligned memory access in the "burst" parameter of
dn_link.  A printf of it on my system gives:
&(p->burst)=0x0xfffff80002c48f7c

burst is an uint64_t.. that isn't 64bit aligned.

This raises a few questions:
1) Why isn't it being autoaligned, doesn't gcc do this (I am almost
positive it does (or it should) (I have no /etc/make.conf, completely stock
options)
2) Why is this causing a _deadlock_? (note kernel debugger _does_ work..
which was a boon in getting to "close" to where the problem was in the
first place)
3) Since it does cause a deadlock, it means that a bus-fault handler is
being called that _doesn't_ panic.. and doesn't return correctly?
4) since its not tripping a RED error, its not looping the handler.
and
5) given all of the above.. what's the fix?  I am modifying dn_link to be
64 bit aligned (manually).. but this feels like the wrong approach (though
it will hopefully get me what I want for 'now'.

-- 
David E. Cross

On Tue, Mar 20, 2012 at 10:38 AM, David Cross <dcrosstech at gmail.com> wrote:

> I will provide my kernel config in a second updated message, but I don't
> believe it will be needed; I am reasonably sure this affects all builds.
>
> In short I have a SPARC Ultra10 running 9.0-RELEASE (with the
> ofw_printf/ofw_panic patches obviously) running a custom kernel that has
> dummynet, ipfw, and ipsec compiled into it.  It has been running month+
> with no issues.  Last night I did:
>
> ipfw pipe 1 config bw 200KByte/sec
>
> and then it hard hung, no response to ping, no response to console, didn't
> even get it to bind to a ruleset.
>
> I reset it and did the same command again, same result.
>
> Any ideas on this?
>
> --
> David E. Cross