Kok, Auke wrote:
Jeff Garzik wrote:
Bill Davidsen wrote:
Adrian Bunk wrote:
This patch contains the planned removal of the eepro100 driver.
Are the e100 people satisfied that e100 now handles all known cases? I
Nope. There are still e100 work outstanding that means we cannot kill
eepro100
Jeff Garzik wrote:
> Bill Davidsen wrote:
>> Adrian Bunk wrote:
>>> This patch contains the planned removal of the eepro100 driver.
>>>
>> Are the e100 people satisfied that e100 now handles all known cases? I
>
> Nope. There are still e100 work outstandi
Bill Davidsen wrote:
Adrian Bunk wrote:
This patch contains the planned removal of the eepro100 driver.
Are the e100 people satisfied that e100 now handles all known cases? I
Nope. There are still e100 work outstanding that means we cannot kill
eepro100.
Jeff
-
To unsubscribe
Adrian Bunk wrote:
This patch contains the planned removal of the eepro100 driver.
Are the e100 people satisfied that e100 now handles all known cases? I
remember that there were corner cases e100 didn't handle, have they all
been fixed?
--
Bill Davidsen <[EMAIL PROTECTED]>
&q
On 01/10/2007, Kok, Auke <[EMAIL PROTECTED]> wrote:
...
>
> is this actually a problem? everybody should be running e100. I'm surprised
> to see
> a patch for eepro100, just before it gets removed...
>
The patch is actually about a year old, it just never got merged
[EMAIL PROTECTED] wrote:
> The patch titled
> eepro100: Avoid potential NULL pointer deref in speedo_init_rx_ring()
> has been removed from the -mm tree. Its filename was
> eepro100-avoid-potential-null-pointer-deref-in-speedo_init_rx_ring.patch
>
> This patch was
On Mon, Aug 27, 2007 at 02:58:05PM -0700, Kok, Auke wrote:
> Adrian Bunk wrote:
>...
>> This patch has been sent on:
>> - 14 Aug 2007
>> - 29 Jul 2007
>
> currently we won't have e100 fixed up for ARM in 2.6.23, so removing this
> for 2.6.24 sounds a bit premature. Maybe 2.6.25. Can you
> resched
Adrian Bunk wrote:
This patch contains the planned removal of the eepro100 driver.
Signed-off-by: Adrian Bunk
you lost your e-mail address? :)
---
This patch has been sent on:
- 14 Aug 2007
- 29 Jul 2007
currently we won't have e100 fixed up for ARM in 2.6.23, so removing thi
Add file pattern to MAINTAINER entry
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
diff --git a/MAINTAINERS b/MAINTAINERS
index 84f6f6b..208bfea 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1737,6 +1737,7 @@ EEPRO100 NETWORK DRIVER
P: Andrey V. Savochkin
M: [EMAIL PROTECT
On Fri 2007-07-13 21:11:28, Kok, Auke wrote:
> [adding netdev]
>
> David Fries wrote:
> >When I did a software suspend to disk then resumed the Intel network
> >card using eepro100 driver would be unable to transmit packets. I
> >tracked this down and found a reg
On Fri, Jul 13, 2007 at 09:11:28PM -0700, Kok, Auke wrote:
> [adding netdev]
>
> David Fries wrote:
> >When I did a software suspend to disk then resumed the Intel network
> >card using eepro100 driver would be unable to transmit packets. I
> >tracked this down and f
[adding netdev]
David Fries wrote:
When I did a software suspend to disk then resumed the Intel network
card using eepro100 driver would be unable to transmit packets. I
tracked this down and found a register write after the print message
"DP83840 specific setup" which wasn't
When I did a software suspend to disk then resumed the Intel network
card using eepro100 driver would be unable to transmit packets. I
tracked this down and found a register write after the print message
"DP83840 specific setup" which wasn't being executed when the system
was rest
On 7/10/07, Bill Davidsen <[EMAIL PROTECTED]> wrote:
If there were any benefit to removing a working driver I would at least
be able to see it as a resources issue, but as far as I can see you just
seem to have a personal preference for the e100 driver and want to force
others to use it because y
idate various accelerated video drivers on systems running mostly text
console, never check sound options on systems with an audio application,
etc. After I tried the e100 driver on the first few systems and found
issues (which may be resolved by now) I went back to eepro100 and used what
worked
Kok, Auke wrote:
as discussed before we really want to avoid having (1) an unmaintained
bitrotting driver for X and (2) one that should work because people are
being paid to take care of it.
The community has always encouraged us to work with us fixing the last
issues in e100 to make it work
>
>>> If you think the e100 driver fixes your problems use it and be happy. But
>>> since you don't have to test system behavior with the new driver, and you
>>> won't be called at night or on weekends if it doesn't work, do the rest
>>&g
ve to test system behavior with the new driver, and you
won't be called at night or on weekends if it doesn't work, do the rest of
the world a favor and stop taking out things we know to work! Leaving in
the eepro100 causes no work for you, and even if e100 works perfectly it
needs to be v
avior with the new driver, and you
won't be called at night or on weekends if it doesn't work, do the rest of
the world a favor and stop taking out things we know to work! Leaving in
the eepro100 causes no work for you, and even if e100 works perfectly it
needs to be validated in any s
>>> This patch contains the overdue removal of the eepro100 driver.
>>>>
>>>> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>>>>
>>> The hardware supported by this driver is still in use, thanks. It's
>>> probably easier to l
Please do not make unnecessary kernel changes which require changes in
our systems.
Kok, Auke wrote:
Bill Davidsen wrote:
Adrian Bunk wrote:
This patch contains the overdue removal of the eepro100 driver.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
The hardware supported by this
Bill Davidsen wrote:
Adrian Bunk wrote:
This patch contains the overdue removal of the eepro100 driver.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
The hardware supported by this driver is still in use, thanks. It's
probably easier to leave the eepro100 driver in than find
Adrian Bunk wrote:
This patch contains the overdue removal of the eepro100 driver.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
The hardware supported by this driver is still in use, thanks. It's
probably easier to leave the eepro100 driver in than find anyone who
wants to inve
Kok, Auke wrote:
this needs to be resceduled for 2.6.24 (at least). We're hoping to merge
the proposed changes (still being worked on) in .23. Milton Miller and
David Acker are working on that.
Quite agreed.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kern
Adrian Bunk wrote:
This patch contains the overdue removal of the eepro100 driver.
...
this needs to be resceduled for 2.6.24 (at least). We're hoping to merge the
proposed changes (still being worked on) in .23. Milton Miller and David Acker
are working on that.
Auke
-
To unsubs
Brandeburg, Jesse wrote:
Roberto Nibali wrote:
Sounds sane to me. My overall opinion on eepro100 removal is that
we're not there yet. Rare problem cases remain where e100 fails
but eepro100 works, and it's older drivers so its low priority for
everybody.
Needs to happ
Roberto Nibali wrote:
>>> Sounds sane to me. My overall opinion on eepro100 removal is that
>>> we're not there yet. Rare problem cases remain where e100 fails
>>> but eepro100 works, and it's older drivers so its low priority for
>>> everybody.
Sounds sane to me. My overall opinion on eepro100 removal is that we're
not there yet. Rare problem cases remain where e100 fails but eepro100
works, and it's older drivers so its low priority for everybody.
Needs to happen, though...
It seems that several Tyan Opteron base system
On 3/28/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
Kok, Auke wrote:
Sounds sane to me. My overall opinion on eepro100 removal is that we're
not there yet. Rare problem cases remain where e100 fails but eepro100
works, and it's older drivers so its low priority for everybody.
Kok, Auke wrote:
Bill Davidsen wrote:
Adrian Bunk wrote:
This patch contains the scheduled removal of the eepro100 driver.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
This keeps coming around, but I haven't seen an answer to the
questions raised by Eric Piel or Kiszka. I d
Bill Davidsen wrote:
Adrian Bunk wrote:
This patch contains the scheduled removal of the eepro100 driver.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
This keeps coming around, but I haven't seen an answer to the questions
raised by Eric Piel or Kiszka. I do know that e100 did
Adrian Bunk wrote:
This patch contains the scheduled removal of the eepro100 driver.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
This keeps coming around, but I haven't seen an answer to the questions
raised by Eric Piel or Kiszka. I do know that e100 didn't work on som
On 1/2/07, Eric Piel <[EMAIL PROTECTED]> wrote:
Hi, I've been using e100 for years with no problem, however more by
curiosity than necessity I'd like to know how will be handled the
devices which are (supposedly) supported by eepro100 and not by e100?
According to "
Adrian Bunk wrote:
> This patch contains the scheduled removal of the eepro100 driver.
>
I'm sorry to disturb the schedule, but I'm not sure right now if this
pending issue of the e100 was meanwhile solved or declared a non-issue:
http://lkml.org/lkml/2006/9/8/105
Auke, can you
02.01.2007 22:57, Adrian Bunk wrote/a écrit:
This patch contains the scheduled removal of the eepro100 driver.
Hi, I've been using e100 for years with no problem, however more by
curiosity than necessity I'd like to know how will be handled the
devices which are (supposedly) su
eachable
> >
> > There were no such error in 2.6.13-rc2
> odd, both e100 and eepro100 are broken? This might indicate something
> wierd with the pci layer. Don't know what might cause the Network is
> unreachable...
It works fine here... latest .git from yesterday
On Wed, 13 Jul 2005 23:28:15 -0700, Jesse Brandeburg <[EMAIL PROTECTED]> wrote:
>On 7/13/05, Mikhail Kshevetskiy <[EMAIL PROTECTED]> wrote:
>> symptom
>> ===
>> modprobe e100
>> ifconfig eth0 netmask
>>
>> result:
>> ===
>> SIOCADDRT: Network is unreachable
>>
>> There were no such err
On 7/13/05, Mikhail Kshevetskiy <[EMAIL PROTECTED]> wrote:
> symptom
> ===
> modprobe e100
> ifconfig eth0 netmask
>
> result:
> ===
> SIOCADDRT: Network is unreachable
>
> There were no such error in 2.6.13-rc2
odd, both e100 and eepro100 are br
Hi,
>> Are both drivers supported by their authors, etc.
> eepro100 is unmaintained and going away.
Well, good to know then, I am switching right now.
Thanks.
> Jeff
Maciej
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messa
On Fri, Feb 18, 2005 at 08:01:11PM +0100, Maciej Soltysiak wrote:
> Hello,
>
> Can anyone shed some light upon the state of development
> of these drivers?
> I mean: the set of supported both NIC and kernel features.
> Are both drivers supported by their authors, etc.
eepro1
Hello,
Can anyone shed some light upon the state of development
of these drivers?
I mean: the set of supported both NIC and kernel features.
Are both drivers supported by their authors, etc.
Looking for answers that would lead to a conclusion which to use.
Regards,
Maciej
-
To unsubscribe from
On Tue, 2005-02-01 at 11:09, linux-os wrote:
> You just need to load mii first. Both of these drivers are working
> fine on 2.6.10.
Huh? You have 82556 cards working with eepro100 or e100 on 2.6.10?
Neither driver will work on any card without mii loaded.
-scott
-
To unsubscribe fro
On Tue, 1 Feb 2005, Scott Feldman wrote:
On Tue, 2005-02-01 at 04:48, Meelis Roos wrote:
See if eepro100 works on your 82556 cards. I would be surprised if it
does. If it does, maybe it's not that much trouble to add support to
e100. Let us know.
I did add the PCI ID to e100 to to try it
On Tue, 2005-02-01 at 04:48, Meelis Roos wrote:
> > See if eepro100 works on your 82556 cards. I would be surprised if it
> > does. If it does, maybe it's not that much trouble to add support to
> > e100. Let us know.
>
> I did add the PCI ID to e100 to to try
See if eepro100 works on your 82556 cards. I would be surprised if it
does. If it does, maybe it's not that much trouble to add support to
e100. Let us know.
I did add the PCI ID to e100 to to try it with both drivers.
In short: both eepro100 and e100 have problems loading the eeprom and
On Thu, Jan 27, 2005 at 03:45:40PM -0500, Jeff Garzik wrote:
>
> (GregKH cc'd for his deprecated list)
It's a file in the Documentation/ directory, feel free to just patch it,
adding entries for these drivers.
thanks,
greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-ke
On Fri, 2005-01-28 at 01:33, Meelis Roos wrote:
> eepro100 also drives 82556-based cards. I have a couple of EtherExpress
> PRO/100 Smart cards, Intel identifier is PILA8485, PCI ID is 8086:1228.
> e100 doesn't support them, I'm told eepro100 works (I have not verified
> it m
eepro100 also drives 82556-based cards. I have a couple of EtherExpress
PRO/100 Smart cards, Intel identifier is PILA8485, PCI ID is 8086:1228.
e100 doesn't support them, I'm told eepro100 works (I have not verified
it myself). I can probably get a card or to for testing with Linux.
On Thu, 27 Jan 2005 17:58:37 -0800
Scott Feldman <[EMAIL PROTECTED]> wrote:
> eepro100 does a copy if pkt_len < rx_copybreak, otherwise it send up the
> skb and allocates and links a new one in it's place (see
> speedo_rx_link).
My bad, you're right. So I wonder too
On Thu, 2005-01-27 at 16:48, David S. Miller wrote:
> On Fri, 28 Jan 2005 00:14:30 +
> Russell King <[EMAIL PROTECTED]> wrote:
>
> > The fact of the matter is that eepro100.c works on ARM, e100.c doesn't.
> > There's a message from me back on 30th June 200
On Fri, 28 Jan 2005 00:14:30 +
Russell King <[EMAIL PROTECTED]> wrote:
> The fact of the matter is that eepro100.c works on ARM, e100.c doesn't.
> There's a message from me back on 30th June 2004 at about 10:30 BST on
> this very list which generated almost no inter
On Fri, Jan 28, 2005 at 12:14:30AM +, Russell King wrote:
> The fact of the matter is that eepro100.c works on ARM, e100.c doesn't.
Hmmm, I recall e100 working fine on a Radisys ENP-2611, which has a
IXP2400 (xscale) in big-endian mode, running 2.6. This particular
board had its roo
the chip may be modifying the RFD
while the CPU is accessing it. Adding extra sync calls does not fix
it because as far as I can see, there's nothing to tell the chip "don't
write to this RFD because any changes the CPU is making right now will
overwrite the chips own changes."
The
On Thu, 27 Jan 2005 22:57:25 +
Russell King <[EMAIL PROTECTED]> wrote:
> Has e100 actually been fixed to use the PCI DMA API correctly yet?
It seems to be doing the right thing. I see the DMA sync calls
(properly using cpu vs. device syncing variants) at the right
spots, and the only thing t
On Thu, Jan 27, 2005 at 03:45:40PM -0500, Jeff Garzik wrote:
> 3) eepro100
>
> Unmaintained; users should use e100.
>
> When I last mentioned eepro100 was going away, I got a few private
> emails saying complaining about issues not yet taken care of in e100.
> eepro10
On Thu, Jan 27, 2005 at 03:45:40PM -0500, Jeff Garzik wrote:
> 1) iphase (iph5526 a.k.a. drivers/net/fc/*)
>
> Been broken since 2.3 or 2.4. Only janitors have kept it compiling.
No, it doesn't even compile, and didn't so for more than two years.
-
To unsubscribe from this list: send the line "
3 or 2.4. Only janitors have kept it compiling.
2) xircom_tulip_cb
Unmaintained, and does not work for all xircom 32bit cards. xircom_cb,
on the other hand, works for ALL xircom 32bit cards.
3) eepro100
Unmaintained; users should use e100.
When I last mentioned eepro100 was going away, I got a few
Hiho.. While working on some code which tries to monitor physical link status
for ethernet interfaces, I noticed that apparently under the 2.4 kernel, the
eepro100 driver does not reflect link status with the IFF_RUNNING flag as it
used to under 2.2.x.
It looks like a bit of the code in
ECTED]>
Subject: [PATCH] eepro100 PCI/PM fixes
Hi!
Appened patch against 2.4.7-pre3 fixes a couple of issues in the eepro100
driver. I realize some of the changes may be not appropriate due to
compatibility concerns or whatever.
o call pci_enable_device before accessing resources/irqs.
On Sat, 30 Jun 2001, Dylan Griffiths wrote:
> I'd love to do some of this, but since the box is now being shipped to a
> colo facility in New York, I don't really have a choice in the matter.
>
> Hopefully someone here doing SMP + EEPro100 can see if they can reproduce
>
bove doesn't work, add `nmi_watchdog=1' to the kernel boot
>options. That may catch the lockup.
>
> 3: Replace the NIC with another eepro100. If the problem goes away then
>chuck the old one.
>
> 4: Replace the NIC with one of a different type (ie: swap with th
I have a lock problem on a dual P3 1GHz w/1GB RAM setup and 2.4.5, but it
doesn't seem to be NIC related although I have two EEPro100's in it.
I get lockups while doing large disk reads that use larges amounts of memory
(MySQL's myisamchk on a 600MB MyISAM table, for insta
Dylan Griffiths wrote:
>
> Hi. While doing some file tranfers to our new server (a Compaq Proliant
> 8way XEON 500 with 4gb ram and an EEPro100 NIC), the box socked solid (no
> oops, no response via network, no response via console). The other hardware
> in the syst
Hi. While doing some file tranfers to our new server (a Compaq Proliant
8way XEON 500 with 4gb ram and an EEPro100 NIC), the box socked solid (no
oops, no response via network, no response via console). The other hardware
in the system was a Compaq Smart Array 9SMART2 driver). It&#
Alan Cox wrote:
> Someone has done S/CONFIG_EEPRO100_PM/CONFIG_PM/ on the driver and in doing
> so permanently enabled the eepro100 pm code which to say the least doesnt work
> for a lot of people but gives them weird eepro100 hangs
Do you have a bug report of this actually breaking?
> Do you have a bug report of this actually breaking?
I've not been able to make 2.4.6pre5 stay up long enough to do any real
testing on this. It just keeps hanging all the time anyway
> eepro100 is doing standard PCI PM. The only reason AFAICS why it was
> breaking for peopl
Looking over the merges Im doing from 2.4.6pre I found a couple of suprises
the most dubious of which is the rather bogus hackery on eepro100.c
Someone has done S/CONFIG_EEPRO100_PM/CONFIG_PM/ on the driver and in doing
so permanently enabled the eepro100 pm code which to say the least doesnt
>The e100 driver from intel claims to support these cards (the 100 S
>desktop adaptor, that is), but in fact the drivers lock up under heavy
>UDP load (at least they do for me in 2.2.19). It seems to only be a
>problem with these newer cards, the e100 is solid with older cards
>(and things like
Hi Andrey,
I'm attaching the log file.. please let me know if u need other
details.
-Wilson
* Andrey Savochkin ([EMAIL PROTECTED]) wrote:
> On Thu, Jun 21, 2001 at 06:36:03PM -0700, Dionysius Wilson Almeida wrote:
> > I tried inserting a udelay(1) and increasing the count ..but
> > the same beh
On Thu, Jun 21, 2001 at 06:36:03PM -0700, Dionysius Wilson Almeida wrote:
> I tried inserting a udelay(1) and increasing the count ..but
> the same behaviour.
>
> any clues ? btw, i've been able to compile the redhat 7.1 intel e100
> driver and it works fine for my card.
Your problem is differ
rd hangs :
> > > =
> > > Jun 20 16:10:18 debianlap kernel: NETDEV WATCHDOG: eth0: transmit timed out
> > > Jun 20 16:10:18 debianlap kernel: eth0: Transmit timed out: status 0050 0c80 at
>314/342 command 000c.
> > > Jun
On Thu, 21 Jun 2001 09:37:47 -0500
John Madden <[EMAIL PROTECTED]> wrote:
> errors. Think the patch with the udelay() will still work?
In my system, the patch with the udelay() is working.
--
Masaru Kawashima
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
Hi, again!
I'ts me, Masaru Kawashima, from home.
I'm sorry I made a stupid mistake last time!
This time, I promise you that I attach the proper patch for
linux/drivers/net/eepro100.c. (running version)
On Thu, 21 Jun 2001 23:19:39 +0900
Masaru Kawashima > wrote:
> Hi!
>
&g
> Dionysius Wilson Almeida >
>wrote:
> > Jun 20 16:14:07 debianlap kernel: eepro100: wait_for_cmd_done timeout!
> > Jun 20 16:14:38 debianlap last message repeated 5 times
>
> I saw the same message.
>
> The comment before wait_for_cmd_done() function in
&g
Hi!
On Wed, 20 Jun 2001 16:31:34 -0700
Dionysius Wilson Almeida > wrote:
> Jun 20 16:14:07 debianlap kernel: eepro100: wait_for_cmd_done timeout!
> Jun 20 16:14:38 debianlap last message repeated 5 times
I saw the same message.
The comment before wait_for_cmd_done() function in
linu
---Reply to mail from Dionysius Wilson Almeida about eepro100: wait_for_cmd_done
timeout
> No..that was pretty much what i saw in the logs.
>
> I see wait_for_cmd_done timeout being the only one being repeated in the
> logs
>
The same here with 2.4.1 and 2.4.3.
Rafael
queue 342 / 314:
> > Jun 20 16:14:07 debianlap kernel: eepro100: wait_for_cmd_done timeout!
> > Jun 20 16:14:38 debianlap last message repeated 5 times
--
Eat shit -- billions of flies can't be wrong.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel
16:10:18 debianlap kernel: eth0: Tx ring dump, Tx queue 342 / 314:
> Jun 20 16:14:07 debianlap kernel: eepro100: wait_for_cmd_done timeout!
> Jun 20 16:14:38 debianlap last message repeated 5 times
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bod
20 16:10:18 debianlap kernel: eth0:27 0001.
Jun 20 16:10:18 debianlap kernel: eth0:28 0001.
Jun 20 16:10:18 debianlap kernel: eth0:29 0001.
Jun 20 16:10:18 debianlap kernel: eth0:30 0001.
Jun 20 16:10:18 debianlap kernel: eth0:31 0001.
Jun 20 16:14:07 debianlap
On Sun, Jun 17, 2001 at 12:40:34AM -0300, Christian Robottom Reis wrote:
>
> I am _very_ willing to devote some time to getting this fixed in both the
> kernel and Donald's drivers if anyone is interested in tracking down the
> problem. I'm not very familiar with the hardware, but I have a test b
On Sun, 17 Jun 2001, Christian Robottom Reis wrote:
> > Try to add "options eepro100 options=0" to your /etc/modules.conf
> > to default the speed to 10Mbps if you're using 10BaseT.
>
> I'm not using modules for this driver (can't see the point, reall
> FWIW, I believe Intel's Linux drivers will support this card under
> 2.4, and I believe (not 100% certain on this) that they're GPL. I'll
> have to check on that.
The e100 driver from intel claims to support these cards (the 100 S
desktop adaptor, that is), but in fact the drivers lock up unde
On Sun, 17 Jun 2001, Jeff Chua wrote:
> Try to add "options eepro100 options=0" to your /etc/modules.conf
> to default the speed to 10Mbps if you're using 10BaseT.
I'm not using modules for this driver (can't see the point, really); does
this fix anything if I
Try to add "options eepro100 options=0" to your /etc/modules.conf
to default the speed to 10Mbps if you're using 10BaseT.
add to /etc/modules.conf ...
# options=0x30 100mbps full duplex
# options=0x20 100mbps half duplex
# options=0 10mbps half duplex
options eepro100 opti
On Sat, 16 Jun 2001, Christian Robottom Reis wrote:
> I'm having a ton of problems with a set of boxes that use an onboard
> variant of the eepro100. I'm not sure what version it is (#$@#*&$@ Intel
> documentation - motherboard is model D815EEA2) but eepro100-dia
Just noticed:
On Sat, 16 Jun 2001, Christian Robottom Reis wrote:
> Steps to reproduce problem:
>
> * Run large ( > 2MB works ) ftp transfer in box.
> * ssh in from another box and attempt an ls -lR /
Note below:
> * 2.2.19 with Donald's eepro100.c scyld:network/
>
Hello everybody,
I'm having a ton of problems with a set of boxes that use an onboard
variant of the eepro100. I'm not sure what version it is (#$@#*&$@ Intel
documentation - motherboard is model D815EEA2) but eepro100-diag reports:
eepro100-diag.c:v2.05 6/13/2001 Donald
> Hey all,
> I just had an eepro/100 S delivered to me. I haven't dug through specs
> yet, but has anyone looke at this? Supposedly has a 3DES ASIC built in to
> the core.
>
> Any way we can use it?
Good question. I've been wondering how exactly that ASIC would even benefit
Windows users.
Sho
Hey all,
I just had an eepro/100 S delivered to me. I haven't dug through specs
yet, but has anyone looke at this? Supposedly has a 3DES ASIC built in to
the core.
Any way we can use it?
--
Tim Hockin
Systems Software Engineer
Sun Microsystems, Cobalt Server Appliances
[EMAIL PROTECTED]
-
To
On 12 Jun 2001 12:20:58 -0700, Ken Brownfield wrote:
> Or you could keep your hardware and try the Intel driver, which seems to
> work fine. It only works as a module, though. This might also help
> narrow the issue to a driver vs. card vs. mobo/BIOS/IRQ/APIC/etc issue.
I did that, and it see
I would suggest that you use the e100 driver instead of the eepro100 driver.
We switched to the e100 driver from the eepro100 driver, and a number of our
FTP, NFS and rsync (IE: High bandwidth apps) problems went away.
Our system are mostly 6 Proc boxes with 4 gigs of memeory.
--
Jason Murphy
David Lang wrote:
>
> I am useing the D-link 4 port card without running into problems
> (admittidly I have not been stressing it much yet)
I was able to get the D-Link to work in half-duplex (100bt), but
not in auto-negotiate or full-duplex mode. (Packets would pass,
but there would be huge nu
L PROTECTED]>
> Cc: Florin Andrei <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Subject: Re: 2.2.19: eepro100 and cmd_wait issues
>
> Ken Brownfield wrote:
>
> > OT: does anyone know what the current state of the Tulip driver is and
> > if there is good hardware out th
Ken Brownfield wrote:
> OT: does anyone know what the current state of the Tulip driver is and
> if there is good hardware out there? SMC left Tulip and went through at
> least two other chipsets, so the only Tulip card I could find as of a
> couple of years ago was Digital's. But it was astoni
Or you could keep your hardware and try the Intel driver, which seems to
work fine. It only works as a module, though. This might also help
narrow the issue to a driver vs. card vs. mobo/BIOS/IRQ/APIC/etc issue.
Personally, I've found the EtherExpress hardware and eepro100 driver t
On 12 Jun 2001 13:00:41 -0500, John Madden wrote:
>
> kernel: eepro100: cmd_wait for(0x70) timedout with(0x70)!
> kernel: eepro100: cmd_wait for(0x10) timedout with(0x10)!
I have the same problem, since a long time, with various 2.2 and 2.4
kernels running on a i815 motherboard, with
I'm having trouble on one machine out of about 20 that run with eepro100's.
This one in particular happens to be a dual port. I searched through the
archives for this, but I didn't find any definite solutions (one thread, on
"2.2.18 and laptop problems," provided a p
Intel onboard card in this system as well using the
eepro100 driver. This card seems to function fine when used via
the 10 Mbit hub - however once I connect it via a cross cable and
it switches from 10 Mbit half duplex to 100 Mbit full duplex it
stops responding completely as well.
I've seen some
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 tha
Quoting Ion Badulescu ([EMAIL PROTECTED]):
> 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
1 - 100 of 273 matches
Mail list logo
