Bug 99109 - Hotplug gets confused if module loading visor module
Hotplug gets confused if module loading visor module
Product: Red Hat Linux
Classification: Retired
Component: hotplug (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2003-07-14 13:46 EDT by Edward Grace
Modified: 2014-03-16 22:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-02-04 15:52:35 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Edward Grace 2003-07-14 13:46:11 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030701

Description of problem:
The hotplug facility is unreliable if a problem occurs loading a module, in this
case "visor".  If something goes wrong, "visor" and "usbserial" remain loaded
preventing reliable operation the next time a hotplug operation is attempted.

As it stands there is no /etc/hotplug/usb/visor script by default, so what
happens is the visor and usb serial modules are loaded when the hotsync button
is pressed.  When this operation is finished they are not unloaded.  This
casuses the procedure to break next time around.  Each time, the "device ID" is
incremented by 1.

Version-Release number of selected component (if applicable):
hotplug-2002_04_01-13 kdepim-3.0.5a-1 kernel-2.4.18-14 pilot-link-0.11.8-1

How reproducible:

Steps to Reproduce:
1. From fresh reboot, as root.
2. Push hotsync button.
3. Run "pilot-xfer -p /dev/usb/ttyUSB1 -l"
4. Wait for process to finish.
5. Repeat steps 2. - 4.

Actual Results:  After the first time the hotsync button is pressed, the correct
modules are loaded and pilot-xfer works as expected.  Once the transfer has
completed however the modules are not unloaded. The second time around, the
pilot-xfer program is unable to correctly talk to the visor and the modules are

Expected Results:  The dump from pilot-xfer should not be sensitive to the
number of times the hotsync button is pressed.  The modules should cleanly
unload when they have served their purpose.

Additional info:

As a work around I created the following script as /etc/hotplug/usb/visor, based
on similar problems reported on the web.

#! /bin/sh
# Visor hotplug script.  Generates a remover script to make sure that the visor
and usbserial
# modules are unloaded when the visor is unplugged.
# Ed Grace.
export PATH

logger -t visor-hotplug-script "Entering script $0 for (ACTION: ${ACTION})..."

# We start all the stuff

if [ "${ACTION}" = "add" ] && [ -f "${DEVICE}" ]
        logger -t visor-hotplug-script  "Inside my first if statement...."
        modprobe visor
        modprobe usbserial
        # create a remover script
        if [ "X$REMOVER" != "X" ]
                logger -t visor-hotplug-script  "Generating remover script
                mkdir -p /var/run/usb

                echo '' > $REMOVER
                echo '#!/bin/sh' >> $REMOVER
                echo 'PATH=/usr/sbin:$PATH' >> $REMOVER
                echo 'export PATH' >> $REMOVER
                echo 'echo "Entering script $0 for (ACTION: ${ACTION})..."' >>
                echo 'logger -t visor-remover-script "unloading visor and
usbserial modules..." ' >> $REMOVER
                echo 'rmmod visor' >> $REMOVER
                echo 'rmmod usbserial' >> $REMOVER
                chmod +x $REMOVER
                logger -t visor-hotplug-script "...finished generating remover
                logger  -t visor-hotplug-script-error "...in the remover else? 
Does this make sense?"
        logger  -t visor-hotplug-script-error "In the else for $0.  Does this
make sense?"

logger  -t visor-hotplug-script "hotplug script finished..."

exit 0

When everything is behaving itself this seems to cure the problem, with the
created remover script correctly unloading the modules on disconnect.  

HOWEVER! If there is _any_ untoward error in the transfer, the same problem
occurs, the modules either do not finish getting inserted or are not removed.  
There is then no way to remove them, /sbin/rmmod bugs out saying that the
"resource is busy".  

When this happens there seems to be no way of restoring normality other than

I have already tried upgrading the kernel, to no effect.
Comment 1 Bill Nottingham 2003-07-14 14:42:06 EDT
Why would the modules need to be unloaded?
Comment 2 Edward Grace 2003-07-14 15:09:04 EDT
Hi, thanks for the rapid response.... 
In principle they probably don't. In practice however it seems empiricaly 
necessary, as  
displayed by the supplied "ACTION=REMOVE" workaround script.    
If they are not unloaded, for some reason pilot-xfer is unable to sucessfully  
talk to the visor. Could this be due to the device id incrementing?  
Either way it's sliced or diced there seems to be something going wrong....  
Comment 3 Bill Nottingham 2005-02-04 15:52:35 EST
Closing out bugs on older, no longer supported, releases. Apologies
for any lack of response. Please reopen if problems persist on more
current releases.

Note You need to log in before you can comment on or make changes to this bug.