<div dir="ltr"><div><div><div>There is one situation that svccfg changes are not turning off fast reboot.   If the system has a panic the next boot will have an automated reboot that gets hung.  <br><br></div>I'm assuming this is the crash dump being collected then a reboot initiated. <br><br></div>Anyone know how to fix this one or how to collect better information on where the fast reboot is coming from?<br><br></div>-Chip<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 12, 2014 at 5:24 AM, Stephan Budach <span dir="ltr"><<a href="mailto:stephan.budach@jvm.de" target="_blank">stephan.budach@jvm.de</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am 12.12.14 um 08:58 schrieb Jim Klimov:<div><div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
12 декабря 2014 г. 8:35:18 CET, Jim Klimov <<a href="mailto:jimklimov@cos.ru" target="_blank">jimklimov@cos.ru</a>> пишет:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
11 декабря 2014 г. 23:41:35 CET, Rune Tipsmark <<a href="mailto:rt@steait.net" target="_blank">rt@steait.net</a>> пишет:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
NIC's are not shared with IPMI.<br>
<br>
<br>
<br>
I will try the target-mode first, however on the 3rd box I actually<br>
have Infiniband and it also caused the same issue without touching the<br>
target-mode for FC.<br>
<br>
<br>
<br>
I have a 4th system on an old HP server and it reboots perfect every<br>
time, no target-mode and has Infiniband as well... I am leaning<br>
</blockquote>
towards<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
something with the SuperMicro hardware but can't really pinpoint it.<br>
<br>
br,<br>
<br>
Rune<br>
<br>
______________________________<u></u>__<br>
From: Dan McDonald <<a href="mailto:danmcd@omniti.com" target="_blank">danmcd@omniti.com</a>><br>
Sent: Thursday, December 11, 2014 11:39 PM<br>
To: Rune Tipsmark<br>
Cc: <a href="mailto:omnios-discuss@lists.omniti.com" target="_blank">omnios-discuss@lists.omniti.<u></u>com</a><br>
Subject: Re: [OmniOS-discuss] hangs on reboot<br>
<br>
Nothing printed out on the console?<br>
<br>
And try eliminating the target mode first - just in case.<br>
<br>
Also, is one of your NICs a dual IPMI/host NIC?  If so, disable the<br>
IPMI portion, we don't cope with shared NIC ports like that.<br>
<br>
Dan<br>
<br>
Sent from my iPhone (typos, autocorrect, and all)<br>
<br>
On Dec 11, 2014, at 5:25 PM, Rune Tipsmark<br>
<<a href="mailto:rt@steait.net" target="_blank">rt@steait.net</a><mailto:<a href="mailto:rt@steait.net" target="_blank">rt@<u></u>steait.net</a>>> wrote:<br>
<br>
<br>
hi all,<br>
<br>
<br>
<br>
I got a bunch (3) installations of omnios on SuperMicro hardware and<br>
all 3 have issues rebooting. They simply hang and never ever reboot.<br>
<br>
<br>
<br>
The install is latest version and I only added the storage-server<br>
package and installed napp-it and changed the fibre channel setting in<br>
/kernel/drv/emlxs.conf target-mode=1<br>
<br>
<br>
<br>
two nics igb0 and igb1 configured as aggregation (aggr0)<br>
<br>
<br>
<br>
besides this its 100% default install, not 10 minutes old...<br>
<br>
<br>
<br>
Any ideas?<br>
<br>
br,<br>
<br>
Rune<br>
<br>
______________________________<u></u>_________________<br>
OmniOS-discuss mailing list<br>
<a href="mailto:OmniOS-discuss@lists.omniti.com" target="_blank">OmniOS-discuss@lists.omniti.<u></u>com</a><mailto:<a href="mailto:OmniOS-discuss@lists.omniti.com" target="_blank">OmniOS-discuss@<u></u>lists.omniti.com</a>><br>
<a href="http://lists.omniti.com/mailman/listinfo/omnios-discuss" target="_blank">http://lists.omniti.com/<u></u>mailman/listinfo/omnios-<u></u>discuss</a><br>
<br>
<br>
------------------------------<u></u>------------------------------<u></u>------------<br>
<br>
______________________________<u></u>_________________<br>
OmniOS-discuss mailing list<br>
<a href="mailto:OmniOS-discuss@lists.omniti.com" target="_blank">OmniOS-discuss@lists.omniti.<u></u>com</a><br>
<a href="http://lists.omniti.com/mailman/listinfo/omnios-discuss" target="_blank">http://lists.omniti.com/<u></u>mailman/listinfo/omnios-<u></u>discuss</a><br>
</blockquote>
I've installed latest bloody on an HP Z400 workstation last week with<br>
an lsi 9212 addon hba, and it too needed to disable fastboot.<br>
<br>
IIRC this is somehow tied to ability of all drivers to quiesce like for<br>
standby - if some one refuses to, suspend or fastboot fail.<br>
IMHO the fastboot handler should have a reasonable/configurable timeout<br>
after 'stand by for reboot' to do slowboot if that expires.<br>
<br>
Alternately on servers you can set up bmc-watchdog and have the mobo<br>
reboot itself. But then use long timeouts (10-15 min) and/or take care<br>
that the watchdog driver is among the first pieces of software that<br>
runs in your bootup or especially 'live' repair-boots.<br>
<br>
HTH,<br>
Jim<br>
--<br>
Typos courtesy of K-9 Mail on my Samsung Android<br>
</blockquote>
Forgot to add my 2c: if the driver quiesce is at fault, maybe it is also a signal for devs to improve at least nominal hw support for new usb3, video chips, maybe some sata HBAs?<br>
Even if they don't perform optimally (i.e. let usb3 be as slow as usb2 or usb1, or let radeon be a vesa-video, but let it work without errors) -- they should not impede system work either.<br>
<br>
Jim<br>
--<br>
</blockquote></div></div>
I have recently bought a new SuperMicro which showed exactly the same behaviour regarding fast reboots. Rebooting through the prom however, worked each time I can remember trying it. That system had been originally installed using the release 006 of OmniOS. After upgrading to 012 stable, these issues seem to have gone. The only thing that is different on the new host is, that it's equipped with a SSD DOM instead of a "traditional" HD,. This DOM is stuffed in SATA0 and somewhat cabled to the MB, so it's not just a dumb one. This cable seems to be a bit picky about its connection of the plug that goes into the DOM.<br>
<br>
As for 012… I just performed 4 fast reboots in a row without issues on my new SuperMicro box…<br>
<br>
Cheers,<br>
budy<div class="HOEnZb"><div class="h5"><br>
______________________________<u></u>_________________<br>
OmniOS-discuss mailing list<br>
<a href="mailto:OmniOS-discuss@lists.omniti.com" target="_blank">OmniOS-discuss@lists.omniti.<u></u>com</a><br>
<a href="http://lists.omniti.com/mailman/listinfo/omnios-discuss" target="_blank">http://lists.omniti.com/<u></u>mailman/listinfo/omnios-<u></u>discuss</a><br>
</div></div></blockquote></div></div>