Created by: Bob Fitzgerald on 29-09-2010 08:56:36 PM Hey there everyone!
I had a customer call me saying that at the beginning of the boot sequence, the order in which the carriage return and the line feed happen becomes reversed (changing from CR/LF to LF/CR), which is causing an "input buffer overflow" on his Crestron. It reverts back to the CR/LF order after a short time, but the damage has been done by that point. This is what he's seeing on the output of the serial port;
0000000C=OK[0D][0A] 0000000C= Loading Ramdisk to 1e358000, end 1eb8427c ... 0000000C=OK 0000000C=[0D][0A] Loading Device Tree to 007fb000, end 007ff14a ... OK[0D][0A] 0000000C=Using MPC8347 Saturn PPC machine description[0A][0D]Linux version 2.6.25.1-129 (kaa@rema.rd.tandberg.com) (gcc version 4.4.1 (GCC 0000000C=) ) #1 PREEMPT Tue Jun 22 13:27:27 CEST 2010[0A][0D]Found initrd at 0xde358000:0xdeb8427c[0A][0D]console [udbg0] enabled[0A][0D]setup_arch: b 0000000C=ootmem[0A][0D]mpc8347_saturn_ppc_setup_arch()[0A][0D]Found MPC83xx PCI host bridge at 0x00000000e0008500. Firmware bus number: 0->0[0A][0D]PC 0000000C=I host bridge /soc8349@e0000000/pci@8500 (primary) ranges:[0A][0D]arch: exit[0A][0D]Zone PFN ranges:[0A][0D] DMA 0 -> 131072[0A][0D] 0000000C= Normal 131072 -> 131072[0A][0D] HighMem 131072 -> 131072[0A][0D]Movable zone start PFN for each node[0A][0D]early_node_map[1] a 0000000C=ctive PFN ranges[0A][0D] 0: 0 -> 131072[0A][0D]Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048[0A] 0000000C=[0D]Kernel command line: basemount=/dev/mtdblock1 console=tty0,38400 mainboard=0xc1 videoboard=0xd1 audioextboard=0xffffffff u 0000000C=-boot=2009.03-53[0A][0D]IPIC (128 IRQ sources) at fdffa700[0A][0D]PID hash table entries: 2048 (order: 11, 8192 bytes)[0A][0D]clocksource: ti 0000000C=mebase mult[5000002] shift[22] registered[0A][0D]Console: colour dummy device 80x25[0A][0D]console handover: boot [udbg0] -> real [tty0 0000000C=][0A][0D] [0A][0D] 0000000C=[0D][0D][0A]login: 0000000B=admin[0D][0A] 0000000C=admin[0D][0A] 0000000C=tshe He says that ordinarily he would write something that would account for the switch. However, for this client, he says it would be extremely difficult to implement. He has two questions; 1-Is Tandberg aware of this? 2-Is there a planned fix for this?
Thanks!
Subject: RE: carriage return/line feed sequence Replied by: Bob Fitzgerald on 04-10-2010 06:38:39 PM Hello again,
Any thoughts on this one?
Thanks!
Subject: RE: carriage return/line feed sequence Replied by: Bob Fitzgerald on 07-10-2010 12:20:49 AM bump
Subject: RE: carriage return/line feed sequence Replied by: David Bruun-Lie on 07-10-2010 04:35:20 PM Hi Sorry for the late answer. This is something that we will look into. The lf/cr occurs in the boot sequence only but I am aware that this data coming on the serial port is not easily managed by Crestron. One way of minimising Overflows is to add a serial buffer that is only enabled once it has been established that one has successfully logged in to the codec so that no other parts of the module gets any data on device_rx until then. This is something I have implemented in a new module that will be out soon. But I will also see if it is possible to get the lf/cr fixed for a future SW release.
Cheers David
Subject: RE: carriage return/line feed sequence Replied by: Bob Fitzgerald on 07-10-2010 06:16:31 PM Hi David,
Thank you very much for the reply. I hope the customer can add the fix you suggested to his code. I'll have him keep an eye out for that new module.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:
