Re: [9fans] rtl8139 ether driver

Re: [9fans] rtl8139 ether driver

[jmk]

On Tue Jun 25 21:48:22 EDT 2002, okamoto@granite.cias.osakafu-u.ac.jp wrote:
>
> I'm now forced to use rtl8139 nic for my new Auth/CPU server (
> it's for 3ed not 4ed. I cannot update our system now, because it's
> being used for the platform for our application, and the semester is
> still going here).   it reboots once a day.  :-)
>
> We had been using dual Pen III on SuperMicro motherboard, but it
> crushed about a month ago.   Then, I changed that server to a Pen 4
> mother board (1.6GHz) of AOpen AX4B Pro-533 which has on board
> nic chip of Realtek 8100BL.   It seems to work fine, however, it may
> have problem as above.
>
> When I read the /sys/src/9/pc/ether8139.c, I found the lines of
> "Error recovery for the various over/under-flow conditions may need work"
> phrase.   Does my problem relate to this remark?
>
> Kenji

I only have an 8139C and I've not ever seen an error of any kind on it,
hence my comment about work may be required if any error conditions happen.
Someone else asked me a similar question some months ago, and I suggested
putting in debugging prints in the driver wherever an error is detected.
That way you will see something if the card causes any problem and then
reboots the machine.

There may also be problems with the P4 processor, we don't have any here
to run on.

--jim

[9fans] Rest of the world waking up to filesystem based name models?

[ggm]

 From LWN, on some hubristical ottowa kernel summit

http://lwn.net/Articles/3327/

-----------
	:
	:

The other approach was presented by Patrick Mochel. As part of his ongoing
driver model work, he implemented "driverfs," the driver filesystem. driverfs
is a virtual filesystem initially developed as a debugging tool; it is a
convenient way of looking at the structure of the device tree. The facilities
provided by driverfs are similar to those provided by Rusty's scheme;
driverfs, too, is type-safe and easy to set up. It is also, for now, limited
to device drivers only; the question is whether it should be expanded to
handle kernel parameters in general.

While no conclusions were drawn in the session, driverfs looks (to your
author) like it is here to stay, since it so nicely incorporates the system's
structure in the filesystem it creates. It just needs to be expanded to cover
all of the other types of parameters in the system (i.e. VM, networking, etc.)
that are not directly associated with devices. A merger with some variant
Rusty's scheme would help in that regard, and seems likely at some point.

Linus pointed out that he would like to see a single, integrated filesystem
that includes all such information. Thus, for example, the "fsfs" that
provides filesystem information can include links to the underlying devices
holding those filesystems. Module information can link to the associated
driver and devices. Such a filesystem, he said, makes the linkages in the
system visible and explicit.

Eventually, /proc could be phased out in favor of a driverfs-like system, with
a "one file, one value" rule. This change really has to begin in 2.5, since
/proc has to be supported for at least one more stable kernel cycle. Expect to
see more activity in this area in the near future.

	:
	: