WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] pvops netconsole

To: Brad Plant <bplant@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] pvops netconsole
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Mon, 15 Feb 2010 17:22:56 -0800
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 15 Feb 2010 17:23:22 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20100214155635.17d57bf7@daedalus>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20100205111507.4e7089fd@daedalus> <4B75DF98.3070307@xxxxxxxx> <20100214132820.4bfbd0d7@daedalus> <4B777483.80700@xxxxxxxx> <20100214155635.17d57bf7@daedalus>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.7) Gecko/20100120 Fedora/3.0.1-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.1
On 02/13/2010 08:56 PM, Brad Plant wrote:
Actually, I tried something like this first because I first looked at pcnet32.c 
and e100.c:

disable_irq(dev->irq);
xennet_interrupt(dev->irq, dev);
enable_irq(dev->irq);

The same WARN_ONCE() was triggered.

Given that netconsole works with e1000 (I presume; haven't tested it lately), I guess it needs a close look to see what differs from the netfront case.

3. Initially netconsole would not initialise because the interface didn't yet have a 
mac address as setup_netfront hadn't yet been called. I changed the module_init() in 
netconsole.c to late_initcall() if !CONFIG_MODULES&&   CONFIG_XEN. Is this 
allowed and sane?
Probably not.  In practice every kernel will have modules and Xen
enabled, and it will change netconsole for all users.  I guess we
probably need to find some way to init the MAC address earlier, or
trigger netconsole init once the mac address is known.
I figured it was dodgy. How would you init the MAC address earlier though? I've 
observed the xen devices being initialised at slightly different times with 
respect to other devices which suggests to me that they (and possibly all 
devices) are being initialised in separate threads. It would mean setting the 
MAC address before device initialisation yes?

Not sure how correct this is either, but another solution might be to set the 
MAC address to say 00:00:00:00:00:01 when the netdev structure is first 
created. This lets netconsole initialise since the MAC address isn't all zeros 
or all 0xFF. By the time any net console logs are transmitted, setup_netfront 
will have already been called and the correct MAC address set so no packets 
will actually be sent with the above MAC address. I have attached a patch that 
does this.

That seems a bit sketchy.

netfront is like a lot of network devices; it needs to query some external source to find its own mac address. Mostly this means querying some eeprom over i2c or something, but in our case it means talking to xenstore to find the configured mac address. I think the problem here is that this happens asynchronously, rather than synchronously in the net device's init routine. One fix might be to synchronously wait for the mac address to be set before returning from the init function.

    J

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

<Prev in Thread] Current Thread [Next in Thread>