patches added to release/test trees

patches added to release/test trees

[Luck, Tony]

The following patches have been added to the release tree (destined
to go into 2.6.16 when Linus gets back from linux.conf.au):

Dean Roe:
      [IA64-SGI] add sn_feature_sets bit

Greg Edwards:
      [IA64] sn2 maintainer update (Jes Sorensen)

Jack Steiner:
      [IA64] Scaling fix for simultaneous unaligned accesses

Jes Sorensen:
      [IA64-SGI] XPC remove unnecessary GFP_DMA flag

Keith Owens:
      [IA64] Set the correct default OS status in the MCA handler

Prarit Bhargava:
      [IA64-SGI] Add PROM feature set for device flush list

Takashi Iwai:
      [IA64-SGI] sn_dma_alloc_coherent should use gfp flags

All of the above and these patches have been added to the test tree (destined
for some -mm releases, and then 2.6.17):

Aaron Young:
      [IA64-SGI] Handle SC env. powerdown events

Brent Casavant:
      [IA64] hooks to wait for mmio writes to drain when migrating processes

Chen, Kenneth W:
      [IA64] implement ia64 specific mutex primitives

Jack Steiner:
      [IA64-SGI] Update TLB flushing code for SN platform

Jes Sorensen:
      [IA64-SGI] sem2mutex ioc4.c
      drivers/sn/ must be entered for CONFIG_SGI_IOC3

Keith Owens:
      [IA64-SGI] Recursive flags do not work for selective builds
      [IA64] Delete MCA/INIT sigdelayed code

Mark Maule:
      [IA64-SGI] driver bugfixes and hardware workarounds for CE1.0 asic

patches added to release/test trees

[Luck, Tony]

The following patches have been added to the release tree:

Bjorn Helgaas:
      [IA64] avoid broken SAL_CACHE_FLUSH implementations

Chen, Kenneth W:
      [IA64] remove staled comments in asm/system.h

Jack Steiner:
      [IA64-SGI] Update TLB flushing code for SN platform (pulled from test)

Jes Sorensen:
      drivers/sn/ must be entered for CONFIG_SGI_IOC3 (pulled from test)
      [IA64-SGI] sn2 housekeeping
      [IA64-SGI] include/asm-ia64/sn/intr.h more sn2 housekeeping

Kyle McMartin:
      [IA64] Remove stale comment from ia64/Kconfig

Mark Maule:
      [IA64-SGI] fix smp_affinity redirection when using CONFIG_PCI_MSI
      [IA64-SGI] disable msi for all altix pci devices

Robin Holt:
      [IA64-SGI] Fix XPC code which sleeps with spin_lock_irqsave().

patches added to release/test trees

[Luck, Tony]

The following patches have been added to the release/test trees:

Jes Sorensen:
      [IA64] prevent sn2 specific code to be run in generic kernels

Tony Luck:
      [IA64] Fix CONFIG_PRINTK_TIME

Zou Nan hai:
      [IA64] Fix a possible buffer overflow in efi.c
      [IA64] Fix wrong use of memparse in efi.c

The following patches have been added to the test tree:

Chen, Kenneth W:
      [IA64] map ia64_hint definition to intel compiler intrinsic
      [IA64] clean up asm/intel_intrin.h
      [IA64] add __builtin_trap definition for icc build
      [IA64] use icc defined constant

Jack Steiner:
      [IA64-SGI] - Eliminate SN pio_phys_xxx macros. Move to assembly

Keith Owens:
      [IA64] MCA: print messages in MCA handler
      [IA64] MCA: update MCA comm field for user space tasks
      [IA64] MCA: remove obsolete ifdef

patches added to release/test trees

[Luck, Tony]

The following patches have been added to my release/test trees:

Bjorn Helgaas:
      [IA64] update HP CSR space discovery via ACPI

KAMEZAWA Hiroyuki:
      [IA64] for_each_possible_cpu: ia64

Tony Luck:
      [IA64] Wire up new syscall sync_file_range()
      [IA64] 'msg' may be used uninitialized in xpc_initiate_allocate()
      [IA64] Wire up new syscalls {set,get}_robust_list

patches added to release/test trees

[Luck, Tony]

I just did a quick skim through my backlog of patches and pushed
all the "obviously correct" (famous last words) ones into the
release tree.  I'll send them to Linus on Friday (unless I hear
about any problems).  Remind me about any other "obvious" stuff
that my eyes skipped over.

The following patches have been added to the release tree:

Alex Williamson:
      [IA64] add vmlinuz target
      [IA64] sanity check reserved region usage

Bjorn Helgaas:
      [IA64] rework memory attribute aliasing

David Mosberger-Tang:
      [IA64] make efi_stub.S fit in 80 cols

Ian Wienand:
      [IA64] SKI Simulator boot

Jack Steiner:
      [IA64-SGI] SN topology fix for large systems

Keith Owens:
      [IA64] Sanitize assembler code for ia64_sal_os_state

Kenji Kaneshige:
      [IA64] Make PCI Express support selectable

Mike Habeck:
      [IA64-SGI] fix SGI Altix tioce_bus_fixup() bug

Russ Anderson:
      [IA64-SGI] Remove SN SAL error handling feature bit that is no longer needed


Additionally the following patches have been added to the test tree. These
will probably go to Linus before we get to -rc1.

David Mosberger-Tang:
      [IA64] esi-support

Tony Luck:
      [IA64] Add "model name" to /proc/cpuinfo


Horms and Ian.  Thanks for all the kexec patches you've posted.  I'll
be folding them in on top of the current kexec stuff soon.  There
still seem to be a lot of open issues on this, and hardly any reports
of any testing going on.  At this pace kexec/kdump will be sitting in
"test" (and -mm) for at least another release cycle.

Re: patches added to release/test trees

[Keith Owens]

"Luck, Tony" (on Wed, 21 Jun 2006 16:19:58 -0700) wrote:
>I just did a quick skim through my backlog of patches and pushed
>all the "obviously correct" (famous last words) ones into the
>release tree.

I just did a git-fetch on git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git
and the log for the release branch shows no changes to arch/ia64 since
May 16.  The Makefile is for 2.6.17-rc5.  Is there a propogation delay
on your git updates before they hit git.kernel.org?

BTW, is there any reason that the aegl git tree has no tags?

Re: patches added to release/test trees

[Keith Owens]

Keith Owens (on Thu, 22 Jun 2006 10:33:24 +1000) wrote:
>"Luck, Tony" (on Wed, 21 Jun 2006 16:19:58 -0700) wrote:
>>I just did a quick skim through my backlog of patches and pushed
>>all the "obviously correct" (famous last words) ones into the
>>release tree.
>
>I just did a git-fetch on git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git
>and the log for the release branch shows no changes to arch/ia64 since
>May 16.  The Makefile is for 2.6.17-rc5.  Is there a propogation delay
>on your git updates before they hit git.kernel.org?

Never mind, a later git-fetch got the data.  Must be a propogation
delay between master.kernel.org and git.kernel.org.

Re: patches added to release/test trees

[Horms]

In article <200606212319.k5LNJw7e014316@agluck-lia64.sc.intel.com> you wrote:
> 
> Horms and Ian.  Thanks for all the kexec patches you've posted.  I'll
> be folding them in on top of the current kexec stuff soon.  There
> still seem to be a lot of open issues on this, and hardly any reports
> of any testing going on.  At this pace kexec/kdump will be sitting in
> "test" (and -mm) for at least another release cycle.

Hi Tony,

thanks for the feedback. I understand that kexec/kdump is quite
green/flakey and having it sit in test as you suggest is quite
approtiate in my oppinion too. Hopefully its quality can improve over
time.

As for the patches that I have sent, let me know if you need any of them
rediffed or reworked. I'm more than happy to do that kind of leg work,
as some of the patches conflict in minor ways, and some of them are
against the kdump patch before it went into your tree, and thus may need
some minor merging.

Thanks

-- 
Horms                                           http://www.vergenet.net/~horms/

RE: patches added to release/test trees

[Luck, Tony]

> May 16.  The Makefile is for 2.6.17-rc5.  Is there a propogation delay
> on your git updates before they hit git.kernel.org?

Yes, there is a delay.  I update to a backend system at kernel.org which
regularly rsyncs the data to the two front-end systems: {www1,www2}.kernel.org
The delay varies depending on load on the systems, and the overall internet
weather.  It can be as short as a couple of minutes.  When it goes above
a couple of hours it indicates there is a problem.  The updates to the
two front-end systems are independent ... you can force access to one
or the other by using the www1, www2 names to see whether one managed to
get the update.

> BTW, is there any reason that the aegl git tree has no tags?

I haven't thought of any useful way to use tags.  But perhaps it's
becuase I mostly think of my GIT trees as conduits to Linus/Andrew.
If you have suggestions on how I can make my trees more useful to
you by tagging things, then let me know.

-Tony

Re: patches added to release/test trees

[Keith Owens]

"Luck, Tony" (on Thu, 22 Jun 2006 10:34:06 -0700) wrote:
>> BTW, is there any reason that the aegl git tree has no tags?
>
>I haven't thought of any useful way to use tags.  But perhaps it's
>becuase I mostly think of my GIT trees as conduits to Linus/Andrew.
>If you have suggestions on how I can make my trees more useful to
>you by tagging things, then let me know.

Not adding your own tags, but Linus's tags are missing from the ia64
tree.  For some reason, just copying .git/refs/tags from the torvalds
git tree does not work, git-branch complains about invalid objects.  I
thought that tags were portable between trees with common ancestors.

  git-clone .../git/torvalds/linux-2.6.git linux-2.6
  git-clone .../git/aegl/linux-2.6.git linux-2.6-ia64
  cp -a linux-2.6/.git/refs/tags/* linux-2.6-ia64/.git/refs/tags/
  cd linux-2.6-ia64
  git-branch
  error: refs/tags/v2.6.11 does not point to a valid commit object!
  error: refs/tags/v2.6.11-tree does not point to a valid commit object!
  ...
  error: refs/tags/v2.6.17-rc5 does not point to a valid commit object!
  error: refs/tags/v2.6.17-rc6 does not point to a valid commit object!
    origin
    * release
    test

Re: patches added to release/test trees

[Andreas Schwab]

Keith Owens <kaos@sgi.com> writes:

> Not adding your own tags, but Linus's tags are missing from the ia64
> tree.  For some reason, just copying .git/refs/tags from the torvalds
> git tree does not work, git-branch complains about invalid objects.  I
> thought that tags were portable between trees with common ancestors.

You have only copied the references, but not the objects itself.  The
easiest way to do that is to point objects/info/alternates to your copy of
Linus' object store.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: patches added to release/test trees

[Keith Owens]

Andreas Schwab (on Fri, 23 Jun 2006 02:11:55 +0200) wrote:
>Keith Owens <kaos@sgi.com> writes:
>
>> Not adding your own tags, but Linus's tags are missing from the ia64
>> tree.  For some reason, just copying .git/refs/tags from the torvalds
>> git tree does not work, git-branch complains about invalid objects.  I
>> thought that tags were portable between trees with common ancestors.
>
>You have only copied the references, but not the objects itself.  The
>easiest way to do that is to point objects/info/alternates to your copy of
>Linus' object store.

That makes sense.  But why is the ia64 git tree missing the Linus
objects and tags in the first place?

RE: patches added to release/test trees

[Luck, Tony]

> That makes sense.  But why is the ia64 git tree missing the Linus
> objects and tags in the first place?

"tags" is a bit ambiguous here, there are two possible things that
you might be talking about when you say "tag" w.r.t. a GIT tree.

1) A file in .git/refs/tags/ that contains the SHA1 of a git object.

2) A git object of type "tag".

The files in .git/refs/tags refer to GIT tag objects.  Usually a
tag object is a pointer to a commit object ... but they can point
at anything (the v2.6.11 tag object points to a "tree").

Things get more complex from here.  My kernel.org tree contains none
of the .git/refs/tags files (because I "git push" the heads of the
release/test branches up from my local tree, anf this won't copy any
tags files up ... even though they are all in my local tree from
my "git fetch linus" pulls from Linus).

The git tag objects actually are in my kernel.org tree!  But only
because I share packfiles with Linus to reduce load on kernel.org
mirroring system.

You don't get to see them though.  When you do a fetch/pull from
my tree (using "git://" transfer method), git will construct the
list of commit/tree/blob objects, build a packfile, and send it to
you.  Any tag objects in my (really Linus') packfile will just be
ignored.  If you used "rsync://", it would copy the whole packfile.
Not sure what an http:// pull would do.


Is that as clear as mud now?

-Tony

Re: patches added to release/test trees

[Keith Owens]

"Luck, Tony" (on Fri, 23 Jun 2006 10:08:22 -0700) wrote:
>> That makes sense.  But why is the ia64 git tree missing the Linus
>> objects and tags in the first place?
>
>"tags" is a bit ambiguous here, there are two possible things that
>you might be talking about when you say "tag" w.r.t. a GIT tree.
>
>1) A file in .git/refs/tags/ that contains the SHA1 of a git object.

Them.

>2) A git object of type "tag".
>
>The files in .git/refs/tags refer to GIT tag objects.  Usually a
>tag object is a pointer to a commit object ... but they can point
>at anything (the v2.6.11 tag object points to a "tree").
>
>Things get more complex from here.  My kernel.org tree contains none
>of the .git/refs/tags files (because I "git push" the heads of the
>release/test branches up from my local tree, anf this won't copy any
>tags files up ... even though they are all in my local tree from
>my "git fetch linus" pulls from Linus).

Could you push the refs/tags from your tree as well?  Many of the git
trees on kernel.org have copies of Linus's tags, which makes it a bit
easier to cross reference.

RE: patches added to release/test trees

[Luck, Tony]

> Could you push the refs/tags from your tree as well?  Many of the git
> trees on kernel.org have copies of Linus's tags, which makes it a bit
> easier to cross reference.

I linked his tags directory to my tree ... lets see how that works.

-Tony

Re: patches added to release/test trees

[Horms]

In article <617E1C2C70743745A92448908E030B2A22FFE9@scsmsx411.amr.corp.intel.com> you wrote:
>> Could you push the refs/tags from your tree as well?  Many of the git
>> trees on kernel.org have copies of Linus's tags, which makes it a bit
>> easier to cross reference.
> 
> I linked his tags directory to my tree ... lets see how that works.

I noticed (to my surprise) a bunch of tags show up while using gitweb 
this morning. So I guess its working, at least to some extent.

-- 
Horms                                           
H: http://www.vergenet.net/~horms/          W: http://www.valinux.co.jp/en/

RE: patches added to release/test trees

[Luck, Tony]

> > I linked his tags directory to my tree ... lets see how that works.
>
> I noticed (to my surprise) a bunch of tags show up while using gitweb 
> this morning. So I guess its working, at least to some extent.

The only bit that I'm worried about is what will happen when
Linus adds a new tag.  Until I do a pull&push to catch up, I'll
have a "bogus" tag (pointing to an object that I don't have).
Whether this is an annoyance, or a major problem, remains to
be seen.

The 2.6.17 tag is now 8 days old, so if Linus sticks to the 2-week
merge window, we'll find out in ~6days when 2.6.18-rc1 comes out.

-Tony

Re: patches added to release/test trees

[Keith Owens]

"Luck, Tony" (on Mon, 26 Jun 2006 10:23:19 -0700) wrote:
>> > I linked his tags directory to my tree ... lets see how that works.
>>
>> I noticed (to my surprise) a bunch of tags show up while using gitweb 
>> this morning. So I guess its working, at least to some extent.
>
>The only bit that I'm worried about is what will happen when
>Linus adds a new tag.  Until I do a pull&push to catch up, I'll
>have a "bogus" tag (pointing to an object that I don't have).
>Whether this is an annoyance, or a major problem, remains to
>be seen.

Annoyance only.  git-branch will list it as a dangling tag but that is all.