On Sun, Jun 01, 2014 at 11:30:02PM +0700, Jun Koi wrote:
> (1) do you think this VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL is the
> reason why ESXi falls back to binary translation?
It might be, its been a while since I got ESXi to use VMX on KVM. Take
a look at the VMware log file for the L2, it
On Sun, Jun 01, 2014 at 11:30:02PM +0700, Jun Koi wrote:
(1) do you think this VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL is the
reason why ESXi falls back to binary translation?
It might be, its been a while since I got ESXi to use VMX on KVM. Take
a look at the VMware log file for the L2, it
On Sun, Jun 01, 2014 at 05:54:25PM +0700, Jun Koi wrote:
> So this means ESXi never uses VMResume/VMLaunch? How is this
> possible, because it uses VMX for its implementation?
ESXi will fall back to binary translation if it decides that it cannot
use VMX for some reason. Look at the L2's log
On Sun, Jun 01, 2014 at 05:54:25PM +0700, Jun Koi wrote:
So this means ESXi never uses VMResume/VMLaunch? How is this
possible, because it uses VMX for its implementation?
ESXi will fall back to binary translation if it decides that it cannot
use VMX for some reason. Look at the L2's log file
Patch looks good to me.
Acked-by: Muli Ben-Yehuda
Cheers,
Muli
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FA
Patch looks good to me.
Acked-by: Muli Ben-Yehuda mu...@mulix.org
Cheers,
Muli
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
On Fri, Mar 07, 2014 at 11:09:06AM -0500, Vivek Goyal wrote:
> I would say it is not very complicated to maintain backward
> compatibility in this case. So let us keep saved_max_pfn for some
> time and make kexec-tools changes. Some time down the line, one can
> get rid of saved_max_pfn
On Thu, Mar 06, 2014 at 07:46:44AM -0700, Jon Mason wrote:
> > I don't know of anyone still using it, but it's not
> > impossible. Calgary and CalIOC2 machines would now be ~5-8 years
> > old.
>
> It is getting a bit crufty in arch/x86. Would it be better to move
> it to drivers/iommu?
Not
On Thu, Mar 06, 2014 at 07:46:44AM -0700, Jon Mason wrote:
I don't know of anyone still using it, but it's not
impossible. Calgary and CalIOC2 machines would now be ~5-8 years
old.
It is getting a bit crufty in arch/x86. Would it be better to move
it to drivers/iommu?
Not sure I see
On Fri, Mar 07, 2014 at 11:09:06AM -0500, Vivek Goyal wrote:
I would say it is not very complicated to maintain backward
compatibility in this case. So let us keep saved_max_pfn for some
time and make kexec-tools changes. Some time down the line, one can
get rid of saved_max_pfn completely.
On Wed, Mar 05, 2014 at 10:50:41PM -0800, H. Peter Anvin wrote:
> OK, second question... is it time to axe Calgary?
I don't know of anyone still using it, but it's not
impossible. Calgary and CalIOC2 machines would now be ~5-8 years old.
Cheers,
Muli
--
To unsubscribe from this list: send the
On Wed, Mar 05, 2014 at 01:36:17PM +0800, WANG Chao wrote:
> Hi, Muli
>
> saved_max_pfn is becoming a setback for kexec-tools. Ideally calgary
> could get rid of saved_max_pfn at all. But If this can't work, how
> about exporting a calgary tce table size to user space, so that
> kexec-tools can
On Wed, Mar 05, 2014 at 01:36:17PM +0800, WANG Chao wrote:
Hi, Muli
saved_max_pfn is becoming a setback for kexec-tools. Ideally calgary
could get rid of saved_max_pfn at all. But If this can't work, how
about exporting a calgary tce table size to user space, so that
kexec-tools can simply
On Wed, Mar 05, 2014 at 10:50:41PM -0800, H. Peter Anvin wrote:
OK, second question... is it time to axe Calgary?
I don't know of anyone still using it, but it's not
impossible. Calgary and CalIOC2 machines would now be ~5-8 years old.
Cheers,
Muli
--
To unsubscribe from this list: send the
On Fri, Feb 15, 2008 at 10:28:22AM -0800, Greg KH wrote:
> That would be nice. Muli, want to make a patch for this?
Sure, I'll put something together.
Cheers,
Muli
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
On Fri, Feb 15, 2008 at 10:28:22AM -0800, Greg KH wrote:
That would be nice. Muli, want to make a patch for this?
Sure, I'll put something together.
Cheers,
Muli
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
On Thu, Feb 14, 2008 at 11:17:03PM -0800, Greg KH wrote:
> Hm, that's wierd. I thought I got something, until I realized that
> you are doing a lot of logic before you ever even determine that
> your hardware is present in the system. Why are you calling
> calgary_locate_bbars() and doing all
On Thu, Feb 14, 2008 at 11:17:03PM -0800, Greg KH wrote:
Hm, that's wierd. I thought I got something, until I realized that
you are doing a lot of logic before you ever even determine that
your hardware is present in the system. Why are you calling
calgary_locate_bbars() and doing all of
atch below would be fine?
Yep, looks good.
Acked-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
Cheers,
Muli
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Tue, Feb 12, 2008 at 04:16:38PM -0800, Greg KH wrote:
> Why does the calgary driver need this? Can we just use
> pci_get_device() instead? Why do you need to walk the device list
> backwards? Do you get false positives going forward?
It's not strictly needed, we used it for symmetry. Feel
On Tue, Feb 12, 2008 at 04:16:38PM -0800, Greg KH wrote:
Why does the calgary driver need this? Can we just use
pci_get_device() instead? Why do you need to walk the device list
backwards? Do you get false positives going forward?
It's not strictly needed, we used it for symmetry. Feel
no longer recall what it was. Some
reason the real PCI driver API didn't fit at the time. If someone
were to whip up a working patch, I'd happily apply it.
Feel free to nuke it and walk the list forward.
So something like the patch below would be fine?
Yep, looks good.
Acked-by: Muli Ben-Yehuda
On Tue, Feb 12, 2008 at 01:00:06AM -0800, David Miller wrote:
> From: Muli Ben-Yehuda <[EMAIL PROTECTED]>
> Date: Tue, 12 Feb 2008 10:52:56 +0200
>
> > The streaming DMA-API was designed to conserve IOMMU mappings for
> > machines where IOMMU mappings are a scarce reso
On Mon, Feb 11, 2008 at 02:41:05PM -0800, mark gross wrote:
> The intel-iommu hardware requires a polling operation to flush IOTLB
> PTE's after an unmap operation. Through some TSC instrumentation of
> a netperf UDP stream with small packets test case it was seen that
> the flush operations
On Mon, Feb 11, 2008 at 02:41:05PM -0800, mark gross wrote:
The intel-iommu hardware requires a polling operation to flush IOTLB
PTE's after an unmap operation. Through some TSC instrumentation of
a netperf UDP stream with small packets test case it was seen that
the flush operations where
On Tue, Feb 12, 2008 at 01:00:06AM -0800, David Miller wrote:
From: Muli Ben-Yehuda [EMAIL PROTECTED]
Date: Tue, 12 Feb 2008 10:52:56 +0200
The streaming DMA-API was designed to conserve IOMMU mappings for
machines where IOMMU mappings are a scarce resource, and is a poor
fit
submission deadline: May 13th, 2008
OSR guest editors:
* Muli Ben-Yehuda, IBM Haifa Research Lab <[EMAIL PROTECTED]>
* Eric Van Hensbergen, IBM Austin Research Lab <[EMAIL PROTECTED]>
* Marc E. Fiuczynski, Princeton University <[EMAIL PROTECTED]>
Review committee:
* Patrick B
submission deadline: May 13th, 2008
OSR guest editors:
* Muli Ben-Yehuda, IBM Haifa Research Lab [EMAIL PROTECTED]
* Eric Van Hensbergen, IBM Austin Research Lab [EMAIL PROTECTED]
* Marc E. Fiuczynski, Princeton University [EMAIL PROTECTED]
Review committee:
* Patrick Bridges (University of New
and it needs to be cleared if DMA's are going to happen
> effectively.
>
> please apply
>
> --mgross
>
> Signed-off-by: mark gross <[EMAIL PROTECTED]>
Acked-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
Mark, please try in the future to not mix unrelated changes such as
thes
if DMA's are going to happen
effectively.
please apply
--mgross
Signed-off-by: mark gross [EMAIL PROTECTED]
Acked-by: Muli Ben-Yehuda [EMAIL PROTECTED]
Mark, please try in the future to not mix unrelated changes such as
these. This patch should've been two patches, one to disable
On Mon, Nov 12, 2007 at 07:25:27PM +0530, Amit Shah wrote:
> Selectively? What happens in the case when some iommu doesn't want
> to invoke the prev_op, but the mapping depends on it being called
> (eg, the hypercalling op is embedded somewhere in the prev_op chain)
Bad things :-)
There needs to
On Mon, Nov 12, 2007 at 05:26:24PM +0530, Amit Shah wrote:
> On Monday 12 November 2007 16:20:01 Muli Ben-Yehuda wrote:
> > On Wed, Nov 07, 2007 at 04:21:04PM +0200, Amit Shah wrote:
> > > We make the dma_mapping_ops structure to point to our structure so
> > > that ev
On Wed, Nov 07, 2007 at 04:21:06PM +0200, Amit Shah wrote:
> Of all the DMA calls, only dma_alloc_coherent might not actually
> call dma_ops->alloc_coherent. We make sure that gets called if the
> device that's being worked on is a PV device
I always thougt that's a mess... the reason it's done
On Wed, Nov 07, 2007 at 04:21:05PM +0200, Amit Shah wrote:
> A guest can call dma_ops->is_pv_device() to find out if a device is
> a passthrough'ed device (device passed on to a guest by the
> host). If this is true, a hypercall will be made to translate DMA
> mapping operations.
Doesn't really
On Wed, Nov 07, 2007 at 04:21:04PM +0200, Amit Shah wrote:
> We make the dma_mapping_ops structure to point to our structure so
> that every DMA access goes through us. (This is the reason this only
> works for 64-bit guest. 32-bit guest doesn't yet have a dma_ops
> struct.)
I need the same
On Wed, Nov 07, 2007 at 04:21:04PM +0200, Amit Shah wrote:
We make the dma_mapping_ops structure to point to our structure so
that every DMA access goes through us. (This is the reason this only
works for 64-bit guest. 32-bit guest doesn't yet have a dma_ops
struct.)
I need the same facility
On Wed, Nov 07, 2007 at 04:21:05PM +0200, Amit Shah wrote:
A guest can call dma_ops-is_pv_device() to find out if a device is
a passthrough'ed device (device passed on to a guest by the
host). If this is true, a hypercall will be made to translate DMA
mapping operations.
Doesn't really
On Wed, Nov 07, 2007 at 04:21:06PM +0200, Amit Shah wrote:
Of all the DMA calls, only dma_alloc_coherent might not actually
call dma_ops-alloc_coherent. We make sure that gets called if the
device that's being worked on is a PV device
I always thougt that's a mess... the reason it's done this
On Mon, Nov 12, 2007 at 05:26:24PM +0530, Amit Shah wrote:
On Monday 12 November 2007 16:20:01 Muli Ben-Yehuda wrote:
On Wed, Nov 07, 2007 at 04:21:04PM +0200, Amit Shah wrote:
We make the dma_mapping_ops structure to point to our structure so
that every DMA access goes through us
On Mon, Nov 12, 2007 at 07:25:27PM +0530, Amit Shah wrote:
Selectively? What happens in the case when some iommu doesn't want
to invoke the prev_op, but the mapping depends on it being called
(eg, the hypercalling op is embedded somewhere in the prev_op chain)
Bad things :-)
There needs to be
On Fri, Nov 09, 2007 at 07:03:30AM +0100, Adrian Bunk wrote:
> "debugging" is a horrible name for a global variable - thankfully it can
> become static.
>
> Also put it out of __read_mostly so that gcc no longer has to emit it
> at all.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
On Fri, Nov 09, 2007 at 07:03:30AM +0100, Adrian Bunk wrote:
debugging is a horrible name for a global variable - thankfully it can
become static.
Also put it out of __read_mostly so that gcc no longer has to emit it
at all.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Thanks, applied.
} while (count--);
> > + } while (--count);
> >
> > spin_unlock_irqrestore(>lock, flags);
> >
> > if (count == 0) {
> >
>
> Thanks, much better. In the future, please also CC: the appropriate
> maintainers, or Andrew Morton if
Morton if you're at a loss...
Indeed.
Reviewed-by: Ray Lee [EMAIL PROTECTED]
Acked-by: Muli Ben-Yehuda [EMAIL PROTECTED]
Andrew, can you please push to Linus?
Thanks,
Muli
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED
On Sat, Nov 03, 2007 at 02:05:39AM +0900, FUJITA Tomonori wrote:
> This patchset convert the PPC64 IOMMU to use the iova code for free
> area management.
>
> The IOMMUs ignores low level drivers' restrictions, the maximum
> segment size and segment boundary.
>
> I fixed the former:
>
>
On Sat, Nov 03, 2007 at 02:05:39AM +0900, FUJITA Tomonori wrote:
This patchset convert the PPC64 IOMMU to use the iova code for free
area management.
The IOMMUs ignores low level drivers' restrictions, the maximum
segment size and segment boundary.
I fixed the former:
having a command line to preserve any protected areas
> set up at boot time.
The society for controlled proliferation of command line options
thanks you.
> Signed-off-by: mark gross <[EMAIL PROTECTED]>
Acked-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
Cheers,
Muli
--
SYSTOR 2007 -
to preserve any protected areas
set up at boot time.
The society for controlled proliferation of command line options
thanks you.
Signed-off-by: mark gross [EMAIL PROTECTED]
Acked-by: Muli Ben-Yehuda [EMAIL PROTECTED]
Cheers,
Muli
--
SYSTOR 2007 --- 1st Annual Haifa Systems and Storage Conference
On Fri, Oct 26, 2007 at 11:18:49AM -0700, Mark Gross wrote:
> The following patch clears the portect memory region enable bit at
> boot time by default. It also provides a kernel parrameter for
> disabling this behavior and leave the PMEN_REG untouched if so
> wanted.
>
> If the boot loader or
On Fri, Oct 26, 2007 at 11:18:49AM -0700, Mark Gross wrote:
The following patch clears the portect memory region enable bit at
boot time by default. It also provides a kernel parrameter for
disabling this behavior and leave the PMEN_REG untouched if so
wanted.
If the boot loader or
On Tue, Oct 23, 2007 at 08:10:54PM +0200, Andi Kleen wrote:
> I think his goal was to get an prefix that describes the module
> uniquely. gart_* clearly does not fulfill that criteria.
>
> So basically he's replacing an
> ambigious-with-other-IOMMU-implementations prefix with an
>
On Tue, Oct 23, 2007 at 07:41:32PM +0200, Joerg Roedel wrote:
> This patch makes some functions and variables static in pci-gart_64.c which
> are
> not used somewhere else.
>
> Signed-off-by: Joerg Roedel <[EMAIL PROTECTED]>
Acked-by: Muli Ben-Yehuda <[EMAIL PROTECTED]&g
On Tue, Oct 23, 2007 at 07:41:31PM +0200, Joerg Roedel wrote:
> This patch renames the IOMMU config option to GART_IOMMU because in fact it
> means the GART and not general support for an IOMMU on x86.
>
> Signed-off-by: Joerg Roedel <[EMAIL PROTECTED]>
Acked-by: Muli
Roedel <[EMAIL PROTECTED]>
Acked-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
Cheers,
Muli
--
SYSTOR 2007 --- 1st Annual Haifa Systems and Storage Conference 2007
http://www.haifa.il.ibm.com/Workshops/systor2007/
Virtualization workshop: Oct 29th, 2007 | Storage workshop: Oct 30th, 2007
-by: Muli Ben-Yehuda [EMAIL PROTECTED]
Cheers,
Muli
--
SYSTOR 2007 --- 1st Annual Haifa Systems and Storage Conference 2007
http://www.haifa.il.ibm.com/Workshops/systor2007/
Virtualization workshop: Oct 29th, 2007 | Storage workshop: Oct 30th, 2007
-
To unsubscribe from this list: send the line
On Tue, Oct 23, 2007 at 07:41:32PM +0200, Joerg Roedel wrote:
This patch makes some functions and variables static in pci-gart_64.c which
are
not used somewhere else.
Signed-off-by: Joerg Roedel [EMAIL PROTECTED]
Acked-by: Muli Ben-Yehuda [EMAIL PROTECTED]
Cheers,
Muli
--
SYSTOR 2007
On Tue, Oct 23, 2007 at 07:41:31PM +0200, Joerg Roedel wrote:
This patch renames the IOMMU config option to GART_IOMMU because in fact it
means the GART and not general support for an IOMMU on x86.
Signed-off-by: Joerg Roedel [EMAIL PROTECTED]
Acked-by: Muli Ben-Yehuda [EMAIL PROTECTED
On Tue, Oct 23, 2007 at 08:10:54PM +0200, Andi Kleen wrote:
I think his goal was to get an prefix that describes the module
uniquely. gart_* clearly does not fulfill that criteria.
So basically he's replacing an
ambigious-with-other-IOMMU-implementations prefix with an
ambigious-with-AGP
On Fri, Oct 19, 2007 at 02:38:11PM +0200, Joerg Roedel wrote:
> This patch renames the include file asm-x86/iommu.h to asm-x86/gart.h to make
> clear to which IOMMU implementation it belongs. The patch also adds "GART" to
> the Kconfig line.
Long overdue IMHO. How about also renaming the config
On Fri, Oct 19, 2007 at 02:38:11PM +0200, Joerg Roedel wrote:
This patch renames the include file asm-x86/iommu.h to asm-x86/gart.h to make
clear to which IOMMU implementation it belongs. The patch also adds GART to
the Kconfig line.
Long overdue IMHO. How about also renaming the config
On Wed, Oct 10, 2007 at 11:00:58AM +0530, Vivek Goyal wrote:
> On Tue, Oct 09, 2007 at 11:06:23PM +0200, Muli Ben-Yehuda wrote:
> > Hi Chandru,
> >
> > Thanks for the patch. Comments on the patch below, but first a general
> > question for my education: the mai
On Wed, Oct 10, 2007 at 11:00:58AM +0530, Vivek Goyal wrote:
On Tue, Oct 09, 2007 at 11:06:23PM +0200, Muli Ben-Yehuda wrote:
Hi Chandru,
Thanks for the patch. Comments on the patch below, but first a general
question for my education: the main problem here that aacraid
continues
Hi Chandru,
Thanks for the patch. Comments on the patch below, but first a general
question for my education: the main problem here that aacraid
continues DMA'ing when it shouldn't. Why can't we shut it down
cleanly? Even without the presence of an IOMMU, it seems dangerous to
let an adapter
Hi Chandru,
Thanks for the patch. Comments on the patch below, but first a general
question for my education: the main problem here that aacraid
continues DMA'ing when it shouldn't. Why can't we shut it down
cleanly? Even without the presence of an IOMMU, it seems dangerous to
let an adapter
Now that we check for translation enabled/disabled based on the
presence of the IOMMU translation table, we can get rid of
translate_phb.
Signed-off-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
---
pci-calgary.c | 31 +++
1 files changed, 15 insertions(+), 16 del
off-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
Acked-by: Murillo Fernandes Bernardes <[EMAIL PROTECTED]>
---
Andi, This is Calgary 2.6.24 material - please apply.
pci-calgary.c | 16 +++-
1 files changed, 11 insertions(+), 5 deletions(-)
diff -r ca20f7bdb869 -r c9308d0538d
The old check we used based on dev-bus-number is wrong for devices
on CalIOC2. Instead look whether we have an IOMMU table for that bus -
if not, translation is disabled.
Thanks to Murillo Fernandes Bernardes [EMAIL PROTECTED] for
spotting, suggesting a fix and testing.
Signed-off-by: Muli Ben
Now that we check for translation enabled/disabled based on the
presence of the IOMMU translation table, we can get rid of
translate_phb.
Signed-off-by: Muli Ben-Yehuda [EMAIL PROTECTED]
---
pci-calgary.c | 31 +++
1 files changed, 15 insertions(+), 16 deletions
On Tue, Sep 18, 2007 at 06:29:19AM +0200, Borislav Petkov wrote:
> These patches remove redundant DMA_..BIT_MASK definitions across two drivers.
> In this version of the patches, the computation of the bitmasks is done by
> the compiler.
>
> Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>
>
On Tue, Sep 18, 2007 at 06:29:19AM +0200, Borislav Petkov wrote:
These patches remove redundant DMA_..BIT_MASK definitions across two drivers.
In this version of the patches, the computation of the bitmasks is done by
the compiler.
Signed-off-by: Borislav Petkov [EMAIL PROTECTED]
Cc: Jeremy
On Tue, Sep 11, 2007 at 10:42:31AM -0700, Keshavamurthy, Anil S wrote:
> Yes, I agree that pci_dev->sysdata can;t be removed. Even we (IOMMU)
> were dependent on this field but somehow this field is being
> overwritten to point to pci_bus's->sysdata and hence IOMMU was
> failing. Earlier it was
On Tue, Sep 11, 2007 at 10:42:31AM -0700, Keshavamurthy, Anil S wrote:
Yes, I agree that pci_dev-sysdata can;t be removed. Even we (IOMMU)
were dependent on this field but somehow this field is being
overwritten to point to pci_bus's-sysdata and hence IOMMU was
failing. Earlier it was
On Mon, Sep 10, 2007 at 08:43:59AM -0700, Keshavamurthy, Anil S wrote:
> On Sun, Sep 09, 2007 at 02:16:19PM +0300, Muli Ben-Yehuda wrote:
> > On Sat, Sep 08, 2007 at 01:05:24PM -0700, Keshavamurthy, Anil S wrote:
> >
> > > Subject: [RFC][Intel-IOMMU] Fix for IOMMU early c
On Sat, Sep 08, 2007 at 01:05:24PM -0700, Keshavamurthy, Anil S wrote:
> Subject: [RFC][Intel-IOMMU] Fix for IOMMU early crash
This patch feels like a huge hack. See below.
> This patch removes sysdata from pci_dev struct and creates a new
> field called sys_data which is exclusively used by
On Sat, Sep 08, 2007 at 01:05:24PM -0700, Keshavamurthy, Anil S wrote:
Subject: [RFC][Intel-IOMMU] Fix for IOMMU early crash
This patch feels like a huge hack. See below.
This patch removes sysdata from pci_dev struct and creates a new
field called sys_data which is exclusively used by IOMMU
On Mon, Sep 10, 2007 at 08:43:59AM -0700, Keshavamurthy, Anil S wrote:
On Sun, Sep 09, 2007 at 02:16:19PM +0300, Muli Ben-Yehuda wrote:
On Sat, Sep 08, 2007 at 01:05:24PM -0700, Keshavamurthy, Anil S wrote:
Subject: [RFC][Intel-IOMMU] Fix for IOMMU early crash
This patch feels like
On Sat, Sep 01, 2007 at 10:32:23AM -0400, Jeff Garzik wrote:
>
> Now that the dust has settled and the prep work is upstream, adding
> PCI edomain support to x86 is a lot more straightforward.
>
> Targetted for 2.6.24.
Looks good to me.
Cheers,
Muli
-
To unsubscribe from this list: send the
On Sat, Sep 01, 2007 at 10:32:23AM -0400, Jeff Garzik wrote:
Now that the dust has settled and the prep work is upstream, adding
PCI edomain support to x86 is a lot more straightforward.
Targetted for 2.6.24.
Looks good to me.
Cheers,
Muli
-
To unsubscribe from this list: send the line
On Wed, Aug 22, 2007 at 11:56:22PM +0200, Thomas Gleixner wrote:
> We are pleased to announce v2 of the unified arch/x86 project we are
> working on.
After having recently inadvertently broken i386 while making x86-64
changes, thumbs up from me!
Cheers,
Muli
-
To unsubscribe from this list:
On Wed, Aug 22, 2007 at 11:56:22PM +0200, Thomas Gleixner wrote:
We are pleased to announce v2 of the unified arch/x86 project we are
working on.
After having recently inadvertently broken i386 while making x86-64
changes, thumbs up from me!
Cheers,
Muli
-
To unsubscribe from this list: send
On Mon, Aug 13, 2007 at 10:25:02AM -0700, Joe Perches wrote:
> On Mon, 2007-08-13 at 15:18 +0300, Muli Ben-Yehuda wrote:
> > Nope, this entry is for sound/oss/trident*.
>
> TRIDENT 4DWAVE/SIS 7018 PCI AUDIO CORE
> P: Muli Ben-Yehuda
> M:[EMAIL PROTECTED]
INTAINERS
> @@ -4563,6 +4563,7 @@ P: Muli Ben-Yehuda
> M: [EMAIL PROTECTED]
> L: linux-kernel@vger.kernel.org
> S: Maintained
> +F: sound/pci/trident/
Nope, this entry is for sound/oss/trident*.
Cheers,
Muli
-
To unsubscribe from this list: send the line "
On Sun, Aug 12, 2007 at 10:53:19PM -0700, Joe Perches wrote:
> Describe the new F: pattern
Patch looks reversed?
>
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 0d7f856..d3a0684 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -83,13
+F: arch/x86_64/kernel/tce.c
> +F: include/asm-x86_6/calgary.h
> +F: include/asm-x86_6/pci.h
Likewise pci.h.
You may also want to include
F: include/asm-x86_6/tce.h
F: include/asm-x86_6/rio.h
Rest looks good:
Acked-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
Cheers,
M
+F: include/asm-x86_6/pci.h
Likewise pci.h.
You may also want to include
F: include/asm-x86_6/tce.h
F: include/asm-x86_6/rio.h
Rest looks good:
Acked-by: Muli Ben-Yehuda [EMAIL PROTECTED]
Cheers,
Muli
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
On Sun, Aug 12, 2007 at 10:53:19PM -0700, Joe Perches wrote:
Describe the new F: pattern
Patch looks reversed?
Signed-off-by: Joe Perches [EMAIL PROTECTED]
diff --git a/MAINTAINERS b/MAINTAINERS
index 0d7f856..d3a0684 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -83,13 +83,6 @@ S:
: Muli Ben-Yehuda
M: [EMAIL PROTECTED]
L: linux-kernel@vger.kernel.org
S: Maintained
+F: sound/pci/trident/
Nope, this entry is for sound/oss/trident*.
Cheers,
Muli
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
On Mon, Aug 13, 2007 at 10:25:02AM -0700, Joe Perches wrote:
On Mon, 2007-08-13 at 15:18 +0300, Muli Ben-Yehuda wrote:
Nope, this entry is for sound/oss/trident*.
TRIDENT 4DWAVE/SIS 7018 PCI AUDIO CORE
P:Muli Ben-Yehuda
M:[EMAIL PROTECTED]
L:linux-kernel@vger.kernel.org
S
On Thu, Aug 09, 2007 at 02:29:58PM +0100, Jan Beulich wrote:
> The issue here is not with clflush by itself, but with what pages it
> is being applied to. Here, it gets used on page table pages when
> flushing really is needed on what one or more page table entries in
> that page table page
On Thu, Aug 09, 2007 at 02:41:31PM +0200, Andi Kleen wrote:
>
> It turns out CLFLUSH support is still not complete; we
> flush the wrong pages. Again disable it for the release.
> Noticed by Jan Beulich.
>
> Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
Aside from the bug Jan pointed out with
"pci=noacpi" on your laptop?
Comments appreciated. If this looks ok it should go into 2.6.23.
Signed-off-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
Cc: Yinghai Lu <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Cc: Andrew Morton <[EMAIL PROTECTED]>
Cc: Chu
On Thu, Aug 09, 2007 at 02:41:31PM +0200, Andi Kleen wrote:
It turns out CLFLUSH support is still not complete; we
flush the wrong pages. Again disable it for the release.
Noticed by Jan Beulich.
Signed-off-by: Andi Kleen [EMAIL PROTECTED]
Aside from the bug Jan pointed out with the
?
Comments appreciated. If this looks ok it should go into 2.6.23.
Signed-off-by: Muli Ben-Yehuda [EMAIL PROTECTED]
Cc: Yinghai Lu [EMAIL PROTECTED]
Cc: Andi Kleen [EMAIL PROTECTED]
Cc: Andrew Morton [EMAIL PROTECTED]
Cc: Chuck Ebbert [EMAIL PROTECTED],
Cc: [EMAIL PROTECTED]
Cc: Andy Whitcroft
On Thu, Aug 09, 2007 at 02:29:58PM +0100, Jan Beulich wrote:
The issue here is not with clflush by itself, but with what pages it
is being applied to. Here, it gets used on page table pages when
flushing really is needed on what one or more page table entries in
that page table page point(ed)
On Tue, Aug 07, 2007 at 06:20:33PM -0700, Yinghai Lu wrote:
> please check this one against pci_scan_bus_with_sysdata
>
> [PATCH 1/5] x86_64: get mp_bus_to_node as early v3
>
> current on amd k8 system with multi ht chain, the numa_node of pci
> devices under r/sys/devices/pci:80/* always
On Tue, Aug 07, 2007 at 06:20:33PM -0700, Yinghai Lu wrote:
please check this one against pci_scan_bus_with_sysdata
[PATCH 1/5] x86_64: get mp_bus_to_node as early v3
current on amd k8 system with multi ht chain, the numa_node of pci
devices under r/sys/devices/pci:80/* always 0, even
On Tue, Aug 07, 2007 at 03:49:11PM -0700, Andrew Morton wrote:
> I am sooo tired of this thing. Andi, someone, can we for heaven's
> sake please just get it all sorted out?
With regards to the sysdata conversion: Riku says he cannot test new
kernel. I haven't heard anything from Andy
On Tue, Aug 07, 2007 at 03:49:11PM -0700, Andrew Morton wrote:
I am sooo tired of this thing. Andi, someone, can we for heaven's
sake please just get it all sorted out?
With regards to the sysdata conversion: Riku says he cannot test new
kernel. I haven't heard anything from Andy
On Sun, Aug 05, 2007 at 01:49:57AM -0700, Yinghai Lu wrote:
> Can you change
> pci_scan_bus_with_sysdata(int busno)
> to
> pci_scan_bus_on_node(int bus, struct pci_ops *ops, int node)?
Do you anticipate passing in a different pci_ops or node?
In any case please remember I am aiming for the
x86-64. Unfortunately none of
my machines exhibited the bugs so caveat emptor.
Andy, could you please see if this fixes the NUMA issues you've seen?
Riku, does this fix "pci=noacpi" on your laptop?
Comments appreciated. If this looks ok it should go into 2.6.23.
Signed-off-by: Mu
1 - 100 of 305 matches
Mail list logo
