[ENBD] fr1 hangs when trying to access raid device..

[Arve Emil Myrås]

>Oh, OK! That's an oops. But in any case, can you now repeat WITHOUT
>doing a mke2fs? Or if you do do a mke2fs, use a block count (-b 1024
>2048, I believe, in this case).
>Stick to loopback now that it's known you can do it with loop.

will do..

>mke2fs deliberately writes beyond the device bounds. That should
>cause an error condition. It may be that I didn't handle the error
>condition correctly. Anyway, to confirm, see if you can read and write
>the device normally (using dd), aand then see if giving the device size
>explicitly to mke2fs helps. That would confirm.

Tried with: 
dd if=/dev/zero of=/dev/md0 bs=1024 count=200
and it hangs in the same instant that i press enter (this is with the smp-kernel)...

Tried with a non-smp kernel an smp disabled in bios and this time the system doesn't freeze that compleatly an the syslog spits out:
Feb  4 16:50:59 vserv kernel: fr1 hotadd component 07:00[0] to device 0
Feb  4 16:50:59 vserv kernel: fr1 added new device 07:00 to f76d8e00 with err 0
Feb  4 16:50:59 vserv kernel: fr1 ioctl 40140921
Feb  4 16:50:59 vserv kernel: fr1 hotadd component 07:01[1] to device 0
Feb  4 16:50:59 vserv kernel: fr1 added new device 07:01 to f76d8e00 with err 0
Feb  4 16:50:59 vserv kernel: fr1 ioctl 400c0930
Feb  4 16:51:10 vserv kernel: fr1 ioctl 1260
Feb  4 16:51:10 vserv kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000010
Feb  4 16:51:10 vserv kernel:  printing eip:
Feb  4 16:51:10 vserv kernel: fae40c08
Feb  4 16:51:10 vserv kernel: *pde = 00000000
Feb  4 16:51:10 vserv kernel: Oops: 0000
Feb  4 16:51:10 vserv kernel: CPU:    0
Feb  4 16:51:10 vserv kernel: EIP:    0010:[<fae40c08>]    Not tainted
Feb  4 16:51:10 vserv kernel: EFLAGS: 00010046
Feb  4 16:51:10 vserv kernel: eax: 00000000   ebx: 00000000   ecx: c02e8b2c   edx: c02e8b2c
Feb  4 16:51:10 vserv kernel: esi: f62dfed0   edi: c02e8b2c   ebp: f62dfeb8   esp: f62dfea0
Feb  4 16:51:10 vserv kernel: ds: 0018   es: 0018   ss: 0018
Feb  4 16:51:10 vserv kernel: Process mke2fs (pid: 986, stackpage=f62df000)
Feb  4 16:51:10 vserv kernel: Stack: c01a31ed 00000000 c02e8b4c 00000286 f62dfed0 c1c01148 f62dfef0 c01a21e6
Feb  4 16:51:10 vserv kernel:        c02e8b2c f62dfed0 c011ad7d c02e8b2c c02e8b84 c02e8b84 c1a287b0 f62de000
Feb  4 16:51:10 vserv kernel:        c013a7a1 c02852c0 c0127ba6 c1a287b0 00000000 f62de000 c1c01148 c1c01148
Feb  4 16:51:10 vserv kernel: Call Trace:    [<c01a31ed>] [<c01a21e6>] [<c011ad7d>] [<c013a7a1>] [<c0127ba6>]
Feb  4 16:51:10 vserv kernel:   [<c012843e>] [<c0128820>] [<c0128998>] [<c0128820>] [<c01360b3>] [<c0108eff>]
Feb  4 16:51:10 vserv kernel:
Feb  4 16:51:10 vserv kernel: Code: 8a 43 10 8b 34 85 00 45 e4 fa 85 f6 0f 84 b6 00 00 00 8b 06

this was the same test as last with mke2fs,,, now running to do the same thing with dd....

-Arve Emil