VSBHDA seems to initialize correctly and hangs there
vanfanel opened this issue · 27 comments
Hi there,
I have this Compaq Mini CQ10-500 netbook, where SBEMU used to work fine, but I'm having some trouble running VSBHDA on the same computer.
It seems to initialize without errors, then stays there forever:
This is what APICinfo says on this computer, in case it can help:
Scanning SDTs...
RSDT/XSDT header at 3f5f6120
Table Signature: XSDT
Table length: 74
Entries: 10
MADT at 3f5f3000, sig=APIC, length=120
APIC base address: fee00000
APICID=0
APICVersion=50014
Task Priority Register=0
Destination Format Register=ffffffff
Spurious Interrupt Vector Register=10f (APIC enabled)
Interrupt Command Register Low=c06e9
Interrupt Command Register High=f000000
Timer Local Vector Table Entry=10000 (masked)
Thermal Local Vector Table Entry=200 SMI
Performance Counter Local Vector Table Entry=10000 (masked)
Local Interrupt 0 Vector Table Entry=700 extINT
Local Interrupt 1 Vector Table Entry=400 NMI
Error Vector Table Entry=10000 (masked)
Timer Initial Count Register=0
Timer Current Count Register=0
Timer Divide Config Register=0
Extended APIC Feature Register=0
Extended APIC Control Register=0
MADT (length=120, LAPIC=fee00000, flags=1):
legacy PICs installed
Type 0: Processor LAPIC, ACPI Processor ID=1 APIC ID=0 flags=1
Type 0: Processor LAPIC, ACPI Processor ID=2 APIC ID=1 flags=1
Type 0: Processor LAPIC, ACPI Processor ID=3 APIC ID=0 flags=0
Type 0: Processor LAPIC, ACPI Processor ID=4 APIC ID=0 flags=0
Type 1: IOAPIC, ID=4 address=fec00000 GblSysIntBase=0
Type 2: IOAPIC Interrupt Source Override, Bus Src=0 Irq Src=0 GblSysInt=2 flags=0
Type 2: IOAPIC Interrupt Source Override, Bus Src=0 Irq Src=9 GblSysInt=9 flags=d
Type 4: LAPIC NMI, ACPI Processor ID=1 flags=0 LINT=1
Type 4: LAPIC NMI, ACPI Processor ID=2 flags=0 LINT=1
IOAPIC fec00000
0 IOAPICID=0
1 IOAPICVER=170020
2 IOAPICARB=170020
16 IOREDTBL=33600000.10000
18 IOREDTBL=33000000.10000
20 IOREDTBL=10000000.10416
22 IOREDTBL=29200000.10006
24 IOREDTBL=0.10006
26 IOREDTBL=11600000.10414
28 IOREDTBL=20000000.10052
30 IOREDTBL=33000000.10080
32 IOREDTBL=400000.10002
34 IOREDTBL=600000.10400
36 IOREDTBL=14000000.10406
38 IOREDTBL=30200000.10094
40 IOREDTBL=11400000.10402
42 IOREDTBL=20700000.10004
44 IOREDTBL=33400000.10028
46 IOREDTBL=2000000.10014
48 IOREDTBL=11200000.10416
50 IOREDTBL=20600000.10002
52 IOREDTBL=73600000.10000
54 IOREDTBL=21000000.10416
56 IOREDTBL=1e10000.10100
58 IOREDTBL=33600000.10040
60 IOREDTBL=2600000.10404
62 IOREDTBL=20600000.10410
There's nothing else loaded before I run start.bat or start16.bat that could be interfering:
I am using latest v1.4pre1 tagged build from here.
Any idea on what could be going on?
Any idea on what could be going on?
No. APICinfo is of limited helpfulness if a "freeze" occurs. You'll probably have to create a debug version of the binaries and run them. They display a lot, and this might give a hint what's going on...
@Baron-von-Riedesel Do you mean I should build a debug version of the VSBHDA binaries? If that's what you mean, is it possible to build it on GNU/Linux?
is it possible to build it on GNU/Linux?
Yes - but I have no experience with Open Watcom on Linux. If you aren't familiar with such things, I recommend not to waste time with trying. I may as well upload those binaries here...
ow16d.zip
is it possible to build it on GNU/Linux?
Yes - but I have no experience with Open Watcom on Linux. If you aren't familiar with such things, I recommend not to waste time with trying. I may as well upload those binaries here... ow16d.zip
Thanks for uploading that debug version! However, I don't see any more info than I saw before. Maybe I am missing something? Some special parameter to debug it? On Linux I use GDB, and I remember a program called "debug" on DOS, maybe I should use that?
On Linux I use GDB, and I remember a program called "debug" on DOS, maybe I should use that?
No, these binaries are not supposed to be debugged - they display (debug) infos on the screen. And they don't need special parameters to activate those displays.
On Linux I use GDB, and I remember a program called "debug" on DOS, maybe I should use that?
No, these binaries are not supposed to be debugged - they display (debug) infos on the screen. And they don't need special parameters to activate those displays.
They don't display anything more than the normal binaries here... Maybe you uploaded the non-debug binaries by mistake?
They don't display anything more than the normal binaries here... Maybe you uploaded the non-debug binaries by mistake?
No - both binaries are about 8 kB larger - no mistake.
Here's how the protocol should look like
vsbhda16: entry, esp=8524
b7: malloc(c) free=0 (dynend/curbrk=8524/8524
b7, brk(10): new/old _curbrk 11000/8524, _dynend=9000
b7: malloc(18) free=7ff0 (dynend/curbrk=9010/11000
b7: malloc(18) free=7fd4 (dynend/curbrk=902c/11000
b7: malloc(18) free=7fb8 (dynend/curbrk=9048/11000
[snip]
PTRAP_Install_PM_PortTraps: 388-38b
PTRAP_Install_PM_PortTraps: 20-20
PTRAP_Install_PM_PortTraps: 2-f
PTRAP_Install_PM_PortTraps: 83-8b
PTRAP_Install_PM_PortTraps: c4-de
PTRAP_Install_PM_PortTraps: 220-22f
PTRAP_Install_PM_PortTraps: 330-331
b7: malloc(11f4) free=7e6c (dynend/curbrk=9194/11000
OPL3 emulation enabled at port 388h (44100 Hz).
Sound Blaster emulation enabled at Address=220, IRQ=7, DMA=1, HDMA=5, Type=6
b7: malloc(8200) free=6c74 (dynend/curbrk=a38c/11000
b7, brk(8204): new/old _curbrk 39210/11000, _dynend=31000
b7: malloc(8200) free=c (dynend/curbrk=39204/39210
b7, brk(8204): new/old _curbrk 42210/39210, _dynend=3a000
SNDISR_InstallISR: pOPLPCM=31004 pPCM=3a004
b7: malloc(10000) free=c (dynend/curbrk=42204/42210
b7, brk(10004): new/old _curbrk 53010/42210, _dynend=43000
b7: free(43000) ok
HDA_start, stream#=4
The last line "HDA_start..." should be displayed just before the DOS prompt reappears.
@Baron-von-Riedesel Thanks for your patience with this, really.
I have properly overwritten the VSBHDA files now (it seems my OS wasn't doing so for some reason...), and I can see the debug information when running start16.bat.
There is a LOT of information, and it is printed very fast, so I can only see the last part:
In order to caoture the full log, I tried running vshda16 with > log.txt since that's supposed to redirect the output to the txt file, but the resulting log file is 0 bytes long.
Is there any other way specific to VSBHDA to capture the full log?
The full log isn't really interesting here - it's a pile of info from the HDA device, but that isn't the problem, since your card is properly detected. If I compare the last part of your log with the log that I posted:
b7: malloc(11f4) free=7e6c (dynend/curbrk=9194/11000
OPL3 emulation enabled at port 388h (44100 Hz).
then there's already a hint where the program stops. My guess is that it doesn't really "freeze", but enters an "infinite loop". I will check the program source how to insert some more displays to hunt down the lock...
I
Ok, I will test new builds and try to get more info from them as they are available :)
I checked the code. Between those two lines:
b7: malloc(11f4) free=7e6c (dynend/curbrk=9194/11000
OPL3 emulation enabled at port 388h (44100 Hz).
doesn't happen much. Your log shows the first line only - so the OPL3 emulation initialization causes the problem.
The one problem I can think of is a FPU exception that cannot pop up. That's not too likely, but still possible.
I attached a small tool that may help to make the process go on. Just run
cpustat -f
before running start16.bat and watch if vsbhda16.exe still hangs at the very same line.
@Baron-von-Riedesel If I run cpustat -f before start16.bat, VSBHDA does not hang anymore!
This is what cpustat -f says:
..And this is start16.bat running successfully:
However, there is no sound in games. Prince of Persia and Mystic Towers for example used to work well with SBEmu, but they don't emit sound here.
However, there is no sound in games. Prince of Persia and Mystic Towers for example used to work well with SBEmu, but they don't emit sound here.
Ok - did vsbhda16 emit a notice about what device it uses for output? You should now be able to run the "normal" vsbhda16 without debug displays - or redirect the displays to a file, which should work now. Perhaps it's as simple as using the /O1 or /O2 cmdline option...
@Baron-von-Riedesel Yes, vsbhda16 emits a notice about what device it uses for output. BUT only when I don't pass any /O value or when I pass /O0
So, with NO /O value or /O0 I get this:
With /O1 I get this:
With /O2 I get this:
In all three cases, I get no audio in games. When passing no /0 at all, /O0, or /O2, games like Lemmings, Old Towers and Prince of Persia all detect the SoundBlaster card, but they don't emit a single sound.
I tried the headphone jack too, with all of these /O options, too. All silent.
I tried the headphone jack too, with all of these /O options, too. All silent.
Try the HDAplay utility at https://github.com/Baron-von-Riedesel/HDAutils and see if that produces any sound.
There's also the hdastat utility included that displays the detailed status of the HDA. The idea is to run it once after vsbhda16 has run ( and keeps silent ) and compare that to the status when sound is NOT muted ( after running hdaplay/mpxplay/sbemu, whatever program produces hearable sound ).
@Baron-von-Riedesel This version of SBEMU works:
https://github.com/crazii/SBEMU/releases/download/1.0beta3/SBEMU.1.0beta3.zip
Current SBEMU version are silent, too.
Before running SBEMU 1.0 BETA 3:
HDA_ANT.TXT
AFTER running SBEMU 1.0 BETA 3 (when sound is working in games):
HDA_DES.TXT
That's not too helpful.
What's needed would be:
- AFTER runnung SBEMU
- AFTER running VSBHDA16.
@Baron-von-Riedesel Ok, sorry, I will try my best.
AFTER running SBEMU 1.0 BETA 3 (Games produce sound!):
HDA_DES.TXT
AFTER running VSBHDA16 (Games don't emit any sound):
DES_VSB.TXT
Ok, I found a severe problem in the mpxplay source for HDA that may mute the output amplifier. And that's at least the problem that I saw in the log files. So there's a chance that sound may work now - just download the v1.4 prerelease again ( there are now both the std and the debug variants included ).
A grain of salt: VirtualBox with Intel ICH9 chipset still doesn't work - I hoped this fix would also fix this issue, but no.
@Baron-von-Riedesel Sound works now, BUT only with the debug version!
HDASTAT without doing anything:
HDASTAT after loading release vsbhda16 (non-working audio):
VSBHDA16 debug build log (working audio!!):
HDASTAT after loading VSBHDA16 debug build (working audio!!):
The logs confirm my considerations, but still have to see why it doesn't work in the non-debug version.
FYI, here's the relevent part in the hdastat log:
"working:"
0/ 19/000B/8000 - amplifier gain/mute: 0x71 ([7] mute, [6:0] gain)
"NOT working:"
0/ 19/000B/8000 - amplifier gain/mute: 0xe2 ([7] mute, [6:0] gain)
Bit 7 of the value ( here either 0x71 or 0xe2 - it's the "volume" ) must be zero, because a '1' mutes the amplifier.
Uploaded another version, forcing the output amplifier bit 7 to zero, so it's no longer possible for the program to mute the amplifier "accidentally".
@Baron-von-Riedesel Yes! That new version works perfectly on this machine!
Many thanks for investigating this incompatibility!
Should I close this thread? I don't know if, with this, this particular issue is now considered as solved.
Should I close this thread?
No. It reminds me of the "FPU problem" and also that vsbhda still keeps silent in VBox with ICH9.
@Baron-von-Riedesel Latest version is again hanging after initialization.. Is that expected? It was fixed previously as we discussed here.
@Baron-von-Riedesel Latest version is again hanging after initialization.. Is that expected? It was fixed previously as we discussed here.
Actually, there was never a "fix" in vsbhda code - IIRC, it was just the cpustat cmdline option -f to reinit the FPU that avoided the hang. This should work as it worked a month ago.
I'm still not 100% sure what the best fix is, Currently I guess it's 3 fpu instructions:
- fsave
- fninit
- do some fpu stuff
- frestor
Since it happens only on one machine, priority is low...
@Baron-von-Riedesel Ah yes, that was it, sorry I had forgotten.