DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD General

OpenBSD General Other questions regarding OpenBSD which do not fit in any of the categories below.

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 22nd January 2013
shep shep is offline
Real Name: Scott
Arp Constable
 
Join Date: May 2008
Location: Dry and Dusty
Posts: 1,503
Default mem address conflict in amd64 current

In
Code:
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:
Code:
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:
Code:
0x001c: BAR mem 64bit addr: 0x00000000e0000000/0x20000000
and pcidump -v | grep 0x001c
Code:
	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

Last edited by shep; 23rd January 2013 at 03:00 AM. Reason: added live cd
Reply With Quote
  #2   (View Single Post)  
Old 23rd January 2013
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

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.
Reply With Quote
  #3   (View Single Post)  
Old 24th January 2013
shep shep is offline
Real Name: Scott
Arp Constable
 
Join Date: May 2008
Location: Dry and Dusty
Posts: 1,503
Default

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.
Reply With Quote
  #4   (View Single Post)  
Old 24th January 2013
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

Quote:
...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:
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:
Code:
--- 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.

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

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Can't find packages for amd64 -current Daffy OpenBSD Packages and Ports 6 8th June 2011 02:44 PM
Does pf conflict with OpenVPN? Emile OpenBSD Packages and Ports 37 2nd February 2011 11:03 PM
Status of Current amd64 shep OpenBSD General 3 24th August 2010 02:14 PM
Current Missing some amd64 Packages shep OpenBSD Packages and Ports 3 5th March 2010 03:50 PM
FreeBSD 8.0-CURRENT (amd64 & i386) VMware Virtual Appliances Available glarkin_at_FreeBSD FreeBSD Installation and Upgrading 1 3rd December 2008 08:49 AM


All times are GMT. The time now is 02:33 PM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick