Bisect: i2c regression in 63daa9589cb88617d9cc8a0b0282564682a975b7

Bisect: i2c regression in 63daa9589cb88617d9cc8a0b0282564682a975b7

[Vincent Pelletier]

Hi.

Updating nouveau module to a newer git revision, I noticed I lost hwmon.

I ran a bisect, which identified 63daa9589cb88617d9cc8a0b0282564682a975b7 as 
being the first bad commit.

Adding printk traces, I saw that probing i2c bus 3 for sensors always failed 
with -EIO (no ack from slave). After reading the code, remembering how i2c 
works and reading sample code on wikipedia, I couldn't identify any 
algorythmic problem.

So I gave a try at changing delays. I doubled T_RISEFALL and T_HOLD, and the 
adt7473 chip could be detected & used again. I haven't tested other 
combination, nor tried to link those delays with any datasheet.

My card is a GTX 280.

Regards,
-- 
Vincent Pelletier

Re: Bisect: i2c regression in 63daa9589cb88617d9cc8a0b0282564682a975b7

[Ben Skeggs]

On Sun, 2012-01-01 at 22:38 +0100, Vincent Pelletier wrote:
> Hi.
Hey,

> 
> Updating nouveau module to a newer git revision, I noticed I lost hwmon.
> 
> I ran a bisect, which identified 63daa9589cb88617d9cc8a0b0282564682a975b7 as 
> being the first bad commit.
> 
> Adding printk traces, I saw that probing i2c bus 3 for sensors always failed 
> with -EIO (no ack from slave). After reading the code, remembering how i2c 
> works and reading sample code on wikipedia, I couldn't identify any 
> algorythmic problem.
> 
> So I gave a try at changing delays. I doubled T_RISEFALL and T_HOLD, and the 
> adt7473 chip could be detected & used again. I haven't tested other 
> combination, nor tried to link those delays with any datasheet.
Apologies for the breakage, and thanks for looking into the cause!
Could you identify whether both timeouts needed doubling, or just one of
them?

Thanks,
Ben.

> 
> My card is a GTX 280.
> 
> Regards,

Re: Bisect: i2c regression in 63daa9589cb88617d9cc8a0b0282564682a975b7

[Vincent Pelletier]

Le lundi 02 janvier 2012 23:40:10, Ben Skeggs a écrit :
> Could you identify whether both timeouts needed doubling, or just one of
> them?

Not yet, and it seems there is still a problem: sensors report temperatures of 
+16k°C from time to time, making psensor go crazy. Maybe it's just the timing 
being too long now when receiving data...

I intend to do more testing this week.

Regards,
-- 
Vincent Pelletier
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: Bisect: i2c regression in 63daa9589cb88617d9cc8a0b0282564682a975b7

[Vincent Pelletier]

Le lundi 02 janvier 2012 23:40:10, Ben Skeggs a écrit :
> Could you identify whether both timeouts needed doubling, or just one of
> them?

Ahem, it has been a bit more than a week. Oh well.

I tried lowering both defines toward their original value, and failed wuite 
early. Those are the minimums with which I got success:

#define T_RISEFALL 4500
#define T_HOLD     9500

Lowering either by 50 makes hwmon disappear. Looks like I got lucky on the 
first try with my 5k/10k...

Sensors still report +16k°C occasionally, so I must be getting something wrong 
somewhere. If needed, I can try to disassemble my card (I already failed once 
to remove the cover, but didn't have an actual motivation) and see what my DSO 
Nano can get - if I can find the trace.

-- 
Vincent Pelletier
_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau