linux-kernel - Problems with pcmcia driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <4A817FFB.5080307@zg.t-com.hr>
Date:	Tue, 11 Aug 2009 16:28:11 +0200
From:	Hrvoje Habjanic <hrvoje.habjanic@...t-com.hr>
To:	linux-pcmcia@...ts.infradead.org
CC:	linux-kernel@...r.kernel.org
Subject: Problems with pcmcia driver


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.


View attachment "dmesg.2.6.28-14-generic" of type "text/plain" (50069 bytes)

Download attachment "dmesg.2.6.28-14-generic.2" of type "application/x-troff-man" (51149 bytes)

View attachment "lspci" of type "text/plain" (25626 bytes)

Download attachment "lspci.2" of type "application/x-troff-man" (25626 bytes)

View attachment "proc.iomem" of type "text/plain" (2348 bytes)

Download attachment "proc.iomem.2" of type "application/x-troff-man" (2343 bytes)