On Wednesday 16 December 2009 8:47:56 am Robert Noland wrote: > On Tue, 2009-12-15 at 15:51 -0500, John Baldwin wrote: > > On Tuesday 15 December 2009 2:47:03 pm Jonathan Chen wrote: > > > On Tue, Dec 15, 2009 at 10:18:36AM -0500, John Baldwin wrote: > > > > On Monday 14 December 2009 9:37:51 pm Jonathan Chen wrote: > > > > > On Mon, Dec 14, 2009 at 10:46:27AM -0500, John Baldwin wrote: > > > > > > On Sunday 13 December 2009 2:19:05 pm Jonathan Chen wrote: > > > > > > > Hi, > > > > > > > > > > > > > > This is a general rehash of a problem that I've been having with > > > > > > > my > > > > > > > Dell Latitude D830 with an nVidia Quadro NVS 140M internal > > > > > > > graphics > > > > > > > card. I've been using the XOrg's "vesa" driver ever since > > > > > > > something in > > > > the > > > > > > > code rendered the "nvidia" driver inoperable in 7-STABLE sometime > > > > > > > mid > > > > > > > last year. With nVidia's new 195.22 (BETA) drivers, I had hoped > > > > > > > that I > > > > > > > could bypass the problem. Unfortunately, I seem to be > > > > > > > experiencing the > > > > same > > > > > > > problem as described in the following thread: > > > > > > > > > > > > > > http://www.nvnews.net/vbulletin/showthread.php?t=142391 > > > > > > > > > > > > > > which appears to be implying that something in the kernel is > > > > > > > interfering with memory allocation. Would it be possible for > > > > > > > someone > > > > > > > with deeper kernel-fu be able to take a look at this issue? > > > > > > > > > > > > Do you have a verbose dmesg available? > > > > > > > > > > I've attached a dmesg with a verbose boot. I hope this is what you're > > > > > looking for. > > > > > > > > Ok, can you grab the output of 'devinfo -r' and 'devinfo -ur'? I > > > > suspect that > > > > when the bridge allocates the prefetch resource range from the parent > > > > it is > > > > failing somehow. For a quick hack try something like this: > > > [...] > > > > > > I've attatched the requested output. Unfortunately, the patch didn't > > > result in anything different. > > > > > > I/O memory addresses: > > > 0xdff00000-0xe06fffff (acpi0) > > > 0xe0700000-0xe0700fff (cbb0) > > > 0xe0701000-0xf3ffffff (root0) > > > > The root0 range is ok (it really means free), but the cbb0 and acpi0 ranges > > here conflict with the prefetch BAR for the video adapter. The cbb0 one I > > think is because that range is free when cbb0 needs to allocate a fresh > > range > > of resources. The real bug is why your BIOS thinks that a system resource > > is > > using 0xe0000000-0xe06fffff which conflicts with the nvidia card. You can > > try disabling ACPI's system-resource handling (set > > debug.acpi.disabled="sysres" from the loader). > > I'm not sure what is the root issue, but we have seen system resource > conflicts like this reasonably often with Nvidia graphics. I've never > some across this issue with any other display adapter. But I've had at > least a handful of reports of noveau not working due to this issue.
This is not specific to Nvidia adapters. These are just incompetent BIOS writers. We should probably trust any BARs set by the BIOS over what is listed in the ACPI system resources. This it not super easy to fix now, but I can see how to handle that as part of the multipass device resource stuff. -- John Baldwin _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
