Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Philipp Reisner wrote: > The backing storage's driver is the suspect here. So far I tested DRBD-8.0 > on UML and its udb block device driver as well on our main development > cluster (SCSI and Compaqs' CCISS driver) and on the borrowed testing > cluster from ThomasKrenn (3Ware controller is SCSI to the host, SATA to > the distsk) > > All test machines where SMP & HIGHMEM. > Linbit's development cluster: 2.6.15 & 2.6.16 mainline - vanilla Linus > TK's cluster CentOS's : 2.6.9-22.EL Ok, I get these oopses with both CentOS's 2.6.9-34.EL (default install) and with a xen-patched 2.6.16 incl. many of the patches from Fedora Core 5 (SELinux, execshield,...) and Xen 3.0.2. So either 2.6.9-34.EL is broken for DRBD v8 or it is something with the backing storage driver, as you suggest. I have reproduced the problems on two servers for now: - An Intel SR1325 (TK btw.) with on-board SATA, which uses libata (SATA disks are represented as /dev/sd[a-d]). - An old Pentium 3 with regular IDE/(P)ATA disks I will try on a HP Proliant DL360 (smart array 5i controller with the cciss driver) tomorrow. > I guess it is something ether with Xen's block device driver/emulation. > Are I am right, that you tested it in VMware ? - Then the chances are > high that it is something with VMware's block device driver/emulation. It was Werner, who tested on VMware. I used Xen, but only inside the "backend" domain, i.e. the base system that has direct access to the hardware (although most access goes through the Xen hypervisor, all devices drivers are unmodified at least from a source code perspective; Xen still performs memory address mapping, additional IRQ routing, etc.). I will also test in a *virtual* machine, tomorrow. > I do not say that the bug is in their code, I just say the issue is > related to the interaction of Xen's/VMware's driver and DRBD. > > I guess I either need to setup such an environment here, or someone > gives me access to an environment where DRBD-8.0 failes with the > posted OOPS. > > Currently I have not 100% of my time for DRBD-8.0 OSS development, I have > to work on my paying customers' requests as well... ...but access > to an "OOPSing" environment would help for sure. I think that can be arranged. I am going to try with other hardware and with a 2.6.9-22.EL kernel before that, but if that does not give any results, I will prepare a test server for you. An additional question: all my oopses are with metadata internal, because with external md, I do not even get as far as the oops (as reported before). Are you using internal or external md? Best Regards, Michael Paesold