Embedded Intel Atom® Processors
Technological Conversations about Intel Atom® Hardware, Software, Firmware, Graphics
1210 Discussions

Ixgbe driver fails to reset on C3508 X553

TMiki1
Beginner
2,263 Views

I am using Intel C3508's built-in 10GbE LAN controller with "1GBASE-T (via Marvell 1543), 1 GbE SKU" (PCI device id 0x15e5), but it fails in rare cases with the probe of ixgbe driver of Linux.

 

Please tell us if you know the reason why this failure occurs.

 

The operating system is Linux-4.14.125, using the ixgbe driver of the kernel.

 

The function of the ixgbe driver that caused an error is ixgbe_reset_hw_X550em().

 

After performing a link reset by writing 1 to LRST bit (bit 3) of Device Control Register, it seems that LRST bit does not return to 0.

 

When I displayed the variable ctrl that read the value of Device Control Register when an error occurred, it was 0xdeadbeef.

 

Is there any way to prevent the device control register value from becoming 0xdeadbeef after reset?

Should I extend the sleep time after reset or read more device control registers?

0 Kudos
6 Replies
CarlosAM_INTEL
Moderator
1,964 Views

Hello, @TMiki1​:

 

Thank you for contacting Intel Embedded Community.

 

Could you please clarify if the affected project is your design or a third- party one?

 

In case that it is a third-party device, could you please inform the name of the manufacturer, its model, the part number, and where its documentation is stated?

 

On the other hand, could you please let us know how many units of the project related to this circumstance have been manufactured? How many are affected? Could you please give the failure rate? Also, could you please list the sources that you have used to design it and if it has been verified by Intel?

 

Could you please explain the procedure followed to obtain the cited driver?

 

We are waiting for your answer.

 

Best regards,

@Mæcenas_INTEL​.

 

 

0 Kudos
TMiki1
Beginner
1,964 Views

> Could you please clarify if the affected project is your design or a third- party one?

 

The carrier board is designed using third party COM Express.

> In case that it is a third-party device, could you please inform the name of the manufacturer, its model, the part number, and where its documentation is stated?

Use this product.

https://www.kontron.com/products/boards-and-standard-form-factors/com-express/com-express-basic/come-bdv7.html

 

> On the other hand, could you please let us know how many units of the project related to this circumstance have been manufactured? How many are affected? Could you please give the failure rate? Also, could you please list the sources that you have used to design it and if it has been verified by Intel?

It is unknown because the product has not yet been released.

I can't get a clear failure rate, but I think it's about 1/100.

I am a software engineer and do not understand hardware design.

 

> Could you please explain the procedure followed to obtain the cited driver?

 

It can be obtained from https://www.kernel.org/.

The git tag is v4.14.125

 

0 Kudos
CarlosAM_INTEL
Moderator
1,964 Views

Hello, @TMiki1​:

 

Thanks for your reply.

 

We suggest you as a reference address these type of consultations to the channels listed at the following website:

 

https://www.kernel.org/category/contact-us.html

 

Best regards,

@Mæcenas_INTEL​.

0 Kudos
Fq
Beginner
736 Views

Hello @TMiki1,

 

I'm facing the same issue as yours described in this discussion. I'm working with kernel linux-4.14.44 so driver ixgbe is very similar as the one you've used in your kernel linux-4.14.125 and sometimes LRST doesn't self-clear correctly and when ixgbe initialization fails it returns error code (-15) and the value of ixgbe CTRL is 0xdeadbeef as you shown before.

 

Can you share your kernel patch or modifications you've applied in order to solve this issue?

 

Best regards,

Francesco

0 Kudos
Fq
Beginner
685 Views

According to intel document #560805 [ c3000-sightingsreport ] there's an important note:

142.Software Driver Initialization May Fail During System Warm Reset
Cycles Using LEK4(SGMII Backplane) Topology
Problem:After several system warm reset cycles using LEK4 topology, LAN MAC may fail to
initialize resulting to driver initialization failure.
Implication:One or more ports may fail to establish link. The issue has only been observed on LEK4.
The issue cannot be observed on other LEK images.
Workaround: None identified.
Status:
Non-Si (Fixed in WW49 LEK4 official LEK release)

 

So updating LEK4 image to WW49 we can solve this issue.

0 Kudos
CarlosAM_INTEL
Moderator
659 Views

Hello, @Fq:

 

Thank you for contacting Intel Embedded Community.

 

We are glad that you found information that may help you.

 

In case you need it, the questions related to the cited driver should be addressed to the channel stated on the following website:

https://github.com/intel/ethernet-linux-ixgbe/issues

 

Best regards,

@CarlosAM_INTEL.

 

 

0 Kudos
Reply