Kernel 2.6.0-test2 and qm_modules error

From Thomas Adam

Answered By: Thomas Adam, Kapil Hari Paranjape, Jim Dennis

Dear All,

I decided to upgrade my kernel from 2.4.20 to 2.6.0-test2. "No probem", I thought. So off I trotted to www.kernel.org, selected my UK mirror and downloaded it, and bunzip/untarred it in /usr/src.

I had planned to implement an ACPI/swsusp patch so that I could effectively make use of some of the more advanced features of my laptop in terms of power management. I applied to ACPI patch fine, but the swsusp patch didn't work, so I removed it.

I copied my /boot/config-2.4.20 to /usr/src/.config and ran a "make menuconfig". Yay, no problems. I simply added my ACPI settings, eye-balled the rest of the options, removed support for things like ADFS and AFS (Andrew's File System) and did a classic:

fakeroot make-kpkg --revision=rev0.1 kernel_image modules_image

Prior to this I had installed and setup "ccache". For those of you who haven't got this: "apt-get install ccache". Seriously, I recommend it. It makes successive compilations much faster; by ccache caching the results. But I digress...

The make went fine, and I was soon "dpkg -i ../kernel_image-rev0.1*.deb" I did notice that as this was happening, I got a lot of "** Unresolved Symbols **", but that was alright, because it was in modules that I was never really going to load, and had put them there for a "just in case" scenario.

So I went through the motions of "liloconfig" et al and was soon rebooting my nice new kernel. I have to say that I am impressed thus far with 2.6.0-test2. Finally Framebuffer support is getting better with the maintainer of that section actually removing that huge flashing block and replacing it with a static "_" cursor

As I watched the screen, nothing out of the ordinary was happening, and I was soon at a login prompt. I did notice that "acpid" (the acpi software control) didn't load due to "QM_MODULES function not implemented". Odd I thought. So I logged in (as 'root'), and did a:

lsmod

hmm, I got the following error message:

QM_MODULES function not implemented

"Ok", I thought, how about this:

depmod -a

hmm, same error message.

I wasn't sure what was causing this error, and it was nothing that I had seen before. So I did the following:

cd /usr/src/linux-2.6.0-test2 && find . | xargs grep -i qm_modules

...guess what? I got nothing! Grep had let me down . So now I am thinking that maybe the error isn't listed in any of the textual based files but that it is statically built into the ".o" files. So....

find . | xargs strings | grep -i qm_modules

...sigh. Nothing, zilch. Of course this last command is slightly superfluous because in order for the string "qm_modules" to be there, it would have to come from one of the ".c" files that created the compiled object file, but I couldn't see how the command could hurt. Now what should I do???

.... enter "strace" One of my friends. At this point I was thinking that maybe I should see just where the "depmod -a" command was failing. Why did I choose this command and not "lsmod"? Well, in order for the kernel to know about it's modules and dependencies, it has to make use of "/lib/modules/$(uname -r)/modules.dep". So, I typed:

strace -o ~/.strace/depmod_2.6.0-test2 depmod -a

had a quick look in the file and yes, sure as I was I could see it complaining about "qm_modules". Pah, makes no sense to me, really.

What I did next was to boot my "old" 2.4.20 kernel. "liloconfig" is sufficiently clever to actually keep your old kernel for you. I did that, and ran:

strace -o ~/.strace/depmod_2.4.20 depmod -a

had a look and that worked fine. Hmmmm, what could be wrong? I ran a "diff" on the two files, but my brain just cannot make any head nor tail of what it all means.

I cannot see what, or more importantly where the "QM_MODULES" function exists. The fact that grepping the kernel source tree returns no results, suggests that this is a function that is called from no where within the kernel but rather externally, perhaps from one of the rarer "glibc" libs?

I tried a google/linux search, but found nothing conclusive. Perhaps I have compiled something incorrectly in the kernel? I have tried compiling it many times now, but still the same result. While I am aware that 2.6.0-test3 exists, the ACPI patch only works for the test-2 branch.

Three files to help you...

1. depmod_2.4.20 2. depmod_2.6.0-test2 3. diff

They can be found here:

http://www.darksatanic.net/ta

My thanks to Hugo Mills for very kindly hosting them. Cheers, Hugo

(number 3 is the difference between the two files. I neglected to do a unified diff).

Any ideas, tips, points of error would be appreciated.

[Kapil]

Hello,

On Tue, Aug 12, 2003 at 11:48:28AM +0100, Thomas Adam wrote on the problems he had with the upgrade from 2.4.20 to 2.6.0-test2.

1. Problem with module loading.

2. Problem with Software Suspend (swsusp).

Has any tagger got 2.6.0-testn working successfully?

I did manage to solve problem (1) --- one needs a newer version of modutils.

[JimD] :r!ssh vega.starshine.org uname -r 2.6.0-test3

I've been running 2.5.x and 2.6.x kernels most of the time for most of the last year on vega (my living room desktop system). One of my housemates (Tabitha) used that system's console more than I did for most of the last year (she was made to sit in the "comfy chair" ). I used it quite alot from the other machine in the living room (usually booted off of KNOPPIX, with ssh and X11 forwarding making it mostly just a really smart terminal). (An Xterminal with a local running copy of OpenOffice.org ... hmmmm).

[Kapil]

Problem (2) eludes me. The swsusp patch from swsusp.sf.net for 2.4.21 is working fine with 2.4.21. I notice that swsusp in 2.6.0 has run into stormy weather developer-wise so maybe that's the reason.

My main reason for trying out 2.6.0-textn was the support for the i815 framebuffer---just can't do without the Penguin at boot-time

[Thomas]

I did mention that the original reason I was using 2.6.0-test2 was to do with the swsusp patch. Because 2.6.0 at the time was VERY new (in terms of the latest stable release), the swsusp people hadn't yet released one that would work with that version -- hence I dropped it from my patch'd kernel.

I did, however, apply the ACPI patch so that actions such as "lid_close" on my laptop would be registered by the kernel.

Having updated "module-init-tools" (as I mentioned in my original thread to this) it still didn't work -- what I did do to try and fix it was to NOT use "make-kpkg" to compile the kernel. This then fixed my problem.

The only thing i can think of here (albeit loosely) is that fakeroot caused some weird permissions and/or the package that was produced was corrupt somehow.