From owner-freebsd-emulation@FreeBSD.ORG Thu Sep 27 20:32:05 2007 Return-Path: Delivered-To: emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5252116A418; Thu, 27 Sep 2007 20:32:05 +0000 (UTC) (envelope-from ml@t-b-o-h.net) Received: from vjofn.tucs-beachin-obx-house.com (vjofn-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::5e5]) by mx1.freebsd.org (Postfix) with ESMTP id ECC6213C46E; Thu, 27 Sep 2007 20:32:04 +0000 (UTC) (envelope-from ml@t-b-o-h.net) Received: from himinbjorg.tucs-beachin-obx-house.com (cpe-68-175-8-11.hvc.res.rr.com [68.175.8.11]) (authenticated bits=0) by vjofn.tucs-beachin-obx-house.com (8.12.9/8.12.9) with ESMTP id l8RKW4BJ035517; Thu, 27 Sep 2007 16:32:04 -0400 (EDT) Received: from himinbjorg.tucs-beachin-obx-house.com (localhost.tucs-beachin-obx-house.com [127.0.0.1]) by himinbjorg.tucs-beachin-obx-house.com (8.13.8/8.13.6) with ESMTP id l8RKVwjx022475; Thu, 27 Sep 2007 16:31:58 -0400 (EDT) (envelope-from ml@t-b-o-h.net) Received: (from tbohml@localhost) by himinbjorg.tucs-beachin-obx-house.com (8.13.8/8.13.6/Submit) id l8RKVwXs022474; Thu, 27 Sep 2007 16:31:58 -0400 (EDT) (envelope-from tbohml) From: "Tuc at T-B-O-H.NET" Message-Id: <200709272031.l8RKVwXs022474@himinbjorg.tucs-beachin-obx-house.com> To: jhein@timing.com (John E Hein) Date: Thu, 27 Sep 2007 16:31:58 -0400 (EDT) In-Reply-To: <18172.2105.13764.795975@gromit.timing.com> X-Mailer: ELM [version 2.5 PL8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: emulation@freebsd.org Subject: Re: Signal 12 on simple ldd / Linux X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2007 20:32:05 -0000 > > 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