lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 15 Mar 2010 08:42:48 -0700
From:	Bjorn Helgaas <bjorn.helgaas@...com>
To:	Giampaolo Bellini <iw2lsi@...il.com>
Cc:	Linux PCI <linux-pci@...r.kernel.org>,
	linux-kernel@...r.kernel.org, "Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: PCI conflicts with latest kernels

[I re-added the CC: list, so the archives will have the whole
conversation, in case anybody else has similar problems or
can help answer this.]

On Sunday 14 March 2010 05:11:55 pm Giampaolo Bellini wrote:
> I apply the patch but seems that it does not solve conflicts

Yes, I didn't expect it to fix anything, only to tell us more about
what's happening.

But from your dmesg, I think the problem is that the e820 map reserves
0xe0000-0x100000, and then PCI device 0b.0 has a BAR programmed to part
of that same region:

   BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
  pci 0000:00:0b.0: reg 10: [mem 0x000e0000-0x000e0fff]
  pci 0000:00:0b.0: address space collision: [mem 0x000e0000-0x000e0fff] already in use

I don't know enough about the e820 map to know whether this is a bug in
the e820 map or a problem in the PCI BAR programming, or what.

> as far I understand, the problem was there also with 2.6.29 but was not
> logged the same way and/or with the same debug-level due to changes made in
> *drivers/pci/setup-res.c* (expecially in pci_claim_resource()))

Yes.  In 2.6.29, pcibios_allocate_resources() used request_resource()
directly and logged errors with dev_info().  In 2.6.34-rc1, we use
pci_claim_resource(), which calls request_resource() and logs errors
with dev_err(), so we now have a higher priority message than we used
to have.

> machine, however, seems stable... for me the problem is that I'm trying to
> avoid text-messages during boot stage and printk(KERN_ERR "message") cause
> the system to switch in text mode & show such errors...

If you only want to hide the message, you can use "loglevel=2".

> as you can see, I've try also with pci=use_crs

Since you don't have ACPI, pci=use_crs and pci=nocrs are not relevant
for your system.

Bjorn

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists