Author Topic: Possible causes of TRAP000e in OS2LVM?  (Read 13617 times)

Pete

  • Hero Member
  • *****
  • Posts: 1281
  • Karma: +9/-0
    • View Profile
Possible causes of TRAP000e in OS2LVM?
« on: June 21, 2016, 03:13:38 pm »
Hi All

Having shutdown a system that had been running fine, no reported problems and xWP shutdown seemed to work fine, I was somewhat surprised the next morning when the system failed to boot with this problem

Exception in module OS2LVM
TRAP000e


I have 2 other eCS installations on the same system and both of those fail to boot with the same problem.

I tried booting from the eCS2.2beta2 install dvd. That does not quite succeed; the system reboots when the graphical part of the install should start. I suspect the problem could well be the OS2LVM TRAP000e as with the problem disk disconnected the eCS install dvd boots fine.


Any thoughts on this problem - and how to resolve it? Possible loss of partition LVM info?

I could post an image of the TRAP screen if required.


Regards

Pete


ivan

  • Hero Member
  • *****
  • Posts: 1556
  • Karma: +17/-0
    • View Profile
Re: Possible causes of TRAP000e in OS2LVM?
« Reply #1 on: June 21, 2016, 04:00:20 pm »
Hi Pete,

TRAP 000E - PAGE FAULT: The referenced page is not present in memory, or the procedure referencing the page does not have enough privilege to access the page.

It could be that you have some dud memory which is the usual reason for this.  Just run memtest from a bootable CD.

Pete

  • Hero Member
  • *****
  • Posts: 1281
  • Karma: +9/-0
    • View Profile
Re: Possible causes of TRAP000e in OS2LVM?
« Reply #2 on: June 21, 2016, 08:48:52 pm »
Hi ivan

I had not thought of checking RAM so followed your advice.The memtest result after 1:33:02 is Pass: 2, Errors: 0

I suspect that the problem is LVM info related. Of the 3 eCS installations on the disk 2 boot from HPFS formatted drives and have JFS-1.09.06 installed. These trap immediately after the kernel message is displayed, probably during loading OS2LVM.DMD. The other installation boots from a JFS-1.09.05 formatted drive and gets a little further; chkdsk for the 1st JFS volume starts before the trap appears.

Jan (DFSee) is having a look through the files generated by the DFSee "analyse disks" function so if it is LVM info related it should be "sortable" - hopefully. The question will then be: What caused the loss of LVM info?


Regards

Pete






Dave Yeo

  • Hero Member
  • *****
  • Posts: 4775
  • Karma: +99/-1
    • View Profile
Re: Possible causes of TRAP000e in OS2LVM?
« Reply #3 on: June 22, 2016, 05:02:31 am »
I'd suspect a dieing hard drive. Also always a good idea to clean your computer. Do to using wood heat here, I need to blow out the dust monthly.

Pete

  • Hero Member
  • *****
  • Posts: 1281
  • Karma: +9/-0
    • View Profile
Re: Possible causes of TRAP000e in OS2LVM?
« Reply #4 on: June 22, 2016, 05:12:36 pm »
Hi Dave

If the disk is dying then I hope it does it quickly - only a few more months warranty on it. However, this disk has been accused of dying previously, about 6 months ago, as that seems the quick answer to disk/file/filesystem problems so I doubt that is the case.

I am somewhat hopeful it is some missing LVM info - I seem to recall a similar trap years ago when I did not run vcu(?) against a drive with Warp4 installed before trying to use it with an LVM system.

As Jan (DFSee) is currently on holiday I am not expecting a quick response but will post outcome of attempted rescue in the, hopefully, near future.

I certainly hope it is not a dying disk as I bought 5 of these WD "Green" 1TB SATA3 drives at the same time...


Regards

Pete

Pete

  • Hero Member
  • *****
  • Posts: 1281
  • Karma: +9/-0
    • View Profile
Re: Possible causes of TRAP000e in OS2LVM?
« Reply #5 on: July 10, 2016, 08:28:57 am »
Hi All

The answer seems to have been a failing power supply.

I noticed when running some DFSee tests from Windows that the same tests repeated later could take much longer than expected - Analyse disks should take about 2 hours for a 1Tb disk which is about the time it took for the first test; the second test started around 4 hours after the first test had completed showed an ETA of 22 hours - after running for 3 hours. Windows7, installed on a different disk, also got slower at accessing programs/data. Obviously something wrong...

As DFSee seemed to be able to work shortly after power on but struggled after the system had been on for a while I opened the system box for a clean out and noticed the psu vent grille looking very dusty so pulled out the psu for a thorough clean.

On opening the psu it was obvious that it had been overheating. Guess I could have given it a clean up and hoped that it would work but as the receipt dates it as purchased in October 2008 I decided to replace it.

With the new psu installed I still could not boot any of the 3 eCS systems installed.

Jan (DFSee) suggested setting the volume/partition type to something unknown and then trying to boot from the eCS2.2beta2 dvd. I booted Windows7 to change the OS/2 partition types...

I then booted from the eCS2.2beta2 dvd through to the Maintenance Console, opened a command line window and tried to use dir against several of the volumes. All reported "dirty filesystem".

After running chkdsk /f against all the volumes I booted from the eCS2.2beta installation on drive H: - rather pleased that it was not a failing hard drive as my backups were not as up to date as they should be.

My best guess is that things got a bit "mangled" during the last shutdown, possibly just before, due to a failing psu.


Regards

Pete






Pete

  • Hero Member
  • *****
  • Posts: 1281
  • Karma: +9/-0
    • View Profile
Re: Possible causes of TRAP000e in OS2LVM?
« Reply #6 on: February 15, 2017, 04:58:07 pm »
Hi All

Based on a very recent reappearance of this problem it seems that the PSU was not necessarily to blame.

I had just booted my system, waited for all startup activity to finish and then started Seamonkey. I used google to locate the download page for an app called PC Companion - for the Sony Xperia phone range.

I tried to download the app but the webpage required javascript to be enabled so I selected the NoScript option "Temporarily allow all this page"

The webpage started to reload and I noticed my mouse was moving very erratically when I tried to move the pointer - naff javascript? - then Seamonkey froze followed by a complete system lockup which required a press of the Reset button.

Guess what happened on the reboot? Yes, you got it :-

Exception in module OS2LVM
TRAP000e

Having been here before I booted into Windows7, ran DFSee and changed all volumes with Type 0x35 to Type 0x07 and rebooted to eCS2.2b2 - all volumes were chkdsk'd during boot and they needed it.

So, it seems the problem is caused when an application or hardware failure takes the system down and whatever extra LVM Info Type 0x35 (LVM) volumes should have does not get written at shutdown.

As Type 0x07 volumes do not have to write the Type 0x35 "extra" LVM Info at shutdown they do not seem to suffer this problem.

I think I'll leave all my volumes as Type 0x07.


Regards

Pete


Alex Taylor

  • Sr. Member
  • ****
  • Posts: 385
  • Karma: +5/-0
    • View Profile
Re: Possible causes of TRAP000e in OS2LVM?
« Reply #7 on: February 16, 2017, 10:42:31 am »
I recently saw this whenever I tried to plug in a USB hard disk, into either of two different OS/2 systems. 

The hard disk in question was a SATA disk that had previously been pulled out of a desktop and been sitting on the shelf for months, with various partitions full of old data on it.  Putting it into a SATA-to-USB cradle and plugging it into either OS/2 system caused an instant trap in OS2LVM.DMD when LVM /rediscoverprm ran. Since it happened on both systems I assumed it wasn't the computer(s), and since other disks seemed fine in the USB cradle I concluded it must be something in the drive.

However, attaching the drive under Windows worked fine, and I could see all partitions and access the ones with Win-compatible filesystems. 

On a hunch, therefore, I deleted all of the partitions on the drive (using the Windows disk manager).

That appears to have eliminated the trap.  After that, I could plug it into my OS/2 systems and repartition & use it without problems.

So my guess is that something in the partition table ended up in a state which LVM just choked on.

Pete

  • Hero Member
  • *****
  • Posts: 1281
  • Karma: +9/-0
    • View Profile
Re: Possible causes of TRAP000e in OS2LVM?
« Reply #8 on: February 16, 2017, 04:52:09 pm »
Hi Alex

My guess would be that the disk had type 0x35 (LVM) volumes and that the "extra" LVM info relating to that volume type was scrambled - based on my recent experience of 2 instances of this problem. Simply changing the volume type to 0x07 Compatible may well have resolved the issue for you.

Anyone know what this extra LVM info is?

As you may have noticed disks with this problem cannot be fixed from OS/2 based systems - and the use of DFSee is highly recommended; if you have a Registration Jan is very helpful  :-)


Regards

Pete




Lars

  • Hero Member
  • *****
  • Posts: 1268
  • Karma: +65/-0
    • View Profile
Re: Possible causes of TRAP000e in OS2LVM?
« Reply #9 on: February 17, 2017, 04:11:36 pm »
I suppose that Partition type 0x7 is "compatibility Volume" and Partition type 0x35 is "LVM volume".
This is only relevant for JFS as only JFS can be either "compatibility" or "LVM" volume (everything else needs to be "compatibility"):

A "compatibility" and also a "LVM" JFS volume has a DLAT sector as the last sector of the first track of a partition. It saves stuff like disk Name, Partition Name and volume Name and drive letter.

In addition , a "LVM" JFS volume also has a "LVM signature area (BBR)" right inside the JFS Partition that contains "DriveLink" and "BadBlock" Information. Obviously, the DriveLink info is needed if an "LVM" volume spans multiple partitions, possibly across multiple physical drives. It will allow LVM to figure out what partitions on what drives belong to that one JFS volume.
"BadBlock" adds additional functionality to remember which sector/block was broken so that the filesystem can avoid using that sector/block. I don't think that is too valuable as modern hard disks do a bad sector remapping in HW, completely transparent to any SW.
Thinking about the fact that the DLAT sector saves the drive letter, I would say there is some cross-dependency between the BBR and the DLAT sector (the DLAT sector needs to list the very same drive letter for all partitions belonging to the same volume).

Taken from here:
http://www.dfsee.com/present/pcpartit/pcpartit.pdf

That said I'd suspect that there is some problem with the BBR and/or the dependency to the DLAT sector.
Why are you using "LVM" volumes anyway ? They cannot be booted from and they have no added benefit unless you intend to span a volume across multiple partitions/drives. With today's large disks (and "home user" requirements) I cannot see why you would want to do that.


« Last Edit: February 17, 2017, 04:18:58 pm by Lars »

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: Possible causes of TRAP000e in OS2LVM?
« Reply #10 on: February 17, 2017, 06:11:52 pm »
Quote
Why are you using "LVM" volumes anyway ? They cannot be booted from and they have no added benefit unless you intend to span a volume across multiple partitions/drives.

The main advantage, IMO, is that windows will ignore them, rather than try to convince the user to format them.

Pete

  • Hero Member
  • *****
  • Posts: 1281
  • Karma: +9/-0
    • View Profile
Re: Possible causes of TRAP000e in OS2LVM?
« Reply #11 on: February 17, 2017, 06:41:51 pm »
Hi Lars,

No, I am no longer using Type 0x35 (LVM) for any volume as it seems that type is prone to problems. As Doug says the main (only?) advantage is that Windows totally ignores that volume type.

Type 0x35 is not necessary to create a volume that spans drives - Type 0x07 does that.

All my ex-Type0x35 volumes were data only volumes and had no need to be bootable as they would not boot.

From a quick look using DFSee I see that I need to "clean up" the ex-Type 0x35 volumes which involves clearing the BBR sector for each volume to avoid possible "disk corrupt" messages from LVM. Nice of the DFSee log to also provide the required command.


Regards

Pete


« Last Edit: February 17, 2017, 06:47:24 pm by Pete »

Lars

  • Hero Member
  • *****
  • Posts: 1268
  • Karma: +65/-0
    • View Profile
Re: Possible causes of TRAP000e in OS2LVM?
« Reply #12 on: February 17, 2017, 10:21:13 pm »
A "compatibility" volume cannot span drives.

Pete

  • Hero Member
  • *****
  • Posts: 1281
  • Karma: +9/-0
    • View Profile
Re: Possible causes of TRAP000e in OS2LVM?
« Reply #13 on: February 18, 2017, 05:04:00 am »
Hi Lars

Sorry, you are correct; it has to be an LVM volume.

Long time since I used a spanned drive; probably sometime around mid 2006 - just before I switched to SATA. I seem to recall using HPFS for the spanned drive which is probably why I miss-remembered the requirements.


Regards

Pete