Subject: Problems with PCMCIA on AMD Alchemy DB1100

From: Josh Green <[email-masked]>
Date: Tue, 01 Feb 2005 16:36:07 -0800

I'm using the latest Linux MIPS CVS (2.6.11-rc2) on an AMD Alchemy
DB1100 with a tool chain created with buildroot (gcc 3.4.3, binutils
2.15.91.0.2) and found a bug in drivers/pcmcia/au1000_generic.c that was
causing the following error during initialization (not exact text, close
as I can remember), and subsequently the PCMCIA hardware was unavailable
(pcmcia_register_socket() was failing due to NULL resource_opts field).

au1x00_pcmcia: probe of au1x00-pcmcia0 failed with error -22

Here is a patch:

--- au1000_generic.c.orig       2005-02-01 12:19:29.572617936 -0800
+++ au1000_generic.c    2005-02-01 13:47:08.543132896 -0800
@@ -392,6 +392,7 @@
                memset(skt, 0, sizeof(*skt));

                skt->socket.ops = &au1x00_pcmcia_operations;
+               skt->socket.resource_ops = &pccard_static_ops;
                skt->socket.owner = ops->owner;
                skt->socket.dev.dev = dev;

Additionally I noticed that some of the 36 bit constants in
au1000_generic.h (AU1X_SOCK0_IO and AU1X_SOCK1_IO) were causing the
warning "Integer constant too large for long type" (IIRC).  Here is a
patch for this, although I'm not sure if this is the correct way to fix
it, or even if it was causing problems or not, although it does get rid
of the warnings.

--- au1000_generic.h.orig       2005-02-01 12:39:16.371197128 -0800
+++ au1000_generic.h    2005-02-01 12:40:23.405006440 -0800
@@ -34,9 +34,9 @@
 #define AU1000_PCMCIA_IO_SPEED       (255)
 #define AU1000_PCMCIA_MEM_SPEED      (300)

-#define AU1X_SOCK0_IO        0xF00000000
-#define AU1X_SOCK0_PHYS_ATTR 0xF40000000
-#define AU1X_SOCK0_PHYS_MEM  0xF80000000
+#define AU1X_SOCK0_IO        0xF00000000LL
+#define AU1X_SOCK0_PHYS_ATTR 0xF40000000LL
+#define AU1X_SOCK0_PHYS_MEM  0xF80000000LL
 /* pseudo 32 bit phys addresses, which get fixed up to the
  * real 36 bit address in fixup_bigphys_addr() */
 #define AU1X_SOCK0_PSEUDO_PHYS_ATTR 0xF4000000
@@ -46,15 +46,15 @@
  * differs from board to board.
  */
 #if defined(CONFIG_MIPS_PB1000) || defined(CONFIG_MIPS_PB1100) || defined(CONFIG_MIPS_PB1500) || defined(CONFIG_MIPS_PB1550)
-#define AU1X_SOCK1_IO        0xF08000000
-#define AU1X_SOCK1_PHYS_ATTR 0xF48000000
-#define AU1X_SOCK1_PHYS_MEM  0xF88000000
+#define AU1X_SOCK1_IO        0xF08000000LL
+#define AU1X_SOCK1_PHYS_ATTR 0xF48000000LL
+#define AU1X_SOCK1_PHYS_MEM  0xF88000000LL
 #define AU1X_SOCK1_PSEUDO_PHYS_ATTR 0xF4800000
 #define AU1X_SOCK1_PSEUDO_PHYS_MEM  0xF8800000
 #elif defined(CONFIG_MIPS_DB1000) || defined(CONFIG_MIPS_DB1100) || defined(CONFIG_MIPS_DB1500) || defined(CONFIG_MIPS_DB1550)
-#define AU1X_SOCK1_IO        0xF04000000
-#define AU1X_SOCK1_PHYS_ATTR 0xF44000000
-#define AU1X_SOCK1_PHYS_MEM  0xF84000000
+#define AU1X_SOCK1_IO        0xF04000000LL
+#define AU1X_SOCK1_PHYS_ATTR 0xF44000000LL
+#define AU1X_SOCK1_PHYS_MEM  0xF84000000LL
 #define AU1X_SOCK1_PSEUDO_PHYS_ATTR 0xF4400000
 #define AU1X_SOCK1_PSEUDO_PHYS_MEM  0xF8400000
 #endif

Some additional problems that I have been experiencing, but am still
investigating.  If anyone has any ideas of what is causing these, I'd
love to hear them.

I have 2 Senao 802.11b PCMCIA cards and I'm using the hostap_cs driver.
If I initialize pcmcia (cardmgr) with both cards in the PCMCIA slots
only one of them will initialize, the second one causes an error:

Linux Kernel Card Services
  options:  none
hostap_cs: 0.2.6 - 2004-12-25 (Jouni Malinen <[email-masked]>)
hostap_cs: Registered netdevice wifi0
hostap_cs: index 0x01: Vcc 3.3, irq 34, io 0xc0000000-0xc000003f
wifi0: NIC: id=0x800c v1.0.0
wifi0: PRI: id=0x15 v1.1.0
wifi0: STA: id=0x1f v1.4.9
0.0: RequestIO: Configuration locked    <--- Second card causes this
0.0: GetNextTuple: No more items
ds: unable to create instance of 'hostap_cs'!

If I bring up PCMCIA without the cards in, and then insert one, and then
the other, both cards initialize fine and I get wlan0 and wlan1.

The other problem I've experienced is a kernel oops when ejecting a
card.  While it isn't a problem for my project (should never be
inserting/ejecting cards) I thought I'd mention it.  Here is the oops
output, I wasn't able to use ksymoops since I'm having trouble building
a cross compiled version (buildroot didn't install libbfd, etc from
binutils), so this may or may not be useful:

Unhandled kernel unaligned access in arch/mips/kernel/unaligned.c::emulate_load_store_insn, line 475[#1]:
Cpu 0
$ 0   : 00000000 1000fc00 37312031 3a31303a
$ 4   : 83e6cec8 1000fc01 80300d48 00000031
$ 8   : 8110e080 801fadcc 00000000 80318000
$12   : 00000001 00000000 00000003 00000000
$16   : c0010000 83e6cec0 812b77a0 00000008
$20   : 812b77d0 80223c38 00200200 00100100
$24   : 00000000 801f5c60
$28   : 83dea000 83debe88 80364b60 c000a860
Hi    : 00000280
Lo    : 00000230
epc   : c000a8cc ds_event+0x2a0/0x4ac [pcmcia]     Not tainted
ra    : c000a860 ds_event+0x234/0x4ac [pcmcia]
Status: 1000fc02    KERNEL EXL
Cause : 00800014
BadVA : 3a31303a
PrId  : 02030204
Modules linked in: hostap_cs hostap pcmcia au1x00_ss pcmcia_core
Process pccardd (pid: 775, threadinfo=83dea000, task=83de67b0)
Stack : c0007f18 8012c328 80364b60 c00137d8 802f0000 c0007efc c0007dcc 80100dd8
        0000003b c0007dcc c0007dcc c00052ec 80131c00 00200200 00000000 1000fc01
        c0007dcc 00000008 00000001 c00137d8 802f0000 c0007efc c0007f18 c0007f0c
        802ebc88 c00138c4 00000001 00000000 00000003 00000000 c0007dcc 00000000
        c0013000 c0007dcc 80364b60 c0013d80 c0007f18 c0007f0c 00000000 2ab92420
        ...
Call Trace:
 [<8012c328>] do_softirq+0x8c/0xb8
 [<c00137d8>] send_event+0x0/0x204 [pcmcia_core]
 [<80100dd8>] au1000_IRQ+0x118/0x1a0
 [<c00052ec>] au1x00_pcmcia_get_status+0x24/0x44 [au1x00_ss]
 [<80131c00>] msleep+0x48/0x60
 [<c00137d8>] send_event+0x0/0x204 [pcmcia_core]
 [<802ebc88>] __down+0x0/0x15c
 [<c00138c4>] send_event+0xec/0x204 [pcmcia_core]
 [<c0013000>] cs_debug_level+0x0/0x10 [pcmcia_core]
 [<c0013d80>] socket_shutdown+0x44/0x2cc [pcmcia_core]
 [<c0014bc0>] socket_remove+0x1c/0xf4 [pcmcia_core]
 [<c0014f94>] pccardd+0x2fc/0x470 [pcmcia_core]
 [<c00150ec>] pccardd+0x454/0x470 [pcmcia_core]
 [<c0014c98>] pccardd+0x0/0x470 [pcmcia_core]
 [<801208f0>] default_wake_function+0x0/0x20
 [<801208f0>] default_wake_function+0x0/0x20
 [<80104e8c>] kernel_thread_helper+0x10/0x18
 [<80104e7c>] kernel_thread_helper+0x0/0x18

Code: 8c820000  8c830004  2491fff8 <ac620000> ac430004  ac970000  ac960004  8e220020  34420010

Best regards,
	Josh Green

---

From: Pete Popov <[email-masked]>
Date: Tue, 01 Feb 2005 16:47:06 -0800

> au1x00_pcmcia: probe of au1x00-pcmcia0 failed with error -22

Interesting. I haven't seen this problem with a slightly older kernel.

> it, or even if it was causing problems or not, although it does get rid

Thanks, will apply.

> the other, both cards initialize fine and I get wlan0 and wlan1.

No suggestions right now.

> binutils), so this may or may not be useful:

I'll take a look at this.

Pete

---

From: "Robin H. Johnson" <[email-masked]>
Date: Tue, 01 Feb 2005 17:16:14 -0800

On Tue, Feb 01, 2005 at 04:36:07PM -0800, Josh Green wrote:
> 2.15.91.0.2) and found a bug in drivers/pcmcia/au1000_generic.c that
> was causing the following error during initialization (not exact text,
> close as I can remember), and subsequently the PCMCIA hardware was
> unavailable (pcmcia_register_socket() was failing due to NULL
> resource_opts field).
> 
I can confirm this. I thought it was my error in trying to implement
PCMCIA for the XXS1500 board.
A fuller log available here:
http://dev.gentoo.org/~robbat2/xxs1500/linux-xxs1500-20050130.4.status

The preliminary patch that status report refers to is:
http://dev.gentoo.org/~robbat2/xxs1500/linux-xxs1500-20050130.4.gz
(not ready for any merging yet, still contains extra debug code)

> output, I wasn't able to use ksymoops since I'm having trouble
> building a cross compiled version (buildroot didn't install libbfd,
> etc from binutils), so this may or may not be useful:
For your ksymoops, i find it very useful to build my host binutils (not
the cross-compiler chain) with '--enable-targets=all' as then it's
possible to use your regular ksymoops (as of 2.4.10, see the INSTALL
document for more details, I wrote up 'Building ksymoops for
cross-debugging only' section ;-) without having to jump thru hoops for
a cross-ksymoops.

-- 
Robin Hugh Johnson
E-Mail     : [email-masked]
Home Page  : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ#       : 30269588 or 41961639
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

---

From: Josh Green <[email-masked]>
Date: Tue, 01 Feb 2005 21:50:35 -0800

On Tue, 2005-02-01 at 17:16 -0800, Robin H. Johnson wrote:

<cut>

> cross-debugging only' section ;-) without having to jump thru hoops for

Thanks for the tip on ksymoops, I'll give that a shot.  I'm also using
gentoo, for my host system, would be nice if there was a USE flag to
enable all targets :)  Cheers.
	Josh Green

---

From: "Robin H. Johnson" <[email-masked]>
Date: Tue, 01 Feb 2005 22:16:03 -0800

> enable all targets :)  Cheers.
stick 'multitarget' in your USE flags and re-merge binutils ;-).

---

From: Josh Green <[email-masked]>
Date: Tue, 01 Feb 2005 22:23:44 -0800

> Interesting. I haven't seen this problem with a slightly older kernel.

http://www.linux-mips.org/cvsweb/linux/drivers/pcmcia/cs.c.diff?r1=1.51&r2=1.52&f=h

The change around Line 212 looks like the reason.

<cut>

> Pete

I'm still looking into those other problems.  I found another issue
though, which I'm unsure of the exact cause (seems related to hostap
module).  I get this from time to time:

Badness in local_bh_enable at kernel/softirq.c:140
Call Trace:
 [<802482c4>] skb_clone+0x24/0x374
 [<8012c3c8>] local_bh_enable+0x74/0x9c
 [<80251048>] dev_queue_xmit+0x310/0x374
 [<80249884>] kfree_skbmem+0x14/0x30
 [<c0064438>] hostap_data_start_xmit+0x80c/0xac4 [hostap]
 [<8024866c>] alloc_skb+0x58/0xf4
 [<802a1240>] arp_constructor+0x28/0x274
 [<802a0000>] udp_rcv+0x368/0x938
 [<80250e14>] dev_queue_xmit+0xdc/0x374
 [<80360000>] ip_auto_config_setup+0x64/0x240
 [<802a2944>] arp_process+0x7f8/0xa6c
 [<c0062b20>] hostap_80211_rx+0x1034/0x1f04 [hostap]
 [<80251978>] netif_receive_skb+0x1c4/0x3d4
 [<80251978>] netif_receive_skb+0x1c4/0x3d4
 [<80251c98>] process_backlog+0x110/0x2f0
 [<80250000>] dev_change_name+0x34/0x2ec
 [<c003f96c>] hostap_rx_tasklet+0x228/0x2bc [hostap_cs]
 [<80251f44>] net_rx_action+0xcc/0x294
 [<8012c818>] tasklet_action+0xc4/0x194
 [<801479f4>] handle_IRQ_event+0x7c/0x134
 [<8012c1dc>] __do_softirq+0x8c/0x14c
 [<80147c40>] __do_IRQ+0x194/0x1b4
 [<80360000>] ip_auto_config_setup+0x64/0x240
 [<80360000>] ip_auto_config_setup+0x64/0x240
 [<8012c328>] do_softirq+0x8c/0xb8
 [<80360000>] ip_auto_config_setup+0x64/0x240
 [<80100e2c>] au1000_IRQ+0x16c/0x1a0
 [<80360000>] ip_auto_config_setup+0x64/0x240
 [<80104a90>] cpu_idle+0x48/0x50
 [<80104a60>] cpu_idle+0x18/0x50
 [<801f4980>] idr_cache_ctor+0x0/0xc
 [<80360000>] ip_auto_config_setup+0x64/0x240
 [<803437ac>] start_kernel+0x200/0x2c0
 [<803430fc>] unknown_bootoption+0x0/0x310

Might not be a MIPS related problem though.  Seems line 140 is
"WARN_ON(irqs_disabled());" which is at the beginning of
local_bh_enable.  Cheers.
	Josh Green

---

From: Josh Green <[email-masked]>
Date: Wed, 02 Feb 2005 12:07:48 -0800

> > the other, both cards initialize fine and I get wlan0 and wlan1.

I think I found this bug, and this time its in drivers/pcmcia/ds.c which
surprises me, since I would think it would have been detected sooner.
Here is the patch:

--- ds.c.orig   2005-01-13 06:06:18.000000000 -0800
+++ ds.c        2005-02-02 11:58:29.125469160 -0800
@@ -660,7 +660,7 @@
                        p_dev = pcmcia_get_dev(p_dev);
                        if (!p_dev)
                                continue;
-                       if ((!p_dev->client.state & CLIENT_UNBOUND) ||
+                       if ((!(p_dev->client.state & CLIENT_UNBOUND)) ||
                            (!p_dev->dev.driver)) {
                                pcmcia_put_dev(p_dev);
                                continue;

Best regards,
	Josh Green

---

From: Josh Green <[email-masked]>
Date: Wed, 02 Feb 2005 14:33:17 -0800

Seems the "Badness in local_bh_enable at kernel/softirq.c:140" error I
reported has been fixed (patch that caused the problem was reverted in
bk), here is a reference to this and a patch (had to replace " <at> "
with @ since they got munged by GMANE):

http://article.gmane.org/gmane.linux.kernel/273477

> I'll take a look at this.

I tried ejecting a card and it seemed to work fine.  The oops could have
been related to the ds.c bug.  At any rate, everything seems to be
running great at this point and I have yet to see any other problems.
	Best regards,
	Josh Green

---

From: Pete Popov <[email-masked]>
Date: Wed, 02 Feb 2005 14:38:26 -0800

> running great at this point and I have yet to see any other problems.

Phew. I hadn't seen these problems and wasn't looking forward more 
pcmcia debug. I'll apply the other patches later. I can't apply the 
ds.c patch though -- that's out of my control. It should go to the 
pcmcia maintainer.

Pete