I am trying to add my own interrupt handler to FC3. I have tried two methods
of modifying the IDT, both of which work under most kernels I've tried (incl
the 2.6.9 vanilla kernel) but fail under the FC3 kernel (2.6.9-1.667). I've
also tried the FC3 kernel with the alternate security models off, and large
memory support off, but I have the same problem. Although I haven't tried it
yet personally, I've been told that some code I have working on the vanilla
2.6.9 kernel works fine under FC4.
Method 1 is to just modify the IDT in place. This causes a segfault on FC3.
Method 2 is to make a copy of the IDT, modify the copy, and then use lidt to
change the IDT used by the processor to the copy. This causes an immediate
reboot on FC3.
Any pointers on what I might be doing wrong? What is the "correct" or
"officially supported" way of adding an interrupt handler on FC3?
Thanks for any pointers (or sample code :)
I updated to rawhide from fc4 on Thursday and now I'm getting:
Bringing up interface eth0: Device eth0 does not seem to be present, delaying
This message is coming from the initscripts, what could be the problem? I've
tried booting with old fc4 kernel - no change.
The ethernet controller works fine under fc4. lspci shows a Ethernet controller
RTL-8139/8139C/8139C+ (rev 10)
Yahoo! Mail for Mobile
Take Yahoo! Mail with you! Check email on your mobile phone.
I'm interested in making a Fedora Live CD, but I've noticed with all the
Fedora based Live CD's, kudzu prompts the user if hardware was
added/removed and the normal "Keep Configuration" "Do Nothing" prompts.
I'd like to add a switch to kudzu that would automatically handle the
addition/removal of hardware without any prompts. I know kudzu already
has a "quiet" switch, but the manpage states that it is only for
supressing dialogs that do not require user input. Anyone worked on this
James S. Martin, RHCE
Administrative Office of the United States Courts
On Thu, 25 Aug 2005 16:59:50 -0400, Ray Strode <rstrode(a)redhat.com> wrote:
> > (gvim:8960): Gdk-WARNING **: gdk_property_get(): length value has wrapped in calculation (did you pass G_MAXLONG?)
> > (sylpheed:2518): Gdk-WARNING **: gdk_property_get(): length value has wrapped in calculation (did you pass G_MAXLONG?)
> it's a bug in the individual apps. See
> for more information.
[zaitcev@lembas sylpheed-2.0.0-p3]$ find . -name '*.[hc]' | xargs grep property_get
[zaitcev@lembas sylpheed-2.0.0-p3]$ find . -name '*.[hc]' | xargs grep G_MAXLONG
This seems to be called from inside of a library, not from the
application. I suppose I have to track it down now. The only way I see
is to have a debuggable version of gtk and place a debugger breakpoint
where the printf originates. What a hassle...
Should kernel-devel be made to depend on the same version of the kernel?
I have kernel-devel installed, and every time a new kernel comes out the
corresponding version of kernel-devel becomes installed as well - but
the old package does not get uninstalled.
Unless there is a specific reason why it is desirable to have
kernel-devel-X installed when kernel-X is not, having the former
Requires: the latter would make maintenance tidier, I think.
We have begun work on X.Org X11 modularization, and are in the process
of packaging the video and input drivers. Upstream, each driver has
its own individual tarball, which are available at:
One of the benefits of the modularized X.Org X11R7, is that it makes
it much easier for us to provide individual driver updates without
having to release the entire 150Mb monolithic X release.
The ability for us to update a single driver, and release that
single driver to users is an important thing for a modern OS, in
particular for desktop systems.
As such, we have decided to package each driver individually in its
own src.rpm package. It has now come to the time where we must
make a decision as to how the driver src.rpm packages will be
named, so we can begin packaging them, and also let the installer
team and other groups know what they're called. As such we are
soliciting feedback from the Fedora community, including Red Hat
developers and subsystem maintainers.
Here is my initial proposal for naming the src.rpms, along with
brief rationale, and the real (or perceived) advantages and
The prefix of "xorg-x11" identifies the driver package as being
an official part of the upstream X.Org project. This distinguishes
the driver from one that might be provided by the "dri" project,
the "gatos" project, or any other project. It makes it easier
to substitute alternative driver packages that provide a driver
of the same name. It also makes it clear to the user, the
developer, and anyone else looking at the package, that the source
code contained inside came from X.Org directly. It also makes
it clearer where bug reports should be filed upstream. As such,
I propose all driver packages start with the "xorg-x11-" prefix.
The "driver" portion of the proposed name, indicates that it is
a driver for the X server, much like "module" in kernel-module
packages. It namespaces all drivers, so that they all appear
together in directory listings, and are easy to group together
from scripts using globs, etc. ie:
# Install all of the xorg drivers:
rpm -ivh xorg-x11-driver-*.rpm
The "<type>" attribute is either "video" or "input", as used
in the upstream tarball names, and further namespaces things,
so that all input drivers appear together, and all video
drivers appear together. This makes it easy to handle all
input drivers or all video drivers from a script as well.
Finally, the driver <name> field, is the official name of the
driver from the upstream tarballs, which generally is the
name of the driver binary that gets installed as well.
Using this naming mechanism, I believe gives us the most
flexibility with driver packages, and makes life a lot easier
down the line as far as maintenance goes. It also makes the
packages very obvious as to what their contents are.
The only slight disadvantage to this naming scheme that
comes to mind which someone might point out, is that the
package names are semi-lengthy. I don't see this as a
problem however, as all modern shells have filename completion,
and it works quite well. The benefits of clarity of
contents, directory listing grouping, CVS repository grouping,
bugzilla grouping, etc., IMHO far outweigh any perceived
disadvantages of lenthy names.
Request for comments:
Interested Fedora Core, Fedora Extras, or community developers
who have an opinion about the X.Org modular package naming
conventions, or who just want to provide feedback concerning
the above proposal, are encouraged to respond to this RFC on
or before Monday August 29th if possible.
We look forward to hearing everyone's feedback, and incorporating
the collective concious of the community into our decision
Thanks for your considerations.
Mike A. Harris
Red Hat Canada, Ltd.
X Devel Team