Re: VxWorks 6.6 - Ethernet interface driver support


Hello Bill

Sorry for taking so long to respond!

The code, writing of registers, was added at the end of the
“geiMuxConnect” routine (after the muxDevStart() function call).

The effect of the writing to the registers RXCW and STATUS is outlined
below. The two node boards were equipped with one optical PMC card
each and each of the two interfaces was connected to the corresponding
interface of the other board/card (loop test).

This is not a "loop test." This is just connecting two targets
together back to back. I remember at some point asking you just what
it was that these two targets were connected to (i.e. what kind of
switch, if any), but you never told me. (Or if you did tell me, it was
long enough ago that I forgot.)

So I'm going to ask you this again, and I'm going to insist that you
answer this time:

- When you first posted, and you said you couldn't get a link in the
fiber optic ports, what were they plugged into? Did you just have two
targets connected back to back like you do now? Was the target
connected to a switch with fiber optic ports? If so, what kind of
switch?

The reason why the unit
numbering is not what you may expect is the fact that I force a
certain numbering scheme, so that the interfaces of the upper PMC card
always have the unit numbers 5 and 6 in order to avoid that the
numbering is different when no, one or two PMC cards are attached.

Okay, this is very cryptic. Exactly what the heck did you do to "force
a certain numbering scheme?" I submit to you that you should have held
off on doing anything strange like this until _AFTER_ you'd figured
out the problem with the GEI driver.

I checked on the content of the STATUS and RXCW registers, at three
different points in time:
1. Register content directly before the write done in the
“geiMuxConnect” routine
2. Register content directly after the write done in the
“geiMuxConnect” routine
3. Register content some seconds later (by calling a routine that
examines the content)



What can be seen is that the write to the STATUS register has no
effect and the write to the RXCW at most a temporary one since it also
changes between point 2 and point 3 in time (without me doing anything
in the mean time).

Okay, I'm going to say this again: both the GEI_STS and GEI_RXCW
registers are _read-only_. Writing to them _NEVER_ has any effect. You
only see their contents change because the underlying device status
has changed. If you don't believe me, wait until the link comes up and
then try writing a garbage value to the RXCW register manually from
the target shell, then read it back again. You'll see that nothing
happens.

The values within parentheses show the change in content after I have
removed the write to the STATUS and RXCW registers.

BOARD 1:

unitNumber=5

GEI_STS=dba4
GEI_RXCW=c000000

GEI_STS=dba4
GEI_RXCW=640001e0 (64000000)

GEI_STS=dba7
GEI_RXCW=c40041e0 (c40041e0)

unitNumber=6

GEI_STS=dba0
GEI_RXCW=c000000

GEI_STS=dba0
GEI_RXCW=640001e0 (64000000)

GEI_STS=dba3
GEI_RXCW=c40041e0 (c40041e0)

BOARD 2:

unitNumber=5

GEI_STS=dba4
GEI_RXCW=c000000

GEI_STS=dba4
GEI_RXCW=74000000 (640001e0)

GEI_STS=dba7
GEI_RXCW=c40041e0 (c40041e0)

unitNumber=6

GEI_STS=dba0
GEI_RXCW=c000000

GEI_STS=dba0
GEI_RXCW=74000000 (640001e0)

GEI_STS=dba3
GEI_RXCW=c40041e0 (c40041e0)

It would appear from the output here that you set the unit numbers
backwards. Bit 3 in the status register is the function ID code. This
bit is used to tell the difference between different ports on a dual
port card. It should be cleared for port 0 and set for port 1. (This
is mainly used to set the MAC address: there is only one EEPROM, which
is shared between both ports, so both ports end up reading the same
station address from the EEPROM, and the one with function ID 1 flips
the last bit so that the address on the second port will be different
from the first.)

But it looks like port 0 and port 1 per card translate to unit 6 and
unit 5, instead of unit 5 and unit 6. Again, I want to know just what
the heck you did to achieve this.

Consequently, the writing to the STATUS and RXCW registers was
dropped. However, the writing to the CTRL register is still necessary
since alone the change to the routine “geiTbiPhyInit” that you
proposed doesn’t bring the link to an operating state (seems to have
no effect).

That's the main thing I wanted to know. I still don't understand why
enabling flow control here made a difference.

Something else I noted is that the change I earlier did to the file
“geiTbiPy.c”, always flagging for status active in the routine
“geiTbiPhyModeGet”, is no longer needed for bringing the interfaces
into the RUNNING state (indicated by “ifconfig”).

That's because it wasn't actually needed in the first place: you did
it early on to force the link to appear up, but once you poked the
CTRL register to actually establish the link, this change became
redundant.

Please note that the strange behavior "unplugging a cable effecting
also other interfaces" still remains.

I still don't fully understant the strange behavior. I'm starting to
suspect it has to do with this hitherto unmentioned unit number
forcing.

If you would be so kind, please describe for me a complete test setup
where you experience this problem. And I mean describe all of it, from
start to finish: explain how you connect up the hardware. Explain how
you configure the VxWorks image that you load. Explain what test you
run. If you want to be really nice, show the console output where you
run the tests. (It makes it easier for me to attempt the same thing.)

Also, you might want to experiment with forcing the flow control
enable bits in the control register on at a different point within the
code. Doing it in the geiMuxConnect() routine is suboptimal, since
it's only evern called once. I would try doing it somewhere in the
geiEndStart() routine instead.

-Bill

Many thanks for your support so far and best regards

Ulrik

.

Relevant Pages

  • Re: Benchmarker
    ... > What I was thinking of is to have each contesting routine to ... > register itself with the following information: ... It can be registered by one line in the initialization section. ...
    (borland.public.delphi.language.basm)
  • Re: [RFC][PATCH 1/3] PM: Introduce new top level suspend and hibernation callbacks
    ... will want a simple way to know when it is illegal for them to register ... the routine won't try to register new children improperly is to have ... the routine check a flag which gets set _before_ prepareis called. ... Drivers could have their own flag set ...
    (Linux-Kernel)
  • Re: Patch to add support for SGIs IOC4 chipset
    ... > In order to do this you must modify sgiioc4_clearirqslightly, ... routine is not used, since the ide_ack_intr macro will not call it. ... Is that register read supposed to clear ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: Native Code vs PCode OT
    ... > Directive Parameter order Clean-up Passes parameters in registers? ... > register Left-to-right Routine Yes ... _pascal is not the default calling convention for most Pascal compilers. ...
    (microsoft.public.vb.general.discussion)
  • Re: Via VT 6410 Raid Controller
    ... Using 1 I/O APICs Using ACPI for SMP configuration information Allocating PCI resources starting at 20000000 Built 1 zonelists mapped APIC to ffffd000 ... Allocate Port Service ... USB Universal Host Controller Interface driver v2.2 ... IFWLOG: register target usbcore: registered new driver usblp drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver parport: PnPBIOS parport detected. ...
    (Linux-Kernel)
Loading