On 28.08.2012 01:59, James Harper wrote:

quoted

On 27/08/2012 21:18, Joseph Glanville wrote:

quoted

On 28 August 2012 06:15, Jonathan Tripathy [off-list ref] 

wrote:

quoted

quoted

On 27/08/2012 21:07, Jonathan Tripathy wrote:

quoted

On 27/08/2012 21:00, Jonathan Tripathy wrote:

quoted

quoted

2) The windows setup didn't complain that it couldn't install 

on

quoted

quoted

quoted

quoted

quoted

the LV, but once I clicked 'next', the Dom0 crashed and the 

server

quoted

quoted

quoted

quoted

quoted

rebooted. A lot of output was displayed on screen but quickly
vanished as the system rebooted. I'm trying to see if the 

output

quoted

quoted

quoted

quoted

quoted

was saved anywhere. Any ideas why this could of happened 

and/or
where the output might be saved?

quoted

quoted

quoted

quoted

quoted

I'd also like to add that after the server came back up, the md
raid array started rebuilding. I wondering if that's just a
coincidence (due to the forced reboot), or a sign of something
wrong with the md integration with bcache?

I'm going to see if Windows installs natively on the md array 

(it's

quoted

quoted

quoted

quoted

RAID
10 btw) and post back here.

Ok, so trying to install Windows directly onto the spindles 

causes

quoted

quoted

quoted

the same thing to happen. I'm going to try and boot up into the
non-bcache kernel (The default ubuntu one) and see if it works
there. If it fails there, then this is clearly a xen and/or 

mdraid issue...

quoted

quoted

quoted

Thanks

Ok, so booting into the default Ubuntu kernel, the windows
installation seems to progress just fine.

Does this mean there is something wrong with the mdraid code in 

the

quoted

quoted

bcache kernel?

Actually, I'm not telling the whole story. The kernel I'm using 

is

quoted

quoted

the
bcache-3.2 tree (from evilpriate.org) with changes merged in from
kernel.org's 3.2.27 tree. There were no merge conflicts when I 

did

quoted

quoted

the git merge.

What do you think I should do?


Thanks

--
To unsubscribe from this list: send the line "unsubscribe
linux-bcache" in the body of a message to 

majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org

quoted

quoted

More majordomo info at  

http://vger.kernel.org/majordomo-info.html

quoted

I would recommend booting with the raw bcache-3.2 branch before
applying the stable patches (even though they should be fine) and
trying to catch the panic.
This is easiest done with a serial port and setting it to the 

kernel

quoted

console on the kernel command line in grub.

Joseph.

Hi There,

I can confirm that the problem occurs even when using the raw 
bcache-3.2
branch from evilpirate.org. Just to clarify, I am trying to install 
Windows
Server 2008 in a Xen HVM DomU, onto an LV which is on top of a 
MDRAID 10
array. Using the bcache-3.2 kernel, the system reboots (after
panicing) as soon as I click 'next' after selecting the drive to 
install windows
onto. Using the standard Ubuntu kernel everything works as normal. 
This
leads me to believe that there is an issue with the mdraid code 
inside the
bcache-3.2 tree. I'd like to stress that I wasn't doing any bcaching 
during this
test.

FWIW, i'm using the 3.2 patches applied to a Debian kernel with lvm
on raid1 (not raid10) on bcache and it's all working fine since I
changed to a 512 byte block size. I haven't done an install of 2008,
just 2003, but there doesn't seem to be any problems.

Hi James,

That's very interesting. However, my problem occurs regardless of 
whether I'm using a bcache or not. I will try to see if the problems 
happens with Windows 2003 and I'll also try RAID1.

That's a good idea about the netconsole, I'll give that a go!

Out of interest, do you see poor fio benchmark performance when using a 
512 byte block size?