On Fri, 12 Jan 2001, Frank de Lange wrote:
[I've cut syslog junk away for clarity -- you could just do `dmesg -s 32768'.]
> before network hang
> ===
[...]
> NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
[...]
> 13 0FF 0F 010 1 01199
[...]
>
On Fri, 12 Jan 2001, Frank de Lange wrote:
[I've cut syslog junk away for clarity -- you could just do `dmesg -s 32768'.]
before network hang
===
[...]
NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
[...]
13 0FF 0F 010 1 01199
[...]
printing
On Sun, Jan 14, 2001 at 12:13:58AM +, Roeland Th. Jansen wrote:
> On Fri, Jan 12, 2001 at 09:03:49PM +0100, Ingo Molnar wrote:
> > well, some time ago i had an ne2k card in an SMP system as well, and found
> > this very problem. Disabling/enabling focus-cpu appeared to make a
> > difference,
On Fri, Jan 12, 2001 at 09:03:49PM +0100, Ingo Molnar wrote:
> well, some time ago i had an ne2k card in an SMP system as well, and found
> this very problem. Disabling/enabling focus-cpu appeared to make a
> difference, but later on i made experiments that show that in both cases
> the hang
On Fri, Jan 12, 2001 at 09:03:49PM +0100, Ingo Molnar wrote:
well, some time ago i had an ne2k card in an SMP system as well, and found
this very problem. Disabling/enabling focus-cpu appeared to make a
difference, but later on i made experiments that show that in both cases
the hang happens.
On Sun, Jan 14, 2001 at 12:13:58AM +, Roeland Th. Jansen wrote:
On Fri, Jan 12, 2001 at 09:03:49PM +0100, Ingo Molnar wrote:
well, some time ago i had an ne2k card in an SMP system as well, and found
this very problem. Disabling/enabling focus-cpu appeared to make a
difference, but
> Remind me: what polarity are your io-apic irq's? Level, edge, sideways?
> Anything else that might be relevant?
Well, sideways ofcourse! :-)
here's a cat /proc/interrupts from the (BP6) box:
CPU0 CPU1
0: 104936 105433IO-APIC-edge timer
1:
On Fri, Jan 12, 2001 at 11:59:25AM -0800, Linus Torvalds wrote:
> > Could this really be the solution?
>
> I'd like to know _which_ of the two makes a difference (or does it only
> trigger with both of them enabled)? And even then I'm not sure that it is
> "the" solution - both changes to
On Fri, Jan 12, 2001 at 08:33:15PM +0100, Manfred Spraul wrote:
> Frank, the 2.4.0 contains 2 band aids that were added for ne2k smp:
>
> * From Ingo: focus cpu disabled, in arch/i386/kernel/apic.c
> * From myself: TARGET_CPU = cpu_online_mask, was 0xFF.
>
> Could you disable both bandaids? I
Frank de Lange wrote:
>
> On Fri, Jan 12, 2001 at 08:04:24PM +0100, Manfred Spraul wrote:
> > I removed the disable_irq lines from 8390.c, and that fixed the problem:
> > no hang within 2 minutes - the test is still running.
> >
> > Frank, could you double check it?
>
> I'm currently running my
On Fri, Jan 12, 2001 at 08:04:24PM +0100, Manfred Spraul wrote:
> I removed the disable_irq lines from 8390.c, and that fixed the problem:
> no hang within 2 minutes - the test is still running.
>
> Frank, could you double check it?
I'm currently running my own patched version, which uses
On Fri, Jan 12, 2001 at 08:04:24PM +0100, Manfred Spraul wrote:
> Linus wrote:
> > Does this seem to happen mainly with drivers that use "disable_irq()"
> > and "enable_irq()"? I know the ne drivers do (through the 8390 module),
> > and some others do too (3c59x).
>
> I removed the
Linus wrote:
> Does this seem to happen mainly with drivers that use "disable_irq()"
> and "enable_irq()"? I know the ne drivers do (through the 8390 module),
> and some others do too (3c59x).
I removed the disable_irq lines from 8390.c, and that fixed the problem:
no hang within 2 minutes -
On Fri, Jan 12, 2001 at 06:51:36PM +0100, Manfred Spraul wrote:
> Frank, I've attached a proposed kick_IOAPIC pin. Could you try it?
> I'm rebooting with that patch right now.
I added the patch, and tried it out. When the network hangs, I am able to revive it
with ALT-SYSRQ-Q. The debug log
Frank de Lange wrote:
>
> On Fri, Jan 12, 2001 at 06:16:36PM +0100, Manfred Spraul wrote:
> > I would first concentrate on the differences between 2.2 and 2.4:
> >
> > Frank, could you try what happens with the NMI oopser disabled?
>
> Here's the results with nmi_watchdog=0
>
>
> After
On Fri, Jan 12, 2001 at 06:16:36PM +0100, Manfred Spraul wrote:
> I would first concentrate on the differences between 2.2 and 2.4:
>
> Frank, could you try what happens with the NMI oopser disabled?
Here's the results with nmi_watchdog=0
Before network hang (nmi_watchdog=0)
>
> [EMAIL PROTECTED] said:
> > IRR for interrupt 19 is set, that means the IO APIC has sent the
> > interrupt to a cpu but not yet received the corresponding EOI.
>
> OK, but couldn't we reset it by sending an extra EOI when the drivers
> decide that they've missed interrupts?
How?
You
[EMAIL PROTECTED] said:
> IRR for interrupt 19 is set, that means the IO APIC has sent the
> interrupt to a cpu but not yet received the corresponding EOI.
OK, but couldn't we reset it by sending an extra EOI when the drivers
decide that they've missed interrupts?
--
dwmw2
-
To unsubscribe
Let's decode it:
> IO APIC #2..
> NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
> 12 0FF 0F 0 1 0 1 0 1 1 91
> 13 0FF 0F 0 1 1 1 0 1 1 99
IRR for interrupt 19 is set, that means the IO APIC has sent the
interrupt to a cpu but not yet received the corresponding EOI.
That bit is read
On Fri, Jan 12, 2001 at 10:40:04PM +1100, Andrew Morton wrote:
> Here is a debugging patch. Could you please apply this,
> rebuild and:
>
> 1: Type ALT-SYSRQ-A when everything is good
> 2: Type ALT-SYSRQ-A when everything is bad
> 3: send the resulting logs.
And, for completeness' sake, here's
On Fri, Jan 12, 2001 at 10:40:04PM +1100, Andrew Morton wrote:
> Here is a debugging patch. Could you please apply this,
> rebuild and:
>
> 1: Type ALT-SYSRQ-A when everything is good
> 2: Type ALT-SYSRQ-A when everything is bad
> 3: send the resulting logs.
OK, here's the results I get...
On Fri, Jan 12, 2001 at 10:40:04PM +1100, Andrew Morton wrote:
> Frank de Lange wrote:
> >
> > Quick and dirty conclusion: as soon as the apic comes in to play, things get
> > messy...
> Here is a debugging patch. Could you please apply this,
> rebuild and:
>
> 1: Type ALT-SYSRQ-A when
[EMAIL PROTECTED] said:
> No, I'm judging based on the fact that I found reports from people
> using NE2K-PCI with several cards as well as tulip-based cards
> (different driver) on abit BP6 as well as Gigabyte motherboards,
> mostly on 2.3.x/2.4.x kernels. I found some postings with these
>
Frank de Lange wrote:
>
> Quick and dirty conclusion: as soon as the apic comes in to play, things get
> messy...
Yup.
Frank, for over a year there have been sporadic reports
of APIC's forgetting how to deliver interrupts. Not only
on BP6's. Often with 3com NICs, so I've never been 100% sure
Frank de Lange wrote:
Quick and dirty conclusion: as soon as the apic comes in to play, things get
messy...
Yup.
Frank, for over a year there have been sporadic reports
of APIC's forgetting how to deliver interrupts. Not only
on BP6's. Often with 3com NICs, so I've never been 100% sure
[EMAIL PROTECTED] said:
No, I'm judging based on the fact that I found reports from people
using NE2K-PCI with several cards as well as tulip-based cards
(different driver) on abit BP6 as well as Gigabyte motherboards,
mostly on 2.3.x/2.4.x kernels. I found some postings with these
On Fri, Jan 12, 2001 at 10:40:04PM +1100, Andrew Morton wrote:
Frank de Lange wrote:
Quick and dirty conclusion: as soon as the apic comes in to play, things get
messy...
Here is a debugging patch. Could you please apply this,
rebuild and:
1: Type ALT-SYSRQ-A when everything is good
On Fri, Jan 12, 2001 at 10:40:04PM +1100, Andrew Morton wrote:
Here is a debugging patch. Could you please apply this,
rebuild and:
1: Type ALT-SYSRQ-A when everything is good
2: Type ALT-SYSRQ-A when everything is bad
3: send the resulting logs.
OK, here's the results I get...
Before
On Fri, Jan 12, 2001 at 10:40:04PM +1100, Andrew Morton wrote:
Here is a debugging patch. Could you please apply this,
rebuild and:
1: Type ALT-SYSRQ-A when everything is good
2: Type ALT-SYSRQ-A when everything is bad
3: send the resulting logs.
And, for completeness' sake, here's the
Let's decode it:
IO APIC #2..
NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
12 0FF 0F 0 1 0 1 0 1 1 91
13 0FF 0F 0 1 1 1 0 1 1 99
IRR for interrupt 19 is set, that means the IO APIC has sent the
interrupt to a cpu but not yet received the corresponding EOI.
That bit is read
[EMAIL PROTECTED] said:
IRR for interrupt 19 is set, that means the IO APIC has sent the
interrupt to a cpu but not yet received the corresponding EOI.
OK, but couldn't we reset it by sending an extra EOI when the drivers
decide that they've missed interrupts?
--
dwmw2
-
To unsubscribe
[EMAIL PROTECTED] said:
IRR for interrupt 19 is set, that means the IO APIC has sent the
interrupt to a cpu but not yet received the corresponding EOI.
OK, but couldn't we reset it by sending an extra EOI when the drivers
decide that they've missed interrupts?
How?
You send an
On Fri, Jan 12, 2001 at 06:16:36PM +0100, Manfred Spraul wrote:
I would first concentrate on the differences between 2.2 and 2.4:
Frank, could you try what happens with the NMI oopser disabled?
Here's the results with nmi_watchdog=0
Before network hang (nmi_watchdog=0)
Frank de Lange wrote:
On Fri, Jan 12, 2001 at 06:16:36PM +0100, Manfred Spraul wrote:
I would first concentrate on the differences between 2.2 and 2.4:
Frank, could you try what happens with the NMI oopser disabled?
Here's the results with nmi_watchdog=0
After network hang
On Fri, Jan 12, 2001 at 06:51:36PM +0100, Manfred Spraul wrote:
Frank, I've attached a proposed kick_IOAPIC pin. Could you try it?
I'm rebooting with that patch right now.
I added the patch, and tried it out. When the network hangs, I am able to revive it
with ALT-SYSRQ-Q. The debug log shows
Linus wrote:
Does this seem to happen mainly with drivers that use "disable_irq()"
and "enable_irq()"? I know the ne drivers do (through the 8390 module),
and some others do too (3c59x).
I removed the disable_irq lines from 8390.c, and that fixed the problem:
no hang within 2 minutes - the
On Fri, Jan 12, 2001 at 08:04:24PM +0100, Manfred Spraul wrote:
Linus wrote:
Does this seem to happen mainly with drivers that use "disable_irq()"
and "enable_irq()"? I know the ne drivers do (through the 8390 module),
and some others do too (3c59x).
I removed the disable_irq lines
On Fri, Jan 12, 2001 at 08:04:24PM +0100, Manfred Spraul wrote:
I removed the disable_irq lines from 8390.c, and that fixed the problem:
no hang within 2 minutes - the test is still running.
Frank, could you double check it?
I'm currently running my own patched version, which uses
Frank de Lange wrote:
On Fri, Jan 12, 2001 at 08:04:24PM +0100, Manfred Spraul wrote:
I removed the disable_irq lines from 8390.c, and that fixed the problem:
no hang within 2 minutes - the test is still running.
Frank, could you double check it?
I'm currently running my own patched
On Fri, Jan 12, 2001 at 08:33:15PM +0100, Manfred Spraul wrote:
Frank, the 2.4.0 contains 2 band aids that were added for ne2k smp:
* From Ingo: focus cpu disabled, in arch/i386/kernel/apic.c
* From myself: TARGET_CPU = cpu_online_mask, was 0xFF.
Could you disable both bandaids? I
On Fri, Jan 12, 2001 at 11:59:25AM -0800, Linus Torvalds wrote:
Could this really be the solution?
I'd like to know _which_ of the two makes a difference (or does it only
trigger with both of them enabled)? And even then I'm not sure that it is
"the" solution - both changes to io-apic
Remind me: what polarity are your io-apic irq's? Level, edge, sideways?
Anything else that might be relevant?
Well, sideways ofcourse! :-)
here's a cat /proc/interrupts from the (BP6) box:
CPU0 CPU1
0: 104936 105433IO-APIC-edge timer
1:
On Thu, Jan 11, 2001 at 02:23:53PM -0500, Jeff Garzik wrote:
> Just out of curiosity, if you boot a Linux 2.4.0 kernel with the
> "noapic" command line option, does behavior improve?
For the curious, here's a summary of some tests I did:
apic, 2 cpu's, no smp affinity -> network hangs under
On Thu, Jan 11, 2001 at 04:47:00PM -0500, Jeff Garzik wrote:
> Are you judging based on the error message? The 'netdev watchdog ...'
> message is a generic error message that could have any number of
> causes. It's just saying, well, what it says :) The kernel was unable
> to transmit a packet
Frank de Lange wrote:
>
> OK, just one last addition to what has nearly become my own thread...
>
> I now am fairly certain that the problem (network stalls on multiprocessor systems)
>is not BP6 or NE2K-PCI specific. I found several postings which relate to similar
>problems on dissimilar
OK, just one last addition to what has nearly become my own thread...
I now am fairly certain that the problem (network stalls on multiprocessor systems) is
not BP6 or NE2K-PCI specific. I found several postings which relate to similar
problems on dissimilar hardware. Another interesting one
Hm, the noapic option seems to help, as I'm currently beating the network to
death but it won't die... As the problem is elusive, it is hard to tell, and it
would not surprise me if the net dropped dead the moment this mail went
through, but current indication is that noapic makes the sudden
Another observation wrt. behaviour with 'noapic'...
When streaming time-critical data over the network (running esound to another
server, etc), sometimes there are hiccups in the stream. These hiccups seem to
be much less frequent, if at all present, when running with 'noapic'. I'm
currently
Here's another posting to the list which mentions problems with NE2K and BP6:
http://web.gnu.walfield.org/mail-archive/linux-kernel/2000-August/0132.html
"...In another machine, a dual celeron abit-bp6, recent 2.3.x kernels seem to
dislike my realtek 8029 NIC. (I know, it's garbage plugged in
> Do you get any transmit timeout messages in the logs? If
> so, send them.
In addition to my previous message, here's what I get from the debug log
facility:
Jan 10 22:56:51 behemoth kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jan 10 22:56:51 behemoth kernel: eth0: Tx timed out, lost
On Thu, Jan 11, 2001 at 10:48:23PM +1100, Andrew Morton wrote:
> Losing both NICs at the same time could be the elusive "APIC
> stops generating interrupts" problem.
Yup, that's what I thought... But the real question is, is this a
software/configuration problem or a hardware problem which can
Frank de Lange wrote:
>
> Hi'all,
>
> Ever since I put two ethernet-cards (cheap Winbond W89C940 based PCI NE2K
> clones) in my BP-6 system, I've been experiencing intermittent network hangs. A
> hang manifests itself as a total failure to communicate through either network
> card, and can only
Frank de Lange wrote:
Hi'all,
Ever since I put two ethernet-cards (cheap Winbond W89C940 based PCI NE2K
clones) in my BP-6 system, I've been experiencing intermittent network hangs. A
hang manifests itself as a total failure to communicate through either network
card, and can only be
On Thu, Jan 11, 2001 at 10:48:23PM +1100, Andrew Morton wrote:
Losing both NICs at the same time could be the elusive "APIC
stops generating interrupts" problem.
Yup, that's what I thought... But the real question is, is this a
software/configuration problem or a hardware problem which can
Do you get any transmit timeout messages in the logs? If
so, send them.
In addition to my previous message, here's what I get from the debug log
facility:
Jan 10 22:56:51 behemoth kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jan 10 22:56:51 behemoth kernel: eth0: Tx timed out, lost
Here's another posting to the list which mentions problems with NE2K and BP6:
http://web.gnu.walfield.org/mail-archive/linux-kernel/2000-August/0132.html
"...In another machine, a dual celeron abit-bp6, recent 2.3.x kernels seem to
dislike my realtek 8029 NIC. (I know, it's garbage plugged in
Another observation wrt. behaviour with 'noapic'...
When streaming time-critical data over the network (running esound to another
server, etc), sometimes there are hiccups in the stream. These hiccups seem to
be much less frequent, if at all present, when running with 'noapic'. I'm
currently
Hm, the noapic option seems to help, as I'm currently beating the network to
death but it won't die... As the problem is elusive, it is hard to tell, and it
would not surprise me if the net dropped dead the moment this mail went
through, but current indication is that noapic makes the sudden
OK, just one last addition to what has nearly become my own thread...
I now am fairly certain that the problem (network stalls on multiprocessor systems) is
not BP6 or NE2K-PCI specific. I found several postings which relate to similar
problems on dissimilar hardware. Another interesting one
Frank de Lange wrote:
OK, just one last addition to what has nearly become my own thread...
I now am fairly certain that the problem (network stalls on multiprocessor systems)
is not BP6 or NE2K-PCI specific. I found several postings which relate to similar
problems on dissimilar
On Thu, Jan 11, 2001 at 04:47:00PM -0500, Jeff Garzik wrote:
Are you judging based on the error message? The 'netdev watchdog ...'
message is a generic error message that could have any number of
causes. It's just saying, well, what it says :) The kernel was unable
to transmit a packet in
On Thu, Jan 11, 2001 at 02:23:53PM -0500, Jeff Garzik wrote:
Just out of curiosity, if you boot a Linux 2.4.0 kernel with the
"noapic" command line option, does behavior improve?
For the curious, here's a summary of some tests I did:
apic, 2 cpu's, no smp affinity - network hangs under load
On Wed, Jan 10, 2001 at 11:21:49PM +0100, Manfred Spraul wrote:
> > which should work, they are
> > NON-busmastering cards after all...),
> third line in w840_probe1():
>
> pci_set_master().
>
> And the documentation begins with
> W89C840F
> PCI Bus Master Fast Ethernet LAN
On Wed, Jan 10, 2001 at 11:21:49PM +0100, Manfred Spraul wrote:
> Which driver do you use? The driver in 2.4.0 contains several bugfixes.
> If that driver still hangs then I'll double check the documentation.
The NE2K PCI one... I'll try to fiddle around with the driver, who knows...
> And the
Frank de Lange wrote:
>
> Hi'all,
>
> Ever since I put two ethernet-cards (cheap Winbond W89C940 based PCI NE2K
> clones) in my BP-6 system, I've been experiencing intermittent network hangs.
>
Which driver do you use? The driver in 2.4.0 contains several bugfixes.
If that driver still hangs
Frank de Lange wrote:
Hi'all,
Ever since I put two ethernet-cards (cheap Winbond W89C940 based PCI NE2K
clones) in my BP-6 system, I've been experiencing intermittent network hangs.
Which driver do you use? The driver in 2.4.0 contains several bugfixes.
If that driver still hangs then
On Wed, Jan 10, 2001 at 11:21:49PM +0100, Manfred Spraul wrote:
Which driver do you use? The driver in 2.4.0 contains several bugfixes.
If that driver still hangs then I'll double check the documentation.
The NE2K PCI one... I'll try to fiddle around with the driver, who knows...
And the
On Wed, Jan 10, 2001 at 11:21:49PM +0100, Manfred Spraul wrote:
which should work, they are
NON-busmastering cards after all...),
third line in w840_probe1():
pci_set_master().
And the documentation begins with
W89C840F
PCI Bus Master Fast Ethernet LAN Controller.
...in
68 matches
Mail list logo
