headers
Mark Lobo | 1 Nov 2002 01:16
Picon
Favicon

Bounce buffer usage

Guys,
Simple question on bounce buffer usage.
As of my understanding right now, a bounce buffer will
not be used if 
1) We say we dont support over a fixed number of
address bits, for example, ISA devices.
2) If the address of the buffer is not in a space
directly addressable by the kernel ( not in kernel
logical address space )

Now my question is: what happens in the case where an
application sends an IO down? are bounce buffers used
in that case? I guess I am still confused on kernel
virtual v/s kernel logical addresses. As I understand,
a kernel logical address is one that is directly
addressable by the kernel, and is limited to 1GB. So
if we have a system with 2GB, does it mean some of the
physical memory ( probably 1GB )  has a kernel logical
address assigned to it permanently and the other 1GB
does not, which means if a user happens to get a page
in that space, there will be no logical address ( and
therefore bounce buffers WILL be used? ).
Or is any user address not mapped in the kernel
"logical" space at all? 

Im confused in this one, I would appreciate if someone
can clear it up for me.

Thanks,
Mark
(Continue reading)

Permalink | Reply | 7 comments |
headers
Patrick Mansfield | 1 Nov 2002 02:41
Picon
Favicon

Re: [PATCH] Ghost devices being reported with AIC7XXX version 6.2.6

On Thu, Oct 31, 2002 at 07:21:12PM +0000, Alan Cox wrote:
> On Thu, 2002-10-31 at 18:28, Matthew Jacob wrote:
> > > 3) Linux should be using the Report Luns command to determine how
> > >    many luns are on a device and at what locations.  This might
> > >    even allow you to never probe more than 8 luns on a SCSI 2
> > >    device unless they support this command.  Does the Symetrix support
> > >    it?  Going beyond 8 luns on a SCSI2 device is really a hack
> > >    otherwise.
> > 
> > Absolutely.
> 
> Now is the right time to fix this properly for 2.5

REPORT LUNS is a SCSI-3 command, not SCSI-2, so it can't solve
the problem. Right?

You should be able to configure any recent EMC box (and AFAIK any
recent disk array hardware, at least IBM Shark, IBM fastt) to report
back as a SCSI-3 device.

-- Patrick Mansfield
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Douglas Gilbert | 1 Nov 2002 03:07

Re: [PATCH] Re: ieee1394/sbp2.c doesn't compile in 2.5.45

Miles Lane wrote:
> 
> Douglas wrote:
> 
>> Adrian,
>> Could you try this patch that I sent to the scsi
>> list against 2.5.44-bk3.
> 
> 
> Yes, this patch fixed the 2.5.45 compile for me.
> 
>     Miles
> 
>> --- linux/drivers/ieee1394/sbp2.h    2002-10-26 03:11:32.000000000 +1000
>> +++ linux/drivers/ieee1394/sbp2.h2544bk3fix    2002-10-31 
>> 11:27:25.000000000 +1100
>>  <at>  <at>  -552,7 +552,8  <at>  <at> 
>>  #if LINUX_VERSION_CODE < KERNEL_VERSION(2,5,28)
>>  static int sbp2scsi_biosparam (Scsi_Disk *disk, kdev_t dev, int geom[]);
>>  #else
>> -static int sbp2scsi_biosparam (Scsi_Disk *disk, struct block_device 
>> *dev, int geom[]);
>> +static int sbp2scsi_biosparam (struct scsi_device *sdev, +            
>> struct block_device *dev, sector_t capacy, int geom[]);
>>  #endif
>>  static int sbp2scsi_abort (Scsi_Cmnd *SCpnt);  static int 
>> sbp2scsi_reset (Scsi_Cmnd *SCpnt); --- 
>> linux/drivers/ieee1394/sbp2.c    2002-10-31 09:22:50.000000000 +1100
>> +++ linux/drivers/ieee1394/sbp2.c2544bk3fix    2002-10-31 
>> 11:30:20.000000000 +1100
(Continue reading)

Permalink | Reply | 0 comments |
headers
Douglas Gilbert | 1 Nov 2002 03:43

Re: [patches] rq_dev removal

Willem Riede wrote:
> On 2002.10.31 17:43 Alexander Viro wrote:
> 
>>	Folks, ->rq_dev is going away in 2.5 RSN.  The only non-trivial
>>remaining uses were in SCSI (scsi_lib.c::scsi_get_request_dev() and
>>uses in st.c, osst.c and sg.c to identify a device).
>>
>>	Series of patches on ftp.math.psu.edu/pub/viro/P/P*-C45 deals
>>with that stuff and removes most of the uses of minor() in there.  Please,
>>review it.
> 
> 
> I reviewed the changes to osst (which I maintain).
> 
> [snip]
> 
>>	* sd.c and sr.c got a pointer to Scsi_Device_Template in
>>scsi_disk and scsi_cd resp.  That pointer is initialized to &s{d,r}_template.
>>disk->private_data points to that field (instead of entire scsi_disk/scsi_cd)
>>and old uses of disk->private_data are updated to compensate.
>>	* st.c, osst.c and sg.c got gendisks allocated, but not registered.
> 
> 
> How appropriate is it, to have something called '*disk' in a tape driver?
> I assume that at least the data in it is valid for this type of driver?

It seems as though sg's (scsi) _device_ abstraction has
been replaced by a _disk_ abstraction. At the very least
this is misleading for the dvd/cd writers, scanners,
tape robots and enclosures that sg typically deals with.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexander Viro | 1 Nov 2002 03:55
Picon
Favicon

Re: [PATCH] don't increment use count twice on open


On Fri, 1 Nov 2002, Christoph Hellwig wrote:

> Since 2.4 drivers get their usecount managed by higher levels if they
> supply a owner field in block_device_operations/file_operations.
> 
> Remove managment of the additional usecount in ->open/->close.
> 
> 
> --- 1.17/drivers/scsi/osst.c	Thu Oct 17 13:52:39 2002
> +++ edited/drivers/scsi/osst.c	Thu Oct 31 00:50:21 2002
>  <at>  <at>  -4178,8 +4178,6  <at>  <at> 
>  
>  	if (STp->device->host->hostt->module)
>  		 __MOD_INC_USE_COUNT(STp->device->host->hostt->module);

BTW, that (and similar in other drivers) is a walking rmmod race.
Think what happens if module is already in the middle of unload -
it's done with checking the refcount, decision is already made.
try_inc_mod_count() is needed here...

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Christoph Hellwig | 1 Nov 2002 03:52
Picon

[PATCH] don't increment use count twice on open

Since 2.4 drivers get their usecount managed by higher levels if they
supply a owner field in block_device_operations/file_operations.

Remove managment of the additional usecount in ->open/->close.

--- 1.17/drivers/scsi/osst.c	Thu Oct 17 13:52:39 2002
+++ edited/drivers/scsi/osst.c	Thu Oct 31 00:50:21 2002
 <at>  <at>  -4178,8 +4178,6  <at>  <at> 

 	if (STp->device->host->hostt->module)
 		 __MOD_INC_USE_COUNT(STp->device->host->hostt->module);
-	if (osst_template.module)
-		 __MOD_INC_USE_COUNT(osst_template.module);
 	STp->device->access_count++;

 	if (mode != STp->current_mode) {
 <at>  <at>  -4522,8 +4520,6  <at>  <at> 

 	if (STp->device->host->hostt->module)
 	    __MOD_DEC_USE_COUNT(STp->device->host->hostt->module);
-	if (osst_template.module)
-	    __MOD_DEC_USE_COUNT(osst_template.module);

 	return retval;
 }
 <at>  <at>  -4667,8 +4663,6  <at>  <at> 

 	if (STp->device->host->hostt->module)
 		__MOD_DEC_USE_COUNT(STp->device->host->hostt->module);
-	if(osst_template.module)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jens Axboe | 1 Nov 2002 08:48
Picon

Re: Bounce buffer usage

On Thu, Oct 31 2002, Mark Lobo wrote:
> Guys,
> Simple question on bounce buffer usage.
> As of my understanding right now, a bounce buffer will
> not be used if 
> 1) We say we dont support over a fixed number of
> address bits, for example, ISA devices.

Correct, if unchecked_isa_dma is set for instance.

> 2) If the address of the buffer is not in a space
> directly addressable by the kernel ( not in kernel
> logical address space )

Not so true anymore in 2.4.20-pre (and hasn't been true in 2.5 since
2.5.1). If you set host highmem_io flag, it will be happy to pass you
pages that have no kernel virtual mapping.

> Now my question is: what happens in the case where an
> application sends an IO down? are bounce buffers used
> in that case? I guess I am still confused on kernel

You just outlined the bounce scenarious above yourself :-). If the
buffer sent down resides at a higher address than what the adapter can
handle, then it is bounced. This may not necessarily have anything to do
with kernel virtual mapping or not.

> virtual v/s kernel logical addresses. As I understand,
> a kernel logical address is one that is directly
> addressable by the kernel, and is limited to 1GB. So
(Continue reading)

Permalink | Reply | 6 comments |
headers
JP Howard | 1 Nov 2002 09:17

ServeRaid 5i drivers/performance

I am looking at purchasing a number of servers using ServeRaid 5i cards.
I have found new Red Hat drivers on IBM's site, but I can't see whether
they're source or binary only. I've only found a GPL driver page at
DeveloperWorks for v4.8 (that doesn't support the 5i) but not for 5.11
(which does support the 5i). Does anyone know if source for the 5.11
driver exists somewhere? The 2.4.20pre11 source changelog shows that it
is v5.01, although the Configure help doesn't mention the 5i at all
(although this may just be an oversight in keeping the docs up to
date...)

Also, does anyone have experience of comparative performance between the
ServeRaid 5i, 4mx, and 4h?

I am also potentially buying some Dells, which use own-branded Megaraid
cards--Dell calls it the "Perc 3dc". We currently have a Megaraid card
that we're disappointed with because it doesn't return instantly from
fsync(), even although we have a battery backed writeback cache. I
understand that this may be because the controller is not able to handle
ordering commands correctly.

Does anyone have experience with this with the ServeRaid cards? Do any of
them provide immediate return from fsync()?

If no-one knows the answer to this, does anyone on this list have a
ServeRaid card? If so, we've got a little C program that tests the
overhead of fsync() to answer this question--perhaps some generous soul
could try running this on their machine?

TIA,
  Jeremy
(Continue reading)

Permalink | Reply | 0 comments |
headers
j-nomura | 1 Nov 2002 12:50
Picon

QLA12160 ring buffer starvation? on 2.4.x

Hello,

I'm using qla1280 driver 3.23 Beta with 2.4.19 kernel and have a trouble
with it.

When I access multiple disks connected to a single SCSI card,
some of disks suffer QLA12160 ring buffer starvation.
It eventually cause SCSI timeout in middle layer (and panics).

As the timed out command have stayed in qla1280 per-LUN queue more than
30 seconds while commands in other queues haven't, I suspect that current
qla1280 driver has a structual problem which brings unfairness of command
issuing. (as followings)

Do you have any idea?

I can workaround it by limitting ha->bus_settings[].hiwat to 16. 

The command issuing process of qla1280 is:

1. scsi_dispatch_cmd puts commands into queue by qla1280_queuecommand().
2. Queued commands are issued to QLA12160 ring buffer by qla1280_next()
   until ring becomes full or outstanding command for the queue reaches
   maximum.
   The maximum number of outstanding commands per queue is determined
   by ha->bus_settings[].hiwat.
3. When ring buffer does not have enough room, commands are put again
   to the tail of queue by qla1280_putq_t().

qla1280_next is executed either when the first command is queued by
(Continue reading)

Permalink | Reply | 3 comments |
headers
Alan Cox | 1 Nov 2002 14:00
Picon

Re: [PATCH] Ghost devices being reported with AIC7XXX version 6.2.6

On Thu, 2002-10-31 at 20:17, Doug Ledford wrote:
> On Thu, Oct 31, 2002 at 12:04:16PM -0800, Matthew Jacob wrote:
> > 
> > *blush*
> > 
> > I was actually going to start finally working 2.5 next week (don't hit
> > me! don't hit me)
> 
> Hehehe!  Going to start after the feature freeze is already over, makes it 
> kind of hard to get anything new in doesn't it ;-)

Its not a major new feature its just some more scsi bug fixing

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |

Gmane