Re: [Qemu-devel] [PATCH] e1000: Delay flush queue when receive RCTL

[Jason Wang]

On 2019/3/25 下午1:56, yuchenlin via Qemu-devel wrote:
> On 2019-03-25 12:26, Jason Wang wrote:
> > On 2019/3/21 上午9:35, yuchenlin wrote:
> > > Ping?
> > >
> > > On 2019-03-13 14:56, address@hidden wrote:
> > > > From: yuchenlin <address@hidden>
> > > >
> > > > Due to too early RCT0 interrput, win10x32 may hang on booting.
> > > > This problem can be reproduced by doing power cycle on win10x32 guest.
> > > > In our environment, we have 10 win10x32 and stress power cycle.
> > > > The problem will happen about 20 rounds.
> > > >
> > > > Below shows some log with comment:
> > > >
> > > > The normal case:
> > > >
> > > > address@hidden:e1000x_rx_disabled Received packet dropped
> > > > because receive is disabled RCTL = 0
> > > > address@hidden:e1000x_rx_disabled Received packet dropped
> > > > because receive is disabled RCTL = 0
> > > > address@hidden:e1000x_rx_disabled Received packet dropped
> > > > because receive is disabled RCTL = 0
> > > > e1000: set_ics 0, ICR 0, IMR 0
> > > > e1000: set_ics 0, ICR 0, IMR 0
> > > > e1000: set_ics 0, ICR 0, IMR 0
> > > > e1000: RCTL: 0, mac_reg[RCTL] = 0x0
> > > > address@hidden:e1000x_rx_disabled Received packet dropped
> > > > because receive is disabled RCTL = 0
> > > > e1000: set_ics 0, ICR 0, IMR 0
> > > > e1000: ICR read: 0
> > > > e1000: set_ics 0, ICR 0, IMR 0
> > > > e1000: set_ics 0, ICR 0, IMR 0
> > > > e1000: RCTL: 0, mac_reg[RCTL] = 0x0
> > > > address@hidden:e1000x_rx_disabled Received packet dropped
> > > > because receive is disabled RCTL = 0
> > > > e1000: set_ics 0, ICR 0, IMR 0
> > > > e1000: ICR read: 0
> > > > e1000: set_ics 2, ICR 0, IMR 0
> > > > e1000: set_ics 2, ICR 2, IMR 0
> > > > e1000: RCTL: 0, mac_reg[RCTL] = 0x0
> > > > address@hidden:e1000x_rx_disabled Received packet dropped
> > > > because receive is disabled RCTL = 0
> > > > address@hidden:e1000x_rx_disabled Received packet dropped
> > > > because receive is disabled RCTL = 0
> > > > e1000: RCTL: 255, mac_reg[RCTL] = 0x40002 <- win10x32 says it can 
> > > > handle
> > > > RX now
> > > > e1000: set_ics 0, ICR 2, IMR 9d <- unmask interrupt
> > > > e1000: RCTL: 255, mac_reg[RCTL] = 0x48002
> > > > e1000: set_ics 80, ICR 2, IMR 9d <- interrupt and work!
> > > > ...
> > > >
> > > > The bad case:
> > > >
> > > > address@hidden:e1000x_rx_disabled Received packet dropped
> > > > because receive is disabled RCTL = 0
> > > > address@hidden:e1000x_rx_disabled Received packet dropped
> > > > because receive is disabled RCTL = 0
> > > > e1000: set_ics 0, ICR 0, IMR 0
> > > > e1000: set_ics 0, ICR 0, IMR 0
> > > > e1000: set_ics 0, ICR 0, IMR 0
> > > > e1000: RCTL: 0, mac_reg[RCTL] = 0x0
> > > > address@hidden:e1000x_rx_disabled Received packet dropped
> > > > because receive is disabled RCTL = 0
> > > > e1000: set_ics 0, ICR 0, IMR 0
> > > > e1000: ICR read: 0
> > > > e1000: set_ics 0, ICR 0, IMR 0
> > > > e1000: set_ics 0, ICR 0, IMR 0
> > > > e1000: RCTL: 0, mac_reg[RCTL] = 0x0
> > > > address@hidden:e1000x_rx_disabled Received packet dropped
> > > > because receive is disabled RCTL = 0
> > > > e1000: set_ics 0, ICR 0, IMR 0
> > > > e1000: ICR read: 0
> > > > e1000: set_ics 2, ICR 0, IMR 0
> > > > e1000: set_ics 2, ICR 2, IMR 0
> > > > e1000: RCTL: 0, mac_reg[RCTL] = 0x0
> > > > address@hidden:e1000x_rx_disabled Received packet dropped
> > > > because receive is disabled RCTL = 0
> > > > address@hidden:e1000x_rx_disabled Received packet dropped
> > > > because receive is disabled RCTL = 0
> > > > e1000: RCTL: 255, mac_reg[RCTL] = 0x40002 <- win10x32 says it can 
> > > > handle
> > > > RX now
> > > > e1000: set_ics 80, ICR 2, IMR 0 <- flush queue (caused by setting 
> > > > RCTL)
> > > > e1000: set_ics 0, ICR 82, IMR 9d <- unmask interrupt and because 
> > > > 0x82&0x9d
> > > > != 0 generate interrupt, hang on here...
> >
> >
> > Do you mean the interrupt handler is not ready in guest actually?
>
> From my observation, I think yes.
>
> > We used to have similar workarounds like autoneg timer, I wonder if we
> > can reuse that.
>
> IMO, we can't re-use the autoneg timer. The autoneg seems not always 
> be triggered.
>
> Thanks


Ok, I've queued this patch.

Thanks