[Bug 21968] select does not work on stdin

[Bug 21968] select does not work on stdin

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=21968

Ken <kenkyee@excite.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kenkyee@excite.com

--- Comment #3 from Ken <kenkyee@excite.com> 2012-11-15 21:12:51 GMT ---
This seems like a pretty bad bug to be categorized as "low" priority?!?

Use case is: people want diag/log output to a serial port, but also want to be
able to fire up a shell command processor when users put in a special
sequence...this should be a fairly common thing to do :-P

For workarounds, we've tried this:
- tried using select() then getchar()...selects apparently are broken because
it sometimes says a character is ready but it isn't, so it goes to the getchar
and locks up the entire scheduler (locking up the console task would have been
fine, but no....)-:
- tried using select() and then read() to bypass the buffering...same weird
behavior
- use direct calls to the HAL COMM_IF_GETC_TIMEOUT etc. functions...these don't
block but also returns maybe 1% of characters typed in
- tried to use configtool to tell eCos not to use that port for diag output,
but apparently, you can't just point it at /dev/null or a non-existent serial
port :-P
- tried enabling termios in eCos, but the ioctl call to get the number of
characters queued doesn't work

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 21968] select does not work on stdin

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=21968

Jonathan Larmour <jifl@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jifl@ecoscentric.com

--- Comment #4 from Jonathan Larmour <jifl@ecoscentric.com> 2012-11-16 03:14:10 GMT ---
(In reply to comment #3)
> This seems like a pretty bad bug to be categorized as "low" priority?!?
> 
> Use case is: people want diag/log output to a serial port, but also want to be
> able to fire up a shell command processor when users put in a special
> sequence...this should be a fairly common thing to do :-P
> For workarounds, we've tried this:
> - tried using select() then getchar()...selects apparently are broken because
> it sometimes says a character is ready but it isn't, so it goes to the getchar
> and locks up the entire scheduler (locking up the console task would have been
> fine, but no....)-:

Where is it locked? What's the backtrace when you interrupt it from a debugger?

> - tried using select() and then read() to bypass the buffering...same weird
> behavior
> - use direct calls to the HAL COMM_IF_GETC_TIMEOUT etc. functions...these don't
> block but also returns maybe 1% of characters typed in

That seems to tell me that you're trying to use select with a HAL diagnostic
channel as your stdin. Don't do that. The HAL diagnostic channel is there for
debug only for simple output. It is polled only with interrupts off. Use a
proper serial driver, or if this is for user terminal use, then a tty wrapper
around a serial driver (e.g. /dev/tty0 for /dev/ser0 - look at the serial
docs).

> - tried to use configtool to tell eCos not to use that port for diag output,
> but apparently, you can't just point it at /dev/null or a non-existent serial
> port :-P

If you don't want to use that channel at all, then don't try and use it for
input or output surely!

> - tried enabling termios in eCos, but the ioctl call to get the number of
> characters queued doesn't work

This should work without termios, no need to complicate things by including it.

What port is this? Since this is an 11 year old bug report you've added to, I'm
tempted to believe it isn't an Intel StrongARM Assabet board.

Jifl

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 21968] select does not work on stdin

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=21968

Bernd Edlinger <bernd.edlinger@hotmail.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bernd.edlinger@hotmail.de

--- Comment #5 from Bernd Edlinger <bernd.edlinger@hotmail.de> 2012-11-18 09:18:10 GMT ---
(In reply to comment #3)
Hi Ken,

the code in this sample is inherently worng.
The assumption is wrong that fd 0 is always connected to stdin.
the right file handle would be fileno(stdin);

what is fileno(stdin) in your environment?

Regards,
Bernd.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 21968] select does not work on stdin

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=21968

--- Comment #6 from Jonathan Larmour <jifl@ecoscentric.com> 2012-11-18 17:25:54 GMT ---
(In reply to comment #5)
> (In reply to comment #3)
> Hi Ken,
> 
> the code in this sample is inherently worng.
> The assumption is wrong that fd 0 is always connected to stdin.
> the right file handle would be fileno(stdin);
> 
> what is fileno(stdin) in your environment?

In fairness, in eCos, if stdin exists at all, it is fd 0.

Jifl

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 21968] select does not work on stdin

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=21968

--- Comment #7 from Ken <kenkyee@excite.com> 2012-11-19 16:01:56 GMT ---
> Where is it locked? What's the backtrace when you interrupt it from a debugger?

The backtrace when I hit the stop button in Insight is:
Cyg_HardwareThread::thread_entry(Cyg_Thread*)
Cyg_HardwareThread::thread_entry(Cyg_Thread*)
ConsoleTask() <--- this is my console thread
read(int, void* size_t)  <-- it went past the select and is blocked here
readwritev(int, cyg_iovec const*, int, int)
dev_fo_read(CYG_FILE_TAG*, CYGUIO_TAG*)
cyg_io_read
tty_read
cyg_io_read
serial-read
haldiag_getc
hal_if_diag_read_char
__call_COMM_IF_GETC
cyg_hal_plf_serial_getc
cyg_hal_plf_serial_getc_nonblock

Ironically, it ends up in a nonblocking function that blocks :-)


> That seems to tell me that you're trying to use select with a HAL diagnostic
> channel as your stdin. Don't do that. The HAL diagnostic channel is there for
> debug only for simple output. It is polled only with interrupts off. Use a

The problem is, with this board, we're short one port.  It has 3 serial ports. 
Two are used for system usage (modem and board-board communication).  The 3rd
is our console port which we sent stdin/stdout to.  eCos has a diag port where
Assert messages are printed and we'd prefer that to go to the stdout port as
well since we can't catch them and save them in our logs...unfortunately
disabling the ROM monitor doesn't seem to help...it still seems to want to do
blocking diag calls to the same port we're sharing stdin/stdout to.

Sounds like we have to write a dummy serial port driver that writes the Assert
to a known location in memory instead of having it dump to the stdin/stdout
port?


> What port is this?

It's a port to a board based on an archaic 10yr old Atmel AT91M55800A chip that
Atmel is no longer recommending for new designs :-P


> what is fileno(stdin) in your environment?

Matches what it should be according to the POSIX API..0 which matches the
STDIN_FILENO macro

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 21968] select does not work on stdin

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=21968

--- Comment #8 from Ken <kenkyee@excite.com> 2012-11-19 16:04:43 GMT ---
Forgot to mention that I did get it to be nonblocking by using this call:
          ioctl(STDIN_FILENO, FIONBIO, &opt);

but the diag port appears to eat characters.  I need to press a key 17-18 times
before it will register and my application can see it, so it's not useful even
if it is non-blocking :-P

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 21968] select does not work on stdin

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=21968

--- Comment #9 from Bernd Edlinger <bernd.edlinger@hotmail.de> 2012-11-19 16:40:51 GMT ---
(In reply to comment #8)
> Forgot to mention that I did get it to be nonblocking by using this call:
>           ioctl(STDIN_FILENO, FIONBIO, &opt);
> but the diag port appears to eat characters.  I need to press a key 17-18 times
> before it will register and my application can see it, so it's not useful even
> if it is non-blocking :-P

Ken,

as far as I know this API is only implemented for sockets in eCos.

Regards
Bernd.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 21968] select does not work on stdin

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=21968

--- Comment #9 from Bernd Edlinger <bernd.edlinger@hotmail.de> 2012-11-19 16:40:51 GMT ---
(In reply to comment #8)
> Forgot to mention that I did get it to be nonblocking by using this call:
>           ioctl(STDIN_FILENO, FIONBIO, &opt);
> but the diag port appears to eat characters.  I need to press a key 17-18 times
> before it will register and my application can see it, so it's not useful even
> if it is non-blocking :-P

Ken,

as far as I know this API is only implemented for sockets in eCos.

Regards
Bernd.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 21968] select does not work on stdin

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=21968

--- Comment #8 from Ken <kenkyee@excite.com> 2012-11-19 16:04:43 GMT ---
Forgot to mention that I did get it to be nonblocking by using this call:
          ioctl(STDIN_FILENO, FIONBIO, &opt);

but the diag port appears to eat characters.  I need to press a key 17-18 times
before it will register and my application can see it, so it's not useful even
if it is non-blocking :-P

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 21968] select does not work on stdin

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=21968

--- Comment #7 from Ken <kenkyee@excite.com> 2012-11-19 16:01:56 GMT ---
> Where is it locked? What's the backtrace when you interrupt it from a debugger?

The backtrace when I hit the stop button in Insight is:
Cyg_HardwareThread::thread_entry(Cyg_Thread*)
Cyg_HardwareThread::thread_entry(Cyg_Thread*)
ConsoleTask() <--- this is my console thread
read(int, void* size_t)  <-- it went past the select and is blocked here
readwritev(int, cyg_iovec const*, int, int)
dev_fo_read(CYG_FILE_TAG*, CYGUIO_TAG*)
cyg_io_read
tty_read
cyg_io_read
serial-read
haldiag_getc
hal_if_diag_read_char
__call_COMM_IF_GETC
cyg_hal_plf_serial_getc
cyg_hal_plf_serial_getc_nonblock

Ironically, it ends up in a nonblocking function that blocks :-)


> That seems to tell me that you're trying to use select with a HAL diagnostic
> channel as your stdin. Don't do that. The HAL diagnostic channel is there for
> debug only for simple output. It is polled only with interrupts off. Use a

The problem is, with this board, we're short one port.  It has 3 serial ports. 
Two are used for system usage (modem and board-board communication).  The 3rd
is our console port which we sent stdin/stdout to.  eCos has a diag port where
Assert messages are printed and we'd prefer that to go to the stdout port as
well since we can't catch them and save them in our logs...unfortunately
disabling the ROM monitor doesn't seem to help...it still seems to want to do
blocking diag calls to the same port we're sharing stdin/stdout to.

Sounds like we have to write a dummy serial port driver that writes the Assert
to a known location in memory instead of having it dump to the stdin/stdout
port?


> What port is this?

It's a port to a board based on an archaic 10yr old Atmel AT91M55800A chip that
Atmel is no longer recommending for new designs :-P


> what is fileno(stdin) in your environment?

Matches what it should be according to the POSIX API..0 which matches the
STDIN_FILENO macro

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 21968] select does not work on stdin

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=21968

--- Comment #6 from Jonathan Larmour <jifl@ecoscentric.com> 2012-11-18 17:25:54 GMT ---
(In reply to comment #5)
> (In reply to comment #3)
> Hi Ken,
> 
> the code in this sample is inherently worng.
> The assumption is wrong that fd 0 is always connected to stdin.
> the right file handle would be fileno(stdin);
> 
> what is fileno(stdin) in your environment?

In fairness, in eCos, if stdin exists at all, it is fd 0.

Jifl

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 21968] select does not work on stdin

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=21968

Bernd Edlinger <bernd.edlinger@hotmail.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bernd.edlinger@hotmail.de

--- Comment #5 from Bernd Edlinger <bernd.edlinger@hotmail.de> 2012-11-18 09:18:10 GMT ---
(In reply to comment #3)
Hi Ken,

the code in this sample is inherently worng.
The assumption is wrong that fd 0 is always connected to stdin.
the right file handle would be fileno(stdin);

what is fileno(stdin) in your environment?

Regards,
Bernd.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 21968] select does not work on stdin

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=21968

Jonathan Larmour <jifl@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jifl@ecoscentric.com

--- Comment #4 from Jonathan Larmour <jifl@ecoscentric.com> 2012-11-16 03:14:10 GMT ---
(In reply to comment #3)
> This seems like a pretty bad bug to be categorized as "low" priority?!?
> 
> Use case is: people want diag/log output to a serial port, but also want to be
> able to fire up a shell command processor when users put in a special
> sequence...this should be a fairly common thing to do :-P
> For workarounds, we've tried this:
> - tried using select() then getchar()...selects apparently are broken because
> it sometimes says a character is ready but it isn't, so it goes to the getchar
> and locks up the entire scheduler (locking up the console task would have been
> fine, but no....)-:

Where is it locked? What's the backtrace when you interrupt it from a debugger?

> - tried using select() and then read() to bypass the buffering...same weird
> behavior
> - use direct calls to the HAL COMM_IF_GETC_TIMEOUT etc. functions...these don't
> block but also returns maybe 1% of characters typed in

That seems to tell me that you're trying to use select with a HAL diagnostic
channel as your stdin. Don't do that. The HAL diagnostic channel is there for
debug only for simple output. It is polled only with interrupts off. Use a
proper serial driver, or if this is for user terminal use, then a tty wrapper
around a serial driver (e.g. /dev/tty0 for /dev/ser0 - look at the serial
docs).

> - tried to use configtool to tell eCos not to use that port for diag output,
> but apparently, you can't just point it at /dev/null or a non-existent serial
> port :-P

If you don't want to use that channel at all, then don't try and use it for
input or output surely!

> - tried enabling termios in eCos, but the ioctl call to get the number of
> characters queued doesn't work

This should work without termios, no need to complicate things by including it.

What port is this? Since this is an 11 year old bug report you've added to, I'm
tempted to believe it isn't an Intel StrongARM Assabet board.

Jifl

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 21968] select does not work on stdin

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=21968

Ken <kenkyee@excite.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kenkyee@excite.com

--- Comment #3 from Ken <kenkyee@excite.com> 2012-11-15 21:12:51 GMT ---
This seems like a pretty bad bug to be categorized as "low" priority?!?

Use case is: people want diag/log output to a serial port, but also want to be
able to fire up a shell command processor when users put in a special
sequence...this should be a fairly common thing to do :-P

For workarounds, we've tried this:
- tried using select() then getchar()...selects apparently are broken because
it sometimes says a character is ready but it isn't, so it goes to the getchar
and locks up the entire scheduler (locking up the console task would have been
fine, but no....)-:
- tried using select() and then read() to bypass the buffering...same weird
behavior
- use direct calls to the HAL COMM_IF_GETC_TIMEOUT etc. functions...these don't
block but also returns maybe 1% of characters typed in
- tried to use configtool to tell eCos not to use that port for diag output,
but apparently, you can't just point it at /dev/null or a non-existent serial
port :-P
- tried enabling termios in eCos, but the ioctl call to get the number of
characters queued doesn't work

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.