After compiling 2.6.21 with the same .config as 2.6.20 using genkernel, I get: determining root device block device /dev/sda3 is not a valid root device the root block device is unspecified or not detected Only thing I found on google was this quote from #gentoo andy_t_roo wrote: from #gentoo : (4:19:28 PM) DrChandra: andy_t_roo: Looks like it needs to be a a bug against version 3.04.04 of the driver, that Eric Moore submitted in February against 2.6.20. the resolution to my problem was via replacing the .21 drivers with the .20 drivers (literally replacing the /usr/src/linux/drivers/message/fusion directory) and recompiling. Reproducible: Always
Most recent VMware guest install are using this Fusion driver.. so this is indeed a critical problem.
Can you reproduce this on the latest gentoo-sources-2.6.22 release?
(In reply to comment #2) > Can you reproduce this on the latest gentoo-sources-2.6.22 release? Just tested gentoo sources 2.6.22-r1 and I have the same problem. I am using the /proc/config.gz from the 2007.0 minimal install disk and it worked fine with 2.6.20.
What kind of controller do you have and how is it attached (parallel/FC/SAS)? Can you please post both the 2.6.20 and the 2.6.22 .config and dmesg output? Thanks.
Here is a thread over at the vmware forums http://www.vmware.com/community/thread.jspa?messageID=675110 Their is a post form jsg@q1 that includes a possible patch.
Here is the patch they propose in the vmware thread: diff -uNr linux-2.6.21.3/drivers/message/fusion/mptbase.c linux-2.6.21.3-patched/drivers/message/fusion/mptbase.c --- linux-2.6.21.3/drivers/message/fusion/mptbase.c 2007-05-24 18:22:47.000000000 -0300 +++ linux-2.6.21.3-patched/drivers/message/fusion/mptbase.c 2007-05-30 15:46:49.000000000 -0300 @@ -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);
So have you tested this patch? Does it fix the problem for you?
OK, just discovered (as you may have) that this patch doesn't apply cleanly. Please try the one I'm attaching. In /usr/src/linux, type: patch -p0 < fusion_mptbase.patch
Created attachment 126178 [details, diff] fusion_mptbase.patch
Thanks that patch works fine
Please don't close bugs until we actually ship the fix
It's great the patch works for you, unfortunately it's not going to be included upstream. Upstream says: "Since it is a problem not specific to the kernel, no 'fix' or workaround is going to be included." So your choices are either to keep/maintain the patch yourself, complain to VMware, or upgrade to a newer version of VMware.
The upstream thread indicates this is fixed in version "WS6.0", I hope that means something to someone http://marc.info/?l=linux-scsi&m=118591877927022&w=2
*** Bug 187809 has been marked as a duplicate of this bug. ***