[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
i386/92070: wi0: No irq?! with LG 11Mbps Wireless LAN PCI Card
>Number: 92070
>Category: i386
>Synopsis: wi0: No irq?! with LG 11Mbps Wireless LAN PCI Card
>Confidential: no
>Severity: serious
>Priority: low
>Responsible: freebsd-i386
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Fri Jan 20 18:30:05 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 #602: Fri Jan 20 15:43:51 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.
Please see i386/91919 for another issue with this specific card. However
this one is independent. With the patch from this PR the card is being
recognized as follows:
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
unhandled CISTPL 1d
1d 05 03 67 5a 08 ff
CISTPL_VERS_1
15 32 05 00 4c 47 00 31 31 4d 62 70 73 20 57 69
72 65 6c 65 73 73 20 4c 41 4e 20 50 43 49 20 43
61 72 64 00 56 65 72 73 69 6f 6e 20 30 31 2e 30
32 00 00 ff
CISTPL_MANFID
20 04 56 01 02 00
CISTPL_FUNCID
21 02 06 00
CISTPL_FUNCE
22 02 01 07
CISTPL_FUNCE
22 05 02 40 42 0f 00
CISTPL_FUNCE
22 05 02 80 84 1e 00
CISTPL_FUNCE
22 05 02 60 ec 53 00
CISTPL_FUNCE
22 05 02 c0 d8 a7 00
CISTPL_FUNCE
22 02 03 07
CISTPL_FUNCE
22 08 04 06 00 04 47 50 15 3a
CISTPL_FUNCE
22 02 05 01
CISTPL_CONFIG
1a 07 03 01 e0 03 00 00 01
CISTPL_CFTABLE_ENTRY
1b 0d c1 01 09 77 b5 1e 35 b5 3c 36 36 05 46
CISTPL_END
ff
cis mem map d31ad000
CISTPL_LINKTARGET expected, code 00 observed
pccard0: check_cis_quirks
pccard0: CIS version PC Card Standard 5.0
pccard0: CIS info: LG, 11Mbps Wireless LAN PCI Card, Version 01.02,
pccard0: Manufacturer code 0x156, product 0x2
pccard0: function 0: network adapter, ccr addr 3e0 mask 1
pccard0: function 0, config table entry 1: I/O card; irq mask 0; iomask 6, iospace 0-3f; io16
pccard0: functions scanning
pccard0: Card has 1 functions. pccard_mfc is 0
pccard0: I/O rid 0 start 0 end ffffffff
cbb_pcic_socket_enable:
cbb0: cbb_power: 0V
cbb0: cbb_power: 3V
pccard0: ccr_res == 88000000-880003ff, base=3e0
pccard0: function 0 CCR at 0 offset 3e0: 41 80 22 ff, ff ff ff ff, ff
wi0: <LG 11Mbps Wireless LAN PCI Card> at port 0x100-0x13f function 0 config 1 on pccard0
wi0: No irq?!
device_attach: wi0 attach returned 6
What is odd is the lack of an IRQ for the card. (With OLDCARD it is
correctly assigned irq 11.)
There is only a single function in the CIS, with a single configuration
table entry that we need to analyze:
CISTPL_CFTABLE_ENTRY
1b 0d c1 01 09 77 b5 1e 35 b5 3c 36 36 05 46
1b is the CISTPL_CFTABLE_ENTRY tag
0d is the length of this entry
c1 says that the default interface is interface 1
01 says that we are interface 1
09 says there follows a power (0x01) and an iospace (0x08) subfunction, but there is no timing, irq, memspace, or misc subfunction
This is reflected by the debug output:
pccard0: function 0, config table entry 1: I/O card; irq mask 0; iomask 6, iospace 0-3f; io16
The issue is the lack of an irq mask. I don't understand the PCMCIA
specs to well, but it appears that the card is going to tell us "I don't
care about the actual IRQ" which is not too unreasonable for a card that
is attached to a PCI-PCCARD bridge. However, since this is an I/O card,
it clearly needs an IRQ.
But the IRQ mask remains initialized to zero, which effectively disables
all IRQs for this card. Hence the "No irq?!" output from device_attach.
I think the best approach would be to initialize the IRQ mask not
to zero, but to 0xffff. This would permit all IRQs, unless the CIS
specifies an IRQ mask explicitely. For I/O cards this should be the
normal behaviour. For memory cards a pre-assigned IRQ mask doesn't harm
- they don't need an IRQ anyway.
The trivial patch below implements this default 0xffff IRQ mask.
There are certainly other approaches to this problem, e.g. interpreting
a zero cfe->irqmask as "don't care about the IRQ" upon device
attachment.
Note again that OLDCARD does it the Right Way; so the correct solution
should probably be stolen from OLDCARD (from pccardd?).
Note also that this issue is likely also present in 6-STABLE and
CURRENT.
>How-To-Repeat:
>Fix:
--- src/sys/dev/pccard/pccard_cis.c.ctm Thu Feb 3 07:44:38 2005
+++ src/sys/dev/pccard/pccard_cis.c Fri Jan 20 15:32:17 2006
@@ -1135,6 +1144,8 @@
cfe->irqmask =
(1 << (reg & PCCARD_TPCE_IR_IRQ));
}
+ } else {
+ cfe->irqmask = 0xffff;
}
if (memspace) {
if (tuple->length <= idx) {
>Release-Note:
>Audit-Trail:
>Unformatted:
