https://bugzilla.novell.com/show_bug.cgi?id=862163 https://bugzilla.novell.com/show_bug.cgi?id=862163#c2 --- Comment #2 from Tony Su 2014-02-07 19:20:14 UTC --- Some additional info. Apparently this is a common problem when deploying in VMware. Unknown why this problem exists only when installing openSUSE in "minimal server mode" -- I don't see this problem at all when installing any Desktop (I've installed KDE, XFCE, LXDE). So, I assume that this may be an issue where implementation overlooked installing openSUSE without a Desktop or is for some reason tied into installing a Desktop(I can't imagine why). Unfortunately the published solution to simply blacklist in /etc/modprobe.d/blacklist on Debian type systems does not seem to work on openSUSE. Have attempted to add blacklist i2c_piix4 to /etc/modprobe.d/50-blacklist.conf But it didn't work. I then tried moving the blacklist in priority before system-conf by modifying the filename prefix, but still no diff. So, it's possible that somewhere a solution already exists when a Desktop is installed although I haven't yet found a published generic solution for openSUSE and may be related to "enlightenment"(when an install recognizes it's being installed in a virtualized environment). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=862163 https://bugzilla.novell.com/show_bug.cgi?id=862163#c3 --- Comment #3 from Tony Su 2014-02-17 16:25:11 UTC --- Maybe I should have done this earlier, but I have now found that this problem also exists in IceWM and LXDE 13.1 running as a VM Guest. This can be easily verified by searching the logs, the following is from LXDE # cat /var/log/messages | grep SMBus 2014-02-03T15:54:48.909932-08:00 Personal-LXDE kernel: [ 50.284427] piix4_smbus 0000:00:07.3: Host SMBus controller not enabled! 2014-02-04T10:32:25.620543-08:00 Personal-LXDE kernel: [ 55.318665] piix4_smbus 0000:00:07.3: Host SMBus controller not enabled! 2014-02-06T09:15:21.144446-08:00 Personal-LXDE kernel: [ 43.061389] piix4_smbus 0000:00:07.3: Host SMBus controller not enabled! 2014-02-10T15:52:15.265080-08:00 Personal-LXDE kernel: [ 18.501921] piix4_smbus 0000:00:07.3: Host SMBus controller not enabled! 2014-02-14T09:57:04.416601-08:00 Personal-LXDE kernel: [ 18.916402] piix4_smbus 0000:00:07.3: Host SMBus controller not enabled! 2014-02-17T08:03:54.921691-08:00 Personal-LXDE kernel: [ 20.534156] piix4_smbus 0000:00:07.3: Host SMBus controller not enabled! Although I'm seeing this in VMware, I have little reason to believe this is a far more extensive problem, probably applies to all 13.1 whether running a Desktop or not, and probably applies to many more if not all virtualization technologies. Why this problem may be under reported - The stdout error if even piped to stdout is hidden by the Plymouth splash screen - I've found the error is onerous in "minimal server mode" because it's obvious how the disk pauses for up to a minute on every boot looking for the missing SMBus hardware. On other systems like LXDE it's unknown how long the wait is, because it's hidden. On IceWM, the wait is only about 10 seconds. This <may> be an underlying problem for anyone who complains of a long boot time, especially if it's not clarified the User is booting a virtual machine Guest. It will not show up as identifieable in systemd-analyze. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=862163 http://bugzilla.novell.com/show_bug.cgi?id=862163#c5 Takashi Iwai changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tiwai@suse.com, | |tonysu@su-networking.com Flags| |needinfo?(tonysu@su-network | |ing.com) --- Comment #5 from Takashi Iwai --- Is this still an issue with more recent versions of openSUSE and VMware? Basically it's an issue of VMware itself. The vmware package should have a blacklist for avoiding this. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=862163 http://bugzilla.novell.com/show_bug.cgi?id=862163#c7 Tony Su changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|NORESPONSE |--- --- Comment #7 from Tony Su --- (In reply to Jiri Slaby from comment #6)

Closing due to lack of response.

Well, This is error still exists. After many more VMware Guests, I can now verify this error exists in all VMware guests, no matter the distro (ie Fedora, Ubuntu, ChromeOS) without regard to any distro version. Should this really be a VMware issue or something Linux in general should address and should openSUSE take steps to implement this blacklist if it's not done upstream? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=862163 http://bugzilla.novell.com/show_bug.cgi?id=862163#c9 --- Comment #9 from Tony Su --- (In reply to Takashi Iwai from comment #8)

It's a VMware problem, the TSC is unstable on VM. Look at their explanation:

http://kb.vmware.com/selfservice/microsites/search. do?language=en_US&cmd=displayKC&externalId=1004384

The workaround mentioned in the above should be applicable to openSUSE, too.

That's an interesting KB article I never found, I wonder how recent it is (VMware should date their publications). A close read suggests the problem might be only obvious in a VMware Guest, it could also be a latent issue in all deployments, even physical (if I'm reading the articles right). Maybe the person who discovered this issue (Jordan Russell) should be contacted to better understand the scope of the issue. Unfortunately, the link in the KB is slightly incorrect, but even after locating him in the forum thread his email is blocked. Googling, I see one possible hit. I am contacting to see if he is the person. In any case, if this looks like a significant issue to be fixed, it looks like the older acpi_pm option is already now available in the current stable 13.2 kernel (3.16.7-21) so although might be configurable "later" with a sysconfig, it should probably be implemented in grub as the KB article describes. To date, I have only observed seconds... sometimes many seconds delay but never the 2 hrs described in the KB article. -- You are receiving this mail because: You are on the CC list for the bug.