Re: Problem setting up lm-sensors
From: Jean-David Beyer (jdbeyer_at_exit109.com)
Date: 06/12/04
- Next message: Hendrik van Hees: "Re: Walmart PC's with Linux SUCK."
- Previous message: Kadaitcha Man: "Re: Walmart PC's with Linux SUCK."
- In reply to: P.T. Breuer: "Re: Problem setting up lm-sensors"
- Next in thread: P.T. Breuer: "Re: Problem setting up lm-sensors"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 12 Jun 2004 12:45:03 -0400
P.T. Breuer wrote:
> Jean-David Beyer <jdbeyer@exit109.com> wrote:
[snip]
>>> if [ "$CONFIG_OBSOLETE" = "y" ]; then tristate ' SK_G16 support'
>>> CONFIG_SK_G16 fi
>>>
>>> Try not to compile obsolete drivers with bugs in them!
>>
>> I used the same .config building these modules that Red Hat did when
>> they built the kernel. It seemed the right thing to do. Guess not.
>
>
> I was looking at 2.4.22 or 2.4.24 - I forget which. I don't have
> 2.4.21.
>
>
>> STRANGE: CONFIG_OBSOLETE does not appear in the .config file...
>>
>> Why does the Makefile not use .config? Rhetorical question, I think.
>> I assume no one wants to see that 727 line Makefile.
>
>
> It sounds like RH have their own compile system. I don't know.
>
Well, why send me a complete source tree full of Makefiles and stuff, and
a .config file, that are supposed to build me exactly what I have if it is
not exactly what I have?
>
[snip]
>>> I have a question that is probably very important, though. Should I
>>> use the default gcc compiler or the gcc296 compiler for this?
>>
>> They replied:
>>
>>> Have you checked in /proc for the information you seek?
>
> Uh - of course. Silly us. uname -a will show the compiler name. And
> that comes from /proc/version.
>
I think if that techie is trying to prove to me that he is smarter than I
am, I am willing to grant that point. But why not either answer the
question or give me a better pointer to where the answer is. I am quite
willing to RTFM, but what manual? I have lots of the things. One for make,
one for bash, many for Linux. "tristate" which litters the Makefiles is
not in the make book, nor in shell, and apropos never heard of it. I tried
Google, but it did not help either.
jdbeyer[~]$ cat /proc/version
Linux version 2.4.21-15.ELsmp (bhcompile@bugs.build.redhat.com) (gcc
version 3.2.3 20030502 (Red Hat Linux 3.2.3-34)) #1 SMP Thu Apr 22
00:18:24 EDT 2004
OK. I have
trillian:jdbeyer[~]$ rpm -q gcc
gcc-3.2.3-34
That is the one their Makefile picks up, too. So they say I am using the
compiler they used.
>
>> This does not seem to my naive understanding to be responsive to the
>> question as to what compiler I should use.
>
> It is sort-of-responsive, once you realize what he means. If you want
> to piss him off, ask him why he didn't direct you to the output of
> uname -a instead of leaving you to guess that he meant /proc/version
> (or something else, for all I know!).
>
What good would it do me to piss him off. I have to work with this guy.
>
>
>> If they built the kernel with the 3.2.3 compiler and I make the
>> modules with the 2.96 compiler, I would anticipate severe problems.
>
> I'd expect severe problems with the former approach anyway!
>
Which is former? It seems to me that I would be crazy to use a different
compiler for the modules than they used for the kernel. Now if they lie in
/proc/version, I am doomed.
>
>> ... and later...
>>
>>> Red Hat Tech Support can not assist you in compiling custom kernels
>>> and plugging in non-Red Hat modules for this project. We can't help
>>> you break the terms of the support agreement.
>>
>> I protested that the modules in question are supplied as part of the
>> distribution by Red Hat, that I will not be compiling the kernel at
>> all, nor will I be plugging in non-Red Hat modules.
>
> Well, if their kernel comes in an rpm, there will be a spec file in the
> corresponding srpm which will tell you how to compile their kernel.
>
I wonder where that might be. In linux-2.4.21-15.EL? I do not notice
anything that I would think is a "spec file."
>
>> This paid support is not so good. So far, nothing I have asked about
>> has received a satisfactory response: Three items they claim are not
>> supported. They do not seem able to understand English and do not
>> respond to the questions.
>
> Well, it is a human being, clearly. And one who knows the answer. But
> yes, you have not asked him how to compile non-redhat modules, but how
> to compile redhat modules, in the redhat way. I suppose the answer to
> that is "let us do it for you".
>
> At least you found a kernel bug! Now you get to check the latest code
> and send in the one line patch to linux-kernel if it is not corrected
> yet.
>
>> The only one where they do respond is that demand dialing does not
>> work,
>
> Is that diald? I never tried such things. I am on ADSL at home
> nowadays.
Nope: wvdial and pppd.
[snip]
>>> Boring. Why are you compiling yellowfin?
>>
>> Absolutely boring. I thunk if I did
>>
>> make modules
>>
>> that it would compile the modules I need. It may have done that: it
>
>
> Well, it looks to me as though RH don't compile their modules that way.
> I suspect their spec file for the modules rpm contains a patch for
> .config.
Well, the .config is the one they supply for my kernel.
>
>
>> certainly did i2c-i810.o that I know I need to run
>> /usr/sbin/sensors-detect. But I do not want to do make
>> modules-install
>
>
> Yes you do. The trick is that you don't want to do it TO THE PLACE
> WHERE THEY ALREADY ARE. Do it to /tmp first. Look in the Makefile for
> something like MOD_INSTALL_PATH (if memory serves).
>
>
>> because that would replace all the modules and I do not even know if
>> I am using the same compiler they did to make the kernel. I think so,
>> because
>
>
> I believe you are not.
I am using what they say, in /proc/version, that they use.
>
>> the Makefile says
>>
>> HOSTCC = gcc
>>
>> which gets me gcc-3.2.3-34
>
> But I don't think RH will leave that makefile unpatched when making
> their modules RPM.
>
>> Now, given the i2c-i810.o, I guess I do not know how to install it. I
>>
>
>
> Just put it in place and run depmod -a - but I think you probably used
> the wrong compiler.
>
>
>> copied it to /lib/modules/2.4.21-15.ELsmp/kernel/drivers and tried to
>> do depmod -a, and it found it, but does not like dependencies. I
>> guess that is not how to do it.
>
>
> It is how to do it. You may need a slew more supporting stuff. One of
> modules.dep says:
>
> /lib/modules/2.4.19-SMP-XFS/misc/i2c-i810.o:
> /lib/modules/2.4.19-SMP-XFS/kernel/drivers/i2c/i2c-algo-bit.o
>
> so it needs that at least.
>
I find the source for i2c-algo-bit and will see if I can get it to
compile. I looked at modules.dep and it has an entry for anything with i2c
in it, and all I get is this:
/lib/modules/2.4.21-15.ELsmp/kernel/drivers/i2c-i810.o:
If I manage to figure out depmod(8) program (should not take too long), I
will stuff the modules in it and see what it thinks. Because my
/lib/modules/2.4.21-15.ELsmp/modules.dep file may be bad. I tried depmod
on some of these things and get:
trillian:jdbeyer[/usr/src/linux-2.4.21-15.EL/drivers/i2c]$ /sbin/depmod -v
--show i2c-algo-bit.o i2c-core.o i2c-i810.o
i2c-algo-bit.o
i2c-algo-bit.o: i2c-core.o
i2c-core.o
i2c-core.o:
i2c-i810.o
i2c-i810.o: i2c-algo-bit.o
# module id=string
# pci module vendor device subvendor subdevice class
class_mask driver_data
# isapnp module cardvendor carddevice driver_data vendor function
...
# usb module match_flags idVendor idProduct bcdDevice_lo
bcdDevice_hi bDeviceClass bDeviceSubClass bDeviceProtocol bInterfaceClass
bInterfaceSubClass bInterfaceProtocol driver_info
# module pattern
# ieee1394 module match_flags vendor_id model_id specifier_id version
# module id
I do not know what the stuff at the end means. I gather the beginning
means I have found every module I need to start. Right?
i2c-i810.o
i2c-algo-bit.o
i2c-core.o
[snip]
>
> But you don't use the same .config that they use.
>
I was using the one they sent me along with the kernel. They come together
in the same rpm so I would think they go together.
>
>> Do no users of RHEL 3 monitor processor temperatures and fan speeds
>> which is what I wanted to do in the first place. I would imagine
>> operators of servers would like to know this kind of thing.
>
>
> I think so. Why not ask RH support THAT question?
>
I have. They do not answer it. When I ask a question, they either answer a
different question, or say what I want is unsupported.
Anyhow, I just went through the whole thing again:
make mrproper
make oldconfig
make modules
and this time it seems to have completed normally. So should I just copy
those three modules up to /lib/modules/2.4.21-15.ELsmp/kernel/drivers?
They have these directories:
addon audit block cdrom char hotplug ide input md message net
parport pcmcia scsi sound usb video
and none seem likely. Do I put it in one of the others? or make an i2c up
there?
I seem to be getting a headache...
-- .~. Jean-David Beyer Registered Linux User 85642. /V\ Registered Machine 241939. /( )\ Shrewsbury, New Jersey http://counter.li.org ^^-^^ 11:30:00 up 4 days, 20:55, 6 users, load average: 2.10, 2.70, 2.94
- Next message: Hendrik van Hees: "Re: Walmart PC's with Linux SUCK."
- Previous message: Kadaitcha Man: "Re: Walmart PC's with Linux SUCK."
- In reply to: P.T. Breuer: "Re: Problem setting up lm-sensors"
- Next in thread: P.T. Breuer: "Re: Problem setting up lm-sensors"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
