:Hi
:
:Please excuse any silly questions, but I am stuck with
:a problem that I can't find the answer for.
:
:I wrote a KLD module that performs encryption on
:network packets in the kernel. Packets are intercepted
:for encryption on a ethernet level (in ether_input()
:and ether_output_frame() respectively). This module is
:implemented on 4.1.1-RELEASE.
:
:For input packets I added my own NETISR as well as
:interrupt queue. In the ether_input() routine the
:packets are queued and a software interrupt scheduled.
:Further processing on the packet then happens at a
:priority of splnet().
:
:If I do bulk data transfers (encrypted) everything
:works fine until I run a shell script that does a
:'ls -lR' in an infinite loop. A few "virtual time
:alarm" messages appear and then a kernel panic.
:Looking at the DDB output, it seems a lot like a
:kernel stack overflow has resulted. Very strange
:values for ebp and page faults on stack accesses is
:making me think along these lines.
:
:Does anyone know where I can find more information
:about the kernel stack at interrupt time (such as the
:maximum size)?
:I'm also not quite sure what the "virtual time alarm"
:messages mean, can anyone help me out?
:
:jacques
The stack is very small. You cannot safely allocate large
structures on the stack -- I would limit your stack utilization
to 256 bytes total to be safe.
If you need to allocate large structures or arrays you need
to do it at device-open and then save a reference that your
interrupt can then use.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message