kldunload ucom.ko returns "Device busy" error...

[Gary E. RAFE, Ph.D.]

I dusted off the USB cradle for my Palm m515
the other day to have another look at the most
recent "pilot-link" pre-release, since I hadn't had
any success with earlier versions of the software
and FreeBSD/USB.

While I didn't have any success getting pilot-xfer(1) to
talk to/with the Palm device via USB,
I also found an unwelcome "nit" with the ucom.ko kernel
module.

I'm running 5.4-R on a Toshiba Satellite Pro 6100 with the
most recent Toshiba BIOS.
ACPI suspend/resume does not work on this notebook,
but APM suspend/resume works fine (mostly).
The only suspend/resume trouble has been with USB;
with USB services compiled into the kernel,
they don't normally come back following the resume event.
I was able to work around this by compiling in DEBUG
information and enabling certain USB DEBUG messages.
Then there was the problem of suspending/resuming
in/out of the desktop port replicator -- USB wasn't
surviving this condition, either.
So I took USB out of the kernel completely,
and use loadable kernel modules to manage USB devices
around APM suspend/resumes.

That has been working very well, until recently.

The Palm m515 device uses the kernel module "uvisor.ko",
which, in turn, uses the "ucom.ko" kernel module.
When the uvisor(4) is loaded as a kernel module with kldload(1),
the kernel also loads ucom(4) as a module.

The trouble comes when the uvisor/ucom devices are no longer
needed (say, just prior to an APM suspend/resume cycle).
"kldunload uvisor.ko" seems to do what it is supposed to,
as reported by kldstat(1).
The ucom.ko module, however, does not get unloaded, as expected.
Attempts to unload the module directly (kldunload ucom.ko)
result in a complaint by the kernel with the message "Device busy",
and the module is not unloaded.
This causes the subsequent "kldunload usb.ko" just prior to
APM suspend to fail with the same complaint from the kernel
(i.e., "Device busy").
USB services following the APM resume event do not return,
and a warm reboot is necessary.

Attempts to load ucom(4) separately (kldload ucom.ko)
produce the same results
(i.e., kldunload ucom.ko does not unload the module,
and a warm reboot is necessary to continue).

A quick Google of "kldunload ucom.ko device busy"
returns exactly one link, which references a 4.7-Stable
installation from 2002 (but similar behavior).

Is this a known problem with the ucom.ko kernel module ?
Does a work-around exist ?

Pointers and/or suggestions regarding next steps are welcome.
--
Gary E. RAFE, Ph.D. <mailto:rafege at gmail.com>
Plain-text messages (non-HTML encoded),
without proprietary attachments, are preferred.