Re: port-i386/55113: Vortex86EX2 based board crashes on reboot

[Andrius V <vezhlys%gmail.com@localhost>]

The following reply was made to PR port-i386/55113; it has been noted by GNATS.

From: Andrius V <vezhlys%gmail.com@localhost>
To: port-i386-maintainer%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, 
	netbsd-bugs%netbsd.org@localhost, gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: port-i386/55113: Vortex86EX2 based board crashes on reboot
Date: Tue, 5 May 2020 22:42:21 +0300

 The crash on reboot and failing USB were caused by IRQ conflict.
 GENERIC kernel is configured to assign IRQ 5 for com2 (this board has
 5 COM ports) but IRQ 5 is used for USB only in this board. According
 to board manual, other COM ports uses IRQ 3,4, 10 and 11. So, I tested
 the the custom kernel with properly assigned IRQ values on com ports,
 USB starts to work and system doesn't crash on reboot anymore. Unless
 something still needs to be done to avoid crash in this specific
 situation, this PR can be considered solved.
 
 Regards,
 Andrius V
 
 On Thu, Apr 2, 2020 at 12:30 AM Andrius V <vezhlys%gmail.com@localhost> wrote:
 >
 > The following reply was made to PR port-i386/55113; it has been noted by GNATS.
 >
 > From: Andrius V <vezhlys%gmail.com@localhost>
 > To: port-i386-maintainer%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
 >         netbsd-bugs%netbsd.org@localhost, gnats-bugs%netbsd.org@localhost,
 >         Martin Husemann <martin%duskware.de@localhost>
 > Cc:
 > Subject: Re: port-i386/55113: Vortex86EX2 based board crashes on reboot
 > Date: Thu, 2 Apr 2020 00:26:19 +0300
 >
 >  Hi,
 >
 >  I probably found some clue on DEBUG enabled kernel boot with -vx
 >  options. There's a print output on pin5: "intr_establish_xname: pic
 >  pic0 pin 5: can't share type 3 with 2". It seems like pin5 is related
 >  to ohci/ehci since their attachment follows right after it's
 >  allocation.
 >
 >  Looking at the code intr_establish_xname returns NULL right after the printf:
 >  https://github.com/NetBSD/src/blob/cd62c3173cefc33a9a9d183c302f2df02ad15ec4/sys/arch/x86/x86/intr.c#L913
 >
 >  case IST_PULSE:
 >  if (type != IST_NONE) {
 >  intr_source_free(ci, slot, pic, idt_vec);
 >  intr_free_io_intrsource_direct(chained);
 >  mutex_exit(&cpu_lock);
 >  kmem_free(ih, sizeof(*ih));
 >  printf("%s: pic %s pin %d: can't share "
 >  "type %d with %d\n",
 >  __func__, pic->pic_name, pin,
 >  source->is_type, type);
 >  return NULL;
 >  }
 >  break;
 >
 >  Subsequent panic happens on intr_disestablish_xcall check on null:
 >  https://github.com/NetBSD/src/blob/cd62c3173cefc33a9a9d183c302f2df02ad15ec4/sys/arch/x86/x86/intr.c#L1181
 >
 >  if (q == NULL) {
 >  x86_write_psl(psl);
 >  panic("%s: handler not registered", __func__);
 >  /* NOTREACHED */
 >  }
 >
 >  Not sure if the "q" variable is really the return value from establish
 >  but I would guess it is related. It's probably more of consequence
 >  than a cause, but maybe it can give a some information on why it may
 >  have happened, especially what may have caused intr_establish_xname
 >  issue?
 >
 >  relevant dmesg parts:
 >  ....
 >  ohci0 at pci0 dev 10 function 0: RDC Semiconductor R6060 USB OHCI (rev. 0x15)
 >  csr: 02000006
 >  allocated pic pic0 type level pin 5 level 6 to cpu0 slot 5 idt entry 37
 >  ohci0: interrupting at irq 5
 >  ohci0: OHCI version 1.0, legacy support
 >  usb0 at ohci0: USB revision 1.0
 >  ehci0 at pci0 dev 10 function 1: RDC Semiconductor R6061 USB EHCI (rev. 0x09)
 >  allocated pic pic0 type level pin 5 level 6 to cpu0 slot 5 idt entry 37
 >  ehci0: interrupting at irq 5
 >  ehci0: EHCI version 1.0
 >  ehci0: 1 companion controller, 2 ports: ohci0
 >  usb1 at ehci0: USB revision 2.0
 >  ...
 >  intr_establish_xname: pic pic0 pin 5: can't share type 3 with 2
 >  ...
 >  uhub0 at usb0: NetBSD (0x0000) OHCI root hub (0x0000), class 9/0, rev
 >  1.00/1.00, addr 1
 >  uhub0: 2 ports with 2 removable, self powered
 >  uhub1 at usb1: NetBSD (0x0000) EHCI root hub (0x0000), class 9/0, rev
 >  2.00/1.00, addr 1
 >  uhub1: 2 ports with 2 removable, self powered
 >  ...
 >  ehci_sync_hc: timed out
 >  ehci_sync_hc: timed out
 >  ehci_sync_hc: timed out
 >  ehci_sync_hc: timed out
 >  ehci_sync_hc: timed out
 >  ehci_sync_hc: timed out
 >  ehci_sync_hc: timed out
 >  ehci_sync_hc: timed out
 >  ehci_sync_hc: timed out
 >  ehci_sync_hc: timed out
 >  ehci_sync_hc: timed out
 >  ...
 >  On Sat, Mar 28, 2020 at 1:45 AM Andrius V <vezhlys%gmail.com@localhost> wrote:
 >  >
 >  > The following reply was made to PR port-i386/55113; it has been noted by GNATS.
 >  >
 >  > From: Andrius V <vezhlys%gmail.com@localhost>
 >  > To: gnats-bugs%netbsd.org@localhost, Martin Husemann <martin%duskware.de@localhost>
 >  > Cc: port-i386-maintainer%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
 >  >         netbsd-bugs%netbsd.org@localhost
 >  > Subject: Re: port-i386/55113: Vortex86EX2 based board crashes on reboot
 >  > Date: Sat, 28 Mar 2020 01:42:32 +0200
 >  >
 >  >  Tried rebooting with Vortex86DX3 in ACPI mode, it didn't crash, so
 >  >  problems between two SoCs are very likely unrelated. EHCI timeout in
 >  >  VortexEX2 coming even without anything attached (unless board has
 >  >  something hidden, but I don't see any candidate). Plus, I also
 >  >  realized from dmesg messages that Vortex86EX probably doesn't have
 >  >  ACPI enabled (or ACPI support at all), thus those ACPI errors are
 >  >  coming from this. So, possibly error messages are related to eventual
 >  >  crash on reboot. Will try to enable some debugging to see if anything
 >  >  more will come up.
 >  >
 >  >  On the side note is there any ideas on the best way to change
 >  >  cpu_probe_vortex86 to include 0x38504d44 as EX2? Thanks.
 >  >
 >  >
 >  >  On Fri, Mar 27, 2020 at 12:00 PM Andrius V <vezhlys%gmail.com@localhost> wrote:
 >  >  >
 >  >  > Actually I included full dmesg in bug report unless something more may
 >  >  > come with different build options? Except number of "ehci_sync_hc:
 >  >  > timed out" messages everything else seems to be as "usual". This
 >  >  > message comes only if something (non keyboard) is physically attached
 >  >  > to USB (and it fails to attach). These messages probably caused by the
 >  >  > same issue as PR 53894 in Vortex86DX3 (as much as I tried to
 >  >  > investigate last year, USB transfer  was timing out, which in turn
 >  >  > calls ehci_sync_hc and it is timing out as well). Possibly reboot
 >  >  > issue is related and this bug may be a duplicate. I should try to
 >  >  > somehow to reproduce this on Vortex86DX3 in ACPI mode too
 >  >  > (unfortunately, on ACPI mode I've never done proper reboot/shutdown
 >  >  > since both network and USB doesn't work and I can't interact with
 >  >  > system in any way and system is autopower without power button, but I
 >  >  > probably can schedule a cron job).
 >  >  >
 >  >  > Parts from dmesg:
 >  >  >
 >  >  > ohci0 at pci0 dev 10 function 0: RDC Semiconductor R6060 USB OHCI (rev. 0x15)
 >  >  > ohci0: interrupting at irq 5
 >  >  > ohci0: OHCI version 1.0, legacy support
 >  >  > usb0 at ohci0: USB revision 1.0
 >  >  > ehci0 at pci0 dev 10 function 1: RDC Semiconductor R6061 USB EHCI (rev. 0x09)
 >  >  > ehci0: interrupting at irq 5
 >  >  > ehci0: EHCI version 1.0
 >  >  > ehci0: 1 companion controller, 2 ports: ohci0
 >  >  > usb1 at ehci0: USB revision 2.0
 >  >  > ....
 >  >  > uhub0 at usb0: NetBSD (0x0000) OHCI root hub (0x0000), class 9/0, rev
 >  >  > 1.00/1.00, addr 1
 >  >  > uhub0: 2 ports with 2 removable, self powered
 >  >  > uhub1 at usb1: NetBSD (0x0000) EHCI root hub (0x0000), class 9/0, rev
 >  >  > 2.00/1.00, addr 1
 >  >  > uhub1: 2 ports with 2 removable, self powered
 >  >  > ...
 >  >  > ehci_sync_hc: timed out
 >  >  > ehci_sync_hc: timed out
 >  >  > ehci_sync_hc: timed out
 >  >  > ...
 >  >  >
 >  >  >
 >  >  > On Fri, Mar 27, 2020 at 9:05 AM Martin Husemann <martin%duskware.de@localhost> wrote:
 >  >  > >
 >  >  > > The following reply was made to PR port-i386/55113; it has been noted by GNATS.
 >  >  > >
 >  >  > > From: Martin Husemann <martin%duskware.de@localhost>
 >  >  > > To: gnats-bugs%netbsd.org@localhost
 >  >  > > Cc:
 >  >  > > Subject: Re: port-i386/55113: Vortex86EX2 based board crashes on reboot
 >  >  > > Date: Fri, 27 Mar 2020 08:01:52 +0100
 >  >  > >
 >  >  > >  Can you show the dmesg part(s) about ehci attching? I guess there is an
 >  >  > >  error message in there.
 >  >  > >
 >  >  > >  Martin
 >  >  > >
 >  >
 >