From: benoar@dolka.fr (Benjamin Cama)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] Re: Linkstation Mini and __machine_arch_type problem, not booting since 3.8
Date: Thu, 18 Jun 2015 04:12:35 +0200 [thread overview]
Message-ID: <1434593555.13334.14.camel@dolka.fr> (raw)
In-Reply-To: <1434446447.4785.7.camel@dolka.fr>
Hi again (feeling lonely),
I have got some news, I think I found the culprit.
Le mardi 16 juin 2015 ? 11:20 +0200, Benjamin Cama a ?crit :
> Le lundi 15 juin 2015 ? 15:51 +0200, Benjamin Cama a ?crit :
> > it didn't boot anymore at
> > all: no message at all displayed, not even with earlyprintk
>
> Note that I tried the earlyprintk=serial,ttyS0,115200 with a working
> kernel as I do for the non-working ones, and it hangs at boot too, so
> this is no indication, sorry.
(Note for later: read the manual first, earlyprintk on this arch is for
a special tool to handle on the serial port on the host side. So it
looks like it hangs when running with it.)
> > I bisected
> > the faulty commit down to b8b499c86be58cb309964fcab5b62ac4a240a878
> > ?ARM:
> > 7602/1: Pass real "__machine_arch_type" variable to
> > setup_machine_tags()
> > procedure? which looks like a quite broad change, and makes me 1)
> > not
> > really understand what it does 2) astonished not to see someone
> > else
> > affected (judging by the time since it doesn't work).
>
> I dug some more and found what changed: it simply passes the bootloader
> -provided machine ID instead of the kernel-configured one! This is
> quite a change indeed, which is not mentionned in the commit text. This
> may seem good for vendor-provided support which assigns IDs early with
> upstream, but for user one (like for this machine), the machine ID will
> in general be some ID that has nothing to do with the one passed by the
> bootloader. So this ought to be mentioned somewhere!
No comment on this? I continued with my hack which hardcodes the
machine ID, but has anyone some advice on how it should be done? Should
the behavior be reverted, or is there a clean way to force a machine ID
at build time?
> How I found this? Well, my bootloader passes a bad machine ID (526
> instead of 1858), and thus the code doesn't recognize it. What I cannot
> understand is why the decompressor doesn't even run with a wrong
> machine ID (MMU initialization that depend on it maybe??). This is very
> strange.
(that was because I enabled earlyprintk, which for some reason removes
messages from the decompressor? or maybe I mixed things up while
configuring the kernel)
> And also, I don't get why a more recent kernel with a hardcoded machine
> ID (personal modification) doesn't work either. Maybe I should bisect
> that too.
And I did it. And I stumbled upon commit
a71b092a9c68685a270ebdde7b5986ba8787e575 ?ARM: Convert handle_IRQ to
use __handle_domain_irq? (author Cc'ed). The new function
__handle_domain_irq (in kernel/irq/irqdesc.c, which comes just two
commits before, with 76ba59f8366f2d9282cb5bda9de75b4b68cbe55f) is
subtly different from the one it replaces, handle_IRQ, as it checks if
the irq is not 0 as well as checking for an upper bound. Removing the
check for 0 makes my machine work again! But honestly, I do not know if
a zero irq is legit, so I hope some more knowledgeable people will tell
me if this is OK.
-- >8 --
Subject: [PATCH] Make __handle_domain_irq accept IRQ 0
The same as handle_IRQ did before.
Signed-off-by: Benjamin Cama <benoar@dolka.fr>
---
kernel/irq/irqdesc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index a1782f8..bfbeeb6 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -365,7 +365,7 @@ int __handle_domain_irq(struct irq_domain *domain, unsigned int hwirq,
* Some hardware gives randomly wrong interrupts. Rather
* than crashing, do something sensible.
*/
- if (unlikely(!irq || irq >= nr_irqs)) {
+ if (unlikely(irq >= nr_irqs)) {
ack_bad_irq(irq);
ret = -EINVAL;
} else {
--
2.1.4
next prev parent reply other threads:[~2015-06-18 2:12 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-15 13:51 Linkstation Mini and __machine_arch_type problem, not booting since 3.8 Benjamin Cama
2015-06-16 9:20 ` Benjamin Cama
2015-06-18 2:12 ` Benjamin Cama [this message]
2015-06-18 7:52 ` [PATCH] " Marc Zyngier
2015-06-18 8:14 ` Arnd Bergmann
2015-06-18 13:23 ` Andrew Lunn
2015-06-19 1:38 ` Benjamin Cama
2015-06-19 9:13 ` Marc Zyngier
2015-06-19 12:16 ` Benjamin Cama
2015-06-19 13:01 ` Jason Cooper
2015-06-19 13:13 ` Russell King - ARM Linux
2015-06-19 13:46 ` Benjamin Cama
2015-06-19 15:25 ` Jason Cooper
2015-06-19 15:48 ` Russell King - ARM Linux
2015-06-19 17:13 ` Jason Cooper
2015-06-21 17:37 ` Benjamin Cama
2015-06-22 12:08 ` Jason Cooper
2015-06-22 17:49 ` Benjamin Cama
2015-06-22 17:58 ` Russell King - ARM Linux
2015-06-22 18:04 ` Jason Cooper
[not found] ` <1436710916.5657.169.camel@dolka.fr>
2015-07-14 14:25 ` [PATCH] ARM: orion5x: fix legacy orion5x IRQ numbers Benjamin Cama
2015-07-14 20:50 ` Arnd Bergmann
2015-08-14 15:46 ` Gregory CLEMENT
2015-06-19 15:44 ` [PATCH] Re: Linkstation Mini and __machine_arch_type problem, not booting since 3.8 Russell King - ARM Linux
2015-06-20 1:01 ` Benjamin Cama
2015-06-18 8:12 ` Gregory CLEMENT
2015-06-19 1:50 ` Benjamin Cama
2015-06-19 9:33 ` Gregory CLEMENT
2015-06-19 11:41 ` Jason Cooper
2015-06-20 0:28 ` Benjamin Cama
2015-06-20 14:36 ` Andrew Lunn
2015-06-21 17:36 ` Benjamin Cama
2015-06-21 20:07 ` Andrew Lunn
[not found] ` <1434995000.5657.42.camel@dolka.fr>
2015-06-22 18:23 ` SERIAL_OF_PLATFORM default setting for DT headless systems Jason Cooper
2015-06-22 19:42 ` Benjamin Cama
2015-06-22 12:00 ` Linkstation Mini and __machine_arch_type problem, not booting since 3.8 Jason Cooper
2015-06-22 17:44 ` Benjamin Cama
2015-06-19 22:38 ` Andrew Lunn
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=1434593555.13334.14.camel@dolka.fr \
--to=benoar@dolka.fr \
--cc=linux-arm-kernel@lists.infradead.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.