Menu
▾
▴
linux-atm-general — General discussion of ATM networking under linux
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(25) |
Oct
(110) |
Nov
(138) |
Dec
(146) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(221) |
Feb
(154) |
Mar
(113) |
Apr
(84) |
May
(79) |
Jun
(114) |
Jul
(148) |
Aug
(197) |
Sep
(76) |
Oct
(116) |
Nov
(88) |
Dec
(58) |
| 2002 |
Jan
(69) |
Feb
(77) |
Mar
(41) |
Apr
(52) |
May
(80) |
Jun
(129) |
Jul
(54) |
Aug
(38) |
Sep
(50) |
Oct
(69) |
Nov
(39) |
Dec
(59) |
| 2003 |
Jan
(42) |
Feb
(67) |
Mar
(82) |
Apr
(87) |
May
(38) |
Jun
(74) |
Jul
(56) |
Aug
(99) |
Sep
(201) |
Oct
(73) |
Nov
(15) |
Dec
(55) |
| 2004 |
Jan
(67) |
Feb
(54) |
Mar
(73) |
Apr
(67) |
May
(13) |
Jun
(33) |
Jul
(35) |
Aug
(18) |
Sep
(11) |
Oct
(18) |
Nov
(8) |
Dec
(21) |
| 2005 |
Jan
(66) |
Feb
(20) |
Mar
(26) |
Apr
(56) |
May
(39) |
Jun
(16) |
Jul
(21) |
Aug
(32) |
Sep
(33) |
Oct
(55) |
Nov
(126) |
Dec
(8) |
| 2006 |
Jan
(7) |
Feb
(11) |
Mar
|
Apr
(15) |
May
(17) |
Jun
(4) |
Jul
(7) |
Aug
(12) |
Sep
(18) |
Oct
(30) |
Nov
(12) |
Dec
(12) |
| 2007 |
Jan
(6) |
Feb
(20) |
Mar
(16) |
Apr
(20) |
May
(14) |
Jun
(12) |
Jul
(5) |
Aug
(20) |
Sep
(17) |
Oct
(2) |
Nov
|
Dec
(10) |
| 2008 |
Jan
(1) |
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
(17) |
Jul
(32) |
Aug
(8) |
Sep
(3) |
Oct
(4) |
Nov
(4) |
Dec
(6) |
| 2009 |
Jan
|
Feb
(12) |
Mar
(10) |
Apr
|
May
(1) |
Jun
|
Jul
(8) |
Aug
(11) |
Sep
(6) |
Oct
(6) |
Nov
(5) |
Dec
|
| 2010 |
Jan
|
Feb
(3) |
Mar
(1) |
Apr
(2) |
May
(7) |
Jun
(14) |
Jul
(60) |
Aug
(39) |
Sep
(41) |
Oct
(4) |
Nov
|
Dec
(29) |
| 2011 |
Jan
(15) |
Feb
(3) |
Mar
(37) |
Apr
(5) |
May
(3) |
Jun
|
Jul
(15) |
Aug
(16) |
Sep
|
Oct
(7) |
Nov
(10) |
Dec
(2) |
| 2012 |
Jan
(3) |
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
(1) |
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(2) |
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(9) |
Aug
(10) |
Sep
|
Oct
|
Nov
(2) |
Dec
(3) |
| 2015 |
Jan
(6) |
Feb
|
Mar
(4) |
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
(5) |
Oct
(1) |
Nov
|
Dec
(2) |
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Guy E. <gu...@tr...> - 2010-08-11 21:35:27
|
Hi again, PPPoA is described in the driver README file.... <snip> For PPPoA (RFC2364)... $ modprobe atm $ modprobe pppoatm $ insmod solos-pci.ko $ pppd plugin pppoatm.so 0.0.38 user test password test noauth </snip> In the above example the PVC (VPI/VCI) is 0/38 - this may be different for your provider. - Guy. On 9/08/2010 8:00 AM, Philip Prindeville wrote: > Hi. > > I've been successfully using a Solos PCI card for PPPoE in Qwestland, but have been moved to a different DSLAM (well, remote terminal really) and now have to use PPPoA. > > Anyone able to point me at setup instructions for that? > > Thanks, > > -Philip > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Linux-atm-general mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-atm-general > > -- Guy Ellis gu...@tr... http://www.traverse.com.au Skype: guy.ellis1 Tel: +613 9386 4430 Fax: +613 9386 4435 |
|
From: Guy E. <gu...@tr...> - 2010-08-11 21:35:07
|
Hi Philip, What version does soloscli report? - Guy. On 10/08/2010 3:28 PM, Philip Prindeville wrote: > I've tried both the canned soloscli sources in the tarball and the latest SVN version (r26), and both get the same result: > > # soloscli -s 0 SupportedAnnexes T1.413A > Error. No response from modem > # > > anyone else seeing anything similar? > > At boot I was seeing: > > Solos PCI Driver Version 0.11 svn-25 > solos 0000:00:0e.0: Solos FPGA Version 0.03 svn-37 > solos 0000:00:0e.0: Registered ATM device 0 > solos 0000:00:0e.0: Registered ATM device 1 > solos 0000:00:0e.0: Received packet for unknown VCI.VPI 0.0 on port 0 > Error. No response from modem > Error. No response from modem > Sequence incorrect. > Expected x1499, buffer was: > > o data. > > Error. No response from modem > > > Thanks. > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Linux-atm-general mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-atm-general > > -- Guy Ellis gu...@tr... http://www.traverse.com.au Skype: guy.ellis1 Tel: +613 9386 4430 Fax: +613 9386 4435 |
|
From: Philip P. <phi...@re...> - 2010-08-10 05:29:14
|
I've tried both the canned soloscli sources in the tarball and the latest SVN version (r26), and both get the same result: # soloscli -s 0 SupportedAnnexes T1.413A Error. No response from modem # anyone else seeing anything similar? At boot I was seeing: Solos PCI Driver Version 0.11 svn-25 solos 0000:00:0e.0: Solos FPGA Version 0.03 svn-37 solos 0000:00:0e.0: Registered ATM device 0 solos 0000:00:0e.0: Registered ATM device 1 solos 0000:00:0e.0: Received packet for unknown VCI.VPI 0.0 on port 0 Error. No response from modem Error. No response from modem Sequence incorrect. Expected x1499, buffer was: o data. Error. No response from modem Thanks. |
|
From: Philip P. <phi...@re...> - 2010-08-10 01:15:45
|
On 5/21/10 7:08 AM, Chas Williams (CONTRACTOR) wrote: > In message<4BF...@le...>,Nicolas Michel writes: >> And the ones I found are very old. > the atm utilities havent changed much so these might still be ok. > >> So I wanted to ask you some questions : >> - is there somewhere a howto up-to-date about ATM configuration? > not really. this is on the todo list, but i dont use atm over dsl. > >> - on a hardware point of view, what do I need : >> - what kind of modem? >> - by which media that modem should talk to the linux? USB? RJ-45? >> Other? > i typically deal with optical connections so i dont have any good > advice here. i suspect you would need an adapter with dsl support. > (i.e. atm/dsl). here in the US, it would be delivered over rj-11. > there are a couple atm/dsl adapters supported in linux. Of those adapters, which of them expose themselves as real ATM interfaces, and not as Ethernet bridges to ATM? A lot of adapters, including the Solos, are a "bridge-on-a-board" type design, which I'm not a big fan of, in part because the dumbed-down abstraction hides from you a lot of the useful instrumentation on the device... The Solos, for instance, doesn't log to dmesg when it loses sync or gets a bit error, etc. >> My particular case : I have a Belgacom Office line (Belgium) which is in >> ATM. I want my linux having the public IP configured directly on an >> interface of my linux. > as for the software side, i think you would be using pppoatm or possibly > brctl. the hard part might be figuring out what vpi/vci is used by > your network provider. typically its 8.35 in the US. again, no idea > what they might use in belgium. Ok, this through me for a loop. If you're using br2684ctl then it creates the device nas0 for you. But if you're not using it, what is the name of the device that gets passed to pppoatm? I don't see anything being auto-created. |
|
From: Nathan W. <na...@tr...> - 2010-08-09 00:23:22
|
On Sun, 2010-08-08 at 15:00 -0700, Philip Prindeville wrote: > Hi. > > I've been successfully using a Solos PCI card for PPPoE in Qwestland, but have been moved to a different DSLAM (well, remote terminal really) and now have to use PPPoA. > > Anyone able to point me at setup instructions for that? Load the solos-pci module pppd plugin pppoatm.so 0.8.35 user test password test noauth (port 0, vpi = 8, vci = 35) There is a README: http://openadsl.svn.sourceforge.net/viewvc/openadsl/solos-pci/trunk/README Nathan |
|
From: Nathan W. <na...@tr...> - 2010-08-09 00:19:40
|
On Sun, 2010-08-08 at 14:55 -0700, Philip Prindeville wrote: > Speaking of which, can we remove ppp from there, as it's 2.4.2b3a and 2.4.5 is out? > Thanks Philip, I've removed ppp from http://sourceforge.net/projects/openadsl/files/ Nathan |
|
From: Philip P. <phi...@re...> - 2010-08-08 22:00:25
|
Hi. I've been successfully using a Solos PCI card for PPPoE in Qwestland, but have been moved to a different DSLAM (well, remote terminal really) and now have to use PPPoA. Anyone able to point me at setup instructions for that? Thanks, -Philip |
|
From: Philip P. <phi...@re...> - 2010-08-08 21:55:43
|
Speaking of which, can we remove ppp from there, as it's 2.4.2b3a and 2.4.5 is out? On 5/20/10 5:00 PM, Guy Ellis wrote: > Hi Nicolas, > > If you take a look at the documentation for the Solos-PCI driver you > will find some useful hints... > > http://sourceforge.net/projects/openadsl/files/ > > Kind regards, > > - Guy. > > On 20/05/2010 6:46 PM, Nicolas Michel wrote: >> Hello, >> >> I'll need to use and configure an ATM connection on a linux Debian. I >> never did it and it seems that there are not so many howto on the net. >> And the ones I found are very old. >> >> So I wanted to ask you some questions : >> - is there somewhere a howto up-to-date about ATM configuration? >> - on a hardware point of view, what do I need : >> - what kind of modem? >> - by which media that modem should talk to the linux? USB? RJ-45? >> Other? >> >> My particular case : I have a Belgacom Office line (Belgium) which is in >> ATM. I want my linux having the public IP configured directly on an >> interface of my linux. >> >> Thank you so much for your help, >> nm |
|
From: David W. <dw...@in...> - 2010-08-06 16:58:13
|
We were seeing faults in the solos-pci receive tasklet when packets
arrived for a VCC which was currently being closed:
[18842.727906] EIP: [<e082f490>] br2684_push+0x19/0x234 [br2684] SS:ESP 0068:dfb89d14
[18845.090712] [<c13ecff3>] ? do_page_fault+0x0/0x2e1
[18845.120042] [<e082f490>] ? br2684_push+0x19/0x234 [br2684]
[18845.153530] [<e084fa13>] solos_bh+0x28b/0x7c8 [solos_pci]
[18845.186488] [<e084f711>] ? solos_irq+0x2d/0x51 [solos_pci]
[18845.219960] [<c100387b>] ? handle_irq+0x3b/0x48
[18845.247732] [<c10265cb>] ? irq_exit+0x34/0x57
[18845.274437] [<c1025720>] tasklet_action+0x42/0x69
[18845.303247] [<c102643f>] __do_softirq+0x8e/0x129
[18845.331540] [<c10264ff>] do_softirq+0x25/0x2a
[18845.358274] [<c102664c>] _local_bh_enable_ip+0x5e/0x6a
[18845.389677] [<c102666d>] local_bh_enable+0xb/0xe
[18845.417944] [<e08490a8>] ppp_unregister_channel+0x32/0xbb [ppp_generic]
[18845.458193] [<e08731ad>] pppox_unbind_sock+0x18/0x1f [pppox]
This patch uses an RCU-inspired approach to fix it. In the RX tasklet's
find_vcc() function we first refuse to use a VCC which already has the
ATM_VF_READY bit cleared. And in the VCC close function, we synchronise
with the tasklet to ensure that it can't still be using the VCC before
we continue and allow the VCC to be destroyed.
Signed-off-by: David Woodhouse <Dav...@in...>
Tested-by: Nathan Williams <na...@tr...>
Cc: st...@ke...
---
Nathan, you probably still ought to work out why your customer's setup
keeps disconnecting and closing the connection -- under normal operation
on a stable DSL line, this race should almost never have been triggered.
diff --git a/drivers/atm/solos-pci.c b/drivers/atm/solos-pci.c
index c5f5186..a73f102 100644
--- a/drivers/atm/solos-pci.c
+++ b/drivers/atm/solos-pci.c
@@ -774,7 +774,8 @@ static struct atm_vcc *find_vcc(struct atm_dev *dev, short vpi, int vci)
sk_for_each(s, node, head) {
vcc = atm_sk(s);
if (vcc->dev == dev && vcc->vci == vci &&
- vcc->vpi == vpi && vcc->qos.rxtp.traffic_class != ATM_NONE)
+ vcc->vpi == vpi && vcc->qos.rxtp.traffic_class != ATM_NONE &&
+ test_bit(ATM_VF_READY, &vcc->flags))
goto out;
}
vcc = NULL;
@@ -900,6 +901,10 @@ static void pclose(struct atm_vcc *vcc)
clear_bit(ATM_VF_ADDR, &vcc->flags);
clear_bit(ATM_VF_READY, &vcc->flags);
+ /* Hold up vcc_destroy_socket() (our caller) until solos_bh() in the
+ tasklet has finished processing any incoming packets (and, more to
+ the point, using the vcc pointer). */
+ tasklet_unlock_wait(&card->tlet);
return;
}
--
David Woodhouse Open Source Technology Centre
Dav...@in... Intel Corporation
|
|
From: Chas W. (CONTRACTOR) <ch...@cm...> - 2010-08-06 04:56:32
|
ask mike said, for aal5 the last cell in the pdu (which is indicated via the pti bits as i recall) will contain the complete aal5 trailer -- padding the pdu so that the trailer will appear in the last 8 bytes of the last cell. this website has some diagrams of these layouts: http://www.protocols.com/pbook/atm.htm generally, the atm hardware will deliver either a full pdu to you or fragments of the pdu as its arrives. if you get fragments you need to chain them together until you have a completely assembled pdu. this can be tricky since you dont know the size of the pdu ahead of time since the information is in the trailer. either keep a linked list of these fragments or guess at the size, alloc a skb, and grow (realloc) the skb as necessary to keep appending the data. the assembled pdu should be some multiple of 48. once you have the full pdu, you will find the trailer at the end, so determine the aal5 length, truncate the skb to this length and push the skb into the atm/network layer. you can take a look at the atm he driver, look for the AAL5_LEN() macro. dont forget that this length is big endian -- dont forget to convert to cpu endian before using it. In message <AAN...@ma...>,mahendra varman writes: >I could able to receive all the cells upto last cell. >I do not have a register in the ATM controller indicating the length count >of the received >bytes ( the datasheet claims the length count is done internally and updated >in the last cell) > >I need to remove padding and send only user data to upper layer. > >I have only the last cell buffer address and entire content of the last cell >including padding >and trailer. > >My doubt is Since I do not have the length indicator through some register >how to find the trailer in the entire content of the last cell ? > > > > > >On Thu, Aug 5, 2010 at 8:06 PM, Ashish <wri...@gm...> wrote: > >> And if that kind of register is not there then system should have max >> possible length of buffer (perhaps mtu sized) and then as we get cells we >> put there and when we received last cell of all5 (based on PTI field) we >> remove the padding and send only user data to upper layer. >> >> --Ashish >> >> >> On Thu, Aug 5, 2010 at 7:51 PM, MIke Westall <we...@cs...>wrote: >> >>> I'm not 100% sure what you are asking here. Some NICs (that do SAR) >>> have registers that the driver can read to determine application payload >>> length. At minimum you MUST be able (somehow) to know how many >>> cell's comprise the AAL5 PDU. But once you can do that the rest is >>> trivial.. The CS trailer is always "right" justified in the LAST cell of >>> the >>> PDU. >>> In your second example, 80 byte payload requires two cells. Two cells >>> have payload capacity 96. Thus CRC is at offset 92 with UU at offset 88, >>> CPI at 89 and len at offset 90. >>> Stated another way the 2 byte length field will always be located 6 bytes >>> before the end of the last 48 byte cell. >>> mahendra varman wrote: >>> >>>> Hi >>>> In the ATM driver during reception, I have a doubt in finding the >>>> length of the received bytes. >>>> >>>> 1. If the user send me 40 bytes of data, below is the dump of the >>>> buffer with trailer >>>> >>>> size: 56 getrsmbuffer = cf888000 >>>> >>>> ------------------------------------------------------------------------------------------------------------- >>>> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 >>>> 0x69 0x69 >>>> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 >>>> 0x69 0x69 >>>> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x0 0x0 0x0 0x28 0xdf 0xe9 0x8c >>>> 0x21 >>>> 0xae 0x7b 0x62 0x16 0xce 0xf5 0xf1 0x2f >>>> >>>> 0x0 0x0 0x0 0x28 0xdf 0xe9 0x8c 0x21 = trailer with 0x28 as length >>>> indicator. >>>> >>>> >>>> 2. If the user send me 80 bytes of data, below is the dump of the LAST >>>> buffer with trailer >>>> >>>> size: 56 getrsmbuffer = cf878048 >>>> >>>> --------------------------------------------------------------------------------------------------------------------------- >>>> >>>> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 >>>> 0x69 0x69 >>>> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 >>>> 0x0 0x0 0x0 0x50 0xdc 0x9e 0xca 0xa4 0x0 0x0 0x0 0x0 0x1e 0xd8 0xd2 0xeb >>>> 0xff 0xff 0xff 0xff 0x0 0x0 0x0 0x0 >>>> >>>> 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 = padding data(8 bytes) after >>>> data 0x69 >>>> 0x0 0x0 0x0 0x50 0xdc 0x9e 0xca 0xa4 = trailer with 0x50 as length >>>> indicator >>>> >>>> But, In realtime I do not know how many bytes the user will send to me. >>>> The padding bytes and the trailer area in the last buffer differs >>>> depending on the number of received bytes. I need to get the length >>>> indicator field through some logic irrespective of the number of >>>> received bytes. >>>> >>>> Can you please help me on the above ? >>>> >>>> Mahendra >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> The Palm PDK Hot Apps Program offers developers who use the >>>> Plug-In Development Kit to bring their C/C++ apps to Palm for a share >>>> of $1 Million in cash or HP Products. Visit us here for more details: >>>> http://p.sf.net/sfu/dev2dev-palm >>>> _______________________________________________ >>>> Linux-atm-general mailing list >>>> Lin...@li... >>>> https://lists.sourceforge.net/lists/listinfo/linux-atm-general >>>> >>>> >>>> >>>> >>> >> > >--000e0cd3317ee36175048d1494c9 >Content-Type: text/html; charset=ISO-8859-1 >Content-Transfer-Encoding: quoted-printable > ><br>I could able to receive all the cells upto last cell.<br>I do not have = >a register in the ATM controller indicating the length count of the receive= >d<br>bytes ( the datasheet claims the length count is done internally and u= >pdated in the last cell)<br> ><br>I need to remove padding and send only user data to upper layer.<br><br= >>I have only the last cell buffer address and entire content of the last ce= >ll including padding <br>and trailer.<br><br>My doubt is Since I do not hav= >e the length indicator through some register how to find the trailer in the= > entire content of the last cell ?<br> ><br><br><br><br><br><div class=3D"gmail_quote">On Thu, Aug 5, 2010 at 8:06 = >PM, Ashish <span dir=3D"ltr"><<a href=3D"mailto:writetoashishgupta@gmail= >.com">wri...@gm...</a>></span> wrote:<br><blockquote cla= >ss=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px sol= >id rgb(204, 204, 204); padding-left: 1ex;"> >And if that kind of register is not there then system should have max possi= >ble length of buffer (perhaps mtu sized) and then as we get cells we put th= >ere and when we received last cell of all5 (based on PTI field) we remove t= >he padding and send only user data to upper layer.<br> ><font color=3D"#888888"> ><br>--Ashish</font><div><div></div><div class=3D"h5"><br><br><div class=3D"= >gmail_quote">On Thu, Aug 5, 2010 at 7:51 PM, MIke Westall <span dir=3D"ltr"= >><<a href=3D"mailto:we...@cs..." target=3D"_blank">westall@cs= >.clemson.edu</a>></span> wrote:<br> ><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= >r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> >I'm not 100% sure what you are asking here. =A0 Some NICs (that do SAR)= ><br> >have registers that the driver can read to determine application payload<br= >> >length. =A0 At minimum you MUST be able (somehow) to know how many<br> >cell's comprise the AAL5 PDU. =A0 But once you can do that the rest is<= >br> >trivial.. =A0The CS trailer is always "right" justified in the LA= >ST cell of the<br> >PDU. =A0<br> >In your second example, =A080 byte payload requires two cells. =A0Two cells= ><br> >have payload capacity 96. =A0 Thus CRC is at offset 92 with UU at offset 88= >,<br> >CPI at 89 and len at offset 90. <br> >Stated another way the 2 byte length field will always be located 6 bytes<b= >r> >before the end of the last 48 byte cell. =A0 =A0<br> >mahendra varman wrote:<br> ><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= >r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div></div><= >div> >Hi<br> >In the ATM driver during reception, I have a doubt in finding the<br> >length of the received bytes.<br> ><br> >1. If the user send me 40 bytes of data, below is the dump of the<br> >buffer with trailer<br> ><br> >=A0size: 56 getrsmbuffer =3D cf888000<br> >---------------------------------------------------------------------------= >----------------------------------<br> >0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 = >0x69<br> >0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 = >0x69<br> >0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x0 0x0 0x0 0x28 0xdf 0xe9 0x8c 0x2= >1<br> >0xae 0x7b 0x62 0x16 0xce 0xf5 0xf1 0x2f<br> ><br> >0x0 0x0 0x0 0x28 0xdf 0xe9 0x8c 0x21 =3D trailer with 0x28 as length indica= >tor.<br> ><br> ><br> >2. If the user send me 80 bytes of data, below is the dump of the LAST<br> >buffer with trailer<br> ><br> >=A0size: 56 getrsmbuffer =3D cf878048<br> >=A0------------------------------------------------------------------------= >---------------------------------------------------<br> ><br> >0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 = >0x69<br> >0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0<br> >0x0 0x0 0x0 0x50 0xdc 0x9e 0xca 0xa4 0x0 0x0 0x0 0x0 0x1e 0xd8 0xd2 0xeb<br= >> >0xff 0xff 0xff 0xff 0x0 0x0 0x0 0x0<br> ><br> >0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 =A0 =A0 =A0 =A0 =3D padding data(8 bytes) a= >fter data 0x69<br> >0x0 0x0 0x0 0x50 0xdc 0x9e 0xca 0xa4 =3D =A0trailer with 0x50 as length ind= >icator<br> ><br> >But, In realtime I do not know how many bytes the user will send to me.<br> >The padding bytes and the trailer area in the last buffer differs<br> >depending on the number of received bytes. I need to get the length<br> >indicator field through some logic irrespective of the number of<br> >received bytes.<br> ><br> >Can you please help me on the above ?<br> ><br> >Mahendra<br> ><br></div></div> >---------------------------------------------------------------------------= >---<br> >The Palm PDK Hot Apps Program offers developers who use the<br> >Plug-In Development Kit to bring their C/C++ apps to Palm for a share<br> >of $1 Million in cash or HP Products. Visit us here for more details:<br> ><a href=3D"http://p.sf.net/sfu/dev2dev-palm" target=3D"_blank">http://p.sf.= >net/sfu/dev2dev-palm</a><br> >_______________________________________________<br> >Linux-atm-general mailing list<br> ><a href=3D"mailto:Lin...@li..." target=3D"_blank= >">Lin...@li...</a><br> ><a href=3D"https://lists.sourceforge.net/lists/listinfo/linux-atm-general" = >target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/linux-atm-ge= >neral</a><br> ><br> ><br> > =A0<br> ></blockquote> ></blockquote></div><br> ></div></div></blockquote></div><br> > >--000e0cd3317ee36175048d1494c9-- > |
|
From: MIke W. <we...@cs...> - 2010-08-05 21:45:13
|
Mahendra, While what Ashish and I have said is generally true. There are some special cases that must be accounted for. If a user wants to transmit 92 byte APDU the APDU will fit in two cells but the CS trailer will not. In that case a third cell will be required and the CS trailer will be (as usual) at offset 88 in the third cell and there will be 4 bytes pad in the second cell and 88 bytes pad in the third cell. IN THESE CASES THERE WILL BE NO USER DATA AT ALL IN THE LAST CELL and there may or may not (APDU is multiple of 48 in length) be padding in next to last cell. It takes a only little bit of special case code to handle this situation correctly, but you need to not overlook it. Mike Ashish wrote: > Mahendra, > westall, has given very good example to track length field in aal5 > trailer. > > "In your second example, 80 byte payload requires two cells. Two cells > have payload capacity 96. Thus CRC is at offset 92 with UU at offset 88, > CPI at 89 and len at offset 90. " > > you can check structure of aal5 trailer on net. > other thing is trailer would be last 8 bytes in last cell. so last > cell contains = remaining user bytes + padding + 8B aal5 trailer. > > --Ashish > > On Thu, Aug 5, 2010 at 8:14 PM, mahendra varman > <mah...@gm... <mailto:mah...@gm...>> wrote: > > > I could able to receive all the cells upto last cell. > I do not have a register in the ATM controller indicating the > length count of the received > bytes ( the datasheet claims the length count is done internally > and updated in the last cell) > > I need to remove padding and send only user data to upper layer. > > I have only the last cell buffer address and entire content of the > last cell including padding > and trailer. > > My doubt is Since I do not have the length indicator through some > register how to find the trailer in the entire content of the last > cell ? > > > > > > > On Thu, Aug 5, 2010 at 8:06 PM, Ashish > <wri...@gm... > <mailto:wri...@gm...>> wrote: > > And if that kind of register is not there then system should > have max possible length of buffer (perhaps mtu sized) and > then as we get cells we put there and when we received last > cell of all5 (based on PTI field) we remove the padding and > send only user data to upper layer. > > --Ashish > > > On Thu, Aug 5, 2010 at 7:51 PM, MIke Westall > <we...@cs... <mailto:we...@cs...>> wrote: > > I'm not 100% sure what you are asking here. Some NICs > (that do SAR) > have registers that the driver can read to determine > application payload > length. At minimum you MUST be able (somehow) to know > how many > cell's comprise the AAL5 PDU. But once you can do that > the rest is > trivial.. The CS trailer is always "right" justified in > the LAST cell of the > PDU. > In your second example, 80 byte payload requires two > cells. Two cells > have payload capacity 96. Thus CRC is at offset 92 with > UU at offset 88, > CPI at 89 and len at offset 90. > Stated another way the 2 byte length field will always be > located 6 bytes > before the end of the last 48 byte cell. > mahendra varman wrote: > > Hi > In the ATM driver during reception, I have a doubt in > finding the > length of the received bytes. > > 1. If the user send me 40 bytes of data, below is the > dump of the > buffer with trailer > > size: 56 getrsmbuffer = cf888000 > ------------------------------------------------------------------------------------------------------------- > 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 > 0x69 0x69 0x69 0x69 0x69 > 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 > 0x69 0x69 0x69 0x69 0x69 > 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x0 0x0 0x0 > 0x28 0xdf 0xe9 0x8c 0x21 > 0xae 0x7b 0x62 0x16 0xce 0xf5 0xf1 0x2f > > 0x0 0x0 0x0 0x28 0xdf 0xe9 0x8c 0x21 = trailer with > 0x28 as length indicator. > > > 2. If the user send me 80 bytes of data, below is the > dump of the LAST > buffer with trailer > > size: 56 getrsmbuffer = cf878048 > --------------------------------------------------------------------------------------------------------------------------- > > 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 > 0x69 0x69 0x69 0x69 0x69 > 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x0 0x0 0x0 > 0x0 0x0 0x0 0x0 0x0 > 0x0 0x0 0x0 0x50 0xdc 0x9e 0xca 0xa4 0x0 0x0 0x0 0x0 > 0x1e 0xd8 0xd2 0xeb > 0xff 0xff 0xff 0xff 0x0 0x0 0x0 0x0 > > 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 = padding > data(8 bytes) after data 0x69 > 0x0 0x0 0x0 0x50 0xdc 0x9e 0xca 0xa4 = trailer with > 0x50 as length indicator > > But, In realtime I do not know how many bytes the user > will send to me. > The padding bytes and the trailer area in the last > buffer differs > depending on the number of received bytes. I need to > get the length > indicator field through some logic irrespective of the > number of > received bytes. > > Can you please help me on the above ? > > Mahendra > > ------------------------------------------------------------------------------ > The Palm PDK Hot Apps Program offers developers who > use the > Plug-In Development Kit to bring their C/C++ apps to > Palm for a share > of $1 Million in cash or HP Products. Visit us here > for more details: > http://p.sf.net/sfu/dev2dev-palm > _______________________________________________ > Linux-atm-general mailing list > Lin...@li... > <mailto:Lin...@li...> > https://lists.sourceforge.net/lists/listinfo/linux-atm-general > > > > > > > |
|
From: Ashish <wri...@gm...> - 2010-08-05 18:05:44
|
Mahendra, westall, has given very good example to track length field in aal5 trailer. "In your second example, 80 byte payload requires two cells. Two cells have payload capacity 96. Thus CRC is at offset 92 with UU at offset 88, CPI at 89 and len at offset 90. " you can check structure of aal5 trailer on net. other thing is trailer would be last 8 bytes in last cell. so last cell contains = remaining user bytes + padding + 8B aal5 trailer. --Ashish On Thu, Aug 5, 2010 at 8:14 PM, mahendra varman <mah...@gm...>wrote: > > I could able to receive all the cells upto last cell. > I do not have a register in the ATM controller indicating the length count > of the received > bytes ( the datasheet claims the length count is done internally and > updated in the last cell) > > I need to remove padding and send only user data to upper layer. > > I have only the last cell buffer address and entire content of the last > cell including padding > and trailer. > > My doubt is Since I do not have the length indicator through some register > how to find the trailer in the entire content of the last cell ? > > > > > > > On Thu, Aug 5, 2010 at 8:06 PM, Ashish <wri...@gm...>wrote: > >> And if that kind of register is not there then system should have max >> possible length of buffer (perhaps mtu sized) and then as we get cells we >> put there and when we received last cell of all5 (based on PTI field) we >> remove the padding and send only user data to upper layer. >> >> --Ashish >> >> >> On Thu, Aug 5, 2010 at 7:51 PM, MIke Westall <we...@cs...>wrote: >> >>> I'm not 100% sure what you are asking here. Some NICs (that do SAR) >>> have registers that the driver can read to determine application payload >>> length. At minimum you MUST be able (somehow) to know how many >>> cell's comprise the AAL5 PDU. But once you can do that the rest is >>> trivial.. The CS trailer is always "right" justified in the LAST cell of >>> the >>> PDU. >>> In your second example, 80 byte payload requires two cells. Two cells >>> have payload capacity 96. Thus CRC is at offset 92 with UU at offset >>> 88, >>> CPI at 89 and len at offset 90. >>> Stated another way the 2 byte length field will always be located 6 bytes >>> before the end of the last 48 byte cell. >>> mahendra varman wrote: >>> >>>> Hi >>>> In the ATM driver during reception, I have a doubt in finding the >>>> length of the received bytes. >>>> >>>> 1. If the user send me 40 bytes of data, below is the dump of the >>>> buffer with trailer >>>> >>>> size: 56 getrsmbuffer = cf888000 >>>> >>>> ------------------------------------------------------------------------------------------------------------- >>>> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 >>>> 0x69 0x69 >>>> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 >>>> 0x69 0x69 >>>> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x0 0x0 0x0 0x28 0xdf 0xe9 0x8c >>>> 0x21 >>>> 0xae 0x7b 0x62 0x16 0xce 0xf5 0xf1 0x2f >>>> >>>> 0x0 0x0 0x0 0x28 0xdf 0xe9 0x8c 0x21 = trailer with 0x28 as length >>>> indicator. >>>> >>>> >>>> 2. If the user send me 80 bytes of data, below is the dump of the LAST >>>> buffer with trailer >>>> >>>> size: 56 getrsmbuffer = cf878048 >>>> >>>> --------------------------------------------------------------------------------------------------------------------------- >>>> >>>> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 >>>> 0x69 0x69 >>>> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 >>>> 0x0 0x0 0x0 0x50 0xdc 0x9e 0xca 0xa4 0x0 0x0 0x0 0x0 0x1e 0xd8 0xd2 0xeb >>>> 0xff 0xff 0xff 0xff 0x0 0x0 0x0 0x0 >>>> >>>> 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 = padding data(8 bytes) after >>>> data 0x69 >>>> 0x0 0x0 0x0 0x50 0xdc 0x9e 0xca 0xa4 = trailer with 0x50 as length >>>> indicator >>>> >>>> But, In realtime I do not know how many bytes the user will send to me. >>>> The padding bytes and the trailer area in the last buffer differs >>>> depending on the number of received bytes. I need to get the length >>>> indicator field through some logic irrespective of the number of >>>> received bytes. >>>> >>>> Can you please help me on the above ? >>>> >>>> Mahendra >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> The Palm PDK Hot Apps Program offers developers who use the >>>> Plug-In Development Kit to bring their C/C++ apps to Palm for a share >>>> of $1 Million in cash or HP Products. Visit us here for more details: >>>> http://p.sf.net/sfu/dev2dev-palm >>>> _______________________________________________ >>>> Linux-atm-general mailing list >>>> Lin...@li... >>>> https://lists.sourceforge.net/lists/listinfo/linux-atm-general >>>> >>>> >>>> >>>> >>> >> > |
|
From: mahendra v. <mah...@gm...> - 2010-08-05 15:13:57
|
Hi Mlke Thanks for your Information. My doubt is cleared and I understood the concept Thanks a Lot Mahendra On Thu, Aug 5, 2010 at 8:33 PM, MIke Westall <we...@cs...> wrote: > The full 8 byte trailer is ALWAYS located at offset +40 from start of last > cell. Hence > length is always located at offset +42 from start of last cell (as it was > in your examples). > Mike > > > mahendra varman wrote: > > > I could able to receive all the cells upto last cell. > I do not have a register in the ATM controller indicating the length count > of the received > bytes ( the datasheet claims the length count is done internally and > updated in the last cell) > > I need to remove padding and send only user data to upper layer. > > I have only the last cell buffer address and entire content of the last > cell including padding > and trailer. > > My doubt is Since I do not have the length indicator through some register > how to find the trailer in the entire content of the last cell ? > > > > > > On Thu, Aug 5, 2010 at 8:06 PM, Ashish <wri...@gm...>wrote: > >> And if that kind of register is not there then system should have max >> possible length of buffer (perhaps mtu sized) and then as we get cells we >> put there and when we received last cell of all5 (based on PTI field) we >> remove the padding and send only user data to upper layer. >> >> --Ashish >> >> >> On Thu, Aug 5, 2010 at 7:51 PM, MIke Westall <we...@cs...>wrote: >> >>> I'm not 100% sure what you are asking here. Some NICs (that do SAR) >>> have registers that the driver can read to determine application payload >>> length. At minimum you MUST be able (somehow) to know how many >>> cell's comprise the AAL5 PDU. But once you can do that the rest is >>> trivial.. The CS trailer is always "right" justified in the LAST cell of >>> the >>> PDU. >>> In your second example, 80 byte payload requires two cells. Two cells >>> have payload capacity 96. Thus CRC is at offset 92 with UU at offset >>> 88, >>> CPI at 89 and len at offset 90. >>> Stated another way the 2 byte length field will always be located 6 bytes >>> before the end of the last 48 byte cell. >>> mahendra varman wrote: >>> >>>> Hi >>>> In the ATM driver during reception, I have a doubt in finding the >>>> length of the received bytes. >>>> >>>> 1. If the user send me 40 bytes of data, below is the dump of the >>>> buffer with trailer >>>> >>>> size: 56 getrsmbuffer = cf888000 >>>> >>>> ------------------------------------------------------------------------------------------------------------- >>>> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 >>>> 0x69 0x69 >>>> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 >>>> 0x69 0x69 >>>> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x0 0x0 0x0 0x28 0xdf 0xe9 0x8c >>>> 0x21 >>>> 0xae 0x7b 0x62 0x16 0xce 0xf5 0xf1 0x2f >>>> >>>> 0x0 0x0 0x0 0x28 0xdf 0xe9 0x8c 0x21 = trailer with 0x28 as length >>>> indicator. >>>> >>>> >>>> 2. If the user send me 80 bytes of data, below is the dump of the LAST >>>> buffer with trailer >>>> >>>> size: 56 getrsmbuffer = cf878048 >>>> >>>> --------------------------------------------------------------------------------------------------------------------------- >>>> >>>> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 >>>> 0x69 0x69 >>>> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 >>>> 0x0 0x0 0x0 0x50 0xdc 0x9e 0xca 0xa4 0x0 0x0 0x0 0x0 0x1e 0xd8 0xd2 0xeb >>>> 0xff 0xff 0xff 0xff 0x0 0x0 0x0 0x0 >>>> >>>> 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 = padding data(8 bytes) after >>>> data 0x69 >>>> 0x0 0x0 0x0 0x50 0xdc 0x9e 0xca 0xa4 = trailer with 0x50 as length >>>> indicator >>>> >>>> But, In realtime I do not know how many bytes the user will send to me. >>>> The padding bytes and the trailer area in the last buffer differs >>>> depending on the number of received bytes. I need to get the length >>>> indicator field through some logic irrespective of the number of >>>> received bytes. >>>> >>>> Can you please help me on the above ? >>>> >>>> Mahendra >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> The Palm PDK Hot Apps Program offers developers who use the >>>> Plug-In Development Kit to bring their C/C++ apps to Palm for a share >>>> of $1 Million in cash or HP Products. Visit us here for more details: >>>> http://p.sf.net/sfu/dev2dev-palm >>>> _______________________________________________ >>>> Linux-atm-general mailing list >>>> Lin...@li... >>>> https://lists.sourceforge.net/lists/listinfo/linux-atm-general >>>> >>>> >>>> >>>> >>> >> > ------------------------------ > > ------------------------------------------------------------------------------ > The Palm PDK Hot Apps Program offers developers who use the > Plug-In Development Kit to bring their C/C++ apps to Palm for a share > of $1 Million in cash or HP Products. Visit us here for more details:http://p.sf.net/sfu/dev2dev-palm > > ------------------------------ > > _______________________________________________ > Linux-atm-general mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/linux-atm-general > > |
|
From: MIke W. <we...@cs...> - 2010-08-05 15:03:34
|
The full 8 byte trailer is ALWAYS located at offset +40 from start of last cell. Hence length is always located at offset +42 from start of last cell (as it was in your examples). Mike mahendra varman wrote: > > I could able to receive all the cells upto last cell. > I do not have a register in the ATM controller indicating the length > count of the received > bytes ( the datasheet claims the length count is done internally and > updated in the last cell) > > I need to remove padding and send only user data to upper layer. > > I have only the last cell buffer address and entire content of the > last cell including padding > and trailer. > > My doubt is Since I do not have the length indicator through some > register how to find the trailer in the entire content of the last cell ? > > > > > > On Thu, Aug 5, 2010 at 8:06 PM, Ashish <wri...@gm... > <mailto:wri...@gm...>> wrote: > > And if that kind of register is not there then system should have > max possible length of buffer (perhaps mtu sized) and then as we > get cells we put there and when we received last cell of all5 > (based on PTI field) we remove the padding and send only user data > to upper layer. > > --Ashish > > > On Thu, Aug 5, 2010 at 7:51 PM, MIke Westall > <we...@cs... <mailto:we...@cs...>> wrote: > > I'm not 100% sure what you are asking here. Some NICs (that > do SAR) > have registers that the driver can read to determine > application payload > length. At minimum you MUST be able (somehow) to know how many > cell's comprise the AAL5 PDU. But once you can do that the > rest is > trivial.. The CS trailer is always "right" justified in the > LAST cell of the > PDU. > In your second example, 80 byte payload requires two cells. > Two cells > have payload capacity 96. Thus CRC is at offset 92 with UU > at offset 88, > CPI at 89 and len at offset 90. > Stated another way the 2 byte length field will always be > located 6 bytes > before the end of the last 48 byte cell. > mahendra varman wrote: > > Hi > In the ATM driver during reception, I have a doubt in > finding the > length of the received bytes. > > 1. If the user send me 40 bytes of data, below is the dump > of the > buffer with trailer > > size: 56 getrsmbuffer = cf888000 > ------------------------------------------------------------------------------------------------------------- > 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 > 0x69 0x69 0x69 0x69 0x69 > 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 > 0x69 0x69 0x69 0x69 0x69 > 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x0 0x0 0x0 0x28 > 0xdf 0xe9 0x8c 0x21 > 0xae 0x7b 0x62 0x16 0xce 0xf5 0xf1 0x2f > > 0x0 0x0 0x0 0x28 0xdf 0xe9 0x8c 0x21 = trailer with 0x28 > as length indicator. > > > 2. If the user send me 80 bytes of data, below is the dump > of the LAST > buffer with trailer > > size: 56 getrsmbuffer = cf878048 > --------------------------------------------------------------------------------------------------------------------------- > > 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 > 0x69 0x69 0x69 0x69 0x69 > 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x0 0x0 0x0 0x0 > 0x0 0x0 0x0 0x0 > 0x0 0x0 0x0 0x50 0xdc 0x9e 0xca 0xa4 0x0 0x0 0x0 0x0 0x1e > 0xd8 0xd2 0xeb > 0xff 0xff 0xff 0xff 0x0 0x0 0x0 0x0 > > 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 = padding data(8 > bytes) after data 0x69 > 0x0 0x0 0x0 0x50 0xdc 0x9e 0xca 0xa4 = trailer with 0x50 > as length indicator > > But, In realtime I do not know how many bytes the user > will send to me. > The padding bytes and the trailer area in the last buffer > differs > depending on the number of received bytes. I need to get > the length > indicator field through some logic irrespective of the > number of > received bytes. > > Can you please help me on the above ? > > Mahendra > > ------------------------------------------------------------------------------ > The Palm PDK Hot Apps Program offers developers who use the > Plug-In Development Kit to bring their C/C++ apps to Palm > for a share > of $1 Million in cash or HP Products. Visit us here for > more details: > http://p.sf.net/sfu/dev2dev-palm > _______________________________________________ > Linux-atm-general mailing list > Lin...@li... > <mailto:Lin...@li...> > https://lists.sourceforge.net/lists/listinfo/linux-atm-general > > > > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > The Palm PDK Hot Apps Program offers developers who use the > Plug-In Development Kit to bring their C/C++ apps to Palm for a share > of $1 Million in cash or HP Products. Visit us here for more details: > http://p.sf.net/sfu/dev2dev-palm > ------------------------------------------------------------------------ > > _______________________________________________ > Linux-atm-general mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-atm-general > |
|
From: mahendra v. <mah...@gm...> - 2010-08-05 14:44:13
|
I could able to receive all the cells upto last cell. I do not have a register in the ATM controller indicating the length count of the received bytes ( the datasheet claims the length count is done internally and updated in the last cell) I need to remove padding and send only user data to upper layer. I have only the last cell buffer address and entire content of the last cell including padding and trailer. My doubt is Since I do not have the length indicator through some register how to find the trailer in the entire content of the last cell ? On Thu, Aug 5, 2010 at 8:06 PM, Ashish <wri...@gm...> wrote: > And if that kind of register is not there then system should have max > possible length of buffer (perhaps mtu sized) and then as we get cells we > put there and when we received last cell of all5 (based on PTI field) we > remove the padding and send only user data to upper layer. > > --Ashish > > > On Thu, Aug 5, 2010 at 7:51 PM, MIke Westall <we...@cs...>wrote: > >> I'm not 100% sure what you are asking here. Some NICs (that do SAR) >> have registers that the driver can read to determine application payload >> length. At minimum you MUST be able (somehow) to know how many >> cell's comprise the AAL5 PDU. But once you can do that the rest is >> trivial.. The CS trailer is always "right" justified in the LAST cell of >> the >> PDU. >> In your second example, 80 byte payload requires two cells. Two cells >> have payload capacity 96. Thus CRC is at offset 92 with UU at offset 88, >> CPI at 89 and len at offset 90. >> Stated another way the 2 byte length field will always be located 6 bytes >> before the end of the last 48 byte cell. >> mahendra varman wrote: >> >>> Hi >>> In the ATM driver during reception, I have a doubt in finding the >>> length of the received bytes. >>> >>> 1. If the user send me 40 bytes of data, below is the dump of the >>> buffer with trailer >>> >>> size: 56 getrsmbuffer = cf888000 >>> >>> ------------------------------------------------------------------------------------------------------------- >>> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 >>> 0x69 0x69 >>> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 >>> 0x69 0x69 >>> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x0 0x0 0x0 0x28 0xdf 0xe9 0x8c >>> 0x21 >>> 0xae 0x7b 0x62 0x16 0xce 0xf5 0xf1 0x2f >>> >>> 0x0 0x0 0x0 0x28 0xdf 0xe9 0x8c 0x21 = trailer with 0x28 as length >>> indicator. >>> >>> >>> 2. If the user send me 80 bytes of data, below is the dump of the LAST >>> buffer with trailer >>> >>> size: 56 getrsmbuffer = cf878048 >>> >>> --------------------------------------------------------------------------------------------------------------------------- >>> >>> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 >>> 0x69 0x69 >>> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 >>> 0x0 0x0 0x0 0x50 0xdc 0x9e 0xca 0xa4 0x0 0x0 0x0 0x0 0x1e 0xd8 0xd2 0xeb >>> 0xff 0xff 0xff 0xff 0x0 0x0 0x0 0x0 >>> >>> 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 = padding data(8 bytes) after >>> data 0x69 >>> 0x0 0x0 0x0 0x50 0xdc 0x9e 0xca 0xa4 = trailer with 0x50 as length >>> indicator >>> >>> But, In realtime I do not know how many bytes the user will send to me. >>> The padding bytes and the trailer area in the last buffer differs >>> depending on the number of received bytes. I need to get the length >>> indicator field through some logic irrespective of the number of >>> received bytes. >>> >>> Can you please help me on the above ? >>> >>> Mahendra >>> >>> >>> ------------------------------------------------------------------------------ >>> The Palm PDK Hot Apps Program offers developers who use the >>> Plug-In Development Kit to bring their C/C++ apps to Palm for a share >>> of $1 Million in cash or HP Products. Visit us here for more details: >>> http://p.sf.net/sfu/dev2dev-palm >>> _______________________________________________ >>> Linux-atm-general mailing list >>> Lin...@li... >>> https://lists.sourceforge.net/lists/listinfo/linux-atm-general >>> >>> >>> >>> >> > |
|
From: MIke W. <we...@cs...> - 2010-08-05 14:40:15
|
I'm not 100% sure what you are asking here. Some NICs (that do SAR) have registers that the driver can read to determine application payload length. At minimum you MUST be able (somehow) to know how many cell's comprise the AAL5 PDU. But once you can do that the rest is trivial.. The CS trailer is always "right" justified in the LAST cell of the PDU. In your second example, 80 byte payload requires two cells. Two cells have payload capacity 96. Thus CRC is at offset 92 with UU at offset 88, CPI at 89 and len at offset 90. Stated another way the 2 byte length field will always be located 6 bytes before the end of the last 48 byte cell. mahendra varman wrote: > Hi > In the ATM driver during reception, I have a doubt in finding the > length of the received bytes. > > 1. If the user send me 40 bytes of data, below is the dump of the > buffer with trailer > > size: 56 getrsmbuffer = cf888000 > ------------------------------------------------------------------------------------------------------------- > 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 > 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 > 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x0 0x0 0x0 0x28 0xdf 0xe9 0x8c 0x21 > 0xae 0x7b 0x62 0x16 0xce 0xf5 0xf1 0x2f > > 0x0 0x0 0x0 0x28 0xdf 0xe9 0x8c 0x21 = trailer with 0x28 as length indicator. > > > 2. If the user send me 80 bytes of data, below is the dump of the LAST > buffer with trailer > > size: 56 getrsmbuffer = cf878048 > --------------------------------------------------------------------------------------------------------------------------- > > 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 > 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 > 0x0 0x0 0x0 0x50 0xdc 0x9e 0xca 0xa4 0x0 0x0 0x0 0x0 0x1e 0xd8 0xd2 0xeb > 0xff 0xff 0xff 0xff 0x0 0x0 0x0 0x0 > > 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 = padding data(8 bytes) after data 0x69 > 0x0 0x0 0x0 0x50 0xdc 0x9e 0xca 0xa4 = trailer with 0x50 as length indicator > > But, In realtime I do not know how many bytes the user will send to me. > The padding bytes and the trailer area in the last buffer differs > depending on the number of received bytes. I need to get the length > indicator field through some logic irrespective of the number of > received bytes. > > Can you please help me on the above ? > > Mahendra > > ------------------------------------------------------------------------------ > The Palm PDK Hot Apps Program offers developers who use the > Plug-In Development Kit to bring their C/C++ apps to Palm for a share > of $1 Million in cash or HP Products. Visit us here for more details: > http://p.sf.net/sfu/dev2dev-palm > _______________________________________________ > Linux-atm-general mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-atm-general > > > |
|
From: Ashish <wri...@gm...> - 2010-08-05 14:36:20
|
And if that kind of register is not there then system should have max possible length of buffer (perhaps mtu sized) and then as we get cells we put there and when we received last cell of all5 (based on PTI field) we remove the padding and send only user data to upper layer. --Ashish On Thu, Aug 5, 2010 at 7:51 PM, MIke Westall <we...@cs...> wrote: > I'm not 100% sure what you are asking here. Some NICs (that do SAR) > have registers that the driver can read to determine application payload > length. At minimum you MUST be able (somehow) to know how many > cell's comprise the AAL5 PDU. But once you can do that the rest is > trivial.. The CS trailer is always "right" justified in the LAST cell of > the > PDU. > In your second example, 80 byte payload requires two cells. Two cells > have payload capacity 96. Thus CRC is at offset 92 with UU at offset 88, > CPI at 89 and len at offset 90. > Stated another way the 2 byte length field will always be located 6 bytes > before the end of the last 48 byte cell. > mahendra varman wrote: > >> Hi >> In the ATM driver during reception, I have a doubt in finding the >> length of the received bytes. >> >> 1. If the user send me 40 bytes of data, below is the dump of the >> buffer with trailer >> >> size: 56 getrsmbuffer = cf888000 >> >> ------------------------------------------------------------------------------------------------------------- >> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 >> 0x69 >> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 >> 0x69 >> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x0 0x0 0x0 0x28 0xdf 0xe9 0x8c >> 0x21 >> 0xae 0x7b 0x62 0x16 0xce 0xf5 0xf1 0x2f >> >> 0x0 0x0 0x0 0x28 0xdf 0xe9 0x8c 0x21 = trailer with 0x28 as length >> indicator. >> >> >> 2. If the user send me 80 bytes of data, below is the dump of the LAST >> buffer with trailer >> >> size: 56 getrsmbuffer = cf878048 >> >> --------------------------------------------------------------------------------------------------------------------------- >> >> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 >> 0x69 >> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 >> 0x0 0x0 0x0 0x50 0xdc 0x9e 0xca 0xa4 0x0 0x0 0x0 0x0 0x1e 0xd8 0xd2 0xeb >> 0xff 0xff 0xff 0xff 0x0 0x0 0x0 0x0 >> >> 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 = padding data(8 bytes) after data >> 0x69 >> 0x0 0x0 0x0 0x50 0xdc 0x9e 0xca 0xa4 = trailer with 0x50 as length >> indicator >> >> But, In realtime I do not know how many bytes the user will send to me. >> The padding bytes and the trailer area in the last buffer differs >> depending on the number of received bytes. I need to get the length >> indicator field through some logic irrespective of the number of >> received bytes. >> >> Can you please help me on the above ? >> >> Mahendra >> >> >> ------------------------------------------------------------------------------ >> The Palm PDK Hot Apps Program offers developers who use the >> Plug-In Development Kit to bring their C/C++ apps to Palm for a share >> of $1 Million in cash or HP Products. Visit us here for more details: >> http://p.sf.net/sfu/dev2dev-palm >> _______________________________________________ >> Linux-atm-general mailing list >> Lin...@li... >> https://lists.sourceforge.net/lists/listinfo/linux-atm-general >> >> >> >> > |
|
From: mahendra v. <mah...@gm...> - 2010-08-05 09:08:30
|
Hi In the ATM driver during reception, I have a doubt in finding the length of the received bytes. 1. If the user send me 40 bytes of data, below is the dump of the buffer with trailer size: 56 getrsmbuffer = cf888000 ------------------------------------------------------------------------------------------------------------- 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x0 0x0 0x0 0x28 0xdf 0xe9 0x8c 0x21 0xae 0x7b 0x62 0x16 0xce 0xf5 0xf1 0x2f 0x0 0x0 0x0 0x28 0xdf 0xe9 0x8c 0x21 = trailer with 0x28 as length indicator. 2. If the user send me 80 bytes of data, below is the dump of the LAST buffer with trailer size: 56 getrsmbuffer = cf878048 --------------------------------------------------------------------------------------------------------------------------- 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x50 0xdc 0x9e 0xca 0xa4 0x0 0x0 0x0 0x0 0x1e 0xd8 0xd2 0xeb 0xff 0xff 0xff 0xff 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 = padding data(8 bytes) after data 0x69 0x0 0x0 0x0 0x50 0xdc 0x9e 0xca 0xa4 = trailer with 0x50 as length indicator But, In realtime I do not know how many bytes the user will send to me. The padding bytes and the trailer area in the last buffer differs depending on the number of received bytes. I need to get the length indicator field through some logic irrespective of the number of received bytes. Can you please help me on the above ? Mahendra |
|
From: Nathan W. <na...@tr...> - 2010-07-27 23:28:22
|
On 7/06/2010 8:02 PM, David Woodhouse wrote: > On Wed, 2010-05-26 at 12:16 +0100, David Woodhouse wrote: >> I've had this crash reported to me... >> >> [18842.727906] EIP: [<e082f490>] br2684_push+0x19/0x234 [br2684] >> SS:ESP 0068:dfb89d14 > > Nathan, did you manage to get your customer to confirm that this fixes > the problem? It'd be useful to get this into 2.6.35 and -stable. > I've had confirmation from the customer. The patch fixed his problem. |
|
From: chas w. - C. <ch...@cm...> - 2010-07-09 17:45:26
|
On Fri, 09 Jul 2010 09:48:56 -0700 (PDT) David Miller <da...@da...> wrote: > Which is stupid because it causes one to be able to keep less actual > code on the screen at a time. stupid or not it is preferred. get it changed. |
|
From: chas w. - C. <ch...@cm...> - 2010-07-09 11:16:47
|
On Thu, 08 Jul 2010 21:47:45 -0700 (PDT)
David Miller <da...@da...> wrote:
> From: Karl Hiramoto <ka...@hi...>
> Date: Thu, 8 Jul 2010 10:34:47 +0200
>
> /* Like
> * this.
> */
>
> not:
>
> /*
> * Like
> * this.
> */
>
> Honestly, I don't know how I can be more clear about this :-)
this is somewhat contrary to the suggested multi-line format given in
Documentation/CodingStyle:
The preferred style for long (multi-line) comments is:
/*
* This is the preferred style for multi-line
* comments in the Linux kernel source code.
* Please use it consistently.
*
* Description: A column of asterisks on the left side,
* with beginning and ending almost-blank lines.
*/
|
|
From: Karl H. <ka...@hi...> - 2010-07-09 06:56:12
|
Propagate signal changes to upper atm layer.
Signed-off-by: Karl Hiramoto <ka...@hi...>
---
drivers/usb/atm/ueagle-atm.c | 13 ++++++++++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/atm/ueagle-atm.c b/drivers/usb/atm/ueagle-atm.c
index e213d3f..ebae944 100644
--- a/drivers/usb/atm/ueagle-atm.c
+++ b/drivers/usb/atm/ueagle-atm.c
@@ -575,6 +575,13 @@ MODULE_PARM_DESC(annex,
sc->usbatm->atm_dev->type = val; \
} while (0)
+#define UPDATE_ATM_SIGNAL(val) \
+ do { \
+ if (sc->usbatm->atm_dev) \
+ atm_dev_signal_change(sc->usbatm->atm_dev, val); \
+ } while (0)
+
+
/* Firmware loading */
#define LOAD_INTERNAL 0xA0
#define F8051_USBCS 0x7f92
@@ -1359,7 +1366,7 @@ static int uea_stat_e1(struct uea_softc *sc)
/* always update it as atm layer could not be init when we switch to
* operational state
*/
- UPDATE_ATM_STAT(signal, ATM_PHY_SIG_FOUND);
+ UPDATE_ATM_SIGNAL(ATM_PHY_SIG_FOUND);
/* wake up processes waiting for synchronization */
wake_up(&sc->sync_q);
@@ -1498,7 +1505,7 @@ static int uea_stat_e4(struct uea_softc *sc)
/* always update it as atm layer could not be init when we switch to
* operational state
*/
- UPDATE_ATM_STAT(signal, ATM_PHY_SIG_FOUND);
+ UPDATE_ATM_SIGNAL(ATM_PHY_SIG_FOUND);
/* wake up processes waiting for synchronization */
wake_up(&sc->sync_q);
@@ -1825,7 +1832,7 @@ static int uea_start_reset(struct uea_softc *sc)
* So we will failed to wait Ready CMV.
*/
sc->cmv_ack = 0;
- UPDATE_ATM_STAT(signal, ATM_PHY_SIG_LOST);
+ UPDATE_ATM_SIGNAL(ATM_PHY_SIG_LOST);
/* reset statistics */
memset(&sc->stats, 0, sizeof(struct uea_stats));
--
1.7.1
|
|
From: Karl H. <ka...@hi...> - 2010-07-09 06:56:06
|
Propagate changes to upper atm layer.
Signed-off-by: Karl Hiramoto <ka...@hi...>
---
drivers/atm/suni.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/atm/suni.c b/drivers/atm/suni.c
index da4b91f..41c56ea 100644
--- a/drivers/atm/suni.c
+++ b/drivers/atm/suni.c
@@ -291,8 +291,9 @@ static int suni_ioctl(struct atm_dev *dev,unsigned int cmd,void __user *arg)
static void poll_los(struct atm_dev *dev)
{
- dev->signal = GET(RSOP_SIS) & SUNI_RSOP_SIS_LOSV ? ATM_PHY_SIG_LOST :
- ATM_PHY_SIG_FOUND;
+ atm_dev_signal_change(dev,
+ GET(RSOP_SIS) & SUNI_RSOP_SIS_LOSV ?
+ ATM_PHY_SIG_LOST : ATM_PHY_SIG_FOUND);
}
--
1.7.1
|
|
From: Karl H. <ka...@hi...> - 2010-07-09 06:56:04
|
Propagate signal changes to upper atm layer.
Signed-off-by: Karl Hiramoto <ka...@hi...>
---
drivers/usb/atm/speedtch.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/atm/speedtch.c b/drivers/usb/atm/speedtch.c
index 1335456..80f9617 100644
--- a/drivers/usb/atm/speedtch.c
+++ b/drivers/usb/atm/speedtch.c
@@ -525,7 +525,7 @@ static void speedtch_check_status(struct work_struct *work)
switch (status) {
case 0:
- atm_dev->signal = ATM_PHY_SIG_LOST;
+ atm_dev_signal_change(atm_dev, ATM_PHY_SIG_LOST);
if (instance->last_status)
atm_info(usbatm, "ADSL line is down\n");
/* It may never resync again unless we ask it to... */
@@ -533,12 +533,12 @@ static void speedtch_check_status(struct work_struct *work)
break;
case 0x08:
- atm_dev->signal = ATM_PHY_SIG_UNKNOWN;
+ atm_dev_signal_change(atm_dev, ATM_PHY_SIG_UNKNOWN);
atm_info(usbatm, "ADSL line is blocked?\n");
break;
case 0x10:
- atm_dev->signal = ATM_PHY_SIG_LOST;
+ atm_dev_signal_change(atm_dev, ATM_PHY_SIG_LOST);
atm_info(usbatm, "ADSL line is synchronising\n");
break;
@@ -554,7 +554,7 @@ static void speedtch_check_status(struct work_struct *work)
}
atm_dev->link_rate = down_speed * 1000 / 424;
- atm_dev->signal = ATM_PHY_SIG_FOUND;
+ atm_dev_signal_change(atm_dev, ATM_PHY_SIG_FOUND);
atm_info(usbatm,
"ADSL line is up (%d kb/s down | %d kb/s up)\n",
@@ -562,7 +562,7 @@ static void speedtch_check_status(struct work_struct *work)
break;
default:
- atm_dev->signal = ATM_PHY_SIG_UNKNOWN;
+ atm_dev_signal_change(atm_dev, ATM_PHY_SIG_UNKNOWN);
atm_info(usbatm, "unknown line state %02x\n", status);
break;
}
--
1.7.1
|
|
From: Karl H. <ka...@hi...> - 2010-07-09 06:56:03
|
Propagate signal changes to upper atm layer.
Signed-off-by: Karl Hiramoto <ka...@hi...>
---
drivers/usb/atm/cxacru.c | 18 +++++++++---------
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/atm/cxacru.c b/drivers/usb/atm/cxacru.c
index c89990f..101ffc9 100644
--- a/drivers/usb/atm/cxacru.c
+++ b/drivers/usb/atm/cxacru.c
@@ -866,50 +866,50 @@ static void cxacru_poll_status(struct work_struct *work)
instance->line_status = buf[CXINF_LINE_STATUS];
switch (instance->line_status) {
case 0:
- atm_dev->signal = ATM_PHY_SIG_LOST;
+ atm_dev_signal_change(atm_dev, ATM_PHY_SIG_LOST);
atm_info(usbatm, "ADSL line: down\n");
break;
case 1:
- atm_dev->signal = ATM_PHY_SIG_LOST;
+ atm_dev_signal_change(atm_dev, ATM_PHY_SIG_LOST);
atm_info(usbatm, "ADSL line: attempting to activate\n");
break;
case 2:
- atm_dev->signal = ATM_PHY_SIG_LOST;
+ atm_dev_signal_change(atm_dev, ATM_PHY_SIG_LOST);
atm_info(usbatm, "ADSL line: training\n");
break;
case 3:
- atm_dev->signal = ATM_PHY_SIG_LOST;
+ atm_dev_signal_change(atm_dev, ATM_PHY_SIG_LOST);
atm_info(usbatm, "ADSL line: channel analysis\n");
break;
case 4:
- atm_dev->signal = ATM_PHY_SIG_LOST;
+ atm_dev_signal_change(atm_dev, ATM_PHY_SIG_LOST);
atm_info(usbatm, "ADSL line: exchange\n");
break;
case 5:
atm_dev->link_rate = buf[CXINF_DOWNSTREAM_RATE] * 1000 / 424;
- atm_dev->signal = ATM_PHY_SIG_FOUND;
+ atm_dev_signal_change(atm_dev, ATM_PHY_SIG_FOUND);
atm_info(usbatm, "ADSL line: up (%d kb/s down | %d kb/s up)\n",
buf[CXINF_DOWNSTREAM_RATE], buf[CXINF_UPSTREAM_RATE]);
break;
case 6:
- atm_dev->signal = ATM_PHY_SIG_LOST;
+ atm_dev_signal_change(atm_dev, ATM_PHY_SIG_LOST);
atm_info(usbatm, "ADSL line: waiting\n");
break;
case 7:
- atm_dev->signal = ATM_PHY_SIG_LOST;
+ atm_dev_signal_change(atm_dev, ATM_PHY_SIG_LOST);
atm_info(usbatm, "ADSL line: initializing\n");
break;
default:
- atm_dev->signal = ATM_PHY_SIG_UNKNOWN;
+ atm_dev_signal_change(atm_dev, ATM_PHY_SIG_UNKNOWN);
atm_info(usbatm, "Unknown line state %02x\n", instance->line_status);
break;
}
--
1.7.1
|
34 messages has been excluded from this view by a project administrator.
