Problems with pcmcia driver

Tue Aug 11 10:28:11 EDT 2009

Hi!

I'm not sure if i'm posting to the right place, so if i'm wrong, please 
forward it to the "right" people. :-)

Now, on the problem. I own laptop, Dell Latitude D630 with 4Gig of ram. 
Installed is Ubuntu, 9.04 Desktop x86_64, with 2.6.28 kernel. I also own 
pcmcia network card, Edimax EP-4203DL (1gb), which is having problems. 
More precisely - it does not work. My first guess was that this is 
driver related and i did try all of them - with no success.

Problem is, that when card is inserted, card is recognized and right 
driver is loaded, BUT, then driver reports unknown eeprom version and 
assigns -1 (ff:ff:ff:ff:ff:ff) as mac address. Of course, any attempt to 
change mac back to right or to initialize card - just fails. As the card 
is not there!? I get those stupid error "unable to assign address" or 
something from ifconfig command.

After a lot of fiddling around, i did notice following line:

pci_bus 0000:03: Raising subordinate bus# of parent bus (#03) from #04 
to #07

After investigating a little, i found that this is related to fixup for 
bios bug, which incorrectly assigns bus id to pcmcia chip? This message 
is from code which attempts to reassign bus so card can work. But, in my 
case, it does not.

What is very interesting is that, removing yenta_socket module and 
inserting it again - solves the problem!!!

Here is dmesg for first insert:

[    8.036478] yenta_cardbus 0000:03:01.0: CardBus bridge found [1028:01f9]
[    8.036502] yenta_cardbus 0000:03:01.0: O2: res at 0x94/0xD4: 00/ea
[    8.036503] yenta_cardbus 0000:03:01.0: O2: enabling read 
prefetch/write burst
[    8.165238] yenta_cardbus 0000:03:01.0: ISA IRQ mask 0x04b8, PCI irq 19
[    8.165241] yenta_cardbus 0000:03:01.0: Socket status: 30000006
[    8.165244] pci_bus 0000:03: Raising subordinate bus# of parent bus 
(#03) from #04 to #07
[    8.165249] yenta_cardbus 0000:03:01.0: pcmcia: parent PCI bridge I/O 
window: 0x2000 - 0x2fff
[    8.165251] yenta_cardbus 0000:03:01.0: pcmcia: parent PCI bridge 
Memory window: 0xf1d00000 - 0xf1dfffff
[    8.165252] yenta_cardbus 0000:03:01.0: pcmcia: parent PCI bridge 
Memory window: 0x120000000 - 0x123ffffff

And this is on second insert:

[    8.680195] yenta_cardbus 0000:03:01.0: CardBus bridge found [1028:01f9]
[    8.680227] yenta_cardbus 0000:03:01.0: Preassigned resource 2 busy 
or not available, reconfiguring...
[    8.680235] yenta_cardbus 0000:03:01.0: Preassigned resource 3 busy 
or not available, reconfiguring...
[    8.680237] yenta_cardbus 0000:03:01.0: CardBus bridge, secondary bus 
0000:04
[    8.680239] yenta_cardbus 0000:03:01.0:   IO window: 0x002000-0x0020ff
[    8.680244] yenta_cardbus 0000:03:01.0:   IO window: 0x002400-0x0024ff
[    8.680249] yenta_cardbus 0000:03:01.0:   PREFETCH window: 
0xf0000000-0xf03fffff
[    8.680254] yenta_cardbus 0000:03:01.0:   MEM window: 
0xf0400000-0xf07fffff
[    8.680263] yenta_cardbus 0000:03:01.0: O2: res at 0x94/0xD4: 00/ea
[    8.680264] yenta_cardbus 0000:03:01.0: O2: enabling read 
prefetch/write burst
[    8.813294] yenta_cardbus 0000:03:01.0: ISA IRQ mask 0x0cb8, PCI irq 19
[    8.813297] yenta_cardbus 0000:03:01.0: Socket status: 30000006
[    8.813337] yenta_cardbus 0000:03:01.0: pcmcia: parent PCI bridge I/O 
window: 0x2000 - 0x2fff
[    8.813339] yenta_cardbus 0000:03:01.0: pcmcia: parent PCI bridge 
Memory window: 0xf1d00000 - 0xf1dfffff
[    8.813341] yenta_cardbus 0000:03:01.0: pcmcia: parent PCI bridge 
Memory window: 0x120000000 - 0x123ffffff

In source, this message about subordinate buses comes from 
yenta_fixup_parent_bridge, and it is called from devinit method 
yenta_probe.

So, as i see it, yenta_fixup_parent_bridge fixes problem with buses, but 
it is called way down after driver initialization, and effectively, 
driver is not aware of changed resources (pci inspecting is done BEFORE 
call to fixup), so - it does not work! Should not fixup be called way 
before, or should not initialization be restarted after something changed??

Attached are two dmesg-s:
- dmesg.2.6.28-14-generic - clean boot
- dmesg.2.6.28-14-generic.2 - at boot, yenta_socked is removed and then 
reinserted
and two /proc/iomem:
- proc.iomem - iomem after clean boot
- proc.iomem.2 - after second boot, where yenta_socket is reinserted
and, finaly two, lspci -vv:
- lspci - clean boot
- lspci - boot with reinserted yenta_socket

Hope this will help ... :-)

H.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: dmesg.2.6.28-14-generic
URL: <http://lists.infradead.org/pipermail/linux-pcmcia/attachments/20090811/d97c8dc1/attachment-0003.el>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dmesg.2.6.28-14-generic.2
Type: application/x-troff-man
Size: 51149 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-pcmcia/attachments/20090811/d97c8dc1/attachment-0003.2>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: lspci
URL: <http://lists.infradead.org/pipermail/linux-pcmcia/attachments/20090811/d97c8dc1/attachment-0004.el>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lspci.2
Type: application/x-troff-man
Size: 25626 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-pcmcia/attachments/20090811/d97c8dc1/attachment-0004.2>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: proc.iomem
URL: <http://lists.infradead.org/pipermail/linux-pcmcia/attachments/20090811/d97c8dc1/attachment-0005.el>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: proc.iomem.2
Type: application/x-troff-man
Size: 2342 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-pcmcia/attachments/20090811/d97c8dc1/attachment-0005.2>