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-devel@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