It was observed that Windows 2003 x64 hangs when shutting down if an
RTL8139 NIC and a USB device tablet are both present. What seems to be
happening is:
- the guest shuts down the transmitter and receiver
- time passes
- the guest requests a tally counter dump
As it happens, the tally counter command register overlaps the transmit
status register in C mode. Qemu determines whether the chip is in C or C+
mode by looking at the C+ transmit enable bit; as this is now unset, the
dump tally counter command is interpreted as a C mode transmit command. The
guest doesn't think so, however, and continues to poll for completion of the
tally counter dump command. This never occurs, so the guest hangs.
Fix by redefining C+ mode as "a write to the C+ command register has occurred
since the last reset". The data sheet is silent on the matter.
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6279 c046a42c-6fe2-441c-8c8c-71466251a162
Allow the user to supply a vlan client name on the command line.
This is probably only useful for management tools so that they can
use their own names rather than parsing the output of 'info network'.
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6220 c046a42c-6fe2-441c-8c8c-71466251a162
Factor out a simple little function for formatting a NIC's
info_str and make all NICs use it.
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6218 c046a42c-6fe2-441c-8c8c-71466251a162
Don't lose track of what type/model a vlan client is so that we can
e.g. assign a global per-model id to clients.
The entire patch is basically a tedious excercise in making sure the
type/model string gets propagated down to qemu_new_vlan_client().
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6216 c046a42c-6fe2-441c-8c8c-71466251a162
On big endian targets with mmio accesses, the values are not always
swapped, depending on the accessed register. The Linux 8139too module
was able to cope with that, but not the 8139cp one.
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@4045 c046a42c-6fe2-441c-8c8c-71466251a162
