Bug 80840

This appears to be a kernel issue.

Maybe - but I have some old usb-scripts from somewhere which makes it work again, 
somehow. If it was kernel-problem only - it should not work? 
The script gives me an error-message about usb not started, but everything works afterwords - 
I think. File attached. 

Created attachment 89025 [details]
tarball of some old usb-scripts

Odd, the only differences there aside from what we do in rc.sysinit are:

a) rc.sysinit explicitly loads usbcore before the host controller, they don't
   (shouldn't make any difference)
b) rc.sysinit is running with a r/o filesystem (which shouldn't make any
   difference)

First: I don't know anything about the usb-scripts I attached, I only have tried them now and 
then when something else has not worked. I put the scrips in /etc/usb, I have done nothing to 
the redhat-scripts in /etc/hotplug. I have now tried the following: 
 
After restarting the box, I print a textfile - it works. 
11.29 I unplug the printer - and then attach it again. 
11.30 Trying to print a textfile now does not work, lots of error-messages occur in 
/var/log/messages. 
11.30 After this I try the '/etc/usb/rc.usb restart'. Actually, I did it twice, because I had to do it 
twice last time to make the printer work again. 
11.32 I can now print files again. 
 
I attach the messages in /var/log/messages. 
 
What I think is vedy odd, is that after I have run the /etc/usb/rc.usb restart, hotpluging of the 
devices now works. I do not have to run this old script again when plugging/unplugging 
usb-devices until next boot. 
 

Created attachment 89050 [details]
output from /var/log/messages

*** This bug has been marked as a duplicate of 80622 ***

I think I found the real difference - the attached scritps use uhci module,
while the rc.sysinit uses the usb-uhci!

The interesting message I see is 

uhci.c: bf80: host controller halted. very bad

I get it after - plug printer; rc.usb restart; unplug printer; and *before*
"usb.c: USB disconnect" message. In other words, it seems that uhci module knows
how to deal with the halted controller while usb-uhci does not!

OK, it was an erroneous aliasing then.

1)  /etc/hotplug/usb.rc line 275, maybe_start_usb is commented out. Is it ment to be so? If I 
remove the '#' in line 275, '/etc/hotplug/usb.rc restart' will work as well - and hotplug works. So 
this seems for me to have nothing to do with uhci og usb-uhci module.  
 
This sequence will work for me as well: 
 
# stop usb: 
rmmod usb-uhci 
rmmod -a 
rmmod scanner printer hid 
umount /proc/bus/usb 
rmmod usbcore 
 
# start usb: 
modprobe usb-uhci 
mount -t usbdevfs usbdevfs /proc/bus/usb 
 
 
2) If I remove the usb-stuff from rc.sysinit and move it to rc.local, hotplug works. If I put it at 
the end of rc.sysinit, hotplug doesn't work. This means something, but I don't know what.... 

The USB hub thread is getting a strange SIGHUP from somewhere and exiting.
Unknown why...

USB hotplug seems to work in beta4. 
 
Trying to restart usb with /etc/hotplug/usb.rc restart is not working. Is this 
right? 

Inger, I do not understand what an attempt to "restart usb" supposed
to do? Not all modules can be unloaded, for example usbcore refuses
rmmod with a use count, until khubd is stopped, and for a good reason.
Please tell us why you want to "restart usb" if "hotplug seems to work".
Some problem other than hotplug?

I have an usb-hub, usb-printer, usb-scanner and usb-camera. Now and then in 
the past usb has 'crashed' in some way, most when trying to download from 
camera (possible sort of bad picture-files). That is when I have tried the 
usb-scripts in attachment 89025 [details]. I thought maybe the usb.rc script in 
/etc/hotplug was ment to do the same. 
But, if I ask the other way: is '/etc/hotplug/usb.rc restart' ment to do 
anything at all, or should I never use it? If not - is it a another way I can 
restart all the usb-stuff without my old scripts?   
 

The issue was khubd dying due to early and unfinished NPTL signals processing,
so closing.

Regarding "restart", it should not be needed. It basically requires reboot.
If something bad happens which shouldn't, file bugs for separate problems
and I'll look into it.