Dear Christoph Hellwig,
I have figure out your comments about "remove internal queueing" and "remove
odd ioctl".
But about "hardware datastructures", areca's firmware spec is need to get a
trunk of contingous memory space under 4G.
In 64bit platform arcmsr need to make sure all ccbs have same of
ccb_phyaddr_hi32 physical address.
If arcmsr use dma_pool_alloc do a separate dma mapping.
Is there any method to avoid ccbs pool cross 4G segment?
- msi should be a module options if at all, but defintitly not
a config options
In some mainboard if I always enable msi function, it will cause system hang
up.
If it is not a config option, do you have any idea to avoid this issue?
Best Regards
Erich Chen
----- Original Message -----
From: "Christoph Hellwig" <hch@xxxxxxxxxxxxx>
To: "erich" <erich@xxxxxxxxxxxx>
Cc: <linux-scsi@xxxxxxxxxxxxxxx>; <linux-kernel@xxxxxxxxxxxxxxx>;
<billion.wu@xxxxxxxxxxxx>; <alan@xxxxxxxxxxxxxxxxxxx>; <akpm@xxxxxxxx>;
<arjan@xxxxxxxxxxxxx>; <oliver@xxxxxxxxxx>
Sent: Wednesday, February 22, 2006 10:57 PM
Subject: Re: Areca RAID driver remaining items?
On Wed, Feb 22, 2006 at 02:27:32PM +0800, erich wrote:
Hi Christoph Hellwig,
Thanks for your comment with "arcmsr".
I will follow your comment to redo this driver.
But I am confuse with your mention about some items.
Hope you can tell me more detail and let me realy know your comment.
1- remove internal queueing:
Does the "internal queueing" is mention with arcmsr of ccb_free_list
?
Currently the drivers queuecommand routine works the following:
1) perform some checks
2) try to post outstanding ccbs
3) grab new ccb from freelist and set it up
4) try to post new ccb, else enqueue it
there is not poin in having such a pending queue in the driver because
the midlayer does that work for you. If ->queuecommand can't immediately
post a ccb you should return
SCSI_MLQUEUE_HOST_BUSY if there is a resource shortage at the hba level
SCSI_MLQUEUE_DEVICE_BUSY if there is a resource shortage at the device
level
and the scsi midlayer will try to send the command again once a command
has been completed on the hba/device.
2- fix hardware datastructures:
Does the "fix hardware datastructures" is to fix struct ARCMSR_CDB?
Is it illeagal in linux?
struct CCB is a structure that is passed to the hardware but contains
pointers which have different sized on different architectures. This
is generally very dangerous. If this is just a cookie that the hardware
doesn't interpret at all it needs more documentation. Also the way
you try to convert from bus to virtual addresses with pACB->vir2phy_offset
can't work on many linux platforms because the virtual to bus address
mapping isn't contingous. you need a separate dma mapping for each ccb,
a good way to archive that is the dma_pool_ * API.
3- remove odd ioctls:
How about remove odd ioctl?
generally we don't want to add new ioctls. For scsi/raid drivers there's
been an exception where we allow a pass-through to the firmware which
the managment applications need. the driver has various ioctls that
don't seem to fall into that category.
-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
