Re: More about 2.4.3 timer problems

Re: More about 2.4.3 timer problems

[James Simmons]

>Err, tried the patch you recommended me to apply to the 2.4.3 source code
>(not the 2.4.3-pre6), but everything else started complaining it couldn't
>see printk() any more.  Any advice?  Thanks...

Can you tell us your hardware configuration and your kernel configuration.
What do you mean it couldn't see printk any more?

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsimmons@linux-fbdev.org]               ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: More about 2.4.3 timer problems

[Eric Gillespie]

On Wed, 4 Apr 2001, James Simmons wrote:

:
:>Err, tried the patch you recommended me to apply to the 2.4.3 source code
:>(not the 2.4.3-pre6), but everything else started complaining it couldn't
:>see printk() any more.  Any advice?  Thanks...
:
:Can you tell us your hardware configuration and your kernel configuration.

This has been mentioned in an earlier message of mine, but basically, I have a
Cyrix M-II machine, 32 meg of ram, 3.4 gig HD, PCI and ISA buses, SiS chipset,
etc etc.

:What do you mean it couldn't see printk any more?

What I meant was that while kernel/printk.c got compiled to printk.o, none of
the modules compiled could then see the function printk(); when I did a depmod
-ae, the unresolved function (and the ONLY function) they all complained about
was printk, even though it appeared in the System.Map file, (c0xxxx T printk)
and, presumably, in the kernel image as well.

I noted that the patch touched printk.c, so wondered what the patch had
done... and I really didn't want to have to compile everything into my kernel
just to get it to work... it's almost like it was a question of scope...

The patch did work to eliminate the clock skew, aside from this printk
problem, but fortunately I was bright enough to have kept an older kernel
tarball around, so I could go back to unpatched version. 

Thanks for keeping in touch... me not being much of a programmer, I can't just
get my hands dirty and fix the patch problem, otherwise, I'd do it.  But
knowing my luck, I'd end up with a kernel that worked six times faster than
anything previously, but wind up destroying the hard disk and CMOS in two
minutes fifteen point three seconds.  And set my monitor on fire too...

-- 
 /|   _,.:*^*:.,   |\           Cheers from the Viking family, 
| |_/'  viking@ `\_| |            including Pippin, our cat
|    flying-brick    | $FunnyMail  Bilbo   : Now far ahead the Road has gone,
 \_.caverock.net.nz_/     5.39    in LOTR  : Let others follow it who can!

[QUESTION] 2.4.3: hotplug_path unresolved in usbcore?

[Ryan Mack]

Sorry for such a stupid question, but I'm stumped (it doesn't take much).
modprobe reports that hotplug_path is unresolved when it processes
usbcore. CONFIG_HOTPLUG is defined, so it seems that hotplug_path is
defined and EXPORTed in kernel/kmod.c, so I'm unsure what the problem is.

Thanks, Ryan

Re: [QUESTION] 2.4.3: hotplug_path unresolved in usbcore?

[Bart Trojanowski]

On Wed, 4 Apr 2001, Ryan Mack wrote:

> Sorry for such a stupid question, but I'm stumped (it doesn't take much).
> modprobe reports that hotplug_path is unresolved when it processes
> usbcore. CONFIG_HOTPLUG is defined, so it seems that hotplug_path is
> defined and EXPORTed in kernel/kmod.c, so I'm unsure what the problem is.

I have noticed that sometimes when I change my .config doing a make dep,
make bzImage, make modules, is not enough.  So, I back up my .config, run
make mrproper, copy the .config back, and then make dep, etc.  The option
I know causes this is netfilter under 2.4.2.

> Thanks, Ryan

Hope this helps.
Bart.

-- 
	WebSig: http://www.jukie.net/~bart/sig/