NetBSD Problem Report #55113
From www@netbsd.org Thu Mar 26 20:31:44 2020
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id 0FBE41A9213
for <gnats-bugs@gnats.NetBSD.org>; Thu, 26 Mar 2020 20:31:44 +0000 (UTC)
Message-Id: <20200326203142.99BA01A9217@mollari.NetBSD.org>
Date: Thu, 26 Mar 2020 20:31:42 +0000 (UTC)
From: vezhlys@gmail.com
Reply-To: vezhlys@gmail.com
To: gnats-bugs@NetBSD.org
Subject: Vortex86EX2 based board crashes on reboot
X-Send-Pr-Version: www-1.0
>Number: 55113
>Category: port-i386
>Synopsis: Vortex86EX2 based board crashes on reboot
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: port-i386-maintainer
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Thu Mar 26 20:35:00 +0000 2020
>Last-Modified: Fri Oct 16 18:05:01 +0000 2020
>Originator: Andrius V
>Release: NetBSD 9.99.51
>Organization:
>Environment:
>Description:
Yesterday I received the board based on DM&P Vortex86EX2 SoC. It boots without serious issues (no USB support like DX3, some other small errors and unindentified hardware), however it always crashes on reboot/shutdown with stacktrace:
Skipping crash dump on recursive panic
panic: intr_disestablish_xcall: handler not registered
cpu0: Begin traceback...
vpanic(c10f9058,db089d80,db089da8,c0150c3a,c10f9058,c0e010cc,0,c2ad1c00,ffffffff,2c) at netbsd:vpanic+0x139
snprintf(c10f9058,c0e010cc,0,c2ad1c00,ffffffff,2c,c2c58280,246,c13bbd40,c2c5a500) at netbsd:snprintf
intr_disestablish_xcall(c2c5a500,0,c05c92bd,c13bc900,da3bbd00,c2abd300,c2ad0900,4,db089df4,c0238cd7) at netbsd:intr_disestablish_xcall+0xb5
intr_disestablish(c2c5a500,c2c5a500,28,0,c2ad0900,4,c14374e0,db089e34,c09867fb,c2ad0900) at netbsd:intr_disestablish+0x55
ehci_pci_detach(c2ad0900,4,c14e9924,c09885b1,0,c2ad0c80,c14e9924,c14e9920,db089e34,c098864a) at netbsd:ehci_pci_detach+0xb9
config_detach(c2ad0900,4,0,0,0,db089e70,c011db9a,0,0,0) at netbsd:config_detach+0xca
config_detach_all(0,0,0,db089f68,0,c1403960,db089e8c,c095f32f,0,0) at netbsd:config_detach_all+0x8b
cpu_reboot(0,0,c2dcca80,0,db089f68,db089f38,c095f3ae,0,0,0) at netbsd:cpu_reboot+0x196
sys_reboot(0,0,0,0,0,0,c09b988a,c2dcca80,db089ec0,0) at netbsd:sys_reboot
sys_reboot(c2dcca80,db089f68,db089f60,c2999648,c015946c,d0,db089f60,db089f68,0,0) at netbsd:sys_reboot+0x7f
syscall() at netbsd:syscall+0x20a
--- syscall (number 208) ---
acc462d7:
cpu0: End traceback...
During boot it has some ACPI errors, but I guess it's unlikely, that they are related to crash:
Firmware Error (ACPI): A valid RSDP was not found (20191213/tbxfroot-261)
acpi_probe: failed to initialize tables
ACPI Error: Could not remove SCI handler (20191213/evmisc-317)
cpu0 at mainbus0
ACPI Error: AE_BAD_PARAMETER, Thread 3242220288 could not acquire Mutex (0x2) (20191213/utmutex-328)
ACPI Error: Mutex [ACPI_MTX_Tables] (0x2) is not acquired, cannot release (20191213/utmutex-369)
On side note, CPU has next id: 0x38504d44, current identification code is not suitable anymore without changing bitwise operations or going back to old switch statement.
Full dmesg:
NetBSD 9.99.51 (GENERIC) #23: Thu Mar 26 20:43:22 EET 2020
andriusv@jarossd:/home/andriusv/workspace/netbsd-obj/sys/arch/i386/compile/GENERIC
total memory = 1023 MB
avail memory = 982 MB
sysctl_createv: sysctl_locate(maxtypenum) returned 2
pool redzone disabled for 'buf64k'
timecounter: Timecounters tick every 10.000 msec
Kernelized RAIDframe activated
running cgd selftest aes-xts-256 aes-xts-512 done
RTC BIOS diagnostic error 0x20<config_unit>
timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100
DMP Vortex86EX (1.0)
mainbus0 (root)
Firmware Error (ACPI): A valid RSDP was not found (20191213/tbxfroot-261)
autoconfiguration error: acpi_probe: failed to initialize tables
ACPI Error: Could not remove SCI handler (20191213/evmisc-317)
cpu0 at mainbus0
ACPI Error: AE_BAD_PARAMETER, Thread 3242220288 could not acquire Mutex [ACPI_MTX_Tables] (0x2) (20191213/utmutex-328)
ACPI Error: Mutex [ACPI_MTX_Tables] (0x2) is not acquired, cannot release (20191213/utmutex-369)
cpu0: Vortex86??, id 0x602
cpu0: node 0, package 0, core 0, smt 0
pci0 at mainbus0 bus 0: configuration mode 1
pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok
pchb0 at pci0 dev 0 function 0: RDC Semiconductor product 6026 (rev. 0x00)
ppb0 at pci0 dev 4 function 0: RDC Semiconductor product 1031 (rev. 0x03)
ppb0: PCI Express capability version 1 <PCI/PCI-X to PCI-E Bridge> x1 @ 2.5GT/s
pci1 at ppb0 bus 1
pci1: i/o space, memory space enabled, rd/line, wr/inv ok
ppb1 at pci0 dev 5 function 0: RDC Semiconductor product 1031 (rev. 0x03)
ppb1: PCI Express capability version 1 <PCI/PCI-X to PCI-E Bridge> x1 @ 2.5GT/s
pci2 at ppb1 bus 2
pci2: i/o space, memory space enabled, rd/line, wr/inv ok
RDC Semiconductor product 1930 (undefined, subclass 0xff) at pci0 dev 6 function 0 not configured
pcib0 at pci0 dev 7 function 0: RDC Semiconductor product 6013 (rev. 0x00)
pcib1 at pci0 dev 7 function 1: RDC Semiconductor product 6013 (rev. 0x00)
vte0 at pci0 dev 8 function 0: RDC Semiconductor R6040 10/100 Ethernet (rev. 0x00)
vte0: Ethernet address xx:xx:xx:xx:xx:xx
vte0: interrupting at irq 6
ukphy0 at vte0 phy 1: OUI 0x00d02d, model 0x0006, rev. 0
ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
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
RDC Semiconductor product 1061 (USB serial bus, device) at pci0 dev 11 function 0 not configured
rdcide0 at pci0 dev 12 function 0: RDC R1012 IDE controller (rev. 0x05)
rdcide0: bus-master DMA support present
rdcide0: primary channel configured to compatibility mode
rdcide0: primary channel interrupting at irq 14
atabus0 at rdcide0 channel 0
rdcide0: secondary channel configured to compatibility mode
rdcide0: secondary channel ignored (disabled)
hdaudio0 at pci0 dev 14 function 0: HD Audio Controller
hdaudio0: interrupting at irq 7
hdaudio0: HDA ver. 1.0, OSS 4, ISS 4, BSS 0, SDO 1
hdafg0 at hdaudio0: vendor 10ec product 0262
hdafg0: autoconfiguration error: duplicate pin in association
hdafg0: autoconfiguration error: duplicate pin in association
hdafg0: DAC00 2ch: Speaker [Jack]
hdafg0: DAC01 2ch: HP Out [Jack]
hdafg0: DIG03 2ch: SPDIF Out [Jack]
hdafg0: DIG04 2ch: Digital Out [Jack]
hdafg0: ADC05 2ch: Mic In [Jack]
hdafg0: 2ch/2ch 44100Hz 48000Hz 96000Hz 192000Hz PCM16 PCM20 PCM24 AC3
audio0 at hdafg0: playback, capture, full duplex, independent
audio0: slinear_le:16 2ch 48000Hz, blk 4ms for playback
audio0: slinear_le:16 2ch 48000Hz, blk 4ms for recording
RDC Semiconductor product 1331 (undefined, subclass 0xff, revision 0x01) at pci0 dev 15 function 0 not configured
RDC Semiconductor product 1331 (undefined, subclass 0xff, revision 0x01) at pci0 dev 16 function 0 not configured
RDC Semiconductor product 1331 (undefined, subclass 0xff, revision 0x01) at pci0 dev 17 function 0 not configured
RDC Semiconductor product 1070 (CANbus serial bus, revision 0x01) at pci0 dev 18 function 0 not configured
RDC Semiconductor product 1070 (CANbus serial bus, revision 0x01) at pci0 dev 18 function 1 not configured
isa0 at pcib0
com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo
com0: console
com1 at isa0 port 0x2f8-0x2ff irq 3: ns16550a, working fifo
com2 at isa0 port 0x3e8-0x3ef irq 5: ns16550a, working fifo
intr_establish_xname: pic pic0 pin 5: can't share type 3 with 2
pckbc0 at isa0 port 0x60-0x64
pms0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pms0 mux 0
attimer0 at isa0 port 0x40-0x43
pcppi0 at isa0 port 0x61
midi0 at pcppi0: PC speaker
sysbeep0 at pcppi0
isapnp0 at isa0 port 0x279
pcic: does not support memory and I/O cards, ignored (ident=3)
pcic: does not support memory and I/O cards, ignored (ident=3)
pcic: does not support memory and I/O cards, ignored (ident=3)
pcic: does not support memory and I/O cards, ignored (ident=3)
attimer0: attached to pcppi0
isapnp0: no ISA Plug 'n Play devices found
isa at pcib1 not configured
timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 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
IPsec: Initialized Security Association Processing.
wd0 at atabus0 drive 0
wd0: <SS16G D0 RDC SD-IDE HOST CONTROLLER>
wd0: drive supports 1-sector PIO transfers, LBA addressing
wd0: 15193 MB, 30869 cyl, 16 head, 63 sec, 512 bytes/sect x 31116288 sectors
wd0: 32-bit data port
wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133)
wd0(rdcide0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 2 (Ultra/33) (using DMA)
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
uhub1: autoconfiguration error: device problem, disabling port 1
WARNING: 4 errors while detecting hardware; check system log.
boot device: wd0
root on wd0a dumps on wd0b
root file system type: ffs
kern.module.path=/stand/i386/9.99.51/modules
clock: unknown CMOS layout
>How-To-Repeat:
Reboot the system.
>Fix:
>Audit-Trail:
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
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
From: Andrius V <vezhlys@gmail.com>
To: gnats-bugs@netbsd.org
Cc: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: port-i386/55113: Vortex86EX2 based board crashes on reboot
Date: Fri, 27 Mar 2020 12:00:57 +0200
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> wrote:
>
> The following reply was made to PR port-i386/55113; it has been noted by GNATS.
>
> From: Martin Husemann <martin@duskware.de>
> To: gnats-bugs@netbsd.org
> 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
>
From: Andrius V <vezhlys@gmail.com>
To: gnats-bugs@netbsd.org, Martin Husemann <martin@duskware.de>
Cc: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
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> 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> wrote:
> >
> > The following reply was made to PR port-i386/55113; it has been noted by GNATS.
> >
> > From: Martin Husemann <martin@duskware.de>
> > To: gnats-bugs@netbsd.org
> > 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
> >
From: Andrius V <vezhlys@gmail.com>
To: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, gnats-bugs@netbsd.org,
Martin Husemann <martin@duskware.de>
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> wrote:
>
> The following reply was made to PR port-i386/55113; it has been noted by GNATS.
>
> From: Andrius V <vezhlys@gmail.com>
> To: gnats-bugs@netbsd.org, Martin Husemann <martin@duskware.de>
> Cc: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
> netbsd-bugs@netbsd.org
> 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> 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> wrote:
> > >
> > > The following reply was made to PR port-i386/55113; it has been noted by GNATS.
> > >
> > > From: Martin Husemann <martin@duskware.de>
> > > To: gnats-bugs@netbsd.org
> > > 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
> > >
>
From: Andrius V <vezhlys@gmail.com>
To: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, gnats-bugs@netbsd.org
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> wrote:
>
> The following reply was made to PR port-i386/55113; it has been noted by GNATS.
>
> From: Andrius V <vezhlys@gmail.com>
> To: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
> netbsd-bugs@netbsd.org, gnats-bugs@netbsd.org,
> Martin Husemann <martin@duskware.de>
> 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> wrote:
> >
> > The following reply was made to PR port-i386/55113; it has been noted by GNATS.
> >
> > From: Andrius V <vezhlys@gmail.com>
> > To: gnats-bugs@netbsd.org, Martin Husemann <martin@duskware.de>
> > Cc: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
> > netbsd-bugs@netbsd.org
> > 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> 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> wrote:
> > > >
> > > > The following reply was made to PR port-i386/55113; it has been noted by GNATS.
> > > >
> > > > From: Martin Husemann <martin@duskware.de>
> > > > To: gnats-bugs@netbsd.org
> > > > 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
> > > >
> >
>
From: Andrius V <vezhlys@gmail.com>
To: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, gnats-bugs@netbsd.org
Cc:
Subject: Re: port-i386/55113: Vortex86EX2 based board crashes on reboot
Date: Tue, 5 May 2020 23:12:35 +0300
As a "bonus" this patch can be applied to add GENESYS GL850G USB 2.0
hub controller to knows USB devices, since this is the chip which is
soldered on the board (patch didn't actually change anything in dmesg
messages but as I understand usbdevs comments, it serves as
"informational" file mostly):
diff --git a/sys/dev/usb/usbdevs b/sys/dev/usb/usbdevs
index 3248aca89fd..9c712628680 100644
--- a/sys/dev/usb/usbdevs
+++ b/sys/dev/usb/usbdevs
@@ -1668,6 +1668,7 @@ product GENERALINSTMNTS SB5100 0x5100
SURFboard SB5100 Cable modem
/* Genesys Logic products */
product GENESYS GENELINK 0x05e3 GeneLink Host-Host Bridge
product GENESYS GL650 0x0604 GL650 Hub
+product GENESYS GL850G 0x0608 GL850G USB 2.0 STT Hub Controller
product GENESYS GL641USB 0x0700 GL641USB CompactFlash Card Reader
product GENESYS GL641USB2IDE_2 0x0701 GL641USB USB-IDE Bridge
product GENESYS GL641USB2IDE 0x0702 GL641USB USB-IDE Bridge
dmesg:
[ 3.503792] uhub2 at uhub1 port 1: vendor 05e3 (0x05e3) USB2.0 Hub
(0x0608), class 9/0, rev 2.00/60.70, addr 2
[ 3.544976] uhub2: single transaction translator
[ 3.570092] uhub2: 4 ports with 4 removable, self powered
On Tue, May 5, 2020 at 10:45 PM Andrius V <vezhlys@gmail.com> wrote:
>
> The following reply was made to PR port-i386/55113; it has been noted by GNATS.
>
> From: Andrius V <vezhlys@gmail.com>
> To: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
> netbsd-bugs@netbsd.org, gnats-bugs@netbsd.org
> 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> wrote:
> >
> > The following reply was made to PR port-i386/55113; it has been noted by GNATS.
> >
> > From: Andrius V <vezhlys@gmail.com>
> > To: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
> > netbsd-bugs@netbsd.org, gnats-bugs@netbsd.org,
> > Martin Husemann <martin@duskware.de>
> > 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> wrote:
> > >
> > > The following reply was made to PR port-i386/55113; it has been noted by GNATS.
> > >
> > > From: Andrius V <vezhlys@gmail.com>
> > > To: gnats-bugs@netbsd.org, Martin Husemann <martin@duskware.de>
> > > Cc: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
> > > netbsd-bugs@netbsd.org
> > > 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> 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> wrote:
> > > > >
> > > > > The following reply was made to PR port-i386/55113; it has been noted by GNATS.
> > > > >
> > > > > From: Martin Husemann <martin@duskware.de>
> > > > > To: gnats-bugs@netbsd.org
> > > > > 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
> > > > >
> > >
> >
>
From: Andrius V <vezhlys@gmail.com>
To: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, gnats-bugs@netbsd.org
Cc:
Subject: Re: port-i386/55113: Vortex86EX2 based board crashes on reboot
Date: Fri, 16 Oct 2020 21:00:03 +0300
Hi,
I just want to update on the issue that a more recent kernel fails on
boot, not only shutdown/reboot anymore (which seems logical to me).
The reason is still the same, IRQ conflict between statically assigned
serial (com*) port and either USB (which uses IRQ5) or sometimes with
some miniPCIe plugin cards (IRQ10 specifically was the issue).
Recompiling kernel with correct com IRQs or removing serial with
conflicting IRQ alltogether makes system bootable and stable. Current
message after the crash:
kernel: supervisor trap page fault, code=0
Stopped in pid 0.0 (system) at netbsd:intr_establish_xname+0x3e1: movl
104c(%edx),%eax
Again, if a crash is expected with the IRQ conflict, the bug can be
closed, since I have a workaround and it is system specific issue.
Unrelated to this, once I found my system in ddb after I connected to
it through minicom. It was basically idle for two days (network and
COM cable connected), backtrace was like this:
breakpoint(c142b620,3f8,5,7,47278b,c2d9b1f4,c2d9b16c,c2b4e000,800,c63f7f6c)
at netbsd:breakpoint+0x4
comintr(c2d9b040,da337f30,0,0,0,0,0,0,0,0) at netbsd:comintr+0x8c0
--- switch to interrupt stack ---
Xintr_legacy4() at netbsd:Xintr_legacy4+0xda
--- interrupt ---
x86_stihlt(c2aeb040,0,c2aeb040,c01020f3,c2aeb040,c2aeb040,c0c4e120,c2aeb040,0,c0102011)
at netbsd:x86_stihlt+0x5
idle_loop(c2aeb040,1705000,1710000,0,c01005a8,0,0,0,0,0) at
netbsd:idle_loop+0x122
Haven't reproduced it second time yet, thus I will refrain from
registering a new bug, but posting it, if any clues can be determined
from this.
Regards,
Andrius V
On Tue, May 5, 2020 at 11:15 PM Andrius V <vezhlys@gmail.com> wrote:
>
> The following reply was made to PR port-i386/55113; it has been noted by GNATS.
>
> From: Andrius V <vezhlys@gmail.com>
> To: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
> netbsd-bugs@netbsd.org, gnats-bugs@netbsd.org
> Cc:
> Subject: Re: port-i386/55113: Vortex86EX2 based board crashes on reboot
> Date: Tue, 5 May 2020 23:12:35 +0300
>
> As a "bonus" this patch can be applied to add GENESYS GL850G USB 2.0
> hub controller to knows USB devices, since this is the chip which is
> soldered on the board (patch didn't actually change anything in dmesg
> messages but as I understand usbdevs comments, it serves as
> "informational" file mostly):
>
> diff --git a/sys/dev/usb/usbdevs b/sys/dev/usb/usbdevs
> index 3248aca89fd..9c712628680 100644
> --- a/sys/dev/usb/usbdevs
> +++ b/sys/dev/usb/usbdevs
> @@ -1668,6 +1668,7 @@ product GENERALINSTMNTS SB5100 0x5100
> SURFboard SB5100 Cable modem
> /* Genesys Logic products */
> product GENESYS GENELINK 0x05e3 GeneLink Host-Host Bridge
> product GENESYS GL650 0x0604 GL650 Hub
> +product GENESYS GL850G 0x0608 GL850G USB 2.0 STT Hub Controller
> product GENESYS GL641USB 0x0700 GL641USB CompactFlash Card Reader
> product GENESYS GL641USB2IDE_2 0x0701 GL641USB USB-IDE Bridge
> product GENESYS GL641USB2IDE 0x0702 GL641USB USB-IDE Bridge
>
> dmesg:
> [ 3.503792] uhub2 at uhub1 port 1: vendor 05e3 (0x05e3) USB2.0 Hub
> (0x0608), class 9/0, rev 2.00/60.70, addr 2
> [ 3.544976] uhub2: single transaction translator
> [ 3.570092] uhub2: 4 ports with 4 removable, self powered
>
> On Tue, May 5, 2020 at 10:45 PM Andrius V <vezhlys@gmail.com> wrote:
> >
> > The following reply was made to PR port-i386/55113; it has been noted by GNATS.
> >
> > From: Andrius V <vezhlys@gmail.com>
> > To: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
> > netbsd-bugs@netbsd.org, gnats-bugs@netbsd.org
> > 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> wrote:
> > >
> > > The following reply was made to PR port-i386/55113; it has been noted by GNATS.
> > >
> > > From: Andrius V <vezhlys@gmail.com>
> > > To: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
> > > netbsd-bugs@netbsd.org, gnats-bugs@netbsd.org,
> > > Martin Husemann <martin@duskware.de>
> > > 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> wrote:
> > > >
> > > > The following reply was made to PR port-i386/55113; it has been noted by GNATS.
> > > >
> > > > From: Andrius V <vezhlys@gmail.com>
> > > > To: gnats-bugs@netbsd.org, Martin Husemann <martin@duskware.de>
> > > > Cc: port-i386-maintainer@netbsd.org, gnats-admin@netbsd.org,
> > > > netbsd-bugs@netbsd.org
> > > > 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> 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> wrote:
> > > > > >
> > > > > > The following reply was made to PR port-i386/55113; it has been noted by GNATS.
> > > > > >
> > > > > > From: Martin Husemann <martin@duskware.de>
> > > > > > To: gnats-bugs@netbsd.org
> > > > > > 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
> > > > > >
> > > >
> > >
> >
>
(Contact us)
$NetBSD: query-full-pr,v 1.46 2020/01/03 16:35:01 leot Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2020
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home