similar to: Module i2c-piix4 for lm_sensors on CentOS 5 64 Bit

I have a Tyan Thunder K8HM (S3892) motherboard and I am trying to get lm_sensors to work with it. The problem is that I am getting conflicting information. The source for lm_sensors says not to compile the modules for the 2.6 kernel. The information from Tyan says that I need to compile the modules if my kernel is less than 2.6.12. Has anyone here configured lm_sensors for this motherboard?

I have a Tyan S3870 (K855A) motherboard which I would like to perform a burn in test with. lm_sensors needs a kernel module compiled to be support this motherboard's sensors. The instructions, for compiling the module, by tyan (ftp://ftp.tyan.com/software/lms/3870.sensors.conf) match closely with the instructions I found here (http://www.howtoforge.com/kernel_compilation_centos). I

Tyan has posted a lm_sensors config file for the Thunder K8SE S2892 at ftp://ftp.tyan.com/software/lms/lms_s2892.conf However when I ran the sensors command on my S2892 I was getting a readout for an adt7463 chip that wasn't referenced in the config file. I emailed Raphael Deng at Tyan asking him to confirm the manual edit needed to get sensors.conf to refer to the adt7463 chip. His

CentOS Guru's, I am trying to get supermicro's superodoctorII to spit out some numbers for CPU temps but I am failing. It appears I need a module i2c-piix4 but it is not available in the kernel. Trusty old lm_sensors won't seem to work with this darn board. Any hints would be mucho appreciated. Rik

Does anyone know how to upgrade the I2C modules *without* compiling the current kernel source? I have a system that apparently needs the current set of I2C modules to work with lm_sensors. If I compile the current kernel source, the proper readings show up. However, with the stock 2.6.9-42.0.2 kernel, one sensor chip isn't seen. Trying to compile the I2C source yields a "Use the

Has anyone succeeded in getting lm_sensors to produce useful output for intel D945-based motherboards? According to the lm_sensors site, I need a newer kernel (2.6.16) to read the ICH7 data. I noticed the i2c patches in the kernel source rpm, but no joy. I'd be okay with building my own modules, but haven't found anyone to provide the kernel module source apart from the kernel

I'd like to export the corresponding functions from the i2c core so that I can use them in fallback bit-banging in i915.ko Cc: nouveau at lists.freedesktop.org Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch> --- drivers/gpu/drm/nouveau/nouveau_i2c.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_i2c.c

Signed-off-by: Viktor Novotny <noviktor at seznam.cz> --- Hi, I think I found a bug - my NV11 fails to init i2c ports and is then unable to read EDID. It's because while i2c_table in nouveau_i2c.c:324 returns null for this card, i2c is initialized anyway at line 341 and wrong i2c table format is then selected at line 350. This patch fixes the problem on NV11 and was tested also on NV25.

Hello I'm encountering a big problem with usbhid-ups driver : the driver hangs after loading some other modules (stale data message) ! And we can't restart it. We load : i2c-piix4 adm1021 adm9240 lm75 The unloading of the modules doesn't solve the problem. # ps -eaf | grep usb /root 188 2 0 07:29 ? 00:00:00 [ksuspend_usbd] root 996 2 0 07:29 ?

For a while, we've had the problem of i2c bus access not grabbing a runtime PM ref when it's being used in userspace by i2c-dev, resulting in nouveau spamming the kernel log with errors if anything attempts to access the i2c bus while the GPU is in runtime suspend. An example: [ 130.078386] nouveau 0000:01:00.0: i2c: aux 000d: begin idle timeout ffffffff Since the GPU is in runtime

On 2020/9/3 ??1:34, Jie Deng wrote: > Add an I2C bus driver for virtio para-virtualization. > > The controller can be emulated by the backend driver in > any device model software by following the virtio protocol. > > This driver communicates with the backend driver through a > virtio I2C message structure which includes following parts: > > - Header: i2c_msg addr,

On 9/10/20 8:48 PM, Jie Deng wrote: > diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig > index 293e7a0..70c8e30 100644 > --- a/drivers/i2c/busses/Kconfig > +++ b/drivers/i2c/busses/Kconfig > @@ -21,6 +21,17 @@ config I2C_ALI1535 > This driver can also be built as a module. If so, the module > will be called i2c-ali1535. > > +config

On Wed, 10 Apr 2019 at 06:23, Lyude Paul <lyude at redhat.com> wrote: > > For a while, we've had the problem of i2c bus access not grabbing > a runtime PM ref when it's being used in userspace by i2c-dev, resulting > in nouveau spamming the kernel log with errors if anything attempts to > access the i2c bus while the GPU is in runtime suspend. An example: > > [

On Thu, Sep 03, 2020 at 01:34:45PM +0800, Jie Deng wrote: > Add an I2C bus driver for virtio para-virtualization. > > The controller can be emulated by the backend driver in > any device model software by following the virtio protocol. > > This driver communicates with the backend driver through a > virtio I2C message structure which includes following parts: > > -

On 2020/9/3 ??1:34, Jie Deng wrote: > Add an I2C bus driver for virtio para-virtualization. > > The controller can be emulated by the backend driver in > any device model software by following the virtio protocol. > > This driver communicates with the backend driver through a > virtio I2C message structure which includes following parts: > > - Header: i2c_msg addr,

On 2020/9/11 ??11:48, Jie Deng wrote: > Add an I2C bus driver for virtio para-virtualization. > > The controller can be emulated by the backend driver in > any device model software by following the virtio protocol. > > This driver communicates with the backend driver through a > virtio I2C message structure which includes following parts: > > - Header: i2c_msg addr,

On 2020/9/4 ??9:21, Jie Deng wrote: > > On 2020/9/4 12:06, Jason Wang wrote: >> >>> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig >>> index 293e7a0..70c8e30 100644 >>> --- a/drivers/i2c/busses/Kconfig >>> +++ b/drivers/i2c/busses/Kconfig >>> @@ -21,6 +21,17 @@ config I2C_ALI1535 >>> ??????? This driver can

On Tue, Sep 22, 2020 at 10:58:43AM +0800, Jie Deng wrote: > Add an I2C bus driver for virtio para-virtualization. > > The controller can be emulated by the backend driver in > any device model software by following the virtio protocol. > > This driver communicates with the backend driver through a > virtio I2C message structure which includes following parts: > > -

On 2020/9/3 14:12, Jason Wang wrote: > > On 2020/9/3 ??1:34, Jie Deng wrote: >> Add an I2C bus driver for virtio para-virtualization. >> >> The controller can be emulated by the backend driver in >> any device model software by following the virtio protocol. >> >> This driver communicates with the backend driver through a >> virtio I2C message

It turns out that while disabling i2c bus access from software when the GPU is suspended was a step in the right direction with: commit 342406e4fbba ("drm/nouveau/i2c: Disable i2c bus access after ->fini()") We also ended up accidentally breaking the vbios init scripts on some older Tesla GPUs, as apparently said scripts can actually use the i2c bus. Since these scripts are executed