[BlueOnyx:02173] Re: Kernel Panic - Boooom!

[Jeff Jones]

This system does bandwidth management (limiting bandwidth to certain  
servers) and the last big change I did on this system was a few days  
ago where I enabled quite a few busy servers with new bandwidth  
restrictions.

I'm told that for the bandwidth management software to work - the  
following needs to be compiled:

sch_sfq (Stochastic Fair Queuing) - CONFIG_NET_SCH_SFQ
sch_htb (Hierarchical Token Bucket) - CONFIG_NET_SCH_HTB

Plus the iproute2 package needs to be installed.

Now I never actually realized I needed to do this (now they tell me)  
although - Bandwidth Management has worked fine. So I'm guessing BX  
comes with these kernel modules installed.

So the best bet is that perhaps there is some sort of bug in HTB/SFQ -  
and this has been fixed in a newer kernel. Thus - upgrade the kernel.

That's the best I think I'm going to get eh?

Jeff



On 21 Aug 2009, at 14:47, Michael Stauber wrote:

> Hi Jeff,
>
>> I have spotted this in the messages log.
>>
>> Could this be why I didn't get a kernel dump?
>>
>> Aug 21 07:48:18 deathwatch2 kernel: Memory for crash kernel (0x0 to  
>> 0x0)
>> notwithin permissible range Aug 21 07:48:18 deathwatch2 kernel:  
>> disabling
>> kdump
>>
>> Is this a BX generic issue - or something wrong with this sytem?
>
> That's just an info line, not an error.
>
> See:
>
> http://www.centos.org/modules/newbb/viewtopic.php?topic_id=12469
> https://bugzilla.redhat.com/show_bug.cgi?id=431584
>
> Various levels of logging - including the optional creation of  
> kernel core
> dumpfiles are possible in Linux in general. Often the creation of  
> kernel core
> files is disabled by default (as it is on RHEL5 and CentOS5),  
> because these
> coredumps are fairly large, may litter the system and are only  
> really useful
> to people with expertise in debugging kernel related issues. But  
> like said
> earlier: With such an old clunker of a kernel it ain't worth the  
> effort.
> You'll most likely be chasing bugs which are fixed in later kernel  
> versions,
> or simply find out that it as an oddball event involving a rare even  
> under
> high load situation inside your specific VMware setup.
>
> -- 
> With best regards
>
> Michael Stauber
>
> _______________________________________________
> Blueonyx mailing list
> Blueonyx at blueonyx.it
> http://www.blueonyx.it/mailman/listinfo/blueonyx