NetBSD Problem Report #13613

Received: (qmail 10913 invoked from network); 1 Aug 2001 17:17:08 -0000
Message-Id: <20010801172056.5FFCD1110F@www.netbsd.org>
Date: Wed,  1 Aug 2001 10:20:56 -0700 (PDT)
From: krupp@mipz.de
Sender: nobody@netbsd.org
Reply-To: krupp@mipz.de
To: gnats-bugs@gnats.netbsd.org
Subject: protection fault trap while probing Lucent wi PCMCIA-Card
X-Send-Pr-Version: www-1.0
X-GNATS-Notify: jhawk@NetBSD.ORG

>Number:         13613
>Category:       kern
>Synopsis:       protection fault trap while probing Lucent wi PCMCIA-Card
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people
>State:          analyzed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Aug 01 17:18:00 +0000 2001
>Closed-Date:    
>Last-Modified:  Sun Sep 03 01:13:11 +0000 2006
>Originator:     Heiko Krupp
>Release:        1.5.1
>Organization:
MIP GmbH
>Environment:
NetBSD  1.5.1 NetBSD 1.5.1 (GENERIC) #56: Mon Jul  2 15:54:23 CEST 2001     he@nsa.uninett.no:/usr/src/sys/arch/i386/compile/GENERIC i386
>Description:
System (Toshiba Satellite Pro 420CDT) starts and after probing
PCMCIA-Cards it drops into Kernel-Debugger after detecting a wi0
Interface.

>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:

From: John Hawkinson <jhawk@MIT.EDU>
To: krupp@mipz.de
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: kern/13613: protection fault trap while probing Lucent wi PCMCIA-Card
Date: Mon, 20 Aug 2001 13:57:48 -0400 (EDT)

 Hi!

 | System (Toshiba Satellite Pro 420CDT) starts and after probing
 | PCMCIA-Cards it drops into Kernel-Debugger after detecting a wi0

 Can you please provide a stack trace (output of "t") in the kernel
 debugger when this happens?

 Thanks. Sorry for the delay.

 --jhawk

From: John Hawkinson <jhawk@MIT.EDU>
To: gnats-bugs@netbsd.org
Cc:  
Subject: kern/13613: stack trace, etc.
Date: Thu, 6 Feb 2003 19:08:12 -0500 (EST)

 I had the joy to encounter this problem today on a Toshiba Satelite T1910CS
 (ancient laptop) with the NetBSD-1-6 branch.

 wi0 at pcmcia0 function 0: Lucent Technologies, WaveLAN/IEEE, Version 01.01
 wi0: port 0x400-0x43fpcmcia0: card irq 9
 kernel: protection fault trap, code=0
 Stopped in pid 2 (pcic0,0,0) at 0xc0100c7c:     pushl   $0x4
 db> t
 (null)(c05d9000,5,c011f9c0,c05d9000) at 0xc0100c7c
 (null)(c05b8200,c05d9000,c3840f0c,c01ae3a4,c05d9000,c3840f0c,c05b8214,c01adf27) at 0xc0286cd2
 (null)(c05b8200,c02ee4f0,c3840f0c,c027549c,c05b6480) at 0xc01ae3b8
 (null)(c05b8200,c3840f0c,c027549c,c0275464,c05c689c) at 0xc01ae003
 (null)(c05b8200,c05c689c,0,0,c05c689c) at 0xc027538d
 (null)(c05c689c,2,0,0) at 0xc026f782
 (null)(c05c689c) at 0xc026f172
 db> 


 Translated with http://web.mit.edu/watchmaker/src/unsym/unsym (modified
 to support nm symbol files):

 wi0 at pcmcia0 function 0: Lucent Technologies, WaveLAN/IEEE, Version 01.01
 wi0: port 0x400-0x43fpcmcia0: card irq 9
 kernel: protection fault trap, code=0
 Stopped in pid 2 (pcic0,0,0) at [c0100c7c=Xtrap0d+0x0]:     pushl   $0x4
 db> t
 (null)(c05d9000,5,[c011f9c0=wi_intr+0x0],c05d9000) at [c0100c7c=Xtrap0d+0x0]
 (null)(c05b8200,c05d9000,c3840f0c,[c01ae3a4=config_attach+0x218],c05d9000,c3840f0c,c05b8214,[c01adf27=config_search+0x77]) at [c0286cd2=wi_pcmcia_attach+0x172]
 (null)(c05b8200,[c02ee4f0=cfdata+0x1f8],c3840f0c,[c027549c=pcmcia_print+0x0],c05b6480) at [c01ae3b8=config_attach+0x22c]
 (null)(c05b8200,c3840f0c,[c027549c=pcmcia_print+0x0],[c0275464=pcmcia_submatch+0x0],c05c689c) at [c01ae003=config_found_sm+0x2f]
 (null)(c05b8200,c05c689c,0,0,c05c689c) at [c027538d=pcmcia_card_attach+0xf9]
 (null)(c05c689c,2,0,0) at [c026f782=pcic_attach_card+0x1e]
 (null)(c05c689c) at [c026f172=pcic_event_thread+0x216]
 db> 

 Hmm, that's an ugly format. Well:

 [c0100c7c=Xtrap0d+0x0]
 [c0286cd2=wi_pcmcia_attach+0x172]
 [c01ae3b8=config_attach+0x22c]
 [c01ae003=config_found_sm+0x2f]
 [c027538d=pcmcia_card_attach+0xf9]
 [c026f782=pcic_attach_card+0x1e]
 [c026f172=pcic_event_thread+0x216]

 --jhawk

From: John Hawkinson <jhawk@MIT.EDU>
To: gnats-bugs@netbsd.org
Cc:  
Subject: kern/13613: stack trace, etc.
Date: Thu, 6 Feb 2003 21:23:50 -0500 (EST)

 Easy workaround is to set

 	pcic_isa_alloc_iobase	0x300
 	pcic_isa_alloc_iosize	0xbf

 I'll try to see if I can find out what the conflict is and why.

 --jhawk

From: John Hawkinson <jhawk@MIT.EDU>
To: Martin Husemann <martin@duskware.de>
Cc: gnats-bugs@netbsd.org
Subject: Re: kern/13613: stack trace, etc.
Date: Fri, 7 Feb 2003 10:42:54 -0500

 Martin Husemann <martin@duskware.de> wrote on Fri,  7 Feb 2003
 at 08:27:59 +0100 in <20030207072759.GD2327@drowsy.duskware.de>:

 > To: John Hawkinson <jhawk@MIT.EDU>

 You should cc gnats-bugs, I think. How'd you notice this PR get updated
 so quickly?

 > >  [c0100c7c=Xtrap0d+0x0]
 > >  [c0286cd2=wi_pcmcia_attach+0x172]
 > 
 > Could you disassemble wi_pcmcia_attach (x/i in both ddb and gdb, IIRC,
 > like "x/16i wi_pcmcia_attach" (or the hex value instead of the symbol name,
 > maybe leaving out the 16 and repeating until +0x172 is covered))
 > 
 > Alternatively, send a objdump -d output of the *wi*.o file containing that
 > symbol.

 It's the build from 20030205 on releng.netbsd.org, you can grab it
 yourself...otherwise I can do it later this afternoon (UTC-5).

 If it's a bug in the wi driver I'm not sure its worth fixing...the root
 cause is an isa iospace conflict, and that won't just go away without
 more effort.

 --jhawk

From: Martin Husemann <martin@duskware.de>
To: John Hawkinson <jhawk@MIT.EDU>
Cc: gnats-bugs@netbsd.org
Subject: Re: kern/13613: stack trace, etc.
Date: Fri, 7 Feb 2003 17:02:12 +0100

 On Fri, Feb 07, 2003 at 10:42:54AM -0500, John Hawkinson wrote:

 > It's the build from 20030205 on releng.netbsd.org, you can grab it
 > yourself...otherwise I can do it later this afternoon (UTC-5).

 Thanks, I can fetch that.

 > If it's a bug in the wi driver I'm not sure its worth fixing...the root
 > cause is an isa iospace conflict, and that won't just go away without
 > more effort.

 Every crash is worth fixing, IMHO.

 Martin

From: John Hawkinson <jhawk@MIT.EDU>
To: Martin Husemann <martin@duskware.de>
Cc: gnats-bugs@netbsd.org
Subject: Re: kern/13613: stack trace, etc.
Date: Fri, 7 Feb 2003 11:05:43 -0500

 Martin Husemann <martin@duskware.de> wrote on Fri,  7 Feb 2003
 at 17:02:12 +0100 in <20030207160212.GD3190@drowsy.duskware.de>:

 > > If it's a bug in the wi driver I'm not sure its worth fixing...the root
 > > cause is an isa iospace conflict, and that won't just go away without
 > > more effort.
 > 
 > Every crash is worth fixing, IMHO.

 Right...I'm suggesting that if indeed there's a bug in the wi driver
 involved here [I'm not so sure], we will likely still crash when it is
 fixed, because of the iospace conflict.

 --jhawk

From: John Hawkinson <jhawk@MIT.EDU>
To: Martin Husemann <martin@duskware.de>
Cc: gnats-bugs@netbsd.org
Subject: Re: kern/13613: stack trace, etc.
Date: Sat, 8 Feb 2003 11:37:51 -0500

 Martin Husemann <martin@duskware.de> wrote on Sat,  8 Feb 2003
 at 09:35:18 +0100 in <20030208083517.GB4839@drowsy.duskware.de>:

 > Which of the kernels did you try to boot?
 > The symbols all differ slightly...

 Oops, sorry. INSTALL_LAPTOP of course.


 Martin Husemann <martin@duskware.de> wrote on Sat,  8 Feb 2003
 at 09:37:00 +0100 in <20030208083700.GC4839@drowsy.duskware.de>:


 > Even better would be if you could try booting GENERIC and get the trace from
 > that.

 Err, umm, ok. Not really sure why, but can do. Later today I guess...

 --jhawk

From: John Hawkinson <jhawk@MIT.EDU>
To: Martin Husemann <martin@duskware.de>
Cc: kern-bug-people@netbsd.org, gnats-bugs@netbsd.org
Subject: Re: kern/13613: stack trace, etc.
Date: Sat, 8 Feb 2003 14:42:30 -0500

 Martin Husemann <martin@duskware.de> wrote on Sat,  8 Feb 2003
 at 18:52:44 +0100 in <20030208175244.GE4839@drowsy.duskware.de>:

 > Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org

 Where did that come from? It seems totally wrong (omitting gnats-bugs).

 > It has the symbols in place so ddb will give good output right from the
 > start. Eliminates one dubious step of the decoding...

 You have me rather unconvinced, but here you go.

 --jhawk

 > boot /ng.gz
 booting hd0a:/ng.gz
 5488224+112552+341476 [305712+256831]=0x635320
 [ using 562996 bytes of netbsd ELF symbol table ]
 BIOS CFG: Model-SubM-Rev: fc-01-00, 0x74<EBDA,KBDINT,RTC,IC2>
 Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002
     The NetBSD Foundation, Inc.  All rights reserved.
 Copyright (c) 1982, 1986, 1989, 1991, 1993
     The Regents of the University of California.  All rights reserved.

 NetBSD 1.6.1_RC1 (GENERIC) #0: Thu Feb  6 15:14:02 UTC 2003
     autobuild@tgm.daemon.org:/autobuild/netbsd-1-6/i386/OBJ/autobuild/netbsd-1-6/src/sys/arch/i386/compile/GENERIC
 cpu0: Intel 486SX (486-class)
 cpu0: features 2<VME>
 total memory = 12156 KB
 avail memory = 4772 KB
 using 177 buffers containing 708 KB of memory
 mainbus0 (root)
 isa0 at mainbus0
 com0 at isa0 port 0x3f8-0x3ff irq 4: ns8250 or ns16450, no fifo
 com0: console
 pckbc0 at isa0 port 0x60-0x64
 pckbd0 at pckbc0 (kbd slot)
 pckbc0: using irq 1 for kbd slot
 wskbd0 at pckbd0 mux 1
 wdc0 at isa0 port 0x1f0-0x1f7 irq 14
 wd0 at wdc0 channel 0 drive 0: <ST9235A>
 wd0: drive supports 8-sector PIO transfers, chs addressing
 wd0: 200 MB, 985 cyl, 13 head, 32 sec, 512 bytes/sect x 409760 sectors
 vga0 at isa0 port 0x3b0-0x3df iomem 0xa0000-0xbffff
 wsdisplay0 at vga0 kbdmux 1
 wsmux1: connecting to wsdisplay0
 wskbd0: connecting to wsdisplay0
 lpt0 at isa0 port 0x378-0x37b irq 7
 pcppi0 at isa0 port 0x61
 midi0 at pcppi0: PC speaker
 sysbeep0 at pcppi0
 isapnp0 at isa0 port 0x279: ISA Plug 'n Play device support
 fdc0 at isa0 port 0x3f0-0x3f7 irq 6 drq 2
 fd0 at fdc0 drive 0: 1.44MB, 80 cyl, 2 head, 18 sec
 pcic0 at isa0 port 0x3e0-0x3e1 iomem 0xd0000-0xdffff irq 
 pcic0: controller 0 (Intel 82365SL Revision 1) has socket A only
 pcic0: controller 1 (Intel 82365SL Revision 1) has no sockets
 pcmcia0 at pcic0 controller 0 socket 0
 isapnp0: no ISA Plug 'n Play devices found
 biomask ff6d netmask ff6d ttymask ffef
 pcic0: controller 0 detecting irqs with mask 0xdeb8:..3..5..9..10..11..15
 pcic0: using irq 3 for socket events
 Kernelized RAIDframe activated
 wi0 at pcmcia0 function 0: Lucent Technologies, WaveLAN/IEEE, Version 01.01
 wi0: port 0x400-0x43fpcmcia0: card irq 5
 kernel: protection fault trap, code=0
 Stopped in pid 2 (pcic0,0,0) at Xtrap0d:        pushl   $0x4
 db> t
 Xtrap0d(c01702a7,c3a50008,10246,c07c6000) at Xtrap0d
 end(c07fa000,5,c01714b0,c07fa000) at 0xc07f0703
 wi_pcmcia_attach(c07c8800,c07fa000,c3a58efc,c028bfc0,c07fa000,c3a58efc,c07c8814,
 c028bb10) at wi_pcmcia_attach+0x172
 config_attach(c07c8800,c063f914,c3a58efc,c0474388,c07c6080) at config_attach+0x2
 48
 config_found_sm(c07c8800,c3a58efc,c0474388,c0474350,c07d409c) at config_found_sm
 +0x2f
 pcmcia_card_attach(c07c8800,c07d409c,0,0,c07d409c) at pcmcia_card_attach+0xf9
 pcic_attach_card(c07d409c,2,0,0) at pcic_attach_card+0x1e
 pcic_event_thread(c07d409c) at pcic_event_thread+0x216
 db> 

From: Martin Husemann <martin@duskware.de>
To: John Hawkinson <jhawk@MIT.EDU>
Cc: kern-bug-people@netbsd.org, gnats-bugs@netbsd.org
Subject: Re: kern/13613: stack trace, etc.
Date: Sat, 8 Feb 2003 21:36:43 +0100

 On Sat, Feb 08, 2003 at 02:42:30PM -0500, John Hawkinson wrote:

 > You have me rather unconvinced, but here you go.

 Sorry, I was insisting since the prior results didn't make any sense to me.
 Unfortunately, it's still consistent:

 0xc0486cde <wi_pcmcia_attach+350>:	mov    %esi,%esi
 0xc0486ce0 <wi_pcmcia_attach+352>:	lea    0x2c(%esi),%eax
 0xc0486ce3 <wi_pcmcia_attach+355>:	mov    %eax,0x1a0(%esi)
 0xc0486ce9 <wi_pcmcia_attach+361>:	add    $0xfffffff4,%esp
 0xc0486cec <wi_pcmcia_attach+364>:	push   %esi
 0xc0486ced <wi_pcmcia_attach+365>:	call   0xc01701e0 <wi_attach>
 0xc0486cf2 <wi_pcmcia_attach+370>:	add    $0x10,%esp

 (370 = 0x172)
 There's nothing in here that would justify a protection fault trap, IMHO.
 Maybe it's realy wi_attach that's faulting (it's the first thing that tries
 to access the pcmcia ports previously mapped in wi_pcmcia_attach). Or the
 crash happens in the interrupt handler, since that has been established
 a few instructions ago.

 Since the code seems to properly check all return values, I realy don't see
 what's going on.

 Your workaround (move the pcmcia IO map window down to 0x300) probably breaks
 wi for many other machines (it's beyound 0x400 for a reason).

 I don't have clever ideas how to proceed - besides sprinkling printfs in there
 and narrowing down the real crash. Maybe some i386-clued person could have
 a look?

 Martin

From: John Hawkinson <jhawk@MIT.EDU>
To: Martin Husemann <martin@duskware.de>
Cc: kern-bug-people@netbsd.org, gnats-bugs@netbsd.org
Subject: Re: kern/13613: stack trace, etc.
Date: Sat, 8 Feb 2003 17:12:15 -0500

 Martin Husemann <martin@duskware.de> wrote on Sat,  8 Feb 2003
 at 21:36:43 +0100 in <20030208203642.GA7248@drowsy.duskware.de>:

 > Since the code seems to properly check all return values, I realy don't see
 > what's going on.
 > 
 > Your workaround (move the pcmcia IO map window down to 0x300)
 > probably breaks wi for many other machines (it's beyound 0x400 for a
 > reason).

 Sure. I'm not proposing it as a general solution, merely for this
 laptop. 

 > I don't have clever ideas how to proceed - besides sprinkling
 > printfs in there and narrowing down the real crash. Maybe some
 > i386-clued person could have a look?

 Again, the root cause is an iospace conflict. Something else is
 using the io space and is dying when the wi card frobs its registers.
 I don't think there's much point in trying to stare too hard at the
 wi driver if there's nothing obviously wrong with it.

 --jhawk


From: Heiko Krupp <krupp@mipz.de>
To: gnats-bugs@gnats.netbsd.org
Cc:  
Subject: kern/13613: protection fault trap while probing Lucent wi PCMCIA-Card
Date: Fri, 16 Apr 2004 13:31:10 +0200

 Hiho...

 in http://mail-index.netbsd.org/current-users/2004/03/27/0004.html I read t=
 hat=20
 this bug is probably fixed. Yesterday I found some time to check this again=
 st=20
 1.6.2 and current. Both versions still have this bug. After probing the wi0=
 =20
 the kernel drops into the debugger.

 wi0 at pcmcia1 function0: Lucent Technologies, WaveLAN/IEEE, Version 01.01
 pcic0: port 0x400-0x43f
 pcmcia1: card irq 11
 wi0: kernel: protection fault trap, code=3D0 stopped in pid 5.1 (pcic0,0,1)=
  at=20
 0xc0102ca4: pushc $0x4

 So this bug is still existent but my laptop is even more outdated now ;-)

 	Heiko Krupp.

 =2D-=20
  /"\  Multimedia Internet Park GmbH, Prager Ring 4-12
  \ /  D-66482 Zweibr=FCcken. Tel: 06332/79-1164 Fax: 06332/79-1101
   X   export LANG=3DDE -> Kein Weltraum links auf dem Geraet!
  / \  ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL


From: Martin Husemann <martin@duskware.de>
To: Heiko Krupp <krupp@mipz.de>
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org
Subject: Re: kern/13613: protection fault trap while probing Lucent wi PCMCIA-Card
Date: Fri, 16 Apr 2004 20:28:27 +0200

 On Fri, Apr 16, 2004 at 11:32:02AM -0000, Heiko Krupp wrote:
 >  So this bug is still existent but my laptop is even more outdated now ;-)

 Does it work for you if you move the pcmcia IO base around, as John suggested?

 Martin

State-Changed-From-To: open->analyzed 
State-Changed-By: mycroft 
State-Changed-When: Thu Aug 5 21:23:11 UTC 2004 
State-Changed-Why:  
This is due to an I/O space conflict, not a wi bug.  This is a general resource 
allocation issue. 


Responsible-Changed-From-To: kern-bug-people->mycroft 
Responsible-Changed-By: mycroft 
Responsible-Changed-When: Thu Aug 5 21:23:11 UTC 2004 
Responsible-Changed-Why:  
. 
Responsible-Changed-From-To: mycroft->kern-bug-people
Responsible-Changed-By: wiz@netbsd.org
Responsible-Changed-When: Sun, 03 Sep 2006 01:13:11 +0000
Responsible-Changed-Why:
Back to role account, mycroft doesn't have commit access any longer.


>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.