As of this morning, Linus's current bk tree
(http://linux.bkbits.net:8080/linux-2.5) builds and works out of the
box for ia64!
Thanks to everybody who helped make this happen. In particular,
thanks to Andrew Morton and Christoph Hellwig for their efforts, and
Andy Grover for a last-minute ACPI patch!
For maximum performance/stability, I'd still recommend to use the
ia64-specific patches, but for someone who needs to build bleeding
edge kernels for multiple architectures, being able to use Linus' tree
should make it a lot easier to include ia64 in their regular testing
etc.
Now that Linus' tree works for ia64, the next question is how we can
keep it that way. I think it would be useful to have someone setup a
cron job which does daily builds/automated tests off of Linus tree.
If something breaks, the person doing this could perhaps come up with
a minimal patch which gets Linus' tree to build again (and submit a
patch to the appropriate maintainer, with cc to the linux-ia64 list).
I plan on continuing to put out roughly monthly ia64-specific patches
and during those normal cycles, I'd then integrate the "quick fix up"
patches as needed. Does this sound reasonable? Anybody want to
volunteer for this "Linus watchdog" role?
--david
On Mon, Aug 04, 2003 at 10:37:39AM -0700, David Mosberger wrote:
> As of this morning, Linus's current bk tree
> (http://linux.bkbits.net:8080/linux-2.5) builds and works out of the
> box for ia64!
>
Does it work on bigsur? Does it support kernel modules?
H.J.
On Mon, Aug 04, 2003 at 10:53:08AM -0700, H. J. Lu wrote:
> On Mon, Aug 04, 2003 at 10:37:39AM -0700, David Mosberger wrote:
> > As of this morning, Linus's current bk tree
> > (http://linux.bkbits.net:8080/linux-2.5) builds and works out of the
> > box for ia64!
> >
>
> Does it work on bigsur? Does it support kernel modules?
I just tried the latest on my big sur, and though I think modules work
(at least they build for other machines), big sur is broken because
non-ACPI based PCI enumeration has been removed from the tree.
Jesse
On Mon, Aug 04, 2003 at 11:00:16AM -0700, Jesse Barnes wrote:
> On Mon, Aug 04, 2003 at 10:53:08AM -0700, H. J. Lu wrote:
> > On Mon, Aug 04, 2003 at 10:37:39AM -0700, David Mosberger wrote:
> > > As of this morning, Linus's current bk tree
> > > (http://linux.bkbits.net:8080/linux-2.5) builds and works out of the
> > > box for ia64!
> > >
> >
> > Does it work on bigsur? Does it support kernel modules?
>
> I just tried the latest on my big sur, and though I think modules work
> (at least they build for other machines), big sur is broken because
> non-ACPI based PCI enumeration has been removed from the tree.
>
Can you try this patch for bigsur?
H.J.
---
--- linux/drivers/acpi/osl.c.acpi Mon Jul 28 11:41:53 2003
+++ linux/drivers/acpi/osl.c Mon Jul 28 15:12:44 2003
@@ -250,7 +250,12 @@ acpi_os_install_interrupt_handler(u32 ir
irq = acpi_fadt.sci_int;
#ifdef CONFIG_IA64
- irq = gsi_to_vector(irq);
+ irq = acpi_irq_to_vector (irq);
+ if (irq < 0) {
+ printk(KERN_ERR PREFIX "SCI (IRQ%d/%d) not registerd\n",
+ irq, acpi_fadt.sci_int);
+ return AE_OK;
+ }
#endif
acpi_irq_irq = irq;
acpi_irq_handler = handler;
>>>>> On Mon, 4 Aug 2003 10:53:08 -0700, "H. J. Lu" <[email protected]> said:
HJ> Does it work on bigsur?
It should, apart from a qla1280.c glitch (see the latest ia64 diff for
the one-liner to get it to work; Jes Sorensen said he's going to
cleanup qla1280 for real).
HJ> Does it support kernel modules?
Sure. Kernel modules have been working for a while. You do need
module-init-tools, of course (Debian has the necessary package in the
"unstable" tree).
--david
>>>>> On Mon, 4 Aug 2003 11:00:16 -0700, [email protected] (Jesse Barnes) said:
Jesse> big sur is broken because non-ACPI based PCI enumeration has
Jesse> been removed from the tree.
That shouldn't break big sur. Perhaps you need newer firmware,
though?
--david
On Mon, 4 Aug 2003 10:37:39 -0700
David Mosberger <[email protected]> wrote:
> As of this morning, Linus's current bk tree
> (http://linux.bkbits.net:8080/linux-2.5) builds and works out of the
> box for ia64!
I hate to rain on your parade, but for a platform that has so many
companies paying people full time to maintain under Linux having it
take this long is a big diasppointment for me :(
I do sparc64 as a hobby in my spare time, as a single individual, and
it has been working daily throughout the entire 2.4.x and 2.5.x
series.
The fact that there are still "external patches for performance"
is even more disheartening.
My tree never lags Linus's by more than 24 or 48 hours, unless one
of us is on vacation and not near computers. And if I can do this
in my spare time, it should be doable by people getting paid full
time to maintain the ia64 port, don't you think? 8-)
>>>>> On Mon, 4 Aug 2003 11:31:44 -0700, "David S. Miller" <[email protected]> said:
Dave> My tree never lags Linus's by more than 24 or 48 hours, unless
Dave> one of us is on vacation and not near computers. And if I can
Dave> do this in my spare time, it should be doable by people
Dave> getting paid full time to maintain the ia64 port, don't you
Dave> think? 8-)
Well, you're obviously just way better than everybody else!
For what it's worth, I spend on average about 1 day a week on ia64
linux maintenance and that's just about as much as I'd want to (though
in recent months it has been a bit more, partly so that we can get
into sync with Linus' tree).
--david
>>>>> "David" == David Mosberger <[email protected]> writes:
>>>>> On Mon, 4 Aug 2003 10:53:08 -0700, "H. J. Lu" <[email protected]> said:
HJ> Does it work on bigsur?
David> It should, apart from a qla1280.c glitch (see the latest ia64
David> diff for the one-liner to get it to work; Jes Sorensen said
David> he's going to cleanup qla1280 for real).
Yes, I already have in fact. I submitted the updated driver to James
Bottomley for inclusion in the tree. I'll post it to you shortly.
Cheers,
Jes
On Mon, 4 Aug 2003 11:40:25 -0700
David Mosberger <[email protected]> wrote:
> For what it's worth, I spend on average about 1 day a week on ia64
> linux maintenance and that's just about as much as I'd want to (though
> in recent months it has been a bit more, partly so that we can get
> into sync with Linus' tree).
I'm not addressing you specifically, but I will note how great
you tend to say ia64 is when platform performance comparison
discussions happen on the lists :-)
In general, I think some platform maintainence drifts way too easily
into a tail-spin of local changes that take forever to get merged.
My point was that if some random single monkey like me can keep a
loser platform like sparc64 still building in Linus's tree, a group of
several trained professionals should be able to fare much better :)
Thanks H.J., this patch works for me! I had to add one more for xfs
(included), but after that, things seemed to work.
Thanks,
Jesse
On Mon, Aug 04, 2003 at 11:10:33AM -0700, H. J. Lu wrote:
> On Mon, Aug 04, 2003 at 11:00:16AM -0700, Jesse Barnes wrote:
> > On Mon, Aug 04, 2003 at 10:53:08AM -0700, H. J. Lu wrote:
> > > On Mon, Aug 04, 2003 at 10:37:39AM -0700, David Mosberger wrote:
> > > > As of this morning, Linus's current bk tree
> > > > (http://linux.bkbits.net:8080/linux-2.5) builds and works out of the
> > > > box for ia64!
> > > >
> > >
> > > Does it work on bigsur? Does it support kernel modules?
> >
> > I just tried the latest on my big sur, and though I think modules work
> > (at least they build for other machines), big sur is broken because
> > non-ACPI based PCI enumeration has been removed from the tree.
> >
>
> Can you try this patch for bigsur?
diff -Nru a/fs/xfs/linux/xfs_vfs.h b/fs/xfs/linux/xfs_vfs.h
--- a/fs/xfs/linux/xfs_vfs.h Wed Jul 16 12:10:39 2003
+++ b/fs/xfs/linux/xfs_vfs.h Wed Jul 16 12:10:39 2003
@@ -44,8 +44,8 @@
typedef struct vfs {
u_int vfs_flag; /* flags */
- fsid_t vfs_fsid; /* file system ID */
- fsid_t *vfs_altfsid; /* An ID fixed for life of FS */
+ __kernel_fsid_t vfs_fsid; /* file system ID */
+ __kernel_fsid_t *vfs_altfsid; /* An ID fixed for life of FS */
bhv_head_t vfs_bh; /* head of vfs behavior chain */
struct super_block *vfs_super; /* Linux superblock structure */
struct task_struct *vfs_sync_task;
diff -Nru a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c
--- a/fs/xfs/xfs_mount.c Wed Jul 16 12:10:39 2003
+++ b/fs/xfs/xfs_mount.c Wed Jul 16 12:10:39 2003
@@ -889,7 +889,7 @@
* File systems that don't support user level file handles (i.e.
* all of them except for XFS) will leave vfs_altfsid as NULL.
*/
- vfsp->vfs_altfsid = (fsid_t *)mp->m_fixedfsid;
+ vfsp->vfs_altfsid = (__kernel_fsid_t *)mp->m_fixedfsid;
mp->m_dmevmask = 0; /* not persistent; set after each mount */
/*
On Mon, Aug 04, 2003 at 11:27:53AM -0700, David Mosberger wrote:
> >>>>> On Mon, 4 Aug 2003 11:00:16 -0700, [email protected] (Jesse Barnes) said:
>
> Jesse> big sur is broken because non-ACPI based PCI enumeration has
> Jesse> been removed from the tree.
>
> That shouldn't break big sur. Perhaps you need newer firmware,
> though?
You're right, I thought that big sur didn't use ACPI to enumerate PCI,
but I guess it does.
Jesse
On Llu, 2003-08-04 at 19:45, David S. Miller wrote:
> My point was that if some random single monkey like me can keep a
> loser platform like sparc64 still building in Linus's tree, a group of
> several trained professionals should be able to fare much better :)
Right but ia64 - for better or worse started off as a hideously
divergent tree that did really stupid things like redefine GFP_DMA. It
may be that ia64 should have aimed in a different direction from day one
but having finally ended up in the right place *is* a milestone.
[email protected] (Jesse Barnes) writes:
|> diff -Nru a/fs/xfs/linux/xfs_vfs.h b/fs/xfs/linux/xfs_vfs.h
|> --- a/fs/xfs/linux/xfs_vfs.h Wed Jul 16 12:10:39 2003
|> +++ b/fs/xfs/linux/xfs_vfs.h Wed Jul 16 12:10:39 2003
|> @@ -44,8 +44,8 @@
|>
|> typedef struct vfs {
|> u_int vfs_flag; /* flags */
|> - fsid_t vfs_fsid; /* file system ID */
|> - fsid_t *vfs_altfsid; /* An ID fixed for life of FS */
|> + __kernel_fsid_t vfs_fsid; /* file system ID */
|> + __kernel_fsid_t *vfs_altfsid; /* An ID fixed for life of FS */
|> bhv_head_t vfs_bh; /* head of vfs behavior chain */
|> struct super_block *vfs_super; /* Linux superblock structure */
|> struct task_struct *vfs_sync_task;
Alternatively you could use this patch (following the other
architectures):
--- linux-2.5.73/include/asm-ia64/statfs.h.~1~ 2003-06-22 20:32:55.000000000 +0200
+++ linux-2.5.73/include/asm-ia64/statfs.h 2003-07-01 16:14:44.000000000 +0200
@@ -6,6 +6,11 @@
* Copyright (C) 1998, 1999 David Mosberger-Tang <[email protected]>
*/
+#ifndef __KERNEL_STRICT_NAMES
+# include <linux/types.h>
+typedef __kernel_fsid_t fsid_t;
+#endif
+
/*
* This is ugly --- we're already 64-bit, so just duplicate the definitions
*/
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 N?rnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
On 04 Aug 2003 20:07:58 +0100
Alan Cox <[email protected]> wrote:
> but having finally ended up in the right place *is* a milestone.
I agree.
I apologize, I really didn't want to diminsh what has been
accomplished. I was trying to achieve something different :)
>>>>> "David" == David Mosberger <[email protected]> writes:
David> Now that Linus' tree works for ia64, the next question is how
David> we can keep it that way. I think it would be useful to have
David> someone setup a cron job which does daily builds/automated
David> tests off of Linus tree. If something breaks, the person doing
David> this could perhaps come up with a minimal patch which gets
David> Linus' tree to build again (and submit a patch to the
David> appropriate maintainer, with cc to the linux-ia64 list). I
David> plan on continuing to put out roughly monthly ia64-specific
David> patches and during those normal cycles, I'd then integrate the
David> "quick fix up" patches as needed. Does this sound reasonable?
David> Anybody want to volunteer for this "Linus watchdog" role?
We can do this. We're tracking Linus's tree anyway for the work we're
doing.
We'd probably do daily automated builds to check that the kernel
still compiles cleanly for HPSIM, DIG, and ZX1, but test only weekly.
If you have anyu specific configuration options you think should be
included, let us know.
--
Dr Peter Chubb http://www.gelato.unsw.edu.au peterc AT gelato.unsw.edu.au
You are lost in a maze of BitKeeper repositories, all slightly different.
>>>>> On Tue, 5 Aug 2003 09:06:18 +1000, Peter Chubb <[email protected]> said:
>>>>> "David" == David Mosberger <[email protected]> writes:
David> Now that Linus' tree works for ia64, the next question is how
David> we can keep it that way. I think it would be useful to have
David> someone setup a cron job which does daily builds/automated
David> tests off of Linus tree. If something breaks, the person doing
David> this could perhaps come up with a minimal patch which gets
David> Linus' tree to build again (and submit a patch to the
David> appropriate maintainer, with cc to the linux-ia64 list). I
David> plan on continuing to put out roughly monthly ia64-specific
David> patches and during those normal cycles, I'd then integrate the
David> "quick fix up" patches as needed. Does this sound reasonable?
David> Anybody want to volunteer for this "Linus watchdog" role?
Peter> We can do this. We're tracking Linus's tree anyway for the work we're
Peter> doing.
Excellent!
Peter> We'd probably do daily automated builds to check that the kernel
Peter> still compiles cleanly for HPSIM, DIG, and ZX1, but test only weekly.
Sounds reasonable. Except doing a boot/halt cycle on the simulator
should be easy to automate, no? The simulator can actually catch a
surprising number of problems.
Peter> If you have anyu specific configuration options you think should be
Peter> included, let us know.
Nothing in particular, though it would be good to cover UP, MP, 16,
and 64KB page sizes (not in all permutations, of course).
Thanks,
--david
On Mon, Aug 04, 2003 at 04:35:32PM -0700, David Mosberger wrote:
> David> Now that Linus' tree works for ia64, the next question is how
> David> we can keep it that way. I think it would be useful to have
> David> someone setup a cron job which does daily builds/automated
> David> tests off of Linus tree.
>
> Peter> We'd probably do daily automated builds to check that the kernel
> Peter> still compiles cleanly for HPSIM, DIG, and ZX1, but test only weekly.
It has been running OK for a few days now, so please feel free to
check out
http://www.gelato.unsw.edu.au/kerncomp
for the status of daily IA64 builds. We will attempt to keep track of
what is happening and fix anything that needs fixing or point to where
it has been fixed.
We're still working on automated testing (i.e. booting on the
simulator, maybe real hardware).
-i
[email protected]
http://www.gelato.unsw.edu.au
On Wed, Aug 13, 2003 at 10:07:51AM +1000, Ian Wienand wrote:
> We're still working on automated testing (i.e. booting on the
> simulator, maybe real hardware).
For those who are interested, we now attempt to boot the autobuilt
kernels on the simulator daily. See
http://www.gelato.unsw.edu.au/kerncomp/simboot.php
-i
[email protected]
http://www.gelato.unsw.edu.au
>>>>> On Wed, 10 Sep 2003 10:53:17 +1000, Ian Wienand <[email protected]> said:
Ian> On Wed, Aug 13, 2003 at 10:07:51AM +1000, Ian Wienand wrote:
>> We're still working on automated testing (i.e. booting on the
>> simulator, maybe real hardware).
Ian> For those who are interested, we now attempt to boot the autobuilt
Ian> kernels on the simulator daily. See
Ian> http://www.gelato.unsw.edu.au/kerncomp/simboot.php
Very nice! (The test setup & web-page, not the fact that the boot
failed... ;-).
As for perfmon under Ski: the latest perfmon should have the necessary
code, but I don't remember whether it made it into test5 already (and
I don't have CONFIG_PERFMON enabled in my Ski setup). If it's not
there already, it should be there tomorrow, as Linus pulled on the
ia64 repository a couple of hours ago.
--david