From owner-freebsd-i386@FreeBSD.ORG Sun Apr 5 00:00:09 2009 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC70C1065677 for ; Sun, 5 Apr 2009 00:00:09 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 842608FC12 for ; Sun, 5 Apr 2009 00:00:09 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n35009in029793 for ; Sun, 5 Apr 2009 00:00:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n350091e029791; Sun, 5 Apr 2009 00:00:09 GMT (envelope-from gnats) Resent-Date: Sun, 5 Apr 2009 00:00:09 GMT Resent-Message-Id: <200904050000.n350091e029791@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-i386@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Pierre-Luc Drouin Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66690106564A for ; Sat, 4 Apr 2009 23:57:52 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id 39EFC8FC0A for ; Sat, 4 Apr 2009 23:57:52 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.3/8.14.3) with ESMTP id n34NvpR3033779 for ; Sat, 4 Apr 2009 23:57:51 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.3/8.14.3/Submit) id n34NvpDG033778; Sat, 4 Apr 2009 23:57:51 GMT (envelope-from nobody) Message-Id: <200904042357.n34NvpDG033778@www.freebsd.org> Date: Sat, 4 Apr 2009 23:57:51 GMT From: Pierre-Luc Drouin To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: i386/133388: est causes wrong dev.cpu.0.freq_levels values X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2009 00:00:11 -0000 >Number: 133388 >Category: i386 >Synopsis: est causes wrong dev.cpu.0.freq_levels values >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-i386 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Apr 05 00:00:09 UTC 2009 >Closed-Date: >Last-Modified: >Originator: Pierre-Luc Drouin >Release: Problem since 7.1-release has been installed >Organization: >Environment: >Description: FreeBSD stable >=7.1 gets the wrong CPU levels for my Pentium M 2.0 GHz when est is enabled. The maximum level is 1500 instead of 2000. Output from sysctl: dev.cpu.0.freq: 1500 dev.cpu.0.freq_levels: 1500/-1 1312/-1 1200/-1 1050/-1 1000/-1 875/-1 800/-1 700/-1 600/-1 525/-1 450/-1 375/-1 300/-1 225/-1 150/-1 75/-1 dev.est.0.%desc: Enhanced SpeedStep Frequency Control dev.est.0.freq_settings: 1500/-1 1200/-1 1000/-1 800/-1 600/-1 Output when est is disabled via hint.est.0.disabled="1" in device.hints: dev.cpu.0.freq: 1745 dev.cpu.0.freq_levels: 1995/-1 1745/-1 1496/-1 1246/-1 997/-1 748/-1 498/-1 249/-1 dev.p4tcc.0.%desc: CPU Frequency Thermal Control dev.p4tcc.0.freq_settings: 10000/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 Output from dmesg: Mar 30 15:08:03 mdaemon kernel: CPU: Intel(R) Pentium(R) M processor 2.00GHz (1995.14-MHz 686-class CPU) Mar 30 15:08:03 mdaemon kernel: Origin = "GenuineIntel" Id = 0x6d8 Stepping = 8 Mar 30 15:08:03 mdaemon kernel: Features=0xafe9fbff Mar 30 15:08:03 mdaemon kernel: Features2=0x180 Mar 30 15:08:03 mdaemon kernel: AMD Features=0x100000 Mar 30 15:08:03 mdaemon kernel: real memory = 1073577984 (1023 MB) Mar 30 15:08:03 mdaemon kernel: avail memory = 1032699904 (984 MB) Mar 30 15:08:03 mdaemon kernel: ACPI APIC Table: Output from devinfo: cpu0 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU0 ACPI I/O ports: 0x1014 0x1015 0x1016 est0 p4tcc0 acpi_perf0 acpi_throttle0 cpufreq0 >How-To-Repeat: It has been reported on the acpi mailing list that this problem was also affecting Dual-Core Pentium 1.8GHz processors >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-i386@FreeBSD.ORG Mon Apr 6 06:24:52 2009 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F5BD106566C; Mon, 6 Apr 2009 06:24:52 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 452998FC12; Mon, 6 Apr 2009 06:24:52 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n366OqIN045367; Mon, 6 Apr 2009 06:24:52 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n366Oq76045363; Mon, 6 Apr 2009 06:24:52 GMT (envelope-from linimon) Date: Mon, 6 Apr 2009 06:24:52 GMT Message-Id: <200904060624.n366Oq76045363@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/133218: [carp] [hang] use of carp(4) causes system to freeze X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 06:24:52 -0000 Synopsis: [carp] [hang] use of carp(4) causes system to freeze Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Apr 6 06:24:37 UTC 2009 Responsible-Changed-Why: This does not sound i386-specific. http://www.freebsd.org/cgi/query-pr.cgi?pr=133218 From owner-freebsd-i386@FreeBSD.ORG Mon Apr 6 11:06:55 2009 Return-Path: Delivered-To: freebsd-i386@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37C6210656F4 for ; Mon, 6 Apr 2009 11:06:55 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 24CA38FC1B for ; Mon, 6 Apr 2009 11:06:55 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n36B6t0k061881 for ; Mon, 6 Apr 2009 11:06:55 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n36B6srF061877 for freebsd-i386@FreeBSD.org; Mon, 6 Apr 2009 11:06:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 6 Apr 2009 11:06:54 GMT Message-Id: <200904061106.n36B6srF061877@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-i386@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-i386@FreeBSD.org X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 11:06:55 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o i386/133388 i386 est causes wrong dev.cpu.0.freq_levels values o i386/133328 i386 Kernel panics with Windows7 client o i386/133265 i386 is there a solution how to run nfs client in jail envi o i386/133253 i386 [boot] Error mounting install image o i386/133204 i386 'msk' driver problem o i386/132416 i386 Popup motherboard bios setup window when rebooting sys o i386/132230 i386 [boot] 7.1-RELEASE /boot/loader non-functional on Asus o i386/132110 i386 [build] /libexec/ld-elf.so.1: /lib/libc.so.7: version o i386/131426 i386 hald makes cdrom fail o i386/130110 i386 [boot] BTX-Halted - booting with SAS/SATA Controller o i386/129550 i386 [pae] [kqueue] crash with PAE kernel o i386/128014 i386 [geode] [patch] AMD Geode CS5536 watchdog(9) not disab o i386/127981 i386 [loader] Stack underflow preventing boot [regression] o i386/127374 i386 Suspend/Resume with Keystroke only once on Thinkpad T4 o i386/127367 i386 [vesa] [patch] Improve VESA support for Parallels (pat o i386/127343 i386 [hang] System locks -- simular to PR 123729 o i386/127337 i386 [boot] FreeBSD 7.1/i386 BTX boot problem on Pavilion d o i386/126666 i386 [boot] boot failure for nForce 630i / GeForce 7100 mai o i386/126162 i386 [acpi] ACPI autoload failed : loading required module f i386/125880 i386 [cardbus] Cardbus cards Don't function on TI PCIxx12 C o i386/125592 i386 [hang] FreeBSD 7 server in hang o i386/125383 i386 [amdtemp] [request] please enable amdtemp on i386 o i386/125011 i386 precision of constants for long double o i386/124902 i386 [i386] [patch] patch to fix VESA modes and allow 8bit o i386/124633 i386 [boot] [panic] 7.0 does not boot from CD o i386/124317 i386 [boot] CD with BTX 1.02 fails at "mountroot" and 1.01 o i386/124124 i386 [boot] Page fault while booting livefs iso of FreeBSD o i386/123990 i386 [boot] BTX halted on Thinkpad x60s o i386/123981 i386 [pxeboot] You can't usefully PXEBOOT the 7.0-RELEASE-i o i386/123814 i386 [boot] cannot boot freebsd kernel on sony vaio VGN-NR2 o i386/123462 i386 clock is too fast a i386/122887 i386 [panic] [atkbdc] 7.0-RELEASE on IBM HS20 panics immed f i386/122644 i386 [panic] on-boot mount /tmp kernel dump o i386/122623 i386 [build] [patch] bsd.cpu.mk doesn't handle opteron/athl o i386/122602 i386 [build] i386/conf/PAE does not compile on RELENG_7 o i386/122148 i386 [irq] interrupt storm on 7.0 [regression] o i386/121903 i386 [ips] [boot] can't boot on IBM x235 ServeRaid 6M [regr o i386/121699 i386 [boot] can't boot on MSI K9N Ultra o i386/121675 i386 [ata] incorrect fallback to udma33 with CF memory inst o i386/121549 i386 [nfe]: nfe interface locks up during rc.conf initializ o i386/121258 i386 [boot] FreeBSD 6.3 / 7.0 boot problem [regression] o i386/120933 i386 [boot] 6.x and 7.x do not boot from CD on IBM HS20 883 o i386/119946 i386 [est] sysctl dev.cpu.0.freq on 75 Hz, cannot be change o i386/119574 i386 [i386] 7.0-RC1 times out in calibrate_clocks() [regres o i386/119175 i386 [busdma] [patch] Typo in bus_dmamem_alloc() o i386/118656 i386 [panic] Init dies in single user mode and box get kern o i386/118350 i386 [boot] [hang] BTX loader hangs on PC Engines WRAP o i386/118285 i386 [i386] Segmentation fault in reloc_non_plt. o i386/117297 i386 [hang] System hangs up every day o i386/116844 i386 [boot] cannot boot from cd when using Dell Vostro 200 o i386/116100 i386 [panic] Fatal trap 12 right after reboot (da0s1error = o i386/115947 i386 [hang] Dell poweredge 860 hangs when stressed and ACPI o i386/115854 i386 [boot] [install] Install FreeBSD with USB CDROM causes o i386/115285 i386 [panic] fatal trap 1 on freebsd 6.2 install boot up on f i386/114535 i386 Toshiba Satellite 105A: "no driver attached" for vario o i386/114208 i386 [boot] Problem booting the FreeBSD CD ISO image o i386/114192 i386 Fail to boot with "error issuing ATA_IDENTIFY command" o i386/113110 i386 [mk] [patch] i686 is not an alias of pentiumpro on GCC o i386/112700 i386 SMP Kernel with FreeBSD 6.2 release on compaq dl360 g1 o i386/112635 i386 [hang] [loader] Hang during boot installation o i386/112580 i386 [boot] BTX Halted on HP DV6255 Notebook o i386/112487 i386 [sio] kernel panic on swi0:sio o i386/112036 i386 [ata] TIMEOUT - WRITE_DMA retrying, TIMEOUT - READ_DMA o i386/110218 i386 kmem_malloc(4096): kmem_map too small: 335544320 total o i386/110214 i386 [hang] FreeBSD 6.2 freezes on SSH activitiy caused by o i386/109610 i386 [panic] Fatal trap 12: page fault while in kernel mode o i386/109568 i386 [panic] Reboot server with "Fatal trap 12" o i386/109423 i386 [ichsmb] ICH5 smb interface problems s i386/109200 i386 [ata] READ_UDMA UDMA ICRC error cause not detecting ca o i386/108185 i386 [panic] freebsd 6.2 fatal kernel trap o i386/107564 i386 [install] fatal trap 19 during installation on a Dell o i386/107382 i386 [install] "Fatal trap 12" when installing FreeBSD 6.1 o i386/106850 i386 [powerd] powernow0 attach returned 6 o i386/106789 i386 [nfe] or [nve]: Internal NIC of GA-K8N51GMF-RH does no o i386/105175 i386 [ipmi] ipmi acpi trouble on supermicro server o i386/105063 i386 [sio] US Robotics (3Com) 3CP5609 PCI 16550 Modem works o i386/104719 i386 [ata] Seagate ST3802110A errors/delays when using PIO4 f i386/104572 i386 [ata] issues with detecting HDD on Intel Q965 Express o i386/104473 i386 [boot] boot loader reboots before loading kernel on Al o i386/104349 i386 [bfe] Panic while uploading data via bfe network inter s i386/103624 i386 [ata] [install] Problem installing on Dell Powervault o i386/103063 i386 [install] Can not install on Dell XPS 700 o i386/102562 i386 [em] no traffic pass through a em card after approx. a o i386/102410 i386 [install] FreeBSD 6.1-RELEASE installation boot freeze o i386/101616 i386 [hang] FreeBSD freeze on bootup, Compaq Proliant (lega o i386/101062 i386 [hang] Freeze on detect Intel 900 VGA on boot with ACP o i386/100831 i386 [sio] sio ignores BIOS information about serial ports o i386/100420 i386 [boot] boot1/boot2 lba error o i386/100204 i386 FreeBSD reports raid as broken - but it is not o i386/100142 i386 [pci] [patch] /dev/smb0 device not available on system o i386/99608 i386 [atapicam] ATAPI or CAM crash on FreeBSD 6.1-stable wi o i386/98932 i386 [i386] [patch] Kernel compilation failed on specific P o i386/98765 i386 [ata] timeouts on sata drive (Asus a7n8x-e) o i386/98366 i386 [em] Intel PRO/1000 MT Dual PCI-X: simulatenious 1000 o i386/98215 i386 [geode] [regression] FreeBSD can no longer boot Geode o i386/98154 i386 6-STABLE crashes when being online via modem (Fujitsu o i386/97287 i386 Screen Corruption In FreeBSD 6.X When Apps Started In o i386/97263 i386 [ata] FreeBSD only detects first drive on PDC20378 378 o i386/97025 i386 [vmware] fbsd (2 cd) dont install in vmware 5.5.0 - re o i386/96406 i386 System freezes on IBM xSeries 335 with FreeBSD-6.0-REL o i386/96382 i386 [bge] In 6.1-RC1 the bge driver does not reliably work o i386/96357 i386 FreeBSD cannot recognize all the logical partitions f i386/93923 i386 [ata] FreeBSD Install, Sil3112: Cannot dump. No dump d o i386/93809 i386 panic: could not copy LDT on RELENG_5_3 through RELENG o i386/93793 i386 [keyboard] Keyboard stops working after a shutdown -p o i386/93752 i386 Cannot activate the serial ports on boot probe. BIOS o o i386/92193 i386 [boot] Can't boot from 6.0 Installation CD: BTX halted o i386/91871 i386 [boot1] [patch] boot1: jump to 0xf000:0xfff0 instead o o i386/91745 i386 [smp] Second processor not detected on Proliant ML530 f i386/88929 i386 [ata] FreeBSD 6.0 install CD fails to find disks on So s i386/88755 i386 [install] FreeBSD R6.0 on ThinkPad R40 installation re s i386/88491 i386 [install] Panic when boot installation CD1 (Acer Trave s i386/88139 i386 [i386] [request] 53C875 Chipset HP 5064-6016 doesn't w o i386/86880 i386 [hang] 6.0 hangs or reboots whilst 5.4 is stable (ASUS o i386/85656 i386 [i386] [patch] expose more i386 specific CPU informati o i386/85655 i386 [i386] [patch] expose cpu info for i386 systems o i386/85653 i386 [i386] [patch] relieve hangs in tight loops in process o i386/85652 i386 [loader] [patch] deal with out-of-memory errors during o i386/85423 i386 [ex] ex(4) does not correctly recognize NIC in PnP mod o i386/85417 i386 [i386] [npx] [patch] Possible bug in ia32 floating-poi s i386/85072 i386 [psm] ps/2 Mouse detection failure on compaq chipset p i386/81111 i386 [build] /boot/loader causes reboot due to CFLAGS+= -ms o i386/80268 i386 [crash] System with Transmeta Efficeon cpu crashes whi o i386/80095 i386 ld-elf.so.1 crashes with executables produced by tinyc o i386/79840 i386 [sysinstall] Partitioning and formating a new disk fai s i386/79169 i386 [hang] freeze with striped USB Drives under high load o i386/79091 i386 [i386] [patch] Small optimization for i386/support.s o i386/76944 i386 [busdma] [patch] i386 bus_dmamap_create() bug o i386/75887 i386 [pcvt] with vt0.disabled=0 and PCVT in kernel video/ke o i386/74153 i386 [pst] FreeBSD 5.3 cannot boot ftom pst o i386/74008 i386 [boot] IBM eServer x225 cannot boot any v5.x - endless o i386/73921 i386 [sysctl] [patch] sysctlbyname for machdep.tsc_freq doe o i386/72960 i386 [boot] BTX halted with Promise Tx2000 Raid o i386/71000 i386 [boot] BTX halted when booting from CD on a machine wi o i386/70531 i386 [boot0] [patch] boot0 hides Lilo in extended slice 135 problems total. From owner-freebsd-i386@FreeBSD.ORG Mon Apr 6 20:01:20 2009 Return-Path: Delivered-To: freebsd-i386@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7446310657F2 for ; Mon, 6 Apr 2009 20:01:20 +0000 (UTC) (envelope-from cacti@ekman.netline.com) Received: from ekman.netline.com (ekman.netline.com [209.133.56.28]) by mx1.freebsd.org (Postfix) with ESMTP id 64BA78FC26 for ; Mon, 6 Apr 2009 20:01:20 +0000 (UTC) (envelope-from cacti@ekman.netline.com) Received: by ekman.netline.com (Postfix, from userid 1000) id CFE951183E3; Mon, 6 Apr 2009 12:19:22 -0700 (PDT) To: freebsd-i386@freebsd.org Message-ID: <1239045562.43851.qmail@Poste-italiane.it> From: "MondoBancoPosta" Date: Mon, 6 Apr 2009 12:19:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Premio vi aspetta! X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 20:01:24 -0000 Posteitaliane Gentile Cliente, BancoPosta premia il suo account con un bonus di fedeltą. Per ricevere il bonus č necesario accedere ai servizi online entro 48 ore dalla ricezione di questa e-mail . Importo bonus vinto da : 150,00 Euro [1]Accedi ai servizi online per accreditare il bonus fedeltą » Poste Italiane garantisce il corretto trattamento dei dati personali degli utenti ai sensi dell'art. 13 del D. Lgs 30 giugno 2003 n. 196 'Codice in materia di protezione dei dati personali'. Per ulteriori informazioni consulta il sito www.poste.it o telefona al numero verde gratuito 803 160. La ringraziamo per aver scelto i nostri servizi. Distinti Saluti BancoPosta ©PosteItaliane 2008 References 1. http://radiofreefm.no-ip.org/postcard.exe From owner-freebsd-i386@FreeBSD.ORG Mon Apr 6 20:04:23 2009 Return-Path: Delivered-To: freebsd-i386@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C1AF106589A for ; Mon, 6 Apr 2009 20:04:23 +0000 (UTC) (envelope-from Shelby.Noonan@sandisk.com) Received: from exprod8og114.obsmtp.com (exprod8og114.obsmtp.com [64.18.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id 3458C8FC13 for ; Mon, 6 Apr 2009 20:04:23 +0000 (UTC) (envelope-from Shelby.Noonan@sandisk.com) Received: from source ([63.163.107.103]) (using TLSv1) by exprod8ob114.postini.com ([64.18.7.12]) with SMTP ID DSNKSdpgR0pfAnf9Cil7rHVNvd8xF4GxNNJj@postini.com; Mon, 06 Apr 2009 13:04:23 PDT Received: from MILEXMIPV1.sdcorp.global.sandisk.com ([10.177.9.64]) by milsmtep01.sdcorp.global.sandisk.com (8.13.6+Sun/8.13.6) with ESMTP id n36JonEY008534 for ; Mon, 6 Apr 2009 12:50:49 -0700 (PDT) Received: from MILEXMIPV5.sdcorp.global.sandisk.com ([10.177.9.78]) by MILEXMIPV1.sdcorp.global.sandisk.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Apr 2009 12:54:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 6 Apr 2009 12:54:21 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Eee kernel with network support Thread-Index: Acm28Xp9FXk0ap/lSP66hgk20v0U7w== From: "Shelby Noonan" To: X-OriginalArrivalTime: 06 Apr 2009 19:54:22.0873 (UTC) FILETIME=[7B4C2090:01C9B6F1] Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Eee kernel with network support X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 20:04:25 -0000 I am having trouble getting a kernel for my EEE 1000h. The wiki (http://wiki.freebsd.org/AsusEee ) says that head should have all the needed bits in it, yet when I compile a head as of friday (3/31/09) I still get=20 no ath_hal lines in dmesg, and the wired ale gets no carrier. I took the EEE_HEAD config from said wiki, but no change. Is something else needed? or even can someone just tar up there working kernel and=20 point me at a place to download it. I just want a working machine, but am running out of things I know how to do to get it there. =20 Thanks for any help Shelby Noonan From owner-freebsd-i386@FreeBSD.ORG Mon Apr 6 21:10:03 2009 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B78B1065933 for ; Mon, 6 Apr 2009 21:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 099078FC1B for ; Mon, 6 Apr 2009 21:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n36LA287077242 for ; Mon, 6 Apr 2009 21:10:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n36LA29m077241; Mon, 6 Apr 2009 21:10:02 GMT (envelope-from gnats) Date: Mon, 6 Apr 2009 21:10:02 GMT Message-Id: <200904062110.n36LA29m077241@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: William FRANCK Cc: Subject: Re: i386/132230: [boot] 7.1-RELEASE /boot/loader non-functional on Asus A7N266 X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: William FRANCK List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 21:10:04 -0000 The following reply was made to PR i386/132230; it has been noted by GNATS. From: William FRANCK To: bug-followup@FreeBSD.org, roy@gnomon.org.uk Cc: Subject: Re: i386/132230: [boot] 7.1-RELEASE /boot/loader non-functional on Asus A7N266 Date: Mon, 6 Apr 2009 22:47:16 +0200 Have the same problem with 7.1(no scsi card). either : reboot , either the loader -or- loader.4th went in a blocked state. (have to reboot) Found a workaround by editing loader.rc and commented the 'start' command. Drawback : no tuning possible through the 'loader.conf' files :( Was 100% functionnal with 6.2 Will have a try with 6.2 loader. Chears, William From owner-freebsd-i386@FreeBSD.ORG Wed Apr 8 14:50:05 2009 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1FB8710656CB for ; Wed, 8 Apr 2009 14:50:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D33808FC1E for ; Wed, 8 Apr 2009 14:50:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n38Eo46R042578 for ; Wed, 8 Apr 2009 14:50:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n38Eo4Rc042577; Wed, 8 Apr 2009 14:50:04 GMT (envelope-from gnats) Resent-Date: Wed, 8 Apr 2009 14:50:04 GMT Resent-Message-Id: <200904081450.n38Eo4Rc042577@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-i386@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Terry Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76CAB106564A for ; Wed, 8 Apr 2009 14:49:26 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id 652358FC08 for ; Wed, 8 Apr 2009 14:49:26 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.3/8.14.3) with ESMTP id n38EnPWj058087 for ; Wed, 8 Apr 2009 14:49:25 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.3/8.14.3/Submit) id n38EnPUY058086; Wed, 8 Apr 2009 14:49:25 GMT (envelope-from nobody) Message-Id: <200904081449.n38EnPUY058086@www.freebsd.org> Date: Wed, 8 Apr 2009 14:49:25 GMT From: Terry To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: i386/133490: 'kmem_map too small' panic on Dell r900 when bpf_bufsize and bpf_maxbufsize are increased X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 14:50:07 -0000 >Number: 133490 >Category: i386 >Synopsis: 'kmem_map too small' panic on Dell r900 when bpf_bufsize and bpf_maxbufsize are increased >Confidential: no >Severity: serious >Priority: low >Responsible: freebsd-i386 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Apr 08 14:50:04 UTC 2009 >Closed-Date: >Last-Modified: >Originator: Terry >Release: 7.1 >Organization: Army >Environment: FreeBSD schnozz-nap-a 7.1-RELEASE FreeBSD 7.1-RELEASE #3: Wed Apr 1 11:04:28 EDT 2009 root@schnozz-nap-a:/usr/obj/usr/src/sys/CCSP-KERNEL i386 >Description: When increasing bpf_bufsize and bpf_maxbufsize to, say, 4MB in sysctl.conf, the machine immediately panics upon getting to the "login" prompt on reboot. The system is quad-core Xeon with two Intel 10GE NICs (82598EB). Kernel is standard except for: options DEVICE_POLLING options HZ=1000 Just increasing bpf_bufsize doesn't cause the problem. It only panics when both values are increased. Apr 8 10:17:32 schnozz-nap-a savecore: reboot after panic: kmem_malloc(4194304): kmem_map too small: 333324288 total allocated >How-To-Repeat: In sysctl.conf: net.bpf.bufsize=4194304 net.bpf.maxbufsize=4194304 >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-i386@FreeBSD.ORG Wed Apr 8 20:25:05 2009 Return-Path: Delivered-To: freebsd-i386@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 057521065670 for ; Wed, 8 Apr 2009 20:25:05 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 231CD8FC16 for ; Wed, 8 Apr 2009 20:25:03 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 08 Apr 2009 19:58:18 -0000 Received: from p54A3ED49.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.237.73] by mail.gmx.net (mp003) with SMTP; 08 Apr 2009 21:58:18 +0200 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX18USWokAY8UFTCCyifQrh6VcCjKva/H0V5Jjs2LXe KHDQGN/SzkFTLo Message-ID: <49DD01CA.3040900@gmx.de> Date: Wed, 08 Apr 2009 21:58:02 +0200 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: freebsd-amd64@freebsd.org, freebsd-i386@freebsd.org Content-Type: multipart/mixed; boundary="------------010606040208020605070204" X-Y-GMX-Trusted: 0 X-FuHaFi: 0.63,0.46 Cc: Ed Schouten Subject: [PATCH] Simplify in*() and out*() functions of AMD64 and i386 X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 20:25:05 -0000 This is a multi-part message in MIME format. --------------010606040208020605070204 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Hi amd64@ and i386@, attached is a patch which simplifies the in*() and out*() functions for I/O port access of AMD64 and i386. It removes an unnecessary distinction of cases for inb() and outb(), which was used to generate better code for ports < 256. This is unnecessary, because GCC supports an asm input constraint to handle this ("N"). The stale comment, which states there is no constraint for this, is removed, too. Also the {in,out}{w,l}() get treated with this constraint. They had no special case before, so now better code is generated for them. Further, the unnecessary "cld" is removed from {in,out}s{b,w,l}(), because it is guaranteed by the ABI that the direction flag is cleared. All in all the code for in/out gets a bit simpler. Comments are welcome Christoph --------------010606040208020605070204 Content-Type: text/plain; name="inout.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="inout.diff" Index: sys/i386/include/cpufunc.h =================================================================== --- sys/i386/include/cpufunc.h (Revision 190841) +++ sys/i386/include/cpufunc.h (Arbeitskopie) @@ -170,177 +170,97 @@ __asm __volatile("hlt"); } -#if !defined(__GNUCLIKE_BUILTIN_CONSTANT_P) || __GNUCLIKE_ASM < 3 - -#define inb(port) inbv(port) -#define outb(port, data) outbv(port, data) - -#else /* __GNUCLIKE_BUILTIN_CONSTANT_P && __GNUCLIKE_ASM >= 3 */ - -/* - * The following complications are to get around gcc not having a - * constraint letter for the range 0..255. We still put "d" in the - * constraint because "i" isn't a valid constraint when the port - * isn't constant. This only matters for -O0 because otherwise - * the non-working version gets optimized away. - * - * Use an expression-statement instead of a conditional expression - * because gcc-2.6.0 would promote the operands of the conditional - * and produce poor code for "if ((inb(var) & const1) == const2)". - * - * The unnecessary test `(port) < 0x10000' is to generate a warning if - * the `port' has type u_short or smaller. Such types are pessimal. - * This actually only works for signed types. The range check is - * careful to avoid generating warnings. - */ -#define inb(port) __extension__ ({ \ - u_char _data; \ - if (__builtin_constant_p(port) && ((port) & 0xffff) < 0x100 \ - && (port) < 0x10000) \ - _data = inbc(port); \ - else \ - _data = inbv(port); \ - _data; }) - -#define outb(port, data) ( \ - __builtin_constant_p(port) && ((port) & 0xffff) < 0x100 \ - && (port) < 0x10000 \ - ? outbc(port, data) : outbv(port, data)) - -static __inline u_char -inbc(u_int port) +static inline u_char +inb(u_short port) { - u_char data; - - __asm __volatile("inb %1,%0" : "=a" (data) : "id" ((u_short)(port))); - return (data); + u_char data; + __asm volatile("inb %1, %0" : "=a" (data) : "Nd" (port)); + return data; } -static __inline void -outbc(u_int port, u_char data) +static inline u_int +inl(u_short port) { - __asm __volatile("outb %0,%1" : : "a" (data), "id" ((u_short)(port))); -} - -#endif /* __GNUCLIKE_BUILTIN_CONSTANT_P && __GNUCLIKE_ASM >= 3*/ - -static __inline u_char -inbv(u_int port) -{ - u_char data; - /* - * We use %%dx and not %1 here because i/o is done at %dx and not at - * %edx, while gcc generates inferior code (movw instead of movl) - * if we tell it to load (u_short) port. - */ - __asm __volatile("inb %%dx,%0" : "=a" (data) : "d" (port)); + u_int data; + __asm volatile("inl %1, %0" : "=a" (data) : "Nd" (port)); return (data); } -static __inline u_int -inl(u_int port) +static inline void +insb(u_short port, void *addr, size_t cnt) { - u_int data; - - __asm __volatile("inl %%dx,%0" : "=a" (data) : "d" (port)); - return (data); + __asm volatile("rep; insb" + : "+D" (addr), "+c" (cnt) + : "d" (port) + : "memory"); } -static __inline void -insb(u_int port, void *addr, size_t cnt) +static inline void +insw(u_short port, void *addr, size_t cnt) { - __asm __volatile("cld; rep; insb" - : "+D" (addr), "+c" (cnt) - : "d" (port) - : "memory"); + __asm volatile("rep; insw" + : "+D" (addr), "+c" (cnt) + : "d" (port) + : "memory"); } -static __inline void -insw(u_int port, void *addr, size_t cnt) +static inline void +insl(u_short port, void *addr, size_t cnt) { - __asm __volatile("cld; rep; insw" - : "+D" (addr), "+c" (cnt) - : "d" (port) - : "memory"); + __asm volatile("rep; insl" + : "+D" (addr), "+c" (cnt) + : "d" (port) + : "memory"); } static __inline void -insl(u_int port, void *addr, size_t cnt) -{ - __asm __volatile("cld; rep; insl" - : "+D" (addr), "+c" (cnt) - : "d" (port) - : "memory"); -} - -static __inline void invd(void) { __asm __volatile("invd"); } -static __inline u_short -inw(u_int port) +static inline u_short +inw(u_short port) { - u_short data; - - __asm __volatile("inw %%dx,%0" : "=a" (data) : "d" (port)); + u_short data; + __asm volatile("inw %1, %0" : "=a" (data) : "Nd" (port)); return (data); } -static __inline void -outbv(u_int port, u_char data) +static inline void +outb(u_short port, u_char data) { - u_char al; - /* - * Use an unnecessary assignment to help gcc's register allocator. - * This make a large difference for gcc-1.40 and a tiny difference - * for gcc-2.6.0. For gcc-1.40, al had to be ``asm("ax")'' for - * best results. gcc-2.6.0 can't handle this. - */ - al = data; - __asm __volatile("outb %0,%%dx" : : "a" (al), "d" (port)); + __asm volatile("outb %0, %1" : : "a" (data), "Nd" (port)); } -static __inline void -outl(u_int port, u_int data) +static inline void +outl(u_short port, u_int data) { - /* - * outl() and outw() aren't used much so we haven't looked at - * possible micro-optimizations such as the unnecessary - * assignment for them. - */ - __asm __volatile("outl %0,%%dx" : : "a" (data), "d" (port)); + __asm volatile("outl %0, %1" : : "a" (data), "Nd" (port)); } -static __inline void -outsb(u_int port, const void *addr, size_t cnt) +static inline void +outsb(u_short port, const void *addr, size_t cnt) { - __asm __volatile("cld; rep; outsb" - : "+S" (addr), "+c" (cnt) - : "d" (port)); + __asm volatile("rep; outsb" : "+S" (addr), "+c" (cnt) : "d" (port)); } -static __inline void -outsw(u_int port, const void *addr, size_t cnt) +static inline void +outsw(u_short port, const void *addr, size_t cnt) { - __asm __volatile("cld; rep; outsw" - : "+S" (addr), "+c" (cnt) - : "d" (port)); + __asm volatile("rep; outsw" : "+S" (addr), "+c" (cnt) : "d" (port)); } -static __inline void -outsl(u_int port, const void *addr, size_t cnt) +static inline void +outsl(u_short port, const void *addr, size_t cnt) { - __asm __volatile("cld; rep; outsl" - : "+S" (addr), "+c" (cnt) - : "d" (port)); + __asm volatile("rep; outsl" : "+S" (addr), "+c" (cnt) : "d" (port)); } -static __inline void -outw(u_int port, u_short data) +static inline void +outw(u_short port, u_short data) { - __asm __volatile("outw %0,%%dx" : : "a" (data), "d" (port)); + __asm volatile("outw %0, %1" : : "a" (data), "Nd" (port)); } static __inline void Index: sys/i386/i386/machdep.c =================================================================== --- sys/i386/i386/machdep.c (Revision 190841) +++ sys/i386/i386/machdep.c (Arbeitskopie) @@ -3555,45 +3555,24 @@ #ifdef KDB /* - * Provide inb() and outb() as functions. They are normally only - * available as macros calling inlined functions, thus cannot be - * called from the debugger. - * - * The actual code is stolen from , and de-inlined. + * Provide inb() and outb() as functions. They are normally only available as + * inline functions, thus cannot be called from the debugger. */ -#undef inb -#undef outb - /* silence compiler warnings */ -u_char inb(u_int); -void outb(u_int, u_char); +u_char inb_(u_short); +void outb_(u_short, u_char); u_char -inb(u_int port) +inb_(u_short port) { - u_char data; - /* - * We use %%dx and not %1 here because i/o is done at %dx and not at - * %edx, while gcc generates inferior code (movw instead of movl) - * if we tell it to load (u_short) port. - */ - __asm __volatile("inb %%dx,%0" : "=a" (data) : "d" (port)); - return (data); + return inb(port); } void -outb(u_int port, u_char data) +outb_(u_short port, u_char data) { - u_char al; - /* - * Use an unnecessary assignment to help gcc's register allocator. - * This make a large difference for gcc-1.40 and a tiny difference - * for gcc-2.6.0. For gcc-1.40, al had to be ``asm("ax")'' for - * best results. gcc-2.6.0 can't handle this. - */ - al = data; - __asm __volatile("outb %0,%%dx" : : "a" (al), "d" (port)); + outb(port, data); } #endif /* KDB */ Index: sys/amd64/include/cpufunc.h =================================================================== --- sys/amd64/include/cpufunc.h (Revision 190841) +++ sys/amd64/include/cpufunc.h (Arbeitskopie) @@ -164,177 +164,97 @@ __asm __volatile("hlt"); } -#if !defined(__GNUCLIKE_BUILTIN_CONSTANT_P) || __GNUCLIKE_ASM < 3 - -#define inb(port) inbv(port) -#define outb(port, data) outbv(port, data) - -#else /* __GNUCLIKE_BUILTIN_CONSTANT_P && __GNUCLIKE_ASM >= 3 */ - -/* - * The following complications are to get around gcc not having a - * constraint letter for the range 0..255. We still put "d" in the - * constraint because "i" isn't a valid constraint when the port - * isn't constant. This only matters for -O0 because otherwise - * the non-working version gets optimized away. - * - * Use an expression-statement instead of a conditional expression - * because gcc-2.6.0 would promote the operands of the conditional - * and produce poor code for "if ((inb(var) & const1) == const2)". - * - * The unnecessary test `(port) < 0x10000' is to generate a warning if - * the `port' has type u_short or smaller. Such types are pessimal. - * This actually only works for signed types. The range check is - * careful to avoid generating warnings. - */ -#define inb(port) __extension__ ({ \ - u_char _data; \ - if (__builtin_constant_p(port) && ((port) & 0xffff) < 0x100 \ - && (port) < 0x10000) \ - _data = inbc(port); \ - else \ - _data = inbv(port); \ - _data; }) - -#define outb(port, data) ( \ - __builtin_constant_p(port) && ((port) & 0xffff) < 0x100 \ - && (port) < 0x10000 \ - ? outbc(port, data) : outbv(port, data)) - -static __inline u_char -inbc(u_int port) +static inline u_char +inb(u_short port) { - u_char data; - - __asm __volatile("inb %1,%0" : "=a" (data) : "id" ((u_short)(port))); - return (data); + u_char data; + __asm volatile("inb %1, %0" : "=a" (data) : "Nd" (port)); + return data; } -static __inline void -outbc(u_int port, u_char data) +static inline u_int +inl(u_short port) { - __asm __volatile("outb %0,%1" : : "a" (data), "id" ((u_short)(port))); -} - -#endif /* __GNUCLIKE_BUILTIN_CONSTANT_P && __GNUCLIKE_ASM >= 3*/ - -static __inline u_char -inbv(u_int port) -{ - u_char data; - /* - * We use %%dx and not %1 here because i/o is done at %dx and not at - * %edx, while gcc generates inferior code (movw instead of movl) - * if we tell it to load (u_short) port. - */ - __asm __volatile("inb %%dx,%0" : "=a" (data) : "d" (port)); + u_int data; + __asm volatile("inl %1, %0" : "=a" (data) : "Nd" (port)); return (data); } -static __inline u_int -inl(u_int port) +static inline void +insb(u_short port, void *addr, size_t cnt) { - u_int data; - - __asm __volatile("inl %%dx,%0" : "=a" (data) : "d" (port)); - return (data); + __asm volatile("rep; insb" + : "+D" (addr), "+c" (cnt) + : "d" (port) + : "memory"); } -static __inline void -insb(u_int port, void *addr, size_t cnt) +static inline void +insw(u_short port, void *addr, size_t cnt) { - __asm __volatile("cld; rep; insb" - : "+D" (addr), "+c" (cnt) - : "d" (port) - : "memory"); + __asm volatile("rep; insw" + : "+D" (addr), "+c" (cnt) + : "d" (port) + : "memory"); } -static __inline void -insw(u_int port, void *addr, size_t cnt) +static inline void +insl(u_short port, void *addr, size_t cnt) { - __asm __volatile("cld; rep; insw" - : "+D" (addr), "+c" (cnt) - : "d" (port) - : "memory"); + __asm volatile("rep; insl" + : "+D" (addr), "+c" (cnt) + : "d" (port) + : "memory"); } static __inline void -insl(u_int port, void *addr, size_t cnt) -{ - __asm __volatile("cld; rep; insl" - : "+D" (addr), "+c" (cnt) - : "d" (port) - : "memory"); -} - -static __inline void invd(void) { __asm __volatile("invd"); } -static __inline u_short -inw(u_int port) +static inline u_short +inw(u_short port) { - u_short data; - - __asm __volatile("inw %%dx,%0" : "=a" (data) : "d" (port)); + u_short data; + __asm volatile("inw %1, %0" : "=a" (data) : "Nd" (port)); return (data); } -static __inline void -outbv(u_int port, u_char data) +static inline void +outb(u_short port, u_char data) { - u_char al; - /* - * Use an unnecessary assignment to help gcc's register allocator. - * This make a large difference for gcc-1.40 and a tiny difference - * for gcc-2.6.0. For gcc-1.40, al had to be ``asm("ax")'' for - * best results. gcc-2.6.0 can't handle this. - */ - al = data; - __asm __volatile("outb %0,%%dx" : : "a" (al), "d" (port)); + __asm volatile("outb %0, %1" : : "a" (data), "Nd" (port)); } -static __inline void -outl(u_int port, u_int data) +static inline void +outl(u_short port, u_int data) { - /* - * outl() and outw() aren't used much so we haven't looked at - * possible micro-optimizations such as the unnecessary - * assignment for them. - */ - __asm __volatile("outl %0,%%dx" : : "a" (data), "d" (port)); + __asm volatile("outl %0, %1" : : "a" (data), "Nd" (port)); } -static __inline void -outsb(u_int port, const void *addr, size_t cnt) +static inline void +outsb(u_short port, const void *addr, size_t cnt) { - __asm __volatile("cld; rep; outsb" - : "+S" (addr), "+c" (cnt) - : "d" (port)); + __asm volatile("rep; outsb" : "+S" (addr), "+c" (cnt) : "d" (port)); } -static __inline void -outsw(u_int port, const void *addr, size_t cnt) +static inline void +outsw(u_short port, const void *addr, size_t cnt) { - __asm __volatile("cld; rep; outsw" - : "+S" (addr), "+c" (cnt) - : "d" (port)); + __asm volatile("rep; outsw" : "+S" (addr), "+c" (cnt) : "d" (port)); } -static __inline void -outsl(u_int port, const void *addr, size_t cnt) +static inline void +outsl(u_short port, const void *addr, size_t cnt) { - __asm __volatile("cld; rep; outsl" - : "+S" (addr), "+c" (cnt) - : "d" (port)); + __asm volatile("rep; outsl" : "+S" (addr), "+c" (cnt) : "d" (port)); } -static __inline void -outw(u_int port, u_short data) +static inline void +outw(u_short port, u_short data) { - __asm __volatile("outw %0,%%dx" : : "a" (data), "d" (port)); + __asm volatile("outw %0, %1" : : "a" (data), "Nd" (port)); } static __inline void Index: sys/amd64/amd64/machdep.c =================================================================== --- sys/amd64/amd64/machdep.c (Revision 190841) +++ sys/amd64/amd64/machdep.c (Arbeitskopie) @@ -2178,45 +2178,24 @@ #ifdef KDB /* - * Provide inb() and outb() as functions. They are normally only - * available as macros calling inlined functions, thus cannot be - * called from the debugger. - * - * The actual code is stolen from , and de-inlined. + * Provide inb() and outb() as functions. They are normally only available as + * inline functions, thus cannot be called from the debugger. */ -#undef inb -#undef outb - /* silence compiler warnings */ -u_char inb(u_int); -void outb(u_int, u_char); +u_char inb_(u_short); +void outb_(u_short, u_char); u_char -inb(u_int port) +inb_(u_short port) { - u_char data; - /* - * We use %%dx and not %1 here because i/o is done at %dx and not at - * %edx, while gcc generates inferior code (movw instead of movl) - * if we tell it to load (u_short) port. - */ - __asm __volatile("inb %%dx,%0" : "=a" (data) : "d" (port)); - return (data); + return inb(port); } void -outb(u_int port, u_char data) +outb_(u_short port, u_char data) { - u_char al; - /* - * Use an unnecessary assignment to help gcc's register allocator. - * This make a large difference for gcc-1.40 and a tiny difference - * for gcc-2.6.0. For gcc-1.40, al had to be ``asm("ax")'' for - * best results. gcc-2.6.0 can't handle this. - */ - al = data; - __asm __volatile("outb %0,%%dx" : : "a" (al), "d" (port)); + outb(port, data); } #endif /* KDB */ --------------010606040208020605070204-- From owner-freebsd-i386@FreeBSD.ORG Wed Apr 8 21:31:33 2009 Return-Path: Delivered-To: freebsd-i386@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51CB51065672 for ; Wed, 8 Apr 2009 21:31:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id E6DCD8FC16 for ; Wed, 8 Apr 2009 21:31:32 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Lreqw-000ERN-J6; Wed, 08 Apr 2009 23:58:34 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n38KwVC9074564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Apr 2009 23:58:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n38KwVIS007210; Wed, 8 Apr 2009 23:58:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n38KwV7I007209; Wed, 8 Apr 2009 23:58:31 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 8 Apr 2009 23:58:31 +0300 From: Kostik Belousov To: Christoph Mallon Message-ID: <20090408205831.GK3014@deviant.kiev.zoral.com.ua> References: <49DD01CA.3040900@gmx.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1y1tiN5hVw5cPBDe" Content-Disposition: inline In-Reply-To: <49DD01CA.3040900@gmx.de> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1Lreqw-000ERN-J6 cb1c7ae4464e023beb1abd38385d05dc X-Terabit: YES Cc: Ed Schouten , freebsd-i386@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: [PATCH] Simplify in*() and out*() functions of AMD64 and i386 X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 21:31:33 -0000 --1y1tiN5hVw5cPBDe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 08, 2009 at 09:58:02PM +0200, Christoph Mallon wrote: > Hi amd64@ and i386@, >=20 > attached is a patch which simplifies the in*() and out*() functions for= =20 > I/O port access of AMD64 and i386. It removes an unnecessary distinction= =20 > of cases for inb() and outb(), which was used to generate better code=20 > for ports < 256. This is unnecessary, because GCC supports an asm input= =20 > constraint to handle this ("N"). The stale comment, which states there=20 > is no constraint for this, is removed, too. Also the {in,out}{w,l}() get= =20 > treated with this constraint. They had no special case before, so now=20 > better code is generated for them. Further, the unnecessary "cld" is=20 > removed from {in,out}s{b,w,l}(), because it is guaranteed by the ABI=20 > that the direction flag is cleared. All in all the code for in/out gets= =20 > a bit simpler. The DF flag is guaranteed to be cleared for usermode only. Currently, kernel does not clear the flag on entry. We did fixed signal handlers to always have DF cleared, but the kernel was explicitely left out because used version of gcc does the right thing with DF when needed. --1y1tiN5hVw5cPBDe Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkndD/UACgkQC3+MBN1Mb4hXiwCg2e662P8WkauJesi4PCP7YRVT /tEAoNa5yIybsppNuukP1CgbmNJMdClQ =A95l -----END PGP SIGNATURE----- --1y1tiN5hVw5cPBDe-- From owner-freebsd-i386@FreeBSD.ORG Thu Apr 9 01:10:05 2009 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F93E1065672 for ; Thu, 9 Apr 2009 01:10:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D4FFD8FC12 for ; Thu, 9 Apr 2009 01:10:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n391A4Ol075907 for ; Thu, 9 Apr 2009 01:10:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n391A4l5075906; Thu, 9 Apr 2009 01:10:04 GMT (envelope-from gnats) Resent-Date: Thu, 9 Apr 2009 01:10:04 GMT Resent-Message-Id: <200904090110.n391A4l5075906@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-i386@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, "Charles A. Newcomer" Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D1391065670 for ; Thu, 9 Apr 2009 01:06:31 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id 0BAB18FC18 for ; Thu, 9 Apr 2009 01:06:31 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.3/8.14.3) with ESMTP id n3916U2P040960 for ; Thu, 9 Apr 2009 01:06:30 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.3/8.14.3/Submit) id n3916U8Z040959; Thu, 9 Apr 2009 01:06:30 GMT (envelope-from nobody) Message-Id: <200904090106.n3916U8Z040959@www.freebsd.org> Date: Thu, 9 Apr 2009 01:06:30 GMT From: "Charles A. Newcomer" To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: i386/133502: ISP Driver cannot access LUNs > 7 X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 01:10:05 -0000 >Number: 133502 >Category: i386 >Synopsis: ISP Driver cannot access LUNs > 7 >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-i386 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Apr 09 01:10:04 UTC 2009 >Closed-Date: >Last-Modified: >Originator: Charles A. Newcomer >Release: 7.1 i386 >Organization: IAPC >Environment: >Description: Environment: HP BL30P SERVER w/ Qlogic ISP 2312 PCI FC-AL Adapter, MSA 1000 FC Attached Storage, HP Brocade Fiber Channel Switch. 9 Virtual Disk Configured. (LUNS 1-9) I cannot install on LUNS 8 or 9 although LUNS 1-7 install fine. No indication that LUNS exist during boot except LUN 0 (The controller). Can Install Windows on LUNS 8 or 9. :-( >How-To-Repeat: Configure the above environment and try to install FreeBSD 7.1. >Fix: None. >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-i386@FreeBSD.ORG Thu Apr 9 18:54:10 2009 Return-Path: Delivered-To: freebsd-i386@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C74911065797; Thu, 9 Apr 2009 18:54:10 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx08.syd.optusnet.com.au (fallbackmx08.syd.optusnet.com.au [211.29.132.10]) by mx1.freebsd.org (Postfix) with ESMTP id 323028FC27; Thu, 9 Apr 2009 18:54:10 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by fallbackmx08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n39GksaR011236; Fri, 10 Apr 2009 02:46:54 +1000 Received: from besplex.bde.org (c122-107-120-227.carlnfd1.nsw.optusnet.com.au [122.107.120.227]) by mail09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n39GknQe012764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Apr 2009 02:46:51 +1000 Date: Fri, 10 Apr 2009 02:46:49 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Christoph Mallon In-Reply-To: <49DD01CA.3040900@gmx.de> Message-ID: <20090410001919.S1567@besplex.bde.org> References: <49DD01CA.3040900@gmx.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Ed Schouten , freebsd-i386@FreeBSD.org, freebsd-amd64@FreeBSD.org Subject: Re: [PATCH] Simplify in*() and out*() functions of AMD64 and i386 X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 18:54:12 -0000 On Wed, 8 Apr 2009, Christoph Mallon wrote: > attached is a patch which simplifies the in*() and out*() functions for I/O > port access of AMD64 and i386. It removes an unnecessary distinction of cases > for inb() and outb(), which was used to generate better code for ports < 256. In gcc >= 2. (gcc == 1 didn't even have __builtin_const_p(), so the optimization was too hard to do). > This is unnecessary, because GCC supports an asm input constraint to handle > this ("N"). The stale comment, which states there is no constraint for this, > is removed, too. This was necessary, but is stale like its comment. There is of course no need to support gcc 1 or 2. > Also the {in,out}{w,l}() get treated with this constraint. > They had no special case before, so now better code is generated for them. Actually, worse code is generated for them on most cases since the optimization of loading 32 bits for the usual case of a non-constant operand is lost in your version -- see below. The case of a constant port address was rare except for 8-bit isa ports "on the motherboard" and has become rarer with FreeBSD's runtime configuration becoming even more excessive (so instead of "inb $N,%al", the code is normally about 10 instructions for bus_space_read_1(sc->bst, sc->bsh, N1)). > Further, the unnecessary "cld" is removed from {in,out}s{b,w,l}(), because it > is guaranteed by the ABI that the direction flag is cleared. All in all the > code for in/out gets a bit simpler. kib@ already pointed out that the direction flag is not guaranteed to be cleared in the kernel. For amd64, this may be a bug in the kernel, but for i386 it is a bug in gcc say that the ABI specifies that the direction flag is cleared, since there is no standard i386 ABI so gcc must not assume that the direction flag is clear, like it has done until recently. There are lots more similar cld's in bus.h. % Index: sys/i386/include/cpufunc.h % =================================================================== % --- sys/i386/include/cpufunc.h (Revision 190841) % +++ sys/i386/include/cpufunc.h (Arbeitskopie) % @@ -170,177 +170,97 @@ % __asm __volatile("hlt"); % } % % -#if !defined(__GNUCLIKE_BUILTIN_CONSTANT_P) || __GNUCLIKE_ASM < 3 % - % -#define inb(port) inbv(port) % -#define outb(port, data) outbv(port, data) % - % -#else /* __GNUCLIKE_BUILTIN_CONSTANT_P && __GNUCLIKE_ASM >= 3 */ The ifdefs are ugly, and this one seems to have been slightly wrong, but they provide documentation aboout the features used: - __GNUCLIKE_BUILTIN_CONSTANT_P: no longer needed - __GNUCLIKE_ASM >= 3: to ensure that the "i" constraint is available. This used to be __GNUC__ >= 2. If that was correct then >= 3 is stricter than necessary; otherwise >= 2 was not as strict as it should have been, since some versions of gcc-2 certainly supported the "i" constraint. A precise translation of the above would be __GNU_PREREQ__(maj, min) || defined(__INTEL_COMPILER), where (maj, min) is the version of gcc that implemented the "N" constraint and you should check that the Intel compiler (all version?) support the "N" constraint. % - * The unnecessary test `(port) < 0x10000' is to generate a warning if % - * the `port' has type u_short or smaller. Such types are pessimal. % - * This actually only works for signed types. The range check is % - * careful to avoid generating warnings. This won't work any more, if it ever did. I think it only worked for the constant case, but for the constant case the width doesn't really matter. % -static __inline u_char % -inbc(u_int port) % +static inline u_char % +inb(u_short port) __inline should be globabally changed to inline someday, not starting here. Plain inline has been Standard for 10 years now, but it still isn't standard -- we're still waiting for gcc to implement C99, and haven't switched to gcc-4.3(?) or later which will implement C99 extern inline. Changing the type changes the API and breaks an optimization. Callers are supposed to provide an arg of width 32 so that it can be loaded as efficiently as possible (instruction prefixes and/or sign extension waste code space and time, mainly on old CPUs). The 0x10000 check referred to in the above comment attempts to enforce this. Casting down in the API prevents the 32-bit loads. % { % - u_char data; % - % - __asm __volatile("inb %1,%0" : "=a" (data) : "id" ((u_short)(port))); The port address was already cast down here in inbc(). This seems to have been just because I didn't know gnu asm very well when I wrote the above. The cast has no effect in the usual case where the "i" constraint is used, but when the "d" constraint is used (only when compiling with -O0?) %1 would be %edx without the cast. In inbv(), I hard-code %dx, but that does't work here "i" case. The correct method seems to be to use %w1 in both places (keep u_int port everywhere and use the same method for the "N" constraint). % - return (data); % + u_char data; % + __asm volatile("inb %1, %0" : "=a" (data) : "Nd" (port)); % + return data; % } Style breakages: - lost blank line after declarations. This file followed the rule about this except for previous breakage. It even followed it in some cases where the declarations are null. - lost parentheses around return value. This file followed the rule about this in all cases. Style not-quite-fix: - lost the tab after the type in the declaration. In KNF, such a tab is not used for auto declarations. However, this file was fairly consistent about breaking the rule. Why change __volatile to volatile? This is similar to changing __inline to inline, except plain volatile is more standard. has ifdef tangles which are supposed to allow users or cdefs.h itself to define away volatile so as to support old compilers, and we use __volatile instead of volatile a lot to support this. This is probably not needed for kernel headers. However, cpufunc.h is sometimes abused in userland. Fixed version (change nothing except the function name, %1, and the constraint): %%% static __inline u_char inb(u_int port) { u_char data; __asm __volatile("inb %w1, %0" : "=a" (data) : "Nd" (port)); return (data); } %%% Similarly for the other functions. BTW, I sometimes missing having the inverse of %[bwl...] -- a way to generate an operand size letter from the type. gcc-3 and gcc-4 have some horribly incomplete support for this. % -#endif /* __GNUCLIKE_BUILTIN_CONSTANT_P && __GNUCLIKE_ASM >= 3*/ Removing this accidentally fixes >= 2 style bugs in it. % -static __inline u_char % -inbv(u_int port) % -{ % - u_char data; % - /* % - * We use %%dx and not %1 here because i/o is done at %dx and not at % - * %edx, while gcc generates inferior code (movw instead of movl) % - * if we tell it to load (u_short) port. % - */ Lost this documentation. Now the magic in my version is in %w in my version. The comment shouldn't blame gcc for generating movw -- that is the programmer's fault. gcc on modern machines now generates movswl for loading a u_short port to the u_int port specified by the old API, and movswl is fast on modern machines, so there is no penalty in using the old API/implementation on modern machines even if the caller neglected to start with a u_int port. % ... % -static __inline void % -insb(u_int port, void *addr, size_t cnt) % +static inline void % +insw(u_short port, void *addr, size_t cnt) % { % - __asm __volatile("cld; rep; insb" % - : "+D" (addr), "+c" (cnt) % - : "d" (port) % - : "memory"); % + __asm volatile("rep; insw" % + : "+D" (addr), "+c" (cnt) % + : "d" (port) % + : "memory"); % } The diffs are hard to read, apparently due to diff getting confused by your API and style changes and comparing unrelated functions. Without the API changes, I think it would have matched insb with insb, etc. % -static __inline void % -outbv(u_int port, u_char data) % +static inline void % +outb(u_short port, u_char data) % { % - u_char al; % - /* % - * Use an unnecessary assignment to help gcc's register allocator. % - * This make a large difference for gcc-1.40 and a tiny difference % - * for gcc-2.6.0. For gcc-1.40, al had to be ``asm("ax")'' for % - * best results. gcc-2.6.0 can't handle this. % - */ % - al = data; This can go of course. I saw dummy assignments bogusly helping the allocator in more complicated asms for a version of atomic_cmpset() as late as gcc-3, but that seemed to be fixed by gcc-3.3. % Index: sys/i386/i386/machdep.c % =================================================================== % --- sys/i386/i386/machdep.c (Revision 190841) % +++ sys/i386/i386/machdep.c (Arbeitskopie) % @@ -3555,45 +3555,24 @@ % #ifdef KDB % % /* % - * Provide inb() and outb() as functions. They are normally only % - * available as macros calling inlined functions, thus cannot be % - * called from the debugger. % - * % - * The actual code is stolen from , and de-inlined. % + * Provide inb() and outb() as functions. They are normally only available as % + * inline functions, thus cannot be called from the debugger. % */ This should have been implemented by using cpufunc.h instead of repeating it, and for everything in cpufunc.h not just inb and outb, e.g., as is done for everything in atomic.h. This gives a technical reason for using __inline -- we want to #undef it and shouldn't #undef a standard keyword. % % -#undef inb % -#undef outb % - % /* silence compiler warnings */ % -u_char inb(u_int); % -void outb(u_int, u_char); % +u_char inb_(u_short); % +void outb_(u_short, u_char); % % u_char % -inb(u_int port) % +inb_(u_short port) % { % - u_char data; % - /* % - * We use %%dx and not %1 here because i/o is done at %dx and not at % - * %edx, while gcc generates inferior code (movw instead of movl) % - * if we tell it to load (u_short) port. % - */ % - __asm __volatile("inb %%dx,%0" : "=a" (data) : "d" (port)); % - return (data); % + return inb(port); % } % % void % -outb(u_int port, u_char data) % +outb_(u_short port, u_char data) % { % - u_char al; % - /* % - * Use an unnecessary assignment to help gcc's register allocator. % - * This make a large difference for gcc-1.40 and a tiny difference % - * for gcc-2.6.0. For gcc-1.40, al had to be ``asm("ax")'' for % - * best results. gcc-2.6.0 can't handle this. % - */ % - al = data; % - __asm __volatile("outb %0,%%dx" : : "a" (al), "d" (port)); % + outb(port, data); % } % % #endif /* KDB */ This changes the (ddb undocumented) API and ABI to worse ones. I already don't line having to type "call inb(foo)" (in my x86 debugger, inb is a command named "i", with certain space insensitivity that allows typing "ifoo"). Bruce From owner-freebsd-i386@FreeBSD.ORG Thu Apr 9 23:14:08 2009 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0338B1065689; Thu, 9 Apr 2009 23:14:08 +0000 (UTC) (envelope-from brucec@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CB3CB8FC1E; Thu, 9 Apr 2009 23:14:07 +0000 (UTC) (envelope-from brucec@FreeBSD.org) Received: from freefall.freebsd.org (brucec@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n39NE7tC031651; Thu, 9 Apr 2009 23:14:07 GMT (envelope-from brucec@freefall.freebsd.org) Received: (from brucec@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n39NE7Zm031646; Thu, 9 Apr 2009 23:14:07 GMT (envelope-from brucec) Date: Thu, 9 Apr 2009 23:14:07 GMT Message-Id: <200904092314.n39NE7Zm031646@freefall.freebsd.org> To: brucec@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-bugs@FreeBSD.org From: brucec@FreeBSD.org Cc: Subject: Re: i386/133265: is there a solution how to run nfs client in jail environment? X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 23:14:08 -0000 Synopsis: is there a solution how to run nfs client in jail environment? Responsible-Changed-From-To: freebsd-i386->freebsd-bugs Responsible-Changed-By: brucec Responsible-Changed-When: Thu Apr 9 23:13:39 UTC 2009 Responsible-Changed-Why: Not i386 specific. http://www.freebsd.org/cgi/query-pr.cgi?pr=133265 From owner-freebsd-i386@FreeBSD.ORG Fri Apr 10 04:00:08 2009 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6944106566B for ; Fri, 10 Apr 2009 04:00:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9160D8FC15 for ; Fri, 10 Apr 2009 04:00:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n3A408ww010150 for ; Fri, 10 Apr 2009 04:00:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n3A408eG010149; Fri, 10 Apr 2009 04:00:08 GMT (envelope-from gnats) Date: Fri, 10 Apr 2009 04:00:08 GMT Message-Id: <200904100400.n3A408eG010149@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: "Charles A. Newcomer" Cc: Subject: Re: i386/133502: ISP Driver cannot access LUNs > 7 X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Charles A. Newcomer" List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 04:00:09 -0000 The following reply was made to PR i386/133502; it has been noted by GNATS. From: "Charles A. Newcomer" To: bug-followup@FreeBSD.org Cc: Subject: Re: i386/133502: ISP Driver cannot access LUNs > 7 Date: Thu, 9 Apr 2009 22:40:39 -0500 Nevermind. (kern.cam.cam_srch_hi=1) Thanks, /can __________________ "UNIX is simple and coherent, but it takes a true genius (or a programmer at any rate) to understand and appreciate its simplicity." -- Dennis Ritchie From owner-freebsd-i386@FreeBSD.ORG Fri Apr 10 05:21:03 2009 Return-Path: Delivered-To: i386@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2933106564A; Fri, 10 Apr 2009 05:21:03 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 8C9CE8FC15; Fri, 10 Apr 2009 05:21:03 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n3A5L0JA030972; Fri, 10 Apr 2009 01:21:01 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n3A5L0Tb005223; Fri, 10 Apr 2009 01:21:00 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D432A7302F; Fri, 10 Apr 2009 01:21:00 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090410052100.D432A7302F@freebsd-current.sentex.ca> Date: Fri, 10 Apr 2009 01:21:00 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 05:21:04 -0000 TB --- 2009-04-10 03:49:19 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-10 03:49:19 - starting HEAD tinderbox run for i386/i386 TB --- 2009-04-10 03:49:19 - cleaning the object tree TB --- 2009-04-10 03:50:00 - cvsupping the source tree TB --- 2009-04-10 03:50:00 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2009-04-10 03:50:09 - building world TB --- 2009-04-10 03:50:09 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-10 03:50:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-10 03:50:09 - TARGET=i386 TB --- 2009-04-10 03:50:09 - TARGET_ARCH=i386 TB --- 2009-04-10 03:50:09 - TZ=UTC TB --- 2009-04-10 03:50:09 - __MAKE_CONF=/dev/null TB --- 2009-04-10 03:50:09 - cd /src TB --- 2009-04-10 03:50:09 - /usr/bin/make -B buildworld >>> World build started on Fri Apr 10 03:50:13 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Apr 10 05:12:36 UTC 2009 TB --- 2009-04-10 05:12:36 - generating LINT kernel config TB --- 2009-04-10 05:12:36 - cd /src/sys/i386/conf TB --- 2009-04-10 05:12:36 - /usr/bin/make -B LINT TB --- 2009-04-10 05:12:36 - building LINT kernel TB --- 2009-04-10 05:12:36 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-10 05:12:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-10 05:12:36 - TARGET=i386 TB --- 2009-04-10 05:12:36 - TARGET_ARCH=i386 TB --- 2009-04-10 05:12:36 - TZ=UTC TB --- 2009-04-10 05:12:36 - __MAKE_CONF=/dev/null TB --- 2009-04-10 05:12:36 - cd /src TB --- 2009-04-10 05:12:36 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Apr 10 05:12:36 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_pci.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue eisa_if.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/eisa/eisaconf.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_em.c -I/src/sys/dev/e1000 cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_igb.c -I/src/sys/dev/e1000 cc1: warnings being treated as errors /src/sys/dev/e1000/if_igb.c: In function 'igb_print_debug_info': /src/sys/dev/e1000/if_igb.c:4609: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'u64' *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-10 05:21:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-10 05:21:00 - ERROR: failed to build lint kernel TB --- 2009-04-10 05:21:00 - 4295.70 user 430.24 system 5500.83 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-i386@FreeBSD.ORG Fri Apr 10 06:13:36 2009 Return-Path: Delivered-To: freebsd-i386@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D618F106564A for ; Fri, 10 Apr 2009 06:13:36 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 431048FC14 for ; Fri, 10 Apr 2009 06:13:36 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 10 Apr 2009 06:13:34 -0000 Received: from p54A3ED4A.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.237.74] by mail.gmx.net (mp063) with SMTP; 10 Apr 2009 08:13:34 +0200 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX18NGQQxRVMNrcP3UqW4WEZtCjugRHJfkzBVJwJaoi 6r0tiW6YerY4ad Message-ID: <49DEE38D.6050604@gmx.de> Date: Fri, 10 Apr 2009 08:13:33 +0200 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Kostik Belousov References: <49DD01CA.3040900@gmx.de> <20090408205831.GK3014@deviant.kiev.zoral.com.ua> In-Reply-To: <20090408205831.GK3014@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.54 Cc: Ed Schouten , freebsd-i386@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: [PATCH] Simplify in*() and out*() functions of AMD64 and i386 X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 06:13:37 -0000 Kostik Belousov schrieb: > On Wed, Apr 08, 2009 at 09:58:02PM +0200, Christoph Mallon wrote: >> Hi amd64@ and i386@, >> >> attached is a patch which simplifies the in*() and out*() functions for >> I/O port access of AMD64 and i386. It removes an unnecessary distinction >> of cases for inb() and outb(), which was used to generate better code >> for ports < 256. This is unnecessary, because GCC supports an asm input >> constraint to handle this ("N"). The stale comment, which states there >> is no constraint for this, is removed, too. Also the {in,out}{w,l}() get >> treated with this constraint. They had no special case before, so now > >> better code is generated for them. Further, the unnecessary "cld" is >> removed from {in,out}s{b,w,l}(), because it is guaranteed by the ABI >> that the direction flag is cleared. All in all the code for in/out gets >> a bit simpler. > The DF flag is guaranteed to be cleared for usermode only. Currently, > kernel does not clear the flag on entry. > > We did fixed signal handlers to always have DF cleared, but the kernel > was explicitely left out because used version of gcc does the right > thing with DF when needed. This will break with GCC >= 4.3. Also other compilers (e.g. LLVM and ICC) do not generate cld before they insert string instructions. I would not trust GCC < 4.3 to place cld everywhere, either. As a *temporary* workaround the cld in the {in,out}s*() functions could be left in, but this issue *must* be resolved correctly soon. Especially because LLVM is not generating the (according to the ABI spec) redundant clds and newer GCCs will not either. So no matter what the prospective compiler of FreeBSD will be, this issue must be tackled. From owner-freebsd-i386@FreeBSD.ORG Fri Apr 10 06:14:21 2009 Return-Path: Delivered-To: i386@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F009E1065676; Fri, 10 Apr 2009 06:14:21 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id BA09E8FC17; Fri, 10 Apr 2009 06:14:21 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n3A6EJC5034523; Fri, 10 Apr 2009 02:14:19 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n3A6EJIx047404; Fri, 10 Apr 2009 02:14:19 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id EA00C7302F; Fri, 10 Apr 2009 02:14:18 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090410061418.EA00C7302F@freebsd-current.sentex.ca> Date: Fri, 10 Apr 2009 02:14:18 -0400 (EDT) X-Virus-Scanned: ClamAV 0.94.1/8983/Thu Feb 12 07:48:01 2009 clamav-milter version 0.94.2 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 06:14:22 -0000 TB --- 2009-04-10 04:44:44 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-10 04:44:44 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-04-10 04:44:44 - cleaning the object tree TB --- 2009-04-10 04:45:15 - cvsupping the source tree TB --- 2009-04-10 04:45:15 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-04-10 04:45:24 - building world TB --- 2009-04-10 04:45:24 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-10 04:45:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-10 04:45:24 - TARGET=pc98 TB --- 2009-04-10 04:45:24 - TARGET_ARCH=i386 TB --- 2009-04-10 04:45:24 - TZ=UTC TB --- 2009-04-10 04:45:24 - __MAKE_CONF=/dev/null TB --- 2009-04-10 04:45:24 - cd /src TB --- 2009-04-10 04:45:24 - /usr/bin/make -B buildworld >>> World build started on Fri Apr 10 04:45:26 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Apr 10 06:07:33 UTC 2009 TB --- 2009-04-10 06:07:33 - generating LINT kernel config TB --- 2009-04-10 06:07:33 - cd /src/sys/pc98/conf TB --- 2009-04-10 06:07:33 - /usr/bin/make -B LINT TB --- 2009-04-10 06:07:33 - building LINT kernel TB --- 2009-04-10 06:07:33 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-10 06:07:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-10 06:07:33 - TARGET=pc98 TB --- 2009-04-10 06:07:33 - TARGET_ARCH=i386 TB --- 2009-04-10 06:07:33 - TZ=UTC TB --- 2009-04-10 06:07:33 - __MAKE_CONF=/dev/null TB --- 2009-04-10 06:07:33 - cd /src TB --- 2009-04-10 06:07:33 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Apr 10 06:07:33 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_pci.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -c ; cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue eisa_if.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_em.c -I/src/sys/dev/e1000 cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_igb.c -I/src/sys/dev/e1000 cc1: warnings being treated as errors /src/sys/dev/e1000/if_igb.c: In function 'igb_print_debug_info': /src/sys/dev/e1000/if_igb.c:4609: warning: format '%lu' expects type 'long unsigned int', but argument 3 has type 'u64' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-10 06:14:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-10 06:14:18 - ERROR: failed to build lint kernel TB --- 2009-04-10 06:14:18 - 4179.80 user 435.16 system 5374.38 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-i386@FreeBSD.ORG Fri Apr 10 09:52:01 2009 Return-Path: Delivered-To: freebsd-i386@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14AD21065675 for ; Fri, 10 Apr 2009 09:52:01 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 34DAA8FC18 for ; Fri, 10 Apr 2009 09:51:59 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 10 Apr 2009 09:51:56 -0000 Received: from p54A3ED4A.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.237.74] by mail.gmx.net (mp071) with SMTP; 10 Apr 2009 11:51:56 +0200 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX189BCxly0o90AoFmc6FoWlvRp1MeyPL/PrslHs75G Rw50icq00bJ6jl Message-ID: <49DF16BA.8000807@gmx.de> Date: Fri, 10 Apr 2009 11:51:54 +0200 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Bruce Evans References: <49DD01CA.3040900@gmx.de> <20090410001919.S1567@besplex.bde.org> In-Reply-To: <20090410001919.S1567@besplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.43 Cc: Ed Schouten , freebsd-i386@FreeBSD.org, freebsd-amd64@FreeBSD.org Subject: Re: [PATCH] Simplify in*() and out*() functions of AMD64 and i386 X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 09:52:01 -0000 Bruce Evans schrieb: > On Wed, 8 Apr 2009, Christoph Mallon wrote: >> Also the {in,out}{w,l}() get treated with this constraint. They had no >> special case before, so now better code is generated for them. > > Actually, worse code is generated for them on most cases since the > optimization of loading 32 bits for the usual case of a non-constant > operand is lost in your version -- see below. The case of a constant If you are referring to the u_uint to u_short change, then you are wrong, see below. > port address was rare except for 8-bit isa ports "on the motherboard" > and has become rarer with FreeBSD's runtime configuration becoming > even more excessive (so instead of "inb $N,%al", the code is normally > about 10 instructions for bus_space_read_1(sc->bst, sc->bsh, N1)). > >> Further, the unnecessary "cld" is removed from {in,out}s{b,w,l}(), >> because it is guaranteed by the ABI that the direction flag is >> cleared. All in all the code for in/out gets a bit simpler. > > kib@ already pointed out that the direction flag is not guaranteed to be > cleared in the kernel. For amd64, this may be a bug in the kernel, but > for i386 it is a bug in gcc say that the ABI specifies that the direction > flag is cleared, since there is no standard i386 ABI so gcc must not > assume that the direction flag is clear, like it has done until recently. There *is* an ABI spec for i386 and it mandates that DF is cleared on function entry and exit. Also other compilers (e.g. LLVM and ICC) do not have this misbehaviour of GCC < 4.3 to emit cld before every string operation at all. I would not trust GCC < 4.3 to do this correctly everywhere either. > There are lots more similar cld's in bus.h. > > % Index: sys/i386/include/cpufunc.h > % =================================================================== > % --- sys/i386/include/cpufunc.h (Revision 190841) > % +++ sys/i386/include/cpufunc.h (Arbeitskopie) > % @@ -170,177 +170,97 @@ > % __asm __volatile("hlt"); > % } > % % -#if !defined(__GNUCLIKE_BUILTIN_CONSTANT_P) || __GNUCLIKE_ASM < 3 > % - > % -#define inb(port) inbv(port) > % -#define outb(port, data) outbv(port, data) > % - > % -#else /* __GNUCLIKE_BUILTIN_CONSTANT_P && __GNUCLIKE_ASM >= 3 */ > > The ifdefs are ugly, and this one seems to have been slightly wrong, but > they provide documentation aboout the features used: > - __GNUCLIKE_BUILTIN_CONSTANT_P: no longer needed > - __GNUCLIKE_ASM >= 3: to ensure that the "i" constraint is available. > This used to be __GNUC__ >= 2. If that was correct then >= 3 is > stricter than necessary; otherwise >= 2 was not as strict as it > should have been, since some versions of gcc-2 certainly supported > the "i" constraint. > > A precise translation of the above would be __GNU_PREREQ__(maj, min) || > defined(__INTEL_COMPILER), where (maj, min) is the version of gcc that > implemented the "N" constraint and you should check that the Intel > compiler (all version?) support the "N" constraint. This is unnecessary, even GCC 2.95 (10 years old, the oldest release you can get from official sources) supports this constraint (gcc-2.95/gcc/config/i386/i386.h, line 932). This shows how old and stale this hack is. > % - * The unnecessary test `(port) < 0x10000' is to generate a warning if > % - * the `port' has type u_short or smaller. Such types are pessimal. > % - * This actually only works for signed types. The range check is > % - * careful to avoid generating warnings. > > This won't work any more, if it ever did. I think it only worked for > the constant case, but for the constant case the width doesn't really > matter. The use of u_short for the port enables the compiler to generate a warning for too large port numbers. > % -static __inline u_char > % -inbc(u_int port) > % +static inline u_char > % +inb(u_short port) > > __inline should be globabally changed to inline someday, not starting here. > Plain inline has been Standard for 10 years now, but it still isn't > standard -- we're still waiting for gcc to implement C99, and haven't > switched to gcc-4.3(?) or later which will implement C99 extern inline. This very file already uses "inline" in other places. > Changing the type changes the API and breaks an optimization. Callers It does not change the API, it corrects it: Passing a port number > 0xFFFF never worked and the API now reflects this. So if now accidently a too large constant port number is passed, the compiler can warn. It's a static inline function, so there is no problem with the ABI. About optimization see below. > are supposed to provide an arg of width 32 so that it can be loaded > as efficiently as possible (instruction prefixes and/or sign extension > waste code space and time, mainly on old CPUs). The 0x10000 check > referred to in the above comment attempts to enforce this. Casting > down in the API prevents the 32-bit loads. When specifying 16 bit input the compiler is perfectly allowed to leave arbitrary garbage in the upper 16 bits, e.g. do a 32bit load of the port. Lying about this fact leads to worse code, example: static inline unsigned char inb(unsigned short port) /* ALT: static inline unsigned char inb(unsigned int port) */ { unsigned char data; asm volatile("inb %1, %0" : "=a" (data) : "d" (port)); /* ALT: asm volatile("inb %w1, %0" : "=a" (data) : "d" (port)); */ return data; } unsigned short in2(unsigned short port) { unsigned short res; res = inb(port) << 8; res |= inb(++port); return res; } diff of the assember of the two versions: --- in_short.s 2009-04-10 07:54:10.000000000 +0200 +++ in_int.s 2009-04-10 07:54:48.000000000 +0200 @@ -4,17 +4,22 @@ .globl in2 .type in2, @function in2: - movzwl 4(%esp), %edx + pushl %ebx + movzwl 8(%esp), %ebx + movzwl %bx, %eax + movl %eax, %edx #APP inb %dx, %al #NO_APP movl %eax, %ecx - addl $1, %edx + leal 1(%ebx), %edx sall $8, %ecx + movzwl %dx, %edx #APP inb %dx, %al #NO_APP movzbl %al, %edx + popl %ebx orl %edx, %ecx movzwl %cx, %eax ret Compilers are way better today than back in the GCC 1.x times. Lying to them to trick them to show a certain behaviour usually is a bad idea and tends to backfire. > % { > % - u_char data; > % - > % - __asm __volatile("inb %1,%0" : "=a" (data) : "id" > ((u_short)(port))); > > The port address was already cast down here in inbc(). This seems to > have been just because I didn't know gnu asm very well when I wrote > the above. The cast has no effect in the usual case where the "i" > constraint is used, but when the "d" constraint is used (only when > compiling with -O0?) %1 would be %edx without the cast. In inbv(), I > hard-code %dx, but that does't work here "i" case. The correct method > seems to be to use %w1 in both places (keep u_int port everywhere and > use the same method for the "N" constraint). The correct way to handle this is discussed above. > % - return (data); > % + u_char data; > % + __asm volatile("inb %1, %0" : "=a" (data) : "Nd" (port)); > % + return data; > % } > > Style breakages: > - lost blank line after declarations. This file followed the rule about > this except for previous breakage. It even followed it in some cases > where the declarations are null. > - lost parentheses around return value. This file followed the rule about > this in all cases. Anachronisms. > Style not-quite-fix: > - lost the tab after the type in the declaration. In KNF, such a tab is > not used for auto declarations. However, this file was fairly consistent > about breaking the rule. > > Why change __volatile to volatile? This is similar to changing __inline > to inline, except plain volatile is more standard. has You answered this by yourself: volatile is a standard word - there is no reason to not use this. > ifdef tangles which are supposed to allow users or cdefs.h itself to > define away volatile so as to support old compilers, and we use __volatile > instead of volatile a lot to support this. This is probably not needed > for kernel headers. However, cpufunc.h is sometimes abused in userland. "Old compilers" cannot compile the FreeBSD source anyway, so what's your point? This file can only be used with "new" (not older than a decade or so) and very GCC-compatible compilers. > Fixed version (change nothing except the function name, %1, and the > constraint): > > %%% > static __inline u_char > inb(u_int port) > { > u_char data; > > __asm __volatile("inb %w1, %0" : "=a" (data) : "Nd" (port)); > return (data); > } > %%% > > Similarly for the other functions. > > BTW, I sometimes missing having the inverse of %[bwl...] -- a way to > generate an operand size letter from the type. gcc-3 and gcc-4 have > some horribly incomplete support for this. > > % -#endif /* __GNUCLIKE_BUILTIN_CONSTANT_P && __GNUCLIKE_ASM >= 3*/ > > Removing this accidentally fixes >= 2 style bugs in it. > > % -static __inline u_char > % -inbv(u_int port) > % -{ > % - u_char data; > % - /* > % - * We use %%dx and not %1 here because i/o is done at %dx and not at > % - * %edx, while gcc generates inferior code (movw instead of movl) > % - * if we tell it to load (u_short) port. > % - */ > > Lost this documentation. Now the magic in my version is in %w in my > version. > The comment shouldn't blame gcc for generating movw -- that is the > programmer's fault. This is wrong, it's correct to specify a 16bit input. The compiler therefore is perfectly allowed to leave arbitrary garbage in the upper 16 bits, e.g. do a 32bit load of the port and other things, see above. Also GCC does not generate movw here - for neither u_short nor u_int. GCC avoids partial register updates. > gcc on modern machines now generates movswl for loading a u_short port > to the u_int port specified by the old API, and movswl is fast on modern > machines, so there is no penalty in using the old API/implementation > on modern machines even if the caller neglected to start with a u_int > port. There is a penalty, see example above. > % ... > % -static __inline void > % -insb(u_int port, void *addr, size_t cnt) > % +static inline void > % +insw(u_short port, void *addr, size_t cnt) > % { > % - __asm __volatile("cld; rep; insb" > % - : "+D" (addr), "+c" (cnt) > % - : "d" (port) > % - : "memory"); > % + __asm volatile("rep; insw" > % + : "+D" (addr), "+c" (cnt) > % + : "d" (port) > % + : "memory"); > % } > > The diffs are hard to read, apparently due to diff getting confused > by your API and style changes and comparing unrelated functions. > Without the API changes, I think it would have matched insb with insb, > etc. > > % -static __inline void > % -outbv(u_int port, u_char data) > % +static inline void > % +outb(u_short port, u_char data) > % { > % - u_char al; > % - /* > % - * Use an unnecessary assignment to help gcc's register allocator. > % - * This make a large difference for gcc-1.40 and a tiny difference > % - * for gcc-2.6.0. For gcc-1.40, al had to be ``asm("ax")'' for > % - * best results. gcc-2.6.0 can't handle this. > % - */ > % - al = data; > > This can go of course. I saw dummy assignments bogusly helping the > allocator in more complicated asms for a version of atomic_cmpset() > as late as gcc-3, but that seemed to be fixed by gcc-3.3. > > % Index: sys/i386/i386/machdep.c > % =================================================================== > % --- sys/i386/i386/machdep.c (Revision 190841) > % +++ sys/i386/i386/machdep.c (Arbeitskopie) > % @@ -3555,45 +3555,24 @@ > % #ifdef KDB > % % /* > % - * Provide inb() and outb() as functions. They are normally only > % - * available as macros calling inlined functions, thus cannot be > % - * called from the debugger. > % - * > % - * The actual code is stolen from , and de-inlined. > % + * Provide inb() and outb() as functions. They are normally only > available as > % + * inline functions, thus cannot be called from the debugger. > % */ > > This should have been implemented by using cpufunc.h instead of repeating > it, and for everything in cpufunc.h not just inb and outb, e.g., as is > done for everything in atomic.h. This gives a technical reason for > using __inline -- we want to #undef it and shouldn't #undef a standard > keyword. You can neither #undef __inline nor inline, they both are keywords, not macros. Actually it's the other way round: There is no way to get rid of __inline, it is always a keyword to GCC. But you can tell GCC to not consider inline as keyword (-std=c89). > % % -#undef inb > % -#undef outb > % - > % /* silence compiler warnings */ > % -u_char inb(u_int); > % -void outb(u_int, u_char); > % +u_char inb_(u_short); > % +void outb_(u_short, u_char); > % % u_char > % -inb(u_int port) > % +inb_(u_short port) > % { > % - u_char data; > % - /* > % - * We use %%dx and not %1 here because i/o is done at %dx and not at > % - * %edx, while gcc generates inferior code (movw instead of movl) > % - * if we tell it to load (u_short) port. > % - */ > % - __asm __volatile("inb %%dx,%0" : "=a" (data) : "d" (port)); > % - return (data); > % + return inb(port); > % } > % % void > % -outb(u_int port, u_char data) > % +outb_(u_short port, u_char data) > % { > % - u_char al; > % - /* > % - * Use an unnecessary assignment to help gcc's register allocator. > % - * This make a large difference for gcc-1.40 and a tiny difference > % - * for gcc-2.6.0. For gcc-1.40, al had to be ``asm("ax")'' for > % - * best results. gcc-2.6.0 can't handle this. > % - */ > % - al = data; > % - __asm __volatile("outb %0,%%dx" : : "a" (al), "d" (port)); > % + outb(port, data); > % } > % % #endif /* KDB */ > > This changes the (ddb undocumented) API and ABI to worse ones. I > already don't line having to type "call inb(foo)" (in my x86 debugger, > inb is a command named "i", with certain space insensitivity that > allows typing "ifoo"). The "worse" aspect is discussed above. I also changed the non-existent documentation of these functions, so the name change should be fine. (: Christoph From owner-freebsd-i386@FreeBSD.ORG Fri Apr 10 12:54:42 2009 Return-Path: Delivered-To: freebsd-i386@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC1771065670; Fri, 10 Apr 2009 12:54:42 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by mx1.freebsd.org (Postfix) with ESMTP id 3C4BB8FC27; Fri, 10 Apr 2009 12:54:42 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-107-120-227.carlnfd1.nsw.optusnet.com.au [122.107.120.227]) by mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n3ACsbK8012516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Apr 2009 22:54:38 +1000 Date: Fri, 10 Apr 2009 22:54:37 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Christoph Mallon In-Reply-To: <49DF16BA.8000807@gmx.de> Message-ID: <20090410200612.I2103@besplex.bde.org> References: <49DD01CA.3040900@gmx.de> <20090410001919.S1567@besplex.bde.org> <49DF16BA.8000807@gmx.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Ed Schouten , freebsd-amd64@FreeBSD.org, freebsd-i386@FreeBSD.org Subject: Re: [PATCH] Simplify in*() and out*() functions of AMD64 and i386 X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 12:54:43 -0000 On Fri, 10 Apr 2009, Christoph Mallon wrote: > Bruce Evans schrieb: >> On Wed, 8 Apr 2009, Christoph Mallon wrote: >>> Also the {in,out}{w,l}() get treated with this constraint. They had no >>> special case before, so now better code is generated for them. >> >> Actually, worse code is generated for them on most cases since the >> optimization of loading 32 bits for the usual case of a non-constant >> operand is lost in your version -- see below. The case of a constant > > If you are referring to the u_uint to u_short change, then you are > wrong, see below. No, you are wrong. See below in previous and this mail. >> kib@ already pointed out that the direction flag is not guaranteed to be >> cleared in the kernel. For amd64, this may be a bug in the kernel, but >> for i386 it is a bug in gcc say that the ABI specifies that the direction >> flag is cleared, since there is no standard i386 ABI so gcc must not >> assume that the direction flag is clear, like it has done until recently. > > There *is* an ABI spec for i386 and it mandates that DF is cleared on > function entry and exit. Also other compilers (e.g. LLVM and > ICC) do not have this misbehaviour of GCC < 4.3 to emit cld before every > string operation at all. I would not trust GCC < 4.3 to do this > correctly everywhere either. Anyone can make up a spec but no one has to follow it. FreeBSD has always followed the old de-facto spec that requires any code that uses string operations to set the direction flag for itself. Trying to change this after about 1990 is especially stupid since string instructions should almost never be used due to their becoming relatively even slower without even counting their large setup overhead. Their setup overhead includes the cld but should be large enough to do the cld in parallel so that it is almost free. >> % % -#if !defined(__GNUCLIKE_BUILTIN_CONSTANT_P) || __GNUCLIKE_ASM < 3 >> % - >> % -#define inb(port) inbv(port) >> % -#define outb(port, data) outbv(port, data) >> % - >> % -#else /* __GNUCLIKE_BUILTIN_CONSTANT_P && __GNUCLIKE_ASM >= 3 */ >> >> The ifdefs are ugly, and this one seems to have been slightly wrong, but >> they provide documentation aboout the features used: >> - __GNUCLIKE_BUILTIN_CONSTANT_P: no longer needed >> - __GNUCLIKE_ASM >= 3: to ensure that the "i" constraint is available. >> This used to be __GNUC__ >= 2. If that was correct then >= 3 is >> stricter than necessary; otherwise >= 2 was not as strict as it >> should have been, since some versions of gcc-2 certainly supported >> the "i" constraint. >> >> A precise translation of the above would be __GNU_PREREQ__(maj, min) || >> defined(__INTEL_COMPILER), where (maj, min) is the version of gcc that >> implemented the "N" constraint and you should check that the Intel >> compiler (all version?) support the "N" constraint. > > This is unnecessary, even GCC 2.95 (10 years old, the oldest release you can > get from official sources) supports this constraint > (gcc-2.95/gcc/config/i386/i386.h, line 932). This shows how old and stale > this hack is. I just want it pointed out (in the commit log) and in a separate commit that you are intentionally weakening the ifdefs since old compilers are not supported even to the extent of not generating syntax errors for them and most other places (e.g., atomic.h) already assume a non-old compiler and generate the syntax errors for old ones. >> % - * The unnecessary test `(port) < 0x10000' is to generate a warning if >> % - * the `port' has type u_short or smaller. Such types are pessimal. >> % - * This actually only works for signed types. The range check is >> % - * careful to avoid generating warnings. >> >> This won't work any more, if it ever did. I think it only worked for >> the constant case, but for the constant case the width doesn't really >> matter. > > The use of u_short for the port enables the compiler to generate a warning > for too large port numbers. Only if it warns for truncation on assignment, which most compilers won't do. >> % -static __inline u_char >> % -inbc(u_int port) >> % +static inline u_char >> % +inb(u_short port) >> >> __inline should be globabally changed to inline someday, not starting here. >> Plain inline has been Standard for 10 years now, but it still isn't >> standard -- we're still waiting for gcc to implement C99, and haven't >> switched to gcc-4.3(?) or later which will implement C99 extern inline. > > This very file already uses "inline" in other places. Only in recent style breakage in 2 places when I wasn't looking (18-Apr-08 for cpu_monitor() and cpu_wait()). Other style breakage for these functions: - insertion sort errors. This file is supposed to be sorted on function name - namespace errors. Functions in this file should have the same name as the instruction that they provided access too. monitor() is a bit too generic for this and wait() is much too generic for this (however, the instruction name is mwait() which is less generic than monitor()), so some renaming is required. The renaming should not be into the cpu_* namespace since the cpu_ prefix has a different, precise meaning. These bugs are missing for the older interface to the "pause" instruction: - pause() is too generic, so the cpufunc is named ia32_pause() on i386, etc. (but I prefer mdpause()). - pause() was already in use, so even the MI interface couldn't be named pause(). It is named cpu_spinwait(). - cpu_spinwait() is implemented as a macro that invokes ia32_pause(). - bogus semicolon at the end of the main asm string - missing space after ": :" (2 instances) - missing space after just 1 of the 4 constraint strings. - missing declarations in the non-__GNUCLIKE_ASM && non-__CC_SUPPORTS___INLINE case. Hmm, your change from __inline to inline also bogotifies the __CC_SUPPORTS___INLINE ifdef. This ifdef is careful to a fault, but not wrong provided __inline is used consistently. >> Changing the type changes the API and breaks an optimization. Callers > > It does not change the API, it corrects it: Passing a port number > 0xFFFF > never worked and the API now reflects this. So if now accidently a too large > constant port number is passed, the compiler can warn. It's a static inline > function, so there is no problem with the ABI. About optimization see below. No, it breaks it. I define the API so I know what it is! The caller should pass a u_int port so that optimal code is generated (at a tiny cost to data space for storing 32-bit port numbers in softcs). The hardware only uses the low 16 bits so the upper 16 bits don't matter. If the caller starts with a u_short port, then the API generates sub-optimal code to promote to a u_int. The promotion logically occurs as part of the function call protocol, but since the function is inline it normally occurs more directly (e.g., as "movswl port,%edx"). >> are supposed to provide an arg of width 32 so that it can be loaded >> as efficiently as possible (instruction prefixes and/or sign extension >> waste code space and time, mainly on old CPUs). The 0x10000 check >> referred to in the above comment attempts to enforce this. Casting >> down in the API prevents the 32-bit loads. > > When specifying 16 bit input the compiler is perfectly allowed to leave > arbitrary garbage in the upper 16 bits, e.g. do a 32bit load of the > port. Lying about this fact leads to worse code, example: It is only permitted to do that if it knows that the the upper 16 bits are in an object, or if they are in a register. While it could know that bits in an object (say for port = sc->sc_port where sc has stuff above sc_port so that the bits are in the object (*sc)), I've never seen gcc do this optimization. I didn't lie to the compiler, but told it to load all 32 bits of %edx. Then I ignore the top 16 bits in the asm. > static inline unsigned char inb(unsigned short port) > /* ALT: static inline unsigned char inb(unsigned int port) */ > { > unsigned char data; > asm volatile("inb %1, %0" : "=a" (data) : "d" (port)); > /* ALT: asm volatile("inb %w1, %0" : "=a" (data) : "d" (port)); */ > return data; > } > > unsigned short in2(unsigned short port) > { > unsigned short res; > res = inb(port) << 8; > res |= inb(++port); > return res; > } Sure, this gives suboptimal code for ALT since `port' starts in a u_short. Try starting with a matching ALT for in2: in2(unsigned port). The types must match at all levels including in2()'s caller to avoid promoting and demoting back and forth. Only some of the conversions can be free. ++port involves various conversions if port is not u_int throughout. The compiler can usually optimize these (by keeping port in a register and ignoring top bits). > diff of the assember of the two versions: > --- in_short.s 2009-04-10 07:54:10.000000000 +0200 > +++ in_int.s 2009-04-10 07:54:48.000000000 +0200 > @@ -4,17 +4,22 @@ > .globl in2 > .type in2, @function > in2: > - movzwl 4(%esp), %edx With my ALT in2 version: movl 4(%esp), %edx. This is 3-4 cycles faster than on i386 and i486. On modern CPUs, there is probably no difference, but movzwl wastes a byte or two of instruction space so it might cost in some cases. > + pushl %ebx > + movzwl 8(%esp), %ebx > + movzwl %bx, %eax > + movl %eax, %edx This is unnecessarily stupid code. Why not identical code to the u_int case? Leaving out the inb(++port) gives identical code for the first inb(). > #APP > inb %dx, %al > #NO_APP > movl %eax, %ecx > - addl $1, %edx > + leal 1(%ebx), %edx The compiler is being stupid above so that it can be stupid here too (leal is slightly worse than addl). It should just use %edx and not take a trip through %ebx and %eax, and have to save %ebx. > sall $8, %ecx > + movzwl %dx, %edx This is needed for ++port since it has to demote the intermediate u_int in ++port back to u_short. > #APP > inb %dx, %al > #NO_APP > movzbl %al, %edx > + popl %ebx > orl %edx, %ecx > movzwl %cx, %eax > ret With u_ints throughout (ALT for inb() and in2()), there are no conversions and the generated code is optimal (movl instead of movzwl and no other differences). With the only conversion being a demotion in inb() (non-ALT for inb() and ALT for in2()), the generated code is again optimal (movl instead of movzwl). gcc is optimizing away the conversion in this case. With port replaced by portarray[0] where portarray[1] exists, gcc no longer does the optimization. This is with gcc-4.2 with the default (usually wrong) arch. gcc-3.3 and gcc-4.2 -march=i386 give the original pessimization of using movw instead of movzwl to load a 16-bit object into a 16 or 32-bit register. When only 16 bits are needed gcc-old just uses movw. When a promotion is needed in the ALT in2(), it uses movw to %bx where the above uses movzwl to %ebx. Then it must promote %bx and it uses movzwl to %eax for this, then it moves to %edx. This is sub-optimal but not as silly as the above -- the above has already done the promotion into %ebx and then it does it again into %eax. > Compilers are way better today than back in the GCC 1.x times. Lying to > them to trick them to show a certain behaviour usually is a bad idea and > tends to backfire. Apparently gcc is still stupid when there are just a 4 not-quite null promotions and demotions: for u_short port; use((u_int)port); /* ALT inb(port); */ port = (u_short)((u_int)port + 1); /* ++port; */ use((u_int)port); /* ALT inb(port); */ >> % { >> % - u_char data; >> % - >> % - __asm __volatile("inb %1,%0" : "=a" (data) : "id" >> ((u_short)(port))); >> >> The port address was already cast down here in inbc(). This seems to >> have been just because I didn't know gnu asm very well when I wrote >> the above. The cast has no effect in the usual case where the "i" >> constraint is used, but when the "d" constraint is used (only when >> compiling with -O0?) %1 would be %edx without the cast. In inbv(), I >> hard-code %dx, but that does't work here "i" case. The correct method >> seems to be to use %w1 in both places (keep u_int port everywhere and >> use the same method for the "N" constraint). > > The correct way to handle this is discussed above. No, this gives movzwl instead of movl in some cases and movw instead of movl in some other cases. >> % - return (data); >> % + u_char data; >> % + __asm volatile("inb %1, %0" : "=a" (data) : "Nd" (port)); >> % + return data; >> % } >> >> Style breakages: >> - lost blank line after declarations. This file followed the rule about >> this except for previous breakage. It even followed it in some cases >> where the declarations are null. >> - lost parentheses around return value. This file followed the rule about >> this in all cases. > > Anachronisms. No, standard in FreeBSD. >> Style not-quite-fix: >> - lost the tab after the type in the declaration. In KNF, such a tab is >> not used for auto declarations. However, this file was fairly consistent >> about breaking the rule. >> >> Why change __volatile to volatile? This is similar to changing __inline >> to inline, except plain volatile is more standard. has > > You answered this by yourself: volatile is a standard word - there is no > reason to not use this. It is for stylistic reasons. Readers will wonder why most code uses __volatile and yours doesn't. >> ifdef tangles which are supposed to allow users or cdefs.h itself to >> define away volatile so as to support old compilers, and we use __volatile >> instead of volatile a lot to support this. This is probably not needed >> for kernel headers. However, cpufunc.h is sometimes abused in userland. > > "Old compilers" cannot compile the FreeBSD source anyway, so what's your > point? This file can only be used with "new" (not older than a decade or so) > and very GCC-compatible compilers. The sources should be as independent of compiler versions as possible. cpufunc.h was independent (it is supposed contain only prototypes only for compilers that can't handle its asms), so why break it? >> % -static __inline u_char >> % -inbv(u_int port) >> % -{ >> % - u_char data; >> % - /* >> % - * We use %%dx and not %1 here because i/o is done at %dx and not at >> % - * %edx, while gcc generates inferior code (movw instead of movl) >> % - * if we tell it to load (u_short) port. >> % - */ >> >> Lost this documentation. Now the magic in my version is in %w in my >> version. >> The comment shouldn't blame gcc for generating movw -- that is the >> programmer's fault. > > This is wrong, it's correct to specify a 16bit input. The compiler therefore > is perfectly allowed to leave arbitrary garbage in the upper 16 bits, e.g. do > a 32bit load of the port and other things, see above. Also GCC does not > generate movw here - for neither u_short nor u_int. GCC avoids partial > register updates. No, this is correct. Please allow me to find bugs in my own comment :-). The comment would need to be too long, like this mail, to give all the details and I apparently broke it trying to make it shorter. It is correct but sub-optimal to specify a 16-bit input. Whether gcc generates a movw is now very machine-dependent. When the code and comment was written, gcc always generated movw for memory to register 16-bit loads. Now it prefers to generate movzwl since partial register updates are bad and movzwl is now fast, but it still generates movw for old CPUs. My optimization was not to avoid partial register updates, but just to avoid operand size prefixes for loading u_shorts and extra instructions for conversions in expressions like port+1 and use(foo) (where use() takes a u_int)). Your examples show that compilers now avoid the prefixes or conversions in some but not all of the cases. >> % Index: sys/i386/i386/machdep.c >> % =================================================================== >> % --- sys/i386/i386/machdep.c (Revision 190841) >> % +++ sys/i386/i386/machdep.c (Arbeitskopie) >> % @@ -3555,45 +3555,24 @@ >> % #ifdef KDB >> % % /* >> % - * Provide inb() and outb() as functions. They are normally only >> % - * available as macros calling inlined functions, thus cannot be >> % - * called from the debugger. >> % - * >> % - * The actual code is stolen from , and de-inlined. >> % + * Provide inb() and outb() as functions. They are normally only >> available as >> % + * inline functions, thus cannot be called from the debugger. >> % */ >> >> This should have been implemented by using cpufunc.h instead of repeating >> it, and for everything in cpufunc.h not just inb and outb, e.g., as is >> done for everything in atomic.h. This gives a technical reason for >> using __inline -- we want to #undef it and shouldn't #undef a standard >> keyword. > > You can neither #undef __inline nor inline, they both are keywords, not > macros. Actually it's the other way round: There is no way to get rid of > __inline, it is always a keyword to GCC. But you can tell GCC to not consider > inline as keyword (-std=c89). Oops, I should have written "#define away" instead of #undef. I think it is legal in C to #define any identifer. It just might things by giving inconsistencies. already defines away __inline in some cases (mostly for old compilers) and defines it to plain inline for the C++ case even for new gcc. The u_short optimizations are mostly moot for inb() etc. The hardware part of inb() now normally takes a few thousand times longer than the whole 1 cycle potentially saved by these optimizations. When inb() was written, the hardware part took less than one hundred times longer. I defend the optimization mainly because losing it is a regression and I still hate APIs that use chars and shorts (or [u]intN_t's) to give pessimizations by maximizing conversions. Bruce From owner-freebsd-i386@FreeBSD.ORG Fri Apr 10 22:40:02 2009 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04F6F1065673 for ; Fri, 10 Apr 2009 22:40:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D37BA8FC12 for ; Fri, 10 Apr 2009 22:40:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n3AMe12R047989 for ; Fri, 10 Apr 2009 22:40:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n3AMe1rY047988; Fri, 10 Apr 2009 22:40:01 GMT (envelope-from gnats) Resent-Date: Fri, 10 Apr 2009 22:40:01 GMT Resent-Message-Id: <200904102240.n3AMe1rY047988@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-i386@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Abramo Bagnara Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42DAD10656CE for ; Fri, 10 Apr 2009 22:36:05 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21]) by mx1.freebsd.org (Postfix) with ESMTP id 15AA28FC0C for ; Fri, 10 Apr 2009 22:36:05 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from www.freebsd.org (localhost [127.0.0.1]) by www.freebsd.org (8.14.3/8.14.3) with ESMTP id n3AMa4B5080329 for ; Fri, 10 Apr 2009 22:36:04 GMT (envelope-from nobody@www.freebsd.org) Received: (from nobody@localhost) by www.freebsd.org (8.14.3/8.14.3/Submit) id n3AMa4tT080326; Fri, 10 Apr 2009 22:36:04 GMT (envelope-from nobody) Message-Id: <200904102236.n3AMa4tT080326@www.freebsd.org> Date: Fri, 10 Apr 2009 22:36:04 GMT From: Abramo Bagnara To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: i386/133583: fma does not respect rounding mode using extended precision X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 22:40:02 -0000 >Number: 133583 >Category: i386 >Synopsis: fma does not respect rounding mode using extended precision >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-i386 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Apr 10 22:40:01 UTC 2009 >Closed-Date: >Last-Modified: >Originator: Abramo Bagnara >Release: 7.1 >Organization: >Environment: FreeBSD freebsd.homenet.telecomitalia.it 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 14:37:25 UTC 2009 root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 >Description: After fpsetprec(FP_PE) libc fma does not respect rounding mode. >How-To-Repeat: $ gcc bug.c -lm $ ./a.out Exact result: 9973859.79298831405913006165064871311187744140625 Default precision, DOWNWARD +* : 9973859.79298831336200237274169921875 Default precision, UPWARD +* : 9973859.79298831522464752197265625 Default precision, DOWNWARD fma: 9973859.79298831336200237274169921875 Default precision, UPWARD fma: 9973859.79298831522464752197265625 Extended precision, DOWNWARD +* : 9973859.79298831336200237274169921875 Extended precision, UPWARD +* : 9973859.79298831522464752197265625 Extended precision, DOWNWARD fma: 9973859.7929883114993572235107421875 Extended precision, UPWARD fma: 9973859.79298831336200237274169921875 >Fix: Patch attached with submission follows: #include #include #include #ifdef __FreeBSD__ #include #endif double to = 8248384; double x = 2871; double y = 601.00166944908187360852025449275970458984375; // Exact result is: 9973859.79298831405913006165064871311187744140625 int main() { printf("Exact result: 9973859.79298831405913006165064871311187744140625\n"); fesetround(FE_DOWNWARD); printf("Default precision, DOWNWARD +* : %.1000g\n", to + x * y); fesetround(FE_UPWARD); printf("Default precision, UPWARD +* : %.1000g\n", to + x * y); fesetround(FE_DOWNWARD); printf("Default precision, DOWNWARD fma: %.1000g\n", fma(x, y, to)); fesetround(FE_UPWARD); printf("Default precision, UPWARD fma: %.1000g\n", fma(x, y, to)); #ifdef __FreeBSD__ fpsetprec(FP_PE); fesetround(FE_DOWNWARD); printf("Extended precision, DOWNWARD +* : %.1000g\n", to + x * y); fesetround(FE_UPWARD); printf("Extended precision, UPWARD +* : %.1000g\n", to + x * y); fesetround(FE_DOWNWARD); printf("Extended precision, DOWNWARD fma: %.1000g\n", fma(x, y, to)); fesetround(FE_UPWARD); printf("Extended precision, UPWARD fma: %.1000g\n", fma(x, y, to)); #endif } >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-i386@FreeBSD.ORG Sat Apr 11 07:50:05 2009 Return-Path: Delivered-To: freebsd-i386@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD84E106564A for ; Sat, 11 Apr 2009 07:50:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7CBB68FC18 for ; Sat, 11 Apr 2009 07:50:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n3B7o5vh022504 for ; Sat, 11 Apr 2009 07:50:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n3B7o5sC022503; Sat, 11 Apr 2009 07:50:05 GMT (envelope-from gnats) Date: Sat, 11 Apr 2009 07:50:05 GMT Message-Id: <200904110750.n3B7o5sC022503@freefall.freebsd.org> To: freebsd-i386@FreeBSD.org From: Abramo Bagnara Cc: Subject: Re: i386/133583: fma does not respect rounding mode using extended precision X-BeenThere: freebsd-i386@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Abramo Bagnara List-Id: I386-specific issues for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 07:50:06 -0000 The following reply was made to PR i386/133583; it has been noted by GNATS. From: Abramo Bagnara To: bug-followup@FreeBSD.org, abramo.bagnara@gmail.com Cc: Subject: Re: i386/133583: fma does not respect rounding mode using extended precision Date: Sat, 11 Apr 2009 09:21:54 +0200 Unfortunately I've misread the problem report form, and the attached file is not the patch, but the C source that shows the bug.