[vortex] Re: New driver - 0.99Q

[Donald Becker]

On Tue, 16 May 2000, Bogdan Costescu wrote:

> Subject: New driver - 0.99Q
>
> It would have been nice to have an announcement on this list (like there
> used to be) plus a detailed list of changes. I will do it this time.

It was already light out when I finished plugging boards in last night for
tests. (And I got a phone call at 10:00am :-(.)  I thought it best to wait
until I got a little sleep before writing text.

> 1. Polling mode added for capable cards (Cyclone/Tornado). This is done
...
> In vortex_timer, detect blocked interrupts. If true, check for polling
> mode (which should be true, except the first time vortex_timer is called)
> and then call vortex_interrupt and set the next timer call at jiffies+2;
> if not true (no blocked interrupt), call vortex_tx_timeout. In case of
> repeated blocked interrupt, vortex_interrupt is called every 2 jiffies.
> In boomerang_start_xmit, if ! IS_BOOMERANG and cur_tx == 0 (this happens
> only for the first queued packet) write the DPD to the card; it's only
> necessary to write the first DPD to the card in polling mode.
...
> My comments:
> 
> 1. - Why do we keep calling vortex_interrupt in case of physically blocked
> interrupts? It's the same case as in vortex_tx_timeout - we give the
> impression that the network is working (with lousy performance) when in
> fact it doesn't.
>    - How was the DownPollRate value chosen?

This is a fall-back to provide a minimal level operation when the interrupt
line is physcially blocked.  This allows remote debugging of isolated
machines.

Our clusters typically use SMP machines, and we keep getting burned by APIC
configuration bugs appearing as driver bugs.  When you don't have a video
card, it is very difficult guess what is going wrong.

It's also useful for detecting CardBus problems.  The most common problem is
a allocatable but non-working interrupt, or an interrupt that fails with
suspend-resume.

> 2. Default switched back to I/O based as opposed to mem-based access.
..
> 2. Why was the mode changed back to I/O based? Are there problems with
> mem-based access or just to be have the default mode compatible with EISA
> cards?

It's just to support the EISA cards.  You'll note that compiling to use
PCI memory mode (-DUSE_MEM_OPS) now disables the EISA scan.

Most of my PCI drivers now take either -DUSE_MEM_OPS or -DUSE_IO_OPS to
switch modes.  They default to the slightly faster PCI memory mode unless
there is a reason not to.

> 3. For Tornado cards, don't print "INVALID CHECKSUM".
> 3. Whouldn't be better computing the correct checksum for Tornado?

My same 3c905C card was a first-production version, and it has a checksum
("Hurricane-style") that matches the manual.  It appears that there are a
few other minor differences as well.
I picked up a new manual when I was in Santa Clara two weeks ago, so
hopefully I'll figure out the correct checksum calculation for each type.
The code will be added to vortex-diag.c before it goes into the driver.

> 4. Added HAS_NWAY for Tornado cards in pci_tbl.

________________

BTW, is anyone having problems with the new 'mailman' mailer, or the new
list host?  I know that this is much the same as asking "can you hear me in
the back of the room?"

I'm getting hundreds of list problem messages a day, most of which I expect
to go away when 'mailman' figure out the email addresses are long-term
invalid.  Or at least I hope the claims for 'mailman' are true.  The old
'majordomo' admin was so verbose from transient errors that I just filed the
emails and ignored them.


Donald Becker				becker@scyld.com
Scyld Computing Corporation
410 Severn Ave. Suite 210
Annapolis MD 21403