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

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

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

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
[email protected]

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

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

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

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

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.

Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
[email protected]
Ph: 303/938-9838

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

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

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
[email protected]

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

Thanks for that info...

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

--ken