All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baruch Siach <baruch@tkos.co.il>
To: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: "Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
	"Jason Cooper" <jason@lakedaemon.net>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Jan Kundrát" <jan.kundrat@cesnet.cz>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured"
Date: Thu, 13 Sep 2018 06:19:54 +0300	[thread overview]
Message-ID: <87y3c63wyt.fsf@tkos.co.il> (raw)
In-Reply-To: <20180912231050.GX30658@n2100.armlinux.org.uk>

Hi Russell,

Russell King - ARM Linux writes:
> On Wed, Sep 12, 2018 at 09:49:41PM +0300, Baruch Siach wrote:
>> I reproduced the same Oops on Clearfog Base without any taint:
>> 
>> [    1.476401] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
> ...
>> [    1.855954] Code: e2844004 e5972000 e3520000 0affffee (e7f001f2)
>
> That is a BUG().  Please turn on verbose bug reporting to get more
> information about the cause.
>
> There are two possibilities:
>
>         BUG_ON(addr >= end);
>
> and
>
>                 BUG_ON(!pte_none(*pte));
>
> It's probably the latter - the region is probably already mapped, that
> being the PCI IO region.

That is the one. Enabling CONFIG_DEBUG_BUGVERBOSE shows:

[    1.481927] kernel BUG at lib/ioremap.c:72!
[    1.486118] Internal error: Oops - BUG: 0 [#1] SMP ARM
[    1.491269] CPU: 0 PID: 1246 Comm: kworker/0:2 Not tainted 4.19.0-rc3 #146
...

baruch

> The original driver was setup to call pci_ioremap_io() as the very
> last thing - and as the driver is non-removable, we were guaranteed
> to never tear down this mapping (which is sensible, it's published
> to userspace.)
>
> However, the current code calls pci_ioremap_io() much earlier, in
> a path where probe failures can occur.  This breaks pci_ioremap_io()'s
> requirements - it must not be called more than once.  So:
>
> ee1604381a37 ("PCI: mvebu: Only remap I/O space if configured")
>
> is basically incorrect - pci_ioremap_io() needs to move back to a
> place where it is only called in a path which will never fail.
> However, looking at the generic host bits, I'm not sure such a place
> exists in the new effort to make stuff more generic.

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: baruch@tkos.co.il (Baruch Siach)
To: linux-arm-kernel@lists.infradead.org
Subject: [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured"
Date: Thu, 13 Sep 2018 06:19:54 +0300	[thread overview]
Message-ID: <87y3c63wyt.fsf@tkos.co.il> (raw)
In-Reply-To: <20180912231050.GX30658@n2100.armlinux.org.uk>

Hi Russell,

Russell King - ARM Linux writes:
> On Wed, Sep 12, 2018 at 09:49:41PM +0300, Baruch Siach wrote:
>> I reproduced the same Oops on Clearfog Base without any taint:
>> 
>> [    1.476401] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
> ...
>> [    1.855954] Code: e2844004 e5972000 e3520000 0affffee (e7f001f2)
>
> That is a BUG().  Please turn on verbose bug reporting to get more
> information about the cause.
>
> There are two possibilities:
>
>         BUG_ON(addr >= end);
>
> and
>
>                 BUG_ON(!pte_none(*pte));
>
> It's probably the latter - the region is probably already mapped, that
> being the PCI IO region.

That is the one. Enabling CONFIG_DEBUG_BUGVERBOSE shows:

[    1.481927] kernel BUG at lib/ioremap.c:72!
[    1.486118] Internal error: Oops - BUG: 0 [#1] SMP ARM
[    1.491269] CPU: 0 PID: 1246 Comm: kworker/0:2 Not tainted 4.19.0-rc3 #146
...

baruch

> The original driver was setup to call pci_ioremap_io() as the very
> last thing - and as the driver is non-removable, we were guaranteed
> to never tear down this mapping (which is sensible, it's published
> to userspace.)
>
> However, the current code calls pci_ioremap_io() much earlier, in
> a path where probe failures can occur.  This breaks pci_ioremap_io()'s
> requirements - it must not be called more than once.  So:
>
> ee1604381a37 ("PCI: mvebu: Only remap I/O space if configured")
>
> is basically incorrect - pci_ioremap_io() needs to move back to a
> place where it is only called in a path which will never fail.
> However, looking at the generic host bits, I'm not sure such a place
> exists in the new effort to make stuff more generic.

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

WARNING: multiple messages have this Message-ID (diff)
From: Baruch Siach <baruch@tkos.co.il>
To: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: "Jan Kundrát" <jan.kundrat@cesnet.cz>,
	"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
	"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
	"Jason Cooper" <jason@lakedaemon.net>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured"
Date: Thu, 13 Sep 2018 06:19:54 +0300	[thread overview]
Message-ID: <87y3c63wyt.fsf@tkos.co.il> (raw)
In-Reply-To: <20180912231050.GX30658@n2100.armlinux.org.uk>

Hi Russell,

Russell King - ARM Linux writes:
> On Wed, Sep 12, 2018 at 09:49:41PM +0300, Baruch Siach wrote:
>> I reproduced the same Oops on Clearfog Base without any taint:
>> 
>> [    1.476401] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
> ...
>> [    1.855954] Code: e2844004 e5972000 e3520000 0affffee (e7f001f2)
>
> That is a BUG().  Please turn on verbose bug reporting to get more
> information about the cause.
>
> There are two possibilities:
>
>         BUG_ON(addr >= end);
>
> and
>
>                 BUG_ON(!pte_none(*pte));
>
> It's probably the latter - the region is probably already mapped, that
> being the PCI IO region.

That is the one. Enabling CONFIG_DEBUG_BUGVERBOSE shows:

[    1.481927] kernel BUG at lib/ioremap.c:72!
[    1.486118] Internal error: Oops - BUG: 0 [#1] SMP ARM
[    1.491269] CPU: 0 PID: 1246 Comm: kworker/0:2 Not tainted 4.19.0-rc3 #146
...

baruch

> The original driver was setup to call pci_ioremap_io() as the very
> last thing - and as the driver is non-removable, we were guaranteed
> to never tear down this mapping (which is sensible, it's published
> to userspace.)
>
> However, the current code calls pci_ioremap_io() much earlier, in
> a path where probe failures can occur.  This breaks pci_ioremap_io()'s
> requirements - it must not be called more than once.  So:
>
> ee1604381a37 ("PCI: mvebu: Only remap I/O space if configured")
>
> is basically incorrect - pci_ioremap_io() needs to move back to a
> place where it is only called in a path which will never fail.
> However, looking at the generic host bits, I'm not sure such a place
> exists in the new effort to make stuff more generic.

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

  reply	other threads:[~2018-09-13  3:19 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-12 16:11 [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured" Jan Kundrát
2018-09-12 16:11 ` Jan Kundrát
2018-09-12 16:11 ` Jan Kundrát
2018-09-12 18:49 ` Baruch Siach
2018-09-12 18:49   ` Baruch Siach
2018-09-12 18:49   ` Baruch Siach
2018-09-12 18:50   ` Thomas Petazzoni
2018-09-12 18:50     ` Thomas Petazzoni
2018-09-12 18:50     ` Thomas Petazzoni
2018-09-12 19:00     ` Jan Kundrát
2018-09-12 19:00       ` Jan Kundrát
2018-09-12 19:00       ` Jan Kundrát
2018-09-12 23:10   ` Russell King - ARM Linux
2018-09-12 23:10     ` Russell King - ARM Linux
2018-09-12 23:10     ` Russell King - ARM Linux
2018-09-13  3:19     ` Baruch Siach [this message]
2018-09-13  3:19       ` Baruch Siach
2018-09-13  3:19       ` Baruch Siach
2018-09-13  7:45     ` Thomas Petazzoni
2018-09-13  7:45       ` Thomas Petazzoni
2018-09-13  7:45       ` Thomas Petazzoni
2018-09-13  8:20       ` Jan Kundrát
2018-09-13  8:20         ` Jan Kundrát
2018-09-13  8:20         ` Jan Kundrát
2018-09-13  8:42         ` Thomas Petazzoni
2018-09-13  8:42           ` Thomas Petazzoni
2018-09-13  8:42           ` Thomas Petazzoni
2018-09-24 10:02           ` Jan Kundrát
2018-09-24 10:02             ` Jan Kundrát
2018-09-24 10:10             ` Thomas Petazzoni
2018-09-24 10:10               ` Thomas Petazzoni
2018-09-24 10:12           ` Russell King - ARM Linux
2018-09-24 10:12             ` Russell King - ARM Linux
2018-09-24 10:26             ` Thomas Petazzoni
2018-09-24 10:26               ` Thomas Petazzoni
2018-09-24 11:13               ` Russell King - ARM Linux
2018-09-24 11:13                 ` Russell King - ARM Linux
2018-09-24 12:12                 ` Thomas Petazzoni
2018-09-24 12:12                   ` Thomas Petazzoni
2018-09-24 12:46                   ` Lorenzo Pieralisi
2018-09-24 12:46                     ` Lorenzo Pieralisi
2018-09-24 13:10                     ` Thomas Petazzoni
2018-09-24 13:10                       ` Thomas Petazzoni
2018-09-24 14:15                       ` Lorenzo Pieralisi
2018-09-24 14:15                         ` Lorenzo Pieralisi
2018-09-24 14:52                         ` Thomas Petazzoni
2018-09-24 14:52                           ` Thomas Petazzoni
2018-09-24 16:42                           ` Lorenzo Pieralisi
2018-09-24 16:42                             ` Lorenzo Pieralisi
2018-10-01 10:56                           ` Jan Kundrát
2018-10-01 10:56                             ` Jan Kundrát
2018-10-01 12:51                             ` Thomas Petazzoni
2018-10-01 12:51                               ` Thomas Petazzoni
2018-10-01 21:01                               ` Bjorn Helgaas
2018-10-01 21:01                                 ` Bjorn Helgaas
2018-09-25  8:18                   ` Andrew Murray
2018-09-25  8:18                     ` Andrew Murray

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=87y3c63wyt.fsf@tkos.co.il \
    --to=baruch@tkos.co.il \
    --cc=bhelgaas@google.com \
    --cc=jan.kundrat@cesnet.cz \
    --cc=jason@lakedaemon.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=thomas.petazzoni@bootlin.com \
    /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.