Re: mm_serial_port_queue_process: (ttyUSB2) response array is not empty.....



> 
> I found this in my logs, a huge amount:
> 
> May 18 07:52:40 localhost modem-manager[1998]:
> mm_serial_port_queue_process: (ttyUSB2) response array is not empty when
> using cached reply, cleaning up 26 bytes
> May 18 07:52:56 localhost modem-manager[1998]:
> mm_serial_port_queue_process: (ttyUSB2) response array is not empty when
> using cached reply, cleaning up 26 bytes
> May 18 07:53:08 localhost modem-manager[1998]:
> mm_serial_port_queue_process: (ttyUSB2) response array is not empty when
> using cached reply, cleaning up 13 bytes
> May 18 07:53:13 localhost modem-manager[1998]:
> mm_serial_port_queue_process: (ttyUSB2) response array is not empty when
> using cached reply, cleaning up 26 bytes
> May 18 07:53:19 localhost modem-manager[1998]:
> mm_serial_port_queue_process: (ttyUSB2) response array is not empty when
> using cached reply, cleaning up 13 bytes
> May 18 07:53:24 localhost modem-manager[1998]:
> mm_serial_port_queue_process: (ttyUSB2) response array is not empty when
> using cached reply, cleaning up 13 bytes
> May 18 07:53:30 localhost modem-manager[1998]:
> mm_serial_port_queue_process: (ttyUSB2) response array is not empty when
> using cached reply, cleaning up 26 bytes
> May 18 07:53:41 localhost modem-manager[1998]:
> mm_serial_port_queue_process: (ttyUSB2) response array is not empty when
> using cached reply, cleaning up 65 bytes
> May 18 07:53:52 localhost modem-manager[1998]:
> mm_serial_port_queue_process: (ttyUSB2) response array is not empty when
> usingcached reply, cleaning up 13 bytes
>  
> 
> What does it mean? I did not find any useful on the net.
> 

It means that array used to store the responses wasn't empty when an AT
command was requested and a previously cached reply used instead of
firing the new command. Whenever an AT command is sent, we expect the
response array to be empty; if it is not, it may be a leftover (e.g.
previously sent command timed out and response arrived afterwards), or
maybe some unexpected unsolicited indication not properly parsed.

Could you get debug logs to see exactly where this is happening?

-- 
Aleksander


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]