| ID | Category [?] | Severity [?] | Reproducibility | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 05545 | Crash/Freeze | Critical (emulator) | Sometimes | Apr 25, 2014, 04:57 | May 2, 2016, 15:49 |
| Tester | maclover490 | View Status | Public | Platform | MESS (Official Binary) |
| Assigned To | smf | Resolution | Open | OS | Windows Vista/7/8 (64-bit) |
| Status [?] | Assigned | Driver | |||
| Version | 0.153 | Fixed in Version | Build | 64-bit | |
| Fixed in Git Commit | Github Pull Request # | ||||
| Summary |
 05545: ct486: Attempting to install Microsoft OS/2 1.1 crashes MESS |
||||
| Description |
When I attempt to install Microsoft OS/2 1.1 the installer is able to partition the hard disk but after rebooting to continue installation, the guest OS crashes with a "TRAP 000D" and sometimes takes MESS down with it. The error displayed on the console output is: "FATALERROR: i386: Invalid REP/opcode 1A combination" |
||||
| Steps To Reproduce |
- Create a hard disk for installing OS/2 (I used a 40MB disk with CHS values 820/6/17) - Start MESS using the ct486 driver with "hard1" set to the CHD you created and "flop1" set to the OS/2 1.1 install floppy. - Configure the CMOS settings (For the hard disk I configured, it was a "Type 40" disk and drive A: needs to be set to 1.44MB) - Attempt to install OS/2 1.1 following the onscreen instructions. |
||||
| Additional Information |
I did a regression test with the SVN and found that this problem began with MESS SVN r26322. When I attempted to capture the TRAP error with F12 it seemed to prevent MESS from crashing. I also seemed to get two slightly different TRAP errors. |
||||
| Github Commit | |||||
| Flags | |||||
| Regression Version | 0.152 | ||||
| Affected Sets / Systems | ct486 | ||||
|
Attached Files
|
 0032.png (6,561 bytes) Apr 25, 2014, 04:57 Uploaded by maclover490One of the TRAP errors I captured
| ||||
| 0031.png (6,796 bytes) Apr 29, 2014, 19:05 Uploaded by maclover490 The other TRAP message that I get
| |||||
 No.10643
NekoEd Senior Tester
Apr 28, 2014, 23:01
|
I noticed in the screenshot that as it's printing the register dump for the first trap (0xD) it traps again after getting as far as BH, then traps 0x1. At this point the register dump starts over. |
|---|---|
 No.10649
mahlemiut Developer
Apr 29, 2014, 22:14
|
Does the same thing occur on the at486 driver also? I've had a similar issue trying to boot a certain Linux distro on ct486, but it worked fine on at486. Could possibly be related to the CS4031 chipset that ct486 emulates. |
 No.10653
crazyc Developer
Apr 29, 2014, 23:08
|
I get a trap now when booting from an already installed and previously working HDD image. |
|
No.10654
maclover490 Tester
Apr 30, 2014, 02:18
|
Same thing happens in at486 |
 No.10656
Duke Developer
Apr 30, 2014, 08:07
|
Assign to smf please. commit e48755ef7aea40271e62718e4ee5d875e9f9b370 Author: smf <smf@localhost> Date: Thu Nov 21 01:12:08 2013 +0000 Calculate seek time using tracks rather than sectors, assuming that reading any sector on the current track will already be in the drives cache. Zeros m_cur_lba when the drive is reset for consistency (running kinst in a debug build took 30 seconds to start) (nw) Notes: r26322 trunk http://git.redump.net/mame/commit/?id=e48755ef7aea40271e62718e4ee5d875e9f9b370 |
|
No.12585
crazyc Developer
May 2, 2016, 12:46
|
The original issue has been fixed but in the meantime, IDE timing were changed to be too fast so it still doesn't work. |
|
No.12586
Haze Senior Tester
May 2, 2016, 15:49
|
are we still trying to squeeze everything into a single timing model when really a lot of this older stuff ran slower than newer drives? |