1250

1250

[David]

ls -l /proc/sys/dev/sensors
total 0
-rw-r--r--    1 root     root            0 Jun  2 10:05 chips
dr-xr-xr-x    2 root     root            0 Jun  2 09:49 via686a-isa-6000

ls -l /proc/sys/dev/sensors/via*
total 0
-r--r--r--    1 root     root            0 Jun  2 10:06 alarms
-rw-r--r--    1 root     root            0 Jun  2 10:06 fan1
-rw-r--r--    1 root     root            0 Jun  2 10:06 fan2
-rw-r--r--    1 root     root            0 Jun  2 10:06 fan_div
-rw-r--r--    1 root     root            0 Jun  2 10:06 in0
-rw-r--r--    1 root     root            0 Jun  2 10:06 in1
-rw-r--r--    1 root     root            0 Jun  2 10:06 in2
-rw-r--r--    1 root     root            0 Jun  2 10:06 in3
-rw-r--r--    1 root     root            0 Jun  2 10:06 in4
-rw-r--r--    1 root     root            0 Jun  2 10:06 temp1
-rw-r--r--    1 root     root            0 Jun  2 10:06 temp2
-rw-r--r--    1 root     root            0 Jun  2 10:06 temp3

But even when I change the via686a-isa-6000 folder to have root write 
permissions it doesn't work.

ls -l /proc/sys/dev/sensors
total 0
-rw-r--r--    1 root     root            0 Jun  2 10:07 chips
drwxr-xr-x    2 root     root            0 Jun  2 09:49 via686a-isa-6000

So still get: 
sensors -s
via686a-isa-6000: Can't access /proc file for writing;
Run as root?

I don't think the permission is staying either. Would devfs have something to 
do with this?

1250

[Mark D. Studebaker]

devfs could be it. no other good ideas at the moment.

David wrote:
> ls -l /proc/sys/dev/sensors
> total 0
> -rw-r--r--    1 root     root            0 Jun  2 10:05 chips
> dr-xr-xr-x    2 root     root            0 Jun  2 09:49 via686a-isa-6000
> 
> ls -l /proc/sys/dev/sensors/via*
> total 0
> -r--r--r--    1 root     root            0 Jun  2 10:06 alarms
> -rw-r--r--    1 root     root            0 Jun  2 10:06 fan1
> -rw-r--r--    1 root     root            0 Jun  2 10:06 fan2
> -rw-r--r--    1 root     root            0 Jun  2 10:06 fan_div
> -rw-r--r--    1 root     root            0 Jun  2 10:06 in0
> -rw-r--r--    1 root     root            0 Jun  2 10:06 in1
> -rw-r--r--    1 root     root            0 Jun  2 10:06 in2
> -rw-r--r--    1 root     root            0 Jun  2 10:06 in3
> -rw-r--r--    1 root     root            0 Jun  2 10:06 in4
> -rw-r--r--    1 root     root            0 Jun  2 10:06 temp1
> -rw-r--r--    1 root     root            0 Jun  2 10:06 temp2
> -rw-r--r--    1 root     root            0 Jun  2 10:06 temp3
> 
> But even when I change the via686a-isa-6000 folder to have root write 
> permissions it doesn't work.
> 
> ls -l /proc/sys/dev/sensors
> total 0
> -rw-r--r--    1 root     root            0 Jun  2 10:07 chips
> drwxr-xr-x    2 root     root            0 Jun  2 09:49 via686a-isa-6000
> 
> So still get: 
> sensors -s
> via686a-isa-6000: Can't access /proc file for writing;
> Run as root?
> 
> I don't think the permission is staying either. Would devfs have something to 
> do with this?
> 

1250

[Philip Pokorny]

You shouldn't actually need write permissions to the directory since 
user-space won't be creating or deleteing files in via686a-isa-6000...

And all the individual files have the right permisions...

David, what OS are you running on?  I had a similar problem on SuSE 
Linux 8 for 64-bit Opteron that was caused by sensors_proc_write having 
it's data violated by some other code...

Can you run 'strace -o sensors.strace sensors -s' and post the last 20 
or 30 lines of the sensors.strace file?.  I'm looking for pairs of calls 
to sysctl where the first works and the second has a strange (???) entry 
in the first argument to sysctl.

If so, I've got a patch that you can try...

:v)

Mark D. Studebaker wrote:
> devfs could be it. no other good ideas at the moment.
> 
> David wrote:
> 
>> ls -l /proc/sys/dev/sensors
>> total 0
>> -rw-r--r--    1 root     root            0 Jun  2 10:05 chips
>> dr-xr-xr-x    2 root     root            0 Jun  2 09:49 via686a-isa-6000
>>
>> ls -l /proc/sys/dev/sensors/via*
>> total 0
>> -r--r--r--    1 root     root            0 Jun  2 10:06 alarms
>> -rw-r--r--    1 root     root            0 Jun  2 10:06 fan1
>> -rw-r--r--    1 root     root            0 Jun  2 10:06 fan2
>> -rw-r--r--    1 root     root            0 Jun  2 10:06 fan_div
>> -rw-r--r--    1 root     root            0 Jun  2 10:06 in0
>> -rw-r--r--    1 root     root            0 Jun  2 10:06 in1
>> -rw-r--r--    1 root     root            0 Jun  2 10:06 in2
>> -rw-r--r--    1 root     root            0 Jun  2 10:06 in3
>> -rw-r--r--    1 root     root            0 Jun  2 10:06 in4
>> -rw-r--r--    1 root     root            0 Jun  2 10:06 temp1
>> -rw-r--r--    1 root     root            0 Jun  2 10:06 temp2
>> -rw-r--r--    1 root     root            0 Jun  2 10:06 temp3
>>
>> But even when I change the via686a-isa-6000 folder to have root write 
>> permissions it doesn't work.
>>
>> ls -l /proc/sys/dev/sensors
>> total 0
>> -rw-r--r--    1 root     root            0 Jun  2 10:07 chips
>> drwxr-xr-x    2 root     root            0 Jun  2 09:49 via686a-isa-6000
>>
>> So still get: sensors -s
>> via686a-isa-6000: Can't access /proc file for writing;
>> Run as root?
>>
>> I don't think the permission is staying either. Would devfs have 
>> something to do with this?
>>
> 



-- 
Philip Pokorny, Director of Engineering
Tel: 415-358-2635   Fax: 415-358-2646   Toll Free: 888-PENGUIN
PENGUIN COMPUTING, INC.
www.penguincomputing.com

1250

[Philip Pokorny]

The magic is in the 'sensors.strace' file that should have been created.

 >> and post the last 20
 >> or 30 lines of the sensors.strace file?.  I'm looking for pairs of
 >> calls to sysctl where the first works and the second has a strange
 >> (???) entry in the first argument to sysctl.

At this point it *does* look like the same problem I had on SuSE...

I've attached the one-line fix...

:v)

David wrote:
> Didn't even get very far to even provide you with useful information. Here are 
> the results though. 
> By the way I am running Gentoo Linux, with gentoo-sources kernel 
> (2.4.20-gentoo-r5)
> 
> The results are:
> 
>>strace -o sensors.strace sensors -s
> 
> 
> ptrace: umoven: Input/output error
> ptrace: umoven: Input/output error
> ptrace: umoven: Input/output error
> ptrace: umoven: Input/output error
> ptrace: umoven: Input/output error
> ptrace: umoven: Input/output error
> ptrace: umoven: Input/output error
> ptrace: umoven: Input/output error
> ptrace: umoven: Input/output error
> via686a-isa-6000: Can't access /proc file for writing;
> Run as root?
> 
> That is as far as it got. Sorry. Thanks for the help.
> 
> Dave
> 
> 
> On Monday 02 June 2003 08:56 pm, you wrote:
> 
>>You shouldn't actually need write permissions to the directory since
>>user-space won't be creating or deleteing files in via686a-isa-6000...
>>
>>And all the individual files have the right permisions...
>>
>>David, what OS are you running on?  I had a similar problem on SuSE
>>Linux 8 for 64-bit Opteron that was caused by sensors_proc_write having
>>it's data violated by some other code...
>>
>>Can you run 'strace -o sensors.strace sensors -s' and post the last 20
>>or 30 lines of the sensors.strace file?.  I'm looking for pairs of calls
>>to sysctl where the first works and the second has a strange (???) entry
>>in the first argument to sysctl.
>>
>>If so, I've got a patch that you can try...
>>
>>:v)
>>
>>Mark D. Studebaker wrote:
>>
>>>devfs could be it. no other good ideas at the moment.
>>>
>>>David wrote:
>>>
>>>>ls -l /proc/sys/dev/sensors
>>>>total 0
>>>>-rw-r--r--    1 root     root            0 Jun  2 10:05 chips
>>>>dr-xr-xr-x    2 root     root            0 Jun  2 09:49 via686a-isa-6000
>>>>
>>>>ls -l /proc/sys/dev/sensors/via*
>>>>total 0
>>>>-r--r--r--    1 root     root            0 Jun  2 10:06 alarms
>>>>-rw-r--r--    1 root     root            0 Jun  2 10:06 fan1
>>>>-rw-r--r--    1 root     root            0 Jun  2 10:06 fan2
>>>>-rw-r--r--    1 root     root            0 Jun  2 10:06 fan_div
>>>>-rw-r--r--    1 root     root            0 Jun  2 10:06 in0
>>>>-rw-r--r--    1 root     root            0 Jun  2 10:06 in1
>>>>-rw-r--r--    1 root     root            0 Jun  2 10:06 in2
>>>>-rw-r--r--    1 root     root            0 Jun  2 10:06 in3
>>>>-rw-r--r--    1 root     root            0 Jun  2 10:06 in4
>>>>-rw-r--r--    1 root     root            0 Jun  2 10:06 temp1
>>>>-rw-r--r--    1 root     root            0 Jun  2 10:06 temp2
>>>>-rw-r--r--    1 root     root            0 Jun  2 10:06 temp3
>>>>
>>>>But even when I change the via686a-isa-6000 folder to have root write
>>>>permissions it doesn't work.
>>>>
>>>>ls -l /proc/sys/dev/sensors
>>>>total 0
>>>>-rw-r--r--    1 root     root            0 Jun  2 10:07 chips
>>>>drwxr-xr-x    2 root     root            0 Jun  2 09:49 via686a-isa-6000
>>>>
>>>>So still get: sensors -s
>>>>via686a-isa-6000: Can't access /proc file for writing;
>>>>Run as root?
>>>>
>>>>I don't think the permission is staying either. Would devfs have
>>>>something to do with this?
>>>
> 



-- 
Philip Pokorny, Director of Engineering
Tel: 415-358-2635   Fax: 415-358-2646   Toll Free: 888-PENGUIN
PENGUIN COMPUTING, INC.
www.penguincomputing.com
-------------- next part --------------
diff -ru --new-file ../_relion1x/lm_sensors-2.7.0/lib/proc.c lm_sensors-2.7.0.adm1026/lib/proc.c
--- ../_relion1x/lm_sensors-2.7.0/lib/proc.c	Sun Nov 10 15:13:38 2002
+++ lm_sensors-2.7.0.adm1026/lib/proc.c	Wed May 28 14:04:25 2003
@@ -184,6 +184,7 @@
   sysctl_name[3] = the_feature->sysctl;
   if (sysctl(sysctl_name, 4, buf, &buflen, NULL, 0))
     return -SENSORS_ERR_PROC;
+  if (sysctl_name[0] != CTL_DEV) { sysctl_name[0] = CTL_DEV ; }
   for (mag = the_feature->scaling; mag > 0; mag --)
     value *= 10.0;
   for (; mag < 0; mag ++)

1250

[Philip Pokorny]

I don't know why you're having so much trouble...

It should be this simple:

[ppokorny@ppokorny sysctl_test]$ ls -l
total 716
-rw-r--r--    1    122846 Jun  4 09:21 i2c-2.7.0.tar.gz
-rw-rw-r--    1       543 Jun  4 09:12 lm_sensors-2.7.0-sysctl-1.patch
-rw-rw-r--    1    595379 Jun  4 09:12 lm_sensors-2.7.0.tar.gz
[sysctl_test]$ tar zxf i2c-2.7.0.tar.gz
[sysctl_test]$ cd i2c-2.7.0
[i2c-2.7.0]$ make
[i2c-2.7.0]$ ln -s kernel linux
[i2c-2.7.0]$ cd ..
[sysctl_test]$ tar zxf lm_sensors-2.7.0.tar.gz
[sysctl_test]$ cd lm_sensors-2.7.0
[lm_sensors-2.7.0]$ patch -p1 < ../lm_sensors-2.7.0-sysctl-1.patch
patching file lib/proc.c
[lm_sensors-2.7.0]$ make I2C_HEADERS=../i2c-2.7.0

Have you opened or edited the patch on a DOS system?  Perhaps the patch 
I sent you has been corrupted in transit or on it's way to your system.

As you see above, the patch applies without any complaints if you CD to 
the lm_sensors-2.7.0 directory and specify '-p1' to the patch command.

Best of luck,
:v)

David wrote:
> Got the tar file for the lm_sensors-2.7.0 and extracted it.
> Have no idea where or what makes libsensors.so so did a grep for
> parts of the patch. The closest match is the /lib/proc.c file.
> I wasn't sure how to change the header, but luckily the patch program
> asked me what I wanted to patch. Still nogo though.
> 
> I would assume that the patch looks for matching lines and patches the + line in there.
> Grep results showed that two lines it was looking for are not in any file (proc.c either)
> 
> sysctl_name[3] = the_feature->sysctl;
> and
> value *= 10.0;
> 
> The rest were all in /lib/proc.c  and one was in /lib/access.c  .  So the obvious 
> prospect from my limited knowledge was to patch /lib/proc.c  
> 
> Results:
> 
> File to patch: lib/proc.c
> Patching file lib/proc.c using Plan A...
> patch: **** malformed patch at line 4:    sysctl_name[3] = the_feature->sysctl;
> 
> Well, maybe my obvious idea didn't work. I removed those line and tried it just to see and 
> it said the same thing about the + line to add.
> 
> Well, thanks for the help. I don't want to waste your time with this, I'm sure you have better things
> to do.  I had some other guy write me wondering if anything was going on with this cause he has the 
> same problem.  If your bored then you might want to sink your teeth in further, otherwise Thanks. 
> Lm_sensors still works, just can't set anything.
> 
> Dave
> 
> On Tuesday 03 June 2003 05:40 pm, you wrote:
> 
>>The file you need to patch is part of the userspace library
>>/lib/libsensors.so
>>
>>If you had the lm_sensors.2.6.5 or lm_sensors-2.7.0 sources, you'd have
>>what you need.  _relion1x is a Penguin Computing product and happens to
>>be the directory where I had the original sources for the diff.
>>
>>Try and find the sources for the user space utilities (sensors,
>>sensors-detect, libsensors).  That's what you need to patch, not the
>>kernel...
>>
>>:v)
>>
>>David wrote:
>>
>>>Well nogo. Found the ebuild for lm_sensors-2.7.0 and installed it.
>>>Copied the patch to /usr/src/linux
>>>Tried to apply the patch
>>>
>>>patch -p1 < lm_sensors-2.7.0-sysctl-1.patch
>>>
>>>but all I got was:
>>>******************
>>>can't find file to patch at input line 4
>>>Perhaps you used the wrong -p or --strip option?
>>>The text leading up to this was:
>>>--------------------------
>>>
>>>|diff -ru --new-file ../_relion1x/lm_sensors-2.7.0/lib/proc.c
>>>
>>>lm_sensors-2.7.0.adm1026/lib/proc.c
>>>
>>>|--- ../_relion1x/lm_sensors-2.7.0/lib/proc.c    Sun Nov 10 15:13:38 2002
>>>|+++ lm_sensors-2.7.0.adm1026/lib/proc.c Wed May 28 14:04:25 2003
>>>
>>>******************
>>>
>>>Tried to locate a 'relion' ..... but was unable to find it. So not sure
>>>what it needs to patch. Hmmm.
>>>
>>>Guess I backed up the src for nothing.
>>>
>>>Thanks again,
>>>Dave
>>>
>>>On Tuesday 03 June 2003 03:00 pm, you wrote:
>>>
>>>>The magic is in the 'sensors.strace' file that should have been created.
>>>>
>>>>
>>>>>>and post the last 20
>>>>>>or 30 lines of the sensors.strace file?.  I'm looking for pairs of
>>>>>>calls to sysctl where the first works and the second has a strange
>>>>>>(???) entry in the first argument to sysctl.
>>>>>
>>>>At this point it *does* look like the same problem I had on SuSE...
>>>>
>>>>I've attached the one-line fix...
>>>
> 



-- 
Philip Pokorny, Director of Engineering
Tel: 415-358-2635   Fax: 415-358-2646   Toll Free: 888-PENGUIN
PENGUIN COMPUTING, INC.
www.penguincomputing.com

1250

[Jean Delvare]

I David,

Some times ago, Philip Pokorny sent you a patch that could possibly
solve your problem with lm_sensors. Did you try it? Did it work?

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

1250

[David]

Hello,

	No it didn't. I couldn't get the patch to work. He told me exactly
what to do after try several times myself to patch the source, with errors. 
I got the same errors, so doesn't look like it was me. One of the lines it
was suppose to look for wasn't there. I grepped the source files and I think
a couple of the lines weren't there. 
Looks like a bad patch.  
I sent the patch to someone else and apparently they didn't have any success
either.


Sincerely,

David

On Wednesday 18 June 2003 03:06 pm, you wrote:
> I David,
>
> Some times ago, Philip Pokorny sent you a patch that could possibly
> solve your problem with lm_sensors. Did you try it? Did it work?

1250

[Jean Delvare]

> > Some times ago, Philip Pokorny sent you a patch that could possibly
> > solve your problem with lm_sensors. Did you try it? Did it work?

> No it didn't. I couldn't get the patch to work. He told me exactly
> what to do after try several times myself to patch the source, with
> errors. I got the same errors, so doesn't look like it was me. One of
> the lines it was suppose to look for wasn't there. I grepped the
> source files and I think a couple of the lines weren't there. 
> Looks like a bad patch.  
> I sent the patch to someone else and apparently they didn't have any
> success either.

I'd like you to try again. Attached is a modified version of the same
patch that should apply. I tested it some minutes ago, and it does apply
cleanly to lm_sensors-2.7.0. Go inside the directory where the
lm_sensors sources reside and apply with "patch -p1 <
/path/to/lm_sensors-2.7.0-sysctl-2.patch".

We are planing to release a new version of lm_sensors in a few days and
I'd like to know if your problem is still present or not.

Thanks.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/
-------------- next part --------------
--- lm_sensors-2.7.0/lib/proc.c	Sun Nov 10 15:13:38 2002
+++ lm_sensors-2.7.0/lib/proc.c	Wed May 28 14:04:25 2003
@@ -184,6 +184,7 @@
   sysctl_name[3] = the_feature->sysctl;
   if (sysctl(sysctl_name, 4, buf, &buflen, NULL, 0))
     return -SENSORS_ERR_PROC;
+  if (sysctl_name[0] != CTL_DEV) { sysctl_name[0] = CTL_DEV ; }
   for (mag = the_feature->scaling; mag > 0; mag --)
     value *= 10.0;
   for (; mag < 0; mag ++)

1250

[David]

Applied the patch, works this time!!!
 
Results:patch --verbose -p1 < /home/david/lm_sensors-2.7.0-sysctl-2.patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- lm_sensors-2.7.0/lib/proc.c        Sun Nov 10 15:13:38 2002
|+++ lm_sensors-2.7.0/lib/proc.c        Wed May 28 14:04:25 2003
--------------------------
Patching file lib/proc.c using Plan A...
Hunk #1 succeeded at 184.
Hmm...  Ignoring the trailing garbage.
done

1) Then I tar'd the package back up and put in my /usr/portage/distfiles.
Rebuilt the digest and emerged it again.  (Gentoo speak, easier to remove
if let portage handle the install.)

2)  Installed fine. Tried several things. Still get same error. I restarted lm_sensors
and rebooted. Still:
#sensors -s
via686a-isa-6000: Can't access /proc file for writing;
Run as root?

3) So still same problem. I remember Philip P. saying something about having
i2c source also. Since the patch is only applied against lm_sensors I don't think
that was necessary, maybe he was mentioning it just because he was installing the
whole ball of wax at once. I already had i2c installed so didn't reinstall. 

If you want me to do something else OR install with  'make', 'make install',..... instead
of letting Gentoo install it let me know.  

Let me know.

Dave



On Thursday 19 June 2003 02:34 am, you wrote:
> > > Some times ago, Philip Pokorny sent you a patch that could possibly
> > > solve your problem with lm_sensors. Did you try it? Did it work?
> >
> > No it didn't. I couldn't get the patch to work. He told me exactly
> > what to do after try several times myself to patch the source, with
> > errors. I got the same errors, so doesn't look like it was me. One of
> > the lines it was suppose to look for wasn't there. I grepped the
> > source files and I think a couple of the lines weren't there.
> > Looks like a bad patch.
> > I sent the patch to someone else and apparently they didn't have any
> > success either.
>
> I'd like you to try again. Attached is a modified version of the same
> patch that should apply. I tested it some minutes ago, and it does apply
> cleanly to lm_sensors-2.7.0. Go inside the directory where the
> lm_sensors sources reside and apply with "patch -p1 <
> /path/to/lm_sensors-2.7.0-sysctl-2.patch".
>
> We are planing to release a new version of lm_sensors in a few days and
> I'd like to know if your problem is still present or not.
>
> Thanks.

1250

[Jean Delvare]

> 2)  Installed fine. Tried several things. Still get same error. I
> restarted lm_sensors and rebooted. Still:
> #sensors -s
> via686a-isa-6000: Can't access /proc file for writing;
> Run as root?

OK, so the patch doesn't work. Or, at least, it doesn't fix *that*
problem. Philip, should we remove the fix from CVS?

Do you by any chance have any additional patch to your kernel, such as
GRSEC or ACL?

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

1250

[DAVID]

>Do you by any chance have any additional patch to your 
>kernel, such as
>GRSEC or ACL?

If your asking me I don't believe so. Even if I do I don't 
have GRSEC set in the kernel.


On Fri, 20 Jun 2003 08:35:43 +0200
  Jean Delvare <khali@linux-fr.org> wrote:
>
>> 2)  Installed fine. Tried several things. Still get same 
>>error. I
>> restarted lm_sensors and rebooted. Still:
>> #sensors -s
>> via686a-isa-6000: Can't access /proc file for writing;
>> Run as root?
>
>OK, so the patch doesn't work. Or, at least, it doesn't 
>fix *that*
>problem. Philip, should we remove the fix from CVS?
>
>Do you by any chance have any additional patch to your 
>kernel, such as
>GRSEC or ACL?
>
>-- 
>Jean Delvare
>http://www.ensicaen.ismra.fr/~delvare/

<TEXTAREA NAME="Signature" ROWS="4" COLS="60">

1250

[Philip Pokorny]

I'm glad you were able to apply the patch.

The via686a is on the ISA bus.  That may be changing the "corruption" 
that happens when we attempt to read from /proc.

David, can you please run:

    strace -o /tmp/sensors.strace sensors -s

And then send me (or the list) the file /tmp/sensors.strace that will be 
created.  I'd like to see the system calls and more detail about the 
error before we decide to back out the patch.  It definitely does solve 
a problem for some people...

Thanks,
:v)

DAVID wrote:
>> Do you by any chance have any additional patch to your kernel, such as
>> GRSEC or ACL?
> 
> 
> If your asking me I don't believe so. Even if I do I don't have GRSEC 
> set in the kernel.
> 
> 
> On Fri, 20 Jun 2003 08:35:43 +0200
>  Jean Delvare <khali@linux-fr.org> wrote:
> 
>>
>>> 2)  Installed fine. Tried several things. Still get same error. I
>>> restarted lm_sensors and rebooted. Still:
>>> #sensors -s
>>> via686a-isa-6000: Can't access /proc file for writing;
>>> Run as root?
>>
>>
>> OK, so the patch doesn't work. Or, at least, it doesn't fix *that*
>> problem. Philip, should we remove the fix from CVS?
>>
>> Do you by any chance have any additional patch to your kernel, such as
>> GRSEC or ACL?
>>
>> -- 
>> Jean Delvare
>> http://www.ensicaen.ismra.fr/~delvare/
> 
> 
> <TEXTAREA NAME="Signature" ROWS="4" COLS="60">
> 



-- 
Philip Pokorny, Director of Engineering
Tel: 415-358-2635   Fax: 415-358-2646   Toll Free: 888-PENGUIN
PENGUIN COMPUTING, INC.
www.penguincomputing.com

1250

[Philip Pokorny]

Thanks!

See comments below...

David wrote:

> Philip,
> 
> 	Got the trace done for you. It isn't that big so will just paste the results here.
> Results:
> *******************************************************************************************

> _sysctl({{CTL_DEV, 2, 100, 3e8}, 4, 0x4003b300, 12, (nil), 0}) = 0
> _sysctl({{CTL_DEV, 2, 100, 3e8}, 4, (nil), 1074751684, 0x4003b300, 4}) = -1 EACCES (Permission denied)
> _sysctl({{CTL_DEV, 2, 100, 3e8}, 4, 0x4003b300, 12, (nil), 0}) = 0
> _sysctl({{CTL_DEV, 2, 100, 3e8}, 4, (nil), 1074751684, 0x4003b300, 8}) = -1 EACCES (Permission denied)


Well, the patch is either doing it's job or you didn't have the problem the 
patch was designed to fix.  However, in either case, your problem lies 
someplace else.

The second _sysctl() call above would not have said "CTL_DEV" if you had the 
problem the patch was designed to solve.

However, we *do* see that the kernel is denying write access to the files. 
(-1 EACCESS (Permission denied)) when attempting to set the limits.

> write(2, "via686a-isa-6000: Can\'t access /"..., 55) = 55
> write(2, "Run as root?\n", 13)          = 13


Are you running "sensors -s" as root?  While you can read sensors as any user, 
only root can write the limits.

The output from 'ls -l /proc/sys/dev/sensors/via686a-isa-6000' might also be 
interesting to see.

:v)

> *********************************************************************************************************************
> 
> Need anything else, just give me a holler.
> 
> David
> 
> 
> On Friday 20 June 2003 07:20 pm, you wrote:
> 
>>I'm glad you were able to apply the patch.
>>
>>The via686a is on the ISA bus.  That may be changing the "corruption"
>>that happens when we attempt to read from /proc.
>>
>>David, can you please run:
>>
>>    strace -o /tmp/sensors.strace sensors -s
>>
>>And then send me (or the list) the file /tmp/sensors.strace that will be
>>created.  I'd like to see the system calls and more detail about the
>>error before we decide to back out the patch.  It definitely does solve
>>a problem for some people...
>>
>>Thanks,
>>
>>:v)
>>
>>DAVID wrote:
>>
>>>>Do you by any chance have any additional patch to your kernel, such as
>>>>GRSEC or ACL?
>>>>
>>>If your asking me I don't believe so. Even if I do I don't have GRSEC
>>>set in the kernel.
>>>
>>>
>>>On Fri, 20 Jun 2003 08:35:43 +0200
>>>
>>> Jean Delvare <khali@linux-fr.org> wrote:
>>>
>>>>>2)  Installed fine. Tried several things. Still get same error. I
>>>>>restarted lm_sensors and rebooted. Still:
>>>>>#sensors -s
>>>>>via686a-isa-6000: Can't access /proc file for writing;
>>>>>Run as root?
>>>>>
>>>>OK, so the patch doesn't work. Or, at least, it doesn't fix *that*
>>>>problem. Philip, should we remove the fix from CVS?
>>>>
>>>>Do you by any chance have any additional patch to your kernel, such as
>>>>GRSEC or ACL?
>>>>
>>>>--
>>>>Jean Delvare
>>>>http://www.ensicaen.ismra.fr/~delvare/
>>>>
>>><TEXTAREA NAME="Signature" ROWS="4" COLS="60">
>>>
> 

1250

[Philip Pokorny]

I don't have my lm_sensors source handy right now, but I wanted to reply 
so perhaps you or someone else could look into this...

I notice that the adapter is registered at address 6000.  That's a bit 
of a strange isa address.  I believe that the original ISA bus only has 
I/O addresses up to 3fff.  Anything above that is either an alias or a 
PCI bus address.

Perhaps there is a test in the ISA write function that makes sure the 
address you're attempting to write is in the range: 0-3fff or less and 
if not, returns an error.

If 6000 is an alias, then the "ISA" address would have been 2000...  I 
wonder why the VIA686A driver is looking for address 6000.  Perhaps that 
came from a PCI register programmed by the BIOS?  If so, then the 
VIA686A is really a PCI device and we need to generalize the isa 
driver's notion of I/O address space for PCI devices...

:v)

David wrote:
> On Sunday 22 June 2003 03:44 pm, you wrote:
> 
>>Well, the patch is either doing it's job or you didn't have the problem the
>>patch was designed to fix.  However, in either case, your problem lies
>>someplace else.
>>
>>The second _sysctl() call above would not have said "CTL_DEV" if you had
>>the problem the patch was designed to solve.
>>
>>However, we *do* see that the kernel is denying write access to the files.
>>(-1 EACCESS (Permission denied)) when attempting to set the limits.
>>
>>
>>>write(2, "via686a-isa-6000: Can\'t access /"..., 55) = 55
>>>write(2, "Run as root?\n", 13)          = 13
>>
>>Are you running "sensors -s" as root?  While you can read sensors as any
>>user, only root can write the limits.
>>
>>The output from 'ls -l /proc/sys/dev/sensors/via686a-isa-6000' might also
>>be interesting to see.
> 
> 
> 
> 
> root # ls -l /proc/sys/dev/sensors/via686a-isa-6000
> total 0
> -r--r--r--    1 root     root            0 Jun 22 20:50 alarms
> -rw-r--r--    1 root     root            0 Jun 22 20:50 fan1
> -rw-r--r--    1 root     root            0 Jun 22 20:50 fan2
> -rw-r--r--    1 root     root            0 Jun 22 20:50 fan_div
> -rw-r--r--    1 root     root            0 Jun 22 20:50 in0
> -rw-r--r--    1 root     root            0 Jun 22 20:50 in1
> -rw-r--r--    1 root     root            0 Jun 22 20:50 in2
> -rw-r--r--    1 root     root            0 Jun 22 20:50 in3
> -rw-r--r--    1 root     root            0 Jun 22 20:50 in4
> -rw-r--r--    1 root     root            0 Jun 22 20:50 temp1
> -rw-r--r--    1 root     root            0 Jun 22 20:50 temp2
> -rw-r--r--    1 root     root            0 Jun 22 20:50 temp3
> 
> 
> 
>>Are you running "sensors -s" as root?  While you can read sensors as any
>>user, only root can write the limits.
> 
> 
> Hmmm, hope your joking here. But I guess sometimes you do have to ask.
> 
> Dave
> 
> 



-- 
Philip Pokorny, Director of Engineering
Tel: 415-358-2635   Fax: 415-358-2646   Toll Free: 888-PENGUIN
PENGUIN COMPUTING, INC.
www.penguincomputing.com

1250

[Jean Delvare]

> I don't have my lm_sensors source handy right now, but I wanted to
> reply so perhaps you or someone else could look into this...
> 
> I notice that the adapter is registered at address 6000.  That's a bit
> of a strange isa address.  I believe that the original ISA bus only
> has I/O addresses up to 3fff.  Anything above that is either an alias
> or a PCI bus address.
> 
> Perhaps there is a test in the ISA write function that makes sure the 
> address you're attempting to write is in the range: 0-3fff or less and
> if not, returns an error.

This would make sense. David, correct me if I'm wrong, but I believe
that you can actually write to the files (simply using "cat 1 2 >
/proc/sys/dev/sensors/via686a-isa-6000/in1" for example). So, if
"sensors -s" fails, this must be because of libsensors *thinking* it
cannot write.

David, maybe we already asked you and I'm sorry for that, but I can't
remember (it's been so long):

1* Are you using i2c & lm_sensors 2.7.0 or CVS?

2* Are you using the mkpatch method or the traditional separated
compilation tree method?

Thanks.

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

1250

[David]

> This would make sense. David, correct me if I'm wrong, but I believe
> that you can actually write to the files (simply using "cat 1 2 >
> /proc/sys/dev/sensors/via686a-isa-6000/in1" for example). So, if
> "sensors -s" fails, this must be because of libsensors *thinking* it
> cannot write.
Actually no. Not using cat. I get this error if do that:

bash-2.05b# cat 1 2 > /proc/sys/dev/sensors/via686a-isa-6000/in1
cat: 1: No such file or directory
cat: 2: No such file or directory

I can though 'echo' to it:





Previous message:
On Wednesday 25 June 2003 08:52 am, you wrote:
> > I don't have my lm_sensors source handy right now, but I wanted to
> > reply so perhaps you or someone else could look into this...
> >
> > I notice that the adapter is registered at address 6000.  That's a bit
> > of a strange isa address.  I believe that the original ISA bus only
> > has I/O addresses up to 3fff.  Anything above that is either an alias
> > or a PCI bus address.
> >
> > Perhaps there is a test in the ISA write function that makes sure the
> > address you're attempting to write is in the range: 0-3fff or less and
> > if not, returns an error.
>
> This would make sense. David, correct me if I'm wrong, but I believe
> that you can actually write to the files (simply using "cat 1 2 >
> /proc/sys/dev/sensors/via686a-isa-6000/in1" for example). So, if
> "sensors -s" fails, this must be because of libsensors *thinking* it
> cannot write.
>
> David, maybe we already asked you and I'm sorry for that, but I can't
> remember (it's been so long):
>
> 1* Are you using i2c & lm_sensors 2.7.0 or CVS?
>
> 2* Are you using the mkpatch method or the traditional separated
> compilation tree method?
>
> Thanks.

1250

[David]

Hi Jean,

Sorry, must have hit send. Anyways.
> This would make sense. David, correct me if I'm wrong, but I believe
> that you can actually write to the files (simply using "cat 1 2 >
> /proc/sys/dev/sensors/via686a-isa-6000/in1" for example). So, if
> "sensors -s" fails, this must be because of libsensors *thinking* it
> cannot write.

Actually no. Not using cat. I get this error if do that:

bash-2.05b# cat 1 2 > /proc/sys/dev/sensors/via686a-isa-6000/in1
cat: 1: No such file or directory
cat: 2: No such file or directory

I can though 'echo' to it:
bash-2.05b# echo 1 2 > /proc/sys/dev/sensors/via686a-isa-6000/in1
Haven't done that before though so not sure why it changed it to:
0.99 1.99 1.07
from the defaults in there. Doesn't matter now though. Root can write
to the file using 'echo'

>So, if  "sensors -s" fails, this must be because of libsensors *thinking* it
> cannot write.

Does seem so, yes.

> 1* Are you using i2c & lm_sensors 2.7.0 or CVS?

2.7.0 both, not CVS.

> 2* Are you using the mkpatch method or the traditional separated
> compilation tree method?

Not sure, Probably closer to the 2nd one. I could try not using the ebuild
below if you think it might be the problem.
**********************************************************
# Copyright 1999-2003 Gentoo Technologies, Inc.
# Distributed under the terms of the GNU General Public License v2
# $Header: /home/cvsroot/gentoo-x86/sys-apps/lm-sensors/lm-sensors-2.7.0-r1.ebuild,v 1.4 2003/06/23 12:26:33 phosphan Exp $

inherit flag-o-matic

MY_P=${PN/-/_}-${PV}

S="${WORKDIR}/${MY_P}"
MYI2C="${WORKDIR}/i2c-headers"

DESCRIPTION="Hardware Sensors Monitoring by lm_sensors"
SRC_URI="http://www2.lm-sensors.nu/~lm78/archive/${MY_P}.tar.gz
	mirror://gentoo/${P}-sensors-detect-gentoo.diff.bz2"
HOMEPAGE="http://www2.lm-sensors.nu/~lm78"

SLOT="0"
# gentoo-sources-2.4.20-r1 and xfs-sources-2.4.20-r1 will
# have support for this package, do not change these to ~
# until your arch has i2c-2.7.0 in it's kernel.
KEYWORDS="x86 amd64 -ppc -sparc"
LICENSE="GPL-2"

DEPEND="|| (
	     >=sys-apps/i2c-2.7.0
	     >=sys-kernel/gentoo-sources-2.4.20-r1
	     >=sys-kernel/lolo-sources-2.4.20.1
	     >=sys-kernel/xfs-sources-2.4.20_pre4
	   )"

src_unpack() {
	unpack ${A} || die
	cd ${S} || die
	patch -p 1 <../${P}-sensors-detect-gentoo.diff || die
	# get the right i2c includes without dropping the kernel includes
	mkdir -p ${MYI2C}/linux
	cp /usr/include/linux/i2c* ${MYI2C}/linux/
}

src_compile()  {
	check_KV

	filter-flags -fPIC

	emake I2C_HEADERS=${MYI2C} clean all || die "lm_sensors requires the source of a compatible kernel\nversion installed in /usr/src/linux and >=i2c-2.7.0 support built as a modules this support is included in gentoo-sources as of 2.4.20-r1"
}

src_install() {
	einstall DESTDIR=${D} PREFIX=/usr MANDIR=/usr/share/man || die "Install failed"
	exeinto /etc/init.d
	newexe ${FILESDIR}/rc lm_sensors
}

pkg_postinst() {
	[ -x /usr/sbin/update-modules ] && /usr/sbin/update-modules

	einfo
	einfo "The lm_sensors hardware sensors package has been installed."
	einfo
	einfo "It is recommended that you read the lm_sensors documentation."
	einfo "To enable lm_sensors you will need to compile i2c support in"
	einfo "your kernel as a module and run /usr/sbin/sensors-detect to"
	einfo "detect the hardware in your system."
	einfo
	einfo "Be warned, the probing of hardware in your system performed by"
	einfo "sensors-detect could freeze your system.  Also do not use"
	einfo "lm_sensors on certain laptop models from IBM.  See the lm_sensors"
	einfo "documentation and website for more information."
	einfo
	einfo "IMPORTANT: When you merge this package it installs kernel modules"
	einfo "that can only be used with the specific kernel version whose"
	einfo "source is located in /usr/src/linux.  If you upgrade to a new"
	einfo "kernel, you will need to remerge the lm_sensors package to build"
	einfo "new kernel modules."
	einfo
}
***********************************************************
David


Previous message:
On Wednesday 25 June 2003 08:52 am, you wrote:
> > I don't have my lm_sensors source handy right now, but I wanted to
> > reply so perhaps you or someone else could look into this...
> >
> > I notice that the adapter is registered at address 6000.  That's a bit
> > of a strange isa address.  I believe that the original ISA bus only
> > has I/O addresses up to 3fff.  Anything above that is either an alias
> > or a PCI bus address.
> >
> > Perhaps there is a test in the ISA write function that makes sure the
> > address you're attempting to write is in the range: 0-3fff or less and
> > if not, returns an error.
>
> This would make sense. David, correct me if I'm wrong, but I believe
> that you can actually write to the files (simply using "cat 1 2 >
> /proc/sys/dev/sensors/via686a-isa-6000/in1" for example). So, if
> "sensors -s" fails, this must be because of libsensors *thinking* it
> cannot write.
>
> David, maybe we already asked you and I'm sorry for that, but I can't
> remember (it's been so long):
>
> 1* Are you using i2c & lm_sensors 2.7.0 or CVS?
>
> 2* Are you using the mkpatch method or the traditional separated
> compilation tree method?
>
> Thanks.

1250

[Jean Delvare]

> Sorry, must have hit send. Anyways.

Well, that happens to *me* also sometimes ;)

> > This would make sense. David, correct me if I'm wrong, but I believe
> > that you can actually write to the files (simply using "cat 1 2 >
> > /proc/sys/dev/sensors/via686a-isa-6000/in1" for example). So, if
> > "sensors -s" fails, this must be because of libsensors *thinking* it
> > cannot write.
> 
> Actually no. Not using cat. I get this error if do that:
> 
> bash-2.05b# cat 1 2 > /proc/sys/dev/sensors/via686a-isa-6000/in1
> cat: 1: No such file or directory
> cat: 2: No such file or directory
> 
> I can though 'echo' to it:
> bash-2.05b# echo 1 2 > /proc/sys/dev/sensors/via686a-isa-6000/in1
> Haven't done that before though so not sure why it changed it to:
> 0.99 1.99 1.07
> from the defaults in there. Doesn't matter now though. Root can write
> to the file using 'echo'

(hitting me head on the table) I of course meant echo, not cat :) Glad
you figured it out by yourself.

> > 1* Are you using i2c & lm_sensors 2.7.0 or CVS?
> 
> 2.7.0 both, not CVS.

Could you possibly give a try to CVS? It could be interesting to see if
the problem could have been already been solved as a side effect of
another fix.

> > 2* Are you using the mkpatch method or the traditional separated
> > compilation tree method?
> 
> Not sure, Probably closer to the 2nd one. I could try not using the
> ebuild below if you think it might be the problem.

I think you're right, 2nd method. I don't think it changes anything that
you use ebuild (except that you may not be able to use it for CVS).

> SRC_URI="http://www2.lm-sensors.nu/~lm78/archive/${MY_P}.tar.gz
> 	mirror://gentoo/${P}-sensors-detect-gentoo.diff.bz2"

BTW, what's this patch? I'd like to know what Gentoo changed in our
original sensors-detect script.

Thanks.

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

1250

[David]

Hi Jean,
	I will try putting the CVS on tonight. For now though here is the info
you were interested on about the patch.


> > SRC_URI="http://www2.lm-sensors.nu/~lm78/archive/${MY_P}.tar.gz
> > 	mirror://gentoo/${P}-sensors-detect-gentoo.diff.bz2"
>
> BTW, what's this patch? I'd like to know what Gentoo changed in our
> original sensors-detect script.

This looks relitively new. I remember the first time I installed lm-sensors I had to make
the /etc/sysconfig folder and put the stuff there. So they just fixed that for the
Gentoo layout, which doesn't have that folder. Then /etc/init.d is the
run scripts for daemons and such you start/stop.  

*************************************************************
diff -urN lm_sensors-2.7.0-orig/prog/detect/sensors-detect lm_sensors-2.7.0/prog/detect/sensors-detect
--- lm_sensors-2.7.0-orig/prog/detect/sensors-detect	2003-03-02 01:26:59.000000000 +0100
+++ lm_sensors-2.7.0/prog/detect/sensors-detect	2003-03-02 02:42:16.000000000 +0100
@@ -25,6 +25,14 @@
 # each be put in a separate file, using modules and packages. That is beyond
 # me.

+# Changelog
+#  02/Mar/2003, Rudo Thomas <thomr9am@ss1000.ms.mff.cuni.cz>
+#    * a few small changes in config file output to reflect Gentoo Linux layout
+#      - /etc/sysconfig -> /etc/conf.d
+#      - /etc/rc.d/init.d -> /etc/init.d
+#      - added a warning to the generated config file
+#      - small change when asking about writing the new config file
+
 require 5.004;

 use strict;
@@ -3277,33 +3285,38 @@
   my ($modprobes,$configfile) = generate_modprobes $use_isa;
   print "\nWARNING! If you have some things built into your kernel, the \n",
         "below list will contain too many modules. Skip the appropriate ones!";
-  print "\nTo load everything that is needed, add this to some /etc/rc* ",
-        "file:\n\n";
+  print "\nTo load everything that is needed, execute these commands:\n\n";
   print "#----cut here----\n";
   print $modprobes;
   print "#----cut here----\n";
-  print "\nTo make the sensors modules behave correctly, add these lines to ",
-        "either\n",
-        "/etc/modules.conf or /etc/conf.modules:\n\n";
+  print "\nIf you want to load the modules at startup, generate a config",
+  	" file\n",
+	"below and make sure lm_sensors get started ",
+	"(eg. rc-update add lm_sensors default).\n";
+  print "\nTo make the sensors modules behave correctly, add these lines to\n",
+        "/etc/modules.conf:\n\n";
   print "#----cut here----\n";
   print $configfile;
   print "#----cut here----\n";

-  my $have_sysconfig = -d '/etc/sysconfig';
-  print "\nDo you want to generate /etc/sysconfig/lm_sensors? (".
-    ($have_sysconfig?"YES/no":"yes/NO")."): ";
-  if ($> != 0) {
-    print "\nAs you are not root, we shall skip this step.\n";
-  } else {
-    if (($have_sysconfig and not <STDIN> =~ /^\s*[Nn]/) or <STDIN> =~ /^\s*[Yy]/) {
-      unless ($have_sysconfig) {
-        mkdir '/etc/sysconfig', 0777
-          or die "Sorry, can't create /etc/sysconfig ($!)?!?";
-      }
-      open(SYSCONFIG, ">/etc/sysconfig/lm_sensors")
-        or die "Sorry, can't create /etc/sysconfig/lm_sensors ($!)?!?";
+  my $have_config = -f '/etc/conf.d/lm_sensors';
+  print "\nDo you want to ".($have_config?"overwrite":"generate").
+  	" /etc/conf.d/lm_sensors? Enter s to specify other file name?\n",
+	"  (".($have_config?"yes/NO":"YES/no")."/s): ";
+  my $reply = <STDIN>;
+
+  if (($have_config and $reply =~ /^\s*[Yy]/) or
+      (not $have_config and not $reply =~ /^\s*[Nn]/) or
+      $reply =~ /^\s*[Ss]/) {
+    my $filename = "/etc/conf.d/lm_sensors";
+    if ($reply =~ /^\s*[Ss]/) {
+      print "Specify the file to store the configuration to: ";
+      $filename = <STDIN>;
+    }
+    open(SYSCONFIG, ">".$filename)
+      or die "Sorry, can't create $filename ($!).";
       print SYSCONFIG <<'EOT';
-#    /etc/sysconfig/sensors - Defines modules loaded by /etc/rc.d/init.d/lm_sensors
+#    /etc/conf.d/sensors - Defines modules loaded by /etc/init.d/lm_sensors
 #    Copyright (c) 1998 - 2001  Frodo Looijaard <frodol@dds.nl>
 #
 #    This program is free software; you can redistribute it and/or modify
@@ -3324,13 +3337,17 @@
 # See also the lm_sensors homepage at:
 #     http://www2.lm-sensors.nu/~lm78/index.html
 #
-# This file is used by /etc/rc.d/init.d/lm_sensors and defines the modules to
-# be loaded/unloaded. This file is sourced into /etc/rc.d/init.d/lm_sensors.
+# This file is used by /etc/init.d/lm_sensors and defines the modules to
+# be loaded/unloaded. This file is sourced into /etc/init.d/lm_sensors.
 #
 # The format of this file is a shell script that simply defines the modules
 # in order as normal variables with the special names:
 #    MODULE_0, MODULE_1, MODULE_2, etc.
 #
+# Please note that the numbers in MODULE_X must start at 0 and increase in
+# steps of 1. Any number that is missing will make the init script skip the
+# rest of the modules.
+#
 # List the modules that are to be loaded for your system
 #
 EOT
@@ -3346,9 +3363,7 @@
       }
       print SYSCONFIG $sysconfig;
       close(SYSCONFIG);
-      print "Copy prog/init/lm_sensors.init to /etc/rc.d/init.d/lm_sensors\n";
-      print "for initialization at boot time.\n";
-    }
+      print "Done.\n";
   }
 }
*************************************************

> I of course meant echo, not cat :)
Ya, I never seen cat used that way, but you always see someone using a 
command in a new way, so I though hmmm, let's try it. :)

Get back with you on the CVS in awhile.

David

Original message:

On Thursday 26 June 2003 08:40 am, you wrote:
> > Sorry, must have hit send. Anyways.
>
> Well, that happens to *me* also sometimes ;)
>
> > > This would make sense. David, correct me if I'm wrong, but I believe
> > > that you can actually write to the files (simply using "cat 1 2 >
> > > /proc/sys/dev/sensors/via686a-isa-6000/in1" for example). So, if
> > > "sensors -s" fails, this must be because of libsensors *thinking* it
> > > cannot write.
> >
> > Actually no. Not using cat. I get this error if do that:
> >
> > bash-2.05b# cat 1 2 > /proc/sys/dev/sensors/via686a-isa-6000/in1
> > cat: 1: No such file or directory
> > cat: 2: No such file or directory
> >
> > I can though 'echo' to it:
> > bash-2.05b# echo 1 2 > /proc/sys/dev/sensors/via686a-isa-6000/in1
> > Haven't done that before though so not sure why it changed it to:
> > 0.99 1.99 1.07
> > from the defaults in there. Doesn't matter now though. Root can write
> > to the file using 'echo'
>
> (hitting me head on the table) I of course meant echo, not cat :) Glad
> you figured it out by yourself.
>
> > > 1* Are you using i2c & lm_sensors 2.7.0 or CVS?
> >
> > 2.7.0 both, not CVS.
>
> Could you possibly give a try to CVS? It could be interesting to see if
> the problem could have been already been solved as a side effect of
> another fix.
>
> > > 2* Are you using the mkpatch method or the traditional separated
> > > compilation tree method?
> >
> > Not sure, Probably closer to the 2nd one. I could try not using the
> > ebuild below if you think it might be the problem.
>
> I think you're right, 2nd method. I don't think it changes anything that
> you use ebuild (except that you may not be able to use it for CVS).
>
> > SRC_URI="http://www2.lm-sensors.nu/~lm78/archive/${MY_P}.tar.gz
> > 	mirror://gentoo/${P}-sensors-detect-gentoo.diff.bz2"
>
> BTW, what's this patch? I'd like to know what Gentoo changed in our
> original sensors-detect script.
>
> Thanks.

1250

[Jean Delvare]

> I will try putting the CVS on tonight. For now though here is
> the info you were interested on about the patch.

OK, thanks. It turns out to be unrelated to our problems, but
interesting though. They customized some of messages at the end of the
script to reflect files locations and names on Gentoo. Part of what they
did could even make it back into our version.

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

1250

[David]

Well, no luck so far. Having a little trouble with the cvs and little short
on time till Sunday.  
CVS i2c installed fine. CVS lm_sensors got an error during make right after:

lib/chips.c:2397: initializer element is not constant
lib/chips.c:2397: (near initialization for `adm1026_features[103]')
make: *** [lib/chips.ao] Error 1

Still seem to install fine during make install. 
Ran sensors-detect, seemed normal. Couldn't use the init script cause diff
than gentoos. 

bash-2.05b# lsmod
Module                  Size  Used by    Tainted: P
i2c-proc                6804   0
i2c-isa                  748   0  (unused)
i2c-viapro              3604   0  (unused)
i2c-core               15396   0  [i2c-proc i2c-isa i2c-viapro]

module via686a not loading though. Can't 'modprobe' or 'insmod' to get it working
gives:

bash-2.05b# insmod via686a
Using /lib/modules/2.4.20-gentoo-r5/kernel/drivers/i2c/chips/via686a.o
/lib/modules/2.4.20-gentoo-r5/kernel/drivers/i2c/chips/via686a.o: init_module: No such device
Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters.
      You may find more information in syslog or the output from dmesg

The only thing I did before installing was:
uninstall i2c and lm_sensors. rmmod all the modules, had to take some out of /etc/modules.autoload and
reboot to get them out. Normal.  Rebooted. Then installed like said above. 
Will see if can get working at least by Sunday.
Didn't change anything in the kernel and via686a worked before.

build is linked to the correct kernel source, yadda, yadda.

Might put the ebuild in for i2c and then just try lm_sensors from CVS.

HMMMM, sensors -s doesn't work. Then checked and there is no /usr/bin/sensors.
Must not have install do to the error during 'make'


Dave







On Friday 27 June 2003 02:53 am, you wrote:
> > I will try putting the CVS on tonight. For now though here is
> > the info you were interested on about the patch.
>
> OK, thanks. It turns out to be unrelated to our problems, but
> interesting though. They customized some of messages at the end of the
> script to reflect files locations and names on Gentoo. Part of what they
> did could even make it back into our version.

1250

[David]

I reinstalled the gentoo ebuilds. Something got borked from
installing the cvs. Will be a couple days before I have time
to figure out what it is though. First time I have had problems
getting it to work. 
I need to build a test system.

Dave

1250

[David]

Jean,

	Finally got lm_sensors working again after whatever happened when
I installed the cvs. Had a heck of a time getting via686a to work. Keeped putting
in only lm80 for some reason. Module for via686a was loaded but sensors wouldn't
use it for some reason.  Then when would take out via-pro and lm80 it would say
no sensors, when ran  'sensors'.

Long story so won't bore you, but finally got it working, gkrellm2 working with it also again,
just like before. 

I did notice one thing that might be important during my trouble after the cvs and trying
to get it working again. 

sensors -s     

did work with the lm80 and Smsbus.  Just not with the via686a, so maybe what Philip
said about the ISA is correct.

>Philip Pokorny wrote:
> I don't have my lm_sensors source handy right now, but I wanted to
> reply so perhaps you or someone else could look into this...
> 
> I notice that the adapter is registered at address 6000.  That's a bit
> of a strange isa address.  I believe that the original ISA bus only
> has I/O addresses up to 3fff.  Anything above that is either an alias
> or a PCI bus address.
> 
> Perhaps there is a test in the ISA write function that makes sure the 
> address you're attempting to write is in the range: 0-3fff or less and
> if not, returns an error.


Dave

Sorry it took me a few days to get back with you, but have to work the weekends.