Now, I should really wait for the card to interrupt me and tell me
that everything is ok with my command, but calling any type of
scheduling panics the kernel (i.e. interruptible_sleep_on_timeout,
schedule etc.)
The questions is, have I screwed up (highly likely) or is the
kernel in the middle of something clever that doesn't like to be
scheduled. If so, I'll have to poll the registers to see when they
are set, which I really don't want to do.
Look at the sunlance.c driver for example, same problem. You create a
timer for the device which goes off periodically later when you need
to wait for the card to be "ready" before you change the multicast
settings.
set_multicast_list can be called from interrupts now, this is why the
kernel is panic'ing on you, you cannot sleep inside of an interrupt.
Later,
David S. Miller
davem@redhat.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/