The Minimal Install CD no longer supports a 486 processor. Trying previous versions, the last one that will boot without an "Illegal Instruction" is 2006.0. Reproducible: Always Steps to Reproduce: 1. Boot Minimal Install CD version 2006.1, 2007.0, and 2007.0-r1 (any kernel options will do. You won't get far) 2. Watch as "Illegal Instruction" and a stack trace show up practically immediately Actual Results: Nothing. That is the problem. Expected Results: Not halted with "Illegal Instruction"
CC'ed releng for confirmation
It *should* work on i486 just fine. Both the stage 2 and 3 that were used to build the CD were built with the following: CFLAGS="-O2 -mtune=i686 -pipe" CHOST="i486-pc-linux-gnu" and neither of these were changed for the minimal CD. This is either a bug in glibc (it generates different asm based on the CHOST, and it could be acting up) or a bug in gcc (-mtune using instructions for i686 instead of just optimizing while using i486 instructions). Additionally, the LiveCD and LiveDVD are definitely i686-only. It was also a known issue that the 2006.1 x86 minimal CD did not work on <i686. This was due to setting an i686-pc-linux-gnu CHOST in one of the stage specs in an attempt to fix another bug and not setting it back. We made sure this wasn't the case in the 2007.0 release.
My guess is no one has used this on real 486 style hardware for a long time. This is actually very similar to the sparc port of Gentoo, in that, practically no one used Gentoo on sparc32 hardware, and while support was intended, no one noticed it started breaking the further you got down the line. It got to the point where someone finally said "Anyone willing to keep maintaining sparc32 please stand up, because as far as we see, no one has anymore interest". This may be true here in this case too. I am not really fighting such a looming decision, but rather, would like documentation to reflect it. I have tested this on both an Intel 486 DX 33 and a Cyrix MediaGX 133 processor machines, both with the same result. I can offer to give you the exact position the illegal instruction occurs in the kernel boot sequence, if you think it will help. It happens pretty immediately, so I figured it wouldn't have been much use in my originating bug post.
No, these releases are not tested on 486 (or even 586 hardware). Also, comparing i486 vs. i686 to sparc32 vs. sparc64 isn't really the same. It's more like comparing a v7 sparc32 to a v8 sparc32. sparc32 is essentially a completely separate architecture (think x86 vs. x86_64). What point during the boot process is it? Is it in the kernel? initramfs? after it switched to the loopback image on the CD? What's the last few lines you see before you get SIGILL?
This IS in the kernel. Also keep in mind, I tried this with and without the 'nosmp' kernel param. I mention this because the invalid opcode SEEMS like it may relate to SMP. Here are the last things I see (can't be but a few lines down from kernel loading): Checking if this table honours the WP bit even in supervisor mode... Ok. Mount-cache hash table entries: 512 invalid opcode: 0000 [#1] SMP Modules linked in: CPU: 0 EIP: 0060:[<c03df849>] Not tainted VLI EFLAGS: 00010286 (2.6.19-gentoo-r5 #1) eax: 00000001 ebx: c1048200 ecx: 00000000 edx: 00040000 esi: 00000000 edi: c0421ca8 ebp: c0421c80 esp: c0425fac ds: 007b es: 007b ss: 0068 Process swapper (pid: 0, ti=c0424000 task=c03ee440 task.ti=c0424000) Stack: c0421c80 c1048200 c017f6b6 c03bd041 0000016d c1048200 c0467b64 c1044c64 00008000 c042a698 c0421c80 c046b620 c03ed4fc 00000047 c042a1e4 c046b620 00000000 00039100 c0417000 004c1007 00000000 Call trace: [<c017f6b6>] <0> [<c042a698>] <0> [<c042a1e4>] <0> ======================= Code: b0 01 89 f1 0f a2 89 55 10 89 4d 24 81 ff 03 00 00 80 76 08 89 2c 24 e8 b3 fa ff ff 89 2c 23 e8 6e 16 00 00 b8 01 00 00 00 31 c9 <0f> a2 c1 eb 18 88 9d 93 00 00 00 c7 04 24 30 44 3a c0 e8 95 6f EIP: [<c04321e5>] SS:ESP 0068:c0425fac <0>Kernel panic - not syncing: Attempted to kill the idle task!
The kernel was built with CONFIG_M486=y, so there shouldn't be a problem there. I'm not sure what happened. Have you tried booting 2006.0 on the machine recently? Perhaps it's a hardware problem.
I would have to disagree that it is a "hardware" problem as in bad hardware. 2006.0 boots the kernel. Nothing after it will. Like I said before, I tried this on two COMPLETELY different machines. Nothing about them is the same, not even the ram type. I have done a diff on the 2006.0 and 2006.1 to look for any changes that may be of consequence here. Oddly enough, the 2006.0 kernel actually has CONFIG_M586=y instead of CONFIG_M486=y as in the 2006.1 kernel, but that one boots on my 486, so I am inclined to think that these CPU flags don't have as much effect as you would think. Also, 2006.1 has CONFIG_X86_GENERIC=y where it isn't set in 2006.0. It just doesn't seem right, as it seems that 2006.1 actually had a MORE generic kernel based on the config files, but it flat out fails. Lastly, The 2006.1 kernel has L1_CACHE_SHIFT=7 where 2006.0 has L1_CACHE_SHIFT=5. From what I gather, L2 Cache is divided into X lines of Y bytes... where Y is the size of this param... so is it expecting more actual L1 Cache?
considering L1 isnt visible from the core (in terms of being able to address it), i doubt that is terribly relevant beyond a pure performance point of view considering it crashes in the kernel, sounds like glibc is off the hook you should take the 2006.0 cd, boot it, install Gentoo, copy the kernel off that cd onto your machine, and reboot into it ... then build up the same kernel version as is on the 2006.1 cd but using the 2006.0 .config and see if that helps the issue is this ... you say 2006.1 is broken on 486 and your tests seem to back this claim up; however, Gentoo peeps tend to lack 486 hardware to even test on (assuming they even care to test in the first place), so if you want this resolved you'll most likely need to do the testing/research
Mike is completely right here. While I have no problems supporting such old hardware, not having access to it is a major factor in our inability to fully support it. Age is another. Do we really need to be spending $x hours trying to make sure our media works on hardware that's been considered obsolete for more than 10 years? Obviously, the answer is no. That being said, if someone were to say to us "If you change $foo, it'll work on i486" we would gladly fix the problem. It all really boils down to what we can support with our limited resources. Also, everything *should* work, as stated by everyone else. If something isn't working here, it is definitely something we'd like to look into, since things are not performing in the expected manner. It is one thing to accidentally do something (like setting CHOST=i686) to disable older support. It is another entirely to set everything up correctly and it still not work.
Re-assigning to Releng (hi guys!). Seems to be hardware issue/boot support, so this is their turf. I'll leave us CCed though so that we can work with releng on any doc changes that need to happen, but for now, the primary assignee should be releng.
Since I brought this to everyones attention, and since I have the hardware, I am willing to dig in and start debugging the matter. I will get on things tonight and hopefully sometime tomorrow have something to report.
Thanks, Jason. I am going to build up a new minimal CD for you to test, also. It might take me a little while because of unforseen complications, but I'll let you know when I have one ready for you to test.
Hey guys. I didn't bail on you. I just got caught up in work. I'll let you know what I find.
Jason, I have built a new CD that I would like for you to test, if you can. I'm sending you an email with instructions on how to get it. Just follow the directions in the email and let me know if it doesn't work.
Can anyone verify this with the 2008.0 Beta 1 media?
(In reply to comment #15) > Can anyone verify this with the 2008.0 Beta 1 media? > I can't veryfy in real hardware but under kvm [Kernel Virtual Machine] 2008.0 beta1 boots fine =)
What exactly does that have to do with booting it on i486 hardware?
Any real need to keep this open? I see that the GDP is still CCed on it. I'm fine with changing our docs to say that at least i586 is necessary to boot, though I'm sure that all 7 i486 users would be sorry to see the media go. ;)
The 2008.0 minimal *should* boot just fine on i486 hardware. However, we haven't had any testing, afaik.
Well, if we don't have any testing, do we really want to keep it? Or just bump everything up to something like i586 or i686, and adjust our requirements in the docs. The i586 camp includes older VIA chip users; slightly more widespread than i486. Who uses i486, anyways? If we don't, and we have no way to test....then why provide support for it?
There's no reason *not* to support it. It doesn't take us any extra effort to retain support for it. It's just that the support can't be tested on a regular basis.
As far as we know, the cause of this one has been fixed. Please reopen if current media exhibits this problem again.
