kernel April 2010

kernel@lists.fedoraproject.org

29 participants
10 discussions

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

10 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
by Kevin Fenzi 26 Apr '10

26 Apr '10

Greetings. I happened to see the other week that there are currently around 1600 open kernel bugs in bugzilla against currently supported Fedora releases. :( The large majority of them are in NEW, and it's unclear how many are at all useful to us. I'd like to revisit the idea of getting a team of bugzappers working on triaging the kernel bugs so we do know more about whats got useful info and what does not and let kernel maintainers be able to more clearly see what could be worked on. So, the first question: Would this effort be worthwhile to kernel maintainers? If 'yes', or 'perhaps', I have a bunch more questions about how you folks would like to handle things: - Should bugs showing the user has a tainted kernel be simply closed? Or should reporter be asked to duplicate without the tainting module? Or both? :) - Should we ask folks for more info and close bugs after some predefined time? How long should that be? - Should feature requests be closed and reporter asked to file upstream? - Should bugs that contain patches get a PATCH subject line or be just asked to report upstream? - Is there a list of commands that would be helpful to run on any new reported issue? uname/lsmod/dmesg? Anything else? Would smolt profiles be of help? - Ideally I would like to sort bugs into large buckets based on subsystem, and then put keywords or something on them so subsystem maintainers could easily look at the bugs in their area. What would be a list of such subsystems that would be useful? - Would it be helpfull to add a keyword or whiteboard on what kernel version it was reported with? Then a search could find all bugs with that particular version (of course it would need to change if reporter updated, etc). - There seem to be a fair number of 'enable this option' or 'disable this option' type requests. Would they be good to mark ? I've started a draft page at: https://fedoraproject.org/wiki/KernelTriage I'd like to flesh it out more and look at adding some canned responses there and then see how much interest there is to do this. Comments/edits/shouting welcome. ;) kevin

8 13

[mst@redhat.com: Re: [PATCH] tun: orphan an skb on tx]
by Michael S. Tsirkin 22 Apr '10

22 Apr '10

This is commit 0110d6f22f392f976e84ab49da1b42f85b64a3c5 in net-2.6 Please cherry-pick this fix for F13 (in fact, it's needed for F12 as well). ----- Forwarded message from "Michael S. Tsirkin" <mst(a)redhat.com> ----- Date: Wed, 21 Apr 2010 14:35:57 +0300 From: "Michael S. Tsirkin" <mst(a)redhat.com> To: stable(a)kernel.org Cc: "David S. Miller" <davem(a)davemloft.net>, Herbert Xu <herbert(a)gondor.hengli.com.au>, Paul Moore <paul.moore(a)hp.com>, David Woodhouse <David.Woodhouse(a)intel.com>, netdev(a)vger.kernel.org, linux-kernel(a)vger.kernel.org, Jan Kiszka <jan.kiszka(a)siemens.com>, qemu-devel <qemu-devel(a)nongnu.org> Subject: Re: [PATCH] tun: orphan an skb on tx Message-ID: <20100421113557.GA31606(a)redhat.com> In-Reply-To: <20100413145944.GA7716(a)redhat.com> On Tue, Apr 13, 2010 at 05:59:44PM +0300, Michael S. Tsirkin wrote: > The following situation was observed in the field: > tap1 sends packets, tap2 does not consume them, as a result > tap1 can not be closed. This happens because > tun/tap devices can hang on to skbs undefinitely. > > As noted by Herbert, possible solutions include a timeout followed by a > copy/change of ownership of the skb, or always copying/changing > ownership if we're going into a hostile device. > > This patch implements the second approach. > > Note: one issue still remaining is that since skbs > keep reference to tun socket and tun socket has a > reference to tun device, we won't flush backlog, > instead simply waiting for all skbs to get transmitted. > At least this is not user-triggerable, and > this was not reported in practice, my assumption is > other devices besides tap complete an skb > within finite time after it has been queued. > > A possible solution for the second issue > would not to have socket reference the device, > instead, implement dev->destructor for tun, and > wait for all skbs to complete there, but this > needs some thought, probably too risky for 2.6.34. > > Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com> > Tested-by: Yan Vugenfirer <yvugenfi(a)redhat.com> > > --- > > Please review the below, and consider for 2.6.34, > and stable trees. > > drivers/net/tun.c | 4 ++++ > 1 files changed, 4 insertions(+), 0 deletions(-) > > diff --git a/drivers/net/tun.c b/drivers/net/tun.c > index 96c39bd..4326520 100644 > --- a/drivers/net/tun.c > +++ b/drivers/net/tun.c > @@ -387,6 +387,10 @@ static netdev_tx_t tun_net_xmit(struct sk_buff *skb, struct net_device *dev) > } > } > > + /* Orphan the skb - required as we might hang on to it > + * for indefinite time. */ > + skb_orphan(skb); > + > /* Enqueue packet */ > skb_queue_tail(&tun->socket.sk->sk_receive_queue, skb); > dev->trans_start = jiffies; > -- > 1.7.0.2.280.gc6f05 This is commit 0110d6f22f392f976e84ab49da1b42f85b64a3c5 in net-2.6 Please cherry-pick this fix in stable kernels (2.6.32 and 2.6.33). Thanks! -- MST ----- End forwarded message -----

1 0

How to deploy lttng on an embedded system
by jerome zh 20 Apr '10

20 Apr '10

Hi all, I am now trying to debug linux kernel with lttng toolkit. My qusetion is how to deloy the lttng and lttv on my target/host system? -- Best regards Jerome

2 1

RFE: vhost net backport in fc13
by Michael S. Tsirkin 18 Apr '10

18 Apr '10

All, What is needed to backport vhost net accelerator to make it avaiable in fc13? The following patches from net-next (git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6.git) should apply to fedora kernel without changes, and are fairly non-intrusive: 05c2828c72c4eabf62376adfe27bd24797621f62 tun: export underlying socket 5da779c34ccff5e1e617892b6c8bd8260fb1f04c mm: export use_mm/unuse_mm to modules 3a4d5c94e959359ece6d6b55045c3f046677f55c vhost_net: a kernel-level virtio server This module is required for vhost net feature. Feature page here: https://fedoraproject.org/wiki/Features/VHostNet -- MST

2 2

Recent change to nouveau breaks PPC on F-13
by Josh Boyer 16 Apr '10

16 Apr '10

Sigh, The drm-nouveau-acpi-edid-fallback.patch recently had some code added to nouveau_connector.c to do some fallback to ACPI. It looks like this: @@ -718,6 +718,14 @@ nouveau_connector_create_lvds(struct drm } } + /* Let's try ACPI */ + if (!nv_connector->edid && !nv_connector->native_mode && + !dev_priv->vbios.fp_no_ddc && + !nouveau_acpi_get_edid(dev,connector)) { + nv_connector->edid = + (struct edid *)&nv_connector->acpi_edid; + } + if (!nv_connector->edid) goto out; However, there is no ACPI on PPC/PPC64, so the build fails with this: drivers/gpu/drm/nouveau/nouveau_connector.c: In function 'nouveau_connector_create_lvds': drivers/gpu/drm/nouveau/nouveau_connector.c:726: error: 'struct nouveau_connector' has no member named 'acpi_edid' make[4]: *** [drivers/gpu/drm/nouveau/nouveau_connector.o] Error 1 make[3]: *** [drivers/gpu/drm/nouveau] Error 2 make[2]: *** [drivers/gpu/drm] Error 2 make[1]: *** [drivers/gpu] Error 2 make: *** [drivers] Error 2 make: *** Waiting for unfinished jobs.... I'm pretty sure the above code should be wrapped with #ifdef CONFIG_ACPI or something similar. The structure add in nouveau_connector.h is at least. josh

2 2

RFC: re-enable auto loading of floppy driver when the PNP info says there is a floppy
by Hans de Goede 15 Apr '10

15 Apr '10

Hi, I'm currently looking into fixing: http://bugzilla.redhat.com/show_bug.cgi?id=565693 The easiest way to do this would be to remove the always modprobe floppy code from anaconda and rely on udev for floppy driver loading. But that cannot be done as for some reason the fedora kernel caries this "beauty" of a patch called die-floppy-die.patch: ### Kill the floppy.ko pnp modalias. We were surviving just fine without autoloading floppy drivers, tyvm. Please feel free to register all complaints in the wastepaper bin. diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c index 91b7530..2ea84a6 100644 --- a/drivers/block/floppy.c +++ b/drivers/block/floppy.c @@ -4631,7 +4631,7 @@ static const struct pnp_device_id floppy_pnpids[] = { { "PNP0700", 0 }, { } }; -MODULE_DEVICE_TABLE(pnp, floppy_pnpids); +/* MODULE_DEVICE_TABLE(pnp, floppy_pnpids); */ #else ### Which although it says "to register all complaints in the wastepaper bin", I beg to differ. We can certainly do some kludge in anaconda to restore the autoload behavior there, but I wonder why as many people seem to think that the removal of the autoloading is a bad idea, see: http://bugzilla.redhat.com/show_bug.cgi?id=537741 And also, this thread was which supposed to be about an anaconda specific solution but turned into a why is floppy driver autoloading disabled thread: http://www.redhat.com/archives/anaconda-devel-list/2010-March/msg00332.html So even though the auto loading may cause some issues (mostly for people who have congfigured there is a floppy in the BIOS while there isn't one), disabling it also causes issues, and we're deviating from upstream here. So I wonder why are we deviating from upstream here, with a patch that clearly has no intention of ever going upstream ? That seems to contradict most of our policies. And if those who are in favor of the patch believe it is a good patch, why are they not taking this discussion upstream, and let it be fixed there ? Regards, Hans

10 28

enable CONFIG_INTEL_TXT
by Kyle McMartin 11 Apr '10

11 Apr '10

So... since it was I who precipitated this whole debacle by leaving TXT disabled when I merged that kernel a while ago, I guess I should weigh in a bit. If I had just enabled it then I doubt anyone who doesn't care about this feature would have noticed. After reviewing the hooks it adds to the kernel, I'm going to recommend we enable it. I'll detail the logic in this below. 1. It actually has people who want to use it. 2. It doesn't actually hook into much of the kernel at all, just s3 hooks to turn it off/on when sleeping and a hook in to the iommu initialization to force it on so that page level protection can be done. 3. The blob I don't think meets our firmware guidelines, but that's ok, we ship other features useless without firmware that must be fetched externally. (Broadcom wifi being the big one I can think of.) 4. The fact that the blob runs isn't much worse than SMM running or whatever, those are all pretty opaque things that can screw with the system on the way up. 5. It doesn't look like it will be a maintenance burden, aside from the fact that intel_iommu will be forced on, which is its own can of worms. That said, I think that Intel have been a little silly in the way this upstream with, as far as I can tell, fairly little review of whether it's a desireable feature. Anyway, I recommend we turn it on, but let users sort it out for themselves. If it's a burden, we can add a TAINT flag for it and just email all the bugs to Eric since he's so gung ho on it. :) --Kyle

3 3

nouveau rebase for future kernels
by Jon Masters 08 Apr '10

08 Apr '10

Folks, This may have come up already (and I don't mean upstream :) ) but am interested to know what the plans are in F12 wrt. nouveau updates. Is there a plan to eventually rebase the kernel to 2.6.34? (and with it, requiring a non-backwards compatible update to xorg-x11-drv-nouveau?) If there is not, is there any way (other than building them manually) of getting an X driver that can work with more recent kernels in F12? I am not personally a fan of rebasing so I think I would rather deal with having to rebuild the X driver myself, but in my perfect world maybe someone has done this already and can share. Jon.

2 2

enable CONFIG_INTEL_TXT
by Eric Paris 01 Apr '10

01 Apr '10

Long ago we were ask to enable CONFIG_INTEL_TXT in the fedora kernels by a large user, the US National Security Agency: http://lists.fedoraproject.org/pipermail/kernel/2009-October/002228.html At the time the objection to this configuration option was that the technology was all predicated on a closed source binary blob signed by Intel. In private discussions it was learned that there was no chance that the module would ever be open sourced and we learned that hardware is not capable of recognizing signatures of a module from other vendors (aka Fedora can't sign our own version.) However, in light of a recent public statement from IBM: http://lists.fedoraproject.org/pipermail/devel/2010-March/133089.html We see that at least one hardware vendor has been listening to our objections to closed source software and has agreed to re-architect how they implement their systems so that our users will not need to download and install any closed source proprietary software. They agreed to make any changes necessary to their BIOS (UEFI) to support this technology without the need for the separate closed source proprietary Intel signed blob. Red Hat has ask other hardware vendors to follow the admirable lead set by IBM if they have any interest in being supported by the open source community. At this point we know that we have hardware vendors, software vendors, and users all asking for the enablement of this technology. So the question become why should we enable CONFIG_INTEL_TXT and what do we get? What do we lose? By itself enabling TXT gets us nothing except a small chuck of dead code in the kernel. But it allows us and our customers to build new solutions with new security goals in mind which are not possible today. This config option allows a user to download new (open source) software (tboot) along with other third party software to verify the correctness of the BOOTED system. This allows us to build future solutions such as utilizing the TPM chip in many laptops to harden the disk encryption key. It can be used as root of trust for the verification of the software originally loaded on a machine before it is allowed network access (aka machines with a rootkit couldn't get on the network.) The technology can also be extended to provide usefulness to system integrity checkers like aide or IMA for tamper proof software integrity logging. These are all things which are impossible to do with today's kernels. We don't really lose anything except a bit of code in the kernel. Unless the user specifically installs tboot the kernel code will sit dormant. It has no implications on AMD processors. If the user does install tboot and their hardware supports this technology (like this future generation of IBM system X products mentioned above) they will get a root of trust which can be used to build other solutions. Some of those potential solutions will hopefully be available someday in Fedora if a user wishes to activate them (and we can overcome the management burden they will seemingly place upon the user), but we cannot get there without starting here. This is the beginning. It is the first step to allow users to use other open source software which will give them a root of trust. But remember the config options does nothing unless a user takes those very clear active steps. Are there any objections to enabling CONFIG_INTEL_TXT on x86_64? -Eric

8 30

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel April 2010