Re: [Linux-ATM-General] Solos driver weirdness in bridged mode

[Philip P. <phi...@re...>]

On 3/21/11 4:41 AM, chas williams - CONTRACTOR wrote:
> On Sun, 20 Mar 2011 13:34:25 -0700
> Philip Prindeville<phi...@re...>  wrote:
>
>> Ok, so my previous posting fixed the preamble issue...  I'm digging more into the driver and had a few more questions.
>>
>> First, it calls a local (static) function release_vccs(struct atm_dev *dev) but from what I can tell, this is identical to what the function atm_dev_release_vccs(struct atm_dev *dev) does in net/atm/common.c, right?
> appears to be.  this isnt an exported function so the author needed to
> duplicate it to make it work out of tree for his driver.

Yeah, I sent a patch for that.  Hopefully no one has any objections...


>> The function find_vcc() is duplicated (almost verbatim) in solos-pci.c and atmtcp.c ... why not move it into atm/common.c?
> which is also pretty similar to the find_vcc() in he.c as well.  they
> all probably share the same lineage relating to the consolidation of
> the vcc table a while back.
>
>> Getting into /proc/net/atm/ and looking at the files, I get:
>>
>> root@OpenWrt:/proc/1485/net/atm# pwd
>> /proc/net/atm
>> root@OpenWrt:/proc/1485/net/atm# head *
>> ==>   br2684<==
>> dev nas0: num=1, mac=00:0a:fa:22:00:84 (set)
>>     vcc 0.0.35: encaps=LLC payload=bridged, failed copies 0/236
>>
>> ==>   devices<==
>> Itf Type    ESI/"MAC"addr AAL(TX,err,RX,err,drop) ...               [refcnt]
>>     0 solos-pci000000000000  0 ( 0 0 0 0 0 )  5 ( 236 0 0 0 0 )   [2]
>>     1 solos-pci000000000000  0 ( 0 0 0 0 0 )  5 ( 0 0 0 0 0 )     [1]
>>
>> ==>   pvc<==
>> Itf VPI VCI   AAL RX(PCR,Class) TX(PCR,Class)
>>
>> ==>   svc<==
>> Itf VPI VCI           State      Remote
>>
>> ==>   vc<==
>> Address Itf VPI VCI   Fam Flags Reply Send buffer     Recv buffer      [refcnt]
>> root@OpenWrt:/proc/1485/net/atm#
>>
>>
>>
>> so it seems that there really is something broken, at least in that the VPI/VCI failed to get plumbed if it's not showing up in the "vc" file.
> something must be erroring that is causing the socket/vcc to be removed
> from the list.  perhaps release_vccs()?  if you manage to enter
> process_status() before the vcc is in "Showtime" it seems it will be
> dropped regardless of the open status?  i gather that br2684ctl
> probably doesnt reopen the vcc in question (actually i have no idea
> what it does)
>

Yeah, it turns out there was... the transition from UNKNOWN to LOST.

Should we (a) initialize the driver state as LOST, and (b) not release all VCs when the carrier flaps?

I'm thinking that now that we have correct carrier state indication, maybe user-space apps should pay attention to that instead?

-Philip