public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Ivan G." <ivangurdiev@yahoo.com>
To: Urban Widmark <urban@teststation.com>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Via-rhine minor issues
Date: Mon, 22 Apr 2002 22:07:16 -0600	[thread overview]
Message-ID: <02042222071600.00745@cobra.linux> (raw)
In-Reply-To: <Pine.LNX.4.33.0204222056480.9063-100000@cola.teststation.com>

> The public docs don't say.
>

That is precisely the problem.
4 missing interrupts in the interrupt mask, 1 additional interrupt 
which Jeff Garzik says all drivers should handle and the via-rhine doesn't.
2 interrupts handled quite differently in the linuxfet driver.
1 wicked error message of which I've seen 3 different versions and none of 
them makes much sense to me. 

It is lack of documentation.
The tech sheets do not explain what causes the interrupts in detail, how to 
handle the interrupts in detail. They rather provide the bit address of the 
interrupt which is good to know, but not enough. What resources did Donald 
Becker use when he was writing this?

Perhaps I should ask him.
Or do you know a good document on such things?
 

> You should probably add them to the list of reasons to call
> via_rhine_error, and let them be caught by the "wicked" error rule. A
> reason to use a term that doesn't try to be specific is that we don't
> really know what is causing the event.

Well, most Rx errors are handled in via_rhine_rx.
The "Wicked" error rule doesn't do anything besides a CmdTxDemand.
Is this correct handling for, let's say RxOverflow?  ..Again, facing the
overwhelming lack of documentation :) (see above paragraph)

Yes, we do know what's causing the event.
We know exactly which interrupt.
We just don't know how to handle it.

> Does merging this error handling change into the main kernel really help
> you test other things for your timeout problem? Can't you just include
> this bit in your other work?
>
> /Urban

Ok not really.
Apparently this change is controversial and I'll leave it out of my patch 
until decided what to do. I would just like the kernel driver to be less 
buggy and I wanted to contribute.

Plus, I've been making too many changes to my copy. It would be easier to 
work over a clean kernel driver.  I would have less things to keep track of 
that have been changed.


---------------------------
While we're talking about bugs, here's a (possibly ignorant) question:
Do Rhine-III's have a place in the following? : 

#ifdef USE_MEM
static void __devinit enable_mmio(long ioaddr, int chip_id)
{
        int n;
        if (chip_id == VT86C100A) {
                /* More recent docs say that this bit is reserved ... */
                n = inb(ioaddr + ConfigA) | 0x20;
                outb(n, ioaddr + ConfigA);
        } else if (chip_id == VT6102) {
                n = inb(ioaddr + ConfigD) | 0x80;
                outb(n, ioaddr + ConfigD);
        }
}
#endif


-----------------------------

Well, apart from things which are not precisely clear how to fix, 
would you like to me to submit any portions of my patch for inclusion at all?
A little warning: as far as testing goes - my card stalls without the fixes,
and it stalls with the fixes :) Yet, they seem simple enough to offer for 
inclusion. 








  reply	other threads:[~2002-04-23  4:13 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-21 21:16 Ivan G.
2002-04-21 23:02 ` your mail Jeff Garzik
2002-04-21 23:25   ` [PATCH] Via-rhine minor issues Ivan G.
2002-04-22 19:33     ` Urban Widmark
2002-04-23  4:07       ` Ivan G. [this message]
2002-04-23 13:44         ` Urban Widmark
  -- strict thread matches above, loose matches on Subject: below --
2002-04-21  7:02 Ivan G.
2002-04-21 10:00 ` Martin Eriksson
2002-04-21 10:19 ` Urban Widmark
2002-04-21 16:07   ` Jeff Garzik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=02042222071600.00745@cobra.linux \
    --to=ivangurdiev@yahoo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=urban@teststation.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox