On Tue, 9 Dec 2003, Tuukka Toivonen wrote:
The first try would be to call usb_unlink_urb() (synchronously), but this
Amazing. Exactly this same topic was discussed since the weekend in the
thread RFC: Synchronous unlinking and resubmission of URBs. I only
checked archives, didn't read the recent
I guess this patch have been missed so I resend it as 2 rc more and still not applied
or rejected.
Begin forwarded message:
Date: Tue, 11 Nov 2003 00:00:26 +0100
From: fee mail [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [linux-usb-devel] oops with usb-uhci module
here it is in diff
I didn't note the reason for the oops. Was it a segmentation violation?
The usb_device memory isn't deallocated until the reference count goes to
0. Maybe something was doing an extra usb_put_dev.
Maybe this is related to oopses in kobjects in 2.6.0-test11 (was Re: kobject patch)?
My call to
Yes. ps-devsem is used to protect against disconnection: all top level
routines take it (as a read lock), and in driver_disconnect it is taken
as a write lock. Top level routines call lower level routines which
sometimes need to take dev-serialize (and do already in several places).
Hi Alan,
it tried your patch. It looks quite good. Reading CD and playing DVD movies works now.
The 3nd attempt of reading CSW works. Therefore, the USB bus is not be reseted.
I will do more tests (writing) at the weekend.
Thanks a lot
matthias
On Mon, 8 Dec 2003, Oliver Neukum wrote:
Why are these new problems?
The newly submitted URB cannot complete because the hardware or SMP code
will prevent an IRQ handler from being reentered.
You yourself have solved the problem or you couldn't fail resubmission
under these circumstances.
This is a little bit behind-hand in the thread, but bear with me...
On Tue, 9 Dec 2003, Herbert Xu wrote:
The problem here is the khubd is stuck in usb_set_address() waiting
for the URB to complete, but it never finishes because the UHCI driver
isn't getting any interrupts.
Unloading UHCI
On 8 Dec 2003, Ken Bass wrote:
Hello all,
I'm digging through the USB mass storage code and am pretty confused.
Previously we used a Sony AIT-1 tape drive via SCSI. However, we
recently acquired a new model that supports either firewire / USB.
Neither works (I think for the same reason).
On Tue, 9 Dec 2003, Duncan Sands wrote:
Maybe this is related to oopses in kobjects in 2.6.0-test11 (was Re: kobject
patch)?
My call to usb_put_dev in usbdev_release is releasing the kobject,
which shows that the reference count was not already zero. However
it dereferences a NULL pointer
Am Dienstag, 9. Dezember 2003 15:55 schrieb Alan Stern:
On Mon, 8 Dec 2003, Oliver Neukum wrote:
Why are these new problems?
The newly submitted URB cannot complete because the hardware or SMP code
will prevent an IRQ handler from being reentered.
You yourself have solved the problem or
On Tue, 9 Dec 2003, Duncan Sands wrote:
You may simply have to release the lock because calling
usb_set_configuration and then reacquire it afterwards.
Right, I did this in my patch along with the other changes, but in fact it could
be fixed separately.
Doesn't this approach work? I
I still think the proper approach is to fix suspend/resume. Detecting
malfunctioning interrupts during HC startup won't help because resume is
different from startup. Just detecting them during resume won't help
either, because pre-existing URBs will still be linked.
Quick evil
On Tue, 9 Dec 2003, Duncan Sands wrote:
There is another solution by the way, which involves changes in the core:
make dev-serialize into a read/write semaphore, and have disconnect
be called with a READ lock taken on dev-serialize. Then in usbfs, I can
take a read lock on dev-serialize
On Tue, 9 Dec 2003, Oliver Neukum wrote:
from usb_hcd_giveback_urb()
* @urb: urb being returned to the USB device driver.
* @regs: pt_regs, passed down to the URB completion handler
* Context: in_interrupt()
If you wish to drop that requirement you'll have to audit all drivers with
It would still be a good idea to give drivers an easy way to wait for an
URB to be completely idle (i.e., completion handler not running and URB
not currently linked) without making them do careful locking and
Absolutely. That's what people want when they do a synchronous unlink.
On Tue, Dec 02, 2003 at 06:20:59PM -0800, Matthew Dharm wrote:
This patch fixes some obvious errors in the jumpshot and datafab drivers.
Greg, please apply.
This should close out Bugzilla bug #1408
Applied, thanks.
greg k-h
(hm, sf.net seems to not like my domain anymore, bleah...)
On Fri, Nov 21, 2003 at 10:02:55PM +0100, Oliver Neukum wrote:
Hi,
somebody built his own version of be16_to_cpu(). Such things affect
maintainability.
Applied, thanks.
greg k-h
---
This SF.net email is sponsored by: IBM Linux Tutorials.
On Tue, 9 Dec 2003, Oliver Neukum wrote:
It would still be a good idea to give drivers an easy way to wait for an
URB to be completely idle (i.e., completion handler not running and URB
not currently linked) without making them do careful locking and
Absolutely. That's what people want
On Fri, Nov 21, 2003 at 09:53:43PM +0100, Oliver Neukum wrote:
Hi,
this fixes the questionable error return codes Paulo noticed
in usblp. I hope I really got all cases now.
Probably 2.6.1. The cset is against Linus' tree.
Applied, thanks. And I've fixed up the compiler warning this patch
Rogério:
This quick patch will add a 1-second delay between powering up the ports
on your internal hub. Try it out on your desktop computer and post the
debugging log so we can see what happens.
Alan Stern
--- 2.6/drivers/usb/core/hub.c.orig Mon Sep 22 12:37:50 2003
+++
On Tue, Nov 04, 2003 at 04:52:05PM -0500, Alan Stern wrote:
Greg and all:
(I've lost track of patches that have been submitted in the last few
weeks, so it's possible that something incorporating this change is
already somewhere in the queue.)
The usb_physical_reset_device() routine in
Am Dienstag, 9. Dezember 2003 18:50 schrieb Greg KH:
On Fri, Nov 21, 2003 at 09:53:43PM +0100, Oliver Neukum wrote:
Hi,
this fixes the questionable error return codes Paulo noticed
in usblp. I hope I really got all cases now.
Probably 2.6.1. The cset is against Linus' tree.
Applied,
On Tue, Dec 09, 2003 at 07:15:29PM +0100, Oliver Neukum wrote:
Am Dienstag, 9. Dezember 2003 18:50 schrieb Greg KH:
On Fri, Nov 21, 2003 at 09:53:43PM +0100, Oliver Neukum wrote:
Hi,
this fixes the questionable error return codes Paulo noticed
in usblp. I hope I really got all
On Fri, Dec 05, 2003 at 10:46:47PM +0100, Oliver Neukum wrote:
Hi,
apart from locking bugs, there are other races. This fixes one with
signal delivery. The signal should be delivered _before_ the reciever
is woken.
Nice fix, applied.
thanks,
greg k-h
Hello Dave,
On Monday 08 December 2003 21:54, David Brownell wrote:
Re implementation, I'll continue to lobby for simplicity.
and immediately followed by:
Drivers can implement interruptible waits themselves, on top of
async unlink.
Nothing personal, Dave - but how long will it last until
Hello Dave,
On Monday 08 December 2003 21:15, David Brownell wrote:
Sure, but I can't think of that as anything other than a
set of long-standing driver bugs.
If few drivers are wrong: shame on the driver writer.
If most drivers are wrong: shame on the API designer.
best regards
Wolfgang
On Tue, 9 Dec 2003, Oliver Neukum wrote:
Couldn't we eliminate most uses of usb_unlink_urb() from 2.6 anyway?
David, can we rely on the core nuking URBs in all cases, even software driven
disconnect?
What about cases where the urbs must be unlinked during release() and
then re-used later
Wolfgang Mües wrote:
Nothing personal, Dave - but how long will it last until
you will accept that making a simple and bullet-proof
API for device driver writers is a key to linux USB success?
You're implying that I don't already accept that.
I'm not sure why ... just because I disagreed with
On Tue, 9 Dec 2003, Greg KH wrote:
Hm, doesn't hub_port_reset() already set the state of the device for us
here properly?
usb_set_address() already sets the state of the device to this when it
is successful. Why set it here again?
In both cases, of course you are right.
@@ -1342,6
On Thu, Dec 04, 2003 at 05:18:41PM -0800, Matthew Dharm wrote:
This patch updates the jumpshot driver to the new scatter-gather routines.
Greg, please apply.
Applied, thanks.
greg k-h
---
This SF.net email is sponsored by: IBM Linux
On Thu, Dec 04, 2003 at 06:03:27PM -0800, Matthew Dharm wrote:
This patch adds some comments to clarify why we have to jump through all of
these hoops for scatter-gather...
Greg, please apply.
Applied, thanks.
greg k-h
---
This SF.net
On Thu, Dec 04, 2003 at 05:25:14PM -0800, Matthew Dharm wrote:
This patch adds some helper functions, which are used by some later
patches, in our quest to make all the sub-drivers scatter-gather-safe.
Greg, please apply.
Applied, thanks.
greg k-h
Am Dienstag, 9. Dezember 2003 20:24 schrieben Sie:
On Tue, 9 Dec 2003, Oliver Neukum wrote:
Couldn't we eliminate most uses of usb_unlink_urb() from 2.6 anyway?
David, can we rely on the core nuking URBs in all cases, even software driven
disconnect?
What about cases where the urbs
On Thu, Dec 04, 2003 at 05:32:23PM -0800, Matthew Dharm wrote:
This patch updates the shuttle-usbat driver to be scatter-gather safe.
Greg, please apply.
Applied, thanks.
greg k-h
---
This SF.net email is sponsored by: IBM Linux
On Thu, Dec 04, 2003 at 05:14:03PM -0800, Matthew Dharm wrote:
This patch updates the datafab driver to the new scatter-gather handling,
which makes it safe for systems with 1GByte of memory.
Greg, please apply.
Applied, thanks.
greg k-h
On Thu, Dec 04, 2003 at 05:39:47PM -0800, Matthew Dharm wrote:
This patch updates the sdd55 driver to be scatter-gather safe.
Greg, please apply.
Applied, thanks.
greg k-h
---
This SF.net email is sponsored by: IBM Linux Tutorials.
Here's how I see it.
dev-serialize is meant to protect significant state changes, things like
set_configuration and device disconnect. ps-devsem is meant to protect
against usbfs trying to do two things to the device at the same time.
Actually no: it is a read lock and all routines take it
There are problems lurking in the driver binding code for usb,
with highlights being disagreements about:
(a) locks: usb bus writelock v. BKL v. driver-serialize
(b) driver: interface.driver v. interface.dev.driver
Fixing those is going to take multiple patches, and I thought
I'd start out
On Tue, Dec 09, 2003 at 11:50:24AM -0800, Greg KH wrote:
On Thu, Dec 04, 2003 at 05:55:01PM -0800, Matthew Dharm wrote:
Greg, please apply this patch and remove the raw_bulk.[ch] files.
Ok, I've done this. But in the future, if you send me a patch that does
remove a file, that will work
On Tuesday 09 December 2003 16:55, Alan Stern wrote:
On Tue, 9 Dec 2003, Duncan Sands wrote:
You may simply have to release the lock because calling
usb_set_configuration and then reacquire it afterwards.
Right, I did this in my patch along with the other changes, but in fact
it could
On Dec 09 2003, Alan Stern wrote:
Rogério:
This quick patch will add a 1-second delay between powering up the
ports on your internal hub. Try it out on your desktop computer and
post the debugging log so we can see what happens.
Hi, Alan. Thank you for your patch.
Unfortunately, it seems
Oliver Neukum wrote:
It would still be a good idea to give drivers an easy way to wait for an
URB to be completely idle (i.e., completion handler not running and URB
not currently linked) without making them do careful locking and
Absolutely. That's what people want when they do a synchronous
Comments? That description seems bigger than the patch!
Splendid!
Just one issue. Giving up an interface just needs a readlock,
not a writelock.
Regards
Oliver
---
This SF.net email is sponsored by: IBM Linux
This is a minor cleanup that replaces a test for non-null urb-hcpriv
with is the urb on this list. HCDs don't need to use hcpriv in that
way, and in general this is a safer way to test that. (AIO does much
the same thing in its kiocb cancelation paths.)
Please merge.
- Dave
---
Oliver Neukum wrote:
Comments? That description seems bigger than the patch!
Splendid!
Just one issue. Giving up an interface just needs a readlock,
not a writelock.
Could you elaborate a bit? I don't think I noticed any
code getting readlocks on the bus rwsem on such paths.
Isn't giving up
EIP is at hcd_pci_release+0x19/0x20 [usbcore]
I don't understand this stack dump. The EIP address is _after the end_ of
hcd_pci_release, as you can see from the fact that the following code is
nothing but a long string of NOPs.
Hi Alan, I'm not sure what you mean. 0x19/0x20 seems to be
Am Dienstag, 9. Dezember 2003 22:01 schrieb David Brownell:
Oliver Neukum wrote:
Comments? That description seems bigger than the patch!
Splendid!
Just one issue. Giving up an interface just needs a readlock,
not a writelock.
Could you elaborate a bit? I don't think I noticed
Alan Stern wrote:
And the usage count thing seems to be designed to facilitate something
that I think usbcore should avoid.
I'm not sure what you're referring to. The particular reason I introduced
it was to handle the case of reentrant calls to giveback_urb. I don't see
how the core can
Hi Dave, I think this one
* Removes driver-serialize ... not needed, since
it's only gotten when the bus writelock is held.
is problematic for efficiency reasons: suppose I want to
protect myself from (for example) configuration changes.
By taking dev-serialize I am taking a
Duncan Sands wrote:
Hi Dave, I think this one
* Removes driver-serialize ... not needed, since
it's only gotten when the bus writelock is held.
is problematic for efficiency reasons: suppose I want to
protect myself from (for example) configuration changes.
By taking
Just one issue. Giving up an interface just needs a readlock,
not a writelock.
At some level I'm just passing along the driver model
constraints ... as from device_release_driver(), which
does modify sysfs data structures. Getting a readlock
would mean that things like /bin/ls would have data
On Tue, 9 Dec 2003, Duncan Sands wrote:
EIP is at hcd_pci_release+0x19/0x20 [usbcore]
I don't understand this stack dump. The EIP address is _after the end_ of
hcd_pci_release, as you can see from the fact that the following code is
nothing but a long string of NOPs.
Hi Alan, I'm
On Tue, 9 Dec 2003, Duncan Sands wrote:
Hi Dave, I think this one
* Removes driver-serialize ... not needed, since
it's only gotten when the bus writelock is held.
is problematic for efficiency reasons: suppose I want to
protect myself from (for example) configuration
I think you mis-read something: dev-serialize is a
different lock from driver-serialize. Only one of
them is superfluous -- though the names are similar.
I did indeed completely misread it. Having dev-serialize
on my mind a lot right now, anything with serialize in it
makes my neurons go
On Tue, 9 Dec 2003, David Brownell wrote:
There is no such thing as a reentrant call to giveback_urb(); that'd
mean that somehow the same URB got queued twice. If nothing else, the
data structures don't support such a notion ... only one queue! :)
Oliver has now convinced me of that. But
On Tue, 9 Dec 2003, Rogério Brito wrote:
Hi, Alan. Thank you for your patch.
Unfortunately, it seems that the patch still doesn't work. Just as you
know what I did, I uninstalled the hotplug scripts, booted into single
user mode, loaded the module uhci-hcd, issued the command
echo 4
Hi.
Here is a patch for test11 which modifies the datafab driver according
to my understanding of the datafab device. I completely removed the lun
detection but left this work up to the operating system, namely
sd_mod.ko. sd_mod can decide which lun is available by means of checking
the media
On Tue, Dec 09, 2003 at 12:37:22PM -0800, Matthew Dharm wrote:
On Tue, Dec 09, 2003 at 11:50:24AM -0800, Greg KH wrote:
On Thu, Dec 04, 2003 at 05:55:01PM -0800, Matthew Dharm wrote:
Greg, please apply this patch and remove the raw_bulk.[ch] files.
Ok, I've done this. But in the
Está promoção é valida
até 10 de Dezembro de 2003.
Promoção do final do ano de 2003.Plano anual (doze meses). (+ O
mês de aniversario de graça) = 13
meses.Valor do mês R$
36.92 (trinta e seis reais e noventa dois
Comments?
Will look later.
Andries
---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
On Monday 08 December 2003 03:59pm, Alessio Sangalli wrote:
Hi, I wrote an email directly to greg at kroah.com because he's the
author of the pl2303 driver but I think I could have some help here too
about an issue with the pl2303 driver.
if I connect a usb-serial adapter to my laptop, and I
On Tue, Dec 09, 2003 at 02:40:36PM -0500, Alan Stern wrote:
I didn't look into the subroutines when composing the patch; I just
assumed that since the third assignment was needed the first two were
needed as well. Included below is a revised patch (as131b) that leaves
out the first two
On Tue, Dec 02, 2003 at 08:24:00PM +0100, Oliver Neukum wrote:
Hi,
this driver has locking problems. Here's the first round of fixes
for the obvious cases.
- it makes clear differences between completion handlers and task context
- it fixes cases of sleeping in interrupt
The cset is
On Tue, Dec 09, 2003 at 12:55:37PM -0800, David Brownell wrote:
This is a minor cleanup that replaces a test for non-null urb-hcpriv
with is the urb on this list. HCDs don't need to use hcpriv in that
way, and in general this is a safer way to test that. (AIO does much
the same thing in its
On Tue, Dec 09, 2003 at 11:49:27AM +0100, Duncan Sands wrote:
I didn't note the reason for the oops. Was it a segmentation violation?
The usb_device memory isn't deallocated until the reference count goes to
0. Maybe something was doing an extra usb_put_dev.
Maybe this is related to
David Brownell wrote:
A separate usbfs patch is needed to fix its driver binding;
mostly just to use the right lock, but those changes were
more extensive and uncovered other issues. (Like, I think,
some that Duncan has been noticing ...)
And here it is. I currently don't have code using usbfs
Duncan Sands wrote:
It occurred on system shutdown - so I guess the module was unloaded.
Maybe the bus reference counting is borked.
Various folk have reported similar problems on system shutdown
before, and the simple fix has been not to clean up so aggressively.
?
Like: don't rmmod during
On Tue, 9 Dec 2003, David Brownell wrote:
Various folk have reported similar problems on system shutdown
before, and the simple fix has been not to clean up so aggressively.
What puzzled me was that a normal rmmod wouldn't give the
same symptoms -- but the same codepaths could oops in
On Tue, 9 Dec 2003, Alan Stern wrote:
Simply stated, things that matter to a device driver can thereby be of
interest to the core. If by providing a simple -- though not strictly
necessary -- service the core can make device drivers easier to write and
more obviously error-free, then the
69 matches
Mail list logo
