Re: alpha boot hang - 4.14-rc* regression

[Lorenzo Pieralisi]

On Wed, Oct 25, 2017 at 09:01:07PM +0300, Meelis Roos wrote:
> > It is probably because I patched the wrong map_irq() function,
> > I am trying to detect which one you are _actually_ using, if
> > the patch below fails I will patch them all (which is what I
> > have to do anyway).
> > 
> > Please give this a go - this _has_ to make a difference, it is not
> > correct to leave map_irq() pointers as __init memory, IRQ routing
> > for modules can't work.
> 
> This works for mainline git too.
> 
> If you have another round that fixes all subarches, I will try it on a 
> PC164 too.

Sure, I will send one patch shortly updating all map/swizzle functions
to remove the __init markers.

Thanks,
Lorenzo

Re: alpha boot hang - 4.14-rc* regression

[Lorenzo Pieralisi]

On Wed, Oct 25, 2017 at 09:01:07PM +0300, Meelis Roos wrote:
> > It is probably because I patched the wrong map_irq() function,
> > I am trying to detect which one you are _actually_ using, if
> > the patch below fails I will patch them all (which is what I
> > have to do anyway).
> > 
> > Please give this a go - this _has_ to make a difference, it is not
> > correct to leave map_irq() pointers as __init memory, IRQ routing
> > for modules can't work.
> 
> This works for mainline git too.
> 
> If you have another round that fixes all subarches, I will try it on a 
> PC164 too.

Sure, I will send one patch shortly updating all map/swizzle functions
to remove the __init markers.

Thanks,
Lorenzo

Re: alpha boot hang - 4.14-rc* regression

[Meelis Roos]

> It is probably because I patched the wrong map_irq() function,
> I am trying to detect which one you are _actually_ using, if
> the patch below fails I will patch them all (which is what I
> have to do anyway).
> 
> Please give this a go - this _has_ to make a difference, it is not
> correct to leave map_irq() pointers as __init memory, IRQ routing
> for modules can't work.

This works for mainline git too.

If you have another round that fixes all subarches, I will try it on a 
PC164 too.

-- 
Meelis Roos (mr...@linux.ee)

Re: alpha boot hang - 4.14-rc* regression

[Meelis Roos]

> It is probably because I patched the wrong map_irq() function,
> I am trying to detect which one you are _actually_ using, if
> the patch below fails I will patch them all (which is what I
> have to do anyway).
> 
> Please give this a go - this _has_ to make a difference, it is not
> correct to leave map_irq() pointers as __init memory, IRQ routing
> for modules can't work.

This works for mainline git too.

If you have another round that fixes all subarches, I will try it on a 
PC164 too.

-- 
Meelis Roos (mr...@linux.ee)

Re: alpha boot hang - 4.14-rc* regression

[Meelis Roos]

> > > > > > removing libata modules and rebooting fixes it - so it seems to be 
> > > > > > loading of libata.
> > > > > 
> > > > > Can you please cherry-pick:
> > > > > 
> > > > > commit b1f9e5e355e9 ("ide: fix IRQ assignment for PCI bus order 
> > > > > probing")
> > > > > 
> > > > > from mainline and let us know if that solves the issue ?
> > > > 
> > > > No, still breaks the same way (b1f9e5e355e9 patched on top of 
> > > > 0e4c2eeb758a).
> > > > 
> > > > 4.14.0-rc5-00095-g1c9fec470b81 was also still broken the same way 
> > > > (tried 
> > > > on Sunday).
> > > 
> > > I am not sure I patched the right sys file but if I did, does the patch
> > > below help ?
> > > 
> > > I think that at sata driver binding time the kernel finds a freed
> > > pointer in the host bridge map_irq() hook and that's where things
> > > go wrong.
> > > 
> > > Please let me know if that's the right sys file, it is a mechanical
> > > change and making it for other sys file should be reasonably simple.
> > > 
> > > Lorenzo
> > > 
> > > -- >8 --
> > > diff --git a/arch/alpha/kernel/sys_dp264.c b/arch/alpha/kernel/sys_dp264.c
> > 
> > "Booting GENERIC on Tsunami variation Webbrick using machine vector 
> > Webbrick from SRM"
> > 
> > Seems to be the correct file - tsunami is referenced from this file and 
> > the IRQ-s are DP264.
> > 
> > But the patch does not make a difference :(
> 
> It is probably because I patched the wrong map_irq() function,
> I am trying to detect which one you are _actually_ using, if
> the patch below fails I will patch them all (which is what I
> have to do anyway).
> 
> Please give this a go - this _has_ to make a difference, it is not
> correct to leave map_irq() pointers as __init memory, IRQ routing
> for modules can't work.

Yes, webrick entry seems to be the correct one fro DS10L. It works fine 
on top of the cherry-picked ATA IRQ patch.

Will try it on top of current mainline git.

-- 
Meelis Roos (mr...@linux.ee)

Re: alpha boot hang - 4.14-rc* regression

[Meelis Roos]

> > > > > > removing libata modules and rebooting fixes it - so it seems to be 
> > > > > > loading of libata.
> > > > > 
> > > > > Can you please cherry-pick:
> > > > > 
> > > > > commit b1f9e5e355e9 ("ide: fix IRQ assignment for PCI bus order 
> > > > > probing")
> > > > > 
> > > > > from mainline and let us know if that solves the issue ?
> > > > 
> > > > No, still breaks the same way (b1f9e5e355e9 patched on top of 
> > > > 0e4c2eeb758a).
> > > > 
> > > > 4.14.0-rc5-00095-g1c9fec470b81 was also still broken the same way 
> > > > (tried 
> > > > on Sunday).
> > > 
> > > I am not sure I patched the right sys file but if I did, does the patch
> > > below help ?
> > > 
> > > I think that at sata driver binding time the kernel finds a freed
> > > pointer in the host bridge map_irq() hook and that's where things
> > > go wrong.
> > > 
> > > Please let me know if that's the right sys file, it is a mechanical
> > > change and making it for other sys file should be reasonably simple.
> > > 
> > > Lorenzo
> > > 
> > > -- >8 --
> > > diff --git a/arch/alpha/kernel/sys_dp264.c b/arch/alpha/kernel/sys_dp264.c
> > 
> > "Booting GENERIC on Tsunami variation Webbrick using machine vector 
> > Webbrick from SRM"
> > 
> > Seems to be the correct file - tsunami is referenced from this file and 
> > the IRQ-s are DP264.
> > 
> > But the patch does not make a difference :(
> 
> It is probably because I patched the wrong map_irq() function,
> I am trying to detect which one you are _actually_ using, if
> the patch below fails I will patch them all (which is what I
> have to do anyway).
> 
> Please give this a go - this _has_ to make a difference, it is not
> correct to leave map_irq() pointers as __init memory, IRQ routing
> for modules can't work.

Yes, webrick entry seems to be the correct one fro DS10L. It works fine 
on top of the cherry-picked ATA IRQ patch.

Will try it on top of current mainline git.

-- 
Meelis Roos (mr...@linux.ee)

Re: alpha boot hang - 4.14-rc* regression

[Lorenzo Pieralisi]

On Wed, Oct 25, 2017 at 05:49:54PM +0300, Meelis Roos wrote:
> > > > > removing libata modules and rebooting fixes it - so it seems to be 
> > > > > loading of libata.
> > > > 
> > > > Can you please cherry-pick:
> > > > 
> > > > commit b1f9e5e355e9 ("ide: fix IRQ assignment for PCI bus order 
> > > > probing")
> > > > 
> > > > from mainline and let us know if that solves the issue ?
> > > 
> > > No, still breaks the same way (b1f9e5e355e9 patched on top of 
> > > 0e4c2eeb758a).
> > > 
> > > 4.14.0-rc5-00095-g1c9fec470b81 was also still broken the same way (tried 
> > > on Sunday).
> > 
> > I am not sure I patched the right sys file but if I did, does the patch
> > below help ?
> > 
> > I think that at sata driver binding time the kernel finds a freed
> > pointer in the host bridge map_irq() hook and that's where things
> > go wrong.
> > 
> > Please let me know if that's the right sys file, it is a mechanical
> > change and making it for other sys file should be reasonably simple.
> > 
> > Lorenzo
> > 
> > -- >8 --
> > diff --git a/arch/alpha/kernel/sys_dp264.c b/arch/alpha/kernel/sys_dp264.c
> 
> "Booting GENERIC on Tsunami variation Webbrick using machine vector 
> Webbrick from SRM"
> 
> Seems to be the correct file - tsunami is referenced from this file and 
> the IRQ-s are DP264.
> 
> But the patch does not make a difference :(

It is probably because I patched the wrong map_irq() function,
I am trying to detect which one you are _actually_ using, if
the patch below fails I will patch them all (which is what I
have to do anyway).

Please give this a go - this _has_ to make a difference, it is not
correct to leave map_irq() pointers as __init memory, IRQ routing
for modules can't work.

-- >8 --
diff --git a/arch/alpha/kernel/sys_dp264.c b/arch/alpha/kernel/sys_dp264.c
index 6c35159..62fd7f1 100644
--- a/arch/alpha/kernel/sys_dp264.c
+++ b/arch/alpha/kernel/sys_dp264.c
@@ -356,7 +356,7 @@ clipper_init_irq(void)
  *  10  64 bit PCI option slot 3 (not bus 0)
  */
 
-static int __init
+static int
 isa_irq_fixup(const struct pci_dev *dev, int irq)
 {
u8 irq8;
@@ -372,10 +372,10 @@ isa_irq_fixup(const struct pci_dev *dev, int irq)
return irq8 & 0xf;
 }
 
-static int __init
+static int
 dp264_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
 {
-   static char irq_tab[6][5] __initdata = {
+   static char irq_tab[6][5] = {
/*INTINTA   INTB   INTC   INTD */
{-1,-1,-1,-1,-1}, /* IdSel 5 ISA Bridge */
{ 16+ 3, 16+ 3, 16+ 2, 16+ 2, 16+ 2}, /* IdSel 6 SCSI builtin*/
@@ -456,10 +456,10 @@ monet_swizzle(struct pci_dev *dev, u8 *pinp)
return slot;
 }
 
-static int __init
+static int
 webbrick_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
 {
-   static char irq_tab[13][5] __initdata = {
+   static char irq_tab[13][5] = {
/*INTINTA   INTB   INTC   INTD */
{-1,-1,-1,-1,-1}, /* IdSel 7 ISA Bridge */
{-1,-1,-1,-1,-1}, /* IdSel 8 unused */

Re: alpha boot hang - 4.14-rc* regression

[Lorenzo Pieralisi]

On Wed, Oct 25, 2017 at 05:49:54PM +0300, Meelis Roos wrote:
> > > > > removing libata modules and rebooting fixes it - so it seems to be 
> > > > > loading of libata.
> > > > 
> > > > Can you please cherry-pick:
> > > > 
> > > > commit b1f9e5e355e9 ("ide: fix IRQ assignment for PCI bus order 
> > > > probing")
> > > > 
> > > > from mainline and let us know if that solves the issue ?
> > > 
> > > No, still breaks the same way (b1f9e5e355e9 patched on top of 
> > > 0e4c2eeb758a).
> > > 
> > > 4.14.0-rc5-00095-g1c9fec470b81 was also still broken the same way (tried 
> > > on Sunday).
> > 
> > I am not sure I patched the right sys file but if I did, does the patch
> > below help ?
> > 
> > I think that at sata driver binding time the kernel finds a freed
> > pointer in the host bridge map_irq() hook and that's where things
> > go wrong.
> > 
> > Please let me know if that's the right sys file, it is a mechanical
> > change and making it for other sys file should be reasonably simple.
> > 
> > Lorenzo
> > 
> > -- >8 --
> > diff --git a/arch/alpha/kernel/sys_dp264.c b/arch/alpha/kernel/sys_dp264.c
> 
> "Booting GENERIC on Tsunami variation Webbrick using machine vector 
> Webbrick from SRM"
> 
> Seems to be the correct file - tsunami is referenced from this file and 
> the IRQ-s are DP264.
> 
> But the patch does not make a difference :(

It is probably because I patched the wrong map_irq() function,
I am trying to detect which one you are _actually_ using, if
the patch below fails I will patch them all (which is what I
have to do anyway).

Please give this a go - this _has_ to make a difference, it is not
correct to leave map_irq() pointers as __init memory, IRQ routing
for modules can't work.

-- >8 --
diff --git a/arch/alpha/kernel/sys_dp264.c b/arch/alpha/kernel/sys_dp264.c
index 6c35159..62fd7f1 100644
--- a/arch/alpha/kernel/sys_dp264.c
+++ b/arch/alpha/kernel/sys_dp264.c
@@ -356,7 +356,7 @@ clipper_init_irq(void)
  *  10  64 bit PCI option slot 3 (not bus 0)
  */
 
-static int __init
+static int
 isa_irq_fixup(const struct pci_dev *dev, int irq)
 {
u8 irq8;
@@ -372,10 +372,10 @@ isa_irq_fixup(const struct pci_dev *dev, int irq)
return irq8 & 0xf;
 }
 
-static int __init
+static int
 dp264_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
 {
-   static char irq_tab[6][5] __initdata = {
+   static char irq_tab[6][5] = {
/*INTINTA   INTB   INTC   INTD */
{-1,-1,-1,-1,-1}, /* IdSel 5 ISA Bridge */
{ 16+ 3, 16+ 3, 16+ 2, 16+ 2, 16+ 2}, /* IdSel 6 SCSI builtin*/
@@ -456,10 +456,10 @@ monet_swizzle(struct pci_dev *dev, u8 *pinp)
return slot;
 }
 
-static int __init
+static int
 webbrick_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
 {
-   static char irq_tab[13][5] __initdata = {
+   static char irq_tab[13][5] = {
/*INTINTA   INTB   INTC   INTD */
{-1,-1,-1,-1,-1}, /* IdSel 7 ISA Bridge */
{-1,-1,-1,-1,-1}, /* IdSel 8 unused */

Re: alpha boot hang - 4.14-rc* regression

[Meelis Roos]

> > > > removing libata modules and rebooting fixes it - so it seems to be 
> > > > loading of libata.
> > > 
> > > Can you please cherry-pick:
> > > 
> > > commit b1f9e5e355e9 ("ide: fix IRQ assignment for PCI bus order probing")
> > > 
> > > from mainline and let us know if that solves the issue ?
> > 
> > No, still breaks the same way (b1f9e5e355e9 patched on top of 
> > 0e4c2eeb758a).
> > 
> > 4.14.0-rc5-00095-g1c9fec470b81 was also still broken the same way (tried 
> > on Sunday).
> 
> I am not sure I patched the right sys file but if I did, does the patch
> below help ?
> 
> I think that at sata driver binding time the kernel finds a freed
> pointer in the host bridge map_irq() hook and that's where things
> go wrong.
> 
> Please let me know if that's the right sys file, it is a mechanical
> change and making it for other sys file should be reasonably simple.
> 
> Lorenzo
> 
> -- >8 --
> diff --git a/arch/alpha/kernel/sys_dp264.c b/arch/alpha/kernel/sys_dp264.c

"Booting GENERIC on Tsunami variation Webbrick using machine vector 
Webbrick from SRM"

Seems to be the correct file - tsunami is referenced from this file and 
the IRQ-s are DP264.

But the patch does not make a difference :(

-- 
Meelis Roos (mr...@linux.ee)

Re: alpha boot hang - 4.14-rc* regression

[Meelis Roos]

> > > > removing libata modules and rebooting fixes it - so it seems to be 
> > > > loading of libata.
> > > 
> > > Can you please cherry-pick:
> > > 
> > > commit b1f9e5e355e9 ("ide: fix IRQ assignment for PCI bus order probing")
> > > 
> > > from mainline and let us know if that solves the issue ?
> > 
> > No, still breaks the same way (b1f9e5e355e9 patched on top of 
> > 0e4c2eeb758a).
> > 
> > 4.14.0-rc5-00095-g1c9fec470b81 was also still broken the same way (tried 
> > on Sunday).
> 
> I am not sure I patched the right sys file but if I did, does the patch
> below help ?
> 
> I think that at sata driver binding time the kernel finds a freed
> pointer in the host bridge map_irq() hook and that's where things
> go wrong.
> 
> Please let me know if that's the right sys file, it is a mechanical
> change and making it for other sys file should be reasonably simple.
> 
> Lorenzo
> 
> -- >8 --
> diff --git a/arch/alpha/kernel/sys_dp264.c b/arch/alpha/kernel/sys_dp264.c

"Booting GENERIC on Tsunami variation Webbrick using machine vector 
Webbrick from SRM"

Seems to be the correct file - tsunami is referenced from this file and 
the IRQ-s are DP264.

But the patch does not make a difference :(

-- 
Meelis Roos (mr...@linux.ee)

Re: alpha boot hang - 4.14-rc* regression

[Lorenzo Pieralisi]

On Wed, Oct 25, 2017 at 03:21:21PM +0300, Meelis Roos wrote:
> > > (Added linux-pci to CC)
> > > 
> > > > > I run Gentoo Linux on my alphas, with latest git kernels for test. 
> > > > > 4.13.0 worked well on 3 alphas but 4.13.0-09217-g5969d1bb3082 hangs 
> > > > > on 
> > > > > boot on all 3 of them. Tried bisecting on PC164, got into unrelated 
> > > > > stuff, so probably it does not trigger always. Retried bisecting on 
> > > > > DS10L. On the first try I got that the same keel where I first saw 
> > > > > bad 
> > > > > was the culprit, another bisect led me to 
> > > > > 0e4c2eeb758a91e68b9eaf7a4bee9bd5ed97ff2b which looks more related.
> > > > > 
> > > > > This is how the crash looks on console:
> > > > > 
> > > > >  * Starting udev ...
> > > > > starting version 225
> > > > >  [ ok ]
> > > > >  * Generating a rule to create a /dev/root symlink ...
> > > > >  [ ok ]
> > > > >  * Populating /dev with existing devices through uevents ...
> > > > >  [ ok ]
> > > > > 
> > > > > halted CPU 0
> > > > > 
> > > > > halt code = 5
> > > > > HALT instruction executed
> > > > > PC = fc9bf914
> > > > > boot failure
> > > > > >>>
> > > > > 
> > > > > What else can I do to debug this?
> > > > 
> > > > Booting with debug ignore_loglevel I get also this:
> > > [...]
> > > > So maybe it is related pcspkr loading, or the just loaded libata or 
> > > > floppy...
> > > 
> > > removing libata modules and rebooting fixes it - so it seems to be 
> > > loading of libata.
> > 
> > Can you please cherry-pick:
> > 
> > commit b1f9e5e355e9 ("ide: fix IRQ assignment for PCI bus order probing")
> > 
> > from mainline and let us know if that solves the issue ?
> 
> No, still breaks the same way (b1f9e5e355e9 patched on top of 
> 0e4c2eeb758a).
> 
> 4.14.0-rc5-00095-g1c9fec470b81 was also still broken the same way (tried 
> on Sunday).

I am not sure I patched the right sys file but if I did, does the patch
below help ?

I think that at sata driver binding time the kernel finds a freed
pointer in the host bridge map_irq() hook and that's where things
go wrong.

Please let me know if that's the right sys file, it is a mechanical
change and making it for other sys file should be reasonably simple.

Lorenzo

-- >8 --
diff --git a/arch/alpha/kernel/sys_dp264.c b/arch/alpha/kernel/sys_dp264.c
index 6c35159..88c72fe 100644
--- a/arch/alpha/kernel/sys_dp264.c
+++ b/arch/alpha/kernel/sys_dp264.c
@@ -356,7 +356,7 @@
  *  10  64 bit PCI option slot 3 (not bus 0)
  */
 
-static int __init
+static int
 isa_irq_fixup(const struct pci_dev *dev, int irq)
 {
u8 irq8;
@@ -372,10 +372,10 @@
return irq8 & 0xf;
 }
 
-static int __init
+static int
 dp264_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
 {
-   static char irq_tab[6][5] __initdata = {
+   static char irq_tab[6][5] = {
/*INTINTA   INTB   INTC   INTD */
{-1,-1,-1,-1,-1}, /* IdSel 5 ISA Bridge */
{ 16+ 3, 16+ 3, 16+ 2, 16+ 2, 16+ 2}, /* IdSel 6 SCSI builtin*/

Re: alpha boot hang - 4.14-rc* regression

[Lorenzo Pieralisi]

On Wed, Oct 25, 2017 at 03:21:21PM +0300, Meelis Roos wrote:
> > > (Added linux-pci to CC)
> > > 
> > > > > I run Gentoo Linux on my alphas, with latest git kernels for test. 
> > > > > 4.13.0 worked well on 3 alphas but 4.13.0-09217-g5969d1bb3082 hangs 
> > > > > on 
> > > > > boot on all 3 of them. Tried bisecting on PC164, got into unrelated 
> > > > > stuff, so probably it does not trigger always. Retried bisecting on 
> > > > > DS10L. On the first try I got that the same keel where I first saw 
> > > > > bad 
> > > > > was the culprit, another bisect led me to 
> > > > > 0e4c2eeb758a91e68b9eaf7a4bee9bd5ed97ff2b which looks more related.
> > > > > 
> > > > > This is how the crash looks on console:
> > > > > 
> > > > >  * Starting udev ...
> > > > > starting version 225
> > > > >  [ ok ]
> > > > >  * Generating a rule to create a /dev/root symlink ...
> > > > >  [ ok ]
> > > > >  * Populating /dev with existing devices through uevents ...
> > > > >  [ ok ]
> > > > > 
> > > > > halted CPU 0
> > > > > 
> > > > > halt code = 5
> > > > > HALT instruction executed
> > > > > PC = fc9bf914
> > > > > boot failure
> > > > > >>>
> > > > > 
> > > > > What else can I do to debug this?
> > > > 
> > > > Booting with debug ignore_loglevel I get also this:
> > > [...]
> > > > So maybe it is related pcspkr loading, or the just loaded libata or 
> > > > floppy...
> > > 
> > > removing libata modules and rebooting fixes it - so it seems to be 
> > > loading of libata.
> > 
> > Can you please cherry-pick:
> > 
> > commit b1f9e5e355e9 ("ide: fix IRQ assignment for PCI bus order probing")
> > 
> > from mainline and let us know if that solves the issue ?
> 
> No, still breaks the same way (b1f9e5e355e9 patched on top of 
> 0e4c2eeb758a).
> 
> 4.14.0-rc5-00095-g1c9fec470b81 was also still broken the same way (tried 
> on Sunday).

I am not sure I patched the right sys file but if I did, does the patch
below help ?

I think that at sata driver binding time the kernel finds a freed
pointer in the host bridge map_irq() hook and that's where things
go wrong.

Please let me know if that's the right sys file, it is a mechanical
change and making it for other sys file should be reasonably simple.

Lorenzo

-- >8 --
diff --git a/arch/alpha/kernel/sys_dp264.c b/arch/alpha/kernel/sys_dp264.c
index 6c35159..88c72fe 100644
--- a/arch/alpha/kernel/sys_dp264.c
+++ b/arch/alpha/kernel/sys_dp264.c
@@ -356,7 +356,7 @@
  *  10  64 bit PCI option slot 3 (not bus 0)
  */
 
-static int __init
+static int
 isa_irq_fixup(const struct pci_dev *dev, int irq)
 {
u8 irq8;
@@ -372,10 +372,10 @@
return irq8 & 0xf;
 }
 
-static int __init
+static int
 dp264_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
 {
-   static char irq_tab[6][5] __initdata = {
+   static char irq_tab[6][5] = {
/*INTINTA   INTB   INTC   INTD */
{-1,-1,-1,-1,-1}, /* IdSel 5 ISA Bridge */
{ 16+ 3, 16+ 3, 16+ 2, 16+ 2, 16+ 2}, /* IdSel 6 SCSI builtin*/

Re: alpha boot hang - 4.14-rc* regression

[Meelis Roos]

> > (Added linux-pci to CC)
> > 
> > > > I run Gentoo Linux on my alphas, with latest git kernels for test. 
> > > > 4.13.0 worked well on 3 alphas but 4.13.0-09217-g5969d1bb3082 hangs on 
> > > > boot on all 3 of them. Tried bisecting on PC164, got into unrelated 
> > > > stuff, so probably it does not trigger always. Retried bisecting on 
> > > > DS10L. On the first try I got that the same keel where I first saw bad 
> > > > was the culprit, another bisect led me to 
> > > > 0e4c2eeb758a91e68b9eaf7a4bee9bd5ed97ff2b which looks more related.
> > > > 
> > > > This is how the crash looks on console:
> > > > 
> > > >  * Starting udev ...
> > > > starting version 225
> > > >  [ ok ]
> > > >  * Generating a rule to create a /dev/root symlink ...
> > > >  [ ok ]
> > > >  * Populating /dev with existing devices through uevents ...
> > > >  [ ok ]
> > > > 
> > > > halted CPU 0
> > > > 
> > > > halt code = 5
> > > > HALT instruction executed
> > > > PC = fc9bf914
> > > > boot failure
> > > > >>>
> > > > 
> > > > What else can I do to debug this?
> > > 
> > > Booting with debug ignore_loglevel I get also this:
> > [...]
> > > So maybe it is related pcspkr loading, or the just loaded libata or 
> > > floppy...
> > 
> > removing libata modules and rebooting fixes it - so it seems to be 
> > loading of libata.
> 
> Can you please cherry-pick:
> 
> commit b1f9e5e355e9 ("ide: fix IRQ assignment for PCI bus order probing")
> 
> from mainline and let us know if that solves the issue ?

No, still breaks the same way (b1f9e5e355e9 patched on top of 
0e4c2eeb758a).

4.14.0-rc5-00095-g1c9fec470b81 was also still broken the same way (tried 
on Sunday).

-- 
Meelis Roos (mr...@linux.ee)

Re: alpha boot hang - 4.14-rc* regression

[Meelis Roos]

> > (Added linux-pci to CC)
> > 
> > > > I run Gentoo Linux on my alphas, with latest git kernels for test. 
> > > > 4.13.0 worked well on 3 alphas but 4.13.0-09217-g5969d1bb3082 hangs on 
> > > > boot on all 3 of them. Tried bisecting on PC164, got into unrelated 
> > > > stuff, so probably it does not trigger always. Retried bisecting on 
> > > > DS10L. On the first try I got that the same keel where I first saw bad 
> > > > was the culprit, another bisect led me to 
> > > > 0e4c2eeb758a91e68b9eaf7a4bee9bd5ed97ff2b which looks more related.
> > > > 
> > > > This is how the crash looks on console:
> > > > 
> > > >  * Starting udev ...
> > > > starting version 225
> > > >  [ ok ]
> > > >  * Generating a rule to create a /dev/root symlink ...
> > > >  [ ok ]
> > > >  * Populating /dev with existing devices through uevents ...
> > > >  [ ok ]
> > > > 
> > > > halted CPU 0
> > > > 
> > > > halt code = 5
> > > > HALT instruction executed
> > > > PC = fc9bf914
> > > > boot failure
> > > > >>>
> > > > 
> > > > What else can I do to debug this?
> > > 
> > > Booting with debug ignore_loglevel I get also this:
> > [...]
> > > So maybe it is related pcspkr loading, or the just loaded libata or 
> > > floppy...
> > 
> > removing libata modules and rebooting fixes it - so it seems to be 
> > loading of libata.
> 
> Can you please cherry-pick:
> 
> commit b1f9e5e355e9 ("ide: fix IRQ assignment for PCI bus order probing")
> 
> from mainline and let us know if that solves the issue ?

No, still breaks the same way (b1f9e5e355e9 patched on top of 
0e4c2eeb758a).

4.14.0-rc5-00095-g1c9fec470b81 was also still broken the same way (tried 
on Sunday).

-- 
Meelis Roos (mr...@linux.ee)

Re: alpha boot hang - 4.14-rc* regression

[Lorenzo Pieralisi]

On Wed, Oct 25, 2017 at 11:43:22AM +0300, Meelis Roos wrote:
> (Added linux-pci to CC)
> 
> > > I run Gentoo Linux on my alphas, with latest git kernels for test. 
> > > 4.13.0 worked well on 3 alphas but 4.13.0-09217-g5969d1bb3082 hangs on 
> > > boot on all 3 of them. Tried bisecting on PC164, got into unrelated 
> > > stuff, so probably it does not trigger always. Retried bisecting on 
> > > DS10L. On the first try I got that the same keel where I first saw bad 
> > > was the culprit, another bisect led me to 
> > > 0e4c2eeb758a91e68b9eaf7a4bee9bd5ed97ff2b which looks more related.
> > > 
> > > This is how the crash looks on console:
> > > 
> > >  * Starting udev ...
> > > starting version 225
> > >  [ ok ]
> > >  * Generating a rule to create a /dev/root symlink ...
> > >  [ ok ]
> > >  * Populating /dev with existing devices through uevents ...
> > >  [ ok ]
> > > 
> > > halted CPU 0
> > > 
> > > halt code = 5
> > > HALT instruction executed
> > > PC = fc9bf914
> > > boot failure
> > > >>>
> > > 
> > > What else can I do to debug this?
> > 
> > Booting with debug ignore_loglevel I get also this:
> [...]
> > So maybe it is related pcspkr loading, or the just loaded libata or 
> > floppy...
> 
> removing libata modules and rebooting fixes it - so it seems to be 
> loading of libata.

Can you please cherry-pick:

commit b1f9e5e355e9 ("ide: fix IRQ assignment for PCI bus order probing")

from mainline and let us know if that solves the issue ?

Thanks,
Lorenzo

> lspci -vvv from broken kernel with no libata loaded:
> 
> 00:07.0 ISA bridge: ULi Electronics Inc. M1533/M1535/M1543 PCI to ISA Bridge 
> [Aladdin IV/V/V+] (rev c3)
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B- DisINTx-
> Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
> SERR-  Latency: 0
> 
> 00:09.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 
> (rev 41)
> Subsystem: Digital Equipment Corporation DE500B Fast Ethernet
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B- DisINTx-
> Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
> SERR-  Latency: 255 (5000ns min, 1ns max), Cache Line Size: 64 bytes
> Interrupt: pin A routed to IRQ 29
> Region 0: I/O ports at 8400 [size=128]
> Region 1: Memory at 09091000 (32-bit, non-prefetchable) [size=1K]
> Expansion ROM at 0900 [disabled] [size=256K]
> Kernel driver in use: tulip
> 
> 00:0b.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 
> (rev 41)
> Subsystem: Digital Equipment Corporation DE500B Fast Ethernet
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B- DisINTx-
> Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
> SERR-  Latency: 255 (5000ns min, 1ns max), Cache Line Size: 64 bytes
> Interrupt: pin A routed to IRQ 30
> Region 0: I/O ports at 8480 [size=128]
> Region 1: Memory at 09092000 (32-bit, non-prefetchable) [size=1K]
> Expansion ROM at 0904 [disabled] [size=256K]
> Kernel driver in use: tulip
> 
> 00:0d.0 IDE interface: ULi Electronics Inc. M5229 IDE (rev c1) (prog-if f0)
> Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B- DisINTx-
> Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
> SERR-  Latency: 255 (500ns min, 1000ns max)
> Interrupt: pin A routed to IRQ 238
> Region 0: I/O ports at 01f0 [size=8]
> Region 1: I/O ports at 03f4
> Region 2: I/O ports at 0170 [size=8]
> Region 3: I/O ports at 0374
> Region 4: I/O ports at 8800 [size=16]
> 
> 00:11.0 SCSI storage controller: QLogic Corp. ISP1020 Fast-wide SCSI (rev 05)
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B- DisINTx-
> Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
> SERR-  Latency: 248, Cache Line Size: 64 bytes
> Interrupt: pin A routed to IRQ 47
> Region 0: I/O ports at 8000 [size=256]
> Region 1: Memory at 0909 (32-bit, non-prefetchable) [size=4K]
> Expansion ROM at 0908 [disabled] [size=64K]
> Kernel driver in use: qla1280
> 
> 
> /proc/interrupts from the same kernel:
>CPU0   
>   1:  3XT-PIC  i8042
>   2:  0XT-PIC  cascade
>   4:319XT-PIC  ttyS0
>   6:  3XT-PIC  floppy
>   8: 688138 dummy-RTC   timer
>  12:  5XT-PIC  i8042
>  29:975 DP264  enp0s9
>  47:  18229 DP264  qla1280
> PMI:  0   Performance Monitoring
> ERR:  0
> 
> lspci - from working 

Re: alpha boot hang - 4.14-rc* regression

[Lorenzo Pieralisi]

On Wed, Oct 25, 2017 at 11:43:22AM +0300, Meelis Roos wrote:
> (Added linux-pci to CC)
> 
> > > I run Gentoo Linux on my alphas, with latest git kernels for test. 
> > > 4.13.0 worked well on 3 alphas but 4.13.0-09217-g5969d1bb3082 hangs on 
> > > boot on all 3 of them. Tried bisecting on PC164, got into unrelated 
> > > stuff, so probably it does not trigger always. Retried bisecting on 
> > > DS10L. On the first try I got that the same keel where I first saw bad 
> > > was the culprit, another bisect led me to 
> > > 0e4c2eeb758a91e68b9eaf7a4bee9bd5ed97ff2b which looks more related.
> > > 
> > > This is how the crash looks on console:
> > > 
> > >  * Starting udev ...
> > > starting version 225
> > >  [ ok ]
> > >  * Generating a rule to create a /dev/root symlink ...
> > >  [ ok ]
> > >  * Populating /dev with existing devices through uevents ...
> > >  [ ok ]
> > > 
> > > halted CPU 0
> > > 
> > > halt code = 5
> > > HALT instruction executed
> > > PC = fc9bf914
> > > boot failure
> > > >>>
> > > 
> > > What else can I do to debug this?
> > 
> > Booting with debug ignore_loglevel I get also this:
> [...]
> > So maybe it is related pcspkr loading, or the just loaded libata or 
> > floppy...
> 
> removing libata modules and rebooting fixes it - so it seems to be 
> loading of libata.

Can you please cherry-pick:

commit b1f9e5e355e9 ("ide: fix IRQ assignment for PCI bus order probing")

from mainline and let us know if that solves the issue ?

Thanks,
Lorenzo

> lspci -vvv from broken kernel with no libata loaded:
> 
> 00:07.0 ISA bridge: ULi Electronics Inc. M1533/M1535/M1543 PCI to ISA Bridge 
> [Aladdin IV/V/V+] (rev c3)
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B- DisINTx-
> Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
> SERR-  Latency: 0
> 
> 00:09.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 
> (rev 41)
> Subsystem: Digital Equipment Corporation DE500B Fast Ethernet
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B- DisINTx-
> Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
> SERR-  Latency: 255 (5000ns min, 1ns max), Cache Line Size: 64 bytes
> Interrupt: pin A routed to IRQ 29
> Region 0: I/O ports at 8400 [size=128]
> Region 1: Memory at 09091000 (32-bit, non-prefetchable) [size=1K]
> Expansion ROM at 0900 [disabled] [size=256K]
> Kernel driver in use: tulip
> 
> 00:0b.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 
> (rev 41)
> Subsystem: Digital Equipment Corporation DE500B Fast Ethernet
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B- DisINTx-
> Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
> SERR-  Latency: 255 (5000ns min, 1ns max), Cache Line Size: 64 bytes
> Interrupt: pin A routed to IRQ 30
> Region 0: I/O ports at 8480 [size=128]
> Region 1: Memory at 09092000 (32-bit, non-prefetchable) [size=1K]
> Expansion ROM at 0904 [disabled] [size=256K]
> Kernel driver in use: tulip
> 
> 00:0d.0 IDE interface: ULi Electronics Inc. M5229 IDE (rev c1) (prog-if f0)
> Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B- DisINTx-
> Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
> SERR-  Latency: 255 (500ns min, 1000ns max)
> Interrupt: pin A routed to IRQ 238
> Region 0: I/O ports at 01f0 [size=8]
> Region 1: I/O ports at 03f4
> Region 2: I/O ports at 0170 [size=8]
> Region 3: I/O ports at 0374
> Region 4: I/O ports at 8800 [size=16]
> 
> 00:11.0 SCSI storage controller: QLogic Corp. ISP1020 Fast-wide SCSI (rev 05)
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B- DisINTx-
> Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
> SERR-  Latency: 248, Cache Line Size: 64 bytes
> Interrupt: pin A routed to IRQ 47
> Region 0: I/O ports at 8000 [size=256]
> Region 1: Memory at 0909 (32-bit, non-prefetchable) [size=4K]
> Expansion ROM at 0908 [disabled] [size=64K]
> Kernel driver in use: qla1280
> 
> 
> /proc/interrupts from the same kernel:
>CPU0   
>   1:  3XT-PIC  i8042
>   2:  0XT-PIC  cascade
>   4:319XT-PIC  ttyS0
>   6:  3XT-PIC  floppy
>   8: 688138 dummy-RTC   timer
>  12:  5XT-PIC  i8042
>  29:975 DP264  enp0s9
>  47:  18229 DP264  qla1280
> PMI:  0   Performance Monitoring
> ERR:  0
> 
> lspci - from working 4.13.0:
> 
> 00:07.0 

Re: alpha boot hang - 4.14-rc* regression

[Meelis Roos]

(Added linux-pci to CC)

> > I run Gentoo Linux on my alphas, with latest git kernels for test. 
> > 4.13.0 worked well on 3 alphas but 4.13.0-09217-g5969d1bb3082 hangs on 
> > boot on all 3 of them. Tried bisecting on PC164, got into unrelated 
> > stuff, so probably it does not trigger always. Retried bisecting on 
> > DS10L. On the first try I got that the same keel where I first saw bad 
> > was the culprit, another bisect led me to 
> > 0e4c2eeb758a91e68b9eaf7a4bee9bd5ed97ff2b which looks more related.
> > 
> > This is how the crash looks on console:
> > 
> >  * Starting udev ...
> > starting version 225
> >  [ ok ]
> >  * Generating a rule to create a /dev/root symlink ...
> >  [ ok ]
> >  * Populating /dev with existing devices through uevents ...
> >  [ ok ]
> > 
> > halted CPU 0
> > 
> > halt code = 5
> > HALT instruction executed
> > PC = fc9bf914
> > boot failure
> > >>>
> > 
> > What else can I do to debug this?
> 
> Booting with debug ignore_loglevel I get also this:
[...]
> So maybe it is related pcspkr loading, or the just loaded libata or 
> floppy...

removing libata modules and rebooting fixes it - so it seems to be 
loading of libata.

lspci -vvv from broken kernel with no libata loaded:

00:07.0 ISA bridge: ULi Electronics Inc. M1533/M1535/M1543 PCI to ISA Bridge 
[Aladdin IV/V/V+] (rev c3)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- http://www.cs.ut.ee/~mroos/

Re: alpha boot hang - 4.14-rc* regression

[Meelis Roos]

(Added linux-pci to CC)

> > I run Gentoo Linux on my alphas, with latest git kernels for test. 
> > 4.13.0 worked well on 3 alphas but 4.13.0-09217-g5969d1bb3082 hangs on 
> > boot on all 3 of them. Tried bisecting on PC164, got into unrelated 
> > stuff, so probably it does not trigger always. Retried bisecting on 
> > DS10L. On the first try I got that the same keel where I first saw bad 
> > was the culprit, another bisect led me to 
> > 0e4c2eeb758a91e68b9eaf7a4bee9bd5ed97ff2b which looks more related.
> > 
> > This is how the crash looks on console:
> > 
> >  * Starting udev ...
> > starting version 225
> >  [ ok ]
> >  * Generating a rule to create a /dev/root symlink ...
> >  [ ok ]
> >  * Populating /dev with existing devices through uevents ...
> >  [ ok ]
> > 
> > halted CPU 0
> > 
> > halt code = 5
> > HALT instruction executed
> > PC = fc9bf914
> > boot failure
> > >>>
> > 
> > What else can I do to debug this?
> 
> Booting with debug ignore_loglevel I get also this:
[...]
> So maybe it is related pcspkr loading, or the just loaded libata or 
> floppy...

removing libata modules and rebooting fixes it - so it seems to be 
loading of libata.

lspci -vvv from broken kernel with no libata loaded:

00:07.0 ISA bridge: ULi Electronics Inc. M1533/M1535/M1543 PCI to ISA Bridge 
[Aladdin IV/V/V+] (rev c3)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- http://www.cs.ut.ee/~mroos/

alpha boot hang - 4.14-rc* regression

[Meelis Roos]

I run Gentoo Linux on my alphas, with latest git kernels for test. 
4.13.0 worked well on 3 alphas but 4.13.0-09217-g5969d1bb3082 hangs on 
boot on all 3 of them. Tried bisecting on PC164, got into unrelated 
stuff, so probably it does not trigger always. Retried bisecting on 
DS10L. On the first try I got that the same keel where I first saw bad 
was the culprit, another bisect led me to 
0e4c2eeb758a91e68b9eaf7a4bee9bd5ed97ff2b which looks more related.

This is how the crash looks on console:

 * Starting udev ...
starting version 225
 [ ok ]
 * Generating a rule to create a /dev/root symlink ...
 [ ok ]
 * Populating /dev with existing devices through uevents ...
 [ ok ]

halted CPU 0

halt code = 5
HALT instruction executed
PC = fc9bf914
boot failure
>>>

What else can I do to debug this?


0e4c2eeb758a91e68b9eaf7a4bee9bd5ed97ff2b is the first bad commit
commit 0e4c2eeb758a91e68b9eaf7a4bee9bd5ed97ff2b
Author: Lorenzo Pieralisi 
Date:   Mon Jul 31 17:37:51 2017 +0100

alpha/PCI: Replace pci_fixup_irqs() call with host bridge IRQ mapping hooks

The pci_fixup_irqs() function allocates IRQs for all PCI devices present in
a system; those PCI devices possibly belong to different PCI bus trees (and
possibly rooted at different host bridges) and may well be enabled (ie
probed and bound to a driver) by the time pci_fixup_irqs() is called when
probing a given host bridge driver.

Furthermore, current kernel code relying on pci_fixup_irqs() to assign
legacy PCI IRQs to devices does not work at all for hotplugged devices in
that the code carrying out the IRQ fixup is called at host bridge driver
probe time, which just cannot take into account devices hotplugged after
the system has booted.

The introduction of map/swizzle function hooks in struct pci_host_bridge
allows us to define per-bridge map/swizzle functions that can be used at
device probe time in PCI core code to allocate IRQs for a given device
(through pci_assign_irq()).

Convert PCI host bridge initialization code to the
pci_scan_root_bus_bridge() API (that allows to pass a struct
pci_host_bridge with initialized map/swizzle pointers) and remove the
pci_fixup_irqs() call from arch code.

Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: Bjorn Helgaas 
Cc: Richard Henderson 
Cc: Ivan Kokshaysky 

:04 04 18f71e214185d05a58284efd4e97927f48e217ac 
327e88f6df911f58be520ae99a02022dab6a8f5e M  arch

In case this does not look related, here are all the known bad kernels 
from all my bisect logs:

# bad: [0e4c2eeb758a91e68b9eaf7a4bee9bd5ed97ff2b] alpha/PCI: Replace 
pci_fixup_irqs() call with host bridge IRQ mapping hooks
# bad: [19cc4c843f40c6110dd07270414586e7fe4121b2] m68k/PCI: Replace 
pci_fixup_irqs() call with host bridge IRQ mapping hooks
# bad: [1c9fec470b81ca5e89391c20a11ead31a1e9314b] waitid(): Avoid unbalanced 
user_access_end() on access_ok() error
# bad: [572c01ba19ef150e98aea0b45ca17d43356521b5] Merge tag 'scsi-misc' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
# bad: [5969d1bb3082b41eba8fd2c826559abe38ccb6df] Merge branch 'gperf-removal'
# bad: [7f1b9be13a7dbe8e51ea541bbcd6c47adae39c71] Merge tag 'armsoc-platforms' 
of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
# bad: [98611dd735b472c23cc1e8cca90a997393a3a955] tile/PCI: Replace 
pci_fixup_irqs() call with host bridge IRQ mapping hooks
# bad: [c054be10ffdbd5507a1fd738067d76acfb4808fd] remove gperf left-overs from 
build system
# bad: [d4fdf844c9c3debc080aea1be8b71d9d0aaa01dc] Merge branch 'pci/irq-fixups' 
into next
# bad: [d872694bac212f76ca13fd20a85e5c1bdb53a945] Merge branch 'pci/pm' into 
next



-- 
Meelis Roos (mr...@linux.ee)

alpha boot hang - 4.14-rc* regression

[Meelis Roos]

I run Gentoo Linux on my alphas, with latest git kernels for test. 
4.13.0 worked well on 3 alphas but 4.13.0-09217-g5969d1bb3082 hangs on 
boot on all 3 of them. Tried bisecting on PC164, got into unrelated 
stuff, so probably it does not trigger always. Retried bisecting on 
DS10L. On the first try I got that the same keel where I first saw bad 
was the culprit, another bisect led me to 
0e4c2eeb758a91e68b9eaf7a4bee9bd5ed97ff2b which looks more related.

This is how the crash looks on console:

 * Starting udev ...
starting version 225
 [ ok ]
 * Generating a rule to create a /dev/root symlink ...
 [ ok ]
 * Populating /dev with existing devices through uevents ...
 [ ok ]

halted CPU 0

halt code = 5
HALT instruction executed
PC = fc9bf914
boot failure
>>>

What else can I do to debug this?


0e4c2eeb758a91e68b9eaf7a4bee9bd5ed97ff2b is the first bad commit
commit 0e4c2eeb758a91e68b9eaf7a4bee9bd5ed97ff2b
Author: Lorenzo Pieralisi 
Date:   Mon Jul 31 17:37:51 2017 +0100

alpha/PCI: Replace pci_fixup_irqs() call with host bridge IRQ mapping hooks

The pci_fixup_irqs() function allocates IRQs for all PCI devices present in
a system; those PCI devices possibly belong to different PCI bus trees (and
possibly rooted at different host bridges) and may well be enabled (ie
probed and bound to a driver) by the time pci_fixup_irqs() is called when
probing a given host bridge driver.

Furthermore, current kernel code relying on pci_fixup_irqs() to assign
legacy PCI IRQs to devices does not work at all for hotplugged devices in
that the code carrying out the IRQ fixup is called at host bridge driver
probe time, which just cannot take into account devices hotplugged after
the system has booted.

The introduction of map/swizzle function hooks in struct pci_host_bridge
allows us to define per-bridge map/swizzle functions that can be used at
device probe time in PCI core code to allocate IRQs for a given device
(through pci_assign_irq()).

Convert PCI host bridge initialization code to the
pci_scan_root_bus_bridge() API (that allows to pass a struct
pci_host_bridge with initialized map/swizzle pointers) and remove the
pci_fixup_irqs() call from arch code.

Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: Bjorn Helgaas 
Cc: Richard Henderson 
Cc: Ivan Kokshaysky 

:04 04 18f71e214185d05a58284efd4e97927f48e217ac 
327e88f6df911f58be520ae99a02022dab6a8f5e M  arch

In case this does not look related, here are all the known bad kernels 
from all my bisect logs:

# bad: [0e4c2eeb758a91e68b9eaf7a4bee9bd5ed97ff2b] alpha/PCI: Replace 
pci_fixup_irqs() call with host bridge IRQ mapping hooks
# bad: [19cc4c843f40c6110dd07270414586e7fe4121b2] m68k/PCI: Replace 
pci_fixup_irqs() call with host bridge IRQ mapping hooks
# bad: [1c9fec470b81ca5e89391c20a11ead31a1e9314b] waitid(): Avoid unbalanced 
user_access_end() on access_ok() error
# bad: [572c01ba19ef150e98aea0b45ca17d43356521b5] Merge tag 'scsi-misc' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
# bad: [5969d1bb3082b41eba8fd2c826559abe38ccb6df] Merge branch 'gperf-removal'
# bad: [7f1b9be13a7dbe8e51ea541bbcd6c47adae39c71] Merge tag 'armsoc-platforms' 
of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
# bad: [98611dd735b472c23cc1e8cca90a997393a3a955] tile/PCI: Replace 
pci_fixup_irqs() call with host bridge IRQ mapping hooks
# bad: [c054be10ffdbd5507a1fd738067d76acfb4808fd] remove gperf left-overs from 
build system
# bad: [d4fdf844c9c3debc080aea1be8b71d9d0aaa01dc] Merge branch 'pci/irq-fixups' 
into next
# bad: [d872694bac212f76ca13fd20a85e5c1bdb53a945] Merge branch 'pci/pm' into 
next



-- 
Meelis Roos (mr...@linux.ee)

Re: alpha boot hang - 4.14-rc* regression

[Meelis Roos]

> I run Gentoo Linux on my alphas, with latest git kernels for test. 
> 4.13.0 worked well on 3 alphas but 4.13.0-09217-g5969d1bb3082 hangs on 
> boot on all 3 of them. Tried bisecting on PC164, got into unrelated 
> stuff, so probably it does not trigger always. Retried bisecting on 
> DS10L. On the first try I got that the same keel where I first saw bad 
> was the culprit, another bisect led me to 
> 0e4c2eeb758a91e68b9eaf7a4bee9bd5ed97ff2b which looks more related.
> 
> This is how the crash looks on console:
> 
>  * Starting udev ...
> starting version 225
>  [ ok ]
>  * Generating a rule to create a /dev/root symlink ...
>  [ ok ]
>  * Populating /dev with existing devices through uevents ...
>  [ ok ]
> 
> halted CPU 0
> 
> halt code = 5
> HALT instruction executed
> PC = fc9bf914
> boot failure
> >>>
> 
> What else can I do to debug this?

Booting with debug ignore_loglevel I get also this:

seq 421 queued, 'add' 'platform'
seq 417 running
passed device to netlink monitor 0x200010c7820
seq 417 processed
seq 418 running
IMPORT builtin 'hwdb' /lib/udev/rules.d/50-udev-default.rules:15
IMPORT builtin 'hwdb' returned non-zero
RUN 'kmod load $env{MODALIAS}' /lib/udev/rules.d/80-drivers.rules:5
Execute 'load' 'platform:alarmtimer'
seq 419 running
IMPORT builtin 'hwdb' /lib/udev/rules.d/50-udev-default.rules:15
IMPORT builtin 'hwdb' returned non-zero
RUN 'kmod load $env{MODALIAS}' /lib/udev/rules.d/80-drivers.rules:5
Execute 'load' 'platform:floppy'
No module matches 'platform:floppy'
passed device to netlink monitor 0x200010ca0c0
seq 419 processed
seq 421 forked new worker [453]
seq 422 queued, 'add' 'serio'
seq 420 running
GROUP 11 /lib/udev/rules.d/40-gentoo.rules:2
GROUP 6 /lib/udev/rules.d/50-udev-default.rules:55
handling device node '/dev/fd0', devnum=b2:0, mode=0660, uid=0, gid=6
set permissions /dev/fd0, 060660, uid=0, gid=6
creating symlink '/dev/block/2:0' to '../fd0'
created empty file '/run/udev/data/b2:0' for 
'/devices/platform/floppy.0/block/fd0'
passed device to netlink monitor 0x200010c7820
seq 420 processed
No module matches 'platform:alarmtimer'
passed device to netlink monitor 0x200010c8c50
seq 418 processed
passed 208 byte device to netlink monitor 0x2000109ffa0
seq 423 queued, 'add' 'serio'
seq 424 queued, 'add' 'platform'
passed 178 byte device to netlink monitor 0x2000109ffa0
seq 425 queued, 'add' 'platform'
seq 425 running
IMPORT builtin 'hwdb' /lib/udev/rules.d/50-udev-default.rules:15
IMPORT builtin 'hwdb' returned non-zero
RUN 'kmod load $env{MODALIAS}' /lib/udev/rules.d/80-drivers.rules:5
Execute 'load' 'platform:rtc-alpha'
No module matches 'platform:rtc-alpha'
passed device to netlink monitor 0x200010c7820
seq 425 processed
seq 424 running
IMPORT builtin 'hwdb' /lib/udev/rules.d/50-udev-default.rules:15
IMPORT builtin 'hwdb' returned non-zero
RUN 'kmod load $env{MODALIAS}' /lib/udev/rules.d/80-drivers.rules:5
Execute 'load' 'platform:pcspkr'
[   29.890609] libata version 3.00 loaded.

passed device to netlink monitor 0x200010c8c50
halted CPU 0

halt code = 5
HALT instruction executed
PC = fc9bf914
boot failure


So maybe it is related pcspkr loading, or the just loaded libata or 
floppy...

-- 
Meelis Roos (mr...@linux.ee)

Re: alpha boot hang - 4.14-rc* regression

[Meelis Roos]

> I run Gentoo Linux on my alphas, with latest git kernels for test. 
> 4.13.0 worked well on 3 alphas but 4.13.0-09217-g5969d1bb3082 hangs on 
> boot on all 3 of them. Tried bisecting on PC164, got into unrelated 
> stuff, so probably it does not trigger always. Retried bisecting on 
> DS10L. On the first try I got that the same keel where I first saw bad 
> was the culprit, another bisect led me to 
> 0e4c2eeb758a91e68b9eaf7a4bee9bd5ed97ff2b which looks more related.
> 
> This is how the crash looks on console:
> 
>  * Starting udev ...
> starting version 225
>  [ ok ]
>  * Generating a rule to create a /dev/root symlink ...
>  [ ok ]
>  * Populating /dev with existing devices through uevents ...
>  [ ok ]
> 
> halted CPU 0
> 
> halt code = 5
> HALT instruction executed
> PC = fc9bf914
> boot failure
> >>>
> 
> What else can I do to debug this?

Booting with debug ignore_loglevel I get also this:

seq 421 queued, 'add' 'platform'
seq 417 running
passed device to netlink monitor 0x200010c7820
seq 417 processed
seq 418 running
IMPORT builtin 'hwdb' /lib/udev/rules.d/50-udev-default.rules:15
IMPORT builtin 'hwdb' returned non-zero
RUN 'kmod load $env{MODALIAS}' /lib/udev/rules.d/80-drivers.rules:5
Execute 'load' 'platform:alarmtimer'
seq 419 running
IMPORT builtin 'hwdb' /lib/udev/rules.d/50-udev-default.rules:15
IMPORT builtin 'hwdb' returned non-zero
RUN 'kmod load $env{MODALIAS}' /lib/udev/rules.d/80-drivers.rules:5
Execute 'load' 'platform:floppy'
No module matches 'platform:floppy'
passed device to netlink monitor 0x200010ca0c0
seq 419 processed
seq 421 forked new worker [453]
seq 422 queued, 'add' 'serio'
seq 420 running
GROUP 11 /lib/udev/rules.d/40-gentoo.rules:2
GROUP 6 /lib/udev/rules.d/50-udev-default.rules:55
handling device node '/dev/fd0', devnum=b2:0, mode=0660, uid=0, gid=6
set permissions /dev/fd0, 060660, uid=0, gid=6
creating symlink '/dev/block/2:0' to '../fd0'
created empty file '/run/udev/data/b2:0' for 
'/devices/platform/floppy.0/block/fd0'
passed device to netlink monitor 0x200010c7820
seq 420 processed
No module matches 'platform:alarmtimer'
passed device to netlink monitor 0x200010c8c50
seq 418 processed
passed 208 byte device to netlink monitor 0x2000109ffa0
seq 423 queued, 'add' 'serio'
seq 424 queued, 'add' 'platform'
passed 178 byte device to netlink monitor 0x2000109ffa0
seq 425 queued, 'add' 'platform'
seq 425 running
IMPORT builtin 'hwdb' /lib/udev/rules.d/50-udev-default.rules:15
IMPORT builtin 'hwdb' returned non-zero
RUN 'kmod load $env{MODALIAS}' /lib/udev/rules.d/80-drivers.rules:5
Execute 'load' 'platform:rtc-alpha'
No module matches 'platform:rtc-alpha'
passed device to netlink monitor 0x200010c7820
seq 425 processed
seq 424 running
IMPORT builtin 'hwdb' /lib/udev/rules.d/50-udev-default.rules:15
IMPORT builtin 'hwdb' returned non-zero
RUN 'kmod load $env{MODALIAS}' /lib/udev/rules.d/80-drivers.rules:5
Execute 'load' 'platform:pcspkr'
[   29.890609] libata version 3.00 loaded.

passed device to netlink monitor 0x200010c8c50
halted CPU 0

halt code = 5
HALT instruction executed
PC = fc9bf914
boot failure


So maybe it is related pcspkr loading, or the just loaded libata or 
floppy...

-- 
Meelis Roos (mr...@linux.ee)