changelog.megaraid

linux 内核源代码

Release Date	: Thu Nov 16 15:32:35 EST 2006 -
				Sumant Patro <[e-mail]>
Current Version : 2.20.5.1 (scsi module), 2.20.2.6 (cmm module)
Older Version	: 2.20.4.9 (scsi module), 2.20.2.6 (cmm module)

1.	Changes in Initialization to fix kdump failure.
	Send SYNC command on loading.
	This command clears the pending commands in the adapter
	and re-initialize its internal RAID structure.
	Without this change, megaraid driver either panics or fails to
	initialize the adapter during kdump's second kernel boot
	if there are pending commands or interrupts from other devices
	sharing the same IRQ.
2. 	Authors email-id domain name changed from lsil.com to lsi.com.
	Also modified the MODULE_AUTHOR to [e-mail]

Release Date	: Fri May 19 09:31:45 EST 2006 - Seokmann Ju <[e-mail]>
Current Version : 2.20.4.9 (scsi module), 2.20.2.6 (cmm module)
Older Version	: 2.20.4.8 (scsi module), 2.20.2.6 (cmm module)

1.	Fixed a bug in megaraid_init_mbox().
	Customer reported "garbage in file on x86_64 platform".
	Root Cause: the driver registered controllers as 64-bit DMA capable
	for those which are not support it.
	Fix: Made change in the function inserting identification machanism
	identifying 64-bit DMA capable controllers.

	> -----Original Message-----
	> From: Vasily Averin [mailto:[e-mail]]
	> Sent: Thursday, May 04, 2006 2:49 PM
	> To: [e-mail]; Kolli, Neela; Mukker, Atul;
	> Ju, Seokmann; Bagalkote, Sreenivas;
	> [e-mail]; [e-mail]
	> Subject: megaraid_mbox: garbage in file
	>
	> Hello all,
	>
	> I've investigated customers claim on the unstable work of
	> their node and found a
	> strange effect: reading from some files leads to the
	>  "attempt to access beyond end of device" messages.
	>
	> I've checked filesystem, memory on the node, motherboard BIOS
	> version, but it
	> does not help and issue still has been reproduced by simple
	> file reading.
	>
	> Reproducer is simple:
	>
	> echo 0xffffffff >/proc/sys/dev/scsi/logging_level ;
	> cat /vz/private/101/root/etc/ld.so.cache >/tmp/ttt  ;
	> echo 0 >/proc/sys/dev/scsi/logging
	>
	> It leads to the following messages in dmesg
	>
	> sd_init_command: disk=sda, block=871769260, count=26
	> sda : block=871769260
	> sda : reading 26/26 512 byte blocks.
	> scsi_add_timer: scmd: f79ed980, time: 7500, (c02b1420)
	> sd 0:1:0:0: send 0xf79ed980                  sd 0:1:0:0:
	>         command: Read (10): 28 00 33 f6 24 ac 00 00 1a 00
	> buffer = 0xf7cfb540, bufflen = 13312, done = 0xc0366b40,
	> queuecommand 0xc0344010
	> leaving scsi_dispatch_cmnd()
	> scsi_delete_timer: scmd: f79ed980, rtn: 1
	> sd 0:1:0:0: done 0xf79ed980 SUCCESS        0 sd 0:1:0:0:
	>         command: Read (10): 28 00 33 f6 24 ac 00 00 1a 00
	> scsi host busy 1 failed 0
	> sd 0:1:0:0: Notifying upper driver of completion (result 0)
	> sd_rw_intr: sda: res=0x0
	> 26 sectors total, 13312 bytes done.
	> use_sg is 4
	> attempt to access beyond end of device
	> sda6: rw=0, want=1044134458, limit=951401367
	> Buffer I/O error on device sda6, logical block 522067228
	> attempt to access beyond end of device

2.	When INQUIRY with EVPD bit set issued to the MegaRAID controller,
	system memory gets corrupted.
	Root Cause: MegaRAID F/W handle the INQUIRY with EVPD bit set
	incorrectly.
	Fix: MegaRAID F/W has fixed the problem and being process of release,
	soon. Meanwhile, driver will filter out the request.

3.	One of member in the data structure of the driver leads unaligne
	issue on 64-bit platform.
	Customer reporeted "kernel unaligned access addrss" issue when
	application communicates with MegaRAID HBA driver.
	Root Cause: in uioc_t structure, one of member had misaligned and it
	led system to display the error message.
	Fix: A patch submitted to community from following folk.

	> -----Original Message-----
	> From: [e-mail]
	> [mailto:[e-mail]] On Behalf Of Sakurai Hiroomi
	> Sent: Wednesday, July 12, 2006 4:20 AM
	> To: [e-mail]; [e-mail]
	> Subject: Re: Help: strange messages from kernel on IA64 platform
	>
	> Hi,
	>
	> I saw same message.
	>
	> When GAM(Global Array Manager) is started, The following
	> message output.
	> kernel: kernel unaligned access to 0xe0000001fe1080d4,
	> ip=0xa000000200053371
	>
	> The uioc structure used by ioctl is defined by packed,
	> the allignment of each member are disturbed.
	> In a 64 bit structure, the allignment of member doesn't fit 64 bit
	> boundary. this causes this messages.
	> In a 32 bit structure, we don't see the message because the allinment
	> of member fit 32 bit boundary even if packed is specified.
	>
	> patch
	> I Add 32 bit dummy member to fit 64 bit boundary. I tested.
	> We confirmed this patch fix the problem by IA64 server.
	>
	> **************************************************************
	> ****************
	> --- linux-2.6.9/drivers/scsi/megaraid/megaraid_ioctl.h.orig
	> 2006-04-03 17:13:03.000000000 +0900
	> +++ linux-2.6.9/drivers/scsi/megaraid/megaraid_ioctl.h
	> 2006-04-03 17:14:09.000000000 +0900
	> @@ -132,6 +132,10 @@
	>  /* Driver Data: */
	>          void __user *           user_data;
	>          uint32_t                user_data_len;
	> +
	> +        /* 64bit alignment */
	> +        uint32_t                pad_0xBC;
	> +
	>          mraid_passthru_t        __user *user_pthru;
	>
	>          mraid_passthru_t        *pthru32;
	> **************************************************************
	> ****************

Release Date	: Mon Apr 11 12:27:22 EST 2006 - Seokmann Ju <[e-mail]>
Current Version : 2.20.4.8 (scsi module), 2.20.2.6 (cmm module)
Older Version	: 2.20.4.7 (scsi module), 2.20.2.6 (cmm module)

1.	Fixed a bug in megaraid_reset_handler().
	Customer reported "Unable to handle kernel NULL pointer dereference
	at virtual address 00000000" when system goes to reset condition
	for some reason. It happened randomly.
	Root Cause: in the megaraid_reset_handler(), there is possibility not
	returning pending packets in the pend_list if there are multiple
	pending packets.
	Fix: Made the change in the driver so that it will return all packets
	in the pend_list.

2.	Added change request.
	As found in the following URL, rmb() only didn't help the
	problem. I had to increase the loop counter to 0xFFFFFF. (6 F's)
	http://marc.theaimsgroup.com/?l=linux-scsi&m=110971060502497&w=2

	I attached a patch for your reference, too.
	Could you check and get this fix in your driver?

	Best Regards,
	Jun'ichi Nomura

Release Date	: Fri Nov 11 12:27:22 EST 2005 - Seokmann Ju <[e-mail]>
Current Version : 2.20.4.7 (scsi module), 2.20.2.6 (cmm module)
Older Version	: 2.20.4.6 (scsi module), 2.20.2.6 (cmm module)

1.	Sorted out PCI IDs to remove megaraid support overlaps.
	Based on the patch from Daniel, sorted out PCI IDs along with
	charactor node name change from 'megadev' to 'megadev_legacy' to avoid
	conflict.
	---
	Hopefully we'll be getting the build restriction zapped much sooner, 
	but we should also be thinking about totally removing the hardware 
	support overlap in the megaraid drivers.

	This patch pencils in a date of Feb 06 for this, and performs some 
	printk abuse in hope that existing legacy users might pick up on what's
	going on.

	Signed-off-by: Daniel Drake <[e-mail]>
	---

2.	Fixed a issue: megaraid always fails to reset handler.
	---
	I found that the megaraid driver always fails to reset the
	adapter with the following message:
		megaraid: resetting the host...
		megaraid mbox: reset sequence completed successfully
		megaraid: fast sync command timed out
		megaraid: reservation reset failed
	when the "Cluster mode" of the adapter BIOS is enabled.
	So, whenever the reset occurs, the adapter goes to
	offline and just become unavailable.

	Jun'ichi Nomura [mailto:[e-mail]]
	---

Release Date	: Mon Mar 07 12:27:22 EST 2005 - Seokmann Ju <[e-mail]>
Current Version : 2.20.4.6 (scsi module), 2.20.2.6 (cmm module)
Older Version	: 2.20.4.5 (scsi module), 2.20.2.5 (cmm module)

1.	Added IOCTL backward compatibility.
	Convert megaraid_mm driver to new compat_ioctl entry points.
	I don't have easy access to hardware, so only compile tested.
		- Signed-off-by:Andi Kleen <[e-mail]>

2.	megaraid_mbox fix: wrong order of arguments in memset()
	That, BTW, shows why cross-builds are useful-the only indication of
	problem had been a new warning showing up in sparse output on alpha
	build (number of exceeding 256 got truncated).
		- Signed-off-by: Al Viro
		<[e-mail]>

3.	Convert pci_module_init to pci_register_driver
	Convert from pci_module_init to pci_register_driver
	(from:http://kerneljanitors.org/TODO)
		- Signed-off-by: Domen Puncer <[e-mail]>

4.	Use the pre defined DMA mask constants from dma-mapping.h
	Use the DMA_{64,32}BIT_MASK constants from dma-mapping.h when calling
	pci_set_dma_mask() or pci_set_consistend_dma_mask(). See
	http://marc.theaimsgroup.com/?t=108001993000001&r=1&w=2 for more
	details.
		Signed-off-by: Tobias Klauser <[e-mail]>
		Signed-off-by: Domen Puncer <[e-mail]>

5.	Remove SSID checking for Dobson, Lindsay, and Verde based products.
	Checking the SSVID/SSID for controllers which have Dobson, Lindsay,
	and Verde is unnecessary because device ID has been assigned by LSI
	and it is unique value. So, all controllers with these IOPs have to be
	supported by the driver regardless SSVID/SSID.

6.	Date Thu, 27 Jan 2005 04:31:09 +0100 
	From Herbert Poetzl <> 
	Subject RFC: assert_spin_locked() for 2.6 

	Greetings!

	overcautious programming will kill your kernel ;)
	ever thought about checking a spin_lock or even
	asserting that it must be held (maybe just for
	spinlock debugging?) ...

	there are several checks present in the kernel
	where somebody does a variation on the following:

	  BUG_ON(!spin_is_locked(&some_lock));

	so what's wrong about that? nothing, unless you
	compile the code with CONFIG_DEBUG_SPINLOCK but 
	without CONFIG_SMP ... in which case the BUG()
	will kill your kernel ...

	maybe it's not advised to make such assertions, 
	but here is a solution which works for me ...
	(compile tested for sh, x86_64 and x86, boot/run
	tested for x86 only)

	best,
	Herbert

		- Herbert Poetzl <[e-mail]>, Thu, 27 Jan 2005

Release Date	: Thu Feb 03 12:27:22 EST 2005 - Seokmann Ju <[e-mail]>
Current Version	: 2.20.4.5 (scsi module), 2.20.2.5 (cmm module)
Older Version	: 2.20.4.4 (scsi module), 2.20.2.4 (cmm module)

1.	Modified name of two attributes in scsi_host_template.
	On Wed, 2005-02-02 at 10:56 -0500, Ju, Seokmann wrote:
	> +	.sdev_attrs			= megaraid_device_attrs,
	> +	.shost_attrs			= megaraid_class_device_attrs,

	These are, perhaps, slightly confusing names.
	The terms device and class_device have well defined meanings in the
	generic device model, neither of which is what you mean here.
	Why not simply megaraid_sdev_attrs and megaraid_shost_attrs?

	Other than this, it looks fine to me too.

Release Date	: Thu Jan 27 00:01:03 EST 2005 - Atul Mukker <[e-mail]>
Current Version	: 2.20.4.4 (scsi module), 2.20.2.5 (cmm module)
Older Version	: 2.20.4.3 (scsi module), 2.20.2.4 (cmm module)

1.	Bump up the version of scsi module due to its conflict.

Release Date	: Thu Jan 21 00:01:03 EST 2005 - Atul Mukker <[e-mail]>
Current Version	: 2.20.4.3 (scsi module), 2.20.2.5 (cmm module)
Older Version	: 2.20.4.2 (scsi module), 2.20.2.4 (cmm module)

1.	Remove driver ioctl for logical drive to scsi address translation and
	replace with the sysfs attribute. To remove drives and change
	capacity, application shall now use the device attribute to get the
	logical drive number for a scsi device. For adding newly created
	logical drives, class device attribute would be required to uniquely
	identify each controller.
		- Atul Mukker <[e-mail]>

	"James, I've been thinking about this a little more, and you may be on
	to something here. Let each driver add files as such:"

		- Matt Domsch <[e-mail]>, 12.15.2004
		 linux-scsi mailing list


	"Then, if you simply publish your LD number as an extra parameter of
	the device, you can look through /sys to find it."