Greg Lehey wrote:
> Technical explanation: A buffer header gets corrupted between the
> time the top half of the driver issues the request to the disk
> driver, and when the I/O completes. Currently, the evidence is
> pointing towards the disk driver, but the corruption is of such an
> u
In message <[EMAIL PROTECTED]>, Greg Lehey writes:
>>
>> The problem in vinum/releng4 is the problem greg has been blaming
>> on CAM since at least FreeBSDcon and indications seems to be that
>> it is actually a malloc/free gottcha in vinum.
>
>No, this is not correct. The problem you're talking
On Tuesday, 4 April 2000 at 15:33:43 +0200, Poul-Henning Kamp wrote:
> In message , Brad Knowles writes:
>> At 8:23 AM +0200 2000/4/4, Jeroen Ruigrok/Asmodai wrote:
>>
>>> Like I said in another mail, this is CURRENT, things are
>>> expected to br
On Tuesday, 4 April 2000 at 15:31:00 +0200, Søren Schmidt wrote:
> It seems Brad Knowles wrote:
>>
>> Like I said in a previous message, Poul broke vinum (among other
>> things) under 4.0-STABLE, and this needs to be fixed ASAP. If Poul
>> had kept his changes unique to -CURRENT, then 4.0-S
> Like I said in a previous message, Poul broke vinum (among other
> things) under 4.0-STABLE, and this needs to be fixed ASAP. If Poul
I'd actually consider it a really good idea if you could back this up
since I have not seen anything to suggest that phk's changes have
affected 4.0-STA
On Tue, Apr 04, 2000 at 08:14:40AM +0200, Jeroen Ruigrok/Asmodai wrote:
> Ehm. Not as if your VM stuff wasn't causing disruption. Needed,
> granted, but disruptive as well. And ucd-snmp has been broken quite
> some time (still is?) due to the work.
> And I know of a lot of people who actively
At 3:33 PM +0200 2000/4/4, Poul-Henning Kamp wrote:
> I have not made one single commit to 4.0-STABLE which even comes
> close to vinum.
My apologies. I must have misread/misremembered what was being
said with regards to the commits breaking vinum, and somehow gotten
that crossed wi
In message , Brad Knowles writes:
>At 8:23 AM +0200 2000/4/4, Jeroen Ruigrok/Asmodai wrote:
>
>> Like I said in another mail, this is CURRENT, things are
>> expected to break. You want stability of API's, go 3-STABLE. You want
>> a somewhat stab
It seems Brad Knowles wrote:
>
> Like I said in a previous message, Poul broke vinum (among other
> things) under 4.0-STABLE, and this needs to be fixed ASAP. If Poul
> had kept his changes unique to -CURRENT, then 4.0-STABLE wouldn't
> have been affected. But he didn't, and it was.
W
At 8:23 AM +0200 2000/4/4, Jeroen Ruigrok/Asmodai wrote:
> Like I said in another mail, this is CURRENT, things are
> expected to break. You want stability of API's, go 3-STABLE. You want
> a somewhat stable environment, go 4-STABLE. 5 is bleeding edge, have
> your bandages ready.
At 8:14 AM +0200 2000/4/4, Jeroen Ruigrok/Asmodai wrote:
> Besides, CURRENT does allow for the tree to be broken. I guess Bleeding
> Edge lost its meaning within the FreeBSD ranks.
Yes, but RELENG_4 is no longer -CURRENT. Therefore, different
procedures need to be applied to it, now
-On [2404 04:01], Adrian Chadd ([EMAIL PROTECTED]) wrote:
>This really isn't constructive. I haven't looked at the patchset that
>phk has posted up but I think it'd be more useful if people gave
>comments about the changes and their usefulness rather than the bickering
>going on now.
Agreed.
-On [2404 04:02], Matthew Dillon ([EMAIL PROTECTED]) wrote:
>:
>:* His timing did suck
>:* He's now doing the right thing, at least, instead of committing the
>: second patchset without submitting them for peer review
>
>I disagree. What Poul is doing is committing stuff first, then tryi
-On [2403 20:05], Matthew Dillon ([EMAIL PROTECTED]) wrote:
>
>:When I mailed arch@ about this change I got no response from anybody
>:but Bruce.
>:
>:I talked to Kirk about it in Malmø and got his approval.
>:
>:This is not unplanned.
>:
>:This is also not untested, I have two complete protot
:
:* His timing did suck
:* He's now doing the right thing, at least, instead of committing the
: second patchset without submitting them for peer review
I disagree. What Poul is doing is committing stuff first, then trying
to get validation after the fact (and in a rather demanding way
On Mon, Apr 03, 2000, Matthew Dillon wrote:
>
> :
> :
> :Matt,
> :
> :When I mailed arch@ about this change I got no response from anybody
> :but Bruce.
> :
> :I talked to Kirk about it in Malmø and got his approval.
> :
> :This is not unplanned.
> :
> :This is also not untested, I have two compl
:
:
:Matt,
:
:When I mailed arch@ about this change I got no response from anybody
:but Bruce.
:
:I talked to Kirk about it in Malmø and got his approval.
:
:This is not unplanned.
:
:This is also not untested, I have two complete prototypes behind me.
:
:It is regretable that vinum was broken, a
Matt,
When I mailed arch@ about this change I got no response from anybody
but Bruce.
I talked to Kirk about it in Malmø and got his approval.
This is not unplanned.
This is also not untested, I have two complete prototypes behind me.
It is regretable that vinum was broken, and I hope that i
:>Ripping up the buffer cache right smack in the middle of Greg trying
:>to debug a serious vinum/bio problem is atrocious timing.
:
:Actually, it is the other way around, Greg finally started to look for
:the bug in vinum in the middle of my commits.
:
:How dare he do that ?
:
::-)
:
:--
In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
>
>: http://phk.freebsd.dk/misc
>:
>:I belive the patch is now fundamentally ready for commit, I'm running
>:it here myself, and the delta in kernel warnings have been analyzed
>:and deemed mostly harmless.
>:
>:Some componenents are stil
: http://phk.freebsd.dk/misc
:
:I belive the patch is now fundamentally ready for commit, I'm running
:it here myself, and the delta in kernel warnings have been analyzed
:and deemed mostly harmless.
:
:Some componenents are still not converted and use a cast from bio to
:buf, prominently v
http://phk.freebsd.dk/misc
I belive the patch is now fundamentally ready for commit, I'm running
it here myself, and the delta in kernel warnings have been analyzed
and deemed mostly harmless.
Some componenents are still not converted and use a cast from bio to
buf, prominently vinum an
22 matches
Mail list logo