On Fri, 25 Jan 2013, Norbert Preining wrote:
> Hi Alan,
>
> here some status update, and a slight problem: I cannot recreate
> the problem anymore ... maybe because I pulled from master the latest
> changes, but whatever I do currently, I cannot trigger it again.
> No way.
>
> The last git commi
On Fri, Jan 25, 2013 at 11:23 PM, Alan Stern wrote:
> On Fri, 25 Jan 2013, Ming Lei wrote:
>
> Good. Can I add your Tested-by: when I submit it?
Sure, please feel free to add the below:
Tested-by: Ming Lei
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubsc
On Fri, 25 Jan 2013, Norbert Preining wrote:
> Hi Alan,
>
> here some status update, and a slight problem: I cannot recreate
> the problem anymore ... maybe because I pulled from master the latest
> changes, but whatever I do currently, I cannot trigger it again.
> No way.
>
> The last git commi
On Fri, 25 Jan 2013, Ming Lei wrote:
> On Fri, Jan 25, 2013 at 4:11 AM, Alan Stern wrote:
> >
> > Okay, here's a second test I'd like you to try. It fixes all the
> > problems on my machine.
> >
> > For this test you don't need to change any settings under /sys. Just
> > apply this patch and se
Hi Alan,
here some status update, and a slight problem: I cannot recreate
the problem anymore ... maybe because I pulled from master the latest
changes, but whatever I do currently, I cannot trigger it again.
No way.
The last git commit I used was ed06ef318a, thee I think it happened
(but I didn'
On Fri, Jan 25, 2013 at 4:11 AM, Alan Stern wrote:
>
> Okay, here's a second test I'd like you to try. It fixes all the
> problems on my machine.
>
> For this test you don't need to change any settings under /sys. Just
> apply this patch and see what the dmesg log says.
Looks the patch fixes th
On Thu, 24 Jan 2013, Norbert Preining wrote:
> Hi everyone,
>
> thanks for all the emails, but I am a bit at loss what to try next.
> THere where patches, suggestions for usbsnoop etc flying around.
>
> Can someone please let me know what information you would like
> to see?
Okay, here's a seco
On Thu, 24 Jan 2013, Norbert Preining wrote:
> Hi everyone,
>
> thanks for all the emails, but I am a bit at loss what to try next.
> THere where patches, suggestions for usbsnoop etc flying around.
>
> Can someone please let me know what information you would like
> to see?
Please start with t
On Thu, 24 Jan 2013, Ming Lei wrote:
> > What we really want to do is prevent the root hub from autosuspending
> > while the resume signal is active. One possibility is to have the HCD
> > call pm_runtime_get_noresume. Can you think of anything better?
>
> pm_runtime_get_noresume should be bett
On Thu, Jan 24, 2013 at 2:19 PM, Peter Chen wrote:
>
> My puzzle is after calling usb_autopm_get_interface_no_resume() at kick_khubd
> the dev->power.usage_count is 1, when the hub's suspend will be called?
usb_autopm_put_interface() will decrease the counter and trigger auto-suspend,
then hub_su
On Thu, Jan 24, 2013 at 01:44:09PM +0800, Ming Lei wrote:
> On Thu, Jan 24, 2013 at 10:45 AM, Chen Peter-B29397
> wrote:
> >
> > I also agree with no auto suspend occur during the resume signal is active.
>
> Yes, I agree too.
>
> >
> > But one think I still can't understand that you add
> > usb
Hi everyone,
thanks for all the emails, but I am a bit at loss what to try next.
THere where patches, suggestions for usbsnoop etc flying around.
Can someone please let me know what information you would like
to see?
Norbert
--
On Thu, Jan 24, 2013 at 10:45 AM, Chen Peter-B29397
wrote:
>
> I also agree with no auto suspend occur during the resume signal is active.
Yes, I agree too.
>
> But one think I still can't understand that you add
> usb_autopm_get_interface_no_resume(
> to_usb_interface(hub->intfd
On Thu, Jan 24, 2013 at 2:10 AM, Alan Stern wrote:
>
> Not so. It's true that the message can be produced even when the delay
> is present, but if the delay is set to 30 ms then you will get no more
> than one message every 30 ms. By contrast, Norbert was getting about 8
> messages per ms.
IMO,
>
> > I have post one patch which may remove the message, see link[2].
>
> I don't think sleeping is the right answer. For example, at the same
> time as the resume there could be a new device plugged in.
>
> What we really want to do is prevent the root hub from autosuspending
> while the re
On Thu, 24 Jan 2013, Ming Lei wrote:
> On Thu, Jan 24, 2013 at 12:08 AM, Alan Stern
> wrote:
> >
> > Not increasing the delay explains why you got all those "suspend failed
> > because a port is resuming" messages.
>
> Alan, looks the "suspend failed because a port is resuming" messages"
> is n
On Thu, Jan 24, 2013 at 12:08 AM, Alan Stern wrote:
>
> Not increasing the delay explains why you got all those "suspend failed
> because a port is resuming" messages.
Alan, looks the "suspend failed because a port is resuming" messages"
is nothing to do with the autosuspend delay, and increase t
On Wed, 23 Jan 2013, Norbert Preining wrote:
> Hi Alan,
>
> On Di, 22 Jan 2013, Alan Stern wrote:
> > It looks like things may improve if you do
> >
> > echo 50 >/sys/bus/usb/devices/usb1/power/autosuspend_delay_ms
>
> > I did some testing over here. It looks like in addition to increasing
Hi Alan,
On Di, 22 Jan 2013, Alan Stern wrote:
> It looks like things may improve if you do
>
> echo 50 >/sys/bus/usb/devices/usb1/power/autosuspend_delay_ms
> I did some testing over here. It looks like in addition to increasing
> the autosuspend delay, the following patch is needed.
I
Hi Alan, hi Felipe,
On Di, 22 Jan 2013, Felipe Balbi wrote:
> That would be great, meanwhile I'll go over current log again.
Considering Alan's answer, is the full log still necessary?
On Di, 22 Jan 2013, Alan Stern wrote:
> echo 50 >/sys/bus/usb/devices/usb1/power/autosuspend_delay_ms
>
On Tue, 22 Jan 2013, Alan Stern wrote:
> On Tue, 22 Jan 2013, Norbert Preining wrote:
>
> > Hi Felipe, hi all,
> >
> > On Mo, 21 Jan 2013, Felipe Balbi wrote:
> > > Can you try rebuilding your kernel with CONFIG_USB_DEBUG=y and run your
> > > test again ? Maybe it gives us more information of wh
On Tue, 22 Jan 2013, Norbert Preining wrote:
> Hi Felipe, hi all,
>
> On Mo, 21 Jan 2013, Felipe Balbi wrote:
> > Can you try rebuilding your kernel with CONFIG_USB_DEBUG=y and run your
> > test again ? Maybe it gives us more information of what's going on.
>
> Ok, I can reliably reproduce the p
HI,
On Tue, Jan 22, 2013 at 06:04:53PM +0900, Norbert Preining wrote:
> Hi
>
> > I need to see what happens before the problem shows up. Your log starts
> > after the problem has already triggered.
>
> It is a cycle, it repeats after the lsusb -v when it is back to
> normal. So reading from *aft
Hi
> I need to see what happens before the problem shows up. Your log starts
> after the problem has already triggered.
It is a cycle, it repeats after the lsusb -v when it is back to normal. So
reading from *after* the issuing the lsusb -v should show you what you need.
If you want I sent tomo
Hi,
On Tue, Jan 22, 2013 at 10:52:41AM +0900, Norbert Preining wrote:
> Hi Felipe, hi all,
>
> On Mo, 21 Jan 2013, Felipe Balbi wrote:
> > Can you try rebuilding your kernel with CONFIG_USB_DEBUG=y and run your
> > test again ? Maybe it gives us more information of what's going on.
>
> Ok, I can
Hi Felipe, hi all,
On Mo, 21 Jan 2013, Felipe Balbi wrote:
> Can you try rebuilding your kernel with CONFIG_USB_DEBUG=y and run your
> test again ? Maybe it gives us more information of what's going on.
Ok, I can reliably reproduce the problem as follows:
* connect the kindle, it goes into usb di
On Mo, 21 Jan 2013, Felipe Balbi wrote:
> Can you try rebuilding your kernel with CONFIG_USB_DEBUG=y and run your
> test again ? Maybe it gives us more information of what's going on.
Done, redoing the tests ASAP.
Thanks.
Norbert
-
Hi,
On Mon, Jan 21, 2013 at 04:51:28PM +0900, Norbert Preining wrote:
> Hi everyone,
> (please Cc)
>
> I am currently running 3.8.0-rc4 and see the following behaviour:
> When I plug/eject my kindle a few times, suddenly the kernel does
> not see any USB activity any more. Nothing. PLugging in th
Hi everyone,
(please Cc)
I am currently running 3.8.0-rc4 and see the following behaviour:
When I plug/eject my kindle a few times, suddenly the kernel does
not see any USB activity any more. Nothing. PLugging in the kindle -
no reaction, plugging in a usb kbd - no reaction, plugging in a
usb mo
29 matches
Mail list logo
