oops in 2.4.1-pre8

oops in 2.4.1-pre8

[Scott A. Sibert]

Hello.

I've got a Dell Precision 420 (dual P3/800 w/1gb RDRAM).

I'm consistently getting an oops when accessing any smbfs mount whether 
running 'ls' inside the smbfs mount or hitting TAB for filename 
completion of a directory in an smbfs mount.  I have another machine 
(dual P2/300 w/320MB memory) that does not have this problem.  The P2 
has an eepro100 ethernet card whereas the Dell has the built-in 3c920 
(3c905c emulation).

Below is the ksymoops output.  The oops screen I manually typed onto my 
other computer because the /var/log/messages file gets corrupted when 
this occurs and I don't know how to save the oops screen on the computer 
itself.  SAR-S, SAR-U say they're doing to do their action but do not 
actually sync or remount the disks.  CAD does not reboot the computer. 
SAR-B does reboot the machine though.

Unable to handle kernel NULL pointer dereference at virtual address 00000000
c012b2fb
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0010:[<c012b2fb>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202
eax: 00000001   ebx: 00000000   ecx: c02ea430   edx: 0003ff9e
esi: c2093878   edi: 00000000   ebp: f7e00004   esp: f73b3e18
ds: 0018   es: 0018   ss: 0018
Process ls (pid: 862, stackpage=f73b3000)
Stack: c02ea430 c02ea690 f73b3e4c 00000000 c2093878 f7e00004 f73b3e4c 
00000001
      c012e829 c2093878 00000000 00000001 f7300004 c2093878 c019344a 
f7918e9c
      c0000000 00000012 00000000 fe1ec014 0000001a 00000012 c019218b 
00000000
Call Trace: [<c012e829>] [<c019344a>] [<c019218b>] [<f8957a20>] 
[<f8959188>] [<c018fde6>] [<f8959048>]
      [<f895903c>] [<c0191364>] [<c0192259>] [<c0191569>] [<c014e338>] 
[<c014e140>] [<c0109113>]
Code: 8b 07 ff 47 18 89 70 04 89 06 89 7e 04 89 37 89 7e 08 8b 55

 >>EIP; c012b2fb <add_to_page_cache_unique+bb/120>   <=====
Trace; c012e829 <grab_cache_page+79/a0>
Trace; c019344a <smb_trans2_request+18a/1f0>
Trace; c019218b <smb_add_to_cache+fb/180>
Trace; f8957a20 <__module_using_checksums+3b52/???
Trace; f8959188 <__module_using_checksums+52ba/???
Trace; c018fde6 <smb_proc_readdir_long+456/4d0>
Trace; f8959048 <__module_using_checksums+517a/???
Trace; f895903c <__module_using_checksums+516e/???
Trace; c0191364 <smb_proc_readdir+24/40>
Trace; c0192259 <smb_refill_dircache+29/70>
Trace; c0191569 <smb_readdir+d9/190>
Trace; c014e338 <sys_getdents64+b8/170>
Trace; c014e140 <filldir64+0/140>
Trace; c0109113 <system_call+33/38>
Code;  c012b2fb <add_to_page_cache_unique+bb/120>
00000000 <_EIP>:
Code;  c012b2fb <add_to_page_cache_unique+bb/120>   <=====
  0:   8b 07                     mov    (%edi),%eax   <=====
Code;  c012b2fd <add_to_page_cache_unique+bd/120>
  2:   ff 47 18                  incl   0x18(%edi)
Code;  c012b300 <add_to_page_cache_unique+c0/120>
  5:   89 70 04                  mov    %esi,0x4(%eax)
Code;  c012b303 <add_to_page_cache_unique+c3/120>
  8:   89 06                     mov    %eax,(%esi)
Code;  c012b305 <add_to_page_cache_unique+c5/120>
  a:   89 7e 04                  mov    %edi,0x4(%esi)
Code;  c012b308 <add_to_page_cache_unique+c8/120>
  d:   89 37                     mov    %esi,(%edi)
Code;  c012b30a <add_to_page_cache_unique+ca/120>
  f:   89 7e 08                  mov    %edi,0x8(%esi)
Code;  c012b30d <add_to_page_cache_unique+cd/120>
  12:   8b 55 00                  mov    0x0(%ebp),%edx

Ethernet is compiled into the kernel as is smbfs (not as modules).  I've 
compiled this kernel with 4GB bigmem support (otherwise I only get 8xxMB 
total).

If anyone needs more please let me know.

--Scott

-
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: oops in 2.4.1-pre8

[Urban Widmark]

On Wed, 17 Jan 2001, Scott A. Sibert wrote:

> I'm consistently getting an oops when accessing any smbfs mount whether
> running 'ls' inside the smbfs mount or hitting TAB for filename
> completion of a directory in an smbfs mount.  I have another machine
> (dual P2/300 w/320MB memory) that does not have this problem.  The P2

That other machine is not compiled with bigmem, I assume.


> Ethernet is compiled into the kernel as is smbfs (not as modules).  I've
> compiled this kernel with 4GB bigmem support (otherwise I only get 8xxMB
> total).

The smbfs cache code in 2.4.0 doesn't work with bigmem. For now disable
bigmem or don't use smbfs, it's oopsing all the time.

Rainer Mager reported the same thing yesterday ("Oops with 4GB memory
setting in 2.4.0 stable" if you want to read the thread).

I am currently looking into this ... what kind of server are you
connecting to? win2k/NT4/9x? It is easier to test with those than the more
exotic OS/2 & NetApp.

/Urban

-
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: oops in 2.4.1-pre8

[Scott A. Sibert]

Hi Urban.

I'm connecting to a Win2K server (same share between computers).  A 
slight change in my previous post:  my dual P2 w/320MB appears to be 
running 2.4.0-ac9 instead of 2.4.1-pre8.  The bigmem machine (1gb mem) 
had the oops on 2.4.0-ac9 but before reporting I thought I'd try 
2.4.1-pre8 and see if it also had the oops.  (This morning the small mem 
machine had a problem but I'll put that in a separate email.)

Earlier I had tried 2.4.0-test12 but it partially scrambled my root 
partition so I went back to 2.2.19-pre2.  After the oops I tried 2.4.0 
straight but when it was booting it decided my root partition had been 
umounted not-cleanly and decided it needed to do lots of icky things to 
my root partition.  I just rebooted it (without letting it do any 
changes) and went back into 2.4.1-pre8 and let it clean up the root 
partition.  So I don't know if 2.4.0 straight would do this (apparently 
it does from other people's reports) since 2.4.0 didn't want to play 
nice on my machine.

Since I can't do without smbfs I guess I'll have to do without bigmem.  
Please let me know when you're ready to test some fixes; I would be glad 
to help testing.

--Scott


Urban Widmark wrote:

> On Wed, 17 Jan 2001, Scott A. Sibert wrote:
> 
>> I'm consistently getting an oops when accessing any smbfs mount whether
>> running 'ls' inside the smbfs mount or hitting TAB for filename
>> completion of a directory in an smbfs mount.  I have another machine
>> (dual P2/300 w/320MB memory) that does not have this problem.  The P2
> 
> 
> That other machine is not compiled with bigmem, I assume.
> 
> 
>> Ethernet is compiled into the kernel as is smbfs (not as modules).  I've
>> compiled this kernel with 4GB bigmem support (otherwise I only get 8xxMB
>> total).
> 
> 
> The smbfs cache code in 2.4.0 doesn't work with bigmem. For now disable
> bigmem or don't use smbfs, it's oopsing all the time.
> 
> Rainer Mager reported the same thing yesterday ("Oops with 4GB memory
> setting in 2.4.0 stable" if you want to read the thread).
> 
> I am currently looking into this ... what kind of server are you
> connecting to? win2k/NT4/9x? It is easier to test with those than the more
> exotic OS/2 & NetApp.
> 
> /Urban
> 


-
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: oops in 2.4.1-pre8

[Petr Vandrovec]

> > Ethernet is compiled into the kernel as is smbfs (not as modules).  I've
> > compiled this kernel with 4GB bigmem support (otherwise I only get 8xxMB
> > total).
> 
> The smbfs cache code in 2.4.0 doesn't work with bigmem. For now disable
> bigmem or don't use smbfs, it's oopsing all the time.
> 
> Rainer Mager reported the same thing yesterday ("Oops with 4GB memory
> setting in 2.4.0 stable" if you want to read the thread).

I think that I found source of problem. I have no simple solution :-(

You are using 'page_cache_entry()' function three times. But you
are using it on kmap()ped memory (cachep, in this oops example). So
it returns almost random value, which caused 'mapping' to be set
to NULL when doing grab_page_cache(), which caused oops later in
add_to_page_cache_unique...

But I'm not 100% sure, as this would mean that you do not 
kunmap/UnlockPage/page_cache_release any >1GB page at all in 
smb_free_cache_blocks(), as page pointer obtained by page_cache_entry()
points to some random page (to couple just below 1GB boundary) instead 
of to correct one, so smbfs should die as soon as it finds first highmem
page... Is it possible?

Same problem is in smb_free_dircache. 

You can try using __find_get_page() with index to get 'struct *page' 
(it should always suceed, as you have all pages locked...), instead 
of page_cache_entry(), but better solution is using couple { page, 
page_address } instead of page_address alone.

So your system has couple of chances to deadlock - either on out of
kmaps, or on locked directory cache root (cachep), or on some of locked 
directory cache pages (blocks)...

And one nonfatal ;-) In smb_add_to_cache you have:

page_off = PAGE_SIZE + (cachep->idx << PAGE_SHIFT);
page = grab_cache_page(mapping, page_off >> PAGE_CACHE_SHIFT);

This does not look correct to me. You should use PAGE_CACHE_SHIFT and
PAGE_CACHE_SIZE, as otherwise you'll receive same page for idx=1 and 2
when cache will use 8KB pages, but CPU 4KB ones. Using only first 4KB 
of each cache page is better solution, than using same page for two
different indexes, I think... But as currently PAGE_CACHE_SIZE == PAGE_SIZE...
                                        Best regards,
                                            Petr Vandrovec
                                            vandrove@vc.cvut.cz
-
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: oops in 2.4.1-pre8

[Urban Widmark]

On Thu, 18 Jan 2001, Petr Vandrovec wrote:

> > Rainer Mager reported the same thing yesterday ("Oops with 4GB memory
> > setting in 2.4.0 stable" if you want to read the thread).
>
> I think that I found source of problem. I have no simple solution :-(
>

I think the source of the problem is that this code was changed without
anyone being capable of actively maintaining it (time, knowledge,
motivation, ...). And later maintainers (me) haven't known or seen
anything wrong with it.


> But I'm not 100% sure, as this would mean that you do not
> kunmap/UnlockPage/page_cache_release any >1GB page at all in
> smb_free_cache_blocks(), as page pointer obtained by page_cache_entry()
> points to some random page (to couple just below 1GB boundary) instead
> of to correct one, so smbfs should die as soon as it finds first highmem
> page... Is it possible?

It sounds possible from the reports, where it has died as soon as it is
touched on a highmem mmachine.


> So your system has couple of chances to deadlock - either on out of
> kmaps, or on locked directory cache root (cachep), or on some of locked
> directory cache pages (blocks)...

Thanks for looking. I haven't begun to verify any of your previous
suggestions.

Copying the ncpfs cache code seems so much better. It's possibly a bigger
change (currently 20k diff -u) than to fix the cache.c code to do whatever
is right but the end result should be a lot better (I hope). Fixed size
cache entries makes lookups simpler, creating dentry/inode from the info
returned by the findfirst/findnext smb calls avoids extra calls on some
common(?) usage patterns.

Assuming your code is correct, and I'm sure it is, this should be a faster
way to do it than for me to figure out how the existing smbfs cahce can be
made to work. The differences are not that great between ncpfs and smbfs,
both are networked dos-ish filesystems. :)

My new code oopsed on me last night (and then I realized what time it
was). But so far the ncpfs code is fitting quite nicely.

/Urban

-
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/