linux emulation problem on releng6/7

Gary gary at velocity-servers.net
Wed Nov 8 04:06:51 UTC 2006


At 04:02 PM 11/6/2006, Dan Nelson wrote:
>In the last episode (Nov 06), Alexander Leidinger said:
> > Quoting Gary <gary at velocity-servers.net> (from Mon, 06 Nov 2006
> > 01:49:23 -0500):
> >
> > Redirecting to emulation@, ENOTIME until the weekend on my side ATM...
> >
> > Bye,
> > Alexander.
> >
> > >With VALVe's Counter-Strike Source server, I noticed some strange
> > >cpu usage readings (among other things)
> > >
> > >ktrace:
> > >
> > > 80786 srcds_amd CALL  old.recv(0x5,0xbfbfb480)
> > > 80786 srcds_amd RET   old.recv -1 errno -11 Unknown error: -11
>
>Running linux_kdump would give you more useful output here.  Errno 11
>on Linux is EAGAIN, and syscall 102 is socketcall.  Call #5 is
>SYS_ACCEPT, so it looks like it's trying to accept() a connection on a
>listening socket with no pending connections.
>
>--
>         Dan Nelson
>         dnelson at allantgroup.com


Here's with linux_kdump:

    658 srcds_amd CALL  gettimeofday(0xbfbfc5d0,0)
    658 srcds_amd RET   gettimeofday 0
    658 srcds_amd CALL  linux_socketcall(0x5,0xbfbfb4d0)
    658 srcds_amd RET   linux_socketcall -1 errno 11 Resource deadlock avoided
    658 srcds_amd CALL  gettimeofday(0xbfbfc5e0,0)
    658 srcds_amd RET   gettimeofday 0
    658 srcds_amd CALL  gettimeofday(0xbfbfc5b0,0)
    658 srcds_amd RET   gettimeofday 0
    658 srcds_amd CALL  linux_socketcall(0xc,0xbfbe4d40)
    658 srcds_amd RET   linux_socketcall -1 errno 11 Resource deadlock avoided
    658 srcds_amd CALL  gettimeofday(0xbfbfb4c0,0)
    658 srcds_amd RET   gettimeofday 0
    658 srcds_amd CALL  gettimeofday(0xbfbfc590,0)
    658 srcds_amd RET   gettimeofday 0
    658 srcds_amd CALL  gettimeofday(0xbfbfc5b0,0)
    658 srcds_amd RET   gettimeofday 0
    658 srcds_amd CALL  nanosleep(0xbfbfc830,0)
    658 srcds_amd RET   nanosleep 0
    658 srcds_amd CALL  linux_select(0x1,0xbfbfc670,0,0,0xbfbfc5e8)
    658 srcds_amd RET   linux_select 1

Strange, though, is linux_socketcall() the culprit for the strange 
error, or is it something else?





More information about the freebsd-emulation mailing list