long resume bugs in Lucid (thoughts?).

[Colin Ian King]

Hi Manoj,

On Tue, 2010-02-09 at 19:25 -0600, Manoj Iyer wrote:
> apw,
> 
> I did some data-mining on the bugs that report resume takes a long time, ie 
> in the order of seconds. There are 150 such bugs which I believe spans 
> karmic+lucid. The long resume bug#s and their resume time can be found on
> 
> http://people.canonical.com/~manjo/sr/longresume.html
> 
> The average of the long resume time is 18.141 seconds. The resume times 
> that are reported is the total resume time. In my patch I am printing 
> resume time per driver:device which is in the order of milli seconds in 
> most cases, and I print as I resume, so I wont be able to know the total 
> resume time until I fully resume. I don't think I found what I was looking 
> for triaging these bugs, as a result. If you look at my sample output most 
> devices resume in 0.001ms (on dell Mini10V), and resume took 3.880 seconds 
> total.
> 
> http://people.canonical.com/~manjo/sr/dmesg.sr.example
> 
> I estimate that I should print any device that takes more than 100.00 msec 
> to resume. This will eliminate a lot of noise from dmesg.
> 
> thoughts ?

I'm not completely sure. My original thought was that 100ms is cutting
it a little fine -  are there any i2c bit-banging devices that
legitimately take that long?

However, from your empirical results we can see a lot of noise is
generated on small 1ms resume delays. I looked at your example and
looked at the distribution of delays:

        Delay in ms     Count
   0.00000..   0.00999  517
   0.01000..   0.01999  6
   0.02000..   0.02999  3
   0.03000..   0.03999  1
   0.04000..   0.04999  2
   0.05000..   0.05999  3
   0.06000..   0.06999  3
   0.66000..   0.66999  1
   1.02000..   1.02999  1
   1.63000..   1.63999  1
   2.44000..   2.44999  1
   2.83000..   2.83999  1
   4.51000..   4.51999  1
  24.21000..  24.21999  1
  32.33000..  32.33999  1
  64.45000..  64.45999  1
 146.81000.. 146.81999  1
 269.86000.. 269.86999  1
 269.89000.. 269.89999  1
 269.92000.. 269.92999  1
 271.76000.. 271.76999  1
 279.91000.. 279.91999  1
 279.94000.. 279.94999  1
 302.64000.. 302.64999  1
1652.09000..1652.09999  1

So we 100ms will cut out ~99% of the noise and leave us with the more
interesting delays.

Colin

> 
> Cheers
> --- manjo
>