RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 812809 - It will keep generating dump files when use ib700 and action is dump
Summary: It will keep generating dump files when use ib700 and action is dump
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm
Version: 6.3
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: rc
: ---
Assignee: Richard W.M. Jones
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On: 1099514
Blocks: 1050977
TreeView+ depends on / blocked
 
Reported: 2012-04-16 09:59 UTC by Luwen Su
Modified: 2019-03-27 06:44 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1050977 (view as bug list)
Environment:
Last Closed: 2016-06-27 17:07:50 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Luwen Su 2012-04-16 09:59:43 UTC 
Description
When attach watchdog and use ib700 with action is dump , it will keep generating dump file.
I don't know if it normal and this situation never happen in ib6300


Version
libvirt-0.9.10-11.el6.x86_64
qemu-kvm-0.12.1.2-2.267.el6.x86_64
kernel-2.6.32-257.el6.x86_64
watchdog-5.5-10.el6

How reproducible:
100%

Steps to Reproduce

Have a guest first


1. Edit the config file /etc/libvirt/qemu.conf and uncomment the following line:

auto_dump_path = "/var/lib/libvirt/qemu/dump"


2. Add a watchdog device through edit the guest's XML file, and start the guest.

<watchdog model='ib700' action='dump'/>

3. In guest
   #modprobe ib700wdt

4. Setup wathcdog , you can find it in brewweb too.
 #yum install watchdog

5. In guest, adjust settings in /etc/watchdog.conf:
interval        = 100
watchdog-device = /dev/watchdog
** should be larger than 60.

6. In guest, start watchdog process.
# watchdog -f

7. Wait for some minutes, check the status of guest and if there's a dump file for the guest.
   In host ,
   #ll /var/lib/libvirt/qemu/dump


8. Both in ib700 and ib6300 ,
   a.the ps always exist watchdog -f
   b.after generate the dump file , the guest is running.
   c.6300 will generate the dump file only once , but ib700 will keep do it until kill the process.

Actual results:
The dump file will be kept generating.

Expected results:
The dump file will be generated only once.

Additional info:
I'm not sure if it should belong to component libvirt , so please help me change it if you know where it should be.Thanks
Comment 2 Osier Yang 2012-04-24 07:28:18 UTC 
>    a.the ps always exist watchdog -f
>    b.after generate the dump file , the guest is running.
>    c.6300 will generate the dump file only once , but ib700 will keep do it
> until kill the process.

Hi, time.

Can you see what the result with command below at the meantime of testing?

$ python /usr/share/doc/libvirt-python-0.9.10/events-python/event-test.py
Comment 3 Luwen Su 2012-04-25 09:21:09 UTC 
(In reply to comment #2)
> >    a.the ps always exist watchdog -f
> >    b.after generate the dump file , the guest is running.
> >    c.6300 will generate the dump file only once , but ib700 will keep do it
> > until kill the process.
> 
> Hi, time.
> 
> Can you see what the result with command below at the meantime of testing?
> 
> $ python /usr/share/doc/libvirt-python-0.9.10/events-python/event-test.py

Hi , Osier.

I tested again with
libvirt-0.9.10-14.el6.x86_64
qemu-kvm-0.12.1.2-2.277.el6.x86_64.

The problem still exist.When generated a dump file , 
event-test.py will show 
myDomainEventWatchdogCallback: Domain wat(19) 1
myDomainEventCallback1 EVENT: Domain wat(19) Suspended Watchdog
myDomainEventCallback2 EVENT: Domain wat(19) Suspended Watchdog

And the second file appeared after a little while.
Comment 4 Osier Yang 2012-04-25 13:18:49 UTC 
(In reply to comment #3)
> (In reply to comment #2)
> > >    a.the ps always exist watchdog -f
> > >    b.after generate the dump file , the guest is running.
> > >    c.6300 will generate the dump file only once , but ib700 will keep do it
> > > until kill the process.
> > 
> > Hi, time.
> > 
> > Can you see what the result with command below at the meantime of testing?
> > 
> > $ python /usr/share/doc/libvirt-python-0.9.10/events-python/event-test.py
> 
> Hi , Osier.
> 
> I tested again with
> libvirt-0.9.10-14.el6.x86_64
> qemu-kvm-0.12.1.2-2.277.el6.x86_64.
> 
> The problem still exist.When generated a dump file , 
> event-test.py will show 
> myDomainEventWatchdogCallback: Domain wat(19) 1
> myDomainEventCallback1 EVENT: Domain wat(19) Suspended Watchdog
> myDomainEventCallback2 EVENT: Domain wat(19) Suspended Watchdog
> 
> And the second file appeared after a little while.

I mean how many events of each "ib700" and "ib6300" event-test.py got?
Comment 5 Luwen Su 2012-04-26 07:19:34 UTC 
There is something that seems i not explained clear enough.
I'm sorry about it if so.

For ib6300

myDomainEventWatchdogCallback: Domain wat(20) 1
myDomainEventCallback1 EVENT: Domain wat(20) Suspended Watchdog
myDomainEventCallback2 EVENT: Domain wat(20) Suspended Watchdog

The events be catched once. Then the guest will be paused to stop action dump.After that  the guest started.
Guest ---> pause ---> start ---> not generated dump file and no events

For ib700

1.The events will be catched again and again Like below.So the dump action repeats again and again.

myDomainEventCallback1 EVENT: Domain wat(22) Suspended Watchdog
myDomainEventCallback2 EVENT: Domain wat(22) Suspended Watchdog
myDomainEventWatchdogCallback: Domain wat(22) 1
myDomainEventCallback1 EVENT: Domain wat(22) Suspended Watchdog
myDomainEventCallback2 EVENT: Domain wat(22) Suspended Watchdog
myDomainEventWatchdogCallback: Domain wat(22) 1
myDomainEventCallback1 EVENT: Domain wat(22) Suspended Watchdog
myDomainEventCallback2 EVENT: Domain wat(22) Suspended Watchdog
myDomainEventWatchdogCallback: Domain wat(22) 1
myDomainEventCallback1 EVENT: Domain wat(22) Suspended Watchdog
myDomainEventCallback2 EVENT: Domain wat(22) Suspended Watchdog
.........


2.The guest will pause once when first dump .

Guest ---> pause ---> start ---> keep generated dump file and events be catched like above
Comment 6 Osier Yang 2012-04-26 09:31:57 UTC 
So I reassgin it to qemu, as libvirt behaves right, for ib6300, it gets only one event and thus one coredump, for ib700, it gets many events and thus many coredumps.(In reply to comment #5)
> There is something that seems i not explained clear enough.
> I'm sorry about it if so.
> 
> For ib6300
> 
> myDomainEventWatchdogCallback: Domain wat(20) 1
> myDomainEventCallback1 EVENT: Domain wat(20) Suspended Watchdog
> myDomainEventCallback2 EVENT: Domain wat(20) Suspended Watchdog
> 
> The events be catched once. Then the guest will be paused to stop action
> dump.After that  the guest started.
> Guest ---> pause ---> start ---> not generated dump file and no events
> 
> For ib700
> 
> 1.The events will be catched again and again Like below.So the dump action
> repeats again and again.
> 
> myDomainEventCallback1 EVENT: Domain wat(22) Suspended Watchdog
> myDomainEventCallback2 EVENT: Domain wat(22) Suspended Watchdog
> myDomainEventWatchdogCallback: Domain wat(22) 1
> myDomainEventCallback1 EVENT: Domain wat(22) Suspended Watchdog
> myDomainEventCallback2 EVENT: Domain wat(22) Suspended Watchdog
> myDomainEventWatchdogCallback: Domain wat(22) 1
> myDomainEventCallback1 EVENT: Domain wat(22) Suspended Watchdog
> myDomainEventCallback2 EVENT: Domain wat(22) Suspended Watchdog
> myDomainEventWatchdogCallback: Domain wat(22) 1
> myDomainEventCallback1 EVENT: Domain wat(22) Suspended Watchdog
> myDomainEventCallback2 EVENT: Domain wat(22) Suspended Watchdog
> .........
> 
> 
> 2.The guest will pause once when first dump .
> 
> Guest ---> pause ---> start ---> keep generated dump file and events be catched
> like above

Thanks, @time, I believe it's not problem of libvirt (well, if it's problem finally) then, and thus reassign to qemu.
Comment 10 Richard W.M. Jones 2014-01-09 14:08:36 UTC 
I wrote a simple test program for the Linux watchdog.  It's
much easier to use than running the watchdog daemon (for
testing).

http://git.annexia.org/?p=watchdog-test-framework.git;a=tree
Comment 12 Richard W.M. Jones 2016-06-27 17:07:50 UTC 
I'm closing this as wontfix, although it is likely fixed in the
latest upstream qemu.
Note You need to log in before you can comment on or make changes to this bug.