flex scanner jammed problem

flex scanner jammed problem

[Emperor]

Hi everybody,

I just installed lm_sensors via synaptic. I could set up my sensors. But
since I did that the KDE process window does not work any more,
ksysguardd and ksensors
gave me "flex scanner jammed". 

I put the output to your ticket system.

And I got another question! is there plan in lm_sensors to support writing to fan values, too? the w83627hf chip I have supports that.

So there could be a tool which controls the fan speed in relation with temperature, cpu load...

Is there any infos about that, another project? or a tool?

thx,

nils

flex scanner jammed problem

[Emperor]

Am Don, 2003-09-25 um 19.44 schrieb Jean Delvare:
> > > I admit I could have guess that (syn-apt-ic after all). But since I
> > > don't use apt anyway...
> > 
> > hey you should ;) great thing! easy to manage... simply search for
> > package lm_sensors and click on install, and soon your jammed your
> > flex scanner ;)
> 
> I use Slackware. Ease to manage too ;) OK, OK, I'll give a try to Debian
> someday.

no I'm running redhat, you can use apt on any rpm platform.

> 
> > > Your vid reading could be wrong, try changing vrm in the config
> > > file.
> > 
> > I did, now the values are right:
> > 
> > w83627hf-isa-0290
> > Adapter: ISA adapter
> > Algorithm: ISA algorithm
> > VCore 1:   +1.52 V  (min =  +1.44 V, max =  +1.60 V)
> 
> Yup, that one is OK.
> 
> > VCore 2:   +1.69 V  (min =  +1.44 V, max =  +1.60 V)
> 
> Is this value changing? If you have a single-plan CPU, this value
> doesn't make sense and you should add an "ignore in1" statement to you
> config file.
> 
> > fan1:     2045 RPM  (min = 1500 RPM, div = 4)
> > fan2:     1599 RPM  (min = 1500 RPM, div = 4)
> > fan3:     1339 RPM  (min = 1500 RPM, div = 4)
> 
> Your fans are running really low. A least, I guess your computer is
> really quiet :)
> 

yes it is. fan1 is a zalman and the other are papsts.

> > temp3:     +71.0C  (limit =  +60C, hysteresis =  +50C) sensor > > thermistor   ALARM
> 
> That's quite high, maybe you should invest in higher-speed fans.
> 

I thin 70 ~71 for cpu core is normal for a p4. I read this in their
spec. I tried to have this value below 70 C, but it simply won't go,
also with running my fans at higher speed. the cpu temp is around 45 C.

> > > > Adapter: saa7134[0]
> > > > Algorithm: saa7134
> > > 
> > > What's that thing?
> > 
> > it's my Terratec Cinergy 400 TV tuner card. I kicked it from the
> > lm_sensors file. didn't change anything.
> 
> The sensors program doesn't know a thing about it, so I wonder why it is
> showing there. Will take a look someday.
> 
> > > What if you plain delete the config file?
> > 
> > Then ksensors and ksysguard work! So they use the same config file...
> 
> Good thing to know. Then, my analysis is that you have two different
> versions of libsensors on your disk. One old for ksensors/ksysguard, and
> one new for sensors. Running ldd on these binaries should confirm that.
> In that case, you should use a configuration file that work for both
> (which means,: that work for the old library, since the new library is
> already OK). To do so, either strip your current file so that it only
> contains the w83627hf-* section (you just don't care about the others),
> or get etc/sensors.conf.eg from lm_sensors-2.7.0 or older, until it's
> OK.
> 

aha aha... I could also look for the files and try to delete the old
version, too, couldn't I?

> > > > Ok, in the meantime, I'm running varyfan very succesfully... PWM
> > > > works nice.
> > > 
> > > I did not know about that program, thanks for the information. I am
> > > going to add a link on our useful addresses page. I wonder if it
> > > offers something the programs included in our package don't.
> > 
> > I didn't try them out, you can specify temperatures, fan speed,
> > slowdown speed... it was right what I needed.
> 
> Would you have some time to give them a try and tell us how they behave
> compared with varyfan? I'd appreciate that.

I'll give a try.

> 
> Thanks.

flex scanner jammed problem

[Emperor]

Thank you!

with your help I got it!!

I first uninstalled lm_sensors270... which had deps to kdebase... no
matter ;)

And then uninstalled lm_sensors 2.8.0... 

deleted all sensors executables (yes there was a 2.6.5 one... what a
mess)

And reinstall 2.8.0.

Then reinstall ksensors...

and all works now!

oh and yes I had to clean the sensors.conf file.

Thank you for all your help!

flex scanner jammed problem

[Jean Delvare]

> I just installed lm_sensors via synaptic.

What is synaptic?

> I could set up my sensors.
> But since I did that the KDE process window does not work any more,
> ksysguardd and ksensors gave me "flex scanner jammed".

Which means that sensors itself doesn't work. Am I right?

This is a known problem, which has two possible solutions:

1* Fix your /etc/sensors.conf file. Copy the default etc/sensors.conf.eg
file that match the version you're using, and it should be OK.

2* If it doesn't work, update to 2.8.0 or CVS, we fixed a bug in the
parser some weeks ago.


> And I got another question! is there plan in lm_sensors to support
> writing to fan values, too? the w83627hf chip I have supports that.

"Writing to fan values" makes no sense ;) You already should be able to
write to the min settings. As for the speed control, it is known as PWM.
It *is* supported by our w83781d and w83627hf drivers (one of which you
must be using), although it is known not to work properly for everyone.
See the prog/pwm in our package, where you'll find the fancontrol and
pwmprogram. These are the ones you need in order to have PWM working.
Give it a try and let us know how it works for you.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

flex scanner jammed problem

[Emperor]

Am Mit, 2003-09-24 um 20.11 schrieb Jean Delvare:

> I admit I could have guess that (syn-apt-ic after all). But since I
> don't use apt anyway...

hey you should ;) great thing! easy to manage... simply search for
package lm_sensors and click on install, and soon your jammed your flex
scanner ;)

> 
> > w83627hf-isa-0290
> > Adapter: ISA adapter
> > Algorithm: ISA algorithm
> > VCore 1:   +1.50 V  (min =  +1.32 V, max =  +1.47 V)       ALARM
> > (...)
> > vid:      +1.400 V
> 
> Your vid reading could be wrong, try changing vrm in the config file.
> 

I did, now the values are right:

eeprom-i2c-0-50
Adapter: SMBus I801 adapter at 5000
Algorithm: Non-I2C SMBus adapter
Memory type:            DDR SDRAM DIMM SPD
Memory size (MB):       512

eeprom-i2c-0-51
Adapter: SMBus I801 adapter at 5000
Algorithm: Non-I2C SMBus adapter
Memory type:            DDR SDRAM DIMM SPD
Memory size (MB):       512

w83627hf-isa-0290
Adapter: ISA adapter
Algorithm: ISA algorithm
VCore 1:   +1.52 V  (min =  +1.44 V, max =  +1.60 V)
VCore 2:   +1.69 V  (min =  +1.44 V, max =  +1.60 V)
+3.3V:     +3.36 V  (min =  +3.13 V, max =  +3.45 V)
+5V:       +5.04 V  (min =  +4.72 V, max =  +5.24 V)
+12V:     +11.89 V  (min = +10.79 V, max = +13.19 V)
-12V:     -11.62 V  (min = -13.21 V, max = -10.90 V)
-5V:       -4.92 V  (min =  -5.26 V, max =  -4.76 V)
V5SB:      +5.53 V  (min =  +4.72 V, max =  +5.24 V)
VBat:      +3.02 V  (min =  +2.40 V, max =  +3.60 V)
fan1:     2045 RPM  (min = 1500 RPM, div = 4)
fan2:     1599 RPM  (min = 1500 RPM, div = 4)
fan3:     1339 RPM  (min = 1500 RPM, div = 4)
temp1:       +47C  (limit =  +60C)                       sensor thermistor
temp2:     +47.5C  (limit =  +60C, hysteresis =  +50C) sensor thermistor
temp3:     +71.0C  (limit =  +60C, hysteresis =  +50C) sensor thermistor   ALARM
vid:      +1.525 V
alarms:
beep_enable:
          Sound alarm disabled



> > Adapter: saa7134[0]
> > Algorithm: saa7134
> 
> What's that thing?
> 

it's my Terratec Cinergy 400 TV tuner card. I kicked it from the
lm_sensors file. didn't change anything.

> > > This is a known problem, which has two possible solutions:
> > > 
> > > 1* Fix your /etc/sensors.conf file. Copy the default
> > > etc/sensors.conf.eg file that match the version you're using, and it
> > > should be OK.
> > 
> > I tried... and runned sensors -s. Didn't help.
> 
> What if you plain delete the config file?

Then ksensors and ksysguard work! So they use the same config file...

> 
> > > 2* If it doesn't work, update to 2.8.0 or CVS, we fixed a bug in the
> > > parser some weeks ago.
> > 
> > I'm using 2.8.0
> 
> Try CVS then <grin> (just kidding, although it may actually give
> results).
> 
> > 
> > Ok, in the meantime, I'm running varyfan very succesfully... PWM works
> > nice.
> 
> I did not know about that program, thanks for the information. I am
> going to add a link on our useful addresses page. I wonder if it offers
> something the programs included in our package don't.

I didn't try them out, you can specify temperatures, fan speed, slowdown
speed... it was right what I needed.

flex scanner jammed problem

[Emperor]

Am Die, 2003-09-23 um 21.14 schrieb Jean Delvare:
> > I just installed lm_sensors via synaptic.
> 
> What is synaptic?

a frontend for apt. very nice. try it and you'll never give it away!

> 
> > I could set up my sensors.
> > But since I did that the KDE process window does not work any more,
> > ksysguardd and ksensors gave me "flex scanner jammed".
> 
> Which means that sensors itself doesn't work. Am I right?

Somehow... But sensors works...

eeprom-i2c-0-50
Adapter: SMBus I801 adapter at 5000
Algorithm: Non-I2C SMBus adapter
Memory type:            DDR SDRAM DIMM SPD
Memory size (MB):       512

eeprom-i2c-0-51
Adapter: SMBus I801 adapter at 5000
Algorithm: Non-I2C SMBus adapter
Memory type:            DDR SDRAM DIMM SPD
Memory size (MB):       512

w83627hf-isa-0290
Adapter: ISA adapter
Algorithm: ISA algorithm
VCore 1:   +1.50 V  (min =  +1.32 V, max =  +1.47 V)       ALARM
VCore 2:   +1.64 V  (min =  +1.32 V, max =  +1.47 V)
+3.3V:     +3.39 V  (min =  +3.13 V, max =  +3.45 V)
+5V:       +5.02 V  (min =  +4.72 V, max =  +5.24 V)
+12V:     +11.97 V  (min = +10.79 V, max = +13.19 V)
-12V:     -11.62 V  (min = -13.21 V, max = -10.90 V)
-5V:       -4.85 V  (min =  -5.26 V, max =  -4.76 V)
V5SB:      +5.53 V  (min =  +4.72 V, max =  +5.24 V)
VBat:      +3.02 V  (min =  +2.40 V, max =  +3.60 V)
fan1:     1471 RPM  (min = 1500 RPM, div = 4)              ALARM
fan2:     1584 RPM  (min = 1500 RPM, div = 4)
fan3:     1333 RPM  (min = 1500 RPM, div = 4)
temp1:       +43C  (limit =  +60C)                       sensor thermistor
temp2:     +46.5C  (limit =  +60C, hysteresis =  +50C) sensor thermistor
temp3:     +70.5C  (limit =  +60C, hysteresis =  +50C) sensor thermistor   ALARM
vid:      +1.400 V
alarms:
beep_enable:
          Sound alarm disabled

eeprom-i2c-2-50
Adapter: saa7134[0]
Algorithm: saa7134



> 
> This is a known problem, which has two possible solutions:
> 
> 1* Fix your /etc/sensors.conf file. Copy the default etc/sensors.conf.eg
> file that match the version you're using, and it should be OK.

I tried... and runned sensors -s. Didn't help.
> 
> 2* If it doesn't work, update to 2.8.0 or CVS, we fixed a bug in the
> parser some weeks ago.
> 

I'm using 2.8.0

> 
> > And I got another question! is there plan in lm_sensors to support
> > writing to fan values, too? the w83627hf chip I have supports that.
> 
> "Writing to fan values" makes no sense ;) You already should be able to
> write to the min settings. As for the speed control, it is known as PWM.
> It *is* supported by our w83781d and w83627hf drivers (one of which you
> must be using), although it is known not to work properly for everyone.
> See the prog/pwm in our package, where you'll find the fancontrol and
> pwmprogram. These are the ones you need in order to have PWM working.
> Give it a try and let us know how it works for you.

Ok, in the meantime, I'm running varyfan very succesfully... PWM works
nice.

thx,

Nils

flex scanner jammed problem

[Jean Delvare]

> > I admit I could have guess that (syn-apt-ic after all). But since I
> > don't use apt anyway...
> 
> hey you should ;) great thing! easy to manage... simply search for
> package lm_sensors and click on install, and soon your jammed your
> flex scanner ;)

I use Slackware. Ease to manage too ;) OK, OK, I'll give a try to Debian
someday.

> > Your vid reading could be wrong, try changing vrm in the config
> > file.
> 
> I did, now the values are right:
> 
> w83627hf-isa-0290
> Adapter: ISA adapter
> Algorithm: ISA algorithm
> VCore 1:   +1.52 V  (min =  +1.44 V, max =  +1.60 V)

Yup, that one is OK.

> VCore 2:   +1.69 V  (min =  +1.44 V, max =  +1.60 V)

Is this value changing? If you have a single-plan CPU, this value
doesn't make sense and you should add an "ignore in1" statement to you
config file.

> fan1:     2045 RPM  (min = 1500 RPM, div = 4)
> fan2:     1599 RPM  (min = 1500 RPM, div = 4)
> fan3:     1339 RPM  (min = 1500 RPM, div = 4)

Your fans are running really low. A least, I guess your computer is
really quiet :)

> temp3:     +71.0C  (limit =  +60C, hysteresis =  +50C) sensor > thermistor   ALARM

That's quite high, maybe you should invest in higher-speed fans.

> > > Adapter: saa7134[0]
> > > Algorithm: saa7134
> > 
> > What's that thing?
> 
> it's my Terratec Cinergy 400 TV tuner card. I kicked it from the
> lm_sensors file. didn't change anything.

The sensors program doesn't know a thing about it, so I wonder why it is
showing there. Will take a look someday.

> > What if you plain delete the config file?
> 
> Then ksensors and ksysguard work! So they use the same config file...

Good thing to know. Then, my analysis is that you have two different
versions of libsensors on your disk. One old for ksensors/ksysguard, and
one new for sensors. Running ldd on these binaries should confirm that.
In that case, you should use a configuration file that work for both
(which means,: that work for the old library, since the new library is
already OK). To do so, either strip your current file so that it only
contains the w83627hf-* section (you just don't care about the others),
or get etc/sensors.conf.eg from lm_sensors-2.7.0 or older, until it's
OK.

> > > Ok, in the meantime, I'm running varyfan very succesfully... PWM
> > > works nice.
> > 
> > I did not know about that program, thanks for the information. I am
> > going to add a link on our useful addresses page. I wonder if it
> > offers something the programs included in our package don't.
> 
> I didn't try them out, you can specify temperatures, fan speed,
> slowdown speed... it was right what I needed.

Would you have some time to give them a try and tell us how they behave
compared with varyfan? I'd appreciate that.

Thanks.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

flex scanner jammed problem

[Jean Delvare]

> > What is synaptic?
> 
> a frontend for apt. very nice. try it and you'll never give it away!

I admit I could have guess that (syn-apt-ic after all). But since I
don't use apt anyway...

> > > I could set up my sensors.
> > > But since I did that the KDE process window does not work any
> > > more, ksysguardd and ksensors gave me "flex scanner jammed".
> > 
> > Which means that sensors itself doesn't work. Am I right?
> 
> Somehow... But sensors works...

So the answer is not "somehow", it is "no, you're wrong".

Then, I guess that ksysguardd and ksensors use their own configuration
files?

> w83627hf-isa-0290
> Adapter: ISA adapter
> Algorithm: ISA algorithm
> VCore 1:   +1.50 V  (min =  +1.32 V, max =  +1.47 V)       ALARM
> (...)
> vid:      +1.400 V

Your vid reading could be wrong, try changing vrm in the config file.

> Adapter: saa7134[0]
> Algorithm: saa7134

What's that thing?

> > This is a known problem, which has two possible solutions:
> > 
> > 1* Fix your /etc/sensors.conf file. Copy the default
> > etc/sensors.conf.eg file that match the version you're using, and it
> > should be OK.
> 
> I tried... and runned sensors -s. Didn't help.

What if you plain delete the config file?

> > 2* If it doesn't work, update to 2.8.0 or CVS, we fixed a bug in the
> > parser some weeks ago.
> 
> I'm using 2.8.0

Try CVS then <grin> (just kidding, although it may actually give
results).

> > "Writing to fan values" makes no sense ;) You already should be able
> > to write to the min settings. As for the speed control, it is known
> > as PWM. It *is* supported by our w83781d and w83627hf drivers (one
> > of which you must be using), although it is known not to work
> > properly for everyone. See the prog/pwm in our package, where you'll
> > find the fancontrol and pwmprogram. These are the ones you need in
> > order to have PWM working. Give it a try and let us know how it
> > works for you.
> 
> Ok, in the meantime, I'm running varyfan very succesfully... PWM works
> nice.

I did not know about that program, thanks for the information. I am
going to add a link on our useful addresses page. I wonder if it offers
something the programs included in our package don't.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

[lm-sensors] Flex Scanner Jammed Problem

[Calabro, Anthony]

Hello,
 
    We recently upgraded from Linux v2.4.9 to 2.6.9 and are trying to go
from lm_sensors 2.8.7 to 2.10.0.
 
    the old version of sensors works on the new system, but the VBatt
readings are incorrect.  Most of the other values seem to be fine
though.
 
    using sensors-detect, we find (ignoring all the "Failed!" lines) :
 
    Probing for PCI bus adapters
    Use driver 'i2c-i801' for device 00:1f.3 : Intel 82801DB ICH4
    ......
    Module 'i2c-i801' already loaded
    ......
    i2c-dev is already loaded
    .......
    Next adapter: SMBus I801 adapter at 1100
    ......
    Client found at address 0x18
    Probing for 'Maxim MAC1617'... Success!
        (confidence 3, driver 'adm1021')
    ......
    Client found at address 0x1a
    Probing for 'Maxim MAC1617'... Success!
        (confidence 3, driver 'adm1021')
    ....
    Client found at address 0x2d
    Probing for 'Winbond W83627HF'... Success!
        (confidence 8, driver 'w83781d'), other addresses: 0x48 0x49
    .....
    Client found at address 0x2e
    Probing for 'LM87'... Success!
        (confidence 7, driver 'LM87')
    .... 
    Client found at address 0x30
    Client found at address 0x48
    Client found at address 0x49
    Client found at address 0x61
    Probing for 'SMBus 2.0 ARP-Capable Device'... Success!
        confidence 1, driver 'smbus-arp'
    Client found at address 0x69
    .....
    ISA scan:
    Probing for Winbond W83627HF'... Success!
        (confidence 8, driver 'w83781d')
        Alias of the chip on I2C bus 'SMBus I801 adapter at 1100'
    .....
 
    #---cut here----
    # I2C module options
    alias char-major-89 i2c-dev
    options w83781d ignore=0,0x2d
    #----cut here-----
 
    #---cut here----
    # I2C adapter drivers
    modprobe i2c-i801
    modprobe i2c-isa
    # I2C chip drivers
    modprobe adm1021
    modprobe w83781d
    # Warning:  required module lm87 is not currently installed on your
system.
    modprobe lm87
    # Warning:  required module smbus-arp is not currently installed on
your system.
    modprobe smbus-arp
    modprobe w83627hf
    #----cut here-----
             
 
so i load all available libraries and run sensors -s it returns flex
scanner jammed.
 
modules loaded:
w83781d
w83627hf
i2c-isa
i2c-sensor
i2c-i801
i2c-dev
i2c-core
 
i tried getting the new sensors.conf file, and copying over old ones,
and even trying an empty file, none of which work...
 
i also tried removing modules down to just sensors, i801 and w83781d,
and removing ones until i got the proc/sysfs error message, then adding
modules back up until the flex scanner message returned.
 
any help or suggestions would be very useful, thanks...
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060802/dbfaf3cf/attachment.html 

[lm-sensors] Flex Scanner Jammed Problem

[Jean Delvare]

Hi Anthony,

>     We recently upgraded from Linux v2.4.9 to 2.6.9 and are trying to go
> from lm_sensors 2.8.7 to 2.10.0.
>  
>     the old version of sensors works on the new system, but the VBatt
> readings are incorrect.  Most of the other values seem to be fine
> though.
>  
>     using sensors-detect, we find (ignoring all the "Failed!" lines) :
>  
>     Probing for PCI bus adapters
>     Use driver 'i2c-i801' for device 00:1f.3 : Intel 82801DB ICH4
>     ......
>     Module 'i2c-i801' already loaded
>     ......
>     i2c-dev is already loaded
>     .......
>     Next adapter: SMBus I801 adapter at 1100
>     ......
>     Client found at address 0x18
>     Probing for 'Maxim MAC1617'... Success!

You certainly mean MA_X_1617. Did you really copy all of this output
manually? ;)

>         (confidence 3, driver 'adm1021')
>     ......
>     Client found at address 0x1a
>     Probing for 'Maxim MAC1617'... Success!
>         (confidence 3, driver 'adm1021')

Dual-Xeon system?

>     ....
>     Client found at address 0x2d
>     Probing for 'Winbond W83627HF'... Success!
>         (confidence 8, driver 'w83781d'), other addresses: 0x48 0x49
>     .....
>     Client found at address 0x2e
>     Probing for 'LM87'... Success!
>         (confidence 7, driver 'LM87')
>     .... 
>     Client found at address 0x30
>     Client found at address 0x48
>     Client found at address 0x49
>     Client found at address 0x61
>     Probing for 'SMBus 2.0 ARP-Capable Device'... Success!
>         confidence 1, driver 'smbus-arp'
>     Client found at address 0x69
>     .....
>     ISA scan:
>     Probing for Winbond W83627HF'... Success!
>         (confidence 8, driver 'w83781d')
>         Alias of the chip on I2C bus 'SMBus I801 adapter at 1100'
>     .....
>  
>     #---cut here----
>     # I2C module options
>     alias char-major-89 i2c-dev
>     options w83781d ignore=0,0x2d

Hm, this is a bug, this ignore line shouldn't be there. I thought I had
fixed this some months ago...

>     #----cut here-----
>  
>     #---cut here----
>     # I2C adapter drivers
>     modprobe i2c-i801
>     modprobe i2c-isa
>     # I2C chip drivers
>     modprobe adm1021
>     modprobe w83781d
>     # Warning:  required module lm87 is not currently installed on your system.
>     modprobe lm87

This one wasn't ported to Linux 2.6 at the time of 2.6.9. If you need
it, you'll need to backport it, or to move to a more recent kernel.

>     # Warning:  required module smbus-arp is not currently installed on your system.
>     modprobe smbus-arp

You can ignore this one, it's useless anyway.

>     modprobe w83627hf
>     #----cut here-----
>              
>  
> so i load all available libraries 

What do you mean? Do you mean you loaded the _kernel_modules_?

> and run sensors -s it returns flex scanner jammed.

This means that the configuration file contains something libsensors
doesn't understand. This would happen if you have an old libsensors,
and a new sensors.conf file, or if your sensors.conf file got somehow
corrupted.

>  
> modules loaded:
> w83781d
> w83627hf

Loading both drivers is a bad idea. This too, I thought I had fixed...
Load either driver, but not both. I would recommend w83627hf, it's
generally better.

> i2c-isa
> i2c-sensor
> i2c-i801
> i2c-dev
> i2c-core
>  
> i tried getting the new sensors.conf file, and copying over old ones,
> and even trying an empty file, none of which work...

By "none of which work", I take it that you always obtained the "flex
scanner jammed" error message?

> i also tried removing modules down to just sensors, i801 and w83781d,
> and removing ones until i got the proc/sysfs error message, then adding
> modules back up until the flex scanner message returned.

I suspect that you have both the old and the new libsensors installed
on your system, and the new "sensors" picks the old library. Try
"sensors -v" and see what it returns. Or run "ldd $(which sensors)" for
a similar effect.

If I'm right, you should simply get rid of (or rename) the old library,
run ldconfig, and try again.

The only strange thing is that an empty configuration file should have
let "sensors" work, and you report it did not...

-- 
Jean Delvare

[lm-sensors] Flex Scanner Jammed Problem

[Calabro, Anthony]

 
Hi Anthony,

>     We recently upgraded from Linux v2.4.9 to 2.6.9 and are trying to 
> go from lm_sensors 2.8.7 to 2.10.0.
>  
>     the old version of sensors works on the new system, but the VBatt 
> readings are incorrect.  Most of the other values seem to be fine 
> though.
>  
>     using sensors-detect, we find (ignoring all the "Failed!" lines) :
>  
>     Probing for PCI bus adapters
>     Use driver 'i2c-i801' for device 00:1f.3 : Intel 82801DB ICH4
>     ......
>     Module 'i2c-i801' already loaded
>     ......
>     i2c-dev is already loaded
>     .......
>     Next adapter: SMBus I801 adapter at 1100
>     ......
>     Client found at address 0x18
>     Probing for 'Maxim MAC1617'... Success!

You certainly mean MA_X_1617. Did you really copy all of this output
manually? ;)

-- Yeah, I cant actually paste any of the ouptput over, huuge pain.

>         (confidence 3, driver 'adm1021')
>     ......
>     Client found at address 0x1a
>     Probing for 'Maxim MAC1617'... Success!
>         (confidence 3, driver 'adm1021')

Dual-Xeon system?

-- Yes

>     ....
>     Client found at address 0x2d
>     Probing for 'Winbond W83627HF'... Success!
>         (confidence 8, driver 'w83781d'), other addresses: 0x48 0x49
>     .....
>     Client found at address 0x2e
>     Probing for 'LM87'... Success!
>         (confidence 7, driver 'LM87')
>     .... 
>     Client found at address 0x30
>     Client found at address 0x48
>     Client found at address 0x49
>     Client found at address 0x61
>     Probing for 'SMBus 2.0 ARP-Capable Device'... Success!
>         confidence 1, driver 'smbus-arp'
>     Client found at address 0x69
>     .....
>     ISA scan:
>     Probing for Winbond W83627HF'... Success!
>         (confidence 8, driver 'w83781d')
>         Alias of the chip on I2C bus 'SMBus I801 adapter at 1100'
>     .....
>  
>     #---cut here----
>     # I2C module options
>     alias char-major-89 i2c-dev
>     options w83781d ignore=0,0x2d

Hm, this is a bug, this ignore line shouldn't be there. I thought I had
fixed this some months ago...

>     #----cut here-----
>  
>     #---cut here----
>     # I2C adapter drivers
>     modprobe i2c-i801
>     modprobe i2c-isa
>     # I2C chip drivers
>     modprobe adm1021
>     modprobe w83781d
>     # Warning:  required module lm87 is not currently installed on
your system.
>     modprobe lm87

This one wasn't ported to Linux 2.6 at the time of 2.6.9. If you need
it, you'll need to backport it, or to move to a more recent kernel.

-- OK

>     # Warning:  required module smbus-arp is not currently installed
on your system.
>     modprobe smbus-arp

You can ignore this one, it's useless anyway.

>     modprobe w83627hf
>     #----cut here-----
>              
>  
> so i load all available libraries

What do you mean? Do you mean you loaded the _kernel_modules_?

-- yes loaded all the modules...

> and run sensors -s it returns flex scanner jammed.

This means that the configuration file contains something libsensors
doesn't understand. This would happen if you have an old libsensors, and
a new sensors.conf file, or if your sensors.conf file got somehow
corrupted.

>  
> modules loaded:
> w83781d
> w83627hf

Loading both drivers is a bad idea. This too, I thought I had fixed...
Load either driver, but not both. I would recommend w83627hf, it's
generally better.

> i2c-isa
> i2c-sensor
> i2c-i801
> i2c-dev
> i2c-core
>  
> i tried getting the new sensors.conf file, and copying over old ones, 
> and even trying an empty file, none of which work...

By "none of which work", I take it that you always obtained the "flex
scanner jammed" error message?

-- correct.

> i also tried removing modules down to just sensors, i801 and w83781d, 
> and removing ones until i got the proc/sysfs error message, then 
> adding modules back up until the flex scanner message returned.

I suspect that you have both the old and the new libsensors installed on
your system, and the new "sensors" picks the old library. Try "sensors
-v" and see what it returns. Or run "ldd $(which sensors)" for a similar
effect.

If I'm right, you should simply get rid of (or rename) the old library,
run ldconfig, and try again.

The only strange thing is that an empty configuration file should have
let "sensors" work, and you report it did not...

-- I ran sensors -v and get:
	sensors version 2.10.0 with libsensors version 2.10.0

 with ldd /usr/bin/sensors I get:
	libsensors.so.3 => /usr/lib/libsensors.so.3 (0x00664000)
	libc.so.6 => /lib/tls/libc.so.6 (0x0075b000)
	libm.so.6 => /lib/tls/libm.so.6 (0x0088d000)
	libsysfs.so.1 => /usr/lib/libsysfs.so.1 (0x00101000)
	/lib/ld-linux.so.2 (0x00742000)

If I do ls /usr/lib/libsens* I get:

libsensors.a
libsensors.so -> libsensors.so.3
libsensors.so.3 -> libsensors.so.3.1.0
libsensors.so.3.0.5
libsensors.so.3.1.0

I definitely think that could be possible, I simply installed the new
version right over top of the old versions on sensors and libsensors.
But everything looks OK.  Thanks so much for your quick response and let
me know if you see anything else that might help.

-Anthony Calabro

[lm-sensors] Flex Scanner Jammed Problem

[Calabro, Anthony]

Well, I tried a few things and removed w83781d, I again removed the
sensors.conf file, and this time it worked.

The problem definitely is with the sensors.conf file...

I think its because im copying it over from a windows machine down to
the linux server, I ran dos2unix on it, but I guess its still corrupted
in some way.

Im going to try to create my own.... Thanks for your help.


-----Original Message-----
From: Jean Delvare [mailto:khali at linux-fr.org] 
Sent: Wednesday, August 02, 2006 12:16 PM
To: Calabro, Anthony
Cc: LM Sensors
Subject: Re: [lm-sensors] Flex Scanner Jammed Problem

Hi Anthony,

>     We recently upgraded from Linux v2.4.9 to 2.6.9 and are trying to 
> go from lm_sensors 2.8.7 to 2.10.0.
>  
>     the old version of sensors works on the new system, but the VBatt 
> readings are incorrect.  Most of the other values seem to be fine 
> though.
>  
>     using sensors-detect, we find (ignoring all the "Failed!" lines) :
>  
>     Probing for PCI bus adapters
>     Use driver 'i2c-i801' for device 00:1f.3 : Intel 82801DB ICH4
>     ......
>     Module 'i2c-i801' already loaded
>     ......
>     i2c-dev is already loaded
>     .......
>     Next adapter: SMBus I801 adapter at 1100
>     ......
>     Client found at address 0x18
>     Probing for 'Maxim MAC1617'... Success!

You certainly mean MA_X_1617. Did you really copy all of this output
manually? ;)

>         (confidence 3, driver 'adm1021')
>     ......
>     Client found at address 0x1a
>     Probing for 'Maxim MAC1617'... Success!
>         (confidence 3, driver 'adm1021')

Dual-Xeon system?

>     ....
>     Client found at address 0x2d
>     Probing for 'Winbond W83627HF'... Success!
>         (confidence 8, driver 'w83781d'), other addresses: 0x48 0x49
>     .....
>     Client found at address 0x2e
>     Probing for 'LM87'... Success!
>         (confidence 7, driver 'LM87')
>     .... 
>     Client found at address 0x30
>     Client found at address 0x48
>     Client found at address 0x49
>     Client found at address 0x61
>     Probing for 'SMBus 2.0 ARP-Capable Device'... Success!
>         confidence 1, driver 'smbus-arp'
>     Client found at address 0x69
>     .....
>     ISA scan:
>     Probing for Winbond W83627HF'... Success!
>         (confidence 8, driver 'w83781d')
>         Alias of the chip on I2C bus 'SMBus I801 adapter at 1100'
>     .....
>  
>     #---cut here----
>     # I2C module options
>     alias char-major-89 i2c-dev
>     options w83781d ignore=0,0x2d

Hm, this is a bug, this ignore line shouldn't be there. I thought I had
fixed this some months ago...

>     #----cut here-----
>  
>     #---cut here----
>     # I2C adapter drivers
>     modprobe i2c-i801
>     modprobe i2c-isa
>     # I2C chip drivers
>     modprobe adm1021
>     modprobe w83781d
>     # Warning:  required module lm87 is not currently installed on
your system.
>     modprobe lm87

This one wasn't ported to Linux 2.6 at the time of 2.6.9. If you need
it, you'll need to backport it, or to move to a more recent kernel.

>     # Warning:  required module smbus-arp is not currently installed
on your system.
>     modprobe smbus-arp

You can ignore this one, it's useless anyway.

>     modprobe w83627hf
>     #----cut here-----
>              
>  
> so i load all available libraries

What do you mean? Do you mean you loaded the _kernel_modules_?

> and run sensors -s it returns flex scanner jammed.

This means that the configuration file contains something libsensors
doesn't understand. This would happen if you have an old libsensors, and
a new sensors.conf file, or if your sensors.conf file got somehow
corrupted.

>  
> modules loaded:
> w83781d
> w83627hf

Loading both drivers is a bad idea. This too, I thought I had fixed...
Load either driver, but not both. I would recommend w83627hf, it's
generally better.

> i2c-isa
> i2c-sensor
> i2c-i801
> i2c-dev
> i2c-core
>  
> i tried getting the new sensors.conf file, and copying over old ones, 
> and even trying an empty file, none of which work...

By "none of which work", I take it that you always obtained the "flex
scanner jammed" error message?

> i also tried removing modules down to just sensors, i801 and w83781d, 
> and removing ones until i got the proc/sysfs error message, then 
> adding modules back up until the flex scanner message returned.

I suspect that you have both the old and the new libsensors installed on
your system, and the new "sensors" picks the old library. Try "sensors
-v" and see what it returns. Or run "ldd $(which sensors)" for a similar
effect.

If I'm right, you should simply get rid of (or rename) the old library,
run ldconfig, and try again.

The only strange thing is that an empty configuration file should have
let "sensors" work, and you report it did not...

--
Jean Delvare

[lm-sensors] Flex Scanner Jammed Problem

[Calabro, Anthony]

Im still finding now that whatever I put in the sensors.conf file I get
flex scanner jammed.

Even with just two lines, one defining the chip, and one defining a
label.

Even with the newest version in the downloads section.

But when I put a 0 byte file there it works...

Any suggestions? 


Anthony W. Calabro

Voice: 703.367.3138 
Email:  anthony.calabro at lmco.com

-----Original Message-----
From: Jean Delvare [mailto:khali at linux-fr.org] 
Sent: Wednesday, August 02, 2006 12:16 PM
To: Calabro, Anthony
Cc: LM Sensors
Subject: Re: [lm-sensors] Flex Scanner Jammed Problem

Hi Anthony,

>     We recently upgraded from Linux v2.4.9 to 2.6.9 and are trying to 
> go from lm_sensors 2.8.7 to 2.10.0.
>  
>     the old version of sensors works on the new system, but the VBatt 
> readings are incorrect.  Most of the other values seem to be fine 
> though.
>  
>     using sensors-detect, we find (ignoring all the "Failed!" lines) :
>  
>     Probing for PCI bus adapters
>     Use driver 'i2c-i801' for device 00:1f.3 : Intel 82801DB ICH4
>     ......
>     Module 'i2c-i801' already loaded
>     ......
>     i2c-dev is already loaded
>     .......
>     Next adapter: SMBus I801 adapter at 1100
>     ......
>     Client found at address 0x18
>     Probing for 'Maxim MAC1617'... Success!

You certainly mean MA_X_1617. Did you really copy all of this output
manually? ;)

>         (confidence 3, driver 'adm1021')
>     ......
>     Client found at address 0x1a
>     Probing for 'Maxim MAC1617'... Success!
>         (confidence 3, driver 'adm1021')

Dual-Xeon system?

>     ....
>     Client found at address 0x2d
>     Probing for 'Winbond W83627HF'... Success!
>         (confidence 8, driver 'w83781d'), other addresses: 0x48 0x49
>     .....
>     Client found at address 0x2e
>     Probing for 'LM87'... Success!
>         (confidence 7, driver 'LM87')
>     .... 
>     Client found at address 0x30
>     Client found at address 0x48
>     Client found at address 0x49
>     Client found at address 0x61
>     Probing for 'SMBus 2.0 ARP-Capable Device'... Success!
>         confidence 1, driver 'smbus-arp'
>     Client found at address 0x69
>     .....
>     ISA scan:
>     Probing for Winbond W83627HF'... Success!
>         (confidence 8, driver 'w83781d')
>         Alias of the chip on I2C bus 'SMBus I801 adapter at 1100'
>     .....
>  
>     #---cut here----
>     # I2C module options
>     alias char-major-89 i2c-dev
>     options w83781d ignore=0,0x2d

Hm, this is a bug, this ignore line shouldn't be there. I thought I had
fixed this some months ago...

>     #----cut here-----
>  
>     #---cut here----
>     # I2C adapter drivers
>     modprobe i2c-i801
>     modprobe i2c-isa
>     # I2C chip drivers
>     modprobe adm1021
>     modprobe w83781d
>     # Warning:  required module lm87 is not currently installed on
your system.
>     modprobe lm87

This one wasn't ported to Linux 2.6 at the time of 2.6.9. If you need
it, you'll need to backport it, or to move to a more recent kernel.

>     # Warning:  required module smbus-arp is not currently installed
on your system.
>     modprobe smbus-arp

You can ignore this one, it's useless anyway.

>     modprobe w83627hf
>     #----cut here-----
>              
>  
> so i load all available libraries

What do you mean? Do you mean you loaded the _kernel_modules_?

> and run sensors -s it returns flex scanner jammed.

This means that the configuration file contains something libsensors
doesn't understand. This would happen if you have an old libsensors, and
a new sensors.conf file, or if your sensors.conf file got somehow
corrupted.

>  
> modules loaded:
> w83781d
> w83627hf

Loading both drivers is a bad idea. This too, I thought I had fixed...
Load either driver, but not both. I would recommend w83627hf, it's
generally better.

> i2c-isa
> i2c-sensor
> i2c-i801
> i2c-dev
> i2c-core
>  
> i tried getting the new sensors.conf file, and copying over old ones, 
> and even trying an empty file, none of which work...

By "none of which work", I take it that you always obtained the "flex
scanner jammed" error message?

> i also tried removing modules down to just sensors, i801 and w83781d, 
> and removing ones until i got the proc/sysfs error message, then 
> adding modules back up until the flex scanner message returned.

I suspect that you have both the old and the new libsensors installed on
your system, and the new "sensors" picks the old library. Try "sensors
-v" and see what it returns. Or run "ldd $(which sensors)" for a similar
effect.

If I'm right, you should simply get rid of (or rename) the old library,
run ldconfig, and try again.

The only strange thing is that an empty configuration file should have
let "sensors" work, and you report it did not...

--
Jean Delvare

[lm-sensors] Flex Scanner Jammed Problem

[Jean Delvare]

Hi Anthony,

> Im still finding now that whatever I put in the sensors.conf file I get
> flex scanner jammed.
> 
> Even with just two lines, one defining the chip, and one defining a
> label.

Can you please send this file to us? In a way it won't be altered by
the transfer.

> Even with the newest version in the downloads section.
> 
> But when I put a 0 byte file there it works...
> 
> Any suggestions? 

Try our latest default configuration file:
http://lm-sensors.org/svn/lm-sensors/trunk/etc/sensors.conf.eg

If that works, then the problem is definitely the configuration file
you created. If not... Please tell us with which versions of flex and
bison you built lm_sensors.

Note that you can use the "-c" option of "sensors" to select a
configuration file. This should help you test different files.

-- 
Jean Delvare

[lm-sensors] Flex Scanner Jammed Problem

[Calabro, Anthony]

 


-----Original Message-----
From: Jean Delvare [mailto:khali at linux-fr.org] 
Sent: Thursday, August 03, 2006 4:50 AM
To: Calabro, Anthony
Cc: LM Sensors
Subject: Re: [lm-sensors] Flex Scanner Jammed Problem

Hi Anthony,

> Im still finding now that whatever I put in the sensors.conf file I 
> get flex scanner jammed.
> 
> Even with just two lines, one defining the chip, and one defining a 
> label.

Can you please send this file to us? In a way it won't be altered by the
transfer.

> Even with the newest version in the downloads section.
> 
> But when I put a 0 byte file there it works...
> 
> Any suggestions? 

Try our latest default configuration file:
http://lm-sensors.org/svn/lm-sensors/trunk/etc/sensors.conf.eg

If that works, then the problem is definitely the configuration file you
created. If not... Please tell us with which versions of flex and bison
you built lm_sensors.

Note that you can use the "-c" option of "sensors" to select a
configuration file. This should help you test different files.

-- I tried the newest config file, still flex scanner jammed, working on
getting a copy to send to you.

-- using flex version 2.5.4
-- using bison version 1.875c

-- Thanks...

[lm-sensors] Flex Scanner Jammed Problem

[Jean Delvare]

> Try our latest default configuration file:
> http://lm-sensors.org/svn/lm-sensors/trunk/etc/sensors.conf.eg
> 
> If that works, then the problem is definitely the configuration file you
> created. If not... Please tell us with which versions of flex and bison
> you built lm_sensors.
> 
> Note that you can use the "-c" option of "sensors" to select a
> configuration file. This should help you test different files.
> 
> -- I tried the newest config file, still flex scanner jammed, working on
> getting a copy to send to you.
> 
> -- using flex version 2.5.4
> -- using bison version 1.875c

I just tried this combination but was unable to reproduce the problem.

Can you try removing the following line from lib/conf-lex.l:

%option nodefault

As I understand it, it should cause libsensors to output anything it
doesn't understand in the config file to stdout. Maybe that will
provide some hint. Other than that, I don't know what to suggest.

-- 
Jean Delvare

[lm-sensors] Flex Scanner Jammed Problem

[Calabro, Anthony]

-----Original Message-----
From: Jean Delvare [mailto:khali at linux-fr.org] 
Sent: Thursday, August 03, 2006 11:41 AM
To: Calabro, Anthony
Cc: LM Sensors
Subject: Re: [lm-sensors] Flex Scanner Jammed Problem

> Try our latest default configuration file:
> http://lm-sensors.org/svn/lm-sensors/trunk/etc/sensors.conf.eg
> 
> If that works, then the problem is definitely the configuration file 
> you created. If not... Please tell us with which versions of flex and 
> bison you built lm_sensors.
> 
> Note that you can use the "-c" option of "sensors" to select a 
> configuration file. This should help you test different files.
> 
> -- I tried the newest config file, still flex scanner jammed, working 
> on getting a copy to send to you.
> 
> -- using flex version 2.5.4
> -- using bison version 1.875c

I just tried this combination but was unable to reproduce the problem.

Can you try removing the following line from lib/conf-lex.l:

%option nodefault

As I understand it, it should cause libsensors to output anything it
doesn't understand in the config file to stdout. Maybe that will provide
some hint. Other than that, I don't know what to suggest.

--------------

Thanks, I tried that, again I emptied out the sensors.conf file to just
the chip line and the label lines.  I got rid of all of the parsing
errors, but it outputs this when you run sensors -s:

	in0  in1  in2  in3  in4  in5  ....

So it seems that it doesn't recognize these names.  I tried changing
them to make sure, and it did the same thing, I changed all of the (n)'s
to (t)'s and got
	
	it0  it1  it2 .....

Samething when I run sensors.  I see the 

	in0  in1  in2  in3  in4  in5  ....

At the top of the output, followed by the sensors readings with 

in0:  
in1:	
....
...

as labels...

[lm-sensors] Flex Scanner Jammed Problem

[Mark M. Hoffman]

Hi Jean:

* Jean Delvare <khali at linux-fr.org> [2006-08-03 17:40:45 +0200]:
> > Try our latest default configuration file:
> > http://lm-sensors.org/svn/lm-sensors/trunk/etc/sensors.conf.eg
> > 
> > If that works, then the problem is definitely the configuration file you
> > created. If not... Please tell us with which versions of flex and bison
> > you built lm_sensors.
> > 
> > Note that you can use the "-c" option of "sensors" to select a
> > configuration file. This should help you test different files.
> > 
> > -- I tried the newest config file, still flex scanner jammed, working on
> > getting a copy to send to you.
> > 
> > -- using flex version 2.5.4
> > -- using bison version 1.875c
> 
> I just tried this combination but was unable to reproduce the problem.
> 
> Can you try removing the following line from lib/conf-lex.l:
> 
> %option nodefault
> 
> As I understand it, it should cause libsensors to output anything it
> doesn't understand in the config file to stdout. Maybe that will
> provide some hint. Other than that, I don't know what to suggest.

I have been watching this thread closely, even though I haven't spoken
up until now.

Version 2.5.4 of flex is current[1] (same as mine), version 1.875c of bison
is ancient (I have 2.0).  OTOH, I'm pretty sure that's irrelevant to this
problem because the "flex scanner jammed" message happens prior to the
parser (from bison) receiving the token from flex.

I.e. we both have the same version of flex; AFAICT that's all that matters.

As for the %option nodefault... I think there is some bad interaction 
between that one and %option yylineno.  Some time ago I played with
getting rid of %option yylineno (and keeping track of line numbers with
explicit rules) as a performance optimization.  As soon as I turned off
the yylineno option, flex started complaining about the nodefault option
being specified even though the default rule was still in use.  But
those two options should be unrelated... I haven't figured it out yet.

I'm not sure how helpful any of this is for the problem at hand... sorry.

Regards,

[1] Well, not really.  Flex has been updated a lot since 2.5.4, but that
all happened outside of the GNU project and I don't think any distro ships
the newer non-GNU flex versions.  If you look on ftp.gnu.org, they claim
the latest is 2.5.4.

-- 
Mark M. Hoffman
mhoffman at lightlink.com

[lm-sensors] Flex Scanner Jammed Problem

[Jean Delvare]

Hi Mark, Anthony,

> Version 2.5.4 of flex is current[1] (same as mine), version 1.875c of bison
> is ancient (I have 2.0).  OTOH, I'm pretty sure that's irrelevant to this
> problem because the "flex scanner jammed" message happens prior to the
> parser (from bison) receiving the token from flex.
> 
> I.e. we both have the same version of flex; AFAICT that's all that matters.
> 
> As for the %option nodefault... I think there is some bad interaction 
> between that one and %option yylineno.  Some time ago I played with
> getting rid of %option yylineno (and keeping track of line numbers with
> explicit rules) as a performance optimization.  As soon as I turned off
> the yylineno option, flex started complaining about the nodefault option
> being specified even though the default rule was still in use.  But
> those two options should be unrelated... I haven't figured it out yet.
> 
> I'm not sure how helpful any of this is for the problem at hand... sorry.

Well, thanks for the information anyway. Good thing to know that bison
isn't involved. I am really not familiar with the configuration file
parsing part of libsensors, I've been avoiding messing up with it as
much as possible so far.

I'm out of (non-stupid) ideas on this one. It's rather hard to debug a
problem I am not able to reproduce.

Anthony, are you running a non-standard locale, maybe?

You may also try intermediate versions of lm_sensors, if you had 2.8.7
working before and 2.10.0 doesn't work anymore, it suggests that
something changed in-between (although you could try rebuilding 2.8.7
rebuilding 2.8.7 to start with, and check if it really still works -
maybe your build environment changed, rather than the code?)

-- 
Jean Delvare

[lm-sensors] Flex Scanner Jammed Problem

[Calabro, Anthony]

> 
> Hi Mark, Anthony,
> 
> > Version 2.5.4 of flex is current[1] (same as mine), version 
> 1.875c of 
> > bison is ancient (I have 2.0).  OTOH, I'm pretty sure that's 
> > irrelevant to this problem because the "flex scanner 
> jammed" message 
> > happens prior to the parser (from bison) receiving the 
> token from flex.
> > 
> > I.e. we both have the same version of flex; AFAICT that's 
> all that matters.
> > 
> > As for the %option nodefault... I think there is some bad 
> interaction 
> > between that one and %option yylineno.  Some time ago I played with 
> > getting rid of %option yylineno (and keeping track of line numbers 
> > with explicit rules) as a performance optimization.  As soon as I 
> > turned off the yylineno option, flex started complaining about the 
> > nodefault option being specified even though the default rule was 
> > still in use.  But those two options should be unrelated... 
> I haven't figured it out yet.
> > 
> > I'm not sure how helpful any of this is for the problem at 
> hand... sorry.
> 
> Well, thanks for the information anyway. Good thing to know 
> that bison isn't involved. I am really not familiar with the 
> configuration file parsing part of libsensors, I've been 
> avoiding messing up with it as much as possible so far.
> 
> I'm out of (non-stupid) ideas on this one. It's rather hard 
> to debug a problem I am not able to reproduce.
> 
> Anthony, are you running a non-standard locale, maybe?
> 
> You may also try intermediate versions of lm_sensors, if you 
> had 2.8.7 working before and 2.10.0 doesn't work anymore, it 
> suggests that something changed in-between (although you 
> could try rebuilding 2.8.7 rebuilding 2.8.7 to start with, 
> and check if it really still works - maybe your build 
> environment changed, rather than the code?)
> 
> --
> Jean Delvare
> 
> 

Very interesting results... When I turned off the %option nodefault, it
showed me everyhting that was happening incorrectly in the parsing, and
the way I finally made it run without error and correctly work, I had to
put the in0 in quotes also.  Ex:  "in0".  That way a label lin looked
something like this:

label "in0" "VCore 1"
label "in1" "VCore 2"

Doing this causes sensors -s to run without error and also now displays
the correct labels when you run sensors...  Im still messing around and
trying different things to attempt to figure out why this is happening
or if there is anything else going on here.  Ill keep you up to date on
what I find out.

[lm-sensors] Flex Scanner Jammed Problem

[Jean Delvare]

Hi Anthony,

> Very interesting results... When I turned off the %option nodefault, it
> showed me everyhting that was happening incorrectly in the parsing, and
> the way I finally made it run without error and correctly work, I had to
> put the in0 in quotes also.  Ex:  "in0".  That way a label lin looked
> something like this:
> 
> label "in0" "VCore 1"
> label "in1" "VCore 2"
> 
> Doing this causes sensors -s to run without error and also now displays
> the correct labels when you run sensors...  Im still messing around and
> trying different things to attempt to figure out why this is happening
> or if there is anything else going on here.  Ill keep you up to date on
> what I find out.

Wow. It is known that labels need to be quoted when they do not begin
with a letter, but for regular ones like "in0" that's completely new to
me. I really wonder what causes your version of libsensors to behave
like this.

What about my question on the locale you use?

Anyway, thanks for keeping us informed, this is really appreciated.
That way we may help if other users report a similar problem.

-- 
Jean Delvare

[lm-sensors] Flex Scanner Jammed Problem

[Calabro, Anthony]

Hello,
> -----Original Message-----
> From: Jean Delvare [mailto:khali at linux-fr.org] 
> Sent: Wednesday, August 09, 2006 1:13 PM
> To: Calabro, Anthony
> Cc: LM Sensors
> Subject: Re: [lm-sensors] Flex Scanner Jammed Problem
> 
> Hi Anthony,
> 
> > Very interesting results... When I turned off the %option 
> nodefault, 
> > it showed me everyhting that was happening incorrectly in 
> the parsing, 
> > and the way I finally made it run without error and 
> correctly work, I 
> > had to put the in0 in quotes also.  Ex:  "in0".  That way a 
> label lin 
> > looked something like this:
> > 
> > label "in0" "VCore 1"
> > label "in1" "VCore 2"
> > 
> > Doing this causes sensors -s to run without error and also now 
> > displays the correct labels when you run sensors...  Im 
> still messing 
> > around and trying different things to attempt to figure out 
> why this 
> > is happening or if there is anything else going on here.  
> Ill keep you 
> > up to date on what I find out.
> 
> Wow. It is known that labels need to be quoted when they do 
> not begin with a letter, but for regular ones like "in0" 
> that's completely new to me. I really wonder what causes your 
> version of libsensors to behave like this.
> 
> What about my question on the locale you use?

Locale is en_US.UTF-8

> 
> Anyway, thanks for keeping us informed, this is really appreciated.
> That way we may help if other users report a similar problem.

It seems that the only thing the parser recognizes are lm_sensors
keywords (label, compute, set), but only if they are in the first
position on the line.  The sample sensors.conf will not work for me with
the spaces in front of the terms.  I get Invalid Keyword errors.

In a compute line, I havent figured out how to make it process without
error, I get syntax errors on the computation part of the line, if it
put it into quotes, I get an unexpected EOL error.

> 
> --
> Jean Delvare
> 
> 

[lm-sensors] Flex Scanner Jammed Problem

[Calabro, Anthony]

Jean, 

> -----Original Message-----
> From: Jean Delvare [mailto:khali at linux-fr.org] 
> Sent: Wednesday, August 09, 2006 1:13 PM
> To: Calabro, Anthony
> Cc: LM Sensors
> Subject: Re: [lm-sensors] Flex Scanner Jammed Problem
> 
> Hi Anthony,
> 
> > Very interesting results... When I turned off the %option 
> nodefault, 
> > it showed me everyhting that was happening incorrectly in 
> the parsing, 
> > and the way I finally made it run without error and 
> correctly work, I 
> > had to put the in0 in quotes also.  Ex:  "in0".  That way a 
> label lin 
> > looked something like this:
> > 
> > label "in0" "VCore 1"
> > label "in1" "VCore 2"
> > 
> > Doing this causes sensors -s to run without error and also now 
> > displays the correct labels when you run sensors...  Im 
> still messing 
> > around and trying different things to attempt to figure out 
> why this 
> > is happening or if there is anything else going on here.  
> Ill keep you 
> > up to date on what I find out.
> 
> Wow. It is known that labels need to be quoted when they do 
> not begin with a letter, but for regular ones like "in0" 
> that's completely new to me. I really wonder what causes your 
> version of libsensors to behave like this.
> 
> What about my question on the locale you use?
> 
> Anyway, thanks for keeping us informed, this is really appreciated.
> That way we may help if other users report a similar problem.
> 
> --
> Jean Delvare
> 
> 


If I run sensors  v2.10.0 with the libsensors v2.8.7, the parser works
correctly with the original sensors.conf input file.  I wonder if there
is a problem with where it is being compiled...

So right now I have sensors 2.10.0 running with either libsensors 2.8.7
or 2.10.0.  in either case I am getting weird sensors readings....  Most
voltages read 4.08 V, and the fans and temps are not returning any
values. 

[lm-sensors] Flex Scanner Jammed Problem

[Jean Delvare]

Hi Anthony,

> > What about my question on the locale you use?
> 
> Locale is en_US.UTF-8

Pretty standard. But just in case, would you mind recompiling
libsensors with locale set to C or POSIX, and then running "sensors"
with the same locale?

> It seems that the only thing the parser recognizes are lm_sensors
> keywords (label, compute, set), but only if they are in the first
> position on the line.  The sample sensors.conf will not work for me with
> the spaces in front of the terms.  I get Invalid Keyword errors.
> 
> In a compute line, I havent figured out how to make it process without
> error, I get syntax errors on the computation part of the line, if it
> put it into quotes, I get an unexpected EOL error.

Compute lines are by far the most complex ones in the configuration
file. Given the trouble you had for more simple statements, it's likely
they will never work.

-- 
Jean Delvare

[lm-sensors] Flex Scanner Jammed Problem

[Jean Delvare]

> If I run sensors  v2.10.0 with the libsensors v2.8.7, the parser works
> correctly with the original sensors.conf input file.  I wonder if there
> is a problem with where it is being compiled...

All the parsing code is in the library, "sensors" itself only queries
for data and print it. So the version of "sensors" shouldn't matter at
all.

Indeed there seems to be a problem at compilation time, but I don't
have any idea on what could cause that much trouble, given that you use
the same version of flex everyone does. Unless your distribution has
some additional patch applied?

> So right now I have sensors 2.10.0 running with either libsensors 2.8.7
> or 2.10.0.  in either case I am getting weird sensors readings....  Most
> voltages read 4.08 V, and the fans and temps are not returning any
> values. 

Could be that your chip isn't properly wired, but I wouldn't trust
libsensors much given the trouble you have with the configuration file
parsing. Also, I suppose that the values reported were correct before
the kernel update? Please provide the output of:
  systool -c hwmon -v

-- 
Jean Delvare

[lm-sensors] Flex Scanner Jammed Problem

[Calabro, Anthony]

No additional patches applied....

~@> systool -c hwmon -v
Error opening class hwmon
~@> 


-----Original Message-----
From: Jean Delvare [mailto:khali at linux-fr.org] 
Sent: Thursday, August 10, 2006 4:43 AM
To: Calabro, Anthony
Cc: LM Sensors
Subject: Re: [lm-sensors] Flex Scanner Jammed Problem

> If I run sensors  v2.10.0 with the libsensors v2.8.7, the parser works

> correctly with the original sensors.conf input file.  I wonder if 
> there is a problem with where it is being compiled...

All the parsing code is in the library, "sensors" itself only queries
for data and print it. So the version of "sensors" shouldn't matter at
all.

Indeed there seems to be a problem at compilation time, but I don't have
any idea on what could cause that much trouble, given that you use the
same version of flex everyone does. Unless your distribution has some
additional patch applied?

> So right now I have sensors 2.10.0 running with either libsensors 
> 2.8.7 or 2.10.0.  in either case I am getting weird sensors 
> readings....  Most voltages read 4.08 V, and the fans and temps are 
> not returning any values.

Could be that your chip isn't properly wired, but I wouldn't trust
libsensors much given the trouble you have with the configuration file
parsing. Also, I suppose that the values reported were correct before
the kernel update? Please provide the output of:
  systool -c hwmon -v

--
Jean Delvare

[lm-sensors] Flex Scanner Jammed Problem

[Jean Delvare]

> No additional patches applied....
> 
> ~@> systool -c hwmon -v
> Error opening class hwmon
> ~@> 

Hm, and what other things fail mysteriously on that machine? ;) I start
suspecting that your machine has specific problems beyond libsensors.

-- 
Jean Delvare

[lm-sensors] Flex Scanner Jammed Problem

[Calabro, Anthony]

Jean, 
	kernel 2.6.9 does not have the class hwmon. 


Anthony W. Calabro

Voice: 703.367.3138 
Email:  anthony.calabro at lmco.com

-----Original Message-----
From: Jean Delvare [mailto:khali at linux-fr.org] 
Sent: Friday, August 11, 2006 8:15 AM
To: Calabro, Anthony
Cc: LM Sensors
Subject: Re: [lm-sensors] Flex Scanner Jammed Problem

> No additional patches applied....
> 
> ~@> systool -c hwmon -v
> Error opening class hwmon
> ~@>

Hm, and what other things fail mysteriously on that machine? ;) I start
suspecting that your machine has specific problems beyond libsensors.

--
Jean Delvare

[lm-sensors] Flex Scanner Jammed Problem

[Calabro, Anthony]

I guess Im going to try to start over with this thread.  I have solved
the Flex Scanner Jammed problem by going back to sensors version 2.9.0.
When using 2.10.0 the best I could do is get label lines to parse
correctly, but I never had any luck with the compute lines.  I also
upgraded my linux kernel from 2.6.9-34 to 2.6.9-42.  In this new version
there is an i2c sensors update.  We are running the newest version of
RedHat Enterprise with AS 4.  Is there any support for the Winbond
83627HG chip, or the nVidia nForce Pro 2200 (CK804)???  

Right now I have sensors up and running using the Winbond 83627HF
driver, and this is giving me incorrect readings.


Are these chips or busses supported right now?  

[lm-sensors] Flex Scanner Jammed Problem

[Jean Delvare]

Anthony,

> > > No additional patches applied....
> > > 
> > > ~@> systool -c hwmon -v
> > > Error opening class hwmon
> > > ~@>
> > 
> > Hm, and what other things fail mysteriously on that machine? ;) I start
> > suspecting that your machine has specific problems beyond libsensors.
>
> kernel 2.6.9 does not have the class hwmon. 

Ah, my bad, I did not remember you were using an old kernel. This
command should be a suitable replacement on 2.6.9:

systool -b i2c -v

-- 
Jean Delvare

[lm-sensors] Flex Scanner Jammed Problem

[Mark M. Hoffman]

Hi:

* Calabro, Anthony <anthony.calabro at lmco.com> [2006-08-22 16:19:55 -0400]:
> I guess Im going to try to start over with this thread.  I have solved
> the Flex Scanner Jammed problem by going back to sensors version 2.9.0.
> When using 2.10.0 the best I could do is get label lines to parse
> correctly, but I never had any luck with the compute lines.  I also

Did you install 2.9.0 from source?  Looking back at the archives, you
actually started with 2.8.7 - it probably came with the distro.

If you were able to install 2.9.0 from source, but not 2.10.0... well
that is very strange.  The scanner didn't change between those versions.

Anyway, if you're still interested in trying to debug the scanner error:
please add the flag '-d' to the last line of the Makefile.  It should
look like this:

 	$(FLEX) -Psensors_yy -t -d $< > $@

Then 'make clean' && 'make' && 'make install'.  That flag will cause the
scanner to make a lot of noise about what it's doing.  Send some results
back to this list and I'll have a look.

> upgraded my linux kernel from 2.6.9-34 to 2.6.9-42.  In this new version
> there is an i2c sensors update.  We are running the newest version of
> RedHat Enterprise with AS 4.  Is there any support for the Winbond
> 83627HG chip, or the nVidia nForce Pro 2200 (CK804)???  
> 
> Right now I have sensors up and running using the Winbond 83627HF
> driver, and this is giving me incorrect readings.
> 
> 
> Are these chips or busses supported right now?  

The Winbond (sensor) chip is supported including access by ISA bus...
so you don't need any other bus driver to get that working.

Regards,

-- 
Mark M. Hoffman
mhoffman at lightlink.com

[lm-sensors] Flex Scanner Jammed Problem

[Jean Delvare]

Hi Anthony, Mark,

> * Calabro, Anthony <anthony.calabro at lmco.com> [2006-08-22 16:19:55 -0400]:
> > I guess Im going to try to start over with this thread.  I have solved
> > the Flex Scanner Jammed problem by going back to sensors version 2.9.0.
> > When using 2.10.0 the best I could do is get label lines to parse
> > correctly, but I never had any luck with the compute lines.  I also
> 
> Did you install 2.9.0 from source?  Looking back at the archives, you
> actually started with 2.8.7 - it probably came with the distro.
> 
> If you were able to install 2.9.0 from source, but not 2.10.0... well
> that is very strange.  The scanner didn't change between those versions.
> 
> Anyway, if you're still interested in trying to debug the scanner error:
> please add the flag '-d' to the last line of the Makefile.  It should
> look like this:
> 
>  	$(FLEX) -Psensors_yy -t -d $< > $@
> 
> Then 'make clean' && 'make' && 'make install'.  That flag will cause the
> scanner to make a lot of noise about what it's doing.  Send some results
> back to this list and I'll have a look.

Another approach would be to perform a bisection. If 2.9.0 actually
works, and 2.10.0 doesn't, then a change must have broken it - even
though I just can't think of any. 2.9.0 is r2809, 2.10.0 is r3256. You
will converge after 11 iterations, should be fast enough.

> > upgraded my linux kernel from 2.6.9-34 to 2.6.9-42.  In this new version
> > there is an i2c sensors update.

What update is this?

-- 
Jean Delvare

[lm-sensors] Flex Scanner Jammed Problem

[Calabro, Anthony]

 

-----Original Message-----
From: Mark M. Hoffman [mailto:mhoffman at lightlink.com] 
Sent: Wednesday, August 23, 2006 7:19 AM
To: Calabro, Anthony
Cc: LM Sensors
Subject: Re: [lm-sensors] Flex Scanner Jammed Problem

Hi:

* Calabro, Anthony <anthony.calabro at lmco.com> [2006-08-22 16:19:55
-0400]:
> I guess Im going to try to start over with this thread.  I have solved

> the Flex Scanner Jammed problem by going back to sensors version
2.9.0.
> When using 2.10.0 the best I could do is get label lines to parse 
> correctly, but I never had any luck with the compute lines.  I also

Did you install 2.9.0 from source?  Looking back at the archives, you
actually started with 2.8.7 - it probably came with the distro.

Yes, I installed it from source.


If you were able to install 2.9.0 from source, but not 2.10.0... well
that is very strange.  The scanner didn't change between those versions.

??

Anyway, if you're still interested in trying to debug the scanner error:
please add the flag '-d' to the last line of the Makefile.  It should
look like this:

 	$(FLEX) -Psensors_yy -t -d $< > $@

Then 'make clean' && 'make' && 'make install'.  That flag will cause the
scanner to make a lot of noise about what it's doing.  Send some results
back to this list and I'll have a look.

I will try this later this afternoon and send the output.

> upgraded my linux kernel from 2.6.9-34 to 2.6.9-42.  In this new 
> version there is an i2c sensors update.  We are running the newest 
> version of RedHat Enterprise with AS 4.  Is there any support for the 
> Winbond 83627HG chip, or the nVidia nForce Pro 2200 (CK804)???
> 
> Right now I have sensors up and running using the Winbond 83627HF 
> driver, and this is giving me incorrect readings.
> 
> 
> Are these chips or busses supported right now?  

The Winbond (sensor) chip is supported including access by ISA bus...
so you don't need any other bus driver to get that working.

The 83627HG uses the same drivers as the 83627HF???


Regards,

--
Mark M. Hoffman
mhoffman at lightlink.com




Ok,  I went into BIOS and read the output of the sensors it is reading,
and compared it with the lm_sensors output.   Below is what BIOS is
reading, and attached is the output of sensors, as well as a few other
programs to give input on what is going on the system, including
sensors-detect, systool, lspci, lsmod.  Please let me know what, if any
other input would be helpful.  I'm going to try to find out how the BIOS
is reading the sensors and maybe ill have a better shot doing it that
way.


BIOS INFO:

CPU1 VCore:			1.19V
CPU2 VCore:			1.19V
CPU1 DIMM Volt:		2.62V
CPU2 DIMM Volt:		2.63V
1.2V Hyper-Transport:	1.21V
1.5V:				1.50V
2.5V:				2.63V
3.3V VCC:			3.44V
3.3V SB:			3.44V
5Vin:				5.10V
12Vin:			12.06V
-12V Vcc:			-12.09V
Vbatt:			3.07V

CPU1:				17 C
CPU2:				0 C
SYS Temp:			25 C

FAN1:				NA (not attached)
FAN2:				~7000
FAN3:				NA (not attached)
FAN4:				6750
FAN5:				NA (not attached)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lsmod.out
Type: application/octet-stream
Size: 1813 bytes
Desc: lsmod.out
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060823/25dfd06c/attachment-0007.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lspci.out
Type: application/octet-stream
Size: 26720 bytes
Desc: lspci.out
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060823/25dfd06c/attachment-0008.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lspci-x.out
Type: application/octet-stream
Size: 8398 bytes
Desc: lspci-x.out
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060823/25dfd06c/attachment-0009.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sensors.out
Type: application/octet-stream
Size: 1203 bytes
Desc: sensors.out
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060823/25dfd06c/attachment-0010.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sensorsblank.out
Type: application/octet-stream
Size: 1203 bytes
Desc: sensorsblank.out
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060823/25dfd06c/attachment-0011.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sensors-detect.out
Type: application/octet-stream
Size: 5593 bytes
Desc: sensors-detect.out
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060823/25dfd06c/attachment-0012.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: systool.out
Type: application/octet-stream
Size: 1934 bytes
Desc: systool.out
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060823/25dfd06c/attachment-0013.obj 

[lm-sensors] Flex Scanner Jammed Problem

[Calabro, Anthony]

Attached is the ouput of sensors -s (2.10.0) with the ocmpile flag '-d'
and also theline %nodefault  commented out of the file lib/conf-lex.l

PS.  Thanks both of you for all of your help and suggestions.  I really
appreciate it.


-----Original Message-----
From: Jean Delvare [mailto:khali at linux-fr.org] 
Sent: Wednesday, August 23, 2006 11:24 AM
To: Mark M. Hoffman; Calabro, Anthony
Cc: LM Sensors
Subject: Re: [lm-sensors] Flex Scanner Jammed Problem

Hi Anthony, Mark,

> * Calabro, Anthony <anthony.calabro at lmco.com> [2006-08-22 16:19:55
-0400]:
> > I guess Im going to try to start over with this thread.  I have 
> > solved the Flex Scanner Jammed problem by going back to sensors
version 2.9.0.
> > When using 2.10.0 the best I could do is get label lines to parse 
> > correctly, but I never had any luck with the compute lines.  I also
> 
> Did you install 2.9.0 from source?  Looking back at the archives, you 
> actually started with 2.8.7 - it probably came with the distro.
> 
> If you were able to install 2.9.0 from source, but not 2.10.0... well 
> that is very strange.  The scanner didn't change between those
versions.
> 
> Anyway, if you're still interested in trying to debug the scanner
error:
> please add the flag '-d' to the last line of the Makefile.  It should 
> look like this:
> 
>  	$(FLEX) -Psensors_yy -t -d $< > $@
> 
> Then 'make clean' && 'make' && 'make install'.  That flag will cause 
> the scanner to make a lot of noise about what it's doing.  Send some 
> results back to this list and I'll have a look.

Another approach would be to perform a bisection. If 2.9.0 actually
works, and 2.10.0 doesn't, then a change must have broken it - even
though I just can't think of any. 2.9.0 is r2809, 2.10.0 is r3256. You
will converge after 11 iterations, should be fast enough.

> > upgraded my linux kernel from 2.6.9-34 to 2.6.9-42.  In this new 
> > version there is an i2c sensors update.

What update is this?

--
Jean Delvare


-------------- next part --------------
A non-text attachment was scrubbed...
Name: sensorsdebug.out
Type: application/octet-stream
Size: 4110 bytes
Desc: sensorsdebug.out
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060823/efebee77/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sensors.conf.temp
Type: application/octet-stream
Size: 189 bytes
Desc: sensors.conf.temp
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20060823/efebee77/attachment-0001.obj 

[lm-sensors] Flex Scanner Jammed Problem

[Calabro, Anthony]

 


Anthony W. Calabro

Voice: 703.367.3138 
Email:  anthony.calabro at lmco.com

-----Original Message-----
From: Jean Delvare [mailto:khali at linux-fr.org] 
Sent: Wednesday, August 23, 2006 11:24 AM
To: Mark M. Hoffman; Calabro, Anthony
Cc: LM Sensors
Subject: Re: [lm-sensors] Flex Scanner Jammed Problem

Hi Anthony, Mark,

> * Calabro, Anthony <anthony.calabro at lmco.com> [2006-08-22 16:19:55
-0400]:
> > I guess Im going to try to start over with this thread.  I have 
> > solved the Flex Scanner Jammed problem by going back to sensors
version 2.9.0.
> > When using 2.10.0 the best I could do is get label lines to parse 
> > correctly, but I never had any luck with the compute lines.  I also
> 
> Did you install 2.9.0 from source?  Looking back at the archives, you 
> actually started with 2.8.7 - it probably came with the distro.
> 
> If you were able to install 2.9.0 from source, but not 2.10.0... well 
> that is very strange.  The scanner didn't change between those
versions.
> 
> Anyway, if you're still interested in trying to debug the scanner
error:
> please add the flag '-d' to the last line of the Makefile.  It should 
> look like this:
> 
>  	$(FLEX) -Psensors_yy -t -d $< > $@
> 
> Then 'make clean' && 'make' && 'make install'.  That flag will cause 
> the scanner to make a lot of noise about what it's doing.  Send some 
> results back to this list and I'll have a look.

Another approach would be to perform a bisection. If 2.9.0 actually
works, and 2.10.0 doesn't, then a change must have broken it - even
though I just can't think of any. 2.9.0 is r2809, 2.10.0 is r3256. You
will converge after 11 iterations, should be fast enough.

> > upgraded my linux kernel from 2.6.9-34 to 2.6.9-42.  In this new 
> > version there is an i2c sensors update.

What update is this?


-- In the change log for kernel 2.6.9-42 from redhat enterprise, it
says:
2006-05-02 22:00:00 
Jason Baron <jbaron at redhat.com> [2.6.9-35]: 
-revert: fix hanging serial console
-Introduce netpoll over bonded interfaces (Thomas Graf)
-fix USB error handling (Kimball Murray) [189279]
-qla2xxx update v. 8.01.04-d7 (Mike Christie) [188912]
-Fix coredump vs exec deadlock (David Howells) [168112]
*****-add i2c sensors drivers (Eric Paris) [171507]*****
-s390: fix sysrq backtrace oops (Jan Glauber) [185736]
-s390: fix crypto driver memory overwrite (Jan Glauber)
-s390: lcs driver fixes (Jan Glauber)
-add hpet_period finetuning to allow correction of hpet drift (Brian
Maly) [169876]
-bonding updates (Thomas Graf) [180431]
-Add MSI/MSI-X support to cciss (Tom Coughlan) [179860]
-add modern_apic() tests (Jim Paradis) [166885]
-SUNRPC: rpcbind should retry if server's portmapper becomes unavailable
(Steve Dickson) [172082]
-device-mapper mirroring: error on log failure override (Jonathan
Brassow)
-make aic7xxx and aic79xx Drivers Support 16-byte CDBs (Chip Coldwell)
-fix ipmi driver broken on HP Integrity platform (Brian Maly) [174986]
-fix mmap wastes too much virtual address space for 32-bit environment
(Larry Woodman) [173662]
-IPMI: Resolve startup race condition (Peter Martuccelli) [189390]
-ati sb600 support (John Linville) [189844]
-Emulex lpfc/lpfcdfc drivers re-organizations (Chip Coldwell) [179752]

-- I tried to research the bug from redhat but didn't have the right
access.



--
Jean Delvare

[lm-sensors] Flex Scanner Jammed Problem

[Mark M. Hoffman]

Hi Anthony:

* Calabro, Anthony <anthony.calabro at lmco.com> [2006-08-23 13:46:24 -0400]:
> Attached is the ouput of sensors -s (2.10.0) with the ocmpile flag '-d'
> and also theline %nodefault  commented out of the file lib/conf-lex.l

Here is some of the output from your attachment...

> --(end of buffer or a NUL)
> --accepting rule at line 122 ("chip")
> --accepting default rule (" ")

It missed the rule at line 88, which refrences "[[:space:]]".  In flex, this
is called a character class expression.  It means any character for which the
standard C library function isspace(3) returns true.

> --accepting rule at line 189 (""")
> --accepting rule at line 257 ("w83782d-*")
> --accepting rule at line 205 (""")
> --accepting default rule (" ")

Missed rule 88 again.

> --accepting rule at line 189 (""")
> --accepting rule at line 257 ("w83627hf-*")
> --accepting rule at line 205 (""")
> --accepting rule at line 80 ("
> ")
> --accepting default rule ("
> ")
> --accepting rule at line 98 ("label")
> --accepting default rule (" ")

Missed rule 88 again.

> --accepting default rule ("i")
> --accepting default rule ("n")
> --accepting default rule ("0")

Here, it missed the rule at line 262 which references "[[:alnum:]]".  This
corresponds to the standard C library function isalnum(3).  Hmmm...

You said before that if you quote the identifiers, the scanner will accept
them.  That further points to the character class expressions being somehow
broken because the rules for *inside* the quotes do not use them.

I'm going to guess that you are having some bad interaction with the standard
C library.  I'm not sure how that's possible, especially if you can compile
and use lm-sensors 2.9.0 without problems.  Did you compile the two versions
on two different machines?  I think the character class expressions are
resolved during compile time / scanner generation, i.e. from *.l -> *.c.

I don't know what else to suggest.  This much is certain: given the output
you attached, something is getting miscompiled or corrupted when you build
2.10.0.  As unlikely as that may sound, nothing else makes sense.

Regards,

-- 
Mark M. Hoffman
mhoffman at lightlink.com

[lm-sensors] Flex Scanner Jammed Problem

[Jean Delvare]

Anthony,

> > The Winbond (sensor) chip is supported including access by ISA bus...
> > so you don't need any other bus driver to get that working.
> 
> The 83627HG uses the same drivers as the 83627HF???

Yes. The "HG" variant is lead-free, but otherwise it's the same chip.

> Ok,  I went into BIOS and read the output of the sensors it is reading,
> and compared it with the lm_sensors output.   Below is what BIOS is
> reading, and attached is the output of sensors, as well as a few other
> programs to give input on what is going on the system, including
> sensors-detect, systool, lspci, lsmod.  Please let me know what, if any
> other input would be helpful.  I'm going to try to find out how the BIOS
> is reading the sensors and maybe ill have a better shot doing it that
> way.

Can you please set the MIME type properly for text attachements next
time?

> BIOS INFO:
> 
> CPU1 VCore:			1.19V
> CPU2 VCore:			1.19V
> CPU1 DIMM Volt:		2.62V
> CPU2 DIMM Volt:		2.63V
> 1.2V Hyper-Transport:	1.21V
> 1.5V:				1.50V
> 2.5V:				2.63V
> 3.3V VCC:			3.44V
> 3.3V SB:			3.44V
> 5Vin:				5.10V
> 12Vin:			12.06V
> -12V Vcc:			-12.09V
> Vbatt:			3.07V
> 
> CPU1:				17 C
> CPU2:				0 C
> SYS Temp:			25 C
> 
> FAN1:				NA (not attached)
> FAN2:				~7000
> FAN3:				NA (not attached)
> FAN4:				6750
> FAN5:				NA (not attached)

13 voltage inputs and 5 fan inputs, while the W83627HF/HG has only 9
and 3, respectively. This suggests that there is a second hardware
monitoring on your motherboard, most probably connected to the SMBus.

> 00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)

This is your SMBus. Support was added to the i2c-nforce2 driver in
2.6.12. I think you said you were running 2.6.9, so no surprise it
doesn't work.

You may load i2c-nforce2 manually, then run the following command:
echo "10de 0052" > /sys/bus/pci/drivers/nForce2_smbus/new_id

This should enable the SMBus. If it works, you'll have to do the same
after each reboot. Then you can run sensors-detect again and hopefully
it will find some other chip. I suggest running the most recent version
of sensors-detect, else it'll miss recent chips.

BTW I notice that this system is completely different from the one you
reported for in the first place. The original one was Intel-based and
this one is nVidia-based. Please make separate threads for separate
issues, else it is very difficult for us to keep track of everything at
once.

What motherboard is this?

-- 
Jean Delvare

[lm-sensors] Flex Scanner Jammed Problem

[Jean Delvare]

Anthony,

> > What update is this?
> 
> 
> -- In the change log for kernel 2.6.9-42 from redhat enterprise, it
> says:
> 2006-05-02 22:00:00 
> Jason Baron <jbaron at redhat.com> [2.6.9-35]: 
> -revert: fix hanging serial console
> -Introduce netpoll over bonded interfaces (Thomas Graf)
> -fix USB error handling (Kimball Murray) [189279]
> -qla2xxx update v. 8.01.04-d7 (Mike Christie) [188912]
> -Fix coredump vs exec deadlock (David Howells) [168112]
> *****-add i2c sensors drivers (Eric Paris) [171507]*****
> -s390: fix sysrq backtrace oops (Jan Glauber) [185736]
> -s390: fix crypto driver memory overwrite (Jan Glauber)
> -s390: lcs driver fixes (Jan Glauber)
> -add hpet_period finetuning to allow correction of hpet drift (Brian
> Maly) [169876]
> -bonding updates (Thomas Graf) [180431]
> -Add MSI/MSI-X support to cciss (Tom Coughlan) [179860]
> -add modern_apic() tests (Jim Paradis) [166885]
> -SUNRPC: rpcbind should retry if server's portmapper becomes unavailable
> (Steve Dickson) [172082]
> -device-mapper mirroring: error on log failure override (Jonathan
> Brassow)
> -make aic7xxx and aic79xx Drivers Support 16-byte CDBs (Chip Coldwell)
> -fix ipmi driver broken on HP Integrity platform (Brian Maly) [174986]
> -fix mmap wastes too much virtual address space for 32-bit environment
> (Larry Woodman) [173662]
> -IPMI: Resolve startup race condition (Peter Martuccelli) [189390]
> -ati sb600 support (John Linville) [189844]
> -Emulex lpfc/lpfcdfc drivers re-organizations (Chip Coldwell) [179752]
> 
> -- I tried to research the bug from redhat but didn't have the right
> access.

I asked for access, that may or may not be accepted.

Anyway, I was asking out of curiousity. It certainly has nothing to do
with your current problems.

-- 
Jean Delvare

[lm-sensors] Flex Scanner Jammed Problem

[Calabro, Anthony]

Jean,

-----Original Message-----
From: Jean Delvare [mailto:khali at linux-fr.org] 
Sent: Thursday, August 24, 2006 3:49 AM
To: Calabro, Anthony
Cc: Mark M. Hoffman; LM Sensors
Subject: Re: [lm-sensors] Flex Scanner Jammed Problem

Anthony,

> > The Winbond (sensor) chip is supported including access by ISA bus...
> > so you don't need any other bus driver to get that working.
> 
> The 83627HG uses the same drivers as the 83627HF???

Yes. The "HG" variant is lead-free, but otherwise it's the same chip.

> Ok,  I went into BIOS and read the output of the sensors it is reading,
> and compared it with the lm_sensors output.   Below is what BIOS is
> reading, and attached is the output of sensors, as well as a few other 
> programs to give input on what is going on the system, including 
> sensors-detect, systool, lspci, lsmod.  Please let me know what, if 
> any other input would be helpful.  I'm going to try to find out how 
> the BIOS is reading the sensors and maybe ill have a better shot doing 
> it that way.

Can you please set the MIME type properly for text attachements next time?

> BIOS INFO:
> 
> CPU1 VCore:			1.19V
> CPU2 VCore:			1.19V
> CPU1 DIMM Volt:		2.62V
> CPU2 DIMM Volt:		2.63V
> 1.2V Hyper-Transport:	1.21V
> 1.5V:				1.50V
> 2.5V:				2.63V
> 3.3V VCC:			3.44V
> 3.3V SB:			3.44V
> 5Vin:				5.10V
> 12Vin:			12.06V
> -12V Vcc:			-12.09V
> Vbatt:			3.07V
> 
> CPU1:				17 C
> CPU2:				0 C
> SYS Temp:			25 C
> 
> FAN1:				NA (not attached)
> FAN2:				~7000
> FAN3:				NA (not attached)
> FAN4:				6750
> FAN5:				NA (not attached)

13 voltage inputs and 5 fan inputs, while the W83627HF/HG has only 9 and 3, respectively. This suggests that there is a second hardware monitoring on your motherboard, most probably connected to the SMBus.

> 00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)

This is your SMBus. Support was added to the i2c-nforce2 driver in 2.6.12. I think you said you were running 2.6.9, so no surprise it doesn't work.

You may load i2c-nforce2 manually, then run the following command:
echo "10de 0052" > /sys/bus/pci/drivers/nForce2_smbus/new_id

This should enable the SMBus. If it works, you'll have to do the same after each reboot. Then you can run sensors-detect again and hopefully it will find some other chip. I suggest running the most recent version of sensors-detect, else it'll miss recent chips.

** I think we're getting somewhere.  I ran sensors-detect and got the nForce2 driver loaded, and then wrote the line into the driver.  Then ran sensors-detect again and it found a lot more sensors information.  In the end I loaded eeprom and adm1026,  on the adm1026 is all the correct values I am looking for.  Well, mostly, but in different places.  Now all I have to do is figure out which values are what and how they are ordered.  

Below is the new sensors output:

adm1026-i2c-2-2c
Adapter: SMBus nForce2 adapter at 4c40
in0:       +1.30 V  (min =  +2.25 V, max =  +2.75 V)   ALARM
in1:       +1.30 V  (min =  +1.49 V, max =  +1.82 V)   ALARM
in2:       +1.50 V  (min =  +1.35 V, max =  +1.65 V)   
in3:       +2.64 V  (min =  +2.16 V, max =  +2.86 V)   
in4:       +2.62 V  (min =  +2.34 V, max =  +2.86 V)   
in5:       +0.00 V  (min =  +1.22 V, max =  +2.02 V)   ALARM
in6:       +1.21 V  (min =  +1.08 V, max =  +1.32 V)   
in7:       +1.19 V  (min =  +1.02 V, max =  +1.68 V)   
in8:       +0.00 V  (min =  +0.00 V, max =  +2.49 V)   
in9:       +0.16 V  (min =  +0.00 V, max =  +0.70 V)   
in10:      +3.06 V  (min =  +2.70 V, max =  +3.30 V)   
in11:      +3.40 V  (min =  +2.97 V, max =  +3.64 V)   
in12:      +3.40 V  (min =  +2.97 V, max =  +3.64 V)   
in13:      +5.10 V  (min =  +4.50 V, max =  +5.49 V)   
in14:      +1.19 V  (min =  +1.02 V, max =  +1.68 V)   
in15:     +12.06 V  (min = +10.81 V, max = +13.19 V)   
in16:     -12.10 V  (min = -13.18 V, max = -10.80 V)   
ERROR: Can't get FAN0 data!
fan1:        0 RPM  (min =    0 RPM, div = 8)   
fan2:     6750 RPM  (min =    0 RPM, div = 8)   
fan3:        0 RPM  (min =    0 RPM, div = 8)   
fan4:     7031 RPM  (min =    0 RPM, div = 8)   
fan5:        0 RPM  (min =    0 RPM, div = 8)   
fan6:        0 RPM  (min =    0 RPM, div = 8)   
fan7:        0 RPM  (min =    0 RPM, div = 8)   
temp1:       +24??C  (low  =    +0??C, high =   +72??C)  
temp2:        -1??C  (low  =    +0??C, high =   +72??C)     ALARM
temp3:       +16??C  (low  =    +0??C, high =   +72??C)  
vid:      +1.175 V  (VRM Version 2.4)

A few of the values are obvious, but others are not.  Is there any way to find out which inputs are designated as which values?


BTW I notice that this system is completely different from the one you reported for in the first place. The original one was Intel-based and this one is nVidia-based. Please make separate threads for separate issues, else it is very difficult for us to keep track of everything at once.

What motherboard is this?

***  Sorry, Im actually working on 3 or 4 different motherboards right now, all having similar problems, most of them are nVidia AMD based, but a couple are Intel Based.  The one ive been doing most of my testing on is:  http://www.supermicro.com/Aplus/motherboard/Opteron/nForce/H8DCR-3.cfm

It looks like we're very close.  Thanks for all your help...


--
Jean Delvare

[lm-sensors] Flex Scanner Jammed Problem

[Calabro, Anthony]

Jean,
	Apparently one of the updates has to do with the hwmon class,
because not it does exist, with the adm1026 driver attached to it.  
 

-----Original Message-----
From: Jean Delvare [mailto:khali at linux-fr.org] 
Sent: Thursday, August 24, 2006 10:52 AM
To: Calabro, Anthony
Cc: LM Sensors; Mark M. Hoffman
Subject: Re: [lm-sensors] Flex Scanner Jammed Problem

Anthony,

> > What update is this?
> 
> 
> -- In the change log for kernel 2.6.9-42 from redhat enterprise, it
> says:
> 2006-05-02 22:00:00
> Jason Baron <jbaron at redhat.com> [2.6.9-35]: 
> -revert: fix hanging serial console
> -Introduce netpoll over bonded interfaces (Thomas Graf) -fix USB error

> handling (Kimball Murray) [189279] -qla2xxx update v. 8.01.04-d7 (Mike

> Christie) [188912] -Fix coredump vs exec deadlock (David Howells) 
> [168112] *****-add i2c sensors drivers (Eric Paris) [171507]*****
> -s390: fix sysrq backtrace oops (Jan Glauber) [185736]
> -s390: fix crypto driver memory overwrite (Jan Glauber)
> -s390: lcs driver fixes (Jan Glauber)
> -add hpet_period finetuning to allow correction of hpet drift (Brian
> Maly) [169876]
> -bonding updates (Thomas Graf) [180431] -Add MSI/MSI-X support to 
> cciss (Tom Coughlan) [179860] -add modern_apic() tests (Jim Paradis) 
> [166885]
> -SUNRPC: rpcbind should retry if server's portmapper becomes 
> unavailable (Steve Dickson) [172082] -device-mapper mirroring: error 
> on log failure override (Jonathan
> Brassow)
> -make aic7xxx and aic79xx Drivers Support 16-byte CDBs (Chip Coldwell)

> -fix ipmi driver broken on HP Integrity platform (Brian Maly) [174986]

> -fix mmap wastes too much virtual address space for 32-bit environment

> (Larry Woodman) [173662]
> -IPMI: Resolve startup race condition (Peter Martuccelli) [189390] 
> -ati sb600 support (John Linville) [189844] -Emulex lpfc/lpfcdfc 
> drivers re-organizations (Chip Coldwell) [179752]
> 
> -- I tried to research the bug from redhat but didn't have the right 
> access.

I asked for access, that may or may not be accepted.

Anyway, I was asking out of curiousity. It certainly has nothing to do
with your current problems.

--
Jean Delvare

[lm-sensors] Flex Scanner Jammed Problem

[Jean Delvare]

Anthony,

> 	Apparently one of the updates has to do with the hwmon class,
> because not it does exist, with the adm1026 driver attached to it.  

I have access now and I can confirm that, the update adds the adm1026
and lm87 drivers, backported from a later kernel. It adds the hwmon
class as a side effect, because the later kernel had it so the adm1026
and lm87 driver used it.

-- 
Jean Delvare

[lm-sensors] Flex Scanner Jammed Problem

[Jean Delvare]

> Below is the new sensors output:
> 
> adm1026-i2c-2-2c
> Adapter: SMBus nForce2 adapter at 4c40
> in0:       +1.30 V  (min =  +2.25 V, max =  +2.75 V)   ALARM
> in1:       +1.30 V  (min =  +1.49 V, max =  +1.82 V)   ALARM
> in2:       +1.50 V  (min =  +1.35 V, max =  +1.65 V)   
> in3:       +2.64 V  (min =  +2.16 V, max =  +2.86 V)   
> in4:       +2.62 V  (min =  +2.34 V, max =  +2.86 V)   
> in5:       +0.00 V  (min =  +1.22 V, max =  +2.02 V)   ALARM
> in6:       +1.21 V  (min =  +1.08 V, max =  +1.32 V)   
> in7:       +1.19 V  (min =  +1.02 V, max =  +1.68 V)   
> in8:       +0.00 V  (min =  +0.00 V, max =  +2.49 V)   
> in9:       +0.16 V  (min =  +0.00 V, max =  +0.70 V)   
> in10:      +3.06 V  (min =  +2.70 V, max =  +3.30 V)   
> in11:      +3.40 V  (min =  +2.97 V, max =  +3.64 V)   
> in12:      +3.40 V  (min =  +2.97 V, max =  +3.64 V)   
> in13:      +5.10 V  (min =  +4.50 V, max =  +5.49 V)   
> in14:      +1.19 V  (min =  +1.02 V, max =  +1.68 V)   
> in15:     +12.06 V  (min = +10.81 V, max = +13.19 V)   
> in16:     -12.10 V  (min = -13.18 V, max = -10.80 V)   
> ERROR: Can't get FAN0 data!
> fan1:        0 RPM  (min =    0 RPM, div = 8)   
> fan2:     6750 RPM  (min =    0 RPM, div = 8)   
> fan3:        0 RPM  (min =    0 RPM, div = 8)   
> fan4:     7031 RPM  (min =    0 RPM, div = 8)   
> fan5:        0 RPM  (min =    0 RPM, div = 8)   
> fan6:        0 RPM  (min =    0 RPM, div = 8)   
> fan7:        0 RPM  (min =    0 RPM, div = 8)   
> temp1:       +24?C  (low  =    +0?C, high =   +72?C)  
> temp2:        -1?C  (low  =    +0?C, high =   +72?C)     ALARM
> temp3:       +16?C  (low  =    +0?C, high =   +72?C)  
> vid:      +1.175 V  (VRM Version 2.4)

OK, so it mostly works now. The error on FAN0 can be explained by the
fact that the 2.4 driver (and thus libsensors) numbered fans from 0 to
7 while the 2.6 driver numbers them the standard way (1 to 8). It's odd
that nobody ever complained about that...

I've just fixed it in lm_sensors SVN.

temp3 is a bit too cold to be real, unless the system is heavily
air-conditioned.

> A few of the values are obvious, but others are not.  Is there
> any way to find out which inputs are designated as which values?

Ask the system/motherboard vendor?

If the BIOS displays hardware monitoring data, you can use that as a
target for where the sensors output should look like.

-- 
Jean Delvare