lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Fri, 16 May 2008 17:22:07 +0200
From:	Michelle Konzack <linux4michelle@...ay-dogan.net>
To:	linux-kernel@...r.kernel.org
Subject: Re: Hardware designt to prevent Damages... [WAS: [patch 23/37] i2c-piix4: Blacklist two mainboards]

Hello Jean,

Thank you for explanation.

OK, if I understand I2C right, there are more or less reserved addresses
for each type of chip if I understand it  right,  but  I  have  only  an
incomplete list of it. (gotten from the  NXP  website  where  the  Tech-
Support is very helpful.  Same for Dallas/Maxim)

Do you know, where I can get a full list of it?

Thanks, Greetings and nice Day
    Michelle Konzack
    Tamay Dogan Network
    Debian GNU/Linux Consultant


Am 2008-05-15 20:49:55, schrieb Jean Delvare:
> In this particular case, the CPU was apparently damaged as the result
> of accidental memory over-voltage. It is worth noting though that said
> CPU had gone through intensive overclocking session beforehand, and
> this might explain the death. Other CPUs are known to have gone through
> the same experience and are still working.
> 
> So, to clear up any misunderstanding: the CPU damage did not occur
> because we used some odd CPU instruction sequence or anything like
> that. The damage came to the CPU from other hardware on the board.
> 
> To be a bit more technical, the design mistake (I think) that was made
> by the designers of the motherboard in question, was to use an
> I2C/SMBus chip on a PC motherboard, which uses SMBus receive byte and
> SMBus send byte for control, and which lives at an I2C address which is
> very common amongst hardware monitoring chip. The 4th factor being, of
> course, that improperly programming the chip in question can result in
> hardware damage. If only 3 of these 4 factors had been present, most
> probably there would have been no issue in practice. But with all 4
> factors, bad things just had to happen. And it's not just Linux, users
> had similar problems running hardware monitoring tools under Windows
> too.
------------------------ END OF REPLIED MESSAGE ------------------------



-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack   Apt. 917                  ICQ #328449886
+49/177/9351947    50, rue de Soultz         MSN LinuxMichi
+33/6/61925193     67100 Strasbourg/France   IRC #Debian (irc.icq.com)

Download attachment "signature.pgp" of type "application/pgp-signature" (190 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ