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:	Mon, 1 Dec 2008 20:36:40 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Frans Pop <elendil@...net.nl>
cc:	rjw@...k.pl, greg@...ah.com, mingo@...e.hu,
	jbarnes@...tuousgeek.org, lenb@...nel.org,
	linux-kernel@...r.kernel.org, tiwai@...e.de,
	akpm@...ux-foundation.org
Subject: Re: Regression from 2.6.26: Hibernation (possibly suspend) broken
 on Toshiba R500 (bisected)



On Tue, 2 Dec 2008, Frans Pop wrote:
> 
> Your debug patch gives me on boot (hp 2510p; x86_64; current git head):
> 
> ! pci 0000:02:06.0: BAR 9 0-3ffffff wrong alignment flags 21200 4000000 (0)
> ! pci 0000:02:06.0: BAR 9 bad alignment 0: [0x000000-0x3ffffff]

Hmm. flags 21200 means that IORESOURCE_SIZEALIGN is set, and 'align' is 
_correct_ (0x4000000==size), while 'expected_align' is total crap (0).

So at least on your machine, using the expected_align value (which is 
effectively what Rafael's patch does) would definitely be the wrong thing.

Of course, it might then happen to work (because the thing doesn't 
actually need that big alignment at all).

Also:

> From lspci -vv:
> 02:06.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ba)
>         Subsystem: Hewlett-Packard Company Device 30c9
>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
>         Latency: 168
>         Interrupt: pin A routed to IRQ 18
>         Region 0: Memory at e0100000 (32-bit, non-prefetchable) [size=4K]
>         Bus: primary=02, secondary=03, subordinate=06, sec-latency=176
>         Memory window 0: 84400000-847ff000 (prefetchable)
>         Memory window 1: 80000000-83fff000
>         I/O window 0: 00003000-000030ff
>         I/O window 1: 00003400-000034ff

the above all looks fine, and it apparently works for you.

I'd like to see what Rafael's machine does.

Of course, the thing to keep in mind here is that resource alignment is 
one of those things that changes how PCI resources get laid out, and two 
different layouts may well _both_ be correct - but then one of them may 
not work, because there is some hidden SMI resource that we don't know 
about, or some other stupid BIOS issue where the BIOS is unhappy about how 
we laid things out.

We've had many of those before. And they can easily result in "innocent" 
changes (including real fixes) just then exposing problems that were 
hidden before due to just a subtly different layout.

That's why I'd like to see what the layout differences are for Rafael with 
and without his patch (and also both before and after hibernate/resume). 
Maybe both layouts are "correct", but the non-working one can give us a 
clue about what may be triggering the problem.

			Linus
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ