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 wher
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 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 f
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/
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
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 major
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
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 conti
the Makefile
to become less readable.
Cheers,
Muli
--
Muli Ben-Yehuda
http://www.mulix.org | http://mulix.livejournal.com/
signature.asc
Description: Digital signature
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,
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 facil
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 b
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 t
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 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
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
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 p
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
On Fri, Jul 20, 2007 at 10:22:21AM -0700, H. Peter Anvin wrote:
> Andi Kleen wrote:
> > On Friday 20 July 2007 00:55:40 Glauber de Oliveira Costa wrote:
> >> This patch uses the already-existant wbinvd() macro to replace
> >> raw assembly to perform this very same task in some .c files
> >>
>
On Fri, Jul 20, 2007 at 02:19:58PM -0700, H. Peter Anvin wrote:
> Create an inline function for clflush(), with the proper arguments,
> and use it instead of hard-coding the instruction.
>
> This also removes one instance of hard-coded wbinvd, based on a patch
> by Bauder de Oliveira Costa.
>
> C
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
On Thu, Jul 26, 2007 at 12:02:38PM +0200, Sam Ravnborg wrote:
> Now I recall I saw it too :-(
> This one is beeter although the __init in the prototype declaration
> should have no effect. (Also wonder why the prototypes are extern -
> that should be a no-op too).
The __init in the prototype is
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 list: send the lin
On Fri, Aug 03, 2007 at 03:50:35PM -0700, Andrew Morton wrote:
> On Fri, 03 Aug 2007 18:10:03 -0400
> Chuck Ebbert <[EMAIL PROTECTED]> wrote:
>
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=250859
> >
> > at line 74:
> >
> > [EMAIL PROTECTED]:
> > [EMAIL PROTECTED]:
On Sun, Aug 05, 2007 at 01:40:49AM +0200, Andi Kleen wrote:
> > "pci device ensure sysdata initialised", now at version 4.
>
> Oh what a mess. I think I'll ask Linus to revert the sysdata patch
> instead. Clearly the stuff is half-baked
Personally I don't care that much, but I think you'll make
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,
Muli
-
To unsubs
On Sun, Aug 05, 2007 at 01:40:49AM +0200, Andi Kleen wrote:
> Oh what a mess. I think I'll ask Linus to revert the sysdata patch
> instead. Clearly the stuff is half-baked
By the way, Andi, just making sure you're aware the issue Andy's patch
addresses is separate from the 2.6.23-rc1 ->sysdata br
On Sat, Aug 04, 2007 at 10:52:22PM -0700, Andrew Morton wrote:
> On Sat, 4 Aug 2007 12:02:35 -0700 "Yinghai Lu" <[EMAIL PROTECTED]> wrote:
>
> > On 8/4/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > On Sat, 4 Aug 2007 10:45:31 -0700 "Yinghai Lu" <[EMAIL PROTECTED]> wrote:
> > >
> > > > Andrew,
On Sat, Aug 04, 2007 at 11:07:04PM -0700, Yinghai Lu wrote:
> You just use my patch plus Andy's patch together...
Your patch does other things that in my opinion are not appropriate at
this stage for 2.6.23. I am aiming for the minimal change that will
fix the regression, and your patch should be
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
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 minim
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 Whitcro
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,
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 t
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
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(
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 a message to [EMAIL PRO
pwards until we get to the top (Calgary/CalIOC2
bridge), where the iommu table resides.
Signed-off-by: Murillo Fernandes Bernardes <[EMAIL PROTECTED]>
Signed-off-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
--
diff -ruN linux-2.6.23-rc1.orig/arch/x86_64/kernel/pci-calgary.c
linux-2.6.23-rc1/
+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
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,
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]
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 o
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
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
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 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:
>
> http://t
- } 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
On Sun, Jan 14, 2007 at 12:05:13PM +0100, Jan Engelhardt wrote:
> >+(void)xenbus_switch_state(info->xbdev, XenbusStateConnected);
>
> Cast remove, if xenbus_switch_state does not have __must_check.
> Also elsewhere.
Hmm, why? this way you know that the programmer isn't checking the
return va
On Mon, Jan 22, 2007 at 01:21:28AM +0200, Boaz Harrosh wrote:
> - Introduce a new enum dma_data_direction data_dir member in struct request.
> and remove the RW bit from request->cmd_flag
Some architecture use 'enum dma_data_direction' and some 'int
dma_data_direction'. The consensus was to mov
On Tue, Jan 23, 2007 at 03:45:00PM +0200, Benny Halevy wrote:
> >> +static inline int dma_uni_dir(enum dma_data_direction dir)
> >> +{
> >> + return (dir == DMA_TO_DEVICE) || (dir == DMA_FROM_DEVICE) ||
> >> + (dir == DMA_NONE);
> >> +}
> >
> > While this doesn't look very useful. Why is
On Wed, Dec 20, 2006 at 10:28:28AM -0500, Dave Jones wrote:
> Good job tracking this down. I saw someone get bit by probably this
> same bug a few days ago. Whilst on the subject though, can we do
> something about the printk ?
Calgary can't be built as a module. I agree that being quiet when w
On Wed, Dec 20, 2006 at 05:23:38PM +0100, Ingo Molnar wrote:
> > I think that it makes sense to have it default y for the mainline
> > kernel and default n for the distro kernels, which is why I added the
> > option to make it possible to compile Calgary in but only enable it if
> > you want to
On Thu, Dec 21, 2006 at 11:37:02AM +0100, Ingo Molnar wrote:
> I think in the future it would be better to annotate the introduction of
> new, widely used codepaths via KERN_DEBUG printouts, something along the
> lines of:
>
> printk(KERN_DEBUG "calgary: running new EBDA code.\n");
>
On Mon, Dec 25, 2006 at 05:30:23PM +0900, Akinobu Mita wrote:
> On Mon, Dec 25, 2006 at 05:12:57PM +0900, Akinobu Mita wrote:
> > Index: 2.6-mm/drivers/infiniband/hw/ehca/ehca_irq.c
> > ===
> > --- 2.6-mm.orig/drivers/infiniband/hw/ehc
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&
On Sun, Dec 31, 2006 at 02:32:25PM -0500, Robert P. J. Day wrote:
> Generally, inline functions are preferable to macros resembling
> functions.
This should be stressed, IMHO. We have too many macros which have no
reason to live.
> -Macros with multiple statements should be enclosed in a do -
On Sun, Dec 31, 2006 at 02:49:48PM -0500, Robert P. J. Day wrote:
> there would appear to be *lots* of cases where the ({ }) notation is
> used when nothing is being returned. i'm not sure you can be that
> adamant about that distinction at this point.
IMHO, the main point of CodingStyle is to c
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
On Wed, Feb 21, 2007 at 10:06:52AM +0200, Pekka J Enberg wrote:
> From: Pekka Enberg <[EMAIL PROTECTED]>
>
> This exports ksize in slab and slob allocators to modules.
That's a pretty generic name... if it's going to be part of the module
API, it should be renamed to something a bit more obvious.
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
On Sat, Feb 10, 2007 at 02:52:16PM +0100, Andi Kleen wrote:
> On Saturday 10 February 2007 14:43, Muli Ben-Yehuda wrote:
> > On Sat, Feb 10, 2007 at 12:42:48PM +0100, Andi Kleen wrote:
> > >
> > > I will post the existing patches in batches for closer review.
>
On Mon, Feb 12, 2007 at 09:14:25AM +0100, Arjan van de Ven wrote:
> Xen the linux guest
> or
> Xen the hypervisor?
>
> if it's the later, why on earth would we want to uglyfy linux for it?
> (arguably it holds in the former case as well)
Xen the hypervisor (i.e., dom0).
Cheers,
Muli
-
To unsubs
On Mon, Feb 12, 2007 at 03:47:50PM -0800, Joe Perches wrote:
> Now that most of the sizeof(array)/sizeof(array[0]) conversions have
> been done (there are about 800 done and about another 130 left),
> perhaps it could be useful to change the code to use a define
> similar to the list_for_each
>
>
On Tue, Jan 30, 2007 at 06:51:51AM +0100, Jes Sorensen wrote:
> Last year the subject of DMA engines was put up, however most of the
> people interested in the subject weren't even invited. In that case
> there's really little concrete that can come out of the discussion.
Likewise IOMMUs.
I thin
On Tue, Jan 30, 2007 at 02:18:16AM -0500, Dave Jones wrote:
> > Likewise IOMMUs.
>
> There were a number of people there last year who understood IOMMUs
> and could easily talk at length about them if able to do so. iirc,
> you were also invited, but were unable to travel due to bad things
> f
On Thu, Dec 07, 2006 at 03:49:53PM +0100, Olivier Galibert wrote:
> +void __init pci_mmcfg_init(int type)
> +{
> + extern int pci_mmcfg_arch_init(void);
Please put this in a suitable header file.
> @@ -27,7 +23,7 @@
> /* The base address of the last MMCONFIG device accessed */
> static u32
On Thu, Dec 07, 2006 at 03:50:52PM +0100, Olivier Galibert wrote:
> The x86-64 mmconfig code always map a range of MMCONFIG_APER_MAX
> bytes, i.e. 256MB, whatever the number of accessible busses is. Fix
> it, and add the end of the zone in the printk while we're at it.
>
> Signed-off-by: Olivier
On Thu, Dec 07, 2006 at 04:19:41PM +0100, Olivier Galibert wrote:
> On Thu, Dec 07, 2006 at 05:00:23PM +0200, Muli Ben-Yehuda wrote:
> > On Thu, Dec 07, 2006 at 03:49:53PM +0100, Olivier Galibert wrote:
> >
> > > +void __init pci_mmcfg_init(int type)
>
On Thu, Dec 07, 2006 at 04:53:36PM +0100, Olivier Galibert wrote:
> # git grep '//' -- '*.c' |fgrep -v 'http://' |wc -l
> 14333
>
> You lost that war ages ago. Come join us in this millenia,
> line-comments exist officially in C since 1999, and were supported
> way before that.
If I was bored,
On Fri, Dec 08, 2006 at 01:04:23PM +0100, Arkadiusz Miskiewicz wrote:
> On Friday 08 December 2006 04:01, Andi Kleen wrote:
>
> > - Support for a Processor Data Area (PDA) on i386. This makes
> > the code more similar to x86-64 and will allow some other
> > optimizations in the future.
>
> LD
On Fri, Dec 08, 2006 at 02:03:12PM +0100, Arkadiusz Miskiewicz wrote:
> On Friday 08 December 2006 13:51, Muli Ben-Yehuda wrote:
> > On Fri, Dec 08, 2006 at 01:04:23PM +0100, Arkadiusz Miskiewicz wrote:
> > > On Friday 08 December 2006 04:01, Andi Kleen wrote:
> > >
On Sun, Dec 10, 2006 at 06:59:10AM +1100, Benjamin Herrenschmidt wrote:
> I'd really like to have some kind of macro or attribute or whatever I
> can put on a function call to say that I'm purposefully ignoring the
> error. Is there some gcc magic that can do that ?
(void)bla()?
Cheers,
Muli
-
T
On Mon, Dec 11, 2006 at 05:35:06PM +0100, Joscha Ihl wrote:
> Hi,
>
> I am using the Nokia E61 phone on my Fujitsu Siemens Amilo D Celeron
> 2.8GHz Notebook as an USB-Modem (cdc_acm 2-1:1.10: ttyACM0: USB ACM
> device) to connect over UMTS to the internet.
>
> If I plug the USB-cable in the Note
On Wed, Dec 13, 2006 at 09:34:16PM +0100, Karsten Weiss wrote:
> FWIW: As far as I understand the linux kernel code (I am no kernel
> developer so please correct me if I am wrong) the PCI dma mapping code is
> abstracted by struct dma_mapping_ops. I.e. there are currently four
> possible implem
On Wed, Dec 13, 2006 at 01:29:25PM -0700, Erik Andersen wrote:
> On Mon Dec 11, 2006 at 10:24:02AM +0100, Karsten Weiss wrote:
> > We could not reproduce the data corruption anymore if we boot
> > the machines with the kernel parameter "iommu=soft" i.e. if we
> > use software bounce buffering inste
On Thu, Dec 14, 2006 at 12:33:23AM +0100, Christoph Anton Mitterer wrote:
> 4)
> And does someone know if the nforce/opteron iommu requires IBM Calgary
> IOMMU support?
It doesn't, Calgary isn't found in machine with Opteron CPUs or NForce
chipsets (AFAIK). However, compiling Calgary in should ma
On Wed, Dec 13, 2006 at 10:15:47PM +0100, Arjan van de Ven wrote:
> with DRI you have the case where "something" needs to do security
> validation of the commands that are sent to the card. (to avoid a
> non-privileged user to DMA all over your memory)
We also have the interesting case where your
On Thu, Dec 14, 2006 at 02:52:35AM -0700, Erik Andersen wrote:
> On Thu Dec 14, 2006 at 11:23:11AM +0200, Muli Ben-Yehuda wrote:
> > > I just realized that booting with "iommu=soft" makes my pcHDTV
> > > HD5500 DVB cards not work. Time to go back to disabling th
On Thu, Dec 14, 2006 at 12:38:08PM +0100, Karsten Weiss wrote:
> On Thu, 14 Dec 2006, Muli Ben-Yehuda wrote:
>
> > On Wed, Dec 13, 2006 at 09:34:16PM +0100, Karsten Weiss wrote:
> >
> > > BTW: It would be really great if this area of the kernel would get some
> >
On Thu, Dec 14, 2006 at 02:16:31PM +0100, Karsten Weiss wrote:
> On Thu, 14 Dec 2006, Muli Ben-Yehuda wrote:
>
> > The rest looks good. Please resend and I'll add my Acked-by.
>
> Thanks a lot for your comments and suggestions. Here's my 2nd try:
>
> ==
On Mon, Dec 18, 2006 at 02:53:05PM -0500, Robert P. J. Day wrote:
>
> Replace kmalloc() + memset() pairs with the appropriate kzalloc()
> calls.
>
> Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
>
> ---
>
> i could have sworn i submitted this patch a while back but it
> doesn't seem t
On Wed, Dec 20, 2006 at 11:28:46AM +0100, Ingo Molnar wrote:
> config CALGARY_IOMMU_ENABLED_BY_DEFAULT
> bool "Should Calgary be enabled by default?"
> default y
> depends on CALGARY_IOMMU
> help
> Should Calgary be enabled by default? if you choose 'y',
On Wed, Dec 20, 2006 at 11:53:32AM +0100, Ingo Molnar wrote:
> Index: linux/arch/x86_64/kernel/pci-calgary.c
> ===
> --- linux.orig/arch/x86_64/kernel/pci-calgary.c
> +++ linux/arch/x86_64/kernel/pci-calgary.c
> @@ -1052,7 +1052,7 @@
On Wed, Dec 20, 2006 at 01:34:15PM +0200, Muli Ben-Yehuda wrote:
> On Wed, Dec 20, 2006 at 11:53:32AM +0100, Ingo Molnar wrote:
[snipped patch]
> Patch looks good to me, thanks. I'll give it a spin to verify.
Signed-off-by: Muli Ben-Yehuda <[EMAIL PROTECTED]>
Andi, I assume
On Thu, Nov 16, 2006 at 09:19:50PM +0200, Yitzchak Eidus wrote:
> is it possible to replace linux kernel internal functions such as
> schdule () to lets say my_schdule () in a run time with a module
> patch??? (so that every call in the kernel to schdule() will go to
> my_schdule()... ) ???
Not
On Fri, Nov 17, 2006 at 06:58:29AM +, Christoph Hellwig wrote:
> This kind of stuff is just sick. Better let them play with their research
> OS for this kind of thing :)
sick, research, what's the difference? :-)
> In practice any non-trivial bug fix requires
> changes to global data struct
On Sun, Nov 19, 2006 at 10:47:12AM +0100, Arjan van de Ven wrote:
>
> >
> > Oh, and if anything starts complaining "But this adds some warnings to
> > my kernel build!", he should either first fix the 200 kB (sic) of
> > warnings I'm getting in 2.6.19-rc5-mm2 starting at MODPOST or go to hell.
On Sun, Nov 19, 2006 at 03:06:00PM +0100, Adrian Bunk wrote:
> unmaintained != not used
>
> As an example, some people might be unhappy if the floppy driver that is
> unmaintained for ages and not in a good state was removed.
I understand. However, if it was slated to be removed, said people
mi
1 - 100 of 153 matches
Mail list logo
