with 2.5.5-pre1 usb-uhci module can't unload. rmmod hangs, leaving the
system unstable. in one circumstance the box freezed with an oops
involving swapper pid0 . this doesn't happen with 2.5.4
# modprobe usb-uhci
# lsmod
usb-uhci 21924 0 (unused)
usbcore 60524 1 [usb-uhci]
# rmmod usb-uhci [hangs undefinitely in stat D]
PID TTY STAT TIME COMMAND
119 vc/1 D 0:00 rmmod usb-uhci
# lsmod
usb-uhci 0 0 (deleted)
usbcore 60524 1 [usb-uhci]
any clue ?
Pierre
--
------------------------------------------------
Pierre Rousselet <[email protected]>
------------------------------------------------
On Fri, Feb 15, 2002 at 03:54:40PM +0100, Pierre Rousselet wrote:
> with 2.5.5-pre1 usb-uhci module can't unload. rmmod hangs, leaving the
> system unstable. in one circumstance the box freezed with an oops
> involving swapper pid0 . this doesn't happen with 2.5.4
Try this (untested, I haven't rebooted yet) patch:
thanks,
greg k-h
diff -Nru a/drivers/usb/usb.c b/drivers/usb/usb.c
--- a/drivers/usb/usb.c Thu Feb 14 22:47:21 2002
+++ b/drivers/usb/usb.c Thu Feb 14 22:47:21 2002
@@ -1979,11 +1979,11 @@
if (driver->owner)
__MOD_DEC_USE_COUNT(driver->owner);
/* if driver->disconnect didn't release the interface */
- if (interface->driver) {
- put_device (&interface->dev);
+ if (interface->driver)
usb_driver_release_interface(driver, interface);
- }
}
+ /* remove our device node for this interface */
+ put_device(&interface->dev);
}
}
Greg KH wrote:
> On Fri, Feb 15, 2002 at 03:54:40PM +0100, Pierre Rousselet wrote:
>
>>with 2.5.5-pre1 usb-uhci module can't unload. rmmod hangs, leaving the
>>system unstable. in one circumstance the box freezed with an oops
>>involving swapper pid0 . this doesn't happen with 2.5.4
>>
>
> Try this (untested, I haven't rebooted yet) patch:
>
> thanks,
>
> greg k-h
>
>
> diff -Nru a/drivers/usb/usb.c b/drivers/usb/usb.c
> --- a/drivers/usb/usb.c Thu Feb 14 22:47:21 2002
> +++ b/drivers/usb/usb.c Thu Feb 14 22:47:21 2002
> @@ -1979,11 +1979,11 @@
> if (driver->owner)
> __MOD_DEC_USE_COUNT(driver->owner);
> /* if driver->disconnect didn't release the interface */
> - if (interface->driver) {
> - put_device (&interface->dev);
> + if (interface->driver)
> usb_driver_release_interface(driver, interface);
> - }
> }
> + /* remove our device node for this interface */
> + put_device(&interface->dev);
> }
> }
>
>
>
no, it doesn't solve the problem. i would like to test it whith
preemtible kernel not set but it doesn't boot.
with both 2.5.4 and 2.5.5-pre1 when loading usb-uhci usb.c reports 2
devices :
device 1 : USB UHCI Root Hub
device 2 : Alcatel Speed Touch USB (the driver module and firmware are
not loaded at this stage)
when rmmoding usb-uhci with 2.5.4 usb.c reports:
usb.c: USB disconnect on device 1
usb.c: USB disconnect on device 2
with 2.5.5-pre1
usb.c: USB disconnect on device 1
and nothing else.
Pierre
--
------------------------------------------------
Pierre Rousselet <[email protected]>
------------------------------------------------
> no, it doesn't solve the problem. i would like to test it whith
> preemtible kernel not set but it doesn't boot.
While Greg's patch did fix part of the problem, the rest of it was on my
end. Could you try this patch, and see if helps?
Thanks,
-pat
===== fs/driverfs/inode.c 1.14 vs edited =====
--- 1.14/fs/driverfs/inode.c Wed Feb 13 15:27:02 2002
+++ edited/fs/driverfs/inode.c Fri Feb 15 09:53:44 2002
@@ -585,29 +585,6 @@
}
/**
- * __remove_file - remove a regular file in the filesystem
- * @dentry: dentry of file to remove
- *
- * Call unlink to remove the file, and dput on the dentry to drop
- * the refcount.
- */
-static void __remove_file(struct dentry * dentry)
-{
- dget(dentry);
- down(&dentry->d_inode->i_sem);
-
- vfs_unlink(dentry->d_parent->d_inode,dentry);
-
- up(&dentry->d_inode->i_sem);
- dput(dentry);
-
- /* remove reference count from when file was created */
- dput(dentry);
-
- put_mount();
-}
-
-/**
* driverfs_remove_file - exported file removal
* @dir: directory the file supposedly resides in
* @name: name of the file
@@ -617,14 +594,12 @@
*/
void driverfs_remove_file(struct driver_dir_entry * dir, const char * name)
{
- struct dentry * dentry;
struct list_head * node;
if (!dir->dentry)
return;
- dentry = dget(dir->dentry);
- down(&dentry->d_inode->i_sem);
+ down(&dir->dentry->d_inode->i_sem);
node = dir->files.next;
while (node != &dir->files) {
@@ -633,14 +608,13 @@
entry = list_entry(node,struct driver_file_entry,node);
if (!strcmp(entry->name,name)) {
list_del_init(node);
-
- __remove_file(entry->dentry);
+ vfs_unlink(entry->dentry->d_parent->d_inode,entry->dentry);
+ put_mount();
break;
}
node = node->next;
}
- up(&dentry->d_inode->i_sem);
- dput(dentry);
+ up(&dir->dentry->d_inode->i_sem);
}
/**
@@ -669,15 +643,14 @@
entry = list_entry(node,struct driver_file_entry,node);
list_del_init(node);
-
- __remove_file(entry->dentry);
-
+ vfs_unlink(dentry->d_inode,entry->dentry);
+ put_mount();
node = dir->files.next;
}
+ up(&dentry->d_inode->i_sem);
vfs_rmdir(dentry->d_parent->d_inode,dentry);
up(&dentry->d_parent->d_inode->i_sem);
- up(&dentry->d_inode->i_sem);
dput(dentry);
done:
put_mount();
On Fri, 15 Feb 2002, Patrick Mochel wrote:
>
> > no, it doesn't solve the problem. i would like to test it whith
> > preemtible kernel not set but it doesn't boot.
>
> While Greg's patch did fix part of the problem, the rest of it was on my
> end. Could you try this patch, and see if helps?
Actually, the patch that I sent is against my current tree, which includes
some changes that I've already pushed to Linus. If you're using BK, you
should be able to pull his current tree (if you're into that kinda thing).
Or, wait until -pre2. Sorry about that.
-pat
On Fri, Feb 15, 2002 at 10:22:05AM -0800, Patrick Mochel wrote:
>
> On Fri, 15 Feb 2002, Patrick Mochel wrote:
>
> >
> > > no, it doesn't solve the problem. i would like to test it whith
> > > preemtible kernel not set but it doesn't boot.
> >
> > While Greg's patch did fix part of the problem, the rest of it was on my
> > end. Could you try this patch, and see if helps?
>
> Actually, the patch that I sent is against my current tree, which includes
> some changes that I've already pushed to Linus. If you're using BK, you
> should be able to pull his current tree (if you're into that kinda thing).
> Or, wait until -pre2. Sorry about that.
Your current tree, + this patch, + my patch solves all of the unloading,
removing, and loading problems that I had been seeing.
Thanks for finding this.
greg k-h
Patrick Mochel wrote:
> On Fri, 15 Feb 2002, Patrick Mochel wrote:
>
>
>>> no, it doesn't solve the problem. i would like to test it whith
preemtible
>>> kernel not set but it doesn't boot.
>>>
>> While Greg's patch did fix part of the problem, the rest of it was
>> on my end. Could you try this patch, and see if helps?
>>
>
> Actually, the patch that I sent is against my current tree, which
> includes some changes that I've already pushed to Linus. If you're
> using BK, you should be able to pull his current tree (if you're
> into that kinda thing). Or, wait until -pre2. Sorry about that.
well, it looks like my driverfs/inode.c has 20 lines or so more than
yours, but *it works* (together with Greg's patch on usb.c).
good work
Pierre
--
------------------------------------------------
Pierre Rousselet <[email protected]>
------------------------------------------------
Greg KH <[email protected]> remarked:
>
> On Fri, Feb 15, 2002 at 10:22:05AM -0800, Patrick Mochel wrote:
> >
> > On Fri, 15 Feb 2002, Patrick Mochel wrote:
> >
> > >
> > > > no, it doesn't solve the problem. i would like to test it whith
> > > > preemtible kernel not set but it doesn't boot.
> > >
> > > While Greg's patch did fix part of the problem, the rest of it was on my
> > > end. Could you try this patch, and see if helps?
> >
> > Actually, the patch that I sent is against my current tree, which includes
> > some changes that I've already pushed to Linus. If you're using BK, you
> > should be able to pull his current tree (if you're into that kinda thing).
> > Or, wait until -pre2. Sorry about that.
>
> Your current tree, + this patch, + my patch solves all of the unloading,
> removing, and loading problems that I had been seeing.
>
> Thanks for finding this.
I wonder if anyone might look at doing the same sort of fix to
the 2.4.18 working tree? I experience the same sort of behavior
with usb-uhci on my KT266A board (VT82C586B USB) on 2.4.18-rc1 (and
previous 2.4.x kernels, too). I'd do it myself, but the patch from
Patrick on inode.c makes me too nervous to do it, since I have
no experience with the filesystem drivers.
Thanks,
Dan Hopper
On Sat, Feb 23, 2002 at 08:54:11PM -0600, Dan Hopper wrote:
>
> I wonder if anyone might look at doing the same sort of fix to
> the 2.4.18 working tree? I experience the same sort of behavior
> with usb-uhci on my KT266A board (VT82C586B USB) on 2.4.18-rc1 (and
> previous 2.4.x kernels, too). I'd do it myself, but the patch from
> Patrick on inode.c makes me too nervous to do it, since I have
> no experience with the filesystem drivers.
These patches will not apply for the 2.4 tree, even if you tried :)
What problems are you having with 2.4.18-rc1 and previous? Any oops
messages?
thanks,
greg k-h
Greg KH <[email protected]> remarked:
> These patches will not apply for the 2.4 tree, even if you tried :)
>
> What problems are you having with 2.4.18-rc1 and previous? Any oops
> messages?
Hi,
Well, basically if I use usb-uhci instead of uhci, the computer
locks during the shutdown process. I believe I've used the stock
Mandrake 8.1 kernel as well as 2.4.17 and 2.4.18-rc1 with similar
results. Mandrake even seems to make a note of the issue:
http://www.linux-mandrake.com/en/errata.php3
"Error scenario: The computer locks up when shutting down or when
stopping the usb service.
Why: In certain cases, the usb-uhci module is broken for some usb
devices.
Solution: Modify your /etc/modules.conf file and change the line
"alias usb-interface usb-uhci" to "alias usb-interface uhci". The
change will take effect after the next shutdown and will prevent the
usb service from locking up the computer."
I have a Brother HL-1450 Postscript printer and an HP Scanjet 6300C
attached, FWIW.
The reason I'd like to switch back to usb-uhci instead of uhci is
twfold: Vmware seems to want to only use usb-uhci and not uhci
(dummies!). And uhci seems to be unable to get the scanner going
such that it doesn't "stutter" all the way down the page. usb-uhci
seems to be able to keep up so that it just sweeps on down the page.
I saw the thread on usb-uhci on 2.5, and it looked so similar that I
(incorrectly) assumed them to be one and the same problem.
Thanks,
Dan
On Sun, Feb 24, 2002 at 12:39:15AM -0600, Dan Hopper wrote:
>
> The reason I'd like to switch back to usb-uhci instead of uhci is
> twfold: Vmware seems to want to only use usb-uhci and not uhci
> (dummies!). And uhci seems to be unable to get the scanner going
> such that it doesn't "stutter" all the way down the page. usb-uhci
> seems to be able to keep up so that it just sweeps on down the page.
I noticed that Vmware does that, and was wondering why.
If you get a chance, can you try the uhci patches that were posted on
linux-usb-devel last week, or all of them rolled up at:
http://www.kernel.org/pub/linux/kernel/people/gregkh/usb/linux-2.4.18-rc2-gregkh-1.patch.gz
and let me know if that solves your problem with uhci or not?
thanks,
greg k-h
Greg KH <[email protected]> remarked:
> On Sun, Feb 24, 2002 at 12:39:15AM -0600, Dan Hopper wrote:
> >
> > The reason I'd like to switch back to usb-uhci instead of uhci is
> > twfold: Vmware seems to want to only use usb-uhci and not uhci
> > (dummies!). And uhci seems to be unable to get the scanner going
> > such that it doesn't "stutter" all the way down the page. usb-uhci
> > seems to be able to keep up so that it just sweeps on down the page.
>
> I noticed that Vmware does that, and was wondering why.
>
> If you get a chance, can you try the uhci patches that were posted on
> linux-usb-devel last week, or all of them rolled up at:
> http://www.kernel.org/pub/linux/kernel/people/gregkh/usb/linux-2.4.18-rc2-gregkh-1.patch.gz
> and let me know if that solves your problem with uhci or not?
Well, that was interesting. I upgraded to rc2 and applied that
patch. uhci still behaved the same (can't keep up with scanner).
But usb-uhci now doesn't lock up the system on a shutdown. And it
was the patch that did it, not rc2, because I tried a pristine rc2
build, too, and it still locks up. I note that there's nothing in
the patch that directly touches usb-uhci, so it must be a side
affect of some other fix.
(I'd still like to eventually get uhci working, since the docs
indicate it's the newer, cooler driver. And the ipaq driver
indicates uhci is preferred over the usb-uhci driver.)
Thanks, Greg! That was quite useful.
Dan