On 26/09/13 23:37, Pavel Roskin wrote: > Hello! > > I have spent some time on the issue. I'm not sure it's a nouveau bug. > I have a fix that changes arch/x86/kernel/sysfb_simplefb.c only. > > GRUB actually uses graphic mode on my card. That mode is supported by > simplefb. However, the resource conflict happens regardless of whether > simplefb is enabled. It's sysfb_simplefb that causes it, a completely > different driver. > > If GRUB keeps the graphic mode, I have this entry in /proc/iomem: > > f1000000-f112bfff : BOOTFB > > It is reserved by sysfb_simplefb. Nouveau tries to map an area at > 0xf0000000-0xf1ffffff, so it includes the existing resource without > being equivalent to it. > > Nouveau correctly calls remove_conflicting_framebuffers() before trying > to map that resource. However, sysfb_simplefb is not a real > framebuffer, so it doesn't free its resources. > > iomem_map_sanity_check() doesn't check regions with IORESOURCE_BUSY > set. That's the comment from the code: > > /* > * if a resource is "BUSY", it's not a hardware resource > * but a driver mapping of such a resource; we don't want > * to warn for those; some drivers legitimately map only > * partial hardware resources. (example: vesafb) > */ > > So I added IORESOURCE_BUSY to sysfb_simplefb.c and the problem is fixed > now. Actually, it prevents nvidiafb from claiming the device: > > nvidiafb 0000:01:00.0: BAR 3: can't reserve [mem 0xf0000000-0xf1ffffff > 64bit pref] > > But maybe that's the point of sysfb_simplefb? Anyway, here's the > patch/hack, signed off in case it's correct :) > > FWIW another nvc0 user is experiencing the same/similar issue and the patch seems to resolve the problem in his case.
https://bugs.freedesktop.org/show_bug.cgi?id=69488 Thanks Pavel :) Cheers Emil _______________________________________________ Nouveau mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/nouveau
