On Sat, 14 May 2005, [EMAIL PROTECTED] whispered secretively:
> On Saturday 14 May 2005 02:00, Nix wrote:
>> On Sat, 14 May 2005, [EMAIL PROTECTED] spake:
>> > What's your host processor? Can you try upgrading to UML 2.6.11-bs5? I've
>> > recently fixed one problem with this checking, which affected a VIA C3
>> > Samuel2 (because it didn't support PTRACE_GETFPXREGS). cat /proc/cpuinfo
>> > will reveal the presence of the "fxsr" feature; if it's missing upgrade
>> > as I said and you'll get the fix.
>
>> That's probably it: there's absolutely no chance that this 1997-vintage
>> Pentium has fxsr :)
> Well, so thanks for running GDB, because otherwise I'd never have linked to
> that problem.
I tend to assume that nobody can get anywhere debugging a problem
without at least a traceback, especially if it comes with as little
attached information as that panic did.
> How much does it takes to compile a UML kernel? (Have you
time(1) says
1838.05s user 241.21s system 85% cpu 40:29.98 total
for this kernel (with iptables and traffic shaping adding about ten
minutes to that).
> *only* this Pentium or is it an auxiliary machine?)
It's my pandemonium host (i.e. it runs most of the internal-network-visible
daemons) and my firewall host (running the UMLs that are the firewall ---
obviously those UMLs run very little themselves!)
It's not usually my desktop, but it can run X and has been known to do
desktop duty when my i686 is dead from yet another fan failure. (The
actual desktop programs run on an UltraSPARC in any case.)
>> , but I'll do a test build tonight and check it in the morning.
Hm, well, it failed, because you link against -lutil but don't have any
library search paths set up in vmlinux.lds. Trivial fix, which doesn't
use quite the same (arch-dependent) search path as the usual scripts,
but which certainly should suffice to catch libutil:
--- linux-2.6.11.9-bs5/arch/um/kernel/vmlinux.lds.orig 2005-05-14
11:54:40.000000000 +0100
+++ linux-2.6.11.9-bs5/arch/um/kernel/vmlinux.lds 2005-05-14
11:53:30.000000000 +0100
@@ -3,6 +3,8 @@
ENTRY(_start)
jiffies = jiffies_64;
+SEARCH_DIR("/lib"); SEARCH_DIR("/usr/lib"); SEARCH_DIR("/usr/local/lib");
+
SECTIONS
{
PROVIDE (__executable_start = 0x8048000);
With that fix, it works :) --- well, it gets far enough to panic because
my quick test didn't bother with anything as radical as an actual root
filesystem.
Again, thank you!
--
`End users are just test loads for verifying that the system works, kind of
like resistors in an electrical circuit.' - Kaz Kylheku in c.o.l.d.s
-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
User-mode-linux-user mailing list
User-mode-linux-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
