Duncan Sands wrote:
It's not at all clear how that could happen. Those pointers are located
in static data in the HCD modules. It doesn't seem likely that the
pointer was overwritten. The only other possibility I can think of is
that the module was already unloaded. But that's not possible sinc
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
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
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 syst
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
fo
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
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 i
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 cs
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 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,
> 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.
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
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 t
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, 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
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
> > 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.
?
> What puzzled me was that a normal
Duncan Sands wrote:
It's not at all clear how that could happen. Those pointers are located
in static data in the HCD modules. It doesn't seem likely that the
pointer was overwritten. The only other possibility I can think of is
that the module was already unloaded. But that's not possible sinc
> It's not at all clear how that could happen. Those pointers are located
> in static data in the HCD modules. It doesn't seem likely that the
> pointer was overwritten. The only other possibility I can think of is
> that the module was already unloaded. But that's not possible since you
> were
> 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 neuron
> The simplest fix was to replace ps->devsem with dev->serialize.
> What am I to do now?
Answer: the same as before. D'oh!
Duncan.
---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skil
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) config
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
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
s
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 dev->seriali
> 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 ...)
The simplest fix was to replace ps->devsem with dev->serialize.
What am
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
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 avo
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'
> > 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 b
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 an
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
--- 1.74/driver
> 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 Tuto
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 unl
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 se
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
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 wo
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 wit
> 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 ta
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.
Bec
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: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 Tutori
On Thu, Dec 04, 2003 at 05:55:01PM -0800, Matthew Dharm wrote:
> This patch updates the Makefile to show that the raw_bulk.[ch] files are no
> longer needed.
Applied, thanks.
> Greg, please apply this patch and remove the raw_bulk.[ch] files.
Ok, I've done this. But in the future, if you send m
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
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
-
On Thu, Dec 04, 2003 at 05:30:34PM -0800, Matthew Dharm wrote:
> This patch updates the ISD-200 subdriver to be scatter-gather safe.
>
> Greg, please apply.
Applied, thanks.
greg k-h
---
This SF.net email is sponsored by: IBM Linux Tutorials
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: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 Tu
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
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
som
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 du
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
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 unt
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
On Sat, Nov 22, 2003 at 12:10:30AM +0100, Oliver Neukum wrote:
> Hi,
>
> this fixes two instances of GFP_KERNEL from completion handlers.
> It might be in the "sweet onliners" category Linus likes.
> The cset is against Linus' tree.
Applied, thanks.
greg k-h
---
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 reall
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.
>
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
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
+++ 2.6/drivers/usb/core/h
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 pat
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 peo
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 Tutoria
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...)
--
> 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.
> synchro
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
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->serializ
> 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 thou
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?
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 p
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 po
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 reaso
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 U
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
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
__
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 whenever I want to rummage around
in the device
> > 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 plac
> 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 cal
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 di
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 rece
79 matches
Mail list logo
