HI Dmirty,

I would have no idea of where to get that information from today.   That code 
was written over 12 years ago.  I sure there was an errata back then but where 
to find something that old would be a problem.  Also, since the drivers that 
are in FreeBSD today and in Linux do not have reports of this happening it make 
sense that this is a QNX only issue.  I'd take a look at the FreeBSD driver to 
see how different it is from the one you are using.  Since QNX has never been 
on our supported OS list we have never tested it ourselves.  So we have no idea 
if other QNX users are seeing this or not, especially since it on such old HW.

Sorry I can't be more help.  Try to debug code that 12 or more years old when 
it's not our driver is very problematic for us.

Cheers,
John

> -----Original Message-----
> From: Желобанов Дмитрий Владимирович
> [mailto:zheloba...@prosoftsystems.ru]
> Sent: Tuesday, September 15, 2015 10:20 PM
> To: Ronciak, John; Fujinaka, Todd; e1000-devel@lists.sourceforge.net
> Subject: RE: Intel 82551IL chips
> 
> I want to give a small addition: even the chip is EOL, but we have a big
> number of embedded devices with the chip on board. All devices installed in
> the field and, unfortunately,  we do must support the devices!
> 
> -----Original Message-----
> From: Желобанов Дмитрий Владимирович
> Sent: Wednesday, September 16, 2015 10:08 AM
> To: 'Ronciak, John'; Fujinaka, Todd; e1000-devel@lists.sourceforge.net
> Subject: RE: Intel 82551IL chips
> 
> Hello,
> 
> Of course I wouldn't copy-paste Linux driver into QNX. As a matter of fact,
> we have the source code for QNX, it names devnp-speedo.
> I just want to fix the QNX driver by inspiration of the Linux driver. By the 
> way,
> the QNX network kernel is a port of the FreeBSD kernel.
> 
> The device is visible on PCI bus when the driver doesn't receive packets.
> Let me give you more details on the issue:
> When the driver stops receiving: the "RX packet counter" is about 200, and
> we have the message in the slog: <timeout  sending 20, stat 80> I looked in
> the source code and found lines which issues the message:
> #define SCB_STATUS            0x00            /* Command Unit Status */
> #define SCB_BYTE2 2
> 
>       int     iobase = speedo->iobase + SCB_STATUS + SCB_BYTE2;
>       int     timeout;
> 
>       /*
>        * wait for the previous command to finish
>        */
>       if (SPEEDO_IN8(iobase) != 0x00) {
>               for(timeout = 1000000; timeout && (SPEEDO_IN8(iobase));
> timeout--)
>                       nsec_delay(1000);
>               if (!timeout) {
>                       log(LOG_ERR,
>                           "timeout sending %x, stat %x", bcmd,
> SPEEDO_IN8(iobase));
>                       return -1;
>               }
>       }
> 
> I do want to know what the comment from the Linux driver means:
>        * Based on comments in the source code for the FreeBSD fxp
>        * driver, the FIRMWARE_D102E ucode includes both CPUSaver and
>        *
>        *    "fixes for bugs in the B-step hardware (specifically, bugs
>        *     with Inline Receive)."
>        *
>        * So we must fail if it cannot be loaded.
> 
> It seems as it is our case, because PCI enumeration gives:
> Class          = Network (Ethernet)
> Vendor ID      = 8086h, Intel Corporation
> Device ID      = 1209h,  8255xER/82551IT Fast Ethernet Controller
> PCI index      = 1h
> Class Codes    = 020000h
> Revision ID    = 10h
> 
> Could you give me a document which describes the statement "fixes for bugs
> in the B-step hardware (specifically, bugs with Inline Receive)."?
> 
> Dmitry Zhelobanov
> Prosoft-Systems, Russia, Ekaterinburg
> 
> 
> 
> -----Original Message-----
> From: Ronciak, John [mailto:john.ronc...@intel.com]
> Sent: Tuesday, September 15, 2015 10:40 PM
> To: Fujinaka, Todd; Желобанов Дмитрий Владимирович; e1000-
> de...@lists.sourceforge.net
> Subject: RE: Intel 82551IL chips
> 
> As long as there is no copy and pasting from the Linux driver to the QNX
> driver it should not be a problem.  I'm not a lawyer but that's generally the
> case.  That said, since the driver works after another a second reboot it's
> probably not related to the driver.  This is probably something that is 
> related
> to the system during the PCI enumeration of devices.  Are all the other
> devices seen on a cold boot?  Is there an equivalent to 'lspci' in QNX?  If so
> what's it show on the first boot from power-off?  Are all the devices seen at
> that point or are some missing?
> 
> Cheers,
> John
> 
> > -----Original Message-----
> > From: Fujinaka, Todd [mailto:todd.fujin...@intel.com]
> > Sent: Tuesday, September 15, 2015 9:43 AM
> > To: zheloba...@prosoftsystems.ru; e1000-devel@lists.sourceforge.net
> > Subject: Re: [E1000-devel] Intel 82551IL chips
> >
> > The 82551L has been EOLed for about nine years by my estimation. We
> > don't have any further support for it.
> >
> > Also, it is probably a violation of the GPL to start with the Linux
> > driver to work on the QNX driver. I would suggest trying the FreeBSD driver.
> >
> > Todd Fujinaka
> > Software Application Engineer
> > Networking Division (ND)
> > Intel Corporation
> > todd.fujin...@intel.com
> > (503) 712-4565
> >
> > -----Original Message-----
> > From: Желобанов Дмитрий Владимирович
> > [mailto:zheloba...@prosoftsystems.ru]
> > Sent: Tuesday, September 15, 2015 5:15 AM
> > To: e1000-devel@lists.sourceforge.net
> > Subject: [E1000-devel] Intel 82551IL chips
> >
> > Hello,
> >
> > We use chips 82551IL (did 0x1209 rev 0x10) in our embedded platforms.
> > Our devices run QNX operation system. We faced with an issue:
> > sometimes our devices don't receive Ethernet packets right after boot
> > at all, only reboot helps to revive the devices. We think the root
> > problem is in hardware- software communication with the Ethernet
> > controller, or rather in QNX Ethernet driver.
> > I looked in Linux driver (e100.c) and found, the driver uploads
> > special firmware in chips like ours.
> >
> > So, could you give us a document which clarifies changes in
> > d102e_ucode.bin firmware from the original on chip microcode?
> >
> > Желобанов Д.В.
> > ООО <Прософт-Системы>, г. Екатеринбург.
> >
> >
> > ----------------------------------------------------------------------
> > -------- _______________________________________________
> > E1000-devel mailing list
> > E1000-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/e1000-devel
> > To learn more about Intel&#174; Ethernet, visit
> > http://communities.intel.com/community/wired

------------------------------------------------------------------------------
Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel&#174; Ethernet, visit 
http://communities.intel.com/community/wired
  • [E1000-devel] I... Желобанов Дмитрий Владимирович
    • Re: [E1000... Fujinaka, Todd
      • Re: [E... Ronciak, John
        • Re... Желобанов Дмитрий Владимирович
        • Re... Желобанов Дмитрий Владимирович
          • ... Ronciak, John

Reply via email to