w83627hf in ubuntu gutsy (2.6.22-14) and current hardy (2.6.24-16) troubles on AOpen i915GMm-HFS

[ticket]

Hi! Since some recent upgrade I have trouble watching dvb-s streams from an saa7146-based PCI card on an AOpen i915GMm-HFS if the module w83627hf is loaded for fancontrol. The dvb streams unregularly contain glitches. This is also true if the fancontrol daemon is not run or just the hwmon_vid module is loaded.

When the module w83627hf is not loaded, the streams are fine.

[ticket]

Sorry - the error does not occur if just the hwmon_vid module is loaded.

Loading w83627hf triggers the errors.

[khali]

Your report is not very clear about this: what happens if the w83627hf driver is loaded but the fancontrol daemon is not started? Is DVB-S working or is it broken?

You mention a "recent update", what did you update exactly?

If you load the w83627hf driver and then unload it, is DVB-S working OK again, or is it still broken?

Does fancontrol itself work? What does your fancontrol configuration file contain?

How much time does "sensors" take to return?

Which version of lm-sensors are you using?

[ticket]

Hi, some more information:

First of all: With my original gutsy system (unfortunately, I cannot fully recover its status, see below), DVB-S was working with the fancontrol daemon without any problems, so I had my system in a working state... as for your questions:

(i) If the w83627hf driver is loaded and the fancontrol daemon is not started, the dvb-s streams are still broken (contain errors).

(ii) To be more precise regarding my recent update: I upgraded my gutsy system to hardy two weeks ago (including its kernel 2.6.24-16), and after finishing system configuration (including setting up fancontrol) I noticed the errors in the stream. They also remained if I switch down almost all services (including the fancontrol daemon) and just record the streams via szap -r for tuning and cat /dev/dvb/adapter0/dvr0 to file - I was not checking loaded modules then, w83267hf was still loaded. So I thought that the error was with the 2.6.24-16 kernel (without pinpointing it to the w83627hf driver yet).

After downgrading back to gutsy (with its kernel 2.6.22-14) and doing an "apt-get upgrade" to include the latest bugfixes, I noticed that after finishing setting up my system, the errors were also present there! Then, I found the w83627hf driver to be the cause. But as the errors were not present in my original gutsy system that I had three weeks ago, either the drivers must have changed in the meantime, or I was using a different kernel module (or something else was different? unfortunately I have not saved /etc/modules of my original system and was using pwmconfig for finding them "from scratch" after up- and downgrading - but this is what I did in the first place as well...)

(iii) If I unload the 283627hf driver, DVB-S does not contain errors anymore (I will do a longer check tonight and post here in case this is wrong, but I am pretty sure as I checked this yesterday)

(iv) Fancontrol itself works (but again, the errors also occur if fancontrol is not running and only the module is loaded). The configuration file is here:

INTERVAL=10 FCTEMPS=hwmon0/device/pwm1=hwmon0/device/temp1_input hwmon0/device/pwm2=hwmon0/device/temp2_input FCFANS=hwmon0/device/pwm1=hwmon0/device/fan1_input hwmon0/device/pwm2=hwmon0/device/fan2_input MINTEMP=hwmon0/device/pwm1=35 hwmon0/device/pwm2=40 MAXTEMP=hwmon0/device/pwm1=45 hwmon0/device/pwm2=60 MINSTART=hwmon0/device/pwm1=255 hwmon0/device/pwm2=250 MINSTOP=hwmon0/device/pwm1=20 hwmon0/device/pwm2=20

(v) sensors immediately returns with this information: w83627thf-isa-0290 Adapter: ISA adapter VCore: +0.99 V (min = +0.70 V, max = +1.87 V) +12V: +11.98 V (min = +3.89 V, max = +4.38 V) ALARM +3.3V: +3.20 V (min = +0.05 V, max = +3.36 V) +5V: +4.93 V (min = +0.21 V, max = +1.81 V) ALARM -12V: -5.78 V (min = +1.95 V, max = -4.38 V) ALARM V5SB: +4.97 V (min = +1.56 V, max = +0.65 V) ALARM VBat: +3.09 V (min = +2.59 V, max = +1.58 V) ALARM fan1: 1205 RPM (min = 664 RPM, div = 8) CPU Fan: 2083 RPM (min = 664 RPM, div = 8) fan3: 0 RPM (min = 664 RPM, div = 8) ALARM M/B Temp: +32°C (high = +2°C, hyst = +0°C) sensor = diode ALARM CPU Temp: +47.5°C (high = +80°C, hyst = +75°C) sensor = diode (beep) temp3: -48.0°C (high = +80°C, hyst = +75°C) sensor = diode alarms: beep_enable:

Sound alarm disabled

If this is interesting to you: The modules that are loaded if my system is running (including fancontrol) are the following (I removed i2c-i802 from /etc/modules, pwmconfig reported this, but it does not seem to be needed):

Module Size Used by w83627hf 26260 0 hwmon_vid 4352 1 w83627hf squashfs 48132 1 loop 19076 2 nls_cp437 6784 1 battery 11012 0 ac 6148 0 thermal 14344 0 fan 5764 0 button 8976 0 dvb_ttpci 104136 0 lirc_imon 17028 2 lirc_dev 15860 1 lirc_imon isofs 36412 1 udf 87204 0 cpufreq_ondemand 9612 1 acpi_cpufreq 10568 0 freq_table 5792 2 cpufreq_ondemand,acpi_cpufreq autofs4 23044 1 sbs 19592 0 container 5504 0 dock 10656 0 video 18060 0 ipv6 273892 20 af_packet 24840 2 sbp2 24072 0 parport_pc 37412 0 lp 12580 0 parport 37448 2 parport_pc,lp tua6100 4224 1 snd_hda_intel 263712 0 snd_pcm_oss 44672 0 snd_mixer_oss 17664 1 snd_pcm_oss nvidia 6221648 56 stv0299 11400 2 snd_pcm 80388 2 snd_hda_intel,snd_pcm_oss snd_seq_dummy 4740 0 snd_seq_oss 33152 0 snd_seq_midi 9600 0 snd_rawmidi 25728 1 snd_seq_midi pcspkr 4224 0 budget_av 21120 13 dvb_pll 15492 1 budget_av saa7146_vv 50688 2 dvb_ttpci,budget_av video_buf 26244 1 saa7146_vv videodev 29312 1 saa7146_vv v4l2_common 18432 2 saa7146_vv,videodev v4l1_compat 15364 2 saa7146_vv,videodev budget_core 12420 1 budget_av dvb_core 82216 4 dvb_ttpci,stv0299,budget_av,budget_core iTCO_wdt 11940 0 iTCO_vendor_support 4868 1 iTCO_wdt saa7146 20360 4 dvb_ttpci,budget_av,saa7146_vv,budget_core snd_seq_midi_event 8448 2 snd_seq_oss,snd_seq_midi ttpci_eeprom 3456 2 dvb_ttpci,budget_core sky2 46852 0 snd_seq 53232 6 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event snd_timer 24324 2 snd_pcm,snd_seq snd_seq_device 9228 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_rawmidi,snd_seq i2c_core 26112 8 dvb_ttpci,tua6100,nvidia,stv0299,budget_av,dvb_pll,budget_core,ttpci_eeprom snd 54660 9 snd_hda_intel,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_seq_oss,snd_rawmidi,snd_seq,snd_timer,snd_seq_device soundcore 8800 1 snd snd_page_alloc 11400 2 snd_hda_intel,snd_pcm intel_agp 25620 0 agpgart 35016 2 nvidia,intel_agp shpchp 34580 0 pci_hotplug 32704 1 shpchp evdev 11136 2 ext3 133896 6 jbd 60456 1 ext3 mbcache 9732 1 ext3 sg 36764 0 usb_storage 73024 0 ide_core 116804 1 usb_storage sr_mod 17828 1 cdrom 37536 1 sr_mod sd_mod 30336 8 libusual 18448 1 usb_storage ata_piix 17540 8 floppy 60004 0 ohci1394 36528 0 ieee1394 96312 2 sbp2,ohci1394 ata_generic 8452 0 libata 125168 2 ata_piix,ata_generic scsi_mod 147084 6 sbp2,sg,usb_storage,sr_mod,sd_mod,libata ehci_hcd 36492 0 uhci_hcd 26640 0 usbcore 138632 7 lirc_imon,usb_storage,libusual,ehci_hcd,uhci_hcd processor 32072 2 thermal,acpi_cpufreq fuse 47124 1 apparmor 40728 0 commoncap 8320 1 apparmor

(vi) I am using lm-sensors version 2.10.4-1ubuntu1

If there is more I can find out, please let me know.

Thanks!

[khali]

The w83627hf driver doesn't do anything by itself while loaded. Its code is running only when someone accesses its sysfs interface. And unloading the w83627hf driver is a no-op from hardware point of view. As you say that unloading the w83627hf driver does solve the problem, this leads me to the conclusion that something on your system is accessing the w83627hf sysfs interface on a regular basis. This is however somewhat contradictory with your statement that the problem still occurs "if you switch down almost all services".

Do you have some desktop applet which monitors your system (ksysguard, gkrellm, gnome or xfce4 sensors applet...)? You must find out what application is making use of the w83627hf sysfs interface (directly or through libsensors). A quick test to start with would be to reproduce the problem from the console, with X not running. If things work fine without X, then most likely some X applet is triggering the problem.

[ticket]

First, regarding your hint to try without X: Yes, this is what I did as I also had in mind that maybe the nvidia graphics driver is doing illegal stuff. So there were no obvious daemons (checked with ps -aux and can redo this if it is necessary).

Now, I just did some further testing in both setups (gutsy and hardy, boot without fancontrol and loading related modules) and this is what I figured out (my first observations indeed were not 100% correct):

1. modprobe w83627hf: Fine, no errors (checked this for 15 minutes)
2. /etc/init.d/fancontrol start: Errors occur
3. /etc/init.d/fancontrol stop: Errors remain
4. modprobe -r w83627hf: Errors stop

If done again: Same behavior, on both systems - and, yes, I am sure about step (3).

Step (4) is still surprising to me (also regarding your statement that removing the module is a no-up). I understand your reasoning that something else might be accessing sysfs on a regular basis, but why do the errors not start after step (1)? Is sysfs not set up when loading the module but only if the fancontrol daemon starts (how can I find out)? If this is indeed the case, then it would be great if you could give me a hint on how to find out using libsensors.... but if the module itself is already setting up sysfs, then I am lost here... anyhow: How can I use libsensors in order to find out what application is making use of the w83627hf sysfs interface?

[khali]

Thanks for the good problem description in comment #5, it should help narrowing the root cause.

First of all, please attach the /etc/init.d/fancontrol script. Each distribution has its own script and I'd like to see what exactly yours is doing on "start" and "stop". Also, please check that fancontrol is _really_ stopped after step 3 (/etc/init.d/fancontrol stop). If for some reason the fancontrol init script failed to stop the fancontrol daemon, this could explain why the errors remain at this point.

To answer your question about sysfs: the w83627hf driver creates the sysfs interface. libsensors is used by applications to access this sysfs interface, although it is also possible to access it directly (like the fancontrol daemon does.)

It isn't easy to find out who is accessing a given sysfs file. However it is possible to find out if an application is making use of libsensors, using the lsof tool:

$ lsof | grep libsensors
ksysguard 4318      khali  mem       REG                3,6   344136     816418 /usr/lib64/libsensors.so.3.1.4

That being said, your last experiments really suggest that fancontrol itself is causing the problem, rather than another mysterious application.

In order to prove that fancontrol is responsible for your problem, I suggest playing with the INTERVAL value in /etc/fancontrol. It defaults to 10 seconds. I am curious if the DVB-S stream errors you have are separated by a multiple of 10 seconds each time? You could try setting INTERVAL to 3, and see if the errors are more frequent. Then try 60 and see if the errors are less frequent. Of course you must restart the fancontrol daemon each time.

[ticket]

/etc/init.d/fancontrol

[ticket]

/lib/lsb/init-functions

[ticket]

/usr/sbin/fancontrol

[ticket]

Thanks for your suggestions. The fancontrol script may indeed be the cause; this is probably the only remaining file that is different from my original working setup (as unfortunately I did not save it. The new one comes from a debian package, see below, but the old one was from a different site that I don't remember). I attached the fancontrol-script, the daemon and the one providing init functions.

I played with the interval, and I tend to agree that the errors occur more frequently. However, they are random and also seem to depend on something else, so sometime the stream is fine for a minute even with an interval of 1 second.

And you are right - when calling /etc/init.d/fancontrol stop, the process is still active! Once unloading w83627hf, it finally disappears. This is good news.

I just checked on the web: Whereas Hardy includes lm-sensors 1:3.0.0-4ubuntu1, gutsy includes 2.10.4-1ubuntu1 (as I reported above), and it did not change for several months... so, it seems that regardless of /usr/sbin/fancontrol being in 3.0.0 or 2.10.4, it does not work with the "new" daemon script /etc/init.d/fancontrol that I now use and which is coming from the Debian package 3.0.1-2 (see  http://packages.debian.org/changelogs/pool/main/l/lm-sensors-3/lm-sensors-3_3.0.1-2/changelog). Is this something you can figure out by looking at the scripts or do you know of a different /etc/init.d/fancontrol that I might try?

[khali]

Could you please try running /usr/sbin/fancontrol directly instead of calling "/etc/init.d/fancontrol start"? I wonder if your DVB-S stream will still contain errors or not. If it no longer contains errors then the problem is definitely with this new /etc/init.d/fancontrol script you got from Debian, or with the way it integrates in your system.

Out of curiosity, is there any daemon involved in your DVB-S task?

[ticket]

First of all: My problem seems to be solved.

I ran /usr/sbin/fancontrol directly, and the stream still contains errors, so the init-script is unlikely to be the cause. Therefore, as everything worked fine in my original gutsy system, I ran pwm-config to generate /etc/fancontrol again - since it was really the only remaining file which I generated from scratch after upgrading.

Interestingly, the file was different - not only because I typed in some different numbers at which the fans stop and start (MINSTART, MINSTOP), but in my previous file (causing the errors), two lines were missing:

MINPWM=hwmon0/device/pwm1=120 hwmon0/device/pwm2=0
MAXPWM=hwmon0/device/pwm1=195 hwmon0/device/pwm2=195

I don't know the reason for it - maybe I did something wrong when creating the corrupt one? What does fancontrol do if the lines are missing? As a suggestion: It would be great if there would be an error message in that case and fancontrol would quit with an error - as the user will notice that something went wrong.

Regarding your question at the end: As far as I know, the bunch of dvb-drivers set up a dvb-subsystem that contain devices /dev/dvb/adapter0/... for communication with the card, similar to what I expect the sysfs to be. Low-level DVB-S recording can be done with a tuning application (szap) running in background and keeping data to be available at /dev/dvb/adapter0/dvr0. This can be recorded with (cat /dev... >recording.mpg). So generally, there is no daemon involved. I noticed that there are two kernel threads running (kdvb-ca), they seem to monitor the decryption card slot (my cards seem to support it even though I do not have an expansion card for this).

Anyway, thanks a lot for pointing me into the right direction! Now I can enjoy watchinhg TV again :-)

[khali]

The MINPWM and MAXPWM settings were introduced in lm-sensors 2.10.4. Before that, the fancontrol script was always using 0 and 255 for min and max PWM values, respectively. In later versions, the MINPWM and MAXPWM settings are optional, and 0 and 255 are still used by default when the configuration file doesn't provide them. So your previous configuration file was valid, which is why fancontrol did not complain.

I'm a bit confused by your previous comment. Are you saying that changing the fancontrol configuration file solved your DVB-S problems? That would be hard to believe and explain.

[ticket]

In a way, I am sorry to disappoint you, but indeed the different fancontrol configuration file solved the DVB-S problem[[BR]]

I replaced it with the old version and restarted the daemon, and the errors occurred as before. Then, I moved to the new configuration file again (even with INTERVAL=1), and DVB-S was fine. I'm not kidding! I will attach the new configuration file after this comment so that you can compare them.

If there is anything that you would like me to test, I would be happy to serve as a guinea pig.

[ticket]

/etc/fancontrol (works)

[ticket]

Some more info: I stepwise adjusted the working fancontrol configuration file to the one producing errors and noticed that indeed the missing MINPWM and MAXPWM were not the reason. In fact both MINSTART and MINSTOP have to be changed in order to reintroduce the errors. Changing only one of them does not do the trick - I do not have an explanation for this...

[khali]

I think I have an idea of what's going on. I now remember being told that tuners are very sensitive to electrical noise. Fan speed control does generate electrical noise, so maybe the problem isn't with the fancontrol daemon itself but with some of the fan speeds. I.e. it could be a hardware problem rather than software problem.

Your new configuration file restricts the fan speeds that fancontrol can use (thanks to the new MINPWM and MAXPWM settings.) Maybe the speeds that were causing the DVB-S problems are outside of this speed range and that would explain why DVB-S works fine now.

Out of curiosity, how far from your fans is your DVB-S adapter? Just moving it to another PCI slot might work around the electrical noise problem (if that's really what is happening here.)

If I am correct, you should be able to reproduce the problem without fancontrol. Stop fancontrol, then set the fan speeds manually:

cd /sys/class/hwmon/hwmon0/device
echo 240 > pwm1
echo 224 > pwm1
echo 208 > pwm1
...
echo 32 > pwm1
echo 16 > pwm1
echo 240 > pwm1 # Set to full speed again

The W83627THF uses a 4-bit DAC for fan speed control so you can use steps of 16 as shown above. Test DVB-S after each speed change. I suspect that some of the pwm1 values will cause the DVB-S problems. If not, try again with pwm2. Let's just hope that it doesn't take a specific combination of pwm1 and pwm2 to cause the problem.

Keep in mind that setting pwm1 or pwm2 to 0 will (most probably) stop the corresponding fan, so make sure that your other fan is spinning at full speed, and/or open the case if you can. Low, non-zero values might stop the fan as well, so keep an eye on your fans. You probably don't want to stop your CPU fan so don't set pwm2 too low, unless you have already tried everything else.

Oh, and when you're done with the tests, set INTERVAL to a somewhat higher value again ;) 1 second is overkill.

[ticket]

I followed your suggestions with

for((i=240;i>0;i=i-16)); do echo $i >pwm1; read -p "Set to $i. Press any key to continue."; done

and did not experience any problems. Also, I am not sure whether your assumption really is the cause. My DVB-S cards have a can tuner, i.e. the tuner sits in a small metal box which should protect it from noise. The DVB-S cable is fixed with a metal screw, so the chance for electrical noise is also low there.

The distance from the main fan to the DVB-S card is about 6 cm, and there is the graphics card in between...

Finally, the case fan (pwm1) is not running most of the time, but increasing the interval to 1 in /etc/fancontrol (the one causing errors) seem to increase the error rate, even though its speed does not change every second. I will have a look at the CPU fan pwm2 on the weekend, but it is even further away from the DVB cards. Also, I will try to run fancontrol on only one of the two fans to further narrow down the problem.

[khali]

Your comment #12 provides an interesting hint which I think is worth investigating. MINSTOP says from how fast the fan will drop to stop. MINSTART says how fast the fan will spin when it starts again. So maybe your problems are related to one of the fans starting and/or stopping too abruptly? The previous manual test didn't cover this. One strange thing still is that both settings are essentially unrelated, while you say that only the combination of both triggers the problem.

I still would like you to do the basic test with pwm2, just in case. Also, your idea to test fancontrol with pwm1 and pwm2 separately is a very good one, please do that.

[khali]

Any news on this? Did you run additional tests?

[ticket]

Just checked back today - actually, I did not run any additional tests as the setup works now for me and I did not find the time... also, it seems that (i) if this problem occurs at other installations, it seems to be solvable by just using different parameters and (ii) I have been the only one suffering from this problem. So I wonder if the tests are worth the effort as basically there is not practical problem anymore.<p>

If you convince me to invest some more time, I will run some more tests, but as I think would be really a minor issue for only very few people, I am also happy with the current state. Let me know...

[khali]

As you wish, I'm not insisting whatsoever, I have no idea what is going on anyway. I'm closing this as worksforme, feel free to reopen if you gather more information and conclude that something needs fixing on our end. Everybody else, please add a comment if you hit the same problem.