Distribution: gentoo Hardware Environment: Compaq NC6000 laptop. (but fails on all laptops.) Software Environment: Linux Problem Description: Cardbus ioports fails. inb(), inw() and ind() cause an entire system hang and pci bus error. Steps to reproduce: use the attached ca0106_main.c file and replace ./linux/sound/pci/ca0106/ca0106_main.c Compile the ALSA sound modules and include the ca0106 module in debug mode. Installing alsa-driver separately might be required. configure --with-cards=ca0106 --with-debug=basic make make install modprobe snd-ca0106 cat /proc/asound/cards cat /proc/asound/card0/ca0106_regs32 (ca0106_regs32 will only appear in debug mode) This causes the system to hang. If one removed the cardbus card, the system continues on again. I am attaching two files. Each of these files can be read with "lspci -Ffilename" so one can use lspci to dump any information that might be useful. One of the files linux.txt is using lspci in Linux, the win32.txt is the equivalent in windows, where the cardbus card functions. There must be something wrong with the way ioport resources are being assigned in the PCI config registers. Can anybody help?
Created attachment 5625 [details] lspci output using "lspci -m -xxx" under linux kernel 2.6.13-rc5
Created attachment 5626 [details] lspci output in "lspci -m -xxx" format under Windows 2000
Created attachment 5627 [details] Version of ca0106_main.c for test purposes. It should produce a file /proc/asound/card0/ca0106_reg32. "cat"ing this file will hang the pc. But doing the same with a PCI card version of the same sound card work. Only the Cardbus card version fails this command.
Created attachment 5628 [details] output from "cat /proc/ioports"
Created attachment 5667 [details] Example diff Try to set up yenta controller more like W2000
Under Linux, the secondary timer for the cardbus bridge is set to 176 cycles, under Windows its zero (disabled). Under Linux, we also have the bridge reporting: Secondary status: SERR and bridge-control has write posting enabled. I'm attaching a stupid patch that may or may not make Linux work more like Windows in this respect. That SERR makes me worry.
Created attachment 5674 [details] lspci output using "lspci -m -xxx" under linux kernel 2.6.13-rc5 This is the output of "lspci -m -xxx" after applying the patch to yenta-socket.c The inw() etc. still fail just as before.
I noticed something... Every cardbus bridge appears to be attached to 0000:00:1e.0. Linux: 0000:00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 83) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR+ Latency: 0 Bus: primary=00, secondary=02, subordinate=0e, sec-latency=32 I/O behind bridge: 00004000-00009fff Memory behind bridge: 90000000-902fffff Prefetchable memory behind bridge: 40000000-46ffffff BridgeCtl: Parity- SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B- Windows: 0000:00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 83) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR+ Latency: 0 Bus: primary=00, secondary=02, subordinate=05, sec-latency=32 Memory behind bridge: 90000000-902fffff BridgeCtl: Parity- SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B- It looks like this bridge is psuedo-transparent. It's catched by a quirk in arch/i386/pci/fixup.c, but for some reason we still assigned resources to it. I'm not sure if this would have any negative effect. Also it's interesting that, in windows, all cardbus bridges' Mem windows are allocated outside of the memory range 90000000-902fffff but all non-bridge devices are bound to that range. It's almost as if bridge devices pass through, but other devices must be allocated within a window. Thanks, Adam
Created attachment 5675 [details] pci-transparent-hack.patch This is a quick hack to prevent the PCI subsystem from writting to bridge windows in transparent bridges. Resources are still assigned the usual way. Hopefully the quirk is detected before this point.
Does the above patch solve your problem? Also, could I see the new lspci output. Thanks, Adam
On Thu, 18 Aug 2005 bugme-daemon@kernel-bugs.osdl.org wrote: > > The inw() etc. still fail just as before. Ok, SERR is still set - I wonder if the problem is this one: 07:00.0 Multimedia audio controller: Creative Labs: Unknown device 0008 Subsystem: Creative Labs: Unknown device 2001 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Note how it is marked as "Mem-", because the kernel has determined that it has no IOMEM resources. But under Win2000, it's "Mem+". Now, exactly because it has no IOMEM resources, it shouldn't _matter_. But hey, maybe the card is buggy. I assume that PCMCIA is otherwise functioning on this machine, and it's really only this particular card that causes this problem? If so, you could try doing pci_write_config_word(dev, PCI_COMMAND, 7); in the driver, and see if that makes any difference.. Linus
On Thu, 18 Aug 2005 bugme-daemon@kernel-bugs.osdl.org wrote: > > Also it's interesting that, in windows, all cardbus bridges' Mem windows are > allocated outside of the memory range 90000000-902fffff but all non-bridge > devices are bound to that range. It's almost as if bridge devices pass through, > but other devices must be allocated within a window. Pretty much all Intel bridges seem to be of this semi-transparent kind, where they actually pass through a lot more than they claim to do. It's very confusing, and we've never had any official word from Intel, but it seems to work for everything else, so this is "normal". Linus
Created attachment 5694 [details] Result of lspci -m -xxx after the "transparent" patch from Adam After applying the patch, there card still fails the inw(). This is the lspci -m -xxx output after applying the patch.
Created attachment 5695 [details] Result of lspci -m -xxx after the "pci-command 7" from Linus Result of lspci -m -xxx after the "pci-command 7" from Linus After applying the patch, there card still fails the inw(). This is the lspci -m -xxx output after applying the patch.
As a follow up to the "Secondary status: SERR". How can we clear that signal?
On Sat, 20 Aug 2005 bugme-daemon@kernel-bugs.osdl.org wrote: > > As a follow up to the "Secondary status: SERR". How can we clear that signal? Afaik, it's one of the "write to clear" bits, and you write back the bits you want to clear. If your computer explodes, I was wrong. Linus
Notice below the value differences at offset 0x82 and 0xfe, 0xff. Does anyone know what those registers do? Could changing them help us fix this? --- win32.txt 2005-08-13 15:39:15.000000000 +0100 +++ after-pci-command-7.txt 2005-08-20 11:38:13.000000000 +0100 00:1e.0 "PCI bridge" "Intel Corporation" "82801 Mobile PCI Bridge" -r83 "" "" 00: 86 80 48 24 07 01 80 80 83 00 04 06 00 00 01 00 -10: 00 00 00 00 00 00 00 00 00 02 05 20 f0 00 80 22 +10: 00 00 00 00 00 00 00 00 00 02 0e 20 f0 00 80 22 20: 00 90 20 90 f0 ff 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 00 40: 02 28 20 00 00 00 00 00 00 00 00 00 00 00 00 00 50: 02 60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -80: 00 00 87 00 00 00 00 00 00 00 00 00 00 00 00 00 +80: 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0: 10 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 01 00 02 00 00 00 c0 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -f0: 00 00 00 00 00 00 00 00 60 0f 00 00 00 00 32 44 +f0: 00 00 00 00 00 00 00 00 60 0f 00 00 00 00 34 42
Could you try 2.6.13-mm3, please?
Retried with kernel 2.6.13-mm3 No change. It still hangs the machine at the inw() instruction.
Is this bug related to the bug with the Sound Blaster Audigy 2 ZS Notebook card mentionned on alsa compatibility list ? : http://www.alsa-project.org/alsa-doc/index.php?vendor=vendor-Creative_Labs#matrix I just bought this card (knowing the bug) and I confirm insmod yenta_socket hangs the kernel. If can do something useful to debug, just tell me.
It is the same problem. In case you don't know. I am an ALSA developer trying to write a driver for this card. But I think the problem is due to PCI or PCMCIA cardbus issues in the kernel. I am no expert on PCMCIA cardbus as I don't have access to any standards documents about it. (due to lack of funds to purchase them). So, I raised this bug report in the hopes that someone else will have the necessary PCMCIA cardbus knowledge to fix this problem. But no luck yet.
Correct me if I'm wrong, but it seems that "lspci output using "lspci -m -xxx" under linux kernel 2.6.13-rc5" doesn't show the "PostWrite" bit as being set as the patch intends. Also do any other cardbus (or even pcmcia) cards work correctly on this system? -Adam
I am fairly sure I installed the "transparent" patch correctly, so is there any possibility that the your patch did not actually perform the desired task? I used exactly the same procedure to try "pci-command 7" and that did actually change the correct pci bytes. Which byte contains the "PostWrite" bit and what should it now be set to, so that I can see if it changes or not? All the pcmcia cards I have work. I don't have any other cardbus cards, so I cannot determine if others work or not. Maybe, if you could create a new patch for kernel 2.6.13 (which I am currently running), and at the same time tell me which config bytes the patch should be changing, I could help provide better feedback.
I'm sorry for not being clearer. My patch worked as intended and I was referring to an earlier patch. "PostWrites" was actually intended to be disabled in this patch. I was confused because it was enabled in Windows. You can change PCI registers from userspace. The best time would be after yenta_socket is loaded but before the cardbus card is inserted. The two major differences I noticed between windows and linux are as follows: #setpci 02:06.1 0d.b=40 /* latency timer */ #setpci 02:06.1 1b.b=00 /* secondary latency timer */ But I'm not sure if this will make any difference. When is SERR set? When the card is inserted? After the card's IO is touched? -Adam
SERR is not set on card insertion, SERR is set after IO touched.
Any news? I've got one of these cards and I'm willing to help.
I am also interested in resolving this. We'd really like to have hardware mixing capabilities on our laptops and this is about the only option I've been able to find. Please let me know how I can help! -Jay
Using 2.6.14-rc5 results in same hang. Something interesting is when booting with 2.6.14-rc5-mm1 the I/O windows are not the same. Is this behaviour expected? I/O window 0: 00002400-000024ff I/O window 1: 00002800-000028ff --- I/O window 0: 00003000-00003fff I/O window 1: 00004000-00004fff Further, when issuing a "pccardctl insert" the first time with the mm kernel it results in the following message: cs: pcmcia_socket0: unsupported voltage key. Upon subsequent boots of the same kernel a "pccardctl insert" hangs the system as previously mentioned. FWIW, - Todd.
Bah! Just noticed I didn't label the lspci output. It should be: 2.6.14-rc5-mm1 -------------- I/O window 0: 00002400-000024ff I/O window 1: 00002800-000028ff 2.6.14-rc5 (vanilla) -------------------- I/O window 0: 00003000-00003fff I/O window 1: 00004000-00004fff
These settings seem to match more how windows does things: I/O window 0: 00002400-000024ff I/O window 1: 00002800-000028ff But even more interesting, is the message: cs: pcmcia_socket0: unsupported voltage key. I have no idea what this actually means, could any pcmcia expert help?
Can somebody say what this card is called in a retail box? I'll just run down to Fry's and see for myself. It seems to be impossible to debug this remotely, and hey, the worst that can happen is that I waste some money on a cardbus card that I don't need. Linus
The Card itself has written on it: Creative Sound Blaster Audigy 2 ZS Notebook. http://www.creative.com/products/product.asp?category=1&subcategory=204&product=10769&nav=artwork
Just to be sure, it is Model No. SB0530. I am located in Canada so I'll be presumptuos (sp?) and say that is the North American model number. - Todd.
Yes, it is Model SB0530. I am in the UK. The Serial number of the device also contains the model number: E.g. M1SB0530504000000P
On Thu, 27 Oct 2005, bugme-daemon@kernel-bugs.osdl.org wrote: > > Yes, it is Model SB0530. I am in the UK. Ok, I've got an SB0530, and sure enough, I can re-create the hang easily. That said, I can't see why it hangs. I'm trying to debug it, but from what I see so far, it looks rather like it's the card itself, not the pcmcia layer. I wonder if there is some magic initialization sequence for that card that we simply don't know about and don't do, so that it doesn't reset correctly under Linux. I'll try different things, but so far all the traces for setting up on the cardbus side have looked perfectly straightforward and correct. Btw, the ca0106 driver seems to reserve and use only the first 32 bytes, but the hardware itself says that it decodes 64 bytes. FWIW. Linus
Created attachment 6401 [details] Experimental patch to show CB/ExCA registers Added patch that adds a "yenta_registers" file to sysfs for any yenta device that we've attached to. You can just "cat" it as root to see what the CB and ExCA register state is at that point.
On Thu, 27 Oct 2005, bugzilla-daemon@osdl.org wrote: > > I'll try different things, but so far all the traces for setting up on the > cardbus side have looked perfectly straightforward and correct. Ok, I just added a pretty rough patch that adds a "yenta_registers" attribute to each PCI device that the yenta driver attaches to (Greg may shudder at what I do), which will show the yenta register state at any time. Now, the problem is that I'd really like some way to compare against the same yenta register state when the card has been inserted under Windows, but quite frankly, not only don't I have windows on any computers I have access to (surprise surprise), but even if I had, I wouldn't know how to get the cardbus registers out of it. Maybe somebody else does? Maybe there's some nice windows hardware debug tool? Regardless, the trivial patch I just added as an attachement to this bugzilla report should do it on Linux. On my laptop, I can just do [torvalds@evo ~]$ find /sys -name yenta_registers /sys/devices/pci0000:00/0000:00:1e.0/0000:02:06.1/yenta_registers /sys/devices/pci0000:00/0000:00:1e.0/0000:02:06.0/yenta_registers and then as root: [root@evo torvalds]# cat /sys/devices/pci0000:00/0000:00:1e.0/0000:02:06.0/yenta_registers CB registers: 00: 00000000 00000006 30000828 00000000 10: 00000433 00000433 00000000 00000000 20: 00000000 00000018 02000600 00000000 30: 00000000 00000000 00000000 00000000 ExCA registers: 00: 84 7d 19 40 00 08 00 00 08: 00 00 01 00 00 00 01 00 10: 00 00 00 00 00 00 00 00 18: 00 00 00 00 00 00 00 00 which is not all of the registers, but it's sure better than nothing. There weren't any differences in the PCI config registers (apart from the trivial kind where Linux and Windows just mapped the IO windows at different addresses). Maybe this shows some smoking gun. In case it's not obvious: the "cardbus registers" (aka "CB registers") are the first 64 bytes as long-words of the PCI MMIO mapping for the cardbus bridge. The ExCA registers are byte regs offset by 0x800 in that same MMIO window (I made it print out the first 32 bytes). So even if there isn't any yenta-specialized tool under windows, just a PCI MMIO debugging tool should be able to generate this.. Anybody? The registers have a standard subset, but are otherwise somewhat chip-specific, so you really want to compare the values in the _same_ machine. Linus
Created attachment 6406 [details] win XP pci information from PCIScope I found PCIScope (http://www.drivertools.net/Products/Utilities/EngineeringUtilities/PCIScope.htm) a great tool to retrieve ton of PCI info from devices (This tools give some information on the purpose of every register / bit !) The attached file is detailed info from PCIScope including CardBus registers and ExCA registers + a lot more info on the device If necesserary I can patch the kernel to compare with values on linux
Couple of questions, I hope they're not silly. (Kernel-level stuff is beyond me) 1) Which kernel version does this patch apply against (2.6.14 vanilla, I presume?) 2) Isn't the alsa driver used for this card supposed to be emu10k1 not ca0106? Or was that just an example by demonstrating what works on a similar device? - Todd
I used the ca0106 driver just for test purposes. It simply loads a module, assigns resources to it, and creates a few useful /proc files. One can then make sure that all the correct PCI values have been set. One then does a "cat /proc/asound/card0/io_regs" to do the actual inb() that causes the hang. Once we get the inb() working, I will sort out the rest of the driver, and it will then be based on the snd-emu10k1 driver. I just used the ca0106 driver as a shell because it had less code in it.
Some comparison between linux and XP from the PCIscope dump: CB registers ============ Linux XP 00: 00000000 00000006 30000828 00000000 00000008 00000006 30000868 00000000 10: 00000433 00000433 00000000 00000000 00000433 00000000 00000000 00000000 20: 00000000 00000018 02000600 00000000 02000000 00000000 00000000 30: 00000000 00000000 00000000 00000000 dword 2 : only bit 6 differs. This bit indicate the current status of the READY(IREQ)//CINT signal at the PCCard interface. it is low on linux (0) and high on windows (1). Looks strange that dword 4 (433) is repeated in dword 5 as PCIscope indicate dwarod 5 as "reserved" From Dword 9, PCIscope indicate theses registers as unknown, yet they contains values on linux. ExCA registers ============== Linux XP 00: 84 7d 19 40 00 08 00 00 84 6E 19 50 00 00 00 00 08: 00 00 01 00 00 00 01 00 00 00 00 00 00 00 00 00 10: 00 00 00 00 00 00 00 00 FF 0F FF 0F 00 00 C0 00 18: 00 00 00 00 00 00 00 00 FF 0F FF 0F 00 00 00 00 offset 1 byte (Interface Status) show that on linux PCCard is Read only (Bit 4) but Read-Write on Windows Also Bit 0-1 indicate battery voltage with is "dead" on linux (01) while "low" on windows (10) offset 3 byte (Interrupt and general control) has bit 4 set on linux but not windows: CSC interrupt routed to PCI interrupts on linux while CSC interrupt routed to ExCA registers on windows (PCIscope indicate this last one is the default)
Okay, I have patched both vanilla & mm- kernels and have attached the results of the following tests: mm-kernel 2.6.14-rc5 - card not inserted (didn't know if it would help testing the changes) mm-kernel 2.6.14-rc5 - card inserted vanilla 2.6.14-rc5 - card inserted (forget w/o card) The diff between card in & out under mm-kernel was: 2c2 < 00: 00000000 00000006 30000821 00000000 --- > 00: 00000000 00000006 30000007 00000000 8c8 < 00: 84 3d 00 40 08 08 00 00 --- > 00: 84 33 00 40 00 08 00 00 I will try and download PCIscope under Windows and post its results soon. Regards, - Todd.
Created attachment 6408 [details] 2.6.14-rc5-mm1 w/patch card inserted.
Created attachment 6409 [details] 2.6.14-rc5-mm1 w/patch w/o card inserted
Created attachment 6410 [details] 2.16.14-rc5 vanilla w/patch w/card inserted
Created attachment 6411 [details] Windows XP dump of PCI bus (O2 controller & SB0530) Dump of the configuration space for this device & the PCMCIA controller, hopefully relevant. - Todd
> --> (http://bugzilla.kernel.org/attachment.cgi?id=6411&action=view) >Windows XP dump of PCI bus (O2 controller & SB0530) > >Dump of the configuration space for this device & the PCMCIA controller, >hopefully relevant. > >- Todd > > > Maybe you could post the CardBus and ExCA registers ? Michael
Tried PCIScope and it crashes my system everytime it enumerates the bus. Is there another utility? So far, the only one I have tried is PCI32 and it didn't have the data required. - Todd.
bugme-daemon@kernel-bugs.osdl.org a
Ah, the /SD switch did the trick. I had to set it to use the "Configuration" option instead of HAL to access the bus. Eval s/w, gotta love it. Big red flags saying all the good information will be hidden (you thief!) I practically expected it to swear at me through the soundcard. :) Here is a complete register dump of the Creative card: @81:00:00 ; Vendor: Creative Labs ; Device: Unknown 00: 02 11 08 00 00 00 90 02 - 00 00 01 04 00 00 00 00 10: 01 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 - 60 00 00 00 02 11 01 20 30: 00 00 00 00 DC 00 00 00 - 00 00 00 00 0A 01 02 14 40: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 82 00 00 50: 00 80 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 60: 13 03 43 49 53 04 06 03 - 01 00 00 00 00 05 06 41 70: 18 02 30 FF FF 07 06 11 - 00 40 00 00 00 21 02 FE 80: 00 20 04 2B 01 01 01 15 - 19 08 01 43 52 45 41 54 90: 49 56 45 00 43 41 52 44 - 42 55 53 20 41 55 44 49 A0: 4F 00 FF FF 00 00 00 00 - 00 00 00 00 00 00 00 00 B0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 C0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 D0: 00 00 00 00 00 00 00 00 - 00 00 00 00 01 00 22 06 E0: 00 1E 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 F0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 And the bridge: @00:0C:00 ; Vendor: O2 Micro Inc ; Device: OZ6912/711E0 ACPI CardBus Controller 00: 17 12 72 69 07 00 10 04 - 00 00 07 06 00 00 02 00 10: 00 F0 E7 FF A0 00 00 02 - 00 81 81 00 00 E0 E7 FF 20: 00 E0 E7 FF 00 00 C0 FA - 00 F0 BF FE 01 FD 00 00 30: FD FD 00 00 01 FC 00 00 - FD FC 00 00 0A 01 00 04 40: 09 15 60 18 01 00 00 00 - 00 00 00 00 00 00 00 00 50: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 70: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 80: 00 00 00 00 00 00 00 00 - 00 00 00 00 22 1C 82 01 90: 02 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 A0: 01 00 02 FE 00 7E C0 00 - 00 00 00 00 0F 00 00 00 B0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 C0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 D0: 00 40 00 08 EA 03 82 02 - 00 00 00 00 00 00 00 00 E0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 F0: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00 @PCI_DEVICE_REGISTERS Device: 00:0C:00 AddressSpace: Memory BAR: PWR Base: 00000000 Offset: 00000000 Length: 00000020 00: 02 00 03 00 03 00 03 00 - 02 00 03 00 03 00 03 00 10: 02 00 03 00 03 00 03 00 - 03 00 03 00 03 00 03 00 @PCI_DEVICE_REGISTERS Device: 00:0C:00 AddressSpace: Memory BAR: ExCA Base: FFE7F000 Offset: 00000000 Length: 0000002C 00: 08 00 00 00 06 00 00 00 - 28 08 00 30 00 00 00 00 10: 33 00 00 00 33 00 00 00 - 00 00 00 00 00 00 00 00 20: 00 00 00 00 18 00 00 00 - 01 06 00 0A @PCI_DEVICE_REGISTERS Device: 00:0C:00 AddressSpace: Memory BAR: ExCA Base: FFE7F000 Offset: 00000800 Length: 00000046 00: 84 7D 19 50 00 08 00 00 - 00 00 00 00 00 00 00 00 10: FF 0F FF 0F 00 00 00 00 - FF 0F FF 0F 00 00 00 00 20: FF 0F FF 0F 00 00 24 00 - FF 0F FF 0F 00 00 0D 00 30: FF 0F FF 0F 00 00 00 00 - 00 00 A0 42 18 00 2A 00 40: 00 00 00 00 00 00
On Fri, 28 Oct 2005, bugme-daemon@kernel-bugs.osdl.org wrote: > > Some comparison between linux and XP from the PCIscope dump: Thanks. > CB registers > ============ > > Linux XP > > 00: 00000000 00000006 30000828 00000000 00000008 00000006 30000868 00000000 > 10: 00000433 00000433 00000000 00000000 00000433 00000000 00000000 00000000 > 20: 00000000 00000018 02000600 00000000 02000000 00000000 00000000 > 30: 00000000 00000000 00000000 00000000 Nothing really looks wrong as far as I can tell. Yes, Linux repeats dword 5, but that's probably a fluke of the hardware (nonimplemented register, perhaps just echoing whatever the last access was). Or maybe PCIscope just doesn't even read that register at all, since it's reserved. > From Dword 9, PCIscope indicate theses registers as unknown, yet they contains > values on linux. They are indeed unknown, I just dumped out a random amount that was "enough". > ExCA registers > ============== > > Linux XP > > > 00: 84 7d 19 40 00 08 00 00 84 6E 19 50 00 00 00 00 > 08: 00 00 01 00 00 00 01 00 00 00 00 00 00 00 00 00 > 10: 00 00 00 00 00 00 00 00 FF 0F FF 0F 00 00 C0 00 > 18: 00 00 00 00 00 00 00 00 FF 0F FF 0F 00 00 00 00 > > offset 1 byte (Interface Status) show that on linux PCCard is Read only (Bit 4) > but Read-Write on Windows > > Also Bit 0-1 indicate battery voltage with is "dead" on linux (01) while "low" > on windows (10) I think both of those definitions are valid only for "memory cards", not IO cards. For IO cards, the two low bits just indicate the status of SPKR (bit 1) and STSCHG (bit 0) at the PC card interface. Another report had XP with the same 7d value as Linux, so I think this is basically just random noise. > offset 3 byte (Interrupt and general control) has bit 4 set on linux but not > windows: > CSC interrupt routed to PCI interrupts on linux while CSC interrupt routed to > ExCA registers on windows (PCIscope indicate this last one is the default) Linux tries to route the CSC interrupt over PCI, Windows obviously uses the legacy ISA irq. This shouldn't matter. And both Linux and XP has all the IO and MEM windows disabled (so the fact that XP then has those programmed to some other values in the FF.. range shouldn't matter in the least). In short, I don't see anything that looks even _remotely_ suspicious. Dang. Linus
Maybe we should contact creative or a creative developer to help on this ? Michael
After Linus suggesting that maybe this is the special startup sequence for this card, I went ahead and investigated. I have not investigated before as none of the other Creative sound cards require a startup sequence to get the IO ports responding. Here is a capture of some of the initial IO port access the Audigy Notebook does when one inserts it in windows: IO-Base: 0xfcc0 (So the first IO-Read is to offset 0x38) Read 0x00c30000 from register 0xfcf8 (offset 0x38) Write 0x00d00000 to register 0xfcf8 (offset 0x38) Read 0x00d30000 from register 0xfcf8 (offset 0x38) Write 0x00d00001 to register 0xfcf8 (offset 0x38) Read 0x00d30001 from register 0xfcf8 (offset 0x38) Write 0x00d0005f to register 0xfcf8 (offset 0x38) Read 0x00d30e5f from register 0xfcf8 (offset 0x38) Write 0x00d0007f to register 0xfcf8 (offset 0x38) Read 0x00d30e7f from register 0xfcf8 (offset 0x38) Write 0x0090007f to register 0xfcf8 (offset 0x38) Read 0x00930e7f from register 0xfcf8 (offset 0x38) Write 0x005e0000 to register 0xfcc0 (offset 0x00) Write 0x00000f00 to register 0xfcc4 (offset 0x04) I know that offset 0x00 and 0x04 do. I have no idea what offset 0x38 does. Maybe this is the special startup sequence. I have tried this, and it does in fact liven up the IO ports of the card. I have checked in some init code to the ALSA cvs, if someone wants to see it. Even with this init code, the card behaves quite differently from previous creative sound cards so I have some work to do with the driver itself. I at least can get sound out from the card, although the sound is badly distorted. I am therefore closing this bug, as it is now not a Linux kernel pcmcia/cardbus issue.
Created attachment 6427 [details] Patch to snd-emu10k1 driver to work with the Audigy 2 ZS Notebook. This patch implements the card recognition and special startup sequence required to activate the IO ports on the card. The sound quality is still very bad, but that is a driver problem and not a pcmcia/cardbus problem.
*** Bug 4734 has been marked as a duplicate of this bug. ***