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. And
IMHO, as long as the drive
[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 dropped because an upd
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 error in 2.6.13-rc2
> odd, b
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 broken? This might indicate something
wie
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.
eepro100 is unmaintained and
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
> the issue (2.4.5 kernel).
Andrew Morton wrote:
> 1: Include `magic sysrq' support in the kernel and use ALT-SYSRQ-T and S
>when it has locked up. If you get some traces then please feed them
>into `ksymoops -m System.map' and report back.
That was locked as well, AFAIK.
> 2: If the above doesn't work, add `nmi
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 instance). The SCSI
subsyste
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 system was a Compaq Smart
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?
eepro100 is
> 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 people was that the prev
>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
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.
-Wilson
* Dionysius Wilson Almeida ([EMAIL PROTECTED]) wrote:
> No..that was pretty much what i saw in th
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!
>
> On Wed, 20 Jun 2001
> 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
> linux/drivers/net/eepro100.c says:
> /
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
linux/drivers/ne
---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 Martinez
-
To unsubscr
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
-Wilson
`
* Andrey Savochkin ([EMAIL PROTECTED]) wrote:
> What was the first error message from the driver?
> NETDEV WATCHDOG report went before wait_for_cmd_done timeou
What was the first error message from the driver?
NETDEV WATCHDOG report went before wait_for_cmd_done timeout and is more
important. I wonder if you had some other messages before the watchdog one.
Andrey
On Wed, Jun 20, 2001 at 04:31:34PM -0700, Dionysius Wilson Almeida wrote:
> And t
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, really); does
> this fix anything if I change it to
> 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 change it to 0x20 for 100BaseT?
Ta
ons=0
then run "depmod -a"
Thanks,
Jeff
[ [EMAIL PROTECTED] ]
- Original Message -
From: "Christian Robottom Reis" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Sunday, June 17, 2001 10:43 AM
Sub
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-diag reports:
>
> eepro100-diag.c:v2.
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/
> Hard lock (seems to t
> 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
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 boots
> > and can be configu
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 da
Alan Cox <[EMAIL PROTECTED]> writes:
>
> Do you see this if you run a -ac kernel or apply the APIC 440BX patch ?
Alan, what APIC 440BX patch are you referring to? I must have missed
it, and I can't find anything in the archives.
Kevin <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send t
Alan Cox <[EMAIL PROTECTED]> writes:
> > What seems to happen is that the kernel stops seeing interrupts on the
> > IRQ shared by eth0 (my outside interface) and usb-uhci. I can still
> > ssh in on eth1, and when I do, syslog contains things like "eth0:
> > Interrupt timed out" and usb-uhci grip
> What seems to happen is that the kernel stops seeing interrupts on the
> IRQ shared by eth0 (my outside interface) and usb-uhci. I can still
> ssh in on eth1, and when I do, syslog contains things like "eth0:
> Interrupt timed out" and usb-uhci griping about devices that failed to
> accept new
On Fri, 23 Mar 2001 09:34:36 -0800, Jun Sun <[EMAIL PROTECTED]> wrote:
> BTW, does the eepro100 patch for 2.2.19pre apply to 2.4.2? Or it is already
> in it?
It was backported from 2.4.1, so yes, it's already in.
Ion
--
It is better to keep your mouth shut and be thought a fool,
I'm having a similar problem with the onboard network card of a Sony
Vaio Laptop. I haven't tracked it down as far as you can; how can I
confirm its the same problem as yours?
On Fri, Mar 23, 2001 at 09:34:36AM -0800, Jun Sun wrote:
> christophe barbe wrote:
> >
> > Which kernel are you using.
christophe barbe wrote:
>
> Which kernel are you using.
>
> I've had a similar problem with 2.2.18.
> I've backported 2.2.19pre changes to it.
> (i.e. apply on 2.2.18 a diff of the file drivers/net/eepro100.c made between 2.2.18
>and the last 2.2.19pre)
> And since I've never seen this problem
Which kernel are you using.
I've had a similar problem with 2.2.18.
I've backported 2.2.19pre changes to it.
(i.e. apply on 2.2.18 a diff of the file drivers/net/eepro100.c made between 2.2.18
and the last 2.2.19pre)
And since I've never seen this problem again.
Christophe
On jeu, 22 mar 2001
On Tue, Feb 13, 2001 at 09:26:38AM +0800, Andrey Savochkin wrote:
> On Sun, Feb 11, 2001 at 10:40:33PM +1100, CaT wrote:
> [snip]
> > Feb 11 22:30:18 theirongiant kernel: eepro100: cmd_wait for(0x70) timedout
>with(0x70)!
>
> Please try the attached patch.
> Actually, it's designed to solve anot
On Tue, Feb 20, 2001 at 05:18:37PM +0900, Augustin Vidovic wrote:
> 00:0c.0 Ethernet controller: Intel Corporation 82557 (rev 08)
> 00:0d.0 Ethernet controller: Intel Corporation 82557 (rev 08)
It's i82559.
It can't have that original bug which is checked by those EEPROM bits and
workaround for w
On Tue, Feb 20, 2001 at 02:00:31AM -0800, Ion Badulescu wrote:
> Are you sure this driver has my patch applied? There is no way you could
> have gotten these messages without getting the other printk as well..
>
> Can you check it again, please?
*sigh* too much kernel bouncing. I got the right
On Tue, 20 Feb 2001, CaT wrote:
> > patched, old removed, new installed, waiting for fubar. :)
>
> Ok. this is what I got in my kern.log. this is on a fresh reboot.
>
> Feb 20 18:31:49 theirongiant kernel: eepro100: cmd_wait for(0x70) timedout
>with(0x70)!
> Feb 20 18:31:49 theirongiant kernel
On Mon, Feb 19, 2001 at 11:21:36PM -0800, Andrey Savochkin wrote:
> On Tue, Feb 20, 2001 at 03:30:48PM +0900, Augustin Vidovic wrote:
> > On Mon, Feb 12, 2001 at 01:00:34AM -0800, Ion Badulescu wrote:
> > > > Augustin, could you send the output of `lspci' and `eepro100-diag -ee', please?
> > > > (
On Tue, Feb 20, 2001 at 11:31:52AM +1100, CaT wrote:
> On Mon, Feb 19, 2001 at 04:18:40PM -0800, Ion Badulescu wrote:
> > > In my experiments wait_for_cmd timeouts almost always were related to
> > > DumpStats command.
> > > I think, we need to investigate what time constraints are related to this
On Tue, Feb 20, 2001 at 03:30:48PM +0900, Augustin Vidovic wrote:
> On Mon, Feb 12, 2001 at 01:00:34AM -0800, Ion Badulescu wrote:
> > > Augustin, could you send the output of `lspci' and `eepro100-diag -ee', please?
> > > (The latter may be taken from ftp://scyld.com/pub/diag/)
> >
> > I'd be cu
On Mon, Feb 12, 2001 at 01:00:34AM -0800, Ion Badulescu wrote:
> > Augustin, could you send the output of `lspci' and `eepro100-diag -ee', please?
> > (The latter may be taken from ftp://scyld.com/pub/diag/)
>
> I'd be curious to see them too.
Ok, here is the output (the status are displayed onl
On Mon, Feb 19, 2001 at 04:18:40PM -0800, Ion Badulescu wrote:
> > In my experiments wait_for_cmd timeouts almost always were related to
> > DumpStats command.
> > I think, we need to investigate what time constraints are related to this
> > command.
>
> Nothing documented...
>
> CaT, can you ap
On Mon, 19 Feb 2001 14:49:35 -0800, Andrey Savochkin <[EMAIL PROTECTED]> wrote:
> On Tue, Feb 20, 2001 at 09:21:06AM +1100, CaT wrote:
>>
>> It happened again. Same deal. Once was after a reboot and this time
>> was after a resume. :/
>
> In my experiments wait_for_cmd timeouts almost always we
Hi,
On Tue, Feb 20, 2001 at 09:21:06AM +1100, CaT wrote:
> On Tue, Feb 13, 2001 at 03:14:09PM +1100, CaT wrote:
> > On Tue, Feb 13, 2001 at 09:26:38AM +0800, Andrey Savochkin wrote:
> > > On Sun, Feb 11, 2001 at 10:40:33PM +1100, CaT wrote:
> > > [snip]
> > > > Feb 11 22:30:18 theirongiant kernel
On Mon, Feb 19, 2001 at 03:44:10PM -0800, Dragan Stancevic wrote:
> On Tue, Feb 20, 2001, CaT <[EMAIL PROTECTED]> wrote:
> ;
> ; None. This is before any traffic gets put through it. At worst the
> ; card has the wrong IP for the network but that is not always the case
> ; from memory.
>
> So wh
On Tue, Feb 20, 2001, CaT <[EMAIL PROTECTED]> wrote:
;
; None. This is before any traffic gets put through it. At worst the
; card has the wrong IP for the network but that is not always the case
; from memory.
So where does that card get the address from, are you doing DHCP?
--
No Kernel Hac
On Mon, Feb 19, 2001 at 03:37:02PM -0800, Dragan Stancevic wrote:
> On Tue, Feb 20, 2001, CaT <[EMAIL PROTECTED]> wrote:
> ; > 100% accuracy and so it'll take me a wee while before I decide '
> ; > a... that rocks my boat. it's fixed.'. :)
> ;
> ; It happened again. Same deal. Once wa
On Tue, Feb 20, 2001, CaT <[EMAIL PROTECTED]> wrote:
; > 100% accuracy and so it'll take me a wee while before I decide '
; > a... that rocks my boat. it's fixed.'. :)
;
; It happened again. Same deal. Once was after a reboot and this time
; was after a resume. :/
What kind of trafic
On Tue, Feb 13, 2001 at 03:14:09PM +1100, CaT wrote:
> On Tue, Feb 13, 2001 at 09:26:38AM +0800, Andrey Savochkin wrote:
> > On Sun, Feb 11, 2001 at 10:40:33PM +1100, CaT wrote:
> > [snip]
> > > Feb 11 22:30:18 theirongiant kernel: eepro100: cmd_wait for(0x70) timedout
>with(0x70)!
> >
> > Pleas
On Wed, Feb 14, 2001 at 10:19:20AM +0200, Andriy Korud wrote:
> Hello all,
> My setup is Intel 440GX MB with intergrated EEPro100.
> When using Linux 2.2.18 the following happen: after reboot, I got:
> eepro100: cmd_wait for (0xff90) timedout with (0xff90)!
I reported the same hassle
On Tue, Feb 13, 2001 at 09:26:38AM +0800, Andrey Savochkin wrote:
> On Sun, Feb 11, 2001 at 10:40:33PM +1100, CaT wrote:
> [snip]
> > Feb 11 22:30:18 theirongiant kernel: eepro100: cmd_wait for(0x70) timedout
>with(0x70)!
>
> Please try the attached patch.
> Actually, it's designed to solve anot
On Sun, Feb 11, 2001 at 10:40:33PM +1100, CaT wrote:
[snip]
> Feb 11 22:30:18 theirongiant kernel: eepro100: cmd_wait for(0x70) timedout
>with(0x70)!
Please try the attached patch.
Actually, it's designed to solve another problem, but may be your one has the
same origin as that other.
Best rega
On Mon, 12 Feb 2001, Andrey Savochkin wrote:
> I've just checked: "Sending a multicast list set command" is printed only on
> high debug levels, so Augustin might not see them.
I could have sworn that I saw the message being printed unconditionally.
But you're right, so we're back to square one
Ion,
On Thu, Feb 08, 2001 at 03:26:51AM -0800, Ion Badulescu wrote:
> On Thu, 8 Feb 2001 20:15:39 +0900, Augustin Vidovic <[EMAIL PROTECTED]> wrote:
>
> >> eth0: Sending a multicast list set command from a timer routine."
> >>
> >> If you find such messages, the work-around really did s
On Thu, Feb 08, 2001 at 02:42:52AM -0500, 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
uot;Davide Libenzi" <[EMAIL PROTECTED]>
To: "Micah Gorrell" <[EMAIL PROTECTED]>; "Andrey Savochkin"
<[EMAIL PROTECTED]>
Cc: "Romain Kang" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "Craig I. Hagan"
&
On Tuesday 30 January 2001 08:14, Micah Gorrell wrote:
> I have been running 2.2 on many machines since its release and have updated
> to the latest version of 2.2 many times. All of these machines have an
> eepro100 and I never saw a single problem with any of them. I updated most
> of my machi
-
From: "Andrey Savochkin" <[EMAIL PROTECTED]>
To: "Micah Gorrell" <[EMAIL PROTECTED]>
Cc: "Romain Kang" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "Craig I. Hagan"
<[EMAIL PROTECTED]>
Date: Tuesday, J
On Mon, Jan 29, 2001 at 11:06:11AM -0700, Micah Gorrell wrote:
> As stated in a number of previous messages to this list many people have had
> serious problems with the eepro100 driver in 2.4. These problems where not
> there in 2.2 and it is not a select few machines showing this so I very much
On Mon, 29 Jan 2001, Sergey Kubushin wrote:
> On Mon, 29 Jan 2001, Richard B. Johnson wrote:
>
> > Two of my Linux machines use the Intel Ethernet controller on the
> > motherboard. These are both SMP machines. I have never, ever, had
> > any problems with the eepro100 driver that handles these
Sergey Kubushin wrote:
>
> The older chips (e.g. 82557) work fine. The problem arises when you have the
> newer 82559's. They do work, however, if the power management for eepro100
> is enabled in kernel config. It definitely means that those chips are
> underinitialized (or overinitialized :)) w
aig I. Hagan" <[EMAIL PROTECTED]>
Cc: "Romain Kang" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Date: Monday, January 29, 2001 10:50 AM
Subject: Re: eepro100 - Linux vs. FreeBSD
>On Mon, 29 Jan 2001, Craig I. Hagan wrote:
>
>> > One approach to the endl
On Mon, 29 Jan 2001, Richard B. Johnson wrote:
> Two of my Linux machines use the Intel Ethernet controller on the
> motherboard. These are both SMP machines. I have never, ever, had
> any problems with the eepro100 driver that handles these chips.
>
> I spite of the fact that the driver loops in
On Mon, 29 Jan 2001, Craig I. Hagan wrote:
> > One approach to the endless eepro100 headaches would be to port
> > the FreeBSD if_fxp driver to Linux. After all, drivers have been
> > ported between these OSs before; e.g., the aic7xxx SCSI adapter.
> > However, I see no evidence that this has be
> One approach to the endless eepro100 headaches would be to port
> the FreeBSD if_fxp driver to Linux. After all, drivers have been
> ported between these OSs before; e.g., the aic7xxx SCSI adapter.
> However, I see no evidence that this has been attempted. Can
> someone tell me what I'm obviou
Hello,
On Thu, Jan 25, 2001 at 01:20:03PM -0700, Micah Gorrell wrote:
> I have doing some testing with kernel 2.4 and I have had constant problems
> with the eepro100 driver. Under 2.2 it works perfectly but under 2.4 I am
> unable to use more than one card in a server and when I do use one card
Andrey Savochkin wrote:
>
> Hi,
>
> On Thu, Jan 25, 2001 at 04:19:27PM -0500, Jeff Garzik wrote:
> > Oops, sorry guys. Thanks to DaveM for correcting me -- my patch has
> > nothing to do with the "card reports no resources" problem. My
> > apologies.
>
> No problems.
>
> However, there is a
On Friday, 26 January 2001, [EMAIL PROTECTED] wrote:
> Hi,
>
> On Thu, Jan 25, 2001 at 04:19:27PM -0500, Jeff Garzik wrote:
> > Oops, sorry guys. Thanks to DaveM for correcting me -- my patch has
> > nothing to do with the "card reports no resources" problem. My
> > apologies.
>
> No problems.
cott Robinson <[EMAIL PROTECTED]>
To: Andrey Savochkin <[EMAIL PROTECTED]>
Subject: Re: EEPRO100 Power Management problem?
Message-ID: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: multipart/signed; mical
Jeff Garzik wrote:
>
> Micah Gorrell wrote:
> > Because of the problems we where having we are no longer using the machine
> > with 3 nics. We are now using a machine with just one and it is going live
> > next week. We do need kernel 2.4 because of the process limits in 2.2.
> > Does the 'Enab
nus Torvalds claims to be trying to take over the world
> -Original Message-
> From: "Tom Sightler" <[EMAIL PROTECTED]>
> To: "Micah Gorrell" <[EMAIL PROTECTED]>;
> <[EMAIL PROTECTED]>
> Date: Thursday, January 25, 2001 1:48 PM
> S
]>
> To: "Micah Gorrell" <[EMAIL PROTECTED]>;
> <[EMAIL PROTECTED]>
> Date: Thursday, January 25, 2001 1:48 PM
> Subject: Re: eepro100 problems in 2.4.0
[...]
> >I had a similar problem with a server that had dual embedded eepro100
> >adapters howev
L PROTECTED]>;
<[EMAIL PROTECTED]>
Date: Thursday, January 25, 2001 1:48 PM
Subject: Re: eepro100 problems in 2.4.0
> > I have doing some testing with kernel 2.4 and I have had constant
>problems
>> with the eepro100 driver. Under 2.2 it works perfectly but under 2.4 I
am
&g
> I have doing some testing with kernel 2.4 and I have had constant
problems
> with the eepro100 driver. Under 2.2 it works perfectly but under 2.4 I am
> unable to use more than one card in a server and when I do use one card I
> get errors stating that eth0 reports no recources. Has anyone el
On Thu, 25 Jan 2001, Micah Gorrell wrote:
I have it too. Kernel spits a lot of "eepro100: wait_for_cmd_done timeout!"
and network doesn't work. 2.2 is fine. This behaviour is not persistent,
sometimes the eepro100 module is loaded without such an error and works fine
then.
The eepro100 in questi
On Tue, Jan 16, 2001 at 07:02:52PM -0800, Kostas Nikoloudakis wrote:
> Jan 16 00:49:04 cd20 kernel: eth0: card reports no resources.
> Jan 16 00:49:06 cd20 kernel: eth0: can't fill rx buffer (force 0)!
The driver can't allocate buffers for incoming packets.
Increase /proc/sys/vm/freepages numbe
In article <[EMAIL PROTECTED]> you wrote:
> On Tue, Jan 16, 2001 at 07:02:52PM -0800, Kostas Nikoloudakis wrote:
>> The machine is running under heavy CPU + memory + network load.
>> It seems that the card has problems finding the required resources.
>> Is there a way to "guarantee" that the car
On Tue, Jan 16, 2001 at 07:02:52PM -0800, Kostas Nikoloudakis wrote:
> The machine is running under heavy CPU + memory + network load.
> It seems that the card has problems finding the required resources.
> Is there a way to "guarantee" that the card will have the necessary
> resources even at hi
On Fri, Jan 12, 2001, Dan B <[EMAIL PROTECTED]> wrote:
; Has anyone gotten Intel's (non-GPL) e100 driver working in 2.4.x yet? What
; about their e100-ANS driver that supports FEC 800mbps?
I don't think the intels driver is using pci_dma yet so it's
going to take a while before they port all th
I'm using the following and its been flawless under 2.4x:
eepro100.c:v1.09j-t 9/29/99 Donald Becker
http://cesdis.gsfc.nasa.gov/linux/driv
ers/eepro100.html
eepro100.c: $Revision: 1.35 $ 2000/11/17 Modified by Andrey V.
Savochkin and others
PCI: Found IRQ 11 for device 00:0b.0
eth0: Intel Corpor
Dan B wrote:
>
> Has anyone gotten Intel's (non-GPL) e100 driver working in 2.4.x yet? What
> about their e100-ANS driver that supports FEC 800mbps?
My system at home has an Intel 815 motherboard (video, sound and network are
included into the motherboard), and works quite well with 2.4
Has anyone gotten Intel's (non-GPL) e100 driver working in 2.4.x yet? What
about their e100-ANS driver that supports FEC 800mbps?
Dan Browning, Cyclone Computer Systems,
[EMAIL PROTECTED]
At 02:14 PM 1/11/2001 -0800, you wrote:
>On Tue, Jan 09, 2001, Kambo Lohan <[EMAIL PROTECTED]> wrote:
>;
On Tue, Jan 09, 2001, Kambo Lohan <[EMAIL PROTECTED]> wrote:
; I am having the same problems, I have duplicated the hard lockups / ethernet
; hangs on two intel 815EE boards. It happens when send traffic through the
; onboard eepro100 is high, and sometimes running something like vmstat 1 in
;
>You could try the Intel driver (e100.c), which is downloadable from their
>website. It apparently has some silicon bug workarounds that Donald's
>driver hasn't.
We've been back and forth with that driver, yeah. It has its own set of
problems, sometimes it doesnt even autonegotiate properly,
Whoops,
I didnt set the cc address properly, the full thread is on the
[EMAIL PROTECTED] list.
Karl Pickett
_
Get your FREE download of MSN Explorer at http://explorer.msn.com
-
To unsubscribe from this list: send the line "unsubs
You could try the Intel driver (e100.c), which is downloadable from their website.
It apparently has some silicon bug workarounds that Donald's driver hasn't.
Another popular cause of strange lockups are PCI bios problems (interrupt conflicts
etc. -- exchanging slots may help)
Also please not
I am having the same problems, I have duplicated the hard lockups / ethernet
hangs on two intel 815EE boards. It happens when send traffic through the
onboard eepro100 is high, and sometimes running something like vmstat 1 in
the background triggers the lockup faster. When it locks up there i
At 03:16 11/12/2000, Ion Badulescu wrote:
>On Mon, 11 Dec 2000, Udo A. Steinberg wrote:
>Anton Altaparmakov wrote:
> > > My card is an Ether Express Pro 100, lcpci says: Intel Corporation 82557
> > > [Ethernet Pro 100] (rev 04)
>
>So it's an i82558 A-step. That's interesting, the patch shouldn't h
Ion Badulescu wrote:
> This is an i82559 C-step. What kind of switch is it attached to?
It's a 3Com FDDI/Ethernet Linkswitch 2200 Rev 2.8
> Also, if you feel like experimenting, edit speedo_interrupt() and change
> outw(status & 0xfc00, ioaddr + SCBStatus);
> to
> outw(status &
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 ifcon
Hi,
Anton Altaparmakov wrote:
> Just to say that the patch (including added 4) fixed the "card reports no
> resources" messages for me. - Looking at my logs the messages appeared once
> every 10-40 minutes. - Now the box is up for more than 5 hours with the
> patch and test12-pre7 and not a sing
At 20:57 08/12/2000, Ion Badulescu wrote:
>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);
> >
>
1 - 100 of 128 matches
Mail list logo
