All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: mroos@linux.ee
Cc: yinghai@kernel.org, linux-pci@vger.kernel.org,
	sparclinux@vger.kernel.org
Subject: Re: sparc64 PCI BAR allocation is still problematic
Date: Sun, 08 Apr 2018 17:21:52 -0400 (EDT)	[thread overview]
Message-ID: <20180408.172152.113123578529151252.davem@davemloft.net> (raw)
In-Reply-To: <alpine.LRH.2.21.1804081219340.17185@math.ut.ee>

From: Meelis Roos <mroos@linux.ee>
Date: Sun, 8 Apr 2018 21:44:57 +0300 (EEST)

> This is a followup on the thread https://lkml.org/lkml/2015/10/7/135 and 
> corresponding https://bugzilla.kernel.org/show_bug.cgi?id=117191 entry.
> 
> I saw some sparc64 PCI allocation changes in yesterdays git and compiled 
> 4.16.0-10242-gf605ba9 on most of my sparc64 machines to test if the PCI 
> BAR allocation problems introduced in 4.3 were fixed on some of them. 
> Alas, no change at all - of the test machines, none showed any changes 
> in the error messages in "dmesg | grep BAR".
> 
> There was one test machine, T1000 with no addon cards, that did not 
> encounter any problem, before or after the recent patch. All the other 
> test machines tried still have the BAR allocation problems.
> 
> The errors seem to cluster into 3 categories:
> 
> 1. many devices fail BAR allocations
> 2. one of the Davicom Ethernet devices fails BAR allocation
> 3. Uli ISA bridge fails BAR allocation.
> 
> Full current dmesg and lspci info is also available if there is any 
> interest. I did not include it all here, which machines are interesting?

PCI folks, please look into this.

A regression like this should not linger since 4.3, thank you.

WARNING: multiple messages have this Message-ID (diff)
From: David Miller <davem@davemloft.net>
To: mroos@linux.ee
Cc: yinghai@kernel.org, linux-pci@vger.kernel.org,
	sparclinux@vger.kernel.org
Subject: Re: sparc64 PCI BAR allocation is still problematic
Date: Sun, 08 Apr 2018 21:21:52 +0000	[thread overview]
Message-ID: <20180408.172152.113123578529151252.davem@davemloft.net> (raw)
In-Reply-To: <alpine.LRH.2.21.1804081219340.17185@math.ut.ee>

From: Meelis Roos <mroos@linux.ee>
Date: Sun, 8 Apr 2018 21:44:57 +0300 (EEST)

> This is a followup on the thread https://lkml.org/lkml/2015/10/7/135 and 
> corresponding https://bugzilla.kernel.org/show_bug.cgi?id\x117191 entry.
> 
> I saw some sparc64 PCI allocation changes in yesterdays git and compiled 
> 4.16.0-10242-gf605ba9 on most of my sparc64 machines to test if the PCI 
> BAR allocation problems introduced in 4.3 were fixed on some of them. 
> Alas, no change at all - of the test machines, none showed any changes 
> in the error messages in "dmesg | grep BAR".
> 
> There was one test machine, T1000 with no addon cards, that did not 
> encounter any problem, before or after the recent patch. All the other 
> test machines tried still have the BAR allocation problems.
> 
> The errors seem to cluster into 3 categories:
> 
> 1. many devices fail BAR allocations
> 2. one of the Davicom Ethernet devices fails BAR allocation
> 3. Uli ISA bridge fails BAR allocation.
> 
> Full current dmesg and lspci info is also available if there is any 
> interest. I did not include it all here, which machines are interesting?

PCI folks, please look into this.

A regression like this should not linger since 4.3, thank you.

  reply	other threads:[~2018-04-08 21:21 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-08 18:44 sparc64 PCI BAR allocation is still problematic Meelis Roos
2018-04-08 18:44 ` Meelis Roos
2018-04-08 21:21 ` David Miller [this message]
2018-04-08 21:21   ` David Miller
2018-04-09  3:00   ` Sinan Kaya
2018-04-09  3:00     ` Sinan Kaya
2018-04-09 10:47     ` Meelis Roos
2018-04-09 10:47       ` Meelis Roos
2018-04-09  3:23 ` Bjorn Helgaas
2018-04-09  3:23   ` Bjorn Helgaas
2018-04-09 14:30   ` Meelis Roos
2018-04-09 14:30     ` Meelis Roos
2018-04-10 17:34 ` Bjorn Helgaas
2018-04-10 17:34   ` Bjorn Helgaas
2018-04-10 18:45   ` Meelis Roos
2018-04-10 18:45     ` Meelis Roos
2018-04-10 18:56     ` Bjorn Helgaas
2018-04-10 18:56       ` Bjorn Helgaas
2018-04-11  7:59       ` Meelis Roos
2018-04-11  7:59         ` Meelis Roos
2018-04-11 13:33         ` Bjorn Helgaas
2018-04-11 13:33           ` Bjorn Helgaas
2018-04-11 14:40           ` Meelis Roos
2018-04-11 14:40             ` Meelis Roos
2018-04-11 20:01             ` Bjorn Helgaas
2018-04-11 20:01               ` Bjorn Helgaas
2018-04-11 20:25               ` Meelis Roos
2018-04-11 20:25                 ` Meelis Roos
2018-04-11 21:17                 ` Bjorn Helgaas
2018-04-11 21:17                   ` Bjorn Helgaas
2018-05-21 20:10         ` Bjorn Helgaas
2018-05-21 20:10           ` Bjorn Helgaas
2018-06-20 22:05 ` Bjorn Helgaas
2018-06-20 22:05   ` Bjorn Helgaas
2018-06-29 10:06   ` Meelis Roos
2018-06-29 10:06     ` Meelis Roos
2018-06-29 13:47     ` Bjorn Helgaas
2018-06-29 13:47       ` Bjorn Helgaas
2018-07-06 19:49       ` Meelis Roos
2018-07-06 19:49         ` Meelis Roos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180408.172152.113123578529151252.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=linux-pci@vger.kernel.org \
    --cc=mroos@linux.ee \
    --cc=sparclinux@vger.kernel.org \
    --cc=yinghai@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.