Bug 119714 - Segfaults on boot (durring rhgb/X load?)
Segfaults on boot (durring rhgb/X load?)
Product: Fedora
Classification: Fedora
Component: fedora-release (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Ed Bailey
Depends On:
  Show dependency treegraph
Reported: 2004-04-01 14:06 EST by Nick Marsh
Modified: 2007-11-30 17:10 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-07-21 13:52:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Screenshot (7.86 KB, image/gif)
2004-08-13 16:21 EDT, Nick Marsh
no flags Details
config-2.6.7-gentoo (27.42 KB, text/plain)
2004-08-15 09:59 EDT, Nick Marsh
no flags Details

  None (edit)
Description Nick Marsh 2004-04-01 14:06:51 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6)
Gecko/20040206 Firefox/0.8

Description of problem:
System boots directly into "segmentation faults" after clean install.
INIT: Id "x" respawning too fast: disabled for 5 minutes.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Install FC2 T2
2. Boot normally.

Actual Results:  Init loads and X kicks out errors and segfaults.

Expected Results:  Should load RHGb or fallback on text mode.

Additional info:

Something about unicode_start $SYSFONT $SYSFONTMATCH on line 80.
Comment 1 Marlin Borsick 2004-04-19 23:09:59 EDT
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>...
Comment 2 Nick Marsh 2004-05-07 03:56:51 EDT
Resolved on FC2 T3 (with Virtual PC). Thanks.
Comment 3 Mike A. Harris 2004-05-07 05:04:26 EDT
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
Comment 4 Mike A. Harris 2004-05-07 05:05:01 EDT
Bug alias of the vm86 issue is "vm86-segv" for reference.
Comment 5 Nick Marsh 2004-05-07 10:09:42 EDT
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.
Comment 6 Mike A. Harris 2004-05-07 10:32:35 EDT
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.
Comment 7 Nick Marsh 2004-05-07 10:42:07 EDT
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?
Comment 8 Nick Marsh 2004-05-07 10:52:03 EDT
FYI - I tried a "linux rescue" and /mnt/sysimage/var/log/messages is 0
Comment 9 Mike A. Harris 2004-05-07 10:53:21 EDT
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

Closing as NOTABUG
Comment 10 Mike A. Harris 2004-05-07 10:58:00 EDT
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.
Comment 11 Marlin Borsick 2004-05-07 16:24:08 EDT
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 
Comment 12 Nick Marsh 2004-05-07 17:12:35 EDT
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
Comment 13 Mike A. Harris 2004-05-08 03:25:49 EDT
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.


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.

Comment 14 Marlin Borsick 2004-05-10 17:45:04 EDT
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.
Comment 15 Nick Marsh 2004-05-26 16:55:17 EDT
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.
Comment 16 Mike A. Harris 2004-05-28 03:57:36 EDT
Reassigning to "distribution" component for consideration
of the reporter's request in comment #15.

Comment 18 Bill Nottingham 2004-05-28 12:13:00 EDT
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.)
Comment 20 Ed Bailey 2004-07-21 13:52:44 EDT
Closing as notabug due to the lack of in-house resources to
verify/validate this issue for documentation purposes.
Comment 21 Nick Marsh 2004-07-21 19:24:44 EDT
I'm pretty sure it's valid. I have tested other distos with 2.6 and it barfs. Anyway, thanks 
for the update.
Comment 22 Barry K. Nathan 2004-07-22 11:40:07 EDT
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?
Comment 23 Nick Marsh 2004-08-13 16:21:57 EDT
Created attachment 102719 [details]

Screenshot of 2.6 running in VPC.
Comment 24 Nick Marsh 2004-08-13 16:24:17 EDT
FYI - 2.6 works in VPC under Gentoo 2004. Added a screen shot.
Comment 25 Barry K. Nathan 2004-08-14 01:52:06 EDT
Would you mind attaching your .config from the Gentoo 2004 2.6 kernel
to this bug?
Comment 26 Nick Marsh 2004-08-15 09:59:03 EDT
Created attachment 102742 [details]

Requested .config file for 2.6.7

Note You need to log in before you can comment on or make changes to this bug.