Hi, On Tue, Apr 21, 2009 at 12:28:13AM +0100, Da Zheng wrote:
> First, I don't know how to handle vm_wire() and thread_wire(). Since > the boot doesn't have the real privileged host port, there seems to > be no way to handle them. Currently, I don't implement them and just > let them return EOPNOTSUPP. As far as I see, vm_wire() is only used > by init and the mach default pager, and thread_wire() is only used by > the mach default pager. Since the second Hurd doesn't have its own > mach default pager, init is the only program that might cause the > problem. Well, if it doesn't panic immediately, I guess it's fine... If EOPNOTSUPP makes trouble, it might be also possible just to return success, but doing nothing. I do not see what the subhurd would really need wired memory for. Wired memory is necessary only in the paging path itself, and in certain code dealing with hardware devices directly -- and subhurd shouldn't have either... > In order to track all tasks in subhurd, boot works as a proxy for all > RPCs on the task port, [...] > However, it seems to be the source of the most serious bug in my > modified boot. > > BUG: After I added the proxy for all RPCs to 'boot', I find that > subhurd sometimes failed to boot. For example, it sometimes stops > booting after the system displays "GNU 0.3 (hurd) (console)" and it > sometimes boots successfully and displays "login>" but stops working > after I try to login. Sometimes, it even prints the error message > like > getty[47]: /bin/login: No such file or directory Use `login USER' > to login, or `help' for more information. > Of course, sometimes subhurd can boot and I can login successfully. Sounds like some kind of race condition... But I don't know where. You could try tracing all RPCs made to the proxy (using some logging mechanism in the proxy itself, or perhaps rpctrace), and comparing the results of various runs... -antrik-
