[Linux-ia64] Kernel: which machine to choose?

[Linux-ia64] Kernel: which machine to choose?

[G\351raud Krawezik]

Hello,

In order to use a kernel that support modules, I have downloaded
2.4.0-test5.
There are four different kind of workstations available: Generic,
HP-simulator, SN1, DIG Compliant.

HP-Sim crashes at the very beginning of the booting sequence
SN1 cannot compile
DIG compliant crashes while booting.

I'm ok to make minor modifications by myself to haev this fixed, but could
someone tell me what version should I use? (from what I have seen, Generic
uses all the others, so it does not compile and some definitions seem to
be rather old...)
I'm using an SDV from intel.


Thanks by advance


Geraud

RE: [Linux-ia64] Kernel: which machine to choose?

[Broadfoot, KenX]

I use:

DIG-compliant
Enable Itanium A-step
Enable Itanium A1-step
Enable AzusA hacks
Enable IA64 Machine Check Abort
SMP support

----------------------------------------------------------------

I am not using SoftSDV hacks ( strange I know )
I compile SMP even for the single proc box. It just "seems" more stable.

My uptime is 4 days and 20 hours as of this writing.

--ken

> -----Original Message-----
> From:	G\351raud Krawezik [SMTP:gk@scali.no]
> Sent:	Tuesday, August 08, 2000 12:15 AM
> To:	linux-ia64@linuxia64.com
> Subject:	[Linux-ia64] Kernel: which machine to choose?
> 
> Hello,
> 
> In order to use a kernel that support modules, I have downloaded
> 2.4.0-test5.
> There are four different kind of workstations available: Generic,
> HP-simulator, SN1, DIG Compliant.
> 
> HP-Sim crashes at the very beginning of the booting sequence
> SN1 cannot compile
> DIG compliant crashes while booting.
> 
> I'm ok to make minor modifications by myself to haev this fixed, but could
> someone tell me what version should I use? (from what I have seen, Generic
> uses all the others, so it does not compile and some definitions seem to
> be rather old...)
> I'm using an SDV from intel.
> 
> 
> Thanks by advance
> 
> 
> Geraud
> 
> 
> _______________________________________________
> Linux-IA64 mailing list
> Linux-IA64@linuxia64.org
> http://lists.linuxia64.org/lists/listinfo/linux-ia64

RE: [Linux-ia64] Kernel: which machine to choose?

[David Mosberger]

>>>>> On Tue, 8 Aug 2000 09:02:51 -0700 , "Broadfoot, KenX" <kenx.broadfoot@intel.com> said:

  Ken> I use:
  Ken>	DIG-compliant Enable
  Ken>  Itanium A-step Enable
  Ken>  Itanium A1-step Enable
  Ken>  AzusA hacks Enable
  Ken>  IA64 Machine Check Abort
  Ken>  SMP support

I wouldn't recommendn turning on AzusA hacks unless you have an AzusA
machine.

  Ken> I am not using SoftSDV hacks ( strange I know ) I compile SMP
  Ken> even for the single proc box. It just "seems" more stable.

SoftSDV is for the (Intel) simulator only.  Do _not_ turn this on for
real hw.

	--david

Re: [Linux-ia64] Kernel: which machine to choose?

[Uros Prestor]

David Mosberger wrote:

> I wouldn't recommendn turning on AzusA hacks unless you have an AzusA
> machine.

Why is that?  Our kernels have been compiled with AzusA hacks enabled and we had no problems
with our kernels running on BigSurs and Lions.

On another note, we are getting a lot more segfaults during builds lately.  The 0505 release
which had the 2.3.99-pre6 kernel was rock solid; after moving to 2.4.0 kernels the segfaults
came back with a vengeance.  We did upgrade processors from A2 to A3 but I don't think this
could be a culprit.  Any ideas on this?

Thanks,
Uros

--
Uros Prestor
uros@turbolinux.com

Re: [Linux-ia64] Kernel: which machine to choose?

[David Mosberger]

>>>>> On Tue, 08 Aug 2000 11:26:09 -0700, Uros Prestor <uros@turbolinux.com> said:

  Uros> Why is that?  Our kernels have been compiled with AzusA hacks
  Uros> enabled and we had no problems with our kernels running on
  Uros> BigSurs and Lions.

Any configuration with the string *HACKS* in it should be turned on
only for that machine.  You may get lucky at the moment and the
current AzusA hacks may not cause problems on Lion or BigSur, but I
won't guarantee that it will stay that way.  The AzusA hacks need to
be merged in cleanly with the existing source code so that #define can
go away (eventually, I don't expect this to happen over night).

  Uros> On another note, we are getting a lot more segfaults during
  Uros> builds lately.  The 0505 release which had the 2.3.99-pre6
  Uros> kernel was rock solid; after moving to 2.4.0 kernels the
  Uros> segfaults came back with a vengeance.  We did upgrade
  Uros> processors from A2 to A3 but I don't think this could be a
  Uros> culprit.  Any ideas on this?

Yes, we are seeing similar behavior.  I suspect the kernel's new
memcpy routine.  Can you try the old (and stupid) byte-by-byte copy
routine and let me know if that helps on your machines?

	--david

Re: [Linux-ia64] Kernel: which machine to choose?

[Gerrit.Huizenga]

I noted recently that I couldn't build a kernel on the Lion when
rlogin'd to the machine, but at the console I seem to have no
problem.

Could the problems be a deadlock or other problem in the test1/test4
linux tcp code?

I've also noted that when compiling kernels with:

$ gcc -v
Reading specs from /usr/lib/gcc-lib/ia64-redhat-linux/2.9-ia64-000216-final/specs
 gcc version 2.9-ia64-000216-final

I get 40 MB kernels, although the size of text/data/bss/etc. are about the
same as the 7-8 MB kernels shipped with the RedHat distro on my machine.
And, trying to get the newer compiler to work on the RedHat distro has
been a little problematic.  I'm trying to bootstrap my way to a newer
kernel on the Lion (newer that ~test1) and running into problems where
the Dig kernel won't boot.

Procs are all A3 in the Lions.

gerrit

> David Mosberger wrote:
> 
> > I wouldn't recommendn turning on AzusA hacks unless you have an AzusA
> > machine.
> 
> Why is that?  Our kernels have been compiled with AzusA hacks enabled and we had no problems
> with our kernels running on BigSurs and Lions.
> 
> On another note, we are getting a lot more segfaults during builds lately.  The 0505 release
> which had the 2.3.99-pre6 kernel was rock solid; after moving to 2.4.0 kernels the segfaults
> came back with a vengeance.  We did upgrade processors from A2 to A3 but I don't think this
> could be a culprit.  Any ideas on this?
> 
> Thanks,
> Uros
> 
> --
> Uros Prestor
> uros@turbolinux.com
> 
> 
> 
> 
> _______________________________________________
> Linux-IA64 mailing list
> Linux-IA64@linuxia64.org
> http://lists.linuxia64.org/lists/listinfo/linux-ia64
> 

Re: [Linux-ia64] Kernel: which machine to choose?

[Jes Sorensen]

>>>>> "Uros" = Uros Prestor <uros@turbolinux.com> writes:

Uros> On another note, we are getting a lot more segfaults during
Uros> builds lately.  The 0505 release which had the 2.3.99-pre6
Uros> kernel was rock solid; after moving to 2.4.0 kernels the
Uros> segfaults came back with a vengeance.  We did upgrade processors
Uros> from A2 to A3 but I don't think this could be a culprit.  Any
Uros> ideas on this?

Did you upgrade the compiler as well to a more recent snapshot? Did
you include Dan's hand optimized string/mem routines in your glibc
package?

Jes

Re: [Linux-ia64] Kernel: which machine to choose?

[Jim Wilson]

	I get 40 MB kernels, although the size of text/data/bss/etc. are about the
	same as the 7-8 MB kernels shipped with the RedHat distro on my machine.

Strip out the debug info if you don't want it.  That accounts for most of
the extra size.  There are people working on fixing the dwarf2 debug info
size problem, but I don't know when the result will be available or how well
it will work.

	And, trying to get the newer compiler to work on the RedHat distro has
	been a little problematic.

Which "new" compiler are you trying to use?  000216-final is the latest
compiler release that we have made.  If you try to use something from the
FSF (e.g. gcc.gnu.org), you are likely to run into lots of problem.
We will be making a new compiler release soon, in conjunction with the
glibc 2.2 release that Jes Sorensen is working on.  You might want to wait
for that.

Jim

Re: [Linux-ia64] Kernel: which machine to choose?

[Don Dugger]

Gerrit-

By default the top level `Makefile' specifies the `-g' flag, which puts
about 40MB of debug info into the kernel executable.  Just remove this flag
and your kernel should drop dramatically in size.

On Tue, Aug 08, 2000 at 11:55:11AM -0700, Gerrit.Huizenga@us.ibm.com wrote:
> 
> $ gcc -v
> Reading specs from /usr/lib/gcc-lib/ia64-redhat-linux/2.9-ia64-000216-final/specs
>  gcc version 2.9-ia64-000216-final
> 
> I get 40 MB kernels, although the size of text/data/bss/etc. are about the
> same as the 7-8 MB kernels shipped with the RedHat distro on my machine.

-- 
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
n0ano@valinux.com
Ph: 303/938-9838

Re: [Linux-ia64] Kernel: which machine to choose?

[Jes Sorensen]

>>>>> "Gerrit" = Gerrit Huizenga <Gerrit.Huizenga@us.ibm.com> writes:

Gerrit> I noted recently that I couldn't build a kernel on the Lion
Gerrit> when rlogin'd to the machine, but at the console I seem to
Gerrit> have no problem.

Gerrit> Could the problems be a deadlock or other problem in the
Gerrit> test1/test4 linux tcp code?

I have actually noticed that my machine seems slightly more stable
when compiling without spewing the output to a remote window. Ie. if I
compile XFree in a remote window it is almost certain to lock up, but
both times I tried running it directing the output from stdout/stderr
to a local file the build actually completed. This is on a UP A2 Lion
btw.

I would actually suspect that eepro100 driver or similar.

Jes

Re: [Linux-ia64] Kernel: which machine to choose?

[Uros Prestor]

Jes Sorensen wrote:

> Did you upgrade the compiler as well to a more recent snapshot?

No, we are using Cygnus May release with additional patches.

> Did you include Dan's hand optimized string/mem routines in your glibc
> package?

No -- they are disabled both in 0505 and in 0714 releases because A1
boxes would freeze in about 5-10 minutes with optimized memory functions
enabled.  I haven't tested optimized string/mem functions with A2/A3,
though.

Uros

--
Uros Prestor
uros@turbolinux.com

Re: [Linux-ia64] Kernel: which machine to choose?

[Gerrit.Huizenga]

Ditto - I can be logged in remotely all day, no problem.  I can
build things redirecting output to a file, look at that file
periodically during the build without a problem, run top through
an rlogin session, etc. all without a problem.  However, spewing
output from a build seems to pretty reliably cause a lockup or
sometimes a panic/oops.  I'm not set up so that I can catch the
output of an oops (console over serial) so I'll look at it in more
detail next time it happens.

I've also noticed that when the machine "hangs" it isn't really hung
but cc1 is doing a loop of about 10-20 mmap()'s followed by a break();
the panic seems to happen when the machine runs out of swap.

Why it gets into an mmap/break loop is a mystery (to me, at least).

BTW, thanks to all for the comment about -g (I still have a hand-shaped
imprint on my forehead from that one - we had the same problem with our
compilation tools when we first converted to ELF/DWARF; had to write
sysv cprs(1) to be more agressive).  File sizes are more comprehensible.

On a last question, has anyone run a test4 kernel on a 4-proc Lion
(A3 procs, I forget which BIOS/EFI, but fairly recent)?  I keep getting
SCSI timeouts from the qlogics/SCSI driver.  I see a lot of changes
between test1 & test4 in the generic SCSI code, a couple of which
might be related (looks like test1 has some improved Inquiry code
that test4 does not have).

The relevent dmesg output is:

	scsi(0): Determining if RISC is loaded...
	scsi(0): Verifying chip...
	scsi(0): Setup chip...
	scsi(0): Configure NVRAM parameters...
	scsi(0): Resetting SCSI BUS (0)
	scsi(0): Resetting SCSI BUS (1)
	scsi0 : QLogic QLA12160 PCI to SCSI Host Adapter: bus 1 device 2 irq 10
	       Firmware version: 10.01.19, Driver version  3.00-Beta
	scsi : 1 host.
	scsi : aborting command due to timeout : pid 0, scsi0, channel 0, id 0, lun 0 Inquiry 00 00 00 ff 00
	scsi(0): ABORT Command=0xe00000007fd06080, handle=0x1
	SCSI host 0 abort (pid 0) timed out - resetting
	SCSI bus is being reset for host 0 channel 0.
	scsi(): Resetting Cmnd=0xe00000007fd06080, Handle=0x1, flags=0x2
	scsi(0:0:0:0): Queueing device reset command.
	SCSI host 0 channel 0 reset (pid 0) timed out - trying harder
	SCSI bus is being reset for host 0 channel 0.
	scsi(): Resetting Cmnd=0xe00000007fd06080, Handle=0x1, flags=0x6
	qla1280(0:0:0:0): Issuing BUS DEVICE RESET.
	scsi(0): Resetting SCSI BUS (0)

I note that the IRQ is 10 on the test4 kernel, my test1 kernel has it as
irq 48, I believe.  Other than that, no apparent differences...

gerrit

> >>>>> "Gerrit" = Gerrit Huizenga <Gerrit.Huizenga@us.ibm.com> writes:
> 
> Gerrit> I noted recently that I couldn't build a kernel on the Lion
> Gerrit> when rlogin'd to the machine, but at the console I seem to
> Gerrit> have no problem.
> 
> Gerrit> Could the problems be a deadlock or other problem in the
> Gerrit> test1/test4 linux tcp code?
> 
> I have actually noticed that my machine seems slightly more stable
> when compiling without spewing the output to a remote window. Ie. if I
> compile XFree in a remote window it is almost certain to lock up, but
> both times I tried running it directing the output from stdout/stderr
> to a local file the build actually completed. This is on a UP A2 Lion
> btw.
> 
> I would actually suspect that eepro100 driver or similar.
> 
> Jes

RE: [Linux-ia64] Kernel: which machine to choose?

[Broadfoot, KenX]

Thanks for that info...

I just strip the kernel....that seems to work as well..

--ken

> -----Original Message-----
> From:	Don Dugger [SMTP:n0ano@valinux.com]
> Sent:	Tuesday, August 08, 2000 12:15 PM
> To:	linux-ia64@linuxia64.org
> Subject:	Re: [Linux-ia64] Kernel: which machine to choose?
> 
> Gerrit-
> 
> By default the top level `Makefile' specifies the `-g' flag, which puts
> about 40MB of debug info into the kernel executable.  Just remove this
> flag
> and your kernel should drop dramatically in size.
> 
> On Tue, Aug 08, 2000 at 11:55:11AM -0700, Gerrit.Huizenga@us.ibm.com
> wrote:
> > 
> > $ gcc -v
> > Reading specs from
> /usr/lib/gcc-lib/ia64-redhat-linux/2.9-ia64-000216-final/specs
> >  gcc version 2.9-ia64-000216-final
> > 
> > I get 40 MB kernels, although the size of text/data/bss/etc. are about
> the
> > same as the 7-8 MB kernels shipped with the RedHat distro on my machine.
> 
> -- 
> Don Dugger
> "Censeo Toto nos in Kansa esse decisse." - D. Gale
> n0ano@valinux.com
> Ph: 303/938-9838
> 
> _______________________________________________
> Linux-IA64 mailing list
> Linux-IA64@linuxia64.org
> http://lists.linuxia64.org/lists/listinfo/linux-ia64