Re: ipf 4.1.32RC4 crashes Solaris9

Just for history, sometimes happen also to my NAT box ( solaris9/sparc) 
with the 4.1.31/pfil 2.1.13 to get repeatedly crashes apparently without 
any reason (connection load ? around 6000/7000 at concurrent connection).
The kernel errors varies between crashes, so i didn't tell anything to 
the list, waiting for a newer release....

If you wish, i'll search around my latest 12 kernel crash... (5 in 15 
minutes, yust the time to get the kernel running and crash....)

Just for info: uname -a -> SunOS pak 5.9 Generic_122300-30 sun4u sparc 
SUNW,Sun-Fire-V210

Bye.

Darren Reed ha scritto:
> Joseph Tam wrote:
>   
>> On Thu, 9 Apr 2009, Darren Reed wrote:
>>
>>     
>>> | I spoke too soon when I reported this being stable for Solaris8/9.
>>> | It still crashes my Sol9 loaded DNS server.  The symptoms are the
>>> same:
>>> | it is stable just as long as you don't filter by UDP ports, but as
>>> soon
>>> | as you add UDP port filter rules, it will crash after a while.
>>> |
>>> | I ran ACT on the core dump, and I've included the relevant portion
>>> of the
>>> | output.  Trap 0x31 is some sort of data access MMU miss in
>>> fr_derefrule().
>>> | What could cause that?
>>>
>>> A bad pointer... something similar has been seen on FreeBSD, so it is
>>> kind
>>> of comforting to see this...
>>> See:
>>> http://sourceforge.net/tracker/?func=detail&aid=2706212&group_id=169098&atid
>>>
>>> =849053
>>> ...
>>> | 20fc07a     panic[cpu1]/thread=30003367340: 20fc07a     BAD TRAP:
>>> type=31
>>> rp=2a100370720 addr=30000c59b2c mmu_fsr=0
>>> | 20fc07a 20fc07a     dnscache: 20fc07a     trap type = 0x31
>>> | 20fc07a     addr=0x30000c59b2c
>>> | 20fc07a     pid=363, pc=0x118b8a8, sp=0x2a10036ffc1,
>>> tstate=0x80001600,
>>> |         context=0x8a4
>>>
>>> If you can go into /var/crash/machine and run "adb -k *.#", what
>>> does the output of "0x118b8a8/i" say?
>>>       
>> I was afraid you were going to ask that.  I deleted those core dumps.
>> Let's see, it's now 2am on Easter Sunday -- it shouldn't be too
>> disruptive
>> to cause another crash: add UDP port rules ... swap in firewall rules
>> .. resolve apache log file to generate DNS traffic, bingo! core dump.
>>     
>
> That sounds too easily repeatable... are you saying that some specific
> rules and/or course of action could make it happen?
>
>
>   
>>     # adb -k unix.0 vmcore.0
>>     physmem 3df9f
>>     adb: warning: dump is from SunOS 5.9 Generic_122300-31; dcmds and
>> macros may not match kernel implementation
>>     0x118b8a8/i
>>     bcopy+0x4b8:    ld        [%i0], %i4
>>
>> Does that help?  (I'm keeping the core files this time in case you ask
>> something else).
>>     
>
> And stack trace output from $C?
>
> Darren
>
>   

-- 
Ing. Sergio Rabellino

Università degli Studi di Torino
Dipartimento di Informatica
ICT Services Director
Tel +39-0116706701  Fax +39-011751603
C.so Svizzera , 185 - 10149 - Torino

<http://www.di.unito.it>