Thank you Jesse,
> you also apparently are not using MSI interrupts.
No. I can see the kernel messages below in syslog.
In the kernel options, I found APIC related items and MSI are disabled.
kernel: e1000e: Intel(R) PRO/1000 Network Driver - 0.5.18.3
kernel: e1000e: Copyright(c) 1999 - 2009 Intel Corporation.
kernel: ACPI: PCI interrupt 0000:02:00.0[A] -> GSI 11 (level, low)-> IRQ 11
kernel: PCI: Setting latency timer of device 0000:02:00.0 to 64
kernel: 0000:02:00.0: : Failed to initialize MSI interrupts. Falling back
to legacy interrupts.
kernel: e1000e 0000:02:00.0: Warning: detected DSPD enabled in EEPROM
kernel: 0000:02:00.0: eth0: (PCI Express:2.5GB/s:Width x1) **:**:**:**:**:**
kernel: 0000:02:00.0: eth0: Intel(R) PRO/1000 Network Connection
kernel: 0000:02:00.0: eth0: MAC: 3, PHY: 2, PBA No: ffffff-0ff
> this was probably a shared interrupt, does /proc/interrupts show ethX
> sharing?
Yes, it is shared with uhci controller and the our board. (dsppci*).
CPU0
0: 4156373 XT-PIC timer 0/56373
1: 8 XT-PIC i8042 0/8
2: 0 XT-PIC cascade 0/0
4: 7 XT-PIC serial 0/7
5: 65122 XT-PIC HDA Intel, uhci_hcd, dsppci0 0/65122
7: 552750 XT-PIC ehci_hcd, uhci_hcd 0/52750
9: 0 XT-PIC acpi 0/0
10: 64995 XT-PIC dsppci1 0/64995
11: 192084 XT-PIC uhci_hcd, eth0, dsppci2 0/92084
14: 58499 XT-PIC ide0 0/58499
15: 794424 XT-PIC libata, uhci_hcd, dsppci3 0/94424
NMI: 0
ERR: 0
> If INT_ASSERTED was not set it was not our interrupt, but it
> is normal to
> have e1000_intr called in a shared interrupt case.
>
> We have fixed a bug in the latest release of e1000e, which is
> available
> now, look for e1000e-1.0.2.5
I understand as follows. Is it right understanding?
- Irq11 for eth0 is shared with uhci_hdc and dsppci2 because MSI is
unavailable.
- When the interrupt for either uhci_hdc or dsppci2 is asserted, we can see
e1000_intr() called with ICR.INT_ASSERTED=0b.
- If the other device's interrupt is asserted during e1000 down state,
e1000_intr()
and clean_rx/tx_irq functions are processed in an uncertain initialize
condition,
then sometimes it could destroy some buffers and variables.
- It is fixed in e1000e-1.0.2.5.
Thanks,
Hizume
> -----Original Message-----
> From: Brandeburg, Jesse [mailto:jesse.brandeb...@intel.com]
> Sent: Thursday, July 02, 2009 1:39 AM
> To: Yosuke HIZUME
> Cc: e1000-devel@lists.sourceforge.net
> Subject: Re: [E1000-devel] e1000e: Rx Descriptor FIFO Parity Error
>
> On Wed, 1 Jul 2009, Yosuke HIZUME wrote:
> > I'm using e1000e-0.5.8.13 *Non-NAPI* on kernel 2.6.10 with 82573L.
> > I found the receiving data was occasionally corrupted just after I
> > changed the mtu or the speed and duplex setting.
>
> you also apparently are not using MSI interrupts.
>
> > Then I inserted some printk codes to investigate and found that
> > e1000_intr() was infrequently called sometime in between
> the beginning of
> > e1000e_down() and the end of e1000e_up() despite the irq
> was disabled.
>
> this was probably a shared interrupt, does /proc/interrupts show ethX
> sharing?
>
> > In such case, the register ICR.INT_ASSERTED was not set and
> > ICR.RX_DESC_FIFO_Par0 was set. (ex. icr=0x00100000h)
>
> If INT_ASSERTED was not set it was not our interrupt, but it
> is normal to
> have e1000_intr called in a shared interrupt case.
>
> We have fixed a bug in the latest release of e1000e, which is
> available
> now, look for e1000e-1.0.2.5
>
> > I want to know the reason why the interrupt handler was called
> > nevertheless interrupt disabled, and also the reason why
> > RX_DESC_FIFO_Par0 was set.
>
> par0 was probably set as part of the reset process.
>
> > And hopefully, please let me know if there are any workarounds.
>
> yes, the e1000_intr routine can check to make sure it is not
> running when
> the __E1000_DOWN flag is set, you'll see that code in the new driver.
>
> Jesse
------------------------------------------------------------------------------
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
