[PATCH]: PCI: GART iommu alignment fixes [v2]

[PATCH]: PCI: GART iommu alignment fixes [v2]

[Prarit Bhargava]

pci_alloc_consistent/dma_alloc_coherent does not return size aligned
addresses.

>From Documentation/DMA-mapping.txt:

"pci_alloc_consistent returns two values: the virtual address which you
can use to access it from the CPU and dma_handle which you pass to the
card.

The cpu return address and the DMA bus master address are both
guaranteed to be aligned to the smallest PAGE_SIZE order which
is greater than or equal to the requested size.  This invariant
exists (for example) to guarantee that if you allocate a chunk
which is smaller than or equal to 64 kilobytes, the extent of the
buffer you receive will not cross a 64K boundary."

1.  Modify alloc_iommu to allow for an alignment mask
2.  Modify pci_gart_simple to return size-aligned values.
3.  Fixup the alignment calculation in the iommu-helper code.
4.  Fix possible overflow in alloc_iommu's boundary_size calculation.
    (It is possible that alloc_iommu()'s boundary_size overflows as
     dma_get_seg_boundary can return 0xffffffff.  In that case, further usage of
     boundary_size triggers a BUG_ON() in the iommu code.)

End result: When allocating from IOMMU, pci_alloc_consistent/dma_alloc_coherent
will now return a size aligned value.

Signed-off-by: Prarit Bhargava <prarit@redhat.com>

diff --git a/arch/x86/kernel/pci-gart_64.c b/arch/x86/kernel/pci-gart_64.c
index faf3229..717ae64 100644
--- a/arch/x86/kernel/pci-gart_64.c
+++ b/arch/x86/kernel/pci-gart_64.c
@@ -83,7 +83,8 @@ AGPEXTERN __u32 *agp_gatt_table;
 static unsigned long next_bit;  /* protected by iommu_bitmap_lock */
 static int need_flush;		/* global flush state. set for each gart wrap */
 
-static unsigned long alloc_iommu(struct device *dev, int size)
+static unsigned long alloc_iommu(struct device *dev, int size,
+				 unsigned long mask)
 {
 	unsigned long offset, flags;
 	unsigned long boundary_size;
@@ -91,16 +92,17 @@ static unsigned long alloc_iommu(struct device *dev, int size)
 
 	base_index = ALIGN(iommu_bus_base & dma_get_seg_boundary(dev),
 			   PAGE_SIZE) >> PAGE_SHIFT;
-	boundary_size = ALIGN(dma_get_seg_boundary(dev) + 1,
+	boundary_size = ALIGN((unsigned long long)dma_get_seg_boundary(dev) + 1,
 			      PAGE_SIZE) >> PAGE_SHIFT;
 
 	spin_lock_irqsave(&iommu_bitmap_lock, flags);
 	offset = iommu_area_alloc(iommu_gart_bitmap, iommu_pages, next_bit,
-				  size, base_index, boundary_size, 0);
+				  size, base_index, boundary_size, mask);
 	if (offset == -1) {
 		need_flush = 1;
 		offset = iommu_area_alloc(iommu_gart_bitmap, iommu_pages, 0,
-					  size, base_index, boundary_size, 0);
+					  size, base_index, boundary_size,
+					  mask);
 	}
 	if (offset != -1) {
 		set_bit_string(iommu_gart_bitmap, offset, size);
@@ -240,10 +242,11 @@ nonforced_iommu(struct device *dev, unsigned long addr, size_t size)
  * Caller needs to check if the iommu is needed and flush.
  */
 static dma_addr_t dma_map_area(struct device *dev, dma_addr_t phys_mem,
-				size_t size, int dir)
+				size_t size, int dir, u64 align_mask)
 {
 	unsigned long npages = to_pages(phys_mem, size);
-	unsigned long iommu_page = alloc_iommu(dev, npages);
+	unsigned long palign_mask = align_mask >> PAGE_SHIFT;
+	unsigned long iommu_page = alloc_iommu(dev, npages, palign_mask);
 	int i;
 
 	if (iommu_page == -1) {
@@ -266,7 +269,8 @@ static dma_addr_t dma_map_area(struct device *dev, dma_addr_t phys_mem,
 static dma_addr_t
 gart_map_simple(struct device *dev, char *buf, size_t size, int dir)
 {
-	dma_addr_t map = dma_map_area(dev, virt_to_bus(buf), size, dir);
+	dma_addr_t map = dma_map_area(dev, virt_to_bus(buf), size, dir,
+				      size - 1);
 
 	flush_gart();
 
@@ -286,7 +290,8 @@ gart_map_single(struct device *dev, void *addr, size_t size, int dir)
 	if (!need_iommu(dev, phys_mem, size))
 		return phys_mem;
 
-	bus = gart_map_simple(dev, addr, size, dir);
+	dma_addr_t map = dma_map_area(dev, virt_to_bus(addr), size, dir, 0);
+	flush_gart();
 
 	return bus;
 }
@@ -345,7 +350,7 @@ static int dma_map_sg_nonforce(struct device *dev, struct scatterlist *sg,
 		unsigned long addr = sg_phys(s);
 
 		if (nonforced_iommu(dev, addr, s->length)) {
-			addr = dma_map_area(dev, addr, s->length, dir);
+			addr = dma_map_area(dev, addr, s->length, dir, 0);
 			if (addr == bad_dma_address) {
 				if (i > 0)
 					gart_unmap_sg(dev, sg, i, dir);
@@ -367,7 +372,7 @@ static int __dma_map_cont(struct device *dev, struct scatterlist *start,
 			  int nelems, struct scatterlist *sout,
 			  unsigned long pages)
 {
-	unsigned long iommu_start = alloc_iommu(dev, pages);
+	unsigned long iommu_start = alloc_iommu(dev, pages, 0);
 	unsigned long iommu_page = iommu_start;
 	struct scatterlist *s;
 	int i;
diff --git a/lib/iommu-helper.c b/lib/iommu-helper.c
index a3b8d4c..39940e7 100644
--- a/lib/iommu-helper.c
+++ b/lib/iommu-helper.c
@@ -16,7 +16,7 @@ again:
 	index = find_next_zero_bit(map, size, start);
 
 	/* Align allocation */
-	index = (index + align_mask) & ~align_mask;
+	index = __ALIGN_MASK(index, align_mask);
 
 	end = index + nr;
 	if (end >= size)

Re: [PATCH]: PCI: GART iommu alignment fixes [v2]

[Joerg Roedel]

On Wed, Jul 23, 2008 at 07:19:43AM -0400, Prarit Bhargava wrote:
> pci_alloc_consistent/dma_alloc_coherent does not return size aligned
> addresses.
> 
> >From Documentation/DMA-mapping.txt:
> 
> "pci_alloc_consistent returns two values: the virtual address which you
> can use to access it from the CPU and dma_handle which you pass to the
> card.
> 
> The cpu return address and the DMA bus master address are both
> guaranteed to be aligned to the smallest PAGE_SIZE order which
> is greater than or equal to the requested size.  This invariant
> exists (for example) to guarantee that if you allocate a chunk
> which is smaller than or equal to 64 kilobytes, the extent of the
> buffer you receive will not cross a 64K boundary."

Interesting. Have you experienced any problems because of that
misbehavior in the GART code? AMD IOMMU currently also violates this
requirement. I will send a patch to fix that there too.

Joerg

Re: [PATCH]: PCI: GART iommu alignment fixes [v2]

[FUJITA Tomonori]

On Thu, 24 Jul 2008 00:10:33 +0200
Joerg Roedel <joro@8bytes.org> wrote:

> On Wed, Jul 23, 2008 at 07:19:43AM -0400, Prarit Bhargava wrote:
> > pci_alloc_consistent/dma_alloc_coherent does not return size aligned
> > addresses.
> > 
> > >From Documentation/DMA-mapping.txt:
> > 
> > "pci_alloc_consistent returns two values: the virtual address which you
> > can use to access it from the CPU and dma_handle which you pass to the
> > card.
> > 
> > The cpu return address and the DMA bus master address are both
> > guaranteed to be aligned to the smallest PAGE_SIZE order which
> > is greater than or equal to the requested size.  This invariant
> > exists (for example) to guarantee that if you allocate a chunk
> > which is smaller than or equal to 64 kilobytes, the extent of the
> > buffer you receive will not cross a 64K boundary."
> 
> Interesting. Have you experienced any problems because of that
> misbehavior in the GART code? AMD IOMMU currently also violates this
> requirement. I will send a patch to fix that there too.

IIRC, only PARISC and POWER IOMMUs follow the above rule. So I also
wondered what problem he hit.

Re: [PATCH]: PCI: GART iommu alignment fixes [v2]

[Prarit Bhargava]

>> Interesting. Have you experienced any problems because of that
>> misbehavior in the GART code? AMD IOMMU currently also violates this
>> requirement. I will send a patch to fix that there too.
>>     
>
>   

Joerg,  yes I can see misbehavior caused by this code.  O/w I wouldn't 
be spending my time fixing it :) :)

See below ....

> IIRC, only PARISC and POWER IOMMUs follow the above rule. So I also
> wondered what problem he hit.
>   

I wonder if IBM's Calgary IOMMU needs this fix? ... I've added Ed 
Pollard to find out.

On big memory footprint (16G or above) systems it is possible that the 
e820 map reserves most of the lower 4G of memory for system use*.  So 
it's possible that the 4G region is almost completely reserved at boot 
time and so the kernel starts using the IOMMU for DMA (see 
dma_alloc_coherent()).  The addresses returned are not properly aligned, 
and this causes serious problems for some drivers that require a 
physical aligned address for the device.

P.

* I have one large system with 64G of memory on which I can reproduce 
this issue very quickly.  Even booting the system with mem=16G seems to 
cause the problem, although I did have to load a module that reserved a 
few M of DMA addresses before I started alloc'ing from the IOMMU.

I also reproduced this on a smaller system by loading one module that 
reserved as much DMA-able region as possible, and then loaded another 
module that reserved from the IOMMU.  While this situation is a bit 
contrived the bug still hit -- the returned addresses are not properly 
aligned.

Re: [PATCH]: PCI: GART iommu alignment fixes [v2]

[Joerg Roedel]

On Wed, Jul 23, 2008 at 07:47:03PM -0400, Prarit Bhargava wrote:
> 
> >>Interesting. Have you experienced any problems because of that
> >>misbehavior in the GART code? AMD IOMMU currently also violates this
> >>requirement. I will send a patch to fix that there too.
> >>    
> >
> >  
> 
> Joerg,  yes I can see misbehavior caused by this code.  O/w I wouldn't 
> be spending my time fixing it :) :)
> 
> See below ....
> 
> >IIRC, only PARISC and POWER IOMMUs follow the above rule. So I also
> >wondered what problem he hit.
> >  
> 
> I wonder if IBM's Calgary IOMMU needs this fix? ... I've added Ed 
> Pollard to find out.
> 
> On big memory footprint (16G or above) systems it is possible that the 
> e820 map reserves most of the lower 4G of memory for system use*.  So 
> it's possible that the 4G region is almost completely reserved at boot 
> time and so the kernel starts using the IOMMU for DMA (see 
> dma_alloc_coherent()).  The addresses returned are not properly aligned, 
> and this causes serious problems for some drivers that require a 
> physical aligned address for the device.

Do you have a list of driver which require this? I would like to
reproduce this issue. Does it also happen when you start the kernel with
iommu=force (GART should then be used for all DMA remapping) too?

Joerg

Re: [PATCH]: PCI: GART iommu alignment fixes [v2]

[Prarit Bhargava]

Joerg Roedel wrote:
> On Wed, Jul 23, 2008 at 07:47:03PM -0400, Prarit Bhargava wrote:
>   
>>>> Interesting. Have you experienced any problems because of that
>>>> misbehavior in the GART code? AMD IOMMU currently also violates this
>>>> requirement. I will send a patch to fix that there too.
>>>>    
>>>>         
>>>  
>>>       
>> Joerg,  yes I can see misbehavior caused by this code.  O/w I wouldn't 
>> be spending my time fixing it :) :)
>>
>> See below ....
>>
>>     
>>> IIRC, only PARISC and POWER IOMMUs follow the above rule. So I also
>>> wondered what problem he hit.
>>>  
>>>       
>> I wonder if IBM's Calgary IOMMU needs this fix? ... I've added Ed 
>> Pollard to find out.
>>
>> On big memory footprint (16G or above) systems it is possible that the 
>> e820 map reserves most of the lower 4G of memory for system use*.  So 
>> it's possible that the 4G region is almost completely reserved at boot 
>> time and so the kernel starts using the IOMMU for DMA (see 
>> dma_alloc_coherent()).  The addresses returned are not properly aligned, 
>> and this causes serious problems for some drivers that require a 
>> physical aligned address for the device.
>>     
>
> Do you have a list of driver which require this? 

No, I don't have a list. :(

But it seems that the skge driver suffers from this because this code 
exists in the driver:

        skge->mem = pci_alloc_consistent(hw->pdev, skge->mem_size, 
&skge->dma);
        if (!skge->mem)
                return -ENOMEM;

        BUG_ON(skge->dma & 7);

        if ((u64)skge->dma >> 32 != ((u64) skge->dma + skge->mem_size) 
 >> 32) {
                printk(KERN_ERR PFX "pci_alloc_consistent region crosses 
4G boundary\n");
                err = -EINVAL;
                goto free_pci_mem;
        }


If pci_alloc_consistent did the "right" thing, we should *never* see 
that warning message.

In theory, any 32-bit device attempting to request larger than PAGE_SIZE 
DMA memory on a system where no memory is available below 4G should show 
this problem.

> I would like to
> reproduce this issue. Does it also happen when you start the kernel with
> iommu=force (GART should then be used for all DMA remapping) too?
>   

Yes, this happens if you specify iommu=force on the command line.

P.

Re: [PATCH]: PCI: GART iommu alignment fixes [v2]

[FUJITA Tomonori]

On Thu, 24 Jul 2008 06:09:31 -0400
Prarit Bhargava <prarit@redhat.com> wrote:

> 
> 
> Joerg Roedel wrote:
> > On Wed, Jul 23, 2008 at 07:47:03PM -0400, Prarit Bhargava wrote:
> >   
> >>>> Interesting. Have you experienced any problems because of that
> >>>> misbehavior in the GART code? AMD IOMMU currently also violates this
> >>>> requirement. I will send a patch to fix that there too.
> >>>>    
> >>>>         
> >>>  
> >>>       
> >> Joerg,  yes I can see misbehavior caused by this code.  O/w I wouldn't 
> >> be spending my time fixing it :) :)
> >>
> >> See below ....
> >>
> >>     
> >>> IIRC, only PARISC and POWER IOMMUs follow the above rule. So I also
> >>> wondered what problem he hit.
> >>>  
> >>>       
> >> I wonder if IBM's Calgary IOMMU needs this fix? ... I've added Ed 
> >> Pollard to find out.
> >>
> >> On big memory footprint (16G or above) systems it is possible that the 
> >> e820 map reserves most of the lower 4G of memory for system use*.  So 
> >> it's possible that the 4G region is almost completely reserved at boot 
> >> time and so the kernel starts using the IOMMU for DMA (see 
> >> dma_alloc_coherent()).  The addresses returned are not properly aligned, 
> >> and this causes serious problems for some drivers that require a 
> >> physical aligned address for the device.
> >>     
> >
> > Do you have a list of driver which require this? 
> 
> No, I don't have a list. :(
> 
> But it seems that the skge driver suffers from this because this code 
> exists in the driver:

seems? You hit the bug with this driver, right?


>         skge->mem = pci_alloc_consistent(hw->pdev, skge->mem_size, 
> &skge->dma);
>         if (!skge->mem)
>                 return -ENOMEM;
> 
>         BUG_ON(skge->dma & 7);
> 
>         if ((u64)skge->dma >> 32 != ((u64) skge->dma + skge->mem_size) 
>  >> 32) {
>                 printk(KERN_ERR PFX "pci_alloc_consistent region crosses 
> 4G boundary\n");
>                 err = -EINVAL;
>                 goto free_pci_mem;
>         }
> 
> 
> If pci_alloc_consistent did the "right" thing, we should *never* see 
> that warning message.

Well, I think that this is not releated with the pci_alloc_consistent
alignment problem that you talk about.

I think that the driver tries to avoid 4GB boundary crossing
problem. You can find some work to avoid this, for example:

http://www.ussg.iu.edu/hypermail/linux/kernel/0712.0/2206.html

pci_device_add() has the following code to avoid this:

pci_set_dma_seg_boundary(dev, 0xffffffff);

I suspect that the problem you talk about, alloc_consistent doesn't
return the reqeuested size aligned memory, breaks anything.


> In theory, any 32-bit device attempting to request larger than PAGE_SIZE 
> DMA memory on a system where no memory is available below 4G should show 
> this problem.
> 
> > I would like to
> > reproduce this issue. Does it also happen when you start the kernel with
> > iommu=force (GART should then be used for all DMA remapping) too?
> >   
> 
> Yes, this happens if you specify iommu=force on the command line.
> 
> P.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH]: PCI: GART iommu alignment fixes [v2]

[Joerg Roedel]

On Thu, Jul 24, 2008 at 07:34:35PM +0900, FUJITA Tomonori wrote:
> On Thu, 24 Jul 2008 06:09:31 -0400
> Prarit Bhargava <prarit@redhat.com> wrote:
> >         skge->mem = pci_alloc_consistent(hw->pdev, skge->mem_size, 
> > &skge->dma);
> >         if (!skge->mem)
> >                 return -ENOMEM;
> > 
> >         BUG_ON(skge->dma & 7);
> > 
> >         if ((u64)skge->dma >> 32 != ((u64) skge->dma + skge->mem_size) 
> >  >> 32) {
> >                 printk(KERN_ERR PFX "pci_alloc_consistent region crosses 
> > 4G boundary\n");
> >                 err = -EINVAL;
> >                 goto free_pci_mem;
> >         }
> > 
> > 
> > If pci_alloc_consistent did the "right" thing, we should *never* see 
> > that warning message.
> 
> Well, I think that this is not releated with the pci_alloc_consistent
> alignment problem that you talk about.
> 
> I think that the driver tries to avoid 4GB boundary crossing
> problem. You can find some work to avoid this, for example:
> 
> http://www.ussg.iu.edu/hypermail/linux/kernel/0712.0/2206.html
> 
> pci_device_add() has the following code to avoid this:
> 
> pci_set_dma_seg_boundary(dev, 0xffffffff);
> 
> I suspect that the problem you talk about, alloc_consistent doesn't
> return the reqeuested size aligned memory, breaks anything.

But I think Prarit is right with this change. If the interface defines
this behavior the IOMMU drivers have to implement it. I am just
wondering that the problem never showed up before. The GART driver is a
few years old now.

Joerg

Re: [PATCH]: PCI: GART iommu alignment fixes [v2]

[Prarit Bhargava]

> But I think Prarit is right with this change. If the interface defines
> this behavior the IOMMU drivers have to implement it. I am just
> wondering that the problem never showed up before. The GART driver is a
> few years old now.
>
>   

Joerg -- there's an easy explanation for this.  This will only happen 
when a 32-bit device requests DMA memory and all memory below 4G is 
used.  Just doing a quick overview of a few systems, allocated DMA 
memory is usually less than 512M of the system memory so it is unlikely 
a system hits the 4G limit.

In addition to that most systems do not reserve all or most of the lower 
4G in the e820 maps.  Those that do are usually larger systems.

ie) The only reason we're seeing this now is because large memory 
footprint systems are coming online -- IMO ;)

P.

Re: [PATCH]: PCI: GART iommu alignment fixes [v2]

[FUJITA Tomonori]

On Thu, 24 Jul 2008 14:37:55 +0200
Joerg Roedel <joro@8bytes.org> wrote:

> On Thu, Jul 24, 2008 at 07:34:35PM +0900, FUJITA Tomonori wrote:
> > On Thu, 24 Jul 2008 06:09:31 -0400
> > Prarit Bhargava <prarit@redhat.com> wrote:
> > >         skge->mem = pci_alloc_consistent(hw->pdev, skge->mem_size, 
> > > &skge->dma);
> > >         if (!skge->mem)
> > >                 return -ENOMEM;
> > > 
> > >         BUG_ON(skge->dma & 7);
> > > 
> > >         if ((u64)skge->dma >> 32 != ((u64) skge->dma + skge->mem_size) 
> > >  >> 32) {
> > >                 printk(KERN_ERR PFX "pci_alloc_consistent region crosses 
> > > 4G boundary\n");
> > >                 err = -EINVAL;
> > >                 goto free_pci_mem;
> > >         }
> > > 
> > > 
> > > If pci_alloc_consistent did the "right" thing, we should *never* see 
> > > that warning message.
> > 
> > Well, I think that this is not releated with the pci_alloc_consistent
> > alignment problem that you talk about.
> > 
> > I think that the driver tries to avoid 4GB boundary crossing
> > problem. You can find some work to avoid this, for example:
> > 
> > http://www.ussg.iu.edu/hypermail/linux/kernel/0712.0/2206.html
> > 
> > pci_device_add() has the following code to avoid this:
> > 
> > pci_set_dma_seg_boundary(dev, 0xffffffff);
> > 
> > I suspect that the problem you talk about, alloc_consistent doesn't
> > return the reqeuested size aligned memory, breaks anything.
> 
> But I think Prarit is right with this change. If the interface defines
> this behavior the IOMMU drivers have to implement it. I am just
> wondering that the problem never showed up before. The GART driver is a
> few years old now.

Yeah, I'm not against fixing IOMMUs to make alloc_consistent return
the reqeuested size aligned memory. My point is that it's not likely
to fix anything. Even with the patch, we hit the above problem because
as I explained, the root cause of the problem is the boundary issue;
we need to fix pci-dma.c

Re: [PATCH]: PCI: GART iommu alignment fixes [v2]

[Prarit Bhargava]

>> But I think Prarit is right with this change. If the interface defines
>> this behavior the IOMMU drivers have to implement it. I am just
>> wondering that the problem never showed up before. The GART driver is a
>> few years old now.
>>     
>
> Yeah, I'm not against fixing IOMMUs to make alloc_consistent return
> the reqeuested size aligned memory. My point is that it's not likely
> to fix anything. Even with the patch, we hit the above problem because
> as I explained, the root cause of the problem is the boundary issue;
> we need to fix pci-dma.c
>
>   

Sorry, I misquoted code up there and was looking for a clear example of 
where this would happen.  The issue I'm trying to resolve didn't happen 
on the skge -- it was just a convenient piece of code to examine and 
point out ;)

P.

Re: [PATCH]: PCI: GART iommu alignment fixes [v2]

[FUJITA Tomonori]

On Thu, 24 Jul 2008 10:31:58 -0400
Prarit Bhargava <prarit@redhat.com> wrote:

> 
> >> But I think Prarit is right with this change. If the interface defines
> >> this behavior the IOMMU drivers have to implement it. I am just
> >> wondering that the problem never showed up before. The GART driver is a
> >> few years old now.
> >>     
> >
> > Yeah, I'm not against fixing IOMMUs to make alloc_consistent return
> > the reqeuested size aligned memory. My point is that it's not likely
> > to fix anything. Even with the patch, we hit the above problem because
> > as I explained, the root cause of the problem is the boundary issue;
> > we need to fix pci-dma.c
> >
> >   
> 
> Sorry, I misquoted code up there and was looking for a clear example of 
> where this would happen.  The issue I'm trying to resolve didn't happen 
> on the skge -- it was just a convenient piece of code to examine and 
> point out ;)

So please tell us what driver you hit the bug with. Can you give us
the details?

Thanks,

Re: [PATCH]: PCI: GART iommu alignment fixes [v2]

[Prarit Bhargava]

> So please tell us what driver you hit the bug with. Can you give us
> the details?
>
>   

Sorry Fujita,  I had to re-install and reboot the system to get those 
details.

The cciss driver is the one that really went haywire for me on the large 
system.

It does two greater than PAGE_SIZE pci_alloc_consistent() calls -- one 
with 0x3a800 and the other with 0x4800.  Both calls seem to complete but 
my cciss was completely hosed.  I couldn't access it at all :(

The tg3 (which alloc's 0x8000 and 0x4000) actually worked but the 
network wasn't working very well.

P.

> Thanks,
>   

Re: [PATCH]: PCI: GART iommu alignment fixes [v2]

[Prarit Bhargava]

>>>  
>>
>> Yeah, I'm not against fixing IOMMUs to make alloc_consistent return
>> the reqeuested size aligned memory. My point is that it's not likely
>> to fix anything. Even with the patch, we hit the above problem because
>> as I explained, the root cause of the problem is the boundary issue;
>> we need to fix pci-dma.c
>>
>>   
>
> Sorry, I misquoted code up there and was looking for a clear example 
> of where this would happen.  The issue I'm trying to resolve didn't 
> happen on the skge -- it was just a convenient piece of code to 
> examine and point out ;)
>

Here's a case where USB has problems:

 BIOS-e820: 0000000000000000 - 000000000009f400 (usable)
 BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 00000000f57f6800 (reserved)
 BIOS-e820: 00000000f57f6800 - 00000000f5800000 (ACPI data)
 BIOS-e820: 00000000f5800000 - 00000000fdc00000 (reserved)
 BIOS-e820: 00000000fdc00000 - 00000000fdc01000 (reserved)
 BIOS-e820: 00000000fdc10000 - 00000000fdc01000 (reserved)
 BIOS-e820: 00000000fdc20000 - 00000000fdc01000 (reserved)
 BIOS-e820: 00000000fdc30000 - 00000000fdc01000 (reserved)
 BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
 BIOS-e820: 00000000fec10000 - 00000000fec20000 (reserved)
 BIOS-e820: 00000000fec20000 - 00000000fec30000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee10000 (reserved)
 BIOS-e820: 00000000fee10000 - 00000000ff800000 (reserved)
 BIOS-e820: 00000000ff800000 - 0000000100000000 (reserved)
 BIOS-e820: 0000000100000000 - 00000017fffff000 (usable)

I haven't tracked down what pci_alloc_consistent went wrong in 
usb-storage yet ... it seemed irrelevant because GART was broken.

P.

Re: [PATCH]: PCI: GART iommu alignment fixes [v2]

[Jesse Barnes]

On Wednesday, July 23, 2008 4:14 pm FUJITA Tomonori wrote:
> On Thu, 24 Jul 2008 00:10:33 +0200
>
> Joerg Roedel <joro@8bytes.org> wrote:
> > On Wed, Jul 23, 2008 at 07:19:43AM -0400, Prarit Bhargava wrote:
> > > pci_alloc_consistent/dma_alloc_coherent does not return size aligned
> > > addresses.
> > >
> > > >From Documentation/DMA-mapping.txt:
> > >
> > > "pci_alloc_consistent returns two values: the virtual address which you
> > > can use to access it from the CPU and dma_handle which you pass to the
> > > card.
> > >
> > > The cpu return address and the DMA bus master address are both
> > > guaranteed to be aligned to the smallest PAGE_SIZE order which
> > > is greater than or equal to the requested size.  This invariant
> > > exists (for example) to guarantee that if you allocate a chunk
> > > which is smaller than or equal to 64 kilobytes, the extent of the
> > > buffer you receive will not cross a 64K boundary."
> >
> > Interesting. Have you experienced any problems because of that
> > misbehavior in the GART code? AMD IOMMU currently also violates this
> > requirement. I will send a patch to fix that there too.
>
> IIRC, only PARISC and POWER IOMMUs follow the above rule. So I also
> wondered what problem he hit.

Prarit, what's the latest here?  The v3 patch I have from you doesn't apply to 
my tree but it looks like a good fix.  Care to send me a new patch against my 
for-linus branch?

Thanks,
Jesse

Re: [PATCH]: PCI: GART iommu alignment fixes [v2]

[Prarit Bhargava]

[-- Attachment #1: Type: text/plain, Size: 207 bytes --]


>
> Prarit, what's the latest here?  The v3 patch I have from you doesn't apply to 
> my tree but it looks like a good fix.  Care to send me a new patch against my 
> for-linus branch?
>
>   

New patch.



[-- Attachment #2: upstream3.patch --]
[-- Type: text/plain, Size: 4534 bytes --]

pci_alloc_consistent/dma_alloc_coherent does not return size aligned
addresses.

>From Documentation/DMA-mapping.txt:

"pci_alloc_consistent returns two values: the virtual address which you
can use to access it from the CPU and dma_handle which you pass to the
card.

The cpu return address and the DMA bus master address are both
guaranteed to be aligned to the smallest PAGE_SIZE order which
is greater than or equal to the requested size.  This invariant
exists (for example) to guarantee that if you allocate a chunk
which is smaller than or equal to 64 kilobytes, the extent of the
buffer you receive will not cross a 64K boundary."

1.  Modify alloc_iommu to allow for an alignment mask
2.  Modify pci_gart_simple to return size-aligned values.
3.  Fix possible overflow in alloc_iommu's boundary_size calculation.
    (It is possible that alloc_iommu()'s boundary_size overflows as
     dma_get_seg_boundary can return 0xffffffff.  In that case, further usage of
     boundary_size triggers a BUG_ON() in the iommu code.)

End result: When allocating from IOMMU, pci_alloc_consistent/dma_alloc_coherent
will now return a size aligned value.

Signed-off-by: Prarit Bhargava <prarit@redhat.com>

diff --git a/arch/x86/kernel/pci-gart_64.c b/arch/x86/kernel/pci-gart_64.c
index 744126e..d3eb527 100644
--- a/arch/x86/kernel/pci-gart_64.c
+++ b/arch/x86/kernel/pci-gart_64.c
@@ -85,7 +85,8 @@ AGPEXTERN __u32 *agp_gatt_table;
 static unsigned long next_bit;  /* protected by iommu_bitmap_lock */
 static int need_flush;		/* global flush state. set for each gart wrap */
 
-static unsigned long alloc_iommu(struct device *dev, int size)
+static unsigned long alloc_iommu(struct device *dev, int size,
+				 unsigned long mask)
 {
 	unsigned long offset, flags;
 	unsigned long boundary_size;
@@ -93,16 +94,17 @@ static unsigned long alloc_iommu(struct device *dev, int size)
 
 	base_index = ALIGN(iommu_bus_base & dma_get_seg_boundary(dev),
 			   PAGE_SIZE) >> PAGE_SHIFT;
-	boundary_size = ALIGN(dma_get_seg_boundary(dev) + 1,
+	boundary_size = ALIGN((unsigned long long)dma_get_seg_boundary(dev) + 1,
 			      PAGE_SIZE) >> PAGE_SHIFT;
 
 	spin_lock_irqsave(&iommu_bitmap_lock, flags);
 	offset = iommu_area_alloc(iommu_gart_bitmap, iommu_pages, next_bit,
-				  size, base_index, boundary_size, 0);
+				  size, base_index, boundary_size, mask);
 	if (offset == -1) {
 		need_flush = 1;
 		offset = iommu_area_alloc(iommu_gart_bitmap, iommu_pages, 0,
-					  size, base_index, boundary_size, 0);
+					  size, base_index, boundary_size,
+					  mask);
 	}
 	if (offset != -1) {
 		next_bit = offset+size;
@@ -239,10 +241,11 @@ nonforced_iommu(struct device *dev, unsigned long addr, size_t size)
  * Caller needs to check if the iommu is needed and flush.
  */
 static dma_addr_t dma_map_area(struct device *dev, dma_addr_t phys_mem,
-				size_t size, int dir)
+				size_t size, int dir, u64 align_mask)
 {
 	unsigned long npages = to_pages(phys_mem, size);
-	unsigned long iommu_page = alloc_iommu(dev, npages);
+	unsigned long palign_mask = align_mask >> PAGE_SHIFT;
+	unsigned long iommu_page = alloc_iommu(dev, npages, palign_mask);
 	int i;
 
 	if (iommu_page == -1) {
@@ -265,7 +268,7 @@ static dma_addr_t dma_map_area(struct device *dev, dma_addr_t phys_mem,
 static dma_addr_t
 gart_map_simple(struct device *dev, phys_addr_t paddr, size_t size, int dir)
 {
-	dma_addr_t map = dma_map_area(dev, paddr, size, dir);
+	dma_addr_t map = dma_map_area(dev, paddr, size, dir, size - 1);
 
 	flush_gart();
 
@@ -284,7 +287,8 @@ gart_map_single(struct device *dev, phys_addr_t paddr, size_t size, int dir)
 	if (!need_iommu(dev, paddr, size))
 		return paddr;
 
-	bus = gart_map_simple(dev, paddr, size, dir);
+	bus = dma_map_area(dev, paddr, size, dir, 0);
+	flush_gart();
 
 	return bus;
 }
@@ -343,7 +347,7 @@ static int dma_map_sg_nonforce(struct device *dev, struct scatterlist *sg,
 		unsigned long addr = sg_phys(s);
 
 		if (nonforced_iommu(dev, addr, s->length)) {
-			addr = dma_map_area(dev, addr, s->length, dir);
+			addr = dma_map_area(dev, addr, s->length, dir, 0);
 			if (addr == bad_dma_address) {
 				if (i > 0)
 					gart_unmap_sg(dev, sg, i, dir);
@@ -365,7 +369,7 @@ static int __dma_map_cont(struct device *dev, struct scatterlist *start,
 			  int nelems, struct scatterlist *sout,
 			  unsigned long pages)
 {
-	unsigned long iommu_start = alloc_iommu(dev, pages);
+	unsigned long iommu_start = alloc_iommu(dev, pages, 0);
 	unsigned long iommu_page = iommu_start;
 	struct scatterlist *s;
 	int i;

Re: [PATCH]: PCI: GART iommu alignment fixes [v2]

[Jesse Barnes]

On Tuesday, July 29, 2008 7:24 am Prarit Bhargava wrote:
> > Prarit, what's the latest here?  The v3 patch I have from you doesn't
> > apply to my tree but it looks like a good fix.  Care to send me a new
> > patch against my for-linus branch?
>
> New patch.

Thanks Prarit, I pushed this out to my for-linus branch.

Jesse

Re: [PATCH]: PCI: GART iommu alignment fixes [v2]

[FUJITA Tomonori]

On Mon, 28 Jul 2008 15:23:35 -0700
Jesse Barnes <jbarnes@virtuousgeek.org> wrote:

> On Wednesday, July 23, 2008 4:14 pm FUJITA Tomonori wrote:
> > On Thu, 24 Jul 2008 00:10:33 +0200
> >
> > Joerg Roedel <joro@8bytes.org> wrote:
> > > On Wed, Jul 23, 2008 at 07:19:43AM -0400, Prarit Bhargava wrote:
> > > > pci_alloc_consistent/dma_alloc_coherent does not return size aligned
> > > > addresses.
> > > >
> > > > >From Documentation/DMA-mapping.txt:
> > > >
> > > > "pci_alloc_consistent returns two values: the virtual address which you
> > > > can use to access it from the CPU and dma_handle which you pass to the
> > > > card.
> > > >
> > > > The cpu return address and the DMA bus master address are both
> > > > guaranteed to be aligned to the smallest PAGE_SIZE order which
> > > > is greater than or equal to the requested size.  This invariant
> > > > exists (for example) to guarantee that if you allocate a chunk
> > > > which is smaller than or equal to 64 kilobytes, the extent of the
> > > > buffer you receive will not cross a 64K boundary."
> > >
> > > Interesting. Have you experienced any problems because of that
> > > misbehavior in the GART code? AMD IOMMU currently also violates this
> > > requirement. I will send a patch to fix that there too.
> >
> > IIRC, only PARISC and POWER IOMMUs follow the above rule. So I also
> > wondered what problem he hit.
> 
> Prarit, what's the latest here?  The v3 patch I have from you doesn't apply to 
> my tree but it looks like a good fix.  Care to send me a new patch against my 
> for-linus branch?

I'm not sure how the following cast to 'unsigned long long' fixes
something on X86_64.

> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
> 
> diff --git a/arch/x86/kernel/pci-gart_64.c b/arch/x86/kernel/pci-gart_64.c
> index 744126e..d3eb527 100644
> --- a/arch/x86/kernel/pci-gart_64.c
> +++ b/arch/x86/kernel/pci-gart_64.c
> @@ -85,7 +85,8 @@ AGPEXTERN __u32 *agp_gatt_table;
>  static unsigned long next_bit;  /* protected by iommu_bitmap_lock */
>  static int need_flush;		/* global flush state. set for each gart wrap */
>  
> -static unsigned long alloc_iommu(struct device *dev, int size)
> +static unsigned long alloc_iommu(struct device *dev, int size,
> +				 unsigned long mask)
>  {
>  	unsigned long offset, flags;
>  	unsigned long boundary_size;
> @@ -93,16 +94,17 @@ static unsigned long alloc_iommu(struct device *dev, int size)
>  
>  	base_index = ALIGN(iommu_bus_base & dma_get_seg_boundary(dev),
>  			   PAGE_SIZE) >> PAGE_SHIFT;
> -	boundary_size = ALIGN(dma_get_seg_boundary(dev) + 1,
> +	boundary_size = ALIGN((unsigned long long)dma_get_seg_boundary(dev) + 1,
>  			      PAGE_SIZE) >> PAGE_SHIFT;

I don't think that the following code works since the size is not
always a power of 2.


> @@ -265,7 +268,7 @@ static dma_addr_t dma_map_area(struct device *dev, dma_addr_t phys_mem,
>  static dma_addr_t
>  gart_map_simple(struct device *dev, phys_addr_t paddr, size_t size, int dir)
>  {
> -	dma_addr_t map = dma_map_area(dev, paddr, size, dir);
> +	dma_addr_t map = dma_map_area(dev, paddr, size, dir, size - 1);

Re: [PATCH]: PCI: GART iommu alignment fixes [v2]

[Prarit Bhargava]

FUJITA Tomonori wrote:
> On Mon, 28 Jul 2008 15:23:35 -0700
> Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
>
>   
>> On Wednesday, July 23, 2008 4:14 pm FUJITA Tomonori wrote:
>>     
>>> On Thu, 24 Jul 2008 00:10:33 +0200
>>>
>>> Joerg Roedel <joro@8bytes.org> wrote:
>>>       
>>>> On Wed, Jul 23, 2008 at 07:19:43AM -0400, Prarit Bhargava wrote:
>>>>         
>>>>> pci_alloc_consistent/dma_alloc_coherent does not return size aligned
>>>>> addresses.
>>>>>
>>>>> >From Documentation/DMA-mapping.txt:
>>>>>
>>>>> "pci_alloc_consistent returns two values: the virtual address which you
>>>>> can use to access it from the CPU and dma_handle which you pass to the
>>>>> card.
>>>>>
>>>>> The cpu return address and the DMA bus master address are both
>>>>> guaranteed to be aligned to the smallest PAGE_SIZE order which
>>>>> is greater than or equal to the requested size.  This invariant
>>>>> exists (for example) to guarantee that if you allocate a chunk
>>>>> which is smaller than or equal to 64 kilobytes, the extent of the
>>>>> buffer you receive will not cross a 64K boundary."
>>>>>           
>>>> Interesting. Have you experienced any problems because of that
>>>> misbehavior in the GART code? AMD IOMMU currently also violates this
>>>> requirement. I will send a patch to fix that there too.
>>>>         
>>> IIRC, only PARISC and POWER IOMMUs follow the above rule. So I also
>>> wondered what problem he hit.
>>>       
>> Prarit, what's the latest here?  The v3 patch I have from you doesn't apply to 
>> my tree but it looks like a good fix.  Care to send me a new patch against my 
>> for-linus branch?
>>     
>
> I'm not sure how the following cast to 'unsigned long long' fixes
> something on X86_64.
>
>   

You can write a very simple module that kmalloc's a pci_dev, sets up 
some trivial values for the dev, and then calls pci_alloc_consistent.  
You will panic 100% of the time because  'dma_get_seg_boundary(dev) + 1' 
overflows an unsigned long.

>> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
>>
>> diff --git a/arch/x86/kernel/pci-gart_64.c b/arch/x86/kernel/pci-gart_64.c
>> index 744126e..d3eb527 100644
>> --- a/arch/x86/kernel/pci-gart_64.c
>> +++ b/arch/x86/kernel/pci-gart_64.c
>> @@ -85,7 +85,8 @@ AGPEXTERN __u32 *agp_gatt_table;
>>  static unsigned long next_bit;  /* protected by iommu_bitmap_lock */
>>  static int need_flush;		/* global flush state. set for each gart wrap */
>>  
>> -static unsigned long alloc_iommu(struct device *dev, int size)
>> +static unsigned long alloc_iommu(struct device *dev, int size,
>> +				 unsigned long mask)
>>  {
>>  	unsigned long offset, flags;
>>  	unsigned long boundary_size;
>> @@ -93,16 +94,17 @@ static unsigned long alloc_iommu(struct device *dev, int size)
>>  
>>  	base_index = ALIGN(iommu_bus_base & dma_get_seg_boundary(dev),
>>  			   PAGE_SIZE) >> PAGE_SHIFT;
>> -	boundary_size = ALIGN(dma_get_seg_boundary(dev) + 1,
>> +	boundary_size = ALIGN((unsigned long long)dma_get_seg_boundary(dev) + 1,
>>  			      PAGE_SIZE) >> PAGE_SHIFT;
>>     
>
> I don't think that the following code works since the size is not
> always a power of 2.
>   



>
>   
>> @@ -265,7 +268,7 @@ static dma_addr_t dma_map_area(struct device *dev, dma_addr_t phys_mem,
>>  static dma_addr_t
>>  gart_map_simple(struct device *dev, phys_addr_t paddr, size_t size, int dir)
>>  {
>> -	dma_addr_t map = dma_map_area(dev, paddr, size, dir);
>> +	dma_addr_t map = dma_map_area(dev, paddr, size, dir, size - 1);
>>     

Maybe I'm missing something -- what implies  size has to be a power of two?

P.

Re: [PATCH]: PCI: GART iommu alignment fixes [v2]

[Prarit Bhargava]

>>
>>  
>>> @@ -265,7 +268,7 @@ static dma_addr_t dma_map_area(struct device 
>>> *dev, dma_addr_t phys_mem,
>>>  static dma_addr_t
>>>  gart_map_simple(struct device *dev, phys_addr_t paddr, size_t size, 
>>> int dir)
>>>  {
>>> -    dma_addr_t map = dma_map_area(dev, paddr, size, dir);
>>> +    dma_addr_t map = dma_map_area(dev, paddr, size, dir, size - 1);
>>>     
>
> Maybe I'm missing something -- what implies  size has to be a power of 
> two?
>
> P.
>

Ixnay that last comment -- I geddit (duh.).

The implication of "size-1" is that size is always a power of two.

Jesse -- I'll have to post a follow-up patch to fix this.

P.

Re: [PATCH]: PCI: GART iommu alignment fixes [v2]

[FUJITA Tomonori]

On Wed, 06 Aug 2008 08:29:49 -0400
Prarit Bhargava <prarit@redhat.com> wrote:

> 
> 
> FUJITA Tomonori wrote:
> > On Mon, 28 Jul 2008 15:23:35 -0700
> > Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> >
> >   
> >> On Wednesday, July 23, 2008 4:14 pm FUJITA Tomonori wrote:
> >>     
> >>> On Thu, 24 Jul 2008 00:10:33 +0200
> >>>
> >>> Joerg Roedel <joro@8bytes.org> wrote:
> >>>       
> >>>> On Wed, Jul 23, 2008 at 07:19:43AM -0400, Prarit Bhargava wrote:
> >>>>         
> >>>>> pci_alloc_consistent/dma_alloc_coherent does not return size aligned
> >>>>> addresses.
> >>>>>
> >>>>> >From Documentation/DMA-mapping.txt:
> >>>>>
> >>>>> "pci_alloc_consistent returns two values: the virtual address which you
> >>>>> can use to access it from the CPU and dma_handle which you pass to the
> >>>>> card.
> >>>>>
> >>>>> The cpu return address and the DMA bus master address are both
> >>>>> guaranteed to be aligned to the smallest PAGE_SIZE order which
> >>>>> is greater than or equal to the requested size.  This invariant
> >>>>> exists (for example) to guarantee that if you allocate a chunk
> >>>>> which is smaller than or equal to 64 kilobytes, the extent of the
> >>>>> buffer you receive will not cross a 64K boundary."
> >>>>>           
> >>>> Interesting. Have you experienced any problems because of that
> >>>> misbehavior in the GART code? AMD IOMMU currently also violates this
> >>>> requirement. I will send a patch to fix that there too.
> >>>>         
> >>> IIRC, only PARISC and POWER IOMMUs follow the above rule. So I also
> >>> wondered what problem he hit.
> >>>       
> >> Prarit, what's the latest here?  The v3 patch I have from you doesn't apply to 
> >> my tree but it looks like a good fix.  Care to send me a new patch against my 
> >> for-linus branch?
> >>     
> >
> > I'm not sure how the following cast to 'unsigned long long' fixes
> > something on X86_64.
> >
> >   
> 
> You can write a very simple module that kmalloc's a pci_dev, sets up 
> some trivial values for the dev, and then calls pci_alloc_consistent.  
> You will panic 100% of the time because  'dma_get_seg_boundary(dev) + 1' 
> overflows an unsigned long.

You can't kmalloc pci_dev or setup some trivial values. You need to
use a proper value. The pci code does for us.

Calgary IOMMU has the same code. New AMD IOMMU has the same code too.


> >> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
> >>
> >> diff --git a/arch/x86/kernel/pci-gart_64.c b/arch/x86/kernel/pci-gart_64.c
> >> index 744126e..d3eb527 100644
> >> --- a/arch/x86/kernel/pci-gart_64.c
> >> +++ b/arch/x86/kernel/pci-gart_64.c
> >> @@ -85,7 +85,8 @@ AGPEXTERN __u32 *agp_gatt_table;
> >>  static unsigned long next_bit;  /* protected by iommu_bitmap_lock */
> >>  static int need_flush;		/* global flush state. set for each gart wrap */
> >>  
> >> -static unsigned long alloc_iommu(struct device *dev, int size)
> >> +static unsigned long alloc_iommu(struct device *dev, int size,
> >> +				 unsigned long mask)
> >>  {
> >>  	unsigned long offset, flags;
> >>  	unsigned long boundary_size;
> >> @@ -93,16 +94,17 @@ static unsigned long alloc_iommu(struct device *dev, int size)
> >>  
> >>  	base_index = ALIGN(iommu_bus_base & dma_get_seg_boundary(dev),
> >>  			   PAGE_SIZE) >> PAGE_SHIFT;
> >> -	boundary_size = ALIGN(dma_get_seg_boundary(dev) + 1,
> >> +	boundary_size = ALIGN((unsigned long long)dma_get_seg_boundary(dev) + 1,
> >>  			      PAGE_SIZE) >> PAGE_SHIFT;
> >>     
> >
> > I don't think that the following code works since the size is not
> > always a power of 2.
> >   
> 
> 
> 
> >
> >   
> >> @@ -265,7 +268,7 @@ static dma_addr_t dma_map_area(struct device *dev, dma_addr_t phys_mem,
> >>  static dma_addr_t
> >>  gart_map_simple(struct device *dev, phys_addr_t paddr, size_t size, int dir)
> >>  {
> >> -	dma_addr_t map = dma_map_area(dev, paddr, size, dir);
> >> +	dma_addr_t map = dma_map_area(dev, paddr, size, dir, size - 1);
> >>     
> 
> Maybe I'm missing something -- what implies  size has to be a power of two?

Yes, see iommu_area_alloc().

Re: [PATCH]: PCI: GART iommu alignment fixes [v2]

[Prarit Bhargava]

FUJITA Tomonori wrote:
> On Wed, 06 Aug 2008 08:29:49 -0400
> Prarit Bhargava <prarit@redhat.com> wrote:
>
>   
>> FUJITA Tomonori wrote:
>>     
>>> On Mon, 28 Jul 2008 15:23:35 -0700
>>> Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
>>>
>>>   
>>>       
>>>> On Wednesday, July 23, 2008 4:14 pm FUJITA Tomonori wrote:
>>>>     
>>>>         
>>>>> On Thu, 24 Jul 2008 00:10:33 +0200
>>>>>
>>>>> Joerg Roedel <joro@8bytes.org> wrote:
>>>>>       
>>>>>           
>>>>>> On Wed, Jul 23, 2008 at 07:19:43AM -0400, Prarit Bhargava wrote:
>>>>>>         
>>>>>>             
>>>>>>> pci_alloc_consistent/dma_alloc_coherent does not return size aligned
>>>>>>> addresses.
>>>>>>>
>>>>>>> >From Documentation/DMA-mapping.txt:
>>>>>>>
>>>>>>> "pci_alloc_consistent returns two values: the virtual address which you
>>>>>>> can use to access it from the CPU and dma_handle which you pass to the
>>>>>>> card.
>>>>>>>
>>>>>>> The cpu return address and the DMA bus master address are both
>>>>>>> guaranteed to be aligned to the smallest PAGE_SIZE order which
>>>>>>> is greater than or equal to the requested size.  This invariant
>>>>>>> exists (for example) to guarantee that if you allocate a chunk
>>>>>>> which is smaller than or equal to 64 kilobytes, the extent of the
>>>>>>> buffer you receive will not cross a 64K boundary."
>>>>>>>           
>>>>>>>               
>>>>>> Interesting. Have you experienced any problems because of that
>>>>>> misbehavior in the GART code? AMD IOMMU currently also violates this
>>>>>> requirement. I will send a patch to fix that there too.
>>>>>>         
>>>>>>             
>>>>> IIRC, only PARISC and POWER IOMMUs follow the above rule. So I also
>>>>> wondered what problem he hit.
>>>>>       
>>>>>           
>>>> Prarit, what's the latest here?  The v3 patch I have from you doesn't apply to 
>>>> my tree but it looks like a good fix.  Care to send me a new patch against my 
>>>> for-linus branch?
>>>>     
>>>>         
>>> I'm not sure how the following cast to 'unsigned long long' fixes
>>> something on X86_64.
>>>
>>>   
>>>       
>> You can write a very simple module that kmalloc's a pci_dev, sets up 
>> some trivial values for the dev, and then calls pci_alloc_consistent.  
>> You will panic 100% of the time because  'dma_get_seg_boundary(dev) + 1' 
>> overflows an unsigned long.
>>     
>
> You can't kmalloc pci_dev or setup some trivial values. You need to
> use a proper value. The pci code does for us.
>   

Oops -- I meant struct device, not struct pci_dev.

Anwyay, Jesse -- is this true?  I can no longer do something like:


static struct device junk_dev = {
        .bus_id = "junk device",
        .coherent_dma_mask = 0xffffffff,
        .dma_mask = &junk_dev.coherent_dma_mask,
};

And then use that as the device target for dma_alloc_coherent?  AFAIK, 
that has always worked for me.

Anyhoo -- it is possible that dma_get_seg_boundary returns 0xffffffff.  
Add one to that.  You overflow.

> Calgary IOMMU has the same code. New AMD IOMMU has the same code too.
>
>   

Then they don't handle the above problem and are broken when 
dma_get_seg_boundary() returns 0xffffffff and will require patches.

/me hasn't tried out Calgary of AMD IOMMU.

>   
>>>> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
>>>>
>>>> diff --git a/arch/x86/kernel/pci-gart_64.c b/arch/x86/kernel/pci-gart_64.c
>>>> index 744126e..d3eb527 100644
>>>> --- a/arch/x86/kernel/pci-gart_64.c
>>>> +++ b/arch/x86/kernel/pci-gart_64.c
>>>> @@ -85,7 +85,8 @@ AGPEXTERN __u32 *agp_gatt_table;
>>>>  static unsigned long next_bit;  /* protected by iommu_bitmap_lock */
>>>>  static int need_flush;		/* global flush state. set for each gart wrap */
>>>>  
>>>> -static unsigned long alloc_iommu(struct device *dev, int size)
>>>> +static unsigned long alloc_iommu(struct device *dev, int size,
>>>> +				 unsigned long mask)
>>>>  {
>>>>  	unsigned long offset, flags;
>>>>  	unsigned long boundary_size;
>>>> @@ -93,16 +94,17 @@ static unsigned long alloc_iommu(struct device *dev, int size)
>>>>  
>>>>  	base_index = ALIGN(iommu_bus_base & dma_get_seg_boundary(dev),
>>>>  			   PAGE_SIZE) >> PAGE_SHIFT;
>>>> -	boundary_size = ALIGN(dma_get_seg_boundary(dev) + 1,
>>>> +	boundary_size = ALIGN((unsigned long long)dma_get_seg_boundary(dev) + 1,
>>>>  			      PAGE_SIZE) >> PAGE_SHIFT;
>>>>     
>>>>         
>>> I don't think that the following code works since the size is not
>>> always a power of 2.
>>>   
>>>       
>>
>>     
>>>   
>>>       
>>>> @@ -265,7 +268,7 @@ static dma_addr_t dma_map_area(struct device *dev, dma_addr_t phys_mem,
>>>>  static dma_addr_t
>>>>  gart_map_simple(struct device *dev, phys_addr_t paddr, size_t size, int dir)
>>>>  {
>>>> -	dma_addr_t map = dma_map_area(dev, paddr, size, dir);
>>>> +	dma_addr_t map = dma_map_area(dev, paddr, size, dir, size - 1);
>>>>     
>>>>         
>> Maybe I'm missing something -- what implies  size has to be a power of two?
>>     
>
> Yes, see iommu_area_alloc().
>   

/me looks and still doesn't see where the size passed into 
gart_map_simple() must be a power of two.  ... and if that was the case, 
shouldn't we be failing all the time?  I mean, I've seen values passed 
into pci_alloc_consistent like 0x3820 -- clearly not a multiple of 2.

iommu_area_alloc() deals with pages, not actual sizes as 
gart_map_simple() does.

If anything, I would make this simple fix:

dma_addr_t map = dma_map_area(dev, paddr, size, dir, size - 1);

should be

dma_addr_t map = dma_map_area(dev, paddr, size, dir, size);

because after my patch we round up the mask argument to get the correct 
alignment to # of pages anyway.

P.
 

Re: [PATCH]: PCI: GART iommu alignment fixes [v2]

[Jesse Barnes]

On Wednesday, August 6, 2008 7:32 am Prarit Bhargava wrote:
> > You can't kmalloc pci_dev or setup some trivial values. You need to
> > use a proper value. The pci code does for us.
>
> Oops -- I meant struct device, not struct pci_dev.
>
> Anwyay, Jesse -- is this true?  I can no longer do something like:
>
>
> static struct device junk_dev = {
>         .bus_id = "junk device",
>         .coherent_dma_mask = 0xffffffff,
>         .dma_mask = &junk_dev.coherent_dma_mask,
> };
>
> And then use that as the device target for dma_alloc_coherent?  AFAIK,
> that has always worked for me.

It gets dangerous since platforms are in control of some pci_dev and dev 
fields, and if they don't get initialized you can get into trouble.

> > Calgary IOMMU has the same code. New AMD IOMMU has the same code too.
>
> Then they don't handle the above problem and are broken when
> dma_get_seg_boundary() returns 0xffffffff and will require patches.
>
> /me hasn't tried out Calgary of AMD IOMMU.

Would be good to find someone to do some testing on one of those platforms...

> >> Maybe I'm missing something -- what implies  size has to be a power of
> >> two?
> >
> > Yes, see iommu_area_alloc().
>
> /me looks and still doesn't see where the size passed into
> gart_map_simple() must be a power of two.  ... and if that was the case,
> shouldn't we be failing all the time?  I mean, I've seen values passed
> into pci_alloc_consistent like 0x3820 -- clearly not a multiple of 2.
>
> iommu_area_alloc() deals with pages, not actual sizes as
> gart_map_simple() does.
>
> If anything, I would make this simple fix:
>
> dma_addr_t map = dma_map_area(dev, paddr, size, dir, size - 1);
>
> should be
>
> dma_addr_t map = dma_map_area(dev, paddr, size, dir, size);
>
> because after my patch we round up the mask argument to get the correct
> alignment to # of pages anyway.

Feel like respinning with a full changelog against my for-linus branch?  Maybe 
you can convince Tomonori-san this time. :)

Jesse

Re: [PATCH]: PCI: GART iommu alignment fixes [v2]

[Prarit Bhargava]

Jesse Barnes wrote:
> On Wednesday, August 6, 2008 7:32 am Prarit Bhargava wrote:
>   
>>> You can't kmalloc pci_dev or setup some trivial values. You need to
>>> use a proper value. The pci code does for us.
>>>       
>> Oops -- I meant struct device, not struct pci_dev.
>>
>> Anwyay, Jesse -- is this true?  I can no longer do something like:
>>
>>
>> static struct device junk_dev = {
>>         .bus_id = "junk device",
>>         .coherent_dma_mask = 0xffffffff,
>>         .dma_mask = &junk_dev.coherent_dma_mask,
>> };
>>
>> And then use that as the device target for dma_alloc_coherent?  AFAIK,
>> that has always worked for me.
>>     
>
> It gets dangerous since platforms are in control of some pci_dev and dev 
> fields, and if they don't get initialized you can get into trouble.
>   

True, but dma_alloc_coherent also allows for a NULL dev pointer, and 
uses a dummy struct dev (fallback_device).  So it should be callable 
without any dev struct pointer.

In that case, I hit the BUG() check warning in iommu_is_span_boundary() 
because boundary_size was calculated as (unsigned long) 0xffffffff + 1 = 0.

That's why we must cast to "unsigned long long".

ie) it is possible to hit this BUG() right now.

>   
>>> Calgary IOMMU has the same code. New AMD IOMMU has the same code too.
>>>       
>> Then they don't handle the above problem and are broken when
>> dma_get_seg_boundary() returns 0xffffffff and will require patches.
>>
>> /me hasn't tried out Calgary of AMD IOMMU.
>>     
>
> Would be good to find someone to do some testing on one of those platforms...
>   

I've pinged someone at AMD to see if I can get my hands on a system (or 
if to see if there is a system available locally).

As for Calgary, I'm looking into it ATM.  I think I can get my hands on one.

If I find the problem on those platforms I'll ping the maintainers and 
post separate patches.  ATM I'm much more concerned about GART.

>   
>>>> Maybe I'm missing something -- what implies  size has to be a power of
>>>> two?
>>>>         
>>> Yes, see iommu_area_alloc().
>>>       
>> /me looks and still doesn't see where the size passed into
>> gart_map_simple() must be a power of two.  ... and if that was the case,
>> shouldn't we be failing all the time?  I mean, I've seen values passed
>> into pci_alloc_consistent like 0x3820 -- clearly not a multiple of 2.
>>
>> iommu_area_alloc() deals with pages, not actual sizes as
>> gart_map_simple() does.
>>     

Tomonori-san, I think I understand where your confusion may lie.  The 
size argument in the iommu-helper.c code is NOT the same size in 
dma_alloc_coherent() and gart_map_simple().  In iommu-helper.c the size 
is the # of pages, and the in the exported function calls it is an 
actual size.  Is that what is confusing you?

>> If anything, I would make this simple fix:
>>
>> dma_addr_t map = dma_map_area(dev, paddr, size, dir, size - 1);
>>
>> should be
>>
>> dma_addr_t map = dma_map_area(dev, paddr, size, dir, size);
>>
>> because after my patch we round up the mask argument to get the correct
>> alignment to # of pages anyway.
>>     
>
> Feel like respinning with a full changelog against my for-linus branch?  Maybe 
> you can convince Tomonori-san this time. :)
>
>   

I no longer think the above suggested change is necessary.  AFAICT, the 
code is doing exactly the right thing.  "size-1" is correct.

P.

> Jesse
>   

Re: [PATCH]: PCI: GART iommu alignment fixes [v2]

[Muli Ben-Yehuda]

On Thu, Aug 07, 2008 at 01:41:40PM -0400, Prarit Bhargava wrote:

> As for Calgary, I'm looking into it ATM.  I think I can get my hands
> on one.

Feel free to ping me if Calgary testing is needed.

Cheers,
Muli
-- 
Workshop on I/O Virtualization (WIOV '08)
Co-located with OSDI '08, Dec 2008, San Diego, CA
http://www.usenix.org/wiov08

Re: [PATCH]: PCI: GART iommu alignment fixes [v2]

[Prarit Bhargava]

Muli Ben-Yehuda wrote:
> On Thu, Aug 07, 2008 at 01:41:40PM -0400, Prarit Bhargava wrote:
>
>   
>> As for Calgary, I'm looking into it ATM.  I think I can get my hands
>> on one.
>>     
>
> Feel free to ping me if Calgary testing is needed.
>   

Muli -- I just ran tests on an IBM system with a Calgary iommu that Ed 
Pollard pointed me at.

dma_ops_alloc_addresses() does not have the option to return 
size-aligned values.  This means that 
pci_alloc_consistent()/dma_alloc_coherent() will return unaligned values 
to callers when the lower 4G of memory not available.

Additionally, a quick test shows that in dma_ops_alloc_addresses()

        boundary_size = ALIGN(dma_get_seg_boundary(dev) + 1,
                        PAGE_SIZE) >> PAGE_SHIFT;

may return 0 in the same manner I've been pointing out -- if 
dma_get_seg_boundary(dev) returns 0xffffffff and 1 is added to that 
result, boundary_size = 0.  Then you BUG() in the iommu-helper code.

Jesse pointed out to me that my fix on that line is incorrect.  _If_ 
this is not a compiler issue (I've emailed jakub privately and cc'd him 
on this email) then a better fix would be to do (sorry for the 
cut-and-paste):

--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -78,7 +78,7 @@ static inline unsigned int dma_set_max_seg_size(struct 
device
 static inline unsigned long dma_get_seg_boundary(struct device *dev)
 {
        return dev->dma_parms ?
-               dev->dma_parms->segment_boundary_mask : 0xffffffff;
+               dev->dma_parms->segment_boundary_mask : 0xffffffffUL;
 }
 
However, I'm still waiting for clarification from jakub before 
submitting again with that chunk.

P.


> Cheers,
> Muli
>   

Re: [PATCH]: PCI: GART iommu alignment fixes [v2]

[Jesse Barnes]

On Friday, August 8, 2008 8:18 am Prarit Bhargava wrote:
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -78,7 +78,7 @@ static inline unsigned int dma_set_max_seg_size(struct
> device
>  static inline unsigned long dma_get_seg_boundary(struct device *dev)
>  {
>         return dev->dma_parms ?
> -               dev->dma_parms->segment_boundary_mask : 0xffffffff;
> +               dev->dma_parms->segment_boundary_mask : 0xffffffffUL;
>  }

Yeah generally you need to cast values like this when working with real 
unsigned long values rather than ints, but this *should* still be safe 
(barring a compiler bug).  The return type is unsigned long, so even if you 
just return 0xffffffff the right thing should still happen...

Jesse

Re: [PATCH]: PCI: GART iommu alignment fixes [v2]

[FUJITA Tomonori]

On Fri, 8 Aug 2008 09:15:51 -0700
Jesse Barnes <jbarnes@virtuousgeek.org> wrote:

> On Friday, August 8, 2008 8:18 am Prarit Bhargava wrote:
> > --- a/include/linux/dma-mapping.h
> > +++ b/include/linux/dma-mapping.h
> > @@ -78,7 +78,7 @@ static inline unsigned int dma_set_max_seg_size(struct
> > device
> >  static inline unsigned long dma_get_seg_boundary(struct device *dev)
> >  {
> >         return dev->dma_parms ?
> > -               dev->dma_parms->segment_boundary_mask : 0xffffffff;
> > +               dev->dma_parms->segment_boundary_mask : 0xffffffffUL;
> >  }
> 
> Yeah generally you need to cast values like this when working with real 
> unsigned long values rather than ints, but this *should* still be safe 
> (barring a compiler bug).  The return type is unsigned long, so even if you 
> just return 0xffffffff the right thing should still happen...

I told Prarid that the overflow should not happen here again and
again...

Re: [PATCH]: PCI: GART iommu alignment fixes [v2]

[Prarit Bhargava]

FUJITA Tomonori wrote:
> On Fri, 8 Aug 2008 09:15:51 -0700
> Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
>
>   
>> On Friday, August 8, 2008 8:18 am Prarit Bhargava wrote:
>>     
>>> --- a/include/linux/dma-mapping.h
>>> +++ b/include/linux/dma-mapping.h
>>> @@ -78,7 +78,7 @@ static inline unsigned int dma_set_max_seg_size(struct
>>> device
>>>  static inline unsigned long dma_get_seg_boundary(struct device *dev)
>>>  {
>>>         return dev->dma_parms ?
>>> -               dev->dma_parms->segment_boundary_mask : 0xffffffff;
>>> +               dev->dma_parms->segment_boundary_mask : 0xffffffffUL;
>>>  }
>>>       
>> Yeah generally you need to cast values like this when working with real 
>> unsigned long values rather than ints, but this *should* still be safe 
>> (barring a compiler bug).  The return type is unsigned long, so even if you 
>> just return 0xffffffff the right thing should still happen...
>>     
>
> I told Prarid that the overflow should not happen here again and
> again...
>   

I misunderstood what was going on here.

P.

Re: [PATCH]: PCI: GART iommu alignment fixes [v2]

[FUJITA Tomonori]

On Thu, 07 Aug 2008 13:41:40 -0400
Prarit Bhargava <prarit@redhat.com> wrote:

> In that case, I hit the BUG() check warning in iommu_is_span_boundary() 
> because boundary_size was calculated as (unsigned long) 0xffffffff + 1 = 0.
> 
> That's why we must cast to "unsigned long long".
> 
> ie) it is possible to hit this BUG() right now.

Wrong, it doesn't happen, as I said again and again.


> >>>> Maybe I'm missing something -- what implies  size has to be a power of
> >>>> two?
> >>>>         
> >>> Yes, see iommu_area_alloc().
> >>>       
> >> /me looks and still doesn't see where the size passed into
> >> gart_map_simple() must be a power of two.  ... and if that was the case,
> >> shouldn't we be failing all the time?  I mean, I've seen values passed
> >> into pci_alloc_consistent like 0x3820 -- clearly not a multiple of 2.
> >>
> >> iommu_area_alloc() deals with pages, not actual sizes as
> >> gart_map_simple() does.
> >>     
> 
> Tomonori-san, I think I understand where your confusion may lie.  The 
> size argument in the iommu-helper.c code is NOT the same size in 
> dma_alloc_coherent() and gart_map_simple().  In iommu-helper.c the size 
> is the # of pages, and the in the exported function calls it is an 
> actual size.  Is that what is confusing you?

I understand it. FYI, I wrote iommu-helper.c.

Again, you don't understand the code. Here's a patch to fix the GART
to allocate a size-aligned address for alloc_coherent.

But as I told you again and again, I doubt that this fixes something.

=
From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Subject: [PATCH] x86 gart: allocate size-aligned address for alloc_coherent

This fixes GART to return a properly aligned address as
DMA-mapping.txt defines.

Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
---
 arch/x86/kernel/pci-gart_64.c |   25 ++++++++++++++++---------
 1 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/arch/x86/kernel/pci-gart_64.c b/arch/x86/kernel/pci-gart_64.c
index 49285f8..8e64b49 100644
--- a/arch/x86/kernel/pci-gart_64.c
+++ b/arch/x86/kernel/pci-gart_64.c
@@ -82,7 +82,8 @@ AGPEXTERN __u32 *agp_gatt_table;
 static unsigned long next_bit;  /* protected by iommu_bitmap_lock */
 static int need_flush;		/* global flush state. set for each gart wrap */
 
-static unsigned long alloc_iommu(struct device *dev, int size)
+static unsigned long alloc_iommu(struct device *dev, int size,
+				 unsigned long align_mask)
 {
 	unsigned long offset, flags;
 	unsigned long boundary_size;
@@ -95,11 +96,12 @@ static unsigned long alloc_iommu(struct device *dev, int size)
 
 	spin_lock_irqsave(&iommu_bitmap_lock, flags);
 	offset = iommu_area_alloc(iommu_gart_bitmap, iommu_pages, next_bit,
-				  size, base_index, boundary_size, 0);
+				  size, base_index, boundary_size, align_mask);
 	if (offset == -1) {
 		need_flush = 1;
 		offset = iommu_area_alloc(iommu_gart_bitmap, iommu_pages, 0,
-					  size, base_index, boundary_size, 0);
+					  size, base_index, boundary_size,
+					  align_mask);
 	}
 	if (offset != -1) {
 		next_bit = offset+size;
@@ -236,10 +238,10 @@ nonforced_iommu(struct device *dev, unsigned long addr, size_t size)
  * Caller needs to check if the iommu is needed and flush.
  */
 static dma_addr_t dma_map_area(struct device *dev, dma_addr_t phys_mem,
-				size_t size, int dir)
+				size_t size, int dir, unsigned long align_mask)
 {
 	unsigned long npages = iommu_num_pages(phys_mem, size);
-	unsigned long iommu_page = alloc_iommu(dev, npages);
+	unsigned long iommu_page = alloc_iommu(dev, npages, align_mask);
 	int i;
 
 	if (iommu_page == -1) {
@@ -262,7 +264,11 @@ static dma_addr_t dma_map_area(struct device *dev, dma_addr_t phys_mem,
 static dma_addr_t
 gart_map_simple(struct device *dev, phys_addr_t paddr, size_t size, int dir)
 {
-	dma_addr_t map = dma_map_area(dev, paddr, size, dir);
+	dma_addr_t map;
+	unsigned long align_mask;
+
+	align_mask = (roundup_pow_of_two(size) >> PAGE_SHIFT) - 1;
+	map = dma_map_area(dev, paddr, size, dir, align_mask);
 
 	flush_gart();
 
@@ -281,7 +287,8 @@ gart_map_single(struct device *dev, phys_addr_t paddr, size_t size, int dir)
 	if (!need_iommu(dev, paddr, size))
 		return paddr;
 
-	bus = gart_map_simple(dev, paddr, size, dir);
+	bus = dma_map_area(dev, paddr, size, dir, 0);
+	flush_gart();
 
 	return bus;
 }
@@ -340,7 +347,7 @@ static int dma_map_sg_nonforce(struct device *dev, struct scatterlist *sg,
 		unsigned long addr = sg_phys(s);
 
 		if (nonforced_iommu(dev, addr, s->length)) {
-			addr = dma_map_area(dev, addr, s->length, dir);
+			addr = dma_map_area(dev, addr, s->length, dir, 0);
 			if (addr == bad_dma_address) {
 				if (i > 0)
 					gart_unmap_sg(dev, sg, i, dir);
@@ -362,7 +369,7 @@ static int __dma_map_cont(struct device *dev, struct scatterlist *start,
 			  int nelems, struct scatterlist *sout,
 			  unsigned long pages)
 {
-	unsigned long iommu_start = alloc_iommu(dev, pages);
+	unsigned long iommu_start = alloc_iommu(dev, pages, 0);
 	unsigned long iommu_page = iommu_start;
 	struct scatterlist *s;
 	int i;
-- 
1.5.5.GIT

Re: [PATCH]: PCI: GART iommu alignment fixes [v2]

[Ingo Molnar]

* FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:

> From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
> Subject: [PATCH] x86 gart: allocate size-aligned address for alloc_coherent
> 
> This fixes GART to return a properly aligned address as
> DMA-mapping.txt defines.

applied to tip/x86/gart, thanks! Any v2.6.27-urgency of this patch?

	Ingo

Re: [PATCH]: PCI: GART iommu alignment fixes [v2]

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> 
> * FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:
> 
> > From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
> > Subject: [PATCH] x86 gart: allocate size-aligned address for alloc_coherent
> > 
> > This fixes GART to return a properly aligned address as
> > DMA-mapping.txt defines.
> 
> applied to tip/x86/gart, thanks! Any v2.6.27-urgency of this patch?

hm, -tip testing has found that this patch causes a hard hang during 
bootup:

 initcall ali_init+0x0/0x1b returned 0 after 3 msecs
 calling  amd_init+0x0/0x1b
 bus: 'pci': add driver pata_amd
 bus: 'pci': driver_probe_device: matched device 0000:00:06.0 with driver pata_amd
 bus: 'pci': really_probe: probing driver pata_amd with device 0000:00:06.0
 pata_amd 0000:00:06.0: version 0.3.10
 pata_amd 0000:00:06.0: setting latency timer to 64
 [hard hang]

should have continued with:

 scsi0 : pata_amd
 device: 'host0': device_add
 device: 'host0': device_add
 scsi1 : pata_amd
 [... etc. ... ]

on an AMD X2 testsystem. (Asus board) Can send more info on request. 
Config is:

  http://redhat.com/~mingo/misc/config-Fri_Aug_15_18_30_56_CEST_2008.bad

Any idea why that is so? Apparently the alignment change wasnt as benign 
as assumed.

	Ingo

Re: [PATCH]: PCI: GART iommu alignment fixes [v2]

[Prarit Bhargava]

>
> on an AMD X2 testsystem. (Asus board) Can send more info on request. 
> Config is:
>
>   http://redhat.com/~mingo/misc/config-Fri_Aug_15_18_30_56_CEST_2008.bad
>
> Any idea why that is so? Apparently the alignment change wasnt as benign 
> as assumed.
>
>   

Ingo, can you please send me details on the system?  I'll try to track 
it down.

P.

> 	Ingo
>   

Re: [PATCH]: PCI: GART iommu alignment fixes [v2]

[Ingo Molnar]

* Prarit Bhargava <prarit@redhat.com> wrote:

>> on an AMD X2 testsystem. (Asus board) Can send more info on request.  
>> Config is:
>>
>>   http://redhat.com/~mingo/misc/config-Fri_Aug_15_18_30_56_CEST_2008.bad
>>
>> Any idea why that is so? Apparently the alignment change wasnt as 
>> benign as assumed.
>
> Ingo, can you please send me details on the system?  I'll try to track 
> it down.

below is a bootlog and lspci output. There's nothing special about it - 
run of the mill whitebox PC, ASUS A8N-E, Athlon64 X2 3800+, 1GB RAM.

	Ingo

--------------->
Initializing cgroup subsys cpuset
Linux version 2.6.27-rc3-tip (mingo@dione) (gcc version 4.2.3) #24581 SMP Fri Aug 15 23:11:30 CEST 2008
Command line: root=/dev/sda6 earlyprintk=serial,ttyS0,115200,keep debug initcall_debug apic=verbose sysrq_always_enabled ignore_loglevel selinux=0 nmi_watchdog=0 highres=0 nmi_watchdog=0 nolapic_timer idle=mwait idle=poll highmem=512m nopat notsc pci=nomsi
KERNEL supported cpus:
  Intel GenuineIntel
  AMD AuthenticAMD
  Centaur CentaurHauls
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
 BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000003fff0000 (usable)
 BIOS-e820: 000000003fff0000 - 000000003fff3000 (ACPI NVS)
 BIOS-e820: 000000003fff3000 - 0000000040000000 (ACPI data)
 BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
 BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
console [earlyser0] enabled
debug: ignoring loglevel setting.
using polling idle threads.
PAT support disabled.
last_pfn = 0x3fff0 max_arch_pfn = 0x3ffffffff
init_memory_mapping
 0000000000 - 003fe00000 page 2M
 003fe00000 - 003fff0000 page 4k
kernel direct mapping tables up to 3fff0000 @ 8000-b000
last_map_addr: 3fff0000 end: 3fff0000
DMI 2.3 present.
(5 early reservations) ==> bootmem [0000000000 - 003fff0000]
  #0 [0000000000 - 0000001000]   BIOS data page ==> [0000000000 - 0000001000]
  #1 [0000006000 - 0000008000]       TRAMPOLINE ==> [0000006000 - 0000008000]
  #2 [0000200000 - 000107959c]    TEXT DATA BSS ==> [0000200000 - 000107959c]
  #3 [000009f800 - 0000100000]    BIOS reserved ==> [000009f800 - 0000100000]
  #4 [0000008000 - 0000009000]          PGTABLE ==> [0000008000 - 0000009000]
Scan SMP from ffff880000000000 for 1024 bytes.
Scan SMP from ffff88000009fc00 for 1024 bytes.
Scan SMP from ffff8800000f0000 for 65536 bytes.
found SMP MP-table at [ffff8800000f5680] 000f5680
 [ffffe20000000000-ffffe20000ffffff] PMD -> [ffff880001200000-ffff8800021fffff] on node 0
Zone PFN ranges:
  DMA      0x00000000 -> 0x00001000
  DMA32    0x00001000 -> 0x00100000
  Normal   0x00100000 -> 0x00100000
Movable zone start PFN for each node
early_node_map[2] active PFN ranges
    0: 0x00000000 -> 0x0000009f
    0: 0x00000100 -> 0x0003fff0
On node 0 totalpages: 262031
  DMA zone: 3833 pages, LIFO batch:0
  DMA32 zone: 254000 pages, LIFO batch:31
Intel MultiProcessor Specification v1.4
MPTABLE: OEM ID: OEM00000
MPTABLE: Product ID: PROD00000000
MPTABLE: APIC at: 0xFEE00000
Processor #0 (Bootup-CPU)
Processor #1
Bus #0 is PCI   
Bus #1 is PCI   
Bus #2 is PCI   
Bus #3 is PCI   
Bus #4 is PCI   
Bus #5 is PCI   
Bus #6 is ISA   
I/O APIC #2 Version 17 at 0xFEC00000.
Int: type 0, pol 3, trig 3, bus 00, IRQ 28, APIC ID 2, APIC INT 0b
Int: type 0, pol 3, trig 3, bus 00, IRQ 10, APIC ID 2, APIC INT 03
Int: type 0, pol 3, trig 3, bus 01, IRQ 00, APIC ID 2, APIC INT 05
Int: type 0, pol 3, trig 3, bus 05, IRQ 1c, APIC ID 2, APIC INT 0b
Int: type 3, pol 0, trig 0, bus 06, IRQ 00, APIC ID 2, APIC INT 00
Int: type 0, pol 0, trig 0, bus 06, IRQ 01, APIC ID 2, APIC INT 01
Int: type 0, pol 0, trig 0, bus 06, IRQ 00, APIC ID 2, APIC INT 02
Int: type 0, pol 0, trig 0, bus 06, IRQ 04, APIC ID 2, APIC INT 04
Int: type 0, pol 0, trig 0, bus 06, IRQ 06, APIC ID 2, APIC INT 06
Int: type 0, pol 0, trig 0, bus 06, IRQ 07, APIC ID 2, APIC INT 07
Int: type 0, pol 1, trig 1, bus 06, IRQ 08, APIC ID 2, APIC INT 08
Int: type 0, pol 0, trig 0, bus 06, IRQ 09, APIC ID 2, APIC INT 09
Int: type 0, pol 0, trig 0, bus 06, IRQ 0a, APIC ID 2, APIC INT 0a
Int: type 0, pol 0, trig 0, bus 06, IRQ 0c, APIC ID 2, APIC INT 0c
Int: type 0, pol 0, trig 0, bus 06, IRQ 0d, APIC ID 2, APIC INT 0d
Int: type 0, pol 0, trig 0, bus 06, IRQ 0e, APIC ID 2, APIC INT 0e
Int: type 0, pol 0, trig 0, bus 06, IRQ 0f, APIC ID 2, APIC INT 0f
Lint: type 3, pol 0, trig 0, bus 00, IRQ 00, APIC ID ff, APIC LINT 00
Lint: type 1, pol 0, trig 0, bus 00, IRQ 00, APIC ID ff, APIC LINT 01
Processors: 2
SMP: Allowing 2 CPUs, 0 hotplug CPUs
mapped APIC to ffffffffff5fc000 (        fee00000)
mapped IOAPIC to ffffffffff5fb000 (00000000fec00000)
PM: Registered nosave memory: 000000000009f000 - 00000000000a0000
PM: Registered nosave memory: 00000000000a0000 - 00000000000f0000
PM: Registered nosave memory: 00000000000f0000 - 0000000000100000
Allocating PCI resources starting at 50000000 (gap: 40000000:a0000000)
dyn_array irq_2_pin_head+0x0/0x8 size:0x10 nr:256 align:0x1000
dyn_array irq_cfgx+0x0/0x8 size:0x420 nr:32 align:0x1000
dyn_array irq_descX+0x0/0x8 size:0x500 nr:32 align:0x1000
dyn_array total_size: 0x14000
dyn_array irq_2_pin_head+0x0/0x8  ==> [0x1084000 - 0x1085000]
dyn_array irq_cfgx+0x0/0x8  ==> [0x1085000 - 0x108d400]
dyn_array irq_descX+0x0/0x8  ==> [0x108e000 - 0x1098000]
kstat_irqs ==> [0x1098000 - 0x1098100]
PERCPU: Allocating 69632 bytes of per cpu data
NR_CPUS: 4096, nr_cpu_ids: 2, nr_node_ids 512
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 257833
Kernel command line: root=/dev/sda6 earlyprintk=serial,ttyS0,115200,keep debug initcall_debug apic=verbose sysrq_always_enabled ignore_loglevel selinux=0 nmi_watchdog=0 highres=0 nmi_watchdog=0 nolapic_timer idle=mwait idle=poll highmem=512m nopat notsc pci=nomsi
debug: sysrq always enabled.
notsc: Kernel compiled with CONFIG_X86_TSC, cannot disable TSC completely.
Initializing CPU#0
found new irq_desc for irq 0
found new irq_desc for irq 1
found new irq_desc for irq 2
found new irq_desc for irq 3
found new irq_desc for irq 4
found new irq_desc for irq 5
found new irq_desc for irq 6
found new irq_desc for irq 7
found new irq_desc for irq 8
found new irq_desc for irq 9
found new irq_desc for irq 10
found new irq_desc for irq 11
found new irq_desc for irq 12
found new irq_desc for irq 13
found new irq_desc for irq 14
found new irq_desc for irq 15
PID hash table entries: 4096 (order: 12, 32768 bytes)
TSC calibrated against PIT
Detected 2010.337 MHz processor.
spurious 8259A interrupt: IRQ7.
Console: colour VGA+ 80x25
console [tty0] enabled
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
Memory: 1014380k/1048512k available (5275k kernel code, 33136k reserved, 5387k data, 1128k init)
CPA: page pool initialized 1 of 1 pages preallocated
SLUB: Genslabs=12, HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=512
Calibrating delay loop (skipped), value calculated using timer frequency.. 4020.67 BogoMIPS (lpj=8041348)
Security Framework initialized
Mount-cache hash table entries: 256
Initializing cgroup subsys debug
Initializing cgroup subsys ns
Initializing cgroup subsys cpuacct
Initializing cgroup subsys memory
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
tseg: 0000000000
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
ftrace: converting mcount calls to 0f 1f 44 00 00
ftrace: allocating 22239 hash entries in 175 pages
Setting APIC routing to flat
enabled ExtINT on CPU#0
ExtINT not setup in hardware but reported by MP table
ENABLING IO-APIC IRQs
init IO_APIC IRQs
 IO-APIC (apicid-pin) 2-0 not connected.
 0 add_pin_to_irq: irq 1 --> apic 0 pin 1
IOAPIC[0]: Set routing entry (2-1 -> 0x31 -> IRQ 1 Mode:0 Active:0)
 0 add_pin_to_irq: irq 0 --> apic 0 pin 2
IOAPIC[0]: Set routing entry (2-2 -> 0x30 -> IRQ 0 Mode:0 Active:0)
 0 add_pin_to_irq: irq 3 --> apic 0 pin 3
IOAPIC[0]: Set routing entry (2-3 -> 0x33 -> IRQ 3 Mode:1 Active:1)
 0 add_pin_to_irq: irq 4 --> apic 0 pin 4
IOAPIC[0]: Set routing entry (2-4 -> 0x34 -> IRQ 4 Mode:0 Active:0)
 0 add_pin_to_irq: irq 5 --> apic 0 pin 5
IOAPIC[0]: Set routing entry (2-5 -> 0x35 -> IRQ 5 Mode:1 Active:1)
 0 add_pin_to_irq: irq 6 --> apic 0 pin 6
IOAPIC[0]: Set routing entry (2-6 -> 0x36 -> IRQ 6 Mode:0 Active:0)
 0 add_pin_to_irq: irq 7 --> apic 0 pin 7
IOAPIC[0]: Set routing entry (2-7 -> 0x37 -> IRQ 7 Mode:0 Active:0)
 0 add_pin_to_irq: irq 8 --> apic 0 pin 8
IOAPIC[0]: Set routing entry (2-8 -> 0x38 -> IRQ 8 Mode:0 Active:0)
 0 add_pin_to_irq: irq 9 --> apic 0 pin 9
IOAPIC[0]: Set routing entry (2-9 -> 0x39 -> IRQ 9 Mode:0 Active:0)
 0 add_pin_to_irq: irq 10 --> apic 0 pin 10
IOAPIC[0]: Set routing entry (2-10 -> 0x3a -> IRQ 10 Mode:0 Active:0)
 0 add_pin_to_irq: irq 11 --> apic 0 pin 11
IOAPIC[0]: Set routing entry (2-11 -> 0x3b -> IRQ 11 Mode:1 Active:1)
 0 add_pin_to_irq: irq 12 --> apic 0 pin 12
IOAPIC[0]: Set routing entry (2-12 -> 0x3c -> IRQ 12 Mode:0 Active:0)
 0 add_pin_to_irq: irq 13 --> apic 0 pin 13
IOAPIC[0]: Set routing entry (2-13 -> 0x3d -> IRQ 13 Mode:0 Active:0)
 0 add_pin_to_irq: irq 14 --> apic 0 pin 14
IOAPIC[0]: Set routing entry (2-14 -> 0x3e -> IRQ 14 Mode:0 Active:0)
 0 add_pin_to_irq: irq 15 --> apic 0 pin 15
IOAPIC[0]: Set routing entry (2-15 -> 0x3f -> IRQ 15 Mode:0 Active:0)
 IO-APIC (apicid-pin) 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not connected.
..TIMER: vector=0x30 apic1=0 pin1=2 apic2=0 pin2=0
..MP-BIOS bug: 8254 timer not connected to IO-APIC
...trying to set up timer (IRQ0) through the 8259A ...
..... (found apic 0 pin 0) ...
....... works.
CPU0: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ stepping 02
Disabling APIC timer
calling  migration_init+0x0/0x4f
initcall migration_init+0x0/0x4f returned 1 after 0 msecs
initcall migration_init+0x0/0x4f returned with error code 1 
calling  spawn_ksoftirqd+0x0/0x4d
initcall spawn_ksoftirqd+0x0/0x4d returned 0 after 0 msecs
calling  init_call_single_data+0x0/0x5a
initcall init_call_single_data+0x0/0x5a returned 0 after 0 msecs
calling  relay_init+0x0/0x14
initcall relay_init+0x0/0x14 returned 0 after 0 msecs
Booting processor 1/1 ip 6000
Initializing CPU#1
masked ExtINT on CPU#1
Calibrating delay loop... 2007.04 BogoMIPS (lpj=4014080)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 1
CPU1: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ stepping 02
Brought up 2 CPUs
Total of 2 processors activated (6027.71 BogoMIPS).
CPU0 attaching sched-domain:
 domain 0: span 0-1 level CPU
  groups: 0 1
CPU1 attaching sched-domain:
 domain 0: span 0-1 level CPU
  groups: 1 0
PM: Adding info for No Bus:platform
calling  init_cpufreq_transition_notifier_list+0x0/0x1b
initcall init_cpufreq_transition_notifier_list+0x0/0x1b returned 0 after 0 msecs
calling  net_ns_init+0x0/0x13e
net_namespace: 1392 bytes
initcall net_ns_init+0x0/0x13e returned 0 after 3 msecs
calling  cpufreq_tsc+0x0/0x16
initcall cpufreq_tsc+0x0/0x16 returned 0 after 0 msecs
calling  init_smp_flush+0x0/0x53
initcall init_smp_flush+0x0/0x53 returned 0 after 0 msecs
calling  print_banner+0x0/0xe
Booting paravirtualized kernel on bare hardware
initcall print_banner+0x0/0xe returned 0 after 3 msecs
calling  ksysfs_init+0x0/0xbb
initcall ksysfs_init+0x0/0xbb returned 0 after 0 msecs
calling  init_jiffies_clocksource+0x0/0x12
initcall init_jiffies_clocksource+0x0/0x12 returned 0 after 0 msecs
calling  pm_init+0x0/0x34
initcall pm_init+0x0/0x34 returned 0 after 0 msecs
calling  pm_disk_init+0x0/0x19
initcall pm_disk_init+0x0/0x19 returned 0 after 0 msecs
calling  swsusp_header_init+0x0/0x31
initcall swsusp_header_init+0x0/0x31 returned 0 after 0 msecs
calling  filelock_init+0x0/0x2e
initcall filelock_init+0x0/0x2e returned 0 after 0 msecs
calling  init_script_binfmt+0x0/0x12
initcall init_script_binfmt+0x0/0x12 returned 0 after 0 msecs
calling  init_elf_binfmt+0x0/0x12
initcall init_elf_binfmt+0x0/0x12 returned 0 after 0 msecs
calling  init_compat_elf_binfmt+0x0/0x12
initcall init_compat_elf_binfmt+0x0/0x12 returned 0 after 0 msecs
calling  debugfs_init+0x0/0x51
initcall debugfs_init+0x0/0x51 returned 0 after 0 msecs
calling  securityfs_init+0x0/0x51
initcall securityfs_init+0x0/0x51 returned 0 after 0 msecs
calling  random32_init+0x0/0xca
initcall random32_init+0x0/0xca returned 0 after 0 msecs
calling  early_resume_init+0x0/0x1a6
Time: 21:11:41  Date: 08/15/08
initcall early_resume_init+0x0/0x1a6 returned 0 after 0 msecs
calling  cpufreq_core_init+0x0/0x89
initcall cpufreq_core_init+0x0/0x89 returned 0 after 0 msecs
calling  cpuidle_init+0x0/0x40
initcall cpuidle_init+0x0/0x40 returned 0 after 0 msecs
calling  virtio_init+0x0/0x2b
initcall virtio_init+0x0/0x2b returned 0 after 0 msecs
calling  sock_init+0x0/0x5e
initcall sock_init+0x0/0x5e returned 0 after 0 msecs
calling  netpoll_init+0x0/0x31
initcall netpoll_init+0x0/0x31 returned 0 after 0 msecs
calling  netlink_proto_init+0x0/0x14d
NET: Registered protocol family 16
initcall netlink_proto_init+0x0/0x14d returned 0 after 3 msecs
calling  bdi_class_init+0x0/0x41
initcall bdi_class_init+0x0/0x41 returned 0 after 0 msecs
calling  kobject_uevent_init+0x0/0x45
initcall kobject_uevent_init+0x0/0x45 returned 0 after 0 msecs
calling  pcibus_class_init+0x0/0x19
initcall pcibus_class_init+0x0/0x19 returned 0 after 0 msecs
calling  pci_driver_init+0x0/0x12
initcall pci_driver_init+0x0/0x12 returned 0 after 0 msecs
calling  lcd_class_init+0x0/0x4d
initcall lcd_class_init+0x0/0x4d returned 0 after 0 msecs
calling  tty_class_init+0x0/0x31
initcall tty_class_init+0x0/0x31 returned 0 after 0 msecs
calling  vtconsole_class_init+0x0/0xc3
PM: Adding info for No Bus:vtcon0
initcall vtconsole_class_init+0x0/0xc3 returned 0 after 3 msecs
calling  enable_pci_io_ecs+0x0/0x2e
initcall enable_pci_io_ecs+0x0/0x2e returned 0 after 0 msecs
calling  early_fill_mp_bus_info+0x0/0x7c2
node 0 link 0: io port [1000, fffff]
TOM: 0000000040000000 aka 1024M
node 0 link 0: mmio [e0000000, efffffff]
node 0 link 0: mmio [feb00000, fec0ffff]
node 0 link 0: mmio [a0000, bffff]
node 0 link 0: mmio [40000000, fed3ffff]
bus: [00,ff] on node 0 link 0
bus: 00 index 0 io port: [0, ffff]
bus: 00 index 1 mmio: [40000000, fcffffffff]
bus: 00 index 2 mmio: [feb00000, fec0ffff]
bus: 00 index 3 mmio: [a0000, bffff]
initcall early_fill_mp_bus_info+0x0/0x7c2 returned 0 after 34 msecs
calling  arch_kdebugfs_init+0x0/0x24
initcall arch_kdebugfs_init+0x0/0x24 returned 0 after 0 msecs
calling  mtrr_if_init+0x0/0x77
initcall mtrr_if_init+0x0/0x77 returned 0 after 0 msecs
calling  dmi_id_init+0x0/0x2f0
PM: Adding info for No Bus:id
initcall dmi_id_init+0x0/0x2f0 returned 0 after 0 msecs
calling  pci_arch_init+0x0/0x40
PCI: Using configuration type 1 for base access
initcall pci_arch_init+0x0/0x40 returned 0 after 3 msecs
calling  topology_init+0x0/0x33
initcall topology_init+0x0/0x33 returned 0 after 0 msecs
calling  mtrr_init_finialize+0x0/0x3d
initcall mtrr_init_finialize+0x0/0x3d returned 0 after 0 msecs
calling  param_sysfs_init+0x0/0x1d6
initcall param_sysfs_init+0x0/0x1d6 returned 0 after 15 msecs
calling  pm_sysrq_init+0x0/0x1e
initcall pm_sysrq_init+0x0/0x1e returned 0 after 3 msecs
calling  readahead_init+0x0/0x38
PM: Adding info for No Bus:default
initcall readahead_init+0x0/0x38 returned 0 after 0 msecs
calling  init_bio+0x0/0xc5
initcall init_bio+0x0/0xc5 returned 0 after 0 msecs
calling  blk_settings_init+0x0/0x2a
initcall blk_settings_init+0x0/0x2a returned 0 after 0 msecs
calling  blk_ioc_init+0x0/0x2a
initcall blk_ioc_init+0x0/0x2a returned 0 after 0 msecs
calling  genhd_device_init+0x0/0x55
initcall genhd_device_init+0x0/0x55 returned 0 after 0 msecs
calling  gpiolib_debugfs_init+0x0/0x24
initcall gpiolib_debugfs_init+0x0/0x24 returned 0 after 0 msecs
calling  pci_slot_init+0x0/0x4a
initcall pci_slot_init+0x0/0x4a returned 0 after 0 msecs
calling  misc_init+0x0/0x9f
initcall misc_init+0x0/0x9f returned 0 after 0 msecs
calling  tifm_init+0x0/0x7e
initcall tifm_init+0x0/0x7e returned 0 after 0 msecs
calling  phy_init+0x0/0x31
initcall phy_init+0x0/0x31 returned 0 after 0 msecs
calling  init_scsi+0x0/0x81
SCSI subsystem initialized
initcall init_scsi+0x0/0x81 returned 0 after 3 msecs
calling  ata_init+0x0/0x336
libata version 3.00 loaded.
initcall ata_init+0x0/0x336 returned 0 after 3 msecs
calling  spi_init+0x0/0x83
initcall spi_init+0x0/0x83 returned 0 after 0 msecs
calling  usb_init+0x0/0x10f
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
initcall usb_init+0x0/0x10f returned 0 after 11 msecs
calling  serio_init+0x0/0x99
initcall serio_init+0x0/0x99 returned 0 after 0 msecs
calling  gameport_init+0x0/0x98
initcall gameport_init+0x0/0x98 returned 0 after 0 msecs
calling  input_init+0x0/0x10e
initcall input_init+0x0/0x10e returned 0 after 0 msecs
calling  i2c_init+0x0/0x66
i2c-core: driver [dummy] registered
initcall i2c_init+0x0/0x66 returned 0 after 3 msecs
calling  leds_init+0x0/0x31
initcall leds_init+0x0/0x31 returned 0 after 0 msecs
calling  pci_subsys_init+0x0/0x116
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
PM: Adding info for No Bus:pci0000:00
PM: Adding info for No Bus:0000:00
HPET not enabled in BIOS. You might try hpet=force boot option
pci 0000:00:01.1: PME# supported from D3hot D3cold
pci 0000:00:01.1: PME# disabled
pci 0000:00:02.0: supports D1
pci 0000:00:02.0: supports D2
pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:02.0: PME# disabled
pci 0000:00:02.1: supports D1
pci 0000:00:02.1: supports D2
pci 0000:00:02.1: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:02.1: PME# disabled
pci 0000:00:04.0: supports D1
pci 0000:00:04.0: supports D2
pci 0000:00:0a.0: supports D1
pci 0000:00:0a.0: supports D2
pci 0000:00:0a.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:0a.0: PME# disabled
pci 0000:00:0b.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:0b.0: PME# disabled
pci 0000:00:0c.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:0c.0: PME# disabled
pci 0000:00:0d.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:0d.0: PME# disabled
pci 0000:00:0e.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:00:0e.0: PME# disabled
pci 0000:05:07.0: supports D1
pci 0000:05:07.0: supports D2
pci 0000:05:07.0: PME# supported from D1 D2 D3hot
pci 0000:05:07.0: PME# disabled
pci 0000:00:09.0: transparent bridge
PCI: bridge 0000:00:09.0 io port: [c000, cfff]
PCI: bridge 0000:00:09.0 32bit mmio: [da000000, da0fffff]
pci 0000:01:00.0: supports D1
pci 0000:01:00.0: supports D2
pci 0000:01:00.1: supports D1
pci 0000:01:00.1: supports D2
Pre-1.1 PCIe device detected, disable ASPM for 0000:00:0e.0. It can be enabled forcedly with 'pcie_aspm=force'
PCI: bridge 0000:00:0e.0 io port: [b000, bfff]
PCI: bridge 0000:00:0e.0 32bit mmio: [d8000000, d9ffffff]
PCI: bridge 0000:00:0e.0 64bit mmio pref: [d0000000, d7ffffff]
PM: Adding info for pci:0000:00:00.0
PM: Adding info for pci:0000:00:01.0
PM: Adding info for pci:0000:00:01.1
PM: Adding info for pci:0000:00:02.0
PM: Adding info for pci:0000:00:02.1
PM: Adding info for pci:0000:00:04.0
PM: Adding info for pci:0000:00:06.0
PM: Adding info for pci:0000:00:09.0
PM: Adding info for pci:0000:00:0a.0
PM: Adding info for pci:0000:00:0b.0
PM: Adding info for pci:0000:00:0c.0
PM: Adding info for pci:0000:00:0d.0
PM: Adding info for pci:0000:00:0e.0
PM: Adding info for pci:0000:00:18.0
PM: Adding info for pci:0000:00:18.1
PM: Adding info for pci:0000:00:18.2
PM: Adding info for pci:0000:00:18.3
PM: Adding info for pci:0000:05:07.0
PM: Adding info for No Bus:0000:05
PM: Adding info for No Bus:0000:04
PM: Adding info for No Bus:0000:03
PM: Adding info for No Bus:0000:02
PM: Adding info for pci:0000:01:00.0
PM: Adding info for pci:0000:01:00.1
PM: Adding info for No Bus:0000:01
pci 0000:00:00.0: default IRQ router [10de/005e]
pci 0000:00:04.0: PCI->APIC IRQ transform: INT A -> IRQ 3
pci 0000:00:0a.0: PCI->APIC IRQ transform: INT A -> IRQ 11
pci 0000:05:07.0: PCI->APIC IRQ transform: INT A -> IRQ 11
pci 0000:01:00.0: PCI->APIC IRQ transform: INT A -> IRQ 5
initcall pci_subsys_init+0x0/0x116 returned 0 after 221 msecs
calling  proto_init+0x0/0x2e
initcall proto_init+0x0/0x2e returned 0 after 0 msecs
calling  net_dev_init+0x0/0x148
initcall net_dev_init+0x0/0x148 returned 0 after 0 msecs
calling  neigh_init+0x0/0x71
initcall neigh_init+0x0/0x71 returned 0 after 0 msecs
calling  fib_rules_init+0x0/0xa6
initcall fib_rules_init+0x0/0xa6 returned 0 after 0 msecs
calling  pktsched_init+0x0/0xc4
initcall pktsched_init+0x0/0xc4 returned 0 after 0 msecs
calling  tc_filter_init+0x0/0x4c
initcall tc_filter_init+0x0/0x4c returned 0 after 0 msecs
calling  tc_action_init+0x0/0x4c
initcall tc_action_init+0x0/0x4c returned 0 after 0 msecs
calling  genl_init+0x0/0xd8
initcall genl_init+0x0/0xd8 returned 0 after 15 msecs
calling  cipso_v4_init+0x0/0x64
initcall cipso_v4_init+0x0/0x64 returned 0 after 0 msecs
calling  wanrouter_init+0x0/0x55
Sangoma WANPIPE Router v1.1 (c) 1995-2000 Sangoma Technologies Inc.
initcall wanrouter_init+0x0/0x55 returned 0 after 3 msecs
calling  wireless_nlevent_init+0x0/0x31
initcall wireless_nlevent_init+0x0/0x31 returned 0 after 0 msecs
calling  netlbl_init+0x0/0x83
NetLabel: Initializing
NetLabel:  domain hash size = 128
NetLabel:  protocols = UNLABELED CIPSOv4
NetLabel:  unlabeled traffic allowed by default
initcall netlbl_init+0x0/0x83 returned 0 after 11 msecs
calling  pci_iommu_init+0x0/0xd
initcall pci_iommu_init+0x0/0xd returned 0 after 0 msecs
calling  print_all_ICs+0x0/0x441

printing PIC contents
... PIC  IMR: fffa
... PIC  IRR: 0001
... PIC  ISR: 0001
... PIC ELCR: 0828

printing local APIC contents on CPU#0/0:
... APIC ID:      00000000 (0)
... APIC VERSION: 00040010
... APIC TASKPRI: 00000000 (00)
... APIC ARBPRI: 000000e0 (e0)
... APIC PROCPRI: 00000000
... APIC EOI: 00000000
... APIC RRR: 00000000
... APIC LDR: 01000000
... APIC DFR: ffffffff
... APIC SPIV: 000001ff
... APIC ISR field:
0123456789abcdef0123456789abcdef
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
... APIC TMR field:
0123456789abcdef0123456789abcdef
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
... APIC IRR field:
0123456789abcdef0123456789abcdef
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000010000000000000000
... APIC ESR: 00000000
... APIC ICR: 000008ef
... APIC ICR2: 02000000
... APIC LVTT: 00010000
... APIC LVTPC: 00010000
... APIC LVT0: 00010700
... APIC LVT1: 00000400
... APIC LVTERR: 000000fe
... APIC TMICT: 00000000
... APIC TMCCT: 00000000
... APIC TDCR: 00000000


printing local APIC contents on CPU#1/1:
... APIC ID:      01000000 (1)
... APIC VERSION: 00040010
... APIC TASKPRI: 00000000 (00)
... APIC ARBPRI: 00000030 (30)
... APIC PROCPRI: 00000000
... APIC EOI: 00000000
... APIC RRR: 00000000
... APIC LDR: 02000000
... APIC DFR: ffffffff
... APIC SPIV: 000001ff
... APIC ISR field:
0123456789abcdef0123456789abcdef
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
... APIC TMR field:
0123456789abcdef0123456789abcdef
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
... APIC IRR field:
0123456789abcdef0123456789abcdef
00000000000000000000000000000000
00000000000000001000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
... APIC ESR: 00000000
... APIC ICR: 000008ef
... APIC ICR2: 01000000
... APIC LVTT: 00010000
... APIC LVTPC: 00010000
... APIC LVT0: 00010700
... APIC LVT1: 00010400
... APIC LVTERR: 000000fe
... APIC TMICT: 00000000
... APIC TMCCT: 00000000
... APIC TDCR: 00000000

number of MP IRQ sources: 17.
number of IO-APIC #2 registers: 24.
testing the IO APIC.......................

IO APIC #2......
.... register #00: 00000000
.......    : physical APIC id: 00
.......    : Delivery Type: 0
.......    : LTS          : 0
.... register #01: 00170011
.......     : max redirection entries: 0017
.......     : PRQ implemented: 0
.......     : IO APIC version: 0011
.... register #02: 00000000
.......     : arbitration: 00
.... IRQ redirection table:
 NR Dst Mask Trig IRR Pol Stat Dmod Deli Vect:   
 00 003 0    0    0   0   0    1    1    30
 01 003 0    0    0   0   0    1    1    31
 02 000 1    0    0   0   0    0    0    00
 03 003 1    1    0   1   0    1    1    33
 04 003 0    0    0   0   0    1    1    34
 05 003 1    1    0   1   0    1    1    35
 06 003 0    0    0   0   0    1    1    36
 07 003 1    0    0   0   0    1    1    37
 08 003 0    0    0   0   0    1    1    38
 09 003 0    0    0   0   0    1    1    39
 0a 003 0    0    0   0   0    1    1    3A
 0b 003 1    1    0   1   0    1    1    3B
 0c 003 0    0    0   0   0    1    1    3C
 0d 003 0    0    0   0   0    1    1    3D
 0e 003 0    0    0   0   0    1    1    3E
 0f 003 0    0    0   0   0    1    1    3F
 10 000 1    0    0   0   0    0    0    00
 11 000 1    0    0   0   0    0    0    00
 12 000 1    0    0   0   0    0    0    00
 13 000 1    0    0   0   0    0    0    00
 14 000 1    0    0   0   0    0    0    00
 15 000 1    0    0   0   0    0    0    00
 16 000 1    0    0   0   0    0    0    00
 17 000 1    0    0   0   0    0    0    00
IRQ to pin mappings:
IRQ0 -> 0:0
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ5 -> 0:5
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ9 -> 0:9
IRQ10 -> 0:10
IRQ11 -> 0:11
IRQ12 -> 0:12
IRQ13 -> 0:13
IRQ14 -> 0:14
IRQ15 -> 0:15
.................................... done.
initcall print_all_ICs+0x0/0x441 returned 0 after 175 msecs
calling  hpet_late_init+0x0/0x4d
initcall hpet_late_init+0x0/0x4d returned -19 after 0 msecs
calling  clocksource_done_booting+0x0/0x12
initcall clocksource_done_booting+0x0/0x12 returned 0 after 0 msecs
calling  ftrace_init_debugfs+0x0/0xfd
initcall ftrace_init_debugfs+0x0/0xfd returned 0 after 0 msecs
calling  tracer_alloc_buffers+0x0/0x608
tracer: 357 pages allocated for 16384 entries of 88 bytes
   actual entries 16422
initcall tracer_alloc_buffers+0x0/0x608 returned 0 after 7 msecs
calling  init_pipe_fs+0x0/0x4c
initcall init_pipe_fs+0x0/0x4c returned 0 after 0 msecs
calling  init_mnt_writers+0x0/0x55
initcall init_mnt_writers+0x0/0x55 returned 0 after 0 msecs
calling  anon_inode_init+0x0/0x115
initcall anon_inode_init+0x0/0x115 returned 0 after 0 msecs
calling  pcie_aspm_init+0x0/0x8
initcall pcie_aspm_init+0x0/0x8 returned 0 after 0 msecs
calling  chr_dev_init+0x0/0xb4
PM: Adding info for No Bus:mem
PM: Adding info for No Bus:null
PM: Adding info for No Bus:port
PM: Adding info for No Bus:zero
PM: Adding info for No Bus:full
PM: Adding info for No Bus:random
PM: Adding info for No Bus:urandom
PM: Adding info for No Bus:kmsg
PM: Adding info for No Bus:oldmem
initcall chr_dev_init+0x0/0xb4 returned 0 after 26 msecs
calling  firmware_class_init+0x0/0x79
initcall firmware_class_init+0x0/0x79 returned 0 after 0 msecs
calling  loopback_init+0x0/0x12
PM: Adding info for No Bus:lo
initcall loopback_init+0x0/0x12 returned 0 after 0 msecs
calling  cpufreq_gov_performance_init+0x0/0x12
initcall cpufreq_gov_performance_init+0x0/0x12 returned 0 after 0 msecs
calling  ssb_modinit+0x0/0x4a
initcall ssb_modinit+0x0/0x4a returned 0 after 0 msecs
calling  pcibios_assign_resources+0x0/0x88
pci 0000:00:09.0: PCI bridge, secondary bus 0000:05
pci 0000:00:09.0:   IO window: 0xc000-0xcfff
pci 0000:00:09.0:   MEM window: 0xda000000-0xda0fffff
pci 0000:00:09.0:   PREFETCH window: disabled
pci 0000:00:0b.0: PCI bridge, secondary bus 0000:04
pci 0000:00:0b.0:   IO window: disabled
pci 0000:00:0b.0:   MEM window: disabled
pci 0000:00:0b.0:   PREFETCH window: disabled
pci 0000:00:0c.0: PCI bridge, secondary bus 0000:03
pci 0000:00:0c.0:   IO window: disabled
pci 0000:00:0c.0:   MEM window: disabled
pci 0000:00:0c.0:   PREFETCH window: disabled
pci 0000:00:0d.0: PCI bridge, secondary bus 0000:02
pci 0000:00:0d.0:   IO window: disabled
pci 0000:00:0d.0:   MEM window: disabled
pci 0000:00:0d.0:   PREFETCH window: disabled
pci 0000:00:0e.0: PCI bridge, secondary bus 0000:01
pci 0000:00:0e.0:   IO window: 0xb000-0xbfff
pci 0000:00:0e.0:   MEM window: 0xd8000000-0xd9ffffff
pci 0000:00:0e.0:   PREFETCH window: 0x000000d0000000-0x000000d7ffffff
pci 0000:00:09.0: setting latency timer to 64
pci 0000:00:0b.0: setting latency timer to 64
pci 0000:00:0c.0: setting latency timer to 64
pci 0000:00:0d.0: setting latency timer to 64
pci 0000:00:0e.0: setting latency timer to 64
bus: 00 index 0 io port: [0, ffff]
bus: 00 index 1 mmio: [0, ffffffffffffffff]
bus: 05 index 0 io port: [c000, cfff]
bus: 05 index 1 mmio: [da000000, da0fffff]
bus: 05 index 2 mmio: [0, 0]
bus: 05 index 3 io port: [0, ffff]
bus: 05 index 4 mmio: [0, ffffffffffffffff]
bus: 04 index 0 mmio: [0, 0]
bus: 04 index 1 mmio: [0, 0]
bus: 04 index 2 mmio: [0, 0]
bus: 04 index 3 mmio: [0, 0]
bus: 03 index 0 mmio: [0, 0]
bus: 03 index 1 mmio: [0, 0]
bus: 03 index 2 mmio: [0, 0]
bus: 03 index 3 mmio: [0, 0]
bus: 02 index 0 mmio: [0, 0]
bus: 02 index 1 mmio: [0, 0]
bus: 02 index 2 mmio: [0, 0]
bus: 02 index 3 mmio: [0, 0]
bus: 01 index 0 io port: [b000, bfff]
bus: 01 index 1 mmio: [d8000000, d9ffffff]
bus: 01 index 2 mmio: [d0000000, d7ffffff]
bus: 01 index 3 mmio: [0, 0]
initcall pcibios_assign_resources+0x0/0x88 returned 0 after 148 msecs
calling  inet_init+0x0/0x1fb
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 6, 262144 bytes)
TCP established hash table entries: 131072 (order: 9, 2097152 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
initcall inet_init+0x0/0x1fb returned 0 after 72 msecs
calling  af_unix_init+0x0/0x55
NET: Registered protocol family 1
initcall af_unix_init+0x0/0x55 returned 0 after 3 msecs
calling  populate_rootfs+0x0/0x201
initcall populate_rootfs+0x0/0x201 returned 0 after 0 msecs
calling  pci_init+0x0/0x3a
pci 0000:00:00.0: Enabling HT MSI Mapping
pci 0000:00:0b.0: Enabling HT MSI Mapping
pci 0000:00:0b.0: Found enabled HT MSI Mapping
pci 0000:00:0c.0: Enabling HT MSI Mapping
pci 0000:00:0c.0: Found enabled HT MSI Mapping
pci 0000:00:0d.0: Enabling HT MSI Mapping
pci 0000:00:0d.0: Found enabled HT MSI Mapping
pci 0000:00:0e.0: Enabling HT MSI Mapping
pci 0000:00:0e.0: Found enabled HT MSI Mapping
pci 0000:01:00.0: Boot video device
initcall pci_init+0x0/0x3a returned 0 after 53 msecs
calling  i8259A_init_sysfs+0x0/0x22
calling  ehci_hcd_init+0x0/0x1b
ehci_hcd 0000:00:02.1: can't find IRQ for PCI INT B; probably buggy MP table
ehci_hcd 0000:00:02.1: Found HC with no IRQ.  Check BIOS/PCI 0000:00:02.1 setup!
ehci_hcd 0000:00:02.1: init 0000:00:02.1 fail, -19
initcall ehci_hcd_init+0x0/0x1b returned 0 after 15 msecs
calling  ohci_hcd_mod_init+0x0/0x6b
ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
ohci_hcd 0000:00:02.0: can't find IRQ for PCI INT A; probably buggy MP table
ohci_hcd 0000:00:02.0: Found HC with no IRQ.  Check BIOS/PCI 0000:00:02.0 setup!
ohci_hcd 0000:00:02.0: init 0000:00:02.0 fail, -19
initcall i8259A_init_sysfs+0x0/0x22 returned 0 after 41 msecs
calling  vsyscall_init+0x0/0x27
initcall vsyscall_init+0x0/0x27 returned 0 after 0 msecs
calling  sbf_init+0x0/0xd5
initcall sbf_init+0x0/0xd5 returned 0 after 0 msecs
calling  i8237A_init_sysfs+0x0/0x22
initcall ohci_hcd_mod_init+0x0/0x6b returned 0 after 38 msecs
calling  uhci_hcd_init+0x0/0xac
USB Universal Host Controller Interface driver v3.0
initcall i8237A_init_sysfs+0x0/0x22 returned 0 after 11 msecs
calling  add_rtc_cmos+0x0/0x14
PM: Adding info for platform:rtc_cmos
initcall uhci_hcd_init+0x0/0xac returned 0 after 15 msecs
initcall add_rtc_cmos+0x0/0x14 returned 0 after 7 msecs
calling  cache_sysfs_init+0x0/0x5c
initcall cache_sysfs_init+0x0/0x5c returned 0 after 0 msecs
calling  mce_init_device+0x0/0x78
PM: Adding info for No Bus:mcelog
initcall mce_init_device+0x0/0x78 returned 0 after 3 msecs
calling  periodic_mcheck_init+0x0/0x3f
initcall periodic_mcheck_init+0x0/0x3f returned 0 after 0 msecs
calling  thermal_throttle_init_device+0x0/0x68
initcall thermal_throttle_init_device+0x0/0x68 returned 0 after 0 msecs
calling  threshold_init_device+0x0/0x43
initcall threshold_init_device+0x0/0x43 returned 0 after 0 msecs
calling  msr_init+0x0/0xed
PM: Adding info for No Bus:msr0
PM: Adding info for No Bus:msr1
initcall msr_init+0x0/0xed returned 0 after 7 msecs
calling  cpuid_init+0x0/0xed
PM: Adding info for No Bus:cpu0
PM: Adding info for No Bus:cpu1
initcall cpuid_init+0x0/0xed returned 0 after 3 msecs
calling  init_lapic_sysfs+0x0/0x2d
initcall init_lapic_sysfs+0x0/0x2d returned 0 after 0 msecs
calling  ioapic_init_sysfs+0x0/0x99
initcall ioapic_init_sysfs+0x0/0x99 returned 0 after 0 msecs
calling  add_pcspkr+0x0/0x43
PM: Adding info for platform:pcspkr
initcall add_pcspkr+0x0/0x43 returned 0 after 3 msecs
calling  uv_ptc_init+0x0/0x75
initcall uv_ptc_init+0x0/0x75 returned 0 after 0 msecs
calling  uv_bau_init+0x0/0x58d
initcall uv_bau_init+0x0/0x58d returned 0 after 0 msecs
calling  audit_classes_init+0x0/0xaf
initcall audit_classes_init+0x0/0xaf returned 0 after 0 msecs
calling  init+0x0/0x12
initcall init+0x0/0x12 returned 0 after 0 msecs
calling  init_vdso_vars+0x0/0x1f7
initcall init_vdso_vars+0x0/0x1f7 returned 0 after 0 msecs
calling  sysenter_setup+0x0/0x296
initcall sysenter_setup+0x0/0x296 returned 0 after 0 msecs
calling  init_sched_debug_procfs+0x0/0x2c
initcall init_sched_debug_procfs+0x0/0x2c returned 0 after 0 msecs
calling  ioresources_init+0x0/0x3c
initcall ioresources_init+0x0/0x3c returned 0 after 0 msecs
calling  uid_cache_init+0x0/0x77
initcall uid_cache_init+0x0/0x77 returned 0 after 0 msecs
calling  init_posix_timers+0x0/0xb6
initcall init_posix_timers+0x0/0xb6 returned 0 after 0 msecs
calling  init_posix_cpu_timers+0x0/0xd4
initcall init_posix_cpu_timers+0x0/0xd4 returned 0 after 0 msecs
calling  nsproxy_cache_init+0x0/0x2d
initcall nsproxy_cache_init+0x0/0x2d returned 0 after 0 msecs
calling  create_proc_profile+0x0/0x241
initcall create_proc_profile+0x0/0x241 returned 0 after 0 msecs
calling  timekeeping_init_device+0x0/0x22
initcall timekeeping_init_device+0x0/0x22 returned 0 after 0 msecs
calling  init_clocksource_sysfs+0x0/0x50
initcall init_clocksource_sysfs+0x0/0x50 returned 0 after 0 msecs
calling  init_timer_list_procfs+0x0/0x2c
initcall init_timer_list_procfs+0x0/0x2c returned 0 after 0 msecs
calling  futex_init+0x0/0x6f
initcall futex_init+0x0/0x6f returned 0 after 0 msecs
calling  proc_dma_init+0x0/0x22
initcall proc_dma_init+0x0/0x22 returned 0 after 0 msecs
calling  percpu_modinit+0x0/0x74
initcall percpu_modinit+0x0/0x74 returned 0 after 0 msecs
calling  kallsyms_init+0x0/0x25
initcall kallsyms_init+0x0/0x25 returned 0 after 0 msecs
calling  snapshot_device_init+0x0/0x12
PM: Adding info for No Bus:snapshot
initcall snapshot_device_init+0x0/0x12 returned 0 after 3 msecs
calling  audit_init+0x0/0x126
audit: initializing netlink socket (disabled)
type=2000 audit(1218834701.408:1): initialized
initcall audit_init+0x0/0x126 returned 0 after 7 msecs
calling  init_kprobes+0x0/0x143
initcall init_kprobes+0x0/0x143 returned 0 after 7 msecs
calling  init_lstats_procfs+0x0/0x25
initcall init_lstats_procfs+0x0/0x25 returned 0 after 0 msecs
calling  init_sched_switch_trace+0x0/0x41
Testing tracer sched_switch: PASSED
initcall init_sched_switch_trace+0x0/0x41 returned 0 after 141 msecs
calling  init_stack_trace+0x0/0x12
Testing tracer sysprof: PASSED
initcall init_stack_trace+0x0/0x12 returned 0 after 106 msecs
calling  init_function_trace+0x0/0x12
Testing tracer ftrace: PASSED
Testing dynamic ftrace: PASSED
initcall init_function_trace+0x0/0x12 returned 0 after 415 msecs
calling  init_wakeup_tracer+0x0/0x12
Testing tracer wakeup: .. no entries found ..FAILED!
initcall init_wakeup_tracer+0x0/0x12 returned -1 after 213 msecs
initcall init_wakeup_tracer+0x0/0x12 returned with error code -1 
calling  init_per_zone_pages_min+0x0/0x45
initcall init_per_zone_pages_min+0x0/0x45 returned 0 after 0 msecs
calling  pdflush_init+0x0/0x1d
initcall pdflush_init+0x0/0x1d returned 0 after 0 msecs
calling  kswapd_init+0x0/0x68
initcall kswapd_init+0x0/0x68 returned 0 after 0 msecs
calling  setup_vmstat+0x0/0x44
initcall setup_vmstat+0x0/0x44 returned 0 after 0 msecs
calling  mm_sysfs_init+0x0/0x29
initcall mm_sysfs_init+0x0/0x29 returned 0 after 0 msecs
calling  procswaps_init+0x0/0x22
initcall procswaps_init+0x0/0x22 returned 0 after 0 msecs
calling  init_tmpfs+0x0/0x29
initcall init_tmpfs+0x0/0x29 returned 0 after 0 msecs
calling  slab_sysfs_init+0x0/0xf0
initcall slab_sysfs_init+0x0/0xf0 returned 0 after 11 msecs
calling  fasync_init+0x0/0x2a
initcall fasync_init+0x0/0x2a returned 0 after 0 msecs
calling  aio_setup+0x0/0x6e
initcall aio_setup+0x0/0x6e returned 0 after 0 msecs
calling  inotify_setup+0x0/0x12
initcall inotify_setup+0x0/0x12 returned 0 after 0 msecs
calling  inotify_user_setup+0x0/0xb8
initcall inotify_user_setup+0x0/0xb8 returned 0 after 0 msecs
calling  init_sys32_ioctl+0x0/0x85
initcall init_sys32_ioctl+0x0/0x85 returned 0 after 0 msecs
calling  init_mbcache+0x0/0x14
initcall init_mbcache+0x0/0x14 returned 0 after 0 msecs
calling  vmcore_init+0x0/0x8b5
initcall vmcore_init+0x0/0x8b5 returned 0 after 0 msecs
calling  configfs_init+0x0/0xb3
initcall configfs_init+0x0/0xb3 returned 0 after 0 msecs
calling  init_devpts_fs+0x0/0x3f
initcall init_devpts_fs+0x0/0x3f returned 0 after 0 msecs
calling  init_ext3_fs+0x0/0x6a
initcall init_ext3_fs+0x0/0x6a returned 0 after 0 msecs
calling  journal_init+0x0/0x85
initcall journal_init+0x0/0x85 returned 0 after 0 msecs
calling  init_ext2_fs+0x0/0x5a
initcall init_ext2_fs+0x0/0x5a returned 0 after 0 msecs
calling  init_ramfs_fs+0x0/0x12
initcall init_ramfs_fs+0x0/0x12 returned 0 after 0 msecs
calling  init_fat_fs+0x0/0x4f
initcall init_fat_fs+0x0/0x4f returned 0 after 0 msecs
calling  init_vfat_fs+0x0/0x12
initcall init_vfat_fs+0x0/0x12 returned 0 after 0 msecs
calling  init_nls_cp855+0x0/0x12
initcall init_nls_cp855+0x0/0x12 returned 0 after 0 msecs
calling  init_nls_cp860+0x0/0x12
initcall init_nls_cp860+0x0/0x12 returned 0 after 0 msecs
calling  init_nls_cp861+0x0/0x12
initcall init_nls_cp861+0x0/0x12 returned 0 after 0 msecs
calling  init_nls_cp862+0x0/0x12
initcall init_nls_cp862+0x0/0x12 returned 0 after 0 msecs
calling  init_nls_cp866+0x0/0x12
initcall init_nls_cp866+0x0/0x12 returned 0 after 0 msecs
calling  init_nls_cp869+0x0/0x12
initcall init_nls_cp869+0x0/0x12 returned 0 after 0 msecs
calling  init_nls_cp1251+0x0/0x12
initcall init_nls_cp1251+0x0/0x12 returned 0 after 0 msecs
calling  init_nls_ascii+0x0/0x12
initcall init_nls_ascii+0x0/0x12 returned 0 after 0 msecs
calling  init_nls_iso8859_1+0x0/0x12
initcall init_nls_iso8859_1+0x0/0x12 returned 0 after 0 msecs
calling  init_nls_iso8859_2+0x0/0x12
initcall init_nls_iso8859_2+0x0/0x12 returned 0 after 0 msecs
calling  init_nls_iso8859_4+0x0/0x12
initcall init_nls_iso8859_4+0x0/0x12 returned 0 after 0 msecs
calling  init_nls_iso8859_13+0x0/0x12
initcall init_nls_iso8859_13+0x0/0x12 returned 0 after 0 msecs
calling  init_nls_iso8859_15+0x0/0x12
initcall init_nls_iso8859_15+0x0/0x12 returned 0 after 0 msecs
calling  init_smb_fs+0x0/0x6c
initcall init_smb_fs+0x0/0x6c returned 0 after 0 msecs
calling  init_ncp_fs+0x0/0x5a
initcall init_ncp_fs+0x0/0x5a returned 0 after 0 msecs
calling  init_efs_fs+0x0/0x68
EFS: 1.0a - http://aeschi.ch.eu.org/efs/
initcall init_efs_fs+0x0/0x68 returned 0 after 3 msecs
calling  init_adfs_fs+0x0/0x5a
initcall init_adfs_fs+0x0/0x5a returned 0 after 0 msecs
calling  fuse_init+0x0/0x125
fuse init (API version 7.9)
PM: Adding info for No Bus:fuse
initcall fuse_init+0x0/0x125 returned 0 after 3 msecs
calling  init_befs_fs+0x0/0x7b
BeFS version: 0.9.3
initcall init_befs_fs+0x0/0x7b returned 0 after 3 msecs
calling  init_gfs2_fs+0x0/0x178
GFS2 (built Aug 15 2008 23:09:32) installed
initcall init_gfs2_fs+0x0/0x178 returned 0 after 3 msecs
calling  key_proc_init+0x0/0x33
initcall key_proc_init+0x0/0x33 returned 0 after 0 msecs
calling  crypto_algapi_init+0x0/0xd
initcall crypto_algapi_init+0x0/0xd returned 0 after 0 msecs
calling  blkcipher_module_init+0x0/0x2a
initcall blkcipher_module_init+0x0/0x2a returned 0 after 0 msecs
calling  seqiv_module_init+0x0/0x12
initcall seqiv_module_init+0x0/0x12 returned 0 after 0 msecs
calling  cryptomgr_init+0x0/0x12
initcall cryptomgr_init+0x0/0x12 returned 0 after 0 msecs
calling  hmac_module_init+0x0/0x12
initcall hmac_module_init+0x0/0x12 returned 0 after 0 msecs
calling  md5_mod_init+0x0/0x12
initcall md5_mod_init+0x0/0x12 returned 0 after 0 msecs
calling  rmd128_mod_init+0x0/0x12
initcall rmd128_mod_init+0x0/0x12 returned 0 after 0 msecs
calling  rmd160_mod_init+0x0/0x12
initcall rmd160_mod_init+0x0/0x12 returned 0 after 0 msecs
calling  sha1_generic_mod_init+0x0/0x12
initcall sha1_generic_mod_init+0x0/0x12 returned 0 after 0 msecs
calling  wp512_mod_init+0x0/0x64
initcall wp512_mod_init+0x0/0x64 returned 0 after 0 msecs
calling  tgr192_mod_init+0x0/0x64
initcall tgr192_mod_init+0x0/0x64 returned 0 after 0 msecs
calling  crypto_cbc_module_init+0x0/0x12
initcall crypto_cbc_module_init+0x0/0x12 returned 0 after 0 msecs
calling  crypto_ctr_module_init+0x0/0x3f
initcall crypto_ctr_module_init+0x0/0x3f returned 0 after 0 msecs
calling  des_generic_mod_init+0x0/0x3f
initcall des_generic_mod_init+0x0/0x3f returned 0 after 0 msecs
calling  fcrypt_mod_init+0x0/0x12
initcall fcrypt_mod_init+0x0/0x12 returned 0 after 0 msecs
calling  serpent_mod_init+0x0/0x3f
initcall serpent_mod_init+0x0/0x3f returned 0 after 0 msecs
calling  camellia_init+0x0/0x12
initcall camellia_init+0x0/0x12 returned 0 after 0 msecs
calling  arc4_init+0x0/0x12
initcall arc4_init+0x0/0x12 returned 0 after 0 msecs
calling  tea_mod_init+0x0/0x64
initcall tea_mod_init+0x0/0x64 returned 0 after 0 msecs
calling  deflate_mod_init+0x0/0x12
initcall deflate_mod_init+0x0/0x12 returned 0 after 0 msecs
calling  crc32c_mod_init+0x0/0x3f
initcall crc32c_mod_init+0x0/0x3f returned 0 after 0 msecs
calling  crypto_authenc_module_init+0x0/0x12
initcall crypto_authenc_module_init+0x0/0x12 returned 0 after 0 msecs
calling  bsg_init+0x0/0x126
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
initcall bsg_init+0x0/0x126 returned 0 after 3 msecs
calling  noop_init+0x0/0x14
io scheduler noop registered
initcall noop_init+0x0/0x14 returned 0 after 3 msecs
calling  as_init+0x0/0x14
io scheduler anticipatory registered (default)
initcall as_init+0x0/0x14 returned 0 after 3 msecs
calling  init_kmp+0x0/0x12
initcall init_kmp+0x0/0x12 returned 0 after 0 msecs
calling  init_bm+0x0/0x12
initcall init_bm+0x0/0x12 returned 0 after 0 msecs
calling  init_fsm+0x0/0x12
initcall init_fsm+0x0/0x12 returned 0 after 0 msecs
calling  percpu_counter_startup+0x0/0x14
initcall percpu_counter_startup+0x0/0x14 returned 0 after 0 msecs
calling  max732x_init+0x0/0x14
i2c-core: driver [max732x] registered
initcall max732x_init+0x0/0x14 returned 0 after 3 msecs
calling  pci_proc_init+0x0/0x6a
initcall pci_proc_init+0x0/0x6a returned 0 after 0 msecs
calling  pcie_portdrv_init+0x0/0x4c
pcieport-driver 0000:00:0b.0: setting latency timer to 64
pcieport-driver 0000:00:0b.0: found MSI capability
pci_express 0000:00:0b.0:pcie00: allocate port service
PM: Adding info for pci_express:0000:00:0b.0:pcie00
pcieport-driver 0000:00:0c.0: setting latency timer to 64
pcieport-driver 0000:00:0c.0: found MSI capability
pci_express 0000:00:0c.0:pcie00: allocate port service
PM: Adding info for pci_express:0000:00:0c.0:pcie00
pcieport-driver 0000:00:0d.0: setting latency timer to 64
pcieport-driver 0000:00:0d.0: found MSI capability
pci_express 0000:00:0d.0:pcie00: allocate port service
PM: Adding info for pci_express:0000:00:0d.0:pcie00
pcieport-driver 0000:00:0e.0: setting latency timer to 64
pcieport-driver 0000:00:0e.0: found MSI capability
pci_express 0000:00:0e.0:pcie00: allocate port service
PM: Adding info for pci_express:0000:00:0e.0:pcie00
initcall pcie_portdrv_init+0x0/0x4c returned 0 after 61 msecs
calling  aer_service_init+0x0/0x20
initcall aer_service_init+0x0/0x20 returned 0 after 0 msecs
calling  vgg2432a4_init+0x0/0x12
initcall vgg2432a4_init+0x0/0x12 returned 0 after 0 msecs
calling  display_class_init+0x0/0x7e
initcall display_class_init+0x0/0x7e returned 0 after 0 msecs
calling  rand_initialize+0x0/0x31
initcall rand_initialize+0x0/0x31 returned 0 after 0 msecs
calling  tty_init+0x0/0x1cd
PM: Adding info for No Bus:tty
PM: Adding info for No Bus:console
PM: Adding info for No Bus:ptmx
PM: Adding info for No Bus:tty0
PM: Adding info for No Bus:vcs
PM: Adding info for No Bus:vcsa
PM: Adding info for No Bus:tty1
PM: Adding info for No Bus:tty2
PM: Adding info for No Bus:tty3
PM: Adding info for No Bus:tty4
PM: Adding info for No Bus:tty5
PM: Adding info for No Bus:tty6
PM: Adding info for No Bus:tty7
PM: Adding info for No Bus:tty8
PM: Adding info for No Bus:tty9
PM: Adding info for No Bus:tty10
PM: Adding info for No Bus:tty11
PM: Adding info for No Bus:tty12
PM: Adding info for No Bus:tty13
PM: Adding info for No Bus:tty14
PM: Adding info for No Bus:tty15
PM: Adding info for No Bus:tty16
PM: Adding info for No Bus:tty17
PM: Adding info for No Bus:tty18
PM: Adding info for No Bus:tty19
PM: Adding info for No Bus:tty20
PM: Adding info for No Bus:tty21
PM: Adding info for No Bus:tty22
PM: Adding info for No Bus:tty23
PM: Adding info for No Bus:tty24
PM: Adding info for No Bus:tty25
PM: Adding info for No Bus:tty26
PM: Adding info for No Bus:tty27
PM: Adding info for No Bus:tty28
PM: Adding info for No Bus:tty29
PM: Adding info for No Bus:tty30
PM: Adding info for No Bus:tty31
PM: Adding info for No Bus:tty32
PM: Adding info for No Bus:tty33
PM: Adding info for No Bus:tty34
PM: Adding info for No Bus:tty35
PM: Adding info for No Bus:tty36
PM: Adding info for No Bus:tty37
PM: Adding info for No Bus:tty38
PM: Adding info for No Bus:tty39
PM: Adding info for No Bus:tty40
PM: Adding info for No Bus:tty41
PM: Adding info for No Bus:tty42
PM: Adding info for No Bus:tty43
PM: Adding info for No Bus:tty44
PM: Adding info for No Bus:tty45
PM: Adding info for No Bus:tty46
PM: Adding info for No Bus:tty47
PM: Adding info for No Bus:tty48
PM: Adding info for No Bus:tty49
PM: Adding info for No Bus:tty50
PM: Adding info for No Bus:tty51
PM: Adding info for No Bus:tty52
PM: Adding info for No Bus:tty53
PM: Adding info for No Bus:tty54
PM: Adding info for No Bus:tty55
PM: Adding info for No Bus:tty56
PM: Adding info for No Bus:tty57
PM: Adding info for No Bus:tty58
PM: Adding info for No Bus:tty59
PM: Adding info for No Bus:tty60
PM: Adding info for No Bus:tty61
PM: Adding info for No Bus:tty62
PM: Adding info for No Bus:tty63
initcall tty_init+0x0/0x1cd returned 0 after 202 msecs
calling  pty_init+0x0/0x26f
initcall pty_init+0x0/0x26f returned 0 after 0 msecs
calling  isicom_init+0x0/0x19d
initcall isicom_init+0x0/0x19d returned 0 after 0 msecs
calling  synclink_init+0x0/0x258
SyncLink serial driver $Revision: 4.38 $
PM: Adding info for No Bus:ttySL0
PM: Adding info for No Bus:ttySL1
PM: Adding info for No Bus:ttySL2
PM: Adding info for No Bus:ttySL3
PM: Adding info for No Bus:ttySL4
PM: Adding info for No Bus:ttySL5
PM: Adding info for No Bus:ttySL6
PM: Adding info for No Bus:ttySL7
PM: Adding info for No Bus:ttySL8
PM: Adding info for No Bus:ttySL9
PM: Adding info for No Bus:ttySL10
PM: Adding info for No Bus:ttySL11
PM: Adding info for No Bus:ttySL12
PM: Adding info for No Bus:ttySL13
PM: Adding info for No Bus:ttySL14
PM: Adding info for No Bus:ttySL15
PM: Adding info for No Bus:ttySL16
PM: Adding info for No Bus:ttySL17
PM: Adding info for No Bus:ttySL18
PM: Adding info for No Bus:ttySL19
PM: Adding info for No Bus:ttySL20
PM: Adding info for No Bus:ttySL21
PM: Adding info for No Bus:ttySL22
PM: Adding info for No Bus:ttySL23
PM: Adding info for No Bus:ttySL24
PM: Adding info for No Bus:ttySL25
PM: Adding info for No Bus:ttySL26
PM: Adding info for No Bus:ttySL27
PM: Adding info for No Bus:ttySL28
PM: Adding info for No Bus:ttySL29
PM: Adding info for No Bus:ttySL30
PM: Adding info for No Bus:ttySL31
PM: Adding info for No Bus:ttySL32
PM: Adding info for No Bus:ttySL33
PM: Adding info for No Bus:ttySL34
PM: Adding info for No Bus:ttySL35
PM: Adding info for No Bus:ttySL36
PM: Adding info for No Bus:ttySL37
PM: Adding info for No Bus:ttySL38
PM: Adding info for No Bus:ttySL39
PM: Adding info for No Bus:ttySL40
PM: Adding info for No Bus:ttySL41
PM: Adding info for No Bus:ttySL42
PM: Adding info for No Bus:ttySL43
PM: Adding info for No Bus:ttySL44
PM: Adding info for No Bus:ttySL45
PM: Adding info for No Bus:ttySL46
PM: Adding info for No Bus:ttySL47
PM: Adding info for No Bus:ttySL48
PM: Adding info for No Bus:ttySL49
PM: Adding info for No Bus:ttySL50
PM: Adding info for No Bus:ttySL51
PM: Adding info for No Bus:ttySL52
PM: Adding info for No Bus:ttySL53
PM: Adding info for No Bus:ttySL54
PM: Adding info for No Bus:ttySL55
PM: Adding info for No Bus:ttySL56
PM: Adding info for No Bus:ttySL57
PM: Adding info for No Bus:ttySL58
PM: Adding info for No Bus:ttySL59
PM: Adding info for No Bus:ttySL60
PM: Adding info for No Bus:ttySL61
PM: Adding info for No Bus:ttySL62
PM: Adding info for No Bus:ttySL63
PM: Adding info for No Bus:ttySL64
PM: Adding info for No Bus:ttySL65
PM: Adding info for No Bus:ttySL66
PM: Adding info for No Bus:ttySL67
PM: Adding info for No Bus:ttySL68
PM: Adding info for No Bus:ttySL69
PM: Adding info for No Bus:ttySL70
PM: Adding info for No Bus:ttySL71
PM: Adding info for No Bus:ttySL72
PM: Adding info for No Bus:ttySL73
PM: Adding info for No Bus:ttySL74
PM: Adding info for No Bus:ttySL75
PM: Adding info for No Bus:ttySL76
PM: Adding info for No Bus:ttySL77
PM: Adding info for No Bus:ttySL78
PM: Adding info for No Bus:ttySL79
PM: Adding info for No Bus:ttySL80
PM: Adding info for No Bus:ttySL81
PM: Adding info for No Bus:ttySL82
PM: Adding info for No Bus:ttySL83
PM: Adding info for No Bus:ttySL84
PM: Adding info for No Bus:ttySL85
PM: Adding info for No Bus:ttySL86
PM: Adding info for No Bus:ttySL87
PM: Adding info for No Bus:ttySL88
PM: Adding info for No Bus:ttySL89
PM: Adding info for No Bus:ttySL90
PM: Adding info for No Bus:ttySL91
PM: Adding info for No Bus:ttySL92
PM: Adding info for No Bus:ttySL93
PM: Adding info for No Bus:ttySL94
PM: Adding info for No Bus:ttySL95
PM: Adding info for No Bus:ttySL96
PM: Adding info for No Bus:ttySL97
PM: Adding info for No Bus:ttySL98
PM: Adding info for No Bus:ttySL99
PM: Adding info for No Bus:ttySL100
PM: Adding info for No Bus:ttySL101
PM: Adding info for No Bus:ttySL102
PM: Adding info for No Bus:ttySL103
PM: Adding info for No Bus:ttySL104
PM: Adding info for No Bus:ttySL105
PM: Adding info for No Bus:ttySL106
PM: Adding info for No Bus:ttySL107
PM: Adding info for No Bus:ttySL108
PM: Adding info for No Bus:ttySL109
PM: Adding info for No Bus:ttySL110
PM: Adding info for No Bus:ttySL111
PM: Adding info for No Bus:ttySL112
PM: Adding info for No Bus:ttySL113
PM: Adding info for No Bus:ttySL114
PM: Adding info for No Bus:ttySL115
PM: Adding info for No Bus:ttySL116
PM: Adding info for No Bus:ttySL117
PM: Adding info for No Bus:ttySL118
PM: Adding info for No Bus:ttySL119
PM: Adding info for No Bus:ttySL120
PM: Adding info for No Bus:ttySL121
PM: Adding info for No Bus:ttySL122
PM: Adding info for No Bus:ttySL123
PM: Adding info for No Bus:ttySL124
PM: Adding info for No Bus:ttySL125
PM: Adding info for No Bus:ttySL126
PM: Adding info for No Bus:ttySL127
SyncLink serial driver $Revision: 4.38 $, tty major#253
initcall synclink_init+0x0/0x258 returned 0 after 396 msecs
calling  n_hdlc_init+0x0/0x94
HDLC line discipline: version $Revision: 4.8 $, maxframe=4096
N_HDLC line discipline registered.
initcall n_hdlc_init+0x0/0x94 returned 0 after 7 msecs
calling  raw_init+0x0/0xdd
PM: Adding info for No Bus:rawctl
initcall raw_init+0x0/0xdd returned 0 after 3 msecs
calling  r3964_init+0x0/0x44
r3964: Philips r3964 Driver $Revision: 1.10 $
initcall r3964_init+0x0/0x44 returned 0 after 3 msecs
calling  nvram_init+0x0/0x8a
PM: Adding info for No Bus:nvram
Non-volatile memory driver v1.2
initcall nvram_init+0x0/0x8a returned 0 after 3 msecs
calling  i8k_init+0x0/0x1ef
initcall i8k_init+0x0/0x1ef returned -19 after 0 msecs
calling  serial8250_init+0x0/0x118
Serial: 8250/16550 driver4 ports, IRQ sharing disabled
PM: Adding info for platform:serial8250
serial8250: ttyS0 at I/O 0x3f8 (irq = 0) is a 16550A
PM: Adding info for No Bus:ttyS0
PM: Adding info for No Bus:ttyS1
PM: Adding info for No Bus:ttyS2
PM: Adding info for No Bus:ttyS3
initcall serial8250_init+0x0/0x118 returned 0 after 267 msecs
calling  serial8250_pci_init+0x0/0x1b
initcall serial8250_pci_init+0x0/0x1b returned 0 after 0 msecs
calling  jsm_init_module+0x0/0x48
initcall jsm_init_module+0x0/0x48 returned 0 after 0 msecs
calling  topology_sysfs_init+0x0/0x48
initcall topology_sysfs_init+0x0/0x48 returned 0 after 0 msecs
calling  brd_init+0x0/0x19c
PM: Adding info for No Bus:ram0
PM: Adding info for No Bus:1:0
PM: Adding info for No Bus:ram1
PM: Adding info for No Bus:1:1
PM: Adding info for No Bus:ram2
PM: Adding info for No Bus:1:2
PM: Adding info for No Bus:ram3
PM: Adding info for No Bus:1:3
PM: Adding info for No Bus:ram4
PM: Adding info for No Bus:1:4
PM: Adding info for No Bus:ram5
PM: Adding info for No Bus:1:5
PM: Adding info for No Bus:ram6
PM: Adding info for No Bus:1:6
PM: Adding info for No Bus:ram7
PM: Adding info for No Bus:1:7
PM: Adding info for No Bus:ram8
PM: Adding info for No Bus:1:8
PM: Adding info for No Bus:ram9
PM: Adding info for No Bus:1:9
PM: Adding info for No Bus:ram10
PM: Adding info for No Bus:1:10
PM: Adding info for No Bus:ram11
PM: Adding info for No Bus:1:11
PM: Adding info for No Bus:ram12
PM: Adding info for No Bus:1:12
PM: Adding info for No Bus:ram13
PM: Adding info for No Bus:1:13
PM: Adding info for No Bus:ram14
PM: Adding info for No Bus:1:14
PM: Adding info for No Bus:ram15
PM: Adding info for No Bus:1:15
brd: module loaded
initcall brd_init+0x0/0x19c returned 0 after 91 msecs
calling  cpqarray_init+0x0/0x264
Compaq SMART2 Driver (v 2.6.0)
initcall cpqarray_init+0x0/0x264 returned 0 after 3 msecs
calling  mm_init+0x0/0x17b
MM: desc_per_page = 128
initcall mm_init+0x0/0x17b returned 0 after 0 msecs
calling  nbd_init+0x0/0x2d5
nbd: registered device at major 43
PM: Adding info for No Bus:nbd0
PM: Adding info for No Bus:43:0
PM: Adding info for No Bus:nbd1
PM: Adding info for No Bus:43:1
PM: Adding info for No Bus:nbd2
PM: Adding info for No Bus:43:2
PM: Adding info for No Bus:nbd3
PM: Adding info for No Bus:43:3
PM: Adding info for No Bus:nbd4
PM: Adding info for No Bus:43:4
PM: Adding info for No Bus:nbd5
PM: Adding info for No Bus:43:5
PM: Adding info for No Bus:nbd6
PM: Adding info for No Bus:43:6
PM: Adding info for No Bus:nbd7
PM: Adding info for No Bus:43:7
PM: Adding info for No Bus:nbd8
PM: Adding info for No Bus:43:8
PM: Adding info for No Bus:nbd9
PM: Adding info for No Bus:43:9
PM: Adding info for No Bus:nbd10
PM: Adding info for No Bus:43:10
PM: Adding info for No Bus:nbd11
PM: Adding info for No Bus:43:11
PM: Adding info for No Bus:nbd12
PM: Adding info for No Bus:43:12
PM: Adding info for No Bus:nbd13
PM: Adding info for No Bus:43:13
PM: Adding info for No Bus:nbd14
PM: Adding info for No Bus:43:14
PM: Adding info for No Bus:nbd15
PM: Adding info for No Bus:43:15
initcall nbd_init+0x0/0x2d5 returned 0 after 99 msecs
calling  init+0x0/0x2a
initcall init+0x0/0x2a returned 0 after 0 msecs
calling  carm_init+0x0/0x1b
initcall carm_init+0x0/0x1b returned 0 after 0 msecs
calling  tifm_7xx1_init+0x0/0x1b
initcall tifm_7xx1_init+0x0/0x1b returned 0 after 0 msecs
calling  ioc4_init+0x0/0x20
initcall ioc4_init+0x0/0x20 returned 0 after 0 msecs
calling  pasic3_base_init+0x0/0x19
initcall pasic3_base_init+0x0/0x19 returned -19 after 0 msecs
calling  e1000_init_module+0x0/0x6b
e1000e: Intel(R) PRO/1000 Network Driver - 0.3.3.3-k2
e1000e: Copyright (c) 1999-2008 Intel Corporation.
initcall e1000_init_module+0x0/0x6b returned 0 after 7 msecs
calling  igb_init_module+0x0/0x56
Intel(R) Gigabit Ethernet Network Driver - version 1.2.45-k2
Copyright (c) 2008 Intel Corporation.
initcall igb_init_module+0x0/0x56 returned 0 after 7 msecs
calling  ixgbe_init_module+0x0/0x5a
ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver - version 1.3.18-k2
ixgbe: Copyright (c) 1999-2007 Intel Corporation.
initcall ixgbe_init_module+0x0/0x5a returned 0 after 11 msecs
calling  ipg_init_module+0x0/0x1b
initcall ipg_init_module+0x0/0x1b returned 0 after 0 msecs
calling  t1_init_module+0x0/0x1b
initcall t1_init_module+0x0/0x1b returned 0 after 0 msecs
calling  cxgb3_init_module+0x0/0x20
initcall cxgb3_init_module+0x0/0x20 returned 0 after 0 msecs
calling  bonding_init+0x0/0x8df
Ethernet Channel Bonding Driver: v3.3.0 (June 10, 2008)
bonding: Warning: either miimon or arp_interval and arp_ip_target module parameters must be specified, otherwise bonding will not detect link failures! see bonding.txt for details.
PM: Adding info for No Bus:bond0
initcall bonding_init+0x0/0x8df returned 0 after 11 msecs
calling  atl1_init_module+0x0/0x1b
initcall atl1_init_module+0x0/0x1b returned 0 after 0 msecs
calling  atl1e_init_module+0x0/0x1b
initcall atl1e_init_module+0x0/0x1b returned 0 after 0 msecs
calling  rr_init_module+0x0/0x1b
initcall rr_init_module+0x0/0x1b returned 0 after 0 msecs
calling  cas_init+0x0/0x3d
initcall cas_init+0x0/0x3d returned 0 after 0 msecs
calling  vortex_init+0x0/0xad
initcall vortex_init+0x0/0xad returned 0 after 0 msecs
calling  typhoon_init+0x0/0x1b
initcall typhoon_init+0x0/0x1b returned 0 after 0 msecs
calling  eepro100_init_module+0x0/0x1b
initcall eepro100_init_module+0x0/0x1b returned 0 after 0 msecs
calling  e100_init_module+0x0/0x5d
e100: Intel(R) PRO/100 Network Driver, 3.5.23-k4-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
initcall e100_init_module+0x0/0x5d returned 0 after 7 msecs
calling  sis900_init_module+0x0/0x1b
initcall sis900_init_module+0x0/0x1b returned 0 after 0 msecs
calling  tg3_init+0x0/0x1b
initcall tg3_init+0x0/0x1b returned 0 after 0 msecs
calling  bnx2x_init+0x0/0x1b
initcall bnx2x_init+0x0/0x1b returned 0 after 0 msecs
calling  skge_init_module+0x0/0x1b
initcall skge_init_module+0x0/0x1b returned 0 after 0 msecs
calling  velocity_init_module+0x0/0x3b
initcall velocity_init_module+0x0/0x3b returned 0 after 0 msecs
calling  vsc8244_init+0x0/0x12
initcall vsc8244_init+0x0/0x12 returned 0 after 0 msecs
calling  fixed_mdio_bus_init+0x0/0xa8
PM: Adding info for platform:Fixed MDIO bus.0
Fixed MDIO Bus: probed
initcall fixed_mdio_bus_init+0x0/0xa8 returned 0 after 7 msecs
calling  hamachi_init+0x0/0x1b
initcall hamachi_init+0x0/0x1b returned 0 after 0 msecs
calling  net_olddevs_init+0x0/0xa0
initcall net_olddevs_init+0x0/0xa0 returned 0 after 0 msecs
calling  hp100_module_init+0x0/0x1b
initcall hp100_module_init+0x0/0x1b returned 0 after 0 msecs
calling  init_nic+0x0/0x1b
forcedeth: Reverse Engineered nForce ethernet driver. Version 0.61.
forcedeth 0000:00:0a.0: setting latency timer to 64
PM: Adding info for No Bus:eth0
forcedeth 0000:00:0a.0: ifname eth0, PHY OUI 0x5043 @ 9, addr 00:13:d4:dc:41:12
forcedeth 0000:00:0a.0: highdma csum timirq gbit lnktim desc-v3
initcall init_nic+0x0/0x1b returned 0 after 514 msecs
calling  ql3xxx_init_module+0x0/0x1b
initcall ql3xxx_init_module+0x0/0x1b returned 0 after 3 msecs
calling  ppp_init+0x0/0xa3
PPP generic driver version 2.4.2
PM: Adding info for No Bus:ppp
initcall ppp_init+0x0/0xa3 returned 0 after 7 msecs
calling  deflate_init+0x0/0x3b
PPP Deflate Compression module registered
initcall deflate_init+0x0/0x3b returned 0 after 3 msecs
calling  pppox_init+0x0/0x12
NET: Registered protocol family 24
initcall pppox_init+0x0/0x12 returned 0 after 0 msecs
calling  pppoe_init+0x0/0x99
initcall pppoe_init+0x0/0x99 returned 0 after 0 msecs
calling  slip_init+0x0/0xb2
SLIP: version 0.8.4-NET3.019-NEWTTY (dynamic channels, max=256) (6 bit encapsulation enabled).
SLIP linefill/keepalive option.
initcall slip_init+0x0/0xb2 returned 0 after 7 msecs
calling  rtl8139_init_module+0x0/0x1b
8139too Fast Ethernet driver 0.9.28
PM: Adding info for No Bus:eth1
eth1: RealTek RTL8139 at 0xffffc20000004000, 00:c0:df:03:68:5d, IRQ 11
eth1:  Identified 8139 chip type 'RTL-8139B'
initcall rtl8139_init_module+0x0/0x1b returned 0 after 11 msecs
calling  eql_init_module+0x0/0x65
Equalizer2002: Simon Janes (simon@ncm.com) and David S. Miller (davem@redhat.com)
PM: Adding info for No Bus:eql
initcall eql_init_module+0x0/0x65 returned 0 after 7 msecs
calling  rio_init+0x0/0x1b
initcall rio_init+0x0/0x1b returned 0 after 0 msecs
calling  s2io_starter+0x0/0x1b
initcall s2io_starter+0x0/0x1b returned 0 after 0 msecs
calling  enc28j60_init+0x0/0x23
initcall enc28j60_init+0x0/0x23 returned 0 after 0 msecs
calling  strip_init_driver+0x0/0x6a
STRIP: Version 1.3A-STUART.CHESHIRE (unlimited channels)
initcall strip_init_driver+0x0/0x6a returned 0 after 3 msecs
calling  init_netconsole+0x0/0x238
console [netcon0] enabled
netconsole: network logging started
initcall init_netconsole+0x0/0x238 returned 0 after 3 msecs
calling  netxen_init_module+0x0/0x48
initcall netxen_init_module+0x0/0x48 returned 0 after 0 msecs
calling  init+0x0/0x12
initcall init+0x0/0x12 returned 0 after 0 msecs
calling  efx_init_module+0x0/0x8f
Solarflare NET driver v2.2
initcall efx_init_module+0x0/0x8f returned 0 after 3 msecs
calling  saa7146_vv_init_module+0x0/0x8
initcall saa7146_vv_init_module+0x0/0x8 returned 0 after 0 msecs
calling  videodev_init+0x0/0x84
Linux video capture interface: v2.00
initcall videodev_init+0x0/0x84 returned 0 after 3 msecs
calling  v4l2_i2c_drv_init+0x0/0xfd
i2c-core: driver [tvaudio'] registered
i2c-core: driver [tvaudio] registered
initcall v4l2_i2c_drv_init+0x0/0xfd returned 0 after 7 msecs
calling  init_saa_5246a+0x0/0x2c
SAA5246A (or compatible) Teletext decoder driver version 1.8
i2c-core: driver [SAA5246A] registered
initcall init_saa_5246a+0x0/0x2c returned 0 after 7 msecs
calling  init_saa_5249+0x0/0x2c
SAA5249 driver (SAA5249 interface) for VideoText version 1.8
i2c-core: driver [SAA5249] registered
initcall init_saa_5249+0x0/0x2c returned 0 after 7 msecs
calling  v4l2_i2c_drv_init+0x0/0xfe
i2c-core: driver [saa7115'] registered
i2c-core: driver [saa7115] registered
initcall v4l2_i2c_drv_init+0x0/0xfe returned 0 after 7 msecs
calling  v4l2_i2c_drv_init+0x0/0x74
i2c-core: driver [saa717x] registered
initcall v4l2_i2c_drv_init+0x0/0x74 returned 0 after 3 msecs
calling  v4l2_i2c_drv_init+0x0/0x77
i2c-core: driver [saa7127] registered
initcall v4l2_i2c_drv_init+0x0/0x77 returned 0 after 3 msecs
calling  adv7175_init+0x0/0x14
i2c-core: driver [adv7175] registered
initcall adv7175_init+0x0/0x14 returned 0 after 3 msecs
calling  cx8800_init+0x0/0x37
cx88/0: cx2388x v4l2 driver version 0.0.6 loaded
initcall cx8800_init+0x0/0x37 returned 0 after 3 msecs
calling  cx8802_init+0x0/0x37
cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.6 loaded
initcall cx8802_init+0x0/0x37 returned 0 after 3 msecs
calling  usbvision_init+0x0/0x105
usbcore: registered new interface driver usbvision
USBVision USB Video Device Driver for Linux : 0.9.9
initcall usbvision_init+0x0/0x105 returned 0 after 7 msecs
calling  tvp5150_init+0x0/0x14
i2c-core: driver [tvp5150] registered
initcall tvp5150_init+0x0/0x14 returned 0 after 3 msecs
calling  v4l2_i2c_drv_init+0x0/0xfe
i2c-core: driver [msp3400'] registered
i2c-core: driver [msp3400] registered
initcall v4l2_i2c_drv_init+0x0/0xfe returned 0 after 7 msecs
calling  v4l2_i2c_drv_init+0x0/0x77
i2c-core: driver [cs5345] registered
initcall v4l2_i2c_drv_init+0x0/0x77 returned 0 after 3 msecs
calling  v4l2_i2c_drv_init+0x0/0xfd
i2c-core: driver [cs53l32a'] registered
i2c-core: driver [cs53l32a] registered
initcall v4l2_i2c_drv_init+0x0/0xfd returned 0 after 7 msecs
calling  v4l2_i2c_drv_init+0x0/0x74
i2c-core: driver [m52790] registered
initcall v4l2_i2c_drv_init+0x0/0x74 returned 0 after 3 msecs
calling  v4l2_i2c_drv_init+0x0/0xfd
i2c-core: driver [wm8775'] registered
i2c-core: driver [wm8775] registered
initcall v4l2_i2c_drv_init+0x0/0xfd returned 0 after 7 msecs
calling  v4l2_i2c_drv_init+0x0/0x74
i2c-core: driver [wm8739] registered
initcall v4l2_i2c_drv_init+0x0/0x74 returned 0 after 3 msecs
calling  v4l2_i2c_drv_init+0x0/0x74
i2c-core: driver [vp27smpx] registered
initcall v4l2_i2c_drv_init+0x0/0x74 returned 0 after 3 msecs
calling  mxb_init_module+0x0/0x57
saa7146: register extension 'Multimedia eXtension Board'.
initcall mxb_init_module+0x0/0x57 returned 0 after 3 msecs
calling  tuner3036_init+0x0/0x14
i2c-core: driver [sab3036] registered
initcall tuner3036_init+0x0/0x14 returned 0 after 3 msecs
calling  v4l2_i2c_drv_init+0x0/0xfd
i2c-core: driver [tuner'] registered
i2c-core: driver [tuner] registered
initcall v4l2_i2c_drv_init+0x0/0xfd returned 0 after 7 msecs
calling  v4l2_i2c_drv_init+0x0/0xfe
i2c-core: driver [cx25840'] registered
i2c-core: driver [cx25840] registered
initcall v4l2_i2c_drv_init+0x0/0xfe returned 0 after 7 msecs
calling  v4l2_i2c_drv_init+0x0/0x74
i2c-core: driver [upd64031a] registered
initcall v4l2_i2c_drv_init+0x0/0x74 returned 0 after 3 msecs
calling  v4l2_i2c_drv_init+0x0/0x74
i2c-core: driver [upd64083] registered
initcall v4l2_i2c_drv_init+0x0/0x74 returned 0 after 3 msecs
calling  cafe_init+0x0/0x91
Marvell M88ALP01 'CAFE' Camera Controller version 2
initcall cafe_init+0x0/0x91 returned 0 after 3 msecs
calling  ov7670_mod_init+0x0/0x22
OmniVision ov7670 sensor driver, at your service
i2c-core: driver [ov7670] registered
initcall ov7670_mod_init+0x0/0x22 returned 0 after 7 msecs
calling  stk_camera_init+0x0/0x3a
usbcore: registered new interface driver stkwebcam
initcall stk_camera_init+0x0/0x3a returned 0 after 3 msecs
calling  sn9c102_module_init+0x0/0x5b
sn9c102: V4L2 driver for SN9C1xx PC Camera Controllers v1:1.47pre49
usbcore: registered new interface driver sn9c102
initcall sn9c102_module_init+0x0/0x5b returned 0 after 7 msecs
calling  et61x251_module_init+0x0/0x5a
et61x251: V4L2 driver for ET61X[12]51 PC Camera Controllers v1:1.09
usbcore: registered new interface driver et61x251
initcall et61x251_module_init+0x0/0x5a returned 0 after 7 msecs
calling  konicawc_init+0x0/0xb3
konicawc: Konica Webcam driver v1.4
usbcore: registered new interface driver konicawc
initcall konicawc_init+0x0/0xb3 returned 0 after 7 msecs
calling  usb_vicam_init+0x0/0x38
usbcore: registered new interface driver vicam
initcall usb_vicam_init+0x0/0x38 returned 0 after 3 msecs
calling  module_start+0x0/0xb6
ivtv:  Start initialization, version 1.3.0
ivtv:  End initialization
initcall module_start+0x0/0xb6 returned 0 after 7 msecs
calling  maxiradio_radio_init+0x0/0x1b
initcall maxiradio_radio_init+0x0/0x1b returned 0 after 0 msecs
calling  gemtek_pci_init_module+0x0/0x1b
initcall gemtek_pci_init_module+0x0/0x1b returned 0 after 0 msecs
calling  maestro_radio_init+0x0/0x38
initcall maestro_radio_init+0x0/0x38 returned 0 after 0 msecs
calling  dsbr100_init+0x0/0x34
usbcore: registered new interface driver dsbr100
dsbr100: v0.41:D-Link DSB-R100 USB FM radio driver
initcall dsbr100_init+0x0/0x34 returned 0 after 7 msecs
calling  spi_transport_init+0x0/0x2e
initcall spi_transport_init+0x0/0x2e returned 0 after 0 msecs
calling  fc_transport_init+0x0/0x4c
initcall fc_transport_init+0x0/0x4c returned 0 after 0 msecs
calling  iscsi_transport_init+0x0/0x148
Loading iSCSI transport class v2.0-870.
initcall iscsi_transport_init+0x0/0x148 returned 0 after 3 msecs
calling  sas_transport_init+0x0/0xbb
initcall sas_transport_init+0x0/0xbb returned 0 after 0 msecs
calling  ahc_linux_init+0x0/0x59
initcall ahc_linux_init+0x0/0x59 returned 0 after 0 msecs
calling  init_sd+0x0/0xef
Driver 'sd' needs updating - please use bus_type methods
initcall init_sd+0x0/0xef returned 0 after 3 msecs
calling  init_sr+0x0/0x49
Driver 'sr' needs updating - please use bus_type methods
initcall init_sr+0x0/0x49 returned 0 after 3 msecs
calling  ahci_init+0x0/0x1b
initcall ahci_init+0x0/0x1b returned 0 after 0 msecs
calling  piix_init+0x0/0x29
initcall piix_init+0x0/0x29 returned 0 after 0 msecs
calling  pdc_ata_init+0x0/0x1b
initcall pdc_ata_init+0x0/0x1b returned 0 after 0 msecs
calling  qs_ata_init+0x0/0x1b
initcall qs_ata_init+0x0/0x1b returned 0 after 0 msecs
calling  sil24_init+0x0/0x1b
initcall sil24_init+0x0/0x1b returned 0 after 0 msecs
calling  pdc_sata_init+0x0/0x1b
initcall pdc_sata_init+0x0/0x1b returned 0 after 0 msecs
calling  nv_init+0x0/0x1b
initcall nv_init+0x0/0x1b returned 0 after 0 msecs
calling  mv_init+0x0/0x48
initcall mv_init+0x0/0x48 returned 0 after 0 msecs
calling  inic_init+0x0/0x1b
initcall inic_init+0x0/0x1b returned 0 after 0 msecs
calling  ali_init+0x0/0x1b
initcall ali_init+0x0/0x1b returned 0 after 0 msecs
calling  amd_init+0x0/0x1b
pata_amd 0000:00:06.0: version 0.3.10
pata_amd 0000:00:06.0: setting latency timer to 64
scsi0 : pata_amd
PM: Adding info for No Bus:host0
PM: Adding info for No Bus:host0
scsi1 : pata_amd
PM: Adding info for No Bus:host1
PM: Adding info for No Bus:host1
ata1: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xf000 irq 14
ata2: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xf008 irq 15
ata1.00: ATA-6: HDS722525VLAT80, V36OA60A, max UDMA/100
ata1.00: 488397168 sectors, multi 1: LBA48 
ata1: nv_mode_filter: 0x3f39f&0x3f07f->0x3f01f, BIOS=0x3f000 (0xc60000c0) ACPI=0x0
ata1.00: configured for UDMA/100
ata2.01: ATAPI: DVDRW IDE 16X, VER A079, max UDMA/66
ata2: nv_mode_filter: 0x1f39f&0x707f->0x701f, BIOS=0x7000 (0xc60000c0) ACPI=0x0
ata2.01: configured for UDMA/33
isa bounce pool size: 16 pages
scsi 0:0:0:0: Direct-Access     ATA      HDS722525VLAT80  V36O PQ: 0 ANSI: 5
PM: Adding info for No Bus:target0:0:0
PM: Adding info for scsi:0:0:0:0
PM: Adding info for No Bus:0:0:0:0
sd 0:0:0:0: [sda] 488397168 512-byte hardware sectors (250059 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
PM: Adding info for No Bus:sda
sd 0:0:0:0: [sda] 488397168 512-byte hardware sectors (250059 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sda: sda1 sda2 sda3 < sda5 sda6 sda7 sda8 sda9 sda10 >
PM: Adding info for No Bus:sda1
PM: Adding info for No Bus:sda2
PM: Adding info for No Bus:sda3
PM: Adding info for No Bus:sda5
PM: Adding info for No Bus:sda6
PM: Adding info for No Bus:sda7
PM: Adding info for No Bus:sda8
PM: Adding info for No Bus:sda9
PM: Adding info for No Bus:sda10
PM: Adding info for No Bus:8:0
sd 0:0:0:0: [sda] Attached SCSI disk
PM: Adding info for No Bus:0:0:0:0
PM: Adding info for No Bus:0:0:0:0
scsi 1:0:1:0: CD-ROM            DVDRW    IDE 16X          A079 PQ: 0 ANSI: 5
PM: Adding info for No Bus:target1:0:1
PM: Adding info for scsi:1:0:1:0
sr0: scsi3-mmc drive: 1x/48x writer cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.20
PM: Adding info for No Bus:sr0
PM: Adding info for No Bus:11:0
sr 1:0:1:0: Attached scsi CD-ROM sr0
PM: Adding info for No Bus:1:0:1:0
PM: Adding info for No Bus:1:0:1:0
initcall amd_init+0x0/0x1b returned 0 after 656 msecs
calling  cs5520_init+0x0/0x1b
initcall cs5520_init+0x0/0x1b returned 0 after 0 msecs
calling  hpt3x3_init+0x0/0x1b
initcall hpt3x3_init+0x0/0x1b returned 0 after 0 msecs
calling  netcell_init+0x0/0x1b
initcall netcell_init+0x0/0x1b returned 0 after 0 msecs
calling  mpiix_init+0x0/0x1b
initcall mpiix_init+0x0/0x1b returned 0 after 0 msecs
calling  oldpiix_init+0x0/0x1b
initcall oldpiix_init+0x0/0x1b returned 0 after 0 msecs
calling  via_init+0x0/0x1b
initcall via_init+0x0/0x1b returned 0 after 0 msecs
calling  sl82c105_init+0x0/0x1b
initcall sl82c105_init+0x0/0x1b returned 0 after 0 msecs
calling  pata_platform_init+0x0/0x12
initcall pata_platform_init+0x0/0x12 returned 0 after 0 msecs
calling  fusion_init+0x0/0xf8
Fusion MPT base driver 3.04.07
Copyright (c) 1999-2008 LSI Corporation
initcall fusion_init+0x0/0xf8 returned 0 after 3 msecs
calling  mptspi_init+0x0/0xde
Fusion MPT SPI Host driver 3.04.07
initcall mptspi_init+0x0/0xde returned 0 after 3 msecs
calling  ieee1394_init+0x0/0x26c
initcall ieee1394_init+0x0/0x26c returned 0 after 0 msecs
calling  pcilynx_init+0x0/0x3c
initcall pcilynx_init+0x0/0x3c returned 0 after 0 msecs
calling  init_raw1394+0x0/0xf4
PM: Adding info for No Bus:raw1394
ieee1394: raw1394: /dev/raw1394 device initialized
initcall init_raw1394+0x0/0xf4 returned 0 after 7 msecs
calling  cdrom_init+0x0/0x8
initcall cdrom_init+0x0/0x8 returned 0 after 0 msecs
calling  at25_init+0x0/0x12
initcall at25_init+0x0/0x12 returned 0 after 0 msecs
calling  tle62x0_init+0x0/0x12
initcall tle62x0_init+0x0/0x12 returned 0 after 0 msecs
calling  aoe_init+0x0/0xa7
PM: Adding info for No Bus:err
PM: Adding info for No Bus:discover
PM: Adding info for No Bus:interfaces
PM: Adding info for No Bus:revalidate
PM: Adding info for No Bus:flush
aoe: AoE v47 initialised.
initcall aoe_init+0x0/0xa7 returned 0 after 19 msecs
calling  isp116x_init+0x0/0x3e
116x: driver isp116x-hcd, 03 Nov 2005
initcall isp116x_init+0x0/0x3e returned 0 after 3 msecs
calling  sl811h_init+0x0/0x3e
sl811: driver sl811-hcd, 19 May 2005
initcall sl811h_init+0x0/0x3e returned 0 after 0 msecs
calling  u132_hcd_init+0x0/0xa8
driver u132_hcd built at 23:10:19 on Aug 15 2008
initcall u132_hcd_init+0x0/0xa8 returned 0 after 3 msecs
calling  r8a66597_init+0x0/0x3e
r8a66597_hcd: driver r8a66597_hcd, 10 Apr 2008
initcall r8a66597_init+0x0/0x3e returned 0 after 3 msecs
calling  c67x00_init+0x0/0x12
initcall c67x00_init+0x0/0x12 returned 0 after 0 msecs
calling  usb_stor_init+0x0/0x50
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
initcall usb_stor_init+0x0/0x50 returned 0 after 11 msecs
calling  usb_usual_init+0x0/0x3e
usbcore: registered new interface driver libusual
initcall usb_usual_init+0x0/0x3e returned 0 after 3 msecs
calling  usb_serial_init+0x0/0x235
usbcore: registered new interface driver usbserial
usbserial: USB Serial support registered for generic
usbcore: registered new interface driver usbserial_generic
usbserial: USB Serial Driver core
initcall usb_serial_init+0x0/0x235 returned 0 after 11 msecs
calling  ch341_init+0x0/0x48
usbserial: USB Serial support registered for ch341-uart
usbcore: registered new interface driver ch341
initcall ch341_init+0x0/0x48 returned 0 after 7 msecs
calling  cyberjack_init+0x0/0x66
usbserial: USB Serial support registered for Reiner SCT Cyberjack USB card reader
usbcore: registered new interface driver cyberjack
cyberjack: v1.01 Matthias Bruestle
cyberjack: REINER SCT cyberJack pinpad/e-com USB Chipcard Reader Driver
initcall cyberjack_init+0x0/0x66 returned 0 after 15 msecs
calling  debug_init+0x0/0x48
usbserial: USB Serial support registered for debug
usbcore: registered new interface driver debug
initcall debug_init+0x0/0x48 returned 0 after 7 msecs
calling  digi_init+0x0/0x76
usbserial: USB Serial support registered for Digi 2 port USB adapter
usbserial: USB Serial support registered for Digi 4 port USB adapter
usbcore: registered new interface driver digi_acceleport
digi_acceleport: v1.80.1.2:Digi AccelePort USB-2/USB-4 Serial Converter driver
initcall digi_init+0x0/0x76 returned 0 after 15 msecs
calling  edgeport_init+0x0/0xc1
usbserial: USB Serial support registered for Edgeport 2 port adapter
usbserial: USB Serial support registered for Edgeport 4 port adapter
usbserial: USB Serial support registered for Edgeport 8 port adapter
usbserial: USB Serial support registered for EPiC device
usbcore: registered new interface driver io_edgeport
io_edgeport: Edgeport USB Serial Driver v2.7
initcall edgeport_init+0x0/0xc1 returned 0 after 22 msecs
calling  usb_ipw_init+0x0/0x5d
usbserial: USB Serial support registered for IPWireless converter
usbcore: registered new interface driver ipwtty
ipw: IPWireless tty driver v0.3
initcall usb_ipw_init+0x0/0x5d returned 0 after 7 msecs
calling  ir_init+0x0/0x58
usbserial: USB Serial support registered for IR Dongle
usbcore: registered new interface driver ir-usb
ir_usb: USB IR Dongle driver v0.4
initcall ir_init+0x0/0x58 returned 0 after 11 msecs
calling  mct_u232_init+0x0/0x58
usbserial: USB Serial support registered for MCT U232
usbcore: registered new interface driver mct_u232
mct_u232: Magic Control Technology USB-RS232 converter driver z2.1
initcall mct_u232_init+0x0/0x58 returned 0 after 11 msecs
calling  moto_init+0x0/0x48
usbserial: USB Serial support registered for moto-modem
usbcore: registered new interface driver moto-modem
initcall moto_init+0x0/0x48 returned 0 after 7 msecs
calling  omninet_init+0x0/0x58
usbserial: USB Serial support registered for ZyXEL - omni.net lcd plus usb
usbcore: registered new interface driver omninet
omninet: v1.1:USB ZyXEL omni.net LCD PLUS Driver
initcall omninet_init+0x0/0x58 returned 0 after 11 msecs
calling  option_init+0x0/0x58
usbserial: USB Serial support registered for GSM modem (1-port)
usbcore: registered new interface driver option
option: USB Driver for GSM modems: v0.7.2
initcall option_init+0x0/0x58 returned 0 after 11 msecs
calling  spcp8x5_init+0x0/0x58
usbserial: USB Serial support registered for SPCP8x5
usbcore: registered new interface driver spcp8x5
spcp8x5: SPCP8x5 USB to serial adaptor driver v0.04
initcall spcp8x5_init+0x0/0x58 returned 0 after 11 msecs
calling  whiteheat_init+0x0/0x77
usbserial: USB Serial support registered for Connect Tech - WhiteHEAT - (prerenumeration)
usbserial: USB Serial support registered for Connect Tech - WhiteHEAT
usbcore: registered new interface driver whiteheat
whiteheat: USB ConnectTech WhiteHEAT driver v2.0
initcall whiteheat_init+0x0/0x77 returned 0 after 15 msecs
calling  keyspan_pda_init+0x0/0x94
usbserial: USB Serial support registered for Keyspan PDA
usbserial: USB Serial support registered for Keyspan PDA - (prerenumeration)
usbserial: USB Serial support registered for Xircom / Entregra PGS - (prerenumeration)
usbcore: registered new interface driver keyspan_pda
keyspan_pda: USB Keyspan PDA Converter driver v1.1
initcall keyspan_pda_init+0x0/0x94 returned 0 after 19 msecs
calling  berry_init+0x0/0x1b
usbcore: registered new interface driver berry_charge
initcall berry_init+0x0/0x1b returned 0 after 3 msecs
calling  cypress_init+0x0/0x3a
usbcore: registered new interface driver cypress_cy7c63
initcall cypress_init+0x0/0x3a returned 0 after 3 msecs
calling  ftdi_elan_init+0x0/0x159
driver ftdi-elan built at 23:10:27 on Aug 15 2008
usbcore: registered new interface driver ftdi-elan
initcall ftdi_elan_init+0x0/0x159 returned 0 after 7 msecs
calling  usb_lcd_init+0x0/0x3a
usbcore: registered new interface driver usblcd
initcall usb_lcd_init+0x0/0x3a returned 0 after 3 msecs
calling  tv_init+0x0/0x4a
usbcore: registered new interface driver trancevibrator
trancevibrator: v1.1:PlayStation 2 Trance Vibrator driver
initcall tv_init+0x0/0x4a returned 0 after 7 msecs
calling  usb_sisusb_init+0x0/0x20
usbcore: registered new interface driver sisusb
initcall usb_sisusb_init+0x0/0x20 returned 0 after 3 msecs
calling  i8042_init+0x0/0xef
PM: Adding info for platform:i8042
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
initcall i8042_init+0x0/0xef returned 0 after 11 msecs
calling  serport_init+0x0/0x34
initcall serport_init+0x0/0x34<7>PM: Adding info for serio:serio0
 returned 0 after 0 msecs
calling  fm801_gp_init+0x0/0x1b
PM: Adding info for serio:serio1
initcall fm801_gp_init+0x0/0x1b returned 0 after 3 msecs
calling  ns558_init+0x0/0x2fa
initcall ns558_init+0x0/0x2fa returned -19 after 7 msecs
calling  mousedev_init+0x0/0x8e
PM: Adding info for No Bus:mice
PM: Adding info for No Bus:psaux
mice: PS/2 mouse device common for all mice
initcall mousedev_init+0x0/0x8e returned 0 after 7 msecs
calling  evdev_init+0x0/0x12
initcall evdev_init+0x0/0x12 returned 0 after 0 msecs
calling  atkbd_init+0x0/0x27
initcall atkbd_init+0x0/0x27 returned 0 after 0 msecs
calling  adi_init+0x0/0x16
initcall adi_init+0x0/0x16 returned 0 after 0 msecs
calling  analog_init+0x0/0xf1
initcall analog_init+0x0/0xf1 returned 0 after 0 msecs
calling  interact_init+0x0/0x16
initcall interact_init+0x0/0x16 returned 0 after 0 msecs
calling  spaceball_init+0x0/0x1b
PM: Adding info for No Bus:input0
input: AT Translated Set 2 keyboard as /class/input/input0
PM: Adding info for No Bus:event0
initcall spaceball_init+0x0/0x1b returned 0 after 41 msecs
calling  stinger_init+0x0/0x1b
initcall stinger_init+0x0/0x1b returned 0 after 0 msecs
calling  tmdc_init+0x0/0x16
initcall tmdc_init+0x0/0x16 returned 0 after 0 msecs
calling  zhenhua_init+0x0/0x1b
initcall zhenhua_init+0x0/0x1b returned 0 after 0 msecs
calling  usb_acecad_init+0x0/0x38
usbcore: registered new interface driver usb_acecad
acecad: v3.2:USB Acecad Flair tablet driver
initcall usb_acecad_init+0x0/0x38 returned 0 after 7 msecs
calling  gtco_init+0x0/0x51
usbcore: registered new interface driver gtco
GTCO usb driver version: 2.00.0006initcall gtco_init+0x0/0x51 returned 0 after 7 msecs
calling  wacom_init+0x0/0x44
usbcore: registered new interface driver wacom
wacom: v1.48:USB Wacom Graphire and Wacom Intuos tablet driver
initcall wacom_init+0x0/0x44 returned 0 after 7 msecs
calling  tr_init+0x0/0x1b
initcall tr_init+0x0/0x1b returned 0 after 0 msecs
calling  ali1563_init+0x0/0x1b
initcall ali1563_init+0x0/0x1b returned 0 after 0 msecs
calling  i2c_ali15x3_init+0x0/0x1b
initcall i2c_ali15x3_init+0x0/0x1b returned 0 after 0 msecs
calling  amd756_init+0x0/0x1b
initcall amd756_init+0x0/0x1b returned 0 after 0 msecs
calling  i2c_amd8111_init+0x0/0x1b
initcall i2c_amd8111_init+0x0/0x1b returned 0 after 0 msecs
calling  nforce2_init+0x0/0x1b
PM: Adding info for No Bus:i2c-0
i2c-adapter i2c-0: adapter [SMBus nForce2 adapter at 4c00] registered
i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x6a
i2c-adapter i2c-0: Transaction failed (0x10)!
i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x6b
i2c-adapter i2c-0: Transaction failed (0x10)!
i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x2a
i2c-adapter i2c-0: Transaction failed (0x10)!
i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x2b
i2c-adapter i2c-0: Transaction failed (0x10)!
i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x5c
i2c-adapter i2c-0: Transaction failed (0x10)!
i2c-adapter i2c-0: found normal entry for adapter 0, addr 0x5d
i2c-adapter i2c-0: Transaction failed (0x10)!
i2c-adapter i2c-0: nForce2 SMBus adapter at 0x4c00
PM: Adding info for No Bus:i2c-1
i2c-adapter i2c-1: adapter [SMBus nForce2 adapter at 4c40] registered
i2c-adapter i2c-1: found normal entry for adapter 1, addr 0x6a
i2c-adapter i2c-1: Transaction failed (0x10)!
i2c-adapter i2c-1: found normal entry for adapter 1, addr 0x6b
i2c-adapter i2c-1: Transaction failed (0x10)!
i2c-adapter i2c-1: found normal entry for adapter 1, addr 0x2a
i2c-adapter i2c-1: Transaction failed (0x10)!
i2c-adapter i2c-1: found normal entry for adapter 1, addr 0x2b
i2c-adapter i2c-1: Transaction failed (0x10)!
i2c-adapter i2c-1: found normal entry for adapter 1, addr 0x5c
i2c-adapter i2c-1: Transaction failed (0x10)!
i2c-adapter i2c-1: found normal entry for adapter 1, addr 0x5d
i2c-adapter i2c-1: Transaction failed (0x10)!
i2c-adapter i2c-1: nForce2 SMBus adapter at 0x4c40
initcall nforce2_init+0x0/0x1b returned 0 after 247 msecs
calling  i2c_piix4_init+0x0/0x1b
initcall i2c_piix4_init+0x0/0x1b returned 0 after 0 msecs
calling  i2c_vt596_init+0x0/0x1b
initcall i2c_vt596_init+0x0/0x1b returned 0 after 0 msecs
calling  i2c_adap_simtec_init+0x0/0x12
initcall i2c_adap_simtec_init+0x0/0x12 returned 0 after 0 msecs
calling  i2c_pca_pf_init+0x0/0x12
initcall i2c_pca_pf_init+0x0/0x12 returned 0 after 0 msecs
calling  ds1682_init+0x0/0x14
i2c-core: driver [ds1682] registered
initcall ds1682_init+0x0/0x14 returned 0 after 3 msecs
calling  pcf8574_init+0x0/0x14
i2c-core: driver [pcf8574] registered
initcall pcf8574_init+0x0/0x14 returned 0 after 3 msecs
calling  isdn_init+0x0/0x2fd
ISDN subsystem Rev: 1.1.2.3/1.1.2.3/1.1.2.2/1.1.2.3/1.1.2.2/1.1.2.2
initcall isdn_init+0x0/0x2fd returned 0 after 7 msecs
calling  divert_init+0x0/0x64
dss1_divert module successfully installed
initcall divert_init+0x0/0x64 returned 0 after 3 msecs
calling  gigaset_init_module+0x0/0x37
gigaset: Hansjoerg Lipp <hjlipp@web.de>, Tilman Schmidt <tilman@imap.cc>, Stefan Eilers
gigaset: Driver for Gigaset 307x
initcall gigaset_init_module+0x0/0x37 returned 0 after 7 msecs
calling  bas_gigaset_init+0x0/0xa5
usbcore: registered new interface driver bas_gigaset
bas_gigaset: Tilman Schmidt <tilman@imap.cc>, Hansjoerg Lipp <hjlipp@web.de>, Stefan Eilers
bas_gigaset: USB Driver for Gigaset 307x
initcall bas_gigaset_init+0x0/0xa5 returned 0 after 11 msecs
calling  cpufreq_stats_init+0x0/0x89
initcall cpufreq_stats_init+0x0/0x89 returned 0 after 0 msecs
calling  cpufreq_gov_userspace_init+0x0/0x12
initcall cpufreq_gov_userspace_init+0x0/0x12 returned 0 after 0 msecs
calling  cpufreq_gov_dbs_init+0x0/0x12
initcall cpufreq_gov_dbs_init+0x0/0x12 returned 0 after 0 msecs
calling  init_ladder+0x0/0x12
cpuidle: using governor ladder
initcall init_ladder+0x0/0x12 returned 0 after 3 msecs
calling  gpio_led_init+0x0/0x12
initcall gpio_led_init+0x0/0x12 returned 0 after 0 msecs
calling  heartbeat_trig_init+0x0/0x12
initcall heartbeat_trig_init+0x0/0x12 returned 0 after 0 msecs
calling  hid_init+0x0/0xb
initcall hid_init+0x0/0xb returned 0 after 0 msecs
calling  hid_init+0x0/0x62
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
usbhid: v2.6:USB HID core driver
initcall hid_init+0x0/0x62 returned 0 after 11 msecs
calling  usb_mouse_init+0x0/0x38
usbcore: registered new interface driver usbmouse
usbmouse: v1.6:USB HID Boot Protocol mouse driver
initcall usb_mouse_init+0x0/0x38 returned 0 after 7 msecs
calling  virtio_pci_init+0x0/0x48
PM: Adding info for No Bus:virtio-pci
initcall virtio_pci_init+0x0/0x48 returned 0 after 3 msecs
calling  init+0x0/0x12
initcall init+0x0/0x12 returned 0 after 0 msecs
calling  init_soundcore+0x0/0x60
initcall init_soundcore+0x0/0x60 returned 0 after 0 msecs
calling  alsa_sound_init+0x0/0x93
Advanced Linux Sound Architecture Driver Version 1.0.17.
initcall alsa_sound_init+0x0/0x93 returned 0 after 3 msecs
calling  alsa_sound_last_init+0x0/0x61
ALSA device list:
  No soundcards found.
initcall alsa_sound_last_init+0x0/0x61 returned 0 after 3 msecs
calling  flow_cache_init+0x0/0x1b8
initcall flow_cache_init+0x0/0x1b8 returned 0 after 0 msecs
calling  pg_init+0x0/0x304
pktgen v2.70: Packet Generator for packet performance testing.
initcall pg_init+0x0/0x304 returned 0 after 3 msecs
calling  llc_init+0x0/0x20
initcall llc_init+0x0/0x20 returned 0 after 0 msecs
calling  llc2_init+0x0/0xaa
NET: Registered protocol family 26
initcall llc2_init+0x0/0xaa returned 0 after 7 msecs
calling  snap_init+0x0/0x31
initcall snap_init+0x0/0x31 returned 0 after 0 msecs
calling  rif_init+0x0/0x70
initcall rif_init+0x0/0x70 returned 0 after 0 msecs
calling  blackhole_module_init+0x0/0x12
initcall blackhole_module_init+0x0/0x12 returned 0 after 0 msecs
calling  mirred_init_module+0x0/0x20
Mirror/redirect action on
initcall mirred_init_module+0x0/0x20 returned 0 after 3 msecs
calling  cbq_module_init+0x0/0x12
initcall cbq_module_init+0x0/0x12 returned 0 after 0 msecs
calling  red_module_init+0x0/0x12
initcall red_module_init+0x0/0x12 returned 0 after 0 msecs
calling  ingress_module_init+0x0/0x12
initcall ingress_module_init+0x0/0x12 returned 0 after 0 msecs
calling  tbf_module_init+0x0/0x12
initcall tbf_module_init+0x0/0x12 returned 0 after 0 msecs
calling  init_route4+0x0/0x12
initcall init_route4+0x0/0x12 returned 0 after 0 msecs
calling  init_fw+0x0/0x12
initcall init_fw+0x0/0x12 returned 0 after 0 msecs
calling  init_rsvp+0x0/0x12
initcall init_rsvp+0x0/0x12 returned 0 after 0 msecs
calling  init_rsvp+0x0/0x12
initcall init_rsvp+0x0/0x12 returned 0 after 0 msecs
calling  cls_flow_init+0x0/0x12
initcall cls_flow_init+0x0/0x12 returned 0 after 0 msecs
calling  nfnetlink_init+0x0/0x5d
Netfilter messages via NETLINK v0.30.
initcall nfnetlink_init+0x0/0x5d returned 0 after 3 msecs
calling  nfnetlink_queue_init+0x0/0xa2
initcall nfnetlink_queue_init+0x0/0xa2 returned 0 after 0 msecs
calling  nf_conntrack_standalone_init+0x0/0x7d
nf_conntrack version 0.5.0 (8192 buckets, 32768 max)
CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Plase use
nf_conntrack.acct=1 kernel paramater, acct=1 nf_conntrack module option or
sysctl net.netfilter.nf_conntrack_acct=1 to enable it.
initcall nf_conntrack_standalone_init+0x0/0x7d returned 0 after 15 msecs
calling  nf_ct_proto_gre_init+0x0/0x12
initcall nf_ct_proto_gre_init+0x0/0x12 returned 0 after 0 msecs
calling  nf_conntrack_proto_udplite_init+0x0/0x43
initcall nf_conntrack_proto_udplite_init+0x0/0x43 returned 0 after 0 msecs
calling  nf_conntrack_amanda_init+0x0/0xa6
initcall nf_conntrack_amanda_init+0x0/0xa6 returned 0 after 0 msecs
calling  nf_conntrack_ftp_init+0x0/0x1a0
initcall nf_conntrack_ftp_init+0x0/0x1a0 returned 0 after 0 msecs
calling  nf_conntrack_pptp_init+0x0/0x12
initcall nf_conntrack_pptp_init+0x0/0x12 returned 0 after 0 msecs
calling  nf_conntrack_sip_init+0x0/0x18c
initcall nf_conntrack_sip_init+0x0/0x18c returned 0 after 0 msecs
calling  xt_init+0x0/0xca
initcall xt_init+0x0/0xca returned 0 after 0 msecs
calling  tcpudp_mt_init+0x0/0x17
initcall tcpudp_mt_init+0x0/0x17 returned 0 after 0 msecs
calling  classify_tg_init+0x0/0x17
initcall classify_tg_init+0x0/0x17 returned 0 after 0 msecs
calling  nflog_tg_init+0x0/0x17
initcall nflog_tg_init+0x0/0x17 returned 0 after 0 msecs
calling  connmark_mt_init+0x0/0x17
initcall connmark_mt_init+0x0/0x17 returned 0 after 0 msecs
calling  dscp_mt_init+0x0/0x17
initcall dscp_mt_init+0x0/0x17 returned 0 after 0 msecs
calling  length_mt_init+0x0/0x17
initcall length_mt_init+0x0/0x17 returned 0 after 0 msecs
calling  limit_mt_init+0x0/0x17
initcall limit_mt_init+0x0/0x17 returned 0 after 0 msecs
calling  policy_mt_init+0x0/0x17
initcall policy_mt_init+0x0/0x17 returned 0 after 0 msecs
calling  quota_mt_init+0x0/0x17
initcall quota_mt_init+0x0/0x17 returned 0 after 0 msecs
calling  sctp_mt_init+0x0/0x17
initcall sctp_mt_init+0x0/0x17 returned 0 after 0 msecs
calling  statistic_mt_init+0x0/0x17
initcall statistic_mt_init+0x0/0x17 returned 0 after 0 msecs
calling  string_mt_init+0x0/0x17
initcall string_mt_init+0x0/0x17 returned 0 after 0 msecs
calling  tcpmss_mt_init+0x0/0x17
initcall tcpmss_mt_init+0x0/0x17 returned 0 after 0 msecs
calling  time_mt_init+0x0/0x17
initcall time_mt_init+0x0/0x17 returned 0 after 0 msecs
calling  ipgre_init+0x0/0x71
GRE over IPv4 tunneling driver
PM: Adding info for No Bus:gre0
initcall ipgre_init+0x0/0x71 returned 0 after 3 msecs
calling  esp4_init+0x0/0x68
initcall esp4_init+0x0/0x68 returned 0 after 0 msecs
calling  ipv4_netfilter_init+0x0/0x17
initcall ipv4_netfilter_init+0x0/0x17 returned 0 after 0 msecs
calling  ip_queue_init+0x0/0x114
initcall ip_queue_init+0x0/0x114 returned 0 after 0 msecs
calling  inet_diag_init+0x0/0x69
initcall inet_diag_init+0x0/0x69 returned 0 after 0 msecs
calling  tcp_diag_init+0x0/0x12
initcall tcp_diag_init+0x0/0x12 returned 0 after 0 msecs
calling  bictcp_register+0x0/0x12
TCP bic registered
initcall bictcp_register+0x0/0x12 returned 0 after 3 msecs
calling  tcp_westwood_register+0x0/0x12
TCP westwood registered
initcall tcp_westwood_register+0x0/0x12 returned 0 after 0 msecs
calling  hybla_register+0x0/0x12
TCP hybla registered
initcall hybla_register+0x0/0x12 returned 0 after 0 msecs
calling  tcp_vegas_register+0x0/0x14
TCP vegas registered
initcall tcp_vegas_register+0x0/0x14 returned 0 after 3 msecs
calling  tcp_scalable_register+0x0/0x12
TCP scalable registered
initcall tcp_scalable_register+0x0/0x12 returned 0 after 3 msecs
calling  packet_init+0x0/0x47
NET: Registered protocol family 17
initcall packet_init+0x0/0x47 returned 0 after 0 msecs
calling  atalk_init+0x0/0x88
NET: Registered protocol family 5
initcall atalk_init+0x0/0x88 returned 0 after 30 msecs
calling  x25_init+0x0/0x5a
NET: Registered protocol family 9
X.25 for Linux Version 0.2
initcall x25_init+0x0/0x5a returned 0 after 7 msecs
calling  lapb_init+0x0/0x8
initcall lapb_init+0x0/0x8 returned 0 after 0 msecs
calling  vlan_proto_init+0x0/0xc7
802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
All bugs added by David S. Miller <davem@redhat.com>
initcall vlan_proto_init+0x0/0xc7 returned 0 after 7 msecs
calling  powernowk8_init+0x0/0xd9
powernow-k8: Found 1 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ processors (2 cpu cores) (version 2.20.00)
powernow-k8: ACPI Processor support is required for SMP systems but is absent. Please load the ACPI Processor module before starting this driver.
powernow-k8: ACPI Processor support is required for SMP systems but is absent. Please load the ACPI Processor module before starting this driver.
initcall powernowk8_init+0x0/0xd9 returned -19 after 15 msecs
calling  update_mp_table+0x0/0x476
initcall update_mp_table+0x0/0x476 returned 0 after 0 msecs
calling  lapic_insert_resource+0x0/0x40
initcall lapic_insert_resource+0x0/0x40 returned 0 after 0 msecs
calling  init_lapic_nmi_sysfs+0x0/0x38
initcall init_lapic_nmi_sysfs+0x0/0x38 returned 0 after 0 msecs
calling  ioapic_insert_resources+0x0/0x4f
initcall ioapic_insert_resources+0x0/0x4f returned 0 after 0 msecs
calling  check_early_ioremap_leak+0x0/0x22
initcall check_early_ioremap_leak+0x0/0x22 returned 0 after 0 msecs
calling  pat_memtype_list_init+0x0/0x29
initcall pat_memtype_list_init+0x0/0x29 returned 0 after 3 msecs
calling  sched_init_debug+0x0/0x24
initcall sched_init_debug+0x0/0x24 returned 0 after 0 msecs
calling  init_oops_id+0x0/0x28
initcall init_oops_id+0x0/0x28 returned 0 after 0 msecs
calling  disable_boot_consoles+0x0/0x3a
initcall disable_boot_consoles+0x0/0x3a returned 0 after 0 msecs
calling  pm_qos_power_init+0x0/0x61
PM: Adding info for No Bus:cpu_dma_latency
PM: Adding info for No Bus:network_latency
PM: Adding info for No Bus:network_throughput
initcall pm_qos_power_init+0x0/0x61 returned 0 after 11 msecs
calling  software_resume+0x0/0x1b8
initcall software_resume+0x0/0x1b8 returned -2 after 0 msecs
initcall software_resume+0x0/0x1b8 returned with error code -2 
calling  debugfs_kprobe_init+0x0/0x89
initcall debugfs_kprobe_init+0x0/0x89 returned 0 after 0 msecs
calling  taskstats_init+0x0/0x95
registered taskstats version 1
initcall taskstats_init+0x0/0x95 returned 0 after 3 msecs
calling  random32_reseed+0x0/0x9e
initcall random32_reseed+0x0/0x9e returned 0 after 0 msecs
calling  pci_sysfs_init+0x0/0x4c
initcall pci_sysfs_init+0x0/0x4c returned 0 after 0 msecs
calling  seqgen_init+0x0/0xf
initcall seqgen_init+0x0/0xf returned 0 after 0 msecs
calling  late_resume_init+0x0/0xf2
  Magic number: 4:982:196
initcall late_resume_init+0x0/0xf2 returned 0 after 0 msecs
calling  hd_init+0x0/0x2fe
hd: no drives specified - use hd=cyl,head,sectors on kernel command line
initcall hd_init+0x0/0x2fe returned -1 after 3 msecs
initcall hd_init+0x0/0x2fe returned with error code -1 
calling  scsi_complete_async_scans+0x0/0x129
initcall scsi_complete_async_scans+0x0/0x129 returned 0 after 0 msecs
calling  memmap_init+0x0/0x90
initcall memmap_init+0x0/0x90 returned 0 after 0 msecs
calling  tcp_congestion_default+0x0/0x12
initcall tcp_congestion_default+0x0/0x12 returned 0 after 0 msecs
calling  ip_auto_config+0x0/0xce7
initcall ip_auto_config+0x0/0xce7 returned 0 after 0 msecs
EXT3-fs: INFO: recovery required on readonly filesystem.
EXT3-fs: write access will be enabled during recovery.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 1128k freed
PM: Adding info for No Bus:vcs1
PM: Adding info for No Bus:vcsa1
PM: Removing info for No Bus:vcs1
PM: Removing info for No Bus:vcsa1
PM: Adding info for No Bus:vcs1
PM: Adding info for No Bus:vcsa1
PM: Removing info for No Bus:vcs1
PM: Removing info for No Bus:vcsa1
PM: Adding info for No Bus:vcs1
PM: Adding info for No Bus:vcsa1
PM: Removing info for No Bus:vcs1
PM: Removing info for No Bus:vcsa1
PM: Adding info for No Bus:vcs1
PM: Adding info for No Bus:vcsa1
PM: Removing info for No Bus:vcs1
PM: Removing info for No Bus:vcsa1
PM: Adding info for No Bus:vcs1
PM: Adding info for No Bus:vcsa1
PM: Removing info for No Bus:vcs1
PM: Removing info for No Bus:vcsa1
PM: Adding info for No Bus:vcs1
PM: Adding info for No Bus:vcsa1
udev: renamed network interface eth0 to eth1
udev: renamed network interface eth1_rename to eth0
eth0: link down
EXT3 FS on sda6, internal journal
kjournald starting.  Commit interval 5 seconds
EXT3 FS on sda5, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
Adding 3911816k swap on /dev/sda2.  Priority:-1 extents:1 across:3911816k
PM: Removing info for No Bus:vcs1
PM: Removing info for No Bus:vcsa1
PM: Adding info for No Bus:vcs1
PM: Adding info for No Bus:vcsa1
PM: Removing info for No Bus:vcs1
PM: Removing info for No Bus:vcsa1
PM: Adding info for No Bus:vcs1
PM: Adding info for No Bus:vcsa1
PM: Removing info for No Bus:vcs1
PM: Removing info for No Bus:vcsa1
PM: Adding info for No Bus:vcs1
PM: Adding info for No Bus:vcsa1
PM: Removing info for No Bus:vcs1
PM: Removing info for No Bus:vcsa1
PM: Adding info for No Bus:vcs1
PM: Adding info for No Bus:vcsa1
warning: `sudo' uses 32-bit capabilities (legacy support in use)
PM: Adding info for No Bus:vcs4
PM: Adding info for No Bus:vcsa4
PM: Removing info for No Bus:vcs4
PM: Removing info for No Bus:vcsa4
PM: Adding info for No Bus:vcs4
PM: Adding info for No Bus:vcsa4
PM: Adding info for No Bus:vcs3
PM: Adding info for No Bus:vcsa3
PM: Removing info for No Bus:vcs3
PM: Removing info for No Bus:vcsa3
PM: Adding info for No Bus:vcs3
PM: Adding info for No Bus:vcsa3
PM: Adding info for No Bus:vcs6
PM: Adding info for No Bus:vcsa6
PM: Adding info for No Bus:vcs2
PM: Adding info for No Bus:vcsa2
PM: Adding info for No Bus:vcs5
PM: Adding info for No Bus:vcsa5
PM: Removing info for No Bus:vcs6
PM: Removing info for No Bus:vcsa6
PM: Adding info for No Bus:vcs6
PM: Adding info for No Bus:vcsa6
PM: Removing info for No Bus:vcs2
PM: Removing info for No Bus:vcsa2
PM: Removing info for No Bus:vcs5
PM: Removing info for No Bus:vcsa5
PM: Adding info for No Bus:vcs5
PM: Adding info for No Bus:vcsa5
PM: Adding info for No Bus:vcs2
PM: Adding info for No Bus:vcsa2
PM: Adding info for No Bus:vcs7
PM: Adding info for No Bus:vcsa7
PM: Removing info for No Bus:vcs7
PM: Removing info for No Bus:vcsa7
eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.
PM: Adding info for No Bus:vcs7
PM: Adding info for No Bus:vcsa7
eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.
PM: Removing info for No Bus:vcs7
PM: Removing info for No Bus:vcsa7
eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.
PM: Adding info for No Bus:vcs7
PM: Adding info for No Bus:vcsa7
eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.
PM: Removing info for No Bus:vcs7
PM: Removing info for No Bus:vcsa7
PM: Adding info for No Bus:vcs7
PM: Adding info for No Bus:vcsa7
eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.
eth1: too many iterations (6) in nv_nic_irq.
---------------------->
00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3)
00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2)
00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2)
00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3)
00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio Controller (rev a2)
00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2)
00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2)
00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
00:0b.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:0c.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
01:00.0 VGA compatible controller: ATI Technologies Inc RV370 5B60 [Radeon X300 (PCIE)]
01:00.1 Display controller: ATI Technologies Inc RV370 [Radeon X300SE]
05:07.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)

Re: [PATCH]: PCI: GART iommu alignment fixes [v2]

[FUJITA Tomonori]

On Fri, 15 Aug 2008 20:00:48 +0200
Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Ingo Molnar <mingo@elte.hu> wrote:
> 
> > 
> > * FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:
> > 
> > > From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
> > > Subject: [PATCH] x86 gart: allocate size-aligned address for alloc_coherent
> > > 
> > > This fixes GART to return a properly aligned address as
> > > DMA-mapping.txt defines.
> > 
> > applied to tip/x86/gart, thanks! Any v2.6.27-urgency of this patch?
> 
> hm, -tip testing has found that this patch causes a hard hang during 
> bootup:
> 
>  initcall ali_init+0x0/0x1b returned 0 after 3 msecs
>  calling  amd_init+0x0/0x1b
>  bus: 'pci': add driver pata_amd
>  bus: 'pci': driver_probe_device: matched device 0000:00:06.0 with driver pata_amd
>  bus: 'pci': really_probe: probing driver pata_amd with device 0000:00:06.0
>  pata_amd 0000:00:06.0: version 0.3.10
>  pata_amd 0000:00:06.0: setting latency timer to 64
>  [hard hang]
> 
> should have continued with:
> 
>  scsi0 : pata_amd
>  device: 'host0': device_add
>  device: 'host0': device_add
>  scsi1 : pata_amd
>  [... etc. ... ]
> 
> on an AMD X2 testsystem. (Asus board) Can send more info on request. 
> Config is:
> 
>   http://redhat.com/~mingo/misc/config-Fri_Aug_15_18_30_56_CEST_2008.bad
> 
> Any idea why that is so? Apparently the alignment change wasnt as benign 
> as assumed.

Ah, sorry,

@@ -262,7 +264,11 @@ static dma_addr_t dma_map_area(struct device *dev, dma_addr_t phys_mem,
 static dma_addr_t
 gart_map_simple(struct device *dev, phys_addr_t paddr, size_t size, int dir)
 {
-	dma_addr_t map = dma_map_area(dev, paddr, size, dir);
+	dma_addr_t map;
+	unsigned long align_mask;
+
+	align_mask = (roundup_pow_of_two(size) >> PAGE_SHIFT) - 1;
+	map = dma_map_area(dev, paddr, size, dir, align_mask);

This code doesn't work with the case size < PAGE_SIZE.

I think that dmam_alloc_consistent in libata-core fails due to this
bug.

Can you try this?

BTW, I think that this is not urgent stuff at all.


diff --git a/arch/x86/kernel/pci-gart_64.c b/arch/x86/kernel/pci-gart_64.c
index 49285f8..045ae6f 100644
--- a/arch/x86/kernel/pci-gart_64.c
+++ b/arch/x86/kernel/pci-gart_64.c
@@ -82,7 +82,8 @@ AGPEXTERN __u32 *agp_gatt_table;
 static unsigned long next_bit;  /* protected by iommu_bitmap_lock */
 static int need_flush;		/* global flush state. set for each gart wrap */
 
-static unsigned long alloc_iommu(struct device *dev, int size)
+static unsigned long alloc_iommu(struct device *dev, int size,
+				 unsigned long align_mask)
 {
 	unsigned long offset, flags;
 	unsigned long boundary_size;
@@ -95,11 +96,12 @@ static unsigned long alloc_iommu(struct device *dev, int size)
 
 	spin_lock_irqsave(&iommu_bitmap_lock, flags);
 	offset = iommu_area_alloc(iommu_gart_bitmap, iommu_pages, next_bit,
-				  size, base_index, boundary_size, 0);
+				  size, base_index, boundary_size, align_mask);
 	if (offset == -1) {
 		need_flush = 1;
 		offset = iommu_area_alloc(iommu_gart_bitmap, iommu_pages, 0,
-					  size, base_index, boundary_size, 0);
+					  size, base_index, boundary_size,
+					  align_mask);
 	}
 	if (offset != -1) {
 		next_bit = offset+size;
@@ -236,10 +238,10 @@ nonforced_iommu(struct device *dev, unsigned long addr, size_t size)
  * Caller needs to check if the iommu is needed and flush.
  */
 static dma_addr_t dma_map_area(struct device *dev, dma_addr_t phys_mem,
-				size_t size, int dir)
+				size_t size, int dir, unsigned long align_mask)
 {
 	unsigned long npages = iommu_num_pages(phys_mem, size);
-	unsigned long iommu_page = alloc_iommu(dev, npages);
+	unsigned long iommu_page = alloc_iommu(dev, npages, align_mask);
 	int i;
 
 	if (iommu_page == -1) {
@@ -262,7 +264,11 @@ static dma_addr_t dma_map_area(struct device *dev, dma_addr_t phys_mem,
 static dma_addr_t
 gart_map_simple(struct device *dev, phys_addr_t paddr, size_t size, int dir)
 {
-	dma_addr_t map = dma_map_area(dev, paddr, size, dir);
+	dma_addr_t map;
+	unsigned long align_mask;
+
+	align_mask = (1UL << get_order(size)) - 1;
+	map = dma_map_area(dev, paddr, size, dir, align_mask);
 
 	flush_gart();
 
@@ -281,7 +287,8 @@ gart_map_single(struct device *dev, phys_addr_t paddr, size_t size, int dir)
 	if (!need_iommu(dev, paddr, size))
 		return paddr;
 
-	bus = gart_map_simple(dev, paddr, size, dir);
+	bus = dma_map_area(dev, paddr, size, dir, 0);
+	flush_gart();
 
 	return bus;
 }
@@ -340,7 +347,7 @@ static int dma_map_sg_nonforce(struct device *dev, struct scatterlist *sg,
 		unsigned long addr = sg_phys(s);
 
 		if (nonforced_iommu(dev, addr, s->length)) {
-			addr = dma_map_area(dev, addr, s->length, dir);
+			addr = dma_map_area(dev, addr, s->length, dir, 0);
 			if (addr == bad_dma_address) {
 				if (i > 0)
 					gart_unmap_sg(dev, sg, i, dir);
@@ -362,7 +369,7 @@ static int __dma_map_cont(struct device *dev, struct scatterlist *start,
 			  int nelems, struct scatterlist *sout,
 			  unsigned long pages)
 {
-	unsigned long iommu_start = alloc_iommu(dev, pages);
+	unsigned long iommu_start = alloc_iommu(dev, pages, 0);
 	unsigned long iommu_page = iommu_start;
 	struct scatterlist *s;
 	int i;

Re: [PATCH]: PCI: GART iommu alignment fixes [v2]

[Ingo Molnar]

* FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:

> > Config is:
> > 
> >   http://redhat.com/~mingo/misc/config-Fri_Aug_15_18_30_56_CEST_2008.bad
> > 
> > Any idea why that is so? Apparently the alignment change wasnt as benign 
> > as assumed.
> 
> Ah, sorry,
> 
> @@ -262,7 +264,11 @@ static dma_addr_t dma_map_area(struct device *dev, dma_addr_t phys_mem,
>  static dma_addr_t
>  gart_map_simple(struct device *dev, phys_addr_t paddr, size_t size, int dir)
>  {
> -	dma_addr_t map = dma_map_area(dev, paddr, size, dir);
> +	dma_addr_t map;
> +	unsigned long align_mask;
> +
> +	align_mask = (roundup_pow_of_two(size) >> PAGE_SHIFT) - 1;
> +	map = dma_map_area(dev, paddr, size, dir, align_mask);
> 
> This code doesn't work with the case size < PAGE_SIZE.
> 
> I think that dmam_alloc_consistent in libata-core fails due to this
> bug.
> 
> Can you try this?

ok - merged the commit below in tip/x86/iommu.

> BTW, I think that this is not urgent stuff at all.

ok - i've queued it up for v2.6.28.

	Ingo

-------------->
>From 4ae29849888f85a0cee12553995d47ec527ad049 Mon Sep 17 00:00:00 2001
From: Prarit Bhargava <prarit@redhat.com>
Date: Sat, 16 Aug 2008 10:15:32 +0900
Subject: [PATCH] x86 gart: allocate size-aligned address for alloc_coherent, v2

pci_alloc_consistent/dma_alloc_coherent does not return size aligned
addresses.

>From Documentation/DMA-mapping.txt:

"pci_alloc_consistent returns two values: the virtual address which you
can use to access it from the CPU and dma_handle which you pass to the
card.

The cpu return address and the DMA bus master address are both
guaranteed to be aligned to the smallest PAGE_SIZE order which
is greater than or equal to the requested size.  This invariant
exists (for example) to guarantee that if you allocate a chunk
which is smaller than or equal to 64 kilobytes, the extent of the
buffer you receive will not cross a 64K boundary."

1.  Modify alloc_iommu to allow for an alignment mask
2.  Modify pci_gart_simple to return size-aligned values.
3.  Fixup the alignment calculation in the iommu-helper code.
4.  Fix possible overflow in alloc_iommu's boundary_size calculation.
    (It is possible that alloc_iommu()'s boundary_size overflows as
     dma_get_seg_boundary can return 0xffffffff.  In that case, further usage of
     boundary_size triggers a BUG_ON() in the iommu code.)

End result: When allocating from IOMMU, pci_alloc_consistent/dma_alloc_coherent
will now return a size aligned value.

Signed-off-by: Prarit Bhargava <prarit@redhat.com>
[ FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>: boot hang fix. ]
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 arch/x86/kernel/pci-gart_64.c |   25 ++++++++++++++++---------
 1 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/arch/x86/kernel/pci-gart_64.c b/arch/x86/kernel/pci-gart_64.c
index cdab678..4d8efb0 100644
--- a/arch/x86/kernel/pci-gart_64.c
+++ b/arch/x86/kernel/pci-gart_64.c
@@ -82,7 +82,8 @@ AGPEXTERN __u32 *agp_gatt_table;
 static unsigned long next_bit;  /* protected by iommu_bitmap_lock */
 static int need_flush;		/* global flush state. set for each gart wrap */
 
-static unsigned long alloc_iommu(struct device *dev, int size)
+static unsigned long alloc_iommu(struct device *dev, int size,
+				 unsigned long align_mask)
 {
 	unsigned long offset, flags;
 	unsigned long boundary_size;
@@ -95,11 +96,12 @@ static unsigned long alloc_iommu(struct device *dev, int size)
 
 	spin_lock_irqsave(&iommu_bitmap_lock, flags);
 	offset = iommu_area_alloc(iommu_gart_bitmap, iommu_pages, next_bit,
-				  size, base_index, boundary_size, 0);
+				  size, base_index, boundary_size, align_mask);
 	if (offset == -1) {
 		need_flush = 1;
 		offset = iommu_area_alloc(iommu_gart_bitmap, iommu_pages, 0,
-					  size, base_index, boundary_size, 0);
+					  size, base_index, boundary_size,
+					  align_mask);
 	}
 	if (offset != -1) {
 		next_bit = offset+size;
@@ -236,10 +238,10 @@ nonforced_iommu(struct device *dev, unsigned long addr, size_t size)
  * Caller needs to check if the iommu is needed and flush.
  */
 static dma_addr_t dma_map_area(struct device *dev, dma_addr_t phys_mem,
-				size_t size, int dir)
+				size_t size, int dir, unsigned long align_mask)
 {
 	unsigned long npages = iommu_num_pages(phys_mem, size);
-	unsigned long iommu_page = alloc_iommu(dev, npages);
+	unsigned long iommu_page = alloc_iommu(dev, npages, align_mask);
 	int i;
 
 	if (iommu_page == -1) {
@@ -262,7 +264,11 @@ static dma_addr_t dma_map_area(struct device *dev, dma_addr_t phys_mem,
 static dma_addr_t
 gart_map_simple(struct device *dev, phys_addr_t paddr, size_t size, int dir)
 {
-	dma_addr_t map = dma_map_area(dev, paddr, size, dir);
+	dma_addr_t map;
+	unsigned long align_mask;
+
+	align_mask = (1UL << get_order(size)) - 1;
+	map = dma_map_area(dev, paddr, size, dir, align_mask);
 
 	flush_gart();
 
@@ -281,7 +287,8 @@ gart_map_single(struct device *dev, phys_addr_t paddr, size_t size, int dir)
 	if (!need_iommu(dev, paddr, size))
 		return paddr;
 
-	bus = gart_map_simple(dev, paddr, size, dir);
+	bus = dma_map_area(dev, paddr, size, dir, 0);
+	flush_gart();
 
 	return bus;
 }
@@ -340,7 +347,7 @@ static int dma_map_sg_nonforce(struct device *dev, struct scatterlist *sg,
 		unsigned long addr = sg_phys(s);
 
 		if (nonforced_iommu(dev, addr, s->length)) {
-			addr = dma_map_area(dev, addr, s->length, dir);
+			addr = dma_map_area(dev, addr, s->length, dir, 0);
 			if (addr == bad_dma_address) {
 				if (i > 0)
 					gart_unmap_sg(dev, sg, i, dir);
@@ -362,7 +369,7 @@ static int __dma_map_cont(struct device *dev, struct scatterlist *start,
 			  int nelems, struct scatterlist *sout,
 			  unsigned long pages)
 {
-	unsigned long iommu_start = alloc_iommu(dev, pages);
+	unsigned long iommu_start = alloc_iommu(dev, pages, 0);
 	unsigned long iommu_page = iommu_start;
 	struct scatterlist *s;
 	int i;

Re: [PATCH]: PCI: GART iommu alignment fixes [v2]

[FUJITA Tomonori]

On Sun, 17 Aug 2008 14:56:14 +0200
Ingo Molnar <mingo@elte.hu> wrote:

> 
> * FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:
> 
> > > Config is:
> > > 
> > >   http://redhat.com/~mingo/misc/config-Fri_Aug_15_18_30_56_CEST_2008.bad
> > > 
> > > Any idea why that is so? Apparently the alignment change wasnt as benign 
> > > as assumed.
> > 
> > Ah, sorry,
> > 
> > @@ -262,7 +264,11 @@ static dma_addr_t dma_map_area(struct device *dev, dma_addr_t phys_mem,
> >  static dma_addr_t
> >  gart_map_simple(struct device *dev, phys_addr_t paddr, size_t size, int dir)
> >  {
> > -	dma_addr_t map = dma_map_area(dev, paddr, size, dir);
> > +	dma_addr_t map;
> > +	unsigned long align_mask;
> > +
> > +	align_mask = (roundup_pow_of_two(size) >> PAGE_SHIFT) - 1;
> > +	map = dma_map_area(dev, paddr, size, dir, align_mask);
> > 
> > This code doesn't work with the case size < PAGE_SIZE.
> > 
> > I think that dmam_alloc_consistent in libata-core fails due to this
> > bug.
> > 
> > Can you try this?
> 
> ok - merged the commit below in tip/x86/iommu.
> 
> > BTW, I think that this is not urgent stuff at all.
> 
> ok - i've queued it up for v2.6.28.
> 
> 	Ingo
> 
> -------------->
> From 4ae29849888f85a0cee12553995d47ec527ad049 Mon Sep 17 00:00:00 2001
> From: Prarit Bhargava <prarit@redhat.com>
> Date: Sat, 16 Aug 2008 10:15:32 +0900
> Subject: [PATCH] x86 gart: allocate size-aligned address for alloc_coherent, v2
> 
> pci_alloc_consistent/dma_alloc_coherent does not return size aligned
> addresses.
> 
> >From Documentation/DMA-mapping.txt:
> 
> "pci_alloc_consistent returns two values: the virtual address which you
> can use to access it from the CPU and dma_handle which you pass to the
> card.
> 
> The cpu return address and the DMA bus master address are both
> guaranteed to be aligned to the smallest PAGE_SIZE order which
> is greater than or equal to the requested size.  This invariant
> exists (for example) to guarantee that if you allocate a chunk
> which is smaller than or equal to 64 kilobytes, the extent of the
> buffer you receive will not cross a 64K boundary."
> 
> 1.  Modify alloc_iommu to allow for an alignment mask
> 2.  Modify pci_gart_simple to return size-aligned values.
> 3.  Fixup the alignment calculation in the iommu-helper code.
> 4.  Fix possible overflow in alloc_iommu's boundary_size calculation.
>     (It is possible that alloc_iommu()'s boundary_size overflows as
>      dma_get_seg_boundary can return 0xffffffff.  In that case, further usage of
>      boundary_size triggers a BUG_ON() in the iommu code.)
> 
> End result: When allocating from IOMMU, pci_alloc_consistent/dma_alloc_coherent
> will now return a size aligned value.

The above commit log of Prarit's patch is completely wrong (so I wrote
this patch). To avoid misunderstanding, can you apply this patch with
a proper description like this:

=
This patch changes GART IOMMU to return a size aligned address wrt
dma_alloc_coherent, as DMA-mapping.txt defines:

The cpu return address and the DMA bus master address are both
guaranteed to be aligned to the smallest PAGE_SIZE order which
is greater than or equal to the requested size.  This invariant
exists (for example) to guarantee that if you allocate a chunk
which is smaller than or equal to 64 kilobytes, the extent of the
buffer you receive will not cross a 64K boundary.


But it is very unlikely that this matters. As DMA-mapping.txt
explains, This invariant is to avoid the boundary problem (such as
64K). Now the majority of IOMMUs including GART (except for Intel
IOMMU) don't allocate a buffer that crosses a 64K boundary wrt all the
DMA mapping interfaces (dma_alloc_coherent, dma_map_sg, and
dma_map_single) because of segment_boundary_mask in struct
device_dma_parameters.

Re: [PATCH]: PCI: GART iommu alignment fixes [v2]

[Ingo Molnar]

* FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:

> The above commit log of Prarit's patch is completely wrong (so I wrote 
> this patch). To avoid misunderstanding, can you apply this patch with 
> a proper description like this:

sure, i've created the commit below - is that fine?

	Ingo

--------------->
>From 3f18931be15856db01a216995670412e4421f3c9 Mon Sep 17 00:00:00 2001
From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Date: Mon, 18 Aug 2008 00:36:18 +0900
Subject: [PATCH] x86 gart: allocate size-aligned address for alloc_coherent, v2

This patch changes GART IOMMU to return a size aligned address wrt
dma_alloc_coherent, as DMA-mapping.txt defines:

The cpu return address and the DMA bus master address are both
guaranteed to be aligned to the smallest PAGE_SIZE order which
is greater than or equal to the requested size.  This invariant
exists (for example) to guarantee that if you allocate a chunk
which is smaller than or equal to 64 kilobytes, the extent of the
buffer you receive will not cross a 64K boundary.

But it is very unlikely that this matters. As DMA-mapping.txt
explains, This invariant is to avoid the boundary problem (such as
64K). Now the majority of IOMMUs including GART (except for Intel
IOMMU) don't allocate a buffer that crosses a 64K boundary wrt all the
DMA mapping interfaces (dma_alloc_coherent, dma_map_sg, and
dma_map_single) because of segment_boundary_mask in struct
device_dma_parameters.

Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 arch/x86/kernel/pci-gart_64.c |   25 ++++++++++++++++---------
 1 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/arch/x86/kernel/pci-gart_64.c b/arch/x86/kernel/pci-gart_64.c
index cdab678..4d8efb0 100644
--- a/arch/x86/kernel/pci-gart_64.c
+++ b/arch/x86/kernel/pci-gart_64.c
@@ -82,7 +82,8 @@ AGPEXTERN __u32 *agp_gatt_table;
 static unsigned long next_bit;  /* protected by iommu_bitmap_lock */
 static int need_flush;		/* global flush state. set for each gart wrap */
 
-static unsigned long alloc_iommu(struct device *dev, int size)
+static unsigned long alloc_iommu(struct device *dev, int size,
+				 unsigned long align_mask)
 {
 	unsigned long offset, flags;
 	unsigned long boundary_size;
@@ -95,11 +96,12 @@ static unsigned long alloc_iommu(struct device *dev, int size)
 
 	spin_lock_irqsave(&iommu_bitmap_lock, flags);
 	offset = iommu_area_alloc(iommu_gart_bitmap, iommu_pages, next_bit,
-				  size, base_index, boundary_size, 0);
+				  size, base_index, boundary_size, align_mask);
 	if (offset == -1) {
 		need_flush = 1;
 		offset = iommu_area_alloc(iommu_gart_bitmap, iommu_pages, 0,
-					  size, base_index, boundary_size, 0);
+					  size, base_index, boundary_size,
+					  align_mask);
 	}
 	if (offset != -1) {
 		next_bit = offset+size;
@@ -236,10 +238,10 @@ nonforced_iommu(struct device *dev, unsigned long addr, size_t size)
  * Caller needs to check if the iommu is needed and flush.
  */
 static dma_addr_t dma_map_area(struct device *dev, dma_addr_t phys_mem,
-				size_t size, int dir)
+				size_t size, int dir, unsigned long align_mask)
 {
 	unsigned long npages = iommu_num_pages(phys_mem, size);
-	unsigned long iommu_page = alloc_iommu(dev, npages);
+	unsigned long iommu_page = alloc_iommu(dev, npages, align_mask);
 	int i;
 
 	if (iommu_page == -1) {
@@ -262,7 +264,11 @@ static dma_addr_t dma_map_area(struct device *dev, dma_addr_t phys_mem,
 static dma_addr_t
 gart_map_simple(struct device *dev, phys_addr_t paddr, size_t size, int dir)
 {
-	dma_addr_t map = dma_map_area(dev, paddr, size, dir);
+	dma_addr_t map;
+	unsigned long align_mask;
+
+	align_mask = (1UL << get_order(size)) - 1;
+	map = dma_map_area(dev, paddr, size, dir, align_mask);
 
 	flush_gart();
 
@@ -281,7 +287,8 @@ gart_map_single(struct device *dev, phys_addr_t paddr, size_t size, int dir)
 	if (!need_iommu(dev, paddr, size))
 		return paddr;
 
-	bus = gart_map_simple(dev, paddr, size, dir);
+	bus = dma_map_area(dev, paddr, size, dir, 0);
+	flush_gart();
 
 	return bus;
 }
@@ -340,7 +347,7 @@ static int dma_map_sg_nonforce(struct device *dev, struct scatterlist *sg,
 		unsigned long addr = sg_phys(s);
 
 		if (nonforced_iommu(dev, addr, s->length)) {
-			addr = dma_map_area(dev, addr, s->length, dir);
+			addr = dma_map_area(dev, addr, s->length, dir, 0);
 			if (addr == bad_dma_address) {
 				if (i > 0)
 					gart_unmap_sg(dev, sg, i, dir);
@@ -362,7 +369,7 @@ static int __dma_map_cont(struct device *dev, struct scatterlist *start,
 			  int nelems, struct scatterlist *sout,
 			  unsigned long pages)
 {
-	unsigned long iommu_start = alloc_iommu(dev, pages);
+	unsigned long iommu_start = alloc_iommu(dev, pages, 0);
 	unsigned long iommu_page = iommu_start;
 	struct scatterlist *s;
 	int i;

Re: [PATCH]: PCI: GART iommu alignment fixes [v2]

[FUJITA Tomonori]

On Sun, 17 Aug 2008 17:42:13 +0200
Ingo Molnar <mingo@elte.hu> wrote:

> 
> * FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:
> 
> > The above commit log of Prarit's patch is completely wrong (so I wrote 
> > this patch). To avoid misunderstanding, can you apply this patch with 
> > a proper description like this:
> 
> sure, i've created the commit below - is that fine?
> 
> 	Ingo

I think that 'v2' in the subject is unnecessary. The rest looks fine.

Thanks,


> --------------->
> From 3f18931be15856db01a216995670412e4421f3c9 Mon Sep 17 00:00:00 2001
> From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
> Date: Mon, 18 Aug 2008 00:36:18 +0900
> Subject: [PATCH] x86 gart: allocate size-aligned address for alloc_coherent, v2
> 
> This patch changes GART IOMMU to return a size aligned address wrt
> dma_alloc_coherent, as DMA-mapping.txt defines:
> 
> The cpu return address and the DMA bus master address are both
> guaranteed to be aligned to the smallest PAGE_SIZE order which
> is greater than or equal to the requested size.  This invariant
> exists (for example) to guarantee that if you allocate a chunk
> which is smaller than or equal to 64 kilobytes, the extent of the
> buffer you receive will not cross a 64K boundary.
> 
> But it is very unlikely that this matters. As DMA-mapping.txt
> explains, This invariant is to avoid the boundary problem (such as
> 64K). Now the majority of IOMMUs including GART (except for Intel
> IOMMU) don't allocate a buffer that crosses a 64K boundary wrt all the
> DMA mapping interfaces (dma_alloc_coherent, dma_map_sg, and
> dma_map_single) because of segment_boundary_mask in struct
> device_dma_parameters.
> 
> Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
> Signed-off-by: Ingo Molnar <mingo@elte.hu>
> ---
>  arch/x86/kernel/pci-gart_64.c |   25 ++++++++++++++++---------
>  1 files changed, 16 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/x86/kernel/pci-gart_64.c b/arch/x86/kernel/pci-gart_64.c
> index cdab678..4d8efb0 100644
> --- a/arch/x86/kernel/pci-gart_64.c
> +++ b/arch/x86/kernel/pci-gart_64.c
> @@ -82,7 +82,8 @@ AGPEXTERN __u32 *agp_gatt_table;
>  static unsigned long next_bit;  /* protected by iommu_bitmap_lock */
>  static int need_flush;		/* global flush state. set for each gart wrap */
>  
> -static unsigned long alloc_iommu(struct device *dev, int size)
> +static unsigned long alloc_iommu(struct device *dev, int size,
> +				 unsigned long align_mask)
>  {
>  	unsigned long offset, flags;
>  	unsigned long boundary_size;
> @@ -95,11 +96,12 @@ static unsigned long alloc_iommu(struct device *dev, int size)
>  
>  	spin_lock_irqsave(&iommu_bitmap_lock, flags);
>  	offset = iommu_area_alloc(iommu_gart_bitmap, iommu_pages, next_bit,
> -				  size, base_index, boundary_size, 0);
> +				  size, base_index, boundary_size, align_mask);
>  	if (offset == -1) {
>  		need_flush = 1;
>  		offset = iommu_area_alloc(iommu_gart_bitmap, iommu_pages, 0,
> -					  size, base_index, boundary_size, 0);
> +					  size, base_index, boundary_size,
> +					  align_mask);
>  	}
>  	if (offset != -1) {
>  		next_bit = offset+size;
> @@ -236,10 +238,10 @@ nonforced_iommu(struct device *dev, unsigned long addr, size_t size)
>   * Caller needs to check if the iommu is needed and flush.
>   */
>  static dma_addr_t dma_map_area(struct device *dev, dma_addr_t phys_mem,
> -				size_t size, int dir)
> +				size_t size, int dir, unsigned long align_mask)
>  {
>  	unsigned long npages = iommu_num_pages(phys_mem, size);
> -	unsigned long iommu_page = alloc_iommu(dev, npages);
> +	unsigned long iommu_page = alloc_iommu(dev, npages, align_mask);
>  	int i;
>  
>  	if (iommu_page == -1) {
> @@ -262,7 +264,11 @@ static dma_addr_t dma_map_area(struct device *dev, dma_addr_t phys_mem,
>  static dma_addr_t
>  gart_map_simple(struct device *dev, phys_addr_t paddr, size_t size, int dir)
>  {
> -	dma_addr_t map = dma_map_area(dev, paddr, size, dir);
> +	dma_addr_t map;
> +	unsigned long align_mask;
> +
> +	align_mask = (1UL << get_order(size)) - 1;
> +	map = dma_map_area(dev, paddr, size, dir, align_mask);
>  
>  	flush_gart();
>  
> @@ -281,7 +287,8 @@ gart_map_single(struct device *dev, phys_addr_t paddr, size_t size, int dir)
>  	if (!need_iommu(dev, paddr, size))
>  		return paddr;
>  
> -	bus = gart_map_simple(dev, paddr, size, dir);
> +	bus = dma_map_area(dev, paddr, size, dir, 0);
> +	flush_gart();
>  
>  	return bus;
>  }
> @@ -340,7 +347,7 @@ static int dma_map_sg_nonforce(struct device *dev, struct scatterlist *sg,
>  		unsigned long addr = sg_phys(s);
>  
>  		if (nonforced_iommu(dev, addr, s->length)) {
> -			addr = dma_map_area(dev, addr, s->length, dir);
> +			addr = dma_map_area(dev, addr, s->length, dir, 0);
>  			if (addr == bad_dma_address) {
>  				if (i > 0)
>  					gart_unmap_sg(dev, sg, i, dir);
> @@ -362,7 +369,7 @@ static int __dma_map_cont(struct device *dev, struct scatterlist *start,
>  			  int nelems, struct scatterlist *sout,
>  			  unsigned long pages)
>  {
> -	unsigned long iommu_start = alloc_iommu(dev, pages);
> +	unsigned long iommu_start = alloc_iommu(dev, pages, 0);
>  	unsigned long iommu_page = iommu_start;
>  	struct scatterlist *s;
>  	int i;
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH]: PCI: GART iommu alignment fixes [v2]

[FUJITA Tomonori]

On Mon, 18 Aug 2008 00:48:05 +0900
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:

> On Sun, 17 Aug 2008 17:42:13 +0200
> Ingo Molnar <mingo@elte.hu> wrote:
> 
> > 
> > * FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> wrote:
> > 
> > > The above commit log of Prarit's patch is completely wrong (so I wrote 
> > > this patch). To avoid misunderstanding, can you apply this patch with 
> > > a proper description like this:
> > 
> > sure, i've created the commit below - is that fine?
> > 
> > 	Ingo
> 
> I think that 'v2' in the subject is unnecessary. The rest looks fine.
> 
> Thanks,
> 
> 
> > --------------->
> > From 3f18931be15856db01a216995670412e4421f3c9 Mon Sep 17 00:00:00 2001
> > From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
> > Date: Mon, 18 Aug 2008 00:36:18 +0900
> > Subject: [PATCH] x86 gart: allocate size-aligned address for alloc_coherent, v2
> > 
> > This patch changes GART IOMMU to return a size aligned address wrt
> > dma_alloc_coherent, as DMA-mapping.txt defines:
> > 
> > The cpu return address and the DMA bus master address are both
> > guaranteed to be aligned to the smallest PAGE_SIZE order which
> > is greater than or equal to the requested size.  This invariant
> > exists (for example) to guarantee that if you allocate a chunk
> > which is smaller than or equal to 64 kilobytes, the extent of the
> > buffer you receive will not cross a 64K boundary.

Ops, can you remove the following part? I confused
segment_boundary_mask with max_segment_size. A device needs to set
segment_boundary_mask properly if it doesn't want a buffer that
crosses a 64K boundary. We set the default boundary to 4G.


> > But it is very unlikely that this matters. As DMA-mapping.txt
> > explains, This invariant is to avoid the boundary problem (such as
> > 64K). Now the majority of IOMMUs including GART (except for Intel
> > IOMMU) don't allocate a buffer that crosses a 64K boundary wrt all the
> > DMA mapping interfaces (dma_alloc_coherent, dma_map_sg, and
> > dma_map_single) because of segment_boundary_mask in struct
> > device_dma_parameters.

Re: [PATCH]: PCI: GART iommu alignment fixes [v2]

[Prarit Bhargava]

>
> Feel like respinning with a full changelog against my for-linus branch?  Maybe 
> you can convince Tomonori-san this time. :)
>
>   

Oops ;)  I forgot to add "New patch with full changelog is coming."

P.

> Jesse
>   

Re: [PATCH]: PCI: GART iommu alignment fixes [v2]

[FUJITA Tomonori]

On Wed, 23 Jul 2008 07:19:43 -0400
Prarit Bhargava <prarit@redhat.com> wrote:

> pci_alloc_consistent/dma_alloc_coherent does not return size aligned
> addresses.
> 
> From Documentation/DMA-mapping.txt:
> 
> "pci_alloc_consistent returns two values: the virtual address which you
> can use to access it from the CPU and dma_handle which you pass to the
> card.
> 
> The cpu return address and the DMA bus master address are both
> guaranteed to be aligned to the smallest PAGE_SIZE order which
> is greater than or equal to the requested size.  This invariant
> exists (for example) to guarantee that if you allocate a chunk
> which is smaller than or equal to 64 kilobytes, the extent of the
> buffer you receive will not cross a 64K boundary."
> 
> 1.  Modify alloc_iommu to allow for an alignment mask
> 2.  Modify pci_gart_simple to return size-aligned values.
> 3.  Fixup the alignment calculation in the iommu-helper code.

Hmm, you don't fix anything in the helper code. You just use
__ALIGN_MASK.

And please don't use __ALIGN_MASK. You will notice that no one in
mainline use __ALIGN_MASK. Andrew said that we should not.

Ideally, we should use ALIGN here but the current code was accepted
because it is pretty simple and we have an comment what we do here. So
please let it alone.

Re: [PATCH]: PCI: GART iommu alignment fixes [v2]

[Prarit Bhargava]

FUJITA Tomonori wrote:
> On Wed, 23 Jul 2008 07:19:43 -0400
> Prarit Bhargava <prarit@redhat.com> wrote:
>
>   
>> pci_alloc_consistent/dma_alloc_coherent does not return size aligned
>> addresses.
>>
>> From Documentation/DMA-mapping.txt:
>>
>> "pci_alloc_consistent returns two values: the virtual address which you
>> can use to access it from the CPU and dma_handle which you pass to the
>> card.
>>
>> The cpu return address and the DMA bus master address are both
>> guaranteed to be aligned to the smallest PAGE_SIZE order which
>> is greater than or equal to the requested size.  This invariant
>> exists (for example) to guarantee that if you allocate a chunk
>> which is smaller than or equal to 64 kilobytes, the extent of the
>> buffer you receive will not cross a 64K boundary."
>>
>> 1.  Modify alloc_iommu to allow for an alignment mask
>> 2.  Modify pci_gart_simple to return size-aligned values.
>> 3.  Fixup the alignment calculation in the iommu-helper code.
>>     
>
> Hmm, you don't fix anything in the helper code. You just use
> __ALIGN_MASK.
>
>   
Yeah -- I meant "fixup" as opposed to fix.

> And please don't use __ALIGN_MASK. You will notice that no one in
> mainline use __ALIGN_MASK. Andrew said that we should not.
>
> Ideally, we should use ALIGN here but the current code was accepted
> because it is pretty simple and we have an comment what we do here. So
> please let it alone.
>   

I'll resubmit shortly ...

P.