On Wed, Feb 23, 2005 at 01:33:00PM -0800, Mark Milano wrote:
> I am not sure if this is the right place, but I REALLY
> need some help and I am not getting it.

Probably not the right place. I've never played with davfs, but I do
know a bit about the Coda kernel module.

> DAVFS2 0.2.3 opend : /dev/davfs0
> Ready to be mount!!Trying to mount!!got 056 byte
> command: opcode = 00  (uid=476847211,euid=0,
> suid=0,fsuid=0) CODA OPCODE: 0
>  unimplemented coda call returning FAILURE (90), 12
> bytes 

Yeah, there is no opcode 0, the first upcall should have opcode 2
(CODA_ROOT), which is used to get the file identifier of the object that
is supposed to get mounted on top of /coda (probably /davfs in your
case). Also that uid looks pretty bad, 476847211 is something like
0x1c6c1c6b, which looks like some sort of a debugging pattern (although
the typical slab poisoning pattern is 0x5a).

The size of that upcall (56 bytes) seems to match an otherwise empty
upcall similar to CODA_ROOT using the old API, which pretty much matches
what I'd expect with a linux 2.4 kernel (by quick calculation the
coda_in_hdr would be about 58 bytes). If my calculation of 58 bytes is
right we somehow had a short read which might have shifted everything by
2 bytes, but even looking at everything shifted 2 bytes, in that case
the opcode would still not be 0, and the uid still doesn't make sense.

Now if your userspace was built so that it is expecting the new style
upcalls, which were introduced in 2.6 and are available as a backport
to 2.4, the opcode field didn't move between the two so even that
doesn't explain the 00 opcode.

> Please let me know what I need to do.

Don't really know, check the kernel logs for messages, maybe the other
side (Coda kernel module) has some interesting things to report as well.

Jan