- May 4, 2001
- 15,381
- 6
- 91
Some background info:
- my lab has 3 opensuse workstations, Aw, Bw and Cw.
- Aw and Bw run opensuse 10.3 where Cw runs 10.2.
- Aw and Bw were purchased at the same time, Cw was purchased some time later...I dunno why it was loaded with 10.2, this was all setup before I got here.
- All workstations are identical in terms of hardware, including monitors: Pogo Linux D50 workstations:
* dual quad-core xeons (e5440 I think), 8gb ram, evga nvidia 8800gts, CTL 220UW monitor, Super X7DWA-N mobo
Last week sometime my co-worker installed updates for his workstation...I'm not positive what kind, though I suspect a kernel update was involved, since I had to recompile the network drivers. However, his monitor would simply fall in to sleep mode when entering X.
After much troubleshooting and running config programs (installing and/or compiling various nvidia driver versions, running sax2, running nvidia-xconfig, manually manipulating xorg.conf, etc...) we figured, "lets try it with another monitor". So we swap out his monitor (Bm) with mine (Cm). Voila, sax2 runs/detects/configs fine and the nvidia drivers run perfectly. We switch back and rerun sax2, his monitor sleeps...strange. So we switch again, run sax2, reboot, and get into X, then switch monitors back again in the live X environment. It works. Bm will even sleep and wake correctly......so long as we never exit the X environment, end the session or reboot....well that's just not ideal.
Then we try switching Bm with the other workstation's monitor (Am), and running sax2 all over again for testing purposes...trying to solidify the idea that Bm is fubar and needs to be RMAed. Am doesn't work either! It acts exactly like Bm. In fact, when we bring Am back to Aw...it will no longer work on that workstation after a reboot or leaving X, sax2, the whole shebang...identical problems to Bw/Bm.....WTF!?!? Aw had absolutely no updates or changes applied to that system.
So we bring back Cm, which continues to work fine...for both Aw and Bw, and never fails for me on Cw when I bring it back. Still though, it's not ideal to have to use Cm to "initialize" Aw and Bw for the X environment. We learn that Bm will work using the vga input and a DVI-->VGA adapter on Bw. Aw/Am are no-go using such a method though, I continue having to "initialize" X for that workstation using Cm.
So....are both Am and Bm fubar? Why in the world would Cm be impervious to any such problems? Pogo confirmed that Am and Bm are NOT from the same batch/lot#...so what are the chances of receiving two bad monitors, that exhibit that same symptoms, from different batches? What in the hell about hooking up Am to Bw would have fubared Am such that it would no longer work on its original, unmodified workstation?
I'm totally at a loss at this point...it seems to me that Am and Bm need to be RMAed, but I wanted to get AT input anyway.
Cliffs:
-sorry for the long post, cliffs won't really work here though.
- my lab has 3 opensuse workstations, Aw, Bw and Cw.
- Aw and Bw run opensuse 10.3 where Cw runs 10.2.
- Aw and Bw were purchased at the same time, Cw was purchased some time later...I dunno why it was loaded with 10.2, this was all setup before I got here.
- All workstations are identical in terms of hardware, including monitors: Pogo Linux D50 workstations:
* dual quad-core xeons (e5440 I think), 8gb ram, evga nvidia 8800gts, CTL 220UW monitor, Super X7DWA-N mobo
Last week sometime my co-worker installed updates for his workstation...I'm not positive what kind, though I suspect a kernel update was involved, since I had to recompile the network drivers. However, his monitor would simply fall in to sleep mode when entering X.
After much troubleshooting and running config programs (installing and/or compiling various nvidia driver versions, running sax2, running nvidia-xconfig, manually manipulating xorg.conf, etc...) we figured, "lets try it with another monitor". So we swap out his monitor (Bm) with mine (Cm). Voila, sax2 runs/detects/configs fine and the nvidia drivers run perfectly. We switch back and rerun sax2, his monitor sleeps...strange. So we switch again, run sax2, reboot, and get into X, then switch monitors back again in the live X environment. It works. Bm will even sleep and wake correctly......so long as we never exit the X environment, end the session or reboot....well that's just not ideal.
Then we try switching Bm with the other workstation's monitor (Am), and running sax2 all over again for testing purposes...trying to solidify the idea that Bm is fubar and needs to be RMAed. Am doesn't work either! It acts exactly like Bm. In fact, when we bring Am back to Aw...it will no longer work on that workstation after a reboot or leaving X, sax2, the whole shebang...identical problems to Bw/Bm.....WTF!?!? Aw had absolutely no updates or changes applied to that system.
So we bring back Cm, which continues to work fine...for both Aw and Bw, and never fails for me on Cw when I bring it back. Still though, it's not ideal to have to use Cm to "initialize" Aw and Bw for the X environment. We learn that Bm will work using the vga input and a DVI-->VGA adapter on Bw. Aw/Am are no-go using such a method though, I continue having to "initialize" X for that workstation using Cm.
So....are both Am and Bm fubar? Why in the world would Cm be impervious to any such problems? Pogo confirmed that Am and Bm are NOT from the same batch/lot#...so what are the chances of receiving two bad monitors, that exhibit that same symptoms, from different batches? What in the hell about hooking up Am to Bw would have fubared Am such that it would no longer work on its original, unmodified workstation?
I'm totally at a loss at this point...it seems to me that Am and Bm need to be RMAed, but I wanted to get AT input anyway.
Cliffs:
-sorry for the long post, cliffs won't really work here though.