LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Petr Vandrovec <petr@vandrovec.name>
To: bunk@stusta.de
Cc: linux-kernel@vger.kernel.org, jengelh@linux01.gwdg.de
Subject: Re: 2.6.21-rc regression in mptbase
Date: Sat, 24 Mar 2007 02:02:13 +0100	[thread overview]
Message-ID: <20070324010213.GA32620@vana.vc.cvut.cz> (raw)
In-Reply-To: <460475EF.1040109@vc.cvut.cz>

> On Fri, Mar 23, 2007 at 11:39:12PM +0100, Jan Engelhardt wrote:
> > Hello world,
> > 
> > 
> > in at least 2.6.21-rc4, one or more of the mptscsi scsi modules is 
> > broken with respect to not detecting any harddisk (VMware provides that 
> > virtual LSI MPT controller), which means no working system.
> > No problems in 2.6.20.2.
> >...
> 
> Could be a bug in the driver or a bug in the emulation exposed by a 
> change in the driver.
> 
> Can you bisect which change to the driver broke it?

Hello,
   it is bug in the emulation.  It should be fixed in Workstation 6.0 RC1.  If you
want to use VMware's LSILogic emulation with older products, you need fix below until
new releases come out (or unless I'll put out binary patch to fix binaries to
return 16 instead of previous value).
							Petr

If port reports that no devices are connected to it, assume that 16 devices
are there.  Hopefully nobody will ever build device with port but no devices,
and even for them it should be safe as before code always probed 16 devices
regardless of MaxDevices reported by port facts.

Signed-off-by:  Petr Vandrovec <petr@vandrovec.name>

--- linux/drivers/message/fusion/mptbase.c.orig	2007-03-20 13:47:28.000000000 -0700
+++ linux/drivers/message/fusion/mptbase.c	2007-03-23 17:45:51.000000000 -0700
@@ -2564,6 +2564,16 @@
 	pfacts->IOCStatus = le16_to_cpu(pfacts->IOCStatus);
 	pfacts->IOCLogInfo = le32_to_cpu(pfacts->IOCLogInfo);
 	pfacts->MaxDevices = le16_to_cpu(pfacts->MaxDevices);
+	/*
+	 * VMware emulation is broken, its PortFact's MaxDevices reports value
+	 * programmed by IOC Init, so if you program IOC Init to 256 (which is 0,
+	 * as that field is only 8 bit), it reports back 0 in port facts, instead
+	 * of 256...  And unfortunately using 256 triggers another bug in the
+	 * code (parallel SCSI can have only 16 devices).
+	 */
+	if (pfacts->MaxDevices == 0) {
+	   pfacts->MaxDevices = 16;
+	}
 	pfacts->PortSCSIID = le16_to_cpu(pfacts->PortSCSIID);
 	pfacts->ProtocolFlags = le16_to_cpu(pfacts->ProtocolFlags);
 	pfacts->MaxPostedCmdBuffers = le16_to_cpu(pfacts->MaxPostedCmdBuffers);

       reply	other threads:[~2007-03-24  1:02 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <460475EF.1040109@vc.cvut.cz>
2007-03-24  1:02 ` Petr Vandrovec [this message]
2007-04-01 21:55   ` Jan Engelhardt
2007-03-23 22:39 Jan Engelhardt
2007-03-23 23:06 ` Chuck Ebbert
2007-03-24  0:14   ` Jan Engelhardt
2007-03-24  0:30 ` Adrian Bunk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070324010213.GA32620@vana.vc.cvut.cz \
    --to=petr@vandrovec.name \
    --cc=bunk@stusta.de \
    --cc=jengelh@linux01.gwdg.de \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: 2.6.21-rc regression in mptbase' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).