Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Am Donnerstag, 13. April 2006 19:00 schrieb Michael Paesold: > Philipp Reisner wrote: > > Am Freitag, 7. April 2006 17:50 schrieb Michael Paesold: > > > Using internal meta-data results in a kernel oops. Using both the > > > regular > > > 2.6.9 as well as the Xen 2.6.16 kernel. I have captured the oops over a > > > serial line, so if you are interested, I can send it to you. > > > > Please post the OOPS! > > Already done in the other thread. > > I have another plea - since you are yourself successfully using v8, could > you please post some information on configurations where it's working? > Distribution; kernel version, release, type (smp, up), overall > configuration (like what kind of meta-data; or any settings that one would > normally not modify, but you have set to non-default values) > > That would help me and perhaps others to create a working installation and > track down what components actually break drbd v8. > > I am very eager to have a working drbd v8, so I am more than willing to > help testing. Although kernel hacking is rather new to me, I have started > to read some stuff to get at least a bit of understanding :-) (e.g. > Documentation/block/* -- anything else to recommend?) > 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 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. 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. Best regards, Philipp -- : Dipl-Ing Philipp Reisner Tel +43-1-8178292-50 : : LINBIT Information Technologies GmbH Fax +43-1-8178292-82 : : Schönbrunnerstr 244, 1120 Vienna, Austria http://www.linbit.com :