fedora core 6 1.2949 + vserver 2.2.0
[linux-2.6.git] / Documentation / scsi / ChangeLog.megaraid
index a9356c6..a056bbe 100644 (file)
@@ -1,3 +1,252 @@
+Release Date   : Fri May 19 09:31:45 EST 2006 - Seokmann Ju <sju@lsil.com>
+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:vvs@sw.ru]
+       > Sent: Thursday, May 04, 2006 2:49 PM
+       > To: linux-scsi@vger.kernel.org; Kolli, Neela; Mukker, Atul;
+       > Ju, Seokmann; Bagalkote, Sreenivas;
+       > James.Bottomley@SteelEye.com; devel@openvz.org
+       > 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: linux-scsi-owner@vger.kernel.org
+       > [mailto:linux-scsi-owner@vger.kernel.org] On Behalf Of Sakurai Hiroomi
+       > Sent: Wednesday, July 12, 2006 4:20 AM
+       > To: linux-scsi@vger.kernel.org; linux-kernel@vger.kernel.org
+       > 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 <sju@lsil.com>
+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 <sju@lsil.com>
+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 <dsd@gentoo.org>
+       ---
+
+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:jnomura@mtc.biglobe.ne.jp]
+       ---
+
+Release Date   : Mon Mar 07 12:27:22 EST 2005 - Seokmann Ju <sju@lsil.com>
+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 <ak@muc.de>
+
+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
+               <viro@parcelfarce.linux.theplanet.co.uk>
+
+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 <domen@coderock.org>
+
+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 <tklauser@nuerscht.ch>
+               Signed-off-by: Domen Puncer <domen@coderock.org>
+
+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 <herbert@13thfloor.at>, Thu, 27 Jan 2005
+
 Release Date   : Thu Feb 03 12:27:22 EST 2005 - Seokmann Ju <sju@lsil.com>
 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)