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, 21 Sep 2007 14:52:44 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@...ux-mips.org>
To:	Peter Fordham <peter.fordham@...il.com>
cc:	linux-kernel@...r.kernel.org
Subject: Re: fpu IO port reservation (arch/i386)

Hi Peter,

> Does anybody know why we reserve this range of IO ports for 'fpu'?
> AFAIK from all the IO maps I can find on the internet for various x86
> chipsets only 0x00f0 is actaully ever used.

 There are two ports used: 0xf0 is the busy latch reset and 0xf1 is the 
coprocessor reset.  They are legacy ports resulting from the interesting 
way the FPU has been wired by IBM in their PC design.  None of them is 
used by Linux for i486 and newer systems, which can support the FPU in its 
native configuration.

> ./arch/i386/kernel/setup.c
> 282 }, {
> 283         .name   = "fpu",
> 284         .start  = 0x00f0,
> 285         .end    = 0x00ff,
> 286         .flags  = IORESOURCE_BUSY | IORESOURCE_IO
> 287 } };

 The reason is most likely the definition of the address decoder for the 
chip-select for this range in the IBM PC -- like with all motherboard port 
I/O peripherals the smallest size of the chunk the decoder resolved to was 
16 bytes, with unused locations aliasing to defined ones.

> The reason I ask is that I've written a watchdog driver for a Nexcom
> MAX6600 server blade type device which has the watchdog control
> register at 0xF2. Currently request_region fails due to the fpu
> reservation.

 Reservations for some of the legacy ranges have been shrunk in the past; 
perhaps this one could too.  I hope you have a way to make sure not to 
interact badly with the FPU possibly being decoded there on other systems 
-- the original registers are write-only.

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