From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 5 12:12:02 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47EEC106564A for ; Sun, 5 Apr 2009 12:12:02 +0000 (UTC) (envelope-from hansot@iae.nl) Received: from smtp-vbr9.xs4all.nl (smtp-vbr9.xs4all.nl [194.109.24.29]) by mx1.freebsd.org (Postfix) with ESMTP id A3D9F8FC19 for ; Sun, 5 Apr 2009 12:12:01 +0000 (UTC) (envelope-from hansot@iae.nl) Received: from merom.hotsoft.nl (beasties.demon.nl [82.161.3.114]) by smtp-vbr9.xs4all.nl (8.13.8/8.13.8) with ESMTP id n35BpjYs078494 for ; Sun, 5 Apr 2009 13:51:45 +0200 (CEST) (envelope-from hansot@iae.nl) Message-ID: <49D89B50.3000304@iae.nl> Date: Sun, 05 Apr 2009 13:51:44 +0200 From: Hans Ottevanger User-Agent: Thunderbird 2.0.0.21 (X11/20090322) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: multipart/mixed; boundary="------------090600010407000403070006" X-Virus-Scanned: by XS4ALL Virus Scanner Subject: mlockall() failure and direction for possible solution X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2009 12:12:02 -0000 This is a multi-part message in MIME format. --------------090600010407000403070006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi folks, As has been noted before, there is an issue with the mlockall() system call always failing on (at least) the amd64 architecture. This is quite evident by the automounter (as configured out-of-the-box) printing error messages on startup like: Couldn't lock process pages in memory using mlockall() I have verified the occurrence of this issue on the amd64 platform on 7.1-STABLE and 8.0-CURRENT. On the i386 platform this problem does not occur. To investigate this issue a bit further I ran the following trivial program: #include #include #include #include int main(int argc, char *argv[]) { if (mlockall(MCL_CURRENT|MCL_FUTURE) == -1) perror(argv[0]); char command[80]; snprintf(command, 80, "procstat -v %d", getpid()); system(command); exit(0); } which yields (using CURRENT-8.0 as of today, on an Intel DP965LT board with a Q6600 and 8 Gbyte RAM, GENERIC kernel stripped of unused devices, output folded to 72 characters per line): /mltest: Resource temporarily unavailable PID START END PRT RES PRES REF SHD FL TP PATH 1064 0x400000 0x401000 r-x 1 0 1 0 CN vn /root/mlockall/mltest 1064 0x500000 0x501000 rw- 1 0 1 0 CN df 1064 0x501000 0x600000 rwx 255 0 1 0 -- df 1064 0x800500000 0x80052c000 r-x 44 0 64 31 CN vn /libexec/ld-elf.so.1 1064 0x80052c000 0x800534000 rw- 8 0 1 0 C- df 1064 0x80062b000 0x800633000 rw- 8 0 1 0 CN vn /libexec/ld-elf.so.1 1064 0x800633000 0x80063f000 rw- 12 0 1 0 C- df 1064 0x80063f000 0x80072e000 r-x 239 0 128 62 CN vn /lib/libc.so.7 1064 0x80072e000 0x80072f000 r-x 1 0 1 0 CN vn /lib/libc.so.7 1064 0x80072f000 0x80082f000 r-x 51 0 128 62 CN vn /lib/libc.so.7 1064 0x80082f000 0x80084f000 rw- 32 0 1 0 C- vn /lib/libc.so.7 1064 0x80084f000 0x800865000 rw- 6 0 1 0 CN df 1064 0x800900000 0x800965000 rw- 101 0 1 0 -- df 1064 0x800965000 0x800a00000 rw- 155 0 1 0 -- df 1064 0x7ffffffe0000 0x800000000000 rwx 3 0 1 0 C- df I have hunted down the exact location in the kernel where the call to mlockall() returns an error (just using printf's, debugging using Firewire proved not to be as trivial to set up as it was just a few years ago). It appears that while wiring the memory, finally vm_fault() is called and it bails out at line 412 of vm_fault.c. The virtual address of the page that the system is attempting to wire (argument vaddr of vm_fault()) is 0x800762000. From the procstat output above it appears that this in the third region backed by /lib/libc.so.7. This made me think that the issue might be somehow related to the way in which dynamic libraries are linked on runtime. Indeed, if above program is linked -statically- it does not fail. Also if the program in compiled and linked -dynamically- on a i386 platform and run on an amd64, it runs successfully. To make a long story at least a bit shorter, I found that the problem is in /usr/src/libexec/rtld_elf/map_object.c at line 156. Here a contiguous region is staked out for the code and data. For the amd64, where the required alignment of the segments is 1 Mbytes, this causes a region to be mapped that is far larger than the library file by which it is backed. Addresses that are not backed by the file cannot be resident and hence the region cannot be locked into memory. On the i386 architecture this problem does not occur since the alignment of the segments is just 4 Kbytes. I suspect that the problem also occurs at least on the sparc64 architecture. As a first step to a possible solution you can apply the attached (provisional) patch, that uses an anonymous, read-only mapping to create the required region. The output of the above program then becomes: PID START END PRT RES PRES REF SHD FL TP PATH 1302 0x400000 0x401000 r-x 1 0 1 0 CN vn /root/mlockall/mltest 1302 0x500000 0x501000 rw- 1 0 1 0 -- df 1302 0x800500000 0x80052c000 r-x 44 0 8 4 CN vn /libexec/ld-elf.so.1 1302 0x80052c000 0x800534000 rw- 8 0 1 0 -- df 1302 0x80062b000 0x800633000 rw- 8 0 1 0 C- vn /libexec/ld-elf.so.1 1302 0x800633000 0x80063f000 rw- 12 0 1 0 -- df 1302 0x80063f000 0x80072e000 r-x 239 0 124 62 CN vn /lib/libc.so.7 1302 0x80072e000 0x80072f000 r-x 1 0 1 0 C- vn /lib/libc.so.7 1302 0x80072f000 0x80082f000 r-- 256 0 1 0 -- df 1302 0x80082f000 0x80084f000 rw- 32 0 1 0 C- vn /lib/libc.so.7 1302 0x80084f000 0x800865000 rw- 22 0 1 0 -- df 1302 0x7ffffffe0000 0x800000000000 rwx 32 0 1 0 -- df i.e. mlockall() does not return an error anymore. I still have the following questions: 1. Is worth the trouble to solve the mlockall() problem at all ? Should I file a PR ? 2. Can someone confirm that it also occurs on the other 64 bit architectures ? 3. It might be more elegant to use PROT_NONE instead of PROT_READ when just staking out the address space. Currently mlockall() returns an error when attempting that, so most likely mlockall() would need to be changed to ignore regions mapped with PROT_NONE. On the other hand, the pthread implementation uses PROT_NONE to create red zones on the stack and mlockall() apparently succeeds with threaded applications (using the provided patch). Any opinions/ideas/hints ? Kind regards, Hans --------------090600010407000403070006 Content-Type: text/plain; name="rtld.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="rtld.diff" Index: map_object.c =================================================================== RCS file: /home/ncvs/src/libexec/rtld-elf/map_object.c,v retrieving revision 1.19 diff -u -r1.19 map_object.c --- map_object.c 18 Mar 2009 13:40:37 -0000 1.19 +++ map_object.c 5 Apr 2009 10:53:31 -0000 @@ -153,8 +153,8 @@ mapsize = base_vlimit - base_vaddr; base_addr = hdr->e_type == ET_EXEC ? (caddr_t) base_vaddr : NULL; - mapbase = mmap(base_addr, mapsize, convert_prot(segs[0]->p_flags), - convert_flags(segs[0]->p_flags), fd, base_offset); + mapbase = mmap(base_addr, mapsize, PROT_READ, + MAP_NOCORE|MAP_ANON, -1, 0); if (mapbase == (caddr_t) -1) { _rtld_error("%s: mmap of entire address space failed: %s", path, strerror(errno)); @@ -175,8 +175,7 @@ data_addr = mapbase + (data_vaddr - base_vaddr); data_prot = convert_prot(segs[i]->p_flags); data_flags = convert_flags(segs[i]->p_flags) | MAP_FIXED; - /* Do not call mmap on the first segment - this is redundant */ - if (i && mmap(data_addr, data_vlimit - data_vaddr, data_prot, + if (mmap(data_addr, data_vlimit - data_vaddr, data_prot, data_flags, fd, data_offset) == (caddr_t) -1) { _rtld_error("%s: mmap of data failed: %s", path, strerror(errno)); return NULL; --------------090600010407000403070006-- From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 5 15:59:24 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CB9B106564A for ; Sun, 5 Apr 2009 15:59:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id AA78D8FC18 for ; Sun, 5 Apr 2009 15:59:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1LqUkk-000NHQ-9Z; Sun, 05 Apr 2009 18:59:22 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n35FxJ3Y085098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 5 Apr 2009 18:59:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n35FxILw076224; Sun, 5 Apr 2009 18:59:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n35FxIM3076223; Sun, 5 Apr 2009 18:59:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 5 Apr 2009 18:59:18 +0300 From: Kostik Belousov To: Hans Ottevanger Message-ID: <20090405155918.GO31897@deviant.kiev.zoral.com.ua> References: <49D89B50.3000304@iae.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TabdQyBgAIOfnE51" Content-Disposition: inline In-Reply-To: <49D89B50.3000304@iae.nl> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1LqUkk-000NHQ-9Z c7bf50a149c24f3cbab0216252ed5dd6 X-Terabit: YES Cc: freebsd-hackers@freebsd.org Subject: Re: mlockall() failure and direction for possible solution X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2009 15:59:24 -0000 --TabdQyBgAIOfnE51 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 05, 2009 at 01:51:44PM +0200, Hans Ottevanger wrote: > Hi folks, >=20 > As has been noted before, there is an issue with the mlockall() system > call always failing on (at least) the amd64 architecture. This is quite > evident by the automounter (as configured out-of-the-box) printing error > messages on startup like: >=20 > Couldn't lock process pages in memory using mlockall() >=20 > I have verified the occurrence of this issue on the amd64 platform on > 7.1-STABLE and 8.0-CURRENT. On the i386 platform this problem does not > occur. >=20 > To investigate this issue a bit further I ran the following trivial progr= am: >=20 > #include > #include > #include > #include >=20 > int main(int argc, char *argv[]) > { > if (mlockall(MCL_CURRENT|MCL_FUTURE) =3D=3D -1) > perror(argv[0]); >=20 > char command[80]; > snprintf(command, 80, "procstat -v %d", getpid()); > system(command); >=20 > exit(0); > } >=20 > which yields (using CURRENT-8.0 as of today, on an Intel DP965LT board > with a Q6600 and 8 Gbyte RAM, GENERIC kernel stripped of unused devices, > output folded to 72 characters per line): >=20 > /mltest: Resource temporarily unavailable > PID START END PRT RES PRES REF SHD FL TP > PATH > 1064 0x400000 0x401000 r-x 1 0 1 0 CN vn > /root/mlockall/mltest > 1064 0x500000 0x501000 rw- 1 0 1 0 CN df > 1064 0x501000 0x600000 rwx 255 0 1 0 -- df > 1064 0x800500000 0x80052c000 r-x 44 0 64 31 CN vn > /libexec/ld-elf.so.1 > 1064 0x80052c000 0x800534000 rw- 8 0 1 0 C- df > 1064 0x80062b000 0x800633000 rw- 8 0 1 0 CN vn > /libexec/ld-elf.so.1 > 1064 0x800633000 0x80063f000 rw- 12 0 1 0 C- df > 1064 0x80063f000 0x80072e000 r-x 239 0 128 62 CN vn > /lib/libc.so.7 > 1064 0x80072e000 0x80072f000 r-x 1 0 1 0 CN vn > /lib/libc.so.7 > 1064 0x80072f000 0x80082f000 r-x 51 0 128 62 CN vn > /lib/libc.so.7 > 1064 0x80082f000 0x80084f000 rw- 32 0 1 0 C- vn > /lib/libc.so.7 > 1064 0x80084f000 0x800865000 rw- 6 0 1 0 CN df > 1064 0x800900000 0x800965000 rw- 101 0 1 0 -- df > 1064 0x800965000 0x800a00000 rw- 155 0 1 0 -- df > 1064 0x7ffffffe0000 0x800000000000 rwx 3 0 1 0 C- df >=20 > I have hunted down the exact location in the kernel where the call to=20 > mlockall() returns an error (just using printf's, debugging using=20 > Firewire proved not to be as trivial to set up as it was just a few=20 > years ago). It appears that while wiring the memory, finally vm_fault()= =20 > is called and it bails out at line 412 of vm_fault.c. The virtual=20 > address of the page that the system is attempting to wire (argument=20 > vaddr of vm_fault()) is 0x800762000. From the procstat output above it=20 > appears that this in the third region backed by /lib/libc.so.7. >=20 > This made me think that the issue might be somehow related to the way in= =20 > which dynamic libraries are linked on runtime. Indeed, if above program= =20 > is linked -statically- it does not fail. Also if the program in compiled= =20 > and linked -dynamically- on a i386 platform and run on an amd64, it runs= =20 > successfully. >=20 > To make a long story at least a bit shorter, I found that the problem is= =20 > in /usr/src/libexec/rtld_elf/map_object.c at line 156. Here a contiguous= =20 > region is staked out for the code and data. For the amd64, where the=20 > required alignment of the segments is 1 Mbytes, this causes a region to= =20 > be mapped that is far larger than the library file by which it is=20 > backed. Addresses that are not backed by the file cannot be resident and= =20 > hence the region cannot be locked into memory. On the i386 architecture= =20 > this problem does not occur since the alignment of the segments is just= =20 > 4 Kbytes. I suspect that the problem also occurs at least on the sparc64= =20 > architecture. >=20 > As a first step to a possible solution you can apply the attached=20 > (provisional) patch, that uses an anonymous, read-only mapping to create= =20 > the required region. >=20 > The output of the above program then becomes: >=20 > PID START END PRT RES PRES REF SHD FL TP > PATH > 1302 0x400000 0x401000 r-x 1 0 1 0 CN vn > /root/mlockall/mltest > 1302 0x500000 0x501000 rw- 1 0 1 0 -- df > 1302 0x800500000 0x80052c000 r-x 44 0 8 4 CN vn > /libexec/ld-elf.so.1 > 1302 0x80052c000 0x800534000 rw- 8 0 1 0 -- df > 1302 0x80062b000 0x800633000 rw- 8 0 1 0 C- vn > /libexec/ld-elf.so.1 > 1302 0x800633000 0x80063f000 rw- 12 0 1 0 -- df > 1302 0x80063f000 0x80072e000 r-x 239 0 124 62 CN vn > /lib/libc.so.7 > 1302 0x80072e000 0x80072f000 r-x 1 0 1 0 C- vn > /lib/libc.so.7 > 1302 0x80072f000 0x80082f000 r-- 256 0 1 0 -- df > 1302 0x80082f000 0x80084f000 rw- 32 0 1 0 C- vn > /lib/libc.so.7 > 1302 0x80084f000 0x800865000 rw- 22 0 1 0 -- df > 1302 0x7ffffffe0000 0x800000000000 rwx 32 0 1 0 -- df >=20 > i.e. mlockall() does not return an error anymore. >=20 > I still have the following questions: >=20 > 1. Is worth the trouble to solve the mlockall() problem at all ? Should= =20 > I file a PR ? Yes. Do as you want, but I see no reason. Your analisys looks correct and useful. >=20 > 2. Can someone confirm that it also occurs on the other 64 bit=20 > architectures ? >=20 > 3. It might be more elegant to use PROT_NONE instead of PROT_READ when=20 > just staking out the address space. Currently mlockall() returns an=20 > error when attempting that, so most likely mlockall() would need to be=20 > changed to ignore regions mapped with PROT_NONE. On the other hand, the= =20 > pthread implementation uses PROT_NONE to create red zones on the stack=20 > and mlockall() apparently succeeds with threaded applications (using the= =20 > provided patch). Any opinions/ideas/hints ? I think that it is better to unmap the holes, instead of making some mapping. Please, try this patch instead. diff --git a/libexec/rtld-elf/map_object.c b/libexec/rtld-elf/map_object.c index 2d06074..3266af0 100644 --- a/libexec/rtld-elf/map_object.c +++ b/libexec/rtld-elf/map_object.c @@ -83,6 +83,7 @@ map_object(int fd, const char *path, const struct stat *s= b) Elf_Addr bss_vaddr; Elf_Addr bss_vlimit; caddr_t bss_addr; + size_t hole; =20 hdr =3D get_elf_header(fd, path); if (hdr =3D=3D NULL) @@ -91,8 +92,7 @@ map_object(int fd, const char *path, const struct stat *s= b) /* * Scan the program header entries, and save key information. * - * We rely on there being exactly two load segments, text and data, - * in that order. + * We expect that the loadable segments are ordered by load address. */ phdr =3D (Elf_Phdr *) ((char *)hdr + hdr->e_phoff); phsize =3D hdr->e_phnum * sizeof (phdr[0]); @@ -214,6 +214,17 @@ map_object(int fd, const char *path, const struct stat= *sb) return NULL; } } + + /* Unmap the region between two non-adjusted ELF segments */ + if (i < nsegs) { + hole =3D trunc_page(segs[i + 1]->p_vaddr) - bss_vlimit; + if (hole > 0 && munmap(mapbase + bss_vlimit, hole) =3D=3D -1) { + _rtld_error("%s: munmap hole failed: %s", path, + strerror(errno)); + return NULL; + } + } + if (phdr_vaddr =3D=3D 0 && data_offset <=3D hdr->e_phoff && (data_vlimit - data_vaddr + data_offset) >=3D (hdr->e_phoff + hdr->e_phnum * sizeof (Elf_Phdr))) { --TabdQyBgAIOfnE51 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAknY1VUACgkQC3+MBN1Mb4hEigCgom6yh9eRWYFm0ALLVCip2Lum o94AoNWvC7V0iljTBaCKZxPpHtrcEcYT =OEJG -----END PGP SIGNATURE----- --TabdQyBgAIOfnE51-- From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 5 16:24:26 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 297EE106566C for ; Sun, 5 Apr 2009 16:24:26 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms173015pub.verizon.net (vms173015pub.verizon.net [206.46.173.15]) by mx1.freebsd.org (Postfix) with ESMTP id 098FF8FC26 for ; Sun, 5 Apr 2009 16:24:25 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms124.mailsrvcs.net ([172.18.12.134]) by vms173015.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KHM0050EYVF3WDM@vms173015.mailsrvcs.net>; Sun, 05 Apr 2009 11:23:39 -0500 (CDT) Received: from 96.234.43.209 ([96.234.43.209]) by vms124.mailsrvcs.net (Verizon Webmail) with HTTP; Sun, 05 Apr 2009 11:23:39 -0500 (CDT) Date: Sun, 05 Apr 2009 11:23:39 -0500 (CDT) From: Sergey Babkin To: ivoras@freebsd.org Message-id: <1366225354.253456.1238948619308.JavaMail.root@vms124.mailsrvcs.net> Content-transfer-encoding: quoted-printable X-Originating-IP: [96.234.43.209] X-Mailman-Approved-At: Sun, 05 Apr 2009 17:04:45 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: Patch for MS Hyper V (virtualization) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2009 16:24:26 -0000 Apr 4, 2009 02:10:23 PM, ivoras@freebsd.org wrote: >Can someo= ne please review and commit (if appropriate) the tweak for >Hyper-V shu= tdown issue at http://shell.peach.ne.jp/aoyama/archives/40 >? > = >>The problem is: the VM appears to hang on shutdown without it (hanging >the Hyper-V VM with it so the host also can't shutdown or reboot >re= liably - someone at MS skipped the part where an error in the VM >isn't= supposed to bring the host down with it) I don't have the commit = permission any more but I can review :-) Yes, Hyper-V does not like th= e writes into the PCI config space. Very specifically, writing the base= register window address of the simulated 21140 screws up something tha= t prevents the VM from shutting down. Interestingly, even reading and writi= ng back the same value has this effect. So the patch is valid. = >I don't particularly like the hackish checking for the 21140 chip, and I'= m not sure if if would break some real 21140 chip out there. If the dri= ver does the same as another one I've seen, the driver tries to align t= he register window to 0x80, and in the simulated 21140 it's already ali= gned. I've had a quick look but couldn't say it for sure. I'd do it dif= ferently: check if the value being written is the same that was read, = and skip the write in this case. Let me see, maybe I'll make a dif= ferent patch. -SB From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 5 18:42:59 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9D881065686 for ; Sun, 5 Apr 2009 18:42:59 +0000 (UTC) (envelope-from fbsdhackers@beasties.demon.nl) Received: from smtp-vbr3.xs4all.nl (smtp-vbr3.xs4all.nl [194.109.24.23]) by mx1.freebsd.org (Postfix) with ESMTP id 6DC2A8FC21 for ; Sun, 5 Apr 2009 18:42:59 +0000 (UTC) (envelope-from fbsdhackers@beasties.demon.nl) Received: from merom.hotsoft.nl (beasties.demon.nl [82.161.3.114]) by smtp-vbr3.xs4all.nl (8.13.8/8.13.8) with ESMTP id n35IQl5M068218; Sun, 5 Apr 2009 20:26:47 +0200 (CEST) (envelope-from fbsdhackers@beasties.demon.nl) Message-ID: <49D8F7E6.8010105@beasties.demon.nl> Date: Sun, 05 Apr 2009 20:26:46 +0200 From: Hans Ottevanger User-Agent: Thunderbird 2.0.0.21 (X11/20090322) MIME-Version: 1.0 To: Kostik Belousov References: <49D89B50.3000304@iae.nl> <20090405155918.GO31897@deviant.kiev.zoral.com.ua> In-Reply-To: <20090405155918.GO31897@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-hackers@freebsd.org Subject: Re: mlockall() failure and direction for possible solution X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2009 18:43:01 -0000 Kostik Belousov wrote: > On Sun, Apr 05, 2009 at 01:51:44PM +0200, Hans Ottevanger wrote: >> Hi folks, >> >> As has been noted before, there is an issue with the mlockall() system >> call always failing on (at least) the amd64 architecture. This is quite >> evident by the automounter (as configured out-of-the-box) printing error >> messages on startup like: >> >> Couldn't lock process pages in memory using mlockall() >> >> I have verified the occurrence of this issue on the amd64 platform on >> 7.1-STABLE and 8.0-CURRENT. On the i386 platform this problem does not >> occur. >> >> To investigate this issue a bit further I ran the following trivial program: >> >> #include >> #include >> #include >> #include >> >> int main(int argc, char *argv[]) >> { >> if (mlockall(MCL_CURRENT|MCL_FUTURE) == -1) >> perror(argv[0]); >> >> char command[80]; >> snprintf(command, 80, "procstat -v %d", getpid()); >> system(command); >> >> exit(0); >> } >> >> which yields (using CURRENT-8.0 as of today, on an Intel DP965LT board >> with a Q6600 and 8 Gbyte RAM, GENERIC kernel stripped of unused devices, >> output folded to 72 characters per line): >> >> /mltest: Resource temporarily unavailable >> PID START END PRT RES PRES REF SHD FL TP >> PATH >> 1064 0x400000 0x401000 r-x 1 0 1 0 CN vn >> /root/mlockall/mltest >> 1064 0x500000 0x501000 rw- 1 0 1 0 CN df >> 1064 0x501000 0x600000 rwx 255 0 1 0 -- df >> 1064 0x800500000 0x80052c000 r-x 44 0 64 31 CN vn >> /libexec/ld-elf.so.1 >> 1064 0x80052c000 0x800534000 rw- 8 0 1 0 C- df >> 1064 0x80062b000 0x800633000 rw- 8 0 1 0 CN vn >> /libexec/ld-elf.so.1 >> 1064 0x800633000 0x80063f000 rw- 12 0 1 0 C- df >> 1064 0x80063f000 0x80072e000 r-x 239 0 128 62 CN vn >> /lib/libc.so.7 >> 1064 0x80072e000 0x80072f000 r-x 1 0 1 0 CN vn >> /lib/libc.so.7 >> 1064 0x80072f000 0x80082f000 r-x 51 0 128 62 CN vn >> /lib/libc.so.7 >> 1064 0x80082f000 0x80084f000 rw- 32 0 1 0 C- vn >> /lib/libc.so.7 >> 1064 0x80084f000 0x800865000 rw- 6 0 1 0 CN df >> 1064 0x800900000 0x800965000 rw- 101 0 1 0 -- df >> 1064 0x800965000 0x800a00000 rw- 155 0 1 0 -- df >> 1064 0x7ffffffe0000 0x800000000000 rwx 3 0 1 0 C- df >> >> I have hunted down the exact location in the kernel where the call to >> mlockall() returns an error (just using printf's, debugging using >> Firewire proved not to be as trivial to set up as it was just a few >> years ago). It appears that while wiring the memory, finally vm_fault() >> is called and it bails out at line 412 of vm_fault.c. The virtual >> address of the page that the system is attempting to wire (argument >> vaddr of vm_fault()) is 0x800762000. From the procstat output above it >> appears that this in the third region backed by /lib/libc.so.7. >> >> This made me think that the issue might be somehow related to the way in >> which dynamic libraries are linked on runtime. Indeed, if above program >> is linked -statically- it does not fail. Also if the program in compiled >> and linked -dynamically- on a i386 platform and run on an amd64, it runs >> successfully. >> >> To make a long story at least a bit shorter, I found that the problem is >> in /usr/src/libexec/rtld_elf/map_object.c at line 156. Here a contiguous >> region is staked out for the code and data. For the amd64, where the >> required alignment of the segments is 1 Mbytes, this causes a region to >> be mapped that is far larger than the library file by which it is >> backed. Addresses that are not backed by the file cannot be resident and >> hence the region cannot be locked into memory. On the i386 architecture >> this problem does not occur since the alignment of the segments is just >> 4 Kbytes. I suspect that the problem also occurs at least on the sparc64 >> architecture. >> >> As a first step to a possible solution you can apply the attached >> (provisional) patch, that uses an anonymous, read-only mapping to create >> the required region. >> >> The output of the above program then becomes: >> >> PID START END PRT RES PRES REF SHD FL TP >> PATH >> 1302 0x400000 0x401000 r-x 1 0 1 0 CN vn >> /root/mlockall/mltest >> 1302 0x500000 0x501000 rw- 1 0 1 0 -- df >> 1302 0x800500000 0x80052c000 r-x 44 0 8 4 CN vn >> /libexec/ld-elf.so.1 >> 1302 0x80052c000 0x800534000 rw- 8 0 1 0 -- df >> 1302 0x80062b000 0x800633000 rw- 8 0 1 0 C- vn >> /libexec/ld-elf.so.1 >> 1302 0x800633000 0x80063f000 rw- 12 0 1 0 -- df >> 1302 0x80063f000 0x80072e000 r-x 239 0 124 62 CN vn >> /lib/libc.so.7 >> 1302 0x80072e000 0x80072f000 r-x 1 0 1 0 C- vn >> /lib/libc.so.7 >> 1302 0x80072f000 0x80082f000 r-- 256 0 1 0 -- df >> 1302 0x80082f000 0x80084f000 rw- 32 0 1 0 C- vn >> /lib/libc.so.7 >> 1302 0x80084f000 0x800865000 rw- 22 0 1 0 -- df >> 1302 0x7ffffffe0000 0x800000000000 rwx 32 0 1 0 -- df >> >> i.e. mlockall() does not return an error anymore. >> >> I still have the following questions: >> >> 1. Is worth the trouble to solve the mlockall() problem at all ? Should >> I file a PR ? > Yes. Do as you want, but I see no reason. > > Your analisys looks correct and useful. > >> 2. Can someone confirm that it also occurs on the other 64 bit >> architectures ? >> >> 3. It might be more elegant to use PROT_NONE instead of PROT_READ when >> just staking out the address space. Currently mlockall() returns an >> error when attempting that, so most likely mlockall() would need to be >> changed to ignore regions mapped with PROT_NONE. On the other hand, the >> pthread implementation uses PROT_NONE to create red zones on the stack >> and mlockall() apparently succeeds with threaded applications (using the >> provided patch). Any opinions/ideas/hints ? > I think that it is better to unmap the holes, instead of making some > mapping. > In that way you free up virtual address space and make it available to the next call to mmap() with the first argument set to zero (i.e. where the caller does not care about the exact location), if the requested space fits in the hole you left. In this way unrelated mappings could end up between the regions of you dynamic libraries. I don't think that would be desirable. Using PROT_NONE would prevent such a mix up: the address space is still there, but not accessible. BTW: Note that even in the current implementation there is a hole available between the regions for /libexec/ld-elf.so.1 itself, starting at 0x800534000 in the above examples. > Please, try this patch instead. > I have tried your patch on my amd64 8.0-CURRENT system and it works perfectly with the described test program. I will stress test it later by running a "make buildworld". In can easily be demonstrated however, that allocations using mmap() as described above may end up in "strange" locations. > diff --git a/libexec/rtld-elf/map_object.c b/libexec/rtld-elf/map_object.c > index 2d06074..3266af0 100644 > --- a/libexec/rtld-elf/map_object.c > +++ b/libexec/rtld-elf/map_object.c > @@ -83,6 +83,7 @@ map_object(int fd, const char *path, const struct stat *sb) > Elf_Addr bss_vaddr; > Elf_Addr bss_vlimit; > caddr_t bss_addr; > + size_t hole; > > hdr = get_elf_header(fd, path); > if (hdr == NULL) > @@ -91,8 +92,7 @@ map_object(int fd, const char *path, const struct stat *sb) > /* > * Scan the program header entries, and save key information. > * > - * We rely on there being exactly two load segments, text and data, > - * in that order. > + * We expect that the loadable segments are ordered by load address. > */ > phdr = (Elf_Phdr *) ((char *)hdr + hdr->e_phoff); > phsize = hdr->e_phnum * sizeof (phdr[0]); > @@ -214,6 +214,17 @@ map_object(int fd, const char *path, const struct stat *sb) > return NULL; > } > } > + > + /* Unmap the region between two non-adjusted ELF segments */ > + if (i < nsegs) { > + hole = trunc_page(segs[i + 1]->p_vaddr) - bss_vlimit; > + if (hole > 0 && munmap(mapbase + bss_vlimit, hole) == -1) { > + _rtld_error("%s: munmap hole failed: %s", path, > + strerror(errno)); > + return NULL; > + } > + } > + > if (phdr_vaddr == 0 && data_offset <= hdr->e_phoff && > (data_vlimit - data_vaddr + data_offset) >= > (hdr->e_phoff + hdr->e_phnum * sizeof (Elf_Phdr))) { From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 5 18:40:41 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 486371065675 for ; Sun, 5 Apr 2009 18:40:41 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id EEB548FC15 for ; Sun, 5 Apr 2009 18:40:40 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (pD954FF67.dip.t-dialin.net [217.84.255.103]) by redbull.bpaserver.net (Postfix) with ESMTP id 7C7222E051; Sun, 5 Apr 2009 20:40:35 +0200 (CEST) Received: from unknown (IO.Leidinger.net [192.168.2.103]) by outgoing.leidinger.net (Postfix) with ESMTP id B0F4210C653; Sun, 5 Apr 2009 20:40:30 +0200 (CEST) Date: Sun, 5 Apr 2009 20:40:28 +0200 From: Alexander Leidinger To: Doug Ambrisko Message-ID: <20090405204028.0000654f@unknown> In-Reply-To: <200904031419.n33EJYb8069855@ambrisko.com> References: <20090403084601.108111xg6o3b49ms@webmail.leidinger.net> <200904031419.n33EJYb8069855@ambrisko.com> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.10.13; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 7C7222E051.274A6 X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, ORDB-RBL, SpamAssassin (not cached, score=-14.2, required 6, BAYES_00 -15.00, J_CHICKENPOX_21 0.60, J_CHICKENPOX_22 0.60, RDNS_DYNAMIC 0.10, SMILEY -0.50) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No X-Mailman-Approved-At: Sun, 05 Apr 2009 18:44:14 +0000 Cc: freebsd-hackers@freebsd.org, Andriy Gapon Subject: Re: watchdog: hw+sw? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2009 18:40:42 -0000 On Fri, 3 Apr 2009 07:19:34 -0700 (PDT) Doug Ambrisko wrote: > We start watchdogd manually with our own rc.d script mainly since > I noticed Dell pe2650's do false triggers :-( Also I wanted to check > that our app. is functioning so we'd need to start after that. It > would be good to add flags option to the stock start-up scripts. > Just having watchdogd running without checking on anything real tends > to be useless since it is usually swapped in and can run just fine > without depending on much of the system. In the mean time I noticed that the watchdogd can be started with flags just by adding watchdogd_flags="..." to rc.conf. So I just needed to write a shell script which checks the disks which cause problems sometimes, and add a line to rc.conf and now I'm satisfied (... but this should be documented somewhere more obvious). For your app watching stuff, why not write a shell script which checks for a file in a mfs which the app-start creates (if the file is there and the pid not, the app died), and let the WD run this script. This way you can use the default start script. Bye, Alexander. From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 5 20:23:52 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EA9A106564A; Sun, 5 Apr 2009 20:23:52 +0000 (UTC) (envelope-from so14k@valentine.liquidneon.com) Received: from valentine.liquidneon.com (valentine.liquidneon.com [216.87.78.132]) by mx1.freebsd.org (Postfix) with ESMTP id 231758FC18; Sun, 5 Apr 2009 20:23:51 +0000 (UTC) (envelope-from so14k@valentine.liquidneon.com) Received: by valentine.liquidneon.com (Postfix, from userid 1018) id DDF6A8FE15; Sun, 5 Apr 2009 13:51:09 -0600 (MDT) Date: Sun, 5 Apr 2009 13:51:09 -0600 From: Brad Davis To: freebsd-current@FreeBSD.org, freebsd-hackers@FreeBSD.org Message-ID: <20090405195109.GB25817@valentine.liquidneon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: FreeBSD Status Reports due April 20th, 2009 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2009 20:23:52 -0000 Hi Everyone, We would like to remind everybody who has exciting news to share to write a report about their project. This is a good way to improve exposure of your work, receive feedback and help. We are looking forward to your reports. As always you can either use the template or the CGI generator and mail the output to monthly@ by Wednesday April 20th, 2009. http://www.freebsd.org/news/status/ http://www.freebsd.org/cgi/monthly.cgi http://www.freebsd.org/news/status/report-sample.xml Regards, Brad Davis From owner-freebsd-hackers@FreeBSD.ORG Sun Apr 5 20:39:22 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A87B2106566C for ; Sun, 5 Apr 2009 20:39:22 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 0BF198FC0C for ; Sun, 5 Apr 2009 20:39:21 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: by ewy19 with SMTP id 19so1580849ewy.43 for ; Sun, 05 Apr 2009 13:39:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:organization:to:subject :date:user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=SYIT12sZUpSCyKsp1q0I7Dmr54PkVGVeoJMeO2SHaw4=; b=wNIAZBtuLuGt5pRPCl9UgHJFYGEdeLQopsyxpEVYDpsYbbWdP2c5X1KcMj8HmoLgWR CzLjyFErhzlGCp+APi4OpyFNp1B5A8IIvfijKlyylEoEzCqwetKG4/GTWDfKe6y3VPob SewG73viCbx3y5tZxwzbixVEGwDxNjwS2NuAE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:organization:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; b=KpPaRK3hm5UfwcTQZJLIGMRssmr1xdZOyFsPjpnQylhL5rEHNe2EUSDuClkxgcYHQr F24hDYiXWNeIwNETceaxglm5tpzAwb7jyKj7yP6jBYLRo+pmXYeVvqgMuT5W28h0KYoB xFZPVor3wevps/UDf6UV/f1hQgPxq80qdueBA= Received: by 10.216.20.83 with SMTP id o61mr976968weo.206.1238962413609; Sun, 05 Apr 2009 13:13:33 -0700 (PDT) Received: from ?0.0.0.0? ([196.34.241.123]) by mx.google.com with ESMTPS id 5sm5835772eyh.21.2009.04.05.13.13.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 05 Apr 2009 13:13:32 -0700 (PDT) From: David Naylor Organization: Private To: Travis Daygale Date: Sun, 5 Apr 2009 22:14:03 +0200 User-Agent: KMail/1.9.10 References: <313500.27821.qm@web37106.mail.mud.yahoo.com> In-Reply-To: <313500.27821.qm@web37106.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1333544.9sYBSKDk9c"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200904052214.08866.naylor.b.david@gmail.com> X-Mailman-Approved-At: Sun, 05 Apr 2009 22:25:13 +0000 Cc: freebsd-hackers@freebsd.org Subject: Re: compiling root filesystem into kernel (preferably tmpfs root filesystem) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2009 20:39:22 -0000 --nextPart1333544.9sYBSKDk9c Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 04 April 2009 21:52:14 Travis Daygale wrote: > In both the loader and kernel compiling doc, I see snippets of information > like this: #Make space in the kernel for a root filesystem on a md > device.options MD_ROOT_SIZE=3D10 boot_dfltrootInstructs the kernel to mou= nt > the statically compiled-in root file system. Yes, you can compile a fs image into the kernel. This however will be stat= ic=20 and if you want editing then will need to use unionfs with mdmfs. tmpfs=20 cannot be used for this as it does not yet (to my knowledge) support unionf= s. =20 > My question is, how does one compile a root filesystem into the FreeBSD > kernel? =A0 Personally I wouldn't recommend taking the approach you want to do. There = is=20 simply an easier way. Just load the fs image as a kernel module (sort of).= =20 You get the same effect with more flexibility. (I'll explain below). > When mounted, I want this root filesystem to run entirely in=20 > memory with no other backing store (not even a readonly flash disc nor > other backing media such as DVD/CD).=20 This is do-able. I've created a CD that ejects it self when loaded=20 completely. (I thought it was cool :-)) > The standard FreeBSD DVD install disc=20 > uses just such a root? =A0(Though seems to rely heavily on the rescue > binaries being on a read only filesystem backed by the install DVD?)=20 Can't comment, haven't used the FreeBSD CD/DVD's for years (since 6.0) > I'm=20 > still trying to reverse engineer how that was done, without much luck. Is > there a place/documentation I should be finding? =A0PicoBSD, NanoBSD, NFS > root diskless systems... all tantalizing close, but not the same thing > (read only roots backed by media other than memory). The root filesystem > I'm wanting would presumably be in some conceptual sense similar to > initramfs in Linux land, if that helps explain what I'm trying to achieve= =2E =20 I'll give you a quick tutorial below (if you need further help please let m= e=20 know). > =A0In fact I have a Linux distribution which consists of a single giant > kernel image and when boot, runs entirely in memory, the kernel in fact > can't read filesystems other than tmpfs because no filesystems are compil= ed > in. =A0 I think you are getting some concepts confused here. =20 > It appears all of this won't be possible in FreeBSD (looks like ufs is=20 > required) but it appears I can get close to this. Indeed, I'd love a way > for the root filesystem in FreeBSD to be of type tmpfs, again similar to > what is possible on the Linux side, though I'm much less concerned with t= he > type of filesystem (it just needs to be compiled into the FreeBSD kernel > and needs to be a memory backed filesystem when it mounts, no other backi= ng > store). Thanks in advance! Ok, onto my explanation: my understanding is that you want to have some typ= e=20 of FreeBSD based system that is loaded completely into RAM. Once loaded (a= t=20 boot time) this system should have no reliance on any medium (other than=20 RAM). This system, once loaded, should behave the same as if it were backe= d=20 by a hard drive (except the statefullness after reboots). i.e. the=20 filesystem should be editable. =20 This is of course very possible. =20 STAGE 1: The filesystem In order to have the system in memory one needs a delivery method. As=20 mentioned before this is achieved using a MD device. =20 MD's can have three types of backing, a vnode (aka file, on a CD/DVD or har= d=20 drive), or memory (purely in memory, AFAIK no swapping out) and swap (same = as=20 memory except my get swapped out). Ignoring the subtle difference between= =20 memory and swap, swap is better. Technically the forth is preload but this= =20 is the same as memory but done by the loader. See md(4) for further detail= s. =20 Now, MD just imitates a hard drive, one still needs the data to put there. = =20 Any filesystem will suite this purpose. My preference is UFS but ISO9660=20 works just as easily (other options are not so easy but still do-able). =20 Now, to create the filesystem, just install your system into a folder. e.g. # su - # mkdir /tmp/world # cd src; make world kernel distribution DESTDIR=3D/tmp/world # cp /path/to/packages /tmp/world/tmp # chroot /tmp/world sh -c 'cd /tmp ; pkg_add *' # rm -rf /tmp/world/tmp/* # cat > /tmp/world/etc/fstab < _EOF proc /proc procfs rw 0 0 tmpfs /tmp tmpfs rw 0 0 _EOF * Now, edit /tmp/world as you require to make it work as you want (the easi= est=20 way is to create a Flash stick [as per my script], edit the system live and= =20 then copy all changes across). * STAGE 2: The filesystem image *** For UFS *** # makefs /tmp/world.ufs /tmp/world # MDDEV=3D$(mdconfig -a -t vnode /tmp/world.ufs) # tunefs -L ROOTFS /dev/$MDDEV # mdconfig -d -u $MDDEV *** For CD9660 *** # mkisofs -quiet -sysid=20 =46REEBSD -rock -untranslated-filenames -max-iso9660-filenames -iso-level=20 4 -volid DragonBSD -o $WORKDIR/DragonBSD.iso -volid=20 DragonBSD -o /tmp/world.iso /tmp/world Now, since these images are often much larger then required I prefer to=20 compress them. This allows more programs to be added to the image and it=20 takes up less memory during runtime (not to mention faster load times). =20 [I assume UFS option, do the appropriate for CD9660 option] # mkuzip -s 8192 -o /tmp/world.uzip /tmp/world.ufs STAGE 3: Loading the filesystem image Now you have an image that can be loaded on boot, to do so add the followin= g=20 to loader.conf # cd /path/to/boot/system/image # cat >> boot/loader.conf < _EOF rootfs_load=3D"YES" rootfs_type=3D"mfs_root" rootfs_name=3D"/boot/world.uzip" _EOF # cp /tmp/world.uzip boot/ Now, to inform the system that you want it to boot off the memory system # cat >> boot/loader.conf < _EOF vfs.root.mountfrom=3D"ufs:/dev/ufs/ROOTFS" _EOF STAGE 4: Making the Live System editable Now, to make the whole system editable (everything) is quite the challenge = and=20 requires a change in the way the previous stages are done. The concept is= =20 simple though. First: Because the filesystem was compressed (using mkuzip), it cannot be written = to. =20 If the system were not compressed and extra space was allocated to the UFS= =20 image then it can be editable. Even the extra size at load time can be=20 compensated for (since loader supports compressed modules [both gzip and=20 bzip2] however you will be running the full image uncompressed in memory. = It=20 is faster but much more expensive. Just to give you an idea, I have gotten= a=20 700MB system to boot and run off a mini CD (210MB) and a system with 512MB = of=20 RAM, using the compressed approach with everything editable :-). =20 To do this approach requires some changes to stage 2. Basically, after=20 completing the approach for UFS image do the following # EXTRA_SIZE=3D32 # SIZE=3D$(($(du -m /tmp/world.ufs) + EXTRA_SIZE)) # dd if=3D/dev/zero of=3D/tmp/world.ufs count=3D$SIZE bs=3D1m # NB, use ze= ro to allow=20 for compression # MDDEV=3D$(mdconfig -a -t vnode /tmp/world.ufs) # newfs -L ROOTFS -o space /dev/$MDDEV # mkdir /tmp/btstrp # mount /dev/$MDDEV /tmp/btstrp # (cd /tmp/world; tar -cf - .) | (cd /tmp/btstrp; tar -xf -) # umount /tmp/btstrp # mdconfig -d -u $MDDEV Next, DO NOT compress the image with mkuzip, instead do: # gzip -9 /tmp/world.ufs This requires either geom_uzip loaded or compiled into the kernel. and, instead of the first part of stage 3 do # cd /path/to/boot/system/image # cat >> boot/loader.conf < _EOF rootfs_load=3D"YES" rootfs_type=3D"mfs_root" rootfs_name=3D"/boot/world.ufs" _EOF # cp /tmp/world.ufs.gz boot/ NOTE: this approach cannot be done using cd9660. The second approach, the one I prefer requires a double boot image (one ins= ide=20 the other), where the one acts as a boot strap, mdconfig and mount's the=20 embedded second image, creates a editable fs using mdmfs and unionfs it ove= r=20 the second image. =20 This is done through using # cat >> boot/loader.conf < _EOF init_script=3D"/chroot.sh" init_chroot=3D"/base" where /chroot.sh basically does: mount -o ro /dev/$(mdconfig -a -t vnode -o readonly -f /world.uzip).uzip /b= ase mdmfs -s 32m md /tmp mount -t unionfs -o noatime -o copymode=3Dtransparent /tmp/base It would be very nice to add unionfs support to tmpfs but not yet :-(. The= =20 second approach I have not described fully, it is quite a bit more involved= =20 than the first but has great benefits, memory wise. If you want more detai= ls=20 about this approach please let me know. =20 I've created a set of scripts that are designed to create LiveCD/DVD/Flash = of=20 =46reeBSD. There are three cd9660 images that it produces: 1) CD backed live system (using compressed ufs image) 2) Memory backed live system (using compressed ufs image) 3) CD backed live system (no compression). And one Flash memory based image: 1) Flash based memory (using compressed ufs image and perpetual state overl= ay)=20 [similar to option 1 above except the changes are permanent). =20 If you would like access to these scripts please let me know and I will gla= dly=20 forward them to you. Also if you have any questions or want further=20 clarification please ask. =20 Regards, David Disclaimer: The commands may be incorrect but the procedure has been tried = and=20 tested. =20 --nextPart1333544.9sYBSKDk9c Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEABECAAYFAknZERAACgkQUaaFgP9pFrLsjgCfd0nMbBs0SL1F9re/ygjZnggM TWQAn2ZyOWhyz0SsyRoOTlG/oeYzFrNS =if6I -----END PGP SIGNATURE----- --nextPart1333544.9sYBSKDk9c-- From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 6 11:25:04 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A930910659EC for ; Mon, 6 Apr 2009 11:25:04 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id F0E968FC2B for ; Mon, 6 Apr 2009 11:24:39 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id C62841D171; Mon, 6 Apr 2009 13:24:38 +0200 (CEST) Date: Mon, 6 Apr 2009 13:24:38 +0200 From: Ed Schouten To: freebsd-hackers@FreeBSD.org Message-ID: <20090406112438.GA13393@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QFliEIXSSz7hGqqc" Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Subject: Decreasiong default dcons poll hz X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 11:25:45 -0000 --QFliEIXSSz7hGqqc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, I was just discussing with rwatson on IRC that the default polling frequency used by dcons may be a little too high. It's currently set to 100 Hz. I guess it should probably use 25 Hz at most. My question is if anyone using dcons could try decreasing kern.dcons.poll_hz to 25 and let me know whether that's still usable. Thanks! --=20 Ed Schouten WWW: http://80386.nl/ --QFliEIXSSz7hGqqc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAknZ5nYACgkQ52SDGA2eCwWZcwCfajUvNy4BV/E+LFTpp0OQUfVM RRQAn0He+D+JtADvz0akuz5XGERS6cdq =G4vJ -----END PGP SIGNATURE----- --QFliEIXSSz7hGqqc-- From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 6 13:18:56 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80A991065678; Mon, 6 Apr 2009 13:18:56 +0000 (UTC) (envelope-from gabriele.modena@gmail.com) Received: from mail-bw0-f164.google.com (mail-bw0-f164.google.com [209.85.218.164]) by mx1.freebsd.org (Postfix) with ESMTP id A9D0E8FC1C; Mon, 6 Apr 2009 13:18:55 +0000 (UTC) (envelope-from gabriele.modena@gmail.com) Received: by bwz8 with SMTP id 8so1827631bwz.43 for ; Mon, 06 Apr 2009 06:18:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ynNrQH584n70yTRpk2SxyvlooZFPjH65Wn4iElRxn68=; b=PkPGv6hgeCM3iA369yTSNNR0vK/QCP4YSAF134/dBIqKbaB48Vq9zxgaZXpxVsJCs+ O2QbFPvd3puunroaAWN/Xb2FkQLCwK0qcMawNba7xB9N6iiq9i3GSw/2M0uwkGB9QL2x qkc/awqdmfAwjTPzH3QmB9l4Az28rqCZYxzns= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tfxmaflI0VtgLhTnFhp6pfunrd0A4r4ojJq8SgrsQ2ip2zuCQT/1i422FfN0G2Q0W9 gn2jKj6FthXW4q4wxYmeBF6PNl3TjuQr7Qg+Zg4YZFKSpoORGRXERnthz4iRiPpPzLkj vp9Y8Xmc8o9KlSLjPTLo7RFkwd1VDm+IEs92g= MIME-Version: 1.0 Received: by 10.204.113.198 with SMTP id b6mr1642135bkq.108.1239023934587; Mon, 06 Apr 2009 06:18:54 -0700 (PDT) In-Reply-To: References: <1fe1d5d60903210422g70efef15hdd685695cdf8df3c@mail.gmail.com> <1fe1d5d60904020904ya6dcb00h54a54d6a00e2bd0@mail.gmail.com> Date: Mon, 6 Apr 2009 15:18:54 +0200 Message-ID: <1fe1d5d60904060618j1f68b45fl7810169d66890fd6@mail.gmail.com> From: Gabriele Modena To: Robert Watson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: GSoC: Semantic File System X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 13:18:56 -0000 On Thu, Apr 2, 2009 at 7:26 PM, Robert Watson wrote: >> In this moment I am considering also an userspace approach similar to >> Spotlight/Beagles, but I don't know how I could propose this as a FreeBSD >> GSoC project. > > I think that would make a fine GSoC proposal. Keep in mind that one of the > premises of Spotlight is the fsevents kernel feature, and fseventsd, which > allow Spotlight to subscribe to changes in trees and kick off reindexing as > required. Porting the fsevents API to FreeBSD is fairly straight forward, > with one exception: HFS+ offers a much more reliable notion of vnode->path > mapping, but it would be interesting to see how well our current vnode->path > mapping mechanisms would suffice in practice (since a lot of the edge cases > that don't work well with our mapping system are exactly that -- edge > cases). This is in case of using UFS/FFS as the base fs or is a more general VFS issue? And what about ZFS? Since apple has not (partially) started to support it, IMHO it may be an interesting fs to investigate. > Between kernel and userspace parts there's quite a bit to do, but one > possibility would be to borrow parts from Mac OS X/etc that we need. For > example, do a literal port of the fsevents mechanism from XNU, provide our > own implementation that provides a similar API, or provide a new mechanism > that meets fseventd's semantic requirements for monitoring. This would definitely be an interesting approach. One of my original ideas was to have a look at how inotify has been implemented in linux, but probably fsevents would be a better choice (also license wise). > I'm probably blending reality with imagination here, but my vague > recollection is that the model was a slightly different blend of user vs. > application involvement in indexing. For how I see it now the steps for my work could be: 1) port/implement an event notification feature; 2) build a userspace indexer; 3) write a gui/search tool on top of it. > In the BeOS model, or my reinterpretation based on something I read a long > time ago and then presumably had dreams about, the split is a bit different: > the file system maintains indexes of extended attributes, which are written > by applications in order to expose searchable material. This sounds to me like adding another layer/proxy between the applications and the actual data. I found some material about node watch and extended attributes that I'm going to study in these days. > It's also worth observing that one of the authors of BFS was Dominic > Giampaolo, who now works on Apple's HFS+, and implemented fsevents there as > part of their Spotlight project. Thanks a lot for you feedback, you provided me a with lot of very interesting material to look up! Cheers. From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 6 13:22:21 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6282F1065688 for ; Mon, 6 Apr 2009 13:22:21 +0000 (UTC) (envelope-from decado@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.185]) by mx1.freebsd.org (Postfix) with ESMTP id EF5B78FC14 for ; Mon, 6 Apr 2009 13:22:20 +0000 (UTC) (envelope-from decado@gmail.com) Received: by ti-out-0910.google.com with SMTP id u5so2372722tia.3 for ; Mon, 06 Apr 2009 06:22:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=vGz9I7ri5AjgfTbw67lI97Bc4y4YsfYTBvrPpBSinL4=; b=GTZNBRHJ1rbjR5ewcyxUvmhxZKTzrqSJNbX9k045oPZ7a8CcSyIYBK4Q2gM4Th/NY/ aV3DApYsxpR3Cbg89ixGlU2CNALcDUFuKF6TbNnkOAvesew7WJgXzcCqOrAKh1l5jacu yPWx0MPZS+Nw3UQ+wTarR+OGsCG9oSnB6IA5A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=R3KkuznI4k7roohJKYWy+i5AT2j0pAe3ejHWd21c8UWGIxdGJ74svk/e568kZjTQRq qOolwEPB0gitwUdPZL817dZD4Fr6CeGqbq4IfzqglZNCaCHL0ymFeisXeh9TUlJQ3G/5 fztuS9pbjC2tmdOZVQSYUOhts4PtgzcHoZ2II= Received: by 10.110.84.3 with SMTP id h3mr6430011tib.22.1239022309154; Mon, 06 Apr 2009 05:51:49 -0700 (PDT) Received: from ?192.168.1.200? (ppp118-208-145-104.lns10.mel4.internode.on.net [118.208.145.104]) by mx.google.com with ESMTPS id b7sm304013tic.35.2009.04.06.05.51.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 06 Apr 2009 05:51:48 -0700 (PDT) Message-ID: <49DB4C20.5010107@gmail.com> Date: Tue, 07 Apr 2009 22:50:40 +1000 From: k User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ed Schouten References: <200902251724.40212.fbsd.hackers@rachie.is-a-geek.net> <20090311130557.GJ31961@hoeg.nl> In-Reply-To: <20090311130557.GJ31961@hoeg.nl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Mel , FreeBSD Hackers Subject: Re: [PATCH] Support for thresholds in du(1) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 13:22:21 -0000 Ed Schouten wrote: > * Mel wrote: >> Example usage: >> # du -xht 20m . >> 29M ./contrib/binutils >> 52M ./contrib/gcc >> 237M ./contrib >> 35M ./crypto >> 28M ./lib >> 20M ./share >> 55M ./sys/dev >> 139M ./sys >> 545M . > > Ooh! That looks awesome! > Would this option benefit from perhaps swinging both ways? As in: du -t +20m (show >20mb) du -t -20m (show <20mb) Or something along those lines From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 6 15:35:41 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B49A1065675; Mon, 6 Apr 2009 15:35:41 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) by mx1.freebsd.org (Postfix) with ESMTP id 766138FC13; Mon, 6 Apr 2009 15:35:41 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms068.mailsrvcs.net ([172.18.12.132]) by vms173003.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KHO009G2RASWWVN@vms173003.mailsrvcs.net>; Mon, 06 Apr 2009 10:35:17 -0500 (CDT) Received: from 65.242.108.162 ([65.242.108.162]) by vms068.mailsrvcs.net (Verizon Webmail) with HTTP; Mon, 06 Apr 2009 10:35:16 -0500 (CDT) Date: Mon, 06 Apr 2009 10:35:16 -0500 (CDT) From: Sergey Babkin To: julian@elischer.org Message-id: <13591482.311321.1239032116786.JavaMail.root@vms068.mailsrvcs.net> Content-transfer-encoding: 7bit X-Originating-IP: [65.242.108.162] X-Mailman-Approved-At: Mon, 06 Apr 2009 15:51:04 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: sobomax@FreeBSD.org, babkin@verizon.net, freebsd-hackers@FreeBSD.org, freebsd-current@FreeBSD.org, prashant.vaibhav@gmail.com, davidxu@FreeBSD.org Subject: Re: Re: Improving the kernel/i386 timecounter performance (GSoC proposal) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 15:35:42 -0000 Apr 4, 2009 02:02:07 PM, julian@elischer.org wrote: >Hey Sergey, whatever you are using for a mail client SUCKS >real bad at the moment.. > > it's really messing up your outgoing mails.. > >note the mail below.... Looks like using the text mode didn't help :-( Oh, well, I guess I should not write replies from the web interface. -SB From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 6 16:10:19 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4CD010657CE; Mon, 6 Apr 2009 16:10:19 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4C7518FC1D; Mon, 6 Apr 2009 16:10:10 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id F3F5546B03; Mon, 6 Apr 2009 12:10:09 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 74CD98A04B; Mon, 6 Apr 2009 12:10:08 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Mon, 6 Apr 2009 11:54:19 -0400 User-Agent: KMail/1.9.7 References: <1366225354.253456.1238948619308.JavaMail.root@vms124.mailsrvcs.net> In-Reply-To: <1366225354.253456.1238948619308.JavaMail.root@vms124.mailsrvcs.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904061154.19601.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 06 Apr 2009 12:10:08 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.1 required=4.2 tests=RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Sergey Babkin , ivoras@freebsd.org Subject: Re: Patch for MS Hyper V (virtualization) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 16:10:27 -0000 On Sunday 05 April 2009 12:23:39 pm Sergey Babkin wrote: > > Apr 4, 2009 02:10:23 PM, ivoras@freebsd.org wrote: > >Can someo=ne please review and commit (if appropriate) the tweak for > >Hyper-V shu=tdown issue at > http://shell.peach.ne.jp/aoyama/archives/40 > >? > > > =>>The problem is: the VM appears to hang on shutdown without it > (hanging > >the Hyper-V VM with it so the host also can't shutdown or reboot > >re=liably - someone at MS skipped the part where an error in the VM > >isn't=supposed to bring the host down with it) > I don't have the commit =permission any more but I can review :-) > Yes, Hyper-V does not like th=e writes into the PCI config space. > Very specifically, > writing the base=register window address of the simulated 21140 > screws up something > tha=t prevents the VM from shutting down. Interestingly, even reading > and writi=ng > back the same value has this effect. So the patch is valid. > =>I don't particularly like the hackish checking for the 21140 chip, > and I'=m not sure > if if would break some real 21140 chip out there. If the dri=ver does > the same as another > one I've seen, the driver tries to align t=he register window to > 0x80, and in the > simulated 21140 it's already ali=gned. I've had a quick look but > couldn't say it > for sure. I'd do it dif=ferently: check if the value being written is > the same that was read, > =and skip the write in this case. > Let me see, maybe I'll make a dif=ferent patch. Hmm, the problem is we need to be able to write to BARs to size them. Any OS needs to be able to do this to know what address space regions are being decoded by devices. We can't avoid writing to BARs. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 6 17:07:54 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E053410656E9 for ; Mon, 6 Apr 2009 17:07:54 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 548AB8FC13 for ; Mon, 6 Apr 2009 17:07:53 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by ewy19 with SMTP id 19so1910685ewy.43 for ; Mon, 06 Apr 2009 10:07:53 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <200904061154.19601.jhb@freebsd.org> References: <1366225354.253456.1238948619308.JavaMail.root@vms124.mailsrvcs.net> <200904061154.19601.jhb@freebsd.org> Date: Mon, 6 Apr 2009 19:07:38 +0200 Received: by 10.210.34.5 with SMTP id h5mr3143952ebh.38.1239037673256; Mon, 06 Apr 2009 10:07:53 -0700 (PDT) Message-ID: <9bbcef730904061007y66a8440al3c43a6a6b6cd6ed6@mail.gmail.com> From: Ivan Voras To: John Baldwin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Sergey Babkin Subject: Re: Patch for MS Hyper V (virtualization) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 17:07:55 -0000 2009/4/6 John Baldwin : > On Sunday 05 April 2009 12:23:39 pm Sergey Babkin wrote: > Hmm, the problem is we need to be able to write to BARs to size them. =C2= =A0Any OS > needs to be able to do this to know what address space regions are being > decoded by devices. =C2=A0We can't avoid writing to BARs. I have only vague idea what BARs are and if it's the correct diagnosis in this case, but the fact is that other operating systems (Windows, Linux tested) work, so either there is a way around it or the original premise is wrong-ish. From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 6 17:23:13 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 258811065707; Mon, 6 Apr 2009 17:23:13 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id BAFE48FC1D; Mon, 6 Apr 2009 17:23:12 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n36HH9V3010695; Mon, 6 Apr 2009 11:17:09 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 06 Apr 2009 11:17:55 -0600 (MDT) Message-Id: <20090406.111755.1973602189.imp@bsdimp.com> To: jhb@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <200904061154.19601.jhb@freebsd.org> References: <1366225354.253456.1238948619308.JavaMail.root@vms124.mailsrvcs.net> <200904061154.19601.jhb@freebsd.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, babkin@verizon.net, ivoras@FreeBSD.org Subject: Re: Patch for MS Hyper V (virtualization) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 17:23:13 -0000 In message: <200904061154.19601.jhb@freebsd.org> John Baldwin writes: : On Sunday 05 April 2009 12:23:39 pm Sergey Babkin wrote: : > : > Apr 4, 2009 02:10:23 PM, ivoras@freebsd.org wrote: : > >Can someo=ne please review and commit (if appropriate) the tweak for : > >Hyper-V shu=tdown issue at : > http://shell.peach.ne.jp/aoyama/archives/40 : > >? : > > : > =>>The problem is: the VM appears to hang on shutdown without it : > (hanging : > >the Hyper-V VM with it so the host also can't shutdown or reboot : > >re=liably - someone at MS skipped the part where an error in the VM : > >isn't=supposed to bring the host down with it) : > I don't have the commit =permission any more but I can review :-) : > Yes, Hyper-V does not like th=e writes into the PCI config space. Why not? We need to understand exactly what it doesn't like because this is non-standard compliant behavior. : > Very specifically, : > writing the base=register window address of the simulated 21140 : > screws up something : > tha=t prevents the VM from shutting down. Interestingly, even reading : > and writi=ng : > back the same value has this effect. So the patch is valid. Then the Hyper-V is broken. This is bog-standard PCI behavior. The OS must be able to write to the BARs to size the resource being decoded. In addition, the OS is allowed to move the location of an allocation for a BAR, so avoiding writes to it is bad. Finally, some BIOSes don't allocate resources for a card, and this would totally prevent 21140's from being usable on those machines. : > =>I don't particularly like the hackish checking for the 21140 chip, : > and I'=m not sure : > if if would break some real 21140 chip out there. If the dri=ver does : > the same as another : > one I've seen, the driver tries to align t=he register window to : > 0x80, and in the : > simulated 21140 it's already ali=gned. I've had a quick look but : > couldn't say it : > for sure. I'd do it dif=ferently: check if the value being written is : > the same that was read, : > =and skip the write in this case. : > Let me see, maybe I'll make a dif=ferent patch. : : Hmm, the problem is we need to be able to write to BARs to size them. Any OS : needs to be able to do this to know what address space regions are being : decoded by devices. We can't avoid writing to BARs. Exactly. Not only do we have to read/write them to size the BAR resource, but as I indicated above, one must write to them when the BIOS doesn't assign resources to the BAR and the driver requests that resource. Warner From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 6 17:44:22 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8D0D1065717; Mon, 6 Apr 2009 17:44:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 800DD8FC24; Mon, 6 Apr 2009 17:44:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 30A4146BC6; Mon, 6 Apr 2009 13:44:22 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 01AAE8A04D; Mon, 6 Apr 2009 13:44:21 -0400 (EDT) From: John Baldwin To: Ivan Voras Date: Mon, 6 Apr 2009 13:42:21 -0400 User-Agent: KMail/1.9.7 References: <1366225354.253456.1238948619308.JavaMail.root@vms124.mailsrvcs.net> <200904061154.19601.jhb@freebsd.org> <9bbcef730904061007y66a8440al3c43a6a6b6cd6ed6@mail.gmail.com> In-Reply-To: <9bbcef730904061007y66a8440al3c43a6a6b6cd6ed6@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200904061342.22000.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 06 Apr 2009 13:44:21 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.1 required=4.2 tests=RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-hackers@freebsd.org, Sergey Babkin Subject: Re: Patch for MS Hyper V (virtualization) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 17:44:23 -0000 On Monday 06 April 2009 1:07:38 pm Ivan Voras wrote: > 2009/4/6 John Baldwin : > > On Sunday 05 April 2009 12:23:39 pm Sergey Babkin wrote: >=20 > > Hmm, the problem is we need to be able to write to BARs to size them. = =C2=A0Any=20 OS > > needs to be able to do this to know what address space regions are being > > decoded by devices. =C2=A0We can't avoid writing to BARs. >=20 > I have only vague idea what BARs are and if it's the correct diagnosis > in this case, but the fact is that other operating systems (Windows, > Linux tested) work, so either there is a way around it or the original > premise is wrong-ish. Every OS writes to BARs to size them during boot. It's the defined procedu= re=20 for sizing them. A BAR is a base address register, and it is how a PCI=20 device gets memory and I/O port resources. OS (or BIOS) writes a starting= =20 address into the register to tell the PCI device where a given=20 resource "starts". =2D-=20 John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Mon Apr 6 23:29:57 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 656C910657CA for ; Mon, 6 Apr 2009 23:29:57 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell.rawbw.com (shell.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 38F0B8FC1B for ; Mon, 6 Apr 2009 23:29:57 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from eagle.syrec.org (ppp-71-139-21-14.dsl.snfc21.pacbell.net [71.139.21.14]) (authenticated bits=0) by shell.rawbw.com (8.13.6/8.13.6) with ESMTP id n36NTumu081074 for ; Mon, 6 Apr 2009 16:29:56 -0700 (PDT) Message-ID: <49DA9073.9030401@rawbw.com> Date: Mon, 06 Apr 2009 16:29:55 -0700 From: Yuri User-Agent: Thunderbird 2.0.0.21 (X11/20090322) MIME-Version: 1.0 CC: freebsd-hackers@freebsd.org References: <49D6807D.1040902@rawbw.com> In-Reply-To: <49D6807D.1040902@rawbw.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Is international support broken is msdosfs file system driver? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: yuri@rawbw.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 23:29:57 -0000 Nobody replied and I still have the problem. I extracted the area of the disk where long file names are stored. And can see that all characters are in UTF-8. So how to correctly read UTF-8 encoded VFAT? Yuri From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 7 01:42:21 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F099910656CC for ; Tue, 7 Apr 2009 01:42:21 +0000 (UTC) (envelope-from kitchetech@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by mx1.freebsd.org (Postfix) with ESMTP id A79AE8FC1C for ; Tue, 7 Apr 2009 01:42:21 +0000 (UTC) (envelope-from kitchetech@gmail.com) Received: by an-out-0708.google.com with SMTP id d11so1482236and.13 for ; Mon, 06 Apr 2009 18:42:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=dnlQaJEvY8E3Gjs3gSSo0Nf0FCtomaODWKpo3s/w3ps=; b=Cyrgadaf4EPL0I4ZhE3XUrHwBwRYN3bI8/eiIStJUBKMufQ/PAe0ThZpAjTr/ShSJ2 8ewNtWd41HaqAr9q0SjwaqKAxbZcKnV1g5+HnrFX1N1HvlgnvqpOE6G04r2hU7NjWdjg cZN3JLydRDINmyPS5+QkuzxHomu4gywOhD7KA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=G869jDqf+ead2PP1F4X1IC9Z9YaGoRLAIdVkJUU2F5HBgMKg02jSrA4OVV9g+F1i5h dQHOIWveFlikH3tHD2MoeMqguYV5WAg1fPL4TW7vtOtFj/bZ/AYTaHxfKHEY0JTRQ0ex s5LbUm6hyYIl3Vm8mfRUakb5ySS+H7cY0ZU8Y= MIME-Version: 1.0 Received: by 10.100.144.11 with SMTP id r11mr9678745and.45.1239067189469; Mon, 06 Apr 2009 18:19:49 -0700 (PDT) In-Reply-To: <49DA9073.9030401@rawbw.com> References: <49D6807D.1040902@rawbw.com> <49DA9073.9030401@rawbw.com> From: matt donovan Date: Mon, 6 Apr 2009 21:19:32 -0400 Message-ID: <28283d910904061819v13653du8734215a16029eee@mail.gmail.com> To: yuri@rawbw.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: Is international support broken is msdosfs file system driver? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 01:42:23 -0000 On Mon, Apr 6, 2009 at 7:29 PM, Yuri wrote: > Nobody replied and I still have the problem. > > I extracted the area of the disk where long file names are stored. And can > see that all characters are in UTF-8. > > So how to correctly read UTF-8 encoded VFAT? > > > Yuri > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > >From what I can see FreeBSD can not read UTf-8 on the console but can in X From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 7 03:50:07 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FF851065828 for ; Tue, 7 Apr 2009 03:50:07 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from poseidon.ceid.upatras.gr (poseidon.ceid.upatras.gr [150.140.141.169]) by mx1.freebsd.org (Postfix) with ESMTP id 4C4B98FC0C for ; Tue, 7 Apr 2009 03:50:07 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from mail.ceid.upatras.gr (unknown [10.1.0.143]) by poseidon.ceid.upatras.gr (Postfix) with ESMTP id C3B01EB54DC; Tue, 7 Apr 2009 06:29:02 +0300 (EEST) Received: from localhost (europa.ceid.upatras.gr [127.0.0.1]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 888E4450C6; Tue, 7 Apr 2009 06:29:02 +0300 (EEST) X-Virus-Scanned: amavisd-new at ceid.upatras.gr Received: from mail.ceid.upatras.gr ([127.0.0.1]) by localhost (europa.ceid.upatras.gr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLrSCtcxnhSA; Tue, 7 Apr 2009 06:29:02 +0300 (EEST) Received: from kobe.laptop (adsl16-193.kln.forthnet.gr [77.49.143.193]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 4B5EE4503F; Tue, 7 Apr 2009 06:29:02 +0300 (EEST) Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id n373T1Rn035447; Tue, 7 Apr 2009 06:29:01 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id n373T0el035446; Tue, 7 Apr 2009 06:29:00 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) From: Giorgos Keramidas To: yuri@rawbw.com References: <49D6807D.1040902@rawbw.com> <49DA9073.9030401@rawbw.com> Date: Tue, 07 Apr 2009 06:28:59 +0300 In-Reply-To: <49DA9073.9030401@rawbw.com> (yuri@rawbw.com's message of "Mon, 06 Apr 2009 16:29:55 -0700") Message-ID: <87skkl16ro.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-hackers@freebsd.org Subject: Re: Is international support broken is msdosfs file system driver? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 03:50:07 -0000 On Mon, 06 Apr 2009 16:29:55 -0700, Yuri wrote: > Nobody replied and I still have the problem. > > I extracted the area of the disk where long file names are stored. And > can see that all characters are in UTF-8. > > So how to correctly read UTF-8 encoded VFAT? Remap the locale to something you *can* read? I regularly use mount options like -L el_GR.ISO8859-7 to browse FAT filesystems frm non-UTF8 sessions. Can you try mounting with something like this? # mount -o -L=el_GR.ISO8859-7 /dev/msdosfs/FOO /mnt BTW, this should probably be in -questions not -hackers. From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 7 04:29:44 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DFDB106578C for ; Tue, 7 Apr 2009 04:29:44 +0000 (UTC) (envelope-from wsw1wsw2@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by mx1.freebsd.org (Postfix) with ESMTP id D39AA8FC1A for ; Tue, 7 Apr 2009 04:29:43 +0000 (UTC) (envelope-from wsw1wsw2@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so2303628wfg.7 for ; Mon, 06 Apr 2009 21:29:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:cc:content-type; bh=Vi1AGjq5RUUJgC/S5Jqbp06I11bue8CLbBpyJM+OhM4=; b=h0vZiyb0rvEBJCx1Jspj4XvoXJrs4VM5JRc5h5LE+W2W0r/ScTnDs+0+nXlUH1fSSi qqmtmzqxG9CU5s5Bc3k/0tQlKpNHT5YK+jPuu2f0eeN302lQMfm7vCxouTZDmqJ33+NS PhgkTbwpdpTdVFTr1i/fTy7K/jy8g57zFMyPc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; b=gw+hT1Y2GzoDDamPscKePykiop14m5GsBsuJKxAGosQZ/YqVT23CiRWDV76S0XBznf ZZlL3WNBfXsPYV1jD25blPq0xv0FNkwhYECp+/dBwIV9unnhUdJrgiVm+n6RsWUUws5W B7+tYov2yvLEf8Awmd/DXroH8uU/Ah9HMhPm8= MIME-Version: 1.0 Received: by 10.143.166.10 with SMTP id t10mr1491875wfo.210.1239078582523; Mon, 06 Apr 2009 21:29:42 -0700 (PDT) In-Reply-To: <2e566b9e0904062128id1c3312r9389c77b2a039c6a@mail.gmail.com> References: <49D6807D.1040902@rawbw.com> <2e566b9e0904062128id1c3312r9389c77b2a039c6a@mail.gmail.com> Date: Tue, 7 Apr 2009 12:29:42 +0800 Message-ID: <2e566b9e0904062129k6e028f94w952dbaf40673dfca@mail.gmail.com> From: "Shaowei Wang (wsw)" Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Fwd: Is international support broken is msdosfs file system driver? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 04:29:44 -0000 ---------- Forwarded message ---------- From: Shaowei Wang (wsw) Date: Tue, Apr 7, 2009 at 12:28 PM Subject: Re: Is international support broken is msdosfs file system driver? To: yuri@rawbw.com On Sat, Apr 4, 2009 at 5:32 AM, Yuri wrote: > I have a FAT disk written in Windows that has Chinese characters in file > names. > > When I mount this disk without any special options I see question marks in > place of Chinese characters. > When I mount with options -D=CP950,-L=zh_TW.Big5 there are still some > question marks and garbage characters. > When I mount with options -D=CP936,-L=zh_CN.GBK there are also some > question marks and garbage characters in place of Chinese. > > I read the contents with 'ls' command from x-terminal in kde4. Normally > Chinese characters are shown ok this way. > > My question is how to read proper file names from FAT disk in FreeBSD? try -L zh_CN.euc . FreeBSD-current don't have UTF-8 support for FAT filesystem. > > Also the concept of even having the options like -D=CP950,-L=zh_TW.Big5 > seems questionable. > What if there are files with names in many encodings are on the same FS? > Which options should be used? > Shouldn't msdosfs driver just show international characters without any > special options like ufs driver normally does? Windows file system use a different way to encode i18n chars, like code page. There is a hacked version of msdosfs which can support UTF-8 locale. http://groups.google.com/group/btload/web/msdosfs.tar.bz2 and for using: mount_msdosfs -L zh_CN.UTF-8 /dev/ad?s? /path/to/mount I've tried it and it's work. > > Yuri > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 7 04:30:06 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BF55106566C for ; Tue, 7 Apr 2009 04:30:06 +0000 (UTC) (envelope-from wsw1wsw2@gmail.com) Received: from wf-out-1112.google.com (wf-out-1112.google.com [209.85.200.177]) by mx1.freebsd.org (Postfix) with ESMTP id 143768FC1F for ; Tue, 7 Apr 2009 04:30:05 +0000 (UTC) (envelope-from wsw1wsw2@gmail.com) Received: by wf-out-1112.google.com with SMTP id 19so86918wfi.33 for ; Mon, 06 Apr 2009 21:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:received:message-id:subject :from:to:content-type:content-transfer-encoding; bh=qTOUVK9e1J5gkJU2RvbcBuLfFf/y0P5Guhf/1GePWSI=; b=vK4T143re2y2TPnU8sdxzT+n9oGd/vjImhOkzflzjesBsX4QFyBbSKa6MZQDBZPRLT rtkRKH9PYtWJUuhdq6GBERR0mG0wR9kFN2T8QhaRiQv3GmY1RkZS6DI5SnLo5vJc4pGl qPzTnNrUVv9GWjJrf4MbWzC6bV6wrVDtQ4alw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=FLKgiRfDjqBdwZ6gr36yJ6BbSJS2e9N15tyfcAxjU0Je05aiioPMXLQD+d8nvFYOid rL9xsbxes0v+9f15VAQpEsmjmzOI6e3zK2L4MVKhStRFfPQ8ItUEbZ2ut2Qjn9qA9iLH lK0hzc4xH60/X3G1xQxeYqCqZILi70Zg5vJ/w= MIME-Version: 1.0 Date: Tue, 7 Apr 2009 12:30:05 +0800 Received: by 10.142.68.5 with SMTP id q5mr1498609wfa.12.1239078605619; Mon, 06 Apr 2009 21:30:05 -0700 (PDT) Message-ID: <2e566b9e0904062130i5f470dd6r@mail.gmail.com> From: "Shaowei Wang (wsw)" To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Shaowei Wang (wsw) has invited you to open a Google mail account X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 04:30:06 -0000 I've been using Gmail and thought you might like to try it out. Here's an invitation to create an account. ----------------------------------------------------------------------- Shaowei Wang (wsw) has invited you to open a free Gmail account. To accept this invitation and register for your account, visit http://mail.google.com/mail/a-4edf8f191f-12b39a4ad0-ce26dbdf4e Once you create your account, Shaowei Wang (wsw) will be notified with your new email address so you can stay in touch with Gmail! If you haven't already heard about Gmail, it's a new search-based webmail service that offers: - Over 2,700 megabytes (two gigabytes) of free storage - Built-in Google search that instantly finds any message you want - Automatic arrangement of messages and related replies into "conversations" - Powerful spam protection using innovative Google technology - No large, annoying ads--just small text ads and related pages that are relevant to the content of your messages To learn more about Gmail before registering, visit: http://mail.google.com/mail/help/benefits.html And, to see how easy it can be to switch to a new email service, check out our new switch guide: http://mail.google.com/mail/help/switch/ We're still working every day to improve Gmail, so we might ask for your comments and suggestions periodically. We hope you'll like Gmail. We do. And, it's only going to get better. Thanks, The Gmail Team (If clicking the URLs in this message does not work, copy and paste them into the address bar of your browser). From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 7 03:03:43 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EAF010656F2; Tue, 7 Apr 2009 03:03:43 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms173009pub.verizon.net (vms173009pub.verizon.net [206.46.173.9]) by mx1.freebsd.org (Postfix) with ESMTP id 499318FC0A; Tue, 7 Apr 2009 03:03:43 +0000 (UTC) (envelope-from babkin@verizon.net) MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_WiFBaHW3z0cbU6RwDfiehA)" Received: from verizon.net ([96.234.43.209]) by vms173009.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KHP0056BN5L84EC@vms173009.mailsrvcs.net>; Mon, 06 Apr 2009 22:03:21 -0500 (CDT) Sender: root Message-id: <49DAC4A1.589A5FE@verizon.net> Date: Mon, 06 Apr 2009 23:12:33 -0400 From: Sergey Babkin X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.7-RELEASE i386) X-Accept-Language: en, ru To: John Baldwin References: <1366225354.253456.1238948619308.JavaMail.root@vms124.mailsrvcs.net> <200904061154.19601.jhb@freebsd.org> <9bbcef730904061007y66a8440al3c43a6a6b6cd6ed6@mail.gmail.com> <200904061342.22000.jhb@freebsd.org> X-Mailman-Approved-At: Tue, 07 Apr 2009 04:49:07 +0000 Cc: freebsd-hackers@freebsd.org, Ivan Voras Subject: Re: Patch for MS Hyper V (virtualization) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 03:03:43 -0000 This is a multi-part message in MIME format. --Boundary_(ID_WiFBaHW3z0cbU6RwDfiehA) Content-type: text/plain; charset=koi8-r Content-transfer-encoding: 8BIT John Baldwin wrote: > > On Monday 06 April 2009 1:07:38 pm Ivan Voras wrote: > > 2009/4/6 John Baldwin : > > > On Sunday 05 April 2009 12:23:39 pm Sergey Babkin wrote: > > > > > Hmm, the problem is we need to be able to write to BARs to size them. Â Any > OS > > > needs to be able to do this to know what address space regions are being > > > decoded by devices. Â We can't avoid writing to BARs. > > > > I have only vague idea what BARs are and if it's the correct diagnosis > > in this case, but the fact is that other operating systems (Windows, > > Linux tested) work, so either there is a way around it or the original > > premise is wrong-ish. > > Every OS writes to BARs to size them during boot. It's the defined procedure > for sizing them. A BAR is a base address register, and it is how a PCI > device gets memory and I/O port resources. OS (or BIOS) writes a starting > address into the register to tell the PCI device where a given > resource "starts". The OS doesn't have to write to the BAR if BIOS has already done it. And the BIOS in the Hyper-V VM is obviously special, so it doesn't trip on iself. Anyway, as far as I can tell, it's only the base register of the simulated DEC21140 device that has this issue, so it's quite possible that the bug is in that device's simulator. I've attached a modified patch that checks conservatively for this precise situation, so it should not break compatibility with anything else. I've tested it on Hyper-V. -SB --Boundary_(ID_WiFBaHW3z0cbU6RwDfiehA) Content-type: text/plain; charset=koi8-r; name=hyperv.df Content-transfer-encoding: 7BIT Content-disposition: inline; filename=hyperv.df --- dev/pci/pci.c.0 2009-04-06 21:35:26.000000000 +0000 +++ dev/pci/pci.c 2009-04-06 22:43:08.000000000 +0000 @@ -3590,6 +3590,18 @@ struct pci_devinfo *dinfo = device_get_ivars(child); pcicfgregs *cfg = &dinfo->cfg; + /* A workaround for Hyper-V that hangs on VM stop + * if the base address register of the 21140 simulator is written; + * since on Hyper-V the value written is the same as the one + * already in the register, it can be simply skipped. + * 0x1011: DEC, 0x0009: 21140 */ + if (dinfo->cfg.vendor == 0x1011 && dinfo->cfg.device == 0x0009) { + if (reg == PCIR_BARS + && (val & ~3) == (PCIB_READ_CONFIG(device_get_parent(dev), + cfg->bus, cfg->slot, cfg->func, reg, width) & ~3) ) + return; + } + PCIB_WRITE_CONFIG(device_get_parent(dev), cfg->bus, cfg->slot, cfg->func, reg, val, width); } --Boundary_(ID_WiFBaHW3z0cbU6RwDfiehA)-- From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 7 06:00:37 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02AA2106570B for ; Tue, 7 Apr 2009 06:00:37 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell.rawbw.com (shell.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id E17DE8FC17 for ; Tue, 7 Apr 2009 06:00:36 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from eagle.syrec.org (ppp-71-139-21-14.dsl.snfc21.pacbell.net [71.139.21.14]) (authenticated bits=0) by shell.rawbw.com (8.13.6/8.13.6) with ESMTP id n3760ahJ061649; Mon, 6 Apr 2009 23:00:36 -0700 (PDT) Message-ID: <49DAEBFF.9020502@rawbw.com> Date: Mon, 06 Apr 2009 23:00:31 -0700 From: Yuri User-Agent: Thunderbird 2.0.0.21 (X11/20090322) MIME-Version: 1.0 To: "Shaowei Wang (wsw)" , freebsd-hackers@freebsd.org References: <49D6807D.1040902@rawbw.com> <2e566b9e0904062128id1c3312r9389c77b2a039c6a@mail.gmail.com> In-Reply-To: <2e566b9e0904062128id1c3312r9389c77b2a039c6a@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Is international support broken is msdosfs file system driver? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: yuri@rawbw.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 06:00:37 -0000 Shaowei Wang (wsw) wrote: > > try -L zh_CN.euc . zh_CN.euc doesn't exist, I tried zh_CN.eucCN instead. Didn't work. I tried all zh_CN* and zh_TW* ones from /usr/share/locale/ -- none of them worked. Nut the garbage displayed by 'ls' changes depending on the one used. > > Windows file system use a different way to encode i18n chars, like > code page. > > There is a hacked version of msdosfs which can support UTF-8 locale. > http://groups.google.com/group/btload/web/msdosfs.tar.bz2 > and for using: > mount_msdosfs -L zh_CN.UTF-8 /dev/ad?s? /path/to/mount > > I've tried it and it's work. http://groups.google.com/group/btload/web/msdosfs.tar.bz2 doesn't exist. Somehow in Windows the disk is read correctly without specifying any additional options. So I guess this is a serious defect that msdosfs driver can't do the same. Yuri From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 7 06:35:23 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1C1B106572A for ; Tue, 7 Apr 2009 06:35:23 +0000 (UTC) (envelope-from wsw1wsw2@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by mx1.freebsd.org (Postfix) with ESMTP id 6E8DE8FC15 for ; Tue, 7 Apr 2009 06:35:23 +0000 (UTC) (envelope-from wsw1wsw2@gmail.com) Received: by rv-out-0506.google.com with SMTP id l9so2480184rvb.43 for ; Mon, 06 Apr 2009 23:35:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=KvUn/mE2tSEmURnZBEuM7BWhFjssTlGTjPm0oU2d7ps=; b=lVs5vfDShcbSaDGCF5CW3frQ4y3rY3ybrMeweZZlR8XSgFNbmn8BGXAECVsA5sMLvz LGYG8h8q1pl9WTM2AJW2t/KtE+GfRZxsrpXbXDbXuw0/CK0rVrDM3ZqGoE6dZAKpLFW3 Sf0EywrChDJv0tyoVwiWY1WhRk4LiwJ87NfWw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=n3g4+LZoYT0wEjQxkhqTaE+lpmQVQUKID4hkfqQ35h0NbnOCt4Hq1dxdrLNa/6xSrl TnLL3o0o47RnvkEBEVHn99FCEFGsKrQRfJmnOP6zVeIPnOjEehU0/T9Dee8Bd60m43Vk p1CAHruyBvXkxMSThWTUJ8kwHW/RxltDu5h8M= MIME-Version: 1.0 Received: by 10.142.73.19 with SMTP id v19mr1522234wfa.324.1239086123010; Mon, 06 Apr 2009 23:35:23 -0700 (PDT) In-Reply-To: <49DAEBFF.9020502@rawbw.com> References: <49D6807D.1040902@rawbw.com> <2e566b9e0904062128id1c3312r9389c77b2a039c6a@mail.gmail.com> <49DAEBFF.9020502@rawbw.com> Date: Tue, 7 Apr 2009 14:35:22 +0800 Message-ID: <2e566b9e0904062335w19eecca5h8f30ee26ded6ac10@mail.gmail.com> From: "Shaowei Wang (wsw)" To: yuri@rawbw.com Content-Type: multipart/mixed; boundary=001636e1fd83354aff0466f138a0 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: Is international support broken is msdosfs file system driver? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 06:35:24 -0000 --001636e1fd83354aff0466f138a0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On Tue, Apr 7, 2009 at 2:00 PM, Yuri wrote: > Shaowei Wang (wsw) wrote: > >> >> try -L zh_CN.euc . >> > zh_CN.euc doesn't exist, I tried zh_CN.eucCN instead. Didn't work. > I tried all zh_CN* and zh_TW* ones from /usr/share/locale/ -- none of them > worked. > Nut the garbage displayed by 'ls' changes depending on the one used. > You locale should be same as the param which passed to the -L option and make sure your xterm(rxvt) can display chinese chars. > > >> Windows file system use a different way to encode i18n chars, like code >> page. >> >> There is a hacked version of msdosfs which can support UTF-8 locale. >> http://groups.google.com/group/btload/web/msdosfs.tar.bz2 >> and for using: >> mount_msdosfs -L zh_CN.UTF-8 /dev/ad?s? /path/to/mount >> >> I've tried it and it's work. >> > > http://groups.google.com/group/btload/web/msdosfs.tar.bz2 doesn't exist. Please try the attached file. > > > Somehow in Windows the disk is read correctly without specifying any > additional options. > So I guess this is a serious defect that msdosfs driver can't do the same. > I think so. > > > Yuri > > --001636e1fd83354aff0466f138a0-- From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 7 12:37:29 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8D2C1065674 for ; Tue, 7 Apr 2009 12:37:29 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 34DF88FC08 for ; Tue, 7 Apr 2009 12:37:28 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA02716 for ; Tue, 07 Apr 2009 15:37:27 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <49DB4906.7080407@icyb.net.ua> Date: Tue, 07 Apr 2009 15:37:26 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org References: <49D4A16F.6020906@icyb.net.ua> In-Reply-To: <49D4A16F.6020906@icyb.net.ua> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: Re: watchdog: hw+sw? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 12:37:30 -0000 I've been thinking about this some more. So, clearly, sw watchdog is different from all the hw watchdogs (that I know about) in that it tries to take a debugging action as opposed to a straightforward recovery action. As such it currently doesn't make much sense to mix sw and hw watchdogs together, because in the case of a problem they would fire at close times and a (typical) hw watchdog would override sw watchdog. This is fine as it is, maybe a small warning in a case of such mix would be nice too. However, I think that it should be possible to use sw watchdog as a special "primary" watchdog and hw watchdog(s) as "failsafe" watchdogs for the primary one. I see two general approaches at the moment: 1. hw watchdog has only "slightly" longer timeout than the sw watchdog (by a configurable delta), the watchdogs gets patted at the same time; if the sw wd fires and is able to proceed, it first disables hw watchdog(s) and the performs its duty (panic, ddb); 2. hw watchdog has "substantially" longer timeout that the sw watchdog (by a configurable delta), the watchdogs gets patted at the same time; if the sw wd fires it has a limited amount of time to do its action before the hw wd fires too; in this case it would also be nice to have a short ddb command for stopping hw watchdog. Each approach has its own advantages and disadvantages. The first approach guarantees that sw wd would not be interrupted by hw wd. On the other hand, there is no protection e.g. from a system getting stuck during a dump. Also, hw watchdogs would have to provide a method for "emergency stop" that should be safe from locking issues. The second approach is more robust. Its problems: (a) it can interrupt sw wd action too early; (b) it wastes more time if sw wd is not able to fire. Since using sw and hw watchdogs together makes more sense in unattended scenarios, I think that approach #2 may be better. IMO, attended scenarios should use sw wd exclusively. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 7 13:08:25 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E531E1065670; Tue, 7 Apr 2009 13:08:25 +0000 (UTC) (envelope-from fbsdlists@honeyguide.net) Received: from jail0064.vps.exonetric.net (jail0064.vps.exonetric.net [82.138.248.239]) by mx1.freebsd.org (Postfix) with ESMTP id AA1588FC1E; Tue, 7 Apr 2009 13:08:25 +0000 (UTC) (envelope-from fbsdlists@honeyguide.net) Received: from [10.221.119.32] (tmo-100-80.customers.d1-online.com [80.187.100.80]) by jail0064.vps.exonetric.net (Postfix) with ESMTP id CD0E1D4B0F; Tue, 7 Apr 2009 12:50:33 +0000 (GMT) Message-Id: From: Stephan Lichtenauer To: freebsd-hackers@freebsd.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 7 Apr 2009 14:50:15 +0200 References: <1fe1d5d60903210422g70efef15hdd685695cdf8df3c@mail.gmail.com> <1fe1d5d60904020904ya6dcb00h54a54d6a00e2bd0@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: Gabriele Modena , Robert Watson Subject: Re: GSoC: Semantic File System X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 13:08:26 -0000 Gabriele, Robert, Am 02.04.2009 um 19:26 schrieb Robert Watson: > > In the BeOS model, or my reinterpretation based on something I read > a long time ago and then presumably had dreams about, the split is a > bit different: the file system maintains indexes of extended > attributes, which are written by applications in order to expose > searchable material. For example, a mail application might write > out each message as a file, and attach a series of extended > attributes, such as subject line, date, author, etc. These extended > attributes are then indexed automatically by the file system in > order to allow queries to be evaluated. I don't recall how queries > and results are expressed, and in particular, whether the queries > are processed by the file system (possibly exposed via special APIs > or the name space) or userspace (accessing special files maintained > by the kernel that are the indexes). > > It's also worth observing that one of the authors of BFS was Dominic > Giampaolo, who now works on Apple's HFS+, and implemented fsevents > there as part of their Spotlight project. > Maybe you also might be interested that there is a PDF document (formerly book) from Dominic available describing the BeOS file system in great detail: http://www.haiku-os.org/legacy-docs/practical-file-system-design.pdf Additionally, there seems to be a GSoC project to create something like Spotlight for Haiku, the open source BeOS clone. You could browse through the haiku-developer mailing list archives at http://www.freelists.org/archive/haiku-development , the thread where this has been discussed is titled "Need Some GSoC Advice" with the first mail from 21 March. Stephan From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 7 13:16:15 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BE87106566C for ; Tue, 7 Apr 2009 13:16:15 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 03F2D8FC13 for ; Tue, 7 Apr 2009 13:16:15 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 9B17846C08; Tue, 7 Apr 2009 09:16:14 -0400 (EDT) Date: Tue, 7 Apr 2009 14:16:14 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Stephan Lichtenauer In-Reply-To: Message-ID: References: <1fe1d5d60903210422g70efef15hdd685695cdf8df3c@mail.gmail.com> <1fe1d5d60904020904ya6dcb00h54a54d6a00e2bd0@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, Gabriele Modena Subject: Re: GSoC: Semantic File System X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 13:16:15 -0000 On Tue, 7 Apr 2009, Stephan Lichtenauer wrote: > Am 02.04.2009 um 19:26 schrieb Robert Watson: > >> In the BeOS model, or my reinterpretation based on something I read a long >> time ago and then presumably had dreams about, the split is a bit >> different: the file system maintains indexes of extended attributes, which >> are written by applications in order to expose searchable material. For >> example, a mail application might write out each message as a file, and >> attach a series of extended attributes, such as subject line, date, author, >> etc. These extended attributes are then indexed automatically by the file >> system in order to allow queries to be evaluated. I don't recall how >> queries and results are expressed, and in particular, whether the queries >> are processed by the file system (possibly exposed via special APIs or the >> name space) or userspace (accessing special files maintained by the kernel >> that are the indexes). >> >> It's also worth observing that one of the authors of BFS was Dominic >> Giampaolo, who now works on Apple's HFS+, and implemented fsevents there as >> part of their Spotlight project. > > Maybe you also might be interested that there is a PDF document (formerly > book) from Dominic available describing the BeOS file system in great > detail: http://www.haiku-os.org/legacy-docs/practical-file-system-design.pdf > > Additionally, there seems to be a GSoC project to create something like > Spotlight for Haiku, the open source BeOS clone. You could browse through > the haiku-developer mailing list archives at > http://www.freelists.org/archive/haiku-development, the thread where this > has been discussed is titled "Need Some GSoC Advice" with the first mail > from 21 March. Actually, I have a original copy of the book on the bookshelf behind me. :-) Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 7 14:28:50 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BC8E106564A; Tue, 7 Apr 2009 14:28:50 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id EFC638FC15; Tue, 7 Apr 2009 14:28:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 8987946B39; Tue, 7 Apr 2009 10:28:49 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 76B1C8A04B; Tue, 7 Apr 2009 10:28:48 -0400 (EDT) From: John Baldwin To: Sergey Babkin Date: Tue, 7 Apr 2009 09:21:13 -0400 User-Agent: KMail/1.9.7 References: <1366225354.253456.1238948619308.JavaMail.root@vms124.mailsrvcs.net> <200904061342.22000.jhb@freebsd.org> <49DAC4A1.589A5FE@verizon.net> In-Reply-To: <49DAC4A1.589A5FE@verizon.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200904070921.14294.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 07 Apr 2009 10:28:48 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.1 required=4.2 tests=RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-hackers@freebsd.org, Ivan Voras Subject: Re: Patch for MS Hyper V (virtualization) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 14:28:50 -0000 On Monday 06 April 2009 11:12:33 pm Sergey Babkin wrote: > John Baldwin wrote: > >=20 > > On Monday 06 April 2009 1:07:38 pm Ivan Voras wrote: > > > 2009/4/6 John Baldwin : > > > > On Sunday 05 April 2009 12:23:39 pm Sergey Babkin wrote: > > > > > > > Hmm, the problem is we need to be able to write to BARs to size the= m.=20 =D0=B1 Any > > OS > > > > needs to be able to do this to know what address space regions are= =20 being > > > > decoded by devices. =D0=B1 We can't avoid writing to BARs. > > > > > > I have only vague idea what BARs are and if it's the correct diagnosis > > > in this case, but the fact is that other operating systems (Windows, > > > Linux tested) work, so either there is a way around it or the original > > > premise is wrong-ish. > >=20 > > Every OS writes to BARs to size them during boot. It's the defined=20 procedure > > for sizing them. A BAR is a base address register, and it is how a PCI > > device gets memory and I/O port resources. OS (or BIOS) writes a start= ing > > address into the register to tell the PCI device where a given > > resource "starts". >=20 > The OS doesn't have to write to the BAR if BIOS has already > done it. And the BIOS in the Hyper-V VM is obviously special, > so it doesn't trip on iself.=20 Yes it does because we don't know how _big_ the BAR is. The OS has to know= if=20 the device is decoding 1MB or 64KB because we need to reserve the entire=20 window to prevent any other devices from using it. We don't just write the= =20 existing value, we write all 1's to it and read it back. The lower N=20 bits "stick" at zero and we use that to figure out the BAR's size. See=20 pci_add_map() in sys/dev/pci/pci.c > Anyway, as far as I can tell, it's only the base register of=20 > the simulated DEC21140 device that has this issue, so it's=20 > quite possible that the bug is in that device's simulator.=20 >=20 > I've attached a modified patch that checks conservatively for this > precise situation, so it should not break compatibility with > anything else. I've tested it on Hyper-V. Can you test unmodified FreeBSD 8 on Hyper-V? It has an extra fix relative= to=20 7 to disable decoding via the PCI command register while sizing BARs that m= ay=20 address this. =2D-=20 John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 7 15:04:26 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 228EF106566C for ; Tue, 7 Apr 2009 15:04:26 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by mx1.freebsd.org (Postfix) with ESMTP id A06A08FC0C for ; Tue, 7 Apr 2009 15:04:25 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: by an-out-0708.google.com with SMTP id d11so1621108and.13 for ; Tue, 07 Apr 2009 08:04:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=86S2fpiGHpbCVlMP231XtS5VSSyoRhUw8WfXcXD9BMU=; b=VQLzR2USxxp5BN/hzvgnZDty8lWu4hKLAadFC5p0ovXZSgD67078aYOJJtjnUzSaxM hDWvp+dCGw8R4V22yU5c6Yr9gd34r0zwFusQ4ljSQuzy9+BrPCOYPIkop2ib8LSXts4y mHFzfqtR1+WuqF/esmIEoiGv7Dmyv9jbvEFTo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=r+6s25AkxJ2E9Xa9b0jYAsQi0EaAwBOCVaxuwkXG0FDQlpmeadhCEKs8pIsLae+ok0 V5SK+6oB5G2gU8WHfabbZVGH5QyRlvpkszCdJbP6UkGILLaEJAZGSRixvGmGdPhHgzV3 PxqDR6OlhE+TH4v72P8msYDRu4hs4Zr97u2HM= MIME-Version: 1.0 Received: by 10.101.69.6 with SMTP id w6mr318011ank.71.1239116652034; Tue, 07 Apr 2009 08:04:12 -0700 (PDT) In-Reply-To: <200904070921.14294.jhb@freebsd.org> References: <1366225354.253456.1238948619308.JavaMail.root@vms124.mailsrvcs.net> <200904061342.22000.jhb@freebsd.org> <49DAC4A1.589A5FE@verizon.net> <200904070921.14294.jhb@freebsd.org> Date: Tue, 7 Apr 2009 11:04:11 -0400 Message-ID: <3c0b01820904070804s1aa63cc3ife542e7001f5497c@mail.gmail.com> From: Alexander Sack To: John Baldwin Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, Sergey Babkin , Ivan Voras Subject: Re: Patch for MS Hyper V (virtualization) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 15:04:26 -0000 On Tue, Apr 7, 2009 at 9:21 AM, John Baldwin wrote: > On Monday 06 April 2009 11:12:33 pm Sergey Babkin wrote: >> John Baldwin wrote: >> > >> > On Monday 06 April 2009 1:07:38 pm Ivan Voras wrote: >> > > 2009/4/6 John Baldwin : >> > > > On Sunday 05 April 2009 12:23:39 pm Sergey Babkin wrote: >> > > >> > > > Hmm, the problem is we need to be able to write to BARs to size th= em. > =C2 Any >> > OS >> > > > needs to be able to do this to know what address space regions are > being >> > > > decoded by devices. =C2 We can't avoid writing to BARs. >> > > >> > > I have only vague idea what BARs are and if it's the correct diagnos= is >> > > in this case, but the fact is that other operating systems (Windows, >> > > Linux tested) work, so either there is a way around it or the origin= al >> > > premise is wrong-ish. >> > >> > Every OS writes to BARs to size them during boot. =9AIt's the defined > procedure >> > for sizing them. =9AA BAR is a base address register, and it is how a = PCI >> > device gets memory and I/O port resources. =9AOS (or BIOS) writes a st= arting >> > address into the register to tell the PCI device where a given >> > resource "starts". >> >> The OS doesn't have to write to the BAR if BIOS has already >> done it. And the BIOS in the Hyper-V VM is obviously special, >> so it doesn't trip on iself. > > Yes it does because we don't know how _big_ the BAR is. =9AThe OS has to = know if > the device is decoding 1MB or 64KB because we need to reserve the entire > window to prevent any other devices from using it. =9AWe don't just write= the > existing value, we write all 1's to it and read it back. =9AThe lower N > bits "stick" at zero and we use that to figure out the BAR's size. =9ASee > pci_add_map() in sys/dev/pci/pci.c John is 100% correct. Every kernel PCI driver has to figure out how big the BAR is and IN FACT typically the BIOS assigns more address space than the register set you are mapping. This is straight out of the PCI spec. -aps From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 7 15:12:55 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1ADAC106564A; Tue, 7 Apr 2009 15:12:55 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms173001pub.verizon.net (vms173001pub.verizon.net [206.46.173.1]) by mx1.freebsd.org (Postfix) with ESMTP id EC4B58FC08; Tue, 7 Apr 2009 15:12:54 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms124.mailsrvcs.net ([172.18.12.134]) by vms173001.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KHQ006THKX8DDII@vms173001.mailsrvcs.net>; Tue, 07 Apr 2009 10:12:44 -0500 (CDT) Received: from 65.242.108.162 ([65.242.108.162]) by vms124.mailsrvcs.net (Verizon Webmail) with HTTP; Tue, 07 Apr 2009 10:12:44 -0500 (CDT) Date: Tue, 07 Apr 2009 10:12:44 -0500 (CDT) From: Sergey Babkin To: jhb@freebsd.org Message-id: <365687070.340074.1239117164323.JavaMail.root@vms124.mailsrvcs.net> Content-transfer-encoding: quoted-printable X-Originating-IP: [65.242.108.162] X-Mailman-Approved-At: Tue, 07 Apr 2009 16:07:59 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, babkin@verizon.net, ivoras@freebsd.org Subject: Re: Re: Patch for MS Hyper V (virtualization) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 15:12:55 -0000 (Let's see if I've figured yet another workaround for the web interface= ). The address space used by the card I think is actually 0x80 bytes= , in the I/O port space. The card has it located at the port 0xEC00. Yester= day I've had all the values and addresses written to this card's registers = printed for debugging and I don't remember seeing all ones written to this = register. It was writing back first 0xEC01 (1 is the I/O space indicator), = then 0xEC00. And no, the culprit is not the missing bit 0 (which should be = read-only by the PCI spec): I've tried adding it back, and it made no diffe= rence. I'll try FreeBSD 8 and see what happens. -SB Ap= r 7, 2009 10:28:50 AM, [1]jhb@freebsd.org wrote: On Monday 06 April 2009 11:12:33= pm Sergey Babkin wrote: > John Baldwin wrote: > > > = > On Monday 06 April 2009 1:07:38 pm Ivan Voras wrote: > > >= 2009/4/6 John Baldwin <[2]jhb@freebsd.org>: > >= ; > > On Sunday 05 April 2009 12:23:39 pm Sergey Babkin wrote: >= ; > > > > > > Hmm, the problem is we need to be able t= o write to BARs to size them. =D0=B1 Any > > OS > > &= gt; > needs to be able to do this to know what address space regions are= being > > > > decoded by devices. =D0=B1 We can't avoid= writing to BARs. > > > > > > I have only vague ide= a what BARs are and if it's the correct diagnosis > > > in this= case, but the fact is that other operating systems (Windows, > > = > Linux tested) work, so either there is a way around it or the original= > > > premise is wrong-ish. > > > > Every O= S writes to BARs to size them during boot. It's the defined procedure<= br>> > for sizing them. A BAR is a base address register, and it is = how a PCI > > device gets memory and I/O port resources. OS (or B= IOS) writes a starting > > address into the register to tell the P= CI device where a given > > resource "starts". > > Th= e OS doesn't have to write to the BAR if BIOS has already > done it. = And the BIOS in the Hyper-V VM is obviously special, > so it doesn't = trip on iself. Yes it does because we don't know how _big_ the BAR = is. The OS has to know if the device is decoding 1MB or 64KB because w= e need to reserve the entire window to prevent any other devices from u= sing it. We don't just write the existing value, we write all 1's to i= t and read it back. The lower N bits "stick" at zero and we use that t= o figure out the BAR's size. See pci_add_map() in sys/dev/pci/pci.c > Anyway, as far as I can tell, it's only the base register of = > the simulated DEC21140 device that has this issue, so it's > qu= ite possible that the bug is in that device's simulator. > > = I've attached a modified patch that checks conservatively for this > = precise situation, so it should not break compatibility with > anythi= ng else. I've tested it on Hyper-V. Can you test unmodified FreeBSD = 8 on Hyper-V? It has an extra fix relative to 7 to disable decoding vi= a the PCI command register while sizing BARs that may address this. = -- John Baldwin References 1. 3D"mailto:jhb@freebsd.org" 2. 3D"mailto:jhb@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 7 18:35:33 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E364A106564A for ; Tue, 7 Apr 2009 18:35:33 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from mta1.srv.hcvlny.cv.net (mta1.srv.hcvlny.cv.net [167.206.4.196]) by mx1.freebsd.org (Postfix) with ESMTP id BBC338FC0C for ; Tue, 7 Apr 2009 18:35:33 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from flosoft.no-ip.biz (ool-435559b8.dyn.optonline.net [67.85.89.184]) by mta1.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0KHQ0053PUB2EXG0@mta1.srv.hcvlny.cv.net> for freebsd-hackers@freebsd.org; Tue, 07 Apr 2009 14:35:27 -0400 (EDT) Received: from flosoft.no-ip.biz (localhost [127.0.0.1]) by flosoft.no-ip.biz (8.14.3/8.14.3) with ESMTP id n37IZPo2042879; Tue, 07 Apr 2009 14:35:26 -0400 Date: Tue, 07 Apr 2009 14:35:25 -0400 From: "Aryeh M. Friedman" To: freebsd-hackers@freebsd.org Message-id: <49DB9CED.2030603@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0.0.21 (X11/20090331) Subject: DNS problems X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 18:35:34 -0000 I have registered and pointed to my name server the following domains: istudentunion.com (.net and .org) They resolve locally but do not resolve remotely.... it has been 24 hrs so some propagation should of occured... I tested resolving remotely with hardcoding the nameserver to be me and that works... what else should I look at... I am using the named in base 7.2-PREREALSE (i386) and used the guidelines in O'reilly's DNS and BIND.... what other tests configs should I try? (I double checked the zone type and that I have all the trailing dots) Note I have also transfered registers in the last 24 hrs (but whois has all the right data) From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 7 19:01:40 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F6DE1065673 for ; Tue, 7 Apr 2009 19:01:40 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id C78608FC08 for ; Tue, 7 Apr 2009 19:01:39 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 376E728448 for ; Wed, 8 Apr 2009 03:01:38 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 613D8EDD2A3; Wed, 8 Apr 2009 03:01:37 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id gjLavuvIUVim; Wed, 8 Apr 2009 03:01:32 +0800 (CST) Received: from charlie.delphij.net (adsl-76-237-33-62.dsl.pltn13.sbcglobal.net [76.237.33.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id E6425EBAED1; Wed, 8 Apr 2009 03:01:30 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=VLWJDYhLrqFPHxpZNfT8/l6J7u6GuZwWtHfNdxbkUcNEAWxg4IYejCOtD38+2LCWn ZczpNXInIwdAlAv6OApPQ== Message-ID: <49DBA307.30307@delphij.net> Date: Tue, 07 Apr 2009 12:01:27 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.21 (X11/20090324) MIME-Version: 1.0 To: "Aryeh M. Friedman" References: <49DB9CED.2030603@gmail.com> In-Reply-To: <49DB9CED.2030603@gmail.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: DNS problems X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 19:01:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aryeh M. Friedman wrote: > I have registered and pointed to my name server the following domains: > > istudentunion.com (.net and .org) > > They resolve locally but do not resolve remotely.... it has been 24 hrs > so some propagation should of occured... I tested resolving remotely > with hardcoding the nameserver to be me and that works... what else > should I look at... I am using the named in base 7.2-PREREALSE (i386) > and used the guidelines in O'reilly's DNS and BIND.... what other tests > configs should I try? (I double checked the zone type and that I have > all the trailing dots) > > Note I have also transfered registers in the last 24 hrs (but whois has > all the right data) BIND by default listen on lo0 only. Check your /etc/namedb/named.conf. - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAknbowcACgkQi+vbBBjt66BPRwCdE3cAE8U+3687Dl9ICDx5PIsv 6pEAn1ZCCPmEJiFw7UkM2E7ErTLvG2S5 =k1/J -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 7 19:05:01 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63F2310656C9 for ; Tue, 7 Apr 2009 19:05:01 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from mta3.srv.hcvlny.cv.net (mta3.srv.hcvlny.cv.net [167.206.4.198]) by mx1.freebsd.org (Postfix) with ESMTP id 361388FC14 for ; Tue, 7 Apr 2009 19:05:01 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from flosoft.no-ip.biz (ool-435559b8.dyn.optonline.net [67.85.89.184]) by mta3.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0KHQ008P9VO34GF0@mta3.srv.hcvlny.cv.net> for freebsd-hackers@freebsd.org; Tue, 07 Apr 2009 15:04:51 -0400 (EDT) Received: from flosoft.no-ip.biz (localhost [127.0.0.1]) by flosoft.no-ip.biz (8.14.3/8.14.3) with ESMTP id n37J4nko000277; Tue, 07 Apr 2009 15:04:51 -0400 Date: Tue, 07 Apr 2009 15:04:49 -0400 From: "Aryeh M. Friedman" In-reply-to: <49DBA307.30307@delphij.net> To: d@delphij.net Message-id: <49DBA3D1.6060904@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT References: <49DB9CED.2030603@gmail.com> <49DBA307.30307@delphij.net> User-Agent: Thunderbird 2.0.0.21 (X11/20090331) Cc: freebsd-hackers@freebsd.org Subject: Re: DNS problems X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 19:05:02 -0000 Already did (went a step farther had my machine at home -CURRENT use the one at work [the one with the probldem] as it's /etc/resolv.conf and as a forwarder in my named.conf and both worked fine) Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Aryeh M. Friedman wrote: > >> I have registered and pointed to my name server the following domains: >> >> istudentunion.com (.net and .org) >> >> They resolve locally but do not resolve remotely.... it has been 24 hrs >> so some propagation should of occured... I tested resolving remotely >> with hardcoding the nameserver to be me and that works... what else >> should I look at... I am using the named in base 7.2-PREREALSE (i386) >> and used the guidelines in O'reilly's DNS and BIND.... what other tests >> configs should I try? (I double checked the zone type and that I have >> all the trailing dots) >> >> Note I have also transfered registers in the last 24 hrs (but whois has >> all the right data) >> > > BIND by default listen on lo0 only. Check your /etc/namedb/named.conf. > > - -- > Xin LI http://www.delphij.net/ > FreeBSD - The Power to Serve! > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.11 (FreeBSD) > > iEYEARECAAYFAknbowcACgkQi+vbBBjt66BPRwCdE3cAE8U+3687Dl9ICDx5PIsv > 6pEAn1ZCCPmEJiFw7UkM2E7ErTLvG2S5 > =k1/J > -----END PGP SIGNATURE----- > > From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 7 19:06:57 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B919C10656E2 for ; Tue, 7 Apr 2009 19:06:57 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from mta5.srv.hcvlny.cv.net (mta5.srv.hcvlny.cv.net [167.206.4.200]) by mx1.freebsd.org (Postfix) with ESMTP id 8E4358FC19 for ; Tue, 7 Apr 2009 19:06:57 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from flosoft.no-ip.biz (ool-435559b8.dyn.optonline.net [67.85.89.184]) by mta5.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0KHQ00B5ZVRFKNM0@mta5.srv.hcvlny.cv.net> for freebsd-hackers@freebsd.org; Tue, 07 Apr 2009 15:06:52 -0400 (EDT) Received: from flosoft.no-ip.biz (localhost [127.0.0.1]) by flosoft.no-ip.biz (8.14.3/8.14.3) with ESMTP id n37J6pLV000323; Tue, 07 Apr 2009 15:06:51 -0400 Date: Tue, 07 Apr 2009 15:06:51 -0400 From: "Aryeh M. Friedman" In-reply-to: <49DBA3D1.6060904@gmail.com> To: d@delphij.net Message-id: <49DBA44B.2070308@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT References: <49DB9CED.2030603@gmail.com> <49DBA307.30307@delphij.net> <49DBA3D1.6060904@gmail.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090331) Cc: freebsd-hackers@freebsd.org Subject: Re: DNS problems X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 19:06:58 -0000 Aryeh M. Friedman wrote: > Already did (went a step farther had my machine at home -CURRENT use > the one at work [the one with the probldem] as it's /etc/resolv.conf > and as a forwarder in my named.conf and both worked fine) > Forgot to mention that different ISP's so it is not a port blocking problem > > Xin LI wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Aryeh M. Friedman wrote: >> >>> I have registered and pointed to my name server the following domains: >>> >>> istudentunion.com (.net and .org) >>> >>> They resolve locally but do not resolve remotely.... it has been 24 hrs >>> so some propagation should of occured... I tested resolving remotely >>> with hardcoding the nameserver to be me and that works... what else >>> should I look at... I am using the named in base 7.2-PREREALSE >>> (i386) and used the guidelines in O'reilly's DNS and BIND.... what >>> other tests >>> configs should I try? (I double checked the zone type and that I have >>> all the trailing dots) >>> >>> Note I have also transfered registers in the last 24 hrs (but whois has >>> all the right data) >>> >> >> BIND by default listen on lo0 only. Check your /etc/namedb/named.conf. >> >> - -- >> Xin LI http://www.delphij.net/ >> FreeBSD - The Power to Serve! >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2.0.11 (FreeBSD) >> >> iEYEARECAAYFAknbowcACgkQi+vbBBjt66BPRwCdE3cAE8U+3687Dl9ICDx5PIsv >> 6pEAn1ZCCPmEJiFw7UkM2E7ErTLvG2S5 >> =k1/J >> -----END PGP SIGNATURE----- >> >> > > From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 7 19:16:33 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0458106566B for ; Tue, 7 Apr 2009 19:16:33 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-qy0-f134.google.com (mail-qy0-f134.google.com [209.85.221.134]) by mx1.freebsd.org (Postfix) with ESMTP id 581B98FC14 for ; Tue, 7 Apr 2009 19:16:33 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: by qyk40 with SMTP id 40so4979050qyk.3 for ; Tue, 07 Apr 2009 12:16:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=fq9mM/VD2b5OfbyGtxqkbkgih9evWUpPpCi1/pmUHqM=; b=uNxSl16p2T8HBZm19yzto/jIhptGhPj94+oDHhQAmjoeEHNzOxgBJ0zf6DTYLo+ae8 LDfDNJISMMzeTbBmd53EAVrBuCo0QYFccCZ7eJf40/r3Fu56pFGCum2KNFWm8guGUnKb mroSy4alGb+lzI1j1dZD0en9xOyPntbah7vLc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=JqAKT9ryp/2VKUIap4dHhrFy+vkWj3MWJoLzNGV9yZnECXYzChtfn3lZ5uzmZ3+BSI 9rWsPbW8iWF5oa/DUj2frLi3DrZWKWtcX6IeZNXwxWRNAyGRBWq55eWFoLXJi7oaQv4r OaJahw8E4FDgBzFjcAjpFDr5yEipELsll2aWY= MIME-Version: 1.0 Received: by 10.220.45.205 with SMTP id g13mr872241vcf.64.1239131792506; Tue, 07 Apr 2009 12:16:32 -0700 (PDT) Date: Tue, 7 Apr 2009 12:16:32 -0700 Message-ID: From: Navdeep Parhar To: FreeBSD Hackers Content-Type: multipart/mixed; boundary=0016364ec8685281e50466fbda97 Subject: KLDs missing CTF information (patch attached) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 19:16:34 -0000 --0016364ec8685281e50466fbda97 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit It appears that the KLD build process is missing a ctfmerge at the end, and this results in KLDs with incomplete CTF information. Here is a patch that fixes this. I verified it on amd64 with various KLDs. Before: # ctfdump /boot/kernel/if_cxgb.ko | wc -l 2269 # ctfdump /boot/kernel/zfs.ko | wc -l 430 After: # ctfdump /boot/kernel/if_cxgb.ko | wc -l 6568 # ctfdump /boot/kernel/zfs.ko | wc -l 15032 It is wasteful to have CTF information in both the .ko and the .ko.symbols file but this is what the kernel does too. Regards, Navdeep --0016364ec8685281e50466fbda97 Content-Type: application/octet-stream; name="ctf-kld.patch" Content-Disposition: attachment; filename="ctf-kld.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ft8yyxoz0 ZGlmZiAtciBiM2Y0ZTZhODJhODYgc3lzL2NvbmYva21vZC5tawotLS0gYS9zeXMvY29uZi9rbW9k Lm1rCU1vbiBBcHIgMDYgMTM6NDc6MzkgMjAwOSAtMDcwMAorKysgYi9zeXMvY29uZi9rbW9kLm1r CVR1ZSBBcHIgMDcgMTI6MDA6NTIgMjAwOSAtMDcwMApAQCAtMTI4LDYgKzEyOCwxMCBAQAogQ0ZM QUdTKz0JLW1sb25nY2FsbCAtZm5vLW9taXQtZnJhbWUtcG9pbnRlcgogLmVuZGlmCiAKKy5pZiBk ZWZpbmVkKERFQlVHKSB8fCBkZWZpbmVkKERFQlVHX0ZMQUdTKQorQ1RGRkxBR1MrPQktZworLmVu ZGlmCisKIC5pZiBkZWZpbmVkKEZJUk1XUykKIC5pZiAhZXhpc3RzKEApCiAke0tNT0Q6Uy8kLy5j L306IEAKQEAgLTE5Myw2ICsxOTcsOSBAQAogJHtGVUxMUFJPR306ICR7T0JKU30KIC5lbmRpZgog CSR7TER9ICR7TERGTEFHU30gLXIgLWQgLW8gJHsuVEFSR0VUfSAke09CSlN9CisuaWYgZGVmaW5l ZChDVEZNRVJHRSkKKwkke0NURk1FUkdFfSAke0NURkZMQUdTfSAtbyAkey5UQVJHRVR9ICR7T0JK U30KKy5lbmRpZgogLmlmIGRlZmluZWQoRVhQT1JUX1NZTVMpCiAuaWYgJHtFWFBPUlRfU1lNU30g IT0gWUVTCiAuaWYgJHtFWFBPUlRfU1lNU30gPT0gTk8K --0016364ec8685281e50466fbda97-- From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 7 19:36:23 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB92710656BD for ; Tue, 7 Apr 2009 19:36:23 +0000 (UTC) (envelope-from george@m5p.com) Received: from mailhost.m5p.com (unknown [IPv6:2001:418:3fd::3]) by mx1.freebsd.org (Postfix) with ESMTP id 8F9608FC15 for ; Tue, 7 Apr 2009 19:36:23 +0000 (UTC) (envelope-from george@m5p.com) Received: from m5p.com (ssh.m5p.com [IPv6:2001:418:3fd::fb]) by mailhost.m5p.com (8.14.3/8.14.3) with ESMTP id n37JaGXL013262 for ; Tue, 7 Apr 2009 15:36:21 -0400 (EDT) (envelope-from george@m5p.com) Received: (from george@localhost) by m5p.com (8.14.2/8.13.7/Submit) id n37JaGGp032845; Tue, 7 Apr 2009 15:36:16 -0400 (EDT) Date: Tue, 7 Apr 2009 15:36:16 -0400 (EDT) Message-Id: <200904071936.n37JaGGp032845@m5p.com> From: george+freebsd@m5p.com To: freebsd-hackers@freebsd.org In-Reply-To: <49DB9CED.2030603@gmail.com> X-Spam-Score: -2.313 () BAYES_00,NO_RELAYS X-Scanned-By: MIMEDefang 2.64 on IPv6:2001:418:3fd::f7 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mailhost.m5p.com [IPv6:2001:418:3fd::f7]); Tue, 07 Apr 2009 15:36:21 -0400 (EDT) Subject: Re: DNS problems X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 19:36:24 -0000 > I have registered and pointed to my name server the following domains: > > istudentunion.com (.net and .org) > > They resolve locally but do not resolve remotely.... it has been 24 hrs > so some propagation should of occured... I tested resolving remotely > with hardcoding the nameserver to be me and that works... what else > should I look at... I am using the named in base 7.2-PREREALSE (i386) > and used the guidelines in O'reilly's DNS and BIND.... what other tests > configs should I try? (I double checked the zone type and that I have > all the trailing dots) > > Note I have also transfered registers in the last 24 hrs (but whois has > all the right data) Your registrar has not inserted the glue records for your name servers into the root zone. Try a different registrar. -- George Mitchell From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 8 01:03:48 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8844E1065670; Wed, 8 Apr 2009 01:03:48 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from vms173005pub.verizon.net (vms173005pub.verizon.net [206.46.173.5]) by mx1.freebsd.org (Postfix) with ESMTP id 684638FC22; Wed, 8 Apr 2009 01:03:48 +0000 (UTC) (envelope-from babkin@verizon.net) Received: from verizon.net ([96.234.43.209]) by vms173005.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KHR007T2CA3KJEM@vms173005.mailsrvcs.net>; Tue, 07 Apr 2009 20:03:42 -0500 (CDT) Sender: root Message-id: <49DBFA72.9E64AB4F@verizon.net> Date: Tue, 07 Apr 2009 21:14:26 -0400 From: Sergey Babkin X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.7-RELEASE i386) X-Accept-Language: en, ru MIME-version: 1.0 To: John Baldwin References: <1366225354.253456.1238948619308.JavaMail.root@vms124.mailsrvcs.net> <200904061342.22000.jhb@freebsd.org> <49DAC4A1.589A5FE@verizon.net> <200904070921.14294.jhb@freebsd.org> Content-type: text/plain; charset=koi8-r Content-transfer-encoding: 7bit X-Mailman-Approved-At: Wed, 08 Apr 2009 01:49:15 +0000 Cc: freebsd-hackers@freebsd.org, Ivan Voras Subject: Re: Patch for MS Hyper V (virtualization) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 01:03:48 -0000 John Baldwin wrote: > > On Monday 06 April 2009 11:12:33 pm Sergey Babkin wrote: > > Anyway, as far as I can tell, it's only the base register of > > the simulated DEC21140 device that has this issue, so it's > > quite possible that the bug is in that device's simulator. > > > > I've attached a modified patch that checks conservatively for this > > precise situation, so it should not break compatibility with > > anything else. I've tested it on Hyper-V. > > Can you test unmodified FreeBSD 8 on Hyper-V? It has an extra fix relative to > 7 to disable decoding via the PCI command register while sizing BARs that may > address this. 8.0 (February snapshot) seems to have the same issue. I've also saved the log of writes that 7.1 does for this device: reg 10 val ec01 reg 14 val febff000 reg 18 val 0 reg 1c val 0 reg 20 val 0 reg 24 val 0 reg 30 val febe0000 reg 4 val 117 reg 3c val b reg 3d val 1 reg 3e val 14 reg 3f val 28 reg c val 8 reg d val 40 reg 9 val 0 reg 8 val 20 reg 10 val ec00 reg 14 val febff000 reg 4 val 117 reg 4 val 117 I don't see any ffffffff values. -SB From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 8 08:57:22 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D7061065673 for ; Wed, 8 Apr 2009 08:57:22 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id D36388FC1D for ; Wed, 8 Apr 2009 08:57:21 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from gidgate.gid.co.uk (80-46-130-69.static.dsl.as9105.com [80.46.130.69]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id n388gxBb057761; Wed, 8 Apr 2009 09:42:59 +0100 (BST) (envelope-from rb@gid.co.uk) Received: from [194.32.164.28] ([194.32.164.6]) by gidgate.gid.co.uk (8.13.8/8.13.8) with ESMTP id n388gsXV072785; Wed, 8 Apr 2009 09:42:54 +0100 (BST) (envelope-from rb@gid.co.uk) Message-Id: <953481EE-1A58-4852-BA23-8CB571939537@gid.co.uk> From: Bob Bishop To: "Aryeh M. Friedman" In-Reply-To: <49DB9CED.2030603@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 8 Apr 2009 09:42:53 +0100 References: <49DB9CED.2030603@gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: freebsd-hackers@freebsd.org Subject: Re: DNS problems X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 08:57:22 -0000 Hi, On 7 Apr 2009, at 19:35, Aryeh M. Friedman wrote: > I have registered and pointed to my name server the following domains: > > istudentunion.com (.net and .org) [etc] Actually, the registrar only seems to have delegated istudentunion.net I'm not sure that using a CNAME for the server(s) is a good idea either. -- Bob Bishop rb@gid.co.uk From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 8 09:00:12 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DEAD1065672 for ; Wed, 8 Apr 2009 09:00:12 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from mta4.srv.hcvlny.cv.net (mta4.srv.hcvlny.cv.net [167.206.4.199]) by mx1.freebsd.org (Postfix) with ESMTP id EFF148FC1C for ; Wed, 8 Apr 2009 09:00:11 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from flosoft.no-ip.biz (ool-435559b8.dyn.optonline.net [67.85.89.184]) by mta4.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0KHR007MCYBYV5F1@mta4.srv.hcvlny.cv.net> for freebsd-hackers@freebsd.org; Wed, 08 Apr 2009 04:59:58 -0400 (EDT) Received: from flosoft.no-ip.biz (localhost [127.0.0.1]) by flosoft.no-ip.biz (8.14.3/8.14.3) with ESMTP id n388xuxB000462; Wed, 08 Apr 2009 04:59:56 -0400 Date: Wed, 08 Apr 2009 04:59:56 -0400 From: "Aryeh M. Friedman" In-reply-to: <953481EE-1A58-4852-BA23-8CB571939537@gid.co.uk> To: Bob Bishop Message-id: <49DC678C.7070403@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT References: <49DB9CED.2030603@gmail.com> <953481EE-1A58-4852-BA23-8CB571939537@gid.co.uk> User-Agent: Thunderbird 2.0.0.21 (X11/20090331) Cc: freebsd-hackers@freebsd.org Subject: Re: DNS problems X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 09:00:14 -0000 Bob Bishop wrote: > Hi, > > On 7 Apr 2009, at 19:35, Aryeh M. Friedman wrote: > >> I have registered and pointed to my name server the following domains: >> >> istudentunion.com (.net and .org) [etc] > > Actually, the registrar only seems to have delegated istudentunion.net > > I'm not sure that using a CNAME for the server(s) is a good idea either. it is a huge ball of wax... they claimed they delegated everything but our nameservers are on .org and org is not delegated (according to dig)... what I did tempurarly was make the registers nameserver be the master but since it refuses to do a zone transfer all the internal IP;s and stuff are lost (as well as the MX since they do not offer MX [extra fee actually])... as to the CNAME issue I have used that for years (used to be a hosting ISP head sys/netadmin) and it is the recommended method in O'reilly... the only issue seems to be I have not done dns work in so long that I was used to bind 4 (but once I got used to the 8/9 semantics it seems to be working fine localy) From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 8 11:26:03 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 87C6210656C5 for ; Wed, 8 Apr 2009 11:26:03 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 13B6D8FC29 for ; Wed, 8 Apr 2009 11:26:02 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id n38BPgYX004277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 8 Apr 2009 13:25:42 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id n38BPdVR081316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Apr 2009 13:25:39 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id n38BPdRn074890; Wed, 8 Apr 2009 13:25:39 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id n38BPdf9074889; Wed, 8 Apr 2009 13:25:39 +0200 (CEST) (envelope-from ticso) Date: Wed, 8 Apr 2009 13:25:39 +0200 From: Bernd Walter To: Ed Schouten Message-ID: <20090408112538.GA68699@cicely7.cicely.de> References: <20090401205306.GO13393@hoeg.nl> <20090401205703.GX31897@deviant.kiev.zoral.com.ua> <20090401210835.GP13393@hoeg.nl> <20090401215308.GA91493@psconsult.nl> <20090402061003.GR13393@hoeg.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090402061003.GR13393@hoeg.nl> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: FreeBSD Hackers Subject: Re: How to increase the max pty's on Freebsd 7.0? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 11:26:04 -0000 On Thu, Apr 02, 2009 at 08:10:03AM +0200, Ed Schouten wrote: > * Paul Schenkeveld wrote: > > Or change 'pts' to, for example, 'pt' so without changing utmp and > > related stuff we'll have space for a four digit pty number. > > I've noticed lots of apps already misbehave because of the pty(4) -> > pts(4) migration. I guess using a new naming scheme would totally break > stuff. There are lots of apps that do things like: > > if (strncmp(tty, "tty", 3) != 0 && strncmp(tty, "pts/", 4) != 0) > printf("Not a valid pseudo-terminal!\n"); > > But those are just workarounds. Our utmp format is broken anyway. It's > not just UT_LINESIZE that's too small. I think we received many > complaints from people who want to increase UT_HOSTSIZE as well. Well, UT_HOSTSIZE can't hold a full sized IPv6 address. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 8 11:56:41 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FB2C1065674 for ; Wed, 8 Apr 2009 11:56:41 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.freebsd.org (Postfix) with ESMTP id 972A98FC27 for ; Wed, 8 Apr 2009 11:56:40 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-024-239.pools.arcor-ip.net [88.66.24.239]) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis) id 0ML29c-1LrWCG3lYB-0001mr; Wed, 08 Apr 2009 13:44:05 +0200 Received: (qmail 41079 invoked from network); 8 Apr 2009 11:43:54 -0000 Received: from fbsd8.laiers.local (192.168.4.200) by router.laiers.local with SMTP; 8 Apr 2009 11:43:54 -0000 From: Max Laier Organization: FreeBSD To: freebsd-hackers@freebsd.org, ticso@cicely.de Date: Wed, 8 Apr 2009 12:43:53 +0100 User-Agent: KMail/1.11.0 (FreeBSD/8.0-CURRENT; KDE/4.2.1; i386; ; ) References: <20090402061003.GR13393@hoeg.nl> <20090408112538.GA68699@cicely7.cicely.de> In-Reply-To: <20090408112538.GA68699@cicely7.cicely.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904081343.53600.max@love2party.net> X-Provags-ID: V01U2FsdGVkX19NrY7o/0h2v3bqRME2EsyP4XR9mfY0jOu9aah RLHhhm0Om5IxwliqV102UIbVZ2mLlLe6fgtE88y2aazBC5uyQ/ umV19TGa/i9RVY/IALh9Q== Cc: Ed Schouten Subject: Re: How to increase the max pty's on Freebsd 7.0? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 11:56:41 -0000 On Wednesday 08 April 2009 13:25:39 Bernd Walter wrote: > On Thu, Apr 02, 2009 at 08:10:03AM +0200, Ed Schouten wrote: > > * Paul Schenkeveld wrote: > > > Or change 'pts' to, for example, 'pt' so without changing utmp and > > > related stuff we'll have space for a four digit pty number. > > > > I've noticed lots of apps already misbehave because of the pty(4) -> > > pts(4) migration. I guess using a new naming scheme would totally break > > stuff. There are lots of apps that do things like: > > > > if (strncmp(tty, "tty", 3) != 0 && strncmp(tty, "pts/", 4) != 0) > > printf("Not a valid pseudo-terminal!\n"); > > > > But those are just workarounds. Our utmp format is broken anyway. It's > > not just UT_LINESIZE that's too small. I think we received many > > complaints from people who want to increase UT_HOSTSIZE as well. > > Well, UT_HOSTSIZE can't hold a full sized IPv6 address. RFC 1924 (still needs four more, but avoids ridiculously large UT_HOSTSIZE ;) -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 8 12:09:01 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4297106564A for ; Wed, 8 Apr 2009 12:09:01 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 517E28FC17 for ; Wed, 8 Apr 2009 12:09:00 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id n38C8iXX005938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 8 Apr 2009 14:08:44 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id n38C8gYe082596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Apr 2009 14:08:42 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id n38C8flR075023; Wed, 8 Apr 2009 14:08:41 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id n38C8fE3075022; Wed, 8 Apr 2009 14:08:41 +0200 (CEST) (envelope-from ticso) Date: Wed, 8 Apr 2009 14:08:41 +0200 From: Bernd Walter To: Max Laier Message-ID: <20090408120841.GC68699@cicely7.cicely.de> References: <20090402061003.GR13393@hoeg.nl> <20090408112538.GA68699@cicely7.cicely.de> <200904081343.53600.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200904081343.53600.max@love2party.net> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: freebsd-hackers@freebsd.org, ticso@cicely.de, Ed Schouten Subject: Re: How to increase the max pty's on Freebsd 7.0? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 12:09:03 -0000 On Wed, Apr 08, 2009 at 12:43:53PM +0100, Max Laier wrote: > On Wednesday 08 April 2009 13:25:39 Bernd Walter wrote: > > On Thu, Apr 02, 2009 at 08:10:03AM +0200, Ed Schouten wrote: > > > * Paul Schenkeveld wrote: > > > > Or change 'pts' to, for example, 'pt' so without changing utmp and > > > > related stuff we'll have space for a four digit pty number. > > > > > > I've noticed lots of apps already misbehave because of the pty(4) -> > > > pts(4) migration. I guess using a new naming scheme would totally break > > > stuff. There are lots of apps that do things like: > > > > > > if (strncmp(tty, "tty", 3) != 0 && strncmp(tty, "pts/", 4) != 0) > > > printf("Not a valid pseudo-terminal!\n"); > > > > > > But those are just workarounds. Our utmp format is broken anyway. It's > > > not just UT_LINESIZE that's too small. I think we received many > > > complaints from people who want to increase UT_HOSTSIZE as well. > > > > Well, UT_HOSTSIZE can't hold a full sized IPv6 address. > > RFC 1924 (still needs four more, but avoids ridiculously large UT_HOSTSIZE ;) It doesn't handle scope information ;-) -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 8 14:04:09 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E59D1065696 for ; Wed, 8 Apr 2009 14:04:09 +0000 (UTC) (envelope-from mehulc87@gmail.com) Received: from mail-qy0-f134.google.com (mail-qy0-f134.google.com [209.85.221.134]) by mx1.freebsd.org (Postfix) with ESMTP id 20ED38FC1D for ; Wed, 8 Apr 2009 14:04:09 +0000 (UTC) (envelope-from mehulc87@gmail.com) Received: by qyk40 with SMTP id 40so168432qyk.3 for ; Wed, 08 Apr 2009 07:04:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=PlOcBCy6E43pkWP5UWJlw921PUC//OV5/Xbg5+4KY1s=; b=LOwsPK9KwzNPxQdY9Rj8qTXkk9T998L/yvHg8Ln1aPdsPA1Efp0ozo4n9hySGzcyI0 CGV7ae1UD9qAX3i/3LdtBDguF+nmrGDuIQ/KjbC0DPsINymgmW5w+8Q9UQ15Cy/3grPq 6ILqAhv4WALl/HDd30tyJAno8DIjzMIsc2huQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=soKiO98o2B+Wf5V28gNMyKVTIm7B2U2CZakn8YECV5urkLqffnvZX8uZGq5fZB6th3 Rb26heSzmtfCIesDv/CbiyJ2d7xL+9QShRTYYJiXtt/MBK2f6MkRSEDmzghlVjJGZTOM Y+LbIaUOYAEE+kQwdEmWWjgrQ65qL1Eq2iarY= MIME-Version: 1.0 Received: by 10.229.97.19 with SMTP id j19mr565518qcn.54.1239198190917; Wed, 08 Apr 2009 06:43:10 -0700 (PDT) Date: Wed, 8 Apr 2009 19:13:10 +0530 Message-ID: <251d650c0904080643o8789860w87c8cca070a16489@mail.gmail.com> From: Mehul Chadha To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: working of syscall handling X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 14:04:10 -0000 Hello all, I have a doubt in understanding the working of the freebsd OS. In the program given below the function readlink gets called up when printf is executed and the program ends without any output. readlink is a system call (syscall number = 58) which is being made by the printf function, but according to my understanding of system call, it is made by putting the handler number in eax register and then interrupting the processor, so that it can enter the kernel mode and execute the required function, but in this case(dont know why) my readlink function gets called up which should not have happened. I will be very thankful if you can help me with it. #include int readlink(void *a, void *b) { exit(0); } int main(int argc, char **argv) { printf("Hello World"); } From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 8 14:55:18 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6B3F106567D for ; Wed, 8 Apr 2009 14:55:18 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email1.allantgroup.com (email1.emsphone.com [199.67.51.115]) by mx1.freebsd.org (Postfix) with ESMTP id 9AE428FC2C for ; Wed, 8 Apr 2009 14:55:18 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email1.allantgroup.com (8.14.0/8.14.0) with ESMTP id n38EtHsM058316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 8 Apr 2009 09:55:18 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.3/8.14.3) with ESMTP id n38EtHqB040081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 8 Apr 2009 09:55:17 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.3/8.14.3/Submit) id n38EtF0N040078; Wed, 8 Apr 2009 09:55:15 -0500 (CDT) (envelope-from dan) Date: Wed, 8 Apr 2009 09:55:15 -0500 From: Dan Nelson To: Mehul Chadha Message-ID: <20090408145515.GB90152@dan.emsphone.com> References: <251d650c0904080643o8789860w87c8cca070a16489@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <251d650c0904080643o8789860w87c8cca070a16489@mail.gmail.com> X-OS: FreeBSD 7.1-STABLE User-Agent: Mutt/1.5.19 (2009-01-05) X-Virus-Scanned: ClamAV version 0.94.1, clamav-milter version 0.94.1 on email1.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (email1.allantgroup.com [199.67.51.78]); Wed, 08 Apr 2009 09:55:18 -0500 (CDT) X-Scanned-By: MIMEDefang 2.45 Cc: freebsd-hackers@freebsd.org Subject: Re: working of syscall handling X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 14:55:19 -0000 In the last episode (Apr 08), Mehul Chadha said: > In the program given below the function readlink gets called up when > printf is executed and the program ends without any output. > > readlink is a system call (syscall number = 58) which is being made by the > printf function, but according to my understanding of system call, it is > made by putting the handler number in eax register and then interrupting > the processor, so that it can enter the kernel mode and execute the > required function, but in this case(dont know why) my readlink function > gets called up which should not have happened. Readlink is not only a syscall, but a POSIX library function. You are overriding that, and FreeBSD's malloc function uses readlink to read the /etc/malloc.conf settings file. printf calls malloc, so that's why your program exits. http://www.opengroup.org/onlinepubs/9699919799/functions/readlink.html > I will be very thankful if you can help me with it. > > #include > > int readlink(void *a, void *b) > { > exit(0); > } > > int main(int argc, char **argv) > { > printf("Hello World"); > } -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 8 15:02:30 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C85681065670 for ; Wed, 8 Apr 2009 15:02:30 +0000 (UTC) (envelope-from joseph.koshy@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by mx1.freebsd.org (Postfix) with ESMTP id 9B3088FC24 for ; Wed, 8 Apr 2009 15:02:30 +0000 (UTC) (envelope-from joseph.koshy@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so128001wfg.7 for ; Wed, 08 Apr 2009 08:02:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=djZLrE9ZQK4PcgRH++E068yjbZge7WLf2+nq5gaDUEI=; b=TzXOpa6YGlSuislvPagK9VHTENFyP4f/2Ee08JqAzJeE1kM3DTMY8BP2zbKwDDsg9N 2C3MknOb7QsJDLx8qQCxndhBK8wuFRFgieIMoYJ3eH4auuda9aUx5qiKQrJ5kBW7xAct 9m60Mv5Boz3+JKmjKndoJQLf5wDzfEimb9KUc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=GbWCxozkSndfznxGJbB4rjC5zJcpx4ceeJAaZYkhjTMrsFySrSkNOP2FM9DKo7XkYp ku6U/yVxPf0Ghiy9DfD0KsGwiI/WLvicQQiMh/jRwvnTHb7XCKxEgwTB1ymH/wKMBgEw 4461zoLrycHXwHBVoDrP+xrDvlEsIaN33z54Q= MIME-Version: 1.0 Received: by 10.142.158.3 with SMTP id g3mr490377wfe.29.1239201550092; Wed, 08 Apr 2009 07:39:10 -0700 (PDT) In-Reply-To: <251d650c0904080643o8789860w87c8cca070a16489@mail.gmail.com> References: <251d650c0904080643o8789860w87c8cca070a16489@mail.gmail.com> Date: Wed, 8 Apr 2009 20:09:10 +0530 Message-ID: <84dead720904080739q1d98662ch219899990f66767@mail.gmail.com> From: Joseph Koshy To: Mehul Chadha Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: working of syscall handling X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 15:02:33 -0000 > In the program given below the function readlink gets called up when > printf is executed and the program ends without any output. > > readlink is a system call (syscall number = 58) which is being made by > the printf function, but according to my understanding of system call, > it is made by putting the handler number in eax register and then > interrupting the processor, so that it can enter the kernel mode and > execute the required function, but in this case(dont know why) my > readlink function gets called up which should not have happened. > > I will be very thankful if you can help me with it. > > > #include > > int readlink(void *a, void *b) > { > exit(0); > } > > int main(int argc, char **argv) > { > printf("Hello World"); > } Since you have defined 'readlink' to be a global symbol, the run time linker will satisfy references to the symbol 'readlink' from within libc using the definition you provided. % cc a.c % nm a.out | grep readlink 00000000004006d0 T readlink % gdb a.out ... startup messages snipped ... Breakpoint 1, main (argc=1, argv=0x7fffffffe020) at a.c:11 11 printf("Hello World"); (gdb) b readlink Breakpoint 2 at 0x4006e0: file a.c, line 6. (gdb) c Continuing. Breakpoint 2, readlink (a=0x8007082a9, b=0x7fffffffd660) at a.c:6 6 exit(0); (gdb) bt #0 readlink (a=0x8007082a9, b=0x7fffffffd660) at a.c:6 #1 0x000000080069b87c in _UTF8_init () from /lib/libc.so.6 #2 0x0000000800703343 in __smakebuf () from /lib/libc.so.6 #3 0x00000008007031e8 in __swsetup () from /lib/libc.so.6 #4 0x00000008006f872e in __vfprintf () from /lib/libc.so.6 #5 0x00000008006fbeae in vfprintf () from /lib/libc.so.6 #6 0x00000008006e8eca in printf () from /lib/libc.so.6 #7 0x000000000040070e in main (argc=1, argv=0x7fffffffe020) at a.c:11 (gdb) Regards, Koshy From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 9 01:30:01 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67A76106566B for ; Thu, 9 Apr 2009 01:30:01 +0000 (UTC) (envelope-from chuckr@telenix.org) Received: from mail7.sea5.speakeasy.net (mail7.sea5.speakeasy.net [69.17.117.9]) by mx1.freebsd.org (Postfix) with ESMTP id 43CCF8FC14 for ; Thu, 9 Apr 2009 01:30:01 +0000 (UTC) (envelope-from chuckr@telenix.org) Received: (qmail 11640 invoked from network); 9 Apr 2009 01:30:00 -0000 Received: from april.chuckr.org (HELO april.telenix.org) (chuckr@[66.92.151.30]) (envelope-sender ) by mail7.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 9 Apr 2009 01:30:00 -0000 Message-ID: <49DD4FA6.7090805@telenix.org> Date: Wed, 08 Apr 2009 21:30:14 -0400 From: Chuck Robey User-Agent: Thunderbird 2.0.0.19 (X11/20090121) MIME-Version: 1.0 To: FreeBSD-Hackers X-Enigmail-Version: 0.95.5 OpenPGP: id=F3DCA0E9; url=http://pgp.mit.edu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: building a gcc crosscompiler X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 01:30:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Since the last time I built a gcc crosscompiler, the gcc folks have added in dependencies on mpfr and gmp libraries. When I first read this, I was worried that I had a chicken/egg problem, but I found that you can do with the host's version of those libraries. I found a port of gnu libmpfr, but I notice here that FreeBSD has it's own libmp, and I don't know if the 4.3.1 version of gnu gcc can use our libmp, or if I need to install the port "libgmp4" and tell the gnu gcc configure about which mp I'm using. So, if you know if I can use FreeBSD's libmp, or if I need to build the ports libgmp4, please let me know. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkndT6YACgkQz62J6PPcoOmsiQCff6qjZ46dxn8P+5c19gAP2dip 3YsAnj2/sy3nhZzk1TWz1Rfv7PQ2Uw5f =5iqj -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 9 08:38:45 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA90C106566C for ; Thu, 9 Apr 2009 08:38:45 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (brucec-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:c09::2]) by mx1.freebsd.org (Postfix) with ESMTP id A85C28FC18 for ; Thu, 9 Apr 2009 08:38:45 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id 378CE19017; Thu, 9 Apr 2009 09:38:48 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muon X-Spam-Level: X-Spam-Status: No, score=-2.6 required=8.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 Received: from gluon.draftnet (unknown [IPv6:2a01:348:10f:0:240:f4ff:fe57:9871]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Thu, 9 Apr 2009 09:38:48 +0000 (GMT) Date: Thu, 9 Apr 2009 09:38:37 +0100 From: Bruce Cran To: Chuck Robey Message-ID: <20090409093837.5f6e8628@gluon.draftnet> In-Reply-To: <49DD4FA6.7090805@telenix.org> References: <49DD4FA6.7090805@telenix.org> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD-Hackers Subject: Re: building a gcc crosscompiler X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 08:38:46 -0000 On Wed, 08 Apr 2009 21:30:14 -0400 Chuck Robey wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Since the last time I built a gcc crosscompiler, the gcc folks have > added in dependencies on mpfr and gmp libraries. When I first read > this, I was worried that I had a chicken/egg problem, but I found > that you can do with the host's version of those libraries. I found > a port of gnu libmpfr, but I notice here that FreeBSD has it's own > libmp, and I don't know if the 4.3.1 version of gnu gcc can use our > libmp, or if I need to install the port "libgmp4" and tell the gnu > gcc configure about which mp I'm using. > > So, if you know if I can use FreeBSD's libmp, or if I need to build > the ports libgmp4, please let me know. I don't know if it's required, but devel/cross-gcc does depend on math/libgmp4 . -- Bruce Cran From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 9 06:34:23 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB9321065749 for ; Thu, 9 Apr 2009 06:34:23 +0000 (UTC) (envelope-from anti_spamsys@yahoo.com) Received: from web37103.mail.mud.yahoo.com (web37103.mail.mud.yahoo.com [209.191.85.105]) by mx1.freebsd.org (Postfix) with SMTP id ACE628FC1B for ; Thu, 9 Apr 2009 06:34:23 +0000 (UTC) (envelope-from anti_spamsys@yahoo.com) Received: (qmail 62859 invoked by uid 60001); 9 Apr 2009 06:34:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1239258863; bh=udb6m+CfTIslMuYd2RxA50xtauCVGxSZ/dMT6L1oSw0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=rk1bDSU5yTzVl3gfRoGRh7Oo3iFgIJNUZmfux6opTnKjHTDzVTl+PECtnBoB3Mf8yHvqli/NIf/ivUmqTChRuBYxwwIZKSmb+2/eb41TD/c9yQjLCHJRAkFvcSQmjbTdp6NWUlAVNPjmyduRebMRXb22wnWGAnupu4X70FD5Wv8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=Gn2+EzRfuTtLBP6UpMx/QcMpKFJZZfofZ99TniIBs9F7552UOY87hMDsaco9nt1mptxsH+lR3CZZNpDxLoquYLR1OVEarWcogA9Lc9u5qwgTLQkw/F4BFb2NvLIf/5ULocqurRzFrp/7X3GAzalteLmPUSHsDiRd5GHnd2TLV18=; Message-ID: <104771.62272.qm@web37103.mail.mud.yahoo.com> X-YMail-OSG: aF8I1qEVM1k6jHox7rlI69Jj5QjaEFC34Wh8.c6DL2YbAEvgMEn8hrWUNdPmW9a7_tpbCZzdvE9h4e1RbOQSezlz5b8Xu4BPiVFZ9auoFm4cXCUkHAbkgur.bhve3rprX8fnHuWM.dIFdk4gOyaRLGXrnJK3LaXFjK0sQatHyBeFsRWPv12.vEZrdd8.YfWIwKZJcNDT9Nck4OexYByh5dBvx.Vz9K9wFsB58pd4J382LUX7bQjApmeKhyM0bMR.xM1.o8YAP6_WtPPjSkNA5mbuVpO9G3f7Jk9Cpec09O_wfxFZSAk.A1vXdgJcYrc8MDEQ8ZRmykzdB4JTcCibhX8. Received: from [76.227.12.174] by web37103.mail.mud.yahoo.com via HTTP; Wed, 08 Apr 2009 23:34:22 PDT X-Mailer: YahooMailClassic/5.2.15 YahooMailWebService/0.7.289.1 Date: Wed, 8 Apr 2009 23:34:22 -0700 (PDT) From: Travis Daygale To: David Naylor MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 09 Apr 2009 11:53:38 +0000 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: compiling root filesystem into kernel (preferably tmpfs root filesystem) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 06:34:24 -0000 David, thank you for the great information! =A0Yes, I would appreciate seei= ng the scripts and hearing about the other method you outline. =A0 Yes, you understand what I want to achieve exactly. I see what you're saying about not needing to put it in the kernel file, th= ough for a variety of reasons, I do prefer a single file in the end. And I did find this after posting (didn't see it on previous searches, thou= gh I invested a lot of time looking before I posted):http://lists.freebsd.o= rg/pipermail/freebsd-hackers/2006-November/018662.html I have built a root image that I put in the kernel as described in the Nov = 2006 post. =A0My UFS root image consists of /sbin/init, where init is a sta= tically compiled C program that just spits out "Hello world" and sleeps, th= is binary runs fine under FBSD. =A0At this point, I have the kernel booting= but it panics because it says it can't find init.... =A0Hmmm... =A0I belie= ve (haven't had time to test) that it is finding root? =A0Not sure though w= hat loader args I might need to be providing? =A0Could it be a /dev issue (= though I'm not needing sh, etc., since my init is not a real init)? =A0Stil= l figuring this out. Trever --- On Sun, 4/5/09, David Naylor wrote: From: David Naylor Subject: Re: compiling root filesystem into kernel (preferably tmpfs root f= ilesystem) To: "Travis Daygale" Cc: freebsd-hackers@freebsd.org Date: Sunday, April 5, 2009, 1:14 PM On Saturday 04 April 2009 21:52:14 Travis Daygale wrote: > In both the loader and kernel compiling doc, I see snippets of informatio= n > like this: #Make space in the kernel for a root filesystem on a md > device.options MD_ROOT_SIZE=3D10 boot_dfltrootInstructs the kernel to mou= nt > the statically compiled-in root file system. Yes, you can compile a fs image into the kernel.=A0 This however will be st= atic=20 and if you want editing then will need to use unionfs with mdmfs.=A0 tmpfs= =20 cannot be used for this as it does not yet (to my knowledge) support unionf= s.=A0=20 > My question is, how does one compile a root filesystem into the FreeBSD > kernel? =A0 Personally I wouldn't recommend taking the approach you want to do.=A0 Ther= e is=20 simply an easier way.=A0 Just load the fs image as a kernel module (sort of= ).=A0=20 You get the same effect with more flexibility.=A0 (I'll explain below). > When mounted, I want this root filesystem to run entirely in=20 > memory with no other backing store (not even a readonly flash disc nor > other backing media such as DVD/CD).=20 This is do-able.=A0 I've created a CD that ejects it self when loaded=20 completely.=A0 (I thought it was cool :-)) > The standard FreeBSD DVD install disc=20 > uses just such a root? =A0(Though seems to rely heavily on the rescue > binaries being on a read only filesystem backed by the install DVD?)=20 Can't comment, haven't used the FreeBSD CD/DVD's for years (since 6.0) > I'm=20 > still trying to reverse engineer how that was done, without much luck. Is > there a place/documentation I should be finding? =A0PicoBSD, NanoBSD, NFS > root diskless systems... all tantalizing close, but not the same thing > (read only roots backed by media other than memory). The root filesystem > I'm wanting would presumably be in some conceptual sense similar to > initramfs in Linux land, if that helps explain what I'm trying to achieve= .=A0=20 I'll give you a quick tutorial below (if you need further help please let m= e=20 know). > =A0In fact I have a Linux distribution which consists of a single giant > kernel image and when boot, runs entirely in memory, the kernel in fact > can't read filesystems other than tmpfs because no filesystems are compil= ed > in. =A0 I think you are getting some concepts confused here.=A0=20 > It appears all of this won't be possible in FreeBSD (looks like ufs is=20 > required) but it appears I can get close to this. Indeed, I'd love a way > for the root filesystem in FreeBSD to be of type tmpfs, again similar to > what is possible on the Linux side, though I'm much less concerned with t= he > type of filesystem (it just needs to be compiled into the FreeBSD kernel > and needs to be a memory backed filesystem when it mounts, no other backi= ng > store). Thanks in advance! Ok, onto my explanation: my understanding is that you want to have some typ= e=20 of FreeBSD based system that is loaded completely into RAM.=A0 Once loaded = (at=20 boot time) this system should have no reliance on any medium (other than=20 RAM).=A0 This system, once loaded, should behave the same as if it were bac= ked=20 by a hard drive (except the statefullness after reboots).=A0 i.e. the=20 filesystem should be editable.=A0=20 This is of course very possible.=A0=20 STAGE 1: The filesystem In order to have the system in memory one needs a delivery method.=A0 As=20 mentioned before this is achieved using a MD device.=A0=20 MD's can have three types of backing, a vnode (aka file, on a CD/DVD or har= d=20 drive), or memory (purely in memory, AFAIK no swapping out) and swap (same = as=20 memory except my get swapped out).=A0 Ignoring the subtle difference betwee= n=20 memory and swap, swap is better.=A0 Technically the forth is preload but th= is=20 is the same as memory but done by the loader.=A0 See md(4) for further deta= ils.=A0=20 Now, MD just imitates a hard drive, one still needs the data to put there.= =A0=20 Any filesystem will suite this purpose.=A0 My preference is UFS but ISO9660= =20 works just as easily (other options are not so easy but still do-able).=A0= =20 Now, to create the filesystem, just install your system into a folder.=A0 e= .g. # su - # mkdir /tmp/world # cd src; make world kernel distribution DESTDIR=3D/tmp/world # cp /path/to/packages /tmp/world/tmp # chroot /tmp/world sh -c 'cd=A0 /tmp ; pkg_add *' # rm -rf /tmp/world/tmp/* # cat > /tmp/world/etc/fstab < _EOF proc=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /proc=A0 =A0 =A0 =A0 =A0=A0=A0p= rocfs=A0 rw=A0 =A0 =A0 =A0 =A0 =A0 =A0 0=A0 =A0 =A0=A0=A00 tmpfs=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0=A0/tmp=A0 =A0 =A0 =A0 =A0 =A0 t= mpfs=A0=A0=A0rw=A0 =A0 =A0 =A0 =A0 =A0 =A0 0=A0 =A0 =A0=A0=A00 _EOF * Now, edit /tmp/world as you require to make it work as you want (the easi= est=20 way is to create a Flash stick [as per my script], edit the system live and= =20 then copy all changes across).=A0 * STAGE 2: The filesystem image *** For UFS *** # makefs /tmp/world.ufs /tmp/world # MDDEV=3D$(mdconfig -a -t vnode /tmp/world.ufs) # tunefs -L ROOTFS /dev/$MDDEV # mdconfig -d -u $MDDEV *** For CD9660 *** # mkisofs -quiet -sysid=20 FREEBSD -rock -untranslated-filenames -max-iso9660-filenames -iso-level=20 4 -volid DragonBSD -o $WORKDIR/DragonBSD.iso -volid=20 DragonBSD -o /tmp/world.iso /tmp/world Now, since these images are often much larger then required I prefer to=20 compress them.=A0 This allows more programs to be added to the image and it= =20 takes up less memory during runtime (not to mention faster load times).=A0= =20 [I assume UFS option, do the appropriate for CD9660 option] # mkuzip -s 8192 -o /tmp/world.uzip /tmp/world.ufs STAGE 3: Loading the filesystem image Now you have an image that can be loaded on boot, to do so add the followin= g=20 to loader.conf # cd /path/to/boot/system/image # cat >> boot/loader.conf < _EOF rootfs_load=3D"YES" rootfs_type=3D"mfs_root" rootfs_name=3D"/boot/world.uzip" _EOF # cp /tmp/world.uzip boot/ Now, to inform the system that you want it to boot off the memory system # cat >> boot/loader.conf < _EOF vfs.root.mountfrom=3D"ufs:/dev/ufs/ROOTFS" _EOF STAGE 4: Making the Live System editable Now, to make the whole system editable (everything) is quite the challenge = and=20 requires a change in the way the previous stages are done.=A0 The concept i= s=20 simple though.=A0 First: Because the filesystem was compressed (using mkuzip), it cannot be written = to.=A0=20 If the system were not compressed and extra space was allocated to the UFS= =20 image then it can be editable.=A0 Even the extra size at load time can be= =20 compensated for (since loader supports compressed modules [both gzip and=20 bzip2] however you will be running the full image uncompressed in memory.= =A0 It=20 is faster but much more expensive.=A0 Just to give you an idea, I have gott= en a=20 700MB system to boot and run off a mini CD (210MB) and a system with 512MB = of=20 RAM, using the compressed approach with everything editable :-).=A0=20 To do this approach requires some changes to stage 2.=A0 Basically, after= =20 completing the approach for UFS image do the following # EXTRA_SIZE=3D32 # SIZE=3D$(($(du -m /tmp/world.ufs) + EXTRA_SIZE)) # dd if=3D/dev/zero of=3D/tmp/world.ufs count=3D$SIZE bs=3D1m=A0 # NB, use = zero to allow=20 for compression # MDDEV=3D$(mdconfig -a -t vnode /tmp/world.ufs) # newfs -L ROOTFS -o space /dev/$MDDEV # mkdir /tmp/btstrp # mount /dev/$MDDEV /tmp/btstrp # (cd /tmp/world; tar -cf - .) | (cd /tmp/btstrp; tar -xf -) # umount /tmp/btstrp # mdconfig -d -u $MDDEV Next, DO NOT compress the image with mkuzip, instead do: # gzip -9 /tmp/world.ufs This requires either geom_uzip loaded or compiled into the kernel. and, instead of the first part of stage 3 do # cd /path/to/boot/system/image # cat >> boot/loader.conf < _EOF rootfs_load=3D"YES" rootfs_type=3D"mfs_root" rootfs_name=3D"/boot/world.ufs" _EOF # cp /tmp/world.ufs.gz boot/ NOTE: this approach cannot be done using cd9660. The second approach, the one I prefer requires a double boot image (one ins= ide=20 the other), where the one acts as a boot strap, mdconfig and mount's the=20 embedded second image, creates a editable fs using mdmfs and unionfs it ove= r=20 the second image.=A0=20 This is done through using # cat >> boot/loader.conf < _EOF init_script=3D"/chroot.sh" init_chroot=3D"/base" where /chroot.sh basically does: mount -o ro /dev/$(mdconfig -a -t vnode -o readonly -f /world.uzip).uzip /b= ase mdmfs -s 32m md /tmp mount -t unionfs -o noatime -o copymode=3Dtransparent /tmp/base It would be very nice to add unionfs support to tmpfs but not yet :-(.=A0 T= he=20 second approach I have not described fully, it is quite a bit more involved= =20 than the first but has great benefits, memory wise.=A0 If you want more det= ails=20 about this approach please let me know.=A0=20 I've created a set of scripts that are designed to create LiveCD/DVD/Flash = of=20 FreeBSD.=A0 There are three cd9660 images that it produces: 1) CD backed live system (using compressed ufs image) 2) Memory backed live system (using compressed ufs image) 3) CD backed live system (no compression). And one Flash memory based image: 1) Flash based memory (using compressed ufs image and perpetual state overl= ay)=20 [similar to option 1 above except the changes are permanent).=A0=20 If you would like access to these scripts please let me know and I will gla= dly=20 forward them to you.=A0 Also if you have any questions or want further=20 clarification please ask.=A0=20 Regards, David Disclaimer: The commands may be incorrect but the procedure has been tried = and=20 tested.=A0=20 =0A=0A=0A From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 9 13:24:36 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A142106566B; Thu, 9 Apr 2009 13:24:36 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 077788FC08; Thu, 9 Apr 2009 13:24:34 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA27610; Thu, 09 Apr 2009 16:24:33 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <49DDF710.4050004@icyb.net.ua> Date: Thu, 09 Apr 2009 16:24:32 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Alexander Motin Subject: smart self-test vs 7200.12/ich9r/ahci X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 13:24:36 -0000 I wonder if anybody has an issue like I do: http://thread.gmane.org/gmane.linux.utilities.smartmontools/6354 Does anybody has guesses/clues about what might be happening? -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 9 20:13:31 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9DD1106566B for ; Thu, 9 Apr 2009 20:13:31 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (agora.rdrop.com [199.26.172.34]) by mx1.freebsd.org (Postfix) with ESMTP id B0DFE8FC08 for ; Thu, 9 Apr 2009 20:13:31 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id n39KDVc0076600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 9 Apr 2009 13:13:31 -0700 (PDT) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id n39KDVri076599; Thu, 9 Apr 2009 13:13:31 -0700 (PDT) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA00925; Thu, 9 Apr 09 12:57:01 PDT Date: Thu, 09 Apr 2009 12:55:08 -0700 From: perryh@pluto.rain.com To: anti_spamsys@yahoo.com Message-Id: <49de529c.UkvqMSxncVbt/6KA%perryh@pluto.rain.com> References: <104771.62272.qm@web37103.mail.mud.yahoo.com> In-Reply-To: <104771.62272.qm@web37103.mail.mud.yahoo.com> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: compiling root filesystem into kernel (preferably tmpfs root filesystem) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 20:13:32 -0000 Travis Daygale wrote: > I have built a root image that I put in the kernel as described in > the Nov 2006 post. ?My UFS root image consists of /sbin/init, > where init is a statically compiled C program that just spits out > "Hello world" and sleeps, this binary runs fine under FBSD. ?At > this point, I have the kernel booting but it panics because it > says it can't find init.... ?Hmmm... ?I believe (haven't had time > to test) that it is finding root? Yes, if it gets to the point of "can't find init" it has already successfully mounted the root filesystem (although, perhaps, not the *intended* root filesystem). From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 9 20:52:45 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39D8C106566C for ; Thu, 9 Apr 2009 20:52:45 +0000 (UTC) (envelope-from anti_spamsys@yahoo.com) Received: from web37103.mail.mud.yahoo.com (web37103.mail.mud.yahoo.com [209.191.85.105]) by mx1.freebsd.org (Postfix) with SMTP id E87578FC0A for ; Thu, 9 Apr 2009 20:52:44 +0000 (UTC) (envelope-from anti_spamsys@yahoo.com) Received: (qmail 75332 invoked by uid 60001); 9 Apr 2009 20:52:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1239310364; bh=d45v42AUSXmubJ+DVzxD9vfVl6kklsKlISMl0p1ZXkU=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=3jok85kbWO87FIUi/igIovap0BgdW9NBY4ImnLa2VfjWiHdw5r9HeO8HuLFQPhaelUl7OGmlCY2RmRSgmAmBP/pANpdGoF7PiG5zM8kwKYirXQeRT+On/SQFoloV+kqD69m8EbbOKI5C4TELAjRzdkAKxSm8CHEGIRFrKrN0ldc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=eSw5f1wHrggz1IjhV/JnZJ0G/Na55bbdnn9ub3AxJb4B9zekKZd2G4oIxO8CdXTnvo5EGNLt0a7f0sxBmMPBSMiTSlqkfIzHAriG7H/MeemcJenRkl3bIlXah0tlZlhqOrLjbT+oZ2IdvIyTnKwrQG6kSn/WyrG0YFvBdI01ock=; Message-ID: <449148.74528.qm@web37103.mail.mud.yahoo.com> X-YMail-OSG: 2xg6U_oVM1lqMj3WRBkEGbo5yrvlBiO7tPuzmBtKoFHy0UlqGgm95op7q3QUFCqbUKoUq8eiH7qFNV_CKsX9L8A_BjcNwEvRzaPGN2ljkhqFQ5cTqjGyic7HZfG7PUU0PNZ2itEhA1iYe5i3zCucbs9GkDpXD1JGyF_cgaU07f2mbaPHKZtFR2IqYJ_EDECYgFoQMSB9nKhupkls7cePOMOw71kA5h3dwOOVgmw4E.wofH5iAoRhKw7g6Yz79cRAVbjbSt4MCveUBdJufvEoIQNmAL4YxRSD68Nt5uf28NlFC7WZ8.EVNvmxut8X5yY6Tp0Q8con92YfGislXf_F Received: from [76.227.12.174] by web37103.mail.mud.yahoo.com via HTTP; Thu, 09 Apr 2009 13:52:44 PDT X-Mailer: YahooMailClassic/5.2.15 YahooMailWebService/0.7.289.1 Date: Thu, 9 Apr 2009 13:52:44 -0700 (PDT) From: Travis Daygale To: perryh@pluto.rain.com MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 09 Apr 2009 20:57:51 +0000 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org Subject: Re: compiling root filesystem into kernel (preferably tmpfs root filesystem) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 20:52:45 -0000 I wonder if there is a sequence of loader commands and/or configuration (both at kernel compile and at boot) that can assure the kernel mounts the root filesystem installed into itself? Trever --- On Thu, 4/9/09, perryh@pluto.rain.com wrote: From: perryh@pluto.rain.com Subject: Re: compiling root filesystem into kernel (preferably tmpfs root filesystem) To: anti_spamsys@yahoo.com Cc: freebsd-hackers@freebsd.org Date: Thursday, April 9, 2009, 12:55 PM Travis Daygale wrote: > I have built a root image that I put in the kernel as described in > the Nov 2006 post. ?My UFS root image consists of /sbin/init, > where init is a statically compiled C program that just spits out > "Hello world" and sleeps, this binary runs fine under FBSD. ?At > this point, I have the kernel booting but it panics because it > says it can't find init.... ?Hmmm... ?I believe (haven't had time > to test) that it is finding root? Yes, if it gets to the point of "can't find init" it has already successfully mounted the root filesystem (although, perhaps, not the *intended* root filesystem). From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 10 05:42:52 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39F8E1065670; Fri, 10 Apr 2009 05:42:52 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by mx1.freebsd.org (Postfix) with ESMTP id F2E658FC16; Fri, 10 Apr 2009 05:42:50 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: by fxm11 with SMTP id 11so890552fxm.43 for ; Thu, 09 Apr 2009 22:42:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:organization:to:subject :date:user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=UF3DZ3rM/WX3m1N6QUuq92hDSTQz02oVmzhIb1rLulc=; b=pvyUFv0rsf6FBfJegpdwlZxIjaCD1qRZgfAjTX2OLQ/yNMNHPFetUNjt6h17/RSqWx XjbvMTazhWJNeejERlCr66cSFF2RqqZq22DFs+VLhtLemLUl+woQeaIZt80X5OV+mHLi DKKXyoUCfX9M7GPR6UUHytB2foOS9+X9dSiO8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:organization:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; b=c3yfSoKFNQLh871bpLV5FIbXLF7eYp4oqplPjYXo4h4B06zAxwjB9/czN2GJwKWpPl ATnZI+1lLF100l3VF3cXxU06t15VNtfjaGlYxH7kkr84o3S3UOSK9qGjLqMSV9G2nA0W o0lFiGy3QzDk/gR5JvoLYBHQ2fwQMl6wUsqTA= Received: by 10.86.51.10 with SMTP id y10mr509531fgy.51.1239342169924; Thu, 09 Apr 2009 22:42:49 -0700 (PDT) Received: from ?0.0.0.0? ([196.34.241.123]) by mx.google.com with ESMTPS id 3sm1215551fge.19.2009.04.09.22.42.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 09 Apr 2009 22:42:48 -0700 (PDT) From: David Naylor Organization: Private To: Travis Daygale Date: Fri, 10 Apr 2009 07:43:24 +0200 User-Agent: KMail/1.9.10 References: <104771.62272.qm@web37103.mail.mud.yahoo.com> In-Reply-To: <104771.62272.qm@web37103.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1429101.k2Q3nErVYx"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200904100743.28140.naylor.b.david@gmail.com> X-Mailman-Approved-At: Fri, 10 Apr 2009 11:26:22 +0000 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-hackers@freebsd.org, Sam Leffler Subject: Re: compiling root filesystem into kernel (preferably tmpfs root filesystem) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 05:42:52 -0000 --nextPart1429101.k2Q3nErVYx Content-Type: multipart/mixed; boundary="Boundary-01=_8xt3J28kuX58opI" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_8xt3J28kuX58opI Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 09 April 2009 08:34:22 Travis Daygale wrote: > David, thank you for the great information! =A0Yes, I would appreciate se= eing > the scripts and hearing about the other method you outline. =A0 Yes, you > understand what I want to achieve exactly. Please see attached for the scripts. There is now a README file, that=20 *should* explain everything, I hope. If you are running FreeBSD 7 then=20 usbbt.sh needs to be edited (newfs and du have options only supported=20 by -current). =20 > I see what you're saying about not needing to put it in the kernel file, > though for a variety of reasons, I do prefer a single file in the end.=20 Although testing is made much easier by having it as a module (and not havi= ng=20 to rebuild the kernel every time). =20 > And=20 > I did find this after posting (didn't see it on previous searches, though= I > invested a lot of time looking before I > posted):http://lists.freebsd.org/pipermail/freebsd-hackers/2006-November/= 01 >8662.html I have built a root image that I put in the kernel as described = in > the Nov 2006 post. =A0My UFS root image consists of /sbin/init, where ini= t is > a statically compiled C program that just spits out "Hello world" and > sleeps, this binary runs fine under FBSD. =A0At this point, I have the ke= rnel > booting but it panics because it says it can't find init.... =A0Hmmm... = =A0I > believe (haven't had time to test) that it is finding root? =A0 The kernel complains when there is no root (and asks for one). =20 Here is a hint: /> grep init_ /boot/defaults/loader.conf #init_path=3D"/sbin/init:/sbin/oinit:/sbin/init.bak:/rescue/init:/stand/sys= install" #init_shell=3D"/bin/sh" # The shell binary used by init(8). #init_script=3D"" # Initial script to run by init(8) before chrooti= ng. #init_chroot=3D"" # Directory for init(8) to chroot into. If you need further help on this please provide more information (the outpu= t=20 produced by the kernel, for starters). > Not sure=20 > though what loader args I might need to be providing? =A0Could it be a /d= ev > issue (though I'm not needing sh, etc., since my init is not a real init)? > =A0Still figuring this out. The kernel automatically mounts /dev/ for you (just make sure there is a mo= unt=20 point). =20 Just to point out. There are two other scripts (that I know of) that also= =20 produce live images: freesbie and nanobsd. Neither do RAM based images=20 (again, as far as I know). =20 Sam: I've cc'ed you so you can have a look at my scripts, if you are=20 interested. I'll send you an e-mail once I've read through nanobsd carefull= y. =20 Regards --Boundary-01=_8xt3J28kuX58opI-- --nextPart1429101.k2Q3nErVYx Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEABECAAYFAkne3IAACgkQUaaFgP9pFrLtnwCeOvEM/3Vf/gMrHQElyPtIiWwR S/0AoIjUTRFwB4Km05NyZrlfGbg60/Jd =rI8I -----END PGP SIGNATURE----- --nextPart1429101.k2Q3nErVYx-- From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 10 16:08:01 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 375201065678 for ; Fri, 10 Apr 2009 16:08:01 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 66E238FC18 for ; Fri, 10 Apr 2009 16:08:00 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: by ewy19 with SMTP id 19so1132828ewy.43 for ; Fri, 10 Apr 2009 09:07:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to; bh=OfBOLKtujRyZTYohJ7bswYuDGZU46gm15LKu8YP4FKQ=; b=KT353nj0jZpIpuHT95sfCU5paqKOpEayVSdXxRYoO3OZqa5YZi22z2chFRJPWwA+MF KHSlGi/XF79UuYotPrQB8gZL52P4FwUJYrraoyqiiJdpjqKMSfUp9iWGy9xWt8jWa6J/ 4f/8q3CX3ABYGjnd7du04ShkZ4XRQnCvY+Z40= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; b=HVWGIQMmhgW/cJ0hV8DKzEQDsWzhlLmJxPBjO7p7z1+xphKEsMHCAJpKMZloQ44kSI vPLa0u7dK/NmrKQjIVSywpWR07RvJs8yo9dw+FHhbIObiwDM+WcHyNuWwOw4PHVO+jr1 sa7J2+l6GuziCNOy8oRfQp7j3reNP4KJ+5a1k= Received: by 10.210.20.17 with SMTP id 17mr306193ebt.87.1239378173931; Fri, 10 Apr 2009 08:42:53 -0700 (PDT) Received: from logik.internal.network (81-86-41-187.dsl.pipex.com [81.86.41.187]) by mx.google.com with ESMTPS id 7sm957073ewy.34.2009.04.10.08.42.52 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Apr 2009 08:42:53 -0700 (PDT) Received: by logik.internal.network (Postfix, from userid 11001) id 3E2D35C62; Fri, 10 Apr 2009 15:42:51 +0000 (UTC) Date: Fri, 10 Apr 2009 16:42:51 +0100 From: xorquewasp@googlemail.com To: freebsd-hackers@freebsd.org Message-ID: <20090410154251.GA49384@logik.internal.network> References: <20090410132354.GA20721@logik.internal.network> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090410132354.GA20721@logik.internal.network> Subject: Re: diagnosing freezes (DRI?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 16:08:01 -0000 Hello. Recently bought a new system and am experiencing problems with system freezes. I think the most likely culprit is DRI. The freezes occur apparently at random. I've disabled drm.ko and radeon.ko and the system doesn't appear to have frozen yet. I'm running 7.2-PRERELEASE (STABLE as of yesterday). Machine's dmesg: 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.2-PRERELEASE #0: Fri Apr 10 00:09:48 BST 2009 root@viper.internal.network:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz (2665.04-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x106a4 Stepping = 4 Features=0xbfebfbff Features2=0x98e3bd,,> AMD Features=0x28100800 AMD Features2=0x1 Cores per package: 8 Logical CPUs per core: 2 usable memory = 12862480384 (12266 MB) avail memory = 12424323072 (11848 MB) ACPI APIC Table: <121008 APIC1726> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ioapic0: Changing APIC ID to 8 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: <121008 RSDT1726> on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, bff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci7: on pcib1 pcib2: at device 3.0 on pci0 pci6: on pcib2 vgapci0: port 0xe000-0xe0ff mem 0xd0000000-0xdfffffff,0xfbee0000-0xfbeeffff irq 16 at device 0.0 on pci6 drm0: on vgapci0 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] Initialized radeon 1.29.0 20080528 vgapci1: mem 0xfbef0000-0xfbefffff at device 0.1 on pci6 pcib3: at device 7.0 on pci0 pci5: on pcib3 pci0: at device 16.0 (no driver attached) pci0: at device 16.1 (no driver attached) pci0: at device 20.0 (no driver attached) pci0: at device 20.1 (no driver attached) pci0: at device 20.2 (no driver attached) pci0: at device 20.3 (no driver attached) uhci0: port 0x9080-0x909f 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 0x9400-0x941f 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 0x9480-0x949f irq 19 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 0xfb9f6000-0xfb9f63ff 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 uhub4: on uhub3 uhub4: single transaction translator uhub4: 4 ports with 4 removable, self powered ukbd0: on uhub4 kbd2 at ukbd0 ums0: on uhub4 ums0: 3 buttons. ums1: on uhub4 ums1: 3 buttons and Z dir. uhub5: on uhub4 uhub5: 3 ports with 2 removable, bus powered ugen0: on uhub5 ukbd1: on uhub5 kbd3 at ukbd1 uhid0: on uhub5 pci0: at device 27.0 (no driver attached) pcib4: irq 17 at device 28.0 on pci0 pci4: on pcib4 atapci0: port 0xdc00-0xdc07,0xd880-0xd883,0xd800-0xd807,0xd480-0xd483,0xd400-0xd40f mem 0xfbdfe000-0xfbdfffff irq 16 at device 0.0 on pci4 atapci0: [ITHREAD] atapci0: AHCI called from vendor specific driver atapci0: AHCI Version 01.00 controller with 2 ports detected ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] pcib5: irq 16 at device 28.1 on pci0 pci3: on pcib5 re0: port 0xc800-0xc8ff mem 0xfbcff000-0xfbcfffff,0xcfff0000-0xcfffffff irq 17 at device 0.0 on pci3 re0: Using 1 MSI messages re0: Chip rev. 0x3c000000 re0: MAC rev. 0x00400000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:e0:4d:b3:5b:bd re0: [FILTER] pcib6: irq 18 at device 28.2 on pci0 pci2: on pcib6 re1: port 0xb800-0xb8ff mem 0xfbbff000-0xfbbfffff,0xcfef0000-0xcfefffff irq 18 at device 0.0 on pci2 re1: Using 1 MSI messages re1: Chip rev. 0x3c000000 re1: MAC rev. 0x00400000 miibus1: on re1 rgephy1: PHY 1 on miibus1 rgephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re1: Ethernet address: 00:e0:4d:b3:5b:be re1: [FILTER] uhci3: port 0x9800-0x981f irq 23 at device 29.0 on pci0 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb4: on uhci3 usb4: USB revision 1.0 uhub6: on usb4 uhub6: 2 ports with 2 removable, self powered uhci4: port 0x9880-0x989f irq 19 at device 29.1 on pci0 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] usb5: on uhci4 usb5: USB revision 1.0 uhub7: on usb5 uhub7: 2 ports with 2 removable, self powered uhci5: port 0x9c00-0x9c1f irq 18 at device 29.2 on pci0 uhci5: [GIANT-LOCKED] uhci5: [ITHREAD] usb6: on uhci5 usb6: USB revision 1.0 uhub8: on usb6 uhub8: 2 ports with 2 removable, self powered ehci1: mem 0xfb9fc000-0xfb9fc3ff 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 uhub9: on usb7 uhub9: 6 ports with 6 removable, self powered pcib7: at device 30.0 on pci0 pci1: on pcib7 fwohci0: mem 0xfbaff800-0xfbafffff,0xfbaf8000-0xfbafbfff irq 19 at device 7.0 on pci1 fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:00:00:00:00:07:7b:3d fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x199c000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:00:00:07:7b:3d fwe0: Ethernet address: 02:00:00:07:7b:3d fwip0: on firewire0 fwip0: Firewire address: 00:00:00:00:00:07:7b:3d @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff90-0xff9f,0xffa0-0xffaf at device 31.2 on pci0 ata0: on atapci1 ata0: [ITHREAD] ata1: on atapci1 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) atapci2: port 0xac00-0xac07,0xa880-0xa883,0xa800-0xa807,0xa480-0xa483,0xa400-0xa40f,0xa080-0xa08f irq 19 at device 31.5 on pci0 atapci2: [ITHREAD] ata5: on atapci2 ata5: [ITHREAD] ata6: on atapci2 ata6: [ITHREAD] acpi_button0: on acpi0 acpi_tz0: on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] cpu0: on acpi0 ACPI Warning (tbutils-0243): Incorrect checksum in table [OEMB] - 6, should be FE [20070320] est0: 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 14 device_attach: est1 attach returned 6 p4tcc1: on cpu1 cpu2: on acpi0 est2: on cpu2 p4tcc2: on cpu2 cpu3: on acpi0 est3: on cpu3 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 14 device_attach: est3 attach returned 6 p4tcc3: on cpu3 cpu4: on acpi0 est4: on cpu4 p4tcc4: on cpu4 cpu5: on acpi0 est5: on cpu5 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 14 device_attach: est5 attach returned 6 p4tcc5: on cpu5 cpu6: on acpi0 est6: on cpu6 p4tcc6: on cpu6 cpu7: on acpi0 est7: on cpu7 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 14 device_attach: est7 attach returned 6 p4tcc7: on cpu7 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ppc0: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> 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 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio0: [FILTER] 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 firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) ad0: 76319MB at ata0-master SATA300 ad2: 953869MB at ata1-master SATA300 GEOM_LABEL: Label for provider ad0s1a is ufsid/49dd1626d599346c. GEOM_LABEL: Label for provider ad0s1d is ufsid/49dd1626c888923e. GEOM_LABEL: Label for provider ad0s1e is ufsid/49dd16280e8a20d0. GEOM_LABEL: Label for provider ad0s1f is ufsid/49dd1626ed87573c. acd0: DVDR at ata4-master UDMA66 SMP: AP CPU #1 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #6 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #5 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #7 Launched! Trying to mount root from ufs:/dev/ad0s1a cryptosoft0: on motherboard GEOM_ELI: Device ad0s1b.eli created. GEOM_ELI: Encryption: AES-CBC 256 GEOM_ELI: Crypto: software GEOM_LABEL: Label ufsid/49dd1626d599346c removed. GEOM_LABEL: Label for provider ad0s1a is ufsid/49dd1626d599346c. GEOM_LABEL: Label ufsid/49dd1626c888923e removed. GEOM_LABEL: Label for provider ad0s1d is ufsid/49dd1626c888923e. GEOM_LABEL: Label ufsid/49dd1626ed87573c removed. GEOM_LABEL: Label for provider ad0s1f is ufsid/49dd1626ed87573c. GEOM_LABEL: Label ufsid/49dd16280e8a20d0 removed. GEOM_LABEL: Label for provider ad0s1e is ufsid/49dd16280e8a20d0. GEOM_LABEL: Label ufsid/49dd1626d599346c removed. GEOM_LABEL: Label ufsid/49dd1626c888923e removed. GEOM_LABEL: Label ufsid/49dd1626ed87573c removed. GEOM_LABEL: Label ufsid/49dd16280e8a20d0 removed. re0: link state changed to UP I've not been able to obtain anything in the way of crash logs. The system just freezes and doesn't respond to keyboard, mouse, network activity, shouting and/or threats. I've run memtest86+ for hours with no errors, tested the CPU with various utilities and run WD's hard disk diagnostic tools. As I said, DRI seems the likely culprit. Unfortunately I can't do without DRI as this machine's intended for OpenGL development and video editing. Any advice would be much appreciated. I'm under slight time pressure to get this system up and running. thanks, xw From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 10 17:43:43 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53DE7106566B for ; Fri, 10 Apr 2009 17:43:43 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 071808FC13 for ; Fri, 10 Apr 2009 17:43:42 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-157-33-136.bna.bellsouth.net [70.157.33.136]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n3AHgOhv073048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Apr 2009 13:42:24 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: xorquewasp@googlemail.com In-Reply-To: <20090410154251.GA49384@logik.internal.network> References: <20090410132354.GA20721@logik.internal.network> <20090410154251.GA49384@logik.internal.network> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-S0GZoc1Opm5UtrSyxjZk" Organization: FreeBSD Date: Fri, 10 Apr 2009 12:42:48 -0500 Message-Id: <1239385368.1922.74.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-hackers@freebsd.org Subject: Re: diagnosing freezes (DRI?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 17:43:43 -0000 --=-S0GZoc1Opm5UtrSyxjZk Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2009-04-10 at 16:42 +0100, xorquewasp@googlemail.com wrote: > Hello. >=20 > Recently bought a new system and am experiencing problems with system fre= ezes. > I think the most likely culprit is DRI. The freezes occur apparently at r= andom. > I've disabled drm.ko and radeon.ko and the system doesn't appear to have = frozen > yet. >=20 > I'm running 7.2-PRERELEASE (STABLE as of yesterday). >=20 > Machine's dmesg: >=20 > 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.2-PRERELEASE #0: Fri Apr 10 00:09:48 BST 2009 > root@viper.internal.network:/usr/obj/usr/src/sys/GENERIC > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz (2665.04-MHz K8-clas= s CPU) > Origin =3D "GenuineIntel" Id =3D 0x106a4 Stepping =3D 4 > Features=3D0xbfebfbff > Features2=3D0x98e3bd,,> > AMD Features=3D0x28100800 > AMD Features2=3D0x1 > Cores per package: 8 > Logical CPUs per core: 2 > usable memory =3D 12862480384 (12266 MB) > avail memory =3D 12424323072 (11848 MB) > ACPI APIC Table: <121008 APIC1726> > FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu2 (AP): APIC ID: 2 > cpu3 (AP): APIC ID: 3 > cpu4 (AP): APIC ID: 4 > cpu5 (AP): APIC ID: 5 > cpu6 (AP): APIC ID: 6 > cpu7 (AP): APIC ID: 7 > ioapic0: Changing APIC ID to 8 > ioapic0 irqs 0-23 on motherboard > kbd1 at kbdmux0 > acpi0: <121008 RSDT1726> on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > acpi0: reservation of 0, a0000 (3) failed > acpi0: reservation of 100000, bff00000 (3) failed > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: at device 1.0 on pci0 > pci7: on pcib1 > pcib2: at device 3.0 on pci0 > pci6: on pcib2 > vgapci0: port 0xe000-0xe0ff mem 0xd0000000-0xdff= fffff,0xfbee0000-0xfbeeffff irq 16 at device 0.0 on pci6 > drm0: on vgapci0 > vgapci0: child drm0 requested pci_enable_busmaster > info: [drm] Initialized radeon 1.29.0 20080528 > vgapci1: mem 0xfbef0000-0xfbefffff at device 0.1= on pci6 > pcib3: at device 7.0 on pci0 > pci5: on pcib3 > pci0: at device 16.0 (no driver a= ttached) > pci0: at device 16.1 (no driver a= ttached) > pci0: at device 20.0 (no driver a= ttached) > pci0: at device 20.1 (no driver a= ttached) > pci0: at device 20.2 (no driver a= ttached) > pci0: at device 20.3 (no driver a= ttached) > uhci0: port 0x9080-0x909f irq 16 at devic= e 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 0x9400-0x941f irq 21 at devic= e 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 0x9480-0x949f irq 19 at devic= e 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 0xfb9f6000-0xfb9f63ff 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 > uhub4: on uhub3 > uhub4: single transaction translator > uhub4: 4 ports with 4 removable, self powered > ukbd0: on uhub4 > kbd2 at ukbd0 > ums0: on uhub4 > ums0: 3 buttons. > ums1: o= n uhub4 > ums1: 3 buttons and Z dir. > uhub5: on uhub4 > uhub5: 3 ports with 2 removable, bus powered > ugen0: on uhub5 > ukbd1: on uhub5 > kbd3 at ukbd1 > uhid0: on uhub5 > pci0: at device 27.0 (no driver attached) > pcib4: irq 17 at device 28.0 on pci0 > pci4: on pcib4 > atapci0: port 0xdc00-0xdc07,0xd880-0x= d883,0xd800-0xd807,0xd480-0xd483,0xd400-0xd40f mem 0xfbdfe000-0xfbdfffff ir= q 16 at device 0.0 on pci4 > atapci0: [ITHREAD] > atapci0: AHCI called from vendor specific driver > atapci0: AHCI Version 01.00 controller with 2 ports detected > ata2: on atapci0 > ata2: [ITHREAD] > ata3: on atapci0 > ata3: [ITHREAD] > ata4: on atapci0 > ata4: [ITHREAD] > pcib5: irq 16 at device 28.1 on pci0 > pci3: on pcib5 > re0: port 0xc800-0xc8ff mem 0xfbcff000-0xfbcfffff,0xcfff0000-0xcfff= ffff irq 17 at device 0.0 on pci3 > re0: Using 1 MSI messages > re0: Chip rev. 0x3c000000 > re0: MAC rev. 0x00400000 > miibus0: on re0 > rgephy0: PHY 1 on miibus0 > rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000= baseT-FDX, auto > re0: Ethernet address: 00:e0:4d:b3:5b:bd > re0: [FILTER] > pcib6: irq 18 at device 28.2 on pci0 > pci2: on pcib6 > re1: port 0xb800-0xb8ff mem 0xfbbff000-0xfbbfffff,0xcfef0000-0xcfef= ffff irq 18 at device 0.0 on pci2 > re1: Using 1 MSI messages > re1: Chip rev. 0x3c000000 > re1: MAC rev. 0x00400000 > miibus1: on re1 > rgephy1: PHY 1 on miibus1 > rgephy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000= baseT-FDX, auto > re1: Ethernet address: 00:e0:4d:b3:5b:be > re1: [FILTER] > uhci3: port 0x9800-0x981f irq 23 at devic= e 29.0 on pci0 > uhci3: [GIANT-LOCKED] > uhci3: [ITHREAD] > usb4: on uhci3 > usb4: USB revision 1.0 > uhub6: on usb4 > uhub6: 2 ports with 2 removable, self powered > uhci4: port 0x9880-0x989f irq 19 at devic= e 29.1 on pci0 > uhci4: [GIANT-LOCKED] > uhci4: [ITHREAD] > usb5: on uhci4 > usb5: USB revision 1.0 > uhub7: on usb5 > uhub7: 2 ports with 2 removable, self powered > uhci5: port 0x9c00-0x9c1f irq 18 at devic= e 29.2 on pci0 > uhci5: [GIANT-LOCKED] > uhci5: [ITHREAD] > usb6: on uhci5 > usb6: USB revision 1.0 > uhub8: on usb6 > uhub8: 2 ports with 2 removable, self powered > ehci1: mem 0xfb9fc000-0xfb9fc3ff 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 > uhub9: on usb7 > uhub9: 6 ports with 6 removable, self powered > pcib7: at device 30.0 on pci0 > pci1: on pcib7 > fwohci0: mem 0xfbaff800-0xfbafffff,0xfbaf= 8000-0xfbafbfff irq 19 at device 7.0 on pci1 > fwohci0: [FILTER] > fwohci0: OHCI version 1.10 (ROM=3D1) > fwohci0: No. of Isochronous channels is 4. > fwohci0: EUI64 00:00:00:00:00:07:7b:3d > fwohci0: Phy 1394a available S400, 2 ports. > fwohci0: Link S400, max_rec 2048 bytes. > firewire0: on fwohci0 > dcons_crom0: on firewire0 > dcons_crom0: bus_addr 0x199c000 > fwe0: on firewire0 > if_fwe0: Fake Ethernet address: 02:00:00:07:7b:3d > fwe0: Ethernet address: 02:00:00:07:7b:3d > fwip0: on firewire0 > fwip0: Firewire address: 00:00:00:00:00:07:7b:3d @ 0xfffe00000000, S400, = maxrec 2048 > sbp0: on firewire0 > fwohci0: Initiate bus reset > fwohci0: BUS reset > fwohci0: node_id=3D0xc800ffc0, gen=3D1, CYCLEMASTER mode > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x= 177,0x376,0xff90-0xff9f,0xffa0-0xffaf at device 31.2 on pci0 > ata0: on atapci1 > ata0: [ITHREAD] > ata1: on atapci1 > ata1: [ITHREAD] > pci0: at device 31.3 (no driver attached) > atapci2: port 0xac00-0xac07,0xa880-0xa88= 3,0xa800-0xa807,0xa480-0xa483,0xa400-0xa40f,0xa080-0xa08f irq 19 at device = 31.5 on pci0 > atapci2: [ITHREAD] > ata5: on atapci2 > ata5: [ITHREAD] > ata6: on atapci2 > ata6: [ITHREAD] > acpi_button0: on acpi0 > acpi_tz0: on acpi0 > fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 = on acpi0 > fdc0: [FILTER] > cpu0: on acpi0 > ACPI Warning (tbutils-0243): Incorrect checksum in table [OEMB] - 6, sh= ould be FE [20070320] > est0: 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 14 > device_attach: est1 attach returned 6 > p4tcc1: on cpu1 > cpu2: on acpi0 > est2: on cpu2 > p4tcc2: on cpu2 > cpu3: on acpi0 > est3: on cpu3 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 14 > device_attach: est3 attach returned 6 > p4tcc3: on cpu3 > cpu4: on acpi0 > est4: on cpu4 > p4tcc4: on cpu4 > cpu5: on acpi0 > est5: on cpu5 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 14 > device_attach: est5 attach returned 6 > p4tcc5: on cpu5 > cpu6: on acpi0 > est6: on cpu6 > p4tcc6: on cpu6 > cpu7: on acpi0 > est7: on cpu7 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 14 > device_attach: est7 attach returned 6 > p4tcc7: on cpu7 > atkbdc0: at port 0x60,0x64 on isa0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > ppc0: cannot reserve I/O port range > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=3D0x300> > 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 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > sio0: type 8250 or not responding > sio0: [FILTER] > 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 > firewire0: 1 nodes, maxhop <=3D 0, cable IRM =3D 0 (me) > firewire0: bus manager 0 (me) > ad0: 76319MB at ata0-master SATA300 > ad2: 953869MB at ata1-master SATA300 > GEOM_LABEL: Label for provider ad0s1a is ufsid/49dd1626d599346c. > GEOM_LABEL: Label for provider ad0s1d is ufsid/49dd1626c888923e. > GEOM_LABEL: Label for provider ad0s1e is ufsid/49dd16280e8a20d0. > GEOM_LABEL: Label for provider ad0s1f is ufsid/49dd1626ed87573c. > acd0: DVDR at ata4-master UDMA66 > SMP: AP CPU #1 Launched! > SMP: AP CPU #4 Launched! > SMP: AP CPU #6 Launched! > SMP: AP CPU #3 Launched! > SMP: AP CPU #5 Launched! > SMP: AP CPU #2 Launched! > SMP: AP CPU #7 Launched! > Trying to mount root from ufs:/dev/ad0s1a > cryptosoft0: on motherboard > GEOM_ELI: Device ad0s1b.eli created. > GEOM_ELI: Encryption: AES-CBC 256 > GEOM_ELI: Crypto: software > GEOM_LABEL: Label ufsid/49dd1626d599346c removed. > GEOM_LABEL: Label for provider ad0s1a is ufsid/49dd1626d599346c. > GEOM_LABEL: Label ufsid/49dd1626c888923e removed. > GEOM_LABEL: Label for provider ad0s1d is ufsid/49dd1626c888923e. > GEOM_LABEL: Label ufsid/49dd1626ed87573c removed. > GEOM_LABEL: Label for provider ad0s1f is ufsid/49dd1626ed87573c. > GEOM_LABEL: Label ufsid/49dd16280e8a20d0 removed. > GEOM_LABEL: Label for provider ad0s1e is ufsid/49dd16280e8a20d0. > GEOM_LABEL: Label ufsid/49dd1626d599346c removed. > GEOM_LABEL: Label ufsid/49dd1626c888923e removed. > GEOM_LABEL: Label ufsid/49dd1626ed87573c removed. > GEOM_LABEL: Label ufsid/49dd16280e8a20d0 removed. > re0: link state changed to UP >=20 > I've not been able to obtain anything in the way of crash logs. The syste= m > just freezes and doesn't respond to keyboard, mouse, network activity, > shouting and/or threats. >=20 > I've run memtest86+ for hours with no errors, tested the CPU with various > utilities and run WD's hard disk diagnostic tools. As I said, DRI seems > the likely culprit. Unfortunately I can't do without DRI as this machine'= s > intended for OpenGL development and video editing. >=20 > Any advice would be much appreciated. I'm under slight time pressure to > get this system up and running. Are you running powerd by chance? I was seeing an issue that seemed to be related to powerd. Since I've disabled it on that box, it hasn't hung up any more. As far as drm is concerned, I've been running on an x1650 for probably a week now while working mostly on port stuff and I haven't seen any issues. This is with full 3d and compiz running, etc... So, if it is drm related... we are going to have to dig up some debugging info somehow... robert. > thanks, > xw > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " --=20 Robert Noland FreeBSD --=-S0GZoc1Opm5UtrSyxjZk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknfhRgACgkQM4TrQ4qfRON1qgCdFFF8fPbFScFCItHWF/WsFTUv 4rcAnAk6gmI/LH1kUvAUHZn55GM1FvRz =D0uN -----END PGP SIGNATURE----- --=-S0GZoc1Opm5UtrSyxjZk-- From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 10 17:58:27 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 648D4106570E for ; Fri, 10 Apr 2009 17:58:26 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 1096D8FC13 for ; Fri, 10 Apr 2009 17:58:25 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: by ewy19 with SMTP id 19so1167635ewy.43 for ; Fri, 10 Apr 2009 10:58:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:cc :subject:message-id:references:mime-version:content-type :content-disposition:in-reply-to; bh=suFhS3Bb7urJCG+t78tSMh14Ehyh8uqpJ1NoXp25dlU=; b=o+aYUj4QDKBQyxdsylStf6sM7Q6W9KHtmPR9HYy/+0ZZb2k8hIV3kmvLA57mk3Oxzb 8bkEASaAw53YrXaLefVLe6Y5mxkZv80vkYcMtkj4Pu+fKyflRSqmilN2rtmmQKUIMoEK mu7aKdipmlAXkX0MJKFMV1WP4omjiLSP8gzQw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; b=uWroYQd3hPPTMOjmXPNStOQ6GLqvv7kT7GeksCRyGXMpECztyFa+HGKEENqdDOOXN5 UJF5FO75Sl59M+7us58lHgKJTn0+7fB54VOa88q8G+ybAU50DL45w0njRROGv+bJkHSU N6+h9x9GUauAeBZZTe3Hhlqc5n+F8ZiX1inrk= Received: by 10.210.71.12 with SMTP id t12mr3189899eba.41.1239386305055; Fri, 10 Apr 2009 10:58:25 -0700 (PDT) Received: from logik.internal.network (81-86-41-187.dsl.pipex.com [81.86.41.187]) by mx.google.com with ESMTPS id 24sm2176776ewy.97.2009.04.10.10.58.24 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Apr 2009 10:58:24 -0700 (PDT) Received: by logik.internal.network (Postfix, from userid 11001) id 758AE5C31; Fri, 10 Apr 2009 17:59:22 +0000 (UTC) Date: Fri, 10 Apr 2009 18:59:22 +0100 From: xorquewasp@googlemail.com To: Robert Noland Message-ID: <20090410175922.GA50520@logik.internal.network> References: <20090410132354.GA20721@logik.internal.network> <20090410154251.GA49384@logik.internal.network> <1239385368.1922.74.camel@balrog.2hip.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1239385368.1922.74.camel@balrog.2hip.net> Cc: freebsd-hackers@freebsd.org Subject: Re: diagnosing freezes (DRI?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 17:58:28 -0000 Hello. On 2009-04-10 12:42:48, Robert Noland wrote: > > Are you running powerd by chance? I was seeing an issue that seemed to > be related to powerd. Since I've disabled it on that box, it hasn't > hung up any more. I'm not running powerd, no. > > As far as drm is concerned, I've been running on an x1650 for probably a > week now while working mostly on port stuff and I haven't seen any > issues. This is with full 3d and compiz running, etc... So, if it is > drm related... we are going to have to dig up some debugging info > somehow... > > robert. > The system doesn't seem to have frozen since DRI/DRM was disabled. I did have one crash/reboot whilst building a large number of packages with tinderbox. I've currently got both tinderbox and a make -j 16 buildworld going on a loop in the hope that I can trigger it again. Being the idiot I am, I had encrypted swap enabled and so savecore didn't save anything. Won't make that mistake twice. I'm currently using a world compiled WITH_DEBUG but is there anything else I can do? thanks, xw From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 10 18:32:28 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2B19106564A for ; Fri, 10 Apr 2009 18:32:28 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 680828FC1B for ; Fri, 10 Apr 2009 18:32:28 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-1-210-55.bna.bellsouth.net [65.1.210.55]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n3AIV9WU073534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Apr 2009 14:31:09 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: xorquewasp@googlemail.com In-Reply-To: <20090410175922.GA50520@logik.internal.network> References: <20090410132354.GA20721@logik.internal.network> <20090410154251.GA49384@logik.internal.network> <1239385368.1922.74.camel@balrog.2hip.net> <20090410175922.GA50520@logik.internal.network> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-ABgEv5/yoxMYHp9F+ppQ" Organization: FreeBSD Date: Fri, 10 Apr 2009 13:31:33 -0500 Message-Id: <1239388293.1922.80.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RCVD_IN_SORBS_DUL,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-hackers@freebsd.org Subject: Re: diagnosing freezes (DRI?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 18:32:28 -0000 --=-ABgEv5/yoxMYHp9F+ppQ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2009-04-10 at 18:59 +0100, xorquewasp@googlemail.com wrote: > Hello. >=20 > On 2009-04-10 12:42:48, Robert Noland wrote: > >=20 > > Are you running powerd by chance? I was seeing an issue that seemed to > > be related to powerd. Since I've disabled it on that box, it hasn't > > hung up any more. >=20 > I'm not running powerd, no. >=20 > >=20 > > As far as drm is concerned, I've been running on an x1650 for probably = a > > week now while working mostly on port stuff and I haven't seen any > > issues. This is with full 3d and compiz running, etc... So, if it is > > drm related... we are going to have to dig up some debugging info > > somehow... > >=20 > > robert. > >=20 >=20 > The system doesn't seem to have frozen since DRI/DRM was disabled. >=20 > I did have one crash/reboot whilst building a large number of packages > with tinderbox. I've currently got both tinderbox and a make -j 16 > buildworld going on a loop in the hope that I can trigger it again. >=20 > Being the idiot I am, I had encrypted swap enabled and so savecore > didn't save anything. Won't make that mistake twice. >=20 > I'm currently using a world compiled WITH_DEBUG but is there anything > else I can do? If it is locking the whole system, then a core is really our best shot. If you can extract anything useful from xorg.log or setting hw.dri.0.debug that also might be of use. I'm running on 2 cores, but it is possible that some locking issue exists. All of the driver specific ioctls are run under a lock though. robert. > thanks, > xw > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " --=20 Robert Noland FreeBSD --=-ABgEv5/yoxMYHp9F+ppQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAknfkIUACgkQM4TrQ4qfROM1BgCdGTQClBQdo+yaZbueBjQmh+aD ykEAn11Fy70MGp04+K5UyMUnJEYUTsju =hK7c -----END PGP SIGNATURE----- --=-ABgEv5/yoxMYHp9F+ppQ-- From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 10 21:13:10 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBF08106566B; Fri, 10 Apr 2009 21:13:10 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 3CCCB8FC13; Fri, 10 Apr 2009 21:13:09 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: by ewy19 with SMTP id 19so1225022ewy.43 for ; Fri, 10 Apr 2009 14:13:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:cc :subject:message-id:references:mime-version:content-type :content-disposition:in-reply-to; bh=uxpuQplqj24xZODUv46uO1bMGz8xTtOF4XpGX8t0PLk=; b=bfJYC9UCFcDLyQZM1Ls39q94YKjYc9PH5OP3i8MofXLMwU6Jgi+dRbnyDLrXwxnsBr N2JLBV39Xb9PWT4Ij4HfWUWt7JPhA213p6OZwULC6/jW+MzSziXzR/4NcS6GqlZICnFE cFWjO7uq1Fb1U81GnFsNPbP0eUhz4MWA/n2ig= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; b=wKYa7qQoM11dmN3g6ur+pjhxf2svAAYLwnjLMtYtdM9VVUlbkhm2oqoYcyVmxGD4V6 j5nAaKgmh0Sa2mtUCkSFJt7XJAvQ0qo+/RVwO7Vqj47s/FJiK3O3/I7mLUDhF89HRs3B mh4sZEoUORxkEe9uHgFLaG3XmtI8FVx99o3lc= Received: by 10.210.87.19 with SMTP id k19mr531874ebb.39.1239397989172; Fri, 10 Apr 2009 14:13:09 -0700 (PDT) Received: from logik.internal.network (81-86-41-187.dsl.pipex.com [81.86.41.187]) by mx.google.com with ESMTPS id 19sm2332373ewy.22.2009.04.10.14.13.08 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Apr 2009 14:13:08 -0700 (PDT) Received: by logik.internal.network (Postfix, from userid 11001) id D36225C31; Fri, 10 Apr 2009 21:13:07 +0000 (UTC) Date: Fri, 10 Apr 2009 22:13:07 +0100 From: xorquewasp@googlemail.com To: Robert Noland Message-ID: <20090410211307.GA83697@logik.internal.network> References: <20090410132354.GA20721@logik.internal.network> <20090410154251.GA49384@logik.internal.network> <1239385368.1922.74.camel@balrog.2hip.net> <20090410175922.GA50520@logik.internal.network> <1239388293.1922.80.camel@balrog.2hip.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1239388293.1922.80.camel@balrog.2hip.net> Cc: freebsd-hackers@freebsd.org Subject: Re: diagnosing freezes (DRI?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 21:13:11 -0000 On 2009-04-10 13:31:33, Robert Noland wrote: > > If it is locking the whole system, then a core is really our best shot. > If you can extract anything useful from xorg.log or setting > hw.dri.0.debug that also might be of use. > > I'm running on 2 cores, but it is possible that some locking issue > exists. All of the driver specific ioctls are run under a lock though. > > robert. Ok. I've re-enabled drm.ko and radeon.ko and am running X. I'll leave the system under load and let you know when it inevitably locks up... cheers, xw From owner-freebsd-hackers@FreeBSD.ORG Fri Apr 10 23:37:47 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76D1C1065670 for ; Fri, 10 Apr 2009 23:37:47 +0000 (UTC) (envelope-from brampton@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id D9B488FC19 for ; Fri, 10 Apr 2009 23:37:46 +0000 (UTC) (envelope-from brampton@gmail.com) Received: by ewy19 with SMTP id 19so1254002ewy.43 for ; Fri, 10 Apr 2009 16:37:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=4CuX10XSoox3AOVNrcA3mjoHkfn2qG5wzcpGEeSqA4M=; b=oydtt28nZ3Vcay5RPRqJKCUnYIut+nnXXgCUHp8sUduqGS4YfNMIU3RUgoxFDS66b/ RtOwG+BzX6vwLESKYQkuzDglap2Gf0evnku4r/pDDabKXJ1TM1/Rav8OO9jsBkjNpI9c 6tqcZ2kTouCIOzOTBEADBKyRl7ORcDNVyTXhg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; b=J68cys4JSVVU83PRwmfYC3O/A9Omo4tSh6iyEq7RMYN1l1F0eK5TIRnyHjgwEFoPiq vEqnNCPYRnKchFH6T8df2h/tGo58XMu7ItuT6hnYLC1fBG21JV4vi0drt/J1OTXZsRqY v45u2TTS1DOBRTNdWJFUpgktdiZfEmylhS6ZI= MIME-Version: 1.0 Sender: brampton@gmail.com Received: by 10.210.42.13 with SMTP id p13mr1613136ebp.53.1239405385849; Fri, 10 Apr 2009 16:16:25 -0700 (PDT) Date: Sat, 11 Apr 2009 00:16:25 +0100 X-Google-Sender-Auth: b5a3b9511c10de23 Message-ID: From: Andrew Brampton To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: FreeBSD memguard + spinlocks X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 23:37:47 -0000 Hi, I'm having a problem with memguard(9) on FreeBSD 7.1 but before I ask about that I just need to check my facts about malloc. When in interrupt context malloc must be called with M_NOWAIT, this is because I can't sleep inside a interrupt. Now when I hold a spinlock (MTX_SPIN) I am also not allowed to sleep or obtain a sleepable mutex (such as MTX_DEF). So I assume while holding a spin lock any mallocs I do must have the M_NOWAIT flag? This was not clear from the manual pages, but at least makes sense to me. So my problem with memguard stems from the fact that I am locking a spinlock, and then I'm calling malloc with M_NOWAIT. But inside memguard_alloc a MTX_DEF is acquired causing WITNESS to panic. So I think fundamental memguard is flawed and should be using MTX_SPIN instead of MTX_DEF otherwise it can't be called from inside a interrupt or when a spin lock is held. But maybe I'm missing something? Also on a related note, I see that MTX_SPIN disables interrupts, making it a rather "heavy" spinlock. Is there a lighter spin lock that literally just spins? I read that MTX_DEF are far quicker to acquire , but surely a light spinlock would be easier to acquire than sleeping? I think for the moment I will fix my code by not using a MTX_SPIN (since the code is not in a interrupt), however, I think memguard should change its lock. thanks Andrew From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 11 00:30:41 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1C251065688; Sat, 11 Apr 2009 00:30:41 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 1A7388FC17; Sat, 11 Apr 2009 00:30:40 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by ewy19 with SMTP id 19so1262260ewy.43 for ; Fri, 10 Apr 2009 17:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=KJGdqGIT2OglIMBpDGFlQtDMIFCmJEhGK5go5AkFLPU=; b=X7BRq4ta24I86rb+Ta7TOlcZvDO7Uq5qFeJDMzl8rVb7ICfA+I2RuTIrZnxV4RFPQa TdUGTgFdTKkyzWhLMgsNy0FhE6CQxCN9txE6gvXUk/PWq2Fa34ZpLgm2pTaHltwYIiaO uMBVfgg6ez7XRdbFwsJwLthIuv4nURE2SypQE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=BGm+Id/5WNSL0DGuOwMV0iQX+31obL8RVeIshaqFcaiplgZqsNDNceJIWWu/PxRj0g 1uQIwD1Oq175UYfJNle5QuiO9f6JkI9bQLWvZlv+RrzU4oYjL1f/LDLC5LnrQv2fRVeo e/cv8z9ruXpGxdHgyGWS5AncKIF90t+aMkwNE= MIME-Version: 1.0 Received: by 10.211.137.19 with SMTP id p19mr788527ebn.67.1239409840151; Fri, 10 Apr 2009 17:30:40 -0700 (PDT) In-Reply-To: <20090410211307.GA83697@logik.internal.network> References: <20090410132354.GA20721@logik.internal.network> <20090410154251.GA49384@logik.internal.network> <1239385368.1922.74.camel@balrog.2hip.net> <20090410175922.GA50520@logik.internal.network> <1239388293.1922.80.camel@balrog.2hip.net> <20090410211307.GA83697@logik.internal.network> Date: Sat, 11 Apr 2009 02:30:40 +0200 Message-ID: <3a142e750904101730k53b7fbabn6e801ac36f1182e0@mail.gmail.com> From: "Paul B. Mahol" To: xorquewasp@googlemail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, Robert Noland Subject: Re: diagnosing freezes (DRI?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 00:30:42 -0000 On 4/10/09, xorquewasp@googlemail.com wrote: > On 2009-04-10 13:31:33, Robert Noland wrote: >> >> If it is locking the whole system, then a core is really our best shot. >> If you can extract anything useful from xorg.log or setting >> hw.dri.0.debug that also might be of use. >> >> I'm running on 2 cores, but it is possible that some locking issue >> exists. All of the driver specific ioctls are run under a lock though. >> >> robert. > > Ok. I've re-enabled drm.ko and radeon.ko and am running X. I'll leave > the system under load and let you know when it inevitably locks up... > > cheers, If it locks under X11 then use debug.debugger_on_panic=0 sysctl. Not doing this will increase drasticaly chances of locking whole system and not providing any debug data. -- Paul From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 11 10:30:36 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2C14106566B for ; Sat, 11 Apr 2009 10:30:36 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 5A4B18FC27 for ; Sat, 11 Apr 2009 10:30:36 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: by ewy19 with SMTP id 19so1358532ewy.43 for ; Sat, 11 Apr 2009 03:30:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:cc :subject:message-id:references:mime-version:content-type :content-disposition:in-reply-to; bh=D8rbfBk/0BJgFL5IwSiQ9+oQ8d8JWdbcqDaBmR7N5XY=; b=s+w8xMngMt2bHSdogMlw7FjC2TvWOgA4xuKt3biypZ9XnVuO1C8arHq1Lo5qMhvec6 lcfhduxH2XrRK6Yk0l1fhoRRo5uYAZKEgIYGGLoVEwqYYt6XJ7OP00g0UZk0M8AzSmxC RM7hIWIht2o58ZLr3JopABn+gb4UoqU9V8SWo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; b=NaSlwyl9DoLEem05x0FV3Sr+SqCytdfUQHSd6uu9d1nm+ppPf3EQgO8x1e0J0kTagZ JL+lcMHfB+Av3Q4Yr0BvTCxqU7OleiSkUwY/GQTO2gWAam01Dma5vts00DgiEy9sVNfi kPQNgVKQht6mJ+2SDcxEW5dByFrB4Z/B+BSbA= Received: by 10.210.56.7 with SMTP id e7mr387728eba.5.1239445835436; Sat, 11 Apr 2009 03:30:35 -0700 (PDT) Received: from logik.internal.network (81-86-41-187.dsl.pipex.com [81.86.41.187]) by mx.google.com with ESMTPS id 28sm2877575ewy.72.2009.04.11.03.30.34 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 11 Apr 2009 03:30:35 -0700 (PDT) Received: by logik.internal.network (Postfix, from userid 11001) id 34E695C31; Sat, 11 Apr 2009 10:15:59 +0000 (UTC) Date: Sat, 11 Apr 2009 11:15:59 +0100 From: xorquewasp@googlemail.com To: "Paul B. Mahol" Message-ID: <20090411101559.GC83697@logik.internal.network> References: <20090410132354.GA20721@logik.internal.network> <20090410154251.GA49384@logik.internal.network> <1239385368.1922.74.camel@balrog.2hip.net> <20090410175922.GA50520@logik.internal.network> <1239388293.1922.80.camel@balrog.2hip.net> <20090410211307.GA83697@logik.internal.network> <3a142e750904101730k53b7fbabn6e801ac36f1182e0@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3a142e750904101730k53b7fbabn6e801ac36f1182e0@mail.gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: diagnosing freezes (DRI?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 10:30:37 -0000 On 2009-04-11 02:30:40, Paul B. Mahol wrote: > > If it locks under X11 then use debug.debugger_on_panic=0 sysctl. > Not doing this will increase drasticaly chances of locking whole system > and not providing any debug data. I don't seem to have that sysctl. You sure that's the correct name? xw From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 11 10:30:38 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3351106566C; Sat, 11 Apr 2009 10:30:38 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 80BD88FC1F; Sat, 11 Apr 2009 10:30:37 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: by ewy19 with SMTP id 19so1358537ewy.43 for ; Sat, 11 Apr 2009 03:30:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:cc :subject:message-id:references:mime-version:content-type :content-disposition:in-reply-to; bh=3u1vQ78Jdic0l8XOy0cCuMNxSMitTHGN3F/iB1+Drv4=; b=Wr6AJeNnK6+FPcnads/JOiya/eaRKfvRCJEfHQSJojsoeavCrJvZOoliwsPW2Dl+mq DAuIx0tIvVoKmGoHV3aWm5UqfYgd9OsXsPCflpgFRHZ1TmqOYppuYn0Wo3Fv21bOTkkq 7wsu0JJb9w4rZ609wQSadIAu2e1V5vEq3meYc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; b=edHwO1FMp8yYb+9LDrfwnklt2E4/QORkLNGLnZDWmymyDoxJiGSsqxggXl0CsaCuKq bHK12kVV48SHuR9J8MR1YdzqqgL0AdXtg/l8F74oIyPbnIm7DhcS5jnbTNzaRvEClx5R oXTzp64ikdVp3QGNWivyVl3L1sKVEndl5dce4= Received: by 10.210.115.15 with SMTP id n15mr360413ebc.98.1239445836675; Sat, 11 Apr 2009 03:30:36 -0700 (PDT) Received: from logik.internal.network (81-86-41-187.dsl.pipex.com [81.86.41.187]) by mx.google.com with ESMTPS id 12sm2881251ewy.55.2009.04.11.03.30.34 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 11 Apr 2009 03:30:36 -0700 (PDT) Received: by logik.internal.network (Postfix, from userid 11001) id F24C75C32; Sat, 11 Apr 2009 10:23:00 +0000 (UTC) Date: Sat, 11 Apr 2009 11:23:00 +0100 From: xorquewasp@googlemail.com To: Robert Noland Message-ID: <20090411102300.GD83697@logik.internal.network> References: <20090410132354.GA20721@logik.internal.network> <20090410154251.GA49384@logik.internal.network> <1239385368.1922.74.camel@balrog.2hip.net> <20090410175922.GA50520@logik.internal.network> <1239388293.1922.80.camel@balrog.2hip.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1239388293.1922.80.camel@balrog.2hip.net> Cc: freebsd-hackers@freebsd.org Subject: Re: diagnosing freezes (DRI?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 10:30:39 -0000 The machine ran for hours, apparently. I ended up going to bed and leaving it running. Woke up to find it on display sleep, frozen. It didn't panic, apparently. I've included Xorg.0.log and the last few lines of /var/log/messages but I don't believe they show anything very interesting. I should point out that this card is the dual-DVI version. I'm not sure if that's relevant (I think it's just less common). I'm only using one screen, currently. /var/log/Xorg.0.log: X.Org X Server 1.6.0 Release Date: 2009-2-25 X Protocol Version 11, Revision 0 Build Operating System: FreeBSD 7.2-PRERELEASE amd64 Current Operating System: FreeBSD viper.internal.network 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #0: Fri Apr 10 00:09:48 BST 2009 root@viper.internal.network:/usr/obj/usr/src/sys/GENERIC amd64 Build Date: 11 April 2009 04:34:30AM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Sat Apr 11 06:16:46 2009 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "X.org Configured" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Monitor0" (**) | |-->Device "Card0" (**) |-->Input Device "Mouse0" (**) |-->Input Device "Keyboard0" (==) Not automatically adding devices (==) Not automatically enabling devices (WW) The directory "/usr/local/lib/X11/fonts/TTF/" does not exist. Entry deleted from font path. (WW) The directory "/usr/local/lib/X11/fonts/OTF" does not exist. Entry deleted from font path. (WW) The directory "/usr/local/lib/X11/fonts/Type1/" does not exist. Entry deleted from font path. (WW) The directory "/usr/local/lib/X11/fonts/TTF/" does not exist. Entry deleted from font path. (WW) The directory "/usr/local/lib/X11/fonts/OTF" does not exist. Entry deleted from font path. (WW) The directory "/usr/local/lib/X11/fonts/Type1/" does not exist. Entry deleted from font path. (**) FontPath set to: /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/, /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/, built-ins (**) ModulePath set to "/usr/local/lib/xorg/modules" (II) Loader magic: 0xd20 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 5.0 X.Org XInput driver : 4.0 X.Org Server Extension : 2.0 (II) Loader running on freebsd (--) Using syscons driver with X support (version 134217730.0) (--) using VT number 9 (--) PCI:*(0@6:0:0) ATI Technologies Inc RV570 [Radeon X1950 Pro] rev 154, Mem @ 0xd0000000/268435456, 0xfbee0000/65536, I/O @ 0x0000e000/256, BIOS @ 0x????????/65536 (--) PCI: (0@6:0:1) ATI Technologies Inc RV570 [Radeon X1950 Pro] (secondary) rev 154, Mem @ 0xfbef0000/65536 (II) System resource ranges: [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [3] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [4] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) "extmod" will be loaded. This was enabled by default and also specified in the config file. (II) "dbe" will be loaded. This was enabled by default and also specified in the config file. (II) "glx" will be loaded. This was enabled by default and also specified in the config file. (II) "record" will be loaded. This was enabled by default and also specified in the config file. (II) "dri" will be loaded. This was enabled by default and also specified in the config file. (II) "dri2" will be loaded. This was enabled by default and also specified in the config file. (II) LoadModule: "extmod" (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so (II) Module extmod: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: "record" (II) Loading /usr/local/lib/xorg/modules/extensions//librecord.so (II) Module record: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.13.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension RECORD (II) LoadModule: "dbe" (II) Loading /usr/local/lib/xorg/modules/extensions//libdbe.so (II) Module dbe: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: "glx" (II) Loading /usr/local/lib/xorg/modules/extensions//libglx.so (II) Module glx: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (==) AIGLX disabled (II) Loading extension GLX (II) LoadModule: "dri" (II) Loading /usr/local/lib/xorg/modules/extensions//libdri.so (II) Module dri: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension XFree86-DRI (II) LoadModule: "dri2" (II) Loading /usr/local/lib/xorg/modules/extensions//libdri2.so (II) Module dri2: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DRI2 (II) LoadModule: "radeon" (II) Loading /usr/local/lib/xorg/modules/drivers//radeon_drv.so (II) Module radeon: vendor="X.Org Foundation" compiled for 1.6.0, module version = 6.12.2 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 5.0 (II) LoadModule: "mouse" (II) Loading /usr/local/lib/xorg/modules/input//mouse_drv.so (II) Module mouse: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.4.0 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 4.0 (II) LoadModule: "kbd" (II) Loading /usr/local/lib/xorg/modules/input//kbd_drv.so (II) Module kbd: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.3.2 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 4.0 (II) RADEON: Driver for ATI Radeon chipsets: ATI Radeon Mobility X600 (M24) 3150 (PCIE), ATI FireMV 2400 (PCI), ATI Radeon Mobility X300 (M24) 3152 (PCIE), ATI FireGL M24 GL 3154 (PCIE), ATI Radeon X600 (RV380) 3E50 (PCIE), ATI FireGL V3200 (RV380) 3E54 (PCIE), ATI Radeon IGP320 (A3) 4136, ATI Radeon IGP330/340/350 (A4) 4137, ATI Radeon 9500 AD (AGP), ATI Radeon 9500 AE (AGP), ATI Radeon 9600TX AF (AGP), ATI FireGL Z1 AG (AGP), ATI Radeon 9800SE AH (AGP), ATI Radeon 9800 AI (AGP), ATI Radeon 9800 AJ (AGP), ATI FireGL X2 AK (AGP), ATI Radeon 9600 AP (AGP), ATI Radeon 9600SE AQ (AGP), ATI Radeon 9600XT AR (AGP), ATI Radeon 9600 AS (AGP), ATI FireGL T2 AT (AGP), ATI Radeon 9650, ATI FireGL RV360 AV (AGP), ATI Radeon 7000 IGP (A4+) 4237, ATI Radeon 8500 AIW BB (AGP), ATI Radeon 8500 AIW BC (AGP), ATI Radeon IGP320M (U1) 4336, ATI Radeon IGP330M/340M/350M (U2) 4337, ATI Radeon Mobility 7000 IGP 4437, ATI Radeon 9000/PRO If (AGP/PCI), ATI Radeon 9000 Ig (AGP/PCI), ATI Radeon X800 (R420) JH (AGP), ATI Radeon X800PRO (R420) JI (AGP), ATI Radeon X800SE (R420) JJ (AGP), ATI Radeon X800 (R420) JK (AGP), ATI Radeon X800 (R420) JL (AGP), ATI FireGL X3 (R420) JM (AGP), ATI Radeon Mobility 9800 (M18) JN (AGP), ATI Radeon X800 SE (R420) (AGP), ATI Radeon X800XT (R420) JP (AGP), ATI Radeon X850 XT (R480) (AGP), ATI Radeon X850 SE (R480) (AGP), ATI Radeon X850 PRO (R480) (AGP), ATI Radeon X850 XT PE (R480) (AGP), ATI Radeon Mobility M7 LW (AGP), ATI Mobility FireGL 7800 M7 LX (AGP), ATI Radeon Mobility M6 LY (AGP), ATI Radeon Mobility M6 LZ (AGP), ATI FireGL Mobility 9000 (M9) Ld (AGP), ATI Radeon Mobility 9000 (M9) Lf (AGP), ATI Radeon Mobility 9000 (M9) Lg (AGP), ATI Radeon 9700 Pro ND (AGP), ATI Radeon 9700/9500Pro NE (AGP), ATI Radeon 9600TX NF (AGP), ATI FireGL X1 NG (AGP), ATI Radeon 9800PRO NH (AGP), ATI Radeon 9800 NI (AGP), ATI FireGL X2 NK (AGP), ATI Radeon 9800XT NJ (AGP), ATI Radeon Mobility 9600/9700 (M10/M11) NP (AGP), ATI Radeon Mobility 9600 (M10) NQ (AGP), ATI Radeon Mobility 9600 (M11) NR (AGP), ATI Radeon Mobility 9600 (M10) NS (AGP), ATI FireGL Mobility T2 (M10) NT (AGP), ATI FireGL Mobility T2e (M11) NV (AGP), ATI Radeon QD (AGP), ATI Radeon QE (AGP), ATI Radeon QF (AGP), ATI Radeon QG (AGP), ATI FireGL 8700/8800 QH (AGP), ATI Radeon 8500 QL (AGP), ATI Radeon 9100 QM (AGP), ATI Radeon 7500 QW (AGP/PCI), ATI Radeon 7500 QX (AGP/PCI), ATI Radeon VE/7000 QY (AGP/PCI), ATI Radeon VE/7000 QZ (AGP/PCI), ATI ES1000 515E (PCI), ATI Radeon Mobility X300 (M22) 5460 (PCIE), ATI Radeon Mobility X600 SE (M24C) 5462 (PCIE), ATI FireGL M22 GL 5464 (PCIE), ATI Radeon X800 (R423) UH (PCIE), ATI Radeon X800PRO (R423) UI (PCIE), ATI Radeon X800LE (R423) UJ (PCIE), ATI Radeon X800SE (R423) UK (PCIE), ATI Radeon X800 XTP (R430) (PCIE), ATI Radeon X800 XL (R430) (PCIE), ATI Radeon X800 SE (R430) (PCIE), ATI Radeon X800 (R430) (PCIE), ATI FireGL V7100 (R423) (PCIE), ATI FireGL V5100 (R423) UQ (PCIE), ATI FireGL unknown (R423) UR (PCIE), ATI FireGL unknown (R423) UT (PCIE), ATI Mobility FireGL V5000 (M26) (PCIE), ATI Mobility FireGL V5000 (M26) (PCIE), ATI Mobility Radeon X700 XL (M26) (PCIE), ATI Mobility Radeon X700 (M26) (PCIE), ATI Mobility Radeon X700 (M26) (PCIE), ATI Radeon X550XTX 5657 (PCIE), ATI Radeon 9100 IGP (A5) 5834, ATI Radeon Mobility 9100 IGP (U3) 5835, ATI Radeon XPRESS 200 5954 (PCIE), ATI Radeon XPRESS 200M 5955 (PCIE), ATI Radeon 9250 5960 (AGP), ATI Radeon 9200 5961 (AGP), ATI Radeon 9200 5962 (AGP), ATI Radeon 9200SE 5964 (AGP), ATI FireMV 2200 (PCI), ATI ES1000 5969 (PCI), ATI Radeon XPRESS 200 5974 (PCIE), ATI Radeon XPRESS 200M 5975 (PCIE), ATI Radeon XPRESS 200 5A41 (PCIE), ATI Radeon XPRESS 200M 5A42 (PCIE), ATI Radeon XPRESS 200 5A61 (PCIE), ATI Radeon XPRESS 200M 5A62 (PCIE), ATI Radeon X300 (RV370) 5B60 (PCIE), ATI Radeon X600 (RV370) 5B62 (PCIE), ATI Radeon X550 (RV370) 5B63 (PCIE), ATI FireGL V3100 (RV370) 5B64 (PCIE), ATI FireMV 2200 PCIE (RV370) 5B65 (PCIE), ATI Radeon Mobility 9200 (M9+) 5C61 (AGP), ATI Radeon Mobility 9200 (M9+) 5C63 (AGP), ATI Mobility Radeon X800 XT (M28) (PCIE), ATI Mobility FireGL V5100 (M28) (PCIE), ATI Mobility Radeon X800 (M28) (PCIE), ATI Radeon X850 5D4C (PCIE), ATI Radeon X850 XT PE (R480) (PCIE), ATI Radeon X850 SE (R480) (PCIE), ATI Radeon X850 PRO (R480) (PCIE), ATI unknown Radeon / FireGL (R480) 5D50 (PCIE), ATI Radeon X850 XT (R480) (PCIE), ATI Radeon X800XT (R423) 5D57 (PCIE), ATI FireGL V5000 (RV410) (PCIE), ATI Radeon X700 XT (RV410) (PCIE), ATI Radeon X700 PRO (RV410) (PCIE), ATI Radeon X700 SE (RV410) (PCIE), ATI Radeon X700 (RV410) (PCIE), ATI Radeon X700 SE (RV410) (PCIE), ATI Radeon X1800, ATI Mobility Radeon X1800 XT, ATI Mobility Radeon X1800, ATI Mobility FireGL V7200, ATI FireGL V7200, ATI FireGL V5300, ATI Mobility FireGL V7100, ATI Radeon X1800, ATI Radeon X1800, ATI Radeon X1800, ATI Radeon X1800, ATI Radeon X1800, ATI FireGL V7300, ATI FireGL V7350, ATI Radeon X1600, ATI RV505, ATI Radeon X1300/X1550, ATI Radeon X1550, ATI M54-GL, ATI Mobility Radeon X1400, ATI Radeon X1300/X1550, ATI Radeon X1550 64-bit, ATI Mobility Radeon X1300, ATI Mobility Radeon X1300, ATI Mobility Radeon X1300, ATI Mobility Radeon X1300, ATI Radeon X1300, ATI Radeon X1300, ATI RV505, ATI RV505, ATI FireGL V3300, ATI FireGL V3350, ATI Radeon X1300, ATI Radeon X1550 64-bit, ATI Radeon X1300/X1550, ATI Radeon X1600, ATI Radeon X1300/X1550, ATI Mobility Radeon X1450, ATI Radeon X1300/X1550, ATI Mobility Radeon X2300, ATI Mobility Radeon X2300, ATI Mobility Radeon X1350, ATI Mobility Radeon X1350, ATI Mobility Radeon X1450, ATI Radeon X1300, ATI Radeon X1550, ATI Mobility Radeon X1350, ATI FireMV 2250, ATI Radeon X1550 64-bit, ATI Radeon X1600, ATI Radeon X1650, ATI Radeon X1600, ATI Radeon X1600, ATI Mobility FireGL V5200, ATI Mobility Radeon X1600, ATI Radeon X1650, ATI Radeon X1650, ATI Radeon X1600, ATI Radeon X1300 XT/X1600 Pro, ATI FireGL V3400, ATI Mobility FireGL V5250, ATI Mobility Radeon X1700, ATI Mobility Radeon X1700 XT, ATI FireGL V5200, ATI Mobility Radeon X1700, ATI Radeon X2300HD, ATI Mobility Radeon HD 2300, ATI Mobility Radeon HD 2300, ATI Radeon X1950, ATI Radeon X1900, ATI Radeon X1950, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, ATI AMD Stream Processor, ATI Radeon X1900, ATI Radeon X1950, ATI RV560, ATI RV560, ATI Mobility Radeon X1900, ATI RV560, ATI Radeon X1950 GT, ATI RV570, ATI RV570, ATI FireGL V7400, ATI RV560, ATI Radeon X1650, ATI Radeon X1650, ATI RV560, ATI Radeon 9100 PRO IGP 7834, ATI Radeon Mobility 9200 IGP 7835, ATI Radeon X1200, ATI Radeon X1200, ATI Radeon X1200, ATI Radeon X1200, ATI Radeon X1200, ATI RS740, ATI RS740M, ATI RS740, ATI RS740M, ATI Radeon HD 2900 XT, ATI Radeon HD 2900 XT, ATI Radeon HD 2900 XT, ATI Radeon HD 2900 Pro, ATI Radeon HD 2900 GT, ATI FireGL V8650, ATI FireGL V8600, ATI FireGL V7600, ATI Radeon 4800 Series, ATI Radeon HD 4870 x2, ATI Radeon 4800 Series, ATI FirePro V8750 (FireGL), ATI FirePro V7760 (FireGL), ATI Mobility RADEON HD 4850, ATI Mobility RADEON HD 4850 X2, ATI Radeon 4800 Series, ATI FirePro RV770, AMD FireStream 9270, AMD FireStream 9250, ATI FirePro V8700 (FireGL), ATI Mobility RADEON HD 4870, ATI Mobility RADEON M98, ATI Radeon 4800 Series, ATI Radeon 4800 Series, ATI FirePro M7750, ATI M98, ATI M98, ATI M98, ATI Radeon RV730 (AGP), ATI FirePro M5750, ATI Radeon RV730 (AGP), ATI RV730XT [Radeon HD 4670], ATI RADEON E4600, ATI RV730 PRO [Radeon HD 4650], ATI FirePro V7750 (FireGL), ATI FirePro V5700 (FireGL), ATI FirePro V3750 (FireGL), ATI RV610, ATI Radeon HD 2400 XT, ATI Radeon HD 2400 Pro, ATI Radeon HD 2400 PRO AGP, ATI FireGL V4000, ATI RV610, ATI Radeon HD 2350, ATI Mobility Radeon HD 2400 XT, ATI Mobility Radeon HD 2400, ATI RADEON E2400, ATI RV610, ATI FireMV 2260, ATI RV670, ATI Radeon HD3870, ATI Mobility Radeon HD 3850, ATI Radeon HD3850, ATI Mobility Radeon HD 3850 X2, ATI RV670, ATI Mobility Radeon HD 3870, ATI Mobility Radeon HD 3870 X2, ATI Radeon HD3870 X2, ATI FireGL V7700, ATI Radeon HD3850, ATI Radeon HD3690, AMD Firestream 9170, ATI Radeon HD 4550, ATI Radeon RV710, ATI Radeon RV710, ATI Radeon HD 4350, ATI Mobility Radeon 4300 Series, ATI Mobility Radeon 4500 Series, ATI Mobility Radeon 4500 Series, ATI RV630, ATI Mobility Radeon HD 2600, ATI Mobility Radeon HD 2600 XT, ATI Radeon HD 2600 XT AGP, ATI Radeon HD 2600 Pro AGP, ATI Radeon HD 2600 XT, ATI Radeon HD 2600 Pro, ATI Gemini RV630, ATI Gemini Mobility Radeon HD 2600 XT, ATI FireGL V5600, ATI FireGL V3600, ATI Radeon HD 2600 LE, ATI Mobility FireGL Graphics Processor, ATI Radeon RV710, ATI Radeon HD 3470, ATI Mobility Radeon HD 3430, ATI Mobility Radeon HD 3400 Series, ATI Radeon HD 3450, ATI Radeon HD 3450, ATI Radeon HD 3430, ATI Radeon HD 3450, ATI FirePro V3700, ATI FireMV 2450, ATI FireMV 2260, ATI FireMV 2260, ATI Radeon HD 3600 Series, ATI Radeon HD 3650 AGP, ATI Radeon HD 3600 PRO, ATI Radeon HD 3600 XT, ATI Radeon HD 3600 PRO, ATI Mobility Radeon HD 3650, ATI Mobility Radeon HD 3670, ATI Mobility FireGL V5700, ATI Mobility FireGL V5725, ATI Radeon HD 3200 Graphics, ATI Radeon 3100 Graphics, ATI Radeon HD 3200 Graphics, ATI Radeon 3100 Graphics, ATI Radeon HD 3300 Graphics, ATI Radeon HD 3200 Graphics, ATI Radeon 3000 Graphics, ATI Radeon HD Graphics, ATI Radeon Graphics, ATI Mobility Radeon HD Graphics, ATI Mobility Radeon Graphics, ATI Radeon Graphics (II) Primary Device is: PCI 06@00:00:0 (II) resource ranges after xf86ClaimFixedResources() call: [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [3] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [4] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] (II) resource ranges after probing: [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [3] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B] [4] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] [5] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B] [6] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [7] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [8] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B] [9] 0 0 0x000003c0 - 0x000003df (0x20) IS[B] (II) Setting vga for screen 0. (II) RADEON(0): TOTO SAYS 00000000fbee0000 (II) RADEON(0): MMIO registers at 0x00000000fbee0000: size 64KB (II) RADEON(0): PCI bus 6 card 0 func 0 (==) RADEON(0): Depth 24, (--) framebuffer bpp 32 (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps) (==) RADEON(0): Default visual is TrueColor (II) Loading sub module "vgahw" (II) LoadModule: "vgahw" (II) Loading /usr/local/lib/xorg/modules//libvgahw.so (II) Module vgahw: vendor="X.Org Foundation" compiled for 1.6.0, module version = 0.1.0 ABI class: X.Org Video Driver, version 5.0 (II) RADEON(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000 (==) RADEON(0): RGB weight 888 (II) RADEON(0): Using 8 bits per RGB (8 bit DAC) (--) RADEON(0): Chipset: "ATI Radeon X1950" (ChipID = 0x7280) (WW) RADEON(0): R500 support is under development. Please report any issues to xorg-driver-ati@lists.x.org (--) RADEON(0): Linear framebuffer at 0x00000000d0000000 (II) RADEON(0): PCIE card detected (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Loading /usr/local/lib/xorg/modules//libint10.so (II) Module int10: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.0.0 ABI class: X.Org Video Driver, version 5.0 (II) RADEON(0): initializing int10 (==) RADEON(0): Write-combining range (0xa0000,0x20000) was already clear (==) RADEON(0): Write-combining range (0xc0000,0x40000) was already clear (II) RADEON(0): Primary V_BIOS segment is: 0xc000 (==) RADEON(0): Write-combining range (0x0,0x1000) was already clear (II) RADEON(0): ATOM BIOS detected (II) RADEON(0): ATOM BIOS Rom: SubsystemVendorID: 0x148c SubsystemID: 0x2204 IOBaseAddress: 0xe000 Filename: 64125LAB.SEF BIOS Bootup Message: RV570XT DDR3 256MB 64125LAB.SEF V9.13.1.12 (II) RADEON(0): Framebuffer space used by Firmware (kb): 20 (II) RADEON(0): Start of VRAM area used by Firmware: 0xfffb000 (II) RADEON(0): AtomBIOS requests 20kB of VRAM scratch space (II) RADEON(0): AtomBIOS VRAM scratch base: 0xfffb000 (II) RADEON(0): Cannot get VRAM scratch space. Allocating in main memory instead (II) RADEON(0): Default Engine Clock: 600000 (II) RADEON(0): Default Memory Clock: 700000 (II) RADEON(0): Maximum Pixel ClockPLL Frequency Output: 1100000 (II) RADEON(0): Minimum Pixel ClockPLL Frequency Output: 0 (II) RADEON(0): Maximum Pixel ClockPLL Frequency Input: 13500 (II) RADEON(0): Minimum Pixel ClockPLL Frequency Input: 1000 (II) RADEON(0): Maximum Pixel Clock: 400000 (II) RADEON(0): Reference Clock: 27000 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 10, (OK) drmOpenByBusid: Searching for BusID pci:0000:06:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 10, (OK) drmOpenByBusid: drmOpenMinor returns 10 drmOpenByBusid: drmGetBusid reports pci:0000:06:00.0 (II) RADEON(0): [dri] Found DRI library version 1.3.0 and kernel module version 1.29.0 (==) RADEON(0): Page Flipping disabled on r5xx and newer chips. (II) RADEON(0): Will try to use DMA for Xv image transfers (II) RADEON(0): Generation 2 PCI interface, using max accessible memory (II) RADEON(0): Detected total video RAM=262144K, accessible=262144K (PCI BAR=262144K) (--) RADEON(0): Mapped VideoRAM: 262144 kByte (256 bit DDR SDRAM) (II) RADEON(0): Color tiling enabled by default (II) RADEON(0): Max desktop size set to 2560x1600 (II) RADEON(0): For a larger or smaller max desktop size, add a Virtual line to your xorg.conf (II) RADEON(0): If you are having trouble with 3D, reduce the desktop size by adjusting the Virtual line to your xorg.conf (II) Loading sub module "ddc" (II) LoadModule: "ddc" (II) Module "ddc" already built-in (II) Loading sub module "i2c" (II) LoadModule: "i2c" (II) Module "i2c" already built-in (II) RADEON(0): ref_freq: 2700, min_out_pll: 64800, max_out_pll: 110000, min_in_pll: 100, max_in_pll: 1350, xclk: 40000, sclk: 600.000000, mclk: 700.000000 (II) RADEON(0): PLL parameters: rf=2700 rd=13 min=64800 max=110000; xclk=40000 (II) RADEON(0): Skipping TV-Out (II) RADEON(0): Skipping Component Video encoder: 0x15 encoder: 0x13 encoder: 0x16 encoder: 0xf (II) RADEON(0): Output DVI-1 using monitor section Monitor0 (II) RADEON(0): I2C bus "DVI-1" initialized. (II) RADEON(0): Output DVI-0 has no monitor section (II) RADEON(0): I2C bus "DVI-0" initialized. (II) RADEON(0): Port0: XRANDR name: DVI-1 Connector: DVI-I CRT2: INTERNAL_KLDSCP_DAC2 DFP1: INTERNAL_KLDSCP_TMDS1 DDC reg: 0x7e50 (II) RADEON(0): Port1: XRANDR name: DVI-0 Connector: DVI-I CRT1: INTERNAL_KLDSCP_DAC1 DFP3: INTERNAL_LVTM1 DDC reg: 0x7e40 (II) RADEON(0): I2C device "DVI-1:E-EDID segment register" registered at address 0x60. (II) RADEON(0): I2C device "DVI-1:ddc2" registered at address 0xA0. (II) RADEON(0): EDID vendor "SAM", prod id 628 (II) RADEON(0): Using hsync ranges from config file (II) RADEON(0): Using vrefresh ranges from config file (II) RADEON(0): Printing DDC gathered Modelines: (II) RADEON(0): Modeline "1440x900"x0.0 106.50 1440 1520 1672 1904 900 903 909 934 -hsync +vsync (55.9 kHz) (II) RADEON(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) RADEON(0): Modeline "800x600"x0.0 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) (II) RADEON(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz) (II) RADEON(0): Modeline "640x480"x0.0 31.50 640 664 704 832 480 489 492 520 -hsync -vsync (37.9 kHz) (II) RADEON(0): Modeline "640x480"x0.0 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (35.0 kHz) (II) RADEON(0): Modeline "640x480"x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) RADEON(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz) (II) RADEON(0): Modeline "1280x1024"x0.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz) (II) RADEON(0): Modeline "1024x768"x0.0 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz) (II) RADEON(0): Modeline "1024x768"x0.0 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz) (II) RADEON(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) RADEON(0): Modeline "832x624"x0.0 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz) (II) RADEON(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz) (II) RADEON(0): Modeline "800x600"x0.0 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz) (II) RADEON(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz) (II) RADEON(0): Modeline "1440x900"x0.0 88.75 1440 1488 1520 1600 900 903 909 926 +hsync -vsync (55.5 kHz) (II) RADEON(0): Modeline "1440x900"x0.0 136.75 1440 1536 1688 1936 900 903 909 942 -hsync +vsync (70.6 kHz) (II) RADEON(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz) (II) RADEON(0): Modeline "1280x960"x0.0 108.00 1280 1376 1488 1800 960 961 964 1000 +hsync +vsync (60.0 kHz) (II) RADEON(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz) (II) RADEON(0): Output: DVI-1, Detected Monitor Type: 3 (II) RADEON(0): EDID data from the display on output: DVI-1 ---------------------- (II) RADEON(0): Manufacturer: SAM Model: 274 Serial#: 1296380217 (II) RADEON(0): Year: 2007 Week: 28 (II) RADEON(0): EDID Version: 1.3 (II) RADEON(0): Digital Display Input (II) RADEON(0): Max Image Size [cm]: horiz.: 41 vert.: 26 (II) RADEON(0): Gamma: 2.35 (II) RADEON(0): DPMS capabilities: Off (II) RADEON(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4 (II) RADEON(0): First detailed timing is preferred mode (II) RADEON(0): redX: 0.640 redY: 0.329 greenX: 0.300 greenY: 0.600 (II) RADEON(0): blueX: 0.150 blueY: 0.060 whiteX: 0.313 whiteY: 0.329 (II) RADEON(0): Supported VESA Video Modes: (II) RADEON(0): 720x400@70Hz (II) RADEON(0): 640x480@60Hz (II) RADEON(0): 640x480@67Hz (II) RADEON(0): 640x480@72Hz (II) RADEON(0): 640x480@75Hz (II) RADEON(0): 800x600@56Hz (II) RADEON(0): 800x600@60Hz (II) RADEON(0): 800x600@72Hz (II) RADEON(0): 800x600@75Hz (II) RADEON(0): 832x624@75Hz (II) RADEON(0): 1024x768@60Hz (II) RADEON(0): 1024x768@70Hz (II) RADEON(0): 1024x768@75Hz (II) RADEON(0): 1280x1024@75Hz (II) RADEON(0): 1152x870@75Hz (II) RADEON(0): Manufacturer's mask: 0 (II) RADEON(0): Supported Future Video Modes: (II) RADEON(0): #0: hsize: 1440 vsize 900 refresh: 60 vid: 149 (II) RADEON(0): #1: hsize: 1440 vsize 900 refresh: 75 vid: 3989 (II) RADEON(0): #2: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) RADEON(0): #3: hsize: 1280 vsize 960 refresh: 60 vid: 16513 (II) RADEON(0): #4: hsize: 1152 vsize 864 refresh: 75 vid: 20337 (II) RADEON(0): Supported additional Video Mode: (II) RADEON(0): clock: 106.5 MHz Image Size: 410 x 257 mm (II) RADEON(0): h_active: 1440 h_sync: 1520 h_sync_end 1672 h_blank_end 1904 h_border: 0 (II) RADEON(0): v_active: 900 v_sync: 903 v_sync_end 909 v_blanking: 934 v_border: 0 (II) RADEON(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 81 kHz, PixClock max 140 MHz (II) RADEON(0): Monitor name: SyncMaster (II) RADEON(0): Serial No: H9XP701904 (II) RADEON(0): EDID (in hex): (II) RADEON(0): 00ffffffffffff004c2d74023931454d (II) RADEON(0): 1c11010380291a872ade95a3544c9926 (II) RADEON(0): 0f5054bfef809500950f81808140714f (II) RADEON(0): 0101010101019a29a0d0518422305098 (II) RADEON(0): 36009a011100001c000000fd00384b1e (II) RADEON(0): 510e000a202020202020000000fc0053 (II) RADEON(0): 796e634d61737465720a2020000000ff (II) RADEON(0): 00483958503730313930340a20200062 finished output detect: 0 (II) RADEON(0): I2C device "DVI-0:E-EDID segment register" registered at address 0x60. (II) RADEON(0): I2C device "DVI-0:ddc2" registered at address 0xA0. (II) RADEON(0): Output: DVI-0, Detected Monitor Type: 0 Dac detection success Unhandled monitor type 0 finished output detect: 1 finished all detect before xf86InitialConfiguration (II) RADEON(0): EDID vendor "SAM", prod id 628 (II) RADEON(0): Using hsync ranges from config file (II) RADEON(0): Using vrefresh ranges from config file (II) RADEON(0): Printing DDC gathered Modelines: (II) RADEON(0): Modeline "1440x900"x0.0 106.50 1440 1520 1672 1904 900 903 909 934 -hsync +vsync (55.9 kHz) (II) RADEON(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz) (II) RADEON(0): Modeline "800x600"x0.0 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz) (II) RADEON(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 484 500 -hsync -vsync (37.5 kHz) (II) RADEON(0): Modeline "640x480"x0.0 31.50 640 664 704 832 480 489 492 520 -hsync -vsync (37.9 kHz) (II) RADEON(0): Modeline "640x480"x0.0 30.24 640 704 768 864 480 483 486 525 -hsync -vsync (35.0 kHz) (II) RADEON(0): Modeline "640x480"x0.0 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz) (II) RADEON(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 414 449 -hsync +vsync (31.5 kHz) (II) RADEON(0): Modeline "1280x1024"x0.0 135.00 1280 1296 1440 1688 1024 1025 1028 1066 +hsync +vsync (80.0 kHz) (II) RADEON(0): Modeline "1024x768"x0.0 78.75 1024 1040 1136 1312 768 769 772 800 +hsync +vsync (60.0 kHz) (II) RADEON(0): Modeline "1024x768"x0.0 75.00 1024 1048 1184 1328 768 771 777 806 -hsync -vsync (56.5 kHz) (II) RADEON(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz) (II) RADEON(0): Modeline "832x624"x0.0 57.28 832 864 928 1152 624 625 628 667 -hsync -vsync (49.7 kHz) (II) RADEON(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601 604 625 +hsync +vsync (46.9 kHz) (II) RADEON(0): Modeline "800x600"x0.0 50.00 800 856 976 1040 600 637 643 666 +hsync +vsync (48.1 kHz) (II) RADEON(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz) (II) RADEON(0): Modeline "1440x900"x0.0 88.75 1440 1488 1520 1600 900 903 909 926 +hsync -vsync (55.5 kHz) (II) RADEON(0): Modeline "1440x900"x0.0 136.75 1440 1536 1688 1936 900 903 909 942 -hsync +vsync (70.6 kHz) (II) RADEON(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz) (II) RADEON(0): Modeline "1280x960"x0.0 108.00 1280 1376 1488 1800 960 961 964 1000 +hsync +vsync (60.0 kHz) (II) RADEON(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864 865 868 900 +hsync +vsync (67.5 kHz) (II) RADEON(0): Output: DVI-1, Detected Monitor Type: 3 (II) RADEON(0): EDID data from the display on output: DVI-1 ---------------------- (II) RADEON(0): Manufacturer: SAM Model: 274 Serial#: 1296380217 (II) RADEON(0): Year: 2007 Week: 28 (II) RADEON(0): EDID Version: 1.3 (II) RADEON(0): Digital Display Input (II) RADEON(0): Max Image Size [cm]: horiz.: 41 vert.: 26 (II) RADEON(0): Gamma: 2.35 (II) RADEON(0): DPMS capabilities: Off (II) RADEON(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4 (II) RADEON(0): First detailed timing is preferred mode (II) RADEON(0): redX: 0.640 redY: 0.329 greenX: 0.300 greenY: 0.600 (II) RADEON(0): blueX: 0.150 blueY: 0.060 whiteX: 0.313 whiteY: 0.329 (II) RADEON(0): Supported VESA Video Modes: (II) RADEON(0): 720x400@70Hz (II) RADEON(0): 640x480@60Hz (II) RADEON(0): 640x480@67Hz (II) RADEON(0): 640x480@72Hz (II) RADEON(0): 640x480@75Hz (II) RADEON(0): 800x600@56Hz (II) RADEON(0): 800x600@60Hz (II) RADEON(0): 800x600@72Hz (II) RADEON(0): 800x600@75Hz (II) RADEON(0): 832x624@75Hz (II) RADEON(0): 1024x768@60Hz (II) RADEON(0): 1024x768@70Hz (II) RADEON(0): 1024x768@75Hz (II) RADEON(0): 1280x1024@75Hz (II) RADEON(0): 1152x870@75Hz (II) RADEON(0): Manufacturer's mask: 0 (II) RADEON(0): Supported Future Video Modes: (II) RADEON(0): #0: hsize: 1440 vsize 900 refresh: 60 vid: 149 (II) RADEON(0): #1: hsize: 1440 vsize 900 refresh: 75 vid: 3989 (II) RADEON(0): #2: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 (II) RADEON(0): #3: hsize: 1280 vsize 960 refresh: 60 vid: 16513 (II) RADEON(0): #4: hsize: 1152 vsize 864 refresh: 75 vid: 20337 (II) RADEON(0): Supported additional Video Mode: (II) RADEON(0): clock: 106.5 MHz Image Size: 410 x 257 mm (II) RADEON(0): h_active: 1440 h_sync: 1520 h_sync_end 1672 h_blank_end 1904 h_border: 0 (II) RADEON(0): v_active: 900 v_sync: 903 v_sync_end 909 v_blanking: 934 v_border: 0 (II) RADEON(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 81 kHz, PixClock max 140 MHz (II) RADEON(0): Monitor name: SyncMaster (II) RADEON(0): Serial No: H9XP701904 (II) RADEON(0): EDID (in hex): (II) RADEON(0): 00ffffffffffff004c2d74023931454d (II) RADEON(0): 1c11010380291a872ade95a3544c9926 (II) RADEON(0): 0f5054bfef809500950f81808140714f (II) RADEON(0): 0101010101019a29a0d0518422305098 (II) RADEON(0): 36009a011100001c000000fd00384b1e (II) RADEON(0): 510e000a202020202020000000fc0053 (II) RADEON(0): 796e634d61737465720a2020000000ff (II) RADEON(0): 00483958503730313930340a20200062 (II) RADEON(0): Panel infos found from DDC detailed: 1440x900 (II) RADEON(0): EDID vendor "SAM", prod id 628 (II) RADEON(0): Output: DVI-0, Detected Monitor Type: 0 Dac detection success Unhandled monitor type 0 (II) RADEON(0): Output DVI-1 connected (II) RADEON(0): Output DVI-0 disconnected (II) RADEON(0): Using exact sizes for initial modes (II) RADEON(0): Output DVI-1 using initial mode 1440x900 after xf86InitialConfiguration (**) RADEON(0): Display dimensions: (410, 260) mm (**) RADEON(0): DPI set to (89, 140) (II) Loading sub module "fb" (II) LoadModule: "fb" (II) Loading /usr/local/lib/xorg/modules//libfb.so (II) Module fb: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.0.0 ABI class: X.Org ANSI C Emulation, version 0.4 (==) RADEON(0): Using gamma correction (1.0, 1.0, 1.0) (II) Loading sub module "ramdac" (II) LoadModule: "ramdac" (II) Module "ramdac" already built-in (==) RADEON(0): Using XAA acceleration architecture (II) Loading sub module "xaa" (II) LoadModule: "xaa" (II) Loading /usr/local/lib/xorg/modules//libxaa.so (II) Module xaa: vendor="X.Org Foundation" compiled for 1.6.0, module version = 1.2.1 ABI class: X.Org Video Driver, version 5.0 (==) RADEON(0): Write-combining range (0x0,0x1000) was already clear (!!) RADEON(0): For information on using the multimedia capabilities of this adapter, please see http://gatos.sf.net. (!!) RADEON(0): MergedFB support has been removed and replaced with xrandr 1.2 support (--) Depth 24 pixmap format is 32 bpp (II) do I need RAC? No, I don't. (II) resource ranges after preInit: [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [3] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B](OprU) [4] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B](OprU) [5] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B](OprU) [6] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [7] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [8] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B](OprU) [9] 0 0 0x000003c0 - 0x000003df (0x20) IS[B](OprU) (II) RADEON(0): RADEONScreenInit d0000000 0 0 (==) RADEON(0): Write-combining range (0xa0000,0x10000) was already clear Output DFP1 disable success Blank CRTC 0 success Disable CRTC 0 success Blank CRTC 1 success Disable CRTC 1 success (==) RADEON(0): Using 24 bit depth buffer (II) RADEON(0): RADEONInitMemoryMap() : (II) RADEON(0): mem_size : 0x10000000 (II) RADEON(0): MC_FB_LOCATION : 0xdfffd000 (II) RADEON(0): MC_AGP_LOCATION : 0x003f0000 (II) RADEON(0): Depth moves disabled by default (II) RADEON(0): Using 32 MB GART aperture (II) RADEON(0): Using 1 MB for the ring buffer (II) RADEON(0): Using 2 MB for vertex/indirect buffers (II) RADEON(0): Using 29 MB for GART textures (II) RADEON(0): Memory manager initialized to (0,0) (1472,8191) (II) RADEON(0): Reserved area from (0,1440) to (1472,1442) (II) RADEON(0): Largest offscreen area available: 1472 x 6749 (II) RADEON(0): Will use front buffer at offset 0x0 (II) RADEON(0): Will use back buffer at offset 0x23c2000 (II) RADEON(0): Will use depth buffer at offset 0x2bd8000 (II) RADEON(0): Will use 32 kb for PCI GART table at offset 0xfff8000 (II) RADEON(0): Will use 208896 kb for textures at offset 0x33ee000 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 10, (OK) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 10, (OK) drmOpenByBusid: Searching for BusID pci:0000:06:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 10, (OK) drmOpenByBusid: drmOpenMinor returns 10 drmOpenByBusid: drmGetBusid reports pci:0000:06:00.0 (II) [drm] DRM interface version 1.2 (II) [drm] DRM open master succeeded. (II) RADEON(0): [drm] Using the DRM lock SAREA also for drawables. (II) RADEON(0): [drm] framebuffer handle = 0xd0000000 (II) RADEON(0): [drm] added 1 reserved context for kernel (II) RADEON(0): X context handle = 0x1 (II) RADEON(0): [drm] installed DRM signal handler (II) RADEON(0): [pci] 32768 kB allocated with handle 0x7a2cb000 (II) RADEON(0): [pci] ring handle = 0x7a2cb000 (II) RADEON(0): [pci] Ring mapped at 0x812e00000 (II) RADEON(0): [pci] Ring contents 0x00000000 (II) RADEON(0): [pci] ring read ptr handle = 0x7a3cc000 (II) RADEON(0): [pci] Ring read ptr mapped at 0x80076b000 (II) RADEON(0): [pci] Ring read ptr contents 0x00000000 (II) RADEON(0): [pci] vertex/indirect buffers handle = 0x7a3cd000 (II) RADEON(0): [pci] Vertex/indirect buffers mapped at 0x812f01000 (II) RADEON(0): [pci] Vertex/indirect buffers contents 0x00000000 (II) RADEON(0): [pci] GART texture map handle = 0x7a5cd000 (II) RADEON(0): [pci] GART Texture map mapped at 0x8131cd000 (II) RADEON(0): [drm] register handle = 0xfbee0000 (II) RADEON(0): [dri] Visual configs initialized (II) RADEON(0): RADEONRestoreMemMapRegisters() : (II) RADEON(0): MC_FB_LOCATION : 0xdfffd000 0xfffff000 (II) RADEON(0): MC_AGP_LOCATION : 0x003f0000 (==) RADEON(0): Backing store disabled (II) RADEON(0): [DRI] installation complete (II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers (II) RADEON(0): [drm] Mapped 32 vertex/indirect buffers (II) RADEON(0): [drm] dma control initialized, using IRQ 16 (II) RADEON(0): [drm] Initialized kernel GART heap manager, 29884416 (WW) RADEON(0): DRI init changed memory map, adjusting ... (WW) RADEON(0): MC_FB_LOCATION was: 0xdfffd000 is: 0xdfffd000 (WW) RADEON(0): MC_AGP_LOCATION was: 0x003f0000 is: 0xffffffc0 (II) RADEON(0): RADEONRestoreMemMapRegisters() : (II) RADEON(0): MC_FB_LOCATION : 0xdfffd000 0xdfffd000 (II) RADEON(0): MC_AGP_LOCATION : 0xffffffc0 (II) RADEON(0): Direct rendering enabled (II) RADEON(0): XAA Render acceleration unsupported on Radeon 9500/9700 and newer. Please use EXA instead. (II) RADEON(0): Render acceleration disabled (II) RADEON(0): num quad-pipes is 3 (II) RADEON(0): Using XFree86 Acceleration Architecture (XAA) Screen to screen bit blits Solid filled rectangles 8x8 mono pattern filled rectangles Indirect CPU to Screen color expansion Solid Lines Scanline Image Writes Setting up tile and stipple cache: 32 128x128 slots 32 256x256 slots 16 512x512 slots (II) RADEON(0): Acceleration enabled (**) Option "dpms" (**) RADEON(0): DPMS enabled (==) RADEON(0): Silken mouse enabled (II) RADEON(0): Will use 32 kb for hardware cursor 0 at offset 0x00819000 (II) RADEON(0): Will use 32 kb for hardware cursor 1 at offset 0x0081f000 (II) RADEON(0): Largest offscreen area available: 1472 x 6741 (II) RADEON(0): Set up textured video Output DFP1 disable success Blank CRTC 0 success Disable CRTC 0 success Blank CRTC 1 success Disable CRTC 1 success Output DFP1 disable success Mode 1440x900 - 1904 934 6 (II) RADEON(0): RADEONRestoreMemMapRegisters() : (II) RADEON(0): MC_FB_LOCATION : 0xdfffd000 0xdfffd000 (II) RADEON(0): MC_AGP_LOCATION : 0xffffffc0 freq: 106500000 best_freq: 106500000 best_feedback_div: 71 best_ref_div: 2 best_post_div: 9 (II) RADEON(0): crtc(0) Clock: mode 106500, PLL 106500 (II) RADEON(0): crtc(0) PLL : refdiv 2, fbdiv 0x47(71), pdiv 9 Set CRTC 0 PLL success Set CRTC Timing success Set CRTC 0 Overscan success Not using RMX scaler 0 setup success Set CRTC 0 Source success crtc 0 YUV disable setup success Output digital setup success Enable CRTC 0 success Unblank CRTC 0 success Output DFP1 enable success Blank CRTC 1 success Disable CRTC 1 success (II) RADEON(0): RandR 1.2 enabled, ignore the following RandR disabled message. Lock CRTC 0 success Unlock CRTC 0 success (--) RandR disabled (II) Initializing built-in extension Generic Event Extension (II) Initializing built-in extension SHAPE (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension BIG-REQUESTS (II) Initializing built-in extension SYNC (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension XC-MISC (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFIXES (II) Initializing built-in extension RENDER (II) Initializing built-in extension RANDR (II) Initializing built-in extension COMPOSITE (II) Initializing built-in extension DAMAGE (II) AIGLX: Loaded and initialized /usr/local/lib/dri/swrast_dri.so (II) GLX: Initialized DRISWRAST GL provider for screen 0 (II) RADEON(0): Setting screen physical size to 410 x 257 (**) Option "Protocol" "auto" (**) Mouse0: Device: "/dev/sysmouse" (**) Mouse0: Protocol: "auto" (**) Option "CorePointer" (**) Mouse0: always reports core events (**) Option "Device" "/dev/sysmouse" (==) Mouse0: Emulate3Buttons, Emulate3Timeout: 50 (**) Option "ZAxisMapping" "4 5 6 7" (**) Mouse0: ZAxisMapping: buttons 4, 5, 6 and 7 (**) Mouse0: Buttons: 11 (**) Mouse0: Sensitivity: 1 (II) XINPUT: Adding extended input device "Mouse0" (type: MOUSE) (**) Mouse0: (accel) keeping acceleration scheme 1 (**) Mouse0: (accel) filter chain progression: 2.00 (**) Mouse0: (accel) filter stage 0: 20.00 ms (**) Mouse0: (accel) set acceleration profile 0 (II) Mouse0: SetupAuto: hw.iftype is 4, hw.model is 0 (II) Mouse0: SetupAuto: protocol is SysMouse (**) Option "CoreKeyboard" (**) Keyboard0: always reports core events (**) Option "Protocol" "standard" (**) Keyboard0: Protocol: standard (**) Option "AutoRepeat" "500 30" (**) Option "XkbRules" "xorg" (**) Keyboard0: XkbRules: "xorg" (**) Option "XkbModel" "pc105" (**) Keyboard0: XkbModel: "pc105" (**) Option "XkbLayout" "us" (**) Keyboard0: XkbLayout: "us" (**) Option "CustomKeycodes" "off" (**) Keyboard0: CustomKeycodes disabled (II) XINPUT: Adding extended input device "Keyboard0" (type: KEYBOARD) Output DFP1 disable success Blank CRTC 0 success Disable CRTC 0 success Blank CRTC 1 success Disable CRTC 1 success Enable CRTC 0 success Unblank CRTC 0 success Output DFP1 enable success Enable CRTC 0 success Unblank CRTC 0 success Output DFP1 disable success Enable CRTC 0 success Unblank CRTC 0 success Output DFP1 enable success Output DFP1 disable success Blank CRTC 0 success Disable CRTC 0 success Blank CRTC 1 success Disable CRTC 1 success Enable CRTC 0 success Unblank CRTC 0 success Output DFP1 enable success Enable CRTC 0 success Unblank CRTC 0 success Output DFP1 disable success Enable CRTC 0 success Unblank CRTC 0 success Output DFP1 enable success Output DFP1 disable success Blank CRTC 0 success Disable CRTC 0 success Blank CRTC 1 success Disable CRTC 1 success Enable CRTC 0 success Unblank CRTC 0 success Output DFP1 enable success Enable CRTC 0 success Unblank CRTC 0 success Output DFP1 disable success Enable CRTC 0 success Unblank CRTC 0 success Output DFP1 enable success Output DFP1 disable success Blank CRTC 0 success Disable CRTC 0 success Blank CRTC 1 success Disable CRTC 1 success Enable CRTC 0 success Unblank CRTC 0 success Output DFP1 enable success Output DFP1 disable success Blank CRTC 0 success Disable CRTC 0 success Blank CRTC 1 success Disable CRTC 1 success Enable CRTC 0 success Unblank CRTC 0 success Output DFP1 enable success Output DFP1 disable success Blank CRTC 0 success Disable CRTC 0 success Blank CRTC 1 success Disable CRTC 1 success Enable CRTC 0 success Unblank CRTC 0 success Output DFP1 enable success Enable CRTC 0 success Unblank CRTC 0 success Output DFP1 disable success Enable CRTC 0 success Unblank CRTC 0 success Output DFP1 enable success Enable CRTC 0 success Unblank CRTC 0 success Output DFP1 disable success /var/log/messages: Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_indirect] idx=30 s=0 e=3288 d=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_dispatch_indirect] buf=30 s=0x0 e=0xcd8 Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc0406429, nr=0x29, dev 0xffffff0001b3f800, auth=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_freelist_get] done_age = 941502 Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc010644d, nr=0x4d, dev 0xffffff0001b3f800, auth=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_indirect] idx=31 s=0 e=1684 d=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_dispatch_indirect] buf=31 s=0x0 e=0x694 Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0x20006444, nr=0x44, dev 0xffffff0001b3f800, auth=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_idle] Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_do_cp_idle] Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0x20006444, nr=0x44, dev 0xffffff0001b3f800, auth=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_idle] Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_do_cp_idle] Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc0406429, nr=0x29, dev 0xffffff0001b3f800, auth=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_freelist_get] done_age = 941503 Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc010644d, nr=0x4d, dev 0xffffff0001b3f800, auth=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_indirect] idx=0 s=0 e=13260 d=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_dispatch_indirect] buf=0 s=0x0 e=0x33cc Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc0406429, nr=0x29, dev 0xffffff0001b3f800, auth=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_freelist_get] done_age = 941504 Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc010644d, nr=0x4d, dev 0xffffff0001b3f800, auth=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_indirect] idx=1 s=0 e=6084 d=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_dispatch_indirect] buf=1 s=0x0 e=0x17c4 Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc0406429, nr=0x29, dev 0xffffff0001b3f800, auth=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_freelist_get] done_age = 941505 Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc010644d, nr=0x4d, dev 0xffffff0001b3f800, auth=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_indirect] idx=2 s=0 e=1840 d=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_dispatch_indirect] buf=2 s=0x0 e=0x730 Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc0406429, nr=0x29, dev 0xffffff0001b3f800, auth=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_freelist_get] done_age = 941506 Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc010644d, nr=0x4d, dev 0xffffff0001b3f800, auth=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_indirect] idx=3 s=0 e=5152 d=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_dispatch_indirect] buf=3 s=0x0 e=0x1420 Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc0406429, nr=0x29, dev 0xffffff0001b3f800, auth=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_freelist_get] done_age = 941506 Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc010644d, nr=0x4d, dev 0xffffff0001b3f800, auth=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_indirect] idx=4 s=0 e=3288 d=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_dispatch_indirect] buf=4 s=0x0 e=0xcd8 Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc0406429, nr=0x29, dev 0xffffff0001b3f800, auth=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_freelist_get] done_age = 941508 Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc010644d, nr=0x4d, dev 0xffffff0001b3f800, auth=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_indirect] idx=5 s=0 e=3236 d=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_dispatch_indirect] buf=5 s=0x0 e=0xca4 Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc0406429, nr=0x29, dev 0xffffff0001b3f800, auth=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_freelist_get] done_age = 941509 Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc010644d, nr=0x4d, dev 0xffffff0001b3f800, auth=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_indirect] idx=6 s=0 e=1684 d=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_dispatch_indirect] buf=6 s=0x0 e=0x694 Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc0406429, nr=0x29, dev 0xffffff0001b3f800, auth=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_freelist_get] done_age = 941510 Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=68478, cmd=0xc010644d, nr=0x4d, dev 0xffffff0001b3f800, auth=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_indirect] idx=7 s=0 e=1736 d=1 Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_dispatch_indirect] buf=7 s=0x0 e=0x6c8 From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 11 12:06:46 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B9C91065719 for ; Sat, 11 Apr 2009 12:06:46 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout2.freenet.de (mout2.freenet.de [IPv6:2001:748:100:40::2:4]) by mx1.freebsd.org (Postfix) with ESMTP id CD0A88FC1B for ; Sat, 11 Apr 2009 12:06:45 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from [195.4.92.11] (helo=1.mx.freenet.de) by mout2.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #88) id 1Lsbyu-0002Eu-Kh; Sat, 11 Apr 2009 14:06:44 +0200 Received: from tbd17.t.pppool.de ([89.55.189.23]:56858 helo=ernst.jennejohn.org) by 1.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #79) id 1Lsbyu-0003LD-D2; Sat, 11 Apr 2009 14:06:44 +0200 Date: Sat, 11 Apr 2009 14:06:43 +0200 From: Gary Jennejohn To: xorquewasp@googlemail.com Message-ID: <20090411140643.35cc82ae@ernst.jennejohn.org> In-Reply-To: <20090411101559.GC83697@logik.internal.network> References: <20090410132354.GA20721@logik.internal.network> <20090410154251.GA49384@logik.internal.network> <1239385368.1922.74.camel@balrog.2hip.net> <20090410175922.GA50520@logik.internal.network> <1239388293.1922.80.camel@balrog.2hip.net> <20090410211307.GA83697@logik.internal.network> <3a142e750904101730k53b7fbabn6e801ac36f1182e0@mail.gmail.com> <20090411101559.GC83697@logik.internal.network> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, "Paul B. Mahol" Subject: Re: diagnosing freezes (DRI?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 12:06:49 -0000 On Sat, 11 Apr 2009 11:15:59 +0100 xorquewasp@googlemail.com wrote: > On 2009-04-11 02:30:40, Paul B. Mahol wrote: > > > > If it locks under X11 then use debug.debugger_on_panic=0 sysctl. > > Not doing this will increase drasticaly chances of locking whole system > > and not providing any debug data. > > I don't seem to have that sysctl. > > You sure that's the correct name? > It's definitely in 8-current. Seems to be set to 0 as default. --- Gary Jennejohn From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 11 13:38:31 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B58D0106566C for ; Sat, 11 Apr 2009 13:38:31 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by mx1.freebsd.org (Postfix) with ESMTP id 142AC8FC13 for ; Sat, 11 Apr 2009 13:38:30 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: by fxm11 with SMTP id 11so1428378fxm.43 for ; Sat, 11 Apr 2009 06:38:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:to:subject:references :organization:from:date:in-reply-to:message-id:user-agent :mime-version:content-type; bh=nrz/awDTk874KbpP3wv9uQNdPzGqx92E5tSr6EuZEIk=; b=YYPdP2kU16AWRSp+p+lzW42GIzlzWaan/2OIwUeDktGU6s0NTkfxCe/jf8YIOKIIHv dGqloI2KAosNTcy0RBDlVDIAEwzUYiGPEipZ9N2I+wuLNeXhrGWFBccsiNnDXxDXiree BqypGc2d54XzAuJrFvoJNJORXaH6dq43Kan5Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=to:subject:references:organization:from:date:in-reply-to:message-id :user-agent:mime-version:content-type; b=lRVo6ZOhB15yj1AzKDQKmu9kI4ilWsO2hD20Bnwu7VxO+ZmMAoHx8LCsSTaFmx9DnU pcSZRd6/VXobg1ktYhESms5paHyrblReRVLRnhokROf5EjzrcgajYPD2/3c5kDOVGLTr dvquG7nz7ewrmcMuaZyvNlyGcB/LElKigyA4g= Received: by 10.103.213.19 with SMTP id p19mr2348613muq.9.1239455567639; Sat, 11 Apr 2009 06:12:47 -0700 (PDT) Received: from localhost (vpn-195-69-246-114.customer.onet.com.ua [195.69.246.114]) by mx.google.com with ESMTPS id j6sm5302513mue.4.2009.04.11.06.12.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 11 Apr 2009 06:12:46 -0700 (PDT) To: xorquewasp@googlemail.com, freebsd-hackers@freebsd.org References: <20090410132354.GA20721@logik.internal.network> <20090410154251.GA49384@logik.internal.network> <1239385368.1922.74.camel@balrog.2hip.net> <20090410175922.GA50520@logik.internal.network> <1239388293.1922.80.camel@balrog.2hip.net> <20090410211307.GA83697@logik.internal.network> <3a142e750904101730k53b7fbabn6e801ac36f1182e0@mail.gmail.com> <20090411101559.GC83697@logik.internal.network> Organization: TOA Ukraine From: Mikolaj Golub Date: Sat, 11 Apr 2009 16:12:45 +0300 In-Reply-To: <20090411101559.GC83697@logik.internal.network> (xorquewasp@googlemail.com's message of "Sat\, 11 Apr 2009 11\:15\:59 +0100") Message-ID: <86zlen9vw2.fsf@kopusha.onet> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: Re: diagnosing freezes (DRI?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 13:38:32 -0000 On Sat, 11 Apr 2009 11:15:59 +0100 xorquewasp@googlemail.com wrote: x> On 2009-04-11 02:30:40, Paul B. Mahol wrote: >> >> If it locks under X11 then use debug.debugger_on_panic=0 sysctl. >> Not doing this will increase drasticaly chances of locking whole system >> and not providing any debug data. x> I don't seem to have that sysctl. You will see this sysctl only if you build your kernel with ddb(4) support. If you are interested in providing useful information about your freezes, please read the following: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html You need to build your kernel with options described in http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-online-ddb.html and http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html As you run X, you need to have debug.debugger_on_panic=0 set (as Paul has suggested). Otherwise ddb would enter on panic but you wouldn't be able to access it due to X. After panic you will be able to get useful information from generated core dump using kgdb. Another option is to set debug.debugger_on_panic=1 but also set some ddb script that will run when the kernel debugger is entered as a result of a panic. This script will enable output capture, dump some useful debugging info to capture buffer, and then force a kernel dump to be written out followed by a reboot. E.g. running something like this will do the trick: ddb script 'kdb.enter.panic=capture on; show pcpu; show allpcpu; bt; ps; show locks; show alllocks; show lockedvnods; alltrace; call doadump; reset' After reboot you can extract captured information from the capture buffer information using the command: ddb capture -M /var/crash/vmcore.X print > ddb.out You need to increase the value of debug.ddb.capture.bufsize sysctl variable to make sure all ddb output will be captured. You can read more about this in ddb(4), ddb(8), textdump(4). -- Mikolaj Golub From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 11 15:21:52 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEB541065675 for ; Sat, 11 Apr 2009 15:21:52 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8EF068FC21 for ; Sat, 11 Apr 2009 15:21:52 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 4964E46B85; Sat, 11 Apr 2009 11:21:52 -0400 (EDT) Date: Sat, 11 Apr 2009 16:21:52 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andrew Brampton In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD memguard + spinlocks X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 15:21:53 -0000 On Sat, 11 Apr 2009, Andrew Brampton wrote: > I'm having a problem with memguard(9) on FreeBSD 7.1 but before I ask about > that I just need to check my facts about malloc. > > When in interrupt context malloc must be called with M_NOWAIT, this is > because I can't sleep inside a interrupt. Now when I hold a spinlock > (MTX_SPIN) I am also not allowed to sleep or obtain a sleepable mutex (such > as MTX_DEF). So I assume while holding a spin lock any mallocs I do must > have the M_NOWAIT flag? This was not clear from the manual pages, but at > least makes sense to me. > > So my problem with memguard stems from the fact that I am locking a > spinlock, and then I'm calling malloc with M_NOWAIT. But inside > memguard_alloc a MTX_DEF is acquired causing WITNESS to panic. > > So I think fundamental memguard is flawed and should be using MTX_SPIN > instead of MTX_DEF otherwise it can't be called from inside a interrupt or > when a spin lock is held. But maybe I'm missing something? > > Also on a related note, I see that MTX_SPIN disables interrupts, making it a > rather "heavy" spinlock. Is there a lighter spin lock that literally just > spins? I read that MTX_DEF are far quicker to acquire , but surely a light > spinlock would be easier to acquire than sleeping? > > I think for the moment I will fix my code by not using a MTX_SPIN (since the > code is not in a interrupt), however, I think memguard should change its > lock. Your understanding is mostly right. The missing bit is this: there are two kinds of interrupt contexts -- fast/filter interrupt handlers, which borrow the stack and execution context of the kernel thread they preempt, and interrupt threads, which get their own complete thread context. Fast interrupt handlers are allowed unlock to acquire spinlocks so as to avoid deadlock because of the borrowed context. This means they can't perform any sort of sleep, or acquire any locks that might sleep, since the thread they've preempted may hold conflicting locks, or be the one that would have woken up the sleep that the handler performed. Almost no code will run in fast handlers -- perhaps checking some device registers, doing work on a lockless or spinlock-protected queue, and waking up a worker thread. This is why, BTW, spin locks disable interrupt: they need to control preemption by other interrupt handlers to avoid deadlock, but they are not intended for use except when either in the scheduler, in a few related IPI contexts, or when synchronizing between normal kernel code and a fast handler. Full interrupt thread contexts are permitted to perform short lock sleeps, such as those performed when contending default mutexes, rwlocks, and rmlocks. They are permitted to invoke kernel services such as malloc(9), UMA(9), the network stack, etc, as long as they use M_NOWAIT and don't invoke msleep(9) or similar unbounded sleeps -- again to avoid the possibility of deadlocks, since you don't want an interrupt thread sleeping waiting for an event that only it can satisfy. So the first question, really, is whether you are or mean to be using fast/filter interrupt handler. Device drivers will never call memory allocation, free, etc, from there, but will defer it to an ithread using the filter mechanism in 8.x, or to a task queue or other worker in 7.x and earlier. If you're using a regular INTR_MPSAFE ithread, you should be able to use only default mutexes (a single atomic operation if uncontended) without disabling interrupts, etc. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 11 19:12:14 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81B87106564A for ; Sat, 11 Apr 2009 19:12:14 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 21A1A8FC13 for ; Sat, 11 Apr 2009 19:12:14 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-1-210-55.bna.bellsouth.net [65.1.210.55]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n3BJAr95084273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Apr 2009 15:10:53 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: xorquewasp@googlemail.com In-Reply-To: <20090411102300.GD83697@logik.internal.network> References: <20090410132354.GA20721@logik.internal.network> <20090410154251.GA49384@logik.internal.network> <1239385368.1922.74.camel@balrog.2hip.net> <20090410175922.GA50520@logik.internal.network> <1239388293.1922.80.camel@balrog.2hip.net> <20090411102300.GD83697@logik.internal.network> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-NiQTX7SfpGcYRmHNHJzD" Organization: FreeBSD Date: Sat, 11 Apr 2009 14:11:15 -0500 Message-Id: <1239477075.1932.5.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.0 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RCVD_IN_SORBS_DUL,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-hackers@freebsd.org Subject: Re: diagnosing freezes (DRI?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 19:12:14 -0000 --=-NiQTX7SfpGcYRmHNHJzD Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2009-04-11 at 11:23 +0100, xorquewasp@googlemail.com wrote: > The machine ran for hours, apparently. I ended up going to > bed and leaving it running. Woke up to find it on display > sleep, frozen. Are you running the 7.2-PRE or -STABLE? There are a few relevant fixes in -STABLE that didn't make it into the pre-release. robert. > It didn't panic, apparently. >=20 > I've included Xorg.0.log and the last few lines of /var/log/messages > but I don't believe they show anything very interesting. >=20 > I should point out that this card is the dual-DVI version. I'm not > sure if that's relevant (I think it's just less common). I'm only > using one screen, currently. >=20 > /var/log/Xorg.0.log: >=20 > X.Org X Server 1.6.0 > Release Date: 2009-2-25 > X Protocol Version 11, Revision 0 > Build Operating System: FreeBSD 7.2-PRERELEASE amd64=20 > Current Operating System: FreeBSD viper.internal.network 7.2-PRERELEASE F= reeBSD 7.2-PRERELEASE #0: Fri Apr 10 00:09:48 BST 2009 root@viper.inter= nal.network:/usr/obj/usr/src/sys/GENERIC amd64 > Build Date: 11 April 2009 04:34:30AM > =20 > Before reporting problems, check http://wiki.x.org > to make sure that you have the latest version. > Markers: (--) probed, (**) from config file, (=3D=3D) default setting, > (++) from command line, (!!) notice, (II) informational, > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > (=3D=3D) Log file: "/var/log/Xorg.0.log", Time: Sat Apr 11 06:16:46 2009 > (=3D=3D) Using config file: "/etc/X11/xorg.conf" > (=3D=3D) ServerLayout "X.org Configured" > (**) |-->Screen "Screen0" (0) > (**) | |-->Monitor "Monitor0" > (**) | |-->Device "Card0" > (**) |-->Input Device "Mouse0" > (**) |-->Input Device "Keyboard0" > (=3D=3D) Not automatically adding devices > (=3D=3D) Not automatically enabling devices > (WW) The directory "/usr/local/lib/X11/fonts/TTF/" does not exist. > Entry deleted from font path. > (WW) The directory "/usr/local/lib/X11/fonts/OTF" does not exist. > Entry deleted from font path. > (WW) The directory "/usr/local/lib/X11/fonts/Type1/" does not exist. > Entry deleted from font path. > (WW) The directory "/usr/local/lib/X11/fonts/TTF/" does not exist. > Entry deleted from font path. > (WW) The directory "/usr/local/lib/X11/fonts/OTF" does not exist. > Entry deleted from font path. > (WW) The directory "/usr/local/lib/X11/fonts/Type1/" does not exist. > Entry deleted from font path. > (**) FontPath set to: > /usr/local/lib/X11/fonts/misc/, > /usr/local/lib/X11/fonts/100dpi/, > /usr/local/lib/X11/fonts/75dpi/, > /usr/local/lib/X11/fonts/misc/, > /usr/local/lib/X11/fonts/100dpi/, > /usr/local/lib/X11/fonts/75dpi/, > built-ins > (**) ModulePath set to "/usr/local/lib/xorg/modules" > (II) Loader magic: 0xd20 > (II) Module ABI versions: > X.Org ANSI C Emulation: 0.4 > X.Org Video Driver: 5.0 > X.Org XInput driver : 4.0 > X.Org Server Extension : 2.0 > (II) Loader running on freebsd > (--) Using syscons driver with X support (version 134217730.0) > (--) using VT number 9 >=20 > (--) PCI:*(0@6:0:0) ATI Technologies Inc RV570 [Radeon X1950 Pro] rev 154= , Mem @ 0xd0000000/268435456, 0xfbee0000/65536, I/O @ 0x0000e000/256, BIOS = @ 0x????????/65536 > (--) PCI: (0@6:0:1) ATI Technologies Inc RV570 [Radeon X1950 Pro] (second= ary) rev 154, Mem @ 0xfbef0000/65536 > (II) System resource ranges: > [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] > [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] > [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] > [3] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] > [4] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] > (II) "extmod" will be loaded. This was enabled by default and also specif= ied in the config file. > (II) "dbe" will be loaded. This was enabled by default and also specified= in the config file. > (II) "glx" will be loaded. This was enabled by default and also specified= in the config file. > (II) "record" will be loaded. This was enabled by default and also specif= ied in the config file. > (II) "dri" will be loaded. This was enabled by default and also specified= in the config file. > (II) "dri2" will be loaded. This was enabled by default and also specifie= d in the config file. > (II) LoadModule: "extmod" > (II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so > (II) Module extmod: vendor=3D"X.Org Foundation" > compiled for 1.6.0, module version =3D 1.0.0 > Module class: X.Org Server Extension > ABI class: X.Org Server Extension, version 2.0 > (II) Loading extension MIT-SCREEN-SAVER > (II) Loading extension XFree86-VidModeExtension > (II) Loading extension XFree86-DGA > (II) Loading extension DPMS > (II) Loading extension XVideo > (II) Loading extension XVideo-MotionCompensation > (II) Loading extension X-Resource > (II) LoadModule: "record" > (II) Loading /usr/local/lib/xorg/modules/extensions//librecord.so > (II) Module record: vendor=3D"X.Org Foundation" > compiled for 1.6.0, module version =3D 1.13.0 > Module class: X.Org Server Extension > ABI class: X.Org Server Extension, version 2.0 > (II) Loading extension RECORD > (II) LoadModule: "dbe" > (II) Loading /usr/local/lib/xorg/modules/extensions//libdbe.so > (II) Module dbe: vendor=3D"X.Org Foundation" > compiled for 1.6.0, module version =3D 1.0.0 > Module class: X.Org Server Extension > ABI class: X.Org Server Extension, version 2.0 > (II) Loading extension DOUBLE-BUFFER > (II) LoadModule: "glx" > (II) Loading /usr/local/lib/xorg/modules/extensions//libglx.so > (II) Module glx: vendor=3D"X.Org Foundation" > compiled for 1.6.0, module version =3D 1.0.0 > ABI class: X.Org Server Extension, version 2.0 > (=3D=3D) AIGLX disabled > (II) Loading extension GLX > (II) LoadModule: "dri" > (II) Loading /usr/local/lib/xorg/modules/extensions//libdri.so > (II) Module dri: vendor=3D"X.Org Foundation" > compiled for 1.6.0, module version =3D 1.0.0 > ABI class: X.Org Server Extension, version 2.0 > (II) Loading extension XFree86-DRI > (II) LoadModule: "dri2" > (II) Loading /usr/local/lib/xorg/modules/extensions//libdri2.so > (II) Module dri2: vendor=3D"X.Org Foundation" > compiled for 1.6.0, module version =3D 1.0.0 > ABI class: X.Org Server Extension, version 2.0 > (II) Loading extension DRI2 > (II) LoadModule: "radeon" > (II) Loading /usr/local/lib/xorg/modules/drivers//radeon_drv.so > (II) Module radeon: vendor=3D"X.Org Foundation" > compiled for 1.6.0, module version =3D 6.12.2 > Module class: X.Org Video Driver > ABI class: X.Org Video Driver, version 5.0 > (II) LoadModule: "mouse" > (II) Loading /usr/local/lib/xorg/modules/input//mouse_drv.so > (II) Module mouse: vendor=3D"X.Org Foundation" > compiled for 1.6.0, module version =3D 1.4.0 > Module class: X.Org XInput Driver > ABI class: X.Org XInput driver, version 4.0 > (II) LoadModule: "kbd" > (II) Loading /usr/local/lib/xorg/modules/input//kbd_drv.so > (II) Module kbd: vendor=3D"X.Org Foundation" > compiled for 1.6.0, module version =3D 1.3.2 > Module class: X.Org XInput Driver > ABI class: X.Org XInput driver, version 4.0 > (II) RADEON: Driver for ATI Radeon chipsets: > ATI Radeon Mobility X600 (M24) 3150 (PCIE), ATI FireMV 2400 (PCI), > ATI Radeon Mobility X300 (M24) 3152 (PCIE), > ATI FireGL M24 GL 3154 (PCIE), ATI Radeon X600 (RV380) 3E50 (PCIE), > ATI FireGL V3200 (RV380) 3E54 (PCIE), ATI Radeon IGP320 (A3) 4136, > ATI Radeon IGP330/340/350 (A4) 4137, ATI Radeon 9500 AD (AGP), > ATI Radeon 9500 AE (AGP), ATI Radeon 9600TX AF (AGP), > ATI FireGL Z1 AG (AGP), ATI Radeon 9800SE AH (AGP), > ATI Radeon 9800 AI (AGP), ATI Radeon 9800 AJ (AGP), > ATI FireGL X2 AK (AGP), ATI Radeon 9600 AP (AGP), > ATI Radeon 9600SE AQ (AGP), ATI Radeon 9600XT AR (AGP), > ATI Radeon 9600 AS (AGP), ATI FireGL T2 AT (AGP), ATI Radeon 9650, > ATI FireGL RV360 AV (AGP), ATI Radeon 7000 IGP (A4+) 4237, > ATI Radeon 8500 AIW BB (AGP), ATI Radeon 8500 AIW BC (AGP), > ATI Radeon IGP320M (U1) 4336, ATI Radeon IGP330M/340M/350M (U2) 4337, > ATI Radeon Mobility 7000 IGP 4437, ATI Radeon 9000/PRO If (AGP/PCI), > ATI Radeon 9000 Ig (AGP/PCI), ATI Radeon X800 (R420) JH (AGP), > ATI Radeon X800PRO (R420) JI (AGP), > ATI Radeon X800SE (R420) JJ (AGP), ATI Radeon X800 (R420) JK (AGP), > ATI Radeon X800 (R420) JL (AGP), ATI FireGL X3 (R420) JM (AGP), > ATI Radeon Mobility 9800 (M18) JN (AGP), > ATI Radeon X800 SE (R420) (AGP), ATI Radeon X800XT (R420) JP (AGP), > ATI Radeon X850 XT (R480) (AGP), ATI Radeon X850 SE (R480) (AGP), > ATI Radeon X850 PRO (R480) (AGP), ATI Radeon X850 XT PE (R480) (AGP), > ATI Radeon Mobility M7 LW (AGP), > ATI Mobility FireGL 7800 M7 LX (AGP), > ATI Radeon Mobility M6 LY (AGP), ATI Radeon Mobility M6 LZ (AGP), > ATI FireGL Mobility 9000 (M9) Ld (AGP), > ATI Radeon Mobility 9000 (M9) Lf (AGP), > ATI Radeon Mobility 9000 (M9) Lg (AGP), ATI Radeon 9700 Pro ND (AGP), > ATI Radeon 9700/9500Pro NE (AGP), ATI Radeon 9600TX NF (AGP), > ATI FireGL X1 NG (AGP), ATI Radeon 9800PRO NH (AGP), > ATI Radeon 9800 NI (AGP), ATI FireGL X2 NK (AGP), > ATI Radeon 9800XT NJ (AGP), > ATI Radeon Mobility 9600/9700 (M10/M11) NP (AGP), > ATI Radeon Mobility 9600 (M10) NQ (AGP), > ATI Radeon Mobility 9600 (M11) NR (AGP), > ATI Radeon Mobility 9600 (M10) NS (AGP), > ATI FireGL Mobility T2 (M10) NT (AGP), > ATI FireGL Mobility T2e (M11) NV (AGP), ATI Radeon QD (AGP), > ATI Radeon QE (AGP), ATI Radeon QF (AGP), ATI Radeon QG (AGP), > ATI FireGL 8700/8800 QH (AGP), ATI Radeon 8500 QL (AGP), > ATI Radeon 9100 QM (AGP), ATI Radeon 7500 QW (AGP/PCI), > ATI Radeon 7500 QX (AGP/PCI), ATI Radeon VE/7000 QY (AGP/PCI), > ATI Radeon VE/7000 QZ (AGP/PCI), ATI ES1000 515E (PCI), > ATI Radeon Mobility X300 (M22) 5460 (PCIE), > ATI Radeon Mobility X600 SE (M24C) 5462 (PCIE), > ATI FireGL M22 GL 5464 (PCIE), ATI Radeon X800 (R423) UH (PCIE), > ATI Radeon X800PRO (R423) UI (PCIE), > ATI Radeon X800LE (R423) UJ (PCIE), > ATI Radeon X800SE (R423) UK (PCIE), > ATI Radeon X800 XTP (R430) (PCIE), ATI Radeon X800 XL (R430) (PCIE), > ATI Radeon X800 SE (R430) (PCIE), ATI Radeon X800 (R430) (PCIE), > ATI FireGL V7100 (R423) (PCIE), ATI FireGL V5100 (R423) UQ (PCIE), > ATI FireGL unknown (R423) UR (PCIE), > ATI FireGL unknown (R423) UT (PCIE), > ATI Mobility FireGL V5000 (M26) (PCIE), > ATI Mobility FireGL V5000 (M26) (PCIE), > ATI Mobility Radeon X700 XL (M26) (PCIE), > ATI Mobility Radeon X700 (M26) (PCIE), > ATI Mobility Radeon X700 (M26) (PCIE), > ATI Radeon X550XTX 5657 (PCIE), ATI Radeon 9100 IGP (A5) 5834, > ATI Radeon Mobility 9100 IGP (U3) 5835, > ATI Radeon XPRESS 200 5954 (PCIE), > ATI Radeon XPRESS 200M 5955 (PCIE), ATI Radeon 9250 5960 (AGP), > ATI Radeon 9200 5961 (AGP), ATI Radeon 9200 5962 (AGP), > ATI Radeon 9200SE 5964 (AGP), ATI FireMV 2200 (PCI), > ATI ES1000 5969 (PCI), ATI Radeon XPRESS 200 5974 (PCIE), > ATI Radeon XPRESS 200M 5975 (PCIE), > ATI Radeon XPRESS 200 5A41 (PCIE), > ATI Radeon XPRESS 200M 5A42 (PCIE), > ATI Radeon XPRESS 200 5A61 (PCIE), > ATI Radeon XPRESS 200M 5A62 (PCIE), > ATI Radeon X300 (RV370) 5B60 (PCIE), > ATI Radeon X600 (RV370) 5B62 (PCIE), > ATI Radeon X550 (RV370) 5B63 (PCIE), > ATI FireGL V3100 (RV370) 5B64 (PCIE), > ATI FireMV 2200 PCIE (RV370) 5B65 (PCIE), > ATI Radeon Mobility 9200 (M9+) 5C61 (AGP), > ATI Radeon Mobility 9200 (M9+) 5C63 (AGP), > ATI Mobility Radeon X800 XT (M28) (PCIE), > ATI Mobility FireGL V5100 (M28) (PCIE), > ATI Mobility Radeon X800 (M28) (PCIE), ATI Radeon X850 5D4C (PCIE), > ATI Radeon X850 XT PE (R480) (PCIE), > ATI Radeon X850 SE (R480) (PCIE), ATI Radeon X850 PRO (R480) (PCIE), > ATI unknown Radeon / FireGL (R480) 5D50 (PCIE), > ATI Radeon X850 XT (R480) (PCIE), > ATI Radeon X800XT (R423) 5D57 (PCIE), > ATI FireGL V5000 (RV410) (PCIE), ATI Radeon X700 XT (RV410) (PCIE), > ATI Radeon X700 PRO (RV410) (PCIE), > ATI Radeon X700 SE (RV410) (PCIE), ATI Radeon X700 (RV410) (PCIE), > ATI Radeon X700 SE (RV410) (PCIE), ATI Radeon X1800, > ATI Mobility Radeon X1800 XT, ATI Mobility Radeon X1800, > ATI Mobility FireGL V7200, ATI FireGL V7200, ATI FireGL V5300, > ATI Mobility FireGL V7100, ATI Radeon X1800, ATI Radeon X1800, > ATI Radeon X1800, ATI Radeon X1800, ATI Radeon X1800, > ATI FireGL V7300, ATI FireGL V7350, ATI Radeon X1600, ATI RV505, > ATI Radeon X1300/X1550, ATI Radeon X1550, ATI M54-GL, > ATI Mobility Radeon X1400, ATI Radeon X1300/X1550, > ATI Radeon X1550 64-bit, ATI Mobility Radeon X1300, > ATI Mobility Radeon X1300, ATI Mobility Radeon X1300, > ATI Mobility Radeon X1300, ATI Radeon X1300, ATI Radeon X1300, > ATI RV505, ATI RV505, ATI FireGL V3300, ATI FireGL V3350, > ATI Radeon X1300, ATI Radeon X1550 64-bit, ATI Radeon X1300/X1550, > ATI Radeon X1600, ATI Radeon X1300/X1550, ATI Mobility Radeon X1450, > ATI Radeon X1300/X1550, ATI Mobility Radeon X2300, > ATI Mobility Radeon X2300, ATI Mobility Radeon X1350, > ATI Mobility Radeon X1350, ATI Mobility Radeon X1450, > ATI Radeon X1300, ATI Radeon X1550, ATI Mobility Radeon X1350, > ATI FireMV 2250, ATI Radeon X1550 64-bit, ATI Radeon X1600, > ATI Radeon X1650, ATI Radeon X1600, ATI Radeon X1600, > ATI Mobility FireGL V5200, ATI Mobility Radeon X1600, > ATI Radeon X1650, ATI Radeon X1650, ATI Radeon X1600, > ATI Radeon X1300 XT/X1600 Pro, ATI FireGL V3400, > ATI Mobility FireGL V5250, ATI Mobility Radeon X1700, > ATI Mobility Radeon X1700 XT, ATI FireGL V5200, > ATI Mobility Radeon X1700, ATI Radeon X2300HD, > ATI Mobility Radeon HD 2300, ATI Mobility Radeon HD 2300, > ATI Radeon X1950, ATI Radeon X1900, ATI Radeon X1950, > ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, > ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, > ATI Radeon X1900, ATI Radeon X1900, ATI Radeon X1900, > ATI AMD Stream Processor, ATI Radeon X1900, ATI Radeon X1950, > ATI RV560, ATI RV560, ATI Mobility Radeon X1900, ATI RV560, > ATI Radeon X1950 GT, ATI RV570, ATI RV570, ATI FireGL V7400, > ATI RV560, ATI Radeon X1650, ATI Radeon X1650, ATI RV560, > ATI Radeon 9100 PRO IGP 7834, ATI Radeon Mobility 9200 IGP 7835, > ATI Radeon X1200, ATI Radeon X1200, ATI Radeon X1200, > ATI Radeon X1200, ATI Radeon X1200, ATI RS740, ATI RS740M, ATI RS740, > ATI RS740M, ATI Radeon HD 2900 XT, ATI Radeon HD 2900 XT, > ATI Radeon HD 2900 XT, ATI Radeon HD 2900 Pro, ATI Radeon HD 2900 GT, > ATI FireGL V8650, ATI FireGL V8600, ATI FireGL V7600, > ATI Radeon 4800 Series, ATI Radeon HD 4870 x2, > ATI Radeon 4800 Series, ATI FirePro V8750 (FireGL), > ATI FirePro V7760 (FireGL), ATI Mobility RADEON HD 4850, > ATI Mobility RADEON HD 4850 X2, ATI Radeon 4800 Series, > ATI FirePro RV770, AMD FireStream 9270, AMD FireStream 9250, > ATI FirePro V8700 (FireGL), ATI Mobility RADEON HD 4870, > ATI Mobility RADEON M98, ATI Radeon 4800 Series, > ATI Radeon 4800 Series, ATI FirePro M7750, ATI M98, ATI M98, ATI M98, > ATI Radeon RV730 (AGP), ATI FirePro M5750, ATI Radeon RV730 (AGP), > ATI RV730XT [Radeon HD 4670], ATI RADEON E4600, > ATI RV730 PRO [Radeon HD 4650], ATI FirePro V7750 (FireGL), > ATI FirePro V5700 (FireGL), ATI FirePro V3750 (FireGL), ATI RV610, > ATI Radeon HD 2400 XT, ATI Radeon HD 2400 Pro, > ATI Radeon HD 2400 PRO AGP, ATI FireGL V4000, ATI RV610, > ATI Radeon HD 2350, ATI Mobility Radeon HD 2400 XT, > ATI Mobility Radeon HD 2400, ATI RADEON E2400, ATI RV610, > ATI FireMV 2260, ATI RV670, ATI Radeon HD3870, > ATI Mobility Radeon HD 3850, ATI Radeon HD3850, > ATI Mobility Radeon HD 3850 X2, ATI RV670, > ATI Mobility Radeon HD 3870, ATI Mobility Radeon HD 3870 X2, > ATI Radeon HD3870 X2, ATI FireGL V7700, ATI Radeon HD3850, > ATI Radeon HD3690, AMD Firestream 9170, ATI Radeon HD 4550, > ATI Radeon RV710, ATI Radeon RV710, ATI Radeon HD 4350, > ATI Mobility Radeon 4300 Series, ATI Mobility Radeon 4500 Series, > ATI Mobility Radeon 4500 Series, ATI RV630, > ATI Mobility Radeon HD 2600, ATI Mobility Radeon HD 2600 XT, > ATI Radeon HD 2600 XT AGP, ATI Radeon HD 2600 Pro AGP, > ATI Radeon HD 2600 XT, ATI Radeon HD 2600 Pro, ATI Gemini RV630, > ATI Gemini Mobility Radeon HD 2600 XT, ATI FireGL V5600, > ATI FireGL V3600, ATI Radeon HD 2600 LE, > ATI Mobility FireGL Graphics Processor, ATI Radeon RV710, > ATI Radeon HD 3470, ATI Mobility Radeon HD 3430, > ATI Mobility Radeon HD 3400 Series, ATI Radeon HD 3450, > ATI Radeon HD 3450, ATI Radeon HD 3430, ATI Radeon HD 3450, > ATI FirePro V3700, ATI FireMV 2450, ATI FireMV 2260, ATI FireMV 2260, > ATI Radeon HD 3600 Series, ATI Radeon HD 3650 AGP, > ATI Radeon HD 3600 PRO, ATI Radeon HD 3600 XT, > ATI Radeon HD 3600 PRO, ATI Mobility Radeon HD 3650, > ATI Mobility Radeon HD 3670, ATI Mobility FireGL V5700, > ATI Mobility FireGL V5725, ATI Radeon HD 3200 Graphics, > ATI Radeon 3100 Graphics, ATI Radeon HD 3200 Graphics, > ATI Radeon 3100 Graphics, ATI Radeon HD 3300 Graphics, > ATI Radeon HD 3200 Graphics, ATI Radeon 3000 Graphics, > ATI Radeon HD Graphics, ATI Radeon Graphics, > ATI Mobility Radeon HD Graphics, ATI Mobility Radeon Graphics, > ATI Radeon Graphics > (II) Primary Device is: PCI 06@00:00:0 > (II) resource ranges after xf86ClaimFixedResources() call: > [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] > [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] > [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] > [3] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] > [4] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] > (II) resource ranges after probing: > [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] > [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] > [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] > [3] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B] > [4] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] > [5] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B] > [6] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] > [7] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] > [8] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B] > [9] 0 0 0x000003c0 - 0x000003df (0x20) IS[B] > (II) Setting vga for screen 0. > (II) RADEON(0): TOTO SAYS 00000000fbee0000 > (II) RADEON(0): MMIO registers at 0x00000000fbee0000: size 64KB > (II) RADEON(0): PCI bus 6 card 0 func 0 > (=3D=3D) RADEON(0): Depth 24, (--) framebuffer bpp 32 > (II) RADEON(0): Pixel depth =3D 24 bits stored in 4 bytes (32 bpp pixmaps= ) > (=3D=3D) RADEON(0): Default visual is TrueColor > (II) Loading sub module "vgahw" > (II) LoadModule: "vgahw" > (II) Loading /usr/local/lib/xorg/modules//libvgahw.so > (II) Module vgahw: vendor=3D"X.Org Foundation" > compiled for 1.6.0, module version =3D 0.1.0 > ABI class: X.Org Video Driver, version 5.0 > (II) RADEON(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is = 0x0000 > (=3D=3D) RADEON(0): RGB weight 888 > (II) RADEON(0): Using 8 bits per RGB (8 bit DAC) > (--) RADEON(0): Chipset: "ATI Radeon X1950" (ChipID =3D 0x7280) > (WW) RADEON(0): R500 support is under development. Please report any issu= es to xorg-driver-ati@lists.x.org > (--) RADEON(0): Linear framebuffer at 0x00000000d0000000 > (II) RADEON(0): PCIE card detected > (II) Loading sub module "int10" > (II) LoadModule: "int10" > (II) Loading /usr/local/lib/xorg/modules//libint10.so > (II) Module int10: vendor=3D"X.Org Foundation" > compiled for 1.6.0, module version =3D 1.0.0 > ABI class: X.Org Video Driver, version 5.0 > (II) RADEON(0): initializing int10 > (=3D=3D) RADEON(0): Write-combining range (0xa0000,0x20000) was already c= lear > (=3D=3D) RADEON(0): Write-combining range (0xc0000,0x40000) was already c= lear > (II) RADEON(0): Primary V_BIOS segment is: 0xc000 > (=3D=3D) RADEON(0): Write-combining range (0x0,0x1000) was already clear > (II) RADEON(0): ATOM BIOS detected > (II) RADEON(0): ATOM BIOS Rom:=20 > SubsystemVendorID: 0x148c SubsystemID: 0x2204 > IOBaseAddress: 0xe000 > Filename: 64125LAB.SEF > BIOS Bootup Message:=20 > RV570XT DDR3 256MB 64125LAB.SEF V9.13.1.12 = =20 > =20 > (II) RADEON(0): Framebuffer space used by Firmware (kb): 20 > (II) RADEON(0): Start of VRAM area used by Firmware: 0xfffb000 > (II) RADEON(0): AtomBIOS requests 20kB of VRAM scratch space > (II) RADEON(0): AtomBIOS VRAM scratch base: 0xfffb000 > (II) RADEON(0): Cannot get VRAM scratch space. Allocating in main memory = instead > (II) RADEON(0): Default Engine Clock: 600000 > (II) RADEON(0): Default Memory Clock: 700000 > (II) RADEON(0): Maximum Pixel ClockPLL Frequency Output: 1100000 > (II) RADEON(0): Minimum Pixel ClockPLL Frequency Output: 0 > (II) RADEON(0): Maximum Pixel ClockPLL Frequency Input: 13500 > (II) RADEON(0): Minimum Pixel ClockPLL Frequency Input: 1000 > (II) RADEON(0): Maximum Pixel Clock: 400000 > (II) RADEON(0): Reference Clock: 27000 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 10, (OK) > drmOpenByBusid: Searching for BusID pci:0000:06:00.0 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 10, (OK) > drmOpenByBusid: drmOpenMinor returns 10 > drmOpenByBusid: drmGetBusid reports pci:0000:06:00.0 > (II) RADEON(0): [dri] Found DRI library version 1.3.0 and kernel module v= ersion 1.29.0 > (=3D=3D) RADEON(0): Page Flipping disabled on r5xx and newer chips. >=20 > (II) RADEON(0): Will try to use DMA for Xv image transfers > (II) RADEON(0): Generation 2 PCI interface, using max accessible memory > (II) RADEON(0): Detected total video RAM=3D262144K, accessible=3D262144K = (PCI BAR=3D262144K) > (--) RADEON(0): Mapped VideoRAM: 262144 kByte (256 bit DDR SDRAM) > (II) RADEON(0): Color tiling enabled by default > (II) RADEON(0): Max desktop size set to 2560x1600 > (II) RADEON(0): For a larger or smaller max desktop size, add a Virtual l= ine to your xorg.conf > (II) RADEON(0): If you are having trouble with 3D, reduce the desktop siz= e by adjusting the Virtual line to your xorg.conf > (II) Loading sub module "ddc" > (II) LoadModule: "ddc" > (II) Module "ddc" already built-in > (II) Loading sub module "i2c" > (II) LoadModule: "i2c" > (II) Module "i2c" already built-in > (II) RADEON(0): ref_freq: 2700, min_out_pll: 64800, max_out_pll: 110000, = min_in_pll: 100, max_in_pll: 1350, xclk: 40000, sclk: 600.000000, mclk: 700= .000000 > (II) RADEON(0): PLL parameters: rf=3D2700 rd=3D13 min=3D64800 max=3D11000= 0; xclk=3D40000 > (II) RADEON(0): Skipping TV-Out > (II) RADEON(0): Skipping Component Video > encoder: 0x15 > encoder: 0x13 > encoder: 0x16 > encoder: 0xf > (II) RADEON(0): Output DVI-1 using monitor section Monitor0 > (II) RADEON(0): I2C bus "DVI-1" initialized. > (II) RADEON(0): Output DVI-0 has no monitor section > (II) RADEON(0): I2C bus "DVI-0" initialized. > (II) RADEON(0): Port0: > XRANDR name: DVI-1 > Connector: DVI-I > CRT2: INTERNAL_KLDSCP_DAC2 > DFP1: INTERNAL_KLDSCP_TMDS1 > DDC reg: 0x7e50 > (II) RADEON(0): Port1: > XRANDR name: DVI-0 > Connector: DVI-I > CRT1: INTERNAL_KLDSCP_DAC1 > DFP3: INTERNAL_LVTM1 > DDC reg: 0x7e40 > (II) RADEON(0): I2C device "DVI-1:E-EDID segment register" registered at = address 0x60. > (II) RADEON(0): I2C device "DVI-1:ddc2" registered at address 0xA0. > (II) RADEON(0): EDID vendor "SAM", prod id 628 > (II) RADEON(0): Using hsync ranges from config file > (II) RADEON(0): Using vrefresh ranges from config file > (II) RADEON(0): Printing DDC gathered Modelines: > (II) RADEON(0): Modeline "1440x900"x0.0 106.50 1440 1520 1672 1904 900= 903 909 934 -hsync +vsync (55.9 kHz) > (II) RADEON(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601= 605 628 +hsync +vsync (37.9 kHz) > (II) RADEON(0): Modeline "800x600"x0.0 36.00 800 824 896 1024 600 601= 603 625 +hsync +vsync (35.2 kHz) > (II) RADEON(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 = 484 500 -hsync -vsync (37.5 kHz) > (II) RADEON(0): Modeline "640x480"x0.0 31.50 640 664 704 832 480 489 = 492 520 -hsync -vsync (37.9 kHz) > (II) RADEON(0): Modeline "640x480"x0.0 30.24 640 704 768 864 480 483 = 486 525 -hsync -vsync (35.0 kHz) > (II) RADEON(0): Modeline "640x480"x0.0 25.18 640 656 752 800 480 490 = 492 525 -hsync -vsync (31.5 kHz) > (II) RADEON(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 = 414 449 -hsync +vsync (31.5 kHz) > (II) RADEON(0): Modeline "1280x1024"x0.0 135.00 1280 1296 1440 1688 10= 24 1025 1028 1066 +hsync +vsync (80.0 kHz) > (II) RADEON(0): Modeline "1024x768"x0.0 78.75 1024 1040 1136 1312 768= 769 772 800 +hsync +vsync (60.0 kHz) > (II) RADEON(0): Modeline "1024x768"x0.0 75.00 1024 1048 1184 1328 768= 771 777 806 -hsync -vsync (56.5 kHz) > (II) RADEON(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768= 771 777 806 -hsync -vsync (48.4 kHz) > (II) RADEON(0): Modeline "832x624"x0.0 57.28 832 864 928 1152 624 625= 628 667 -hsync -vsync (49.7 kHz) > (II) RADEON(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601= 604 625 +hsync +vsync (46.9 kHz) > (II) RADEON(0): Modeline "800x600"x0.0 50.00 800 856 976 1040 600 637= 643 666 +hsync +vsync (48.1 kHz) > (II) RADEON(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864= 865 868 900 +hsync +vsync (67.5 kHz) > (II) RADEON(0): Modeline "1440x900"x0.0 88.75 1440 1488 1520 1600 900= 903 909 926 +hsync -vsync (55.5 kHz) > (II) RADEON(0): Modeline "1440x900"x0.0 136.75 1440 1536 1688 1936 900= 903 909 942 -hsync +vsync (70.6 kHz) > (II) RADEON(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 10= 24 1025 1028 1066 +hsync +vsync (64.0 kHz) > (II) RADEON(0): Modeline "1280x960"x0.0 108.00 1280 1376 1488 1800 960= 961 964 1000 +hsync +vsync (60.0 kHz) > (II) RADEON(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864= 865 868 900 +hsync +vsync (67.5 kHz) > (II) RADEON(0): Output: DVI-1, Detected Monitor Type: 3 > (II) RADEON(0): EDID data from the display on output: DVI-1 -------------= --------- > (II) RADEON(0): Manufacturer: SAM Model: 274 Serial#: 1296380217 > (II) RADEON(0): Year: 2007 Week: 28 > (II) RADEON(0): EDID Version: 1.3 > (II) RADEON(0): Digital Display Input > (II) RADEON(0): Max Image Size [cm]: horiz.: 41 vert.: 26 > (II) RADEON(0): Gamma: 2.35 > (II) RADEON(0): DPMS capabilities: Off > (II) RADEON(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4=20 > (II) RADEON(0): First detailed timing is preferred mode > (II) RADEON(0): redX: 0.640 redY: 0.329 greenX: 0.300 greenY: 0.600 > (II) RADEON(0): blueX: 0.150 blueY: 0.060 whiteX: 0.313 whiteY: 0.329 > (II) RADEON(0): Supported VESA Video Modes: > (II) RADEON(0): 720x400@70Hz > (II) RADEON(0): 640x480@60Hz > (II) RADEON(0): 640x480@67Hz > (II) RADEON(0): 640x480@72Hz > (II) RADEON(0): 640x480@75Hz > (II) RADEON(0): 800x600@56Hz > (II) RADEON(0): 800x600@60Hz > (II) RADEON(0): 800x600@72Hz > (II) RADEON(0): 800x600@75Hz > (II) RADEON(0): 832x624@75Hz > (II) RADEON(0): 1024x768@60Hz > (II) RADEON(0): 1024x768@70Hz > (II) RADEON(0): 1024x768@75Hz > (II) RADEON(0): 1280x1024@75Hz > (II) RADEON(0): 1152x870@75Hz > (II) RADEON(0): Manufacturer's mask: 0 > (II) RADEON(0): Supported Future Video Modes: > (II) RADEON(0): #0: hsize: 1440 vsize 900 refresh: 60 vid: 149 > (II) RADEON(0): #1: hsize: 1440 vsize 900 refresh: 75 vid: 3989 > (II) RADEON(0): #2: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 > (II) RADEON(0): #3: hsize: 1280 vsize 960 refresh: 60 vid: 16513 > (II) RADEON(0): #4: hsize: 1152 vsize 864 refresh: 75 vid: 20337 > (II) RADEON(0): Supported additional Video Mode: > (II) RADEON(0): clock: 106.5 MHz Image Size: 410 x 257 mm > (II) RADEON(0): h_active: 1440 h_sync: 1520 h_sync_end 1672 h_blank_end= 1904 h_border: 0 > (II) RADEON(0): v_active: 900 v_sync: 903 v_sync_end 909 v_blanking: 93= 4 v_border: 0 > (II) RADEON(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 81 kHz, = PixClock max 140 MHz > (II) RADEON(0): Monitor name: SyncMaster > (II) RADEON(0): Serial No: H9XP701904 > (II) RADEON(0): EDID (in hex): > (II) RADEON(0): 00ffffffffffff004c2d74023931454d > (II) RADEON(0): 1c11010380291a872ade95a3544c9926 > (II) RADEON(0): 0f5054bfef809500950f81808140714f > (II) RADEON(0): 0101010101019a29a0d0518422305098 > (II) RADEON(0): 36009a011100001c000000fd00384b1e > (II) RADEON(0): 510e000a202020202020000000fc0053 > (II) RADEON(0): 796e634d61737465720a2020000000ff > (II) RADEON(0): 00483958503730313930340a20200062 > finished output detect: 0 > (II) RADEON(0): I2C device "DVI-0:E-EDID segment register" registered at = address 0x60. > (II) RADEON(0): I2C device "DVI-0:ddc2" registered at address 0xA0. > (II) RADEON(0): Output: DVI-0, Detected Monitor Type: 0 > Dac detection success > Unhandled monitor type 0 > finished output detect: 1 > finished all detect > before xf86InitialConfiguration > (II) RADEON(0): EDID vendor "SAM", prod id 628 > (II) RADEON(0): Using hsync ranges from config file > (II) RADEON(0): Using vrefresh ranges from config file > (II) RADEON(0): Printing DDC gathered Modelines: > (II) RADEON(0): Modeline "1440x900"x0.0 106.50 1440 1520 1672 1904 900= 903 909 934 -hsync +vsync (55.9 kHz) > (II) RADEON(0): Modeline "800x600"x0.0 40.00 800 840 968 1056 600 601= 605 628 +hsync +vsync (37.9 kHz) > (II) RADEON(0): Modeline "800x600"x0.0 36.00 800 824 896 1024 600 601= 603 625 +hsync +vsync (35.2 kHz) > (II) RADEON(0): Modeline "640x480"x0.0 31.50 640 656 720 840 480 481 = 484 500 -hsync -vsync (37.5 kHz) > (II) RADEON(0): Modeline "640x480"x0.0 31.50 640 664 704 832 480 489 = 492 520 -hsync -vsync (37.9 kHz) > (II) RADEON(0): Modeline "640x480"x0.0 30.24 640 704 768 864 480 483 = 486 525 -hsync -vsync (35.0 kHz) > (II) RADEON(0): Modeline "640x480"x0.0 25.18 640 656 752 800 480 490 = 492 525 -hsync -vsync (31.5 kHz) > (II) RADEON(0): Modeline "720x400"x0.0 28.32 720 738 846 900 400 412 = 414 449 -hsync +vsync (31.5 kHz) > (II) RADEON(0): Modeline "1280x1024"x0.0 135.00 1280 1296 1440 1688 10= 24 1025 1028 1066 +hsync +vsync (80.0 kHz) > (II) RADEON(0): Modeline "1024x768"x0.0 78.75 1024 1040 1136 1312 768= 769 772 800 +hsync +vsync (60.0 kHz) > (II) RADEON(0): Modeline "1024x768"x0.0 75.00 1024 1048 1184 1328 768= 771 777 806 -hsync -vsync (56.5 kHz) > (II) RADEON(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768= 771 777 806 -hsync -vsync (48.4 kHz) > (II) RADEON(0): Modeline "832x624"x0.0 57.28 832 864 928 1152 624 625= 628 667 -hsync -vsync (49.7 kHz) > (II) RADEON(0): Modeline "800x600"x0.0 49.50 800 816 896 1056 600 601= 604 625 +hsync +vsync (46.9 kHz) > (II) RADEON(0): Modeline "800x600"x0.0 50.00 800 856 976 1040 600 637= 643 666 +hsync +vsync (48.1 kHz) > (II) RADEON(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864= 865 868 900 +hsync +vsync (67.5 kHz) > (II) RADEON(0): Modeline "1440x900"x0.0 88.75 1440 1488 1520 1600 900= 903 909 926 +hsync -vsync (55.5 kHz) > (II) RADEON(0): Modeline "1440x900"x0.0 136.75 1440 1536 1688 1936 900= 903 909 942 -hsync +vsync (70.6 kHz) > (II) RADEON(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 10= 24 1025 1028 1066 +hsync +vsync (64.0 kHz) > (II) RADEON(0): Modeline "1280x960"x0.0 108.00 1280 1376 1488 1800 960= 961 964 1000 +hsync +vsync (60.0 kHz) > (II) RADEON(0): Modeline "1152x864"x0.0 108.00 1152 1216 1344 1600 864= 865 868 900 +hsync +vsync (67.5 kHz) > (II) RADEON(0): Output: DVI-1, Detected Monitor Type: 3 > (II) RADEON(0): EDID data from the display on output: DVI-1 -------------= --------- > (II) RADEON(0): Manufacturer: SAM Model: 274 Serial#: 1296380217 > (II) RADEON(0): Year: 2007 Week: 28 > (II) RADEON(0): EDID Version: 1.3 > (II) RADEON(0): Digital Display Input > (II) RADEON(0): Max Image Size [cm]: horiz.: 41 vert.: 26 > (II) RADEON(0): Gamma: 2.35 > (II) RADEON(0): DPMS capabilities: Off > (II) RADEON(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4=20 > (II) RADEON(0): First detailed timing is preferred mode > (II) RADEON(0): redX: 0.640 redY: 0.329 greenX: 0.300 greenY: 0.600 > (II) RADEON(0): blueX: 0.150 blueY: 0.060 whiteX: 0.313 whiteY: 0.329 > (II) RADEON(0): Supported VESA Video Modes: > (II) RADEON(0): 720x400@70Hz > (II) RADEON(0): 640x480@60Hz > (II) RADEON(0): 640x480@67Hz > (II) RADEON(0): 640x480@72Hz > (II) RADEON(0): 640x480@75Hz > (II) RADEON(0): 800x600@56Hz > (II) RADEON(0): 800x600@60Hz > (II) RADEON(0): 800x600@72Hz > (II) RADEON(0): 800x600@75Hz > (II) RADEON(0): 832x624@75Hz > (II) RADEON(0): 1024x768@60Hz > (II) RADEON(0): 1024x768@70Hz > (II) RADEON(0): 1024x768@75Hz > (II) RADEON(0): 1280x1024@75Hz > (II) RADEON(0): 1152x870@75Hz > (II) RADEON(0): Manufacturer's mask: 0 > (II) RADEON(0): Supported Future Video Modes: > (II) RADEON(0): #0: hsize: 1440 vsize 900 refresh: 60 vid: 149 > (II) RADEON(0): #1: hsize: 1440 vsize 900 refresh: 75 vid: 3989 > (II) RADEON(0): #2: hsize: 1280 vsize 1024 refresh: 60 vid: 32897 > (II) RADEON(0): #3: hsize: 1280 vsize 960 refresh: 60 vid: 16513 > (II) RADEON(0): #4: hsize: 1152 vsize 864 refresh: 75 vid: 20337 > (II) RADEON(0): Supported additional Video Mode: > (II) RADEON(0): clock: 106.5 MHz Image Size: 410 x 257 mm > (II) RADEON(0): h_active: 1440 h_sync: 1520 h_sync_end 1672 h_blank_end= 1904 h_border: 0 > (II) RADEON(0): v_active: 900 v_sync: 903 v_sync_end 909 v_blanking: 93= 4 v_border: 0 > (II) RADEON(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 81 kHz, = PixClock max 140 MHz > (II) RADEON(0): Monitor name: SyncMaster > (II) RADEON(0): Serial No: H9XP701904 > (II) RADEON(0): EDID (in hex): > (II) RADEON(0): 00ffffffffffff004c2d74023931454d > (II) RADEON(0): 1c11010380291a872ade95a3544c9926 > (II) RADEON(0): 0f5054bfef809500950f81808140714f > (II) RADEON(0): 0101010101019a29a0d0518422305098 > (II) RADEON(0): 36009a011100001c000000fd00384b1e > (II) RADEON(0): 510e000a202020202020000000fc0053 > (II) RADEON(0): 796e634d61737465720a2020000000ff > (II) RADEON(0): 00483958503730313930340a20200062 > (II) RADEON(0): Panel infos found from DDC detailed: 1440x900 > (II) RADEON(0): EDID vendor "SAM", prod id 628 > (II) RADEON(0): Output: DVI-0, Detected Monitor Type: 0 > Dac detection success > Unhandled monitor type 0 > (II) RADEON(0): Output DVI-1 connected > (II) RADEON(0): Output DVI-0 disconnected > (II) RADEON(0): Using exact sizes for initial modes > (II) RADEON(0): Output DVI-1 using initial mode 1440x900 > after xf86InitialConfiguration > (**) RADEON(0): Display dimensions: (410, 260) mm > (**) RADEON(0): DPI set to (89, 140) > (II) Loading sub module "fb" > (II) LoadModule: "fb" > (II) Loading /usr/local/lib/xorg/modules//libfb.so > (II) Module fb: vendor=3D"X.Org Foundation" > compiled for 1.6.0, module version =3D 1.0.0 > ABI class: X.Org ANSI C Emulation, version 0.4 > (=3D=3D) RADEON(0): Using gamma correction (1.0, 1.0, 1.0) > (II) Loading sub module "ramdac" > (II) LoadModule: "ramdac" > (II) Module "ramdac" already built-in > (=3D=3D) RADEON(0): Using XAA acceleration architecture > (II) Loading sub module "xaa" > (II) LoadModule: "xaa" > (II) Loading /usr/local/lib/xorg/modules//libxaa.so > (II) Module xaa: vendor=3D"X.Org Foundation" > compiled for 1.6.0, module version =3D 1.2.1 > ABI class: X.Org Video Driver, version 5.0 > (=3D=3D) RADEON(0): Write-combining range (0x0,0x1000) was already clear > (!!) RADEON(0): For information on using the multimedia capabilities > of this adapter, please see http://gatos.sf.net. > (!!) RADEON(0): MergedFB support has been removed and replaced with xrand= r 1.2 support > (--) Depth 24 pixmap format is 32 bpp > (II) do I need RAC? No, I don't. > (II) resource ranges after preInit: > [0] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] > [1] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] > [2] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] > [3] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B](OprU) > [4] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B](OprU) > [5] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B](OprU) > [6] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] > [7] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] > [8] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B](OprU) > [9] 0 0 0x000003c0 - 0x000003df (0x20) IS[B](OprU) > (II) RADEON(0): RADEONScreenInit d0000000 0 0 > (=3D=3D) RADEON(0): Write-combining range (0xa0000,0x10000) was already c= lear > Output DFP1 disable success > Blank CRTC 0 success > Disable CRTC 0 success > Blank CRTC 1 success > Disable CRTC 1 success > (=3D=3D) RADEON(0): Using 24 bit depth buffer > (II) RADEON(0): RADEONInitMemoryMap() :=20 > (II) RADEON(0): mem_size : 0x10000000 > (II) RADEON(0): MC_FB_LOCATION : 0xdfffd000 > (II) RADEON(0): MC_AGP_LOCATION : 0x003f0000 > (II) RADEON(0): Depth moves disabled by default > (II) RADEON(0): Using 32 MB GART aperture > (II) RADEON(0): Using 1 MB for the ring buffer > (II) RADEON(0): Using 2 MB for vertex/indirect buffers > (II) RADEON(0): Using 29 MB for GART textures > (II) RADEON(0): Memory manager initialized to (0,0) (1472,8191) > (II) RADEON(0): Reserved area from (0,1440) to (1472,1442) > (II) RADEON(0): Largest offscreen area available: 1472 x 6749 > (II) RADEON(0): Will use front buffer at offset 0x0 > (II) RADEON(0): Will use back buffer at offset 0x23c2000 > (II) RADEON(0): Will use depth buffer at offset 0x2bd8000 > (II) RADEON(0): Will use 32 kb for PCI GART table at offset 0xfff8000 > (II) RADEON(0): Will use 208896 kb for textures at offset 0x33ee000 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 10, (OK) > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 10, (OK) > drmOpenByBusid: Searching for BusID pci:0000:06:00.0 > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is 10, (OK) > drmOpenByBusid: drmOpenMinor returns 10 > drmOpenByBusid: drmGetBusid reports pci:0000:06:00.0 > (II) [drm] DRM interface version 1.2 > (II) [drm] DRM open master succeeded. > (II) RADEON(0): [drm] Using the DRM lock SAREA also for drawables. > (II) RADEON(0): [drm] framebuffer handle =3D 0xd0000000 > (II) RADEON(0): [drm] added 1 reserved context for kernel > (II) RADEON(0): X context handle =3D 0x1 > (II) RADEON(0): [drm] installed DRM signal handler > (II) RADEON(0): [pci] 32768 kB allocated with handle 0x7a2cb000 > (II) RADEON(0): [pci] ring handle =3D 0x7a2cb000 > (II) RADEON(0): [pci] Ring mapped at 0x812e00000 > (II) RADEON(0): [pci] Ring contents 0x00000000 > (II) RADEON(0): [pci] ring read ptr handle =3D 0x7a3cc000 > (II) RADEON(0): [pci] Ring read ptr mapped at 0x80076b000 > (II) RADEON(0): [pci] Ring read ptr contents 0x00000000 > (II) RADEON(0): [pci] vertex/indirect buffers handle =3D 0x7a3cd000 > (II) RADEON(0): [pci] Vertex/indirect buffers mapped at 0x812f01000 > (II) RADEON(0): [pci] Vertex/indirect buffers contents 0x00000000 > (II) RADEON(0): [pci] GART texture map handle =3D 0x7a5cd000 > (II) RADEON(0): [pci] GART Texture map mapped at 0x8131cd000 > (II) RADEON(0): [drm] register handle =3D 0xfbee0000 > (II) RADEON(0): [dri] Visual configs initialized > (II) RADEON(0): RADEONRestoreMemMapRegisters() :=20 > (II) RADEON(0): MC_FB_LOCATION : 0xdfffd000 0xfffff000 > (II) RADEON(0): MC_AGP_LOCATION : 0x003f0000 > (=3D=3D) RADEON(0): Backing store disabled > (II) RADEON(0): [DRI] installation complete > (II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers > (II) RADEON(0): [drm] Mapped 32 vertex/indirect buffers > (II) RADEON(0): [drm] dma control initialized, using IRQ 16 > (II) RADEON(0): [drm] Initialized kernel GART heap manager, 29884416 > (WW) RADEON(0): DRI init changed memory map, adjusting ... > (WW) RADEON(0): MC_FB_LOCATION was: 0xdfffd000 is: 0xdfffd000 > (WW) RADEON(0): MC_AGP_LOCATION was: 0x003f0000 is: 0xffffffc0 > (II) RADEON(0): RADEONRestoreMemMapRegisters() :=20 > (II) RADEON(0): MC_FB_LOCATION : 0xdfffd000 0xdfffd000 > (II) RADEON(0): MC_AGP_LOCATION : 0xffffffc0 > (II) RADEON(0): Direct rendering enabled > (II) RADEON(0): XAA Render acceleration unsupported on Radeon 9500/9700 a= nd newer. Please use EXA instead. > (II) RADEON(0): Render acceleration disabled > (II) RADEON(0): num quad-pipes is 3 > (II) RADEON(0): Using XFree86 Acceleration Architecture (XAA) > Screen to screen bit blits > Solid filled rectangles > 8x8 mono pattern filled rectangles > Indirect CPU to Screen color expansion > Solid Lines > Scanline Image Writes > Setting up tile and stipple cache: > 32 128x128 slots > 32 256x256 slots > 16 512x512 slots > (II) RADEON(0): Acceleration enabled > (**) Option "dpms" > (**) RADEON(0): DPMS enabled > (=3D=3D) RADEON(0): Silken mouse enabled > (II) RADEON(0): Will use 32 kb for hardware cursor 0 at offset 0x00819000 > (II) RADEON(0): Will use 32 kb for hardware cursor 1 at offset 0x0081f000 > (II) RADEON(0): Largest offscreen area available: 1472 x 6741 > (II) RADEON(0): Set up textured video > Output DFP1 disable success > Blank CRTC 0 success > Disable CRTC 0 success > Blank CRTC 1 success > Disable CRTC 1 success > Output DFP1 disable success > Mode 1440x900 - 1904 934 6 > (II) RADEON(0): RADEONRestoreMemMapRegisters() :=20 > (II) RADEON(0): MC_FB_LOCATION : 0xdfffd000 0xdfffd000 > (II) RADEON(0): MC_AGP_LOCATION : 0xffffffc0 > freq: 106500000 > best_freq: 106500000 > best_feedback_div: 71 > best_ref_div: 2 > best_post_div: 9 > (II) RADEON(0): crtc(0) Clock: mode 106500, PLL 106500 > (II) RADEON(0): crtc(0) PLL : refdiv 2, fbdiv 0x47(71), pdiv 9 > Set CRTC 0 PLL success > Set CRTC Timing success > Set CRTC 0 Overscan success > Not using RMX > scaler 0 setup success > Set CRTC 0 Source success > crtc 0 YUV disable setup success > Output digital setup success > Enable CRTC 0 success > Unblank CRTC 0 success > Output DFP1 enable success > Blank CRTC 1 success > Disable CRTC 1 success > (II) RADEON(0): RandR 1.2 enabled, ignore the following RandR disabled me= ssage. > Lock CRTC 0 success > Unlock CRTC 0 success > (--) RandR disabled > (II) Initializing built-in extension Generic Event Extension > (II) Initializing built-in extension SHAPE > (II) Initializing built-in extension MIT-SHM > (II) Initializing built-in extension XInputExtension > (II) Initializing built-in extension XTEST > (II) Initializing built-in extension BIG-REQUESTS > (II) Initializing built-in extension SYNC > (II) Initializing built-in extension XKEYBOARD > (II) Initializing built-in extension XC-MISC > (II) Initializing built-in extension XINERAMA > (II) Initializing built-in extension XFIXES > (II) Initializing built-in extension RENDER > (II) Initializing built-in extension RANDR > (II) Initializing built-in extension COMPOSITE > (II) Initializing built-in extension DAMAGE > (II) AIGLX: Loaded and initialized /usr/local/lib/dri/swrast_dri.so > (II) GLX: Initialized DRISWRAST GL provider for screen 0 > (II) RADEON(0): Setting screen physical size to 410 x 257 > (**) Option "Protocol" "auto" > (**) Mouse0: Device: "/dev/sysmouse" > (**) Mouse0: Protocol: "auto" > (**) Option "CorePointer" > (**) Mouse0: always reports core events > (**) Option "Device" "/dev/sysmouse" > (=3D=3D) Mouse0: Emulate3Buttons, Emulate3Timeout: 50 > (**) Option "ZAxisMapping" "4 5 6 7" > (**) Mouse0: ZAxisMapping: buttons 4, 5, 6 and 7 > (**) Mouse0: Buttons: 11 > (**) Mouse0: Sensitivity: 1 > (II) XINPUT: Adding extended input device "Mouse0" (type: MOUSE) > (**) Mouse0: (accel) keeping acceleration scheme 1 > (**) Mouse0: (accel) filter chain progression: 2.00 > (**) Mouse0: (accel) filter stage 0: 20.00 ms > (**) Mouse0: (accel) set acceleration profile 0 > (II) Mouse0: SetupAuto: hw.iftype is 4, hw.model is 0 > (II) Mouse0: SetupAuto: protocol is SysMouse > (**) Option "CoreKeyboard" > (**) Keyboard0: always reports core events > (**) Option "Protocol" "standard" > (**) Keyboard0: Protocol: standard > (**) Option "AutoRepeat" "500 30" > (**) Option "XkbRules" "xorg" > (**) Keyboard0: XkbRules: "xorg" > (**) Option "XkbModel" "pc105" > (**) Keyboard0: XkbModel: "pc105" > (**) Option "XkbLayout" "us" > (**) Keyboard0: XkbLayout: "us" > (**) Option "CustomKeycodes" "off" > (**) Keyboard0: CustomKeycodes disabled > (II) XINPUT: Adding extended input device "Keyboard0" (type: KEYBOARD) > Output DFP1 disable success > Blank CRTC 0 success > Disable CRTC 0 success > Blank CRTC 1 success > Disable CRTC 1 success > Enable CRTC 0 success > Unblank CRTC 0 success > Output DFP1 enable success > Enable CRTC 0 success > Unblank CRTC 0 success > Output DFP1 disable success > Enable CRTC 0 success > Unblank CRTC 0 success > Output DFP1 enable success > Output DFP1 disable success > Blank CRTC 0 success > Disable CRTC 0 success > Blank CRTC 1 success > Disable CRTC 1 success > Enable CRTC 0 success > Unblank CRTC 0 success > Output DFP1 enable success > Enable CRTC 0 success > Unblank CRTC 0 success > Output DFP1 disable success > Enable CRTC 0 success > Unblank CRTC 0 success > Output DFP1 enable success > Output DFP1 disable success > Blank CRTC 0 success > Disable CRTC 0 success > Blank CRTC 1 success > Disable CRTC 1 success > Enable CRTC 0 success > Unblank CRTC 0 success > Output DFP1 enable success > Enable CRTC 0 success > Unblank CRTC 0 success > Output DFP1 disable success > Enable CRTC 0 success > Unblank CRTC 0 success > Output DFP1 enable success > Output DFP1 disable success > Blank CRTC 0 success > Disable CRTC 0 success > Blank CRTC 1 success > Disable CRTC 1 success > Enable CRTC 0 success > Unblank CRTC 0 success > Output DFP1 enable success > Output DFP1 disable success > Blank CRTC 0 success > Disable CRTC 0 success > Blank CRTC 1 success > Disable CRTC 1 success > Enable CRTC 0 success > Unblank CRTC 0 success > Output DFP1 enable success > Output DFP1 disable success > Blank CRTC 0 success > Disable CRTC 0 success > Blank CRTC 1 success > Disable CRTC 1 success > Enable CRTC 0 success > Unblank CRTC 0 success > Output DFP1 enable success > Enable CRTC 0 success > Unblank CRTC 0 success > Output DFP1 disable success > Enable CRTC 0 success > Unblank CRTC 0 success > Output DFP1 enable success > Enable CRTC 0 success > Unblank CRTC 0 success > Output DFP1 disable success >=20 > /var/log/messages: >=20 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_indirect] idx=3D30 = s=3D0 e=3D3288 d=3D1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_dispatch_indirect] = buf=3D30 s=3D0x0 e=3D0xcd8 > Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=3D68478, cmd= =3D0xc0406429, nr=3D0x29, dev 0xffffff0001b3f800, auth=3D1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_freelist_get] done_age= =3D 941502 > Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=3D68478, cmd= =3D0xc010644d, nr=3D0x4d, dev 0xffffff0001b3f800, auth=3D1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_indirect] idx=3D31 = s=3D0 e=3D1684 d=3D1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_dispatch_indirect] = buf=3D31 s=3D0x0 e=3D0x694 > Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=3D68478, cmd= =3D0x20006444, nr=3D0x44, dev 0xffffff0001b3f800, auth=3D1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_idle]=20 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_do_cp_idle]=20 > Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=3D68478, cmd= =3D0x20006444, nr=3D0x44, dev 0xffffff0001b3f800, auth=3D1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_idle]=20 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_do_cp_idle]=20 > Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=3D68478, cmd= =3D0xc0406429, nr=3D0x29, dev 0xffffff0001b3f800, auth=3D1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_freelist_get] done_age= =3D 941503 > Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=3D68478, cmd= =3D0xc010644d, nr=3D0x4d, dev 0xffffff0001b3f800, auth=3D1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_indirect] idx=3D0 s= =3D0 e=3D13260 d=3D1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_dispatch_indirect] = buf=3D0 s=3D0x0 e=3D0x33cc > Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=3D68478, cmd= =3D0xc0406429, nr=3D0x29, dev 0xffffff0001b3f800, auth=3D1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_freelist_get] done_age= =3D 941504 > Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=3D68478, cmd= =3D0xc010644d, nr=3D0x4d, dev 0xffffff0001b3f800, auth=3D1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_indirect] idx=3D1 s= =3D0 e=3D6084 d=3D1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_dispatch_indirect] = buf=3D1 s=3D0x0 e=3D0x17c4 > Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=3D68478, cmd= =3D0xc0406429, nr=3D0x29, dev 0xffffff0001b3f800, auth=3D1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_freelist_get] done_age= =3D 941505 > Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=3D68478, cmd= =3D0xc010644d, nr=3D0x4d, dev 0xffffff0001b3f800, auth=3D1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_indirect] idx=3D2 s= =3D0 e=3D1840 d=3D1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_dispatch_indirect] = buf=3D2 s=3D0x0 e=3D0x730 > Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=3D68478, cmd= =3D0xc0406429, nr=3D0x29, dev 0xffffff0001b3f800, auth=3D1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_freelist_get] done_age= =3D 941506 > Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=3D68478, cmd= =3D0xc010644d, nr=3D0x4d, dev 0xffffff0001b3f800, auth=3D1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_indirect] idx=3D3 s= =3D0 e=3D5152 d=3D1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_dispatch_indirect] = buf=3D3 s=3D0x0 e=3D0x1420 > Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=3D68478, cmd= =3D0xc0406429, nr=3D0x29, dev 0xffffff0001b3f800, auth=3D1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_freelist_get] done_age= =3D 941506 > Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=3D68478, cmd= =3D0xc010644d, nr=3D0x4d, dev 0xffffff0001b3f800, auth=3D1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_indirect] idx=3D4 s= =3D0 e=3D3288 d=3D1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_dispatch_indirect] = buf=3D4 s=3D0x0 e=3D0xcd8 > Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=3D68478, cmd= =3D0xc0406429, nr=3D0x29, dev 0xffffff0001b3f800, auth=3D1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_freelist_get] done_age= =3D 941508 > Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=3D68478, cmd= =3D0xc010644d, nr=3D0x4d, dev 0xffffff0001b3f800, auth=3D1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_indirect] idx=3D5 s= =3D0 e=3D3236 d=3D1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_dispatch_indirect] = buf=3D5 s=3D0x0 e=3D0xca4 > Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=3D68478, cmd= =3D0xc0406429, nr=3D0x29, dev 0xffffff0001b3f800, auth=3D1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_freelist_get] done_age= =3D 941509 > Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=3D68478, cmd= =3D0xc010644d, nr=3D0x4d, dev 0xffffff0001b3f800, auth=3D1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_indirect] idx=3D6 s= =3D0 e=3D1684 d=3D1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_dispatch_indirect] = buf=3D6 s=3D0x0 e=3D0x694 > Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=3D68478, cmd= =3D0xc0406429, nr=3D0x29, dev 0xffffff0001b3f800, auth=3D1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_freelist_get] done_age= =3D 941510 > Apr 11 09:51:42 viper kernel: [drm:pid68478:drm_ioctl] pid=3D68478, cmd= =3D0xc010644d, nr=3D0x4d, dev 0xffffff0001b3f800, auth=3D1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_indirect] idx=3D7 s= =3D0 e=3D1736 d=3D1 > Apr 11 09:51:42 viper kernel: [drm:pid68478:radeon_cp_dispatch_indirect] = buf=3D7 s=3D0x0 e=3D0x6c8 --=20 Robert Noland FreeBSD --=-NiQTX7SfpGcYRmHNHJzD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAkng61MACgkQM4TrQ4qfROOVEgCfUI5BKAdzSlW1zpZug4f0r2IL X1oAn0x95ysRKHRKwm78TZabm1jj3CQf =8qZt -----END PGP SIGNATURE----- --=-NiQTX7SfpGcYRmHNHJzD-- From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 11 19:28:37 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C77FB106566C for ; Sat, 11 Apr 2009 19:28:37 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 4CA268FC18 for ; Sat, 11 Apr 2009 19:28:37 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: by ewy19 with SMTP id 19so1484685ewy.43 for ; Sat, 11 Apr 2009 12:28:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:cc :subject:message-id:references:mime-version:content-type :content-disposition:in-reply-to; bh=Xqbd8KIgUEOKV+7GpJOz9cTcKkObImKRY1dWCy/Yb9I=; b=Q+dOnB9jSJTJyjRuZFkGSQAoU8WOphKHCpceZ/yWduIlbbqYRUWkwiP6P0sarcJZBT hX+lR4dcW2W30vDK1jElCSPF17qUiUFxXOR2QNCI107dw7zwMliffI4oC8noVrC3KozP pMcsxdbJ5xiwNGZ6ZIyyaAaIGrgUCED5V7KoA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; b=DPv2txB3SgWsfYo7hNrUMUhxINz/iGWgQ2KNQ/Vc+6rbZSQRNnr8J6y7BBe5TtvWXL xDzzsyoBVMa4fKEdL8aS6DFXdZxyBv7cs7X03Qrb7yUwPEDCyqbsuIAUzQcJKC+oXYR3 YLLUWdEdTI3dY9T06G79NkgqHkZHytw2QBQ8k= Received: by 10.210.65.2 with SMTP id n2mr3940966eba.80.1239478116519; Sat, 11 Apr 2009 12:28:36 -0700 (PDT) Received: from logik.internal.network (81-86-41-187.dsl.pipex.com [81.86.41.187]) by mx.google.com with ESMTPS id 24sm3623096ewy.49.2009.04.11.12.28.35 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 11 Apr 2009 12:28:36 -0700 (PDT) Received: by logik.internal.network (Postfix, from userid 11001) id CF3265C31; Sat, 11 Apr 2009 19:28:34 +0000 (UTC) Date: Sat, 11 Apr 2009 20:28:34 +0100 From: xorquewasp@googlemail.com To: Mikolaj Golub Message-ID: <20090411192834.GE83697@logik.internal.network> References: <20090410132354.GA20721@logik.internal.network> <20090410154251.GA49384@logik.internal.network> <1239385368.1922.74.camel@balrog.2hip.net> <20090410175922.GA50520@logik.internal.network> <1239388293.1922.80.camel@balrog.2hip.net> <20090410211307.GA83697@logik.internal.network> <3a142e750904101730k53b7fbabn6e801ac36f1182e0@mail.gmail.com> <20090411101559.GC83697@logik.internal.network> <86zlen9vw2.fsf@kopusha.onet> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86zlen9vw2.fsf@kopusha.onet> Cc: freebsd-hackers@freebsd.org Subject: Re: diagnosing freezes (DRI?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 19:28:38 -0000 On 2009-04-11 16:12:45, Mikolaj Golub wrote: > > If you are interested in providing useful information about your freezes, > please read the following: Thanks very much. Will be doing all of the above. From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 11 19:30:57 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 758251065670; Sat, 11 Apr 2009 19:30:57 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id 8C96A8FC19; Sat, 11 Apr 2009 19:30:56 +0000 (UTC) (envelope-from xorquewasp@googlemail.com) Received: by ewy19 with SMTP id 19so1485142ewy.43 for ; Sat, 11 Apr 2009 12:30:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:cc :subject:message-id:references:mime-version:content-type :content-disposition:in-reply-to; bh=nnT8kdx/J+0YXxoPl+z+1myjyZxtfNUfjqRUnLSRZcs=; b=M47UaR6qF5W6IWh5bu7wr3d3JZej2YzjaKo6eW4cUOMKLuvs9RkTtNF1citrn2LeWf L7mLUMaj7qo0j85PEFE0ryZUqoMT4xqxPjlyhPbJxelweEU17UXEZjqGx/PskQFdQ3SI Lky1gV9jhWSSPGLV5mZmSGNTDfAiMe9ynHBN8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; b=G+M+a2FQ5M1mElIWqs7hiDt/JTrVcxfW1QJ2rYWYIsDzOuN2BwSrdyCQcRhGxrOWEs Xc04GvhRljqV24QyuzlrgbwzzOYR5DThzMTKa684PKX98RHag31/qXB5RELjnJs6CZLF DdGNXCstw11GC6ME54/51fSXX7xhDID2EYEfM= Received: by 10.211.196.13 with SMTP id y13mr3949195ebp.79.1239478255740; Sat, 11 Apr 2009 12:30:55 -0700 (PDT) Received: from logik.internal.network (81-86-41-187.dsl.pipex.com [81.86.41.187]) by mx.google.com with ESMTPS id 24sm3610967ewy.97.2009.04.11.12.30.55 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 11 Apr 2009 12:30:55 -0700 (PDT) Received: by logik.internal.network (Postfix, from userid 11001) id 3B3A65C31; Sat, 11 Apr 2009 19:30:54 +0000 (UTC) Date: Sat, 11 Apr 2009 20:30:54 +0100 From: xorquewasp@googlemail.com To: Robert Noland Message-ID: <20090411193054.GF83697@logik.internal.network> References: <20090410132354.GA20721@logik.internal.network> <20090410154251.GA49384@logik.internal.network> <1239385368.1922.74.camel@balrog.2hip.net> <20090410175922.GA50520@logik.internal.network> <1239388293.1922.80.camel@balrog.2hip.net> <20090411102300.GD83697@logik.internal.network> <1239477075.1932.5.camel@balrog.2hip.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1239477075.1932.5.camel@balrog.2hip.net> Cc: freebsd-hackers@freebsd.org Subject: Re: diagnosing freezes (DRI?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 19:30:58 -0000 On 2009-04-11 14:11:15, Robert Noland wrote: > > Are you running the 7.2-PRE or -STABLE? There are a few relevant fixes > in -STABLE that didn't make it into the pre-release. Sorry, should've made that clear. It was meant to be -STABLE but it seems to be calling itself -PRE. Just to clarify, my uname says 7.2-PRERELEASE but I used the 'stable-supfile'. This is expected, yes? I'm about to update the machine's BIOS and then enable all the possible debugging options from the kernel dev handbook. xw From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 11 19:37:53 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28C6210656F5 for ; Sat, 11 Apr 2009 19:37:53 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id DE9318FC12 for ; Sat, 11 Apr 2009 19:37:52 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-1-210-55.bna.bellsouth.net [65.1.210.55]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n3BJaOCd084476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Apr 2009 15:36:34 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: xorquewasp@googlemail.com In-Reply-To: <20090411193054.GF83697@logik.internal.network> References: <20090410132354.GA20721@logik.internal.network> <20090410154251.GA49384@logik.internal.network> <1239385368.1922.74.camel@balrog.2hip.net> <20090410175922.GA50520@logik.internal.network> <1239388293.1922.80.camel@balrog.2hip.net> <20090411102300.GD83697@logik.internal.network> <1239477075.1932.5.camel@balrog.2hip.net> <20090411193054.GF83697@logik.internal.network> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-x/lYu343H4rNPakfTA16" Organization: FreeBSD Date: Sat, 11 Apr 2009 14:36:46 -0500 Message-Id: <1239478606.1932.13.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.0 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RCVD_IN_SORBS_DUL,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-hackers@freebsd.org Subject: Re: diagnosing freezes (DRI?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 19:37:54 -0000 --=-x/lYu343H4rNPakfTA16 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2009-04-11 at 20:30 +0100, xorquewasp@googlemail.com wrote: > On 2009-04-11 14:11:15, Robert Noland wrote: > >=20 > > Are you running the 7.2-PRE or -STABLE? There are a few relevant fixes > > in -STABLE that didn't make it into the pre-release. >=20 > Sorry, should've made that clear. It was meant to be -STABLE but it > seems to be calling itself -PRE. Just to clarify, my uname=20 > says 7.2-PRERELEASE but I used the 'stable-supfile'. This is expected, > yes? >=20 > I'm about to update the machine's BIOS and then enable all the possible > debugging options from the kernel dev handbook. Yes, just make sure that your -STABLE is at least: r190653 | rnoland | 2009-04-02 13:21:41 -0500 (Thu, 02 Apr 2009) | 7 lines robert. > xw --=20 Robert Noland FreeBSD --=-x/lYu343H4rNPakfTA16 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAkng8U4ACgkQM4TrQ4qfRON09wCfQbCVrp+blyJOb6E05ED6wpdx sDwAn0XV1NKRhjWoVNMI1Yep6q7qn+m5 =u4t7 -----END PGP SIGNATURE----- --=-x/lYu343H4rNPakfTA16-- From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 11 19:45:29 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24121106564A for ; Sat, 11 Apr 2009 19:45:29 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id BEFA28FC12 for ; Sat, 11 Apr 2009 19:45:28 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.156] (adsl-1-210-55.bna.bellsouth.net [65.1.210.55]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n3BJi98D084534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Apr 2009 15:44:10 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: gary.jennejohn@freenet.de In-Reply-To: <20090411140643.35cc82ae@ernst.jennejohn.org> References: <20090410132354.GA20721@logik.internal.network> <20090410154251.GA49384@logik.internal.network> <1239385368.1922.74.camel@balrog.2hip.net> <20090410175922.GA50520@logik.internal.network> <1239388293.1922.80.camel@balrog.2hip.net> <20090410211307.GA83697@logik.internal.network> <3a142e750904101730k53b7fbabn6e801ac36f1182e0@mail.gmail.com> <20090411101559.GC83697@logik.internal.network> <20090411140643.35cc82ae@ernst.jennejohn.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-Y9ZG1SG0PafQzWrLhXAz" Organization: FreeBSD Date: Sat, 11 Apr 2009 14:44:31 -0500 Message-Id: <1239479071.1932.16.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.0 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RCVD_IN_SORBS_DUL,RDNS_DYNAMIC autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-hackers@freebsd.org, "Paul B. Mahol" , xorquewasp@googlemail.com Subject: Re: diagnosing freezes (DRI?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 19:45:29 -0000 --=-Y9ZG1SG0PafQzWrLhXAz Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2009-04-11 at 14:06 +0200, Gary Jennejohn wrote: > On Sat, 11 Apr 2009 11:15:59 +0100 > xorquewasp@googlemail.com wrote: >=20 > > On 2009-04-11 02:30:40, Paul B. Mahol wrote: > > >=20 > > > If it locks under X11 then use debug.debugger_on_panic=3D0 sysctl. > > > Not doing this will increase drasticaly chances of locking whole syst= em > > > and not providing any debug data. > >=20 > > I don't seem to have that sysctl. > >=20 > > You sure that's the correct name? > >=20 >=20 > It's definitely in 8-current. Seems to be set to 0 as default. This may only exist if you have DDB enabled... robert. > --- > Gary Jennejohn > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " --=20 Robert Noland FreeBSD --=-Y9ZG1SG0PafQzWrLhXAz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAkng8x8ACgkQM4TrQ4qfRONgDgCfYSilMQYaZ2ume1NXG1pTlhMc hmwAnAul9k3OmA2wbqw3CuUfVj9TkRZs =3CJ/ -----END PGP SIGNATURE----- --=-Y9ZG1SG0PafQzWrLhXAz-- From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 11 20:56:48 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D75521065672 for ; Sat, 11 Apr 2009 20:56:48 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from mta1.srv.hcvlny.cv.net (mta1.srv.hcvlny.cv.net [167.206.4.196]) by mx1.freebsd.org (Postfix) with ESMTP id AE7718FC16 for ; Sat, 11 Apr 2009 20:56:48 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from flosoft.no-ip.biz (ool-435559b8.dyn.optonline.net [67.85.89.184]) by mta1.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0KHY000ODFIFMZC0@mta1.srv.hcvlny.cv.net> for freebsd-hackers@freebsd.org; Sat, 11 Apr 2009 16:56:39 -0400 (EDT) Received: from flosoft.no-ip.biz (localhost [127.0.0.1]) by flosoft.no-ip.biz (8.14.3/8.14.3) with ESMTP id n3BKucPJ001628; Sat, 11 Apr 2009 16:56:38 -0400 Date: Sat, 11 Apr 2009 16:56:38 -0400 From: "Aryeh M. Friedman" To: freebsd-hackers@freebsd.org Message-id: <49E10406.7060006@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0.0.21 (X11/20090331) Subject: setting up local authorative name server with a no-ip.com registered domain X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 20:56:49 -0000 I have 3 domains that are registered with no-ip.com (istudentunion.com, org and net). All three are also using their "no-ip plus" service which provides both static and dynamic resolution via their nameservers. When I configure the domains nameservers to be theirs everything works great (for the most part), but when I change the nameservers to my own sites BIND (base 7.3-RELEASE) I can get everything to resolve locally and via dig/host/nslookup remotely (if and only if I specify the nameserver by IP). What appears to be happing is this: ~/Desktop:aryeh@flosoft% !d dig ns istudentunion.org +trace ; <<>> DiG 9.4.3-P2 <<>> ns istudentunion.org +trace ;; global options: printcmd . 463753 IN NS I.ROOT-SERVERS.NET. . 463753 IN NS C.ROOT-SERVERS.NET. . 463753 IN NS L.ROOT-SERVERS.NET. . 463753 IN NS K.ROOT-SERVERS.NET. . 463753 IN NS M.ROOT-SERVERS.NET. . 463753 IN NS A.ROOT-SERVERS.NET. . 463753 IN NS E.ROOT-SERVERS.NET. . 463753 IN NS B.ROOT-SERVERS.NET. . 463753 IN NS H.ROOT-SERVERS.NET. . 463753 IN NS D.ROOT-SERVERS.NET. . 463753 IN NS G.ROOT-SERVERS.NET. . 463753 IN NS F.ROOT-SERVERS.NET. . 463753 IN NS J.ROOT-SERVERS.NET. ;; Received 500 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms org. 172800 IN NS B2.ORG.AFILIAS-NST.org. org. 172800 IN NS A2.ORG.AFILIAS-NST.INFO. org. 172800 IN NS C0.ORG.AFILIAS-NST.INFO. org. 172800 IN NS B0.ORG.AFILIAS-NST.org. org. 172800 IN NS A0.ORG.AFILIAS-NST.INFO. org. 172800 IN NS D0.ORG.AFILIAS-NST.org. ;; Received 437 bytes from 192.203.230.10#53(E.ROOT-SERVERS.NET) in 86 ms istudentunion.org. 86400 IN NS ns2.istudentunion.org. istudentunion.org. 86400 IN NS ns1.istudentunion.org. ;; Received 103 bytes from 199.19.54.1#53(B0.ORG.AFILIAS-NST.org) in 88 ms ;; connection timed out; no servers could be reached From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 11 21:04:00 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2085B106564A for ; Sat, 11 Apr 2009 21:04:00 +0000 (UTC) (envelope-from brampton@gmail.com) Received: from mail-bw0-f164.google.com (mail-bw0-f164.google.com [209.85.218.164]) by mx1.freebsd.org (Postfix) with ESMTP id 473C68FC1C for ; Sat, 11 Apr 2009 21:03:58 +0000 (UTC) (envelope-from brampton@gmail.com) Received: by bwz8 with SMTP id 8so1580895bwz.43 for ; Sat, 11 Apr 2009 14:03:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=hgRXqnvuc3XdAnUoHF1Xy2mMmIeq+B1KboSgP91IBWM=; b=bge49vxVfL54JgyPxY4+qzJbBfNJvTygYN7bTADUgPLM9xo8+63vUsPc8hSuigBgIU NFgcjNIkDrscrJXX2HB8XXENxOJPXfco3FNLKyw1MDZHbfIwZ/YsJKGzvCpBV0ysKFhD 3ySYazNVl4+08DlEMM6FwtRPXniDrhMyZZ0eE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=PqghV51fzwtpFQgdF4Y1auNq6AqI0qK1MviYQwd8BHwsI4kuaLVVMpn3Bg/NcYXuNG iezbvanF22YiEeF8RhnC7qi9S2yQKX28jkqs5nkT39ncSMbak11icUPONO02rnJFpkx0 u6eWakQc1CVjdTBCuHbotXLUIdd1IN1eAdQfs= MIME-Version: 1.0 Sender: brampton@gmail.com Received: by 10.223.126.66 with SMTP id b2mr1383714fas.3.1239483838034; Sat, 11 Apr 2009 14:03:58 -0700 (PDT) In-Reply-To: References: Date: Sat, 11 Apr 2009 22:03:58 +0100 X-Google-Sender-Auth: e4daf6e033b17634 Message-ID: From: Andrew Brampton To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Robert Watson Subject: Re: FreeBSD memguard + spinlocks X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 21:04:00 -0000 2009/4/11 Robert Watson : > On Sat, 11 Apr 2009, Andrew Brampton wrote: > > Your understanding is mostly right. =C2=A0The missing bit is this: there = are two > kinds of interrupt contexts -- fast/filter interrupt handlers, which borr= ow > the stack and execution context of the kernel thread they preempt, and > interrupt threads, which get their own complete thread context. > > Fast interrupt handlers are allowed unlock to acquire spinlocks so as to > avoid deadlock because of the borrowed context. =C2=A0This means they can= 't > perform any sort of sleep, or acquire any locks that might sleep, since t= he > thread they've preempted may hold conflicting locks, or be the one that > would have woken up the sleep that the handler performed. =C2=A0Almost no= code > will run in fast handlers -- perhaps checking some device registers, doin= g > work on a lockless or spinlock-protected queue, and waking up a worker > thread. > > This is why, BTW, spin locks disable interrupt: they need to control > preemption by other interrupt handlers to avoid deadlock, but they are no= t > intended for use except when either in the scheduler, in a few related IP= I > contexts, or when synchronizing between normal kernel code and a fast > handler. > > Full interrupt thread contexts are permitted to perform short lock sleeps= , > such as those performed when contending default mutexes, rwlocks, and > rmlocks. They are permitted to invoke kernel services such as malloc(9), > UMA(9), the network stack, etc, as long as they use M_NOWAIT and don't > invoke msleep(9) or similar unbounded sleeps -- again to avoid the > possibility of deadlocks, since you don't want an interrupt thread sleepi= ng > waiting for an event that only it can satisfy. > > So the first question, really, is whether you are or mean to be using > fast/filter interrupt handler. =C2=A0Device drivers will never call memor= y > allocation, free, etc, from there, but will defer it to an ithread using = the > filter mechanism in 8.x, or to a task queue or other worker in 7.x and > earlier. =C2=A0If you're using a regular INTR_MPSAFE ithread, you should = be able > to use only default mutexes (a single atomic operation if uncontended) > without disabling interrupts, etc. > > Robert N M Watson > Computer Laboratory > University of Cambridge > Thanks very much for your detailed reply. I'm slowly understanding how everything in FreeBSD fits together, and I appreciate your help. I've been given a project to take over, and all of the design decisions were made before I started working on it, thus I'm playing catch up. One of the decisions was to implement their own version of a spin lock, which literally looks something like this: lock_aquire() { critical_enter(); while (! lockHeld ) {} lockHeld++; } This was actually the code tripping up MemGuard, as it is inside a critical section, which MemGuard is unable to sleep within. This is all running inside a kthread_create thread (I'm unsure of the proper name of this type of thread). Anyway, that is why I also asked about a lighter weight spin lock (perhaps similar to this one). I tempted to replace this custom spinlock with the standard MTX_DEF, however I'm unsure of its impact. The custom spin lock seems quick and light to acquire, and it does not concern me that a interrupt can potentially interrupt the code. On a related note, if you change the lock in memguard to a MTX_SPIN, it panics the kernel during boot. So that is not an option :) I was only using memguard because I suspected memory being used after it was freed. However, I think I will either change my locks to MTX_DEF or live without memguard. I realise I've not really asked any questions, but I would be grateful for any insights anyone may have. Andrew From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 11 21:10:25 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B344106566B for ; Sat, 11 Apr 2009 21:10:25 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from mta1.srv.hcvlny.cv.net (mta1.srv.hcvlny.cv.net [167.206.4.196]) by mx1.freebsd.org (Postfix) with ESMTP id E3FAB8FC19 for ; Sat, 11 Apr 2009 21:10:24 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from flosoft.no-ip.biz (ool-435559b8.dyn.optonline.net [67.85.89.184]) by mta1.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0KHY002JMG5A0HB0@mta1.srv.hcvlny.cv.net> for freebsd-hackers@freebsd.org; Sat, 11 Apr 2009 17:10:22 -0400 (EDT) Received: from flosoft.no-ip.biz (localhost [127.0.0.1]) by flosoft.no-ip.biz (8.14.3/8.14.3) with ESMTP id n3BLALNp001653; Sat, 11 Apr 2009 17:10:22 -0400 Date: Sat, 11 Apr 2009 17:10:21 -0400 From: "Aryeh M. Friedman" In-reply-to: <49E10406.7060006@gmail.com> To: freebsd-hackers@freebsd.org Message-id: <49E1073D.2090303@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT References: <49E10406.7060006@gmail.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090331) Subject: Re: setting up local authorative name server with a no-ip.com registered domain X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 21:10:26 -0000 Aryeh M. Friedman wrote: > I have 3 domains that are registered with no-ip.com > (istudentunion.com, org and net). All three are also using their > "no-ip plus" service which provides both static and dynamic resolution > via their nameservers. When I configure the domains nameservers to > be theirs everything works great (for the most part), but when I > change the nameservers to my own sites BIND (base 7.3-RELEASE) I can > get everything to resolve locally and via dig/host/nslookup remotely > (if and only if I specify the nameserver by IP). What appears to be > happing is this: > > ~/Desktop:aryeh@flosoft% !d > dig ns istudentunion.org +trace > > ; <<>> DiG 9.4.3-P2 <<>> ns istudentunion.org +trace > ;; global options: printcmd > . 463753 IN NS I.ROOT-SERVERS.NET. > . 463753 IN NS C.ROOT-SERVERS.NET. > . 463753 IN NS L.ROOT-SERVERS.NET. > . 463753 IN NS K.ROOT-SERVERS.NET. > . 463753 IN NS M.ROOT-SERVERS.NET. > . 463753 IN NS A.ROOT-SERVERS.NET. > . 463753 IN NS E.ROOT-SERVERS.NET. > . 463753 IN NS B.ROOT-SERVERS.NET. > . 463753 IN NS H.ROOT-SERVERS.NET. > . 463753 IN NS D.ROOT-SERVERS.NET. > . 463753 IN NS G.ROOT-SERVERS.NET. > . 463753 IN NS F.ROOT-SERVERS.NET. > . 463753 IN NS J.ROOT-SERVERS.NET. > ;; Received 500 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms > > org. 172800 IN NS B2.ORG.AFILIAS-NST.org. > org. 172800 IN NS A2.ORG.AFILIAS-NST.INFO. > org. 172800 IN NS C0.ORG.AFILIAS-NST.INFO. > org. 172800 IN NS B0.ORG.AFILIAS-NST.org. > org. 172800 IN NS A0.ORG.AFILIAS-NST.INFO. > org. 172800 IN NS D0.ORG.AFILIAS-NST.org. > ;; Received 437 bytes from 192.203.230.10#53(E.ROOT-SERVERS.NET) in 86 ms > > istudentunion.org. 86400 IN NS ns2.istudentunion.org. > istudentunion.org. 86400 IN NS ns1.istudentunion.org. > ;; Received 103 bytes from 199.19.54.1#53(B0.ORG.AFILIAS-NST.org) in > 88 ms > > ;; connection timed out; no servers could be reached > > Quick additional note we upgraded all 3 domains to no-ip plus because they assured us that we could run our own dns From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 11 21:26:45 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A1AE10656C3 for ; Sat, 11 Apr 2009 21:26:45 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ew0-f171.google.com (mail-ew0-f171.google.com [209.85.219.171]) by mx1.freebsd.org (Postfix) with ESMTP id EE2818FC1E for ; Sat, 11 Apr 2009 21:26:44 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by ewy19 with SMTP id 19so1507720ewy.43 for ; Sat, 11 Apr 2009 14:26:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=nVl62KpyO9+CjPDWPB+8OEZEWu/qXwwR7bOvTFHwKE8=; b=PkYiC7uWcZ/ePpCd8cqIuQNg2fbyxs8Wsf7dVT7HpC2L7e7uYGa3zHKAKxy+JjS3kS 6BcCZt/oX3vEz6eJNDDkzlZBk4VeyXtQg9Abhvh52h14Pp3E56NV9Uhn/cblZKvDaf9X gP4v13B7NmPB7m1HxBoYIO+NZV7im2+LCW+RE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tNY1Hz9V9TojeylAN5khqUJ2SUF29Zo67ql1jIM6dehy4N33MOrdA0ppYFtbf6p8ws BGNL4ndZLoZo+NRKPXIb3lqxjxRYuJ5lhnvcmsy6YNZBzSQ5FJoy+cMqJ6BuZy8sklmV F/RRVa58M9jh6gxqzXaONVlcOlv285N1RqTHs= MIME-Version: 1.0 Received: by 10.210.111.17 with SMTP id j17mr712739ebc.13.1239485204017; Sat, 11 Apr 2009 14:26:44 -0700 (PDT) In-Reply-To: <20090411101559.GC83697@logik.internal.network> References: <20090410132354.GA20721@logik.internal.network> <20090410154251.GA49384@logik.internal.network> <1239385368.1922.74.camel@balrog.2hip.net> <20090410175922.GA50520@logik.internal.network> <1239388293.1922.80.camel@balrog.2hip.net> <20090410211307.GA83697@logik.internal.network> <3a142e750904101730k53b7fbabn6e801ac36f1182e0@mail.gmail.com> <20090411101559.GC83697@logik.internal.network> Date: Sat, 11 Apr 2009 23:26:43 +0200 Message-ID: <3a142e750904111426u43c11a38wc6b385d3ff215673@mail.gmail.com> From: "Paul B. Mahol" To: xorquewasp@googlemail.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: diagnosing freezes (DRI?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 21:26:45 -0000 On 4/11/09, xorquewasp@googlemail.com wrote: > On 2009-04-11 02:30:40, Paul B. Mahol wrote: >> >> If it locks under X11 then use debug.debugger_on_panic=0 sysctl. >> Not doing this will increase drasticaly chances of locking whole system >> and not providing any debug data. > > I don't seem to have that sysctl. > > You sure that's the correct name? Well if you dont have it, capturing cores should generaly still work. But in this case some kind of serial console is only remaining option. -- Paul From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 11 21:39:00 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E7881065676 for ; Sat, 11 Apr 2009 21:39:00 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 15D008FC1C for ; Sat, 11 Apr 2009 21:39:00 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id A647446B39; Sat, 11 Apr 2009 17:38:59 -0400 (EDT) Date: Sat, 11 Apr 2009 22:38:59 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andrew Brampton In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD memguard + spinlocks X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Apr 2009 21:39:01 -0000 On Sat, 11 Apr 2009, Andrew Brampton wrote: > Thanks very much for your detailed reply. I'm slowly understanding how > everything in FreeBSD fits together, and I appreciate your help. > > I've been given a project to take over, and all of the design decisions were > made before I started working on it, thus I'm playing catch up. One of the > decisions was to implement their own version of a spin lock, which literally > looks something like this: > > lock_aquire() { > critical_enter(); > while (! lockHeld ) {} > lockHeld++; > } > > This was actually the code tripping up MemGuard, as it is inside a critical > section, which MemGuard is unable to sleep within. This is all running > inside a kthread_create thread (I'm unsure of the proper name of this type > of thread). > > Anyway, that is why I also asked about a lighter weight spin lock (perhaps > similar to this one). I tempted to replace this custom spinlock with the > standard MTX_DEF, however I'm unsure of its impact. The custom spin lock > seems quick and light to acquire, and it does not concern me that a > interrupt can potentially interrupt the code. > > On a related note, if you change the lock in memguard to a MTX_SPIN, it > panics the kernel during boot. So that is not an option :) I was only using > memguard because I suspected memory being used after it was freed. However, > I think I will either change my locks to MTX_DEF or live without memguard. > > I realise I've not really asked any questions, but I would be grateful for > any insights anyone may have. Andrew My advice, unless you're definitely executing code in fast interrupt contexts, is to simply use the FreeBSD default mutex primitive instead of either a custom-build spinlock or a FreeBSD MTX_SPIN mutex. The default mutex is adaptive, and will spin when contending the lock unless the thread holding the lock isn't executing, in which case it will fall back on a context switch. Our mutexes also make correct use of memory barriers, which the above example code doesn't appear to, so will work on systems that have weaker memory ordering properties. Using the default mutex scheme also allows you to take advantage of WITNESS, our lock order verifier, which proves a really useful tool when a lot of locks are in flight. The critical sections you're using above may not have the effect you intend: they prevent preemption by another thread, and they prevent migration to another CPU, but they don't prevent fast interrupt handlers from executing. Any synchronization with a fast interrupt handler needs to be done either using spinlocks, or other atomic operations. Robert N M Watson Computer Laboratory University of Cambridge