<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Panic in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/panic/m-p/3566267#M227397</link>
    <description>Hi Isaac&lt;BR /&gt;&lt;BR /&gt;In a multiprocessor system, spinlocks are used to protect a critical code path&lt;BR /&gt;or critical data structures from multiple CPU access.  The implementation is&lt;BR /&gt;that way, that the processor trying to acquire the lock will busy wait until it&lt;BR /&gt;is able to get the spinlock.  The reason to chose this implementation, is&lt;BR /&gt;due to the assumption that the lock is only held for very short time periods&lt;BR /&gt;and that a complete context switch of a CPU in contrast to busy waiting would&lt;BR /&gt;be much more time and resource consuming.  As long as the lock is held by the&lt;BR /&gt;CPU, no other CPU will be able to access that critical part.  As soon as the&lt;BR /&gt;CPU is done, with for example, updating a structure, the lock has to be&lt;BR /&gt;released.  As a precaution, the other CPU's waiting for the access to the&lt;BR /&gt;spinlock, record how long they already waited. If the wait time exceeds 60&lt;BR /&gt;seconds, the system will be paniced with a "spinlock deadlock panic".&lt;BR /&gt;&lt;BR /&gt;This locking scheme is no more or less than a software convention.  The&lt;BR /&gt;programmer has to take care of properly coding to lock and unlock the right&lt;BR /&gt;spinlock(s).  A possible and more or less frequently met problem is, that a&lt;BR /&gt;driver has a seldom called exit path where a spinlock is not unlocked.  Another&lt;BR /&gt;CPU waiting for access to this specific lock will wait until the 60 seconds&lt;BR /&gt;have passed and then panic the system.&lt;BR /&gt;&lt;BR /&gt;regards&lt;BR /&gt;&lt;BR /&gt;Vinod&lt;BR /&gt;</description>
    <pubDate>Sat, 18 Jun 2005 00:04:48 GMT</pubDate>
    <dc:creator>vinod_25</dc:creator>
    <dc:date>2005-06-18T00:04:48Z</dc:date>
    <item>
      <title>Panic</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/panic/m-p/3566264#M227394</link>
      <description>Hi:&lt;BR /&gt;&lt;BR /&gt;I get a messages in /etc/shutdownlog&lt;BR /&gt;&lt;BR /&gt;20:14 Sat Jun 11 2005. Reboot after panic: Spinlock deadlock! &lt;BR /&gt;&lt;BR /&gt;Some one know, about that?&lt;BR /&gt;&lt;BR /&gt;Than You !!!!</description>
      <pubDate>Fri, 17 Jun 2005 17:43:48 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/panic/m-p/3566264#M227394</guid>
      <dc:creator>Isaac_4</dc:creator>
      <dc:date>2005-06-17T17:43:48Z</dc:date>
    </item>
    <item>
      <title>Re: Panic</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/panic/m-p/3566265#M227395</link>
      <description>I remember this one from a long time ago. This panic is observed on the multi cpu machines. Spinlock is a requirement when OS activities are spread out over multi processors. Some tasks require all kernel activity on all processors to be suspended until this particular task gets completed on the first processor (a.k.a. Monarch). This spinlock is required because the task running has impact on other running kernel processes. Without spinlock, you may end up with an out of sync kernel operation, which may be equally fatal.&lt;BR /&gt;&lt;BR /&gt;As you can see, if the spinlock does not get released, the system will hang waiting for this task to complete without letting anything else to run. Hence there is some sort of timer, somewhere, set to wait for the spinlock even to end in a given period of time. If it soe not, this panic happens and the system crashes.&lt;BR /&gt;&lt;BR /&gt;It was suggested by HP at the time that crash dump to be sent to HP for analysis of the case to determine what caused the spinlock deadlock and subsequently the panic, exactly.&lt;BR /&gt;&lt;BR /&gt;You will see tons of patches in the patch database talking about spinlocks. My advice to you will be, to apply the latest and greatest QPK patch bundle that you can get your hands on to as well as the hardware enablement patches as a start. &lt;BR /&gt;&lt;BR /&gt;Hope this helps and good luck... needless to say I do not envy you right now.&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Fri, 17 Jun 2005 18:00:49 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/panic/m-p/3566265#M227395</guid>
      <dc:creator>Mel Burslan</dc:creator>
      <dc:date>2005-06-17T18:00:49Z</dc:date>
    </item>
    <item>
      <title>Re: Panic</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/panic/m-p/3566266#M227396</link>
      <description>the good old "spinlock deadlock"..&lt;BR /&gt;&lt;BR /&gt;think of four cpu's on you system..&lt;BR /&gt;&lt;BR /&gt;one cpu is the boss, yea, he gives the orders for the other children cpus. call him the master cpu.&lt;BR /&gt;&lt;BR /&gt;if the master cpu is too-busy to give order to the other children-cpus, then nothing can get done..&lt;BR /&gt;&lt;BR /&gt;if the master or monarch-cpu is Spinning, then all work assignments STOP!&lt;BR /&gt;&lt;BR /&gt;so, you just might have an issue with your hardware.. maybe one of your CPU processors is going bad..&lt;BR /&gt;&lt;BR /&gt;if you on the other hand, are JAVA process intensive, then this could be a reason for the SPINing of the CPUs.. JAVA tends to SPIN the CPU's waiting for an EVENT or CONDITION to wake-up..&lt;BR /&gt;&lt;BR /&gt;call HP support, you need some patches on your box, or you need some new CPU (or if a superdome, you need a new CELL board.).&lt;BR /&gt;&lt;BR /&gt;best of luck,&lt;BR /&gt;Tom</description>
      <pubDate>Fri, 17 Jun 2005 23:47:48 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/panic/m-p/3566266#M227396</guid>
      <dc:creator>D Block 2</dc:creator>
      <dc:date>2005-06-17T23:47:48Z</dc:date>
    </item>
    <item>
      <title>Re: Panic</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/panic/m-p/3566267#M227397</link>
      <description>Hi Isaac&lt;BR /&gt;&lt;BR /&gt;In a multiprocessor system, spinlocks are used to protect a critical code path&lt;BR /&gt;or critical data structures from multiple CPU access.  The implementation is&lt;BR /&gt;that way, that the processor trying to acquire the lock will busy wait until it&lt;BR /&gt;is able to get the spinlock.  The reason to chose this implementation, is&lt;BR /&gt;due to the assumption that the lock is only held for very short time periods&lt;BR /&gt;and that a complete context switch of a CPU in contrast to busy waiting would&lt;BR /&gt;be much more time and resource consuming.  As long as the lock is held by the&lt;BR /&gt;CPU, no other CPU will be able to access that critical part.  As soon as the&lt;BR /&gt;CPU is done, with for example, updating a structure, the lock has to be&lt;BR /&gt;released.  As a precaution, the other CPU's waiting for the access to the&lt;BR /&gt;spinlock, record how long they already waited. If the wait time exceeds 60&lt;BR /&gt;seconds, the system will be paniced with a "spinlock deadlock panic".&lt;BR /&gt;&lt;BR /&gt;This locking scheme is no more or less than a software convention.  The&lt;BR /&gt;programmer has to take care of properly coding to lock and unlock the right&lt;BR /&gt;spinlock(s).  A possible and more or less frequently met problem is, that a&lt;BR /&gt;driver has a seldom called exit path where a spinlock is not unlocked.  Another&lt;BR /&gt;CPU waiting for access to this specific lock will wait until the 60 seconds&lt;BR /&gt;have passed and then panic the system.&lt;BR /&gt;&lt;BR /&gt;regards&lt;BR /&gt;&lt;BR /&gt;Vinod&lt;BR /&gt;</description>
      <pubDate>Sat, 18 Jun 2005 00:04:48 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/panic/m-p/3566267#M227397</guid>
      <dc:creator>vinod_25</dc:creator>
      <dc:date>2005-06-18T00:04:48Z</dc:date>
    </item>
    <item>
      <title>Re: Panic</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/panic/m-p/3566268#M227398</link>
      <description>hi,&lt;BR /&gt;&lt;BR /&gt;something u should know about unexpected reboot from this doc:&lt;BR /&gt;&lt;BR /&gt;&lt;A href="http://www1.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&amp;amp;docId=200000070978149" target="_blank"&gt;http://www1.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&amp;amp;docId=200000070978149&lt;/A&gt;&lt;BR /&gt;&lt;BR /&gt;regards.</description>
      <pubDate>Sat, 18 Jun 2005 00:24:53 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/panic/m-p/3566268#M227398</guid>
      <dc:creator>Joseph Loo</dc:creator>
      <dc:date>2005-06-18T00:24:53Z</dc:date>
    </item>
    <item>
      <title>Re: Panic</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/panic/m-p/3566269#M227399</link>
      <description>Many thing can produce a spinlock deadlock, software, hardware. It needs a crash dump&lt;BR /&gt;analysis to find the root cause&lt;BR /&gt;The best is to open a ticket at HP support, &lt;BR /&gt;and send the crashdump you will find at /var/adm/crash/crash.?  you'll have the answer.&lt;BR /&gt;&lt;BR /&gt;There are mainly 2 cases where we identify a spinlock deadlock:&lt;BR /&gt;1) we have a priority inversion between 2 spinlocks. 2 cpu (or more) are requesting for the same couple of spinlock but not in the same order&lt;BR /&gt;2) hardware failure&lt;BR /&gt;&lt;BR /&gt;Most of the cases are from 1)&lt;BR /&gt; &lt;BR /&gt;</description>
      <pubDate>Sat, 18 Jun 2005 01:40:00 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/panic/m-p/3566269#M227399</guid>
      <dc:creator>Laurent Menase</dc:creator>
      <dc:date>2005-06-18T01:40:00Z</dc:date>
    </item>
  </channel>
</rss>

