Re: please DON'T run 2.5.27 with IDE!

[Marcin Dalecki <dalecki@evision.ag>]

Bartlomiej Zolnierkiewicz wrote:
>  Tue, 23 Jul 2002, Marcin Dalecki wrote:
> 
> 
>>Bartlomiej Zolnierkiewicz wrote:
>>
>>
>>>Martin why aren't you telling people all facts?
>>>It was the default behaviour before your change in IDE 99.
>>>This patch in practice reverts IDE 99 change.
>>>
>>>You have INTRODUCED a bug and now you try to
>>>pretend that it wasn't your fault and it was somehow broken before.
>>
>>Never said that. Sure it was my fault I looked in the wrong direction
>>I looked at the ide-tcq code, becouse I still dont like the
>>idea that we pass a pointer for a struct on the local stack down.
>>(It's preventing the futile hope to make this thingee somehow
>>asynchronous form ever taking place.)
>>
>>I should have looked at SCSI in first place instead indeed.
>>
>>
>>>Before 2.5.27 code had the same functionality as scsi version.
>>
>>That's actually not true... At least the setting of the
>>request rq->flags is significantly different here and there.
> 
> 
> You are right here...
> Actually IDE request should have REQ_BARRIER bit also set for safety
> and coherency.
> Without barrier requests added after special command can be merged
> with requests added before special command.
> 
> 
>>However I think but I'm not sure that the fact aht we have rq->special
>>!= NULL here has the hidded side effect that we indeed accomplish the
>>same semantics.
> 
> 
> No.

There are some nasty checks for it != NULL in the generic BIO code.
And REQ_BARRIER got introduced just recently, so we can see the
error will have been propagated.

>>>And yes it will be useful to move it to block layer.
>>
>>Done. Just needs testing. I have at least an ZIP parport drive, which
>>allows me to do some basic checks.
> 
> 
> Test everything on your production machine + main hdd.
> Will make you care more about code correctness ;-).

Nah... that's just for the SCSI code "move around". The rest
I usually run continuously on two systems.

>>BTW.> Having a fill up request queue trashing data transfers
>>is indicating that there may be are bugs in the generic block layer too.
>>If it gets pushed to boundary conditions it's apparently not very
> 
> 
> No it wasn't "pushed to boundary conditions", you screwed it, sorry.
> 
> 
>>robust... BTW.> I never ever will understand why
>>request_fn returns void instead of an status value.
> 
> 
> So look at ide.c for example.

So look at drivers which call blk_start_queue() from within 
q->request_fn context, which is, well, causing deliberate *recursion*.