Re: [Xen-devel] Debug event_channel.c

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

On Thu, 2011-09-29 at 13:36 +0100, Daniel Castro wrote:
> On Thu, Sep 29, 2011 at 8:30 PM, Ian Campbell
> <Ian.Campbell@xxxxxxxxxxxxx> wrote:
> > On Thu, 2011-09-29 at 12:09 +0100, Daniel Castro wrote:
> >> On Tue, Sep 27, 2011 at 9:09 PM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> 
> >> wrote:
> >> > On Tue, 2011-09-27 at 12:36 +0100, Daniel Castro wrote:
> >> >> On Tue, Sep 27, 2011 at 8:33 PM, Andrew Cooper
> >> >> <andrew.cooper3@xxxxxxxxxx> wrote:
> >> >> > On 27/09/11 12:09, Daniel Castro wrote:
> >> >> >> Hello All,
> >> >> >>
> >> >> >> I am trying to debug event_channel.c for this I have filled the
> >> >> >> functions with gdprintk(XENLOG_WARNING, "..."); yet the messages are
> >> >> >> not displayed on dmesg or /var/log/xen. Where could they be printed?
> >> >> >> or should I use a different function?
> >> >> >>
> >> >> >> In grub I have loglvl=all to print all messages...
> >> >> >>
> >> >> >> Thanks for the answer,
> >> >> >>
> >> >> >> Daniel
> >> >> >>
> >> >> >
> >> >> > gdprintk only gets set with guest debugging enabled. ( guest_loglvl on
> >> >> > the command line )
> >> >> >
> >> >> > My suggestion would be to just use regular printks and look at the
> >> >> > serial log.
> >> >>
> >> >> How can can I look at the serial log from dom0?
> >> >
> >> > 'xl dmesg' (or using a serial cable of course ;-))
> >> >
> >> > You can also add XENCONSOLED_TRACE=hv in /etc/sysconfig/xencommons (or
> >> > the equivalent on your distro, the effect should be to add --log=hv to
> >> > the xenconsoled command line). Then the xen console will be logged
> >> > under /var/log/xen somewhere.
> >>
> >> Ian, thanks for the info.
> >>
> >> This is the info I gathered:
> >> (XEN) schedule.c:658:d1 DEBUG 1: START DO POLL port -32060 on
> >> sched_poll.nr_ports 1
> >
> > port == -32060 doesn't sound right...
> >
> >> (XEN) schedule.c:719:d1 DEBUG 1: DO POLL test bit on port 2 exit here
> >> -> if ( test_bit(port, &shared_info(d, evtchn_pending)) )
> >> (XEN) schedule.c:746:d1 DEBUG 1: DO POLL GOTO out: check previus msg,
> >> return rc=0
> >> (XEN) event_channel.c:606:d1 DEBUG 1: set_pending
> >> (XEN) event_channel.c:628:d1 DEBUG 1 : evtchn_set_pending test_bit AND
> >> test_and_set_bit returned 0.
> >> (XEN) event_channel.c:637:d1 DEBUG 1: evtchn_set_pending bitmap_empty 
> >> return 0.
> >>
> >> In my code test_bit_and_clear in Xenstore ring_wait is in fact
> >> returning 0, it was expecting a one, the do_poll is finding the bit in
> >> 1 also according to test_bit, right?
> >> So the error is on the my test_bit_and_clear. Am I reading it correctly?
> >
> > I'm not sure I follow what your debug messages are actually saying, but
> > if do_poll is exiting because of the
> >        if ( test_bit(port, &shared_info(d, evtchn_pending)) )
> >            goto out;
> > inside the "for ( i = 0; i < sched_poll->nr_ports; i++ )" loop then this
> > indicates that the event channel is pending. If you aren't seeing this
> > on the guest end then there is likely a problem somewhere on that end.
> >
> > In your current ring_wait function you have:
> >        int wait = test_and_clear_bit(event, shinfo->evtchn_pending);
> >        int ret = 1;
> >        while (wait!=0 || ret!=0){
> >                ret = hypercall_sched_op(SCHEDOP_poll, &poll);
> >                wait = test_and_clear_bit(event, shinfo->evtchn_pending);
> >                struct vcpu_info *vcpu = shinfo->vcpu_info;
> >                dprintf(1,"DEBUG bit clear is %d and ret %d\n",wait,ret);
> >                time = shinfo->vcpu_info[0].time;
> >                dprintf(1,"TIME system %d timestamp 
> > %d\n",time.system_time,time.tsc_timestamp);
> >        }
> > }
> >
> > Isn't "wait!=0" backwards? Don't you want to succeed (i.e. fall out of
> > the loop) when wait!=0 rather than keep looping?
> 
> Yes, at some point I must have screwed that up, and later corrected
> it... Sorry... Yet the problem remains, in the ring wait I get
> stuck...
> 
> What else could I check?

Does shinfo actually point to the right thing?

Looking at your *get_shared_info(void) you have:
    xatp.gpfn  = malloc_high(sizeof(shared_info));
    shared_info = (struct shared_info *)(xatp.gpfn << PAGE_SHIFT);

but malloc_high returns a void * (i.e. a pointer) not an mfn.

I suspect you want:
    shared_info = malloc_high(sizeof(shared_info));
    xatp.gpfn  = ((unsigned long)shared_info >> PAGE_SHIFT);

At least here the compiler produces a clear warning about this issue:

        src/xen.c: In function âget_shared_infoâ:
        src/xen.c:157: warning: assignment makes integer from pointer without a 
cast

The code in your seabios tree currently produces nearly a page of
warnings. It is very good practice to get into the habit of taking care
of all warnings as soon as they appear, more often than not they
represent are real problem with the code. For example just from skimming
them I can see that a bunch of your debug is not printing what you seem
to think it is.

Ian.

> 
> >
> > Ian.
> >
> >>
> >> Thanks all,
> >>
> >> Daniel
> >> >
> >> > Ian.
> >> >
> >> >>
> >> >> >
> >> >> > --
> >> >> > Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
> >> >> > T: +44 (0)1223 225 900, http://www.citrix.com
> >> >> >
> >> >> >
> >> >> > _______________________________________________
> >> >> > Xen-devel mailing list
> >> >> > Xen-devel@xxxxxxxxxxxxxxxxxxx
> >> >> > http://lists.xensource.com/xen-devel
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >>
> >>
> >>
> >
> >
> >
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel