[2.6.0-test1] yenta_socket.c:yenta_get_status returns bad value compared to 2.4

[2.6.0-test1] yenta_socket.c:yenta_get_status returns bad value compared to 2.4

[Stefan Jones]

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

Re: [2.6.0-test1] yenta_socket.c:yenta_get_status returns bad value compared to 2.4

[OSDL]

Stefan Jones wrote:
>
> 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;

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

Re: [2.6.0-test1] yenta_socket.c:yenta_get_status returns bad value compared to 2.4

[Stefan Jones]

OSDL wrote:
> 
> 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? 
> 
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

Re: [2.6.0-test1] yenta_socket.c:yenta_get_status returns bad value compared to 2.4

[Russell King]

On Sat, Jul 26, 2003 at 07:31:59PM +0100, Stefan Jones wrote:
> 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 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: <20030802173352.A1895@flint.arm.linux.org.uk>

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [2.6.0-test1] yenta_socket.c:yenta_get_status returns bad value compared to 2.4

[Stefan Jones]

On Sat, 2003-08-02 at 18:08, Russell King wrote:
> On Sat, Jul 26, 2003 at 07:31:59PM +0100, Stefan Jones wrote:
> > 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 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: <20030802173352.A1895@flint.arm.linux.org.uk>

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 <hermes@gibson.dropbear.id.au> and others)
orinoco_cs.c 0.13e (David Gibson <hermes@gibson.dropbear.id.au> 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

Re: [2.6.0-test1] yenta_socket.c:yenta_get_status returns bad value compared to 2.4

[Russell King]

On Sun, Aug 03, 2003 at 12:07:41PM +0100, Stefan Jones wrote:
> Linux Kernel Card Services 3.1.22
>   options:  [pci] [cardbus] [pm]
> Yenta IRQ list 0038, PCI irq11
> Socket status: 30000417

No card inserted.

> 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

This is a removal event.

> parse_events: socket d080002c thread ce4db3c0 events 00000080
> yenta_get_status: status=30000411
> socket d080002c status 000000c1

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 (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [2.6.0-test1] yenta_socket.c:yenta_get_status returns bad value compared to 2.4

[Stefan Jones]

On Sun, 2003-08-03 at 13:50, Russell King wrote:

> 
> 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?

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 <hermes@gibson.dropbear.id.au> and others)
orinoco_cs.c 0.13e (David Gibson <hermes@gibson.dropbear.id.au> 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 ..... ]