Hi,
I get plenty of this in my logs:
i2c_adapter i2c-0: Bus collision! SMBus may be locked until next hard
reset. (sorry!)
Kernel 2.6.0 with lm-sensors 2.8.2.
I get very weird results, especially on the fan, but others as well.
Here are three runs of sensors:
buick:~# sensors
w83627hf-i2c-0-2d
Adapter: SMBus Via Pro adapter at 5000
Algorithm: Unavailable from sysfs
VCore 1: +1.79 V (min = +1.66 V, max = +0.72 V)
VCore 2: +1.50 V (min = +1.66 V, max = +0.72 V)
+3.3V: +3.34 V (min = +3.14 V, max = +3.46 V)
+5V: +4.95 V (min = +4.73 V, max = +5.24 V)
+12V: +11.55 V (min = +10.82 V, max = +13.19 V)
CPU0: 12980 RPM (min = 3750 RPM, div = 8)
CPU1: 0 RPM (min = 750 RPM, div = 8)
CPU0: +29.0?C (high = +60?C, hyst = +50?C) sensor =
PII/Celeron diode
CPU1: +29.5?C (high = +50?C, hyst = +50?C) sensor =
PII/Celeron diode
vid: +0.000 V
alarms: Chassis intrusion detection ALARM
beep_enable:
Sound alarm disabled
buick:~# sensors
w83627hf-i2c-0-2d
Adapter: SMBus Via Pro adapter at 5000
Algorithm: Unavailable from sysfs
VCore 1: +1.81 V (min = +1.66 V, max = +0.72 V)
VCore 2: +4.08 V (min = +1.66 V, max = +4.08 V)
+3.3V: +3.34 V (min = +3.14 V, max = +3.46 V)
+5V: +4.95 V (min = +4.73 V, max = +5.24 V)
+12V: +11.55 V (min = +10.82 V, max = +13.19 V)
CPU0: 450000 RPM (min = 30000 RPM, div = 1)
CPU1: 0 RPM (min = 6000 RPM, div = 1)
CPU0: +29.0?C (high = +60?C, hyst = +50?C) sensor =
PII/Celeron diode
CPU1: +29.5?C (high = +50?C, hyst = +50?C) sensor =
PII/Celeron diode
vid: +3.300 V
alarms: Chassis intrusion detection ALARM
beep_enable:
Sound alarm disabled
buick:~# sensors
w83627hf-i2c-0-2d
Adapter: SMBus Via Pro adapter at 5000
Algorithm: Unavailable from sysfs
VCore 1: +1.79 V (min = +3.14 V, max = +3.46 V)
VCore 2: +1.50 V (min = +3.14 V, max = +3.46 V)
+3.3V: +3.34 V (min = +3.14 V, max = +3.46 V)
+5V: +5.03 V (min = +4.73 V, max = +5.24 V)
+12V: +11.49 V (min = +10.82 V, max = +15.50 V)
CPU0: 337500 RPM (min = 7500 RPM, div = 4)
CPU1: 3125 RPM (min = 1500 RPM, div = 4)
CPU0: +29.0?C (high = +60?C, hyst = +50?C) sensor =
PII/Celeron diode
CPU1: +29.0?C (high = +50?C, hyst = +50?C) sensor =
PII/Celeron diode
vid: +3.300 V
alarms: Chassis intrusion detection ALARM
beep_enable:
Sound alarm disabled
It works fine with MBM in Windows. Well, MBM is having some troubles
with the temperature (it gets lower and lower as time pass, and ends on
about 8-9 degrees celsius. But fan and temperatures are read just fine,
never any glitch. On thing thing though, the Vcore2 is 1,70. The Bios
reports it correctly, but both MBM and LM-sensors says 1,50. Have no
idea why. The 1,50 is static, never changes, while VCore1 (which ideally
should be 1,75) varies from 1,75 to 1,79. In the BIOS both seem sane,
and varies with 3-4 degrees.
I guess all these problems are because of the bus collision, which I
have read usually happens because of bad boards. Which I admit that I do
have, but it works in Windows :(
What are the most common reasons for the bus collisions, and is there
anything to do?
Best regards,
Stian
> i2c_adapter i2c-0: Bus collision! SMBus may be locked until next hard
> reset. (sorry!)
>
> Kernel 2.6.0 with lm-sensors 2.8.2.
Are you able to reproduce the same behavior with kernel 2.4.24 and
lm-sensors 2.8.2?
> I get very weird results, especially on the fan, but others as well.
> Here are three runs of sensors:
> (...)
Could you provide a few outputs of "i2cdump 0 0x2d"? I wonder if this
will show read errors (as "XX") or simply changing values.
Does your BIOS provide a feature such as "Circle Of Protection" or
anything that sounds like "active" hardware monitoring? Is it enabled?
If you have any other chips (eeproms for example) on the bus, do you
observe similar behavior with these?
> It works fine with MBM in Windows. Well, MBM is having some troubles
> with the temperature (it gets lower and lower as time pass, and ends
> on about 8-9 degrees celsius. But fan and temperatures are read just
> fine, never any glitch. On thing thing though, the Vcore2 is 1,70. The
> Bios reports it correctly, but both MBM and LM-sensors says 1,50. Have
> no idea why. The 1,50 is static, never changes, while VCore1 (which
> ideally should be 1,75) varies from 1,75 to 1,79. In the BIOS both
> seem sane, and varies with 3-4 degrees.
>
> I guess all these problems are because of the bus collision, which I
> have read usually happens because of bad boards. Which I admit that I
> do have, but it works in Windows :(
Which motherboard is it?
Did you have to enable any particular option in MBM?
> What are the most common reasons for the bus collisions (...)?
Bad brakes?
Just kidding... ;)
--
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/
tor, 08.01.2004 kl. 23.05 skrev Jean Delvare:
> > i2c_adapter i2c-0: Bus collision! SMBus may be locked until next hard
> > reset. (sorry!)
> >
> > Kernel 2.6.0 with lm-sensors 2.8.2.
>
> Are you able to reproduce the same behavior with kernel 2.4.24 and
> lm-sensors 2.8.2?
Just tried, and I do. I forgot to mention it in my last mail, but I
sometime has to reload the modules before "sensors" finds any sensor.
> > I get very weird results, especially on the fan, but others as well.
> > Here are three runs of sensors:
> > (...)
>
> Could you provide a few outputs of "i2cdump 0 0x2d"? I wonder if this
> will show read errors (as "XX") or simply changing values.
Attached three runs. Seems to be some read errors :( On these three runs I got
first three bus-collisions, then one, and last two.
> Does your BIOS provide a feature such as "Circle Of Protection" or
> anything that sounds like "active" hardware monitoring? Is it enabled?
No such option.
> If you have any other chips (eeproms for example) on the bus, do you
> observe similar behavior with these?
Not other chips.
> > It works fine with MBM in Windows. Well, MBM is having some troubles
> > with the temperature (it gets lower and lower as time pass, and ends
> > on about 8-9 degrees celsius. But fan and temperatures are read just
> > fine, never any glitch. On thing thing though, the Vcore2 is 1,70. The
> > Bios reports it correctly, but both MBM and LM-sensors says 1,50. Have
> > no idea why. The 1,50 is static, never changes, while VCore1 (which
> > ideally should be 1,75) varies from 1,75 to 1,79. In the BIOS both
> > seem sane, and varies with 3-4 degrees.
> >
> > I guess all these problems are because of the bus collision, which I
> > have read usually happens because of bad boards. Which I admit that I
> > do have, but it works in Windows :(
>
> Which motherboard is it?
A Rioworks SDVIA (http://www.rioworks.com/SDVIA.htm) Not very new, I'm afraid.
And not very good.
> Did you have to enable any particular option in MBM?
Nah, it just worked :)
> > What are the most common reasons for the bus collisions (...)?
>
> Bad brakes?
>
> Just kidding... ;)
Hehe :)
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.
Thanks for your reply :)
Best regards,
Stian
Jean,
sorry to bother you again, but this didn't tell you anything about
what's going on?
Best regards,
Stian
l?r, 10.01.2004 kl. 05.06 skrev Stian Jordet:
> tor, 08.01.2004 kl. 23.05 skrev Jean Delvare:
> > > i2c_adapter i2c-0: Bus collision! SMBus may be locked until next hard
> > > reset. (sorry!)
> > >
> > > Kernel 2.6.0 with lm-sensors 2.8.2.
> >
> > Are you able to reproduce the same behavior with kernel 2.4.24 and
> > lm-sensors 2.8.2?
>
> Just tried, and I do. I forgot to mention it in my last mail, but I
> sometime has to reload the modules before "sensors" finds any sensor.
>
> > > I get very weird results, especially on the fan, but others as well.
> > > Here are three runs of sensors:
> > > (...)
> >
> > Could you provide a few outputs of "i2cdump 0 0x2d"? I wonder if this
> > will show read errors (as "XX") or simply changing values.
>
> Attached three runs. Seems to be some read errors :( On these three runs I got
> first three bus-collisions, then one, and last two.
>
> > Does your BIOS provide a feature such as "Circle Of Protection" or
> > anything that sounds like "active" hardware monitoring? Is it enabled?
>
> No such option.
>
> > If you have any other chips (eeproms for example) on the bus, do you
> > observe similar behavior with these?
>
> Not other chips.
>
> > > It works fine with MBM in Windows. Well, MBM is having some troubles
> > > with the temperature (it gets lower and lower as time pass, and ends
> > > on about 8-9 degrees celsius. But fan and temperatures are read just
> > > fine, never any glitch. On thing thing though, the Vcore2 is 1,70. The
> > > Bios reports it correctly, but both MBM and LM-sensors says 1,50. Have
> > > no idea why. The 1,50 is static, never changes, while VCore1 (which
> > > ideally should be 1,75) varies from 1,75 to 1,79. In the BIOS both
> > > seem sane, and varies with 3-4 degrees.
> > >
> > > I guess all these problems are because of the bus collision, which I
> > > have read usually happens because of bad boards. Which I admit that I
> > > do have, but it works in Windows :(
> >
> > Which motherboard is it?
>
> A Rioworks SDVIA (http://www.rioworks.com/SDVIA.htm) Not very new, I'm afraid.
> And not very good.
>
> > Did you have to enable any particular option in MBM?
>
> Nah, it just worked :)
>
> > > What are the most common reasons for the bus collisions (...)?
> >
> > Bad brakes?
> >
> > Just kidding... ;)
>
> Hehe :)
>
> 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.
>
> Thanks for your reply :)
>
> Best regards,
> Stian
> 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.
--
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/
l?r, 17.01.2004 kl. 09.48 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 do. Sorry for buggin' you again, I just figured you had forgot me when
you answered other mails on LKML.
> > > 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.
I see.
> > > 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.
I don't doubt that.
> > > > 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).
Yes, it's a Via Apollo Pro 133A.
> 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 help :)
Best regards,
Stian
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.
>
Hi Stian,
> 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 :)
Thanks a lot for keeping us informed.
Too bad you did not tell us you had the possibility to use the ISA
access in the first place. It is well known that ISA access is more
reliable than SMBus or I2C.
It also might explain why MBM was working without a problem. I suppose
it was also using the ISA interface, same as you do now.
--
Jean Delvare
http://khali.linux-fr.org/
ons, 12,.01.2005 kl. 21.23 +0100, skrev Jean Delvare:
> Hi Stian,
>
> > 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 :)
>
> Thanks a lot for keeping us informed.
>
> Too bad you did not tell us you had the possibility to use the ISA
> access in the first place. It is well known that ISA access is more
> reliable than SMBus or I2C.
>
> It also might explain why MBM was working without a problem. I suppose
> it was also using the ISA interface, same as you do now.
Believe me, had I known it, I would have told you :) Anyway, a happy
ending :) Thanks for your support.
Best regards,
Stian