[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-atm
Subject:    Possible bug /omission in IA 5575 driver
From:       Mike Westall <westall () cs ! clemson ! edu>
Date:       2000-12-27 19:14:05
[Download RAW message or body]

Anne Atkinson has pointed out what appears to me to be a
couple of problems living in the 5575 driver:

1) In IaFrontEndIntr() at line 847 there is a line that
   says: 
        else if (iadev->phy_type & FE_E3_PHY) 
        {
   Her phy_type is 1 (SMF) not 9 (FE_E3_PHY) but because
   there is an & not an == the code "acts like" its an
   E3 with a 7345 instead of OC-3C SMF. Is this right???

2) She is also getting a stream of ints with the master 
   interrupt status stuck on 0x8 (assuming OC-3 SMF suni)
   which would be an RACP intr (some sort of failure to sync)
   It would be nice to report this, turn off the board, 
   and exit gracefully (instead of crashing the system ;-)) 

Mike


AAtkinson@verilink.com wrote:
> 
> whoops --
> since the phy_type path taken in IaFrontEndIntr() is FE_E3_PHY, that left
> suni uninitialized when i was printing out the master interrupt status
> value
> (so scratch that 0xA000).  i added the line:
>    suni = (IA_SUNI *)iadev->phy;
> to initialize it, and what the master interrupt status really is is
> 0xFF88 the first time through, and 0xFF08 subsequently...
> Is there some documentation i could get that outlines the valid / expected
> values for the master interrupt status?  i apologize if that's a dumb
> question
> and i already have that in some of what i've downloaded already -- i'll
> hunt through what i've got and look...
> -anne
> 
> Sent by:        owner-linux-atm@lrc.epfl.ch
> To:     Mike Westall <westall@cs.clemson.edu>
> cc:     linux-atm@lrc.epfl.ch
> Subject:        Re: having problems bringing up Interphase 5575's under
> Linux
> 
> The value of iadev->phy_type in IaFrontEndIntr() is 0x10 (hex) --
> so that's singlemode, right?  (FE_SINGLE_MODE in iphase.h)?
> Thanks for the suggestion for looking at the master interrupt value --
> it's 0xA000 -- I'm not sure what that means _yet_, but you've given
> me a direction to go hunting in -- thank YOU!!!  :)
> As per having the SMF plugged into SMF -- what i've got is two
> P133's, each with an Interphase 5575-009 PCI ATM adapter;
> i've got 'em hooked up back-to-back with an SC duplex connector
> single mode 8.5/125 fiber patch cord.  That should be okay,
> shouldn't it?
> Great suggestion on getting the M$ drivers and trying this out on
> a windows box to verify the boards -- die-hard that i am i think i'll try
> investigating a bit to understand the driver under Linux a bit more,
> then go for that....
> Thanks Mike -- you've helped a lot.
> -anne
> PS --
> i hope everyone had / is having wonderful holidays!
> and if i may, i'd like to nominate myself for "stupid newby of the
> year" for 2000 for setting up the single mode fiber adapters with
> multimode fiber patch cords to start with -- gosh did i feel stupid
> when i figured THAT out!!!  ;-)  :-)  :-)
> 
> Sent by:        westall@cs.clemson.edu
> To:     AAtkinson@verilink.com, linux-atm@lrc.epfl.ch
> cc:
> Subject:        Re: having problems bringing up Interphase 5575's under
> Linux
> What is the value (in hex or decimal.. but tell me
> which ) of iadev->phy_type in IaFrontEndIntr()?
> ------
> I would also definitely recommend inserting (right BEFORE
> the
>    if (iadev->carrier_detect)
> statement near the end of the FrontEnd interrupt routine:
>    intr_status = suni->suni_master_intr_stat & 0xffff;
>    printk("Master int was %x \n", intr_status);
> It looks to me like the IA_5575 driver handles
> ONLY RSOP FE interrupts and doesn't bother to check
> for or clear TACP,RACP, RPOP, or RLOPs etc.. My guess
> is that most of the time these other guys don't
> happen but it definitely looks to me like if
> you EVER got ONE you would end up with an
> infinite stream of them!! (Since I don't have the
> board, I can't tell... maybe Peter could comment
> on this... (The solaris driver reads the suni_master_intr_stat
> on EVERY FE interrupt for an OC-3 interface)).
> -----
> The other thing I would suggest is that you secure
> the M$ drivers from Interphase, put the board in
> a Win machine and see what happens.  If it works,
> you definitely don't have a hardware problem.
> Mike

[prev in list] [next in list] [prev in thread] [next in thread]