...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")
...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
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.
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 [email protected]
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 [email protected]
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")
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
[email protected]|ChangeSet|20020529050157|61124
(currently revision 1.373.214.73 in my tree) and the key for the fix is
[email protected]|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
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 [email protected]
> 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 [email protected]
> 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
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