Bug 1015558
| Summary: | Kernel 3.11.1 and higher does not boot on VMware VM with BusLogic driver (32-bit) | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Bojan Smojver <bojan> | ||||||||
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | high | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 19 | CC: | gansalmon, itamar, jonathan, kernel-maint, lonelywoolf, madhu.chinakonda, marcelo.barbosa, mstevens, nettrash | ||||||||
| Target Milestone: | --- | Keywords: | Patch, Reopened | ||||||||
| Target Release: | --- | ||||||||||
| Hardware: | i686 | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | kernel-3.11.7-100.fc18 | Doc Type: | Bug Fix | ||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2013-11-13 02:15:35 UTC | Type: | Bug | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
Created attachment 807665 [details]
Hang with 64-bit kernel 3.11.2
This is probably an upstream bug! Please report it to: https://bugzilla.kernel.org do you shure with upstream? ) I'm confirming bug with vmware ESXi 5.5 in 32-bit vm installation (In reply to lonelywoolf from comment #4) > I'm confirming bug with vmware ESXi 5.5 in 32-bit vm installation Thank you kindly for your help. (In reply to lonelywoolf from comment #4) > I'm confirming bug with vmware ESXi 5.5 in 32-bit vm installation Just one question: do you see this problem just with BusLogic controller or in general? What version of VMWare? Are you using out-of-tree VMWare modules? Can you attach the output dmesg after a working boot, and save the output of dmesg somewhere when it fails (or the output of a serial console)? Can you bisect with kernels in koji to see which point in the 3.11 development series it started failing? Did you report this upstream as suggested in comment #2? (In reply to Josh Boyer from comment #7) > What version of VMWare? I do not know. I have asked the VMware admin, but I was not given that information yet. > Are you using out-of-tree VMWare modules? No. Everything is vanilla Fedora. > Can you attach the output dmesg after a working boot, and save the output of > dmesg somewhere when it fails (or the output of a serial console)? I will do the first one. For the second one, I'll have to ask the VMware admin to do it. May take a few days. > Can you bisect with kernels in koji to see which point in the 3.11 > development series it started failing? I can try this, but it may take weeks. > Did you report this upstream as suggested in comment #2? No, because I am not yet convinced it is an upstream bug. I have googled far and wide and could not find anything resembling this. The closest was some problem in one of 3.11 RCs where some crypto module was not included, due to dependency problems caused by recent changes. What I also did try is switching SCSI controller to LSI Logic SAS. I rebuilt initramfs with --add-driver=mptsas (I checked with lsinitrd and indeed a number of modules did get included: mptsas, mptscsih, mptbase). The VMware admin then switched the VM to that controller and rebooted. Same result. Now, whether I screwed something up and the test was invalid or whether this really is BusLogic unrelated, I cannot tell for sure. Created attachment 810827 [details]
dmesg of 3.10.11-200.fc19.i686
Successful boot.
(In reply to Bojan Smojver from comment #6) > (In reply to lonelywoolf from comment #4) > > I'm confirming bug with vmware ESXi 5.5 in 32-bit vm installation > > Just one question: do you see this problem just with BusLogic controller or > in general? Only with BusLogic I will test all kernels tomorrow on my installation. (In reply to lonelywoolf from comment #11) > > Just one question: do you see this problem just with BusLogic controller or > > in general? > > Only with BusLogic Thanks for that info. My test with LSI must have been bogus then. Interesting link: http://www.spinics.net/lists/linux-scsi/msg69044.html Includes a patch, which, AFAICT, is not included in the current head or stable. (In reply to Bojan Smojver from comment #14) > Interesting link: > > http://www.spinics.net/lists/linux-scsi/msg69044.html > > Includes a patch, which, AFAICT, is not included in the current head or > stable. It is this commit that broke the driver to require the above patch: 839cb99e8f748391059d10388c8aea48a88c142c. Not the one I mentioned in comment #0. Josh, Could you please produce a scratch build with the patch included? Or just wind back the driver in a scratch build so that we can see whether this fixes the issue? Kernel 3.11.4 now running on my VM with mptspi driver. The problem with my previous test was that I added mptsas driver, but the virtual controller is actually LSI parallel SCSI on that VM. So, most definitely a BusLogic only problem. (In reply to Bojan Smojver from comment #15) > (In reply to Bojan Smojver from comment #14) > > Interesting link: > > > > http://www.spinics.net/lists/linux-scsi/msg69044.html > > > > Includes a patch, which, AFAICT, is not included in the current head or > > stable. > > It is this commit that broke the driver to require the above patch: > 839cb99e8f748391059d10388c8aea48a88c142c. Not the one I mentioned in comment > #0. > > Josh, > > Could you please produce a scratch build with the patch included? Or just > wind back the driver in a scratch build so that we can see whether this > fixes the issue? Scratch build with the patch: http://koji.fedoraproject.org/koji/taskinfo?taskID=6062997 Thanks for chasing things down on this one. Let me know if that works. (In reply to Josh Boyer from comment #17) > Scratch build with the patch: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=6062997 > > Thanks for chasing things down on this one. Let me know if that works. Thanks for that. Unless someone beats me to it, I'll give it a go. It make take a few days. (In reply to Josh Boyer from comment #17) > Scratch build with the patch: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=6062997 > > Thanks for chasing things down on this one. Let me know if that works. Yep, that's the fix. Great, thanks for testing. I'll get the patch included soon. Patch added in Fedora git. kernel-3.11.6-200.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/kernel-3.11.6-200.fc19 kernel-3.11.6-100.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/kernel-3.11.6-100.fc18 kernel-3.11.6-300.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/kernel-3.11.6-300.fc20 Package kernel-3.11.6-300.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kernel-3.11.6-300.fc20' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-19611/kernel-3.11.6-300.fc20 then log in and leave karma (feedback). kernel-3.11.6-300.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. kernel-3.11.6-200.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report. kernel-3.11.6-101.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/kernel-3.11.6-101.fc18 Package kernel-3.11.6-101.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kernel-3.11.6-101.fc18' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-20545/kernel-3.11.6-101.fc18 then log in and leave karma (feedback). kernel-3.11.7-100.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/kernel-3.11.7-100.fc18 kernel-3.11.7-100.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report. Hello Few days ago I updated my Fedora 18, now I cant compile Vmware 9.2 Need help with this. Fedora 18 (3.11.7-100.fc18.x86_64) + Vmware 9.2 Log:http://pastebin.com/kttLFAeY Thank you. |
Created attachment 807664 [details] Hang with 32-bit kernel 3.11.3 Description of problem: No kernels from 3.11.1 to 3.11.3 will boot inside this VMware VM. No LVM volumes are found. Switching back to 3.10 boots immediately. I am suspecting that latest changes to BusLogic driver may be the problem. See kernel commit 391e2f25601e34a7d7e5dc155e487bc58dffd8c6. Version-Release number of selected component (if applicable): kernel-3.11.3-201.fc19 How reproducible: Always. Steps to Reproduce: 1. yum -y update 2. reboot 3. Hang. Actual results: Kernel hangs on boot. LVM volumes cannot be found. Expected results: Boots fine with 3.10, so it should boot fine with 3.11? Additional info: I have even tried a 64-bit 3.11.2 kernel, because the CPUs support it. Same result - hang.