Re: Repeatable 2.4.0-test13-pre4 nfsd Oops rears it head again

Re: Repeatable 2.4.0-test13-pre4 nfsd Oops rears it head again

[David S. Miller]

Try pre5

Later,
David S. Miller
davem@redhat.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Repeatable 2.4.0-test13-pre4 nfsd Oops rears it head again

[Mike Elmore]

[-- Attachment #1: Type: text/plain, Size: 381 bytes --]

All,

Had another nfsd oops today.  I was listening to a mp3
that is located on a nfs partition mounted off the machine
that oops'd with no other network activity.

Ksymoops output is attached as well as the regular console
text.

What the heck, I say what the heck is goin on here?

-- 


Mike Elmore
mike@kre8tive.org

"Never confuse activity with accomplishment."
				-unknown


[-- Attachment #2: sodham-crash2.ksymoops --]
[-- Type: text/plain, Size: 3842 bytes --]

ksymoops 2.3.5 on i686 2.4.0-test13-pre4.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.0-test13-pre4/ (default)
     -m /usr/src/linux/System.map (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

kre8tive.org login: Unable to handle kernel paging request at virtual address dbdbdc17
 c01e78b6      
 *pde = 00000000
 Oops: 0000     
 CPU:    0 
 EIP:    0010:[<c01e78b6>]
Using defaults from ksymoops -t elf32-i386 -a i386
 EFLAGS: 00010286         
 eax: dbdbdbdb   ebx: c1324140   ecx: c3de4f20   edx: 000005c8
 esi: c3de4f20   edi: 00000000   ebp: 00000000   esp: c22d3c68
 ds: 0018   es: 0018   ss: 0018                               
 Process nfsd (pid: 637, stackpage=c22d3000)
 Stack: c2a02da0 00000000 c3de4f20 0000bbfa 000005c8 c2a02da0 012e3b11 c01e7cd9 
        c2a02da0 c3de4f20 c02e3b4c c22d2000 c23c8680 c3de4f20 c2481010 0101a8c0 
        c22d2000 dbdbdbdb c482a15f c3de4f20 c482c41c c22d3d84 00000003 c22d3d94 
Call Trace: [<c01e7cd9>] [<dbdbdbdb>] [<c482a15f>] [<c482c41c>] [<c4828fc9>] [<c482c41c>] [<c012b9f9>] 
[<c482755a>] [<c01ea33c>] [<c01e1c1c>] [<c01ea33c>] [<c01e1ed1>] [<c01ea33c>] [<c482c41c>] [<c01e9938>] 
[<c01ea33c>] [<c01e9a6e>] [<c01ffe38>] [<c02002cc>] [<c01ffe38>] [<c0205bc8>] [<c0205c06>] [<c01d764d>] 
[<c0205bc8>] [<c0217074>] [<c0217581>] [<c02184d6>] [<c0216c14>] [<c0175b2a>] [<c01074bb>]
Code: 8b 40 3c 8b 4c 24 20 89 41 3c 8b 74 24 24 c7 46 18 00 00 00

>>EIP; c01e78b6 <ip_frag_queue+23e/2a4>   <=====
Trace; c01e7cd9 <ip_defrag+ed/184>
Trace; dbdbdbdb <END_OF_CODE+17581564/????>
Trace; c482a15f <[ip_conntrack]ip_ct_gather_frags+3b/c8>
Trace; c482c41c <[ip_conntrack]ip_conntrack_local_out_ops+0/18>
Trace; c4828fc9 <[ip_conntrack]ip_conntrack_in+39/32c>
Trace; c482c41c <[ip_conntrack]ip_conntrack_local_out_ops+0/18>
Trace; c012b9f9 <kmem_cache_grow+1a1/268>
Trace; c482755a <[ip_conntrack]ip_conntrack_local+5a/60>
Trace; c01ea33c <output_maybe_reroute+0/14>
Trace; c01e1c1c <nf_iterate+34/90>
Trace; c01ea33c <output_maybe_reroute+0/14>
Trace; c01e1ed1 <nf_hook_slow+79/f8>
Trace; c01ea33c <output_maybe_reroute+0/14>
Trace; c482c41c <[ip_conntrack]ip_conntrack_local_out_ops+0/18>
Trace; c01e9938 <ip_build_xmit_slow+3a0/488>
Trace; c01ea33c <output_maybe_reroute+0/14>
Trace; c01e9a6e <ip_build_xmit+4e/320>
Trace; c01ffe38 <udp_getfrag+0/c4>
Trace; c02002cc <udp_sendmsg+388/414>
Trace; c01ffe38 <udp_getfrag+0/c4>
Trace; c0205bc8 <inet_sendmsg+0/44>
Trace; c0205c06 <inet_sendmsg+3e/44>
Trace; c01d764d <sock_sendmsg+81/a4>
Trace; c0205bc8 <inet_sendmsg+0/44>
Trace; c0217074 <svc_sendto+8c/d4>
Trace; c0217581 <svc_udp_sendto+35/64>
Trace; c02184d6 <svc_send+7a/124>
Trace; c0216c14 <svc_process+2f8/544>
Trace; c0175b2a <nfsd+1ca/358>
Trace; c01074bb <kernel_thread+23/30>
Code;  c01e78b6 <ip_frag_queue+23e/2a4>
00000000 <_EIP>:
Code;  c01e78b6 <ip_frag_queue+23e/2a4>   <=====
   0:   8b 40 3c                  mov    0x3c(%eax),%eax   <=====
Code;  c01e78b9 <ip_frag_queue+241/2a4>
   3:   8b 4c 24 20               mov    0x20(%esp,1),%ecx
Code;  c01e78bd <ip_frag_queue+245/2a4>
   7:   89 41 3c                  mov    %eax,0x3c(%ecx)
Code;  c01e78c0 <ip_frag_queue+248/2a4>
   a:   8b 74 24 24               mov    0x24(%esp,1),%esi
Code;  c01e78c4 <ip_frag_queue+24c/2a4>
   e:   c7 46 18 00 00 00 00      movl   $0x0,0x18(%esi)

Kernel panic: Aiee, killing interrupt handler!

1 warning issued.  Results may not be reliable.

[-- Attachment #3: sodham-crash2.txt --]
[-- Type: text/plain, Size: 1405 bytes --]

Red Hat Linux release 7.0 (Guinness)
Kernel 2.4.0-test13-pre4 on an i686

kre8tive.org login: Unable to handle kernel paging request at virtual address dbdbdc17
 printing eip:                                                                        
 c01e78b6      
 *pde = 00000000
 Oops: 0000     
 CPU:    0 
 EIP:    0010:[<c01e78b6>]
 EFLAGS: 00010286         
 eax: dbdbdbdb   ebx: c1324140   ecx: c3de4f20   edx: 000005c8
 esi: c3de4f20   edi: 00000000   ebp: 00000000   esp: c22d3c68
 ds: 0018   es: 0018   ss: 0018                               
 Process nfsd (pid: 637, stackpage=c22d3000)
 Stack: c2a02da0 00000000 c3de4f20 0000bbfa 000005c8 c2a02da0 012e3b11 c01e7cd9 
        c2a02da0 c3de4f20 c02e3b4c c22d2000 c23c8680 c3de4f20 c2481010 0101a8c0 
        c22d2000 dbdbdbdb c482a15f c3de4f20 c482c41c c22d3d84 00000003 c22d3d94 
Call Trace: [<c01e7cd9>] [<dbdbdbdb>] [<c482a15f>] [<c482c41c>] [<c4828fc9>] [<c482c41c>] [<c012b9f9>] 
[<c482755a>] [<c01ea33c>] [<c01e1c1c>] [<c01ea33c>] [<c01e1ed1>] [<c01ea33c>] [<c482c41c>] [<c01e9938>] 
[<c01ea33c>] [<c01e9a6e>] [<c01ffe38>] [<c02002cc>] [<c01ffe38>] [<c0205bc8>] [<c0205c06>] [<c01d764d>] 
[<c0205bc8>] [<c0217074>] [<c0217581>] [<c02184d6>] [<c0216c14>] [<c0175b2a>] [<c01074bb>]
Code: 8b 40 3c 8b 4c 24 20 89 41 3c 8b 74 24 24 c7 46 18 00 00 00
Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing           

Re: Repeatable 2.4.0-test13-pre4 nfsd Oops rears it head again

[Mike Elmore]

All,

You are some damn smart people.

Whatever evil was happening is fixed in test13-pre5.

I pounded it with 3 successive full backups of my
multigig nfs mounted home directory to my Onstream
drive while downloading a kernel and doing multiple
>100M file copies over nfs at the same time while
playing an mp3 off a nfs mounted partition.

It was moving slow cause the card is 10mbs, but all
jobs finished and the machine is now sitting idle
as happy as can be.

Any idea what portion of pre4 got fixed in pre5 to
fix this problem?  I'd just like to know so I can
look around if it comes back.

Sorta related:

I really need to get rid of this 8139 card.  Since
yall are the oracle, which nice 100mbs card is fine
hardware and is coupled with a well debugged driver?

I don't want to have any more network card problems.
I'm tired of this crappy 8139.

-mwe


On Thu, Dec 28, 2000 at 01:59:03PM -0800, David S. Miller wrote:
> 
> Try pre5
> 
> Later,
> David S. Miller
> davem@redhat.com
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/

-- 


Mike Elmore
mike@kre8tive.org

"Never confuse activity with accomplishment."
				-unknown

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Repeatable 2.4.0-test13-pre4 nfsd Oops rears it head again

[Chris Wedgwood]

On Thu, Dec 28, 2000 at 09:21:16PM -0600, Mike Elmore wrote:

    Any idea what portion of pre4 got fixed in pre5 to
    fix this problem?  I'd just like to know so I can
    look around if it comes back.

nfs over UDP? My guess is the IP fragmentation fix Alexey posted a
couple of days ago.


  --cw
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Repeatable 2.4.0-test13-pre4 nfsd Oops rears it head again

[Linus Torvalds]

In article <20001228212116.A968@lingas.basement.bogus>,
Mike Elmore  <mike@kre8tive.org> wrote:
>
>I really need to get rid of this 8139 card.  Since
>yall are the oracle, which nice 100mbs card is fine
>hardware and is coupled with a well debugged driver?

There are always problems with some hardware, but my personal
recommendation for a card would definitely be the Intel Ethernet Pro 100
series (82557). 

Unlike the tulip cards (which are pretty good too), there aren't a
million different versions of it.  There's a few, but it's not a big
mess.  It performs well, and is stable.  It's pretty well documented
(apart from the magic extensions), and it's common. 

That said, some people have trouble even with that card.  Nobody knows
why, but at least the driver is actively maintained etc, so I still am
not nervous about recommending it. 

I bet that others will have other recommendations, but so far I have at
least personally had good luck with the eepro100.

		Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Repeatable 2.4.0-test13-pre4 nfsd Oops rears it head again

[David Ford]

[-- Attachment #1: Type: text/plain, Size: 400 bytes --]

> I really need to get rid of this 8139 card.  Since
> yall are the oracle, which nice 100mbs card is fine
> hardware and is coupled with a well debugged driver?
>
> I don't want to have any more network card problems.
> I'm tired of this crappy 8139.

I have an 8139 card and it's on a 2.4 testN kernel that's several weeks old but
it's running like a champ at 200FD, sometimes heavily loaded.

-d


[-- Attachment #2: Card for David Ford --]
[-- Type: text/x-vcard, Size: 274 bytes --]

begin:vcard 
n:Ford;David
x-mozilla-html:TRUE
url:www.blue-labs.org
adr:;;;;;;
version:2.1
email;internet:david@blue-labs.org
title:Blue Labs Developer
note;quoted-printable:GPG key: http://www.blue-labs.org/david@nifty.key=0D=0A
x-mozilla-cpt:;9952
fn:David Ford
end:vcard

Re: Repeatable 2.4.0-test13-pre4 nfsd Oops rears it head again

[Chris Wedgwood]

On Thu, Dec 28, 2000 at 10:15:17PM -0800, Linus Torvalds wrote:

    I bet that others will have other recommendations, but so far I
    have at least personally had good luck with the eepro100.

I have (and still do) use 3c59x, 3c90x cards, eepro100 and tulips
cards. They all work reasonably well except they all have their own
quirks and none of them are as reliable as (say) the hme cards in our
Solaris machines.

Nor are they as reliable as the same hardware under FreeBSD, which is
somewhat embarrassing.

I have to wonder -- am I jinxed or do other people also find this?

I'm also slightly perturbed by the fact there is no easy way to set
media and duplex on all the cards. This was discussed on netdev not
long ago and I tried hacking ethtool support into the 3c59x code but
its far from a clean job. I'm not sure how simple this would be for
other drivers. Both Solaris and FreeBSD let you set media and duplex
in a uniform way; it's a pity Linux cannot.



  --cw

P.S. FWIW I'm currently trying to standardize on eepro100 cards; so
     far so good except nder sustained load (i.e. 100M full duplex
     completely saturated for many minutes) I get:

	eth1: card reports no resources.

     messages. Looking at the driver source code I can't see wy these
     might occur (I don't have the specs, I'm just going by the
     surrounding code). No harm, but what seems like a slight
     slowdown when this occurs.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Repeatable 2.4.0-test13-pre4 nfsd Oops rears it head again

[Andrew Morton]

Linus Torvalds wrote:
> 
> I bet that others will have other recommendations, but so far I have at
> least personally had good luck with the eepro100.

The 3c905C is a well manufactured and very feature-rich NIC which at
present appears to have fewer problem reports than eepro100, 8139 or tulip.

Available in PCI, Cardbus, Mini-PCI.  A dual-interface PCI version has
just been released (3c982), although we've yet to hear of anyone trying
it with Linux.

3com provide full specs without any NDA restrictions, plus a GPL'ed
driver.

Perhaps most significantly, the 905 has full scatter/gather support.
This isn't used at present, but Alexey's zerocopy-sendfile patches
do utilise it.  He currently has scatter-gather support for acenic,
3c905 and sunhme.  I don't know what the plans are to support other
100 mbps NICs.

The in-kernel 3c59x.c isn't the world's fastest driver.  On the todo list
for 2.5 is MMIO support, scatter-gather maintenance, optional use of DPD
polling and implementation of the onboard multicast hash filter. And 
implementation of the on-board VLAN support if 2.5 becomes VLAN-capable.

-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Repeatable 2.4.0-test13-pre4 nfsd Oops rears it head again

[Francois Romieu]

Andrew Morton <andrewm@uow.edu.au> écrit :
[...]
> The 3c905C is a well manufactured and very feature-rich NIC which at
> present appears to have fewer problem reports than eepro100, 8139 or tulip.

I guess that the lack of problem reports for the epic chipset comes from
a smaller user base. FWIW, I haven't experienced real problems with
it (observation base: 20~30 boards). Neither did I with the few 3c905 used btw.

[...]
> Perhaps most significantly, the 905 has full scatter/gather support.

May be done for the epic. TODO++

-- 
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

NIC recommendations (was Re: Repeatable 2.4.0-test13-pre4...)

[Barry K. Nathan]

Andrew Morton wrote:
> The 3c905C is a well manufactured and very feature-rich NIC which at
> present appears to have fewer problem reports than eepro100, 8139 or tulip.

3c905c is a bit expensive, though. pcnet32 cards also work very well for
me, and are less expensive. The 905c could be a better card (I don't
really know), but pcnet32's might be more cost-effective, depending
on your needs. (I've seen pcnet32-based cards selling for $15-20, and
I bought a new 10-pack (of HP NightDirector 10/100's) for about $36,
including shipping, on eBay.)
 
In any case, tulips have been more problematic for me than 8139, pcnet32,
or 3c905c (whose reliability are all comparable IME). I've never tried
eepro100, though. (Also, I'm speaking in terms of my experiences across
all OS's which I've used the cards under, not just under Linux, although
my Linux experiences are similar to the experiences I've had overall.)

Anyway, those are my experiences and recommendations. YMMV. :)

-Barry K. Nathan <barryn@pobox.com>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: NIC recommendations (was Re: Repeatable 2.4.0-test13-pre4...)

[H. Peter Anvin]

Followup to:  <200012302301.eBUN1IF01354@pobox.com>
By author:    "Barry K. Nathan" <barryn@pobox.com>
In newsgroup: linux.dev.kernel
>  
> In any case, tulips have been more problematic for me than 8139, pcnet32,
> or 3c905c (whose reliability are all comparable IME). I've never tried
> eepro100, though. (Also, I'm speaking in terms of my experiences across
> all OS's which I've used the cards under, not just under Linux, although
> my Linux experiences are similar to the experiences I've had overall.)
> 

I have used eepro100's on *a lot* of boxes, including *.kernel.org;
haven't had any problems whatsoever any time recently.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Repeatable 2.4.0-test13-pre4 nfsd Oops rears it head again

[Jeff Chua]

the only thing you've to be careful is to make sure you set
the correct options for the module (if you compiled it as module).

# options=0x30 100mbps full duplex
# options=0x20 100mbps half duplex
# options=0     10mbps half duplex
options eepro100 options=0

Otherwise, it'll cause a lot of unnecessary network traffic and
slow down your network!

These are not obvious unless you read the source code.

Jeff.


>From linux-kernel-owner@vger.kernel.org  Fri Dec 29 14:14:55 2000
X-Authentication-Warning: palladium.transmeta.com: mail set sender to news@transmeta.com using -f
To: linux-kernel@vger.kernel.org
From: torvalds@transmeta.com (Linus Torvalds)
Subject: Re: Repeatable 2.4.0-test13-pre4 nfsd Oops rears it head again
Date: 	28 Dec 2000 22:15:17 -0800
Organization: Transmeta Corporation
In-Reply-To: <20001228161126.A982@lingas.basement.bogus> <200012282159.NAA00929@pizda.ninka.net> <20001228212116.A968@lingas.basement.bogus>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
X-Mailing-List: 	linux-kernel@vger.kernel.org

In article <20001228212116.A968@lingas.basement.bogus>,
Mike Elmore  <mike@kre8tive.org> wrote:
>
>I really need to get rid of this 8139 card.  Since
>yall are the oracle, which nice 100mbs card is fine
>hardware and is coupled with a well debugged driver?

There are always problems with some hardware, but my personal
recommendation for a card would definitely be the Intel Ethernet Pro 100
series (82557). 

Unlike the tulip cards (which are pretty good too), there aren't a
million different versions of it.  There's a few, but it's not a big
mess.  It performs well, and is stable.  It's pretty well documented
(apart from the magic extensions), and it's common. 

That said, some people have trouble even with that card.  Nobody knows
why, but at least the driver is actively maintained etc, so I still am
not nervous about recommending it. 

I bet that others will have other recommendations, but so far I have at
least personally had good luck with the eepro100.

		Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Repeatable 2.4.0-test13-pre4 nfsd Oops rears it head again

[Ray Strode]

> I don't want to have any more network card problems.
> I'm tired of this crappy 8139.
hmmm... The only cards I'll buy are 8139 based (SMC EZNet 10/100).
They have worked great on every OS i've tried and only cost 14 bucks 
at my local CompUSA.  I love em to pieces... The newer ones are only
like an inch tall too.. very slick.

--Ray

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/