smbus probleempje met intel chipsets

[femmer]

Hallo,

een tijdje terug heb ik op ebay 2 intel NIC's (X540-T2) gekocht voor wat testen te doen. Bij het plaatsen van zo'n NIC in een asus moederbord (in dit geval een P8Z77-v pro) kwam het systeem niet door POST, de z.g.n "mem-led" op dit bord bleef branden. Uiteindelijk heb ik het werkend gekregen door de helft van het geheugen te verwijderen.
Na weken zoeken wat het probleem zou kunnen zijn kwam ik dit weekend de volgende link tegen:
scroll naar "SMBus Issue with Intel Chipsets".
Dit heb ik geprobeerd en jawel, deze "truuk" werkt dus ook bij mijn netwerkkaarten.
Ik heb nog redelijk wat lopen zoeken hierover op internet maar kom er niet achter en dus is mijn vraag hier: zit de fout in de insteekkaarten (b.v. die raid controller of de NIC) of in het moederbord?
Ik heb nl. een supermicro bordje (X9SAE2, ook met intel chipset) en die heeft nergens last van. Het probleem heb ik ook getest op een MSI bordje (b85i) en die mist ook de helft van het geheugen zonder gepatchte NIC.
Een aantal weken terug heb ik e.e.a. ook voorgelegd aan Asus (ik dacht dat hun moederbord niet goed was) maar daar ben ik nog niet veel mee opgeschoten.
Dus wie doet het fout? Moederbord makers of insteekkaart fabrikanten?

[ThePowershift]

Heb je ook al een keer een ander PCI-E slot geprobeerd?
Naar mijn weten is het bovenste slot voor een VGA kaart en is de onderste voor evt. uitbreidings kaarten, ik heb er na genoeg geen problemen mee gehad, nieuwste drivers ook al geprobeerd?

bios instellingen ook na gekeken?

[Ploink]

femmer schreef op maandag 28 oktober 2013 @ 17:43:
Dus wie doet het fout? Moederbord makers of insteekkaart fabrikanten?

SMBus is min of meer compatibel met I2C waar elke aangesloten slave een eigen adres heeft. Bij I2C is het een vast adres en dus kunnen er conflicten optreden, maar:
Wikipedia: System Management Bus Address_Resolution_Protocol

The SMBus uses I²C hardware and I²C hardware addressing, but adds second-level software for building special systems. In particular its specifications include an Address Resolution Protocol that can make dynamic address allocations. Dynamic reconfiguration of the hardware and software allow bus devices to be ‘hot-plugged’ and used immediately, without restarting the system. The devices are recognized automatically and assigned unique addresses.

http://cache.freescale.co...t/doc/app_note/AN4471.pdf

Each device that exists as a slave on the SMBus has one unique seven bit address called the slave address. Each address is seven bits long with a read/write bit appended in bit position 0. When a device “sees” its address, it wakes up and responds to the rest of the command. Besides the General Call Address, SMBus systems can have 127 devices. SMBus version 2.0 introduces the concept of dynamically assigned addresses, and the SMBus Device Default Address is reserved for this purpose. A process called SMBus Address Resolution Protocol (ARP) uses this address. When the host detects two devices with the same slave address, the ARP process resolves the slave address conflict by dynamically assigning a new unique address to slaves.

Ik denk dat minimaal een van de twee apparaten niet v2.0 compatibel is en er toevallig een conflict optreedt.

Wikipedia: Serial presence detect

The SPD EEPROM is accessed using SMBus, a variant of the I²C protocol. This reduces the number of communication pins on the module to just two: a clock signal and a data signal. The EEPROM shares ground pins with the RAM, has its own power pin, and has three additional pins (SA0–2) to identify the slot, which are used to assign the EEPROM a unique address in the range 0x50–0x57. Not only can the communication lines be shared among 8 memory modules, the same SMBus is commonly used on motherboards for system health monitoring tasks such as reading power supply voltages, CPU temperatures, and fan speeds.

(SPD EEPROMs also respond to I²C addresses 0x30–0x37 if they have not been write protected, and an extension uses addresses 0x18–0x1F to access an optional on-chip temperature sensor.[2])

SPD heeft dus een vast adres bereik en als daarmee een conflict optreedt, dan denk ik dat het probleem in de netwerk kaart zit. Ik denk dat de netwerk kaart een illegaal adres gebruikt voor een temperatuur sensortje oid, dus door deze af te lakken mis je die functie nu.

Misschien kan je het adres achterhalen. Installeer lm_sensors in Linux en gebruik sensors-detect om je hele smbus te scannen. Vergelijk de output met en zonder de NIC geinstalleerd. Onder Windows lukt dit misschien met Speedfan.

[ Voor 27% gewijzigd door Ploink op 29-10-2013 10:34 ]

[femmer]

venmulder schreef op dinsdag 29 oktober 2013 @ 09:06:
Heb je ook al een keer een ander PCI-E slot geprobeerd?
Naar mijn weten is het bovenste slot voor een VGA kaart en is de onderste voor evt. uitbreidings kaarten, ik heb er na genoeg geen problemen mee gehad, nieuwste drivers ook al geprobeerd?

bios instellingen ook na gekeken?

Ja, natuurlijk ook andere pci-e sloten geprobeerd, maakt niet uit. Het is geen driver issue en in de BIOS zie ik geen opties.
Zie ook het antwoord van Ploink.

[femmer]

[...]
Ik denk dat minimaal een van de twee apparaten niet v2.0 compatibel is en er toevallig een conflict optreedt.

Ja, zou kunnen. Ik verwacht bij een haswell bordje toch wil minstens v2.0 en eigenlijk ook een bij een PCI-E gen2 NIC. Er is iets niet compatible met smbus en/of PCI-E spec maar is dat het bord of de NIC?

SPD heeft dus een vast adres bereik en als daarmee een conflict optreedt, dan denk ik dat het probleem in de netwerk kaart zit. Ik denk dat de netwerk kaart een illegaal adres gebruikt voor een temperatuur sensortje oid, dus door deze af te lakken mis je die functie nu.

Misschien kan je het adres achterhalen. Installeer lm_sensors in Linux en gebruik sensors-detect om je hele smbus te scannen. Vergelijk de output met en zonder de NIC geinstalleerd. Onder Windows lukt dit misschien met Speedfan.

Nog niet geprobeerd met sensors (lspci -vvv kwam ik iig niet verder mee) maar in de X540 FAQ vond ik dit:
What are the X540 SMBus slave addresses?
For NVM images that support SMBus manageability, SMBus addresses are defined as:
SMBus 0 Slave Address 0x63
SMBus 1 Slave Address 0x62

Dat zou dus niet moeten/mogen conflicteren met die EEPROM.
Dank voor de input. Ik ga het nog eens verder voorleggen bij ASUS hoewel ik betwijfel of ze 't gaan oplossen gezien het probleem al sinds 2008 bekend is bij meerdere merken en generaties mobo's.
Bij Intel heeft ook iemand gevraagd hoe het zit maar helaas geen reactie van Intel.