On Mon, Sep 17, 2012 at 10:14:36PM +0200, Henrik Rydberg wrote:
> > Any better/other ideas ? Is the problem that we have to increase the wait
> > time,
> > or is something else going on ?
>
> No, it makes sense now that I got the right number of zeroes. ;-)
>
> So, to be explicit, this is the pa
> Any better/other ideas ? Is the problem that we have to increase the wait
> time,
> or is something else going on ?
No, it makes sense now that I got the right number of zeroes. ;-)
So, to be explicit, this is the patch I would like to go in. It is
completely safe, back-portable, and a no-brai
> > So bottomline, I suspect we will need to bump to 0x2 if you want to
> > keep the current loop termination and udelay().
>
> That is just crazy, since your code works with a 32ms maximum.
I am sorry, I misread the number of zeroes here. If you are saying
that fours times the current numbe
On Mon, Sep 17, 2012 at 02:54:25PM -0400, Parag Warudkar wrote:
>
>
> On Mon, 17 Sep 2012, Henrik Rydberg wrote:
>
> > So the question is, does this patch work equally well for you?
> >
> >
> > diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c
> > index 2827088..8bf9011 100644
>
On Mon, 17 Sep 2012, Henrik Rydberg wrote:
> So the question is, does this patch work equally well for you?
>
>
> diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c
> index 2827088..8bf9011 100644
> --- a/drivers/hwmon/applesmc.c
> +++ b/drivers/hwmon/applesmc.c
> @@ -56,7 +56,7
On Mon, Sep 17, 2012 at 02:06:05PM -0400, Parag Warudkar wrote:
>
>
> On Mon, 17 Sep 2012, Henrik Rydberg wrote:
>
> > The current patch does exactly the same sleeps, the only difference is
> > that the test is also done before the first sleep. Thus, the increased
> > delay, if any, comes from t
On Mon, 17 Sep 2012, Henrik Rydberg wrote:
> The MBP10,1 experiences a lot of write errors with this patch.
I just noticed a single write failure - are you seeing something similar?
[ 1660.362997] applesmc: send_byte(0x00, 0x0300) fail: 0x00
[ 1660.363002] applesmc: LKSB: write data fail
Sinc
On Mon, 17 Sep 2012, Henrik Rydberg wrote:
> The current patch does exactly the same sleeps, the only difference is
> that the test is also done before the first sleep. Thus, the increased
> delay, if any, comes from the sleep range.
My understanding is that the original patch resulted in trying
On Mon, Sep 17, 2012 at 06:27:05PM +0200, Henrik Rydberg wrote:
> > > If a), that is very valuable information, and the patch can be
> > > simplified further. If b), just crank up the wait time and be done
> > > with it. If c), well, then we don't have a case for a patch.
> > >
> > I initially exp
> > If a), that is very valuable information, and the patch can be
> > simplified further. If b), just crank up the wait time and be done
> > with it. If c), well, then we don't have a case for a patch.
> >
> I initially experimented with different max wait values and came to the
> conclusion tha
On Mon, 17 Sep 2012, Henrik Rydberg wrote:
> What exact model is this?
MacBookPro6,1 - 2010 17" MBP.
>
> In addition to Guenter's comments, it is not clear what part of this
> patch makes things work for you. Is it a) the doubling of the wait
> time, or b) the zero initial wait? Or c) just ra
Hi Parag,
> > On Sat, Sep 15, 2012 at 09:31:16PM -0700, Guenter Roeck wrote:
> > > That looks terribly complicated. Better keep the loop, and just replace
> > > udelay(us);
> > > with something like
> > > usleep_range(us, us << 1);
> > >
> > > Alternatively, just use a constant such as
> > >
On Sun, Sep 16, 2012 at 05:22:21PM -0400, Parag Warudkar wrote:
>
>
> On Sun, 16 Sep 2012, Henrik Rydberg wrote:
>
> > On Sat, Sep 15, 2012 at 09:31:16PM -0700, Guenter Roeck wrote:
> > > That looks terribly complicated. Better keep the loop, and just replace
> > > udelay(us);
> > > with somet
On Sun, 16 Sep 2012, Henrik Rydberg wrote:
> On Sat, Sep 15, 2012 at 09:31:16PM -0700, Guenter Roeck wrote:
> > That looks terribly complicated. Better keep the loop, and just replace
> > udelay(us);
> > with something like
> > usleep_range(us, us << 1);
> >
> > Alternatively, just use
On Sat, Sep 15, 2012 at 09:31:16PM -0700, Guenter Roeck wrote:
> On Sat, Sep 15, 2012 at 11:29:58PM -0400, Parag Warudkar wrote:
> >
> >
> > On Sat, 15 Sep 2012, Parag Warudkar wrote:
> >
> > >
> > >
> > > On Sat, 15 Sep 2012, Guenter Roeck wrote:
> > > >
> > > > Also, since the delay time ca
On Sat, Sep 15, 2012 at 11:29:58PM -0400, Parag Warudkar wrote:
>
>
> On Sat, 15 Sep 2012, Parag Warudkar wrote:
>
> >
> >
> > On Sat, 15 Sep 2012, Guenter Roeck wrote:
> > >
> > > Also, since the delay time can get quite large, would it make sense to
> > > replace
> > > udelay with usleep_r
On Sat, 15 Sep 2012, Parag Warudkar wrote:
>
>
> On Sat, 15 Sep 2012, Guenter Roeck wrote:
> >
> > Also, since the delay time can get quite large, would it make sense to
> > replace
> > udelay with usleep_range() ?
> >
>
> Yes, I think that would be a good thing to do. We could sleep in ra
On Sat, 15 Sep 2012, Parag Warudkar wrote:
>
> Yeah, that would fix the code to match what it says and eliminate most
> failures. But in my testing sometimes it needed a max wait of 57344 us -
> I wrote a separate patch to instrument it by bumping up max wait in
> increments of 0x2000 until
On Sat, 15 Sep 2012, Guenter Roeck wrote:
> On Sat, Sep 15, 2012 at 06:42:30PM -0400, Parag Warudkar wrote:
> > I have been getting a steady stream of wait_read timeouts on my 2010 MBP.
> >
> > After playing around with various values of APPLESMC_MAX_WAIT a value of
> > 0x1 reduces the wai
On Sat, Sep 15, 2012 at 06:42:30PM -0400, Parag Warudkar wrote:
> I have been getting a steady stream of wait_read timeouts on my 2010 MBP.
>
> After playing around with various values of APPLESMC_MAX_WAIT a value of
> 0x1 reduces the wait_read failures to zero under most normal workloads
>
I have been getting a steady stream of wait_read timeouts on my 2010 MBP.
After playing around with various values of APPLESMC_MAX_WAIT a value of
0x1 reduces the wait_read failures to zero under most normal workloads
- with and without AC power plugged in, at idle and and at make -j4 loads.
21 matches
Mail list logo
