bitkeeper comments

bitkeeper comments

[Albert Cahalan]

This just got into BitKeeper, about 10 hours ago:

> [PATCH] x86-64 update
>
> Make everything compile and boot again.
>
> The earlier third party ioport.c changes unfortunately
> didn't even compile, fix that too.
>
> - Update defconfig
> - Some minor cleanup
> - Introduce physid_t for APIC masks (fixes UP kernels)
> - Finish ioport.c merge and fix compilation

Several days ago, I mailed Andi Kleen a build log which
showed that ioport.c builds perfectly well on x86-64.
The whole 2.6.0-test4 kernel does in fact, as downloaded
from kernel.org. Andi Kleen agreed...

...and now this comment gets submitted to Linus, ending
up in BitKeeper. I'd like this changed. I realize that
it may be a rather difficult thing to change at this point,
but it is clearly wrong.

Re: bitkeeper comments

[Larry McVoy]

On Mon, Sep 01, 2003 at 12:15:30AM -0400, Albert Cahalan wrote:
> This just got into BitKeeper, about 10 hours ago:
> 
> > [PATCH] x86-64 update
> >
> > Make everything compile and boot again.
> >
> > The earlier third party ioport.c changes unfortunately
> > didn't even compile, fix that too.
> >
> > - Update defconfig
> > - Some minor cleanup
> > - Introduce physid_t for APIC masks (fixes UP kernels)
> > - Finish ioport.c merge and fix compilation
> 
> Several days ago, I mailed Andi Kleen a build log which
> showed that ioport.c builds perfectly well on x86-64.
> The whole 2.6.0-test4 kernel does in fact, as downloaded
> from kernel.org. Andi Kleen agreed...
> 
> ...and now this comment gets submitted to Linus, ending
> up in BitKeeper. I'd like this changed. I realize that
> it may be a rather difficult thing to change at this point,
> but it is clearly wrong.

If you want the comments changed I can do that on bkbits.net and anyone
who grabs the update from there will get the new comments.  If you want
the patch gone out of BK anyone can do that with a cset -x.
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: bitkeeper comments

[Albert Cahalan]

On Mon, 2003-09-01 at 10:07, Larry McVoy wrote:
> On Mon, Sep 01, 2003 at 12:15:30AM -0400, Albert Cahalan wrote:
> > This just got into BitKeeper, about 10 hours ago:
> > 
> > > [PATCH] x86-64 update
> > >
> > > Make everything compile and boot again.
> > >
> > > The earlier third party ioport.c changes unfortunately
> > > didn't even compile, fix that too.
> > >
> > > - Update defconfig
> > > - Some minor cleanup
> > > - Introduce physid_t for APIC masks (fixes UP kernels)
> > > - Finish ioport.c merge and fix compilation
> > 
> > Several days ago, I mailed Andi Kleen a build log which
> > showed that ioport.c builds perfectly well on x86-64.
> > The whole 2.6.0-test4 kernel does in fact, as downloaded
> > from kernel.org. Andi Kleen agreed...
> > 
> > ...and now this comment gets submitted to Linus, ending
> > up in BitKeeper. I'd like this changed. I realize that
> > it may be a rather difficult thing to change at this point,
> > but it is clearly wrong.
> 
> If you want the comments changed I can do that on bkbits.net and anyone
> who grabs the update from there will get the new comments.  If you want
> the patch gone out of BK anyone can do that with a cset -x.

The code itself is OK I guess; the physid_t changes
may well be important, although they could be redone.

It's the comment that bugs me, specifically:

"Make everything compile and boot again."
"The earlier third party ioport.c changes unfortunately
didn't even compile, fix that too."
"Finish ioport.c merge and fix compilation"

(BTW, there's a bit more beyond the end of what I quoted)

I'm OK with whatever ensures that somebody looking back
through the BitKeeper logs isn't going to come to the
conclusion that I broke something.

Um, not everybody will grab updates from bkbits.net,
right? Pardon me for being clueless about BitKeeper,
but is there some command Andi or Linus could run?

Re: bitkeeper comments

[Larry McVoy]

On Mon, Sep 01, 2003 at 11:26:55AM -0400, Albert Cahalan wrote:
> I'm OK with whatever ensures that somebody looking back
> through the BitKeeper logs isn't going to come to the
> conclusion that I broke something.
> 
> Um, not everybody will grab updates from bkbits.net,
> right? Pardon me for being clueless about BitKeeper,
> but is there some command Andi or Linus could run?

Unfortunately the checkin comments themselves are not revision controlled.
You have to run a command on each repository that needs to be fixed,
if you send me the desired comments I'll post the command.  Then if
Linus or Marcelo says do it I'll do it on bkbits.net.  That should be good
enough, the logs there are what people tend to browse.
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: bitkeeper comments

[Christoph Hellwig]

On Mon, Sep 01, 2003 at 08:46:46AM -0700, Larry McVoy wrote:
> Unfortunately the checkin comments themselves are not revision controlled.
> You have to run a command on each repository that needs to be fixed,
> if you send me the desired comments I'll post the command.  Then if
> Linus or Marcelo says do it I'll do it on bkbits.net.  That should be good
> enough, the logs there are what people tend to browse.

WTF?  Andi probably had a reason to put this in.  If Albert feels pissed
of he should shred his repo instead of doing stupid censorship crap.

Re: bitkeeper comments

[Larry McVoy]

On Mon, Sep 01, 2003 at 04:56:58PM +0100, Christoph Hellwig wrote:
> On Mon, Sep 01, 2003 at 08:46:46AM -0700, Larry McVoy wrote:
> > Unfortunately the checkin comments themselves are not revision controlled.
> > You have to run a command on each repository that needs to be fixed,
> > if you send me the desired comments I'll post the command.  Then if
> > Linus or Marcelo says do it I'll do it on bkbits.net.  That should be good
> > enough, the logs there are what people tend to browse.
> 
> WTF?  Andi probably had a reason to put this in.  If Albert feels pissed
> of he should shred his repo instead of doing stupid censorship crap.

Hey, I'm not in the middle of this because I don't understand who is right
and it's not my place to make that call.  I said "if Linus or Marcelo says
do it"  specifically for the case that there is some hanky panky going on.
On the other hand, it's perfectly possible that the wrong comment got 
stuck in there and if that's the case why shouldn't it get fixed?
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: bitkeeper comments

[Christoph Hellwig]

On Mon, Sep 01, 2003 at 08:59:15AM -0700, Larry McVoy wrote:
> Hey, I'm not in the middle of this because I don't understand who is right
> and it's not my place to make that call.

I doesn't matter who's actually right.  If Andi was wrong Albert can
demand a apology from him or sue him or whater (not that his name is
actually mentioned in the message).

But we're not going to retroactively censor commit messages.

Re: bitkeeper comments

[Larry McVoy]

On Mon, Sep 01, 2003 at 05:02:18PM +0100, Christoph Hellwig wrote:
> On Mon, Sep 01, 2003 at 08:59:15AM -0700, Larry McVoy wrote:
> > Hey, I'm not in the middle of this because I don't understand who is right
> > and it's not my place to make that call.
> 
> I doesn't matter who's actually right.  If Andi was wrong Albert can
> demand a apology from him or sue him or whater (not that his name is
> actually mentioned in the message).
> 
> But we're not going to retroactively censor commit messages.

I'm confused, I thought Linus/Marcelo/Andrew were the tree maintainers.
As long as they are they get to make the call, not you (or me or whoever).
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: bitkeeper comments

[Andi Kleen]

On Mon, Sep 01, 2003 at 05:02:18PM +0100, Christoph Hellwig wrote:
> On Mon, Sep 01, 2003 at 08:59:15AM -0700, Larry McVoy wrote:
> > Hey, I'm not in the middle of this because I don't understand who is right
> > and it's not my place to make that call.
> 
> I doesn't matter who's actually right.  If Andi was wrong Albert can
> demand a apology from him or sue him or whater (not that his name is
> actually mentioned in the message).

I was wrong in this case, although I partly blame Albert because he sneaked
in x86-64 patches behind my back directly to Linus, which caused 
merging problems and resulted in this comment. 

-Andi

Re: bitkeeper comments

[Geert Uytterhoeven]

On Mon, 1 Sep 2003, Larry McVoy wrote:
> On Mon, Sep 01, 2003 at 05:02:18PM +0100, Christoph Hellwig wrote:
> > On Mon, Sep 01, 2003 at 08:59:15AM -0700, Larry McVoy wrote:
> > > Hey, I'm not in the middle of this because I don't understand who is right
> > > and it's not my place to make that call.
> > 
> > I doesn't matter who's actually right.  If Andi was wrong Albert can
> > demand a apology from him or sue him or whater (not that his name is
> > actually mentioned in the message).
> > 
> > But we're not going to retroactively censor commit messages.
> 
> I'm confused, I thought Linus/Marcelo/Andrew were the tree maintainers.
> As long as they are they get to make the call, not you (or me or whoever).

Retroactively changing a commit message may be a dangerous precedent. While
there may be legitimate reasons (E.g. plain wrong comments or `actually this
part was not written by x but by y'), one day The Evil Empire may claim we
changed the evidence of who did what.

Putting comments under revision control is another option, but may be too
deep-involving...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: bitkeeper comments

[Alan Cox]

On Llu, 2003-09-01 at 16:59, Larry McVoy wrote:
> Hey, I'm not in the middle of this because I don't understand who is right
> and it's not my place to make that call.  I said "if Linus or Marcelo says
> do it"  specifically for the case that there is some hanky panky going on.
> On the other hand, it's perfectly possible that the wrong comment got 
> stuck in there and if that's the case why shouldn't it get fixed?

Presumably in the abstract "if you care" case you can generate this
change globally by excluding that changeset and all after, then
reapplying it with a different comment then reapplying all that follow ?

Re: bitkeeper comments

[Larry McVoy]

On Mon, Sep 01, 2003 at 05:33:40PM +0100, Alan Cox wrote:
> On Llu, 2003-09-01 at 16:59, Larry McVoy wrote:
> > Hey, I'm not in the middle of this because I don't understand who is right
> > and it's not my place to make that call.  I said "if Linus or Marcelo says
> > do it"  specifically for the case that there is some hanky panky going on.
> > On the other hand, it's perfectly possible that the wrong comment got 
> > stuck in there and if that's the case why shouldn't it get fixed?
> 
> Presumably in the abstract "if you care" case you can generate this
> change globally by excluding that changeset and all after, then
> reapplying it with a different comment then reapplying all that follow ?

Yup, that would work just fine.  Anyone can do this.
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: bitkeeper comments

[Linus Torvalds]

On Mon, 1 Sep 2003, Christoph Hellwig wrote:
> 
> But we're not going to retroactively censor commit messages.

Actually, I do that all the time. In fact, it was I who asked Larry to add 
the "bk comment" command in to make it easy to do so.

The thing is, it's hard to do after the message has already gone out into 
the public - but I fix up peoples email commentary by hand both in the 
email and often later after it has hit my BK tree too. I try to fix 
obvious typos, and just generally make the things more readable.

And if the comment was wrong, then it should be fixed. Not because of any 
"censorship", but because it's misleading if the comment says it fixes 
something it doesn't fix - and that might make people overlook the _real_ 
thing the change does.

		Linus

Bug in linux-2.6.0-test4 ?

[dada1]

[-- Attachment #1: Type: text/plain, Size: 3849 bytes --]

Hi all

I have an annoying problem with a network server (TCP sockets)

On some stress situation,  LowMemory goes close to 0, and the whole machine
freezes.

When the sockets receive a lot of data, and the server is busy, the TCP
stack just can use too many buffers (in LowMem).

TCP stack uses "size-4096" buffers to store the datas, even if only one byte
is coming from the network.

I tried to change /proc/sys/net/ipv4/tcp_mem, without results.
# echo "1000 10000 15000" >/proc/sys/net/ipv4/tcp_mem

You can reproduce the problem with the test program attached.

# gcc -o crash crash.c
# ulimit -n 20000
# ./crash listen  8888 &
# ./crash call 127.0.0.1:8888 &

grep "size-4096 " /proc/slabinfo
size-4096      40015  40015  4096  1  1 : tunables  24  12  0  : slabdata
40015  40015 0

(thats is 160 Mo, far more than the limit given in
/proc/sys/net/ipv4/tcp_mem)

grep TCP /proc/net/sockstat
TCP: inuse 39996 orphan 0 tw 0 alloc 39997  mem 79986

What is the unit of 'mem' field ? Unless it is 2Ko, the numbers are wrong.

 How may I ask the kernel NOT to use more than 'X Mo' to store TCP messages
?

Thanks

Eric Dumazet

/*
 * Program to freeze a linux box, by using all the LOWMEM
 * A bug on the tcp stack may be the reason
 * Use at your own risk !!
 */

/* Principles :
   A listener accepts incoming tcp sockets, write 40 bytes, and does nothing
with them (no reading)
   A writer establish TCP sockets, sends some data (40 bytes), no more
reading/writing
 */
#include <stdio.h>
# include <sys/socket.h>
# include <netinet/tcp.h>
# include <arpa/inet.h>
# include <netdb.h>
# include <unistd.h>
# include <string.h>

/*
 * Usage :
 *              crash listen port
 *              crash call IP:port
 */
void usage(int code)
{
fprintf(stderr, "Usages :\n") ;
fprintf(stderr, "    crash listen port\n") ;
fprintf(stderr, "    crash call IP:port\n") ;
exit(code) ;
}
const char some_data[40] = "some data.... just some data" ;

void do_listener(const char *string)
{
int port = atoi(string) ;
struct sockaddr_in host, from ;
int fdlisten ;
unsigned int total ;
socklen_t fromlen ;
  memset(&host,0, sizeof(host));
  host.sin_family = AF_INET;
  host.sin_port = htons(port);
  fdlisten = socket(AF_INET, SOCK_STREAM, 0) ;
  if (bind(fdlisten, (struct sockaddr *)&host, sizeof(host)) == -1) {
        perror("bind") ;
        return ;
        }
listen(fdlisten, 10) ;
for (total=0;;total++) {
        int nfd ;
        fromlen = sizeof(from) ;
        nfd = accept(fdlisten, (struct sockaddr *)&from, &fromlen) ;
        if (nfd == -1) break ;
        write(nfd, some_data, sizeof(some_data)) ;
        }
printf("total=%u\n", total) ;
pause() ;
}

void do_caller(const char *string)
{
union {
   int i ;
   char c[4] ;
        } u ;
struct sockaddr_in dest;
int a1, a2, a3, a4, port ;
unsigned int total ;
sscanf(string, "%d.%d.%d.%d:%d", &a1, &a2, &a3, &a4, &port) ;
u.c[0] = a1 ; u.c[1] = a2 ; u.c[2] = a3 ; u.c[3] = a4 ;
for (total=0;;total++) {
    int fd ;
        memset(&dest, 0, sizeof(dest)) ;
        dest.sin_family = AF_INET ;
        dest.sin_port = htons(port) ;
        dest.sin_addr.s_addr = u.i ;
    fd = socket(AF_INET, SOCK_STREAM, 0) ;
        if (fd == -1) break ;
        if (connect(fd, (struct sockaddr *)&dest, sizeof(dest)) == -1) {
                perror("connect") ;
                break ;
                }
        write(fd, some_data, sizeof(some_data)) ;
        }
printf("total=%u\n", total) ;
pause() ;
}

int main(int argc, char *argv[])
{
int listener ;
int caller ;
if (argc != 3) {
        usage(1);
        }
listener = !strcmp(argv[1], "listen") ;
caller = !strcmp(argv[1], "call") ;
if (listener) {
        do_listener(argv[2]) ;
        }
else if (caller) {
        do_caller(argv[2]) ;
        }
else usage(2) ;
return 0 ;
}
/********************************************************************/

[-- Attachment #2: crash.c --]
[-- Type: text/plain, Size: 2624 bytes --]

/*
 * Program to freeze a linux box, by using all the LOWMEM
 * A bug on the tcp stack may be the reason 
 * Use at your own risk !!
 */

/* Principles :
   A listener accepts incoming tcp sockets, write 40 bytes, and does nothing with them (no reading)
   A writer establish TCP sockets, sends some data (40 bytes), no more reading/writing
 */
#include <stdio.h>
# include <sys/socket.h>
# include <netinet/tcp.h>
# include <arpa/inet.h>
# include <netdb.h>
# include <unistd.h>
# include <string.h>

/*
 * Usage :
 *              crash listen port
 *              crash call IP:port
 */
void usage(int code)
{
fprintf(stderr, "Usages :\n") ;
fprintf(stderr, "    crash listen port\n") ;
fprintf(stderr, "    crash call IP:port\n") ;
exit(code) ;
}
const char some_data[40] = "some data.... just some data" ;

void do_listener(const char *string)
{
int port = atoi(string) ;
struct sockaddr_in host, from ;
int fdlisten ;
unsigned int total ;
socklen_t fromlen ;
  memset(&host,0, sizeof(host));
  host.sin_family = AF_INET;
  host.sin_port = htons(port);
  fdlisten = socket(AF_INET, SOCK_STREAM, 0) ;
  if (bind(fdlisten, (struct sockaddr *)&host, sizeof(host)) == -1) {
	perror("bind") ;
	return ;
	}
listen(fdlisten, 10) ;
for (total=0;;total++) {
	int nfd ;
	fromlen = sizeof(from) ;
	nfd = accept(fdlisten, (struct sockaddr *)&from, &fromlen) ;
	if (nfd == -1) break ;
	write(nfd, some_data, sizeof(some_data)) ;
	}
printf("total=%u\n", total) ;
pause() ;
}

void do_caller(const char *string)
{
union {
   int i ;
   char c[4] ;
	} u ;
struct sockaddr_in dest;
int a1, a2, a3, a4, port ;
unsigned int total ;
sscanf(string, "%d.%d.%d.%d:%d", &a1, &a2, &a3, &a4, &port) ;
u.c[0] = a1 ; u.c[1] = a2 ; u.c[2] = a3 ; u.c[3] = a4 ;
for (total=0;;total++) {
    int fd ;
	memset(&dest, 0, sizeof(dest)) ;
	dest.sin_family = AF_INET ;
   	dest.sin_port = htons(port) ;
   	dest.sin_addr.s_addr = u.i ;
    fd = socket(AF_INET, SOCK_STREAM, 0) ;
	if (fd == -1) break ;
	if (connect(fd, (struct sockaddr *)&dest, sizeof(dest)) == -1) {
		perror("connect") ;
		break ;
		}
	write(fd, some_data, sizeof(some_data)) ;
	}
printf("total=%u\n", total) ;
pause() ;
}

int main(int argc, char *argv[])
{
int listener ;
int caller ;
if (argc != 3) {
	usage(1);
	}
listener = !strcmp(argv[1], "listen") ;
caller = !strcmp(argv[1], "call") ;
if (listener) {
	do_listener(argv[2]) ;
	}
else if (caller) {
	do_caller(argv[2]) ;
	}
else usage(2) ;
return 0 ;
}
/********************************************************************/

Re: bitkeeper comments

[Jakob Oestergaard]

On Mon, Sep 01, 2003 at 09:59:58AM -0700, Linus Torvalds wrote:
> 
> On Mon, 1 Sep 2003, Christoph Hellwig wrote:
> > 
> > But we're not going to retroactively censor commit messages.
> 
> Actually, I do that all the time. In fact, it was I who asked Larry to add 
> the "bk comment" command in to make it easy to do so.
> 
> The thing is, it's hard to do after the message has already gone out into 
> the public - but I fix up peoples email commentary by hand both in the 
> email and often later after it has hit my BK tree too. I try to fix 
> obvious typos, and just generally make the things more readable.
> 
> And if the comment was wrong, then it should be fixed. Not because of any 
> "censorship", but because it's misleading if the comment says it fixes 
> something it doesn't fix - and that might make people overlook the _real_ 
> thing the change does.

There is an important difference.

If I send you a mail saying "X" and you change it to say "Y" and put "Y"
in the source tree, fine.  It was a mail between us, noone except you
and me will know.  If I think it's wrong, maybe I can make you submit
"X" to the source tree instead, with an explanation.

Everything that was ever publicly visible, stays publicly visible, even
with the the revised comments, thanks to the revision history.

But changing the source tree revision history retroactively, that's bad.
It defies the purpose of revision control itself.

The source tree is a public record. People will remember "this said 'Y'
I'm sure, but now it says 'X', why is that?" - and noone can answer.
History forgotten.

It's your call, but I can certainly see why some feel bad about this.

After all, we wouldn't want to edit the e-mail archives to remove all
trace of what happened, either, would we?   ;)

Cheers,

-- 
................................................................
:   jakob@unthought.net   : And I see the elder races,         :
:.........................: putrid forms of man                :
:   Jakob Østergaard      : See him rise and claim the earth,  :
:        OZ9ABN           : his downfall is at hand.           :
:.........................:............{Konkhra}...............:

Re: bitkeeper comments

[Christoph Hellwig]

On Mon, Sep 01, 2003 at 07:23:34PM +0200, Jakob Oestergaard wrote:
> There is an important difference.
> 
> If I send you a mail saying "X" and you change it to say "Y" and put "Y"
> in the source tree, fine.  It was a mail between us, noone except you
> and me will know.  If I think it's wrong, maybe I can make you submit
> "X" to the source tree instead, with an explanation.
> 
> Everything that was ever publicly visible, stays publicly visible, even
> with the the revised comments, thanks to the revision history.
> 
> But changing the source tree revision history retroactively, that's bad.
> It defies the purpose of revision control itself.
> 
> The source tree is a public record. People will remember "this said 'Y'
> I'm sure, but now it says 'X', why is that?" - and noone can answer.
> History forgotten.

Yupp, that's what I meant.  I certainly don't want a thought police
on my source trees.

Re: bitkeeper comments

[Larry McVoy]

On Mon, Sep 01, 2003 at 06:28:27PM +0100, Christoph Hellwig wrote:
> On Mon, Sep 01, 2003 at 07:23:34PM +0200, Jakob Oestergaard wrote:
> > There is an important difference.
> > 
> > If I send you a mail saying "X" and you change it to say "Y" and put "Y"
> > in the source tree, fine.  It was a mail between us, noone except you
> > and me will know.  If I think it's wrong, maybe I can make you submit
> > "X" to the source tree instead, with an explanation.
> > 
> > Everything that was ever publicly visible, stays publicly visible, even
> > with the the revised comments, thanks to the revision history.
> > 
> > But changing the source tree revision history retroactively, that's bad.
> > It defies the purpose of revision control itself.
> > 
> > The source tree is a public record. People will remember "this said 'Y'
> > I'm sure, but now it says 'X', why is that?" - and noone can answer.
> > History forgotten.
> 
> Yupp, that's what I meant.  I certainly don't want a thought police
> on my source trees.

Trivial w/ the current BK because the comments aren't versioned.  Just have
someone be elected as the archiver and have them have a cron job which pulls
bkbits.net every 20 minutes or so.  Then if the comments are ever changed
your archive will have the originals.
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm

Re: bitkeeper comments

[Albert Cahalan]

On Mon, 2003-09-01 at 11:46, Larry McVoy wrote:
> On Mon, Sep 01, 2003 at 11:26:55AM -0400, Albert Cahalan wrote:
> > I'm OK with whatever ensures that somebody looking back
> > through the BitKeeper logs isn't going to come to the
> > conclusion that I broke something.
> > 
> > Um, not everybody will grab updates from bkbits.net,
> > right? Pardon me for being clueless about BitKeeper,
> > but is there some command Andi or Linus could run?
> 
> Unfortunately the checkin comments themselves are not revision controlled.
> You have to run a command on each repository that needs to be fixed,
> if you send me the desired comments I'll post the command.  Then if
> Linus or Marcelo says do it I'll do it on bkbits.net.  That should be good
> enough, the logs there are what people tend to browse.

============ as a patch =============
--- old  2003-09-01 14:04:46.000000000 -0400
+++ new  2003-09-01 14:05:18.000000000 -0400
@@ -2,13 +2,9 @@
 
 Make everything compile and boot again.
 
-The earlier third party ioport.c changes unfortunately didn't even
-compile, fix that too.
-
  - Update defconfig
  - Some minor cleanup
  - Introduce physid_t for APIC masks (fixes UP kernels)
- - Finish ioport.c merge and fix compilation
  - Add bandaid for CardBus bridges and broken BIOS (Vojtech)
  - Add bandaid for unsynchronized TSCs  (Vojtech)
  - Fix ffs(0) return value (fixes XFS) 

=========== old content ============
[PATCH] x86-64 update

Make everything compile and boot again.

The earlier third party ioport.c changes unfortunately didn't even
compile, fix that too.

 - Update defconfig
 - Some minor cleanup
 - Introduce physid_t for APIC masks (fixes UP kernels)
 - Finish ioport.c merge and fix compilation
 - Add bandaid for CardBus bridges and broken BIOS (Vojtech)
 - Add bandaid for unsynchronized TSCs  (Vojtech)
 - Fix ffs(0) return value (fixes XFS) 
 - Fix compilation with software suspend

=========== new content ============
[PATCH] x86-64 update

Make everything compile and boot again.

 - Update defconfig
 - Some minor cleanup
 - Introduce physid_t for APIC masks (fixes UP kernels)
 - Add bandaid for CardBus bridges and broken BIOS (Vojtech)
 - Add bandaid for unsynchronized TSCs  (Vojtech)
 - Fix ffs(0) return value (fixes XFS) 
 - Fix compilation with software suspend