From owner-freebsd-i386@FreeBSD.ORG Tue Jan 17 20:20:30 2006 Return-Path: X-Original-To: freebsd-i386@hub.freebsd.org Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6173D16A420 for ; Tue, 17 Jan 2006 20:20:30 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9782743D75 for ; Tue, 17 Jan 2006 20:20:10 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k0HKK7Im027951 for ; Tue, 17 Jan 2006 20:20:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k0HKK7AU027946; Tue, 17 Jan 2006 20:20:07 GMT (envelope-from gnats) Resent-Date: Tue, 17 Jan 2006 20:20:07 GMT Resent-Message-Id: <200601172020.k0HKK7AU027946@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-i386@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Helge Oldach Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 03A8216A41F for ; Tue, 17 Jan 2006 20:10:08 +0000 (GMT) (envelope-from hmo@sep.oldach.net) Received: from rigel.oldach.net (rigel.oldach.net [194.8.96.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id C895643D7E for ; Tue, 17 Jan 2006 20:09:54 +0000 (GMT) (envelope-from hmo@sep.oldach.net) Received: from sep.oldach.net (p548F9A99.dip0.t-ipconnect.de [84.143.154.153]) by rigel.oldach.net (8.13.4/8.13.4/hmo30jul04) with ESMTP id k0HK9o97098519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 17 Jan 2006 21:09:51 +0100 (CET) (envelope-from hmo@sep.oldach.net) Received: from sep.oldach.net (localhost [127.0.0.1]) by sep.oldach.net (8.13.4/8.13.4/hmo26jun05) with ESMTP id k0HK9lVv010463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Jan 2006 21:09:47 +0100 (CET) (envelope-from hmo@sep.oldach.net) Received: (from hmo@localhost) by sep.oldach.net (8.13.4/8.13.4/Submit/hmo26jun05) id k0HK9lUR010462; Tue, 17 Jan 2006 21:09:47 +0100 (CET) (envelope-from hmo) Message-Id: <200601172009.k0HK9lUR010462@sep.oldach.net> Date: Tue, 17 Jan 2006 21:09:47 +0100 (CET) From: Helge Oldach To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: Subject: i386/91919: pccbb does not supply appropriate voltage X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Helge Oldach List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2006 20:20:30 -0000 >Number: 91919 >Category: i386 >Synopsis: pccbb does not supply appropriate voltage >Confidential: no >Severity: serious >Priority: low >Responsible: freebsd-i386 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Jan 17 20:20:06 GMT 2006 >Closed-Date: >Last-Modified: >Originator: Helge Oldach >Release: FreeBSD 5.4-STABLE i386 >Organization: >Environment: System: FreeBSD localhost 5.4-STABLE FreeBSD 5.4-STABLE #598: Tue Jan 17 16:07:22 CET 2006 toor@localhost:/usr/obj/usr/src/sys/HMO i386 >Description: I own an LG Electronics LW1100P wireless LAN PCI board, consisting of a Texas Instruments TI-1211 PCI-CardBus bridge and a wi(4)-compatible PCCARD. This card is recognized with an OLDCARD kernel but not with a(n almost) GENERIC kernel. Debugging the GENERIC kernel delivered the following output: cbb0: at device 15.0 on pci0 cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0x80000000 cbb0: Found memory at 80000000 cbb0: Secondary bus is 0 cbb0: Secondary bus set to 2 subbus 3 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [MPSAFE] cbb0: PCI Configuration space: 0x00: 0xac1e104c 0x02100007 0x06070000 0x00024208 0x10: 0x80000000 0x020000a0 0x20030200 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc 0x30: 0x00000000 0xfffffffc 0x00000000 0x0740010b 0x40: 0x00000000 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x0044b060 0x00000000 0x00000000 0x00000022 0x90: 0x616600c0 0x00000000 0x00000000 0x00000000 0xa0: 0x7e210001 0x00c00000 0x0000000b 0x0000001f 0xb0: 0x09000000 0x00000000 0x00000000 0x00000000 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 Status is 0x30001851 cbb0: card inserted: event=0x00000000, state=30001851 pccard0: chip_socket_enable cbb_pcic_socket_enable: cbb0: cbb_power: 2V pccard0: read_cis cis mem map 0xd31ad000 (resource: 0x88000000) pccard0: CIS tuple chain: CISTPL_END ff cis mem map d31ad000 CISTPL_LINKTARGET expected, code ff observed pccard0: check_cis_quirks pccard0: Card has no functions! cbb0: PC Card card activation failed The interesting line is cbb0: cbb_power: 2V which is rather odd as this is a PCI board. There should be no reason to activate this PCCARD at 2V only. It should either be a 5V or a 3.3V PCCARD. Even stranger, this PCCARD announces itself as cbb0: card inserted: event=0x00000000, state=30001851 where the state basically says it supports 3.3V (0x0800) *and* 2V (0x1000). This seems broken. I don't quite understand whether it's this specific card, or a general issue with the bridge chip. A quick code comparison revealed that the OLDCARD code is activating the slots starting with the highest voltage (5V) first, while pccbb starts at the lowest voltage (YV) first. For that reason this specific card was configured at 2V and just didn't work. For testing I changed the statement ordering around line 841 in pccbb.c (according to the patch below), and voilá: cbb0: at device 15.0 on pci0 cbb0: Found memory at 80000000 cbb0: Secondary bus is 0 cbb0: Secondary bus set to 2 subbus 3 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 Status is 0x30001851 cbb0: card inserted: event=0x00000000, state=30001851 pccard0: chip_socket_enable cbb_pcic_socket_enable: cbb0: cbb_power: 3V pccard0: read_cis cis mem map 0xd31ad000 (resource: 0x88000000) pccard0: CIS tuple chain: CISTPL_DEVICE type=null speed=null 01 03 00 00 ff CISTPL_DEVICE_A type=sram speed=ext 17 04 67 5a 08 ff [...] I suspect that this issue might be the cause for lots of NEWCARD problem reports that I've spotted through Google. There are tons of reports basically saying that it "does work with 4.x but fails with 5.x" (or 6.x). Note that 6-STABLE's pccbb.c does it the same way as 5.x. So the question is: - Is this a quirk of this specific card, or - should the voltage activation code in pccbb.c reverted to the pcic.c situation? Alternatively, a sysctl might help. >How-To-Repeat: >Fix: --- sys/dev/pccbb/pccbb.c.ctm Thu Feb 3 07:44:38 2005 +++ sys/dev/pccbb/pccbb.c Thu Jan 12 16:27:58 2006 @@ -842,14 +842,14 @@ /* Prefer lowest voltage supported */ voltage = cbb_detect_voltage(brdev); cbb_power(brdev, CARD_OFF); - if (voltage & CARD_YV_CARD) - cbb_power(brdev, CARD_VCC(YV)); - else if (voltage & CARD_XV_CARD) - cbb_power(brdev, CARD_VCC(XV)); + if (voltage & CARD_5V_CARD) + cbb_power(brdev, CARD_VCC(5)); else if (voltage & CARD_3V_CARD) cbb_power(brdev, CARD_VCC(3)); - else if (voltage & CARD_5V_CARD) - cbb_power(brdev, CARD_VCC(5)); + else if (voltage & CARD_XV_CARD) + cbb_power(brdev, CARD_VCC(XV)); + else if (voltage & CARD_YV_CARD) + cbb_power(brdev, CARD_VCC(YV)); else { device_printf(brdev, "Unknown card voltage\n"); return (ENXIO); >Release-Note: >Audit-Trail: >Unformatted: