Date: Thu, 27 Sep 2007 16:31:58 -0400 (EDT) From: "Tuc at T-B-O-H.NET" <ml@t-b-o-h.net> To: jhein@timing.com (John E Hein) Cc: emulation@freebsd.org Subject: Re: Signal 12 on simple ldd / Linux Message-ID: <200709272031.l8RKVwXs022474@himinbjorg.tucs-beachin-obx-house.com> In-Reply-To: <18172.2105.13764.795975@gromit.timing.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > John E Hein wrote at 13:26 -0600 on Sep 27, 2007: > > Tuc at T-B-O-H.NET wrote at 14:17 -0400 on Sep 27, 2007: > > > I'm finding out that this also ISN'T happening on systems where > > > the Linux install is local, and used local. I'm finding 100% so far that > > > it only happens where /compat is NFS mounted. Is this something someone > > > has ever done, and are there any gotchas that I am running into because > > > of it, or is it just "One of those things you figure out that leads you > > > down the completely wrong path". > > > > We mount /compat/linux over NFS. I have not found any problems like > > the one you are having with it after doing so on some boxes for years > > (from 4.x to 6.x). Sometimes, I experience permission problems if, > > for instance, the app tries to write to /var/db or something (I don't > > export it with maproot=0). So occasionally I'll add a sym link in > > the nfs compat/linux tree to point to a local native directory. > > Is there any file locking that the app might be doing? If it tries to > lock a file in /var/db or something, it might try to lock the file in > /compat/linux/var/db. I don't remember if 5.3 (which is what you are > running) supports proper nfs file locking (nfs locking in 4.x just > always successfully gives out a lock, so if multiple lockers try to > lock a file, they will all think they own the lock resulting in > possible file corruption depending on how the lock is used), but you > do have to make sure lockd and friends are running to get nfs locking > to work. > Unfortunately, I really wouldn't know. The binary is from the "SHA-1 Collision Search Graz" BOINC project. Its closed source. I had just done testing on an addition I made to the ports tree for it, when I finally went to test on one of the NFS mounted servers. Since there isn't source to it, I can't gdb/backtrace a copy. I've run many different apps that do use locking, and Hylafax oddly enough was the only one that ever presented a locking issue. I pretty much got blown off on the list for help. I did run a sample program that was made to test all sorts of locking, and I never got it to fail. I run lockd/statd on all servers involved ever since they started to run in mid 2005. I guess I go back to that linux_modify_ldt. On the bad copy I see : > 82825: #243() ERR#78 'Function not implemen te > d' > SIGNAL 12 (SIGSYS) > SIGNAL 12 (SIGSYS) > Process stopped because of: 16 > process exit, rval = 140 > Bad system call which makes me think that it did the #243, and got the not implemented, and the next command is the system call it didn't understand. Again, I could be barking up a wrong tree, especially with this being limited to the NFS'd machines. If I can find the time, as much as I hate to, I might pull a "Winderz" and reboot.. I did set the linux up after the system had started, so maybe something isn't right. It probably has nothing to do with /proc and linprocfs's, since one machine I use has both, one only has /proc.....(Oddly, though, the NFS'd systems /proc DOES NOT have "currproc". Not sure if that means anything to anyone or anything.......... Thanks, Tuc
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200709272031.l8RKVwXs022474>