linux-kernel - Re: Geode-GX1 processor in 2.6.21

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, 30 Apr 2007 14:20:22 +0200
From:	Andreas Mohr <andi@...x01.fht-esslingen.de>
To:	Juergen Beisert <juergen127@...uzholzen.de>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Geode-GX1 processor in 2.6.21

Hi,

On Mon, Apr 30, 2007 at 12:51:05PM +0200, Juergen Beisert wrote:
> Hi all,
> 
> I do not understand it, but setting up some chipset features (tweaks) fail on 
> Geode GX1.
> 
> In arch/i386/kernel/cpu/cyrix.c function geode_configure() tries to enable 
> the "suspend on halt power saving feature". This is the line:
> 
> 	setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
> 
> If this register is 0x00 before, it is still 0x00 after this line. If I change 
> the line into this:
> 
> 	ccr2 = getCx86(CX86_CCR2);
> 	ccr2 |= 0x88;
> 	setCx86(CX86_CCR2, ccr2);
> 
> register ccr2 is 0x88 after the setCx86 call and the power saving feature is 
> active (and BTW: the TSC is useless then, because it also stops when the CPU 
> runs into a HLT instruction).
> 
> setCx86 and getCx86 are macros defined in include/asm-i386/processor.h:
> 
> #define getCx86(reg) ({ outb((reg), 0x22); inb(0x23); })
> 
> #define setCx86(reg, data) do { \
>          outb((reg), 0x22); \
>          outb((data), 0x23); \
> } while (0)
> 
> Maybe the compiler does the wrong thing if someone uses these macros in the 
> same instruction?

Sounds quite likely.
You should check objdump -d output of cyrix.o to verify whether the compiler
"illegally" reorders some I/O instructions in geode_configure().
Probably you need to add a barrier() or wmb() or similar to these macros.
Or should this be a (code-invisible) PCI posting issue? In that case you need
to add some dummy read operations.

Also, it would probably be good to convert these macros into inline functions
in this header.

Andreas Mohr
-
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/