Repeatable 2.4.0-test13-pre4 nfsd Oops rears it head again
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?
Signature · 5 lines
Mike Elmore [email protected] "Never confuse activity with accomplishment." -unknown
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 00Quoted 1 line
Quoted 1 line
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.
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
Try pre5
Later,
David S. Miller
[email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
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
Quoted 1 line
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
Quoted 10 lines · David S. Miller
Try pre5
Later,
David S. Miller
[email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Signature · 10 lines
Mike Elmore [email protected] "Never confuse activity with accomplishment." -unknown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] Please read the FAQ at http://www.tux.org/lkml/
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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/
In article <[email protected]>,
Quoted 4 lines · Mike Elmore
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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 6 lines
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
begin:vcard
n:Ford;David
x-mozilla-html:TRUE
url:www.blue-labs.org
adr:;;;;;;
version:2.1
email;internet:[email protected]
title:Blue Labs Developer
note;quoted-printable:GPG key: http://www.blue-labs.org/[email protected]=0D=0A
x-mozilla-cpt:;9952
fn:David Ford
end:vcard
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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 3 lines · Linus Torvalds
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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/
NIC recommendations (was Re: Repeatable 2.4.0-test13-pre4...)
Quoted 2 lines · Andrew Morton
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 <[email protected]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Re: NIC recommendations (was Re: Repeatable 2.4.0-test13-pre4...)
In reply to Andrew MortonFollowup to: <[email protected]> By author: "Barry K. Nathan" <[email protected]> In newsgroup: linux.dev.kernel
Quoted 7 lines
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
Signature · 7 lines
<[email protected]> at work, <[email protected]> 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 [email protected] Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton <[email protected]> écrit :
[...]
Quoted 2 lines
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.
[...]
Quoted 1 line
Perhaps most significantly, the 905 has full scatter/gather support.
May be done for the epic. TODO++
Signature · 5 lines
Ueimor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] Please read the FAQ at http://www.tux.org/lkml/