Bug 608506 - 'pci : no compatible bridge window' error related to eth0 doesnt autoenable on reboot?
'pci : no compatible bridge window' error related to eth0 doesnt autoenable o...
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
16
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
first=2.6.33 tested=3.3 pci
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-27 17:46 EDT by collura
Modified: 2013-01-10 03:09 EST (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-11-14 10:17:01 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmesg with the bridge error in it (46.68 KB, text/plain)
2010-06-27 17:52 EDT, collura
no flags Details
lspci seems to suggest ethernet card is associated with bridge error? (13.19 KB, text/plain)
2010-06-27 17:53 EDT, collura
no flags Details
var log message with bridge error (61.58 KB, text/plain)
2010-06-27 17:54 EDT, collura
no flags Details

  None (edit)
Description collura 2010-06-27 17:46:05 EDT
Description of problem:

random error on bootup.

on bootup get error message about 'no compatible bridge window':

"pci 0000:04:00.0: no compatible bridge window for [mem 0xfffe0000-0xffffffff pref]"

if i am reading the logs right that this error is also related to the eth0 not being brought up at boot?

when the ethernet cable is connected to eth0 port at boot it doesnt automatically come up but have to click in network icon in toolbar and then click on the eth0 item of that menu in order to bring the interface up manually. 

Version-Release number of selected component (if applicable):

kernel-2.6.33.5-124.fc (x86_64)

How reproducible:
always

Steps to Reproduce:
1. boot up and message greets you along the way up
2.
3.
  
Actual results:
message is there, and ethernet doesnt come up automatically

Expected results:
message not be there, and ethernet comes up automatically

Additional info:

seems related to 

https://bugzilla.redhat.com/show_bug.cgi?id=549089

but the --print-reply workaround doesnt seem to effect the network reconnection at reboot and of course the error message is still there.
Comment 1 collura 2010-06-27 17:52:06 EDT
Created attachment 427273 [details]
dmesg with the bridge error in it

also that kernel was 2.6.33.5-124.fc13 (x86_64)
Comment 2 collura 2010-06-27 17:53:13 EDT
Created attachment 427274 [details]
lspci seems to suggest ethernet card is associated with bridge error?
Comment 3 collura 2010-06-27 17:54:03 EDT
Created attachment 427275 [details]
var log message with bridge error
Comment 4 Matthew Garrett 2010-06-28 13:03:01 EDT
Does the message disappear if you boot with

pci=use_crs

on the kernel command line? I don't think it's related to your network connection not being brought up automatically.
Comment 5 collura 2010-06-28 21:15:48 EDT
bridge error still is there when i tack on the 'pci=use_crs' at the grub entry.




for completeness and anyone that wants to know i did it like this:

-power on

-press a key to go to grub menu

-move to current boot option in boot list and press 'e' to edit that entry

-move to kernel line of that entry and press 'e' again to edit that line of entry

-puts you at end of kernel line of entry so then after a space type 'pci=use_crs' without quotes and then hit enter to go back to main entry

-press 'b' to boot with the option we just added

(note that the changes to the entry will be forgotten when reboot)
Comment 6 collura 2010-06-29 03:13:30 EDT
have to read it a few more times but found random link in archive of linux kernel mailing list that talks about this error also being present with kernel 2.6.34:

http://lkml.org/lkml/2010/2/28/146

"[    0.977506] pci 0000:04:00.0: no compatible bridge window for [mem 0xfffe0000-0xffffffff pref]"
Comment 7 Chuck Ebbert 2010-07-01 23:21:40 EDT
Possibly fixed by:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=9a928660c9dcaff568c9d379655c5aa16fb981f8

which is in 2.6.34. Can you manually install a 2.6.34 kernel from koji? Even better, can you try 2.6.34.1-rc1?

http://koji.fedoraproject.org/koji/buildinfo?buildID=181064

It should work on F-13.
Comment 8 Heiko 2010-07-05 15:20:00 EDT
I have the same problem on boot-up:
"pci 0000:01:00.0: no compatible bridge window for [mem 0xfffe0000-0xffffffff pref].

Kernel: 2.6.33.5-124.fc13.i686.PAE

As suggested, I tried kernel 2.6.34.1-46.2.7.rc1.fc14.i686.PAE, but I still get the error.

Despite of this error, I didn't have any problem with the system... so far.
Comment 9 uros 2010-08-04 07:50:16 EDT
I have some similar symptoms:
on bootup get error message about 'no compatible bridge window':

"no compatible bridge window for [mem 0xfffe0000-0xffffffff pref]"

I also get "some" messages:
DMAR:[DMA Read] Request device [44:00.0] fault addr fffff000 
DMAR:[fault reason 02] Present bit in context entry is clear
DRHD: handling fault status reg 2
DMAR:[DMA Read] Request device [44:00.0] fault addr fffff000 
DMAR:[fault reason 02] Present bit in context entry is clear
DRHD: handling fault status reg 2
DMAR:[DMA Read] Request device [44:00.0] fault addr fffff000 
DMAR:[fault reason 02] Present bit in context entry is clear
DRHD: handling fault status reg 2
...


This would not bother me if /var/log/messages would not fill up (!!over 45 GB !!) my root file system.

my system is:
uname -a
Linux xyz 2.6.33.6-147.2.4.fc13.x86_64 #1 SMP Fri Jul 23 17:14:44 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux

on HP ProBook6540b


I did not notice any other issue in two days of PC use. Have not tried all of the hw.
Comment 10 Chuck Ebbert 2010-08-06 00:53:42 EDT
(In reply to comment #9)
> I also get "some" messages:
> DMAR:[DMA Read] Request device [44:00.0] fault addr fffff000 
> DMAR:[fault reason 02] Present bit in context entry is clear
> DRHD: handling fault status reg 2
> DMAR:[DMA Read] Request device [44:00.0] fault addr fffff000 
> DMAR:[fault reason 02] Present bit in context entry is clear
> DRHD: handling fault status reg 2
> DMAR:[DMA Read] Request device [44:00.0] fault addr fffff000 
> DMAR:[fault reason 02] Present bit in context entry is clear
> DRHD: handling fault status reg 2
> ...

Those are from the Intel IOMMU driver. You can disable it with the boot option "intel_iommu=off".
Comment 11 David Woodhouse 2011-05-30 05:05:44 EDT
(In reply to comment #10)
> (In reply to comment #9)
> > DMAR:[DMA Read] Request device [44:00.0] fault addr fffff000 
> > DMAR:[fault reason 02] Present bit in context entry is clear
> > DRHD: handling fault status reg 2
> > ...
> 
> Those are from the Intel IOMMU driver. You can disable it with the boot option
> "intel_iommu=off".


The IOMMU exists for a reason. Disabling the protection as soon as it actually tells you that it's protecting you from something, is not necessarily the *best* approach. Would you do the same with the 'normal' MMU? Here's what you'd say:

   "That SEGV message when you ran a dodgy userspace program was from the
   kernel's MMU code. You can disable it by running uCLinux."

Does that seem like a sensible approach?

uros, please show the output of 'lspci'. I'd like to know what device 44:00.0 is, and if that devices has any other functions. You should probably do so in a completely separate bug, since this seems to have no relationship at all to the bug actually being discussed here. Please Cc me when you file the bug.
Comment 12 Bug Zapper 2011-06-01 11:25:17 EDT
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 13 collura 2011-11-02 16:20:52 EDT
still getting this in dmesg in fc16-gnome-rc2 with kernel-3.1.0-5.fc16 (64bit) :

[    0.622871] pci 0000:04:00.0: no compatible bridge window for [mem 0xfffe0000-0xffffffff pref]
Comment 14 Dave Jones 2012-03-22 12:44:01 EDT
[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.
Comment 15 Dave Jones 2012-03-22 12:48:31 EDT
[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.
Comment 16 Dave Jones 2012-03-22 12:57:48 EDT
[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.
Comment 17 collura 2012-04-23 15:21:07 EDT
getting same error in var log messages as in comment#13 
on fc16 and on fc17 still as of:

  kernel-3.3.2-1.fc16.x86_64
and
  kernel-3.3.1-5.fc17.x86_64
Comment 19 Bjorn Helgaas 2012-07-16 14:55:21 EDT
I don't see anything wrong with the r8169 0000:04:00.0 device from a PCI perspective.  The BIOS does leave it a BAR value that we don't like, and we move it, but as far as I can tell, it's working at the new location.

In the upstream kernel, the "no compatible bridge window" message is dev_info() because it's fairly common and the user doesn't need to do anything about it.  It was once a dev_err(), but I don't know what it is in RHEL or Fedora.

I don't know what's involved in bringing up eth0 automatically at boot-time, but I doubt the issue there is related to our having moved the BAR.
Comment 20 Dave Jones 2012-10-23 11:32:15 EDT
# Mass update to all open bugs.

Kernel 3.6.2-1.fc16 has just been pushed to updates.
This update is a significant rebase from the previous version.

Please retest with this kernel, and let us know if your problem has been fixed.

In the event that you have upgraded to a newer release and the bug you reported
is still present, please change the version field to the newest release you have
encountered the issue with.  Before doing so, please ensure you are testing the
latest kernel update in that release and attach any new and relevant information
you may have gathered.

If you are not the original bug reporter and you still experience this bug,
please file a new report, as it is possible that you may be seeing a
different problem. 
(Please don't clone this bug, a fresh bug referencing this bug in the comment is sufficient).
Comment 21 Justin M. Forbes 2012-11-14 10:17:01 EST
With no response, we are closing this bug under the assumption that it is no longer an issue. If you still experience this bug, please feel free to reopen the bug report.

Note You need to log in before you can comment on or make changes to this bug.