Hi,
On Wed, Oct 18, 2017 at 7:54 PM, Andy Shevchenko
wrote:
> While Rafael is looking for a solution, can you in meantime gather the
> following on the affected hardware and share it via some resource on
> Internet?
>
> 1. % acpidump -o tables.dat # tables.dat is point of interest
https://gist.g
On Wed, Oct 18, 2017 at 11:36 AM, Daniel Drake wrote:
> [retitling and re-summarizing in hope of attention from Intel]
>
> Andy / Rafael,
>
> Thomas Gleixner suggested that you might be able to help with a nasty
> issue related to Intel Apollo Lake platforms - or you can put us in
> contact with a
On Wednesday, October 18, 2017 10:36:49 AM CEST Daniel Drake wrote:
> [retitling and re-summarizing in hope of attention from Intel]
>
> Andy / Rafael,
>
> Thomas Gleixner suggested that you might be able to help with a nasty
> issue related to Intel Apollo Lake platforms - or you can put us in
>
> Subject: Re: PCIe MSI address is not written at pci_enable_msi_range call
>
> +tglx
>
> On 13/07/16 09:33, Bharat Kumar Gogada wrote:
> >> Subject: Re: PCIe MSI address is not written at pci_enable_msi_range
> >> call
> >>
> >> On 13/07/16 0
+tglx
On 13/07/16 09:33, Bharat Kumar Gogada wrote:
>> Subject: Re: PCIe MSI address is not written at pci_enable_msi_range call
>>
>> On 13/07/16 07:22, Bharat Kumar Gogada wrote:
>>>> Subject: Re: PCIe MSI address is not written at pci_enable_msi_range
>>
On 13/07/16 16:34, Bharat Kumar Gogada wrote:
>> On 13/07/16 10:36, Bharat Kumar Gogada wrote:
>>>> Subject: Re: PCIe MSI address is not written at pci_enable_msi_range
>>>> call
>>>>
>>>> On 13/07/16 10:10, Bharat Kumar Gogada wrote:
> On 13/07/16 10:36, Bharat Kumar Gogada wrote:
> >> Subject: Re: PCIe MSI address is not written at pci_enable_msi_range
> >> call
> >>
> >> On 13/07/16 10:10, Bharat Kumar Gogada wrote:
> >>>> Subject: Re: PCIe MSI address is not written at
&
On 13/07/16 10:36, Bharat Kumar Gogada wrote:
>> Subject: Re: PCIe MSI address is not written at pci_enable_msi_range call
>>
>> On 13/07/16 10:10, Bharat Kumar Gogada wrote:
>>>> Subject: Re: PCIe MSI address is not written at pci_enable_msi_range
>>>>
> Subject: Re: PCIe MSI address is not written at pci_enable_msi_range call
>
> On 13/07/16 10:10, Bharat Kumar Gogada wrote:
> >> Subject: Re: PCIe MSI address is not written at pci_enable_msi_range
> >> call
> >>
> >> On 13/07/16 09:33, Bharat Kum
On 13/07/16 10:10, Bharat Kumar Gogada wrote:
>> Subject: Re: PCIe MSI address is not written at pci_enable_msi_range call
>>
>> On 13/07/16 09:33, Bharat Kumar Gogada wrote:
>>>> Subject: Re: PCIe MSI address is not written at pci_enable_msi_range call
>>>
> Subject: Re: PCIe MSI address is not written at pci_enable_msi_range call
>
> On 13/07/16 09:33, Bharat Kumar Gogada wrote:
> >> Subject: Re: PCIe MSI address is not written at pci_enable_msi_range call
> >>
> >> On 13/07/16 07:22, Bharat Kumar Gogada wrote:
On 13/07/16 09:33, Bharat Kumar Gogada wrote:
>> Subject: Re: PCIe MSI address is not written at pci_enable_msi_range call
>>
>> On 13/07/16 07:22, Bharat Kumar Gogada wrote:
>>>> Subject: Re: PCIe MSI address is not written at pci_enable_msi_range
>>>>
> Subject: Re: PCIe MSI address is not written at pci_enable_msi_range call
>
> On 13/07/16 07:22, Bharat Kumar Gogada wrote:
> >> Subject: Re: PCIe MSI address is not written at pci_enable_msi_range
> >> call
> >>
> >> On 11/07/16 10
On 13/07/16 07:22, Bharat Kumar Gogada wrote:
>> Subject: Re: PCIe MSI address is not written at pci_enable_msi_range call
>>
>> On 11/07/16 10:33, Bharat Kumar Gogada wrote:
>>> Hi Marc,
>>>
>>> Thanks for the reply.
>>>
>>> From PCIe
> Subject: Re: PCIe MSI address is not written at pci_enable_msi_range call
>
> On 11/07/16 10:33, Bharat Kumar Gogada wrote:
> > Hi Marc,
> >
> > Thanks for the reply.
> >
> > From PCIe Spec:
> > MSI Enable Bit:
> > If 1 and the MSI-X Enable
On 11/07/16 10:33, Bharat Kumar Gogada wrote:
> Hi Marc,
>
> Thanks for the reply.
>
> From PCIe Spec:
> MSI Enable Bit:
> If 1 and the MSI-X Enable bit in the MSI-X Message
> Control register (see Section 6.8.2.3) is 0, the
> function is permitted to use MSI to request service
> and is prohibite
On 12/07/16 10:11, Bharat Kumar Gogada wrote:
>> Subject: Re: PCIe MSI address is not written at pci_enable_msi_range call
>>
>> On 11/07/16 11:51, Bharat Kumar Gogada wrote:
>>>>> Hi Marc,
>>>>>
>>>>> Thanks for the reply.
>>>
> Subject: Re: PCIe MSI address is not written at pci_enable_msi_range call
>
> On 11/07/16 11:51, Bharat Kumar Gogada wrote:
> >>> Hi Marc,
> >>>
> >>> Thanks for the reply.
> >>>
> >>> From PCIe Spec:
> >>> MSI Enab
On 11/07/16 11:51, Bharat Kumar Gogada wrote:
>>> Hi Marc,
>>>
>>> Thanks for the reply.
>>>
>>> From PCIe Spec:
>>> MSI Enable Bit:
>>> If 1 and the MSI-X Enable bit in the MSI-X Message
>>> Control register (see Section 6.8.2.3) is 0, the
>>> function is permitted to use MSI to request service
>>
> > Hi Marc,
> >
> > Thanks for the reply.
> >
> > From PCIe Spec:
> > MSI Enable Bit:
> > If 1 and the MSI-X Enable bit in the MSI-X Message
> > Control register (see Section 6.8.2.3) is 0, the
> > function is permitted to use MSI to request service
> > and is prohibited from using its INTx# pin.
[Please don't top-post]
On 11/07/16 10:33, Bharat Kumar Gogada wrote:
> Hi Marc,
>
> Thanks for the reply.
>
> From PCIe Spec:
> MSI Enable Bit:
> If 1 and the MSI-X Enable bit in the MSI-X Message
> Control register (see Section 6.8.2.3) is 0, the
> function is permitted to use MSI to request s
.@vger.kernel.org; linux-kernel@vger.kernel.org
> Cc: Arnd Bergmann ; Bjorn Helgaas
>
> Subject: Re: PCIe MSI address is not written at pci_enable_msi_range call
>
> On 11/07/16 03:32, Bharat Kumar Gogada wrote:
> > Hi,
> >
> > I have a query.
> > I see that when
On 11/07/16 03:32, Bharat Kumar Gogada wrote:
> Hi,
>
> I have a query.
> I see that when we use PCI_MSI_IRQ_DOMAIN to handle MSI's, MSI address is not
> being
> written in to end point's PCI_MSI_ADDRESS_LO/HI at the call
> pci_enable_msi_range.
>
> Instead it is being written at the time end p
Hi Vinod/kanya,
> On 6/13/2016 1:25 AM, Vinod Koul wrote:
> >> We are planning to write a PCIe EndPoint DMA driver with DMA
> >> Framework
> >> > targeting x86 machine. (
> >> >
> "https://www.kernel.org/doc/Documentation/dmaengine/provider.txt";)
> >> > Our DMA controller is part of PCIe End Poi
On 6/13/2016 1:25 AM, Vinod Koul wrote:
>> We are planning to write a PCIe EndPoint DMA driver with DMA Framework
>> > targeting x86 machine. (
>> > "https://www.kernel.org/doc/Documentation/dmaengine/provider.txt";) Our DMA
>> > controller is part of PCIe End Point. We are targeting to measure P
On Fri, Jun 10, 2016 at 03:39:15PM +, Bharat Kumar Gogada wrote:
> Hi,
>
PLEASE wrap your replied to 80 chars.. I have reflown below..
> We are planning to write a PCIe EndPoint DMA driver with DMA Framework
> targeting x86 machine. (
> "https://www.kernel.org/doc/Documentation/dmaengine/p
Sorry Please neglect the footer. Forgot to configure some settings.
> Hi All,
>
> We are planning to write a PCIe EndPoint DMA driver with DMA Framework
> on x86 machine.
> ("https://www.kernel.org/doc/Documentation/dmaengine/provider.txt";)
> We are targeting to measure PCIe performance with this
Hi,
On Tuesday 24 November 2015 05:44 PM, Jisheng Zhang wrote:
>
>
> On Tue, 24 Nov 2015 17:31:07 +0530
> Kishon Vijay Abraham I wrote:
>
>> Hi,
>>
>> I'm seeing a regression with ("PCI:
>> designware: Make driver arch-agnostic").
>>
>> Logs using a SATA PCIe card [1]. The PCIe card enumerates
Hi,
On Tuesday 24 November 2015 05:38 PM, Gabriele Paoloni wrote:
> Hi Kishon
>
>> -Original Message-
>> From: Kishon Vijay Abraham I [mailto:kis...@ti.com]
>> Sent: 24 November 2015 12:01
>> To: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
>> o...@vger.kernel.org; jame
On Tue, 24 Nov 2015 17:31:07 +0530
Kishon Vijay Abraham I wrote:
> Hi,
>
> I'm seeing a regression with ("PCI:
> designware: Make driver arch-agnostic").
>
> Logs using a SATA PCIe card [1]. The PCIe card enumerates fine but after that
> I
> observe "ata3.00: qc timeout (cmd 0xec), ata3.00: f
Hi Kishon
> -Original Message-
> From: Kishon Vijay Abraham I [mailto:kis...@ti.com]
> Sent: 24 November 2015 12:01
> To: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> o...@vger.kernel.org; james.mo...@arm.com; gabriel.fernan...@st.com;
> minghuan.l...@freescale.com; Wa
On 13 November 2015 14:00, Arnd Bergmann wrote:
> On Friday 13 November 2015 13:03:11 Phil Edworthy wrote:
> >
> > > > Then pci_device_add() sets the devices coherent_dma_mask to 4GiB
> before
> > > > calling of_pci_dma_configure(). I assume it does this on the basis that
> > > > this is
> a
> > >
On Friday 13 November 2015 13:03:11 Phil Edworthy wrote:
>
> > > Then pci_device_add() sets the devices coherent_dma_mask to 4GiB before
> > > calling of_pci_dma_configure(). I assume it does this on the basis that
> > > this is a
> > > good default for PCI drivers that don't call dma_set_mask().
Hi Arnd,
On 12 November 2015 16:17, Arnd Bergmann wrote:
> On Thursday 12 November 2015 15:33:41 Phil Edworthy wrote:
> > On 12 November 2015 09:49, Arnd Bergmann wrote:
> > > On Thursday 12 November 2015 09:26:33 Phil Edworthy wrote:
> > > > On 11 November 2015 18:25, LIviu wrote:
> > > > > On Mo
On Thursday 12 November 2015 15:33:41 Phil Edworthy wrote:
> On 12 November 2015 09:49, Arnd Bergmann wrote:
> > On Thursday 12 November 2015 09:26:33 Phil Edworthy wrote:
> > > On 11 November 2015 18:25, LIviu wrote:
> > > > On Mon, Nov 09, 2015 at 12:32:13PM +, Phil Edworthy wrote:
> >
> > o
Hi Arnd,
On 12 November 2015 09:49, Arnd Bergmann wrote:
> On Thursday 12 November 2015 09:26:33 Phil Edworthy wrote:
> > On 11 November 2015 18:25, LIviu wrote:
> > > On Mon, Nov 09, 2015 at 12:32:13PM +, Phil Edworthy wrote:
>
> > > I think you're mixing things a bit or not explaining them
On Thu, Nov 12, 2015 at 09:26:33AM +, Phil Edworthy wrote:
> Hi Liviu, Arnd,
>
> On 11 November 2015 18:25, LIviu wrote:
> > On Mon, Nov 09, 2015 at 12:32:13PM +, Phil Edworthy wrote:
> > > Hi Liviu, Will,
> > >
> > > On 04 November 2015 15:19, Phil wrote:
> > > > On 04 November 2015 15:02
On Thursday 12 November 2015 09:26:33 Phil Edworthy wrote:
> On 11 November 2015 18:25, LIviu wrote:
> > On Mon, Nov 09, 2015 at 12:32:13PM +, Phil Edworthy wrote:
> > I think you're mixing things a bit or not explaining them very well. Having
> > the
> > PCIe controller limited to 32-bit AXI
Hi Liviu, Arnd,
On 11 November 2015 18:25, LIviu wrote:
> On Mon, Nov 09, 2015 at 12:32:13PM +, Phil Edworthy wrote:
> > Hi Liviu, Will,
> >
> > On 04 November 2015 15:19, Phil wrote:
> > > On 04 November 2015 15:02, Liviu wrote:
> > > > On Wed, Nov 04, 2015 at 02:48:38PM +, Phil Edworthy
On Wednesday 11 November 2015 18:24:56 liviu.du...@arm.com wrote:
>
> > Somewhat related to this, since our PCIe controller HW is limited to
> > 32-bit AXI address range, before trying to hook up the IOMMU I have
> > tried to limit the dma_mask for PCI cards to DMA_BIT_MASK(32). The
> > reason bei
On Mon, Nov 09, 2015 at 12:32:13PM +, Phil Edworthy wrote:
> Hi Liviu, Will,
>
> On 04 November 2015 15:19, Phil wrote:
> > On 04 November 2015 15:02, Liviu wrote:
> > > On Wed, Nov 04, 2015 at 02:48:38PM +, Phil Edworthy wrote:
> > > > Hi Liviu,
> > > >
> > > > On 04 November 2015 14:24,
Hi Liviu, Will,
On 04 November 2015 15:19, Phil wrote:
> On 04 November 2015 15:02, Liviu wrote:
> > On Wed, Nov 04, 2015 at 02:48:38PM +, Phil Edworthy wrote:
> > > Hi Liviu,
> > >
> > > On 04 November 2015 14:24, Liviu wrote:
> > > > On Wed, Nov 04, 2015 at 01:57:48PM +, Phil Edworthy wr
Hi Will,
On 04 November 2015 15:30, Will wrote:
> On Wed, Nov 04, 2015 at 03:19:13PM +, Phil Edworthy wrote:
> > On 04 November 2015 15:02, Liviu wrote:
> > > On Wed, Nov 04, 2015 at 02:48:38PM +, Phil Edworthy wrote:
> > > > Sure, though since this is bog standard Intel PCIe ethernet card
On Wed, Nov 04, 2015 at 03:19:13PM +, Phil Edworthy wrote:
> On 04 November 2015 15:02, Liviu wrote:
> > On Wed, Nov 04, 2015 at 02:48:38PM +, Phil Edworthy wrote:
> > > Sure, though since this is bog standard Intel PCIe ethernet card which
> > > works
> > > fine when the IOMMU is effectiv
Hi Liviu,
On 04 November 2015 15:02, Liviu wrote:
> On Wed, Nov 04, 2015 at 02:48:38PM +, Phil Edworthy wrote:
> > Hi Liviu,
> >
> > On 04 November 2015 14:24, Liviu wrote:
> > > On Wed, Nov 04, 2015 at 01:57:48PM +, Phil Edworthy wrote:
> > > > Hi,
> > > >
> > > > I am trying to hook up a
On Wed, Nov 04, 2015 at 02:48:38PM +, Phil Edworthy wrote:
> Hi Liviu,
>
> On 04 November 2015 14:24, Liviu wrote:
> > On Wed, Nov 04, 2015 at 01:57:48PM +, Phil Edworthy wrote:
> > > Hi,
> > >
> > > I am trying to hook up a PCIe host controller that sits behind an IOMMU,
> > > but having
Hi Liviu,
On 04 November 2015 14:24, Liviu wrote:
> On Wed, Nov 04, 2015 at 01:57:48PM +, Phil Edworthy wrote:
> > Hi,
> >
> > I am trying to hook up a PCIe host controller that sits behind an IOMMU,
> > but having some problems.
> >
> > I'm using the pcie-rcar PCIe host controller and it work
On Wed, Nov 04, 2015 at 01:57:48PM +, Phil Edworthy wrote:
> Hi,
>
> I am trying to hook up a PCIe host controller that sits behind an IOMMU,
> but having some problems.
>
> I'm using the pcie-rcar PCIe host controller and it works fine without
> the IOMMU, and I can attach the IOMMU to the c
On Tue, Sep 29, 2015 at 7:04 AM, Ruud wrote:
>
> (for illustration, lspci -tv from a 3.2 kernel, hand edited as the
> original picture has already discovered the subordinate busses)
> +-02.0-[04-17]00.0-[05-17]--+-04.0-[06-16]00.0-[07-16]---
> |
>>
>> Thus the procedure that works is:
>> 1) Chassis off
>> 2) Boot linux
>> 3) Chassis on
>> 4) setpci busnrs to 0
>> 5) remove switch
>> 6) rescan
>
> 4, 5 is reversed?
I can not setpci on a removed device, afaik for that reason I
reset the busses before removing the switch (not physically
On Mon, Sep 21, 2015 at 7:06 AM, Ruud wrote:
> 2015-09-21 9:49 GMT+02:00 Ruud :
> Test result based upon
>
> http://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
> 7e3fad2 (for-pci-v4.3-rc1)
>
> Unfortunately your script hangs the system, I modified it for my
> situation (only
On Mon, Sep 21, 2015 at 12:49 AM, Ruud wrote:
> Sorry for the rookie question: which version do you mean by "current
> upstream", the current main trunk rc?.
current linus tree like v4.2 or v4.3-rc1 etc
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a me
2015-09-21 9:49 GMT+02:00 Ruud :
>> /sbin/setpci -s $NAME 0x1a.b=0
>> N=`find /sys/devices/pci:"$BUS"/"$NAME"/remove -name "remove"`
>> echo $N
>> echo -n 1 > "$N"
>> sleep 1s
>> done
>> done
>>
>
> Thanks for the script!
>
>>
>>>
>>> I will test next monday.
>
> /sbin/setpci -s $NAME 0x1a.b=0
> N=`find /sys/devices/pci:"$BUS"/"$NAME"/remove -name "remove"`
> echo $N
> echo -n 1 > "$N"
> sleep 1s
> done
> done
>
Thanks for the script!
>
>>
>> I will test next monday.
>
> Good. Please check current upstream and my tr
On Sun, Sep 20, 2015 at 2:17 AM, Ruud wrote:
>
> The current procedure I follow is to boot with two PCIe switches in the host.
> (one at the root complex level, intel based, one level above PLX
> based, and the whole tree in the chassis).
>
> - I turn off the chassis (as it conflicts with the BIOS
>> The current algorithm seems to allocate 8 extra busnumbers at the
>> hotplug switch, but clearly 8 is not sufficient for the whole tree
>> when it is discovered after initial numbering has been assigned. As
>> the PCIe routing requires the bus numbers to be consecutive as it
>> describes ranges
On Sat, Sep 19, 2015 at 1:20 AM, Ruud wrote:
> Hello all,
>
> Not a patch, not a complaint: a start of a discussion on PCIe bus
> renumbering and bus numbering in general..
>
>
> The current algorithm seems to allocate 8 extra busnumbers at the
> hotplug switch, but clearly 8 is not sufficient for
On Wed, Sep 16, 2015 at 12:08 PM, Ruudgoogle wrote:
>
> For a big system i use an external pcie enclosure. Unfortunately the bios
> fails to properly initialise the system. As work around i plan to start the
> chassis after the linux kernel has booted. This leads to some other problems
> i wou
On Fri, Jun 19, 2015 at 11:20 AM, Bharat Kumar Gogada
wrote:
> Hi
>
> I am developing PCIe root port driver for Xilinx device. We have used
> following patch for ARM64 bit support "https://lkml.org/lkml/2014/7/3/764";.
> The link explains it as temporary patch and main line will be updated soon
On Wed, Mar 04, 2015 at 11:01:59AM -0600, Bjorn Helgaas wrote:
> On Wed, Mar 04, 2015 at 03:12:04PM +0800, Daniel J Blueman wrote:
> > Your patch solves the conflicts nicely [1] with:
> >
> > From f835b16b0758a1dde6042a0e4c8aa5a2e8be5f21 Mon Sep 17 00:00:00 2001
> > From: Daniel J Blueman
> > Dat
On Wed, Mar 04, 2015 at 03:12:04PM +0800, Daniel J Blueman wrote:
> Your patch solves the conflicts nicely [1] with:
>
> From f835b16b0758a1dde6042a0e4c8aa5a2e8be5f21 Mon Sep 17 00:00:00 2001
> From: Daniel J Blueman
> Date: Wed, 4 Mar 2015 14:53:00 +0800
> Subject: [PATCH] Mark PCI BARs with add
On 04/03/2015 06:38, Bjorn Helgaas wrote:
[+cc linux-pci, linux-acpi]
On Tue, Feb 24, 2015 at 12:37:39PM +0800, Daniel J Blueman wrote:
Hi Bjorn, Jiang,
On 29/01/2015 23:23, Bjorn Helgaas wrote:
Hi Daniel,
On Wed, Jan 28, 2015 at 2:42 AM, Daniel J Blueman wrote:
With systems with a large n
[+cc linux-pci, linux-acpi]
On Tue, Feb 24, 2015 at 12:37:39PM +0800, Daniel J Blueman wrote:
> Hi Bjorn, Jiang,
>
> On 29/01/2015 23:23, Bjorn Helgaas wrote:
> >Hi Daniel,
> >
> >On Wed, Jan 28, 2015 at 2:42 AM, Daniel J Blueman
> >wrote:
> >>With systems with a large number of PCI devices, we
Hi Bjorn, Jiang,
On 29/01/2015 23:23, Bjorn Helgaas wrote:
Hi Daniel,
On Wed, Jan 28, 2015 at 2:42 AM, Daniel J Blueman wrote:
With systems with a large number of PCI devices, we're seeing lack of 32-bit
MMIO space, eg one quad-port NetXtreme-2 adapter takes 128MB of space [1].
An errata to
[+cc Yinghai]
Hi Daniel,
On Wed, Jan 28, 2015 at 2:42 AM, Daniel J Blueman wrote:
> With systems with a large number of PCI devices, we're seeing lack of 32-bit
> MMIO space, eg one quad-port NetXtreme-2 adapter takes 128MB of space [1].
>
> An errata to the PCIe 2.1 spec provides guidance on li
On Wed, Oct 15, 2014 at 09:50:58PM -0600, Bjorn Helgaas wrote:
> [+cc Joerg, Suravee, Jay, iommu list, linux-pci]
>
> On Wed, Oct 15, 2014 at 5:44 PM, Kallol Biswas wrote:
> > Resending, as message got bounced for html content.
> >
> > Hi,
> > PCIe
[+cc Joerg, Suravee, Jay, iommu list, linux-pci]
On Wed, Oct 15, 2014 at 5:44 PM, Kallol Biswas wrote:
> Resending, as message got bounced for html content.
>
> Hi,
> PCIe has introduced PASID TLP Prefix. There are two ECNs on this.
>
> It seems t
Hi,
PCIe has introduced PASID TLP Prefix. There are two ECNs on this.
It seems that AMD iommu code makes use of PASID. Is there a device that
utilizes this TLP prefix?
PASID allocation and management within a device is not clear to me. How
does device know which PASID to issue for with virtu
On Tuesday 08 July 2014 14:27:00 Bjorn Helgaas wrote:
> On Tue, Jul 8, 2014 at 1:20 PM, Federico Vaga
wrote:
> > On Tuesday 08 July 2014 12:23:39 Bjorn Helgaas wrote:
> >> On Tue, Jul 8, 2014 at 1:15 AM, Federico Vaga
> >
> > wrote:
> >> >> > So, It looks like that some BIOS disable the bridge
On Tue, Jul 8, 2014 at 1:20 PM, Federico Vaga wrote:
> On Tuesday 08 July 2014 12:23:39 Bjorn Helgaas wrote:
>> On Tue, Jul 8, 2014 at 1:15 AM, Federico Vaga
> wrote:
>> >> > So, It looks like that some BIOS disable the bridge when there
>> >> > is
>> >> > nothing behind it. Why? Power save? :/
>
On Tuesday 08 July 2014 12:23:39 Bjorn Helgaas wrote:
> On Tue, Jul 8, 2014 at 1:15 AM, Federico Vaga
wrote:
> >> > So, It looks like that some BIOS disable the bridge when there
> >> > is
> >> > nothing behind it. Why? Power save? :/
> >>
> >> Could be power savings, or possibly to conserve bus
On Tue, Jul 8, 2014 at 1:15 AM, Federico Vaga wrote:
>> > So, It looks like that some BIOS disable the bridge when there is
>> > nothing behind it. Why? Power save? :/
>>
>> Could be power savings, or possibly to conserve bus numbers, which
>> are a limited resource.
>
> what is the maximum number
(I'm changing my email address to the work one. Initially it was just
my personal curiosity but now you are helping me with my work, so I
think is correct in this way)
> > So, It looks like that some BIOS disable the bridge when there is
> > nothing behind it. Why? Power save? :/
>
> Could be p
On Mon, Jul 7, 2014 at 1:29 AM, Federico Vaga wrote:
> On Friday 04 July 2014 15:26:12 Bjorn Helgaas wrote:
>> On Fri, Jul 04, 2014 at 09:55:20AM +0200, Federico Vaga wrote:
>> > > I assume these ports don't support hotplug. If they *did*
>> > > support
>> > > hotplug, those ports would have to e
On Friday 04 July 2014 15:26:12 Bjorn Helgaas wrote:
> On Fri, Jul 04, 2014 at 09:55:20AM +0200, Federico Vaga wrote:
> > > I assume these ports don't support hotplug. If they *did*
> > > support
> > > hotplug, those ports would have to exist because they handle the
> > > hotplug events (presence
On Fri, Jul 04, 2014 at 09:55:20AM +0200, Federico Vaga wrote:
> > I assume these ports don't support hotplug. If they *did* support
> > hotplug, those ports would have to exist because they handle the
> > hotplug events (presence detect, etc.)
>
> I asked: yes, they do not support hotplug
>
> >
On Thu, Jul 3, 2014 at 2:40 PM, Federico Vaga wrote:
> On Thursday 03 July 2014 13:43:14 Bjorn Helgaas wrote:
>> The /sys/bus/pci/slots/*/address files might help. On my system, I
>> have:
>>
>> $ grep . /sys/bus/pci/slots/*/address /dev/null
>> /sys/bus/pci/slots/5/address::03:00
>
> My
(Sorry for double emailing, a sw update changes my configuration to
HTML email as default.So, the linux kernel mailing list complains that
probably I'm spamming)
On Thursday 03 July 2014 13:43:14 Bjorn Helgaas wrote:
> On Thu, Jul 3, 2014 at 10:45 AM, Federico Vaga
wrote:
> > Hello,
> >
> > (
On Thu, Jul 3, 2014 at 10:45 AM, Federico Vaga wrote:
> Hello,
>
> (I haven't a deep knowledge of the PCIe specification, maybe I'm just
> missing something)
>
> is there a way to force the PCI subsystem to assign a bus-number to
> every PCIe bridge, even if there is nothing connected?
>
>
> My ai
Hi, Takao
On 07/12/2013 10:39 AM, Takao Indoh wrote:
> Hi Dave,
>
> (2013/07/12 11:04), Dave Young wrote:
>> Hi, Takao
>>
>> I know you are working on the PCIE resetting patches for the iommu kdump
>> issue.
>>
>> You explicitly excluded the graphic card in your patch. I have some
>> questions abo
Hi Dave,
(2013/07/12 11:04), Dave Young wrote:
> Hi, Takao
>
> I know you are working on the PCIE resetting patches for the iommu kdump
> issue.
>
> You explicitly excluded the graphic card in your patch. I have some
> questions about this. Why can't we reset the graphic card like other
> pcie d
2013-06-12 15:54-0600, Bjorn Helgaas:
> [+cc linux-pci, Myron, Joe]
I'll remember it.
> On Wed, Jun 12, 2013 at 11:21 AM, Radim Krčmář wrote:
> > Hello,
> >
> > as a consequence of hitting a NULL dereference bug[1] while downstream
> > aspm is setting up link_state, I started to wonder why is th
[+cc linux-pci, Myron, Joe]
On Wed, Jun 12, 2013 at 11:21 AM, Radim Krčmář wrote:
> Hello,
>
> as a consequence of hitting a NULL dereference bug[1] while downstream
> aspm is setting up link_state, I started to wonder why is the code
> skipping its parent bus in favour of grandparent's link_stat
Hi All,
In my Graphics card, it has 4 memory requirement:
a. 32 bit non-prefetchable
b. 32 bit prefetchable
c. 64 bit non-prefetchable.
d. 64 bit prefetchable
And I see a is programmed in BAR0(offset 0x10), c in BAR3(offset 0x1C), d in
BAR1(offset 0x14) but b is not programmed anywhere.
So is
On Fri, Mar 22, 2013 at 05:59:13PM +0530, Jay Agarwal wrote:
> I don't see can't assign things now on Thierry's latest repo() + my tegra3
> support patch, but some reconfiguring things are still there as below:
>
> bridge configuration invalid ([bus 00-00]), reconfiguring
>
>
>
> I am not su
On Fri, Oct 26, 2012 at 7:39 PM, Cyberman Wu wrote:
> On Sat, Oct 27, 2012 at 12:28 AM, Bjorn Helgaas wrote:
>> On Fri, Oct 26, 2012 at 8:08 AM, Chris Metcalf wrote:
>>
>>> Cyberman: it seems like your bias hack is working for you. But, as Bjorn
>>> says, this sounds like a driver bug. What ha
On Sat, Oct 27, 2012 at 12:28 AM, Bjorn Helgaas wrote:
> On Fri, Oct 26, 2012 at 8:08 AM, Chris Metcalf wrote:
>
>> Cyberman: it seems like your bias hack is working for you. But, as Bjorn
>> says, this sounds like a driver bug. What happens if you just revert your
>> changes, but then in mvsas
On Fri, Oct 26, 2012 at 8:08 AM, Chris Metcalf wrote:
> Cyberman: it seems like your bias hack is working for you. But, as Bjorn
> says, this sounds like a driver bug. What happens if you just revert your
> changes, but then in mvsas.c change the "if (!res_start || !res_len)" to
> just say "if
On 10/26/2012 4:03 AM, Bjorn Helgaas wrote:
> [+cc Chris, also a few comments below]
Bjorn, thanks for looping me in.
> On Fri, Oct 26, 2012 at 12:59 AM, Cyberman Wu wrote:
>> After we upgrade to MDE 4.1.0 from Tilera, we encounter a problem that
>> only on HighPoint 2680 card works, I've
>> tri
On Fri, Oct 26, 2012 at 3:01 AM, Cyberman Wu wrote:
> We're not using 3.6.x, we're using is from MDE-4.1.0 from Tilera and
> it patch 3.0.38.
That's fine, but you sent the email to the linux-pci and linux-kernel
lists, and on those lists, we're only concerned with the upstream
Linux kernels, e.g.
We're not using 3.6.x, we're using is from MDE-4.1.0 from Tilera and
it patch 3.0.38.
>From its release notes that PCIe I/O space is already supported.
I provide diff of pci_gx.c between 3.6.3 and MDE-4.1.0 for a hint,
since I don't know
if it's allowed to use attached file in mail list, and their
[+cc Chris, also a few comments below]
On Fri, Oct 26, 2012 at 12:59 AM, Cyberman Wu wrote:
> After we upgrade to MDE 4.1.0 from Tilera, we encounter a problem that
> only on HighPoint 2680 card works, I've
> tried to fix it, but since most time I'm working in user space, I'm
> not sure my fix is
On Wed, 2008-02-06 at 01:40 +0800, Дамјан Георгиевски wrote:
> I've patched my kernel with the PCIe ASPM and after setting
> echo powersave > /sys/module/pcie_aspm/parameters/policy
>
> I started to experience random hangs of my laptop.
> Hardware info:
> Thinkpad x60s 1704-5UG
> also tested on a
On Wed, Feb 06, 2008 at 01:46:22PM -0800, Kok, Auke wrote:
> Rafael J. Wysocki wrote:
> > On Wednesday, 6 of February 2008, Pavel Machek wrote:
> >> On Tue 2008-02-05 16:22:55, Kok, Auke wrote:
> >>> ?? ??? wrote:
> I've patched my kernel with the PCIe ASPM and after setting
>
Rafael J. Wysocki wrote:
> On Wednesday, 6 of February 2008, Pavel Machek wrote:
>> On Tue 2008-02-05 16:22:55, Kok, Auke wrote:
>>> ?? ??? wrote:
I've patched my kernel with the PCIe ASPM and after setting
echo powersave > /sys/module/pcie_aspm/parameters/policy
>
On Wednesday, 6 of February 2008, Pavel Machek wrote:
> On Tue 2008-02-05 16:22:55, Kok, Auke wrote:
> > ?? ??? wrote:
> > > I've patched my kernel with the PCIe ASPM and after setting
> > > echo powersave > /sys/module/pcie_aspm/parameters/policy
> > >
> > > I started t
On Tue 2008-02-05 16:22:55, Kok, Auke wrote:
> ?? ??? wrote:
> > I've patched my kernel with the PCIe ASPM and after setting
> > echo powersave > /sys/module/pcie_aspm/parameters/policy
> >
> > I started to experience random hangs of my laptop.
> > Hardware info:
> >
?? ??? wrote:
> I've patched my kernel with the PCIe ASPM and after setting
> echo powersave > /sys/module/pcie_aspm/parameters/policy
>
> I started to experience random hangs of my laptop.
> Hardware info:
> Thinkpad x60s 1704-5UG
the x60's chipset doesn't
> >>> I've patched my kernel with the PCIe ASPM and after setting
> >>> echo powersave > /sys/module/pcie_aspm/parameters/policy
> >>>
> >>> I started to experience random hangs of my laptop.
> >>> Hardware info:
> >>> Thinkpad x60s 1704-5UG
> >>
> >> the x60's chipset doesn't support ASPM properly
Greg KH wrote:
> On Tue, Feb 05, 2008 at 10:46:23AM -0800, Arjan van de Ven wrote:
>> On Tue, 5 Feb 2008 18:40:04 +0100
>> ?? <[EMAIL PROTECTED]> wrote:
>>
>>> I've patched my kernel with the PCIe ASPM and after setting
>>> echo powersave > /sys/module/pcie_aspm/pa
1 - 100 of 151 matches
Mail list logo
