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:

Code:

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.

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.

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:

Code:

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:

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.

Last edited by jggimi; 24th January 2013 at 02:58 AM.
Reason: typo, clarity