In message: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> writes:
:
: > Okay, so I got unlazy and threw some stuff together. Try these patches;
: > this will default the PCM200 cards to store-and-forward. This might help.
: > -ksaihr
: [...]
: > --- /usr/src/sys/pci/if_dcreg.h Thu Aug 5 13:
> Okay, so I got unlazy and threw some stuff together. Try these patches;
> this will default the PCM200 cards to store-and-forward. This might help.
> -ksaihr
[...]
> --- /usr/src/sys/pci/if_dcreg.h Thu Aug 5 13:46:14 2004
> +++ if_dcreg.h Sun Oct 24 13:09:31 2004
> @@ -98,6 +98,13 @@
> #defin
> > <>I don't see a way how it could break other cards' functionality -
> > should be no concerns here
> D-Link isn't the only 0x00a8; The AboCom FE2500MX bears 0x13d1 0xab08.
Are there any cards that have exactly the same 32-bit PCIID, and
different/modified chipsets? I didn't think that somethi
Okay, so I got unlazy and threw some stuff together. Try these patches;
this will default the PCM200 cards to store-and-forward. This might help.
-ksaihr
--- /usr/src/sys/pci/if_dc.cSun Oct 24 13:09:28 2004
+++ if_dc.c Sun Oct 24 12:59:07 2004
@@ -3022,6 +3022,16 @@
}
[EMAIL PROTECTED] wrote:
I've done a little testing under various loads. The driver switches
chip to store and forward mode soon during initial use after attaching
(I also get few messages about watchdog timeouts together with
"increasing TX threshold"). But it seems to work OK.
I haven't done any
> If you have done any testing, that should be sufficent.
I've done a little testing under various loads. The driver switches
chip to store and forward mode soon during initial use after attaching
(I also get few messages about watchdog timeouts together with
"increasing TX threshold"). But it s
On Fri, Oct 22, 2004 at 02:16:54AM -0600, [EMAIL PROTECTED] wrote:
>
> > Could some people with dc(4) devices please test the following patch?
> > It compiles for me and is trivial, but a quick test is probalby in order
> > before I commit it.
>
> It's rather necessary to test it well, because I
> Could some people with dc(4) devices please test the following patch?
> It compiles for me and is trivial, but a quick test is probalby in order
> before I commit it.
It's rather necessary to test it well, because I didn't actually remove
the card's case to see the chip; I relied on my own test
On Thu, Oct 21, 2004 at 10:34:56AM -0700, Brooks Davis wrote:
> On Wed, Oct 20, 2004 at 10:59:50PM -0600, [EMAIL PROTECTED] wrote:
> >
> > [got no answer on [EMAIL PROTECTED]
> >
> > I've tested this on 5.3-BETA7 - works OK, no more watchdog timeouts.
> > So could someone review those patches and
On Thu, Oct 21, 2004 at 10:34:56AM -0700, Brooks Davis wrote:
> On Wed, Oct 20, 2004 at 10:59:50PM -0600, [EMAIL PROTECTED] wrote:
> > @@ -1978,6 +1982,7 @@
> > case DC_DEVICEID_3CSOHOB:
> > case DC_DEVICEID_MSMN120:
> > case DC_DEVICEID_MSMN130_FAKE: /* XXX avoid collision
On Wed, Oct 20, 2004 at 10:59:50PM -0600, [EMAIL PROTECTED] wrote:
>
> [got no answer on [EMAIL PROTECTED]
>
> I've tested this on 5.3-BETA7 - works OK, no more watchdog timeouts.
> So could someone review those patches and add them to the source tree?
> It's probably a good idea to update dc(4)
On 2004.10.20 22:59:50 -0600, [EMAIL PROTECTED] wrote:
>
> [got no answer on [EMAIL PROTECTED]
>
> I've tested this on 5.3-BETA7 - works OK, no more watchdog timeouts.
> So could someone review those patches and add them to the source tree?
> It's probably a good idea to update dc(4) and supporte
[got no answer on [EMAIL PROTECTED]
I've tested this on 5.3-BETA7 - works OK, no more watchdog timeouts.
So could someone review those patches and add them to the source tree?
It's probably a good idea to update dc(4) and supported hw list also.
/usr/src/sys/pci/if_dc.c udiff:
--- ./if_dc.c S
13 matches
Mail list logo
