>> >Don't build 2.0.34 with gcc 2.8.x/egcs.
>>
>> I originally thought that this was the problem, however I recompiled my
>> kernel with gcc v2.7.2.3 and the problem persists.
>
>Run strace and gdb on the pnp tools. If they make a syscall to iopl(3)
>then fault on an inb/outb instruction according to gdb then you are
>running your 2.8.x kernel still
>
Very weird problem. Well I used strace and gdb. pnpdump does call
iopl(0x3) and then dies, after several more system calls, at an outb
instruction. (ex. out1) I assume that you meant it died right after calling
iopl(0x3), besides which I noticed that pnpdump also apparently called outb
several times before dying at an outb instruction. (ex. out2) And as far
as the kernel goes, it says that it was compiled by gcc 2.7.2.3. (ex. out3)
I downloaded a 2.0.34 kernel from another one of my machines, compiled by
2.7.2.3 and, to the best of my recollection, only differing in its choice of
CPU optimization and non-inclusion of CMD and RZ1000? EIDE chipset bug
workarounds. (486 instead of Pentium) When booting with that kernel
pnpdump worked. This seams to narrow the cause to some piece of gcc 2.8.1
object object code laying around. By the way I again recompiled my kernel
today. Same as last time, "make dep && make clean && make zImage && make
zlilo && make modules && make modules_install". And the problem remains. I
am assuming that the previous commands should build the kernel from scratch,
except for the comfiguration. Is there a bug in "make clean" perhaps, not
getting rid of all the old object files? Thanks for any help.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu