Re: in-kernel pcmcia oopsing in SMP

[David Gibson <hermes@gibson.dropbear.id.au>]

On Sat, Dec 01, 2001 at 12:46:30PM -0800, David Hinds wrote:
> On Sat, Dec 01, 2001 at 03:27:24PM -0500, Ian Morgan wrote:
> > 
> > > I don't know how to interpret your oops report; you should probably
> > > also forward the bug to David Gibson, hermes@gibson.dropbear.id.au,
> > > since he is the orinoco maintainer.
> > 
> > Well, Gibson's the one who suggested the broblem was with the pcmcia system,
> > and not the orinoco driver! Hmm.... can you say runaround?

Look, I'm not paid to do tech support for you, so there is nothing for
me to gain in trying to give you the runaround.  The orinoco driver is
designed to make hard hangs very unlikely, even at the expense of a
greater chance of the driver operation falling over, so that was by
best initial guess at the problem - albeit possibly a hurried and
inaccurate one (see below).

> It pretty much can't be a PCMCIA subsystem bug.  The basic PCMCIA code
> handles card identification and configuration of the socket; however,
> for almost all cards, the PCMCIA subsystem is completely out of the
> loop during normal card operation.  No PCMCIA code outside of the
> orinoco driver itself will ever be executed.

Hmm... yes, I suppose so.  How odd.

> Your oops, in tasklet code, sounds to me like a locking bug in the
> driver code for managing the transmit stack vs. interrupt handling.
> Have there been reports of the driver working well on SMP boxes?

Well, one of the main features of the driver is that the Tx path and
the interupt handler (Rx path) are permitted to run concurrently.
This is an issue even on UP (although not as complex), since the Rx
patch can interrupt the Tx path.  I believe there has been at least
some successful operation on SMP machines, but unfortunately I don't
know any details.

-- 
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.  -- H.L. Mencken
http://www.ozlabs.org/people/dgibson