NetBSD Problem Report #38298

From st@tty00.org  Wed Mar 26 00:33:45 2008
Return-Path: <st@tty00.org>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by narn.NetBSD.org (Postfix) with ESMTP id CF06F63B293
	for <gnats-bugs@gnats.netbsd.org>; Wed, 26 Mar 2008 00:33:45 +0000 (UTC)
Message-Id: <20080326003549.6AAB824C3F@slartibartfast.tty00.org>
Date: Wed, 26 Mar 2008 00:35:49 +0000 (GMT)
From: stelford@mail.com
Reply-To: stelford@mail.com
To: gnats-bugs@gnats.NetBSD.org
Subject: TI1131 CardBus controller "bad Vcc request" error
X-Send-Pr-Version: 3.95

>Number:         38298
>Category:       kern
>Synopsis:       TI1131 CardBus controller "bad Vcc request" error
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Mar 26 00:35:00 +0000 2008
>Last-Modified:  Thu Apr 17 23:05:02 +0000 2008
>Originator:     Scott Telford
>Release:        NetBSD 4.0
>Organization:
>Environment:
System: NetBSD slartibartfast 4.0 NetBSD 4.0 (SLARTIBARTFAST) #1: Tue Mar 11 11:28:41 GMT 2008 st@slartibartfast:/usr/src/sys/arch/i386/compile/SLARTIBARTFAST i386
Architecture: i386
Machine: i386
>Description:
Booting the NetBSD/i386 4.0 GENERIC_LAPTOP kernel on a DEC HiNote VP710 laptop
with a TI1131 CardBus controller sometimes, but not always, (usually after a
"halt -p") results in error messages similar to the following when a CardBus
or PCMCIA card is present or is inserted:

cbb1: bad Vcc request. sock_ctrl 0x0, sock_status 0x30000710
cbb1: disabling socket
new status 0x30000710
cbb1: bad Vcc request. sock_ctrl 0x22, sock_status 0x30000719
cbb1: disabling socket

The sock_ctrl and sock_status values vary: I have also seen 0x30 for sock_ctrl
and 0x30000306, 0x30000a20 or 0x30000a68 for sock_status. The kernel appears to
hang after the messages and Ctrl-Alt-Esc fails to invoke DDB.

>How-To-Repeat:
Boot NetBSD/i386 4.0 GENERIC_LAPTOP kernel on DEC HiNote VP710 (or other 
system with TI1131?) with CardBus or PCMCIA card inserted after a "halt -p"
shutdown.

>Fix:
The following patch to dev/pci/pccbb.c (adapted from a patch posted to
port-i386@netbsd.org by Xning Lee on 2006/12/11 addressing a similar problem
with another CardBus controller) appears to fix the problem (tested with a 3Com
3C575CT CardBus card and a Xircom Ethernet 10/100 PCMCIA card).

--- pccbb.c     2008/02/03 22:33:37     1.1
+++ pccbb.c     2008/02/03 22:36:32
@@ -881,6 +881,10 @@
        bus_space_write_1(bmt, bmh, 0x800 + PCIC_INTR,
            bus_space_read_1(bmt, bmh, 0x800 + PCIC_INTR) & ~PCIC_INTR_RESET);

+       /* Redo card voltage interrogation */
+       if (bus_space_read_4(bmt, bmh, CB_SOCKET_STAT) & CB_SOCKET_STAT_BADVCC)
+               bus_space_write_4(bmt, bmh, CB_SOCKET_FORCE, 0x00004000);
+
        /* turn off power */
        pccbb_power((cardbus_chipset_tag_t)sc, CARDBUS_VCC_0V | CARDBUS_VPP_0V);

>Audit-Trail:
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/38298
Date: Wed, 26 Mar 2008 21:37:33 +0100

 The 0x00004000 needs a symbolic name (CB_SOCKET_FORCE_*, and maybe
 CB_SOCKET_STAT_*).

 So what happens is that the slot is in badvcc state and won't power down?
 Wouldn't it be better to detect and handle that inside pccbb_power()?

 Martin

From: "Scott Telford" <stelford@mail.com>
To: gnats-bugs@NetBSD.org, kern-bug-people@netbsd.org,
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, stelford@mail.com
Cc: 
Subject: Re: kern/38298
Date: Tue, 15 Apr 2008 23:24:22 +0000

 >   The 0x00004000 needs a symbolic name (CB_SOCKET_FORCE_*, and maybe
 >   CB_SOCKET_STAT_*).

 I agree. I'm not sure what this bit is called in the official documentation,
 but Linux defines it thus:

 #define    CB_CVSTEST           0x00004000      /* Card VS test */

 >=20
 >   So what happens is that the slot is in badvcc state and won't power dow=
 n?
 >   Wouldn't it be better to detect and handle that inside pccbb_power()?

 Possibly.=20

 While perusing the PR database, I found PR/36652, which seems to describe
 a similar problem. I've tried merging the pccbb.c rev 1.145 change suggested
 in this PR, which does write to CB_SOCKET_FORCE in pccbb_power(), but this
 doesn't fully fix the problem - the kernel doesn't seem to hang, but I still
 get the "disabling socket" message and the CardBus device isn't probed.
 Maybe if I added the 0x00004000 bit to the write, this might work, but I ha=
 ven't
 tried that yet.

 Regards,
 Scott.


 --=20
 Want an e-mail address like mine?
 Get a free e-mail account today at www.mail.com!

From: Arnaud Lacombe <lacombar@gmail.com>
To: Scott Telford <stelford@mail.com>
Cc: gnats-bugs@NetBSD.org, kern-bug-people@netbsd.org,
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/38298
Date: Thu, 17 Apr 2008 23:00:03 +0000

 On Tue, Apr 15, 2008 at 11:24:22PM +0000, Scott Telford wrote:
 > >   The 0x00004000 needs a symbolic name (CB_SOCKET_FORCE_*, and maybe
 > >   CB_SOCKET_STAT_*).
 > 
 > I agree. I'm not sure what this bit is called in the official documentation,
 > but Linux defines it thus:
 > 
 > #define    CB_CVSTEST           0x00004000      /* Card VS test */
 That would be CB_SOCKET_FORCE_CVTEST to match our other constant name :)

 > While perusing the PR database, I found PR/36652, which seems to describe
 > a similar problem. I've tried merging the pccbb.c rev 1.145 change suggested
 > in this PR, which does write to CB_SOCKET_FORCE in pccbb_power(), but this
 > doesn't fully fix the problem - the kernel doesn't seem to hang, but I still
 > get the "disabling socket" message and the CardBus device isn't probed.
 > Maybe if I added the 0x00004000 bit to the write, this might work, but I haven't
 > tried that yet.
 > 
 Does the patch change something for you ? I'm not sure the code is good,
 CB_SOCKET_FORCE is a register to force some bit of CB_SOCKET_STAT to 1, or in the
 is the special case of CB_SOCKET_FORCE_CVTEST to force the controller to determine
 the voltage supported and the card type, which may explain why after setting it the
 card works. Clearing bit should have no effect.

 best regards,

  - Arnaud 

Home	PR Database Search