I am seeing the same exact fault on FCT2 installed on an MS Virtual 
PC. The hardware driver is an S3 Trio 64. I have reinstalled three 
times with the same error. I can reproduce the error at will <G>...

Resolved on FC2 T3 (with Virtual PC). Thanks.

X.org X11 hasn't changed at all.  This must have been caused by the
kernel's buggy vm86() code which was fixed recently.  That caused
a SEGV to occur in vm86() on any video driver which used the video
BIOS.

Bug alias of the vm86 issue is "vm86-segv" for reference.

Crap, this is not fixed (my bad). I was thinking of something else
(anaconda). In my haste I closed the bug. It's still a problem when
RHGB tries to load on FC2 T3. Same error with unicode_start $SYSFONT
$SYSFONTMATCH on line 80. Repoened.

unicode_start has nothing to do with X.  It sounds to me like you're
having 2 problems:

1) Your X server isn't starting

2) You're getting an unrelated error about unicode_start from
   rc.sysinit or some other initscript

We don't support Virtual PC installations, however if you attach
your X server log and config file, and /var/log/messages, I will
review the issue anyway in case it is something obvious.

Thanks in advance.

When I switch to the VCs, every command returns a segfault error. What
is the best way to export the logs on a system that will not boot?

FYI - I tried a "linux rescue" and /mnt/sysimage/var/log/messages is 0
bytes.

If every command is segfaulting, then that very definitely is not
an X specific error or bug.  Most likely this is a problem caused by
using VirtualPC instead of a real machine.  Please try using real
x86 hardware and if the problem persists, feel free to reopen the
report.

Closing as NOTABUG

Another engineer just mentioned to me also, that the 2.6.x kernel
contains polymorphic code, and Virtual PC doesn't support that.
That could be the problem you're experiencing perhaps.

Just thought I'd mention that in case it saves you time trying to
find an alternate solution.

Hope this helps.

Hell of an answer guys. Maybe you should be passing this on to Linus 
then. It's comments like this that make it easy for corporations to 
stay in the Windows camp. I would suggest you find a way to make it 
work...

It's not Red Hat's fault that VPC will not support "polymorphic code".
Yes, it sucks, but that's just the way it is. I believe VMWare has
committed to 2.6 kernel support and other features like 64 bit
extensions. At the same time, Microsoft has removed official Linux
support from Virtual PC. Perhaps people like you and I should
reevaluate our virtualization systems and choose a more Linux friendly
vendor. 

Hi Marlin,

I'm sorry you seem to be upset with Red Hat however I think there
is a bit of a misunderstanding and I would like to try and resolve
that and help you to find a workable solution if possible.

First I'll try to resolve the misunderstanding through a bit of
explanation and clarification, and then I'll make some
recommendations that may help you to find a reasonable solution
that meets your real needs.


Background:

The Virtual PC problem seems to be that it does not support
polymorphic code.  I am not a kernel engineer myself, however I've
briefly discussed this issue with a few kernel engineers.  To the
best of my current understanding, the Linux kernel uses
polymorphic code for patching in code optimized for the running
processor at boot time, which is a very important feature of the
current Linux kernel, as it allows for a single binary kernel to
support many CPUs, while also containing optimizations for all
common CPUs, rather than being optimized for a single CPU.  This
feature also benefits Red Hat and our customers, by allowing us to
support more processors with fewer kernels, which in turn has a
major engineering cost savings that allows us to develop more
features for our next generation products, and to do so in much
less time.

The problems experienced by the reporter, yourself and perhaps
others, are allegedly due to a design flaw in Virtual PC itself,
and there may be various other problems as well.  If Red Hat did
support Virtual PC officially, since this is a design flaw in
Virtual PC, and not a bug in the OS that is causing the problem,
the only way that these issues could really be resolved, is for
the Virtual PC vendor to modify their proprietary software to
support the 2.6.x Linux kernel properly, and to address any other
flaws in the software which prevent it from being able to use
modern Linux systems.  It seems that VirtualPC may be intentionally
not supporting Linux, and unfortunately there isn't much that
Red Hat can do about that, however we may be able to provide some
other type of solution that meets your needs, and I'll discuss that
further below.

Assuming we were to contact Linus about this, we have no influence
over Linus's decisions, and both Red Hat and our customers support
and benefit from this feature greatly.  Except for VirtualPC users
perhaps.  ;o)

Bugzilla bug reports come to engineering, and while we do not
make the decisions of what platforms Red Hat supports, we do have
to honour this.  Even though Virtual PC is unsupported, I did try
to acquire further information in case I was able to do something
on my own anyway, however once I was able to conclude that the
problem was caused by a design flaw in Virtual PC, since that is
beyond Red Hat's support policies and beyond Red Hat's reach of
being able to fix, I closed this as NOTABUG, although NOTOURBUG
would probably be a useful bugzilla resolution addition, as it is
a bug, just not a Red Hat bug.


Possible solution:

That said, what is much more important, is that you and other
customers have a workable solution of some kind.  As an engineer,
I'm not the best suited to determine that, however Red Hat customers
and potential customers are encouraged to contact the Red Hat sales
department or Red Hat support for inquiries regarding which
processor architectures or virtualized platforms are supported by
Red Hat and which are not, and what technical and customer support
options are available.  Our sales/support teams are much better
equipped to provide a direct solution for a given customer's needs.  

This is also the best route for customers to provide feedback to
Red Hat of what types of solutions and support they require, and
inform Red Hat of feature and/or other requests for the future.
Such feedback is important to determine future product and support
level planning.  Please contact Red Hat sales at sales@redhat.com,
or by dialing 1-888-RED-HAT1, and one of our associates can work
with you to find a solution that best meets your needs.

I'd like to offer my apology for any confusion I may have
caused in earlier comments, and hope that Red Hat sales/support
is able to offer a solution or make a recommendation which can
meet your needs.

Thanks,
TTYL

Sorry I did not respond to this sooner, I had to play "colonel" this 
past weekend <G>.

Actually  I understand exactly where you are coming from on this 
issue. I am an IT professional and make my living tying different 
operating systems, etc. together for customers.

My point is one that I hear echoed from my customers and frankly is a 
valid one. I have had similar issues with Novell in the past when 
they thought they could not get torched by anyone and Microsoft made 
mincemeat out of them. I, along with a lot of other resellers, got 
out of the Novell camp when they began to blame their resellers for 
their own marketing mistakes.

And this is a marketing mistake that Red Hat can't afford to make. 
Linux is getting into smaller businesses primarily due to cost 
issues, but telling a small business owner that you won't make 
something work just because it's Microsoft isn't going to keep you on 
the premises. I have enough experience with marketing folks (I have 
an MBA, too) that they do not listen to facts when those facts 
disrupt their thinking and the greatness in their own minds.

That's why I feel sorry for the engineers on matters like this. We 
who are small and face customers everyday knows what is said and 
done. When you get too big, you lose contact with the customers and 
you will lose business in the long run. Maybe big business helps the 
stock price, but it's small business that pays the bills and offers 
the best engineering experiences.

So I guess what I am saying here is that I won't waste my time with 
your marketing folks and let things lie as they are. My customers 
will most likely remain in the Microsoft camp because that is where 
things work and reasonably well. I continue to play with Linux here 
on the side...

Thanks for listening.

It would have been nice to see the FC2 release notes reflect that it's
a known issue that MS VPC will not support FC2. I think it's a valid
point and would saved many users a lot of time.

Reassigning to "distribution" component for consideration
of the reporter's request in comment #15.

Assigning to the release notes component. However, it doesn't seem
right to claim <foo> doesn't work if we haven't actually verified it
inhouse (and, with virtual PC, we haven't, AFAIK.)

Closing as notabug due to the lack of in-house resources to
verify/validate this issue for documentation purposes.

I'm pretty sure it's valid. I have tested other distos with 2.6 and it barfs. Anyway, thanks 
for the update.

Here's an idea, FWIW (but I don't think I have time to test this
myself): If you try a 2.6 kernel with CONFIG_X86_GENERIC disabled,
does that work around this problem?

Created attachment 102719 [details]
Screenshot

Screenshot of 2.6 running in VPC.

FYI - 2.6 works in VPC under Gentoo 2004. Added a screen shot.

Would you mind attaching your .config from the Gentoo 2004 2.6 kernel
to this bug?

Created attachment 102742 [details]
config-2.6.7-gentoo

Requested .config file for 2.6.7