linux-kernel - Re: Linux 2.6.33-rc2

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 25 Dec 2009 22:50:32 +0100
From:	Borislav Petkov <petkovbb@...glemail.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	David Miller <davem@...emloft.net>
Subject: Re: Linux 2.6.33-rc2 - Merry Christmas ...

On Fri, Dec 25, 2009 at 09:00:17PM +0100, Borislav Petkov wrote:
> Hi,
> 
> the r8169 driver fails loading here with the following message:
> 
> [    0.353955] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
> [    0.354258] r8169 0000:02:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
> [    0.354391] r8169 0000:02:00.0: PCI INT A disabled
> [    0.354527] r8169: probe of 0000:02:00.0 failed with error -22
> 
> Machine is Acer Aspire One, Atom N270 CPU.
> 
> Actually, the breakage seems to have appeared a bit earlier, sometime
> between .32 and .33-rc1 as the bisection result shows:
> 
> ac1aa47b131416a6ff37eb1005a0a1d2541aad6c is the first bad commit
> commit ac1aa47b131416a6ff37eb1005a0a1d2541aad6c
> Author: Jesse Barnes <jbarnes@...tuousgeek.org>
> Date:   Mon Oct 26 13:20:44 2009 -0700
> 
>     PCI: determine CLS more intelligently
>     
>     Till now, CLS has been determined either by arch code or as
>     L1_CACHE_BYTES.  Only x86 and ia64 set CLS explicitly and x86 doesn't
>     always get it right.  On most configurations, the chance is that
>     firmware configures the correct value during boot.
>     
>     This patch makes pci_init() determine CLS by looking at what firmware
>     has configured.  It scans all devices and if all non-zero values
>     agree, the value is used.  If none is configured or there is a
>     disagreement, pci_dfl_cache_line_size is used.  arch can set the dfl
>     value (via PCI_CACHE_LINE_BYTES or pci_dfl_cache_line_size) or
>     override the actual one.
>     
>     ia64, x86 and sparc64 updated to set the default cls instead of the
>     actual one.
>     
>     While at it, declare pci_cache_line_size and pci_dfl_cache_line_size
>     in pci.h and drop private declarations from arch code.

Ok here's what happens: 

pci_apply_final_quirks() dumps on the console

[    0.369252] PCI: CLS 0 bytes, default 64

which means that it hasn't fallen back to setting the default cache line
size. Also, the call

pci_read_config_byte(dev, PCI_CACHE_LINE_SIZE, &tmp);

sets tmp = 0 and the following condition hits everytime

if (!cls)
         cls = tmp;
if (!tmp || cls == tmp)
         continue;

Which means that we never get around the set the default CLS.

The following dirty fix solves the issue on my machine:

--
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 7cfa7c3..9854c26 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -2629,7 +2629,10 @@ static int __init pci_apply_final_quirks(void)
 	if (!pci_cache_line_size) {
 		printk(KERN_DEBUG "PCI: CLS %u bytes, default %u\n",
 		       cls << 2, pci_dfl_cache_line_size << 2);
-		pci_cache_line_size = cls;
+		if (!cls)
+			pci_cache_line_size = pci_dfl_cache_line_size;
+		else
+			pci_cache_line_size = cls;
 	}
 
 	return 0;


-- 
Regards/Gruss,
    Boris.
--
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/