Date: Thu, 16 Jun 2005 16:38:36 -0400 From: rafege@gmail.com (Gary E. RAFE, Ph.D.) To: freebsd-mobile@freebsd.org Subject: kldunload ucom.ko returns "Device busy" error... Message-ID: <42b1e34c.Vf5W/G/aRvxO4X0k/jYWPS19@lmrmac.uhw.utoledo.edu>
next in thread | raw e-mail | index | archive | help
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@gmail.com> Plain-text messages (non-HTML encoded), without proprietary attachments, are preferred.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42b1e34c.Vf5W/G/aRvxO4X0k/jYWPS19>