Hi Andi,
This patch should go into mainline in the next x86-64 update.
Thanks,
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
From: Muli Ben-Yehuda <[EMAIL PROTECTED]>
- set bad_dma_address explicitly to 0x0
- reserve 32 pages from bad_dma_address and up
- WARN_ON() a driver feeding us bad_dma_address
Thanks to Leo Duran <[EMAIL PROTECTED]> for the suggestion.
Signed-off-by: Muli Ben-Yehuda <[EMAIL PROT
From: Yinghai Lu <[EMAIL PROTECTED]>
there function are called via dma_ops->.., so change them to static
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
Signed-off-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/pci-calgary.c |8
1 files change
apply.
Thanks,
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/
From: Muli Ben-Yehuda <[EMAIL PROTECTED]>
After the bitmap changes we can get rid of the unlocked versions of
calgary_unmap_sg and iommu_free. Fold __calgary_unmap_sg and
__iommu_free into their calgary_unmap_sg and iommu_free, respectively.
Signed-off-by: Muli Ben-Yehuda <[EMAIL
From: Muli Ben-Yehuda <[EMAIL PROTECTED]>
No actual code was harmed in the production of this patch.
Thanks to Andrew Morton <[EMAIL PROTECTED]> for telling me
about checkpatch.pl.
Signed-off-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/pci-calgary.c |9
From: Muli Ben-Yehuda <[EMAIL PROTECTED]>
Currently the IOMMU table's lock protects both the bitmap and access
to the hardware's TCE table. Access to the TCE table is synchronized
through the bitmap; therefore, only hold the lock while modifying the
bitmap. This gives a yummy 10-
From: Muli Ben-Yehuda <[EMAIL PROTECTED]>
Signed-off-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
---
sound/oss/trident.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/sound/oss/trident.c b/sound/oss/trident.c
index 2e3e78e..96adc47 100644
--- a/sound/o
From: Muli Ben-Yehuda <[EMAIL PROTECTED]>
Signed-off-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
---
sound/oss/trident.c | 358 +-
1 files changed, 179 insertions(+), 179 deletions(-)
diff --git a/sound/oss/trident.c b/sound/oss/tri
From: Muli Ben-Yehuda <[EMAIL PROTECTED]>
trident_write_voice_regs() was getting called with the card spinlock
held in only some cases. Fix it.
Explanation: we allocate a new virtual channel in open, and then we
frob some hardware registers (in write_voice_regs) for that
channel. B
Andi,
Here are Calgary updates for 2.6.23. The most notable change is the
addition of support for the CalIOC2 PCI-E IOMMU - more details in the
patchset. Please apply.
Thanks,
Muli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
From: Muli Ben-Yehuda <[EMAIL PROTECTED]>
... in preparation for doing it differently for CalIOC2.
Signed-off-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/pci-calgary.c | 21 ++---
1 files changed, 14 insertions(+), 7 deletions(-)
diff --git a
From: Muli Ben-Yehuda <[EMAIL PROTECTED]>
CalIOC2 is a PCI-e implementation of the Calgary logic. Most of the
programming details are the same, but some differ, e.g., TCE cache
flush. This patch introduces CalIOC2 support - detection and various
support routines. It's not expected
From: Muli Ben-Yehuda <[EMAIL PROTECTED]>
Signed-off-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/pci-calgary.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/x86_64/kernel/pci-calgary.c b/arch/x86_64/kernel/pci-calgary.c
i
From: Muli Ben-Yehuda <[EMAIL PROTECTED]>
Signed-off-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/pci-calgary.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86_64/kernel/pci-calgary.c b/arch/x86_64/kernel/pci-calgary.c
index 4b0c
From: Muli Ben-Yehuda <[EMAIL PROTECTED]>
... will be used by CalIOC2 later
Signed-off-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/pci-calgary.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/x86_64/kernel/pci-calgary.c b
From: Muli Ben-Yehuda <[EMAIL PROTECTED]>
Provide seperate versions for Calgary and CalIOC2
Also print out the PCIe Root Complex Status on CalIOC2 errors
Signed-off-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/pci-calg
From: Muli Ben-Yehuda <[EMAIL PROTECTED]>
Signed-off-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/pci-calgary.c | 88 +-
1 files changed, 87 insertions(+), 1 deletions(-)
diff --git a/arch/x86_64/kernel/pci-calgary.c b/arch/x
From: Muli Ben-Yehuda <[EMAIL PROTECTED]>
Signed-off-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/pci-calgary.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86_64/kernel/pci-calgary.c b/arch/x86_64/kernel/pci-calgary.c
index 0bb0
From: Muli Ben-Yehuda <[EMAIL PROTECTED]>
Signed-off-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/pci-calgary.c | 38 ++
1 files changed, 34 insertions(+), 4 deletions(-)
diff --git a/arch/x86_64/kernel/pci-calgary.c b/arch/x
From: Muli Ben-Yehuda <[EMAIL PROTECTED]>
Signed-off-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/pci-calgary.c | 13 +++--
1 files changed, 3 insertions(+), 10 deletions(-)
diff --git a/arch/x86_64/kernel/pci-calgary.c b/arch/x86_64/kernel/pci-cal
From: Muli Ben-Yehuda <[EMAIL PROTECTED]>
Calgary and CalIOC2 share most of the same logic. Introduce struct
cal_chipset_ops for quirks and tce flush logic which are
different. CalIOC2 implementation to appear in a later patch.
Signed-off-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
---
From: Muli Ben-Yehuda <[EMAIL PROTECTED]>
Move the aic94xx split completion timeout handling there.
Signed-off-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/pci-calgary.c | 25 +
1 files changed, 17 insertions(+), 8 deletions(-)
diff
From: Guillaume Thouvenin <[EMAIL PROTECTED]>
Cleanup unneeded macros used for register space address calculation.
Now we are using the EBDA to find the space address.
Signed-off-by: Guillaume Thouvenin <[EMAIL PROTECTED]>
Signed-off-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
From: Muli Ben-Yehuda <[EMAIL PROTECTED]>
This works around a bug where DMAs that have the same addresses as
some MEM regions do not go through. Not clear yet if this is due to a
mis-configuration or something deeper.
Signed-off-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
---
arch/x86_6
From: Muli Ben-Yehuda <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/pci-calgary.c | 44 +++---
1 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/arch/x86_64/kernel/pci-calgary.c b/arch/x86_64/kernel/pci-calgary.c
index 5ec9be2..0bb0eb0 100644
7295 cpu_id=3
-0 [003] d...2.. 355.621762: cpu_idle: state=1 cpu_id=3
--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 at http://www.tux.org/lkml/
as well, to make NO_HZ_FULL work again on the stable trees?
Thanks,
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
O is to fix the drivers to batch mapping and unmapping operations
or map up-front and unmap when done. The streaming DMA-API was
designed to conserve IOMMU mappings for machines where IOMMU mappings
are a scarce resource, and is a poor fit for a modern IOMMU such as
VT-d with a 64-bit IO address spa
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
symmetry. Feel free to nuke
it and walk the list forward.
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/
g like the patch 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/
PCI
device initialization, since we want to turn translation on before any
device will try to DMA.
In conclusion, our usage doesn't seem lika a good fit for the probe
approach, although it could probably converted provided we got the
ordering right with regards to regular PCI device
initializati
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 [EMA
t; + vma->vm_start = VSYSCALL32_BASE;
> + vma->vm_end = VSYSCALL32_END;
> + /* MAYWRITE to allow gdb to COW and set breakpoints */
> + vma->vm_flags =
> VM_READ|VM_EXEC|VM_MAYREAD|VM_MAYEXEC|VM_MAYEXEC|VM_MAYWRITE;
Any reason for VM_MAYEXEC to be specifie
On Tue, Aug 30, 2005 at 07:37:59PM +0200, Jesper Juhl wrote:
> Here's a quick list of suspects for you :
[snip]
> ./sound/oss/trident.c
I'll take care of this one.
Cheers,
Muli
--
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/
-
To unsubscribe from thi
On Tue, Aug 30, 2005 at 08:54:59PM +0300, Muli Ben-Yehuda wrote:
> On Tue, Aug 30, 2005 at 07:37:59PM +0200, Jesper Juhl wrote:
> > Here's a quick list of suspects for you :
>
> [snip]
>
> > ./sound/oss/trident.c
>
> I'll take care of this one.
hing that does boot
Linux such as qemu strikes me as a much easier approach than modifying
a kernel running on bare metal to also use "virtual" hardware.
Cheers,
Muli
--
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/
-
To unsubscribe from this list: send the line &
ready 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:
* Patr
not be
corrupted...) from the old kernel.
Cheers,
Muli
On Wed, Oct 10, 2007 at 02:10:13AM +0530, chandru wrote:
> kdump kernel fails to boot with calgary iommu and aacraid driver on
> a x366 box. The ongoing dma's of aacraid from the first kernel
> continue to exist until the driver
the Makefile
to become less readable.
Cheers,
Muli
--
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/
signature.asc
Description: Digital signature
unk <[EMAIL PROTECTED]>
Thanks, applied. Will push with my next batch of Calgary updates.
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/m
I need the same facility for Calgary for falling back to swiotlb if a
translation is disabled on some slot, and IB needs the same facility
for some IB adapters (e.g., ipath). Perhaps it's time to consider
stackable dma-ops (unless someone has a better idea...).
Cheers,
Muli
-
To unsubscribe fr
ons.
Doesn't really belong in the DMA mapping API. Instead what I think we
should do is to cache this (per device) value in the pci_device struct
(or device struct?) and in the dma-ops implementation inspect it to
decide exactly how to do DMA mapping for this device.
Cheers,
Muli
-
To unsubsc
. the reason it's done this way is that
Andi Kleen preferred it for some reason at the time. How about trying
to fix it cleanly so that dma_alloc_coherent always gets called rather
than adding a hack to work around a hack? It will require auditing all
of the different x86 dma-ops but I can he
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
t just return prev_ops->op if it's set.
> It seems a small dispatcher which takes care of this seems the
> likely choice here, but avoiding it (or at least caching the
> decisions) is something that needs more thought.
Yeah, I'm not too enthusiastic about it, but we do need su
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
th
lear_pmen_epm = 0;
`suppress', I assume. Rest looks fine, if the configuration option is
really needed.
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
point to 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
--
SYS
m volatile("wbinvd":::"memory");
> >> + wbinvd();
> >
> > I guess it can be just removed there. I don' think there are any
> > calgary machines without clflush
> >
> That seems like an unsafe thing to do (unless we err out so
f (last_page &&
> + (((unsigned long)page^(unsigned long)last_page) &
> + clflush_mask))
> + clflush(last_page);
Same thing.
> last_page = page;
> }
>
> if ( last_page )
> -
On Sat, Jul 21, 2007 at 12:52:26PM -0700, H. Peter Anvin wrote:
> Muli Ben-Yehuda wrote:
> >
> > Mostly looks good, but see below.
> >
> >> diff --git a/drivers/char/agp/efficeon-agp.c
> >> b/drivers/char/agp/efficeon-agp.c
> >> index df8da72..41f
On Sat, Jul 21, 2007 at 01:18:54PM -0700, H. Peter Anvin wrote:
> Muli Ben-Yehuda wrote:
> >
> > So it looks like we have a purely syntactic patch that does something
> > different than the original code in one of the above places. What am I
> > missing?
> >
On Sat, Jul 21, 2007 at 03:09:41PM -0700, H. Peter Anvin wrote:
> Muli Ben-Yehuda wrote:
> >
> > Ok, let's try again:
> >
> > You're changing this (pageattr.c)
> >
> > asm volatile("clflush (%0)" :: "r" (adr
igned-off-by: Randy Dunlap <[EMAIL PROTECTED]>
At some point in time we will need to support hotplug with IOMMU
translation enabled, in which case they'll be called when hotplug
happens as well, but in the mean time
Signed-off-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
I'll
prototype is for consistency's sake with the
definition. The extern I have no idea... probably legacy from some
other code, but they don't bother me.
Anyway, forgot to mention earlier - thanks for your patch!
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe l
nce to
.init.text:free_bootmem (between 'free_tce_table' and 'build_tce_table')
WARNING: vmlinux.o(.text+0x187e5): Section mismatch: reference to
.init.text:__alloc_bootmem_low (between 'alloc_tce_table' and
'kretprobe_trampoline_holder')
Signed-off-by: Randy Du
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
}
> > }
> > }
> >
>
> Andy keeps trotting out a patch which will probably fix this, but
> for some reason it doesn't seem to make progress.
Hmm, looks like we're missing one of the paths where
on any of my machines, but I'm
looking into it.
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 Sat, Aug 04, 2007 at 09:33:58PM -0700, Yinghai Lu wrote:
> I hope we can use .node and .iommu in pci_bus...
pci_bus is shared between different architectures, and not all
architectures need .node and .iommu. Why is this better than using the
(arch specific) ->sysdata?
Cheers,
Mul
2.6.23-rc1 ->sysdata breakage?
Reverting my and jgarzik's sysdata patch won't fix Andy's issue.
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.kern
_bus_to_node-as-early-v2) that only takes care
of the missing ->sysdata bits. If that patch cures the original bug
and doesn't cause any more regressions, it's definitely 2.6.23
material.
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/
h should be considered for 2.6.24.
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/
S) and run-time tested on i386 and 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 s
ming for the minimal "obviously
correc" change for 2.6.23...
> pci_scan_bus_with_sysdata(int busno) make me feel that i need feed one
> sysdata as on param for it.
Yeah, lousy name, but the best I came up with. Runner up was
'x86_pci_scan_bus', which is I think worse?
Cheers
ything from Andy Whitcroft. It passes all of
my tests and what we have now is obviously broken... I think we should
put the fix in.
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:/
ne update version to pci_sysdata ... also reverse
> pci_acpi_scan_root to use pcibios_scan_root again.
Can you explain why this patch (and your other patches in this area)
are needed? is this a performance issue? the patches seem complex, is
there a good argument for that complexity?
Cheers,
bug Jan pointed out with the patch, we're also using
cflflush in other places (arch/i386/kernel/alternative.c and
arch/x86_64/kernel/tce.c). Is the issue with clflush support specific
to pageattr.c or should it be disabled every else too? what
specifically is the issue?
Cheers,
Muli
-
To uns
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: Muli Ben-Yehuda <[EMAIL PROTECTED]>
Cc: Yinghai Lu <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Cc: An
e page point(ed) to.
I see, thanks.
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 Sun, Jul 29, 2007 at 06:27:22PM -0700, Randy Dunlap wrote:
> From: Randy Dunlap <[EMAIL PROTECTED]>
>
> Fix typos and update function parameters.
>
> Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
Acked-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
Cheers,
Mul
On Wed, Aug 01, 2007 at 07:53:15PM +0200, Michal Piotrowski wrote:
> Hi,
>
> There is no need to include linux/init.h twice
Thanks, looks good. Will be pushed for 2.6.24.
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
Andrew, can you please push this Calgary bug-fix to 2.6.23 in your
next merge? it fixes a showstopper bug in the recently merged CalIOC2
support that hits machines with multiple levels of PCI-to-PCI bridges.
Thanks,
Muli
---
From: Murillo Fernandes Bernardes <[EMAIL PROTECTED]>
Subject:
+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
Multiple F: lines acceptable.
> -
> 3C359 NETWORK DRIVER
> P: Mike Phillips
> M: [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/
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 "uns
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]
renaming the config option to
CONFIG_GART_IOMMU while you're at it?
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 unsubscr
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
-
To
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
IOMMU is off?" and "how come some iommu_xxx options
(which were really gart options...) don't actually affect the
(Calgary) IOMMU"?
If the variable names clash the correct solution is to s/gart/agpgart/
in the AGP code and then continue renaming gart specific bits 'gart&#
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
> restrictions, rather than fixing all the IOMMUs' free area
> management,
In general it sounds like a great idea, but have you looked at what
impact this has on the performance of the IO path?
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel&q
- } while (count--);
> > + } while (--count);
> >
> > spin_unlock_irqrestore(&card->lock, flags);
> >
> > if (count == 0) {
> >
>
> Thanks, much better. In the future, please also CC: the appropriate
> maintainers, o
7;t checking the
return value *on purpose*. More information is good.
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/
(dir == DMA_NONE);
> +}
While this doesn't look very useful. Why is "DMA_NONE" a uni-dir? I
suggest replacing this with an open coded (dir != DMA_BIDIRECTIONAL).
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/
27;d add a BUG_ON such as (dir < 0 || dir >
> DMA_BIDIRECTIONAL)
If DMA_NONE isn't actually allowed here, you can use valid_dma_direction().
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/
ing quiet when we
don't find the HW is the appropriate thing to do. I'll push a patch to
make this KERN_DEBUG in the next batch of updates.
Cheers,
Muli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTE
calgary.c. [...]
>
> no, what happened is what i described in my second patch. That 'new
> code' which was default-enabled had a bug which locked up my box.
Yes, I realized that once I've read your other mail.
Cheers,
Muli
-
To unsubscribe from this list: send the line &quo
/. Especially
> if it's in a hard to debug place like early bootup code.
No argument about this.
> This incident i think shows that bisection and testing in -mm doesnt
> always cut it (bisection-testing is quite laborous with a large
> distro kernel), and i think we could do more tec
kthread_bind(cct->task, any_online_cpu(cpu_online_map));
> + destroy_comp_task(pool, cpu);
> + }
This is correct because cct is allocated via alloc_percpu, which in
turn calls kzalloc, which means cct->task is NULL by default, but it's
a little too obscure for me. How about making it explicit?
task = kthread_create(...)
if (!IS_ERR(task))
cct->task = task;
else
cct->task = NULL;
return cct->task;
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 Mon, Dec 25, 2006 at 06:35:57PM +0900, Akinobu Mita wrote:
> On Mon, Dec 25, 2006 at 10:55:51AM +0200, Muli Ben-Yehuda wrote:
> > This is correct because cct is allocated via alloc_percpu, which in
> > turn calls kzalloc, which means cct->task is NULL by default, but it&
e reader will thank you if you explain
when each should be used. In this case, the second form should be used
when the macro needs to return a value (and you can't use an inline
function for whatever reason), whereas the first form should be used
at all other times.
Cheers,
Muli
-
To unsubscr
ingStyle is to clarify how new code should
be written and old code should've been written.
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-inf
Signed-off-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/pci-calgary.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/x86_64/kernel/pci-calgary.c b/arch/x86_64/kernel/pci-calgary.c
index 87d90cb..3d65b1d 100644
--- a/arch/x86_64/kern
ething a bit more obvious.
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/
sent on
Feb 6th.
Thanks,
Muli
Subject: x86-64 Calgary: robustify bad_dma_address handling
From: Muli Ben-Yehuda <[EMAIL PROTECTED]>
- set bad_dma_address explicitly to 0x0
- reserve 32 pages from bad_dma_address and up
- WARN_ON() a driver feeding us bad_dma_address
Thanks to Leo Duran <[E
1 - 100 of 181 matches
Mail list logo
