Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)

Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)

[kuznet]

Hello!

> that does hardware register access without protecting against interrupts
> or checking if the interface is up.

This issue is not that issue. It is separate issue and in fact
it is private problem of driver and its author, what is safe,
what is not safe.

F.e. I see no cathastrophe even if MII registers are accessed without
any protections. Diag utilities do this from user space. 8)8)


> de4x5 is probably also buggy in regard to this.

de4x5 is hopeless. I added nice comment in softnet to it.
Unfortunately it was lost. 8)

Andi, neither you nor me nor Alan nor anyone are able to audit
all this unnevessarily overcomplicated code. It was buggy, is buggy
and will be buggy. It is inavoidable, as soon as you have hundreds
of drivers.

Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)

[Jeff Garzik]

kuznet@ms2.inr.ac.ru wrote:
> 
> Hello!
> 
> > that does hardware register access without protecting against interrupts
> > or checking if the interface is up.
> 
> This issue is not that issue. It is separate issue and in fact
> it is private problem of driver and its author, what is safe,
> what is not safe.
> 
> F.e. I see no cathastrophe even if MII registers are accessed without
> any protections. Diag utilities do this from user space. 8)8)

It depends on the hardware...  For the ioctl-only case, you are
correct.  rtnl_lock protects us there.  But when the timer and ioctl
both call mdio_xxx, you need SMP protection, otherwise you corrupt the
multi-step MDIO read/write found in many drivers.

IMNSHO the timer routines found in net drivers should all be converted
to kernel threads.  There are too many limitations placed on you by
timers.


> > de4x5 is probably also buggy in regard to this.
> 
> de4x5 is hopeless. I added nice comment in softnet to it.
> Unfortunately it was lost. 8)
> 
> Andi, neither you nor me nor Alan nor anyone are able to audit
> all this unnevessarily overcomplicated code. It was buggy, is buggy
> and will be buggy. It is inavoidable, as soon as you have hundreds
> of drivers.

de4x5 is becoming EISA-only in 2.5.x too, since its PCI support is
duplicated now in tulip driver.

	Jeff


-- 
Jeff Garzik             | Dinner is ready when
Building 1024           | the smoke alarm goes off.
MandrakeSoft            |	-/usr/games/fortune
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)

[Bill Wendling]

Also sprach kuznet@ms2.inr.ac.ru:
} > de4x5 is probably also buggy in regard to this.
} 
} de4x5 is hopeless. I added nice comment in softnet to it.
} Unfortunately it was lost. 8)
} 
} Andi, neither you nor me nor Alan nor anyone are able to audit
} all this unnevessarily overcomplicated code. It was buggy, is buggy
} and will be buggy. It is inavoidable, as soon as you have hundreds
} of drivers.
} 
If they are buggy and unsupported, why aren't they being expunged from
the main source tree and placed into a ``contrib'' directory or something
for people who may want those drivers?

-- 
|| Bill Wendling			wendling@ganymede.isdn.uiuc.edu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)

[Jeff Garzik]

Bill Wendling wrote:
> 
> Also sprach kuznet@ms2.inr.ac.ru:
> } > de4x5 is probably also buggy in regard to this.
> }
> } de4x5 is hopeless. I added nice comment in softnet to it.
> } Unfortunately it was lost. 8)
> }
> } Andi, neither you nor me nor Alan nor anyone are able to audit
> } all this unnevessarily overcomplicated code. It was buggy, is buggy
> } and will be buggy. It is inavoidable, as soon as you have hundreds
> } of drivers.
> }
> If they are buggy and unsupported, why aren't they being expunged from
> the main source tree and placed into a ``contrib'' directory or something
> for people who may want those drivers?

de4x5 is stable.  Its hopeless to add stuff to it, or try to any fix of
the (IMHO small) issues, but its fine as is.  For maintenance issues,
its PCI support will be eliminated in 2.5.x because it is a duplicate of
support in the tulip driver.

	Jeff


-- 
Jeff Garzik             | Dinner is ready when
Building 1024           | the smoke alarm goes off.
MandrakeSoft            |	-/usr/games/fortune
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)

[Andi Kleen]

On Fri, Nov 03, 2000 at 05:30:26PM -0500, Jeff Garzik wrote:
> Bill Wendling wrote:
> > 
> > Also sprach kuznet@ms2.inr.ac.ru:
> > } > de4x5 is probably also buggy in regard to this.
> > }
> > } de4x5 is hopeless. I added nice comment in softnet to it.
> > } Unfortunately it was lost. 8)
> > }
> > } Andi, neither you nor me nor Alan nor anyone are able to audit
> > } all this unnevessarily overcomplicated code. It was buggy, is buggy
> > } and will be buggy. It is inavoidable, as soon as you have hundreds
> > } of drivers.
> > }
> > If they are buggy and unsupported, why aren't they being expunged from
> > the main source tree and placed into a ``contrib'' directory or something
> > for people who may want those drivers?
> 
> de4x5 is stable.  Its hopeless to add stuff to it, or try to any fix of
> the (IMHO small) issues, but its fine as is.  For maintenance issues,
> its PCI support will be eliminated in 2.5.x because it is a duplicate of
> support in the tulip driver.

de4x5 is stable, but tends to perform badly under load, mostly because
it doesn't use rx_copybreak and overflows standard socket buffers with its
always MTU sized skbuffs.


-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)

[Jeff Garzik]

Andi Kleen wrote:
> de4x5 is stable, but tends to perform badly under load, mostly because
> it doesn't use rx_copybreak and overflows standard socket buffers with its
> always MTU sized skbuffs.

One of the reasons that de4x5 isn't gone already is that I get reports
that de4x5 performs better than the tulip driver for their card.

	Jeff


-- 
Jeff Garzik             | Dinner is ready when
Building 1024           | the smoke alarm goes off.
MandrakeSoft            |	-/usr/games/fortune
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)

[Alan Cox]

> } Andi, neither you nor me nor Alan nor anyone are able to audit
> } all this unnevessarily overcomplicated code. It was buggy, is buggy
> } and will be buggy. It is inavoidable, as soon as you have hundreds
> } of drivers.
> } 
> If they are buggy and unsupported, why aren't they being expunged from
> the main source tree and placed into a ``contrib'' directory or something
> for people who may want those drivers?

Because by 2.4.5 it will be working ;). Pain power 8)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)

[Andi Kleen]

On Fri, Nov 03, 2000 at 06:57:32PM -0500, Jeff Garzik wrote:
> Andi Kleen wrote:
> > de4x5 is stable, but tends to perform badly under load, mostly because
> > it doesn't use rx_copybreak and overflows standard socket buffers with its
> > always MTU sized skbuffs.
> 
> One of the reasons that de4x5 isn't gone already is that I get reports
> that de4x5 performs better than the tulip driver for their card.

I have the same reports from various sources (but then they complain
about the socket buffer issue ;)  I think it would be best
to just keep it as it is with minimal mainteance, even in 2.5.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)

[kuznet]

Hello!

> de4x5 is becoming EISA-only in 2.5.x too, since its PCI support is
> duplicated now in tulip driver.

Luckily, my old Multia died. 8)

Jeff, tulip did not work with genuine Digital cards.
de4x5 was faulty (link state machine was broken, it has lost
link after some events on wire) but it worked yet.

Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)

[Jeff Garzik]

kuznet@ms2.inr.ac.ru wrote:
> > de4x5 is becoming EISA-only in 2.5.x too, since its PCI support is
> > duplicated now in tulip driver.
> 
> Luckily, my old Multia died. 8)
> 
> Jeff, tulip did not work with genuine Digital cards.

I'm pretty sure I fixed that.  Tested it on my Multia in fact :)  (and
my AS200 too)

The fix should be in 2.2.17 tulip.c, as well as 2.4.x...

	Jeff


-- 
Jeff Garzik             | Dinner is ready when
Building 1024           | the smoke alarm goes off.
MandrakeSoft            |	-/usr/games/fortune
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)

[kuznet]

Hello!

> > Luckily, my old Multia died. 8)
> > 
> > Jeff, tulip did not work with genuine Digital cards.
> 
> I'm pretty sure I fixed that.  Tested it on my Multia in fact :)  (and
> my AS200 too)
> 
> The fix should be in 2.2.17 tulip.c, as well as 2.4.x...

Then sed -e 's/Luckily/What a pity/' in may mail. 8)

Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

tulip vs. de4x5 (was Re: Linux 2.4 Status / TODO page ...)

[Jim Schutt]

Jeff Garzik wrote:
> 
> 
> de4x5 is becoming EISA-only in 2.5.x too, since its PCI support is
> duplicated now in tulip driver.
> 

I've got some DEC Miatas with DECchip 21142/43 ethernet cards, and I
don't get the same link speeds when using the de4x5 and tulip drivers,
as of 2.4.0-test10.  The machines are connected to a Netgear 16-port 
10/100 hub.  With the tulip driver the hub shows a 10 Mb/s connection;
with the de4x5 driver the hub shows a 100 Mb/s connection.  In both
cases the drivers are configured into the kernel, not as modules, if
it matters.

Am I doing something wrong, or is this a known issue?

FWIW, these machines are diskless, and according to the hub they download
the kernel at 100 Mb/s.  When the tulip-based kernel initializes the
card, the hub shows the link speed switching to 10 Mb/s.


from lspci -v:

00:03.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev
30)
	Flags: bus master, medium devsel, latency 255, IRQ 24
	I/O ports at 8000 [size=128]
	Memory at 0000000009000000 (32-bit, non-prefetchable) [size=128]
	Expansion ROM at 0000000009040000 [disabled] [size=256K]


de4x5 boot messages:

eth0: DC21143 at 0x8000 (PCI bus 0, device 3), h/w address 00:00:f8:76:3c:74,
      and requires IRQ24 (provided by PCI BIOS).
de4x5.c:V0.545 1999/11/28 davies@maniac.ultranet.com


tulip boot messages:

Linux Tulip driver version 0.9.10 (September 6, 2000)
eth0: Digital DS21143 Tulip rev 48 at 0x8000, 00:00:F8:76:3C:74, IRQ 24.
eth0:  EEPROM default media type Autosense.
eth0:  Index #0 - Media 10baseT (#0) described by a 21142 Serial PHY (2) block.
eth0:  Index #1 - Media 10baseT-FD (#4) described by a 21142 Serial PHY (2)
block.
eth0:  Index #2 - Media 10base2 (#1) described by a 21142 Serial PHY (2) block.
eth0:  Index #3 - Media AUI (#2) described by a 21142 Serial PHY (2) block.
eth0:  Index #4 - Media MII (#11) described by a 21142 MII PHY (3) block.
eth0:  MII transceiver #5 config 2000 status 784b advertising 01e1.

-- Jim

-----
James A. Schutt
jaschut@sandia.gov

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)

[David C. Davies]

All,

As you can see, I get little time to attend to maintenance chores on the 
de4x5 driver. If there are particular problems that you want sorted out 
please let me know and I'll see what I can do.

Regards,

Dave

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

Jeff Garzik wrote:

> Andi Kleen wrote:
> 
>> de4x5 is stable, but tends to perform badly under load, mostly because
>> it doesn't use rx_copybreak and overflows standard socket buffers with its
>> always MTU sized skbuffs.
> 
> 
> One of the reasons that de4x5 isn't gone already is that I get reports
> that de4x5 performs better than the tulip driver for their card.
> 
> 	Jeff
> 
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Linux 2.4 Status / TODO page (Updated as of 2.4.0-test10)

[David C. Davies]

[-- Attachment #1: Type: text/plain, Size: 522 bytes --]

All,

Please reply to daviesrallis@mediaone.net rather than this email account.

Regards,

Dave
------------------------------------

Jeff Garzik wrote:

> Andi Kleen wrote:
> 
>> de4x5 is stable, but tends to perform badly under load, mostly because
>> it doesn't use rx_copybreak and overflows standard socket buffers with its
>> always MTU sized skbuffs.
> 
> 
> One of the reasons that de4x5 isn't gone already is that I get reports
> that de4x5 performs better than the tulip driver for their card.
> 
> 	Jeff
> 
> 


[-- Attachment #2: Type: text/html, Size: 888 bytes --]