> "David" == David S Miller <[EMAIL PROTECTED]> writes:
David> I think this is an Acenic specific issue. The second processor
David> on the Acenic board is only there to work around bugs in their
David> DMA controller.
It wasn't put there for that reason. It was intended for better work
"David" == David S Miller [EMAIL PROTECTED] writes:
David I think this is an Acenic specific issue. The second processor
David on the Acenic board is only there to work around bugs in their
David DMA controller.
It wasn't put there for that reason. It was intended for better work
;-)
Jes
-
Jeff Garzik writes:
> And in another message, On Mon, 12 Feb 2001, David S. Miller wrote:
> > 3) The acenic/gbit performance anomalies have been cured
> >by reverting the PCI mem_inval tweaks.
>
>
> Just to be clear, acenic should or should not use MWI?
>
> And can a general rule
Jeff Garzik writes:
And in another message, On Mon, 12 Feb 2001, David S. Miller wrote:
3) The acenic/gbit performance anomalies have been cured
by reverting the PCI mem_inval tweaks.
Just to be clear, acenic should or should not use MWI?
And can a general rule be applied
> "Petr" == Petr Vandrovec <[EMAIL PROTECTED]> writes:
Petr> On 14 Feb 01 at 16:35, Jes Sorensen wrote:
>> What else is sending out 802.3 frames these days? I really don't
>> care about IPX when it comes to performance.
>>
>> I am just advocating that we optimize for the common case which
"Petr" == Petr Vandrovec [EMAIL PROTECTED] writes:
Petr On 14 Feb 01 at 16:35, Jes Sorensen wrote:
What else is sending out 802.3 frames these days? I really don't
care about IPX when it comes to performance.
I am just advocating that we optimize for the common case which is
DIX frames
On Tue, 13 Feb 2001, Ion Badulescu wrote:
> On Tue, 13 Feb 2001 12:29:16 -0800, Ion Badulescu <[EMAIL PROTECTED]>
>wrote:
> > On Tue, 13 Feb 2001 07:06:44 -0600 (CST), Jeff Garzik
><[EMAIL PROTECTED]> wrote:
> >
> >> On 12 Feb 2001, Jes Sorensen wrote:
> >>> In fact one has to look out for
On 14 Feb 01 at 16:35, Jes Sorensen wrote:
> > "Donald" == Donald Becker <[EMAIL PROTECTED]> writes:
> Donald> On 12 Feb 2001, Jes Sorensen wrote:
> Donald> ??? - It's not just IPX hosts that send 802.3 headers. -
> Donald> While a good initial value might depend on the architecture,
>
> "Jeff" == Jeff Garzik <[EMAIL PROTECTED]> writes:
Jeff> On 12 Feb 2001, Jes Sorensen wrote:
>> 3) The acenic/gbit performance anomalies have been cured by
>> reverting the PCI mem_inval tweaks.
Jeff> Just to be clear, acenic should or should not use MWI?
Jeff> And can a general rule be
> "Donald" == Donald Becker <[EMAIL PROTECTED]> writes:
Donald> On 12 Feb 2001, Jes Sorensen wrote:
>> In this case it just results in a performance degradation for 99%
>> of the usage. What about making the change so it is optimized away
>> unless IPX is enabled?
Donald> ??? - It's not
On Wed, 14 Feb 2001, Alan Cox wrote:
> > The way I understand it, IA64 and Alpha cope with it, but at the expense
> > of taking an exception for each packet -- so it's not worth it.
>
> You want to copy_checksum the frame on these platforms,
That's what we're doing...
> or better yet use
>
> The way I understand it, IA64 and Alpha cope with it, but at the expense
> of taking an exception for each packet -- so it's not worth it.
You want to copy_checksum the frame on these platforms, or better yet use
a decent network card that can start the frame on odd word alignment. You need
On Wed, 14 Feb 2001, Jeff Garzik wrote:
> On Wed, 14 Feb 2001, Alan Cox wrote:
> > It does. It does so on IA64 now as well. The only architecture which has troubles
> > with alignment on IP frames now is ARM2
>
> So the IA64-specific PKT_CAN_COPY code in starfire can go away
> completely? Jes,
On Wed, 14 Feb 2001, Alan Cox wrote:
> > There was not a bug in the driver. The bug was/is in the protocol handling
> > code. The protocol handling code *must* be able to handle unaligned IP
> > headers.
> It does. It does so on IA64 now as well. The only architecture which has troubles
> with
> There was not a bug in the driver. The bug was/is in the protocol handling
> code. The protocol handling code *must* be able to handle unaligned IP
> headers.
It does. It does so on IA64 now as well. The only architecture which has troubles
with alignment on IP frames now is ARM2
-
To
There was not a bug in the driver. The bug was/is in the protocol handling
code. The protocol handling code *must* be able to handle unaligned IP
headers.
It does. It does so on IA64 now as well. The only architecture which has troubles
with alignment on IP frames now is ARM2
-
To
On Wed, 14 Feb 2001, Alan Cox wrote:
There was not a bug in the driver. The bug was/is in the protocol handling
code. The protocol handling code *must* be able to handle unaligned IP
headers.
It does. It does so on IA64 now as well. The only architecture which has troubles
with
On Wed, 14 Feb 2001, Jeff Garzik wrote:
On Wed, 14 Feb 2001, Alan Cox wrote:
It does. It does so on IA64 now as well. The only architecture which has troubles
with alignment on IP frames now is ARM2
So the IA64-specific PKT_CAN_COPY code in starfire can go away
completely? Jes, can you
The way I understand it, IA64 and Alpha cope with it, but at the expense
of taking an exception for each packet -- so it's not worth it.
You want to copy_checksum the frame on these platforms, or better yet use
a decent network card that can start the frame on odd word alignment. You need
On Wed, 14 Feb 2001, Alan Cox wrote:
The way I understand it, IA64 and Alpha cope with it, but at the expense
of taking an exception for each packet -- so it's not worth it.
You want to copy_checksum the frame on these platforms,
That's what we're doing...
or better yet use
a decent
On 14 Feb 01 at 16:35, Jes Sorensen wrote:
"Donald" == Donald Becker [EMAIL PROTECTED] writes:
Donald On 12 Feb 2001, Jes Sorensen wrote:
Donald ??? - It's not just IPX hosts that send 802.3 headers. -
Donald While a good initial value might depend on the architecture,
Donald the best
On 12 Feb 2001, Jes Sorensen wrote:
> > "Donald" == Donald Becker <[EMAIL PROTECTED]> writes:
>
> Donald> On 9 Feb 2001, Jes Sorensen wrote:
> >> The ia64 kernel has gotten mis aligned load support, but it's slow
> >> as a dog so we really want to copy the packet every time anyway
> >> when
On Tue, 13 Feb 2001 12:29:16 -0800, Ion Badulescu <[EMAIL PROTECTED]> wrote:
> On Tue, 13 Feb 2001 07:06:44 -0600 (CST), Jeff Garzik
><[EMAIL PROTECTED]> wrote:
>
>> On 12 Feb 2001, Jes Sorensen wrote:
>>> In fact one has to look out for this and disable the feature in some
>>> cases. On the
On 12 Feb 2001, Jes Sorensen wrote:
> Ion> Yes, but I'd rather let people turn off the always-copy behavior
> Ion> by simply changing rx_copybreak. The unused code is not really
> Ion> that much of a deal, it's only a few lines.
>
> However, it is in the hot path code where it hurts the most.
On Tue, 13 Feb 2001 07:06:44 -0600 (CST), Jeff Garzik
<[EMAIL PROTECTED]> wrote:
> On 12 Feb 2001, Jes Sorensen wrote:
>> In fact one has to look out for this and disable the feature in some
>> cases. On the acenic not disabling Memory Write and Invalidate costs
>> ~20% on performance on some
On 12 Feb 2001, Jes Sorensen wrote:
> > "Gérard" == Gérard Roudier <[EMAIL PROTECTED]> writes:
> Gérard> In PCI, it is the Memory Write and Invalidate PCI transaction
> Gérard> that is intended to allow core-logics to optimize DMA this
> Gérard> way. For normal Memory Write PCI transactions
On Tue, 13 Feb 2001 07:06:44 -0600 (CST), Jeff Garzik
[EMAIL PROTECTED] wrote:
On 12 Feb 2001, Jes Sorensen wrote:
In fact one has to look out for this and disable the feature in some
cases. On the acenic not disabling Memory Write and Invalidate costs
~20% on performance on some systems.
On 12 Feb 2001, Jes Sorensen wrote:
Ion Yes, but I'd rather let people turn off the always-copy behavior
Ion by simply changing rx_copybreak. The unused code is not really
Ion that much of a deal, it's only a few lines.
However, it is in the hot path code where it hurts the most.
I
On Tue, 13 Feb 2001 12:29:16 -0800, Ion Badulescu [EMAIL PROTECTED] wrote:
On Tue, 13 Feb 2001 07:06:44 -0600 (CST), Jeff Garzik
[EMAIL PROTECTED] wrote:
On 12 Feb 2001, Jes Sorensen wrote:
In fact one has to look out for this and disable the feature in some
cases. On the acenic not
On 12 Feb 2001, Jes Sorensen wrote:
"Donald" == Donald Becker [EMAIL PROTECTED] writes:
Donald On 9 Feb 2001, Jes Sorensen wrote:
The ia64 kernel has gotten mis aligned load support, but it's slow
as a dog so we really want to copy the packet every time anyway
when the header is not
> "Gérard" == Gérard Roudier <[EMAIL PROTECTED]> writes:
Gérard> On Fri, 9 Feb 2001, Alan Cox wrote:
>> DMA to main memory normally invalidates those lines in the CPU
>> cache rather than the cache snooping and updating its view of them.
Gérard> In PCI, it is the Memory Write and
> "Ion" == Ion Badulescu <[EMAIL PROTECTED]> writes:
Ion> On 9 Feb 2001, Jes Sorensen wrote:
>> Inefficient, my patch will make the unused code path disappear
>> during compilation, what you suggest results in an extra branch and
>> unused code.
Ion> Yes, but I'd rather let people turn off
> "Donald" == Donald Becker <[EMAIL PROTECTED]> writes:
Donald> On 9 Feb 2001, Jes Sorensen wrote:
>> The ia64 kernel has gotten mis aligned load support, but it's slow
>> as a dog so we really want to copy the packet every time anyway
>> when the header is not aligned. If people send out
"Donald" == Donald Becker [EMAIL PROTECTED] writes:
Donald On 9 Feb 2001, Jes Sorensen wrote:
The ia64 kernel has gotten mis aligned load support, but it's slow
as a dog so we really want to copy the packet every time anyway
when the header is not aligned. If people send out 802.3 headers or
"Ion" == Ion Badulescu [EMAIL PROTECTED] writes:
Ion On 9 Feb 2001, Jes Sorensen wrote:
Inefficient, my patch will make the unused code path disappear
during compilation, what you suggest results in an extra branch and
unused code.
Ion Yes, but I'd rather let people turn off the
"Grard" == Grard Roudier [EMAIL PROTECTED] writes:
Grard On Fri, 9 Feb 2001, Alan Cox wrote:
DMA to main memory normally invalidates those lines in the CPU
cache rather than the cache snooping and updating its view of them.
Grard In PCI, it is the Memory Write and Invalidate PCI transaction
Hi Jes,
I read through your acenic driver and noticed that you replaced
spinlocks with bitops.
Is that a good idea? I always avoid bitops and replace them with
spinlocks:
* On uniprocessor they are obviously slower.
* on SMP i386 spin_lock() / spin_unlock() is faster than
On Fri, 9 Feb 2001, Alan Cox wrote:
> > > For non routing paths its virtually free because the DMA forced the lines
> > > from cache anyway.
> >
> > Are you actually sure about this? I thought DMA from PCI devices reached
> > the main memory without polluting the L2 cache. Otherwise any
Hi Jes,
I read through your acenic driver and noticed that you replaced
spinlocks with bitops.
Is that a good idea? I always avoid bitops and replace them with
spinlocks:
* On uniprocessor they are obviously slower.
* on SMP i386 spin_lock() / spin_unlock() is faster than
> > For non routing paths its virtually free because the DMA forced the lines
> > from cache anyway.
>
> Are you actually sure about this? I thought DMA from PCI devices reached
> the main memory without polluting the L2 cache. Otherwise any large DMA
> transfer would kill the cache (think
On Fri, 9 Feb 2001, Alan Cox wrote:
> > It's amusing that a full receive copy is added without any concern, in
> > the same discussion where zero-copy transmit is treated as a holy grail!
>
> For non routing paths its virtually free because the DMA forced the lines
> from cache anyway.
Are
On 9 Feb 2001, Jes Sorensen wrote:
> > "Jeff" == Jeff Garzik <[EMAIL PROTECTED]> writes:
> Jeff> Donald Becker wrote:
> >> On Tue, 16 Jan 2001, Jeff Garzik wrote: > * IA64 support (Jes) Oh,
> >> and this is completely bogus. This isn't a fix, it's a hack that
> >> covers up the real
On 9 Feb 2001, Jes Sorensen wrote:
> Manfred> What about changing the default for rx_copybreak instead?
> Manfred> Set it to 1536 on ia64 and Alpha, 0 for the rest. tulip and
> Manfred> eepro100 use that aproach.
>
> Inefficient, my patch will make the unused code path disappear during
>
> "Manfred" == Manfred Spraul <[EMAIL PROTECTED]> writes:
Manfred> Ion Badulescu wrote:
>> > > +#if defined(__ia64__) || defined(__alpha__) > > +#define
>> PKT_SHOULD_COPY(pkt_len) 1 > > +#else > > +#define
>> PKT_SHOULD_COPY(pkt_len) (pkt_len < rx_copybreak) > > +#endif >
>> [snip]
>>
>>
> "Jeff" == Jeff Garzik <[EMAIL PROTECTED]> writes:
Jeff> Donald Becker wrote:
>> On Tue, 16 Jan 2001, Jeff Garzik wrote: > * IA64 support (Jes) Oh,
>> and this is completely bogus. This isn't a fix, it's a hack that
>> covers up the real problem.
>>
>> The align-copy should *never* be
Ion Badulescu wrote:
> ... and use both SET_MODULE_OWNER and STAR_MOD_*_USE_COUNT. It's along the
> lines of what I was thinking -- though I don't think it's very clean.
It's about the best you can do, considering the 'no ifdefs in raw'
axiom.. Better suggestions are certainly welcome.
> And
On Fri, 9 Feb 2001, Jeff Garzik wrote:
> For 2.2, define SET_MODULE_OWNER to null.
>
> Define STAR_MOD_INC_USE_COUNT and STAR_MOD_DEC_USE_COUNT. For 2.4,
> these are null. For 2.2, these point to MOD_{INC,DEC}_USE_COUNT.
... and use both SET_MODULE_OWNER and STAR_MOD_*_USE_COUNT. It's along
Ion Badulescu wrote:
> On Fri, 9 Feb 2001, Jeff Garzik wrote:
> > BTW, I would suggest looking at Jes' acenic.c as an example of a 2.4
> > driver that is clean but also [hopefully!] works under 2.2.
>
> The *only* thing I couldn't solve cleanly is the MOD_{INC,DEC}_USE_COUNT
> vs
On Fri, 9 Feb 2001, Jeff Garzik wrote:
> I would prefer that zerocopy code remain out of all official kernels
> until zerocopy itself is in said kernels. It's experimental code that
> simply cannot work in its present form, due to lack of infrastructure in
> the general kernel. And being based
Ion Badulescu wrote:
> On Thu, 8 Feb 2001, Jeff Garzik wrote:
> > The #ifdef ZEROCOPY code you added is a classic example of the kind of
> > code I -remove- from the kernel tree.
>
> It's an issue of maintainer convenience vs. esthetics. And (last but not
> least) it's also about other people's
> It's amusing that a full receive copy is added without any concern, in
> the same discussion where zero-copy transmit is treated as a holy grail!
For non routing paths its virtually free because the DMA forced the lines
from cache anyway. Basically its a deficiency in the chipset. We don't
It's amusing that a full receive copy is added without any concern, in
the same discussion where zero-copy transmit is treated as a holy grail!
For non routing paths its virtually free because the DMA forced the lines
from cache anyway. Basically its a deficiency in the chipset. We don't
Ion Badulescu wrote:
On Thu, 8 Feb 2001, Jeff Garzik wrote:
The #ifdef ZEROCOPY code you added is a classic example of the kind of
code I -remove- from the kernel tree.
It's an issue of maintainer convenience vs. esthetics. And (last but not
least) it's also about other people's ability
On Fri, 9 Feb 2001, Jeff Garzik wrote:
I would prefer that zerocopy code remain out of all official kernels
until zerocopy itself is in said kernels. It's experimental code that
simply cannot work in its present form, due to lack of infrastructure in
the general kernel. And being based on
Ion Badulescu wrote:
On Fri, 9 Feb 2001, Jeff Garzik wrote:
BTW, I would suggest looking at Jes' acenic.c as an example of a 2.4
driver that is clean but also [hopefully!] works under 2.2.
The *only* thing I couldn't solve cleanly is the MOD_{INC,DEC}_USE_COUNT
vs MODULE_SET_OWNER(). And
On Fri, 9 Feb 2001, Jeff Garzik wrote:
For 2.2, define SET_MODULE_OWNER to null.
Define STAR_MOD_INC_USE_COUNT and STAR_MOD_DEC_USE_COUNT. For 2.4,
these are null. For 2.2, these point to MOD_{INC,DEC}_USE_COUNT.
... and use both SET_MODULE_OWNER and STAR_MOD_*_USE_COUNT. It's along the
Ion Badulescu wrote:
... and use both SET_MODULE_OWNER and STAR_MOD_*_USE_COUNT. It's along the
lines of what I was thinking -- though I don't think it's very clean.
It's about the best you can do, considering the 'no ifdefs in raw'
axiom.. Better suggestions are certainly welcome.
And one
"Manfred" == Manfred Spraul [EMAIL PROTECTED] writes:
Manfred Ion Badulescu wrote:
+#if defined(__ia64__) || defined(__alpha__) +#define
PKT_SHOULD_COPY(pkt_len) 1 +#else +#define
PKT_SHOULD_COPY(pkt_len) (pkt_len rx_copybreak) +#endif
[snip]
It's not *required* per se, as
"Jeff" == Jeff Garzik [EMAIL PROTECTED] writes:
Jeff Donald Becker wrote:
On Tue, 16 Jan 2001, Jeff Garzik wrote: * IA64 support (Jes) Oh,
and this is completely bogus. This isn't a fix, it's a hack that
covers up the real problem.
The align-copy should *never* be required because the
On 9 Feb 2001, Jes Sorensen wrote:
Manfred What about changing the default for rx_copybreak instead?
Manfred Set it to 1536 on ia64 and Alpha, 0 for the rest. tulip and
Manfred eepro100 use that aproach.
Inefficient, my patch will make the unused code path disappear during
compilation,
On 9 Feb 2001, Jes Sorensen wrote:
"Jeff" == Jeff Garzik [EMAIL PROTECTED] writes:
Jeff Donald Becker wrote:
On Tue, 16 Jan 2001, Jeff Garzik wrote: * IA64 support (Jes) Oh,
and this is completely bogus. This isn't a fix, it's a hack that
covers up the real problem.
The
On Fri, 9 Feb 2001, Alan Cox wrote:
It's amusing that a full receive copy is added without any concern, in
the same discussion where zero-copy transmit is treated as a holy grail!
For non routing paths its virtually free because the DMA forced the lines
from cache anyway.
Are you
For non routing paths its virtually free because the DMA forced the lines
from cache anyway.
Are you actually sure about this? I thought DMA from PCI devices reached
the main memory without polluting the L2 cache. Otherwise any large DMA
transfer would kill the cache (think frame
On Thu, 8 Feb 2001, Donald Becker wrote:
> > Or we can just tell people, "hey, don't use this 64-bit PCI card on a real
> > 64-bit system, it's broken by design"? I don't think that's a good
> > solution either.
>
> This is not a 64 bit PCI issue.
I know. It was just an ironic comment: we
On Thu, 8 Feb 2001, Ion Badulescu wrote:
> On Thu, 8 Feb 2001, Donald Becker wrote:
>
> > > > The align-copy should *never* be required because the alignment differs
> > > > between DIX and E-II encapsulated packets. The machine shouldn't crash
> > > > because someone sends you a different
On Thu, 8 Feb 2001, Ion Badulescu wrote:
> >The MII read code is no longer reliable. I spent twenty minutes at
> >the show, but couldn't figure out the problem. I haven't been able
> >reproduce the problem locally with my 2.2 code and someone older
> >hardware.
>
> Yes, I've
On Thu, 8 Feb 2001, Donald Becker wrote:
> > > The align-copy should *never* be required because the alignment differs
> > > between DIX and E-II encapsulated packets. The machine shouldn't crash
> > > because someone sends you a different encapsulation type!
>
> This is true for a number of
On Thu, 8 Feb 2001, Jeff Garzik wrote:
> Well at least let's do it the Linux Kernel Way(tm): separate out the
> zerocopy stuff such that there are minimal ifdefs in the code... For
> example:
>
> /* add these functions... */
> #ifdef ZEROCOPY
> static inline
On Thu, 8 Feb 2001, Jeff Garzik wrote:
> > Well, I decided to bite the bullet and port my zerocopy starfire
> > changes to the official tree, properly ifdef'ed. So here it goes,
>
> I would prefer that the zerocopy changes stay in DaveM's external patch
> until they are ready to be merged.
On Thu, 8 Feb 2001, Manfred Spraul wrote:
> What about changing the default for rx_copybreak instead?
> Set it to 1536 on ia64 and Alpha, 0 for the rest.
> tulip and eepro100 use that aproach.
That makes a lot of sense, thanks for the suggestion. I'll do so in the
next version.
Ion
--
It
Ion Badulescu wrote:
>
> On Thu, 8 Feb 2001, Jeff Garzik wrote:
>
> > I would prefer that the zerocopy changes stay in DaveM's external patch
> > until they are ready to be merged.
>
> I would actually prefer to have a single source for all the driver
> versions. The 2.2.x version I sent to
Ion Badulescu wrote:
>
> > > +#if defined(__ia64__) || defined(__alpha__)
> > > +#define PKT_SHOULD_COPY(pkt_len) 1
> > > +#else
> > > +#define PKT_SHOULD_COPY(pkt_len) (pkt_len < rx_copybreak)
> > > +#endif
> >
> [snip]
>
> It's not *required* per se, as far as I know both the
On Thu, 8 Feb 2001, Jeff Garzik wrote:
> I would prefer that the zerocopy changes stay in DaveM's external patch
> until they are ready to be merged.
I would actually prefer to have a single source for all the driver
versions. The 2.2.x version I sent to Alan later on actually compiles on
Ion Badulescu wrote:
>
> Hi Jeff,
>
> On Wed, 07 Feb 2001 14:57:16 -0500, Jeff Garzik <[EMAIL PROTECTED]> wrote:
>
> > Here's the patch I have, against vanilla 2.4.2-pre1, with the
> > pci_enable_device preferred changes included...
>
> Well, I decided to bite the bullet and port my zerocopy
Ion Badulescu wrote:
Hi Jeff,
On Wed, 07 Feb 2001 14:57:16 -0500, Jeff Garzik [EMAIL PROTECTED] wrote:
Here's the patch I have, against vanilla 2.4.2-pre1, with the
pci_enable_device preferred changes included...
Well, I decided to bite the bullet and port my zerocopy starfire
On Thu, 8 Feb 2001, Jeff Garzik wrote:
I would prefer that the zerocopy changes stay in DaveM's external patch
until they are ready to be merged.
I would actually prefer to have a single source for all the driver
versions. The 2.2.x version I sent to Alan later on actually compiles on
Ion Badulescu wrote:
+#if defined(__ia64__) || defined(__alpha__)
+#define PKT_SHOULD_COPY(pkt_len) 1
+#else
+#define PKT_SHOULD_COPY(pkt_len) (pkt_len rx_copybreak)
+#endif
[snip]
It's not *required* per se, as far as I know both the Alpha and IA64 have
Ion Badulescu wrote:
On Thu, 8 Feb 2001, Jeff Garzik wrote:
I would prefer that the zerocopy changes stay in DaveM's external patch
until they are ready to be merged.
I would actually prefer to have a single source for all the driver
versions. The 2.2.x version I sent to Alan later
On Thu, 8 Feb 2001, Manfred Spraul wrote:
What about changing the default for rx_copybreak instead?
Set it to 1536 on ia64 and Alpha, 0 for the rest.
tulip and eepro100 use that aproach.
That makes a lot of sense, thanks for the suggestion. I'll do so in the
next version.
Ion
--
It is
On Thu, 8 Feb 2001, Jeff Garzik wrote:
Well, I decided to bite the bullet and port my zerocopy starfire
changes to the official tree, properly ifdef'ed. So here it goes,
I would prefer that the zerocopy changes stay in DaveM's external patch
until they are ready to be merged. Zerocopy is
On Thu, 8 Feb 2001, Jeff Garzik wrote:
Well at least let's do it the Linux Kernel Way(tm): separate out the
zerocopy stuff such that there are minimal ifdefs in the code... For
example:
/* add these functions... */
#ifdef ZEROCOPY
static inline setup_txrx_rings(...) {
On Thu, 8 Feb 2001, Donald Becker wrote:
The align-copy should *never* be required because the alignment differs
between DIX and E-II encapsulated packets. The machine shouldn't crash
because someone sends you a different encapsulation type!
This is true for a number of drivers --
On Thu, 8 Feb 2001, Ion Badulescu wrote:
The MII read code is no longer reliable. I spent twenty minutes at
the show, but couldn't figure out the problem. I haven't been able
reproduce the problem locally with my 2.2 code and someone older
hardware.
Yes, I've noticed
On Thu, 8 Feb 2001, Ion Badulescu wrote:
On Thu, 8 Feb 2001, Donald Becker wrote:
The align-copy should *never* be required because the alignment differs
between DIX and E-II encapsulated packets. The machine shouldn't crash
because someone sends you a different encapsulation
On Thu, 8 Feb 2001, Donald Becker wrote:
Or we can just tell people, "hey, don't use this 64-bit PCI card on a real
64-bit system, it's broken by design"? I don't think that's a good
solution either.
This is not a 64 bit PCI issue.
I know. It was just an ironic comment: we have a
Manfred Spraul wrote:
>
> Jeff Garzik wrote:
> >
> > + SET_MODULE_OWNER(dev);
> >
> > irq = pdev->irq;
> >
>
> One question:
> The code copies 'pdev->irq' into 'dev->irq'.
>
> Is that required, who need 'dev->irq'?
>
> > retval = request_irq(dev->irq, _handler, SA_SHIRQ,
Hi Jeff,
On Wed, 07 Feb 2001 14:57:16 -0500, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Here's the patch I have, against vanilla 2.4.2-pre1, with the
> pci_enable_device preferred changes included...
Well, I decided to bite the bullet and port my zerocopy starfire
changes to the official tree,
Jeff Garzik wrote:
>
> + SET_MODULE_OWNER(dev);
>
> irq = pdev->irq;
>
One question:
The code copies 'pdev->irq' into 'dev->irq'.
Is that required, who need 'dev->irq'?
> retval = request_irq(dev->irq, _handler, SA_SHIRQ, dev->name, dev);
Can't the driver use?
retval =
[EMAIL PROTECTED] wrote:
>
> > rejected -- ioaddr assigned a value before pci_enable_device is called
>
> Better ?
Here's the patch I have, against vanilla 2.4.2-pre1, with the
pci_enable_device preferred changes included...
--
Jeff Garzik | "You see, in this world there's two kinds of
> rejected -- ioaddr assigned a value before pci_enable_device is called
Better ?
Dave.
--
| Dave Jones.http://www.suse.de/~davej
| SuSE Labs
diff -urN --exclude-from=/home/davej/.exclude linux/drivers/net/starfire.c
linux-dj/drivers/net/starfire.c
--- linux/drivers/net/starfire.c
Hi Alan, Donald,
This driver should call pci_enable_device before reading
pdev->irq.
regards,
Dave.
--
| Dave Jones.http://www.suse.de/~davej
| SuSE Labs
diff -urN --exclude-from=/home/davej/.exclude linux/drivers/net/starfire.c
linux-dj/drivers/net/starfire.c
---
Hi Alan, Donald,
This driver should call pci_enable_device before reading
pdev-irq.
regards,
Dave.
--
| Dave Jones.http://www.suse.de/~davej
| SuSE Labs
diff -urN --exclude-from=/home/davej/.exclude linux/drivers/net/starfire.c
linux-dj/drivers/net/starfire.c
---
rejected -- ioaddr assigned a value before pci_enable_device is called
Better ?
Dave.
--
| Dave Jones.http://www.suse.de/~davej
| SuSE Labs
diff -urN --exclude-from=/home/davej/.exclude linux/drivers/net/starfire.c
linux-dj/drivers/net/starfire.c
--- linux/drivers/net/starfire.c
[EMAIL PROTECTED] wrote:
rejected -- ioaddr assigned a value before pci_enable_device is called
Better ?
Here's the patch I have, against vanilla 2.4.2-pre1, with the
pci_enable_device preferred changes included...
--
Jeff Garzik | "You see, in this world there's two kinds of
Jeff Garzik wrote:
+ SET_MODULE_OWNER(dev);
irq = pdev-irq;
One question:
The code copies 'pdev-irq' into 'dev-irq'.
Is that required, who need 'dev-irq'?
retval = request_irq(dev-irq, intr_handler, SA_SHIRQ, dev-name, dev);
Can't the driver use?
retval =
Hi Jeff,
On Wed, 07 Feb 2001 14:57:16 -0500, Jeff Garzik [EMAIL PROTECTED] wrote:
Here's the patch I have, against vanilla 2.4.2-pre1, with the
pci_enable_device preferred changes included...
Well, I decided to bite the bullet and port my zerocopy starfire
changes to the official tree,
Manfred Spraul wrote:
Jeff Garzik wrote:
+ SET_MODULE_OWNER(dev);
irq = pdev-irq;
One question:
The code copies 'pdev-irq' into 'dev-irq'.
Is that required, who need 'dev-irq'?
retval = request_irq(dev-irq, intr_handler, SA_SHIRQ, dev-name, dev);
Can't the
97 matches
Mail list logo
