On Thu, 18 Jan 2001, Rainer Mager wrote:
> Here is a newly parsed oops, this time using the /var/log/ksymoops method
> mentioned by Keith Owens. Does this look better?
Yes, and it sort of matches the other oops someone sent. Thanks.
I have a changed version now, based on the ncpfs directory
> smb_rename suggests mv, but the process is ls ... er? What commands where
> you running on smbfs when it crashed?
>
> Could this be a symbol mismatch? Keith Owens suggested a less manual way
> to get module symbol output. Do you get the same results using that?
Here is a newly parsed oops,
smb_rename suggests mv, but the process is ls ... er? What commands where
you running on smbfs when it crashed?
Could this be a symbol mismatch? Keith Owens suggested a less manual way
to get module symbol output. Do you get the same results using that?
Here is a newly parsed oops, this
Hi again,
It looks like some progress is being made, *wonderful*, as to some earlier
questions...
> I'll have a look tonight or so. It works for you on non-bigmem?
Yes. Absolutely no problems on non-bigmem.
> smb_rename suggests mv, but the process is ls ... er? What commands where
On Tue, 16 Jan 2001, Petr Vandrovec wrote:
> If there is new dentry, which is at fpos postion, and it is child of
> readdir-ed directory, we should return it anyway, no? There must not be
> two ncpfs dentries with same d_parent and d_fsdata if d_fsdata != 0,
> as each dentry can be in only one
On 16 Jan 01 at 21:17, Urban Widmark wrote:
> The smbfs dircache needs to find/kmap all of its cache pages since the
> entries in it are variable length and the way it is called. It would be
> nice to change that.
>
> I haven't looked at all your detailed comments yet. They may not matter if
>
On Tue, 16 Jan 2001, Petr Vandrovec wrote:
> smb_get_dircache looks suspicious to me, as it can try to map unlimited
> number of pages with kmap. And kmaps are not unlimited resource...
> You have 512 kmaps, but one SMBFS cache page can contain about 504
> pages... So two smbfs cached
On 16 Jan 01 at 9:40, Urban Widmark wrote:
> On Tue, 16 Jan 2001, Rainer Mager wrote:
>
> > Hi all,
> >
> > I have a 100% reproducable bug in all of the 2.4.0 kernels including the
> > latest stable one. The issue is that if I compile the kernel to support 4GB
> > RAM (I have 1 GB) and then
On Tue, 16 Jan 2001, Rainer Mager wrote:
> Hi all,
>
> I have a 100% reproducable bug in all of the 2.4.0 kernels including the
> latest stable one. The issue is that if I compile the kernel to support 4GB
> RAM (I have 1 GB) and then try to access a samba mount I get an oops. This
I'll
On Tue, 16 Jan 2001, Rainer Mager wrote:
Hi all,
I have a 100% reproducable bug in all of the 2.4.0 kernels including the
latest stable one. The issue is that if I compile the kernel to support 4GB
RAM (I have 1 GB) and then try to access a samba mount I get an oops. This
I'll have a
On 16 Jan 01 at 9:40, Urban Widmark wrote:
On Tue, 16 Jan 2001, Rainer Mager wrote:
Hi all,
I have a 100% reproducable bug in all of the 2.4.0 kernels including the
latest stable one. The issue is that if I compile the kernel to support 4GB
RAM (I have 1 GB) and then try to access
On Tue, 16 Jan 2001, Petr Vandrovec wrote:
smb_get_dircache looks suspicious to me, as it can try to map unlimited
number of pages with kmap. And kmaps are not unlimited resource...
You have 512 kmaps, but one SMBFS cache page can contain about 504
pages... So two smbfs cached directories
On 16 Jan 01 at 21:17, Urban Widmark wrote:
The smbfs dircache needs to find/kmap all of its cache pages since the
entries in it are variable length and the way it is called. It would be
nice to change that.
I haven't looked at all your detailed comments yet. They may not matter if
the
On Tue, 16 Jan 2001, Petr Vandrovec wrote:
If there is new dentry, which is at fpos postion, and it is child of
readdir-ed directory, we should return it anyway, no? There must not be
two ncpfs dentries with same d_parent and d_fsdata if d_fsdata != 0,
as each dentry can be in only one
Hi again,
It looks like some progress is being made, *wonderful*, as to some earlier
questions...
I'll have a look tonight or so. It works for you on non-bigmem?
Yes. Absolutely no problems on non-bigmem.
smb_rename suggests mv, but the process is ls ... er? What commands where
On Mon, 15 Jan 2001 20:09:14 -0200 (BRST),
Marcelo Tosatti <[EMAIL PROTECTED]> wrote:
>On Tue, 16 Jan 2001, Rainer Mager wrote:
>>>EIP; f889e044<=
>Trace; f889d966
>
>It seems the oops is happening in a module's function.
>
>You have to make ksymoops parse the oops output against a
On Tue, 16 Jan 2001, Rainer Mager wrote:
> Ok, now were making progress. I did as you said and have attached (really!)
> the new parsed output. Now we have some useful information (I hope). I still
> got lots of warnings on symbols (which I have edited out of the parsed file
> for the sake of
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Marcelo Tosatti
> Sent: Tuesday, January 16, 2001 7:09 AM
> To: Rainer Mager
> Cc: [EMAIL PROTECTED]
> Subject: RE: Oops with 4GB memory setting in 2.4.0 stable
>
> >>EIP; f88
On Tue, 16 Jan 2001, Rainer Mager wrote:
> I knew that, I was just testing you all. ;-)
>>EIP; f889e044<=
Trace; f889d966
Trace; c0140c10
Trace; c0140e7c
Trace; c0140f9e
Trace; c0140e7c
It seems the oops is happening in a module's function.
You have to make ksymoops parse the
gt; Subject: Re: Oops with 4GB memory setting in 2.4.0 stable
>
>
>
>
> On Tue, 16 Jan 2001, Rainer Mager wrote:
>
> > Attached is my oops.txt and the result sent through
> ksymoops. The results
> > don't look particularly useful to me so perhaps I'm doing
&
On Tue, 16 Jan 2001, Rainer Mager wrote:
> Attached is my oops.txt and the result sent through ksymoops. The results
> don't look particularly useful to me so perhaps I'm doing something wrong.
> PLEASE tell me if I should parse this differently. Likewise, if there is
> anything else I
On Tue, 16 Jan 2001, Rainer Mager wrote:
Attached is my oops.txt and the result sent through ksymoops. The results
don't look particularly useful to me so perhaps I'm doing something wrong.
PLEASE tell me if I should parse this differently. Likewise, if there is
anything else I can
memory setting in 2.4.0 stable
On Tue, 16 Jan 2001, Rainer Mager wrote:
Attached is my oops.txt and the result sent through
ksymoops. The results
don't look particularly useful to me so perhaps I'm doing
something wrong.
PLEASE tell me if I should parse this differently. Likewise
On Tue, 16 Jan 2001, Rainer Mager wrote:
I knew that, I was just testing you all. ;-)
EIP; f889e044 END_OF_CODE+385bfe34/ =
Trace; f889d966 END_OF_CODE+385bf756/
Trace; c0140c10 vfs_readdir+90/ec
Trace; c0140e7c filldir+0/d8
Trace; c0140f9e sys_getdents+4a/98
Trace; c0140e7c
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Marcelo Tosatti
Sent: Tuesday, January 16, 2001 7:09 AM
To: Rainer Mager
Cc: [EMAIL PROTECTED]
Subject: RE: Oops with 4GB memory setting in 2.4.0 stable
EIP; f889e044 END_OF_CODE+385bfe34/ =
Trace
On Tue, 16 Jan 2001, Rainer Mager wrote:
Ok, now were making progress. I did as you said and have attached (really!)
the new parsed output. Now we have some useful information (I hope). I still
got lots of warnings on symbols (which I have edited out of the parsed file
for the sake of
On Mon, 15 Jan 2001 20:09:14 -0200 (BRST),
Marcelo Tosatti [EMAIL PROTECTED] wrote:
On Tue, 16 Jan 2001, Rainer Mager wrote:
EIP; f889e044 END_OF_CODE+385bfe34/ =
Trace; f889d966 END_OF_CODE+385bf756/
It seems the oops is happening in a module's function.
You have to make
27 matches
Mail list logo
