Sorry for the previous post, I have just tried to read it and found
it very unreadable, so now I'm just trying to produce a better
formated message, I hope it doesn't gets reformated somewhere.
So, now the text again, and sorry for the waste.
Well, doing a find on my machine seems to hit a bug in 8390 module, I
have got the same Oops a two times, the first I have a nfs tree
mounted, but I could heard the hd while it was searching, the second
time I didn't have any network mounted dir, but the Oops was also in
8390.
So the Oops and some traces:
The first Oops (with an nfs mounted tree)
Unable to handle kernel NULL pointer dereference at virtual address
00000000
current->tss.cr3 = 010f7000, %cr3 = 010f7000
*pde = 00000000
Oops: 0002
CPU: 0
EIP: 0010:[8390:ei_open+-36832/96]
EFLAGS: 00010216
eax: 00000120 ebx: c3fa1edc ecx: 00000048 edx: 00000120
esi: c0d95400 edi: 00000000 ebp: 00000120 esp: c3fa1e28
ds: 0018 es: 0018 ss: 0018
Process find (pid: 2572, process nr: 87, stackpage=c3fa1000)
Stack: c484abe5 00000000 c0d95400 00000120 c3fa1edc c0b274cc c484b9c6
c3fa1edc
c0d95400 00000120 c3fa1edc c0b274cc 00000000 c3fa1f1c 00002eee
00000003
c484abcc 000000a8 c484b005 c0d95400 c4850fc8 00000004 00000200
c0b274cc
Call Trace: [8390:ei_open+-33895/96] [8390:ei_open+-30342/96]
[8390:ei_open+-33920/96] [8390:ei_open+-32839/96] [8390:ei_open+-
8324/96] [8390:ei_open+-29675/96] [8390:ei_open+-20961/96]
[8390:ei_open+-8324/96] [8390:ei_open+-33920/96]
[8390:ei_open+-20840/96] [8390:ei_open+-38703/96] [d_alloc+24/336]
[real_lookup+72/112] [lookup_dentry+266/440] [__namei+41/92]
[sys_newlstat+46/148] [system_call+52/56]
Code: f3 a5 a8 02 74 02 66 a5 a8 01 74 01 a4 5e 5f c3 57 56 8b 7c
after this I rerun the find, that ended in such way:
root@quartz:/mnt/linux2/kernel/linux-2.2.4.smp/scripts/ksymoops/ > ps
aux |grep find
root 3549 7.9 0.6 932 432 p3 D 19:27 0:21 find / -
perm 400 -typ
root 3666 0.0 0.6 852 388 p0 S 19:32 0:00 grep find
root@quartz:/mnt/linux2/kernel/linux-2.2.4.smp/scripts/ksymoops/ > ps
auxw |grep find
root 3549 7.8 0.6 932 432 p3 D 19:27 0:21 find / -
perm 400 -type f -name core -exec rm -f {} ;
root 3668 0.0 0.6 852 388 p0 S 19:32 0:00 grep find
root@quartz:/mnt/linux2/kernel/linux-2.2.4.smp/scripts/ksymoops/ > ps
auxl |grep find
0 0 3670 689 8 0 852 388 pipe_read S p0
0:00 grep find
100 0 3549 3542 0 0 932 432 down_failed D p3
0:21 find / -p
root@quartz:/mnt/linux2/kernel/linux-2.2.4.smp/scripts/ksymoops/ > ps
auxl |grep find
0 0 3672 689 4 0 852 388 pipe_read S p0
0:00 grep find
100 0 3549 3542 0 0 932 432 down_failed D p3
0:21 find / -p
root@quartz:/mnt/linux2/kernel/linux-2.2.4.smp/scripts/ksymoops/ > ps
auxl |grep find
100 0 3549 1 0 0 932 432 down_failed D ?
0:21 find / -p
0 0 3704 689 4 0 852 388 pipe_read S p0
0:00 grep find
as you can see after some time the find entered in a D state in
down_failed. It didn't want to die, even with kill -9...
Well after rebooting and a day after I made another find
find / -name "x11amp*"
And also got the same Oops (the second at the moment)
Unable to handle kernel NULL pointer dereference at virtual address
00000000
current->tss.cr3 = 023aa000, %cr3 = 023aa000
*pde = 00000000
Oops: 0002
CPU: 1
EIP: 0010:[8390:ei_open+-36832/96]
EFLAGS: 00010212
eax: 00000038 ebx: c1ac1edc ecx: 0000000e edx: 00000038
esi: c0905440 edi: 00000000 ebp: 00000038 esp: c1ac1e28
ds: 0018 es: 0018 ss: 0018
Process find (pid: 5217, process nr: 88, stackpage=c1ac1000)
Stack: c484abe5 00000000 c0905440 00000038 c1ac1edc c3a4f7fc c484b9c6
c1ac1edc
c0905440 00000038 c1ac1edc c3a4f7fc 00000000 c1ac1f1c 00005487
00000003
c484abcc 000000a8 c484b005 c0905440 c4850fc8 00000004 00000200
c3a4f7fc
Call Trace: [8390:ei_open+-33895/96] [8390:ei_open+-30342/96]
[8390:ei_open+-33920/96] [8390:ei_open+-32839/96] [8390:ei_open+-
8324/96] [8390:ei_open+-29675/96] [8390:ei_open+-20961/96]
[8390:ei_open+-8324/96] [8390:ei_open+-33920/96]
[8390:ei_open+-20840/96] [8390:ei_open+-38703/96] [d_alloc+24/336]
[real_lookup+72/112] [lookup_dentry+266/440] [__namei+41/92]
[sys_newlstat+46/148] [system_call+52/56]
Code: f3 a5 a8 02 74 02 66 a5 a8 01 74 01 a4 5e 5f c3 57 56 8b 7c
I also repeated the comand, but with ltrace -C -S to see where it
stops, and that was the results:
strrchr("/mnt/winnt/Archivos de programa/"..., '/') = "/AIR.SBJ"
fnmatch(0xbffffd0c, 0x080647cf, 4, 0x08064780, 0x08056938) = 1
strcpy(0x080647cf, "GROUND") = 0x080647cf
__lxstat(3, 0x080647cf, 0xbffff4c8, 0xbffff520, 0x08049760
<unfinished ...>
SYS_lstat(0x080647cf, 0xbffff454, 0x400a86cc, 0xbffff4c8, 86) = 0
<... __lxstat resumed> ) = 0
strrchr("/mnt/winnt/Archivos de programa/"..., '/') = "/GROUND"
fnmatch(0xbffffd0c, 0x080647cf, 4, 0x08064780, 0x08056938) = 1
__errno_location() = 0x400a9484
opendir("GROUND" <unfinished ...>
SYS_stat(0x080647cf, 0xbffff384, 0x400a86cc, 0xbffff3ec, 85) = 0
SYS_open("GROUND", 2048, 027777772310) = 5
SYS_fcntl(5, 2, 1, 0x080647cf, 85) = 0
<... opendir resumed> ) = 0x08056f00
malloc(4096) = 0x08064b88
readdir(0x08056f00 <unfinished ...>
SYS_lseek(5, 0, 1, 0x08064b88, 0x08056f00) = 0
SYS_getdents(5, 0xbfffb680, 15729, 0xbfffb680, 0x08068380
While reading a local nt mounted dir it stoped in SYS_getdents, wich
never returned, when it works ok that is what it seems:
readdir(0x08056f00 <unfinished ...>
SYS_lseek(5, 0, 1, 0x08064f90, 0x08056f00) = 0
SYS_getdents(5, 0xbffff01c, 984, 0xbffff01c, 0x08064b88) = 240
<... readdir resumed> ) = 0x08064b88
I have rebooted again and had made a find with ltrace over my hd and
nfs tree, but it didn't crash, those traces are from the second
finds, after the firts crashes and Oopses, the net works ok after
those Oopses and also the nt local dir.
>From my point of view it seems that I'm a little crazy, I don't know
why a find produces an Oops in 8390, and why the second time it stops
in a nt mounted dir.
P.S. the third, fourth, and so on also stop in the same place...
\_/, _
| @___oo ( Jorge Nerin
/\ /\ / (___,,,}_--~
) /^\) ^\/ _) ~__ [EMAIL PROTECTED]
) /^\/ _) (_
) _ / / _) ( [EMAIL PROTECTED]
/\ )/\/ || | )_)
< > |(,,) )__)
|| / \)___)\
| \____( )___) )___
\______(_______;;; __;;;
Greeetings from Zaragoza (Spain)
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
