For the record, unfortunately I managed to crash the kernel by active
(readonly) use of Coda together with Linux ABI.

Actually no surprise, we knew there is some wrongly implemented directory
access in the code. Hopefully this will disappear as soon as the
directory code is fixed. May be this is caused by something else, too.

Anyway:

I ran linux binaries, including many shared libraries, from Coda and the
system rebooted, leaving the local file system corrupted, including dups
on venus log.

An fsck, venus -init and a second try to run the same software caused a
similar panic, this time letting me read the console contents:

-------------------------------------------------------------------------------------------------
 ...
coda_inactive: 0xXXXXXXXX usecount 1
coda_inactive: 0xYYYYYYYY usecount 1
coda_inactive: 0xZZZZZZZZ usecount 1
uvm_fault(0xc0b69480, 0xfffff000, 1) -> 0xe
fatal page fault in supervisor mode
trap type 6 code 0 eip c0730157 cs 8 eflags 10213 cr2 fffffff8 ilevel 0
panic: trap
Begin traceback...
End traceback...

dumping to dev 0,1 offset 8
dump ahcisata0 port 0: device present, speed: 3.0Gb/s
ahcisata0: BSY never cleared, TD 0x80
97 96 [...downcount...] 67 66 [freeze]
-------------------------------------------------------------------------------------------------

(By the way, "coda_inactive: 0x.... usecount 1" messages at least
somtimes repeat with repeating accesses, not only the first time as I
wrongly believed)

On Mon, Jan 16, 2012 at 03:19:04PM +0100, u-codalist-tccc_at_aetey.se wrote:
> Testing NetBSD 5.1.1 on i386 with Coda 6.9.5 via pkg_add.

I will be happy to troubleshoot and test further, given a guidance from a
NetBSD guru. Otherwise I hardly have the resources to dig deeper in this.
Greg, would you give me a hand?

It would be really nice to have another platform besides Linux to be
able to reliably run Coda on.

Regards,
Rune