device or resource busy
Noah Roberts
where they did not initialize correctly, out of some mistake of mine or
the developer's, and then I can't try again because the rmmod command
results in "Device or resource busy". I have been rebooting when this
happens, but this is Linux so there must be a better answer that I am
unaware of. The device or resource is not busy because it never started
correctly - somehow the module thinks it is busy when it isn't actually
doing anything useful. Isn't there a way to force it to leave?
Thanks,
NR
Sam Trenholme
>better answer that I am unaware of.
This is one of the disadvantages of a monolithic kernel; any bad
device driver can not be dealt with properly. As you probably know,
one of the earliest Linux flame wars was one about whether Linux
should be a microkernel or not. If Linux were a Microkernel, it
would be possibly slower, but be able to kill a miscreant device
driver like a process.
Since Linux is monolithic, she is as stable as her weakest device
driver. I used to crash Linux with the device driver for the parallel
port Iomega Zip drive if I disconnected the drive.
- Sam
--
My email address may be obtained at http://www.samiam.org/ssi/mailme.shtml
Peter T. Breuer
>>The rmmod command results in "Device or resource busy". I have been
>>rebooting when this happens, but this is Linux so there must be a
>>better answer that I am unaware of.
> This is one of the disadvantages of a monolithic kernel; any bad
> device driver can not be dealt with properly. As you probably know,
> one of the earliest Linux flame wars was one about whether Linux
> should be a microkernel or not. If Linux were a Microkernel, it
> would be possibly slower, but be able to kill a miscreant device
> driver like a process.
> Since Linux is monolithic, she is as stable as her weakest device
> driver. I used to crash Linux with the device driver for the parallel
> port Iomega Zip drive if I disconnected the drive.
This is all nice but irrelevant. The driver in question has errored in
its init routine. Probbaly an oops. The OP does not tell us, which I
find aggravating.
Having not completed init, the kernel has done well to isolate
the unit. Locks are preventing it being removed since it has not
finished inserting. This is the best that can be done since in any case
the situation requires a reboot (the kernel has oopsed!) and any
more intelligent response would require detailed controls that would
give rise to more race conditions in general.
THere is a movement towards not allowing removal of any driver, once
inserted.
Peter
Tony Lawrence
I don't totally understand this. Is the concern that the driver may
have trampled other kernel structures? If so, that would seem to
indicate that you shouldn't be continuing at all.
If it has been isolated, then why can't it be removed? I assume
isolated means that nothing is going to be allowed to reference any of
its routines, that the entry points for the device just don't point
there, that no part of it is in the scheduler?
Understand that I'm not arguing the point: I'm far, far from enough
expertise in this are to even begin to do that. I'm just curious if the
reasoning behind this can be explained in a way we mere mortals can
comprehend.
>
> THere is a movement towards not allowing removal of any driver, once
> inserted.
So I have read, but again I do not totally understand that. Again,
speaking from my incomplete understanding: if you can close off the
entry points and remove any scheduled handlers, why wouldn't you then be
able to drop it? Yes, processes may be waiting on it, but isn't that a
separate problem?
It just seems to me that this is a design decision at some basic level.
Obviously (?) you *could* design to remove or replace recacitrant
kernel code, but maybe the required effort is just too high? Again,
just asking :-)
--
Tony Lawrence
Free SCO, Mac OS X and Linux Skills Tests:
http://aplawrence.com/skillstest.html
Peter T. Breuer
> Peter T. Breuer wrote:
>> Having not completed init, the kernel has done well to isolate
>> the unit. Locks are preventing it being removed since it has not
>> finished inserting. This is the best that can be done since in any case
>> the situation requires a reboot (the kernel has oopsed!) and any
>> more intelligent response would require detailed controls that would
>> give rise to more race conditions in general.
> I don't totally understand this. Is the concern that the driver may
> have trampled other kernel structures? If so, that would seem to
Anything at all may have happened. Module init has not completed, so we
know that the ordinary flow of execution was not followed. Normally
when you start a subroutine you exit from it some time later!
> indicate that you shouldn't be continuing at all.
Indeed, you should not. However, you get the opportunity right now to
gather data about the oops. Save it and play it through ksymoops.
> If it has been isolated, then why can't it be removed? I assume
Becuase it hasn't finished its init. It's a transaction. You can't
remove a module /while/ it's inserting. And it's still inserting!
By saying that it was isolated I meant that it's only this modules lock
that is affected. All other modules are OK.
> isolated means that nothing is going to be allowed to reference any of
> its routines, that the entry points for the device just don't point
> there, that no part of it is in the scheduler?
Exactly. None of this is predictable. The init routine can do anything
and will normally register functions elsewhere in the kernel. They may
be associated with its major and they may not.
> Understand that I'm not arguing the point: I'm far, far from enough
> expertise in this are to even begin to do that. I'm just curious if the
> reasoning behind this can be explained in a way we mere mortals can
It looks obvious to me. You can't remove until inserted. Insertion has
not completed. End of story. ANything more subtle would require
knowledge of the module innards, and the kernel doesn;t have that.
> comprehend.
> > THere is a movement towards not allowing removal of any driver, once
> > inserted.
> So I have read, but again I do not totally understand that. Again,
> speaking from my incomplete understanding: if you can close off the
> entry points and remove any scheduled handlers, why wouldn't you then be
> able to drop it? Yes, processes may be waiting on it, but isn't that a
Because you can't control what the module has done. It may have planted
a timebomb elsewhere, say a task that in 10s will start to send requests
to a function of its own whose code no longer exists, since you removed
it ...
> separate problem?
> It just seems to me that this is a design decision at some basic level.
It is. Linus decided that there was no need to put excessive
complication in here since you can always just whip the admin
responsible for breakage until he stops doing it. And all attempts
to add complication simply expose more complicated rce conditions,
in my opinion, at least.
What is going on right now in 2.5 however makes me shudder ...
> Obviously (?) you *could* design to remove or replace recacitrant
No, you couldn't, not safely.
> kernel code, but maybe the required effort is just too high? Again,
Yes. It requires coding discipline that is too much to ask of authors.
> just asking :-)
Essentially, removing a module is a race. You try and remove it before
anyone new can use it!
Peter
Noah Roberts
> Sam Trenholme <nob...@koala.samiam.org> wrote:
>
>>>The rmmod command results in "Device or resource busy". I have been
>>>rebooting when this happens, but this is Linux so there must be a
>>>better answer that I am unaware of.
>>
>
>>This is one of the disadvantages of a monolithic kernel; any bad
>>device driver can not be dealt with properly. As you probably know,
>>one of the earliest Linux flame wars was one about whether Linux
>>should be a microkernel or not. If Linux were a Microkernel, it
>>would be possibly slower, but be able to kill a miscreant device
>>driver like a process.
>
>
>>Since Linux is monolithic, she is as stable as her weakest device
>>driver. I used to crash Linux with the device driver for the parallel
>>port Iomega Zip drive if I disconnected the drive.
>
>
> This is all nice but irrelevant. The driver in question has errored in
> its init routine. Probbaly an oops.
Nope, no oops.
NR