From: Bjorn Helgaas
Date: Fri, 3 Apr 2015 10:45:26 -0500
> On Sun, Mar 29, 2015 at 11:32:50AM -0700, David Miller wrote:
>> From: Bjorn Helgaas
>> Date: Sun, 29 Mar 2015 08:30:40 -0500
>>
>> > Help me understand the sparc64 situation: are you saying that BAR
>> > addresses, i.e., MMIO
On Sun, Mar 29, 2015 at 11:32:50AM -0700, David Miller wrote:
> From: Bjorn Helgaas
> Date: Sun, 29 Mar 2015 08:30:40 -0500
>
> > Help me understand the sparc64 situation: are you saying that BAR
> > addresses, i.e., MMIO transactions from a CPU or a peer-to-peer DMA can be
> > 64 bits, but a
From: Bjorn Helgaas bhelg...@google.com
Date: Fri, 3 Apr 2015 10:45:26 -0500
On Sun, Mar 29, 2015 at 11:32:50AM -0700, David Miller wrote:
From: Bjorn Helgaas bjorn.helg...@gmail.com
Date: Sun, 29 Mar 2015 08:30:40 -0500
Help me understand the sparc64 situation: are you saying that BAR
On Sun, Mar 29, 2015 at 11:32:50AM -0700, David Miller wrote:
From: Bjorn Helgaas bjorn.helg...@gmail.com
Date: Sun, 29 Mar 2015 08:30:40 -0500
Help me understand the sparc64 situation: are you saying that BAR
addresses, i.e., MMIO transactions from a CPU or a peer-to-peer DMA can be
64
On 3/31/15 4:38 PM, Yinghai Lu wrote:
On Tue, Mar 31, 2015 at 3:29 PM, David Ahern wrote:
Please check attached three patches on top of current linus tree.
new log. Same as before -- PCI_DEBUG, ignore_loglevel ofpci_debug=1
Good, it is clean now.
Yes. You can add a Tested-by to all 3.
On Tue, Mar 31, 2015 at 3:29 PM, David Ahern wrote:
>>
>> Please check attached three patches on top of current linus tree.
>>
>
> new log. Same as before -- PCI_DEBUG, ignore_loglevel ofpci_debug=1
>
Good, it is clean now.
Thanks
Yinghai
--
To unsubscribe from this list: send the line
On Tue, Mar 31, 2015 at 10:04 AM, David Ahern wrote:
>> Clear out the old and apply these new ones.
>
>
> I take DaveM's response to mean the patches (3rd one?) needs another
> version.
>
> I will be on PTO Wed-Fri with limited access through Sunday. If you have
> something to try out later today
On Tue, Mar 31, 2015 at 11:19 AM, David Miller wrote:
> I totally disagree, I think your test is too stringent and should be
> significantly relaxed if not removed entirely.
ok, will produce one version that only verify first criteria.
Thanks
Yinghai
--
To unsubscribe from this list: send the
From: Yinghai Lu
Date: Tue, 31 Mar 2015 11:16:11 -0700
> On Tue, Mar 31, 2015 at 8:06 AM, David Miller wrote:
>> Your patch only allows the condition behind resources that have 64-bits
>> of significance, but that is not what the document above says about
>> when this situation is allowed.
>>
On Tue, Mar 31, 2015 at 8:06 AM, David Miller wrote:
> Your patch only allows the condition behind resources that have 64-bits
> of significance, but that is not what the document above says about
> when this situation is allowed.
>
> Please implement the check either exactly as stated in the
On 3/31/15 10:53 AM, Yinghai Lu wrote:
On Mon, Mar 30, 2015 at 9:10 PM, David Ahern wrote:
On 3/30/15 7:06 PM, Yinghai Lu wrote:
To make sure I am on the same page: these are a new round of patches? clear
out the old, apply these?
Clear out the old and apply these new ones.
I take DaveM's
On Mon, Mar 30, 2015 at 9:10 PM, David Ahern wrote:
> On 3/30/15 7:06 PM, Yinghai Lu wrote:
> To make sure I am on the same page: these are a new round of patches? clear
> out the old, apply these?
Clear out the old and apply these new ones.
Thanks
Yinghai
--
To unsubscribe from this list:
From: Yinghai Lu
Date: Mon, 30 Mar 2015 18:06:02 -0700
> ok, that is really non-pref mmio 64bit.
> We can workaround the problem by honoring firmware setting, according
> to
> https://www.pcisig.com/specifications/pciexpress/base2/PCIe_Base_r2.1_Errata_08Jun10.pdf
> page 13
>
> Please check
From: Yinghai Lu ying...@kernel.org
Date: Mon, 30 Mar 2015 18:06:02 -0700
ok, that is really non-pref mmio 64bit.
We can workaround the problem by honoring firmware setting, according
to
https://www.pcisig.com/specifications/pciexpress/base2/PCIe_Base_r2.1_Errata_08Jun10.pdf
page 13
On Mon, Mar 30, 2015 at 9:10 PM, David Ahern david.ah...@oracle.com wrote:
On 3/30/15 7:06 PM, Yinghai Lu wrote:
To make sure I am on the same page: these are a new round of patches? clear
out the old, apply these?
Clear out the old and apply these new ones.
Thanks
Yinghai
--
To unsubscribe
On 3/31/15 10:53 AM, Yinghai Lu wrote:
On Mon, Mar 30, 2015 at 9:10 PM, David Ahern david.ah...@oracle.com wrote:
On 3/30/15 7:06 PM, Yinghai Lu wrote:
To make sure I am on the same page: these are a new round of patches? clear
out the old, apply these?
Clear out the old and apply these new
On Tue, Mar 31, 2015 at 8:06 AM, David Miller da...@davemloft.net wrote:
Your patch only allows the condition behind resources that have 64-bits
of significance, but that is not what the document above says about
when this situation is allowed.
Please implement the check either exactly as
From: Yinghai Lu ying...@kernel.org
Date: Tue, 31 Mar 2015 11:16:11 -0700
On Tue, Mar 31, 2015 at 8:06 AM, David Miller da...@davemloft.net wrote:
Your patch only allows the condition behind resources that have 64-bits
of significance, but that is not what the document above says about
when
On Tue, Mar 31, 2015 at 11:19 AM, David Miller da...@davemloft.net wrote:
I totally disagree, I think your test is too stringent and should be
significantly relaxed if not removed entirely.
ok, will produce one version that only verify first criteria.
Thanks
Yinghai
--
To unsubscribe from
On Tue, Mar 31, 2015 at 10:04 AM, David Ahern david.ah...@oracle.com wrote:
Clear out the old and apply these new ones.
I take DaveM's response to mean the patches (3rd one?) needs another
version.
I will be on PTO Wed-Fri with limited access through Sunday. If you have
something to try
On 3/31/15 4:38 PM, Yinghai Lu wrote:
On Tue, Mar 31, 2015 at 3:29 PM, David Ahern david.ah...@oracle.com wrote:
Please check attached three patches on top of current linus tree.
new log. Same as before -- PCI_DEBUG, ignore_loglevel ofpci_debug=1
Good, it is clean now.
Yes. You can add
On Tue, Mar 31, 2015 at 3:29 PM, David Ahern david.ah...@oracle.com wrote:
Please check attached three patches on top of current linus tree.
new log. Same as before -- PCI_DEBUG, ignore_loglevel ofpci_debug=1
Good, it is clean now.
Thanks
Yinghai
--
To unsubscribe from this list: send the
On 3/30/15 7:06 PM, Yinghai Lu wrote:
ok, that is really non-pref mmio 64bit.
We can workaround the problem by honoring firmware setting, according
to
https://www.pcisig.com/specifications/pciexpress/base2/PCIe_Base_r2.1_Errata_08Jun10.pdf
page 13
Please check attached updated patches that
On Mon, Mar 30, 2015 at 3:54 PM, David Ahern wrote:
> On 3/29/15 2:07 PM, Yinghai Lu wrote:
>>
>> [ 286.647560] PCI: scan_bus[/pci@300/pci@1/pci@0/pci@6] bus no 8
>> [ 286.921232] PCI: Claiming :00:01.0: Resource 15:
>> 8001..8004afff [220c]
>> [ 287.229190] PCI:
On 3/29/15 2:07 PM, Yinghai Lu wrote:
[ 286.647560] PCI: scan_bus[/pci@300/pci@1/pci@0/pci@6] bus no 8
[ 286.921232] PCI: Claiming :00:01.0: Resource 15:
8001..8004afff [220c]
[ 287.229190] PCI: Claiming :01:00.0: Resource 15:
8001..8004afff
On 3/29/15 2:07 PM, Yinghai Lu wrote:
[ 286.647560] PCI: scan_bus[/pci@300/pci@1/pci@0/pci@6] bus no 8
[ 286.921232] PCI: Claiming :00:01.0: Resource 15:
8001..8004afff [220c]
[ 287.229190] PCI: Claiming :01:00.0: Resource 15:
8001..8004afff
On Mon, Mar 30, 2015 at 3:54 PM, David Ahern david.ah...@oracle.com wrote:
On 3/29/15 2:07 PM, Yinghai Lu wrote:
[ 286.647560] PCI: scan_bus[/pci@300/pci@1/pci@0/pci@6] bus no 8
[ 286.921232] PCI: Claiming :00:01.0: Resource 15:
8001..8004afff [220c]
[ 287.229190]
On 3/30/15 7:06 PM, Yinghai Lu wrote:
ok, that is really non-pref mmio 64bit.
We can workaround the problem by honoring firmware setting, according
to
https://www.pcisig.com/specifications/pciexpress/base2/PCIe_Base_r2.1_Errata_08Jun10.pdf
page 13
Please check attached updated patches that
On Sun, Mar 29, 2015 at 7:47 AM, David Ahern wrote:
> On 3/28/15 2:24 PM, Yinghai Lu wrote:
>>
>> Can you append "ofpci_debug=1" in boot command line?
>
>
> here you go.
[ 286.647560] PCI: scan_bus[/pci@300/pci@1/pci@0/pci@6] bus no 8
[ 286.921232] PCI: Claiming :00:01.0: Resource 15:
From: Bjorn Helgaas
Date: Sun, 29 Mar 2015 08:30:40 -0500
> Help me understand the sparc64 situation: are you saying that BAR
> addresses, i.e., MMIO transactions from a CPU or a peer-to-peer DMA can be
> 64 bits, but a DMA to main memory can only be 32 bits?
>
> I assume this would work if we
From: Bjorn Helgaas bjorn.helg...@gmail.com
Date: Sun, 29 Mar 2015 08:30:40 -0500
Help me understand the sparc64 situation: are you saying that BAR
addresses, i.e., MMIO transactions from a CPU or a peer-to-peer DMA can be
64 bits, but a DMA to main memory can only be 32 bits?
I assume this
On Sun, Mar 29, 2015 at 7:47 AM, David Ahern david.ah...@oracle.com wrote:
On 3/28/15 2:24 PM, Yinghai Lu wrote:
Can you append ofpci_debug=1 in boot command line?
here you go.
[ 286.647560] PCI: scan_bus[/pci@300/pci@1/pci@0/pci@6] bus no 8
[ 286.921232] PCI: Claiming :00:01.0:
On Sat, Mar 28, 2015 at 7:48 AM, David Ahern wrote:
> On 3/27/15 11:26 PM, Yinghai Lu wrote:
>>
>>
>> looks like the offset for mem64 is not right.
>>
>> Please try attached v2.
still have problem.
[139295.760918] pci_sun4v f02dbcfc: PCI host bridge to bus :00
[139295.831448] pci_bus
On Sat, Mar 28, 2015 at 11:16 AM, David Miller wrote:
> PCI addresses being 64-bit or not is an attribute of the PCI
> controller and the geography of the bridges behind it, not the
> cpu architecture.
Good point. We should add one choice in pci subsystem Kconfig.
Thanks
Yinghai
--
To
From: Yinghai Lu
Date: Fri, 27 Mar 2015 16:57:23 -0700
> On Fri, Mar 27, 2015 at 2:01 PM, Yinghai Lu wrote:
>> On Thu, Mar 26, 2015 at 4:27 PM, David Ahern wrote:
>
>> Also please make sure your config have
>>
>> CONFIG_PCI_DEBUG=y
>>
>> and capture serial console with "debug
On 3/27/15 11:26 PM, Yinghai Lu wrote:
On Fri, Mar 27, 2015 at 8:45 PM, David Ahern wrote:
On 3/27/15 9:19 PM, Yinghai Lu wrote:
Good. But we still have annoying warning about "no compatible window".
Please try attached patch that support 64bit pci mem space for sparc.
BTW, looks like you
> >> config ARM_THUMB
> >> bool "Support Thumb user binaries" if !CPU_THUMBONLY
> >> depends on CPU_ARM720T || CPU_ARM740T || CPU_ARM920T || CPU_ARM922T
> >> || \
> >> Index: linux-2.6/arch/arm64/Kconfig
> >> ===
> >>
On Sat, Mar 28, 2015 at 7:48 AM, David Ahern david.ah...@oracle.com wrote:
On 3/27/15 11:26 PM, Yinghai Lu wrote:
looks like the offset for mem64 is not right.
Please try attached v2.
still have problem.
[139295.760918] pci_sun4v f02dbcfc: PCI host bridge to bus :00
[139295.831448]
On Sat, Mar 28, 2015 at 11:16 AM, David Miller da...@davemloft.net wrote:
PCI addresses being 64-bit or not is an attribute of the PCI
controller and the geography of the bridges behind it, not the
cpu architecture.
Good point. We should add one choice in pci subsystem Kconfig.
Thanks
On 3/27/15 11:26 PM, Yinghai Lu wrote:
On Fri, Mar 27, 2015 at 8:45 PM, David Ahern david.ah...@oracle.com wrote:
On 3/27/15 9:19 PM, Yinghai Lu wrote:
Good. But we still have annoying warning about no compatible window.
Please try attached patch that support 64bit pci mem space for sparc.
From: Yinghai Lu ying...@kernel.org
Date: Fri, 27 Mar 2015 16:57:23 -0700
On Fri, Mar 27, 2015 at 2:01 PM, Yinghai Lu ying...@kernel.org wrote:
On Thu, Mar 26, 2015 at 4:27 PM, David Ahern david.ah...@oracle.com wrote:
Also please make sure your config have
CONFIG_PCI_DEBUG=y
and capture
config ARM_THUMB
bool Support Thumb user binaries if !CPU_THUMBONLY
depends on CPU_ARM720T || CPU_ARM740T || CPU_ARM920T || CPU_ARM922T
|| \
Index: linux-2.6/arch/arm64/Kconfig
===
---
On Fri, Mar 27, 2015 at 8:45 PM, David Ahern wrote:
> On 3/27/15 9:19 PM, Yinghai Lu wrote:
>>
>> Good. But we still have annoying warning about "no compatible window".
>>
>> Please try attached patch that support 64bit pci mem space for sparc.
>>
>> BTW, looks like you still do not have
On 3/27/15 9:19 PM, Yinghai Lu wrote:
Good. But we still have annoying warning about "no compatible window".
Please try attached patch that support 64bit pci mem space for sparc.
BTW, looks like you still do not have CONFIG_PCI_DEBUG=y in your .config.
otherwise we should more verbose print
On Fri, Mar 27, 2015 at 8:22 PM, David Ahern wrote:
> On 3/27/15 9:19 PM, Yinghai Lu wrote:
>>
>> Good. But we still have annoying warning about "no compatible window".
>>
>> Please try attached patch that support 64bit pci mem space for sparc.
>
>
> in place of or on top of the previous patch?
On 3/27/15 9:19 PM, Yinghai Lu wrote:
Good. But we still have annoying warning about "no compatible window".
Please try attached patch that support 64bit pci mem space for sparc.
in place of or on top of the previous patch?
BTW, looks like you still do not have CONFIG_PCI_DEBUG=y in your
On Fri, Mar 27, 2015 at 5:36 PM, David Ahern wrote:
>>>
Also please make sure your config have
CONFIG_PCI_DEBUG=y
and capture serial console with "debug ignore_loglevel", so we check if
pci :00:01.0 really have resource assigned.
>>>
>>>
>>> Please check attached
On Fri, Mar 27, 2015 at 6:05 PM, Sam Ravnborg wrote:
>>
>> Index: linux-2.6/arch/alpha/Kconfig
>> ===
>> --- linux-2.6.orig/arch/alpha/Kconfig
>> +++ linux-2.6/arch/alpha/Kconfig
>> @@ -66,6 +66,9 @@ config ZONE_DMA
>> config
>
> Index: linux-2.6/arch/alpha/Kconfig
> ===
> --- linux-2.6.orig/arch/alpha/Kconfig
> +++ linux-2.6/arch/alpha/Kconfig
> @@ -66,6 +66,9 @@ config ZONE_DMA
> config ARCH_DMA_ADDR_T_64BIT
> def_bool y
>
> +config
On 3/27/15 6:32 PM, David Ahern wrote:
On 3/27/15 5:57 PM, Yinghai Lu wrote:
On Fri, Mar 27, 2015 at 2:01 PM, Yinghai Lu wrote:
On Thu, Mar 26, 2015 at 4:27 PM, David Ahern
wrote:
Also please make sure your config have
CONFIG_PCI_DEBUG=y
and capture serial console with "debug
On 3/27/15 5:57 PM, Yinghai Lu wrote:
On Fri, Mar 27, 2015 at 2:01 PM, Yinghai Lu wrote:
On Thu, Mar 26, 2015 at 4:27 PM, David Ahern wrote:
Also please make sure your config have
CONFIG_PCI_DEBUG=y
and capture serial console with "debug ignore_loglevel", so we check if
pci :00:01.0
On Fri, Mar 27, 2015 at 2:01 PM, Yinghai Lu wrote:
> On Thu, Mar 26, 2015 at 4:27 PM, David Ahern wrote:
> Also please make sure your config have
>
> CONFIG_PCI_DEBUG=y
>
> and capture serial console with "debug ignore_loglevel", so we check if
> pci :00:01.0 really have resource assigned.
On Fri, Mar 27, 2015 at 2:50 PM, David Miller wrote:
> All DMA occurs behind an IOMMU and these IOMMUs only
> support 32-bit addressing, therefore dma_addr_t is
> 32-bit on sparc64.
>
> If you want to represent PCI address in some way, you
> absolutely cannot use dma_addr_t as your data type.
From: Yinghai Lu
Date: Fri, 27 Mar 2015 14:01:54 -0700
> On Thu, Mar 26, 2015 at 4:27 PM, David Ahern wrote:
>> On 3/26/15 2:43 PM, Yinghai Lu wrote:
>>>
>>> Can you send out boot log with "debug ignore_loglevel"?
>>
>>
>> attached
>
> So the kernel config is sparc32 or sparc64 ?
>
> pci
On Thu, Mar 26, 2015 at 4:27 PM, David Ahern wrote:
> On 3/26/15 2:43 PM, Yinghai Lu wrote:
>>
>> Can you send out boot log with "debug ignore_loglevel"?
>
>
> attached
So the kernel config is sparc32 or sparc64 ?
pci :06:00.0: reg 0x184: can't handle BAR above 4GB (bus address
0x110204000)
On Thu, Mar 26, 2015 at 4:27 PM, David Ahern david.ah...@oracle.com wrote:
On 3/26/15 2:43 PM, Yinghai Lu wrote:
Can you send out boot log with debug ignore_loglevel?
attached
So the kernel config is sparc32 or sparc64 ?
pci :06:00.0: reg 0x184: can't handle BAR above 4GB (bus address
From: Yinghai Lu ying...@kernel.org
Date: Fri, 27 Mar 2015 14:01:54 -0700
On Thu, Mar 26, 2015 at 4:27 PM, David Ahern david.ah...@oracle.com wrote:
On 3/26/15 2:43 PM, Yinghai Lu wrote:
Can you send out boot log with debug ignore_loglevel?
attached
So the kernel config is sparc32 or
On Fri, Mar 27, 2015 at 2:50 PM, David Miller da...@davemloft.net wrote:
All DMA occurs behind an IOMMU and these IOMMUs only
support 32-bit addressing, therefore dma_addr_t is
32-bit on sparc64.
If you want to represent PCI address in some way, you
absolutely cannot use dma_addr_t as your
Index: linux-2.6/arch/alpha/Kconfig
===
--- linux-2.6.orig/arch/alpha/Kconfig
+++ linux-2.6/arch/alpha/Kconfig
@@ -66,6 +66,9 @@ config ZONE_DMA
config ARCH_DMA_ADDR_T_64BIT
def_bool y
+config
On Fri, Mar 27, 2015 at 6:05 PM, Sam Ravnborg s...@ravnborg.org wrote:
Index: linux-2.6/arch/alpha/Kconfig
===
--- linux-2.6.orig/arch/alpha/Kconfig
+++ linux-2.6/arch/alpha/Kconfig
@@ -66,6 +66,9 @@ config ZONE_DMA
config
On Fri, Mar 27, 2015 at 5:36 PM, David Ahern david.ah...@oracle.com wrote:
Also please make sure your config have
CONFIG_PCI_DEBUG=y
and capture serial console with debug ignore_loglevel, so we check if
pci :00:01.0 really have resource assigned.
Please check attached patch and send
On 3/27/15 9:19 PM, Yinghai Lu wrote:
Good. But we still have annoying warning about no compatible window.
Please try attached patch that support 64bit pci mem space for sparc.
in place of or on top of the previous patch?
BTW, looks like you still do not have CONFIG_PCI_DEBUG=y in your
On 3/27/15 5:57 PM, Yinghai Lu wrote:
On Fri, Mar 27, 2015 at 2:01 PM, Yinghai Lu ying...@kernel.org wrote:
On Thu, Mar 26, 2015 at 4:27 PM, David Ahern david.ah...@oracle.com wrote:
Also please make sure your config have
CONFIG_PCI_DEBUG=y
and capture serial console with debug
On 3/27/15 6:32 PM, David Ahern wrote:
On 3/27/15 5:57 PM, Yinghai Lu wrote:
On Fri, Mar 27, 2015 at 2:01 PM, Yinghai Lu ying...@kernel.org wrote:
On Thu, Mar 26, 2015 at 4:27 PM, David Ahern david.ah...@oracle.com
wrote:
Also please make sure your config have
CONFIG_PCI_DEBUG=y
and
On 3/27/15 9:19 PM, Yinghai Lu wrote:
Good. But we still have annoying warning about no compatible window.
Please try attached patch that support 64bit pci mem space for sparc.
BTW, looks like you still do not have CONFIG_PCI_DEBUG=y in your .config.
otherwise we should more verbose print
On Fri, Mar 27, 2015 at 2:01 PM, Yinghai Lu ying...@kernel.org wrote:
On Thu, Mar 26, 2015 at 4:27 PM, David Ahern david.ah...@oracle.com wrote:
Also please make sure your config have
CONFIG_PCI_DEBUG=y
and capture serial console with debug ignore_loglevel, so we check if
pci :00:01.0
On Fri, Mar 27, 2015 at 8:22 PM, David Ahern david.ah...@oracle.com wrote:
On 3/27/15 9:19 PM, Yinghai Lu wrote:
Good. But we still have annoying warning about no compatible window.
Please try attached patch that support 64bit pci mem space for sparc.
in place of or on top of the previous
On Fri, Mar 27, 2015 at 8:45 PM, David Ahern david.ah...@oracle.com wrote:
On 3/27/15 9:19 PM, Yinghai Lu wrote:
Good. But we still have annoying warning about no compatible window.
Please try attached patch that support 64bit pci mem space for sparc.
BTW, looks like you still do not have
On 3/26/15 2:43 PM, Yinghai Lu wrote:
Can you send out boot log with "debug ignore_loglevel"?
attached
PROMLIB: Sun IEEE Boot Prom 'OBP 4.36.2 2014/10/24 08:15'
PROMLIB: Root node compatible: sun4v
Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Initializing cgroup subsys
[+bjorn, pci list]
On Thu, Mar 26, 2015 at 9:51 AM, David Ahern wrote:
> Hi:
>
> Boot of an 8-socket T5 sparc system fails on top of tree. git bisect points
> to this commit:
>
> commit 904bf6bd150bdafb42ddbb3257ea8
> Author: Yinghai Lu
> Date: Thu Jan 15 16:21:51 2015 -0600
>
> sparc/PCI:
Hi:
Boot of an 8-socket T5 sparc system fails on top of tree. git bisect
points to this commit:
commit 904bf6bd150bdafb42ddbb3257ea8
Author: Yinghai Lu
Date: Thu Jan 15 16:21:51 2015 -0600
sparc/PCI: Clip bridge windows to fit in upstream windows
Every PCI-PCI bridge window should fit
Hi:
Boot of an 8-socket T5 sparc system fails on top of tree. git bisect
points to this commit:
commit 904bf6bd150bdafb42ddbb3257ea8
Author: Yinghai Lu ying...@kernel.org
Date: Thu Jan 15 16:21:51 2015 -0600
sparc/PCI: Clip bridge windows to fit in upstream windows
Every PCI-PCI bridge
[+bjorn, pci list]
On Thu, Mar 26, 2015 at 9:51 AM, David Ahern david.ah...@oracle.com wrote:
Hi:
Boot of an 8-socket T5 sparc system fails on top of tree. git bisect points
to this commit:
commit 904bf6bd150bdafb42ddbb3257ea8
Author: Yinghai Lu ying...@kernel.org
Date: Thu Jan 15
On 3/26/15 2:43 PM, Yinghai Lu wrote:
Can you send out boot log with debug ignore_loglevel?
attached
PROMLIB: Sun IEEE Boot Prom 'OBP 4.36.2 2014/10/24 08:15'
PROMLIB: Root node compatible: sun4v
Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Initializing cgroup subsys
74 matches
Mail list logo
