http://bugzilla.opensuse.org/show_bug.cgi?id=919836 --- Comment #2 from Felix Miata --- Created attachment 624717 --> http://bugzilla.opensuse.org/attachment.cgi?id=624717&action=edit tgz of output from systemctl -k [-b -1|-b] (kernel-desktop|kernel-vanilla) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=919836 http://bugzilla.opensuse.org/show_bug.cgi?id=919836#c4 --- Comment #4 from Felix Miata --- Created attachment 648046 --> http://bugzilla.opensuse.org/attachment.cgi?id=648046&action=edit 32 bit 13.2 3.16.7-24 panic screen photograph I no longer believe this invalid. In June the comment 0 machine ceased to be able to POST. I gave its behavioral history some more thought yesterday, and "re-engineered" its P9657AB-8EKRS2H motherboard, replacing 3 of its 4 2200uF 16V voltage regulator capacitors that I had previously replaced with new electrical equivalents, using 3300uF 16V instead. I was then able to boot its 32 bit 13.1, 13.2 and TW installations as when I filed this, still needing nosmp on cmdline in 13.2's 3.16.7-7 and TW's 3.19.0 in order to be able to boot without panic. Then I did zypper up on all three installations. 13.2's 3.16.7-24 still needs nosmp to be able to boot without panic, but, like Kubecek's 13.1 3.12.44, TW's 4.1.6-3 produces no sign of any boot time errors that I can see. With a HD out of another machine in the comment 0 machine, I booted 64 bit 13.1 with 3.12.44, 13.2 with 3.16.7-24, and TW with 4.1.6-1. None of them required or require nosmp to boot without any apparent errors. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=919836 http://bugzilla.opensuse.org/show_bug.cgi?id=919836#c7 Felix Miata changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |WORKSFORME Flags|needinfo?(mrmazda@earthlink | |.net) | --- Comment #7 from Felix Miata --- When I filed this, I had just replaced a RAID1 320G HD pair, hosting 11.0, 11.2 and 11.4, with a 1T RAID1 pair hosting 13.1, 13.2 and TW. All the behaviors then described were with the new RAID. In recent months, the motherboard has been working OK without using nosmp, with a single HD and 64 bit kernels desktop-3.16.7-24 & 29 with a different HD and 13.2 installation. I had to loan out its 500G RAID1 pair for burn-in of the Haswell motherboard destined for this machine with the 1T RAID with which the problem arose. The 500G RAID1 pair was configured to be able to substitute for the 1T RAID1, with 13.1, 13.2 and TW. While in the temporary home of the Haswell, I replaced its TW installation with a 64 bit 13.2. Now that I've returned the 500G RAID to the problem motherboard, *and* done more zypper ups, this is continuing to be non-reproducible in 13.2 in either 32 bit or 64 bit. All that said, I still think there could be a bug, but one that's either BIOS-setting-related, or in the BIOS itself. I've had to spend a lot of time in BIOS setup in order to acquire stability. Simply setting BIOS to global failsafe isn't sufficient. The problem with tweaking BIOS is I never logged what I was doing, so can't be sure which BIOS setting(s) need to be non-default without disturbing the now comfortable dog. Selected current settings are: RAM fully manual 6-6-6-18 @ 800Mhz Sooth over clock disabled Intelligent stepping manual VCore over voltage +0.0125 RAM voltage +0.200 APIC enabled On-Chip serial ATA setting: SATA Mode JMB361 controller disabled Azalia/HD Audio enabled 1394 disabled Floppy controller enabled Serial port disabled IrDA port disabled Parallel port disabled All USB enabled except keyboard If I ever stumble onto which setting(s), and think the problem is in software rather than BIOS or hardware, then I can revisit this, but I'm not planning to spend more time changing BIOS settings before the new battery goes dead. Discovery probably won't happen, as I'm about to replace the 32 bit 13.2 with Leap, and the comment 0 motherboard will probably not be coupled with the comment 0 motherboard again anyway. So given the many OS updates and the parts & HD swapping and BIOS tweaking have masked or eliminated the trouble: -> worksforme -- You are receiving this mail because: You are on the CC list for the bug.