- Community Home
- >
- Servers and Operating Systems
- >
- Legacy
- >
- Operating System - Tru64 Unix
- >
- vmunix: trap: invalid memory write access from ker...
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-14-2005 08:48 PM
тАО10-14-2005 08:48 PM
vmunix: trap: invalid memory write access from kernel mode
Today my server Alpha ES40(o/s 5.1B,firmware 6.3-2)got rebooted giving below mentioned error.
Oct 15 13:00:58 atd1 vmunix: trap: invalid memory write access from kernel mode
Oct 15 13:00:58 atd1 vmunix:
Oct 15 13:00:58 atd1 vmunix: faulting virtual address: 0x0000000000000010
Oct 15 13:00:58 atd1 vmunix: pc of faulting instruction: 0xffffffff000bb82c
Oct 15 13:00:58 atd1 vmunix: ra contents at time of fault: 0xffffffff000bb82c
Oct 15 13:00:58 atd1 vmunix: sp contents at time of fault: 0xfffffe05e5e4f620
Oct 15 13:00:58 atd1 vmunix:
Oct 15 13:00:58 atd1 vmunix: panic (cpu 2): kernel memory fault
Can any one pin point what is the actual cause of failure?
Is it related to h/w?
Attached herewith binary.errlog & messages.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-14-2005 10:36 PM
тАО10-14-2005 10:36 PM
Re: vmunix: trap: invalid memory write access from kernel mode
Thanks
Azim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-15-2005 03:11 AM
тАО10-15-2005 03:11 AM
Re: vmunix: trap: invalid memory write access from kernel mode
what patch kit are you running?
It sounds like a software matter to me.
greetings,
Michael
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-16-2005 05:42 PM
тАО10-16-2005 05:42 PM
Re: vmunix: trap: invalid memory write access from kernel mode
The current installed patchkits are
KITNAME>
KITNAME>
KITNAME>
regds
azim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-17-2005 08:55 AM
тАО10-17-2005 08:55 AM
Re: vmunix: trap: invalid memory write access from kernel mode
Looking at the attached info, its better you call your software support.
It looks like a hardware issue.
David
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО10-24-2005 12:37 AM
тАО10-24-2005 12:37 AM
Re: vmunix: trap: invalid memory write access from kernel mode
There is nothing in the binary.errlog that points to a HW problem. The file is 1 year old, so you should recycle it via the command:
kill -USR1 `cat /var/run/binlogd.pid`
The messages file shows that the ES40 was booted on Oct 15 at 8:49 and 4 hrs later it paniced and rebooted again.
Was anything changed before the reboot at 8:49 ?
Please make sure that new_wire_method=1 in /etc/sysconfigtab . If not, reboot with this vm-parameter set to 1, I believe it will help to avoid this kind of panic.
Rgds,
__ Johan /.
_JB_