search for: hangcheck

I am testing ORACLE RAC 9.2.0.8 and document say "hangcheck-timer-XXX" should include in Redhat Advance server. When I installed CENTOS 4.5, I installed "everything". I can NOT find 'hangcheck-timer" RPM in my system. can Anyone tell me where is "hangcheck-timer" RPM or where can I download it? Thanks. ____________...

...that you are aware of? Example /etc/rc.local script: #!/bin/sh # # This script will be executed *after* all the other init scripts. # You can put your own initialization stuff in here if you don't # want to do the full Sys V style init stuff. touch /var/lock/subsys/local modprobe hangcheck-timer hangcheck_tick=1 hangcheck_margin=10 hangcheck_reboot=1 mount -t ocfs2 -o datavolume,nointr,_netdev,noatime /dev/mapper/mpath0 /u02 mount -t ocfs2 -o datavolume,nointr,_netdev /dev/mapper/mpath1 /u03 Thanks! -Reid Reid McKinley *********************************************...

Hi, I am trying to install Oracle 9i RAC on SLES 8 SP3 with a shared firewire disk. I am using the following OCFS: OCFS Release 1.0.11-1 for suse sp3 2.4.21-138 smp kernel ocfs-2.4.21-138-smp-1.0.11-1.i586.rpm ocfs-tools-1.0.10-1.i386.rpm ocfs-support-1.0.10-1.i386.rpm 1/ I have configured OCFS and a shared file system /opt/oracle/oradata 2/ I have created a raw device for use as quorum

Am 15.05.2014 03:06, schrieb Maarten Lankhorst: > op 14-05-14 17:29, Christian K?nig schreef: >>> + /* did fence get signaled after we enabled the sw irq? */ >>> + if >>> (atomic64_read(&fence->rdev->fence_drv[fence->ring].last_seq) >= >>> fence->seq) { >>> + radeon_irq_kms_sw_irq_put(fence->rdev, fence->ring);

Hi developers, I met some domU issues and the log suggests missing interrupt. Details from here: http://www.gossamer-threads.com/lists/xen/users/263938#263938 In summary, this is the suspicious log: (XEN) vmsi.c:122:d32767 Unsupported delivery mode 3 I''ve checked the code in question and found that mode 3 is an ''reserved_1'' mode. I want to trace down the source of this

...gt;>>>>> The way you designed the interface now means that the driver >>>>>> never gets a chance to wait for the hardware to become idle and >>>>>> so never has the opportunity to the reset the whole thing. >>>>> You could set up a hangcheck timer like intel does, and end up >>>>> with a reliable hangcheck detection that doesn't depend on cpu >>>>> waits. :-) Or override the default wait function and restore the >>>>> old behavior. >>>> >>>> Overriding the defa...

...if necessary. >>>> >>>> The way you designed the interface now means that the driver never >>>> gets a chance to wait for the hardware to become idle and so never >>>> has the opportunity to the reset the whole thing. >>> You could set up a hangcheck timer like intel does, and end up with >>> a reliable hangcheck detection that doesn't depend on cpu waits. :-) >>> Or override the default wait function and restore the old behavior. >> >> Overriding the default wait function sounds better, please implement &gt...

...n then also initiate the reset handling if necessary. >> >> The way you designed the interface now means that the driver never >> gets a chance to wait for the hardware to become idle and so never >> has the opportunity to the reset the whole thing. > You could set up a hangcheck timer like intel does, and end up with a > reliable hangcheck detection that doesn't depend on cpu waits. :-) Or > override the default wait function and restore the old behavior. Overriding the default wait function sounds better, please implement it this way. Thanks, Christian. &g...

...The way you designed the interface now means that the driver >>>>>>>> never gets a chance to wait for the hardware to become idle and >>>>>>>> so never has the opportunity to the reset the whole thing. >>>>>>> You could set up a hangcheck timer like intel does, and end up >>>>>>> with a reliable hangcheck detection that doesn't depend on cpu >>>>>>> waits. :-) Or override the default wait function and restore the >>>>>>> old behavior. >>>>>> >...

...me signaled with a timeout and can then also initiate the reset handling if necessary. > > The way you designed the interface now means that the driver never gets a chance to wait for the hardware to become idle and so never has the opportunity to the reset the whole thing. You could set up a hangcheck timer like intel does, and end up with a reliable hangcheck detection that doesn't depend on cpu waits. :-) Or override the default wait function and restore the old behavior. ~Maarten

...iate the reset handling if necessary. >>>>> >>>>> The way you designed the interface now means that the driver never gets a chance to wait for the hardware to become idle and so never has the opportunity to the reset the whole thing. >>>> You could set up a hangcheck timer like intel does, and end up with a reliable hangcheck detection that doesn't depend on cpu waits. :-) Or override the default wait function and restore the old behavior. >>> >>> Overriding the default wait function sounds better, please implement it this way. >>&gt...

...if necessary. >>>>>>> >>>>>>> The way you designed the interface now means that the driver never gets a chance to wait for the hardware to become idle and so never has the opportunity to the reset the whole thing. >>>>>> You could set up a hangcheck timer like intel does, and end up with a reliable hangcheck detection that doesn't depend on cpu waits. :-) Or override the default wait function and restore the old behavior. >>>>> >>>>> Overriding the default wait function sounds better, please implement it this...

...t;>>>>>> >>>>>>>>> The way you designed the interface now means that the driver never gets a chance to wait for the hardware to become idle and so never has the opportunity to the reset the whole thing. >>>>>>>> You could set up a hangcheck timer like intel does, and end up with a reliable hangcheck detection that doesn't depend on cpu waits. :-) Or override the default wait function and restore the old behavior. >>>>>>> >>>>>>> Overriding the default wait function sounds better, please im...

...t and can then also initiate the reset handling if necessary. >>> >>> The way you designed the interface now means that the driver never gets a chance to wait for the hardware to become idle and so never has the opportunity to the reset the whole thing. >> You could set up a hangcheck timer like intel does, and end up with a reliable hangcheck detection that doesn't depend on cpu waits. :-) Or override the default wait function and restore the old behavior. > > Overriding the default wait function sounds better, please implement it this way. > > Thanks, > Chri...

...read registry value for WatchdogTimerMargin, tid = main:182895169120 file = unixinc.c, line = 1077 {Mon May 4 05:34:38 2009 } >TRACE: Can't read registry value for WatchdogSafetyMargin, tid = main:182895169120 file = unixinc.c, line = 1077 {Mon May 4 05:34:38 2009 } KernelModuleName is hangcheck-timer {Mon May 4 05:34:38 2009 } >TRACE: Can't read registry value for ClientTimeout, tid = main:182895169120 file = unixinc.c, line = 1077 {Mon May 4 05:34:38 2009 } >TRACE: InitNMInfo: setting clientTimeout to 143s based on MissCount 215 and PollInterval 1000ms, tid = main:1828...

...$ORACLE_HOME/oracm/admin/cmcfg.ora for both the nodes. cat cmcfg.ora ClusterName=Oracle Cluster Manager, version 9i MissCount=620 PrivateNodeNames=sunny1prv sunny2prv PublicNodeNames=sunny1pub sunny2pub ServicePort=9998 CmDiskFile=/u01/oradata/orcl/cmquorumfile HostName=sunny1pub KernelModuleName=hangcheck-timer I started cluster manager on node1 with the value of HostName=sunny1pub Now to start the cluster manager on node2, the value of HostName should be sunny2pub. What do i do now? Any help is greatly appreciated. Thanks in advance.

I''ve seen a recent report claiming that it works: http://linux-bsd-sharing.blogspot.pt/2012/10/howto-xen-413-windows-8-hvm-domu-with.html However, in my case, with a slightly different HW configuration the story is totally different. :-（ My config: HW: I7-3770 + AsRock H77M-ITX board Dom0: Debian Wheezy stock xen (v4.1.3) + Debian stock kernel (3.2.x / 3.6.x) 64 bit version. Note that

more messages in the other node of the cluster.../var/log/messages. ======== Jun 1 19:05:59 linux2 kernel: cdrom: open failed. Jun 1 19:05:59 linux2 kernel: cdrom: open failed. Jun 1 19:09:35 linux2 kernel: OCFS2 Node Manager 0.99.10-BETA14 Tue May 31 23:34:42 EDT 2005 (build 82257c19fee200eff2ba31569613b46a) Jun 1 19:09:35 linux2 kernel: OCFS2 DLM 0.99.10-BETA14 Tue May 31 23:34:43 EDT 2005

more messages in the other node of the cluster.../var/log/messages. ======== Jun 1 19:05:59 linux2 kernel: cdrom: open failed. Jun 1 19:05:59 linux2 kernel: cdrom: open failed. Jun 1 19:09:35 linux2 kernel: OCFS2 Node Manager 0.99.10-BETA14 Tue May 31 23:34:42 EDT 2005 (build 82257c19fee200eff2ba31569613b46a) Jun 1 19:09:35 linux2 kernel: OCFS2 DLM 0.99.10-BETA14 Tue May 31 23:34:43 EDT 2005

...limits > that depend on real partner hardware to be certified > are documented on the Red Hat website at > http://www.redhat.com/en_us/USA/rhel/details/limits/ > * IA64 multi-core support > * Driver updates including > cciss, hangcheck-timer, ipmi_devintf, ipmi_msghandler, > ipmi_poweroff, ipmi_si, ipmi_watchdog, mptbase, e1000, ixgb, > tg3, aacraid, ahci, ata_piix, iscsi_sfnet, libata, qla2100, > qla2200, qla2300, qla2322, qla2xxx, qla6312, sata_nv, > sata_promise, sata_svw, sata_sx4,...