PCCARD - interruptible sleep

M. Warner Losh imp at bsdimp.com
Thu Nov 9 14:09:10 UTC 2006


In message: <3bbf2fe10611081130i1e34ab2end66bf238117cfcf8 at mail.gmail.com>
            "Attilio Rao" <attilio at freebsd.org> writes:
: 2006/11/8, Warner Losh <imp at bsdimp.com>:
: > From: "Attilio Rao" <attilio at freebsd.org>
: > Subject: Re: PCCARD - interruptible sleep
: > Date: Wed, 8 Nov 2006 14:43:59 +0100
: >
: > > 2006/11/8, Jacqueline P <jackie7691 at yahoo.com.mx>:
: > > > Hi all
: > > >
: > > >  how can I implement an interruptible sleep within my pccard smart card reader driver like ?
: > > >  For Linux I do this the following way
: > > >
: > > >  // interruptible_pause()
: > > > static inline void ipause(unsigned long amount) {
: > > >  set_current_state(TASK_INTERRUPTIBLE);
: > > >  schedule_timeout(amount);
: > > > }
: > > >
: > > >  and within my driver I use the function DELAY which does a busy wait.
: > > >
: > > >  The problem is, that the driver does not recognize when the pccard is detached during a read / write operation.
: > > >
: > > >  Does the kernel update the struct device_t, so that the driver can use the function device_is_attached() to determine that the device is detached ?
: > >
: > > You can implement a 'dying' flag in your softc structure (and
: > > subsequent macro in order to handle).
: >
: > But that won't tell you if the hardware has disappeared.  Experience
: > has shown that dying isn't such a good idea in many cases and tends to
: > cause more races than it solves.
: 
: Nothing that can't be solved with a softc lock?
: Give an example please.

You are in your ISR with a loop:

	while(sr() & INTR)
		do_interrupt();

if the card is ejected, then sr (the status register) will go all
ones.  This will loop forever.  Since the interrupt for the card
management and for the card isr are shared, so the management
interrupt will be blocked until the ISR returns.  So the detach()
routine never runs, and you never set the 'dying' flag.

There are many other examples.  The real solution is to check to make
sure the hardware is still present by asking the bridge from time to
time and limiting what you do.  A dying flag can be useful in some
cases, but it is naive to think it solves all the problems.  In the
past it was used as such when in fact the drivers that used it were
full of detach races...

Warner




More information about the freebsd-drivers mailing list