From: Jeff D. <jd...@ka...> - 2000-07-04 04:05:18
|
sa...@sk... said: > FYI, for some reason, I can't compile 2.4.0 out of the box (the UM > patch that is...). It seems that you are doing a bunch of #ifdef > __SMP__'s, but __SMP__ is not defined... I just did a build of the patch applied to a clean 2.4.0-test2 pool, and it built fine. Something's wrong at your end. > I added -D__SMP__ to my command line and things seem quite a bit > happier now. :) I have SMP support turned off for now, with pretty good reason. > --- arch/um/kernel/process_kern.c- Mon Jul 3 05:05:03 2000 > +++ arch/um/kernel/process_kern.c Mon Jul 3 10:34:23 2000 > @@ -228,7 +228,9 @@ > if (softirq_state[0].active&softirq_state[0].mask) > do_softirq(); > #else > -#error Need to update do_bh > +/* > + * #error Need to update do_bh > + */ > #endif > } This being one of them. > In spite of making these changes I'm still getting this error: > VFS: Mounted root (ext2 filesystem) readonly. > Warning: unable to open an initial console. > Seg fault in signals Which is another reason I have SMP turned off. If you want to get it to build, get a clean pool, and it will probably work. If it doesn't, send in the compile errors. Don't fix non-existent problems. If you want to get SMP support working, let me know, and I'll be happy to supply hints. There is more to SMP support than removing #errors and putting in kludges to make it build. Jeff |
From: Jeff D. <jd...@ka...> - 2000-07-04 13:43:56
|
sa...@sk... 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 |
From: Chris L. <sa...@sk...> - 2000-07-04 06:10:28
|
> sa...@sk... said: > > FYI, for some reason, I can't compile 2.4.0 out of the box (the UM > > patch that is...). It seems that you are doing a bunch of #ifdef > > __SMP__'s, but __SMP__ is not defined... > > I just did a build of the patch applied to a clean 2.4.0-test2 pool, and it > built fine. Something's wrong at your end. Okay, I just configured it with smp support and built. Not much to go wrong. > > I added -D__SMP__ to my command line and things seem quite a bit > > happier now. :) > I have SMP support turned off for now, with pretty good reason. okay... perhaps then you should remove that option from the configure process, does this mean that all the locks are noops? Is that really what you want? > If you want to get it to build, get a clean pool, and it will probably work. > If it doesn't, send in the compile errors. Don't fix non-existent problems. > > If you want to get SMP support working, let me know, and I'll be happy to > supply hints. There is more to SMP support than removing #errors and putting > in kludges to make it build. Gee, sorry to try to help. -Chris |