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
5 matches
Mail list logo
