Bug 608506

Created attachment 427273 [details]
dmesg with the bridge error in it

also that kernel was 2.6.33.5-124.fc13 (x86_64)

Created attachment 427274 [details]
lspci seems to suggest ethernet card is associated with bridge error?

Created attachment 427275 [details]
var log message with bridge error

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.

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)

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]"

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.

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.

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.

(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".

(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.

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

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]

[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.

[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.

[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.

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

http://www.smolts.org/client/show/?uuid=pub_d71dc9ab-d675-4ee2-a9a9-303efc25df83

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.

# 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).

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.