On Thu, 2003-02-13 at 10:31, Derrick 'dman' Hudson wrote: > On Wed, Feb 12, 2003 at 09:53:15PM +0100, martin f krafft wrote: > | i have a process waiting for data on a device that doesn't exist > | anymore (USB). now the process is listed as uninterruptibly sleeping. > | i want to get rid of it, but kill -9 doesn't do anything, the process > | remains. > | > | what must i do to kill this process? it can't be that i can get > | a process to lock into the scheduler so as to not get out anymore... > > The process isn't "locked into the scheduler" -- the (CPU) scheduler > always bypasses it because the process doesn't want any CPU right now. > The process' PC (Program Counter) is currently pointing to > instructions that are part of the kernel. It is waiting for some I/O > activity. The processs can't be killed outright because that would > harm the integrity of the running kernel. Once the process is back in > user space it can be killed with SIGKILL. Unfortunately, it isn't > likely the process will ever become unblocked. > > I think, but am not 100% positive, that the Hurd doesn't have this > problem. My reasoning is every Hurd process always runs in user space > and requests device I/O from a specialty process via IPC. It is > possible, though, that the process that actually does the device I/O > could become permanently blocked. > > -D Although referring someone who is frustrated with this particular aspect arising on Linux to the Hurd is like saying "if you sometimes have troubles getting through to someone using a telephone, you should switch to telepathy." It isn't going to be an option for everyone, it isn't really operating in the same space (eg. the 1 GiB partition size limit is still there, parts of the functionality that are commonplace for us under Linux haven't been polished to a state of certain comparable reliable availability, and it is essentially working more at a "proof of concept" status than a "production system" at present.) Nearly every operating system beyond trivial complexity that in any way interacts with inputs beyond its immediate control might be at risk of its own equivalent of "D" processes. I'd actually swear that some BSoDs under Windows result from it trying to deal with its equivalent of such processes, and taking actions that leave it (even more) inordinately unstable. I hadn't noticed this problem on later versions of OS/2, but I'd suspect that it was that OS/2 didn't present the information to the user to identify the situation. I wouldn't propose the switch to OS/2 from Linux at this point, as it effectively de-emphasized/discouraged as a solution stream by IBM. We are better off to be able to see that these happen, and look at taking actions to develop work-arounds of the blocking in an updated version. -- Mark L. Kahnt, FLMI/M, ALHC, HIA, AIAA, ACS, MHP ML Kahnt New Markets Consulting Tel: (613) 531-8684 / (613) 539-0935 Email: kahnt@hosehead.dyndns.org
Attachment:
signature.asc
Description: This is a digitally signed message part