[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: NetBSD xen dom0 kernel panic
On Wed, Mar 18, 2009 at 10:32 AM, Christos Zoulas
> In article <49C0957E.5050304%searchy.net@localhost>, Frank
> <netbsd%searchy.net@localhost> wrote:
>>YAMAMOTO Takashi wrote:
>>>> Good, I think that the that pools that are used in interrupt contexts,
>>>> should be using pool_cache_<foo> not pool_<foo> like the signal does.
>>>> Is that right? Can you try to make this change?
>>> it's fine to use pool_foo in interrupt context, if the pool is set up
>>> properly. however, this particular pool is not expected to be used
>>> in interrupt context. it's possible to make packet filters interrupt-safe,
>>> but imo it's better to fix bridge_ipf.
>>> YAMAMOTO Takashi
>>A temporary solution would be to disable BRIDGE_IPF ?
> that will work.
>>If any patches become available, let me know so I can test them.
> Can you explain how to fix bridge_ipf? Processing the packets in a separate
> thread does not really work - I think - because you need to say yes or no,
In what way is using pool_foo safe in an interrupt context? I am
unfamiliar with this but also have these lock errors on an alpha
current build using bridge_ipf. From what I can tell, bridge_ipf
should be modified to use some kind of static cache for storing
routing entrys, or rtupdate calls should be placed on some soft
Is this correct? I can try my hand at fixing it but before I start
I'd like to know that I'm not way off base and that I wouldn't be
duplicating the ongoing efforts of someone more familiar with this.
Main Index |
Thread Index |