From tinderbox at freebsd.org Sun Apr 5 11:30:40 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Apr 5 11:30:48 2009 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <20090405183036.138117302F@freebsd-current.sentex.ca> TB --- 2009-04-05 17:20:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-05 17:20:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2009-04-05 17:20:00 - cleaning the object tree TB --- 2009-04-05 17:21:10 - cvsupping the source tree TB --- 2009-04-05 17:21:10 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2009-04-05 17:21:17 - building world TB --- 2009-04-05 17:21:17 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-05 17:21:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-05 17:21:17 - TARGET=amd64 TB --- 2009-04-05 17:21:17 - TARGET_ARCH=amd64 TB --- 2009-04-05 17:21:17 - TZ=UTC TB --- 2009-04-05 17:21:17 - __MAKE_CONF=/dev/null TB --- 2009-04-05 17:21:17 - cd /src TB --- 2009-04-05 17:21:17 - /usr/bin/make -B buildworld >>> World build started on Sun Apr 5 17:21:20 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 [...] rm -f .depend mkdep -f .depend -a -DRESCUE /src/sbin/routed/rtquery/rtquery.c echo rtquery: /obj/amd64/src/tmp/usr/lib/libc.a /obj/amd64/src/tmp/usr/lib/libmd.a >> .depend cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/sbin/routed/if.c cc -O2 -pipe -DRESCUE -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/sbin/routed/input.c cc1: warnings being treated as errors /src/sbin/routed/input.c: In function 'ck_passwd': /src/sbin/routed/input.c:984: warning: format '%#x' expects type 'unsigned int', but argument 5 has type 'long unsigned int' *** Error code 1 Stop in /src/sbin/routed. *** Error code 1 Stop in /obj/amd64/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-05 18:30:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-05 18:30:35 - ERROR: failed to build world TB --- 2009-04-05 18:30:35 - 3245.27 user 338.72 system 4235.45 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From bugmaster at FreeBSD.org Mon Apr 6 04:06:51 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Apr 6 04:30:46 2009 Subject: Current problem reports assigned to freebsd-amd64@FreeBSD.org Message-ID: <200904061106.n36B6nBk061788@freefall.freebsd.org> 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 amd64/132574 amd64 [boot] Freeze on bootstrap loader (CD) using ATA/133 P o amd64/132170 amd64 7.1 kernel compilation problem o amd64/132019 amd64 [install] kernel trap 12 while installation o amd64/131906 amd64 [ata] SATA data corruption with Promise PDC20378 (amd6 o amd64/131456 amd64 ACPI & ATA problems o amd64/131314 amd64 [modules] [panic] large modules fail to load on amd64 o amd64/131209 amd64 [panic] [bce] 7.1-STABLE amd64 crash - m0 NULL f amd64/130885 amd64 sockstat(1) on amd64 does not work o amd64/130864 amd64 [hang] Problem with copying files to a large partition o amd64/130817 amd64 FreeBSD does not support HP DL160G5 [regression] o amd64/130494 amd64 [boot] netbooting BTX fails on amd64 o amd64/130483 amd64 [mxge] MSI must be disabled when Myricom 10Gbps Card i o amd64/130368 amd64 [hang] Switching from xorg to console locks up compute o amd64/129889 amd64 [boot] The booting process stops at the line mounting o amd64/129721 amd64 [hang] Motherboard K9N2G Neo-FD hangs on boot of 7.0-R o amd64/129667 amd64 [ata] Elitegroup A780GM-A IDE controller not recognize o amd64/129488 amd64 [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o amd64/129426 amd64 [panic] FreeBSD 7.0 crash after subdiskXX: detached o amd64/129315 amd64 [boot] amd64 motherboard: Intel DG965WH motherboard co f amd64/128978 amd64 [install] FreeBSD 6.3 64-bit panics at boot time duri o amd64/128810 amd64 AMD 64 port installation o amd64/128765 amd64 [install] Install CD loads to Install choices but stop o amd64/128686 amd64 [ata] can't detect SATA Disk on 8.0-Current with NF550 o amd64/128263 amd64 [panic] 2 amd64 dl380 g5 with dual quadcore xeons, 8 a o amd64/128259 amd64 csh(1): "`" crashes csh o amd64/127640 amd64 gcc(1) will not build shared libraries with -fprofile- o amd64/127492 amd64 [zfs] System hang on ZFS input-output o amd64/127484 amd64 [timecounters] Drift problem with FreeBSD 7.0 and 7.1 o amd64/127451 amd64 [scheduler] incorrect load on quad core o amd64/127397 amd64 [amd64] 32bit application on FreeBSD-6.3 amd64 gets SI s amd64/127276 amd64 ldd(1) invokes linux yes o amd64/127129 amd64 mdconfig(8) is core dumping with Segmentation Fault 11 o amd64/125873 amd64 [smbd] [panic] Repeated kernel panics, trap 12 page fa o amd64/125002 amd64 [install] amd64, SATA hard disks not detected o amd64/124432 amd64 [panic] 7.0-STABLE panic: invalbuf: dirty bufs o amd64/124134 amd64 [kernel] The kernel doesn't follow the calling convent o amd64/123562 amd64 [install] FreeBSD amd64 not installs o amd64/123520 amd64 [ahd] unable to boot from net while using ahd o amd64/123456 amd64 fstat(1): /usr/bin/fstat shows error messages and hang f amd64/123275 amd64 [cbb] [pcmcia] cbb/pcmcia drivers on amd64 failure [re o kern/122782 amd64 [modules] accf_http.ko kernel module is not loadable o amd64/122695 amd64 [cpufreq] Lack of cpufreq control using amd64 eith cor o amd64/122624 amd64 unusable minimal installation of FreeBSD-7.0 o amd64/122549 amd64 7.0-RELEASE-amd64-bootonly.iso doesn't work w/ serial o amd64/122468 amd64 Compile problems after upgrading to 7.0 o amd64/122174 amd64 [panic] 7.0 no longer includes "device atpic" so fails o amd64/121590 amd64 [est] [p4tcc] [acpi_perf] setting dev.cpu.0.freq somet o amd64/121439 amd64 [boot] Installation of FreeBSD 7.0 fails: ACPI problem o amd64/120202 amd64 [amd64] [patch] [panic] kernel panic at start_all_aps, o amd64/119591 amd64 [amd64] [patch] time_t on 64-bit architecture o amd64/117418 amd64 [hang] FreeBSD 6.2 crash on amd64 4400+ with ssh o amd64/117316 amd64 [acpi] ACPI lockups on SuperMicro motherboard o amd64/117296 amd64 [ata] I don`t see second SATA IDE on VIA VT8237A a amd64/117186 amd64 [modules] kldload Unsupported file type on STABLE amd6 s amd64/116689 amd64 [request] support for MSI K9MM-V o amd64/116620 amd64 [hang] ifconfig spins when creating carp(4) device on o amd64/116322 amd64 [panic] At start fsck on current, the system panics o amd64/116159 amd64 [panic] Panic while debugging on CURRENT s amd64/115815 amd64 [ata] [request] Gigabyte GA-M61P-S3 Motherboard unsupp o amd64/115581 amd64 [Makefile] [patch] -mfancy-math-387 has no effect o amd64/115194 amd64 LCD screen remains blank after Dell XPS M1210 lid is c o amd64/114270 amd64 [cpufreq] cpufreq doesnt work when compiled in to kern o amd64/114111 amd64 [nfs] System crashes while writing on NFS-mounted shar f amd64/113021 amd64 [re] ASUS M2A-VM onboard NIC does not work o amd64/112222 amd64 [libc] 32-bit libc incorrectly converts some FP number f amd64/111992 amd64 [boot] BTX failed - HP Laptop dv2315nr o amd64/110655 amd64 [threads] 32 bit threaded applications crash on amd64 o amd64/110599 amd64 [geli] geli attach to gmirror device hangs and cannot s amd64/108861 amd64 [nve] nve(4) driver on FreeBSD 6.2 AMD64 does not work o amd64/106186 amd64 [panic] panic in swap_pager_swap_init (amd64/smp/6.2-p f amd64/105629 amd64 [re] TrendNet TEG-BUSR 10/100/1000 disables itself on f amd64/105531 amd64 [ata] gigabyte GA-M51GM-S2G / nVidia nForce 430 - does f amd64/105514 amd64 [boot] FreeBSD/amd64 - Fails to boot on HP Pavilion dv o amd64/102716 amd64 ex with no argument in an xterm gets SIGSEGV o amd64/97337 amd64 [dri] xorg reboots system if dri module is enabled o amd64/95888 amd64 [ata] kernel: ad2: TIMEOUT - WRITE_DMA retrying on HP f amd64/94989 amd64 [boot] BTX Halts on Sun Fire X2100 w/6.1-BETA4 (amd64) o amd64/94677 amd64 [panic] panic in amd64 install at non-root user creati o amd64/93961 amd64 [busdma] Problem in bounce buffer handling in sys/amd6 o amd64/92337 amd64 [em] FreeBSD 6.0 Release Intel Pro 1000 MT em1 no buff f amd64/91492 amd64 [boot] BTX halted o amd64/91405 amd64 [asr] [panic] Kernel panic caused by asr on 6.0-amd64 o amd64/89501 amd64 [install] System crashes on install using ftp on local o amd64/88790 amd64 [panic] kernel panic on first boot (after the FreeBSD o amd64/88568 amd64 [panic] 6.0-RELEASE install cd does not boot with usb o amd64/87689 amd64 [powerd] [hang] powerd hangs SMP Opteron 244 5-STABLE o amd64/87316 amd64 [vge] "vge0 attach returned 6" on FreeBSD 6.0-RC1 amd6 o amd64/87305 amd64 [smp] Dual Opteron / FreeBSD 5 & 6 / powerd results in f amd64/87258 amd64 [smp] [boot] cannot boot with SMP and Areca ARC-1160 r f amd64/86080 amd64 [radeon] [hang] radeon DRI causes system hang on amd64 s amd64/85273 amd64 [install] FreeBSD (NetBSD or OpenBSD) not install on l o amd64/78406 amd64 [panic]AMD64 w/ SCSI: issue 'rm -r /usr/ports' and sys o amd64/76136 amd64 [hang] system halts before reboot o amd64/74747 amd64 [panic] System panic on shutdown when process will not f amd64/73322 amd64 [msdosfs] [hang] unarchiving /etc to msdosfs locks up 95 problems total. From christoph.mallon at gmx.de Wed Apr 8 13:25:05 2009 From: christoph.mallon at gmx.de (Christoph Mallon) Date: Wed Apr 8 13:36:56 2009 Subject: [PATCH] Simplify in*() and out*() functions of AMD64 and i386 Message-ID: <49DD01CA.3040900@gmx.de> 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 -------------- next part -------------- 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 */ From kostikbel at gmail.com Wed Apr 8 13:58:38 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Wed Apr 8 13:58:44 2009 Subject: [PATCH] Simplify in*() and out*() functions of AMD64 and i386 In-Reply-To: <49DD01CA.3040900@gmx.de> References: <49DD01CA.3040900@gmx.de> Message-ID: <20090408205831.GK3014@deviant.kiev.zoral.com.ua> 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-amd64/attachments/20090408/9cdfb231/attachment.pgp From brde at optusnet.com.au Thu Apr 9 11:54:11 2009 From: brde at optusnet.com.au (Bruce Evans) Date: Thu Apr 9 11:54:19 2009 Subject: [PATCH] Simplify in*() and out*() functions of AMD64 and i386 In-Reply-To: <49DD01CA.3040900@gmx.de> References: <49DD01CA.3040900@gmx.de> Message-ID: <20090410001919.S1567@besplex.bde.org> 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 info at hobury.com Thu Apr 9 09:10:06 2009 From: info at hobury.com (hobury) Date: Thu Apr 9 12:16:06 2009 Subject: amd64/133540: Cannot connect to ftp mirrors for 7.2 beta boot-only Message-ID: <200904091600.n39G0SJM006542@www.freebsd.org> >Number: 133540 >Category: amd64 >Synopsis: Cannot connect to ftp mirrors for 7.2 beta boot-only >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Apr 09 16:10:05 UTC 2009 >Closed-Date: >Last-Modified: >Originator: hobury >Release: 7.2 beta >Organization: hobury >Environment: Not applicable, but currently using FreeBSD 7.1 >Description: A boot-only of a 7.2 beta (announced 10 apr 2009) enters sysinstall as normal, but cannot connect to the ftp mirrors: leads to timeout. Possibly same issue for non-amd64 machines. A boot-only reinstall on same machines of 7.1 version works fine. Tried several mirrors from the ftp-list. >How-To-Repeat: Boot-only 64-bits 7.2 beta: sysinstall >Fix: >Release-Note: >Audit-Trail: >Unformatted: From tinderbox at freebsd.org Thu Apr 9 21:44:47 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu Apr 9 21:45:05 2009 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <20090410044444.3BB177302F@freebsd-current.sentex.ca> TB --- 2009-04-10 02:40:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-10 02:40:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2009-04-10 02:40:00 - cleaning the object tree TB --- 2009-04-10 02:41:26 - cvsupping the source tree TB --- 2009-04-10 02:41:26 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2009-04-10 02:41:37 - building world TB --- 2009-04-10 02:41:37 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-10 02:41:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-10 02:41:37 - TARGET=amd64 TB --- 2009-04-10 02:41:37 - TARGET_ARCH=amd64 TB --- 2009-04-10 02:41:37 - TZ=UTC TB --- 2009-04-10 02:41:37 - __MAKE_CONF=/dev/null TB --- 2009-04-10 02:41:37 - cd /src TB --- 2009-04-10 02:41:37 - /usr/bin/make -B buildworld >>> World build started on Fri Apr 10 02:41:38 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 >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Fri Apr 10 04:42:02 UTC 2009 TB --- 2009-04-10 04:42:02 - generating LINT kernel config TB --- 2009-04-10 04:42:02 - cd /src/sys/amd64/conf TB --- 2009-04-10 04:42:02 - /usr/bin/make -B LINT TB --- 2009-04-10 04:42:03 - building LINT kernel TB --- 2009-04-10 04:42:03 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-10 04:42:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-10 04:42:03 - TARGET=amd64 TB --- 2009-04-10 04:42:03 - TARGET_ARCH=amd64 TB --- 2009-04-10 04:42:03 - TZ=UTC TB --- 2009-04-10 04:42:03 - __MAKE_CONF=/dev/null TB --- 2009-04-10 04:42:03 - cd /src TB --- 2009-04-10 04:42:03 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Apr 10 04:42:03 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 [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/kern/serdev_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/libkern/iconv_converter_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/opencrypto/cryptodev_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/acpica/acpi_if.m -h rm -f .newdep /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O2 -frename-registers -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 -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -I/src/sys/contrib/opensolaris/compat -I/src/sys/dev/cxgb -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-ss e3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector cc: /src/sys/dev/ixgbe/ixgbe_82599.c: No such file or directory mkdep: compile failed *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-10 04:44:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-10 04:44:43 - ERROR: failed to build lint kernel TB --- 2009-04-10 04:44:43 - 5710.57 user 604.70 system 7483.45 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From christoph.mallon at gmx.de Fri Apr 10 02:52:01 2009 From: christoph.mallon at gmx.de (Christoph Mallon) Date: Fri Apr 10 02:52:07 2009 Subject: [PATCH] Simplify in*() and out*() functions of AMD64 and i386 In-Reply-To: <20090410001919.S1567@besplex.bde.org> References: <49DD01CA.3040900@gmx.de> <20090410001919.S1567@besplex.bde.org> Message-ID: <49DF16BA.8000807@gmx.de> 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 christoph.mallon at gmx.de Thu Apr 9 23:13:37 2009 From: christoph.mallon at gmx.de (Christoph Mallon) Date: Fri Apr 10 04:39:40 2009 Subject: [PATCH] Simplify in*() and out*() functions of AMD64 and i386 In-Reply-To: <20090408205831.GK3014@deviant.kiev.zoral.com.ua> References: <49DD01CA.3040900@gmx.de> <20090408205831.GK3014@deviant.kiev.zoral.com.ua> Message-ID: <49DEE38D.6050604@gmx.de> 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 brde at optusnet.com.au Fri Apr 10 05:54:43 2009 From: brde at optusnet.com.au (Bruce Evans) Date: Fri Apr 10 05:54:56 2009 Subject: [PATCH] Simplify in*() and out*() functions of AMD64 and i386 In-Reply-To: <49DF16BA.8000807@gmx.de> References: <49DD01CA.3040900@gmx.de> <20090410001919.S1567@besplex.bde.org> <49DF16BA.8000807@gmx.de> Message-ID: <20090410200612.I2103@besplex.bde.org> 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 linimon at FreeBSD.org Fri Apr 10 14:40:36 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Fri Apr 10 14:54:06 2009 Subject: misc/133540: Cannot connect to ftp mirrors for 7.2 beta boot-only Message-ID: <200904102140.n3ALeZDg069968@freefall.freebsd.org> Synopsis: Cannot connect to ftp mirrors for 7.2 beta boot-only Responsible-Changed-From-To: freebsd-amd64->freebsd-bugs Responsible-Changed-By: linimon Responsible-Changed-When: Fri Apr 10 21:39:51 UTC 2009 Responsible-Changed-Why: probably not amd64-specific. http://www.freebsd.org/cgi/query-pr.cgi?pr=133540 From jason.harmening at gmail.com Fri Apr 10 19:40:02 2009 From: jason.harmening at gmail.com (Jason Harmening) Date: Fri Apr 10 20:03:01 2009 Subject: amd64/133592: busdma incorrectly calculates bounce buffer requirements for userspace buffers Message-ID: <200904110237.n3B2bHvE015726@www.freebsd.org> >Number: 133592 >Category: amd64 >Synopsis: busdma incorrectly calculates bounce buffer requirements for userspace buffers >Confidential: no >Severity: non-critical >Priority: medium >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Apr 11 02:40:00 UTC 2009 >Closed-Date: >Last-Modified: >Originator: Jason Harmening >Release: 7.2-PRERELEASE >Organization: >Environment: FreeBSD CORONA 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #2: Sat Mar 21 00:30:34 CDT 2009 jason@CORONA:/usr/obj/usr/src/sys/CUSTOM amd64 >Description: The _bus_dmamap_load_buffer function in sys/amd64/amd64/busdma_machdep.c takes a pmap_t param indicating the address space of the buffer (NULL => KVA space). When calculating the number of bounce buffers to reserve, it always calls pmap_kextract() to get the physical address, when it should call pmap_extract() if pmap != NULL. The problem exists in both 7-STABLE and 8-CURRENT--the attached patch is against 7-STABLE. >How-To-Repeat: >Fix: Patch attached with submission follows: --- busdma_machdep.c.bkp 2009-04-10 21:27:51.000000000 -0500 +++ busdma_machdep.c 2009-04-10 21:30:58.000000000 -0500 @@ -602,7 +602,10 @@ vendaddr = (vm_offset_t)buf + buflen; while (vaddr < vendaddr) { - paddr = pmap_kextract(vaddr); + if (pmap) + paddr = pmap_extract(pmap, vaddr); + else + paddr = pmap_kextract(vaddr); if (run_filter(dmat, paddr) != 0) map->pagesneeded++; vaddr += PAGE_SIZE; >Release-Note: >Audit-Trail: >Unformatted: From scottl at samsco.org Sun Apr 12 08:20:07 2009 From: scottl at samsco.org (Scott Long) Date: Sun Apr 12 10:51:26 2009 Subject: amd64/133592: [busdma] [patch] busdma incorrectly calculates bounce buffer requirements for userspace buffers Message-ID: <200904121520.n3CFK6G8032035@freefall.freebsd.org> The following reply was made to PR amd64/133592; it has been noted by GNATS. From: Scott Long To: bug-followup@FreeBSD.org, jason.harmening@gmail.com Cc: Subject: Re: amd64/133592: [busdma] [patch] busdma incorrectly calculates bounce buffer requirements for userspace buffers Date: Sun, 12 Apr 2009 08:53:47 -0600 You're right, it's definitely a problem. The patch looks correct, feel free to commit to i386, amd64, and ia64. Arm needs a similar fix, but the code looks to be somewhat different. Scott From kostikbel at gmail.com Sun Apr 12 12:30:51 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Sun Apr 12 13:22:20 2009 Subject: amd64/133592: [busdma] [patch] busdma incorrectly calculates bounce buffer requirements for userspace buffers In-Reply-To: <200904121520.n3CFK6G8032035@freefall.freebsd.org> References: <200904121520.n3CFK6G8032035@freefall.freebsd.org> Message-ID: <20090412193044.GN3014@deviant.kiev.zoral.com.ua> On Sun, Apr 12, 2009 at 03:20:06PM +0000, Scott Long wrote: > The following reply was made to PR amd64/133592; it has been noted by GNATS. > > From: Scott Long > To: bug-followup@FreeBSD.org, jason.harmening@gmail.com > Cc: > Subject: Re: amd64/133592: [busdma] [patch] busdma incorrectly calculates > bounce buffer requirements for userspace buffers > Date: Sun, 12 Apr 2009 08:53:47 -0600 > > You're right, it's definitely a problem. The patch looks correct, feel > free to commit to i386, amd64, and ia64. Arm needs a similar fix, but > the code looks to be somewhat different. Below is updated patch. It was compile-tested on all affected arches. Scott, any notes ? diff --git a/sys/amd64/amd64/busdma_machdep.c b/sys/amd64/amd64/busdma_machdep.c index c50fcc3..de4717c 100644 --- a/sys/amd64/amd64/busdma_machdep.c +++ b/sys/amd64/amd64/busdma_machdep.c @@ -606,7 +606,10 @@ _bus_dmamap_load_buffer(bus_dma_tag_t dmat, vendaddr = (vm_offset_t)buf + buflen; while (vaddr < vendaddr) { - paddr = pmap_kextract(vaddr); + if (pmap) + paddr = pmap_extract(pmap, vaddr); + else + paddr = pmap_kextract(vaddr); if (run_filter(dmat, paddr) != 0) map->pagesneeded++; vaddr += (PAGE_SIZE - ((vm_offset_t)vaddr & PAGE_MASK)); diff --git a/sys/arm/arm/busdma_machdep.c b/sys/arm/arm/busdma_machdep.c index a738172..153d83f 100644 --- a/sys/arm/arm/busdma_machdep.c +++ b/sys/arm/arm/busdma_machdep.c @@ -669,8 +669,8 @@ bus_dmamem_free(bus_dma_tag_t dmat, void *vaddr, bus_dmamap_t map) } static int -_bus_dmamap_count_pages(bus_dma_tag_t dmat, bus_dmamap_t map, void *buf, - bus_size_t buflen, int flags) +_bus_dmamap_count_pages(bus_dma_tag_t dmat, bus_dmamap_t map, pmap_t pmap, + void *buf, bus_size_t buflen, int flags) { vm_offset_t vaddr; vm_offset_t vendaddr; @@ -689,7 +689,10 @@ _bus_dmamap_count_pages(bus_dma_tag_t dmat, bus_dmamap_t map, void *buf, vendaddr = (vm_offset_t)buf + buflen; while (vaddr < vendaddr) { - paddr = pmap_kextract(vaddr); + if (pmap != NULL) + paddr = pmap_extract(pmap, vaddr); + else + paddr = pmap_kextract(vaddr); if (((dmat->flags & BUS_DMA_COULD_BOUNCE) != 0) && run_filter(dmat, paddr) != 0) map->pagesneeded++; @@ -745,7 +748,8 @@ bus_dmamap_load_buffer(bus_dma_tag_t dmat, bus_dma_segment_t *segs, bmask = ~(dmat->boundary - 1); if ((dmat->flags & BUS_DMA_COULD_BOUNCE) != 0) { - error = _bus_dmamap_count_pages(dmat, map, buf, buflen, flags); + error = _bus_dmamap_count_pages(dmat, map, pmap, buf, buflen, + flags); if (error) return (error); } diff --git a/sys/i386/i386/busdma_machdep.c b/sys/i386/i386/busdma_machdep.c index d4aa9b5..cf0ac51 100644 --- a/sys/i386/i386/busdma_machdep.c +++ b/sys/i386/i386/busdma_machdep.c @@ -142,8 +142,8 @@ static bus_addr_t add_bounce_page(bus_dma_tag_t dmat, bus_dmamap_t map, vm_offset_t vaddr, bus_size_t size); static void free_bounce_page(bus_dma_tag_t dmat, struct bounce_page *bpage); int run_filter(bus_dma_tag_t dmat, bus_addr_t paddr); -int _bus_dmamap_count_pages(bus_dma_tag_t dmat, bus_dmamap_t map, void *buf, - bus_size_t buflen, int flags); +int _bus_dmamap_count_pages(bus_dma_tag_t dmat, bus_dmamap_t map, pmap_t pmap, + void *buf, bus_size_t buflen, int flags); #ifdef XEN #undef pmap_kextract @@ -577,8 +577,8 @@ bus_dmamem_free(bus_dma_tag_t dmat, void *vaddr, bus_dmamap_t map) } int -_bus_dmamap_count_pages(bus_dma_tag_t dmat, bus_dmamap_t map, void *buf, - bus_size_t buflen, int flags) +_bus_dmamap_count_pages(bus_dma_tag_t dmat, bus_dmamap_t map, pmap_t pmap, + void *buf, bus_size_t buflen, int flags) { vm_offset_t vaddr; vm_offset_t vendaddr; @@ -598,7 +598,10 @@ _bus_dmamap_count_pages(bus_dma_tag_t dmat, bus_dmamap_t map, void *buf, vendaddr = (vm_offset_t)buf + buflen; while (vaddr < vendaddr) { - paddr = pmap_kextract(vaddr); + if (pmap) + paddr = pmap_extract(pmap, vaddr); + else + paddr = pmap_kextract(vaddr); if (((dmat->flags & BUS_DMA_COULD_BOUNCE) != 0) && run_filter(dmat, paddr) != 0) { map->pagesneeded++; @@ -660,7 +663,7 @@ _bus_dmamap_load_buffer(bus_dma_tag_t dmat, map = &nobounce_dmamap; if ((dmat->flags & BUS_DMA_COULD_BOUNCE) != 0) { - error = _bus_dmamap_count_pages(dmat, map, buf, buflen, flags); + error = _bus_dmamap_count_pages(dmat, map, pmap, buf, buflen, flags); if (error) return (error); } diff --git a/sys/ia64/ia64/busdma_machdep.c b/sys/ia64/ia64/busdma_machdep.c index 659db52..609a8a9 100644 --- a/sys/ia64/ia64/busdma_machdep.c +++ b/sys/ia64/ia64/busdma_machdep.c @@ -527,7 +527,10 @@ _bus_dmamap_load_buffer(bus_dma_tag_t dmat, vendaddr = (vm_offset_t)buf + buflen; while (vaddr < vendaddr) { - paddr = pmap_kextract(vaddr); + if (pmap != NULL) + paddr = pmap_extract(pmap, vaddr); + else + paddr = pmap_kextract(vaddr); if (run_filter(dmat, paddr, 0) != 0) map->pagesneeded++; vaddr += PAGE_SIZE; -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-amd64/attachments/20090412/19a0e2b8/attachment.pgp From hadley at foxular.net Sun Apr 12 18:10:07 2009 From: hadley at foxular.net (Rob Bloom) Date: Sun Apr 12 18:57:21 2009 Subject: amd64/133676: umount -f'ing a vnode-based memory disk from off a SMB share caused a reboot Message-ID: <200904130106.n3D16edr008576@www.freebsd.org> >Number: 133676 >Category: amd64 >Synopsis: umount -f'ing a vnode-based memory disk from off a SMB share caused a reboot >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Apr 13 01:10:05 UTC 2009 >Closed-Date: >Last-Modified: >Originator: Rob Bloom >Release: 7.1-RELEASE-p1 >Organization: >Environment: FreeBSD goosebox.foxular.net 7.1-RELEASE-p1 FreeBSD 7.1-RELEASE-p1 #10: Wed Jan 7 23:33:58 EST 2009 root@goosebox.foxular.net:/usr/obj/usr/src/sys/GOOSEBOX amd64 >Description: I had at some point used mdconfig to mount an HD image (with the image on an SMB partition) with an msdos partition on it to /dev/md0. I came back a few days later, noticed the disk was still showing as mounted in df, but when I saw the directory was empty, I figured I must have detached the disk without unmounting first. (though while trying to reproduce the bug, this may not have been the case) I did "umount /mnt/dos" first, getting "umount of /mnt/dos failed: Bad file descriptor", and followed that up with "umount -f /mnt/dos", after which my system immediately rebooted. Here is the output from /var/log/messages: Apr 12 20:27:35 goosebox kernel: g_vfs_done():md0s1[READ(offset=512, length=4096)]error = 9 Apr 12 20:27:37 goosebox sudo: hadley : TTY=ttyp1 ; PWD=/mnt ; USER=root ; COMMAND=/sbin/umount dos Apr 12 20:27:37 goosebox kernel: g_vfs_done():md0s1[READ(offset=512, length=4096)]error = 9 Apr 12 20:27:38 goosebox sudo: hadley : TTY=ttyp1 ; PWD=/mnt ; USER=root ; COMMAND=/sbin/umount -f dos Apr 12 20:28:47 goosebox syslogd: kernel boot file is /boot/kernel/kernel >How-To-Repeat: Not quite sure... I know at the very least it involves creating a memory disk based off a disk image mounted over the network. It seems that maybe leaving the image mounted for a while and probably rebooting the machine the image is on at some point inbetween caused the disk image to no longer be locatable, causing the reboot when I unmounted it. >Fix: >Release-Note: >Audit-Trail: >Unformatted: From bugmaster at FreeBSD.org Mon Apr 13 04:06:51 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Apr 13 05:28:00 2009 Subject: Current problem reports assigned to freebsd-amd64@FreeBSD.org Message-ID: <200904131106.n3DB6mHR084854@freefall.freebsd.org> 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 amd64/133676 amd64 umount -f'ing a vnode-based memory disk from off a SMB o amd64/133592 amd64 [busdma] [patch] busdma incorrectly calculates bounce o amd64/132574 amd64 [boot] Freeze on bootstrap loader (CD) using ATA/133 P o amd64/132170 amd64 7.1 kernel compilation problem o amd64/132019 amd64 [install] kernel trap 12 while installation o amd64/131906 amd64 [ata] SATA data corruption with Promise PDC20378 (amd6 o amd64/131456 amd64 ACPI & ATA problems o amd64/131314 amd64 [modules] [panic] large modules fail to load on amd64 o amd64/131209 amd64 [panic] [bce] 7.1-STABLE amd64 crash - m0 NULL f amd64/130885 amd64 sockstat(1) on amd64 does not work o amd64/130864 amd64 [hang] Problem with copying files to a large partition o amd64/130817 amd64 FreeBSD does not support HP DL160G5 [regression] o amd64/130494 amd64 [boot] netbooting BTX fails on amd64 o amd64/130483 amd64 [mxge] MSI must be disabled when Myricom 10Gbps Card i o amd64/130368 amd64 [hang] Switching from xorg to console locks up compute o amd64/129889 amd64 [boot] The booting process stops at the line mounting o amd64/129721 amd64 [hang] Motherboard K9N2G Neo-FD hangs on boot of 7.0-R o amd64/129667 amd64 [ata] Elitegroup A780GM-A IDE controller not recognize o amd64/129488 amd64 [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o amd64/129426 amd64 [panic] FreeBSD 7.0 crash after subdiskXX: detached o amd64/129315 amd64 [boot] amd64 motherboard: Intel DG965WH motherboard co f amd64/128978 amd64 [install] FreeBSD 6.3 64-bit panics at boot time duri o amd64/128810 amd64 AMD 64 port installation o amd64/128765 amd64 [install] Install CD loads to Install choices but stop o amd64/128686 amd64 [ata] can't detect SATA Disk on 8.0-Current with NF550 o amd64/128263 amd64 [panic] 2 amd64 dl380 g5 with dual quadcore xeons, 8 a o amd64/128259 amd64 csh(1): "`" crashes csh o amd64/127640 amd64 gcc(1) will not build shared libraries with -fprofile- o amd64/127492 amd64 [zfs] System hang on ZFS input-output o amd64/127484 amd64 [timecounters] Drift problem with FreeBSD 7.0 and 7.1 o amd64/127451 amd64 [scheduler] incorrect load on quad core o amd64/127397 amd64 [amd64] 32bit application on FreeBSD-6.3 amd64 gets SI s amd64/127276 amd64 ldd(1) invokes linux yes o amd64/127129 amd64 mdconfig(8) is core dumping with Segmentation Fault 11 o amd64/125873 amd64 [smbd] [panic] Repeated kernel panics, trap 12 page fa o amd64/125002 amd64 [install] amd64, SATA hard disks not detected o amd64/124432 amd64 [panic] 7.0-STABLE panic: invalbuf: dirty bufs o amd64/124134 amd64 [kernel] The kernel doesn't follow the calling convent o amd64/123562 amd64 [install] FreeBSD amd64 not installs o amd64/123520 amd64 [ahd] unable to boot from net while using ahd o amd64/123456 amd64 fstat(1): /usr/bin/fstat shows error messages and hang f amd64/123275 amd64 [cbb] [pcmcia] cbb/pcmcia drivers on amd64 failure [re o kern/122782 amd64 [modules] accf_http.ko kernel module is not loadable o amd64/122695 amd64 [cpufreq] Lack of cpufreq control using amd64 eith cor o amd64/122624 amd64 unusable minimal installation of FreeBSD-7.0 o amd64/122549 amd64 7.0-RELEASE-amd64-bootonly.iso doesn't work w/ serial o amd64/122468 amd64 Compile problems after upgrading to 7.0 o amd64/122174 amd64 [panic] 7.0 no longer includes "device atpic" so fails o amd64/121590 amd64 [est] [p4tcc] [acpi_perf] setting dev.cpu.0.freq somet o amd64/121439 amd64 [boot] Installation of FreeBSD 7.0 fails: ACPI problem o amd64/120202 amd64 [amd64] [patch] [panic] kernel panic at start_all_aps, o amd64/119591 amd64 [amd64] [patch] time_t on 64-bit architecture o amd64/117418 amd64 [hang] FreeBSD 6.2 crash on amd64 4400+ with ssh o amd64/117316 amd64 [acpi] ACPI lockups on SuperMicro motherboard o amd64/117296 amd64 [ata] I don`t see second SATA IDE on VIA VT8237A a amd64/117186 amd64 [modules] kldload Unsupported file type on STABLE amd6 s amd64/116689 amd64 [request] support for MSI K9MM-V o amd64/116620 amd64 [hang] ifconfig spins when creating carp(4) device on o amd64/116322 amd64 [panic] At start fsck on current, the system panics o amd64/116159 amd64 [panic] Panic while debugging on CURRENT s amd64/115815 amd64 [ata] [request] Gigabyte GA-M61P-S3 Motherboard unsupp o amd64/115581 amd64 [Makefile] [patch] -mfancy-math-387 has no effect o amd64/115194 amd64 LCD screen remains blank after Dell XPS M1210 lid is c o amd64/114270 amd64 [cpufreq] cpufreq doesnt work when compiled in to kern o amd64/114111 amd64 [nfs] System crashes while writing on NFS-mounted shar f amd64/113021 amd64 [re] ASUS M2A-VM onboard NIC does not work o amd64/112222 amd64 [libc] 32-bit libc incorrectly converts some FP number f amd64/111992 amd64 [boot] BTX failed - HP Laptop dv2315nr o amd64/110655 amd64 [threads] 32 bit threaded applications crash on amd64 o amd64/110599 amd64 [geli] geli attach to gmirror device hangs and cannot s amd64/108861 amd64 [nve] nve(4) driver on FreeBSD 6.2 AMD64 does not work o amd64/106186 amd64 [panic] panic in swap_pager_swap_init (amd64/smp/6.2-p f amd64/105629 amd64 [re] TrendNet TEG-BUSR 10/100/1000 disables itself on f amd64/105531 amd64 [ata] gigabyte GA-M51GM-S2G / nVidia nForce 430 - does f amd64/105514 amd64 [boot] FreeBSD/amd64 - Fails to boot on HP Pavilion dv o amd64/102716 amd64 ex with no argument in an xterm gets SIGSEGV o amd64/97337 amd64 [dri] xorg reboots system if dri module is enabled o amd64/95888 amd64 [ata] kernel: ad2: TIMEOUT - WRITE_DMA retrying on HP f amd64/94989 amd64 [boot] BTX Halts on Sun Fire X2100 w/6.1-BETA4 (amd64) o amd64/94677 amd64 [panic] panic in amd64 install at non-root user creati o amd64/93961 amd64 [busdma] Problem in bounce buffer handling in sys/amd6 o amd64/92337 amd64 [em] FreeBSD 6.0 Release Intel Pro 1000 MT em1 no buff f amd64/91492 amd64 [boot] BTX halted o amd64/91405 amd64 [asr] [panic] Kernel panic caused by asr on 6.0-amd64 o amd64/89501 amd64 [install] System crashes on install using ftp on local o amd64/88790 amd64 [panic] kernel panic on first boot (after the FreeBSD o amd64/88568 amd64 [panic] 6.0-RELEASE install cd does not boot with usb o amd64/87689 amd64 [powerd] [hang] powerd hangs SMP Opteron 244 5-STABLE o amd64/87316 amd64 [vge] "vge0 attach returned 6" on FreeBSD 6.0-RC1 amd6 o amd64/87305 amd64 [smp] Dual Opteron / FreeBSD 5 & 6 / powerd results in f amd64/87258 amd64 [smp] [boot] cannot boot with SMP and Areca ARC-1160 r f amd64/86080 amd64 [radeon] [hang] radeon DRI causes system hang on amd64 s amd64/85273 amd64 [install] FreeBSD (NetBSD or OpenBSD) not install on l o amd64/78406 amd64 [panic]AMD64 w/ SCSI: issue 'rm -r /usr/ports' and sys o amd64/76136 amd64 [hang] system halts before reboot o amd64/74747 amd64 [panic] System panic on shutdown when process will not f amd64/73322 amd64 [msdosfs] [hang] unarchiving /etc to msdosfs locks up 97 problems total. From jhb at freebsd.org Mon Apr 13 10:55:08 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Apr 13 11:16:48 2009 Subject: amd64/133592: [busdma] [patch] busdma incorrectly calculates bounce buffer requirements for userspace buffers In-Reply-To: <20090412193044.GN3014@deviant.kiev.zoral.com.ua> References: <200904121520.n3CFK6G8032035@freefall.freebsd.org> <20090412193044.GN3014@deviant.kiev.zoral.com.ua> Message-ID: <200904131156.36255.jhb@freebsd.org> On Sunday 12 April 2009 3:30:44 pm Kostik Belousov wrote: > On Sun, Apr 12, 2009 at 03:20:06PM +0000, Scott Long wrote: > > The following reply was made to PR amd64/133592; it has been noted by GNATS. > > > > From: Scott Long > > To: bug-followup@FreeBSD.org, jason.harmening@gmail.com > > Cc: > > Subject: Re: amd64/133592: [busdma] [patch] busdma incorrectly calculates > > bounce buffer requirements for userspace buffers > > Date: Sun, 12 Apr 2009 08:53:47 -0600 > > > > You're right, it's definitely a problem. The patch looks correct, feel > > free to commit to i386, amd64, and ia64. Arm needs a similar fix, but > > the code looks to be somewhat different. > > Below is updated patch. It was compile-tested on all affected arches. > Scott, any notes ? I've had a similar patch in a branch for years, it should definitely go in. -- John Baldwin From d-bsd at dctech.net Mon Apr 13 04:10:04 2009 From: d-bsd at dctech.net (D C) Date: Mon Apr 13 12:30:04 2009 Subject: amd64/133701: Recompiling the kernel with k8temp or smbios break GEOM autodetection Message-ID: <200904131105.n3DB5xqM005901@www.freebsd.org> >Number: 133701 >Category: amd64 >Synopsis: Recompiling the kernel with k8temp or smbios break GEOM autodetection >Confidential: no >Severity: serious >Priority: low >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Apr 13 11:10:03 UTC 2009 >Closed-Date: >Last-Modified: >Originator: D C >Release: 7.1-RELEASE >Organization: >Environment: FreeBSD mybox.mynet.local 7.1-RELEASE FreeBSD 7.1-RELEASE #0: Thu Jan 1 08:58:24 UTC 2009 root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 (happens on a selfcompiled kernel) >Description: Recompiling the kernel on 7.1-RELEASE (amd64 platform) with k8temp and smbios in the kernel configuration somehow breaks geom_mirror autodetection and is therefore unable to boot from the /dev/gm0 mirrors. The previous root device /dev/gm0s1a is now detected as both /dev/gm0cs1a and /dev/gm0ccs1a upon booting the new kernel. >How-To-Repeat: cp /usr/src/sys/amd64/conf/GENERIC /usr/src/sys/amd64/conf/VOODOO echo "device k8temp" >> /usr/src/sys/amd64/conf/VOODOO echo "device smbios" >> /usr/src/sys/amd64/conf/VOODOO cd /usr/src make buildkernel KERNCONF=VOODOO make installkernel KERNCONF=VOODOO reboot >Fix: Remove "device k8temp" and "device smbios" from the kernel configuration file. >Release-Note: >Audit-Trail: >Unformatted: From linimon at FreeBSD.org Mon Apr 13 10:33:43 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Mon Apr 13 12:30:05 2009 Subject: kern/133676: [smbfs] [panic] umount -f'ing a vnode-based memory disk from off a SMB share caused a reboot Message-ID: <200904131733.n3DHXglX020272@freefall.freebsd.org> Old Synopsis: umount -f'ing a vnode-based memory disk from off a SMB share caused a reboot New Synopsis: [smbfs] [panic] umount -f'ing a vnode-based memory disk from off a SMB share caused a reboot Responsible-Changed-From-To: freebsd-amd64->freebsd-fs Responsible-Changed-By: linimon Responsible-Changed-When: Mon Apr 13 17:31:51 UTC 2009 Responsible-Changed-Why: Reclassify and reassign. http://www.freebsd.org/cgi/query-pr.cgi?pr=133676 From kostikbel at gmail.com Mon Apr 13 12:29:32 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Mon Apr 13 12:49:13 2009 Subject: amd64/133592: [busdma] [patch] busdma incorrectly calculates bounce buffer requirements for userspace buffers In-Reply-To: <200904131156.36255.jhb@freebsd.org> References: <200904121520.n3CFK6G8032035@freefall.freebsd.org> <20090412193044.GN3014@deviant.kiev.zoral.com.ua> <200904131156.36255.jhb@freebsd.org> Message-ID: <20090413192913.GZ3014@deviant.kiev.zoral.com.ua> On Mon, Apr 13, 2009 at 11:56:35AM -0400, John Baldwin wrote: > On Sunday 12 April 2009 3:30:44 pm Kostik Belousov wrote: > > On Sun, Apr 12, 2009 at 03:20:06PM +0000, Scott Long wrote: > > > The following reply was made to PR amd64/133592; it has been noted by > GNATS. > > > > > > From: Scott Long > > > To: bug-followup@FreeBSD.org, jason.harmening@gmail.com > > > Cc: > > > Subject: Re: amd64/133592: [busdma] [patch] busdma incorrectly calculates > > > bounce buffer requirements for userspace buffers > > > Date: Sun, 12 Apr 2009 08:53:47 -0600 > > > > > > You're right, it's definitely a problem. The patch looks correct, feel > > > free to commit to i386, amd64, and ia64. Arm needs a similar fix, but > > > the code looks to be somewhat different. > > > > Below is updated patch. It was compile-tested on all affected arches. > > Scott, any notes ? > > I've had a similar patch in a branch for years, it should definitely go in. Thanks, I committed this. As discussed with Scott, the bus_dmamap_load_uio() KPI does not look as an easy to use. For uio from UIO_USERSPACE, at least, the pages backing uio chunks must be held by the caller, otherwise the pages may be repurposed at any moment. Also, please note that there is no real error check for the result of pmap_extract(). Some time ago I already looked for the KPI that would hold the pages from uio, possibly topped by some per-process or per-user limit. Also, this KPI should check that all addresses are valid. It seems that we do not have such utility. Hope to be wrong. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-amd64/attachments/20090413/3baf3b06/attachment.pgp From dfilter at FreeBSD.ORG Mon Apr 13 12:40:06 2009 From: dfilter at FreeBSD.ORG (dfilter service) Date: Mon Apr 13 13:46:29 2009 Subject: amd64/133592: commit references a PR Message-ID: <200904131940.n3DJe381081585@freefall.freebsd.org> The following reply was made to PR amd64/133592; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: amd64/133592: commit references a PR Date: Mon, 13 Apr 2009 19:39:17 +0000 (UTC) Author: kib Date: Mon Apr 13 19:20:32 2009 New Revision: 191011 URL: http://svn.freebsd.org/changeset/base/191011 Log: The bus_dmamap_load_uio(9) shall use pmap of the thread recorded in the uio_td to extract pages from, instead of unconditionally use kernel pmap. Submitted by: Jason Harmening (amd64 version) PR: amd64/133592 Reviewed by: scottl (original patch), jhb MFC after: 2 weeks Modified: head/sys/amd64/amd64/busdma_machdep.c head/sys/arm/arm/busdma_machdep.c head/sys/i386/i386/busdma_machdep.c head/sys/ia64/ia64/busdma_machdep.c Modified: head/sys/amd64/amd64/busdma_machdep.c ============================================================================== --- head/sys/amd64/amd64/busdma_machdep.c Mon Apr 13 19:12:28 2009 (r191010) +++ head/sys/amd64/amd64/busdma_machdep.c Mon Apr 13 19:20:32 2009 (r191011) @@ -606,7 +606,10 @@ _bus_dmamap_load_buffer(bus_dma_tag_t dm vendaddr = (vm_offset_t)buf + buflen; while (vaddr < vendaddr) { - paddr = pmap_kextract(vaddr); + if (pmap) + paddr = pmap_extract(pmap, vaddr); + else + paddr = pmap_kextract(vaddr); if (run_filter(dmat, paddr) != 0) map->pagesneeded++; vaddr += (PAGE_SIZE - ((vm_offset_t)vaddr & PAGE_MASK)); Modified: head/sys/arm/arm/busdma_machdep.c ============================================================================== --- head/sys/arm/arm/busdma_machdep.c Mon Apr 13 19:12:28 2009 (r191010) +++ head/sys/arm/arm/busdma_machdep.c Mon Apr 13 19:20:32 2009 (r191011) @@ -669,8 +669,8 @@ bus_dmamem_free(bus_dma_tag_t dmat, void } static int -_bus_dmamap_count_pages(bus_dma_tag_t dmat, bus_dmamap_t map, void *buf, - bus_size_t buflen, int flags) +_bus_dmamap_count_pages(bus_dma_tag_t dmat, bus_dmamap_t map, pmap_t pmap, + void *buf, bus_size_t buflen, int flags) { vm_offset_t vaddr; vm_offset_t vendaddr; @@ -689,7 +689,10 @@ _bus_dmamap_count_pages(bus_dma_tag_t dm vendaddr = (vm_offset_t)buf + buflen; while (vaddr < vendaddr) { - paddr = pmap_kextract(vaddr); + if (pmap != NULL) + paddr = pmap_extract(pmap, vaddr); + else + paddr = pmap_kextract(vaddr); if (((dmat->flags & BUS_DMA_COULD_BOUNCE) != 0) && run_filter(dmat, paddr) != 0) map->pagesneeded++; @@ -745,7 +748,8 @@ bus_dmamap_load_buffer(bus_dma_tag_t dma bmask = ~(dmat->boundary - 1); if ((dmat->flags & BUS_DMA_COULD_BOUNCE) != 0) { - error = _bus_dmamap_count_pages(dmat, map, buf, buflen, flags); + error = _bus_dmamap_count_pages(dmat, map, pmap, buf, buflen, + flags); if (error) return (error); } Modified: head/sys/i386/i386/busdma_machdep.c ============================================================================== --- head/sys/i386/i386/busdma_machdep.c Mon Apr 13 19:12:28 2009 (r191010) +++ head/sys/i386/i386/busdma_machdep.c Mon Apr 13 19:20:32 2009 (r191011) @@ -142,8 +142,8 @@ static bus_addr_t add_bounce_page(bus_dm vm_offset_t vaddr, bus_size_t size); static void free_bounce_page(bus_dma_tag_t dmat, struct bounce_page *bpage); int run_filter(bus_dma_tag_t dmat, bus_addr_t paddr); -int _bus_dmamap_count_pages(bus_dma_tag_t dmat, bus_dmamap_t map, void *buf, - bus_size_t buflen, int flags); +int _bus_dmamap_count_pages(bus_dma_tag_t dmat, bus_dmamap_t map, pmap_t pmap, + void *buf, bus_size_t buflen, int flags); #ifdef XEN #undef pmap_kextract @@ -577,8 +577,8 @@ bus_dmamem_free(bus_dma_tag_t dmat, void } int -_bus_dmamap_count_pages(bus_dma_tag_t dmat, bus_dmamap_t map, void *buf, - bus_size_t buflen, int flags) +_bus_dmamap_count_pages(bus_dma_tag_t dmat, bus_dmamap_t map, pmap_t pmap, + void *buf, bus_size_t buflen, int flags) { vm_offset_t vaddr; vm_offset_t vendaddr; @@ -598,7 +598,10 @@ _bus_dmamap_count_pages(bus_dma_tag_t dm vendaddr = (vm_offset_t)buf + buflen; while (vaddr < vendaddr) { - paddr = pmap_kextract(vaddr); + if (pmap) + paddr = pmap_extract(pmap, vaddr); + else + paddr = pmap_kextract(vaddr); if (((dmat->flags & BUS_DMA_COULD_BOUNCE) != 0) && run_filter(dmat, paddr) != 0) { map->pagesneeded++; @@ -660,7 +663,7 @@ _bus_dmamap_load_buffer(bus_dma_tag_t dm map = &nobounce_dmamap; if ((dmat->flags & BUS_DMA_COULD_BOUNCE) != 0) { - error = _bus_dmamap_count_pages(dmat, map, buf, buflen, flags); + error = _bus_dmamap_count_pages(dmat, map, pmap, buf, buflen, flags); if (error) return (error); } Modified: head/sys/ia64/ia64/busdma_machdep.c ============================================================================== --- head/sys/ia64/ia64/busdma_machdep.c Mon Apr 13 19:12:28 2009 (r191010) +++ head/sys/ia64/ia64/busdma_machdep.c Mon Apr 13 19:20:32 2009 (r191011) @@ -527,7 +527,10 @@ _bus_dmamap_load_buffer(bus_dma_tag_t dm vendaddr = (vm_offset_t)buf + buflen; while (vaddr < vendaddr) { - paddr = pmap_kextract(vaddr); + if (pmap != NULL) + paddr = pmap_extract(pmap, vaddr); + else + paddr = pmap_kextract(vaddr); if (run_filter(dmat, paddr, 0) != 0) map->pagesneeded++; vaddr += PAGE_SIZE; _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From seanjstrand at gmail.com Tue Apr 14 07:42:01 2009 From: seanjstrand at gmail.com (SEan Strand) Date: Tue Apr 14 08:08:06 2009 Subject: Mesa-7.4 Installation Error causing firefox and opera to fail installation. Message-ID: <7619cc20904140709x4f936220rc38df43c83626a5d@mail.gmail.com> This was first notices on FBSD7.1 amd64 after portsnap update and kennel update. The packages: xext, xxf86vm, xdamage, xfixes, xcb-glx all seem to be missing, how ever x11-xcb was foubd and manualy installed. This was all taken from the amd64 OS version. Rgds SEanS ---------- Forwarded message ---------- From: Arjan van Leeuwen Date: 2009/4/14 Subject: Re: installation error To: SEan Strand Hi Sean, On Mon, 13 Apr 2009 19:49:15 +0200, SEan Strand wrote: Good after noon gents, > > Please can you have a good look at the att'd file. then make > recommendation > as to what I do in order to fix the problem and get back into my or your > Opera. > > Thanks a Million, Rgds SEanS. > As you noticed, you are having a problem with installing Mesa. We can't help you with that, since this is a software package that is separate from Opera. I suggest you ask your question on the freebsd-ports@freebsd.org mailing list. If you do so, make sure to include some output of the installation process as well, so that people can check what actually goes wrong. Best regards, Arjan van Leeuwen -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From tinderbox at freebsd.org Wed Apr 15 21:13:32 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Wed Apr 15 21:34:34 2009 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <20090416041328.4CFE37302F@freebsd-current.sentex.ca> TB --- 2009-04-16 02:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-16 02:00:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2009-04-16 02:00:00 - cleaning the object tree TB --- 2009-04-16 02:01:11 - cvsupping the source tree TB --- 2009-04-16 02:01:11 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2009-04-16 02:01:19 - building world TB --- 2009-04-16 02:01:19 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-16 02:01:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-16 02:01:19 - TARGET=amd64 TB --- 2009-04-16 02:01:19 - TARGET_ARCH=amd64 TB --- 2009-04-16 02:01:19 - TZ=UTC TB --- 2009-04-16 02:01:19 - __MAKE_CONF=/dev/null TB --- 2009-04-16 02:01:19 - cd /src TB --- 2009-04-16 02:01:19 - /usr/bin/make -B buildworld >>> World build started on Thu Apr 16 02:01:21 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 >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Thu Apr 16 04:01:48 UTC 2009 TB --- 2009-04-16 04:01:48 - generating LINT kernel config TB --- 2009-04-16 04:01:48 - cd /src/sys/amd64/conf TB --- 2009-04-16 04:01:48 - /usr/bin/make -B LINT TB --- 2009-04-16 04:01:48 - building LINT kernel TB --- 2009-04-16 04:01:48 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-16 04:01:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-16 04:01:48 - TARGET=amd64 TB --- 2009-04-16 04:01:48 - TARGET_ARCH=amd64 TB --- 2009-04-16 04:01:48 - TZ=UTC TB --- 2009-04-16 04:01:48 - __MAKE_CONF=/dev/null TB --- 2009-04-16 04:01:48 - cd /src TB --- 2009-04-16 04:01:48 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Apr 16 04:01:49 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 -frename-registers -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/geom/part/g_part.c awk -f /src/sys/tools/makeobjops.awk /src/sys/geom/part/g_part_if.m -c ; cc -c -O2 -frename-registers -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue g_part_if.c cc -c -O2 -frename-registers -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/geom/part/g_part_apm.c cc -c -O2 -frename-registers -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/geom/part/g_part_bsd.c cc -c -O2 -frename-registers -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/geom/part/g_part_ebr.c cc1: warnings being treated as errors /src/sys/geom/part/g_part_ebr.c: In function 'g_part_ebr_fullname': /src/sys/geom/part/g_part_ebr.c:327: warning: field precision should have type 'int', but argument 3 has type 'size_t' *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-16 04:13:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-16 04:13:28 - ERROR: failed to build lint kernel TB --- 2009-04-16 04:13:28 - 6184.82 user 645.54 system 8007.77 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From gavin at FreeBSD.org Thu Apr 16 04:20:17 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Thu Apr 16 05:01:20 2009 Subject: amd64/91492: [boot] BTX halted Message-ID: <200904161120.n3GBKGjH040398@freefall.freebsd.org> Synopsis: [boot] BTX halted State-Changed-From-To: feedback->closed State-Changed-By: gavin State-Changed-When: Thu Apr 16 11:17:38 UTC 2009 State-Changed-Why: Feedback timeout (~1 year), this problem is believed to be fixed in recent versions of FreeBSD. Responsible-Changed-From-To: freebsd-amd64->gavin Responsible-Changed-By: gavin Responsible-Changed-When: Thu Apr 16 11:17:38 UTC 2009 Responsible-Changed-Why: Track http://www.freebsd.org/cgi/query-pr.cgi?pr=91492 From gavin at FreeBSD.org Thu Apr 16 04:21:01 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Thu Apr 16 05:01:44 2009 Subject: amd64/94989: [boot] BTX Halts on Sun Fire X2100 w/6.1-BETA4 (amd64) and 5.4-RELEASE (x86) Message-ID: <200904161121.n3GBL1Zi044184@freefall.freebsd.org> Synopsis: [boot] BTX Halts on Sun Fire X2100 w/6.1-BETA4 (amd64) and 5.4-RELEASE (x86) State-Changed-From-To: feedback->closed State-Changed-By: gavin State-Changed-When: Thu Apr 16 11:20:38 UTC 2009 State-Changed-Why: Feedback timeout (~1 year), this problem is believed to be fixed in recent versions of FreeBSD. Responsible-Changed-From-To: freebsd-amd64->gavin Responsible-Changed-By: gavin Responsible-Changed-When: Thu Apr 16 11:20:38 UTC 2009 Responsible-Changed-Why: Track http://www.freebsd.org/cgi/query-pr.cgi?pr=94989 From gavin at FreeBSD.org Thu Apr 16 04:23:09 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Thu Apr 16 05:11:03 2009 Subject: amd64/111992: [boot] BTX failed - HP Laptop dv2315nr Message-ID: <200904161123.n3GBN9q0051813@freefall.freebsd.org> Synopsis: [boot] BTX failed - HP Laptop dv2315nr State-Changed-From-To: feedback->closed State-Changed-By: gavin State-Changed-When: Thu Apr 16 11:21:56 UTC 2009 State-Changed-Why: Feedback timeout (~1 year). Although it is hard to say (not enough information in PR), this is likely fixed in recent versions of FreeBSD. Responsible-Changed-From-To: freebsd-amd64->gavin Responsible-Changed-By: gavin Responsible-Changed-When: Thu Apr 16 11:21:56 UTC 2009 Responsible-Changed-Why: Track http://www.freebsd.org/cgi/query-pr.cgi?pr=111992 From gavin at FreeBSD.org Thu Apr 16 04:29:48 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Thu Apr 16 05:17:20 2009 Subject: amd64/87258: [smp] [boot] cannot boot with SMP and Areca ARC-1160 raid controller Message-ID: <200904161129.n3GBTlIC052080@freefall.freebsd.org> Synopsis: [smp] [boot] cannot boot with SMP and Areca ARC-1160 raid controller State-Changed-From-To: feedback->closed State-Changed-By: gavin State-Changed-When: Thu Apr 16 11:29:19 UTC 2009 State-Changed-Why: Feedback timeout (~1 year) Responsible-Changed-From-To: freebsd-amd64->gavin Responsible-Changed-By: gavin Responsible-Changed-When: Thu Apr 16 11:29:19 UTC 2009 Responsible-Changed-Why: Track http://www.freebsd.org/cgi/query-pr.cgi?pr=87258 From tinderbox at freebsd.org Thu Apr 16 21:11:59 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu Apr 16 21:36:13 2009 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <20090417041155.E77097302F@freebsd-current.sentex.ca> TB --- 2009-04-17 03:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-17 03:00:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2009-04-17 03:00:00 - cleaning the object tree TB --- 2009-04-17 03:01:20 - cvsupping the source tree TB --- 2009-04-17 03:01:20 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2009-04-17 03:01:30 - building world TB --- 2009-04-17 03:01:30 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-17 03:01:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-17 03:01:30 - TARGET=amd64 TB --- 2009-04-17 03:01:30 - TARGET_ARCH=amd64 TB --- 2009-04-17 03:01:30 - TZ=UTC TB --- 2009-04-17 03:01:30 - __MAKE_CONF=/dev/null TB --- 2009-04-17 03:01:30 - cd /src TB --- 2009-04-17 03:01:30 - /usr/bin/make -B buildworld >>> World build started on Fri Apr 17 03:01:32 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 [...] /obj/amd64/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0xf0a): In function `archive_write_mtree_data': : undefined reference to `SHA384_Update' /obj/amd64/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x13e4): In function `archive_write_mtree_header': : undefined reference to `SHA512_Init' /obj/amd64/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x1418): In function `archive_write_mtree_header': : undefined reference to `SHA384_Init' /obj/amd64/src/tmp/usr/lib/libarchive.a(archive_write_set_format_mtree.o)(.text+0x14d8): In function `archive_write_mtree_header': : undefined reference to `MD5_Init' *** Error code 1 Stop in /obj/amd64/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-17 04:11:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-17 04:11:55 - ERROR: failed to build world TB --- 2009-04-17 04:11:55 - 3297.12 user 346.25 system 4315.39 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From gavin at FreeBSD.org Fri Apr 17 08:44:32 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Fri Apr 17 09:14:58 2009 Subject: amd64/133592: [busdma] [patch] busdma incorrectly calculates bounce buffer requirements for userspace buffers Message-ID: <200904171544.n3HFiVVU057070@freefall.freebsd.org> Synopsis: [busdma] [patch] busdma incorrectly calculates bounce buffer requirements for userspace buffers State-Changed-From-To: open->patched State-Changed-By: gavin State-Changed-When: Fri Apr 17 15:42:59 UTC 2009 State-Changed-Why: Patch has been committed to HEAD, SVN r191011. Responsible-Changed-From-To: freebsd-amd64->kib Responsible-Changed-By: gavin Responsible-Changed-When: Fri Apr 17 15:42:59 UTC 2009 Responsible-Changed-Why: Over to committer as MFC reminder http://www.freebsd.org/cgi/query-pr.cgi?pr=133592 From rg at progtech.net Fri Apr 17 10:40:04 2009 From: rg at progtech.net (Rolf Grossmann) Date: Fri Apr 17 12:09:02 2009 Subject: amd64/110655: [threads] 32 bit threaded applications crash on amd64 SMP kernel. Message-ID: <200904171740.n3HHe2Ga007002@freefall.freebsd.org> The following reply was made to PR amd64/110655; it has been noted by GNATS. From: Rolf Grossmann To: bug-followup@FreeBSD.org Cc: Subject: Re: amd64/110655: [threads] 32 bit threaded applications crash on amd64 SMP kernel. Date: Fri, 17 Apr 2009 19:17:20 +0200 It now works for me on FreeBSD 7.1 (GENERIC kernel, which includes options SMP, but single cpu): $ uname -m i386 $ cc -o crash32-thr crash32.c -lthr $ cc -o crash32-pthread crash32.c -pthread $ md5 crash32-thr crash32-pthread MD5 (crash32-thr) = 30b58238379b4c3496413f22863c2e86 MD5 (crash32-pthread) = 734e11117fbfd63efb06376cf74430d5 $ ./crash32-thr Thread. $ ./crash32-pthread Thread. $ uname -m amd64 $ md5 crash32-thr crash32-pthread MD5 (crash32-thr) = 30b58238379b4c3496413f22863c2e86 MD5 (crash32-pthread) = 734e11117fbfd63efb06376cf74430d5 $ ./crash32-thr Thread. $ ./crash32-pthread Thread. Can we close this ticket? From tinderbox at freebsd.org Sun Apr 19 22:29:48 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Sun Apr 19 22:30:05 2009 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <20090419222944.AE6767302F@freebsd-current.sentex.ca> TB --- 2009-04-19 22:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-04-19 22:00:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2009-04-19 22:00:00 - cleaning the object tree TB --- 2009-04-19 22:01:20 - cvsupping the source tree TB --- 2009-04-19 22:01:20 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2009-04-19 22:01:30 - building world TB --- 2009-04-19 22:01:30 - MAKEOBJDIRPREFIX=/obj TB --- 2009-04-19 22:01:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-04-19 22:01:30 - TARGET=amd64 TB --- 2009-04-19 22:01:30 - TARGET_ARCH=amd64 TB --- 2009-04-19 22:01:30 - TZ=UTC TB --- 2009-04-19 22:01:30 - __MAKE_CONF=/dev/null TB --- 2009-04-19 22:01:30 - cd /src TB --- 2009-04-19 22:01:30 - /usr/bin/make -B buildworld >>> World build started on Sun Apr 19 22:01:31 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 [...] cc -O2 -pipe -DPTHREAD_KERNEL -I/src/lib/libthr/../libc/include -I/src/lib/libthr/thread -I/src/lib/libthr/../../include -I/src/lib/libthr/arch/amd64/include -I/src/lib/libthr/sys -I/src/lib/libthr/../../libexec/rtld-elf -I/src/lib/libthr/../../libexec/rtld-elf/amd64 -I/src/lib/libthr/../libthread_db -Winline -D_PTHREADS_INVARIANTS -DSYSCALL_COMPAT -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libthr/thread/thr_pspinlock.c cc -O2 -pipe -DPTHREAD_KERNEL -I/src/lib/libthr/../libc/include -I/src/lib/libthr/thread -I/src/lib/libthr/../../include -I/src/lib/libthr/arch/amd64/include -I/src/lib/libthr/sys -I/src/lib/libthr/../../libexec/rtld-elf -I/src/lib/libthr/../../libexec/rtld-elf/amd64 -I/src/lib/libthr/../libthread_db -Winline -D_PTHREADS_INVARIANTS -DSYSCALL_COMPAT -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libthr/thread/thr_resume_np.c cc -O2 -pipe -DPTHREAD_KERNEL -I/src/lib/libthr/../libc/include -I/src/lib/libthr/thread -I/src/lib/libthr/../../include -I/src/lib/libthr/arch/amd64/include -I/src/lib/libthr/sys -I/src/lib/libthr/../../libexec/rtld-elf -I/src/lib/libthr/../../libexec/rtld-elf/amd64 -I/src/lib/libthr/../libthread_db -Winline -D_PTHREADS_INVARIANTS -DSYSCALL_COMPAT -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/lib/libthr/thread/thr_rtld.c /src/lib/libthr/thread/thr_rtld.c:42:1: error: "CACHE_LINE_SIZE" redefined In file included from /obj/amd64/src/tmp/usr/include/sys/param.h:109, from /src/lib/libthr/thread/thr_private.h:42, from /src/lib/libthr/thread/thr_rtld.c:37: /obj/amd64/src/tmp/usr/include/machine/param.h:99:1: error: this is the location of the previous definition *** Error code 1 Stop in /src/lib/libthr. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-04-19 22:29:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-04-19 22:29:44 - ERROR: failed to build world TB --- 2009-04-19 22:29:44 - 1303.71 user 151.27 system 1784.23 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From bugmaster at FreeBSD.org Mon Apr 20 11:06:48 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Apr 20 11:34:24 2009 Subject: Current problem reports assigned to freebsd-amd64@FreeBSD.org Message-ID: <200904201106.n3KB6lei032937@freefall.freebsd.org> 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 amd64/133701 amd64 Recompiling the kernel with k8temp or smbios break GEO o amd64/132574 amd64 [boot] Freeze on bootstrap loader (CD) using ATA/133 P o amd64/132170 amd64 7.1 kernel compilation problem o amd64/132019 amd64 [install] kernel trap 12 while installation o amd64/131906 amd64 [ata] SATA data corruption with Promise PDC20378 (amd6 o amd64/131456 amd64 ACPI & ATA problems o amd64/131314 amd64 [modules] [panic] large modules fail to load on amd64 o amd64/131209 amd64 [panic] [bce] 7.1-STABLE amd64 crash - m0 NULL f amd64/130885 amd64 sockstat(1) on amd64 does not work o amd64/130864 amd64 [hang] Problem with copying files to a large partition o amd64/130817 amd64 FreeBSD does not support HP DL160G5 [regression] o amd64/130494 amd64 [boot] netbooting BTX fails on amd64 o amd64/130483 amd64 [mxge] MSI must be disabled when Myricom 10Gbps Card i o amd64/130368 amd64 [hang] Switching from xorg to console locks up compute o amd64/129889 amd64 [boot] The booting process stops at the line mounting o amd64/129721 amd64 [hang] Motherboard K9N2G Neo-FD hangs on boot of 7.0-R o amd64/129667 amd64 [ata] Elitegroup A780GM-A IDE controller not recognize o amd64/129488 amd64 [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o amd64/129426 amd64 [panic] FreeBSD 7.0 crash after subdiskXX: detached o amd64/129315 amd64 [boot] amd64 motherboard: Intel DG965WH motherboard co f amd64/128978 amd64 [install] FreeBSD 6.3 64-bit panics at boot time duri o amd64/128810 amd64 AMD 64 port installation o amd64/128765 amd64 [install] Install CD loads to Install choices but stop o amd64/128686 amd64 [ata] can't detect SATA Disk on 8.0-Current with NF550 o amd64/128263 amd64 [panic] 2 amd64 dl380 g5 with dual quadcore xeons, 8 a o amd64/128259 amd64 csh(1): "`" crashes csh o amd64/127640 amd64 gcc(1) will not build shared libraries with -fprofile- o amd64/127492 amd64 [zfs] System hang on ZFS input-output o amd64/127484 amd64 [timecounters] Drift problem with FreeBSD 7.0 and 7.1 o amd64/127451 amd64 [scheduler] incorrect load on quad core o amd64/127397 amd64 [amd64] 32bit application on FreeBSD-6.3 amd64 gets SI s amd64/127276 amd64 ldd(1) invokes linux yes o amd64/127129 amd64 mdconfig(8) is core dumping with Segmentation Fault 11 o amd64/125873 amd64 [smbd] [panic] Repeated kernel panics, trap 12 page fa o amd64/125002 amd64 [install] amd64, SATA hard disks not detected o amd64/124432 amd64 [panic] 7.0-STABLE panic: invalbuf: dirty bufs o amd64/124134 amd64 [kernel] The kernel doesn't follow the calling convent o amd64/123562 amd64 [install] FreeBSD amd64 not installs o amd64/123520 amd64 [ahd] unable to boot from net while using ahd o amd64/123456 amd64 fstat(1): /usr/bin/fstat shows error messages and hang f amd64/123275 amd64 [cbb] [pcmcia] cbb/pcmcia drivers on amd64 failure [re o kern/122782 amd64 [modules] accf_http.ko kernel module is not loadable o amd64/122695 amd64 [cpufreq] Lack of cpufreq control using amd64 eith cor o amd64/122624 amd64 unusable minimal installation of FreeBSD-7.0 o amd64/122549 amd64 7.0-RELEASE-amd64-bootonly.iso doesn't work w/ serial o amd64/122468 amd64 Compile problems after upgrading to 7.0 o amd64/122174 amd64 [panic] 7.0 no longer includes "device atpic" so fails o amd64/121590 amd64 [est] [p4tcc] [acpi_perf] setting dev.cpu.0.freq somet o amd64/121439 amd64 [boot] Installation of FreeBSD 7.0 fails: ACPI problem o amd64/120202 amd64 [amd64] [patch] [panic] kernel panic at start_all_aps, o amd64/119591 amd64 [amd64] [patch] time_t on 64-bit architecture o amd64/117418 amd64 [hang] FreeBSD 6.2 crash on amd64 4400+ with ssh o amd64/117316 amd64 [acpi] ACPI lockups on SuperMicro motherboard o amd64/117296 amd64 [ata] I don`t see second SATA IDE on VIA VT8237A a amd64/117186 amd64 [modules] kldload Unsupported file type on STABLE amd6 s amd64/116689 amd64 [request] support for MSI K9MM-V o amd64/116620 amd64 [hang] ifconfig spins when creating carp(4) device on o amd64/116322 amd64 [panic] At start fsck on current, the system panics o amd64/116159 amd64 [panic] Panic while debugging on CURRENT s amd64/115815 amd64 [ata] [request] Gigabyte GA-M61P-S3 Motherboard unsupp o amd64/115581 amd64 [Makefile] [patch] -mfancy-math-387 has no effect o amd64/115194 amd64 LCD screen remains blank after Dell XPS M1210 lid is c o amd64/114270 amd64 [cpufreq] cpufreq doesnt work when compiled in to kern o amd64/114111 amd64 [nfs] System crashes while writing on NFS-mounted shar f amd64/113021 amd64 [re] ASUS M2A-VM onboard NIC does not work o amd64/112222 amd64 [libc] 32-bit libc incorrectly converts some FP number o amd64/110655 amd64 [threads] 32 bit threaded applications crash on amd64 o amd64/110599 amd64 [geli] geli attach to gmirror device hangs and cannot s amd64/108861 amd64 [nve] nve(4) driver on FreeBSD 6.2 AMD64 does not work o amd64/106186 amd64 [panic] panic in swap_pager_swap_init (amd64/smp/6.2-p f amd64/105629 amd64 [re] TrendNet TEG-BUSR 10/100/1000 disables itself on f amd64/105531 amd64 [ata] gigabyte GA-M51GM-S2G / nVidia nForce 430 - does f amd64/105514 amd64 [boot] FreeBSD/amd64 - Fails to boot on HP Pavilion dv o amd64/102716 amd64 ex with no argument in an xterm gets SIGSEGV o amd64/97337 amd64 [dri] xorg reboots system if dri module is enabled o amd64/95888 amd64 [ata] kernel: ad2: TIMEOUT - WRITE_DMA retrying on HP o amd64/94677 amd64 [panic] panic in amd64 install at non-root user creati o amd64/93961 amd64 [busdma] Problem in bounce buffer handling in sys/amd6 o amd64/92337 amd64 [em] FreeBSD 6.0 Release Intel Pro 1000 MT em1 no buff o amd64/91405 amd64 [asr] [panic] Kernel panic caused by asr on 6.0-amd64 o amd64/89501 amd64 [install] System crashes on install using ftp on local o amd64/88790 amd64 [panic] kernel panic on first boot (after the FreeBSD o amd64/88568 amd64 [panic] 6.0-RELEASE install cd does not boot with usb o amd64/87689 amd64 [powerd] [hang] powerd hangs SMP Opteron 244 5-STABLE o amd64/87316 amd64 [vge] "vge0 attach returned 6" on FreeBSD 6.0-RC1 amd6 o amd64/87305 amd64 [smp] Dual Opteron / FreeBSD 5 & 6 / powerd results in f amd64/86080 amd64 [radeon] [hang] radeon DRI causes system hang on amd64 s amd64/85273 amd64 [install] FreeBSD (NetBSD or OpenBSD) not install on l o amd64/78406 amd64 [panic]AMD64 w/ SCSI: issue 'rm -r /usr/ports' and sys o amd64/76136 amd64 [hang] system halts before reboot o amd64/74747 amd64 [panic] System panic on shutdown when process will not f amd64/73322 amd64 [msdosfs] [hang] unarchiving /etc to msdosfs locks up 92 problems total. From jhb at FreeBSD.org Mon Apr 20 12:48:14 2009 From: jhb at FreeBSD.org (jhb@FreeBSD.org) Date: Mon Apr 20 12:48:21 2009 Subject: amd64/110655: [threads] 32 bit threaded applications crash on amd64 SMP kernel. Message-ID: <200904201248.n3KCmDLZ073734@freefall.freebsd.org> Synopsis: [threads] 32 bit threaded applications crash on amd64 SMP kernel. State-Changed-From-To: open->closed State-Changed-By: jhb State-Changed-When: Mon Apr 20 12:47:45 UTC 2009 State-Changed-Why: This is fixed in 6.3 (libthr only) and 7.0+ (libthr + libkse). http://www.freebsd.org/cgi/query-pr.cgi?pr=110655 From gavin at FreeBSD.org Thu Apr 23 10:48:40 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Thu Apr 23 10:48:47 2009 Subject: amd64/113021: [re] ASUS M2A-VM onboard NIC does not work Message-ID: <200904231048.n3NAmdf3068979@freefall.freebsd.org> Synopsis: [re] ASUS M2A-VM onboard NIC does not work State-Changed-From-To: feedback->closed State-Changed-By: gavin State-Changed-When: Thu Apr 23 10:47:15 UTC 2009 State-Changed-Why: Feedback timeout (~1 year). Additionally, there are several reports of this motherboard working well with newer versions of FreeBSD. Responsible-Changed-From-To: freebsd-amd64->gavin Responsible-Changed-By: gavin Responsible-Changed-When: Thu Apr 23 10:47:15 UTC 2009 Responsible-Changed-Why: Track http://www.freebsd.org/cgi/query-pr.cgi?pr=113021 From gavin at FreeBSD.org Thu Apr 23 14:32:38 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Thu Apr 23 14:32:45 2009 Subject: amd64/86080: [radeon] [hang] radeon DRI causes system hang on amd64 using mplayer -vo xv Message-ID: <200904231432.n3NEWbI8083564@freefall.freebsd.org> Synopsis: [radeon] [hang] radeon DRI causes system hang on amd64 using mplayer -vo xv State-Changed-From-To: feedback->closed State-Changed-By: gavin State-Changed-When: Thu Apr 23 14:31:40 UTC 2009 State-Changed-Why: Close, feedback timeout (~1 year). To submitter: If this is still a problem, we can reopen this PR. Responsible-Changed-From-To: freebsd-amd64->gavin Responsible-Changed-By: gavin Responsible-Changed-When: Thu Apr 23 14:31:40 UTC 2009 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=86080 From gavin at FreeBSD.org Thu Apr 23 14:45:40 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Thu Apr 23 14:45:47 2009 Subject: amd64/105629: [re] TrendNet TEG-BUSR 10/100/1000 disables itself on 6.2 [regression] Message-ID: <200904231445.n3NEjdPT097731@freefall.freebsd.org> Synopsis: [re] TrendNet TEG-BUSR 10/100/1000 disables itself on 6.2 [regression] State-Changed-From-To: feedback->closed State-Changed-By: gavin State-Changed-When: Thu Apr 23 14:45:00 UTC 2009 State-Changed-Why: Feedback timeout (~1 year) Responsible-Changed-From-To: freebsd-amd64->gavin Responsible-Changed-By: gavin Responsible-Changed-When: Thu Apr 23 14:45:00 UTC 2009 Responsible-Changed-Why: Track. If this is still an issue, we can reopen the PR. http://www.freebsd.org/cgi/query-pr.cgi?pr=105629 From freebsdpr at sensation.net.au Fri Apr 24 18:00:08 2009 From: freebsdpr at sensation.net.au (Rowan Crowe) Date: Fri Apr 24 19:36:25 2009 Subject: amd64/133977: "panic: ffs_blkfree: freeing free block" after 7.0R->7.1R amd64 src upgrade Message-ID: <200904241756.n3OHu0WI071774@www.freebsd.org> >Number: 133977 >Category: amd64 >Synopsis: "panic: ffs_blkfree: freeing free block" after 7.0R->7.1R amd64 src upgrade >Confidential: no >Severity: critical >Priority: medium >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Apr 24 18:00:07 UTC 2009 >Closed-Date: >Last-Modified: >Originator: Rowan Crowe >Release: 7.1-RELEASE amd64 >Organization: >Environment: >Description: After doing a source upgrade of FreeBSD 7.0-RELEASE to 7.1-RELEASE I am consistently seeing a panic, approximately 25-35 minutes after each boot. At the time the system is effectively idle (it's a MySQL server, but mysqld has been disabled at startup while I diagnose the problem). Two notable exceptions: gmirror is rebuilding two mirrors, and fsck_ufs is checking the file systems. Based on some quick research I suspect it's the latter that is causing the panic. If so I'm stuck in a vicious cycle since the file system is going to be checked after every crash... This is what the panic output shows: ------ dev = stripe/raid10, block = 1, fs = /db panic: ffs_blkfree: freeing free block cpuid = 1 GEOM_MIRROR: Device db2: rebuilding provider ad16 stopped. GEOM_MIRROR: Device db1: rebuilding provider ad12 stopped. Uptime: 31m16s Physical memory: 8183 MB Dumping: 656 MB: ------ Note 1: /db is a stripe (name: "raid10") of two mirrors (names: "db1", "db2"), approx 1.5TB of usable size. Output of /var/run/dmesg.boot: Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.1-RELEASE #0: Fri Apr 24 18:04:00 EST 2009 rowan@db1au.sitedossier.com:/usr/src/sys/amd64/compile/DB1AU Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU E8200 @ 2.66GHz (2669.04-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10676 Stepping = 6 Features=0xbfebfbff Features2=0x8e3fd> AMD Features=0x20100800 AMD Features2=0x1 Cores per package: 2 usable memory = 8581054464 (8183 MB) avail memory = 8293785600 (7909 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, cfde0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: mem 0xe4000000-0xe4ffffff,0xd0000000-0xdfffffff,0xe5000000-0xe5ffffff irq 16 at device 0.0 on pci1 pcib2: irq 16 at device 6.0 on pci0 pci2: on pcib2 em0: port 0x9000-0x901f mem 0xe8020000-0xe803ffff,0xe8000000-0xe801ffff irq 16 at device 0.0 on pci2 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:1b:21:05:11:d4 uhci0: port 0xe200-0xe21f irq 16 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xe000-0xe01f irq 21 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xe100-0xe11f irq 18 at device 26.2 on pci0 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xef100000-0xef1003ff irq 18 at device 26.7 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: on usb3 uhub3: 6 ports with 6 removable, self powered umass0: on uhub3 umass1: on uhub3 pcib3: irq 16 at device 28.0 on pci0 pci3: on pcib3 pcib4: irq 18 at device 28.2 on pci0 pci4: on pcib4 atapci0: port 0xa000-0xa07f mem 0xea004000-0xea00407f,0xea000000-0xea003fff irq 18 at device 0.0 on pci4 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] pcib5: irq 19 at device 28.3 on pci0 pci5: on pcib5 pcib6: irq 16 at device 28.4 on pci0 pci6: on pcib6 re0: port 0xc000-0xc0ff mem 0xec000000-0xec000fff irq 16 at device 0.0 on pci6 re0: turning off MSI enable bit. re0: Chip rev. 0x38000000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:1d:7d:02:aa:6a re0: [FILTER] pcib7: irq 17 at device 28.5 on pci0 pci7: on pcib7 re1: port 0xd000-0xd0ff mem 0xee000000-0xee000fff irq 17 at device 0.0 on pci7 re1: turning off MSI enable bit. re1: Chip rev. 0x38000000 re1: MAC rev. 0x00000000 miibus1: on re1 rgephy1: PHY 1 on miibus1 rgephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re1: Ethernet address: 00:1d:7d:02:aa:7a re1: [FILTER] uhci3: port 0xe300-0xe31f irq 23 at device 29.0 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered uhci4: port 0xe400-0xe41f irq 19 at device 29.1 on pci0 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub5: on usb5 uhub5: 2 ports with 2 removable, self powered uhci5: port 0xe500-0xe51f irq 18 at device 29.2 on pci0 uhci5: [GIANT-LOCKED] uhci5: [ITHREAD] usb6: on uhci5 usb6: USB revision 1.0 uhub6: on usb6 uhub6: 2 ports with 2 removable, self powered ehci1: mem 0xef101000-0xef1013ff irq 23 at device 29.7 on pci0 ehci1: [GIANT-LOCKED] ehci1: [ITHREAD] usb7: EHCI version 1.0 usb7: companion controllers, 2 ports each: usb4 usb5 usb6 usb7: on ehci1 usb7: USB revision 2.0 uhub7: on usb7 uhub7: 6 ports with 6 removable, self powered pcib8: at device 30.0 on pci0 pci8: on pcib8 isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0xe600-0xe607,0xe700-0xe703,0xe800-0xe807,0xe900-0xe903,0xea00-0xea1f mem 0xef102000-0xef1027ff irq 19 at device 31.2 on pci0 atapci1: [ITHREAD] atapci1: AHCI Version 01.20 controller with 6 ports detected ata4: on atapci1 ata4: [ITHREAD] ata5: on atapci1 ata5: [ITHREAD] ata6: on atapci1 ata6: [ITHREAD] ata7: on atapci1 ata7: [ITHREAD] ata8: on atapci1 ata8: [ITHREAD] ata9: on atapci1 ata9: [ITHREAD] pci0: at device 31.3 (no driver attached) speaker0: port 0x61 on acpi0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] cpu0: on acpi0 acpi_perf0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 61a082006000820 device_attach: est1 attach returned 6 p4tcc1: on cpu1 orm0: at iomem 0xd0000-0xd1fff,0xd2000-0xd5fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec ipfw2 initialized, divert enabled, nat loadable, rule-based forwarding enabled, default to accept, logging unlimited ad4: 152627MB at ata2-master SATA300 ad6: 152627MB at ata3-master SATA300 ad8: 286167MB at ata4-master SATA300 ad10: 305245MB at ata5-master SATA300 ad12: 715404MB at ata6-master SATA300 ad14: 715404MB at ata7-master SATA300 ad16: 715404MB at ata8-master SATA300 ad18: 715404MB at ata9-master SATA300 GEOM_MIRROR: Device mirror/gm0 launched (2/2). GEOM_MIRROR: Device mirror/idx0 launched (2/2). GEOM_MIRROR: Device mirror/db1 launched (1/2). GEOM_MIRROR: Device db1: rebuilding provider ad12. GEOM_MIRROR: Device mirror/db2 launched (1/2). GEOM_MIRROR: Device db2: rebuilding provider ad16. GEOM_STRIPE: Device raid10 created (id=1767666037). GEOM_STRIPE: Disk mirror/db1 attached to raid10. GEOM_STRIPE: Disk mirror/db2 attached to raid10. GEOM_STRIPE: Device raid10 activated. SMP: AP CPU #1 Launched! da1 at umass-sim1 bus 1 target 0 lun 0 da1: Removable Direct Access SCSI-0 device da1: 40.000MB/s transfers da1: 3849MB (7883775 512 byte sectors: 255H 63S/T 490C) da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 3849MB (7883775 512 byte sectors: 255H 63S/T 490C) GEOM_STRIPE: Device fl0 created (id=3021002192). GEOM_STRIPE: Disk da0 attached to fl0. GEOM_STRIPE: Disk da1 attached to fl0. GEOM_STRIPE: Device fl0 activated. Trying to mount root from ufs:/dev/mirror/gm0s1a WARNING: / was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted /var: mount pending error: blocks 8 files 2 WARNING: /db was not properly dismounted /db: mount pending error: blocks 608512 files 1 WARNING: /flash0 was not properly dismounted em0: link state changed to UP >How-To-Repeat: Unsure, as all I did was the upgrade. >Fix: Unsure. Will attempt to temporarily disable soft-updates and the mirror rebuild to see whether the system will stay up for more than 30 mins. >Release-Note: >Audit-Trail: >Unformatted: From randy at psg.com Sun Apr 26 00:40:01 2009 From: randy at psg.com (Randy Bush) Date: Sun Apr 26 00:40:07 2009 Subject: amd64/134011: swap_pager_getswapspace(4): failed Message-ID: <200904260039.n3Q0dIpd012186@www.freebsd.org> >Number: 134011 >Category: amd64 >Synopsis: swap_pager_getswapspace(4): failed >Confidential: no >Severity: critical >Priority: high >Responsible: freebsd-amd64 >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Apr 26 00:40:01 UTC 2009 >Closed-Date: >Last-Modified: >Originator: Randy Bush >Release: 8-current Apr 25 12:52 >Organization: Internet Initiative Japan >Environment: FreeBSD work0.psg.com 8.0-CURRENT FreeBSD 8.0-CURRENT #1: Sat Apr 25 13:14:13 UTC 2009 root@work0.psg.com:/usr/obj/usr/src/sys/WORK0 amd64 >Description: midnight (gmt) maint runs on a number of 8-current systems. has been going on for weeks. swap_pager_getswapspace(16): failed swap_pager_getswapspace(16): failed swap_pager_getswapspace(16): failed swap_pager_getswapspace(2): failed swap_pager_getswapspace(2): failed swap_pager_getswapspace(2): failed swap_pager_getswapspace(2): failed many of these and then system either recovers or is dead to serial console. command prompt remains on ssh shells, but type a command and the shell is locked. system is pingable but non-responsive. the below are from when running normally in the case where it has recovered. work0.psg.com:/root# swapinfo Device 1024-blocks Used Avail Capacity /dev/mirror/bootb 8382708 307416 8075292 4% work0.psg.com:/root# df -m Filesystem 1M-blocks Used Avail Capacity Mounted on /dev/mirror/boota 7931 603 6693 8% / devfs 0 0 0 100% /dev procfs 0 0 0 100% /proc tank/data 663002 0 663002 0% /data tank/data/nfsen 828448 165446 663002 20% /data/nfsen tank/data/rpki 663179 177 663002 0% /data/rpki tank 663002 0 663002 0% /tank tank/usr 668072 5069 663002 1% /usr tank/usr/home 669874 6871 663002 1% /usr/home tank/usr/usr 668320 5317 663002 1% /usr/usr tank/var 663109 106 663002 0% /var tank/var/log 663105 103 663002 0% /var/log tank/var/spool 663171 168 663002 0% /var/spool tank/var/spool/var 663002 0 663002 0% /var/spool/var tank/var/spool/var/spool 663016 13 663002 0% /var/spool/var/spool /dev/md0 247 0 227 0% /tmp devfs 0 0 0 100% /data/rpki/rcynic/dev tank/usr@backup 668580 5578 663002 1% /usr/.zfs/snapshot/backup tank/usr/usr@2009-03-21-00-49-06 668341 5338 663002 1% /usr/usr/.zfs/snapshot/2009-03-21-00-49-06 tank/var/spool/var/spool@2009-03-21-02-06-08 663016 13 663002 0% /var/spool/var/spool/.zfs/snapshot/2009-03-21-02-06-08 work0.psg.com:/root# cat /etc/fstab # Device Mountpoint FStype Options Dump Pass# # /dev/mirror/boota / ufs rw 1 1 # /dev/mirror/bootb none swap sw 0 0 # /dev/acd0 /cdrom cd9660 ro,noauto 0 0 # proc /proc procfs rw 0 0 #linprocfs /compat/linux/proc linprocfs rw 0 0 # # end work0.psg.com:/root# top -bores last pid: 29419; load averages: 1.03, 0.46, 0.17 up 6+06:12:06 12:46:21 147 processes: 3 running, 144 sleeping Mem: 202M Active, 39M Inact, 1173M Wired, 2756K Cache, 39M Buf, 2540M Free Swap: 8186M Total, 300M Used, 7886M Free, 3% Inuse PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 1034 ejabberd 2 44 0 124M 51244K ucond 1 7:52 0.00% beam 803 unbound 1 44 0 36420K 24988K select 0 6:05 0.00% unbound 1370 root 1 76 0 225M 22056K nanslp 1 135:43 0.00% perl5.8.9 1229 mysql 9 44 0 66984K 21428K sigwai 1 4:05 0.00% mysqld 29159 www 1 47 0 98M 12824K lockf 0 0:01 0.00% httpd 28447 www 1 44 0 99328K 11968K lockf 0 0:01 0.00% httpd 29081 www 1 44 0 99328K 11836K lockf 0 0:01 0.00% httpd 29217 www 1 45 0 99328K 11600K lockf 1 0:00 1.27% httpd 27072 www 1 44 0 98304K 11064K lockf 0 0:01 0.00% httpd 29018 www 1 44 0 98304K 10912K kqread 1 0:00 0.00% httpd 29141 www 1 44 0 98304K 10840K lockf 0 0:00 0.00% httpd 37090 root 19 44 0 170M 8492K select 0 11:33 0.00% asterisk 28098 root 1 48 0 10528K 6592K select 0 0:17 7.08% cvsup 29222 www 1 44 0 96256K 5700K lockf 0 0:00 0.00% httpd 29306 www 1 44 0 96256K 5624K lockf 0 0:00 0.00% httpd 29337 www 1 44 0 96256K 4536K lockf 0 0:00 0.00% httpd 28072 root 1 44 0 17764K 3316K select 1 0:00 0.00% sshd 1302 root 1 44 0 96256K 2616K select 0 0:15 0.00% httpd work0.psg.com:/root# vmstat -h procs memory page disks faults cpu r b w avm fre flt re pi po fr sr ad4 ad6 in sy cs us sy id 0 0 10 4503M 2628M 219 0 0 2 470 423 0 0 205 2341 4388 2 1 97 >How-To-Repeat: wait for midnight work0.psg.com:/usr/src# cat /etc/daily.local #!/bin/sh # # # reset ipfw filter counts # ipfw -f resetlog ipfw -f zero # # mail and ntp # ( /usr/bin/ntpq -c peers ; echo ; echo ; \ echo irrd mirror requestors ; \ /usr/bin/gunzip -c /var/log/irrd/irrd.log.0.gz \ | for i in `grep 'rror request' | awk '{print $10}' | sort | uniq`; do \ host $i | awk '{print " " $5}'; done \ ; echo ; echo ; \ /usr/local/sbin/eximstats /var/spool/exim/log/main) \ | Mail -s "`hostname` ntp/mail log report" postmaster /usr/local/sbin/exicyclog #/usr/bin/gzip -9 main.01 # # system log # /usr/bin/gunzip -c /var/log/messages.0.gz | \ /usr/bin/egrep -iv '(last message repeated|logfile turned over|PAM: authentication error|reverse map|sshd.*(Did not receive identification string|Disabling protocol|does not map back|(ftp|uucp) not allowed|Invalid user|Failed password|accepted|connection closed|received disconnect|SSH: Server)|sshguard)' | \ /usr/bin/Mail -s "`hostname` System Log" root /usr/bin/gunzip -c /var/log/messages.0.gz | \ /usr/bin/egrep 'sshd.*((ftp|uucp) not allowed|Invalid user|Failed password)|sshguard' | \ /usr/bin/Mail -s "`hostname` attack Log" root # >Fix: >Release-Note: >Audit-Trail: >Unformatted: From fabian at wenks.ch Sun Apr 26 12:48:00 2009 From: fabian at wenks.ch (Fabian Wenk) Date: Sun Apr 26 12:48:07 2009 Subject: amd64/133977: "panic: ffs_blkfree: freeing free block" after 7.0R->7.1R amd64 src upgrade In-Reply-To: <200904241756.n3OHu0WI071774@www.freebsd.org> References: <200904241756.n3OHu0WI071774@www.freebsd.org> Message-ID: <49F457ED.10109@wenks.ch> Hello Rowan On 24.04.09 19:56, Rowan Crowe wrote: > This is what the panic output shows: > > ------ > dev = stripe/raid10, block = 1, fs = /db > panic: ffs_blkfree: freeing free block > cpuid = 1 > GEOM_MIRROR: Device db2: rebuilding provider ad16 stopped. > GEOM_MIRROR: Device db1: rebuilding provider ad12 stopped. > Uptime: 31m16s > Physical memory: 8183 MB > Dumping: 656 MB: > > ------ Boot into single user and try to do a manual fsck on all non / file systems, probably with the -y options to automatically answer all questions like this: fsck -y Hopefully this will run to the end, it can take several hours depending on the file system size and amount of files. I have never played with gmirror, so I don't know if this will work. Eventually you also can run the gmirror check manually in single user before doing fsck. Could it be, that one of your hard disk drives starts to fail or has corrupted sectors? Eventually you see some error messages in your logfiles. bye Fabian From randy at psg.com Mon Apr 27 08:40:03 2009 From: randy at psg.com (Randy Bush) Date: Mon Apr 27 08:40:09 2009 Subject: amd64/134011: swap_pager_getswapspace(4): failed Message-ID: <200904270840.n3R8e2DY099931@freefall.freebsd.org> The following reply was made to PR amd64/134011; it has been noted by GNATS. From: Randy Bush To: bug-followup@FreeBSD.org,randy@psg.com Cc: Subject: Re: amd64/134011: swap_pager_getswapspace(4): failed Date: Mon, 27 Apr 2009 17:31:41 +0900 bug is not restricted to amd64. here it is on an i386 system rip1.psg.com:/root# uname -a FreeBSD rip1.psg.com 8.0-CURRENT FreeBSD 8.0-CURRENT #9: Sun Apr 5 09:32:56 GMT 2009 root@rip1.psg.com:/usr/obj/usr/src/sys/RIP1 i386 Apr 25 00:07:46 rip1 kernel: swap_pager_getswapspace(16): failed Apr 25 00:07:47 rip1 kernel: swap_pager_getswapspace(12): failed Apr 25 00:07:47 rip1 kernel: swap_pager_getswapspace(6): failed Apr 25 00:07:47 rip1 kernel: swap_pager_getswapspace(16): failed Apr 25 00:07:47 rip1 kernel: swap_pager_getswapspace(12): failed Apr 25 00:07:47 rip1 kernel: swap_pager_getswapspace(9): failed Apr 25 00:07:47 rip1 kernel: swap_pager_getswapspace(5): failed Apr 25 00:07:47 rip1 kernel: swap_pager_getswapspace(16): failed Apr 25 00:07:47 rip1 kernel: pid 40337 (exim_tidydb), uid 0, was killed: out of swap space From bugmaster at FreeBSD.org Mon Apr 27 11:06:50 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Apr 27 11:26:41 2009 Subject: Current problem reports assigned to freebsd-amd64@FreeBSD.org Message-ID: <200904271106.n3RB6ntp002200@freefall.freebsd.org> 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 amd64/134011 amd64 swap_pager_getswapspace(4): failed o amd64/133977 amd64 [panic] [ffs] "panic: ffs_blkfree: freeing free block" o amd64/133701 amd64 Recompiling the kernel with k8temp or smbios break GEO o amd64/132574 amd64 [boot] Freeze on bootstrap loader (CD) using ATA/133 P o amd64/132170 amd64 7.1 kernel compilation problem o amd64/132019 amd64 [install] kernel trap 12 while installation o amd64/131906 amd64 [ata] SATA data corruption with Promise PDC20378 (amd6 o amd64/131456 amd64 ACPI & ATA problems o amd64/131314 amd64 [modules] [panic] large modules fail to load on amd64 o amd64/131209 amd64 [panic] [bce] 7.1-STABLE amd64 crash - m0 NULL f amd64/130885 amd64 sockstat(1) on amd64 does not work o amd64/130864 amd64 [hang] Problem with copying files to a large partition o amd64/130817 amd64 FreeBSD does not support HP DL160G5 [regression] o amd64/130494 amd64 [boot] netbooting BTX fails on amd64 o amd64/130483 amd64 [mxge] MSI must be disabled when Myricom 10Gbps Card i o amd64/130368 amd64 [hang] Switching from xorg to console locks up compute o amd64/129889 amd64 [boot] The booting process stops at the line mounting o amd64/129721 amd64 [hang] Motherboard K9N2G Neo-FD hangs on boot of 7.0-R o amd64/129667 amd64 [ata] Elitegroup A780GM-A IDE controller not recognize o amd64/129488 amd64 [smbfs] Kernel "bug" when using smbfs in smbfs_smb.c: o amd64/129426 amd64 [panic] FreeBSD 7.0 crash after subdiskXX: detached o amd64/129315 amd64 [boot] amd64 motherboard: Intel DG965WH motherboard co f amd64/128978 amd64 [install] FreeBSD 6.3 64-bit panics at boot time duri o amd64/128810 amd64 AMD 64 port installation o amd64/128765 amd64 [install] Install CD loads to Install choices but stop o amd64/128686 amd64 [ata] can't detect SATA Disk on 8.0-Current with NF550 o amd64/128263 amd64 [panic] 2 amd64 dl380 g5 with dual quadcore xeons, 8 a o amd64/128259 amd64 csh(1): "`" crashes csh o amd64/127640 amd64 gcc(1) will not build shared libraries with -fprofile- o amd64/127492 amd64 [zfs] System hang on ZFS input-output o amd64/127484 amd64 [timecounters] Drift problem with FreeBSD 7.0 and 7.1 o amd64/127451 amd64 [scheduler] incorrect load on quad core o amd64/127397 amd64 [amd64] 32bit application on FreeBSD-6.3 amd64 gets SI s amd64/127276 amd64 ldd(1) invokes linux yes o amd64/127129 amd64 mdconfig(8) is core dumping with Segmentation Fault 11 o amd64/125873 amd64 [smbd] [panic] Repeated kernel panics, trap 12 page fa o amd64/125002 amd64 [install] amd64, SATA hard disks not detected o amd64/124432 amd64 [panic] 7.0-STABLE panic: invalbuf: dirty bufs o amd64/124134 amd64 [kernel] The kernel doesn't follow the calling convent o amd64/123562 amd64 [install] FreeBSD amd64 not installs o amd64/123520 amd64 [ahd] unable to boot from net while using ahd o amd64/123456 amd64 fstat(1): /usr/bin/fstat shows error messages and hang f amd64/123275 amd64 [cbb] [pcmcia] cbb/pcmcia drivers on amd64 failure [re o kern/122782 amd64 [modules] accf_http.ko kernel module is not loadable o amd64/122695 amd64 [cpufreq] Lack of cpufreq control using amd64 eith cor o amd64/122624 amd64 unusable minimal installation of FreeBSD-7.0 o amd64/122549 amd64 7.0-RELEASE-amd64-bootonly.iso doesn't work w/ serial o amd64/122468 amd64 Compile problems after upgrading to 7.0 o amd64/122174 amd64 [panic] 7.0 no longer includes "device atpic" so fails o amd64/121590 amd64 [est] [p4tcc] [acpi_perf] setting dev.cpu.0.freq somet o amd64/121439 amd64 [boot] Installation of FreeBSD 7.0 fails: ACPI problem o amd64/120202 amd64 [amd64] [patch] [panic] kernel panic at start_all_aps, o amd64/119591 amd64 [amd64] [patch] time_t on 64-bit architecture o amd64/117418 amd64 [hang] FreeBSD 6.2 crash on amd64 4400+ with ssh o amd64/117316 amd64 [acpi] ACPI lockups on SuperMicro motherboard o amd64/117296 amd64 [ata] I don`t see second SATA IDE on VIA VT8237A a amd64/117186 amd64 [modules] kldload Unsupported file type on STABLE amd6 s amd64/116689 amd64 [request] support for MSI K9MM-V o amd64/116620 amd64 [hang] ifconfig spins when creating carp(4) device on o amd64/116322 amd64 [panic] At start fsck on current, the system panics o amd64/116159 amd64 [panic] Panic while debugging on CURRENT s amd64/115815 amd64 [ata] [request] Gigabyte GA-M61P-S3 Motherboard unsupp o amd64/115581 amd64 [Makefile] [patch] -mfancy-math-387 has no effect o amd64/115194 amd64 LCD screen remains blank after Dell XPS M1210 lid is c o amd64/114270 amd64 [cpufreq] cpufreq doesnt work when compiled in to kern o amd64/114111 amd64 [nfs] System crashes while writing on NFS-mounted shar o amd64/112222 amd64 [libc] 32-bit libc incorrectly converts some FP number o amd64/110599 amd64 [geli] geli attach to gmirror device hangs and cannot s amd64/108861 amd64 [nve] nve(4) driver on FreeBSD 6.2 AMD64 does not work o amd64/106186 amd64 [panic] panic in swap_pager_swap_init (amd64/smp/6.2-p f amd64/105531 amd64 [ata] gigabyte GA-M51GM-S2G / nVidia nForce 430 - does f amd64/105514 amd64 [boot] FreeBSD/amd64 - Fails to boot on HP Pavilion dv o amd64/102716 amd64 ex with no argument in an xterm gets SIGSEGV o amd64/97337 amd64 [dri] xorg reboots system if dri module is enabled o amd64/95888 amd64 [ata] kernel: ad2: TIMEOUT - WRITE_DMA retrying on HP o amd64/94677 amd64 [panic] panic in amd64 install at non-root user creati o amd64/93961 amd64 [busdma] Problem in bounce buffer handling in sys/amd6 o amd64/92337 amd64 [em] FreeBSD 6.0 Release Intel Pro 1000 MT em1 no buff o amd64/91405 amd64 [asr] [panic] Kernel panic caused by asr on 6.0-amd64 o amd64/89501 amd64 [install] System crashes on install using ftp on local o amd64/88790 amd64 [panic] kernel panic on first boot (after the FreeBSD o amd64/88568 amd64 [panic] 6.0-RELEASE install cd does not boot with usb o amd64/87689 amd64 [powerd] [hang] powerd hangs SMP Opteron 244 5-STABLE o amd64/87316 amd64 [vge] "vge0 attach returned 6" on FreeBSD 6.0-RC1 amd6 o amd64/87305 amd64 [smp] Dual Opteron / FreeBSD 5 & 6 / powerd results in s amd64/85273 amd64 [install] FreeBSD (NetBSD or OpenBSD) not install on l o amd64/78406 amd64 [panic]AMD64 w/ SCSI: issue 'rm -r /usr/ports' and sys o amd64/76136 amd64 [hang] system halts before reboot o amd64/74747 amd64 [panic] System panic on shutdown when process will not f amd64/73322 amd64 [msdosfs] [hang] unarchiving /etc to msdosfs locks up 90 problems total. From tom.hurst at clara.net Thu Apr 30 19:38:52 2009 From: tom.hurst at clara.net (Thomas Hurst) Date: Thu Apr 30 19:38:59 2009 Subject: amd64/134011: swap_pager_getswapspace(4): failed In-Reply-To: <200904270840.n3R8e2DY099931@freefall.freebsd.org> References: <200904270840.n3R8e2DY099931@freefall.freebsd.org> Message-ID: <20090430190857.GA82277@voi.aagh.net> * Randy Bush (randy@psg.com) wrote: > rip1.psg.com:/root# uname -a > FreeBSD rip1.psg.com 8.0-CURRENT FreeBSD 8.0-CURRENT #9: Sun Apr 5 09:32:56 GMT 2009 root@rip1.psg.com:/usr/obj/usr/src/sys/RIP1 i386 > Apr 25 00:07:47 rip1 kernel: swap_pager_getswapspace(16): failed > Apr 25 00:07:47 rip1 kernel: pid 40337 (exim_tidydb), uid 0, was killed: out of swap space I saw this about a week ago, on a freshly supped and built CURRENT: 2053 root 1 115 0 5966M 5921M CPU3 3 0:23 86.47% exim_tidydb The exim queue was empty. The only other thing of note running was a 11GB mysqld (5.4, which ran about 2-3000x slower than expected). -- Thomas 'Freaky' Hurst http://hur.st/ From ler at lerctr.org Thu Apr 30 20:42:30 2009 From: ler at lerctr.org (Larry Rosenman) Date: Thu Apr 30 20:42:37 2009 Subject: amd64/134011: swap_pager_getswapspace(4): failed In-Reply-To: <20090430190857.GA82277@voi.aagh.net> References: <200904270840.n3R8e2DY099931@freefall.freebsd.org> <20090430190857.GA82277@voi.aagh.net> Message-ID: <004801c9c9d2$03e0d070$0ba27150$@org> I saw this as well. I believe something(tm) changed in the on disk db file format, such that exim_tidydb running with the new libc had issues. I just wiped my db/* directory (they are just caches, they are expendable), and restarted exim. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 -----Original Message----- From: owner-freebsd-amd64@freebsd.org [mailto:owner-freebsd-amd64@freebsd.org] On Behalf Of Thomas Hurst Sent: Thursday, April 30, 2009 2:09 PM To: Randy Bush Cc: freebsd-amd64@FreeBSD.org Subject: Re: amd64/134011: swap_pager_getswapspace(4): failed * Randy Bush (randy@psg.com) wrote: > rip1.psg.com:/root# uname -a > FreeBSD rip1.psg.com 8.0-CURRENT FreeBSD 8.0-CURRENT #9: Sun Apr 5 09:32:56 GMT 2009 root@rip1.psg.com:/usr/obj/usr/src/sys/RIP1 i386 > Apr 25 00:07:47 rip1 kernel: swap_pager_getswapspace(16): failed > Apr 25 00:07:47 rip1 kernel: pid 40337 (exim_tidydb), uid 0, was killed: out of swap space I saw this about a week ago, on a freshly supped and built CURRENT: 2053 root 1 115 0 5966M 5921M CPU3 3 0:23 86.47% exim_tidydb The exim queue was empty. The only other thing of note running was a 11GB mysqld (5.4, which ran about 2-3000x slower than expected). -- Thomas 'Freaky' Hurst http://hur.st/ _______________________________________________ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscribe@freebsd.org" From ler at lerctr.org Thu Apr 30 22:05:15 2009 From: ler at lerctr.org (Larry Rosenman) Date: Thu Apr 30 22:05:22 2009 Subject: amd64/134011: swap_pager_getswapspace(4): failed In-Reply-To: <20090430213340.GA7070@voi.aagh.net> References: <200904270840.n3R8e2DY099931@freefall.freebsd.org> <20090430190857.GA82277@voi.aagh.net> <004801c9c9d2$03e0d070$0ba27150$@org> <20090430213340.GA7070@voi.aagh.net> Message-ID: <00be01c9c9df$bca3a120$35eae360$@org> How was Exim installed? From packages or compiled on the system? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 -----Original Message----- From: Thomas Hurst [mailto:tom@hur.st] Sent: Thursday, April 30, 2009 4:34 PM To: Larry Rosenman Cc: 'Randy Bush'; freebsd-amd64@FreeBSD.org Subject: Re: amd64/134011: swap_pager_getswapspace(4): failed * Larry Rosenman (ler@lerctr.org) wrote: > I saw this as well. I believe something(tm) changed in the on disk db file > format, such that exim_tidydb running with the new libc had issues. I just > wiped my db/* directory (they are just caches, they are expendable), and > restarted exim. This was on a freshly installed system, though, shouldn't have been anything from previous installs on it. -- Thomas 'Freaky' Hurst http://hur.st/ From tom at hur.st Thu Apr 30 22:08:53 2009 From: tom at hur.st (Thomas Hurst) Date: Thu Apr 30 22:27:16 2009 Subject: amd64/134011: swap_pager_getswapspace(4): failed In-Reply-To: <004801c9c9d2$03e0d070$0ba27150$@org> References: <200904270840.n3R8e2DY099931@freefall.freebsd.org> <20090430190857.GA82277@voi.aagh.net> <004801c9c9d2$03e0d070$0ba27150$@org> Message-ID: <20090430213340.GA7070@voi.aagh.net> * Larry Rosenman (ler@lerctr.org) wrote: > I saw this as well. I believe something(tm) changed in the on disk db file > format, such that exim_tidydb running with the new libc had issues. I just > wiped my db/* directory (they are just caches, they are expendable), and > restarted exim. This was on a freshly installed system, though, shouldn't have been anything from previous installs on it. -- Thomas 'Freaky' Hurst http://hur.st/