Anybody got 2.4.0 running on a 386 ?

Hi list,

I can't seem to get the new 2.4.0 kernel running on a 386 CPU. The kernel was built for a 386 Processor, Math emulation has been enabled. I tried three different 386 boards. Execution seems to get as far as pagetable_init() in arch/i386/mm/init.c, then it falls back into the BIOS as if someone had pressed the reset button. The same kernel boots fine on 486 and Pentium Systems.

Any ideas/suggestions ?

Rob

----------------------------------------------------------------
Robert Kaiser email: [email protected]
SYSGO RTS GmbH
Am Pfaffenstein 14 phone: (49) 6136 9948-762
D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

is "Checking if this processor honours the WP bit even in supervisor mode... " the last thing you see before the reset?

--

Brian Gerst
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

No, I don't see _any_ messages from the kernel. The last thing I see is "Uncompressing Linux... Ok, booting the kernel." I have added some quick and dirty debug code that writes messages directly to the VGA screen buffer. According to that, execution seems to get as far as the statement

        *pte = mk_pte_phys(__pa(vaddr), PAGE_KERNEL);

----------------------------------------------------------------
Robert Kaiser email: [email protected]
SYSGO RTS GmbH
Am Pfaffenstein 14 phone: (49) 6136 9948-762
D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Could it be possible that memory size is being misdetected? Try mem=8M (or less) on the command line. Try to catch the value of pte when it crashes.

--

Brian Gerst
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

How about this patch (untested)? max_low_pfn should be a global var...

diff -urN linux-2.4.0/arch/i386/kernel/setup.c
linux/arch/i386/kernel/setup.c

@@ -598,7 +598,7 @@
 void __init setup_arch(char **cmdline_p)
 {
        unsigned long bootmap_size;
-       unsigned long start_pfn, max_pfn, max_low_pfn;
+       unsigned long start_pfn, max_pfn;
        int i;
 
 #ifdef CONFIG_VISWS

--

Brian Gerst
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

I tried "mem=4M" -- no effect. The value of pte is 0xc0001000, so it seems to be the first invocation of that statement in the for() loop.

Now comes the amazing (to me) part: I split the above statement up into:

	temp = mk_pte_phys(__pa(vaddr), PAGE_KERNEL);
	*pte = temp;

where temp is declared "volatile pte_t". I inserted test-prints between the above two lines. Accoding to that, the _first_ line , i.e. the evaluation of the mk_pte_phys() macro is causing the crash!

I am still trying to figure out what mk_pte_phys() does. Apparently it involves an access to the kernel's data section. My current guess is that the data section is not correctly mapped at this point. Would that be possible ?

----------------------------------------------------------------
Robert Kaiser email: [email protected]
SYSGO RTS GmbH
Am Pfaffenstein 14 phone: (49) 6136 9948-762
D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

** Reply to message from Robert Kaiser <[email protected]> on Tue, 9 Jan 2001 23:17:11 +0100

In that case, it's either a compiler bug or a race condition.

Compiling this source file with the -S option will generate an assembly output. The output should be the same regardless of whether you use the temp variable or not. That will answer the question as to what the cause is. If you're lucky, it's a compiler bug, because they're easier to fix.

Timur Tabi - [email protected]
Interactive Silicon - http://www.interactivesi.com

When replying to a mailing-list message, please direct the reply to the mailing list only.  Don't send another copy to me.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

this is almost impossible (except some really weird compiler bug) - unless the mem_map address is invalid. This could happen if your kernel image is *just* too large. Do things improve if you disable eg. ext2fs support (i know, but should be enough to boot). Or if that part is not mapped correctly (which does happen sometimes as well).

and are you sure it crashes there? [are you putting delays between your printouts?]

it accesses mem_map variable, which is near to the end of the kernel image, so it could indeed something of that sort. An uncompressed kernel image (including the data area) must not be bigger than 4MB (IIRC).

Ingo

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

How much physical memory does this box really have?

--

Brian Gerst
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

The one I'm currently using is an old Olivetti 386SX with 5 MB, I also tried two more boards, one 386SX, one 386DX, both with 8MB. All showed the same behavior.

----------------------------------------------------------------
Robert Kaiser email: [email protected]
SYSGO RTS GmbH
Am Pfaffenstein 14 phone: (49) 6136 9948-762
D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

How big is the kernel image? Are you making a zImage or bzImage?

Anuradha

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

I'm using bzImage. It's size is 566964 bytes.

According to System.map, Symbol _end is 0xc0252cf0. That would mean the uncompressed kernel size would be 1387760 bytes (0xc0252cf0-0xc0100000), right ?

----------------------------------------------------------------
Robert Kaiser email: [email protected]
SYSGO RTS GmbH
Am Pfaffenstein 14 phone: (49) 6136 9948-762
D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Sorry, no ext2fs in this kernel (it is for a diskless embedded system). I seem to recall though that the problem at one point magically went away when I disabled the FPU emulation, but I have not been able to reproduce this recently, so I'm not sure. Making minor changes to the kernel code (such as adding/removing some test-prints) certainly does not affect the behavior.

What could I do to check/fix this ?

I have put a "halting statement" (i.e. "while(1);") after my printouts to make sure execution does not go any further than that point. I moved this halting statement ahead in the code line by line until the crash would occur again. So, yes, I am pretty sure.

According to my System.map file, mem_map is at 0xc0244f78. Does that help ?

----------------------------------------------------------------
Robert Kaiser email: [email protected]
SYSGO RTS GmbH
Am Pfaffenstein 14 phone: (49) 6136 9948-762
D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Here's a tip for anyone who has to track down bugs of this nature. To greatly speed up work, just use a binary search technique. That is, go to the section of code that's causing problem, put a breakpoint or similiar half-way. If it dies before that point, move it back half way, after that point, move it forwards half way. Iterate until you find the place.

Cheers,
Alex

If PacMan had affected us as kids we'd be running around in
dark rooms, munching pills and listening to electronic music.

http://www.tahallah.clara.co.uk

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

math-FPU emulation takes up quite some space in the kernel image, so this could indeed be the case. Could you disable any non-boot-essential subsystem (networking, or the serial driver, or anything else), to significantly reduce the image size?

i had this a couple of times while doing the 3-level pagetables and related highmem stuff (and i might even have added this bug ...), and typically i just printed out the pagetables to a serial console and analyzed them manually :-|

(okay, that certainly is a proof. I had to ask.)

not really. Could you write a small function that just reads the kernel image from the first symbol to the last one, and see whether it crashes? (read it into a volatile variable to make sure GCC reads it.) Kernel image goes from _stext to _end - you can access it with something like this:

void test_image (void)

{
	extern char _stext;
	extern char _end;

	volatile char data;
	char *ptr = &_stext;

	while (ptr < _end)
		data = *ptr++;
}

another problem could be if the kernel image is in a place that is somehow invalid physical RAM. We uncompress it into address 1MB physical (and assume there is enough space from that point on to uncompress successfully, without actually checking it), which should work on all 'PC architecture compatible' systems. (other bootloaders use this method frequently as well.)

Ingo

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

you should also try to access the mem_map variable directly, in some simple way. Could you print out the value of mem_map btw.? [This should rule out any compiler interaction.]

Ingo

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Hi Rob,

Just out of curiosity, did you use a 2.2 series .config file and then run make oldconfig or did you build a new .config file from scratch?

I have periodically built kernels that crashed immediately at the point you mention. Usually this was due to me choose configuration options that were incompatible with my machine's hardware.

Another time, the machine wouldn't boot because I needed a new version of LILO. I also have seen at least one machine where I needed to specify "linear" as one of the options in lilo.conf. If you aren't specifying "linear" now, give it a try.

IIRC, here's my litany of goofed configurations:

Building support for multiple framebuffer devices. Apparently, the kernel would hang in the chip detection process.

Wrong CPU architecture.

Wrong IDE chipset specified.

Built EXT2 as a module, but / was on an EXT2 partition.

I may have hit some other bogus configurations over the last two years, but these are ones that come to mind.

Miles

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

^^^

This may be off the wall, but since the 386 is diskless the kernel was obviously built elsewhere. Had that tree previously been used for a 486 build? You might decompile vmlinux and look for non-386 instructions at or prior to the crash point.

It might be faster to recompile from 'make mrproper' and see if it works then.

Tom
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Hi Miles,

Thanks very much for your suggestions!

No, I built it from scratch with make xconfig.

You mean they crashed at the exact same statement ? That would be an interesting hint, can you confirm it ?

I am not using LILO (yet). I tried booting with SYSLINUX or by dumping the kernel binary to floppy and booting from it. Both showed the same result.

----------------------------------------------------------------
Robert Kaiser email: [email protected]
SYSGO RTS GmbH
Am Pfaffenstein 14
D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

I tried this: apparently no effect. However, there may be hardware issues involved (see below).

I tried this: Reading the entire image never caused any crashes.

However, I did have some (rare) instances of the kernel booting successfully. Then it would fail again, booting the very same image that had worked before.

I am beginning to suspect that I may be dealing with flaky hardware. (I'm working from home today and I only have access to one of my 386 specimen here).

I guess I'll better shut up until I can double check on some other 386 boards tomorrow....

In the meantime, it would be helpful if anyone who has successfully booted a 2.4.0 kernel on a 386 could report this to the list.

----------------------------------------------------------------
Robert Kaiser email: [email protected]
SYSGO RTS GmbH
Am Pfaffenstein 14
D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

I dug up an old amd 386 and started compiling kernels for it with gcc 2.95.2:

2.4.0 : doesn't boot, same symptoms as you, Robert, so you're not imagining

	things :-)

2.2.19pre6 : compiles, boots and runs poifectly
2.3.51 : doesn't compile
2.3.99-pre1 : hrm, *cough*
2.3.99-pre2 : *tsjoum*
2.3.39: compiles and boots okay

here is where I got bored :-)

okay, anyone, which 2.3.x kernels should compile okay ?

With kind regards,
Sven

If the odds are a million to one against something occurring, chances
are 50-50 it will.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

move up to 2.4.0-testX kernels

--

Brian Gerst
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Robert Kaiser wrote:

<snip>

I sent the "possible config problem" list mostly as a warning about what can cause kernels to lock up early in the boot cycle. Some of the problems I ] mentioned will cause a lock up immediately after the "Uncompressing kernel... OK Booting Linux" message.

I doubt that these problems are causing your problem and so I really doubt that these crashes are occuring in the same function that yours is.

Mostly, I thought you might want to double-check your configuration options and make sure that you are using none of these broken configuration combinations.

Good luck! I wish I could be of more help.

Miles

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

I had no problems booting an AMD 386DX/40 with 32 megs of RAM. I just dumped a bzImage (703K) to a floppy and it booted on that just fine.
Kernel was built using egcs-1.1.2 from RH 6.2

If I build the same kernel on a RH7 system using gcc 2.96 (gcc-2.96-69) the machine reboots after "Uncompressing Linux... Ok, boot the kernel" no more text is printed.

.config is available on request.

-tgc

Tom G. Christensen, Denmark <[email protected]>
Homepage: http://hjem.get2net.dk/tgc
Linux 2.2.16-3 on an i586



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

I have seen a number of reports claiming something broken in 2.4.0 for DRI.

I have tested under 2.4.0 and 2.4.0 test 12 with the exact same setup.

I see a slight variation in frame rates under the release version, but so small as to be within statistical varience.

Everything else seems to work in reguards to DRI and AGPGART so far. (Of course, the X server on my desk will now explode since I said that...)

I have noticed that the framerate takes a hard nosedive if xinerama is turned on, but that is explained in the docs.

I have not seen any "flashing" behaviour or any other reported weirdnesses.

Maybe it is the sacrifices made to dark penguin gods during that last full moon.

[email protected] | Note to AOL users: for a quick shortcut to reply
Alan Olsen | to my mail, just hit the ctrl, alt and del keys.
"In the future, everything will have its 15 minutes of blame."

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

I just tested 2.4.0-test1, it doesn't boot on the 386 with the same symptoms as 2.4.0.

2.3.99-pre9 same.

2.3.99-pre8 is the last one that boots correctly.

There is one weird thing I notice, the vga-bios-screen at boot-up is monochrome every other automatic reboot.

with kind regards,

Sven

If the odds are a million to one against something occurring, chances
are 50-50 it will.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Changing the

	if( end && (vaddr >= end))
		break;
just before that snippet of yours (I believe it's on lines 379-380) into
	if (vaddr >= end)
		break;
or alternatively adding
	if (!end)
		break;

between if(end &&...) break; and *pte = mk_...; produces a kernel bootable on 386.

With kind regards,

Sven Joos

If the odds are a million to one against something occurring, chances
are 50-50 it will.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

I tested 2.4.0 on probably the exact same box - an Olivetti M300-05 386sx with 5MB and it came up ok, except that memory detection is off by a MB. (to be fixed in 2.4.1 or boot with mem= argument in 2.4.0)

What might be important here is your gcc & binutils (as/gas) version, combined with a miscompile in something like __verify_write that doesn't get used on anything but 386 (and hence went undetected).

Only thing strange on my box is that the kernel is compiled with gcc-2.7.2 which is officially unsupported but can be managed if you know what the gcc bugs are.

Paul.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Hi everybody,

I finally found the reason why 386es have trouble booting the 2.4.0 kernel:

In routine pagetable_init() in arch/i386/mm/init.c, a pte gets installed before it actually has been filled with valid entries. This causes the kernel text segment to be temporarily unmapped. Pentiums are only lucky to not crash because they have a bigger TLB than 386s.

Here is a patch to fix this:

@@ -317,7 +317,7 @@
 	pgd_t *pgd, *pgd_base;
 	int i, j, k;
 	pmd_t *pmd;
-	pte_t *pte;
+	pte_t *pte, *pte_base;
 
 	/*
 	 * This can be zero as well - no problem, in that case we exit

@@ -366,11 +366,7 @@
 				continue;
 			}
 
-			pte = (pte_t *) alloc_bootmem_low_pages(PAGE_SIZE);
-			set_pmd(pmd, __pmd(_KERNPG_TABLE + __pa(pte)));
-
-			if (pte != pte_offset(pmd, 0))
-				BUG();
+			pte_base = pte = (pte_t *) alloc_bootmem_low_pages(PAGE_SIZE);
 
 			for (k = 0; k < PTRS_PER_PTE; pte++, k++) {
 				vaddr = i*PGDIR_SIZE + j*PMD_SIZE + k*PAGE_SIZE;

@@ -378,6 +374,10 @@
 					break;
 				*pte = mk_pte_phys(__pa(vaddr), PAGE_KERNEL);
 			}
+			set_pmd(pmd, __pmd(_KERNPG_TABLE + __pa(pte_base)));
+			if (pte_base != pte_offset(pmd, 0))
+				BUG();
+
 		}
 	}
 

Thanks to everybody who helped with ideas and suggestions, especially Ingo Molnar!

Cheers

Rob

----------------------------------------------------------------
Robert Kaiser email: [email protected]
SYSGO RTS GmbH
Am Pfaffenstein 14 phone: (49) 6136 9948-762
D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Good job.

Actually, with the 4M pages, it's not a question of luck any more - they just don't _have_ this bug, because on a machine with 4M pages the "cpu_has_pse" case handles this all and the buggy code is never actually entered.

Which explains why you'd only see this on a 386 (and I suspect your TLB size explanation is what saved some i486-class machines, although later i486 machines will have PSE as well).

Thanks,

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/