Hi!
In my old laptop I had a PCMCIA Creative SoundBlaster Audigy2 ZS
notebook card in order to get my external speakers working. When I
bought a new laptop, I found out that my old PCMCIA card did not fit
in any hole any more... damn! So, I decided to buy a PCMCIA to
ExpressCard adapter. Specifically, I bought DuelAdapter, but I don't
seem to be able to get it working. It does work properly in the Vista
installation my laptop has since I bought it, so a hardware problem is
out of question. I have been doing quite a lot of googleing, but I am
puzzled and don't know what the issue might be. Here a couple of
things which I think could be related.
lspci reports:
""
...
05:00.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200(A) PCI
Express-to-PCI Bridge (rev 03)
06:00.0 CardBus bridge: Texas Instruments PCIxx12 Cardbus Controller
""
(no sound card!)
Note that the adapter has a switch, which is intended to be in
"position A" for MacOS, and in "position B" for Windows XP (although
my Vista system recognised it perfectly in position A). Under linux,
lspci reports the above devices with the switch in A position, and in
B the devices do not show up.
When googling, I read that the "pci=assign-busses" kernel option could
be the solution, but that didn't help either, and in fact specifying
such option results in the devices above not being listed by lspci.
Here more lspci info:
""
$ lspci -v | grep subordinate
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
Bus: primary=00, secondary=04, subordinate=09, sec-latency=0
Bus: primary=00, secondary=0a, subordinate=0a, sec-latency=32
Bus: primary=00, secondary=00, subordinate=00, sec-latency=0
""
In addition, yenta seems not to be very happy with the setup:
""
$ dmesg | grep yenta
[ 21.098659] yenta_cardbus 0000:05:00.0: No cardbus resource!
""
And I have been unable to find anybody reporting such error in
google... only pages where this error is listed along with the kernel
code, and a couple of pages which do not seem to be related.
I also tried installing the sound card modules by hand via
/etc/modules and rebooting, but that doesn't help either, although the
modules get loaded correctly:
""
$ lsmod | grep yenta
yenta_socket 22901 0
rsrc_nonstatic 9830 1 yenta_socket
pcmcia_core 38176 2 yenta_socket,rsrc_nonstatic
$ lsmod | grep emu10k
snd_emu10k1_synth 6036 0
snd_emux_synth 37367 1 snd_emu10k1_synth
snd_emu10k1 148561 1 snd_emu10k1_synth
snd_ac97_codec 125394 1 snd_emu10k1
snd_pcm 87882 5
snd_emu10k1,snd_hda_intel,snd_hda_codec,snd_ac97_codec,snd_pcm_oss
snd_rawmidi 23420 3 snd_seq_virmidi,snd_emu10k1,snd_seq_midi
snd_util_mem 3818 2 snd_emux_synth,snd_emu10k1
snd_hwdep 6924 3 snd_emux_synth,snd_emu10k1,snd_hda_codec
snd_timer 23649 3 snd_emu10k1,snd_pcm,snd_seq
snd_seq_device 6888 8
snd_emu10k1_synth,snd_emux_synth,snd_emu10k1,snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_rawmidi,snd_seq
snd 71187 20
snd_emux_synth,snd_seq_virmidi,snd_hda_codec_idt,snd_emu10k1,snd_hda_intel,snd_hda_codec,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_seq_oss,snd_pcm,snd_rawmidi,snd_seq,snd_hwdep,snd_timer,snd_seq_device
snd_page_alloc 8500 3 snd_emu10k1,snd_hda_intel,snd_pcm
""
I would have thought that, simply, the adapter is not supported, but
then I also came accross
the following site:
http://fr.audiofanzine.com/carte-son-pcmcia/e-mu/1616M/forums/t.280979,emu-1616m-adaptateur-pcmcia-expresscard-linux.html
Although in french, the author reports that he got a similar sound
card working a PCMCIA-ExpressCard adapter wich reports the same chip
in lspci (the Texas Instruments XIO2000(A)/XIO2200(A) PCI
Express-to-PCI Bridge).
I am running Ubuntu 10.10 with a 2.6.35-28-generic kernel, on a x86_64
machine (an HP dv3000 series laptop).
Any ideas or hints towards where to get any help? ANY help at all is
appreciated, since I have run out of resources towards solving this
problem!! And if you need any further info, please do ask me!
Thanks!!
P.S.: I already posted this problem on the ubuntu forums in
http://ubuntuforums.org/showthread.php?t=1587221
but got no answer, which is why I am finally posting this here. Please
excuse me in the case this is not a kernel-related issue, and, since I
am not subscribed to the kernel-mailing list, please CC me in case of
an answer.
Hey,
On Mon, Apr 25, 2011 at 02:36:15PM +0200, Germ?n Sanchis wrote:
> In my old laptop I had a PCMCIA Creative SoundBlaster Audigy2 ZS
> notebook card in order to get my external speakers working. When I
> bought a new laptop, I found out that my old PCMCIA card did not fit
> in any hole any more... damn! So, I decided to buy a PCMCIA to
> ExpressCard adapter. Specifically, I bought DuelAdapter, but I don't
> seem to be able to get it working. It does work properly in the Vista
> installation my laptop has since I bought it, so a hardware problem is
> out of question. I have been doing quite a lot of googleing, but I am
> puzzled and don't know what the issue might be. Here a couple of
> things which I think could be related.
First of all, does passing "override_bios=1" as a module parameter
to the yenta_socket module help?
> lspci reports:
> ""
> ...
> 05:00.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200(A) PCI
> Express-to-PCI Bridge (rev 03)
> 06:00.0 CardBus bridge: Texas Instruments PCIxx12 Cardbus Controller
> ""
>
> (no sound card!)
What does "lspci -vvv" report?
> Note that the adapter has a switch, which is intended to be in
> "position A" for MacOS, and in "position B" for Windows XP (although
> my Vista system recognised it perfectly in position A). Under linux,
> lspci reports the above devices with the switch in A position, and in
> B the devices do not show up.
Could you send us a full "dmesg" with the switch in the A and one with the
switch in the B position, preferrably with ddebug_query="module yenta_socket +p"
added as boot parameter?
> In addition, yenta seems not to be very happy with the setup:
>
> ""
> $ dmesg | grep yenta
> [ 21.098659] yenta_cardbus 0000:05:00.0: No cardbus resource!
> ""
Was this with or without the "pci=assign-busses" parameter?
Best,
Dominik
Hi again.
First of all, thanks for your help.
Then, one small note: in my first message, the lspci info might have
been slightly incorrect: when I first posted this error in the ubuntu
forums, lspci reported the devices as:
...
04:00.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200(A) PCI
Express-to-PCI Bridge (rev 03)
05:00.0 CardBus bridge: Texas Instruments PCIxx12 Cardbus Controller
whereas this morning it was reporting them at 05:00.0 and 06:00.0. I
changed that part of the post, but didn't think about changing the
rest. Right now, and with the assign_busses and override_bios options,
lspci is reporting them on 04:00.0 and 05:00.0. Just in case you
notice a small inconsistency in that sense.
I tried the "override_bios=1" parameter when loading yenta_socket, but
that does not seem to help. I did this by:
$ echo "options yenta_socket override_bios=1" >
/etc/modprobe.d/yenta_socket.conf
and rebooted. Just to let you know what was done, since it is the
first time I do this and googled for it, so I want to make sure that I
am not reporting to have tried something which I might have done
incorrectly.
I am attaching three files to this email:
- A.log is the dmesg output when the switch is in position A
- B.log is the dmesg output when the switch is in position B
- lspci.log is the output of lspci -vvv with the switch in position A.
When the switch is in position B, lspci does not report the devices 04
and 05 above.
All the files were collected with 'ddebug_query="module yenta_socket
+p" pci=assign-busses' kernel options, and with yenta_socket
override_bios option.
Thanks again for your help,
best regards,
Germ?n Sanchis Trilles
Hey,
thanks for the additional debug information. It seems to me to be not a
bug with the yenta driver, but with the parent PCI bridge instead.
Therefore, I've added Jesse and the linux-pci list as recipients. Germ?n's
problem relates to Ubuntu's 2.6.35-derived kernel; lspci snippets follow.
Let's look at the (grand-)parent bridge: It offers some, if not much I/O and
memory resources for its childs to be used:
00:1c.5 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 6 (rev 03) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Bus: primary=00, secondary=04, subordinate=09, sec-latency=0
I/O behind bridge: 00001000-00001fff
Memory behind bridge: d6100000-d70fffff
Prefetchable memory behind bridge: 00000000d5100000-00000000d60fffff
The PCI bridge, however, does only pass the I/O resources downstream, but
_no_ memory at all.
04:00.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200(A) PCI Express-to-PCI Bridge (rev 03) (prog-if 00 [Normal decode])
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Bus: primary=04, secondary=05, subordinate=09, sec-latency=0
I/O behind bridge: 00001000-00001fff
Memory behind bridge: fff00000-000fffff
The CardBus bridge then has I/O resources to use, but cannot enable memory
resources:
05:00.0 CardBus bridge: Texas Instruments PCIxx12 Cardbus Controller
Memory window 0: 00000000-00000000 [disabled] (prefetchable)
Memory window 1: 00000000-00000000 [disabled] (prefetchable)
I/O window 0: 00001000-000010ff
I/O window 1: 00001400-000014ff
So my question to the PCI folks: why does the PCI bridge fail to pass memory
regions downstream, and assign them properly to the CardBus bridge?
@Germ?n: assign_busses won't be needed, AFAICT, and possibly override_bios
neither (if we get the PCI bridge to work, that is...) -- it gets into
action much later during yenta_cardbus initialization.
Best,
Dominik
On Mon, Apr 25, 2011 at 07:13:12PM +0200, Germ?n Sanchis wrote:
> Hi again.
>
> First of all, thanks for your help.
>
> Then, one small note: in my first message, the lspci info might have
> been slightly incorrect: when I first posted this error in the ubuntu
> forums, lspci reported the devices as:
> ...
> 04:00.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200(A) PCI
> Express-to-PCI Bridge (rev 03)
> 05:00.0 CardBus bridge: Texas Instruments PCIxx12 Cardbus Controller
>
> whereas this morning it was reporting them at 05:00.0 and 06:00.0. I
> changed that part of the post, but didn't think about changing the
> rest. Right now, and with the assign_busses and override_bios options,
> lspci is reporting them on 04:00.0 and 05:00.0. Just in case you
> notice a small inconsistency in that sense.
>
> I tried the "override_bios=1" parameter when loading yenta_socket, but
> that does not seem to help. I did this by:
>
> $ echo "options yenta_socket override_bios=1" >
> /etc/modprobe.d/yenta_socket.conf
>
> and rebooted. Just to let you know what was done, since it is the
> first time I do this and googled for it, so I want to make sure that I
> am not reporting to have tried something which I might have done
> incorrectly.
>
> I am attaching three files to this email:
>
> - A.log is the dmesg output when the switch is in position A
> - B.log is the dmesg output when the switch is in position B
> - lspci.log is the output of lspci -vvv with the switch in position A.
> When the switch is in position B, lspci does not report the devices 04
> and 05 above.
>
> All the files were collected with 'ddebug_query="module yenta_socket
> +p" pci=assign-busses' kernel options, and with yenta_socket
> override_bios option.
>
> Thanks again for your help,
>
> best regards,
>
> Germ?n Sanchis Trilles
Hi again.
Thanks for forwarding the message to the appropriate list. If there is
any other information you guys would need, or anything else I can do
to help, do let me know and I'll collect it as soon as possible.
Thanks again,
Germ?n Sanchis Trilles
2011/4/25 Dominik Brodowski <[email protected]>:
> Hey,
>
> thanks for the additional debug information. It seems to me to be not a
> bug with the yenta driver, but with the parent PCI bridge instead.
> Therefore, I've added Jesse and the linux-pci list as recipients. Germ?n's
> problem relates to Ubuntu's 2.6.35-derived kernel; lspci snippets follow.
>
> Let's look at the (grand-)parent bridge: It offers some, if not much I/O and
> memory resources for its childs to be used:
>
> 00:1c.5 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 6 (rev 03) (prog-if 00 [Normal decode])
> ? ? ? ?Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
> ? ? ? ?Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> ? ? ? ?Latency: 0
> ? ? ? ?Bus: primary=00, secondary=04, subordinate=09, sec-latency=0
> ? ? ? ?I/O behind bridge: 00001000-00001fff
> ? ? ? ?Memory behind bridge: d6100000-d70fffff
> ? ? ? ?Prefetchable memory behind bridge: 00000000d5100000-00000000d60fffff
>
> The PCI bridge, however, does only pass the I/O resources downstream, but
> _no_ memory at all.
>
> 04:00.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200(A) PCI Express-to-PCI Bridge (rev 03) (prog-if 00 [Normal decode])
> ? ? ? ?Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
> ? ? ? ?Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> ? ? ? ?Latency: 0
> ? ? ? ?Bus: primary=04, secondary=05, subordinate=09, sec-latency=0
> ? ? ? ?I/O behind bridge: 00001000-00001fff
> ? ? ? ?Memory behind bridge: fff00000-000fffff
>
> The CardBus bridge then has I/O resources to use, but cannot enable memory
> resources:
>
> 05:00.0 CardBus bridge: Texas Instruments PCIxx12 Cardbus Controller
> ? ? ? ?Memory window 0: 00000000-00000000 [disabled] (prefetchable)
> ? ? ? ?Memory window 1: 00000000-00000000 [disabled] (prefetchable)
> ? ? ? ?I/O window 0: 00001000-000010ff
> ? ? ? ?I/O window 1: 00001400-000014ff
>
> So my question to the PCI folks: why does the PCI bridge fail to pass memory
> regions downstream, and assign them properly to the CardBus bridge?
>
> @Germ?n: assign_busses won't be needed, AFAICT, and possibly override_bios
> neither (if we get the PCI bridge to work, that is...) -- it gets into
> action much later during yenta_cardbus initialization.
>
> Best,
> ? ? ? ?Dominik
>
>
> On Mon, Apr 25, 2011 at 07:13:12PM +0200, Germ?n Sanchis wrote:
>> Hi again.
>>
>> First of all, thanks for your help.
>>
>> Then, one small note: in my first message, the lspci info might have
>> been slightly incorrect: when I first posted this error in the ubuntu
>> forums, lspci reported the devices as:
>> ...
>> 04:00.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200(A) PCI
>> Express-to-PCI Bridge (rev 03)
>> 05:00.0 CardBus bridge: Texas Instruments PCIxx12 Cardbus Controller
>>
>> whereas this morning it was reporting them at 05:00.0 and 06:00.0. I
>> changed that part of the post, but didn't think about changing the
>> rest. Right now, and with the assign_busses and override_bios options,
>> lspci is reporting them on 04:00.0 and 05:00.0. Just in case you
>> notice a small inconsistency in that sense.
>>
>> I tried the "override_bios=1" parameter when loading yenta_socket, but
>> that does not seem to help. I did this by:
>>
>> $ echo "options yenta_socket override_bios=1" >
>> /etc/modprobe.d/yenta_socket.conf
>>
>> and rebooted. Just to let you know what was done, since it is the
>> first time I do this and googled for it, so I want to make sure that I
>> am not reporting to have tried something which I might have done
>> incorrectly.
>>
>> I am attaching three files to this email:
>>
>> - A.log is the dmesg output when the switch is in position A
>> - B.log is the dmesg output when the switch is in position B
>> - lspci.log is the output of lspci -vvv with the switch in position A.
>> When the switch is in position B, lspci does not report the devices 04
>> and 05 above.
>>
>> All the files were collected with ?'ddebug_query="module yenta_socket
>> +p" pci=assign-busses' kernel options, and with yenta_socket
>> override_bios option.
>>
>> Thanks again for your help,
>>
>> best regards,
>>
>> Germ?n Sanchis Trilles
>
On Wed, Apr 27, 2011 at 4:33 AM, Germ?n Sanchis <[email protected]> wrote:
> 2011/4/25 Dominik Brodowski <[email protected]>:
>> Hey,
>>
>> thanks for the additional debug information. It seems to me to be not a
>> bug with the yenta driver, but with the parent PCI bridge instead.
>> Therefore, I've added Jesse and the linux-pci list as recipients. Germ?n's
>> problem relates to Ubuntu's 2.6.35-derived kernel; lspci snippets follow.
>>
>> Let's look at the (grand-)parent bridge: It offers some, if not much I/O and
>> memory resources for its childs to be used:
>>
>> 00:1c.5 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 6 (rev 03) (prog-if 00 [Normal decode])
>> ? ? ? ?Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
>> ? ? ? ?Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>> ? ? ? ?Latency: 0
>> ? ? ? ?Bus: primary=00, secondary=04, subordinate=09, sec-latency=0
>> ? ? ? ?I/O behind bridge: 00001000-00001fff
>> ? ? ? ?Memory behind bridge: d6100000-d70fffff
>> ? ? ? ?Prefetchable memory behind bridge: 00000000d5100000-00000000d60fffff
>>
>> The PCI bridge, however, does only pass the I/O resources downstream, but
>> _no_ memory at all.
>>
>> 04:00.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200(A) PCI Express-to-PCI Bridge (rev 03) (prog-if 00 [Normal decode])
>> ? ? ? ?Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>> ? ? ? ?Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>> ? ? ? ?Latency: 0
>> ? ? ? ?Bus: primary=04, secondary=05, subordinate=09, sec-latency=0
>> ? ? ? ?I/O behind bridge: 00001000-00001fff
>> ? ? ? ?Memory behind bridge: fff00000-000fffff
>>
>> The CardBus bridge then has I/O resources to use, but cannot enable memory
>> resources:
>>
>> 05:00.0 CardBus bridge: Texas Instruments PCIxx12 Cardbus Controller
>> ? ? ? ?Memory window 0: 00000000-00000000 [disabled] (prefetchable)
>> ? ? ? ?Memory window 1: 00000000-00000000 [disabled] (prefetchable)
>> ? ? ? ?I/O window 0: 00001000-000010ff
>> ? ? ? ?I/O window 1: 00001400-000014ff
>>
>> So my question to the PCI folks: why does the PCI bridge fail to pass memory
>> regions downstream, and assign them properly to the CardBus bridge?
The BIOS assigned [mem 0xd6100000-0xd70fffff] (16MB) and [mem
0xd5100000-0xd60fffff 64bit pref] (16MB) to bus 04, but left the
04:00.0 bridge windows to bus 05 disabled. Linux only enables them if
we find a downstream device that needs resources. In this case, there
*is* a downstream CardBus bridge (05:00.0) that would like resources.
By default, pci_bus_size_cardbus() requests 64MB for each CardBus
memory window, but there's only 16MB each (prefetchable and
non-prefetchable) available.
I don't think your audio card needs anywhere near 64MB of memory
space. Can you try booting with "pci=cbmemsize=8M"?
Bjorn
Hi!
Well, that did work, so the sound card is being recognized now, and in
fact I already managed to do a couple of successful sound tests.
I am attaching the output of lspci -vvv after specifying
pci=cbmemsize=8M, in case it helps you further... I am happy with my
card working, but I don't know if this should be considered in future
releases of the kernel.
Thank you very much,
best regards,
Germ?n Sanchis Trilles
On Wed, Apr 27, 2011 at 4:07 PM, Germ?n Sanchis <[email protected]> wrote:
> Hi!
> Well, that did work, so the sound card is being recognized now, and in fact
> I already managed to do a couple of successful sound tests.
> I am attaching the output of lspci -vvv after specifying pci=cbmemsize=8M,
> in case it helps you further... I am happy with my card working, but I don't
> know if this should be considered in future releases of the kernel.
Good, I'm glad the workaround works.
It sure seems like the kernel could be smarter about this. After all,
we can (at least in principle) find out what devices are behind the
CardBus bridge and how much space they need. Unfortunately, we don't
really have good support for dynamically rearranging things, so we
tend to request more space than we need in case the user later plugs
in another device. It's a known problem and people are thinking about
it, but I'm afraid a complete solution is still a ways off.
Bjorn