[<<] [<] Page 1 of 1 [>] [>>] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
nano-X: GsRead failed -1 0: 131
From: "mah_list1" ####@####.#### Date: 2 Sep 2007 19:45:27 +0100 Message-Id: <0FAE9359F7A9324F998A42FCA7C734B618EC55@mail.cfsi.dk> Hi I am struggling with an error. Am running a demo setup where a nano-x app is started and exited many many times. But the sometimes the app stops, i get "nano-X: GsRead failed -1 0: 131" on terminal, and the app i wrote is not killable as it sits in kernelspace lock'd in a disk read. looks like this in ps 907 root 652 S nano-X 913 root 272 S nanowm 915 root DW [pmmd_big] Looking in the source it seams that the error on terminal is coming from the server. If I look in /proc/915/fd no files is open by pmmd_big I only found few pointers in archive about this, but no real help. Regards Martin Hansen | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
SV: [nanogui] nano-X: GsRead failed -1 0: 131
From: "mah_list1" ####@####.#### Date: 2 Sep 2007 23:13:14 +0100 Message-Id: <0FAE9359F7A9324F998A42FCA7C734B618EC57@mail.cfsi.dk> > But the sometimes the app stops, i get "nano-X: GsRead failed -1 0: 131" on terminal, and the app i wrote is not killable as it sits in kernelspace > lock'd in a disk read. Further logging shows that it is the call to getNectEvent, and even getNectEventTimeout, I sense a smell of error in the select() in uClib. Regards Martin Hansen | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Re: [nanogui] nano-X: GsRead failed -1 0: 131
From: "Greg Haerr" ####@####.#### Date: 3 Sep 2007 02:01:54 +0100 Message-Id: <018201c7edc5$9e870ee0$2f01a8c0@HaydenLake> > Further logging shows that it is the call to getNectEvent, and even > getNectEventTimeout, I sense a smell of error in the select() in uClib. Well, the client will be hanging on a pipe read from the network socket connection to the server. Could be a strange kernel issue where for some reason the client process can't be awoken and hangs after the other process side of the pipe is killed... ? If you only have one application running, then you can use the LINK_APP_INTO_SERVER option and eliminate the pipe connection. Regards, Greg | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[<<] [<] Page 1 of 1 [>] [>>] |