Hello,
Does anyone except me still having problems with the eepro100 drivers ?
The network connection stalls and I'll get this message:
eepro100: wait_for_cmd_done timeout!
I am using the eepro100 drivers with my 100/10 card running in
10mbit and it works in windows.
I have been trying all new kernels + the ac patches but nothing
seems to work. The fun thing is that I only gets this problem
when I am running XFree, is this just a weird coincidence?
/Johan Nilsson
Johan:
> Does anyone except me still having problems with the eepro100 drivers ?
Yes, as I've mentioned in a earlier thread on this list, we have problems,
but trying the e100-driver from intel doesn't seem to help either (I'm
running tests now, and so far, they don't look very promising).
> The network connection stalls and I'll get this message:
> eepro100: wait_for_cmd_done timeout!
I'm experiensing the:
eth0: Card reports no resources
And, then a hang of at least a minute before the network connection is
restored. All my connections are 100Mbit full duplex, and the error comes
when doing heavy traffic. (Try bonnie++ over NFS, for instance).
--
Thomas
> I am using the eepro100 drivers with my 100/10 card running in
> 10mbit and it works in windows.
>
> I have been trying all new kernels + the ac patches but nothing
> seems to work. The fun thing is that I only gets this problem
> when I am running XFree, is this just a weird coincidence?
Possibly not.
I have one problem box where you have to disable the kernel ACPI stuff but
the XFree case is a new one to me
On Tue, 30 Oct 2001 12:57:20 +0100
Thomas Lang?s <[email protected]> wrote:
> Johan:
> > Does anyone except me still having problems with the eepro100 drivers ?
>
> Yes, as I've mentioned in a earlier thread on this list, we have problems,
> but trying the e100-driver from intel doesn't seem to help either (I'm
> running tests now, and so far, they don't look very promising).
Yes, I have read it, but it was a while ago and I thought the problem
were sovled.
> I'm experiensing the:
> eth0: Card reports no resources
>
> And, then a hang of at least a minute before the network connection is
> restored. All my connections are 100Mbit full duplex, and the error comes
> when doing heavy traffic. (Try bonnie++ over NFS, for instance).
Yes, its the same for me.
Now I'll know that the driver still have problems.
Thanks for your quick answear.
--
// Johan
On Tue, 30 Oct 2001, Alan Cox wrote:
> > I have been trying all new kernels + the ac patches but nothing
> > seems to work. The fun thing is that I only gets this problem
> > when I am running XFree, is this just a weird coincidence?
>
> Possibly not.
>
> I have one problem box where you have to disable the kernel ACPI stuff but
> the XFree case is a new one to me
I have the same problem with this card and I do not use XFree at all in
my servers
linux-2.4.10-ac12 / 2.4.9 / 2.4.3
eepro100: wait_for_cmd_done timeout!
Rafael Martinez
Hi.
The eepro100 can't get dynamic IP address on my machine too.
Niktar,
This problem is inherent in FreeBSD, OpenBSD, NetBSD as well as Linux. I
spent a few months hacking my Sony Vaio with number of OS's (it has this
network card built onto it).
The problem is fatal unfortunately and the only solution I found was
Intel's e100 driver.
'nuff said
Lee Packham
>
> Hello,
> Does anyone except me still having problems with the eepro100 drivers ?
>
> The network connection stalls and I'll get this message:
>
> eepro100: wait_for_cmd_done timeout!
>
> I am using the eepro100 drivers with my 100/10 card running in
> 10mbit and it works in windows.
>
> I have been trying all new kernels + the ac patches but nothing
>seems to work. The fun thing is that I only gets this problem
> when I am running XFree, is this just a weird coincidence?
>
> /Johan Nilsson
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
I've seen this problem when I compiled 2.4.10 kernel with gcc version
3.0.1. I think there is some problem with broadcast and multicast
packets because I managed to make direct connection but I can't use
dhcpd or xdmcp.
Lee Packham wrote:
>
> This problem is inherent in FreeBSD, OpenBSD, NetBSD as well as Linux. I
> spent a few months hacking my Sony Vaio with number of OS's (it has this
> network card built onto it).
>
> The problem is fatal unfortunately and the only solution I found was
> Intel's e100 driver.
>
> 'nuff said
>
> Lee Packham
>
> >
> > Hello,
> > Does anyone except me still having problems with the eepro100 drivers ?
> >
> > The network connection stalls and I'll get this message:
> >
> > eepro100: wait_for_cmd_done timeout!
> >
> > I am using the eepro100 drivers with my 100/10 card running in
> > 10mbit and it works in windows.
> >
> > I have been trying all new kernels + the ac patches but nothing
> >seems to work. The fun thing is that I only gets this problem
> > when I am running XFree, is this just a weird coincidence?
> >
> > /Johan Nilsson
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> > in the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Johan,
If you mean occasional lockups, which go away if you do ifdown / ifup,
then try the patch I posted Sunday - it forces one of the bug workarounds
on, which was dependent on eeprom by default. Also has a debug line
which writes out what it thinks the chip ID is, which activates
(or not) the other bug workaround. Alan put some or all of this
patch into the latest -ac; from his docs I couldn't tell whether
he put in the 'always use bug override' bit, and I expect not.
if you want to do it yourself, find where rx_bug is set, and just
set it to 1 the line afterwards, and try that.
Alternatively, try the intel drivers.
Alex
--On Tuesday, October 30, 2001 12:39:27 +0100 Johan <[email protected]> wrote:
>
> Hello,
> Does anyone except me still having problems with the eepro100 drivers ?
>
> The network connection stalls and I'll get this message:
>
> eepro100: wait_for_cmd_done timeout!
>
> I am using the eepro100 drivers with my 100/10 card running in
> 10mbit and it works in windows.
>
> I have been trying all new kernels + the ac patches but nothing
> seems to work. The fun thing is that I only gets this problem
> when I am running XFree, is this just a weird coincidence?
>
> /Johan Nilsson
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Alex Bligh
On Tue, Oct 30, 2001 at 12:57:20PM +0100, Thomas Lang?s wrote:
> I'm experiensing the:
> eth0: Card reports no resources
>
> And, then a hang of at least a minute before the network connection is
> restored. All my connections are 100Mbit full duplex, and the error comes
> when doing heavy traffic. (Try bonnie++ over NFS, for instance).
I used to have this problem too. Whenever I downloaded something
at high speed, I got that error.
This was with an older 2.4 kernel (2.4.5 I think), and the
previous harddisk which died on me. Now with 2.4.8 I don't have
the problem anymore. I assumed it had to do with the other disk
being slow, I think it was still doing PIO. Maybe it's some
other thing which causes the kernel not being able to react fast
enough?
Kurt
Johan,
--On Tuesday, October 30, 2001 5:07 PM +0000 Alex Bligh - linux-kernel
<[email protected]> wrote:
> If you mean occasional lockups, which go away if you do ifdown / ifup,
> then try the patch I posted Sunday - it forces one of the bug workarounds
> on, which was dependent on eeprom by default. Also has a debug line
> which writes out what it thinks the chip ID is, which activates
> (or not) the other bug workaround. Alan put some or all of this
> patch into the latest -ac; from his docs I couldn't tell whether
> he put in the 'always use bug override' bit, and I expect not.
> if you want to do it yourself, find where rx_bug is set, and just
> set it to 1 the line afterwards, and try that.
Though this worked for me before, it appears to have stopped working
and I don't think I reverted the code (sigh). Are you by any chance
using something with apm in, or using it as a module and removing
the module? The only difference here between working and non-working
is that I've suspended and resumed the machine (/without/ power
management / apm compiled in).
> Alternatively, try the intel drivers.
I am informed by someone who really should know that this /does/ work.
--
Alex Bligh
On Tue, Oct 30, 2001 at 12:39:27PM +0100, Johan wrote:
>
> Hello,
> Does anyone except me still having problems with the eepro100 drivers ?
>
> The network connection stalls and I'll get this message:
>
> eepro100: wait_for_cmd_done timeout!
Try to add `udelay(1);' inside the loop in wait_for_cmd_done().
It helped to some people with same problems.
Andrey
Andrey Savochkin wrote:
>
> On Tue, Oct 30, 2001 at 12:39:27PM +0100, Johan wrote:
> >
> > Hello,
> > Does anyone except me still having problems with the eepro100 drivers ?
> >
> > The network connection stalls and I'll get this message:
> >
> > eepro100: wait_for_cmd_done timeout!
>
> Try to add `udelay(1);' inside the loop in wait_for_cmd_done().
> It helped to some people with same problems.
In 2.4 that's already there:
> static inline void wait_for_cmd_done(long cmd_ioaddr)
> {
> int wait = 1000;
> do udelay(1) ;
> while(inb(cmd_ioaddr) && --wait >= 0);
> #ifndef final_version
> if (wait < 0)
> printk(KERN_ALERT "eepro100: wait_for_cmd_done timeout!\n");
> #endif
> }
In contrast, here is what Becker's current version looks like. It looks
like Becker just added a hack to continue waiting.
Things to try:
(a) add a rmb() after the udelay
(b) the Becker version
> /* How to wait for the command unit to accept a command.
> Typically this takes 0 ticks. */
>
> static inline void wait_for_cmd_done(long cmd_ioaddr)
> {
> int wait = 0;
> do
> if (inb(cmd_ioaddr) == 0) return;
> while(++wait <= 100);
> do
> if (inb(cmd_ioaddr) == 0) break;
> while(++wait <= 10000);
> printk(KERN_ERR "Command %4.4x was not immediately accepted, %d ticks!\n
> ",
> inb(cmd_ioaddr), wait);
> }
--
Jeff Garzik | Only so many songs can be sung
Building 1024 | with two lips, two lungs, and one tongue.
MandrakeSoft | - nomeansno
Hello,
I'm having the same type of problems that was talked
about in this thread. I have seen the same error
on kernels 2.4.7 - 2.4.10, which is:
eth0: card reports no resources.
__alloc_pages: 0_order allocation failed (gfp=0x20/0) from c012da00
at which point i see NFS timeouts or the machine hangs
and requires a cold reboot.
also, I haven't had any luck with the Intel e100 driver.
I'm now testing on 10 of the nodes the 2.4.16 kernel. They
have been under a moderate load and i haven't seen any
problems yet. I still plan on doing a large load test
on this newer kernel.
joe
http://www.bigidea.com
On Fri, Nov 30, 2001 at 06:08:27PM -0600, Joe Rice wrote:
>
> Hello,
> I'm having the same type of problems that was talked
> about in this thread. I have seen the same error
> on kernels 2.4.7 - 2.4.10, which is:
>
> eth0: card reports no resources.
> __alloc_pages: 0_order allocation failed (gfp=0x20/0) from c012da00
>
> at which point i see NFS timeouts or the machine hangs
> and requires a cold reboot.
>
> also, I haven't had any luck with the Intel e100 driver.
>
e100 probably doesn't help because that is a VM issue triggered by nfs and
networking.
>
> I'm now testing on 10 of the nodes the 2.4.16 kernel. They
> have been under a moderate load and i haven't seen any
> problems yet. I still plan on doing a large load test
> on this newer kernel.
>
Let us know if there's any problems. And if things are better that wouldn't
hurt reporting either ;)
i guess that explains why i haven't seen the problem again
on the bed of machines with 2.4.16.
Could please explain how you came to your answer?
maybe this is to obvious to be addressed on the list, but
please give me a clue.
thanks,
joe
http://www.bigidea.com
Mike Fedyk([email protected])@Fri, Nov 30, 2001 at 04:37:21PM -0800:
> On Fri, Nov 30, 2001 at 06:08:27PM -0600, Joe Rice wrote:
> >
> > Hello,
> > I'm having the same type of problems that was talked
> > about in this thread. I have seen the same error
> > on kernels 2.4.7 - 2.4.10, which is:
> >
> > eth0: card reports no resources.
> > __alloc_pages: 0_order allocation failed (gfp=0x20/0) from c012da00
> >
> > at which point i see NFS timeouts or the machine hangs
> > and requires a cold reboot.
> >
> > also, I haven't had any luck with the Intel e100 driver.
> >
>
> e100 probably doesn't help because that is a VM issue triggered by nfs and
> networking.
>
> >
> > I'm now testing on 10 of the nodes the 2.4.16 kernel. They
> > have been under a moderate load and i haven't seen any
> > problems yet. I still plan on doing a large load test
> > on this newer kernel.
> >
>
> Let us know if there's any problems. And if things are better that wouldn't
> hurt reporting either ;)
On Fri, Nov 30, 2001 at 06:49:16PM -0600, Joe Rice wrote:
> i guess that explains why i haven't seen the problem again
> on the bed of machines with 2.4.16.
> Could please explain how you came to your answer?
> maybe this is to obvious to be addressed on the list, but
> please give me a clue.
>
IIRC the triggers are:
older kernel ( <= 2.4.9)
nfs w/ 1024 byte packets (default) better usually is 8192
lots of network traffic