Date: Tue, 2 Jan 2001 09:28:20 +1030 From: Greg Lehey <grog@lemis.com> To: Roman Shterenzon <roman@harmonic.co.il> Cc: freebsd-stable@FreeBSD.ORG Subject: Re: vinum malfunction! Message-ID: <20010102092819.K44043@wantadilla.lemis.com> In-Reply-To: <Pine.LNX.4.10.10101011231530.21348-100000@shark.harmonic.co.il>; from roman@harmonic.co.il on Mon, Jan 01, 2001 at 12:32:22PM %2B0200 References: <20001231101426.K99806@wantadilla.lemis.com> <Pine.LNX.4.10.10101011231530.21348-100000@shark.harmonic.co.il>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, 1 January 2001 at 12:32:22 +0200, Roman Shterenzon wrote: > On Sun, 31 Dec 2000, Greg Lehey wrote: > >> [Format recovered--see http://www.lemis.com/email/email-format.html] >> >> Please limit your lines to < 80 characters. >> >> On Saturday, 30 December 2000 at 19:00:27 +0100, O. Hartmann wrote: >>> Dear Sirs. >>> Today I run a make world and compiled a new kernel for our server, >>> which uses a vinum RAID 0. At the same time I reconfigured the >>> kernel to use SC console driver and VESA instead of VT console. >>> >>> Since the new kernel got compiled loading of vinum fails! I do not >>> know why, I removed all kernel changes, but it does not help. >>> >>> Does anyone know why? >> >> Of course not. You haven't given *any* details. >> >> Take a look at http://www.vinumvm.org/vinum/how-to-debug.html and give >> some information, and I'll probably be able to help. > > I've submitted kern/22021 which was left untouched, it has all the needed > details. Please don't jump to conclusions. O. Hartmann has, as I mentioned, given *no* information. If you can find the cause of the problem from what he has done, please go ahead and do so. All I can see here is that he is talking about RAID-0, while the problem you failed to describe in 22021 occurs only with RAID-5. kern/22021 was closed one day after it was issued. To quote: Greg Lehey, 17 October 2000 I'm sorry, this PR is so completely mutilated that I can't read it. It appears to have been sent with quoted-printable, but without declaring the fact. As a result, the information is almost completely illegible. It's not so completely mutilated, however, that I don't note that it includes dmesg and kernel config information, information that I specifically ask *not* to include in problem reports. I'm closing this PR because it'll be easier to resubmit it than to fix it. Please read http://www.vinumvm.org/vinum/how-to-debug.html and http://www.lemis.com/email.html before doing so. Since you mention this PR, I suppose I should amplify on this comment. First, it is by *far* the most illegible PR I have ever seen. For example: #39 0xc0236a0d in trap_pfault (frame=3D0xc0276a70, usermode=3D0, eva=3D84) at ../../i386/i386/trap.c:820 #40 0xc023660b in trap (frame=3D{tf_fs =3D -1071185904, tf_es =3D -10723655= 52,=20 tf_ds =3D 7077904, tf_edi =3D -1049722848, tf_esi =3D -1049722880,=20 tf_ebp =3D -1071158580, tf_isp =3D -1071158628, tf_ebx =3D -103960512= 0,=20 tf_edx =3D 0, tf_ecx =3D 90505217, tf_eax =3D -7113793, tf_trapno =3D= 12,=20 tf_err =3D 2, tf_eip =3D -1051657113, tf_cs =3D 8, tf_eflags =3D 6611= 8,=20 tf_esp =3D -1049722848, tf_ss =3D -1051996160}) at ../../i386/i386/tr= ap.c:426 #41 0xc150fc67 in ?? () #42 0xc0178d6b in biodone (bp=3D0xc16e8020) at ../../kern/vfs_bio.c:2637 #43 0xc0126bb9 in dadone (periph=3D0xc14ca700, done_ccb=3D0xc1658c00) at ../../cam/scsi/scsi_da.c:1246 Apart from the fact that it's barely legible, this also shows: 1. You did a backtrace without loading Vinum symbols. 2. It's related to a known, but rare, RAID-5 problem which I am trying to get information on. You don't mention that you resubmitted this PR as 22103. Despite my requests, 1. You insisted on including the config file and dmesg, which just bloat the PR and make it more difficult to read. 2. The backtrace still does not include Vinum symbols, making it pretty useless. 3. It includes (without comment) a mail exchange with Andy Newman, which have been twice mutilated, once before I received the message, once after. After fighting my way through this PR, I don't have any additional information. Dealing with this kind of PR is an absolute pain. It's bloated, illegible, full of irrelevant information and lacking the information I need. It is, however, one of the few cases I've seen of a particular buffer header corruption which occurs only in RAID-5, and I would like to fix it. If you want to help, instead of sending "me too" messages about what is obviously a completely different problem, help me find the problem you're having. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010102092819.K44043>