Sam
11-02-2002, 03:28 PM
I\'ve been running GSt since it came out without problems, and always pitied the poor folks that had problems. I always assumed it was due to marginal hardware or misconfiguration or something, and I\'ve always used top quality hardware and I probably know PC hardware internals as well as anyone (I ported a Unix variant to PCs 10 years ago, done lots of driver work, etc).
Anyway, my dedicated GSt box started giving me fits last week. I needed a machine to scandisk a flaky drive before sending it out for replacement, and though I have a policy to never touch my sampler PC, it was the only one suitable for this task, so against my better judgement, I swapped out the second disk (the one with samples), tested the failing drive, and returned the machine to its old configuration. During this time, I only made 1 change to the system: I disabled com2, freeing up an IRQ, since this would allow me to reduce IRQ sharing on this box.
And this broke my reliable GSt machine! About half my coldboots failed to complete, I\'d get a Windows (win98se) alert panel:
MSG32
This program has performed an illegal operation and will be shut down (...)
MSG32 caused in invalid page fault in module KERNEL32.DLL (...)
On a warm boot, the machine was always fine, and if it booted it continued to work perfectly, just as it always had. I called Tascam support and spoke to Chris. He\'d heard of the problem but had no good tips. He suggested full removal of GSt and installing the latest version. No change. I installed a registry from 2 days before the problems began. No change. I scandisk\'d all my drives. No problems.
At first I didn\'t think about the com port. I used the Asus Cusl2 bios to force all my cards onto unique IRQ\'s, and put my sound cards on the highest IRQ\'s (ie 9 10, I don\'t wanna explain IRQ priorities here...).
By doing this, I could change the behaviour, but I never really fixed it. Specifically, I could change the crash from an alert panel late in the Windows boot to a BSOD earlier in the boot, but the crash was at the exact same location (still in KERNEL32.DLL, same code segment, same instruction pointer).
To me this really smells like a timing related problem. I wonder if there are some critical sections (in my case in KERNEL32.DLL, searching the archives another likely candidate is WSTREAM or something like that) and if these are reentered one of the invocations is smashed and goes off into space.
For now, I have unforced all my IRQ\'s (returned to IRQ sharing) and reenabled my com ports and so far it seems I\'m back to normal, though its too soon to tell for certain. I wonder if lowering the priority of MSG.exe (the GST kernel module) affects the problem, is that what the (undocumented) priority button in the sequencer section does?
If I were Tascam and couldn\'t get to the root of this, I\'d chase it down with an in-circuit-emulator (I rented one before to chase down driver problems related to a bad hardware implementation, they\'re a pain to set up but easy to use). In the archives here, at Yahoo, and at tascam, there are dozens of people who have this problem, and it\'s horrible that no one knows the root of it. The general advice seems to be \"futz with everything on your system and pray for the best\" and near as I can tell, the success rate for this has been low.
Any more ideas?
cheers,
-sam
Anyway, my dedicated GSt box started giving me fits last week. I needed a machine to scandisk a flaky drive before sending it out for replacement, and though I have a policy to never touch my sampler PC, it was the only one suitable for this task, so against my better judgement, I swapped out the second disk (the one with samples), tested the failing drive, and returned the machine to its old configuration. During this time, I only made 1 change to the system: I disabled com2, freeing up an IRQ, since this would allow me to reduce IRQ sharing on this box.
And this broke my reliable GSt machine! About half my coldboots failed to complete, I\'d get a Windows (win98se) alert panel:
MSG32
This program has performed an illegal operation and will be shut down (...)
MSG32 caused in invalid page fault in module KERNEL32.DLL (...)
On a warm boot, the machine was always fine, and if it booted it continued to work perfectly, just as it always had. I called Tascam support and spoke to Chris. He\'d heard of the problem but had no good tips. He suggested full removal of GSt and installing the latest version. No change. I installed a registry from 2 days before the problems began. No change. I scandisk\'d all my drives. No problems.
At first I didn\'t think about the com port. I used the Asus Cusl2 bios to force all my cards onto unique IRQ\'s, and put my sound cards on the highest IRQ\'s (ie 9 10, I don\'t wanna explain IRQ priorities here...).
By doing this, I could change the behaviour, but I never really fixed it. Specifically, I could change the crash from an alert panel late in the Windows boot to a BSOD earlier in the boot, but the crash was at the exact same location (still in KERNEL32.DLL, same code segment, same instruction pointer).
To me this really smells like a timing related problem. I wonder if there are some critical sections (in my case in KERNEL32.DLL, searching the archives another likely candidate is WSTREAM or something like that) and if these are reentered one of the invocations is smashed and goes off into space.
For now, I have unforced all my IRQ\'s (returned to IRQ sharing) and reenabled my com ports and so far it seems I\'m back to normal, though its too soon to tell for certain. I wonder if lowering the priority of MSG.exe (the GST kernel module) affects the problem, is that what the (undocumented) priority button in the sequencer section does?
If I were Tascam and couldn\'t get to the root of this, I\'d chase it down with an in-circuit-emulator (I rented one before to chase down driver problems related to a bad hardware implementation, they\'re a pain to set up but easy to use). In the archives here, at Yahoo, and at tascam, there are dozens of people who have this problem, and it\'s horrible that no one knows the root of it. The general advice seems to be \"futz with everything on your system and pray for the best\" and near as I can tell, the success rate for this has been low.
Any more ideas?
cheers,
-sam