Subject: Re: Sensors on IBM eServer 335/345? - msg#00382

Previous Message by Date:

Re: 2.6.10-mm2: it87 sensor driver stops CPU fan

Hi Nicolas, > > I would also appreciate a dump of the chip (isadump 0x295 0x296 unless > > it lives at some uncommon address) to confirm the guess. > > 0 1 2 3 4 5 6 7 8 9 a b c d e f > 00: 11 10 80 00 37 ff 00 37 ff 07 13 5b 00 51 40 ff > 10: fe fe ff 71 d7 fe 7f fe 00 00 ff ff ff ff ff ff Interesting. Your chip does seem to be configured (i.e. pwm polarity is high), so whatever your problem is, it is probably different from what Simone experienced. Your configuration is as follow: * PWM outputs active high. * PWM 2 and 3 in on/off mode, set to on. * PWM 1 in "smart guardian" mode, set to automatic PWM depending on temp3. I would like to know how temperature channels are used by your motherboard, and how fans are used as well. Which temperature and fan channels correspond to your CPU? What other temperature sensors and fans are present? The values dumped here make me believe that the PWM outputs were configured by the BIOS. Now maybe not the correct way, at least for you. > I guess the BIOS setting will simply be overwritten so changing the BIOS > should not affect subsequent use, no? Changing the BIOS configuration affects the initial register configuration, from which the it87 driver decides whether using PWM or reconfiguring the chip (changing polarity) is safe or not. This is why it might help. With the dump you provided, we now know that the (new) it87 driver will accept PWM operations even when your BIOS was left in "smart guardian" mode. I would like you to give a try to a recent version of the it87 driver (as found in 2.6.11-rc1-bk7 or 2.6.11-rc1-mm2). This will let us know which revision of the IT8712F you have (in case it matters), and will also let you experiment with manual PWM. If manual PWM works, then the problem is in the way temperature interacts with PWM in automatic mode. If manual PWM works the wrong way around (like it did for Simone) then it is a polarity issue (after all, maybe *you* need active low). If manual PWM half works (fan speed changes but not as much as it should) it might be a problem of picking the correct base frequency for PWM. So please let us know how manual PWM behaves, and I'll tell you what I think the problem is, and how I think it can be tinkered with (providing it can). In the meantime, you could contact Gigabyte and explain about the problem. They better learn about the problem and fix their BIOS is needed. Thanks, -- Jean Delvare

Next Message by Date:

Re: I2C support for IPMI

Mark M. Hoffman wrote: Hi Corey: * Corey Minyard <cminyard@xxxxxxxxxx> [2005-01-19 22:11:23 -0600]: Mark M. Hoffman wrote: Well, wait_event_interruptible_timeout() schedules, so at a quick glance this will not work for i2c-ibm_iic at least. But more generally... I think I got that one. If you look at the function in the patch, I made some changes to that. I'm sorry but I don't see it. All I see is that you modified the function iic_wait_for_tc() to not schedule, but only if it's in polling mode. The interrupt mode code is unchanged. Oops, I missed that. I think just adding a !i2c_spin_delay to the first if statement should do it. However, there's still a race where if you panic while in iic_wait_for_tc(), you wouldn't be able to send anything and the interface will be stuck. The same is true for all other bus drivers. If the code is in an msleep() when the panic occurs, the bus lock will be held and nothing else will be able to do anything. I started to rewrite i2c-i801 [1] to use interrupts rather than pure polling as it does now, so I'm interested to know: how can the panic-time operation work for bus drivers that need interrupts? What I have done in the IPMI driver is when you wait for an operation, if you are in a panic then call the interrupt handler continuously until the operation completes. Sort of like the network polling does. So e.g. i2c-ibm_iic would need similar changes too, right? Well, not exactly. The trouble is that the I2C interface is synchronous; it blocks until the message is sent. So there's no way for a user of the i2c code to do a "Send this message and poll until the operation is finished." That way any operations that were in progress would be finished and the operation in question could complete. I've never dealt with a synchronous interface in this manner. I'll have to study the code a little bit more. The trouble is that at panic time, wait_event_interruptuble_timeout() can never be made to "return" and clean things out. And you want the operations in progress to complete; I know of one case where you go into this mode and then return back to a normal running kernel. In the kernel coredump code it supports a "take a kernel dump and then keep going" operation. Scheduling is disabled during the coredump, but the coredump code has to keep kicking the watchdog, and if it's an IPMI watchdog on an SMBus then it has to go through I2C. IMHO, synchronous interfaces are a trap device driver writers fall into. They are simpler at first, but then you run into situations where things just won't work right. For instance, suppose some crazy hardware designer puts a reset register out on the I2C (assuming this hasn't already happened). With the current design of the I2C driver, you could get into a situation where at a panic you cannot reset the system. With an asyncronous interface, you could put setting the reset register into a xmit queue and poll the interface until the reset occurred. Anyway, looking at the current code, I don't think there's a way to make this work correctly. It looks to me that this will take a redesign of the interface between the I2C core code and the bus drivers. I'll have to think about it. -Corey

Previous Message by Thread:

Re: Sensors on IBM eServer 335/345?

Hi, However, sensors-detect still isn't finding any sensor chips on this system. Is there a giant table somewhere that lists motherboard/chip combinations so I can find the appropriate drivers for this system? Or any general guidelines to what IBM or Serverworks prefer to use with their systems/electronics? Could the sensor chips be proprietary? We don't have such a table. We support chips, not board or systems. You may search the mailing-list archives or the support tickets: http://secure.netroedge.com/~lm78/search.html But I don't remember seing this family of servers discussed. You may ask IBM directly, they are supposed to know what hardware is used in their server boards. The hardware could be proprietary. Or they might not be hardware monitoring stuff on these boards at all. What makes you believe there is? The long and the short: IBM hardware support tells me there is hardware monitoring in this machine, but that it is indeed proprietary, and they are not willing to release any specifications with regards to hardware monitoring chips. The proprietary hardware is meant to go with their proprietary monitoring software. Sorry about that - up until this email I was optimistic that though they'd have proprietary software, the hardware would be *somewhat* standard. D'oh. :) I know this machine has two Xeon processors, and Xeons have embedded temperature sensors, but have not had much luck trying to access them after inserting the xeontemp lmsensors module - just wondering if my old kernel could have anything to do with it. I don't think so. If the Xeon have thermal sensors, sensors-detect should have seen them, and the xeontemp driver as well. But I think I remember that not all Xeon CPUs have the thermal sensors. Since the motherboard in this machine has hardware sensors (and a fancy optional software package to go with it), My guess is that the Xeon chips also have temperature sensors. Is the access method of the Xeon temperature sensors such that IBM could have found a way to prevent third-party software (i.e. open source i2c/lmsensors) from retrieving this data? Or could there be a fairly easy way to access this data? How does lmsensors get this data from the Xeon chip? You can send us the full output of sensors-detect (after unloading all i2c chip drivers) and we'll tell you if something can be done. Here's my output of sensors-detect (that comes with lmsensors 2.9.0), if at all useful for answering the above question: =====cut here===== emmy3:~# /usr/local/sbin/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): YES Probing for PCI bus adapters... Use driver `i2c-piix4' for device 00:0f.0: ServerWorks CSB5 South Bridge Probe succesfully concluded. We will now try to load each adapter module in turn. Load `i2c-piix4' (say NO if built into your kernel)? (YES/no): YES Module loaded succesfully. 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): YES 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 PIIX4 adapter at 0440 Do you want to scan it? (YES/no/selectively): YES Client found at address 0x37 Client found at address 0x50 Probing for `SPD EEPROM'... Success! (confidence 8, driver `eeprom') Probing for `DDC monitor'... Failed! Probing for `Maxim MAX6900'... Failed! Client found at address 0x52 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): YES 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 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 IT8705F / IT8712F / 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): YES Probing for `ITE 8702F Super IO Sensors' Failed! (0xee19) Probing for `ITE 8705F Super IO Sensors' Failed! (0xee19) Probing for `ITE 8712F Super IO Sensors' Failed! (0xee19) Probing for `Nat. Semi. PC87351 Super IO Fan Sensors' Failed! (0xee) Probing for `Nat. Semi. PC87360 Super IO Fan Sensors' Failed! (0xee) Probing for `Nat. Semi. PC87363 Super IO Fan Sensors' Failed! (0xee) Probing for `Nat. Semi. PC87364 Super IO Fan Sensors' Failed! (0xee) Probing for `Nat. Semi. PC87365 Super IO Fan Sensors' Failed! (0xee) Probing for `Nat. Semi. PC87365 Super IO Voltage Sensors' Failed! (0xee) Probing for `Nat. Semi. PC87365 Super IO Thermal Sensors' Failed! (0xee) Probing for `Nat. Semi. PC87366 Super IO Fan Sensors' Failed! (0xee) Probing for `Nat. Semi. PC87366 Super IO Voltage Sensors' Failed! (0xee) Probing for `Nat. Semi. PC87366 Super IO Thermal Sensors' Failed! (0xee) Probing for `Nat. Semi. PC87372 Super IO Fan Sensors' Failed! (0xee) Probing for `Nat. Semi. PC87373 Super IO Fan Sensors' Failed! (0xee) Probing for `Nat. Semi. PC8739x Super IO' Failed! (0xee) Probing for `Nat. Semi. PC8741x Super IO' Success... (no hardware monitoring capabilities) Probing for `SMSC 47B27x Super IO Fan Sensors' Failed! (0xee) Probing for `SMSC 47M10x/13x Super IO Fan Sensors' Failed! (0xee) Probing for `SMSC 47M14x Super IO Fan Sensors' Failed! (0xee) Probing for `SMSC 47M15x/192 Super IO Fan Sensors' Failed! (0xee) Probing for `SMSC 47S42x Super IO Fan Sensors' Failed! (0xee) Probing for `SMSC 47S45x Super IO Fan Sensors' Failed! (0xee) Probing for `SMSC 47M172 Super IO' Failed! (0xee) Probing for `SMSC LPC47B397-NC Super IO' Failed! (0xee) Probing for `VT1211 Super IO Sensors' Failed! (0xee) Probing for `Winbond W83627HF Super IO Sensors' Failed! (0xee) Probing for `Winbond W83627THF Super IO Sensors' Failed! (0xee) Probing for `Winbond W83637HF Super IO Sensors' Failed! (0xee) Probing for `Winbond W83697HF Super IO Sensors' Failed! (0xee) Probing for `Winbond W83697SF/UF Super IO PWM' Failed! (0xee) Probing for `Winbond W83L517D Super IO' Failed! (0xee) Do you want to scan for secondary Super I/O sensors? (YES/no): YES 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) Now follows a summary of the probes I have just done. Just press ENTER to continue: Driver `eeprom' (should be inserted): Detects correctly: * Bus `SMBus PIIX4 adapter at 0440' (Non-I2C SMBus adapter) Busdriver `i2c-piix4', I2C address 0x50 Chip `SPD EEPROM' (confidence: 8) * Bus `SMBus PIIX4 adapter at 0440' (Non-I2C SMBus adapter) Busdriver `i2c-piix4', I2C address 0x52 Chip `SPD EEPROM' (confidence: 8) * Bus `SMBus PIIX4 adapter at 0440' (Non-I2C SMBus adapter) Busdriver `i2c-piix4', I2C address 0x57 Chip `SPD EEPROM' (confidence: 1) 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)? ISA To make the sensors modules behave correctly, add these lines to /etc/modules.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-piix4 # I2C chip drivers modprobe eeprom # sleep 2 # optional /usr/local/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): YES Copy prog/init/lm_sensors.init to /etc/rc.d/init.d/lm_sensors for initialization at boot time. emmy3:~# /usr/local/bin/sensors Can't access procfs/sysfs file Unable to find i2c bus information; For 2.6 kernels, make sure you have mounted sysfs and done 'modprobe i2c_sensor'! For older kernels, make sure you have done 'modprobe i2c-proc'! emmy3:~# modprobe i2c-proc emmy3:~# /usr/local/bin/sensors No sensors found! emmy3:~# =====cut here===== Also, here are the relevant messages from the syslog: =====cut here===== dmi_scan.o version 2.9.0 (20041228) dmi_scan.o: SM BIOS found i2c-core.o: i2c core module version 2.9.0 (20041228) i2c-piix4.o version 2.9.0 (20041228) Found ServerWorks CSB5 South Bridge device i2c-piix4.o: Unusual config register value i2c-piix4.o: Try using fix_hstcfg=1 if you experience problems i2c-dev.o: i2c /dev entries driver module version 2.9.0 (20041228) i2c-dev.o: Registered 'SMBus PIIX4 adapter at 0440' as minor 0 i2c-proc.o version 2.9.0 (20041228) =====cut here===== Regarding the unusual config register value, I removed the module and reinserted it with the suggested argument (fix_hstcfg=1). Syslog revealed: =====cut here===== Found ServerWorks CSB5 South Bridge device i2c-piix4.o: Working around buggy BIOS (I2C) i2c-dev.o: Registered 'SMBus PIIX4 adapter at 0440' as minor 0 =====cut here===== However, when I ran sensors-detect again, my machine hung. I displayed the syslog, so you can be sure I used the correct versions of all the modules (2.9.0). [ Incidently, I have noticed that old i2c and lmsensors drivers allow old themselves to load on new i2c drivers. I've rebooted since that case, of course, but is there ever a case where a user would want mismatched versions of i2c/lmsensors drivers? It just seems to me that bad things could happen if that were the case...I know I've done that accidently and its caused erroneous driver behavior with bttv and i2c on a separate machine. Should there be a check to make sure i2c/lmsensors drivers aren't being accidently mismatched? ] I did notice that the above sensors-detect output finds a chip "Nat. Semi. PC8741x Super IO", but does not find hardware monitoring capabilities on it. Maybe this is IBM's proprietary monitoring chip. Here's an output of one of the CPUs in /proc/cpuinfo if at all useful: =====cut here===== emmy3:~# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Xeon(TM) CPU 3.20GHz stepping : 5 cpu MHz : 3189.539 cache size : 512 KB physical id : 0 siblings : 2 runqueue : 0 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm bogomips : 6370.09 ... emmy3:~# =====cut here===== And, if it makes a difference, I am running on kernel 2.4.21-27 (RedHat Enterprise Linux 3). Thanks for your help, - Armen

Next Message by Thread:

Mail delivery failure

****** Message from InterScan E-Mail VirusWall NT ****** Sent >>> . Received <<< 554 Can not send e-mail: Can not send body: Can not finish data state: 'Error: too many hops' Could not deliver mail to francois.barre@xxxxxxxxxxx and users in the same domain. ***************** End of message *************** --- Begin Message --- Hi, On Tue, Jan 18, 2005 at 05:10:50PM +0100, Jean Delvare wrote: > > I've set up a draft bugzilla on http://bugzilla.lm-sensors.org/ for > > playing with. Don't enter any serious bugs as the bugs will be wiped > > before going in production :) > 1* We would need a list of versions of lm_sensors that existed to be > picked from. Yes, I had forgotten to place some versions to play with. I added some to "bus drivers" as a demo. > 2* I would replace Platform with Architecture, and list there all > architectures supposedly supported by lm_sensors (+ "other" just in > case). Which are these? i386 and x86_64? > 3* I don't feel a need for a Priority setting. Severity should be > sufficient. I think this cannot be dumbed. It is also a bit different. A blocker severity in a development version could be of lower priority than a major serverity of security issues in a released version. Or you could move an enhancement at higher priority than a trivial fix etc. > 4* OS can go, as we only support Linux anyway. What would be more > interesting would be a version of Linux, which would be a free input > (because there are that many, and also because people will often report > non-vanilla versions). > > Maybe we can keep the OS to make a difference between the Linux trees > (2.4, 2.6, and older ones for recovered tickets). This could help people > having a problem which they think only affect a given tree (think procfs > or sysfs issues). That's a good idea. bugzilla only supports one-dimensional versioning, e.g. it would not be able to really deal with lm_sensors x Linux version tuples. By abusing the OS field, we can effectivly achive that. :) > 5* Not sure why the reporter would be left a choice for the Initial > State. What is this "Unconfirmed" state for? A new report is, err, > New, period. Unconfirmed means it may be not a bug at all. New means it is a bug but has not yet been assigned to anyone. You can drop the unconfirmed, I currently set it up for having to vote (with one vote) to make a bug new. Personally I don't think voting in general makes sense, but I left it for playing. > > I haven't yet renamed products to categories as one of the things to > > test is whether this hierarchical setup is OK or not. > > Looks OK to me except for the lack of user-space category. OK, added. But not components, yet, so it does not show up. Try adding some to see the mechanics of it (You are and admin now). > > I also allowed for flags, votes, milestone, QA contact and status > > whiteboard fields. Some of them are probably too much (or not) for > > lm_sensors, but I activated them for demonstration purposes. Anything > > that does not serve lm_sensors' needs will be dropped before going up. > > I think I see what milestones and votes are for. But what are flags? flags can be used for example to ask for a review before commiting something. check out the example on http://www.bugzilla.org/docs/2.18/html/flags-overview.html > Is QA Contact something different than the default assignee for this > category? If yes, I don't think we need this. It's the supervisor of the poor assignee, I also don't like him ;) > > Which brings up the question: Who is the "initial owner" of each of > > the catgories above? I tend to think, that we need a dummy bugzilla > > account that is a catch-all, at least for the beginning. Perhaps > > abusing lm-sensors-devel@xxxxxxxxxxxxxx, so that all lm_sensors > > developers get to see bugzilla mail on orphaned bugs. > > Each non-core driver would have a specific owner (current maintainer) > providing this person actually has a bugzilla account. For the rest of > the items, we can attribute them on a voluntarism basis, and using the > mailing-list for the remaining items and core items seems fine. And if > it doesn't please us in the long run we can change then. > > > For testing the administrative part send me your created login account > > in PM and I will activate administrative access for it (like adding > > new components, new keywords, new flags, editing users etc). > > Please do for me: (my e-mail address - don't think this is a really > private information so I don't think a PM was needed at all ;)) Done so. -- Axel.Thimm at ATrpms.net default.txt Description: PGP signature --- End Message ---