NetBSD Problem Report #52965

From www@NetBSD.org  Tue Jan 30 16:56:55 2018
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 C0DA97A1D0
	for <gnats-bugs@gnats.NetBSD.org>; Tue, 30 Jan 2018 16:56:55 +0000 (UTC)
Message-Id: <20180130165654.9129F7A1FB@mollari.NetBSD.org>
Date: Tue, 30 Jan 2018 16:56:54 +0000 (UTC)
From: flxd@netbsd.org
Reply-To: flxd@netbsd.org
To: gnats-bugs@NetBSD.org
Subject: irq-related panic
X-Send-Pr-Version: www-1.0

>Number:         52965
>Category:       port-shark
>Synopsis:       irq-related panic
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-shark-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Jan 30 17:00:00 +0000 2018
>Originator:     Felix Deichmann
>Release:        8.99.12
>Organization:
>Environment:
NetBSD 8.99.12 shark
>Description:
Running HEAD with vlpci(4) and PCI device support compiled in, the shark PCI adapter (see http://www.flxd.de/dnard-pci/) and a ne(4) PCI card installed, and ftp'ing from/to another machine over the network, the system quickly panics with something like:

Non-emulated page fault with intr_depth > 0
Fatal kernel mode data abort: 'Translation Fault (P)'
trapframe: 0xf3917b48
FSR=084a1017, FAR=effffffc, spsr=60000093
r0 =00000000, r1 =f045343c, r2 =0b018f00, r3 =40000013
r4 =f03a56a8, r5 =f04531dc, r6 =f1130978, r7 =00000013
r8 =00000000, r9 =ffeeb388, r10=f13cb010, r11=f3917d8c
r12=f3917b70, ssp=f3917b9c, slr=f0005e88, pc =f0005da8

Stopped in pid 847.1 (ftp) at   netbsd:irq_entry+0xe0:   ldr    r2, [r5, r9, lsl
 #2]
>How-To-Repeat:

>Fix:
The following patch (from jak@) seems to work around the problem, the panic disappears:

--- sys/arch/shark/isa/isa_irq.S        2 Dec 2013 18:36:11 -0000       1.16
+++ sys/arch/shark/isa/isa_irq.S        7 Jun 2017 15:07:25 -0000
@@ -188,7 +188,7 @@ ASENTRY_NP(irq_entry)
 .Lfind_highest_ipl:
        ldr     r2, [r5, r9, lsl #2]
        tst     r8, r2
-       subeq   r9, r9, #1
+       subeqs  r9, r9, #1
        beq     .Lfind_highest_ipl
        /* r9 = SPL level of highest priority interrupt */

However, as skrll@ and mrg@ pointed out, this change looks wrong/incomplete.
Also, there could be a lot of other arm irq_entry()s that need a similar fix.

Home	PR Database Search