Hi,
The starfire driver in 2.4.0 (and 2.4.0-ac8) forgets to release its MMIO
region when the module is unloaded, which makes it impossible to load it a
second time. The attached patch fixed this problem; I tested it here on a
2-port card.
Please apply.
Thanks,
Ion
--
It is better to keep
On Mon, 22 Jan 2001 12:01:23 -0800 (PST), David Lang [EMAIL PROTECTED] wrote:
how about always_defragment (or whatever the option is now called) so that
your routing box always reassembles packets and then fragments them to the
correct size for the next segment? wouldn't this do the job?
It
On Thu, 25 Jan 2001 22:29:14 +0300 (MSK), [EMAIL PROTECTED] wrote:
Hello!
no problems. I simply mounted an NFS server with rsize=wsize=8192
and read a few files - I assume this is sufficient?
This is orthogonal.
Only TCP uses this and you need not to do something special
to test it.
On Thu, 25 Jan 2001, David S. Miller wrote:
Ion Badulescu writes:
I'm just wondering, if a card supports sg but *not* TX csum, is it worth
it to make use of sg? eepro100 falls into this category..
No, not worth it for now. In fact I'm going to mark that combination
(sg without csum
On Thu, 25 Jan 2001, David S. Miller wrote:
Ion Badulescu writes:
Well, yes and no. It's not quite orthogonal, because normally TCP
will never transmit fragmented packets, and it's precisely fragmented
packets that make the interesting case with a card that supports
hardware TCP
On Fri, 26 Jan 2001, David S. Miller wrote:
Firstly, I would not configure the card to drop packets with bad
checksums. If you do this, the errors do not propagate into the
correct ipv4 snmp tables, which is bad. Also consider the case where
the card has some bug and it erroneously
On Fri, 26 Jan 2001, Ion Badulescu wrote:
Besides, I've done some more testing last night, and there are some
problems. The FP doesn't seem to like tinygrams too much, every once in a
while (but *not* always) it decides to send one with a bad checksum. I'm
talking especially about telnet
On Sat, 27 Jan 2001 19:19:01 +1100, Andrew Morton [EMAIL PROTECTED] wrote:
The figures I quoted for the no-hw-checksum case were still
using scatter/gather. That can be turned off as well and
it makes it a tiny bit quicker.
Hmm. Are you sure the differences are not just noise? Unless you
On Sat, 27 Jan 2001 08:01:14 +, David Ford [EMAIL PROTECTED] wrote:
Does Linus or anyone object to raising the ksmg buffer from 16K to 32K?
4/5 systems I have now overflow the buffer during boot before init is
even launched.
Hmm, are you sure? man dmesg:
[...]
-sbufsize
/net/starfire.cSat Jan 27 12:44:35 2001
@@ -34,6 +34,10 @@
LK1.1.4 (jgarzik):
- Merge Becker version 1.03
+
+ LK1.2.0 (Ion Badulescu [EMAIL PROTECTED])
+ - Support hardware Rx/Tx checksumming
+ - Add GFP firmware taken from Adaptec's Netware
On Fri, 26 Jan 2001 18:41:37 +0100, Pavel Machek [EMAIL PROTECTED] wrote:
Hi!
Copying between vfat - vfat partitions is so slow. It seems
that it's vfat/msdos kernel driver problem because I tried to copy
I reported this years ago, with a 700 kB file on a floppy and
a 4 MB file on a
On Sat, 27 Jan 2001, jamal wrote:
starfire:
2.4.1-pre10+zerocopy, using sendfile(): 9.6% CPU
2.4.1-pre10+zerocopy, using read()/write(): 18.3%-29.6% CPU * why so much
variance?
What are your throughput numbers?
11.5kBps, quite consistently.
BTW, Andrew's new
On Thu, 17 May 2001 16:59:04 +0100, James Fidell [EMAIL PROTECTED] wrote:
I have two eepro100 interfaces in a machine, one rev 8, which works just
fine, and another rev 12, which appears as a device when the kernel boots
and can be configured with an IP address etc., but I can't get any data
On Fri, 18 May 2001, James Fidell wrote:
Is this a real card, or is it built-in on the motherboard?
It's a real card.
All right, that's good to know. Maybe I'll get one for myself, so I can
test new code on it -- right now I only have rev 9 and earlier cards.
For various reasons that
On Tue, 22 May 2001 [EMAIL PROTECTED] wrote:
This sounds like a bug I have heard before: some switches don't work with
the xircom card (well, our drivers for it) when doing full duplex.
Could you try the latest driver from
http://people.redhat.com/arjanv
which forces the card to
On Tue, 22 May 2001 20:10:41 +0100 (BST), Alan Cox [EMAIL PROTECTED] wrote:
Before you give up on the xircom thing, try the -ac kernel and set the box
up to use xircom_cb not xircom_tulip_cb
That might help a lot
It doesn't, it still performs poorly with any of the three available
drivers
On Tue, 29 May 2001 15:50:22 +0200, [EMAIL PROTECTED] wrote:
Today I tried to install freeswan1.9. After establishing ipsec tunnel with
my peer I got the wait_on_bh message.
(I cannot paste exactly because It is a production machine, and I restarted
it as fast as I could)
So what to do?
+2,10 @@
/*
Written 1998-2000 by Donald Becker.
+ Current maintainer is Ion Badulescu [EMAIL PROTECTED]. Please
+ send all bug reports to me, and not to Donald Becker, as this code
+ has been modified quite a bit from Donald's original version.
+
This software may
On Tue, 12 Sep 2000, Miquel van Smoorenburg wrote:
It is a tty, it's just that if you open(2) it, it doesn't become
your _controlling_ tty by default. See drivers/char/tty_io.c (I
think, that's from the top of my head).
Then I guess the kernel doesn't perform the proper setup when it opens
In article cs.lists.linux-kernel/8pmnfc$6p1$[EMAIL PROTECTED] you wrote:
Think Alan has made that clear. The way I read things the nfsv2 stuff needs
to be split out, into sets of small independent patches. This lets Alan
audit and control any bad patches easily. The nfsv3 changes should
On Wed, 13 Sep 2000, Miquel van Smoorenburg wrote:
Don't patch the kernel. If init gets the controlling tty, and you
press ^C - SIGINT gets sent to init - init interprets this as
ctrl-alt-del ! Yes, choosing SIGINT as the signal sent to init on
ctrl-alt-del was probably not very bright (and
On Fri, 15 Sep 2000, Russell King wrote:
There are two ways for a tty to become a controlling terminal:
1. First tty opened after a successful setsid() call.
2. using the TIOCSCTTY ioctl after a successful setsid() call.
Both will only suceed if the current process does not already have
In article [EMAIL PROTECTED] Daniel Phillips wrote:
It is important that all technology used in GPL software be free of
patent restrictions.
Indeed.
For another fine example of GPL technology covered by a parent, check out:
http://www.patents.ibm.com/details?pn=US06049528__
This a patent
Hi Alan,
The patch included below allows the kernel to unmount a filesystem whose
root entry is a symlink.
Let me give you a bit of background. In addition to more common 2-level
indirect mounts (also provided by autofs), amd allows for the so-called
"direct mounts". They are implemented by
On Tue, 3 Oct 2000, Alexander Viro wrote:
On 2.4 you can do them directly - no intermediate filesystem
needed. mount() with MS_BIND in flags will do the thing quite fine
(mount(old_dir,new_dir,NULL,MS_BIND,NULL); or mount --bind $old_dir
$new_dir; notices that old_dir doesn't have to
On Tue, 3 Oct 2000, Alexander Viro wrote:
Nope. Doesn't have to be a symlink - it can be a directory. Overmounted by
bind-mount - you can mount over a mountpoint.
And do a mount onto it while the kernel is waiting for revalidation? I'm
sorry, but that makes it even more dependent on the
On Mon, 26 Feb 2001 23:18:37 + (GMT), Alan Cox [EMAIL PROTECTED] wrote:
2.2.19pre15
[...]
o EEpro100 posted writes fix (Ion Badulescu)
All the credit goes to Andrey Savochkin and Don Becker -- I only applied
their 2.4.1 patch to 2.2.x..
Thanks,
Ion
a fool,
than to open it and remove all doubt.
---
--- /mnt/3/linux-2.2.19pre/drivers/net/starfire.c Mon Feb 26 21:56:30 2001
+++ linux-2.2.18/drivers/net/starfire.c Mon Feb 26 21:51:06 2001
@@ -49,6 +49,16 @@
LK1.2.4 (Ion Badulescu
On Wed, 28 Feb 2001, Alexander Viro wrote:
And disadvantages: you can't have broken symlinks.
This actually turns out to be quite a bit of a problem when one tries
to use bind mounts with autofs. For one thing, it's perfectly legal
to have /autofs/foo as a symlink to /autofs/bar/foo,
On Wed, 28 Feb 2001 13:07:29 -0500 (EST), Alexander Viro [EMAIL PROTECTED] wrote:
On Wed, 28 Feb 2001, David L. Parsley wrote:
Yeah, mount --bind is cool, I've been using it on one of my projects
today. But - maybe I'm just not thinking creatively enough - what are
the advantages of mount
On Sat, 10 Mar 2001 01:21:25 +1100, Andrew Morton [EMAIL PROTECTED] wrote:
+/**
+ * enable_nmi_watchdog - enables/disables NMI watchdog checking.
+ * @yes: If zero, disable
Ugh. I have a feeling that your chances to get Linus to accept this are
extremely slim.
Just have two functions,
On Mon, 12 Mar 2001 22:02:12 -0500, Jeff Garzik [EMAIL PROTECTED] wrote:
It is highly recommended to always compile with CONFIG_ISAPNP=y due to
these differences. If you grep around for CONFIG_ISAPNP versus
CONFIG_ISAPNP_MODULE, you'll see that many drivers are woefully
unprepared for
On Tue, 20 Mar 2001 15:19:37 -0500, Doug Ledford [EMAIL PROTECTED] wrote:
Why would esd get a short write() unless it is opening the file in non
blocking mode (which I didn't see when I was working on the i810 sound
driver)? If esd is writing to a file in blocking mode and that write is
On Mon, 20 Nov 2000 17:56:20 -0700, Jeff V. Merkey [EMAIL PROTECTED] wrote:
also, the rpc.lockd program is reporting an error when invoked from the
System V init startup scripts:
lockd: lockdsvc: invalid argument
lockd is a kernel thread nowadays, remove it from your nfsd start script
or
On Thu, 23 Nov 2000 13:52:52 +0100, Guest section DW [EMAIL PROTECTED] wrote:
On Thu, Nov 23, 2000 at 05:03:00PM +1100, Neil Brown wrote:
Oh, good. It's not just me and Tigran then.
You have it all backwards. It would be good if it were
just you and Tigran. Unfortunately it also hits me.
On Thu, 23 Nov 2000, Andre Hedrick wrote:
Since there have been not kernel changes to the driver that effect the
code since 2.4.0-test5 or test6 and it now randomly shows up after five or
six revisions out from the change, and the changes were chipset only.
Please make your point.
My
On Fri, 24 Nov 2000, Mohammad A. Haque wrote:
Yep. Unless of course they are SCSI with an identity crisis =P
Ok. Are there any IDE-related errors in your logs prior to getting the f/s
corruption? They could be relevant no matter how much time passed between
them and the first signs of
On Fri, 24 Nov 2000 06:20:33 +0100 (MET), [EMAIL PROTECTED] wrote:
Reading specs from /usr/lib/gcc-lib/i486-suse-linux/2.95.2/specs
gcc version 2.95.2 19991024 (release)
% /usr/bin/gcc -Wall -O2 -o bug bug.c; ./bug
0x8480
% /usr/gcc/aeb/bin/gcc -v
Reading specs from
On Tue, 28 Nov 2000 23:37:49 -0500, Mohammad A. Haque [EMAIL PROTECTED] wrote:
Ok, I just found a file with about the first 4k of it filled with nulls
(^@^@). No telling if this was a result of what originally started this
thread or not. I hadn't accessed that file since Nov 9th.
1k- or
On Wed, 29 Nov 2000, Mohammad A. Haque wrote:
[mhaque@viper mhaque]$ df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda3 12737128 9988400 2101712 83% /
/dev/hda246668 15106 29153 35% /boot
/dev/hdd1 44327416
On Thu, 30 Nov 2000 01:28:13 +0100 (MET), [EMAIL PROTECTED] wrote:
(I am still a bit curious: did other people see this?
Did someone fix a known problem with net(filter) or say /proc?
It would be a pity if this disappeared by coincidence
and appears again next month.)
No problems here, and
On Fri, 1 Dec 2000 17:51:09 +0800, Andrey Savochkin [EMAIL PROTECTED] wrote:
I've been promised that this issue would be looked up in Intel's errata by
people who had the access to it, but I haven't got the results yet.
There is nothing relevant in the errata, unfortunately...
The card
On 1 Dec 2000 21:09:25 -0800, Linus Torvalds [EMAIL PROTECTED] wrote:
Even then XFree86 does something bad with DPMS, and will lock up the
graphics chipset when it tries to shut down the flat panel display.
Solution: don't enable DPMS is XF86Config. That's an XFree86 problem,
but happily
On Mon, 4 Dec 2000, Andrey Savochkin wrote:
There is nothing relevant in the errata, unfortunately...
Do you have it?
I have the manual in the office, so I can look at it again in a couple of
days. I've used it to hack on the BSDI driver...
The sympthomes are that the card triggers Flow
On Tue, 5 Dec 2000 18:40:00 -0500 , Boerner, Brian [EMAIL PROTECTED] wrote:
I get another oops. I'm not very efficient at reading these messages. To bad
the oops-tracing.txt file isn't in a little more detail. It seems you have
to be quite knowledgeable of the inner workings of the Linux
On Wed, 6 Dec 2000, Andrey Savochkin wrote:
The sympthomes are that the card triggers Flow Control Pause condition (and
interrupt) on the last stages of the initialization or right after.
And it happens with flow control being explicitly turned off.
High network load considerably
On Fri, 8 Dec 2000, Udo A. Steinberg wrote:
+ /* disable advertising the flow-control capability */
+ sp-advertising = ~0x0400;
+ mdio_write(ioaddr, sp-phy[0] 0x1f, sp-advertising);
^^^
On Mon, 11 Dec 2000, Udo A. Steinberg wrote:
Anton Altaparmakov wrote:
The problem here only ever happens at initialisation/first packets. Once the
network interface has been initialised properly it never produces those
messages anymore. Usually it helps to shut the NIC down with ifconfig
On Thu, 14 Dec 2000 07:15:04 -0500, Mohammad A. Haque [EMAIL PROTECTED] wrote:
Were you connected to a network or receiving/sending anything?
ip_defrag is broken -- there is an obvious NULL pointer dereference
in it, introduced in test12. It doesn't hit normally, because of
path MTU discovery,
On Thu, 14 Dec 2000, David S. Miller wrote:
Date: Thu, 14 Dec 2000 10:38:01 -0800
From: Ion Badulescu [EMAIL PROTECTED]
I won't venture a fix, as I don't know the networking code well
enough. So far, no networking maintainer has had anything to say
about this bug
On Thu, 14 Dec 2000, David S. Miller wrote:
If you turn off netfilter, ip_conntrack, etc. does the OOPS still
occur?
I'm afraid I won't be able to answer this question, since I'm leaving for
a 3-week vacation in about 50 minutes and I need my firewall functional
until then. :-) Maybe other
This is the 4th time I'm getting this oops with 2.4.0, and it always
happens when something (usually updatedb) is stressing my SCSI disk.
The ksymoops trace is correct, I also ran it against saved versions of
/proc/ksyms and /proc/modules:
ksymoops 0.7c on i586 2.4.0. Options used
-V
In article [EMAIL PROTECTED] you wrote:
make oldconfig clean dep all install modules modules_install
Makefiles are puzzling, sometimes.
make dep does something that's basically equivalent to changing
the Makefiles. However, make doesn't re-read them, so all the
targets after "dep" will be
On Wed, 8 Nov 2000 21:15:38 -0500, Scott McDermott [EMAIL PROTECTED] wrote:
Sasi Peter on Tue 7/11 23:28 +0100:
I'm getting this under moderate NFS load:
Nov 6 17:39:56 iq kernel: svc: server socket destroy delayed (sk_inuse: 1)
Nov 6 17:40:08 iq kernel: svc: unknown program 100227 (me
On Mon, 13 Nov 2000 12:18:33 -0800, David Hinds [EMAIL PROTECTED] wrote:
The effect of "ifconfig eth0 -multicast" (which should be a no-op) is
that it calls set_rx_mode() with the same set of parameters it was
called with before. Doing this one or more times may kick the card so
that it
On Sat, 18 Nov 2000 12:23:05 -0800 (PST), Andre Hedrick [EMAIL PROTECTED] wrote:
If anyone is suffering from the dreaded "dmaproc error 14: unsupported"
error and want to test a code that could get you out of that deadlock
please speak up.
Basically this is an Intel 440BX PIIX4 issues,
On Tue, 17 Apr 2001 17:30:46 +0100 (BST), Steve Hill [EMAIL PROTECTED] wrote:
Not sure - I've never tried initing more than 3 of the DP83815 cards in a
single machine. (I am using Cobalt Qube 3's, which have 2 DP83815's on
the motherboard, and a single PCI slot which I have installed a
Becker version 1.03
+
+ LK1.2.1 (Ion Badulescu [EMAIL PROTECTED])
+ - Support hardware Rx/Tx checksumming
+ - Use the GFP firmware taken from Adaptec's Netware driver
+
+ LK1.2.2 (Ion Badulescu)
+ - Backported to 2.2.x
+
+ LK1.2.3 (Ion Badulescu)
+ - Fix
Merge Becker version 1.03
+
+ LK1.2.1 (Ion Badulescu [EMAIL PROTECTED])
+ - Support hardware Rx/Tx checksumming
+ - Use the GFP firmware taken from Adaptec's Netware driver
+
+ LK1.2.2 (Ion Badulescu)
+ - Backported to 2.2.x
+
+ LK1.2.3 (Ion Badulescu)
+
On Thu, 19 Apr 2001, Roberto Nibali wrote:
A 2.2.x UP-APIC patch would maybe improve things here while under
heavy load. I'm using such boxes as packetfilters. All quadboards
get IRQ 11 which is rather nasty considering a possible throughput
of 40Mbit/s per NIC.
The UP-APIC wouldn't help
On Fri, 20 Apr 2001, Jeff Garzik wrote:
Have you tried loading the drivers as modules? You might have more luck
with that approach. Space.c was designed at a time when having 4 NIC's in
a PC was "pushing the limits"...
2.2.recent has module_init/exit, so you don't even need Space.c.
On Fri, 20 Apr 2001, Roberto Nibali wrote:
Hmm, but doesn't the code in 2.4.x improve the hard IRQ signal delivery
even for UP systems with a local APIC table? I have an APIC aware board
but I have only got 1 CPU on it and I currently need to run 2.2 kernel.
But if you tell me that there is
On Fri, 20 Apr 2001, Jeff Garzik wrote:
Check again. drivers/net builds a .a, not a .o. Trust me, I've tried.
Sure, but if you are patching anyway, it much better to fix that than
hack space.c :)
Well, I remember asking Alan if he'd prefer it done that way, and not
getting a reply back.
On Fri, 20 Apr 2001, Jeff Garzik wrote:
Sorry, I was talking about a local patch not a global patch. If a user
must patch their 2.2 kernel to get the starfire driver working anyway,
then adding a change to do s/.a/.o/ on Makefiles would be simple.
People don't need to patch *anything* to
+
+ LK1.2.1 (Ion Badulescu [EMAIL PROTECTED])
+ - Support hardware Rx/Tx checksumming
+ - Use the GFP firmware taken from Adaptec's Netware driver
+
+ LK1.2.2 (Ion Badulescu)
+ - Backported to 2.2.x
+
+ LK1.2.3 (Ion Badulescu)
+ - Fix the flaky mdio interface
-
+
LK1.1.4 (jgarzik):
- Merge Becker version 1.03
+
+ LK1.2.1 (Ion Badulescu [EMAIL PROTECTED])
+ - Support hardware Rx/Tx checksumming
+ - Use the GFP firmware taken from Adaptec's Netware driver
+
+ LK1.2.2 (Ion Badulescu)
+ - Backported to 2.2.x
On Fri, 20 Apr 2001, Roberto Nibali wrote:
No, it's not a bug but thank you for this tip. It's just a put-on limitation
in the driver itself:
--- starfire.c~ Fri Apr 20 18:48:05 2001
+++ starfire.cFri Apr 20 18:27:20 2001
@@ -308,7 +308,7 @@
void (*resume)(struct
On 23 Apr 2001 12:54:22 -0600, Eric W. Biederman [EMAIL PROTECTED] wrote:
I'll include it again. I had it attached as a plain text attachment,
I don't know if that is a problem or not.
Actually it was attached as text/x-patch, not as text/plain... so
pine certainly refused to display it
On 25 Apr 2001 00:39:43 +0200, Trond Myklebust [EMAIL PROTECTED] wrote:
== apark [EMAIL PROTECTED] writes:
Hi, Recently upgraded to 2.2.19, along with new
nfs-utils(0.3.1). But I have a program that requires a
exclusive write lock on a NFSed directory. When I was using
Hi Alan,
Over the last week I've tried to upgrade a 4-CPU Xeon box to 2.2.19, but
the it keeps locking up whenever the disks are stresses a bit, e.g. when
updatedb is running. I get the following messages on the console:
wait_on_bh, CPU 1:
irq: 1 [1 0]
bh: 1 [1 0]
[8010af71]
over and over
On Sun, 29 Apr 2001 01:16:04 +0200, bert hubert [EMAIL PROTECTED] wrote:
On Sat, Apr 28, 2001 at 02:21:29PM -0700, Ion Badulescu wrote:
Hi Alan,
Over the last week I've tried to upgrade a 4-CPU Xeon box to 2.2.19, but
the it keeps locking up whenever the disks are stresses a bit, e.g. when
On Mon, 30 Apr 2001, Alan Cox wrote:
I also have reports but related to the network driver updates. So I
suggest to try again with 2.2.19 but with the drivers/net/* of 2.2.18.
Thats probably a better starting point. Its easier to back out than the VM
changes and it would also explain the
On Mon, 30 Apr 2001, Mohammad A. Haque wrote:
Just to give another data point...
2.2.19 + LVM patches - dual P3 550
1 GB RAM
eepro100
ncr53c8xx scsi
mylex accelRAID 1100 RAID controller
We've transferred around 1 GB of stuff over the network and about 200 GB
between two raids w/o
On Mon, 30 Apr 2001, Ion Badulescu wrote:
Ok, so onto the binary search through the 2.2.19pre series...
I think it started in 2.2.19pre10. I can reproduce the hang on pre10,
quite easily, but I couldn't reproduce it on pre5, pre7 and pre9. I'll try
a few other pre versions, just to make sure
On Tue, 1 May 2001, Alan Cox wrote:
Ok the main candidates there would be:
The sunrpc/nfs changes
I'm currently testing this one -- just preparing to reboot pre9 + these
changes.
EEpro100/starfire
eepro100 is in use. But that patch is harmless.
aic7xxx
Loaded but
On Tue, 1 May 2001, Ion Badulescu wrote:
aic7xxx
Loaded but not used, no devices attached to it.
Scratch that, I was confusing it with another box. There is no trace of
aic7xxx on this system.
Ion
--
It is better to keep your mouth shut and be thought a fool,
than
On Tue, 1 May 2001, Ion Badulescu wrote:
Right now I'm pretty sure it's the NFS/SunRPC changes, but I'll know for
sure in about 30 minutes.
As I suspected, 2.2.19pre9 + the NFS/SunRPC changes locked up under load
with the now familiar:
wait_on_bh, CPU 2:
irq: 1 [0 0]
bh: 1 [0 1
On Tue, 1 May 2001, Ion Badulescu wrote:
I'll do another test, 2.2.18 + the NFS/SunRPC changes, and see how it
goes. Hopefully they'll apply easily...
As I suspected, 2.2.18 + all the NFS/NFSd/SunRPC changes present in
2.2.19pre10 locks up with wait_on_bh as soon as I run ls -lR on a large
On Tue, 1 May 2001, Trond Myklebust wrote:
Did you apply the following patch which I put out on the lists a
couple of weeks ago?
No, I was testing with 2.2.19 and then I started going back into the
2.2.19pre series until I found the culprit.
I'll give your patch a spin tomorrow, after I
On Tue, 1 May 2001, Trond Myklebust wrote:
I'll give your patch a spin tomorrow, after I catch some
zzz's. :-)
Right you are.
And indeed, the tcp-hang patch fixed the problem! Thanks a lot!
FYI I've now put up those patches of which I am aware against 2.2.19
on
On Wed, 6 Jun 2001 13:20:41 -0400, Tom Sightler [EMAIL PROTECTED] wrote:
2.4.5-ac9
o Fix xircom_cb problems with some cisco kit (Ion Badulescu)
I'm not sure what this is supposed to fix, but it makes my Xircom
RBEM56G-100 almost useless on my network at the office. Actually, I can't
On Wed, 6 Jun 2001, Tom Sightler wrote:
At home where I have a 10Mb half-duplex hub connection all of the drivers work
properly.
All right, that's expected.
At work where I have a 10/100Mb full-duplex switch connection the drivers work
exactly as I described before:
2.4.4-ac11 -- mostly
On Thu, 7 Jun 2001, Tom Sightler wrote:
Transferring files between the eepro100 machine running 2.4.2-ac11 and my
laptop produced a result of 2.24MB/s for sending and 2.13MB/s recieving the
file.
Transfering files between the Alteon Gigabit machine running 2.2.19 and my
laptop resulted
On Fri, 8 Jun 2001, Tom Sightler wrote:
OK, I tried your patch, it did fix the problem where pump wouldn't
pull an IP address, but I'm still having the problem where my ping
times go nuts. I've attached an example, it's 100% repeatable on my
network at work. It was so bad I couldn't get
On Wed, 6 Jun 2001, Keith Owens wrote:
Nicely spotted. The X3201-3 Software Specification says nothing about
the segment bits for the filter, instead the information is tucked away
in the 21143 PCI/CardBus 10/100Mb/s Ethernet LAN Controller Hardware
Reference Manual. So Xircom have a
On Fri, 2 Feb 2001 16:46:45 + (GMT), Alan Cox [EMAIL PROTECTED] wrote:
:It is the original one. I'll try with the -69:
:
With 2.96-69 the reiserfs seems to work well.
Sorry for the confusion, I forgot to upgrade the gcc on my machine.
Excellent. Im just glad to know its a
On Fri, 2 Feb 2001, Alan Cox wrote:
Oh I can see why Hans wants to cut down his bug reporting load. I can also
say from experience it wont work. If you put #error in then everyone will
mail him and complain it doesnt build, if you put #warning in nobody will
read it and if you dont put
On Sat, 3 Feb 2001, Hans Reiser wrote:
That said, my opinion is that bug reporting load is not as important as bug
avoidance, but I understand your position has merit to it also.
If you do it, at least restrict it to 2.96.0. Maybe Red Hat will see the
light and release a fixed 2.96.1...
Ion
On Wed, 07 Feb 2001 11:48:32 +0100, Stefan Majer [EMAIL PROTECTED] wrote:
Hi All
I installed a Adaptec Quad Port Ethernet Adapter called Quartet64 and
after compiling 2.4.1
with starfire support i got the following messages in syslog
after
ifconfig eth2 172.17.1.4 netmask
Feb 7 17:38:50 2001
@@ -1166,6 +1166,11 @@
W: http://www.stallion.com
S: Supported
+STARFIRE/DURALAN NETWORK DRIVER
+P: Ion Badulescu
+M: [EMAIL PROTECTED]
+S: Maintained
+
STARMODE RADIO IP (STRIP) PROTOCOL DRIVER
W: http://mosquitonet.Stanford.EDU/strip.html
S
@@ -916,6 +916,11 @@
W: http://www.stallion.com
S: Supported
+STARFIRE/DURALAN NETWORK DRIVER
+P: Ion Badulescu
+M: [EMAIL PROTECTED]
+S: Maintained
+
STARMODE RADIO IP (STRIP) PROTOCOL DRIVER
W: http://mosquitonet.Stanford.EDU/strip.html
S: Unsupported ?
diff -urNX
On Thu, 8 Feb 2001 14:53:55 +0900, Augustin Vidovic [EMAIL PROTECTED] wrote:
--- linux-2.4.1/drivers/net/eepro100.c Sun Jan 28 03:40:14 2001
+++ linux-2.4.1-vido1/drivers/net/eepro100.cThu Feb 8 14:08:49 2001
@@ -815,7 +815,7 @@
sp-phy[0] = eeprom[6];
sp-phy[1] =
On Thu, 8 Feb 2001, Alan Cox wrote:
It's the printk that gets it wrong, although that's harmless.
Intel's documentation states that the bug does NOT exist if the
bits 0 and 1 in eeprom[3] are 1. Thus, the workaround is correct,
the printk is wrong.
So why does it fix the problem for
On Thu, 8 Feb 2001 20:15:39 +0900, Augustin Vidovic [EMAIL PROTECTED] wrote:
So what _were_ those messages? Can you post them?
No I can't because they were suppressed by the syslogd (DOS protection), only
their number being reported (several thousands every few seconds).
syslogd does not
On Thu, 8 Feb 2001, Augustin Vidovic wrote:
This suppression of thousands of lines was described as a DOS-protection
in the docs I read.
Still, there should be something before these suppressed messages started.
With my patch, the test becomes (eeprom[3] 0x03), which is not null
for every
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
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 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
1 - 100 of 302 matches
Mail list logo
