Date: Tue, 17 Jan 2006 21:09:47 +0100 (CET) From: Helge Oldach <freebsdpcic@oldach.net> To: FreeBSD-gnats-submit@FreeBSD.org Subject: i386/91919: pccbb does not supply appropriate voltage Message-ID: <200601172009.k0HK9lUR010462@sep.oldach.net> Resent-Message-ID: <200601172020.k0HKK7AU027946@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>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: <TI1211 PCI-CardBus Bridge> 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: <CardBus bus> 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: <TI1211 PCI-CardBus Bridge> 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: <CardBus bus> 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:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200601172009.k0HK9lUR010462>