public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Stian Jordet <liste@jordet.nu>
To: linux-kernel@vger.kernel.org, sensors@stimpy.netroedge.com
Subject: Re: i2c_adapter i2c-0: Bus collision!
Date: Tue, 11 Jan 2005 17:44:55 +0100	[thread overview]
Message-ID: <1105461895.8299.2.camel@localhost.localdomain> (raw)
In-Reply-To: <20040117094856.2f8b44c8.khali@linux-fr.org>

Hi,

about a year ago I asked for help with my motherboard, claiming i2c bus
collisions all the time. Now I found the solution, the sensor uses the
isa bus, not the i2c. Funny it sometimes worked with i2c-viapro, but
with i2c-isa it works all the time :)

Sorry for not finding that out earlier.

Best regards,
Stian

lør, 17,.01.2004 kl. 09.48 +0100, skrev Jean Delvare:
> > sorry to bother you again, but this didn't tell you anything about
> > what's going on?
> 
> Sorry for the delay. Too much work, not enough time. You know the story
> I guess.
> 
> > > I forgot to mention it in my last mail, but I sometime has to
> > > reload the modules before "sensors" finds any sensor.
> 
> As we load sensor chip drivers, we make sure that the chip we want to
> handle is what we think it is. Technically, this means reading from a
> few registers and compare the values with what we would expect for this
> chip. So the same read errors that make your hardware monitoring values
> jump make the chip identification fail sometimes.
> 
> > > Attached three runs. Seems to be some read errors :( On these three
> > > runs I got first three bus-collisions, then one, and last two.
> 
> Not all read errors are detected as bus collisions. Anyway, you got
> loads of 'XX' as I expected, "moving" from run to run, which means that
> your i2c bus is unreliable.
> 
> My conclusion would be: bad hardware design generates noise on the i2c
> bus, resulting in read errors.
> 
> > > > Did you have to enable any particular option in MBM?
> > > 
> > > Nah, it just worked :)

> I asked Alex van Kaam (MBM's brilliant author) about his strategy with
> bus collisions. To make it short, he explained he resets the bus on
> problems. If you confirm that the smbus MBM detected was Via, Alex will
> send me his code so that I can compare with ours, just in case. But I
> doubt it'll change anything (our driver is working, it's just a matter
> of how errors are - or aren't - handled).
> 
> Basically we don't handle read errors at all (because it is so rare).
> Handling them correctly would make all chip drivers (and possibly i2c
> core and bus drivers as well) more complex. I'm not sure it's worth it.
> 
> That said, a similar problem was reported with W83L785TS-S chips (A7N8X
> motherboards). I think that the cause is different (BIOS trying to
> access the bus at the same time we do) but the consequences are the
> same. I plan to add basic error handling to this specific chip driver
> (don't know when I'll find the time to do so though). If it works and
> could be extended to other drivers as well, we'll consider it.
> 
> > > I guess this is unsolvable, but I just wanted to hear what you say.
> > > Kinda weird it works so well with MBM, but that's ok. It's just for
> > > fun I want it to work.
> 
> I think it is work-around-able, but doubt it's worth it. Anyway, thanks
> for reporting, as it increased our knowledge of the topic.
> 
> > > Thanks for your reply :)
> 
> You're welcome. Sorry for the delay again.
> 


  parent reply	other threads:[~2005-01-11 16:58 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-08  2:00 i2c_adapter i2c-0: Bus collision! Stian Jordet
2004-01-08 22:05 ` Jean Delvare
2004-01-10  4:06   ` Stian Jordet
2004-01-17  2:00     ` Stian Jordet
2004-01-17  8:48       ` Jean Delvare
2004-01-19 14:08         ` Stian Jordet
2005-01-11 16:44         ` Stian Jordet [this message]
2005-01-12 20:23           ` Jean Delvare
2005-01-12 20:41             ` Stian Jordet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1105461895.8299.2.camel@localhost.localdomain \
    --to=liste@jordet.nu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sensors@stimpy.netroedge.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox