In the last episode (Feb 03), Walter C. Pelissero said:
> I tried linux_kdump (from ports) and things seem to clarify a bit.
> 
> I concentrated on acushare, which is the daemon that supervises
> inter-process locking (locking on file access) and licence
> verification.  Whereas acushare seems to start properly, an attempt to
> kill it through the recommended means (not with kill(1)), yields an
> IPC error.  On Linux strace on the daemon process shows:
> 
>   msgrcv(256, {1, "\254\1\0\0\6\0\0\0\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...}, 100, 
> 1, MSG_NOERROR) = 12
>   getpid()                                = 376
>   getuid32()                              = -1 ENOSYS (Function not implemented)
>   msgctl(256, IPC_STAT, 0xbffffa54)       = 0
>   msgsnd(256, {428, "x\1\0\0\6\0\0\0\6\0\0\0"}, 12, 0) = 0
> 
> That is, msgrcv returns a 12 bytes long message and the daemon
> answers.  On FreeBSD, on the other hand:
> 
>   75838 acushare RET   linux_ipc 12/0xc
>   75838 acushare CALL  linux_getpid
>   75838 acushare RET   linux_getpid 75838/0x1283e
>   75838 acushare CALL  linux_ipc(0xe,0x50000,0x102,0,0xbfbff444,0)
>   75838 acushare RET   linux_ipc -1 errno 22 Invalid argument
>   75838 acushare CALL  linux_time(0xbfbff49c)
>   75838 acushare RET   linux_time 1075830865/0x401fe051
>   75838 acushare CALL  write(0,0x2806f000,0x4a)
>   75838 acushare GIO   fd 0 wrote 74 bytes
>       "acushare: 2004-02-03 18:54:25: Error replying to test message from run\
>        cbl
>       "
> 
> That is, linux_ipc (possibly a catch-all name for the Linux IPC
> functions family), returns a 12 bytes long message, but when it is
> supposed to do the msgctl it fails miserably with an errno 22.
> 
> I couldn't make sense out of the six arguments to linux_ipc shown in
> the kdump.  Does anyone know how to interprete them?

linux_ipc is emulated in /sys/<machine>/linux/linux_machdep.c, and in
linux.h:

#define LINUX_MSGCTL            14

so the switch() in linux_ipc ends up calling linux_msgctl in
/sys/compat/linux/linux_ipc.c.

Do you have SYSV message queues enabled in your kernel?  Stick "options
SYSVMSG" in your config file and rebuild, or "kldload sysvmsg" if you
have the module.

If you do have sysvmsg loaded, you may have to start adding printfs in
linux_msgctl() to trace which call is failing and why.

-- 
        Dan Nelson
        [EMAIL PROTECTED]
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to