Bug 7304
|
Description
Thomas Nemeth
2006-10-11 02:15:33 UTC
Created attachment 9205 [details]
Boot message for a 2.6.17 kernel
This shows the typical boot messages I get with a 2.6.x kernel
Created attachment 9206 [details]
List of interruptions from /proc
Created attachment 9207 [details]
iomem from /proc
Created attachment 9208 [details]
ioports from /proc
Created attachment 9209 [details]
output of lspci
Created attachment 9210 [details]
Boot message for a 2.4.27 kernel for comparison
Created attachment 9211 [details]
Interrupts for 2.4
Created attachment 9212 [details]
iomem from /proc for 2.4
Created attachment 9213 [details]
ioports from /proc for 2.4
Created attachment 9214 [details]
output of lspci for 2.4
Created attachment 9215 [details]
Boot message for a 2.6.18 kernel
Created attachment 9216 [details]
CPU info for 2.6.18
Created attachment 9217 [details]
kernel build information for 2.6.18
Created attachment 9218 [details]
Software environment (output of ver_linux) for 2.6.18
Created attachment 9219 [details]
Software environment (output of ver_linux) for 2.4.27
I made an error: Most recent kernel where this bug did NOT occur: 2.4.27 (to my knowledge, didn't test with 2.4.x > 2.4.27) Please try to add "acpi=force" to the kernel-command-line. Best Regards Komuro Created attachment 9373 [details]
Boot messages with kernel command line option acpi=force (2.6.18)
These are the boot messages I get when using the acpi=force option. Until now
I thought that it was acpi the problem so I had to disable it. The results of
this option may show I was right :(
I inserted the cardbus after boot and the message about cardbus support is
still the same...
Hi komuro! Thank you for trying to help! Unfortunately I was not able to get good results with acpi=force as you can see in the new attachment I made. As I said in my previous comment, I though acpi was the problem. May be is there a better combination of boot options I should use instead of the ones I tried until now, but it's not something I can find out since the error messages I get are not really usefull :( I will provide anyone who asks to as many log he/she wants, try any option I am asked to. The only thing I can't do is compiling a custom kernel since this computer is quite old (pentium I MMX @ 166Mhz with 80Mb RAM) and it would take hours/days to have a functionnal kernel... Thanks to anyone that can help me fix this! Thomas. Created attachment 10810 [details]
Toshiba Cardbus bridge not working Gentoo 2.6.19.r5 & Ubuntu 2.6.17
I have a script posted on Gentoo's forums. It is helpful in diagnosing pcmcia
issues.
I get this output:
pcmcia-tool
list everything we know about this card
Socket 0:
3.3V 32-bit PC Card
Socket 0 Bridge: [yenta_cardbus] (bus ID: 0000:01:0b.0)
CardBus card -- see "lspci" for more information
PRODID_1=""
PRODID_2=""
PRODID_3=""
PRODID_4=""
MANFID=0000,0000
FUNCID=255
Socket 0:
no product info available
dmesg:
Kernel command line: root=/dev/hda3 pci=assign-busses pci=routeirq Panic=5
ACPI: bus type pci registered
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
pci_get_subsys() called while pci_devices is still empty
PCI: Routing PCI interrupts for all devices because "pci=routeirq" specified
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
pcmcia: parent PCI bridge I/O window: 0xc000 - 0xcfff
pcmcia: parent PCI bridge Memory window: 0xcff00000 - 0xcfffffff
pcmcia: parent PCI bridge Memory window: 0x58000000 - 0x59ffffff
Yenta: CardBus bridge found at 0000:01:0b.0 [1179:0001]
Yenta: ISA IRQ mask 0x04b8, PCI irq 19
memory from /etc/pcmcia/config.opts
include memory 0xc0000-0xfffff
include memory 0xa0000000-0xa0ffffff
include memory 0x60000000-0x60ffffff
lspci:
01:0b.0 CardBus bridge: Toshiba America Info Systems ToPIC100 PCI to Cardbus
Bridge with ZV Support (rev 33)
Bus: primary=00, secondary=01, subordinate=05, sec-latency=64
Bus: primary=01, secondary=02, subordinate=05, sec-latency=0
Seems like same problem.
I tested with 2.6.21 and the problem remains the same. Here are the kernel parameters I tested one by on and sometimes several at a time: noapic nolapic irqpoll pci=assign-busses pic=routeirq pci=bios pci=biosirq pnpacpi=off acip=off Created attachment 11967 [details]
Boot messages for a 2.6.21 kernel
Thomas, any luck with recent kernel? This problem might be related to ACPI, as well as PNP I think, so CCing to Bjorn to take a fresh look. (In reply to comment #23) > Thomas, any luck with recent kernel? No. But this is because I could not test them. I moved from my flat and could not use the offending machine since then. Unfortunately I don't even know if I'll be able to test further more kernels on that machine: I had debian installed on it with a 2.4 so that I could use the net to install and test new softs and kernels. But the last 2.6 test required me to upgrade the glibc which seems not to be compatible with 2.4 :( I need to find a small distro on CD/USB with not much resource needs. If you have an idea of a such a small distro, I'll be glad to use it for my tests. I'll find some time to test the last and the next ubuntu kernels if I can make them boot, then I'll feed again this report. > This problem might be related to ACPI, as well as PNP I think, so CCing to > Bjorn to take a fresh look. I had been trying every ACPI boot parameter. I don't know which one could have a positive effect... Thanks. Thomas. I think you're using the i82365 driver in 2.4.27 but the yenta driver in 2.6. Can you try using i82365 in 2.6? It looks like the CardBus bridge devices (00:13.0 and 00:13.1) claim to be using PCI interrupts INTA and INTB, but we didn't find those in the ACPI _PRT. That might be a BIOS bug, but I don't think it's the root cause here. My PCMCIA/CardBus understanding is meager, but I think the bridge itself and devices behind the bridge (e.g., your NIC) can use different interrupts. Your bridge claims to be generating interrupts on INTA and INTB (and we don't know what they're connected to), but I think the NIC is using IRQ 3. My guess is that the bridge is connecting the CINT# wire from the NIC directly to the IRQ 3 input on an interrupt controller. I don't know why yenta can't deal with this, but I wonder if i82365 can. (In reply to comment #25) > I think you're using the i82365 driver in 2.4.27 but the yenta driver in 2.6. From what I remember, it was yenta_socket also in 2.4.x (as it was for 2.2.x)... > Can you try using i82365 in 2.6? I tried, with a 2.6.24.2, using the slitaz distro. modprobing the i82365 raises an error message: Intel ISA PCIC probe: not found. i82092 gives no error message, but my card is not detected. Yenta_socket still raises the same error messages :( I just tried with a 2.6.25.6 with the same results... I'm now able to build my own kernels. Is there any particular option I could use to debug ? I enabled debug in yenta_socket but I don't think the output is sufficient enough to help debugging... Have you tried loading the yenta_socket module with the option pwr_irqs_off=1? (In reply to comment #28) > Have you tried loading the yenta_socket module with the option > pwr_irqs_off=1? Yes. This option is of no help unfortunately. I'll add an attachment for the dmesg from the 2.6.25.6... I added debug output. Created attachment 16475 [details]
Dmesg of 2.6.25.6 with yenta_socket module insertion.
I have just tested the 2.6.26.2 kernel with, as usual, the same results. However, there is a bit more information I can give. On the same laptop, with a bit old distro and a 2.2.27-pre2 kernel (which I have used for years) the same hardware works perfectly. The IRQs are not found as in recent kernels, so it does not seem the problem comes from here. I checked the modules loaded: the i82365 is the one used by this old kernel. So I loaded this module on the 2.6.26.2 kernel and the result is here: Intel ISA PCIC probe: not found. FATAL: Error inserting i82365 (/lib/modules/2.6.26.2-slitaz/kernel/drivers/pcmcia/i82365.ko): No such device I'll give more information on the 2.2.27-pre2... Created attachment 17204 [details]
Boot messages of 2.2.27-pre2
Created attachment 17205 [details]
Modules list for 2.2.27-pre2
Created attachment 17206 [details]
List of interruptions for 2.2.27-pre2
Created attachment 17207 [details]
List of PCI devices for 2.2.27-pre2
Created attachment 17208 [details]
IO ports for 2.2.27-pre2
I've just made some other tests. I was wrong when I previously said that in 2.2.x it was yenta: it really was i82365. And it worked without PCI IRQs numbers as shown in the boot messages. But with 2.4.x and 2.6.x it really is yenta: i82365 does not support PCI devices -- and in particular ToPIC97 (PCI-to-CardBus) -- but only ISA devices ! Created attachment 17385 [details]
Boot messages of 2.4.22
The boot messages of a 2.4.22 kernel show that kernels 2.4 correctly recognize the ToPIC97 pcmcia Cardbus adapter
Created attachment 17386 [details]
List of modules for 2.4.22
The modules list shows that the pcmcia module used for the recognized pcmcia chipset is really yenta_socket.
Created attachment 17387 [details]
PCI listing for 2.4.22
Additionnal information about PCI listing regarding the pcmcia adapter.
Created attachment 17388 [details]
IO mem for 2.4.22
Created attachment 17389 [details]
IO ports for 2.4.22
I modified a little the yenta_socket module just to see what would happen if CardBus support disabling -- when no IRQ is found -- was dropped (see the patch in the next attachment). The pcmcia chipset is then correctly recognised, and my pcmcia eth card is too. But I couldn't set its IP address (see strace in further attachement). Created attachment 17395 [details]
Patch to force CardBus support in yenta socket even when no IRQ is found.
Created attachment 17396 [details]
Boot messages of 2.6.26.2 with yenta patch applied
Created attachment 17397 [details]
Strace dump when calling ifconfig when yenta patch is applied
Comment on attachment 17396 [details]
Boot messages of 2.6.26.2 with yenta patch applied
boot messages cluttered by several insmod/modprobe attempts... please ignore this one. Sorry.
Created attachment 17399 [details]
Boot messages of 2.6.26.2 with yenta patch applied
It seems the pcmcia-cs uses special technique for the cardbus-bridge
that can't get the irq.
Currently, no one is working at such old PC for kernel 2.6.x.
I recommend you buy a new PC.
>tulip0: MII transceiver #1 config 3100 status 7849 advertising 05e1.
>eth0: ADMtek Comet rev 17 at Port 0x1800, 00:14:00:00:3e:79, IRQ 0.
tulip0 is working at polling mode...
(In reply to comment #49) > It seems the pcmcia-cs uses special technique for the cardbus-bridge > that can't get the irq. Certainly. The real question is: which one :) > Currently, no one is working at such old PC for kernel 2.6.x. > I recommend you buy a new PC. I already have a new PC. That's not the answer I wanted to have. I like using old computers (I have some old Sparcs, MacIntoshes and even an AS400). And, from what I heard on recent news, support for old computers is not planned for removal. I don't have much time. I'll try and see what I can do to bring that pcmcia chipset to work but I need help. Thomas. Hm, it looks to me that the PCI IRQ pins are routed to IRQ #11. So what about trying out (at first) some workaround: Could you replace the line in drivers/pcmcia/yenta_socket.c - function yenta_probe() which states: socket->cb_irq = dev->irq; with: socket->cb_irq = 11; ? Also, some quite new patches (see: http://www.mail-archive.com/linux-pcmcia@lists.infradead.org/msg02903.html http://www.mail-archive.com/linux-pcmcia@lists.infradead.org/msg02904.html http://www.mail-archive.com/linux-pcmcia@lists.infradead.org/msg02906.html ) which currently are only for some TI bridge might be generalized to work also in other cases where the PCI IRQ is 0. I'll dig into that later. > --- Comment #51 from Dominik Brodowski <linux@brodo.de> 2010-03-06 14:07:42 > --- > Hm, it looks to me that the PCI IRQ pins are routed to IRQ #11. So what about > trying out (at first) some workaround: Could you replace the line in > drivers/pcmcia/yenta_socket.c - function yenta_probe() which states: > socket->cb_irq = dev->irq; > with: > socket->cb_irq = 11; > ? It seems that forcing the irq number does not change anything :( I tested that oneliner on the 2.6.25.6 (since it's the one I already had under my hand at that time) and there are still the same messages. > Also, some quite new patches (see: > http://www.mail-archive.com/linux-pcmcia@lists.infradead.org/msg02903.html > http://www.mail-archive.com/linux-pcmcia@lists.infradead.org/msg02904.html > http://www.mail-archive.com/linux-pcmcia@lists.infradead.org/msg02906.html > ) which currently are only for some TI bridge might be generalized to work > also > in other cases where the PCI IRQ is 0. I'll dig into that later. Should I use a more recent kernel or can I continue going on with 2.6.25.6 ? Using a recent kernel may take me some time since there's no network on that machine (the network only comes through pcmcia :( ). Anyway, thank you very much ! I was desperating that someone might have a look at my problem... Thomas. I was wrong. It indeed changed something. My PCMCIA eth device has been recognized once I inserted the yenta_socket module. Still the IRQ at boot time is not detected, but now, at least, I have something close to a working state. The eth device seems to be recognized but the network refuses to communicate. Moreover the patches don't apply to either 2.6.32.9 or 2.6.33 (there are some badly placed newlines in the webpages containing the patches. I tried to correct most of them but I don't know if I did them all). I'll send you some more boot logs with 2.6.25.6 and 2.6.33, and then I'll try to apply the patches by hand. Created attachment 25494 [details]
Boot messages for 2.6.25.6 with IRQ forced to 11.
Here is the bootlog of the 2.6.25.6 kernel with the yenta_socket IRQ forced to
11. There is clearly some improvements here since I can have an ethernet device
when I plugin the pcmcia eth card. However I still cannot send pings through the
network.
What happens if you eject and insert the card multiple times? Is this recognized? Created attachment 25495 [details]
Boot messages for 2.6.33 with IRQ forced to 11.
Created attachment 25496 [details]
Boot messages for 2.6.33 with IRQ forced to 3...
As in the previous kernels messages I had seen that the IRQ used was IRQ3,
this time, instead of 11, I forced the IRQ to 3. However, this did not
worked as expected :)
(In reply to comment #55) > What happens if you eject and insert the card multiple times? Is this > recognized? Yes. Each time I insert back the card, eth0 is recognized the same. Created attachment 25497 [details] Boot messages for 2.6.33 with the 3 pcmcia specified patches in comment #51 I applied by hand the patches from comment #51, but the result is a bit buggy. From the context shown in the original patches, I can see that the code from 2.6.33 is not the one these patches apply on. I'll make my patches available in another attachment if needed. Okay, to summarize: - forcing IRQ to be 11 means the CardBus bridge works as it should -- it recognizes card insert and eject events properly. - the CardBus network card does not work, though. I'm not surprised at all that the patches in comment #51 do not work -- they are for a different, but still similar problem. What I'd be interested now is the output of the "cbdump" tool (part of pcmciautils, pcmcia-cs) both under a working and a non-working kernel. Maybe we need to set some register properly for the hard override to work. Created attachment 25507 [details]
cbdump for 2.6.26.2
This is the output of cbdump for a not-working 2.6.26.2 kernel.
Created attachment 25508 [details]
cbdump for 2.6.33
This is the output of cbdump for the 2.6.33 kernel modified with the
IRQ forced to 11. Although I cannot ping other computers on the network,
it may be the best option by now. I'll investigate to see if it's not a
router related problem.
I can't make a 2.4.27 load the yenta_socket driver anymore with the old
debian sarge install CD.
After having done tests the 2.6.33 with the IRQ forced to 11 really does not work. It's not a router related problem. The 2.2.27 kernel is too old to run cbdump :( I'll try to have a 2.4 working kernel again. Does "lspci -vvxxx" work on a 2.2.27 kernel? Maybe the difference between the output of "lspci -vvxxx" on 2.2.27 and 2.6.33 does help enough to make it work? Created attachment 25509 [details]
output of lspci -vvxxx on 2.6.33
This is the output of the lspci -vvxxx command on the 2.6.33 kernel. I'm
not skilled enough to know what means the hexdump.
Created attachment 25510 [details]
output of lspci -H 2 -vvxxx on 2.2.27
I had to make a direct hardware access.
(In reply to comment #64) > Does "lspci -vvxxx" work on a 2.2.27 kernel? Maybe the difference between the > output of "lspci -vvxxx" on 2.2.27 and 2.6.33 does help enough to make it > work? As you can see, unfortunately, it's not sufficient... At least for me. The only thing I can observe is that with the 2.2.27 kernel, my network adapter is seen as a pci device though it's not even seen by the 2.6.33. Could you repeat the "cbdump" on (plain) 2.6.33 with IRQ forced to 11, and the network card inserted? (In reply to comment #68) > Could you repeat the "cbdump" on (plain) 2.6.33 with IRQ forced to 11, and > the > network card inserted? It should already be the one in attachment 25508 [details] (see Comment #62 for more). While I'm checking the cbdump output: are you sure the "tulip" driver is the correct one for this card? There seem to be some mis-assignments in the past ( https://bugs.launchpad.net/ubuntu/+source/udev/+bug/48026 ), that's why I ask... and next question: Are there two CardBus/PCMCIA slots? If so, might the other one work? (The I365_ settings for slot 0 seem much more appropriate than the ones for slot 1) (In reply to comment #70) > While I'm checking the cbdump output: are you sure the "tulip" driver is the > correct one for this card? There seem to be some mis-assignments in the past > ( > https://bugs.launchpad.net/ubuntu/+source/udev/+bug/48026 ), that's why I > ask... It was the one used by 2.2.27 and 2.4.22 as show in attachment 17205 [details] and in attachment 17386 [details] but may be has it changed since then ? The only difference, module-related, between a working and a current non-working kernel is that the 2.2.27 used the i82365 driver and now only the yenta_socket seems to recognize the device. (In reply to comment #71) > and next question: Are there two CardBus/PCMCIA slots? If so, might the other > one work? (The I365_ settings for slot 0 seem much more appropriate than the > ones for slot 1) Oh ! You got it right !!! That's strange, but now, with 2.6.33 and the yenta_socket IRQ forced to 11, the card when put into the slot 0 works ! I'm more that happy to know that. Excellent news. Is this result sufficient for you? If so, I'd suggest closing the bug as WONTFIX. Otherwise, we'd first need to create a DMI-based quirk so that IRQ is set to 11; and then debug why the second slot does not work, while the first one does. (In reply to comment #74) > Excellent news. Is this result sufficient for you? If so, I'd suggest closing > the bug as WONTFIX. Otherwise, we'd first need to create a DMI-based quirk so > that IRQ is set to 11; and then debug why the second slot does not work, > while > the first one does. I'm ready for the full debug session, if you don't mind, so that the fixes are available in distributions, espacially those targeted for old hardware. But if you want to let it in this state, I'm fine with it, I'll just have to recompile new kernels each time... Or make my own distro :) That's good news. To create the DMI-based quirk, we'd first need a "dmidecode" output. For the other problem(s), I need to dig into some documentation and 2.4 source code first... (In reply to comment #76) > That's good news. To create the DMI-based quirk, we'd first need a > "dmidecode" > output. For the other problem(s), I need to dig into some documentation and > 2.4 > source code first... Ok. I'll provide you this information. Is there anything special needed to look for in the output ? Created attachment 25571 [details]
dmidecode output on 2.6.33 with IRQ 11 forced.
Here we have a problem.
dmidecode did not produce any output. On my work desktop, dmidecode worked
nice producing a lot of output, but on the target machine, nothing came out.
Just this message saying that it found nothing.
I have compiled the other softs in the dmidecode package. If you need some
more information, just tell me.
Regarding the dmidecode output: do you have CONFIG_DMI and CONFIG_DMIID enabled in the kernel? Using a dmi-code is the preferred way to specify an override. Also, could you re-run cbdump, please, with kernel 2.6.34-rc2 and the following fix-up: socket->cb_irq = 11; dev->irq = 11; first inserted into the working socket #1, then into the non-working socket #0? Thanks! Created attachment 25689 [details]
Boot messages for 2.6.34-rc2 with IRQ forced to 11.
As you requested I compiled a 2.6.34-rc2 kernel with the irqs forced to 11.
The configuration file displays:
$ grep CONFIG_DMI linux-2.6.34-rc2/.config
CONFIG_DMI=y
CONFIG_DMIID=y
It was the same with the 2.6.33 :(
I booted and configuered the eth card in the working slot, tested it (ok) and
then put it in the other (non-working) slot. It could get an IP address through
DHCP but ping didn't work.
dmidecode gave the same results as previouly.
Ooops wrong. I didn't get an IP address through DHCP on the non-working slot. I just forgot to ifconfig down the interface before switching slots. The non-working slot still doesn't work. Regarding the dmidecode output, could it be that my computer is too old ? This is with both socket->cb_irq = 11; dev->irq = 11; ? What's the cbdump output of each socket, with the card inserted? (I'm asking as one bit which should be set to 0 is set to 1 in the last cbdump output, and that confuses me) Created attachment 25724 [details]
Output of cbdump on 2.6.34-rc2 with the eth card in the non-working slot
Created attachment 25725 [details]
Output of cbdump on 2.6.34-rc2 with the eth card in the working slot
(In reply to comment #82) > This is with both > socket->cb_irq = 11; > dev->irq = 11; > ? Yes. thomas@cixi:exether$ grep "= 11;" linux-2.6.34-rc2/drivers/pcmcia/yenta_socket.c socket->cb_irq = 11; dev->irq = 11; > What's the cbdump output of each socket, with the card inserted? (I'm asking > as one bit which should be set to 0 is set to 1 in the last cbdump output, > and that confuses me) Here is the diff between the two dumps (hope this helps): thomas@cixi:~$ diff cbdump-2.6.34-rc2-slitaz-nonworkingslot cbdump-2.6.34-rc2-slitaz-workingslot --- cbdump-2.6.34-rc2-slitaz-nonworkingslot 2010-03-26 22:15:39.000000000 +0100 +++ cbdump-2.6.34-rc2-slitaz-workingslot 2010-03-26 22:15:40.000000000 +0100 @@ -12,20 +12,20 @@ IO Limit 0 [30] : 0x000018fc IO Base 1 [34] : 0x00001c00 IO Limit 1 [38] : 0x00001cfc - Bridge control [3e] : 0x0500 + Bridge control [3e] : 0x0580 Subsystem vendor ID [40] : 0x1179 Subsystem device ID [42] : 0x0001 Legacy mode base [44] : 0x0001 -- cardbus registers CB_SOCKET_EVENT [00] : 0x00000000 CB_SOCKET_MASK [04] : 0x00000006 - CB_SOCKET_STATE [08] : 0x30000828 + CB_SOCKET_STATE [08] : 0x30000007 CB_SOCKET_FORCE [0c] : 0x00000000 - CB_SOCKET_CONTROL [10] : 0x00000033 + CB_SOCKET_CONTROL [10] : 0x00000000 CB_SOCKET_POWER [20] : 0x00000000 -- exca registers I365_IDENT [00] : 0x83 - I365_STATUS [01] : 0x8e + I365_STATUS [01] : 0xb2 I365_POWER [02] : 0x40 I365_INTCTL [03] : 0x40 I365_CSC [04] : 0x00 @@ -73,20 +73,20 @@ IO Limit 0 [30] : 0x000010fc IO Base 1 [34] : 0x00001400 IO Limit 1 [38] : 0x000014fc - Bridge control [3e] : 0x0580 + Bridge control [3e] : 0x0500 Subsystem vendor ID [40] : 0x1179 Subsystem device ID [42] : 0x0001 Legacy mode base [44] : 0x0001 -- cardbus registers CB_SOCKET_EVENT [00] : 0x00000000 CB_SOCKET_MASK [04] : 0x00000006 - CB_SOCKET_STATE [08] : 0x30000087 + CB_SOCKET_STATE [08] : 0x30000828 CB_SOCKET_FORCE [0c] : 0x00000000 - CB_SOCKET_CONTROL [10] : 0x00000000 + CB_SOCKET_CONTROL [10] : 0x00000033 CB_SOCKET_POWER [20] : 0x00000000 -- exca registers I365_IDENT [00] : 0x83 - I365_STATUS [01] : 0xb2 + I365_STATUS [01] : 0x8e I365_POWER [02] : 0x40 I365_INTCTL [03] : 0x40 I365_CSC [04] : 0x00 thomas@cixi:~$ Created attachment 25735 [details]
test patch to use ISA IRQs also for CardBus
That's bad news -- both sockets are configured the same way. So they _should_ behave the same way, and work... Well, could you remove the IRQ=11 forced setting, try out the attached patch (both sockets), and send the dmesg (even if it works)? cbdump or other is not needed.
Created attachment 25738 [details]
Boot messages for 2.6.34-rc2 with applied patch
No slot worked :(
Thanks. Both sockets look properly configured (for PCI IRQ = 11); the workaround (trying to use ISA IRQs for PCI) does not work as expected -- at least from what I determine out of the ToPIC97 datasheet found at the pcmcia-cs homepage. :( I often have to read datasheets. Mainly for touchscreens, I2C devices and some other external devices. However, reading through the ToPIC97 datasheet gave me headaches :( What can I do now, in order to help you ? Created attachment 25766 [details]
Patch to force IRQ number as a module parameter.
I know this is not the ideal solution for this problem. Probing would be way
better to handle this, but in the end, if we can't, there's still this handy
solution...
And it's not very intrusive ;) It applies against the 2.6.34-rc2.
Still it does not fix the problem with the non-working slot, of course :(
However what about the 2.2.x code used to detect the IRQ ? Extracting the used
algorithm should be rather difficult mainly due to kernel architecture changes
but it used to work.
The problem isn't detecting the IRQ -- we can use ISA IRQ 3 (as 2.2.xx did) or ISA IRQ 9 and 10 (as the patch in comment #86 did). The problem is setting up the bridge so that it routes CSC (card status change) IRQs for CardBus and 16bit cards to the ISA IRQ and also card IRQs for CardBus and 16bit cards to the ISA IRQ. This seems to be impossible on the ToPIC97. However, 2.2. seems to do some "polling" to get the IRQs right. I.e., it isn't really using the IRQs, but polls whether an IRQ occured. That seems necessary at least or the CSC interrupt. Dominik Brodowski wrote: > The problem isn't detecting the IRQ -- we can use ISA IRQ 3 (as 2.2.xx did) > or > ISA IRQ 9 and 10 (as the patch in comment #86 did). > > The problem is setting up the bridge so that it routes CSC (card status > change) > IRQs for CardBus and 16bit cards to the ISA IRQ and also card IRQs for > CardBus > and 16bit cards to the ISA IRQ. This seems to be impossible on the ToPIC97. > > However, 2.2. seems to do some "polling" to get the IRQs right. I.e., it > isn't > really using the IRQs, but polls whether an IRQ occured. That seems necessary > at least or the CSC interrupt. Hm, so what's the next step (if any)? Just for completeness: Thomas tested[1] with 3.0 and symptoms are still present. [1] http://bugs.debian.org/366507#108 Well, one slot seems to work with the (technically) intrusive patch which forces the IRQ to 11, right? If so, I'd propose to keep it this way -- and keep this patch outside of mainline. Also, a DMI-based override won't work for this machine (strangely) does not report any DMI information at all. Thomas, do you have a patch that works for you against 3.2.y? If so, then I'd suggest putting it in Documentation/pcmcia/ with a note on the issue and calling it done. Or if it is possible to add a kernel command line option for this with a not-too-intrusive patch, that might be another way. I just don't like the idea of someone being stuck on an old kernel because of their hardware. (In reply to comment #94) > Thomas, do you have a patch that works for you against 3.2.y? I don't, but I can make one. My previous patch was only a few lines. I think it still can apply: $ patch -p1 < /home/thomas/pcmcia_yenta_force_irq.patch patching file drivers/pcmcia/yenta_socket.c Hunk #1 succeeded at 36 (offset -1 lines). Hunk #2 succeeded at 1223 (offset -2 lines). However, it does not use the kernel command line. Should not be hard to add... |