mem address conflict in amd64 current

[shep]

In

OpenBSD 5.2-current (GENERIC.MP) #17: Fri Jan 18 17:50:43 MST 2013
    todd@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

and the prior version I am getting warning in
dmesg:

acpicpu0 at acpi0: PSS
acpicpu1 at acpi0: PSS
acpitz0 at acpi0: critical temperature is 65 degC
acpibtn0 at acpi0: PWRB
cpu0: PowerNow! K8 2500 MHz: speeds: 2500 2400 2200 2000 1800 1000 MHz
pci0 at mainbus0 bus 0
0:0:0: mem address conflict 0xe0000000/0x20000000
pchb0 at pci0 dev 0 function 0 "ATI RX780 Host" rev 0x00

I do not see this in my other Intel Atom motherboard running amd64 current.
Is any one else getting this? Does it represent failing memory?

My pcidump -v | grep 0x200:

0x001c: BAR mem 64bit addr: 0x00000000e0000000/0x20000000

and pcidump -v | grep 0x001c

	0x001c: BAR mem 64bit addr: 0x00000000e0000000/0x20000000
	0x001c: I/O Base: d1 I/O Limit: d1 Secondary Status: 2000
	0x001c: I/O Base: e1 I/O Limit: e1 Secondary Status: 0000
	0x001c: BAR io addr: 0x0000fc00/0x0004
	0x001c: BAR empty (00000000)
	0x001c: BAR empty (00000000)
	0x001c: BAR empty (00000000)
	0x001c: BAR empty (00000000)
	0x001c: BAR empty (00000000)
	0x001c: BAR empty (00000000)
	0x001c: BAR empty (00000000)
	0x001c: BAR io addr: 0x00000000/0x0004
	0x001c: BAR empty (00000000)
	0x001c: BAR empty (00000000)
	0x001c: I/O Base: c0 I/O Limit: c0 Secondary Status: 2280
	0x001c: BAR empty (00000000)
	0x001c: BAR empty (00000000)
	0x001c: BAR empty (00000000)
	0x001c: BAR empty (00000000)
	0x001c: BAR empty (00000000)

It seems to be running fine but this is new in the dmesg.

Added: Just to be sure that I was not having a hardware issue , I booted Jggimi's live fluxbox amd64 cd and the memory conflict did not show up in the 5.0 dmesg

[jggimi]

Good day, shep. I responded to your post on misc@ about this, since you mentioned my live media but did not explain which kernel it used.

To follow up to my comments there, I believe patch 1.96 to src/sys/dev/pci.c is a likely root cause for the message. You could prove this by building a test kernel without the patch. The remaining subsequent patch, 1.97, may or may not have a conflict if 1.96 is removed. I haven't checked this.

Patch 1.96 caught my eye first because of the log message for the patch:

Add resource tracking for PCI bus numbers.  This will allow us to prevent
attaching the same PCI bus twice and in the long run this will allown us
to hot plug PCI busses and support CardBus on machines where the firmware
doesn't assign a bus number to CardBus devices.

While there, print a bit more information for memory and io conflicts.

And then looking at the code, it touches the logic which produces the message.

Whether the message is correct, in that your hardware has a memory addressing conflict in how the PCI buses interconnect ... I wouldn't know.

Here's a link to the Web interface to the OpenBSD CVS repository for pci.c. From there, you can look at the patch in unified diff form ("preferred") or even in multiple colors, showing the lines of code added, edited, or removed.

[shep]

Jggimi;

Thanks for stepping in, I am just getting my feet wet with the misc@openbsd.org mailing lists. I usually try to come here first for problems.

I spent a good 5 hours trying to update the bios on my board, which I thought I should do before going further. There were 3 options to update the bios and the easy one to use a thumb drive (F12 during POST) did not work. I then tried to put an old floppy drive which the bios did not seem to recognize - the bios upgrade utility would not find the floppy. The floppy was not recognized by OpenBSD either. I then cleared the cmos - the thumb drive flash utility still would not come up and the floppy (I tried 3 different floppy drives and 2 cables) would not be recognized by the bios. I then found the FAQ(8) to ukc the floppy if not recognized by the kernel but given that the bios could not find it I called it a day.

I also booted the 5.2 install disk and it also had the mem conflict message - I can't believe that I had missed the error all these months. With all the trouble with the bios and floppy drive recognition I'm beginning to wonder if either the memory or mobo is going south.

[jggimi]

...the 5.2 install disk and it also had the mem conflict message...

Then patch 1.96 cannot be the root cause. That's a -current patch. 5.2-release is at patch level 1.94. As is 5.1 -- there was no change to this module between 5.1 and 5.2. However, because 5.0 does not produce the message and is at 1.93, the patch that causes the message must be 1.94. Logic works.

The CVS log entry for 1.94 states:

Introduce pci_probe_device_hook(pci_chipset_tag_t, struct pci_attach_args *).
This mandatory function will get invoked in pci_probe_device(), and allows
a pci host driver to alter the pci_attach_args passed to a device when
attaching.

This function will also, if returning non-zero, cause the device to be
skipped completely during all the phases of the PCI device discovery
(i.e. ressource enumeration, ressource assignment, and actual attachment).
This particular feature is experimental and might be reverted in the future
(or the scope narrowed to device attachment only).

A dummy #define pci_probe_device_hook() 0 is added to all platforms except
sgi, where real functions (currently only returning 0) are added; real meat
will be added shortly.

The patch is very small, and adds a single probe hook at bus attachment time:

--- src/sys/dev/pci/pci.c    2011/06/12 12:13:28    1.93
+++ src/sys/dev/pci/pci.c    2011/10/10 20:42:37    1.94
@@ -1,4 +1,4 @@
-/*    $OpenBSD: pci.c,v 1.93 2011/06/12 11:13:28 kettenis Exp $    */
+/*    $OpenBSD: pci.c,v 1.94 2011/10/10 19:42:37 miod Exp $    */
 /*    $NetBSD: pci.c,v 1.31 1997/06/06 23:48:04 thorpej Exp $    */
 
 /*
@@ -461,6 +461,13 @@ pci_probe_device(struct pci_softc *sc, pcitag_t tag,
                 pa.pa_flags |= PCI_FLAGS_MSI_ENABLED;
         }
     }
+
+    /*
+     * Give the MD code a chance to alter pci_attach_args and/or
+     * skip devices.
+     */
+    if (pci_probe_device_hook(pc, &pa) != 0)
+        return (0);
 
     if (match != NULL) {
         ret = (*match)(&pa);

I'm not a device driver programmer, nor am I cluefull about PCI buses. But this 15-month old driver revision is why you get the message.

If in a few days there are no further posts in misc@ in response to your query, you might contact the developer who commited 1.94 -- Miod Vallet (miod@), and politely ask his advice. He might recommend ignoring the messages - or he might ask you to participate in further testing by applying test patches, building kernels, and testing them with your hardware. Or, he might recommend repairing/replacing your hardware.

The second possibility -- kernel testing -- is very common when users contact developers over specific hardware issues. If you've never used cvs(1) or built a kernel from source, it would be an invaluable learning experience for you, as OpenBSD is source-code maintained using cvs(1) and unified diff(1) patches.