lkml.org 
[lkml]   [2006]   [Feb]   [23]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
    /
    From"erich" <>
    SubjectRe: Areca RAID driver remaining items?
    DateThu, 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/
    
    
    \
     
     \ /
      Last update: 2006-02-23 06:30    [from the cache]
    ©2003-2008