Problem in using PPP & Ethernet Interface together with TCP/IP
Shah, Viral
viral.ashah at patni.com
Thu Mar 3 06:02:15 UTC 2011
Hi Sebastian,
Thanks for your answer. I am sorry there was a typing mistake the structure is actually as below:-
struct rtems_bsdnet_config rtems_bsdnet_config =
{
ð_netdriver_config, /* chained list of network interfaces */
NULL, /* BOOTP */
As shown below we chain the PPP interface in below structure.
static struct rtems_bsdnet_ifconfig eth_netdriver_config =
{
ETH_DEV_NAME, /* name */
&GC_eth_driver_attach, /* attach function */
// Chain the next adaptor:
&ppp_netdriver_config, /* Chain the PPP interface after the ETH adapter */
NULL, /* IP address */
NULL, /* IP net mask */
NULL, /* Driver supplies hardware address */
0 /* Use default driver parameters */
};
Thanks & Regards,
Viral Shah
Specialist(Software) - Product Engineering Services,
Patni Computer Systems Ltd,
IT1/IT2 Patni Knowledge Park (PKP),
Block C, 2nd Floor, Wing A (C2A),
Thane Belapur Road, Airoli,
Navi Mumbai 400 708.
Tel: +91 22 3917 2000 Ext 4203
Tel(Direct): +91 22 3917 4203
Patni Link Line: 9-625-4403
-----Original Message-----
From: rtems-users-bounces at rtems.org [mailto:rtems-users-bounces at rtems.org] On Behalf Of rtems-users-request at rtems.org
Sent: Tuesday, March 01, 2011 8:20 PM
To: rtems-users at rtems.org
Subject: rtems-users Digest, Vol 54, Issue 2
Send rtems-users mailing list submissions to
rtems-users at rtems.org
To subscribe or unsubscribe via the World Wide Web, visit
http://www.rtems.org/mailman/listinfo/rtems-users
or, via email, send a message with subject or body 'help' to
rtems-users-request at rtems.org
You can reach the person managing the list at
rtems-users-owner at rtems.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of rtems-users digest..."
Today's Topics:
1. Re: NULL call to _Workspace_Free() via
_Objects_Extend_information at startup (Sebastian Huber)
2. Re: Problem in using PPP & Ethernet Interface, together, with
TCP/IP (Sebastian Huber)
3. Re: AT91SAM7S256 (Sebastian Huber)
4. Re: NULL call to _Workspace_Free() via
_Objects_Extend_information at startup (Peter Dufault)
5. Re: NULL call to _Workspace_Free() via
_Objects_Extend_information at startup (Peter Dufault)
6. Re: AT91SAM7S256 (Ian Caddy)
7. Re: NULL call to _Workspace_Free() via
_Objects_Extend_information at startup (Chris Johns)
8. RES: RES: RES: Is there any change on interrupt catch between
RTEMS 4.9.4 and 4.10.0? (Fabr?cio de Novaes Kucinskis)
9. ARM - after update from rtems4.9.3 to rtems-4.9.5 Unlimited
Task Test fails (Joachim Rahn)
10. Re: RES: RES: RES: Is there any change on interrupt catch
between RTEMS 4.9.4 and 4.10.0? (Joel Sherrill)
----------------------------------------------------------------------
Message: 1
Date: Tue, 01 Mar 2011 09:56:51 +0100
From: Sebastian Huber <sebastian.huber at embedded-brains.de>
To: Peter Dufault <dufault at hda.com>
Cc: "rtems-users at rtems.org" <rtems-users at rtems.org>
Subject: Re: NULL call to _Workspace_Free() via
_Objects_Extend_information at startup
Message-ID: <4D6CB4D3.7090000 at embedded-brains.de>
Content-Type: text/plain; charset=ISO-8859-1
On 03/01/2011 09:50 AM, Peter Dufault wrote:
> I'm not sure the requirement that "_Heap_Free(heap, NULL)" be ignored makes much sense.
It makes sense in a way that _Heap_Free() accepts in this case all values
returned by _Heap_Allocate_*().
--
Sebastian Huber, embedded brains GmbH
Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone : +49 89 18 90 80 79-6
Fax : +49 89 18 90 80 79-9
E-Mail : sebastian.huber at embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine gesch?ftliche Mitteilung im Sinne des EHUG.
------------------------------
Message: 2
Date: Tue, 01 Mar 2011 10:05:55 +0100
From: Sebastian Huber <sebastian.huber at embedded-brains.de>
To: rtems-users at rtems.org
Subject: Re: Problem in using PPP & Ethernet Interface, together, with
TCP/IP
Message-ID: <4D6CB6F3.3040109 at embedded-brains.de>
Content-Type: text/plain; charset=ISO-8859-1
On 03/01/2011 09:54 AM, Shah, Viral wrote:
[...]
> struct rtems_bsdnet_config rtems_bsdnet_config =
>
> {
>
> &ppp_netdriver_config,
>
> ð_netdriver_config,
>
> NULL, /* BOOTP */
The above is completely wrong. Turn on the warnings. You should remove the
"&ppp_netdriver_config," line.
[...]
--
Sebastian Huber, embedded brains GmbH
Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone : +49 89 18 90 80 79-6
Fax : +49 89 18 90 80 79-9
E-Mail : sebastian.huber at embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine gesch?ftliche Mitteilung im Sinne des EHUG.
------------------------------
Message: 3
Date: Tue, 01 Mar 2011 10:07:08 +0100
From: Sebastian Huber <sebastian.huber at embedded-brains.de>
To: rtems-users at rtems.org
Subject: Re: AT91SAM7S256
Message-ID: <4D6CB73C.5030303 at embedded-brains.de>
Content-Type: text/plain; charset=ISO-8859-1
Hello Tomas,
the csb337 BSP works with an AT91RM9200. I don't know if they are related.
The lpc24xx is a recent ARM7TDMI based BSP.
On 02/28/2011 07:01 PM, Tomas Bures wrote:
> Hello,
>
> I would like to try RTEMS on Lego NXT platform. It uses ARM7TDMI
> processor on Atmel AT91SAM7S256 board. Please is there any BSP for this
> board? Or at least some related, so there is something to start with?
>
> Thank you. Best regards,
> Tomas
>
--
Sebastian Huber, embedded brains GmbH
Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone : +49 89 18 90 80 79-6
Fax : +49 89 18 90 80 79-9
E-Mail : sebastian.huber at embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine gesch?ftliche Mitteilung im Sinne des EHUG.
------------------------------
Message: 4
Date: Tue, 1 Mar 2011 04:10:01 -0500
From: Peter Dufault <dufault at hda.com>
To: Sebastian Huber <Sebastian.Huber at embedded-brains.de>
Cc: "rtems-users at rtems.org" <rtems-users at rtems.org>
Subject: Re: NULL call to _Workspace_Free() via
_Objects_Extend_information at startup
Message-ID: <65B9D2FD-CF1E-4D80-84E7-3335E4B84A7C at hda.com>
Content-Type: text/plain; charset=us-ascii
On Mar 1, 2011, at 3:56 , Sebastian Huber wrote:
>> I'm not sure the requirement that "_Heap_Free(heap, NULL)" be ignored makes much sense.
>
> It makes sense in a way that _Heap_Free() accepts in this case all values
> returned by _Heap_Allocate_*().
Hmm. By that you mean it handles a failure return where _Heap_Allocate_*() couldn't allocate memory or was passed bogus arguments, and the caller didn't check the return code and handle it appropriately? I don't see the advantage of that.
In the malloc() / free() / realloc() case I've always assumed the NULL pointer requirement is so that you can initialize an array of pointers to zero and then use realloc() and free() on them without special testing, not so that you can pass the returned value of a failed malloc() to free().
Peter
-----------------
Peter Dufault
HD Associates, Inc. Software and System Engineering
------------------------------
Message: 5
Date: Tue, 1 Mar 2011 04:15:43 -0500
From: Peter Dufault <dufault at hda.com>
To: "rtems-users at rtems.org List" <rtems-users at rtems.org>
Subject: Re: NULL call to _Workspace_Free() via
_Objects_Extend_information at startup
Message-ID: <1C303889-C3BF-4574-B8C5-048571B44EA3 at hda.com>
Content-Type: text/plain; charset=us-ascii
On Mar 1, 2011, at 3:50 , Peter Dufault wrote:
> Because of the existing design (_Heap_Block_allocate() takes a Heap_Block * not a Heap_Block **) I'm not sure the requirement that "_Heap_Free(heap, NULL)" be ignored makes much sense.
Sorry to be following up to myself. I just noticed that _Heap_Block_allocate() returns a heap block pointer, so it can work the way malloc() does. I thought it just operated on the heap pointer passed in.
Never mind. I personally (almost) never return a pointer but try to always use error returns.
Peter
-----------------
Peter Dufault
HD Associates, Inc. Software and System Engineering
------------------------------
Message: 6
Date: Tue, 01 Mar 2011 17:32:35 +0800
From: Ian Caddy <ianc at goanna.iinet.net.au>
To: rtems-users at rtems.org
Subject: Re: AT91SAM7S256
Message-ID: <4D6CBD33.6090905 at goanna.iinet.net.au>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi All,
We have created a BSP for the Atmel AT91SAM9263 (custom and
AT91SAM9263-EK), which is similar to the AT91RM9200, both these
processors are ARM9 cores.
I think you would be best using the lpc24xx BSP and then looking at the
Atmel BSPs for peripheral code, as the peripherals on the SAM7S are
similar/same as the SAM9263/RM9200.
We know the SAM7S processors quite well as well, but haven't looked at
putting RTEMS on them, as they have a limited amount of RAM.
regards,
Ian Caddy
Goanna Technologies Pty Ltd
On 01/03/11 17:07, Sebastian Huber wrote:
> Hello Tomas,
>
> the csb337 BSP works with an AT91RM9200. I don't know if they are related.
> The lpc24xx is a recent ARM7TDMI based BSP.
>
> On 02/28/2011 07:01 PM, Tomas Bures wrote:
>> Hello,
>>
>> I would like to try RTEMS on Lego NXT platform. It uses ARM7TDMI
>> processor on Atmel AT91SAM7S256 board. Please is there any BSP for this
>> board? Or at least some related, so there is something to start with?
>>
>> Thank you. Best regards,
>> Tomas
>>
>
>
------------------------------
Message: 7
Date: Tue, 01 Mar 2011 21:23:30 +1100
From: Chris Johns <chrisj at rtems.org>
To: Sebastian Huber <sebastian.huber at embedded-brains.de>
Cc: rtems-users at rtems.org
Subject: Re: NULL call to _Workspace_Free() via
_Objects_Extend_information at startup
Message-ID: <4D6CC922.3040205 at rtems.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 1/03/11 7:39 PM, Sebastian Huber wrote:
> It says may because it will not always corrupt the heap. Passing a pointer
> outside the bounding interval of all heap areas will be rejected without harm.
> Passing maybe "valid pointer to allocated heap area + 4" will corrupt the heap.
Is this comment worth adding to the code ? I think it is.
Chris
------------------------------
Message: 8
Date: Tue, 1 Mar 2011 09:20:34 -0300
From: Fabr?cio de Novaes Kucinskis <fabricio at dea.inpe.br>
To: <rtems-users at rtems.com>
Subject: RES: RES: RES: Is there any change on interrupt catch between
RTEMS 4.9.4 and 4.10.0?
Message-ID: <002901cbd80b$10878d70$3196a850$@inpe.br>
Content-Type: text/plain; charset="UTF-8"
Hi Joel,
As I said before, we've solved our problem by replacing printf with printk, and we'll keep it this way; the main reason of this question was to understand what could have changed.
If this new version of the driver will allow printf to work without affecting anything else on 4.10, then ok. But if there's some side effect, please keep the code as it is - I'm worried you're committing a patch just to solve OUR problem...
Thanks again,
Fabr?cio.
-----Mensagem original-----
De: Joel Sherrill [mailto:joel.sherrill at oarcorp.com]
Enviada em: segunda-feira, 28 de fevereiro de 2011 17:11
Para: Fabr?cio de Novaes Kucinskis
Cc: filipe at dea.inpe.br
Assunto: Re: RES: RES: Is there any change on interrupt catch between RTEMS 4.9.4 and 4.10.0?
I think I see a problem. In 4.9.x, the console driver defaults
to polled. You are using UARTA RX ISR. In 4.10, the driver
only supports interrupt mode as best I can tell. Your ISR
is taking the ISR source and not letting it get processed by
the driver.
I am committing a version of the driver to the head which
SHOULD be OK with 4.10 and supports polled. So your
test probably will work again.
--joel
On 02/28/2011 12:19 PM, Fabr?cio de Novaes Kucinskis wrote:
> Joel,
>
> Thanks for the answer. As you asked, I'm sending attached a simple example of the problem. The .zip has also two versions of the executable (stripped for sizing reasons): You'll see that the 4.9.4 version runs on SIS, while the 4.10 version no.
>
> Regards,
>
> Fabr?cio.
>
>
>
> -----Mensagem original-----
> De: Joel Sherrill [mailto:joel.sherrill at oarcorp.com]
> Enviada em: segunda-feira, 28 de fevereiro de 2011 11:07
> Para: Fabr?cio de Novaes Kucinskis; rtems-users at rtems.com
> Assunto: Re: RES: Is there any change on interrupt catch between RTEMS 4.9.4 and 4.10.0?
>
> I don't think this is the overall interrupt processing code. The console code was reworked after 4.9. It is a bug in the new console. Please try to put the old code in the 4.10 or just compare it to find the change that broke this. It really sounds like it is simply not processing the interrupt from the uart. Then the ISR is not tripping termios and tasks are not unblocking. With nothing unblocked, you end up in idle.
>
> Does someone have a simple example so I can repeat this?
>
> --joel
>
> Fabr?cio de Novaes Kucinskis<fabricio at dea.inpe.br> wrote:
>
>> Hello,
>>
>> I'm experiencing the same problem Filipe described, and have some more details.
>>
>> I have a simple application that runs on SPARC/SIS. It uses printf to show the user some info, and gets data through the UART A interrupt.
>>
>> This application worked fine on RTEMS 4.6.4 through 4.9.4. After upgrading to 4.10, it stopped working.
>>
>> What happens, as far as I could go, is the following:
>>
>> 1. The application starts and prints a lot of messages;
>> 2. At some point, it calls 'rtems_interrupt_catch' to install the handler for UARTA (the same UART used by printf);
>> 3. After the rtems_interrupt_catch, it runs some more instructions, until it reaches the next printf;
>> 4. When executing this printf, only the first character is printed, and then the application halts.
>>
>> Debugging, I could identify that, after step 4 above, the application is only running the Idle task, as if there were nothing else to run (which is not true). It seems that the control never returns to the task that called printf, since any breakpoint after this call is reached.
>>
>> If I use printk instead of printf, this doesn't happen.
>>
>> As this didn't occur until RTEMS 4.9.4, what could've changed? Maybe the change on the interrupt handler type on the Interrupt Extension API? Something related to printf?
>>
>> It seems I could change all printf's to printk's to solve the issue, but it would be important to know the reason of the problem.
>>
>> Thanks in advance and best regards,
>>
>> Fabr?cio de Novaes Kucinskis.
--
Joel Sherrill, Ph.D. Director of Research& Development
joel.sherrill at OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
------------------------------
Message: 9
Date: Tue, 1 Mar 2011 14:48:45 +0100
From: Joachim Rahn <Joachim.Rahn at helmholtz-berlin.de>
To: <rtems-users at rtems.org>
Subject: ARM - after update from rtems4.9.3 to rtems-4.9.5 Unlimited
Task Test fails
Message-ID: <4D6CF93D.50409 at Helmholtz-Berlin.de>
Content-Type: text/plain; charset="ISO-8859-15"
Hi all,
after updating from rtems-4.9.3 to rtems-4.9.5 the "Unlimited Task Test" on my
ARM cpu at91sam9263 fails with a message like...
[...skip...]
task 19 ending.
task 20 ending.
task 21 ending.
task 7 ending.
task 8 ending.
INSN_LDR
data_abort at address 0x20018CD8, instruction: 0xE5932000, spsr = 0x20000013
active thread thread 0x0A010001
Previous sp=0x200629A8 lr=0x200135E0 and actual cpsr=60000097
0x20038E30 0x20056EA8 0x0000117C 0x200629E0 0x200629C4 0x200135E0
0x20018CB8 0x20038E30 0x20056EA8 0x20026EC0 0x20026EC0 0x20062A18
0x200629E4 0x20010100 0x200135AC 0x00000000 0x00000000 0x00000000
0x00000000 0x20056EA8 0x20038E30 0x60000013 0x600000D3 0x00000000
0x00000000 0x20062A28 0x20062A1C 0x2000AE48 0x2000FFF8 0x20062A4C
0x20062A2C 0x2000ADA0 0x2000AE24 0x521C9845 0x20056EA8 0x00000000
0x00000000 0x2002ACD8 0x20062A64 0x20062A50 0x20000348 0x2000AD28
0x00000008 0x00000001 0x20062A84 0x20062A68 0x2001C2D4 0x20000310
[...skip...]
which commonly means the cpu tries to access non available memory.
After removing the bugfix bug1718 the "Unlimited Task Test" works fine.
(https://www.rtems.org/bugzilla/show_bug.cgi?id=1718)
*** rtems-4.9.3: ./cpukit/sapi/include/confdefs.h *** unlimited task test works
[...skip...]
#define CONFIGURE_MEMORY_PER_TASK_FOR_POSIX_API \
_Configure_From_workspace( \
sizeof (POSIX_API_Control) + \
(sizeof (void *) * (CONFIGURE_MAXIMUM_POSIX_KEYS)) \
)
[...skip...]
*** rtems-4.9.5: ./cpukit/sapi/include/confdefs.h *** unlimited task test doesn't work
[...skip...]
#define CONFIGURE_MEMORY_PER_TASK_FOR_POSIX_API \
_Configure_From_workspace( \
CONFIGURE_MINIMUM_TASK_STACK_SIZE + \
sizeof (POSIX_API_Control) + \
(sizeof (void *) * (CONFIGURE_MAXIMUM_POSIX_KEYS)) \
)
[...skip...]
Any hints respectively does anyone observe the same?
Cheers
--
Joachim
________________________________
Helmholtz-Zentrum Berlin f?r Materialien und Energie GmbH
Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V
Aufsichtsrat: Vorsitzender Prof. Dr. Dr. h.c. mult. Joachim Treusch, stv. Vorsitzende Dr. Beatrix Vierkorn- Rudolph
Gesch?ftsf?hrer: Prof. Dr. Anke Rita Kaysser-Pyzalla, Prof. Dr. Dr. h.c. Wolfgang Eberhardt, Dr. Ulrich Breuer
Sitz Berlin, AG Charlottenburg, 89 HRB 5583
Postadresse:
Hahn-Meitner-Platz 1
D-14109 Berlin
http://www.helmholtz-berlin.de
------------------------------
Message: 10
Date: Tue, 1 Mar 2011 08:50:10 -0600
From: Joel Sherrill <joel.sherrill at OARcorp.com>
To: Fabr?cio de Novaes Kucinskis <fabricio at dea.inpe.br>
Cc: "rtems-users at rtems.com" <rtems-users at rtems.com>
Subject: Re: RES: RES: RES: Is there any change on interrupt catch
between RTEMS 4.9.4 and 4.10.0?
Message-ID: <4D6D07A2.2000205 at oarcorp.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
On 03/01/2011 06:20 AM, Fabr?cio de Novaes Kucinskis wrote:
> Hi Joel,
>
> As I said before, we've solved our problem by replacing printf with printk, and we'll keep it this way; the main reason of this question was to understand what could have changed.
>
> If this new version of the driver will allow printf to work without affecting anything else on 4.10, then ok. But if there's some side effect, please keep the code as it is - I'm worried you're committing a patch just to solve OUR problem...
>
The driver should support polled so adding that back in as the
default behaviour is correct.
If there are other issues with the new driver, I would like to
nail them before 4.10.1.
--joel
> Thanks again,
>
> Fabr?cio.
>
>
> -----Mensagem original-----
> De: Joel Sherrill [mailto:joel.sherrill at oarcorp.com]
> Enviada em: segunda-feira, 28 de fevereiro de 2011 17:11
> Para: Fabr?cio de Novaes Kucinskis
> Cc: filipe at dea.inpe.br
> Assunto: Re: RES: RES: Is there any change on interrupt catch between RTEMS 4.9.4 and 4.10.0?
>
> I think I see a problem. In 4.9.x, the console driver defaults
> to polled. You are using UARTA RX ISR. In 4.10, the driver
> only supports interrupt mode as best I can tell. Your ISR
> is taking the ISR source and not letting it get processed by
> the driver.
>
> I am committing a version of the driver to the head which
> SHOULD be OK with 4.10 and supports polled. So your
> test probably will work again.
>
> --joel
>
> On 02/28/2011 12:19 PM, Fabr?cio de Novaes Kucinskis wrote:
>> Joel,
>>
>> Thanks for the answer. As you asked, I'm sending attached a simple example of the problem. The .zip has also two versions of the executable (stripped for sizing reasons): You'll see that the 4.9.4 version runs on SIS, while the 4.10 version no.
>>
>> Regards,
>>
>> Fabr?cio.
>>
>>
>>
>> -----Mensagem original-----
>> De: Joel Sherrill [mailto:joel.sherrill at oarcorp.com]
>> Enviada em: segunda-feira, 28 de fevereiro de 2011 11:07
>> Para: Fabr?cio de Novaes Kucinskis; rtems-users at rtems.com
>> Assunto: Re: RES: Is there any change on interrupt catch between RTEMS 4.9.4 and 4.10.0?
>>
>> I don't think this is the overall interrupt processing code. The console code was reworked after 4.9. It is a bug in the new console. Please try to put the old code in the 4.10 or just compare it to find the change that broke this. It really sounds like it is simply not processing the interrupt from the uart. Then the ISR is not tripping termios and tasks are not unblocking. With nothing unblocked, you end up in idle.
>>
>> Does someone have a simple example so I can repeat this?
>>
>> --joel
>>
>> Fabr?cio de Novaes Kucinskis<fabricio at dea.inpe.br> wrote:
>>
>>> Hello,
>>>
>>> I'm experiencing the same problem Filipe described, and have some more details.
>>>
>>> I have a simple application that runs on SPARC/SIS. It uses printf to show the user some info, and gets data through the UART A interrupt.
>>>
>>> This application worked fine on RTEMS 4.6.4 through 4.9.4. After upgrading to 4.10, it stopped working.
>>>
>>> What happens, as far as I could go, is the following:
>>>
>>> 1. The application starts and prints a lot of messages;
>>> 2. At some point, it calls 'rtems_interrupt_catch' to install the handler for UARTA (the same UART used by printf);
>>> 3. After the rtems_interrupt_catch, it runs some more instructions, until it reaches the next printf;
>>> 4. When executing this printf, only the first character is printed, and then the application halts.
>>>
>>> Debugging, I could identify that, after step 4 above, the application is only running the Idle task, as if there were nothing else to run (which is not true). It seems that the control never returns to the task that called printf, since any breakpoint after this call is reached.
>>>
>>> If I use printk instead of printf, this doesn't happen.
>>>
>>> As this didn't occur until RTEMS 4.9.4, what could've changed? Maybe the change on the interrupt handler type on the Interrupt Extension API? Something related to printf?
>>>
>>> It seems I could change all printf's to printk's to solve the issue, but it would be important to know the reason of the problem.
>>>
>>> Thanks in advance and best regards,
>>>
>>> Fabr?cio de Novaes Kucinskis.
>
--
Joel Sherrill, Ph.D. Director of Research& Development
joel.sherrill at OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
------------------------------
_______________________________________________
rtems-users mailing list
rtems-users at rtems.org
http://www.rtems.org/mailman/listinfo/rtems-users
End of rtems-users Digest, Vol 54, Issue 2
******************************************
Information contained and transmitted by this e-mail is confidential and proprietary to Patni Computer Systems Ltd and its affiliates (hitherto referred as Patni Computers) and is intended for use only by the recipient. If you are not the intended recipient , you are hereby notified that any dissemination, distribution, copying or use of this e-mail is strictly prohibited and you are requested to delete this e-mail immediately and notify the originator or netadmin at patni.com. Patni Computers does not enter into any agreement with any party by e-mail. Any views expressed by an individual do not necessarily reflect the view of Patni Computers. Patni Computers is not responsible for the consequences of any actions taken on the basis of information provided, through this email. The contents of an attachment to this e-mail may contain software viruses, which could damage your own computer system. While Patni Computers has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should carry out your own virus checks before opening an attachment. To know more about Patni Computers please visit www.patni.com.
More information about the users
mailing list