gt;synchronization with the autosuspend thread is carried out even for
>root hubs (an oversight in the original code).
>
>Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
Acked-by: Mark Lord <[EMAIL PROTECTED]>
---
Index: 2.6.22-rc3/drivers/usb/core/hub.c
==
Alan Stern wrote:
> On Wed, 2 May 2007, Mark Lord wrote:
>
>> Alan Stern wrote:
>>> A better approach would be to find out why your system gets into that loop
>>> and fix the underlying cause.
>> Not better, just parallel.
>>
>> That loop should
Alan Stern wrote:
>
> A better approach would be to find out why your system gets into that loop
> and fix the underlying cause.
Not better, just parallel.
That loop should not be unbounded, as this example proves.
But it also shouldn't get stuck there regardless.
Two fixes needed.
Cheers
--
accomplish it.
Now, I still get close to a thousand or so such
messages, in groups, showing up in syslog,
but at least the system can resume after suspend.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
--- linux/drivers/usb/core/hub.c.orig 2007-04-26 12:02:47.0 -0400
+++ linux/drive
Pavel Machek wrote:
> ..
> Problem is that suspending _with_ removable mass storage devices
> attached just will not work. User will unplug them, then complain
> about corruption. Advanced user will unplug them, work with them
> somewhere else, replug them, then loose filesystem.
>
> Feel free to
Jim Radford wrote:
> ...
> This patch reverts d9a7ecacac5f8274d2afce09aadcf37bdb42b93a since it
> breaks drivers that need to access the ->port[] array in shutdown
> (most of them).
Patch applied, tested, works for me.
Signed-Off: Jim Radford <[EMAIL PROTECTED]>
Acked-
Jim Radford wrote:
> On Mon, Mar 12, 2007 at 09:55:14PM -0400, Mark Lord wrote:
>
>> So where does the memory get freed -- the structure pointed at
>> by the serial->port[i] thingie ? It's not a leak, is it?
>
> It gets free'd through device_unregister
&g
Oliver Neukum wrote:
>
> If we get to destroy_serial(), how can ports still be open?
(1) open up a ckermit session on /dev/usb_serial_port_0.
(2) suspend the machine (to RAM).
(3) the suspend logic "removes" all USB devices.
Cheers
>>>>> On Mon, Mar 12, 2007 at 04:22:22PM -0400, Mark Lord wrote:
>>>>>> Oliver Neukum wrote:
>>>>>>>> Mark Lord wrote:
>>>>>>>>> Okay, from that part (above), the problem is obvious:
>>>>>>>>
Greg KH wrote:
>>>> Mark Lord wrote:
>> This patch fixes the Oops that otherwise occurs whenever
>> a USB serial adapter is unplugged from a system, as well
>> the Oops seen when one is in use before resume (to RAM).
>>
>> GregKH: This needs to go into 2
Jiri Slaby wrote:
> Jiri Slaby napsal(a):
>> Mark Lord napsal(a):
>>> Mmm.. okay, a quick glance at the USB storage code revealed one instance:
>>>
>>>/* Did we transfer less than the minimum amount required? */
>>>if (srb->result ==
Mark Lord wrote:
> Jiri Slaby wrote:
>> Mark Lord napsal(a):
>>> Jiri Slaby wrote:
..
>>>> ---
>>>> sd 10:0:0:0: SCSI error: return code = 0x1007
>>>> end_request: I/O error, dev sdb, sector 1575
..
> The 0x1007000 is broken down as:
>
Jiri Slaby wrote:
> Mark Lord napsal(a):
>> Jiri Slaby wrote:
>>> Hello,
>>>
>>> I get this with 2.6.17-rc5-mm3 kernel:
>> ..
>>> usb-storage: device found at 10
>>> usb-storage: waiting for device to settle before scanning
>>>
Jiri Slaby wrote:
> Hello,
>
> I get this with 2.6.17-rc5-mm3 kernel:
..
> usb-storage: device found at 10
> usb-storage: waiting for device to settle before scanning
> Vendor: Model: Rev:
> Type: Direct-Access ANSI SCSI revision: 00
> SCSI de
Pavel Machek wrote:
>
> Common cellphones are 2W, iirc; (so it would be ~1mW) but I was more
> interested in system power consumption. WIFI is too power intensive
> for a cellphone (mostly). Is this designed to go into cellphones?
> notebooks?
Most mobile phones in North America typically max out
Andrew Morton wrote:
> On Thu, 01 Jun 2006 02:18:20 -0700
> ..
>> This is generating a lot of grief and appears to be unnecessarily
>> strict. Common USB sticks with a MaxPower value just above 100mA, for
>> instance, typically work fine on unpowered hubs supplying 100mA.
>>
>> Is a more user-frien
Joshua Kwan wrote:
On 04/02/2006 07:09 PM, Alan Stern wrote:
If you were to continue looking farther down in the log, you would find
that ehci-hcd sees all those devices. Those that can run at high speed
continue using the EHCI controller. For those that can't, the switch is
reset and they ge
Adrian Bunk wrote:
Subject: 2.6.16-rc[34]: resume-from-RAM unreliable (SATA)
References : http://lkml.org/lkml/2006/2/20/159
Submitter : Mark Lord <[EMAIL PROTECTED]>
Handled-By : Randy Dunlap <[EMAIL PROTECTED]>
Status : one of Randy's patches seems to fix it
I&#x
Jeff Garzik wrote:
On Tue, Nov 22, 2005 at 01:56:39PM -0500, Alan Stern wrote:
..
Or maybe not... Maybe the drive _does_ send those "not ready" messages
and the IDE driver ignores them instead of printing them in the system
log. Or perhaps those messages are sent by the bus interface control
None of the recent kernels can resume-from-ram reliably for me
if I use CONFIG_USB_SUSPEND (set). But with that option UNset,
suspend/resume to/from RAM works very well.
BUT.. new in 2.6.14-rc*, is that the ehci_hcd USB hispeed driver
no longer survives resume from ram. I have to unload/reload
Is someone actively working on USB Suspend/Resume support yet?
I ask because this is becoming more and more important as people
shift more to portable notebook computers with Linux.
Enabling CONFIG_USB_SUSPEND is currently a surefire way to
guarantee crashing my own notebook on suspend/resume,
w
21 matches
Mail list logo
