dave,
Thanks alot for useful information.
Is there any way in which i can verify that is it the
fault of device (i.e device is trying to draw more
current) or my host controller is faulty (as you
mentioned that some Host controllers behave in such
way)?
Thanks
PC
--- David Brownell <[EMAIL PRO
On Tue, 19 Sep 2006, David Brownell wrote:
> On Tuesday 19 September 2006 1:30 pm, Alan Stern wrote:
>
> > None of this is relevant for the vanilla 2.6.18-rc series, since the USB
> > autosuspend code isn't in there at all.
>
> Even that one which can apply just fine to the RC series, addressin
Hi,
Yup, managed to solve the problem. Turned out to be wrong endpoint
configuration values and took me about 14 frustrating days to realize it.
Now i'm on my way to creating a simple OBEX server for the usb device
and hopefully everything will go smoothly from here onwards :)
Thankyou so much f
links to the patch are:
http://web.mit.edu/xiphmont/Public/kernel/ehci-sched-2.6.17-20060919.patch
http://web.mit.edu/xiphmont/Public/kernel/ehci-sched-2.6.18-20060919.patch
The patches are against the clean mainline kernels, not the previous
version of the patch.
This update should address all the
On Tuesday, 19 September 2006 02:04, David Brownell wrote:
> 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 dr
On Tuesday 19 September 2006 1:30 pm, Alan Stern wrote:
> None of this is relevant for the vanilla 2.6.18-rc series, since the USB
> autosuspend code isn't in there at all.
Even that one which can apply just fine to the RC series, addressing
that problem which appears only without CONFIG_USB_SUS
On Tue, 19 Sep 2006, David Brownell wrote:
> Eventually we want hcd->state to vanish, but until it does it sure seems
> like a problem if usbcore can't rely on all HCDs to treat it the same.
uhci-hcd sets hcd->state wherever needed by usbcore, just as the other
HCDs do. (At least that was my in
On Tue, 19 Sep 2006, David Brownell wrote:
> On Tuesday 19 September 2006 7:14 am, Alan Stern wrote:
> > This patch (as787) creates a new workqueue thread to handle delayed
> > USB autosuspend requests.
>
> So, unlike the other patch you sent recently this is an MM-only patch,
> and not releven
On Tue, 19 Sep 2006, David Brownell wrote:
> > what matters is that people have been forced to unmount all
> > filesystems on USB devices before doing suspend-to-disk. On some systems
> > this is necessary even for suspend-to-RAM.
>
> Most PCs maintain the USB connections during suspend-to-RAM;
> i am using 2.6.11,
Try to use a more current kernel. Likely it won't matter
here, but 2.6.11 is over 18 months old by now ... :)
> and EHCI HCD. during boot up i get
> following message:
>
> "usb 1-0:1.0: over-current change on port 1"
>
> and after the system is up none of the USB device
On Tuesday 19 September 2006 7:14 am, Alan Stern wrote:
> This patch (as787) creates a new workqueue thread to handle delayed
> USB autosuspend requests.
So, unlike the other patch you sent recently this is an MM-only patch,
and not relevent for 2.6.18-rc7 etc?
- Dave
On Sunday 10 September 2006 6:10 pm, Lisa Y. wrote:
> Hi,
>
> I can't seem to figure this out. But each time I run the usb.c program,
> it does not seem to go past the write () part in the
> simple_source_thread. It outputs a "signothing 22" and I'm not sure
> whether anything has been written to
On Sunday 17 September 2006 9:59 pm, Aras Vaichas wrote:
> I'm using an at91rm9200 with Linux 2.6.16. Under some unusual circumstances, I
> can create a failure.
Can you reproduce this with 2.6.18-rc7? That newer driver code may
be usable as a straight backport.
> Here is what I do to create the
On Tuesday 05 September 2006 8:26 am, Alan Stern wrote:
> Lots of people have asked why USB mass-storage devices don't survive
> suspend-to-disk (swsusp). The answer is technical and not too
> interesting;
Not that technical: "Unlike most older busses, USB monitors connection
state during suspe
On Thursday 31 August 2006 4:01 am, Rodolfo Giometti wrote:
> On Thu, Aug 31, 2006 at 03:36:42AM -0700, David Brownell wrote:
> > But in general, userspace should be assuming that all removable
> > media will have been removed by the time the system comes back up,
> > and have prepared for it. Un
On Tuesday 19 September 2006 3:43 am, Jiri Kosina wrote:
> (by the way, EHCI and OHCI seem to have broken (read: missing) locking
> when accessing the hcd->state. Should I fix it by per-hcd spinlock, or
> does the patch already exist somewhere?)
They should only ever access it while holding the
--
This is a multi-part message in MIME format.
Command 'this' not recognized.
--=_NextPart_6.3624382019043E-03
Command '--=_nextpart_6.3624382019043e-03' not recognized.
Content-Type: text/plain; format=flowed
Command 'content-type:' not recognized.
>>>
On Tue, 19 Sep 2006, Florian Echtler wrote:
> > Any such workaround would have to go into the SCSI disk driver, not
> > usb-storage. All usb-storage does is transfer commands and results back
> > and forth between the SCSI core and the USB device. If the commands
> > themselves are bad, the SCSI
On Tue, 19 Sep 2006, Jiri Kosina wrote:
> On Mon, 18 Sep 2006, David Brownell wrote:
>
> > > 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 us
On Tue, 19 Sep 2006, Jiri Kosina wrote:
> 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
This patch (as787) creates a new workqueue thread to handle delayed
USB autosuspend requests. Previously the code used keventd. However
it turns out that the hub driver's suspend routine calls
flush_scheduled_work(), making it a poor candidate for running in
keventd (the call immediately deadlock
This patch (as786) removes a redundant test and fixes a problem
involving repeated system sleeps when CONFIG_USB_SUSPEND is not set.
During the first wakeup, the root hub's dev.power.power_state.event
field doesn't get updated, causing it not to be suspended during the
second sleep transition.
Thi
This patch(as785) forces the PM core to resume a root hub after a
power loss during system sleep. If the root hub had been suspended
before the system sleep then normally the PM core would not resume it
afterward. Without this resume, various sorts of wakeup events (like
port change events) can g
-- Forwarded message --
From: pankaj chauhan <[EMAIL PROTECTED]>
Date: Sep 18, 2006 7:31 PM
Subject: USB device not getting detected.
To: [EMAIL PROTECTED]
hi all,
i am using 2.6.11, and EHCI HCD. during boot up i get
following message:
"usb 1-0:1.0: over-current change on port
>> 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 at least 256 MB in size, the camera generates errors when
>>
On Mon, 18 Sep 2006, David Brownell wrote:
> > 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.
>
--
This is a multi-part message in MIME format.
Command 'this' not recognized.
--=_NextPart_2.61159181594849E-02
Command '--=_nextpart_2.61159181594849e-02' not recognized.
Content-Type: text/plain; format=flowed
Command 'content-type:' not recognized.
>
27 matches
Mail list logo
