Re: tlug: Problems with 3Com 3C575-TX

["Manuel M. T. Chakravarty" <chak@example.com>]

Scott Stone <sstone@example.com> wrote,

> On Mon, 14 Dec 1998, Manuel M. T. Chakravarty wrote:
> 
> > Hi!
> > 
> > I am trying to get 3Com's 3C575-TX FastEthernet CardBus PCMCIA
> > card working in my VAIO PC-505 notebook.  I am running
> > TurboLinux 3.0J's APM kernel version 2.0.36 with
> > kernel-pcmcia-cs version 3.0.6.
> > 
> > When I put the card in the slot, it is recognized,
> > initialized, and the network settings are correctly set up.
> > I can ping the card with its own IP address, but I cannot
> > reach anything else.  Even worse when I eject the card, the
> > PCMCIA software is in a strange state and doesn't accept any 
> > other (non-CardBus) cards anymore; and if I try, it sometimes 
> > locks up the whole machine.
> > 
> > The driver is Donald Becker's 3c575_cb version 0.99H from 11/17/98.
> > 
> > I am pretty sure it is a interrupt problem for two reasons:
> > 
> > (1) Sometimes when I try to access the network via the
> >     CardBus card I get a message in /var/log/messages saying
> >     `Interrupt posted but not delivered -- IRQ blocked by
> >     another device?'
> 
> after loading the card, cat /var/run/stab - what IRQ is it using?  You can
> edit the stuff under /etc/pcmcia to tell it to exclude certain IRQs as
> well.

Hmmm, /var/run/stab doesn't list the IRQ as far as I see,
but according to /proc/interrupts IRQ 10 is used.  

> > Chris Sekiya <chris@example.com> wrote,
> > 
> > > On Mon, 14 Dec 1998, Manuel M. T. Chakravarty wrote:
> > > 
> > > > However, the interrupt that is assigned to the card (IRQ 10) 
> > > > is *free* - it is used sucessfully by my older non-CardBus
> > > > PCMCIA Ethernet card.
> > > 
> > > Isn't IRQ10 commonly used by PCMCIA host adaptors?  ISTR that my
> > > (currently dead) laptop's Cirrus controller sat at IRQ10.
> > 
> > Hmm, but then it shouldn't work with the other card also,
> > should't it?  Anyway, thanks for the comment, I will check
> > that again!
> 
> BTW, David Hinds, author of pcmcia-cs, does respond to email usually.  I
> say though that you should try telling it to exclude IRQ10 just in case.

I tried it.  Then, IRQ 11 is used with identical results.

However, I made some more experiments, which gave some vage
clues:

(1) I could reproduce the fatal freezing of the machine.  It 
    happens if I insert the CardBus card again after ejecting 
    it once.

(2) Similarly, whenever I insert the non-CardBus PCMCIA card 
    after I ejected the CardBus card, the machine also
    freezes, but unlocks when ejecting the card again (this
    is not the case for (1)).

So, ejecting the CardBus card leaves the machine in a
strange state.  

(3) After suspending and reactivating the machine, the
    strange state is still present, *but* after hibernation, 
    the machine seems to be reset and the non-CardBus card
    works again.

This can have two reasons:

(a) The strange state is `stored' in the hardware, which is
    of course fully reset after hibernation or

(b) the strange state is in a part of the software that goes
    through an additional resume cycle after a hibernation.

I think the PCMCIA hardware is already powered down during a
suspend and it doesn't seem very likely that any other part of
the hardware stores the strange state, right?  This leaves
us mainly with `ds.c' and `pcmcia_core.c' (all other related
modules are unloaded when I eject the CardBus card) - and
the (scary) possibility that some kernel table is screwed up 
(if so, probably due to a bug in a module and not the kernel 
itself).

Does anybody know whether anything (maybe in the kernel) is
reset after hibernation - cf. reason (b) above?

A brief look into `ds.c' suggests that it doesn't make a
distinction between CardBus and non-CardBus cards.
Furthermore, the actual card driver communicates with the
rest of the PCMCIA modules only via the `cb_enabler' module
(judging from `lsmod').  Hmmm, it looks like maybe the
`cb_enabler' module triggers an event that then screws
something up in `pcmcia_core'...does this make sense?

Any ideas apart from compiling the modules with debugging
enabled?

Anyhow, thanks for listening...aehmm...reading.  It is late
now and I go to bed,

Manuel

P.S.: Interesting aside: `cb_enabler.c' can be compiled not
      only for Linux, but also for BeOS (if we believe the
      preprocessor directives)...maybe that is the reason
      why pcmcia-cs comes with the MPL and not the GPL...
------------------------------------------------------------------
Next Nomikai: 15 January 1999, 19:30 Tengu TokyoEkiMae 03-3275-3691
Next Technical Meeting: 13 February, 12:30               Place: TBD
------------------------------------------------------------------
more info: http://tlug.linux.or.jp                     Sponsor: PHT