Boot breaks in -next from LEGACY to LINEAR conversion

-next fails to boot for me today on my s3c64xx based systems.  Walking
back to the last time I tried and bisecting likely branches I find that
commit 910139 (irqdomain: Replace LEGACY mapping with LINEAR) is the one
that introduces the build break.  Unfortunately the boot fails before I
get a console which makes diagnosis somewhat more tricky than would be
ideal.  Any ideas?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120717/b89437d7/attachment.sig>

On Tue, Jul 17, 2012 at 07:57:49PM +0100, Mark Brown wrote:

-next fails to boot for me today on my s3c64xx based systems.  Walking
back to the last time I tried and bisecting likely branches I find that
commit 910139 (irqdomain: Replace LEGACY mapping with LINEAR) is the one
that introduces the build break.  Unfortunately the boot fails before I
get a console which makes diagnosis somewhat more tricky than would be
ideal.  Any ideas?

Does http://www.spinics.net/lists/linux-sh/msg11995.html fix it for you?

I did Cc you on the legacy -> linear thread, but perhaps you missed it.

On Wed, Jul 18, 2012 at 09:52:30AM +0900, Paul Mundt wrote:

On Tue, Jul 17, 2012 at 07:57:49PM +0100, Mark Brown wrote:

quoted

-next fails to boot for me today on my s3c64xx based systems.  Walking
back to the last time I tried and bisecting likely branches I find that
commit 910139 (irqdomain: Replace LEGACY mapping with LINEAR) is the one
that introduces the build break.  Unfortunately the boot fails before I
get a console which makes diagnosis somewhat more tricky than would be
ideal.  Any ideas?

Does http://www.spinics.net/lists/linux-sh/msg11995.html fix it for you?

I did Cc you on the legacy -> linear thread, but perhaps you missed it.

I do remember seeing it, it's a big part of how I isolated that this
patch series was the issue.  To be honest I hadn't got terribly far with
the diagnosis of what the actual breakage is, it took a while to isolate
as it had been a little while since I'd rebased through onto -next and
there's no diagnostics at all from the system when it fails.

I tried applying the patch but the underlying code has changed a lot so
patch gets upset, I'll try to find time to resolve them but can't
guarantee when as things are especially hectic right now.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120718/28ea8fb1/attachment.sig>

On Tue, Jul 17, 2012 at 07:57:49PM +0100, Mark Brown wrote:

-next fails to boot for me today on my s3c64xx based systems.  Walking
back to the last time I tried and bisecting likely branches I find that
commit 910139 (irqdomain: Replace LEGACY mapping with LINEAR) is the one
that introduces the build break.  Unfortunately the boot fails before I
get a console which makes diagnosis somewhat more tricky than would be
ideal.  Any ideas?

Further data: the irq_domain_associate_many() calls that we're now doing
are also causing WARN_ON()s to go off during boot after commit 98aa46
(irqdomain: Support for static IRQ mapping and association) causing
breakage for my interrupt using MFDs.

I don't really have time to investigate now but backing out that commit
seems to make things much happier, I suspect there's some collision with
IRQs allocated statically by the platform but I don't immediately see
what's new here.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120718/a55fdf50/attachment.sig>

On Wed, Jul 18, 2012 at 10:10 AM, Mark Brown
[off-list ref] wrote:

On Tue, Jul 17, 2012 at 07:57:49PM +0100, Mark Brown wrote:

quoted

-next fails to boot for me today on my s3c64xx based systems.  Walking
back to the last time I tried and bisecting likely branches I find that
commit 910139 (irqdomain: Replace LEGACY mapping with LINEAR) is the one
that introduces the build break.  Unfortunately the boot fails before I
get a console which makes diagnosis somewhat more tricky than would be
ideal.  Any ideas?

Further data: the irq_domain_associate_many() calls that we're now doing
are also causing WARN_ON()s to go off during boot after commit 98aa46
(irqdomain: Support for static IRQ mapping and association) causing
breakage for my interrupt using MFDs.

I don't really have time to investigate now but backing out that commit
seems to make things much happier, I suspect there's some collision with
IRQs allocated statically by the platform but I don't immediately see
what's new here.

I had seen that on my end too, but I thought I had fixed it...  I
guess not (or this is a similar type of failure).  I'll investigate.

g.



-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

On Wed, Jul 18, 2012 at 10:10 AM, Mark Brown
[off-list ref] wrote:

On Tue, Jul 17, 2012 at 07:57:49PM +0100, Mark Brown wrote:

quoted

-next fails to boot for me today on my s3c64xx based systems.  Walking
back to the last time I tried and bisecting likely branches I find that
commit 910139 (irqdomain: Replace LEGACY mapping with LINEAR) is the one
that introduces the build break.  Unfortunately the boot fails before I
get a console which makes diagnosis somewhat more tricky than would be
ideal.  Any ideas?

Further data: the irq_domain_associate_many() calls that we're now doing
are also causing WARN_ON()s to go off during boot after commit 98aa46
(irqdomain: Support for static IRQ mapping and association) causing
breakage for my interrupt using MFDs.

Okay, I've got a theory about what the issue is now. The .map()
callback is failing (returning non-zero) for one of the hwirqs. The
new code is stricter about associations, and actually unwinds the
associations if one of them fails. The old legacy code simply called
all the .map() hooks blindly without any error checking. Can you send
me the kernel log after backing out those changes.

The other possibility is that irqs aren't being reserved correctly.
Seeing the backtrace will tell me which issue it is.

In the mean time I've backed out the top three commits from irqdomain/next.

g.

On Thu, Jul 19, 2012 at 10:30:11PM -0600, Grant Likely wrote:

Okay, I've got a theory about what the issue is now. The .map()
callback is failing (returning non-zero) for one of the hwirqs. The
new code is stricter about associations, and actually unwinds the
associations if one of them fails. The old legacy code simply called
all the .map() hooks blindly without any error checking. Can you send
me the kernel log after backing out those changes.

Looks like the error checking is the issue.  Always knew that was a bad
idea :)  I've just sent a patch to improve the diagnostics here which
might help a bit, though I realise now with some of my debug I need to
send a v2 :/ .

On my system there's only one mapping failed, but it's for one of the
VIC mappings which is rather unfortunate.  The error is there because
the VIC is returning -ENOTSUPP to skip invalid IRQs which doesn't
immediately seem like an awful thing to do for generic code like this.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120720/e8c18b18/attachment-0001.sig>