> Okay, I just configured it with smp support and built. Not much to go
Oh. You didn't mention that you configured it with SMP.
> perhaps then you should remove that option from the configure process,
Maybe. But it's been there long enough and I'm close enough to getting around
to making it work again, that I think I'll just leave it there.
> does this mean that all the locks are noops? Is that really what you
For a UP kernel, all the locks are noops, which is fine.
> Gee, sorry to try to help.
Like I said, it sounded like you ran into some compilation error that involved
some __SMP__ code somehow and you decided to turn on -D__SMP__.
So going back to the problems you found:
> Warning: unable to open an initial console.
I don't know what this is about.
> Seg fault in signals
This I can make a better guess about.
Under SMP, a problem you have to deal with is getting a process's
current_task. Linux does it by putting the task structure at the bottom of
the process kernel stack so it can get its current_task by zeroing the bottom
11 bits of its sp.
Sometimes something needs current_task, but isn't running on the kernel stack.
This is true of the tracing thread, which needs the current_task of whatever
process got a signal, and sometimes true of the process itself, which can run
kernel code on the process stack when delivering signals.
So, there's an array, cpu_tasks which maps pids (in the host kernel) to task
structures. The tracing thread looks the task structure up there.
I just had a look at restore_state. It's only called from exit_kernel, which
means that it needs to pass in task rather than NULL.
That will fix that problem. That #error that I put in do_bh needs to be
looked at, otherwise softirqs probably won't work.