yenta_socket.c:yenta_get_status returns bad value compared to 2.4

Dear all,

It seems the the change from 2.4 to 2.6 made the state read from yenta_get_status change it's return value. It reads it from hardware.

The change in value has an effect later on which causes CB_CBCARD not to be set, and thus SOCKET_CARDBUS not being set, this memory reads are from the wrong ioport, locking up the machine.

Hardware:
00:0a.0 CardBus bridge: O2 Micro, Inc. OZ6912 Cardbus Controller with a Netgear wireless card for testing.

see http://www.ussg.iu.edu/hypermail/linux/kernel/0307.3/0166.html
for more info.

I added

printk(KERN_DEBUG "yenta_get_status: status=%04x\n",state);

after the call
u32 state = cb_readl(socket, CB_SOCKET_STATE);
in
static int yenta_get_status(struct pcmcia_socket *sock, unsigned int *value)
in drivers/pcmcia/yenta_socket.c

in both 2.4.21 and 2.6.0-test1

2.6.0-test1 gives: 30000411
2.4.21 gives: 30000419

I wonder why the values are different, and yet fairly close. It is enough to give hard lockups ( I debugged this one with printk's and commenting out code )

I have added

state |= CB_CBCARD;

to the 2.6 kernel and that stops lockups, but I haven't yet tried forcing the complete value.

What should I do, who should I contact, please advise. ( I am not a kernel developer )

Stefan

The difference between 2.4 and 2.6 is not CB_CBCARD (0x0020), but CB_PWRCYCLE (0x0008).

For some reason 2.6.x hasn't powered up the 16-bit card.

However, the whole CB_POWERCYCLE thing is ignored for 16-bit cards, and what you end up doing by marking the card as a 32-bit cardbus card (that's what the CB_CBCARD define means) is to basically force the wrong code to be run, at which point the 32-bit code decides that the card isn't powered.

The real question is why the card isn't powered up. Also, it sounds like the 16-bit status (from I365_STATUS) doesn't agree with the 32-bit status (from CB_SOCKET_STATE), so when you _do_ force trusting of the 32-bit status, then things work.

Which is interesting in itself. It's entirely possible that we should just ignore the 16-bit status when it comes to the SS_POWERON logic.

Does the card actually _work_ when you do your hack? Or does it just stop the hang?

Linus

It just stopped the hang, which caused me to think I was onto something.

I will continue my debugging and take this to the pcmcia list,

so far with printk's and early returns I have got the following:

The ds_ioctl's are triggering the hang,

ioctl calls to DS_ADJUST_RESOURCE_INFO and DS_GET_STATUS work fine (all others are quoted out and are not called before the hang )

But the first call to DS_VALIDATE_CIS causes the machine to hang. I have tracked down the hang to

pcmcia_get_first_tuple called from
pcmcia_validate_cis called from
ds_ioctl

in cistpl.c

Will narrow it down some more today.

PS. the card is:
Netgear 802.11b wireless PC card 16-bit PCMCIA MA401 ( which works fine with 2.4.21 )

For you pcmcia ppl:
http://www.ussg.iu.edu/hypermail/linux/kernel/0307.3/0166.html
( hardware details )
http://www.ussg.iu.edu/hypermail/linux/kernel/0307.3/0690.html
( my misdiagnosis )

Any tips, known problem?

Stefan

The get_status function is called multiple times during card initialisation. I doubt that it is valid to compare the get_status values from 2.4 and 2.6 kernels, without examining what's going on in the cs.c code.

It would be helpful if you could apply the patch to cs.c which I've recently posted to lkml, and report back the full kernel messages, including the messages you get from your printk in yenta_get_status().

The message id was: <[email protected]>

Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Ok, here is the result. I had to use "probe_mem=0" to stop my machine hanging ( as I said before).

I started pcmcia
"/etc/init.d/pcmcia start"
I then inserted card for the first time and nothing happened .. removed it and reinserted it was configured fine.

Thanks for your time,

Stefan

Log:

[ Snip .... ]
Linux Kernel Card Services 3.1.22
options: [pci] [cardbus] [pm]
Yenta IRQ list 0038, PCI irq11
Socket status: 30000417
parse_events: socket d080002c thread ce4db3c0 events 00000080
yenta_get_status: status=30000417
socket d080002c status 00000041
cs: IO port probe 0x0c00-0x0cff: clean.
cs: IO port probe 0x0800-0x08ff: clean.
cs: IO port probe 0x0100-0x04ff: excluding 0x2c8-0x2cf 0x378-0x37f 0x3c0-0x3df 0x4d0-0x4d7
cs: IO port probe 0x0a00-0x0aff: clean.
yenta_get_status: status=30000417

**** INSERT card first time nothing gets printed

**** REINSERT card and I get this;

parse_events: socket d080002c thread ce4db3c0 events 00000080
yenta_get_status: status=30000417
socket d080002c status 00000041
parse_events: socket d080002c thread ce4db3c0 events 00000080
yenta_get_status: status=30000411
socket d080002c status 000000c1
socket_insert: skt d080002c
yenta_get_status: status=30000411
socket_setup: skt d080002c status 000000c1
yenta_get_status: status=30000411
socket_reset: skt d080002c
yenta_get_status: status=30000419
yenta_get_status: status=30000419
orinoco.c 0.13e (David Gibson <[email protected]> and others) orinoco_cs.c 0.13e (David Gibson <[email protected]> and others)
eth1: Station identity 001f:0006:0001:0003
eth1: Looks like an Intersil firmware version 1.3.6
eth1: Ad-hoc demo mode supported
eth1: IEEE standard IBSS ad-hoc mode supported
eth1: WEP supported, 104-bit key
eth1: MAC address 00:09:5B:4A:B1:B6
eth1: Station name "Prism I"
eth1: ready
eth1: index 0x01: Vcc 5.0, irq 3, io 0x0100-0x013f

No card inserted.

This is a removal event.

This is an insert event.

Hmm, so it looks like the hardware didn't report an insert event. Can you add a couple of printk()'s to yenta_events() to display the values of cb_event and csc please?

Thanks.

Russell King ([email protected])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

using

printk(KERN_DEBUG"yenta_events: csc= %04x cb_event= %04x\n",csc,cb_event); in yenta_events

I get,

Stefan

Linux Kernel Card Services 3.1.22
options: [pci] [cardbus] [pm]
yenta_events: csc= 0000 cb_event= 0001
yenta_events: csc= 0000 cb_event= 0001
yenta_events: csc= 0000 cb_event= 0001
yenta_events: csc= 0000 cb_event= 0001
yenta_events: csc= 0000 cb_event= 0001
Yenta IRQ list 0038, PCI irq11
Socket status: 30000417
parse_events: socket d56afc2c thread ce4db3c0 events 00000080
yenta_get_status: status=30000417
socket d56afc2c status 00000041
cs: IO port probe 0x0c00-0x0cff: clean.
cs: IO port probe 0x0800-0x08ff: clean.
cs: IO port probe 0x0100-0x04ff: excluding 0x2c8-0x2cf 0x378-0x37f 0x3c0-0x3df 0x4d0-0x4d7
cs: IO port probe 0x0a00-0x0aff: clean.
yenta_get_status: status=30000417

[ Still nothing on first insertion ]

yenta_events: csc= 0000 cb_event= 0006
parse_events: socket d56afc2c thread ce4db3c0 events 00000080
yenta_get_status: status=30000417
socket d56afc2c status 00000041
yenta_events: csc= 0000 cb_event= 0006
parse_events: socket d56afc2c thread ce4db3c0 events 00000080
yenta_get_status: status=30000411
socket d56afc2c status 000000c1
socket_insert: skt d56afc2c
yenta_get_status: status=30000411
socket_setup: skt d56afc2c status 000000c1
yenta_get_status: status=30000411
socket_reset: skt d56afc2c
yenta_get_status: status=30000419
yenta_get_status: status=30000419
orinoco.c 0.13e (David Gibson <[email protected]> and others) orinoco_cs.c 0.13e (David Gibson <[email protected]> and others)
eth1: Station identity 001f:0006:0001:0003
eth1: Looks like an Intersil firmware version 1.3.6
eth1: Ad-hoc demo mode supported
eth1: IEEE standard IBSS ad-hoc mode supported
eth1: WEP supported, 104-bit key
eth1: MAC address 00:09:5B:4A:B1:B6
eth1: Station name "Prism I"
eth1: ready
eth1: index 0x01: Vcc 5.0, irq 3, io 0x0100-0x013f
yenta_events: csc= 0000 cb_event= 0000
[ repeated many times ..... ]