| Summary: | Card detected as NV20 (endian issue?) With nv driver run first, fifo lockup on nv11ppc machine | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | Henrik Sørensen <henrik.sorensen> | ||||||||||||
| Component: | Driver/nouveau | Assignee: | Nouveau Project <nouveau> | ||||||||||||
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||||||||||
| Severity: | normal | ||||||||||||||
| Priority: | medium | ||||||||||||||
| Version: | unspecified | ||||||||||||||
| Hardware: | Other | ||||||||||||||
| OS: | All | ||||||||||||||
| Whiteboard: | |||||||||||||||
| i915 platform: | i915 features: | ||||||||||||||
| Attachments: |
|
||||||||||||||
Created attachment 14163 [details]
Kernel log
Created attachment 14309 [details]
X log
Either because of code changes or due to the system firmware being upgraded to 4.2.8, the card is now detected as a nv11. However it does not get far without crashing with a fifo lockup, the x checkboard partern and x cursor is shown for only a second. Created attachment 14310 [details]
kernel log
Sigh.. I was way to quick. The card had been initialised by the nv driver before I started X with the nouveau driver. If the machine is booted without nv having run, it is back to the old behaviour. (NV20 detected and 0 MiB of ram). Created attachment 17630 [details] [review] correctly set endian access in nouveau_state.c The first issue (card being in the wrong mode) is probably a bug in the drm. Both nv and nvidiafb set up BE access by writing 0x01000001 to NV03_PMC_BOOT_1 (instead of 0x00000001 as done by drm). This also explains why it worked after running nv (nv set up the card correctly). Patch is attached. The second problem is probably something else. It may have been fixed in the meantime, so pls test. Actually, the drm used to write 0x01000001 but this was changed by marcheu in commit 30353c8efcc026ee8940f3eadab084c42a3acd4e. I do not know the reason of this change. d. The code in current DRM still is: #ifdef __BIG_ENDIAN /* Put the card in BE mode if it's not */ if (nv_rd32(dev, NV03_PMC_BOOT_1)) nv_wr32(dev, NV03_PMC_BOOT_1, 0x00000001); DRM_MEMORYBARRIER(); #endif Does the patch change anything? How does Nouveau currently work with and without the patch? The patch may not apply as is, but you can easily do the equivalent change by hand in drivers/gpu/drm/nouveau/nouveau_state.c in the nouveau/linux-2.6 kernel tree, near line 540. Reports in IRC suggest that the issue still exists. It might be a good idea to ask the committer of 30353c8efcc026ee8940f3eadab084c42a3acd4e what was the reasoning behind the change. (In reply to comment #8) > Reports in IRC suggest that the issue still exists. > > It might be a good idea to ask the committer of > 30353c8efcc026ee8940f3eadab084c42a3acd4e what was the reasoning behind the > change. > That change was motivated by the fact that it fixed at least one system. If you (PPC guys) can come up with a patch that pleases everyone with a PPC, I think we're more than happy to merge it... Changes almost identical to the proposed patch are part of upstream for a while now. Can you try the latest nouvea-git or linux-3.1 Both of which include the commit "drm/nouveau: fix big-endian switch" Thanks |
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.
Created attachment 14162 [details] Xorg log The system is a gigabit g4 powermac with a PC AGP NV11 (10de:0110) flashed with a mac ROM. While the drm module seems to identify it as a NV11, the nouveau ddx driver does not. [drm] Detected an NV11 generation card (0x011000b2) vs (--) NOUVEAU(0): Chipset: "NVIDIA NV20" There's also a message in further down in the log that seems to suggest endian issues. (EE) NOUVEAU(0): Card is in big endian mode, something is very wrong !