Can't read e1000 NIC EEPROM on NetBSD guest

Bug #581737 reported by Izumi Tsutsui
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
QEMU
Fix Released
Undecided
Unassigned

Bug Description

QEMU Version: qemu-0.12.4
Host OS: NetBSD/i386 5.0.2
Guest OS: NetBSD/i386 5.1_RC1

On this environment, guest NetBSD tries to attach e1000 NIC using its own wm(4) driver but fails to read EEPROM as the following:
---
NetBSD 5.1_RC1 (GENERIC) #0: Sat Apr 24 23:26:09 UTC 2010
        <email address hidden>:/home/builds/ab/netbsd-5-1-RC1/i386/201004250032Z-obj/home/builds/ab/
netbsd-5-1-RC1/src/sys/arch/i386/compile/GENERIC
total memory = 127 MB
avail memory = 113 MB
Bochs Bochs
 :
drm at vga1 not configured
wm0 at pci0 dev 3 function 0: Intel i82540EM 1000BASE-T Ethernet, rev. 3
wm0: interrupting at irq 11
wm0: unable to read Ethernet address
isa0 at pcib0
 :
---

You can reproduce this with NetBSD/i386 install CD image:
 ftp://ftp.NetBSD.org/pub/NetBSD/NetBSD-5.1_RC1/iso/i386cd-5.1_RC1.iso
 % qemu -cdrom i386cd-5.1_RC1.iso -boot d
 ---in QEMU window---
 [type ^C to quit installer]
 # dmesg | grep wm0
------

Per DBGOUT(EEPROM) messages, it show too large eecd_state.bitnum values, i.e. EEPROM state is not reset properly.
The set_eecd() function in e1000.c clears EEPROM internal state values on SK rising edge during CS==L.
But according to FM93C06 EEPROM (which is MicroWire compatible) data sheet,
EEPROM internal status should be cleared on CS rise edge regardless of SK input:
 "... a rising edge on this signal is required to reset the internal state-machine to accept a new cycle .."

Intel's em driver seems to explicitly raise and lower SK output after CS is negated in em_standby_eeprom()
so many other OSes that use Intel's driver don't have this problem with current e1000.c implementation,
but I can't find articles that say the MICROWIRE or EEPROM spec requires such sequence.

With the attached patch, NetBSD guest properly gets MAC address from e1000 NIC EEPROM.

Revision history for this message
Izumi Tsutsui (tsutsui) wrote :
Revision history for this message
Ryan Harper (raharper) wrote :

I applied this patch against qemu.git and it does indeed fix the issue for netbsd referenced in the bug. Please submit this patch against upstream qemu.git and include a Signed-off-by: in the patch.

Changed in qemu:
status: New → Incomplete
Revision history for this message
Izumi Tsutsui (tsutsui) wrote :
Revision history for this message
Ryan Harper (raharper) wrote :

Please email the patch to <email address hidden> via git-send-email. This will ensure the maintainers see the patch and the community has a chance to review the patch.

Revision history for this message
Izumi Tsutsui (tsutsui) wrote :

> Please email the patch to <email address hidden> via git-send-email.
Isn't the following post enough? What's incomplete on this?
http://lists.nongnu.org/archive/html/qemu-devel/2010-06/msg00449.html
(sorry I'm not familiar with git)

Revision history for this message
Andreas Färber (afaerber) wrote : Re: [Qemu-devel] [Bug 581737] Re: Can't read e1000 NIC EEPROM on NetBSD guest

Am 13.06.2010 um 07:16 schrieb Izumi Tsutsui:

>> Please email the patch to <email address hidden> via git-send-email.
> Isn't the following post enough? What's incomplete on this?
> http://lists.nongnu.org/archive/html/qemu-devel/2010-06/msg00449.html

That is still not a proper git-format-patch patch, it is missing among
others the From: and Subject: lines and, likely, a more detailled
description of what it does and why, for maintainers to be able to
apply it with the git-am tool.

But first it needs to be reviewed and ack'ed by people knowing that
part of the code, and such review is done by inline patches on qemu-
devel mailing list, not by HTTP links to bugtrackers (there are simply
too many patches). The git-send-email tool assures that the format is
not damaged by your favorite mail agent.

Hope that explains,

Andreas

Revision history for this message
Izumi Tsutsui (tsutsui) wrote : Re: [Qemu-devel] [Bug 581737] Re: Can't read e1000 NIC EEPROM onNetBSD guest

> >> Please email the patch to <email address hidden> via git-send-email.
> > Isn't the following post enough? What's incomplete on this?
> > http://lists.nongnu.org/archive/html/qemu-devel/2010-06/msg00449.html
>
> That is still not a proper git-format-patch patch, it is missing among
> others the From: and Subject: lines and, likely, a more detailled
> description of what it does and why, for maintainers to be able to
> apply it with the git-am tool.

Whole description is in the bug report itself.
git-format-patch is strictly required even in such case?
If so, is there any proper documents how to submit patches for QEMU?
---
Izumi Tsutsui

Revision history for this message
Andreas Färber (afaerber) wrote :

Am 13.06.2010 um 14:50 schrieb Izumi Tsutsui:

>>>> Please email the patch to <email address hidden> via git-send-email.
>>> Isn't the following post enough? What's incomplete on this?
>>> http://lists.nongnu.org/archive/html/qemu-devel/2010-06/
>>> msg00449.html
>>
>> That is still not a proper git-format-patch patch, it is missing
>> among
>> others the From: and Subject: lines and, likely, a more detailled
>> description of what it does and why, for maintainers to be able to
>> apply it with the git-am tool.
>
> Whole description is in the bug report itself.
> git-format-patch is strictly required even in such case?

A self-contained description is required for the commit in the
(distributed) Git repository.

http://www.spheredev.org/wiki/Git_for_the_lazy#Writing_good_commit_messages
http://git.qemu.org/qemu.git/log/

> If so, is there any proper documents how to submit patches for QEMU?

http://wiki.qemu.org/Contribute/StartHere
http://git.qemu.org/qemu.git/plain/CODING_STYLE
http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html#_patch_workflow

It's not too QEMU-specific, so any Git tutorial should do.

HTH,
Andreas

Aurelien Jarno (aurel32)
Changed in qemu:
status: Incomplete → Fix Committed
Aurelien Jarno (aurel32)
Changed in qemu:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.