Hello, world!\n
I have a SGI Altix 350 IA64 machine (running SLES 8) for testing before
it goes to the production use. I have succeeded recompiling and booting
the SuSE distribution kernel (2.4.21+patches) from sources, but I have
failed to compile/run any stock kernel from ftp.kernel.org (+ patches from
kernel/ports/ia64/v2.[46]).
Firstly, is there any Linux IA64-specific mailing list?
The MAINTAINERS file points to http://www.linuxia64.org, which is probably
expired (please update the MAINTAINERS file).
Now the detailed description:
---------------------
The 2.6.6 kernel + linux-2.6.6-ia64-040521.diff.bz2 patch compiled and
linked correctly, but failed to boot (it did not print anything to the
console):
ELILO boot: 2.6.6 console=ttyS0
Uncompressing Linux... done
(and without "console=ttyS0" it was the same).
---------------------
The 2.4.26 kernel + linux-2.4.26-ia64-040510.diff.bz2 patch failed to link
on my box with <asm/sn/idle.h> missing:
gcc -D__KERNEL__ -I/usr/src/linux-2.4.26/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -g -fomit-frame-pointer -pipe -ffixed-r13 -mfixed-range=f12-f15,f32-f127 -falign-functions=32 -DGAS_HAS_HINT_INSN -frename-registers --param max-inline-insns=5000 -DBRINGUP -mconstant-gp -nostdinc -iwithprefix include -DKBUILD_BASENAME=process -c -o process.o process.c
process.c:33:25: asm/sn/idle.h: No such file or directory
process.c: In function `cpu_idle':
process.c:167: warning: implicit declaration of function `snidle'
process.c:173: warning: implicit declaration of function `snidleoff'
process.c: In function `arch_kernel_thread':
/usr/src/linux-2.4.26/include/asm/unistd.h:313: warning: `dummy3' might be used uninitialized in this function
/usr/src/linux-2.4.26/include/asm/unistd.h:313: warning: `dummy4' might be used uninitialized in this function
/usr/src/linux-2.4.26/include/asm/unistd.h:313: warning: `dummy5' might be used uninitialized in this function
/usr/src/linux-2.4.26/include/asm/unistd.h:316: warning: `dummy3' might be used uninitialized in this function
/usr/src/linux-2.4.26/include/asm/unistd.h:316: warning: `dummy4' might be used uninitialized in this function
/usr/src/linux-2.4.26/include/asm/unistd.h:316: warning: `dummy5' might be used uninitialized in this function
make[1]: *** [process.o] Error 1
after "touch include/asm/sn/idle.h" it failed to compile sn2_smp.c:
gcc -D__KERNEL__ -I/usr/src/linux-2.4.26/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -g -fomit-frame-pointer -pipe -ffixed-r13 -mfixed-range=f12-f15,f32-f127 -falign-functions=32 -DGAS_HAS_HINT_INSN -frename-registers --param max-inline-insns=5000 -DBRINGUP -mconstant-gp -DLITTLE_ENDIAN -nostdinc -iwithprefix include -DKBUILD_BASENAME=sn2_smp -c -o sn2_smp.o sn2_smp.c
sn2_smp.c: In function `sn2_global_tlb_purge':
sn2_smp.c:116: `node_has_active_cpus' undeclared (first use in this function)
sn2_smp.c:116: (Each undeclared identifier is reported only once
sn2_smp.c:116: for each function it appears in.)
sn2_smp.c:120: structure has no member named `shared_mm'
sn2_smp.c:120: structure has no member named `node_history'
sn2_smp.c: In function `sn2_ptc_deadlock_recovery':
sn2_smp.c:164: `node_has_active_cpus' undeclared (first use in this function)
make[3]: *** [sn2_smp.o] Error 1
include/asm-ia64/sn/nodepda.h is the only containng the "node_has_active_cpus".
---------------------
My .configs are at http://www.fi.muni.cz/~kas/tmp/ia64/.
So is it possible to use stock kernel on Altix 350? Is there a better
list to report this than lkml?
Thanks,
-Yenya
--
| Jan "Yenya" Kasprzak <kas at {fi.muni.cz - work | yenya.net - private}> |
| GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/ Czech Linux Homepage: http://www.linux.cz/ |
++> I consider none of the code I contributed to glibc (which is quite a <++
++> lot) to be as part of the GNU project. -- Ulrich Drepper <++
On Thursday, June 3, 2004 10:01 am, Jan Kasprzak wrote:
> I have a SGI Altix 350 IA64 machine (running SLES 8) for testing before
> it goes to the production use. I have succeeded recompiling and booting
> the SuSE distribution kernel (2.4.21+patches) from sources, but I have
> failed to compile/run any stock kernel from ftp.kernel.org (+ patches from
> kernel/ports/ia64/v2.[46]).
The 2.6 kernel, as of 2.6.0-test10 iirc, should work ok. Recent kernels
contain an 'sn2_defconfig' file that you can use to build a usable kernel:
# tar zxf linux-2.6.6.tar.gz
# cd linux-2.6.6
# make sn2_defconfig
# make -j<some high number> compressed
# boot your kernel
But don't forget that you need to pass 'console=ttyS0' on your kernel boot
line (it's easiest to add this to your elilo.conf file).
> Firstly, is there any Linux IA64-specific mailing list?
> The MAINTAINERS file points to http://www.linuxia64.org, which is probably
> expired (please update the MAINTAINERS file).
Yep, [email protected]
> Now the detailed description:
>
> ---------------------
> The 2.6.6 kernel + linux-2.6.6-ia64-040521.diff.bz2 patch compiled and
> linked correctly, but failed to boot (it did not print anything to the
> console):
>
> ELILO boot: 2.6.6 console=ttyS0
> Uncompressing Linux... done
>
> (and without "console=ttyS0" it was the same).
Is this with the sn2_defconfig file? What PROM are you running?
>
> ---------------------
> The 2.4.26 kernel + linux-2.4.26-ia64-040510.diff.bz2 patch failed to link
> on my box with <asm/sn/idle.h> missing:
Stock (i.e. non-SGI or non-SuSE) 2.4 kernels won't work on Altix. You need
2.6.
> My .configs are at http://www.fi.muni.cz/~kas/tmp/ia64/.
> So is it possible to use stock kernel on Altix 350? Is there a better
> list to report this than lkml?
It should work fine. And linux-ia64 is probably a better list (more chance of
me seeing your message).
Jesse
I am routinely building and booting *-mm kernels on Altix systems. For
example, the 2.6.7-rc2-mm2 kernel I made from Andrews patch set of last
night works fine. His patch set 2.6.7-rc2-mm1 had "issues", but
apparently not just on Altix.
I'd guess that Linus's kernels, such as 2.6.7-rc2, unpatched, are ok too,
but I don't have actual experience with them of late.
I don't know about the kernel/ports/ia64/v2.[46] patches. I am not
adding any such for my work, at least not lately.
> Is there a better list to report this than lkml?
Probably - but I don't know where.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[email protected]> 1.650.933.1373
Wow, mail to lkml is way faster than asking local SGI support :-).
Thank you all for fast reply and sorry for posting to the wrong list.
Jesse Barnes wrote:
: The 2.6 kernel, as of 2.6.0-test10 iirc, should work ok. Recent kernels
: contain an 'sn2_defconfig' file that you can use to build a usable kernel:
: # tar zxf linux-2.6.6.tar.gz
: # cd linux-2.6.6
: # make sn2_defconfig
: # make -j<some high number> compressed
: # boot your kernel
:
Thanks, I did not know about sn2_defconfig nor compressed
(I was trying to boot gzip-9'ed vmlinux, which was probably the reason
of why I failed). Is make sn2_defconfig and make compressed documented
anywhere in the kernel sources? I think short Documentation/ia64/README.Altix
or README.sn2 would be helpful.
However - it still does not work, altough I got at least some
console messages. I have tried both stock 2.6.6 and 2.6.7-rc2-mm2
(make sn2_defconfig, make -j compressed).
Uncompressing Linux... done
Memory: 11803200k/11929104k available (7422k code, 137904k reserved, 4016k data, 336k init)
McKinley Errata 9 workaround not needed; disabling it
Calibrating delay loop... 2077.40 BogoMIPS
Dentry cache hash table entries: 2097152 (order: 10, 16777216 bytes)
Inode-cache hash table entries: 1048576 (order: 9, 8388608 bytes)
Mount-cache hash table entries: 1024 (order: 0, 16384 bytes)
Boot processor id 0x0/0x0
task migration cache decay timeout: 10 msecs.
Mount-cache hash table entries: 1024 (order: 0, 16384 bytes)
Boot processor id 0x0/0x0
task migration cache decay timeout: 10 msecs.
CPU 1: base freq=200.000MHz, ITC ratio=14/2, ITC freq=1400.000MHz+/--1ppm
Calibrating delay loop... 16.44 BogoMIPS
... both kernel versions (2.6.6 and 2.6.7-rc2-mm2) hang there. Also note
the strange bogomips value for CPU 1. The system has three bricks
(6 CPUs, 1400MHz/3MB cache). Firmware is pretty recent (the newest
we could find at http://www.sgi.com):
002c06#0a: SGI SAL Version 3.25 rel040225 IP41 built 12:01:43 PM Feb 25, 2004
I have the following compiler (default in SLES 8):
$ gcc -v
Reading specs from /usr/lib/gcc-lib/ia64-suse-linux/3.2.2/specs
Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --enable-languages=c,c++,f77,objc,java,ada --enable-libgcj --with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit ia64-suse-linux
Thread model: posix
gcc version 3.2.2
: But don't forget that you need to pass 'console=ttyS0' on your kernel boot
: line (it's easiest to add this to your elilo.conf file).
Yes, of course. I have the following in my elilo.conf:
prompt
timeout = 80
read-only
relocatable
image = /vmlinuz-2.6.6
label = 2.6.6
root = 900
append = "console=ttyS0"
[...]
: Yep, [email protected]
:
OK.
: Stock (i.e. non-SGI or non-SuSE) 2.4 kernels won't work on Altix. You need
: 2.6.
:
OK. 2.6 was my primary target, I have tried 2.4 only because
2.6 failed to me.
: It should work fine. And linux-ia64 is probably a better list (more chance of
: me seeing your message).
:
Thanks, I will subscribe to it.
-Yenya
--
| Jan "Yenya" Kasprzak <kas at {fi.muni.cz - work | yenya.net - private}> |
| GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/ Czech Linux Homepage: http://www.linux.cz/ |
++> I consider none of the code I contributed to glibc (which is quite a <++
++> lot) to be as part of the GNU project. -- Ulrich Drepper <++
On Thursday, June 3, 2004 1:09 pm, Jan Kasprzak wrote:
> Wow, mail to lkml is way faster than asking local SGI support :-).
> Thank you all for fast reply and sorry for posting to the wrong list.
Cool, but keep in mind that this is totally unsupported. If this kernel
breaks, you get to keep both pieces (though I'll try to help glue it back
together!) :)
> Thanks, I did not know about sn2_defconfig nor compressed
> (I was trying to boot gzip-9'ed vmlinux, which was probably the reason
> of why I failed). Is make sn2_defconfig and make compressed documented
> anywhere in the kernel sources? I think short
> Documentation/ia64/README.Altix or README.sn2 would be helpful.
I think 'make help' documents most of it.
> However - it still does not work, altough I got at least some
> console messages. I have tried both stock 2.6.6 and 2.6.7-rc2-mm2
> (make sn2_defconfig, make -j compressed).
>
> Uncompressing Linux... done
> Memory: 11803200k/11929104k available (7422k code, 137904k reserved, 4016k
> data, 336k init) McKinley Errata 9 workaround not needed; disabling it
> Calibrating delay loop... 2077.40 BogoMIPS
> Dentry cache hash table entries: 2097152 (order: 10, 16777216 bytes)
> Inode-cache hash table entries: 1048576 (order: 9, 8388608 bytes)
> Mount-cache hash table entries: 1024 (order: 0, 16384 bytes)
> Boot processor id 0x0/0x0
> task migration cache decay timeout: 10 msecs.
> Mount-cache hash table entries: 1024 (order: 0, 16384 bytes)
> Boot processor id 0x0/0x0
> task migration cache decay timeout: 10 msecs.
> CPU 1: base freq=200.000MHz, ITC ratio=14/2, ITC freq=1400.000MHz+/--1ppm
> Calibrating delay loop... 16.44 BogoMIPS
>
> ... both kernel versions (2.6.6 and 2.6.7-rc2-mm2) hang there. Also note
> the strange bogomips value for CPU 1. The system has three bricks
> (6 CPUs, 1400MHz/3MB cache). Firmware is pretty recent (the newest
> we could find at http://www.sgi.com):
>
> 002c06#0a: SGI SAL Version 3.25 rel040225 IP41 built 12:01:43 PM Feb 25,
> 2004
These messages are consistent with having a PROM that's too old; you need at
least 3.32. You'll have to dig around the support site some more or talk to
your support person for that though. Booting with 'nohalt' should work
around this particular issue though.
Jesse
Jesse Barnes wrote:
: Cool, but keep in mind that this is totally unsupported. If this kernel
: breaks, you get to keep both pieces
Yes, of course.
: (though I'll try to help glue it back
: together!) :)
:
Thanks.
: I think 'make help' documents most of it.
OK.
:
: These messages are consistent with having a PROM that's too old; you need at
: least 3.32. You'll have to dig around the support site some more or talk to
: your support person for that though.
:
3.25 is the latest released (or at least the latest I can find).
I will ask local support.
: Booting with 'nohalt' should work
: around this particular issue though.
Yes. It works now, I have 2.6.7-rc2-mm2 up and running. Thanks again.
-Yenya
--
| Jan "Yenya" Kasprzak <kas at {fi.muni.cz - work | yenya.net - private}> |
| GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/ Czech Linux Homepage: http://www.linux.cz/ |
++> I consider none of the code I contributed to glibc (which is quite a <++
++> lot) to be as part of the GNU project. -- Ulrich Drepper <++
>>>>> "Paul" == Paul Jackson <[email protected]> writes:
>> Is there a better list to report this than lkml?
Paul> Probably - but I don't know where.
There are two:
the Gelato-technical mailing list
( see http://www.gelato.org and
https://www.gelato.unsw.edu.au/mailman/listinfo/gelato-technical )
And the Linux-ia64 list
( Archives at http://www.gelato.unsw.edu.au/linux-ia64/
subscription instructions at
http://vger.kernel.org/vger-lists.html#linux-ia64
--
Dr Peter Chubb http://www.gelato.unsw.edu.au peterc AT gelato.unsw.edu.au
The technical we do immediately, the political takes *forever*
On Thu, 2004-06-03 22:09:06 +0200, Jan Kasprzak <[email protected]>
wrote in message <[email protected]>:
[ia64 booting]
> Dentry cache hash table entries: 2097152 (order: 10, 16777216 bytes)
> Inode-cache hash table entries: 1048576 (order: 9, 8388608 bytes)
> Mount-cache hash table entries: 1024 (order: 0, 16384 bytes)
> Boot processor id 0x0/0x0
> task migration cache decay timeout: 10 msecs.
> Mount-cache hash table entries: 1024 (order: 0, 16384 bytes)
> Boot processor id 0x0/0x0
> task migration cache decay timeout: 10 msecs.
> CPU 1: base freq=200.000MHz, ITC ratio=14/2, ITC freq=1400.000MHz+/--1ppm
> Calibrating delay loop... 16.44 BogoMIPS
Hihi:) A ~ 55MHz VAX does nothing with about 15 BogoMIPS.
MfG, JBG*hides now*G
--
Jan-Benedict Glaw [email protected] . +49-172-7608481
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg
fuer einen Freien Staat voll Freier B?rger" | im Internet! | im Irak!
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
On Fri, 4 Jun 2004, Jan-Benedict Glaw wrote:
> On Thu, 2004-06-03 22:09:06 +0200, Jan Kasprzak <[email protected]>
> wrote in message <[email protected]>:
> [ia64 booting]
> > CPU 1: base freq=200.000MHz, ITC ratio=14/2, ITC freq=1400.000MHz+/--1ppm
> > Calibrating delay loop... 16.44 BogoMIPS
>
> Hihi:) A ~ 55MHz VAX does nothing with about 15 BogoMIPS.
Yeah, the bogomips have become too bogus to even be useful these days.
Just as a clarification, "bogomips" is really "bogo-timing-events-per-
second-multiplied-by-two" (aka "bogotepsmbt").
The "timing event" used to be a "two-instruction loop", which is where the
"multiplied-by-two" comes from: at that point the "bogotepsmbt" becomes
the number of instructions per second, and that explains the "mips" part
of the name.
But since it's really used for timing small delay loops, and since the
two-instruction loop wasn't very good at that (due to power-usage, SMT
issues, frequency changes, you name it), the implementations have sadly
started to drift away from using instruction retire as the event they
count, and start using a separate counter instead.
So 16.44 BogoMIPS these days really implies " ~8MHz timer frequency ".
The timer is a lot better from a technical standpoint, but it sure is a
hell of a lot less entertaining than the original MIPS thing..
Linus