8178, go440, toshiba 5105-s501, acpi "no-legacy"

[Dr. Tyrell]

8178 fixed nothing for me.
1. Maxclock still limited to 108Mhz, which is wrong.
2. Display gets "fried" when lid switch used (kde 3.5), but ctrl-alt-f1 then ctrl-alt-f7 brings it back.
3. Must use nvreg_mobile=1, which is technically wrong

nv bug report attached

[Dr. Tyrell]

Just hoping everyone has a great holiday season!

[120]

same problems here (well ... no wonder, my laptop being a toshiba 5100-503 so same series). The workaround for getting 1600x1200 doesn't work anymore BUT it's possible to obtain 1600x1200 at 43 Hz (which sounds a bit weird to me I've to say).
For the lid switch problem, it didn't happen with 7xxx driver series (and isn't related to kde since I don't use it). I didn't try if it was also happening with xorg 6.8 (using v7.0 here).
Attaching a bug report in case it may be useful.

[Dr. Tyrell]

Thanks 120 for the input.
We need more people to relate their dotclock stories, that and the lid switch are probably the only things that need repair.

Hopefully our fearless nvidia gurus are working on these as we speak.

[sk0rpi0]

Toshiba 5100, 8178 nvidia, toshiba_acpi experimental 4.

My screen freezes after launching kde, needs physical shutdown of system, doesn't happen with 7xxx series drivers.

Any ideas?

[netllama]

sk0rpi0,
Please post a bug report that captures the freeze.

Thanks,
Lonni

[Dr. Tyrell]

Lonni, just wondering, any progress on dotclock detection?

[netllama]

I'm afraid not. I don't have your laptop here, and am not able to reproduce this on any other system.

Sorry,
Lonni

[Dr. Tyrell]

Would it help if i sent a copy of my windoze registry?
Perhaps if you can dig into that and find where the Toshiba's store things....etc.
It's a shame that Toshiba has this "legacy free" bios, but there IS a bios in these machines, and I'm not the only one with this problem.

If the Nvidia windoze drivers can detect things, and previous Linux drivers detected things (mostly), then surely there's some simple mistake in the 8xxx code, or at least a way to correctly detect the dot clock....heck, even nvclock detects it correctly !!!!

Being forced to set nvreg_mobile to dell is completely out of the blue, and probably is the factor that leads to the bad dotclock reading.

I'm willing to do what's needed to resolve this problem.

The Doctor

[netllama]

I'm afraid the Windows registry is not going to assist in debugging this, as we'd still need a means of reproducing it in order to ensure that the bug was fixed, and that assumes that the windows registry showed a clear problem.

The only way to ensure that this issue can be debugged further is to obtain such a system so that the problem can be reproduced and debugged.

Thanks,
Lonni

[Imperito]

Well, we can reproduce it readily enough, is there any debugging we can do in software that would help? I'd be willing to give it a shot if there is anything you are able to use.

That or if you guys are in orlando I could drop by

[macemoneta]

We are certainly willing to run debug driver code (or traces) to identify the problem, if Nvidia makes the code/information available. Alternatively, you can still buy these machines on E-Bay (at least the 5105-s607).