Date: 02 Nov 1998 02:28:26 -0600 From: stephen farrell <stephen@farrell.org> To: John Fieber <jfieber@indiana.edu> Cc: freebsd emulation list <emulation@FreeBSD.ORG> Subject: Linux/Sybase on FreeBSD problems Message-ID: <874ssi5wid.fsf@couatl.uchicago.edu> In-Reply-To: John Fieber's message of "Mon, 2 Nov 1998 02:03:28 -0500 (EST)" References: <Pine.BSF.4.05.9811020151220.394-100000@fallout.campusview.indiana.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
emulation ppl: John and I have identical (well as close as we can muster) setups running FreeBSD-3.0R. His runs linux sybase; mine doesn't. We've gone through making sure we have all the same binaries, etc. The problem I have is when the server is first starting up... it seems to get a SEGV after doing a significant amount of work. This result is highly reproducible -- the SEGV always happens at the same time, after reading the same data). John Fieber <jfieber@indiana.edu> writes: > On 2 Nov 1998, stephen farrell wrote: > > > http://people.healthquiz.com/~sfarrell/traces/linux_kdump.sf > > http://people.healthquiz.com/~sfarrell/traces/linux_kdump.jf > > > > might this be a race? > > The sigalarms after your SEGV are probably not comparable. As > for the absence of ALRMs up until very near then end, recall that > they are real time based so the fact that you have a wicked fast > CPU, wads of RAM for cache, and I'll bet positively sizzling > disks as well. Consequently I'll be getting a lot more ALRMs sf: p2/400 256MB jf: AMD ?? 64MB > than you during the startup just because it takes my machine a > while to slog through the process. I see--that makes sense. But still, it seems odd to me that the first time I catch a SIGALRM bad stuff happens... > I initially paid a bunch of attention to this when comparing with > a syscall trace made on a linux machine, then realized what was > going on and that it wasn't actually important. The ALRM handler > gets installed pretty early on and if I start the server fresh > and it all has to page in, I get a lot of signals going off > during startup. The second time around, not nearly so many since > everything is in cache and takes much less time. > > Incidentally, when comparing the traces, ran the linux one (the > reference) through cat -n, then went through the marking > corresponding line numbers of various "landmark" events, and in > much more detail in suspicious looking spots. It worked pretty > well and should be much easier for you since both of your traces > are in the same format. :) Hmm... well, yours installs the signal handler here (I'm assuming the memory addresses match up, which might be dubious): There is no sigalrm at this time. 1088 15462 dataserver RET read 2048/0x800 1089 15462 dataserver CALL linux_newselect(0,0x85c56a8,0,0,0x85c55a0) 1090 15462 dataserver RET linux_newselect 0 1091 15462 dataserver CALL linux_sigaction(0x1d,0x85c5494,0) 1092 15462 dataserver RET linux_sigaction 0 1093 15462 dataserver CALL linux_lseek(0x5,0x2800,0) 1094 15462 dataserver RET linux_lseek 10240/0x2800 1095 15462 dataserver CALL read(0x5,0x90be000,0x800) 1096 15462 dataserver GIO fd 5 read 2048 bytes Which is the one mine chokes on here: 26405 434 dataserver CALL linux_sigaction(0x1d,0x85c5494,0) 26406 434 dataserver RET linux_sigaction 0 26407 434 dataserver PSIG SIGSEGV caught handler=0x82955cc mask=0x0 code=0 As far as I can tell, the two traces are pretty much lock-step cruising through the master.dat file, but then mine bails as soon as it gets the SIGALRM. The turning point appears to be 0x5d9800. I guess since they do, in fact, differ, that mine must be trying to do a slightly different thing, which could be significant. Look at http://www.people.healthquiz.com/~sfarrell/traces/seek.txt (jf's trace is on the left; the filehandle replaced by "FH" is master.dat) -- Steve Farrell To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-emulation" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?874ssi5wid.fsf>