2002-09-27 21:17:58

by James Bottomley

[permalink] [raw]
Subject: Re: Warning - running *really* short on DMA buffers while doingfiletransfers

[email protected] said:
> Duh. There had been race conditions in the past which caused all of us
> HBA writers to in fact start swalloing things like QFULL and
> maintaining internal queues.

That was true of 2.2, 2.3 (and I think early 2.4) but it isn't true of late
2.4 and 2.5

James



2002-09-27 21:27:15

by Matthew Jacob

[permalink] [raw]
Subject: Re: Warning - running *really* short on DMA buffers while doingfiletransfers


> [email protected] said:
> > Duh. There had been race conditions in the past which caused all of us
> > HBA writers to in fact start swalloing things like QFULL and
> > maintaining internal queues.
>
> That was true of 2.2, 2.3 (and I think early 2.4) but it isn't true of late
> 2.4 and 2.5

Probably. But I'll like leave the 2.4 driver alone. I'm about to fork my
bk repository into 2.2, 2.4 and 2.5 streams and put the 2.4 version into
maintenance mode.

It turns out that there are other reasons why I maintain an internal
queue that have to do more with hiding fibre channel issues. For
example, if I get a LIP or an RSCN, I have to go out and re-evaluate the
loop/fabric and make sure I've tracked any changes in the identity of
the devices. The cleanest way to handle this right now for linux is to
accept comamnds, disable the scsi timer on them, and restart them once I
get things sorted out again. Maybe this will change for 2.5.

2002-09-27 21:24:45

by Justin T. Gibbs

[permalink] [raw]
Subject: Re: Warning - running *really* short on DMA buffers while doingfiletransfers

> That was true of 2.2, 2.3 (and I think early 2.4) but it isn't true of
> late 2.4 and 2.5

I have see 0 changes in 2.4 that indicate that it is safe to have the
mid-layer do queuing.

--
Justin

2002-09-27 22:02:16

by Mike Anderson

[permalink] [raw]
Subject: Re: Warning - running *really* short on DMA buffers while doingfiletransfers


James Bottomley [[email protected]] wrote:
> [email protected] said:
> > Duh. There had been race conditions in the past which caused all of us
> > HBA writers to in fact start swalloing things like QFULL and
> > maintaining internal queues.
>
> That was true of 2.2, 2.3 (and I think early 2.4) but it isn't true of late
> 2.4 and 2.5
>

The current model appears to not be ideal. We go through the process of
starting a cmd only to find out the adapter really knew we could not
start this command. We then put this request back on the head of the
queue while it is holding resources (a request that possibly could have
more merging and mem from the scsi_sg_pools).

I thought there was discussion previously on mid-layer queue
adjustments during the (? attach patch ?) but I am having trouble
finding it.

-andmike
--
Michael Anderson
[email protected]

2002-09-30 23:44:17

by Doug Ledford

[permalink] [raw]
Subject: Re: Warning - running *really* short on DMA buffers while doingfiletransfers

On Fri, Sep 27, 2002 at 05:23:10PM -0400, James Bottomley wrote:
> [email protected] said:
> > Duh. There had been race conditions in the past which caused all of us
> > HBA writers to in fact start swalloing things like QFULL and
> > maintaining internal queues.
>
> That was true of 2.2, 2.3 (and I think early 2.4) but it isn't true of late
> 2.4 and 2.5

Oh, it's true of current 2.4 (as of 2.4.19). It's broken for new and old
eh drivers both in 2.4. Hell, it's still broken for new eh drivers in 2.5
as well.

--
Doug Ledford <[email protected]> 919-754-3700 x44233
Red Hat, Inc.
1801 Varsity Dr.
Raleigh, NC 27606