Bug 5057

Summary: Cardbus ioports fails. inb(), inw() and ind() cause an entire system hang and pci bus error.
Product: Drivers Reporter: James Courtier-Dutton (James)
Component: Video(Other)Assignee: Greg Kroah-Hartman (greg)
Status: CLOSED CODE_FIX    
Severity: high CC: ambx1, chainsaw, hades.himself, pujos.michael, raymond.lai, thomas, torvalds, twalter
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: 2.6.13-rc5 Subsystem:
Regression: --- Bisected commit-id:
Attachments: lspci output using "lspci -m -xxx" under linux kernel 2.6.13-rc5
lspci output in "lspci -m -xxx" format under Windows 2000
Version of ca0106_main.c for test purposes.
output from "cat /proc/ioports"
Example diff
lspci output using "lspci -m -xxx" under linux kernel 2.6.13-rc5
pci-transparent-hack.patch
Result of lspci -m -xxx after the "transparent" patch from Adam
Result of lspci -m -xxx after the "pci-command 7" from Linus
Experimental patch to show CB/ExCA registers
win XP pci information from PCIScope
2.6.14-rc5-mm1 w/patch card inserted.
2.6.14-rc5-mm1 w/patch w/o card inserted
2.16.14-rc5 vanilla w/patch w/card inserted
Windows XP dump of PCI bus (O2 controller & SB0530)
Patch to snd-emu10k1 driver to work with the Audigy 2 ZS Notebook.

Description James Courtier-Dutton 2005-08-13 07:57:59 UTC
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?
Comment 1 James Courtier-Dutton 2005-08-13 08:00:06 UTC
Created attachment 5625 [details]
lspci output using "lspci -m -xxx" under linux kernel 2.6.13-rc5
Comment 2 James Courtier-Dutton 2005-08-13 08:01:11 UTC
Created attachment 5626 [details]
lspci output in "lspci -m -xxx" format under Windows 2000
Comment 3 James Courtier-Dutton 2005-08-13 08:04:32 UTC
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.
Comment 4 James Courtier-Dutton 2005-08-13 08:22:51 UTC
Created attachment 5628 [details]
output from "cat /proc/ioports"
Comment 5 Linus Torvalds 2005-08-18 12:45:58 UTC
Created attachment 5667 [details]
Example diff

Try to set up yenta controller more like W2000
Comment 6 Linus Torvalds 2005-08-18 12:46:43 UTC
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.
Comment 7 James Courtier-Dutton 2005-08-18 15:13:20 UTC
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.
Comment 8 Adam Belay 2005-08-18 15:30:49 UTC
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
Comment 9 Adam Belay 2005-08-18 15:36:00 UTC
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.
Comment 10 Adam Belay 2005-08-18 15:38:26 UTC
Does the above patch solve your problem?  Also, could I see the new lspci output.

Thanks,
Adam
Comment 11 Linus Torvalds 2005-08-18 15:39:10 UTC

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

Comment 12 Linus Torvalds 2005-08-18 15:42:05 UTC

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

Comment 13 James Courtier-Dutton 2005-08-20 03:27:18 UTC
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.
Comment 14 James Courtier-Dutton 2005-08-20 03:40:22 UTC
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.
Comment 15 James Courtier-Dutton 2005-08-20 04:04:11 UTC
As a follow up to the "Secondary status: SERR". How can we clear that signal?
Comment 16 Linus Torvalds 2005-08-20 08:14:51 UTC

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

Comment 17 James Courtier-Dutton 2005-08-20 15:07:02 UTC
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
Comment 18 Dominik Brodowski 2005-09-13 15:22:07 UTC
Could you try 2.6.13-mm3, please?
Comment 19 James Courtier-Dutton 2005-09-17 07:03:09 UTC
Retried with kernel
2.6.13-mm3

No change. It still hangs the machine at the inw() instruction.
Comment 20 Michael Pujos 2005-09-27 11:05:57 UTC
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.

Comment 21 James Courtier-Dutton 2005-09-27 11:14:10 UTC
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.
Comment 22 Adam Belay 2005-09-27 13:33:36 UTC
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
Comment 23 James Courtier-Dutton 2005-09-27 13:51:35 UTC
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.
Comment 24 Adam Belay 2005-09-27 14:40:03 UTC
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
Comment 25 James Courtier-Dutton 2005-09-27 14:59:02 UTC
SERR is not set on card insertion, SERR is set after IO touched.
Comment 26 Luis F Balbinot 2005-10-19 16:47:06 UTC
Any news? I've got one of these cards and I'm willing to help.
Comment 27 Jay Hilliard 2005-10-23 16:29:39 UTC
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
Comment 28 Todd Walter 2005-10-26 12:17:17 UTC
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.
Comment 29 Todd Walter 2005-10-26 12:20:25 UTC
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
Comment 30 James Courtier-Dutton 2005-10-26 15:13:30 UTC
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?
Comment 31 Linus Torvalds 2005-10-26 15:27:48 UTC

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

Comment 32 James Courtier-Dutton 2005-10-26 15:34:19 UTC
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
Comment 33 Todd Walter 2005-10-26 16:20:09 UTC
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.
Comment 34 James Courtier-Dutton 2005-10-27 01:04:24 UTC
Yes, it is Model SB0530. I am in the UK.
The Serial number of the device also contains the model number:
E.g. M1SB0530504000000P
Comment 35 Linus Torvalds 2005-10-27 13:37:24 UTC

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

Comment 36 Linus Torvalds 2005-10-27 22:48:06 UTC
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.
Comment 37 Linus Torvalds 2005-10-27 22:59:56 UTC

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

Comment 38 Michael Pujos 2005-10-28 04:40:06 UTC
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
Comment 39 Todd Walter 2005-10-28 05:20:01 UTC
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
Comment 40 James Courtier-Dutton 2005-10-28 05:47:04 UTC
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.
Comment 41 Michael Pujos 2005-10-28 05:50:20 UTC
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)
Comment 42 Todd Walter 2005-10-28 05:58:02 UTC
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.
Comment 43 Todd Walter 2005-10-28 05:59:14 UTC
Created attachment 6408 [details]
2.6.14-rc5-mm1 w/patch card inserted.
Comment 44 Todd Walter 2005-10-28 06:00:19 UTC
Created attachment 6409 [details]
2.6.14-rc5-mm1 w/patch w/o card inserted
Comment 45 Todd Walter 2005-10-28 06:01:35 UTC
Created attachment 6410 [details]
2.16.14-rc5 vanilla w/patch w/card inserted
Comment 46 Todd Walter 2005-10-28 06:56:26 UTC
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
Comment 47 Michael Pujos 2005-10-28 07:02:23 UTC
> --> (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

Comment 48 Todd Walter 2005-10-28 07:39:17 UTC
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.
Comment 49 Michael Pujos 2005-10-28 07:53:16 UTC
bugme-daemon@kernel-bugs.osdl.org a 
Comment 50 Todd Walter 2005-10-28 08:10:57 UTC
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                                 
Comment 51 Linus Torvalds 2005-10-28 08:45:37 UTC

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

Comment 52 Michael Pujos 2005-10-28 09:24:14 UTC
Maybe we should contact creative or a creative developer to help on this ?

Michael

Comment 53 James Courtier-Dutton 2005-10-30 15:46:28 UTC
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.

Comment 54 James Courtier-Dutton 2005-10-31 02:11:33 UTC
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.
Comment 55 James Courtier-Dutton 2005-11-06 14:30:10 UTC
*** Bug 4734 has been marked as a duplicate of this bug. ***