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
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.
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
Created attachment 7023 [details] kernel config
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.
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.
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?
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.
thx this works.
Created attachment 7030 [details] Prevent system reboot on modprobe it87
Created attachment 7031 [details] Prevent system reboot on modprobe it87 (v2) Once more without the typo...
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.
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
dev_info(&client->dev, should this be &new_client ?
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 :/
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.
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?
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.
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
For the records, may you please attach the output of dmidecode?
Created attachment 7041 [details] dmidecode output
The fix is in -mm since 2.6.16-rc1-mm2.
Can you please provide the output of: isadump 0x295 0x296
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
Fix merged in 2.6.16-rc3 and 2.6.15.5.
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.
Created attachment 16058 [details] i2c-nforce2: Disable the second SMBus channel on the DFI Lanparty NF4 Expert
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.
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.
(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.
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)
Great, thanks for testing. I'll push this patch in 2.6.26-rc3. Two safeties are better than one.
OK, thanks for the fixes.
fixed by commit 08851d6eb4eeb0894f4d095dfdf8ab61c435ad57