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
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
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
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 here.
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
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
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
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
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 stuck
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
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 cannot
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
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
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 the
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
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
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
18 matches
Mail list logo
