[prev in list] [next in list] [prev in thread] [next in thread] 

List:       user-mode-linux-devel
Subject:    [User-mode-linux-devel] Re: Problems compiling 2.4.0test2 patch...
From:       Jeff Dike <jdike () karaya ! com>
Date:       2000-07-04 14:43:18
[Download RAW message or body]

sabre@skylab.org said:
> Okay, I just configured it with smp support and built.  Not much to go
> wrong. 

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
> want?

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.

				Jeff

[prev in list] [next in list] [prev in thread] [next in thread]