Messages in this thread | | | From | "erich" <> | Subject | Re: Areca RAID driver remaining items? | Date | Thu, 23 Feb 2006 14:27:26 +0800 |
| |
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@infradead.org> To: "erich" <erich@areca.com.tw> Cc: <linux-scsi@vger.kernel.org>; <linux-kernel@vger.kernel.org>; <billion.wu@areca.com.tw>; <alan@lxorguk.ukuu.org.uk>; <akpm@osdl.org>; <arjan@infradead.org>; <oliver@neukum.org> 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.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |