inode state

[Fabian Thylmann]

> Hmm.  Kqueue should be thread-safe in that it's a system call, but I can't
> speak to the safety of various arguments/parameters.  I don't know if
> linuxthreads tries to provide locking around file descriptors and might
> have reference problems if kqueue were held over a call to close(), but it
> could be kqueue will "just work" with linuxthreads.  Do calls like
> select()/poll() require thread-safe versions in linuxthreads?

Yeah, select/poll is not needed, but the thing is that my app, which I just
changed from pthreads to linuxthreads, did all ok, launched threads and all,
but it crashed when running kevent() and all the referrences it gave to
kevent() were fine.

> Do you have an outstanding PR on the LSI problem, and/or a stack trace for
> the trap?  In the past, our LSI drivers have been fairly well maintained
> on the LSI side.  I can certainly try shaking some branches and see if
> anything falls down, if there's a detailed bug report I can point at.

I have no PR nor do I have a stack trace for the trap right now. How would I
exactly get a stack trace of the trap? It happends when booting from the
5.2-beta cd-rom. Let me know when you need from me and I'll get all that.
The box is at a hosting provider so I'll have to get the info from them.

> I know some work has been done relating to this problem at Yahoo,
> especially relating to disk fragmentation resulting from allocation using
> mmap on sparse files.  You might want to try posting about this problem on
> freebsd-fs or freebsd-current and see if you manage to hook someone who's
> been looking at this.

Thanks, I'll give that a try.

Fabian