The kthread_create() API is supposed to allow you to create threads with more than the normal amount of stack pages, however the stack pointer always wound up being initialized using KSTACK_PAGES. It should be using td->td_kstack_pages instead. This means that although the vm subsystem would give you all the stack pages you asked for, %esp would always be initialized as if you had just 2 pages, and the rest would go to waste.
The kthread_create() API is supposed to allow you to create threads
with more than the normal amount of stack pages, however the stack
pointer always wound up being initialized using KSTACK_PAGES. It
should be using td->td_kstack_pages instead. This means that although
the vm subsystem would give you all the stack pages you asked for,
%esp would always be initialized as if you had just 2 pages, and
the rest would go to waste.

I wanted to use the 'give me more stack pages' feature of kthread_create()
because the Intel 2200BG NDIS driver does an alloca() of about 5000 bytes,
which wrecks the stack with the default 2 page size, and I was baffled
that no matter how much code I shoved into thread contexts with
allegedly larger stacks, the thing would still crash unless I changed
KSTACK_PAGES.

Note: this bug is present in _ALL_ arches at this point. Peter has
promised to merge this fix into all of them.

jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase,jrobhoward/SCADAbase