| Summary: | NVAF (320M) crash on modprobe | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Brian Tarricone <brian> | ||||||||
| Component: | Driver/nouveau | Assignee: | Ben Skeggs <skeggsb> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||||||
| Severity: | normal | ||||||||||
| Priority: | medium | ||||||||||
| Version: | git | ||||||||||
| Hardware: | x86-64 (AMD64) | ||||||||||
| OS: | Linux (All) | ||||||||||
| Whiteboard: | |||||||||||
| i915 platform: | i915 features: | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Brian Tarricone
2011-07-18 23:26:20 UTC
Hmm, I'm not sure this is correct. It's likely I just haven't handled the lack of mpll. I'll check this in the morning! Thanks for the report :) Hi Ben
How would you feel about the idea of a static table in *_pm.h that lists the PLLs that should be ignored
"ignored" can be defined as
* do not read/set the pll and report 0 for it
* do not read/set the pll and report that there is no such pll
* or any other combination
I'm talking about cards lacking different plls
* IGPs - mpll
* some nv50 generation lacking core_unk[4,8]
* possibly the nva3+/nvc0+ have such examples?
Eg.
...
#define IGNORE_MPLL 0x0001
#define DOES_NOT_EXIST_CORE_UNK8PLL 0x0002
#define IGNORE_VDEC_PLL 0x0004
....
struct pll_ignore_list {
uint chipset;
uint caps;
}
struct pll_ignore_list ilist[] = { .....
0xaf, 0x0001 // ignore the MPLL for nvaf
........... }
Created attachment 49323 [details] [review] possible fix Can you give this patch a try please? Could I also see dmesg output from this, even if it works? (In reply to comment #2) > Hi Ben > > How would you feel about the idea of a static table in *_pm.h that lists the > PLLs that should be ignored I think this is very overkill. We're going to end up with arch-specific clock code, I think it's sufficient enough that each arch knows how to deal with the chipsets in their own family. If this patch doesn't have the same effect, I'll just "if (chipset != 0xaf)" around the mclk code for example. Created attachment 49329 [details] [review] dmesg with ben's patch (In reply to comment #3) > Created an attachment (id=49323) [details] > possible fix > > Can you give this patch a try please? Could I also see dmesg output from this, > even if it works? Yup, works great. Thanks Ben! dmesg output attached. Tried to cut out the unrelated noise, but if you want the full thing, let me know. Hmm, are you absolutely certain you removed your patch too? The clocks read back are, well, *very* wrong.. Yes, definitely removed my patch. Double-checked nouveau_state.c and it looks reverted to me... (In reply to comment #7) > Yes, definitely removed my patch. Double-checked nouveau_state.c and it looks > reverted to me... Yeah, it turns out NVIDIA decided to make NVAF slightly different in a few more random little ways too. I've committed some patches to nouveau/linux-2.6 git that should improve things. Ok, updated. This look better? [ 3.957056] [drm] nouveau 0000:02:00.0: 0: core 405MHz shader 405MHz memory 405MHz voltage 900mV [ 3.957062] [drm] nouveau 0000:02:00.0: 1: core 450MHz shader 810MHz memory 450MHz voltage 900mV [ 3.957067] [drm] nouveau 0000:02:00.0: 2: core 450MHz shader 810MHz memory 450MHz voltage 900mV [ 3.957072] [drm] nouveau 0000:02:00.0: 3: core 450MHz shader 950MHz memory 450MHz voltage 900mV [ 3.957090] [drm] nouveau 0000:02:00.0: c: core 405MHz shader 810MHz Much better! Thank you :) |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.