* Re: [patch 1/6] 8139too: force media setting cleanup
[not found] <200705232134.l4NLYcm2000578@shell0.pdx.osdl.net>
@ 2007-05-24 21:36 ` Jeff Garzik
2007-06-13 12:52 ` Kyuma Ohta
0 siblings, 1 reply; 3+ messages in thread
From: Jeff Garzik @ 2007-05-24 21:36 UTC (permalink / raw)
To: akpm; +Cc: leewkb, netdev, Linux Kernel Mailing List
akpm@linux-foundation.org wrote:
> From: Bernard Lee <leewkb@yahoo.com>
>
> Setting bit 4 & 5 alone in 8139too module media option does not really
> force 100Mbps full-duplex mode. When media option bit 0-3 is cleared,
> 8139too module does not force media setting. Therefore, bit 0-3 requires
> to be set for bit 4 & 5 to take effect. The hidden bit 0-3 setting is not
> stated in module description.
>
> It can be fixed by changing rtl8139_private structure default_port bitfield
> from 4-bit to 6-bit.
>
> Besides, module media bit 9 is a duplicate of bit 4 (full-duplex). It is
> suggested that bit 9 is freed. A remark is added to module description
> that bit 0 can be used to force setting. It helps to clarify 10Mbps
> half-duplex mode.
>
> Signed-off-by: Bernard Lee <leewkb@yahoo.com>
> Cc: Jeff Garzik <jeff@garzik.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>
> drivers/net/8139too.c | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
(re-replying, just to refresh everybody on the status)
The status of this patch is HOLD, and has been for months.
AFAICS this is a behavior change that differs from other Becker-derived
drivers. I would suggest looking at other drivers.
Furthermore, people should be using ethtool to set media. Rather than
changing the behavior of this module parameter to be non-standard, I
feel it is better to (a) leave it as is or (b) remove it completely.
Jeff
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [patch 1/6] 8139too: force media setting cleanup
2007-05-24 21:36 ` [patch 1/6] 8139too: force media setting cleanup Jeff Garzik
@ 2007-06-13 12:52 ` Kyuma Ohta
2007-06-13 17:09 ` Jeff Garzik
0 siblings, 1 reply; 3+ messages in thread
From: Kyuma Ohta @ 2007-06-13 12:52 UTC (permalink / raw)
To: Jeff Garzik, Linux Kernel Mailing List; +Cc: akpm, leewkb, netdev
Hi,
I was testing 2.6.22-rc4 from yesterday,
but communication speed of 8139 side is very slower
than 2.6.21.* (less than 10kbytes/sec at
100MBPS,FULL-DUPLEX).
I was not test from 2.6.22-rc ,yesterday I started to test 2.6.22-rc.
So, I *must* set HALF-DUPLEX to 8139 side below:
ethtool -s ethx speed 100 duplex half autoneg on
*x is number of 8139 assigned from udev.
So,Pls.apply this patch to upstream,and I test this too.
Best Regards,
Ohta.
Appendix information:
archtecture: x86_64
Main Board : Gigabyte GA-M69P-M3 (rev.1.0?)
MPU: Athlon 64x2 4600+ (Not overclocked)
Chipset : nVidia nForce430+GForce 6150 Complex chip
Memory : PC-5300 2GB (w/shared graphix memory)
Ether: nForce430 (within complex chip,using forcedeth)
Realtec 8139C (+?) (on PCI Slot,using 8139too)
OS: Debian GNU/Linux "sid" (after "etch",using glibc2.5).
On 2007-05-24 (Thu) 17:36 -0400 , Jeff Garzik Wrote:
> akpm@linux-foundation.org wrote:
> > From: Bernard Lee <leewkb@yahoo.com>
> >
> > Setting bit 4 & 5 alone in 8139too module media option does not really
> > force 100Mbps full-duplex mode. When media option bit 0-3 is cleared,
> > 8139too module does not force media setting. Therefore, bit 0-3 requires
> > to be set for bit 4 & 5 to take effect. The hidden bit 0-3 setting is not
> > stated in module description.
> >
> > It can be fixed by changing rtl8139_private structure default_port bitfield
> > from 4-bit to 6-bit.
> >
> > Besides, module media bit 9 is a duplicate of bit 4 (full-duplex). It is
> > suggested that bit 9 is freed. A remark is added to module description
> > that bit 0 can be used to force setting. It helps to clarify 10Mbps
> > half-duplex mode.
> >
> > Signed-off-by: Bernard Lee <leewkb@yahoo.com>
> > Cc: Jeff Garzik <jeff@garzik.org>
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> > ---
> >
> > drivers/net/8139too.c | 8 ++++----
> > 1 files changed, 4 insertions(+), 4 deletions(-)
>
> (re-replying, just to refresh everybody on the status)
>
> The status of this patch is HOLD, and has been for months.
>
> AFAICS this is a behavior change that differs from other Becker-derived
> drivers. I would suggest looking at other drivers.
>
> Furthermore, people should be using ethtool to set media. Rather than
> changing the behavior of this module parameter to be non-standard, I
> feel it is better to (a) leave it as is or (b) remove it completely.
>
> Jeff
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [patch 1/6] 8139too: force media setting cleanup
2007-06-13 12:52 ` Kyuma Ohta
@ 2007-06-13 17:09 ` Jeff Garzik
0 siblings, 0 replies; 3+ messages in thread
From: Jeff Garzik @ 2007-06-13 17:09 UTC (permalink / raw)
To: Kyuma Ohta; +Cc: Linux Kernel Mailing List, akpm, leewkb, netdev
Kyuma Ohta wrote:
> Hi,
> I was testing 2.6.22-rc4 from yesterday,
> but communication speed of 8139 side is very slower
> than 2.6.21.* (less than 10kbytes/sec at
> 100MBPS,FULL-DUPLEX).
> I was not test from 2.6.22-rc ,yesterday I started to test 2.6.22-rc.
>
> So, I *must* set HALF-DUPLEX to 8139 side below:
> ethtool -s ethx speed 100 duplex half autoneg on
> *x is number of 8139 assigned from udev.
>
> So,Pls.apply this patch to upstream,and I test this too.
Your use of ethtool clearly demonstrates the lack of need for this patch.
Jeff
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2007-06-13 17:09 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <200705232134.l4NLYcm2000578@shell0.pdx.osdl.net>
2007-05-24 21:36 ` [patch 1/6] 8139too: force media setting cleanup Jeff Garzik
2007-06-13 12:52 ` Kyuma Ohta
2007-06-13 17:09 ` Jeff Garzik
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).