On Thu, Aug 30, 2001 at 07:47:59AM +0200, Florian Schaefer wrote:
> In addition to the problem with my coda-server I just encountered another
> problem.
> 
> I decided to give ext3 on my laptop a try and made a new 2.4.9 kernel
> with the patch from this URL:
> http://www.zip.com.au/~akpm/ext3-2.4-0.9.6-249.gz

I looked at that patch and they use ext3_file_write which uses
generic_file_write for most of the work, but syncrounous writes to the
container file in ext3 through the Coda kernel module will not get
journalled. So it basically should work.

> kernel BUG at inode.c:201!
> invalid operand: 0000
> CPU:	0
> EIP:	0010:[<c883f991>]
> EFLAGS: 00010286
> eax: 0000001b	ebx: c6ea75e0	ecx: 00000004	edx: 00000000
> esi: 00000000	edi: c6ea75e0	ebp: c6c08800	esp: c6547d70
> ds: 0018   es: 0018   ss: 0018
> Process venus (pid: 535, stackpage=c6547000)
> Stack: c8845ca6 c88460bf 000000c9 00000000 c6ea75e0 c014234a c6ea75e0 00000000
>        00000000 00000000 6e6d6c6b c6547e9c c77ecf88 00000401 c6c08800 c0142592
>        c6c08800 00000401 c77ecf88 c883eee0 c6547e9c 00000282 c6ecfe40 00000d80
> Call Trace: [<c8845ca6>] [<c88460bf>] [<c014234a>] [<c0142592>] [<c883eee0>]
>  [<c883f058>] [<c883eee0>] [<c883f1e5>] [<c0112c7e>] [<c8849320>] [<c883f7f5>]
>  [<c8845fe0>] [<c8849420>] [<c88486c0>] [<c0133c9d>] [<c88486c0>] [<c0133f83>]
>  [<c88486c0>] [<c01347a4>] [<c88486c0>] [<c88486c0>] [<c011242b>] [<c0134a26>]
>  [<c012a034>] [<c01348dc>] [<c0134abc>] [<c0106ceb>]
> Code: 0f 0b 83 c4 0c 81 c3 0c 01 00 00 53 e8 ae fb ff ff 59 85 c0
> 
> I know that those lines are specific to my system and you won't be able
> to make something out of it. So please tell my what I have to do to help
> you. Are there any known problems with coda and ext3 support?

Run the thing through "ksymoops" to get the actual procedures + line
number information of the stacktrace as well as a little dissasembly of
the code surrounding the place where it oopsed.

However, looking at my sources (2.4.10-pre2), which should be close
enough, it is probably the BUG() call in __sync_one when the inode is
still locked.

This could very well be a more generic bug as Coda doesn't influence
anything that is related to the inode locking/unlocking logic at all, so
I'd be very interested in a decoded copy of the OOPS to see how a locked
inode got passed to the __sync_one function.

Jan