Hardware manual

manually. Of course if there is no such process as 100 then you may just remove the lockfile but in most cases
the lockfile should have been automatically removed if it contained a stale process id (such as 100).
16.15 "/dev/tty? Device or resource busy"
This means that the device you are trying to access (or use) is supposedly busy (in use) or that a resource it
needs (such as an IRQ) is supposedly being used by another device and can't be shared. This message is easy
to understand if it only means that the device is busy (in use). But it sometimes means that a needed resource
is already in use (busy). What makes it even more confusing is that in some cases neither the device nor the
resources that it needs are actually "busy".
In olden days, if a PC was shutdown by just turning off the power, a bogus lockfile might remain and then
later on one would get this bogus message and not be able to use the serial port. Software today is supposed to
automatically remove such bogus lockfiles, but as of 2006 there is still a problem with the "wvdial" dialer
program related to lockfiles. If wvdial can't create a lockfile because it doesn't have write permission in the
/var/lock/ directory, you will see this erroneous message. See Cannot create lockfile. Sorry
The following example is where interrupts can't be shared (at least one of the interrupts is on the ISA bus).
The ``resource busy'' part often means (example for ttyS2) ``You can't use ttyS2 since another device is
using ttyS2's interrupt.'' The potential interrupt conflict is inferred from what "setserial" thinks. A more
accurate error message would be ``Can't use ttyS2 since the setserial data (and kernel data) indicates that
another device is using ttyS2's interrupt''. If two devices use the same IRQ and you start up only one of the
devices, everything is OK because there is no conflict yet. But when you next try to start the second device
(without quitting the first device) you get a "... busy" error message. This is because the kernel only keeps
track of what IRQs are actually in use and actual conflicts don't happen unless the devices are in use (open).
The situation for I/O address (such as 0x3f8) conflict is similar.
This error is sometimes due to having two serial drivers: one a module and the other compiled into the kernel.
Both drivers try to grab the same resources and one driver finds them "busy".
There are two possible cases when you see this message:
There may be a real resource conflict that is being avoided.1.
Setserial has it wrong and the only reason ttyS2 can't be used is that setserial erroneously predicts a
conflict.
2.
What you need to do is to find the interrupt setserial thinks ttyS2 is using. Look at /proc/tty/driver/serial.
You should also be able to find it with the "setserial" command for ttyS2.
Bug in old versions: Prior to 2001 there was a bug which wouldn't let you see it with "setserial". Trying to see
it would give the same "... busy" error message.
To try to resolve this problem reboot or: exit or gracefully kill all likely conflicting processes. If you reboot: 1.
Watch the boot-time messages for the serial ports. 2. Hope that the file that runs "setserial" at boot-time
doesn't (by itself) create the same conflict again.
If you think you know what IRQ say ttyS2 is using then you may look at /proc/interrupts to find what else
(besides another serial port) is currently using this IRQ. You might also want to double check that any
suspicious IRQs shown here (and by "setserial") are correct (the same as set in the hardware). A way to test
whether or not it's a potential interrupt conflict is to set the IRQ to 0 (polling) using "setserial". Then if the
Serial HOWTO
16.14 "Device /dev/ttyS? is locked." 63