NetBSD Problem Report #26204

Received: (qmail 27329 invoked by uid 605); 8 Jul 2004 12:01:02 -0000
Message-Id: <1089288059.335319.16033.nullmailer@sinus.cs.uni-bonn.de>
Date: Thu, 08 Jul 2004 14:00:59 +0200
From: ignatios@cs.uni-bonn.de
Sender: gnats-bugs-owner@NetBSD.org
Reply-To: ignatios@cs.uni-bonn.de
To: gnats-bugs@gnats.netbsd.org
Subject: if_txp doesn't work with 3com 3CR990B-FX, panics at boot time
X-Send-Pr-Version: 3.95

>Number:         26204
>Category:       kern
>Synopsis:       if_txp doesn't work with 3com 3CR990B-FX, panics at boot time
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    msaitoh
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jul 08 12:02:00 +0000 2004
>Closed-Date:    
>Last-Modified:  Thu Jan 26 12:35:00 +0000 2023
>Originator:     Ignatios Souvatzis
>Release:        NetBSD 2.0_BETA
>Organization:
computer science department, university of Bonn, Germany
>Environment:


System: NetBSD sinus 2.0_BETA NetBSD 2.0_BETA (GENERIC) #9: Thu Jul 1 14:31:57 CEST 2004 ignatios@sinus:/usr/local/src/cur/oi/sys/arch/i386/compile/GENERIC i386
Architecture: i386
Machine: i386
>Description:
	At boot time, the if_txp driver fails to load the firmware into
	our 3com 3CR990B-FX cards. 
	Additionally, it does this after establish()ing the interupt handler,
	and doesn't disestablish it when the attach() failure is detected.
	At interupt enable time, an uninitialized pointer is accessed,
	causing a kernel panic.
>How-To-Repeat:
	add:
	device txp* at pci?....
	recompile, reboot.
>Fix:
	Fix: unknown.
	Workaround: sys/dev/pci/if_txp.c 1.7 disestablish()es the interupt
	handler, thus avoiding the kernel panic. (While the cards stays 
	unusable).
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: kern-bug-people->msaitoh
Responsible-Changed-By: msaitoh@NetBSD.org
Responsible-Changed-When: Tue, 07 May 2019 06:51:37 +0000
Responsible-Changed-Why:
take.


From: "SAITOH Masanobu" <msaitoh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/26204 CVS commit: src/sys/dev/pci
Date: Tue, 7 May 2019 15:23:32 +0000

 Module Name:	src
 Committed By:	msaitoh
 Date:		Tue May  7 15:23:32 UTC 2019

 Modified Files:
 	src/sys/dev/pci: if_txp.c

 Log Message:
 - Use bus_dmamem_unmap() correctly in txp_dma_free() to prevent panic.
   The code was wrong since rev. 1.1. This panic was found by adding KASSERT
   in uvm_map.c rev. 1.351. This bug may be related to PR kern/26204.
 - Use aprint_normal() for non-error message.


 To generate a diff of this commit:
 cvs rdiff -u -r1.53 -r1.54 src/sys/dev/pci/if_txp.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: open->feedback
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Mon, 27 May 2019 02:52:00 +0000
State-Changed-Why:
fixed now? (only 15 years downstream...)


From: ignatios@cs.uni-bonn.de
To: gnats-bugs@netbsd.org
Cc: msaitoh@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: PR/26204 CVS commit: src/sys/dev/pci
Date: Thu, 5 Sep 2019 09:14:03 +0200

 Hi,

 On Tue, May 07, 2019 at 03:25:01PM +0000, SAITOH Masanobu wrote:
 > The following reply was made to PR kern/26204; it has been noted by GNATS.

 >  Modified Files:
 >  	src/sys/dev/pci: if_txp.c
 >  
 >  Log Message:
 >  - Use bus_dmamem_unmap() correctly in txp_dma_free() to prevent panic.
 >    The code was wrong since rev. 1.1. This panic was found by adding KASSERT
 >    in uvm_map.c rev. 1.351. This bug may be related to PR kern/26204.
 >  - Use aprint_normal() for non-error message.

 Oh! I'll have to see wether I can rig a test box out of the Attic. We
 moved off 100FX a while ago - a too-short while in one of the old buildings,
 but still...

 	-is
 -- 
 Ignatios Souvatzis, Chief IPv6 enabler		RFC 6540
 Gemeinsame Systemgruppe b-it + Informatik	Tel. +49 228 73-60701
 gsg@cs.uni-bonn.de

From: ignatios@cs.uni-bonn.de
To: gnats-bugs@netbsd.org
Cc: netbsd-bugs@netbsd.org, gnats-admin@netbsd.org
Subject: Re: kern/26204 (if_txp doesn't work with 3com 3CR990B-FX, panics at
 boot time)
Date: Tue, 22 Dec 2020 16:22:34 +0100

 Hello,

 On Mon, May 27, 2019 at 02:52:00AM +0000, dholland@NetBSD.org wrote:
 > Synopsis: if_txp doesn't work with 3com 3CR990B-FX, panics at boot time
 > 
 > State-Changed-From-To: open->feedback
 > State-Changed-By: dholland@NetBSD.org
 > State-Changed-When: Mon, 27 May 2019 02:52:00 +0000
 > State-Changed-Why:
 > fixed now? (only 15 years downstream...)

 I've had to reacquire one of those cards. In an amd64 box, I get
 this with netbsd-8 (and switched-off ACPI, which I need for that
 box for other reasons):

 ...
 fwohci0: Initiate bus reset
 txp0 at pci1 dev 8 function 0: vendor 10b7 product 9904
 txp0: interrupting at ioapic0 pin 5
 : fw wait failed comm0
 txp0: fw wait failed, initial
 nfe0 at pci0 dev 10 function 0: vendor 10de product 0057 (rev. 0xa3)
 ...

 -- 
 Ignatios Souvatzis, Chief IPv6 enabler		RFC 6540
 Gemeinsame Systemgruppe b-it + Informatik	Tel. +49 228 73-60701
 gsg@cs.uni-bonn.de

State-Changed-From-To: feedback->open
State-Changed-By: msaitoh@NetBSD.org
State-Changed-When: Thu, 24 Dec 2020 02:22:45 +0000
State-Changed-Why:
 The panic is fixed, but the firmware loading problem still exist.


From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/26204 (if_txp doesn't work with 3com 3CR990B-FX, panics at
 boot time)
Date: Wed, 9 Jun 2021 06:00:21 +0000

 not sent to gnats:
 (not sure if these are two versions of the same message or not)

    ------

 From: ignatios@cs.uni-bonn.de
 To: gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
 Subject: Re: kern/26204 (if_txp doesn't work with 3com 3CR990B-FX, panics at
 	boot time)
 Date: Tue, 22 Dec 2020 16:50:49 +0100

 Hi,

 an addition:

 On Tue, Dec 22, 2020 at 03:25:01PM +0000, ignatios@cs.uni-bonn.de wrote:

 >  ...
 >  fwohci0: Initiate bus reset
 >  txp0 at pci1 dev 8 function 0: vendor 10b7 product 9904
 >  txp0: interrupting at ioapic0 pin 5
 >  : fw wait failed comm0
 >  txp0: fw wait failed, initial
 >  nfe0 at pci0 dev 10 function 0: vendor 10de product 0057 (rev. 0xa3)
 >  ...

 same with netbsd-9.1 kernel and modules without acpi.

 	-is

    ------

 From: ignatios@cs.uni-bonn.de
 To: msaitoh@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
 Subject: Re: kern/26204 (if_txp doesn't work with 3com 3CR990B-FX, panics at
 	boot time)
 Date: Tue, 22 Dec 2020 17:23:05 +0100

 Hi,

 On Tue, Dec 22, 2020 at 03:25:01PM +0000, ignatios@cs.uni-bonn.de wrote:

 >  ...
 >  fwohci0: Initiate bus reset
 >  txp0 at pci1 dev 8 function 0: vendor 10b7 product 9904
 >  txp0: interrupting at ioapic0 pin 5
 >  : fw wait failed comm0
 >  txp0: fw wait failed, initial
 >  nfe0 at pci0 dev 10 function 0: vendor 10de product 0057 (rev. 0xa3)
 >  ...
 >  

 Same for netbsd-9.1

 	-is

From: ignatios@cs.uni-bonn.de
To: gnats-bugs@netbsd.org
Cc: msaitoh@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/26204 (if_txp doesn't work with 3com 3CR990B-FX, panics at
 boot time)
Date: Tue, 22 Feb 2022 10:30:38 +0100

 Same for 9.99.93, 
 and same in a different machine:

 [     1.017542] txp0 at pci9 dev 13 function 0: 3Com 3c990B 10/100 Ethernet w/ 3XP
 [     1.017542] txp0: interrupting at ioapic0 pin 16
 [     1.017542] : fw wait failed comm0
 [     1.017542] txp0: fw wait failed, initial

 	-is

From: ignatios@cs.uni-bonn.de
To: gnats-bugs@netbsd.org
Cc: netbsd-bugs@netbsd.org
Subject: Re: kern/26204 (if_txp doesn't work with 3com 3CR990B-FX, panics at
 boot time)
Date: Thu, 26 Jan 2023 13:31:40 +0100

 Hi,

 Same for 10.99.2

 leopard# dmesg | grep -A1 txp
 [     1.021048] txp0 at pci9 dev 13 function 0: 3Com 3c990B 10/100 Ethernet w/ 3XP
 [     1.021048] txp0: interrupting at ioapic0 pin 16
 [     1.021048] : fw wait failed comm0
 [     1.021048] txp0: fw wait failed, initial

 	-is

>Unformatted:

Home	PR Database Search