When ohci-hcd is shutting down (for rmmod or PC-card removal), there is
a window when the device is shut down, HC communication area (->hcca)
is freed, but the core has not called "free_irq" yet. If another device
triggers a shared interrupt in this window, we oops when trying to
access the freed -
The purpose of this patch is to split off the case when a device does
not reply on the lower level (which is reported by HC hardware), and
a case when the device accepted the request, but does not reply at
upper level. This redefinition allows to diagnose issues easier,
without asking the user if t
On Wed, 13 Sep 2006 13:03:14 +0200, Tilman Schmidt <[EMAIL PROTECTED]> wrote:
> > I adjusted all drivers which I found affected.
>
> Would you mind extending your patch to also adjust
> drivers/isdn/gigaset/bas-gigaset.c accordingly?
You are quite right, my method of search for affected modules
On Friday 15 September 2006 3:45 pm, Pete Zaitcev wrote:
> On Thu, 14 Sep 2006 13:19:53 +0200, "Rafael J. Wysocki" <[EMAIL PROTECTED]>
> wrote:
>
> > In fact I can reproduce it on two different boxes now.
>
> How about the attached?
>
> -- Pete
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
On Thursday 14 September 2006 1:21 am, Milan Svoboda wrote:
> From: Milan Svoboda <[EMAIL PROTECTED]>
>
> This patch removes limitation which prevents use of drivers that support
> speeds different than full speed.
This is the right way to fix that issue, thanks.
- Gadget drivers can support e
On Friday 15 September 2006 3:13 pm, Rafael J. Wysocki wrote:
> Hi,
>
> It looks like the ohci_hcd driver sometimes has problems with the
> initialization (eg. USB mouse doesn't work after a fresh boot and reloading
> of the driver helps).
>
> I have observed this on two different x86_64 boxes (H
On Monday 18 September 2006 6:44 pm, Jiri Kosina wrote:
> Hi,
>
> EHCI, UHCI and OHCI USB host drivers are not consistent when returining
> error values from their _suspend() functions, in case that the device is
> not in suspended state. This could confuse users, so let all three of them
> ret
Somewhere along the line, a variable in a USB-OTG codepath
stopped being used; this removes the relevant compiler warning.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Index: d26.rc4test/drivers/usb/core/hub.c
===
--- d26.rc4tes
This revamps handling of the hardware "async advance" IRQ, and its watchdog
timer. Basically it dis-entangles that important timeout from the others,
simplifying the associated state and code to make it more robust.
This reportedly improves behavior of EHCI on some systems with VIA chips,
and AFA
Hi,
EHCI, UHCI and OHCI USB host drivers are not consistent when returining
error values from their _suspend() functions, in case that the device is
not in suspended state. This could confuse users, so let all three of them
return -EBUSY.
Patch against 2.6.18-rc6-mm2.
Signed-off-by: Jiri Kosi
With 2.6.18-rc6-mm2 it is possible on my IBM T42p to do suspend/resume
cycle only once. The second time, suspend fails with
usb_hcd_pci_suspend(): ehci_pci_suspend+0x0/0xd0 [ehci_hcd]() returns
-22
pci_device_suspend(): usb_hcd_pci_suspend+0x0/0x280() returns -22
suspend_
On Mon, 18 Sep 2006, Rafael J. Wysocki wrote:
> > > I have carried out a binary search and found that the problem is caused by
> > >
> > > gregkh-usb-usbcore-remove-usb_suspend_root_hub.patch
> >
> > Tell me, what happens if you leave that patch installed, and you use
> > the patch I sent last
On Monday, 18 September 2006 17:07, Alan Stern wrote:
> On Mon, 18 Sep 2006, Rafael J. Wysocki wrote:
>
> > > Actually, the problem is ohci_hcd doesn't seem to recognize devices
> > > plugged
> > > into the USB ports.
> > >
> > > For example, if I unplug and replug a mouse (that worked before
>
--
This is a multi-part message in MIME format.
Command 'this' not recognized.
--=_NextPart_8.20753514766693E-02
Command '--=_nextpart_8.20753514766693e-02' not recognized.
Content-Type: text/html; format=flowed
Command 'content-type:' not recognized.
>>
--
This is a multi-part message in MIME format.
Command 'this' not recognized.
--=_NextPart_1.59087300300598E-02
Command '--=_nextpart_1.59087300300598e-02' not recognized.
Content-Type: text/html; format=flowed
Command 'content-type:' not recognized.
>>
--
This is a multi-part message in MIME format.
Command 'this' not recognized.
--=_NextPart_9.67308938503265E-02
Command '--=_nextpart_9.67308938503265e-02' not recognized.
Content-Type: text/html; format=flowed
Command 'content-type:' not recognized.
>>
On Thu, 14 Sep 2006, Florian Echtler wrote:
> Hi everybody,
>
> I have a Jenoptik JD6.0 digital camera (a rather cheap one), which can
> be attached as an USB storage device. I've had some problems mounting
> the camera under Linux, and I've now found out what the reason is: if
> the SD card is a
On Mon, 18 Sep 2006, Rafael J. Wysocki wrote:
> > Actually, the problem is ohci_hcd doesn't seem to recognize devices plugged
> > into the USB ports.
> >
> > For example, if I unplug and replug a mouse (that worked before unplugging),
> > it doesn't work any more. I have to reload ohci_hcd to ma
On Mon, Sep 18, 2006 at 08:37:39PM +1000, [EMAIL PROTECTED] wrote:
> Sorry, I was not clear. Let me try to understand Greg's point before
> doing debug on the system.
>
> I guess the device is registered in function skel_probe. When a device
> is connected, devfs_register in skel_probe is the fu
On Sat, Sep 16, 2006 at 02:14:52PM +0200, Michal Piotrowski wrote:
> On 15/09/06, Greg KH <[EMAIL PROTECTED]> wrote:
> >On Fri, Sep 15, 2006 at 10:35:37PM +0200, Michal Piotrowski wrote:
> >> Good news, I can't reproduce this bug with
> >CONFIG_USB_MULTITHREAD_PROBE=n.
> >
> >Great, thanks for let
On Monday, 18 September 2006 08:50, Jan De Luyck wrote:
> On Monday 18 September 2006 08:27, Rafael J. Wysocki wrote:
> > On Saturday, 16 September 2006 10:13, Rafael J. Wysocki wrote:
> > > On Saturday, 16 September 2006 00:13, Rafael J. Wysocki wrote:
> > > > It looks like the ohci_hcd driver som
Sorry, I was not clear. Let me try to understand Greg's point before
doing debug on the system.
I guess the device is registered in function skel_probe. When a device
is connected, devfs_register in skel_probe is the function where the
device is resisted by usb core. Is it correct?
In my syste
--
This is a multi-part message in MIME format.
Command 'this' not recognized.
--=_NextPart_4.16523814201355E-02
Command '--=_nextpart_4.16523814201355e-02' not recognized.
Content-Type: text/plain; format=flowed
Command 'content-type:' not recognized.
>
23 matches
Mail list logo
