[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
13 years, 5 months
Kernel bug triage
by Kevin Fenzi
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
13 years, 7 months
[mst@redhat.com: Re: [PATCH] tun: orphan an skb on tx]
by Michael S. Tsirkin
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 -----
13 years, 7 months
How to deploy lttng on an embedded system
by jerome zh
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
13 years, 7 months
Recent change to nouveau breaks PPC on F-13
by Josh Boyer
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
13 years, 7 months
RFC: re-enable auto loading of floppy driver when the PNP info says there is a floppy
by Hans de Goede
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
13 years, 7 months
enable CONFIG_INTEL_TXT
by Kyle McMartin
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
13 years, 7 months
nouveau rebase for future kernels
by Jon Masters
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.
13 years, 8 months
enable CONFIG_INTEL_TXT
by Eric Paris
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
13 years, 8 months