From owner-freebsd-current@FreeBSD.ORG Thu Jan 1 03:09:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E271A106568A; Thu, 1 Jan 2009 03:09:07 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 2B4A38FC18; Thu, 1 Jan 2009 03:09:05 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from [10.123.2.23] (p53.kientzle.com [66.166.149.53]) by kientzle.com (8.12.9/8.12.9) with ESMTP id n012VKtv005170; Wed, 31 Dec 2008 18:31:20 -0800 (PST) (envelope-from tim@kientzle.com) Message-ID: <495C2AF5.6030703@kientzle.com> Date: Wed, 31 Dec 2008 18:31:17 -0800 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060422 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Kientzle References: <200812301616.11132.max@love2party.net> <200812302213.07155.max@love2party.net> <20081231094159.GA964@zaphod.nitro.dk> <200812311109.57955.max@love2party.net> <20081231105952.GB964@zaphod.nitro.dk> <495C017F.9000408@freebsd.org> In-Reply-To: <495C017F.9000408@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Max Laier , freebsd-current@freebsd.org, cperciva@freebsd.org, "Simon L. Nielsen" Subject: Re: tar/libarchive gzip problem [was: portsnap corrupted] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2009 03:09:08 -0000 I just committed a fix for this (r186670). Please let me know if you see any other problems. Tim Tim Kientzle wrote: > I think I know what this is. I tried recently to add > support for concatenated gzip files. This involves looking > ahead for another GZip header after the end of the compressed > data. The current version screws this up and ends up trying > to match the file CRC as a Gzip header. About 1 in 256 files > will match the first byte, which triggers the subsequent meltdown. > This also explains why neither of us saw it in testing. > (I knew the code didn't actually work for concatenated gzip > files but didn't realize it would break decode of some > regular non-concatenated files.) > > The attached patch simply disables this additional > header check, which should fix the immediate problem. > Please try it and let me know. > > Apologies, > > Tim > > Simon L. Nielsen wrote: > >> Hey Tim, >> >> I think one of the recent changes to tar or libarchive broke gzip >> handling in some cases. See more below. >> >> [portsnap extract fails with gzip error] >> >> I'm not sure why I didn't run into it in my tests, but I think the >> problem is in tar / libarchive's handling of gzip files. Taking one >> random "broken" file [1] it fails with tar's build in decompression, >> but works using external zcat. >> >> [1] >> http://portsnap1.freebsd.org/f/19faa3b8bd15bb8f4cd9f665a7623887729f3bd834d780e8b069df979f228e8d.gz >> >> http://people.freebsd.org/~simon/tmp/19faa3b8bd15bb8f4cd9f665a7623887729f3bd834d780e8b069df979f228e8d.gz >> >> >> >> Broken system: >> >> [simon@eddie:/tmp] tar --version >> bsdtar 2.5.903a - libarchive 2.5.903a >> [simon@eddie:/tmp] uname -a >> FreeBSD eddie.nitro.dk 8.0-CURRENT FreeBSD 8.0-CURRENT #1: Tue Dec 30 >> 22:28:33 CET 2008 >> simon@eddie.nitro.dk:/FreeBSD/obj/FreeBSD/system-CURRENT/sys/EDDIE i386 >> [simon@eddie:/tmp] tar tvf >> 19faa3b8bd15bb8f4cd9f665a7623887729f3bd834d780e8b069df979f228e8d.gz > >> /dev/null >> tar: Error opening archive: Invalid GZip header (saw 99 at offset 1) >> [simon@eddie:/tmp] zcat >> 19faa3b8bd15bb8f4cd9f665a7623887729f3bd834d780e8b069df979f228e8d.gz | >> tar tf - > /dev/null [simon@eddie:/tmp] zcat >> 19faa3b8bd15bb8f4cd9f665a7623887729f3bd834d780e8b069df979f228e8d.gz | >> sha256 19faa3b8bd15bb8f4cd9f665a7623887729f3bd834d780e8b069df979f228e8d >> >> >> OK system: >> >> [simon@benji:/tmp] tar --version >> bsdtar 2.5.5 - libarchive 2.5.5 >> [simon@benji:/tmp] uname -a >> FreeBSD benji.s 7.1-RC2 FreeBSD 7.1-RC2 #0: Tue Dec 23 15:18:30 UTC >> 2008 root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 >> [simon@benji:/tmp] tar tvf >> 19faa3b8bd15bb8f4cd9f665a7623887729f3bd834d780e8b069df979f228e8d.gz > >> /dev/null [simon@benji:/tmp] zcat >> 19faa3b8bd15bb8f4cd9f665a7623887729f3bd834d780e8b069df979f228e8d.gz | >> sha256 19faa3b8bd15bb8f4cd9f665a7623887729f3bd834d780e8b069df979f228e8d >> >> >> Another OK system: >> >> [simon@ref8-amd64:files] tar --version >> bsdtar 2.5.5 - libarchive 2.5.5 >> [simon@ref8-amd64:files] uname -a >> FreeBSD ref8-amd64.freebsd.org 8.0-CURRENT FreeBSD 8.0-CURRENT #2 >> r184542:185402: Fri Nov 28 19:14:40 UTC 2008 >> peter@ref8-amd64.freebsd.org:/scratch/src/sys/amd64/compile/REF8-AMD64 >> amd64 >> [simon@ref8-amd64:files] tar tvf >> 19faa3b8bd15bb8f4cd9f665a7623887729f3bd834d780e8b069df979f228e8d.gz > >> /dev/null >> [simon@ref8-amd64:files] zcat >> 19faa3b8bd15bb8f4cd9f665a7623887729f3bd834d780e8b069df979f228e8d.gz | >> sha256 >> 19faa3b8bd15bb8f4cd9f665a7623887729f3bd834d780e8b069df979f228e8d >> > > ------------------------------------------------------------------------ > > Index: archive_read_support_compression_gzip.c > =================================================================== > --- archive_read_support_compression_gzip.c (revision 185679) > +++ archive_read_support_compression_gzip.c (working copy) > @@ -428,8 +428,7 @@ > "Failed to clean up gzip decompressor"); > return (ARCHIVE_FATAL); > } > - /* Restart header parser with the next block. */ > - state->header_state = state->header_done = 0; > + state->eof = 1; > /* FALL THROUGH */ > case Z_OK: /* Decompressor made some progress. */ > /* If we filled our buffer, update stats and return. */ From owner-freebsd-current@FreeBSD.ORG Thu Jan 1 03:16:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0618E1065672 for ; Thu, 1 Jan 2009 03:16:12 +0000 (UTC) (envelope-from jos@catnook.com) Received: from lizzy.dyndns.org (209-204-188-132.dsl.static.sonic.net [209.204.188.132]) by mx1.freebsd.org (Postfix) with SMTP id 6A4518FC14 for ; Thu, 1 Jan 2009 03:16:11 +0000 (UTC) (envelope-from jos@catnook.com) Received: (qmail 33686 invoked by uid 1000); 1 Jan 2009 03:16:34 -0000 Date: Wed, 31 Dec 2008 19:16:34 -0800 From: Jos Backus To: Marcel Moolenaar Message-ID: <20090101031634.GD64075@lizzy.catnook.local> References: <3a142e750812201747o339d7298p11236bb02c7f858f@mail.gmail.com> <20081223050425.GA89448@citylink.fud.org.nz> <6D4A57D3-3F6D-43E6-9B69-95514F69C57A@mac.com> <20081226080146.GB25406@dragon.NUXI.org> <20081227191223.GB31177@lizzy.catnook.local> <9F29EF5C-B4FD-4273-8BE9-C134B983A1E1@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9F29EF5C-B4FD-4273-8BE9-C134B983A1E1@mac.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: Changed names of logical disks on recent -CURRENT: part of logical disks not accessible now X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jos@catnook.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2009 03:16:12 -0000 Hi Marcel, On Mon, Dec 29, 2008 at 10:11:03PM -0800, Marcel Moolenaar wrote: > I've seen this before: Erase the second sector on your > disk. You likely have a stale BSD disklabel there. Before I start erasing, does this look like something that can be erased safely? lizzy:~# dd if=/dev/ad0 count=1 skip=1 | hexdump -C 1+0 records in 1+0 records out 512 bytes transferred in 0.009828 secs (52096 bytes/sec) 00000000 57 45 56 82 00 00 00 00 61 6d 6e 65 73 69 61 63 |WEV.....amnesiac| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 00 00 00 00 00 00 00 00 00 02 00 00 3f 00 00 00 |............?...| 00000030 10 00 00 00 15 ed 12 00 f0 03 00 00 b0 82 85 4a |...............J| 00000040 00 00 00 00 00 00 00 00 10 0e 01 00 00 00 00 00 |................| 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000080 00 00 00 00 57 45 56 82 a8 07 08 00 00 20 00 00 |....WEV...... ..| 00000090 00 00 00 00 00 00 20 00 10 00 00 00 00 08 00 00 |...... .........| 000000a0 07 08 88 6f 00 00 80 00 10 00 20 00 00 00 00 00 |...o...... .....| 000000b0 01 00 00 00 b0 82 85 4a 00 00 00 00 00 00 00 00 |.......J........| 000000c0 00 00 00 00 00 00 20 00 10 00 a0 00 00 08 00 00 |...... .........| 000000d0 07 08 88 6f 00 00 00 04 10 00 c0 00 00 08 00 00 |...o............| 000000e0 07 08 88 6f a0 82 c5 45 10 00 c0 04 00 08 00 00 |...o...E........| 000000f0 07 08 88 6f 00 00 00 00 00 00 00 00 00 00 00 00 |...o............| 00000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000200 Or do you mean /dev/ad0s1? (I thought disklabels generally sit inside fdisk partitions^Wslices.) lizzy:~# dd if=/dev/ad0s1 count=1 skip=1 | hexdump -C 1+0 records in 1+0 records out 512 bytes transferred in 0.016460 secs (31105 bytes/sec) 00000000 57 45 56 82 00 00 00 00 61 6d 6e 65 73 69 61 63 |WEV.....amnesiac| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 00 00 00 00 00 00 00 00 00 02 00 00 3f 00 00 00 |............?...| 00000030 10 00 00 00 14 ed 12 00 f0 03 00 00 71 82 85 4a |............q..J| 00000040 00 00 00 00 00 00 00 00 10 0e 01 00 00 00 00 00 |................| 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000080 00 00 00 00 57 45 56 82 68 07 08 00 00 20 00 00 |....WEV.h.... ..| 00000090 00 00 00 00 00 00 20 00 10 00 00 00 00 08 00 00 |...... .........| 000000a0 07 08 88 6f 00 00 80 00 10 00 20 00 00 00 00 00 |...o...... .....| 000000b0 01 00 00 00 71 82 85 4a 00 00 00 00 00 00 00 00 |....q..J........| 000000c0 00 00 00 00 00 00 20 00 10 00 a0 00 00 08 00 00 |...... .........| 000000d0 07 08 88 6f 00 00 00 04 10 00 c0 00 00 08 00 00 |...o............| 000000e0 07 08 88 6f 61 82 c5 45 10 00 c0 04 00 08 00 00 |...oa..E........| 000000f0 07 08 88 6f 00 00 00 00 00 00 00 00 00 00 00 00 |...o............| 00000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000110 00 00 00 00 eb 0e 42 54 58 01 02 80 f6 0f 80 06 |......BTX.......| 00000120 00 20 00 00 fa 31 c0 8e d0 bc 00 18 8e c0 8e d8 |. ...1..........| 00000130 66 6a 02 66 9d bf 00 5e b9 00 19 f3 ab bb 22 95 |fj.f...^......".| 00000140 b9 10 00 bf 80 00 89 1d 47 47 ab 83 c3 04 e2 f6 |........GG......| 00000150 bf 00 5e be d2 95 ac 98 91 e3 1d ac 92 ad 93 ad |..^.............| 00000160 b6 08 d1 eb 73 0b 89 05 88 75 02 88 55 05 83 c0 |....s....u..U...| 00000170 04 8d 7d 08 e2 ec eb de c6 45 05 18 c6 45 08 10 |..}......E...E..| 00000180 c6 45 66 68 bb 20 28 e8 b8 00 0f 01 1e c6 95 0f |.Efh. (.........| 00000190 01 16 c0 95 0f 20 c0 40 0f 22 c0 ea 8c 90 08 00 |..... .@."......| 000001a0 31 c9 b1 10 8e d1 b1 38 0f 00 d9 ba 00 a0 00 00 |1......8........| 000001b0 36 0f b7 05 13 04 00 00 c1 e0 0a 2d 00 10 00 00 |6..........-....| 000001c0 29 d0 b1 33 51 50 68 02 02 00 00 6a 2b ff 35 0c |)..3QPh....j+.5.| 000001d0 90 00 00 51 51 51 51 52 b1 07 6a 00 e2 fc 61 07 |...QQQQR..j...a.| 000001e0 1f 0f a1 0f a9 cf fa bc 00 18 00 00 0f 20 c0 25 |............. .%| 000001f0 ff ff ff 7f 0f 22 c0 31 c9 0f 22 d9 0f 01 15 c0 |.....".1..".....| 00000200 Thanks and Happy New Year! Groetjes, -- Jos Backus jos at catnook.com From owner-freebsd-current@FreeBSD.ORG Thu Jan 1 05:20:19 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8687E10658AF; Thu, 1 Jan 2009 05:20:19 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 10D6C8FC1A; Thu, 1 Jan 2009 05:20:18 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n015KIeE083427; Thu, 1 Jan 2009 00:20:18 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n015KIb1077667; Thu, 1 Jan 2009 00:20:18 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E15197302F; Thu, 1 Jan 2009 00:20:17 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090101052017.E15197302F@freebsd-current.sentex.ca> Date: Thu, 1 Jan 2009 00:20:17 -0500 (EST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2009 05:20:20 -0000 TB --- 2009-01-01 03:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-01-01 03:00:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2009-01-01 03:00:00 - cleaning the object tree TB --- 2009-01-01 03:00:51 - cvsupping the source tree TB --- 2009-01-01 03:00:51 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2009-01-01 03:05:49 - building world TB --- 2009-01-01 03:05:49 - MAKEOBJDIRPREFIX=/obj TB --- 2009-01-01 03:05:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-01-01 03:05:49 - TARGET=amd64 TB --- 2009-01-01 03:05:49 - TARGET_ARCH=amd64 TB --- 2009-01-01 03:05:49 - TZ=UTC TB --- 2009-01-01 03:05:49 - __MAKE_CONF=/dev/null TB --- 2009-01-01 03:05:49 - cd /src TB --- 2009-01-01 03:05:49 - /usr/bin/make -B buildworld >>> World build started on Thu Jan 1 03:05:50 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Thu Jan 1 05:02:36 UTC 2009 TB --- 2009-01-01 05:02:36 - generating LINT kernel config TB --- 2009-01-01 05:02:36 - cd /src/sys/amd64/conf TB --- 2009-01-01 05:02:36 - /usr/bin/make -B LINT TB --- 2009-01-01 05:02:37 - building LINT kernel TB --- 2009-01-01 05:02:37 - MAKEOBJDIRPREFIX=/obj TB --- 2009-01-01 05:02:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-01-01 05:02:37 - TARGET=amd64 TB --- 2009-01-01 05:02:37 - TARGET_ARCH=amd64 TB --- 2009-01-01 05:02:37 - TZ=UTC TB --- 2009-01-01 05:02:37 - __MAKE_CONF=/dev/null TB --- 2009-01-01 05:02:37 - cd /src TB --- 2009-01-01 05:02:37 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jan 1 05:02:37 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] kern_mib.o(.bss+0x2b8): multiple definition of `elf64_fallback_brand' imgact_elf.o(.data+0x0): first defined here elf_machdep.o(.bss+0x0): multiple definition of `elf64_fallback_brand' imgact_elf.o(.data+0x0): first defined here imgact_elf32.o(.data+0x0): multiple definition of `elf32_fallback_brand' ia32_sysvec.o(.bss+0x0): first defined here linux32_sysvec.o(.bss+0x0): multiple definition of `elf32_fallback_brand' ia32_sysvec.o(.bss+0x0): first defined here *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-01-01 05:20:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-01-01 05:20:17 - ERROR: failed to build lint kernel TB --- 2009-01-01 05:20:17 - 6447.54 user 641.41 system 8417.14 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Thu Jan 1 05:57:06 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14D41106566C; Thu, 1 Jan 2009 05:57:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id C96F98FC19; Thu, 1 Jan 2009 05:57:05 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n015v53m084844; Thu, 1 Jan 2009 00:57:05 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n015v4sG085660; Thu, 1 Jan 2009 00:57:05 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id C0F9B7302F; Thu, 1 Jan 2009 00:57:04 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090101055704.C0F9B7302F@freebsd-current.sentex.ca> Date: Thu, 1 Jan 2009 00:57:04 -0500 (EST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2009 05:57:06 -0000 TB --- 2009-01-01 04:10:31 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-01-01 04:10:31 - starting HEAD tinderbox run for i386/i386 TB --- 2009-01-01 04:10:31 - cleaning the object tree TB --- 2009-01-01 04:10:58 - cvsupping the source tree TB --- 2009-01-01 04:10:58 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2009-01-01 04:16:26 - building world TB --- 2009-01-01 04:16:26 - MAKEOBJDIRPREFIX=/obj TB --- 2009-01-01 04:16:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-01-01 04:16:26 - TARGET=i386 TB --- 2009-01-01 04:16:26 - TARGET_ARCH=i386 TB --- 2009-01-01 04:16:26 - TZ=UTC TB --- 2009-01-01 04:16:26 - __MAKE_CONF=/dev/null TB --- 2009-01-01 04:16:26 - cd /src TB --- 2009-01-01 04:16:26 - /usr/bin/make -B buildworld >>> World build started on Thu Jan 1 04:16:27 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Jan 1 05:37:29 UTC 2009 TB --- 2009-01-01 05:37:29 - generating LINT kernel config TB --- 2009-01-01 05:37:29 - cd /src/sys/i386/conf TB --- 2009-01-01 05:37:29 - /usr/bin/make -B LINT TB --- 2009-01-01 05:37:29 - building LINT kernel TB --- 2009-01-01 05:37:29 - MAKEOBJDIRPREFIX=/obj TB --- 2009-01-01 05:37:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-01-01 05:37:29 - TARGET=i386 TB --- 2009-01-01 05:37:29 - TARGET_ARCH=i386 TB --- 2009-01-01 05:37:29 - TZ=UTC TB --- 2009-01-01 05:37:29 - __MAKE_CONF=/dev/null TB --- 2009-01-01 05:37:29 - cd /src TB --- 2009-01-01 05:37:29 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jan 1 05:37:29 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] kern_mib.o(.bss+0x25c): multiple definition of `elf32_fallback_brand' imgact_elf.o(.data+0x0): first defined here svr4_sysvec.o(.bss+0x0): multiple definition of `elf32_fallback_brand' imgact_elf.o(.data+0x0): first defined here elf_machdep.o(.bss+0x0): multiple definition of `elf32_fallback_brand' imgact_elf.o(.data+0x0): first defined here linux_sysvec.o(.bss+0x0): multiple definition of `elf32_fallback_brand' imgact_elf.o(.data+0x0): first defined here *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-01-01 05:57:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-01-01 05:57:04 - ERROR: failed to build lint kernel TB --- 2009-01-01 05:57:04 - 4847.55 user 442.29 system 6393.62 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Thu Jan 1 07:03:35 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE9D7106564A; Thu, 1 Jan 2009 07:03:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id A01FE8FC14; Thu, 1 Jan 2009 07:03:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n0173ZGQ086767; Thu, 1 Jan 2009 02:03:35 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n0173YiE099649; Thu, 1 Jan 2009 02:03:34 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id AB7957302F; Thu, 1 Jan 2009 02:03:34 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090101070334.AB7957302F@freebsd-current.sentex.ca> Date: Thu, 1 Jan 2009 02:03:34 -0500 (EST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2009 07:03:36 -0000 TB --- 2009-01-01 05:20:17 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-01-01 05:20:17 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-01-01 05:20:17 - cleaning the object tree TB --- 2009-01-01 05:20:50 - cvsupping the source tree TB --- 2009-01-01 05:20:50 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-01-01 05:26:14 - building world TB --- 2009-01-01 05:26:14 - MAKEOBJDIRPREFIX=/obj TB --- 2009-01-01 05:26:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-01-01 05:26:14 - TARGET=pc98 TB --- 2009-01-01 05:26:14 - TARGET_ARCH=i386 TB --- 2009-01-01 05:26:14 - TZ=UTC TB --- 2009-01-01 05:26:14 - __MAKE_CONF=/dev/null TB --- 2009-01-01 05:26:14 - cd /src TB --- 2009-01-01 05:26:14 - /usr/bin/make -B buildworld >>> World build started on Thu Jan 1 05:26:16 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Jan 1 06:46:51 UTC 2009 TB --- 2009-01-01 06:46:51 - generating LINT kernel config TB --- 2009-01-01 06:46:51 - cd /src/sys/pc98/conf TB --- 2009-01-01 06:46:51 - /usr/bin/make -B LINT TB --- 2009-01-01 06:46:51 - building LINT kernel TB --- 2009-01-01 06:46:51 - MAKEOBJDIRPREFIX=/obj TB --- 2009-01-01 06:46:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-01-01 06:46:51 - TARGET=pc98 TB --- 2009-01-01 06:46:51 - TARGET_ARCH=i386 TB --- 2009-01-01 06:46:51 - TZ=UTC TB --- 2009-01-01 06:46:51 - __MAKE_CONF=/dev/null TB --- 2009-01-01 06:46:51 - cd /src TB --- 2009-01-01 06:46:51 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jan 1 06:46:51 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] kern_mib.o(.bss+0x25c): multiple definition of `elf32_fallback_brand' imgact_elf.o(.data+0x0): first defined here svr4_sysvec.o(.bss+0x0): multiple definition of `elf32_fallback_brand' imgact_elf.o(.data+0x0): first defined here elf_machdep.o(.bss+0x0): multiple definition of `elf32_fallback_brand' imgact_elf.o(.data+0x0): first defined here linux_sysvec.o(.bss+0x0): multiple definition of `elf32_fallback_brand' imgact_elf.o(.data+0x0): first defined here *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-01-01 07:03:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-01-01 07:03:34 - ERROR: failed to build lint kernel TB --- 2009-01-01 07:03:34 - 4672.82 user 444.89 system 6196.53 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Thu Jan 1 08:11:31 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92316106564A; Thu, 1 Jan 2009 08:11:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 547168FC12; Thu, 1 Jan 2009 08:11:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n018BUq8089422; Thu, 1 Jan 2009 03:11:30 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n018BUWq008285; Thu, 1 Jan 2009 03:11:30 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 59DFB7302F; Thu, 1 Jan 2009 03:11:29 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090101081130.59DFB7302F@freebsd-current.sentex.ca> Date: Thu, 1 Jan 2009 03:11:29 -0500 (EST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2009 08:11:32 -0000 TB --- 2009-01-01 05:57:04 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-01-01 05:57:04 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-01-01 05:57:04 - cleaning the object tree TB --- 2009-01-01 05:57:37 - cvsupping the source tree TB --- 2009-01-01 05:57:37 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-01-01 06:02:41 - building world TB --- 2009-01-01 06:02:41 - MAKEOBJDIRPREFIX=/obj TB --- 2009-01-01 06:02:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-01-01 06:02:41 - TARGET=ia64 TB --- 2009-01-01 06:02:41 - TARGET_ARCH=ia64 TB --- 2009-01-01 06:02:41 - TZ=UTC TB --- 2009-01-01 06:02:41 - __MAKE_CONF=/dev/null TB --- 2009-01-01 06:02:41 - cd /src TB --- 2009-01-01 06:02:41 - /usr/bin/make -B buildworld >>> World build started on Thu Jan 1 06:02:42 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Jan 1 07:49:00 UTC 2009 TB --- 2009-01-01 07:49:00 - generating LINT kernel config TB --- 2009-01-01 07:49:00 - cd /src/sys/ia64/conf TB --- 2009-01-01 07:49:00 - /usr/bin/make -B LINT TB --- 2009-01-01 07:49:00 - building LINT kernel TB --- 2009-01-01 07:49:00 - MAKEOBJDIRPREFIX=/obj TB --- 2009-01-01 07:49:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-01-01 07:49:00 - TARGET=ia64 TB --- 2009-01-01 07:49:00 - TARGET_ARCH=ia64 TB --- 2009-01-01 07:49:00 - TZ=UTC TB --- 2009-01-01 07:49:00 - __MAKE_CONF=/dev/null TB --- 2009-01-01 07:49:00 - cd /src TB --- 2009-01-01 07:49:00 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jan 1 07:49:00 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] kern_mib.o(.sbss+0x88): multiple definition of `elf64_fallback_brand' imgact_elf.o(.sdata+0x0): first defined here ia32_signal.o(.sbss+0x0): multiple definition of `elf32_fallback_brand' ia32_sysvec.o(.sbss+0x8): first defined here elf_machdep.o(.sbss+0x4): multiple definition of `elf64_fallback_brand' imgact_elf.o(.sdata+0x0): first defined here imgact_elf32.o(.sdata+0x0): multiple definition of `elf32_fallback_brand' ia32_sysvec.o(.sbss+0x8): first defined here *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-01-01 08:11:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-01-01 08:11:28 - ERROR: failed to build lint kernel TB --- 2009-01-01 08:11:28 - 6455.54 user 443.66 system 8063.12 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Thu Jan 1 08:49:25 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15AF5106566B; Thu, 1 Jan 2009 08:49:25 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id E12AC8FC18; Thu, 1 Jan 2009 08:49:24 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n018nOQs090720; Thu, 1 Jan 2009 03:49:24 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n018nOIJ015606; Thu, 1 Jan 2009 03:49:24 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 419C07302F; Thu, 1 Jan 2009 03:49:24 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090101084924.419C07302F@freebsd-current.sentex.ca> Date: Thu, 1 Jan 2009 03:49:24 -0500 (EST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on clamscanner1 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2009 08:49:25 -0000 TB --- 2009-01-01 07:03:34 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-01-01 07:03:34 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2009-01-01 07:03:34 - cleaning the object tree TB --- 2009-01-01 07:03:59 - cvsupping the source tree TB --- 2009-01-01 07:03:59 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2009-01-01 07:09:19 - building world TB --- 2009-01-01 07:09:19 - MAKEOBJDIRPREFIX=/obj TB --- 2009-01-01 07:09:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-01-01 07:09:19 - TARGET=powerpc TB --- 2009-01-01 07:09:19 - TARGET_ARCH=powerpc TB --- 2009-01-01 07:09:19 - TZ=UTC TB --- 2009-01-01 07:09:19 - __MAKE_CONF=/dev/null TB --- 2009-01-01 07:09:19 - cd /src TB --- 2009-01-01 07:09:19 - /usr/bin/make -B buildworld >>> World build started on Thu Jan 1 07:09:21 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Jan 1 08:34:10 UTC 2009 TB --- 2009-01-01 08:34:10 - generating LINT kernel config TB --- 2009-01-01 08:34:10 - cd /src/sys/powerpc/conf TB --- 2009-01-01 08:34:10 - /usr/bin/make -B LINT TB --- 2009-01-01 08:34:10 - building LINT kernel TB --- 2009-01-01 08:34:10 - MAKEOBJDIRPREFIX=/obj TB --- 2009-01-01 08:34:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-01-01 08:34:10 - TARGET=powerpc TB --- 2009-01-01 08:34:10 - TARGET_ARCH=powerpc TB --- 2009-01-01 08:34:10 - TZ=UTC TB --- 2009-01-01 08:34:10 - __MAKE_CONF=/dev/null TB --- 2009-01-01 08:34:10 - cd /src TB --- 2009-01-01 08:34:10 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jan 1 08:34:10 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -ffreestanding -fstack-protector -Werror vers.c linking kernel kern_exec.o(.sbss+0x0): multiple definition of `elf32_fallback_brand' imgact_elf.o(.sdata+0x0): first defined here kern_mib.o(.sbss+0x40): multiple definition of `elf32_fallback_brand' imgact_elf.o(.sdata+0x0): first defined here elf_machdep.o(.sbss+0x0): multiple definition of `elf32_fallback_brand' imgact_elf.o(.sdata+0x0): first defined here *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-01-01 08:49:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-01-01 08:49:23 - ERROR: failed to build lint kernel TB --- 2009-01-01 08:49:23 - 4803.91 user 414.56 system 6348.89 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Thu Jan 1 09:47:32 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A99E0106564A; Thu, 1 Jan 2009 09:47:32 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 826A08FC2C; Thu, 1 Jan 2009 09:47:32 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n019lVKO093337; Thu, 1 Jan 2009 04:47:31 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n019lVjP028745; Thu, 1 Jan 2009 04:47:31 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 9651F7302F; Thu, 1 Jan 2009 04:47:31 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090101094731.9651F7302F@freebsd-current.sentex.ca> Date: Thu, 1 Jan 2009 04:47:31 -0500 (EST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on clamscanner1 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2009 09:47:33 -0000 TB --- 2009-01-01 08:11:30 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-01-01 08:11:30 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-01-01 08:11:30 - cleaning the object tree TB --- 2009-01-01 08:12:09 - cvsupping the source tree TB --- 2009-01-01 08:12:09 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-01-01 08:12:18 - building world TB --- 2009-01-01 08:12:18 - MAKEOBJDIRPREFIX=/obj TB --- 2009-01-01 08:12:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-01-01 08:12:18 - TARGET=sparc64 TB --- 2009-01-01 08:12:18 - TARGET_ARCH=sparc64 TB --- 2009-01-01 08:12:18 - TZ=UTC TB --- 2009-01-01 08:12:18 - __MAKE_CONF=/dev/null TB --- 2009-01-01 08:12:18 - cd /src TB --- 2009-01-01 08:12:18 - /usr/bin/make -B buildworld >>> World build started on Thu Jan 1 08:12:20 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Jan 1 09:31:19 UTC 2009 TB --- 2009-01-01 09:31:19 - generating LINT kernel config TB --- 2009-01-01 09:31:19 - cd /src/sys/sparc64/conf TB --- 2009-01-01 09:31:19 - /usr/bin/make -B LINT TB --- 2009-01-01 09:31:19 - building LINT kernel TB --- 2009-01-01 09:31:19 - MAKEOBJDIRPREFIX=/obj TB --- 2009-01-01 09:31:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-01-01 09:31:19 - TARGET=sparc64 TB --- 2009-01-01 09:31:19 - TARGET_ARCH=sparc64 TB --- 2009-01-01 09:31:19 - TZ=UTC TB --- 2009-01-01 09:31:19 - __MAKE_CONF=/dev/null TB --- 2009-01-01 09:31:19 - cd /src TB --- 2009-01-01 09:31:19 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jan 1 09:31:19 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror vers.c linking kernel kern_exec.o(.bss+0x8): multiple definition of `elf64_fallback_brand' imgact_elf.o(.data+0x0): first defined here kern_mib.o(.bss+0x2c8): multiple definition of `elf64_fallback_brand' imgact_elf.o(.data+0x0): first defined here elf_machdep.o(.bss+0x0): multiple definition of `elf64_fallback_brand' imgact_elf.o(.data+0x0): first defined here *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-01-01 09:47:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-01-01 09:47:31 - ERROR: failed to build lint kernel TB --- 2009-01-01 09:47:31 - 4600.91 user 415.00 system 5760.73 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Thu Jan 1 09:51:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 634A7106566B; Thu, 1 Jan 2009 09:51:54 +0000 (UTC) (envelope-from simon@nitro.dk) Received: from mx.nitro.dk (zarniwoop.nitro.dk [83.92.207.38]) by mx1.freebsd.org (Postfix) with ESMTP id EB2358FC08; Thu, 1 Jan 2009 09:51:53 +0000 (UTC) (envelope-from simon@nitro.dk) Received: from arthur.nitro.dk (arthur.bofh [192.168.2.3]) by mx.nitro.dk (Postfix) with ESMTP id 13C631E8C01; Thu, 1 Jan 2009 09:51:53 +0000 (UTC) Received: by arthur.nitro.dk (Postfix, from userid 1000) id F31FC5C86; Thu, 1 Jan 2009 10:51:52 +0100 (CET) Date: Thu, 1 Jan 2009 10:51:52 +0100 From: "Simon L. Nielsen" To: Tim Kientzle Message-ID: <20090101095151.GA1117@arthur.nitro.dk> References: <200812301616.11132.max@love2party.net> <200812302213.07155.max@love2party.net> <20081231094159.GA964@zaphod.nitro.dk> <200812311109.57955.max@love2party.net> <20081231105952.GB964@zaphod.nitro.dk> <495C017F.9000408@freebsd.org> <495C2AF5.6030703@kientzle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <495C2AF5.6030703@kientzle.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Max Laier , Tim Kientzle , cperciva@freebsd.org, freebsd-current@freebsd.org Subject: Re: tar/libarchive gzip problem [was: portsnap corrupted] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2009 09:51:54 -0000 On 2008.12.31 18:31:17 -0800, Tim Kientzle wrote: > I just committed a fix for this (r186670). Please let > me know if you see any other problems. This seems to fix it, thanks! Max, could you see if you have portsnap problems with the latest libarchive? > Tim Kientzle wrote: > > I think I know what this is. I tried recently to add > > support for concatenated gzip files. This involves looking > > ahead for another GZip header after the end of the compressed > > data. The current version screws this up and ends up trying > > to match the file CRC as a Gzip header. About 1 in 256 files > > will match the first byte, which triggers the subsequent meltdown. > > This also explains why neither of us saw it in testing. > > (I knew the code didn't actually work for concatenated gzip > > files but didn't realize it would break decode of some > > regular non-concatenated files.) > > > > The attached patch simply disables this additional > > header check, which should fix the immediate problem. > > Please try it and let me know. > > > > Apologies, > > > > Tim > > > > Simon L. Nielsen wrote: > > > >> Hey Tim, > >> > >> I think one of the recent changes to tar or libarchive broke gzip > >> handling in some cases. See more below. > >> > >> [portsnap extract fails with gzip error] > >> > >> I'm not sure why I didn't run into it in my tests, but I think the > >> problem is in tar / libarchive's handling of gzip files. Taking one > >> random "broken" file [1] it fails with tar's build in decompression, > >> but works using external zcat. > >> > >> [1] > >> http://portsnap1.freebsd.org/f/19faa3b8bd15bb8f4cd9f665a7623887729f3bd834d780e8b069df979f228e8d.gz > >> > >> http://people.freebsd.org/~simon/tmp/19faa3b8bd15bb8f4cd9f665a7623887729f3bd834d780e8b069df979f228e8d.gz > >> > >> > >> > >> Broken system: > >> > >> [simon@eddie:/tmp] tar --version > >> bsdtar 2.5.903a - libarchive 2.5.903a > >> [simon@eddie:/tmp] uname -a > >> FreeBSD eddie.nitro.dk 8.0-CURRENT FreeBSD 8.0-CURRENT #1: Tue Dec 30 > >> 22:28:33 CET 2008 > >> simon@eddie.nitro.dk:/FreeBSD/obj/FreeBSD/system-CURRENT/sys/EDDIE i386 > >> [simon@eddie:/tmp] tar tvf > >> 19faa3b8bd15bb8f4cd9f665a7623887729f3bd834d780e8b069df979f228e8d.gz > > >> /dev/null > >> tar: Error opening archive: Invalid GZip header (saw 99 at offset 1) > >> [simon@eddie:/tmp] zcat > >> 19faa3b8bd15bb8f4cd9f665a7623887729f3bd834d780e8b069df979f228e8d.gz | > >> tar tf - > /dev/null [simon@eddie:/tmp] zcat > >> 19faa3b8bd15bb8f4cd9f665a7623887729f3bd834d780e8b069df979f228e8d.gz | > >> sha256 19faa3b8bd15bb8f4cd9f665a7623887729f3bd834d780e8b069df979f228e8d > >> > >> > >> OK system: > >> > >> [simon@benji:/tmp] tar --version > >> bsdtar 2.5.5 - libarchive 2.5.5 > >> [simon@benji:/tmp] uname -a > >> FreeBSD benji.s 7.1-RC2 FreeBSD 7.1-RC2 #0: Tue Dec 23 15:18:30 UTC > >> 2008 root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 > >> [simon@benji:/tmp] tar tvf > >> 19faa3b8bd15bb8f4cd9f665a7623887729f3bd834d780e8b069df979f228e8d.gz > > >> /dev/null [simon@benji:/tmp] zcat > >> 19faa3b8bd15bb8f4cd9f665a7623887729f3bd834d780e8b069df979f228e8d.gz | > >> sha256 19faa3b8bd15bb8f4cd9f665a7623887729f3bd834d780e8b069df979f228e8d > >> > >> > >> Another OK system: > >> > >> [simon@ref8-amd64:files] tar --version > >> bsdtar 2.5.5 - libarchive 2.5.5 > >> [simon@ref8-amd64:files] uname -a > >> FreeBSD ref8-amd64.freebsd.org 8.0-CURRENT FreeBSD 8.0-CURRENT #2 > >> r184542:185402: Fri Nov 28 19:14:40 UTC 2008 > >> peter@ref8-amd64.freebsd.org:/scratch/src/sys/amd64/compile/REF8-AMD64 > >> amd64 > >> [simon@ref8-amd64:files] tar tvf > >> 19faa3b8bd15bb8f4cd9f665a7623887729f3bd834d780e8b069df979f228e8d.gz > > >> /dev/null > >> [simon@ref8-amd64:files] zcat > >> 19faa3b8bd15bb8f4cd9f665a7623887729f3bd834d780e8b069df979f228e8d.gz | > >> sha256 > >> 19faa3b8bd15bb8f4cd9f665a7623887729f3bd834d780e8b069df979f228e8d > >> > > > > ------------------------------------------------------------------------ > > > > Index: archive_read_support_compression_gzip.c > > =================================================================== > > --- archive_read_support_compression_gzip.c (revision 185679) > > +++ archive_read_support_compression_gzip.c (working copy) > > @@ -428,8 +428,7 @@ > > "Failed to clean up gzip decompressor"); > > return (ARCHIVE_FATAL); > > } > > - /* Restart header parser with the next block. */ > > - state->header_state = state->header_done = 0; > > + state->eof = 1; > > /* FALL THROUGH */ > > case Z_OK: /* Decompressor made some progress. */ > > /* If we filled our buffer, update stats and return. */ > -- Simon L. Nielsen From owner-freebsd-current@FreeBSD.ORG Thu Jan 1 10:20:15 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C069D1065672; Thu, 1 Jan 2009 10:20:15 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 99AC68FC18; Thu, 1 Jan 2009 10:20:15 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n01AKDbj054233; Thu, 1 Jan 2009 05:20:13 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n01AKDsg051665; Thu, 1 Jan 2009 05:20:13 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 5F52B7302F; Thu, 1 Jan 2009 05:20:13 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090101102013.5F52B7302F@freebsd-current.sentex.ca> Date: Thu, 1 Jan 2009 05:20:13 -0500 (EST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2009 10:20:16 -0000 TB --- 2009-01-01 08:49:24 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-01-01 08:49:24 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-01-01 08:49:24 - cleaning the object tree TB --- 2009-01-01 08:49:46 - cvsupping the source tree TB --- 2009-01-01 08:49:46 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-01-01 08:49:54 - building world TB --- 2009-01-01 08:49:54 - MAKEOBJDIRPREFIX=/obj TB --- 2009-01-01 08:49:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-01-01 08:49:54 - TARGET=sun4v TB --- 2009-01-01 08:49:54 - TARGET_ARCH=sparc64 TB --- 2009-01-01 08:49:54 - TZ=UTC TB --- 2009-01-01 08:49:54 - __MAKE_CONF=/dev/null TB --- 2009-01-01 08:49:54 - cd /src TB --- 2009-01-01 08:49:54 - /usr/bin/make -B buildworld >>> World build started on Thu Jan 1 08:49:56 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Jan 1 10:05:57 UTC 2009 TB --- 2009-01-01 10:05:57 - generating LINT kernel config TB --- 2009-01-01 10:05:57 - cd /src/sys/sun4v/conf TB --- 2009-01-01 10:05:57 - /usr/bin/make -B LINT TB --- 2009-01-01 10:05:57 - building LINT kernel TB --- 2009-01-01 10:05:57 - MAKEOBJDIRPREFIX=/obj TB --- 2009-01-01 10:05:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-01-01 10:05:57 - TARGET=sun4v TB --- 2009-01-01 10:05:57 - TARGET_ARCH=sparc64 TB --- 2009-01-01 10:05:57 - TZ=UTC TB --- 2009-01-01 10:05:57 - __MAKE_CONF=/dev/null TB --- 2009-01-01 10:05:57 - cd /src TB --- 2009-01-01 10:05:57 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jan 1 10:05:57 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror vers.c linking kernel kern_exec.o(.bss+0x8): multiple definition of `elf64_fallback_brand' imgact_elf.o(.data+0x0): first defined here kern_mib.o(.bss+0x2c8): multiple definition of `elf64_fallback_brand' imgact_elf.o(.data+0x0): first defined here elf_machdep.o(.bss+0x0): multiple definition of `elf64_fallback_brand' imgact_elf.o(.data+0x0): first defined here *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-01-01 10:20:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-01-01 10:20:13 - ERROR: failed to build lint kernel TB --- 2009-01-01 10:20:13 - 4578.48 user 408.34 system 5448.98 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Thu Jan 1 11:30:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A6F7106564A for ; Thu, 1 Jan 2009 11:30:55 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe16.tele2.se [212.247.155.225]) by mx1.freebsd.org (Postfix) with ESMTP id 511AA8FC08 for ; Thu, 1 Jan 2009 11:30:54 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=rREUrScshOl7G2h6aTFPgw==:17 a=6I5d2MoRAAAA:8 a=v-r4UyAuqrTsnFikN8cA:9 a=ykzim29v7tSbNs3X5Y0A:7 a=YVzcF-Hl6FS1l1h6BLItgIlhvfcA:4 a=MSl-tDqOz04A:10 a=SV7veod9ZcQA:10 a=LY0hPdMaydYA:10 Received: from [62.73.248.227] (account mc467741@c2i.net [62.73.248.227] verified) by mailfe16.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 431004574; Thu, 01 Jan 2009 12:30:52 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Thu, 1 Jan 2009 12:33:14 +0100 User-Agent: KMail/1.9.7 References: <47297827@bb.ipt.ru> <20081231003115.GA22037@cdnetworks.co.kr> <20090101022845.4dc8bc27.nork@FreeBSD.org> In-Reply-To: <20090101022845.4dc8bc27.nork@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901011233.15537.hselasky@c2i.net> Cc: pyunyh@gmail.com, Boris Samorodov , Norikatsu Shigemura Subject: Re: Call for axe(4) testers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2009 11:30:55 -0000 On Wednesday 31 December 2008, Norikatsu Shigemura wrote: > On Wed, 31 Dec 2008 09:31:15 +0900 > > Pyun YongHyeon wrote: > > the updated axe(4) in near future. Alternatively you can try > > attached patch for USB2. > > I tried to buildkernel, and I got following messages: > Sorry, I couldn't fix AXE_FLAG_LINK issue. This is fixed in P4 and my private SVN. This patch is not yet in -current. You need to rename the first flag in one of the axe header files in /sys/dev/usb2/ethernet . --HPS > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - ===> usb2/ethernet_axe (all) > cc -O2 -pipe -march=pentium-m -fno-strict-aliasing -Werror -D_KERNEL > -DKLD_MODULE -std=c99 -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include > /usr/obj/usr/src/sys/MELFINA/opt_global.h -I. -I@ -I@/contrib/altq > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -fno-common -g3 -I/usr/obj/usr/src/sys/MELFINA > -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow > -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector > -fstack-protector -Wall -Wredundant-decls -Wnested-externs > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline > -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c > /usr/src/sys/modules/usb2/ethernet_axe/../../../dev/usb2/ethernet/if_axe2.c > /usr/src/sys/modules/usb2/ethernet_axe/../../../dev/usb2/ethernet/if_axe2.c >: In function 'axe_cfg_miibus_statchg': > /usr/src/sys/modules/usb2/ethernet_axe/../../../dev/usb2/ethernet/if_axe2.c >:418: error: 'AXE_FLAG_LINK' undeclared (first use in this function) > /usr/src/sys/modules/usb2/ethernet_axe/../../../dev/usb2/ethernet/if_axe2.c >:418: error: (Each undeclared identifier is reported only once > /usr/src/sys/modules/usb2/ethernet_axe/../../../dev/usb2/ethernet/if_axe2.c >:418: error: for each function it appears in.) > /usr/src/sys/modules/usb2/ethernet_axe/../../../dev/usb2/ethernet/if_axe2.c >: In function 'axe_bulk_write_callback': > /usr/src/sys/modules/usb2/ethernet_axe/../../../dev/usb2/ethernet/if_axe2.c >:1165: error: 'AXE_FLAG_LINK' undeclared (first use in this function) > /usr/src/sys/modules/usb2/ethernet_axe/../../../dev/usb2/ethernet/if_axe2.c >: In function 'axe_cfg_tick': > /usr/src/sys/modules/usb2/ethernet_axe/../../../dev/usb2/ethernet/if_axe2.c >:1263: error: 'AXE_FLAG_LINK' undeclared (first use in this function) > /usr/src/sys/modules/usb2/ethernet_axe/../../../dev/usb2/ethernet/if_axe2.c >: In function 'axe_cfg_pre_stop': > /usr/src/sys/modules/usb2/ethernet_axe/../../../dev/usb2/ethernet/if_axe2.c >:1499: error: 'AXE_FLAG_LINK' undeclared (first use in this function) *** > Error code 1 > 1 error > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Jan 1 12:54:35 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C40D106566B; Thu, 1 Jan 2009 12:54:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id C39228FC1E; Thu, 1 Jan 2009 12:54:34 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n01CsXnQ061809; Thu, 1 Jan 2009 07:54:33 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n01CsWB4013416; Thu, 1 Jan 2009 07:54:32 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 7E8DB7302F; Thu, 1 Jan 2009 07:54:32 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090101125432.7E8DB7302F@freebsd-current.sentex.ca> Date: Thu, 1 Jan 2009 07:54:32 -0500 (EST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2009 12:54:35 -0000 TB --- 2009-01-01 10:40:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-01-01 10:40:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2009-01-01 10:40:01 - cleaning the object tree TB --- 2009-01-01 10:40:41 - cvsupping the source tree TB --- 2009-01-01 10:40:41 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2009-01-01 10:40:48 - building world TB --- 2009-01-01 10:40:48 - MAKEOBJDIRPREFIX=/obj TB --- 2009-01-01 10:40:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-01-01 10:40:48 - TARGET=amd64 TB --- 2009-01-01 10:40:48 - TARGET_ARCH=amd64 TB --- 2009-01-01 10:40:48 - TZ=UTC TB --- 2009-01-01 10:40:48 - __MAKE_CONF=/dev/null TB --- 2009-01-01 10:40:48 - cd /src TB --- 2009-01-01 10:40:48 - /usr/bin/make -B buildworld >>> World build started on Thu Jan 1 10:40:51 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Thu Jan 1 12:36:26 UTC 2009 TB --- 2009-01-01 12:36:26 - generating LINT kernel config TB --- 2009-01-01 12:36:26 - cd /src/sys/amd64/conf TB --- 2009-01-01 12:36:26 - /usr/bin/make -B LINT TB --- 2009-01-01 12:36:26 - building LINT kernel TB --- 2009-01-01 12:36:26 - MAKEOBJDIRPREFIX=/obj TB --- 2009-01-01 12:36:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-01-01 12:36:26 - TARGET=amd64 TB --- 2009-01-01 12:36:26 - TARGET_ARCH=amd64 TB --- 2009-01-01 12:36:26 - TZ=UTC TB --- 2009-01-01 12:36:26 - __MAKE_CONF=/dev/null TB --- 2009-01-01 12:36:26 - cd /src TB --- 2009-01-01 12:36:26 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jan 1 12:36:26 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] kern_mib.o(.bss+0x2b8): multiple definition of `elf64_fallback_brand' imgact_elf.o(.data+0x0): first defined here elf_machdep.o(.bss+0x0): multiple definition of `elf64_fallback_brand' imgact_elf.o(.data+0x0): first defined here imgact_elf32.o(.data+0x0): multiple definition of `elf32_fallback_brand' ia32_sysvec.o(.bss+0x0): first defined here linux32_sysvec.o(.bss+0x0): multiple definition of `elf32_fallback_brand' ia32_sysvec.o(.bss+0x0): first defined here *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-01-01 12:54:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-01-01 12:54:32 - ERROR: failed to build lint kernel TB --- 2009-01-01 12:54:32 - 6442.43 user 635.49 system 8071.36 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Thu Jan 1 13:25:22 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5C1B106564A; Thu, 1 Jan 2009 13:25:22 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 792B58FC08; Thu, 1 Jan 2009 13:25:22 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n01DPKId063661; Thu, 1 Jan 2009 08:25:20 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n01DPKvc026211; Thu, 1 Jan 2009 08:25:20 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 836197302F; Thu, 1 Jan 2009 08:25:20 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090101132520.836197302F@freebsd-current.sentex.ca> Date: Thu, 1 Jan 2009 08:25:20 -0500 (EST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on clamscanner1 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2009 13:25:23 -0000 TB --- 2009-01-01 11:45:35 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-01-01 11:45:35 - starting HEAD tinderbox run for i386/i386 TB --- 2009-01-01 11:45:35 - cleaning the object tree TB --- 2009-01-01 11:45:55 - cvsupping the source tree TB --- 2009-01-01 11:45:55 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2009-01-01 11:46:03 - building world TB --- 2009-01-01 11:46:03 - MAKEOBJDIRPREFIX=/obj TB --- 2009-01-01 11:46:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-01-01 11:46:03 - TARGET=i386 TB --- 2009-01-01 11:46:03 - TARGET_ARCH=i386 TB --- 2009-01-01 11:46:03 - TZ=UTC TB --- 2009-01-01 11:46:03 - __MAKE_CONF=/dev/null TB --- 2009-01-01 11:46:03 - cd /src TB --- 2009-01-01 11:46:03 - /usr/bin/make -B buildworld >>> World build started on Thu Jan 1 11:46:06 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Jan 1 13:06:17 UTC 2009 TB --- 2009-01-01 13:06:17 - generating LINT kernel config TB --- 2009-01-01 13:06:17 - cd /src/sys/i386/conf TB --- 2009-01-01 13:06:17 - /usr/bin/make -B LINT TB --- 2009-01-01 13:06:17 - building LINT kernel TB --- 2009-01-01 13:06:17 - MAKEOBJDIRPREFIX=/obj TB --- 2009-01-01 13:06:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-01-01 13:06:17 - TARGET=i386 TB --- 2009-01-01 13:06:17 - TARGET_ARCH=i386 TB --- 2009-01-01 13:06:17 - TZ=UTC TB --- 2009-01-01 13:06:17 - __MAKE_CONF=/dev/null TB --- 2009-01-01 13:06:17 - cd /src TB --- 2009-01-01 13:06:17 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Jan 1 13:06:18 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] kern_mib.o(.bss+0x25c): multiple definition of `elf32_fallback_brand' imgact_elf.o(.data+0x0): first defined here svr4_sysvec.o(.bss+0x0): multiple definition of `elf32_fallback_brand' imgact_elf.o(.data+0x0): first defined here elf_machdep.o(.bss+0x0): multiple definition of `elf32_fallback_brand' imgact_elf.o(.data+0x0): first defined here linux_sysvec.o(.bss+0x0): multiple definition of `elf32_fallback_brand' imgact_elf.o(.data+0x0): first defined here *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-01-01 13:25:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-01-01 13:25:20 - ERROR: failed to build lint kernel TB --- 2009-01-01 13:25:20 - 4843.88 user 437.34 system 5984.80 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Thu Jan 1 13:33:41 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC4B11065670 for ; Thu, 1 Jan 2009 13:33:41 +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 70E498FC12 for ; Thu, 1 Jan 2009 13:33:41 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 1CBC71CCA7; Thu, 1 Jan 2009 14:33:40 +0100 (CET) Date: Thu, 1 Jan 2009 14:33:40 +0100 From: Ed Schouten To: current@FreeBSD.org Message-ID: <20090101133340.GE1176@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UpdKy7mRHviOTiWe" Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Subject: VT100/xterm-support for syscons(4) committed to SVN X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2009 13:33:42 -0000 --UpdKy7mRHviOTiWe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello all, I've just committed libteken (the VT100/xterm-compatible terminal emulator I've been working on) to the FreeBSD SVN source tree. See the commit message below. Even though I had some people test the code, there's always a chance I did something wrong. Let me know if you discover any rendering issues. Happy 2009! --=20 Ed Schouten WWW: http://80386.nl/ ----- Forwarded message from Ed Schouten ----- > Date: Thu, 1 Jan 2009 13:26:53 +0000 (UTC) > From: Ed Schouten > To: src-committers@freebsd.org, svn-src-all@freebsd.org, > svn-src-head@freebsd.org > Subject: svn commit: r186681 - in head/sys: conf dev/syscons > dev/syscons/teken pc98/cbus >=20 > Author: ed > Date: Thu Jan 1 13:26:53 2009 > New Revision: 186681 > URL: http://svn.freebsd.org/changeset/base/186681 >=20 > Log: > Replace syscons terminal renderer by a new renderer that uses libteken. > =20 > Some time ago I started working on a library called libteken, which is > terminal emulator. It does not buffer any screen contents, but only > keeps terminal state, such as cursor position, attributes, etc. It > should implement all escape sequences that are implemented by the > cons25 terminal emulator, but also a fair amount of sequences that are > present in VT100 and xterm. > =20 > A lot of random notes, which could be of interest to users/developers: > =20 > - Even though I'm leaving the terminal type set to `cons25', users can > do experiments with placing `xterm-color' in /etc/ttys. Because we > only implement a subset of features of xterm, this may cause > artifacts. We should consider extending libteken, because in my > opinion xterm is the way to go. Some missing features: > =20 > - Keypad application mode (DECKPAM) > - Character sets (SCS) > =20 > - libteken is filled with a fair amount of assertions, but unfortunately > we cannot go into the debugger anymore if we fail them. I've done > development of this library almost entirely in userspace. In > sys/dev/syscons/teken there are two applications that can be helpful > when debugging the code: > =20 > - teken_demo: a terminal emulator that can be started from a regular > xterm that emulates a terminal using libteken. This application can > be very useful to debug any rendering issues. > =20 > - teken_stress: a stress testing application that emulates random > terminal output. libteken has literally survived multiple terabytes > of random input. > =20 > - libteken also includes support for UTF-8, but unfortunately our input > layer and font renderer don't support this. If users want to > experiment with UTF-8 support, they can enable `TEKEN_UTF8' in > teken.h. If you recompile your kernel or the teken_demo application, > you can hold some nice experiments. > =20 > - I've left PC98 the way it is right now. The PC98 platform has a custom > syscons renderer, which supports some form of localised input. Maybe > we should port PC98 to libteken by the time syscons supports UTF-8? > =20 > - I've removed the `dumb' terminal emulator. It has been broken for > years. It hasn't survived the `struct proc' -> `struct thread' > conversion. > =20 > - To prevent confusion among people that want to hack on libteken: > unlike syscons, the state machines that parse the escape sequences are > machine generated. This means that if you want to add new escape > sequences, you have to add an entry to the `sequences' file. This will > cause new entries to be added to `teken_state.h'. > =20 > - Any rendering artifacts that didn't occur prior to this commit are by > accident. They should be reported to me, so I can fix them. > =20 > Discussed on: current@, hackers@ > Discussed with: philip (at 25C3) > ----- End forwarded message ----- --UpdKy7mRHviOTiWe Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAklcxjMACgkQ52SDGA2eCwWzkACeI+Log91UxWSYNGeHHmQcyYMs csYAni4b6McmK6c0wyDca/sBCNuwlQOE =gtvV -----END PGP SIGNATURE----- --UpdKy7mRHviOTiWe-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 1 15:13:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 139F0106566B for ; Thu, 1 Jan 2009 15:13:18 +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 4F16A8FC14 for ; Thu, 1 Jan 2009 15:13:16 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-030-026.pools.arcor-ip.net [88.66.30.26]) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis) id 0ML25U-1LIPEY2fBC-0000FS; Thu, 01 Jan 2009 16:13:14 +0100 Received: (qmail 19605 invoked from network); 1 Jan 2009 15:13:14 -0000 Received: from fbsd8.laiers.local (192.168.4.151) by mx.laiers.local with SMTP; 1 Jan 2009 15:13:14 -0000 From: Max Laier Organization: FreeBSD To: "Simon L. Nielsen" Date: Thu, 1 Jan 2009 16:13:13 +0100 User-Agent: KMail/1.10.1 (FreeBSD/8.0-CURRENT; KDE/4.1.1; i386; ; ) References: <200812301616.11132.max@love2party.net> <495C2AF5.6030703@kientzle.com> <20090101095151.GA1117@arthur.nitro.dk> In-Reply-To: <20090101095151.GA1117@arthur.nitro.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901011613.14175.max@love2party.net> X-Provags-ID: V01U2FsdGVkX18wmSCcrOu2N/44sQCexMmhWwiUaGJbXa08nJs 5EV8RR839mksjmFIS2zoVch63VJheJUgbL2dJTJA5kDoSLumM6 e0mNI5UNZjxrBsddI4Yjw== Cc: Tim Kientzle , cperciva@freebsd.org, freebsd-current@freebsd.org Subject: Re: tar/libarchive gzip problem [was: portsnap corrupted] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2009 15:13:19 -0000 On Thursday 01 January 2009 10:51:52 Simon L. Nielsen wrote: > On 2008.12.31 18:31:17 -0800, Tim Kientzle wrote: > > I just committed a fix for this (r186670). Please let > > me know if you see any other problems. > > This seems to fix it, thanks! > > Max, could you see if you have portsnap problems with the latest > libarchive? Non at all! Thank you for the quick fix! Happy New Year! -- /"\ 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-current@FreeBSD.ORG Thu Jan 1 17:30:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C56F0106564A for ; Thu, 1 Jan 2009 17:30:14 +0000 (UTC) (envelope-from pj@smo.de) Received: from ilk.de (mx-out18.ilk.de [194.121.104.18]) by mx1.freebsd.org (Postfix) with ESMTP id 549A88FC0C for ; Thu, 1 Jan 2009 17:30:13 +0000 (UTC) (envelope-from pj@smo.de) Received: from bologna.intern.smo.de (pool25.ka.ilk.net [212.86.194.25]) by ilk.de (8.13.4/8.13.4/ilk-relay) with ESMTP id n01DxSdQ014489 for ; Thu, 1 Jan 2009 14:59:28 +0100 Received: from [192.168.153.210] (pj@krafla.intern.smo.de [192.168.153.210]) by bologna.intern.smo.de (8.13.8+Sun/8.13.8) with ESMTP id n01DpJpC002372 for ; Thu, 1 Jan 2009 14:51:20 +0100 (CET) Message-ID: <495CCB7D.80402@smo.de> Date: Thu, 01 Jan 2009 14:56:13 +0100 From: Philipp Ost User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.7.13) Gecko/20060601 X-Accept-Language: de, en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: LORs in recent -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2009 17:30:15 -0000 Hi list, I'm running -CURRENT as of December 27th and get these two LORs. No. 1 (happens when booting, doesn't matter if single user or anything else): lock order reversal: 1st 0xc1c6a044 user map (user map) @ /usr/src/sys/vm/vm_map.c:3115 2nd 0xc1d9d7ac ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2079 KDB: stack backtrace: db_trace_self_wrapper(c0839d29,c1aff90c,c05e1e05,4,c0835575,...) at db_trace_self_wrapper+0x26 kdb_backtrace(4,c0835575,c1c29728,c1c2ddd8,c1aff968,...) at kdb_backtrace+0x29 _witness_debugger(c083c844,c1d9d7ac,c083057e,c1c2ddd8,c08435fa,...) at _witness_debugger+0x25 witness_checkorder(c1d9d7ac,1,c08435fa,81f,0,...) at witness_checkorder+0x839 __lockmgr_args(c1d9d7ac,200501,c1d9d7c8,0,0,...) at __lockmgr_args+0x237 ffs_lock(c1affa78,c05e1bab,c0859b8c,200501,c1d9d754,...) at ffs_lock+0x8a VOP_LOCK1_APV(c08a9f80,c1affa78,c1c66e24,c08b99e0,c1d9d754,...) at VOP_LOCK1_APV+0xa5 _vn_lock(c1d9d754,200501,c08435fa,81f,4,...) at _vn_lock+0x5e vget(c1d9d754,200501,c1c66d80,4b4,0,...) at vget+0xc9 vnode_pager_lock(c10448b8,0,c0857168,127,c1affc18,...) at vnode_pager_lock+0x1e0 vm_fault(c1c6a000,80db000,2,8,80db780,...) at vm_fault+0x1df trap_pfault(5,0,c086255f,2e7,c,...) at trap_pfault+0xf9 trap(c1affd38) at trap+0x26f calltrap() at calltrap+0x6 --- trap 0xc, eip = 0x80480e5, esp = 0xbfbfeef0, ebp = 0xbfbfef10 --- Enter full pathname of shell or RETURN for /bin/sh: This one was already reported back in November: No.2 happens when shutting down the system or rebooting: # reboot Jan 1 15:28:41 askja reboot: rebooted by root Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...1 1 1 0 0 done All buffers synced. lock order reversal: 1st 0xc1e60164 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1190 2nd 0xc1e97270 devfs (devfs) @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1174 KDB: stack backtrace: db_trace_self_wrapper(c0839d29,cac339a8,c05e1e05,4,c0835575,...) at db_trace_self_wrapper+0x26 kdb_backtrace(4,c0835575,c1c2ddd8,c1c2dd08,cac33a04,...) at kdb_backtrace+0x29 _witness_debugger(c083c844,c1e97270,c082cb0b,c1c2dd08,c08550ff,...) at _witness_debugger+0x25 witness_checkorder(c1e97270,9,c08550ff,496,c1e9728c,...) at witness_checkorder+0x839 __lockmgr_args(c1e97270,80400,c1e9728c,0,0,...) at __lockmgr_args+0x797 vop_stdlock(cac33b0c,542,cac33b04,80400,c1e97218,...) at vop_stdlock+0x62 VOP_LOCK1_APV(c0884680,cac33b0c,c20af860,c08b99e0,c1e97218,...) at VOP_LOCK1_APV+0xa5 _vn_lock(c1e97218,80400,c08550ff,496,c1e87200,...) at _vn_lock+0x5e ffs_flushfiles(c1e4a500,2,c20bad80,542,3,...) at ffs_flushfiles+0xa7 softdep_flushfiles(c1e4a500,2,c20bad80,8a0,c05749d4,...) at softdep_flushfiles+0x2e ffs_unmount(c1e4a500,80000,c20bad80,c20bad80,0,...) at ffs_unmount+0x14c dounmount(c1e4a500,80000,c20bad80,c1993a30,0,...) at dounmount+0x482 vfs_unmountall(c0836af6,0,c0836ba0,12a,0,...) at vfs_unmountall+0x4e boot(c08d3810,0,c0836ba0,ad,cac33d2c,...) at boot+0x3cf reboot(c20bad80,cac33cf8,4,c083ddff,c0887fa8,...) at reboot+0x4b syscall(cac33d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (55, FreeBSD ELF32, reboot), eip = 0x280be80b, esp = 0xbfbfecfc, ebp = 0xbfbfed38 --- I didn't find a report for this one. $ uname -a FreeBSD askja.x.y.z.de 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sat Dec 27 23:43:34 CET 2008 pj@askja.x.y.z.de:/usr/obj/usr/src/sys/ASKJAKERNEL i386 Regards, Philipp From owner-freebsd-current@FreeBSD.ORG Thu Jan 1 18:25:38 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 897A1106564A for ; Thu, 1 Jan 2009 18:25:38 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id D2CFC8FC14 for ; Thu, 1 Jan 2009 18:25:37 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 1D5EF73098; Thu, 1 Jan 2009 19:30:26 +0100 (CET) Date: Thu, 1 Jan 2009 19:30:26 +0100 From: Luigi Rizzo To: current@freebsd.org Message-ID: <20090101183026.GA15385@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: RFC: new utility, kmodpatch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2009 18:25:38 -0000 I mentioned this utility a couple of months ago, and it's now working so i would like to receive feedback on whether this is good to have as part of the system, or just keep it as a port (which is what i plan to do by default). In a nutshell, the kmodpatch utility can print or alter the content of device/quirk tables in kernel modules (I think Linux has some similar tool, though i don't remember the name -- or perhaps it is a feature of insmod ?). Full manpage is attached at the end, full sources are at http://info.iet.unipi.it/~luigi/FreeBSD/20090101-kmodpatch.tgz What is missing is some extra code to let it patch an on-disk file (elfdump returns the info we need, so in the worst case we just need to write a wrapper around elfdump). Feedback welcome. cheers luigi ------- manpage content -------- KMODPATCH(8) FreeBSD System Manager's Manual KMODPATCH(8) NAME kmodpatch -- print/modify device/quirk tables in kernel modules SYNOPSIS kmodpatch [-v] [-t file | format] module_name table_name [@offset [args ...]] DESCRIPTION The kmodpatch utility can print or alter the content of device/quirk tables in kernel modules. These tables are generally used to identify devices, and possibly apply specific quirks to enable/disable certain features. kmodpatch is especially useful to let the kernel recognise a new device without rebooting and rebuilding/reinstalling kernel or mod- ules. In read mode (when no args are specified), kmodpatch only list one or more entries in the matching module and table. In write mode, kmodpatch overwrites a user's specified entry in a table with the values passed on the command line. kmodpatch does some amount of checking to make sure that the arguments (module and table name, off- set, parameters formats) are compatible with the currently loaded mod- ules. A couple of real life examples: kmodpatch umass.ko - @0 0x4050 0x4a5 0x0101 0x4200 set the kernel to use flags UMASS_PROTO_SCSI | UMASS_PROTO_BBB and quirks WRONG_CSWSIG | NO_SYNCHRONIZE_CACHE for a certain GSM phone that implements the umass interface; kmodpatch uscanner.ko - @0 0x04b8 0x084a 0 let uscanner.ko recognise a newly introduced MFP scanner device. kmodpatch relies on a list of which modules and tables (associated to kernel symbols) it can work on, and the format of the records in each ta- ble. By default kmodpatch uses an internal list, which can be overridden from the command line using the -t option followed by either a file name, or by immediate text describing the kernel table. The format of the file is described in Section MODULE DESCRIPTION The following options are available: -v Verbose mode, print some debugging info -t file | format Specify a file containing the name and format of descriptor tables, or a line with the actual format of the table. MODULE DESCRIPTION The file (or text) describing modules, tables and record structure has a simple text format with one line per table. The `#' character is a com- ment delimiter, and can appear anywhere in the text. Each valid line must contain the following fields: module_name symbol_name entry_format [entry_format ...] Each entry_format describes one field in the table, and it is made of a number and/or a character specifying the field size and format, followed by an optional ':' and a word describing the field itself. Supported formats are: 2 | 2l | 2b 16-bit unsigned in host, little-endian or big-endian format; 4 | 4l | 4b 32-bit unsigned in host, little-endian or big-endian format; 8 | 8l | 8b 64-bit unsigned in host, little-endian or big-endian format; p a pointer; s a null-terminated string; The optional description is used as a header when listing the content of a table. EXAMPLE MODULE DESCRIPTION The following is an example of a file containing module descriptions. umass.ko umass_devdescrs 4:vendor 4:product 4:rev 2:proto 2:quirks uscanner.ko uscanner_devs 2:vendor 2:device 4:flags # comment if_nfe.ko nfe_devs 2:vendor 2:device s:name if_re.ko re_devs 2:vendor 2:device 4:type s:name EXAMPLES In addition to the two examples given at the beginning, one can use kmodpatch to explore the content of kernel tables, as follows. To list entries in module if_re: kmodpatch if_re - To list entry 10 in module umass: kmodpatch umass - @10 To set the last entry in module uscanner.ko kmodpatch uscanner.ko - @-1 0x04b8 0x0839 0 WARNINGS kmodpatch requires root privileges even to just read the content of the kernel tables. In write mode, the use of kmodpatch is as dangerous as accessing /dev/kmem in write mode, even though kmodpatch does some amount of check- ing to make sure that the arguments passed are reasonable. To this pur- pose, it is fundamental that the table descriptions used by kmodpatch match the actual structure of the kernel tables. There is no automatic way to extract this info. BUGS Right now, kmodpatch only writes to in-memory modules (or kernel). As a consequence the approach is not suitable to devices that are persistently connected to the system and for which the system cannot do a "reprobe". SEE ALSO kldconfig(8), kldload(8), kldstat(8), kldunload(8) HISTORY The kmodpatch utility first appeared in FreeBSD 8.0 inspired by a similar feature present on Linux. AUTHORS The kmodpatch utility was designed and implemented by Luigi Rizzo . From owner-freebsd-current@FreeBSD.ORG Thu Jan 1 19:25:35 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EF8E106564A for ; Thu, 1 Jan 2009 19:25:35 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id 117ED8FC19 for ; Thu, 1 Jan 2009 19:25:34 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from [89.178.138.186] (port=55003 helo=HP.lissyara.su) by hosting.lissyara.su with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LITAh-000NH5-SN; Thu, 01 Jan 2009 22:25:31 +0300 Message-ID: <495D18AB.4080402@lissyara.su> Date: Thu, 01 Jan 2009 22:25:31 +0300 From: Alex Keda User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.8.1.18) Gecko/20081124 Thunderbird/2.0.0.18 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Luigi Rizzo References: <20090101183026.GA15385@onelab2.iet.unipi.it> In-Reply-To: <20090101183026.GA15385@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Cc: current@freebsd.org Subject: Re: RFC: new utility, kmodpatch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2009 19:25:35 -0000 Luigi Rizzo ?????: > A couple of real life examples: > > kmodpatch umass.ko - @0 0x4050 0x4a5 0x0101 0x4200 > set the kernel to use flags UMASS_PROTO_SCSI | UMASS_PROTO_BBB and > quirks WRONG_CSWSIG | NO_SYNCHRONIZE_CACHE for a certain GSM phone > that implements the umass interface; > > kmodpatch uscanner.ko - @0 0x04b8 0x084a 0 > let uscanner.ko recognise a newly introduced MFP scanner device. It's very good idea! Now I will be able to replace WiFi in my HP laptop with Broadcom --> Intel, previously overwritten it identifier from Broadcom =))) (In HP laptops work only devices whose ID's contains in BIOS.) From owner-freebsd-current@FreeBSD.ORG Thu Jan 1 19:49:48 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9AA2106564A for ; Thu, 1 Jan 2009 19:49:48 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by mx1.freebsd.org (Postfix) with ESMTP id 6E3048FC14 for ; Thu, 1 Jan 2009 19:49:48 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so1983138fgb.35 for ; Thu, 01 Jan 2009 11:49:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=AjnzUH6Pj37rnG0ypQE8luNrBCzXYxp/lBqys0HR1l0=; b=LtcrGoSoZZIQFtVpGlyDSqvxXbw3U21GAvZW1VM08r9NrwtnZmYgJl5Qn/se+/V7xf gnbNrdVBO7jD468ibnidKHinOBOMKCXDUVozO4yz09xLKFlc4m6pNrezLNkoYWAA4OMM fxP1vptJL4BZgo6/rEoukBbDBCaQILkEDTSMY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=QVjHfF19kwPJPBZCSu1pdmktflWvhrkfJQRVv0Oh3EUZavyuwB7Xnnsn4aohwb0cuh CWdBwAUR0P/Dr/BR0K96zmcs8OIQ/T/9DP7yB1SqVvSYyrwwoxn8SY42If8q8dRZoF/a hliW1gGJNNtDNY+Uq5HENzqWtrd5qeF8GD9Dc= Received: by 10.86.79.4 with SMTP id c4mr10021538fgb.7.1230837444581; Thu, 01 Jan 2009 11:17:24 -0800 (PST) Received: by 10.86.90.7 with HTTP; Thu, 1 Jan 2009 11:17:24 -0800 (PST) Message-ID: <6101e8c40901011117y3e82a226id6f9de940b0f7dcd@mail.gmail.com> Date: Thu, 1 Jan 2009 20:17:24 +0100 From: "Oliver Pinter" To: "Luigi Rizzo" In-Reply-To: <20090101183026.GA15385@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20090101183026.GA15385@onelab2.iet.unipi.it> Cc: current@freebsd.org Subject: Re: RFC: new utility, kmodpatch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2009 19:49:49 -0000 Hi! Do You think for this project: http://www.ksplice.com/ ? On 1/1/09, Luigi Rizzo wrote: > I mentioned this utility a couple of months ago, and it's now working > so i would like to receive feedback on whether this is good to have > as part of the system, or just keep it as a port (which is what > i plan to do by default). > > In a nutshell, the kmodpatch utility can print or alter the content > of device/quirk tables in kernel modules (I think Linux has some > similar tool, though i don't remember the name -- or perhaps it is > a feature of insmod ?). > > Full manpage is attached at the end, full sources are at > > http://info.iet.unipi.it/~luigi/FreeBSD/20090101-kmodpatch.tgz > > What is missing is some extra code to let it patch an on-disk file > (elfdump returns the info we need, so in the worst case we just > need to write a wrapper around elfdump). > > Feedback welcome. > > cheers > luigi > > ------- manpage content -------- > > KMODPATCH(8) FreeBSD System Manager's Manual > KMODPATCH(8) > > NAME > kmodpatch -- print/modify device/quirk tables in kernel modules > > SYNOPSIS > kmodpatch [-v] [-t file | format] module_name table_name [@offset [args > ...]] > > DESCRIPTION > The kmodpatch utility can print or alter the content of device/quirk > tables in kernel modules. These tables are generally used to identify > devices, and possibly apply specific quirks to enable/disable certain > features. kmodpatch is especially useful to let the kernel recognise a > new device without rebooting and rebuilding/reinstalling kernel or mod- > ules. > > In read mode (when no args are specified), kmodpatch only list one or > more entries in the matching module and table. > > In write mode, kmodpatch overwrites a user's specified entry in a table > with the values passed on the command line. kmodpatch does some amount > of checking to make sure that the arguments (module and table name, > off- > set, parameters formats) are compatible with the currently loaded mod- > ules. > > A couple of real life examples: > > kmodpatch umass.ko - @0 0x4050 0x4a5 0x0101 0x4200 > set the kernel to use flags UMASS_PROTO_SCSI | UMASS_PROTO_BBB and > quirks WRONG_CSWSIG | NO_SYNCHRONIZE_CACHE for a certain GSM phone > that implements the umass interface; > > kmodpatch uscanner.ko - @0 0x04b8 0x084a 0 > let uscanner.ko recognise a newly introduced MFP scanner device. > > kmodpatch relies on a list of which modules and tables (associated to > kernel symbols) it can work on, and the format of the records in each > ta- > ble. By default kmodpatch uses an internal list, which can be > overridden > from the command line using the -t option followed by either a file > name, > or by immediate text describing the kernel table. The format of the > file > is described in Section MODULE DESCRIPTION > > The following options are available: > > -v Verbose mode, print some debugging info > > -t file | format > Specify a file containing the name and format of descriptor > tables, or a line with the actual format of the table. > > MODULE DESCRIPTION > The file (or text) describing modules, tables and record structure has > a > simple text format with one line per table. The `#' character is a com- > ment delimiter, and can appear anywhere in the text. Each valid line > must contain the following fields: > > module_name symbol_name entry_format [entry_format ...] > > Each entry_format describes one field in the table, and it is made of a > number and/or a character specifying the field size and format, > followed > by an optional ':' and a word describing the field itself. > > Supported formats are: > > 2 | 2l | 2b > 16-bit unsigned in host, little-endian or big-endian format; > > 4 | 4l | 4b > 32-bit unsigned in host, little-endian or big-endian format; > > 8 | 8l | 8b > 64-bit unsigned in host, little-endian or big-endian format; > > p a pointer; > > s a null-terminated string; > > The optional description is used as a header when listing the content > of > a table. > > EXAMPLE MODULE DESCRIPTION > The following is an example of a file containing module descriptions. > > umass.ko umass_devdescrs 4:vendor 4:product 4:rev 2:proto > 2:quirks > uscanner.ko uscanner_devs 2:vendor 2:device 4:flags # comment > if_nfe.ko nfe_devs 2:vendor 2:device s:name > if_re.ko re_devs 2:vendor 2:device 4:type s:name > > EXAMPLES > In addition to the two examples given at the beginning, one can use > kmodpatch to explore the content of kernel tables, as follows. > > To list entries in module if_re: > > kmodpatch if_re - > > To list entry 10 in module umass: > > kmodpatch umass - @10 > > To set the last entry in module uscanner.ko > > kmodpatch uscanner.ko - @-1 0x04b8 0x0839 0 > > WARNINGS > kmodpatch requires root privileges even to just read the content of the > kernel tables. > > In write mode, the use of kmodpatch is as dangerous as accessing > /dev/kmem in write mode, even though kmodpatch does some amount of > check- > ing to make sure that the arguments passed are reasonable. To this pur- > pose, it is fundamental that the table descriptions used by kmodpatch > match the actual structure of the kernel tables. There is no automatic > way to extract this info. > > BUGS > Right now, kmodpatch only writes to in-memory modules (or kernel). As a > consequence the approach is not suitable to devices that are > persistently > connected to the system and for which the system cannot do a "reprobe". > > SEE ALSO > kldconfig(8), kldload(8), kldstat(8), kldunload(8) > > HISTORY > The kmodpatch utility first appeared in FreeBSD 8.0 inspired by a > similar > feature present on Linux. > > AUTHORS > The kmodpatch utility was designed and implemented by Luigi Rizzo > . > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Thu Jan 1 20:19:21 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6350D1065673; Thu, 1 Jan 2009 20:19:21 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 473128FC16; Thu, 1 Jan 2009 20:19:21 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n01KJKFx026243; Thu, 1 Jan 2009 12:19:20 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Jan 2009 12:16:37 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SCTP related issue with recent ARP changes? Thread-Index: AclsMle5U2WQGWG/SKSzlWZ3/NiGZQAG4G76 References: From: "Li, Qing" To: =?iso-8859-1?Q?Michael_T=FCxen?= , "FreeBSD Net" Cc: qingli@freebsd.org, current@freebsd.org Subject: RE: SCTP related issue with recent ARP changes? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2009 20:19:22 -0000 Hi Michael, Your problem could be related to the recent ARP changes. I will investigate further to confirm.=20 Thanks, -- Qing -----Original Message----- From: owner-freebsd-net@freebsd.org on behalf of Michael T=FCxen Sent: Thu 1/1/2009 8:59 AM To: FreeBSD Net Subject: SCTP related issue with recent ARP changes? =20 Dear all, I'm running the current CVS version of FreeBSD 8 in a virtual machine using VMWare 2.0.1 on a Mac (not sure if this is relevant) and bridged networking having an em interface on the virtual machine. I'm using a similar setup with older FreeBSD machines and they are running fine. Loopback communication based on UDP, TCP, SCTP or ICMP works fine. Communicating with other hosts using UDP, TCP or ICMP works fine. Communicating with other hosts using SCTP does not work. The SCTP stack calls ip_output() and an ARP request for the correct destination IP address is send out. A corresponding ARP reply is visible in Wireshark (running on the FreeBSD 8 box) and looks good. However, the corresponding SCTP packet it never sent out. I'm not sure, but this might be related to the recent ARP changes. Is there anything required from the transport layer to be done when calling ip_output() that was not required before? Best regards Michael _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Jan 1 20:27:55 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63326106564A for ; Thu, 1 Jan 2009 20:27:55 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id A79C98FC17 for ; Thu, 1 Jan 2009 20:27:54 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 01 Jan 2009 20:01:11 -0000 Received: from p54A3CB57.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.203.87] by mail.gmx.net (mp005) with SMTP; 01 Jan 2009 21:01:11 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1+IahVy0qWIis6GK9r4/tioy2yEr9qeMEagR49wdQ OmmeeLI9m2qRcO Message-ID: <495D2106.2090403@gmx.de> Date: Thu, 01 Jan 2009 21:01:10 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.18 (X11/20081124) MIME-Version: 1.0 To: Luigi Rizzo References: <20090101183026.GA15385@onelab2.iet.unipi.it> In-Reply-To: <20090101183026.GA15385@onelab2.iet.unipi.it> Content-Type: multipart/mixed; boundary="------------040209030708000900040003" X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@freebsd.org Subject: Re: RFC: new utility, kmodpatch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2009 20:27:55 -0000 This is a multi-part message in MIME format. --------------040209030708000900040003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Luigi Rizzo schrieb: > In a nutshell, the kmodpatch utility can print or alter the content > of device/quirk tables in kernel modules (I think Linux has some > similar tool, though i don't remember the name -- or perhaps it is > a feature of insmod ?). This looks useful for experimentation. > Feedback welcome. Attached is a slightly cleaned up version of your tool. I style(9)ified it a bit, added const and static, removed unused stuff (asm("jmp foo")?), added error checks in some places, which were missing, and ensured that the table read in from file is NUL-terminated. I also marked one place with XXX, where I think there is an off-by-one error. > DESCRIPTION > [...] > A couple of real life examples: > > kmodpatch umass.ko - @0 0x4050 0x4a5 0x0101 0x4200 > set the kernel to use flags UMASS_PROTO_SCSI | UMASS_PROTO_BBB and > quirks WRONG_CSWSIG | NO_SYNCHRONIZE_CACHE for a certain GSM phone > that implements the umass interface; > > kmodpatch uscanner.ko - @0 0x04b8 0x084a 0 > let uscanner.ko recognise a newly introduced MFP scanner device. I think, this should be moved into the EXAMPLES section. Regards Christoph PS: Hopefully you haven't forgotten my patch. --------------040209030708000900040003-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 1 20:35:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8D12106566C for ; Thu, 1 Jan 2009 20:35:11 +0000 (UTC) (envelope-from jjacobson@panasas.com) Received: from laguna.int.panasas.com (gw-ca.panasas.com [66.104.249.162]) by mx1.freebsd.org (Postfix) with ESMTP id AF71C8FC16 for ; Thu, 1 Jan 2009 20:35:11 +0000 (UTC) (envelope-from jjacobson@panasas.com) Received: from [172.17.133.160] ([172.17.133.160]) by laguna.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Jan 2009 12:22:54 -0800 Message-Id: <3D76E927-AD4F-4B6E-83E8-44379814FD98@panasas.com> From: Joel Jacobson To: freebsd-current@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 1 Jan 2009 12:22:57 -0800 X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 01 Jan 2009 20:22:54.0438 (UTC) FILETIME=[BA39F860:01C96C4E] Subject: gstripe performance oddity X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2009 20:35:12 -0000 i tried sending this to freebsd-geom but got no response, so i'll try a higher traffic superset list... i have a bit of a weird issue, which i suspect is a configuration problem, and was looking for a little advice. i have an LSI JBOD box with a bunch of SAS drives that i would like to gstripe together. each drive individually seems to be able to do about 80 MB/sec streaming write, and doing parallel dd's gives me the 160 MB/sec i would expect. if i gstripe them together with a 256k stripe width, i only see 80 MB/sec, though. if, however, i newfs/mount it as ufs and then dd myself a big file, that gets me about 120-130 MB/sec. why does mounting matter? - j From owner-freebsd-current@FreeBSD.ORG Thu Jan 1 22:00:28 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C4C8106566B for ; Thu, 1 Jan 2009 22:00:28 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id A10678FC17 for ; Thu, 1 Jan 2009 22:00:27 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 01 Jan 2009 22:00:25 -0000 Received: from p54A3CB57.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.203.87] by mail.gmx.net (mp069) with SMTP; 01 Jan 2009 23:00:25 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX19MZNVt7B9MRJ7lTV8i5RHq+7GbVL7FHFpgmKVYie 6OU0xHtYsDku88 Message-ID: <495D3CF9.1010701@gmx.de> Date: Thu, 01 Jan 2009 23:00:25 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.18 (X11/20081124) MIME-Version: 1.0 To: Luigi Rizzo References: <20090101183026.GA15385@onelab2.iet.unipi.it> <495D2106.2090403@gmx.de> In-Reply-To: <495D2106.2090403@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.82 Cc: current@freebsd.org Subject: Re: RFC: new utility, kmodpatch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2009 22:00:28 -0000 Christoph Mallon schrieb: > Attached is a slightly cleaned up version of your tool. [...] The list ate my attachment. Here is a direct link: http://tron.homeunix.org/kmodpatch.c From owner-freebsd-current@FreeBSD.ORG Fri Jan 2 00:39:43 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4F4D1065673 for ; Fri, 2 Jan 2009 00:39:43 +0000 (UTC) (envelope-from minimarmot@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by mx1.freebsd.org (Postfix) with ESMTP id 95D7C8FC22 for ; Fri, 2 Jan 2009 00:39:43 +0000 (UTC) (envelope-from minimarmot@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so7413211rvf.43 for ; Thu, 01 Jan 2009 16:39:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=55SPKD11GfOE/QUl1s41stOXnZurWdazbomP02QF/TA=; b=slanFMdqi/V59dsjeALxwjZXCfr8Ej8fFoZ5Uz6zZqwU7mq0LKz0Mcm38BgH4mefUf thfxVAqtIkHndh3qSJWkdGETdZnHXw6hFXD4OjZ5KLQzKYGh1FkTWixSQbWRxHyIx/jF XOb2/RnN9HNBw9Y1C+k25KIM2K5hpbBuYUwns= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=W3XudeuGCRfg/rbvVSMW1t7VVvJ32fWinZCgbgxYQQFyg5HjdOZmUvkEaoJDV5LrxR 8GYOF68QCsl4NiOqub85vIRYLBAJs/zLMNopqYEAV32EHkhiuIT3HHLelOA4XWPazFpc vKpjQ9tpTWj7N5rvDNv8jxSHHNG60rgGZYyX0= Received: by 10.142.43.7 with SMTP id q7mr7102905wfq.207.1230855552996; Thu, 01 Jan 2009 16:19:12 -0800 (PST) Received: by 10.143.109.9 with HTTP; Thu, 1 Jan 2009 16:19:12 -0800 (PST) Message-ID: <47d0403c0901011619r658fd25ct3d01bc32969bde11@mail.gmail.com> Date: Thu, 1 Jan 2009 19:19:12 -0500 From: "Ben Kaduk" To: "Oliver Pinter" In-Reply-To: <6101e8c40901011117y3e82a226id6f9de940b0f7dcd@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20090101183026.GA15385@onelab2.iet.unipi.it> <6101e8c40901011117y3e82a226id6f9de940b0f7dcd@mail.gmail.com> Cc: Luigi Rizzo , current@freebsd.org Subject: Re: RFC: new utility, kmodpatch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2009 00:39:44 -0000 On Thu, Jan 1, 2009 at 2:17 PM, Oliver Pinter wrote: > Hi! > > Do You think for this project: http://www.ksplice.com/ ? > > On 1/1/09, Luigi Rizzo wrote: >> I mentioned this utility a couple of months ago, and it's now working >> so i would like to receive feedback on whether this is good to have >> as part of the system, or just keep it as a port (which is what >> i plan to do by default). >> >> In a nutshell, the kmodpatch utility can print or alter the content >> of device/quirk tables in kernel modules (I think Linux has some >> similar tool, though i don't remember the name -- or perhaps it is >> a feature of insmod ?). >> Ksplice is not yet in the linux kernel tree, so it's probably not what Luigi was referring to. However, it is a pretty impressive piece of software, intended to apply security updates to a running kernel with a "hot-patch" approach. They give their latest status update here: http://lkml.org/lkml/2008/12/5/330 I like that they have the goal of following the entire stable tree, since it's not always clear which updates are security-related. Their work is currently licensed under a GPLv2, and they haven't thought very hard about whether they would be willing to relicense with a BSD license. (They're focusing their efforts on the Linux kernel, for the moment.) -Ben Kaduk (disclaimer: the Ksplice developers are friends of mine, so I heard most of this first-hand.) From owner-freebsd-current@FreeBSD.ORG Fri Jan 2 01:36:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 692E0106566B for ; Fri, 2 Jan 2009 01:36:46 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from phoebe.cse.buffalo.edu (phoebe.cse.buffalo.edu [128.205.32.89]) by mx1.freebsd.org (Postfix) with ESMTP id 2CF0B8FC08 for ; Fri, 2 Jan 2009 01:36:46 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from [128.205.32.76] (bauer.cse.buffalo.edu [128.205.32.76]) (authenticated bits=0) by phoebe.cse.buffalo.edu (8.14.1/8.13.7) with ESMTP id n0215HJM036605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 1 Jan 2009 20:05:19 -0500 (EST) (envelope-from kensmith@cse.buffalo.edu) From: Ken Smith To: freebsd-current Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-shMbubUrZuyWwEDvmFLn" Date: Thu, 01 Jan 2009 20:05:17 -0500 Message-Id: <1230858317.43523.43.camel@bauer.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-DCC--Metrics: phoebe.cse.buffalo.edu 1335; Body=0 Fuz1=0 Fuz2=0 X-Spam-Status: No, score=-4.0 required=5.0 tests=RCVD_IN_DNSWL_MED autolearn=failed version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on phoebe.cse.buffalo.edu Subject: Warning about uid values larger than 16-bit... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2009 01:36:46 -0000 --=-shMbubUrZuyWwEDvmFLn Content-Type: text/plain Content-Transfer-Encoding: quoted-printable One of the things I'd like to see go away as part of 8.0 is the warnings various things (sysinstall, pwd_mkdb(8), etc.) give if you choose a uid that won't fit in a 16-bit data structure. One of the reasons that warning is still there is the SYS-V IPC infrastructure and I've been contacted by someone who says they will be working on that shortly so that issue should be addressed. Does anyone know of anything else that could cause problems for uids larger than 16-bits? Please just send me private email at this point, I'll investigate and if it is still an issue will try to hunt down someone to fix it. Thanks. --=20 Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-shMbubUrZuyWwEDvmFLn Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkldaE0ACgkQ/G14VSmup/biLQCbBFATuffHqsnSglCeN47Ikvck vBIAn26uVAvdKXIIJSTPLAS26Y4lmgll =yAiB -----END PGP SIGNATURE----- --=-shMbubUrZuyWwEDvmFLn-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 2 06:21:48 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDCB3106564A for ; Fri, 2 Jan 2009 06:21:48 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id B76B58FC17 for ; Fri, 2 Jan 2009 06:21:48 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.28.129] (d75-157-251-204.bchsia.telus.net [75.157.251.204]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id n026Lkxd089136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Jan 2009 22:21:47 -0800 (PST) (envelope-from sobomax@FreeBSD.org) Message-ID: <495DB269.5030803@FreeBSD.org> Date: Thu, 01 Jan 2009 22:21:29 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Joel Jacobson References: <3D76E927-AD4F-4B6E-83E8-44379814FD98@panasas.com> In-Reply-To: <3D76E927-AD4F-4B6E-83E8-44379814FD98@panasas.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: gstripe performance oddity X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2009 06:21:49 -0000 Joel Jacobson wrote: > i tried sending this to freebsd-geom but got no response, so i'll try a > higher traffic superset list... > > i have a bit of a weird issue, which i suspect is a configuration > problem, and was looking for a little advice. i have an LSI JBOD box > with a bunch of SAS drives that i would like to gstripe together. each > drive individually seems to be able to do about 80 MB/sec streaming > write, and doing parallel dd's gives me the 160 MB/sec i would expect. > if i gstripe them together with a 256k stripe width, i only see 80 > MB/sec, though. > > if, however, i newfs/mount it as ufs and then dd myself a big file, that > gets me about 120-130 MB/sec. > > why does mounting matter? You will see dd write speed increase on stripe only if you are using block size (bs=XX) larger than stripe size, so that you should try dd bs=512k or something and see if it helps. -Maxim From owner-freebsd-current@FreeBSD.ORG Fri Jan 2 08:05:23 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37CEE106566C for ; Fri, 2 Jan 2009 08:05:23 +0000 (UTC) (envelope-from jjacobson@panasas.com) Received: from laguna.int.panasas.com (gw-ca.panasas.com [66.104.249.162]) by mx1.freebsd.org (Postfix) with ESMTP id 19E668FC1E for ; Fri, 2 Jan 2009 08:05:22 +0000 (UTC) (envelope-from jjacobson@panasas.com) Received: from [172.17.133.160] ([172.17.133.160]) by laguna.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Jan 2009 00:05:06 -0800 Message-Id: <4B586604-517A-4945-9EED-DC93DD751FB3@panasas.com> From: Joel Jacobson To: Maxim Sobolev In-Reply-To: <495DB269.5030803@FreeBSD.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 2 Jan 2009 00:05:09 -0800 References: <3D76E927-AD4F-4B6E-83E8-44379814FD98@panasas.com> <495DB269.5030803@FreeBSD.org> X-Mailer: Apple Mail (2.929.2) X-OriginalArrivalTime: 02 Jan 2009 08:05:06.0542 (UTC) FILETIME=[D2EAD8E0:01C96CB0] Cc: freebsd-current@FreeBSD.org Subject: Re: gstripe performance oddity X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2009 08:05:23 -0000 im already doing what you suggest. here's a simple sample of experiments which probably better describe what im seeing: --------------------------- ca-sbox-2# foreach i (0 1) foreach? dd if=/dev/zero of=/dev/da$i bs=512k count=1024 & foreach? end [1] 5402 [2] 5403 ca-sbox-2# 1024+0 records in 1024+0 records out 536870912 bytes transferred in 4.262723 secs (125945532 bytes/sec) 1024+0 records in 1024+0 records out 536870912 bytes transferred in 4.272499 secs (125657357 bytes/sec) ca-sbox-2# gstripe create -s 262144 d0 /dev/da{0,1} ca-sbox-2# dd if=/dev/zero of=/dev/stripe/d0 bs=512k count=4096 4096+0 records in 4096+0 records out 2147483648 bytes transferred in 34.124683 secs (62930508 bytes/sec) ca-sbox-2# newfs /dev/stripe/d0 > /dev/null ca-sbox-2# mount /dev/stripe/d0 /mnt ca-sbox-2# dd if=/dev/zero of=/mnt/bigfile bs=512k count=4096 && /usr/ bin/time sync 4096+0 records in 4096+0 records out 2147483648 bytes transferred in 11.081184 secs (193795502 bytes/sec) 0.06 real 0.00 user 0.04 sys # sysctl kern.geom kern.geom.collectstats: 1 kern.geom.debugflags: 0 kern.geom.label.debug: 0 kern.geom.stripe.fast_failed: 0 kern.geom.stripe.maxmem: 13107200 kern.geom.stripe.fast: 1 kern.geom.stripe.debug: 0 ---------------------- - j On Jan 1, 2009, at 10:21 PM, Maxim Sobolev wrote: > Joel Jacobson wrote: >> i tried sending this to freebsd-geom but got no response, so i'll >> try a higher traffic superset list... >> i have a bit of a weird issue, which i suspect is a configuration >> problem, and was looking for a little advice. i have an LSI JBOD >> box with a bunch of SAS drives that i would like to gstripe >> together. each drive individually seems to be able to do about 80 >> MB/sec streaming write, and doing parallel dd's gives me the 160 MB/ >> sec i would expect. if i gstripe them together with a 256k stripe >> width, i only see 80 MB/sec, though. >> if, however, i newfs/mount it as ufs and then dd myself a big file, >> that gets me about 120-130 MB/sec. >> why does mounting matter? > > You will see dd write speed increase on stripe only if you are using > block size (bs=XX) larger than stripe size, so that you should try > dd bs=512k or something and see if it helps. > > -Maxim From owner-freebsd-current@FreeBSD.ORG Fri Jan 2 09:13:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE9A5106566B for ; Fri, 2 Jan 2009 09:13:35 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id AE4B78FC16 for ; Fri, 2 Jan 2009 09:13:35 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.2/8.14.2) with ESMTP id n029DYRM045523; Fri, 2 Jan 2009 01:13:35 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.2/8.14.2/Submit) id n029DY7Y045522; Fri, 2 Jan 2009 01:13:34 -0800 (PST) (envelope-from obrien) Date: Fri, 2 Jan 2009 01:13:34 -0800 From: "David O'Brien" To: Boris Samorodov Message-ID: <20090102091334.GA41230@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Boris Samorodov , Artem Belevich , freebsd-current@freebsd.org References: <80044077@bb.ipt.ru> <69321574@bs1.sp34.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <69321574@bs1.sp34.ru> X-Operating-System: FreeBSD 8.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-current@freebsd.org, Artem Belevich Subject: Re: gjournal is not automounted any more X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2009 09:13:36 -0000 On Wed, Dec 31, 2008 at 10:45:13PM +0300, Boris Samorodov wrote: > "Artem Belevich" writes: > > >> /dev/mirror/gm0.journal /m ufs,async rw 2 2 > > > > Looks like there's an error in your fstab. You've added "async" to the > > filesystem type instead of mount options. It should probably look like > > this: > > > > /dev/mirror/gm0.journal /m ufs async,rw 2 2 > > > > Might explain why mount does not like it. > > Hm, well... You are right. But it used to work so far though... Before 'fsck' would read the lable for the FS type. That has changed and thus you cannot just 'fsck /dev/ad1s1d' anymore. So the FS type in fstab must be accurate. -- David From owner-freebsd-current@FreeBSD.ORG Fri Jan 2 10:28:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA93E106566B for ; Fri, 2 Jan 2009 10:28:09 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from mail.ipt.ru (mail.ipt.ru [194.62.233.102]) by mx1.freebsd.org (Postfix) with ESMTP id 7CA8F8FC16 for ; Fri, 2 Jan 2009 10:28:09 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from sp34.ipt.ru ([194.62.233.107] helo=bs1.sp34.ru) by mail.ipt.ru with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1LIhGA-000MYM-S3; Fri, 02 Jan 2009 13:28:06 +0300 Received: from bsam by bs1.sp34.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LIhGA-0000KG-MV; Fri, 02 Jan 2009 13:28:06 +0300 To: obrien@freebsd.org References: <80044077@bb.ipt.ru> <69321574@bs1.sp34.ru> <20090102091334.GA41230@dragon.NUXI.org> From: Boris Samorodov Date: Fri, 02 Jan 2009 13:28:06 +0300 In-Reply-To: <20090102091334.GA41230@dragon.NUXI.org> (David O'Brien's message of "Fri\, 2 Jan 2009 01\:13\:34 -0800") Message-ID: <03225241@bs1.sp34.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@freebsd.org, Artem Belevich Subject: Re: gjournal is not automounted any more X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2009 10:28:10 -0000 "David O'Brien" writes: > On Wed, Dec 31, 2008 at 10:45:13PM +0300, Boris Samorodov wrote: >> "Artem Belevich" writes: >> >> >> /dev/mirror/gm0.journal /m ufs,async rw 2 2 >> > >> > Looks like there's an error in your fstab. You've added "async" to the >> > filesystem type instead of mount options. It should probably look like >> > this: >> > >> > /dev/mirror/gm0.journal /m ufs async,rw 2 2 >> > >> > Might explain why mount does not like it. >> >> Hm, well... You are right. But it used to work so far though... > > Before 'fsck' would read the lable for the FS type. That has changed and > thus you cannot just 'fsck /dev/ad1s1d' anymore. So the FS type in fstab > must be accurate. Aha, then there is no magic even at a New Year. ;-) Thanks, David! WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-current@FreeBSD.ORG Fri Jan 2 10:43:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4755106566B for ; Fri, 2 Jan 2009 10:43:42 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from smtp-vbr3.xs4all.nl (smtp-vbr3.xs4all.nl [194.109.24.23]) by mx1.freebsd.org (Postfix) with ESMTP id 6B5E78FC0C for ; Fri, 2 Jan 2009 10:43:42 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from w2003s01.double-l.local (double-l.xs4all.nl [80.126.205.144]) by smtp-vbr3.xs4all.nl (8.13.8/8.13.8) with ESMTP id n02ATgJZ028900 for ; Fri, 2 Jan 2009 11:29:46 +0100 (CET) (envelope-from Johan@double-l.nl) MIME-Version: 1.0 Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 2 Jan 2009 11:32:44 +0100 Message-ID: <57200BF94E69E54880C9BB1AF714BBCB0111B3@w2003s01.double-l.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: build -j3 not working anymore on Current Thread-Index: AclsxXKRtWlf/KP/SPCKkWq92S6MEw== From: "Johan Hendriks" To: X-Virus-Scanned: by XS4ALL Virus Scanner Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: build -j3 not working anymore on Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2009 10:43:43 -0000 Hello all=20 First of all a very happy new year to you all. I have 2 test machines running HEAD, one i386 (dual PIII) and one amd64 = Core2Duo=20 I always use the following command to do the buildworld cycles. make cleanworld && make -j3 buildworld && make -j3 kernel But as of now i get the following error =3D=3D=3D> gnu/usr.bin/texinfo/doc (all) --- info.info --- --- info-stnd.info --- --- texinfo.texi --- --- info.info --- makeinfo --no-split -I /usr/src/gnu/usr.bin/texinfo/doc -I = /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc = /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/info.tex= i -o info.info --- info-stnd.info --- makeinfo --no-split -I /usr/src/gnu/usr.bin/texinfo/doc -I = /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc = /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/info-stn= d.texi -o info-stnd.info --- texinfo.texi --- ln -fs = /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/texinfo.= txi texinfo.texi --- texinfo.info --- makeinfo --no-split -I /usr/src/gnu/usr.bin/texinfo/doc -I = /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc = texinfo.texi -o texinfo.info --- info.info.gz --- gzip -cn info.info > info.info.gz --- info-stnd.info.gz --- gzip -cn info-stnd.info > info-stnd.info.gz --- texinfo.info.gz --- gzip -cn texinfo.info > texinfo.info.gz 1 error *** Error code 2 1 error *** Error code 2 1 error This is on both machines. The amd64 machine i rebuild with make cleanworld && make buildworld && = make kernel, and that works, but when i use the -j3 again it fails = again. the source is from today. the i386 uses the USB2 kernel the amd64 machine use a custom kernel include GENERIC ident KRNL # Polling options DEVICE_POLLING # pf options ALTQ options ALTQ_CBQ options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_CDNR options ALTQ_PRIQ device pf device pflog device pfsync # Samba Options options NETSMB options LIBMCHAIN options LIBICONV options SMBFS # Console color options options SC_NORM_ATTR=3D(FG_LIGHTGREY|BG_BLACK) options SC_NORM_REV_ATTR=3D(FG_YELLOW|BG_GREEN) options SC_KERNEL_CONS_ATTR=3D(FG_BROWN|BG_BLACK) options SC_KERNEL_CONS_REV_ATTR=3D(FG_BLACK|BG_RED) # System console options options SC_DISABLE_REBOOT # disable reboot key sequence options SC_HISTORY_SIZE=3D200 # number of history buffer = lines # Debugging for use in -current nooptions KDB # Enable kernel debugger = support. nooptions DDB # Support DDB. nooptions GDB # Support remote GDB. nooptions INVARIANTS # Enable calls of extra sanity = checking nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS nooptions WITNESS # Enable checks to detect = deadlocks and cycles nooptions WITNESS_SKIPSPIN # Don't run witness on = spinlocks for speed regards, Johan Hendriks From owner-freebsd-current@FreeBSD.ORG Fri Jan 2 11:53:41 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA47D106566B for ; Fri, 2 Jan 2009 11:53:41 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9E4AA8FC17 for ; Fri, 2 Jan 2009 11:53:41 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by noop.in-addr.com with local (Exim 4.54 (FreeBSD)) id 1LIiax-000OEe-TD; Fri, 02 Jan 2009 06:53:39 -0500 Date: Fri, 2 Jan 2009 06:53:39 -0500 From: Gary Palmer To: Johan Hendriks Message-ID: <20090102115339.GA81380@in-addr.com> References: <57200BF94E69E54880C9BB1AF714BBCB0111B3@w2003s01.double-l.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57200BF94E69E54880C9BB1AF714BBCB0111B3@w2003s01.double-l.local> Cc: freebsd-current@freebsd.org Subject: Re: build -j3 not working anymore on Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2009 11:53:42 -0000 On Fri, Jan 02, 2009 at 11:32:44AM +0100, Johan Hendriks wrote: > > Hello all > > First of all a very happy new year to you all. > > I have 2 test machines running HEAD, one i386 (dual PIII) and one amd64 Core2Duo > I always use the following command to do the buildworld cycles. > > make cleanworld && make -j3 buildworld && make -j3 kernel > > But as of now i get the following error > > ===> gnu/usr.bin/texinfo/doc (all) > --- info.info --- > --- info-stnd.info --- > --- texinfo.texi --- > --- info.info --- > makeinfo --no-split -I /usr/src/gnu/usr.bin/texinfo/doc -I /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/info.texi -o info.info > --- info-stnd.info --- > makeinfo --no-split -I /usr/src/gnu/usr.bin/texinfo/doc -I /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/info-stnd.texi -o info-stnd.info > --- texinfo.texi --- > ln -fs /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/texinfo.txi texinfo.texi > --- texinfo.info --- > makeinfo --no-split -I /usr/src/gnu/usr.bin/texinfo/doc -I /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc texinfo.texi -o texinfo.info > --- info.info.gz --- > gzip -cn info.info > info.info.gz > --- info-stnd.info.gz --- > gzip -cn info-stnd.info > info-stnd.info.gz > --- texinfo.info.gz --- > gzip -cn texinfo.info > texinfo.info.gz > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error Johan, Unfortunately with -jn where n > 1, the actual error message is hidden earlier in the output. The above text does not include the actual error that occurred, just that one happened at some point. Does make cleanworld && make buildworld && make kernel work? If not, it will highlight where the problem is. Regards, Gary From owner-freebsd-current@FreeBSD.ORG Fri Jan 2 12:01:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3CFB11065670 for ; Fri, 2 Jan 2009 12:01:16 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from smtp-vbr13.xs4all.nl (smtp-vbr13.xs4all.nl [194.109.24.33]) by mx1.freebsd.org (Postfix) with ESMTP id CB9708FC1D for ; Fri, 2 Jan 2009 12:01:15 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from w2003s01.double-l.local (double-l.xs4all.nl [80.126.205.144]) by smtp-vbr13.xs4all.nl (8.13.8/8.13.8) with ESMTP id n02C16lh015851; Fri, 2 Jan 2009 13:01:14 +0100 (CET) (envelope-from Johan@double-l.nl) MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 2 Jan 2009 13:01:07 +0100 Message-ID: <57200BF94E69E54880C9BB1AF714BBCB5DE3C6@w2003s01.double-l.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: build -j3 not working anymore on Current Thread-Index: Acls0TI9HkPoOVWpTIqkGi+dB1kSgAAAB5Ug References: <57200BF94E69E54880C9BB1AF714BBCB0111B3@w2003s01.double-l.local> <20090102115339.GA81380@in-addr.com> From: "Johan Hendriks" To: "Gary Palmer" X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-current@freebsd.org Subject: RE: build -j3 not working anymore on Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2009 12:01:16 -0000 Hello If you read on after the error message in my mail you will see that a = buildworld cycle without the -j3 option works so I get no error message = that way ;-) At least at the amd64 host, the i386 is still building, it takes some = time on a PIII ;-) So I have no idea where the error message kicks in. Is there a way to get the error message? Regards, Johan Hendriks No virus found in this outgoing message. Checked by AVG - http://www.avg.com=20 Version: 8.0.176 / Virus Database: 270.10.2/1871 - Release Date: = 1-1-2009 17:01 From owner-freebsd-current@FreeBSD.ORG Fri Jan 2 12:30:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D18B106566C for ; Fri, 2 Jan 2009 12:30:53 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id E8FA28FC20 for ; Fri, 2 Jan 2009 12:30:52 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from gjp by noop.in-addr.com with local (Exim 4.54 (FreeBSD)) id 1LIjAy-000OHw-1Y; Fri, 02 Jan 2009 07:30:52 -0500 Date: Fri, 2 Jan 2009 07:30:51 -0500 From: Gary Palmer To: Johan Hendriks Message-ID: <20090102123051.GB81380@in-addr.com> References: <57200BF94E69E54880C9BB1AF714BBCB0111B3@w2003s01.double-l.local> <20090102115339.GA81380@in-addr.com> <57200BF94E69E54880C9BB1AF714BBCB5DE3C6@w2003s01.double-l.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57200BF94E69E54880C9BB1AF714BBCB5DE3C6@w2003s01.double-l.local> Cc: freebsd-current@freebsd.org Subject: Re: build -j3 not working anymore on Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2009 12:30:53 -0000 On Fri, Jan 02, 2009 at 01:01:07PM +0100, Johan Hendriks wrote: > > Hello > > If you read on after the error message in my mail you will see that a buildworld cycle without the -j3 option works so I get no error message that way ;-) Johan, Sorry, missed that bit. > At least at the amd64 host, the i386 is still building, it takes some time on a PIII ;-) > > So I have no idea where the error message kicks in. > > Is there a way to get the error message? >From memory: If you have the build output in a log file, look for '**' at the start of the line. If you look around where you find the '**' you should hopefully find the error messages. Regards, Gary From owner-freebsd-current@FreeBSD.ORG Fri Jan 2 13:17:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1DCA106564A; Fri, 2 Jan 2009 13:17:00 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from smtp-vbr5.xs4all.nl (smtp-vbr5.xs4all.nl [194.109.24.25]) by mx1.freebsd.org (Postfix) with ESMTP id EBE038FC12; Fri, 2 Jan 2009 13:16:59 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from w2003s01.double-l.local (double-l.xs4all.nl [80.126.205.144]) by smtp-vbr5.xs4all.nl (8.13.8/8.13.8) with ESMTP id n02DGwnN075438; Fri, 2 Jan 2009 14:16:58 +0100 (CET) (envelope-from Johan@double-l.nl) MIME-Version: 1.0 Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 2 Jan 2009 14:20:00 +0100 Message-ID: <57200BF94E69E54880C9BB1AF714BBCB0111B4@w2003s01.double-l.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: build -j3 not working anymore on Current Thread-Index: Acls1mIG/lZGMBvKRyqJm2zGvBNqAAABVUp4 References: <57200BF94E69E54880C9BB1AF714BBCB0111B3@w2003s01.double-l.local> <20090102115339.GA81380@in-addr.com> <57200BF94E69E54880C9BB1AF714BBCB5DE3C6@w2003s01.double-l.local> <20090102123051.GB81380@in-addr.com> From: "Johan Hendriks" To: "Gary Palmer" X-Virus-Scanned: by XS4ALL Virus Scanner Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: RE: build -j3 not working anymore on Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2009 13:17:01 -0000 >>=20 >> Hello >>=20 >> If you read on after the error message in my mail you will see that a = buildworld cycle without the -j3 option works so I get no error message = that way ;-) >Johan, >Sorry, missed that bit.=20 >> At least at the amd64 host, the i386 is still building, it takes some = time on a PIII ;-) >>=20 >> So I have no idea where the error message kicks in. >>=20 >> Is there a way to get the error message? >From memory: >If you have the build output in a log file, look for '**' at the start >of the line. If you look around where you find the '**' you should >hopefully find the error messages. >Regards, >Gary Ok i did the build again with the following option buildworld -j3 >> = /var/log/buildlog Then i searched for ** and the following came up , i do not now how many = line i need to capture!=20 If you need more let me know! the parts with the double ** came up twice. --- curses.head --- sed = curses.head -e "/@BROKEN_LINKER@/s%%0%" -e "/@HAVE_VSSCANF@/s%%1%" = -e "/@N CURSES_CH_T@/s%%chtype%" -e "/@NCURSES_CONST@/s%%const%" -e = "/@NCURSES_EXT_COLORS@/s%%0%" -e "/@NCURSES_EXT_FUNCS@/s%%1%" -e = "/@NCURSES_INLINE@/s%%inline %" -e "/@NCURSES_LIBUTF8@/s%%0%" -e "/@NCURSES_MAJOR@/s%%5%" -e = "/@NCURSES_MBSTATE_T@/s%%0%" -e "/@NCURSES_MINOR@/s%%7%" -e = "/@NCURSES_MOUSE_VERSION@/s% %1%" -e "/@NCURSES_OK_WCHAR_T@/s%%%" -e "/@NCURSES_OPAQUE@/s%%0%" -e = "/@NCURSES_PATCH@/s%%20081102%" -e "/@NCURSES_SIZE_T@/s%%short%" -e = "/@NCURSES_TPAR M_VARARGS@/s%%1%" -e "/@NCURSES_WCHAR_T@/s%%0%" -e = "/@NCURSES_WCHAR_T@/s%%0%" -e "/@NCURSES_WINT_T@/s%%0%" -e = "/@NEED_WCHAR_H@/s%%0%" -e "/@USE_CXX_BOOL @/s%%defined(__cplusplus)%" -e "s%@cf_cv_1UL@%1UL%g" -e = "s%@cf_cv_builtin_bool@%1%g" -e "s%@cf_cv_enable_lp64@%0%g" -e = "s%@cf_cv_enable_opaque@%NCURSES_O PAQUE%g" -e "s%@cf_cv_enable_reentrant@%0%g" -e = "s%@cf_cv_header_stdbool_h@%1%g" -e "s%@cf_cv_type_of_bool@%unsigned = char%g" -e "s%@cf_cv_typeof_chtype@% long%g" -e "s%@cf_cv_typeof_mmask_t@%long%g" -e "s/ _WCHAR_T/ = __wchar_t/g" -e "s/ _WINT_T/ __wint_t/g" --- MKterm.h.awk --- sed = MKterm.h.awk -e "/@BROKEN_LINKER@/s%%0%" -e = "/@NCURSES_MAJOR@/s%%5%" - e "/@NCURSES_MINOR@/s%%7%" -e "/@NCURSES_CONST@/s%%const%" -e = "/@NCURSES_TPARM_VARARGS@/s%%1%" -e "/@NCURSES_SBOOL@/s%%char%" -e = "/@NCURSES_XNAMES@/s%%1% " -e "/@HAVE_TERMIOS_H@/s%%1%" -e "/@HAVE_TERMIO_H@/s%%0%" -e = "/@HAVE_TCGETATTR@/s%%1%" -e "s%@cf_cv_enable_reentrant@%0%g" --- term.h --- awk -f MKterm.h.awk = /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include/Caps > = term.h.new sh = /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include/edit_cfg.sh= /usr/src/lib/ncurses/ncurses/ncurses_cfg.h term.h.new --- curses.h --- cat curses.head > curses.h.new AWK=3Dawk _POSIX2_VERSION=3D199209 sh = /usr/src/lib/ncurses/ncurses/../../../contrib/ncurses/include/MKkey_defs.= sh /usr/src/lib/ncurses/ncurses/../../../contrib/ ncurses/include/Caps >> curses.h.new --- term.h --- ** edit: HAVE_TCGETATTR 1 ** edit: HAVE_TERMIOS_H 1 ** edit: HAVE_TERMIO_H 0 ** edit: BROKEN_LINKER 0 --- curses.head --- sed = curses.head -e "/@BROKEN_LINKER@/s%%0%" -e "/@HAVE_VSSCANF@/s%%1%" = -e "/@ NCURSES_CH_T@/s%%cchar_t%" -e "/@NCURSES_CONST@/s%%const%" -e = "/@NCURSES_EXT_COLORS@/s%%0%" -e "/@NCURSES_EXT_FUNCS@/s%%1%" -e = "/@NCURSES_INLINE@/s%%inli ne%" -e "/@NCURSES_LIBUTF8@/s%%0%" -e "/@NCURSES_MAJOR@/s%%5%" -e = "/@NCURSES_MBSTATE_T@/s%%0%" -e "/@NCURSES_MINOR@/s%%7%" -e = "/@NCURSES_MOUSE_VERSION@/ s%%1%" -e "/@NCURSES_OK_WCHAR_T@/s%%1%" -e "/@NCURSES_OPAQUE@/s%%0%" = -e "/@NCURSES_PATCH@/s%%20081102%" -e "/@NCURSES_SIZE_T@/s%%short%" -e = "/@NCURSES_T PARM_VARARGS@/s%%1%" -e "/@NCURSES_WCHAR_T@/s%%0%" -e = "/@NCURSES_WCHAR_T@/s%%0%" -e "/@NCURSES_WINT_T@/s%%0%" -e = "/@NEED_WCHAR_H@/s%%1%" -e "/@USE_CXX_B OOL@/s%%defined(__cplusplus)%" -e "s%@cf_cv_1UL@%1UL%g" -e = "s%@cf_cv_builtin_bool@%1%g" -e "s%@cf_cv_enable_lp64@%0%g" -e = "s%@cf_cv_enable_opaque@%NCURSE S_OPAQUE%g" -e "s%@cf_cv_enable_reentrant@%0%g" -e = "s%@cf_cv_header_stdbool_h@%1%g" -e "s%@cf_cv_type_of_bool@%unsigned = char%g" -e "s%@cf_cv_typeof_chtyp e@%long%g" -e "s%@cf_cv_typeof_mmask_t@%long%g" -e "s/ _WCHAR_T/ = __wchar_t/g" -e "s/ _WINT_T/ __wint_t/g" --- curses.h --- cat curses.head > curses.h.new AWK=3Dawk _POSIX2_VERSION=3D199209 sh = /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/include/MKkey_defs= .sh /usr/src/lib/ncurses/ncursesw/../../../contri b/ncurses/include/Caps >> curses.h.new cat = /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/include/curses.wid= e >> curses.h.new --- MKterm.h.awk --- sed = MKterm.h.awk -e "/@BROKEN_LINKER@/s%%0%" -e = "/@NCURSES_MAJOR@/s%%5%" -e "/@NCURSES_MINOR@/s%%7%" -e "/@NCURSES_CONST@/s%%const%" -e = "/@NCURSES_TPARM_VARARGS@/s%%1%" -e "/@NCURSES_SBOOL@/s%%char%" -e = "/@NCURSES_XNAMES@/s%%1 %" -e "/@HAVE_TERMIOS_H@/s%%1%" -e "/@HAVE_TERMIO_H@/s%%0%" -e = "/@HAVE_TCGETATTR@/s%%1%" -e "s%@cf_cv_enable_reentrant@%0%g" --- term.h --- awk -f MKterm.h.awk = /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/include/Caps > = term.h.new sh = /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/include/edit_cfg.s= h /usr/src/lib/ncurses/ncursesw/../ncurses/ncurses_cfg.h term.h.new --- curses.h --- cat = /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/include/curses.tai= l >> curses.h.new mv -f curses.h.new curses.h --- term.h --- ** edit: HAVE_TCGETATTR 1 ** edit: HAVE_TERMIOS_H 1 ** edit: HAVE_TERMIO_H 0 ** edit: BROKEN_LINKER 0 regards, Johan Hendriks From owner-freebsd-current@FreeBSD.ORG Fri Jan 2 13:22:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BFA11065670; Fri, 2 Jan 2009 13:22:31 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from smtp-vbr8.xs4all.nl (smtp-vbr8.xs4all.nl [194.109.24.28]) by mx1.freebsd.org (Postfix) with ESMTP id C663D8FC1F; Fri, 2 Jan 2009 13:22:30 +0000 (UTC) (envelope-from Johan@double-l.nl) Received: from w2003s01.double-l.local (double-l.xs4all.nl [80.126.205.144]) by smtp-vbr8.xs4all.nl (8.13.8/8.13.8) with ESMTP id n02DMTag036814; Fri, 2 Jan 2009 14:22:30 +0100 (CET) (envelope-from Johan@double-l.nl) MIME-Version: 1.0 Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 2 Jan 2009 14:24:07 +0100 Message-ID: <57200BF94E69E54880C9BB1AF714BBCB0111B5@w2003s01.double-l.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: build -j3 not working anymore on Current Thread-Index: Acls1mIG/lZGMBvKRyqJm2zGvBNqAAABwGzh References: <57200BF94E69E54880C9BB1AF714BBCB0111B3@w2003s01.double-l.local> <20090102115339.GA81380@in-addr.com> <57200BF94E69E54880C9BB1AF714BBCB5DE3C6@w2003s01.double-l.local> <20090102123051.GB81380@in-addr.com> From: "Johan Hendriks" To: "Gary Palmer" X-Virus-Scanned: by XS4ALL Virus Scanner Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: RE: build -j3 not working anymore on Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2009 13:22:31 -0000 >>=20 >> Hello >>=20 >> If you read on after the error message in my mail you will see that a = buildworld cycle without the -j3 option works so I get no error message = that way ;-) >Johan, >Sorry, missed that bit.=20 >> At least at the amd64 host, the i386 is still building, it takes some = time on a PIII ;-) >>=20 >> So I have no idea where the error message kicks in. >>=20 >> Is there a way to get the error message? >From memory: >If you have the build output in a log file, look for '**' at the start >of the line. If you look around where you find the '**' you should >hopefully find the error messages. >Regards, >Gary i also found the following error lines. crunchgen: make error: --- crunchgen_objs --- crunchgen: make error: --- loop --- Run "make -f rescue.mk" to build crunched binary. *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 regards, Johan Hendriks From owner-freebsd-current@FreeBSD.ORG Fri Jan 2 15:18:31 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09FC4106564A; Fri, 2 Jan 2009 15:18:31 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id ADF988FC12; Fri, 2 Jan 2009 15:18:30 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.14.3/jtpda-5.4) with ESMTP id n02FIRdN095856 ; Fri, 2 Jan 2009 16:18:28 +0100 (CET) X-Ids: 166 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.13.3/jtpda-5.2) with ESMTP id n02FIQni001836 ; Fri, 2 Jan 2009 16:18:26 +0100 (MET) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.13.3/8.13.1/Submit) id n02FIQOL001833; Fri, 2 Jan 2009 16:18:26 +0100 (MET) (envelope-from arno) To: "Roman Divacky" References: <20081227220645.GA13295@freebsd.org> <20081228175745.GA56640@freebsd.org> <20081228202526.GA74948@freebsd.org> <20081228211505.GA80323@freebsd.org> <20081228214438.GA83007@freebsd.org> From: "Arno J. Klaassen" Date: 02 Jan 2009 16:18:25 +0100 In-Reply-To: Message-ID: Lines: 61 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (shiva.jussieu.fr [134.157.0.166]); Fri, 02 Jan 2009 16:18:28 +0100 (CET) X-Virus-Scanned: ClamAV 0.94.2/8829/Fri Jan 2 15:12:36 2009 on shiva.jussieu.fr X-Virus-Status: Clean X-Miltered: at jchkmail.jussieu.fr with ID 495E3043.006 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 495E3043.006/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ X-j-chkmail-Score: MSGID : 495E3043.006 on jchkmail.jussieu.fr : j-chkmail score : . : R=. U=. O=. B=0.005 -> S=0.005 X-j-chkmail-Status: Ham Cc: emulation@freebsd.org, current@freebsd.org Subject: Re: 8-current: linux_dist-gentoo-stage3 wonn't bootstrap X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2009 15:18:31 -0000 Hello and best wishes, [1 added current@ for a wider audience] [2 the good news, I could install and run quite a number of 'portaghes' in the gentoo_stage3 chroot and this for now is the only problem I have] "Arno J. Klaassen" writes: > [ ... linux-gcc hangs in 'ppwait' state when compiling with -pipe ... ] > > > I dont see anything obvious.. can you do "ps axl" and see what the MWCHAN is? > > > that might shed some light to this... > > > > bon, in fact when I launce the command by hand adding a '-v ' to gcc, output > > says : > > > > /usr/libexec/gcc/i486-pc-linux-gnu/4.1.2/cc1 ... | /usr/lib/gcc/i486-pc-linux-gnu/4.1.2/../../../../i486-pc-linux-gnu/bin/as -V -Qy -o /var/tmp/portage/sys-libs/glibc-2.6.1/work/build-default-i486-pc-linux-gnu-nptl/iconv/gconv_simple.o - > > > > > > but, cc1 is stuck in 'pipewr' and no .../bin/as process is running (any longer) > > nor the file .../gconv_simple.o created > > I investigated this a bit more (still chrooted to /usr/local/gentoo-stage3) : > > i486-pc-linux-gnu-gcc gconv_open.c -c : OK > i486-pc-linux-gnu-gcc gconv_open.c -c -pipe : OK > > i486-pc-linux-gnu-gcc gconv_simple.c -c : OK > i486-pc-linux-gnu-gcc gconv_simple.c -c -pipe : pipe to as(1) fails > > I tried to play with kern.ipc.maxpipekva (I vaguely remember that > was necessary for linux testsuites) pumping it up to "536608768", but > no difference. If someone has another suggestion? Some more info : - it is not specific to just gconv_simple.c; Expat.c generated in the XML-Parser portage has the same behaviour - it is not specific to linux-gcc : it now hangs in "bison -y -d -v 2>/dev/null ./parser.y" a "ps axlww | fgrep 3758" shows : 0 37586 35141 0 76 0 2576 2300 ppwait D+ 0 0:00.04 make (gmake) 0 37587 37586 0 76 0 3316 3148 wait I+ 0 0:00.02 /bin/sh -c bison -y -d -v 2>/dev/null ./parser.y (bash) 0 37588 37587 0 76 0 3044 2484 ppwait D+ 0 0:00.03 bison -y -d -v ./parser.y 0 37589 37588 0 76 0 2432 2132 piperd I+ 0 0:00.01 /usr/bin/m4 /usr/share/bison/m4sugar/m4sugar.m4 - /usr/share/bison/yacc.c -current is as of Sat Dec 27 Thank you for any help Arno From owner-freebsd-current@FreeBSD.ORG Fri Jan 2 18:47:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A247106566B; Fri, 2 Jan 2009 18:47:22 +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 F38CC8FC12; Fri, 2 Jan 2009 18:47:21 +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 n02IkIb3059098; Fri, 2 Jan 2009 11:46:19 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 02 Jan 2009 11:46:27 -0700 (MST) Message-Id: <20090102.114627.1656128188.imp@bsdimp.com> To: Johan@double-l.nl From: "M. Warner Losh" In-Reply-To: <57200BF94E69E54880C9BB1AF714BBCB5DE3C6@w2003s01.double-l.local> References: <57200BF94E69E54880C9BB1AF714BBCB0111B3@w2003s01.double-l.local> <20090102115339.GA81380@in-addr.com> <57200BF94E69E54880C9BB1AF714BBCB5DE3C6@w2003s01.double-l.local> 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: gpalmer@freebsd.org, freebsd-current@freebsd.org Subject: Re: build -j3 not working anymore on Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2009 18:47:22 -0000 In message: <57200BF94E69E54880C9BB1AF714BBCB5DE3C6@w2003s01.double-l.local> "Johan Hendriks" writes: : : Hello : : If you read on after the error message in my mail you will see that a buildworld cycle without the -j3 option works so I get no error message that way ;-) : : At least at the amd64 host, the i386 is still building, it takes some time on a PIII ;-) : : So I have no idea where the error message kicks in. : : Is there a way to get the error message? Search backwards for Error. Warner From owner-freebsd-current@FreeBSD.ORG Fri Jan 2 18:50:27 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A43E106566C; Fri, 2 Jan 2009 18:50:27 +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 19B748FC1C; Fri, 2 Jan 2009 18:50:27 +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 n02Ill4P059144; Fri, 2 Jan 2009 11:47:47 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 02 Jan 2009 11:47:57 -0700 (MST) Message-Id: <20090102.114757.-924277930.imp@bsdimp.com> To: obrien@freebsd.org From: "M. Warner Losh" In-Reply-To: <20090102091334.GA41230@dragon.NUXI.org> References: <69321574@bs1.sp34.ru> <20090102091334.GA41230@dragon.NUXI.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: bsam@ipt.ru, freebsd-current@freebsd.org, fbsdlist@src.cx Subject: Re: gjournal is not automounted any more X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2009 18:50:27 -0000 In message: <20090102091334.GA41230@dragon.NUXI.org> "David O'Brien" writes: : On Wed, Dec 31, 2008 at 10:45:13PM +0300, Boris Samorodov wrote: : > "Artem Belevich" writes: : > : > >> /dev/mirror/gm0.journal /m ufs,async rw 2 2 : > > : > > Looks like there's an error in your fstab. You've added "async" to the : > > filesystem type instead of mount options. It should probably look like : > > this: : > > : > > /dev/mirror/gm0.journal /m ufs async,rw 2 2 : > > : > > Might explain why mount does not like it. : > : > Hm, well... You are right. But it used to work so far though... : : Before 'fsck' would read the lable for the FS type. That has changed and : thus you cannot just 'fsck /dev/ad1s1d' anymore. So the FS type in fstab : must be accurate. Why did that change? I routinely have disks that aren't in my /etc/fstab that I mount and this is a pain in the backside. Warner From owner-freebsd-current@FreeBSD.ORG Fri Jan 2 18:53:27 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7851D106566B for ; Fri, 2 Jan 2009 18:53:27 +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 2938F8FC1B for ; Fri, 2 Jan 2009 18:53:27 +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 n02IoCjr059154; Fri, 2 Jan 2009 11:50:17 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 02 Jan 2009 11:50:22 -0700 (MST) Message-Id: <20090102.115022.1102529931.imp@bsdimp.com> To: rizzo@iet.unipi.it From: "M. Warner Losh" In-Reply-To: <20090101183026.GA15385@onelab2.iet.unipi.it> References: <20090101183026.GA15385@onelab2.iet.unipi.it> 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: current@freebsd.org Subject: Re: RFC: new utility, kmodpatch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2009 18:53:27 -0000 In message: <20090101183026.GA15385@onelab2.iet.unipi.it> Luigi Rizzo writes: : I mentioned this utility a couple of months ago, and it's now working : so i would like to receive feedback on whether this is good to have : as part of the system, or just keep it as a port (which is what : i plan to do by default). : : In a nutshell, the kmodpatch utility can print or alter the content : of device/quirk tables in kernel modules (I think Linux has some : similar tool, though i don't remember the name -- or perhaps it is : a feature of insmod ?). : : Full manpage is attached at the end, full sources are at : : http://info.iet.unipi.it/~luigi/FreeBSD/20090101-kmodpatch.tgz : : What is missing is some extra code to let it patch an on-disk file : (elfdump returns the info we need, so in the worst case we just : need to write a wrapper around elfdump). : : Feedback welcome. Again the feedback I always give here: You really need to have a compatibility table so that all drivers work. This approach is inherently limited to those drivers that have tables, and those drivers that treat any match in that table as the same. Many drivers don't fall into this category. Warner : cheers : luigi : : ------- manpage content -------- : : KMODPATCH(8) FreeBSD System Manager's Manual KMODPATCH(8) : : NAME : kmodpatch -- print/modify device/quirk tables in kernel modules : : SYNOPSIS : kmodpatch [-v] [-t file | format] module_name table_name [@offset [args : ...]] : : DESCRIPTION : The kmodpatch utility can print or alter the content of device/quirk : tables in kernel modules. These tables are generally used to identify : devices, and possibly apply specific quirks to enable/disable certain : features. kmodpatch is especially useful to let the kernel recognise a : new device without rebooting and rebuilding/reinstalling kernel or mod- : ules. : : In read mode (when no args are specified), kmodpatch only list one or : more entries in the matching module and table. : : In write mode, kmodpatch overwrites a user's specified entry in a table : with the values passed on the command line. kmodpatch does some amount : of checking to make sure that the arguments (module and table name, off- : set, parameters formats) are compatible with the currently loaded mod- : ules. : : A couple of real life examples: : : kmodpatch umass.ko - @0 0x4050 0x4a5 0x0101 0x4200 : set the kernel to use flags UMASS_PROTO_SCSI | UMASS_PROTO_BBB and : quirks WRONG_CSWSIG | NO_SYNCHRONIZE_CACHE for a certain GSM phone : that implements the umass interface; : : kmodpatch uscanner.ko - @0 0x04b8 0x084a 0 : let uscanner.ko recognise a newly introduced MFP scanner device. : : kmodpatch relies on a list of which modules and tables (associated to : kernel symbols) it can work on, and the format of the records in each ta- : ble. By default kmodpatch uses an internal list, which can be overridden : from the command line using the -t option followed by either a file name, : or by immediate text describing the kernel table. The format of the file : is described in Section MODULE DESCRIPTION : : The following options are available: : : -v Verbose mode, print some debugging info : : -t file | format : Specify a file containing the name and format of descriptor : tables, or a line with the actual format of the table. : : MODULE DESCRIPTION : The file (or text) describing modules, tables and record structure has a : simple text format with one line per table. The `#' character is a com- : ment delimiter, and can appear anywhere in the text. Each valid line : must contain the following fields: : : module_name symbol_name entry_format [entry_format ...] : : Each entry_format describes one field in the table, and it is made of a : number and/or a character specifying the field size and format, followed : by an optional ':' and a word describing the field itself. : : Supported formats are: : : 2 | 2l | 2b : 16-bit unsigned in host, little-endian or big-endian format; : : 4 | 4l | 4b : 32-bit unsigned in host, little-endian or big-endian format; : : 8 | 8l | 8b : 64-bit unsigned in host, little-endian or big-endian format; : : p a pointer; : : s a null-terminated string; : : The optional description is used as a header when listing the content of : a table. : : EXAMPLE MODULE DESCRIPTION : The following is an example of a file containing module descriptions. : : umass.ko umass_devdescrs 4:vendor 4:product 4:rev 2:proto 2:quirks : uscanner.ko uscanner_devs 2:vendor 2:device 4:flags # comment : if_nfe.ko nfe_devs 2:vendor 2:device s:name : if_re.ko re_devs 2:vendor 2:device 4:type s:name : : EXAMPLES : In addition to the two examples given at the beginning, one can use : kmodpatch to explore the content of kernel tables, as follows. : : To list entries in module if_re: : : kmodpatch if_re - : : To list entry 10 in module umass: : : kmodpatch umass - @10 : : To set the last entry in module uscanner.ko : : kmodpatch uscanner.ko - @-1 0x04b8 0x0839 0 : : WARNINGS : kmodpatch requires root privileges even to just read the content of the : kernel tables. : : In write mode, the use of kmodpatch is as dangerous as accessing : /dev/kmem in write mode, even though kmodpatch does some amount of check- : ing to make sure that the arguments passed are reasonable. To this pur- : pose, it is fundamental that the table descriptions used by kmodpatch : match the actual structure of the kernel tables. There is no automatic : way to extract this info. : : BUGS : Right now, kmodpatch only writes to in-memory modules (or kernel). As a : consequence the approach is not suitable to devices that are persistently : connected to the system and for which the system cannot do a "reprobe". : : SEE ALSO : kldconfig(8), kldload(8), kldstat(8), kldunload(8) : : HISTORY : The kmodpatch utility first appeared in FreeBSD 8.0 inspired by a similar : feature present on Linux. : : AUTHORS : The kmodpatch utility was designed and implemented by Luigi Rizzo : . : : _______________________________________________ : freebsd-current@freebsd.org mailing list : http://lists.freebsd.org/mailman/listinfo/freebsd-current : To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" : From owner-freebsd-current@FreeBSD.ORG Fri Jan 2 18:56:11 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A573106564A for ; Fri, 2 Jan 2009 18:56:11 +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 11EA88FC2E for ; Fri, 2 Jan 2009 18:56:10 +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 n02IsGED059179 for ; Fri, 2 Jan 2009 11:54:16 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 02 Jan 2009 11:54:26 -0700 (MST) Message-Id: <20090102.115426.-1540393465.imp@bsdimp.com> To: current@freebsd.org From: "M. Warner Losh" 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: Subject: New warning, what does it mean? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2009 18:56:11 -0000 I'm getting the following from my main disk on boot now: GEOM: ad0s2: geometry does not match label (255h,63s != 16h,63s). What does it mean? This system is a dual-boot FreeBSD/Windows laptop. In the past I've seen sysinstall barf on the former geometry, and have had problems installing dual-boot core4/FreeBSD systems because of it. In addition, the above error message is useless. Who is complaining? Why are they complaining? What is the corrective action to be taken here? Why does it matter with modern disks and BIOSes anyway? Warner From owner-freebsd-current@FreeBSD.ORG Fri Jan 2 18:59:43 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2666A106566C; Fri, 2 Jan 2009 18:59:43 +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 B83008FC1B; Fri, 2 Jan 2009 18:59:42 +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 n02Ivnwv059212; Fri, 2 Jan 2009 11:57:49 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 02 Jan 2009 11:57:59 -0700 (MST) Message-Id: <20090102.115759.-1625878361.imp@bsdimp.com> To: obrien@freebsd.org From: "M. Warner Losh" In-Reply-To: <20081229181044.GA78575@dragon.NUXI.org> References: <20081229110956.GA71972@dragon.NUXI.org> <20081229111944.GB20239@elvis.mu.org> <20081229181044.GA78575@dragon.NUXI.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: alfred@freebsd.org, hselasky@c2i.net, freebsd-current@freebsd.org Subject: Re: HEADSUP usb2 (usb4bsd) to become default in 2 weeks. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2009 18:59:43 -0000 In message: <20081229181044.GA78575@dragon.NUXI.org> "David O'Brien" writes: : On Mon, Dec 29, 2008 at 03:19:44AM -0800, Alfred Perlstein wrote: : > * David O'Brien [081229 03:10] wrote: : > > [ Note: replies directed to list ] : > > : > > On Fri, Dec 26, 2008 at 05:23:58PM +0100, Hans Petter Selasky wrote: : > > > There are some debugging sysctls which you can try to tune/increase: : > > > : > > > hw.usb2.pr_recovery_delay: 250 : > > > hw.usb2.ss_delay: 0 : > > > hw.usb2.ehci.no_hs: 0 // this value is a boolean : > > : > > Please. Can we quickly rename this before it gets too ingrained? : > > : > > "usb2" just implies too much the "USB 2.0 specification of April 2000" : > > vs. the 2nd USB implementation within FreeBSD. : > > : > > To stop confusion between USB 2.0 spec and this work, can it be renamed : > > to "hpsusb", "usbhps", "usb4bsd", or even the dreaded over-used "usbNG"? : > : > David, in about two weeks we're going to make "usb2" or "hpsusb" ( :) ) : > the default, if things go well we're planning on cleaning it up : > and making it just "usb" within a few weeks after that. I'm very nervous about this. I have several disk enclosure boxes that flat out don't work on usb2 that work flawlessly on the current usb stack. I've not had time to totally characterize things. Also, the rate of patches into perforce seems high and good. However, they aren't making it into svn quickly. I'd rather see them in the tree and tested well in advance of making usb2 just usb. : > Let's not do this now though as we'll just wind up having to : > do it twice. Rest assured we will get to it shortly. : : Thanks Alfred. : Of course I knew it was about to become the default, but wasn't clear as : to what it would look like as the default. : : Like others, I tried to move to a machine to "hpsusb" and didn't find it : so turn-key. I've found that some things work a lot better, while others are a regression. When your object is to burn DVDs, it can be too large a detour to catalog all the problems that I've hit. I should start doing that, however, since it is clear things are moving ahead at breakneck speeds :( Warner From owner-freebsd-current@FreeBSD.ORG Fri Jan 2 19:02:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BDCD1065686; Fri, 2 Jan 2009 19:02:31 +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 21DE68FC20; Fri, 2 Jan 2009 19:02:31 +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 n02J1OU8059254; Fri, 2 Jan 2009 12:01:24 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 02 Jan 2009 12:01:34 -0700 (MST) Message-Id: <20090102.120134.-928138805.imp@bsdimp.com> To: hselasky@c2i.net From: "M. Warner Losh" In-Reply-To: <200812282303.46555.hselasky@c2i.net> References: <4956B34C.2040901@freebsd.org> <20081228184045.0ea74b7d@gluon> <200812282303.46555.hselasky@c2i.net> 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: bruce@cran.org.uk, sam@freebsd.org, freebsd-current@freebsd.org Subject: Re: HEADSUP usb2 (usb4bsd) to become default in 2 weeks. [usb2 configuration] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2009 19:02:32 -0000 In message: <200812282303.46555.hselasky@c2i.net> Hans Petter Selasky writes: : On Sunday 28 December 2008, Bruce Cran wrote: : > http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/128590 : : Yes, there is a dependency between usb2_controller_xxxx and usb2_controller. : : See /sys/conf/files . : : Maybe this can be done in a better way for kernel builds. I think that you've gone too module happy in your design then... Warner From owner-freebsd-current@FreeBSD.ORG Fri Jan 2 19:26:49 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33484106564A; Fri, 2 Jan 2009 19:26:49 +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 CD5BC8FC13; Fri, 2 Jan 2009 19:26:48 +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 n02JNDXI059457; Fri, 2 Jan 2009 12:23:13 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 02 Jan 2009 12:01:34 -0700 (MST) Message-Id: <20090102.120134.-928138805.imp@bsdimp.com> To: hselasky@c2i.net From: "M. Warner Losh" In-Reply-To: <200812282303.46555.hselasky@c2i.net> References: <4956B34C.2040901@freebsd.org> <20081228184045.0ea74b7d@gluon> <200812282303.46555.hselasky@c2i.net> 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: bruce@cran.org.uk, sam@freebsd.org, freebsd-current@freebsd.org Subject: Re: HEADSUP usb2 (usb4bsd) to become default in 2 weeks. [usb2 configuration] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2009 19:26:49 -0000 In message: <200812282303.46555.hselasky@c2i.net> Hans Petter Selasky writes: : On Sunday 28 December 2008, Bruce Cran wrote: : > http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/128590 : : Yes, there is a dependency between usb2_controller_xxxx and usb2_controller. : : See /sys/conf/files . : : Maybe this can be done in a better way for kernel builds. I think that you've gone too module happy in your design then... Warner From owner-freebsd-current@FreeBSD.ORG Fri Jan 2 20:56:44 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A185106564A for ; Fri, 2 Jan 2009 20:56:44 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 915FE8FC26 for ; Fri, 2 Jan 2009 20:56:43 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 9BEA973098; Fri, 2 Jan 2009 22:01:33 +0100 (CET) Date: Fri, 2 Jan 2009 22:01:33 +0100 From: Luigi Rizzo To: "M. Warner Losh" Message-ID: <20090102210133.GA57653@onelab2.iet.unipi.it> References: <20090101183026.GA15385@onelab2.iet.unipi.it> <20090102.115022.1102529931.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090102.115022.1102529931.imp@bsdimp.com> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: RFC: new utility, kmodpatch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2009 20:56:44 -0000 On Fri, Jan 02, 2009 at 11:50:22AM -0700, M. Warner Losh wrote: > In message: <20090101183026.GA15385@onelab2.iet.unipi.it> > Luigi Rizzo writes: > : I mentioned this utility a couple of months ago, and it's now working > : so i would like to receive feedback on whether this is good to have > : as part of the system, or just keep it as a port (which is what > : i plan to do by default). > : > : In a nutshell, the kmodpatch utility can print or alter the content > : of device/quirk tables in kernel modules (I think Linux has some > : similar tool, though i don't remember the name -- or perhaps it is > : a feature of insmod ?). > : > : Full manpage is attached at the end, full sources are at > : > : http://info.iet.unipi.it/~luigi/FreeBSD/20090101-kmodpatch.tgz > : > : What is missing is some extra code to let it patch an on-disk file > : (elfdump returns the info we need, so in the worst case we just > : need to write a wrapper around elfdump). > : > : Feedback welcome. > > Again the feedback I always give here: You really need to have a > compatibility table so that all drivers work. This approach is > inherently limited to those drivers that have tables, and those > drivers that treat any match in that table as the same. Many drivers > don't fall into this category. true, this approach does not cover 100% of the cases, but I do believe that it has a very high coverage, especially with removable devices (more data below). The usage model I expect is that people will be told something like this To support the BenQ T33 phone on FreeBSD/i386 6.x or 7.x do kmodpatch -t "umass.ko umass_devdescrs 4 4 4 2" - - @0 0x4050 0x4a5 0x0101 0x4200 to support the Asus M2N-Vm DVI MCP67 ethernet on FreeBSD/i386 7.x do kmodpatch -t "if_nfe.ko nfe_devs 2 2 s" - - @0 0x10de 0x54c - and please note TX flow control does not work This solves the immediate problem of users trying to talk to new hardware, which hopefully in the next release will be fully supported. I am more than happy if future FreeBSD version incorporate a different mechanism such as the one you proposed to 'alias' the device IDs (even though the alias approach does not cover all cases either; but it has a complementary coverage area so it will be nice to have both). The problem in using the "alias" approach in the short term is that, I believe, it cannot be enabled without changing the kernel. In any case, i should repeat that my goal is 1) to provide users with a tool that does not require them to rebuild kernel/module or reinstall the OS; 2) to figure out if "kmodpatch" (or whatever we want to call it) deserves to be part of the base system or we just keep it as a port (which is perfectly fine in practice, and also a must for those who have an older OS version that they don't want to upgrade). On coverage of the kmodpatch approach: out of 29 (or 30) usb drivers: + 19 are compatible with this approach out of the box + 2 could/should be changed to replace a long 'if' statement with a table-based approach; + 3 (uhid, ulpt, ugen) match on the device class so there is no issue; + 2 (urio and ufm) only recognise a single device so it is unclear how generic they are, anyways and the remaining 3-4 are ehci, uhci and ohci drivers. I am sure things go worse for PCI and PCMCIA devices, but not by a large degree (and no, i did not do a full count because there are 160 entries in /sys/dev and this is far beyond the point i want to make). cheers luigi From owner-freebsd-current@FreeBSD.ORG Fri Jan 2 22:03:13 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82437106566C for ; Fri, 2 Jan 2009 22:03:13 +0000 (UTC) (envelope-from uwe@grohnwaldt.eu) Received: from AurraSing.lando.cc (AurraSing.lando.cc [87.106.187.149]) by mx1.freebsd.org (Postfix) with ESMTP id C66218FC14 for ; Fri, 2 Jan 2009 22:03:12 +0000 (UTC) (envelope-from uwe@grohnwaldt.eu) Received: from AurraSing.lando.cc (unknown [127.0.0.1]) by AurraSing.lando.cc (Postfix) with ESMTP id 356ED18AD927B for ; Fri, 2 Jan 2009 22:03:11 +0000 (UTC) Received: from BriaTharen.local (unknown [139.30.17.205]) by AurraSing.lando.cc (Postfix) with ESMTP for ; Fri, 2 Jan 2009 22:03:11 +0000 (UTC) Message-ID: <495E8F00.2050309@grohnwaldt.eu> Date: Fri, 02 Jan 2009 23:02:40 +0100 From: Uwe Grohnwaldt User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: panic on (hdd)load X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2009 22:03:13 -0000 hi, i try to install freebsd-current on a dedicated strato-server. i got a panic on load with dbench and bonnie++ (but even on normal workload as a tinderbox). db> bt Tracing pid 3 tid 100011 td 0xffffff00014eb390 kdb_enter() at kdb_enter+61 panic() at panic+379 bufinit() at bufinit brelse() at brelse+2237 bufdone() at bufdone+108 ffs_backgroundwritedone() at ffs_backgroundwritedone+172 bufdone() at bufdone+65 g_io_schedule_up() at g_io_schedule_up+241 g_up_procbody() at g_up_procbody+111 fork_exit() at fork_exit+298 fork_trampoline() at fork_trampoline+14 --- trap 0, rip = 0, rsp = 18446744066193640768, rbp = 0 --- uname -a FreeBSD unixfreunde.lando.cc 8.0-CURRENT FreeBSD 8.0-CURRENT #1: Fri Jan 2 17:49:11 UTC 2009 root@unixfreunde.lando.cc:/usr/obj/usr/src/sys/GENERIC amd64 unixfreunde# pciconf -lv |less none0@pci0:0:0:0: class=0x050000 card=0x10c51734 chip=0x02f010de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Host Bridge' class = memory subclass = RAM none1@pci0:0:0:1: class=0x050000 card=0x10c51734 chip=0x02fa10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Memory Controller 0' class = memory subclass = RAM none2@pci0:0:0:2: class=0x050000 card=0x10c51734 chip=0x02fe10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Memory Controller 1' class = memory subclass = RAM none3@pci0:0:0:3: class=0x050000 card=0x10c51734 chip=0x02f810de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Memory Controller 5' class = memory none3@pci0:0:0:3: class=0x050000 card=0x10c51734 chip=0x02f810de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Memory Controller 5' class = memory subclass = RAM none4@pci0:0:0:4: class=0x050000 card=0x10c51734 chip=0x02f910de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Memory Controller 4' class = memory subclass = RAM none5@pci0:0:0:5: class=0x050000 card=0x10c51734 chip=0x02ff10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Host Bridge' class = memory subclass = RAM none6@pci0:0:0:6: class=0x050000 card=0x10c51734 chip=0x027f10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Memory Controller 3' class = memory subclass = RAM none7@pci0:0:0:7: class=0x050000 card=0x10c51734 chip=0x027e10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Memory Controller 2' class = memory subclass = RAM none7@pci0:0:0:7: class=0x050000 card=0x10c51734 chip=0x027e10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'C51 Memory Controller 2' class = memory subclass = RAM pcib1@pci0:0:2:0: class=0x060400 card=0x000010de chip=0x02fc10de rev=0xa1 hdr=0x01 vendor = 'Nvidia Corp' device = 'C51 PCIe Bridge' class = bridge subclass = PCI-PCI pcib2@pci0:0:3:0: class=0x060400 card=0x000010de chip=0x02fd10de rev=0xa1 hdr=0x01 vendor = 'Nvidia Corp' device = 'C51 PCIe Bridge' class = bridge subclass = PCI-PCI vgapci0@pci0:0:5:0: class=0x030000 card=0x10c51734 chip=0x024110de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'NVS 210S nVidia GForce 6150, build in DELL Optiplex 740 (AMD Processor)' class = display subclass = VGA none8@pci0:0:9:0: class=0x050000 card=0x10c61734 chip=0x027010de rev=0xa2 hdr=0x00 device = 'NVS 210S nVidia GForce 6150, build in DELL Optiplex 740 (AMD Processor)' class = display subclass = VGA none8@pci0:0:9:0: class=0x050000 card=0x10c61734 chip=0x027010de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP51 Host Bridge' class = memory subclass = RAM isab0@pci0:0:10:0: class=0x060100 card=0x10c61734 chip=0x026010de rev=0xa3 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP51 LPC Bridge' class = bridge subclass = PCI-ISA none9@pci0:0:10:1: class=0x0c0500 card=0x10c61734 chip=0x026410de rev=0xa3 hdr=0x00 vendor = 'Nvidia Corp' device = 'NVIDIA SMB Bus Controller NVIDIA nForce PCI System Management' class = serial bus subclass = SMBus ohci0@pci0:0:11:0: class=0x0c0310 card=0x10c61734 chip=0x026d10de rev=0xa3 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP51 USB Controller' class = serial bus subclass = USB ehci0@pci0:0:11:1: class=0x0c0320 card=0x10c61734 chip=0x026e10de rev=0xa3 : device = 'MCP51 USB Controller' class = serial bus subclass = USB hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP51 USB Controller' class = serial bus subclass = USB atapci0@pci0:0:13:0: class=0x01018a card=0x10c61734 chip=0x026510de rev=0xf1 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP51 Parallel ATA Controller' class = mass storage subclass = ATA atapci1@pci0:0:14:0: class=0x010185 card=0x10c61734 chip=0x026610de rev=0xf1 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP51 Serial ATA Controller' class = mass storage subclass = ATA atapci2@pci0:0:15:0: class=0x010185 card=0x10c61734 chip=0x026710de rev=0xf1 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP51 Serial ATA Controller' class = mass storage subclass = ATA atapci2@pci0:0:15:0: class=0x010185 card=0x10c61734 chip=0x026710de rev=0xf1 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP51 Serial ATA Controller' class = mass storage subclass = ATA pcib3@pci0:0:16:0: class=0x060401 card=0xcb8410de chip=0x026f10de rev=0xa2 hdr=0x01 vendor = 'Nvidia Corp' device = 'MCP51 PCI Bridge' class = bridge subclass = PCI-PCI hostb0@pci0:0:24:0: class=0x060000 card=0x00000000 chip=0x11001022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(K8) Athlon 64/Opteron HyperTransport Technology Configuration' class = bridge subclass = HOST-PCI hostb1@pci0:0:24:1: class=0x060000 card=0x00000000 chip=0x11011022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(K8) Athlon 64/Opteron Address Map' class = bridge subclass = HOST-PCI hostb2@pci0:0:24:2: class=0x060000 card=0x00000000 chip=0x11021022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(K8) Athlon 64/Opteron DRAM Controller' class = bridge subclass = HOST-PCI hostb3@pci0:0:24:3: class=0x060000 card=0x00000000 chip=0x11031022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(K8) Athlon 64/Opteron Miscellaneous Control' class = bridge subclass = HOST-PCI em0@pci0:4:7:0: class=0x020000 card=0x13768086 chip=0x107c8086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/1000 GT' class = network subclass = ethernet unixfreunde# 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 8.0-CURRENT #1: Fri Jan 2 17:49:11 UTC 2009 root@unixfreunde.lando.cc:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80efb000. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2210068590 Hz CPU: Dual-Core AMD Opteron(tm) Processor 1214 HE (2210.07-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x40f33 Stepping = 3 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x1f Cores per package: 2 L1 2MB data TLB: 8 entries, fully associative L1 2MB instruction TLB: 8 entries, fully associative L1 4KB data TLB: 32 entries, fully associative L1 4KB instruction TLB: 32 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 2MB unified TLB: 0 entries, disabled/not present L2 4KB data TLB: 512 entries, 4-way associative L2 4KB instruction TLB: 512 entries, 4-way associative L2 unified cache: 1024 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative usable memory = 4261937152 (4064 MB) Physical memory chunk(s): 0x0000000000001000 - 0x0000000000099fff, 626688 bytes (153 pages) 0x0000000000f29000 - 0x00000000d7097fff, 3591827456 bytes (876911 pages) 0x0000000100000000 - 0x000000011ffeffff, 536805376 bytes (131056 pages) avail memory = 4106321920 (3916 MB) ACPI APIC Table: INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 ULE: setup cpu 0 ULE: setup cpu 1 ACPI: RSDP @ 0x0xf7810/0x0014 (v 0 PTLTD ) ACPI: RSDT @ 0x0xdef12a72/0x0038 (v 1 PTLTD RSDT 0x00060000 LTP 0x00000000) APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 ULE: setup cpu 0 ULE: setup cpu 1 ACPI: RSDP @ 0x0xf7810/0x0014 (v 0 PTLTD ) ACPI: RSDT @ 0x0xdef12a72/0x0038 (v 1 PTLTD RSDT 0x00060000 LTP 0x00000000) ACPI: FACP @ 0x0xdef15cce/0x0074 (v 1 FSC 0x00060000 0x000F4240) ACPI: DSDT @ 0x0xdef12aaa/0x3224 (v 1 FSC D246x 0x00060000 MSFT 0x03000001) ACPI: FACS @ 0x0xdef16fc0/0x0040 ACPI: SSDT @ 0x0xdef15d42/0x0206 (v 1 PTLTD POWERNOW 0x00060000 LTP 0x00000001) ACPI: APIC @ 0x0xdef15f48/0x0054 (v 1 PTLTD APIC 0x00060000 LTP 0x00000000) ACPI: MCFG @ 0x0xdef15f9c/0x003C (v 1 PTLTD MCFG 0x00060000 LTP 0x00000000) ACPI: BOOT @ 0x0xdef15fd8/0x0028 (v 1 PTLTD $SBFTBL$ 0x00060000 LTP 0x00000001) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high MADT: Forcing active-low polarity and level trigger for SCI ioapic0: intpin 9 polarity: low ioapic0: intpin 9 trigger: level ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 ath_rate: version 1.9 wlan: <802.11 Link Layer> random: nfslock: pseudo-device kbd: new array size 4 kbd1 at kbdmux0 mem: io: null: hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 (Jan 2 2009 17:47:36) acpi0: on motherboard PCIe: Memory Mapped configuration base @ 0xfc000000 ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: Power Button (fixed) AcpiOsDerivePciId: \\_SB_.PCI0.LPC_.PIRQ -> bus 0 dev 10 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.LPC_.HPET.MMTB -> bus 0 dev 0 func 0 ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 5 7 10 11 14 15 Validation 0 10 N 0 5 7 10 11 14 15 After Disable 0 255 N 0 5 7 10 11 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 5 7 10 11 14 15 Validation 0 255 N 0 5 7 10 11 14 15 After Disable 0 255 N 0 5 7 10 11 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 5 7 10 11 14 15 Validation 0 255 N 0 5 7 10 11 14 15 After Disable 0 255 N 0 5 7 10 11 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 5 7 10 11 14 15 Validation 0 255 N 0 5 7 10 11 14 15 After Disable 0 255 N 0 5 7 10 11 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link8: Index IRQ Rtd Ref IRQs Initial Probe 0 7 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link9: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link10: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link11: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link12: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link13: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link14: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 pci_link15: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 16 17 18 19 20 21 22 23 Validation 0 255 N 0 16 17 18 19 20 21 22 23 After Disable 0 255 N 0 16 17 18 19 20 21 22 23 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x10de, dev=0x02f0, revid=0xa2 domain=0, bus=0, slot=0, func=0 class=05-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x02fa, revid=0xa2 domain=0, bus=0, slot=0, func=1 class=05-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0100, statreg=0x4020, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x02fe, revid=0xa2 domain=0, bus=0, slot=0, func=2 class=05-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0020, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x02f8, revid=0xa2 domain=0, bus=0, slot=0, func=3 class=05-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x00a0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x02f9, revid=0xa2 domain=0, bus=0, slot=0, func=4 class=05-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x00a0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x02ff, revid=0xa2 domain=0, bus=0, slot=0, func=5 class=05-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x027f, revid=0xa2 domain=0, bus=0, slot=0, func=6 class=05-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0100, statreg=0x0020, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x027e, revid=0xa2 domain=0, bus=0, slot=0, func=7 class=05-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0020, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x02fc, revid=0xa1 domain=0, bus=0, slot=2, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 2 messages, 64 bit found-> vendor=0x10de, dev=0x02fd, revid=0xa1 domain=0, bus=0, slot=3, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 2 messages, 64 bit found-> vendor=0x10de, dev=0x0241, revid=0xa2 domain=0, bus=0, slot=5, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xf1000000, size 24, enabled map[14]: type Prefetchable Memory, range 64, base 0xe0000000, size 28, enabled map[1c]: type Memory, range 64, base 0xf0000000, size 24, enabled pcib0: matched entry for 0.5.INTA (src \\_SB_.PCI0.LPC_.LNKG:0) pci_link6: Picked IRQ 16 with weight 0 ioapic0: Changing polarity for pin 16 to high pcib0: slot 5 INTA routed to irq 16 via \\_SB_.PCI0.LPC_.LNKG found-> vendor=0x10de, dev=0x0270, revid=0xa2 domain=0, bus=0, slot=9, func=0 class=05-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x0260, revid=0xa3 domain=0, bus=0, slot=10, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x00a0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type I/O Port, range 32, base 0x8800, size 7, enabled found-> vendor=0x10de, dev=0x0264, revid=0xa3 domain=0, bus=0, slot=10, func=1 class=0c-05-00, hdrtype=0x00, mfdev=1 cmdreg=0x0001, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[20]: type I/O Port, range 32, base 0x88c0, size 6, enabled map[24]: type I/O Port, range 32, base 0x8880, size 6, enabled pcib0: matched entry for 0.10.INTA (src \\_SB_.PCI0.LPC_.LNKK:0) pci_link10: Picked IRQ 17 with weight 0 ioapic0: Changing polarity for pin 17 to high pcib0: slot 10 INTA routed to irq 17 via \\_SB_.PCI0.LPC_.LNKK found-> vendor=0x10de, dev=0x026d, revid=0xa3 domain=0, bus=0, slot=11, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xf2300000, size 12, enabled pcib0: matched entry for 0.11.INTA (src \\_SB_.PCI0.LPC_.LNKJ:0) pci_link9: Picked IRQ 18 with weight 0 ioapic0: Changing polarity for pin 18 to high pcib0: slot 11 INTA routed to irq 18 via \\_SB_.PCI0.LPC_.LNKJ found-> vendor=0x10de, dev=0x026e, revid=0xa3 domain=0, bus=0, slot=11, func=1 class=0c-03-20, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=b, irq=7 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xf2303000, size 8, enabled pcib0: matched entry for 0.11.INTB (src \\_SB_.PCI0.LPC_.LNKI:0) pci_link8: Picked IRQ 19 with weight 0 ioapic0: Changing polarity for pin 19 to high pcib0: slot 11 INTB routed to irq 19 via \\_SB_.PCI0.LPC_.LNKI found-> vendor=0x10de, dev=0x0265, revid=0xf1 domain=0, bus=0, slot=13, func=0 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) powerspec 2 supports D0 D3 current D0 map[20]: type I/O Port, range 32, base 0x8c00, size 4, enabled found-> vendor=0x10de, dev=0x0266, revid=0xf1 domain=0, bus=0, slot=14, func=0 class=01-01-85, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 4 messages, 64 bit map[10]: type I/O Port, range 32, base 0x8c40, size 3, enabled map[14]: type I/O Port, range 32, base 0x8c34, size 2, enabled map[14]: type I/O Port, range 32, base 0x8c34, size 2, enabled map[18]: type I/O Port, range 32, base 0x8c38, size 3, enabled map[1c]: type I/O Port, range 32, base 0x8c30, size 2, enabled map[20]: type I/O Port, range 32, base 0x8c10, size 4, enabled map[24]: type Memory, range 32, base 0xf2301000, size 12, memory disabled pcib0: matched entry for 0.14.INTA (src \\_SB_.PCI0.LPC_.LNKN:0) pci_link13: Picked IRQ 20 with weight 0 ioapic0: Changing polarity for pin 20 to high pcib0: slot 14 INTA routed to irq 20 via \\_SB_.PCI0.LPC_.LNKN found-> vendor=0x10de, dev=0x0267, revid=0xf1 domain=0, bus=0, slot=15, func=0 class=01-01-85, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 4 messages, 64 bit map[10]: type I/O Port, range 32, base 0x8c58, size 3, enabled map[14]: type I/O Port, range 32, base 0x8c4c, size 2, enabled map[18]: type I/O Port, range 32, base 0x8c50, size 3, enabled map[1c]: type I/O Port, range 32, base 0x8c48, size 2, enabled map[20]: type I/O Port, range 32, base 0x8c20, size 4, enabled map[24]: type Memory, range 32, base 0xf2302000, size 12, enabled pcib0: matched entry for 0.15.INTA (src \\_SB_.PCI0.LPC_.LNKO:0) pci_link14: Picked IRQ 21 with weight 0 ioapic0: Changing polarity for pin 21 to high pcib0: slot 15 INTA routed to irq 21 via \\_SB_.PCI0.LPC_.LNKO found-> vendor=0x10de, dev=0x026f, revid=0xa2 domain=0, bus=0, slot=16, func=0 class=06-04-01, hdrtype=0x01, mfdev=1 cmdreg=0x0107, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x02 (500 ns) found-> vendor=0x1022, dev=0x1100, revid=0x00 domain=0, bus=0, slot=24, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1101, revid=0x00 domain=0, bus=0, slot=24, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1102, revid=0x00 domain=0, bus=0, slot=24, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1103, revid=0x00 domain=0, bus=0, slot=24, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) pci0: at device 0.0 (no driver attached) pci0: at device 0.1 (no driver attached) pci0: at device 0.2 (no driver attached) pci0: at device 0.3 (no driver attached) pci0: at device 0.4 (no driver attached) pci0: at device 0.5 (no driver attached) pci0: at device 0.6 (no driver attached) pci0: at device 0.7 (no driver attached) pcib1: at device 2.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xf000-0xfff pcib1: no prefetched decode pci1: on pcib1 pci1: domain=0, physical bus=1 pcib2: at device 3.0 on pci0 pci1: domain=0, physical bus=1 pcib2: at device 3.0 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xf000-0xfff pcib2: no prefetched decode pci2: on pcib2 pci2: domain=0, physical bus=2 vgapci0: mem 0xf1000000-0xf1ffffff,0xe0000000-0xefffffff,0xf0000000-0xf0ffffff irq 16 at device 5.0 on pci0 pci0: at device 9.0 (no driver attached) isab0: port 0x8800-0x887f at device 10.0 on pci0 isa0: on isab0 pci0: at device 10.1 (no driver attached) ohci0: mem 0xf2300000-0xf2300fff irq 18 at device 11.0 on pci0 ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xf2300000 ioapic0: routing intpin 18 (PCI IRQ 18) to vector 49 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 8 ports with 8 removable, self powered ehci0: mem 0xf2303000-0xf23030ff irq 19 at device 11.1 on pci0 ehci0: Reserved 0x100 bytes for rid 0x10 type 3 at 0xf2303000 ioapic0: routing intpin 19 (PCI IRQ 19) to vector 50 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb1: EHCI version 1.0 usb1: companion controller, 8 ports each: usb0 usb1: on ehci0 usb1: USB revision 2.0 uhub1: on usb1 uhub1: 8 ports with 8 removable, self powered atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x8c00-0x8c0f at device 13.0 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x8c00 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=60 ostat1=70 ata0: stat0=0x20 err=0x20 lsb=0x20 msb=0x20 ata0: stat1=0x30 err=0x30 lsb=0x30 msb=0x30 ata0: reset tp2 stat0=20 stat1=30 devices=0x0 ata0: stat1=0x30 err=0x30 lsb=0x30 msb=0x30 ata0: reset tp2 stat0=20 stat1=30 devices=0x0 ioapic0: routing intpin 14 (ISA IRQ 14) to vector 51 ata0: [MPSAFE] ata0: [ITHREAD] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=00 ostat0=ff ostat1=ff ioapic0: routing intpin 15 (ISA IRQ 15) to vector 52 ata1: [MPSAFE] ata1: [ITHREAD] atapci1: port 0x8c40-0x8c47,0x8c34-0x8c37,0x8c38-0x8c3f,0x8c30-0x8c33,0x8c10-0x8c1f mem 0xf2301000-0xf2301fff irq 20 at device 14.0 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0x8c10 ioapic0: routing intpin 20 (PCI IRQ 20) to vector 53 atapci1: [MPSAFE] atapci1: [ITHREAD] atapci1: Reserved 0x1000 bytes for rid 0x24 type 3 at 0xf2301000 ata2: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x8c40 atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0x8c34 ata2: SATA connect time=0ms ata2: reset tp1 mask=01 ostat0=50 ostat1=00 ata2: SATA connect time=0ms ata2: reset tp1 mask=01 ostat0=50 ostat1=00 ata2: stat0=0xd0 err=0x00 lsb=0xe0 msb=0x33 ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata2: reset tp2 stat0=50 stat1=00 devices=0x1 ata2: [MPSAFE] ata2: [ITHREAD] ata3: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0x8c38 atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0x8c30 ata3: SATA connect time=0ms ata3: reset tp1 mask=01 ostat0=50 ostat1=00 ata3: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata3: reset tp2 stat0=50 stat1=00 devices=0x1 ata3: [MPSAFE] ata3: [ITHREAD] atapci2: port 0x8c58-0x8c5f,0x8c4c-0x8c4f,0x8c50-0x8c57,0x8c48-0x8c4b,0x8c20-0x8c2f mem 0xf2302000-0xf2302fff irq 21 at device 15.0 on pci0 atapci2: Reserved 0x10 bytes for rid 0x20 type 4 at 0x8c20 ioapic0: routing intpin 21 (PCI IRQ 21) to vector 54 atapci2: [MPSAFE] atapci2: [ITHREAD] atapci2: Reserved 0x1000 bytes for rid 0x24 type 3 at 0xf2302000 ata4: on atapci2 atapci2: Reserved 0x8 bytes for rid 0x10 type 4 at 0x8c58 atapci2: Reserved 0x4 bytes for rid 0x14 type 4 at 0x8c4c ata4: SATA connect status=00000000 ata4: [MPSAFE] ata4: [ITHREAD] ata5: on atapci2 atapci2: Reserved 0x8 bytes for rid 0x18 type 4 at 0x8c50 atapci2: Reserved 0x4 bytes for rid 0x1c type 4 at 0x8c48 ata5: SATA connect status=00000000 ata5: [MPSAFE] ata5: [ITHREAD] pcib3: at device 16.0 on pci0 pcib3: domain 0 pcib3: secondary bus 4 pcib3: subordinate bus 4 pcib3: I/O decode 0x9000-0x9fff pcib3: memory decode 0xf2000000-0xf20fffff pcib3: no prefetched decode pcib3: Subtractively decoded bridge. ACPI: Found matching pin for 4.7.INTA at func 0: 10 pci4: on pcib3 pci4: domain=0, physical bus=4 found-> vendor=0x8086, dev=0x107c, revid=0x05 domain=0, bus=4, slot=7, func=0 domain=0, bus=4, slot=7, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0230, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0xff (63750 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xf2020000, size 17, enabled pcib3: requested memory range 0xf2020000-0xf203ffff: good map[14]: type Memory, range 32, base 0xf2000000, size 17, enabled pcib3: requested memory range 0xf2000000-0xf201ffff: good map[18]: type I/O Port, range 32, base 0x9000, size 6, enabled pcib3: requested I/O range 0x9000-0x903f: in range pcib3: matched entry for 4.7.INTA (src \\_SB_.PCI0.LPC_.LNKA:0) ioapic0: Changing trigger for pin 10 to level pcib3: slot 7 INTA routed to irq 10 via \\_SB_.PCI0.LPC_.LNKA em0: port 0x9000-0x903f mem 0xf2020000-0xf203ffff,0xf2000000-0xf201ffff irq 10 at device 7.0 on pci4 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xf2020000 em0: Reserved 0x40 bytes for rid 0x18 type 4 at 0x9000 ioapic0: routing intpin 10 (ISA IRQ 10) to vector 55 em0: [FILTER] em0: bpf attached em0: Ethernet address: 00:1b:21:27:9d:13 atrtc0: port 0x70-0x71 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us) acpi_hpet0: iomem 0x1e0e000-0x1e0efff on acpi0 device_attach: acpi_hpet0 attach returned 12 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 kbd0: atkbd0, generic (0), config:0x0, flags:0x1f0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 56 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ atkbdc: atkbdc-1 already exists; skipping it psmcpnp0: port 0x60,0x64 irq 12 on acpi0 psm0: current command byte:0067 psm0: failed to reset the aux device. uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 ioapic0: routing intpin 4 (ISA IRQ 4) to vector 57 uart0: [FILTER] uart0: fast interrupt uart0: console (57600,n,8,1) cpu0: on acpi0 cpu0: switching to generic Cx mode powernow0: on cpu0 cpu1: on acpi0 powernow1: on cpu1 acpi_hpet0: iomem 0x1e0e000-0x1e0efff on acpi0 device_attach: acpi_hpet0 attach returned 12 ahc_isa_probe 8: ioport 0x8c00 alloc failed ex_isa_identify() isa_probe_children: disabling PnP devices atkbdc: atkbdc0 already exists; skipping it sc: sc0 already exists; skipping it uart: uart0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xcf000-0xcffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 ppc0: cannot reserve I/O port range ppc0: failed to probe at irq 7 on isa0 uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 uart2: not probed (disabled) uart3: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. Reducing kern.maxvnodes 258194 -> 100000 procfs registered lapic: Divisor 2, Frequency 100457663 hz Timecounter "TSC" frequency 2210068590 Hz quality -100 Timecounters tick every 1.000 msec lo0: bpf attached hptrr: no controller detected. ata0: identify ch->devices=00000000 ata1: identify ch->devices=00000000 ata2: identify ch->devices=00000001 ata2-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad4: 476940MB at ata2-master SATA300 ad4: 976773168 sectors [969021C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad4 ad4: nVidia check1 failed ad4: Adaptec check1 failed ad4: LSI (v3) check1 failed ad4: LSI (v2) check1 failed ad4: FreeBSD check1 failed ata3: identify ch->devices=00000001 ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad6: 476940MB at ata3-master SATA300 ad6: 976773168 sectors [969021C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad6 ad6: nVidia check1 failed ad6: Adaptec check1 failed ad6: LSI (v3) check1 failed ad6: LSI (v2) check1 failed ad6: FreeBSD check1 failed ata4: identify ch->devices=00000000 ata5: identify ch->devices=00000000 ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 ioapic0: Assigning ISA IRQ 1 to local APIC 0 ioapic0: Assigning ISA IRQ 4 to local APIC 1 ioapic0: Assigning ISA IRQ 9 to local APIC 0 ioapic0: Assigning ISA IRQ 10 to local APIC 1 ioapic0: Assigning ISA IRQ 14 to local APIC 0 ioapic0: Assigning ISA IRQ 15 to local APIC 1 ioapic0: Assigning PCI IRQ 18 to local APIC 0 ioapic0: Assigning PCI IRQ 19 to local APIC 1 ioapic0: Assigning PCI IRQ 20 to local APIC 0 ioapic0: Assigning PCI IRQ 21 to local APIC 1 WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/ad4s1a WARNING: / was not properly dismounted ct_to_ts([2009-01-02 21:45:01]) = 1230932701.000000000 start_init: trying /sbin/init lock order reversal: 1st 0xffffff00014ef070 user map (user map) @ /usr/src/sys/vm/vm_map.c:3198 2nd 0xffffff00047d5270 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2079 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e __lockmgr_args() at __lockmgr_args+0xca8 ffs_lock() at ffs_lock+0x8c VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x47 vget() at vget+0x8b vnode_pager_lock() at vnode_pager_lock+0x1d0 vm_fault() at vm_fault+0x1e2 trap_pfault() at trap_pfault+0x128 trap() at trap+0x51c calltrap() at calltrap+0x8 --- trap 0xc, rip = 0x40014f, rsp = 0x7fffffffee70, rbp = 0x7fffffffee90 --- em0: Link is up 100 Mbps Full Duplex em0: link state changed to UP thanks for any help. chers, uwe From owner-freebsd-current@FreeBSD.ORG Fri Jan 2 22:09:52 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E855106564A for ; Fri, 2 Jan 2009 22:09:52 +0000 (UTC) (envelope-from uwe@grohnwaldt.eu) Received: from AurraSing.lando.cc (AurraSing.lando.cc [87.106.187.149]) by mx1.freebsd.org (Postfix) with ESMTP id F3E0F8FC08 for ; Fri, 2 Jan 2009 22:09:51 +0000 (UTC) (envelope-from uwe@grohnwaldt.eu) Received: from AurraSing.lando.cc (unknown [127.0.0.1]) by AurraSing.lando.cc (Postfix) with ESMTP id 9078C18AD927B for ; Fri, 2 Jan 2009 22:09:51 +0000 (UTC) Received: from BriaTharen.local (unknown [139.30.17.205]) by AurraSing.lando.cc (Postfix) with ESMTP for ; Fri, 2 Jan 2009 22:09:51 +0000 (UTC) Message-ID: <495E90A8.2020000@grohnwaldt.eu> Date: Fri, 02 Jan 2009 23:09:44 +0100 From: Uwe Grohnwaldt User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: current@freebsd.org References: <495E8F00.2050309@grohnwaldt.eu> In-Reply-To: <495E8F00.2050309@grohnwaldt.eu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: panic on (hdd)load X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2009 22:09:52 -0000 Uwe Grohnwaldt wrote: > hi, > > i try to install freebsd-current on a dedicated strato-server. i got a > panic on load with dbench and bonnie++ (but even on normal workload as > a tinderbox). > > db> bt > Tracing pid 3 tid 100011 td 0xffffff00014eb390 > kdb_enter() at kdb_enter+61 > panic() at panic+379 > bufinit() at bufinit > brelse() at brelse+2237 > bufdone() at bufdone+108 > ffs_backgroundwritedone() at ffs_backgroundwritedone+172 > bufdone() at bufdone+65 > g_io_schedule_up() at g_io_schedule_up+241 > g_up_procbody() at g_up_procbody+111 > fork_exit() at fork_exit+298 > fork_trampoline() at fork_trampoline+14 > --- trap 0, rip = 0, rsp = 18446744066193640768, rbp = 0 --- > > uname -a > FreeBSD unixfreunde.lando.cc 8.0-CURRENT FreeBSD 8.0-CURRENT #1: Fri > Jan 2 17:49:11 UTC 2009 > root@unixfreunde.lando.cc:/usr/obj/usr/src/sys/GENERIC amd64 i've forgotten to mention that this panic doesn't happen on fbsd71 or linux (was pre-installed on this box). From owner-freebsd-current@FreeBSD.ORG Fri Jan 2 22:12:28 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 758BB10656DF for ; Fri, 2 Jan 2009 22:12:28 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 325BA8FC1F for ; Fri, 2 Jan 2009 22:12:28 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id CA5E77309E; Fri, 2 Jan 2009 23:17:19 +0100 (CET) Date: Fri, 2 Jan 2009 23:17:19 +0100 From: Luigi Rizzo To: Ben Kaduk Message-ID: <20090102221719.GA61058@onelab2.iet.unipi.it> References: <20090101183026.GA15385@onelab2.iet.unipi.it> <6101e8c40901011117y3e82a226id6f9de940b0f7dcd@mail.gmail.com> <47d0403c0901011619r658fd25ct3d01bc32969bde11@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47d0403c0901011619r658fd25ct3d01bc32969bde11@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org, Oliver Pinter Subject: Re: RFC: new utility, kmodpatch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2009 22:12:29 -0000 On Thu, Jan 01, 2009 at 07:19:12PM -0500, Ben Kaduk wrote: > On Thu, Jan 1, 2009 at 2:17 PM, Oliver Pinter wrote: > > Hi! > > > > Do You think for this project: http://www.ksplice.com/ ? > > > > On 1/1/09, Luigi Rizzo wrote: > >> I mentioned this utility a couple of months ago, and it's now working > >> so i would like to receive feedback on whether this is good to have > >> as part of the system, or just keep it as a port (which is what > >> i plan to do by default). > >> > >> In a nutshell, the kmodpatch utility can print or alter the content > >> of device/quirk tables in kernel modules (I think Linux has some > >> similar tool, though i don't remember the name -- or perhaps it is > >> a feature of insmod ?). > >> > > > Ksplice is not yet in the linux kernel tree, so it's probably not > what Luigi was referring to. However, it is a pretty impressive correct, i think there is some feature (in insmod or whatever the utility to load a module is) to configure the module so it uses certain variables (perhaps including recognising a given USB vendor-id pair?) cheers luigi From owner-freebsd-current@FreeBSD.ORG Fri Jan 2 22:15:07 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6BD01065670; Fri, 2 Jan 2009 22:15:07 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id C34758FC1A; Fri, 2 Jan 2009 22:15:07 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n02MF6v1004651; Fri, 2 Jan 2009 14:15:07 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Jan 2009 14:15:44 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SCTP related issue with recent ARP changes? Thread-Index: AclsMle5U2WQGWG/SKSzlWZ3/NiGZQAG4G76ADYDKbA= References: From: "Li, Qing" To: =?iso-8859-1?Q?Michael_T=FCxen?= Cc: qingli@freebsd.org, current@freebsd.org, FreeBSD Net Subject: RE: SCTP related issue with recent ARP changes? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2009 22:15:08 -0000 Hi Michael, The SCTP problem you were having was attributed to the arp-v2 changes. The reason TCP and UDP works well is because the TCP and UDP modules does not supply a route entry when calling ip_output(). Consequently in ip_output() the destination (sockaddr) was reinitialized = and the sin_port field is 0. The destination sockaddr supplied in the route entry from the SCTP module has the actual port value in it. The new L2 search was (initially) written as a generic function. So the L3 address comparison was performed using bcmp() of sockaddr_len bytes. The L2 entry was created with a sockaddr object that includes the port value, however, on ARP input the port value does not apply. The mismatch in port value causes the ARP lookup to fail and the SCTP connection never complete its negotiation. Please apply the patch for IPv4 in my home directory at http://people.freebsd.org/~qingli/in.c.diff I did the basic testing using the programs you gave me and now the client connects successful and completes the transfer. I also verified the packets in wireshark trace. Please let me know if this patch fixes your SCTP problems. Thank you for your help. -- Qing > -----Original Message----- > From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd- > current@freebsd.org] On Behalf Of Li, Qing > Sent: Thursday, January 01, 2009 12:17 PM > To: Michael T=FCxen; FreeBSD Net > Cc: qingli@freebsd.org; current@freebsd.org > Subject: RE: SCTP related issue with recent ARP changes? >=20 >=20 > Hi Michael, >=20 > Your problem could be related to the recent ARP changes. > I will investigate further to confirm. >=20 > Thanks, >=20 > -- Qing >=20 >=20 > -----Original Message----- > From: owner-freebsd-net@freebsd.org on behalf of Michael T=FCxen > Sent: Thu 1/1/2009 8:59 AM > To: FreeBSD Net > Subject: SCTP related issue with recent ARP changes? >=20 > Dear all, >=20 > I'm running the current CVS version of FreeBSD 8 in a virtual > machine using VMWare 2.0.1 on a Mac (not sure if this is relevant) > and bridged networking having an em interface on the virtual machine. > I'm using a similar setup with older FreeBSD machines and they are > running fine. >=20 > Loopback communication based on UDP, TCP, SCTP or ICMP works fine. >=20 > Communicating with other hosts using UDP, TCP or ICMP works fine. >=20 > Communicating with other hosts using SCTP does not work. > The SCTP stack calls ip_output() and an ARP request for the > correct destination IP address is send out. A corresponding > ARP reply is visible in Wireshark (running on the FreeBSD 8 box) > and looks good. However, the corresponding SCTP packet it never > sent out. I'm not sure, but this might be related to the > recent ARP changes. Is there anything required from the > transport layer to be done when calling ip_output() that > was not required before? >=20 > Best regards > Michael >=20 From owner-freebsd-current@FreeBSD.ORG Fri Jan 2 22:59:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03A00106564A for ; Fri, 2 Jan 2009 22:59:22 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from hercules.mthelicon.com (hercules.mthelicon.com [IPv6:2001:49f0:2023::2]) by mx1.freebsd.org (Postfix) with ESMTP id C069B8FC17 for ; Fri, 2 Jan 2009 22:59:21 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from feathers.peganest.com (78-33-110-3.static-adsl.entanet.co.uk [78.33.110.3] (may be forged)) (authenticated bits=0) by hercules.mthelicon.com (8.14.3/8.14.3) with ESMTP id n02MxIBL048147 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Fri, 2 Jan 2009 22:59:20 GMT (envelope-from ken@mthelicon.com) From: Pegasus Mc Cleaft Organization: Feathers To: freebsd-current@freebsd.org Date: Fri, 2 Jan 2009 22:59:17 +0000 User-Agent: KMail/1.10.1 (FreeBSD/8.0-CURRENT; KDE/4.1.1; amd64; ; ) References: <4956B34C.2040901@freebsd.org> <200812282303.46555.hselasky@c2i.net> <20090102.120134.-928138805.imp@bsdimp.com> In-Reply-To: <20090102.120134.-928138805.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901022259.17193.ken@mthelicon.com> Subject: hald and USB2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2009 22:59:22 -0000 Hello everyone, I was wondering if anyone has noticed the HAL daemon running away (taking 100% of one core) while running with USB2? I have nothing unusual plugged into the USB ports (Other than a keyboard, mouse, hub) and can cause the problem by loading a kernel with USB2 enabled. While running under the original USB1 code, the runaway problem doesn't show up. I have also tried recompiling the HAL daemon while running on a USB2 enabled install, just to make sure it wasn't some structure dependent change. The machine info is: FreeBSD feathers.peganest.com 8.0-CURRENT FreeBSD 8.0-CURRENT #34: Fri Dec 26 23:27:39 UTC 2008 ken@feathers.peganest.com:/usr/obj/usr/src/sys/FEATHERS amd64 ~Peg From owner-freebsd-current@FreeBSD.ORG Fri Jan 2 23:02:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 636E1106564A for ; Fri, 2 Jan 2009 23:02:18 +0000 (UTC) (envelope-from marcus@marcuscom.com) Received: from creme-brulee.marcuscom.com (marcuscom-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::1279]) by mx1.freebsd.org (Postfix) with ESMTP id E6C338FC08 for ; Fri, 2 Jan 2009 23:02:17 +0000 (UTC) (envelope-from marcus@marcuscom.com) Received: from [IPv6:2001:470:1f00:2464::4] (shumai.marcuscom.com [IPv6:2001:470:1f00:2464::4]) by creme-brulee.marcuscom.com (8.14.3/8.14.3) with ESMTP id n02N2Yu3066183; Fri, 2 Jan 2009 18:02:36 -0500 (EST) (envelope-from marcus@marcuscom.com) From: Joe Marcus Clarke To: Pegasus Mc Cleaft In-Reply-To: <200901022259.17193.ken@mthelicon.com> References: <4956B34C.2040901@freebsd.org> <200812282303.46555.hselasky@c2i.net> <20090102.120134.-928138805.imp@bsdimp.com> <200901022259.17193.ken@mthelicon.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-YQ8miRXWEX3XTKHQpPbJ" Organization: MarcusCom, Inc. Date: Fri, 02 Jan 2009 18:02:47 -0500 Message-Id: <1230937367.87142.66.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,MIME_QP_LONG_LINE, NO_RELAYS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on creme-brulee.marcuscom.com Cc: freebsd-current@freebsd.org Subject: Re: hald and USB2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2009 23:02:18 -0000 --=-YQ8miRXWEX3XTKHQpPbJ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2009-01-02 at 22:59 +0000, Pegasus Mc Cleaft wrote: > Hello everyone,=20 >=20 > I was wondering if anyone has noticed the HAL daemon running away (takin= g=20 > 100% of one core) while running with USB2?=20 >=20 > I have nothing unusual plugged into the USB ports (Other than a keyboard= ,=20 > mouse, hub) and can cause the problem by loading a kernel with USB2 enabl= ed.=20 > While running under the original USB1 code, the runaway problem doesn't s= how=20 > up. I have also tried recompiling the HAL daemon while running on a USB2=20 > enabled install, just to make sure it wasn't some structure dependent cha= nge.=20 Consult the archives of this list for a bandaid for the CPU problem (Coleman Kane sent out a patch). Hald will still not work with usb2, though. It's on my todo list to fix, but that will not happen until after 7.1 is released. Joe --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-YQ8miRXWEX3XTKHQpPbJ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAklenRYACgkQb2iPiv4Uz4fGaQCfdBevXbqW5ZB1G140OVADpeou QY0AniiWXxmKKT0of2idj2faBhgrSC1b =tlvG -----END PGP SIGNATURE----- --=-YQ8miRXWEX3XTKHQpPbJ-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 2 23:05:51 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42400106566C for ; Fri, 2 Jan 2009 23:05:51 +0000 (UTC) (envelope-from uwe@grohnwaldt.eu) Received: from AurraSing.lando.cc (AurraSing.lando.cc [87.106.187.149]) by mx1.freebsd.org (Postfix) with ESMTP id 03C798FC16 for ; Fri, 2 Jan 2009 23:05:50 +0000 (UTC) (envelope-from uwe@grohnwaldt.eu) Received: from AurraSing.lando.cc (unknown [127.0.0.1]) by AurraSing.lando.cc (Postfix) with ESMTP id B9FFD18B0F5C3 for ; Fri, 2 Jan 2009 23:05:49 +0000 (UTC) Received: from BriaTharen.local (unknown [139.30.17.205]) by AurraSing.lando.cc (Postfix) with ESMTP for ; Fri, 2 Jan 2009 23:05:49 +0000 (UTC) Message-ID: <495E9DC8.7080009@grohnwaldt.eu> Date: Sat, 03 Jan 2009 00:05:44 +0100 From: Uwe Grohnwaldt User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: current@freebsd.org References: <495E8F00.2050309@grohnwaldt.eu> In-Reply-To: <495E8F00.2050309@grohnwaldt.eu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: panic on (hdd)load X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2009 23:05:52 -0000 hi, i have forced a panic again and the backtrace looks like this: db> bt Tracing pid 1012 tid 100204 td 0xffffff000d2ec000 kdb_enter() at kdb_enter+0x3d panic() at panic+0x17b ffs_clusteralloc() at ffs_clusteralloc+0x408 ffs_hashalloc() at ffs_hashalloc+0x67 ffs_reallocblks() at ffs_reallocblks+0x850 cluster_write() at cluster_write+0x4d3 ffs_write() at ffs_write+0x628 VOP_WRITE_APV() at VOP_WRITE_APV+0xfe vn_write() at vn_write+0x23f dofilewrite() at dofilewrite+0x85 kern_writev() at kern_writev+0x60 write() at write+0x54 syscall() at syscall+0x1bf Xfast_syscall() at Xfast_syscall+0xab --- syscall (4, FreeBSD ELF64, write), rip = 0x800c814bc, rsp = 0x7fffffffde58, rbp = 0x7fffffffe510 --- chers, uwe From owner-freebsd-current@FreeBSD.ORG Fri Jan 2 23:18:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CF1F106566B for ; Fri, 2 Jan 2009 23:18:11 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 41F0A8FC1A for ; Fri, 2 Jan 2009 23:18:11 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 16FC71A3C39; Fri, 2 Jan 2009 15:18:11 -0800 (PST) Date: Fri, 2 Jan 2009 15:18:11 -0800 From: Alfred Perlstein To: "M. Warner Losh" Message-ID: <20090102231811.GF60686@elvis.mu.org> References: <20081229110956.GA71972@dragon.NUXI.org> <20081229111944.GB20239@elvis.mu.org> <20081229181044.GA78575@dragon.NUXI.org> <20090102.115759.-1625878361.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090102.115759.-1625878361.imp@bsdimp.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org, hselasky@c2i.net Subject: Re: HEADSUP usb2 (usb4bsd) to become default in 2 weeks. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2009 23:18:11 -0000 I can understand that you're upset that you've hit a few snags, but this is the first report from you I've seen in a while, so please come up with some specifics so that we can address them. "some disk enclosures" and "dvd burning doesn't work for me", isn't a bug report that's very useful, there are published debugging steps for usb4bsd (just as there are for generic kernel errors) and it would be nice if you would look into them. At the very least, some console messages or some details. -Alfred * M. Warner Losh [090102 10:59] wrote: > In message: <20081229181044.GA78575@dragon.NUXI.org> > "David O'Brien" writes: > : On Mon, Dec 29, 2008 at 03:19:44AM -0800, Alfred Perlstein wrote: > : > * David O'Brien [081229 03:10] wrote: > : > > [ Note: replies directed to list ] > : > > > : > > On Fri, Dec 26, 2008 at 05:23:58PM +0100, Hans Petter Selasky wrote: > : > > > There are some debugging sysctls which you can try to tune/increase: > : > > > > : > > > hw.usb2.pr_recovery_delay: 250 > : > > > hw.usb2.ss_delay: 0 > : > > > hw.usb2.ehci.no_hs: 0 // this value is a boolean > : > > > : > > Please. Can we quickly rename this before it gets too ingrained? > : > > > : > > "usb2" just implies too much the "USB 2.0 specification of April 2000" > : > > vs. the 2nd USB implementation within FreeBSD. > : > > > : > > To stop confusion between USB 2.0 spec and this work, can it be renamed > : > > to "hpsusb", "usbhps", "usb4bsd", or even the dreaded over-used "usbNG"? > : > > : > David, in about two weeks we're going to make "usb2" or "hpsusb" ( :) ) > : > the default, if things go well we're planning on cleaning it up > : > and making it just "usb" within a few weeks after that. > > I'm very nervous about this. I have several disk enclosure boxes that > flat out don't work on usb2 that work flawlessly on the current usb > stack. I've not had time to totally characterize things. > > Also, the rate of patches into perforce seems high and good. However, > they aren't making it into svn quickly. I'd rather see them in the > tree and tested well in advance of making usb2 just usb. > > : > Let's not do this now though as we'll just wind up having to > : > do it twice. Rest assured we will get to it shortly. > : > : Thanks Alfred. > : Of course I knew it was about to become the default, but wasn't clear as > : to what it would look like as the default. > : > : Like others, I tried to move to a machine to "hpsusb" and didn't find it > : so turn-key. > > I've found that some things work a lot better, while others are a > regression. When your object is to burn DVDs, it can be too large a > detour to catalog all the problems that I've hit. I should start > doing that, however, since it is clear things are moving ahead at > breakneck speeds :( > > Warner -- - Alfred Perlstein From owner-freebsd-current@FreeBSD.ORG Fri Jan 2 23:29:37 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C63D0106566B; Fri, 2 Jan 2009 23:29:37 +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 753878FC08; Fri, 2 Jan 2009 23:29:37 +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 n02NRk1v062067; Fri, 2 Jan 2009 16:27:46 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 02 Jan 2009 16:27:57 -0700 (MST) Message-Id: <20090102.162757.2007158145.imp@bsdimp.com> To: alfred@freebsd.org From: "M. Warner Losh" In-Reply-To: <20090102231811.GF60686@elvis.mu.org> References: <20081229181044.GA78575@dragon.NUXI.org> <20090102.115759.-1625878361.imp@bsdimp.com> <20090102231811.GF60686@elvis.mu.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-current@freebsd.org, hselasky@c2i.net Subject: Re: HEADSUP usb2 (usb4bsd) to become default in 2 weeks. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2009 23:29:38 -0000 In message: <20090102231811.GF60686@elvis.mu.org> Alfred Perlstein writes: : I can understand that you're upset that you've hit a few snags, : but this is the first report from you I've seen in a while, so : please come up with some specifics so that we can address them. Yea, it is hard to stop to file bug reports when you're trying to get something else done... But I've filed a bug report. I have a few others that I'm waiting to find the time to recreate them. : "some disk enclosures" and "dvd burning doesn't work for me", isn't : a bug report that's very useful, there are published debugging : steps for usb4bsd (just as there are for generic kernel errors) : and it would be nice if you would look into them. : : At the very least, some console messages or some details. I've filed a bug report. hps asked for more information, but I didn't understand what he wanted, so I asked for clarification. Once he tells me more clearly what he needs, I'll get it for him. I have the setup that causes problems in place, and will until I get all the hockey videos made... Several weeks still... I expect that hps will reply in the next day or two... Warner : -Alfred : : : * M. Warner Losh [090102 10:59] wrote: : > In message: <20081229181044.GA78575@dragon.NUXI.org> : > "David O'Brien" writes: : > : On Mon, Dec 29, 2008 at 03:19:44AM -0800, Alfred Perlstein wrote: : > : > * David O'Brien [081229 03:10] wrote: : > : > > [ Note: replies directed to list ] : > : > > : > : > > On Fri, Dec 26, 2008 at 05:23:58PM +0100, Hans Petter Selasky wrote: : > : > > > There are some debugging sysctls which you can try to tune/increase: : > : > > > : > : > > > hw.usb2.pr_recovery_delay: 250 : > : > > > hw.usb2.ss_delay: 0 : > : > > > hw.usb2.ehci.no_hs: 0 // this value is a boolean : > : > > : > : > > Please. Can we quickly rename this before it gets too ingrained? : > : > > : > : > > "usb2" just implies too much the "USB 2.0 specification of April 2000" : > : > > vs. the 2nd USB implementation within FreeBSD. : > : > > : > : > > To stop confusion between USB 2.0 spec and this work, can it be renamed : > : > > to "hpsusb", "usbhps", "usb4bsd", or even the dreaded over-used "usbNG"? : > : > : > : > David, in about two weeks we're going to make "usb2" or "hpsusb" ( :) ) : > : > the default, if things go well we're planning on cleaning it up : > : > and making it just "usb" within a few weeks after that. : > : > I'm very nervous about this. I have several disk enclosure boxes that : > flat out don't work on usb2 that work flawlessly on the current usb : > stack. I've not had time to totally characterize things. : > : > Also, the rate of patches into perforce seems high and good. However, : > they aren't making it into svn quickly. I'd rather see them in the : > tree and tested well in advance of making usb2 just usb. : > : > : > Let's not do this now though as we'll just wind up having to : > : > do it twice. Rest assured we will get to it shortly. : > : : > : Thanks Alfred. : > : Of course I knew it was about to become the default, but wasn't clear as : > : to what it would look like as the default. : > : : > : Like others, I tried to move to a machine to "hpsusb" and didn't find it : > : so turn-key. : > : > I've found that some things work a lot better, while others are a : > regression. When your object is to burn DVDs, it can be too large a : > detour to catalog all the problems that I've hit. I should start : > doing that, however, since it is clear things are moving ahead at : > breakneck speeds :( : > : > Warner : : -- : - Alfred Perlstein : : From owner-freebsd-current@FreeBSD.ORG Fri Jan 2 23:36:08 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4E251065672 for ; Fri, 2 Jan 2009 23:36:07 +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 525EB8FC14 for ; Fri, 2 Jan 2009 23:36:07 +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 n02NWvmw062122; Fri, 2 Jan 2009 16:32:57 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 02 Jan 2009 16:33:08 -0700 (MST) Message-Id: <20090102.163308.-1929116900.imp@bsdimp.com> To: rizzo@iet.unipi.it From: "M. Warner Losh" In-Reply-To: <20090102210133.GA57653@onelab2.iet.unipi.it> References: <20090101183026.GA15385@onelab2.iet.unipi.it> <20090102.115022.1102529931.imp@bsdimp.com> <20090102210133.GA57653@onelab2.iet.unipi.it> 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: current@FreeBSD.org Subject: Re: RFC: new utility, kmodpatch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2009 23:36:08 -0000 In message: <20090102210133.GA57653@onelab2.iet.unipi.it> Luigi Rizzo writes: : On Fri, Jan 02, 2009 at 11:50:22AM -0700, M. Warner Losh wrote: : > In message: <20090101183026.GA15385@onelab2.iet.unipi.it> : > Luigi Rizzo writes: : > : I mentioned this utility a couple of months ago, and it's now working : > : so i would like to receive feedback on whether this is good to have : > : as part of the system, or just keep it as a port (which is what : > : i plan to do by default). : > : : > : In a nutshell, the kmodpatch utility can print or alter the content : > : of device/quirk tables in kernel modules (I think Linux has some : > : similar tool, though i don't remember the name -- or perhaps it is : > : a feature of insmod ?). : > : : > : Full manpage is attached at the end, full sources are at : > : : > : http://info.iet.unipi.it/~luigi/FreeBSD/20090101-kmodpatch.tgz : > : : > : What is missing is some extra code to let it patch an on-disk file : > : (elfdump returns the info we need, so in the worst case we just : > : need to write a wrapper around elfdump). : > : : > : Feedback welcome. : > : > Again the feedback I always give here: You really need to have a : > compatibility table so that all drivers work. This approach is : > inherently limited to those drivers that have tables, and those : > drivers that treat any match in that table as the same. Many drivers : > don't fall into this category. : : true, this approach does not cover 100% of the cases, but I do believe : that it has a very high coverage, especially with removable devices : (more data below). : : The usage model I expect is that people will be told something like this : : To support the BenQ T33 phone on FreeBSD/i386 6.x or 7.x do : kmodpatch -t "umass.ko umass_devdescrs 4 4 4 2" - - @0 0x4050 0x4a5 0x0101 0x4200 : : to support the Asus M2N-Vm DVI MCP67 ethernet on FreeBSD/i386 7.x do : kmodpatch -t "if_nfe.ko nfe_devs 2 2 s" - - @0 0x10de 0x54c - : and please note TX flow control does not work This is a good interface for our users? : This solves the immediate problem of users trying to talk to new hardware, : which hopefully in the next release will be fully supported. : : I am more than happy if future FreeBSD version incorporate a different : mechanism such as the one you proposed to 'alias' the device IDs : (even though the alias approach does not cover all cases either; : but it has a complementary coverage area so it will be nice to have : both). The problem in using the "alias" approach in the short term : is that, I believe, it cannot be enabled without changing the kernel. : : In any case, i should repeat that my goal is : 1) to provide users with a tool that does not require them to rebuild : kernel/module or reinstall the OS; : 2) to figure out if "kmodpatch" (or whatever we want to call it) : deserves to be part of the base system or we just keep it as a port : (which is perfectly fine in practice, and also a must for those : who have an older OS version that they don't want to upgrade). It is interesting technology, I'm not sure it is the right tool for the device aliasing... : On coverage of the kmodpatch approach: out of 29 (or 30) usb drivers: : + 19 are compatible with this approach out of the box : + 2 could/should be changed to replace a long 'if' statement : with a table-based approach; : + 3 (uhid, ulpt, ugen) match on the device class so there is no issue; : + 2 (urio and ufm) only recognise a single device so it is unclear : how generic they are, anyways : and the remaining 3-4 are ehci, uhci and ohci drivers. It does require some extra care to introduce duplicate entries into the table, or reserve space. With proper aliasing, we could publish one big file that has all the new aliases since the last release and there'd be no need to modify the leaf drivers. With these modifications, you are inherently limited as to the number of extra entries you can add. OK for the one-off patching, but not so good as an update mechanism. : I am sure things go worse for PCI and PCMCIA devices, but not by a large : degree (and no, i did not do a full count because there are 160 entries : in /sys/dev and this is far beyond the point i want to make). PC Card drivers are in good shape. The PCI drivers, by and large, tend to be a very mixed bag. Some are good, and have tables, others aren't so good. ISA is even worse, but those are much less relevant today than when I was starting this... Warner From owner-freebsd-current@FreeBSD.ORG Fri Jan 2 23:20:18 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 422EF1065672; Fri, 2 Jan 2009 23:20:18 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by mx1.freebsd.org (Postfix) with ESMTP id 823CF8FC1C; Fri, 2 Jan 2009 23:20:17 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from [IPv6:2002:508f:ceb2::21e:c2ff:fe00:76c8] (unknown [IPv6:2002:508f:ceb2:0:21e:c2ff:fe00:76c8]) by mail-n.franken.de (Postfix) with ESMTP id A2E161C0B461A; Sat, 3 Jan 2009 00:20:15 +0100 (CET) Message-Id: From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: "Li, Qing" In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 3 Jan 2009 00:20:14 +0100 References: X-Mailer: Apple Mail (2.930.3) X-Mailman-Approved-At: Fri, 02 Jan 2009 23:58:24 +0000 Cc: qingli@freebsd.org, Randall Stewart , current@freebsd.org, FreeBSD Net Subject: Re: SCTP related issue with recent ARP changes? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2009 23:20:18 -0000 Hi Qing, I have tested your patch and it works! Thanks you very much for your help. Best regards Michael On Jan 2, 2009, at 11:15 PM, Li, Qing wrote: > Hi Michael, > > The SCTP problem you were having was attributed to the arp-v2 changes. > The reason TCP and UDP works well is because the TCP and UDP > modules does not supply a route entry when calling ip_output(). > Consequently in ip_output() the destination (sockaddr) was =20 > reinitialized > and the sin_port field is 0. > > The destination sockaddr supplied in the route entry from the SCTP > module has the actual port value in it. > > The new L2 search was (initially) written as a generic function. > So the L3 address comparison was performed using bcmp() of =20 > sockaddr_len > bytes. The L2 entry was created with a sockaddr object that includes > the port value, however, on ARP input the port value does not > apply. The mismatch in port value causes the ARP lookup to fail > and the SCTP connection never complete its negotiation. > > Please apply the patch for IPv4 in my home directory at > http://people.freebsd.org/~qingli/in.c.diff > > I did the basic testing using the programs you gave me and now > the client connects successful and completes the transfer. I also > verified the packets in wireshark trace. > > Please let me know if this patch fixes your SCTP problems. > > Thank you for your help. > > -- Qing > > >> -----Original Message----- >> From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd- >> current@freebsd.org] On Behalf Of Li, Qing >> Sent: Thursday, January 01, 2009 12:17 PM >> To: Michael T=FCxen; FreeBSD Net >> Cc: qingli@freebsd.org; current@freebsd.org >> Subject: RE: SCTP related issue with recent ARP changes? >> >> >> Hi Michael, >> >> Your problem could be related to the recent ARP changes. >> I will investigate further to confirm. >> >> Thanks, >> >> -- Qing >> >> >> -----Original Message----- >> From: owner-freebsd-net@freebsd.org on behalf of Michael T=FCxen >> Sent: Thu 1/1/2009 8:59 AM >> To: FreeBSD Net >> Subject: SCTP related issue with recent ARP changes? >> >> Dear all, >> >> I'm running the current CVS version of FreeBSD 8 in a virtual >> machine using VMWare 2.0.1 on a Mac (not sure if this is relevant) >> and bridged networking having an em interface on the virtual machine. >> I'm using a similar setup with older FreeBSD machines and they are >> running fine. >> >> Loopback communication based on UDP, TCP, SCTP or ICMP works fine. >> >> Communicating with other hosts using UDP, TCP or ICMP works fine. >> >> Communicating with other hosts using SCTP does not work. >> The SCTP stack calls ip_output() and an ARP request for the >> correct destination IP address is send out. A corresponding >> ARP reply is visible in Wireshark (running on the FreeBSD 8 box) >> and looks good. However, the corresponding SCTP packet it never >> sent out. I'm not sure, but this might be related to the >> recent ARP changes. Is there anything required from the >> transport layer to be done when calling ip_output() that >> was not required before? >> >> Best regards >> Michael >> > > > From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 00:18:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 385F5106564A; Sat, 3 Jan 2009 00:18:54 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 1A2B38FC12; Sat, 3 Jan 2009 00:18:53 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id B3D771A3C39; Fri, 2 Jan 2009 16:18:53 -0800 (PST) Date: Fri, 2 Jan 2009 16:18:53 -0800 From: Alfred Perlstein To: "M. Warner Losh" Message-ID: <20090103001853.GJ60686@elvis.mu.org> References: <20081229181044.GA78575@dragon.NUXI.org> <20090102.115759.-1625878361.imp@bsdimp.com> <20090102231811.GF60686@elvis.mu.org> <20090102.162757.2007158145.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090102.162757.2007158145.imp@bsdimp.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org, hselasky@c2i.net Subject: Re: HEADSUP usb2 (usb4bsd) to become default in 2 weeks. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 00:18:54 -0000 OK. Will make sure this gets priority. Right now we're trying to set up svk so that me submitting his patches will be much more steamlined. Afaik, your issues are top priority after that. -Alfred * M. Warner Losh [090102 15:29] wrote: > In message: <20090102231811.GF60686@elvis.mu.org> > Alfred Perlstein writes: > : I can understand that you're upset that you've hit a few snags, > : but this is the first report from you I've seen in a while, so > : please come up with some specifics so that we can address them. > > Yea, it is hard to stop to file bug reports when you're trying to get > something else done... But I've filed a bug report. I have a few > others that I'm waiting to find the time to recreate them. > > : "some disk enclosures" and "dvd burning doesn't work for me", isn't > : a bug report that's very useful, there are published debugging > : steps for usb4bsd (just as there are for generic kernel errors) > : and it would be nice if you would look into them. > : > : At the very least, some console messages or some details. > > I've filed a bug report. hps asked for more information, but I didn't > understand what he wanted, so I asked for clarification. Once he > tells me more clearly what he needs, I'll get it for him. I have the > setup that causes problems in place, and will until I get all the > hockey videos made... Several weeks still... I expect that hps will > reply in the next day or two... > > Warner > > > : -Alfred > : > : > : * M. Warner Losh [090102 10:59] wrote: > : > In message: <20081229181044.GA78575@dragon.NUXI.org> > : > "David O'Brien" writes: > : > : On Mon, Dec 29, 2008 at 03:19:44AM -0800, Alfred Perlstein wrote: > : > : > * David O'Brien [081229 03:10] wrote: > : > : > > [ Note: replies directed to list ] > : > : > > > : > : > > On Fri, Dec 26, 2008 at 05:23:58PM +0100, Hans Petter Selasky wrote: > : > : > > > There are some debugging sysctls which you can try to tune/increase: > : > : > > > > : > : > > > hw.usb2.pr_recovery_delay: 250 > : > : > > > hw.usb2.ss_delay: 0 > : > : > > > hw.usb2.ehci.no_hs: 0 // this value is a boolean > : > : > > > : > : > > Please. Can we quickly rename this before it gets too ingrained? > : > : > > > : > : > > "usb2" just implies too much the "USB 2.0 specification of April 2000" > : > : > > vs. the 2nd USB implementation within FreeBSD. > : > : > > > : > : > > To stop confusion between USB 2.0 spec and this work, can it be renamed > : > : > > to "hpsusb", "usbhps", "usb4bsd", or even the dreaded over-used "usbNG"? > : > : > > : > : > David, in about two weeks we're going to make "usb2" or "hpsusb" ( :) ) > : > : > the default, if things go well we're planning on cleaning it up > : > : > and making it just "usb" within a few weeks after that. > : > > : > I'm very nervous about this. I have several disk enclosure boxes that > : > flat out don't work on usb2 that work flawlessly on the current usb > : > stack. I've not had time to totally characterize things. > : > > : > Also, the rate of patches into perforce seems high and good. However, > : > they aren't making it into svn quickly. I'd rather see them in the > : > tree and tested well in advance of making usb2 just usb. > : > > : > : > Let's not do this now though as we'll just wind up having to > : > : > do it twice. Rest assured we will get to it shortly. > : > : > : > : Thanks Alfred. > : > : Of course I knew it was about to become the default, but wasn't clear as > : > : to what it would look like as the default. > : > : > : > : Like others, I tried to move to a machine to "hpsusb" and didn't find it > : > : so turn-key. > : > > : > I've found that some things work a lot better, while others are a > : > regression. When your object is to burn DVDs, it can be too large a > : > detour to catalog all the problems that I've hit. I should start > : > doing that, however, since it is clear things are moving ahead at > : > breakneck speeds :( > : > > : > Warner > : > : -- > : - Alfred Perlstein > : > : -- - Alfred Perlstein From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 00:23:03 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3127C1065737 for ; Sat, 3 Jan 2009 00:23:03 +0000 (UTC) (envelope-from uwe@grohnwaldt.eu) Received: from AurraSing.lando.cc (AurraSing.lando.cc [87.106.187.149]) by mx1.freebsd.org (Postfix) with ESMTP id CC8C68FC0C for ; Sat, 3 Jan 2009 00:23:02 +0000 (UTC) (envelope-from uwe@grohnwaldt.eu) Received: from AurraSing.lando.cc (unknown [127.0.0.1]) by AurraSing.lando.cc (Postfix) with ESMTP id 8148318B0F5C5 for ; Sat, 3 Jan 2009 00:23:01 +0000 (UTC) Received: from BriaTharen.local (unknown [139.30.17.205]) by AurraSing.lando.cc (Postfix) with ESMTP for ; Sat, 3 Jan 2009 00:23:01 +0000 (UTC) Message-ID: <495EAFE1.4040801@grohnwaldt.eu> Date: Sat, 03 Jan 2009 01:22:57 +0100 From: Uwe Grohnwaldt User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: current@freebsd.org References: <495E8F00.2050309@grohnwaldt.eu> In-Reply-To: <495E8F00.2050309@grohnwaldt.eu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: panic on (hdd)load X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 00:23:03 -0000 nox gave me some help to provide a kgdb backtrace: Script started on Sat Jan 3 01:15:12 2009 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: ad4: FAILURE - load data ad4: setting up DMA failed ad4: FAILURE - load data ad4: setting up gDMA failed _vfs_done():ad4s1a[WRITE(offset=2318434304, length=8192)]error = 5 ad4: FAILURE - load data ad4: setting up DMA failed ad6: FAILURE - load data ad6: setting up DMA failed ad6: FAILURE - load data ad6: setting up DMA failed ad6: FAILURE - load data ad6: setting up DMA failed ad6: FAILURE - load data ad6: setting up DMA failed ad6: FAILURE - load data ad6: setting up DMA failed ad6: FAILURE - load data ad6: setting up DMA failed ad6: FAILURE - load data ad6: setting up DMA failed ad6: FAILURE - load data ad6: setting up DMA failed ad6: FAILURE - load data ad6: setting up DMA failed g_vfs_done():ad4s1d[READ(offset=394545070080, length=16384)]error = 5 g_vfs_done():ad4s1d[READ(offset=394545086464, length=131072)]error = 5 g_vfs_done():ad6s1a[WRITE(offset=83236225024, length=131072)]error = 5 g_vfs_done():ad6s1a[WRITE(offset=83236749312, length=131072)]error = 5 g_vfs_done():ad6s1a[WRITE(offset=83237142528, length=131072)]error = 5 g_vfs_done():ad6s1a[WRITE(offset=81102749696, length=16384)]error = 5 g_vfs_done():ad6s1a[WRITE(offset=83221839872, length=16384)]error = 5 g_vfs_done():ad6s1a[WRITE(offset=83221905408, length=16384)]error = 5 panic: bundirty: buffer 0xfffffffe932dd340 still on queue 1 cpuid = 0 KDB: enter: panic Physical memory: 4064 MB Dumping 631 MB: 616 600 584 568 552 536 520 504 488 472 456 440 424 408 392 376 360 344 328 312 296 280 264 248 232 216 200 184 168 152 136 120 104 88 72 56 40 24 8 #0 doadump () at pcpu.h:196 196 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xffffffff801c6edc in db_fncall (dummy1=Variable "dummy1" is not available. ) at /usr/src/sys/ddb/db_command.c:548 #2 0xffffffff801c7211 in db_command (last_cmdp=0xffffffff80b3d120, cmd_table=Variable "cmd_table" is not available. ) at /usr/src/sys/ddb/db_command.c:445 #3 0xffffffff801c7460 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0xffffffff801c9409 in db_trap (type=Variable "type" is not available. ) at /usr/src/sys/ddb/db_main.c:229 #5 0xffffffff805565f5 in kdb_trap (type=3, code=0, tf=0xfffffffe40044910) at /usr/src/sys/kern/subr_kdb.c:534 #6 0xffffffff807e1da4 in trap (frame=0xfffffffe40044910) at /usr/src/sys/amd64/amd64/trap.c:533 #7 0xffffffff807c3e6e in calltrap () at /usr/src/sys/amd64/amd64/exception.S:217 #8 0xffffffff805567cd in kdb_enter (why=0xffffffff808c2e59 "panic", msg=0xa
) at cpufunc.h:63 #9 0xffffffff8052729b in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:559 #10 0xffffffff80598930 in bundirty (bp=Variable "bp" is not available. ) at /usr/src/sys/kern/vfs_bio.c:1055 #11 0xffffffff8059aedd in brelse (bp=0xfffffffe932dd340) at /usr/src/sys/kern/vfs_bio.c:1375 #12 0xffffffff8059b42c in bufdone (bp=0xfffffffe932dd340) at /usr/src/sys/kern/vfs_bio.c:3144 #13 0xffffffff8072492c in ffs_backgroundwritedone (bp=0xfffffffe932dd340) ---Type to continue, or q to quit--- at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1741 #14 0xffffffff8059b401 in bufdone (bp=0xfffffffe932dd340) at /usr/src/sys/kern/vfs_bio.c:3138 #15 0xffffffff804d4be1 in g_io_schedule_up (tp=Variable "tp" is not available. ) at /usr/src/sys/geom/geom_io.c:587 #16 0xffffffff804d52cf in g_up_procbody () at /usr/src/sys/geom/geom_kern.c:95 #17 0xffffffff8050566a in fork_exit ( callout=0xffffffff804d5260 , arg=0x0, frame=0xfffffffe40044c90) at /usr/src/sys/kern/kern_fork.c:821 #18 0xffffffff807c429e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:525 #19 0x0000000000000000 in ?? () #20 0x0000000000000000 in ?? () #21 0x0000000000000001 in ?? () #22 0x0000000000000000 in ?? () #23 0x0000000000000000 in ?? () #24 0x0000000000000000 in ?? () #25 0x0000000000000000 in ?? () #26 0x0000000000000000 in ?? () #27 0x0000000000000000 in ?? () #28 0x0000000000000000 in ?? () #29 0x0000000000000000 in ?? () #30 0x0000000000000000 in ?? () ---Type to continue, or q to quit--- #31 0x0000000000000000 in ?? () #32 0x0000000000000000 in ?? () #33 0x0000000000000000 in ?? () #34 0x0000000000000000 in ?? () #35 0x0000000000000000 in ?? () #36 0x0000000000000000 in ?? () #37 0x0000000000000000 in ?? () #38 0x0000000000000000 in ?? () #39 0x0000000000000000 in ?? () #40 0x0000000000000000 in ?? () #41 0x0000000000000000 in ?? () #42 0x0000000000000000 in ?? () #43 0x0000000000f20000 in ?? () #44 0x0000000000000000 in ?? () #45 0xffffffff80b79ec0 in affinity () #46 0xffffffff80b79ec0 in affinity () #47 0xffffff00014ea000 in ?? () #48 0xfffffffe40044760 in ?? () #49 0xfffffffe40044718 in ?? () #50 0xffffff00014eb390 in ?? () #51 0xffffffff80549810 in sched_switch (td=0x0, newtd=0xffffffff804d5260, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/sched_ule.c:1848 Previous frame inner to this frame (corrupt stack?) (kgdb) bt full #0 doadump () at pcpu.h:196 No locals. #1 0xffffffff801c6edc in db_fncall (dummy1=Variable "dummy1" is not available. ) at /usr/src/sys/ddb/db_command.c:548 fn_addr = -2142082880 args = {-7515912464, -2145609658, -2135502000, 249969, 0, -2135346976, 206158430216, -7515912448, -7515912608, -2145611378} nargs = -2136837024 retval = Variable "retval" is not available. thanks, uwe From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 00:45:49 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3102106566B for ; Sat, 3 Jan 2009 00:45:49 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 88F908FC12 for ; Sat, 3 Jan 2009 00:45:48 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 51C4F73098; Sat, 3 Jan 2009 01:50:40 +0100 (CET) Date: Sat, 3 Jan 2009 01:50:40 +0100 From: Luigi Rizzo To: "M. Warner Losh" Message-ID: <20090103005040.GA64606@onelab2.iet.unipi.it> References: <20090101183026.GA15385@onelab2.iet.unipi.it> <20090102.115022.1102529931.imp@bsdimp.com> <20090102210133.GA57653@onelab2.iet.unipi.it> <20090102.163308.-1929116900.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090102.163308.-1929116900.imp@bsdimp.com> User-Agent: Mutt/1.4.2.3i Cc: current@FreeBSD.org Subject: Re: RFC: new utility, kmodpatch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 00:45:50 -0000 On Fri, Jan 02, 2009 at 04:33:08PM -0700, M. Warner Losh wrote: > In message: <20090102210133.GA57653@onelab2.iet.unipi.it> > Luigi Rizzo writes: ... > : The usage model I expect is that people will be told something like this > : > : To support the BenQ T33 phone on FreeBSD/i386 6.x or 7.x do > : kmodpatch -t "umass.ko umass_devdescrs 4 4 4 2" - - @0 0x4050 0x4a5 0x0101 0x4200 > : > : to support the Asus M2N-Vm DVI MCP67 ethernet on FreeBSD/i386 7.x do > : kmodpatch -t "if_nfe.ko nfe_devs 2 2 s" - - @0 0x10de 0x54c - > : and please note TX flow control does not work > > This is a good interface for our users? i don't know -- in the end it is "if you trust me, cut&paste this line into a root shell" which I believe is simpler than "if you trust me, apply this patch, rebuild the kernel and reinstall" > It is interesting technology, I'm not sure it is the right tool for > the device aliasing... > It does require some extra care to introduce duplicate entries into > the table, or reserve space. or just overwrite some entry that is unused in your setting, which again does not work in 100% of the cases but it is very close to that. > With proper aliasing, we could publish > one big file that has all the new aliases since the last release and > there'd be no need to modify the leaf drivers. With these in principle yes, though that i expect that the source of info is not freebsd.org (which often does not have a chance to check/try whether an alias is correct), but rather mailing lists or other users which happen to have the same device and tried it. cheers luigi From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 01:22:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21BCC106564A for ; Sat, 3 Jan 2009 01:22:28 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe10.swipnet.se [212.247.155.33]) by mx1.freebsd.org (Postfix) with ESMTP id AD8C58FC18 for ; Sat, 3 Jan 2009 01:22:27 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=rREUrScshOl7G2h6aTFPgw==:17 a=6I5d2MoRAAAA:8 a=ETagwzsV7IGY0jYIyqgA:9 a=kyimxPtgPU2r6Pp_UucA:7 a=nY98K5fygFA1iBoIUEEs1oF0vUQA:4 a=LY0hPdMaydYA:10 Received: from [62.73.248.227] (account mc467741@c2i.net [62.73.248.227] verified) by mailfe10.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1005210074; Sat, 03 Jan 2009 02:22:25 +0100 From: Hans Petter Selasky To: Thomas Sparrevohn Date: Sat, 3 Jan 2009 02:24:42 +0100 User-Agent: KMail/1.9.7 References: <495E8F00.2050309@grohnwaldt.eu> <495EAFE1.4040801@grohnwaldt.eu> <200901030116.45837.Thomas.Sparrevohn@btinternet.com> In-Reply-To: <200901030116.45837.Thomas.Sparrevohn@btinternet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901030224.44187.hselasky@c2i.net> Cc: freebsd-current@freebsd.org Subject: Re: panic on (hdd)load X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 01:22:28 -0000 On Saturday 03 January 2009, Thomas Sparrevohn wrote: > On Saturday 03 January 2009 00:22:57 Uwe Grohnwaldt wrote: > > > This error occurs because of some DMA corruption when the PM changes was > added to the ATA framework. The error is actually related to the USB Umass > device. > > HPS has already identified the issue in the new USB stack but I don't think > it has been solved yet ;-( > > Try to disable umass devices and see what happens > Here is the patch I've made. Probably you can or have to make the re-alignment unconditional. http://perforce.freebsd.org/chv.cgi?CH=154181 --HPS From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 01:43:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB2B7106564A for ; Sat, 3 Jan 2009 01:43:36 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: from smtp806.mail.ird.yahoo.com (smtp806.mail.ird.yahoo.com [217.146.188.66]) by mx1.freebsd.org (Postfix) with SMTP id 559688FC13 for ; Sat, 3 Jan 2009 01:43:35 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: (qmail 65654 invoked from network); 3 Jan 2009 01:16:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:From:To:Subject:Date:User-Agent:References:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-Disposition:Message-Id; b=fN8jeh2Lsj5eGcuMTFtPwwVutZnEPkUOfN86omB/Lptjlqe7A34lQUoJa1EeJ4Vl2LXIbrgti/hZi88vg1CrwYo01qgCbPd40aUDcdtr836hAP2ncFjM49h+rlxrD9/EXcpnJsGrAA8Wh/T/401IYU+eI0u4QXIaPmMQp1G2n4s= ; Received: from unknown (HELO w2fzz0vc03.aah-go-on.com) (Thomas.Sparrevohn@86.147.162.100 with login) by smtp806.mail.ird.yahoo.com with SMTP; 3 Jan 2009 01:16:53 -0000 X-YMail-OSG: rVRKN6oVM1nI4rJGW3qXe7ud57R7bTx9AXFBxNqt8mXxeMilY4IZ1bfpYbqtA8ADFJ3KM6bWdsSxTNgTE5571TQ._RzVhhndK2RovFgKdoFUy59B5O4XTlxaEBdMKnBT0I9V8kInh.JsK2coWOkNUNGcHe58HY1msK5IwZoKcIED8GLy31JQXuBReucQ6EqBx5iwuJbH1Poug8MW8xhWdHKj6S7KVbGI X-Yahoo-Newman-Property: ymail-3 From: Thomas Sparrevohn To: freebsd-current@freebsd.org, Hans Petter Selasky Date: Sat, 3 Jan 2009 01:16:45 +0000 User-Agent: KMail/1.9.10 References: <495E8F00.2050309@grohnwaldt.eu> <495EAFE1.4040801@grohnwaldt.eu> In-Reply-To: <495EAFE1.4040801@grohnwaldt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901030116.45837.Thomas.Sparrevohn@btinternet.com> Cc: Subject: Re: panic on (hdd)load X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 01:43:37 -0000 On Saturday 03 January 2009 00:22:57 Uwe Grohnwaldt wrote: This error occurs because of some DMA corruption when the PM changes was added to the ATA framework. The error is actually related to the USB Umass device. HPS has already identified the issue in the new USB stack but I don't think it has been solved yet ;-( Try to disable umass devices and see what happens > nox gave me some help to provide a kgdb backtrace: > > Script started on Sat Jan 3 01:15:12 2009 > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd"... > > Unread portion of the kernel message buffer: > ad4: FAILURE - load data > ad4: setting up DMA failed > ad4: FAILURE - load data > ad4: setting up gDMA failed > _vfs_done():ad4s1a[WRITE(offset=2318434304, length=8192)]error = 5 > ad4: FAILURE - load data > ad4: setting up DMA failed > ad6: FAILURE - load data > ad6: setting up DMA failed > ad6: FAILURE - load data > ad6: setting up DMA failed > ad6: FAILURE - load data > ad6: setting up DMA failed > ad6: FAILURE - load data > ad6: setting up DMA failed > ad6: FAILURE - load data > ad6: setting up DMA failed > ad6: FAILURE - load data > ad6: setting up DMA failed > ad6: FAILURE - load data > ad6: setting up DMA failed > ad6: FAILURE - load data > ad6: setting up DMA failed > ad6: FAILURE - load data > ad6: setting up DMA failed > g_vfs_done():ad4s1d[READ(offset=394545070080, length=16384)]error = 5 > g_vfs_done():ad4s1d[READ(offset=394545086464, length=131072)]error = 5 > g_vfs_done():ad6s1a[WRITE(offset=83236225024, length=131072)]error = 5 > g_vfs_done():ad6s1a[WRITE(offset=83236749312, length=131072)]error = 5 > g_vfs_done():ad6s1a[WRITE(offset=83237142528, length=131072)]error = 5 > g_vfs_done():ad6s1a[WRITE(offset=81102749696, length=16384)]error = 5 > g_vfs_done():ad6s1a[WRITE(offset=83221839872, length=16384)]error = 5 > g_vfs_done():ad6s1a[WRITE(offset=83221905408, length=16384)]error = 5 > panic: bundirty: buffer 0xfffffffe932dd340 still on queue 1 > cpuid = 0 > KDB: enter: panic > Physical memory: 4064 MB > Dumping 631 MB: 616 600 584 568 552 536 520 504 488 472 456 440 424 408 > 392 376 360 344 328 312 296 280 264 248 232 216 200 184 168 152 136 120 > 104 88 72 56 40 24 8 > > #0 doadump () at pcpu.h:196 > 196 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:196 > #1 0xffffffff801c6edc in db_fncall (dummy1=Variable "dummy1" is not > available. > ) > at /usr/src/sys/ddb/db_command.c:548 > #2 0xffffffff801c7211 in db_command (last_cmdp=0xffffffff80b3d120, > cmd_table=Variable "cmd_table" is not available. > ) > at /usr/src/sys/ddb/db_command.c:445 > #3 0xffffffff801c7460 in db_command_loop () > at /usr/src/sys/ddb/db_command.c:498 > #4 0xffffffff801c9409 in db_trap (type=Variable "type" is not available. > ) at /usr/src/sys/ddb/db_main.c:229 > #5 0xffffffff805565f5 in kdb_trap (type=3, code=0, tf=0xfffffffe40044910) > at /usr/src/sys/kern/subr_kdb.c:534 > #6 0xffffffff807e1da4 in trap (frame=0xfffffffe40044910) > at /usr/src/sys/amd64/amd64/trap.c:533 > #7 0xffffffff807c3e6e in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:217 > #8 0xffffffff805567cd in kdb_enter (why=0xffffffff808c2e59 "panic", > msg=0xa
) at cpufunc.h:63 > #9 0xffffffff8052729b in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:559 > #10 0xffffffff80598930 in bundirty (bp=Variable "bp" is not available. > ) at /usr/src/sys/kern/vfs_bio.c:1055 > #11 0xffffffff8059aedd in brelse (bp=0xfffffffe932dd340) > at /usr/src/sys/kern/vfs_bio.c:1375 > #12 0xffffffff8059b42c in bufdone (bp=0xfffffffe932dd340) > at /usr/src/sys/kern/vfs_bio.c:3144 > #13 0xffffffff8072492c in ffs_backgroundwritedone (bp=0xfffffffe932dd340) > ---Type to continue, or q to quit--- > at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1741 > #14 0xffffffff8059b401 in bufdone (bp=0xfffffffe932dd340) > at /usr/src/sys/kern/vfs_bio.c:3138 > #15 0xffffffff804d4be1 in g_io_schedule_up (tp=Variable "tp" is not > available. > ) > at /usr/src/sys/geom/geom_io.c:587 > #16 0xffffffff804d52cf in g_up_procbody () at > /usr/src/sys/geom/geom_kern.c:95 > #17 0xffffffff8050566a in fork_exit ( > callout=0xffffffff804d5260 , arg=0x0, > frame=0xfffffffe40044c90) at /usr/src/sys/kern/kern_fork.c:821 > #18 0xffffffff807c429e in fork_trampoline () > at /usr/src/sys/amd64/amd64/exception.S:525 > #19 0x0000000000000000 in ?? () > #20 0x0000000000000000 in ?? () > #21 0x0000000000000001 in ?? () > #22 0x0000000000000000 in ?? () > #23 0x0000000000000000 in ?? () > #24 0x0000000000000000 in ?? () > #25 0x0000000000000000 in ?? () > #26 0x0000000000000000 in ?? () > #27 0x0000000000000000 in ?? () > #28 0x0000000000000000 in ?? () > #29 0x0000000000000000 in ?? () > #30 0x0000000000000000 in ?? () > ---Type to continue, or q to quit--- > #31 0x0000000000000000 in ?? () > #32 0x0000000000000000 in ?? () > #33 0x0000000000000000 in ?? () > #34 0x0000000000000000 in ?? () > #35 0x0000000000000000 in ?? () > #36 0x0000000000000000 in ?? () > #37 0x0000000000000000 in ?? () > #38 0x0000000000000000 in ?? () > #39 0x0000000000000000 in ?? () > #40 0x0000000000000000 in ?? () > #41 0x0000000000000000 in ?? () > #42 0x0000000000000000 in ?? () > #43 0x0000000000f20000 in ?? () > #44 0x0000000000000000 in ?? () > #45 0xffffffff80b79ec0 in affinity () > #46 0xffffffff80b79ec0 in affinity () > #47 0xffffff00014ea000 in ?? () > #48 0xfffffffe40044760 in ?? () > #49 0xfffffffe40044718 in ?? () > #50 0xffffff00014eb390 in ?? () > #51 0xffffffff80549810 in sched_switch (td=0x0, newtd=0xffffffff804d5260, > flags=Variable "flags" is not available. > ) at /usr/src/sys/kern/sched_ule.c:1848 > Previous frame inner to this frame (corrupt stack?) > (kgdb) bt full > #0 doadump () at pcpu.h:196 > No locals. > #1 0xffffffff801c6edc in db_fncall (dummy1=Variable "dummy1" is not > available. > ) > at /usr/src/sys/ddb/db_command.c:548 > fn_addr = -2142082880 > args = {-7515912464, -2145609658, -2135502000, 249969, 0, > -2135346976, > 206158430216, -7515912448, -7515912608, -2145611378} > nargs = -2136837024 > retval = Variable "retval" is not available. > > > thanks, > uwe > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 03:35:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E226106566B for ; Sat, 3 Jan 2009 03:35:53 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 3F6E78FC1A for ; Sat, 3 Jan 2009 03:35:53 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.2/8.14.2) with ESMTP id n033ZkQ3077713; Fri, 2 Jan 2009 19:35:46 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.2/8.14.2/Submit) id n033Zh9W077711; Fri, 2 Jan 2009 19:35:43 -0800 (PST) (envelope-from obrien) Date: Fri, 2 Jan 2009 19:35:43 -0800 From: "David O'Brien" To: "M. Warner Losh" Message-ID: <20090103033543.GB77475@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, "M. Warner Losh" , bsam@ipt.ru, freebsd-current@freebsd.org, fbsdlist@src.cx References: <69321574@bs1.sp34.ru> <20090102091334.GA41230@dragon.NUXI.org> <20090102.114757.-924277930.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090102.114757.-924277930.imp@bsdimp.com> X-Operating-System: FreeBSD 8.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: bsam@ipt.ru, freebsd-current@freebsd.org, fbsdlist@src.cx Subject: Re: gjournal is not automounted any more X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 03:35:53 -0000 On Fri, Jan 02, 2009 at 11:47:57AM -0700, M. Warner Losh wrote: > In message: <20090102091334.GA41230@dragon.NUXI.org> > "David O'Brien" writes: > : Before 'fsck' would read the lable for the FS type. That has changed and > : thus you cannot just 'fsck /dev/ad1s1d' anymore. So the FS type in fstab > : must be accurate. > > Why did that change? I routinely have disks that aren't in my > /etc/fstab that I mount and this is a pain in the backside. Due to r186240 which: Make gpart the default partitioning class on all platforms. Seems GEOM_PART_BSD does not like labels that GEOM_BSD did. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 06:11:34 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0E341065726 for ; Sat, 3 Jan 2009 06:11:34 +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 673B28FC13 for ; Sat, 3 Jan 2009 06:11:34 +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 n0368EF9064797; Fri, 2 Jan 2009 23:08:14 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 02 Jan 2009 23:08:25 -0700 (MST) Message-Id: <20090102.230825.1159135437.imp@bsdimp.com> To: rizzo@iet.unipi.it From: "M. Warner Losh" In-Reply-To: <20090103005040.GA64606@onelab2.iet.unipi.it> References: <20090102210133.GA57653@onelab2.iet.unipi.it> <20090102.163308.-1929116900.imp@bsdimp.com> <20090103005040.GA64606@onelab2.iet.unipi.it> 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: current@FreeBSD.org Subject: Re: RFC: new utility, kmodpatch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 06:11:35 -0000 In message: <20090103005040.GA64606@onelab2.iet.unipi.it> Luigi Rizzo writes: : On Fri, Jan 02, 2009 at 04:33:08PM -0700, M. Warner Losh wrote: : > In message: <20090102210133.GA57653@onelab2.iet.unipi.it> : > Luigi Rizzo writes: : ... : > : The usage model I expect is that people will be told something like this : > : : > : To support the BenQ T33 phone on FreeBSD/i386 6.x or 7.x do : > : kmodpatch -t "umass.ko umass_devdescrs 4 4 4 2" - - @0 0x4050 0x4a5 0x0101 0x4200 : > : : > : to support the Asus M2N-Vm DVI MCP67 ethernet on FreeBSD/i386 7.x do : > : kmodpatch -t "if_nfe.ko nfe_devs 2 2 s" - - @0 0x10de 0x54c - : > : and please note TX flow control does not work : > : > This is a good interface for our users? : : i don't know -- in the end it is : "if you trust me, cut&paste this line into a root shell" : which I believe is simpler than : "if you trust me, apply this patch, rebuild the kernel and reinstall" That's debatable :). Let's trade this hard to do thing for this thing that's hard to verify... It might be progress, but it is only tiny, incremental progress... : > It is interesting technology, I'm not sure it is the right tool for : > the device aliasing... : : > It does require some extra care to introduce duplicate entries into : > the table, or reserve space. : : or just overwrite some entry that is unused in your setting, : which again does not work in 100% of the cases but it is very : close to that. Yea, it is a kludge that works... : > With proper aliasing, we could publish : > one big file that has all the new aliases since the last release and : > there'd be no need to modify the leaf drivers. With these : : in principle yes, though that i expect that the source of info is not : freebsd.org (which often does not have a chance to check/try : whether an alias is correct), but rather mailing lists or other users : which happen to have the same device and tried it. I'd suspect it is freebsd.org, with inputs from the mailing lists... Warner From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 06:14:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EE95106564A; Sat, 3 Jan 2009 06:14:38 +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 0DD078FC13; Sat, 3 Jan 2009 06:14:37 +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 n036DwAv064850; Fri, 2 Jan 2009 23:13:58 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 02 Jan 2009 23:14:10 -0700 (MST) Message-Id: <20090102.231410.-2001109684.imp@bsdimp.com> To: obrien@freebsd.org From: "M. Warner Losh" In-Reply-To: <20090103033543.GB77475@dragon.NUXI.org> References: <20090102091334.GA41230@dragon.NUXI.org> <20090102.114757.-924277930.imp@bsdimp.com> <20090103033543.GB77475@dragon.NUXI.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: bsam@ipt.ru, freebsd-current@freebsd.org, fbsdlist@src.cx Subject: Re: gjournal is not automounted any more X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 06:14:38 -0000 In message: <20090103033543.GB77475@dragon.NUXI.org> "David O'Brien" writes: : On Fri, Jan 02, 2009 at 11:47:57AM -0700, M. Warner Losh wrote: : > In message: <20090102091334.GA41230@dragon.NUXI.org> : > "David O'Brien" writes: : > : Before 'fsck' would read the lable for the FS type. That has changed and : > : thus you cannot just 'fsck /dev/ad1s1d' anymore. So the FS type in fstab : > : must be accurate. : > : > Why did that change? I routinely have disks that aren't in my : > /etc/fstab that I mount and this is a pain in the backside. : : Due to r186240 which: : Make gpart the default partitioning class on all platforms. : : Seems GEOM_PART_BSD does not like labels that GEOM_BSD did. Then why the change? Shouldn't we make it like them for compatibility? Warner From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 06:52:32 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A0631065675 for ; Sat, 3 Jan 2009 06:52:32 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 6E7E28FC17 for ; Sat, 3 Jan 2009 06:52:32 +0000 (UTC) (envelope-from randy@psg.com) Received: from 50.216.138.210.bn.2iij.net ([210.138.216.50] helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LJ0N5-000LOj-EA for current@FreeBSD.org; Sat, 03 Jan 2009 06:52:31 +0000 Message-ID: <495F0B2D.7060701@psg.com> Date: Sat, 03 Jan 2009 15:52:29 +0900 From: Randy Bush User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081204 Thunderbird/3.0b1 MIME-Version: 1.0 To: current@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: hosts on bridged wlan can not reliably see each other X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 06:52:32 -0000 soekris 5501 of nov 28, pre new arp problem description o all hosts on the wireless can get outside, no problem o they can also get to wired devices on vr[1-3] o they can reliably not see/ping/... each other on the wireless o the soekris can ping them all o higher layers are worse o the messages on this list worry me about upgrading this week, as this is my home gate to the world and somewhat complex (bridge, tunnel, pppoe, ...), whereas the mass of servers are all pretty straightforward. .----------------. | | | b ---ath0| 192.168.0.0/24 | r | ext iij | i --- vr1| LAN hosts, PPP/NAT ---|vr0--- d | WAN | g --- vr2| DHCP Clients | e | | 0 --- vr3| pptp 200-209 | | `----------------' ath0: mem 0xa0010000-0xa001ffff irq 15 at device 17.0 on pci0 ath0: [ITHREAD] ath0: WARNING: using obsoleted if_watchdog interface ath0: mac 5.9 phy 4.3 radio 3.6 # uname -a FreeBSD soek0.psg.com 8.0-CURRENT FreeBSD 8.0-CURRENT #2: Fri Nov 28 19:16:10 UTC 2008 root@soek0.psg.com:/usr/obj/usr/src/sys/SOEK0 i386 wlans_ath0="wlan0 wlan1" create_args_wlan0="wlanmode hostap channel 11 ssid rgnet-aden wep wepkey arbitrarykeys weptxkey 1 media autoselect mode 11g up" cloned_interfaces=bridge0 ifconfig_bridge0="192.168.0.1 addm vr1 addm vr2 addm vr3 addm wlan0 addm wlan1 up" ifconfig_vr1=up ifconfig_vr2=up ifconfig_vr3=up gateway_enable=YES the soekris can see them all # arp -an ? (192.168.0.10) at 00:15:c5:4a:6f:c5 on bridge0 [bridge] ? (192.168.0.12) at 00:1e:52:70:b6:36 on bridge0 [bridge] ? (192.168.0.13) at 00:15:00:10:ed:09 on bridge0 [bridge] ? (192.168.0.17) at 00:0d:65:27:bd:f2 on bridge0 [bridge] ? (192.168.0.128) at 00:23:12:fc:39:b9 on bridge0 [bridge] ? (192.168.0.129) at 00:23:df:6a:dc:9b on bridge0 [bridge] and gets log entries of Jan 2 00:01:09 soek kernel: rtfree: 0xc2e803c0 has 1 refs Jan 2 00:01:16 soek kernel: rtfree: 0xc2e80078 has 1 refs Jan 2 00:01:16 soek kernel: rtfree: 0xc2e80078 has 1 refs Jan 2 00:01:16 soek kernel: arp_proxy: ignoring request from 192.168.0.10 via vr2, expecting bridge0 what more should i do to debug? randy From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 07:37:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6BB8106566B for ; Sat, 3 Jan 2009 07:37:17 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 976A08FC17 for ; Sat, 3 Jan 2009 07:37:17 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.2/8.14.2) with ESMTP id n037bA8f080910; Fri, 2 Jan 2009 23:37:10 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.2/8.14.2/Submit) id n037bAlN080909; Fri, 2 Jan 2009 23:37:10 -0800 (PST) (envelope-from obrien) Date: Fri, 2 Jan 2009 23:37:09 -0800 From: "David O'Brien" To: "M. Warner Losh" Message-ID: <20090103073709.GA80876@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, "M. Warner Losh" , bsam@ipt.ru, freebsd-current@freebsd.org, fbsdlist@src.cx References: <20090102091334.GA41230@dragon.NUXI.org> <20090102.114757.-924277930.imp@bsdimp.com> <20090103033543.GB77475@dragon.NUXI.org> <20090102.231410.-2001109684.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090102.231410.-2001109684.imp@bsdimp.com> X-Operating-System: FreeBSD 8.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: bsam@ipt.ru, freebsd-current@freebsd.org, fbsdlist@src.cx Subject: Re: gjournal is not automounted any more X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 07:37:18 -0000 On Fri, Jan 02, 2009 at 11:14:10PM -0700, M. Warner Losh wrote: > In message: <20090103033543.GB77475@dragon.NUXI.org> > "David O'Brien" writes: > : On Fri, Jan 02, 2009 at 11:47:57AM -0700, M. Warner Losh wrote: > : > In message: <20090102091334.GA41230@dragon.NUXI.org> > : > "David O'Brien" writes: > : > : Before 'fsck' would read the lable for the FS type. That has changed and > : > : thus you cannot just 'fsck /dev/ad1s1d' anymore. So the FS type in fstab > : > : must be accurate. > : > > : > Why did that change? I routinely have disks that aren't in my > : > /etc/fstab that I mount and this is a pain in the backside. > : > : Due to r186240 which: > : Make gpart the default partitioning class on all platforms. > : > : Seems GEOM_PART_BSD does not like labels that GEOM_BSD did. > > Then why the change? Shouldn't we make it like them for compatibility? Looks like Marcel is working on fixing these nits. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 07:47:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6984106566C; Sat, 3 Jan 2009 07:47:28 +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 66C318FC08; Sat, 3 Jan 2009 07:47:28 +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 n037kVMx065581; Sat, 3 Jan 2009 00:46:31 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sat, 03 Jan 2009 00:46:42 -0700 (MST) Message-Id: <20090103.004642.1683993840.imp@bsdimp.com> To: obrien@freebsd.org From: "M. Warner Losh" In-Reply-To: <20090103073709.GA80876@dragon.NUXI.org> References: <20090103033543.GB77475@dragon.NUXI.org> <20090102.231410.-2001109684.imp@bsdimp.com> <20090103073709.GA80876@dragon.NUXI.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: bsam@ipt.ru, freebsd-current@freebsd.org, fbsdlist@src.cx Subject: Re: gjournal is not automounted any more X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 07:47:28 -0000 In message: <20090103073709.GA80876@dragon.NUXI.org> "David O'Brien" writes: : On Fri, Jan 02, 2009 at 11:14:10PM -0700, M. Warner Losh wrote: : > In message: <20090103033543.GB77475@dragon.NUXI.org> : > "David O'Brien" writes: : > : On Fri, Jan 02, 2009 at 11:47:57AM -0700, M. Warner Losh wrote: : > : > In message: <20090102091334.GA41230@dragon.NUXI.org> : > : > "David O'Brien" writes: : > : > : Before 'fsck' would read the lable for the FS type. That has changed and : > : > : thus you cannot just 'fsck /dev/ad1s1d' anymore. So the FS type in fstab : > : > : must be accurate. : > : > : > : > Why did that change? I routinely have disks that aren't in my : > : > /etc/fstab that I mount and this is a pain in the backside. : > : : > : Due to r186240 which: : > : Make gpart the default partitioning class on all platforms. : > : : > : Seems GEOM_PART_BSD does not like labels that GEOM_BSD did. : > : > Then why the change? Shouldn't we make it like them for compatibility? : : Looks like Marcel is working on fixing these nits. Excellent. I'd be happy to send him my disk label blocks if that would help :-). Warner From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 10:16:10 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3272D106566B for ; Sat, 3 Jan 2009 10:16:10 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id 11CBD8FC17 for ; Sat, 3 Jan 2009 10:16:09 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.2/8.14.2) with ESMTP id n03AG7Ct084344; Sat, 3 Jan 2009 02:16:07 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.2/8.14.2/Submit) id n03AG7vl084343; Sat, 3 Jan 2009 02:16:07 -0800 (PST) (envelope-from obrien) Date: Sat, 3 Jan 2009 02:16:07 -0800 From: "David O'Brien" To: Johan Hendriks Message-ID: <20090103101606.GA81276@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Johan Hendriks , freebsd-current@freebsd.org References: <57200BF94E69E54880C9BB1AF714BBCB0111B3@w2003s01.double-l.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57200BF94E69E54880C9BB1AF714BBCB0111B3@w2003s01.double-l.local> X-Operating-System: FreeBSD 8.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-current@freebsd.org Subject: Re: build -j3 not working anymore on Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 10:16:10 -0000 On Fri, Jan 02, 2009 at 11:32:44AM +0100, Johan Hendriks wrote: > First of all a very happy new year to you all. You too! :-) Here's hoping 2009 > 2008. > I always use the following command to do the buildworld cycles. > make cleanworld && make -j3 buildworld && make -j3 kernel > But as of now i get the following error Based on an email I got from Ken Smith, there seems to be something weird going on with the rescue build. I've made a temperary change to make(1) until I can figure out what it is. [svn r186713] -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 10:20:43 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B9AA106566B for ; Sat, 3 Jan 2009 10:20:43 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (trang.nuxi.org [74.95.12.85]) by mx1.freebsd.org (Postfix) with ESMTP id EEEEF8FC18 for ; Sat, 3 Jan 2009 10:20:42 +0000 (UTC) (envelope-from obrien@NUXI.org) Received: from dragon.nuxi.org (obrien@localhost [127.0.0.1]) by dragon.nuxi.org (8.14.2/8.14.2) with ESMTP id n03AKaLD084421; Sat, 3 Jan 2009 02:20:36 -0800 (PST) (envelope-from obrien@dragon.nuxi.org) Received: (from obrien@localhost) by dragon.nuxi.org (8.14.2/8.14.2/Submit) id n03AKaF8084420; Sat, 3 Jan 2009 02:20:36 -0800 (PST) (envelope-from obrien) Date: Sat, 3 Jan 2009 02:20:36 -0800 From: "David O'Brien" To: "M. Warner Losh" Message-ID: <20090103102036.GB81276@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, "M. Warner Losh" , freebsd-current@freebsd.org References: <20090102.115426.-1540393465.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090102.115426.-1540393465.imp@bsdimp.com> X-Operating-System: FreeBSD 8.0-CURRENT User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-current@freebsd.org Subject: Re: New warning, what does it mean? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 10:20:43 -0000 On Fri, Jan 02, 2009 at 11:54:26AM -0700, M. Warner Losh wrote: > I'm getting the following from my main disk on boot now: > GEOM: ad0s2: geometry does not match label (255h,63s != 16h,63s). .. > Why are they complaining? What is the corrective action to be taken > here? Why does it matter with modern disks and BIOSes anyway? All very good questions. See my recent "Shooting sysinstall/SADE geometry warning in the head" thread. Seems maybe GEOM_PART_BSD took a page from that book and should be smacked also. I don't see why FreeBSD is making such a mess of geometries with modern SATA/IDE disks. We seem to be the standout here. :-( -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 11:44:29 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF548106566C for ; Sat, 3 Jan 2009 11:44:29 +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 44B998FC08 for ; Sat, 3 Jan 2009 11:44:29 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from [195.4.92.23] (helo=13.mx.freenet.de) by mout2.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #76) id 1LJ4va-0005g8-Gm; Sat, 03 Jan 2009 12:44:26 +0100 Received: from tdc35.t.pppool.de ([89.55.220.53]:59858 helo=ernst.jennejohn.org) by 13.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #76) id 1LJ4va-0008PY-9W; Sat, 03 Jan 2009 12:44:26 +0100 Date: Sat, 3 Jan 2009 12:44:24 +0100 From: Gary Jennejohn To: Luigi Rizzo Message-ID: <20090103124424.2959f2ac@ernst.jennejohn.org> In-Reply-To: <20090102221719.GA61058@onelab2.iet.unipi.it> References: <20090101183026.GA15385@onelab2.iet.unipi.it> <6101e8c40901011117y3e82a226id6f9de940b0f7dcd@mail.gmail.com> <47d0403c0901011619r658fd25ct3d01bc32969bde11@mail.gmail.com> <20090102221719.GA61058@onelab2.iet.unipi.it> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, Ben Kaduk , Oliver Pinter Subject: Re: RFC: new utility, kmodpatch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 11:44:29 -0000 On Fri, 2 Jan 2009 23:17:19 +0100 Luigi Rizzo wrote: > On Thu, Jan 01, 2009 at 07:19:12PM -0500, Ben Kaduk wrote: > > On Thu, Jan 1, 2009 at 2:17 PM, Oliver Pinter wrote: > > > Hi! > > > > > > Do You think for this project: http://www.ksplice.com/ ? > > > > > > On 1/1/09, Luigi Rizzo wrote: > > >> I mentioned this utility a couple of months ago, and it's now working > > >> so i would like to receive feedback on whether this is good to have > > >> as part of the system, or just keep it as a port (which is what > > >> i plan to do by default). > > >> > > >> In a nutshell, the kmodpatch utility can print or alter the content > > >> of device/quirk tables in kernel modules (I think Linux has some > > >> similar tool, though i don't remember the name -- or perhaps it is > > >> a feature of insmod ?). > > >> > > > > > > Ksplice is not yet in the linux kernel tree, so it's probably not > > what Luigi was referring to. However, it is a pretty impressive > > correct, i think there is some feature (in insmod or whatever the > utility to load a module is) to configure the module so it uses > certain variables (perhaps including recognising a given USB vendor-id pair?) > These are called moduler parameters in Linux parlance and must be built into the drivers themselves. insmod merely provides a mehcanism for passing them to the drivers. --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 14:30:06 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E2AA106566B for ; Sat, 3 Jan 2009 14:30:06 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id C5BDA8FC13 for ; Sat, 3 Jan 2009 14:30:05 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from mr02.lnh.mail.rcn.net ([207.172.157.22]) by smtp02.lnh.mail.rcn.net with ESMTP; 03 Jan 2009 09:01:35 -0500 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr02.lnh.mail.rcn.net (MOS 3.8.6-GA) with ESMTP id PJE83737; Sat, 3 Jan 2009 09:01:35 -0500 (EST) Received: from unknown (HELO jerusalem.litteratus.org.litteratus.org) ([209.6.22.188]) by smtp01.lnh.mail.rcn.net with ESMTP; 03 Jan 2009 09:01:35 -0500 From: Robert Huff MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18783.28606.874391.376202@jerusalem.litteratus.org> Date: Sat, 3 Jan 2009 09:01:34 -0500 To: current@freebsd.org X-Mailer: VM 7.17 under 21.5 (beta28) "fuki" XEmacs Lucid X-Junkmail-Whitelist: YES (by domain whitelist at mr02.lnh.mail.rcn.net) Cc: Subject: kernel complaint about /dev/pts (maybe) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 14:30:06 -0000 On a box running FreeBSD 7.0-CURRENT #2: Wed Nov 19 06:02:02 EST 2008 i386 I am seeing a steady (though not particularly rapid) stream of: comsat[3597]: '/' in "/dev/pts/X" for X = [1-5]. There is no mention of this in UPDATING, or (as far as I can tell) in the lists. Google produces hits for NetBSD and Linux, but none with either a) a real explanation or b) a real (as opposed to half-ass) fix. Doesn't /seem/ to be hurting anything ... but this is a test box for a reason. Anyone (please!) have the clue(s) I'm missing? Robert Huff From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 15:11:44 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBE29106564A for ; Sat, 3 Jan 2009 15:11:44 +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 B7AFB8FC24 for ; Sat, 3 Jan 2009 15:11:43 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 65D391CE07; Sat, 3 Jan 2009 16:11:42 +0100 (CET) Date: Sat, 3 Jan 2009 16:11:42 +0100 From: Ed Schouten To: Robert Huff Message-ID: <20090103151142.GL14235@hoeg.nl> References: <18783.28606.874391.376202@jerusalem.litteratus.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xtmLDbP6TiKhntQb" Content-Disposition: inline In-Reply-To: <18783.28606.874391.376202@jerusalem.litteratus.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: current@freebsd.org Subject: Re: kernel complaint about /dev/pts (maybe) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 15:11:45 -0000 --xtmLDbP6TiKhntQb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Robert, * Robert Huff wrote: > FreeBSD 7.0-CURRENT #2: Wed Nov 19 06:02:02 EST 2008 i386=20 Are you sure this is correct? In Nov 2008 we already had 8.0-CURRENT. If you are running 7.0-CURRENT, you are dealing with the previous (experimental) pts(4) code. If you update your sources to anything past 20 August 2008, you will use the new pts(4) driver. Let me know if you run into any problems after updating to the latest sources. --=20 Ed Schouten WWW: http://80386.nl/ --xtmLDbP6TiKhntQb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAklfgC4ACgkQ52SDGA2eCwX5QgCfb5vdUCkyoZcq+3hil5wKcclu V3wAn2paxZC38GJ+fiRR63qJ0PpgN2rD =zO+N -----END PGP SIGNATURE----- --xtmLDbP6TiKhntQb-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 16:27:27 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 507B5106566B for ; Sat, 3 Jan 2009 16:27:27 +0000 (UTC) (envelope-from chris@hitnet.RWTH-Aachen.DE) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by mx1.freebsd.org (Postfix) with ESMTP id F05728FC14 for ; Sat, 3 Jan 2009 16:27:26 +0000 (UTC) (envelope-from chris@hitnet.RWTH-Aachen.DE) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KCW00EMHKBOX9C0@mta-2.ms.rz.RWTH-Aachen.de> for current@freebsd.org; Sat, 03 Jan 2009 16:57:24 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.36,322,1228086000"; d="diff'?scan'208";a="95317559" Received: from smarthost-2.ms.rz.rwth-aachen.de (HELO smarthost.rwth-aachen.de) ([134.130.7.90]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Sat, 03 Jan 2009 16:57:24 +0100 Received: from bigboss.hitnet.rwth-aachen.de (bigspace.hitnet.RWTH-Aachen.DE [137.226.181.2]) by smarthost.rwth-aachen.de (8.13.8+Sun/8.13.8/1) with ESMTP id n03FvOff002868 for ; Sat, 03 Jan 2009 16:57:24 +0100 (CET) Received: from haakonia.hitnet.rwth-aachen.de ([137.226.181.92]) by bigboss.hitnet.rwth-aachen.de with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1LJ8sO-0003aK-Aw for current@freebsd.org; Sat, 03 Jan 2009 16:57:24 +0100 Received: by haakonia.hitnet.rwth-aachen.de (Postfix, from userid 1001) id 283E63F433; Sat, 03 Jan 2009 16:57:24 +0100 (CET) Date: Sat, 03 Jan 2009 16:57:24 +0100 From: Christian Brueffer To: current@freebsd.org Message-id: <20090103155724.GC1243@haakonia.hitnet.RWTH-Aachen.DE> Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary=Lb0e7rgc7IsuDeGj Content-disposition: inline X-Operating-System: FreeBSD 6.4-STABLE X-PGP-Key: http://people.FreeBSD.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D User-Agent: Mutt/1.5.11 Cc: Subject: CFT: altq support for pcn(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 16:27:27 -0000 --Lb0e7rgc7IsuDeGj Content-Type: multipart/mixed; boundary="cQXOx3fnlpmgJsTP" Content-Disposition: inline --cQXOx3fnlpmgJsTP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi everyone, attached is a patch that adds altq support for the pcn(4) driver. The patch should apply cleanly to HEAD and RELENG_7. The suggested testing procedure is outlined at http://people.freebsd.org/~mlaier/ALTQ_driver/ Feedback welcome. - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --cQXOx3fnlpmgJsTP Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="pcn_altq.diff" Content-Transfer-Encoding: quoted-printable Index: if_pcn.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /data/ncvs/freebsd/src/sys/dev/pcn/if_pcn.c,v retrieving revision 1.1 diff -u -r1.1 if_pcn.c --- if_pcn.c 14 Aug 2008 20:34:46 -0000 1.1 +++ if_pcn.c 2 Jan 2009 20:24:27 -0000 @@ -632,7 +632,9 @@ ifp->if_start =3D pcn_start; ifp->if_watchdog =3D pcn_watchdog; ifp->if_init =3D pcn_init; - ifp->if_snd.ifq_maxlen =3D PCN_TX_LIST_CNT - 1; + IFQ_SET_MAXLEN(&ifp->if_snd, PCN_TX_LIST_CNT - 1); + ifp->if_snd.ifq_drv_maxlen =3D PCN_TX_LIST_CNT - 1; + IFQ_SET_READY(&ifp->if_snd); =20 /* * Do MII setup. @@ -976,7 +978,7 @@ if (!sc->pcn_link && mii->mii_media_status & IFM_ACTIVE && IFM_SUBTYPE(mii->mii_media_active) !=3D IFM_NONE) { sc->pcn_link++; - if (ifp->if_snd.ifq_head !=3D NULL) + if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) pcn_start_locked(ifp); } =20 @@ -1022,7 +1024,7 @@ } } =20 - if (ifp->if_snd.ifq_head !=3D NULL) + if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) pcn_start_locked(ifp); =20 PCN_UNLOCK(sc); @@ -1108,6 +1110,7 @@ struct pcn_softc *sc; struct mbuf *m_head =3D NULL; u_int32_t idx; + int queued =3D 0; =20 sc =3D ifp->if_softc; =20 @@ -1122,16 +1125,18 @@ return; =20 while(sc->pcn_cdata.pcn_tx_chain[idx] =3D=3D NULL) { - IF_DEQUEUE(&ifp->if_snd, m_head); + IFQ_DRV_DEQUEUE(&ifp->if_snd, m_head); if (m_head =3D=3D NULL) break; =20 if (pcn_encap(sc, m_head, &idx)) { - IF_PREPEND(&ifp->if_snd, m_head); + IFQ_DRV_PREPEND(&ifp->if_snd, m_head); ifp->if_drv_flags |=3D IFF_DRV_OACTIVE; break; } =20 + queued++; + /* * If there's a BPF listener, bounce a copy of this frame * to him. @@ -1140,14 +1145,16 @@ =20 } =20 - /* Transmit */ - sc->pcn_cdata.pcn_tx_prod =3D idx; - pcn_csr_write(sc, PCN_CSR_CSR, PCN_CSR_TX|PCN_CSR_INTEN); + if (queued) { + /* Transmit */ + sc->pcn_cdata.pcn_tx_prod =3D idx; + pcn_csr_write(sc, PCN_CSR_CSR, PCN_CSR_TX|PCN_CSR_INTEN); =20 - /* - * Set a timeout in case the chip goes out to lunch. - */ - ifp->if_timer =3D 5; + /* + * Set a timeout in case the chip goes out to lunch. + */ + ifp->if_timer =3D 5; + } =20 return; } @@ -1332,7 +1339,7 @@ pcn_stop(sc); pcn_reset(sc); pcn_init_locked(sc); - if (ifp->if_snd.ifq_head !=3D NULL) + if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) pcn_start_locked(ifp); =20 PCN_UNLOCK(sc); @@ -1445,8 +1452,8 @@ pcn_reset(sc); pcn_init_locked(sc); =20 - if (ifp->if_snd.ifq_head !=3D NULL) + if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) pcn_start(ifp); =20 PCN_UNLOCK(sc); =20 --cQXOx3fnlpmgJsTP-- --Lb0e7rgc7IsuDeGj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFJX4rkbHYXjKDtmC0RAnarAKC2VvJIfLRqmtB7ijoISgdw7KqPXwCg6Vkk fL8iKIrqgyf+OMu+iDW3qoI= =tPwW -----END PGP SIGNATURE----- --Lb0e7rgc7IsuDeGj-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 16:30:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 895B01065670; Sat, 3 Jan 2009 16:30:11 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout014.mac.com (asmtpout014.mac.com [17.148.16.89]) by mx1.freebsd.org (Postfix) with ESMTP id 372658FC19; Sat, 3 Jan 2009 16:30:11 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [192.168.1.96] (75-101-29-67.dsl.static.sonic.net [75.101.29.67]) by asmtp014.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KCW00BT0LU9N200@asmtp014.mac.com>; Sat, 03 Jan 2009 08:30:10 -0800 (PST) Message-id: From: Marcel Moolenaar To: jos@catnook.com In-reply-to: <20090101031634.GD64075@lizzy.catnook.local> Date: Sat, 03 Jan 2009 08:30:08 -0800 References: <3a142e750812201747o339d7298p11236bb02c7f858f@mail.gmail.com> <20081223050425.GA89448@citylink.fud.org.nz> <6D4A57D3-3F6D-43E6-9B69-95514F69C57A@mac.com> <20081226080146.GB25406@dragon.NUXI.org> <20081227191223.GB31177@lizzy.catnook.local> <9F29EF5C-B4FD-4273-8BE9-C134B983A1E1@mac.com> <20090101031634.GD64075@lizzy.catnook.local> X-Mailer: Apple Mail (2.930.3) Cc: freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: Changed names of logical disks on recent -CURRENT: part of logical disks not accessible now X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 16:30:12 -0000 On Dec 31, 2008, at 7:16 PM, Jos Backus wrote: > Hi Marcel, > > On Mon, Dec 29, 2008 at 10:11:03PM -0800, Marcel Moolenaar wrote: >> I've seen this before: Erase the second sector on your >> disk. You likely have a stale BSD disklabel there. > > Before I start erasing, does this look like something that can be > erased > safely? > > lizzy:~# dd if=/dev/ad0 count=1 skip=1 | hexdump -C > 1+0 records in > 1+0 records out > 512 bytes transferred in 0.009828 secs (52096 bytes/sec) > 00000000 57 45 56 82 00 00 00 00 61 6d 6e 65 73 69 61 63 | > WEV.....amnesiac| > 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > |................| > 00000020 00 00 00 00 00 00 00 00 00 02 00 00 3f 00 00 00 > |............?...| > 00000030 10 00 00 00 15 ed 12 00 f0 03 00 00 b0 82 85 4a > |...............J| > 00000040 00 00 00 00 00 00 00 00 10 0e 01 00 00 00 00 00 > |................| > 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > |................| > * > 00000080 00 00 00 00 57 45 56 82 a8 07 08 00 00 20 00 00 > |....WEV...... ..| > 00000090 00 00 00 00 00 00 20 00 10 00 00 00 00 08 00 00 > |...... .........| > 000000a0 07 08 88 6f 00 00 80 00 10 00 20 00 00 00 00 00 > |...o...... .....| > 000000b0 01 00 00 00 b0 82 85 4a 00 00 00 00 00 00 00 00 > |.......J........| > 000000c0 00 00 00 00 00 00 20 00 10 00 a0 00 00 08 00 00 > |...... .........| > 000000d0 07 08 88 6f 00 00 00 04 10 00 c0 00 00 08 00 00 > |...o............| > 000000e0 07 08 88 6f a0 82 c5 45 10 00 c0 04 00 08 00 00 > |...o...E........| > 000000f0 07 08 88 6f 00 00 00 00 00 00 00 00 00 00 00 00 > |...o............| > 00000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > |................| > * > 00000200 > > Or do you mean /dev/ad0s1? (I thought disklabels generally sit > inside fdisk > partitions^Wslices.) > > lizzy:~# dd if=/dev/ad0s1 count=1 skip=1 | hexdump -C > 1+0 records in > 1+0 records out > 512 bytes transferred in 0.016460 secs (31105 bytes/sec) > 00000000 57 45 56 82 00 00 00 00 61 6d 6e 65 73 69 61 63 | > WEV.....amnesiac| > 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > |................| > 00000020 00 00 00 00 00 00 00 00 00 02 00 00 3f 00 00 00 > |............?...| > 00000030 10 00 00 00 14 ed 12 00 f0 03 00 00 71 82 85 4a > |............q..J| > 00000040 00 00 00 00 00 00 00 00 10 0e 01 00 00 00 00 00 > |................| > 00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > |................| > * > 00000080 00 00 00 00 57 45 56 82 68 07 08 00 00 20 00 00 > |....WEV.h.... ..| > 00000090 00 00 00 00 00 00 20 00 10 00 00 00 00 08 00 00 > |...... .........| > 000000a0 07 08 88 6f 00 00 80 00 10 00 20 00 00 00 00 00 > |...o...... .....| > 000000b0 01 00 00 00 71 82 85 4a 00 00 00 00 00 00 00 00 > |....q..J........| > 000000c0 00 00 00 00 00 00 20 00 10 00 a0 00 00 08 00 00 > |...... .........| > 000000d0 07 08 88 6f 00 00 00 04 10 00 c0 00 00 08 00 00 > |...o............| > 000000e0 07 08 88 6f 61 82 c5 45 10 00 c0 04 00 08 00 00 > |...oa..E........| > 000000f0 07 08 88 6f 00 00 00 00 00 00 00 00 00 00 00 00 > |...o............| > 00000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > |................| > 00000110 00 00 00 00 eb 0e 42 54 58 01 02 80 f6 0f 80 06 > |......BTX.......| > 00000120 00 20 00 00 fa 31 c0 8e d0 bc 00 18 8e c0 8e d8 |. ... > 1..........| > 00000130 66 6a 02 66 9d bf 00 5e b9 00 19 f3 ab bb 22 95 | > fj.f...^......".| > 00000140 b9 10 00 bf 80 00 89 1d 47 47 ab 83 c3 04 e2 f6 > |........GG......| > 00000150 bf 00 5e be d2 95 ac 98 91 e3 1d ac 92 ad 93 ad > |..^.............| > 00000160 b6 08 d1 eb 73 0b 89 05 88 75 02 88 55 05 83 c0 > |....s....u..U...| > 00000170 04 8d 7d 08 e2 ec eb de c6 45 05 18 c6 45 08 10 > |..}......E...E..| > 00000180 c6 45 66 68 bb 20 28 e8 b8 00 0f 01 1e c6 95 0f |.Efh. > (.........| > 00000190 01 16 c0 95 0f 20 c0 40 0f 22 c0 ea 8c 90 08 00 > |..... .@."......| > 000001a0 31 c9 b1 10 8e d1 b1 38 0f 00 d9 ba 00 a0 00 00 | > 1......8........| > 000001b0 36 0f b7 05 13 04 00 00 c1 e0 0a 2d 00 10 00 00 | > 6..........-....| > 000001c0 29 d0 b1 33 51 50 68 02 02 00 00 6a 2b ff 35 0c |).. > 3QPh....j+.5.| > 000001d0 90 00 00 51 51 51 51 52 b1 07 6a 00 e2 fc 61 07 > |...QQQQR..j...a.| > 000001e0 1f 0f a1 0f a9 cf fa bc 00 18 00 00 0f 20 c0 25 > |............. .%| > 000001f0 ff ff ff 7f 0f 22 c0 31 c9 0f 22 d9 0f 01 15 c0 |.....". > 1..".....| > 00000200 > > Thanks and Happy New Year! Hi Jos, "dd if=/dev/zero of=/dev/ad0 count=1 oseek=1" is what you need. As you say, the BSD disklabel lives in the slice, so the one in sector 1 (counting from 0) is the stale one and the one preventing you from booting. Happy New Year to you (and Trish) too, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 16:05:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 795E21065670 for ; Sat, 3 Jan 2009 16:05:51 +0000 (UTC) (envelope-from need4spam@bk.ru) Received: from mx44.mail.ru (mx44.mail.ru [195.239.211.10]) by mx1.freebsd.org (Postfix) with ESMTP id 6B6B08FC17 for ; Sat, 3 Jan 2009 16:05:50 +0000 (UTC) (envelope-from need4spam@bk.ru) Received: from f79.mail.ru (f79.mail.ru [194.67.57.179]) by mx44.mail.ru (mPOP.Fallback_MX) with ESMTP id 4657238000800 for ; Sat, 3 Jan 2009 04:10:28 +0300 (MSK) Received: from mail by f79.mail.ru with local id 1LIv22-0002Nt-00 for freebsd-current@freebsd.org; Sat, 03 Jan 2009 04:10:26 +0300 Received: from [62.182.89.99] by win.mail.ru with HTTP; Sat, 03 Jan 2009 04:10:26 +0300 From: Alexey Ivanov To: freebsd-current@freebsd.org Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [62.182.89.99] Date: Sat, 03 Jan 2009 04:10:26 +0300 Content-Type: multipart/mixed; boundary="----ZsXlibyD-b3u64zfXGPVq6btq:1230945026" Message-Id: X-Spam: Not detected X-Mras: Ok X-Mailman-Approved-At: Sat, 03 Jan 2009 16:48:23 +0000 Subject: Can not build r186708 -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alexey Ivanov List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 16:05:51 -0000 ------ZsXlibyD-b3u64zfXGPVq6btq:1230945026 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit last time I've updated my FreeBSD was [PH34R] ~> uname -a FreeBSD PH34R 8.0-CURRENT FreeBSD 8.0-CURRENT #14: Mon Dec 22 13:09:06 MSK 2008 savetherbtz@PH34R:/usr/obj/usr/src/sys/PH34R.8 i386 Now after cvsup I have ... .... awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/acpica/acpi_if.m -h rm -f .newdep make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -march=athlon-mp -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/dev/ath -I/usr/src/sys/dev/ath/ath_hal -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -I/usr/src/sys/gnu/fs/xfs/FreeBSD -I/usr/src/sys/gnu/fs/xfs/FreeBSD/support -I/usr/src/sys/gnu/fs/xfs -I/usr/src/sys/contrib/opensolaris/compat -I/usr/src/sys/dev/cxgb -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestand ing -fstack-protector /usr/src/sys/compat/ndis/subr_usbd.c:64:21: error: usbdevs.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/obj/usr/src/sys/PH34R.8. *** Error code 1 Stop in /usr/src. *** Error code 1 KERNCONF attached ------ZsXlibyD-b3u64zfXGPVq6btq:1230945026 Content-Type: application/octet-stream; name="PH34R.8" Content-Disposition: attachment; filename="PH34R.8" Content-Transfer-Encoding: base64 Y3B1CQlJNjg2X0NQVQppZGVudAkJUEgzNFIKCiMgVG8gc3RhdGljYWxseSBjb21waWxlIGluIGRl dmljZSB3aXJpbmcgaW5zdGVhZCBvZiAvYm9vdC9kZXZpY2UuaGludHMKI2hpbnRzCQkiR0VORVJJ Qy5oaW50cyIJCSMgRGVmYXVsdCBwbGFjZXMgdG8gbG9vayBmb3IgZGV2aWNlcy4KCiNtYWtlb3B0 aW9ucwlERUJVRz0tZwkJIyBCdWlsZCBrZXJuZWwgd2l0aCBnZGIoMSkgZGVidWcgc3ltYm9scwoK b3B0aW9ucyAJU0NIRURfVUxFCQkjIFVMRSBzY2hlZHVsZXIKb3B0aW9ucyAJUFJFRU1QVElPTgkJ IyBFbmFibGUga2VybmVsIHRocmVhZCBwcmVlbXB0aW9uCm9wdGlvbnMgCUlORVQJCQkjIEludGVy TkVUd29ya2luZwpvcHRpb25zIAlJTkVUNgkJCSMgSVB2NiBjb21tdW5pY2F0aW9ucyBwcm90b2Nv bHMKb3B0aW9ucyAJU0NUUAkJCSMgU3RyZWFtIENvbnRyb2wgVHJhbnNtaXNzaW9uIFByb3RvY29s Cm9wdGlvbnMgCUZGUwkJCSMgQmVya2VsZXkgRmFzdCBGaWxlc3lzdGVtCm9wdGlvbnMgCVNPRlRV UERBVEVTCQkjIEVuYWJsZSBGRlMgc29mdCB1cGRhdGVzIHN1cHBvcnQKb3B0aW9ucyAJVUZTX0FD TAkJCSMgU3VwcG9ydCBmb3IgYWNjZXNzIGNvbnRyb2wgbGlzdHMKb3B0aW9ucyAJVUZTX0RJUkhB U0gJCSMgSW1wcm92ZSBwZXJmb3JtYW5jZSBvbiBiaWcgZGlyZWN0b3JpZXMKb3B0aW9ucyAJVUZT X0dKT1VSTkFMCQkjIEVuYWJsZSBnam91cm5hbC1iYXNlZCBVRlMgam91cm5hbGluZwpvcHRpb25z IAlNRF9ST09UCQkJIyBNRCBpcyBhIHBvdGVudGlhbCByb290IGRldmljZQpvcHRpb25zIAlORlND TElFTlQJCSMgTmV0d29yayBGaWxlc3lzdGVtIENsaWVudApvcHRpb25zIAlORlNTRVJWRVIJCSMg TmV0d29yayBGaWxlc3lzdGVtIFNlcnZlcgpvcHRpb25zIAlORlNMT0NLRAkJIyBOZXR3b3JrIExv Y2sgTWFuYWdlcgpvcHRpb25zIAlORlNfUk9PVAkJIyBORlMgdXNhYmxlIGFzIC8sIHJlcXVpcmVz IE5GU0NMSUVOVApvcHRpb25zIAlNU0RPU0ZTCQkJIyBNU0RPUyBGaWxlc3lzdGVtCm9wdGlvbnMg CUNEOTY2MAkJCSMgSVNPIDk2NjAgRmlsZXN5c3RlbQpvcHRpb25zIAlQUk9DRlMJCQkjIFByb2Nl c3MgZmlsZXN5c3RlbSAocmVxdWlyZXMgUFNFVURPRlMpCm9wdGlvbnMgCVBTRVVET0ZTCQkjIFBz ZXVkby1maWxlc3lzdGVtIGZyYW1ld29yawpvcHRpb25zIAlHRU9NX1BBUlRfR1BUCQkjIEdVSUQg UGFydGl0aW9uIFRhYmxlcy4Kb3B0aW9ucyAJR0VPTV9MQUJFTAkJIyBQcm92aWRlcyBsYWJlbGl6 YXRpb24Kb3B0aW9ucyAJQ09NUEFUXzQzVFRZCQkjIEJTRCA0LjMgVFRZIGNvbXBhdCBbS0VFUCBU SElTIV0Kb3B0aW9ucyAJQ09NUEFUX0ZSRUVCU0Q0CQkjIENvbXBhdGlibGUgd2l0aCBGcmVlQlNE NApvcHRpb25zIAlDT01QQVRfRlJFRUJTRDUJCSMgQ29tcGF0aWJsZSB3aXRoIEZyZWVCU0Q1Cm9w dGlvbnMgCUNPTVBBVF9GUkVFQlNENgkJIyBDb21wYXRpYmxlIHdpdGggRnJlZUJTRDYKb3B0aW9u cyAJQ09NUEFUX0ZSRUVCU0Q3CQkjIENvbXBhdGlibGUgd2l0aCBGcmVlQlNENwpvcHRpb25zIAlT Q1NJX0RFTEFZPTUwMDAJCSMgRGVsYXkgKGluIG1zKSBiZWZvcmUgcHJvYmluZyBTQ1NJCm9wdGlv bnMgCUtUUkFDRQkJCSMga3RyYWNlKDEpIHN1cHBvcnQKb3B0aW9ucyAJU1RBQ0sJCQkjIHN0YWNr KDkpIHN1cHBvcnQKb3B0aW9ucyAJU1lTVlNITQkJCSMgU1lTVi1zdHlsZSBzaGFyZWQgbWVtb3J5 Cm9wdGlvbnMgCVNZU1ZNU0cJCQkjIFNZU1Ytc3R5bGUgbWVzc2FnZSBxdWV1ZXMKb3B0aW9ucyAJ U1lTVlNFTQkJCSMgU1lTVi1zdHlsZSBzZW1hcGhvcmVzCm9wdGlvbnMgCV9LUE9TSVhfUFJJT1JJ VFlfU0NIRURVTElORyAjIFBPU0lYIFAxMDAzXzFCIHJlYWwtdGltZSBleHRlbnNpb25zCm9wdGlv bnMgCUtCRF9JTlNUQUxMX0NERVYJIyBpbnN0YWxsIGEgQ0RFViBlbnRyeSBpbiAvZGV2Cm9wdGlv bnMgCVNUT1BfTk1JCQkjIFN0b3AgQ1BVUyB1c2luZyBOTUkgaW5zdGVhZCBvZiBJUEkKb3B0aW9u cyAgCUhXUE1DX0hPT0tTCQkjIE5lY2Vzc2FyeSBrZXJuZWwgaG9va3MgZm9yIGh3cG1jKDQpCm9w dGlvbnMgCUFVRElUCQkJIyBTZWN1cml0eSBldmVudCBhdWRpdGluZwoKIyBEZWJ1Z2dpbmcgZm9y IHVzZSBpbiAtY3VycmVudAojb3B0aW9ucyAJS0RCCQkJIyBFbmFibGUga2VybmVsIGRlYnVnZ2Vy IHN1cHBvcnQuCiNvcHRpb25zIAlEREIJCQkjIFN1cHBvcnQgRERCLgojb3B0aW9ucyAJR0RCCQkJ IyBTdXBwb3J0IHJlbW90ZSBHREIuCiNvcHRpb25zIAlJTlZBUklBTlRTCQkjIEVuYWJsZSBjYWxs cyBvZiBleHRyYSBzYW5pdHkgY2hlY2tpbmcKI29wdGlvbnMgCUlOVkFSSUFOVF9TVVBQT1JUCSMg RXh0cmEgc2FuaXR5IGNoZWNrcyBvZiBpbnRlcm5hbCBzdHJ1Y3R1cmVzLCByZXF1aXJlZCBieSBJ TlZBUklBTlRTCiNvcHRpb25zIAlXSVRORVNTCQkJIyBFbmFibGUgY2hlY2tzIHRvIGRldGVjdCBk ZWFkbG9ja3MgYW5kIGN5Y2xlcwojb3B0aW9ucyAJV0lUTkVTU19TS0lQU1BJTgkjIERvbid0IHJ1 biB3aXRuZXNzIG9uIHNwaW5sb2NrcyBmb3Igc3BlZWQKCiMgVG8gbWFrZSBhbiBTTVAga2VybmVs LCB0aGUgbmV4dCB0d28gbGluZXMgYXJlIG5lZWRlZApvcHRpb25zIAlTTVAJCQkjIFN5bW1ldHJp YyBNdWx0aVByb2Nlc3NvciBLZXJuZWwKZGV2aWNlCQlhcGljCQkJIyBJL08gQVBJQwoKIyBDUFUg ZnJlcXVlbmN5IGNvbnRyb2wKZGV2aWNlCQljcHVmcmVxCgojIEJ1cyBzdXBwb3J0LgpkZXZpY2UJ CWFjcGkKI2RldmljZQkJZWlzYQpkZXZpY2UJCXBjaQoKIyBGbG9wcHkgZHJpdmVzCiNkZXZpY2UJ CWZkYwoKIyBBVEEgYW5kIEFUQVBJIGRldmljZXMKZGV2aWNlCQlhdGEKZGV2aWNlCQlhdGFkaXNr CQkjIEFUQSBkaXNrIGRyaXZlcwpkZXZpY2UJCWF0YXJhaWQJCSMgQVRBIFJBSUQgZHJpdmVzCmRl dmljZQkJYXRhcGljZAkJIyBBVEFQSSBDRFJPTSBkcml2ZXMKZGV2aWNlCQlhdGFwaWZkCQkjIEFU QVBJIGZsb3BweSBkcml2ZXMKZGV2aWNlCQlhdGFwaXN0CQkjIEFUQVBJIHRhcGUgZHJpdmVzCm9w dGlvbnMgCUFUQV9TVEFUSUNfSUQJIyBTdGF0aWMgZGV2aWNlIG51bWJlcmluZwoKIyBTQ1NJIENv bnRyb2xsZXJzCmRldmljZQkJYWhiCQkjIEVJU0EgQUhBMTc0MiBmYW1pbHkKZGV2aWNlCQlhaGMJ CSMgQUhBMjk0MCBhbmQgb25ib2FyZCBBSUM3eHh4IGRldmljZXMKb3B0aW9ucyAJQUhDX1JFR19Q UkVUVFlfUFJJTlQJIyBQcmludCByZWdpc3RlciBiaXRmaWVsZHMgaW4gZGVidWcKCQkJCQkjIG91 dHB1dC4gIEFkZHMgfjEyOGsgdG8gZHJpdmVyLgpkZXZpY2UJCWFoZAkJIyBBSEEzOTMyMC8yOTMy MCBhbmQgb25ib2FyZCBBSUM3OXh4IGRldmljZXMKb3B0aW9ucyAJQUhEX1JFR19QUkVUVFlfUFJJ TlQJIyBQcmludCByZWdpc3RlciBiaXRmaWVsZHMgaW4gZGVidWcKCQkJCQkjIG91dHB1dC4gIEFk ZHMgfjIxNWsgdG8gZHJpdmVyLgpkZXZpY2UJCWFtZAkJIyBBTUQgNTNDOTc0IChUZWtyYW0gREMt MzkwKFQpKQpkZXZpY2UJCWhwdGlvcAkJIyBIaWdocG9pbnQgUm9ja2V0UmFpZCAzeHh4IHNlcmll cwpkZXZpY2UJCWlzcAkJIyBRbG9naWMgZmFtaWx5CiNkZXZpY2UgCWlzcGZ3CQkjIEZpcm13YXJl IGZvciBRTG9naWMgSEJBcy0gbm9ybWFsbHkgYSBtb2R1bGUKZGV2aWNlCQltcHQJCSMgTFNJLUxv Z2ljIE1QVC1GdXNpb24KI2RldmljZQkJbmNyCQkjIE5DUi9TeW1iaW9zIExvZ2ljCmRldmljZQkJ c3ltCQkjIE5DUi9TeW1iaW9zIExvZ2ljIChuZXdlciBjaGlwc2V0cyArIHRob3NlIG9mIGBuY3In KQpkZXZpY2UJCXRybQkJIyBUZWtyYW0gREMzOTVVL1VXL0YgREMzMTVVIGFkYXB0ZXJzCgpkZXZp Y2UJCWFkdgkJIyBBZHZhbnN5cyBTQ1NJIGFkYXB0ZXJzCmRldmljZQkJYWR3CQkjIEFkdmFuc3lz IHdpZGUgU0NTSSBhZGFwdGVycwpkZXZpY2UJCWFoYQkJIyBBZGFwdGVjIDE1NHggU0NTSSBhZGFw dGVycwpkZXZpY2UJCWFpYwkJIyBBZGFwdGVjIDE1WzAxMl14IFNDU0kgYWRhcHRlcnMsIEFJQy02 WzIzXTYwLgpkZXZpY2UJCWJ0CQkjIEJ1c2xvZ2ljL015bGV4IE11bHRpTWFzdGVyIFNDU0kgYWRh cHRlcnMKCmRldmljZQkJbmN2CQkjIE5DUiA1M0M1MDAKZGV2aWNlCQluc3AJCSMgV29ya2JpdCBO aW5qYSBTQ1NJLTMKZGV2aWNlCQlzdGcJCSMgVE1DIDE4QzMwLzE4QzUwCgojIFNDU0kgcGVyaXBo ZXJhbHMKZGV2aWNlCQlzY2J1cwkJIyBTQ1NJIGJ1cyAocmVxdWlyZWQgZm9yIFNDU0kpCmRldmlj ZQkJY2gJCSMgU0NTSSBtZWRpYSBjaGFuZ2VycwpkZXZpY2UJCWRhCQkjIERpcmVjdCBBY2Nlc3Mg KGRpc2tzKQpkZXZpY2UJCXNhCQkjIFNlcXVlbnRpYWwgQWNjZXNzICh0YXBlIGV0YykKZGV2aWNl CQljZAkJIyBDRApkZXZpY2UJCXBhc3MJCSMgUGFzc3Rocm91Z2ggZGV2aWNlIChkaXJlY3QgU0NT SSBhY2Nlc3MpCmRldmljZQkJc2VzCQkjIFNDU0kgRW52aXJvbm1lbnRhbCBTZXJ2aWNlcyAoYW5k IFNBRi1URSkKCiMgUkFJRCBjb250cm9sbGVycyBpbnRlcmZhY2VkIHRvIHRoZSBTQ1NJIHN1YnN5 c3RlbQojZGV2aWNlCQlhbXIJCSMgQU1JIE1lZ2FSQUlECiNkZXZpY2UJCWFyY21zcgkJIyBBcmVj YSBTQVRBIElJIFJBSUQKI2RldmljZQkJYXNyCQkjIERQVCBTbWFydFJBSUQgViwgVkkgYW5kIEFk YXB0ZWMgU0NTSSBSQUlECiNkZXZpY2UJCWNpc3MJCSMgQ29tcGFxIFNtYXJ0IFJBSUQgNSoKI2Rl dmljZQkJZHB0CQkjIERQVCBTbWFydGNhY2hlIElJSSwgSVYgLSBTZWUgTk9URVMgZm9yIG9wdGlv bnMKI2RldmljZQkJaHB0bXYJCSMgSGlnaHBvaW50IFJvY2tldFJBSUQgMTgyeAojZGV2aWNlCQlo cHRycgkJIyBIaWdocG9pbnQgUm9ja2V0UkFJRCAxN3h4LCAyMnh4LCAyM3h4LCAyNXh4CiNkZXZp Y2UJCWlpcgkJIyBJbnRlbCBJbnRlZ3JhdGVkIFJBSUQKI2RldmljZQkJaXBzCQkjIElCTSAoQWRh cHRlYykgU2VydmVSQUlECiNkZXZpY2UJCW1seQkJIyBNeWxleCBBY2NlbGVSQUlEL2VYdHJlbWVS QUlECiNkZXZpY2UJCXR3YQkJIyAzd2FyZSA5MDAwIHNlcmllcyBQQVRBL1NBVEEgUkFJRAoKIyBS QUlEIGNvbnRyb2xsZXJzCiNkZXZpY2UJCWFhYwkJIyBBZGFwdGVjIEZTQSBSQUlECiNkZXZpY2UJ CWFhY3AJCSMgU0NTSSBwYXNzdGhyb3VnaCBmb3IgYWFjIChyZXF1aXJlcyBDQU0pCiNkZXZpY2UJ CWlkYQkJIyBDb21wYXEgU21hcnQgUkFJRAojZGV2aWNlCQltZmkJCSMgTFNJIE1lZ2FSQUlEIFNB UwojZGV2aWNlCQltbHgJCSMgTXlsZXggREFDOTYwIGZhbWlseQojZGV2aWNlCQlwc3QJCSMgUHJv bWlzZSBTdXBlcnRyYWsgU1g2MDAwCiNkZXZpY2UJCXR3ZQkJIyAzd2FyZSBBVEEgUkFJRAoKIyBh dGtiZGMwIGNvbnRyb2xzIGJvdGggdGhlIGtleWJvYXJkIGFuZCB0aGUgUFMvMiBtb3VzZQpkZXZp Y2UJCWF0a2JkYwkJIyBBVCBrZXlib2FyZCBjb250cm9sbGVyCmRldmljZQkJYXRrYmQJCSMgQVQg a2V5Ym9hcmQKZGV2aWNlCQlwc20JCSMgUFMvMiBtb3VzZQoKZGV2aWNlCQlrYmRtdXgJCSMga2V5 Ym9hcmQgbXVsdGlwbGV4ZXIKCmRldmljZQkJdmdhCQkjIFZHQSB2aWRlbyBjYXJkIGRyaXZlcgoK ZGV2aWNlCQlzcGxhc2gJCSMgU3BsYXNoIHNjcmVlbiBhbmQgc2NyZWVuIHNhdmVyIHN1cHBvcnQK CiMgc3lzY29ucyBpcyB0aGUgZGVmYXVsdCBjb25zb2xlIGRyaXZlciwgcmVzZW1ibGluZyBhbiBT Q08gY29uc29sZQpkZXZpY2UJCXNjCgpkZXZpY2UJCWFncAkJIyBzdXBwb3J0IHNldmVyYWwgQUdQ IGNoaXBzZXRzCgojIFBvd2VyIG1hbmFnZW1lbnQgc3VwcG9ydCAoc2VlIE5PVEVTIGZvciBtb3Jl IG9wdGlvbnMpCmRldmljZQkJYXBtCiMgQWRkIHN1c3BlbmQvcmVzdW1lIHN1cHBvcnQgZm9yIHRo ZSBpODI1NC4KZGV2aWNlCQlwbXRpbWVyCgojIFBDQ0FSRCAoUENNQ0lBKSBzdXBwb3J0CiMgUENN Q0lBIGFuZCBjYXJkYnVzIGJyaWRnZSBzdXBwb3J0CmRldmljZQkJY2JiCQkjIGNhcmRidXMgKHll bnRhKSBicmlkZ2UKZGV2aWNlCQlwY2NhcmQJCSMgUEMgQ2FyZCAoMTYtYml0KSBidXMKZGV2aWNl CQljYXJkYnVzCQkjIENhcmRCdXMgKDMyLWJpdCkgYnVzCgojIFNlcmlhbCAoQ09NKSBwb3J0cwpk ZXZpY2UJCXVhcnQJCSMgR2VuZXJpYyBVQVJUIGRyaXZlcgoKIyBQYXJhbGxlbCBwb3J0CmRldmlj ZQkJcHBjCmRldmljZQkJcHBidXMJCSMgUGFyYWxsZWwgcG9ydCBidXMgKHJlcXVpcmVkKQpkZXZp Y2UJCWxwdAkJIyBQcmludGVyCmRldmljZQkJcGxpcAkJIyBUQ1AvSVAgb3ZlciBwYXJhbGxlbApk ZXZpY2UJCXBwaQkJIyBQYXJhbGxlbCBwb3J0IGludGVyZmFjZSBkZXZpY2UKI2RldmljZQkJdnBv CQkjIFJlcXVpcmVzIHNjYnVzIGFuZCBkYQoKIyBJZiB5b3UndmUgZ290IGEgImR1bWIiIHNlcmlh bCBvciBwYXJhbGxlbCBQQ0kgY2FyZCB0aGF0IGlzCiMgc3VwcG9ydGVkIGJ5IHRoZSBwdWMoNCkg Z2x1ZSBkcml2ZXIsIHVuY29tbWVudCB0aGUgZm9sbG93aW5nCiMgbGluZSB0byBlbmFibGUgaXQg KGNvbm5lY3RzIHRvIHNpbywgdWFydCBhbmQvb3IgcHBjIGRyaXZlcnMpOgojZGV2aWNlCQlwdWMK CiMgUENJIEV0aGVybmV0IE5JQ3MuCiNkZXZpY2UJCWRlCQkjIERFQy9JbnRlbCBEQzIxeDR4IChg YFR1bGlwJycpCiNkZXZpY2UJCWVtCQkjIEludGVsIFBSTy8xMDAwIEdpZ2FiaXQgRXRoZXJuZXQg RmFtaWx5CiNkZXZpY2UJCWlnYgkJIyBJbnRlbCBQUk8vMTAwMCBQQ0lFIFNlcnZlciBHaWdhYml0 IEZhbWlseQojZGV2aWNlCQlpeGdiCQkjIEludGVsIFBSTy8xMEdiRSBFdGhlcm5ldCBDYXJkCiNk ZXZpY2UJCWxlCQkjIEFNRCBBbTc5MDAgTEFOQ0UgYW5kIEFtNzlDOXh4IFBDbmV0CiNkZXZpY2UJ CXRpCQkjIEFsdGVvbiBOZXR3b3JrcyBUaWdvbiBJL0lJIGdpZ2FiaXQgRXRoZXJuZXQKI2Rldmlj ZQkJdHhwCQkjIDNDb20gM2NSOTkwIChgYFR5cGhvb24nJykKI2RldmljZQkJdngJCSMgM0NvbSAz YzU5MCwgM2M1OTUgKGBgVm9ydGV4JycpCgojIFBDSSBFdGhlcm5ldCBOSUNzIHRoYXQgdXNlIHRo ZSBjb21tb24gTUlJIGJ1cyBjb250cm9sbGVyIGNvZGUuCiMgTk9URTogQmUgc3VyZSB0byBrZWVw IHRoZSAnZGV2aWNlIG1paWJ1cycgbGluZSBpbiBvcmRlciB0byB1c2UgdGhlc2UgTklDcyEKZGV2 aWNlCQltaWlidXMJCSMgTUlJIGJ1cyBzdXBwb3J0CiNkZXZpY2UJCWFlCQkjIEF0dGFuc2ljL0F0 aGVyb3MgTDIgRmFzdEV0aGVybmV0CiNkZXZpY2UJCWFnZQkJIyBBdHRhbnNpYy9BdGhlcm9zIEwx IEdpZ2FiaXQgRXRoZXJuZXQKI2RldmljZQkJYmNlCQkjIEJyb2FkY29tIEJDTTU3MDYvQkNNNTcw OCBHaWdhYml0IEV0aGVybmV0CiNkZXZpY2UJCWJmZQkJIyBCcm9hZGNvbSBCQ000NDB4IDEwLzEw MCBFdGhlcm5ldApkZXZpY2UJCWJnZQkJIyBCcm9hZGNvbSBCQ001NzB4eCBHaWdhYml0IEV0aGVy bmV0CiNkZXZpY2UJCWRjCQkjIERFQy9JbnRlbCAyMTE0MyBhbmQgdmFyaW91cyB3b3JrYWxpa2Vz CiNkZXZpY2UJCWV0CQkjIEFnZXJlIEVUMTMxMCAxMC8xMDAvR2lnYWJpdCBFdGhlcm5ldAojZGV2 aWNlCQlmeHAJCSMgSW50ZWwgRXRoZXJFeHByZXNzIFBSTy8xMDBCICg4MjU1NywgODI1NTgpCiNk ZXZpY2UJCWptZQkJIyBKTWljcm9uIEpNQzI1MCBHaWdhYml0L0pNQzI2MCBGYXN0IEV0aGVybmV0 CiNkZXZpY2UJCWxnZQkJIyBMZXZlbCAxIExYVDEwMDEgZ2lnYWJpdCBFdGhlcm5ldAojZGV2aWNl CQltc2sJCSMgTWFydmVsbC9TeXNLb25uZWN0IFl1a29uIElJIEdpZ2FiaXQgRXRoZXJuZXQKI2Rl dmljZQkJbmZlCQkjIG5WaWRpYSBuRm9yY2UgTUNQIG9uLWJvYXJkIEV0aGVybmV0CiNkZXZpY2UJ CW5nZQkJIyBOYXRTZW1pIERQODM4MjAgZ2lnYWJpdCBFdGhlcm5ldAojZGV2aWNlCQludmUJCSMg blZpZGlhIG5Gb3JjZSBNQ1Agb24tYm9hcmQgRXRoZXJuZXQgTmV0d29ya2luZwojZGV2aWNlCQlw Y24JCSMgQU1EIEFtNzlDOTd4IFBDSSAxMC8xMDAgKHByZWNlZGVuY2Ugb3ZlciAnbGUnKQojZGV2 aWNlCQlyZQkJIyBSZWFsVGVrIDgxMzlDKy84MTY5LzgxNjlTLzgxMTBTCiNkZXZpY2UJCXJsCQkj IFJlYWxUZWsgODEyOS84MTM5CiNkZXZpY2UJCXNmCQkjIEFkYXB0ZWMgQUlDLTY5MTUgKGBgU3Rh cmZpcmUnJykKI2RldmljZQkJc2lzCQkjIFNpbGljb24gSW50ZWdyYXRlZCBTeXN0ZW1zIFNpUyA5 MDAvU2lTIDcwMTYKI2RldmljZQkJc2sJCSMgU3lzS29ubmVjdCBTSy05ODR4ICYgU0stOTgyeCBn aWdhYml0IEV0aGVybmV0CiNkZXZpY2UJCXN0ZQkJIyBTdW5kYW5jZSBTVDIwMSAoRC1MaW5rIERG RS01NTBUWCkKI2RldmljZQkJc3RnZQkJIyBTdW5kYW5jZS9UYW1hcmFjayBUQzkwMjEgZ2lnYWJp dCBFdGhlcm5ldAojZGV2aWNlCQl0bAkJIyBUZXhhcyBJbnN0cnVtZW50cyBUaHVuZGVyTEFOCiNk ZXZpY2UJCXR4CQkjIFNNQyBFdGhlclBvd2VyIElJICg4M2MxNzAgYGBFUElDJycpCiNkZXZpY2UJ CXZnZQkJIyBWSUEgVlQ2MTJ4IGdpZ2FiaXQgRXRoZXJuZXQKI2RldmljZQkJdnIJCSMgVklBIFJo aW5lLCBSaGluZSBJSQojZGV2aWNlCQl3YgkJIyBXaW5ib25kIFc4OUM4NDBGCiNkZXZpY2UJCXhs CQkjIDNDb20gM2M5MHggKGBgQm9vbWVyYW5nJycsIGBgQ3ljbG9uZScnKQoKIyBJU0EgRXRoZXJu ZXQgTklDcy4gIHBjY2FyZCBOSUNzIGluY2x1ZGVkLgojZGV2aWNlCQljcwkJIyBDcnlzdGFsIFNl bWljb25kdWN0b3IgQ1M4OXgwIE5JQwojICdkZXZpY2UgZWQnIHJlcXVpcmVzICdkZXZpY2UgbWlp YnVzJwojZGV2aWNlCQllZAkJIyBORVsxMl0wMDAsIFNNQyBVbHRyYSwgM2M1MDMsIERTODM5MCBj YXJkcwojZGV2aWNlCQlleAkJIyBJbnRlbCBFdGhlckV4cHJlc3MgUHJvLzEwIGFuZCBQcm8vMTAr CiNkZXZpY2UJCWVwCQkjIEV0aGVybGluayBJSUkgYmFzZWQgY2FyZHMKI2RldmljZQkJZmUJCSMg RnVqaXRzdSBNQjg2OTZ4IGJhc2VkIGNhcmRzCiNkZXZpY2UJCWllCQkjIEV0aGVyRXhwcmVzcyA4 LzE2LCAzQzUwNywgU3RhckxBTiAxMCBldGMuCiNkZXZpY2UJCXNuCQkjIFNNQydzIDkwMDAgc2Vy aWVzIG9mIEV0aGVybmV0IGNoaXBzCiNkZXZpY2UJCXhlCQkjIFhpcmNvbSBwY2NhcmQgRXRoZXJu ZXQKCiMgV2lyZWxlc3MgTklDIGNhcmRzCmRldmljZQkJd2xhbgkJIyA4MDIuMTEgc3VwcG9ydApv cHRpb25zIAlJRUVFODAyMTFfREVCVUcJIyBlbmFibGUgZGVidWcgbXNncwpvcHRpb25zIAlJRUVF ODAyMTFfQU1QRFVfQUdFICMgYWdlIGZyYW1lcyBpbiBBTVBEVSByZW9yZGVyIHEncwpkZXZpY2UJ CXdsYW5fd2VwCSMgODAyLjExIFdFUCBzdXBwb3J0CmRldmljZQkJd2xhbl9jY21wCSMgODAyLjEx IENDTVAgc3VwcG9ydApkZXZpY2UJCXdsYW5fdGtpcAkjIDgwMi4xMSBUS0lQIHN1cHBvcnQKZGV2 aWNlCQl3bGFuX2FtcnIJIyBBTVJSIHRyYW5zbWl0IHJhdGUgY29udHJvbCBhbGdvcml0aG0KI2Rl dmljZQkJYW4JCSMgQWlyb25ldCA0NTAwLzQ4MDAgODAyLjExIHdpcmVsZXNzIE5JQ3MuCiNkZXZp Y2UJCWF0aAkJIyBBdGhlcm9zIHBjaS9jYXJkYnVzIE5JQydzCiNkZXZpY2UJCWF0aF9oYWwJCSMg QXRoZXJvcyBIQUwgKEhhcmR3YXJlIEFjY2VzcyBMYXllcikKI2RldmljZQkJYXRoX3JhdGVfc2Ft cGxlCSMgU2FtcGxlUmF0ZSB0eCByYXRlIGNvbnRyb2wgZm9yIGF0aAojZGV2aWNlCQlyYWwJCSMg UmFsaW5rIFRlY2hub2xvZ3kgUlQyNTAwIHdpcmVsZXNzIE5JQ3MuCiNkZXZpY2UJCXdpCQkjIFdh dmVMQU4vSW50ZXJzaWwvU3ltYm9sIDgwMi4xMSB3aXJlbGVzcyBOSUNzLgojZGV2aWNlCQl3bAkJ IyBPbGRlciBub24gODAyLjExIFdhdmVsYW4gd2lyZWxlc3MgTklDLgoKIyBQc2V1ZG8gZGV2aWNl cy4KZGV2aWNlCQlsb29wCQkjIE5ldHdvcmsgbG9vcGJhY2sKZGV2aWNlCQlyYW5kb20JCSMgRW50 cm9weSBkZXZpY2UKZGV2aWNlCQlldGhlcgkJIyBFdGhlcm5ldCBzdXBwb3J0CmRldmljZQkJdHVu CQkjIFBhY2tldCB0dW5uZWwuCmRldmljZQkJcHR5CQkjIEJTRC1zdHlsZSBjb21wYXRpYmlsaXR5 IHBzZXVkbyB0dHlzCmRldmljZQkJbWQJCSMgTWVtb3J5ICJkaXNrcyIKZGV2aWNlCQlnaWYJCSMg SVB2NiBhbmQgSVB2NCB0dW5uZWxpbmcKZGV2aWNlCQlmYWl0aAkJIyBJUHY2LXRvLUlQdjQgcmVs YXlpbmcgKHRyYW5zbGF0aW9uKQpkZXZpY2UJCWZpcm13YXJlCSMgZmlybXdhcmUgYXNzaXN0IG1v ZHVsZQoKIyBUaGUgYGJwZicgZGV2aWNlIGVuYWJsZXMgdGhlIEJlcmtlbGV5IFBhY2tldCBGaWx0 ZXIuCiMgQmUgYXdhcmUgb2YgdGhlIGFkbWluaXN0cmF0aXZlIGNvbnNlcXVlbmNlcyBvZiBlbmFi bGluZyB0aGlzIQojIE5vdGUgdGhhdCAnYnBmJyBpcyByZXF1aXJlZCBmb3IgREhDUC4KZGV2aWNl CQlicGYJCSMgQmVya2VsZXkgcGFja2V0IGZpbHRlcgoKIyBVU0IgY29yZSBzdXBwb3J0CmRldmlj ZSAgICAgICAgICB1c2IyX2NvcmUKCiMgVVNCIGNvbnRyb2xsZXIgc3VwcG9ydApkZXZpY2UgICAg ICAgICAgdXNiMl9jb250cm9sbGVyCmRldmljZSAgICAgICAgICB1c2IyX2NvbnRyb2xsZXJfZWhj aQpkZXZpY2UgICAgICAgICAgdXNiMl9jb250cm9sbGVyX29oY2kKZGV2aWNlICAgICAgICAgIHVz YjJfY29udHJvbGxlcl91aGNpCgojIFVTQiBtYXNzIHN0b3JhZ2Ugc3VwcG9ydApkZXZpY2UgICAg ICAgICAgdXNiMl9zdG9yYWdlCmRldmljZSAgICAgICAgICB1c2IyX3N0b3JhZ2VfbWFzcwoKIyBV U0IgZXRoZXJuZXQgc3VwcG9ydCwgcmVxdWlyZXMgbWlpYnVzCmRldmljZSAgICAgICAgICB1c2Iy X2V0aGVybmV0CmRldmljZSAgICAgICAgICB1c2IyX2V0aGVybmV0X2F1ZQpkZXZpY2UgICAgICAg ICAgdXNiMl9ldGhlcm5ldF9heGUKZGV2aWNlICAgICAgICAgIHVzYjJfZXRoZXJuZXRfY2RjZQpk ZXZpY2UgICAgICAgICAgdXNiMl9ldGhlcm5ldF9jdWUKZGV2aWNlICAgICAgICAgIHVzYjJfZXRo ZXJuZXRfa3VlCmRldmljZSAgICAgICAgICB1c2IyX2V0aGVybmV0X3J1ZQojZGV2aWNlICAgICAg ICAgIHVzYjJfZXRoZXJuZXRfZGF2CgojIFVTQiB3aXJlbGVzcyBMQU4gc3VwcG9ydApkZXZpY2Ug ICAgICAgICAgdXNiMl93bGFuCmRldmljZSAgICAgICAgICB1c2IyX3dsYW5fcnVtCmRldmljZSAg ICAgICAgICB1c2IyX3dsYW5fcmFsCiNkZXZpY2UgICAgICAgICAgdXNiMl93bGFuX3p5ZAoKIyBV U0Igc2VyaWFsIGRldmljZSBzdXBwb3J0CmRldmljZSAgICAgICAgICB1c2IyX3NlcmlhbApkZXZp Y2UgICAgICAgICAgdXNiMl9zZXJpYWxfYXJrCmRldmljZSAgICAgICAgICB1c2IyX3NlcmlhbF9i c2EKZGV2aWNlICAgICAgICAgIHVzYjJfc2VyaWFsX2JzZXIKZGV2aWNlICAgICAgICAgIHVzYjJf c2VyaWFsX2NoY29tCmRldmljZSAgICAgICAgICB1c2IyX3NlcmlhbF9jeWNvbQpkZXZpY2UgICAg ICAgICAgdXNiMl9zZXJpYWxfZm9tYQpkZXZpY2UgICAgICAgICAgdXNiMl9zZXJpYWxfZnRkaQpk ZXZpY2UgICAgICAgICAgdXNiMl9zZXJpYWxfZ2Vuc2EKZGV2aWNlICAgICAgICAgIHVzYjJfc2Vy aWFsX2lwYXEKZGV2aWNlICAgICAgICAgIHVzYjJfc2VyaWFsX2xwdApkZXZpY2UgICAgICAgICAg dXNiMl9zZXJpYWxfbWN0CmRldmljZSAgICAgICAgICB1c2IyX3NlcmlhbF9tb2RlbQpkZXZpY2Ug ICAgICAgICAgdXNiMl9zZXJpYWxfbW9zY29tCmRldmljZSAgICAgICAgICB1c2IyX3NlcmlhbF9w bGNvbQpkZXZpY2UgICAgICAgICAgdXNiMl9zZXJpYWxfdmlzb3IKZGV2aWNlICAgICAgICAgIHVz YjJfc2VyaWFsX3ZzY29tCgojIFVTQiBibHVldG9vdGggc3VwcG9ydApkZXZpY2UgICAgICAgICAg dXNiMl9ibHVldG9vdGgKZGV2aWNlICAgICAgICAgIHVzYjJfYmx1ZXRvb3RoX25nCgojIFVTQiBp bnB1dCBkZXZpY2Ugc3VwcG9ydApkZXZpY2UgICAgICAgICAgdXNiMl9pbnB1dApkZXZpY2UgICAg ICAgICAgdXNiMl9pbnB1dF9oaWQKZGV2aWNlICAgICAgICAgIHVzYjJfaW5wdXRfa2JkCmRldmlj ZSAgICAgICAgICB1c2IyX2lucHV0X21zCgojIFVTQiBzb3VuZCBhbmQgTUlESSBkZXZpY2Ugc3Vw cG9ydAojZGV2aWNlICAgICAgICAgIHVzYjJfc291bmQKCgpvcHRpb25zIE5ESVNBUEkKZGV2aWNl IG5kaXMKCm9wdGlvbnMgSVBGSVJFV0FMTApvcHRpb25zIElQRklSRVdBTExfVkVSQk9TRQpvcHRp b25zIElQRklSRVdBTExfVkVSQk9TRV9MSU1JVD0xMApvcHRpb25zIElQRklSRVdBTExfREVGQVVM VF9UT19BQ0NFUFQKb3B0aW9ucyBJUEZJUkVXQUxMX0ZPUldBUkQKb3B0aW9ucyBJUERJVkVSVApv cHRpb25zIERVTU1ZTkVUICAgICAgICAgICAgICAgICAgICAgICAgCgpvcHRpb25zIFZFU0EKb3B0 aW9ucyBTQ19QSVhFTF9NT0RFCgpvcHRpb25zIFNDX0RJU0FCTEVfUkVCT09UCm9wdGlvbnMgU0Nf Tk9STV9BVFRSPShGR19HUkVFTnxCR19CTEFDSykKb3B0aW9ucyBTQ19LRVJORUxfQ09OU19BVFRS PShGR19ZRUxMT1d8QkdfQkxBQ0spCm9wdGlvbnMgU0NfSElTVE9SWV9TSVpFPTgxOTIKCmRldmlj ZSAgY3J5cHRvCmRldmljZSAgY3J5cHRvZGV2CgpvcHRpb25zIElQU0VDCgpkZXZpY2Ugdmxhbgpk ZXZpY2UgdGFwICAgICAgICAgICAgICAgICAgICAgI1ZpcnR1YWwgRXRoZXJuZXQgZHJpdmVyCmRl dmljZSBncmUgICAgICAgICAgICAgICAgICAgICAjSVAgb3ZlciBJUCB0dW5uZWxpbmcKZGV2aWNl IGlmX2JyaWRnZSAgICAgICAgICAgICAgICNCcmlkZ2UgaW50ZXJmYWNlCmRldmljZSBwZiAgICAg ICAgICAgICAgICAgICAgICAjUEYgT3BlbkJTRCBwYWNrZXQtZmlsdGVyIGZpcmV3YWxsCmRldmlj ZSBwZmxvZyAgICAgICAgICAgICAgICAgICAjbG9nZ2luZyBzdXBwb3J0IGludGVyZmFjZSBmb3Ig UEYKZGV2aWNlIHBmc3luYyAgICAgICAgICAgICAgICAgICNzeW5jaHJvbml6YXRpb24gaW50ZXJm YWNlIGZvciBQRgpkZXZpY2UgY2FycCAgICAgICAgICAgICAgICAgICAgI0NvbW1vbiBBZGRyZXNz IFJlZHVuZGFuY3kgUHJvdG9jb2wKZGV2aWNlIGVuYyAgICAgICAgICAgICAgICAgICAgICNJUHNl YyBpbnRlcmZhY2UKZGV2aWNlIGxhZ2cgICAgICAgICAgICAgICAgICAgICNMaW5rIGFnZ3JlZ2F0 aW9uIGludGVyZmFjZQoKb3B0aW9ucwkJQUNDRVBUX0ZJTFRFUl9EQVRBCm9wdGlvbnMJCUFDQ0VQ VF9GSUxURVJfSFRUUAoKb3B0aW9ucyAgICAgICAgIEFMVFEKb3B0aW9ucyAgICAgICAgIEFMVFFf Q0JRCm9wdGlvbnMgICAgICAgICBBTFRRX1JFRApvcHRpb25zICAgICAgICAgQUxUUV9SSU8Kb3B0 aW9ucyAgICAgICAgIEFMVFFfSEZTQwpvcHRpb25zICAgICAgICAgQUxUUV9QUklRCgpvcHRpb25z ICAgICAgICAgTkVUR1JBUEgKb3B0aW9ucyAgICAgICAgIE5FVEdSQVBIX0JQRgpvcHRpb25zICAg ICAgICAgTkVUR1JBUEhfSUZBQ0UKb3B0aW9ucyAgICAgICAgIE5FVEdSQVBIX0tTT0NLRVQKb3B0 aW9ucyAgICAgICAgIE5FVEdSQVBIX01QUENfRU5DUllQVElPTgpvcHRpb25zICAgICAgICAgTkVU R1JBUEhfUFBQCm9wdGlvbnMgICAgICAgICBORVRHUkFQSF9QUFRQR1JFCm9wdGlvbnMgICAgICAg ICBORVRHUkFQSF9TT0NLRVQKb3B0aW9ucyAgICAgICAgIE5FVEdSQVBIX1RDUE1TUwoKb3B0aW9u cyAgICAgICAgIEhaPTEwMApvcHRpb25zICAgICAgICAgREVWSUNFX1BPTExJTkcKCg== ------ZsXlibyD-b3u64zfXGPVq6btq:1230945026-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 16:52:08 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5CB6106566B for ; Sat, 3 Jan 2009 16:52:08 +0000 (UTC) (envelope-from chris@hitnet.RWTH-Aachen.DE) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by mx1.freebsd.org (Postfix) with ESMTP id 84ADF8FC1A for ; Sat, 3 Jan 2009 16:52:08 +0000 (UTC) (envelope-from chris@hitnet.RWTH-Aachen.DE) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0KCW00543MUVGM20@mta-1.ms.rz.RWTH-Aachen.de> for current@freebsd.org; Sat, 03 Jan 2009 17:52:07 +0100 (CET) X-IronPort-AV: E=Sophos;i="4.36,323,1228086000"; d="scan'208";a="95320101" Received: from smarthost-2.ms.rz.rwth-aachen.de (HELO smarthost.rwth-aachen.de) ([134.130.7.90]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Sat, 03 Jan 2009 17:52:07 +0100 Received: from bigboss.hitnet.rwth-aachen.de (bigspace.hitnet.RWTH-Aachen.DE [137.226.181.2]) by smarthost.rwth-aachen.de (8.13.8+Sun/8.13.8/1) with ESMTP id n03Gq7Np004898 for ; Sat, 03 Jan 2009 17:52:07 +0100 (CET) Received: from haakonia.hitnet.rwth-aachen.de ([137.226.181.92]) by bigboss.hitnet.rwth-aachen.de with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1LJ9jL-00050I-7N for current@freebsd.org; Sat, 03 Jan 2009 17:52:07 +0100 Received: by haakonia.hitnet.rwth-aachen.de (Postfix, from userid 1001) id 0EE2B3F433; Sat, 03 Jan 2009 17:52:07 +0100 (CET) Date: Sat, 03 Jan 2009 17:52:06 +0100 From: Christian Brueffer To: current@freebsd.org Message-id: <20090103165206.GD1243@haakonia.hitnet.RWTH-Aachen.DE> References: <20090103155724.GC1243@haakonia.hitnet.RWTH-Aachen.DE> Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary=OzxllxdKGCiKxUZM Content-disposition: inline In-reply-to: <20090103155724.GC1243@haakonia.hitnet.RWTH-Aachen.DE> X-Operating-System: FreeBSD 6.4-STABLE X-PGP-Key: http://people.FreeBSD.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D User-Agent: Mutt/1.5.11 Cc: Subject: Re: CFT: altq support for pcn(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 16:52:09 -0000 --OzxllxdKGCiKxUZM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I forgot to mention that this is an updated version of mlaier's patch that can be found at http://people.freebsd.org/~mlaier/ALTQ_driver/ . The updated version can also be found at http://people.freebsd.org/~brueffer/pcn_altq.diff - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --OzxllxdKGCiKxUZM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFJX5e2bHYXjKDtmC0RAmqkAKDvPgdF5gKn8WLpAr4NfqzpPv8HrwCgvJYZ vteo4iXjHTNjYyqrnlFb57s= =7r0J -----END PGP SIGNATURE----- --OzxllxdKGCiKxUZM-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 17:18:25 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FA98106566C for ; Sat, 3 Jan 2009 17:18:25 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout022.mac.com (asmtpout022.mac.com [17.148.16.97]) by mx1.freebsd.org (Postfix) with ESMTP id F0F1F8FC13 for ; Sat, 3 Jan 2009 17:18:24 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed Received: from [192.168.1.96] (75-101-29-67.dsl.static.sonic.net [75.101.29.67]) by asmtp022.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KCW00IRHO2OU450@asmtp022.mac.com> for current@freebsd.org; Sat, 03 Jan 2009 09:18:24 -0800 (PST) Message-id: From: Marcel Moolenaar To: "M. Warner Losh" In-reply-to: <20090102.115426.-1540393465.imp@bsdimp.com> Date: Sat, 03 Jan 2009 09:18:23 -0800 References: <20090102.115426.-1540393465.imp@bsdimp.com> X-Mailer: Apple Mail (2.930.3) Cc: current@freebsd.org Subject: Re: New warning, what does it mean? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 17:18:25 -0000 On Jan 2, 2009, at 10:54 AM, M. Warner Losh wrote: > I'm getting the following from my main disk on boot now: > > GEOM: ad0s2: geometry does not match label (255h,63s != 16h,63s). > > What does it mean? This system is a dual-boot FreeBSD/Windows > laptop. In the past I've seen sysinstall barf on the former geometry, > and have had problems installing dual-boot core4/FreeBSD systems > because of it. > > In addition, the above error message is useless. Who is complaining? > Why are they complaining? What is the corrective action to be taken > here? Why does it matter with modern disks and BIOSes anyway? This is geom_part telling you that the BSD disk label does not have the same geometry as ad0 is telling it it has. Your label claims 255 heads. Your disk claims 16 heads. There's nothing you need to do at this time. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 17:26:37 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5414F106566B for ; Sat, 3 Jan 2009 17:26:37 +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 161518FC16 for ; Sat, 3 Jan 2009 17:26:37 +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 n03HPGsi077431; Sat, 3 Jan 2009 10:25:16 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sat, 03 Jan 2009 10:25:28 -0700 (MST) Message-Id: <20090103.102528.139568125.imp@bsdimp.com> To: xcllnt@mac.com From: "M. Warner Losh" In-Reply-To: References: <20090102.115426.-1540393465.imp@bsdimp.com> 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: current@freebsd.org Subject: Re: New warning, what does it mean? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 17:26:37 -0000 In message: Marcel Moolenaar writes: : : On Jan 2, 2009, at 10:54 AM, M. Warner Losh wrote: : : > I'm getting the following from my main disk on boot now: : > : > GEOM: ad0s2: geometry does not match label (255h,63s != 16h,63s). : > : > What does it mean? This system is a dual-boot FreeBSD/Windows : > laptop. In the past I've seen sysinstall barf on the former geometry, : > and have had problems installing dual-boot core4/FreeBSD systems : > because of it. : > : > In addition, the above error message is useless. Who is complaining? : > Why are they complaining? What is the corrective action to be taken : > here? Why does it matter with modern disks and BIOSes anyway? : : This is geom_part telling you that the BSD disk label does : not have the same geometry as ad0 is telling it it has. : Your label claims 255 heads. Your disk claims 16 heads. : There's nothing you need to do at this time. It would be nice to know which of the numbers is which... You can't tell that without finding this message in the source... Warner From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 17:32:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6538F106564A; Sat, 3 Jan 2009 17:32:46 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout012.mac.com (asmtpout012.mac.com [17.148.16.87]) by mx1.freebsd.org (Postfix) with ESMTP id 4E6388FC0C; Sat, 3 Jan 2009 17:32:46 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [192.168.1.96] (75-101-29-67.dsl.static.sonic.net [75.101.29.67]) by asmtp012.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KCW008M4OQK8A40@asmtp012.mac.com>; Sat, 03 Jan 2009 09:32:46 -0800 (PST) Message-id: <440945C2-252E-489A-902E-A499753A5EF8@mac.com> From: Marcel Moolenaar To: "M. Warner Losh" In-reply-to: <20090102.231410.-2001109684.imp@bsdimp.com> Date: Sat, 03 Jan 2009 09:32:44 -0800 References: <20090102091334.GA41230@dragon.NUXI.org> <20090102.114757.-924277930.imp@bsdimp.com> <20090103033543.GB77475@dragon.NUXI.org> <20090102.231410.-2001109684.imp@bsdimp.com> X-Mailer: Apple Mail (2.930.3) Cc: bsam@ipt.ru, freebsd-current@freebsd.org, fbsdlist@src.cx Subject: Re: gjournal is not automounted any more X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 17:32:46 -0000 On Jan 2, 2009, at 10:14 PM, M. Warner Losh wrote: > In message: <20090103033543.GB77475@dragon.NUXI.org> > "David O'Brien" writes: > : On Fri, Jan 02, 2009 at 11:47:57AM -0700, M. Warner Losh wrote: > : > In message: <20090102091334.GA41230@dragon.NUXI.org> > : > "David O'Brien" writes: > : > : Before 'fsck' would read the lable for the FS type. That has > changed and > : > : thus you cannot just 'fsck /dev/ad1s1d' anymore. So the FS > type in fstab > : > : must be accurate. > : > > : > Why did that change? I routinely have disks that aren't in my > : > /etc/fstab that I mount and this is a pain in the backside. > : > : Due to r186240 which: > : Make gpart the default partitioning class on all platforms. > : > : Seems GEOM_PART_BSD does not like labels that GEOM_BSD did. > > Then why the change? Shouldn't we make it like them for > compatibility? David's statement is incorrect. They like the same labels for all practical purposes. The problem at hand here is that fsck(8) & newfs(8) ask of GEOM_BSD what the partition type is. This means 2 things: 1. Any platform that doesn't use the BSD disklabel by default needs to have a proper /etc/fstab and is not behaving the same as i386. 2. Switching to GPT as the default partitioning scheme yields the same problem. As I said in an email to arch@, it's good to query the partition type to determine what to do when more specific information is missing (running fsck(8) vs fsck_ffs(8)). But it wasn't something that was there at the switchover point. FYI, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 17:43:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 673701065702; Sat, 3 Jan 2009 17:43:38 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout021.mac.com (asmtpout021.mac.com [17.148.16.96]) by mx1.freebsd.org (Postfix) with ESMTP id 526388FC12; Sat, 3 Jan 2009 17:43:38 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed Received: from [192.168.1.96] (75-101-29-67.dsl.static.sonic.net [75.101.29.67]) by asmtp021.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KCW00DQ0P8PSU10@asmtp021.mac.com>; Sat, 03 Jan 2009 09:43:38 -0800 (PST) Message-id: <0A76CAED-D11F-448B-8A1C-E42526B67E89@mac.com> From: Marcel Moolenaar To: obrien@freebsd.org In-reply-to: <20090103102036.GB81276@dragon.NUXI.org> Date: Sat, 03 Jan 2009 09:43:36 -0800 References: <20090102.115426.-1540393465.imp@bsdimp.com> <20090103102036.GB81276@dragon.NUXI.org> X-Mailer: Apple Mail (2.930.3) Cc: freebsd-current@freebsd.org, "M. Warner Losh" Subject: Re: New warning, what does it mean? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 17:43:39 -0000 On Jan 3, 2009, at 2:20 AM, David O'Brien wrote: > On Fri, Jan 02, 2009 at 11:54:26AM -0700, M. Warner Losh wrote: >> I'm getting the following from my main disk on boot now: >> GEOM: ad0s2: geometry does not match label (255h,63s != 16h,63s). > .. >> Why are they complaining? What is the corrective action to be taken >> here? Why does it matter with modern disks and BIOSes anyway? > > All very good questions. See my recent "Shooting sysinstall/SADE > geometry warning in the head" thread. Seems maybe GEOM_PART_BSD > took a page from that book and should be smacked also. Leave it for now. We've been very lacks in checking the disk label as witnessed by the fact that sysinstall creates faulty labels and we didn't even know. The message can go away (or put under boot verbose) when the dust settles. > I don't see why FreeBSD is making such a mess of geometries with > modern SATA/IDE disks. We seem to be the standout here. :-( We've never treated it seriously. We keep saying "it doesn't matter with modern disks" and things like that and as such side-step the issue that file systems or disk labels still record them, use them or need them. We created the problem ourselves by creating inconsistency at various levels. With geom_part I made it more visible so that we can actually make it better. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 17:44:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CBA2106568D; Sat, 3 Jan 2009 17:44:28 +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 E253F8FC08; Sat, 3 Jan 2009 17:44:27 +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 n03Hg8F7077578; Sat, 3 Jan 2009 10:42:08 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sat, 03 Jan 2009 10:42:20 -0700 (MST) Message-Id: <20090103.104220.513891918.imp@bsdimp.com> To: xcllnt@mac.com From: "M. Warner Losh" In-Reply-To: <440945C2-252E-489A-902E-A499753A5EF8@mac.com> References: <20090103033543.GB77475@dragon.NUXI.org> <20090102.231410.-2001109684.imp@bsdimp.com> <440945C2-252E-489A-902E-A499753A5EF8@mac.com> 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: bsam@ipt.ru, freebsd-current@freebsd.org, fbsdlist@src.cx Subject: Re: gjournal is not automounted any more X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 17:44:28 -0000 In message: <440945C2-252E-489A-902E-A499753A5EF8@mac.com> Marcel Moolenaar writes: : : On Jan 2, 2009, at 10:14 PM, M. Warner Losh wrote: : : > In message: <20090103033543.GB77475@dragon.NUXI.org> : > "David O'Brien" writes: : > : On Fri, Jan 02, 2009 at 11:47:57AM -0700, M. Warner Losh wrote: : > : > In message: <20090102091334.GA41230@dragon.NUXI.org> : > : > "David O'Brien" writes: : > : > : Before 'fsck' would read the lable for the FS type. That has : > changed and : > : > : thus you cannot just 'fsck /dev/ad1s1d' anymore. So the FS : > type in fstab : > : > : must be accurate. : > : > : > : > Why did that change? I routinely have disks that aren't in my : > : > /etc/fstab that I mount and this is a pain in the backside. : > : : > : Due to r186240 which: : > : Make gpart the default partitioning class on all platforms. : > : : > : Seems GEOM_PART_BSD does not like labels that GEOM_BSD did. : > : > Then why the change? Shouldn't we make it like them for : > compatibility? : : David's statement is incorrect. They like the same labels : for all practical purposes. The problem at hand here is : that fsck(8) & newfs(8) ask of GEOM_BSD what the partition : type is. This means 2 things: : 1. Any platform that doesn't use the BSD disklabel by : default needs to have a proper /etc/fstab and is not : behaving the same as i386. : 2. Switching to GPT as the default partitioning scheme : yields the same problem. : : As I said in an email to arch@, it's good to query the : partition type to determine what to do when more specific : information is missing (running fsck(8) vs fsck_ffs(8)). : But it wasn't something that was there at the switchover : point. But my problems are with a platform that has BSD labels, and not GPT labels, with a proper BSD label on the device. mount works properly without extra args, but fsck doesn't and this is a new behavior introduced recently... I know this because I'd been messing with this disk in an enclosure several weeks ago and also playing with cardbus fixes, some of which hung my machine (which means that the disk wasn't cleanly unmounted, so I was doing a lot of fsck). % disklabel da0s1 # /dev/da0s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 976767986 16 4.2BSD 2048 16384 28520 c: 976768002 0 unused 0 0 # "raw" part, don't edit I'll have to go read things on arch@. Warner From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 17:53:47 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11B951065674 for ; Sat, 3 Jan 2009 17:53:47 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout011.mac.com (asmtpout011.mac.com [17.148.16.86]) by mx1.freebsd.org (Postfix) with ESMTP id F185C8FC1B for ; Sat, 3 Jan 2009 17:53:46 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [192.168.1.96] (75-101-29-67.dsl.static.sonic.net [75.101.29.67]) by asmtp011.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KCW00DQIPP7CX80@asmtp011.mac.com> for current@freebsd.org; Sat, 03 Jan 2009 09:53:32 -0800 (PST) Message-id: From: Marcel Moolenaar To: "M. Warner Losh" In-reply-to: <20090103.102528.139568125.imp@bsdimp.com> Date: Sat, 03 Jan 2009 09:53:31 -0800 References: <20090102.115426.-1540393465.imp@bsdimp.com> <20090103.102528.139568125.imp@bsdimp.com> X-Mailer: Apple Mail (2.930.3) Cc: current@freebsd.org Subject: Re: New warning, what does it mean? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 17:53:47 -0000 On Jan 3, 2009, at 9:25 AM, M. Warner Losh wrote: > In message: > Marcel Moolenaar writes: > : > : On Jan 2, 2009, at 10:54 AM, M. Warner Losh wrote: > : > : > I'm getting the following from my main disk on boot now: > : > > : > GEOM: ad0s2: geometry does not match label (255h,63s != 16h,63s). > : > > : > What does it mean? This system is a dual-boot FreeBSD/Windows > : > laptop. In the past I've seen sysinstall barf on the former > geometry, > : > and have had problems installing dual-boot core4/FreeBSD systems > : > because of it. > : > > : > In addition, the above error message is useless. Who is > complaining? > : > Why are they complaining? What is the corrective action to be > taken > : > here? Why does it matter with modern disks and BIOSes anyway? > : > : This is geom_part telling you that the BSD disk label does > : not have the same geometry as ad0 is telling it it has. > : Your label claims 255 heads. Your disk claims 16 heads. > : There's nothing you need to do at this time. > > It would be nice to know which of the numbers is which... You can't > tell that without finding this message in the source... True. David added the numbers, which weren't there, so it's an improvement over the original warning, but it helps if we use a second line and be more informative. I think the warning should go away eventually. That's why I'm not too concerned right now with the details of that message. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 18:01:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F291106564A for ; Sat, 3 Jan 2009 18:01:22 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout011.mac.com (asmtpout011.mac.com [17.148.16.86]) by mx1.freebsd.org (Postfix) with ESMTP id 691838FC0C for ; Sat, 3 Jan 2009 18:01:22 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [192.168.1.96] (75-101-29-67.dsl.static.sonic.net [75.101.29.67]) by asmtp011.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KCW00F1SQ272N60@asmtp011.mac.com> for freebsd-current@freebsd.org; Sat, 03 Jan 2009 10:01:20 -0800 (PST) Message-id: <8F22F980-0D4C-4074-8685-3FFAD4558362@mac.com> From: Marcel Moolenaar To: "M. Warner Losh" In-reply-to: <20090103.104220.513891918.imp@bsdimp.com> Date: Sat, 03 Jan 2009 10:01:19 -0800 References: <20090103033543.GB77475@dragon.NUXI.org> <20090102.231410.-2001109684.imp@bsdimp.com> <440945C2-252E-489A-902E-A499753A5EF8@mac.com> <20090103.104220.513891918.imp@bsdimp.com> X-Mailer: Apple Mail (2.930.3) Cc: bsam@ipt.ru, freebsd-current@freebsd.org, fbsdlist@src.cx Subject: Re: gjournal is not automounted any more X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 18:01:22 -0000 On Jan 3, 2009, at 9:42 AM, M. Warner Losh wrote: > In message: <440945C2-252E-489A-902E-A499753A5EF8@mac.com> > Marcel Moolenaar writes: > : > : On Jan 2, 2009, at 10:14 PM, M. Warner Losh wrote: > : > : > In message: <20090103033543.GB77475@dragon.NUXI.org> > : > "David O'Brien" writes: > : > : On Fri, Jan 02, 2009 at 11:47:57AM -0700, M. Warner Losh wrote: > : > : > In message: <20090102091334.GA41230@dragon.NUXI.org> > : > : > "David O'Brien" writes: > : > : > : Before 'fsck' would read the lable for the FS type. That > has > : > changed and > : > : > : thus you cannot just 'fsck /dev/ad1s1d' anymore. So the FS > : > type in fstab > : > : > : must be accurate. > : > : > > : > : > Why did that change? I routinely have disks that aren't in my > : > : > /etc/fstab that I mount and this is a pain in the backside. > : > : > : > : Due to r186240 which: > : > : Make gpart the default partitioning class on all platforms. > : > : > : > : Seems GEOM_PART_BSD does not like labels that GEOM_BSD did. > : > > : > Then why the change? Shouldn't we make it like them for > : > compatibility? > : > : David's statement is incorrect. They like the same labels > : for all practical purposes. The problem at hand here is > : that fsck(8) & newfs(8) ask of GEOM_BSD what the partition > : type is. This means 2 things: > : 1. Any platform that doesn't use the BSD disklabel by > : default needs to have a proper /etc/fstab and is not > : behaving the same as i386. > : 2. Switching to GPT as the default partitioning scheme > : yields the same problem. > : > : As I said in an email to arch@, it's good to query the > : partition type to determine what to do when more specific > : information is missing (running fsck(8) vs fsck_ffs(8)). > : But it wasn't something that was there at the switchover > : point. > > But my problems are with a platform that has BSD labels, and not GPT > labels, with a proper BSD label on the device. You don't have GEOM_BSD to service the DIOCGDINFO ioctl(2) anymore. We need to change fsck(8) so that it doesn't work only on BSD disk labels, but instead obtains the partition type (if applicable) in a more generic way so that it also applies to other partitioning schemes. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 18:08:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7ED92106566C for ; Sat, 3 Jan 2009 18:08:45 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by mx1.freebsd.org (Postfix) with ESMTP id 122B18FC14 for ; Sat, 3 Jan 2009 18:08:44 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by ey-out-2122.google.com with SMTP id d26so735952eyd.7 for ; Sat, 03 Jan 2009 10:08:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=FIJzxVtrgNCY8y75ZXl7lGssWmgz+VJM0iTtRSFoxao=; b=G3qJ/Jx9OLT9w2lmCX5jD/SsRrFy8ke9aPxkBIUA+ZnVxMOUqIz9uEeNEzAgw2QadP yhM5uoaTBWuA94ZiyL+Dy/dJaceSvz8IW80vhkzcQmuAEiaQCvakZ8vUmjYhdPvkUcGy nXRxUPsDWZhRNoqNwsFEhTjW43Crk6mZqeuxY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=dMvovdTmjAglEqO6v86WW1Pms7QnzASLVQHYSNXwnwLawVF4KeNrlJrWsIYeE3z1M1 NsDJlbk0/n6HkjC86Gi2g7BzTip11OIZX2Uz6O7u5LhmDXjcWTyTiRvcfQ3iU1ERb6uQ aqY4Amlbl2CecUuXnenjtowBSDf9lSzEQBFsY= Received: by 10.210.16.17 with SMTP id 17mr9377852ebp.169.1231006123669; Sat, 03 Jan 2009 10:08:43 -0800 (PST) Received: by 10.210.59.20 with HTTP; Sat, 3 Jan 2009 10:08:43 -0800 (PST) Message-ID: <3a142e750901031008x3d2fefc8r4c5b877e049af02a@mail.gmail.com> Date: Sat, 3 Jan 2009 19:08:43 +0100 From: "Paul B. Mahol" To: "Alexey Ivanov" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: Cc: freebsd-current@freebsd.org Subject: Re: Can not build r186708 -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 18:08:45 -0000 On 1/3/09, Alexey Ivanov wrote: > last time I've updated my FreeBSD was > > [PH34R] ~> uname -a > FreeBSD PH34R 8.0-CURRENT FreeBSD 8.0-CURRENT #14: Mon Dec 22 13:09:06 MSK > 2008 savetherbtz@PH34R:/usr/obj/usr/src/sys/PH34R.8 i386 > > > Now after cvsup I have > ... > .... > awk -f /usr/src/sys/tools/makeobjops.awk /usr/src/sys/dev/acpica/acpi_if.m > -h > rm -f .newdep > make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" > xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -march=athlon-mp > -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys > -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter > -I/usr/src/sys/contrib/pf -I/usr/src/sys/dev/ath > -I/usr/src/sys/dev/ath/ath_hal -I/usr/src/sys/contrib/ngatm > -I/usr/src/sys/dev/twa -I/usr/src/sys/gnu/fs/xfs/FreeBSD > -I/usr/src/sys/gnu/fs/xfs/FreeBSD/support -I/usr/src/sys/gnu/fs/xfs > -I/usr/src/sys/contrib/opensolaris/compat -I/usr/src/sys/dev/cxgb -D_KERNEL > -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -mno-align-long-strings > -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > -mno-sse3 -ffreestand > ing -fstack-protector > /usr/src/sys/compat/ndis/subr_usbd.c:64:21: error: usbdevs.h: No such file > or directory > mkdep: compile failed > *** Error code 1 > > Stop in /usr/obj/usr/src/sys/PH34R.8. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > > > KERNCONF attached > Known issue, remove ndis from kernel conf. -- Paul From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 18:14:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22FAD1065678 for ; Sat, 3 Jan 2009 18:14:21 +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 B9C5C8FC26 for ; Sat, 3 Jan 2009 18:14:20 +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 n03IDCBH077947; Sat, 3 Jan 2009 11:13:12 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sat, 03 Jan 2009 11:13:24 -0700 (MST) Message-Id: <20090103.111324.-98089972.imp@bsdimp.com> To: xcllnt@mac.com From: "M. Warner Losh" In-Reply-To: <8F22F980-0D4C-4074-8685-3FFAD4558362@mac.com> References: <440945C2-252E-489A-902E-A499753A5EF8@mac.com> <20090103.104220.513891918.imp@bsdimp.com> <8F22F980-0D4C-4074-8685-3FFAD4558362@mac.com> 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: bsam@ipt.ru, freebsd-current@freebsd.org, fbsdlist@src.cx Subject: Re: gjournal is not automounted any more X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 18:14:21 -0000 In message: <8F22F980-0D4C-4074-8685-3FFAD4558362@mac.com> Marcel Moolenaar writes: : : On Jan 3, 2009, at 9:42 AM, M. Warner Losh wrote: : : > In message: <440945C2-252E-489A-902E-A499753A5EF8@mac.com> : > Marcel Moolenaar writes: : > : : > : On Jan 2, 2009, at 10:14 PM, M. Warner Losh wrote: : > : : > : > In message: <20090103033543.GB77475@dragon.NUXI.org> : > : > "David O'Brien" writes: : > : > : On Fri, Jan 02, 2009 at 11:47:57AM -0700, M. Warner Losh wrote: : > : > : > In message: <20090102091334.GA41230@dragon.NUXI.org> : > : > : > "David O'Brien" writes: : > : > : > : Before 'fsck' would read the lable for the FS type. That : > has : > : > changed and : > : > : > : thus you cannot just 'fsck /dev/ad1s1d' anymore. So the FS : > : > type in fstab : > : > : > : must be accurate. : > : > : > : > : > : > Why did that change? I routinely have disks that aren't in my : > : > : > /etc/fstab that I mount and this is a pain in the backside. : > : > : : > : > : Due to r186240 which: : > : > : Make gpart the default partitioning class on all platforms. : > : > : : > : > : Seems GEOM_PART_BSD does not like labels that GEOM_BSD did. : > : > : > : > Then why the change? Shouldn't we make it like them for : > : > compatibility? : > : : > : David's statement is incorrect. They like the same labels : > : for all practical purposes. The problem at hand here is : > : that fsck(8) & newfs(8) ask of GEOM_BSD what the partition : > : type is. This means 2 things: : > : 1. Any platform that doesn't use the BSD disklabel by : > : default needs to have a proper /etc/fstab and is not : > : behaving the same as i386. : > : 2. Switching to GPT as the default partitioning scheme : > : yields the same problem. : > : : > : As I said in an email to arch@, it's good to query the : > : partition type to determine what to do when more specific : > : information is missing (running fsck(8) vs fsck_ffs(8)). : > : But it wasn't something that was there at the switchover : > : point. : > : > But my problems are with a platform that has BSD labels, and not GPT : > labels, with a proper BSD label on the device. : : You don't have GEOM_BSD to service the DIOCGDINFO ioctl(2) : anymore. We need to change fsck(8) so that it doesn't work : only on BSD disk labels, but instead obtains the partition : type (if applicable) in a more generic way so that it also : applies to other partitioning schemes. Agreed. Do you have a proposal for how to do that? Warner From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 18:25:32 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8FF1106566B for ; Sat, 3 Jan 2009 18:25:32 +0000 (UTC) (envelope-from uwe@grohnwaldt.eu) Received: from AurraSing.lando.cc (AurraSing.lando.cc [87.106.187.149]) by mx1.freebsd.org (Postfix) with ESMTP id 7A4988FC12 for ; Sat, 3 Jan 2009 18:25:32 +0000 (UTC) (envelope-from uwe@grohnwaldt.eu) Received: from AurraSing.lando.cc (unknown [127.0.0.1]) by AurraSing.lando.cc (Postfix) with ESMTP id 5F16518B7B88A for ; Sat, 3 Jan 2009 18:25:31 +0000 (UTC) Received: from BriaTharen.local (unknown [139.30.17.153]) by AurraSing.lando.cc (Postfix) with ESMTP for ; Sat, 3 Jan 2009 18:25:31 +0000 (UTC) Message-ID: <495FAD98.2010503@grohnwaldt.eu> Date: Sat, 03 Jan 2009 19:25:28 +0100 From: Uwe Grohnwaldt User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: current@freebsd.org References: <495E8F00.2050309@grohnwaldt.eu> <495EAFE1.4040801@grohnwaldt.eu> <200901030116.45837.Thomas.Sparrevohn@btinternet.com> <200901030224.44187.hselasky@c2i.net> In-Reply-To: <200901030224.44187.hselasky@c2i.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: panic on (hdd)load X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 18:25:33 -0000 Hans Petter Selasky wrote: > On Saturday 03 January 2009, Thomas Sparrevohn wrote: > >> On Saturday 03 January 2009 00:22:57 Uwe Grohnwaldt wrote: >> >> >> This error occurs because of some DMA corruption when the PM changes was >> added to the ATA framework. The error is actually related to the USB Umass >> device. >> >> HPS has already identified the issue in the new USB stack but I don't think >> it has been solved yet ;-( >> >> Try to disable umass devices and see what happens >> >> > > Here is the patch I've made. Probably you can or have to make the re-alignment > unconditional. > > http://perforce.freebsd.org/chv.cgi?CH=154181 > > I tried the patch and disabled umass - but the panic comes after a short time of hdd-i/o. From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 18:45:01 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B80410656C1 for ; Sat, 3 Jan 2009 18:45:01 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from hosting.lissyara.su (hosting.lissyara.su [77.221.149.162]) by mx1.freebsd.org (Postfix) with ESMTP id D2B1D8FC1D for ; Sat, 3 Jan 2009 18:45:00 +0000 (UTC) (envelope-from admin@lissyara.su) Received: from [89.178.141.42] (port=12606 helo=HP.lissyara.su) by hosting.lissyara.su with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LJBUY-0000R2-HL; Sat, 03 Jan 2009 21:44:58 +0300 Message-ID: <495FB22A.3000703@lissyara.su> Date: Sat, 03 Jan 2009 21:44:58 +0300 From: Alex Keda User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.8.1.19) Gecko/20090103 Thunderbird/2.0.0.19 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Luigi Rizzo References: <20090101183026.GA15385@onelab2.iet.unipi.it> In-Reply-To: <20090101183026.GA15385@onelab2.iet.unipi.it> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Description: if spam count > 60 - this is spam X-Spam-Count: 0 X-Descriptions: powered by www.lissyara.su X-Bounce-ID: hosting.lissyara.su Cc: current@freebsd.org Subject: Re: RFC: new utility, kmodpatch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 18:45:01 -0000 Luigi Rizzo пишет: > I mentioned this utility a couple of months ago, and it's now working > so i would like to receive feedback on whether this is good to have > as part of the system, or just keep it as a port (which is what > i plan to do by default). > > In a nutshell, the kmodpatch utility can print or alter the content > of device/quirk tables in kernel modules (I think Linux has some > similar tool, though i don't remember the name -- or perhaps it is > a feature of insmod ?). > > Full manpage is attached at the end, full sources are at > > http://info.iet.unipi.it/~luigi/FreeBSD/20090101-kmodpatch.tgz cannot build HP$ gunzip --stdout 20090101-kmodpatch.tgz | tar --extract --file=- HP$ cd kmodpatch HP$ ll total 32 -rw-r--r-- 1 lissyara wheel 132B 1 янв 23:08 Makefile -rw-r--r-- 1 lissyara wheel 6,1K 1 янв 23:07 kmodpatch.8 -rw-r--r-- 1 lissyara wheel 16K 1 янв 22:48 kmodpatch.c HP$ make cc -O2 -pipe -O1 -Wall -Werror -Wunused -g -I/usr/local/include -L/usr/local/lib -lkvm kmodpatch.c -o kmodpatch cc1: warnings being treated as errors kmodpatch.c: In function 'dump': kmodpatch.c:234: warning: format '%d' expects type 'int', but argument 3 has type 'size_t' kmodpatch.c:291: warning: format '%016llx' expects type 'long long unsigned int', but argument 3 has type 'uint64_t' kmodpatch.c: In function 'do_rw': kmodpatch.c:535: warning: format '%d' expects type 'int', but argument 5 has type 'size_t' *** Error code 1 Stop in /tmp/kmodpatch. HP$ From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 18:54:55 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 133551065702 for ; Sat, 3 Jan 2009 18:54:55 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id C7E6A8FC08 for ; Sat, 3 Jan 2009 18:54:54 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 70A9C73098; Sat, 3 Jan 2009 19:59:47 +0100 (CET) Date: Sat, 3 Jan 2009 19:59:47 +0100 From: Luigi Rizzo To: Alex Keda Message-ID: <20090103185947.GA96480@onelab2.iet.unipi.it> References: <20090101183026.GA15385@onelab2.iet.unipi.it> <495FB22A.3000703@lissyara.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <495FB22A.3000703@lissyara.su> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: RFC: new utility, kmodpatch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 18:54:55 -0000 On Sat, Jan 03, 2009 at 09:44:58PM +0300, Alex Keda wrote: > Luigi Rizzo ??????????: > >I mentioned this utility a couple of months ago, and it's now working > >so i would like to receive feedback on whether this is good to have > >as part of the system, or just keep it as a port (which is what > >i plan to do by default). > > > >In a nutshell, the kmodpatch utility can print or alter the content > >of device/quirk tables in kernel modules (I think Linux has some > >similar tool, though i don't remember the name -- or perhaps it is > >a feature of insmod ?). > > > >Full manpage is attached at the end, full sources are at > > > > http://info.iet.unipi.it/~luigi/FreeBSD/20090101-kmodpatch.tgz > > cannot build > HP$ gunzip --stdout 20090101-kmodpatch.tgz | tar --extract --file=- is this on amd64 ? in any case, as a temporary workaround just cast the arguments as suggested by the warnings. cheers luigi > HP$ cd kmodpatch > HP$ ll > total 32 > -rw-r--r-- 1 lissyara wheel 132B 1 ?????? 23:08 Makefile > -rw-r--r-- 1 lissyara wheel 6,1K 1 ?????? 23:07 kmodpatch.8 > -rw-r--r-- 1 lissyara wheel 16K 1 ?????? 22:48 kmodpatch.c > HP$ make > cc -O2 -pipe -O1 -Wall -Werror -Wunused -g -I/usr/local/include > -L/usr/local/lib -lkvm kmodpatch.c -o kmodpatch > cc1: warnings being treated as errors > kmodpatch.c: In function 'dump': > kmodpatch.c:234: warning: format '%d' expects type 'int', but argument 3 > has type 'size_t' > kmodpatch.c:291: warning: format '%016llx' expects type 'long long > unsigned int', but argument 3 has type 'uint64_t' > kmodpatch.c: In function 'do_rw': > kmodpatch.c:535: warning: format '%d' expects type 'int', but argument 5 > has type 'size_t' > *** Error code 1 > > Stop in /tmp/kmodpatch. > HP$ From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 19:03:23 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AFFE106564A for ; Sat, 3 Jan 2009 19:03:23 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id 38E838FC18 for ; Sat, 3 Jan 2009 19:03:23 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1LJBWz-00035q-Su for freebsd-current@freebsd.org; Sat, 03 Jan 2009 10:47:29 -0800 Message-ID: <21267890.post@talk.nabble.com> Date: Sat, 3 Jan 2009 10:47:29 -0800 (PST) From: dvg_lab To: freebsd-current@freebsd.org In-Reply-To: <20090101183026.GA15385@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: dvg@tjc.ru References: <20090101183026.GA15385@onelab2.iet.unipi.it> X-Mailman-Approved-At: Sat, 03 Jan 2009 19:08:43 +0000 Subject: Re: RFC: new utility, kmodpatch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 19:03:24 -0000 Hi, I mentioned this utility a couple of months ago, and it's now working > so i would like to receive feedback on whether this is good to have > as part of the system, or just keep it as a port (which is what > i plan to do by default). > > In a nutshell, the kmodpatch utility can print or alter the content > of device/quirk tables in kernel modules (I think Linux has some > similar tool, though i don't remember the name -- or perhaps it is > a feature of insmod ?). > Can't make it on CURRENT (31.12.2008) amd64 dvg-nb# make cc -O2 -pipe -O1 -Wall -Werror -Wunused -g -I/usr/local/include -L/usr/local/lib -lkvm kmodpatch.c -o kmodpatch cc1: warnings being treated as errors kmodpatch.c: In function 'dump': kmodpatch.c:234: warning: format '%d' expects type 'int', but argument 3 has type 'size_t' kmodpatch.c:291: warning: format '%016llx' expects type 'long long unsigned int', but argument 3 has type 'uint64_t' kmodpatch.c: In function 'do_rw': kmodpatch.c:535: warning: format '%d' expects type 'int', but argument 5 has type 'size_t' *** Error code 1 Stop in /home/dvg/downloads/kmodpatch. WBR, Vyacheslav Druzhinin -- View this message in context: http://www.nabble.com/RFC%3A-new-utility%2C-kmodpatch-tp21243504p21267890.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 19:17:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40CFB106567D for ; Sat, 3 Jan 2009 19:17:30 +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 C768A8FC14 for ; Sat, 3 Jan 2009 19:17:29 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-020-175.pools.arcor-ip.net [88.66.20.175]) by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis) id 0MKwpI-1LJC0028gu-000290; Sat, 03 Jan 2009 20:17:28 +0100 Received: (qmail 12819 invoked from network); 3 Jan 2009 19:17:28 -0000 Received: from fbsd8.laiers.local (192.168.4.151) by ns1.laiers.local with SMTP; 3 Jan 2009 19:17:28 -0000 From: Max Laier Organization: FreeBSD To: freebsd-current@freebsd.org Date: Sat, 3 Jan 2009 20:17:27 +0100 User-Agent: KMail/1.10.1 (FreeBSD/8.0-CURRENT; KDE/4.1.1; i386; ; ) References: <20090101183026.GA15385@onelab2.iet.unipi.it> <21267890.post@talk.nabble.com> In-Reply-To: <21267890.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901032017.27608.max@love2party.net> X-Provags-ID: V01U2FsdGVkX18eEOOWGfImczFB4gsEL1LOHHkq9+n9td7g8fy XMJMDkXNw+WZ2sq1Yvw7cC2rolExR/6Wytw8dZHbYem+tSVg// PAjOYMZd8ULE6CcPPgbcw== Cc: dvg_lab Subject: Re: RFC: new utility, kmodpatch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 19:17:30 -0000 On Saturday 03 January 2009 19:47:29 dvg_lab wrote: > Hi, > > I mentioned this utility a couple of months ago, and it's now working > > > so i would like to receive feedback on whether this is good to have > > as part of the system, or just keep it as a port (which is what > > i plan to do by default). > > > > In a nutshell, the kmodpatch utility can print or alter the content > > of device/quirk tables in kernel modules (I think Linux has some > > similar tool, though i don't remember the name -- or perhaps it is > > a feature of insmod ?). > > Can't make it on CURRENT (31.12.2008) amd64 > > dvg-nb# make > cc -O2 -pipe -O1 -Wall -Werror -Wunused -g -I/usr/local/include > -L/usr/local/lib -lkvm kmodpatch.c -o kmodpatch > cc1: warnings being treated as errors > kmodpatch.c: In function 'dump': > kmodpatch.c:234: warning: format '%d' expects type 'int', but argument 3 > has type 'size_t' change %d to %zu > kmodpatch.c:291: warning: format '%016llx' expects type 'long long unsigned > int', but argument 3 has type 'uint64_t' change %016llx to %016jx and cast argument three to uintmax_t > kmodpatch.c: In function 'do_rw': > kmodpatch.c:535: warning: format '%d' expects type 'int', but argument 5 > has type 'size_t' See above %zu > *** Error code 1 > > Stop in /home/dvg/downloads/kmodpatch. > > WBR, > Vyacheslav Druzhinin -- /"\ 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-current@FreeBSD.ORG Sat Jan 3 19:33:43 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67BB4106566B for ; Sat, 3 Jan 2009 19:33:43 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by mx1.freebsd.org (Postfix) with ESMTP id ED0198FC0C for ; Sat, 3 Jan 2009 19:33:42 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by ey-out-2122.google.com with SMTP id d26so737923eyd.7 for ; Sat, 03 Jan 2009 11:33:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:mime-version:content-type:content-transfer-encoding :content-disposition; bh=JEPST6jhJfR1rsjxN4Jdl21qiDtF/zQwy04doo7ei6c=; b=NnZVY4DOg5i+Qkp61RIk5nCkn6BzNJK219c/dP31AW4u4/Ws4NSkbWOP+gwWDjADeD cZuEFi7TfnwALp8iwi1ob4akEwqIkfbuURmvi3vzd4hq43Ipe5cQVmxNzdxOh0PQd26Y A/BRiyvImU/j74yjlKo7RDLaw3WHLNTRSoTds= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type :content-transfer-encoding:content-disposition; b=RcDKPp1OjyFejtVwLFdHswtVnXUxUbbKLO+g/BpKOrBj8nH/pgTzYWNz76t9Ox5KFX em0hSX3pui4lOJaWWrwp4U/sCzUNOa7X/UBC5A4PHDvyJeJwwPlctQXQO5PKPpQvHG0u NeuhC0Gn3feG/vY0fE5u7T+cEANn1QZnw3aU8= Received: by 10.66.236.1 with SMTP id j1mr9663249ugh.67.1231011221705; Sat, 03 Jan 2009 11:33:41 -0800 (PST) Received: by 10.67.88.9 with HTTP; Sat, 3 Jan 2009 11:33:41 -0800 (PST) Message-ID: <7d6fde3d0901031133o5e7dfdc6u7ba89ee491c99ba7@mail.gmail.com> Date: Sat, 3 Jan 2009 11:33:41 -0800 From: "Garrett Cooper" To: "Ed Schouten" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: FreeBSD Current Subject: Weird arrow key disappearing act with latest syscons X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 19:33:43 -0000 Hi Ed, First off, thanks for providing libteken, et all to work out MPSAFE issues with the console driver. On a recent version (synced up last night) of CURRENT for my i386 box I'm noticing that when I use my arrow keys to back over existing text, sometimes the text disappears. Sometimes behind the cursor, other times not. Example (of the former): orangebox# pwd /usr/ports/multimedia/audacious-plugins orangebox# make deinstall clean install (move arrow key over second `l' in deinstall) orangebox# make deinstal clean install Please note that this output was `simulated', but I can have a real typescript produced for you if you like. Let me know if/when you need more data :). Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 19:43:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE8B2106566C for ; Sat, 3 Jan 2009 19:43:12 +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 5A32C8FC1B for ; Sat, 3 Jan 2009 19:43:12 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 3B5E41D1CB; Sat, 3 Jan 2009 20:43:11 +0100 (CET) Date: Sat, 3 Jan 2009 20:43:11 +0100 From: Ed Schouten To: Garrett Cooper Message-ID: <20090103194311.GP14235@hoeg.nl> References: <7d6fde3d0901031133o5e7dfdc6u7ba89ee491c99ba7@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="e2bLSPRkEYxxSNev" Content-Disposition: inline In-Reply-To: <7d6fde3d0901031133o5e7dfdc6u7ba89ee491c99ba7@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: FreeBSD Current Subject: Re: Weird arrow key disappearing act with latest syscons X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 19:43:13 -0000 --e2bLSPRkEYxxSNev Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Garrett, * Garrett Cooper wrote: > Please note that this output was `simulated', but I can have a > real typescript produced for you if you like. > Let me know if/when you need more data :). A real typescript would be great. It really depends on the shell you use, its settings, etc. Thanks for reporting the issue! --=20 Ed Schouten WWW: http://80386.nl/ --e2bLSPRkEYxxSNev Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAklfv88ACgkQ52SDGA2eCwUJIwCfY5OWmypAgt8xCvNNjPVtzb/K meUAnRfaZDuz6o9WDk0xhrDhNzAsNzLX =T0F9 -----END PGP SIGNATURE----- --e2bLSPRkEYxxSNev-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 19:46:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8857E106566B for ; Sat, 3 Jan 2009 19:46:18 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout016.mac.com (asmtpout016.mac.com [17.148.16.91]) by mx1.freebsd.org (Postfix) with ESMTP id 72A468FC12 for ; Sat, 3 Jan 2009 19:46:18 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [192.168.1.96] (75-101-29-67.dsl.static.sonic.net [75.101.29.67]) by asmtp016.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KCW00G68UX12V60@asmtp016.mac.com> for freebsd-current@freebsd.org; Sat, 03 Jan 2009 11:46:14 -0800 (PST) Message-id: <43883A46-9219-4B40-9175-137CFCD0E896@mac.com> From: Marcel Moolenaar To: "M. Warner Losh" In-reply-to: <20090103.111324.-98089972.imp@bsdimp.com> Date: Sat, 03 Jan 2009 11:46:13 -0800 References: <440945C2-252E-489A-902E-A499753A5EF8@mac.com> <20090103.104220.513891918.imp@bsdimp.com> <8F22F980-0D4C-4074-8685-3FFAD4558362@mac.com> <20090103.111324.-98089972.imp@bsdimp.com> X-Mailer: Apple Mail (2.930.3) Cc: bsam@ipt.ru, freebsd-current@freebsd.org, fbsdlist@src.cx Subject: Re: gjournal is not automounted any more X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 19:46:18 -0000 On Jan 3, 2009, at 10:13 AM, M. Warner Losh wrote: > : > But my problems are with a platform that has BSD labels, and not > GPT > : > labels, with a proper BSD label on the device. > : > : You don't have GEOM_BSD to service the DIOCGDINFO ioctl(2) > : anymore. We need to change fsck(8) so that it doesn't work > : only on BSD disk labels, but instead obtains the partition > : type (if applicable) in a more generic way so that it also > : applies to other partitioning schemes. > > Agreed. Do you have a proposal for how to do that? The best way to do it is to introduce a function that returns the file system name/type. It could be used by fsck(8), newfs(8), mount(8), etc to determine which variant to invoke. This function is best defined in libgeom, where it can get all the data it needs from the XML. geom_part puts it there anyway. Doing it in userland also makes it easier to actual read the partition and see if there's already a file system. It's one thing to use the partition type as a best guess, but lacking a partitioning scheme on the disk, it may be beneficial to pursue other avenues. Not to mention that it's better to return the actual file system that's there than some guess based on partition type. Thus: I'd like to eliminate the ioctl and do all or most of the work in user space. Thoughts? -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 20:00:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B25E9106566C for ; Sat, 3 Jan 2009 20:00:03 +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 6F8138FC14 for ; Sat, 3 Jan 2009 20:00:03 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 990D71D1CB; Sat, 3 Jan 2009 21:00:02 +0100 (CET) Date: Sat, 3 Jan 2009 21:00:02 +0100 From: Ed Schouten To: Garrett Cooper Message-ID: <20090103200002.GR14235@hoeg.nl> References: <7d6fde3d0901031133o5e7dfdc6u7ba89ee491c99ba7@mail.gmail.com> <20090103194311.GP14235@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4NNqsQ/a67jpuySk" Content-Disposition: inline In-Reply-To: <20090103194311.GP14235@hoeg.nl> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: FreeBSD Current Subject: Re: Weird arrow key disappearing act with latest syscons X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 20:00:04 -0000 --4NNqsQ/a67jpuySk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Garrett, * Ed Schouten wrote: > Hello Garrett, >=20 > * Garrett Cooper wrote: > > Please note that this output was `simulated', but I can have a > > real typescript produced for you if you like. > > Let me know if/when you need more data :). >=20 > A real typescript would be great. It really depends on the shell you > use, its settings, etc. Thanks for reporting the issue! Before I forget: after running script(1), be sure to invoke a `reset'. This makes it easier for me to reproduce. Thanks! --=20 Ed Schouten WWW: http://80386.nl/ --4NNqsQ/a67jpuySk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAklfw8IACgkQ52SDGA2eCwUYvgCfQXpyuoUvkR0GLdZeWKKiKioD XxkAnAoiwwh/OxWPdCy1glvsi0IDn8Ox =dbVw -----END PGP SIGNATURE----- --4NNqsQ/a67jpuySk-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 20:10:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3D121065674 for ; Sat, 3 Jan 2009 20:10:06 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by mx1.freebsd.org (Postfix) with ESMTP id E94AC8FC13 for ; Sat, 3 Jan 2009 20:10:05 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by ug-out-1314.google.com with SMTP id 30so1186977ugs.39 for ; Sat, 03 Jan 2009 12:10:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=0et8M0Ac0NqOeQ3+gVrHcJV+UCJCyDHJn2N+MnxDvoU=; b=DfxUKRbEnhFyJVcZWLoL0Q7F7MyyeGwAgGGoYQt4Cd/qdt3CcU0CcTqQ2DzypbGEbA sbB4xq+a7oj7n580yazvGcZdQdoDiv/hmhWY7nE3+QssMM21ghaxpp/tZgY1Z74meMif Guq/dM387ttrOHSJhCAW8pFjkg97u2xR2PD/0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=cGIpYQBMLojdTZMCVd/WCkkO/cKBf7FQ4GZh7v7xnxm6/u8mc1DQKQm+TjvMJzTjNB xnLw2FJqFXG47mYCMbVWMhJJFv0NtgUxtTSM2oLtXLY2xLT6ulVgYAYmSb8dQIsIBECa 2DofJUiMCqM99G/YtaBHbskMU3oMnh0HhJ4dU= Received: by 10.67.116.7 with SMTP id t7mr12013775ugm.63.1231013404710; Sat, 03 Jan 2009 12:10:04 -0800 (PST) Received: by 10.67.88.9 with HTTP; Sat, 3 Jan 2009 12:10:04 -0800 (PST) Message-ID: <7d6fde3d0901031210h2bcceeo1ceae4d3a481a00f@mail.gmail.com> Date: Sat, 3 Jan 2009 12:10:04 -0800 From: "Garrett Cooper" To: "Ed Schouten" In-Reply-To: <20090103194311.GP14235@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_69485_1568334.1231013404701" References: <7d6fde3d0901031133o5e7dfdc6u7ba89ee491c99ba7@mail.gmail.com> <20090103194311.GP14235@hoeg.nl> Cc: FreeBSD Current Subject: Re: Weird arrow key disappearing act with latest syscons X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 20:10:07 -0000 ------=_Part_69485_1568334.1231013404701 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Sat, Jan 3, 2009 at 11:43 AM, Ed Schouten wrote: > Hello Garrett, > > * Garrett Cooper wrote: >> Please note that this output was `simulated', but I can have a >> real typescript produced for you if you like. >> Let me know if/when you need more data :). > > A real typescript would be great. It really depends on the shell you > use, its settings, etc. Thanks for reporting the issue! Ah, I think I know what it is. When logged in as root I use tcsh (to avoid linker issues if my build of CURRENT goes south), and I also am using the following settings in rc.conf (note keyrate): font8x14="NO" font8x16="NO" font8x8="NO" saver="blank" scrnmap="NO" keyrate="fast" If you take tcsh, run it from left to right with the keyboard, semi-continuously with keyrate="fast", characters will disappear on the console. I've attached a tarball with a typescript for you, my dmesg, and uname. Let me know if there's anything else you need. Thanks! -Garrett ------=_Part_69485_1568334.1231013404701 Content-Type: application/octet-stream; name=tty-issue.tbz2 Content-Transfer-Encoding: base64 X-Attachment-Id: f_fpipl8x81 Content-Disposition: attachment; filename=tty-issue.tbz2 QlpoOTFBWSZTWVuA4AYAXV9/kvz3WMh85///////+/////AEAAgAAAhgLZ32gAKaAAAAAAAAKAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIaQqaekyYaBMmJpk000wJpgAmAQyBgC ZBjSMDgaBoBoGhoANDIaaAGmgGgADIYgANDgaBoBoGhoANDIaaAGmgGgADIYgANBIqpoyAaGgANB o0AAMhoyMgaA0HqGgaAA4GgaAaBoaADQyGmgBpoBoAAyGIADQKkiBACACYkwJo0CZMImTNE0Gmnq NAmp5MpsU/Qk71UX84O2Fiq7VVFbaAHWghKrDHkOAIQRAVRQ7FSUVCOTAxKiYUSwUKKi1EAkam52 P6dqAFdE5CuZgA5VBILwI/e2jgZHiDEUlUU5nLzvDOUdR8paZFzuPpNgf/ieKf9JSajMtKPqkmst LJn1VrmHyDDFrMD+P98scDjtS1q5sDZNUtN/+BsLFFS1xaqlSLFFXlixaWLGN5eXL3l5eVKlSVKM KRYVLG6dsvOeYljM5zXnslo0RkjRGCLozRdGCNZRqLFiwon+ZtNpfNVjUYFyi5kYnWZG/P1FHEo2 H5D8p085ifu1f01rPI7cjgaGJc4lBxKG8xOo1555nhpOjGWNX6qseapNpRqMCxYsWLCiixYsWLFi hco2lGZRrKOco8ijoKPOjWjrdKuy6ZI7kWSOZHMWDyTcbOUlFHIo5Ci4o5FGJRyORYzMjmmu56OX 3f7pJxecMnZGMKB+VTo1vQs4y6lyiaDA3cCWpYSiAw9000D2iqH20xtf7B5Sjej6cHPJH04In+Jq Pk8/7b7yO1LPaV5FDvo/lKH6y+q5b5y0t9Xy/y+EPoKIMI7CucAaFwCkSdHCVuG2g/AjhJDPCwDT Rmf2hKLpgT6BXiYhyPnGY0KK9dz8R/Ynh8LfPaeo3RPCbjwOLhVTlJH+ZlJHuMixyHtsh2lo2To+ v68Fz0eaN5P4HIjZJuOMiL1HSUNCgWkT9/ScEYE6Hm32cr8T8Y/4RoQ6TkJ2H+MtDmLnYfCTiUde 78tZHYcyxwKKM72Ddnshck+IyJKKGuOwG06U3dOQ6EFHQJmnQN5/eHQkLnWff4dXxzdX6Y6TpKKi 1DaI6JvQ6EcxjyRgmRhOgsWKifR2mqZIxGiUiyf4I/yRcTGYI9Fp9e2Yih/2PT8h/L4G6ewuc2wi eYwInI/Wbh+IqREf6FIg+AojwLFtfb7quWoTYf5nMfObjM9BXwUaTlLCxJ9B0txHzGEkemSj6/Ee ib4VwP2E7TaHsNx8h50ceR0FFFFCj4y5+vkb/sZHcXEyO4wGQYV1mBn04JgV5zQoo6kv7kkwOzWP OH2h/rJ8J8J0HSR2nzH0nrOp6Q+pPzJwOY6zqPRXUTxO1Padh7H1Kcy1VWZ3HXPT9R6pI3ZSSf7i ixU7SHL85xPbPT/EZjxPScjokj7U4Hs7Ud5vkjoLH/Rl7ZepK63yzmI/WZGJyNrr6N4WNhU9B6Tz nXwnsDtO02btBPjnvCxQS4PbtORc+g8pqxKsYcdR85zncYyJJrNOyHz1a9jl2GHZIjOF0gyxT5uj Z9msvjbzpuTvMPKHVKlHynsKLlHuPEYFz3HkYFixkPWUVRmNCx0IYF0YI1yTpSKKNo6R7Tq6TKZT 1+B5FB4T5ZuI4GswPgMzMTHdznQWP5t/Dh47jYkd515mpIMZtHRLZXnicjac0h7xK5pVhOA76H6S hRQooUakNm8mckVEh8BPZJFv/hXYhuYszKGcy9ow5DaNLyTvNqL7B90MZI0269UnoljqKy0FvWTp tFZmRth34g9vb7tmEdxq14TE9RvKPWP1ljAosUWLFD7yoOmpSvZLTE7I+Y17Yj224GfN8UPDj0mV E9fjJGrcY2qHZCpt5TiKFHSOJ9p2Wh4RtLDej+Gyx1HNL8z3c0N3fJFt2waHyHoOn6ZmZU7sOg6T +ByLyS5XR75zWXSMSpCW++YHyly+BYo6Ch8xj8YxFiiaGBYsWLExI3UkkWnR8Hyflqd2B3d/xdaJ HWejyz0JuEnUnzJ0Jsm36vdOgeaUg7kXFjvIm2SKnwDEi/5icZI+mavYdDWNhQUeZHijiRiPxnwp B9IPl6I4x4At5xkRPt83z6YHluRzyR8epPV8Hu6/NpywO6GvxmHVOQ3m6SPR/35zVU9XHn1mw+bn PmzjHGSP/cMTWRhJG8ilq5+g4V8uSI1JSKSkUm6hOrdgaFHMUecoXKPWUfGUc+7X5Ev6Tc6fm5dV ueJHbKF7a+y9YdZPGHwGHbznsNRsr+jSQ+y1D9NSqKvIb51cpUq6SNZQTcUbSpE0EojKkH6D2nu5 SZlXLFjzFc/wj6ivllUlKSqjGJtMYm02m02m04YWYswVeJRAIrQ+P4T5wxPUm9KSk0LfzE7zVvMD M859BgajUYmYzPrKxj9EkZLZf4ZmRIwRSOSPjN558DrOg8UfYJuIobDIUVJB1kT4ivyYPrGJ7Oa9 Va0tKqpUqvyH+B86HR9h3HefnNR/OP7Cx7ztGhRiPxHmP0npPaf8nsLDM9hkajwMTEyLmQufEfqO idvQe9HGSOR5jzE7CpRUhP0FFijvKkeYUPcdZzFzURUcJOk5yjqk3lyGZYPYc/6JjJ3HQeMZnpni Yz6eXWSMN15uPhnzlHrT8ipodxRh7i2F9nw/Frsy+v3mZ+Y+zc/TLKS0O4nMUSiiURQ4nidp+IsO owjEGRgiiLEoolJKLJJYtJRkZHWfNiNVGJiWmRbojTAy1y2pJK1lyxoajUZ6bOapOvBOH2xini9u oTUKJKSSegobSkdcWMj9p+Y0fX4x9kn2yRaLRjH/cZTYROksfeUeoseJbGc8wLReeRLkfaVGNGRU zn8RSOp0H3mMRc2VY4DMsRgay02FalVSSXO0GFxYeGR4GhgaCijyTFPcctp5zXyk3JPUR5ptDW/l kjciWOqdti5iQ3TkMEwkjnO0nXxMTXkWBtKSWORaP/iQaz1n1GJaY6qqkoooqKKKKKKkkzN8dBYa kdRFI2XkMiJtFJJMpRVegzPMmDAxLpgakkUmvblcuXL3LlxUii4wSSURMjG51c2RwLijI6z6rFH+ sqNRzmJfwr+H5a3EaidpmcJu4dIdsdUK6S5UyI7zWLHSUOE6k3o1zUVNaegwNAmznRxRuNE1mvPr qtx3GySxgZEZQ4X2xexjNuJa81S0ljiW1zqLQ0MD4jrLHmOqdSPfPd5HoMz0mZxliixbM160a0mM wMD48DKaSpKNDQuUbT1mBifGaFy+ceupNs1osWKNDZdK0wE/VGhqOO+YlzQsTWUWKG9NZt0XTv3G RqxWFeROiKJoJQlkdptJY8xrjxXOuR2FpEsce47xgTHvpaSX16k/qSokeRYsWLIsRR+ssXLFixdF i5UvKii1VVVVVVoqxRRRRRRRVpYqqKKFFFFFFFFFFyiixYoouWLCpUoooosUWKKKKKKKKxoyTmeB dHFLFztKFFjAmVDhl3FjibknCZE5hSNZwOcntNtyuCM4zIeco+EFSSUULGEotWsseib8xYuMijwF DHAsOF7Vr7LyrS/8RgcJMMLmpeWbbdjjj92ozPioajQsfGKfMUH/J9xUtVZVDhQ5GqixPI4jlcbS iR/wdp3I8DxLnpLewxRaYSioqyLFoWKHq9iV2JskxJ8jiYG6IUf8yUE9E1ScZHMcDwk1DUcjgUcR Yo/Lcwk+Dr332HqPtO6PQaEyJDeeg62sj4D9Bge07tCT2lJDQosUbT4TaPMYXqSp5zsMvOYxxoxP vko81zrxztarmNRRuWhrLmtMiPSf2dJqMUdpvh+zjG0MUYHDwrdwmeY1BNdgzPMeJY6jyPUXmEqK oowKPgmxySw1SxSHoy9fzd8ZaZms3CjYWMo9+WRenf6ihaKKRhSdQ7zoPOY7l5VSvQOUaSOztsfE necJ6Pvxgz3m8+M3DD+s9Zy8a2a/0lHMbDHgdth3HcXLHSbC3kVMJRVCjAosWnXJyk7TdE8Np81E 3WLGRgkckOBtNpqKFjqmMnZiZZHMbkwmR1Wm8pGBGR8BoYJrRoZHKazqRkRxSiND74VkbDVxMzE5 qy3bdC85jylEYHE2TmSTQwKLzA15G8qNms2FTZe2Z4GI6CjAqWlRUUUWKKnORqiZmzzhmMzZlmaT WcIzOgwmA28J0nJFnrbX8kozxMOQ5ReGMVobjWZG4+PcWnKVFUUWKKm3VFHKchl1HKHbcWxoyDE6 TCQuZHAsWNQXMB1mZgi/CRxMs/xIbp+o1ncY9Eqc++NZuMY3HA2RnyKOaWJU1aXK6S/dzlofj0kd Zok6sdhQ18Bim41nHiVRx0OaXNsvecY0mzpNxkXmcbxuOaUFSjUa/E3HAat+3RHDYYbiYmkyTI+k 1GZRiaioo0N5q0oozLFi+81nMdE2G82BM8+02eYvOQ3m0oyOATQ4ThO6TowOgrm3zJnhG42lS1ax YukzlAqNtMxocdTpxkwjNFdWJqnysJrHPmmATUbDAmqjaJNRqomo6y0cT+B0cxUubRc5zVOrWM1D noso1yhOSI5j4sWu5zGsv2D7On2jEofq+SS5ojrNRc3mw6i8lZTadpyRijNGh1HUYEwNhgXFyxc2 C5cuYSUYXNlpUzmc1mY0NDQuXq2Ni5gYF4i6KIqVLTCWl5hNJpNJnLy8ymUylpiZlsKKMDIyMzGJ GOOOOOd75ZZWjAo2I1otP1k+oM5LxKlDUbC0GBR+woyN8kWH1yoNDabTcbzabTM/hRGhRRoYmhoY lVGBjjMTGaTKTSY5FyjMsXMzMxPshxTimcjM1GV2KYpZMZpNJfKapUscSZotJe5LDRHRb+cdB8vy mBMo1rJBTZY3SVxY4m3cc51SYsI8x/TvazCS2suS8TbKp6EiHnKkkFyhP4iibSge+vTUI+4of6Qo f3Jzm89iUixRqPA9R+Q/HR8n0u3I68J9NFTedZk/ceE9JHZ3F7Sp/GZDmKPyH3nQXJsLjM+M6ZRK wNZ1TGbpumOPvBqGvoqN46yjYURiJZDYjYjUD1aT4T8c/sNUSfqMTI/pqz2dqZYRzfKfcTmSPnMM DzGCSxc/A9gko+E/aehBPpN6fuPUnpNiYD8PafnIXJ+onoLEbi9n38jE5SbykjpgofqzI55UiYBk KIipJPOXkzLo5zE74TaZGJVFDf1UJmfaaFznk5rzQ0lH7EZIT8shuEVJIoj95DvOo0htLFtEdgh/ cXDqCjpKI3yJlGYvITA/8qWH/eUcRUTylI7zmC1jkfuk2GH/vX/XIwN8mJYYHNJ5yc6RO0ooVFCV IMJzlEnYnE5HaZGo2D85rLBqKKLme+cTYgmsyOJDUc56E4GIdxcoZ6RUNxZPMejdhcPpTpOs2HDc FkqkdKNh4l07CfYTkZmBrKg85UI8CoUeP7P/Vz/XEHT0k7U65OgwP3aQzk95yIZcUHxGJPhxo7zp k7EJfedxPQlCWDwLmyTYeEiG0jtN4xNeBznnLEouE3BkSSpRRHkVJHEokXLSRYixwNCHjck1PMEo NhsLJ6ScU7Lppl6VzYlHSYHVIh7BgheIj4Sww1lktNXEh3ZmIxfFM05HpkuZHpTUOpOwtDgQuhzm 0P9tCxRwPMbp3jWUXibSvAbz7TWLSRgjA8xxHMPgK5jUcDEbjMLCjvNDUdg69CbyT3bznz6uJfKS LphGBC2Z/bie5HREix3FDVObXC0WRxPUb+zykjA8tprPKcicuosTeZHwZzUHYTuIuR0lBc8ii0OY Q1klFjwPfiLmBDzlCWGhQ7TenOlznLnoOY6TsLHCdLvOfrTZJHRIhpFkbNeehfVqmwz6DZGme6TU nnLkzhHp/oqlfbuNZsOR/scxGqGs2ksk/CaEJ1GqTyMZI8RKKvkbDpKJRR3no1nfImouTWYms8TW XJqNpYbDtk4I2HMdZZN3yai6HX+cLH4ZLGJ4m+RWs80kXS02nxFjrMC5kQ3yXLWMSHXgewmB2yIe R0j9x2GJc4z4PA3kuH/BQdAVCoruJJ+CdRLidJdLTinlHiXIS5UMzsPVxkdc45G0o5CpYvJ6y8XN LcIUckVc1DuKOgdxRcchtlzYdJuTSSLFjI6Nm6icX/axSSglVIhSUVpIMyiewsWgoqSR0mWXcO83 jpH6fEp+38LnYeJY1pslT3Hvqf1l3+X5y36y1k16hug/jPhRuyKixH6DEsjEqJRQiiiVDsqQxChF BgP2QyG2SP6C5kbcCJ6D+abdY8Uf28RqRLGoykRiCzcR+88PpxjKfheVaXlT8lA+dKQpKRSVBqNq Lft6pc3f0HI6JH+PSVR5xHQwweI+PO4eY6o2lPg2fEXJs/ec+/SbO/8iePV5cY4BcbLNgqOkUiWk knKf6ZvbuWlDiJsKkfgXtNWvjiOdFE6OGYlprOo6Uw1NxMyciObrETUgdRSN+R7kqSSHHxC1CoqR UqRSVJFEVIpTGHOdJvk714x4Dr5xwyK1mRKKOBFSw3hRwfjJYwKPTk48SO2LnrOoH950Gg8EYFy8 sYFoXKLli0sVFih+O5cvLFRYosWLFiiWKLGJYoLFy8sVFFCipRUf30LFSio9ZRYiiiiUGIUQnI9B w2EYi5DoomEnjN0MzI6BRcfmMplF5voFFQkqVOwfgTH5tY4G7ATP/yf03SGsUg8j4ixto1oxkHxC gykxjWcxgcx8R17z1HnMRhga5gajUchR6MDUUf0UOw/V3aJzp28sjcFHYR6CcUYyEPitZaQ6/AtL 663kbInXsGWhthnWsaohSGJKGJoc0D00RUoShRUlFRUihFFEpKFFSVUKoUUUUFFEooooooShF2Kj XqMpmMDRIPEqevwlheKmqsRgWOZDsliSPNkZBfVIhwsTnKJRRKKJRpJ7Xi2dJGoTVSJURUjWSKRy KEopJCzl9RVGMYoxDEr1FXMsL1UiLlSWreeYdkoudhReXFBQ56NdFV5rSTI/FaeqS5aaSJ9J6Deb zAOoR2E1WEWJlPM5HDTgPZo9Xqz4AnkcOFjrwSWTb4SHzlSENqth0GsTWdxjJJaSPy8S5PMlcCNo JYWGme4jDDf8XeS8ND0e/CSNVE66gPI40RwPh9YuUUanwFy5s79+IqWYFaTWT+ySN+Oc332bMeFs qw0kjXpmRjlgbBRgRMcqr168SeNHvopR5D3fgc1a85GhsPVJ1c2/EYlE2paWL46QmRvIzRsjsH3I 9xhJlzfUHtOJvGwzj7q6j7DiudhkNgXE/zNyGhfH1QunSKlQwJSg0SikpF0slkWS/f1Bfq1ZTwmE 18TA1k2FDfrmwx5DUbpI3B5+J9UkerR10yqE5twbN86Vp/32mZ3HkSiic+ydcNqRzxEc9DrInSby iii+JXRJJSGza8xl1TIcJIxAzkj4e01T1EjUR/OgwDfJHMYGzMmJkVDp1kbCRRORgekakwRqLI7C spWyckYwwiC/YMq0Imhfec6ExkTdJGNSjQftm0lFGvSJ3Uuc0kYX9sORxbtZY2RgG+pEcdUSZZYC 53Bg1jmkjXJVaihpIfyT3zm16u43Q7TekGo3dhZIhcHGKIvD/en4fvJ795JxcnTEbD3D6Cij35yr FhefSWJ0ETNH4vn1/MrQzH6NeP3fIkn1FDMoWPMaFqNfSIt9p71j3lEyPVLGoYFD8LzzeMkWmupJ MjQ4FG44nUZGRtsdZRgVmmEsSb5cm/M0N5oYn2nadnO2dZyh7CfaWiOnIsRyk+Vk+6mBQjrz1SE6 KW+I1jdY+c/FGVq9ljkJcm04hsLQxNgmwO6jPI2lkaYTORRga5Im5JPeai6pHXDphYX5tgXT+OpE w4azpOAqWKoFiwosWLCiihRQH1kxGSI/FLCrhaRapc8DhG0ucCbAaiQn8xq+cY6rEzhKkoUSooqQ oUQoqSJRRKKChQhnRJOg+M7sSdhznZJxNBFDrF0HmoMy3fEQqvpyObH3dBloJz8uG5mfUP2GYdbP gfQPJCWbHEvuMyRedwVEo0dpRlUbuYrIdJzloatZOS3DZ/HGnza7Mkbp+gwMt+PlrvLw7jrLi8kT hsFIOdSTOZl/0lCUn5kfWRhbrkNaSR0FQ81UqDcUUZIYA6Sxxxsc3Sef4xjRcvwEnMdQxnUTpOjZ JG703GhzGUkaR1mBfMyLXKgvI7jsOgosULChyMSb7aVkMBmbYMqgN5UsFiyKKEqRYefbaLF7YWLV YVF74A0hc3yO/sSTUiGtIubDjCLdCKRYSaypqgqVJG2Ii5yux3kTfG9nRYlyP0TKirpoRGFsd0/f iXJrlZGcbmkpD9pjJGeX9fy6FwYUcaNJEqF09+JFlCX0p0hYqnVLmaB+JGEPcKJv1apgMLEXLSRR QzvE7sIYHcUYyqFJLWkiLhq0szwEtgMhkSih1fKXRqNNSaGkSpSKIlygipe0iSqhLVCVSJFFJEmN F6jUUVLHDLtkXg8k6cCWavrNCRkMY1XIoXpGMfHohr2WRM0Jj0dElFGgvETVJKR/OGAtLjadhcbv TLaIZInSNxio9R5uN4Rme3VaTVJJKFuN5SRsoXq0XvuiSLh0ZESWyDKUZTHXO6HOKkh+s8+UHwEd E/NGFo41JrLz4zWjAjvhlJJ5ZfCUe0kefM6KBsFERrLWhW8c0OZCuYvITqFRvkgoUSRUKRIoikkj jNtzEqjZoOKKRNhgWkfOCiI378Zz0SO0zhmMiyPh1EcjhL1Q/L6vlw+E5+O02Uely+TbGRkjgkRz UkRqF67CbjomuUqohUQpMBz+z+tRY2+8+/KN4V2GstIhboSrEv9I4kTkPQ+bieQeowl4UPHIrs7w 8OEbxUobdCLwkxLCioWLFliwooUUUUUUUUUUa3TM2f6AyOaseo+4YSIazXsOWw2b0VjsesqRIzOm yQcv6sZtwImfQcxeSNfK0jaUReuF5cTQDq6R0cJIjBKk0JsJFSRqmSS5KoUR6ISLCWKJUqvzWS0K g2HOi0kh5G7h+MvrorQWkkmGQwzS1pJNLZL0XJHI2zq+wt3mJHErURNko1bTwhNEg8SWBgZB3SRi RzyWskJqIrVk4CWKlITuE7BifuMtOubNg1mOsKqRRYykHE4EScJNTwPCbkhj+0/y/Ia3b0JJG84S RSKkhUiRwSrapYvRKVAYHrnfkTElGRMixRUkWhbCMcPpO2Ble35of+p1yRRtQ+mTcWEmkqJLR6S+ Raw2GGBrhbBLJRc1yYeqSMJaiJo7hthpmNCw+ZrMyRc0L28IyPzeozRRcsS8/RO9YZjCTxkscxtS xpEOZyiSiPNcQesnamKFJl5WI4GY/JusRMpIuUS0xsLa5ItdJPNhH1RI2rI590OqbxKJQooowkiz cFqJZZNhGjq/VVSjDF9hkPZhyKmJuR5ovbiiHKSSkCieeJlcsXDVjMo3S3JDNGhijrdRYwqftm2P ybcBW6dW/dSRgKm32C8kdQ7SKSQ3F8sCMixglixbBL3vIapzZFEvEhfx2WuaWSGdTZgZa8IVKrLA l5I/2zjS+wtJGKI11RsysWLapc1FpYli1GiZERuLodYrHLGQVMZI4WFGP/VRlP2BnC78paSWreWN yZSiVqrC5uiSNnLJDdJH0EYkukysdhsS2oSeu+uHIfnkWmJgLG06ZLHl85kMYZI2kVGaShMJgZkj gG+GKKpGeZ9GUkG+IkxlE5ocxwoXKdpUBiPvkjcFy4bydtR07OD/famkrMDp/tOc4T3k9iciRJ3G ZHE+XKQPXJxkaEoolFEoolFEookUUKKCgoUFIigpEVqKLH3DeaO9J9xznTJGhH9QmpI30O+SP/us myM6kT9dtcfKdIeXNJGZRH7yoGY2ihQoUKKChQoUKFCigp8KP4vinh4Z8qNkOJsLlFHUegh/dSI6 +MiGY4b+6bxnifHpgGn0EfCWTAYGsljQ6BSRDH/r/zL+TAljEHVLL1ePolySf/ZhPKmDH9MVIXEl yRXIZj4z7UkR1GBZJHNSCaQ5FpJJgbMGNXrmDxKKO89xQsXLB5ygsC+Uot4+F88YoUaEyjDv+BPe 54wMvgGMmIqGs/UJzSRuIEf4u5IpwoSC3AcAMA== ------=_Part_69485_1568334.1231013404701-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 20:11:04 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 192CD106564A for ; Sat, 3 Jan 2009 20:11:04 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.104]) by mx1.freebsd.org (Postfix) with ESMTP id 81F708FC12 for ; Sat, 3 Jan 2009 20:11:03 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from mx-av-05.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-03.forthnet.gr (8.14.3/8.14.3) with ESMTP id n03JwTwG020750; Sat, 3 Jan 2009 21:58:29 +0200 Received: from MX-IN-05.forthnet.gr (mx-in-05.forthnet.gr [193.92.150.30]) by mx-av-05.forthnet.gr (8.14.3/8.14.3) with ESMTP id n03JvUjm021428; Sat, 3 Jan 2009 21:57:30 +0200 Received: from kobe.laptop (ppp160-148.adsl.forthnet.gr [194.219.40.148]) by MX-IN-05.forthnet.gr (8.14.3/8.14.3) with ESMTP id n03JvSmH022059; Sat, 3 Jan 2009 21:57:29 +0200 Authentication-Results: MX-IN-05.forthnet.gr smtp.mail=keramida@freebsd.org; spf=permerror Authentication-Results: MX-IN-05.forthnet.gr header.from=keramida@freebsd.org; sender-id=permerror Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id n03JvSEn003652; Sat, 3 Jan 2009 21:57:28 +0200 (EET) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id n03JvRce003651; Sat, 3 Jan 2009 21:57:27 +0200 (EET) (envelope-from keramida@freebsd.org) From: Giorgos Keramidas To: Alfred Perlstein , Mark Linimon References: <20081222214010.GA18389@elvis.mu.org> <20081224215330.3ccc613d@gluon> <874p0t2iyw.fsf_-_@kobe.laptop> Date: Sat, 03 Jan 2009 21:57:27 +0200 In-Reply-To: <874p0t2iyw.fsf_-_@kobe.laptop> (Giorgos Keramidas's message of "Thu, 25 Dec 2008 02:31:51 +0200") Message-ID: <87ljtsnowo.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: current@freebsd.org, Hans Petter Selasky Subject: Re: Tracking the open USB2 issues? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 20:11:04 -0000 On Thu, 25 Dec 2008 02:31:51 +0200, Giorgos Keramidas wrote: > Just picking one random email in the usb threads to reply to... > > Do we keep a list of open issues with the new USB stack somewhere? On Wed, 24 Dec 2008 19:31:30 -0800, Alfred Perlstein wrote: > * Mark Linimon [081224 19:27] wrote: >> bleh. Forget my suggestion to s/usb/usb2/ -- that's overloaded with >> USB 2.0 in existing PRs. Try s/usb/newusb/ instead. > > Ok we can do that. On Wed, 24 Dec 2008 23:27:13 -0800, Garrett Cooper wrote: > Is the gnats page customizable? If so i'd just mention that the new > USB PR's should be filed under usb2. Cool! I like the [newusb] tag. It avoids confusion with "USB version 2.0" and we can always switch to [whatever] easily by searching for the [newusb] tag and replacing later if a better option surfaces :) From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 21:26:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB688106564A for ; Sat, 3 Jan 2009 21:26:52 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: from smtp819.mail.ird.yahoo.com (smtp819.mail.ird.yahoo.com [77.238.189.19]) by mx1.freebsd.org (Postfix) with SMTP id 0C8188FC1A for ; Sat, 3 Jan 2009 21:26:51 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: (qmail 40125 invoked from network); 3 Jan 2009 21:26:50 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:From:To:Subject:Date:User-Agent:Cc:References:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-Disposition:Message-Id; b=MpszbwhXbo6cH2MnMa8j2XdvriLxWpXJ2WjQETy3nJp7h17KN4nFwdD07kPIEHru0KWj2rq92MyithqLu+j+K0vaqkRRpb2+uwz7/CzmeMef0H1VQg2ovwBJfkGdWZM+Aj5gj3g7Yrqe/5q5VeYGaJTwMQB4BGHmg1paC6+MfVU= ; Received: from unknown (HELO w2fzz0vc03.aah-go-on.com) (Thomas.Sparrevohn@86.147.162.100 with login) by smtp819.mail.ird.yahoo.com with SMTP; 3 Jan 2009 21:26:50 -0000 X-YMail-OSG: .bICe70VM1n4qEEIAmaLpv41a0r7oejSfY6EXppnxXlbQUR4sT38veGNRycO4ld75k8_wf8TKqxbUlE2aTT7t161.RANZPtHz_nHmRV7jPhPW_B9I9YMkaKsxpPkXFp58gWo720P_hTmpx6MmA9fOutn X-Yahoo-Newman-Property: ymail-3 From: Thomas Sparrevohn To: freebsd-current@freebsd.org Date: Sat, 3 Jan 2009 21:26:43 +0000 User-Agent: KMail/1.9.10 References: <495E8F00.2050309@grohnwaldt.eu> <200901030224.44187.hselasky@c2i.net> <495FAD98.2010503@grohnwaldt.eu> In-Reply-To: <495FAD98.2010503@grohnwaldt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901032126.44821.Thomas.Sparrevohn@btinternet.com> Cc: Uwe Grohnwaldt , current@freebsd.org Subject: Re: panic on (hdd)load X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 21:26:53 -0000 On Saturday 03 January 2009 18:25:28 Uwe Grohnwaldt wrote: > I tried the patch and disabled umass - but the panic comes after a short > time of hdd-i/o. I got the same error but due to the umass dma issue - It may not be the only place that triggers that error - last time around I was only one who suffered that error so it tricky to debug Try to disable all USB if you can and see if that helps otherwise check devices using dma one by one its a pain ;-) Try to see if you can isolate when the Port multiplier logic was applied to the version you are running - for CURRENT that was after 10/4-2007 and try to run with the ATA subsystem from then From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 21:53:32 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3916106566C for ; Sat, 3 Jan 2009 21:53:32 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: from smtp819.mail.ird.yahoo.com (smtp819.mail.ird.yahoo.com [77.238.189.19]) by mx1.freebsd.org (Postfix) with SMTP id D2B3B8FC12 for ; Sat, 3 Jan 2009 21:53:31 +0000 (UTC) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: (qmail 40125 invoked from network); 3 Jan 2009 21:26:50 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:From:To:Subject:Date:User-Agent:Cc:References:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Content-Disposition:Message-Id; b=MpszbwhXbo6cH2MnMa8j2XdvriLxWpXJ2WjQETy3nJp7h17KN4nFwdD07kPIEHru0KWj2rq92MyithqLu+j+K0vaqkRRpb2+uwz7/CzmeMef0H1VQg2ovwBJfkGdWZM+Aj5gj3g7Yrqe/5q5VeYGaJTwMQB4BGHmg1paC6+MfVU= ; Received: from unknown (HELO w2fzz0vc03.aah-go-on.com) (Thomas.Sparrevohn@86.147.162.100 with login) by smtp819.mail.ird.yahoo.com with SMTP; 3 Jan 2009 21:26:50 -0000 X-YMail-OSG: .bICe70VM1n4qEEIAmaLpv41a0r7oejSfY6EXppnxXlbQUR4sT38veGNRycO4ld75k8_wf8TKqxbUlE2aTT7t161.RANZPtHz_nHmRV7jPhPW_B9I9YMkaKsxpPkXFp58gWo720P_hTmpx6MmA9fOutn X-Yahoo-Newman-Property: ymail-3 From: Thomas Sparrevohn To: freebsd-current@freebsd.org Date: Sat, 3 Jan 2009 21:26:43 +0000 User-Agent: KMail/1.9.10 References: <495E8F00.2050309@grohnwaldt.eu> <200901030224.44187.hselasky@c2i.net> <495FAD98.2010503@grohnwaldt.eu> In-Reply-To: <495FAD98.2010503@grohnwaldt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901032126.44821.Thomas.Sparrevohn@btinternet.com> Cc: Uwe Grohnwaldt , current@freebsd.org Subject: Re: panic on (hdd)load X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 21:53:35 -0000 On Saturday 03 January 2009 18:25:28 Uwe Grohnwaldt wrote: > I tried the patch and disabled umass - but the panic comes after a short > time of hdd-i/o. I got the same error but due to the umass dma issue - It may not be the only place that triggers that error - last time around I was only one who suffered that error so it tricky to debug Try to disable all USB if you can and see if that helps otherwise check devices using dma one by one its a pain ;-) Try to see if you can isolate when the Port multiplier logic was applied to the version you are running - for CURRENT that was after 10/4-2007 and try to run with the ATA subsystem from then From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 21:57:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 230F4106566B for ; Sat, 3 Jan 2009 21:57:42 +0000 (UTC) (envelope-from jos@catnook.com) Received: from lizzy.dyndns.org (209-204-188-132.dsl.static.sonic.net [209.204.188.132]) by mx1.freebsd.org (Postfix) with SMTP id B1CD58FC13 for ; Sat, 3 Jan 2009 21:57:41 +0000 (UTC) (envelope-from jos@catnook.com) Received: (qmail 1649 invoked by uid 1000); 3 Jan 2009 21:58:10 -0000 Date: Sat, 3 Jan 2009 13:58:10 -0800 From: Jos Backus To: Marcel Moolenaar Message-ID: <20090103215810.GA1527@lizzy.catnook.local> References: <3a142e750812201747o339d7298p11236bb02c7f858f@mail.gmail.com> <20081223050425.GA89448@citylink.fud.org.nz> <6D4A57D3-3F6D-43E6-9B69-95514F69C57A@mac.com> <20081226080146.GB25406@dragon.NUXI.org> <20081227191223.GB31177@lizzy.catnook.local> <9F29EF5C-B4FD-4273-8BE9-C134B983A1E1@mac.com> <20090101031634.GD64075@lizzy.catnook.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: Changed names of logical disks on recent -CURRENT: part of logical disks not accessible now X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jos@catnook.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 21:57:42 -0000 On Sat, Jan 03, 2009 at 08:30:08AM -0800, Marcel Moolenaar wrote: > "dd if=/dev/zero of=/dev/ad0 count=1 oseek=1" is what you > need. As you say, the BSD disklabel lives in the slice, > so the one in sector 1 (counting from 0) is the stale one > and the one preventing you from booting. lizzy:~# dd if=/dev/zero of=/dev/ad0 count=1 oseek=1 dd: /dev/ad0: Operation not permitted lizzy:~# sysctl kern.geom.debugflags=16 kern.geom.debugflags: 0 -> 16 lizzy:~# dd if=/dev/zero of=/dev/ad0 count=1 oseek=1 1+0 records in 1+0 records out 512 bytes transferred in 0.000164 secs (3121343 bytes/sec) lizzy:~# does the trick. Thanks Marcel! -- Jos Backus jos at catnook.com From owner-freebsd-current@FreeBSD.ORG Sat Jan 3 20:07:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 938D9106564A for ; Sat, 3 Jan 2009 20:07:53 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id 7046F8FC08 for ; Sat, 3 Jan 2009 20:07:53 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1LJCmm-0006BQ-Ed for freebsd-current@freebsd.org; Sat, 03 Jan 2009 12:07:52 -0800 Message-ID: <21268756.post@talk.nabble.com> Date: Sat, 3 Jan 2009 12:07:52 -0800 (PST) From: Vyacheslav Druzhinin To: freebsd-current@freebsd.org In-Reply-To: <200901032017.27608.max@love2party.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: dvg@tjc.ru References: <20090101183026.GA15385@onelab2.iet.unipi.it> <21267890.post@talk.nabble.com> <200901032017.27608.max@love2party.net> X-Mailman-Approved-At: Sat, 03 Jan 2009 22:20:45 +0000 Subject: Re: RFC: new utility, kmodpatch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jan 2009 20:07:53 -0000 Max Laier wrote: > > On Saturday 03 January 2009 19:47:29 dvg_lab wrote: >> Hi, >> >> I mentioned this utility a couple of months ago, and it's now working >> >> > so i would like to receive feedback on whether this is good to have >> > as part of the system, or just keep it as a port (which is what >> > i plan to do by default). >> > >> > In a nutshell, the kmodpatch utility can print or alter the content >> > of device/quirk tables in kernel modules (I think Linux has some >> > similar tool, though i don't remember the name -- or perhaps it is >> > a feature of insmod ?). >> >> Can't make it on CURRENT (31.12.2008) amd64 >> >> dvg-nb# make >> cc -O2 -pipe -O1 -Wall -Werror -Wunused -g -I/usr/local/include >> -L/usr/local/lib -lkvm kmodpatch.c -o kmodpatch >> cc1: warnings being treated as errors >> kmodpatch.c: In function 'dump': >> kmodpatch.c:234: warning: format '%d' expects type 'int', but argument 3 >> has type 'size_t' > > change %d to %zu > >> kmodpatch.c:291: warning: format '%016llx' expects type 'long long >> unsigned >> int', but argument 3 has type 'uint64_t' > > change %016llx to %016jx and cast argument three to uintmax_t > >> kmodpatch.c: In function 'do_rw': >> kmodpatch.c:535: warning: format '%d' expects type 'int', but argument 5 >> has type 'size_t' > > See above %zu > >> *** Error code 1 >> >> Stop in /home/dvg/downloads/kmodpatch. > > Thanks a lot, Max, it works for me. WBR, dvg_lab -- View this message in context: http://www.nabble.com/RFC%3A-new-utility%2C-kmodpatch-tp21243504p21268756.html Sent from the freebsd-current mailing list archive at Nabble.com.