kernel May 2010

kernel@lists.fedoraproject.org

9 participants
4 discussions

v2.6.34 for F-13
by Kyle McMartin 16 Jun '10

16 Jun '10

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

9 34

[PATCH] [intel_iommu] Default to igfx_off
by drago01 09 Jun '10

09 Jun '10

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

3 3

Kernel bug triage redux.
by Kevin Fenzi 04 Jun '10

04 Jun '10

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

3 6

Re: NX emulation
by Kees Cook 27 May '10

27 May '10

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

4 10

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel May 2010