Bug 5889

Summary: modprobe it87 causes system to reboot
Product: Drivers Reporter: drago01
Component: Hardware MonitoringAssignee: Jean Delvare (jdelvare)
Status: CLOSED CODE_FIX    
Severity: blocking CC: bunk
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: 2.6.15 Subsystem:
Regression: --- Bisected commit-id:
Attachments: kernel config
Prevent system reboot on modprobe it87
Prevent system reboot on modprobe it87 (v2)
Prevent system reboot on modprobe it87 (v3)
dmidecode output
i2c-nforce2: Disable the second SMBus channel on the DFI Lanparty NF4 Expert

Description drago01 2006-01-14 01:55:55 UTC
Most recent kernel where this bug did not occur: N/A
Distribution: Fedora Core 4 x86_64
Hardware Environment:
(DFI LANPARTY NF4 SLI EXPERT)
00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3)
00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)
00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2)
00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3)
00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev a2)
00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev a3)
00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev a3)
00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2)
00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
00:0b.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:0c.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM
Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Miscellaneous Control
01:07.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 0a)
01:07.1 Input device controller: Creative Labs SB Live! MIDI/Game Port (rev 0a)
01:09.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller
(rev 80)
01:0a.0 Ethernet controller: Marvell Technology Group Ltd. 88E8001 Gigabit
Ethernet Controller (rev 13)
05:00.0 VGA compatible controller: nVidia Corporation GeForce 7800 GTX (rev a1)

Software Environment:
lm_sensors-2.9.1-3.FC4.2

Problem Description:
I bought a new mobo and did sensors-detect but my system got frozen.
so I decided to load the module by hand and did modprobe it87 and the system
imeadetly rebooted. Tryed again, flashed new bios always the same.
whats wrong? any info that I can provide to help debuging this?
Steps to reproduce:
modprobe it87
Comment 1 Jean Delvare 2006-01-14 02:13:06 UTC
Where did sensors-detect stop exactly? Please provide the first part, before it
stops (you can use either "script" or "tee" to log this.)

Is this a vanilla or distribution kernel? If distribution, self-compiled or
binary package? Please provide the kernel configuration file. Please also
provide the output of "lsmod" (before you try to load the it87 driver, obviously.)

Is this an UP or SMP system? Overclocked?

Are there any additional patches to the kernel or any external drivers on that
system?

Please also provide the output of "i2cdetect -l". For each bus listed, provide
the output of "i2cdetect N" (where N is the number of that bus.) Beware that
this may cause your system to freeze.
Comment 2 drago01 2006-01-14 02:47:05 UTC
note: monitring works with xmbmon
>Where did sensors-detect stop exactly? Please provide the first part, before it
>stops (you can use either "script" or "tee" to log this.)
Next adapter: SMBus nForce2 adapter at 1c40
Do you want to scan it? (YES/no/selectively):
after pressing enter it hangs
>Is this a vanilla or distribution kernel? If distribution, self-compiled or
>binary package? Please provide the kernel configuration file. Please also
>provide the output of "lsmod" (before you try to load the it87 driver, >obviously.)
its the fedora distro kernel kernel-2.6.15-1.1824_FC4 (binary one) 
will attach the config after posting this
Is this an UP or SMP system? Overclocked?
its a UP sys with an SMP enabled kernel 
its overclocked now but this also happens at stock speeds
lsmod:
Module                  Size  Used by
i2c_dev                46145  0
eeprom                 41809  0
hwmon_vid              35905  0
hwmon                  36809  0
i2c_isa                39617  0
ipv6                  432321  324
ipt_limit              36033  3
iptable_mangle         36417  1
ipt_LOG                40769  3
ipt_MASQUERADE         37441  0
ip_nat                 56537  1 ipt_MASQUERADE
ipt_TOS                35905  20
ipt_REJECT             39489  1
ip_conntrack_irc       40993  0
ip_conntrack_ftp       42409  0
ipt_state              35393  6
ip_conntrack           98409  5
ipt_MASQUERADE,ip_nat,ip_conntrack_irc,ip_conntrack_ftp,ipt_state
nfnetlink              40969  2 ip_nat,ip_conntrack
iptable_filter         36673  1
ip_tables              56897  8
ipt_limit,iptable_mangle,ipt_LOG,ipt_MASQUERADE,ipt_TOS,ipt_REJECT,ipt_state,iptable_filter
vfat                   48577  0
fat                    91633  1 vfat
nls_utf8               35521  2
ntfs                  134912  2
dm_mod                 99336  0
video                  52553  0
button                 41185  0
battery                44232  0
ac                     38985  0
ohci1394               71457  0
ieee1394              407641  1 ohci1394
ohci_hcd               57565  0
ehci_hcd               70477  0
i2c_nforce2            41409  0
i2c_core               59457  4 i2c_dev,eeprom,i2c_isa,i2c_nforce2
emu10k1_gp             37569  0
gameport               51793  2 emu10k1_gp
snd_emu10k1_synth      41793  0
snd_emux_synth         76609  1 snd_emu10k1_synth
snd_seq_virmidi        41921  1 snd_emux_synth
snd_seq_midi_emul      41281  1 snd_emux_synth
snd_emu10k1           164741  4 snd_emu10k1_synth
snd_rawmidi            64225  2 snd_seq_virmidi,snd_emu10k1
snd_ac97_codec        146045  1 snd_emu10k1
snd_seq_dummy          37445  0
snd_seq_oss            71973  0
snd_seq_midi_event     42177  2 snd_seq_virmidi,snd_seq_oss
snd_seq                99225  8
snd_emux_synth,snd_seq_virmidi,snd_seq_midi_emul,snd_seq_dummy,snd_seq_oss,snd_seq_midi_event
snd_seq_device         43857  7
snd_emu10k1_synth,snd_emux_synth,snd_emu10k1,snd_rawmidi,snd_seq_dummy,snd_seq_oss,snd_seq
snd_pcm_oss            93297  0
snd_mixer_oss          52673  2 snd_pcm_oss
snd_pcm               139593  4 snd_emu10k1,snd_ac97_codec,snd_pcm_oss
snd_timer              62025  3 snd_emu10k1,snd_seq,snd_pcm
snd_ac97_bus           36033  1 snd_ac97_codec
snd_page_alloc         46289  2 snd_emu10k1,snd_pcm
snd_util_mem           38977  2 snd_emux_synth,snd_emu10k1
snd_hwdep              44897  2 snd_emux_synth,snd_emu10k1
snd                   103073  16
snd_emux_synth,snd_seq_virmidi,snd_emu10k1,snd_rawmidi,snd_ac97_codec,snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer,snd_hwdep
soundcore              45025  2 snd
sk98lin               230404  1
forcedeth              60869  0
floppy                107993  0
ext3                  179665  2
jbd                   100073  1 ext3
sata_nv                44101  5
libata                 98265  1 sata_nv
sd_mod                 53697  6
scsi_mod              195705  2 libata,sd_mod

>Are there any additional patches to the kernel or any external drivers on that
>system?
the ones from fedora and the nvidia one (disabled for debugging)
>Please also provide the output of "i2cdetect -l". For each bus listed, provide
>the output of "i2cdetect N" (where N is the number of that bus.) Beware that
>this may cause your system to freeze.
i2c-1   unknown         SMBus nForce2 adapter at 1c40           Algorithm
unavailable
i2c-0   unknown         SMBus nForce2 adapter at 1c00           Algorithm
unavailable
i2cdetect 0
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-0.
I will probe address range 0x03-0x77.
Continue? [Y/n]
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          XX XX XX XX XX 08 XX XX XX XX XX XX XX
10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
50: XX XX UU UU XX XX XX UU XX XX XX XX XX XX XX XX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
70: XX XX XX XX XX XX XX XX

i2cdetect 1
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-1.
I will probe address range 0x03-0x77.
Continue? [Y/n]
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          XX XX XX XX XX 08 XX XX XX XX XX XX XX
10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX 2e XX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX 4e XX
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
70: XX XX XX XX XX XX XX XX
Comment 3 drago01 2006-01-14 02:48:55 UTC
Created attachment 7023 [details]
kernel config
Comment 4 Jean Delvare 2006-01-14 04:12:00 UTC
I suspect that the I2C/SMBus device at 0x2e on nForce4 SMBus #1 is causing the
trouble. It is probably not the IT87xxF hardware monitoring device (these tend
to be only accessed by their ISA address these days) but the it87 driver still
attempts to probe this address as it could, in theory, be the address of a
supported device. Whatever chip is actually there doesn't seem to like the
probing sequence and freezes the machine to express its anger.

At least this is my theory. Please do the following tests which will confirm or
infirm it, and will also help me refine the diagnosis:

1* Run sensors-detect, and when you get the following prompt:
 Next adapter: SMBus nForce2 adapter at 1c40
 Do you want to scan it? (YES/no/selectively):
Answer "S" (for selectively) then type the address "0x2e". This will skip this
address and hopefully sensors-detect will be able to finish its job. If so,
please report the final summary.

2* Try loading the it87 driver with option ignore=1,0x2e. This should let the
driver load without locking your system. If not, try unloading the i2c-nforce2
driver before loading the it87 driver. Report what worked.

3* I suspect that running "i2cdump 1 0x2e" (to dump the contents of the
mysterious chip) would lock your system just like "sensors-detect" and "modprobe
it87" did so far. You may still try if you are curious - but this ain't strictly
necessary.
Comment 5 drago01 2006-01-14 04:17:53 UTC
no freeze this time using your method:
sensors-detect

This program will help you determine which I2C/SMBus modules you need to
load to use lm_sensors most effectively. You need to have i2c and
lm_sensors installed before running this program.
Also, you need to be `root', or at least have access to the /dev/i2c-*
files, for most things.
If you have patched your kernel and have some drivers built in, you can
safely answer NO if asked to load some modules. In this case, things may
seem a bit confusing, but they will still work.

It is generally safe and recommended to accept the default answers to all
questions, unless you know what you're doing.

 We can start with probing for (PCI) I2C or SMBus adapters.
 You do not need any special privileges for this.
 Do you want to probe now? (YES/no):
Probing for PCI bus adapters...
Use driver `i2c-nforce2' for device 00:01.1: nVidia Corporation nForce4 SMBus (MCP)
Probe succesfully concluded.

We will now try to load each adapter module in turn.
Module `i2c-nforce2' already loaded.
If you have undetectable or unsupported adapters, you can have them
scanned by manually loading the modules before running this script.

 To continue, we need module `i2c-dev' to be loaded.
 If it is built-in into your kernel, you can safely skip this.
 i2c-dev is not loaded. Do you want to load it now? (YES/no):
 Module loaded succesfully.

 We are now going to do the adapter probings. Some adapters may hang halfway
 through; we can't really help that. Also, some chips will be double detected;
 we choose the one with the highest confidence value in that case.
 If you found that the adapter hung after probing a certain address, you can
 specify that address to remain unprobed. That often
 includes address 0x69 (clock chip).

Next adapter: SMBus nForce2 adapter at 1c40
Do you want to scan it? (YES/no/selectively): S
Please enter one or more addresses not to scan. Separate them with comma's.
You can specify a range by using dashes. Addresses may be decimal (like 54)
or hexadecimal (like 0x33).
Addresses: 0x2e
Client found at address 0x08
Client found at address 0x4e
Probing for `National Semiconductor LM75'... Failed!
Probing for `Dallas Semiconductor DS1621'... Success!
    (confidence 3, driver `ds1621')
Probing for `Analog Devices ADM1021'... Failed!
Probing for `Analog Devices ADM1021A/ADM1023'... Failed!
Probing for `Maxim MAX1617'... Failed!
Probing for `Maxim MAX1617A'... Failed!
Probing for `TI THMC10'... Failed!
Probing for `National Semiconductor LM84'... Failed!
Probing for `Genesys Logic GL523SM'... Failed!
Probing for `Onsemi MC1066'... Failed!
Probing for `Maxim MAX1619'... Failed!
Probing for `National Semiconductor LM82'... Failed!
Probing for `National Semiconductor LM83'... Failed!
Probing for `Maxim MAX6659'... Failed!
Probing for `Maxim MAX6633/MAX6634/MAX6635'... Failed!

Next adapter: SMBus nForce2 adapter at 1c00
Do you want to scan it? (YES/no/selectively): S
Please enter one or more addresses not to scan. Separate them with comma's.
You can specify a range by using dashes. Addresses may be decimal (like 54)
or hexadecimal (like 0x33).
Addresses: 0x2e
Client found at address 0x08
Client found at address 0x52
Probing for `SPD EEPROM'... Success!
    (confidence 8, driver `eeprom')
Client found at address 0x53
Probing for `SPD EEPROM'... Success!
    (confidence 8, driver `eeprom')
Client found at address 0x57
Probing for `SPD EEPROM'... Success!
    (confidence 1, driver `eeprom')
Probing for `Sony Vaio EEPROM'... Failed!

Some chips are also accessible through the ISA bus. ISA probes are
typically a bit more dangerous, as we have to write to I/O ports to do
this. This is usually safe though.

Do you want to scan the ISA bus? (YES/no):
Probing for `National Semiconductor LM78'
  Trying address 0x0290... Failed!
Probing for `National Semiconductor LM78-J'
  Trying address 0x0290... Failed!
Probing for `National Semiconductor LM79'
  Trying address 0x0290... Failed!
Probing for `Winbond W83781D'
  Trying address 0x0290... Failed!
Probing for `Winbond W83782D'
  Trying address 0x0290... Failed!
Probing for `Winbond W83627HF'
  Trying address 0x0290... Failed!
Probing for `Winbond W83627EHF'
  Trying address 0x0290... Failed!
Probing for `Winbond W83697HF'
  Trying address 0x0290... Failed!
Probing for `Silicon Integrated Systems SIS5595'
  Trying general detect... Failed!
Probing for `VIA Technologies VT82C686 Integrated Sensors'
  Trying general detect... Failed!
Probing for `VIA Technologies VT8231 Integrated Sensors'
  Trying general detect... Failed!
Probing for `ITE IT8712F'
  Trying address 0x0290... Success!
    (confidence 8, driver `it87')
Probing for `ITE IT8705F / SiS 950'
  Trying address 0x0290... Failed!
Probing for `IPMI BMC KCS'
  Trying address 0x0ca0... Failed!
Probing for `IPMI BMC SMIC'
  Trying address 0x0ca8... Failed!

Some Super I/O chips may also contain sensors. Super I/O probes are
typically a bit more dangerous, as we have to write to I/O ports to do
this. This is usually safe though.

Do you want to scan for Super I/O sensors? (YES/no):
Probing for `ITE 8702F Super IO Sensors'
  Failed! (0x8712)
Probing for `ITE 8705F Super IO Sensors'
  Failed! (0x8712)
Probing for `ITE 8712F Super IO Sensors'
  Success... found at address 0x0290
Probing for `Nat. Semi. PC87351 Super IO Fan Sensors'
  Failed! (skipping family)
Probing for `SMSC 47B27x Super IO Fan Sensors'
  Failed! (skipping family)
Probing for `VT1211 Super IO Sensors'
  Failed! (skipping family)
Probing for `Winbond W83627EHF Super IO Sensors'
  Failed! (skipping family)

Do you want to scan for secondary Super I/O sensors? (YES/no):
Probing for `ITE 8702F Super IO Sensors'
  Failed! (skipping family)
Probing for `Nat. Semi. PC87351 Super IO Fan Sensors'
  Failed! (skipping family)
Probing for `SMSC 47B27x Super IO Fan Sensors'
  Failed! (skipping family)
Probing for `VT1211 Super IO Sensors'
  Failed! (skipping family)
Probing for `Winbond W83627EHF Super IO Sensors'
  Failed! (skipping family)

 Now follows a summary of the probes I have just done.
 Just press ENTER to continue:

Driver `ds1621' (should be inserted):
  Detects correctly:
  * Bus `SMBus nForce2 adapter at 1c40'
    Busdriver `i2c-nforce2', I2C address 0x4e
    Chip `Dallas Semiconductor DS1621' (confidence: 3)

Driver `eeprom' (should be inserted):
  Detects correctly:
  * Bus `SMBus nForce2 adapter at 1c00'
    Busdriver `i2c-nforce2', I2C address 0x52
    Chip `SPD EEPROM' (confidence: 8)
  * Bus `SMBus nForce2 adapter at 1c00'
    Busdriver `i2c-nforce2', I2C address 0x53
    Chip `SPD EEPROM' (confidence: 8)
  * Bus `SMBus nForce2 adapter at 1c00'
    Busdriver `i2c-nforce2', I2C address 0x57
    Chip `SPD EEPROM' (confidence: 1)

Driver `it87' (should be inserted):
  Detects correctly:
  * ISA bus address 0x0290 (Busdriver `i2c-isa')
    Chip `ITE 8712F Super IO Sensors' (confidence: 9)


 I will now generate the commands needed to load the I2C modules.
 Sometimes, a chip is available both through the ISA bus and an I2C bus.
 ISA bus access is faster, but you need to load an additional driver module
 for it. If you have the choice, do you want to use the ISA bus or the
 I2C/SMBus (ISA/smbus)?

To make the sensors modules behave correctly, add these lines to
/etc/modprobe.conf:

#----cut here----
# I2C module options
alias char-major-89 i2c-dev
#----cut here----

To load everything that is needed, add this to some /etc/rc* file:

#----cut here----
# I2C adapter drivers
modprobe i2c-nforce2
modprobe i2c-isa
# I2C chip drivers
modprobe ds1621
modprobe eeprom
modprobe it87
# sleep 2 # optional
/usr/bin/sensors -s # recommended
#----cut here----

WARNING! If you have some things built into your kernel, the list above
will contain too many modules. Skip the appropriate ones! You really should
try these commands right now to make sure everything is working properly.
Monitoring programs won't work until it's done.

Do you want to generate /etc/sysconfig/lm_sensors? (YES/no):
Copy prog/init/lm_sensors.init to /etc/rc.d/init.d/lm_sensors
for initialization at boot time.
Comment 6 drago01 2006-01-14 04:22:34 UTC
but modprobing the it87 driver still reboots the system?
is there any param I can add so that it does not try to probe this "bad" adress?
Comment 7 Jean Delvare 2006-01-14 04:45:18 UTC
Did you try "modprobe it87 ignore=1,0x2e" as I suggested? That should do it.

You may also add the following line to /etc/modprobe.conf:
  options it87 ignore=1,0x2e
So the option will be automatically added on each subsequent it87 module load.
Comment 8 drago01 2006-01-15 04:41:50 UTC
thx this works.
Comment 9 Jean Delvare 2006-01-15 06:27:37 UTC
Created attachment 7030 [details]
Prevent system reboot on modprobe it87
Comment 10 Jean Delvare 2006-01-15 06:35:17 UTC
Created attachment 7031 [details]
Prevent system reboot on modprobe it87 (v2)

Once more without the typo...
Comment 11 Jean Delvare 2006-01-15 06:39:29 UTC
Please try this patch (v2) if possible. It should fix the reboot problem without
you having to pass the "ignore=1,0x2e" parameter to it87. If it works OK I'll
push it upstream.
Comment 12 drago01 2006-01-15 06:49:01 UTC
it does not build here:
make -C /lib/modules/2.6.15-1.1824_FC4/build/ SUBDIRS=$PWD modules
make: Entering directory `/usr/src/kernels/2.6.15-1.1824_FC4-x86_64'
  CC [M] 
/home/dragoran/Desktop/Downloads/linux-2.6.15.tar.bz2_FILES/linux-2.6.15/drivers/hwmon/it87.o
/home/dragoran/Desktop/Downloads/linux-2.6.15.tar.bz2_FILES/linux-2.6.15/drivers/hwmon/it87.c:
In function 'it87_detect':
/home/dragoran/Desktop/Downloads/linux-2.6.15.tar.bz2_FILES/linux-2.6.15/drivers/hwmon/it87.c:831:
error: 'client' undeclared (first use in this function)
/home/dragoran/Desktop/Downloads/linux-2.6.15.tar.bz2_FILES/linux-2.6.15/drivers/hwmon/it87.c:831:
error: (Each undeclared identifier is reported only once
/home/dragoran/Desktop/Downloads/linux-2.6.15.tar.bz2_FILES/linux-2.6.15/drivers/hwmon/it87.c:831:
error: for each function it appears in.)
make[1]: ***
[/home/dragoran/Desktop/Downloads/linux-2.6.15.tar.bz2_FILES/linux-2.6.15/drivers/hwmon/it87.o]
Error 1
make: ***
[_module_/home/dragoran/Desktop/Downloads/linux-2.6.15.tar.bz2_FILES/linux-2.6.15/drivers/hwmon]
Error 2
make: Leaving directory `/usr/src/kernels/2.6.15-1.1824_FC4-x86_64'
have applied the patch and done:
 make -C /lib/modules/2.6.15-1.1824_FC4/build/ SUBDIRS=$PWD modules
after enabling it87 in the Makefile
Comment 13 drago01 2006-01-15 06:51:02 UTC
dev_info(&client->dev,
should this be &new_client ?
Comment 14 Jean Delvare 2006-01-15 06:52:11 UTC
Created attachment 7032 [details]
Prevent system reboot on modprobe it87 (v3)

I had forgotten to acyually refresh the patch before uploading it again. This
one should work. Sorry for the noise :/
Comment 15 Jean Delvare 2006-01-15 06:55:14 UTC
BTW, I wonder what device is present at the I2C address 0x4e. It may be a
secondary hardware monitoring chip. Do you know if your motherboard has such a
feature? You may provide the output of "i2cdump 1 0x4e b" (after loading i2c-dev
if needed) for further analysis. sensors-detect thinks it is a Dallas DS1621 but
I doubt this is correct - that's an old and rare chip unlikely to be found on a
recent motherboard.
Comment 16 drago01 2006-01-15 07:05:29 UTC
fixed that typo by hand and it works (no reboot)
something weird is happening here:
i2cdetect 1
Error: Could not open file `/dev/i2c-1': No such device or address
i2cdetect -l
shows nothing
I don't know what kind of sensor is there but I the mobo is able to report the
dram voltage (which sensors does not display) maybe this sensor is for that?
Comment 17 Jean Delvare 2006-01-15 07:13:33 UTC
Remember you need to "modprobe i2c-dev" before i2cdetect or i2cdump will work.

I guess the dram voltage is present in the sensors output, but isn't properly
labelled. That's a common issue. libsensors comes with a default set of labels
which may not match your motherboard wirings, so you usually have to edit
/etc/sensors.conf to adjust the sensors output.

If not a secondary temperature sensor, the chip at 0x4e could be a jumper free
overclock controller. Check if your motherboard advertises such a feature.
Comment 18 drago01 2006-01-15 07:20:50 UTC
ok here is the output:
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-1, address 0x4e, mode byte
Continue? [Y/n] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 02 00 05 05 26 00 00 00 00 00 00 00 00 00 00 00    ?.??&...........
10: 00 00 fe 0f 00 00 00 00 00 00 00 00 00 00 00 00    ..??............
20: 05 05 00 00 00 00 00 00 83 12 12 28 00 00 00 00    ??......???(....
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

I am aware of the issues with sensors.conf (cpu and mb temps where swapped here
and I fixed them)
the dram voltage is 2.66V (in the bios) but the sensors output does not show any
voltage in this range.
looked at the docs and there is no "jumperfree overclocking sensor" listed. (the
ite one is)
here is the output of sensors:
it8712-isa-0290
Adapter: ISA adapter
VCore 1:   +1.46 V  (min =  +1.42 V, max =  +1.57 V)
VCore 2:   +1.18 V  (min =  +2.40 V, max =  +2.61 V)   ALARM
+3.3V:     +6.56 V  (min =  +3.14 V, max =  +3.46 V)   ALARM
+5V:       +5.05 V  (min =  +4.76 V, max =  +5.24 V)
+12V:     +11.84 V  (min = +11.39 V, max = +12.61 V)
-12V:     -15.95 V  (min = -12.63 V, max = -11.41 V)   ALARM
-5V:       -2.35 V  (min =  -5.26 V, max =  -4.77 V)   ALARM
Stdby:     +5.08 V  (min =  +4.76 V, max =  +5.24 V)
VBat:      +3.07 V
fan1:        0 RPM  (min =    0 RPM, div = 8)
fan2:        0 RPM  (min = 3013 RPM, div = 8)
fan3:     7031 RPM  (min = 3013 RPM, div = 8)
CPU Temp:    +36
Comment 19 Jean Delvare 2006-01-15 23:07:48 UTC
For the records, may you please attach the output of dmidecode?
Comment 20 drago01 2006-01-16 09:42:15 UTC
Created attachment 7041 [details]
dmidecode output
Comment 21 Jean Delvare 2006-02-05 01:48:39 UTC
The fix is in -mm since 2.6.16-rc1-mm2.
Comment 22 Jean Delvare 2006-02-14 06:19:27 UTC
Can you please provide the output of:
isadump 0x295 0x296
Comment 23 drago01 2006-02-14 07:03:23 UTC
here is it:
WARNING! Running this program can cause system crashes, data loss and worse!
I will probe address register 0x295 and data register 0x296.
Continue? [Y/n] y
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00: 13 12 62 00 ff ff 03 00 00 00 04 5b 07 53 54 17
10: ff 38 38 77 80 80 81 82 00 00 00 00 00 00 00 00
20: 5b 4a cd bc b9 5d af be bf 1a 1e 23 ec 38 38 38
30: 62 59 a3 96 d9 c4 c3 b1 c5 b2 00 00 00 00 c3 b1
40: 28 0f 2d 0f 2d 0f ff ff 2d ff ff ff ff ff ff ff
50: ff 31 3b 3b 3b ff 85 5d 90 6c ff 12 84 f8 08 88
60: 14 19 19 21 ba 7f ff ff 14 19 19 21 ba 7f ff ff
70: 14 19 19 21 ba 7f ff ff ff ff ff ff ff ff ff ff
80: 00 00 00 00 ff ff ff ff 40 40 ff ff ff ff ff ff
90: 7f 7f 7f 00 00 7f ff ff 7f 7f 7f 00 00 7f ff ff
a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Comment 24 Jean Delvare 2006-03-11 08:49:53 UTC
Fix merged in 2.6.16-rc3 and 2.6.15.5.
Comment 25 Jean Delvare 2008-05-07 04:55:23 UTC
An even better fix would be to plain disable the second SMBus channel on this motherboard, so that neither kernel drivers nor user-space tools (e.g. sensors-detect) can cause the system to reboot. I'll attach a patch doing this, please test it if you can.
Comment 26 Jean Delvare 2008-05-07 04:56:21 UTC
Created attachment 16058 [details]
i2c-nforce2: Disable the second SMBus channel on the DFI Lanparty NF4 Expert
Comment 27 drago01 2008-05-11 03:38:04 UTC
Hi,
Sorry for the delay .. I can apply the patch and test but what exactly should I test? The bug no longer happens because of the older fix.
Comment 28 Jean Delvare 2008-05-11 04:21:22 UTC
With the patch applied, you should see the message "Disabling SMB2 for safety reasons" in the kernel logs when you load the i2c-nforce2 module, and "i2cdetect -l" should only list one SMBus channel for the nForce2 chip.
Comment 29 drago01 2008-05-11 04:39:22 UTC
(In reply to comment #28)
> With the patch applied, you should see the message "Disabling SMB2 for safety
> reasons" in the kernel logs when you load the i2c-nforce2 module, and
> "i2cdetect -l" should only list one SMBus channel for the nForce2 chip.
> 

OK, will test it tomorrow and report the results.
Comment 30 drago01 2008-05-12 01:13:45 UTC
Tested it seems to work fine:
------------
i2c-adapter i2c-0: nForce2 SMBus adapter at 0x1c00
nForce2_smbus 0000:00:01.1: Disabling SMB2 for safety reasons.
-----------
And i2detect -l only shows one channel (2 without the patch applied)
Comment 31 Jean Delvare 2008-05-12 01:35:43 UTC
Great, thanks for testing. I'll push this patch in 2.6.26-rc3. Two safeties are better than one.
Comment 32 drago01 2008-05-12 01:53:33 UTC
OK, thanks for the fixes.
Comment 33 Adrian Bunk 2008-05-18 16:15:43 UTC
fixed by commit 08851d6eb4eeb0894f4d095dfdf8ab61c435ad57