Dear list, Sujal

This is part of a posting of Sujal's from 19th September, 2001:

> The Linux Coda drivers and the ext3 patches don't seem to get along
> very well, at least in Linux 2.4.7. I've got a stock 2.4.7 kernel with
> a patch applied to the USB drivers (for a sony digital camera; see
> http://www.sujal.net/tech/linux/ just a change in unusual_devs.h).
>
> After I applied the ext3 patches from
> http://www.uow.edu.au/~andrewm/linux/ext3/ 
> <http://www.uow.edu.au/%7Eandrewm/linux/ext3/> . Basically, when an
> application tries to write to a file system mounted via coda, the
> application terminates with "Memory Fault" returned to the terminal.
> THe file system still thinks it's busy (can't umount).
>

[snip]

I am finding exactly (well, nearly exactly) the same thing.  I've just 
upgraded my laptop from RH7.1 to RH7.2 and, when asked by the installer 
whether I'd like to convert from ext2 to ext3, I thought, yeah, why not, 
and went ahead.  Maybe that was a mistake!

My laptop is a pretty stock standard Linux laptop, acting as a Coda 
client.  I haven't applied the patches referred to above (are they an 
integral part of RH7.2 now?), but I'm seeing the same symptoms, i.e., 
try to write to Coda filesystem and the writer dies with a segmentation 
fault, then /coda can't be unmounted.

Here is the result of an attempt to save an emacs session, as seen in 
the syslog:

Jan 16 14:17:30 point kernel: Coda Kernel/Venus communications, v5.3.14, coda_at_cs.cmu.edu
Jan 16 14:17:31 point kernel: coda_read_super: device index: 0
Jan 16 14:17:31 point kernel: coda_read_super: rootfid is (0x7f000000,0x1,0x1)
Jan 16 14:17:31 point kernel: coda_read_super: rootinode is 1025 dev 8
Jan 16 14:20:53 point kernel: kernel BUG at file.c:45!
Jan 16 14:20:53 point kernel: invalid operand: 0000
Jan 16 14:20:53 point kernel: CPU:    0
Jan 16 14:20:53 point kernel: EIP:    0010:[usbcore:__insmod_usbcore_S.bss_L96+37964324/173854876]
Jan 16 14:20:53 point kernel: EIP:    0010:[<d2ca13c4>]
Jan 16 14:20:53 point kernel: EFLAGS: 00010282
Jan 16 14:20:53 point kernel: eax: 00000019   ebx: cefda120   ecx: 00000001   edx: 000022a5
Jan 16 14:20:53 point kernel: esi: ffffffea   edi: cfb32a20   ebp: cefda7e0   esp: cc291f64
Jan 16 14:20:53 point kernel: ds: 0018   es: 0018   ss: 0018
Jan 16 14:20:53 point kernel: Process emacs (pid: 1506, stackpage=cc291000)
Jan 16 14:20:53 point kernel: Stack: d2ca878e 0000002d cefda7e0 ffffffea 00000000 000006da c01355e6 cefda7e0
Jan 16 14:20:53 point kernel:        bfffa650 000006da cefda800 00000010 00000003 cefda7e0 c1723d40 cd2e8000
Jan 16 14:20:53 point kernel:        c013504d c1723d40 cd2e8000 cc290000 bfffa650 00000000 bfffa628 c0106f0b
Jan 16 14:20:53 point kernel: Call Trace: [usbcore:__insmod_usbcore_S.bss_L96+37993966/173825234] [sys_write+150/208] [sys_open+125/176] [system_call+51/56]
Jan 16 14:20:53 point kernel: Call Trace: [<d2ca878e>] [<c01355e6>] [<c013504d>] [<c0106f0b>]
Jan 16 14:20:53 point kernel:
Jan 16 14:20:53 point kernel: Code: 0f 0b 5e 58 8b 43 08 8b 70 08 8d 5e 60 89 d9 ff 4e 60 0f 88

Why this manifests itself in usbcore is beyond my feeble skills in Linux 
kernel oops divination.  Has anyone else noticed this problem?  Should 
it be registered properly as a bug?  Is there yet a solution?  (I don't 
seem to be able to take Sujal's option of uninstalling a patch --- 
unless I uninstall RH 7.2!)

Any help would be most appreciated.

Cheers
- Vaughan

-- 
Vaughan Clarkson
School of Information Technology  |  ph. +61 7 3365 8834
  & Electrical Engineering        |  fax +61 7 3365 4999
The University of Queensland      |  mailto:v.clarkson_at_itee.uq.edu.au
Queensland, 4072, Australia       |  http://www.itee.uq.edu.au

** Please note the name change from CSEE to ITEE (effective 5-Oct-01)