linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Carlo Pisani <carlojpisani@gmail.com>
Cc: linux-pci@vger.kernel.org
Subject: Re: Oxford Semiconductor Ltd OX16PCI954 - weird dmesg
Date: Mon, 4 Nov 2019 10:30:04 -0600	[thread overview]
Message-ID: <20191104163004.GA117590@google.com> (raw)
In-Reply-To: <CA+QBN9D4bckEZmNhLJPBmr92St1W2GGyazLGR9kANFk2cfV8Pg@mail.gmail.com>

[+cc linux-pci]

On Mon, Nov 04, 2019 at 05:04:54PM +0100, Carlo Pisani wrote:
> > > > It sounds like the firmware fails to even load v4.11?  If that's the
> > > > case, it's probably not a problem with the kernel itself, since it
> > > > hasn't even started executing.  Possibly a kernel size problem?  Maybe
> > > > the v4.11 kernel is larger than v4.4, v4.9, etc?  Does v4.11 boot if
> > > > you strip out non-essential drivers?
> 
> kernel v4.11 is 7.5Mbyte and doesn't boot from the TFTboot option
> offered by the firmware, it claims "out of range", which makes no
> sense
> 
> out of range in what? too big? bad initialized? who knows ....
> 
> > Is the v4.11 kernel image bigger than the v4.4 kernel that boots?
> 
> everything bigger than 7Mbyte seems to be bad for the firmware.

You should be able to test this by adding built-in drivers to your
v4.4 kernel so it becomes larger than 7 MB.  If the kernel size is the
problem, a large v4.4 kernel should fail the same way the v4.11 kernel
does.

> anyway, I post here to hear if someone is on the RB532A (Mikrotik),
> should I also open a ticket to OpenWrt?

I guess it wouldn't hurt to open an OpenWrt ticket because maybe more
people there have experience with the RB532A.  But if the problem is
simply that the RB532A has broken Rhine devices that don't correctly
support PCI MMIO access, the only fix is to work around it by using
I/O port access instead.

Your matrix at [1] seems to show that the only reliable "stable for
48h" combination is the one with PCI MMIO access disabled.

If there's some way to identify that broken device or the platform,
e.g., RB532A, somebody could write a quirk to automatically disable
PCI MMIO in the driver.  But the comment in the driver already
mentions that, so I guess it's not trivial to identify those cases.

[1] http://www.downthebunker.com/reloaded/space/viewtopic.php?f=79&p=2755

       reply	other threads:[~2019-11-04 16:30 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CA+QBN9D4bckEZmNhLJPBmr92St1W2GGyazLGR9kANFk2cfV8Pg@mail.gmail.com>
2019-11-04 16:30 ` Bjorn Helgaas [this message]
     [not found] <CA+QBN9B4qfxpEa69TB=+MngG9bN0puwByAeGCMxk_Y7fgaKhpQ@mail.gmail.com>
2019-11-04 16:07 ` Oxford Semiconductor Ltd OX16PCI954 - weird dmesg Bjorn Helgaas
     [not found] <CA+QBN9AzXHifP4=F1O1jjbGP0yNxBZeTPgPJvpcKFb9Z4f30KA@mail.gmail.com>
2019-11-04 15:58 ` Bjorn Helgaas
     [not found] <CA+QBN9C_o8HanAzXpDUN410g2o5+xfx64pbX3_VHVDKcj5N3kA@mail.gmail.com>
2019-10-28 17:13 ` Bjorn Helgaas
2019-10-28 16:37   ` Carlo Pisani
2019-10-28 18:48     ` Bjorn Helgaas
2019-10-28 18:06       ` Carlo Pisani
2019-10-28 19:43         ` Bjorn Helgaas
2019-10-28 18:49           ` Carlo Pisani
2019-11-04 14:59             ` Bjorn Helgaas
2019-10-28 16:46   ` Carlo Pisani
2019-10-24 17:11 [PATCH v6 00/30] PCI: Allow BAR movement during hotplug Sergey Miroshnichenko
2019-10-24 17:11 ` [PATCH v6 01/30] PCI: Fix race condition in pci_enable/disable_device() Sergey Miroshnichenko
2019-10-25 14:33   ` Oxford Semiconductor Ltd OX16PCI954 - weird dmesg Carlo Pisani
2019-10-25 16:37     ` Bjorn Helgaas

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=20191104163004.GA117590@google.com \
    --to=helgaas@kernel.org \
    --cc=carlojpisani@gmail.com \
    --cc=linux-pci@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).