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:
(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.