Re: Serial cardbus code.... for testing, please.....

["Theodore Y. Ts'o" <tytso@MIT.EDU>]

   Date: Sat, 09 Dec 2000 11:13:59 -0500
   From: Jeff Garzik <jgarzik@mandrakesoft.com>

   > Note how the "rs_interrupt()" routine _tries_ to avoid this by having a
   > pass counter value, but that logic never triggers because we will loop
   > forever in receive_chars(), so the rs_interrupt() counter never even gets
   > to increment.

   Other places in serial.c check for 0xff, which implies we can and should
   do the same in the interrupt handler...

No, other places in the serial driver check for 0xff *after* setting
various registers and clearing various flags.  Those various
initializations are critical before you can simply do a "bail if LSR ==
0xff" check.

It's possible (not very likely, but possible) for LSR to go into
christmas tree mode where all of the flags are set in normal operation.
So for the interrupt driver, we're going to have to do some kind of loop
based thing --- if interrupt driver receives 0xff more than some number
of times, bail.

   I'm starting to think this Ositech Jack of Spades is unusual in some
   way, since your (Linus) BestData card and other serial CardBus cards
   sound like they work.

Well, I'm able to make the Jack of Spades work if everything is compiled
in --- although the networking side of the card seems to deadlock the
kernel if I eject and re-insert the card --- this problem doesn't show
up if I compile the epic100 driver as a module, only when it is compiled
into the kernel.  However, if the 2.4 pcmcia/cardbus drivers are
compiled as modules, *all* serial cards which I've tried, CardBus and
PCMCIA, fail in mostly the same way.

If I disable the kernel PCMCIA drivers, and use the pcmcia-cs drivers
with the 2.4 kernel, they all work fine.  If I use the pcmcia-cs drivers
with the 2.2 kernel, it also works fine.  So starting to look like it's
a very specific set of circumstances where it doesn't work.  It just
happened to be the one which I tried first, since I do like kernel
modules since it's a lot easier to debug things that way....  

						- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/