Greg KH wrote:
Ok, I'll take a patch to keep the loop from going forever, but the main
issue here is that there is probably a hardware failure somewhere.
Okay, found it. The root cause here was a missing CONFIG_USB_SUSPEND=y,
which means the hci_usb device never got marked as USB_STATE_SUSPEN
On Tue, May 08, 2007 at 09:53:05AM -0400, Mark Lord wrote:
> Greg ?
>
> The oddball thing here is that on a UP machine with a UP kernel,
> this (below) was never an issue.
>
> After moving the drive to a dual-core machine and rebuilding
> the kernel with SMP=y, the problem becomes a killer h
Greg ?
The oddball thing here is that on a UP machine with a UP kernel,
this (below) was never an issue.
After moving the drive to a dual-core machine and rebuilding
the kernel with SMP=y, the problem becomes a killer here.
The two machines are nearly identical, apart from the CPUs.
The failing
On Thu, 3 May 2007, Mark Lord wrote:
> > If the code never gets stuck in a loop, then there's no need to check
> > whether the loop is unbounded! :-)
>
> Yes, except here we know it does actually get stuck in a loop,
> and having unbounded loops in device-driver code is a known baddy.
>
> One
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 not be unbounded, as this example proves.
But it also shouldn't get st
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 not be unbounded, as this example proves.
> But it also shouldn't ge
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
-
To u
On Tue, 1 May 2007, Mark Lord wrote:
> I have just replaced my primary single-core notebook
> with a nearly identical dual-core notebook,
> and moved the usb-bluetooth peripheral from the old
> machine to the new one.
>
> On the single-core machine, suspend/resume (RAM) worked
> fine even with th
I have just replaced my primary single-core notebook
with a nearly identical dual-core notebook,
and moved the usb-bluetooth peripheral from the old
machine to the new one.
On the single-core machine, suspend/resume (RAM) worked
fine even with the bluetooth module enabled.
On the new dual-core m
9 matches
Mail list logo