[Qemu-devel] [Bug 581737] Re: Can't read e1000 NIC EEPROM on NetBSD guest

[Qemu-devel] [Bug 581737] Re: Can't read e1000 NIC EEPROM on NetBSD guest

[Ryan Harper]

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

-- 
Can't read e1000 NIC EEPROM on NetBSD guest
https://bugs.launchpad.net/bugs/581737
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: Incomplete

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
        builds@b7.netbsd.org:/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.

[Qemu-devel] [Bug 581737] Re: Can't read e1000 NIC EEPROM on NetBSD guest

[Izumi Tsutsui]

** Patch added: "patch by git format-patch --signoff"
   http://launchpadlibrarian.net/49607393/qemu-git.patch

-- 
Can't read e1000 NIC EEPROM on NetBSD guest
https://bugs.launchpad.net/bugs/581737
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: Incomplete

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
        builds@b7.netbsd.org:/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.

[Qemu-devel] [Bug 581737] Re: Can't read e1000 NIC EEPROM on NetBSD guest

[Ryan Harper]

Please email the patch to qemu-devel@nongnu.org via git-send-email.
This will ensure the maintainers see the patch and the community has a
chance to review the patch.

-- 
Can't read e1000 NIC EEPROM on NetBSD guest
https://bugs.launchpad.net/bugs/581737
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: Incomplete

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
        builds@b7.netbsd.org:/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.

[Qemu-devel] [Bug 581737] Re: Can't read e1000 NIC EEPROM on NetBSD guest

[Izumi Tsutsui]

> Please email the patch to qemu-devel@nongnu.org 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)

-- 
Can't read e1000 NIC EEPROM on NetBSD guest
https://bugs.launchpad.net/bugs/581737
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: Incomplete

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
        builds@b7.netbsd.org:/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.

Re: [Qemu-devel] [Bug 581737] Re: Can't read e1000 NIC EEPROM on NetBSD guest

[Andreas Färber]

Am 13.06.2010 um 07:16 schrieb Izumi Tsutsui:

>> Please email the patch to qemu-devel@nongnu.org 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

Re: [Qemu-devel] [Bug 581737] Re: Can't read e1000 NIC EEPROM onNetBSD guest

[Izumi Tsutsui]

> >> Please email the patch to qemu-devel@nongnu.org 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

-- 
Can't read e1000 NIC EEPROM on NetBSD guest
https://bugs.launchpad.net/bugs/581737
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.

Status in QEMU: Incomplete

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
        builds@b7.netbsd.org:/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.

Re: [Qemu-devel] [Bug 581737] Re: Can't read e1000 NIC EEPROM onNetBSD guest

[Andreas Färber]

Am 13.06.2010 um 14:50 schrieb Izumi Tsutsui:

>>>> Please email the patch to qemu-devel@nongnu.org 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

[Qemu-devel] [PATCH] e1000: Fix wrong microwire EEPROM state initialization

[Izumi Tsutsui]

This change fixes initialization of e1000's microwire EEPROM internal
state values so that qemu's e1000 emulation works on NetBSD,
which doesn't use Intel's em driver but has its own wm driver
for the Intel i8254x Gigabit Ethernet.

Previously 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 (CS) signal is required to reset the internal
  state-machine to accept a new cycle .."
and nothing should be changed during CS (chip select) is inactive.

Intel's em driver seems to explicitly raise SK output after CS is negated
in em_standby_eeprom() so many other OSes that use Intel's driver
don't have this problem even on the previous e1000.c implementation,
but I can't find any articles that say the MICROWIRE or EEPROM spec
requires such sequence, and actually hardware works fine without it
(i.e. real i82540EM has been working on NetBSD).

This fix also changes initialization to clear each state value in
struct eecd_state individually rather than using memset() against
the whole structre. The old_eecd member stores the last SK and CS
signal levels and it should be preserved even after reset of internal
EEPROM state to detect next signal edges for proper EEPROM emulation.

Signed-off-by: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
---
 hw/e1000.c |   17 ++++++++---------
 1 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/hw/e1000.c b/hw/e1000.c
index 0da65f9..db9143d 100644
--- a/hw/e1000.c
+++ b/hw/e1000.c
@@ -262,21 +262,20 @@ set_eecd(E1000State *s, int index, uint32_t val)
 
     s->eecd_state.old_eecd = val & (E1000_EECD_SK | E1000_EECD_CS |
             E1000_EECD_DI|E1000_EECD_FWE_MASK|E1000_EECD_REQ);
+    if (!(E1000_EECD_CS & val))			// CS inactive; nothing to do
+	return;
+    if (E1000_EECD_CS & (val ^ oldval)) {	// CS rise edge; reset state
+	s->eecd_state.val_in = 0;
+	s->eecd_state.bitnum_in = 0;
+	s->eecd_state.bitnum_out = 0;
+	s->eecd_state.reading = 0;
+    }
     if (!(E1000_EECD_SK & (val ^ oldval)))	// no clock edge
         return;
     if (!(E1000_EECD_SK & val)) {		// falling edge
         s->eecd_state.bitnum_out++;
         return;
     }
-    if (!(val & E1000_EECD_CS)) {		// rising, no CS (EEPROM reset)
-        memset(&s->eecd_state, 0, sizeof s->eecd_state);
-        /*
-         * restore old_eecd's E1000_EECD_SK (known to be on)
-         * to avoid false detection of a clock edge
-         */
-        s->eecd_state.old_eecd = E1000_EECD_SK;
-        return;
-    }
     s->eecd_state.val_in <<= 1;
     if (val & E1000_EECD_DI)
         s->eecd_state.val_in |= 1;
-- 
1.6.6.2

Re: [Qemu-devel] [PATCH] e1000: Fix wrong microwire EEPROM state initialization

[Aurelien Jarno]

On Sat, Jul 10, 2010 at 11:03:45PM +0900, Izumi Tsutsui wrote:
> This change fixes initialization of e1000's microwire EEPROM internal
> state values so that qemu's e1000 emulation works on NetBSD,
> which doesn't use Intel's em driver but has its own wm driver
> for the Intel i8254x Gigabit Ethernet.
> 
> Previously 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 (CS) signal is required to reset the internal
>   state-machine to accept a new cycle .."
> and nothing should be changed during CS (chip select) is inactive.
> 
> Intel's em driver seems to explicitly raise SK output after CS is negated
> in em_standby_eeprom() so many other OSes that use Intel's driver
> don't have this problem even on the previous e1000.c implementation,
> but I can't find any articles that say the MICROWIRE or EEPROM spec
> requires such sequence, and actually hardware works fine without it
> (i.e. real i82540EM has been working on NetBSD).
> 
> This fix also changes initialization to clear each state value in
> struct eecd_state individually rather than using memset() against
> the whole structre. The old_eecd member stores the last SK and CS
> signal levels and it should be preserved even after reset of internal
> EEPROM state to detect next signal edges for proper EEPROM emulation.
> 
> Signed-off-by: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
> ---
>  hw/e1000.c |   17 ++++++++---------
>  1 files changed, 8 insertions(+), 9 deletions(-)

Thanks, applied.

> diff --git a/hw/e1000.c b/hw/e1000.c
> index 0da65f9..db9143d 100644
> --- a/hw/e1000.c
> +++ b/hw/e1000.c
> @@ -262,21 +262,20 @@ set_eecd(E1000State *s, int index, uint32_t val)
>  
>      s->eecd_state.old_eecd = val & (E1000_EECD_SK | E1000_EECD_CS |
>              E1000_EECD_DI|E1000_EECD_FWE_MASK|E1000_EECD_REQ);
> +    if (!(E1000_EECD_CS & val))			// CS inactive; nothing to do
> +	return;
> +    if (E1000_EECD_CS & (val ^ oldval)) {	// CS rise edge; reset state
> +	s->eecd_state.val_in = 0;
> +	s->eecd_state.bitnum_in = 0;
> +	s->eecd_state.bitnum_out = 0;
> +	s->eecd_state.reading = 0;
> +    }
>      if (!(E1000_EECD_SK & (val ^ oldval)))	// no clock edge
>          return;
>      if (!(E1000_EECD_SK & val)) {		// falling edge
>          s->eecd_state.bitnum_out++;
>          return;
>      }
> -    if (!(val & E1000_EECD_CS)) {		// rising, no CS (EEPROM reset)
> -        memset(&s->eecd_state, 0, sizeof s->eecd_state);
> -        /*
> -         * restore old_eecd's E1000_EECD_SK (known to be on)
> -         * to avoid false detection of a clock edge
> -         */
> -        s->eecd_state.old_eecd = E1000_EECD_SK;
> -        return;
> -    }
>      s->eecd_state.val_in <<= 1;
>      if (val & E1000_EECD_DI)
>          s->eecd_state.val_in |= 1;
> -- 
> 1.6.6.2
> 
> 
> 

-- 
Aurelien Jarno                          GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

Re: [Qemu-devel] [Bug 581737] Re: Can't read e1000 NIC EEPROM on NetBSD guest

[Jonathan A. Kollasch]

On Sun, Jun 13, 2010 at 02:21:21PM +0200, Andreas Färber wrote:
> Am 13.06.2010 um 07:16 schrieb Izumi Tsutsui:
> 
> >>Please email the patch to qemu-devel@nongnu.org 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.
> 

Can you imagine how frustrating this is to someone who's just trying
to get a simple bug fix fed upstream?

I find it quite unreasonable that one should be forced through
this many hoops just to get a trivial patch even considered.

	Jonathan Kollasch

Re: [Qemu-devel] [Bug 581737] Re: Can't read e1000 NIC EEPROM on NetBSD guest

[Andreas Färber]

Am 13.06.2010 um 15:10 schrieb Jonathan A. Kollasch:

> On Sun, Jun 13, 2010 at 02:21:21PM +0200, Andreas Färber wrote:
>> Am 13.06.2010 um 07:16 schrieb Izumi Tsutsui:
>>
>>>> Please email the patch to qemu-devel@nongnu.org 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.
>
> Can you imagine how frustrating this is to someone who's just trying
> to get a simple bug fix fed upstream?

Yes. Can you imagine what it's like having 3480 unread qemu-devel  
messages and an estimated average of 50 patches per day?

> I find it quite unreasonable that one should be forced through
> this many hoops just to get a trivial patch even considered.

I've been through those hoops myself. I learned Git for this project  
and am now voluntarily using it for at least three other projects,  
too. It's definitely a good time investment!

In this particular case the reporter apparently went through the hoop  
of *deleting* regular git-format-patch output before uploading it and  
did not even leave a one-line summary.

I didn't make the rules though, and if Anthony or someone wants to  
spend the time of refining such bug patches themselves that's fine  
with me. Ryan and I were just trying to help.

Andreas

[Qemu-devel] [Bug 581737] Re: Can't read e1000 NIC EEPROM on NetBSD guest

[Aurelien Jarno]

** Changed in: qemu
       Status: Incomplete => Fix Committed

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/581737

Title:
  Can't read e1000 NIC EEPROM on NetBSD guest

Status in QEMU:
  Fix Committed

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
          builds@b7.netbsd.org:/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.

[Qemu-devel] [Bug 581737] Re: Can't read e1000 NIC EEPROM on NetBSD guest

[Aurelien Jarno]

** Changed in: qemu
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/581737

Title:
  Can't read e1000 NIC EEPROM on NetBSD guest

Status in QEMU:
  Fix Released

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
          builds@b7.netbsd.org:/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.