On Fri, 2007-08-24 at 15:53 +0900, Yasunori Goto wrote:
> I found find_next_best_node() was wrong.
> I confirmed boot up by the following patch.
> Mel-san, Kamalesh-san, could you try this?
FYI: This patch also allows the alloc-instantiate-race testcase in
libhugetlbfs to pass again :)
--
Adam
On Fri, 2007-08-24 at 15:53 +0900, Yasunori Goto wrote:
I found find_next_best_node() was wrong.
I confirmed boot up by the following patch.
Mel-san, Kamalesh-san, could you try this?
FYI: This patch also allows the alloc-instantiate-race testcase in
libhugetlbfs to pass again :)
--
Adam
On Fri, 24 Aug 2007, Lee Schermerhorn wrote:
> PATCH Diffs between "Fix generic usage of node_online_map" V1 & V2
Ahh. Yes. I remember some of that.
Acked-by: Christoph Lameter <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Fri, 2007-08-24 at 10:00 -0700, Christoph Lameter wrote:
> On Fri, 24 Aug 2007, Lee Schermerhorn wrote:
>
> > I reworked that patch and posted the update on 16aug which does not have
> > this problem:
> >
> > http://marc.info/?l=linux-mm=118729871101418=4
> >
> > This should replace
> >
On Fri, 24 Aug 2007, Mel Gorman wrote:
> Andrew, this fixes a real problem and should be considered a fix to
> memoryless-nodes-fixup-uses-of-node_online_map-in-generic-code.patch unless
> Christoph Lameter objects.
Right. Lets make sure to cc Lee on future discussions of the memoryless
node
On Fri, 24 Aug 2007, Lee Schermerhorn wrote:
> I reworked that patch and posted the update on 16aug which does not have
> this problem:
>
> http://marc.info/?l=linux-mm=118729871101418=4
>
> This should replace
> memoryless-nodes-fixup-uses-of-node_online_map-in-generic-code.patch
> in -mm.
Yasunori Goto wrote:
I found find_next_best_node() was wrong.
I confirmed boot up by the following patch.
Mel-san, Kamalesh-san, could you try this?
Bye.
---
Fix decision of memoryless node in find_next_best_node().
This can be cause of SW-IOMMU's allocation failure.
This patch is for
On Fri, 2007-08-24 at 15:52 +0100, Mel Gorman wrote:
> On (24/08/07 15:53), Yasunori Goto didst pronounce:
> >
> > I found find_next_best_node() was wrong.
> > I confirmed boot up by the following patch.
> > Mel-san, Kamalesh-san, could you try this?
> >
>
> This boots the IA-64 successful and
On (24/08/07 15:53), Yasunori Goto didst pronounce:
>
> I found find_next_best_node() was wrong.
> I confirmed boot up by the following patch.
> Mel-san, Kamalesh-san, could you try this?
>
This boots the IA-64 successful and gets rid of that DMA corrupts
memory message. As a bonus, it fixes up
I found find_next_best_node() was wrong.
I confirmed boot up by the following patch.
Mel-san, Kamalesh-san, could you try this?
Bye.
---
Fix decision of memoryless node in find_next_best_node().
This can be cause of SW-IOMMU's allocation failure.
This patch is for 2.6.23-rc3-mm1.
I found find_next_best_node() was wrong.
I confirmed boot up by the following patch.
Mel-san, Kamalesh-san, could you try this?
Bye.
---
Fix decision of memoryless node in find_next_best_node().
This can be cause of SW-IOMMU's allocation failure.
This patch is for 2.6.23-rc3-mm1.
On (24/08/07 15:53), Yasunori Goto didst pronounce:
I found find_next_best_node() was wrong.
I confirmed boot up by the following patch.
Mel-san, Kamalesh-san, could you try this?
This boots the IA-64 successful and gets rid of that DMA corrupts
memory message. As a bonus, it fixes up the
On Fri, 2007-08-24 at 15:52 +0100, Mel Gorman wrote:
On (24/08/07 15:53), Yasunori Goto didst pronounce:
I found find_next_best_node() was wrong.
I confirmed boot up by the following patch.
Mel-san, Kamalesh-san, could you try this?
This boots the IA-64 successful and gets rid of
Yasunori Goto wrote:
I found find_next_best_node() was wrong.
I confirmed boot up by the following patch.
Mel-san, Kamalesh-san, could you try this?
Bye.
---
Fix decision of memoryless node in find_next_best_node().
This can be cause of SW-IOMMU's allocation failure.
This patch is for
On Fri, 24 Aug 2007, Lee Schermerhorn wrote:
I reworked that patch and posted the update on 16aug which does not have
this problem:
http://marc.info/?l=linux-mmm=118729871101418w=4
This should replace
memoryless-nodes-fixup-uses-of-node_online_map-in-generic-code.patch
in -mm.
Could
On Fri, 24 Aug 2007, Mel Gorman wrote:
Andrew, this fixes a real problem and should be considered a fix to
memoryless-nodes-fixup-uses-of-node_online_map-in-generic-code.patch unless
Christoph Lameter objects.
Right. Lets make sure to cc Lee on future discussions of the memoryless
node
On Fri, 2007-08-24 at 10:00 -0700, Christoph Lameter wrote:
On Fri, 24 Aug 2007, Lee Schermerhorn wrote:
I reworked that patch and posted the update on 16aug which does not have
this problem:
http://marc.info/?l=linux-mmm=118729871101418w=4
This should replace
On Fri, 24 Aug 2007, Lee Schermerhorn wrote:
PATCH Diffs between Fix generic usage of node_online_map V1 V2
Ahh. Yes. I remember some of that.
Acked-by: Christoph Lameter [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
On Thu, 23 Aug 2007 10:22:26 -0700
"Luck, Tony" <[EMAIL PROTECTED]> wrote:
> > __get_free_pages() of swiotlb_alloc_coherent() fails in rc3-mm1.
> > But, it doesn't fail on rc2-mm2, and kernel can boot up.
>
> That looks to be part of the problem here ... failing an order=3
> allocation during
> __get_free_pages() of swiotlb_alloc_coherent() fails in rc3-mm1.
> But, it doesn't fail on rc2-mm2, and kernel can boot up.
That looks to be part of the problem here ... failing an order=3
allocation during boot on a system that just a few lines earlier
in the boot log reported "Memory:
> On (22/08/07 16:27), Luck, Tony didst pronounce:
> > > The more ioc's you have, the more space you will use.
> >
> > Default SW IOTLB allocation is 64MB ... how much should we see
> > used per ioc?
> >
> > Kamelesh: You could try increasing the amount of sw iotlb space
> > available by booting
Luck, Tony wrote:
The more ioc's you have, the more space you will use.
Default SW IOTLB allocation is 64MB ... how much should we see
used per ioc?
Kamelesh: You could try increasing the amount of sw iotlb space
available by booting with a swiotlb=131072 argument (argument
value is the
On (22/08/07 16:27), Luck, Tony didst pronounce:
> > The more ioc's you have, the more space you will use.
>
> Default SW IOTLB allocation is 64MB ... how much should we see
> used per ioc?
>
> Kamelesh: You could try increasing the amount of sw iotlb space
> available by booting with a
On (22/08/07 16:27), Luck, Tony didst pronounce:
The more ioc's you have, the more space you will use.
Default SW IOTLB allocation is 64MB ... how much should we see
used per ioc?
Kamelesh: You could try increasing the amount of sw iotlb space
available by booting with a swiotlb=131072
Luck, Tony wrote:
The more ioc's you have, the more space you will use.
Default SW IOTLB allocation is 64MB ... how much should we see
used per ioc?
Kamelesh: You could try increasing the amount of sw iotlb space
available by booting with a swiotlb=131072 argument (argument
value is the
On (22/08/07 16:27), Luck, Tony didst pronounce:
The more ioc's you have, the more space you will use.
Default SW IOTLB allocation is 64MB ... how much should we see
used per ioc?
Kamelesh: You could try increasing the amount of sw iotlb space
available by booting with a
__get_free_pages() of swiotlb_alloc_coherent() fails in rc3-mm1.
But, it doesn't fail on rc2-mm2, and kernel can boot up.
That looks to be part of the problem here ... failing an order=3
allocation during boot on a system that just a few lines earlier
in the boot log reported Memory:
On Thu, 23 Aug 2007 10:22:26 -0700
Luck, Tony [EMAIL PROTECTED] wrote:
__get_free_pages() of swiotlb_alloc_coherent() fails in rc3-mm1.
But, it doesn't fail on rc2-mm2, and kernel can boot up.
That looks to be part of the problem here ... failing an order=3
allocation during boot on a
On Wed, Aug 22, 2007 at 06:09:48PM -0700, Jeremy Higdon wrote:
> > I traced the pci_alloc_consistent calls from PrimeIocFifos on my
> > system. There are two calls for each ioc. The first is for
> > 266368 bytes, the second for 16320 bytes.
> >
> > I wonder why Kamalesh's system wants the
On Wed, Aug 22, 2007 at 05:05:54PM -0700, Luck, Tony wrote:
> > Hmm. Must be something else going on then. It should be less than 1MB
> > per ioc plus whatever is used for streaming I/O.
> >
> > | mptbase: Initiating ioc2 bringup | GSI 16
> > (level, low) -> CPU 2
> Hmm. Must be something else going on then. It should be less than 1MB
> per ioc plus whatever is used for streaming I/O.
>
> | mptbase: Initiating ioc2 bringup | GSI 16
> (level, low) -> CPU 2 (0xc418) vector 50
> | ioc2: LSI53C1030 C0: Capabilities={Initiator}
On Wed, Aug 22, 2007 at 04:27:09PM -0700, Luck, Tony wrote:
> > The more ioc's you have, the more space you will use.
>
> Default SW IOTLB allocation is 64MB ... how much should we see
> used per ioc?
Hmm. Must be something else going on then. It should be less than 1MB
per ioc plus whatever
> The more ioc's you have, the more space you will use.
Default SW IOTLB allocation is 64MB ... how much should we see
used per ioc?
Kamelesh: You could try increasing the amount of sw iotlb space
available by booting with a swiotlb=131072 argument (argument
value is the number of 2K slabs to
On Wed, Aug 22, 2007 at 03:56:57PM -0700, Luck, Tony wrote:
> [ 20.903201] [] swiotlb_full+0x50/0x120
> [ 20.903202] sp=e0014322fac0 bsp=e00143229120
> [ 20.916902] [] swiotlb_map_single+0x120/0x1c0
> [ 20.916904] sp=e0014322fac0 bsp=e001432290d8
> [ 20.931215] []
[ 20.903201] [] swiotlb_full+0x50/0x120
[ 20.903202] sp=e0014322fac0 bsp=e00143229120
[ 20.916902] [] swiotlb_map_single+0x120/0x1c0
[ 20.916904] sp=e0014322fac0 bsp=e001432290d8
[ 20.931215] [] swiotlb_alloc_coherent+0x150/0x240
[ 20.931217] sp=e0014322fac0
Luck, Tony wrote:
Attached the boot log and config file.
Kamelesh,
I don't see anything obvious in the boot_log.
I used your "dotconfig" file to build a 2.6.23-rc3-mm1 kernel
and booted it on my test system ... it worked just fine
(except that for some reason the network did not come up
> Attached the boot log and config file.
Kamelesh,
I don't see anything obvious in the boot_log.
I used your "dotconfig" file to build a 2.6.23-rc3-mm1 kernel
and booted it on my test system ... it worked just fine
(except that for some reason the network did not come up :-( )
I tried to
Andi Kleen wrote:
[ 20.880366] DMA: Out of SW-IOMMU space for 263200 bytes at device ?
[ 20.886858] Kernel panic - not syncing: DMA: Memory would be corrupted
Gad, never seen that before. Andi, Tony: help?
Either the driver is leaking or more likely something went
wrong with
> > [ 20.880366] DMA: Out of SW-IOMMU space for 263200 bytes at device ?
> > [ 20.886858] Kernel panic - not syncing: DMA: Memory would be corrupted
>
> Gad, never seen that before. Andi, Tony: help?
Either the driver is leaking or more likely something went
wrong with the swiotlb
On Wed, 22 Aug 2007 20:02:29 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
> Hi Andrew,
>
> Following Kernel panic was raised, when tried to boot using IA-64
> machine with 2.6.23-rc3-mm1 kernel.
> ===
> [ 15.198125] target0:0:8: Ending Domain
Hi Andrew,
Following Kernel panic was raised, when tried to boot using IA-64
machine with 2.6.23-rc3-mm1 kernel.
===
[ 15.198125] target0:0:8: Ending Domain Validation
[ 15.203117] target0:0:8: asynchronous
[ 15.207377] scsi 0:0:8:0: Attached
Hi Andrew,
Following Kernel panic was raised, when tried to boot using IA-64
machine with 2.6.23-rc3-mm1 kernel.
===
[ 15.198125] target0:0:8: Ending Domain Validation
[ 15.203117] target0:0:8: asynchronous
[ 15.207377] scsi 0:0:8:0: Attached
On Wed, 22 Aug 2007 20:02:29 +0530 Kamalesh Babulal [EMAIL PROTECTED] wrote:
Hi Andrew,
Following Kernel panic was raised, when tried to boot using IA-64
machine with 2.6.23-rc3-mm1 kernel.
===
[ 15.198125] target0:0:8: Ending Domain
[ 20.880366] DMA: Out of SW-IOMMU space for 263200 bytes at device ?
[ 20.886858] Kernel panic - not syncing: DMA: Memory would be corrupted
Gad, never seen that before. Andi, Tony: help?
Either the driver is leaking or more likely something went
wrong with the swiotlb
Andi Kleen wrote:
[ 20.880366] DMA: Out of SW-IOMMU space for 263200 bytes at device ?
[ 20.886858] Kernel panic - not syncing: DMA: Memory would be corrupted
Gad, never seen that before. Andi, Tony: help?
Either the driver is leaking or more likely something went
wrong with
Attached the boot log and config file.
Kamelesh,
I don't see anything obvious in the boot_log.
I used your dotconfig file to build a 2.6.23-rc3-mm1 kernel
and booted it on my test system ... it worked just fine
(except that for some reason the network did not come up :-( )
I tried to compare
Luck, Tony wrote:
Attached the boot log and config file.
Kamelesh,
I don't see anything obvious in the boot_log.
I used your dotconfig file to build a 2.6.23-rc3-mm1 kernel
and booted it on my test system ... it worked just fine
(except that for some reason the network did not come up
[ 20.903201] [a001003aaa50] swiotlb_full+0x50/0x120
[ 20.903202] sp=e0014322fac0 bsp=e00143229120
[ 20.916902] [a001003aac40] swiotlb_map_single+0x120/0x1c0
[ 20.916904] sp=e0014322fac0 bsp=e001432290d8
[ 20.931215] [a001003ab630] swiotlb_alloc_coherent+0x150/0x240
[
On Wed, Aug 22, 2007 at 03:56:57PM -0700, Luck, Tony wrote:
[ 20.903201] [a001003aaa50] swiotlb_full+0x50/0x120
[ 20.903202] sp=e0014322fac0 bsp=e00143229120
[ 20.916902] [a001003aac40] swiotlb_map_single+0x120/0x1c0
[ 20.916904] sp=e0014322fac0 bsp=e001432290d8
[
The more ioc's you have, the more space you will use.
Default SW IOTLB allocation is 64MB ... how much should we see
used per ioc?
Kamelesh: You could try increasing the amount of sw iotlb space
available by booting with a swiotlb=131072 argument (argument
value is the number of 2K slabs to
On Wed, Aug 22, 2007 at 04:27:09PM -0700, Luck, Tony wrote:
The more ioc's you have, the more space you will use.
Default SW IOTLB allocation is 64MB ... how much should we see
used per ioc?
Hmm. Must be something else going on then. It should be less than 1MB
per ioc plus whatever is
Hmm. Must be something else going on then. It should be less than 1MB
per ioc plus whatever is used for streaming I/O.
| mptbase: Initiating ioc2 bringup | GSI 16
(level, low) - CPU 2 (0xc418) vector 50
| ioc2: LSI53C1030 C0: Capabilities={Initiator}
On Wed, Aug 22, 2007 at 05:05:54PM -0700, Luck, Tony wrote:
Hmm. Must be something else going on then. It should be less than 1MB
per ioc plus whatever is used for streaming I/O.
| mptbase: Initiating ioc2 bringup | GSI 16
(level, low) - CPU 2 (0xc418)
On Wed, Aug 22, 2007 at 06:09:48PM -0700, Jeremy Higdon wrote:
I traced the pci_alloc_consistent calls from PrimeIocFifos on my
system. There are two calls for each ioc. The first is for
266368 bytes, the second for 16320 bytes.
I wonder why Kamalesh's system wants the slightly
54 matches
Mail list logo
