panic (cpu: 0) Unaligned kernel space access from kernel mode

[Victor_166]

Hello, I need your help
I have an Alphaserver 4100 and after an temperature site problem the server is sending this message:

Loading vmunix symbol table ..´.[1239992]
Unaligned kernel access va 0xfffffc00070b932 pc=0xfffffc4c0
panic (cpu 0)Unaligned space access from kernel mode
DUMP: No primary swap, no explicit dumpdev,Nowhere to put header, giving up.

Thanks in advance

Victor

[Michael Schulte zur Sur]

Hi,

you should define dump_dev on console prompt to a partition, the machine can dump to.

greetings,

Michael

[Ivan Ferreira]

Normally, at startup, the dump will be collected by crashdc. Then you can analyze your dump data located in /var/adm/crash/crash-data.X

[Mark Poeschl_2]

The "no primary swap" part of that error message looks pretty ominous. Can you see all the disk devices from the console ">>>" prompt? If you can find a disk device to explicitly point the console variable "dump_dev" towards (as suggested above) be aware that you will wipe out any useful data on at least part if not all of that disk. That's why the swap device is normally used for holding crash dumps.

[Michael Schulte zur Sur]

Mark,

it would surprise me if it detected the dump at all except in a dump space. You would corrupt most certainly any file system if the os didn't prevent if with an open device error in the first place. The dump_dev is the location the os dumps it if does not proceed beyond the definition of swap in sysconfgigtab.

HP, am I correct?

Michael

[Victor_166]

Yes, I can see all the devices at the >>> prompt

[Mark Poeschl_2]

Exactly Michael - I was merely trying to warn that you risked overwriting (possibly good) data if you set that console variable -I wasn't saying anything about the usability of the dump.

Victor - have you tried booting from either the generic kernel or the installation CD and see what you can see as far as disk devices go from the OS?

[Victor_166]

Yes, we tried to boot the genvmunix, but the server present the same problem, I didn´t probe to boot from the cd, but I installed Tru64 in a new disk and we put the failing disk in the second slot. we can see the disk and the partition but is not possible to mount the partitions

[Martin Moore]

The system can't dump memory to swap because it's panicking too early in the boot sequence. There is no swap space defined by the kernel at this point. Setting the console variable DUMP_DEV will *NOT* get you around this. This is a common piece of misinformation floating around. DUMP_DEV is valid only to OpenVMS, *NOT* Tru64 UNIX.

As far as the panic, I would recommend re-running the ECU (EISA Configuration Utility) from floppy at the console level. All you need to do is run it, then save/exit and power cycle the system. I have seen several similar problems caused by a 4100 losing the EISA configuration information stored in NVRAM.

Regards,
Martin

[Victor_166]

Hello Martin,

For some reason my ECU floppy does´t run, but I will try to get some other, but the question is if I have to run it considering that I don´t have any EISA option, the server has only SCSI controller?