From: Grahame J. <gb...@th...> - 2007-11-30 01:15:43
|
Hi, I am looking at using USB serial on the connex board. I have managed to get it working somewhat. Buildroot 1161 When I connect to /etc/ttyACM0 vi a kermit or cu it connects and appears to work OK. However when I run something like: ls -laR / It hangs until I reboot the gumstix. Here is the process for getting g_serial running on the Gumstix mknod -m660 /dev/ttygserial modprobe g_serial use_acm-1 ACM registers on host OK add: ::respawn:/sbin/getty -L ttygserial 115200 vt100 into /etc/inittab kill -1 1 On the host cu -l /dev/ttyACM0 Login ls -laR / Hang Reboot and repeat. Same on Kermit. Any help appreciated. Thanks Grahame Jordan |
From: notstix <art...@ho...> - 2007-11-30 07:50:37
|
Grahame Jordan wrote: > > Hi, > > I am looking at using USB serial on the connex board. > I have managed to get it working somewhat. > > Buildroot 1161 > > When I connect to /etc/ttyACM0 vi a kermit or cu it connects and appears > to work OK. > However when I run something like: > ls -laR / > It hangs until I reboot the gumstix. > > Here is the process for getting g_serial running on the Gumstix > > mknod -m660 /dev/ttygserial > modprobe g_serial use_acm-1 > > ACM registers on host OK > > add: > ::respawn:/sbin/getty -L ttygserial 115200 vt100 > into /etc/inittab > kill -1 1 > > On the host > cu -l /dev/ttyACM0 > Login > ls -laR / > > Hang > > Reboot and repeat. Same on Kermit. > > Any help appreciated. > > Thanks > > Grahame Jordan > > hi, you can't use that serial? I can't get it why ls -laR / is important to you. I wouldn't do it on wearing devices like flash memory. Maybe ls -la /dev/ttygserial or /dev/ttyACM0 ? -- View this message in context: http://www.nabble.com/usb-serial-on-connex-tf4901044.html#a14042188 Sent from the Gumstix mailing list archive at Nabble.com. |
From: Grahame J. <gb...@th...> - 2007-11-30 22:07:50
|
notstix wrote: > > Grahame Jordan wrote: > >> Hi, >> >> I am looking at using USB serial on the connex board. >> I have managed to get it working somewhat. >> >> Buildroot 1161 >> >> When I connect to /etc/ttyACM0 vi a kermit or cu it connects and appears >> to work OK. >> However when I run something like: >> ls -laR / >> It hangs until I reboot the gumstix. >> >> Here is the process for getting g_serial running on the Gumstix >> >> mknod -m660 /dev/ttygserial >> modprobe g_serial use_acm-1 >> >> ACM registers on host OK >> >> add: >> ::respawn:/sbin/getty -L ttygserial 115200 vt100 >> into /etc/inittab >> kill -1 1 >> >> On the host >> cu -l /dev/ttyACM0 >> Login >> ls -laR / >> >> Hang >> >> Reboot and repeat. Same on Kermit. >> >> Any help appreciated. >> >> Thanks >> >> Grahame Jordan >> >> >> > > hi, > > you can't use that serial? I can't get it why ls -laR / is important to you. > I wouldn't do it on wearing devices like flash memory. Maybe ls -la > /dev/ttygserial or /dev/ttyACM0 ? > > Hi. Once serial over USB is setup on the Gumstix I can connect from a computer OK. "ls -laR /" is just an example. "ls -la" in root's dir does the same??. I get the same problem with other commands (buffer/timing)? than simple commands. The point is is that it locks up the port on the gumstix, which shows that something is broken and unusable for general use. I have to reboot the Gumstix to get it back. On the Gumstix it is /dev/ttygserial, on the Linux machine it is /dev/ttyACM0. The serial port params on the computer are 8N1 and no flow control. I tried it via Hyperterminal with exactly the same issue. Cheers Grahame |
From: notstix <art...@ho...> - 2007-12-01 08:57:22
|
Grahame Jordan wrote: > > ... > "ls -laR /" is just an example. "ls -la" in root's dir does the same??. > ... > ls -laR / list all files recursively(go through all subdirectories) using long format (permissions, owner, mod. time). ls -la / list all files only in / directory using long format These are not same. First has -R and it goes through all directory tree to list each folder contents, starting with directory you give as argument - in your case its root dir and it list ALL your root directory files and folders and it may take some time to do it. Is listing one file or directory (ls /etc) fast and does't lock your computer? ls --help -l use a long listing format -a, --all do not ignore entries starting with . -R, --recursive list subdirectories recursively -- View this message in context: http://www.nabble.com/usb-serial-on-connex-tf4901044.html#a14103272 Sent from the Gumstix mailing list archive at Nabble.com. |
From: Grahame J. <gb...@th...> - 2007-12-01 10:58:15
|
Hi, Mmmmm? When connected via ttyS0, ls -laR / works perfectly as it does via usbnet. Pointlessly lists all the files recursively, however it creates lots of traffic on the ports. Only when using usbserial connected via /dev/ttyACM0 on the computer to the Gumstix listening on /dev/ttygserial do I have problems. It hangs the port. Once the port hangs I can drop the module "kill -9 ttyName; rmmod g_serial" and reinsert it "modprobe g_serial use_acm=1" I can get it back, but as soon as I try it again it hangs. There is something wrong here. Has anyone had success with usb_serial on the gumstix? Am I doing something wrong with my setup? Cheers Grahame notstix wrote: > > Grahame Jordan wrote: > >> ... >> "ls -laR /" is just an example. "ls -la" in root's dir does the same??. >> ... >> >> > ls -laR / > list all files recursively(go through all subdirectories) using long format > (permissions, owner, mod. time). > ls -la / > list all files only in / directory using long format > > These are not same. First has -R and it goes through all directory tree to > list each folder contents, starting with directory you give as argument - in > your case its root dir and it list ALL your root directory files and folders > and it may take some time to do it. > Is listing one file or directory (ls /etc) fast and does't lock your > computer? > > ls --help > -l use a long listing format > -a, --all do not ignore entries starting with . > -R, --recursive list subdirectories recursively > |
From: Grahame J. <gb...@th...> - 2007-12-01 12:24:02
|
Hi, Even though the terminal on ttygserial is hung it is still sending commands. If I type reboot in the (apparently) frozen terminal the Gumstix reboots. So the problem is not in the port but probably in the terminal. I will investigate further. Any ideas appreciated. Cheers Grahame Grahame Jordan wrote: > Hi, > > Mmmmm? > When connected via ttyS0, ls -laR / works perfectly as it does via > usbnet. Pointlessly lists all the files recursively, however it creates > lots of traffic on the ports. > > Only when using usbserial connected via /dev/ttyACM0 on the computer to > the Gumstix listening on /dev/ttygserial do I have problems. It hangs > the port. > > Once the port hangs I can drop the module "kill -9 ttyName; rmmod > g_serial" and reinsert it "modprobe g_serial use_acm=1" I can get it > back, but as soon as I try it again it hangs. There is something wrong here. > > Has anyone had success with usb_serial on the gumstix? > Am I doing something wrong with my setup? > > Cheers > > Grahame > > notstix wrote: > >> Grahame Jordan wrote: >> >> >>> ... >>> "ls -laR /" is just an example. "ls -la" in root's dir does the same??. >>> ... >>> >>> >>> >> ls -laR / >> list all files recursively(go through all subdirectories) using long format >> (permissions, owner, mod. time). >> ls -la / >> list all files only in / directory using long format >> >> These are not same. First has -R and it goes through all directory tree to >> list each folder contents, starting with directory you give as argument - in >> your case its root dir and it list ALL your root directory files and folders >> and it may take some time to do it. >> Is listing one file or directory (ls /etc) fast and does't lock your >> computer? >> >> ls --help >> -l use a long listing format >> -a, --all do not ignore entries starting with . >> -R, --recursive list subdirectories recursively >> >> > > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: The Future of Linux Business White Paper > from Novell. From the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > |
From: notstix <art...@ho...> - 2007-12-01 13:45:31
|
Grahame Jordan wrote: > > Hi, > > Even though the terminal on ttygserial is hung it is still sending > commands. If I type reboot in the (apparently) frozen terminal the > Gumstix reboots. So the problem is not in the port but probably in the > terminal. I will investigate further. Any ideas appreciated. > > Cheers > > Grahame > Hi, try reset command if gumstix has it. It should reset terminal or something like that. I have used it if something makes my terminal unreadable garbage, like cat /dev/urandom or /dev/random generates special characters. If reset cleans your terminal then try simple for loop in bash. Let it echo some characters and see if it hangs your connection. for i in `seq 1 1000`; do echo "$i";done; -- View this message in context: http://www.nabble.com/usb-serial-on-connex-tf4901044.html#a14105266 Sent from the Gumstix mailing list archive at Nabble.com. |
From: Grahame J. <gb...@th...> - 2007-12-04 01:31:00
|
Hi Dave, Are you able to find that patch? I just tried the latest build_root 1565 and it is still the same. Thanks Grahame Dave Hylands wrote: > Hi Grahame, > > >> Even though the terminal on ttygserial is hung it is still sending >> commands. If I type reboot in the (apparently) frozen terminal the >> Gumstix reboots. So the problem is not in the port but probably in the >> terminal. I will investigate further. Any ideas appreciated. >> > > I seem to recall some issues with the serial gadget at work. We ran > into some flow control problems when we changed to a newer kernel and > discovered that the whole tty stuff had been redone. > > We wound up adding a patch to the serial gadget to allow it to flow > control properly. > > I'll try to remember to take a look on Monday and see what we patched. > > |
From: Grahame J. <gb...@th...> - 2007-12-05 03:05:19
|
Hi Dave, Thanks for getting that for me. I hand patched it to 2.6.21gum, but it is making no difference. To clarrify the problem, the terminal stops echoing back (Not locking up) With debug on g_serial there is still activity. I can run commands but no echo. For example from the /dev/ttygserial terminal I can echo "Hello" > /dev/ttyS0 and it comes up on the other terminal. Any ideas? Cheers Grahame Jordan Dave Hylands wrote: > Hi Grahame, > > >> Are you able to find that patch? >> >> I just tried the latest build_root 1565 and it is still the same. >> > > I've attached the patch we used at work. It's against 2.6.17, so it > might not apply cleanly to later kernel sources. > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: The Future of Linux Business White Paper > from Novell. From the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > ------------------------------------------------------------------------ > > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Dave H. <dhy...@gm...> - 2007-12-01 18:05:08
|
Hi Grahame, > Even though the terminal on ttygserial is hung it is still sending > commands. If I type reboot in the (apparently) frozen terminal the > Gumstix reboots. So the problem is not in the port but probably in the > terminal. I will investigate further. Any ideas appreciated. I seem to recall some issues with the serial gadget at work. We ran into some flow control problems when we changed to a newer kernel and discovered that the whole tty stuff had been redone. We wound up adding a patch to the serial gadget to allow it to flow control properly. I'll try to remember to take a look on Monday and see what we patched. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Dave H. <dhy...@gm...> - 2007-12-04 16:02:58
Attachments:
serial-gadget-flow-control.patch
|
Hi Grahame, > Are you able to find that patch? > > I just tried the latest build_root 1565 and it is still the same. I've attached the patch we used at work. It's against 2.6.17, so it might not apply cleanly to later kernel sources. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Dave H. <dhy...@gm...> - 2007-12-05 04:14:58
|
HI Grahame, > Thanks for getting that for me. > > I hand patched it to 2.6.21gum, but it is making no difference. > > To clarrify the problem, the terminal stops echoing back (Not locking up) > > With debug on g_serial there is still activity. I can run commands but > no echo. > For example from the /dev/ttygserial terminal I can echo "Hello" > > /dev/ttyS0 and it comes up on the other terminal. > > Any ideas? Since you're still able to run commands, try using stty sane That should at least turn echo back on etc. Also try to do a "Reset" from the terminal software. I know that echoing certain commands to the terminal program can cause it to switch fonts and do other funky stuff. The real thing is to figure out why it's going wonky in the first place. I'm pretty sure that the ls -laR is definitely going to generate data much faster then the USB/serial interface can deal with it. Are you sure that you're running the patched kernel? I know sometimes it's hard to tell. I often have to put a printk in somewhere just to prove to myself that I really am using the modified code. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Grahame J. <gb...@th...> - 2007-12-06 23:19:18
|
Hi Dave, I have tried reset on kermit and in the terminal. The patch is applied. Tried stty -F /dev/ttygserial sane I actually get the problem if I "ls -la" in root's home dir which is very little data. Sometime if I edit a file with vi it hangs also. I enabled core-Utils and unix-utils in buildroot and took out everything in busybox. Still the same. So I think that it is in the g_serial driver. With debug in g_serial I get by pressing enter after it has hung: Jan 1 02:54:40 flowmeter user.debug kernel: gs_flush_chars: (0,c3fdb000) Jan 1 02:54:40 flowmeter user.debug kernel: gs_write_room: (0,c3fdb000) room=8185 Jan 1 02:54:40 flowmeter user.debug kernel: gs_flush_chars: (0,c3fdb000) Jan 1 02:54:40 flowmeter user.debug kernel: gs_write: (0,c3fdb000) writing 0 bytes Jan 1 02:54:40 flowmeter user.debug kernel: gs_write_room: (0,c3fdb000) room=8185 Jan 1 02:54:40 flowmeter user.debug kernel: gs_put_char: (0,c3fdb000) char=0xd, called from c00e1a1c, 00000000, 00000000 Jan 1 02:54:40 flowmeter user.debug kernel: gs_put_char: (0,c3fdb000) char=0xa, called from c00e1b1c, 00000000, 00000000 Jan 1 02:54:40 flowmeter user.debug kernel: gs_flush_chars: (0,c3fdb000) Jan 1 02:54:40 flowmeter user.debug kernel: gs_ioctl: (0,c3fdb000,c0289620) cmd=0x5402, arg=3204414152 Jan 1 02:54:40 flowmeter user.debug kernel: gs_ioctl: (0,c3fdb000,c0289620) cmd=0x5401, arg=3204414152 Jan 1 02:54:40 flowmeter user.debug kernel: gs_ioctl: (0,c3fdb000,c0289620) cmd=0x5401, arg=3204414160 Jan 1 02:54:40 flowmeter user.debug kernel: gs_ioctl: (0,c3fdb000,c0289620) cmd=0x5402, arg=3204414152 Jan 1 02:54:40 flowmeter user.debug kernel: gs_ioctl: (0,c3fdb000,c0289620) cmd=0x5401, arg=3204414152 Jan 1 02:54:40 flowmeter user.debug kernel: gs_write_room: (0,c3fdb000) room=8183 Jan 1 02:54:40 flowmeter user.debug kernel: gs_flush_chars: (0,c3fdb000) Jan 1 02:54:40 flowmeter user.debug kernel: gs_write: (0,c3fdb000) writing 2 bytes Jan 1 02:54:40 flowmeter user.debug kernel: gs_write: (0,c3fdb000) wrote 2 bytes Jan 1 02:54:40 flowmeter user.debug kernel: gs_flush_chars: (0,c3fdb000) I need to unload g_serial and reload it to get back the terminal Thanks Grahame Jordan Dave Hylands wrote: > HI Grahame, > > >> Thanks for getting that for me. >> >> I hand patched it to 2.6.21gum, but it is making no difference. >> >> To clarrify the problem, the terminal stops echoing back (Not locking up) >> >> With debug on g_serial there is still activity. I can run commands but >> no echo. >> For example from the /dev/ttygserial terminal I can echo "Hello" > >> /dev/ttyS0 and it comes up on the other terminal. >> >> Any ideas? >> > > Since you're still able to run commands, try using > > stty sane > > That should at least turn echo back on etc. > > Also try to do a "Reset" from the terminal software. I know that > echoing certain commands to the terminal program can cause it to > switch fonts and do other funky stuff. The real thing is to figure out > why it's going wonky in the first place. > > I'm pretty sure that the ls -laR is definitely going to generate data > much faster then the USB/serial interface can deal with it. > > Are you sure that you're running the patched kernel? I know sometimes > it's hard to tell. I often have to put a printk in somewhere just to > prove to myself that I really am using the modified code. > > |