Oracle 9.2 OOMs again at startup in 2.5.4[78]

Oracle 9.2 OOMs again at startup in 2.5.4[78]

[Alessandro Suardi]

...just like it did a few kernels ago (the current->mm issue in 2.5.19
  that eventually got fixed in 2.5.30 or thereabouts, introduced for the
  bk-enabled by cset 1.373.221.1).

I'll go building a 2.5.44 kernel (think it's the only one I didn't have
  too much trouble building / booting in the 2.5.4x series before .47)
  and see whether it works or not.


Later,

--alessandro

  "Seems that you can't get any more than half free"
        (Bruce Springsteen, "Straight Time")

Re: Oracle 9.2 OOMs again at startup in 2.5.4[78]

[Billy O'Connor]

 ...just like it did a few kernels ago (the current->mm issue in 2.5.19
   that eventually got fixed in 2.5.30 or thereabouts, introduced for the
   bk-enabled by cset 1.373.221.1).
 
 I'll go building a 2.5.44 kernel (think it's the only one I didn't have
   too much trouble building / booting in the 2.5.4x series before .47)
   and see whether it works or not.

I'd like to try to reproduce this, Alessandro.  Could you forward me
the other details about the server you're experiencing the problem on?

Billy O'Connor

Re: Oracle 9.2 OOMs again at startup in 2.5.4[78]

[Andrew Morton]

Alessandro Suardi wrote:
> 
> ...just like it did a few kernels ago (the current->mm issue in 2.5.19
>   that eventually got fixed in 2.5.30 or thereabouts, introduced for the
>   bk-enabled by cset 1.373.221.1).

According to the web interface, 1.373.221.1 is 

"This patch lets more devices hook up to USB 2.0 hubs, stuff
like keyboards, mice, hubs that hasn't worked yet"

so, errr.

> I'll go building a 2.5.44 kernel (think it's the only one I didn't have
>   too much trouble building / booting in the 2.5.4x series before .47)
>   and see whether it works or not.

An `strace -f' of the startup process might reveal something.

Re: Oracle 9.2 OOMs again at startup in 2.5.4[78]

[Alessandro Suardi]

Andrew Morton wrote:
> Alessandro Suardi wrote:
> 
>>...just like it did a few kernels ago (the current->mm issue in 2.5.19
>>  that eventually got fixed in 2.5.30 or thereabouts, introduced for the
>>  bk-enabled by cset 1.373.221.1).
> 
> 
> According to the web interface, 1.373.221.1 is 
> 
> "This patch lets more devices hook up to USB 2.0 hubs, stuff
> like keyboards, mice, hubs that hasn't worked yet"
> 
> so, errr.

The web interface seems to be at fault (or is it your fingers ;)
  from my saved mail with Linus and yourself I have...

--------------------------------------------------------------------------
The patch you actually include seems to be a combination of

     ChangeSet 1.373.204.73 2002/05/28 22:01:57 torvalds@home.transmeta.com
       Remove re-use of "struct mm_struct" at execve() time.

       This will eventually allow us to copy argc/argv without
       any intermediate storage (removing current argument size
       limitations).

and

     ChangeSet 1.373.221.1 2002/05/28 22:55:46 torvalds@home.transmeta.com
       Allocate new mm_struct for execve() early, so that we have
       access to it by the time we start copying arguments.
-------------------------------------------------------------------------

> 
>>I'll go building a 2.5.44 kernel (think it's the only one I didn't have
>>  too much trouble building / booting in the 2.5.4x series before .47)
>>  and see whether it works or not.
> 
> 
> An `strace -f' of the startup process might reveal something.

will also try that - tomorrow, now time's over @ office :)


Thanks,

--alessandro

  "Seems that you can't get any more than half free"
        (Bruce Springsteen, "Straight Time")

Re: Oracle 9.2 OOMs again at startup in 2.5.4[78]

[Linus Torvalds]

On Tue, 19 Nov 2002, Alessandro Suardi wrote:
> 
> The web interface seems to be at fault (or is it your fingers ;)
>   from my saved mail with Linus and yourself I have...

No, what is at fault is thinking that the BK revision numbers mean 
anything. They don't.

A BK revision number is _purely_ local to the tree it was gotten off, and 
will be meaningless after a merge of two trees have happened. The only 
thing that really means anything in BK is the "ChangeSet key", which is a 
truly unique identifier, and is painful as hell to type because of that.

In this case, the key for the changeset that Alessandro was talking about 
is

	torvalds@home.transmeta.com|ChangeSet|20020529050157|61124

(currently revision 1.373.214.73 in my tree) and the key for the fix is 

	hugh@veritas.com|ChangeSet|20021001154212|00224

(currently 1.573.94.1 in my tree).

You can see the key's with "bk changes -k", or if you want to see a 
combination of keys etc you can do more fancy stuff (I used

	bk changes -d":KEY: ':REV:'\n:AUTHOR:\n:COMMENTS:\n" | less

to search for comments and key information, in case you care).

Thus endeth BK 101.

		Linus

Re: Oracle 9.2 OOMs again at startup in 2.5.4[78]

[William Lee Irwin III]

On Tue, Nov 19, 2002 at 08:08:08PM +0100, Alessandro Suardi wrote:
> The patch you actually include seems to be a combination of
>     ChangeSet 1.373.204.73 2002/05/28 22:01:57 torvalds@home.transmeta.com
>       Remove re-use of "struct mm_struct" at execve() time.
>       This will eventually allow us to copy argc/argv without
>       any intermediate storage (removing current argument size
>       limitations).
> and
>     ChangeSet 1.373.221.1 2002/05/28 22:55:46 torvalds@home.transmeta.com
>       Allocate new mm_struct for execve() early, so that we have
>       access to it by the time we start copying arguments.

This created some unusual startup problems for DB2 also, but they went
away (for DB2) before anyone had figured out why they caused a startup
failure. ISTR badari dealing with this more directly (hence the cc:).

badari, do you remember more of what happened?


Thanks,
Bill

Re: Oracle 9.2 OOMs again at startup in 2.5.4[78]

[William Lee Irwin III]

On Tue, Nov 19, 2002 at 11:38:07AM -0800, William Lee Irwin III wrote:
> This created some unusual startup problems for DB2 also, but they went
> away (for DB2) before anyone had figured out why they caused a startup
> failure. ISTR badari dealing with this more directly (hence the cc:).
> badari, do you remember more of what happened?

nm, Linus answered it. =)


Thanks,
Bill