xen discuss - Feb 2008 - Re: achieving deterministic config with xVM (was: Dom0 issues: snv_79b and Tecra M9)

Matt Ingenthron wrote:
> This may be specific to my hardware, but I cannot get things to behave 
> reliably on my system.  For instance, I''ve had situations under
xVM dom0
> where snv81 can see the e1000g interface with dladm show-dev, but not 
> plumb it.  Then one boot later, I can''t see it with dladm, but can
plumb
> and up it with DHCP.
Are there any e1000g driver error / warning messages logged to
/var/adm/messages or the console, when the system has booted and
the e1000g device wasn''t recognized?

It might also be a good idea to install an e1000g driver compiled as
a "DEGUG" kernel modules,  so that all the E1000G_DEBUGLOG_x ()
macros in the driver source are compiled into the driver module,
and their output can be enabled by setting e1000g:e1000g_debug /
e1000g:e1000g_log_mode:
>From a comment in e1000g_debug.h:
 * Debug message control
 * Debug Levels:
 *      0x000 - (0)   no messages
 *      0x001 - (1)   Errors
 *      0x002 - (2)   Warnings
 *      0x004 - (4)   Information
 *      0x008 - (8)   Subroutine calls and control flow
 *      0x010 - (16)  I/O Data (verbose!)
 * Variables can be set with entries in the /etc/system file with
 *      "set e1000g:e1000g_debug=<value>"
 *      "set e1000g:e1000g_log_mode=<value>"
 * The /etc/system file is read only once at boot time, if you change
 * it you must reboot for the change to take effect.

> All of this of course wreaks havoc on NWAM.  This doesn''t bother
me so
> much, but I''d like to be able to use my network every time I boot.
:)
> 
> I get similar behavior when running straight on the hardware too. 
> I''ve generated a whole bevy of kmdb interrupt output. 
I''ve attached
> it.  It does seem that the HW has quite a bit of sharing going on.  How 
> does xVM handle that?
In both cases (shared / non-shared interrupt vectors) the hypervisor
gets called when one of the devices interrupts, and should pass the
interrupt to dom0 as an "event channel callback".  In dom0 all devices
sharing the same vector will have their interrupt handler called and
the device drivers should sort out if their hardware is responsible
for the interrupt or not.

But the e1000g device seems to have an unshared vector 24 on thet Tecra M9.

I''m not sure how the MSI feature for the e1000g hardware in that Tecra
M9
affects all of this.