RFS not stable

[Markus Korber]

Hello,

I'm currently trying to use the RFS module on an LPC2478 device with a
Ubuntu host but I'm having problems getting a reliable connection.  I'm
using a separate physical UART for this purpose (tried with various
speeds from 115200 down to 9600).

However, when I use 'ls' the RFS files are only partially listed or not
at all.  If I try to execute a file from RFS sometimes it says

»lua: cannot open /rfs/hello.lua: No such file or directory«
or
»Press CTRL+Z to exit Lua
 lua: cannot open /rfs/hello.lua: Function not implemented«

However, if I repeat the command 10-20 times the script finally runs.
Does this have something to do with my UART setup?

(Hardware flow control (RTS/CTS) doesn't seem to have an influence on
this behaviour.)

However, it works best if there is only one file in the shared directory
with a name as short as possible.

Regards,
Markus Korber
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Markus Korber]

Thus spake Markus Korber:

> »Press CTRL+Z to exit Lua
>  lua: cannot open /rfs/hello.lua: Function not implemented«

Sorry I forgot to add some loglines from the rfs_server in case this
error appears:
,----
| read_request_packet: ERROR reading full packet, got 20 bytes, expected 36 bytes
| read_request_packet: ERROR getting packet size.
`----

(For different 'got XX bytes').

Regards,
Markus Korber
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

Hi,

On Thu, Dec 15, 2011 at 4:10 PM, Markus Korber <[hidden email]> wrote:

Hello,

I'm currently trying to use the RFS module on an LPC2478 device with a
Ubuntu host but I'm having problems getting a reliable connection.  I'm
using a separate physical UART for this purpose (tried with various
speeds from 115200 down to 9600).

However, when I use 'ls' the RFS files are only partially listed or not
at all.  If I try to execute a file from RFS sometimes it says

»lua: cannot open /rfs/hello.lua: No such file or directory«
or
»Press CTRL+Z to exit Lua
 lua: cannot open /rfs/hello.lua: Function not implemented«

However, if I repeat the command 10-20 times the script finally runs.
Does this have something to do with my UART setup?

(Hardware flow control (RTS/CTS) doesn't seem to have an influence on
this behaviour.)

However, it works best if there is only one file in the shared directory
with a name as short as possible.

I will update a patch today (tonight actually) that might fix this issue.

Best,

Bogdan

 

Regards,
Markus Korber
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

Hi,

The fix is now on master, please try it and let me know if it works for you.

Thanks,

Bogdan

On Thu, Dec 15, 2011 at 5:15 PM, Bogdan Marinescu <[hidden email]> wrote:

Hi,

On Thu, Dec 15, 2011 at 4:10 PM, Markus Korber <[hidden email]> wrote:

Hello,

I'm currently trying to use the RFS module on an LPC2478 device with a
Ubuntu host but I'm having problems getting a reliable connection.  I'm
using a separate physical UART for this purpose (tried with various
speeds from 115200 down to 9600).

However, when I use 'ls' the RFS files are only partially listed or not
at all.  If I try to execute a file from RFS sometimes it says

»lua: cannot open /rfs/hello.lua: No such file or directory«
or
»Press CTRL+Z to exit Lua
 lua: cannot open /rfs/hello.lua: Function not implemented«

However, if I repeat the command 10-20 times the script finally runs.
Does this have something to do with my UART setup?

(Hardware flow control (RTS/CTS) doesn't seem to have an influence on
this behaviour.)

However, it works best if there is only one file in the shared directory
with a name as short as possible.

I will update a patch today (tonight actually) that might fix this issue.

Best,

Bogdan

 

Regards,
Markus Korber
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Markus Korber]

Thus spake Bogdan Marinescu:

> The fix is now on master, please try it and let me know if it works for you.

Directory listings now work like a charm.  Thanks.

However, running a script now either always works or never works.  In
case of an error the server logs read:
,----
| server_execute_request: got request with ID 1
| server_open: request handler starting
| server_open: unable to read request
| send_response_packet: sending response packet of 47 bytes
`----

Further debugging revealed a very obscure behaviour: The error only
occurs for filenames which are exactely 8.3.  All other files work.  The
problem is that the µC transmits a 'pointer length' of 0xD
('\004\003\r') for these files but the rfs_server always receives a 0xA
('\004\003\n') instead and therefore fails to parse the protocol
subsequently.  Very strange.

Until I found that:
http://stackoverflow.com/questions/2589371/lf-cr-issue-with-rs232-in-linux

Et voilà: Everything works as expected.  Thanks a lot, Bogdan.

Regards,
Markus Korber
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

Hi,

On Fri, Dec 16, 2011 at 10:56 AM, Markus Korber <[hidden email]> wrote:

Thus spake Bogdan Marinescu:

> The fix is now on master, please try it and let me know if it works for you.

Directory listings now work like a charm.  Thanks.

However, running a script now either always works or never works.  In
case of an error the server logs read:
,----
| server_execute_request: got request with ID 1
| server_open: request handler starting
| server_open: unable to read request
| send_response_packet: sending response packet of 47 bytes
`----

Further debugging revealed a very obscure behaviour: The error only
occurs for filenames which are exactely 8.3.  All other files work.  The
problem is that the µC transmits a 'pointer length' of 0xD
('\004\003\r') for these files but the rfs_server always receives a 0xA
('\004\003\n') instead and therefore fails to parse the protocol
subsequently.  Very strange.

Until I found that:
http://stackoverflow.com/questions/2589371/lf-cr-issue-with-rs232-in-linux

Et voilà: Everything works as expected.  Thanks a lot, Bogdan.

Thanks for the report. This is actually a bug on the RFS server side, the port should be set in such a way that it doesn't do any translations like this. And I could've sworn I did that. Oh well :) Thank you, I'll take a look at this.

Best,

Bogdan

Regards,
Markus Korber
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

Hi,

On Fri, Dec 16, 2011 at 10:56 AM, Markus Korber <[hidden email]> wrote:

Thus spake Bogdan Marinescu:

> The fix is now on master, please try it and let me know if it works for you.

Directory listings now work like a charm.  Thanks.

However, running a script now either always works or never works.  In
case of an error the server logs read:
,----
| server_execute_request: got request with ID 1
| server_open: request handler starting
| server_open: unable to read request
| send_response_packet: sending response packet of 47 bytes
`----

Further debugging revealed a very obscure behaviour: The error only
occurs for filenames which are exactely 8.3.  All other files work.  The
problem is that the µC transmits a 'pointer length' of 0xD
('\004\003\r') for these files but the rfs_server always receives a 0xA
('\004\003\n') instead and therefore fails to parse the protocol
subsequently.  Very strange.

One more thing: does rfs_server has the same behaviour if you run it as root?

Thanks,

Bogdan

 

Until I found that:
http://stackoverflow.com/questions/2589371/lf-cr-issue-with-rs232-in-linux

Et voilà: Everything works as expected.  Thanks a lot, Bogdan.

Regards,
Markus Korber
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Markus Korber]

Thus spake Bogdan Marinescu:

> On Fri, Dec 16, 2011 at 10:56 AM, Markus Korber <[hidden email]> wrote:
>
>> Further debugging revealed a very obscure behaviour: The error only
>> occurs for filenames which are exactely 8.3.  All other files work.  The
>> problem is that the µC transmits a 'pointer length' of 0xD
>> ('\004\003\r') for these files but the rfs_server always receives a 0xA
>> ('\004\003\n') instead and therefore fails to parse the protocol
>> subsequently.  Very strange.
>
> One more thing: does rfs_server has the same behaviour if you run it as
> root?

Yes (since I can issue the 'stty' commands as a normal user).

Regards,
Markus Korber
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

On Fri, Dec 16, 2011 at 11:56 AM, Markus Korber <[hidden email]> wrote:

Thus spake Bogdan Marinescu:

> On Fri, Dec 16, 2011 at 10:56 AM, Markus Korber <[hidden email]> wrote:
>

>> Further debugging revealed a very obscure behaviour: The error only
>> occurs for filenames which are exactely 8.3.  All other files work.  The
>> problem is that the µC transmits a 'pointer length' of 0xD
>> ('\004\003\r') for these files but the rfs_server always receives a 0xA
>> ('\004\003\n') instead and therefore fails to parse the protocol
>> subsequently.  Very strange.
>
> One more thing: does rfs_server has the same behaviour if you run it as
> root?

Yes (since I can issue the 'stty' commands as a normal user).

That's extremely weird. I checked the code and I actually setup the serial port properly ('raw' mode on output == lack of any CR/LF translations), but it seems that this option is ignored. I'll try to dig a bit deeper.

Thanks,

Bogdan

 

Regards,
Markus Korber
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

Hi,

On Fri, Dec 16, 2011 at 11:56 AM, Markus Korber <[hidden email]> wrote:

Thus spake Bogdan Marinescu:

> On Fri, Dec 16, 2011 at 10:56 AM, Markus Korber <[hidden email]> wrote:
>

>> Further debugging revealed a very obscure behaviour: The error only
>> occurs for filenames which are exactely 8.3.  All other files work.  The
>> problem is that the µC transmits a 'pointer length' of 0xD
>> ('\004\003\r') for these files but the rfs_server always receives a 0xA
>> ('\004\003\n') instead and therefore fails to parse the protocol
>> subsequently.  Very strange.
>
> One more thing: does rfs_server has the same behaviour if you run it as
> root?

Yes (since I can issue the 'stty' commands as a normal user).

Could you please apply the attached patch and let me know if the problem is still reproducible?

Thanks,

Bogdan

 

Regards,
Markus Korber
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Markus Korber]

Thus spake Bogdan Marinescu:

> Hi,
>
> On Fri, Dec 16, 2011 at 11:56 AM, Markus Korber <[hidden email]> wrote:
>
>> Thus spake Bogdan Marinescu:
>
>>> On Fri, Dec 16, 2011 at 10:56 AM, Markus Korber <[hidden email]>
>> wrote:
>
>>>> Further debugging revealed a very obscure behaviour: The error only
>>>> occurs for filenames which are exactely 8.3.  All other files work.  The
>>>> problem is that the µC transmits a 'pointer length' of 0xD
>>>> ('\004\003\r') for these files but the rfs_server always receives a 0xA
>>>> ('\004\003\n') instead and therefore fails to parse the protocol
>>>> subsequently.  Very strange.
>
>>> One more thing: does rfs_server has the same behaviour if you run it as
>>> root?
>
>> Yes (since I can issue the 'stty' commands as a normal user).
>
> Could you please apply the attached patch and let me know if the problem is
> still reproducible?

Problem is still reproducible.  You need another one:
,----
| termdata.c_iflag &= ~( INLCR | ICRNL );
`----

Perhaps some other flags will be needed.  At least if you want to use
'Raw mode' according to termios(3).

Regards,
Markus Korber
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

On Fri, Dec 16, 2011 at 12:32 PM, Markus Korber <[hidden email]> wrote:

Thus spake Bogdan Marinescu:

> Hi,
>
> On Fri, Dec 16, 2011 at 11:56 AM, Markus Korber <[hidden email]> wrote:
>
>> Thus spake Bogdan Marinescu:
>
>>> On Fri, Dec 16, 2011 at 10:56 AM, Markus Korber <[hidden email]>
>> wrote:
>
>>>> Further debugging revealed a very obscure behaviour: The error only
>>>> occurs for filenames which are exactely 8.3.  All other files work.  The
>>>> problem is that the µC transmits a 'pointer length' of 0xD
>>>> ('\004\003\r') for these files but the rfs_server always receives a 0xA
>>>> ('\004\003\n') instead and therefore fails to parse the protocol
>>>> subsequently.  Very strange.
>
>>> One more thing: does rfs_server has the same behaviour if you run it as
>>> root?
>
>> Yes (since I can issue the 'stty' commands as a normal user).
>
> Could you please apply the attached patch and let me know if the problem is
> still reproducible?

Problem is still reproducible.  You need another one:
,----
| termdata.c_iflag &= ~( INLCR | ICRNL );
`----

Ah, my bad. I was looking at the problem from the wrong direction (literally). After reading your message more carefully, it's clear that you need to modify the input flags, not the output flags (which fortunately lowers a bit the perplexity factor of this bug). So, if you do this:

termdata.c_iflag &= ~( INLCR | ICRNL | IGNCR );

is the problem still reproducible ?

Thanks,

Bogdan

 

Perhaps some other flags will be needed.  At least if you want to use
'Raw mode' according to termios(3).

Regards,
Markus Korber
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Markus Korber]

Thus spake Bogdan Marinescu:

> On Fri, Dec 16, 2011 at 12:32 PM, Markus Korber <[hidden email]> wrote:
>
>> Problem is still reproducible.  You need another one:
>> ,----
>> | termdata.c_iflag &= ~( INLCR | ICRNL );
>> `----
>
> Ah, my bad. I was looking at the problem from the wrong direction
> (literally). After reading your message more carefully, it's clear that you
> need to modify the input flags, not the output flags (which fortunately
> lowers a bit the perplexity factor of this bug). So, if you do this:
>
> termdata.c_iflag &= ~( INLCR | ICRNL | IGNCR );
>
> is the problem still reproducible ?

No, it's gone.  Thanks.

Regards,
Markus Korber
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

On Fri, Dec 16, 2011 at 1:46 PM, Markus Korber <[hidden email]> wrote:

Thus spake Bogdan Marinescu:

> On Fri, Dec 16, 2011 at 12:32 PM, Markus Korber <[hidden email]> wrote:
>

>> Problem is still reproducible.  You need another one:
>> ,----
>> | termdata.c_iflag &= ~( INLCR | ICRNL );
>> `----
>
> Ah, my bad. I was looking at the problem from the wrong direction
> (literally). After reading your message more carefully, it's clear that you
> need to modify the input flags, not the output flags (which fortunately
> lowers a bit the perplexity factor of this bug). So, if you do this:
>
> termdata.c_iflag &= ~( INLCR | ICRNL | IGNCR );
>
> is the problem still reproducible ?

No, it's gone.  Thanks.

Nope, thank YOU :) I'll commit the patch soon.

Best,

Bogadn

 

Regards,
Markus Korber
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev