Areca RAID driver remaining items?

Areca RAID driver remaining items?

[Dax Kelson]

This appears to be the most current version of the driver:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16-rc4/2.6.16-rc4-mm1/broken-out/areca-raid-linux-scsi-driver.patch

Is this the current TODO list?

=================
Issues not yet patched:

13. uintNN_t int types:  use kernel types except for userspace
interfaces
14. use kernel-doc
18. Put arcmsr.txt in Documentation/scsi/, not in scsi/arcmsr/.
19. Maybe use sysfs (/sys) instead of /proc.
20. check stack usage, init/exit sections;
=================
   
At one point this comment was made:

"There's lots of architectural problems.  It's doing it's own queueing,
it's stuffing kernel structures into memory on the hardware and so on.
Basically someone knowledgeable about the hardware needs to start from
scratch on it."

What are the show stoppers that prevents a merge into the Linus tree?

Dax Kelson

Re: Areca RAID driver remaining items?

[Arjan van de Ven]

> "There's lots of architectural problems.  It's doing it's own queueing,
> it's stuffing kernel structures into memory on the hardware and so on.
> Basically someone knowledgeable about the hardware needs to start from
> scratch on it."
> 
> What are the show stoppers that prevents a merge into the Linus tree?

own queueing for sure is a show stopper; 
stuffing kernel structures into the hw is also very much evil

Re: Areca RAID driver remaining items?

[Christoph Hellwig]

On Mon, Feb 20, 2006 at 11:02:32AM -0700, Dax Kelson wrote:
> This appears to be the most current version of the driver:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16-rc4/2.6.16-rc4-mm1/broken-out/areca-raid-linux-scsi-driver.patch
> 
> Is this the current TODO list?
> 
> =================
> Issues not yet patched:
> 
> 13. uintNN_t int types:  use kernel types except for userspace
> interfaces
> 14. use kernel-doc
> 18. Put arcmsr.txt in Documentation/scsi/, not in scsi/arcmsr/.
> 19. Maybe use sysfs (/sys) instead of /proc.
> 20. check stack usage, init/exit sections;


 - remove internal queueing
 - fix hardware datastructures
 - remove odd ioctls
 - remove useless forward prototypes
 - give types like ACB useful names
 - give variable useful names, especially follow kernel conventions,
   e.g. a struct pci_dev is usually named pdev
 - kill ->proc_info method
 - use normal comment style even for comments not fitting into the
   kernel-doc item above.  kill useless separator comments without
   text
 - convert arcmsr_show_firmware_info to useful one value per
   file attributes.  best follow the schemes used in aacraid or
   lpfc
 - convert arcmsr_show_driver_state to useful one value per
   file attributes.
 - remove never called release method in the host template
 - audit whether setting unchecked_isa_dma to false really makes
   sense (I strongly doubt it)
 - remove shutdown notifier, add pci_driver ->shutdown method instead
 - remove CameCase PCI Ids.  The vendor Id should go into pci_ids.h,
   the device ids either removed or spelled the normal linux way
 - arcmsr_do_interrupt should stop walking the global host list
   and use the private data passed to request_irq
 - the global host list should go away completely
 - arcmsr_bios_param looks like duplicating the generic CAM version?
 - locking needs to be redone.  If the driver really needs more than
   one per-host lock we'll want a very good explanation
 - arcmsr_device_probe needs to be rewritten to do goto-based
   error unwinding.
 - msi should be a module options if at all, but defintitly not
   a config options
 - arcmsr_scsi_host_template_init should go away.  the host template
   must be initialized statically with no run-time writes to it
 - the hardware documentation should be split out of arcmsr.h
   into a separate file (btw, thanks a lot to areca to provide such
   detailed hardware informations, it's just the wrong format..)
 - remove the SCSISTAT_* defines, and use the generic ones from
   <scsi/scsi.h> instead.  Dito for various other SAM defines.
 - the driver has just two files and should go directly into
   drivers/scsi instead of a subdirectory

Re: Areca RAID driver remaining items?

[erich]

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 ?

  2- fix hardware datastructures:

      Does the "fix hardware datastructures" is to fix struct ARCMSR_CDB?
      Is it illeagal in linux?

  3- remove odd ioctls:

      How about remove odd ioctl?

Best Regards
Erich Chen

----- Original Message ----- 
From: "Christoph Hellwig" <hch@infradead.org>
To: "Dax Kelson" <dax@gurulabs.com>
Cc: <linux-scsi@vger.kernel.org>; <linux-kernel@vger.kernel.org>; 
<billion.wu@areca.com.tw>; <alan@lxorguk.ukuu.org.uk>; <akpm@osdl.org>; 
<erich@areca.com.tw>; <arjan@infradead.org>; <oliver@neukum.org>
Sent: Tuesday, February 21, 2006 2:20 AM
Subject: Re: Areca RAID driver remaining items?


> On Mon, Feb 20, 2006 at 11:02:32AM -0700, Dax Kelson wrote:
>> This appears to be the most current version of the driver:
>>
>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16-rc4/2.6.16-rc4-mm1/broken-out/areca-raid-linux-scsi-driver.patch
>>
>> Is this the current TODO list?
>>
>> =================
>> Issues not yet patched:
>>
>> 13. uintNN_t int types:  use kernel types except for userspace
>> interfaces
>> 14. use kernel-doc
>> 18. Put arcmsr.txt in Documentation/scsi/, not in scsi/arcmsr/.
>> 19. Maybe use sysfs (/sys) instead of /proc.
>> 20. check stack usage, init/exit sections;
>
>
> - remove internal queueing
> - fix hardware datastructures
> - remove odd ioctls
> - remove useless forward prototypes
> - give types like ACB useful names
> - give variable useful names, especially follow kernel conventions,
>   e.g. a struct pci_dev is usually named pdev
> - kill ->proc_info method
> - use normal comment style even for comments not fitting into the
>   kernel-doc item above.  kill useless separator comments without
>   text
> - convert arcmsr_show_firmware_info to useful one value per
>   file attributes.  best follow the schemes used in aacraid or
>   lpfc
> - convert arcmsr_show_driver_state to useful one value per
>   file attributes.
> - remove never called release method in the host template
> - audit whether setting unchecked_isa_dma to false really makes
>   sense (I strongly doubt it)
> - remove shutdown notifier, add pci_driver ->shutdown method instead
> - remove CameCase PCI Ids.  The vendor Id should go into pci_ids.h,
>   the device ids either removed or spelled the normal linux way
> - arcmsr_do_interrupt should stop walking the global host list
>   and use the private data passed to request_irq
> - the global host list should go away completely
> - arcmsr_bios_param looks like duplicating the generic CAM version?
> - locking needs to be redone.  If the driver really needs more than
>   one per-host lock we'll want a very good explanation
> - arcmsr_device_probe needs to be rewritten to do goto-based
>   error unwinding.
> - msi should be a module options if at all, but defintitly not
>   a config options
> - arcmsr_scsi_host_template_init should go away.  the host template
>   must be initialized statically with no run-time writes to it
> - the hardware documentation should be split out of arcmsr.h
>   into a separate file (btw, thanks a lot to areca to provide such
>   detailed hardware informations, it's just the wrong format..)
> - remove the SCSISTAT_* defines, and use the generic ones from
>   <scsi/scsi.h> instead.  Dito for various other SAM defines.
> - the driver has just two files and should go directly into
>   drivers/scsi instead of a subdirectory 

Re: Areca RAID driver remaining items?

[Christoph Hellwig]

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.

Re: Areca RAID driver remaining items?

[erich]

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. 

Re: Areca RAID driver remaining items?

[Arjan van de Ven]

On Thu, 2006-02-23 at 14:27 +0800, erich wrote:
> 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?

the pci mapping layer prevents that already entirely; there is a LOT of
hardware that cannot deal with segments crossing 4G boundaries, so much
in fact that it's now generically disabled.


> 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?

how about a module option (module_param)?

Re: Areca RAID driver remaining items?

[erich]

Dear Arjan van de Ven,

The following contex is coming from comment of Christoph Hellwig.

- msi should be a module options if at all, but defintitly not
   a config options

#ifdef CONFIG_SCSI_ARCMSR_MSI
 if (!pci_enable_msi(pci_device))
  pACB->acb_flags |= ACB_F_HAVE_MSI;
#endif

I make an option config for prevent some mainboards hang up if arcmsr enable 
msi function.
Areca RAID controller is bridged hardware.
There were a lots of mainboards had wrong IRQ routing table issue with it.
If somebody meet this issue and people can enable msi function to fix its 
hardware bug.
But unfortunately I found some mainboards will hang up if I always enable 
this function in my lab.
To avoid this issue, I do an option for this case.

But  Christoph Hellwig give me comment with it.

Best Regards
Erich Chen

----- Original Message ----- 
From: "Arjan van de Ven" <arjan@infradead.org>
To: "erich" <erich@areca.com.tw>
Cc: "Christoph Hellwig" <hch@infradead.org>; <linux-scsi@vger.kernel.org>; 
<linux-kernel@vger.kernel.org>; <billion.wu@areca.com.tw>; 
<alan@lxorguk.ukuu.org.uk>; <akpm@osdl.org>; <oliver@neukum.org>
Sent: Thursday, February 23, 2006 4:25 PM
Subject: Re: Areca RAID driver remaining items?


> On Thu, 2006-02-23 at 14:27 +0800, erich wrote:
>> 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?
>
> the pci mapping layer prevents that already entirely; there is a LOT of
> hardware that cannot deal with segments crossing 4G boundaries, so much
> in fact that it's now generically disabled.
>
>
>> 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?
>
> how about a module option (module_param)?
>
> 

Re: Areca RAID driver remaining items?

[Arjan van de Ven]

On Thu, 2006-02-23 at 17:50 +0800, erich wrote:
> Dear Arjan van de Ven,
> 
> The following contex is coming from comment of Christoph Hellwig.
> 
> - msi should be a module options if at all, but defintitly not
>    a config options
> 
> #ifdef CONFIG_SCSI_ARCMSR_MSI
>  if (!pci_enable_msi(pci_device))
>   pACB->acb_flags |= ACB_F_HAVE_MSI;
> #endif
> 
> I make an option config for prevent some mainboards hang up if arcmsr enable 
> msi function.
> Areca RAID controller is bridged hardware.
> There were a lots of mainboards had wrong IRQ routing table issue with it.
> If somebody meet this issue and people can enable msi function to fix its 
> hardware bug.
> But unfortunately I found some mainboards will hang up if I always enable 
> this function in my lab.
> To avoid this issue, I do an option for this case.


yes the reason for making this optional is clear, and Christoph also
understands that.

However the idea that Christoph is proposing is to not make it a compile
time option, but a runtime option. Compile-time is not very flexible,
especially not for linux distributions. Making it a module option means
it becomes runtime behavior, and the user can load the module like

modprobe aerca msi=0

and msi gets turned off. No need to recompile anything! That has many
advantages over a more inflexible (from the user view) compiletime-only
option.

Re: Areca RAID driver remaining items?

[erich]

Dear Arjan van de Ven,

Thanks for your answer.
I will remove CONFIG_SCSI_ARCMSR_MSI in next patch.

If Linux can not assurent the contingous memory space allocating of 
"dma_alloc_coherent" .
When arcmsr get a physical ccb address from areca's firmware.
Does linux has any functions for converting of  "bus to virtual" ?

Best Regards
Erich Chen

----- Original Message ----- 
From: "Arjan van de Ven" <arjan@infradead.org>
To: "erich" <erich@areca.com.tw>
Cc: ""Christoph Hellwig"" <hch@infradead.org>; <linux-scsi@vger.kernel.org>; 
<linux-kernel@vger.kernel.org>; <billion.wu@areca.com.tw>; 
<alan@lxorguk.ukuu.org.uk>; <akpm@osdl.org>; <oliver@neukum.org>
Sent: Thursday, February 23, 2006 5:56 PM
Subject: Re: Areca RAID driver remaining items?


> On Thu, 2006-02-23 at 17:50 +0800, erich wrote:
>> Dear Arjan van de Ven,
>>
>> The following contex is coming from comment of Christoph Hellwig.
>>
>> - msi should be a module options if at all, but defintitly not
>>    a config options
>>
>> #ifdef CONFIG_SCSI_ARCMSR_MSI
>>  if (!pci_enable_msi(pci_device))
>>   pACB->acb_flags |= ACB_F_HAVE_MSI;
>> #endif
>>
>> I make an option config for prevent some mainboards hang up if arcmsr 
>> enable
>> msi function.
>> Areca RAID controller is bridged hardware.
>> There were a lots of mainboards had wrong IRQ routing table issue with 
>> it.
>> If somebody meet this issue and people can enable msi function to fix its
>> hardware bug.
>> But unfortunately I found some mainboards will hang up if I always enable
>> this function in my lab.
>> To avoid this issue, I do an option for this case.
>
>
> yes the reason for making this optional is clear, and Christoph also
> understands that.
>
> However the idea that Christoph is proposing is to not make it a compile
> time option, but a runtime option. Compile-time is not very flexible,
> especially not for linux distributions. Making it a module option means
> it becomes runtime behavior, and the user can load the module like
>
> modprobe aerca msi=0
>
> and msi gets turned off. No need to recompile anything! That has many
> advantages over a more inflexible (from the user view) compiletime-only
> option.
>
> 

Re: Areca RAID driver remaining items?

[Arjan van de Ven]

On Thu, 2006-02-23 at 19:51 +0800, erich wrote:
> If Linux can not assurent the contingous memory space allocating of 
> "dma_alloc_coherent" .

coherent memory is guaranteed to be in the "lower" 32 bit of memory!
So that is good news, I think you are just fine.

[Exception is that you can say that you are ok with a bigger mask for
this type of memory, but just don't do that if you're not]


> When arcmsr get a physical ccb address from areca's firmware.
> Does linux has any functions for converting of  "bus to virtual" ?

not without using pools. You would have to search the list of memory you
gave it to find that out.

(USB has a similar problem, afaik they solved it with pools)

Re: Areca RAID driver remaining items?

[erich]

Dear Arjan van de Ven,

I would keep dma_alloc_coherent usage.

> [Exception is that you can say that you are ok with a bigger mask for
> this type of memory, but just don't do that if you're not]

Should I remove "pci_set_dma_mask(pci_device, DMA_64BIT_MASK)" for this 
case?

Best Regards
Erich Chen

----- Original Message ----- 
From: "Arjan van de Ven" <arjan@infradead.org>
To: "erich" <erich@areca.com.tw>
Cc: """Christoph Hellwig""" <hch@infradead.org>; 
<linux-scsi@vger.kernel.org>; <linux-kernel@vger.kernel.org>; 
<billion.wu@areca.com.tw>; <alan@lxorguk.ukuu.org.uk>; <akpm@osdl.org>; 
<oliver@neukum.org>
Sent: Thursday, February 23, 2006 8:07 PM
Subject: Re: Areca RAID driver remaining items?


> On Thu, 2006-02-23 at 19:51 +0800, erich wrote:
>> If Linux can not assurent the contingous memory space allocating of
>> "dma_alloc_coherent" .
>
> coherent memory is guaranteed to be in the "lower" 32 bit of memory!
> So that is good news, I think you are just fine.
>
> [Exception is that you can say that you are ok with a bigger mask for
> this type of memory, but just don't do that if you're not]
>
>
>> When arcmsr get a physical ccb address from areca's firmware.
>> Does linux has any functions for converting of  "bus to virtual" ?
>
> not without using pools. You would have to search the list of memory you
> gave it to find that out.
>
> (USB has a similar problem, afaik they solved it with pools)
>
> 

Re: Areca RAID driver remaining items?

[Arjan van de Ven]

On Fri, 2006-02-24 at 10:08 +0800, erich wrote:
> Dear Arjan van de Ven,
> 
> I would keep dma_alloc_coherent usage.
> 
> > [Exception is that you can say that you are ok with a bigger mask for
> > this type of memory, but just don't do that if you're not]
> 
> Should I remove "pci_set_dma_mask(pci_device, DMA_64BIT_MASK)" for this 
> case?

no what you have is correct; the function to change this behavior is
called 
pci_set_consistent_dma_mask()

pci_set_dma_mask() sets the mask for the "data" (eg dynamic mappings via
pci_map_single and pci_map_page and such). pci_set_consistent_dma_mask()
sets the mask for all the "consistent" allocators.

so again your code is fine as is. If you want to explicitly set that
mask to DMA_32BIT_MASK as documentation that you REALLY want it to be 32
bit, that is probably fine too, but not really needed.

Greetings,
   Arjan van de Ven

Re: Areca RAID driver remaining items?

[Alan Cox]

On Iau, 2006-02-23 at 17:50 +0800, erich wrote:
> But unfortunately I found some mainboards will hang up if I always enable 
> this function in my lab.
> To avoid this issue, I do an option for this case.
> 
> But  Christoph Hellwig give me comment with it.


Another thing you can also do for many of these cases is to use either
the PCI or DMI interfaces to identify the problem board and
automatically set the option as well.

There are two ways to do this. One is 

	struct pci_dev *bridge_dev = pci_get_slot(pdev->bus, PCI_DEVFN(0,0));
	if(bridge_dev) {
		if(bridge_dev->subsystem_vendor == 0xXXXX &&
			bridge_dev->subsystem_device == 0xXXXX)
			/* Match by svid/sdid for problem boards */

The other is like this

#include <linux/dmi.h>

struct dmi_system_id problem_dmi_table[] = {
	{
		.ident = "Broken Board Name 1",
		.matches = {
			DMI_MATCH(DMI_SYS_VENDOR, "EvilCorp");
			DMI_MATCH(DMI_PRODUCTNAME, "Wombat 1000");
		}
	}
	{
		ditto per board
	},
	{ }	/* End of list mark
};


And then

	if (dmi_system_check(problem_dmi_table))
		disable_msi..


The DMI code matches on the DMI strings in the ROM BIOS (the ones dumped
by 'dmidecode')


An example driver using this interface is drivers/char/sonypi.c which
uses it to make sure it *is* only run on a sony laptop.

Alan

Re: Areca RAID driver remaining items?

[erich]

Dear Alan Cox,

This is good idea to make black list to prevent system hang up with MSI 
function.
But arcmsr need  to come up against none specific mainboards.
The case at my lab have same chipset but different maker.

Best Regards
Erich Chen

----- Original Message ----- 
From: "Alan Cox" <alan@lxorguk.ukuu.org.uk>
To: "erich" <erich@areca.com.tw>
Cc: "Arjan van de Ven" <arjan@infradead.org>; ""Christoph Hellwig"" 
<hch@infradead.org>; <linux-scsi@vger.kernel.org>; 
<linux-kernel@vger.kernel.org>; <billion.wu@areca.com.tw>; <akpm@osdl.org>; 
<oliver@neukum.org>
Sent: Thursday, February 23, 2006 7:59 PM
Subject: Re: Areca RAID driver remaining items?


> On Iau, 2006-02-23 at 17:50 +0800, erich wrote:
>> But unfortunately I found some mainboards will hang up if I always enable
>> this function in my lab.
>> To avoid this issue, I do an option for this case.
>>
>> But  Christoph Hellwig give me comment with it.
>
>
> Another thing you can also do for many of these cases is to use either
> the PCI or DMI interfaces to identify the problem board and
> automatically set the option as well.
>
> There are two ways to do this. One is
>
> struct pci_dev *bridge_dev = pci_get_slot(pdev->bus, PCI_DEVFN(0,0));
> if(bridge_dev) {
> if(bridge_dev->subsystem_vendor == 0xXXXX &&
> bridge_dev->subsystem_device == 0xXXXX)
> /* Match by svid/sdid for problem boards */
>
> The other is like this
>
> #include <linux/dmi.h>
>
> struct dmi_system_id problem_dmi_table[] = {
> {
> .ident = "Broken Board Name 1",
> .matches = {
> DMI_MATCH(DMI_SYS_VENDOR, "EvilCorp");
> DMI_MATCH(DMI_PRODUCTNAME, "Wombat 1000");
> }
> }
> {
> ditto per board
> },
> { } /* End of list mark
> };
>
>
> And then
>
> if (dmi_system_check(problem_dmi_table))
> disable_msi..
>
>
> The DMI code matches on the DMI strings in the ROM BIOS (the ones dumped
> by 'dmidecode')
>
>
> An example driver using this interface is drivers/char/sonypi.c which
> uses it to make sure it *is* only run on a sony laptop.
>
> Alan
> 

Re: Areca RAID driver remaining items?

[Christoph Hellwig]

On Thu, Feb 23, 2006 at 11:59:50AM +0000, Alan Cox wrote:
> On Iau, 2006-02-23 at 17:50 +0800, erich wrote:
> > But unfortunately I found some mainboards will hang up if I always enable 
> > this function in my lab.
> > To avoid this issue, I do an option for this case.
> > 
> > But  Christoph Hellwig give me comment with it.
> 
> 
> Another thing you can also do for many of these cases is to use either
> the PCI or DMI interfaces to identify the problem board and
> automatically set the option as well.
> 
> There are two ways to do this. One is 

Please avoid that unless really nessecary.  I doubt there's boards where
MSI would only be broken with the areca card but not with other MSI-capable
ones.  If a board or chipset is generally broken vs MSI it should be
added to the global MSI blacklist.  It's probably be nice to have a global
nomsi boot option instead of one in every driver aswell..

Re: Areca RAID driver remaining items?

[Randy.Dunlap]

On Fri, 24 Feb 2006, Christoph Hellwig wrote:

> On Thu, Feb 23, 2006 at 11:59:50AM +0000, Alan Cox wrote:
> > On Iau, 2006-02-23 at 17:50 +0800, erich wrote:
> > > But unfortunately I found some mainboards will hang up if I always enable
> > > this function in my lab.
> > > To avoid this issue, I do an option for this case.
> > >
> > > But  Christoph Hellwig give me comment with it.
> >
> >
> > Another thing you can also do for many of these cases is to use either
> > the PCI or DMI interfaces to identify the problem board and
> > automatically set the option as well.
> >
> > There are two ways to do this. One is
>
> Please avoid that unless really nessecary.  I doubt there's boards where
> MSI would only be broken with the areca card but not with other MSI-capable
> ones.  If a board or chipset is generally broken vs MSI it should be
> added to the global MSI blacklist.  It's probably be nice to have a global
> nomsi boot option instead of one in every driver aswell..

Jeff G. added an "msi" option to the sata_mv driver recently.
But yes, I expect it to be more of a platform issue than a
driver issue.

s2io network people report MSI interrupt problems on various
platforms (on netdev mailing list).

There are other reports (that I have at home, not visible to me
now).  It would be good to have an MSI expert around.

http://www.xenotime.net/linux/patches/pci_nomsi.patch adds a
global boot option to disable MSI interrupt assignments.

-- 
~Randy

Re: Areca RAID driver remaining items?

[Matthew Wilcox]

On Fri, Feb 24, 2006 at 09:03:47AM -0800, Randy.Dunlap wrote:
> On Fri, 24 Feb 2006, Christoph Hellwig wrote:
> > Please avoid that unless really nessecary.  I doubt there's boards where
> > MSI would only be broken with the areca card but not with other MSI-capable
> > ones.  If a board or chipset is generally broken vs MSI it should be
> > added to the global MSI blacklist.  It's probably be nice to have a global
> > nomsi boot option instead of one in every driver aswell..
> 
> http://www.xenotime.net/linux/patches/pci_nomsi.patch adds a
> global boot option to disable MSI interrupt assignments.

I like it.  How about adding pci=nomsi instead of pci_nomsi?

--- drivers/pci/pci.c   4 Feb 2006 04:51:55 -0000       1.28
+++ drivers/pci/pci.c   24 Feb 2006 19:33:25 -0000
@@ -900,8 +900,12 @@ static int __devinit pci_setup(char *str
                if (k)
                        *k++ = 0;
                if (*str && (str = pcibios_setup(str)) && *str) {
-                       /* PCI layer options should be handled here */
-                       printk(KERN_ERR "PCI: Unknown option `%s'\n", str);
+                       if (!strcmp(str, "nomsi")) {
+                               pci_msi_enable = 0;
+                       } else {
+                               printk(KERN_ERR "PCI: Unknown option `%s'\n",
+                                               str);
+                       }
                }
                str = k;
        }

Re: Areca RAID driver remaining items?

[Randy.Dunlap]

On Fri, 24 Feb 2006, Matthew Wilcox wrote:

> On Fri, Feb 24, 2006 at 09:03:47AM -0800, Randy.Dunlap wrote:
> > On Fri, 24 Feb 2006, Christoph Hellwig wrote:
> > > Please avoid that unless really nessecary.  I doubt there's boards where
> > > MSI would only be broken with the areca card but not with other MSI-capable
> > > ones.  If a board or chipset is generally broken vs MSI it should be
> > > added to the global MSI blacklist.  It's probably be nice to have a global
> > > nomsi boot option instead of one in every driver aswell..
> >
> > http://www.xenotime.net/linux/patches/pci_nomsi.patch adds a
> > global boot option to disable MSI interrupt assignments.
>
> I like it.  How about adding pci=nomsi instead of pci_nomsi?

Yes, that's probably better.  Thanks for the change.

> --- drivers/pci/pci.c   4 Feb 2006 04:51:55 -0000       1.28
> +++ drivers/pci/pci.c   24 Feb 2006 19:33:25 -0000
> @@ -900,8 +900,12 @@ static int __devinit pci_setup(char *str
>                 if (k)
>                         *k++ = 0;
>                 if (*str && (str = pcibios_setup(str)) && *str) {
> -                       /* PCI layer options should be handled here */
> -                       printk(KERN_ERR "PCI: Unknown option `%s'\n", str);
> +                       if (!strcmp(str, "nomsi")) {
> +                               pci_msi_enable = 0;
> +                       } else {
> +                               printk(KERN_ERR "PCI: Unknown option `%s'\n",
> +                                               str);
> +                       }
>                 }
>                 str = k;
>         }
>
>

-- 
~Randy

Re: Areca RAID driver remaining items?

[Randy.Dunlap]

On Fri, 24 Feb 2006 12:38:30 -0700 Matthew Wilcox wrote:

> On Fri, Feb 24, 2006 at 09:03:47AM -0800, Randy.Dunlap wrote:
> > On Fri, 24 Feb 2006, Christoph Hellwig wrote:
> > > Please avoid that unless really nessecary.  I doubt there's boards where
> > > MSI would only be broken with the areca card but not with other MSI-capable
> > > ones.  If a board or chipset is generally broken vs MSI it should be
> > > added to the global MSI blacklist.  It's probably be nice to have a global
> > > nomsi boot option instead of one in every driver aswell..
> > 
> > http://www.xenotime.net/linux/patches/pci_nomsi.patch adds a
> > global boot option to disable MSI interrupt assignments.
> 
> I like it.  How about adding pci=nomsi instead of pci_nomsi?
> 
> --- drivers/pci/pci.c   4 Feb 2006 04:51:55 -0000       1.28
> +++ drivers/pci/pci.c   24 Feb 2006 19:33:25 -0000
> @@ -900,8 +900,12 @@ static int __devinit pci_setup(char *str
>                 if (k)
>                         *k++ = 0;
>                 if (*str && (str = pcibios_setup(str)) && *str) {
> -                       /* PCI layer options should be handled here */
> -                       printk(KERN_ERR "PCI: Unknown option `%s'\n", str);
> +                       if (!strcmp(str, "nomsi")) {
> +                               pci_msi_enable = 0;
> +                       } else {
> +                               printk(KERN_ERR "PCI: Unknown option `%s'\n",
> +                                               str);
> +                       }
>                 }
>                 str = k;

OK, updated patch for "pci=nomsi" is now at
  http://www.xenotime.net/linux/patches/pci_nomsi.patch

Thanks.
---
~Randy

Re: Areca RAID driver remaining items?

[Matthew Wilcox]

On Sat, Feb 25, 2006 at 10:41:12PM -0800, Randy.Dunlap wrote:
> OK, updated patch for "pci=nomsi" is now at
>   http://www.xenotime.net/linux/patches/pci_nomsi.patch

After sleeping on it, I realised this wouldn't work if CONFIG_PCI_MSI
is disabled.  So how about this (not even compile-tested):

Signed-off-by: Matthew Wilcox <matthew@wil.cx>

Index: ./Documentation/kernel-parameters.txt
===================================================================
RCS file: /var/cvs/linux-2.6/Documentation/kernel-parameters.txt,v
retrieving revision 1.41.4.1
diff -u -p -r1.41.4.1 kernel-parameters.txt
--- ./Documentation/kernel-parameters.txt	18 Feb 2006 05:26:01 -0000	1.41.4.1
+++ ./Documentation/kernel-parameters.txt	26 Feb 2006 15:58:40 -0000
@@ -49,6 +49,7 @@ restrictions referred to are that the re
 	MCA	MCA bus support is enabled.
 	MDA	MDA console support is enabled.
 	MOUSE	Appropriate mouse support is enabled.
+	MSI	Message Signaled Interrupts (PCI).
 	MTD	MTD support is enabled.
 	NET	Appropriate network support is enabled.
 	NUMA	NUMA support is enabled.
@@ -1135,6 +1136,9 @@ running once the system is up.
 				Mechanism 2.
 		nommconf	[IA-32,X86_64] Disable use of MMCONFIG for PCI
 				Configuration
+		nomsi		[MSI] If the PCI_MSI kernel config parameter is
+				enabled, this kernel boot option can be used to
+				disable the use of MSI interrupts system-wide.
 		nosort		[IA-32] Don't sort PCI devices according to
 				order given by the PCI BIOS. This sorting is
 				done to get a device order compatible with
Index: ./drivers/pci/Kconfig
===================================================================
RCS file: /var/cvs/linux-2.6/drivers/pci/Kconfig,v
retrieving revision 1.8
diff -u -p -r1.8 Kconfig
--- ./drivers/pci/Kconfig	14 Sep 2005 12:56:32 -0000	1.8
+++ ./drivers/pci/Kconfig	26 Feb 2006 15:58:40 -0000
@@ -11,6 +11,10 @@ config PCI_MSI
 	   generate an interrupt using an inbound Memory Write on its
 	   PCI bus instead of asserting a device IRQ pin.
 
+	   Use of PCI MSI interrupts can be disabled at kernel boot time
+	   by using the 'pci=nomsi' option.  This disables MSI for the
+	   entire system.
+
 	   If you don't know what to do here, say N.
 
 config PCI_LEGACY_PROC
Index: ./drivers/pci/msi.c
===================================================================
RCS file: /var/cvs/linux-2.6/drivers/pci/msi.c,v
retrieving revision 1.17
diff -u -p -r1.17 msi.c
--- ./drivers/pci/msi.c	4 Feb 2006 04:51:55 -0000	1.17
+++ ./drivers/pci/msi.c	26 Feb 2006 15:58:40 -0000
@@ -755,6 +755,9 @@ void pci_disable_msi(struct pci_dev* dev
 	u16 control;
 	unsigned long flags;
 
+	if (!pci_msi_enable)
+ 		return;
+
    	if (!dev || !(pos = pci_find_capability(dev, PCI_CAP_ID_MSI)))
 		return;
 
@@ -1006,6 +1009,9 @@ void pci_disable_msix(struct pci_dev* de
 	int pos, temp;
 	u16 control;
 
+	if (!pci_msi_enable)
+ 		return;
+
    	if (!dev || !(pos = pci_find_capability(dev, PCI_CAP_ID_MSIX)))
 		return;
 
@@ -1121,6 +1127,11 @@ void msi_remove_pci_irq_vectors(struct p
 		}
 		dev->irq = temp;		/* Restore IOAPIC IRQ */
 	}
+}
+
+void pci_no_msi(void)
+{
+	pci_msi_enable = 0;
 }
 
 EXPORT_SYMBOL(pci_enable_msi);
Index: ./drivers/pci/pci.c
===================================================================
RCS file: /var/cvs/linux-2.6/drivers/pci/pci.c,v
retrieving revision 1.28
diff -u -p -r1.28 pci.c
--- ./drivers/pci/pci.c	4 Feb 2006 04:51:55 -0000	1.28
+++ ./drivers/pci/pci.c	26 Feb 2006 15:58:40 -0000
@@ -900,8 +900,12 @@ static int __devinit pci_setup(char *str
 		if (k)
 			*k++ = 0;
 		if (*str && (str = pcibios_setup(str)) && *str) {
-			/* PCI layer options should be handled here */
-			printk(KERN_ERR "PCI: Unknown option `%s'\n", str);
+			if (!strcmp(str, "nomsi")) {
+				pci_no_msi();
+			} else {
+				printk(KERN_ERR "PCI: Unknown option `%s'\n",
+						str);
+			}
 		}
 		str = k;
 	}
Index: ./drivers/pci/pci.h
===================================================================
RCS file: /var/cvs/linux-2.6/drivers/pci/pci.h,v
retrieving revision 1.13
diff -u -p -r1.13 pci.h
--- ./drivers/pci/pci.h	17 Jan 2006 14:51:41 -0000	1.13
+++ ./drivers/pci/pci.h	26 Feb 2006 15:58:40 -0000
@@ -50,8 +50,10 @@ extern int pci_msi_quirk;
 
 #ifdef CONFIG_PCI_MSI
 void disable_msi_mode(struct pci_dev *dev, int pos, int type);
+void pci_no_msi(void);
 #else
 static inline void disable_msi_mode(struct pci_dev *dev, int pos, int type) { }
+static inline void pci_no_msi(void) { }
 #endif
 
 extern int pcie_mch_quirk;

Re: Areca RAID driver remaining items?

[Randy.Dunlap]

On Sun, 26 Feb 2006 09:02:47 -0700 Matthew Wilcox wrote:

> On Sat, Feb 25, 2006 at 10:41:12PM -0800, Randy.Dunlap wrote:
> > OK, updated patch for "pci=nomsi" is now at
> >   http://www.xenotime.net/linux/patches/pci_nomsi.patch
> 
> After sleeping on it, I realised this wouldn't work if CONFIG_PCI_MSI
> is disabled.  So how about this (not even compile-tested):

It's good.  Thanks for catching that.

> Signed-off-by: Matthew Wilcox <matthew@wil.cx>
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>


> Index: ./Documentation/kernel-parameters.txt
> ===================================================================
> RCS file: /var/cvs/linux-2.6/Documentation/kernel-parameters.txt,v
> retrieving revision 1.41.4.1
> diff -u -p -r1.41.4.1 kernel-parameters.txt
> --- ./Documentation/kernel-parameters.txt	18 Feb 2006 05:26:01 -0000	1.41.4.1
> +++ ./Documentation/kernel-parameters.txt	26 Feb 2006 15:58:40 -0000
> @@ -49,6 +49,7 @@ restrictions referred to are that the re
>  	MCA	MCA bus support is enabled.
>  	MDA	MDA console support is enabled.
>  	MOUSE	Appropriate mouse support is enabled.
> +	MSI	Message Signaled Interrupts (PCI).
>  	MTD	MTD support is enabled.
>  	NET	Appropriate network support is enabled.
>  	NUMA	NUMA support is enabled.
> @@ -1135,6 +1136,9 @@ running once the system is up.
>  				Mechanism 2.
>  		nommconf	[IA-32,X86_64] Disable use of MMCONFIG for PCI
>  				Configuration
> +		nomsi		[MSI] If the PCI_MSI kernel config parameter is
> +				enabled, this kernel boot option can be used to
> +				disable the use of MSI interrupts system-wide.
>  		nosort		[IA-32] Don't sort PCI devices according to
>  				order given by the PCI BIOS. This sorting is
>  				done to get a device order compatible with
> Index: ./drivers/pci/Kconfig
> ===================================================================
> RCS file: /var/cvs/linux-2.6/drivers/pci/Kconfig,v
> retrieving revision 1.8
> diff -u -p -r1.8 Kconfig
> --- ./drivers/pci/Kconfig	14 Sep 2005 12:56:32 -0000	1.8
> +++ ./drivers/pci/Kconfig	26 Feb 2006 15:58:40 -0000
> @@ -11,6 +11,10 @@ config PCI_MSI
>  	   generate an interrupt using an inbound Memory Write on its
>  	   PCI bus instead of asserting a device IRQ pin.
>  
> +	   Use of PCI MSI interrupts can be disabled at kernel boot time
> +	   by using the 'pci=nomsi' option.  This disables MSI for the
> +	   entire system.
> +
>  	   If you don't know what to do here, say N.
>  
>  config PCI_LEGACY_PROC
> Index: ./drivers/pci/msi.c
> ===================================================================
> RCS file: /var/cvs/linux-2.6/drivers/pci/msi.c,v
> retrieving revision 1.17
> diff -u -p -r1.17 msi.c
> --- ./drivers/pci/msi.c	4 Feb 2006 04:51:55 -0000	1.17
> +++ ./drivers/pci/msi.c	26 Feb 2006 15:58:40 -0000
> @@ -755,6 +755,9 @@ void pci_disable_msi(struct pci_dev* dev
>  	u16 control;
>  	unsigned long flags;
>  
> +	if (!pci_msi_enable)
> + 		return;
> +
>     	if (!dev || !(pos = pci_find_capability(dev, PCI_CAP_ID_MSI)))
>  		return;
>  
> @@ -1006,6 +1009,9 @@ void pci_disable_msix(struct pci_dev* de
>  	int pos, temp;
>  	u16 control;
>  
> +	if (!pci_msi_enable)
> + 		return;
> +
>     	if (!dev || !(pos = pci_find_capability(dev, PCI_CAP_ID_MSIX)))
>  		return;
>  
> @@ -1121,6 +1127,11 @@ void msi_remove_pci_irq_vectors(struct p
>  		}
>  		dev->irq = temp;		/* Restore IOAPIC IRQ */
>  	}
> +}
> +
> +void pci_no_msi(void)
> +{
> +	pci_msi_enable = 0;
>  }
>  
>  EXPORT_SYMBOL(pci_enable_msi);
> Index: ./drivers/pci/pci.c
> ===================================================================
> RCS file: /var/cvs/linux-2.6/drivers/pci/pci.c,v
> retrieving revision 1.28
> diff -u -p -r1.28 pci.c
> --- ./drivers/pci/pci.c	4 Feb 2006 04:51:55 -0000	1.28
> +++ ./drivers/pci/pci.c	26 Feb 2006 15:58:40 -0000
> @@ -900,8 +900,12 @@ static int __devinit pci_setup(char *str
>  		if (k)
>  			*k++ = 0;
>  		if (*str && (str = pcibios_setup(str)) && *str) {
> -			/* PCI layer options should be handled here */
> -			printk(KERN_ERR "PCI: Unknown option `%s'\n", str);
> +			if (!strcmp(str, "nomsi")) {
> +				pci_no_msi();
> +			} else {
> +				printk(KERN_ERR "PCI: Unknown option `%s'\n",
> +						str);
> +			}
>  		}
>  		str = k;
>  	}
> Index: ./drivers/pci/pci.h
> ===================================================================
> RCS file: /var/cvs/linux-2.6/drivers/pci/pci.h,v
> retrieving revision 1.13
> diff -u -p -r1.13 pci.h
> --- ./drivers/pci/pci.h	17 Jan 2006 14:51:41 -0000	1.13
> +++ ./drivers/pci/pci.h	26 Feb 2006 15:58:40 -0000
> @@ -50,8 +50,10 @@ extern int pci_msi_quirk;
>  
>  #ifdef CONFIG_PCI_MSI
>  void disable_msi_mode(struct pci_dev *dev, int pos, int type);
> +void pci_no_msi(void);
>  #else
>  static inline void disable_msi_mode(struct pci_dev *dev, int pos, int type) { }
> +static inline void pci_no_msi(void) { }
>  #endif
>  
>  extern int pcie_mch_quirk;
> 


---

Re: Areca RAID driver remaining items?

[erich]

Dear Arjan van de Ven,
I had  misconstruction with
>> [Exception is that you can say that you are ok with a bigger mask for
>> this type of memory, but just don't do that if you're not]

it should be "pci_set_consistent_dma_mask(pdev, DMA_32BIT_MASK)."

Best Regards
Erich Chen

----- Original Message ----- 
From: "erich" <erich@areca.com.tw>
To: "Arjan van de Ven" <arjan@infradead.org>
Cc: """"Christoph Hellwig"""" <hch@infradead.org>; 
<linux-scsi@vger.kernel.org>; <linux-kernel@vger.kernel.org>; 
<billion.wu@areca.com.tw>; <alan@lxorguk.ukuu.org.uk>; <akpm@osdl.org>; 
<oliver@neukum.org>
Sent: Friday, February 24, 2006 10:08 AM
Subject: Re: Areca RAID driver remaining items?


> Dear Arjan van de Ven,
>
> I would keep dma_alloc_coherent usage.
>
>> [Exception is that you can say that you are ok with a bigger mask for
>> this type of memory, but just don't do that if you're not]
>
> Should I remove "pci_set_dma_mask(pci_device, DMA_64BIT_MASK)" for this 
> case?
>
> Best Regards
> Erich Chen
>
> ----- Original Message ----- 
> From: "Arjan van de Ven" <arjan@infradead.org>
> To: "erich" <erich@areca.com.tw>
> Cc: """Christoph Hellwig""" <hch@infradead.org>; 
> <linux-scsi@vger.kernel.org>; <linux-kernel@vger.kernel.org>; 
> <billion.wu@areca.com.tw>; <alan@lxorguk.ukuu.org.uk>; <akpm@osdl.org>; 
> <oliver@neukum.org>
> Sent: Thursday, February 23, 2006 8:07 PM
> Subject: Re: Areca RAID driver remaining items?
>
>
>> On Thu, 2006-02-23 at 19:51 +0800, erich wrote:
>>> If Linux can not assurent the contingous memory space allocating of
>>> "dma_alloc_coherent" .
>>
>> coherent memory is guaranteed to be in the "lower" 32 bit of memory!
>> So that is good news, I think you are just fine.
>>
>> [Exception is that you can say that you are ok with a bigger mask for
>> this type of memory, but just don't do that if you're not]
>>
>>
>>> When arcmsr get a physical ccb address from areca's firmware.
>>> Does linux has any functions for converting of  "bus to virtual" ?
>>
>> not without using pools. You would have to search the list of memory you
>> gave it to find that out.
>>
>> (USB has a similar problem, afaik they solved it with pools)
>>
>>
> 

Re: Areca RAID driver remaining items?

[erich]

Dear Christoph Hellwig,

Do you have any comments with arcmsr SATA RAID driver on sysfs attribute?
There were four types of function template completed in linux.
iscsi_function_template
sas_function_template
spi_function_template
fc_function_template
Do you have opintion with "arcmsr_transport_functions" ?
and Which function templete does "arcmsr" belong to?

Best Regards
Erich Chen

Re: Areca RAID driver remaining items?

[Matthew Wilcox]

On Mon, Feb 27, 2006 at 07:27:33PM +0800, erich wrote:
> Dear Christoph Hellwig,
> 
> Do you have any comments with arcmsr SATA RAID driver on sysfs attribute?
> There were four types of function template completed in linux.
> iscsi_function_template
> sas_function_template
> spi_function_template
> fc_function_template
> Do you have opintion with "arcmsr_transport_functions" ?
> and Which function templete does "arcmsr" belong to?

The transport really refers to the physical cabling.  iSCSI is
SCSI-over-IP, SAS is Serial Attached SCSI, SPI is Parallel SCSI and FC
is Fibre Channel.  It seems to me from your website that you're
using SATA-II drives, so you'll want to look at the SAS template for
exposing cabling details.

You missed one useful class though, the raid_function_template, which
you almost certainly want to use.  See drivers/scsi/raid_class.c and
include/linux/raid_class.h.  It's early days for the RAID class, so you
may wish to extend it to meet your needs.

James, I presume it's been mis-placed for convenience and it'll move to
block/ or drivers/block/ at some point?