v2.6.34 for F-13
by Kyle McMartin
http://koji.fedoraproject.org/koji/taskinfo?taskID=2199579
I've done a scratch build of the rawhide kernel, with debugging
disabled, with most of the patches from F-13 caught back up, for people
to test.
Obviously, we're shipping F-13 with 2.6.33, but I'd like to get the
update out there pretty quickly afterwards, if possible. It's currently
missing a bit of DRM rebasing, which is kind of ironic, but it looks
like Fedora's 2.6.33 has half of a newer DRM, both have seperate fixes
though.
Anyway, hopefully we can get that sorted by the weekend, and get
rawhide moved over to 2.6.35-git.
regards, Kyle
12 years, 11 months
[PATCH] [intel_iommu] Default to igfx_off
by drago01
This option seems to causes way to many issues, it is
being investigated by Intel's chipset team for months now and
we still don't have any outcome.
The results so far are "black screen when starting X",
"system hangs when using GL", "system does not resume".
The patch adds an intel_iommu=igfx_on option, which makes it opt in,
rather than opt out.
Signed-off-by: Adel Gadllah <adel.gadllah(a)gmail.com>
---
Documentation/kernel-parameters.txt | 11 +++++------
drivers/pci/intel-iommu.c | 9 +++++----
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index e7848a0..9914485 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -992,12 +992,11 @@ and is between 256 and 4096 characters. It is
defined in the file
Enable intel iommu driver.
off
Disable intel iommu driver.
- igfx_off [Default Off]
- By default, gfx is mapped as normal device. If a gfx
- device has a dedicated DMAR unit, the DMAR unit is
- bypassed by not enabling DMAR with this option. In
- this case, gfx device will use physical address for
- DMA.
+ igfx_on [Default Off]
+ By default, the gfx's DMAR unit is bypassed by not enabling
+ DMAR with this option. So the gfx device will use physical
+ address for DMA. When this option is enabled it the gfx is
+ mapped as normal device.
forcedac [x86_64]
With this option iommu will not optimize to look
for io virtual address below 32 bit forcing dual
diff --git a/drivers/pci/intel-iommu.c b/drivers/pci/intel-iommu.c
index 4173125..8f36786 100644
--- a/drivers/pci/intel-iommu.c
+++ b/drivers/pci/intel-iommu.c
@@ -340,7 +340,8 @@ int dmar_disabled = 0;
int dmar_disabled = 1;
#endif /*CONFIG_DMAR_DEFAULT_ON*/
-static int __initdata dmar_map_gfx = 1;
+/* disabled by default; causes way to many issues */
+static int __initdata dmar_map_gfx = 0;
static int dmar_forcedac;
static int intel_iommu_strict;
@@ -361,10 +362,10 @@ static int __init intel_iommu_setup(char *str)
} else if (!strncmp(str, "off", 3)) {
dmar_disabled = 1;
printk(KERN_INFO "Intel-IOMMU: disabled\n");
- } else if (!strncmp(str, "igfx_off", 8)) {
- dmar_map_gfx = 0;
+ } else if (!strncmp(str, "igfx_on", 7)) {
+ dmar_map_gfx = 1;
printk(KERN_INFO
- "Intel-IOMMU: disable GFX device mapping\n");
+ "Intel-IOMMU: enabled GFX device mapping\n");
} else if (!strncmp(str, "forcedac", 8)) {
printk(KERN_INFO
"Intel-IOMMU: Forcing DAC for PCI devices\n");
--
1.6.6.1
12 years, 12 months
Kernel bug triage redux.
by Kevin Fenzi
ok, finally having time to work on this some more... :)
It doesn't seem that at this time there is much we can do with
bugzilla.redhat.com to help with the reporter end. Fedora packages sync
from pkgdb out and we can't easily add subsystems without making some
kind of seperate list for kernel. So, I think at least for now, we are
stuck trying to triage the bugs after they are submitted unless
someone can come up with some way we can beat our infrastructure to our
wishes.
I did some more cleanup on
https://fedoraproject.org/wiki/KernelBugTriage
Some more questions moving forward:
- Can someone check the table there and update it? For example, for
video hardware, do we want to reassign? or just cc those folks? Do
they want their real addresses there, or just add 'xgl-maint'. Other
places I am sure are wrong, like PATA. Are their other known
subsystem maintainers?
- We need a way to mark bugs by subsystem. I think our choices are:
whiteboard, or blocker bugs. Is there a preference? We should add the
bugs or whiteboard keywords to the subsystem table there. We can also
point people to those for filing new bugs as well.
- Feel free to re-word any of the 'stock comments'.
- Do we need stock comments for any other types of bugs? What common
ones do you guys run into?
- Add any common info gathering steps in
https://fedoraproject.org/wiki/KernelBugTriage#NEW_state_bugs
if we can get this page in good enough shape soon, I would like to try
out processing some rawhide bugs. I think starting with rawhide is the
best bet, as their are only 75 of them currently.
Thoughts? Rants? Wiki edits?
kevin
13 years
Re: NX emulation
by Kees Cook
Hi,
On Tue, May 25, 2010 at 11:45:44PM -0400, Kyle McMartin wrote:
> On Tue, May 25, 2010 at 04:37:13PM -0700, Kees Cook wrote:
> > Hi Kyle,
> >
> > Here's my linux-2.6 branch with 3 NX-emulation patches stacked on top:
> >
> > http://kernel.ubuntu.com/git?p=kees/linux-2.6.git;a=summary
> >
> > I think all three should be merged, but I kept them separate for your
> > review.
>
> Can I pull this tree from somewhere?
Yes, the git URL for this is:
git://kernel.ubuntu.com/kees/linux-2.6.git
In looking at how "exec-shield" is used, I was thinking that maybe the
"nonexec" flag should be used instead. It could have multiple settings,
maybe. It seems like it could be used for:
off
hw-only
emu-if-needed
There also seems to be the "2" setting which ignores the stack-exec
markings, but that seems like it should be a separate feature. If we can
clean it up a little more, I'd really like to try to for upstream
inclusion. I know there has been resistance to it in the past, but
nearly every distro includes this patch set now; it's silly not to have it
upstream.
The second commit "x86: clean up nx-emu for ia32-only" adds a bunch more
#ifdef CONFIG_X86_32 around things, mostly I think the primary change in
behavior that would be visible to Fedora would be having the "exec-shield"
sysctl vanish on x86_64, and to fall back to mainline ASLR in the non-emu
case.
> > Is there a better place (public Fedora mailing list?) for me to send these?
> >
>
> fedora-kernel-list(a)redhat.com if you want.
Done! :)
-Kees
--
Kees Cook
Ubuntu Security Team
13 years
