[Prev][Next][Index][Thread]
Re: UDP/IP Problem
> I'm using the oskit to do some UDP-based networking stuff, which
> involves me using setsockopt to adjust the RECVTIMEO. However, the
> second time I try to receive a packet, oskit panics with a
> "is_softnetpending != 0 (1)" message. I was wondering if anyone knew
> what in could be causing this? I know the actual panic refered to is
> in freebsd/net/net_receive.c Thanks in advance.
Disclaimer: I'm not the best qualified Utahn to comment on this but,
on the other hand, I am here at the moment.
Most of the network code (including bsdnet_net_receive) is
"bottom-half" code (code that is run in response to an interrupt) as
opposed to "top-half" code (code is run in response to a "system
call"). Software interrupts (which are manipulated in
bsdnet_net_receive) also count as bottom-half code.
Bottom-half code isn't associated with any particular process so it
can't (which often translates to "really, really shouldn't") do things
which require a process context. In particular, it should not block
(or call a function which blocks).
My guess is that on receiving the first packet, you called something
which blocked. Then along came the second packet and there you are
hosed. (More precisely: the call to ether_input probably sets
oskit_freebsd_ipending (which seems to be this weeks name for
is_softnetpending) but, if you block, you never return from
ether_input so you never execute the pending software interrupt code
at the end so oskit_freebsd_ipending is still set when the second
packet arrives.)
So you should have a look at your code and try to figure out what
top-half-only functions you're calling. A call to sleep or anything
involving mutexes/semaphores would be most likely. In some oskit
configurations, a call to malloc can block (the process/thread blocks
in the hope that some other thread will free up some memory).
Unfortunately, we don't have a complete (or even incomplete!) list of
what is safe to call - the oskit is so darned flexible that it's hard
to know what version of anything you're using.
I hope this helps.
--
Alastair Reid reid@cs.utah.edu http://www2.cs.utah.edu/~reid/
Follow-Ups:
References: