From tim at kientzle.com Thu Jan 1 03:09:08 2009 From: tim at kientzle.com (Tim Kientzle) Date: Thu Jan 1 03:09:16 2009 Subject: tar/libarchive gzip problem [was: portsnap corrupted] In-Reply-To: <495C017F.9000408@freebsd.org> 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> Message-ID: <495C2AF5.6030703@kientzle.com> 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 jos at catnook.com Thu Jan 1 03:16:12 2009 From: jos at catnook.com (Jos Backus) Date: Thu Jan 1 03:16:24 2009 Subject: Changed names of logical disks on recent -CURRENT: part of logical disks not accessible now In-Reply-To: <9F29EF5C-B4FD-4273-8BE9-C134B983A1E1@mac.com> 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> Message-ID: <20090101031634.GD64075@lizzy.catnook.local> 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 tinderbox at freebsd.org Thu Jan 1 05:20:20 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu Jan 1 05:20:32 2009 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <20090101052017.E15197302F@freebsd-current.sentex.ca> 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 tinderbox at freebsd.org Thu Jan 1 05:57:06 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu Jan 1 05:57:19 2009 Subject: [head tinderbox] failure on i386/i386 Message-ID: <20090101055704.C0F9B7302F@freebsd-current.sentex.ca> 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 tinderbox at freebsd.org Thu Jan 1 07:03:36 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu Jan 1 07:03:43 2009 Subject: [head tinderbox] failure on i386/pc98 Message-ID: <20090101070334.AB7957302F@freebsd-current.sentex.ca> 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 tinderbox at freebsd.org Thu Jan 1 08:11:32 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu Jan 1 08:11:49 2009 Subject: [head tinderbox] failure on ia64/ia64 Message-ID: <20090101081130.59DFB7302F@freebsd-current.sentex.ca> 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 tinderbox at freebsd.org Thu Jan 1 08:49:25 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu Jan 1 08:49:39 2009 Subject: [head tinderbox] failure on powerpc/powerpc Message-ID: <20090101084924.419C07302F@freebsd-current.sentex.ca> 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 tinderbox at freebsd.org Thu Jan 1 09:47:33 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu Jan 1 09:47:45 2009 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <20090101094731.9651F7302F@freebsd-current.sentex.ca> 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 simon at FreeBSD.org Thu Jan 1 09:51:54 2009 From: simon at FreeBSD.org (Simon L. Nielsen) Date: Thu Jan 1 09:52:01 2009 Subject: tar/libarchive gzip problem [was: portsnap corrupted] In-Reply-To: <495C2AF5.6030703@kientzle.com> 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> Message-ID: <20090101095151.GA1117@arthur.nitro.dk> 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 tinderbox at freebsd.org Thu Jan 1 10:20:16 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu Jan 1 10:20:28 2009 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <20090101102013.5F52B7302F@freebsd-current.sentex.ca> 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 hselasky at c2i.net Thu Jan 1 11:30:55 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Thu Jan 1 11:31:03 2009 Subject: Call for axe(4) testers. In-Reply-To: <20090101022845.4dc8bc27.nork@FreeBSD.org> References: <47297827@bb.ipt.ru> <20081231003115.GA22037@cdnetworks.co.kr> <20090101022845.4dc8bc27.nork@FreeBSD.org> Message-ID: <200901011233.15537.hselasky@c2i.net> 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 tinderbox at freebsd.org Thu Jan 1 12:54:35 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu Jan 1 12:54:47 2009 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <20090101125432.7E8DB7302F@freebsd-current.sentex.ca> 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 tinderbox at freebsd.org Thu Jan 1 13:25:23 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu Jan 1 13:25:30 2009 Subject: [head tinderbox] failure on i386/i386 Message-ID: <20090101132520.836197302F@freebsd-current.sentex.ca> 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 ed at 80386.nl Thu Jan 1 13:33:42 2009 From: ed at 80386.nl (Ed Schouten) Date: Thu Jan 1 13:33:48 2009 Subject: VT100/xterm-support for syscons(4) committed to SVN Message-ID: <20090101133340.GE1176@hoeg.nl> 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! -- 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 > > Author: ed > Date: Thu Jan 1 13:26:53 2009 > New Revision: 186681 > URL: http://svn.freebsd.org/changeset/base/186681 > > Log: > Replace syscons terminal renderer by a new renderer that uses libteken. > > 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. > > A lot of random notes, which could be of interest to users/developers: > > - 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: > > - Keypad application mode (DECKPAM) > - Character sets (SCS) > > - 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: > > - 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. > > - teken_stress: a stress testing application that emulates random > terminal output. libteken has literally survived multiple terabytes > of random input. > > - 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. > > - 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? > > - I've removed the `dumb' terminal emulator. It has been broken for > years. It hasn't survived the `struct proc' -> `struct thread' > conversion. > > - 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'. > > - 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. > > Discussed on: current@, hackers@ > Discussed with: philip (at 25C3) > ----- End forwarded message ----- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090101/fc2a1998/attachment.pgp From max at love2party.net Thu Jan 1 15:13:19 2009 From: max at love2party.net (Max Laier) Date: Thu Jan 1 15:13:26 2009 Subject: tar/libarchive gzip problem [was: portsnap corrupted] In-Reply-To: <20090101095151.GA1117@arthur.nitro.dk> References: <200812301616.11132.max@love2party.net> <495C2AF5.6030703@kientzle.com> <20090101095151.GA1117@arthur.nitro.dk> Message-ID: <200901011613.14175.max@love2party.net> 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 pj at smo.de Thu Jan 1 17:30:15 2009 From: pj at smo.de (Philipp Ost) Date: Thu Jan 1 17:30:22 2009 Subject: LORs in recent -current Message-ID: <495CCB7D.80402@smo.de> 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 rizzo at iet.unipi.it Thu Jan 1 18:25:38 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Thu Jan 1 18:25:46 2009 Subject: RFC: new utility, kmodpatch Message-ID: <20090101183026.GA15385@onelab2.iet.unipi.it> 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 admin at lissyara.su Thu Jan 1 19:25:35 2009 From: admin at lissyara.su (Alex Keda) Date: Thu Jan 1 19:25:42 2009 Subject: RFC: new utility, kmodpatch In-Reply-To: <20090101183026.GA15385@onelab2.iet.unipi.it> References: <20090101183026.GA15385@onelab2.iet.unipi.it> Message-ID: <495D18AB.4080402@lissyara.su> 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 oliver.pntr at gmail.com Thu Jan 1 19:49:49 2009 From: oliver.pntr at gmail.com (Oliver Pinter) Date: Thu Jan 1 19:49:57 2009 Subject: RFC: new utility, kmodpatch In-Reply-To: <20090101183026.GA15385@onelab2.iet.unipi.it> References: <20090101183026.GA15385@onelab2.iet.unipi.it> Message-ID: <6101e8c40901011117y3e82a226id6f9de940b0f7dcd@mail.gmail.com> 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 qing.li at bluecoat.com Thu Jan 1 20:19:22 2009 From: qing.li at bluecoat.com (Li, Qing) Date: Thu Jan 1 20:19:28 2009 Subject: SCTP related issue with recent ARP changes? References: Message-ID: 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?xen 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 _______________________________________________ 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 christoph.mallon at gmx.de Thu Jan 1 20:27:55 2009 From: christoph.mallon at gmx.de (Christoph Mallon) Date: Thu Jan 1 20:28:02 2009 Subject: RFC: new utility, kmodpatch In-Reply-To: <20090101183026.GA15385@onelab2.iet.unipi.it> References: <20090101183026.GA15385@onelab2.iet.unipi.it> Message-ID: <495D2106.2090403@gmx.de> 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. From jjacobson at panasas.com Thu Jan 1 20:35:12 2009 From: jjacobson at panasas.com (Joel Jacobson) Date: Thu Jan 1 20:35:19 2009 Subject: gstripe performance oddity Message-ID: <3D76E927-AD4F-4B6E-83E8-44379814FD98@panasas.com> 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 christoph.mallon at gmx.de Thu Jan 1 22:00:28 2009 From: christoph.mallon at gmx.de (Christoph Mallon) Date: Thu Jan 1 22:00:36 2009 Subject: RFC: new utility, kmodpatch In-Reply-To: <495D2106.2090403@gmx.de> References: <20090101183026.GA15385@onelab2.iet.unipi.it> <495D2106.2090403@gmx.de> Message-ID: <495D3CF9.1010701@gmx.de> 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 minimarmot at gmail.com Fri Jan 2 00:39:44 2009 From: minimarmot at gmail.com (Ben Kaduk) Date: Fri Jan 2 00:39:50 2009 Subject: RFC: new utility, kmodpatch In-Reply-To: <6101e8c40901011117y3e82a226id6f9de940b0f7dcd@mail.gmail.com> References: <20090101183026.GA15385@onelab2.iet.unipi.it> <6101e8c40901011117y3e82a226id6f9de940b0f7dcd@mail.gmail.com> Message-ID: <47d0403c0901011619r658fd25ct3d01bc32969bde11@mail.gmail.com> 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 kensmith at cse.Buffalo.EDU Fri Jan 2 01:36:46 2009 From: kensmith at cse.Buffalo.EDU (Ken Smith) Date: Fri Jan 2 01:36:53 2009 Subject: Warning about uid values larger than 16-bit... Message-ID: <1230858317.43523.43.camel@bauer.cse.buffalo.edu> 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. -- Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090102/eb60f70a/attachment.pgp From sobomax at FreeBSD.org Fri Jan 2 06:21:49 2009 From: sobomax at FreeBSD.org (Maxim Sobolev) Date: Fri Jan 2 06:21:55 2009 Subject: gstripe performance oddity In-Reply-To: <3D76E927-AD4F-4B6E-83E8-44379814FD98@panasas.com> References: <3D76E927-AD4F-4B6E-83E8-44379814FD98@panasas.com> Message-ID: <495DB269.5030803@FreeBSD.org> 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 jjacobson at panasas.com Fri Jan 2 08:05:23 2009 From: jjacobson at panasas.com (Joel Jacobson) Date: Fri Jan 2 08:05:30 2009 Subject: gstripe performance oddity In-Reply-To: <495DB269.5030803@FreeBSD.org> References: <3D76E927-AD4F-4B6E-83E8-44379814FD98@panasas.com> <495DB269.5030803@FreeBSD.org> Message-ID: <4B586604-517A-4945-9EED-DC93DD751FB3@panasas.com> 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 obrien at freebsd.org Fri Jan 2 09:13:36 2009 From: obrien at freebsd.org (David O'Brien) Date: Fri Jan 2 09:13:45 2009 Subject: gjournal is not automounted any more In-Reply-To: <69321574@bs1.sp34.ru> References: <80044077@bb.ipt.ru> <69321574@bs1.sp34.ru> Message-ID: <20090102091334.GA41230@dragon.NUXI.org> 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 bsam at ipt.ru Fri Jan 2 10:28:10 2009 From: bsam at ipt.ru (Boris Samorodov) Date: Fri Jan 2 10:28:16 2009 Subject: gjournal is not automounted any more In-Reply-To: <20090102091334.GA41230@dragon.NUXI.org> (David O'Brien's message of "Fri\, 2 Jan 2009 01\:13\:34 -0800") References: <80044077@bb.ipt.ru> <69321574@bs1.sp34.ru> <20090102091334.GA41230@dragon.NUXI.org> Message-ID: <03225241@bs1.sp34.ru> "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 Johan at double-l.nl Fri Jan 2 10:43:43 2009 From: Johan at double-l.nl (Johan Hendriks) Date: Fri Jan 2 10:43:52 2009 Subject: build -j3 not working anymore on Current Message-ID: <57200BF94E69E54880C9BB1AF714BBCB0111B3@w2003s01.double-l.local> 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 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=(FG_LIGHTGREY|BG_BLACK) options SC_NORM_REV_ATTR=(FG_YELLOW|BG_GREEN) options SC_KERNEL_CONS_ATTR=(FG_BROWN|BG_BLACK) options SC_KERNEL_CONS_REV_ATTR=(FG_BLACK|BG_RED) # System console options options SC_DISABLE_REBOOT # disable reboot key sequence options SC_HISTORY_SIZE=200 # 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 gpalmer at freebsd.org Fri Jan 2 11:53:42 2009 From: gpalmer at freebsd.org (Gary Palmer) Date: Fri Jan 2 11:53:48 2009 Subject: build -j3 not working anymore on Current In-Reply-To: <57200BF94E69E54880C9BB1AF714BBCB0111B3@w2003s01.double-l.local> References: <57200BF94E69E54880C9BB1AF714BBCB0111B3@w2003s01.double-l.local> Message-ID: <20090102115339.GA81380@in-addr.com> 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 Johan at double-l.nl Fri Jan 2 12:01:16 2009 From: Johan at double-l.nl (Johan Hendriks) Date: Fri Jan 2 12:01:23 2009 Subject: build -j3 not working anymore on Current References: <57200BF94E69E54880C9BB1AF714BBCB0111B3@w2003s01.double-l.local> <20090102115339.GA81380@in-addr.com> Message-ID: <57200BF94E69E54880C9BB1AF714BBCB5DE3C6@w2003s01.double-l.local> 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 Version: 8.0.176 / Virus Database: 270.10.2/1871 - Release Date: 1-1-2009 17:01 From gpalmer at freebsd.org Fri Jan 2 12:30:53 2009 From: gpalmer at freebsd.org (Gary Palmer) Date: Fri Jan 2 12:30:59 2009 Subject: build -j3 not working anymore on Current In-Reply-To: <57200BF94E69E54880C9BB1AF714BBCB5DE3C6@w2003s01.double-l.local> References: <57200BF94E69E54880C9BB1AF714BBCB0111B3@w2003s01.double-l.local> <20090102115339.GA81380@in-addr.com> <57200BF94E69E54880C9BB1AF714BBCB5DE3C6@w2003s01.double-l.local> Message-ID: <20090102123051.GB81380@in-addr.com> 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 Johan at double-l.nl Fri Jan 2 13:17:01 2009 From: Johan at double-l.nl (Johan Hendriks) Date: Fri Jan 2 13:17:09 2009 Subject: build -j3 not working anymore on Current References: <57200BF94E69E54880C9BB1AF714BBCB0111B3@w2003s01.double-l.local> <20090102115339.GA81380@in-addr.com> <57200BF94E69E54880C9BB1AF714BBCB5DE3C6@w2003s01.double-l.local> <20090102123051.GB81380@in-addr.com> Message-ID: <57200BF94E69E54880C9BB1AF714BBCB0111B4@w2003s01.double-l.local> >> >> 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 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! 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=awk _POSIX2_VERSION=199209 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=awk _POSIX2_VERSION=199209 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.wide >> 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.sh /usr/src/lib/ncurses/ncursesw/../ncurses/ncurses_cfg.h term.h.new --- curses.h --- cat /usr/src/lib/ncurses/ncursesw/../../../contrib/ncurses/include/curses.tail >> 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 Johan at double-l.nl Fri Jan 2 13:22:31 2009 From: Johan at double-l.nl (Johan Hendriks) Date: Fri Jan 2 13:22:38 2009 Subject: build -j3 not working anymore on Current References: <57200BF94E69E54880C9BB1AF714BBCB0111B3@w2003s01.double-l.local> <20090102115339.GA81380@in-addr.com> <57200BF94E69E54880C9BB1AF714BBCB5DE3C6@w2003s01.double-l.local> <20090102123051.GB81380@in-addr.com> Message-ID: <57200BF94E69E54880C9BB1AF714BBCB0111B5@w2003s01.double-l.local> >> >> 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 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 arno at heho.snv.jussieu.fr Fri Jan 2 15:18:31 2009 From: arno at heho.snv.jussieu.fr (Arno J. Klaassen) Date: Fri Jan 2 15:18:39 2009 Subject: 8-current: linux_dist-gentoo-stage3 wonn't bootstrap In-Reply-To: References: <20081227220645.GA13295@freebsd.org> <20081228175745.GA56640@freebsd.org> <20081228202526.GA74948@freebsd.org> <20081228211505.GA80323@freebsd.org> <20081228214438.GA83007@freebsd.org> Message-ID: 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 imp at bsdimp.com Fri Jan 2 18:47:22 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Fri Jan 2 18:47:30 2009 Subject: build -j3 not working anymore on Current In-Reply-To: <57200BF94E69E54880C9BB1AF714BBCB5DE3C6@w2003s01.double-l.local> References: <57200BF94E69E54880C9BB1AF714BBCB0111B3@w2003s01.double-l.local> <20090102115339.GA81380@in-addr.com> <57200BF94E69E54880C9BB1AF714BBCB5DE3C6@w2003s01.double-l.local> Message-ID: <20090102.114627.1656128188.imp@bsdimp.com> 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 imp at bsdimp.com Fri Jan 2 18:50:27 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Fri Jan 2 18:50:34 2009 Subject: gjournal is not automounted any more In-Reply-To: <20090102091334.GA41230@dragon.NUXI.org> References: <69321574@bs1.sp34.ru> <20090102091334.GA41230@dragon.NUXI.org> Message-ID: <20090102.114757.-924277930.imp@bsdimp.com> 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 imp at bsdimp.com Fri Jan 2 18:53:27 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Fri Jan 2 18:53:36 2009 Subject: RFC: new utility, kmodpatch In-Reply-To: <20090101183026.GA15385@onelab2.iet.unipi.it> References: <20090101183026.GA15385@onelab2.iet.unipi.it> Message-ID: <20090102.115022.1102529931.imp@bsdimp.com> 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 imp at bsdimp.com Fri Jan 2 18:56:11 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Fri Jan 2 18:56:18 2009 Subject: New warning, what does it mean? Message-ID: <20090102.115426.-1540393465.imp@bsdimp.com> 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 imp at bsdimp.com Fri Jan 2 18:59:43 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Fri Jan 2 18:59:50 2009 Subject: HEADSUP usb2 (usb4bsd) to become default in 2 weeks. In-Reply-To: <20081229181044.GA78575@dragon.NUXI.org> References: <20081229110956.GA71972@dragon.NUXI.org> <20081229111944.GB20239@elvis.mu.org> <20081229181044.GA78575@dragon.NUXI.org> Message-ID: <20090102.115759.-1625878361.imp@bsdimp.com> 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 imp at bsdimp.com Fri Jan 2 19:02:32 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Fri Jan 2 19:02:40 2009 Subject: HEADSUP usb2 (usb4bsd) to become default in 2 weeks. [usb2 configuration] In-Reply-To: <200812282303.46555.hselasky@c2i.net> References: <4956B34C.2040901@freebsd.org> <20081228184045.0ea74b7d@gluon> <200812282303.46555.hselasky@c2i.net> Message-ID: <20090102.120134.-928138805.imp@bsdimp.com> 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 imp at bsdimp.com Fri Jan 2 19:26:49 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Fri Jan 2 19:27:01 2009 Subject: HEADSUP usb2 (usb4bsd) to become default in 2 weeks. [usb2 configuration] In-Reply-To: <200812282303.46555.hselasky@c2i.net> References: <4956B34C.2040901@freebsd.org> <20081228184045.0ea74b7d@gluon> <200812282303.46555.hselasky@c2i.net> Message-ID: <20090102.120134.-928138805.imp@bsdimp.com> 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 rizzo at iet.unipi.it Fri Jan 2 20:56:44 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Fri Jan 2 20:56:57 2009 Subject: RFC: new utility, kmodpatch In-Reply-To: <20090102.115022.1102529931.imp@bsdimp.com> References: <20090101183026.GA15385@onelab2.iet.unipi.it> <20090102.115022.1102529931.imp@bsdimp.com> Message-ID: <20090102210133.GA57653@onelab2.iet.unipi.it> 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 uwe at grohnwaldt.eu Fri Jan 2 22:03:13 2009 From: uwe at grohnwaldt.eu (Uwe Grohnwaldt) Date: Fri Jan 2 22:03:22 2009 Subject: panic on (hdd)load Message-ID: <495E8F00.2050309@grohnwaldt.eu> 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 uwe at grohnwaldt.eu Fri Jan 2 22:09:52 2009 From: uwe at grohnwaldt.eu (Uwe Grohnwaldt) Date: Fri Jan 2 22:09:59 2009 Subject: panic on (hdd)load In-Reply-To: <495E8F00.2050309@grohnwaldt.eu> References: <495E8F00.2050309@grohnwaldt.eu> Message-ID: <495E90A8.2020000@grohnwaldt.eu> 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 rizzo at iet.unipi.it Fri Jan 2 22:12:29 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Fri Jan 2 22:12:35 2009 Subject: RFC: new utility, kmodpatch In-Reply-To: <47d0403c0901011619r658fd25ct3d01bc32969bde11@mail.gmail.com> References: <20090101183026.GA15385@onelab2.iet.unipi.it> <6101e8c40901011117y3e82a226id6f9de940b0f7dcd@mail.gmail.com> <47d0403c0901011619r658fd25ct3d01bc32969bde11@mail.gmail.com> Message-ID: <20090102221719.GA61058@onelab2.iet.unipi.it> 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 qing.li at bluecoat.com Fri Jan 2 22:15:08 2009 From: qing.li at bluecoat.com (Li, Qing) Date: Fri Jan 2 22:15:20 2009 Subject: SCTP related issue with recent ARP changes? In-Reply-To: References: Message-ID: 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?xen; 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?xen > 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 ken at mthelicon.com Fri Jan 2 22:59:22 2009 From: ken at mthelicon.com (Pegasus Mc Cleaft) Date: Fri Jan 2 22:59:29 2009 Subject: hald and USB2 In-Reply-To: <20090102.120134.-928138805.imp@bsdimp.com> References: <4956B34C.2040901@freebsd.org> <200812282303.46555.hselasky@c2i.net> <20090102.120134.-928138805.imp@bsdimp.com> Message-ID: <200901022259.17193.ken@mthelicon.com> 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 marcus at marcuscom.com Fri Jan 2 23:02:18 2009 From: marcus at marcuscom.com (Joe Marcus Clarke) Date: Fri Jan 2 23:02:25 2009 Subject: hald and USB2 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> Message-ID: <1230937367.87142.66.camel@shumai.marcuscom.com> On Fri, 2009-01-02 at 22:59 +0000, Pegasus Mc Cleaft wrote: > 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. 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 -- PGP Key : http://www.marcuscom.com/pgp.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090102/a0eb5b43/attachment.pgp From uwe at grohnwaldt.eu Fri Jan 2 23:05:52 2009 From: uwe at grohnwaldt.eu (Uwe Grohnwaldt) Date: Fri Jan 2 23:05:59 2009 Subject: panic on (hdd)load In-Reply-To: <495E8F00.2050309@grohnwaldt.eu> References: <495E8F00.2050309@grohnwaldt.eu> Message-ID: <495E9DC8.7080009@grohnwaldt.eu> 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 alfred at freebsd.org Fri Jan 2 23:18:11 2009 From: alfred at freebsd.org (Alfred Perlstein) Date: Fri Jan 2 23:18:18 2009 Subject: HEADSUP usb2 (usb4bsd) to become default in 2 weeks. In-Reply-To: <20090102.115759.-1625878361.imp@bsdimp.com> References: <20081229110956.GA71972@dragon.NUXI.org> <20081229111944.GB20239@elvis.mu.org> <20081229181044.GA78575@dragon.NUXI.org> <20090102.115759.-1625878361.imp@bsdimp.com> Message-ID: <20090102231811.GF60686@elvis.mu.org> 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 imp at bsdimp.com Fri Jan 2 23:29:38 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Fri Jan 2 23:29:45 2009 Subject: HEADSUP usb2 (usb4bsd) to become default in 2 weeks. 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> Message-ID: <20090102.162757.2007158145.imp@bsdimp.com> 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 imp at bsdimp.com Fri Jan 2 23:36:08 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Fri Jan 2 23:36:15 2009 Subject: RFC: new utility, kmodpatch 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> Message-ID: <20090102.163308.-1929116900.imp@bsdimp.com> 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 Michael.Tuexen at lurchi.franken.de Fri Jan 2 23:20:18 2009 From: Michael.Tuexen at lurchi.franken.de (=?ISO-8859-1?Q?Michael_T=FCxen?=) Date: Fri Jan 2 23:58:27 2009 Subject: SCTP related issue with recent ARP changes? In-Reply-To: References: Message-ID: 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 > 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?xen; 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?xen >> 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 alfred at freebsd.org Sat Jan 3 00:18:54 2009 From: alfred at freebsd.org (Alfred Perlstein) Date: Sat Jan 3 00:19:02 2009 Subject: HEADSUP usb2 (usb4bsd) to become default in 2 weeks. In-Reply-To: <20090102.162757.2007158145.imp@bsdimp.com> References: <20081229181044.GA78575@dragon.NUXI.org> <20090102.115759.-1625878361.imp@bsdimp.com> <20090102231811.GF60686@elvis.mu.org> <20090102.162757.2007158145.imp@bsdimp.com> Message-ID: <20090103001853.GJ60686@elvis.mu.org> 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 uwe at grohnwaldt.eu Sat Jan 3 00:23:03 2009 From: uwe at grohnwaldt.eu (Uwe Grohnwaldt) Date: Sat Jan 3 00:23:11 2009 Subject: panic on (hdd)load In-Reply-To: <495E8F00.2050309@grohnwaldt.eu> References: <495E8F00.2050309@grohnwaldt.eu> Message-ID: <495EAFE1.4040801@grohnwaldt.eu> 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 rizzo at iet.unipi.it Sat Jan 3 00:45:50 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Sat Jan 3 00:46:04 2009 Subject: RFC: new utility, kmodpatch In-Reply-To: <20090102.163308.-1929116900.imp@bsdimp.com> 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> Message-ID: <20090103005040.GA64606@onelab2.iet.unipi.it> 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 hselasky at c2i.net Sat Jan 3 01:22:28 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sat Jan 3 01:22:35 2009 Subject: panic on (hdd)load In-Reply-To: <200901030116.45837.Thomas.Sparrevohn@btinternet.com> References: <495E8F00.2050309@grohnwaldt.eu> <495EAFE1.4040801@grohnwaldt.eu> <200901030116.45837.Thomas.Sparrevohn@btinternet.com> Message-ID: <200901030224.44187.hselasky@c2i.net> 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 Thomas.Sparrevohn at btinternet.com Sat Jan 3 01:43:37 2009 From: Thomas.Sparrevohn at btinternet.com (Thomas Sparrevohn) Date: Sat Jan 3 01:43:45 2009 Subject: panic on (hdd)load In-Reply-To: <495EAFE1.4040801@grohnwaldt.eu> References: <495E8F00.2050309@grohnwaldt.eu> <495EAFE1.4040801@grohnwaldt.eu> Message-ID: <200901030116.45837.Thomas.Sparrevohn@btinternet.com> 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 obrien at freebsd.org Sat Jan 3 03:35:53 2009 From: obrien at freebsd.org (David O'Brien) Date: Sat Jan 3 03:35:59 2009 Subject: gjournal is not automounted any more In-Reply-To: <20090102.114757.-924277930.imp@bsdimp.com> References: <69321574@bs1.sp34.ru> <20090102091334.GA41230@dragon.NUXI.org> <20090102.114757.-924277930.imp@bsdimp.com> Message-ID: <20090103033543.GB77475@dragon.NUXI.org> 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 imp at bsdimp.com Sat Jan 3 06:11:35 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Sat Jan 3 06:11:41 2009 Subject: RFC: new utility, kmodpatch 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> Message-ID: <20090102.230825.1159135437.imp@bsdimp.com> 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 imp at bsdimp.com Sat Jan 3 06:14:38 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Sat Jan 3 06:14:44 2009 Subject: gjournal is not automounted any more 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> Message-ID: <20090102.231410.-2001109684.imp@bsdimp.com> 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 randy at psg.com Sat Jan 3 06:52:32 2009 From: randy at psg.com (Randy Bush) Date: Sat Jan 3 06:52:41 2009 Subject: hosts on bridged wlan can not reliably see each other Message-ID: <495F0B2D.7060701@psg.com> 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 obrien at freebsd.org Sat Jan 3 07:37:18 2009 From: obrien at freebsd.org (David O'Brien) Date: Sat Jan 3 07:37:24 2009 Subject: gjournal is not automounted any more In-Reply-To: <20090102.231410.-2001109684.imp@bsdimp.com> References: <20090102091334.GA41230@dragon.NUXI.org> <20090102.114757.-924277930.imp@bsdimp.com> <20090103033543.GB77475@dragon.NUXI.org> <20090102.231410.-2001109684.imp@bsdimp.com> Message-ID: <20090103073709.GA80876@dragon.NUXI.org> 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 imp at bsdimp.com Sat Jan 3 07:47:28 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Sat Jan 3 07:47:34 2009 Subject: gjournal is not automounted any more 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> Message-ID: <20090103.004642.1683993840.imp@bsdimp.com> 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 obrien at freebsd.org Sat Jan 3 10:16:10 2009 From: obrien at freebsd.org (David O'Brien) Date: Sat Jan 3 10:16:18 2009 Subject: build -j3 not working anymore on Current In-Reply-To: <57200BF94E69E54880C9BB1AF714BBCB0111B3@w2003s01.double-l.local> References: <57200BF94E69E54880C9BB1AF714BBCB0111B3@w2003s01.double-l.local> Message-ID: <20090103101606.GA81276@dragon.NUXI.org> 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 obrien at freebsd.org Sat Jan 3 10:20:43 2009 From: obrien at freebsd.org (David O'Brien) Date: Sat Jan 3 10:20:49 2009 Subject: New warning, what does it mean? In-Reply-To: <20090102.115426.-1540393465.imp@bsdimp.com> References: <20090102.115426.-1540393465.imp@bsdimp.com> Message-ID: <20090103102036.GB81276@dragon.NUXI.org> 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 gary.jennejohn at freenet.de Sat Jan 3 11:44:29 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Sat Jan 3 11:44:39 2009 Subject: RFC: new utility, kmodpatch 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> Message-ID: <20090103124424.2959f2ac@ernst.jennejohn.org> 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 roberthuff at rcn.com Sat Jan 3 14:30:06 2009 From: roberthuff at rcn.com (Robert Huff) Date: Sat Jan 3 14:30:12 2009 Subject: kernel complaint about /dev/pts (maybe) Message-ID: <18783.28606.874391.376202@jerusalem.litteratus.org> 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 ed at 80386.nl Sat Jan 3 15:11:45 2009 From: ed at 80386.nl (Ed Schouten) Date: Sat Jan 3 15:11:52 2009 Subject: kernel complaint about /dev/pts (maybe) In-Reply-To: <18783.28606.874391.376202@jerusalem.litteratus.org> References: <18783.28606.874391.376202@jerusalem.litteratus.org> Message-ID: <20090103151142.GL14235@hoeg.nl> Hello Robert, * Robert Huff wrote: > FreeBSD 7.0-CURRENT #2: Wed Nov 19 06:02:02 EST 2008 i386 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. -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090103/0afa6a4f/attachment.pgp From brueffer at FreeBSD.org Sat Jan 3 16:27:27 2009 From: brueffer at FreeBSD.org (Christian Brueffer) Date: Sat Jan 3 16:27:34 2009 Subject: CFT: altq support for pcn(4) Message-ID: <20090103155724.GC1243@haakonia.hitnet.RWTH-Aachen.DE> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090103/2103ef97/attachment.pgp From xcllnt at mac.com Sat Jan 3 16:30:12 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Sat Jan 3 16:30:25 2009 Subject: Changed names of logical disks on recent -CURRENT: part of logical disks not accessible now In-Reply-To: <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> <20090101031634.GD64075@lizzy.catnook.local> Message-ID: 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 need4spam at bk.ru Sat Jan 3 16:05:51 2009 From: need4spam at bk.ru (Alexey Ivanov) Date: Sat Jan 3 16:48:24 2009 Subject: Can not build r186708 -CURRENT Message-ID: 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: PH34R.8 Type: application/octet-stream Size: 13501 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090103/7489ca69/PH34R.obj From brueffer at FreeBSD.org Sat Jan 3 16:52:09 2009 From: brueffer at FreeBSD.org (Christian Brueffer) Date: Sat Jan 3 16:52:16 2009 Subject: CFT: altq support for pcn(4) In-Reply-To: <20090103155724.GC1243@haakonia.hitnet.RWTH-Aachen.DE> References: <20090103155724.GC1243@haakonia.hitnet.RWTH-Aachen.DE> Message-ID: <20090103165206.GD1243@haakonia.hitnet.RWTH-Aachen.DE> 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 -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090103/8da7f421/attachment.pgp From xcllnt at mac.com Sat Jan 3 17:18:25 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Sat Jan 3 17:18:31 2009 Subject: New warning, what does it mean? In-Reply-To: <20090102.115426.-1540393465.imp@bsdimp.com> References: <20090102.115426.-1540393465.imp@bsdimp.com> Message-ID: 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 imp at bsdimp.com Sat Jan 3 17:26:37 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Sat Jan 3 17:26:44 2009 Subject: New warning, what does it mean? In-Reply-To: References: <20090102.115426.-1540393465.imp@bsdimp.com> Message-ID: <20090103.102528.139568125.imp@bsdimp.com> 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 xcllnt at mac.com Sat Jan 3 17:32:46 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Sat Jan 3 17:32:54 2009 Subject: gjournal is not automounted any more In-Reply-To: <20090102.231410.-2001109684.imp@bsdimp.com> References: <20090102091334.GA41230@dragon.NUXI.org> <20090102.114757.-924277930.imp@bsdimp.com> <20090103033543.GB77475@dragon.NUXI.org> <20090102.231410.-2001109684.imp@bsdimp.com> Message-ID: <440945C2-252E-489A-902E-A499753A5EF8@mac.com> 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 xcllnt at mac.com Sat Jan 3 17:43:39 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Sat Jan 3 17:43:46 2009 Subject: New warning, what does it mean? In-Reply-To: <20090103102036.GB81276@dragon.NUXI.org> References: <20090102.115426.-1540393465.imp@bsdimp.com> <20090103102036.GB81276@dragon.NUXI.org> Message-ID: <0A76CAED-D11F-448B-8A1C-E42526B67E89@mac.com> 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 imp at bsdimp.com Sat Jan 3 17:44:28 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Sat Jan 3 17:44:36 2009 Subject: gjournal is not automounted any more 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> Message-ID: <20090103.104220.513891918.imp@bsdimp.com> 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 xcllnt at mac.com Sat Jan 3 17:53:47 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Sat Jan 3 17:53:54 2009 Subject: New warning, what does it mean? In-Reply-To: <20090103.102528.139568125.imp@bsdimp.com> References: <20090102.115426.-1540393465.imp@bsdimp.com> <20090103.102528.139568125.imp@bsdimp.com> Message-ID: 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 xcllnt at mac.com Sat Jan 3 18:01:22 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Sat Jan 3 18:01:28 2009 Subject: gjournal is not automounted any more In-Reply-To: <20090103.104220.513891918.imp@bsdimp.com> 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> Message-ID: <8F22F980-0D4C-4074-8685-3FFAD4558362@mac.com> 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 onemda at gmail.com Sat Jan 3 18:08:45 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Sat Jan 3 18:08:51 2009 Subject: Can not build r186708 -CURRENT In-Reply-To: References: Message-ID: <3a142e750901031008x3d2fefc8r4c5b877e049af02a@mail.gmail.com> 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 imp at bsdimp.com Sat Jan 3 18:14:21 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Sat Jan 3 18:14:28 2009 Subject: gjournal is not automounted any more 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> Message-ID: <20090103.111324.-98089972.imp@bsdimp.com> 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 uwe at grohnwaldt.eu Sat Jan 3 18:25:33 2009 From: uwe at grohnwaldt.eu (Uwe Grohnwaldt) Date: Sat Jan 3 18:25:40 2009 Subject: panic on (hdd)load In-Reply-To: <200901030224.44187.hselasky@c2i.net> References: <495E8F00.2050309@grohnwaldt.eu> <495EAFE1.4040801@grohnwaldt.eu> <200901030116.45837.Thomas.Sparrevohn@btinternet.com> <200901030224.44187.hselasky@c2i.net> Message-ID: <495FAD98.2010503@grohnwaldt.eu> 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 admin at lissyara.su Sat Jan 3 18:45:01 2009 From: admin at lissyara.su (Alex Keda) Date: Sat Jan 3 18:45:08 2009 Subject: RFC: new utility, kmodpatch In-Reply-To: <20090101183026.GA15385@onelab2.iet.unipi.it> References: <20090101183026.GA15385@onelab2.iet.unipi.it> Message-ID: <495FB22A.3000703@lissyara.su> 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 rizzo at iet.unipi.it Sat Jan 3 18:54:55 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Sat Jan 3 18:55:02 2009 Subject: RFC: new utility, kmodpatch In-Reply-To: <495FB22A.3000703@lissyara.su> References: <20090101183026.GA15385@onelab2.iet.unipi.it> <495FB22A.3000703@lissyara.su> Message-ID: <20090103185947.GA96480@onelab2.iet.unipi.it> 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 dvg at tjc.ru Sat Jan 3 19:03:24 2009 From: dvg at tjc.ru (dvg_lab) Date: Sat Jan 3 19:08:45 2009 Subject: RFC: new utility, kmodpatch In-Reply-To: <20090101183026.GA15385@onelab2.iet.unipi.it> References: <20090101183026.GA15385@onelab2.iet.unipi.it> Message-ID: <21267890.post@talk.nabble.com> 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 max at love2party.net Sat Jan 3 19:17:30 2009 From: max at love2party.net (Max Laier) Date: Sat Jan 3 19:17:38 2009 Subject: RFC: new utility, kmodpatch In-Reply-To: <21267890.post@talk.nabble.com> References: <20090101183026.GA15385@onelab2.iet.unipi.it> <21267890.post@talk.nabble.com> Message-ID: <200901032017.27608.max@love2party.net> 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 yanefbsd at gmail.com Sat Jan 3 19:33:43 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Sat Jan 3 19:33:50 2009 Subject: Weird arrow key disappearing act with latest syscons Message-ID: <7d6fde3d0901031133o5e7dfdc6u7ba89ee491c99ba7@mail.gmail.com> 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 ed at 80386.nl Sat Jan 3 19:43:13 2009 From: ed at 80386.nl (Ed Schouten) Date: Sat Jan 3 19:43:20 2009 Subject: Weird arrow key disappearing act with latest syscons In-Reply-To: <7d6fde3d0901031133o5e7dfdc6u7ba89ee491c99ba7@mail.gmail.com> References: <7d6fde3d0901031133o5e7dfdc6u7ba89ee491c99ba7@mail.gmail.com> Message-ID: <20090103194311.GP14235@hoeg.nl> 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! -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090103/e1b82f36/attachment.pgp From xcllnt at mac.com Sat Jan 3 19:46:18 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Sat Jan 3 19:46:25 2009 Subject: gjournal is not automounted any more In-Reply-To: <20090103.111324.-98089972.imp@bsdimp.com> 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> Message-ID: <43883A46-9219-4B40-9175-137CFCD0E896@mac.com> 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 ed at 80386.nl Sat Jan 3 20:00:04 2009 From: ed at 80386.nl (Ed Schouten) Date: Sat Jan 3 20:00:11 2009 Subject: Weird arrow key disappearing act with latest syscons In-Reply-To: <20090103194311.GP14235@hoeg.nl> References: <7d6fde3d0901031133o5e7dfdc6u7ba89ee491c99ba7@mail.gmail.com> <20090103194311.GP14235@hoeg.nl> Message-ID: <20090103200002.GR14235@hoeg.nl> Garrett, * 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! Before I forget: after running script(1), be sure to invoke a `reset'. This makes it easier for me to reproduce. Thanks! -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090103/2deeffe1/attachment.pgp From yanefbsd at gmail.com Sat Jan 3 20:10:07 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Sat Jan 3 20:10:39 2009 Subject: Weird arrow key disappearing act with latest syscons In-Reply-To: <20090103194311.GP14235@hoeg.nl> References: <7d6fde3d0901031133o5e7dfdc6u7ba89ee491c99ba7@mail.gmail.com> <20090103194311.GP14235@hoeg.nl> Message-ID: <7d6fde3d0901031210h2bcceeo1ceae4d3a481a00f@mail.gmail.com> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: tty-issue.tbz2 Type: application/octet-stream Size: 7552 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090103/850aa4d8/tty-issue-0001.obj From keramida at freebsd.org Sat Jan 3 20:11:04 2009 From: keramida at freebsd.org (Giorgos Keramidas) Date: Sat Jan 3 20:11:35 2009 Subject: Tracking the open USB2 issues? In-Reply-To: <874p0t2iyw.fsf_-_@kobe.laptop> (Giorgos Keramidas's message of "Thu, 25 Dec 2008 02:31:51 +0200") References: <20081222214010.GA18389@elvis.mu.org> <20081224215330.3ccc613d@gluon> <874p0t2iyw.fsf_-_@kobe.laptop> Message-ID: <87ljtsnowo.fsf@kobe.laptop> 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 Thomas.Sparrevohn at btinternet.com Sat Jan 3 21:26:53 2009 From: Thomas.Sparrevohn at btinternet.com (Thomas Sparrevohn) Date: Sat Jan 3 21:27:00 2009 Subject: panic on (hdd)load In-Reply-To: <495FAD98.2010503@grohnwaldt.eu> References: <495E8F00.2050309@grohnwaldt.eu> <200901030224.44187.hselasky@c2i.net> <495FAD98.2010503@grohnwaldt.eu> Message-ID: <200901032126.44821.Thomas.Sparrevohn@btinternet.com> 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 Thomas.Sparrevohn at btinternet.com Sat Jan 3 21:53:35 2009 From: Thomas.Sparrevohn at btinternet.com (Thomas Sparrevohn) Date: Sat Jan 3 21:53:41 2009 Subject: panic on (hdd)load In-Reply-To: <495FAD98.2010503@grohnwaldt.eu> References: <495E8F00.2050309@grohnwaldt.eu> <200901030224.44187.hselasky@c2i.net> <495FAD98.2010503@grohnwaldt.eu> Message-ID: <200901032126.44821.Thomas.Sparrevohn@btinternet.com> 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 jos at catnook.com Sat Jan 3 21:57:42 2009 From: jos at catnook.com (Jos Backus) Date: Sat Jan 3 21:57:57 2009 Subject: Changed names of logical disks on recent -CURRENT: part of logical disks not accessible now In-Reply-To: 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> Message-ID: <20090103215810.GA1527@lizzy.catnook.local> 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 dvg at tjc.ru Sat Jan 3 20:07:53 2009 From: dvg at tjc.ru (Vyacheslav Druzhinin) Date: Sat Jan 3 22:20:46 2009 Subject: RFC: new utility, kmodpatch In-Reply-To: <200901032017.27608.max@love2party.net> References: <20090101183026.GA15385@onelab2.iet.unipi.it> <21267890.post@talk.nabble.com> <200901032017.27608.max@love2party.net> Message-ID: <21268756.post@talk.nabble.com> 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. From christof.schulze at gmx.net Sun Jan 4 00:38:02 2009 From: christof.schulze at gmx.net (Christof Schulze) Date: Sun Jan 4 00:38:10 2009 Subject: kldload exec format error on amd64 freebsd-7.1-rc2 Message-ID: <20090104011107.143069c3@ccschu935> Hello Everyone, this is my first post to the list so I hope I am not asking a dumb question even though I searched. I am trying to get the Ricoh SD Card reader sdhci0@pci0:5:9:2: class=0x080500 card=0xc024144d chip=0x08221180 rev=0x18 hdr=0x00 to work with the driver written by Alex Motin. The sdhci and mmc code compiles fine and loads into my kernel. The mmcsd module which as I understand things is needed to recognize an inserted SD Card, attach a device name to it etc compiles fine (I ran make clean beforehand) but I cannot kldload it: # kldload mmcsd kldload: can't load mmcsd: Exec format error # dmesg |tail g_vfs_done():acd0[READ(offset=530432, length=2048)]error = 5 g_vfs_done():acd0[READ(offset=530432, length=2048)]error = 5 g_vfs_done():acd0[READ(offset=530432, length=2048)]error = 5 g_vfs_done():acd0[READ(offset=530432, length=2048)]error = 5 g_vfs_done():acd0[READ(offset=530432, length=2048)]error = 5 g_vfs_done():acd0[READ(offset=530432, length=2048)]error = 5 link_elf_obj: symbol kproc_create undefined kldload: /boot/kernel/mmcsd.ko: Unsupported file type link_elf_obj: symbol kproc_create undefined kldload: /boot/kernel/mmcsd.ko: Unsupported file type I ran out of ideas and things to try so maybe someone on this list still has more ideas than I do and is willing to share them. I would greatly appreciate it and of course I will provide further info if needed. These are the stats for the system: # uname -a FreeBSD ccschu935 7.1-RC2 FreeBSD 7.1-RC2 #0: Tue Dec 23 11:42:13 UTC 2008 root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 # kldstat Id Refs Address Size Name 1 39 0xffffffff80100000 b6fd98 kernel 2 1 0xffffffff80c70000 f5b78 zfs.ko 3 2 0xffffffff80d66000 2c00 opensolaris.ko 4 2 0xffffffff80d69000 38f00 linux.ko 5 1 0xffffffff80da2000 f2a8 if_ipw.ko 6 1 0xffffffff80db2000 1a940 snd_hda.ko 7 2 0xffffffff80dcd000 67470 sound.ko 8 1 0xffffffff80e35000 4fe0 atapicam.ko 9 1 0xffffffff80e3a000 33f50 ipw_bss.ko 10 1 0xffffffff80e6e000 32000 ipw_ibss.ko 11 1 0xffffffff80ea0000 30de8 ipw_monitor.ko 12 1 0xffffffffaf67a000 1076 daemon_saver.ko 13 1 0xffffffffaf6c2000 734 rtc.ko 14 1 0xffffffffaf6c7000 4c7c i915.ko 15 1 0xffffffffaf6cc000 d7ec drm.ko 16 1 0xffffffffaf858000 8eb2 if_wpi.ko 17 1 0xffffffffaf931000 24b2e wpifw.ko 18 1 0xffffffffaf7db000 3c65 sdhci.ko 19 1 0xffffffffafa8c000 4241 mmc.ko Regards Christof Schulze -- From sam at freebsd.org Sun Jan 4 05:20:33 2009 From: sam at freebsd.org (Sam Leffler) Date: Sun Jan 4 05:20:41 2009 Subject: hosts on bridged wlan can not reliably see each other In-Reply-To: <495F0B2D.7060701@psg.com> References: <495F0B2D.7060701@psg.com> Message-ID: <49604720.4070703@freebsd.org> Randy Bush wrote: > 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? Use tcpdump to track where the packets are visible. If this is a wireless issue you will have stats to identify drops as well as the usual debug facilities. Sam From randy at psg.com Sun Jan 4 05:44:46 2009 From: randy at psg.com (Randy Bush) Date: Sun Jan 4 05:44:53 2009 Subject: hosts on bridged wlan can not reliably see each other In-Reply-To: <49604720.4070703@freebsd.org> References: <495F0B2D.7060701@psg.com> <49604720.4070703@freebsd.org> Message-ID: <49604CCA.7050301@psg.com> On 09.01.04 14:20, Sam Leffler wrote: > Randy Bush wrote: >> 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? > > Use tcpdump to track where the packets are visible. If this is a > wireless issue you will have stats to identify drops as well as the > usual debug facilities. sorry, this is why i was arp conscious soekris# ping 192.168.0.129 PING 192.168.0.129 (192.168.0.129): 56 data bytes 64 bytes from 192.168.0.129: icmp_seq=0 ttl=64 time=113.103 ms 64 bytes from 192.168.0.129: icmp_seq=1 ttl=64 time=349.680 ms 64 bytes from 192.168.0.129: icmp_seq=2 ttl=64 time=366.531 ms ^C --- 192.168.0.129 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 113.103/276.438/366.531/115.700 ms then, when pinging (unsuccessfully) from another host on the wireless soekris# tcpdump -i bridge0 host 192.168.0.129 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on bridge0, link-type EN10MB (Ethernet), capture size 96 bytes 05:40:28.486793 arp who-has 192.168.0.129 tell 192.168.0.12 05:40:29.486335 arp who-has 192.168.0.129 tell 192.168.0.12 05:40:30.486776 arp who-has 192.168.0.129 tell 192.168.0.12 05:40:31.487058 arp who-has 192.168.0.129 tell 192.168.0.12 05:40:32.487227 arp who-has 192.168.0.129 tell 192.168.0.12 ^C 5 packets captured 2192 packets received by filter 0 packets dropped by kernel ath ierrors are an old fact of life here, see a thread from almost a year ago soekris# netstat -ni Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll vr0 1500 00:00:24:c8:b3:28 139171779 0 102370058 0 0 vr1 1500 00:00:24:c8:b3:29 0 0 0 0 0 vr2 1500 00:00:24:c8:b3:2a 11034998 0 54497266 0 0 vr3 1500 00:00:24:c8:b3:2b 246912 0 321750 0 0 ath0 2290 00:0b:6b:83:59:25 192042747 20665363 77278643 27 0 lo0 16384 111523 0 111523 0 0 lo0 16384 fe80:6::1/64 fe80:6::1 0 - 0 - - lo0 16384 ::1/128 ::1 0 - 0 - - lo0 16384 127.0.0.0/8 127.0.0.1 111523 - 111523 - - bridg 1500 d6:9b:35:b7:7c:bd 92627892 0 131886570 0 0 bridg 1500 192.168.0.0/2 192.168.0.1 231764 - 146544 - - wlan0 1500 00:0b:6b:83:59:25 81345984 0 77084603 192714 0 wlan1 1500 00:0b:6b:83:59:25 0 0 0 0 0 tun0 1454 138915852 0 102337216 0 0 tun0 1454 210.138.216.5 210.138.216.50 7709196 - 10317194 - - randy From sam at freebsd.org Sun Jan 4 06:30:11 2009 From: sam at freebsd.org (Sam Leffler) Date: Sun Jan 4 06:30:18 2009 Subject: hosts on bridged wlan can not reliably see each other In-Reply-To: <49604CCA.7050301@psg.com> References: <495F0B2D.7060701@psg.com> <49604720.4070703@freebsd.org> <49604CCA.7050301@psg.com> Message-ID: <49605770.1050702@freebsd.org> Randy Bush wrote: > On 09.01.04 14:20, Sam Leffler wrote: >> Randy Bush wrote: >>> 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? >> >> Use tcpdump to track where the packets are visible. If this is a >> wireless issue you will have stats to identify drops as well as the >> usual debug facilities. > > sorry, this is why i was arp conscious > > soekris# ping 192.168.0.129 > PING 192.168.0.129 (192.168.0.129): 56 data bytes > 64 bytes from 192.168.0.129: icmp_seq=0 ttl=64 time=113.103 ms > 64 bytes from 192.168.0.129: icmp_seq=1 ttl=64 time=349.680 ms > 64 bytes from 192.168.0.129: icmp_seq=2 ttl=64 time=366.531 ms > ^C > --- 192.168.0.129 ping statistics --- > 3 packets transmitted, 3 packets received, 0.0% packet loss > round-trip min/avg/max/stddev = 113.103/276.438/366.531/115.700 ms > > then, when pinging (unsuccessfully) from another host on the wireless > > soekris# tcpdump -i bridge0 host 192.168.0.129 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on bridge0, link-type EN10MB (Ethernet), capture size 96 bytes > 05:40:28.486793 arp who-has 192.168.0.129 tell 192.168.0.12 > 05:40:29.486335 arp who-has 192.168.0.129 tell 192.168.0.12 > 05:40:30.486776 arp who-has 192.168.0.129 tell 192.168.0.12 > 05:40:31.487058 arp who-has 192.168.0.129 tell 192.168.0.12 > 05:40:32.487227 arp who-has 192.168.0.129 tell 192.168.0.12 > ^C > 5 packets captured > 2192 packets received by filter > 0 packets dropped by kernel > > > ath ierrors are an old fact of life here, see a thread from almost a > year ago > > soekris# netstat -ni > Name Mtu Network Address Ipkts Ierrs Opkts > Oerrs Coll > vr0 1500 00:00:24:c8:b3:28 139171779 0 102370058 > 0 0 > vr1 1500 00:00:24:c8:b3:29 0 0 0 0 0 > vr2 1500 00:00:24:c8:b3:2a 11034998 0 54497266 0 0 > vr3 1500 00:00:24:c8:b3:2b 246912 0 321750 0 0 > ath0 2290 00:0b:6b:83:59:25 192042747 20665363 77278643 > 27 0 > lo0 16384 111523 0 111523 0 0 > lo0 16384 fe80:6::1/64 fe80:6::1 0 - 0 - - > lo0 16384 ::1/128 ::1 0 - 0 - - > lo0 16384 127.0.0.0/8 127.0.0.1 111523 - 111523 - - > bridg 1500 d6:9b:35:b7:7c:bd 92627892 0 131886570 > 0 0 > bridg 1500 192.168.0.0/2 192.168.0.1 231764 - 146544 - - > wlan0 1500 00:0b:6b:83:59:25 81345984 0 77084603 > 192714 0 > wlan1 1500 00:0b:6b:83:59:25 0 0 0 0 0 > tun0 1454 138915852 0 102337216 > 0 0 > tun0 1454 210.138.216.5 210.138.216.50 7709196 - 10317194 - - > > > randy > > I don't see you looking on the wireless interface to see if the arp who-has packet goes out. You know it hit the bridge from the wireless sta but not that it went out over the wireless interface. If you don't see it hit the air then look for a reason for a drop. wlanstats should show you and/or wlandebug +output. Looking at the mac addresses registered w/ the bridge might also tell you where packets are being sent. BTW I see an ath0 interface in your diagram but wlan0 and wlan1 in your netstat output. I'm guessing your setup is confused but you haven't provided the info to be sure. Sam From randy at psg.com Sun Jan 4 06:46:25 2009 From: randy at psg.com (Randy Bush) Date: Sun Jan 4 06:46:32 2009 Subject: hosts on bridged wlan can not reliably see each other In-Reply-To: <49605770.1050702@freebsd.org> References: <495F0B2D.7060701@psg.com> <49604720.4070703@freebsd.org> <49604CCA.7050301@psg.com> <49605770.1050702@freebsd.org> Message-ID: <49605B3D.50403@psg.com> On 09.01.04 15:30, Sam Leffler wrote: > Randy Bush wrote: >> On 09.01.04 14:20, Sam Leffler wrote: >>> Randy Bush wrote: >>>> 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? >>> Use tcpdump to track where the packets are visible. If this is a >>> wireless issue you will have stats to identify drops as well as the >>> usual debug facilities. >> sorry, this is why i was arp conscious >> >> soekris# ping 192.168.0.129 >> PING 192.168.0.129 (192.168.0.129): 56 data bytes >> 64 bytes from 192.168.0.129: icmp_seq=0 ttl=64 time=113.103 ms >> 64 bytes from 192.168.0.129: icmp_seq=1 ttl=64 time=349.680 ms >> 64 bytes from 192.168.0.129: icmp_seq=2 ttl=64 time=366.531 ms >> ^C >> --- 192.168.0.129 ping statistics --- >> 3 packets transmitted, 3 packets received, 0.0% packet loss >> round-trip min/avg/max/stddev = 113.103/276.438/366.531/115.700 ms >> >> then, when pinging (unsuccessfully) from another host on the wireless >> >> soekris# tcpdump -i bridge0 host 192.168.0.129 >> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode >> listening on bridge0, link-type EN10MB (Ethernet), capture size 96 bytes >> 05:40:28.486793 arp who-has 192.168.0.129 tell 192.168.0.12 >> 05:40:29.486335 arp who-has 192.168.0.129 tell 192.168.0.12 >> 05:40:30.486776 arp who-has 192.168.0.129 tell 192.168.0.12 >> 05:40:31.487058 arp who-has 192.168.0.129 tell 192.168.0.12 >> 05:40:32.487227 arp who-has 192.168.0.129 tell 192.168.0.12 >> ^C >> 5 packets captured >> 2192 packets received by filter >> 0 packets dropped by kernel >> >> >> ath ierrors are an old fact of life here, see a thread from almost a >> year ago >> >> soekris# netstat -ni >> Name Mtu Network Address Ipkts Ierrs Opkts >> Oerrs Coll >> vr0 1500 00:00:24:c8:b3:28 139171779 0 102370058 >> 0 0 >> vr1 1500 00:00:24:c8:b3:29 0 0 0 0 0 >> vr2 1500 00:00:24:c8:b3:2a 11034998 0 54497266 0 0 >> vr3 1500 00:00:24:c8:b3:2b 246912 0 321750 0 0 >> ath0 2290 00:0b:6b:83:59:25 192042747 20665363 77278643 >> 27 0 >> lo0 16384 111523 0 111523 0 0 >> lo0 16384 fe80:6::1/64 fe80:6::1 0 - 0 - - >> lo0 16384 ::1/128 ::1 0 - 0 - - >> lo0 16384 127.0.0.0/8 127.0.0.1 111523 - 111523 - - >> bridg 1500 d6:9b:35:b7:7c:bd 92627892 0 131886570 >> 0 0 >> bridg 1500 192.168.0.0/2 192.168.0.1 231764 - 146544 - - >> wlan0 1500 00:0b:6b:83:59:25 81345984 0 77084603 >> 192714 0 >> wlan1 1500 00:0b:6b:83:59:25 0 0 0 0 0 >> tun0 1454 138915852 0 102337216 >> 0 0 >> tun0 1454 210.138.216.5 210.138.216.50 7709196 - 10317194 - - >> >> >> randy >> >> > > I don't see you looking on the wireless interface to see if the arp > who-has packet goes out. You know it hit the bridge from the wireless > sta but not that it went out over the wireless interface. If you don't > see it hit the air then look for a reason for a drop. wlanstats should > show you and/or wlandebug +output. Looking at the mac addresses > registered w/ the bridge might also tell you where packets are being sent. the soekris sees all soek# arp -an soek0.psg.com:/root# ping 192.168.0.129 PING 192.168.0.129 (192.168.0.129): 56 data bytes 64 bytes from 192.168.0.129: icmp_seq=0 ttl=64 time=417.356 ms 64 bytes from 192.168.0.129: icmp_seq=1 ttl=64 time=482.347 ms 64 bytes from 192.168.0.129: icmp_seq=2 ttl=64 time=397.344 ms ^C --- 192.168.0.129 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 397.344/432.349/482.347/36.286 ms soek# 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.28) at 00:80:77:04:35:16 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] but pinging from a macbook pro on same wireless (192.168.0.12) to the iphone (192.168.0.129) as seen from the soekris (192.168.0.1) Jan 4 06:33:13 soek kernel: rtfree: 0xc2e80000 has 1 refs Jan 4 06:33:14 soek kernel: wlan0: [ff:ff:ff:ff:ff:ff] discard frame, sta not associated (type 0x0806) Jan 4 06:33:14 soek kernel: arp_proxy: ignoring request from 192.168.0.12 via wlan0, expecting bridge0 Jan 4 06:33:14 soek kernel: rtfree: 0xc2e80000 has 1 refs Jan 4 06:33:15 soek kernel: wlan0: [ff:ff:ff:ff:ff:ff] discard frame, sta not associated (type 0x0806) Jan 4 06:33:15 soek kernel: arp_proxy: ignoring request from 192.168.0.12 via wlan0, expecting bridge0 Jan 4 06:33:15 soek kernel: rtfree: 0xc2e80000 has 1 refs Jan 4 06:33:16 soek kernel: wlan0: [ff:ff:ff:ff:ff:ff] discard frame, sta not associated (type 0x0806) Jan 4 06:33:16 soek kernel: arp_proxy: ignoring request from 192.168.0.12 via wlan0, expecting bridge0 Jan 4 06:33:16 soek kernel: rtfree: 0xc2e80000 has 1 refs Jan 4 06:33:39 soek kernel: wlan0: [01:00:5e:7f:ff:fa] discard frame, sta not associated (type 0x0800) Jan 4 06:33:44 soek kernel: wlan0: [01:00:0c:cc:cc:cc] discard frame, sta not associated (type 0x0074) Jan 4 06:33:45 soek kernel: wlan0: [ff:ff:ff:ff:ff:ff] discard frame, sta not associated (type 0x0800) > BTW I see an ath0 interface in your diagram but wlan0 and wlan1 in your > netstat output. did not update diagram when life changed six months ago . randy From stas at FreeBSD.org Sun Jan 4 09:39:31 2009 From: stas at FreeBSD.org (Stanislav Sedov) Date: Sun Jan 4 09:39:37 2009 Subject: kldload exec format error on amd64 freebsd-7.1-rc2 In-Reply-To: <20090104011107.143069c3@ccschu935> References: <20090104011107.143069c3@ccschu935> Message-ID: <20090104124141.5d757262.stas@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 4 Jan 2009 01:11:07 +0100 Christof Schulze mentioned: > Hello Everyone, > > this is my first post to the list so I hope I am not asking a dumb > question even though I searched. > > I am trying to get the Ricoh SD Card reader > sdhci0@pci0:5:9:2: class=0x080500 card=0xc024144d chip=0x08221180 > rev=0x18 hdr=0x00 > to work with the driver written by Alex Motin. > The sdhci and mmc code compiles fine and loads into my kernel. > The mmcsd module which as I understand things is needed to recognize > an inserted SD Card, attach a device name to it etc compiles fine (I > ran make clean beforehand) but I cannot kldload it: > > # kldload mmcsd > kldload: can't load mmcsd: Exec format error > > # dmesg |tail > g_vfs_done():acd0[READ(offset=530432, length=2048)]error = 5 > g_vfs_done():acd0[READ(offset=530432, length=2048)]error = 5 > g_vfs_done():acd0[READ(offset=530432, length=2048)]error = 5 > g_vfs_done():acd0[READ(offset=530432, length=2048)]error = 5 > g_vfs_done():acd0[READ(offset=530432, length=2048)]error = 5 > g_vfs_done():acd0[READ(offset=530432, length=2048)]error = 5 > link_elf_obj: symbol kproc_create undefined > kldload: /boot/kernel/mmcsd.ko: Unsupported file type > link_elf_obj: symbol kproc_create undefined > kldload: /boot/kernel/mmcsd.ko: Unsupported file type > > I ran out of ideas and things to try so maybe someone on this list > still has more ideas than I do and is willing to share them. > I would greatly appreciate it and of course I will provide further > info if needed. > > These are the stats for the system: > > # uname -a > FreeBSD ccschu935 7.1-RC2 FreeBSD 7.1-RC2 #0: Tue Dec 23 11:42:13 UTC > 2008 root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC > amd64 > > > # kldstat > Id Refs Address Size Name > 1 39 0xffffffff80100000 b6fd98 kernel > 2 1 0xffffffff80c70000 f5b78 zfs.ko > 3 2 0xffffffff80d66000 2c00 opensolaris.ko > 4 2 0xffffffff80d69000 38f00 linux.ko > 5 1 0xffffffff80da2000 f2a8 if_ipw.ko > 6 1 0xffffffff80db2000 1a940 snd_hda.ko > 7 2 0xffffffff80dcd000 67470 sound.ko > 8 1 0xffffffff80e35000 4fe0 atapicam.ko > 9 1 0xffffffff80e3a000 33f50 ipw_bss.ko > 10 1 0xffffffff80e6e000 32000 ipw_ibss.ko > 11 1 0xffffffff80ea0000 30de8 ipw_monitor.ko > 12 1 0xffffffffaf67a000 1076 daemon_saver.ko > 13 1 0xffffffffaf6c2000 734 rtc.ko > 14 1 0xffffffffaf6c7000 4c7c i915.ko > 15 1 0xffffffffaf6cc000 d7ec drm.ko > 16 1 0xffffffffaf858000 8eb2 if_wpi.ko > 17 1 0xffffffffaf931000 24b2e wpifw.ko > 18 1 0xffffffffaf7db000 3c65 sdhci.ko > 19 1 0xffffffffafa8c000 4241 mmc.ko > I think you took the code intended for CURRENT. E.g. kproc_create does not exists on 7.x. I believe there were some patches agains 7.x as well. You may try to ask mav for them too. The other way might be to update your system to CURRENT and try with it. If you'll take CURRENT kernel it should be able to run 7.x world without problems. - -- Stanislav Sedov ST4096-RIPE -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAklghGAACgkQK/VZk+smlYGtCQCeJjWsnZPwmHOTuHW+5dRrqjcE Xu4AnRpumhlywVKos5r9x7ZMJJxGmjXO =ByTp -----END PGP SIGNATURE----- !DSPAM:496083d0967001599314920! From christof.schulze at gmx.net Sun Jan 4 10:48:49 2009 From: christof.schulze at gmx.net (Christof Schulze) Date: Sun Jan 4 10:48:57 2009 Subject: kldload exec format error on amd64 freebsd-7.1-rc2 In-Reply-To: <20090104011107.143069c3@ccschu935> References: <20090104011107.143069c3@ccschu935> Message-ID: <20090104114844.06db3982@ccschu935> Hi again, something I forgot to mention: The mmcsd Code is not updated/changed compared to 7.1-rc2. Maybe this is the issue? If so where do I have to go and grab the correct sources? Regards Christof Schulze -- From nork at FreeBSD.org Sun Jan 4 15:00:26 2009 From: nork at FreeBSD.org (Norikatsu Shigemura) Date: Sun Jan 4 15:00:33 2009 Subject: Call for axe(4) testers. In-Reply-To: <200901011233.15537.hselasky@c2i.net> References: <47297827@bb.ipt.ru> <20081231003115.GA22037@cdnetworks.co.kr> <20090101022845.4dc8bc27.nork@FreeBSD.org> <200901011233.15537.hselasky@c2i.net> Message-ID: <20090105000014.a11a4d7f.nork@FreeBSD.org> Hi alfred and hps. On Thu, 1 Jan 2009 12:33:14 +0100 Hans Petter Selasky 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 . I tested on r186730 by alfred@. 1. When my all devices are detached, OS is freeze(not panic). 2. GU-1000T doesn't work, but UE-200TX-G works well. From hselasky at c2i.net Sun Jan 4 16:12:46 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sun Jan 4 16:12:54 2009 Subject: Call for axe(4) testers. In-Reply-To: <20090105000014.a11a4d7f.nork@FreeBSD.org> References: <47297827@bb.ipt.ru> <200901011233.15537.hselasky@c2i.net> <20090105000014.a11a4d7f.nork@FreeBSD.org> Message-ID: <200901041715.06163.hselasky@c2i.net> On Sunday 04 January 2009, Norikatsu Shigemura wrote: > Hi alfred and hps. > > > 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 . > > I tested on r186730 by alfred@. > > 1. When my all devices are detached, OS is freeze(not panic). When are all devices detached? Can you explain your cable setup and where you unplug? Are there any USB HUBs involved? > 2. GU-1000T doesn't work, but UE-200TX-G works well. If your kernel is compiled with KDB, then try pressing CTRL+ALT+ESC to enter the debugger after the freeze. Then dump the backtrace of all the threads. Look for function names containing the word "axe". --HPS From nork at FreeBSD.org Sun Jan 4 16:35:12 2009 From: nork at FreeBSD.org (Norikatsu Shigemura) Date: Sun Jan 4 16:35:22 2009 Subject: Call for axe(4) testers. In-Reply-To: <200901041715.06163.hselasky@c2i.net> References: <47297827@bb.ipt.ru> <200901011233.15537.hselasky@c2i.net> <20090105000014.a11a4d7f.nork@FreeBSD.org> <200901041715.06163.hselasky@c2i.net> Message-ID: <20090105013501.dc07970c.nork@FreeBSD.org> Hi hps! On Sun, 4 Jan 2009 17:15:05 +0100 Hans Petter Selasky wrote: > > I tested on r186730 by alfred@. > > 1. When my all devices are detached, OS is freeze(not panic). > When are all devices detached? Can you explain your cable setup and where you > unplug? Are there any USB HUBs involved? Ah, I did following steps: foreach (GU-1000T UE-200TX-G LUA-U2-KTX) { Plug Unplug -> Freeze No key accept reset } On plug: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ugen1.2: at usbus1 axe0: on usbus1 miibus1: on axe0 ukphy0: PHY 16 on miibus1 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto axe0: Ethernet address: 00:90:cc:e7:6b:20 axe0: link state changed to DOWN - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - devinfo -rv - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ehci0 pnpinfo vendor=0x8086 device=0x265c subvendor=0x10f7 subdevice=0x8338 class=0x0c0320 at slot=29 function=7 handle=\_SB_.PCI0.EHCI I/O memory addresses: 0xb0040000-0xb00403ff usbus1 ushub1 axe0 pnpinfo vendor=0x0b95 product=0x7720 devclass=0xff devsubclass=0xff sernum="" intclass=0xff intsubclass=0xff at port=1 interface=0 miibus1 ukphy0 pnpinfo oui=0xec6 model=0x1 rev=0x1 at phyno=16 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - I have no USB HUBs, so I pluged into NOTE PC's USB port. usbconfig list - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen1.1: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen1.2: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > 2. GU-1000T doesn't work, but UE-200TX-G works well. > If your kernel is compiled with KDB, then try pressing CTRL+ALT+ESC to enter > the debugger after the freeze. Then dump the backtrace of all the threads. > Look for function names containing the word "axe". Any key(CTRL+ALT+DEL, etc..) didn't accept. But I didn't hit CTRL+ALT+ESC. So I'll try to hit it. From hselasky at c2i.net Sun Jan 4 16:46:02 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sun Jan 4 16:46:08 2009 Subject: Call for axe(4) testers. In-Reply-To: <20090105013501.dc07970c.nork@FreeBSD.org> References: <47297827@bb.ipt.ru> <200901041715.06163.hselasky@c2i.net> <20090105013501.dc07970c.nork@FreeBSD.org> Message-ID: <200901041748.18798.hselasky@c2i.net> Hi, Also try to turn on axe debugging: sysctl hw.usb2.axe.debug=15 I suspect it is a problem with the miibus. Try waiting some time before you unplug the device (60 seconds). --HPS On Sunday 04 January 2009, Norikatsu Shigemura wrote: > Hi hps! > > On Sun, 4 Jan 2009 17:15:05 +0100 > > Hans Petter Selasky wrote: > > > I tested on r186730 by alfred@. > > > 1. When my all devices are detached, OS is freeze(not panic). > > > > When are all devices detached? Can you explain your cable setup and where > > you unplug? Are there any USB HUBs involved? > > Ah, I did following steps: > foreach (GU-1000T UE-200TX-G LUA-U2-KTX) { > Plug > Unplug -> Freeze > No key accept > reset > } > > On plug: > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - ugen1.2: at usbus1 > axe0: on usbus1 > miibus1: on axe0 > ukphy0: PHY 16 on miibus1 > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > axe0: Ethernet address: 00:90:cc:e7:6b:20 > axe0: link state changed to DOWN > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - > > devinfo -rv > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - ehci0 pnpinfo vendor=0x8086 device=0x265c subvendor=0x10f7 > subdevice=0x8338 class=0x0c0320 at slot=29 function=7 > handle=\_SB_.PCI0.EHCI I/O memory addresses: > 0xb0040000-0xb00403ff > usbus1 > ushub1 > axe0 pnpinfo vendor=0x0b95 product=0x7720 devclass=0xff > devsubclass=0xff sernum="" intclass=0xff intsubclass=0xff at port=1 > interface=0 miibus1 > ukphy0 pnpinfo oui=0xec6 model=0x1 rev=0x1 at phyno=16 > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - > > I have no USB HUBs, so I pluged into NOTE PC's USB port. > > usbconfig list > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL > (12Mbps) pwr=ON ugen1.1: at usbus1, cfg=0 md=HOST > spd=HIGH (480Mbps) pwr=ON ugen1.2: at usbus1, > cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON - - - - - - - - - - - - - - - - - - > - - - - - - - - - - - - - - - - - - - - - - > > > > 2. GU-1000T doesn't work, but UE-200TX-G works well. > > > > If your kernel is compiled with KDB, then try pressing CTRL+ALT+ESC to > > enter the debugger after the freeze. Then dump the backtrace of all the > > threads. Look for function names containing the word "axe". > > Any key(CTRL+ALT+DEL, etc..) didn't accept. But I didn't hit > CTRL+ALT+ESC. So I'll try to hit it. > _______________________________________________ > 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 nork at FreeBSD.org Sun Jan 4 17:18:22 2009 From: nork at FreeBSD.org (Norikatsu Shigemura) Date: Sun Jan 4 17:18:29 2009 Subject: Call for axe(4) testers. In-Reply-To: <200901041748.18798.hselasky@c2i.net> References: <47297827@bb.ipt.ru> <200901041715.06163.hselasky@c2i.net> <20090105013501.dc07970c.nork@FreeBSD.org> <200901041748.18798.hselasky@c2i.net> Message-ID: <20090105021809.d3848b9c.nork@FreeBSD.org> Hi hps! On Sun, 4 Jan 2009 17:48:16 +0100 Hans Petter Selasky wrote: > Also try to turn on axe debugging: > sysctl hw.usb2.axe.debug=15 OK, I'll try. > I suspect it is a problem with the miibus. Yes, me too. after unplug: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - axe0: at ushub1, port 2, addr 3 (disconnected) ukphy0: detached miibus1: detached (freeze) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - I hitted CTRL+ALT+ESC, but nothing. > Try waiting some time before you unplug the device (60 seconds). Thank you, I'll try with single user mode. From nork at FreeBSD.org Sun Jan 4 17:53:38 2009 From: nork at FreeBSD.org (Norikatsu Shigemura) Date: Sun Jan 4 17:53:45 2009 Subject: Call for axe(4) testers. In-Reply-To: <20090105021809.d3848b9c.nork@FreeBSD.org> References: <47297827@bb.ipt.ru> <200901041715.06163.hselasky@c2i.net> <20090105013501.dc07970c.nork@FreeBSD.org> <200901041748.18798.hselasky@c2i.net> <20090105021809.d3848b9c.nork@FreeBSD.org> Message-ID: <20090105025330.68b22f63.nork@FreeBSD.org> Hi hps! On Mon, 5 Jan 2009 02:18:09 +0900 Norikatsu Shigemura wrote: > > Try waiting some time before you unplug the device (60 seconds). > Thank you, I'll try with single user mode. Hum... No different... (added some messages.., but...) From jilles at stack.nl Sun Jan 4 19:52:08 2009 From: jilles at stack.nl (Jilles Tjoelker) Date: Sun Jan 4 19:52:16 2009 Subject: kernel complaint about /dev/pts (maybe) In-Reply-To: <18783.28606.874391.376202@jerusalem.litteratus.org> References: <18783.28606.874391.376202@jerusalem.litteratus.org> Message-ID: <20090104195205.GA14447@stack.nl> On Sat, Jan 03, 2009 at 09:01:34AM -0500, Robert Huff wrote: > 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? NetBSD seems to have fixed this (properly) in their comsat 3.5 years ago, see http://cvsweb.netbsd.org/bsdweb.cgi/src/libexec/comsat/comsat.c.diff?r1=1.32&r2=1.33&only_with_tag=MAIN and http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=30170 A comment describing the potential issue was added over 10 years ago: http://cvsweb.netbsd.org/bsdweb.cgi/src/libexec/comsat/comsat.c.diff?r1=1.11&r2=1.12&only_with_tag=MAIN Briefly, the problem is that comsat thinks that "pts/1" is an attempt to access different files by writing into utmp. It needs to be taught that SVr4 style ptys are OK. NetBSD additionally checks the return value of tcgetattr() so it will never write to non-ttys. -- Jilles Tjoelker From rdivacky at freebsd.org Sun Jan 4 21:07:50 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Sun Jan 4 21:07:57 2009 Subject: panic related to ipv6 (afaik) Message-ID: <20090104205056.GA41264@freebsd.org> hi with r186748 I am getting this panic early on boot (hand rewritten): mi_startup() net_add_domain() ip6_ctloutput(0xsome_number, 0, 0, 0, 3,...) in ip6_ctloutput+0x55 (on i386), the panic is null reference I cant get a dump as dump device has not been defined yet ;( kernel from Tue Dec 30 23:07:56 CET 2008 (dont know the revision but should be within 10 minutes around the date) boots just fine I can 100% reproduce this so if you need anything that can be obtained from a DDB prompt just tell me. roman -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090104/1df937b4/attachment.pgp From ed at 80386.nl Sun Jan 4 21:14:41 2009 From: ed at 80386.nl (Ed Schouten) Date: Sun Jan 4 21:14:48 2009 Subject: panic related to ipv6 (afaik) In-Reply-To: <20090104205056.GA41264@freebsd.org> References: <20090104205056.GA41264@freebsd.org> Message-ID: <20090104211439.GJ14235@hoeg.nl> Hello Roman, * Roman Divacky wrote: > with r186748 I am getting this panic early on boot (hand rewritten): > > I had the same problem, but rwatson discovered the bug. He'll commit a fix in a couple of minutes. -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090104/606b1cdd/attachment.pgp From yr.retarded at gmail.com Sun Jan 4 21:35:07 2009 From: yr.retarded at gmail.com (Chris Ruiz) Date: Sun Jan 4 21:35:13 2009 Subject: panic related to ipv6 (afaik) In-Reply-To: <20090104211439.GJ14235@hoeg.nl> References: <20090104205056.GA41264@freebsd.org> <20090104211439.GJ14235@hoeg.nl> Message-ID: <58c737d70901041335s72ec7335o298d7329fe8a2090@mail.gmail.com> On Sun, Jan 4, 2009 at 3:14 PM, Ed Schouten wrote: > Hello Roman, > > * Roman Divacky wrote: >> with r186748 I am getting this panic early on boot (hand rewritten): >> >> > > I had the same problem, but rwatson discovered the bug. He'll commit a > fix in a couple of minutes. > > -- > Ed Schouten > WWW: http://80386.nl/ > r186750 breaks the build: cc -c -O2 -fno-strict-aliasing -pipe -march=nocona -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 -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror /usr/src/sys/netinet6/in6_gif.c cc1: warnings being treated as errors /usr/src/sys/netinet6/in6_gif.c:84: warning: excess elements in struct initializer /usr/src/sys/netinet6/in6_gif.c:84: warning: (near initialization for 'in6_gif_protosw') *** Error code 1 =Chris From rwatson at FreeBSD.org Sun Jan 4 22:01:06 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Jan 4 22:01:12 2009 Subject: panic related to ipv6 (afaik) In-Reply-To: <58c737d70901041335s72ec7335o298d7329fe8a2090@mail.gmail.com> References: <20090104205056.GA41264@freebsd.org> <20090104211439.GJ14235@hoeg.nl> <58c737d70901041335s72ec7335o298d7329fe8a2090@mail.gmail.com> Message-ID: On Sun, 4 Jan 2009, Chris Ruiz wrote: > r186750 breaks the build: > > cc -c -O2 -fno-strict-aliasing -pipe -march=nocona -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 > -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 -fno-omit-frame-pointer -mcmodel=kernel > -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow > -msoft-float -fno-asynchronous-unwind-tables -ffreestanding > -fstack-protector -Werror /usr/src/sys/netinet6/in6_gif.c cc1: warnings > being treated as errors /usr/src/sys/netinet6/in6_gif.c:84: warning: excess > elements in struct initializer /usr/src/sys/netinet6/in6_gif.c:84: warning: > (near initialization for 'in6_gif_protosw') *** Error code 1 Yes, unfortunately what was intended to be a relatively minor cleanup appears to have snowballed a bit. I think it's now back to booting *and* compiling, but if not let me know. Robert N M Watson Computer Laboratory University of Cambridge From volker at vwsoft.com Sun Jan 4 22:29:04 2009 From: volker at vwsoft.com (Volker) Date: Sun Jan 4 22:29:12 2009 Subject: panic in bundirty Message-ID: <49613379.8040901@vwsoft.com> Gentlemen, I've had the pleasure to inspect miwi's new tinderbox machine in a panic situation. The debugging info we're able to get out of the box is the following: panic: bundirty: buffer 0xffffffff9a475438 still on queue 1 #9 0xffffffff8049f196 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:556 #10 0xffffffff8050b540 in bundirty (bp=Variable "bp" is not available. ) at /usr/src/sys/kern/vfs_bio.c:1068 #11 0xffffffff8050d684 in brelse (bp=0xffffffff9a475438) at /usr/src/sys/kern/vfs_bio.c:1388 #12 0xffffffff8050f07c in bufdone (bp=0xffffffff9a475438) at /usr/src/sys/kern/vfs_bio.c:3157 #13 0xffffffff8069cb6c in ffs_backgroundwritedone (bp=0xffffffff9a475438) ---Type to continue, or q to quit--- at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1679 #14 0xffffffff8050f051 in bufdone (bp=0xffffffff9a475438) at /usr/src/sys/kern/vfs_bio.c:3151 #15 0xffffffff80452b51 in g_io_schedule_up (tp=Variable "tp" is not available. ) at /usr/src/sys/geom/geom_io.c:587 #16 0xffffffff8045323f in g_up_procbody () at /usr/src/sys/geom/geom_kern.c:95 #17 0xffffffff8048037a in fork_exit ( callout=0xffffffff804531d0 , arg=0x0, frame=0xffffffff80e63c80) at /usr/src/sys/kern/kern_fork.c:789 in frame 11, 'p *bp' gives: $1 = {b_bufobj = 0xffffff00034fe958, b_bcount = 16384, b_caller1 = 0x0, b_data = 0xffffffff9f4b7000 "", b_error = 5, b_iocmd = 2 '\002', b_ioflags = 2 '\002', b_iooffset = 7127891968, b_resid = 16384, b_iodone = 0, b_blkno = 13921664, b_offset = 7127891968, b_bobufs = { tqe_next = 0xffffffff9a505a38, tqe_prev = 0xffffff00034fe9a8}, b_left = 0x0, b_right = 0xffffffff9a505a38, b_vflags = 0, b_freelist = { tqe_next = 0xffffffff9a472db8, tqe_prev = 0xffffffff80b56210}, b_qindex = 1, b_flags = 41092, b_xflags = 33 '!', b_lock = {lock_object = { lo_name = 0xffffffff8083ce18 "bufwait", lo_type = 0xffffffff8083ce18 "bufwait", lo_flags = 91947008, lo_witness_data = {lod_list = {stqe_next = 0xffffffff80ae6f80}, lod_witness = 0xffffffff80ae6f80}}, lk_lock = 18446744073709551608, lk_recurse = 0, lk_timo = 0, lk_pri = 80}, b_bufsize = 16384, b_runningbufspace = 0, b_kvabase = 0xffffffff9f4b7000 "", b_kvasize = 16384, b_lblkno = 13921664, b_vp = 0xffffff00034fe820, b_dirtyoff = 0, b_dirtyend = 0, b_rcred = 0x0, b_wcred = 0x0, b_saveaddr = 0xffffffff9f4b7000, b_pager = {pg_reqpage = 0}, b_cluster = { cluster_head = {tqh_first = 0xffffffff9a479c68, tqh_last = 0xffffffff9a4901b0}, cluster_entry = { tqe_next = 0xffffffff9a479c68, tqe_prev = 0xffffffff9a4901b0}}, b_pages = {0xffffff00de0eafa0, 0xffffff00de0eb010, 0xffffff00de0eb080, 0xffffff00de0eb0f0, 0x0 }, b_npages = 4, b_dep = { lh_first = 0x0}, b_fsprivate1 = 0x0, b_fsprivate2 = 0x0, b_fsprivate3 = 0x0, b_pin_count = 0} This panic does not occur before commit 176708. The panic is in sys/kern/vfs_bio.c bundirty 1055: KASSERT( bp->b_flags & B_REMFREE || bp->b_qindex == QUEUE_NONE ... bp->b_qindex = 0x01 (QUEUE_FREE) bp->b_flags = 0xa084 (B_ASYNC | B_DELWRI | B_NOCACHE | B_INVAL) My assumption is: brele knows about the QUEUE_FREE but bundirty only wants to operate on QUEUE_NONE. Either this is a race condition, brele should not call bundirty or bundirty should operate not just on QUEUE_NONE buffers. As there have been some locking related commits in the changes in question, this might also be caused by an unlocked operation. right before the panic, we're seeing DMA errors: ad6: setting up DMA failed _vfs_done():ad6[WRITE(offset=5412487168, length=131072)]error = 5 ad6: FAILURE - load data ad6: setting up DMA failed g_vfs_done():ad6[WRITE(offset=5044109312, length=131072)]error = 5 g_vfs_done():ad6[WRITE(offset=5230985216, length=131072)]error = 5 g_vfs_done():ad6[WRITE(offset=5231116288, length=131072)]error = 5 g_vfs_done():ad6[WRITE(offset=5044240384, length=131072)]error = 5 g_vfs_done():ad6[WRITE(offset=5412618240, length=131072)]error = 5 g_vfs_done():ad4s1d[WRITE(offset=7127891968, length=16384)]error = 5 kgdb output can be found at: http://www.bsdmeat.net/~lando/miwi/kgdb.txt Suggestions what the correct fix to this issue is? Change bundirty or brele? Clean up locking? CC'ing those who committed to vfs_bio.c in the relevant time frame. Thanks Volker From rizzo at iet.unipi.it Sun Jan 4 23:37:45 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Sun Jan 4 23:37:52 2009 Subject: upcoming elfdump refactoring Message-ID: <20090104234238.GA44381@onelab2.iet.unipi.it> I need to extract value and size of some symbols from an ELF file, and make them available to a C program, something like nm -S /boot/kernel/kernel | grep -E "(kernload|kernbase|uscanner_devs)" Rather than using the above tools plus popen() and some parsing code, I have refactored src/usr.bin/elfdump/elfdump.c , making the main routine externally callable, returning the desired info in a struct rather than print them out. I don't know if/how other programs might need to call elfdump(), but given that the changes I made have no functional or performance drawback, I would like to commit them to the tree. Objections ? (note, the diff will be large because in the process I also removed global variables and staticize/constify things) cheers luigi From sobomax at FreeBSD.org Mon Jan 5 00:29:48 2009 From: sobomax at FreeBSD.org (Maxim Sobolev) Date: Mon Jan 5 00:29:55 2009 Subject: upcoming elfdump refactoring In-Reply-To: <20090104234238.GA44381@onelab2.iet.unipi.it> References: <20090104234238.GA44381@onelab2.iet.unipi.it> Message-ID: <49615475.2030803@FreeBSD.org> Luigi Rizzo wrote: > I need to extract value and size of some symbols from an ELF file, > and make them available to a C program, something like > > nm -S /boot/kernel/kernel | grep -E "(kernload|kernbase|uscanner_devs)" > > Rather than using the above tools plus popen() and some parsing code, > I have refactored src/usr.bin/elfdump/elfdump.c , > making the main routine externally callable, returning the > desired info in a struct rather than print them out. > > I don't know if/how other programs might need to call elfdump(), > but given that the changes I made have no functional or performance > drawback, I would like to commit them to the tree. > Objections ? > > (note, the diff will be large because in the process I also removed > global variables and staticize/constify things) Why not make this function part of libelf? -Maxim From rizzo at iet.unipi.it Mon Jan 5 00:56:10 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Mon Jan 5 00:56:18 2009 Subject: upcoming elfdump refactoring In-Reply-To: <49615475.2030803@FreeBSD.org> References: <20090104234238.GA44381@onelab2.iet.unipi.it> <49615475.2030803@FreeBSD.org> Message-ID: <20090105010105.GA47387@onelab2.iet.unipi.it> On Sun, Jan 04, 2009 at 04:29:41PM -0800, Maxim Sobolev wrote: > Luigi Rizzo wrote: > >I need to extract value and size of some symbols from an ELF file, > >and make them available to a C program, something like > > > > nm -S /boot/kernel/kernel | grep -E "(kernload|kernbase|uscanner_devs)" > > > >Rather than using the above tools plus popen() and some parsing code, > >I have refactored src/usr.bin/elfdump/elfdump.c , > >making the main routine externally callable, returning the > >desired info in a struct rather than print them out. > > > >I don't know if/how other programs might need to call elfdump(), > >but given that the changes I made have no functional or performance > >drawback, I would like to commit them to the tree. > >Objections ? > > > >(note, the diff will be large because in the process I also removed > >global variables and staticize/constify things) > > Why not make this function part of libelf? because i was not aware of its existance (also a reason why I posted the request - i didn't want to reinvent the wheel). Thanks for the pointer, I will look at libelf and see if it already contains soemthing that does what i need. cheers luigi From weongyo.jeong at gmail.com Mon Jan 5 01:20:39 2009 From: weongyo.jeong at gmail.com (Weongyo Jeong) Date: Mon Jan 5 01:20:46 2009 Subject: Can not build r186708 -CURRENT In-Reply-To: References: Message-ID: <20090105012025.GA12414@freebsd.weongyo.org> On Sat, Jan 03, 2009 at 04:10:26AM +0300, 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 Hmm.. It looks weird because sys/modules/ndis/Makefile would include usbdevs.h file. Could you please check it whether it has it? Or your system time? regards, Weongyo Jeong From yr.retarded at gmail.com Mon Jan 5 01:34:18 2009 From: yr.retarded at gmail.com (Chris Ruiz) Date: Mon Jan 5 01:34:26 2009 Subject: apcupsd & usb2 Message-ID: <58c737d70901041734u590ce80am7e86ad50077fd97@mail.gmail.com> apcupsd no longer works now that i switched to usb2. the usb2_input_hid module keeps attaching to it. before, with the old usb stack, my ups would attach as ugen0, my dmesg shows it attaching as uhid0 now and apcupsd cannot find it. if i unload the usb2_input_hid module, my ups disappears. because something is mentioned in the post install text for apcupsd, i believe that the usb2_hid_module should not be attaching to the ups. any help would be appreciated. [old stack] ugen0: on uhub5 [usb2] uhid0: on usbus5 Symlink: uhid0 -> usb5.2.0.16 [error message] apcupsd[3643]: apcupsd FATAL ERROR in bsd-usb.c at line 735 Cannot find UPS device -- For a link to detailed USB trouble shooting information, please see . apcupsd[3643]: apcupsd error shutdown completed thanks for all your hard work on the new usb stack, Chris Ruiz From xcllnt at mac.com Mon Jan 5 02:32:19 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Mon Jan 5 02:32:28 2009 Subject: upcoming elfdump refactoring In-Reply-To: <49615475.2030803@FreeBSD.org> References: <20090104234238.GA44381@onelab2.iet.unipi.it> <49615475.2030803@FreeBSD.org> Message-ID: <0AE16877-C02A-40A1-9F3B-FE839CB7B9E5@mac.com> On Jan 4, 2009, at 4:29 PM, Maxim Sobolev wrote: > Luigi Rizzo wrote: >> I need to extract value and size of some symbols from an ELF file, >> and make them available to a C program, something like >> nm -S /boot/kernel/kernel | grep -E "(kernload|kernbase| >> uscanner_devs)" >> Rather than using the above tools plus popen() and some parsing code, >> I have refactored src/usr.bin/elfdump/elfdump.c , >> making the main routine externally callable, returning the >> desired info in a struct rather than print them out. >> I don't know if/how other programs might need to call elfdump(), >> but given that the changes I made have no functional or performance >> drawback, I would like to commit them to the tree. >> Objections ? >> (note, the diff will be large because in the process I also removed >> global variables and staticize/constify things) > > Why not make this function part of libelf? Please don't. libelf has a standard and well-documented API. Don't add random or one-off functions simply on the basis of them having "elf" in the name. In fact, elfdump(1) should really use libelf(3) to read ELF files. -- Marcel Moolenaar xcllnt@mac.com From xcllnt at mac.com Mon Jan 5 03:41:01 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Mon Jan 5 03:41:07 2009 Subject: gpart In-Reply-To: <20081220.154722.162072679.nyan@jp.FreeBSD.org> References: <4EA5F491-CC52-43EC-AC03-F50F8B2D6186@mac.com> <20081219.181532.241936859.nyan@jp.FreeBSD.org> <354036B7-A4AA-4D66-A2AC-9CB66D292FAA@mac.com> <20081220.154722.162072679.nyan@jp.FreeBSD.org> Message-ID: <8BF346D6-B7EB-4FFC-9216-FEFCABBDADB8@mac.com> On Dec 19, 2008, at 10:47 PM, Takahashi Yoshihiro wrote: > In article <354036B7-A4AA-4D66-A2AC-9CB66D292FAA@mac.com> > Marcel Moolenaar writes: > >>> Please see: >>> http://lists.freebsd.org/pipermail/freebsd-arch/2008-September/008627.html >>> >>> The da0 has a BSD slice. GEOM_BSD/GEOM_PC98 recognize it correctly. >>> But the gpart does not. From debug printf (dmesg.txt), it seems >>> that >>> the gpart read incorrect sector. >> >> This seems to indicate that the pc98 slice is wrong, or >> you don't have the BSD disklabel in the right sector. >> >> Can you give me a dump of the first 32 sectors on the >> disk and the first 32 sectors of slice 1. > > I put to the following. > http://home.jp.freebsd.org/~nyan/geom/da0 > http://home.jp.freebsd.org/~nyan/geom/da0s1 > > BTW, the result of using the gpart is: > http://home.jp.freebsd.org/~nyan/geom/gpart.da0 > http://home.jp.freebsd.org/~nyan/geom/gpart.da0s1 I think the problem is with the perceived geometry. If you boot verbose with GEOM_PC98, do you see that the fwsectors/fwheads are being guessed? If not, can you tell me what the fwsectors and fwheads values are? With GEOM_PART_PC98, can you run: gpart list da0 You should get something like: Geom name: da0 fwheads: 16 fwsectors: 63 last: 80293247 first: 63 entries: 4 scheme: MBR Of course scheme should be PC98 in your case. I suspect that the number of heads and/or sectors per track is different. Thanks, -- Marcel Moolenaar xcllnt@mac.com From yanefbsd at gmail.com Mon Jan 5 05:32:51 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Mon Jan 5 05:32:58 2009 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: <7d6fde3d0901042132w4566d619me72bed36f016606b@mail.gmail.com> References: <20081227202117.F3B14341A3@cavin02.kulnet.kuleuven.ac.be> <200812281613.49404.tijl@ulyssis.org> <495B1ABF.4080302@FreeBSD.org> <7d6fde3d0901042132w4566d619me72bed36f016606b@mail.gmail.com> Message-ID: <7d6fde3d0901042132j637f288eo3031e3b1c496a894@mail.gmail.com> On Tue, Dec 30, 2008 at 11:09 PM, Doug Barton wrote: > Li, Qing wrote: >> I don't think we can provide binary compatibility without putting >> back RTF_LLINFO exactly as it was. My preference is to continue down >> the new path without RTF_LLINFO. > > Out of curiosity, what's your reasoning for this decision? If I've > missed this explanation previously, my apologies. > > Doug I think I have a fix (for emulators/wine at least). Let me test it out and then get back to you in a bit... -Garrett From bzeeb-lists at lists.zabbadoz.net Mon Jan 5 09:05:08 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Mon Jan 5 09:05:15 2009 Subject: Can not build r186708 -CURRENT In-Reply-To: References: Message-ID: <20090105090106.O45399@maildrop.int.zabbadoz.net> On Sat, 3 Jan 2009, 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 re-cvsup; While SVN was up-to-date cvs wasn't for other technical reasons. Should work now. -- Bjoern A. Zeeb The greatest risk is not taking one. From danny at cs.huji.ac.il Mon Jan 5 09:16:40 2009 From: danny at cs.huji.ac.il (Danny Braniss) Date: Mon Jan 5 09:16:47 2009 Subject: upcoming elfdump refactoring In-Reply-To: <20090105010105.GA47387@onelab2.iet.unipi.it> References: <20090104234238.GA44381@onelab2.iet.unipi.it> <49615475.2030803@FreeBSD.org> <20090105010105.GA47387@onelab2.iet.unipi.it> Message-ID: > On Sun, Jan 04, 2009 at 04:29:41PM -0800, Maxim Sobolev wrote: > > Luigi Rizzo wrote: > > >I need to extract value and size of some symbols from an ELF file, > > >and make them available to a C program, something like > > > > > > nm -S /boot/kernel/kernel | grep -E "(kernload|kernbase|uscanner_devs)" > > > > > >Rather than using the above tools plus popen() and some parsing code, > > >I have refactored src/usr.bin/elfdump/elfdump.c , > > >making the main routine externally callable, returning the > > >desired info in a struct rather than print them out. > > > > > >I don't know if/how other programs might need to call elfdump(), > > >but given that the changes I made have no functional or performance > > >drawback, I would like to commit them to the tree. > > >Objections ? > > > > > >(note, the diff will be large because in the process I also removed > > >global variables and staticize/constify things) > > > > Why not make this function part of libelf? > > because i was not aware of its existance (also a reason why I posted > the request - i didn't want to reinvent the wheel). > Thanks for the pointer, I will look at libelf and see if it already > contains soemthing that does what i need. > while you are at it, can you check why there is a null when you do: config -x kernel ie: sunfire> config -x /boot/kernel/kernel | grep device Binary file (standard input) matches sunfire> config -x /boot/kernel/kernel | cat -v| tail device cue device kue device rue device firewire device sbp device fwe device fwip device dcons device dcons_crom ^@sunfire> i think the libelf is involved. > cheers > luigi > _______________________________________________ > 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 hselasky at c2i.net Mon Jan 5 09:57:19 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Mon Jan 5 09:57:26 2009 Subject: apcupsd & usb2 In-Reply-To: <58c737d70901041734u590ce80am7e86ad50077fd97@mail.gmail.com> References: <58c737d70901041734u590ce80am7e86ad50077fd97@mail.gmail.com> Message-ID: <200901051059.39566.hselasky@c2i.net> On Monday 05 January 2009, Chris Ruiz wrote: > apcupsd no longer works now that i switched to usb2. the > usb2_input_hid module keeps attaching to it. before, with the old usb > stack, my ups would attach as ugen0, my dmesg shows it attaching as > uhid0 now and apcupsd cannot find it. if i unload the usb2_input_hid > module, my ups disappears. because something is mentioned in the post > install text for apcupsd, i believe that the usb2_hid_module should > not be attaching to the ups. any help would be appreciated. > > [old stack] > ugen0: FW:E6, class 0/0, rev 1.10/1.06, addr 2> on uhub5 > > [usb2] > uhid0: FW:E6, class 0/0, rev 1.10/1.06, addr 2> on usbus5 > Symlink: uhid0 -> usb5.2.0.16 > > [error message] > apcupsd[3643]: apcupsd FATAL ERROR in bsd-usb.c at line 735 Cannot > find UPS device -- For a link to detailed USB trouble shooting > information, please see . > apcupsd[3643]: apcupsd error shutdown completed > > thanks for all your hard work on the new usb stack, Hi Chris, You need to replace libusb0.1.xxx with libusb20 in /usr/local/lib or link apcupsd with libusb20. Then it will work again. --HPS From hopet at ics.muni.cz Mon Jan 5 10:22:03 2009 From: hopet at ics.muni.cz (Petr Holub) Date: Mon Jan 5 10:22:10 2009 Subject: 8.0-SNAPSHOT200812 reversed locks Message-ID: <03a001c96f1b$3fa09b20$bee1d160$@muni.cz> Hi all, after booting a 8.0-SNAPSHOT200812 DVD on my T61p and entering the fixit ``live'' mode, I've encountered the following messages about reversed locks: DEBUG: ioctl(3, TIOCCONS, NULL) = 0 (success) DEBUG: MADT: Found CPU APIC ID 0 enabled DEBUG: MADT: Found CPU APIC ID 1 enabled lock order reversal: 1st 0xc6e43164 isofs (isofs) @ /usr/src/sys/kern/vfs_subr.c:2079 2nd 0xda8e7960 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2443 3rd 0xc6ed0488 isofs (isofs) @ /usr/src/sys/fs/cd9660/cd9660_vfsops.c:676 KDB: stack backtrace: db_trace_self_wrapper(...) at db_trace_self_wrapper+0x26 kdb_backtrace(...) at kdb_backtrace+0x29 _witness_debugger(...) at _witness_debugger+0x25 witness_checkorder(...) at witness_checkorder+0x839 __lockmgr_args(...) at __lockmgr_args+0x797 cd9660_vget_internal(...) at cd9660_vget_internal+0x118 cd9660_lookup(...) at cd9660_lookup+0x73f VOP_CACHEDLOOKUP_APV(...) at VOP_CACHED_LOOKUP+0xa5 vfs_cache_lookup(...) at vfs_cache_lookup+0xcc VOP_LOOKUP_APV(...) at VOP_LOOKUP_APV+0xa5 lookup(...) at lookup+0x0x57e namei(...) at namei+0x04db kern_accessat(...) at kern_accessat+0x94 kern_access(...) at kern_access+0x36 access(...) at access+0x29 syscall(c67d1d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (33, FreeBSD ELF32, access), eip = 0x81d6ed7, esp = 0xbfbfe02c, ebp = 0xbfbfe048 --- DEBUG: CD Volume 1 initialized! lock order reversal: 1st 0xc696ae44 user map (user map) @ /usr/src/sys/vm/vm_map.c:3115 2nd 0xc6ed0270 isofs (isofs) @ /usr/src/sys/kern/vfs_subr.c:2079 KDB: stack backtrace: db_trace_self_wrapper(...) at db_trace_self_wrapper+0x26 kdb_backtrace(...) at kdb_backtrace+0x29 _witness_debugger(...) at _witness_debugger+0x25 witness_checkorder(...) at witness_checkorder+0x839 __lockmgr_args(...) at __lockmgr_args+0x797 vop_stdlock(...) at vop_stdlock+0x62 VOP_LOCK1_APV(...) at VOP_LOCK1_APV+0xa5 _vn_lock(...) at _vn_lock+0x5e vget(...) at vget+0xc9 vnode_pager_lock(...) at vnode_pager_lock+0x1e0 vm_fault(...) at vm_fault+0x1df trap_pfault(...) at trap_pfault+0x118 trap(...) at trap+0x289 calltrap(...) at calltrap+0x6 Because the machine is not enabled for remote debugging, I've hand typed those messages. I function parameters are needed, I can hopefully recover them from screenshots taken by my cell phone :) Petr From Johan at double-l.nl Mon Jan 5 11:26:07 2009 From: Johan at double-l.nl (Johan Hendriks) Date: Mon Jan 5 11:26:15 2009 Subject: build -j3 not working anymore on Current References: <57200BF94E69E54880C9BB1AF714BBCB0111B3@w2003s01.double-l.local> <20090103101606.GA81276@dragon.NUXI.org> Message-ID: <57200BF94E69E54880C9BB1AF714BBCB5DE3C8@w2003s01.double-l.local> >> 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) Well i cvsuped today and still got an error when building with -j3 Regards, Johan Hendriks No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.10.2/1874 - Release Date: 4-1-2009 16:32 From nyan at jp.FreeBSD.org Mon Jan 5 11:59:19 2009 From: nyan at jp.FreeBSD.org (Takahashi Yoshihiro) Date: Mon Jan 5 11:59:26 2009 Subject: gpart In-Reply-To: <8BF346D6-B7EB-4FFC-9216-FEFCABBDADB8@mac.com> References: <354036B7-A4AA-4D66-A2AC-9CB66D292FAA@mac.com> <20081220.154722.162072679.nyan@jp.FreeBSD.org> <8BF346D6-B7EB-4FFC-9216-FEFCABBDADB8@mac.com> Message-ID: <20090105.205912.94971317.nyan@jp.FreeBSD.org> In article <8BF346D6-B7EB-4FFC-9216-FEFCABBDADB8@mac.com> Marcel Moolenaar writes: > I think the problem is with the perceived geometry. > If you boot verbose with GEOM_PC98, do you see that > the fwsectors/fwheads are being guessed? If not, can > you tell me what the fwsectors and fwheads values > are? The value of the fwheads and fwsectors are: g_pc98_taste(PC98,da0): 8 heads / 128 sectors > With GEOM_PART_PC98, can you run: > gpart list da0 The result is: Geom name: da0 fwheads: 255 fwsectors: 63 last: 40017914 first: 16065 entries: 16 scheme: PC98 Providers: 1. Name: da0s1 Mediasize: 321542645760 (299G) Sectorsize: 512 Mode: r0w0e0 rawtype: 17428 attrib: active attrib: bootable label: FreeBSD length: 321542645760 offset: 8225280 type: freebsd index: 1 Consumers: 1. Name: da0 Mediasize: 20496236544 (19G) Sectorsize: 512 Mode: r0w0e0 --- TAKAHASHI Yoshihiro From onemda at gmail.com Mon Jan 5 12:28:13 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Mon Jan 5 12:28:21 2009 Subject: Can not build r186708 -CURRENT In-Reply-To: <20090105090106.O45399@maildrop.int.zabbadoz.net> References: <20090105090106.O45399@maildrop.int.zabbadoz.net> Message-ID: <3a142e750901050428we124de0r38fccd4fd50fb135@mail.gmail.com> On 1/5/09, Bjoern A. Zeeb wrote: > On Sat, 3 Jan 2009, 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 > > re-cvsup; While SVN was up-to-date cvs wasn't for other technical > reasons. Should work now. There is no point to have ndis{api} defined in kernel when usb2 is used instead of usb in same kernel. -- Paul From ohartman at zedat.fu-berlin.de Mon Jan 5 12:29:31 2009 From: ohartman at zedat.fu-berlin.de (O. Hartmann) Date: Mon Jan 5 12:29:44 2009 Subject: FreeBSD 8-Current AMD64: not compiling world, core dump with new kernel Message-ID: <4961F89F.4000004@zedat.fu-berlin.de> Hello. I've trouble compiling world on a FreeBSD 8.0-CUR/amd64 box. uname is as follows: FreeBSD thusnelda.geoinf.fu-berlin.de 8.0-CURRENT FreeBSD 8.0-CURRENT #5 r185330: Wed Nov 26 08:29:58 UTC 2008 I've cvsup'ed the most recent sources, but as the weeks before, compilation of 'world' stops at this point: ===> gnu/usr.bin/texinfo/doc (all) 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 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 ln -fs /usr/src/gnu/usr.bin/texinfo/doc/../../../../contrib/texinfo/doc/texinfo.txi texinfo.texi 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 gzip -cn info.info > info.info.gz gzip -cn info-stnd.info > info-stnd.info.gz gzip -cn texinfo.info > texinfo.info.gz 1 error *** Error code 2 1 error *** Error code 2 1 error Also, the kernel dated as the uname output shows is the only one that boots correctly on this box (DELL Poweredge 1950 with two XEON CPUs, dmesg follows). I can compile a kernel with the most recent sources, but the kernel crashes when booting (this happens also on a dual core Lenovo Thinkpad and affects another SMP box also, but not my private UP box). But this is another issue I will report separately. Can anyone help fixing the problem above? I deleted the stuff remaining in /usr/obj/ and started with a freshly 'svn update', but without success. I guess there is something out of sync, but don't know what. Thanks in advance, Oliver From Johan at double-l.nl Mon Jan 5 12:39:47 2009 From: Johan at double-l.nl (Johan Hendriks) Date: Mon Jan 5 12:39:53 2009 Subject: FreeBSD 8-Current AMD64: not compiling world, core dump with new kernel References: <4961F89F.4000004@zedat.fu-berlin.de> Message-ID: <57200BF94E69E54880C9BB1AF714BBCB5DE3C9@w2003s01.double-l.local> >Hello. >I've trouble compiling world on a FreeBSD 8.0-CUR/amd64 box. uname is as >follows: >FreeBSD thusnelda.geoinf.fu-berlin.de 8.0-CURRENT FreeBSD 8.0-CURRENT #5 >r185330: Wed Nov 26 08:29:58 UTC 2008 >I've cvsup'ed the most recent sources, but as the weeks before, >compilation of 'world' stops at this point: < snip > ........... ........... ........... < /snip > >Also, the kernel dated as the uname output shows is the only one that >boots correctly on this box (DELL Poweredge 1950 with two XEON CPUs, >dmesg follows). I can compile a kernel with the most recent sources, but >the kernel crashes when booting (this happens also on a dual core Lenovo >Thinkpad and affects another SMP box also, but not my private UP box). >But this is another issue I will report separately. >Can anyone help fixing the problem above? I deleted the stuff remaining >in /usr/obj/ and started with a freshly 'svn update', but without >success. I guess there is something out of sync, but don't know what. >Thanks in advance, >Oliver Do you use -jx to do a buildworld ? If so do the buildworld without -jx I have 2 systems running 8.0-CURRENT, and both do not compile with -jx, but do build fine without the -jx option. See also the build with -j3 fails thread. Regards Johan Hendriks No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.176 / Virus Database: 270.10.2/1874 - Release Date: 4-1-2009 16:32 From ohartman at zedat.fu-berlin.de Mon Jan 5 14:53:06 2009 From: ohartman at zedat.fu-berlin.de (O. Hartmann) Date: Mon Jan 5 14:53:12 2009 Subject: FreeBSD 8-Current AMD64: not compiling world, core dump with new kernel In-Reply-To: <57200BF94E69E54880C9BB1AF714BBCB5DE3C9@w2003s01.double-l.local> References: <4961F89F.4000004@zedat.fu-berlin.de> <57200BF94E69E54880C9BB1AF714BBCB5DE3C9@w2003s01.double-l.local> Message-ID: <49621E49.6030708@zedat.fu-berlin.de> Johan Hendriks wrote: >> Hello. > >> I've trouble compiling world on a FreeBSD 8.0-CUR/amd64 box. uname is as >> follows: > >> FreeBSD thusnelda.geoinf.fu-berlin.de 8.0-CURRENT FreeBSD 8.0-CURRENT #5 >> r185330: Wed Nov 26 08:29:58 UTC 2008 > >> I've cvsup'ed the most recent sources, but as the weeks before, >> compilation of 'world' stops at this point: > > < snip > > ........... > ........... > ........... > < /snip > > >> Also, the kernel dated as the uname output shows is the only one that >> boots correctly on this box (DELL Poweredge 1950 with two XEON CPUs, >> dmesg follows). I can compile a kernel with the most recent sources, but >> the kernel crashes when booting (this happens also on a dual core Lenovo >> Thinkpad and affects another SMP box also, but not my private UP box). >> But this is another issue I will report separately. > >> Can anyone help fixing the problem above? I deleted the stuff remaining >> in /usr/obj/ and started with a freshly 'svn update', but without >> success. I guess there is something out of sync, but don't know what. > >> Thanks in advance, >> Oliver > > Do you use -jx to do a buildworld ? > If so do the buildworld without -jx > I have 2 systems running 8.0-CURRENT, and both do not compile with -jx, but do build fine without the -jx option. > See also the build with -j3 fails thread. > > Regards > Johan Hendriks You're right, I used -j8. Without a buildworld performs well. I will see if the core dump problem vanishes when everything is in sync. Thanks Oliver From obrien at freebsd.org Mon Jan 5 15:56:19 2009 From: obrien at freebsd.org (David O'Brien) Date: Mon Jan 5 15:56:25 2009 Subject: build -j3 not working anymore on Current In-Reply-To: <57200BF94E69E54880C9BB1AF714BBCB5DE3C8@w2003s01.double-l.local> References: <57200BF94E69E54880C9BB1AF714BBCB0111B3@w2003s01.double-l.local> <20090103101606.GA81276@dragon.NUXI.org> <57200BF94E69E54880C9BB1AF714BBCB5DE3C8@w2003s01.double-l.local> Message-ID: <20090105155615.GB46222@dragon.NUXI.org> On Mon, Jan 05, 2009 at 12:25:51PM +0100, Johan Hendriks wrote: > >> 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) > > Well i cvsuped today and still got an error when building with -j3 The SVN->CVS exporter was broken (disabled?) over the Holiday, please try again. -- -- David (obrien@FreeBSD.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play "Jeopardy-style quoting" From attilio at freebsd.org Mon Jan 5 16:22:30 2009 From: attilio at freebsd.org (Attilio Rao) Date: Mon Jan 5 16:23:02 2009 Subject: hangup (livelock) - db> prompt in endless loop In-Reply-To: <494B740B.4080602@citrin.ru> References: <4947C526.2080702@citrin.ru> <494B740B.4080602@citrin.ru> Message-ID: <3bbf2fe10901050751y74ccd7e3va68fea0634fbd79f@mail.gmail.com> 2008/12/19 Anton Yuzhaninov : > Anton Yuzhaninov wrote: >> >> My box with fresh current sometimes stops to respond. >> >> On screen in endless loop printed debugger prompt >> >> db> >> >> but I can't type anything here. >> >> Alt+Ctrl+Esc and Alt+Ctrl+Del don't stops this loop. >> >> How I can debug this problem? >> >> system: current from Mon Dec 15 16:16:23 MSK 2008 with GENERIC kernel, >> amd64, SMP. >> > > With more fresh current - Wed Dec 17 21:09:38 > Panic not repeated. This is probabilly a bug in the DDB lookup function. It just stops immediately or after a couple of commands? (and if it does, which comands exactly?) Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From bzeeb-lists at lists.zabbadoz.net Mon Jan 5 17:45:07 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Mon Jan 5 17:45:14 2009 Subject: [cfr] rc.shutdown patch Message-ID: <20090105172736.A45399@maildrop.int.zabbadoz.net> Hi, while starting and stopping jails with rc.d/jail on a system that had no killall in the base (very stripped /usr/**) I found that unmounting devfs for the jail hadn't worked. Digging into this I found that rc.shutdown lets a sleep 30 (rcshutdown_timeout) hanging around for the rest of that time which is unpleasent if it could go away cleanly. I am using pkill, which is in /bin/ as well, to kill the sleep and the subshell instead of only killing the subshell and leaving the sleep hanging re-parented to init. I'd like to commit this but am a bit unsure for adding pkill dependency to such a central rc file; Though, two startup scripts seem to use it already (*ppp*) and dhclient uses 'pgrep' which is the same inode. I have a patch here: http://people.freebsd.org/~bz/20090105-03-rc-shutdown.diff ! ! Instead of killing the 'watchdog' subshell and leaving ! a sleep for the timeout, make sure all goes away cleanly. ! ! This avoids needing killall in rc.d/jail for a clean shutdown ! and generally does not leave dangling processes on shutdown that ! something else has to kill. ! Index: etc/rc.shutdown =================================================================== --- etc/rc.shutdown (revision 186775) +++ etc/rc.shutdown (working copy) @@ -98,7 +98,7 @@ # Terminate the background watchdog timer (if it is running) # if [ -n "$_rcshutdown_watchdog" ]; then - kill -TERM $_rcshutdown_watchdog >/dev/null 2>&1 + pkill -TERM -P $_rcshutdown_watchdog >/dev/null 2>&1 fi # Insert other shutdown procedures here Footnote: for jails we will want to keep the killall for other reasons (as we usually cannot trust the admin inside the jail to get a clean shutdown working). Any comments? /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From stas at FreeBSD.org Mon Jan 5 21:00:17 2009 From: stas at FreeBSD.org (Stanislav Sedov) Date: Mon Jan 5 21:00:23 2009 Subject: apcupsd & usb2 In-Reply-To: <200901051059.39566.hselasky@c2i.net> References: <58c737d70901041734u590ce80am7e86ad50077fd97@mail.gmail.com> <200901051059.39566.hselasky@c2i.net> Message-ID: <20090106000240.d9636f60.stas@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 5 Jan 2009 10:59:38 +0100 Hans Petter Selasky mentioned: > > You need to replace libusb0.1.xxx with libusb20 in /usr/local/lib or link > apcupsd with libusb20. Then it will work again. > Or use libmap.conf(5) which is safer. - -- Stanislav Sedov ST4096-RIPE -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAklidXAACgkQK/VZk+smlYFRpgCfe9cTucBn5HgRr4MT4inSikG7 2MwAn2Uwy7MBQoV76PpWeNX8KlJiJYhP =wAe+ -----END PGP SIGNATURE----- !DSPAM:496274df967002024588998! From yr.retarded at gmail.com Mon Jan 5 21:28:05 2009 From: yr.retarded at gmail.com (Chris Ruiz) Date: Mon Jan 5 21:28:11 2009 Subject: apcupsd & usb2 In-Reply-To: <200901051059.39566.hselasky@c2i.net> References: <58c737d70901041734u590ce80am7e86ad50077fd97@mail.gmail.com> <200901051059.39566.hselasky@c2i.net> Message-ID: <58c737d70901051328t38b99a14g52a0d85bbbc1daa2@mail.gmail.com> On Mon, Jan 5, 2009 at 3:59 AM, Hans Petter Selasky wrote: > On Monday 05 January 2009, Chris Ruiz wrote: >> apcupsd no longer works now that i switched to usb2. the >> usb2_input_hid module keeps attaching to it. before, with the old usb >> stack, my ups would attach as ugen0, my dmesg shows it attaching as >> uhid0 now and apcupsd cannot find it. if i unload the usb2_input_hid >> module, my ups disappears. because something is mentioned in the post >> install text for apcupsd, i believe that the usb2_hid_module should >> not be attaching to the ups. any help would be appreciated. >> >> [old stack] >> ugen0: > FW:E6, class 0/0, rev 1.10/1.06, addr 2> on uhub5 >> >> [usb2] >> uhid0: > FW:E6, class 0/0, rev 1.10/1.06, addr 2> on usbus5 >> Symlink: uhid0 -> usb5.2.0.16 >> >> [error message] >> apcupsd[3643]: apcupsd FATAL ERROR in bsd-usb.c at line 735 Cannot >> find UPS device -- For a link to detailed USB trouble shooting >> information, please see . >> apcupsd[3643]: apcupsd error shutdown completed >> >> thanks for all your hard work on the new usb stack, > > Hi Chris, > > You need to replace libusb0.1.xxx with libusb20 in /usr/local/lib or link > apcupsd with libusb20. Then it will work again. > > --HPS > I dont have a libusb0.1.* anywhere on my system. Here's what apcupsd is linked to: # ldd /usr/local/sbin/apcupsd /usr/local/sbin/apcupsd: libwrap.so.5 => /usr/lib/libwrap.so.5 (0x800660000) libthr.so.3 => /lib/libthr.so.3 (0x800769000) libc.so.7 => /lib/libc.so.7 (0x800880000) Thanks, Chris From hselasky at c2i.net Mon Jan 5 21:48:19 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Mon Jan 5 21:48:26 2009 Subject: apcupsd & usb2 In-Reply-To: <58c737d70901051328t38b99a14g52a0d85bbbc1daa2@mail.gmail.com> References: <58c737d70901041734u590ce80am7e86ad50077fd97@mail.gmail.com> <200901051059.39566.hselasky@c2i.net> <58c737d70901051328t38b99a14g52a0d85bbbc1daa2@mail.gmail.com> Message-ID: <200901052250.36428.hselasky@c2i.net> On Monday 05 January 2009, Chris Ruiz wrote: > On Mon, Jan 5, 2009 at 3:59 AM, Hans Petter Selasky wrote: > > On Monday 05 January 2009, Chris Ruiz wrote: > >> apcupsd no longer works now that i switched to usb2. the > >> usb2_input_hid module keeps attaching to it. before, with the old usb > >> stack, my ups would attach as ugen0, my dmesg shows it attaching as > >> uhid0 now and apcupsd cannot find it. if i unload the usb2_input_hid > >> module, my ups disappears. because something is mentioned in the post > >> install text for apcupsd, i believe that the usb2_hid_module should > >> not be attaching to the ups. any help would be appreciated. > >> > >> [old stack] > >> ugen0: >> FW:E6, class 0/0, rev 1.10/1.06, addr 2> on uhub5 > >> > >> [usb2] > >> uhid0: >> FW:E6, class 0/0, rev 1.10/1.06, addr 2> on usbus5 > >> Symlink: uhid0 -> usb5.2.0.16 > >> > >> [error message] > >> apcupsd[3643]: apcupsd FATAL ERROR in bsd-usb.c at line 735 Cannot > >> find UPS device -- For a link to detailed USB trouble shooting > >> information, please see . > >> apcupsd[3643]: apcupsd error shutdown completed > >> > >> thanks for all your hard work on the new usb stack, > > > > Hi Chris, > > > > You need to replace libusb0.1.xxx with libusb20 in /usr/local/lib or link > > apcupsd with libusb20. Then it will work again. > > > > --HPS > > I dont have a libusb0.1.* anywhere on my system. Here's what apcupsd > is linked to: Ok, Then you have to recompile apcupsd to use the generic USB driver (NOT the bsd.c). Maybe you can figure this out? /usr/ports/sysutils/apcupsd/work/apcupsd-3.14.4/src/drivers/usb/generic Makefile generic-usb.c hidutils.c hidutils.h libusb.h.in After that libusb gets installed you can use libmap.conf to make apcupsd use libusb20 instead of libusb from ports. --HPS From ohartman at mail.zedat.fu-berlin.de Tue Jan 6 00:22:39 2009 From: ohartman at mail.zedat.fu-berlin.de (O. Hartmann) Date: Tue Jan 6 01:30:14 2009 Subject: FreeBSD 8: fails booting from slice ad8s1a Message-ID: <4962A0D3.1010704@mail.zedat.fu-berlin.de> Since January, 3rd my FreeBSD 8/amd64 box won't boot anymore. I have buildworld the most recent sources. Symptomes: after loading and booting kernel, booting suddenly stops and I'm getting prompted for defining the boot slice like ufs:/dev/ad8s1a Typing '?' offers GEOM managed slices/partitions/devices. What changed? Well, I;m confused, because everything worked perfect on January 3rd when I recompiled world, but after then, after svn updating again, booting stops. What informations should I provide? dmesg follows: 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 #29 r186724: Sat Jan 3 17:19:08 CET 2009 root@thor.walstatt.dyndns.org:/usr/obj/usr/src/sys/THOR Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 Processor 3500+ (2376.07-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x10ff0 Stepping = 0 Features=0x78bfbff AMD Features=0xe2500800 AMD Features2=0x1 usable memory = 2136616960 (2037 MB) avail memory = 2065059840 (1969 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard netsmb_dev: loaded kbd1 at kbdmux0 smbios0: at iomem 0xfbdc0-0xfbdde on motherboard smbios0: Version: 2.3, BCD Revision: 2.3 cryptosoft0: on motherboard acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of e0000, 20000 (3) failed acpi0: reservation of 100000, 7ff00000 (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x508-0x50b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 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 pci1: on pcib1 atapci0: port 0xcc00-0xcc7f mem 0xdceffc00-0xdceffc7f,0xdcef8000-0xdcefbfff irq 16 at device 0.0 on pci1 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] pcib2: at device 3.0 on pci0 pci2: on pcib2 mskc0: port 0xd800-0xd8ff mem 0xdcffc000-0xdcffffff irq 17 at device 0.0 on pci2 msk0: on mskc0 msk0: Ethernet address: 00:15:f2:a2:79:aa miibus0: on msk0 e1000phy0: PHY 0 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto mskc0: [FILTER] pcib3: at device 4.0 on pci0 pci3: on pcib3 vgapci0: mem 0xde000000-0xdeffffff,0xc0000000-0xcfffffff,0xdd000000-0xddffffff irq 17 at device 0.0 on pci3 pci0: at device 9.0 (no driver attached) isab0: at device 10.0 on pci0 isa0: on isab0 nfsmb0: port 0xbc00-0xbc1f,0x600-0x63f,0x700-0x73f irq 20 at device 10.1 on pci0 smbus0: on nfsmb0 smb0: on smbus0 nfsmb1: on nfsmb0 smbus1: on nfsmb1 smb1: on smbus1 ohci0: mem 0xdcdfe000-0xdcdfefff irq 21 at device 11.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ehci0: mem 0xdcdffc00-0xdcdffcff irq 22 at device 11.1 on pci0 ehci0: [ITHREAD] usbus1: EHCI version 1.0 usbus1: on ehci0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 15.0 on pci0 ata0: on atapci1 ata0: [ITHREAD] ata1: on atapci1 ata1: [ITHREAD] atapci2: port 0xb480-0xb487,0xb400-0xb403,0xb080-0xb087,0xb000-0xb003,0xac00-0xac0f mem 0xdcdfd000-0xdcdfdfff irq 23 at device 16.0 on pci0 atapci2: [ITHREAD] ata4: on atapci2 ata4: [ITHREAD] ata5: on atapci2 ata5: [ITHREAD] atapci3: port 0xa880-0xa887,0xa800-0xa803,0xa480-0xa487,0xa400-0xa403,0xa080-0xa08f mem 0xdcdfc000-0xdcdfcfff irq 20 at device 17.0 on pci0 atapci3: [ITHREAD] ata6: on atapci3 ata6: [ITHREAD] ata7: on atapci3 ata7: [ITHREAD] pcib4: at device 18.0 on pci0 pci4: on pcib4 pcm0: port 0xec00-0xec1f,0xe880-0xe8ff irq 18 at device 8.0 on pci4 pcm0: [GIANT-LOCKED] pcm0: [ITHREAD] pcm0: system configuration SubVendorID: 0x1412, SubDeviceID: 0x3631 XIN2 Clock Source: 49.152MHz(192kHz*256) MPU-401 UART(s) #: not implemented ADC #: 1 DAC #: 3 Multi-track converter type: I2S(with volume, 192KHz support, 24bit resolution, ID#0x0) S/PDIF(IN/OUT): 0/1 ID# 0x00 GPIO(mask/dir/state): 0x3fff85/0x4000fa/0x72 pci4: at device 11.0 (no driver attached) nfe0: port 0xa000-0xa007 mem 0xdcdfb000-0xdcdfbfff irq 21 at device 19.0 on pci0 miibus1: on nfe0 e1000phy1: PHY 1 on miibus1 e1000phy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto nfe0: Ethernet address: 00:15:f2:a2:85:ba nfe0: [FILTER] pcib5: at device 22.0 on pci0 pci5: on pcib5 pcib6: at device 23.0 on pci0 pci6: on pcib6 k8temp0: on hostb3 acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] cpu0: on acpi0 acpi_throttle0: on cpu0 sc0: at flags 0x100 on isa0 sc0: VGA <8 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0 at vga0 Timecounter "TSC" frequency 2376069974 Hz quality 800 Timecounters tick every 1.333 msec IPsec: Initialized Security Association Processing. usbus0: 12Mbps Full Speed USB v1.0 ugen0.1: at usbus0 ushub0: on usbus0 ushub0: 10 ports with 10 removable, self powered usbus1: 480Mbps High Speed USB v2.0 ugen1.1: at usbus1 ushub1: on usbus1 ushub1: 10 ports with 10 removable, self powered acd0: DVDR at ata0-master UDMA33 ad8: 238475MB at ata4-master SATA300 ad10: 953869MB at ata5-master SATA300 GEOM: ad8s1: geometry does not match label (255h,63s != 16h,63s). ad12: 238475MB at ata6-master SATA300 GEOM: ad8s2: geometry does not match label (255h,63s != 16h,63s). ad14: 152627MB at ata7-master SATA300 ar0: 476950MB Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present ia MediaShield RAID0 (stripe 64 KB)> status: READY ar0: disk0 READY using ad12 at ata6-master ar0: disk1 READY using ad8 at ata4-master hwpmc: TSC/1/64/0x20 K8/4/48/0x1ff GEOM_LABEL: Label for provider ad14s1 is ntfs/THOR. Trying to mount root from ufs:/dev/ad8s1a ugen0.2: at usbus0 ums0: on usbus0 ums0: 8 buttons and [XYZ] coordinates Symlink: ums0 -> usb0.2.0.16 This module (opensolaris) contains code covered by the Common Development and Distribution License (CDDL) see http://opensolaris.org/os/licensing/opensolaris_license/ WARNING: ZFS is considered to be an experimental feature in FreeBSD. ZFS filesystem version 13 ZFS storage pool version 13 pid 1226 (slapd), uid 389: exited on signal 11 nfe0: link state changed to UP From xcllnt at mac.com Tue Jan 6 04:08:36 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Tue Jan 6 04:08:43 2009 Subject: FreeBSD 8: fails booting from slice ad8s1a In-Reply-To: <4962A0D3.1010704@mail.zedat.fu-berlin.de> References: <4962A0D3.1010704@mail.zedat.fu-berlin.de> Message-ID: On Jan 5, 2009, at 4:07 PM, O. Hartmann wrote: > Since January, 3rd my FreeBSD 8/amd64 box won't boot anymore. I have > buildworld the most recent sources. Symptomes: after loading and > booting > kernel, > booting suddenly stops and I'm getting prompted for defining the boot > slice like > > ufs:/dev/ad8s1a > > Typing '?' offers GEOM managed slices/partitions/devices. What > changed? GEOM_PART is default. What are the GEOM managed slices/partitions/devices listed? -- Marcel Moolenaar xcllnt@mac.com From dchagin at freebsd.org Tue Jan 6 13:14:20 2009 From: dchagin at freebsd.org (Chagin Dmitry) Date: Tue Jan 6 13:14:28 2009 Subject: RFC: ELF branding. looking to a ".note.ABI-tag" section Message-ID: <20090106124615.GA2563@dchagin.dialup.corbina.ru> Hi, please, look a patch bellow. kern/118473 related. any comments, help :) Implement new way of branding ELF binaries by looking to a ".note.ABI-tag" section. For what handler .brand_abi_note in Elf_Brandinfo is added. The search order of a brand is changed, now first of all the ".note.ABI-tag" is looked through. Implement .brand_abi_note handler for FreeBSD and Linux binaries. Move code which fetch osreldate for FreeBSD binaries to corresponding handler. Add new branding flag BI_CAN_EXEC_INTERP, which is used if the ABI allows interpreter start (as executable). Implement corresponding handler. diff --git a/sys/amd64/amd64/elf_machdep.c b/sys/amd64/amd64/elf_machdep.c index 4f6d178..0aea61d 100644 --- a/sys/amd64/amd64/elf_machdep.c +++ b/sys/amd64/amd64/elf_machdep.c @@ -84,7 +84,8 @@ static Elf64_Brandinfo freebsd_brand_info = { .interp_path = "/libexec/ld-elf.so.1", .sysvec = &elf64_freebsd_sysvec, .interp_newpath = NULL, - .flags = BI_CAN_EXEC_DYN, + .brand_abi_note = __elfN(freebsd_abi_note), + .flags = BI_CAN_EXEC_DYN }; SYSINIT(elf64, SI_SUB_EXEC, SI_ORDER_ANY, @@ -99,7 +100,8 @@ static Elf64_Brandinfo freebsd_brand_oinfo = { .interp_path = "/usr/libexec/ld-elf.so.1", .sysvec = &elf64_freebsd_sysvec, .interp_newpath = NULL, - .flags = BI_CAN_EXEC_DYN, + .brand_abi_note = __elfN(freebsd_abi_note), + .flags = BI_CAN_EXEC_DYN }; SYSINIT(oelf64, SI_SUB_EXEC, SI_ORDER_ANY, diff --git a/sys/amd64/linux32/linux32_sysvec.c b/sys/amd64/linux32/linux32_sysvec.c index de60744..339bc38 100644 --- a/sys/amd64/linux32/linux32_sysvec.c +++ b/sys/amd64/linux32/linux32_sysvec.c @@ -42,6 +42,7 @@ __FBSDID("$FreeBSD$"); #include #include +#include #include #include #include @@ -93,6 +94,8 @@ MALLOC_DEFINE(M_LINUX, "linux", "Linux mode structures"); suword32(pos++, val); \ } while (0) +#define aligned(a, t) (rounddown((unsigned long)(a), sizeof(t)) == (unsigned long)(a)) + #if BYTE_ORDER == LITTLE_ENDIAN #define SHELLMAGIC 0x2123 /* #! */ #else @@ -999,6 +1002,54 @@ linux32_fixlimit(struct rlimit *rl, int which) } } +static const char GNULINUX_ABI_VENDOR[] = "GNU"; +static const int GNULINUX_ABI_LEN = 16; + +static int +linux32_abi_note(struct image_params *imgp, int32_t *osrel) +{ + const Elf_Note *note, *note_end; + const Elf32_Phdr *phdr, *pnote; + const Elf32_Ehdr *hdr; + const char *note_name; + int i; + + pnote = NULL; + hdr = (const Elf32_Ehdr *)imgp->image_header; + phdr = (const Elf32_Phdr *)(imgp->image_header + hdr->e_phoff); + + for (i = 0; i < hdr->e_phnum; i++) + if (phdr[i].p_type == PT_NOTE) { + pnote = &phdr[i]; + break; + } + + if (pnote == NULL || pnote->p_offset >= PAGE_SIZE || + pnote->p_offset + pnote->p_filesz >= PAGE_SIZE) + return (0); + + note = (const Elf_Note *)(imgp->image_header + pnote->p_offset); + if (!aligned(note, uint32_t)) + return (0); + note_end = (const Elf_Note *)(hdr + pnote->p_offset + + pnote->p_filesz); + while (note < note_end) { + if (note->n_namesz == sizeof(GNULINUX_ABI_VENDOR) && + note->n_descsz == GNULINUX_ABI_LEN && + note->n_type == 1 /* ABI_NOTETYPE */) { + note_name = (const char *)(note + 1); + if (strncmp(GNULINUX_ABI_VENDOR, note_name, + sizeof(GNULINUX_ABI_VENDOR)) == 0) + return(1); + } + note = (const Elf_Note *)((const char *)(note + 1) + + roundup2(note->n_namesz, sizeof(Elf32_Addr)) + + roundup2(note->n_descsz, sizeof(Elf32_Addr))); + } + + return (0); +} + struct sysentvec elf_linux_sysvec = { .sv_size = LINUX_SYS_MAXSYSCALL, .sv_table = linux_sysent, @@ -1038,7 +1089,8 @@ static Elf32_Brandinfo linux_brand = { .interp_path = "/lib/ld-linux.so.1", .sysvec = &elf_linux_sysvec, .interp_newpath = NULL, - .flags = BI_CAN_EXEC_DYN, + .brand_abi_note = linux32_abi_note, + .flags = BI_CAN_EXEC_DYN | BI_CAN_EXEC_INTERP }; static Elf32_Brandinfo linux_glibc2brand = { @@ -1049,7 +1101,8 @@ static Elf32_Brandinfo linux_glibc2brand = { .interp_path = "/lib/ld-linux.so.2", .sysvec = &elf_linux_sysvec, .interp_newpath = NULL, - .flags = BI_CAN_EXEC_DYN, + .brand_abi_note = linux32_abi_note, + .flags = BI_CAN_EXEC_DYN | BI_CAN_EXEC_INTERP }; Elf32_Brandinfo *linux_brandlist[] = { diff --git a/sys/arm/arm/elf_machdep.c b/sys/arm/arm/elf_machdep.c index 693eab1..e65f947 100644 --- a/sys/arm/arm/elf_machdep.c +++ b/sys/arm/arm/elf_machdep.c @@ -84,7 +84,8 @@ static Elf32_Brandinfo freebsd_brand_info = { .interp_path = "/libexec/ld-elf.so.1", .sysvec = &elf32_freebsd_sysvec, .interp_newpath = NULL, - .flags = BI_CAN_EXEC_DYN, + .brand_abi_note = __elfN(freebsd_abi_note), + .flags = BI_CAN_EXEC_DYN }; SYSINIT(elf32, SI_SUB_EXEC, SI_ORDER_ANY, @@ -99,7 +100,8 @@ static Elf32_Brandinfo freebsd_brand_oinfo = { .interp_path = "/usr/libexec/ld-elf.so.1", .sysvec = &elf32_freebsd_sysvec, .interp_newpath = NULL, - .flags = BI_CAN_EXEC_DYN, + .brand_abi_note = __elfN(freebsd_abi_note), + .flags = BI_CAN_EXEC_DYN }; SYSINIT(oelf32, SI_SUB_EXEC, SI_ORDER_ANY, diff --git a/sys/compat/ia32/ia32_sysvec.c b/sys/compat/ia32/ia32_sysvec.c index 0b32b9a..92b990a 100644 --- a/sys/compat/ia32/ia32_sysvec.c +++ b/sys/compat/ia32/ia32_sysvec.c @@ -148,6 +148,7 @@ static Elf32_Brandinfo ia32_brand_info = { .interp_path = "/libexec/ld-elf.so.1", .sysvec = &ia32_freebsd_sysvec, .interp_newpath = "/libexec/ld-elf32.so.1", + .brand_abi_note = __elfN(freebsd_abi_note), .flags = BI_CAN_EXEC_DYN }; @@ -163,7 +164,8 @@ static Elf32_Brandinfo ia32_brand_oinfo = { .interp_path = "/usr/libexec/ld-elf.so.1", .sysvec = &ia32_freebsd_sysvec, .interp_newpath = "/libexec/ld-elf32.so.1", - .flags = BI_CAN_EXEC_DYN, + .brand_abi_note = __elfN(freebsd_abi_note), + .flags = BI_CAN_EXEC_DYN }; SYSINIT(oia32, SI_SUB_EXEC, SI_ORDER_ANY, diff --git a/sys/compat/svr4/svr4_sysvec.c b/sys/compat/svr4/svr4_sysvec.c index 0030e3a..a406576 100644 --- a/sys/compat/svr4/svr4_sysvec.c +++ b/sys/compat/svr4/svr4_sysvec.c @@ -204,6 +204,7 @@ Elf32_Brandinfo svr4_brand = { .interp_path = "/lib/libc.so.1", .sysvec = &svr4_sysvec, .interp_newpath = NULL, + .brand_abi_note = NULL, .flags = 0 }; diff --git a/sys/i386/i386/elf_machdep.c b/sys/i386/i386/elf_machdep.c index 19eddd0..593f9bd 100644 --- a/sys/i386/i386/elf_machdep.c +++ b/sys/i386/i386/elf_machdep.c @@ -84,7 +84,8 @@ static Elf32_Brandinfo freebsd_brand_info = { .interp_path = "/libexec/ld-elf.so.1", .sysvec = &elf32_freebsd_sysvec, .interp_newpath = NULL, - .flags = BI_CAN_EXEC_DYN, + .brand_abi_note = __elfN(freebsd_abi_note), + .flags = BI_CAN_EXEC_DYN }; SYSINIT(elf32, SI_SUB_EXEC, SI_ORDER_ANY, @@ -99,7 +100,8 @@ static Elf32_Brandinfo freebsd_brand_oinfo = { .interp_path = "/usr/libexec/ld-elf.so.1", .sysvec = &elf32_freebsd_sysvec, .interp_newpath = NULL, - .flags = BI_CAN_EXEC_DYN, + .brand_abi_note = __elfN(freebsd_abi_note), + .flags = BI_CAN_EXEC_DYN }; SYSINIT(oelf32, SI_SUB_EXEC, SI_ORDER_ANY, diff --git a/sys/i386/linux/linux_sysvec.c b/sys/i386/linux/linux_sysvec.c index 66cb336..c3f1e84 100644 --- a/sys/i386/linux/linux_sysvec.c +++ b/sys/i386/linux/linux_sysvec.c @@ -91,6 +91,7 @@ MALLOC_DEFINE(M_LINUX, "linux", "Linux mode structures"); #define fldcw(addr) __asm("fldcw %0" : : "m" (*(addr))) #define __LINUX_NPXCW__ 0x37f +#define aligned(a, t) (rounddown((unsigned long)(a), sizeof(t)) == (unsigned long)(a)) extern char linux_sigcode[]; extern int linux_szsigcode; @@ -964,6 +965,53 @@ linux_get_machine(const char **dst) return (0); } +static const char GNULINUX_ABI_VENDOR[] = "GNU"; +static const int GNULINUX_ABI_LEN = 16; + +static int +linux_abi_note(struct image_params *imgp, int32_t *osrel) +{ + const Elf_Note *note, *note_end; + const Elf32_Phdr *phdr, *pnote; + const Elf32_Ehdr *hdr; + const char *note_name; + int i; + + pnote = NULL; + hdr = (const Elf32_Ehdr *)imgp->image_header; + phdr = (const Elf32_Phdr *)(imgp->image_header + hdr->e_phoff); + + for (i = 0; i < hdr->e_phnum; i++) + if (phdr[i].p_type == PT_NOTE) { + pnote = &phdr[i]; + break; + } + if (pnote == NULL || pnote->p_offset >= PAGE_SIZE || + pnote->p_offset + pnote->p_filesz >= PAGE_SIZE) + return (0); + + note = (const Elf_Note *)(imgp->image_header + pnote->p_offset); + if (!aligned(note, uint32_t)) + return (0); + note_end = (const Elf_Note *)(hdr + pnote->p_offset + + pnote->p_filesz); + while (note < note_end) { + if (note->n_namesz == sizeof(GNULINUX_ABI_VENDOR) && + note->n_descsz == GNULINUX_ABI_LEN && + note->n_type == 1 /* ABI_NOTETYPE */) { + note_name = (const char *)(note + 1); + if (strncmp(GNULINUX_ABI_VENDOR, note_name, + sizeof(GNULINUX_ABI_VENDOR)) == 0) + return(1); + } + note = (const Elf_Note *)((const char *)(note + 1) + + roundup2(note->n_namesz, sizeof(Elf32_Addr)) + + roundup2(note->n_descsz, sizeof(Elf32_Addr))); + } + + return (0); +} + struct sysentvec linux_sysvec = { .sv_size = LINUX_SYS_MAXSYSCALL, @@ -1035,7 +1083,8 @@ static Elf32_Brandinfo linux_brand = { .interp_path = "/lib/ld-linux.so.1", .sysvec = &elf_linux_sysvec, .interp_newpath = NULL, - .flags = BI_CAN_EXEC_DYN, + .brand_abi_note = linux_abi_note, + .flags = BI_CAN_EXEC_DYN | BI_CAN_EXEC_INTERP }; static Elf32_Brandinfo linux_glibc2brand = { @@ -1046,7 +1095,8 @@ static Elf32_Brandinfo linux_glibc2brand = { .interp_path = "/lib/ld-linux.so.2", .sysvec = &elf_linux_sysvec, .interp_newpath = NULL, - .flags = BI_CAN_EXEC_DYN, + .brand_abi_note = linux_abi_note, + .flags = BI_CAN_EXEC_DYN | BI_CAN_EXEC_INTERP }; Elf32_Brandinfo *linux_brandlist[] = { diff --git a/sys/ia64/ia64/elf_machdep.c b/sys/ia64/ia64/elf_machdep.c index a3a6e57..a0289de 100644 --- a/sys/ia64/ia64/elf_machdep.c +++ b/sys/ia64/ia64/elf_machdep.c @@ -92,7 +92,8 @@ static Elf64_Brandinfo freebsd_brand_info = { .interp_path = "/libexec/ld-elf.so.1", .sysvec = &elf64_freebsd_sysvec, .interp_newpath = NULL, - .flags = BI_CAN_EXEC_DYN, + .brand_abi_note = __elfN(freebsd_abi_note), + .flags = BI_CAN_EXEC_DYN }; SYSINIT(elf64, SI_SUB_EXEC, SI_ORDER_ANY, (sysinit_cfunc_t)elf64_insert_brand_entry, &freebsd_brand_info); @@ -105,7 +106,8 @@ static Elf64_Brandinfo freebsd_brand_oinfo = { .interp_path = "/usr/libexec/ld-elf.so.1", .sysvec = &elf64_freebsd_sysvec, .interp_newpath = NULL, - .flags = BI_CAN_EXEC_DYN, + .brand_abi_note = __elfN(freebsd_abi_note), + .flags = BI_CAN_EXEC_DYN }; SYSINIT(oelf64, SI_SUB_EXEC, SI_ORDER_ANY, (sysinit_cfunc_t)elf64_insert_brand_entry, &freebsd_brand_oinfo); diff --git a/sys/kern/imgact_elf.c b/sys/kern/imgact_elf.c index 431ee38..c970291 100644 --- a/sys/kern/imgact_elf.c +++ b/sys/kern/imgact_elf.c @@ -78,8 +78,8 @@ __FBSDID("$FreeBSD$"); #define OLD_EI_BRAND 8 static int __elfN(check_header)(const Elf_Ehdr *hdr); -static Elf_Brandinfo *__elfN(get_brandinfo)(const Elf_Ehdr *hdr, - const char *interp); +static Elf_Brandinfo *__elfN(get_brandinfo)(struct image_params *imgp, + const char *interp, int32_t *osrel); static int __elfN(load_file)(struct proc *p, const char *file, u_long *addr, u_long *entry, size_t pagesize); static int __elfN(load_section)(struct vmspace *vmspace, vm_object_t object, @@ -158,19 +158,31 @@ __elfN(brand_inuse)(Elf_Brandinfo *entry) } static Elf_Brandinfo * -__elfN(get_brandinfo)(const Elf_Ehdr *hdr, const char *interp) +__elfN(get_brandinfo)(struct image_params *imgp, const char *interp, + int32_t *osrel) { + const Elf_Ehdr *hdr = (const Elf_Ehdr *)imgp->image_header; Elf_Brandinfo *bi; + int ret, fname_len, interp_len; int i; /* - * We support three types of branding -- (1) the ELF EI_OSABI field + * We support four types of branding -- (1) the ELF EI_OSABI field * that SCO added to the ELF spec, (2) FreeBSD 3.x's traditional string - * branding w/in the ELF header, and (3) path of the `interp_path' - * field. We should also look for an ".note.ABI-tag" ELF section now - * in all Linux ELF binaries, FreeBSD 4.1+, and some NetBSD ones. + * branding w/in the ELF header, (3) path of the `interp_path' + * field, and (4) the ".note.ABI-tag" ELF section. */ + /* Look for an ".note.ABI-tag" ELF section */ + for (i = 0; i < MAX_BRANDS; i++) { + bi = elf_brand_list[i]; + if (bi != NULL && hdr->e_machine == bi->machine && bi->brand_abi_note) { + ret = (*bi->brand_abi_note)(imgp, osrel); + if (ret) + return (bi); + } + } + /* If the executable has a brand, search for it in the brand list. */ for (i = 0; i < MAX_BRANDS; i++) { bi = elf_brand_list[i]; @@ -191,6 +203,23 @@ __elfN(get_brandinfo)(const Elf_Ehdr *hdr, const char *interp) } } + /* Some ABI (Linux) allow to run the interpreter. */ + for (i = 0; i < MAX_BRANDS; i++) { + bi = elf_brand_list[i]; + if (bi == NULL || hdr->e_machine != bi->machine || + (bi->flags & BI_CAN_EXEC_INTERP) == 0) + continue; + + fname_len = strlen(imgp->args->fname); + interp_len = strlen(bi->interp_path); + if (fname_len < interp_len) + continue; + ret = strncmp(imgp->args->fname + (fname_len - interp_len), + bi->interp_path, interp_len); + if (ret == 0) + return (bi); + } + /* Lacking a recognized interpreter, try the default brand */ for (i = 0; i < MAX_BRANDS; i++) { bi = elf_brand_list[i]; @@ -590,13 +619,11 @@ fail: return (error); } -static const char FREEBSD_ABI_VENDOR[] = "FreeBSD"; - static int __CONCAT(exec_, __elfN(imgact))(struct image_params *imgp) { const Elf_Ehdr *hdr = (const Elf_Ehdr *)imgp->image_header; - const Elf_Phdr *phdr, *pnote = NULL; + const Elf_Phdr *phdr; Elf_Auxargs *elf_auxargs; struct vmspace *vmspace; vm_prot_t prot; @@ -604,12 +631,11 @@ __CONCAT(exec_, __elfN(imgact))(struct image_params *imgp) u_long text_addr = 0, data_addr = 0; u_long seg_size, seg_addr; u_long addr, entry = 0, proghdr = 0; + int32_t osrel = 0; int error = 0, i; const char *interp = NULL, *newinterp = NULL; Elf_Brandinfo *brand_info; - const Elf_Note *note, *note_end; char *path; - const char *note_name; struct sysentvec *sv; /* @@ -646,7 +672,7 @@ __CONCAT(exec_, __elfN(imgact))(struct image_params *imgp) } } - brand_info = __elfN(get_brandinfo)(hdr, interp); + brand_info = __elfN(get_brandinfo)(imgp, interp, &osrel); if (brand_info == NULL) { uprintf("ELF binary type \"%u\" not known.\n", hdr->e_ident[EI_OSABI]); @@ -750,9 +776,6 @@ __CONCAT(exec_, __elfN(imgact))(struct image_params *imgp) case PT_PHDR: /* Program header table info */ proghdr = phdr[i].p_vaddr; break; - case PT_NOTE: - pnote = &phdr[i]; - break; default: break; } @@ -839,41 +862,7 @@ __CONCAT(exec_, __elfN(imgact))(struct image_params *imgp) imgp->auxargs = elf_auxargs; imgp->interpreted = 0; - - /* - * Try to fetch the osreldate for FreeBSD binary from the ELF - * OSABI-note. Only the first page of the image is searched, - * the same as for headers. - */ - if (pnote != NULL && pnote->p_offset < PAGE_SIZE && - pnote->p_offset + pnote->p_filesz < PAGE_SIZE ) { - note = (const Elf_Note *)(imgp->image_header + pnote->p_offset); - if (!aligned(note, Elf32_Addr)) { - free(imgp->auxargs, M_TEMP); - imgp->auxargs = NULL; - return (ENOEXEC); - } - note_end = (const Elf_Note *)(imgp->image_header + pnote->p_offset + - pnote->p_filesz); - while (note < note_end) { - if (note->n_namesz == sizeof(FREEBSD_ABI_VENDOR) && - note->n_descsz == sizeof(int32_t) && - note->n_type == 1 /* ABI_NOTETYPE */) { - note_name = (const char *)(note + 1); - if (strncmp(FREEBSD_ABI_VENDOR, note_name, - sizeof(FREEBSD_ABI_VENDOR)) == 0) { - imgp->proc->p_osrel = *(const int32_t *) - (note_name + - round_page_ps(sizeof(FREEBSD_ABI_VENDOR), - sizeof(Elf32_Addr))); - break; - } - } - note = (const Elf_Note *)((const char *)(note + 1) + - round_page_ps(note->n_namesz, sizeof(Elf32_Addr)) + - round_page_ps(note->n_descsz, sizeof(Elf32_Addr))); - } - } + imgp->proc->p_osrel = osrel; return (error); } @@ -1334,6 +1323,63 @@ __elfN(putnote)(void *dst, size_t *off, const char *name, int type, *off += roundup2(note.n_descsz, sizeof(Elf_Size)); } +static const char FREEBSD_ABI_VENDOR[] = "FreeBSD"; + +int +__elfN(freebsd_abi_note)(struct image_params *imgp, int32_t *osrel) +{ + const Elf_Note *note, *note_end; + const Elf32_Phdr *phdr, *pnote; + const Elf32_Ehdr *hdr; + const char *note_name; + int i; + + pnote = NULL; + hdr = (const Elf32_Ehdr *)imgp->image_header; + phdr = (const Elf32_Phdr *)(imgp->image_header + hdr->e_phoff); + + for (i = 0; i < hdr->e_phnum; i++) + if (phdr[i].p_type == PT_NOTE) { + pnote = &phdr[i]; + break; + } + + if (pnote == NULL || pnote->p_offset >= PAGE_SIZE || + pnote->p_offset + pnote->p_filesz >= PAGE_SIZE) + return (0); + + note = (const Elf_Note *)(imgp->image_header + pnote->p_offset); + if (!aligned(note, uint32_t)) + return (0); + note_end = (const Elf_Note *)(hdr + pnote->p_offset + + pnote->p_filesz); + while (note < note_end) { + if (note->n_namesz == sizeof(FREEBSD_ABI_VENDOR) && + note->n_descsz == sizeof(int32_t) && + note->n_type == 1 /* ABI_NOTETYPE */) { + note_name = (const char *)(note + 1); + if (strncmp(FREEBSD_ABI_VENDOR, note_name, + sizeof(FREEBSD_ABI_VENDOR)) != 0) + continue; + /* + * Fetch the osreldate for FreeBSD binary + * from the ELF OSABI-note. + */ + if (osrel != NULL) + *osrel = *(const int32_t *) + (note_name + + round_page_ps(sizeof(FREEBSD_ABI_VENDOR), + sizeof(Elf32_Addr))); + return(1); + } + note = (const Elf_Note *)((const char *)(note + 1) + + round_page_ps(note->n_namesz, sizeof(Elf32_Addr)) + + round_page_ps(note->n_descsz, sizeof(Elf32_Addr))); + } + + return (0); +} + /* * Tell kern_execve.c about it, with a little help from the linker. */ diff --git a/sys/mips/mips/elf_machdep.c b/sys/mips/mips/elf_machdep.c index 163d0ee..807ae67 100644 --- a/sys/mips/mips/elf_machdep.c +++ b/sys/mips/mips/elf_machdep.c @@ -86,6 +86,8 @@ static Elf32_Brandinfo freebsd_brand_info = { .interp_path = "/libexec/ld-elf.so.1", .sysvec = &elf32_freebsd_sysvec, .interp_newpath = NULL, + .brand_abi_note = NULL, + .brand_abi_note = NULL, .flags = 0 }; diff --git a/sys/powerpc/powerpc/elf_machdep.c b/sys/powerpc/powerpc/elf_machdep.c index 69ac55b..f0dc474 100644 --- a/sys/powerpc/powerpc/elf_machdep.c +++ b/sys/powerpc/powerpc/elf_machdep.c @@ -87,7 +87,8 @@ static Elf32_Brandinfo freebsd_brand_info = { .interp_path = "/libexec/ld-elf.so.1", .sysvec = &elf32_freebsd_sysvec, .interp_newpath = NULL, - .flags = BI_CAN_EXEC_DYN, + .brand_abi_note = __elfN(freebsd_abi_note), + .flags = BI_CAN_EXEC_DYN }; SYSINIT(elf32, SI_SUB_EXEC, SI_ORDER_ANY, @@ -102,7 +103,8 @@ static Elf32_Brandinfo freebsd_brand_oinfo = { .interp_path = "/usr/libexec/ld-elf.so.1", .sysvec = &elf32_freebsd_sysvec, .interp_newpath = NULL, - .flags = BI_CAN_EXEC_DYN, + .brand_abi_note = __elfN(freebsd_abi_note), + .flags = BI_CAN_EXEC_DYN }; SYSINIT(oelf32, SI_SUB_EXEC, SI_ORDER_ANY, diff --git a/sys/sparc64/sparc64/elf_machdep.c b/sys/sparc64/sparc64/elf_machdep.c index a956c5c..03b9056 100644 --- a/sys/sparc64/sparc64/elf_machdep.c +++ b/sys/sparc64/sparc64/elf_machdep.c @@ -99,7 +99,8 @@ static Elf64_Brandinfo freebsd_brand_info = { .interp_path = "/libexec/ld-elf.so.1", .sysvec = &elf64_freebsd_sysvec, .interp_newpath = NULL, - .flags = BI_CAN_EXEC_DYN, + .brand_abi_note = __elfN(freebsd_abi_note), + .flags = BI_CAN_EXEC_DYN }; SYSINIT(elf64, SI_SUB_EXEC, SI_ORDER_ANY, @@ -114,7 +115,8 @@ static Elf64_Brandinfo freebsd_brand_oinfo = { .interp_path = "/usr/libexec/ld-elf.so.1", .sysvec = &elf64_freebsd_sysvec, .interp_newpath = NULL, - .flags = BI_CAN_EXEC_DYN, + .brand_abi_note = __elfN(freebsd_abi_note), + .flags = BI_CAN_EXEC_DYN }; SYSINIT(oelf64, SI_SUB_EXEC, SI_ORDER_ANY, diff --git a/sys/sys/imgact_elf.h b/sys/sys/imgact_elf.h index deb5b10..d290185 100644 --- a/sys/sys/imgact_elf.h +++ b/sys/sys/imgact_elf.h @@ -62,8 +62,10 @@ typedef struct { const char *interp_path; struct sysentvec *sysvec; const char *interp_newpath; + int (*brand_abi_note)(struct image_params *, int32_t *); int flags; -#define BI_CAN_EXEC_DYN 0x0001 +#define BI_CAN_EXEC_DYN 0x0001 +#define BI_CAN_EXEC_INTERP 0x0002 } __ElfN(Brandinfo); __ElfType(Auxargs); @@ -76,6 +78,7 @@ int __elfN(insert_brand_entry)(Elf_Brandinfo *entry); int __elfN(remove_brand_entry)(Elf_Brandinfo *entry); int __elfN(freebsd_fixup)(register_t **, struct image_params *); int __elfN(coredump)(struct thread *, struct vnode *, off_t); +int __elfN(freebsd_abi_note)(struct image_params *, int32_t *); /* Machine specific function to dump per-thread information. */ void __elfN(dump_thread)(struct thread *, void *, size_t *); -- Have fun! chd From atkin901 at yahoo.com Tue Jan 6 15:20:32 2009 From: atkin901 at yahoo.com (Mark Atkinson) Date: Tue Jan 6 15:20:41 2009 Subject: FreeBSD 8: fails booting from slice ad8s1a References: <4962A0D3.1010704@mail.zedat.fu-berlin.de> Message-ID: Marcel Moolenaar wrote: > On Jan 5, 2009, at 4:07 PM, O. Hartmann wrote: > >> Since January, 3rd my FreeBSD 8/amd64 box won't boot anymore. I have >> buildworld the most recent sources. Symptomes: after loading and >> booting >> kernel, >> booting suddenly stops and I'm getting prompted for defining the boot >> slice like >> >> ufs:/dev/ad8s1a >> >> Typing '?' offers GEOM managed slices/partitions/devices. What >> changed? > > GEOM_PART is default. > > What are the GEOM managed slices/partitions/devices listed? > I am having the same problem updating yesterday to Jan 5th -current sources from a Nov 25 kernel. The old kernel boots and mounts find, the Jan 5th kernel does not. The way mountroot fails hints that it's just probably looking in the wrong place. lsdev from the bootloader finds the filesystem and I can boot /boot/kernel.old/kernel from here. But the mountroot fallback cannot find the slice. OK lsdev cd devices: disk devices: disk0: BIOS drive C: disk0s1a: FFS disk0s1b: swap pxe devices: Full verbose boot, mountroot failure and slice/label info below: OK boot -v -s GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base=0000000000000000 len=000000000009f800 SMAP type=02 base=000000000009f800 len=0000000000000800 SMAP type=02 base=00000000000dc000 len=0000000000024000 SMAP type=01 base=0000000000100000 len=000000003fd90000 SMAP type=03 base=000000003fe90000 len=000000000000d000 SMAP type=04 base=000000003fe9d000 len=0000000000063000 SMAP type=02 base=000000003ff00000 len=0000000000100000 SMAP type=02 base=00000000fec00000 len=0000000000010000 SMAP type=02 base=00000000fee00000 len=0000000000001000 SMAP type=02 base=00000000ff000000 len=0000000001000000 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 #27: Mon Jan 5 14:48:48 PST 2009 root@pogo-1.f5test.net:/usr/obj/usr/src/sys/POGO WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xc1045000. Preloaded acpi_dsdt "/boot/DSDT.aml" at 0xc10451ac. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 3192016720 Hz CPU: Intel(R) Pentium(R) D CPU 3.20GHz (3192.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf44 Stepping = 4 Features=0xbfebfbff Features2=0x649d AMD Features=0x20100000 TSC: P-state invariant Cores per package: 2 Instruction TLB: 4 KB, 2 MB or 4 MB pages, fully associative, 128 entries Data TLB: 4 KB or 4 MB pages, fully associative, 64 entries 1st-level data cache: 16 KB, 8-way set associative, sectored cache, 64 byte line size Trace cache: 12K-uops, 8-way set associative 2nd-level cache: 1 MB, 8-way set associative, sectored cache, 64 byte line size L2 cache: 1024 kbytes, 8-way associative, 64 bytes/line real memory = 1072234496 (1022 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000001425000 - 0x000000003ed4afff, 1033003008 bytes (252198 pages) avail memory = 1031671808 (983 MB) Table 'FACP' at 0x3fe9cda9 Table 'ASF!' at 0x3fe9ce1d Table 'SPCR' at 0x3fe9cee4 Table 'MCFG' at 0x3fe9cf34 Table 'APIC' at 0x3fe9cf70 MADT: Found table at 0x3fe9cf70 MP Configuration Table version 1.4 found at 0xc009fda1 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 1: enabled SMP: Added CPU 1 (AP) 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 bios32: Found BIOS32 Service Directory header at 0xc00f6080 bios32: Entry = 0xfd450 (c00fd450) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd450+0x1e3 pnpbios: Found PnP BIOS data at 0xc00f6110 pnpbios: Entry = f0000:a9fd Rev = 1.0 Other BIOS signatures found: ULE: setup cpu 0 ULE: setup cpu 1 ACPI: RSDP @ 0x0xf60d0/0x0014 (v 0 PTLTD ) ACPI: RSDT @ 0x0x3fe97360/0x0040 (v 1 PTLTD RSDT 0x06040000 LTP 0x00000000) ACPI: FACP @ 0x0x3fe9cda9/0x0074 (v 1 INTEL 0x06040000 PTL 0x00000003) ACPI: DSDT @ 0x0x3fe9775a/0x564F (v 1 INTEL GLENWOOD 0x06040000 MSFT 0x0100000E) ACPI: FACS @ 0x0x3fe9dfc0/0x0040 ACPI: ASF! @ 0x0x3fe9ce1d/0x00C7 (v 32 ISM CETP 0x06040000 PTL 0x00000001) ACPI: SPCR @ 0x0x3fe9cee4/0x0050 (v 1 PTLTD $UCRTBL$ 0x06040000 PTL 0x00000001) ACPI: MCFG @ 0x0x3fe9cf34/0x003C (v 1 PTLTD MCFG 0x06040000 LTP 0x00000000) ACPI: APIC @ 0x0x3fe9cf70/0x0068 (v 1 PTLTD APIC 0x06040000 LTP 0x00000000) ACPI: BOOT @ 0x0x3fe9cfd8/0x0028 (v 1 PTLTD $SBFTBL$ 0x06040000 LTP 0x00000001) ACPI: SSDT @ 0x0x3fe973a0/0x03BA (v 1 PmRef CpuPm 0x00003000 INTL 0x20030224) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00000200 err: 0x00010000 pcm: 0x00000400 ath_rate: version 1.9 wlan: <802.11 Link Layer> null: random: nfslock: pseudo-device io: kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 (Jan 5 2009 14:46:50) npx0: INT 16 interface acpi0: on motherboard ACPI: Table DSDT replaced by host OS ACPI: DSDT @ 0x0/0x5634 (v 1 INTEL GLENWOOD 0x06040000 INTL 0x20051021) PCIe: Memory Mapped configuration base @ 0xe0000000 pcibios: BIOS version 2.10 ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: wakeup code va 0xc41b0000 pa 0x1000 AcpiOsDerivePciId: \_SB_.PCI0.REGS -> bus 0 dev 0 func 0 AcpiOsDerivePciId: \_SB_.PCI0.LPC0.MMTO -> bus 0 dev 31 func 0 AcpiOsDerivePciId: \_SB_.PCI0.LPC0.REGS -> bus 0 dev 31 func 0 AcpiOsDerivePciId: \_SB_.PCI0.LPC0.PIRX -> bus 0 dev 31 func 0 AcpiOsDerivePciId: \_SB_.PCI0.LPC0.PIRY -> bus 0 dev 31 func 0 ACPI timer: 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 -> 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 7 N 0 3 10 11 14 15 Validation 0 255 N 0 3 10 11 14 15 After Disable 0 255 N 0 3 10 11 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 12 N 0 3 10 11 14 15 Validation 0 255 N 0 3 10 11 14 15 After Disable 0 255 N 0 3 10 11 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 10 11 14 15 Validation 0 11 N 0 3 10 11 14 15 After Disable 0 255 N 0 3 10 11 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 10 11 14 15 Validation 0 10 N 0 3 10 11 14 15 After Disable 0 255 N 0 3 10 11 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 10 11 14 15 Validation 0 255 N 0 3 10 11 14 15 After Disable 0 255 N 0 3 10 11 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 10 11 14 15 Validation 0 255 N 0 3 10 11 14 15 After Disable 0 255 N 0 3 10 11 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 10 11 14 15 Validation 0 255 N 0 3 10 11 14 15 After Disable 0 255 N 0 3 10 11 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 10 11 14 15 Validation 0 255 N 0 3 10 11 14 15 After Disable 0 255 N 0 3 10 11 14 15 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x2778, revid=0x81 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2779, revid=0x81 domain=0, bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0100, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=7 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.1.INTA pcib0: slot 1 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27d0, revid=0x01 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=12 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 17 found-> vendor=0x8086, dev=0x27e0, revid=0x01 domain=0, bus=0, slot=28, func=4 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=a, irq=12 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 17 found-> vendor=0x8086, dev=0x27e2, revid=0x01 domain=0, bus=0, slot=28, func=5 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTB pcib0: slot 28 INTB hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27c8, revid=0x01 domain=0, bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 map[20]: type I/O Port, range 32, base 0x3000, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x27c9, revid=0x01 domain=0, bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[20]: type I/O Port, range 32, base 0x3020, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x27ca, revid=0x01 domain=0, bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 map[20]: type I/O Port, range 32, base 0x3040, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x27cb, revid=0x01 domain=0, bus=0, slot=29, func=3 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=7 map[20]: type I/O Port, range 32, base 0x3060, size 5, enabled pcib0: matched entry for 0.29.INTD pcib0: slot 29 INTD hardwired to IRQ 16 found-> vendor=0x8086, dev=0x27cc, revid=0x01 domain=0, bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xd8500000, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 found-> vendor=0x8086, dev=0x244e, revid=0xe1 domain=0, bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x0c (3000 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27b8, revid=0x01 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x27df, revid=0x01 domain=0, bus=0, slot=31, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 map[20]: type I/O Port, range 32, base 0x30a0, size 4, enabled found-> vendor=0x8086, dev=0x27c0, revid=0x01 domain=0, bus=0, slot=31, func=2 class=01-01-8f, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0x30e8, size 3, enabled map[14]: type I/O Port, range 32, base 0x30dc, size 2, enabled map[18]: type I/O Port, range 32, base 0x30e0, size 3, enabled map[1c]: type I/O Port, range 32, base 0x30d8, size 2, enabled map[20]: type I/O Port, range 32, base 0x30b0, size 4, enabled map[24]: type Memory, range 32, base 0xd8500400, size 10, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x27da, revid=0x01 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0101, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[20]: type I/O Port, range 32, base 0x1100, size 5, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 19 pcib1: irq 16 at device 1.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x0-0x0 pcib1: no prefetched decode pci1: on pcib1 pci1: domain=0, physical bus=1 pcib2: irq 17 at device 28.0 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0x0-0x0 pcib2: no prefetched decode pci2: on pcib2 pci2: domain=0, physical bus=2 pcib3: irq 17 at device 28.4 on pci0 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0x4000-0x4fff pcib3: memory decode 0xd8000000-0xd80fffff pcib3: no prefetched decode pci3: on pcib3 pci3: domain=0, physical bus=3 found-> vendor=0x8086, dev=0x108b, revid=0x03 domain=0, bus=3, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=7 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xd8000000, size 17, enabled pcib3: requested memory range 0xd8000000-0xd801ffff: good map[18]: type I/O Port, range 32, base 0x4000, size 5, enabled pcib3: requested I/O range 0x4000-0x401f: in range pcib3: matched entry for 3.0.INTA pcib3: slot 0 INTA hardwired to IRQ 16 em0: port 0x4000-0x401f mem 0xd8000000-0xd801ffff irq 16 at device 0.0 on pci3 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xd8000000 em0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to vector 49 em0: using IRQ 256 for MSI em0: Using MSI interrupt em0: [FILTER] em0: bpf attached em0: Ethernet address: 00:13:d3:fe:04:f2 pcib4: irq 16 at device 28.5 on pci0 pcib4: domain 0 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: I/O decode 0x5000-0x5fff pcib4: memory decode 0xd8100000-0xd81fffff pcib4: no prefetched decode pci4: on pcib4 pci4: domain=0, physical bus=4 found-> vendor=0x8086, dev=0x108b, revid=0x00 domain=0, bus=4, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=7 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xd8100000, size 17, enabled pcib4: requested memory range 0xd8100000-0xd811ffff: good map[18]: type I/O Port, range 32, base 0x5000, size 5, enabled pcib4: requested I/O range 0x5000-0x501f: in range pcib4: matched entry for 4.0.INTA pcib4: slot 0 INTA hardwired to IRQ 17 em1: port 0x5000-0x501f mem 0xd8100000-0xd811ffff irq 17 at device 0.0 on pci4 em1: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xd8100000 em1: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 257 to vector 50 em1: using IRQ 257 for MSI em1: Using MSI interrupt em1: [FILTER] em1: bpf attached em1: Ethernet address: 00:13:d3:fe:04:f3 uhci0: port 0x3000-0x301f irq 23 at device 29.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x3000 ioapic0: routing intpin 23 (PCI IRQ 23) to vector 51 uhci0: [GIANT-LOCKED] uhci0: [ITHREAD] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x3020-0x303f irq 19 at device 29.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0x3020 ioapic0: routing intpin 19 (PCI IRQ 19) to vector 52 uhci1: [GIANT-LOCKED] uhci1: [ITHREAD] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x3040-0x305f irq 18 at device 29.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0x3040 ioapic0: routing intpin 18 (PCI IRQ 18) to vector 53 uhci2: [GIANT-LOCKED] uhci2: [ITHREAD] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x3060-0x307f irq 16 at device 29.3 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0x3060 ioapic0: routing intpin 16 (PCI IRQ 16) to vector 54 uhci3: [GIANT-LOCKED] uhci3: [ITHREAD] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xd8500000-0xd85003ff irq 23 at device 29.7 on pci0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xd8500000 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered pcib5: at device 30.0 on pci0 pcib5: domain 0 pcib5: secondary bus 10 pcib5: subordinate bus 10 pcib5: I/O decode 0x6000-0x6fff pcib5: memory decode 0xd8200000-0xd82fffff pcib5: prefetched decode 0xd0000000-0xd7ffffff pcib5: Subtractively decoded bridge. pci10: on pcib5 pci10: domain=0, physical bus=10 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x30a0-0x30af at device 31.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x30a0 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=51 ostat1=00 ata0: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=00 stat1=00 devices=0x10000 ioapic0: routing intpin 14 (ISA IRQ 14) to vector 55 ata0: [MPSAFE] ata0: [ITHREAD] atapci1: port 0x30e8-0x30ef,0x30dc-0x30df,0x30e0-0x30e7,0x30d8-0x30db,0x30b0-0x30bf mem 0xd8500400-0xd85007ff irq 19 at device 31.2 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0x30b0 atapci1: [MPSAFE] atapci1: [ITHREAD] pci0: child atapci1 requested type 4 for rid 0x24, but the BAR says it is an memio ata2: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x30e8 atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0x30dc ata2: reset tp1 mask=03 ostat0=7f ostat1=7f ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat1=0x7f err=0xff lsb=0xff msb=0xff ata2: reset tp2 stat0=ff stat1=ff devices=0x0 ata2: [MPSAFE] ata2: [ITHREAD] ata3: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0x30e0 atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0x30d8 ata3: reset tp1 mask=03 ostat0=50 ostat1=00 ata3: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata3: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata3: reset tp2 stat0=50 stat1=00 devices=0x1 ata3: [MPSAFE] ata3: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us) uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 ioapic0: routing intpin 4 (ISA IRQ 4) to vector 56 uart0: [FILTER] uart0: fast interrupt uart0: console (115200,n,8,1) uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 ioapic0: routing intpin 3 (ISA IRQ 3) to vector 57 uart1: [FILTER] uart1: fast interrupt psmcpnp0: irq 12 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 kbd0: atkbd0, generic (0), config:0x0, flags:0x3f0000 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 58 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: current command byte:0067 kbdc: TEST_AUX_PORT status:0000 kbdc: RESET_AUX return code:00fe kbdc: RESET_AUX return code:00fe kbdc: RESET_AUX return code:00fe kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 psm0: failed to reset the aux device. cpu0: on acpi0 cpu0: switching to generic Cx mode est0: enabling SpeedStep est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 102d00000e23 device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 102d00000e23 device_attach: est1 attach returned 6 p4tcc1: on cpu1 unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete ex_isa_identify() isa_probe_children: disabling PnP devices pmtimer0 on isa0 ata: ata0 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it sc: sc0 already exists; skipping it uart: uart0 already exists; skipping it uart: uart1 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcafff,0xdc000-0xdffff,0xe0000-0xe17ff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) ata1 failed to probe at port 0x170 irq 15 on isa0 bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) le0: not probed (disabled) ppc0: parallel port not found. ppc0: failed to probe at irq 7 on isa0 sn0: not probed (disabled) uart2: not probed (disabled) uart3: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. procfs registered lapic: Divisor 2, Frequency 99750516 hz Timecounter "TSC" frequency 3192016720 Hz quality -100 Timecounters tick every 1.000 msec vlan: initialized, using hash tables with chaining lo0: bpf attached hptrr: no controller detected. ata0: identify ch->devices=00010000 ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire acd0: setting PIO4 on ICH7 chip acd0: setting UDMA33 on ICH7 chip acd0: CDRW drive at ata0 as master acd0: 2048KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet acd0: Writes: CDR, CDRW, test write, burnproof acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc ata2: identify ch->devices=00000000 ata3: identify ch->devices=00000001 ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad6: 76319MB at ata3-master SATA150 ad6: 156301488 sectors [155061C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad6 ad6: Intel check1 failed ad6: Adaptec check1 failed ad6: LSI (v3) check1 failed ad6: LSI (v2) check1 failed ad6: FreeBSD check1 failed ATA PseudoRAID loaded SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00050014 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 3 to local APIC 1 ioapic0: Assigning ISA IRQ 4 to local APIC 0 ioapic0: Assigning ISA IRQ 9 to local APIC 1 ioapic0: Assigning ISA IRQ 14 to local APIC 0 ioapic0: Assigning PCI IRQ 16 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 23 to local APIC 0 msi: Assigning MSI IRQ 256 to local APIC 1 msi: Assigning MSI IRQ 257 to local APIC 0 WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/ad6s1a Manual root filesystem specification: : Mount using filesystem eg. ufs:da0s1a ? List valid disk boot devices Abort manual input mountroot> ? List of GEOM managed disk devices: ad6b ad6a ad6 acd0 Manual root filesystem specification: : Mount using filesystem eg. ufs:da0s1a ? List valid disk boot devices Abort manual input mountroot> ufs:ad6a Trying to mount root from ufs:ad6a WARNING: / was not properly dismounted /: mount pending error: blocks 8 files 1 Lookup of /dev for devfs, error: 20 exec /sbin/init: error 20 exec /sbin/oinit: error 20 exec /sbin/init.bak: error 20 exec /rescue/init: error 20 exec /stand/sysinstall: error 20 init: not found in path /sbin/init:/sbin/oinit:/sbin/init.bak:/rescue/init:/stand/sysinstall panic: no init cpuid = 1 KDB: enter: panic [thread pid 1 tid 100002 ] Stopped at kdb_enter+0x3a: movl $0,kdb_why db> If I boot back to the old kernel, here's what the slice layout looks like: # fdisk -v /dev/ad6 ******* Working on device /dev/ad6 ******* parameters extracted from in-core disklabel are: cylinders=155061 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=155061 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 156296322 (76316 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 1023/ head 254/ sector 63 The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: and what bsdlabel thinks: # bsdlabel -A /dev/ad6 # /dev/ad6: type: ESDI disk: ad6s1 label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 16 sectors/cylinder: 1008 cylinders: 155061 sectors/unit: 156301488 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 152205312 0 4.2BSD 2048 16384 28552 b: 4096176 152205312 swap c: 156301488 0 unused 0 0 # "raw" part, don't edit -- Mark Atkinson atkin901@yahoo.com (!wired)?(coffee++):(wired); From ganbold at micom.mng.net Tue Jan 6 16:02:22 2009 From: ganbold at micom.mng.net (Ganbold) Date: Tue Jan 6 16:02:29 2009 Subject: boot hangs with discrete graphics set in BIOS Message-ID: <4963808A.20006@micom.mng.net> Hi, The laptop has 2 graphics, integrated G45 and ATI HD 3740. BIOS has 3 settings, integrated, discrete and switchable. CURRENT boots when BIOS is set to either integrated or switchable. But boot fails when BIOS is set to discrete (ATI graphics). I also tried hw.pci.mcfg=0 on loader.conf, but no success. Boot hangs right after hitting enter after the Boot Menu. Is there any known solution for this? dmesg is at: http://people.freebsd.org/~ganbold/dmesg_verbose.log thanks, Ganbold -- Be cautious in your daily affairs. From yanefbsd at gmail.com Tue Jan 6 18:32:57 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Tue Jan 6 18:33:28 2009 Subject: snd_hda(4): getting line-in to work Message-ID: <7d6fde3d0901061032n72e9d0c4refe3c695f441c827@mail.gmail.com> Hi CURRENT and Alexander, I'm not sure if it's user error or not, but my snd_hda(4) enabled chipset doesn't have line-in support enabled. I was wondering if there were a special set of instructions I need to follow to get this working. My /dev/sndstat says: [gcooper@orangebox /scratch/ltp]$ cat /dev/sndstat FreeBSD Audio Driver (newpcm: 32bit 2007061600/i386) Installed devices: pcm0: at cad 0 nid 1 on hdac0 [MPSAFE] (1p:1v/1r:1v channels duplex default) pcm1: at cad 0 nid 1 on hdac0 [MPSAFE] (1p:1v/0r:0v channels) pcm2: at cad 0 nid 1 on hdac0 [MPSAFE] (1p:1v/0r:0v channels) [gcooper@orangebox /scratch/ltp]$ uname -a FreeBSD orangebox.gateway.2wire.net 8.0-CURRENT FreeBSD 8.0-CURRENT #4: Sat Jan 3 22:54:52 PST 2009 gcooper@orangebox.gateway.2wire.net:/usr/obj/usr/src/sys/ORANGEBOX i386 [gcooper@orangebox /scratch/ltp]$ sysctl -a | grep snd hw.snd.latency_profile: 1 hw.snd.latency: 5 hw.snd.report_soft_formats: 1 hw.snd.compat_linux_mmap: 0 hw.snd.feeder_buffersize: 16384 hw.snd.feeder_rate_round: 25 hw.snd.feeder_rate_max: 2016000 hw.snd.feeder_rate_min: 1 hw.snd.verbose: 1 hw.snd.maxautovchans: 16 hw.snd.default_unit: 0 hw.snd.version: 2007061600/i386 hw.snd.default_auto: 0 pciconf(1) snippet: hdac0@pci0:0:27:0: class=0x040300 card=0x82771043 chip=0x293e8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801IB/IR/IH (ICH9 Family) HD Audio Controller' class = multimedia subclass = HDA Thanks, -Garrett From giffunip at tutopia.com Tue Jan 6 18:05:17 2009 From: giffunip at tutopia.com (Pedro F. Giffuni) Date: Tue Jan 6 18:33:31 2009 Subject: RFC: ELF branding. looking to a ".note.ABI-tag" section Message-ID: <25454.95171.qm@web32702.mail.mud.yahoo.com> Hi; As the author of kern/118473 I think that ELF notes for brand-ELFing is a useless non standard hack. I do understand that we want to teach our linuxulator about GNU ELF notes, but why would we want to use them for FreeBSD binaries? If you follow the posting on the lists by John Polstra and ELF spec you will find we don't need ELF notes. There is also a thread in some binutils list that made me conclude the reason they chose for not using the standard way was "NIH". Pedro. From atkin901 at yahoo.com Tue Jan 6 18:41:05 2009 From: atkin901 at yahoo.com (Mark Atkinson) Date: Tue Jan 6 18:41:12 2009 Subject: FreeBSD 8: fails booting from slice ad8s1a References: <4962A0D3.1010704@mail.zedat.fu-berlin.de> Message-ID: Replying to myself, solution below: Mark Atkinson wrote: > Trying to mount root from ufs:/dev/ad6s1a > > Manual root filesystem specification: > : Mount using filesystem > eg. ufs:da0s1a > ? List valid disk boot devices > Abort manual input > > mountroot> ? > > List of GEOM managed disk devices: > ad6b ad6a ad6 acd0 > > Manual root filesystem specification: > : Mount using filesystem > eg. ufs:da0s1a > ? List valid disk boot devices > Abort manual input > > mountroot> ufs:ad6a > Trying to mount root from ufs:ad6a > WARNING: / was not properly dismounted > /: mount pending error: blocks 8 files 1 > Lookup of /dev for devfs, error: 20 > exec /sbin/init: error 20 > exec /sbin/oinit: error 20 > exec /sbin/init.bak: error 20 > exec /rescue/init: error 20 > exec /stand/sysinstall: error 20 > init: not found in > path /sbin/init:/sbin/oinit:/sbin/init.bak:/rescue/init:/stand/sysinstall > panic: no init > cpuid = 1 > KDB: enter: panic > [thread pid 1 tid 100002 ] > Stopped at kdb_enter+0x3a: movl $0,kdb_why > db> This is the 'stale label' problem described here: http://lists.freebsd.org/pipermail/freebsd-current/2008-December/001750.html with the solution here: http://lists.freebsd.org/pipermail/freebsd-current/2009-January/001892.html After erasing the 'non-slice' label on the disk, I'm able to mount root. -- Mark Atkinson atkin901@yahoo.com (!wired)?(coffee++):(wired); From dchagin at freebsd.org Tue Jan 6 19:59:12 2009 From: dchagin at freebsd.org (Chagin Dmitry) Date: Tue Jan 6 19:59:19 2009 Subject: RFC: ELF branding. looking to a ".note.ABI-tag" section In-Reply-To: <25454.95171.qm@web32702.mail.mud.yahoo.com> References: <25454.95171.qm@web32702.mail.mud.yahoo.com> Message-ID: <20090106195903.GA51780@dchagin.dialup.corbina.ru> On Tue, Jan 06, 2009 at 09:38:35AM -0800, Pedro F. Giffuni wrote: > Hi; > > As the author of kern/118473 I think that ELF notes for brand-ELFing is a useless non standard hack. I do understand that we want to teach our linuxulator about GNU ELF notes, but why would we want to use them for FreeBSD binaries? > > If you follow the posting on the lists by John Polstra and ELF spec you will find we don't need ELF notes. There is also a thread in some binutils list that made me conclude the reason they chose for not using the standard way was "NIH". > > Pedro. > Hi, I don't think so. We already use this for native binaries. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/imgact_elf.c.diff?r1=1.181;r2=1.182 -- Have fun! chd From mav at FreeBSD.org Tue Jan 6 20:53:18 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Tue Jan 6 20:53:24 2009 Subject: snd_hda(4): getting line-in to work In-Reply-To: <7d6fde3d0901061032n72e9d0c4refe3c695f441c827@mail.gmail.com> References: <7d6fde3d0901061032n72e9d0c4refe3c695f441c827@mail.gmail.com> Message-ID: <4963C4C0.6000509@FreeBSD.org> Garrett Cooper wrote: > I'm not sure if it's user error or not, but my snd_hda(4) enabled > chipset doesn't have line-in support enabled. I was wondering if there > were a special set of instructions I need to follow to get this > working. The main instruction is to boot system with verbose messages. snd_hda writes all information needed to answer most questions. Read it yourself and if it does not help - send it to me. > [gcooper@orangebox /scratch/ltp]$ cat /dev/sndstat > FreeBSD Audio Driver (newpcm: 32bit 2007061600/i386) > Installed devices: > pcm0: at cad 0 nid 1 on > hdac0 [MPSAFE] (1p:1v/1r:1v channels duplex default) All I can see here is that you have some recording device. You can browse and select specific recording source with `mixer =rec` command. For additional details look verbose output and read new snd_hda man page. > pcm1: at cad 0 nid 1 on > hdac0 [MPSAFE] (1p:1v/0r:0v channels) > pcm2: at cad 0 nid 1 on > hdac0 [MPSAFE] (1p:1v/0r:0v channels) -- Alexander Motin From artis.caune at gmail.com Tue Jan 6 21:04:17 2009 From: artis.caune at gmail.com (Artis Caune) Date: Tue Jan 6 21:04:49 2009 Subject: Labeling disks In-Reply-To: References: Message-ID: <9e20d71e0901061234n2b6a526ap3290abdca4ef7527@mail.gmail.com> 2008/12/5 Stefan Bethke : > - Using glabel to label the disks, and then fdisk/bsdlabel partioning them, > works nicely. As soon as I put a gmirror on the label/disk?s1a partitions, > *all* labels disappear. Huh? I can understand removing the labels for the > partitions that are now the providers used by the gmirror, but why to the > other get removed? Also, it seems that gmirror references the actual disks > (see gmirror output below) instead of the labels. I was under the impression > that glabel would consume a provider and provide it minus the last sector, > so /dev/label/foo and /dev/ad22 are not the same device (but do overlap). Have you tried to label gmirror with -h flag? -- regards, Artis Caune <----. CCNA | BSDA <----|==================== <----' didii FreeBSD From giffunip at tutopia.com Tue Jan 6 20:48:20 2009 From: giffunip at tutopia.com (giffunip@tutopia.com) Date: Tue Jan 6 21:11:08 2009 Subject: RFC: ELF branding. looking to a '.note.ABI-tag' section Message-ID: <20090106204820.31FFB8FC1B@mx1.freebsd.org> On Mar Ene 6 14:59 , Chagin Dmitry sent: >On Tue, Jan 06, 2009 at 09:38:35AM -0800, Pedro F. Giffuni wrote: >> Hi; >> >> As the author of kern/118473 I think that ELF notes for brand-ELFing is a useless non standard hack. I do understand that we want to teach our linuxulator about GNU ELF notes, but why would we want to use them for FreeBSD binaries? >> >> If you follow the posting on the lists by John Polstra and ELF spec you will find we don't need ELF notes. There is also a thread in some binutils list that made me conclude the reason they chose for not using the standard way was "NIH". >> >> Pedro. >> > >Hi, I don't think so. We already use this for native binaries. > >http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/imgact_elf.c.diff\? r1=1.181;r2=1.182 > Aha .. The ELF standard doesn't include the OS_version so using notes for that makes sense, however for the ABI the standard has always been EI_ABI field. http://www.sco.com/developers/gabi/latest/ch4.eheader.html#osabi Please check this interesting link: http://people.freebsd.org/~obrien/ei_osabi-binutils.mbox Pedro. From bzeeb-lists at lists.zabbadoz.net Wed Jan 7 01:25:07 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Wed Jan 7 01:25:14 2009 Subject: need conf/kern.post.mk review In-Reply-To: <20081216053058.GA37217@amp2.iem.pw.edu.pl> References: <20081215220539.W97918@maildrop.int.zabbadoz.net> <20081216053058.GA37217@amp2.iem.pw.edu.pl> Message-ID: <20090107012048.K45399@maildrop.int.zabbadoz.net> On Tue, 16 Dec 2008, Andrzej Tobola wrote: Hi, > If we are already on kern.port.mk what about the following patch > which gives the posibility to instal to fs without chflags (e.g. nfs) ? > I am using it from a long time as can be seen from time-stamps. > > --- /usr/src/sys/conf/kern.post.mk-OLD 2007-03-24 06:35:08.000000000 +0100 > +++ /usr/src/sys/conf/kern.post.mk 2007-11-24 23:52:03.000000000 +0100 > @@ -14,6 +14,12 @@ > .endif > MKMODULESENV+= KERNBUILDDIR="${.CURDIR}" > > +.if defined(NO_FSCHG) > +CHFLAGS= echo > +.else > +CHFLAGS= chflags -R noschg > +.endif > + > .MAIN: all > > .for target in all clean cleandepend cleandir clobber depend install \ > @@ -208,11 +214,11 @@ > .if exists(${DESTDIR}${KODIR}) > -thiskernel=`sysctl -n kern.bootfile` ; \ > if [ ! "`dirname "$$thiskernel"`" -ef ${DESTDIR}${KODIR} ] ; then \ > - chflags -R noschg ${DESTDIR}${KODIR} ; \ > + ${CHFLAGS} ${DESTDIR}${KODIR} ; \ > rm -rf ${DESTDIR}${KODIR} ; \ > else \ > if [ -d ${DESTDIR}${KODIR}.old ] ; then \ > - chflags -R noschg ${DESTDIR}${KODIR}.old ; \ > + ${CHFLAGS} ${DESTDIR}${KODIR}.old ; \ > rm -rf ${DESTDIR}${KODIR}.old ; \ > fi ; \ > mv ${DESTDIR}${KODIR} ${DESTDIR}${KODIR}.old ; \ > @@ -231,7 +237,7 @@ > > > kernel-reinstall: > - @-chflags -R noschg ${DESTDIR}${KODIR} > + @-${CHFLAGS} ${DESTDIR}${KODIR} > ${INSTALL} -p -m 555 -o root -g wheel ${KERNEL_KO} ${DESTDIR}${KODIR} > .if defined(DEBUG) && !defined(INSTALL_NODEBUG) > ${INSTALL} -p -m 555 -o root -g wheel ${KERNEL_KO}.symbols ${DESTDIR}${KODIR} I cannot see why you would need any of those changes. All three places do not care if they fail. the shell commands are using ; so the next command is just executed and kernel-reinstall has a - which means that a non-zero exist status is ignored. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From alexbestms at math.uni-muenster.de Wed Jan 7 01:42:44 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Wed Jan 7 01:42:51 2009 Subject: Problem with usbconfig and powerstate Message-ID: hi there, i'm having a bit of a problem with usbconfig. the problem first occured a few days ago. when i try to disable a usb device with power_off the power state changes to SAVE and not OFF. if i try to enable the usb device with power_on it won't work although usbconfig tells me the power state is ON. the only way to get the usb device working again is to unlpug it and plug it in again. last week i could switch the power state from off to on and vice versa without any problems. cheers. alex From giffunip at tutopia.com Wed Jan 7 00:58:21 2009 From: giffunip at tutopia.com (Pedro F. Giffuni) Date: Wed Jan 7 02:19:42 2009 Subject: RFC: ELF branding. looking to a ".note.ABI-tag" section Message-ID: <735174.53499.qm@web32704.mail.mud.yahoo.com> On Tue, Jan 06, 2009 at 09:38:35AM -0800, Pedro F. Giffuni wrote: > Hi; > > As the author of kern/118473 I think that ELF notes for brand-ELFing is a > useless non standard hack. I do understand that we want to teach our > linuxulator about GNU ELF notes, but why would we want to use them for > FreeBSD binaries? > Bah .. replying to myself after reviewing the end of the patch, this is the right approach since we still use the standard FreeBSD branding by default. Nevermind. Pedro. From yanefbsd at gmail.com Wed Jan 7 04:29:54 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Wed Jan 7 04:30:01 2009 Subject: snd_hda(4): getting line-in to work In-Reply-To: <4963C4C0.6000509@FreeBSD.org> References: <7d6fde3d0901061032n72e9d0c4refe3c695f441c827@mail.gmail.com> <4963C4C0.6000509@FreeBSD.org> Message-ID: <7d6fde3d0901062029j694d63c1h66c52dfbb80c13d8@mail.gmail.com> On Tue, Jan 6, 2009 at 12:53 PM, Alexander Motin wrote: > Garrett Cooper wrote: >> >> I'm not sure if it's user error or not, but my snd_hda(4) enabled >> chipset doesn't have line-in support enabled. I was wondering if there >> were a special set of instructions I need to follow to get this >> working. > > The main instruction is to boot system with verbose messages. snd_hda writes > all information needed to answer most questions. Read it yourself and if it > does not help - send it to me. > >> [gcooper@orangebox /scratch/ltp]$ cat /dev/sndstat >> FreeBSD Audio Driver (newpcm: 32bit 2007061600/i386) >> Installed devices: >> pcm0: at cad 0 nid 1 on >> hdac0 [MPSAFE] (1p:1v/1r:1v channels duplex default) > > All I can see here is that you have some recording device. You can browse > and select specific recording source with `mixer =rec` command. For > additional details look verbose output and read new snd_hda man page. > >> pcm1: at cad 0 nid 1 on >> hdac0 [MPSAFE] (1p:1v/0r:0v channels) >> pcm2: at cad 0 nid 1 on >> hdac0 [MPSAFE] (1p:1v/0r:0v channels) > > -- > Alexander Motin Trying with the instructions on the manpage actually disabled my sound... then again I probably screwed up the settings (I believe it was noted as pcm2 before??). Here're the device.hints entries and I attached the -v boot log snippet for the card: hint.hdac.0.cad0.nid17.config="as=1seq=0 device=Headphones" hint.hdac.0.cad0.nid18.config="as=2seq=0 device=Line-out" hint.hdac.0.cad0.nid19.config="as=3seq=0 device=Speaker" hint.hdac.0.cad0.nid20.config="as=4seq=0 device=Mic" hint.hdac.0.cad0.nid21.config="as=5seq=0 device=Line-in" hint.hdac.0.cad0.nid22.config="as=6seq=0 device=Line-out" hint.hdac.0.cad0.nid23.config="as=6seq=0 device=Mic" hint.hdac.0.cad0.nid24.config="as=6seq=0 device=CD" hint.hdac.0.cad0.nid36.config="as=5seq=0 device=Line-out" hint.hdac.0.cad0.nid37.config="as=6seq=0 device=Line-out" Thanks! -Garrett -------------- next part -------------- A non-text attachment was scrubbed... Name: hdac.log Type: application/octet-stream Size: 31863 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090107/3dbafb68/hdac-0001.obj From mav at FreeBSD.org Wed Jan 7 09:29:36 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Wed Jan 7 09:29:42 2009 Subject: snd_hda(4): getting line-in to work In-Reply-To: <7d6fde3d0901062029j694d63c1h66c52dfbb80c13d8@mail.gmail.com> References: <7d6fde3d0901061032n72e9d0c4refe3c695f441c827@mail.gmail.com> <4963C4C0.6000509@FreeBSD.org> <7d6fde3d0901062029j694d63c1h66c52dfbb80c13d8@mail.gmail.com> Message-ID: <49647602.9060402@FreeBSD.org> Garrett Cooper wrote: > On Tue, Jan 6, 2009 at 12:53 PM, Alexander Motin wrote: >> Garrett Cooper wrote: >>> I'm not sure if it's user error or not, but my snd_hda(4) enabled >>> chipset doesn't have line-in support enabled. I was wondering if there >>> were a special set of instructions I need to follow to get this >>> working. >> The main instruction is to boot system with verbose messages. snd_hda writes >> all information needed to answer most questions. Read it yourself and if it >> does not help - send it to me. >> >>> [gcooper@orangebox /scratch/ltp]$ cat /dev/sndstat >>> FreeBSD Audio Driver (newpcm: 32bit 2007061600/i386) >>> Installed devices: >>> pcm0: at cad 0 nid 1 on >>> hdac0 [MPSAFE] (1p:1v/1r:1v channels duplex default) >> All I can see here is that you have some recording device. You can browse >> and select specific recording source with `mixer =rec` command. For >> additional details look verbose output and read new snd_hda man page. >> >>> pcm1: at cad 0 nid 1 on >>> hdac0 [MPSAFE] (1p:1v/0r:0v channels) >>> pcm2: at cad 0 nid 1 on >>> hdac0 [MPSAFE] (1p:1v/0r:0v channels) >> -- >> Alexander Motin > > Trying with the instructions on the manpage actually disabled my > sound... then again I probably screwed up the settings (I believe it > was noted as pcm2 before??). > > Here're the device.hints entries and I attached the -v boot log > snippet for the card: In attached log you have missed one of very interesting parts while grepping: pcmX devices output prints sound processing paths within codec for every PCM device. Look it first before doing something. > hint.hdac.0.cad0.nid17.config="as=1seq=0 device=Headphones" > hint.hdac.0.cad0.nid18.config="as=2seq=0 device=Line-out" > hint.hdac.0.cad0.nid19.config="as=3seq=0 device=Speaker" > hint.hdac.0.cad0.nid20.config="as=4seq=0 device=Mic" > hint.hdac.0.cad0.nid21.config="as=5seq=0 device=Line-in" > hint.hdac.0.cad0.nid22.config="as=6seq=0 device=Line-out" > hint.hdac.0.cad0.nid23.config="as=6seq=0 device=Mic" > hint.hdac.0.cad0.nid24.config="as=6seq=0 device=CD" > hint.hdac.0.cad0.nid36.config="as=5seq=0 device=Line-out" > hint.hdac.0.cad0.nid37.config="as=6seq=0 device=Line-out" Except lack of speces between fields there is also lack of any sense. I don't understand what was you trying to do, but it will not work: - you configured nid 21 and nid 36 as association five, but made one of them input and other output. It is incorrect, association may include only pins of one direction (in/out); - association 6 is the same; - nid 19 has connectivity "None", so it will not be used by driver. It is all described in manual. Actually I think default configuration is quite reasonable. There is some things that can be tuned, but you should first understand what you have and how it works. -- Alexander Motin From hselasky at c2i.net Wed Jan 7 10:24:58 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Wed Jan 7 10:25:05 2009 Subject: Problem with usbconfig and powerstate In-Reply-To: References: Message-ID: <200901071127.19863.hselasky@c2i.net> On Wednesday 07 January 2009, Alexander Best wrote: > hi there, > > i'm having a bit of a problem with usbconfig. the problem first occured a > few days ago. when i try to disable a usb device with power_off the power > state changes to SAVE and not OFF. if i try to enable the usb device with > power_on it won't work although usbconfig tells me the power state is ON. > the only way to get the usb device working again is to unlpug it and plug > it in again. > > last week i could switch the power state from off to on and vice versa > without any problems. > Hi, Last week power-save support was introduced. It might be a minor bug in the HC driver's power save support. What host controller are you using? dmesg | grep -i usb --HPS From hselasky at c2i.net Wed Jan 7 10:57:14 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Wed Jan 7 10:57:21 2009 Subject: Problem with usbconfig and powerstate In-Reply-To: <200901071127.19863.hselasky@c2i.net> References: <200901071127.19863.hselasky@c2i.net> Message-ID: <200901071159.33529.hselasky@c2i.net> On Wednesday 07 January 2009, Hans Petter Selasky wrote: > On Wednesday 07 January 2009, Alexander Best wrote: > > hi there, > > > > i'm having a bit of a problem with usbconfig. the problem first occured a > > few days ago. when i try to disable a usb device with power_off the power > > state changes to SAVE and not OFF. if i try to enable the usb device with > > power_on it won't work although usbconfig tells me the power state is ON. > > the only way to get the usb device working again is to unlpug it and plug > > it in again. > > > > last week i could switch the power state from off to on and vice versa > > without any problems. > > Hi, > > Last week power-save support was introduced. It might be a minor bug in the > HC driver's power save support. What host controller are you using? > > dmesg | grep -i usb > Here are some patches which you can try: http://perforce.freebsd.org/chv.cgi?CH=155750 --HPS From hselasky at c2i.net Wed Jan 7 13:28:01 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Wed Jan 7 13:28:14 2009 Subject: Call for axe(4) testers. In-Reply-To: <20090105025330.68b22f63.nork@FreeBSD.org> References: <47297827@bb.ipt.ru> <20090105021809.d3848b9c.nork@FreeBSD.org> <20090105025330.68b22f63.nork@FreeBSD.org> Message-ID: <200901071430.20446.hselasky@c2i.net> On Sunday 04 January 2009, Norikatsu Shigemura wrote: > Hi hps! > Try this patch: http://perforce.freebsd.org/chv.cgi?CH=155755 --HPS From biancalana at gmail.com Wed Jan 7 14:43:07 2009 From: biancalana at gmail.com (Alexandre Biancalana) Date: Wed Jan 7 14:43:13 2009 Subject: ZFS boot Message-ID: <8e10486b0901070617q2ddb82cem18b34b70c8cc45ef@mail.gmail.com> Hi List ! Happy New Year! I From biancalana at gmail.com Wed Jan 7 14:43:35 2009 From: biancalana at gmail.com (Alexandre Biancalana) Date: Wed Jan 7 14:43:42 2009 Subject: ZFS boot In-Reply-To: <8e10486b0901070617q2ddb82cem18b34b70c8cc45ef@mail.gmail.com> References: <8e10486b0901070617q2ddb82cem18b34b70c8cc45ef@mail.gmail.com> Message-ID: <8e10486b0901070620x610a8156lfc1206e5262f8f5a@mail.gmail.com> Hi List ! Happy New Year! Is already possible to boot directly from zfs ?? Regards, From olivier at gid0.org Wed Jan 7 15:02:12 2009 From: olivier at gid0.org (Olivier SMEDTS) Date: Wed Jan 7 15:02:18 2009 Subject: ZFS boot In-Reply-To: <8e10486b0901070620x610a8156lfc1206e5262f8f5a@mail.gmail.com> References: <8e10486b0901070617q2ddb82cem18b34b70c8cc45ef@mail.gmail.com> <8e10486b0901070620x610a8156lfc1206e5262f8f5a@mail.gmail.com> Message-ID: <367b2c980901070702k161bf1a6n1315db538b68a33c@mail.gmail.com> Hi ! 2009/1/7 Alexandre Biancalana : > Hi List ! Happy New Year! > > Is already possible to boot directly from zfs ?? Yes. Look at http://blogs.freebsdish.org/lulf/category/freebsd/ for a ZFS-only FreeBSD using GPT. This is for -CURRENT only. For an MBR partition table scheme, it's more complicated. I wasn't able to boot from a ZFS pool on my amd64 system, but maybe I'm doing something wrong. Look at threads on this list from late 2008, and especially the "LOADER_ZFS_SUPPORT=yes" option and how to install the zfsboot loader with dd. Happy new year :) Olivier > > Regards, > _______________________________________________ > 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" > -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: olivier@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." From mad at madpilot.net Wed Jan 7 16:27:20 2009 From: mad at madpilot.net (Guido Falsi) Date: Wed Jan 7 16:27:27 2009 Subject: ZFS send core Message-ID: <20090107162717.GC13446@megatron.madpilot.net> Hi, I am playing around a little with an 8.0 system on AMD64 and ZFS. Since I wanted to try out gtp booting I thought I'd make a backup of my system, repartition and restore from there. This is just a test machine, so I don't need the backup to be really safe, I thought I could try using zfs send functionality. I gave the follwing commands: zfs snapshot -r tank@test1 zfs send -vR tank@test1 > testdump to create a file I could "receive" later with all the FS data and configurations(I hope I'm getting this right, if I'm just doing something stupid, sorry for the noise). The second command simply dumped core right away. These are the last few lines from a backtrace: #0 0x000000080066d830 in zfs_prop_readonly () from /lib/libzfs.so.1 #1 0x0000000800653dda in fletcher_4_incremental_byteswap () from /lib/libzfs.so.1 #2 0x0000000800654054 in fletcher_4_incremental_byteswap () from /lib/libzfs.so.1 #3 0x00000008006548f0 in fletcher_4_incremental_byteswap () from /lib/libzfs.so.1 #4 0x000000080065833a in zfs_send () from /lib/libzfs.so.1 #5 0x00000000004069a4 in ?? () #6 0x0000000000406176 in ?? () and it goes on up to #634. I can reproduce this all the time. I don't really know if this is zfs fault or I'm simply doing something wrong. I am available to give back any more information needed, just tell me what to look for. BTW zfs send without the -R option works fine, but, as explained in the man page, just dumps one zfs, not the whole hierarchy, which was what I wanted to do. Thank you. -- Guido Falsi From mad at madpilot.net Wed Jan 7 16:34:20 2009 From: mad at madpilot.net (Guido Falsi) Date: Wed Jan 7 16:34:41 2009 Subject: ZFS send core In-Reply-To: <20090107162717.GC13446@megatron.madpilot.net> References: <20090107162717.GC13446@megatron.madpilot.net> Message-ID: <20090107163418.GD13446@megatron.madpilot.net> On Wed, Jan 07, 2009 at 05:27:17PM +0100, Guido Falsi wrote: > The second command simply dumped core right away. Forgot one information, this is a recent current, using zfs 13. I'm also booting using the system described here: http://wiki.freebsd.org/ZFSOnRoot -- Guido Falsi From bra at fsn.hu Wed Jan 7 18:07:52 2009 From: bra at fsn.hu (Attila Nagy) Date: Wed Jan 7 18:08:03 2009 Subject: pxeboot does not work on Sun X4540 Message-ID: <4964EB20.5070709@fsn.hu> Hello, I'm trying to boot FreeBSD 8-CURRENT on a Sun X4540 (2xquad core Opteron, 64 GB memory, 48 SATA disks (in fact 47, the 48th is a write optimized SSD, because this box is a 7210 OpenStorage "appliance", running OpenSolaris) on LSI controllers, nvidia NIC) from our boot server without success. The PXE on the NIC downloads pxeboot with TFTP, but then gets stuck at loading the kernel: http://people.fsn.hu/~bra/freebsd/20090107-freebsd-x4540/Screenshot-6.png pxeboot is configured to load the kernel via NFS (the default) and according to the tcpdump output, the client (X4540) issues an NFS GETPORT call and gets the response from the NFS server and then nothing else happens. I've tried with LOADER_TFTP_SUPPORT=YES and the result is the same, the only difference is that the machine stops sending packets after the first TFTP read request (for /boot/boot.4th.split), which doesn't exist, so the server sends the answer and then nothing comes back from the X4540 box. It seems that it gets to send exactly one packet, then freezes. What else should be done to debug this problem? Thanks, From bra at fsn.hu Wed Jan 7 18:51:42 2009 From: bra at fsn.hu (Attila Nagy) Date: Wed Jan 7 18:51:49 2009 Subject: pxeboot does not work on Sun X4540 In-Reply-To: <4964EB20.5070709@fsn.hu> References: <4964EB20.5070709@fsn.hu> Message-ID: <4964F9BB.3020407@fsn.hu> Attila Nagy wrote: > Hello, > > I'm trying to boot FreeBSD 8-CURRENT on a Sun X4540 (2xquad core > Opteron, 64 GB memory, 48 SATA disks (in fact 47, the 48th is a write > optimized SSD, because this box is a 7210 OpenStorage "appliance", > running OpenSolaris) on LSI controllers, nvidia NIC) from our boot > server without success. > > The PXE on the NIC downloads pxeboot with TFTP, but then gets stuck at > loading the kernel: > http://people.fsn.hu/~bra/freebsd/20090107-freebsd-x4540/Screenshot-6.png > > pxeboot is configured to load the kernel via NFS (the default) and > according to the tcpdump output, the client (X4540) issues an NFS > GETPORT call and gets the response from the NFS server and then > nothing else happens. > > I've tried with LOADER_TFTP_SUPPORT=YES and the result is the same, > the only difference is that the machine stops sending packets after > the first TFTP read request (for /boot/boot.4th.split), which doesn't > exist, so the server sends the answer and then nothing comes back from > the X4540 box. > > It seems that it gets to send exactly one packet, then freezes. > > What else should be done to debug this problem? > > Thanks, BTW, the last FreeBSD 8-CURRENT snapshot from december boots fine (at least I can get to sysinstall, I haven't yet tried installation, because I wouldn't like to touch the boot drives, which house the OpenSolaris image -that's why I want to boot from the net). I would like to do a FreeBSD vs. OpenSolaris comparison on this machine, so please help. :) Thanks, From sgk at troutmask.apl.washington.edu Wed Jan 7 20:02:20 2009 From: sgk at troutmask.apl.washington.edu (Steve Kargl) Date: Wed Jan 7 20:02:26 2009 Subject: mount_nfs is broken Message-ID: <20090107200219.GA71053@troutmask.apl.washington.edu> Someone appears to have broken mount_nfs. I rebuilt kernel and world and install it on my primary system. Everything appears be working fine. So, I then update the first node in my cluster. It reboots fine until the node tries to mount the users' home directories. The line in /etc/fstab is node10:/home /home nfs rw,noatime 0 0 Trying to manually mount /home, I find % mount_nfs 192.168.0.10:/usr/home /home mount_nfs: /usr/home, mount option is unknown: Invalid argument There are no clues in src/UPDATING concerning incompatibilities with NFS. I do not use modules. The kernels are identical on the two system and it was built with options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFS_LEGACYRPC The last option is only documented at http://www.freebsd.org/cgi/cvsweb.cgi/src/sbin/mount_nfs/mount_nfs.c The wonderfully fun part of this problem is that I can no longer NFS mount /usr/src from the node. -- Steve From peter.schuller at infidyne.com Wed Jan 7 20:43:52 2009 From: peter.schuller at infidyne.com (Peter Schuller) Date: Wed Jan 7 20:43:58 2009 Subject: ZFS gets stuck In-Reply-To: References: <20081117205526.GC1733@garage.freebsd.pl> <20081202203308.GA13818@hyperion.scode.org> <200812021254.21242.fjwcash@gmail.com> <20081202232924.GA19134@hyperion.scode.org> <31C70CBC-488A-4A9A-A642-37855E8F1DD1@lassitu.de> <5C97E586-4296-4835-A103-FD273B2D7A4F@lassitu.de> Message-ID: <20090107204349.GA18095@hyperion.scode.org> > I've disabled zil on one of the two identical machines, and the one > with zil still enabled keeps locking up, while the one with zil > disabled keeps on running. Just wanted to add a "me three"; with CURRENT from ~ 2008-12-03, I would semi-determinstically have the machine freeze at some point during a binary package build on my desktop, and sometimes otherwise. After disabling zil, I have not suffered any crashes. By now sufficient time/builds have passed that it seems fairly likely that the change helped. -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090107/4324e503/attachment.pgp From rodrigc at crodrigues.org Wed Jan 7 21:19:21 2009 From: rodrigc at crodrigues.org (Craig Rodrigues) Date: Wed Jan 7 21:19:27 2009 Subject: mount_nfs is broken In-Reply-To: <20090107200219.GA71053@troutmask.apl.washington.edu> References: <20090107200219.GA71053@troutmask.apl.washington.edu> Message-ID: <20090107211920.GA54918@crodrigues.org> On Wed, Jan 07, 2009 at 12:02:19PM -0800, Steve Kargl wrote: > mount_nfs: /usr/home, mount option is unknown: Invalid argument This error seems to indicate that your kernel is older than your mount_nfs in userland. Did you rebuild and install the new kernel? -- Craig Rodrigues rodrigc@crodrigues.org From sgk at troutmask.apl.washington.edu Wed Jan 7 21:58:16 2009 From: sgk at troutmask.apl.washington.edu (Steve Kargl) Date: Wed Jan 7 21:58:23 2009 Subject: mount_nfs is broken In-Reply-To: <20090107211920.GA54918@crodrigues.org> References: <20090107200219.GA71053@troutmask.apl.washington.edu> <20090107211920.GA54918@crodrigues.org> Message-ID: <20090107215808.GA72048@troutmask.apl.washington.edu> On Wed, Jan 07, 2009 at 09:19:20PM +0000, Craig Rodrigues wrote: > On Wed, Jan 07, 2009 at 12:02:19PM -0800, Steve Kargl wrote: > > mount_nfs: /usr/home, mount option is unknown: Invalid argument > > This error seems to indicate that your kernel > is older than your mount_nfs in userland. Did you rebuild and install > the new kernel? Hmmm. Odd, I know I typed "make installkernel" twice. The timestamp of the kernel on the node is too old, so I must have installed the kernel twice on my primary system. :( Thanks for pointer. -- Steve From w8hdkim at gmail.com Wed Jan 7 23:00:11 2009 From: w8hdkim at gmail.com (Kim Culhan) Date: Wed Jan 7 23:00:20 2009 Subject: msk Marvell Yukon 88E8038 hangs Message-ID: <89dbfdc30901071438j314ac431h491f9494593caf64@mail.gmail.com> The msk interface on an Acer Aspire 5570Z hangs, frequently when running cvsup. Not necessarily at each hang but sometimes coincident, this is intermittently output to the console: in_cksum_skip: out of data by 56952 The above is also output to the console at times when receiving a character through ssh to a shell. The in_cksum_skip messages and msk hangs are also present on this hardware running 7.1-RELEASE. Any help here is very greatly appreciated. regards -kim -- From sgk at troutmask.apl.washington.edu Wed Jan 7 23:14:06 2009 From: sgk at troutmask.apl.washington.edu (Steve Kargl) Date: Wed Jan 7 23:14:14 2009 Subject: mount_nfs is broken In-Reply-To: <20090107215808.GA72048@troutmask.apl.washington.edu> References: <20090107200219.GA71053@troutmask.apl.washington.edu> <20090107211920.GA54918@crodrigues.org> <20090107215808.GA72048@troutmask.apl.washington.edu> Message-ID: <20090107231400.GA72918@troutmask.apl.washington.edu> On Wed, Jan 07, 2009 at 01:58:08PM -0800, Steve Kargl wrote: > On Wed, Jan 07, 2009 at 09:19:20PM +0000, Craig Rodrigues wrote: > > On Wed, Jan 07, 2009 at 12:02:19PM -0800, Steve Kargl wrote: > > > mount_nfs: /usr/home, mount option is unknown: Invalid argument > > > > This error seems to indicate that your kernel > > is older than your mount_nfs in userland. Did you rebuild and install > > the new kernel? > > Hmmm. Odd, I know I typed "make installkernel" twice. > The timestamp of the kernel on the node is too old, > so I must have installed the kernel twice on my primary > system. :( > > Thanks for pointer. > Something is broken with 'make installkernel' from an NFS mounted /usr/src and /usr/obj. I just updated a 2nd node from the node's console. 'make installkernel' appeared to complete. Upon rebooting, the old kernel was still present. -- Steve From joe at via.net Wed Jan 7 23:31:54 2009 From: joe at via.net (joe mcguckin) Date: Wed Jan 7 23:32:00 2009 Subject: Best torrent client/server available for FreeBSD? Message-ID: There's quite a number of implementation in the ports collection. Does anyone have any options regarding which are the 'best'? Thanks, Joe Joe McGuckin ViaNet Communications joe@via.net 650-207-0372 cell 650-213-1302 office 650-969-2124 fax From pyunyh at gmail.com Thu Jan 8 01:12:28 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Thu Jan 8 01:12:35 2009 Subject: msk Marvell Yukon 88E8038 hangs In-Reply-To: <89dbfdc30901071438j314ac431h491f9494593caf64@mail.gmail.com> References: <89dbfdc30901071438j314ac431h491f9494593caf64@mail.gmail.com> Message-ID: <20090108011220.GA1256@cdnetworks.co.kr> On Wed, Jan 07, 2009 at 05:38:28PM -0500, Kim Culhan wrote: > The msk interface on an Acer Aspire 5570Z hangs, frequently when running cvsup. > > Not necessarily at each hang but sometimes coincident, this is > intermittently output to the console: > > in_cksum_skip: out of data by 56952 > > The above is also output to the console at times when receiving a > character through ssh > to a shell. > > The in_cksum_skip messages and msk hangs are also present on this hardware > running 7.1-RELEASE. > Would you show me dmesg output for msk(4)? -- Regards, Pyun YongHyeon From sgk at troutmask.apl.washington.edu Thu Jan 8 01:18:11 2009 From: sgk at troutmask.apl.washington.edu (Steve Kargl) Date: Thu Jan 8 01:18:27 2009 Subject: mount_nfs is broken In-Reply-To: <20090107231400.GA72918@troutmask.apl.washington.edu> References: <20090107200219.GA71053@troutmask.apl.washington.edu> <20090107211920.GA54918@crodrigues.org> <20090107215808.GA72048@troutmask.apl.washington.edu> <20090107231400.GA72918@troutmask.apl.washington.edu> Message-ID: <20090108011808.GA73377@troutmask.apl.washington.edu> On Wed, Jan 07, 2009 at 03:14:00PM -0800, Steve Kargl wrote: > On Wed, Jan 07, 2009 at 01:58:08PM -0800, Steve Kargl wrote: > > On Wed, Jan 07, 2009 at 09:19:20PM +0000, Craig Rodrigues wrote: > > > On Wed, Jan 07, 2009 at 12:02:19PM -0800, Steve Kargl wrote: > > > > mount_nfs: /usr/home, mount option is unknown: Invalid argument > > > > > > This error seems to indicate that your kernel > > > is older than your mount_nfs in userland. Did you rebuild and install > > > the new kernel? > > > > Hmmm. Odd, I know I typed "make installkernel" twice. > > The timestamp of the kernel on the node is too old, > > so I must have installed the kernel twice on my primary > > system. :( > > > > Thanks for pointer. > > > > Something is broken with 'make installkernel' from an > NFS mounted /usr/src and /usr/obj. > > I just updated a 2nd node from the node's console. > 'make installkernel' appeared to complete. Upon > rebooting, the old kernel was still present. > Yes, I'm monologuing. Pilot error. I had KERNCONF pointing at an experimental kernel from early October, so kernel and world were out of sync. Sorry about the noise. -- Steve From yanefbsd at gmail.com Thu Jan 8 02:04:36 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Thu Jan 8 02:04:43 2009 Subject: Best torrent client/server available for FreeBSD? In-Reply-To: References: Message-ID: <7d6fde3d0901071804q546c5e5fk332904064d772821@mail.gmail.com> On Wed, Jan 7, 2009 at 3:04 PM, joe mcguckin wrote: > There's quite a number of implementation in the ports collection. Does > anyone have any options regarding which are the 'best'? > > Thanks, > > Joe > > > Joe McGuckin > ViaNet Communications > > joe@via.net > 650-207-0372 cell > 650-213-1302 office > 650-969-2124 fax I haven't really run across a best in Unix (I personally prefer utorrent -- a Windows torrent client -- but the author refuses to opensource it ;(..), but if memory/CPU isn't so much of an issue (it uses Java), I suggest net-p2p/azureus. -Garrett From davidn04 at gmail.com Thu Jan 8 02:36:16 2009 From: davidn04 at gmail.com (David N) Date: Thu Jan 8 02:36:23 2009 Subject: Best torrent client/server available for FreeBSD? In-Reply-To: References: Message-ID: <4d7dd86f0901071810o65e0bf32m196f120bd0e5748c@mail.gmail.com> 2009/1/8 joe mcguckin : > There's quite a number of implementation in the ports collection. Does > anyone have any options regarding which are the 'best'? > > Thanks, > > Joe > > > Joe McGuckin > ViaNet Communications > > joe@via.net > 650-207-0372 cell > 650-213-1302 office > 650-969-2124 fax I use transmission daemon + transmission web. You can control it via command line or web interface. Regards David N From kientzle at freebsd.org Thu Jan 8 05:43:29 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Thu Jan 8 05:43:35 2009 Subject: Extattr portability? Message-ID: <4965927D.1060507@freebsd.org> I'm trying to complete the extended attribute support in libarchive. There are a handful of odd issues that arise which I think I could resolve if I knew of good use cases. Anyone here actually use extended attributes? (Note that ACLs are handled separately.) What software? What information do you store there? If you could benefit from being able to move extended attributes between FreeBSD and other systems, I'm especially interested. Cheers, Tim Kientzle From danny at cs.huji.ac.il Thu Jan 8 07:16:35 2009 From: danny at cs.huji.ac.il (Danny Braniss) Date: Thu Jan 8 07:16:44 2009 Subject: pxeboot does not work on Sun X4540 In-Reply-To: <4964F9BB.3020407@fsn.hu> References: <4964EB20.5070709@fsn.hu> <4964F9BB.3020407@fsn.hu> Message-ID: > Attila Nagy wrote: > > Hello, > > > > I'm trying to boot FreeBSD 8-CURRENT on a Sun X4540 (2xquad core > > Opteron, 64 GB memory, 48 SATA disks (in fact 47, the 48th is a write > > optimized SSD, because this box is a 7210 OpenStorage "appliance", > > running OpenSolaris) on LSI controllers, nvidia NIC) from our boot > > server without success. > > > > The PXE on the NIC downloads pxeboot with TFTP, but then gets stuck at > > loading the kernel: > > http://people.fsn.hu/~bra/freebsd/20090107-freebsd-x4540/Screenshot-6.png > > > > pxeboot is configured to load the kernel via NFS (the default) and > > according to the tcpdump output, the client (X4540) issues an NFS > > GETPORT call and gets the response from the NFS server and then > > nothing else happens. > > > > I've tried with LOADER_TFTP_SUPPORT=YES and the result is the same, > > the only difference is that the machine stops sending packets after > > the first TFTP read request (for /boot/boot.4th.split), which doesn't > > exist, so the server sends the answer and then nothing comes back from > > the X4540 box. > > > > It seems that it gets to send exactly one packet, then freezes. > > > > What else should be done to debug this problem? > > > > Thanks, > BTW, the last FreeBSD 8-CURRENT snapshot from december boots fine (at > least I can get to sysinstall, I haven't yet tried installation, because > I wouldn't like to touch the boot drives, which house the OpenSolaris > image -that's why I want to boot from the net). > older pxeboot - pre interrupt handling fixes - work ok, so you can use that instead. danny > I would like to do a FreeBSD vs. OpenSolaris comparison on this machine, > so please help. :) > > Thanks, > _______________________________________________ > 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 w8hdkim at gmail.com Thu Jan 8 07:36:49 2009 From: w8hdkim at gmail.com (Kim Culhan) Date: Thu Jan 8 07:36:57 2009 Subject: msk Marvell Yukon 88E8038 hangs In-Reply-To: <20090108011220.GA1256@cdnetworks.co.kr> References: <89dbfdc30901071438j314ac431h491f9494593caf64@mail.gmail.com> <20090108011220.GA1256@cdnetworks.co.kr> Message-ID: <89dbfdc30901072336l62c46214i113cccf9985bcdae@mail.gmail.com> On Wed, Jan 7, 2009 at 8:12 PM, Pyun YongHyeon wrote: > On Wed, Jan 07, 2009 at 05:38:28PM -0500, Kim Culhan wrote: > > The msk interface on an Acer Aspire 5570Z hangs, frequently when running cvsup. > > > > Not necessarily at each hang but sometimes coincident, this is > > intermittently output to the console: > > > > in_cksum_skip: out of data by 56952 > > > > The above is also output to the console at times when receiving a > > character through ssh > > to a shell. > > > > The in_cksum_skip messages and msk hangs are also present on this hardware > > running 7.1-RELEASE. > > > > Would you show me dmesg output for msk(4)? dmesg: mskc0: port 0x2000-0x20ff mem 0xd0100000-0xd0103fff irq 16 at device 0.0 on pci2 msk0: on mskc0 msk0: Ethernet address: 00:1b:24:59:5b:7a miibus0: on msk0 e1000phy0: PHY 0 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto mskc0: [FILTER] -kim From yanefbsd at gmail.com Thu Jan 8 07:49:27 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Thu Jan 8 07:49:34 2009 Subject: X becomes unresponsive with nvidia / xscreensaver and desktop panics Message-ID: <7d6fde3d0901072349i50d04d2ch34f308388c9fd414@mail.gmail.com> Hello folks, As many probably know, I recently installed FreeBSD 8-CURRENT on my desktop. One of the things I'm noting is that when I use dual displays with the nvidia driver, and xscreensaver kicks in and keeps going for a period of time, the machine's X.org console eats up a core, and when I try and do anything like gdb Xorg, the system hangs, attempts to panic (I assume that's the case because I hear it beep and attempt to restart), then I have to give it a warm boot. truss(1)'ing Xorg showed that there were a lot of SIGALARM's being fired and masked. This is incredibly reminiscent of the days when I used to run Linux and I forgot to configure my dump device (doh), but this problem appears to be easily reproducible with my environment. I'm fixing that issue right now, so I should have a working crashdump soon... Just wondering if anyone else has seen this issue, or if it's just me once again. Thanks, -Garrett From pyunyh at gmail.com Thu Jan 8 07:52:08 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Thu Jan 8 07:52:15 2009 Subject: msk Marvell Yukon 88E8038 hangs In-Reply-To: <89dbfdc30901072336l62c46214i113cccf9985bcdae@mail.gmail.com> References: <89dbfdc30901071438j314ac431h491f9494593caf64@mail.gmail.com> <20090108011220.GA1256@cdnetworks.co.kr> <89dbfdc30901072336l62c46214i113cccf9985bcdae@mail.gmail.com> Message-ID: <20090108075159.GH1256@cdnetworks.co.kr> On Thu, Jan 08, 2009 at 02:36:48AM -0500, Kim Culhan wrote: > On Wed, Jan 7, 2009 at 8:12 PM, Pyun YongHyeon wrote: > > On Wed, Jan 07, 2009 at 05:38:28PM -0500, Kim Culhan wrote: > > > The msk interface on an Acer Aspire 5570Z hangs, frequently when running cvsup. > > > > > > Not necessarily at each hang but sometimes coincident, this is > > > intermittently output to the console: > > > > > > in_cksum_skip: out of data by 56952 > > > > > > The above is also output to the console at times when receiving a > > > character through ssh > > > to a shell. > > > > > > The in_cksum_skip messages and msk hangs are also present on this hardware > > > running 7.1-RELEASE. > > > > > > > Would you show me dmesg output for msk(4)? > > dmesg: > > mskc0: port 0x2000-0x20ff mem > 0xd0100000-0xd0103fff irq 16 at device 0.0 on pci2 > msk0: on mskc0 > msk0: Ethernet address: 00:1b:24:59:5b:7a > miibus0: on msk0 > e1000phy0: PHY 0 on miibus0 > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > mskc0: [FILTER] > Would you try changes made in r183485(CVS if_msk.c, 1.33)? http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/msk/if_msk.c.diff?r1=1.32;r2=1.33;f=h -- Regards, Pyun YongHyeon From rdivacky at freebsd.org Thu Jan 8 08:55:53 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Thu Jan 8 08:56:01 2009 Subject: X becomes unresponsive with nvidia / xscreensaver and desktop panics In-Reply-To: <7d6fde3d0901072349i50d04d2ch34f308388c9fd414@mail.gmail.com> References: <7d6fde3d0901072349i50d04d2ch34f308388c9fd414@mail.gmail.com> Message-ID: <20090108083645.GA56613@freebsd.org> On Wed, Jan 07, 2009 at 11:49:26PM -0800, Garrett Cooper wrote: > Hello folks, > As many probably know, I recently installed FreeBSD 8-CURRENT on my desktop. > One of the things I'm noting is that when I use dual displays with > the nvidia driver, and xscreensaver kicks in and keeps going for a > period of time, the machine's X.org console eats up a core, and when I > try and do anything like gdb Xorg, the system hangs, attempts to panic > (I assume that's the case because I hear it beep and attempt to > restart), then I have to give it a warm boot. truss(1)'ing Xorg showed > that there were a lot of SIGALARM's being fired and masked. > This is incredibly reminiscent of the days when I used to run Linux and > I forgot to configure my dump device (doh), but this problem appears > to be easily reproducible with my environment. I'm fixing that issue > right now, so I should have a working crashdump soon... > Just wondering if anyone else has seen this issue, or if it's just me > once again. > Thanks, the nvidia driver keeps my 8-current crashing/deadlocking when playing video quite often (once a week?). I have no idea what it causes. the code of the driver seems to be done in 5.x times. I believe it needs some rehashing as it might not get the semantics of "things" in 8.x right From yanefbsd at gmail.com Thu Jan 8 09:34:37 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Thu Jan 8 09:34:44 2009 Subject: X becomes unresponsive with nvidia / xscreensaver and desktop panics In-Reply-To: <20090108083645.GA56613@freebsd.org> References: <7d6fde3d0901072349i50d04d2ch34f308388c9fd414@mail.gmail.com> <20090108083645.GA56613@freebsd.org> Message-ID: <1A86A687-DA2D-4866-8825-8BBF021F6937@gmail.com> On Jan 8, 2009, at 12:36 AM, Roman Divacky wrote: > On Wed, Jan 07, 2009 at 11:49:26PM -0800, Garrett Cooper wrote: >> Hello folks, >> As many probably know, I recently installed FreeBSD 8-CURRENT on >> my desktop. >> One of the things I'm noting is that when I use dual displays with >> the nvidia driver, and xscreensaver kicks in and keeps going for a >> period of time, the machine's X.org console eats up a core, and >> when I >> try and do anything like gdb Xorg, the system hangs, attempts to >> panic >> (I assume that's the case because I hear it beep and attempt to >> restart), then I have to give it a warm boot. truss(1)'ing Xorg >> showed >> that there were a lot of SIGALARM's being fired and masked. >> This is incredibly reminiscent of the days when I used to >> run Linux and >> I forgot to configure my dump device (doh), but this problem appears >> to be easily reproducible with my environment. I'm fixing that issue >> right now, so I should have a working crashdump soon... >> Just wondering if anyone else has seen this issue, or if it's just >> me >> once again. >> Thanks, > > the nvidia driver keeps my 8-current crashing/deadlocking when > playing video > quite often (once a week?). I have no idea what it causes. > > the code of the driver seems to be done in 5.x times. I believe it > needs > some rehashing as it might not get the semantics of "things" in 8.x > right Hey Roman! Yeah, I'm fine with it being slow, for a little while, as long as it's functional... I do realize that nvidia is still giant locked (ew..), so it might be some nasty resource contention. Are you using Linux emulation support with the driver? Cheers, -Garrett From rdivacky at freebsd.org Thu Jan 8 09:42:23 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Thu Jan 8 09:42:30 2009 Subject: X becomes unresponsive with nvidia / xscreensaver and desktop panics In-Reply-To: <1A86A687-DA2D-4866-8825-8BBF021F6937@gmail.com> References: <7d6fde3d0901072349i50d04d2ch34f308388c9fd414@mail.gmail.com> <20090108083645.GA56613@freebsd.org> <1A86A687-DA2D-4866-8825-8BBF021F6937@gmail.com> Message-ID: <20090108094202.GA83183@freebsd.org> On Thu, Jan 08, 2009 at 01:39:04AM -0800, Garrett Cooper wrote: > On Jan 8, 2009, at 12:36 AM, Roman Divacky wrote: > > >On Wed, Jan 07, 2009 at 11:49:26PM -0800, Garrett Cooper wrote: > >>Hello folks, > >> As many probably know, I recently installed FreeBSD 8-CURRENT on > >>my desktop. > >> One of the things I'm noting is that when I use dual displays with > >>the nvidia driver, and xscreensaver kicks in and keeps going for a > >>period of time, the machine's X.org console eats up a core, and > >>when I > >>try and do anything like gdb Xorg, the system hangs, attempts to > >>panic > >>(I assume that's the case because I hear it beep and attempt to > >>restart), then I have to give it a warm boot. truss(1)'ing Xorg > >>showed > >>that there were a lot of SIGALARM's being fired and masked. > >> This is incredibly reminiscent of the days when I used to > >>run Linux and > >> I forgot to configure my dump device (doh), but this problem appears > >>to be easily reproducible with my environment. I'm fixing that issue > >>right now, so I should have a working crashdump soon... > >> Just wondering if anyone else has seen this issue, or if it's just > >>me > >>once again. > >>Thanks, > > > >the nvidia driver keeps my 8-current crashing/deadlocking when > >playing video > >quite often (once a week?). I have no idea what it causes. > > > >the code of the driver seems to be done in 5.x times. I believe it > >needs > >some rehashing as it might not get the semantics of "things" in 8.x > >right > > > Hey Roman! > Yeah, I'm fine with it being slow, for a little while, as long as > it's functional... I do realize that nvidia is still giant locked I didnt mean it being Giant locked. it's just that some semantic might have changed since 5.x and the driver does not reflect that > (ew..), so it might be some nasty resource contention. > Are you using Linux emulation support with the driver? no.... From christof.schulze at gmx.net Thu Jan 8 11:16:17 2009 From: christof.schulze at gmx.net (Christof Schulze) Date: Thu Jan 8 11:16:24 2009 Subject: Best torrent client/server available for FreeBSD? In-Reply-To: References: Message-ID: <200901081216.07107.christof.schulze@gmx.net> Am Donnerstag 08 Januar 2009 00:04:24 schrieb joe mcguckin: > There's quite a number of implementation in the ports collection. Does > anyone have any options regarding which are the 'best'? Azureus is a good client except for: * high cpou/mem usage * does not work in Freebsd 7.X - not sure about 8 because it will not get any connections so I use trackerbt as a tracker and ktorrent as a client. Christof -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090108/d6e8b8b9/attachment.pgp From ed at 80386.nl Thu Jan 8 11:29:19 2009 From: ed at 80386.nl (Ed Schouten) Date: Thu Jan 8 11:29:27 2009 Subject: Best torrent client/server available for FreeBSD? In-Reply-To: References: Message-ID: <20090108112918.GK45775@hoeg.nl> Hello Joe, * joe mcguckin wrote: > There's quite a number of implementation in the ports collection. Does > anyone have any options regarding which are the 'best'? Have you tried net-p2p/rtorrent? Works pretty well. It's a terminal application, which makes it easy to run in screen(1), for example. -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090108/e30f80e2/attachment.pgp From alexbestms at math.uni-muenster.de Thu Jan 8 11:31:35 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Thu Jan 8 11:31:44 2009 Subject: mouse cursor corrupts chars under syscons Message-ID: hi there, i noticed the mouse cursor currupting characters under syscons. to test this do the following under syscons/bash: for i in `jot 5000`; do echo -n 0; done now gently move your cursor over the zeros. see? alex From ed at 80386.nl Thu Jan 8 11:42:44 2009 From: ed at 80386.nl (Ed Schouten) Date: Thu Jan 8 11:42:51 2009 Subject: mouse cursor corrupts chars under syscons In-Reply-To: References: Message-ID: <20090108114243.GL45775@hoeg.nl> Hello Alexander, * Alexander Best wrote: > i noticed the mouse cursor currupting characters under syscons. to test this > do the following under syscons/bash: > > for i in `jot 5000`; do echo -n 0; done > > now gently move your cursor over the zeros. see? Just a message to the lists, to make sure it doesn't end up assigned to me. This issue is not in any way related to the libteken commit I did a week ago, but I also noticed this issue back in June last year. At first I thought it was related to the new MPSAFE TTY layer, but I can remember seeing this on stock sources as well. I think we should see whether it is also present on other architectures supported by syscons. I think it might be a syscons VGA renderer issue. -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090108/f5771e66/attachment.pgp From lwindschuh at googlemail.com Thu Jan 8 12:39:50 2009 From: lwindschuh at googlemail.com (Lucius Windschuh) Date: Thu Jan 8 12:39:56 2009 Subject: Best torrent client/server available for FreeBSD? In-Reply-To: <4d7dd86f0901071810o65e0bf32m196f120bd0e5748c@mail.gmail.com> References: <4d7dd86f0901071810o65e0bf32m196f120bd0e5748c@mail.gmail.com> Message-ID: <90a5caac0901080439h14aa7c6au59a754ce9c0fdf5c@mail.gmail.com> 2009/1/8 David N : > > I use transmission daemon + transmission web. > You can control it via command line or web interface. transmission is a nice, small client, but be aware that it performs poorly on torrents with many files / many torrents. It uses a hard-coded number of open files: 16. Not more. So, transmission gives you a nice system load by opening and closing many files per second (and the only thing you can do is change the source code :-D) with torrents containing many files. That's why I second Ed and suggest net-p2p/rtorrent. rtorrent hashes files slowly because it uses mmap for this and counts on the kernel to behave like Linux does, but FreeBSD doesn't: On Linux, madvise(..., MADV_WILLNEED) will preload a page, and seemingly, FreeBSD has a different behaviour. That's the simple reason. Nonetheless, rtorrent is small and very efficient. Lucius From christoph.mallon at gmx.de Thu Jan 8 13:03:10 2009 From: christoph.mallon at gmx.de (Christoph Mallon) Date: Thu Jan 8 13:03:16 2009 Subject: mouse cursor corrupts chars under syscons In-Reply-To: References: Message-ID: <4965F348.90407@gmx.de> Alexander Best schrieb: > i noticed the mouse cursor currupting characters under syscons. to test this > do the following under syscons/bash: > > for i in `jot 5000`; do echo -n 0; done > > now gently move your cursor over the zeros. see? What do you mean? When moving the mouse cursor down then its bottom suddenly pops up in a row when it already should be several pixels in that row? From dam at c-mal.com Thu Jan 8 13:05:58 2009 From: dam at c-mal.com (Damien Fleuriot) Date: Thu Jan 8 13:06:05 2009 Subject: Bug or unwanted behaviour in echo ? Message-ID: <57dc0bd10901080437y5f745b4ckf40b48a9d9d55ce8@mail.gmail.com> Hello list, First of all, my apologies if this issue was already raised and discussed, I haven't found it so far. I was toying around with a site that proposed to hash passwords to MD5, and comparing results with my host running FreeBSD 7.0-STABLE At some point I didn't get the same hash from the website and from BSD. On BSD: echo -n "test'$@" | md5 5c28a8c6d799d302f3ef53afefdfc81b On website: f883cdacbb478c241c51da1f67fbe9bf After swapping characters around I realized that echo just interprets $@ (which in our case is null). So I tried escaping the @ which didn't work: echo -n "test'$\@" | md5 cff4781da603112b5a271891c7c9cc47 Escaping the $ did work however: echo -n "test'\$@" | md5 f883cdacbb478c241c51da1f67fbe9bf I can not think of a concrete example at the moment, but I can imagine a program creating a hash and inadvertently feeding md5 a string containing $? , $@ , $# or $1 for example. This could lead to unwanted results. Anyone knows if this behaviour is intended ? It sure confused me here. Perhaps a switch should be added to tell echo to not parse the $variables ? Or perhaps it should be the natural behaviour to not parse them, and only do it if -e was given ? Regards, From jelte at NLnetLabs.nl Thu Jan 8 13:15:34 2009 From: jelte at NLnetLabs.nl (Jelte Jansen) Date: Thu Jan 8 13:15:40 2009 Subject: Bug or unwanted behaviour in echo ? In-Reply-To: <57dc0bd10901080437y5f745b4ckf40b48a9d9d55ce8@mail.gmail.com> References: <57dc0bd10901080437y5f745b4ckf40b48a9d9d55ce8@mail.gmail.com> Message-ID: <4965FC6D.5090403@NLnetLabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Damien Fleuriot wrote: > > After swapping characters around I realized that echo just interprets > $@ (which in our case is null). > that's your shell doing the replacement, not echo. With most most shells you can inhibit this behaviour by using single quotes. Escaping the @ should work in some cases too. $ echo "abc$@" abc $ echo 'abc$@' abc$@ Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkll/G0ACgkQ4nZCKsdOncUSSQCeJuQZi1h+TrKNyxpHmu6hjykO +mAAnjKGHk76zsyTwwaahKbFWHQvjf1E =wJHv -----END PGP SIGNATURE----- From david at catwhisker.org Thu Jan 8 13:49:17 2009 From: david at catwhisker.org (David Wolfskill) Date: Thu Jan 8 13:49:23 2009 Subject: Bug or unwanted behaviour in echo ? In-Reply-To: <57dc0bd10901080437y5f745b4ckf40b48a9d9d55ce8@mail.gmail.com> References: <57dc0bd10901080437y5f745b4ckf40b48a9d9d55ce8@mail.gmail.com> Message-ID: <20090108132202.GD64787@albert.catwhisker.org> On Thu, Jan 08, 2009 at 01:37:06PM +0100, Damien Fleuriot wrote: > ... > I was toying around with a site that proposed to hash passwords to > MD5, and comparing results with my host running FreeBSD 7.0-STABLE > > At some point I didn't get the same hash from the website and from BSD. > > On BSD: > echo -n "test'$@" | md5 > 5c28a8c6d799d302f3ef53afefdfc81b > > On website: > f883cdacbb478c241c51da1f67fbe9bf > > After swapping characters around I realized that echo just interprets > $@ (which in our case is null). Errr... no, I think you will find that what echo saw was actually a string whose md5 hash was "5c28a8c6d799d302f3ef53afefdfc81b". The "$@" was seen as a token by the shell, its value interpolated, and passed along to echo (which may well have been a shell builtin in any case, depending on what shell you were using). That's what escaping the "$" worked. > ... Peace, david -- David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090108/45f4348a/attachment.pgp From rnoland at 2hip.net Thu Jan 8 13:34:34 2009 From: rnoland at 2hip.net (Robert Noland) Date: Thu Jan 8 14:17:16 2009 Subject: Best torrent client/server available for FreeBSD? In-Reply-To: <200901081216.07107.christof.schulze@gmx.net> References: <200901081216.07107.christof.schulze@gmx.net> Message-ID: <1231420618.1810.1.camel@wombat.2hip.net> On Thu, 2009-01-08 at 12:16 +0100, Christof Schulze wrote: > Am Donnerstag 08 Januar 2009 00:04:24 schrieb joe mcguckin: > > There's quite a number of implementation in the ports collection. Does > > anyone have any options regarding which are the 'best'? > Azureus is a good client except for: > * high cpou/mem usage > * does not work in Freebsd 7.X - not sure about 8 because it will not get > any connections Does work on 7 and 8. You need to enable "extra hack" option for it to work well. I guess that I should really make that the default. Also, latest version is net-p2p/vuze. robert. > so I use trackerbt as a tracker and ktorrent as a client. > > Christof -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090108/715dbc6e/attachment.pgp From stefan.lambrev at moneybookers.com Thu Jan 8 14:54:22 2009 From: stefan.lambrev at moneybookers.com (Stefan Lambrev) Date: Thu Jan 8 14:54:29 2009 Subject: Best torrent client/server available for FreeBSD? In-Reply-To: References: Message-ID: <7B865AAF-4E24-4DE8-B4C2-25494F449EFD@moneybookers.com> Greetings, On Jan 8, 2009, at 1:04 AM, joe mcguckin wrote: > There's quite a number of implementation in the ports collection. > Does anyone have any options regarding which are the 'best'? I'm very happy with deluge. But it depends on your needs. For desktop my choice is deluge. > > > Thanks, > > Joe > > > Joe McGuckin > ViaNet Communications > > joe@via.net > 650-207-0372 cell > 650-213-1302 office > 650-969-2124 fax > > > > _______________________________________________ > 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 > " -- Best Wishes, Stefan Lambrev ICQ# 24134177 From bra at fsn.hu Thu Jan 8 14:56:13 2009 From: bra at fsn.hu (Attila Nagy) Date: Thu Jan 8 14:56:22 2009 Subject: pxeboot does not work on Sun X4540 In-Reply-To: References: <4964EB20.5070709@fsn.hu> <4964F9BB.3020407@fsn.hu> Message-ID: <49661409.4090600@fsn.hu> Danny Braniss wrote: >> Attila Nagy wrote: >> >>> Hello, >>> >>> I'm trying to boot FreeBSD 8-CURRENT on a Sun X4540 (2xquad core >>> Opteron, 64 GB memory, 48 SATA disks (in fact 47, the 48th is a write >>> optimized SSD, because this box is a 7210 OpenStorage "appliance", >>> running OpenSolaris) on LSI controllers, nvidia NIC) from our boot >>> server without success. >>> >>> The PXE on the NIC downloads pxeboot with TFTP, but then gets stuck at >>> loading the kernel: >>> http://people.fsn.hu/~bra/freebsd/20090107-freebsd-x4540/Screenshot-6.png >>> >>> pxeboot is configured to load the kernel via NFS (the default) and >>> according to the tcpdump output, the client (X4540) issues an NFS >>> GETPORT call and gets the response from the NFS server and then >>> nothing else happens. >>> >>> I've tried with LOADER_TFTP_SUPPORT=YES and the result is the same, >>> the only difference is that the machine stops sending packets after >>> the first TFTP read request (for /boot/boot.4th.split), which doesn't >>> exist, so the server sends the answer and then nothing comes back from >>> the X4540 box. >>> >>> It seems that it gets to send exactly one packet, then freezes. >>> >>> What else should be done to debug this problem? >>> >>> Thanks, >>> >> BTW, the last FreeBSD 8-CURRENT snapshot from december boots fine (at >> least I can get to sysinstall, I haven't yet tried installation, because >> I wouldn't like to touch the boot drives, which house the OpenSolaris >> image -that's why I want to boot from the net). >> >> > > older pxeboot - pre interrupt handling fixes - work ok, so you can use that > instead. > I thought that I did testing with an older version, but as it turned out I was wrong. Confirmed, older versions work fine. The next problem is that a freshly compiled kernel (HEAD from today) panics with this: http://people.fsn.hu/~bra/freebsd/20090107-freebsd-x4540/Screenshot-55.png "BIOS smap did not include a basemem segment!" which is true, according to the above verbose output and taking a quick look at the code. (in the loop there is only a base=0x0 and len=0x0 entry) I'm not an expert of this topic (too), for me these numbers look pretty strange. Maybe Peter can help? Thanks, From alexbestms at math.uni-muenster.de Thu Jan 8 15:24:55 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Thu Jan 8 15:25:03 2009 Subject: mouse cursor corrupts chars under syscons In-Reply-To: <4965F348.90407@gmx.de> Message-ID: the effect is hard to describe. when moving the cursor over chars you can see that the edges of certain chars flicker. try running the command below. the effect should be quite obvious. i'm using an old fashioned crt monitor. the effect might not be visible on tft displays. i have absolutely no idea what's causing this. but here's a wild guess: from the effect it looks like the mouse cursor is actually made up of a 32x32 or 64x64 pixel square. this square contains the white cursor. apart from the cursor the rest of the square is transparent. it appears the code that calculates the actual pixel-colour-value between the transparent parts of the cursor-square and the cars on syscons has a bug in it. however that's just a wild guess. alex Christoph Mallon schrieb am 2009-01-08: > Alexander Best schrieb: > >i noticed the mouse cursor currupting characters under syscons. to > >test this > >do the following under syscons/bash: > >for i in `jot 5000`; do echo -n 0; done > >now gently move your cursor over the zeros. see? > What do you mean? When moving the mouse cursor down then its bottom > suddenly pops up in a row when it already should be several pixels > in that row? From christoph.mallon at gmx.de Thu Jan 8 16:03:21 2009 From: christoph.mallon at gmx.de (Christoph Mallon) Date: Thu Jan 8 16:03:30 2009 Subject: mouse cursor corrupts chars under syscons In-Reply-To: References: Message-ID: <496623C5.90400@gmx.de> Alexander Best schrieb: > the effect is hard to describe. when moving the cursor over chars you can see > that the edges of certain chars flicker. try running the command below. the > effect should be quite obvious. i'm using an old fashioned crt monitor. the > effect might not be visible on tft displays. > > i have absolutely no idea what's causing this. but here's a wild guess: > > from the effect it looks like the mouse cursor is actually made up of a 32x32 > or 64x64 pixel square. this square contains the white cursor. apart from the > cursor the rest of the square is transparent. it appears the code that > calculates the actual pixel-colour-value between the transparent parts of the > cursor-square and the cars on syscons has a bug in it. > > however that's just a wild guess. Ah! Now I understand what you mean. First I did not see the effect, because I use 80x50 instead of 80x25 and a different font is used there. You see the right border of the "0" flickering when you move the mouse cursor, right? The effect is caused by how video hardware works in textmode and how the mouse cursor magic works. First video hardware in textmode: You see 80x25 chars. The resolution is 720x400 pixels. So every char consists 9x16 pixels. To display a char the video card uses a map with a bitmap for every char. But the bitmap of every char consists only of 16 bytes. So we are missing one bit per line. So there is another trick: Either the 9th column is displayed black (or whatever the background colour is) *or* the 8th column is repeated. What actually happens depends on two registers in the video card, which represent a range. You can set them so that char 213 till 234 (just random example) have their 8th column repeated to the 9th and all others have a black 9th column. Usually "0" is outside of this range, so the 9th column is black. Now how does the mouse cursor magic work: The mouse cursors consists of 2x2 chars. The bitmap for these 4 chars are altered and the codes for the 4 chars are copied to the place where the mouse cursor should appear. Remember: We are in text mode, so you cannot just paint pixels. Everything has to go through the character map. So to make the mouse cursor appear following happens: First the pixel coordinates of the cursor are mapped to the character coordinates. Then the 4 chars there are read and the character maps are copied to the 4 reserved chars. Then the mouse cursor is painted onto these 4 reserved chars. Last the 4 reserved character codes are copied to the screen, so you see the mouse cursor appear. So when you move your mouse onto a "0" you no longer see a "real" 0, but you see another character with the same charmap but the mouse cursor painted on it. Now the 9th column trick: The cursor would have a gap when it is outside the repeat-8th-column range. So the reserved characters are chosen to be in this range, the 8th column is copied and the mouse cursor appears continuous. This is also the reason why the mouse cursor has a "jumping" step when you move it around, just look closely. It is exactly at the right edge of a character. So the 8th column gets copied, but a "0" (and other chars, too) have pixel data in there, which also gets copied and this causes the effect you observe. Long story short: Everything is correct. (: Bonus: You can see the mouse cursor magic at work if you move the reserved character range: Write ABCD on the terminal: echo AB; echo CD Then execute "vidcontrol -M 65". 65 is ASCII A, you can only specify the start of the range. Now you see how the magic works in the four letters ABCD you wrote before. You'll also notice, that the mouse cursor now has a gap, because 65-68 are outside of the repeat-8th-column range. When you now move the mouse over "0" you no longer see the effect you described for the same reason. Use "vidcontrol -M 208" to reset to default. I hope this explanation is helpful for you Christoph From w8hdkim at gmail.com Thu Jan 8 16:35:29 2009 From: w8hdkim at gmail.com (Kim Culhan) Date: Thu Jan 8 16:35:40 2009 Subject: msk Marvell Yukon 88E8038 hangs In-Reply-To: <20090108075159.GH1256@cdnetworks.co.kr> References: <89dbfdc30901071438j314ac431h491f9494593caf64@mail.gmail.com> <20090108011220.GA1256@cdnetworks.co.kr> <89dbfdc30901072336l62c46214i113cccf9985bcdae@mail.gmail.com> <20090108075159.GH1256@cdnetworks.co.kr> Message-ID: <89dbfdc30901080835g67b996f4i50e734f0791a0d56@mail.gmail.com> On Thu, Jan 8, 2009 at 2:51 AM, Pyun YongHyeon wrote: > On Thu, Jan 08, 2009 at 02:36:48AM -0500, Kim Culhan wrote: > > On Wed, Jan 7, 2009 at 8:12 PM, Pyun YongHyeon wrote: > > > On Wed, Jan 07, 2009 at 05:38:28PM -0500, Kim Culhan wrote: > > > > The msk interface on an Acer Aspire 5570Z hangs, frequently when running cvsup. > > > > > > > > Not necessarily at each hang but sometimes coincident, this is > > > > intermittently output to the console: > > > > > > > > in_cksum_skip: out of data by 56952 > > > > > > > > The above is also output to the console at times when receiving a > > > > character through ssh > > > > to a shell. > > > > > > > > The in_cksum_skip messages and msk hangs are also present on this hardware > > > > running 7.1-RELEASE. > > > > > > > > > > Would you show me dmesg output for msk(4)? > > > > dmesg: > > > > mskc0: port 0x2000-0x20ff mem > > 0xd0100000-0xd0103fff irq 16 at device 0.0 on pci2 > > msk0: on mskc0 > > msk0: Ethernet address: 00:1b:24:59:5b:7a > > miibus0: on msk0 > > e1000phy0: PHY 0 on miibus0 > > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > mskc0: [FILTER] > > > > Would you try changes made in r183485(CVS if_msk.c, 1.33)? > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/msk/if_msk.c.diff?r1=1.32;r2=1.33;f=h The version in use is 1.35 dated 11-24-08 from 8.0-current cvsup'd on 1-7-09 This has the changes you have made in the diff from the link above. -- regards -kim From christoph.mallon at gmx.de Thu Jan 8 17:07:50 2009 From: christoph.mallon at gmx.de (Christoph Mallon) Date: Thu Jan 8 17:07:58 2009 Subject: mouse cursor corrupts chars under syscons In-Reply-To: <496623C5.90400@gmx.de> References: <496623C5.90400@gmx.de> Message-ID: <496632D3.5070608@gmx.de> Christoph Mallon schrieb: > What actually happens depends on two registers in the video > card, which represent a range. You can set them so that char 213 till > 234 (just random example) have their 8th column repeated to the 9th and > all others have a black 9th column. I remembered some details wrong. The range of chars, which get their 8th column repeated, is always 0xC0 till 0xDF. There is just one bit to completely deactivate repeating the 8th column. From minimarmot at gmail.com Thu Jan 8 17:11:51 2009 From: minimarmot at gmail.com (Ben Kaduk) Date: Thu Jan 8 17:11:58 2009 Subject: panic: initiate_write_inodeblock_ufs2: already started Message-ID: <47d0403c0901080911n7a364a3o20172ce579619fad@mail.gmail.com> I upgraded a few days ago from a year-old RELENG_7 to a fresh RELENG_7 (right before the 7.1 release, basically), and then started an upgrade to CURRENT but noticed that my gmirror was degraded when booting to single-user. It had been degraded for a few days, corresponding roughly to when I physically moved the machine to a different room. I hesitated for a while before sending this, because there are so many correlated things going on, and it's hard to rule out hardware problems. However, I have now seen this panic a couple times; once, the panic string was interleaved with "ad2: FAILURE - load data" and another where the string was interleaved with "ad0: FAILURE - load data", so I am using the working hypothesis that this failure is not tied to a particular one of the disks. Such sparse data as I have collected is up here: http://stuff.mit.edu/afs/sipb.mit.edu/user/kaduk/freebsd/periphrasis/20090107/panic.txt I have seen three four panics so far; I was in X for the first, and thus have no data for it; the last three are in the above file. I was only able to get to KDB for the middle of the three, and I sadly did not print the panicstr from it, so I'm not sure if it's the same panic as the subject line or not. The machine had just errored about failing to set up DMA for both disks, so I was unable to get a dump :( I'll try to see if I can see if there's a difference between kernel.old and kernel. -Ben Kaduk From alexbestms at math.uni-muenster.de Thu Jan 8 17:13:17 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Thu Jan 8 17:13:25 2009 Subject: patch to fix burncd bug Message-ID: could somebody please commit the following patch to dev/ata? it fixes a nasty bug during fixation in burncd. the bug exists in RELENG6, RELENG7 and HEAD (and maybe RELENG5): http://www.freebsd.org/cgi/query-pr.cgi?prp=95979-3-txt&n=/patch the whole PR can be found here: http://www.freebsd.org/cgi/query-pr.cgi?pr=95979 cheers. alex From barney_cordoba at yahoo.com Thu Jan 8 17:34:48 2009 From: barney_cordoba at yahoo.com (Barney Cordoba) Date: Thu Jan 8 17:34:55 2009 Subject: Adding a new kernel module? Message-ID: <321406.5257.qm@web63908.mail.re1.yahoo.com> I'm testing a new kernel module that needs to be compiled in, and everything works fine except that make doesn't make the module for the new driver. The driver is under dev /sys/dev/foo How does the kernel make system decide what modules to build? How can I add a new kernel modules to the build system to get it to build the new module automatically? Thanks, Barney From mike at jellydonut.org Thu Jan 8 17:35:57 2009 From: mike at jellydonut.org (Michael Proto) Date: Thu Jan 8 17:36:05 2009 Subject: patch to fix burncd bug In-Reply-To: References: Message-ID: <1de79840901080935s130f647r36815df468a9220b@mail.gmail.com> On Thu, Jan 8, 2009 at 12:13 PM, Alexander Best < alexbestms@math.uni-muenster.de> wrote: > could somebody please commit the following patch to dev/ata? it fixes a > nasty > bug during fixation in burncd. the bug exists in RELENG6, RELENG7 and HEAD > (and maybe RELENG5): > > http://www.freebsd.org/cgi/query-pr.cgi?prp=95979-3-txt&n=/patch > > the whole PR can be found here: > http://www.freebsd.org/cgi/query-pr.cgi?pr=95979 > > I second this request. A fix would be nice, this bug has bitten me in both 7-STABLE and 8-CURRENT :) -Proto From yanefbsd at gmail.com Thu Jan 8 17:37:20 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Thu Jan 8 17:37:28 2009 Subject: snd_hda(4): getting line-in to work In-Reply-To: <49649333.6060902@gmail.com> References: <7d6fde3d0901061032n72e9d0c4refe3c695f441c827@mail.gmail.com> <4963C4C0.6000509@FreeBSD.org> <7d6fde3d0901062029j694d63c1h66c52dfbb80c13d8@mail.gmail.com> <49647602.9060402@FreeBSD.org> <49649333.6060902@gmail.com> Message-ID: <7d6fde3d0901080937t29ec42f5i6684b9223d0b368a@mail.gmail.com> On Wed, Jan 7, 2009 at 3:34 AM, Garrett Cooper wrote: > Alexander Motin wrote: >> >> Garrett Cooper wrote: >>> >>> On Tue, Jan 6, 2009 at 12:53 PM, Alexander Motin wrote: >>>> >>>> Garrett Cooper wrote: >>>>> >>>>> I'm not sure if it's user error or not, but my snd_hda(4) enabled >>>>> chipset doesn't have line-in support enabled. I was wondering if there >>>>> were a special set of instructions I need to follow to get this >>>>> working. >>>> >>>> The main instruction is to boot system with verbose messages. snd_hda >>>> writes >>>> all information needed to answer most questions. Read it yourself and if >>>> it >>>> does not help - send it to me. >>>> >>>>> [gcooper@orangebox /scratch/ltp]$ cat /dev/sndstat >>>>> FreeBSD Audio Driver (newpcm: 32bit 2007061600/i386) >>>>> Installed devices: >>>>> pcm0: at cad 0 nid 1 on >>>>> hdac0 [MPSAFE] (1p:1v/1r:1v channels duplex default) >>>> >>>> All I can see here is that you have some recording device. You can >>>> browse >>>> and select specific recording source with `mixer =rec` command. For >>>> additional details look verbose output and read new snd_hda man page. >>>> >>>>> pcm1: at cad 0 nid 1 on >>>>> hdac0 [MPSAFE] (1p:1v/0r:0v channels) >>>>> pcm2: at cad 0 nid 1 on >>>>> hdac0 [MPSAFE] (1p:1v/0r:0v channels) >>>> >>>> -- >>>> Alexander Motin >>> >>> Trying with the instructions on the manpage actually disabled my >>> sound... then again I probably screwed up the settings (I believe it >>> was noted as pcm2 before??). >>> >>> Here're the device.hints entries and I attached the -v boot log >>> snippet for the card: >> >> In attached log you have missed one of very interesting parts while >> grepping: pcmX devices output prints sound processing paths within codec for >> every PCM device. Look it first before doing something. >> >>> hint.hdac.0.cad0.nid17.config="as=1seq=0 device=Headphones" >>> hint.hdac.0.cad0.nid18.config="as=2seq=0 device=Line-out" >>> hint.hdac.0.cad0.nid19.config="as=3seq=0 device=Speaker" >>> hint.hdac.0.cad0.nid20.config="as=4seq=0 device=Mic" >>> hint.hdac.0.cad0.nid21.config="as=5seq=0 device=Line-in" >>> hint.hdac.0.cad0.nid22.config="as=6seq=0 device=Line-out" >>> hint.hdac.0.cad0.nid23.config="as=6seq=0 device=Mic" >>> hint.hdac.0.cad0.nid24.config="as=6seq=0 device=CD" >>> hint.hdac.0.cad0.nid36.config="as=5seq=0 device=Line-out" >>> hint.hdac.0.cad0.nid37.config="as=6seq=0 device=Line-out" >> >> Except lack of speces between fields there is also lack of any sense. I >> don't understand what was you trying to do, but it will not work: >> - you configured nid 21 and nid 36 as association five, but made one of >> them input and other output. It is incorrect, association may include only >> pins of one direction (in/out); >> - association 6 is the same; >> - nid 19 has connectivity "None", so it will not be used by driver. >> It is all described in manual. >> >> Actually I think default configuration is quite reasonable. There is some >> things that can be tuned, but you should first understand what you have and >> how it works. > > Honestly, I feel as if I'm staring at a jigsaw puzzle all in pieces right > now, trying to sort out what's going on -- I've never truly played with > device.hints(5) before... > I'll look at the PCM entries and try to finally sort this out... > Thanks, > -Garrett Alexander, Ok, I got stuck again. Can you possibly push me in the right direction (complete verbose dmesg attached)? The line-in and SPDIF (not so much of a concern) are the only issues that I'm aware of. I'll have to open up my case and wire up the front ports in order to test them for you. Also, the knobs that show up in xfce4-mixer are completely useless for snd_hda(4) (every time I move the sliders it sets the volume back to 0). Is this a known issue? Thanks, -Garrett -------------- next part -------------- A non-text attachment was scrubbed... Name: dmesg.today Type: application/octet-stream Size: 63412 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090108/5dbad9ff/dmesg-0001.obj From sam at freebsd.org Thu Jan 8 17:39:19 2009 From: sam at freebsd.org (Sam Leffler) Date: Thu Jan 8 17:39:28 2009 Subject: X becomes unresponsive with nvidia / xscreensaver and desktop panics In-Reply-To: <7d6fde3d0901072349i50d04d2ch34f308388c9fd414@mail.gmail.com> References: <7d6fde3d0901072349i50d04d2ch34f308388c9fd414@mail.gmail.com> Message-ID: <49663A42.7010101@freebsd.org> Garrett Cooper wrote: > Hello folks, > As many probably know, I recently installed FreeBSD 8-CURRENT on my desktop. > One of the things I'm noting is that when I use dual displays with > the nvidia driver, and xscreensaver kicks in and keeps going for a > period of time, the machine's X.org console eats up a core, and when I > try and do anything like gdb Xorg, the system hangs, attempts to panic > (I assume that's the case because I hear it beep and attempt to > restart), then I have to give it a warm boot. truss(1)'ing Xorg showed > that there were a lot of SIGALARM's being fired and masked. > This is incredibly reminiscent of the days when I used to run Linux and > I forgot to configure my dump device (doh), but this problem appears > to be easily reproducible with my environment. I'm fixing that issue > right now, so I should have a working crashdump soon... > Just wondering if anyone else has seen this issue, or if it's just me > once again. > I have been battling with the nvidia binary driver on HEAD for a long time. I've got a Quadro NVS card: vgapci0@pci0:1:0:0: class=0x030000 card=0x019010de chip=0x018a10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'Quadro NVS with AGP 8x [NV18GL.2]' class = display subclass = VGA and run the older port because the card support was yanked at some point: nvidia-driver-96.43.07 NVidia graphics card binary drivers for hardware OpenGL ren I run dual-dvi displays w/ xinerama. I have not seen panics but I do see unacceptable performance. The most obvious problems are impossible mouse and rendering lag. I also see large memory consumption when running something like firefox w/ lots of hidden/off-screen images in a page (e.g. p4web). I am now 100% certain the nvidia driver is at fault as I swapped in an ATI card over the holiday break and the change was like night and day. Unfortunately the xrandr support for the ATI card was too busted to use so I gave up and stuck the nvidia card back in the box (for those that care the card is a Radeon 9600 and the problem is that after a while one display would blank randomly). This is a dual-core AMD (i386) desktop but performance actually dropped when I went from UP to SMP which makes me believe there's something braindead in the nvidia driver. The problems have only gotten worse as FreeBSD has evolved. I've not replaced the video card because I need dual-dvi in an AGP format which is rare these days. Moving to PCIE means a new mb/box which I'm trying to avoid. Sam From ed at 80386.nl Thu Jan 8 17:55:58 2009 From: ed at 80386.nl (Ed Schouten) Date: Thu Jan 8 17:56:05 2009 Subject: Bug or unwanted behaviour in echo ? In-Reply-To: <57dc0bd10901080437y5f745b4ckf40b48a9d9d55ce8@mail.gmail.com> References: <57dc0bd10901080437y5f745b4ckf40b48a9d9d55ce8@mail.gmail.com> Message-ID: <20090108175553.GQ45775@hoeg.nl> Hello Damien, If you want to see what actually happens when you run those echo commands, you can run: echo -n "foobarbaz" | hexdump -C Or you can use xxd(1). Good luck! -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090108/09355573/attachment.pgp From gavin at FreeBSD.org Thu Jan 8 18:16:12 2009 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Thu Jan 8 18:16:20 2009 Subject: Adding a new kernel module? In-Reply-To: <321406.5257.qm@web63908.mail.re1.yahoo.com> References: <321406.5257.qm@web63908.mail.re1.yahoo.com> Message-ID: <1231438568.98820.7.camel@buffy.york.ac.uk> On Thu, 2009-01-08 at 09:08 -0800, Barney Cordoba wrote: > I'm testing a new kernel module that needs to be compiled in, and > everything works fine except that make doesn't make the module for the > new driver. The driver is under dev > > /sys/dev/foo > > How does the kernel make system decide what modules to build? How can > I add a new kernel modules to the build system to get it to build the > new module automatically? Short answer: have a look at /usr/src/sys/modules/Makefile and the directories below that. It might be a little out of date, but have a look at http://www.freebsd.org/doc/en/books/arch-handbook/driverbasics-kld.html Gavin From sziszi at bsd.hu Thu Jan 8 18:48:59 2009 From: sziszi at bsd.hu (Szilveszter Adam) Date: Thu Jan 8 18:49:06 2009 Subject: Adding a new kernel module? In-Reply-To: <321406.5257.qm@web63908.mail.re1.yahoo.com> References: <321406.5257.qm@web63908.mail.re1.yahoo.com> Message-ID: <20090108180838.GA3094@baranyfelhocske.buza.adamsfamily.xx> Hello Barney, On Thu, Jan 08, 2009 at 09:08:07AM -0800, Barney Cordoba wrote: > I'm testing a new kernel module that needs to be compiled in, and everything works fine except that make doesn't make the module for the new driver. The driver is under dev > > /sys/dev/foo > > How does the kernel make system decide what modules to build? How can I add a new kernel modules to the build system to get it to build the new module automatically? This is quite easy. You should make a new directory under sys/modules with the module name, prepare a Makefile there (you can use one of the many existing ones in the other module directories as example). This Makefile should contain all files that your driver uses, and any specific flags that are used for compilation. Again, you will find many simple and more complicated examples among the existing modules. After this, you should add the new subdir to the Makefile in sys/modules (the order is alphabetical now, but you can add it anywhere). I believe that's all. Hope this helps. -- Regards: Szilveszter ADAM Budapest Hungary From mav at FreeBSD.org Thu Jan 8 19:11:18 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Thu Jan 8 19:11:25 2009 Subject: snd_hda(4): getting line-in to work In-Reply-To: <7d6fde3d0901080937t29ec42f5i6684b9223d0b368a@mail.gmail.com> References: <7d6fde3d0901061032n72e9d0c4refe3c695f441c827@mail.gmail.com> <4963C4C0.6000509@FreeBSD.org> <7d6fde3d0901062029j694d63c1h66c52dfbb80c13d8@mail.gmail.com> <49647602.9060402@FreeBSD.org> <49649333.6060902@gmail.com> <7d6fde3d0901080937t29ec42f5i6684b9223d0b368a@mail.gmail.com> Message-ID: <49664FD8.1060700@FreeBSD.org> Garrett Cooper wrote: > Ok, I got stuck again. Can you possibly push me in the right > direction (complete verbose dmesg attached)? The line-in and SPDIF > (not so much of a concern) are the only issues that I'm aware of. I'll > have to open up my case and wire up the front ports in order to test > them for you. Ok. Let's stop for a moment and start from the beginning, because now it is already like a puzzle for me too. Let me explain once more what I see you have and then you explain me where is your problem. You have 3 PCM devices configured: - pcm0: 7.1 playback via 4 rear jacks (Green, Black, Orange and Grey) + record from mic (front Pink), line (rear Blue), monitor (second mic, rear Pink), cd (internal Black) or mix (sum of all these). - pcm1: stereo playback via front Green jack. - pcm2: SPDIF output As for me, this configuration is correct and good enough. You can record from your line-in via pcm0 after selecting that source via `mixer =rec line` command. You can playback via SPDIF by using pcm2 device. So what's wrong? What are you doing and what is not working and how? > Also, the knobs that show up in xfce4-mixer are completely useless > for snd_hda(4) (every time I move the sliders it sets the volume back > to 0). Is this a known issue? You are the first. -- Alexander Motin From Manfred.Knick at T-Online.de Thu Jan 8 19:45:02 2009 From: Manfred.Knick at T-Online.de (Manfred_Knick) Date: Thu Jan 8 19:56:02 2009 Subject: possibility of a "severe flaw in the logic of FreeBSD's kernel handling multiple host bridges ..." Message-ID: <496651ED.8080102@T-Online.de> First: Congratulations upon 7.1 final RELEASE ! On Fri, 24 Oct 2008, I pointed out the "possibility of a severe flaw in the logic of FreeBSD's kernel handling multiple host bridges and the corresponding assignment of (in principle, correctly detected) devices to their host bridges" :: --> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/128331 :: --> http://forums.freebsd.org/showthread.php?t=236 but unfortunately, I did not get any response at all. Two mails to "kensmith@cse.Buffalo.EDU" asking for any contact e-mail address of a FreeBSD Kernel developer knowing his way around host-bridges and PCI-devices also gave no reaction. I am sorry for this noise (I would have preferred to handle this more quietly), but finally I take hope to the advice of Daniel Gerzo (Thanks @ danger): "If you will not receive any feedback I would recommend you to send an email to current@ and stable@ mailing lists. PR's sometimes get lost in the traffic and not all developers are checking GNATS all the time." Looking forward to a contact Kind regards Manfred From rizzo at iet.unipi.it Thu Jan 8 20:57:22 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Thu Jan 8 20:57:28 2009 Subject: reduce directories in sys/modules ? Message-ID: <20090108210221.GA87253@onelab2.iet.unipi.it> Is there a way to reduce the number of directories in sys/modules ? There seems to be one directory per module, even though many of those are related and the source resides in one place (e.g. sys/modules/iwifw/ has three children but the source is in sys/contrib/dev/iwi ; and the same goes for many other entries e.g. sys/modules/digi* <-> /sys/dev/digi, sys/modules/drm <-> sys/dev/drm sys/modules/ata and many more. Ideas ? cheers luigi From rizzo at iet.unipi.it Thu Jan 8 22:17:49 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Thu Jan 8 22:17:57 2009 Subject: reduce directories in sys/modules ? In-Reply-To: <4966756E.7050102@elischer.org> References: <20090108210221.GA87253@onelab2.iet.unipi.it> <4966756E.7050102@elischer.org> Message-ID: <20090108222250.GA90051@onelab2.iet.unipi.it> On Thu, Jan 08, 2009 at 01:51:42PM -0800, Julian Elischer wrote: > Luigi Rizzo wrote: > >Is there a way to reduce the number of directories in sys/modules ? > > > >There seems to be one directory per module, even though many of > >those are related and the source resides in one place > >(e.g. sys/modules/iwifw/ has three children but the source > >is in sys/contrib/dev/iwi ; and the same goes for many other > >entries e.g. > >sys/modules/digi* <-> /sys/dev/digi, > >sys/modules/drm <-> sys/dev/drm > >sys/modules/ata > > > >and many more. > >Ideas ? > > I have many under netgraph. > maybe we could cluster them by type. > ethernet > protocols > or does that not help what you want? yes, i wanted something like that: one directory per cluster (of course where it makes sense to pack stuff). Take e.g. /sys/dev/ata (but there are many similar cases) which has 24 files and generates 15 different directories, each one with only one Makefile containing the same thing # $FreeBSD: ... $ .PATH: ${.CURDIR}/../../../dev/ata KMOD= atasomething SRCS= ata-some-thing.c SRCS+= opt_ata.h ata_if.h device_if.h bus_if.h pci_if.h .include It would be a lot simpler to have one dir and one Makefile in /sys/modules/ata/Makefile with this content # $FreeBSD: ... $ common_headers= opt_ata.h ata_if.h device_if.h bus_if.h KMOD_LIST= atafoo atabar atabaz atadisc ataata atapci... SRCS_atafoo= ata-some-foo.c ${common_headers} SRCS_atabar= ata-bar-src.c ${common_headers} ... .include This would be backward compatible with the existing structure, provided that the bsd.kmod.mk expands the entries in KMOD_LIST creating the individual targets etc. cheers luigi From julian at elischer.org Thu Jan 8 22:19:50 2009 From: julian at elischer.org (Julian Elischer) Date: Thu Jan 8 22:19:58 2009 Subject: reduce directories in sys/modules ? In-Reply-To: <20090108210221.GA87253@onelab2.iet.unipi.it> References: <20090108210221.GA87253@onelab2.iet.unipi.it> Message-ID: <4966756E.7050102@elischer.org> Luigi Rizzo wrote: > Is there a way to reduce the number of directories in sys/modules ? > > There seems to be one directory per module, even though many of > those are related and the source resides in one place > (e.g. sys/modules/iwifw/ has three children but the source > is in sys/contrib/dev/iwi ; and the same goes for many other > entries e.g. > sys/modules/digi* <-> /sys/dev/digi, > sys/modules/drm <-> sys/dev/drm > sys/modules/ata > > and many more. > Ideas ? I have many under netgraph. maybe we could cluster them by type. ethernet protocols or does that not help what you want? > > cheers > luigi > _______________________________________________ > 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 rizzo at iet.unipi.it Thu Jan 8 22:48:15 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Thu Jan 8 22:48:22 2009 Subject: kldpatch updated (Re: RFC: new utility, kmodpatch) In-Reply-To: <20090101183026.GA15385@onelab2.iet.unipi.it> References: <20090101183026.GA15385@onelab2.iet.unipi.it> Message-ID: <20090108225316.GA91026@onelab2.iet.unipi.it> Hi, I have updated and renamed the "kldpatch" utility (formerly kmodpatch), so that now it can also patch the disk copy of modules (or kernel). You can find the updated version at the following URL http://info.iet.unipi.it/~luigi/FreeBSD/20090108-kldpatch.tgz A description of what it can do is below (old posting attached for convenience). The manpage in the tarball is more up-to-date. cheers luigi On Thu, Jan 01, 2009 at 07:30:26PM +0100, 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 > . From sam at freebsd.org Thu Jan 8 22:59:07 2009 From: sam at freebsd.org (Sam Leffler) Date: Thu Jan 8 22:59:14 2009 Subject: reduce directories in sys/modules ? In-Reply-To: <20090108210221.GA87253@onelab2.iet.unipi.it> References: <20090108210221.GA87253@onelab2.iet.unipi.it> Message-ID: <4966853A.70605@freebsd.org> Luigi Rizzo wrote: > Is there a way to reduce the number of directories in sys/modules ? > > There seems to be one directory per module, even though many of > those are related and the source resides in one place > (e.g. sys/modules/iwifw/ has three children but the source > is in sys/contrib/dev/iwi ; and the same goes for many other > entries e.g. > sys/modules/digi* <-> /sys/dev/digi, > sys/modules/drm <-> sys/dev/drm > sys/modules/ata > > and many more. > Ideas ? > Perhaps you should start by saying why you want to change this? Sam From ohartman at mail.zedat.fu-berlin.de Thu Jan 8 23:00:11 2009 From: ohartman at mail.zedat.fu-berlin.de (O. Hartmann) Date: Thu Jan 8 23:08:23 2009 Subject: X becomes unresponsive with nvidia / xscreensaver and desktop panics In-Reply-To: <1A86A687-DA2D-4866-8825-8BBF021F6937@gmail.com> References: <7d6fde3d0901072349i50d04d2ch34f308388c9fd414@mail.gmail.com> <20090108083645.GA56613@freebsd.org> <1A86A687-DA2D-4866-8825-8BBF021F6937@gmail.com> Message-ID: <4966859E.7080301@mail.zedat.fu-berlin.de> Garrett Cooper wrote: > On Jan 8, 2009, at 12:36 AM, Roman Divacky wrote: > >> On Wed, Jan 07, 2009 at 11:49:26PM -0800, Garrett Cooper wrote: >>> Hello folks, >>> As many probably know, I recently installed FreeBSD 8-CURRENT on >>> my desktop. >>> One of the things I'm noting is that when I use dual displays with >>> the nvidia driver, and xscreensaver kicks in and keeps going for a >>> period of time, the machine's X.org console eats up a core, and when I >>> try and do anything like gdb Xorg, the system hangs, attempts to panic >>> (I assume that's the case because I hear it beep and attempt to >>> restart), then I have to give it a warm boot. truss(1)'ing Xorg showed >>> that there were a lot of SIGALARM's being fired and masked. >>> This is incredibly reminiscent of the days when I used to run >>> Linux and >>> I forgot to configure my dump device (doh), but this problem >>> appears >>> to be easily reproducible with my environment. I'm fixing that issue >>> right now, so I should have a working crashdump soon... >>> Just wondering if anyone else has seen this issue, or if it's >>> just me >>> once again. >>> Thanks, >> >> the nvidia driver keeps my 8-current crashing/deadlocking when >> playing video >> quite often (once a week?). I have no idea what it causes. >> >> the code of the driver seems to be done in 5.x times. I believe it needs >> some rehashing as it might not get the semantics of "things" in 8.x >> right > > > Hey Roman! > Yeah, I'm fine with it being slow, for a little while, as long as > it's functional... I do realize that nvidia is still giant locked > (ew..), so it might be some nasty resource contention. > Are you using Linux emulation support with the driver? > Cheers, > -Garrett > _______________________________________________ > 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" I have and I had the same in FreeBSD 7.0/7.1 and now with 8.0-CUR with both a NV8600GTS and an older NV6800GT. A very old NV6600 never showed up these lockings when I used that PCIe-Card with FreeBSD 7.0/7.1, but I'm not sure. The locks came spontanous, sometimes after heavy usage of 'mplayer', but sometimes instantanously after the destop showed up. On those boxes, there is no Linux emulation and no Linux BLOB (useless, due to 64 Bit). I swapped the 'nv' driver on all FreeBSD boxes with 'vesa', because there is another issue with sprites/graphics buffers many times reported using FireFox. When the display got locked, sometimes I had the chance opening a ssh session killing Xorg/xdm and restarting working, but by the end, that was when changing towards 8.0-CUR, this 'trick' didn't work anymore. On FBSD 7, Xorg was eating up 100% CPU time. From keramida at freebsd.org Thu Jan 8 23:14:09 2009 From: keramida at freebsd.org (Giorgos Keramidas) Date: Thu Jan 8 23:14:41 2009 Subject: patch to fix burncd bug In-Reply-To: (Alexander Best's message of "Thu, 08 Jan 2009 18:13:14 +0100 (CET)") References: Message-ID: <87prixz9ne.fsf@kobe.laptop> On Thu, 08 Jan 2009 18:13:14 +0100 (CET), Alexander Best wrote: > could somebody please commit the following patch to dev/ata? it fixes > a nasty bug during fixation in burncd. the bug exists in RELENG6, > RELENG7 and HEAD (and maybe RELENG5): > > http://www.freebsd.org/cgi/query-pr.cgi?prp=95979-3-txt&n=/patch > > the whole PR can be found here: > http://www.freebsd.org/cgi/query-pr.cgi?pr=95979 I think Soren is the best person to look into this bug (Cc: added). Soren, what do you think? Does the patch at bin/95979 look like a nice change to commit? I just saw this PR so I haven't tried the patch on my laptop's CURRENT yet, but I can confirm that burning CD-ROMs and DVDs is busted in my laptop for a few weeks now. From ohartman at mail.zedat.fu-berlin.de Thu Jan 8 23:07:35 2009 From: ohartman at mail.zedat.fu-berlin.de (O. Hartmann) Date: Thu Jan 8 23:22:22 2009 Subject: gcc 4.3: when will it become standard compiler? Message-ID: <49668763.8020705@mail.zedat.fu-berlin.de> When will gcc 4.3 incorporated in FreeBSD 8 and become the standard compiler suite? We figured out that gcc 4.3 does have a speed gain in some numerical code of 3 - 8 % and I guess we can use this in the basic OS as well ... Regards, Oliver From rizzo at iet.unipi.it Thu Jan 8 23:23:25 2009 From: rizzo at iet.unipi.it (Luigi Rizzo) Date: Thu Jan 8 23:23:32 2009 Subject: reduce directories in sys/modules ? In-Reply-To: <4966853A.70605@freebsd.org> References: <20090108210221.GA87253@onelab2.iet.unipi.it> <4966853A.70605@freebsd.org> Message-ID: <20090108232825.GA91454@onelab2.iet.unipi.it> On Thu, Jan 08, 2009 at 02:59:06PM -0800, Sam Leffler wrote: > Luigi Rizzo wrote: > >Is there a way to reduce the number of directories in sys/modules ? > > > >There seems to be one directory per module, even though many of > >those are related and the source resides in one place ... > Perhaps you should start by saying why you want to change this? Because I find it overcomplicated and error prone to force one directory per module. There are many examples of closely related modules whose source live in a single directory whereas the module infrastructure consumes a large subtree. I don't want to put every module in one Makefile, but at least the related ones sometimes do deserve a merge. I already mentioned ata with 15 children, iwifw with 3 entries, netgraph with over 50 children, geom has several too... The problems that I see are: + very easy to forget to update one or more entries when creating or modifying the makefiles; + redundancy in the content of the Makefiles -- e.g. often times related modules share headers and other Makefile variables that right now we need to repeat in every Makefile (and given that the hierarchy is not clear, children Makefiles cannot inherit from the parent's Makefile) + confusion with the names and the hierarchy: sometimes the children are at the same level as the parent (e.g. modules/wlan and modules/wlan_*), sometimes a child replicates a parent's name (modules/ata/ata) sometimes there is a repeated prefix (modules/geom/geom_*) and sometimes there is not (e.g. modules/netgraph/*) I know that kmod.mk is quite large and touching it is perhaps non trivial, but if there is at least agreement on what is the direction we might find someone who wants to work on this. cheers luigi From roberto at keltia.freenix.fr Thu Jan 8 23:33:12 2009 From: roberto at keltia.freenix.fr (Ollivier Robert) Date: Thu Jan 8 23:33:19 2009 Subject: gcc 4.3: when will it become standard compiler? In-Reply-To: <49668763.8020705@mail.zedat.fu-berlin.de> References: <49668763.8020705@mail.zedat.fu-berlin.de> Message-ID: <20090108233311.GA69883@keltia.freenix.fr> According to O. Hartmann: > When will gcc 4.3 incorporated in FreeBSD 8 and become the standard > compiler suite? We figured out that gcc 4.3 does have a speed gain in > some numerical code of 3 - 8 % and I guess we can use this in the basic > OS as well ... I'd rather have llvm instead... -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr Dons / donation Ondine : http://ondine.keltia.net/ From alexbestms at math.uni-muenster.de Fri Jan 9 00:00:25 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Fri Jan 9 00:00:32 2009 Subject: fix tools/tools/usb/print-usb-if-vids.sh Message-ID: here's a fix to make tools/tools/usb/print-usb-if-vids.sh work again. the file hasn't been touched in over 4 years. ;) alex -------------- next part -------------- A non-text attachment was scrubbed... Name: printusbifvids.sh.diff Type: application/octet-stream Size: 391 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090109/ff8a7e65/printusbifvids.sh.obj From sgk at troutmask.apl.washington.edu Fri Jan 9 00:21:33 2009 From: sgk at troutmask.apl.washington.edu (Steve Kargl) Date: Fri Jan 9 00:21:49 2009 Subject: gcc 4.3: when will it become standard compiler? In-Reply-To: <49668763.8020705@mail.zedat.fu-berlin.de> References: <49668763.8020705@mail.zedat.fu-berlin.de> Message-ID: <20090109002133.GA92874@troutmask.apl.washington.edu> On Fri, Jan 09, 2009 at 12:08:19AM +0100, O. Hartmann wrote: > When will gcc 4.3 incorporated in FreeBSD 8 and become the standard > compiler suite? We figured out that gcc 4.3 does have a speed gain in > some numerical code of 3 - 8 % and I guess we can use this in the basic > OS as well ... > Probably not for a very long time. gcc 4.3 requires both GMP and MPFR libraries. Neither library is in src. gcc 4.3 is also subject to the GPLv3 license. This may have a negative impact on contributions from commercial entities such as Juniper. Is there a problem with using port/lang/gcc43? -- Steve From rnoland at FreeBSD.org Fri Jan 9 00:24:16 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Fri Jan 9 00:24:23 2009 Subject: possibility of a "severe flaw in the logic of FreeBSD's kernel handling multiple host bridges ..." In-Reply-To: <496651ED.8080102@T-Online.de> References: <496651ED.8080102@T-Online.de> Message-ID: <1231460648.93079.65.camel@squirrel.corp.cox.com> On Thu, 2009-01-08 at 20:20 +0100, Manfred_Knick wrote: > First: Congratulations upon 7.1 final RELEASE ! > > On Fri, 24 Oct 2008, I pointed out the > > "possibility of a severe flaw in the logic of FreeBSD's kernel > handling multiple host bridges > and the corresponding assignment of > (in principle, correctly detected) > devices to their host bridges" > > :: --> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/128331 > > :: --> http://forums.freebsd.org/showthread.php?t=236 > > but unfortunately, I did not get any response at all. > Two mails to "kensmith@cse.Buffalo.EDU" asking for any contact e-mail > address of a FreeBSD Kernel developer knowing his way around > host-bridges and PCI-devices also gave no reaction. > > I am sorry for this noise > (I would have preferred to handle this more quietly), > but finally I take hope to the advice of Daniel Gerzo (Thanks @ danger): > > "If you will not receive any feedback I would recommend you to send an > email to current@ and stable@ mailing lists. PR's sometimes get lost > in the traffic and not all developers are checking GNATS all the time." > > Looking forward to a contact I'm really not sure that I am the best person to try and tackle this, but it does fall somewhere near me... Can you send me a pciconf -lv. robert. > Kind regards > > Manfred > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090109/e1e0a99c/attachment.pgp From rmtodd at ichotolot.servalan.com Fri Jan 9 01:45:28 2009 From: rmtodd at ichotolot.servalan.com (Richard Todd) Date: Fri Jan 9 01:45:37 2009 Subject: Recent changes to pseudofs causing panics -- leaking a vnode lock? Message-ID: <20090109004853.GA34384@ichotolot.servalan.com> I've noticed that ever since updating to a kernel after the recent changes to the pseudofs code late last month, that I've occasionally gotten the following sort of panic: System call readlink returning with the following locks held: exclusive lockmgr pseudofs (pseudofs) r = 0 (0xffffff00ba581cc8) locked @ /usr/src/sys/fs/pseudofs/pseudofs_vncache.c:193 panic: witness_warn The line in question is the one I marked by an arrow in this chunk of the pfs_vncache_alloc code: if ((pn->pn_flags & PFS_PROCDEP) != 0) (*vpp)->v_vflag |= VV_PROCDEP; pvd->pvd_vnode = *vpp; VN_LOCK_AREC(*vpp); vn_lock(*vpp, LK_EXCLUSIVE | LK_RETRY); <==== this lock here error = insmntque(*vpp, mp); So somehow, a vnode is getting locked here and not getting unlocked. I suspect the code in the retry2: loop later, simply because that's the code that got added in the late December commits, but I'm not clear on how exactly. I've tried littering the code with extra printfs to try to clarify what's going on, but alas, I'm still not really sure what's going on. I do have a good coredump that I can get info out of, if someone can suggest to me what would be useful things to dump. Anyway, here's the patch for the debugging printfs I added, and the console messages produced by those printfs from the most recent coredump/panic. The console msgs do seem to indicate some sort of race condition going on, though, as they seem to show two or more processes simultaneously hitting the pseudofs code and hitting my debugging print statements (alas, making the console log rather a confused mess.) The debugging additions: Index: pseudofs_vncache.c =================================================================== RCS file: /usr/FreeBSDCVS/src/sys/fs/pseudofs/pseudofs_vncache.c,v retrieving revision 1.44 diff -u -r1.44 pseudofs_vncache.c --- pseudofs_vncache.c 29 Dec 2008 13:25:58 -0000 1.44 +++ pseudofs_vncache.c 8 Jan 2009 02:22:50 -0000 @@ -129,6 +129,7 @@ mtx_unlock(&pfs_vncache_mutex); if (vget(vp, LK_EXCLUSIVE | LK_INTERLOCK, curthread) == 0) { ++pfs_vncache_hits; + vprint("XXX vncache 6", vp); *vpp = vp; /* * Some callers cache_enter(vp) later, so @@ -191,7 +192,9 @@ pvd->pvd_vnode = *vpp; VN_LOCK_AREC(*vpp); vn_lock(*vpp, LK_EXCLUSIVE | LK_RETRY); + printf("XXX vncache 1 *vpp=%p\n", *vpp); error = insmntque(*vpp, mp); + printf("XXX vncache 2 *vpp=%p\n", *vpp); if (error != 0) { *vpp = NULLVP; return (error); @@ -211,11 +214,14 @@ mtx_unlock(&pfs_vncache_mutex); if (vget(vp, LK_EXCLUSIVE | LK_INTERLOCK, curthread) == 0) { ++pfs_vncache_hits; + vprint("XXX vncache 3", *vpp); vgone(*vpp); + vprint("XXX vncache 4", *vpp); *vpp = vp; cache_purge(vp); return (0); } + vprint("XXX vncache 5", *vpp); goto retry2; } } Index: pseudofs_vnops.c =================================================================== RCS file: /usr/FreeBSDCVS/src/sys/fs/pseudofs/pseudofs_vnops.c,v retrieving revision 1.72 diff -u -r1.72 pseudofs_vnops.c --- pseudofs_vnops.c 30 Dec 2008 21:49:39 -0000 1.72 +++ pseudofs_vnops.c 6 Jan 2009 23:12:40 -0000 @@ -369,6 +369,7 @@ VOP_UNLOCK(vp, 0); error = pfs_vncache_alloc(mp, dvp, pn, pid); + vprint("XXX vptocnp", *dvp); if (error) { vn_lock(vp, locked | LK_RETRY); vfs_unbusy(mp); @@ -502,6 +503,7 @@ } error = pfs_vncache_alloc(vn->v_mount, vpp, pn, pid); + vprint("XXX lookup", *vpp); if (error) goto failed; and the msgs from the most recent coredump: Script started on Thu Jan 8 18:34:33 2009 You have mail. ichotolot# kgdb kernel.debug /var/crash/vmcore.206 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: XXX vncache 1 *vpp=0xffffff00b0173c30 XXX vncache 2 *vpp=0xffffff00b0173c30 XXX vncache 1 *vpp=0xffffff000d420270XXX vncache 1 *vp p=0xffXfXfX fvfn0cache 2 *vp0c6886750p=0xffffff000d420270 XXX vncache 2 *vpp=0xffffff00c6886750 XXX lookup 0xffffff00c6886750: tag pseudofs, type VLNK usecount 1, writecount 0, refcount 1 mountedhere 0 flags () lock type pseudofs: EXCL by thread 0xffffff00c873e390 (pid 18861) #0 0xffffffff80514c28 at __lockmgr_args+0x758 #1 0xffffffff805a4409 at vop_stdlock+0x39 #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b #3 0xffffffff805bfae7 at _vn_lock+0x57 #4 0xffffffff804ce120 at pfs_vncache_alloc+0x1f0 #5 0xffffffff804cf473 at pfs_lookup+0x273 #6 0xffffffff8083543f at VOP_CACHEDLOOKUP_APV+0xaf #7 0xffffffff805a2220 at vfs_cache_lookup+0xf0 #8 0xffffffff808378a7 at VOP_LOOKUP_APV+0xb7 #9 0xffffffff805a83d3 at lookup+0x513 #10 0xffffffff805a928e at namei+0x53e #11 0xffffffff805b6ffa at kern_readlinkat+0x7a #12 0xffffffff805b7121 at kern_readlink+0x21 #13 0xffffffff807f16b7 at syscall+0x1e7 #14 0xffffffff807d41bb at Xfast_syscall+0xab XXX vncache 3 0xffffff000d420270: tag pseudofs, type VDIR usecount 1, writecount 0, refcount 1 mountedhere 0 flags (VV_ROOT) lock type pseudofs: EXCL by thread 0xffffff0082999390 (pid 18860) #0 0xffffffff80514c28 at __lockmgr_args+0x758 #1 0xffffffff805a4409 at vop_stdlock+0x39 #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b #3 0xffffffff805bfae7 at _vn_lock+0x57 #4 0xffffffff804ce120 at pfs_vncache_alloc+0x1f0 #5 0xffffffff805a885f at lookup+0x99f #6 0xffffffff805a928e at namei+0x53e #7 0xffffffff805b6ffa at kern_readlinkat+0x7a #8 0xffffffff805b7121 at kern_readlink+0x21 #9 0xffffffff807f16b7 at syscall+0x1e7 #10 0xffffffff807d41bb at Xfast_syscall+0xab XXX vncache 4 0xffffff000d420270: tag none, type VBAD usecount 1, writecount 0, refcount 1 mountedhere 0 flags (VV_ROOT|VI_DOOMED) lock type pseudofs: EXCL by thread 0xffffff0082999390 (pid 18860) #0 0xffffffff80514c28 at __lockmgr_args+0x758 #1 0xffffffff805a4409 at vop_stdlock+0x39 #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b #3 0xffffffff805bfae7 at _vn_lock+0x57 #4 0xffffffff804ce120 at pfs_vncache_alloc+0x1f0 #5 0xffffffff805a885f at lookup+0x99f #6 0xffffffff805a928e at namei+0x53e #7 0xffffffff805b6ffa at kern_readlinkat+0x7a #8 0xffffffff805b7121 at kern_readlink+0x21 #9 0xffffffff807f16b7 at syscall+0x1e7 #10 0xffffffff807d41bb at Xfast_syscall+0xab XXX vncache 6 0xffffff00c6886750: tag pseudofs, type VLNK usecount 1, writecount 0, refcount 1 mountedhere 0 flags () lock type pseudofs: EXCL by thread 0xffffff0082999390 (pid 18860) #0 0xffffffff80514c28 at __lockmgr_args+0x758 #1 0xffffffff805a4409 at vop_stdlock+0x39 #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b #3 0xffffffff805bfae7 at _vn_lock+0x57 #4 0xffffffff805b3fdb at vget+0x8b #5 0xffffffff804cdfe8 at pfs_vncache_alloc+0xb8 #6 0xffffffff804cf473 at pfs_lookup+0x273 #7 0xffffffff8083543f at VOP_CACHEDLOOKUP_APV+0xaf #8 0xffffffff805a2220 at vfs_cache_lookup+0xf0 #9 0xffffffff808378a7 at VOP_LOOKUP_APV+0xb7 #10 0xffffffff805a83d3 at lookup+0x513 #11 0xffffffff805a928e at namei+0x53e #12 0xffffffff805b6ffa at kern_readlinkat+0x7a #13 0xffffffff805b7121 at kern_readlink+0x21 #14 0xffffffff807f16b7 at syscall+0x1e7 #15 0xffffffff807d41bb at Xfast_syscall+0xab XXX lookup 0xffffff00c6886750: tag pseudofs, type VLNK usecount 1, writecount 0, refcount 1 mountedhere 0 flags () lock type pseudofs: EXCL by thread 0xffffff0082999390 (pid 18860) #0 0xffffffff80514c28 at __lockmgr_args+0x758 #1 0xffffffff805a4409 at vop_stdlock+0x39 #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b #3 0xffffffff805bfae7 at _vn_lock+0x57 #4 0xffffffff805b3fdb at vget+0x8b #5 0xffffffff804cdfe8 at pfs_vncache_alloc+0xb8 #6 0xffffffff804cf473 at pfs_lookup+0x273 #7 0xffffffff8083543f at VOP_CACHEDLOOKUP_APV+0xaf #8 0xffffffff805a2220 at vfs_cache_lookup+0xf0 #9 0xffffffff808378a7 at VOP_LOOKUP_APV+0xb7 #10 0xffffffff805a83d3 at lookup+0x513 #11 0xffffffff805a928e at namei+0x53e #12 0xffffffff805b6ffa at kern_readlinkat+0x7a #13 0xffffffff805b7121 at kern_readlink+0x21 #14 0xffffffff807f16b7 at syscall+0x1e7 #15 0xffffffff807d41bb at Xfast_syscall+0xab XXX vncache 1 *vpp=0xffffff007af74270 XXX vncache 2 *vpp=0xffffff007af74270 XXX lookup 0xffffff007af74270: tag pseudofs, type VDIR usecount 1, writecount 0, refcount 1 mountedhere 0 flags (VV_PROCDEP) lock type pseudofs: EXCL by thread 0xffffff00c873e390 (pid 18861) #0 0xffffffff80514c28 at __lockmgr_args+0x758 #1 0xffffffff805a4409 at vop_stdlock+0x39 #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b #3 0xffffffff805bfae7 at _vn_lock+0x57 #4 0xffffffff804ce120 at pfs_vncache_alloc+0x1f0 #5 0xffffffff804cf473 at pfs_lookup+0x273 #6 0xffffffff8083543f at VOP_CACHEDLOOKUP_APV+0xaf #7 0xffffffff805a2220 at vfs_cache_lookup+0xf0 #8 0xffffffff808378a7 at VOP_LOOKUP_APV+0xb7 #9 0xffffffff805a83d3 at lookup+0x513 #10 0xffffffff805a928e at namei+0x53e #11 0xffffffff805b6ffa at kern_readlinkat+0x7a #12 0xffffffff805b7121 at kern_readlink+0x21 #13 0xffffffff807f16b7 at syscall+0x1e7 #14 0xffffffff807d41bb at Xfast_syscall+0xab XXX vncache 1 *vpp=0xffffff00cd4719c0 XXX vncache 2 *vpp=0xffffff00cd4719c0 XXX lookup 0xffffff00cd4719c0: tag pseudofs, type VLNK usecount 1, writecount 0, refcount 1 mountedhere 0 flags (VV_PROCDEP) lock type pseudofs: EXCL by thread 0xffffff00c873e390 (pid 18861) #0 0xffffffff80514c28 at __lockmgr_args+0x758 #1 0xffffffff805a4409 at vop_stdlock+0x39 #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b #3 0xffffffff805bfae7 at _vn_lock+0x57 #4 0xffffffff804ce120 at pfs_vncache_alloc+0x1f0 #5 0xffffffff804cf473 at pfs_lookup+0x273 #6 0xffffffff8083543f at VOP_CACHEDLOOKUP_APV+0xaf #7 0xffffffff805a2220 at vfs_cache_lookup+0xf0 #8 0xffffffff808378a7 at VOP_LOOKUP_APV+0xb7 #9 0xffffffff805a83d3 at lookup+0x513 #10 0xffffffff805a928e at namei+0x53e #11 0xffffffff805b6ffa at kern_readlinkat+0x7a #12 0xffffffff805b7121 at kern_readlink+0x21 #13 0xffffffff807f16b7 at syscall+0x1e7 #14 0xffffffff807d41bb at Xfast_syscall+0xab XXX vncache 6 0xffffff00b0173c30: tag pseudofs, type VDIR usecount 2, writecount 0, refcount 3 mountedhere 0 flags (VV_ROOT) lock type pseudofs: EXCL by thread 0xffffff00c625bab0 (pid 18865) #0 0xffffffff80514c28 at __lockmgr_args+0x758 #1 0xffffffff805a4409 at vop_stdlock+0x39 #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b #3 0xffffffff805bfae7 at _vn_lock+0x57 #4 0xffffffff805b3fdb at vget+0x8b #5 0xffffffff804cdfe8 at pfs_vncache_alloc+0xb8 #6 0xffffffff805a885f at lookup+0x99f #7 0xffffffff805a928e at namei+0x53e #8 0xffffffff805b6ffa at kern_readlinkat+0x7a #9 0xffffffff805b7121 at kern_readlink+0x21 #10 0xffffffff807f16b7 at syscall+0x1e7 #11 0xffffffff807d41bb at Xfast_syscall+0xab XXX vncache 6 0xffffff00c6886750: tag pseudofs, type VLNK usecount 1, writecount 0, refcount 1 mountedhere 0 flags () lock type pseudofs: EXCL by thread 0xffffff00c625bab0 (pid 18865) #0 0xffffffff80514c28 at __lockmgr_args+0x758 #1 0xffffffff805a4409 at vop_stdlock+0x39 #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b #3 0xffffffff805bfae7 at _vn_lock+0x57 #4 0xffffffff805b3fdb at vget+0x8b #5 0xffffffff804cdfe8 at pfs_vncache_alloc+0xb8 #6 0xffffffff804cf473 at pfs_lookup+0x273 #7 0xffffffff8083543f at VOP_CACHEDLOOKUP_APV+0xaf #8 0xffffffff805a2220 at vfs_cache_lookup+0xf0 #9 0xffffffff808378a7 at VOP_LOOKUP_APV+0xb7 #10 0xffffffff805a83d3 at lookup+0x513 #11 0xffffffff805a928e at namei+0x53e #12 0xffffffff805b6ffa at kern_readlinkat+0x7a #13 0xffffffff805b7121 at kern_readlink+0x21 #14 0xffffffff807f16b7 at syscall+0x1e7 #15 0xffffffff807d41bb at Xfast_syscall+0xab XXX lookup 0xffffff00c6886750: tag pseudofs, type VLNK usecount 1, writecount 0, refcount 1 mountedhere 0 flags () lock type pseudofs: EXCL by thread 0xffffff00c625bab0 (pid 18865) #0 0xffffffff80514c28 at __lockmgr_args+0x758 #1 0xffffffff805a4409 at vop_stdlock+0x39 #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b #3 0xffffffff805bfae7 at _vn_lock+0x57 #4 0xffffffff805b3fdb at vget+0x8b #5 0xffffffff804cdfe8 at pfs_vncache_alloc+0xb8 #6 0xffffffff804cf473 at pfs_lookup+0x273 #7 0xffffffff8083543f at VOP_CACHEDLOOKUP_APV+0xaf #8 0xffffffff805a2220 at vfs_cache_lookup+0xf0 #9 0xffffffff808378a7 at VOP_LOOKUP_APV+0xb7 #10 0xffffffff805a83d3 at lookup+0x513 #11 0xffffffff805a928e at namei+0x53e #12 0xffffffff805b6ffa at kern_readlinkat+0x7a #13 0xffffffff805b7121 at kern_readlink+0x21 #14 0xffffffff807f16b7 at syscall+0x1e7 #15 0xffffffff807d41bb at Xfast_syscall+0xab XXX vncache 1 *vpp=0xffffff0053e7a750 XXX vncache 2 *vpp=0xffffff0053e7a750 XXX lookup 0xffffff0053e7a750: tag pseudofs, type VDIR usecount 1, writecount 0, refcount 1 mountedhere 0 flags (VV_PROCDEP) lock type pseudofs: EXCL by thread 0xffffff0082999390 (pid 18860) #0 0xffffffff80514c28 at __lockmgr_args+0x758 #1 0xffffffff805a4409 at vop_stdlock+0x39 #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b #3 0xffffffff805bfae7 at _vn_lock+0x57 #4 0xffffffff804ce120 at pfs_vncache_alloc+0x1f0 #5 0xffffffff804cf473 at pfs_lookup+0x273 #6 0xffffffff8083543f at VOP_CACHEDLOOKUP_APV+0xaf #7 0xffffffff805a2220 at vfs_cache_lookup+0xf0 #8 0xffffffff808378a7 at VOP_LOOKUP_APV+0xb7 #9 0xffffffff805a83d3 at lookup+0x513 #10 0xffffffff805a928e at namei+0x53e #11 0xffffffff805b6ffa at kern_readlinkat+0x7a #12 0xffffffff805b7121 at kern_readlink+0x21 #13 0xffffffff807f16b7 at syscall+0x1e7 #14 0xffffffff807d41bb at Xfast_syscall+0xab XXX vncache 1 *vpp=0xffffff00429cb4e0XXX vncache 1 *vpp=0xffffff007a92a750 XXX vncache 2 *vpp=0xffffff00429cb4e0 XXX vncache 2 *vpp=0xffffff007a92a750 XXX lookup XXX lookup 0xffffff00429cb4e0: 0xffffff007a92a750: tag pseudofs, type VLNKtag pseudofs, type VDIR usecount 1, writecount 0, refcount 1 mountedhere 0 usecount 1, writecount 0, refcount 1 mountedhere 0 flags (VV_PROCDEP) flags (VV_PROCDEP) lock type ps eudofs: EXCL by thrleoacdk type0 pseudofs: EXCL by xftfhfrfefafd0 0829099x3f9f0 f(pid 18860)fff00c625bab0 (pid 18865) #0 0xffffffff80514c28 at __lockmgr_args+0x758#0 0xffffffff80514c28 at __lockmgr_args+0x758 #1 0xffffffff805a4409 at vop_stdlock+0x39 #1 0xffffffff805a4409 at vop_stdlock+0x39 #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b#2 0xffffffff808369db at VOP_LOCK1_APV+0x9b #3 0xffffffff805bfae7 at _vn_lock+0x57 #3 0xffffffff805bfae7 at _vn_lock+0x57 #4 0xffffffff804ce120 at pfs_vncache_alloc+0x1f0 #4 0xffffffff804ce120 at pfs_vncache_alloc+0x1f0 #5 0x#f5f ffff0fxff8f0f4fcff473 at pfs_lookffufp8+004xc2f7473 at pfs_lookup+30x273 #6 0xffffffff8083543f at VOP_CACHEDLOOKUP_APV+0xaf#6 0xffffffff8083543f at VOP_CACHEDLOOKUP_APV+0xaf #7 0xffffffff805a2220 at vfs_cache_lookup+0xf0#7 0xffffffff805a2220 at vf s_cache_lookup+0xf0 #8 0xffffffff808378a7 at VOP_LOOKUP_APV+0xb7#8 0xffffffff808378 a7 at VOP_LOOKUP_APV+0xb7 #9 0xffffffff805a83d3 at lookup+0x513 #9 0xffffffff805a83d3 at lookup+0x513 #10 0xffffff#ff8105a928e at namei+00 x53e0xffffffff805a928e at namei+0x53e #11 0xffffffff805b6ffa at kern_readlinkat+0x7a#11 0xffffffff805b6ffa at kern_readlinkat+0x7a #12 0xffffffff805b7121 at kern_readlink+0x21#12 0xffffffff805b7121 at ker n_readlink+0x21 #13 0xffffffff807f16b7 at syscall+0x1e7 #13 0xffffffff807f16b7 at syscall+0x1e7 #14 0xffffffff807d41bb at Xfast_syscall+0xab XXX vncache 1 *vpp=0xffffff007a357750#14 0xffffffff807d41bb at Xfast_syscall+0xab XXX vncache 2 *vpp=0xffffff007a357750 XXX looku p 0xffffff007a357750: tag pseudofs, type VLNKSystem call readlink returning usecount 1, writecount 0, refcount 1 mountedhere 0 with the following flags (VV_PROCDEP) locks held: exclusive lockmgr pseudofs lock type pseudofs: EXCL by thread 0xffffff00c625b a(b0 (ppid seu1d8865)ofs) r = 0 (0xffffff000d420308) locked @ /usr/src/sys/fs/pseudofs/pseudofs_vncache.c:194 panic: witness_warn cpuid = 0 KDB: enter: panic Physical memory: 4012 MB Dumping 2401 MB: 2386 2370 2354 2338 2322 2306 2290 2274 2258 2242 2226 2210 2194 2178 2162 2146 2130 2114 2098 2082 2066 2050 2034 2018 2002 1986 1970 1954 1938 1922 1906 1890 1874 1858 1842 1826 1810 1794 1778 1762 1746 1730 1714 1698 1682 1666 1650 1634 1618 1602 1586 1570 1554 1538 1522 1506 1490 1474 1458 1442 1426 1410 1394 1378 1362 1346 1330 1314 1298 1282 1266 1250 1234 1218 1202 1186 1170 1154 1138 1122 1106 1090 1074 1058 1042 1026 1010 994 978 962 946 930 914 898 882 866 850 834 818 802 786 770 754 738 722 706 690 674 658 642 626 610 594 578 562 546 530 514 498 482 466 450 434 418 402 386 370 354 338 322 306 290 274 258 242 226 210 194 178 162 146 130 114 98 82 66 50 34 18 2 Reading symbols from /boot/kernel/zfs.ko...done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/geom_mirror.ko...done. Loaded symbols for /boot/kernel/geom_mirror.ko Reading symbols from /boot/kernel/snd_hda.ko...done. Loaded symbols for /boot/kernel/snd_hda.ko Reading symbols from /boot/kernel/sound.ko...done. Loaded symbols for /boot/kernel/sound.ko Reading symbols from /boot/kernel/coretemp.ko...done. Loaded symbols for /boot/kernel/coretemp.ko Reading symbols from /boot/kernel/atapicam.ko...done. Loaded symbols for /boot/kernel/atapicam.ko Reading symbols from /boot/kernel/tmpfs.ko...done. Loaded symbols for /boot/kernel/tmpfs.ko Reading symbols from /boot/kernel/linux.ko...done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /usr/local/modules/fuse.ko...done. Loaded symbols for /usr/local/modules/fuse.ko Reading symbols from /boot/modules/cpu.ko...done. Loaded symbols for /boot/modules/cpu.ko Reading symbols from /boot/kernel/green_saver.ko...done. Loaded symbols for /boot/kernel/green_saver.ko Reading symbols from /boot/kernel/radeon.ko...done. Loaded symbols for /boot/kernel/radeon.ko Reading symbols from /boot/kernel/drm.ko...done. Loaded symbols for /boot/kernel/drm.ko Reading symbols from /boot/kernel/nullfs.ko...done. Loaded symbols for /boot/kernel/nullfs.ko Reading symbols from /boot/kernel/linprocfs.ko...done. Loaded symbols for /boot/kernel/linprocfs.ko #0 doadump () at pcpu.h:196 196 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); (kgdb)  p    bt #0 doadump () at pcpu.h:196 #1 0xffffffff801c752c in db_fncall (dummy1=Variable "dummy1" is not available. ) at /usr/src/sys/ddb/db_command.c:548 #2 0xffffffff801c7861 in db_command (last_cmdp=0xffffffff80b547a0, cmd_table=Variable "cmd_table" is not available. ) at /usr/src/sys/ddb/db_command.c:445 #3 0xffffffff801c7ab0 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0xffffffff801c9a59 in db_trap (type=Variable "type" is not available. ) at /usr/src/sys/ddb/db_main.c:229 #5 0xffffffff80558fd5 in kdb_trap (type=3, code=0, tf=0xffffffff2d73e840) at /usr/src/sys/kern/subr_kdb.c:534 #6 0xffffffff807f1e14 in trap (frame=0xffffffff2d73e840) at /usr/src/sys/amd64/amd64/trap.c:533 #7 0xffffffff807d3fae in calltrap () at /usr/src/sys/amd64/amd64/exception.S:217 #8 0xffffffff805591ad in kdb_enter (why=0xffffffff808d5179 "panic", msg=0x1
) at cpufunc.h:63 #9 0xffffffff80529c5b in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:559 #10 0xffffffff8056c41e in witness_warn (flags=Variable "flags" is not available. ) at /usr/src/sys/kern/subr_witness.c:1655 #11 0xffffffff807f175e in syscall (frame=0xffffffff2d73ec90) at /usr/src/sys/amd64/amd64/trap.c:965 #12 0xffffffff807d41bb in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:338 #13 0x0000000018c1ec1c in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) fr 11 #11 0xffffffff807f175e in syscall (frame=0xffffffff2d73ec90) at /usr/src/sys/amd64/amd64/trap.c:965 965 WITNESS_WARN(WARN_PANIC, NULL, "System call %s returning", (kgdb) p td $1 = (struct thread *) 0xffffff0082999390 (kgdb) p td->td_proc $2 = (struct proc *) 0xffffff0082ae4880 (kgdb) p td->td_proc[0] $3 = {p_list = {le_next = 0xffffff00c82e6440, le_prev = 0xffffff007ac31000}, p_threads = {tqh_first = 0xffffff0082999390, tqh_last = 0xffffff00829993a0}, p_slock = {lock_object = {lo_name = 0xffffffff808d3982 "process slock", lo_flags = 720896, lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}, p_ucred = 0xffffff0010b4ec00, p_fd = 0xffffff00bdaac400, p_fdtol = 0x0, p_stats = 0xffffff0082a83c00, p_limit = 0xffffff000ef56c00, p_limco = { c_links = {sle = {sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0x0}}, c_time = 0, c_arg = 0x0, c_func = 0, c_lock = 0xffffff0082ae4978, c_flags = 0, c_cpu = 0}, p_sigacts = 0xffffff00290e1000, p_flag = 268451840, p_state = PRS_NORMAL, p_pid = 18860, p_hash = {le_next = 0x0, le_prev = 0xfffffffe4023fd60}, p_pglist = {le_next = 0x0, le_prev = 0xffffff007ac57948}, p_pptr = 0xffffff007ac57880, p_sibling = {le_next = 0x0, le_prev = 0xffffff007ac57970}, p_children = {lh_first = 0x0}, p_mtx = { lock_object = {lo_name = 0xffffffff808d3975 "process lock", lo_flags = 21168128, lo_data = 0, lo_witness = 0xfffffffe4021a400}, mtx_lock = 4}, p_ksi = 0xffffff000515e000, p_sigqueue = {sq_signals = { __bits = {0, 0, 0, 0}}, sq_kill = {__bits = {0, 0, 0, 0}}, sq_list = { tqh_first = 0x0, tqh_last = 0xffffff0082ae49c0}, sq_proc = 0xffffff0082ae4880, sq_flags = 1}, p_oppid = 0, p_vmspace = 0xffffff0082315d38, p_swtick = 10457673, p_realtimer = { it_interval = {tv_sec = 0, tv_usec = 0}, it_value = {tv_sec = 0, tv_usec = 0}}, p_ru = {ru_utime = {tv_sec = 0, tv_usec = 0}, ru_stime = { tv_sec = 0, tv_usec = 0}, ru_maxrss = 0, ru_ixrss = 0, ru_idrss = 0, ru_isrss = 0, ru_minflt = 0, ru_majflt = 0, ru_nswap = 0, ru_inblock = 0, ru_oublock = 0, ru_msgsnd = 0, ru_msgrcv = 0, ru_nsignals = 0, ru_nvcsw = 0, ru_nivcsw = 0}, p_rux = {rux_runtime = 0, rux_uticks = 0, rux_sticks = 0, rux_iticks = 0, rux_uu = 0, rux_su = 0, rux_tu = 0}, p_crux = {rux_runtime = 0, rux_uticks = 0, rux_sticks = 0, rux_iticks = 0, rux_uu = 0, rux_su = 0, rux_tu = 0}, p_profthreads = 0, p_exitthreads = 0, p_traceflag = 0, p_tracevp = 0x0, p_tracecred = 0x0, p_textvp = 0xffffff001b02a750, p_lock = 0 '\0', p_sigiolst = { slh_first = 0x0}, p_sigparent = 20, p_sig = 0, p_code = 0, p_stops = 0, p_stype = 0, p_step = 0 '\0', p_pfsflags = 0 '\0', p_nlminfo = 0x0, p_aioinfo = 0x0, p_singlethread = 0x0, p_suspcount = 0, p_xthread = 0x0, p_boundary_count = 0, p_pendingcnt = 0, p_itimers = 0x0, p_magic = 3203398350, p_osrel = 800054, p_comm = "perl\000l", '\0' , p_pgrp = 0xffffff000b06ec00, p_sysent = 0xffffffff80b30320, p_args = 0xffffff00bdceda80, p_cpulimit = 9223372036854775807, p_nice = 0 '\0', p_fibnum = 0, p_xstat = 0, p_klist = {kl_list = {slh_first = 0x0}, kl_lock = 0xffffffff805008a0 , kl_unlock = 0xffffffff805008c0 , kl_locked = 0xffffffff80501ba0 , kl_lockarg = 0xffffff0082ae4978}, p_numthreads = 1, p_md = , p_itcallout = {c_links = {sle = {sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0x0}}, c_time = 0, c_arg = 0x0, c_func = 0, c_lock = 0x0, c_flags = 16, c_cpu = 0}, p_acflag = 0, p_peers = 0x0, p_leader = 0xffffff0082ae4880, p_emuldata = 0x0, p_label = 0x0, p_sched = 0xffffff0082ae4cc0, p_ktr = {stqh_first = 0x0, stqh_last = 0xffffff0082ae4c90}, p_mqnotifier = {lh_first = 0x0}, p_dtrace = 0x0, p_pwait = {cv_description = 0xffffffff808d42c2 "ppwait", cv_waiters = 0}} (kgdb)  p *td $4 = {td_lock = 0xffffffff80b91680, td_proc = 0xffffff0082ae4880, td_plist = { tqe_next = 0x0, tqe_prev = 0xffffff0082ae4890}, td_runq = { tqe_next = 0xffffff000549d720, tqe_prev = 0xffffffff80b918c8}, td_slpq = { tqe_next = 0x0, tqe_prev = 0xffffff000721e190}, td_lockq = { tqe_next = 0x0, tqe_prev = 0xffffffff2cb3f750}, td_cpuset = 0xffffff000288cdc8, td_sel = 0xffffff0082f7bb00, td_sleepqueue = 0xffffff000721e190, td_turnstile = 0xffffff0005469900, td_umtxq = 0xffffff008284b500, td_tid = 100316, td_sigqueue = {sq_signals = { __bits = {0, 0, 0, 0}}, sq_kill = {__bits = {0, 0, 0, 0}}, sq_list = { tqh_first = 0x0, tqh_last = 0xffffff0082999430}, sq_proc = 0xffffff0082ae4880, sq_flags = 1}, td_flags = 4, td_inhibitors = 0, td_pflags = 0, td_dupfd = 0, td_sqqueue = 0, td_wchan = 0x0, td_wmesg = 0x0, td_lastcpu = 0 '\0', td_oncpu = 0 '\0', td_owepreempt = 0 '\0', td_tsqueue = 0 '\0', td_locks = 1, td_rw_rlocks = 0, td_lk_slocks = 0, td_blocked = 0x0, td_lockname = 0x0, td_contested = { lh_first = 0x0}, td_sleeplocks = 0xffffffff80cebd40, td_intr_nesting_level = 0, td_pinned = 1, td_ucred = 0xffffff0010b4ec00, td_estcpu = 0, td_slptick = 0, td_ru = {ru_utime = {tv_sec = 0, tv_usec = 0}, ru_stime = {tv_sec = 0, tv_usec = 0}, ru_maxrss = 2044, ru_ixrss = 48, ru_idrss = 3352, ru_isrss = 512, ru_minflt = 186, ru_majflt = 0, ru_nswap = 0, ru_inblock = 0, ru_oublock = 0, ru_msgsnd = 0, ru_msgrcv = 0, ru_nsignals = 0, ru_nvcsw = 13, ru_nivcsw = 13}, td_incruntime = 61985988, td_runtime = 61985988, td_pticks = 3, td_sticks = 4, td_iticks = 0, td_uticks = 0, td_uuticks = 0, td_usticks = 0, td_intrval = 0, td_oldsigmask = {__bits = {0, 0, 0, 0}}, td_sigmask = {__bits = {0, 0, 0, 0}}, td_generation = 26, td_sigstk = { ss_sp = 0x0, ss_size = 0, ss_flags = 4}, td_xsig = 0, td_profil_addr = 0, td_profil_ticks = 0, td_name = "perl\000l", '\0' , td_fpop = 0x0, td_dbgflags = 0, td_osd = {osd_nslots = 0, osd_slots = 0x0, osd_next = {le_next = 0x0, le_prev = 0x0}}, td_rqindex = 32 ' ', td_base_pri = 128 '\200', td_priority = 128 '\200', td_pri_class = 3 '\003', td_user_pri = 129 '\201', td_base_user_pri = 129 '\201', td_pcb = 0xffffffff2d73ed50, td_state = TDS_RUNNING, td_retval = {23, 1023}, td_slpcallout = {c_links = {sle = {sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0xffffffff0031d340}}, c_time = 9773098, c_arg = 0xffffff0082999390, c_func = 0xffffffff80561850 , c_lock = 0x0, c_flags = 16, c_cpu = 0}, td_frame = 0xffffffff2d73ec90, td_kstack_obj = 0xffffff00c83a7c80, td_kstack = 18446744070177140736, td_kstack_pages = 4, td_altkstack_obj = 0x0, td_altkstack = 0, td_altkstack_pages = 0, td_critnest = 1, td_md = {md_spinlock_count = 0, md_saved_flags = 70}, td_sched = 0xffffff00829996f0, td_ar = 0x0, td_syscalls = 1517973, td_lprof = {{lh_first = 0x0}, {lh_first = 0x0}}, td_dtrace = 0x0, td_errno = 0} (kgdb) p td  *td->td_lock $5 = {lock_object = {lo_name = 0xffffffff80b922d8 "sched lock 0", lo_flags = 720896, lo_data = 0, lo_witness = 0x0}, mtx_lock = 4} (kgdb) q ichotolot# From bms at FreeBSD.org Fri Jan 9 01:50:56 2009 From: bms at FreeBSD.org (Bruce M. Simpson) Date: Fri Jan 9 01:51:03 2009 Subject: bsdtar fan In-Reply-To: <4965927D.1060507@freebsd.org> References: <4965927D.1060507@freebsd.org> Message-ID: <4966A9AB.2040802@FreeBSD.org> Off topic: Tim, thank you for bsdtar. I recently had to muck around with ISO images on a debian box, and mounting them all would have been prohibitive. Thanks to bsdtar, I could just extract the files I needed, without using loopback mounts. That was invaluable. thank you! From andrew-freebsd at areilly.bpc-users.org Fri Jan 9 03:12:05 2009 From: andrew-freebsd at areilly.bpc-users.org (Andrew Reilly) Date: Fri Jan 9 03:12:13 2009 Subject: gcc 4.3: when will it become standard compiler? In-Reply-To: <20090108233311.GA69883@keltia.freenix.fr> References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090108233311.GA69883@keltia.freenix.fr> Message-ID: <20090109031147.GB44317@duncan.reilly.home> On Fri, Jan 09, 2009 at 12:33:11AM +0100, Ollivier Robert wrote: > According to O. Hartmann: > > When will gcc 4.3 incorporated in FreeBSD 8 and become the standard > > compiler suite? We figured out that gcc 4.3 does have a speed gain in > > some numerical code of 3 - 8 % and I guess we can use this in the basic > > OS as well ... > > I'd rather have llvm instead... I wouldn't mind that, either. I've got the llvm port installed myself, in preparation for doing some experiments of my own, but haven't tried using it to build the kernel or user-land (or even any of the ports). Has anyone given it a go? Is it missing any crucial features? I believe that it had different (or no?) support for PIC code generation, which could affect the ability to do shared libraries, but recent release notes seem to indicate that that's been addressed. There's also someone working on a BSD-licenced retooling (ANSI/ISO-ification) of the PCC compiler, which is getting close to being useful as a system compiler, I believe. (http://www.ludd.ltu.se/~ragge/pcc/ in ports/lang/pcc) In any case, performance gains on numerical code have almost zero bearing on performance of "operating system" code -- no floating point in kernel for starters, and hardly any time spent in loops, either... Cheers, -- Andrew From yanefbsd at gmail.com Fri Jan 9 05:44:04 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Fri Jan 9 05:44:11 2009 Subject: Fwd: X becomes unresponsive with nvidia / xscreensaver and desktop panics In-Reply-To: <7d6fde3d0901082143xb1fb1acj6a0579a844a10bc3@mail.gmail.com> References: <7d6fde3d0901072349i50d04d2ch34f308388c9fd414@mail.gmail.com> <20090108083645.GA56613@freebsd.org> <1A86A687-DA2D-4866-8825-8BBF021F6937@gmail.com> <4966859E.7080301@mail.zedat.fu-berlin.de> <20090109025218.GA44317@duncan.reilly.home> <7d6fde3d0901082143xb1fb1acj6a0579a844a10bc3@mail.gmail.com> Message-ID: <7d6fde3d0901082144q4ecc989do7a57948a96b8bd74@mail.gmail.com> On Thu, Jan 8, 2009 at 6:52 PM, Andrew Reilly wrote: > On Fri, Jan 09, 2009 at 12:00:46AM +0100, O. Hartmann wrote: >> Garrett Cooper wrote: >> > On Jan 8, 2009, at 12:36 AM, Roman Divacky wrote: >> > >> >> On Wed, Jan 07, 2009 at 11:49:26PM -0800, Garrett Cooper wrote: >> >>> One of the things I'm noting is that when I use dual displays with >> >>> the nvidia driver, and xscreensaver kicks in and keeps going for a >> >>> period of time, the machine's X.org console eats up a core, and when I >> >>> try and do anything like gdb Xorg, the system hangs, attempts to panic >> >>> (I assume that's the case because I hear it beep and attempt to >> >>> restart), then I have to give it a warm boot. truss(1)'ing Xorg showed >> >>> that there were a lot of SIGALARM's being fired and masked. > > Straight up: I can't help with this particular OP's quesiton, > just have a comment, further down. > >> I have and I had the same in FreeBSD 7.0/7.1 and now with 8.0-CUR with >> both a NV8600GTS and an older NV6800GT. A very old NV6600 never showed >> up these lockings when I used that PCIe-Card with FreeBSD 7.0/7.1, but >> I'm not sure. The locks came spontanous, sometimes after heavy usage of >> 'mplayer', but sometimes instantanously after the destop showed up. >> >> On those boxes, there is no Linux emulation and no Linux BLOB (useless, >> due to 64 Bit). I swapped the 'nv' driver on all FreeBSD boxes with >> 'vesa', because there is another issue with sprites/graphics buffers >> many times reported using FireFox. > > I have had terrible trouble with an NV6800 card on my AMD64 > machine and a 1600x1200 LCD display. I mostly had to use the > vesa driver, becauase sometimes the nv driver would just fail > to initialize the card properly, and it would be just black, > or wrong frequencies/jumbled: it was a mess. Vesa worked, > but generally didn't let me go beyond 1280x1024. When nv was > (occasionally) working I had the firefox bug surface. > > I've commented about this on the lists (and on usenet) before, > so I thought that I'd better also mention, for the record, that > I have completely solved the problem by replacing that card with > an inexpensive ATI card that the radionhd driver recognizes as > "RV635" based. Should have done it long ago... Everything > appears to work perfectly, now. > > Cheers, > > Andrew Ok, well given the feedback (what I was kind of fishing for), I'll gladly start talking to some nVidia folks about reproducing these issues and bugfixing their driver. Another datapoint: when it doesn't lock up, Xorg dies mysteriously after some hours use. I'm running XFCE4, but I'm wondering a) what desktops folks are running that have had issues, and b) what the configurations are. That way we can better tie down the problem at hand. Replacing my 8800GTS with a lower grade nVidia card isn't going to cut it -- I don't like workarounds that cost most money and create more spare hardware that I don't use :). Thanks! -Garrett From pyunyh at gmail.com Fri Jan 9 06:10:43 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Fri Jan 9 06:10:50 2009 Subject: msk Marvell Yukon 88E8038 hangs In-Reply-To: <89dbfdc30901080835g67b996f4i50e734f0791a0d56@mail.gmail.com> References: <89dbfdc30901071438j314ac431h491f9494593caf64@mail.gmail.com> <20090108011220.GA1256@cdnetworks.co.kr> <89dbfdc30901072336l62c46214i113cccf9985bcdae@mail.gmail.com> <20090108075159.GH1256@cdnetworks.co.kr> <89dbfdc30901080835g67b996f4i50e734f0791a0d56@mail.gmail.com> Message-ID: <20090109061032.GF30747@cdnetworks.co.kr> On Thu, Jan 08, 2009 at 11:35:28AM -0500, Kim Culhan wrote: > On Thu, Jan 8, 2009 at 2:51 AM, Pyun YongHyeon wrote: > > On Thu, Jan 08, 2009 at 02:36:48AM -0500, Kim Culhan wrote: > > > On Wed, Jan 7, 2009 at 8:12 PM, Pyun YongHyeon wrote: > > > > On Wed, Jan 07, 2009 at 05:38:28PM -0500, Kim Culhan wrote: > > > > > The msk interface on an Acer Aspire 5570Z hangs, frequently when running cvsup. > > > > > > > > > > Not necessarily at each hang but sometimes coincident, this is > > > > > intermittently output to the console: > > > > > > > > > > in_cksum_skip: out of data by 56952 > > > > > > > > > > The above is also output to the console at times when receiving a > > > > > character through ssh > > > > > to a shell. > > > > > > > > > > The in_cksum_skip messages and msk hangs are also present on this hardware > > > > > running 7.1-RELEASE. > > > > > > > > > > > > > Would you show me dmesg output for msk(4)? > > > > > > dmesg: > > > > > > mskc0: port 0x2000-0x20ff mem > > > 0xd0100000-0xd0103fff irq 16 at device 0.0 on pci2 > > > msk0: on mskc0 > > > msk0: Ethernet address: 00:1b:24:59:5b:7a > > > miibus0: on msk0 > > > e1000phy0: PHY 0 on miibus0 > > > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > > mskc0: [FILTER] > > > > > > > Would you try changes made in r183485(CVS if_msk.c, 1.33)? > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/msk/if_msk.c.diff?r1=1.32;r2=1.33;f=h > > The version in use is 1.35 dated 11-24-08 from 8.0-current cvsup'd on 1-7-09 > > This has the changes you have made in the diff from the link above. > Ok, then how about disabling TSO/Tx checksum offload? (eg. ifconfig msk0 -tso -txcsum) -- Regards, Pyun YongHyeon From andrew-freebsd at areilly.bpc-users.org Fri Jan 9 06:53:54 2009 From: andrew-freebsd at areilly.bpc-users.org (Andrew Reilly) Date: Fri Jan 9 06:54:05 2009 Subject: X becomes unresponsive with nvidia / xscreensaver and desktop panics In-Reply-To: <4966859E.7080301@mail.zedat.fu-berlin.de> References: <7d6fde3d0901072349i50d04d2ch34f308388c9fd414@mail.gmail.com> <20090108083645.GA56613@freebsd.org> <1A86A687-DA2D-4866-8825-8BBF021F6937@gmail.com> <4966859E.7080301@mail.zedat.fu-berlin.de> Message-ID: <20090109025218.GA44317@duncan.reilly.home> On Fri, Jan 09, 2009 at 12:00:46AM +0100, O. Hartmann wrote: > Garrett Cooper wrote: > > On Jan 8, 2009, at 12:36 AM, Roman Divacky wrote: > > > >> On Wed, Jan 07, 2009 at 11:49:26PM -0800, Garrett Cooper wrote: > >>> One of the things I'm noting is that when I use dual displays with > >>> the nvidia driver, and xscreensaver kicks in and keeps going for a > >>> period of time, the machine's X.org console eats up a core, and when I > >>> try and do anything like gdb Xorg, the system hangs, attempts to panic > >>> (I assume that's the case because I hear it beep and attempt to > >>> restart), then I have to give it a warm boot. truss(1)'ing Xorg showed > >>> that there were a lot of SIGALARM's being fired and masked. Straight up: I can't help with this particular OP's quesiton, just have a comment, further down. > I have and I had the same in FreeBSD 7.0/7.1 and now with 8.0-CUR with > both a NV8600GTS and an older NV6800GT. A very old NV6600 never showed > up these lockings when I used that PCIe-Card with FreeBSD 7.0/7.1, but > I'm not sure. The locks came spontanous, sometimes after heavy usage of > 'mplayer', but sometimes instantanously after the destop showed up. > > On those boxes, there is no Linux emulation and no Linux BLOB (useless, > due to 64 Bit). I swapped the 'nv' driver on all FreeBSD boxes with > 'vesa', because there is another issue with sprites/graphics buffers > many times reported using FireFox. I have had terrible trouble with an NV6800 card on my AMD64 machine and a 1600x1200 LCD display. I mostly had to use the vesa driver, becauase sometimes the nv driver would just fail to initialize the card properly, and it would be just black, or wrong frequencies/jumbled: it was a mess. Vesa worked, but generally didn't let me go beyond 1280x1024. When nv was (occasionally) working I had the firefox bug surface. I've commented about this on the lists (and on usenet) before, so I thought that I'd better also mention, for the record, that I have completely solved the problem by replacing that card with an inexpensive ATI card that the radionhd driver recognizes as "RV635" based. Should have done it long ago... Everything appears to work perfectly, now. Cheers, Andrew From alexanderchuranov at gmail.com Fri Jan 9 07:01:16 2009 From: alexanderchuranov at gmail.com (Alexander Churanov) Date: Fri Jan 9 07:01:47 2009 Subject: Best torrent client/server available for FreeBSD? In-Reply-To: References: Message-ID: <3cb459ed0901082230y31c5fe2cw98abd9dbdc0e0b83@mail.gmail.com> Hi! I am happy with www/aria2 as ftp- http- and torrent- downloader. Alexander From yanefbsd at gmail.com Fri Jan 9 07:36:09 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Fri Jan 9 07:36:16 2009 Subject: snd_hda(4): getting line-in to work In-Reply-To: <49664FD8.1060700@FreeBSD.org> References: <7d6fde3d0901061032n72e9d0c4refe3c695f441c827@mail.gmail.com> <4963C4C0.6000509@FreeBSD.org> <7d6fde3d0901062029j694d63c1h66c52dfbb80c13d8@mail.gmail.com> <49647602.9060402@FreeBSD.org> <49649333.6060902@gmail.com> <7d6fde3d0901080937t29ec42f5i6684b9223d0b368a@mail.gmail.com> <49664FD8.1060700@FreeBSD.org> Message-ID: <7d6fde3d0901082336o6291c3a8r5cbb91a89db13ef7@mail.gmail.com> On Thu, Jan 8, 2009 at 11:11 AM, Alexander Motin wrote: > Garrett Cooper wrote: >> >> Ok, I got stuck again. Can you possibly push me in the right >> direction (complete verbose dmesg attached)? The line-in and SPDIF >> (not so much of a concern) are the only issues that I'm aware of. I'll >> have to open up my case and wire up the front ports in order to test >> them for you. > > Ok. Let's stop for a moment and start from the beginning, because now it is > already like a puzzle for me too. Let me explain once more what I see you > have and then you explain me where is your problem. > > You have 3 PCM devices configured: > - pcm0: 7.1 playback via 4 rear jacks (Green, Black, Orange and Grey) + > record from mic (front Pink), line (rear Blue), monitor (second mic, rear > Pink), cd (internal Black) or mix (sum of all these). > - pcm1: stereo playback via front Green jack. > - pcm2: SPDIF output > > As for me, this configuration is correct and good enough. You can record > from your line-in via pcm0 after selecting that source via `mixer =rec line` > command. You can playback via SPDIF by using pcm2 device. > > So what's wrong? What are you doing and what is not working and how? Ok, just checking my sanity, I started swapping around the plugs in the back, checking my connections, etc. I tried my mic, worked (the gain was a bit small, sound was _really_ distorted), then switched back to my line-in and sure enough, it now works :D. What changed since yesterday: - I hadn't set mixer_enable="YES" in rc.conf. This brought up a LOT more channels and options than I had originally. - Rebooted the machine with fixed device.hints (unchanged from the default :P). - I changed the volume for mix from 0:0 to 30:30. My summary (experience) thus far: So far the driver functions as expected, but the frequency response seems a bit off for the output -- it's really focused around the vocal range (the lower 3 frequencies on the audacity, iTunes, xmms equalizer -- forget the frequencies). It's not so bad with PCM sound, but It's really off with Line-in / Mic. Any hints or hacking I can do to adjust the voltage levels sent to the ADC's in the hardware? >> Also, the knobs that show up in xfce4-mixer are completely useless >> for snd_hda(4) (every time I move the sliders it sets the volume back >> to 0). Is this a known issue? > > You are the first. oss was complaining about a `unable to open mixer recording device: bad file descriptor' whenever I try and set the mixer levels by opening it up directly from the GUI. Interestingly enough when I opened up the mixer from an xterm, it worked 0-o.. However, I just toasted ~/.config/xfce4/mixer/* and now it works, so apparently it was bad cached preferences. Thanks! -Garrett From mav at FreeBSD.org Fri Jan 9 08:29:41 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Fri Jan 9 08:29:47 2009 Subject: snd_hda(4): getting line-in to work In-Reply-To: <7d6fde3d0901082336o6291c3a8r5cbb91a89db13ef7@mail.gmail.com> References: <7d6fde3d0901061032n72e9d0c4refe3c695f441c827@mail.gmail.com> <4963C4C0.6000509@FreeBSD.org> <7d6fde3d0901062029j694d63c1h66c52dfbb80c13d8@mail.gmail.com> <49647602.9060402@FreeBSD.org> <49649333.6060902@gmail.com> <7d6fde3d0901080937t29ec42f5i6684b9223d0b368a@mail.gmail.com> <49664FD8.1060700@FreeBSD.org> <7d6fde3d0901082336o6291c3a8r5cbb91a89db13ef7@mail.gmail.com> Message-ID: <49670AF2.7040901@FreeBSD.org> Garrett Cooper wrote: > On Thu, Jan 8, 2009 at 11:11 AM, Alexander Motin wrote: >> Garrett Cooper wrote: >>> Ok, I got stuck again. Can you possibly push me in the right >>> direction (complete verbose dmesg attached)? The line-in and SPDIF >>> (not so much of a concern) are the only issues that I'm aware of. I'll >>> have to open up my case and wire up the front ports in order to test >>> them for you. >> Ok. Let's stop for a moment and start from the beginning, because now it is >> already like a puzzle for me too. Let me explain once more what I see you >> have and then you explain me where is your problem. >> >> You have 3 PCM devices configured: >> - pcm0: 7.1 playback via 4 rear jacks (Green, Black, Orange and Grey) + >> record from mic (front Pink), line (rear Blue), monitor (second mic, rear >> Pink), cd (internal Black) or mix (sum of all these). >> - pcm1: stereo playback via front Green jack. >> - pcm2: SPDIF output >> >> As for me, this configuration is correct and good enough. You can record >> from your line-in via pcm0 after selecting that source via `mixer =rec line` >> command. You can playback via SPDIF by using pcm2 device. >> >> So what's wrong? What are you doing and what is not working and how? > > Ok, just checking my sanity, I started swapping around the plugs in > the back, checking my connections, etc. I tried my mic, worked (the > gain was a bit small, sound was _really_ distorted), then switched It is possible to control external mic phantom power via loader.conf. I have never tried it myself, but it may be related. > back to my line-in and sure enough, it now works :D. > > What changed since yesterday: > - I hadn't set mixer_enable="YES" in rc.conf. This brought up a LOT > more channels and options than I had originally. Don't very understand what you mean by channels. mixer_enable just loads mixer settings saved on shutdown. > - Rebooted the machine with fixed device.hints (unchanged from the default :P). > - I changed the volume for mix from 0:0 to 30:30. mix now controls volume of mixed inputs recording (if you select this record source. I would prefer direct line recording) and input monitoring. Sure it is not very good, I am thinking to somehow separate them. > My summary (experience) thus far: > > So far the driver functions as expected, but the frequency response > seems a bit off for the output -- it's really focused around the vocal > range (the lower 3 frequencies on the audacity, iTunes, xmms equalizer > -- forget the frequencies). > > It's not so bad with PCM sound, but It's really off with Line-in / > Mic. Any hints or hacking I can do to adjust the voltage levels sent > to the ADC's in the hardware? There is no standardized ADC controls in HDA specification. Some codecs allows loading some unstandardized "processing coefficients" for some widgets, but I don't see respective "PROC" capability in your verbose output. All you can is to control amplifiers gains and Vref for mics. If you have distorted sound on line-in, I would recommend you to check gains of all amplifiers inside codec where signal passes. Most inputs of your codec (including line) have +30dB mic pre-amplifiers. It is good for mics, but not needed for line-in. Set mixer "line" level to the lowest nonzero value to disable pre-amplification (without muting it) and avoid signal clipping there. Control recording level by other controls. If you are recording from mix, but not from the line, take note that mix control also have +12dB upper amplifier control range, so setting it to maximum values can also produce clipping. All this information obtained from your dmesg. >>> Also, the knobs that show up in xfce4-mixer are completely useless >>> for snd_hda(4) (every time I move the sliders it sets the volume back >>> to 0). Is this a known issue? >> You are the first. > > oss was complaining about a `unable to open mixer recording device: > bad file descriptor' whenever I try and set the mixer levels by > opening it up directly from the GUI. Interestingly enough when I > opened up the mixer from an xterm, it worked 0-o.. However, I just > toasted ~/.config/xfce4/mixer/* and now it works, so apparently it was > bad cached preferences. Fine. I am just using standard console `mixer` tool. -- Alexander Motin From rdivacky at freebsd.org Fri Jan 9 08:30:24 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Fri Jan 9 08:30:31 2009 Subject: X becomes unresponsive with nvidia / xscreensaver and desktop panics In-Reply-To: <4966859E.7080301@mail.zedat.fu-berlin.de> References: <7d6fde3d0901072349i50d04d2ch34f308388c9fd414@mail.gmail.com> <20090108083645.GA56613@freebsd.org> <1A86A687-DA2D-4866-8825-8BBF021F6937@gmail.com> <4966859E.7080301@mail.zedat.fu-berlin.de> Message-ID: <20090109083009.GA55615@freebsd.org> > I have and I had the same in FreeBSD 7.0/7.1 and now with 8.0-CUR with > both a NV8600GTS and an older NV6800GT. A very old NV6600 never showed > up these lockings when I used that PCIe-Card with FreeBSD 7.0/7.1, but > I'm not sure. The locks came spontanous, sometimes after heavy usage of > 'mplayer', but sometimes instantanously after the destop showed up. > > On those boxes, there is no Linux emulation and no Linux BLOB (useless, > due to 64 Bit). I swapped the 'nv' driver on all FreeBSD boxes with > 'vesa', because there is another issue with sprites/graphics buffers > many times reported using FireFox. > > When the display got locked, sometimes I had the chance opening a ssh > session killing Xorg/xdm and restarting working, but by the end, that > was when changing towards 8.0-CUR, this 'trick' didn't work anymore. On > FBSD 7, Xorg was eating up 100% CPU time. exactly my situation. I noticed that when the machine stucks while starting X I am sometimes (~ 60%) able to ctrl-alt-backspace and it after some minutes kills the X (= some sort of livelock?), after that I can 100% start the X successfully... From rdivacky at freebsd.org Fri Jan 9 08:34:20 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Fri Jan 9 08:34:27 2009 Subject: gcc 4.3: when will it become standard compiler? In-Reply-To: <20090108233311.GA69883@keltia.freenix.fr> References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090108233311.GA69883@keltia.freenix.fr> Message-ID: <20090109083404.GB55615@freebsd.org> On Fri, Jan 09, 2009 at 12:33:11AM +0100, Ollivier Robert wrote: > According to O. Hartmann: > > When will gcc 4.3 incorporated in FreeBSD 8 and become the standard > > compiler suite? We figured out that gcc 4.3 does have a speed gain in > > some numerical code of 3 - 8 % and I guess we can use this in the basic > > OS as well ... > > I'd rather have llvm instead... I am working a little on clang/llvm and I also looked at pcc, it's not there yet to be able to compile world/kernel but it's progressing well... there are two major features missing from clang (designated initializers and wchars) that prevents it from compiling world/kernel, and of course bugs :) but I am periodically checking how it performs and I post thebugs to the llvm/clang team... I believe we'll have it one day :) roman From roberto at keltia.freenix.fr Fri Jan 9 08:49:14 2009 From: roberto at keltia.freenix.fr (Ollivier Robert) Date: Fri Jan 9 08:49:21 2009 Subject: gcc 4.3: when will it become standard compiler? In-Reply-To: <20090109002133.GA92874@troutmask.apl.washington.edu> References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090109002133.GA92874@troutmask.apl.washington.edu> Message-ID: <20090109084908.GA76970@keltia.freenix.fr> According to Steve Kargl: > Probably not for a very long time. gcc 4.3 requires both GMP and > MPFR libraries. Neither library is in src. I do not know what MPFR is (something about FP, right?) but I wonder at why GMP could be needed by a compiler... Considering the amount of effort Apple is putting into llvm, I think this is the way to go. I'm not sure whether going with llvm-gcc4 is worth it although it would get us in bed with llvm faster. Go Roman! :) -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr Dons / donation Ondine : http://ondine.keltia.net/ From leafy7382 at gmail.com Fri Jan 9 09:16:26 2009 From: leafy7382 at gmail.com (Jiawei Ye) Date: Fri Jan 9 09:16:39 2009 Subject: gcc 4.3: when will it become standard compiler? In-Reply-To: <20090109083404.GB55615@freebsd.org> References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090108233311.GA69883@keltia.freenix.fr> <20090109083404.GB55615@freebsd.org> Message-ID: On Fri, Jan 9, 2009 at 4:34 PM, Roman Divacky wrote: > I am working a little on clang/llvm and I also looked at pcc, it's not > there yet to be able to compile world/kernel but it's progressing well... > > > there are two major features missing from clang (designated initializers > and wchars) that prevents it from compiling world/kernel, and of course > bugs :) but I am periodically checking how it performs and I post thebugs > to the llvm/clang team... > > I believe we'll have it one day :) > > roman What about llvm-gcc4? This has more compatibility with gcc than clang. Jiawei -- "If it looks like a duck, walks like a duck, and quacks like a duck, then to the end user it's a duck, and end users have made it pretty clear they want a duck; whether the duck drinks hot chocolate or coffee is irrelevant." From christoph.mallon at gmx.de Fri Jan 9 09:19:38 2009 From: christoph.mallon at gmx.de (Christoph Mallon) Date: Fri Jan 9 09:19:46 2009 Subject: gcc 4.3: when will it become standard compiler? In-Reply-To: <20090109084908.GA76970@keltia.freenix.fr> References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090109002133.GA92874@troutmask.apl.washington.edu> <20090109084908.GA76970@keltia.freenix.fr> Message-ID: <496716A6.7010606@gmx.de> Ollivier Robert schrieb: > According to Steve Kargl: >> Probably not for a very long time. gcc 4.3 requires both GMP and >> MPFR libraries. Neither library is in src. > > I do not know what MPFR is (something about FP, right?) but I wonder at why > GMP could be needed by a compiler... Mostly host independent constant folding. From rdivacky at freebsd.org Fri Jan 9 09:21:37 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Fri Jan 9 09:21:43 2009 Subject: gcc 4.3: when will it become standard compiler? In-Reply-To: References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090108233311.GA69883@keltia.freenix.fr> <20090109083404.GB55615@freebsd.org> Message-ID: <20090109092123.GA78163@freebsd.org> On Fri, Jan 09, 2009 at 04:45:00PM +0800, Jiawei Ye wrote: > On Fri, Jan 9, 2009 at 4:34 PM, Roman Divacky wrote: > > I am working a little on clang/llvm and I also looked at pcc, it's not > > there yet to be able to compile world/kernel but it's progressing well... > > > > > > there are two major features missing from clang (designated initializers > > and wchars) that prevents it from compiling world/kernel, and of course > > bugs :) but I am periodically checking how it performs and I post thebugs > > to the llvm/clang team... > > > > I believe we'll have it one day :) > > > > roman > What about llvm-gcc4? This has more compatibility with gcc than clang. it sure does.... now, but I think it's and dead end (for a number of reasons) I like clang better (and hence I work on that) From christoph.mallon at gmx.de Fri Jan 9 09:22:19 2009 From: christoph.mallon at gmx.de (Christoph Mallon) Date: Fri Jan 9 09:22:26 2009 Subject: gcc 4.3: when will it become standard compiler? In-Reply-To: <49668763.8020705@mail.zedat.fu-berlin.de> References: <49668763.8020705@mail.zedat.fu-berlin.de> Message-ID: <49671748.3030709@gmx.de> O. Hartmann schrieb: > When will gcc 4.3 incorporated in FreeBSD 8 and become the standard > compiler suite? We figured out that gcc 4.3 does have a speed gain in > some numerical code of 3 - 8 % and I guess we can use this in the basic > OS as well ... Number crunching has a totally different execution profile than basic operating system services. Gains in one area cannot simply be transferred to the other. From dougb at FreeBSD.org Fri Jan 9 09:37:07 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Fri Jan 9 09:37:14 2009 Subject: X becomes unresponsive with nvidia / xscreensaver and desktop panics In-Reply-To: <7d6fde3d0901072349i50d04d2ch34f308388c9fd414@mail.gmail.com> References: <7d6fde3d0901072349i50d04d2ch34f308388c9fd414@mail.gmail.com> Message-ID: On Wed, 7 Jan 2009, Garrett Cooper wrote: > Hello folks, > As many probably know, I recently installed FreeBSD 8-CURRENT on > my desktop. Why would we know that? I mean good for you, but seriously ... :) > One of the things I'm noting is that when I use dual displays with > the nvidia driver, and xscreensaver kicks in and keeps going for a > period of time, the machine's X.org console eats up a core, and when I > try and do anything like gdb Xorg, the system hangs, attempts to panic > (I assume that's the case because I hear it beep and attempt to > restart), then I have to give it a warm boot. truss(1)'ing Xorg showed > that there were a lot of SIGALARM's being fired and masked. No solutions, but a few general comments. First, I know that the author of xscreensaver has put a lot of work into dual head stuff, and also that it creates a lot of problems, so you're not alone here. If you get any conclusive evidence that xscreensaver is at fault you should contact him at http://www.jwz.org/xscreensaver/bugs.html A few things you can try to narrow it down .... first try turning off the xscreensaver daemon and just run one of the screensaver programs full screen for a while to see if that causes the crash. It's also worth testing GL vs. non-GL screensavers. I had a problem with GL stuff for a while that was fixed by an nvidia driver update a few versions ago. You should probably also try running with just the nv driver and see if that causes the same crash. Finally, you might try setting debug.debugger_on_panic=0 in /etc/sysctl.conf if you don't have it already. That will cause panics to go directly to dumping which is useful if you're in X. hth, Doug -- This .signature sanitized for your protection From christoph.mallon at gmx.de Fri Jan 9 10:06:06 2009 From: christoph.mallon at gmx.de (Christoph Mallon) Date: Fri Jan 9 10:06:13 2009 Subject: gcc 4.3: when will it become standard compiler? In-Reply-To: <20090109031147.GB44317@duncan.reilly.home> References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090108233311.GA69883@keltia.freenix.fr> <20090109031147.GB44317@duncan.reilly.home> Message-ID: <49672189.5060109@gmx.de> Andrew Reilly schrieb: > On Fri, Jan 09, 2009 at 12:33:11AM +0100, Ollivier Robert wrote: >> According to O. Hartmann: >>> When will gcc 4.3 incorporated in FreeBSD 8 and become the standard >>> compiler suite? We figured out that gcc 4.3 does have a speed gain in >>> some numerical code of 3 - 8 % and I guess we can use this in the basic >>> OS as well ... >> I'd rather have llvm instead... > > I wouldn't mind that, either. I've got the llvm port installed myself, in > preparation for doing some experiments of my own, but haven't tried using it to > build the kernel or user-land (or even any of the ports). Has anyone given it a > go? Is it missing any crucial features? I believe that it had different (or > no?) support for PIC code generation, which could affect the ability to do > shared libraries, but recent release notes seem to indicate that that's been > addressed. One quite important difference between GCC and LLVM is that GCC has been used to compile literally billions and billions of lines of code. Sure, LLVM has compiled many lines, too, but it's hard to beat GCC in terms of stability in this respect (yes, I am well aware that GCC had and has its share of bugs). You have to do *lots* of testing before you can honestly say that a compiler can really be used to compile a whole operating system. Another aspect is that LLVM is in some parts more aggressive at optimisation than GCC. So sloppy code, which GCC let you get away with, may suddenly break - though it was wrong all along, but you just never noticed. Of course the code has to be fixed, but this takes time. I'm not saying it's wrong to look for alternatives, but you cannot just change your system compiler like you change underwear. > There's also someone working on a BSD-licenced retooling (ANSI/ISO-ification) of > the PCC compiler, which is getting close to being useful as a system compiler, I > believe. (http://www.ludd.ltu.se/~ragge/pcc/ in ports/lang/pcc) PCC cannot seriously be considered. Its design is stuck in the seventies. From the point of view of compiler construction it is plain plain out of question. I especially was amused by the statement of the author who claimed PCC supports SSA - except for phi-functions. From phk at phk.freebsd.dk Fri Jan 9 10:10:15 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri Jan 9 10:10:24 2009 Subject: 3G modem and USB, old & new Message-ID: <3994.1231494833@critter.freebsd.dk> I tried using my 3g modem (Huawei E196) yesterday, with both the old and the new USB stack, and it fails in slightly different ways. With the old USB stack, it works until I actually try to get a packet of more than approx 1024 bytes through, at which point it hangs with ucom0: ucomreadcb: IOERROR And I need to stop and start ppp(1) to get it working until the next big packet comes around. It does not help to reduce the MRU because two small packets back to back will also trigger this error. With the new USB stack, I am not able to talk to the modem at all using the cuaU* devices. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From marius at nuenneri.ch Fri Jan 9 10:32:26 2009 From: marius at nuenneri.ch (=?ISO-8859-1?Q?Marius_N=FCnnerich?=) Date: Fri Jan 9 10:32:34 2009 Subject: bsdtar fan In-Reply-To: <4966A9AB.2040802@FreeBSD.org> References: <4965927D.1060507@freebsd.org> <4966A9AB.2040802@FreeBSD.org> Message-ID: On Fri, Jan 9, 2009 at 2:34 AM, Bruce M. Simpson wrote: > Off topic: > Tim, thank you for bsdtar. I recently had to muck around with ISO images on > a debian box, and mounting them all would have been prohibitive. Thanks to > bsdtar, I could just extract the files I needed, without using loopback > mounts. That was invaluable. thank you! When I'm on other systems I constantly try tar xf and fail. bsdtar rocks Tim :) From ken at mthelicon.com Fri Jan 9 10:41:29 2009 From: ken at mthelicon.com (Pegasus Mc Cleaft) Date: Fri Jan 9 10:41:36 2009 Subject: gcc 4.3: when will it become standard compiler? In-Reply-To: <49672189.5060109@gmx.de> References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090108233311.GA69883@keltia.freenix.fr><20090109031147.GB44317@duncan.reilly.home> <49672189.5060109@gmx.de> Message-ID: <2889C93967084361AF31BC85B2D52D1D@PegaPegII> ----- Original Message ----- From: "Christoph Mallon" To: "Andrew Reilly" Cc: "Ollivier Robert" ; Sent: Friday, January 09, 2009 10:06 AM Subject: Re: gcc 4.3: when will it become standard compiler? > Andrew Reilly schrieb: >> On Fri, Jan 09, 2009 at 12:33:11AM +0100, Ollivier Robert wrote: >>> According to O. Hartmann: >>>> When will gcc 4.3 incorporated in FreeBSD 8 and become the standard >>>> compiler suite? We figured out that gcc 4.3 does have a speed gain in >>>> some numerical code of 3 - 8 % and I guess we can use this in the basic >>>> OS as well ... >>> I'd rather have llvm instead... >> >> I wouldn't mind that, either. I've got the llvm port installed myself, >> in >> preparation for doing some experiments of my own, but haven't tried using >> it to >> build the kernel or user-land (or even any of the ports). Has anyone >> given it a >> go? Is it missing any crucial features? I believe that it had different >> (or >> no?) support for PIC code generation, which could affect the ability to >> do >> shared libraries, but recent release notes seem to indicate that that's >> been >> addressed. > > One quite important difference between GCC and LLVM is that GCC has been > used to compile literally billions and billions of lines of code. Sure, > LLVM has compiled many lines, too, but it's hard to beat GCC in terms of > stability in this respect (yes, I am well aware that GCC had and has its > share of bugs). You have to do *lots* of testing before you can honestly > say that a compiler can really be used to compile a whole operating > system. > Another aspect is that LLVM is in some parts more aggressive at > optimisation than GCC. So sloppy code, which GCC let you get away with, > may suddenly break - though it was wrong all along, but you just never > noticed. Of course the code has to be fixed, but this takes time. > I'm not saying it's wrong to look for alternatives, but you cannot just > change your system compiler like you change underwear. > >> There's also someone working on a BSD-licenced retooling >> (ANSI/ISO-ification) of >> the PCC compiler, which is getting close to being useful as a system >> compiler, I >> believe. (http://www.ludd.ltu.se/~ragge/pcc/ in ports/lang/pcc) > > PCC cannot seriously be considered. Its design is stuck in the seventies. > From the point of view of compiler construction it is plain plain out of > question. I especially was amused by the statement of the author who > claimed PCC supports SSA - except for phi-functions. Hi Current, I personally dont mind GCC being of a older version for the world and kernel compiles, however, I do wish that a newer version of binutils were used. I can compile GCC from the ports or download the sources and compile it there, but it seems to get really icky if you have two versions of binutils installed. The benifits of having the newer binutils is that I can compile using SSE4.1 which bomb out now due to the older "as" not knowing the new opcodes. I believe there are licenscing issues with using the newer binutils, but what they are I have no idea. Peg From olivier at gid0.org Fri Jan 9 10:44:55 2009 From: olivier at gid0.org (Olivier SMEDTS) Date: Fri Jan 9 10:45:03 2009 Subject: bsdtar fan In-Reply-To: References: <4965927D.1060507@freebsd.org> <4966A9AB.2040802@FreeBSD.org> Message-ID: <367b2c980901090244t64d33c2fx171cda607914189e@mail.gmail.com> 2009/1/9 Marius N?nnerich : > On Fri, Jan 9, 2009 at 2:34 AM, Bruce M. Simpson wrote: >> Off topic: >> Tim, thank you for bsdtar. I recently had to muck around with ISO images on >> a debian box, and mounting them all would have been prohibitive. Thanks to >> bsdtar, I could just extract the files I needed, without using loopback >> mounts. That was invaluable. thank you! > > When I'm on other systems I constantly try tar xf and fail. bsdtar rocks Tim :) I totally agree. Just fed up determining compression type of archives and using z/j flags with non-bsd tar :) Thank you Tim ! > _______________________________________________ > 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" > -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: olivier@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." From hselasky at c2i.net Fri Jan 9 11:00:50 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Fri Jan 9 11:01:04 2009 Subject: 3G modem and USB, old & new In-Reply-To: <3994.1231494833@critter.freebsd.dk> References: <3994.1231494833@critter.freebsd.dk> Message-ID: <200901091202.41011.hselasky@c2i.net> On Friday 09 January 2009, Poul-Henning Kamp wrote: > I tried using my 3g modem (Huawei E196) yesterday, with both the > old and the new USB stack, and it fails in slightly different > ways. > > With the old USB stack, it works until I actually try to get a packet > of more than approx 1024 bytes through, at which point it hangs with > ucom0: ucomreadcb: IOERROR > And I need to stop and start ppp(1) to get it working until the next > big packet comes around. > > It does not help to reduce the MRU because two small packets back to > back will also trigger this error. > > With the new USB stack, I am not able to talk to the modem at all > using the cuaU* devices. Hi, With regard to the new USB stack: Do you see any USB error messages in dmesg? What does the dmesg print out? Also there are debugging sysctls: sysctl -a hw.usb2 | grep debug Also try dumping the descriptors of your device using "usbconfig -u xxx -a yyy dump_device_desc dump_curr_config_desc". You can also try things like: usbconfig -u xxx -a yyy reset --HPS From hselasky at c2i.net Fri Jan 9 11:00:50 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Fri Jan 9 11:01:04 2009 Subject: 3G modem and USB, old & new In-Reply-To: <3994.1231494833@critter.freebsd.dk> References: <3994.1231494833@critter.freebsd.dk> Message-ID: <200901091202.41011.hselasky@c2i.net> On Friday 09 January 2009, Poul-Henning Kamp wrote: > I tried using my 3g modem (Huawei E196) yesterday, with both the > old and the new USB stack, and it fails in slightly different > ways. > > With the old USB stack, it works until I actually try to get a packet > of more than approx 1024 bytes through, at which point it hangs with > ucom0: ucomreadcb: IOERROR > And I need to stop and start ppp(1) to get it working until the next > big packet comes around. > > It does not help to reduce the MRU because two small packets back to > back will also trigger this error. > > With the new USB stack, I am not able to talk to the modem at all > using the cuaU* devices. Hi, With regard to the new USB stack: Do you see any USB error messages in dmesg? What does the dmesg print out? Also there are debugging sysctls: sysctl -a hw.usb2 | grep debug Also try dumping the descriptors of your device using "usbconfig -u xxx -a yyy dump_device_desc dump_curr_config_desc". You can also try things like: usbconfig -u xxx -a yyy reset --HPS From rdivacky at freebsd.org Fri Jan 9 11:05:25 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Fri Jan 9 11:05:32 2009 Subject: gcc 4.3: when will it become standard compiler? In-Reply-To: <49672189.5060109@gmx.de> References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090108233311.GA69883@keltia.freenix.fr> <20090109031147.GB44317@duncan.reilly.home> <49672189.5060109@gmx.de> Message-ID: <20090109110508.GA12123@freebsd.org> On Fri, Jan 09, 2009 at 11:06:01AM +0100, Christoph Mallon wrote: > Andrew Reilly schrieb: > >On Fri, Jan 09, 2009 at 12:33:11AM +0100, Ollivier Robert wrote: > >>According to O. Hartmann: > >>>When will gcc 4.3 incorporated in FreeBSD 8 and become the standard > >>>compiler suite? We figured out that gcc 4.3 does have a speed gain in > >>>some numerical code of 3 - 8 % and I guess we can use this in the basic > >>>OS as well ... > >>I'd rather have llvm instead... > > > >I wouldn't mind that, either. I've got the llvm port installed myself, in > >preparation for doing some experiments of my own, but haven't tried using > >it to > >build the kernel or user-land (or even any of the ports). Has anyone > >given it a > >go? Is it missing any crucial features? I believe that it had different > >(or > >no?) support for PIC code generation, which could affect the ability to do > >shared libraries, but recent release notes seem to indicate that that's > >been > >addressed. > > One quite important difference between GCC and LLVM is that GCC has been > used to compile literally billions and billions of lines of code. Sure, > LLVM has compiled many lines, too, but it's hard to beat GCC in terms of > stability in this respect (yes, I am well aware that GCC had and has its > share of bugs). You have to do *lots* of testing before you can honestly > say that a compiler can really be used to compile a whole operating system. > Another aspect is that LLVM is in some parts more aggressive at > optimisation than GCC. So sloppy code, which GCC let you get away with, > may suddenly break - though it was wrong all along, but you just never > noticed. Of course the code has to be fixed, but this takes time. > I'm not saying it's wrong to look for alternatives, but you cannot just > change your system compiler like you change underwear. well... the first step is imho starting to compile world with C99... that might reveal some bugs, note that as of a few months ago 8-current compiles cleanly with C99, that does not mean that it's working when you run those programs correctly :) > >There's also someone working on a BSD-licenced retooling > >(ANSI/ISO-ification) of > >the PCC compiler, which is getting close to being useful as a system > >compiler, I > >believe. (http://www.ludd.ltu.se/~ragge/pcc/ in ports/lang/pcc) > > PCC cannot seriously be considered. Its design is stuck in the > seventies. From the point of view of compiler construction it is plain > plain out of question. I especially was amused by the statement of the > author who claimed PCC supports SSA - except for phi-functions. what's wrong with design stuck in 70's when it compiles the whole world/kernel? I would not use it for default compilation of releases but it might be useful when you are developing - because of its fast compilation times btw.. are you sure the design is stuck in the 70's? the author claims to have rewritten almost the whole thing. have you looked at the recent code? another question - how is libfirm/cparser? last time I tried it didnt support much of the gcc options (-Wsomething -f-something etc.) so it could not be used as a direct drop-in From rdivacky at freebsd.org Fri Jan 9 11:07:09 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Fri Jan 9 11:07:18 2009 Subject: gcc 4.3: when will it become standard compiler? In-Reply-To: <2889C93967084361AF31BC85B2D52D1D@PegaPegII> References: <49668763.8020705@mail.zedat.fu-berlin.de> <49672189.5060109@gmx.de> <2889C93967084361AF31BC85B2D52D1D@PegaPegII> Message-ID: <20090109110646.GB12123@freebsd.org> > Hi Current, > > I personally dont mind GCC being of a older version for the world and > kernel compiles, however, I do wish that a newer version of binutils were > used. > > I can compile GCC from the ports or download the sources and compile it > there, but it seems to get really icky if you have two versions of binutils > installed. The benifits of having the newer binutils is that I can compile > using SSE4.1 which bomb out now due to the older "as" not knowing the new > opcodes. > > I believe there are licenscing issues with using the newer binutils, but > what they are I have no idea. I am sure the last GPLv2 is MUCH newer than what we have now :) From unixmania at gmail.com Fri Jan 9 11:27:07 2009 From: unixmania at gmail.com (Carlos A. M. dos Santos) Date: Fri Jan 9 11:27:18 2009 Subject: patch to fix burncd bug In-Reply-To: <87prixz9ne.fsf@kobe.laptop> References: <87prixz9ne.fsf@kobe.laptop> Message-ID: On Thu, Jan 8, 2009 at 8:59 PM, Giorgos Keramidas wrote: > On Thu, 08 Jan 2009 18:13:14 +0100 (CET), Alexander Best wrote: >> could somebody please commit the following patch to dev/ata? it fixes >> a nasty bug during fixation in burncd. the bug exists in RELENG6, >> RELENG7 and HEAD (and maybe RELENG5): >> >> http://www.freebsd.org/cgi/query-pr.cgi?prp=95979-3-txt&n=/patch >> >> the whole PR can be found here: >> http://www.freebsd.org/cgi/query-pr.cgi?pr=95979 > > I think Soren is the best person to look into this bug (Cc: added). > > Soren, what do you think? Does the patch at bin/95979 look like a nice > change to commit? I just saw this PR so I haven't tried the patch on my > laptop's CURRENT yet, but I can confirm that burning CD-ROMs and DVDs is > busted in my laptop for a few weeks now. I proposed a solution a similar problem (bin/123693), but patching burncd instead of the kernel. I'm attaching the patch, for your convenience. -- cd /usr/ports/sysutils/life make clean -------------- next part -------------- A non-text attachment was scrubbed... Name: burncd_eject.patch Type: text/x-diff Size: 697 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090109/e2dd9570/burncd_eject.bin From phk at phk.freebsd.dk Fri Jan 9 11:30:14 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri Jan 9 11:30:29 2009 Subject: 3G modem and USB, old & new In-Reply-To: Your message of "Fri, 09 Jan 2009 12:02:39 +0100." <200901091202.41011.hselasky@c2i.net> Message-ID: <20722.1231500610@critter.freebsd.dk> In message <200901091202.41011.hselasky@c2i.net>, Hans Petter Selasky writes: >On Friday 09 January 2009, Poul-Henning Kamp wrote: >With regard to the new USB stack: > >Do you see any USB error messages in dmesg? I didn't see anything that looked like an error, the device just does not respond to "AT" commands on the tty device. It goes through the "change mode from install-CD" dance, comes up with /dev/cuaU[0-2], /dev/cd0 and /dev/da1, da1 because I have another USB disk in the system also (which works), but the cuaU[0-2] devices does not seem to work. >What does the dmesg print out? I don't have the messages saved, I did it in single user. >Also there are debugging sysctls: > >sysctl -a hw.usb2 | grep debug Yeah, tried those, but didn't see anything that looked like an error. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From phk at phk.freebsd.dk Fri Jan 9 11:30:15 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri Jan 9 11:30:31 2009 Subject: 3G modem and USB, old & new In-Reply-To: Your message of "Fri, 09 Jan 2009 12:02:39 +0100." <200901091202.41011.hselasky@c2i.net> Message-ID: <20722.1231500610@critter.freebsd.dk> In message <200901091202.41011.hselasky@c2i.net>, Hans Petter Selasky writes: >On Friday 09 January 2009, Poul-Henning Kamp wrote: >With regard to the new USB stack: > >Do you see any USB error messages in dmesg? I didn't see anything that looked like an error, the device just does not respond to "AT" commands on the tty device. It goes through the "change mode from install-CD" dance, comes up with /dev/cuaU[0-2], /dev/cd0 and /dev/da1, da1 because I have another USB disk in the system also (which works), but the cuaU[0-2] devices does not seem to work. >What does the dmesg print out? I don't have the messages saved, I did it in single user. >Also there are debugging sysctls: > >sysctl -a hw.usb2 | grep debug Yeah, tried those, but didn't see anything that looked like an error. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From hselasky at c2i.net Fri Jan 9 11:42:10 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Fri Jan 9 11:42:23 2009 Subject: 3G modem and USB, old & new In-Reply-To: <20722.1231500610@critter.freebsd.dk> References: <20722.1231500610@critter.freebsd.dk> Message-ID: <200901091243.40981.hselasky@c2i.net> On Friday 09 January 2009, Poul-Henning Kamp wrote: > In message <200901091202.41011.hselasky@c2i.net>, Hans Petter Selasky writes: > >On Friday 09 January 2009, Poul-Henning Kamp wrote: > > > >With regard to the new USB stack: > > > >Do you see any USB error messages in dmesg? > > I didn't see anything that looked like an error, the device just > does not respond to "AT" commands on the tty device. Which serial driver are you using? U3G? Are you using the latest code from -current ? --HPS From hselasky at c2i.net Fri Jan 9 11:42:10 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Fri Jan 9 11:42:24 2009 Subject: 3G modem and USB, old & new In-Reply-To: <20722.1231500610@critter.freebsd.dk> References: <20722.1231500610@critter.freebsd.dk> Message-ID: <200901091243.40981.hselasky@c2i.net> On Friday 09 January 2009, Poul-Henning Kamp wrote: > In message <200901091202.41011.hselasky@c2i.net>, Hans Petter Selasky writes: > >On Friday 09 January 2009, Poul-Henning Kamp wrote: > > > >With regard to the new USB stack: > > > >Do you see any USB error messages in dmesg? > > I didn't see anything that looked like an error, the device just > does not respond to "AT" commands on the tty device. Which serial driver are you using? U3G? Are you using the latest code from -current ? --HPS From phk at phk.freebsd.dk Fri Jan 9 11:46:36 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri Jan 9 11:46:49 2009 Subject: 3G modem and USB, old & new In-Reply-To: Your message of "Fri, 09 Jan 2009 12:43:39 +0100." <200901091243.40981.hselasky@c2i.net> Message-ID: <21013.1231501594@critter.freebsd.dk> In message <200901091243.40981.hselasky@c2i.net>, Hans Petter Selasky writes: >Which serial driver are you using? U3G? > >Are you using the latest code from -current ? I just compiled a USB2 kernel from yesterdays -current while sitting in the train. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From phk at phk.freebsd.dk Fri Jan 9 11:46:36 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri Jan 9 11:46:50 2009 Subject: 3G modem and USB, old & new In-Reply-To: Your message of "Fri, 09 Jan 2009 12:43:39 +0100." <200901091243.40981.hselasky@c2i.net> Message-ID: <21013.1231501594@critter.freebsd.dk> In message <200901091243.40981.hselasky@c2i.net>, Hans Petter Selasky writes: >Which serial driver are you using? U3G? > >Are you using the latest code from -current ? I just compiled a USB2 kernel from yesterdays -current while sitting in the train. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From unixmania at gmail.com Fri Jan 9 11:53:35 2009 From: unixmania at gmail.com (Carlos A. M. dos Santos) Date: Fri Jan 9 11:53:41 2009 Subject: gcc 4.3: when will it become standard compiler? In-Reply-To: <20090109031147.GB44317@duncan.reilly.home> References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090108233311.GA69883@keltia.freenix.fr> <20090109031147.GB44317@duncan.reilly.home> Message-ID: On Fri, Jan 9, 2009 at 1:11 AM, Andrew Reilly wrote: [...] > There's also someone working on a BSD-licenced retooling (ANSI/ISO-ification) of > the PCC compiler, which is getting close to being useful as a system compiler, I > believe. (http://www.ludd.ltu.se/~ragge/pcc/ in ports/lang/pcc) Yes, and they nedd money to keep working on it. Please see http://bsdfund.org/projects/pcc/ I already gave a contribution. Would you guys like to join me? -- cd /usr/ports/sysutils/life make clean From Manfred.Knick at T-Online.de Fri Jan 9 09:01:37 2009 From: Manfred.Knick at T-Online.de (Manfred_Knick) Date: Fri Jan 9 12:26:35 2009 Subject: possibility of a "severe flaw in the logic of FreeBSD's kernel handling multiple host bridges ..." In-Reply-To: <1231460648.93079.65.camel@squirrel.corp.cox.com> References: <496651ED.8080102@T-Online.de> <1231460648.93079.65.camel@squirrel.corp.cox.com> Message-ID: <4967125D.80801@T-Online.de> Robert Noland schrieb: > I'm really not sure that I am the best person to try and tackle this, Hi, Robert, thank you very much for your reply! > but it does fall somewhere near me... Can you send me a pciconf -lv. You are welcome! Well, as stated in the reports, I'm prepared to help with additional information and tests I can provide. My main background is Gentoo (GNU/Linux source based rolling meta- distribution), thus knowing my way around building my hand-crafted kernels ... Kind regards Manfred . --- --- --- pciconf -lv --- --- --- hostb0@pci0:0:0:0: class=0x060000 card=0x00e11849 chip=0x00e110de rev=0xa1 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce3 250 Host/PCI Bridge' <===== class = bridge subclass = HOST-PCI isab0@pci0:0:1:0: class=0x060100 card=0x00e01849 chip=0x00e010de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce3 250 LPC Interface Bridge' class = bridge subclass = PCI-ISA none0@pci0:0:1:1: class=0x0c0500 card=0x00e41849 chip=0x00e410de rev=0xa1 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce3 250 PCI System Management' class = serial bus subclass = SMBus ohci0@pci0:0:2:0: class=0x0c0310 card=0x00e71849 chip=0x00e710de rev=0xa1 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce3 250 OpenHCD USB Controller' class = serial bus subclass = USB ohci1@pci0:0:2:1: class=0x0c0310 card=0x00e71849 chip=0x00e710de rev=0xa1 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce3 250 OpenHCD USB Controller' class = serial bus subclass = USB ehci0@pci0:0:2:2: class=0x0c0320 card=0x00e81849 chip=0x00e810de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce3 250 Enhanced PCI to USB Controller' class = serial bus subclass = USB atapci0@pci0:0:8:0: class=0x01018a card=0x00e51849 chip=0x00e510de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce3 250 Parallel ATA Controller' class = mass storage subclass = ATA atapci1@pci0:0:10:0: class=0x010185 card=0x00e31849 chip=0x00e310de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'nForce3 250 Serial ATA Controller' class = mass storage subclass = ATA pcib1@pci0:0:11:0: class=0x060400 card=0x00000000 chip=0x00e210de rev=0xa2 hdr=0x01 vendor = 'Nvidia Corp' device = 'nForce3 250 AGP Host to PCI Bridge' <===== class = bridge subclass = PCI-PCI pcib2@pci0:0:14:0: class=0x060400 card=0x00000000 chip=0x00ed10de rev=0xa2 hdr=0x01 vendor = 'Nvidia Corp' device = 'nForce3 250 PCI-PCI Bridge' <===== class = bridge subclass = PCI-PCI hostb1@pci0:0:16:0: class=0x060000 card=0x00000000 chip=0x169510b9 rev=0x00 hdr=0x00 vendor = 'Acer Labs Incorporated (ALi/ULi)' device = 'ULi M1695 K8 Northbridge with PCIe and hypertransport' class = bridge subclass = HOST-PCI pcib3@pci0:0:17:0: class=0x060400 card=0x00000000 chip=0x524b10b9 rev=0x00 hdr=0x01 vendor = 'Acer Labs Incorporated (ALi/ULi)' device = 'ALi PCIe Bridge' class = bridge subclass = PCI-PCI pcib4@pci0:0:18:0: class=0x060400 card=0x00000000 chip=0x524c10b9 rev=0x00 hdr=0x01 vendor = 'Acer Labs Incorporated (ALi/ULi)' device = 'ALi PCIe Bridge' class = bridge subclass = PCI-PCI pcib5@pci0:0:19:0: class=0x060400 card=0x00000000 chip=0x524d10b9 rev=0x00 hdr=0x01 vendor = 'Acer Labs Incorporated (ALi/ULi)' class = bridge subclass = PCI-PCI hostb2@pci0:0:24:0: class=0x060000 card=0x00000000 chip=0x12001022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(Family 10h) Athlon 64/Opteron/Sempron HyperTransport Technology Configuration' class = bridge subclass = HOST-PCI hostb3@pci0:0:24:1: class=0x060000 card=0x00000000 chip=0x12011022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(Family 10h) Athlon 64/Opteron/Sempron Address Map' class = bridge subclass = HOST-PCI hostb4@pci0:0:24:2: class=0x060000 card=0x00000000 chip=0x12021022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(Family 10h) Athlon 64/Opteron/Sempron DRAM Controller' class = bridge subclass = HOST-PCI hostb5@pci0:0:24:3: class=0x060000 card=0x00000000 chip=0x12031022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(Family 10h) Athlon 64/Opteron/Sempron Miscellaneous Control' class = bridge subclass = HOST-PCI hostb6@pci0:0:24:4: class=0x060000 card=0x00000000 chip=0x12041022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = '(Family 10h) Athlon 64/Opteron/Sempron Link Control' class = bridge subclass = HOST-PCI vgapci0@pci0:4:0:0: class=0x030000 card=0x0f84102b chip=0x2527102b rev=0x01 hdr=0x00 vendor = 'Matrox Electronic Systems Ltd.' device = 'MGA-G550 AGP Chipset' <===== class = display subclass = VGA atapci2@pci0:1:0:0: class=0x010185 card=0x23631849 chip=0x2363197b rev=0x03 hdr=0x00 vendor = 'JMicron Technology Corp' device = 'JMB36X PCIe-to-SATA-300/IDE RAID Controller' class = mass storage subclass = ATA re0@pci0:2:0:0: class=0x020000 card=0x81681849 chip=0x816810ec rev=0x01 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' class = network subclass = ethernet From gerald at pfeifer.com Fri Jan 9 09:27:31 2009 From: gerald at pfeifer.com (Gerald Pfeifer) Date: Fri Jan 9 12:27:40 2009 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: References: <20081227202117.F3B14341A3@cavin02.kulnet.kuleuven.ac.be><200812281613.49404.tijl@ulyssis.org> Message-ID: On Tue, 30 Dec 2008, Li, Qing wrote: > I don't think we can provide binary compatibility without putting > back RTF_LLINFO exactly as it was. My preference is to continue down > the new path without RTF_LLINFO. So, you are saying that applications built on FreeBSD 7 or earlier that use RTF_LLINFO will no longer work properly on FreeBSD 8 after your change? Ignoring everything else, that would be a killer and the one reason to definitely change the current situation. Otherwise, ISVs will need two builds, one for FreeBSD 7 and earlier and one for FreeBSD 8, and believe me, that is bad, bad, bad. Or rather: unlikely. (GNU/Linux distributions do provide this level of compatibility.) > We still have some time before the 8.0 release. It's straightforward > for me to retain some of the RTF_LLINFO support in the new kernel if > and when the situation becomes necessary. Sounds like that is the case? > Since the affected ports now have the conditional code around > RTF_LLINFO, the updates would allow these ports to compile in > both -current and in the previous releases. emulators/wine still is broken, and upstream Wine has not accepted the patch yet. I believe one reason likely is the above, and the fact that this may break commercial builds of Wine. How are you going to address this? Gerald -- Gerald (Jerry) Pfeifer gerald@pfeifer.com http://www.pfeifer.com/gerald/ From svein-listmail at stillbilde.net Fri Jan 9 10:39:08 2009 From: svein-listmail at stillbilde.net (Svein Skogen (List Mail Account)) Date: Fri Jan 9 12:27:53 2009 Subject: gcc 4.3: when will it become standard compiler? In-Reply-To: <49671748.3030709@gmx.de> References: <49668763.8020705@mail.zedat.fu-berlin.de> <49671748.3030709@gmx.de> Message-ID: <4967259C.9090408@stillbilde.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christoph Mallon wrote: > O. Hartmann schrieb: >> When will gcc 4.3 incorporated in FreeBSD 8 and become the standard >> compiler suite? We figured out that gcc 4.3 does have a speed gain in >> some numerical code of 3 - 8 % and I guess we can use this in the basic >> OS as well ... > > Number crunching has a totally different execution profile than basic > operating system services. Gains in one area cannot simply be > transferred to the other. Would it be possible, as a "workaround" to have "system-CC" and "ports-CC" defined in make.conf, making one CC the compiler for /usr/src and another for ports, or would this just create debugging nightmares? //Svein -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklnJZwACgkQtVbTV+BEzaPDQACgqOavzljEEcRFsI4tsQXxIuhr ZDMAoJwjZI26U0wEMtdbRgVWMvOkkBgY =NDwj -----END PGP SIGNATURE----- From yanefbsd at gmail.com Fri Jan 9 13:12:01 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Fri Jan 9 13:12:08 2009 Subject: gcc 4.3: when will it become standard compiler? In-Reply-To: <4967259C.9090408@stillbilde.net> References: <49668763.8020705@mail.zedat.fu-berlin.de> <49671748.3030709@gmx.de> <4967259C.9090408@stillbilde.net> Message-ID: <7d6fde3d0901090511x21f9109ei527a1998c0f05bf8@mail.gmail.com> On Fri, Jan 9, 2009 at 2:23 AM, Svein Skogen (List Mail Account) wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Christoph Mallon wrote: >> O. Hartmann schrieb: >>> When will gcc 4.3 incorporated in FreeBSD 8 and become the standard >>> compiler suite? We figured out that gcc 4.3 does have a speed gain in >>> some numerical code of 3 - 8 % and I guess we can use this in the basic >>> OS as well ... >> >> Number crunching has a totally different execution profile than basic >> operating system services. Gains in one area cannot simply be >> transferred to the other. > > Would it be possible, as a "workaround" to have "system-CC" and > "ports-CC" defined in make.conf, making one CC the compiler for /usr/src > and another for ports, or would this just create debugging nightmares? > > //Svein If setup properly, something similar to what Gentoo Linux for profiled compilers would be a very nice thing to have for `muxing' between development tools. It would just make upgrades potentially more painful though, and it would make tracking viral license tainting more difficult for folks who are on the receiving end, or ones that aren't paying attention to the licensing in the pieces of software they're distributing... The problem is that gcc is indeed lightyears ahead of any other [opensource] compiler available, and the fact that there are a number of bugs being filed against newer releases of gcc which don't translate back necessarily into our version, cleanly. Similarly, gdb has a lot of years of tread behind it as a debugger. If we were to drop either the compiler or the debugger (and I'm pretty sure we'd have to dump both if we dumped one), I believe that it would take another group of individuals an extensive period of time to get back to speed with what's available thanks to the GNU folks now... even if the GNU stuff in its current state is buggy. One thing I'm curious about though: for the bugs that do matter to us, if there is a patch, would the patch be considered GPLv2 or GPLv3 licensed code? Not a lawyer, and I don't expect a lawyer's PoV, but if the fix is truly trivial and it's compatible with the existing license, that would be cool to import I would think... Yes, we should really upgrade binutils though.. newer binutils would bring in a number of bugfixes as well as feature enhancements... Cheers, -Garrett PS Huzzah for R Stallman and his licensing crusade ;(... From yanefbsd at gmail.com Fri Jan 9 13:18:32 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Fri Jan 9 13:19:12 2009 Subject: X becomes unresponsive with nvidia / xscreensaver and desktop panics In-Reply-To: <20090109083009.GA55615@freebsd.org> References: <7d6fde3d0901072349i50d04d2ch34f308388c9fd414@mail.gmail.com> <20090108083645.GA56613@freebsd.org> <1A86A687-DA2D-4866-8825-8BBF021F6937@gmail.com> <4966859E.7080301@mail.zedat.fu-berlin.de> <20090109083009.GA55615@freebsd.org> Message-ID: <7d6fde3d0901090518m6e214a7pfe4d38249daf445e@mail.gmail.com> On Fri, Jan 9, 2009 at 12:30 AM, Roman Divacky wrote: >> I have and I had the same in FreeBSD 7.0/7.1 and now with 8.0-CUR with >> both a NV8600GTS and an older NV6800GT. A very old NV6600 never showed >> up these lockings when I used that PCIe-Card with FreeBSD 7.0/7.1, but >> I'm not sure. The locks came spontanous, sometimes after heavy usage of >> 'mplayer', but sometimes instantanously after the destop showed up. >> >> On those boxes, there is no Linux emulation and no Linux BLOB (useless, >> due to 64 Bit). I swapped the 'nv' driver on all FreeBSD boxes with >> 'vesa', because there is another issue with sprites/graphics buffers >> many times reported using FireFox. >> >> When the display got locked, sometimes I had the chance opening a ssh >> session killing Xorg/xdm and restarting working, but by the end, that >> was when changing towards 8.0-CUR, this 'trick' didn't work anymore. On >> FBSD 7, Xorg was eating up 100% CPU time. > > exactly my situation. I noticed that when the machine stucks while starting > X I am sometimes (~ 60%) able to ctrl-alt-backspace and it after some minutes > kills the X (= some sort of livelock?), after that I can 100% start the X > successfully... Mine doesn't happen boot -- it happens with the screensaver. Interestingly enough though, it happens less when I use a single screensaver instead of 2 separate screensavers. I'm going to put it back to 2 separate random screensavers and see what happens... -Garrett From yanefbsd at gmail.com Fri Jan 9 13:18:57 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Fri Jan 9 13:19:24 2009 Subject: X becomes unresponsive with nvidia / xscreensaver and desktop panics In-Reply-To: References: <7d6fde3d0901072349i50d04d2ch34f308388c9fd414@mail.gmail.com> Message-ID: <7d6fde3d0901090518j26dccc51v3f7be8e46ce0af77@mail.gmail.com> On Fri, Jan 9, 2009 at 1:37 AM, Doug Barton wrote: > On Wed, 7 Jan 2009, Garrett Cooper wrote: > >> Hello folks, >> As many probably know, I recently installed FreeBSD 8-CURRENT on my >> desktop. > > Why would we know that? I mean good for you, but seriously ... :) > >> One of the things I'm noting is that when I use dual displays with >> the nvidia driver, and xscreensaver kicks in and keeps going for a >> period of time, the machine's X.org console eats up a core, and when I >> try and do anything like gdb Xorg, the system hangs, attempts to panic >> (I assume that's the case because I hear it beep and attempt to >> restart), then I have to give it a warm boot. truss(1)'ing Xorg showed >> that there were a lot of SIGALARM's being fired and masked. > > No solutions, but a few general comments. First, I know that the author of > xscreensaver has put a lot of work into dual head stuff, and also that it > creates a lot of problems, so you're not alone here. If you get any > conclusive evidence that xscreensaver is at fault you should contact him at > http://www.jwz.org/xscreensaver/bugs.html > > A few things you can try to narrow it down .... first try turning off the > xscreensaver daemon and just run one of the screensaver programs full screen > for a while to see if that causes the crash. It's also worth testing GL vs. > non-GL screensavers. I had a problem with GL stuff for a while that was > fixed by an nvidia driver update a few versions ago. > > You should probably also try running with just the nv driver and see if that > causes the same crash. > > Finally, you might try setting debug.debugger_on_panic=0 in /etc/sysctl.conf > if you don't have it already. That will cause panics to go directly to > dumping which is useful if you're in X. > > > hth, > > Doug Thanks for the tips Doug -- I'll give them a shot of course... -Garrett From christoph.mallon at gmx.de Fri Jan 9 13:32:06 2009 From: christoph.mallon at gmx.de (Christoph Mallon) Date: Fri Jan 9 13:32:17 2009 Subject: gcc 4.3: when will it become standard compiler? In-Reply-To: <20090109110508.GA12123@freebsd.org> References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090108233311.GA69883@keltia.freenix.fr> <20090109031147.GB44317@duncan.reilly.home> <49672189.5060109@gmx.de> <20090109110508.GA12123@freebsd.org> Message-ID: <496751D1.20605@gmx.de> Roman Divacky schrieb: >> I'm not saying it's wrong to look for alternatives, but you cannot just >> change your system compiler like you change underwear. > > well... the first step is imho starting to compile world with C99... > that might reveal some bugs, note that as of a few months ago > 8-current compiles cleanly with C99, that does not mean that it's > working when you run those programs correctly :) One step in the right direction is embracing the nice features modern C offers you. For example declaring a variable right were you need it instead of dozens of lines away is one such nice thing which improves readability. Designated initializers improve readability, too. But I'm not exactly sure what you mean by "compile world with C99". C99 is pretty much backwards compatible to C89. >> PCC cannot seriously be considered. Its design is stuck in the >> seventies. From the point of view of compiler construction it is plain >> plain out of question. I especially was amused by the statement of the >> author who claimed PCC supports SSA - except for phi-functions. > > what's wrong with design stuck in 70's when it compiles the whole world/kernel? > > I would not use it for default compilation of releases but it might be > useful when you are developing - because of its fast compilation times If you want a real speed devil, try TCC. > btw.. are you sure the design is stuck in the 70's? the author claims > to have rewritten almost the whole thing. have you looked at the recent > code? It's still a simple tree based approach. From point of view of optimisations this often gets in the way. For example you need temporary variables as helper construct which just complicates things (yes, there are intermediate representations which do not have temporary variables at all). Much has happend in compiler land in the last 30 years. Now we have stuff like SSA and some are even doing code generation in this form. I can go into more details, but this is not the right place. > another question - how is libfirm/cparser? last time I tried it didnt > support much of the gcc options (-Wsomething -f-something etc.) so > it could not be used as a direct drop-in The next release will support several more switches for GCC compatibility. Here's the latest manpage: http://tron.homeunix.org/cparser.1 - you can view it with "nroff -man cparser.1". Switches like -Wl, and -Wp, are supported. Many bugs have been resolved. More warning options have been added - many similar to what GCC does, some doing a better job. We plan to make a new release Really Soon Now(TM). From rdivacky at freebsd.org Fri Jan 9 13:47:44 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Fri Jan 9 13:47:51 2009 Subject: gcc 4.3: when will it become standard compiler? In-Reply-To: <496751D1.20605@gmx.de> References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090108233311.GA69883@keltia.freenix.fr> <20090109031147.GB44317@duncan.reilly.home> <49672189.5060109@gmx.de> <20090109110508.GA12123@freebsd.org> <496751D1.20605@gmx.de> Message-ID: <20090109134725.GA38233@freebsd.org> On Fri, Jan 09, 2009 at 02:32:01PM +0100, Christoph Mallon wrote: > Roman Divacky schrieb: > >>I'm not saying it's wrong to look for alternatives, but you cannot just > >>change your system compiler like you change underwear. > > > >well... the first step is imho starting to compile world with C99... > >that might reveal some bugs, note that as of a few months ago > >8-current compiles cleanly with C99, that does not mean that it's > >working when you run those programs correctly :) > > One step in the right direction is embracing the nice features modern C > offers you. For example declaring a variable right were you need it > instead of dozens of lines away is one such nice thing which improves > readability. Designated initializers improve readability, too. > But I'm not exactly sure what you mean by "compile world with C99". C99 > is pretty much backwards compatible to C89. sorry for the bad wording - I meant to turn C99 compilation on default. We compile in gnu89 mode now. > >>PCC cannot seriously be considered. Its design is stuck in the > >>seventies. From the point of view of compiler construction it is plain > >>plain out of question. I especially was amused by the statement of the > >>author who claimed PCC supports SSA - except for phi-functions. > > > >what's wrong with design stuck in 70's when it compiles the whole > >world/kernel? > > > >I would not use it for default compilation of releases but it might be > >useful when you are developing - because of its fast compilation times > > If you want a real speed devil, try TCC. well.. tcc does not seem to be integrated by any *BSD while pcc has been adopted by netbsd and openbsd :) that shows it has something good (at least good promotion *grin*) > >btw.. are you sure the design is stuck in the 70's? the author claims > >to have rewritten almost the whole thing. have you looked at the recent > >code? > > It's still a simple tree based approach. From point of view of > optimisations this often gets in the way. For example you need temporary > variables as helper construct which just complicates things (yes, there > are intermediate representations which do not have temporary variables > at all). Much has happend in compiler land in the last 30 years. Now we > have stuff like SSA and some are even doing code generation in this > form. I can go into more details, but this is not the right place. ok.. I just wanted to be sure you looked at the new version. > >another question - how is libfirm/cparser? last time I tried it didnt > >support much of the gcc options (-Wsomething -f-something etc.) so > >it could not be used as a direct drop-in > > The next release will support several more switches for GCC > compatibility. Here's the latest manpage: > http://tron.homeunix.org/cparser.1 - you can view it with "nroff -man > cparser.1". Switches like -Wl, and -Wp, are supported. Many bugs have > been resolved. More warning options have been added - many similar to > what GCC does, some doing a better job. We plan to make a new release > Really Soon Now(TM). ok.. looking forward :) From estrabd at gmail.com Fri Jan 9 14:09:46 2009 From: estrabd at gmail.com (B. Estrade) Date: Fri Jan 9 14:09:53 2009 Subject: gcc 4.3: when will it become standard compiler? In-Reply-To: <20090109134725.GA38233@freebsd.org> References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090108233311.GA69883@keltia.freenix.fr> <20090109031147.GB44317@duncan.reilly.home> <49672189.5060109@gmx.de> <20090109110508.GA12123@freebsd.org> <496751D1.20605@gmx.de> <20090109134725.GA38233@freebsd.org> Message-ID: <20090109135215.GI1020@bc3.lsu.edu> On Fri, Jan 09, 2009 at 02:47:25PM +0100, Roman Divacky wrote: > On Fri, Jan 09, 2009 at 02:32:01PM +0100, Christoph Mallon wrote: > > Roman Divacky schrieb: > > >>I'm not saying it's wrong to look for alternatives, but you cannot just > > >>change your system compiler like you change underwear. > > > > > >well... the first step is imho starting to compile world with C99... > > >that might reveal some bugs, note that as of a few months ago > > >8-current compiles cleanly with C99, that does not mean that it's > > >working when you run those programs correctly :) > > > > One step in the right direction is embracing the nice features modern C > > offers you. For example declaring a variable right were you need it > > instead of dozens of lines away is one such nice thing which improves > > readability. Designated initializers improve readability, too. > > But I'm not exactly sure what you mean by "compile world with C99". C99 > > is pretty much backwards compatible to C89. > > sorry for the bad wording - I meant to turn C99 compilation on default. > We compile in gnu89 mode now. This is slightly off topic, but how important might it be wrt SMP progress for there to be OpenMP support in the C compiler? I am not suggesting this be part of any FreeBSD code, but I find having OpenMP support in the base compiler very appealing for many reasons - one of which is SMP benchmarking/testing. I ask because while shared memory executables produced by 4.2.1 are not the fastest (when using OpenMP), the directives are at least mostly supported. And I suppose that the later version of gcc will only get better. On the otherhand, other solutions don't seem to have this support whatsoever - so I ask again, how important might this kind of support be when considering /which/ compiler to use? Thank you, Brett > > > >>PCC cannot seriously be considered. Its design is stuck in the > > >>seventies. From the point of view of compiler construction it is plain > > >>plain out of question. I especially was amused by the statement of the > > >>author who claimed PCC supports SSA - except for phi-functions. > > > > > >what's wrong with design stuck in 70's when it compiles the whole > > >world/kernel? > > > > > >I would not use it for default compilation of releases but it might be > > >useful when you are developing - because of its fast compilation times > > > > If you want a real speed devil, try TCC. > > well.. tcc does not seem to be integrated by any *BSD while pcc has been > adopted by netbsd and openbsd :) that shows it has something good (at least > good promotion *grin*) > > > >btw.. are you sure the design is stuck in the 70's? the author claims > > >to have rewritten almost the whole thing. have you looked at the recent > > >code? > > > > It's still a simple tree based approach. From point of view of > > optimisations this often gets in the way. For example you need temporary > > variables as helper construct which just complicates things (yes, there > > are intermediate representations which do not have temporary variables > > at all). Much has happend in compiler land in the last 30 years. Now we > > have stuff like SSA and some are even doing code generation in this > > form. I can go into more details, but this is not the right place. > > ok.. I just wanted to be sure you looked at the new version. > > > >another question - how is libfirm/cparser? last time I tried it didnt > > >support much of the gcc options (-Wsomething -f-something etc.) so > > >it could not be used as a direct drop-in > > > > The next release will support several more switches for GCC > > compatibility. Here's the latest manpage: > > http://tron.homeunix.org/cparser.1 - you can view it with "nroff -man > > cparser.1". Switches like -Wl, and -Wp, are supported. Many bugs have > > been resolved. More warning options have been added - many similar to > > what GCC does, some doing a better job. We plan to make a new release > > Really Soon Now(TM). > > ok.. looking forward :) > _______________________________________________ > 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" -- B. Estrade Louisiana Optical Network Initiative +1.225.578.1920 aim: bz743 :wq From alexbestms at math.uni-muenster.de Fri Jan 9 14:12:14 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Fri Jan 9 14:12:22 2009 Subject: patch to fix burncd bug In-Reply-To: Message-ID: the actual problem is that the return value EBUSY got overwritten in sys/dev/ata/ata-queue.c. so even when the device returns EBUSY the ioctl call returned EIO. what your patch does is to wait for a specific time until it gives up calling ioctl(fd, CDIOCEJECT). with the changes to sys/dev/ata/atapi-cd.c the EBUSY return value doesn't get overwritten anymore. now when an ioctl call returns EIO you don't have to repeat doing the ioctl. EIO really means EIO! only if the return value is EBUSY you have to repeat doing an ioctl until it returns != EBUSY. alex Carlos A. M. dos Santos schrieb am 2009-01-09: > On Thu, Jan 8, 2009 at 8:59 PM, Giorgos Keramidas > wrote: > > On Thu, 08 Jan 2009 18:13:14 +0100 (CET), Alexander Best > > wrote: > >> could somebody please commit the following patch to dev/ata? it > >> fixes > >> a nasty bug during fixation in burncd. the bug exists in RELENG6, > >> RELENG7 and HEAD (and maybe RELENG5): > >> http://www.freebsd.org/cgi/query-pr.cgi?prp=95979-3-txt&n=/patch > >> the whole PR can be found here: > >> http://www.freebsd.org/cgi/query-pr.cgi?pr=95979 > > I think Soren is the best person to look into this bug (Cc: added). > > Soren, what do you think? Does the patch at bin/95979 look like a > > nice > > change to commit? I just saw this PR so I haven't tried the patch > > on my > > laptop's CURRENT yet, but I can confirm that burning CD-ROMs and > > DVDs is > > busted in my laptop for a few weeks now. > I proposed a solution a similar problem (bin/123693), but patching > burncd instead of the kernel. I'm attaching the patch, for your > convenience. From hselasky at c2i.net Fri Jan 9 14:12:36 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Fri Jan 9 14:12:50 2009 Subject: 3G modem and USB, old & new In-Reply-To: <21013.1231501594@critter.freebsd.dk> References: <21013.1231501594@critter.freebsd.dk> Message-ID: <200901091514.55076.hselasky@c2i.net> On Friday 09 January 2009, Poul-Henning Kamp wrote: > In message <200901091243.40981.hselasky@c2i.net>, Hans Petter Selasky writes: > >Which serial driver are you using? U3G? > > > >Are you using the latest code from -current ? > > I just compiled a USB2 kernel from yesterdays -current while sitting > in the train. Try connecting your device through an external USB HUB. --HPS From hselasky at c2i.net Fri Jan 9 14:12:36 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Fri Jan 9 14:12:51 2009 Subject: 3G modem and USB, old & new In-Reply-To: <21013.1231501594@critter.freebsd.dk> References: <21013.1231501594@critter.freebsd.dk> Message-ID: <200901091514.55076.hselasky@c2i.net> On Friday 09 January 2009, Poul-Henning Kamp wrote: > In message <200901091243.40981.hselasky@c2i.net>, Hans Petter Selasky writes: > >Which serial driver are you using? U3G? > > > >Are you using the latest code from -current ? > > I just compiled a USB2 kernel from yesterdays -current while sitting > in the train. Try connecting your device through an external USB HUB. --HPS From christoph.mallon at gmx.de Fri Jan 9 14:28:24 2009 From: christoph.mallon at gmx.de (Christoph Mallon) Date: Fri Jan 9 14:28:31 2009 Subject: gcc 4.3: when will it become standard compiler? In-Reply-To: <20090109134725.GA38233@freebsd.org> References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090108233311.GA69883@keltia.freenix.fr> <20090109031147.GB44317@duncan.reilly.home> <49672189.5060109@gmx.de> <20090109110508.GA12123@freebsd.org> <496751D1.20605@gmx.de> <20090109134725.GA38233@freebsd.org> Message-ID: <49675F04.20006@gmx.de> Roman Divacky schrieb: > On Fri, Jan 09, 2009 at 02:32:01PM +0100, Christoph Mallon wrote: >> Roman Divacky schrieb: >>>> I'm not saying it's wrong to look for alternatives, but you cannot just >>>> change your system compiler like you change underwear. >>> well... the first step is imho starting to compile world with C99... >>> that might reveal some bugs, note that as of a few months ago >>> 8-current compiles cleanly with C99, that does not mean that it's >>> working when you run those programs correctly :) >> One step in the right direction is embracing the nice features modern C >> offers you. For example declaring a variable right were you need it >> instead of dozens of lines away is one such nice thing which improves >> readability. Designated initializers improve readability, too. >> But I'm not exactly sure what you mean by "compile world with C99". C99 >> is pretty much backwards compatible to C89. > > sorry for the bad wording - I meant to turn C99 compilation on default. > We compile in gnu89 mode now. I still have no idea what you mean. Sure, you can specify -std=c99 (or more likely gnu99), but an int is still an int - what do you expect? In fact default mode of GCC accepts many C99 constructs like // comments and mixed declarations and code, which are not valid C89. From rdivacky at freebsd.org Fri Jan 9 14:33:53 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Fri Jan 9 14:33:59 2009 Subject: gcc 4.3: when will it become standard compiler? In-Reply-To: <49675F04.20006@gmx.de> References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090108233311.GA69883@keltia.freenix.fr> <20090109031147.GB44317@duncan.reilly.home> <49672189.5060109@gmx.de> <20090109110508.GA12123@freebsd.org> <496751D1.20605@gmx.de> <20090109134725.GA38233@freebsd.org> <49675F04.20006@gmx.de> Message-ID: <20090109143339.GA45569@freebsd.org> On Fri, Jan 09, 2009 at 03:28:20PM +0100, Christoph Mallon wrote: > Roman Divacky schrieb: > >On Fri, Jan 09, 2009 at 02:32:01PM +0100, Christoph Mallon wrote: > >>Roman Divacky schrieb: > >>>>I'm not saying it's wrong to look for alternatives, but you cannot just > >>>>change your system compiler like you change underwear. > >>>well... the first step is imho starting to compile world with C99... > >>>that might reveal some bugs, note that as of a few months ago > >>>8-current compiles cleanly with C99, that does not mean that it's > >>>working when you run those programs correctly :) > >>One step in the right direction is embracing the nice features modern C > >>offers you. For example declaring a variable right were you need it > >>instead of dozens of lines away is one such nice thing which improves > >>readability. Designated initializers improve readability, too. > >>But I'm not exactly sure what you mean by "compile world with C99". C99 > >>is pretty much backwards compatible to C89. > > > >sorry for the bad wording - I meant to turn C99 compilation on default. > >We compile in gnu89 mode now. > > I still have no idea what you mean. Sure, you can specify -std=c99 (or > more likely gnu99), but an int is still an int - what do you expect? In > fact default mode of GCC accepts many C99 constructs like // comments > and mixed declarations and code, which are not valid C89. for example __restricted is C99 thing and there are others, I want this because clang for example defaults to C99 (in fact gnu99 as they support gnu extensions on default). By switching to default compilation in C99 mode we can be sure we stay compatible with clang and others.... for example opensolaris seems to use C99 features which are not enabled in our world because of this (I found same assert() related stuff) etc. plus other benefits of the newer languge standard From christoph.mallon at gmx.de Fri Jan 9 14:56:29 2009 From: christoph.mallon at gmx.de (Christoph Mallon) Date: Fri Jan 9 14:56:37 2009 Subject: gcc 4.3: when will it become standard compiler? In-Reply-To: <20090109143339.GA45569@freebsd.org> References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090108233311.GA69883@keltia.freenix.fr> <20090109031147.GB44317@duncan.reilly.home> <49672189.5060109@gmx.de> <20090109110508.GA12123@freebsd.org> <496751D1.20605@gmx.de> <20090109134725.GA38233@freebsd.org> <49675F04.20006@gmx.de> <20090109143339.GA45569@freebsd.org> Message-ID: <49676598.7040708@gmx.de> Roman Divacky schrieb: > On Fri, Jan 09, 2009 at 03:28:20PM +0100, Christoph Mallon wrote: >> Roman Divacky schrieb: >>> On Fri, Jan 09, 2009 at 02:32:01PM +0100, Christoph Mallon wrote: >>>> Roman Divacky schrieb: >>>>>> I'm not saying it's wrong to look for alternatives, but you cannot just >>>>>> change your system compiler like you change underwear. >>>>> well... the first step is imho starting to compile world with C99... >>>>> that might reveal some bugs, note that as of a few months ago >>>>> 8-current compiles cleanly with C99, that does not mean that it's >>>>> working when you run those programs correctly :) >>>> One step in the right direction is embracing the nice features modern C >>>> offers you. For example declaring a variable right were you need it >>>> instead of dozens of lines away is one such nice thing which improves >>>> readability. Designated initializers improve readability, too. >>>> But I'm not exactly sure what you mean by "compile world with C99". C99 >>>> is pretty much backwards compatible to C89. >>> sorry for the bad wording - I meant to turn C99 compilation on default. >>> We compile in gnu89 mode now. >> I still have no idea what you mean. Sure, you can specify -std=c99 (or >> more likely gnu99), but an int is still an int - what do you expect? In >> fact default mode of GCC accepts many C99 constructs like // comments >> and mixed declarations and code, which are not valid C89. > > for example __restricted is C99 thing and there are others, I want this __restrict (not __restricted) is a GCC extension. The C99 spelling is restrict. GCC also accepts __restrict__. Further, you should be *very* careful with the restrict qualifier, because its exact semantic is non-trivial (?6.7.3.1, it's one page of standardese speak). But I see no problem for existing code in this respect. C99 mostly only adds new language constructs. Only very few were removed. E.g. implicit int was removed, but GCC still accepts it (and I guess clang too, cpareser does). > because clang for example defaults to C99 (in fact gnu99 as they support > gnu extensions on default). By switching to default compilation in C99 > mode we can be sure we stay compatible with clang and others.... I'm pretty sure clang also accepts __restrict. A compiler, which does not support most GCC extensions (inline assembler being the most important) has no chance anyway. > for example opensolaris seems to use C99 features which are not enabled > in our world because of this (I found same assert() related stuff) etc. assert() predates C99. The only C99 specific aspect about assert(), that I'm aware of, is, that C99 guarantees that the name of the function is printed. From rdivacky at freebsd.org Fri Jan 9 15:08:14 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Fri Jan 9 15:08:22 2009 Subject: gcc 4.3: when will it become standard compiler? In-Reply-To: <49676598.7040708@gmx.de> References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090108233311.GA69883@keltia.freenix.fr> <20090109031147.GB44317@duncan.reilly.home> <49672189.5060109@gmx.de> <20090109110508.GA12123@freebsd.org> <496751D1.20605@gmx.de> <20090109134725.GA38233@freebsd.org> <49675F04.20006@gmx.de> <20090109143339.GA45569@freebsd.org> <49676598.7040708@gmx.de> Message-ID: <20090109150750.GA50331@freebsd.org> On Fri, Jan 09, 2009 at 03:56:24PM +0100, Christoph Mallon wrote: > Roman Divacky schrieb: > >On Fri, Jan 09, 2009 at 03:28:20PM +0100, Christoph Mallon wrote: > >>Roman Divacky schrieb: > >>>On Fri, Jan 09, 2009 at 02:32:01PM +0100, Christoph Mallon wrote: > >>>>Roman Divacky schrieb: > >>>>>>I'm not saying it's wrong to look for alternatives, but you cannot > >>>>>>just change your system compiler like you change underwear. > >>>>>well... the first step is imho starting to compile world with C99... > >>>>>that might reveal some bugs, note that as of a few months ago > >>>>>8-current compiles cleanly with C99, that does not mean that it's > >>>>>working when you run those programs correctly :) > >>>>One step in the right direction is embracing the nice features modern C > >>>>offers you. For example declaring a variable right were you need it > >>>>instead of dozens of lines away is one such nice thing which improves > >>>>readability. Designated initializers improve readability, too. > >>>>But I'm not exactly sure what you mean by "compile world with C99". C99 > >>>>is pretty much backwards compatible to C89. > >>>sorry for the bad wording - I meant to turn C99 compilation on default. > >>>We compile in gnu89 mode now. > >>I still have no idea what you mean. Sure, you can specify -std=c99 (or > >>more likely gnu99), but an int is still an int - what do you expect? In > >>fact default mode of GCC accepts many C99 constructs like // comments > >>and mixed declarations and code, which are not valid C89. > > > >for example __restricted is C99 thing and there are others, I want this > > __restrict (not __restricted) is a GCC extension. The C99 spelling is > restrict. GCC also accepts __restrict__. Further, you should be *very* > careful with the restrict qualifier, because its exact semantic is > non-trivial (?6.7.3.1, it's one page of standardese speak). > But I see no problem for existing code in this respect. C99 mostly only > adds new language constructs. Only very few were removed. E.g. implicit > int was removed, but GCC still accepts it (and I guess clang too, > cpareser does). my point is that in C89 mode *restrict* (in whatever spelling) got expanded to nothing. we had a bug (typo in fact) related to *restrict* and we didnt catch it because of C89 compilation mode... thats my point (and the *restrict* thing is just an example) > >because clang for example defaults to C99 (in fact gnu99 as they support > >gnu extensions on default). By switching to default compilation in C99 > > >mode we can be sure we stay compatible with clang and others.... > > I'm pretty sure clang also accepts __restrict. > A compiler, which does not support most GCC extensions (inline assembler > being the most important) has no chance anyway. yes.... the problem is (was?) that clang is C99 on default while gcc is C89 on default. > >for example opensolaris seems to use C99 features which are not enabled > >in our world because of this (I found same assert() related stuff) etc. > > assert() predates C99. The only C99 specific aspect about assert(), that > I'm aware of, is, that C99 guarantees that the name of the function is > printed. they had code like #if C99 #define __assert(..) something #else #define __assert(..) something_else #endif my point is that we might have bugs in the C99 code that other (non-gcc) compilers expose and it's a good thing to unite on one standard. ie. C99 :) From sgk at troutmask.apl.washington.edu Fri Jan 9 15:11:25 2009 From: sgk at troutmask.apl.washington.edu (Steve Kargl) Date: Fri Jan 9 15:11:32 2009 Subject: gcc 4.3: when will it become standard compiler? In-Reply-To: <20090109084908.GA76970@keltia.freenix.fr> References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090109002133.GA92874@troutmask.apl.washington.edu> <20090109084908.GA76970@keltia.freenix.fr> Message-ID: <20090109151123.GA97988@troutmask.apl.washington.edu> On Fri, Jan 09, 2009 at 09:49:11AM +0100, Ollivier Robert wrote: > According to Steve Kargl: > > Probably not for a very long time. gcc 4.3 requires both GMP and > > MPFR libraries. Neither library is in src. > > I do not know what MPFR is (something about FP, right?) but I wonder at why > GMP could be needed by a compiler... > http://www.mpfr.org/ The MPFR library is a C library for multiple-precision floating-point computations with correct rounding. It's used for constant folding. -- Steve From rwatson at FreeBSD.org Fri Jan 9 15:27:12 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Fri Jan 9 15:27:18 2009 Subject: Extattr portability? In-Reply-To: <4965927D.1060507@freebsd.org> References: <4965927D.1060507@freebsd.org> Message-ID: On Wed, 7 Jan 2009, Tim Kientzle wrote: > I'm trying to complete the extended attribute support in libarchive. There > are a handful of odd issues that arise which I think I could resolve if I > knew of good use cases. > > Anyone here actually use extended attributes? (Note that ACLs are handled > separately.) What software? What information do you store there? > > If you could benefit from being able to move extended attributes between > FreeBSD and other systems, I'm especially interested. Most (all) of the use of extended attributes that I'm aware of on FreeBSD relates to security extensions, be it ACLs, MAC labels (almost always in the system namespace) for various policies, etc. Mac OS X is now using extended attributes in quite a few more ways, however, so you may want to investigate a bit on that side. Most uses I'm aware of aren't intended to be portable. Robert N M Watson Computer Laboratory University of Cambridge From christoph.mallon at gmx.de Fri Jan 9 15:53:13 2009 From: christoph.mallon at gmx.de (Christoph Mallon) Date: Fri Jan 9 15:53:20 2009 Subject: gcc 4.3: when will it become standard compiler? In-Reply-To: <20090109150750.GA50331@freebsd.org> References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090108233311.GA69883@keltia.freenix.fr> <20090109031147.GB44317@duncan.reilly.home> <49672189.5060109@gmx.de> <20090109110508.GA12123@freebsd.org> <496751D1.20605@gmx.de> <20090109134725.GA38233@freebsd.org> <49675F04.20006@gmx.de> <20090109143339.GA45569@freebsd.org> <49676598.7040708@gmx.de> <20090109150750.GA50331@freebsd.org> Message-ID: <496772E1.2050504@gmx.de> Roman Divacky schrieb: > On Fri, Jan 09, 2009 at 03:56:24PM +0100, Christoph Mallon wrote: >> Roman Divacky schrieb: >>> On Fri, Jan 09, 2009 at 03:28:20PM +0100, Christoph Mallon wrote: >>>> Roman Divacky schrieb: >>>>> On Fri, Jan 09, 2009 at 02:32:01PM +0100, Christoph Mallon wrote: >>>>>> Roman Divacky schrieb: >>>>>>>> I'm not saying it's wrong to look for alternatives, but you cannot >>>>>>>> just change your system compiler like you change underwear. >>>>>>> well... the first step is imho starting to compile world with C99... >>>>>>> that might reveal some bugs, note that as of a few months ago >>>>>>> 8-current compiles cleanly with C99, that does not mean that it's >>>>>>> working when you run those programs correctly :) >>>>>> One step in the right direction is embracing the nice features modern C >>>>>> offers you. For example declaring a variable right were you need it >>>>>> instead of dozens of lines away is one such nice thing which improves >>>>>> readability. Designated initializers improve readability, too. >>>>>> But I'm not exactly sure what you mean by "compile world with C99". C99 >>>>>> is pretty much backwards compatible to C89. >>>>> sorry for the bad wording - I meant to turn C99 compilation on default. >>>>> We compile in gnu89 mode now. >>>> I still have no idea what you mean. Sure, you can specify -std=c99 (or >>>> more likely gnu99), but an int is still an int - what do you expect? In >>>> fact default mode of GCC accepts many C99 constructs like // comments >>>> and mixed declarations and code, which are not valid C89. >>> for example __restricted is C99 thing and there are others, I want this >> __restrict (not __restricted) is a GCC extension. The C99 spelling is >> restrict. GCC also accepts __restrict__. Further, you should be *very* >> careful with the restrict qualifier, because its exact semantic is >> non-trivial (?6.7.3.1, it's one page of standardese speak). >> But I see no problem for existing code in this respect. C99 mostly only >> adds new language constructs. Only very few were removed. E.g. implicit >> int was removed, but GCC still accepts it (and I guess clang too, >> cpareser does). > > my point is that in C89 mode *restrict* (in whatever spelling) got expanded > to nothing. we had a bug (typo in fact) related to *restrict* and we didnt > catch it because of C89 compilation mode... Ah, you mean a simple syntax error like char __restrict* a instead of char* __restrict a. I thought you meant something serious like different behaviour between the standards. Why somebody would #define away __restrict (or #define away any other extension, which GCC accepts anyway) is beyond me. If the source code already contains distinctions between C89 and C99 then, imo, somebody did something wrong. > thats my point (and the *restrict* thing is just an example) > >>> because clang for example defaults to C99 (in fact gnu99 as they support >>> gnu extensions on default). By switching to default compilation in C99 >>> mode we can be sure we stay compatible with clang and others.... >> I'm pretty sure clang also accepts __restrict. >> A compiler, which does not support most GCC extensions (inline assembler >> being the most important) has no chance anyway. > > yes.... the problem is (was?) that clang is C99 on default while gcc is C89 > on default. > >>> for example opensolaris seems to use C99 features which are not enabled >>> in our world because of this (I found same assert() related stuff) etc. >> assert() predates C99. The only C99 specific aspect about assert(), that >> I'm aware of, is, that C99 guarantees that the name of the function is >> printed. > > they had code like > > > #if C99 > #define __assert(..) something > #else > #define __assert(..) something_else > #endif > This is probably, as mentioned above, because C89 does not have __func__. > my point is that we might have bugs in the C99 code that other (non-gcc) compilers > expose and it's a good thing to unite on one standard. ie. C99 :) In general I agree: C99 should be used as language standard for compilation. style(9) needs some updates for this, too. From rdivacky at freebsd.org Fri Jan 9 17:28:15 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Fri Jan 9 17:28:23 2009 Subject: gcc 4.3: when will it become standard compiler? In-Reply-To: <496772E1.2050504@gmx.de> References: <20090109031147.GB44317@duncan.reilly.home> <49672189.5060109@gmx.de> <20090109110508.GA12123@freebsd.org> <496751D1.20605@gmx.de> <20090109134725.GA38233@freebsd.org> <49675F04.20006@gmx.de> <20090109143339.GA45569@freebsd.org> <49676598.7040708@gmx.de> <20090109150750.GA50331@freebsd.org> <496772E1.2050504@gmx.de> Message-ID: <20090109172747.GA69471@freebsd.org> > >my point is that in C89 mode *restrict* (in whatever spelling) got expanded > >to nothing. we had a bug (typo in fact) related to *restrict* and we didnt > >catch it because of C89 compilation mode... > > Ah, you mean a simple syntax error like char __restrict* a instead of > char* __restrict a. I thought you meant something serious like different > behaviour between the standards. Why somebody would #define away > __restrict (or #define away any other extension, which GCC accepts > anyway) is beyond me. If the source code already contains distinctions > between C89 and C99 then, imo, somebody did something wrong. my point was general - people expect C99 features and use them (it's 10 years old) but we dont compile in that mode - this mismatch may yield weird bugs > >my point is that we might have bugs in the C99 code that other (non-gcc) > >compilers > >expose and it's a good thing to unite on one standard. ie. C99 :) > > In general I agree: C99 should be used as language standard for > compilation. style(9) needs some updates for this, too. I hope we'll have C99 on default soon :) From bms at incunabulum.net Fri Jan 9 19:59:37 2009 From: bms at incunabulum.net (Bruce Simpson) Date: Fri Jan 9 19:59:43 2009 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: References: <20081227202117.F3B14341A3@cavin02.kulnet.kuleuven.ac.be><200812281613.49404.tijl@ulyssis.org> Message-ID: <4967ACA5.6080502@incunabulum.net> +1 for introducing RTF_LLINFO backwards compatibility. I had to sneak in a fix to XORP and pretty much broke release protocol to do so. From w8hdkim at gmail.com Fri Jan 9 20:43:41 2009 From: w8hdkim at gmail.com (Kim Culhan) Date: Fri Jan 9 20:43:47 2009 Subject: msk Marvell Yukon 88E8038 hangs In-Reply-To: <20090109061032.GF30747@cdnetworks.co.kr> References: <89dbfdc30901071438j314ac431h491f9494593caf64@mail.gmail.com> <20090108011220.GA1256@cdnetworks.co.kr> <89dbfdc30901072336l62c46214i113cccf9985bcdae@mail.gmail.com> <20090108075159.GH1256@cdnetworks.co.kr> <89dbfdc30901080835g67b996f4i50e734f0791a0d56@mail.gmail.com> <20090109061032.GF30747@cdnetworks.co.kr> Message-ID: <89dbfdc30901091243w1d01ab59mc2ade81e65e51c5d@mail.gmail.com> On Fri, Jan 9, 2009 at 1:10 AM, Pyun YongHyeon wrote: > On Thu, Jan 08, 2009 at 11:35:28AM -0500, Kim Culhan wrote: > > On Thu, Jan 8, 2009 at 2:51 AM, Pyun YongHyeon wrote: > > > On Thu, Jan 08, 2009 at 02:36:48AM -0500, Kim Culhan wrote: > > > > On Wed, Jan 7, 2009 at 8:12 PM, Pyun YongHyeon wrote: > > > > > On Wed, Jan 07, 2009 at 05:38:28PM -0500, Kim Culhan wrote: > > > > > > The msk interface on an Acer Aspire 5570Z hangs, frequently when running cvsup. > > > > > > > > > > > > Not necessarily at each hang but sometimes coincident, this is > > > > > > intermittently output to the console: > > > > > > > > > > > > in_cksum_skip: out of data by 56952 > > > > > > > > > > > > The above is also output to the console at times when receiving a > > > > > > character through ssh > > > > > > to a shell. > > > > > > > > > > > > The in_cksum_skip messages and msk hangs are also present on this hardware > > > > > > running 7.1-RELEASE. [deleted] > Ok, then how about disabling TSO/Tx checksum offload? > (eg. ifconfig msk0 -tso -txcsum) This stops the messages: in_cksum_skip: out of data by 56952 -kim From nick at van-laarhoven.org Fri Jan 9 20:58:11 2009 From: nick at van-laarhoven.org (Nick Hibma) Date: Fri Jan 9 20:58:18 2009 Subject: 3G modem and USB, old & new In-Reply-To: <3994.1231494833@critter.freebsd.dk> References: <3994.1231494833@critter.freebsd.dk> Message-ID: <200901092146.01009.nick@van-laarhoven.org> Poul-Henning, I have had many reports of devices working. I've also had several people report that the device failed miserably with similar problems like you are perceiving. I am talking oldusb here, as that is what I am familiar with. I've not been able to reproduce the problems reliably. But looking at the symptoms somehow buffering goes pear-shaped somewhere. There is no buffering being done in the u3g code.That's all handled by ucom, but to me that looks like cut&paste from other code. So I presume (wildly pointing fingers at code I do not yet understand) that the problem is somewhere in the combination of ucom and tty layer, or perhaps even in the TTY layer. Perhaps you have a clue as to where in the TTY layer we could look for problems? The usage patterns for the u3g devices is much different from other serial devices, as a) the speeds are much higher than other serial (USB) devices, and b) data arrives in large chunks of several kb in some cases. Any pointers would be appreciated. Nick > I tried using my 3g modem (Huawei E196) yesterday, with both the > old and the new USB stack, and it fails in slightly different > ways. > > With the old USB stack, it works until I actually try to get a packet > of more than approx 1024 bytes through, at which point it hangs with > ucom0: ucomreadcb: IOERROR > And I need to stop and start ppp(1) to get it working until the next > big packet comes around. > > It does not help to reduce the MRU because two small packets back to > back will also trigger this error. > > With the new USB stack, I am not able to talk to the modem at all > using the cuaU* devices. From phk at phk.freebsd.dk Fri Jan 9 21:10:13 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri Jan 9 21:10:25 2009 Subject: 3G modem and USB, old & new In-Reply-To: Your message of "Fri, 09 Jan 2009 21:46:00 +0100." <200901092146.01009.nick@van-laarhoven.org> Message-ID: <23654.1231535410@critter.freebsd.dk> In message <200901092146.01009.nick@van-laarhoven.org>, Nick Hibma writes: >I've not been able to reproduce the problems reliably. But looking at the >symptoms somehow buffering goes pear-shaped somewhere. There is no >buffering being done in the u3g code.That's all handled by ucom, but to me >that looks like cut&paste from other code. So I presume (wildly pointing >fingers at code I do not yet understand) that the problem is somewhere in >the combination of ucom and tty layer, or perhaps even in the TTY layer. I can shoot that theory down right away: It worked great when I hacked the magic mode bit support into ubsa.c It must be a u3g issue. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From dougb at FreeBSD.org Fri Jan 9 21:40:40 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Fri Jan 9 21:40:47 2009 Subject: X becomes unresponsive with nvidia / xscreensaver and desktop panics In-Reply-To: <7d6fde3d0901090518j26dccc51v3f7be8e46ce0af77@mail.gmail.com> References: <7d6fde3d0901072349i50d04d2ch34f308388c9fd414@mail.gmail.com> <7d6fde3d0901090518j26dccc51v3f7be8e46ce0af77@mail.gmail.com> Message-ID: <4967C455.1040700@FreeBSD.org> Garrett Cooper wrote: > Thanks for the tips Doug -- I'll give them a shot of course... Glad I could help. The one thing I forgot to mention is to try the nvidia-settings app if you have not already done so. There are various things there that you can tweak that might yield better results. Doug -- This .signature sanitized for your protection From nick at van-laarhoven.org Fri Jan 9 21:45:27 2009 From: nick at van-laarhoven.org (Nick Hibma) Date: Fri Jan 9 21:45:35 2009 Subject: 3G modem and USB, old & new In-Reply-To: <23654.1231535410@critter.freebsd.dk> References: <23654.1231535410@critter.freebsd.dk> Message-ID: <200901092245.16450.nick@van-laarhoven.org> > >I've not been able to reproduce the problems reliably. But looking at > > the symptoms somehow buffering goes pear-shaped somewhere. There is no > > buffering being done in the u3g code.That's all handled by ucom, but to > > me that looks like cut&paste from other code. So I presume (wildly > > pointing fingers at code I do not yet understand) that the problem is > > somewhere in the combination of ucom and tty layer, or perhaps even in > > the TTY layer. > > I can shoot that theory down right away: It worked great when I hacked > the magic mode bit support into ubsa.c > > It must be a u3g issue. Explain that to the people that get great performance on u3g, which had big troubles using ubsa (the same problems you are seeing; me for one). So I am pretty sure I am right. Second: I've had reports of E220 working and the same device not working and choking on 'AT' on the second channel. It is most definitely a buffering issue. Perhaps the buffers are not properly configured, but making them larger or smaller does not change the symptoms in any case for these people. Would you know of a serial device using tty layer code with high speed serial links that I could look at to see what could be wrong in either u3g and/or ucom? Thanks. Nick From dougb at FreeBSD.org Fri Jan 9 21:47:06 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Fri Jan 9 21:47:12 2009 Subject: gcc 4.3: when will it become standard compiler? In-Reply-To: <4967259C.9090408@stillbilde.net> References: <49668763.8020705@mail.zedat.fu-berlin.de> <49671748.3030709@gmx.de> <4967259C.9090408@stillbilde.net> Message-ID: <4967C5D5.7030608@FreeBSD.org> Svein Skogen (List Mail Account) wrote: > Would it be possible, as a "workaround" to have "system-CC" and > "ports-CC" defined in make.conf, making one CC the compiler for /usr/src > and another for ports, or would this just create debugging nightmares? You can do that now. Install ports-mgmt/portconf and set a global for CC accordingly. hth, Doug -- This .signature sanitized for your protection From miwi at FreeBSD.org Fri Jan 9 22:05:12 2009 From: miwi at FreeBSD.org (Martin Wilke) Date: Fri Jan 9 22:05:19 2009 Subject: panic in bundirty In-Reply-To: <49613379.8040901@vwsoft.com> References: <49613379.8040901@vwsoft.com> Message-ID: <20090109214934.GC99849@bsdcrew.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Any news here? On Sun, Jan 04, 2009 at 11:08:57PM +0100, Volker wrote: > Gentlemen, > > I've had the pleasure to inspect miwi's new tinderbox machine in a panic > situation. > > The debugging info we're able to get out of the box is the following: > > panic: bundirty: buffer 0xffffffff9a475438 still on queue 1 > > #9 0xffffffff8049f196 in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:556 > #10 0xffffffff8050b540 in bundirty (bp=Variable "bp" is not available. > ) at /usr/src/sys/kern/vfs_bio.c:1068 > #11 0xffffffff8050d684 in brelse (bp=0xffffffff9a475438) > at /usr/src/sys/kern/vfs_bio.c:1388 > #12 0xffffffff8050f07c in bufdone (bp=0xffffffff9a475438) > at /usr/src/sys/kern/vfs_bio.c:3157 > #13 0xffffffff8069cb6c in ffs_backgroundwritedone (bp=0xffffffff9a475438) > ---Type to continue, or q to quit--- > at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1679 > #14 0xffffffff8050f051 in bufdone (bp=0xffffffff9a475438) > at /usr/src/sys/kern/vfs_bio.c:3151 > #15 0xffffffff80452b51 in g_io_schedule_up (tp=Variable "tp" is not > available. > ) > at /usr/src/sys/geom/geom_io.c:587 > #16 0xffffffff8045323f in g_up_procbody () at > /usr/src/sys/geom/geom_kern.c:95 > #17 0xffffffff8048037a in fork_exit ( > callout=0xffffffff804531d0 , arg=0x0, > frame=0xffffffff80e63c80) at /usr/src/sys/kern/kern_fork.c:789 > > in frame 11, 'p *bp' gives: > $1 = {b_bufobj = 0xffffff00034fe958, b_bcount = 16384, b_caller1 = 0x0, > b_data = 0xffffffff9f4b7000 "", b_error = 5, b_iocmd = 2 '\002', > b_ioflags = 2 '\002', b_iooffset = 7127891968, b_resid = 16384, > b_iodone = 0, b_blkno = 13921664, b_offset = 7127891968, b_bobufs = { > tqe_next = 0xffffffff9a505a38, tqe_prev = 0xffffff00034fe9a8}, > b_left = 0x0, b_right = 0xffffffff9a505a38, b_vflags = 0, b_freelist = { > tqe_next = 0xffffffff9a472db8, tqe_prev = 0xffffffff80b56210}, > b_qindex = 1, b_flags = 41092, b_xflags = 33 '!', b_lock = > {lock_object = { > lo_name = 0xffffffff8083ce18 "bufwait", > lo_type = 0xffffffff8083ce18 "bufwait", lo_flags = 91947008, > lo_witness_data = {lod_list = {stqe_next = 0xffffffff80ae6f80}, > lod_witness = 0xffffffff80ae6f80}}, lk_lock = 18446744073709551608, > lk_recurse = 0, lk_timo = 0, lk_pri = 80}, b_bufsize = 16384, > b_runningbufspace = 0, b_kvabase = 0xffffffff9f4b7000 "", b_kvasize = > 16384, > b_lblkno = 13921664, b_vp = 0xffffff00034fe820, b_dirtyoff = 0, > b_dirtyend = 0, b_rcred = 0x0, b_wcred = 0x0, > b_saveaddr = 0xffffffff9f4b7000, b_pager = {pg_reqpage = 0}, b_cluster = { > cluster_head = {tqh_first = 0xffffffff9a479c68, > tqh_last = 0xffffffff9a4901b0}, cluster_entry = { > tqe_next = 0xffffffff9a479c68, tqe_prev = 0xffffffff9a4901b0}}, > b_pages = {0xffffff00de0eafa0, 0xffffff00de0eb010, 0xffffff00de0eb080, > 0xffffff00de0eb0f0, 0x0 }, b_npages = 4, b_dep = { > lh_first = 0x0}, b_fsprivate1 = 0x0, b_fsprivate2 = 0x0, > b_fsprivate3 = 0x0, b_pin_count = 0} > > This panic does not occur before commit 176708. > > The panic is in sys/kern/vfs_bio.c bundirty 1055: > KASSERT( bp->b_flags & B_REMFREE || bp->b_qindex == QUEUE_NONE ... > > bp->b_qindex = 0x01 (QUEUE_FREE) > bp->b_flags = 0xa084 (B_ASYNC | B_DELWRI | B_NOCACHE | B_INVAL) > > My assumption is: > > brele knows about the QUEUE_FREE but bundirty only wants to operate on > QUEUE_NONE. Either this is a race condition, brele should not call > bundirty or bundirty should operate not just on QUEUE_NONE buffers. > > As there have been some locking related commits in the changes in > question, this might also be caused by an unlocked operation. > > right before the panic, we're seeing DMA errors: > > ad6: setting up DMA failed > _vfs_done():ad6[WRITE(offset=5412487168, length=131072)]error = 5 > ad6: FAILURE - load data > ad6: setting up DMA failed > g_vfs_done():ad6[WRITE(offset=5044109312, length=131072)]error = 5 > g_vfs_done():ad6[WRITE(offset=5230985216, length=131072)]error = 5 > g_vfs_done():ad6[WRITE(offset=5231116288, length=131072)]error = 5 > g_vfs_done():ad6[WRITE(offset=5044240384, length=131072)]error = 5 > g_vfs_done():ad6[WRITE(offset=5412618240, length=131072)]error = 5 > g_vfs_done():ad4s1d[WRITE(offset=7127891968, length=16384)]error = 5 > > kgdb output can be found at: > http://www.bsdmeat.net/~lando/miwi/kgdb.txt > > Suggestions what the correct fix to this issue is? Change bundirty or > brele? Clean up locking? > > CC'ing those who committed to vfs_bio.c in the relevant time frame. > > Thanks > > Volker > _______________________________________________ > 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" > - -- +-----------------------+-------------------------------+ | PGP : 0x05682353 | Jabber : miwi(at)BSDCrew.de | | ICQ : 169139903 | Mail : miwi(at)FreeBSD.org | +-----------------------+-------------------------------+ | Mess with the Best, Die like the Rest! | +-----------------------+-------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAklnxm0ACgkQFwpycAVoI1OZ7wCdFQ5FxqVkFcROpBTe2ws79ARv 378An3ez8Zb8Z2vo7nq2WBwRaOe93zdz =hKtf -----END PGP SIGNATURE----- From yanefbsd at gmail.com Fri Jan 9 22:05:57 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Fri Jan 9 22:06:04 2009 Subject: X becomes unresponsive with nvidia / xscreensaver and desktop panics In-Reply-To: <4967C455.1040700@FreeBSD.org> References: <7d6fde3d0901072349i50d04d2ch34f308388c9fd414@mail.gmail.com> <7d6fde3d0901090518j26dccc51v3f7be8e46ce0af77@mail.gmail.com> <4967C455.1040700@FreeBSD.org> Message-ID: <7d6fde3d0901091405p1e3f61e4o166eb1acfa3aadcb@mail.gmail.com> On Fri, Jan 9, 2009 at 1:40 PM, Doug Barton wrote: > Garrett Cooper wrote: >> Thanks for the tips Doug -- I'll give them a shot of course... > > Glad I could help. The one thing I forgot to mention is to try the > nvidia-settings app if you have not already done so. There are various > things there that you can tweak that might yield better results. > > Doug I did in fact set everything up via nvidia-settings. I'm running some stress tests right now to see whether or not I can simulate the issue -- it doesn't appear to be as straightforward as I thought.. -Garrett From alexanderchuranov at gmail.com Fri Jan 9 22:13:01 2009 From: alexanderchuranov at gmail.com (Alexander Churanov) Date: Fri Jan 9 22:13:07 2009 Subject: gcc 4.3: when will it become standard compiler? In-Reply-To: <49675F04.20006@gmx.de> References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090108233311.GA69883@keltia.freenix.fr> <20090109031147.GB44317@duncan.reilly.home> <49672189.5060109@gmx.de> <20090109110508.GA12123@freebsd.org> <496751D1.20605@gmx.de> <20090109134725.GA38233@freebsd.org> <49675F04.20006@gmx.de> Message-ID: <3cb459ed0901091412o5861ec59web9b48d264ca053b@mail.gmail.com> Folks, The '-std=c99'' only instructs GCC to allow the whole of C99. This is clearly not enough, because this mode allows too many GCC extensions. If you compile your code in "default' mode or just specify '-std=c99', then it's very likely that you will eventually get stuck to GCC. Using this approach you are reducing chances to switch to another C99 compiler. Though I am not aware of any other open source compiler supporting C99, I beleive that there is great need for it. This discussion indicates that there is real necessity for BSD-licensed C99 compiler. That's why I am always propagandizing the following: "-Wall -Werror -std=c99 -pedantic". To my mind, this helps to prepear your code for eventual switching to another standard-compliant compiler. Alexander From rdivacky at freebsd.org Fri Jan 9 22:22:36 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Fri Jan 9 22:22:44 2009 Subject: gcc 4.3: when will it become standard compiler? In-Reply-To: <3cb459ed0901091412o5861ec59web9b48d264ca053b@mail.gmail.com> References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090108233311.GA69883@keltia.freenix.fr> <20090109031147.GB44317@duncan.reilly.home> <49672189.5060109@gmx.de> <20090109110508.GA12123@freebsd.org> <496751D1.20605@gmx.de> <20090109134725.GA38233@freebsd.org> <49675F04.20006@gmx.de> <3cb459ed0901091412o5861ec59web9b48d264ca053b@mail.gmail.com> Message-ID: <20090109222211.GA33145@freebsd.org> On Sat, Jan 10, 2009 at 01:12:57AM +0300, Alexander Churanov wrote: > Folks, > > The '-std=c99'' only instructs GCC to allow the whole of C99. This is > clearly not enough, because this mode allows too many GCC extensions. If you > compile your code in "default' mode or just specify '-std=c99', then it's > very likely that you will eventually get stuck to GCC. Using this approach > you are reducing chances to switch to another C99 compiler. > > Though I am not aware of any other open source compiler supporting C99, I > beleive that there is great need for it. This discussion indicates that > there is real necessity for BSD-licensed C99 compiler. clang (clang.llvm.org) supports almost everything now and aims for full C99 support. pcc aims for full C99 too I believe Chris Mallon can comment better but I believe cparser is C99 too am I missing something? From pluknet at gmail.com Fri Jan 9 22:28:26 2009 From: pluknet at gmail.com (pluknet) Date: Fri Jan 9 22:28:32 2009 Subject: kernel doesn't boot when is built with ukbd/ums Message-ID: Hi. Today I noticed that when kernel has build-in ums and ukbd support, it stops booting with the last seen messages (transcribed): ... uart0: [FILTER] atkbdc0: port 0x60,0x64 irq1 on acpi0 [stops here] ... It boots fine if kernel is built without ums and ukbd devices (and they loaded as modules). And I see in this case. ... atrtc0: port 0x70-0x71 irq 8 on acpi0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] cpu0: on acpi0 ... In both cases I have in loader.conf: ums_load="YES" ukbd_load="YES" I would jump in ddb to see what's going on, but my USB keyboard begin to work only if I replug it close to the multiuser. Hence I can't. -- wbr, pluknet From phk at phk.freebsd.dk Fri Jan 9 22:34:04 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri Jan 9 22:34:11 2009 Subject: 3G modem and USB, old & new In-Reply-To: Your message of "Fri, 09 Jan 2009 22:45:15 +0100." <200901092245.16450.nick@van-laarhoven.org> Message-ID: <24544.1231540442@critter.freebsd.dk> In message <200901092245.16450.nick@van-laarhoven.org>, Nick Hibma writes: >Would you know of a serial device using tty layer code with high speed >serial links that I could look at to see what could be wrong in either u3g >and/or ucom? I have not had issues with any other ucom device, including for instance the USB-GPIB adapter from prologix.biz which gets to very high speeds with certain T&M instruments. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From marcus at FreeBSD.org Fri Jan 9 22:49:06 2009 From: marcus at FreeBSD.org (Joe Marcus Clarke) Date: Fri Jan 9 22:49:14 2009 Subject: Recent changes to pseudofs causing panics -- leaking a vnode lock? In-Reply-To: <20090109004853.GA34384@ichotolot.servalan.com> References: <20090109004853.GA34384@ichotolot.servalan.com> Message-ID: <1231541342.56664.19.camel@shumai.marcuscom.com> On Thu, 2009-01-08 at 18:48 -0600, Richard Todd wrote: > I've noticed that ever since updating to a kernel after the recent changes > to the pseudofs code late last month, that I've occasionally gotten the > following sort of panic: > > System call readlink returning with the following locks held: > exclusive lockmgr pseudofs (pseudofs) r = 0 (0xffffff00ba581cc8) locked @ /usr/src/sys/fs/pseudofs/pseudofs_vncache.c:193 > panic: witness_warn > > The line in question is the one I marked by an arrow in this chunk of the > pfs_vncache_alloc code: > if ((pn->pn_flags & PFS_PROCDEP) != 0) > (*vpp)->v_vflag |= VV_PROCDEP; > pvd->pvd_vnode = *vpp; > VN_LOCK_AREC(*vpp); > vn_lock(*vpp, LK_EXCLUSIVE | LK_RETRY); <==== this lock here > error = insmntque(*vpp, mp); > > So somehow, a vnode is getting locked here and not getting unlocked. > I suspect the code in the retry2: loop later, simply because that's > the code that got added in the late December commits, but I'm not > clear on how exactly. I've tried littering the code with extra > printfs to try to clarify what's going on, but alas, I'm still not > really sure what's going on. I do have a good coredump that I can get > info out of, if someone can suggest to me what would be useful things > to dump. Anyway, here's the patch for the debugging printfs I added, > and the console messages produced by those printfs from the most > recent coredump/panic. The console msgs do seem to indicate some sort > of race condition going on, though, as they seem to show two or more processes > simultaneously hitting the pseudofs code and hitting my debugging print > statements (alas, making the console log rather a confused mess.) I believe I have fixed this in HEAD. Kib gave his review and approval, and the fix really should prevent this hang. Please report back if you still see the problem. Joe > > The debugging additions: > Index: pseudofs_vncache.c > =================================================================== > RCS file: /usr/FreeBSDCVS/src/sys/fs/pseudofs/pseudofs_vncache.c,v > retrieving revision 1.44 > diff -u -r1.44 pseudofs_vncache.c > --- pseudofs_vncache.c 29 Dec 2008 13:25:58 -0000 1.44 > +++ pseudofs_vncache.c 8 Jan 2009 02:22:50 -0000 > @@ -129,6 +129,7 @@ > mtx_unlock(&pfs_vncache_mutex); > if (vget(vp, LK_EXCLUSIVE | LK_INTERLOCK, curthread) == 0) { > ++pfs_vncache_hits; > + vprint("XXX vncache 6", vp); > *vpp = vp; > /* > * Some callers cache_enter(vp) later, so > @@ -191,7 +192,9 @@ > pvd->pvd_vnode = *vpp; > VN_LOCK_AREC(*vpp); > vn_lock(*vpp, LK_EXCLUSIVE | LK_RETRY); > + printf("XXX vncache 1 *vpp=%p\n", *vpp); > error = insmntque(*vpp, mp); > + printf("XXX vncache 2 *vpp=%p\n", *vpp); > if (error != 0) { > *vpp = NULLVP; > return (error); > @@ -211,11 +214,14 @@ > mtx_unlock(&pfs_vncache_mutex); > if (vget(vp, LK_EXCLUSIVE | LK_INTERLOCK, curthread) == 0) { > ++pfs_vncache_hits; > + vprint("XXX vncache 3", *vpp); > vgone(*vpp); > + vprint("XXX vncache 4", *vpp); > *vpp = vp; > cache_purge(vp); > return (0); > } > + vprint("XXX vncache 5", *vpp); > goto retry2; > } > } > Index: pseudofs_vnops.c > =================================================================== > RCS file: /usr/FreeBSDCVS/src/sys/fs/pseudofs/pseudofs_vnops.c,v > retrieving revision 1.72 > diff -u -r1.72 pseudofs_vnops.c > --- pseudofs_vnops.c 30 Dec 2008 21:49:39 -0000 1.72 > +++ pseudofs_vnops.c 6 Jan 2009 23:12:40 -0000 > @@ -369,6 +369,7 @@ > VOP_UNLOCK(vp, 0); > > error = pfs_vncache_alloc(mp, dvp, pn, pid); > + vprint("XXX vptocnp", *dvp); > if (error) { > vn_lock(vp, locked | LK_RETRY); > vfs_unbusy(mp); > @@ -502,6 +503,7 @@ > } > > error = pfs_vncache_alloc(vn->v_mount, vpp, pn, pid); > + vprint("XXX lookup", *vpp); > if (error) > goto failed; > > and the msgs from the most recent coredump: > Script started on Thu Jan 8 18:34:33 2009 > You have mail. > ichotolot# kgdb kernel.debug /var/crash/vmcore.206 > 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: > XXX vncache 1 *vpp=0xffffff00b0173c30 > XXX vncache 2 *vpp=0xffffff00b0173c30 > XXX vncache 1 *vpp=0xffffff000d420270XXX vncache 1 *vp > p=0xffXfXfX fvfn0cache 2 *vp0c6886750p=0xffffff000d420270 > XXX vncache 2 *vpp=0xffffff00c6886750 > > XXX lookup > 0xffffff00c6886750: tag pseudofs, type VLNK > usecount 1, writecount 0, refcount 1 mountedhere 0 > flags () > lock type pseudofs: EXCL by thread 0xffffff00c873e390 (pid 18861) > #0 0xffffffff80514c28 at __lockmgr_args+0x758 > #1 0xffffffff805a4409 at vop_stdlock+0x39 > #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b > #3 0xffffffff805bfae7 at _vn_lock+0x57 > #4 0xffffffff804ce120 at pfs_vncache_alloc+0x1f0 > #5 0xffffffff804cf473 at pfs_lookup+0x273 > #6 0xffffffff8083543f at VOP_CACHEDLOOKUP_APV+0xaf > #7 0xffffffff805a2220 at vfs_cache_lookup+0xf0 > #8 0xffffffff808378a7 at VOP_LOOKUP_APV+0xb7 > #9 0xffffffff805a83d3 at lookup+0x513 > #10 0xffffffff805a928e at namei+0x53e > #11 0xffffffff805b6ffa at kern_readlinkat+0x7a > #12 0xffffffff805b7121 at kern_readlink+0x21 > #13 0xffffffff807f16b7 at syscall+0x1e7 > #14 0xffffffff807d41bb at Xfast_syscall+0xab > > XXX vncache 3 > 0xffffff000d420270: tag pseudofs, type VDIR > usecount 1, writecount 0, refcount 1 mountedhere 0 > flags (VV_ROOT) > lock type pseudofs: EXCL by thread 0xffffff0082999390 (pid 18860) > #0 0xffffffff80514c28 at __lockmgr_args+0x758 > #1 0xffffffff805a4409 at vop_stdlock+0x39 > #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b > #3 0xffffffff805bfae7 at _vn_lock+0x57 > #4 0xffffffff804ce120 at pfs_vncache_alloc+0x1f0 > #5 0xffffffff805a885f at lookup+0x99f > #6 0xffffffff805a928e at namei+0x53e > #7 0xffffffff805b6ffa at kern_readlinkat+0x7a > #8 0xffffffff805b7121 at kern_readlink+0x21 > #9 0xffffffff807f16b7 at syscall+0x1e7 > #10 0xffffffff807d41bb at Xfast_syscall+0xab > > XXX vncache 4 > 0xffffff000d420270: tag none, type VBAD > usecount 1, writecount 0, refcount 1 mountedhere 0 > flags (VV_ROOT|VI_DOOMED) > lock type pseudofs: EXCL by thread 0xffffff0082999390 (pid 18860) > #0 0xffffffff80514c28 at __lockmgr_args+0x758 > #1 0xffffffff805a4409 at vop_stdlock+0x39 > #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b > #3 0xffffffff805bfae7 at _vn_lock+0x57 > #4 0xffffffff804ce120 at pfs_vncache_alloc+0x1f0 > #5 0xffffffff805a885f at lookup+0x99f > #6 0xffffffff805a928e at namei+0x53e > #7 0xffffffff805b6ffa at kern_readlinkat+0x7a > #8 0xffffffff805b7121 at kern_readlink+0x21 > #9 0xffffffff807f16b7 at syscall+0x1e7 > #10 0xffffffff807d41bb at Xfast_syscall+0xab > > XXX vncache 6 > 0xffffff00c6886750: tag pseudofs, type VLNK > usecount 1, writecount 0, refcount 1 mountedhere 0 > flags () > lock type pseudofs: EXCL by thread 0xffffff0082999390 (pid 18860) > #0 0xffffffff80514c28 at __lockmgr_args+0x758 > #1 0xffffffff805a4409 at vop_stdlock+0x39 > #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b > #3 0xffffffff805bfae7 at _vn_lock+0x57 > #4 0xffffffff805b3fdb at vget+0x8b > #5 0xffffffff804cdfe8 at pfs_vncache_alloc+0xb8 > #6 0xffffffff804cf473 at pfs_lookup+0x273 > #7 0xffffffff8083543f at VOP_CACHEDLOOKUP_APV+0xaf > #8 0xffffffff805a2220 at vfs_cache_lookup+0xf0 > #9 0xffffffff808378a7 at VOP_LOOKUP_APV+0xb7 > #10 0xffffffff805a83d3 at lookup+0x513 > #11 0xffffffff805a928e at namei+0x53e > #12 0xffffffff805b6ffa at kern_readlinkat+0x7a > #13 0xffffffff805b7121 at kern_readlink+0x21 > #14 0xffffffff807f16b7 at syscall+0x1e7 > #15 0xffffffff807d41bb at Xfast_syscall+0xab > > XXX lookup > 0xffffff00c6886750: tag pseudofs, type VLNK > usecount 1, writecount 0, refcount 1 mountedhere 0 > flags () > lock type pseudofs: EXCL by thread 0xffffff0082999390 (pid 18860) > #0 0xffffffff80514c28 at __lockmgr_args+0x758 > #1 0xffffffff805a4409 at vop_stdlock+0x39 > #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b > #3 0xffffffff805bfae7 at _vn_lock+0x57 > #4 0xffffffff805b3fdb at vget+0x8b > #5 0xffffffff804cdfe8 at pfs_vncache_alloc+0xb8 > #6 0xffffffff804cf473 at pfs_lookup+0x273 > #7 0xffffffff8083543f at VOP_CACHEDLOOKUP_APV+0xaf > #8 0xffffffff805a2220 at vfs_cache_lookup+0xf0 > #9 0xffffffff808378a7 at VOP_LOOKUP_APV+0xb7 > #10 0xffffffff805a83d3 at lookup+0x513 > #11 0xffffffff805a928e at namei+0x53e > #12 0xffffffff805b6ffa at kern_readlinkat+0x7a > #13 0xffffffff805b7121 at kern_readlink+0x21 > #14 0xffffffff807f16b7 at syscall+0x1e7 > #15 0xffffffff807d41bb at Xfast_syscall+0xab > > XXX vncache 1 *vpp=0xffffff007af74270 > XXX vncache 2 *vpp=0xffffff007af74270 > XXX lookup > 0xffffff007af74270: tag pseudofs, type VDIR > usecount 1, writecount 0, refcount 1 mountedhere 0 > flags (VV_PROCDEP) > lock type pseudofs: EXCL by thread 0xffffff00c873e390 (pid 18861) > #0 0xffffffff80514c28 at __lockmgr_args+0x758 > #1 0xffffffff805a4409 at vop_stdlock+0x39 > #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b > #3 0xffffffff805bfae7 at _vn_lock+0x57 > #4 0xffffffff804ce120 at pfs_vncache_alloc+0x1f0 > #5 0xffffffff804cf473 at pfs_lookup+0x273 > #6 0xffffffff8083543f at VOP_CACHEDLOOKUP_APV+0xaf > #7 0xffffffff805a2220 at vfs_cache_lookup+0xf0 > #8 0xffffffff808378a7 at VOP_LOOKUP_APV+0xb7 > #9 0xffffffff805a83d3 at lookup+0x513 > #10 0xffffffff805a928e at namei+0x53e > #11 0xffffffff805b6ffa at kern_readlinkat+0x7a > #12 0xffffffff805b7121 at kern_readlink+0x21 > #13 0xffffffff807f16b7 at syscall+0x1e7 > #14 0xffffffff807d41bb at Xfast_syscall+0xab > > XXX vncache 1 *vpp=0xffffff00cd4719c0 > XXX vncache 2 *vpp=0xffffff00cd4719c0 > XXX lookup > 0xffffff00cd4719c0: tag pseudofs, type VLNK > usecount 1, writecount 0, refcount 1 mountedhere 0 > flags (VV_PROCDEP) > lock type pseudofs: EXCL by thread 0xffffff00c873e390 (pid 18861) > #0 0xffffffff80514c28 at __lockmgr_args+0x758 > #1 0xffffffff805a4409 at vop_stdlock+0x39 > #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b > #3 0xffffffff805bfae7 at _vn_lock+0x57 > #4 0xffffffff804ce120 at pfs_vncache_alloc+0x1f0 > #5 0xffffffff804cf473 at pfs_lookup+0x273 > #6 0xffffffff8083543f at VOP_CACHEDLOOKUP_APV+0xaf > #7 0xffffffff805a2220 at vfs_cache_lookup+0xf0 > #8 0xffffffff808378a7 at VOP_LOOKUP_APV+0xb7 > #9 0xffffffff805a83d3 at lookup+0x513 > #10 0xffffffff805a928e at namei+0x53e > #11 0xffffffff805b6ffa at kern_readlinkat+0x7a > #12 0xffffffff805b7121 at kern_readlink+0x21 > #13 0xffffffff807f16b7 at syscall+0x1e7 > #14 0xffffffff807d41bb at Xfast_syscall+0xab > > XXX vncache 6 > 0xffffff00b0173c30: tag pseudofs, type VDIR > usecount 2, writecount 0, refcount 3 mountedhere 0 > flags (VV_ROOT) > lock type pseudofs: EXCL by thread 0xffffff00c625bab0 (pid 18865) > #0 0xffffffff80514c28 at __lockmgr_args+0x758 > #1 0xffffffff805a4409 at vop_stdlock+0x39 > #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b > #3 0xffffffff805bfae7 at _vn_lock+0x57 > #4 0xffffffff805b3fdb at vget+0x8b > #5 0xffffffff804cdfe8 at pfs_vncache_alloc+0xb8 > #6 0xffffffff805a885f at lookup+0x99f > #7 0xffffffff805a928e at namei+0x53e > #8 0xffffffff805b6ffa at kern_readlinkat+0x7a > #9 0xffffffff805b7121 at kern_readlink+0x21 > #10 0xffffffff807f16b7 at syscall+0x1e7 > #11 0xffffffff807d41bb at Xfast_syscall+0xab > > XXX vncache 6 > 0xffffff00c6886750: tag pseudofs, type VLNK > usecount 1, writecount 0, refcount 1 mountedhere 0 > flags () > lock type pseudofs: EXCL by thread 0xffffff00c625bab0 (pid 18865) > #0 0xffffffff80514c28 at __lockmgr_args+0x758 > #1 0xffffffff805a4409 at vop_stdlock+0x39 > #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b > #3 0xffffffff805bfae7 at _vn_lock+0x57 > #4 0xffffffff805b3fdb at vget+0x8b > #5 0xffffffff804cdfe8 at pfs_vncache_alloc+0xb8 > #6 0xffffffff804cf473 at pfs_lookup+0x273 > #7 0xffffffff8083543f at VOP_CACHEDLOOKUP_APV+0xaf > #8 0xffffffff805a2220 at vfs_cache_lookup+0xf0 > #9 0xffffffff808378a7 at VOP_LOOKUP_APV+0xb7 > #10 0xffffffff805a83d3 at lookup+0x513 > #11 0xffffffff805a928e at namei+0x53e > #12 0xffffffff805b6ffa at kern_readlinkat+0x7a > #13 0xffffffff805b7121 at kern_readlink+0x21 > #14 0xffffffff807f16b7 at syscall+0x1e7 > #15 0xffffffff807d41bb at Xfast_syscall+0xab > > XXX lookup > 0xffffff00c6886750: tag pseudofs, type VLNK > usecount 1, writecount 0, refcount 1 mountedhere 0 > flags () > lock type pseudofs: EXCL by thread 0xffffff00c625bab0 (pid 18865) > #0 0xffffffff80514c28 at __lockmgr_args+0x758 > #1 0xffffffff805a4409 at vop_stdlock+0x39 > #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b > #3 0xffffffff805bfae7 at _vn_lock+0x57 > #4 0xffffffff805b3fdb at vget+0x8b > #5 0xffffffff804cdfe8 at pfs_vncache_alloc+0xb8 > #6 0xffffffff804cf473 at pfs_lookup+0x273 > #7 0xffffffff8083543f at VOP_CACHEDLOOKUP_APV+0xaf > #8 0xffffffff805a2220 at vfs_cache_lookup+0xf0 > #9 0xffffffff808378a7 at VOP_LOOKUP_APV+0xb7 > #10 0xffffffff805a83d3 at lookup+0x513 > #11 0xffffffff805a928e at namei+0x53e > #12 0xffffffff805b6ffa at kern_readlinkat+0x7a > #13 0xffffffff805b7121 at kern_readlink+0x21 > #14 0xffffffff807f16b7 at syscall+0x1e7 > #15 0xffffffff807d41bb at Xfast_syscall+0xab > > XXX vncache 1 *vpp=0xffffff0053e7a750 > XXX vncache 2 *vpp=0xffffff0053e7a750 > XXX lookup > 0xffffff0053e7a750: tag pseudofs, type VDIR > usecount 1, writecount 0, refcount 1 mountedhere 0 > flags (VV_PROCDEP) > lock type pseudofs: EXCL by thread 0xffffff0082999390 (pid 18860) > #0 0xffffffff80514c28 at __lockmgr_args+0x758 > #1 0xffffffff805a4409 at vop_stdlock+0x39 > #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b > #3 0xffffffff805bfae7 at _vn_lock+0x57 > #4 0xffffffff804ce120 at pfs_vncache_alloc+0x1f0 > #5 0xffffffff804cf473 at pfs_lookup+0x273 > #6 0xffffffff8083543f at VOP_CACHEDLOOKUP_APV+0xaf > #7 0xffffffff805a2220 at vfs_cache_lookup+0xf0 > #8 0xffffffff808378a7 at VOP_LOOKUP_APV+0xb7 > #9 0xffffffff805a83d3 at lookup+0x513 > #10 0xffffffff805a928e at namei+0x53e > #11 0xffffffff805b6ffa at kern_readlinkat+0x7a > #12 0xffffffff805b7121 at kern_readlink+0x21 > #13 0xffffffff807f16b7 at syscall+0x1e7 > #14 0xffffffff807d41bb at Xfast_syscall+0xab > > XXX vncache 1 *vpp=0xffffff00429cb4e0XXX vncache 1 *vpp=0xffffff007a92a750 > XXX vncache 2 *vpp=0xffffff00429cb4e0 > XXX vncache 2 *vpp=0xffffff007a92a750 > XXX lookup > XXX lookup > 0xffffff00429cb4e0: > 0xffffff007a92a750: tag pseudofs, type VLNKtag pseudofs, type VDIR > usecount 1, writecount 0, refcount 1 mountedhere 0 > usecount 1, writecount 0, refcount 1 mountedhere 0 > flags (VV_PROCDEP) > flags (VV_PROCDEP) > > lock type ps eudofs: EXCL by thrleoacdk type0 pseudofs: EXCL by xftfhfrfefafd0 0829099x3f9f0 f(pid 18860)fff00c625bab0 (pid 18865) > > #0 0xffffffff80514c28 at __lockmgr_args+0x758#0 > 0xffffffff80514c28 at __lockmgr_args+0x758 > #1 0xffffffff805a4409 at vop_stdlock+0x39 > #1 0xffffffff805a4409 at vop_stdlock+0x39 > #2 0xffffffff808369db at VOP_LOCK1_APV+0x9b#2 > 0xffffffff808369db at VOP_LOCK1_APV+0x9b > #3 0xffffffff805bfae7 at _vn_lock+0x57 > #3 0xffffffff805bfae7 at _vn_lock+0x57 > #4 0xffffffff804ce120 at pfs_vncache_alloc+0x1f0 > #4 0xffffffff804ce120 at pfs_vncache_alloc+0x1f0 > #5 0x#f5f ffff0fxff8f0f4fcff473 at pfs_lookffufp8+004xc2f7473 at pfs_lookup+30x273 > > #6 0xffffffff8083543f at VOP_CACHEDLOOKUP_APV+0xaf#6 0xffffffff8083543f at VOP_CACHEDLOOKUP_APV+0xaf > > #7 0xffffffff805a2220 at vfs_cache_lookup+0xf0#7 0xffffffff805a2220 at vf > s_cache_lookup+0xf0 > #8 0xffffffff808378a7 at VOP_LOOKUP_APV+0xb7#8 0xffffffff808378 > a7 at VOP_LOOKUP_APV+0xb7 > #9 0xffffffff805a83d3 at lookup+0x513 > #9 0xffffffff805a83d3 at lookup+0x513 > #10 0xffffff#ff8105a928e at namei+00 x53e0xffffffff805a928e at namei+0x53e > > #11 0xffffffff805b6ffa at kern_readlinkat+0x7a#11 0xffffffff805b6ffa at kern_readlinkat+0x7a > > #12 0xffffffff805b7121 at kern_readlink+0x21#12 0xffffffff805b7121 at ker > n_readlink+0x21 > #13 0xffffffff807f16b7 at syscall+0x1e7 > #13 0xffffffff807f16b7 at syscall+0x1e7 > #14 0xffffffff807d41bb at Xfast_syscall+0xab > > XXX vncache 1 *vpp=0xffffff007a357750#14 0xffffffff807d41bb at Xfast_syscall+0xab > XXX vncache 2 *vpp=0xffffff007a357750 > > XXX looku > p > 0xffffff007a357750: tag pseudofs, type VLNKSystem call readlink returning > usecount 1, writecount 0, refcount 1 mountedhere 0 with the following > flags (VV_PROCDEP) locks held: > exclusive lockmgr pseudofs > lock type pseudofs: EXCL by thread 0xffffff00c625b a(b0 (ppid seu1d8865)ofs) > r = 0 (0xffffff000d420308) locked @ /usr/src/sys/fs/pseudofs/pseudofs_vncache.c:194 > panic: witness_warn > cpuid = 0 > KDB: enter: panic > Physical memory: 4012 MB > Dumping 2401 MB: 2386 2370 2354 2338 2322 2306 2290 2274 2258 2242 2226 2210 2194 2178 2162 2146 2130 2114 2098 2082 2066 2050 2034 2018 2002 1986 1970 1954 1938 1922 1906 1890 1874 1858 1842 1826 1810 1794 1778 1762 1746 1730 1714 1698 1682 1666 1650 1634 1618 1602 1586 1570 1554 1538 1522 1506 1490 1474 1458 1442 1426 1410 1394 1378 1362 1346 1330 1314 1298 1282 1266 1250 1234 1218 1202 1186 1170 1154 1138 1122 1106 1090 1074 1058 1042 1026 1010 994 978 962 946 930 914 898 882 866 850 834 818 802 786 770 754 738 722 706 690 674 658 642 626 610 594 578 562 546 530 514 498 482 466 450 434 418 402 386 370 354 338 322 306 290 274 258 242 226 210 194 178 162 146 130 114 98 82 66 50 34 18 2 > > Reading symbols from /boot/kernel/zfs.ko...done. > Loaded symbols for /boot/kernel/zfs.ko > Reading symbols from /boot/kernel/opensolaris.ko...done. > Loaded symbols for /boot/kernel/opensolaris.ko > Reading symbols from /boot/kernel/geom_mirror.ko...done. > Loaded symbols for /boot/kernel/geom_mirror.ko > Reading symbols from /boot/kernel/snd_hda.ko...done. > Loaded symbols for /boot/kernel/snd_hda.ko > Reading symbols from /boot/kernel/sound.ko...done. > Loaded symbols for /boot/kernel/sound.ko > Reading symbols from /boot/kernel/coretemp.ko...done. > Loaded symbols for /boot/kernel/coretemp.ko > Reading symbols from /boot/kernel/atapicam.ko...done. > Loaded symbols for /boot/kernel/atapicam.ko > Reading symbols from /boot/kernel/tmpfs.ko...done. > Loaded symbols for /boot/kernel/tmpfs.ko > Reading symbols from /boot/kernel/linux.ko...done. > Loaded symbols for /boot/kernel/linux.ko > Reading symbols from /usr/local/modules/fuse.ko...done. > Loaded symbols for /usr/local/modules/fuse.ko > Reading symbols from /boot/modules/cpu.ko...done. > Loaded symbols for /boot/modules/cpu.ko > Reading symbols from /boot/kernel/green_saver.ko...done. > Loaded symbols for /boot/kernel/green_saver.ko > Reading symbols from /boot/kernel/radeon.ko...done. > Loaded symbols for /boot/kernel/radeon.ko > Reading symbols from /boot/kernel/drm.ko...done. > Loaded symbols for /boot/kernel/drm.ko > Reading symbols from /boot/kernel/nullfs.ko...done. > Loaded symbols for /boot/kernel/nullfs.ko > Reading symbols from /boot/kernel/linprocfs.ko...done. > Loaded symbols for /boot/kernel/linprocfs.ko > #0 doadump () at pcpu.h:196 > 196 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); > (kgdb)  p    bt > #0 doadump () at pcpu.h:196 > #1 0xffffffff801c752c in db_fncall (dummy1=Variable "dummy1" is not available. > ) > at /usr/src/sys/ddb/db_command.c:548 > #2 0xffffffff801c7861 in db_command (last_cmdp=0xffffffff80b547a0, cmd_table=Variable "cmd_table" is not available. > ) > at /usr/src/sys/ddb/db_command.c:445 > #3 0xffffffff801c7ab0 in db_command_loop () > at /usr/src/sys/ddb/db_command.c:498 > #4 0xffffffff801c9a59 in db_trap (type=Variable "type" is not available. > ) at /usr/src/sys/ddb/db_main.c:229 > #5 0xffffffff80558fd5 in kdb_trap (type=3, code=0, tf=0xffffffff2d73e840) > at /usr/src/sys/kern/subr_kdb.c:534 > #6 0xffffffff807f1e14 in trap (frame=0xffffffff2d73e840) > at /usr/src/sys/amd64/amd64/trap.c:533 > #7 0xffffffff807d3fae in calltrap () > at /usr/src/sys/amd64/amd64/exception.S:217 > #8 0xffffffff805591ad in kdb_enter (why=0xffffffff808d5179 "panic", > msg=0x1
) at cpufunc.h:63 > #9 0xffffffff80529c5b in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:559 > #10 0xffffffff8056c41e in witness_warn (flags=Variable "flags" is not available. > ) > at /usr/src/sys/kern/subr_witness.c:1655 > #11 0xffffffff807f175e in syscall (frame=0xffffffff2d73ec90) > at /usr/src/sys/amd64/amd64/trap.c:965 > #12 0xffffffff807d41bb in Xfast_syscall () > at /usr/src/sys/amd64/amd64/exception.S:338 > #13 0x0000000018c1ec1c in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) fr 11 > #11 0xffffffff807f175e in syscall (frame=0xffffffff2d73ec90) > at /usr/src/sys/amd64/amd64/trap.c:965 > 965 WITNESS_WARN(WARN_PANIC, NULL, "System call %s returning", > (kgdb) p td > $1 = (struct thread *) 0xffffff0082999390 > (kgdb) p td->td_proc > $2 = (struct proc *) 0xffffff0082ae4880 > (kgdb) p td->td_proc[0] > $3 = {p_list = {le_next = 0xffffff00c82e6440, le_prev = 0xffffff007ac31000}, > p_threads = {tqh_first = 0xffffff0082999390, tqh_last = 0xffffff00829993a0}, > p_slock = {lock_object = {lo_name = 0xffffffff808d3982 "process slock", > lo_flags = 720896, lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}, > p_ucred = 0xffffff0010b4ec00, p_fd = 0xffffff00bdaac400, p_fdtol = 0x0, > p_stats = 0xffffff0082a83c00, p_limit = 0xffffff000ef56c00, p_limco = { > c_links = {sle = {sle_next = 0x0}, tqe = {tqe_next = 0x0, > tqe_prev = 0x0}}, c_time = 0, c_arg = 0x0, c_func = 0, > c_lock = 0xffffff0082ae4978, c_flags = 0, c_cpu = 0}, > p_sigacts = 0xffffff00290e1000, p_flag = 268451840, p_state = PRS_NORMAL, > p_pid = 18860, p_hash = {le_next = 0x0, le_prev = 0xfffffffe4023fd60}, > p_pglist = {le_next = 0x0, le_prev = 0xffffff007ac57948}, > p_pptr = 0xffffff007ac57880, p_sibling = {le_next = 0x0, > le_prev = 0xffffff007ac57970}, p_children = {lh_first = 0x0}, p_mtx = { > lock_object = {lo_name = 0xffffffff808d3975 "process lock", > lo_flags = 21168128, lo_data = 0, lo_witness = 0xfffffffe4021a400}, > mtx_lock = 4}, p_ksi = 0xffffff000515e000, p_sigqueue = {sq_signals = { > __bits = {0, 0, 0, 0}}, sq_kill = {__bits = {0, 0, 0, 0}}, sq_list = { > tqh_first = 0x0, tqh_last = 0xffffff0082ae49c0}, > sq_proc = 0xffffff0082ae4880, sq_flags = 1}, p_oppid = 0, > p_vmspace = 0xffffff0082315d38, p_swtick = 10457673, p_realtimer = { > it_interval = {tv_sec = 0, tv_usec = 0}, it_value = {tv_sec = 0, > tv_usec = 0}}, p_ru = {ru_utime = {tv_sec = 0, tv_usec = 0}, ru_stime = { > tv_sec = 0, tv_usec = 0}, ru_maxrss = 0, ru_ixrss = 0, ru_idrss = 0, > ru_isrss = 0, ru_minflt = 0, ru_majflt = 0, ru_nswap = 0, ru_inblock = 0, > ru_oublock = 0, ru_msgsnd = 0, ru_msgrcv = 0, ru_nsignals = 0, > ru_nvcsw = 0, ru_nivcsw = 0}, p_rux = {rux_runtime = 0, rux_uticks = 0, > rux_sticks = 0, rux_iticks = 0, rux_uu = 0, rux_su = 0, rux_tu = 0}, > p_crux = {rux_runtime = 0, rux_uticks = 0, rux_sticks = 0, rux_iticks = 0, > rux_uu = 0, rux_su = 0, rux_tu = 0}, p_profthreads = 0, p_exitthreads = 0, > p_traceflag = 0, p_tracevp = 0x0, p_tracecred = 0x0, > p_textvp = 0xffffff001b02a750, p_lock = 0 '\0', p_sigiolst = { > slh_first = 0x0}, p_sigparent = 20, p_sig = 0, p_code = 0, p_stops = 0, > p_stype = 0, p_step = 0 '\0', p_pfsflags = 0 '\0', p_nlminfo = 0x0, > p_aioinfo = 0x0, p_singlethread = 0x0, p_suspcount = 0, p_xthread = 0x0, > p_boundary_count = 0, p_pendingcnt = 0, p_itimers = 0x0, > p_magic = 3203398350, p_osrel = 800054, > p_comm = "perl\000l", '\0' , p_pgrp = 0xffffff000b06ec00, > p_sysent = 0xffffffff80b30320, p_args = 0xffffff00bdceda80, > p_cpulimit = 9223372036854775807, p_nice = 0 '\0', p_fibnum = 0, > p_xstat = 0, p_klist = {kl_list = {slh_first = 0x0}, > kl_lock = 0xffffffff805008a0 , > kl_unlock = 0xffffffff805008c0 , > kl_locked = 0xffffffff80501ba0 , > kl_lockarg = 0xffffff0082ae4978}, p_numthreads = 1, > p_md = , p_itcallout = {c_links = {sle = {sle_next = 0x0}, > tqe = {tqe_next = 0x0, tqe_prev = 0x0}}, c_time = 0, c_arg = 0x0, > c_func = 0, c_lock = 0x0, c_flags = 16, c_cpu = 0}, p_acflag = 0, > p_peers = 0x0, p_leader = 0xffffff0082ae4880, p_emuldata = 0x0, > p_label = 0x0, p_sched = 0xffffff0082ae4cc0, p_ktr = {stqh_first = 0x0, > stqh_last = 0xffffff0082ae4c90}, p_mqnotifier = {lh_first = 0x0}, > p_dtrace = 0x0, p_pwait = {cv_description = 0xffffffff808d42c2 "ppwait", > cv_waiters = 0}} > (kgdb)  p *td > $4 = {td_lock = 0xffffffff80b91680, td_proc = 0xffffff0082ae4880, td_plist = { > tqe_next = 0x0, tqe_prev = 0xffffff0082ae4890}, td_runq = { > tqe_next = 0xffffff000549d720, tqe_prev = 0xffffffff80b918c8}, td_slpq = { > tqe_next = 0x0, tqe_prev = 0xffffff000721e190}, td_lockq = { > tqe_next = 0x0, tqe_prev = 0xffffffff2cb3f750}, > td_cpuset = 0xffffff000288cdc8, td_sel = 0xffffff0082f7bb00, > td_sleepqueue = 0xffffff000721e190, td_turnstile = 0xffffff0005469900, > td_umtxq = 0xffffff008284b500, td_tid = 100316, td_sigqueue = {sq_signals = { > __bits = {0, 0, 0, 0}}, sq_kill = {__bits = {0, 0, 0, 0}}, sq_list = { > tqh_first = 0x0, tqh_last = 0xffffff0082999430}, > sq_proc = 0xffffff0082ae4880, sq_flags = 1}, td_flags = 4, > td_inhibitors = 0, td_pflags = 0, td_dupfd = 0, td_sqqueue = 0, > td_wchan = 0x0, td_wmesg = 0x0, td_lastcpu = 0 '\0', td_oncpu = 0 '\0', > td_owepreempt = 0 '\0', td_tsqueue = 0 '\0', td_locks = 1, td_rw_rlocks = 0, > td_lk_slocks = 0, td_blocked = 0x0, td_lockname = 0x0, td_contested = { > lh_first = 0x0}, td_sleeplocks = 0xffffffff80cebd40, > td_intr_nesting_level = 0, td_pinned = 1, td_ucred = 0xffffff0010b4ec00, > td_estcpu = 0, td_slptick = 0, td_ru = {ru_utime = {tv_sec = 0, > tv_usec = 0}, ru_stime = {tv_sec = 0, tv_usec = 0}, ru_maxrss = 2044, > ru_ixrss = 48, ru_idrss = 3352, ru_isrss = 512, ru_minflt = 186, > ru_majflt = 0, ru_nswap = 0, ru_inblock = 0, ru_oublock = 0, > ru_msgsnd = 0, ru_msgrcv = 0, ru_nsignals = 0, ru_nvcsw = 13, > ru_nivcsw = 13}, td_incruntime = 61985988, td_runtime = 61985988, > td_pticks = 3, td_sticks = 4, td_iticks = 0, td_uticks = 0, td_uuticks = 0, > td_usticks = 0, td_intrval = 0, td_oldsigmask = {__bits = {0, 0, 0, 0}}, > td_sigmask = {__bits = {0, 0, 0, 0}}, td_generation = 26, td_sigstk = { > ss_sp = 0x0, ss_size = 0, ss_flags = 4}, td_xsig = 0, td_profil_addr = 0, > td_profil_ticks = 0, td_name = "perl\000l", '\0' , > td_fpop = 0x0, td_dbgflags = 0, td_osd = {osd_nslots = 0, osd_slots = 0x0, > osd_next = {le_next = 0x0, le_prev = 0x0}}, td_rqindex = 32 ' ', > td_base_pri = 128 '\200', td_priority = 128 '\200', td_pri_class = 3 '\003', > td_user_pri = 129 '\201', td_base_user_pri = 129 '\201', > td_pcb = 0xffffffff2d73ed50, td_state = TDS_RUNNING, td_retval = {23, 1023}, > td_slpcallout = {c_links = {sle = {sle_next = 0x0}, tqe = {tqe_next = 0x0, > tqe_prev = 0xffffffff0031d340}}, c_time = 9773098, > c_arg = 0xffffff0082999390, c_func = 0xffffffff80561850 , > c_lock = 0x0, c_flags = 16, c_cpu = 0}, td_frame = 0xffffffff2d73ec90, > td_kstack_obj = 0xffffff00c83a7c80, td_kstack = 18446744070177140736, > td_kstack_pages = 4, td_altkstack_obj = 0x0, td_altkstack = 0, > td_altkstack_pages = 0, td_critnest = 1, td_md = {md_spinlock_count = 0, > md_saved_flags = 70}, td_sched = 0xffffff00829996f0, td_ar = 0x0, > td_syscalls = 1517973, td_lprof = {{lh_first = 0x0}, {lh_first = 0x0}}, > td_dtrace = 0x0, td_errno = 0} > (kgdb) p td  *td->td_lock > $5 = {lock_object = {lo_name = 0xffffffff80b922d8 "sched lock 0", > lo_flags = 720896, lo_data = 0, lo_witness = 0x0}, mtx_lock = 4} > (kgdb) q > ichotolot# > > _______________________________________________ > 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" -- Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090109/efa12611/attachment.pgp From alexanderchuranov at gmail.com Fri Jan 9 22:53:58 2009 From: alexanderchuranov at gmail.com (Alexander Churanov) Date: Fri Jan 9 22:54:10 2009 Subject: gcc 4.3: when will it become standard compiler? In-Reply-To: <20090109222211.GA33145@freebsd.org> References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090108233311.GA69883@keltia.freenix.fr> <20090109031147.GB44317@duncan.reilly.home> <49672189.5060109@gmx.de> <20090109110508.GA12123@freebsd.org> <496751D1.20605@gmx.de> <20090109134725.GA38233@freebsd.org> <49675F04.20006@gmx.de> <3cb459ed0901091412o5861ec59web9b48d264ca053b@mail.gmail.com> <20090109222211.GA33145@freebsd.org> Message-ID: <3cb459ed0901091453i2144419fyede5894ae411a259@mail.gmail.com> Roman, > > clang (clang.llvm.org) supports almost everything now and aims for full > C99 > support. > > pcc aims for full C99 too I believe > > Chris Mallon can comment better but I believe cparser is C99 too > > am I missing something? > This means that I am missing something and that '-pedantic' is all the more important. Sincerely, Alexander Churanov From rdivacky at freebsd.org Fri Jan 9 23:03:10 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Fri Jan 9 23:03:17 2009 Subject: gcc 4.3: when will it become standard compiler? In-Reply-To: <3cb459ed0901091453i2144419fyede5894ae411a259@mail.gmail.com> References: <20090108233311.GA69883@keltia.freenix.fr> <20090109031147.GB44317@duncan.reilly.home> <49672189.5060109@gmx.de> <20090109110508.GA12123@freebsd.org> <496751D1.20605@gmx.de> <20090109134725.GA38233@freebsd.org> <49675F04.20006@gmx.de> <3cb459ed0901091412o5861ec59web9b48d264ca053b@mail.gmail.com> <20090109222211.GA33145@freebsd.org> <3cb459ed0901091453i2144419fyede5894ae411a259@mail.gmail.com> Message-ID: <20090109230252.GA37323@freebsd.org> On Sat, Jan 10, 2009 at 01:53:56AM +0300, Alexander Churanov wrote: > Roman, > > > > > clang (clang.llvm.org) supports almost everything now and aims for full > > C99 > > support. > > > > pcc aims for full C99 too I believe > > > > Chris Mallon can comment better but I believe cparser is C99 too > > > > am I missing something? > > > This means that I am missing something and that '-pedantic' is all the more > important. well.... clang DEFINITELY aims to be drop-in replacement for gcc, ie. it supports (aims to support) all the gcc extensions hence no -pedantic needed to be compatible with gcc and clang at the same time pcc discusses this now (http://pcc.ludd.ltu.se/jira/browse/PCC-18) from what Chris Mallon said I believe it's cparser's goal too to be drop-in replacement for gcc ie. no strong need for -pedantic as far as I can tell :) honestly... we need some of the gnu99 features and it's only a good thing that the alternative compilers support that, I also have a gut feeling that (as it was in the past) some of the gnu99 things might appear in the next C standard From alexanderchuranov at gmail.com Fri Jan 9 23:37:30 2009 From: alexanderchuranov at gmail.com (Alexander Churanov) Date: Fri Jan 9 23:37:37 2009 Subject: gcc 4.3: when will it become standard compiler? In-Reply-To: <20090109230252.GA37323@freebsd.org> References: <20090108233311.GA69883@keltia.freenix.fr> <49672189.5060109@gmx.de> <20090109110508.GA12123@freebsd.org> <496751D1.20605@gmx.de> <20090109134725.GA38233@freebsd.org> <49675F04.20006@gmx.de> <3cb459ed0901091412o5861ec59web9b48d264ca053b@mail.gmail.com> <20090109222211.GA33145@freebsd.org> <3cb459ed0901091453i2144419fyede5894ae411a259@mail.gmail.com> <20090109230252.GA37323@freebsd.org> Message-ID: <3cb459ed0901091537ld9858beq9a8428be9c900fab@mail.gmail.com> 2009/1/10 Roman Divacky > ie. no strong need for -pedantic as far as I can tell :) > > honestly... we need some of the gnu99 features and it's only a good thing > that > the alternative compilers support that, I also have a gut feeling that (as > it > was in the past) some of the gnu99 things might appear in the next C > standard > > Well, since standards aim to document existing practice and not to invent things, your assumption sounds very reasonable. However, adoption of gcc extensions means that behavior of gcc is de-facto standard, more respected than ISO, for a group of developers. Sincerely, Alexander Churanov From rmtodd at ichotolot.servalan.com Sat Jan 10 00:46:10 2009 From: rmtodd at ichotolot.servalan.com (Richard Todd) Date: Sat Jan 10 00:46:18 2009 Subject: Recent changes to pseudofs causing panics -- leaking a vnode lock? In-Reply-To: <1231541342.56664.19.camel@shumai.marcuscom.com> References: <20090109004853.GA34384@ichotolot.servalan.com> <1231541342.56664.19.camel@shumai.marcuscom.com> Message-ID: <20090110000450.GA13656@ichotolot.servalan.com> On Fri, Jan 09, 2009 at 05:49:02PM -0500, Joe Marcus Clarke wrote: > I believe I have fixed this in HEAD. Kib gave his review and approval, > and the fix really should prevent this hang. Please report back if you > still see the problem. Okay, I've gone ahead and booted a new kernel with the new pseudofs code, and will let you know if I see any problems. Richard From yanefbsd at gmail.com Sat Jan 10 01:05:54 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Sat Jan 10 01:06:01 2009 Subject: X becomes unresponsive with nvidia and hardlocks with gdb (was Re: X becomes unresponsive with nvidia / xscreensaver and desktop panics) Message-ID: <7d6fde3d0901091705v6eb4c7bfxe23708f8651e2125@mail.gmail.com> On Fri, Jan 9, 2009 at 2:05 PM, Garrett Cooper wrote: > On Fri, Jan 9, 2009 at 1:40 PM, Doug Barton wrote: >> Garrett Cooper wrote: >>> Thanks for the tips Doug -- I'll give them a shot of course... >> >> Glad I could help. The one thing I forgot to mention is to try the >> nvidia-settings app if you have not already done so. There are various >> things there that you can tweak that might yield better results. >> >> Doug > > I did in fact set everything up via nvidia-settings. I'm running > some stress tests right now to see whether or not I can simulate the > issue -- it doesn't appear to be as straightforward as I thought.. > -Garrett > I believe my actual problem with panicking is related to gdb, not X11. So the actual problem is two-fold: - X11 livelocks, where I can login via ssh and kill . - When I use gdb -p, it prints out the same message reported here: . The only thing is that if I press `y' on the first go-around, the machine hardlocks on the first try with hitting `y'. If I hit `n' so gdb coredumps, I can either go on my merry way, or go back to the confirmation dialog. If I hit it again, it doesn't hardlock. It does hardlock though, and for whatever reason my PC speaker beeps, and I have to warm boot it. I haven't been able to get a kernel dump though, so something else mysteriously is going on that I can't track. So, just to simplify: first_try := True while gdb is running: if prompt_for_coredump() and first_try is True: panic() first_try := False Thanks, -Garrett From yanefbsd at gmail.com Sat Jan 10 01:07:44 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Sat Jan 10 01:07:52 2009 Subject: Recent changes to pseudofs causing panics -- leaking a vnode lock? In-Reply-To: <1231541342.56664.19.camel@shumai.marcuscom.com> References: <20090109004853.GA34384@ichotolot.servalan.com> <1231541342.56664.19.camel@shumai.marcuscom.com> Message-ID: <7d6fde3d0901091707u7e2ee080l75d8567a4093144d@mail.gmail.com> On Fri, Jan 9, 2009 at 2:49 PM, Joe Marcus Clarke wrote: > On Thu, 2009-01-08 at 18:48 -0600, Richard Todd wrote: >> I've noticed that ever since updating to a kernel after the recent changes >> to the pseudofs code late last month, that I've occasionally gotten the >> following sort of panic: >> >> System call readlink returning with the following locks held: >> exclusive lockmgr pseudofs (pseudofs) r = 0 (0xffffff00ba581cc8) locked @ /usr/src/sys/fs/pseudofs/pseudofs_vncache.c:193 >> panic: witness_warn >> >> The line in question is the one I marked by an arrow in this chunk of the >> pfs_vncache_alloc code: >> if ((pn->pn_flags & PFS_PROCDEP) != 0) >> (*vpp)->v_vflag |= VV_PROCDEP; >> pvd->pvd_vnode = *vpp; >> VN_LOCK_AREC(*vpp); >> vn_lock(*vpp, LK_EXCLUSIVE | LK_RETRY); <==== this lock here >> error = insmntque(*vpp, mp); >> >> So somehow, a vnode is getting locked here and not getting unlocked. >> I suspect the code in the retry2: loop later, simply because that's >> the code that got added in the late December commits, but I'm not >> clear on how exactly. I've tried littering the code with extra >> printfs to try to clarify what's going on, but alas, I'm still not >> really sure what's going on. I do have a good coredump that I can get >> info out of, if someone can suggest to me what would be useful things >> to dump. Anyway, here's the patch for the debugging printfs I added, >> and the console messages produced by those printfs from the most >> recent coredump/panic. The console msgs do seem to indicate some sort >> of race condition going on, though, as they seem to show two or more processes >> simultaneously hitting the pseudofs code and hitting my debugging print >> statements (alas, making the console log rather a confused mess.) > > I believe I have fixed this in HEAD. Kib gave his review and approval, > and the fix really should prevent this hang. Please report back if you > still see the problem. > > Joe Joe, When did you do this commit / what's the SVN revision #? Thanks! -Garrett From marcus at FreeBSD.org Sat Jan 10 01:23:06 2009 From: marcus at FreeBSD.org (Joe Marcus Clarke) Date: Sat Jan 10 01:23:13 2009 Subject: Recent changes to pseudofs causing panics -- leaking a vnode lock? In-Reply-To: <7d6fde3d0901091707u7e2ee080l75d8567a4093144d@mail.gmail.com> References: <20090109004853.GA34384@ichotolot.servalan.com> <1231541342.56664.19.camel@shumai.marcuscom.com> <7d6fde3d0901091707u7e2ee080l75d8567a4093144d@mail.gmail.com> Message-ID: <1231550590.56664.21.camel@shumai.marcuscom.com> On Fri, 2009-01-09 at 17:07 -0800, Garrett Cooper wrote: > On Fri, Jan 9, 2009 at 2:49 PM, Joe Marcus Clarke wrote: > > On Thu, 2009-01-08 at 18:48 -0600, Richard Todd wrote: > >> I've noticed that ever since updating to a kernel after the recent changes > >> to the pseudofs code late last month, that I've occasionally gotten the > >> following sort of panic: > >> > >> System call readlink returning with the following locks held: > >> exclusive lockmgr pseudofs (pseudofs) r = 0 (0xffffff00ba581cc8) locked @ /usr/src/sys/fs/pseudofs/pseudofs_vncache.c:193 > >> panic: witness_warn > >> > >> The line in question is the one I marked by an arrow in this chunk of the > >> pfs_vncache_alloc code: > >> if ((pn->pn_flags & PFS_PROCDEP) != 0) > >> (*vpp)->v_vflag |= VV_PROCDEP; > >> pvd->pvd_vnode = *vpp; > >> VN_LOCK_AREC(*vpp); > >> vn_lock(*vpp, LK_EXCLUSIVE | LK_RETRY); <==== this lock here > >> error = insmntque(*vpp, mp); > >> > >> So somehow, a vnode is getting locked here and not getting unlocked. > >> I suspect the code in the retry2: loop later, simply because that's > >> the code that got added in the late December commits, but I'm not > >> clear on how exactly. I've tried littering the code with extra > >> printfs to try to clarify what's going on, but alas, I'm still not > >> really sure what's going on. I do have a good coredump that I can get > >> info out of, if someone can suggest to me what would be useful things > >> to dump. Anyway, here's the patch for the debugging printfs I added, > >> and the console messages produced by those printfs from the most > >> recent coredump/panic. The console msgs do seem to indicate some sort > >> of race condition going on, though, as they seem to show two or more processes > >> simultaneously hitting the pseudofs code and hitting my debugging print > >> statements (alas, making the console log rather a confused mess.) > > > > I believe I have fixed this in HEAD. Kib gave his review and approval, > > and the fix really should prevent this hang. Please report back if you > > still see the problem. > > > > Joe > > Joe, > When did you do this commit / what's the SVN revision #? $FreeBSD: head/sys/fs/pseudofs/pseudofs_vncache.c 186981 2009-01-09 22:06:48Z marcus $ Joe -- Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090110/46b7ec29/attachment.pgp From alexanderchuranov at gmail.com Sat Jan 10 01:25:16 2009 From: alexanderchuranov at gmail.com (Alexander Churanov) Date: Sat Jan 10 01:25:23 2009 Subject: Unicode-based FreeBSD In-Reply-To: <20081113080934.18107pb6oxoa9m74@webmail.leidinger.net> References: <3cb459ed0808221700w335b0906g6901d8b8bec4dad9@mail.gmail.com> <200808241415.31812.mitchell@wyatt672earp.force9.co.uk> <6a7033710808241239p1cbdc7adwd4f87814b428b10b@mail.gmail.com> <3cb459ed0808241958v552eafejf7841f0f9993928e@mail.gmail.com> <3cb459ed0811110616t76235e72n24f2411a324a9807@mail.gmail.com> <3cb459ed0811110629g5c7cef8ascb024a9c1a920efa@mail.gmail.com> <20081112083120.18545lxnzm0odc84@webmail.leidinger.net> <3cb459ed0811120652m363470e0i823c451803516e5f@mail.gmail.com> <20081113080934.18107pb6oxoa9m74@webmail.leidinger.net> Message-ID: <3cb459ed0901091725p57e19768w16fdcc1ec3bde19@mail.gmail.com> Folks, This is a short status update on UTF-8 support for syscons. Mainly, output path works but is not customizable yet. Input path, APIs for user-mode and user-mode applications are not completed. I feel, however, that encoding the keyboard input to UTF-8 is the only real bottleneck for me. ioctls and user-mode applications require some routine and very predictable work. Probably, all of this is doable in 8.0 timeframe. I've updated the wiki with current status and brief description of unicode: http://wiki.freebsd.org/SysconsUnicodeProject Sincerely, Alexander Churanov From pyunyh at gmail.com Sat Jan 10 03:18:48 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Sat Jan 10 03:18:55 2009 Subject: msk Marvell Yukon 88E8038 hangs In-Reply-To: <89dbfdc30901091243w1d01ab59mc2ade81e65e51c5d@mail.gmail.com> References: <89dbfdc30901071438j314ac431h491f9494593caf64@mail.gmail.com> <20090108011220.GA1256@cdnetworks.co.kr> <89dbfdc30901072336l62c46214i113cccf9985bcdae@mail.gmail.com> <20090108075159.GH1256@cdnetworks.co.kr> <89dbfdc30901080835g67b996f4i50e734f0791a0d56@mail.gmail.com> <20090109061032.GF30747@cdnetworks.co.kr> <89dbfdc30901091243w1d01ab59mc2ade81e65e51c5d@mail.gmail.com> Message-ID: <20090110031839.GK30747@cdnetworks.co.kr> On Fri, Jan 09, 2009 at 03:43:38PM -0500, Kim Culhan wrote: > On Fri, Jan 9, 2009 at 1:10 AM, Pyun YongHyeon wrote: > > On Thu, Jan 08, 2009 at 11:35:28AM -0500, Kim Culhan wrote: > > > On Thu, Jan 8, 2009 at 2:51 AM, Pyun YongHyeon wrote: > > > > On Thu, Jan 08, 2009 at 02:36:48AM -0500, Kim Culhan wrote: > > > > > On Wed, Jan 7, 2009 at 8:12 PM, Pyun YongHyeon wrote: > > > > > > On Wed, Jan 07, 2009 at 05:38:28PM -0500, Kim Culhan wrote: > > > > > > > The msk interface on an Acer Aspire 5570Z hangs, frequently when running cvsup. > > > > > > > > > > > > > > Not necessarily at each hang but sometimes coincident, this is > > > > > > > intermittently output to the console: > > > > > > > > > > > > > > in_cksum_skip: out of data by 56952 > > > > > > > > > > > > > > The above is also output to the console at times when receiving a > > > > > > > character through ssh > > > > > > > to a shell. > > > > > > > > > > > > > > The in_cksum_skip messages and msk hangs are also present on this hardware > > > > > > > running 7.1-RELEASE. > > [deleted] > > > Ok, then how about disabling TSO/Tx checksum offload? > > (eg. ifconfig msk0 -tso -txcsum) > > This stops the messages: in_cksum_skip: out of data by 56952 Ok, would you try attached patch? -- Regards, Pyun YongHyeon -------------- next part -------------- A non-text attachment was scrubbed... Name: msk.csum.diff Type: text/x-diff Size: 802 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090110/c9e449dd/msk.csum.bin From hartzell at alerce.com Sat Jan 10 02:23:45 2009 From: hartzell at alerce.com (George Hartzell) Date: Sat Jan 10 04:07:51 2009 Subject: patch to fix burncd bug In-Reply-To: <1de79840901080935s130f647r36815df468a9220b@mail.gmail.com> References: <1de79840901080935s130f647r36815df468a9220b@mail.gmail.com> Message-ID: <18791.65426.128568.526167@almost.alerce.com> Michael Proto writes: > On Thu, Jan 8, 2009 at 12:13 PM, Alexander Best < > alexbestms@math.uni-muenster.de> wrote: > > > could somebody please commit the following patch to dev/ata? it fixes a > > nasty > > bug during fixation in burncd. the bug exists in RELENG6, RELENG7 and HEAD > > (and maybe RELENG5): > > > > http://www.freebsd.org/cgi/query-pr.cgi?prp=95979-3-txt&n=/patch > > > > the whole PR can be found here: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=95979 > > > > > > I second this request. A fix would be nice, this bug has bitten me in both > 7-STABLE and 8-CURRENT :) I have a mac pro running 7.1-PRERELEASE system (not sure when I last updated it) on which burncd seems to successfully burn the data but then fails while fixating. I applied the above patch by hand, with a little bit of fuzz, and now it fails to burn the data but fixating no longer bombs out. Here's a section of a script session (edited to remove the bulk of the written lines...). (delicious)[5:37pm]~>>sudo burncd -e data iso/7.0-RELEASE-amd64-livefs.iso fixate Password: next writeable LBA 0 writing from file iso/7.0-RELEASE-amd64-livefs.iso size 279174 KB written this track 32 KB (0%) total 32 KB written this track 64 KB (0%) total 64 KB [...] written this track 1152 KB (0%) total 1152 KB Input/output error fixating CD, please wait.. (delicious)[5:40pm]~>> I think that I got the patch applied properly, I wonder if something's changed to obsolete it? g. From giffunip at tutopia.com Sat Jan 10 03:22:41 2009 From: giffunip at tutopia.com (Pedro F. Giffuni) Date: Sat Jan 10 04:19:17 2009 Subject: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) Message-ID: <61484.71762.qm@web32708.mail.mud.yahoo.com> FWIW, I had some informal talk with brooks@ about this at EuroBSDCon: - groff(1) needs a C++ compiler so clang is not (yet) an option for the time being we will have to live with GCC or llvm-gcc. Some things we should consider: - Replacing groff with something less restricted that doesn't require C++: Heirloom-doctools may be an option. - More extensive testing of gcc-llvm: A USE_GCC= llvm for the ports tree would be nice. - Remove gcc from the base and make the compilation depend on a packaged C.. somewhat like was made with perl. binutils is yet another issue: I am hoping this will be updated to the latest GPL2 version while a new alternative is developed. Perhaps a combination of RH elfutils and our own libelf efforts would make a viable alternative. just my $0.02, Pedro. From alexbestms at math.uni-muenster.de Sat Jan 10 06:45:35 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Sat Jan 10 06:45:42 2009 Subject: patch to fix burncd bug In-Reply-To: <18791.65426.128568.526167@almost.alerce.com> Message-ID: hmmm...that's odd because the only changes the patch makes deal with fixating the cd. maybe you could try updating your sources to either 7-STABLE or 7.1-RELEASE, apply the patch and recompile your kernel. it might be a good idea to also install a fresh version of burncd. i just downloaded ata-queue.c and atapi-cd.c that shipped with 7.1-RELEASE and the patch applies without any problems. so your revision of both files isn't up to date. please also keep in mind that this patch was made for 8-CURRENT. i don't think it's been tested under 7 so far. cheers. alex George Hartzell schrieb am 2009-01-10: > Michael Proto writes: > > On Thu, Jan 8, 2009 at 12:13 PM, Alexander Best < > > alexbestms@math.uni-muenster.de> wrote: > > > could somebody please commit the following patch to dev/ata? it > > > fixes a > > > nasty > > > bug during fixation in burncd. the bug exists in RELENG6, > > > RELENG7 and HEAD > > > (and maybe RELENG5): > > > http://www.freebsd.org/cgi/query-pr.cgi?prp=95979-3-txt&n=/patch > > > the whole PR can be found here: > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=95979 > > I second this request. A fix would be nice, this bug has bitten me > > in both > > 7-STABLE and 8-CURRENT :) > I have a mac pro running 7.1-PRERELEASE system (not sure when I last > updated it) on which burncd seems to successfully burn the data but > then fails while fixating. > I applied the above patch by hand, with a little bit of fuzz, and now > it fails to burn the data but fixating no longer bombs out. Here's a > section of a script session (edited to remove the bulk of the written > lines...). > (delicious)[5:37pm]~>>sudo burncd -e data > iso/7.0-RELEASE-amd64-livefs.iso fixate > Password: > next writeable LBA 0 > writing from file iso/7.0-RELEASE-amd64-livefs.iso size 279174 KB > written this track 32 KB (0%) total 32 KB > written this track 64 KB (0%) total 64 KB > [...] > written this track 1152 KB (0%) total 1152 KB > Input/output error > fixating CD, please wait.. > (delicious)[5:40pm]~>> > I think that I got the patch applied properly, I wonder if > something's > changed to obsolete it? > g. From spam at rm-rf.kiev.ua Sat Jan 10 06:58:53 2009 From: spam at rm-rf.kiev.ua (Alex Kozlov) Date: Sat Jan 10 06:59:00 2009 Subject: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) Message-ID: <20090110065847.GA28029@ravenloft.kiev.ua> On Fri, Jan 09, 2009 at 07:22:38PM -0800, Pedro F. Giffuni wrote: > - groff(1) needs a C++ compiler so clang is not (yet) an option Also devd. -- Adios From a134qaed at gmail.com Sat Jan 10 08:08:36 2009 From: a134qaed at gmail.com (Dylan Cochran) Date: Sat Jan 10 08:08:43 2009 Subject: Extattr portability? In-Reply-To: References: <4965927D.1060507@freebsd.org> Message-ID: On Fri, Jan 9, 2009 at 10:27 AM, Robert Watson wrote: > On Wed, 7 Jan 2009, Tim Kientzle wrote: > >> I'm trying to complete the extended attribute support in libarchive. >> There are a handful of odd issues that arise which I think I could resolve >> if I knew of good use cases. >> >> Anyone here actually use extended attributes? (Note that ACLs are handled >> separately.) What software? What information do you store there? >> >> If you could benefit from being able to move extended attributes between >> FreeBSD and other systems, I'm especially interested. > > Most (all) of the use of extended attributes that I'm aware of on FreeBSD > relates to security extensions, be it ACLs, MAC labels (almost always in the > system namespace) for various policies, etc. Mac OS X is now using extended > attributes in quite a few more ways, however, so you may want to investigate > a bit on that side. Most uses I'm aware of aren't intended to be portable. Another is BeOS/Haiku, which used attributes heavily. I have been waiting for this work for a while. What I don't really mind is whether it is portable, what I really care about is full retention of the user namespace. No silent truncating of an attribute because of perceived need for a size restriction, assuming the contents are only ASCII, etc. If setextattr can set it on a file, tar should be able to retain it as is, and extract it so getextattr later is identical. If that can be done using an already defined extended attribute format, great! If it can't, I can live with an incompatible tar format. That's my 2 cents on the matter, I use extended attributes now for storing cached mime-type, and sha256/md5 for checksum purposes. I have plans sometime in the future to create a patch for ROX-Filer to check for thumbnail and icon attributes, and use them instead of the current cache scheme. Being able to tar up the directory, and then extract it and keep the thumbnail/icon as expected, would greatly improve user experience, in my opinion. From jh at saunalahti.fi Sat Jan 10 08:40:19 2009 From: jh at saunalahti.fi (Jaakko Heinonen) Date: Sat Jan 10 08:40:26 2009 Subject: patch to fix burncd bug In-Reply-To: <18791.65426.128568.526167@almost.alerce.com> References: <1de79840901080935s130f647r36815df468a9220b@mail.gmail.com> <18791.65426.128568.526167@almost.alerce.com> Message-ID: <20090110084012.GA1979@a91-153-125-115.elisa-laajakaista.fi> Hi, On 2009-01-09, George Hartzell wrote: > I have a mac pro running 7.1-PRERELEASE system (not sure when I last > updated it) on which burncd seems to successfully burn the data but > then fails while fixating. > > I applied the above patch by hand, with a little bit of fuzz, and now > it fails to burn the data but fixating no longer bombs out. It can't see how it could be possible that the patch (correctly applied) causes this. Are you sure that this is repeatable behavior and burning always works with an unpatched kernel? Does dmesg show any error messages after failed burn? -- Jaakko From rdivacky at freebsd.org Sat Jan 10 11:33:22 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Sat Jan 10 11:33:29 2009 Subject: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) In-Reply-To: <61484.71762.qm@web32708.mail.mud.yahoo.com> References: <61484.71762.qm@web32708.mail.mud.yahoo.com> Message-ID: <20090110113308.GA25584@freebsd.org> On Fri, Jan 09, 2009 at 07:22:38PM -0800, Pedro F. Giffuni wrote: > FWIW, > > I had some informal talk with brooks@ about this at EuroBSDCon: > > - groff(1) needs a C++ compiler so clang is not (yet) an option for the time being we will have to live with GCC or llvm-gcc. I guess once the switch happens we are going to live for some with both gcc and clang/llvm. I also guess that by the time the switch happens clang is going to be full C++ capable :) From hselasky at c2i.net Sat Jan 10 11:47:46 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sat Jan 10 11:47:52 2009 Subject: fix tools/tools/usb/print-usb-if-vids.sh In-Reply-To: References: Message-ID: <200901101250.06293.hselasky@c2i.net> On Friday 09 January 2009, Alexander Best wrote: > tools/tools/usb/print-usb-if-vids.sh I will take this into -current. http://perforce.freebsd.org/chv.cgi?CH=155902 Thanks for reporting. --HPS From alexbestms at math.uni-muenster.de Sat Jan 10 13:03:10 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Sat Jan 10 13:03:17 2009 Subject: moving to a newer version of binutils Message-ID: hi everybody, since there's a debate going on concerning moving to a different compiler or switching to a more recent version of gcc i'd like to ask what the binutils situation is right now? is somebody working on porting a more recent version? the current version of gas used in freebsd (2.15) e.g. doesn't support sse3/sse4. cheers. From w8hdkim at gmail.com Sat Jan 10 13:19:52 2009 From: w8hdkim at gmail.com (Kim Culhan) Date: Sat Jan 10 13:19:59 2009 Subject: msk Marvell Yukon 88E8038 hangs In-Reply-To: <20090110031839.GK30747@cdnetworks.co.kr> References: <89dbfdc30901071438j314ac431h491f9494593caf64@mail.gmail.com> <20090108011220.GA1256@cdnetworks.co.kr> <89dbfdc30901072336l62c46214i113cccf9985bcdae@mail.gmail.com> <20090108075159.GH1256@cdnetworks.co.kr> <89dbfdc30901080835g67b996f4i50e734f0791a0d56@mail.gmail.com> <20090109061032.GF30747@cdnetworks.co.kr> <89dbfdc30901091243w1d01ab59mc2ade81e65e51c5d@mail.gmail.com> <20090110031839.GK30747@cdnetworks.co.kr> Message-ID: <89dbfdc30901100519x306d0eadicabe751b6e826c3@mail.gmail.com> On Fri, Jan 9, 2009 at 10:18 PM, Pyun YongHyeon wrote: > On Fri, Jan 09, 2009 at 03:43:38PM -0500, Kim Culhan wrote: > > On Fri, Jan 9, 2009 at 1:10 AM, Pyun YongHyeon wrote: > > > On Thu, Jan 08, 2009 at 11:35:28AM -0500, Kim Culhan wrote: > > > > On Thu, Jan 8, 2009 at 2:51 AM, Pyun YongHyeon wrote: > > > Ok, then how about disabling TSO/Tx checksum offload? > > > (eg. ifconfig msk0 -tso -txcsum) > > > > This stops the messages: in_cksum_skip: out of data by 56952 > > Ok, would you try attached patch? With the patch there are no in_cksum_skip messages a cvsup session still has: Network write failure: Connection timed out There are some instances of LOR, maybe these are already known: lock order reversal: 1st 0xd9544090 bufwait (bufwait) @ kern/vfs_bio.c:2443 2nd 0xc5d72c00 dirhash (dirhash) @ ufs/ufs/ufs_dirhash.c:263 KDB: stack backtrace: db_trace_self_wrapper(c0be4788,e8308778,c0871d75,4,c0bdfd93,...) at db_trace_self_wrapper+0x26 kdb_backtrace(4,c0bdfd93,c55236d8,c5526528,e83087d4,...) at kdb_backtrace+0x29 _witness_debugger(c0be7442,c5d72c00,c0c06baa,c5526528,c0c06850,...) at _witness_debugger+0x25 witness_checkorder(c5d72c00,9,c0c06847,107,0,...) at witness_checkorder+0x839 _sx_xlock(c5d72c00,0,c0c06847,107,c5f7d7f8,...) at _sx_xlock+0x85 ufsdirhash_acquire(d9544030,e83088ec,30,da9360a4,e83088a4,...) at ufsdirhash_acquire+0x35 ufsdirhash_add(c5f7d7f8,e83088ec,30a4,e8308890,e8308894,...) at ufsdirhash_add+0x13 ufs_direnter(c5e13860,c6054648,e83088ec,e8308bd4,0,...) at ufs_direnter+0x729 ufs_makeinode(e8308bd4,e8308acc,e8308acc,e8308a34,c0b41375,...) at ufs_makeinode+0x519 ufs_create(e8308acc,e8308acc,0,e8308acc,e8308ba8,...) at ufs_create+0x30 VOP_CREATE_APV(c0ceb5a0,e8308acc,2,c0bda5a0,3,...) at VOP_CREATE_APV+0xa5 vn_open_cred(e8308ba8,e8308c5c,180,c5b05200,c595e498,...) at vn_open_cred+0x1d0 vn_open(e8308ba8,e8308c5c,180,c595e498,2e0013,...) at vn_open+0x33 kern_openat(c596cd80,ffffff9c,82561e0,0,603,...) at kern_openat+0x110 kern_open(c596cd80,82561e0,0,602,180,...) at kern_open+0x35 open(c596cd80,e8308cf8,c,c0be7c53,c0cc6918,...) at open+0x30 syscall(e8308d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (5, FreeBSD ELF32, open), eip = 0x2823b8d3, esp = 0x8202a60, ebp = 0x8202afc --- -- -kim From yanefbsd at gmail.com Sat Jan 10 15:24:18 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Sat Jan 10 15:24:25 2009 Subject: rc.d/mountd: confusing message (and behavior?) In-Reply-To: <4968BCC4.7090708@icyb.net.ua> References: <4968AE90.5010004@icyb.net.ua> <7d6fde3d0901100711p70e9a66ahadc3c2570fc6f94b@mail.gmail.com> <4968BB5D.8070909@icyb.net.ua> <7d6fde3d0901100716i552420ddja6a59a4938e70fc9@mail.gmail.com> <7d6fde3d0901100718s31ae9f38i5db870b7059bdfbe@mail.gmail.com> <4968BCC4.7090708@icyb.net.ua> Message-ID: <7d6fde3d0901100724la51365cp83ed94d917654605@mail.gmail.com> On Sat, Jan 10, 2009 at 7:20 AM, Andriy Gapon wrote: > on 10/01/2009 17:18 Garrett Cooper said the following: >> >> s/same functionality/same basic functionality/. >> Mind you, NFS is a networking filesystem. ZFS is a filestore >> filesystem, more rooted to the local machine I thought, like UFS. > > I am well aware of this. The difference between UFS and ZFS is that for > the former you have to maintain /etc/exports by hand and for the latter > /etc/zfs/exports is automatically managed via zfs tools. > > Andriy Gapon Maybe a zmountd or equivalent script should be written for zfs and the common code should be factored out for both cases? -Garrett From yanefbsd at gmail.com Sat Jan 10 15:25:25 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Sat Jan 10 15:25:32 2009 Subject: rc.d/mountd: confusing message (and behavior?) In-Reply-To: <7d6fde3d0901100724la51365cp83ed94d917654605@mail.gmail.com> References: <4968AE90.5010004@icyb.net.ua> <7d6fde3d0901100711p70e9a66ahadc3c2570fc6f94b@mail.gmail.com> <4968BB5D.8070909@icyb.net.ua> <7d6fde3d0901100716i552420ddja6a59a4938e70fc9@mail.gmail.com> <7d6fde3d0901100718s31ae9f38i5db870b7059bdfbe@mail.gmail.com> <4968BCC4.7090708@icyb.net.ua> <7d6fde3d0901100724la51365cp83ed94d917654605@mail.gmail.com> Message-ID: <7d6fde3d0901100725q74c46bb1vf93379e075879bfd@mail.gmail.com> On Sat, Jan 10, 2009 at 7:24 AM, Garrett Cooper wrote: > On Sat, Jan 10, 2009 at 7:20 AM, Andriy Gapon wrote: >> on 10/01/2009 17:18 Garrett Cooper said the following: >>> >>> s/same functionality/same basic functionality/. >>> Mind you, NFS is a networking filesystem. ZFS is a filestore >>> filesystem, more rooted to the local machine I thought, like UFS. >> >> I am well aware of this. The difference between UFS and ZFS is that for >> the former you have to maintain /etc/exports by hand and for the latter >> /etc/zfs/exports is automatically managed via zfs tools. >> >> Andriy Gapon > > Maybe a zmountd or equivalent script should be written for zfs and the > common code should be factored out for both cases? > -Garrett Sorry -- wrong list (current -> stable) ><. -Garrett From rdivacky at freebsd.org Sat Jan 10 16:03:11 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Sat Jan 10 16:03:19 2009 Subject: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) In-Reply-To: <54244.38350.qm@web32701.mail.mud.yahoo.com> References: <61484.71762.qm@web32708.mail.mud.yahoo.com> <20090110113308.GA25584@freebsd.org> <54244.38350.qm@web32701.mail.mud.yahoo.com> Message-ID: <20090110160255.GA63803@freebsd.org> On Sat, Jan 10, 2009 at 06:33:53AM -0800, Pedro F. Giffuni wrote: > > > From: Roman Divacky > > > > On Fri, Jan 09, 2009 at 07:22:38PM -0800, Pedro F. Giffuni wrote: > > > FWIW, > > > > > > I had some informal talk with brooks@ about this at EuroBSDCon: > > > > > > - groff(1) needs a C++ compiler so clang is not (yet) an option? for the time > > being we will have to live with GCC or llvm-gcc. > > > > I guess once the switch happens we are going to live for some with both > > gcc and clang/llvm. I also guess that by the time the switch happens > > clang is going to be full C++ capable :) > > I think it's more realistic to move to gcc-llvm first and then to clang: testing gcc-llvm helps?test the llvm capabilities?that clang will require to be a viable replacement. In any case, before doing such a thing an experimental run of the ports tree with?the alternative compiler?would prove very valuable to the developers. I have already asked pav@ about this but I am waiting for clang to implement two features (designated initializers and wchars)... about the llvm-gcc... I dont know... it looks like a dead end to me... From giffunip at tutopia.com Sat Jan 10 14:33:54 2009 From: giffunip at tutopia.com (Pedro F. Giffuni) Date: Sat Jan 10 16:18:43 2009 Subject: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) References: <61484.71762.qm@web32708.mail.mud.yahoo.com> <20090110113308.GA25584@freebsd.org> Message-ID: <54244.38350.qm@web32701.mail.mud.yahoo.com> > From: Roman Divacky > > On Fri, Jan 09, 2009 at 07:22:38PM -0800, Pedro F. Giffuni wrote: > > FWIW, > > > > I had some informal talk with brooks@ about this at EuroBSDCon: > > > > - groff(1) needs a C++ compiler so clang is not (yet) an option? for the time > being we will have to live with GCC or llvm-gcc. > > I guess once the switch happens we are going to live for some with both > gcc and clang/llvm. I also guess that by the time the switch happens > clang is going to be full C++ capable :) I think it's more realistic to move to gcc-llvm first and then to clang: testing gcc-llvm helps?test the llvm capabilities?that clang will require to be a viable replacement. In any case, before doing such a thing an experimental run of the ports tree with?the alternative compiler?would prove very valuable to the developers. Pedro. From giffunip at tutopia.com Sat Jan 10 15:37:56 2009 From: giffunip at tutopia.com (Pedro F. Giffuni) Date: Sat Jan 10 16:19:23 2009 Subject: moving to a newer version of binutils Message-ID: <988010.31127.qm@web32708.mail.mud.yahoo.com> AFAICT ... Anything under GPLv3 will have to live on the ports tree: http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/index.html cheers, Pedro. From naddy at mips.inka.de Sat Jan 10 08:52:26 2009 From: naddy at mips.inka.de (Christian Weisgerber) Date: Sat Jan 10 08:52:37 2009 Subject: bsdtar fan References: <4965927D.1060507@freebsd.org> <4966A9AB.2040802@FreeBSD.org> <367b2c980901090244t64d33c2fx171cda607914189e@mail.gmail.com> Message-ID: Olivier SMEDTS wrote: > Just fed up determining compression type of archives and using z/j > flags with non-bsd tar :) FWIW, gtar has supported this for some time now, too. -- Christian "naddy" Weisgerber naddy@mips.inka.de From christoph.mallon at gmx.de Sat Jan 10 10:32:33 2009 From: christoph.mallon at gmx.de (Christoph Mallon) Date: Sat Jan 10 10:32:53 2009 Subject: gcc 4.3: when will it become standard compiler? In-Reply-To: <20090109222211.GA33145@freebsd.org> References: <49668763.8020705@mail.zedat.fu-berlin.de> <20090108233311.GA69883@keltia.freenix.fr> <20090109031147.GB44317@duncan.reilly.home> <49672189.5060109@gmx.de> <20090109110508.GA12123@freebsd.org> <496751D1.20605@gmx.de> <20090109134725.GA38233@freebsd.org> <49675F04.20006@gmx.de> <3cb459ed0901091412o5861ec59web9b48d264ca053b@mail.gmail.com> <20090109222211.GA33145@freebsd.org> Message-ID: <4968E9BC.2070407@gmx.de> Roman Divacky schrieb: > On Sat, Jan 10, 2009 at 01:12:57AM +0300, Alexander Churanov wrote: >> Folks, >> >> The '-std=c99'' only instructs GCC to allow the whole of C99. This is >> clearly not enough, because this mode allows too many GCC extensions. If you >> compile your code in "default' mode or just specify '-std=c99', then it's >> very likely that you will eventually get stuck to GCC. Using this approach >> you are reducing chances to switch to another C99 compiler. >> >> Though I am not aware of any other open source compiler supporting C99, I >> beleive that there is great need for it. This discussion indicates that >> there is real necessity for BSD-licensed C99 compiler. > > clang (clang.llvm.org) supports almost everything now and aims for full C99 > support. > > pcc aims for full C99 too I believe > > Chris Mallon can comment better but I believe cparser is C99 too cparser already supports most C99 constructs (only complex arithmetic is missing, mostly because nobody needed it so far). The other fancy stuff, like designator initializers and compound literals, works. Wide characters are supported, too. It's not a C99 feature per se, but C99 allows concatenation of char and wide char string literals. Also cparser can generate warnings about incorrect wide character format strings (GCC cannot do that). Oh, btw, I'm Christoph. Chris (Lattner) is the LLVM guy. (; From christoph.mallon at gmx.de Sat Jan 10 10:34:28 2009 From: christoph.mallon at gmx.de (Christoph Mallon) Date: Sat Jan 10 10:34:35 2009 Subject: gcc 4.3: when will it become standard compiler? In-Reply-To: <20090109230252.GA37323@freebsd.org> References: <20090108233311.GA69883@keltia.freenix.fr> <20090109031147.GB44317@duncan.reilly.home> <49672189.5060109@gmx.de> <20090109110508.GA12123@freebsd.org> <496751D1.20605@gmx.de> <20090109134725.GA38233@freebsd.org> <49675F04.20006@gmx.de> <3cb459ed0901091412o5861ec59web9b48d264ca053b@mail.gmail.com> <20090109222211.GA33145@freebsd.org> <3cb459ed0901091453i2144419fyede5894ae411a259@mail.gmail.com> <20090109230252.GA37323@freebsd.org> Message-ID: <4968EA30.4010608@gmx.de> Roman Divacky schrieb: > On Sat, Jan 10, 2009 at 01:53:56AM +0300, Alexander Churanov wrote: >> Roman, >> >>> clang (clang.llvm.org) supports almost everything now and aims for full >>> C99 >>> support. >>> >>> pcc aims for full C99 too I believe >>> >>> Chris Mallon can comment better but I believe cparser is C99 too >>> >>> am I missing something? >>> >> This means that I am missing something and that '-pedantic' is all the more >> important. > > well.... > > clang DEFINITELY aims to be drop-in replacement for gcc, ie. it supports (aims > to support) all the gcc extensions hence no -pedantic needed to be compatible > with gcc and clang at the same time > > pcc discusses this now (http://pcc.ludd.ltu.se/jira/browse/PCC-18) > > from what Chris Mallon said I believe it's cparser's goal too to be drop-in > replacement for gcc cparser supports GCC specific command line switches and language extensions. The most important GCC extensions are its inline assembler syntax, attributes (though only some of them, there are so many...), statement expressions (i.e. ({}), not to be confused with expression statements), thread local variables. We are adding command line switches when needed, because there are hundrends. The most important ones are already supported and the next release will support more. But making a drop-in replacement is not that easy, because sometimes people depend on specific GCC behaviour, which is just happens by coincidence. For example the first larger project (aside from SPEC2000), which we compiled with cparser, was ioquake3. It contains some inline assembler statements. The input/output parameter specification of them was wrong, but GCC accidently produced working code. cparser/libFIRM generated code, which was correct according to the specification, but did not work. So when you change the compiler and even if the compiler does everything right, things still might break, because the input was faulty and you just didn't notice so far. I resolved this specific problem by sending a patch to the ioquake3 maintainer. (: What I want to express is that you have to work very thoroughly when changing the compiler of such a large project especially because it also contains many hardware depedent parts. From kientzle at freebsd.org Sat Jan 10 10:57:06 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Sat Jan 10 10:57:13 2009 Subject: Extattr portability? In-Reply-To: References: <4965927D.1060507@freebsd.org> Message-ID: <4968EF7E.5040002@freebsd.org> Dylan Cochran wrote: > > Another is BeOS/Haiku, which used attributes heavily. I have been > waiting for this work for a while. What I don't really mind is whether > it is portable, what I really care about is full retention of the user > namespace. ... > > That's my 2 cents on the matter, I use extended attributes now for > storing cached mime-type, and sha256/md5 for checksum purposes. Wonderful! Care to help test? There's still a lot of open questions about the system namespace I'll have to figure out. Over on the GNU tar mailing list, the Linux filesystem folks have been agitating for GNU tar to support system extattrs that carry filesystem layout hints. The portability issues with this make my head hurt. Tim From hselasky at c2i.net Sat Jan 10 12:21:17 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sat Jan 10 12:21:29 2009 Subject: USB wiki page Message-ID: <200901102123.36484.hselasky@c2i.net> Hi, I've created a USB page at the FreeBSD wiki with some USB2/HPSUSB frequently asked questions. http://wiki.freebsd.org/USB --HPS From a134qaed at gmail.com Sat Jan 10 14:56:07 2009 From: a134qaed at gmail.com (a134qaed@gmail.com) Date: Sat Jan 10 15:38:31 2009 Subject: Extattr portability? In-Reply-To: <4968EF7E.5040002@freebsd.org> References: <4965927D.1060507@freebsd.org> <4968EF7E.5040002@freebsd.org> Message-ID: On 1/10/09, Tim Kientzle wrote: > Dylan Cochran wrote: >> > > Wonderful! Care to help test? Absolutely. > > There's still a lot of open questions about the system > namespace I'll have to figure out. Over on the GNU tar > mailing list, the Linux filesystem folks have been agitating > for GNU tar to support system extattrs that carry filesystem > layout hints. The portability issues with this make my > head hurt. Yea, I think in the end it's going to be inherently un-portable, as in some systems, the system attributes could be filesystem or kernel specific. And I can forsee some dangerous reprocussions (a collision on an attribute name in the system namespace, which on one system is just a tag, like 'page=23', but on another, it's interpreted as a flagged hint to the dynamic linker, on how to page in the file..... > > Tim > From alexbestms at math.uni-muenster.de Sat Jan 10 17:05:30 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Sat Jan 10 17:05:37 2009 Subject: moving to a newer version of binutils In-Reply-To: <988010.31127.qm@web32708.mail.mud.yahoo.com> Message-ID: just found this perforce by coincidence: http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects/binutils it seems binutils 2.19 is under gpl3, but 2.17 is still under gpl2. alex Pedro F. Giffuni schrieb am 2009-01-10: > AFAICT ... > Anything under GPLv3 will have to live on the ports tree: > http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/index.html > cheers, > Pedro. From randy at psg.com Sat Jan 10 18:31:54 2009 From: randy at psg.com (Randy Bush) Date: Sat Jan 10 18:32:00 2009 Subject: quagga-0.99.11_1 is marked as broken: does not build. Message-ID: <49695A15.8010801@psg.com> 8-current amd64 a few days old "quagga-0.99.11_1 is marked as broken: does not build." yikes! darned tough to build a router (sorry folk, i need is-is). clue bat, hack, pixie dust, please. randy From peterjeremy at optushome.com.au Sat Jan 10 20:44:53 2009 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Sat Jan 10 20:45:00 2009 Subject: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) In-Reply-To: <61484.71762.qm@web32708.mail.mud.yahoo.com> References: <61484.71762.qm@web32708.mail.mud.yahoo.com> Message-ID: <20090111044448.GC5661@server.vk2pj.dyndns.org> On 2009-Jan-09 19:22:38 -0800, "Pedro F. Giffuni" wrote: >- Remove gcc from the base and make the compilation depend on a packaged C.. somewhat like was made with perl. Not quite the same. All the build{world,kernel} tools that used perl were re-written in sh/awk/C so perl is not required to build/install the base system (this was a prerequisite for removing perl). IMO, the FreeBSD base system should come complete with the necessary tools to build/install itself. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090111/646b819c/attachment.pgp From roberthuff at rcn.com Sat Jan 10 21:28:03 2009 From: roberthuff at rcn.com (Robert Huff) Date: Sat Jan 10 21:28:11 2009 Subject: changes after kernel update Message-ID: <18793.33627.620753.956505@jerusalem.litteratus.org> I updated one of my systems tonight, to FreeBSD 7.0-CURRENT #0: Sat Jan 10 23:05:28 EST 2009 i386 After rebooting with the new kernel, things were different. 0) uname says 7.0 ... but it should say 8.0 - right? Where is this set? 1) there was a bunch of stuff that flashed by before the boot menu showed up. 2) I was obliged of change disk specifications from (e.g.) /dev/da0s1a to /dev/da0a However after making those changes in fstab and rc.conf, everything works as before. (So far. ;-) I see noting about this in UPDATING. Where can I find out more information? Respectfully, Robert Huff From pyunyh at gmail.com Sat Jan 10 22:31:33 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Sat Jan 10 22:31:41 2009 Subject: msk Marvell Yukon 88E8038 hangs In-Reply-To: <89dbfdc30901100519x306d0eadicabe751b6e826c3@mail.gmail.com> References: <89dbfdc30901071438j314ac431h491f9494593caf64@mail.gmail.com> <20090108011220.GA1256@cdnetworks.co.kr> <89dbfdc30901072336l62c46214i113cccf9985bcdae@mail.gmail.com> <20090108075159.GH1256@cdnetworks.co.kr> <89dbfdc30901080835g67b996f4i50e734f0791a0d56@mail.gmail.com> <20090109061032.GF30747@cdnetworks.co.kr> <89dbfdc30901091243w1d01ab59mc2ade81e65e51c5d@mail.gmail.com> <20090110031839.GK30747@cdnetworks.co.kr> <89dbfdc30901100519x306d0eadicabe751b6e826c3@mail.gmail.com> Message-ID: <20090111063124.GE42714@cdnetworks.co.kr> On Sat, Jan 10, 2009 at 08:19:50AM -0500, Kim Culhan wrote: > On Fri, Jan 9, 2009 at 10:18 PM, Pyun YongHyeon wrote: > > On Fri, Jan 09, 2009 at 03:43:38PM -0500, Kim Culhan wrote: > > > On Fri, Jan 9, 2009 at 1:10 AM, Pyun YongHyeon wrote: > > > > On Thu, Jan 08, 2009 at 11:35:28AM -0500, Kim Culhan wrote: > > > > > On Thu, Jan 8, 2009 at 2:51 AM, Pyun YongHyeon wrote: > > > > > Ok, then how about disabling TSO/Tx checksum offload? > > > > (eg. ifconfig msk0 -tso -txcsum) > > > > > > This stops the messages: in_cksum_skip: out of data by 56952 > > > > Ok, would you try attached patch? > > With the patch there are no in_cksum_skip messages > Thanks for testing! > a cvsup session still has: > Network write failure: Connection timed out > That's odd, I can't reproduce this on my box. If you disable Tx checksum offload of msk(4), cvsup session completes without problems? When cvsup plains network errors, can you still send/receive packets with msk(4)? > There are some instances of LOR, maybe these are already known: > Probably yes. > lock order reversal: > 1st 0xd9544090 bufwait (bufwait) @ kern/vfs_bio.c:2443 > 2nd 0xc5d72c00 dirhash (dirhash) @ ufs/ufs/ufs_dirhash.c:263 > KDB: stack backtrace: > db_trace_self_wrapper(c0be4788,e8308778,c0871d75,4,c0bdfd93,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(4,c0bdfd93,c55236d8,c5526528,e83087d4,...) at kdb_backtrace+0x29 > _witness_debugger(c0be7442,c5d72c00,c0c06baa,c5526528,c0c06850,...) at > _witness_debugger+0x25 > witness_checkorder(c5d72c00,9,c0c06847,107,0,...) at witness_checkorder+0x839 > _sx_xlock(c5d72c00,0,c0c06847,107,c5f7d7f8,...) at _sx_xlock+0x85 > ufsdirhash_acquire(d9544030,e83088ec,30,da9360a4,e83088a4,...) at > ufsdirhash_acquire+0x35 > ufsdirhash_add(c5f7d7f8,e83088ec,30a4,e8308890,e8308894,...) at > ufsdirhash_add+0x13 > ufs_direnter(c5e13860,c6054648,e83088ec,e8308bd4,0,...) at ufs_direnter+0x729 > ufs_makeinode(e8308bd4,e8308acc,e8308acc,e8308a34,c0b41375,...) at > ufs_makeinode+0x519 > ufs_create(e8308acc,e8308acc,0,e8308acc,e8308ba8,...) at ufs_create+0x30 > VOP_CREATE_APV(c0ceb5a0,e8308acc,2,c0bda5a0,3,...) at VOP_CREATE_APV+0xa5 > vn_open_cred(e8308ba8,e8308c5c,180,c5b05200,c595e498,...) at vn_open_cred+0x1d0 > vn_open(e8308ba8,e8308c5c,180,c595e498,2e0013,...) at vn_open+0x33 > kern_openat(c596cd80,ffffff9c,82561e0,0,603,...) at kern_openat+0x110 > kern_open(c596cd80,82561e0,0,602,180,...) at kern_open+0x35 > open(c596cd80,e8308cf8,c,c0be7c53,c0cc6918,...) at open+0x30 > syscall(e8308d38) at syscall+0x2a3 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (5, FreeBSD ELF32, open), eip = 0x2823b8d3, esp = > 0x8202a60, ebp = 0x8202afc --- > > -- > -kim -- Regards, Pyun YongHyeon From peterjeremy at optushome.com.au Sun Jan 11 00:11:23 2009 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Sun Jan 11 00:11:29 2009 Subject: quagga-0.99.11_1 is marked as broken: does not build. In-Reply-To: <49695A15.8010801@psg.com> References: <49695A15.8010801@psg.com> Message-ID: <20090111081118.GB7054@server.vk2pj.dyndns.org> On 2009-Jan-11 11:31:49 +0900, Randy Bush wrote: >8-current amd64 a few days old >"quagga-0.99.11_1 is marked as broken: does not build." This looks like fallout from the ARP-v2 patches. See the thread "HEADSUP: arp-v2 has been committed" here in late December. I'm not sure how difficult it will be to patch quagga. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090111/72d11102/attachment.pgp From mike at jellydonut.org Sun Jan 11 01:09:18 2009 From: mike at jellydonut.org (Michael Proto) Date: Sun Jan 11 01:09:24 2009 Subject: quagga-0.99.11_1 is marked as broken: does not build. In-Reply-To: <20090111081118.GB7054@server.vk2pj.dyndns.org> References: <49695A15.8010801@psg.com> <20090111081118.GB7054@server.vk2pj.dyndns.org> Message-ID: <1de79840901110043v44d31561vf3a0901e23a31dec@mail.gmail.com> On Sun, Jan 11, 2009 at 3:11 AM, Peter Jeremy wrote: > On 2009-Jan-11 11:31:49 +0900, Randy Bush wrote: > >8-current amd64 a few days old > >"quagga-0.99.11_1 is marked as broken: does not build." > > This looks like fallout from the ARP-v2 patches. See the thread > "HEADSUP: arp-v2 has been committed" here in late December. > I'm not sure how difficult it will be to patch quagga. > > -- > Peter Jeremy > Please excuse any delays as the result of my ISP's inability to implement > an MTA that is either RFC2821-compliant or matches their claimed behaviour. > It looks like isc-dhcp30-server is also affected. Can't find a working dhcpd with CURRENT at the moment. -Proto From rea-fbsd at codelabs.ru Sun Jan 11 01:17:34 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Sun Jan 11 01:18:09 2009 Subject: gcc 4.3: when will it become standard compiler? In-Reply-To: <4967259C.9090408@stillbilde.net> References: <49668763.8020705@mail.zedat.fu-berlin.de> <49671748.3030709@gmx.de> <4967259C.9090408@stillbilde.net> Message-ID: Svein, good day. Fri, Jan 09, 2009 at 11:23:24AM +0100, Svein Skogen (List Mail Account) wrote: > Would it be possible, as a "workaround" to have "system-CC" and > "ports-CC" defined in make.conf, making one CC the compiler for /usr/src > and another for ports, or would this just create debugging nightmares? Will the following additions to your make.conf suit you? ----- .if ${.CURDIR:M/usr/src/*} || ${.CURDIR:M/usr/src} CC = system-CC .endif .if ${.CURDIR:M/usr/ports/*} || ${.CURDIR:M/usr/ports} CC = ports-CC .endif ----- -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From admin at lissyara.su Sun Jan 11 01:44:54 2009 From: admin at lissyara.su (Alex Keda) Date: Sun Jan 11 01:45:01 2009 Subject: Problem with USB mass storage Message-ID: <4969BF94.9090002@lissyara.su> I have problem USB box for hdd. Device not work =( No partitions =( (really - exists s1a) lissyara$ ll /dev/da4* crw-r----- 1 root operator 0, 115 11 ??? 12:39 /dev/da4 lissyara$ lissyara$ uname -a FreeBSD lissyara.moskb.local 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sun Jan 11 12:17:46 MSK 2009 lissyara@lissyara.moskb.local:/usr/obj/mnt/jabber/DISTR/FreeBSD/src/CURRENT/sys/USB2 amd64 lissyara$ Jan 11 12:39:38 lissyara kernel: usb2_set_config_index:582: could not read device status: USB_ERR_SHORT_XFER Jan 11 12:39:38 lissyara kernel: ugen5.2: at usbus5 Jan 11 12:39:38 lissyara kernel: umass0: on usbus5 Jan 11 12:39:38 lissyara kernel: umass0: SCSI over Bulk-Only; quirks = 0x0000 Jan 11 12:39:39 lissyara kernel: umass0:5:0:-1: Attached to scbus5 Jan 11 12:39:40 lissyara kernel: (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 Jan 11 12:39:40 lissyara kernel: (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error Jan 11 12:39:40 lissyara kernel: (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition Jan 11 12:39:40 lissyara kernel: (probe0:umass-sim0:0:0:0): NOT READY asc:3a,0 Jan 11 12:39:40 lissyara kernel: (probe0:umass-sim0:0:0:0): Medium not present Jan 11 12:39:40 lissyara kernel: (probe0:umass-sim0:0:0:0): Unretryable error Jan 11 12:39:40 lissyara kernel: da4 at umass-sim0 bus 0 target 0 lun 0 Jan 11 12:39:40 lissyara kernel: da4: < > Fixed Direct Access SCSI-2 device Jan 11 12:39:40 lissyara kernel: da4: 40.000MB/s transfers Jan 11 12:39:40 lissyara kernel: da4: Attempt to query device size failed: NOT READY, Medium not present Jan 11 12:39:40 lissyara kernel: (da4:umass-sim0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 Jan 11 12:39:40 lissyara kernel: (da4:umass-sim0:0:0:0): CAM Status: SCSI Status Error Jan 11 12:39:40 lissyara kernel: (da4:umass-sim0:0:0:0): SCSI Status: Check Condition Jan 11 12:39:40 lissyara kernel: (da4:umass-sim0:0:0:0): NOT READY asc:3a,0 Jan 11 12:39:40 lissyara kernel: (da4:umass-sim0:0:0:0): Medium not present Jan 11 12:39:40 lissyara kernel: (da4:umass-sim0:0:0:0): Unretryable error Jan 11 12:39:40 lissyara kernel: (da4:umass-sim0:0:0:0): READ CAPACITY(10). CDB: 25 0 0 0 0 0 0 0 0 0 Jan 11 12:39:40 lissyara kernel: (da4:umass-sim0:0:0:0): CAM Status: SCSI Status Error Jan 11 12:39:40 lissyara kernel: (da4:umass-sim0:0:0:0): SCSI Status: Check Condition Jan 11 12:39:40 lissyara kernel: (da4:umass-sim0:0:0:0): NOT READY asc:3a,0 Jan 11 12:39:40 lissyara kernel: (da4:umass-sim0:0:0:0): Medium not present Jan 11 12:39:40 lissyara kernel: (da4:umass-sim0:0:0:0): Unretryable error From hselasky at c2i.net Sun Jan 11 02:36:25 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sun Jan 11 02:36:32 2009 Subject: Problem with USB mass storage In-Reply-To: <4969BF94.9090002@lissyara.su> References: <4969BF94.9090002@lissyara.su> Message-ID: <200901111138.45620.hselasky@c2i.net> On Sunday 11 January 2009, Alex Keda wrote: > I have problem USB box for hdd. > Device not work =( > No partitions =( (really - exists s1a) > > lissyara$ ll /dev/da4* > crw-r----- 1 root operator 0, 115 11 ??? 12:39 /dev/da4 > lissyara$ > Have you tried: cat /dev/null > /dev/da4 ? --HPS From ken at mthelicon.com Sun Jan 11 02:41:57 2009 From: ken at mthelicon.com (Pegasus Mc Cleaft) Date: Sun Jan 11 02:42:04 2009 Subject: USB2 & umass problem Message-ID: <200901111041.53255.ken@mthelicon.com> Hi Current... I think there may be a problem with the USB2 stack and the umass driver on AMD64. I have tried this with both a USB SATA/IDE controller and a USB flash stick. Both of them give similar results below. Please note that the disconnect message is when I pulled the device out of the USB port on the computer. feathers$ uname -a FreeBSD feathers.peganest.com 8.0-CURRENT FreeBSD 8.0-CURRENT #43: Sun Jan 11 02:40:44 UTC 2009 ken@feathers.peganest.com:/usr/obj/usr/src/sys/FEATHERS amd64 (USB IDE/SATA controller) usb2_set_config_index:582: could not read device status: USB_ERR_SHORT_XFER ugen7.2: at usbus7 umass0: on usbus7 umass0: SCSI over Bulk-Only; quirks = 0x0000 umass0:15:0:-1: Attached to scbus15 usb2_pc_common_mem_cb:429: Page offset was not preserved! usb2_pc_common_mem_cb:429: Page offset was not preserved! usb2_pc_common_mem_cb:429: Page offset was not preserved! usb2_pc_common_mem_cb:429: Page offset was not preserved! usb2_pc_common_mem_cb:429: Page offset was not preserved! umass0: at ushub7, port 1, addr 2 (disconnected) ugen7.2: at usbus7 (disconnected) (USB Flash Stick) ugen7.2: at usbus7 umass0: on usbus7 umass0: SCSI over Bulk-Only; quirks = 0x0000 umass0:15:0:-1: Attached to scbus15 usb2_pc_common_mem_cb:429: Page offset was not preserved! usb2_pc_common_mem_cb:429: Page offset was not preserved! usb2_pc_common_mem_cb:429: Page offset was not preserved! usb2_pc_common_mem_cb:429: Page offset was not preserved! usb2_pc_common_mem_cb:429: Page offset was not preserved! umass0: at ushub7, port 1, addr 2 (disconnected) ugen7.2: at usbus7 (disconnected) Peg From admin at lissyara.su Sun Jan 11 02:54:30 2009 From: admin at lissyara.su (Alex Keda) Date: Sun Jan 11 02:54:37 2009 Subject: Problem with USB mass storage In-Reply-To: <200901111138.45620.hselasky@c2i.net> References: <4969BF94.9090002@lissyara.su> <200901111138.45620.hselasky@c2i.net> Message-ID: <4969CFE4.5090100@lissyara.su> Hans Petter Selasky ?????: > On Sunday 11 January 2009, Alex Keda wrote: > >> I have problem USB box for hdd. >> Device not work =( >> No partitions =( (really - exists s1a) >> >> lissyara$ ll /dev/da4* >> crw-r----- 1 root operator 0, 115 11 ??? 12:39 /dev/da4 >> lissyara$ >> > Have you tried: > > cat /dev/null > /dev/da4 > A disc containing the necessary data to me =) From hselasky at c2i.net Sun Jan 11 03:23:22 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sun Jan 11 03:23:34 2009 Subject: USB2 & umass problem In-Reply-To: <200901111041.53255.ken@mthelicon.com> References: <200901111041.53255.ken@mthelicon.com> Message-ID: <200901111225.42892.hselasky@c2i.net> On Sunday 11 January 2009, Pegasus Mc Cleaft wrote: > Page offset was not preserved! This error is a well known issue. I hope to get it fixed this week. You find the solution here: http://perforce.freebsd.org/chv.cgi?CH=154181 --HPS From hselasky at c2i.net Sun Jan 11 03:23:22 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sun Jan 11 03:23:35 2009 Subject: USB2 & umass problem In-Reply-To: <200901111041.53255.ken@mthelicon.com> References: <200901111041.53255.ken@mthelicon.com> Message-ID: <200901111225.42892.hselasky@c2i.net> On Sunday 11 January 2009, Pegasus Mc Cleaft wrote: > Page offset was not preserved! This error is a well known issue. I hope to get it fixed this week. You find the solution here: http://perforce.freebsd.org/chv.cgi?CH=154181 --HPS From rea-fbsd at codelabs.ru Sun Jan 11 03:51:43 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Sun Jan 11 03:51:51 2009 Subject: quagga-0.99.11_1 is marked as broken: does not build. In-Reply-To: <49695A15.8010801@psg.com> References: <49695A15.8010801@psg.com> Message-ID: Randy, good day. Sun, Jan 11, 2009 at 11:31:49AM +0900, Randy Bush wrote: > 8-current amd64 a few days old > "quagga-0.99.11_1 is marked as broken: does not build." > > yikes! darned tough to build a router (sorry folk, i need is-is). > > clue bat, hack, pixie dust, please. Please, try patches from the http://lists.freebsd.org/pipermail/freebsd-current/2008-December/001443.html and http://lists.freebsd.org/pipermail/freebsd-current/2008-December/001474.html And please, report any results back ;)) -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From admin at lissyara.su Sun Jan 11 04:02:36 2009 From: admin at lissyara.su (Alex Keda) Date: Sun Jan 11 04:02:44 2009 Subject: Problem with USB mass storage In-Reply-To: <4969CFE4.5090100@lissyara.su> References: <4969BF94.9090002@lissyara.su> <200901111138.45620.hselasky@c2i.net> <4969CFE4.5090100@lissyara.su> Message-ID: <4969DFC7.4000300@lissyara.su> Alex Keda ?????: > Hans Petter Selasky ?????: >> On Sunday 11 January 2009, Alex Keda wrote: >> >>> I have problem USB box for hdd. >>> Device not work =( >>> No partitions =( (really - exists s1a) >>> >>> lissyara$ ll /dev/da4* >>> crw-r----- 1 root operator 0, 115 11 ??? 12:39 /dev/da4 >>> lissyara$ >>> >> Have you tried: >> >> cat /dev/null > /dev/da4 >> > A disc containing the necessary data to me =) Very sorry, I use another cable and all OK =) Jan 11 15:01:21 lissyara kernel: usb2_set_config_index:582: could not read device status: USB_ERR_SHORT_XFER Jan 11 15:01:21 lissyara kernel: ugen5.2: at usbus5 Jan 11 15:01:21 lissyara kernel: umass0: on usbus5 Jan 11 15:01:21 lissyara kernel: umass0: SCSI over Bulk-Only; quirks = 0x0000 Jan 11 15:01:22 lissyara kernel: umass0:5:0:-1: Attached to scbus5 Jan 11 15:01:23 lissyara kernel: da4 at umass-sim0 bus 0 target 0 lun 0 Jan 11 15:01:23 lissyara kernel: da4: Fixed Direct Access SCSI-2 device Jan 11 15:01:23 lissyara kernel: da4: 40.000MB/s transfers Jan 11 15:01:23 lissyara kernel: da4: 76319MB (156301488 512 byte sectors: 255H 63S/T 9729C) From ohartman at mail.zedat.fu-berlin.de Sun Jan 11 02:39:46 2009 From: ohartman at mail.zedat.fu-berlin.de (O. Hartmann) Date: Sun Jan 11 04:17:32 2009 Subject: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) In-Reply-To: <20090111044448.GC5661@server.vk2pj.dyndns.org> References: <61484.71762.qm@web32708.mail.mud.yahoo.com> <20090111044448.GC5661@server.vk2pj.dyndns.org> Message-ID: <4969CC6D.6030707@mail.zedat.fu-berlin.de> Peter Jeremy wrote: > On 2009-Jan-09 19:22:38 -0800, "Pedro F. Giffuni" wrote: > >> - Remove gcc from the base and make the compilation depend on a packaged C.. somewhat like was made with perl. >> > > ... schnipp ... > IMO, the > FreeBSD base system should come complete with the necessary tools to > build/install itself. > > I agree. And it woukd be preferable having a fast and efficient C and/or C++ compiler. Well, initially my question was triggered by reading a performance duell between FreeBSD 7/8, most recent U(n)buntu and OpenSolaris and someone stated the 3% performance gain of U(n)buntu over FreeBSD was due to the gcc4.3 compiler, which generates more efficient code. 3% mean performance gain could mean (as I made this experience) a better advantage in some special cases and having in mind numerical modelling running on my lab's FreeBSd box (yet, but I think this is about to change and move towards a RH Linux system due to the better support of HPC and, a pitty, our admins build the cluster with RH and not FBSD). I'm not an expert in politics and OS development, but as far as I know, SUN tried to extract the compiler out of the base system and failed by doing this. In my opinion, being independend on the base system and additionally having a very fast C compiler could also losen the tight bindings to licensing restrictions. I never took care about GPLv2 and v3 differences but know, this seems to come to relevance in some way. Well, as I understand the discussion about the binutils (there seems to exist a very similar problemacy), did RH already cut off the leashes by introducing their elftools? Correct me, if I'm wrong. Oliver From talon at lpthe.jussieu.fr Sun Jan 11 03:11:36 2009 From: talon at lpthe.jussieu.fr (Michel Talon) Date: Sun Jan 11 04:29:51 2009 Subject: Problem with USB mass storage Message-ID: <20090111110127.GA53156@lpthe.jussieu.fr> Alex Keda wrote: > Hans Petter Selasky ??????????: > > On Sunday 11 January 2009, Alex Keda wrote: > > > >> I have problem USB box for hdd. > >> Device not work =( > >> No partitions =( (really - exists s1a) > >> > >> lissyara$ ll /dev/da4* > >> crw-r----- 1 root operator 0, 115 11 ?????? 12:39 /dev/da4 > >> lissyara$ > >> > > Have you tried: > > > > cat /dev/null > /dev/da4 > > > A disc containing the necessary data to me =) /dev/null is not /dev/zero ! -- Michel TALON From bsam at ipt.ru Sun Jan 11 04:54:39 2009 From: bsam at ipt.ru (Boris Samorodov) Date: Sun Jan 11 04:54:48 2009 Subject: Problem with USB mass storage In-Reply-To: <4969CFE4.5090100@lissyara.su> (Alex Keda's message of "Sun, 11 Jan 2009 13:54:28 +0300") References: <4969BF94.9090002@lissyara.su> <200901111138.45620.hselasky@c2i.net> <4969CFE4.5090100@lissyara.su> Message-ID: <13824919@serv3.int.kfs.ru> On Sun, 11 Jan 2009 13:54:28 +0300 Alex Keda wrote: > Hans Petter Selasky ?????: > > On Sunday 11 January 2009, Alex Keda wrote: > > > >> I have problem USB box for hdd. > >> Device not work =( > >> No partitions =( (really - exists s1a) > >> > >> lissyara$ ll /dev/da4* > >> crw-r----- 1 root operator 0, 115 11 ??? 12:39 /dev/da4 > >> lissyara$ > >> > > Have you tried: > > > > cat /dev/null > /dev/da4 > > > A disc containing the necessary data to me =) Actually nothing will be written to the disk. But only some ata run-time data will be initialized. WBR -- bsam From roberthuff at rcn.com Sun Jan 11 06:57:46 2009 From: roberthuff at rcn.com (Robert Huff) Date: Sun Jan 11 06:57:53 2009 Subject: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) In-Reply-To: <20090111044448.GC5661@server.vk2pj.dyndns.org> References: <20090111044448.GC5661@server.vk2pj.dyndns.org> Message-ID: <18794.1466.255118.38177@jerusalem.litteratus.org> Peter Jeremy writes: > >- Remove gcc from the base and make the compilation depend on a > > packaged C.. somewhat like was made with perl. > > IMO, the FreeBSD base system should come complete with the > necessary tools to build/install itself. While I get an opinion but not a vote ... "(re)build itself" is not negotiable. Robert Huff From giffunip at tutopia.com Sun Jan 11 07:07:28 2009 From: giffunip at tutopia.com (Pedro F. Giffuni) Date: Sun Jan 11 08:03:20 2009 Subject: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) References: <61484.71762.qm@web32708.mail.mud.yahoo.com> <20090111044448.GC5661@server.vk2pj.dyndns.org> Message-ID: <342292.89033.qm@web32703.mail.mud.yahoo.com> ----- Original Message ---- > On 2009-Jan-09 19:22:38 -0800, "Pedro F. Giffuni" wrote: > >- Remove gcc from the base and make the compilation depend on a packaged C.. > somewhat like was made with perl. > > Not quite the same.? All the build{world,kernel} tools that used perl > were re-written in sh/awk/C so perl is not required to build/install > the base system (this was a prerequisite for removing perl).? IMO, the > FreeBSD base system should come complete with the necessary tools to > build/install itself. > OK, I quite agree it's not the same as perl: C is not something we cannot depend on. There was, however, the idea that the installation could be more packaged oriented. The C compiler gets in the way of installing a?lighter client. Many users don't need a C compiler as they can use pre-packaged stuff?and there's also the issue that we don't really do all that much in-tree development of the development tools. Pedro. From spikey.it at gmail.com Sun Jan 11 08:04:36 2009 From: spikey.it at gmail.com (Andrea Di Pasquale) Date: Sun Jan 11 08:04:43 2009 Subject: Options handler for userspace programs Message-ID: <354C4317-4471-47A6-9B52-EF53D753D1B8@gmail.com> Hi Tim! I written new options parser for argv, string and environment variable. optsscan_argv() /* handle argv */ optsscan_strenv() /* handle string or env var */ They include getopt(), getopt_long() and getopt_long_only() functionalities in two types of functions. So, you can handle only short options, short and long options and only long options, all in two types of functions. Obviously, you can to handle an argument, with this syntax: Short options: -o -o arg -o= arg -o=arg Long options: --option --option argument --option= argument --option=argument Link to tarball: http://jo666.altervista.org/optsscan.tar.gz Here, you can find optsscan code and a main example. Thank you, regards, Andrea From giffunip at tutopia.com Sun Jan 11 07:29:48 2009 From: giffunip at tutopia.com (Pedro F. Giffuni) Date: Sun Jan 11 08:14:45 2009 Subject: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) References: <61484.71762.qm@web32708.mail.mud.yahoo.com> <20090111044448.GC5661@server.vk2pj.dyndns.org> <4969CC6D.6030707@mail.zedat.fu-berlin.de> Message-ID: <458984.49823.qm@web32708.mail.mud.yahoo.com> ----- Original Message ---- ... > > Well, initially my question was triggered by reading a performance duell > between FreeBSD 7/8, most recent U(n)buntu and OpenSolaris and someone > stated the 3% performance gain of U(n)buntu over FreeBSD was due to the > gcc4.3 compiler, which generates more efficient code. 3% mean > performance gain could mean (as I made this experience) a better > advantage in some special cases and having in mind numerical modelling > running on my lab's FreeBSd box (yet, but I think this is about to > change and move towards a RH Linux system due to the better support of > HPC and, a pitty, our admins build the cluster with RH and not FBSD). > Even when it can be measured, performance can be very subjective, performance depends on many factors: the threading libraries, the options used to build the packages, the filesystems and maybe even the position of the moon ;-). Most of my numerical packages don't depend on the system compiler but rather depend on what the?ports system?uses?as the?Fortran compiler so you will be glad to know that we are indeed using gcc4.3 since last week. > > Well, as I understand the discussion about the binutils (there seems to > exist a very similar problemacy), did RH already cut off the leashes by > introducing their elftools? Correct me, if I'm wrong. > We already have our own libelf and related utilities however the tough part seems to be having a good assembler that supports all our platforms. I understand the RH elftools have that but I don't know their current state.?Also the?maintainers of these utilities are known to be rather unfriendly with other camps. Pedro. From sem at FreeBSD.org Sun Jan 11 09:43:53 2009 From: sem at FreeBSD.org (Sergey Matveychuk) Date: Sun Jan 11 09:44:00 2009 Subject: quagga-0.99.11_1 is marked as broken: does not build. In-Reply-To: References: <49695A15.8010801@psg.com> Message-ID: <496A254F.2020500@FreeBSD.org> Eygene Ryabinkin wrote: > Randy, good day. > > Sun, Jan 11, 2009 at 11:31:49AM +0900, Randy Bush wrote: >> 8-current amd64 a few days old >> "quagga-0.99.11_1 is marked as broken: does not build." >> >> yikes! darned tough to build a router (sorry folk, i need is-is). >> >> clue bat, hack, pixie dust, please. > > Please, try patches from the > http://lists.freebsd.org/pipermail/freebsd-current/2008-December/001443.html > and > http://lists.freebsd.org/pipermail/freebsd-current/2008-December/001474.html > > And please, report any results back ;)) The fix is already in the port: http://www.freebsd.org/cgi/cvsweb.cgi/ports/net/quagga/files/patch-zebra-kernel_socket.c?rev=1.5 I have no idea why Erwin has marked it as BROKEN again. -- Dixi. Sem. From stephen at math.missouri.edu Sun Jan 11 10:06:09 2009 From: stephen at math.missouri.edu (Stephen Montgomery-Smith) Date: Sun Jan 11 10:06:19 2009 Subject: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) In-Reply-To: <458984.49823.qm@web32708.mail.mud.yahoo.com> References: <61484.71762.qm@web32708.mail.mud.yahoo.com> <20090111044448.GC5661@server.vk2pj.dyndns.org> <4969CC6D.6030707@mail.zedat.fu-berlin.de> <458984.49823.qm@web32708.mail.mud.yahoo.com> Message-ID: <496A31C7.2020107@math.missouri.edu> Pedro F. Giffuni wrote: > > ----- Original Message ---- > ... >> Well, initially my question was triggered by reading a performance duell >> between FreeBSD 7/8, most recent U(n)buntu and OpenSolaris and someone >> stated the 3% performance gain of U(n)buntu over FreeBSD was due to the >> gcc4.3 compiler, which generates more efficient code. 3% mean >> performance gain could mean (as I made this experience) a better >> advantage in some special cases and having in mind numerical modelling >> running on my lab's FreeBSd box (yet, but I think this is about to >> change and move towards a RH Linux system due to the better support of >> HPC and, a pitty, our admins build the cluster with RH and not FBSD). >> > > Even when it can be measured, performance can be very subjective, performance > depends on many factors: the threading libraries, the options used to build the > packages, the filesystems and maybe even the position of the moon ;-). Most of > my numerical packages don't depend on the system compiler but rather depend on > what the ports system uses as the Fortran compiler so you will be glad to know > that we are indeed using gcc4.3 since last week. I also do quite a bit of numerical work. For me a 3% performance gain is not that much, and really becomes negligible compared to other issues. I have written some software that, a year ago, ran twice as fast under Fedora Linux than it did under FreeBSD. Now FreeBSD has completely caught up! And I didn't change the software itself in any substantial manner. My guess is that FreeBSD has improved its cache management/threading management considerably (because my programs (a) use large amounts of data and (b) are threaded). So, for me, a big difference is 2 to 1. A factor of 3% is definitely something dependent on the "position of the moon" as Pedro put it so eloquently. Stephen From rwatson at FreeBSD.org Sun Jan 11 10:52:17 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Jan 11 10:52:25 2009 Subject: Extattr portability? In-Reply-To: <4968EF7E.5040002@freebsd.org> References: <4965927D.1060507@freebsd.org> <4968EF7E.5040002@freebsd.org> Message-ID: On Sat, 10 Jan 2009, Tim Kientzle wrote: > Dylan Cochran wrote: >> >> Another is BeOS/Haiku, which used attributes heavily. I have been waiting >> for this work for a while. What I don't really mind is whether it is >> portable, what I really care about is full retention of the user namespace. >> ... >> >> That's my 2 cents on the matter, I use extended attributes now for storing >> cached mime-type, and sha256/md5 for checksum purposes. > > Wonderful! Care to help test? > > There's still a lot of open questions about the system namespace I'll have > to figure out. Over on the GNU tar mailing list, the Linux filesystem folks > have been agitating for GNU tar to support system extattrs that carry > filesystem layout hints. The portability issues with this make my head > hurt. One of the things I've been considering for FreeBSD is pulling in the xattr API used on Mac OS X and Linux -- our API was modeled on the POSIX.1e ACL API in a manner similar to IRIX, which it was intended to support, and while it looked like Linux might adopt the model we used, they eventually didn't. There are some semantic differences, most importantly that the "namespace" model is quite different. I have a TODO list item somewhere to ask about getting the source files from Apple relicensed under a BSD license so we can share code there, but haven't quite gotten to that yet. Robert N M Watson Computer Laboratory University of Cambridge From shuvaev at physik.uni-wuerzburg.de Sun Jan 11 11:37:09 2009 From: shuvaev at physik.uni-wuerzburg.de (Alexey Shuvaev) Date: Sun Jan 11 11:37:16 2009 Subject: hangup (livelock) - db> prompt in endless loop In-Reply-To: <3bbf2fe10901050751y74ccd7e3va68fea0634fbd79f@mail.gmail.com> References: <4947C526.2080702@citrin.ru> <494B740B.4080602@citrin.ru> <3bbf2fe10901050751y74ccd7e3va68fea0634fbd79f@mail.gmail.com> Message-ID: <20090111190612.GA3700@wep4035.physik.uni-wuerzburg.de> On Mon, Jan 05, 2009 at 04:51:04PM +0100, Attilio Rao wrote: > 2008/12/19 Anton Yuzhaninov : > > Anton Yuzhaninov wrote: > >> > >> My box with fresh current sometimes stops to respond. > >> > >> On screen in endless loop printed debugger prompt > >> > >> db> > >> > >> but I can't type anything here. > >> > >> Alt+Ctrl+Esc and Alt+Ctrl+Del don't stops this loop. > >> > >> How I can debug this problem? > >> > >> system: current from Mon Dec 15 16:16:23 MSK 2008 with GENERIC kernel, > >> amd64, SMP. > >> > > > > With more fresh current - Wed Dec 17 21:09:38 > > Panic not repeated. > > This is probabilly a bug in the DDB lookup function. > It just stops immediately or after a couple of commands? (and if it > does, which comands exactly?) > Hi! I've seen this too - but only with one src checkout. The symptoms as they are observed: Leave the system with Xorg turned off (text mode), logout all users, switch to ttyv0 (not sure about this) and go away. When you are back, you see db> prompt running on the screen. This was amd64 CURRENT with GENERIC kernel. So, there was no user interaction (via keyboard). Hope, this helps, Alexey. From linimon at lonesome.com Sun Jan 11 09:54:00 2009 From: linimon at lonesome.com (Mark Linimon) Date: Sun Jan 11 12:11:06 2009 Subject: quagga-0.99.11_1 is marked as broken: does not build. In-Reply-To: <496A254F.2020500@FreeBSD.org> References: <49695A15.8010801@psg.com> <496A254F.2020500@FreeBSD.org> Message-ID: <20090111175359.GA4231@soaustin.net> On Sun, Jan 11, 2009 at 07:58:55PM +0300, Sergey Matveychuk wrote: > The fix is already in the port: > http://www.freebsd.org/cgi/cvsweb.cgi/ports/net/quagga/files/patch-zebra-kernel_socket.c?rev=1.5 > > I have no idea why Erwin has marked it as BROKEN again. There was no portrevision bump when the patch went in, so pointyhat did not rebuild the package. He apparently marked it as BROKEN due to the results of the previous run. mcl From erwin at FreeBSD.org Sun Jan 11 12:37:09 2009 From: erwin at FreeBSD.org (Erwin Lansing) Date: Sun Jan 11 12:37:22 2009 Subject: quagga-0.99.11_1 is marked as broken: does not build. In-Reply-To: <20090111175359.GA4231@soaustin.net> References: <49695A15.8010801@psg.com> <496A254F.2020500@FreeBSD.org> <20090111175359.GA4231@soaustin.net> Message-ID: <20090111203706.GA39600@droso.net> On Sun, Jan 11, 2009 at 11:53:59AM -0600, Mark Linimon wrote: > On Sun, Jan 11, 2009 at 07:58:55PM +0300, Sergey Matveychuk wrote: > > The fix is already in the port: > > http://www.freebsd.org/cgi/cvsweb.cgi/ports/net/quagga/files/patch-zebra-kernel_socket.c?rev=1.5 > > > > I have no idea why Erwin has marked it as BROKEN again. > > There was no portrevision bump when the patch went in, so pointyhat > did not rebuild the package. He apparently marked it as BROKEN due to > the results of the previous run. > Indeed. I also check cvs history for the ports Makefile, so I didn't notice the patch that was added. I removed the BROKEN tag. Best, -erwin -- Erwin Lansing http://droso.org Prediction is very difficult erwin@FreeBSD.org especially about the future erwin@aauug.dk -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090111/9944b839/attachment.pgp From dougb at FreeBSD.org Sun Jan 11 15:44:19 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Sun Jan 11 15:44:25 2009 Subject: gcc 4.3: when will it become standard compiler? In-Reply-To: References: <49668763.8020705@mail.zedat.fu-berlin.de> <49671748.3030709@gmx.de> <4967259C.9090408@stillbilde.net> Message-ID: <496A7E07.6090702@FreeBSD.org> Eygene Ryabinkin wrote: > Svein, good day. > > Fri, Jan 09, 2009 at 11:23:24AM +0100, Svein Skogen (List Mail Account) wrote: >> Would it be possible, as a "workaround" to have "system-CC" and >> "ports-CC" defined in make.conf, making one CC the compiler for /usr/src >> and another for ports, or would this just create debugging nightmares? > > Will the following additions to your make.conf suit you? > ----- > .if ${.CURDIR:M/usr/src/*} || ${.CURDIR:M/usr/src} > CC = system-CC > .endif > > .if ${.CURDIR:M/usr/ports/*} || ${.CURDIR:M/usr/ports} > CC = ports-CC > .endif > ----- That's a nice idea, but doesn't take into account those of us for whom /usr/ports is a symlink. ports-mgmt/portconf has the logic in the installer to create the correct lines for make.conf, and has the benefit of being useful for other things too. :) Doug -- This .signature sanitized for your protection From dougb at FreeBSD.org Sun Jan 11 15:49:26 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Sun Jan 11 15:49:32 2009 Subject: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) In-Reply-To: <342292.89033.qm@web32703.mail.mud.yahoo.com> References: <61484.71762.qm@web32708.mail.mud.yahoo.com> <20090111044448.GC5661@server.vk2pj.dyndns.org> <342292.89033.qm@web32703.mail.mud.yahoo.com> Message-ID: <496A7F44.3060503@FreeBSD.org> Pedro F. Giffuni wrote: > There was, however, the idea that the installation could be more > packaged oriented. Yes, this idea is perpetual, in large part because no one has stepped up to do the work. So don't talk about it, just do it. :) Doug -- This .signature sanitized for your protection From gnn at neville-neil.com Sun Jan 11 16:36:01 2009 From: gnn at neville-neil.com (George Neville-Neil) Date: Sun Jan 11 16:36:08 2009 Subject: GEOM and moving to CURRENT from 7.1 Message-ID: Howdy, Beware if you are upgrading from a 7.1 system to CURRENT that you may need to have the kernel options GEOM_MBR and GEOM_BSD in your kernel. I spent a couple of hours dealing with this on my Thinkpad X60 today which had, what I thought, was a pretty simple setup of 1 slice for BSD, and a simple layout of /, swap and /usr. When I tried to boot the new kernel I got to the mount error prompt and could not mount ad4p1 or anything like it. Adding the GEOM_MBR and GEOM_BSD options back into the kernel fixed things. Happily I was able to boot 7.1 still and fix this. Best, George -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090112/a51e955b/PGP.pgp From eitanadlerlist at gmail.com Sun Jan 11 17:00:44 2009 From: eitanadlerlist at gmail.com (Eitan Adler) Date: Sun Jan 11 17:00:49 2009 Subject: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) In-Reply-To: <4969CC6D.6030707@mail.zedat.fu-berlin.de> References: <61484.71762.qm@web32708.mail.mud.yahoo.com> <20090111044448.GC5661@server.vk2pj.dyndns.org> <4969CC6D.6030707@mail.zedat.fu-berlin.de> Message-ID: <496A8F45.7010400@gmail.com> I never took care about GPLv2 and v3 > differences but know, this seems to come to relevance in some way. I don't seem to understand this. Why should gpl v3 affect the OS? The output of the compiler isn't affected by the license. Is it? -- Eitan Adler "Security is increased by designing for the way humans actually behave." -Jakob Nielsen From kientzle at freebsd.org Sun Jan 11 17:11:25 2009 From: kientzle at freebsd.org (Tim Kientzle) Date: Sun Jan 11 17:11:31 2009 Subject: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) In-Reply-To: <342292.89033.qm@web32703.mail.mud.yahoo.com> References: <61484.71762.qm@web32708.mail.mud.yahoo.com> <20090111044448.GC5661@server.vk2pj.dyndns.org> <342292.89033.qm@web32703.mail.mud.yahoo.com> Message-ID: <496A98B3.1010301@freebsd.org> >>... the FreeBSD base system should come complete with the >>necessary tools to build/install itself. > > OK, I quite agree it's not the same as perl: C is not something we cannot depend on. You can easily install FreeBSD without a C compiler or other build tools. There's very little reason to do so in a typical desktop/server installation, which is why this capability is used almost exclusively by people building embedded systems or special-use CD-bootable systems. But even in those environments, this concern is fading: multi-gigabyte flash parts and bootable DVDs and USB keys are becoming pretty common. Tim From yanefbsd at gmail.com Sun Jan 11 18:13:49 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Sun Jan 11 18:13:56 2009 Subject: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) In-Reply-To: <496A8F45.7010400@gmail.com> References: <61484.71762.qm@web32708.mail.mud.yahoo.com> <20090111044448.GC5661@server.vk2pj.dyndns.org> <4969CC6D.6030707@mail.zedat.fu-berlin.de> <496A8F45.7010400@gmail.com> Message-ID: <7d6fde3d0901111813y3da92325p6d2a3541d7db53a2@mail.gmail.com> On Sun, Jan 11, 2009 at 4:31 PM, Eitan Adler wrote: > I never took care about GPLv2 and v3 >> differences but know, this seems to come to relevance in some way. > > I don't seem to understand this. Why should gpl v3 affect the OS? The > output of the compiler isn't affected by the license. Is it? Yes the GPLv3 is `extremely viral' when dealing with proprietary innovations and features, compared to GPLv2. Hence that's why Apple, Cisco, Intel, Juniper, etc are incredibly wary of licensing, and are sidestepping around the whole GPLv3 issue as much as possible, wherever possible. Many companies also have to write in functionality and tie-ins which expose portions of the OS, debugging tools, libraries, etc that would require them to expose their proprietary secrets. They should be just as exposed with GPLv2, but the GPLv3 is more stringent and the FSF is ramping up copyright infringement notices to get people to adhere to the licenses they accepted when they started hacking at the relevant pieces of opensource software, as many people having been conforming to the licensing agreements and terms contained within the accepted licenses. Definitely look up the terms of the LGPL and GPL and compare and contrast those licenses versus the BSD, MIT, and Apache licenses. You might be surprised... Cheers, -Garrett From Peter.Ross at alumni.tu-berlin.de Sun Jan 11 18:28:10 2009 From: Peter.Ross at alumni.tu-berlin.de (Peter Ross) Date: Sun Jan 11 18:28:18 2009 Subject: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) In-Reply-To: <496A98B3.1010301@freebsd.org> References: <61484.71762.qm@web32708.mail.mud.yahoo.com> <20090111044448.GC5661@server.vk2pj.dyndns.org> <342292.89033.qm@web32703.mail.mud.yahoo.com> <496A98B3.1010301@freebsd.org> Message-ID: Hi Tim, AFAIK you _need_ a C compiler to keep your system secure, to apply security patches. E.g. http://security.freebsd.org/advisories/FreeBSD-SA-09:02.openssl.asc .. make obj && make depend && make && make install .. Of course there are build-boxes etc. so you only need a compiler once. But still, you need a box to compile it. Regards Peter On Sun, 11 Jan 2009, Tim Kientzle wrote: > > > ... the FreeBSD base system should come complete with the > > > necessary tools to build/install itself. > > > > OK, I quite agree it's not the same as perl: C is not something we cannot > > depend on. > > You can easily install FreeBSD without a C compiler > or other build tools. > > There's very little reason to do so in a typical > desktop/server installation, which is why this > capability is used almost exclusively by people > building embedded systems or special-use > CD-bootable systems. But even in those > environments, this concern is fading: > multi-gigabyte flash parts and bootable DVDs > and USB keys are becoming pretty common. > > Tim > _______________________________________________ > 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 morganw at chemikals.org Sun Jan 11 18:40:27 2009 From: morganw at chemikals.org (Wes Morgan) Date: Sun Jan 11 18:40:34 2009 Subject: GEOM and moving to CURRENT from 7.1 In-Reply-To: References: Message-ID: On Sun, 11 Jan 2009, George Neville-Neil wrote: > Howdy, > > Beware if you are upgrading from a 7.1 system to CURRENT that you may > need to have the kernel options GEOM_MBR and GEOM_BSD in your kernel. > I spent a couple of hours dealing with this on my Thinkpad X60 today > which had, what I thought, was a pretty simple setup of 1 slice for BSD, > and a simple layout of /, swap and /usr. When I tried to boot the new > kernel I got to the mount error prompt and could not mount ad4p1 or > anything like it. Adding the GEOM_MBR and GEOM_BSD options back into the > kernel fixed things. Happily I was able to boot 7.1 still and fix this. There are several things to be aware of moving from GEOM_MBR|BSD to GEOM_PART_*. My label was "wrong" in gpart's eyes, and I had to relabel the drive with a copy of the same label (no data loss). I also have a ZFS root filesystem embedded in the "e" part of the slice, which was marked as "unused" in the label, and thus GEOM_PART_BSD created no device node in /dev. Changing it from "unused" to "ZFS" in the label was the solution to that. Unfortunately, during the process of "fixing" the label, grub stopped working, leaving my system without a boot loader. In the absence of a bootable live cd, I had to pop out the drive and plug it in to another system to install the standard boot loader. Was not a fun evening! From yanefbsd at gmail.com Sun Jan 11 18:53:10 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Sun Jan 11 18:53:23 2009 Subject: X becomes unresponsive with nvidia and hardlocks with gdb (was Re: X becomes unresponsive with nvidia / xscreensaver and desktop panics) In-Reply-To: <7d6fde3d0901091705v6eb4c7bfxe23708f8651e2125@mail.gmail.com> References: <7d6fde3d0901091705v6eb4c7bfxe23708f8651e2125@mail.gmail.com> Message-ID: <7d6fde3d0901111853k40f26893j722d95d3556c820@mail.gmail.com> On Fri, Jan 9, 2009 at 5:05 PM, Garrett Cooper wrote: > On Fri, Jan 9, 2009 at 2:05 PM, Garrett Cooper wrote: >> On Fri, Jan 9, 2009 at 1:40 PM, Doug Barton wrote: >>> Garrett Cooper wrote: >>>> Thanks for the tips Doug -- I'll give them a shot of course... >>> >>> Glad I could help. The one thing I forgot to mention is to try the >>> nvidia-settings app if you have not already done so. There are various >>> things there that you can tweak that might yield better results. >>> >>> Doug >> >> I did in fact set everything up via nvidia-settings. I'm running >> some stress tests right now to see whether or not I can simulate the >> issue -- it doesn't appear to be as straightforward as I thought.. >> -Garrett >> > > I believe my actual problem with panicking is related to gdb, not X11. > So the actual problem is two-fold: > > - X11 livelocks, where I can login via ssh and kill . > - When I use gdb -p, it prints out the same message reported here: > . The only > thing is that if I press `y' on the first go-around, the machine > hardlocks on the first try with hitting `y'. If I hit `n' so gdb > coredumps, I can either go on my merry way, or go back to the > confirmation dialog. If I hit it again, it doesn't hardlock. It does > hardlock though, and for whatever reason my PC speaker beeps, and I > have to warm boot it. I haven't been able to get a kernel dump though, > so something else mysteriously is going on that I can't track. > > So, just to simplify: > > first_try := True > > while gdb is running: > if prompt_for_coredump() and first_try is True: > panic() > first_try := False > > Thanks, > -Garrett Ok, I've been doing some more poking around this weekend, and here's what I discovered: - I've rebuilt my xorg-server a few times and it's still claiming that it was built with 7.1-RC2 -_-... - I can get the Xorg server to go full tilt by just compiling something, like buildworld, via an xterm. - I can't attach truss to Xorg, or the Xorg will livelock. Now, trying out the nv driver: - It constantly uses up ~20% CPU on one of my four cores. When I compile something it chews up ~50% CPU. - I can attach truss to Xorg, but it drags the CPU up to ~100%. Xorg was spending a LOT of time pinging socket data around, which makes me think that what the nvidia driver is doing is actually unrooting a performance issue with the IPC mechanism in Xorg, as nv suffers from the same thing, just on a less grand scale; mind you, I can get both of my screens up and running under nvidia at different resolutions -- 1920x1200 and 1680 x 1050 -- but under nv I only get 2 displays setup at 1680 x 1050. - Detaching truss causes the livelock condition (again). Rebuilding xorg-server has proven to help so far. I did delete-old-files, and it appears that xorg-server may have been picking up some old libraries still. Let's see if this sticks or not... Cheers, -Garrett From giffunip at tutopia.com Sun Jan 11 17:21:36 2009 From: giffunip at tutopia.com (Pedro F. Giffuni) Date: Sun Jan 11 23:11:16 2009 Subject: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) References: <61484.71762.qm@web32708.mail.mud.yahoo.com> <20090111044448.GC5661@server.vk2pj.dyndns.org> <4969CC6D.6030707@mail.zedat.fu-berlin.de> <496A8F45.7010400@gmail.com> Message-ID: <749382.92616.qm@web32702.mail.mud.yahoo.com> ( Sorry everyone about my email not wrapping text anymore :( ) ----- Original Message ---- > > I never took care about GPLv2 and v3 > > differences but know, this seems to come to relevance in some way. > > I don't seem to understand this. Why should gpl v3 affect the OS? The > output of the compiler isn't affected by the license. Is it? > Perhaps we just want to avoid trouble to our commercial co-developers: http://en.wikipedia.org/wiki/FSF_vs._Cisco cheers, Pedro. From Peter.Ross at bogen.in-berlin.de Sun Jan 11 19:10:27 2009 From: Peter.Ross at bogen.in-berlin.de (Peter Ross) Date: Sun Jan 11 23:11:31 2009 Subject: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) In-Reply-To: <7d6fde3d0901111813y3da92325p6d2a3541d7db53a2@mail.gmail.com> References: <61484.71762.qm@web32708.mail.mud.yahoo.com> <20090111044448.GC5661@server.vk2pj.dyndns.org> <4969CC6D.6030707@mail.zedat.fu-berlin.de> <496A8F45.7010400@gmail.com> <7d6fde3d0901111813y3da92325p6d2a3541d7db53a2@mail.gmail.com> Message-ID: On Sun, 11 Jan 2009, Garrett Cooper wrote: > Definitely look up the terms of the LGPL and GPL and compare and > contrast those licenses versus the BSD, MIT, and Apache licenses. You > might be surprised... Probably more interesting are comparisons between GPL v2 and v3 and concerns voiced by Linux developers. E.g. http://en.wikipedia.org/wiki/GNU_General_Public_License and http://lwn.net/Articles/200422/. I am not a lawyer .. I have an opinion but it is probably better to leave comments to people with better understanding of legal issues. Regards Peter From nakal at web.de Sun Jan 11 23:39:52 2009 From: nakal at web.de (Martin) Date: Sun Jan 11 23:40:01 2009 Subject: GEOM and moving to CURRENT from 7.1 In-Reply-To: References: Message-ID: <20090112081221.600f6681@zelda.local> Am Sun, 11 Jan 2009 20:40:13 -0600 (CST) schrieb Wes Morgan : > In the absence of a > bootable live cd, I had to pop out the drive and plug it in to > another system to install the standard boot loader. Was not a fun > evening! Hi Wes, and I can tell you one more thing. Even you actually _have_ the livefs CD (8.0-CURRENT, december snapshot), it won't help you to fix your GPT, because gpart crashes when you call it on the command line from Fixit console. -- Martin From CQG00620 at nifty.ne.jp Mon Jan 12 00:15:42 2009 From: CQG00620 at nifty.ne.jp (WATANABE Kazuhiro) Date: Mon Jan 12 00:15:50 2009 Subject: usb2: kernel panic with an USB floppy drive Message-ID: <20090112081541.0BC3964AC8@mail.asahi-net.or.jp> Hi, all. I have an USB floppy drive which works well on 7.1-RELEASE, and 8-current with the old USB stack. ***** umass0: on uhub0 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 20KB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present port 1 addr 2: full speed, power 500 mA, config 1, USB Floppy Drive(0x0000), Y-E DATA(0x057b), rev 5.01 ***** When I connect the floppy drive to the system with the new USB2 stack, it causes a kernel panic. Here is a stack trace and dmesg output. capricorn# kgdb /boot/kernel/kernel.symbols /var/crash/vmcore.0 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 "i386-marcel-freebsd"... Unread portion of the kernel message buffer: umass0:1:0:-1: Attached to scbus1 Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex UMASS lock (UMASS lock) r = 0 (0xc0d69800) locked @ /FreeBSD/HEAD/src/sys/dev/usb2/core/usb2_transfer.c:1781 KDB: stack backtrace: db_trace_self_wrapper(c0c1f7c2,cc93ea28,c088f145,c0c0d089,6f5,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0c0d089,6f5,ffffffff,c0eabdc4,cc93ea60,...) at kdb_backtrace+0x29 _witness_debugger(c0c21ae3,cc93ea74,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c0c53da2,c28d3b40,c288ea90,...) at witness_warn+0x1fd trap(cc93eb00) at trap+0x152 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0xc0b32da5, esp = 0xcc93eb40, ebp = 0xcc93eb78 --- bus_dmamap_load(c29a4e80,c0ef2bc0,0,24,c077e8b0,...) at bus_dmamap_load+0xd5 usb2_pc_load_mem(c2b87f80,24,0,4cf,c0c02651,...) at usb2_pc_load_mem+0x125 usb2_bdma_work_loop(c2b86000,c2b86400,10000ca,c2b4a900,1,...) at usb2_bdma_work_loop+0x2b5 usb2_command_wrapper(c2b86000,c2b86400,c0c0d089,55b,c28d3be4,...) at usb2_command_wrapper+0x116 usb2_start_hardware(c2b86400,c084127c,c2690b68,4,c0c1ac2a,...) at usb2_start_hardware+0x6eb umass_t_cbi_data_read_callback(c2b86400,0,c0c0d089,752,c0eabdc0,...) at umass_t_cbi_data_read_callback+0xfe usb2_callback_wrapper(c2b86014,6f6,0,c2b86000,c2b86000,...) at usb2_callback_wrapper+0x63a usb2_command_wrapper(c2b86014,0,c0c0d089,6f6,c2b86028,...) at usb2_command_wrapper+0x116 usb2_callback_proc(c2b86028,c2690b68,c0c0cc24,51,c0d704c0,...) at usb2_callback_proc+0x9b usb2_process(c2b86078,cc93ed38,c0c18395,32d,c288ea90,...) at usb2_process+0xde fork_exit(c07906b0,c2b86078,cc93ed38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xcc93ed70, ebp = 0 --- Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xbfc00000 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0b32da5 stack pointer = 0x28:0xcc93eb40 frame pointer = 0x28:0xcc93eb78 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1338 (USBPROC) lock order reversal: (Giant after non-sleepable) 1st 0xc0d69800 UMASS lock (UMASS lock) @ /FreeBSD/HEAD/src/sys/dev/usb2/core/usb2_transfer.c:1781 2nd 0xc0d6bfb0 Giant (Giant) @ /FreeBSD/HEAD/src/sys/dev/kbdmux/kbdmux.c:1044 KDB: stack backtrace: panic: from debugger cpuid = 0 Uptime: 2m8s Physical memory: 223 MB Dumping 40 MB: 25 9 Reading symbols from /boot/kernel/green_saver.ko...Reading symbols from /boot/kernel/green_saver.ko.symbols...done. done. Loaded symbols for /boot/kernel/green_saver.ko #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump () at pcpu.h:246 #1 0xc084fe5e in boot (howto=260) at /FreeBSD/HEAD/src/sys/kern/kern_shutdown.c:420 #2 0xc0850132 in panic (fmt=Variable "fmt" is not available. ) at /FreeBSD/HEAD/src/sys/kern/kern_shutdown.c:576 #3 0xc04bdc27 in db_panic (addr=Could not find the frame base for "db_panic". ) at /FreeBSD/HEAD/src/sys/ddb/db_command.c:478 #4 0xc04be251 in db_command (last_cmdp=0xc0d3a55c, cmd_table=0x0, dopager=1) at /FreeBSD/HEAD/src/sys/ddb/db_command.c:445 #5 0xc04be3aa in db_command_loop () at /FreeBSD/HEAD/src/sys/ddb/db_command.c:498 #6 0xc04c020d in db_trap (type=12, code=0) at /FreeBSD/HEAD/src/sys/ddb/db_main.c:229 #7 0xc087d7f6 in kdb_trap (type=12, code=0, tf=0xcc93eb00) at /FreeBSD/HEAD/src/sys/kern/subr_kdb.c:534 #8 0xc0b50e0f in trap_fatal (frame=0xcc93eb00, eva=3217031168) at /FreeBSD/HEAD/src/sys/i386/i386/trap.c:920 #9 0xc0b51740 in trap (frame=0xcc93eb00) at /FreeBSD/HEAD/src/sys/i386/i386/trap.c:318 #10 0xc0b35b6b in calltrap () at /FreeBSD/HEAD/src/sys/i386/i386/exception.s:165 #11 0xc0b32da5 in bus_dmamap_load (dmat=0xc29a4e80, map=0xc0ef2bc0, buf=0x0, buflen=36, callback=0xc077e8b0 , callback_arg=0xc2b87f80, flags=0) at pmap.h:282 ---Type to continue, or q to quit--- #12 0xc077e415 in usb2_pc_load_mem (pc=0xc2b87f80, size=36, sync=0 '\0') at /FreeBSD/HEAD/src/sys/dev/usb2/core/usb2_busdma.c:635 #13 0xc077e705 in usb2_bdma_work_loop (pq=0xc2b86000) at /FreeBSD/HEAD/src/sys/dev/usb2/core/usb2_busdma.c:1318 #14 0xc0793076 in usb2_command_wrapper (pq=0xc2b86000, xfer=0xc2b86400) at /FreeBSD/HEAD/src/sys/dev/usb2/core/usb2_transfer.c:2484 #15 0xc079434b in usb2_start_hardware (xfer=0xc2b86400) at /FreeBSD/HEAD/src/sys/dev/usb2/core/usb2_transfer.c:1491 #16 0xc077c19e in umass_t_cbi_data_read_callback (xfer=0xc2b86400) at /FreeBSD/HEAD/src/sys/dev/usb2/storage/umass2.c:2414 #17 0xc07956da in usb2_callback_wrapper (pq=0xc2b86014) at /FreeBSD/HEAD/src/sys/dev/usb2/core/usb2_transfer.c:1911 #18 0xc0793076 in usb2_command_wrapper (pq=0xc2b86014, xfer=0x0) at /FreeBSD/HEAD/src/sys/dev/usb2/core/usb2_transfer.c:2484 #19 0xc079315b in usb2_callback_proc (_pm=0xc2b86028) at /FreeBSD/HEAD/src/sys/dev/usb2/core/usb2_transfer.c:1785 #20 0xc079078e in usb2_process (arg=0xc2b86078) at /FreeBSD/HEAD/src/sys/dev/usb2/core/usb2_process.c:139 #21 0xc082ce48 in fork_exit (callout=0xc07906b0 , arg=0xc2b86078, frame=0xcc93ed38) at /FreeBSD/HEAD/src/sys/kern/kern_fork.c:821 #22 0xc0b35be0 in fork_trampoline () at /FreeBSD/HEAD/src/sys/i386/i386/exception.s:270 (kgdb) quit capricorn# 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: Sun Jan 11 22:14:07 JST 2009 nabe@capricorn:/FreeBSD/obj/i386/HEAD/FreeBSD/HEAD/src/sys/USB2 WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.00GHz (1991.92-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf24 Stepping = 4 Features=0x3febfbff real memory = 251592704 (239 MB) avail memory = 227368960 (216 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard lapic0: Forcing LINT1 to edge trigger kbd0 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: on hostb0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0x9000-0x907f mem 0xf0000000-0xf7ffffff,0xec100000-0xec11ffff irq 16 at device 0.0 on pci1 isab0: at device 2.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1000-0x100f at device 2.5 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 2.7 (no driver attached) ohci0: mem 0xec000000-0xec000fff irq 20 at device 3.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ohci1: mem 0xec001000-0xec001fff irq 21 at device 3.1 on pci0 ohci1: [ITHREAD] usbus1: on ohci1 ohci2: mem 0xec002000-0xec002fff irq 22 at device 3.2 on pci0 ohci2: [ITHREAD] usbus2: on ohci2 ehci0: mem 0xec003000-0xec003fff irq 23 at device 3.3 on pci0 ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 fwohci0: mem 0xec004000-0xec004fff irq 18 at device 6.0 on pci0 fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:00:4c:e0:26:82:00:a8 fwohci0: Phy 1394a available S400, 3 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0xeb80000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:00:4c:82:00:a8 fwe0: Ethernet address: 02:00:4c:82:00:a8 fwip0: on firewire0 fwip0: Firewire address: 00:00:4c:e0:26:82:00:a8 @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc000ffc0, gen=1, CYCLEMASTER mode cbb0: at device 8.0 on pci0 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [FILTER] cbb1: at device 8.1 on pci0 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 cbb1: [FILTER] pci0: at device 16.0 (no driver attached) pci0: at device 18.0 (no driver attached) dc0: port 0x1c00-0x1cff mem 0xec005400-0xec0057ff irq 17 at device 20.0 on pci0 miibus0: on dc0 acphy0: PHY 1 on miibus0 acphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc0: Ethernet address: 00:90:96:xx:xx:xx dc0: [ITHREAD] pci0: at device 20.1 (no driver attached) acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd1 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3 ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppc0: [GIANT-LOCKED] ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 cpu0: on acpi0 p4tcc0: on cpu0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcbfff,0xcc000-0xce7ff,0xe0000-0xe3fff,0xe4000-0xe47ff,0xe4800-0xeffff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 1991920060 Hz quality 800 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 ushub0: on usbus0 ugen1.1: at usbus1 ushub1: on usbus1 ugen2.1: at usbus2 ushub2: on usbus2 ugen3.1: at usbus3 ushub3: on usbus3 ad0: 78147MB at ata0-master UDMA100 ushub0: 2 ports with 2 removable, self powered ushub1: 2 ports with 2 removable, self powered ushub2: 2 ports with 2 removable, self powered acd0: CDRW at ata1-master UDMA33 GEOM: ad0s2: geometry does not match label (255h,63s != 16h,63s). GEOM: ad0s3: geometry does not match label (255h,63s != 16h,63s). GEOM_LABEL: Label for provider ad0s4 is msdosfs/NEC-RESTORE. ushub3: 6 ports with 6 removable, self powered ugen3.2: at usbus3 ushub4: on usbus3 ushub4: 4 ports with 4 removable, self powered WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/ad0s3a --- WATANABE Kazuhiro (CQG00620@nifty.ne.jp) From hselasky at c2i.net Mon Jan 12 00:35:08 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Mon Jan 12 00:35:16 2009 Subject: usb2: kernel panic with an USB floppy drive In-Reply-To: <20090112081541.0BC3964AC8@mail.asahi-net.or.jp> References: <20090112081541.0BC3964AC8@mail.asahi-net.or.jp> Message-ID: <200901120937.28951.hselasky@c2i.net> Hi, Thanks for reporting. This bug looks like a glitch on my side when introducing Zero-copy in UMASS. Try the following patch: http://perforce.freebsd.org/chv.cgi?CH=156005 --HPS On Monday 12 January 2009, WATANABE Kazuhiro wrote: > Hi, all. > > I have an USB floppy drive which works well on 7.1-RELEASE, and > 8-current with the old USB stack. > > ***** > umass0: on > uhub0 da0 at umass-sim0 bus 0 target 0 lun 0 > da0: Removable Direct Access SCSI-0 device > da0: 20KB/s transfers > da0: Attempt to query device size failed: NOT READY, Medium not present > > port 1 addr 2: full speed, power 500 mA, config 1, USB Floppy > Drive(0x0000), Y-E DATA(0x057b), rev 5.01 ***** > > When I connect the floppy drive to the system with the new USB2 stack, > it causes a kernel panic. > > > Here is a stack trace and dmesg output. > > capricorn# kgdb /boot/kernel/kernel.symbols /var/crash/vmcore.0 > 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 "i386-marcel-freebsd"... > > Unread portion of the kernel message buffer: > umass0:1:0:-1: Attached to scbus1 > Kernel page fault with the following non-sleepable locks held: > exclusive sleep mutex UMASS lock (UMASS lock) r = 0 (0xc0d69800) locked @ > /FreeBSD/HEAD/src/sys/dev/usb2/core/usb2_transfer.c:1781 KDB: stack > backtrace: > db_trace_self_wrapper(c0c1f7c2,cc93ea28,c088f145,c0c0d089,6f5,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(c0c0d089,6f5,ffffffff,c0eabdc4,cc93ea60,...) at > kdb_backtrace+0x29 _witness_debugger(c0c21ae3,cc93ea74,4,1,0,...) at > _witness_debugger+0x25 witness_warn(5,0,c0c53da2,c28d3b40,c288ea90,...) at > witness_warn+0x1fd trap(cc93eb00) at trap+0x152 > calltrap() at calltrap+0x6 > --- trap 0xc, eip = 0xc0b32da5, esp = 0xcc93eb40, ebp = 0xcc93eb78 --- > bus_dmamap_load(c29a4e80,c0ef2bc0,0,24,c077e8b0,...) at > bus_dmamap_load+0xd5 usb2_pc_load_mem(c2b87f80,24,0,4cf,c0c02651,...) at > usb2_pc_load_mem+0x125 > usb2_bdma_work_loop(c2b86000,c2b86400,10000ca,c2b4a900,1,...) at > usb2_bdma_work_loop+0x2b5 > usb2_command_wrapper(c2b86000,c2b86400,c0c0d089,55b,c28d3be4,...) at > usb2_command_wrapper+0x116 > usb2_start_hardware(c2b86400,c084127c,c2690b68,4,c0c1ac2a,...) at > usb2_start_hardware+0x6eb > umass_t_cbi_data_read_callback(c2b86400,0,c0c0d089,752,c0eabdc0,...) at > umass_t_cbi_data_read_callback+0xfe > usb2_callback_wrapper(c2b86014,6f6,0,c2b86000,c2b86000,...) at > usb2_callback_wrapper+0x63a > usb2_command_wrapper(c2b86014,0,c0c0d089,6f6,c2b86028,...) at > usb2_command_wrapper+0x116 > usb2_callback_proc(c2b86028,c2690b68,c0c0cc24,51,c0d704c0,...) at > usb2_callback_proc+0x9b > usb2_process(c2b86078,cc93ed38,c0c18395,32d,c288ea90,...) at > usb2_process+0xde fork_exit(c07906b0,c2b86078,cc93ed38) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xcc93ed70, ebp = 0 --- > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0xbfc00000 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc0b32da5 > stack pointer = 0x28:0xcc93eb40 > frame pointer = 0x28:0xcc93eb78 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 1338 (USBPROC) > lock order reversal: (Giant after non-sleepable) > 1st 0xc0d69800 UMASS lock (UMASS lock) @ > /FreeBSD/HEAD/src/sys/dev/usb2/core/usb2_transfer.c:1781 2nd 0xc0d6bfb0 > Giant (Giant) @ /FreeBSD/HEAD/src/sys/dev/kbdmux/kbdmux.c:1044 KDB: stack > backtrace: > panic: from debugger > cpuid = 0 > Uptime: 2m8s > Physical memory: 223 MB > Dumping 40 MB: 25 9 > > Reading symbols from /boot/kernel/green_saver.ko...Reading symbols from > /boot/kernel/green_saver.ko.symbols...done. done. > Loaded symbols for /boot/kernel/green_saver.ko > #0 doadump () at pcpu.h:246 > 246 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) where > #0 doadump () at pcpu.h:246 > #1 0xc084fe5e in boot (howto=260) > at /FreeBSD/HEAD/src/sys/kern/kern_shutdown.c:420 > #2 0xc0850132 in panic (fmt=Variable "fmt" is not available. > ) > at /FreeBSD/HEAD/src/sys/kern/kern_shutdown.c:576 > #3 0xc04bdc27 in db_panic (addr=Could not find the frame base for > "db_panic". ) > at /FreeBSD/HEAD/src/sys/ddb/db_command.c:478 > #4 0xc04be251 in db_command (last_cmdp=0xc0d3a55c, cmd_table=0x0, > dopager=1) at /FreeBSD/HEAD/src/sys/ddb/db_command.c:445 > #5 0xc04be3aa in db_command_loop () > at /FreeBSD/HEAD/src/sys/ddb/db_command.c:498 > #6 0xc04c020d in db_trap (type=12, code=0) > at /FreeBSD/HEAD/src/sys/ddb/db_main.c:229 > #7 0xc087d7f6 in kdb_trap (type=12, code=0, tf=0xcc93eb00) > at /FreeBSD/HEAD/src/sys/kern/subr_kdb.c:534 > #8 0xc0b50e0f in trap_fatal (frame=0xcc93eb00, eva=3217031168) > at /FreeBSD/HEAD/src/sys/i386/i386/trap.c:920 > #9 0xc0b51740 in trap (frame=0xcc93eb00) > at /FreeBSD/HEAD/src/sys/i386/i386/trap.c:318 > #10 0xc0b35b6b in calltrap () > at /FreeBSD/HEAD/src/sys/i386/i386/exception.s:165 > #11 0xc0b32da5 in bus_dmamap_load (dmat=0xc29a4e80, map=0xc0ef2bc0, > buf=0x0, buflen=36, callback=0xc077e8b0 , > callback_arg=0xc2b87f80, flags=0) at pmap.h:282 > ---Type to continue, or q to quit--- > #12 0xc077e415 in usb2_pc_load_mem (pc=0xc2b87f80, size=36, sync=0 '\0') > at /FreeBSD/HEAD/src/sys/dev/usb2/core/usb2_busdma.c:635 > #13 0xc077e705 in usb2_bdma_work_loop (pq=0xc2b86000) > at /FreeBSD/HEAD/src/sys/dev/usb2/core/usb2_busdma.c:1318 > #14 0xc0793076 in usb2_command_wrapper (pq=0xc2b86000, xfer=0xc2b86400) > at /FreeBSD/HEAD/src/sys/dev/usb2/core/usb2_transfer.c:2484 > #15 0xc079434b in usb2_start_hardware (xfer=0xc2b86400) > at /FreeBSD/HEAD/src/sys/dev/usb2/core/usb2_transfer.c:1491 > #16 0xc077c19e in umass_t_cbi_data_read_callback (xfer=0xc2b86400) > at /FreeBSD/HEAD/src/sys/dev/usb2/storage/umass2.c:2414 > #17 0xc07956da in usb2_callback_wrapper (pq=0xc2b86014) > at /FreeBSD/HEAD/src/sys/dev/usb2/core/usb2_transfer.c:1911 > #18 0xc0793076 in usb2_command_wrapper (pq=0xc2b86014, xfer=0x0) > at /FreeBSD/HEAD/src/sys/dev/usb2/core/usb2_transfer.c:2484 > #19 0xc079315b in usb2_callback_proc (_pm=0xc2b86028) > at /FreeBSD/HEAD/src/sys/dev/usb2/core/usb2_transfer.c:1785 > #20 0xc079078e in usb2_process (arg=0xc2b86078) > at /FreeBSD/HEAD/src/sys/dev/usb2/core/usb2_process.c:139 > #21 0xc082ce48 in fork_exit (callout=0xc07906b0 , > arg=0xc2b86078, frame=0xcc93ed38) > at /FreeBSD/HEAD/src/sys/kern/kern_fork.c:821 > #22 0xc0b35be0 in fork_trampoline () > at /FreeBSD/HEAD/src/sys/i386/i386/exception.s:270 > (kgdb) quit > capricorn# > > > 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: Sun Jan 11 22:14:07 JST 2009 > nabe@capricorn:/FreeBSD/obj/i386/HEAD/FreeBSD/HEAD/src/sys/USB2 > WARNING: WITNESS option enabled, expect reduced performance. > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Pentium(R) 4 CPU 2.00GHz (1991.92-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf24 Stepping = 4 > > Features=0x3febfbffA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM> real memory > = 251592704 (239 MB) > avail memory = 227368960 (216 MB) > ACPI APIC Table: > ioapic0 irqs 0-23 on motherboard > lapic0: Forcing LINT1 to edge trigger > kbd0 at kbdmux0 > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > agp0: on hostb0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > vgapci0: port 0x9000-0x907f mem > 0xf0000000-0xf7ffffff,0xec100000-0xec11ffff irq 16 at device 0.0 on pci1 > isab0: at device 2.0 on pci0 > isa0: on isab0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1000-0x100f at device 2.5 on pci0 > ata0: on atapci0 > ata0: [ITHREAD] > ata1: on atapci0 > ata1: [ITHREAD] > pci0: at device 2.7 (no driver attached) > ohci0: mem 0xec000000-0xec000fff irq 20 at device > 3.0 on pci0 ohci0: [ITHREAD] > usbus0: on ohci0 > ohci1: mem 0xec001000-0xec001fff irq 21 at device > 3.1 on pci0 ohci1: [ITHREAD] > usbus1: on ohci1 > ohci2: mem 0xec002000-0xec002fff irq 22 at device > 3.2 on pci0 ohci2: [ITHREAD] > usbus2: on ohci2 > ehci0: mem 0xec003000-0xec003fff irq 23 > at device 3.3 on pci0 ehci0: [ITHREAD] > usbus3: EHCI version 1.0 > usbus3: on ehci0 > fwohci0: mem 0xec004000-0xec004fff irq 18 at device 6.0 on > pci0 fwohci0: [FILTER] > fwohci0: OHCI version 1.10 (ROM=1) > fwohci0: No. of Isochronous channels is 4. > fwohci0: EUI64 00:00:4c:e0:26:82:00:a8 > fwohci0: Phy 1394a available S400, 3 ports. > fwohci0: Link S400, max_rec 2048 bytes. > firewire0: on fwohci0 > dcons_crom0: on firewire0 > dcons_crom0: bus_addr 0xeb80000 > fwe0: on firewire0 > if_fwe0: Fake Ethernet address: 02:00:4c:82:00:a8 > fwe0: Ethernet address: 02:00:4c:82:00:a8 > fwip0: on firewire0 > fwip0: Firewire address: 00:00:4c:e0:26:82:00:a8 @ 0xfffe00000000, S400, > maxrec 2048 sbp0: on firewire0 > fwohci0: Initiate bus reset > fwohci0: BUS reset > fwohci0: node_id=0xc000ffc0, gen=1, CYCLEMASTER mode > cbb0: at device 8.0 on pci0 > cardbus0: on cbb0 > pccard0: <16-bit PCCard bus> on cbb0 > cbb0: [FILTER] > cbb1: at device 8.1 on pci0 > cardbus1: on cbb1 > pccard1: <16-bit PCCard bus> on cbb1 > cbb1: [FILTER] > pci0: at device 16.0 (no driver attached) > pci0: at device 18.0 (no driver attached) > dc0: port 0x1c00-0x1cff mem > 0xec005400-0xec0057ff irq 17 at device 20.0 on pci0 miibus0: on > dc0 > acphy0: PHY 1 on miibus0 > acphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > dc0: Ethernet address: 00:90:96:xx:xx:xx > dc0: [ITHREAD] > pci0: at device 20.1 (no driver attached) > acpi_button0: on acpi0 > atrtc0: port 0x70-0x71 irq 8 on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: flags 0x1 irq 1 on atkbdc0 > kbd1 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: [ITHREAD] > psm0: model IntelliMouse, device ID 3 > ppc0: port 0x378-0x37f irq 7 on acpi0 > ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode > ppc0: [GIANT-LOCKED] > ppc0: [ITHREAD] > ppbus0: on ppc0 > plip0: on ppbus0 > plip0: WARNING: using obsoleted IFF_NEEDSGIANT flag > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppi0: on ppbus0 > cpu0: on acpi0 > p4tcc0: on cpu0 > pmtimer0 on isa0 > orm0: at iomem > 0xc0000-0xcbfff,0xcc000-0xce7ff,0xe0000-0xe3fff,0xe4000-0xe47ff,0xe4800-0xe >ffff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > Timecounter "TSC" frequency 1991920060 Hz quality 800 > Timecounters tick every 1.000 msec > firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) > firewire0: bus manager 0 (me) > usbus0: 12Mbps Full Speed USB v1.0 > usbus1: 12Mbps Full Speed USB v1.0 > usbus2: 12Mbps Full Speed USB v1.0 > usbus3: 480Mbps High Speed USB v2.0 > ugen0.1: at usbus0 > ushub0: on usbus0 > ugen1.1: at usbus1 > ushub1: on usbus1 > ugen2.1: at usbus2 > ushub2: on usbus2 > ugen3.1: at usbus3 > ushub3: on usbus3 > ad0: 78147MB at ata0-master UDMA100 > ushub0: 2 ports with 2 removable, self powered > ushub1: 2 ports with 2 removable, self powered > ushub2: 2 ports with 2 removable, self powered > acd0: CDRW at ata1-master UDMA33 > GEOM: ad0s2: geometry does not match label (255h,63s != 16h,63s). > GEOM: ad0s3: geometry does not match label (255h,63s != 16h,63s). > GEOM_LABEL: Label for provider ad0s4 is msdosfs/NEC-RESTORE. > ushub3: 6 ports with 6 removable, self powered > ugen3.2: at usbus3 > ushub4: on usbus3 > ushub4: 4 ports with 4 removable, self powered > WARNING: WITNESS option enabled, expect reduced performance. > Trying to mount root from ufs:/dev/ad0s3a > > --- > WATANABE Kazuhiro (CQG00620@nifty.ne.jp) > _______________________________________________ > 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 rmgls at free.fr Mon Jan 12 01:28:33 2009 From: rmgls at free.fr (raoul) Date: Mon Jan 12 01:28:40 2009 Subject: ext3fs Message-ID: <20090112092824.6B6B8D4800D@smtp5-g21.free.fr> Hi all, it seems on Current buildword from 4 January 2009 that ext3fs is confusing mount: ext2fs works fine; so my question: is ext3fs supported? here is my results: mount -t ext2fs /dev/ad4s2 /mnt => ok ls /mnt => Bad file descriptor with a LOR: GEOM_LABEL: Label ext2fs/debian removed. lock order reversal: 1st 0xd8518110 bufwait (bufwait) @ kern/vfs_bio.c:2443 2nd 0xc4c31e00 dirhash (dirhash) @ ufs/ufs/ufs_dirhash.c:263 KDB: stack backtrace: db_trace_self_wrapper(c0b98baf,e6238898,c0831475,4,c0b941ba,...) at db_trace_self_wrapper+0x26 kdb_backtrace(4,c0b941ba,c4520878,c4523e18,e62388f4,...) at kdb_backtrace+0x29 _witness_debugger(c0b9b869,c4c31e00,c0bbaf87,c4523e18,c0bbac2d,...) at _witness_debugger+0x25 witness_checkorder(c4c31e00,9,c0bbac24,107,0,...) at witness_checkorder+0x839 _sx_xlock(c4c31e00,0,c0bbac24,107,d90c9894,...) at _sx_xlock+0x85 ufsdirhash_acquire(0,e,c4a49000,d85180b0,d90c9894,...) at ufsdirhash_acquire+0x35 ufsdirhash_remove(c4f6f960,d90c9894,894,e6238984,e6238980,...) at ufsdirhash_remove+0x14 ufs_dirremove(c4f6e10c,c4f9d618,500940c,0,0,...) at ufs_dirremove+0xe5 ufs_rename(e6238c1c,e6238c1c,e6238bcc,e6238b7c,e6238bcc,...) at ufs_rename+0xbe3 VOP_RENAME_APV(c0c975c0,e6238c1c,101,0,5009410,...) at VOP_RENAME_APV+0xa5 kern_renameat(c4fb6000,ffffff9c,85c9664,ffffff9c,85c9680,...) at kern_renameat+0x2b7 kern_rename(c4fb6000,85c9664,85c9680,0,e6238d2c,...) at kern_rename+0x36 rename(c4fb6000,e6238cf8,8,c0b9c07a,c0c73400,...) at rename+0x29 syscall(e6238d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (128, FreeBSD ELF32, rename), eip = 0x2824ed0b, esp = 0xbfbfd8bc, ebp = 0xbfbfd8e8 --- lock order reversal: 1st 0xc4f9f594 ufs (ufs) @ kern/vfs_mount.c:1190 2nd 0xc4caedf4 devfs (devfs) @ /usr/src/sys/modules/ext2fs/../../gnu/fs/ext2fs/ext2_vfsops.c:918 KDB: stack backtrace: db_trace_self_wrapper(c0b98baf,e61c3a4c,c0831475,4,c0b941ba,...) at db_trace_self_wrapper+0x26 kdb_backtrace(4,c0b941ba,c4523db0,c4523ce0,e61c3aa8,...) at kdb_backtrace+0x29 _witness_debugger(c0b9b869,c4caedf4,c0b8b90e,c4523ce0,c4faff0f,...) at _witness_debugger+0x25 witness_checkorder(c4caedf4,9,c4faff0f,396,c4caee10,...) at witness_checkorder+0x839 __lockmgr_args(c4caedf4,80400,c4caee10,0,0,...) at __lockmgr_args+0x797 vop_stdlock(e61c3bb0,c0e1cee8,c4a729a4,80400,c4caed9c,...) at vop_stdlock+0x62 VOP_LOCK1_APV(c0c6f400,e61c3bb0,e61c3bd0,c0cab6a0,c4caed9c,...) at VOP_LOCK1_APV+0xa5 _vn_lock(c4caed9c,80400,c4faff0f,396,c4d28840,...) at _vn_lock+0x5e ext2_sync(c4a96280,1,c4a72900,4eb,0,...) at ext2_sync+0x283 dounmount(c4a96280,8000000,c4a72900,471,9,...) at dounmount+0x45c unmount(c4a72900,e61c3cf8,8,e61c3d38,c0c72a10,...) at unmount+0x2e0 syscall(e61c3d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (22, FreeBSD ELF32, unmount), eip = 0x280d224f, esp = 0xbfbfe00c, ebp = 0xbfbfe0d8 --- GEOM_LABEL: Label for provider ad4s2 is ext2fs/debian. 1822]: speaker open error 2: No such file or directory. ssage repeated 3 times GEOM_LABEL: Label ext2fs/debian removed. GEOM_LABEL: Label for provider ad4s2 is ext2fs/debian. it is a journalized debian partition. to help here is the superblock report from tune2fs: tune2fs 1.41.3 (12-Oct-2008) Filesystem volume name: debian Last mounted on: Filesystem UUID: d9497b41-f521-4c61-981c-10ccb840ea59 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file Filesystem flags: signed_directory_hash Default mount options: (none) Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 2260992 Block count: 9032546 Reserved block count: 451627 Free blocks: 7479934 Free inodes: 2027863 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 1021 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8192 Inode blocks per group: 512 Filesystem created: Fri Dec 26 07:48:32 2008 Last mount time: Mon Jan 12 08:43:04 2009 Last write time: Mon Jan 12 08:43:04 2009 Mount count: 15 Maximum mount count: 20 Last checked: Sun Jan 4 13:31:26 2009 Check interval: 15552000 (6 months) Next check after: Fri Jul 3 14:31:26 2009 Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 28 Desired extra isize: 28 Journal inode: 8 First orphan inode: 2109261 Default directory hash: half_md4 Directory Hash Seed: dc0ffcbd-9242-46db-9c2b-77c0349cefa0 Journal backup: inode blocks best regards raoul rmgls@free.fr From ivoras at freebsd.org Mon Jan 12 01:32:30 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Mon Jan 12 01:32:37 2009 Subject: ext3fs In-Reply-To: <20090112092824.6B6B8D4800D@smtp5-g21.free.fr> References: <20090112092824.6B6B8D4800D@smtp5-g21.free.fr> Message-ID: raoul wrote: > Hi all, > > it seems on Current buildword from 4 January 2009 > that ext3fs is confusing mount: > ext2fs works fine; > > so my question: is ext3fs supported? It should be in ext2-compatibility mode. Your best bet is to send a debug description (generated by dumpfs) of the file system (from Linux). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090112/9fd9dfed/signature.pgp From pluknet at gmail.com Mon Jan 12 01:34:44 2009 From: pluknet at gmail.com (pluknet) Date: Mon Jan 12 01:34:51 2009 Subject: ext3fs In-Reply-To: <20090112092824.6B6B8D4800D@smtp5-g21.free.fr> References: <20090112092824.6B6B8D4800D@smtp5-g21.free.fr> Message-ID: 2009/1/12 raoul : > > Hi all, > > it seems on Current buildword from 4 January 2009 > that ext3fs is confusing mount: > ext2fs works fine; > > so my question: is ext3fs supported? > > here is my results: > > mount -t ext2fs /dev/ad4s2 /mnt => ok > ls /mnt => Bad file descriptor > with a LOR: > > GEOM_LABEL: Label ext2fs/debian removed. > > lock order reversal: > 1st 0xd8518110 bufwait (bufwait) @ kern/vfs_bio.c:2443 > 2nd 0xc4c31e00 dirhash (dirhash) @ ufs/ufs/ufs_dirhash.c:263 > KDB: stack backtrace: > db_trace_self_wrapper(c0b98baf,e6238898,c0831475,4,c0b941ba,...) at db_trace_self_wrapper+0x26 > kdb_backtrace(4,c0b941ba,c4520878,c4523e18,e62388f4,...) at kdb_backtrace+0x29 > _witness_debugger(c0b9b869,c4c31e00,c0bbaf87,c4523e18,c0bbac2d,...) at _witness_debugger+0x25 > witness_checkorder(c4c31e00,9,c0bbac24,107,0,...) at witness_checkorder+0x839 > _sx_xlock(c4c31e00,0,c0bbac24,107,d90c9894,...) at _sx_xlock+0x85 > ufsdirhash_acquire(0,e,c4a49000,d85180b0,d90c9894,...) at ufsdirhash_acquire+0x35 > ufsdirhash_remove(c4f6f960,d90c9894,894,e6238984,e6238980,...) at ufsdirhash_remove+0x14 > ufs_dirremove(c4f6e10c,c4f9d618,500940c,0,0,...) at ufs_dirremove+0xe5 > ufs_rename(e6238c1c,e6238c1c,e6238bcc,e6238b7c,e6238bcc,...) at ufs_rename+0xbe3 > VOP_RENAME_APV(c0c975c0,e6238c1c,101,0,5009410,...) at VOP_RENAME_APV+0xa5 > kern_renameat(c4fb6000,ffffff9c,85c9664,ffffff9c,85c9680,...) at kern_renameat+0x2b7 > kern_rename(c4fb6000,85c9664,85c9680,0,e6238d2c,...) at kern_rename+0x36 > rename(c4fb6000,e6238cf8,8,c0b9c07a,c0c73400,...) at rename+0x29 > syscall(e6238d38) at syscall+0x2a3 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (128, FreeBSD ELF32, rename), eip = 0x2824ed0b, esp = 0xbfbfd8bc, ebp = 0xbfbfd8e8 --- > lock order reversal: > 1st 0xc4f9f594 ufs (ufs) @ kern/vfs_mount.c:1190 > 2nd 0xc4caedf4 devfs (devfs) @ /usr/src/sys/modules/ext2fs/../../gnu/fs/ext2fs/ext2_vfsops.c:918 > KDB: stack backtrace: > db_trace_self_wrapper(c0b98baf,e61c3a4c,c0831475,4,c0b941ba,...) at db_trace_self_wrapper+0x26 > kdb_backtrace(4,c0b941ba,c4523db0,c4523ce0,e61c3aa8,...) at kdb_backtrace+0x29 > _witness_debugger(c0b9b869,c4caedf4,c0b8b90e,c4523ce0,c4faff0f,...) at _witness_debugger+0x25 > witness_checkorder(c4caedf4,9,c4faff0f,396,c4caee10,...) at witness_checkorder+0x839 > __lockmgr_args(c4caedf4,80400,c4caee10,0,0,...) at __lockmgr_args+0x797 > vop_stdlock(e61c3bb0,c0e1cee8,c4a729a4,80400,c4caed9c,...) at vop_stdlock+0x62 > VOP_LOCK1_APV(c0c6f400,e61c3bb0,e61c3bd0,c0cab6a0,c4caed9c,...) at VOP_LOCK1_APV+0xa5 > _vn_lock(c4caed9c,80400,c4faff0f,396,c4d28840,...) at _vn_lock+0x5e > ext2_sync(c4a96280,1,c4a72900,4eb,0,...) at ext2_sync+0x283 > dounmount(c4a96280,8000000,c4a72900,471,9,...) at dounmount+0x45c > unmount(c4a72900,e61c3cf8,8,e61c3d38,c0c72a10,...) at unmount+0x2e0 > syscall(e61c3d38) at syscall+0x2a3 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (22, FreeBSD ELF32, unmount), eip = 0x280d224f, esp = 0xbfbfe00c, ebp = 0xbfbfe0d8 --- > GEOM_LABEL: Label for provider ad4s2 is ext2fs/debian. > 1822]: speaker open error 2: No such file or directory. > ssage repeated 3 times > GEOM_LABEL: Label ext2fs/debian removed. > GEOM_LABEL: Label for provider ad4s2 is ext2fs/debian. > > > > it is a journalized debian partition. > > to help here is the superblock report from tune2fs: > > tune2fs 1.41.3 (12-Oct-2008) > Filesystem volume name: debian > Last mounted on: > Filesystem UUID: d9497b41-f521-4c61-981c-10ccb840ea59 > Filesystem magic number: 0xEF53 > Filesystem revision #: 1 (dynamic) > Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file > Filesystem flags: signed_directory_hash > Default mount options: (none) > Filesystem state: clean > Errors behavior: Continue > Filesystem OS type: Linux > Inode count: 2260992 > Block count: 9032546 > Reserved block count: 451627 > Free blocks: 7479934 > Free inodes: 2027863 > First block: 0 > Block size: 4096 > Fragment size: 4096 > Reserved GDT blocks: 1021 > Blocks per group: 32768 > Fragments per group: 32768 > Inodes per group: 8192 > Inode blocks per group: 512 > Filesystem created: Fri Dec 26 07:48:32 2008 > Last mount time: Mon Jan 12 08:43:04 2009 > Last write time: Mon Jan 12 08:43:04 2009 > Mount count: 15 > Maximum mount count: 20 > Last checked: Sun Jan 4 13:31:26 2009 > Check interval: 15552000 (6 months) > Next check after: Fri Jul 3 14:31:26 2009 > Reserved blocks uid: 0 (user root) > Reserved blocks gid: 0 (group root) > First inode: 11 > Inode size: 256 ^^^ This prevents ext2/3 from mount. See "256-byte inode support" thread on hackers@ > Required extra isize: 28 > Desired extra isize: 28 > Journal inode: 8 > First orphan inode: 2109261 > Default directory hash: half_md4 > Directory Hash Seed: dc0ffcbd-9242-46db-9c2b-77c0349cefa0 > Journal backup: inode blocks > -- wbr, pluknet From sem at FreeBSD.org Mon Jan 12 01:41:30 2009 From: sem at FreeBSD.org (Sergey Matveychuk) Date: Mon Jan 12 01:41:38 2009 Subject: quagga-0.99.11_1 is marked as broken: does not build. In-Reply-To: <20090111175359.GA4231@soaustin.net> References: <49695A15.8010801@psg.com> <496A254F.2020500@FreeBSD.org> <20090111175359.GA4231@soaustin.net> Message-ID: <496B1031.6000200@FreeBSD.org> Mark Linimon wrote: > On Sun, Jan 11, 2009 at 07:58:55PM +0300, Sergey Matveychuk wrote: >> The fix is already in the port: >> http://www.freebsd.org/cgi/cvsweb.cgi/ports/net/quagga/files/patch-zebra-kernel_socket.c?rev=1.5 >> >> I have no idea why Erwin has marked it as BROKEN again. > > There was no portrevision bump when the patch went in, so pointyhat > did not rebuild the package. He apparently marked it as BROKEN due to > the results of the previous run. > We did not bump PORTREVISION before if just fixed build on CURRENT. When PORTREVISION bumped, all users will noticed for updates but they are not affected really. -- Dixi. Sem. From sem at FreeBSD.org Mon Jan 12 01:42:24 2009 From: sem at FreeBSD.org (Sergey Matveychuk) Date: Mon Jan 12 01:42:30 2009 Subject: quagga-0.99.11_1 is marked as broken: does not build. In-Reply-To: <20090111203706.GA39600@droso.net> References: <49695A15.8010801@psg.com> <496A254F.2020500@FreeBSD.org> <20090111175359.GA4231@soaustin.net> <20090111203706.GA39600@droso.net> Message-ID: <496B107E.2020302@FreeBSD.org> Erwin Lansing wrote: > On Sun, Jan 11, 2009 at 11:53:59AM -0600, Mark Linimon wrote: >> On Sun, Jan 11, 2009 at 07:58:55PM +0300, Sergey Matveychuk wrote: >>> The fix is already in the port: >>> http://www.freebsd.org/cgi/cvsweb.cgi/ports/net/quagga/files/patch-zebra-kernel_socket.c?rev=1.5 >>> >>> I have no idea why Erwin has marked it as BROKEN again. >> There was no portrevision bump when the patch went in, so pointyhat >> did not rebuild the package. He apparently marked it as BROKEN due to >> the results of the previous run. >> > Indeed. I also check cvs history for the ports Makefile, so I didn't > notice the patch that was added. I removed the BROKEN tag. Thanks, Erwin. -- Dixi. Sem. From bra at fsn.hu Mon Jan 12 01:46:10 2009 From: bra at fsn.hu (Attila Nagy) Date: Mon Jan 12 01:46:18 2009 Subject: FreeBSD panics with 64GiB of RAM Message-ID: <496B115F.1000105@fsn.hu> Hello, FreeBSD-CURRENT/amd64 panics at initialization with this: http://people.fsn.hu/~bra/freebsd/20090107-freebsd-x4540/Screenshot-55.png on a Sun X4550, equipped with two Opteron CPUs and 64 GiB of RAM. The machine will be here for this week, so if somebody can or want to look into this issue, I can test patches. From vince at unsane.co.uk Mon Jan 12 01:59:20 2009 From: vince at unsane.co.uk (Vincent Hoffman) Date: Mon Jan 12 01:59:26 2009 Subject: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) In-Reply-To: References: <61484.71762.qm@web32708.mail.mud.yahoo.com> <20090111044448.GC5661@server.vk2pj.dyndns.org> <342292.89033.qm@web32703.mail.mud.yahoo.com> <496A98B3.1010301@freebsd.org> Message-ID: <496B1471.1080900@unsane.co.uk> Peter Ross wrote: > Hi Tim, > > AFAIK you _need_ a C compiler to keep your system secure, to apply > security patches. > > E.g. http://security.freebsd.org/advisories/FreeBSD-SA-09:02.openssl.asc > > .. > make obj && make depend && make && make install > Or more recently, freebsd-update fetch && freebsd-update install its really not needed if you are just following -RELEASE except of course for ports. Vince > .. > > Of course there are build-boxes etc. so you only need a compiler once. But > still, you need a box to compile it. > > Regards > Peter > > On Sun, 11 Jan 2009, Tim Kientzle wrote: > > From rmgls at free.fr Mon Jan 12 02:15:02 2009 From: rmgls at free.fr (raoul) Date: Mon Jan 12 02:15:09 2009 Subject: ext3fs Message-ID: <20090112101450.DCA4A4C805F@smtp4-g21.free.fr> On Mon, 12 Jan 2009 12:34:42 +0300 pluknet wrote: > 2009/1/12 raoul : > > > > Hi all, > > > > it seems on Current buildword from 4 January 2009 > > that ext3fs is confusing mount: > > ext2fs works fine; > > > > so my question: is ext3fs supported? > > > > here is my results: > > > > mount -t ext2fs /dev/ad4s2 /mnt => ok > > ls /mnt => Bad file descriptor > > with a LOR: > > > > GEOM_LABEL: Label ext2fs/debian removed. > > > > lock order reversal: > > 1st 0xd8518110 bufwait (bufwait) @ kern/vfs_bio.c:2443 > > 2nd 0xc4c31e00 dirhash (dirhash) @ ufs/ufs/ufs_dirhash.c:263 > > KDB: stack backtrace: > > db_trace_self_wrapper(c0b98baf,e6238898,c0831475,4,c0b941ba,...) at db_trace_self_wrapper+0x26 > > kdb_backtrace(4,c0b941ba,c4520878,c4523e18,e62388f4,...) at kdb_backtrace+0x29 > > _witness_debugger(c0b9b869,c4c31e00,c0bbaf87,c4523e18,c0bbac2d,...) at _witness_debugger+0x25 > > witness_checkorder(c4c31e00,9,c0bbac24,107,0,...) at witness_checkorder+0x839 > > _sx_xlock(c4c31e00,0,c0bbac24,107,d90c9894,...) at _sx_xlock+0x85 > > ufsdirhash_acquire(0,e,c4a49000,d85180b0,d90c9894,...) at ufsdirhash_acquire+0x35 > > ufsdirhash_remove(c4f6f960,d90c9894,894,e6238984,e6238980,...) at ufsdirhash_remove+0x14 > > ufs_dirremove(c4f6e10c,c4f9d618,500940c,0,0,...) at ufs_dirremove+0xe5 > > ufs_rename(e6238c1c,e6238c1c,e6238bcc,e6238b7c,e6238bcc,...) at ufs_rename+0xbe3 > > VOP_RENAME_APV(c0c975c0,e6238c1c,101,0,5009410,...) at VOP_RENAME_APV+0xa5 > > kern_renameat(c4fb6000,ffffff9c,85c9664,ffffff9c,85c9680,...) at kern_renameat+0x2b7 > > kern_rename(c4fb6000,85c9664,85c9680,0,e6238d2c,...) at kern_rename+0x36 > > rename(c4fb6000,e6238cf8,8,c0b9c07a,c0c73400,...) at rename+0x29 > > syscall(e6238d38) at syscall+0x2a3 > > Xint0x80_syscall() at Xint0x80_syscall+0x20 > > --- syscall (128, FreeBSD ELF32, rename), eip = 0x2824ed0b, esp = 0xbfbfd8bc, ebp = 0xbfbfd8e8 --- > > lock order reversal: > > 1st 0xc4f9f594 ufs (ufs) @ kern/vfs_mount.c:1190 > > 2nd 0xc4caedf4 devfs (devfs) @ /usr/src/sys/modules/ext2fs/../../gnu/fs/ext2fs/ext2_vfsops.c:918 > > KDB: stack backtrace: > > db_trace_self_wrapper(c0b98baf,e61c3a4c,c0831475,4,c0b941ba,...) at db_trace_self_wrapper+0x26 > > kdb_backtrace(4,c0b941ba,c4523db0,c4523ce0,e61c3aa8,...) at kdb_backtrace+0x29 > > _witness_debugger(c0b9b869,c4caedf4,c0b8b90e,c4523ce0,c4faff0f,...) at _witness_debugger+0x25 > > witness_checkorder(c4caedf4,9,c4faff0f,396,c4caee10,...) at witness_checkorder+0x839 > > __lockmgr_args(c4caedf4,80400,c4caee10,0,0,...) at __lockmgr_args+0x797 > > vop_stdlock(e61c3bb0,c0e1cee8,c4a729a4,80400,c4caed9c,...) at vop_stdlock+0x62 > > VOP_LOCK1_APV(c0c6f400,e61c3bb0,e61c3bd0,c0cab6a0,c4caed9c,...) at VOP_LOCK1_APV+0xa5 > > _vn_lock(c4caed9c,80400,c4faff0f,396,c4d28840,...) at _vn_lock+0x5e > > ext2_sync(c4a96280,1,c4a72900,4eb,0,...) at ext2_sync+0x283 > > dounmount(c4a96280,8000000,c4a72900,471,9,...) at dounmount+0x45c > > unmount(c4a72900,e61c3cf8,8,e61c3d38,c0c72a10,...) at unmount+0x2e0 > > syscall(e61c3d38) at syscall+0x2a3 > > Xint0x80_syscall() at Xint0x80_syscall+0x20 > > --- syscall (22, FreeBSD ELF32, unmount), eip = 0x280d224f, esp = 0xbfbfe00c, ebp = 0xbfbfe0d8 --- > > GEOM_LABEL: Label for provider ad4s2 is ext2fs/debian. > > 1822]: speaker open error 2: No such file or directory. > > ssage repeated 3 times > > GEOM_LABEL: Label ext2fs/debian removed. > > GEOM_LABEL: Label for provider ad4s2 is ext2fs/debian. > > > > > > > > it is a journalized debian partition. > > > > to help here is the superblock report from tune2fs: > > > > tune2fs 1.41.3 (12-Oct-2008) > > Filesystem volume name: debian > > Last mounted on: > > Filesystem UUID: d9497b41-f521-4c61-981c-10ccb840ea59 > > Filesystem magic number: 0xEF53 > > Filesystem revision #: 1 (dynamic) > > Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file > > Filesystem flags: signed_directory_hash > > Default mount options: (none) > > Filesystem state: clean > > Errors behavior: Continue > > Filesystem OS type: Linux > > Inode count: 2260992 > > Block count: 9032546 > > Reserved block count: 451627 > > Free blocks: 7479934 > > Free inodes: 2027863 > > First block: 0 > > Block size: 4096 > > Fragment size: 4096 > > Reserved GDT blocks: 1021 > > Blocks per group: 32768 > > Fragments per group: 32768 > > Inodes per group: 8192 > > Inode blocks per group: 512 > > Filesystem created: Fri Dec 26 07:48:32 2008 > > Last mount time: Mon Jan 12 08:43:04 2009 > > Last write time: Mon Jan 12 08:43:04 2009 > > Mount count: 15 > > Maximum mount count: 20 > > Last checked: Sun Jan 4 13:31:26 2009 > > Check interval: 15552000 (6 months) > > Next check after: Fri Jul 3 14:31:26 2009 > > Reserved blocks uid: 0 (user root) > > Reserved blocks gid: 0 (group root) > > First inode: 11 > > Inode size: 256 > ^^^ > This prevents ext2/3 from mount. > See "256-byte inode support" thread on hackers@ Thanks for the hint i will look at this. Best regards raoul rmgls@free.fr From rwatson at FreeBSD.org Mon Jan 12 02:42:03 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Mon Jan 12 02:42:10 2009 Subject: GEOM and moving to CURRENT from 7.1 In-Reply-To: References: Message-ID: On Sun, 11 Jan 2009, George Neville-Neil wrote: > Beware if you are upgrading from a 7.1 system to CURRENT that you may need > to have the kernel options GEOM_MBR and GEOM_BSD in your kernel. I spent a > couple of hours dealing with this on my Thinkpad X60 today which had, what I > thought, was a pretty simple setup of 1 slice for BSD, and a simple layout > of /, swap and /usr. When I tried to boot the new kernel I got to the mount > error prompt and could not mount ad4p1 or anything like it. Adding the > GEOM_MBR and GEOM_BSD options back into the kernel fixed things. Happily I > was able to boot 7.1 still and fix this. Just to follow up on George's post -- he and I spent a bit of time last night trying to reconcile the fact that he and a few other people found themselves without bootable kernels, while many people don't. For example, my VMWare VMs all seem to boot without a problem, perhaps due to having particularly boring and vanilla fdisk/bsd labeling. Certainly, it seems that the message in the short term when upgrading to an 8.x kernel, or sliding forward, is that some caution is required, so make sure you have a backup kernel in case things don't work out. (This is always true in -CURRENT, of course...) Robert N M Watson Computer Laboratory University of Cambridge From CQG00620 at nifty.ne.jp Mon Jan 12 03:56:39 2009 From: CQG00620 at nifty.ne.jp (WATANABE Kazuhiro) Date: Mon Jan 12 03:56:48 2009 Subject: usb2: kernel panic with an USB floppy drive In-Reply-To: <200901120937.28951.hselasky@c2i.net> References: <20090112081541.0BC3964AC8@mail.asahi-net.or.jp> <200901120937.28951.hselasky@c2i.net> Message-ID: <20090112115636.ABE345D337@mail.asahi-net.or.jp> Hi. This problem seems to be fixed by the patch you suggested, and the floppy drive comes to work again. ***** ugen0.2: at usbus0 umass0: on usbus0 umass0: UFI over CBI with CCI; quirks = 0x0042 umass0:1:0:-1: Attached to scbus1 (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition (probe0:umass-sim0:0:0:0): NOT READY asc:3a,0 (probe0:umass-sim0:0:0:0): Medium not present (probe0:umass-sim0:0:0:0): Unretryable error da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 20KB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present ***** Thanks! At Mon, 12 Jan 2009 09:37:27 +0100, Hans Petter Selasky wrote: > Hi, > > Thanks for reporting. > > This bug looks like a glitch on my side when introducing Zero-copy in UMASS. > > Try the following patch: > > http://perforce.freebsd.org/chv.cgi?CH=156005 > > --HPS > > On Monday 12 January 2009, WATANABE Kazuhiro wrote: > > Hi, all. > > > > I have an USB floppy drive which works well on 7.1-RELEASE, and > > 8-current with the old USB stack. > > > > ***** > > umass0: on > > uhub0 da0 at umass-sim0 bus 0 target 0 lun 0 > > da0: Removable Direct Access SCSI-0 device > > da0: 20KB/s transfers > > da0: Attempt to query device size failed: NOT READY, Medium not present > > > > port 1 addr 2: full speed, power 500 mA, config 1, USB Floppy > > Drive(0x0000), Y-E DATA(0x057b), rev 5.01 ***** > > > > When I connect the floppy drive to the system with the new USB2 stack, > > it causes a kernel panic. > > > > > > Here is a stack trace and dmesg output. > > > > capricorn# kgdb /boot/kernel/kernel.symbols /var/crash/vmcore.0 > > 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 "i386-marcel-freebsd"... > > > > Unread portion of the kernel message buffer: > > umass0:1:0:-1: Attached to scbus1 > > Kernel page fault with the following non-sleepable locks held: > > exclusive sleep mutex UMASS lock (UMASS lock) r = 0 (0xc0d69800) locked @ > > /FreeBSD/HEAD/src/sys/dev/usb2/core/usb2_transfer.c:1781 KDB: stack > > backtrace: > > db_trace_self_wrapper(c0c1f7c2,cc93ea28,c088f145,c0c0d089,6f5,...) at > > db_trace_self_wrapper+0x26 > > kdb_backtrace(c0c0d089,6f5,ffffffff,c0eabdc4,cc93ea60,...) at > > kdb_backtrace+0x29 _witness_debugger(c0c21ae3,cc93ea74,4,1,0,...) at > > _witness_debugger+0x25 witness_warn(5,0,c0c53da2,c28d3b40,c288ea90,...) at > > witness_warn+0x1fd trap(cc93eb00) at trap+0x152 > > calltrap() at calltrap+0x6 > > --- trap 0xc, eip = 0xc0b32da5, esp = 0xcc93eb40, ebp = 0xcc93eb78 --- > > bus_dmamap_load(c29a4e80,c0ef2bc0,0,24,c077e8b0,...) at > > bus_dmamap_load+0xd5 usb2_pc_load_mem(c2b87f80,24,0,4cf,c0c02651,...) at > > usb2_pc_load_mem+0x125 > > usb2_bdma_work_loop(c2b86000,c2b86400,10000ca,c2b4a900,1,...) at > > usb2_bdma_work_loop+0x2b5 > > usb2_command_wrapper(c2b86000,c2b86400,c0c0d089,55b,c28d3be4,...) at > > usb2_command_wrapper+0x116 > > usb2_start_hardware(c2b86400,c084127c,c2690b68,4,c0c1ac2a,...) at > > usb2_start_hardware+0x6eb > > umass_t_cbi_data_read_callback(c2b86400,0,c0c0d089,752,c0eabdc0,...) at > > umass_t_cbi_data_read_callback+0xfe > > usb2_callback_wrapper(c2b86014,6f6,0,c2b86000,c2b86000,...) at > > usb2_callback_wrapper+0x63a > > usb2_command_wrapper(c2b86014,0,c0c0d089,6f6,c2b86028,...) at > > usb2_command_wrapper+0x116 > > usb2_callback_proc(c2b86028,c2690b68,c0c0cc24,51,c0d704c0,...) at > > usb2_callback_proc+0x9b > > usb2_process(c2b86078,cc93ed38,c0c18395,32d,c288ea90,...) at > > usb2_process+0xde fork_exit(c07906b0,c2b86078,cc93ed38) at fork_exit+0xb8 > > fork_trampoline() at fork_trampoline+0x8 > > --- trap 0, eip = 0, esp = 0xcc93ed70, ebp = 0 --- > > > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 0; apic id = 00 > > fault virtual address = 0xbfc00000 > > fault code = supervisor read, page not present > > instruction pointer = 0x20:0xc0b32da5 > > stack pointer = 0x28:0xcc93eb40 > > frame pointer = 0x28:0xcc93eb78 > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, def32 1, gran 1 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 1338 (USBPROC) > > lock order reversal: (Giant after non-sleepable) > > 1st 0xc0d69800 UMASS lock (UMASS lock) @ > > /FreeBSD/HEAD/src/sys/dev/usb2/core/usb2_transfer.c:1781 2nd 0xc0d6bfb0 > > Giant (Giant) @ /FreeBSD/HEAD/src/sys/dev/kbdmux/kbdmux.c:1044 KDB: stack > > backtrace: > > panic: from debugger > > cpuid = 0 > > Uptime: 2m8s > > Physical memory: 223 MB > > Dumping 40 MB: 25 9 > > > > Reading symbols from /boot/kernel/green_saver.ko...Reading symbols from > > /boot/kernel/green_saver.ko.symbols...done. done. > > Loaded symbols for /boot/kernel/green_saver.ko > > #0 doadump () at pcpu.h:246 > > 246 pcpu.h: No such file or directory. > > in pcpu.h > > (kgdb) where > > #0 doadump () at pcpu.h:246 > > #1 0xc084fe5e in boot (howto=260) > > at /FreeBSD/HEAD/src/sys/kern/kern_shutdown.c:420 > > #2 0xc0850132 in panic (fmt=Variable "fmt" is not available. > > ) > > at /FreeBSD/HEAD/src/sys/kern/kern_shutdown.c:576 > > #3 0xc04bdc27 in db_panic (addr=Could not find the frame base for > > "db_panic". ) > > at /FreeBSD/HEAD/src/sys/ddb/db_command.c:478 > > #4 0xc04be251 in db_command (last_cmdp=0xc0d3a55c, cmd_table=0x0, > > dopager=1) at /FreeBSD/HEAD/src/sys/ddb/db_command.c:445 > > #5 0xc04be3aa in db_command_loop () > > at /FreeBSD/HEAD/src/sys/ddb/db_command.c:498 > > #6 0xc04c020d in db_trap (type=12, code=0) > > at /FreeBSD/HEAD/src/sys/ddb/db_main.c:229 > > #7 0xc087d7f6 in kdb_trap (type=12, code=0, tf=0xcc93eb00) > > at /FreeBSD/HEAD/src/sys/kern/subr_kdb.c:534 > > #8 0xc0b50e0f in trap_fatal (frame=0xcc93eb00, eva=3217031168) > > at /FreeBSD/HEAD/src/sys/i386/i386/trap.c:920 > > #9 0xc0b51740 in trap (frame=0xcc93eb00) > > at /FreeBSD/HEAD/src/sys/i386/i386/trap.c:318 > > #10 0xc0b35b6b in calltrap () > > at /FreeBSD/HEAD/src/sys/i386/i386/exception.s:165 > > #11 0xc0b32da5 in bus_dmamap_load (dmat=0xc29a4e80, map=0xc0ef2bc0, > > buf=0x0, buflen=36, callback=0xc077e8b0 , > > callback_arg=0xc2b87f80, flags=0) at pmap.h:282 > > ---Type to continue, or q to quit--- > > #12 0xc077e415 in usb2_pc_load_mem (pc=0xc2b87f80, size=36, sync=0 '\0') > > at /FreeBSD/HEAD/src/sys/dev/usb2/core/usb2_busdma.c:635 > > #13 0xc077e705 in usb2_bdma_work_loop (pq=0xc2b86000) > > at /FreeBSD/HEAD/src/sys/dev/usb2/core/usb2_busdma.c:1318 > > #14 0xc0793076 in usb2_command_wrapper (pq=0xc2b86000, xfer=0xc2b86400) > > at /FreeBSD/HEAD/src/sys/dev/usb2/core/usb2_transfer.c:2484 > > #15 0xc079434b in usb2_start_hardware (xfer=0xc2b86400) > > at /FreeBSD/HEAD/src/sys/dev/usb2/core/usb2_transfer.c:1491 > > #16 0xc077c19e in umass_t_cbi_data_read_callback (xfer=0xc2b86400) > > at /FreeBSD/HEAD/src/sys/dev/usb2/storage/umass2.c:2414 > > #17 0xc07956da in usb2_callback_wrapper (pq=0xc2b86014) > > at /FreeBSD/HEAD/src/sys/dev/usb2/core/usb2_transfer.c:1911 > > #18 0xc0793076 in usb2_command_wrapper (pq=0xc2b86014, xfer=0x0) > > at /FreeBSD/HEAD/src/sys/dev/usb2/core/usb2_transfer.c:2484 > > #19 0xc079315b in usb2_callback_proc (_pm=0xc2b86028) > > at /FreeBSD/HEAD/src/sys/dev/usb2/core/usb2_transfer.c:1785 > > #20 0xc079078e in usb2_process (arg=0xc2b86078) > > at /FreeBSD/HEAD/src/sys/dev/usb2/core/usb2_process.c:139 > > #21 0xc082ce48 in fork_exit (callout=0xc07906b0 , > > arg=0xc2b86078, frame=0xcc93ed38) > > at /FreeBSD/HEAD/src/sys/kern/kern_fork.c:821 > > #22 0xc0b35be0 in fork_trampoline () > > at /FreeBSD/HEAD/src/sys/i386/i386/exception.s:270 > > (kgdb) quit > > capricorn# --- WATANABE Kazuhiro (CQG00620@nifty.ne.jp) From talon at lpthe.jussieu.fr Mon Jan 12 01:44:34 2009 From: talon at lpthe.jussieu.fr (Michel Talon) Date: Mon Jan 12 04:26:46 2009 Subject: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) Message-ID: <20090112094429.GA87628@lpthe.jussieu.fr> Garrett Cooper wrote: > On Sun, Jan 11, 2009 at 4:31 PM, Eitan Adler > wrote: > > I never took care about GPLv2 and v3 > >> differences but know, this seems to come to relevance in some way. > > > > I don't seem to understand this. Why should gpl v3 affect the OS? > > The > > output of the compiler isn't affected by the license. Is it? > > Yes the GPLv3 is `extremely viral' when dealing with proprietary > innovations and features, compared to GPLv2. This is complete rubbish, the V3 is viral in exactly the same way as the V2, the V3 simply closes a hole allowing people to do things which were obviously against the spirit of the V2, but were able to go through a hole in the letter of the V2. The spirit of the GPL has always been: "if you derive software from GPL software, and you distribute it, then it must be distributed under the GPL, and you must provide source code. The end users can modify the code, distribute their work, and run the modified version as they see fit". The Tivo loophole was that the hardaware runs only signed binaries, hence you cannot run your modified version. This is completely obviously in contradiction with the spirit of the GPL, if allowed by the letter. Now the large incertitude in this game is to know what is exactly a derived software from another one. This is an extremely vague concept. > Many companies also have to write in functionality and tie-ins which > expose portions of the OS, debugging tools, libraries, etc that would > require them to expose their proprietary secrets. They should be just > as exposed with GPLv2, but the GPLv3 is more stringent and the FSF is > ramping up copyright infringement notices Precisely they were just as exposed with the GPL V2, but were deliberately ignoring their obligations. the fact that the FSF ramps up its legal action is the new factor of importance. These legal actions also serve to define and precise the concept of derivation, and perhaps commercial companies begin to understand that they are vulnerable. Anyways the fact that the compiler is GPL V2 or GPL V3 is totally insignificant with respect to FreeBSD, since it is an established fact that the result of the compilation is not derived from the compiler, hence is not subject to the virality of the licence. I think this is not so clear for C++ code, because the compiler then includes some stuff of its own in the result, but there is perhaps a special exemption for that. The last thing FreeBSD needs is losing time and performance to solve a problem which doesn't exist in the first place, when there are so many actual and concrete problems which are not fixed. -- Michel TALON From alexanderchuranov at gmail.com Mon Jan 12 05:01:34 2009 From: alexanderchuranov at gmail.com (Alexander Churanov) Date: Mon Jan 12 05:01:41 2009 Subject: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) In-Reply-To: <20090112094429.GA87628@lpthe.jussieu.fr> References: <20090112094429.GA87628@lpthe.jussieu.fr> Message-ID: <3cb459ed0901120501s1bfde6fax7ae0164a37468adb@mail.gmail.com> 2009/1/12 Michel Talon > The last thing FreeBSD needs is losing time and performance to > solve a problem which doesn't exist in the first place, when there are > so many actual and concrete problems which are not fixed. > > -- > > Michel TALON > > Do you contribute to FreeBSD? I have some work on "concrete problems" to share :-) Sincerely, Alexander Churanov From stephen at math.missouri.edu Mon Jan 12 05:34:16 2009 From: stephen at math.missouri.edu (Stephen Montgomery-Smith) Date: Mon Jan 12 05:34:23 2009 Subject: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) In-Reply-To: <20090112094429.GA87628@lpthe.jussieu.fr> References: <20090112094429.GA87628@lpthe.jussieu.fr> Message-ID: <496B46D6.6060403@math.missouri.edu> Michel Talon wrote: > Garrett Cooper wrote: > >> On Sun, Jan 11, 2009 at 4:31 PM, Eitan Adler >> wrote: >>> I never took care about GPLv2 and v3 >>>> differences but know, this seems to come to relevance in some way. >>> I don't seem to understand this. Why should gpl v3 affect the OS? >>> The >>> output of the compiler isn't affected by the license. Is it? >> Yes the GPLv3 is `extremely viral' when dealing with proprietary >> innovations and features, compared to GPLv2. > > This is complete rubbish, the V3 is viral in exactly the same way as the > V2, the V3 simply closes a hole allowing people to do things which were > obviously against the spirit of the V2, but were able to go through a > hole in the letter of the V2. The spirit of the GPL has always been: "if > you derive software from GPL software, and you distribute it, then it > must be distributed under the GPL, and you must provide source code. > The end users can modify the code, distribute their work, and run the > modified version as they see fit". The Tivo loophole was that the > hardaware runs only signed binaries, hence you cannot run your modified > version. This is completely obviously in contradiction with the spirit > of the GPL, if allowed by the letter. Now the large incertitude in this > game is to know what is exactly a derived software from another one. > This is an extremely vague concept. > >> Many companies also have to write in functionality and tie-ins which >> expose portions of the OS, debugging tools, libraries, etc that would >> require them to expose their proprietary secrets. They should be just >> as exposed with GPLv2, but the GPLv3 is more stringent and the FSF is >> ramping up copyright infringement notices > > Precisely they were just as exposed with the GPL V2, but were > deliberately ignoring their obligations. the fact that the FSF ramps up > its legal action is the new factor of importance. These legal actions > also serve to define and precise the concept of derivation, and perhaps > commercial companies begin to understand that they are vulnerable. > > Anyways the fact that the compiler is GPL V2 or GPL V3 is totally > insignificant with respect to FreeBSD, since it is an established fact > that the result of the compilation is not derived from the compiler, > hence is not subject to the virality of the licence. I think this > is not so clear for C++ code, because the compiler then includes some > stuff of its own in the result, but there is perhaps a special exemption > for that. The last thing FreeBSD needs is losing time and performance to > solve a problem which doesn't exist in the first place, when there are > so many actual and concrete problems which are not fixed. I am not a lawyer. But I was reading the GPLv3 license. And I was coming to exactly the same conclusions as Michel. Also, reading the prior postings where Linux kernel developers were complaining about GPLv3. But their complaints were against draft versions, and as far as I can see, their complaints were adequately handled in the final version. As for Michel's point that the results of the compilation are not covered by GPL - this seems to be stated explicitly in the GPLv3 license. Stephen From obrien at freebsd.org Mon Jan 12 08:26:06 2009 From: obrien at freebsd.org (David O'Brien) Date: Mon Jan 12 08:26:12 2009 Subject: gcc 4.3: when will it become standard compiler? In-Reply-To: <4967259C.9090408@stillbilde.net> References: <49668763.8020705@mail.zedat.fu-berlin.de> <49671748.3030709@gmx.de> <4967259C.9090408@stillbilde.net> Message-ID: <20090112162604.GA77988@dragon.NUXI.org> On Fri, Jan 09, 2009 at 11:23:24AM +0100, Svein Skogen (List Mail Account) wrote: > Christoph Mallon wrote: > > O. Hartmann schrieb: > >> When will gcc 4.3 incorporated in FreeBSD 8 and become the standard > >> compiler suite? We figured out that gcc 4.3 does have a speed gain in > >> some numerical code of 3 - 8 % and I guess we can use this in the basic > >> OS as well ... > > > > Number crunching has a totally different execution profile than basic > > operating system services. Gains in one area cannot simply be > > transferred to the other. > > Would it be possible, as a "workaround" to have "system-CC" and > "ports-CC" defined in make.conf, making one CC the compiler for /usr/src > and another for ports, or would this just create debugging nightmares? Why do you think you don't have this today? Install /usr/ports/lang/gcc/gcc43. It lives nicely beside the base compiler. Anytime you want to use it - set 'CC' to 'gcc43'. I guess you're asking for some auto choosing of which compiler to use? -- -- David (obrien@FreeBSD.org) From obrien at freebsd.org Mon Jan 12 08:31:42 2009 From: obrien at freebsd.org (David O'Brien) Date: Mon Jan 12 08:31:53 2009 Subject: fix tools/tools/usb/print-usb-if-vids.sh In-Reply-To: References: Message-ID: <20090112163134.GB77988@dragon.NUXI.org> On Fri, Jan 09, 2009 at 01:00:17AM +0100, Alexander Best wrote: > here's a fix to make tools/tools/usb/print-usb-if-vids.sh work again. the file > hasn't been touched in over 4 years. ;) committed - thanks! From ken at mthelicon.com Mon Jan 12 08:48:16 2009 From: ken at mthelicon.com (Pegasus Mc Cleaft) Date: Mon Jan 12 08:48:22 2009 Subject: gcc 4.3: when will it become standard compiler? In-Reply-To: <20090112162604.GA77988@dragon.NUXI.org> References: <49668763.8020705@mail.zedat.fu-berlin.de><49671748.3030709@gmx.de> <4967259C.9090408@stillbilde.net> <20090112162604.GA77988@dragon.NUXI.org> Message-ID: <290AA3DA54624A6FA91872B8909564F2@PegaPegII> ----- Original Message ----- From: "David O'Brien" To: "Svein Skogen (List Mail Account)" Cc: Sent: Monday, January 12, 2009 4:26 PM Subject: Re: gcc 4.3: when will it become standard compiler? > On Fri, Jan 09, 2009 at 11:23:24AM +0100, Svein Skogen (List Mail Account) > wrote: >> Christoph Mallon wrote: >> > O. Hartmann schrieb: >> >> When will gcc 4.3 incorporated in FreeBSD 8 and become the standard >> >> compiler suite? We figured out that gcc 4.3 does have a speed gain in >> >> some numerical code of 3 - 8 % and I guess we can use this in the >> >> basic >> >> OS as well ... >> > >> > Number crunching has a totally different execution profile than basic >> > operating system services. Gains in one area cannot simply be >> > transferred to the other. >> >> Would it be possible, as a "workaround" to have "system-CC" and >> "ports-CC" defined in make.conf, making one CC the compiler for /usr/src >> and another for ports, or would this just create debugging nightmares? > > Why do you think you don't have this today? > > Install /usr/ports/lang/gcc/gcc43. It lives nicely beside the base > compiler. Anytime you want to use it - set 'CC' to 'gcc43'. > I know this is a different issue, and being hashed in another thread, but this is exactly what I did. However, with an older version of binutils installed, I didnt get the advantage of being able to use SSE4.1 on my machine. I made from the sources binutils, but it was a real pain to get the /usr/ports/lang/gcc/gcc43 port to pick up the presence of the newer version of binutils. I had to make simlinks for various directories and every time they changed the port it would klobber the links. It became ickey! Peg From yoctogram at gmail.com Mon Jan 12 07:30:37 2009 From: yoctogram at gmail.com (Yocto) Date: Mon Jan 12 09:08:40 2009 Subject: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) References: <61484.71762.qm@web32708.mail.mud.yahoo.com><20090111044448.GC5661@server.vk2pj.dyndns.org><4969CC6D.6030707@mail.zedat.fu-berlin.de><496A8F45.7010400@gmail.com><7d6fde3d0901111813y3da92325p6d2a3541d7db53a2@mail.gmail.com> Message-ID: > > I am not a lawyer .. I have an opinion but it is probably better to leave > comments to people with better understanding of legal issues. This is not the first time I heard "I am not a lawyer". Even if you were a lawyer, it would still be an 'opinion'. And judges will give verdict based on both side 'opinions'. That is why a rather stick we BSD/MIT type of licenses... I can't afford (time & money) on lawyers "opinions" that may or may not ... // Yocto From alexanderchuranov at gmail.com Mon Jan 12 09:13:04 2009 From: alexanderchuranov at gmail.com (Alexander Churanov) Date: Mon Jan 12 09:13:11 2009 Subject: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) In-Reply-To: References: <61484.71762.qm@web32708.mail.mud.yahoo.com> <20090111044448.GC5661@server.vk2pj.dyndns.org> <4969CC6D.6030707@mail.zedat.fu-berlin.de> <496A8F45.7010400@gmail.com> <7d6fde3d0901111813y3da92325p6d2a3541d7db53a2@mail.gmail.com> Message-ID: <3cb459ed0901120913i17e7b68fk6c8050774a326041@mail.gmail.com> 2009/1/12 Yocto > Even if you were a lawyer, it would still be an 'opinion'. > And judges will give verdict based on both side 'opinions'. > > That is why a rather stick we BSD/MIT type of licenses... > I can't afford (time & money) on lawyers "opinions" that may or may not ... > +1 Alexander Churanov From hartzell at alerce.com Mon Jan 12 08:02:49 2009 From: hartzell at alerce.com (George Hartzell) Date: Mon Jan 12 09:13:57 2009 Subject: patch to fix burncd bug In-Reply-To: <20090110084012.GA1979@a91-153-125-115.elisa-laajakaista.fi> References: <1de79840901080935s130f647r36815df468a9220b@mail.gmail.com> <18791.65426.128568.526167@almost.alerce.com> <20090110084012.GA1979@a91-153-125-115.elisa-laajakaista.fi> Message-ID: <18795.27048.855213.465843@almost.alerce.com> Jaakko Heinonen writes: > > Hi, > > On 2009-01-09, George Hartzell wrote: > > I have a mac pro running 7.1-PRERELEASE system (not sure when I last > > updated it) on which burncd seems to successfully burn the data but > > then fails while fixating. > > > > I applied the above patch by hand, with a little bit of fuzz, and now > > it fails to burn the data but fixating no longer bombs out. > > It can't see how it could be possible that the patch (correctly applied) > causes this. Are you sure that this is repeatable behavior and burning > always works with an unpatched kernel? Does dmesg show any error > messages after failed burn? I'm willing to believe that I messed it up.... Alex has suggested that I upgrade the system to 7.1, which is on my list of things to do this week (just been waiting for gnome to update). I'll let you know as soon as I try it out. Thanks, g. From obrien at freebsd.org Mon Jan 12 09:20:59 2009 From: obrien at freebsd.org (David O'Brien) Date: Mon Jan 12 09:21:06 2009 Subject: patch to fix burncd bug In-Reply-To: References: Message-ID: <20090112172057.GA78699@dragon.NUXI.org> On Thu, Jan 08, 2009 at 06:13:14PM +0100, Alexander Best wrote: > could somebody please commit the following patch to dev/ata? it fixes a nasty > bug during fixation in burncd. the bug exists in RELENG6, RELENG7 and HEAD > (and maybe RELENG5): > > http://www.freebsd.org/cgi/query-pr.cgi?prp=95979-3-txt&n=/patch I've committed the ata-queue.c change (r187105) as I hit this again over the weekend. I didn't commit the timeout change as I'm not sure all the implications. Also folks "thought" cdrecord did the same, but I didn't see a high enough confidence factor and I didn't have time to track it down myself. -- -- David (obrien@FreeBSD.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play "Jeopardy-style quoting" From qing.li at bluecoat.com Mon Jan 12 10:25:18 2009 From: qing.li at bluecoat.com (Li, Qing) Date: Mon Jan 12 10:25:32 2009 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: References: <20081227202117.F3B14341A3@cavin02.kulnet.kuleuven.ac.be><200812281613.49404.tijl@ulyssis.org> Message-ID: I have revived the RTF_LLINFO definition in route.h. A new kernel option "COMPAT_ROUTE_FLAGS" is introduced, all for providing binary compatibility for existing ports. I could have made the RTF_LLINFO bit only applicable with _KERNEL. Without rehashing the discussion we all had on this topic on both -current@ and -net@ MLs last month, moving forward, all arp-v2 affected ports should continue to be modified and updated with the understanding the RTF_LLINFO, RTF_WASCLONED etc. flags are obsolete. There are no support for the semantics of these flag bits in the kernel, other than returning these bits to userland for the existing ports. Please sync-up to the following revision: SVN rev 187094 on 2009-01-12 11:24:32Z by qingli Thanks, -- Qing > -----Original Message----- > From: Gerald Pfeifer [mailto:gerald@pfeifer.com] > Sent: Friday, January 09, 2009 1:27 AM > To: Li, Qing > Cc: Tijl Coosemans; Qing Li; freebsd-net@freebsd.org; freebsd- > current@freebsd.org > Subject: RE: HEADSUP: arp-v2 has been committed > > On Tue, 30 Dec 2008, Li, Qing wrote: > > I don't think we can provide binary compatibility without putting > > back RTF_LLINFO exactly as it was. My preference is to continue down > > the new path without RTF_LLINFO. > > So, you are saying that applications built on FreeBSD 7 or earlier > that use RTF_LLINFO will no longer work properly on FreeBSD 8 after > your change? > > Ignoring everything else, that would be a killer and the one reason > to definitely change the current situation. Otherwise, ISVs will need > two builds, one for FreeBSD 7 and earlier and one for FreeBSD 8, and > believe me, that is bad, bad, bad. Or rather: unlikely. (GNU/Linux > distributions do provide this level of compatibility.) > > > We still have some time before the 8.0 release. It's straightforward > > for me to retain some of the RTF_LLINFO support in the new kernel if > > and when the situation becomes necessary. > > Sounds like that is the case? > > > Since the affected ports now have the conditional code around > > RTF_LLINFO, the updates would allow these ports to compile in > > both -current and in the previous releases. > > emulators/wine still is broken, and upstream Wine has not accepted > the patch yet. I believe one reason likely is the above, and the > fact that this may break commercial builds of Wine. > > How are you going to address this? > > Gerald > -- > Gerald (Jerry) Pfeifer gerald@pfeifer.com > http://www.pfeifer.com/gerald/ From rdivacky at freebsd.org Mon Jan 12 12:01:58 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Mon Jan 12 12:02:05 2009 Subject: [RFC]: flex/lex update Message-ID: <20090112200128.GA85280@freebsd.org> hi I noticed there is an update to lex/flex. The version in our tree is ancient and there seems to be some updates (http://flex.sourceforge.net/) Can someone comment on the state of lex in our tree? It's not considered a contributed software (it resides in usr.bin) but it was taken from elsewhere. what is our position? is it preferable for me to work on updating it or just fixing the one bug I ran into? thnx! roman From yanefbsd at gmail.com Mon Jan 12 12:12:24 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Mon Jan 12 12:12:32 2009 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: References: <20081227202117.F3B14341A3@cavin02.kulnet.kuleuven.ac.be> <200812281613.49404.tijl@ulyssis.org> Message-ID: <7d6fde3d0901121212i3acf282dj6bc3b7d59a044e5e@mail.gmail.com> On Mon, Jan 12, 2009 at 10:25 AM, Li, Qing wrote: > I have revived the RTF_LLINFO definition in route.h. > A new kernel option "COMPAT_ROUTE_FLAGS" is introduced, all > for providing binary compatibility for existing ports. > I could have made the RTF_LLINFO bit only applicable with _KERNEL. > > Without rehashing the discussion we all had on this topic on > both -current@ and -net@ MLs last month, moving forward, all > arp-v2 affected ports should continue to be modified and updated > with the understanding the RTF_LLINFO, RTF_WASCLONED etc. flags are > obsolete. There are no support for the semantics of these > flag bits in the kernel, other than returning these bits to > userland for the existing ports. > > Please sync-up to the following revision: > > SVN rev 187094 on 2009-01-12 11:24:32Z by qingli > > Thanks, > > -- Qing > > >> -----Original Message----- >> From: Gerald Pfeifer [mailto:gerald@pfeifer.com] >> Sent: Friday, January 09, 2009 1:27 AM >> To: Li, Qing >> Cc: Tijl Coosemans; Qing Li; freebsd-net@freebsd.org; freebsd- >> current@freebsd.org >> Subject: RE: HEADSUP: arp-v2 has been committed >> >> On Tue, 30 Dec 2008, Li, Qing wrote: >> > I don't think we can provide binary compatibility without putting >> > back RTF_LLINFO exactly as it was. My preference is to continue down >> > the new path without RTF_LLINFO. >> >> So, you are saying that applications built on FreeBSD 7 or earlier >> that use RTF_LLINFO will no longer work properly on FreeBSD 8 after >> your change? >> >> Ignoring everything else, that would be a killer and the one reason >> to definitely change the current situation. Otherwise, ISVs will need >> two builds, one for FreeBSD 7 and earlier and one for FreeBSD 8, and >> believe me, that is bad, bad, bad. Or rather: unlikely. (GNU/Linux >> distributions do provide this level of compatibility.) >> >> > We still have some time before the 8.0 release. It's straightforward >> > for me to retain some of the RTF_LLINFO support in the new kernel if >> > and when the situation becomes necessary. >> >> Sounds like that is the case? >> >> > Since the affected ports now have the conditional code around >> > RTF_LLINFO, the updates would allow these ports to compile in >> > both -current and in the previous releases. >> >> emulators/wine still is broken, and upstream Wine has not accepted >> the patch yet. I believe one reason likely is the above, and the >> fact that this may break commercial builds of Wine. >> >> How are you going to address this? >> >> Gerald Oh, btw... wine works well when you set the RTF_LLINFO value to 0 with arp-v2, AFAICT. -Garrett From yanefbsd at gmail.com Mon Jan 12 12:47:56 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Mon Jan 12 12:48:09 2009 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: <496BAA26.9010200@elischer.org> References: <20081227202117.F3B14341A3@cavin02.kulnet.kuleuven.ac.be> <200812281613.49404.tijl@ulyssis.org> <7d6fde3d0901121212i3acf282dj6bc3b7d59a044e5e@mail.gmail.com> <496BAA26.9010200@elischer.org> Message-ID: <7d6fde3d0901121247t31ee0d8cp6d46cf9b3b256fad@mail.gmail.com> On Mon, Jan 12, 2009 at 12:37 PM, Julian Elischer wrote: > Garrett Cooper wrote: > > I think setting it to a value of 0 has two good points... > > In code that does: > if (XXX & RTF_LLINFO) { > yyy() > } > the optimiser should simply remove the code, > or at worst give an error messages that makes people go look for > the answer, and secondly, > the conditional > > #if defined(RTF_LLINFO) && (RTF_LLINFO != 0) > > can be easily used to make code conditionally do the right thing > for different versions of freeBSD, > possibly trivially replacing earlier occurances of > > #ifdef RTF_LLINFO > > > >> >> Oh, btw... wine works well when you set the RTF_LLINFO value to 0 >> with arp-v2, AFAICT. >> -Garrett That's basically what I did (2 instances in the file had to be replaced) -- #ifndef RTF_LLINFO /* Insert code here with 0. */ #else /* Insert code here with RTF_LLINFO. */ #endif The code checks to see if sysctl exists, and then defaults to Linux-y behavior, so other OS'es with proper sysctl support could be broken by this change. I tested this out with Steam and wine-doors, but unfortunately I ran into OpenGL issues that prevented me from playing Steam games -_-... Cheers, -Garrett From julian at elischer.org Mon Jan 12 13:06:33 2009 From: julian at elischer.org (Julian Elischer) Date: Mon Jan 12 13:06:45 2009 Subject: HEADSUP: arp-v2 has been committed In-Reply-To: <7d6fde3d0901121212i3acf282dj6bc3b7d59a044e5e@mail.gmail.com> References: <20081227202117.F3B14341A3@cavin02.kulnet.kuleuven.ac.be> <200812281613.49404.tijl@ulyssis.org> <7d6fde3d0901121212i3acf282dj6bc3b7d59a044e5e@mail.gmail.com> Message-ID: <496BAA26.9010200@elischer.org> Garrett Cooper wrote: I think setting it to a value of 0 has two good points... In code that does: if (XXX & RTF_LLINFO) { yyy() } the optimiser should simply remove the code, or at worst give an error messages that makes people go look for the answer, and secondly, the conditional #if defined(RTF_LLINFO) && (RTF_LLINFO != 0) can be easily used to make code conditionally do the right thing for different versions of freeBSD, possibly trivially replacing earlier occurances of #ifdef RTF_LLINFO > > Oh, btw... wine works well when you set the RTF_LLINFO value to 0 > with arp-v2, AFAICT. > -Garrett > _______________________________________________ > 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 rohit.trip at gmail.com Mon Jan 12 14:00:06 2009 From: rohit.trip at gmail.com (Rohit Tripathi) Date: Mon Jan 12 14:00:13 2009 Subject: hints on setting up usb cdma modem? Message-ID: <33615c8e0901121328h5e594c7fw43ff42943baf70d0@mail.gmail.com> I'm running current and after many failed attempts to setup my Novatel U727, I'm posting here with whatever information could be of interest. When the modem is plugged in: umass0: on uhub3 cd0 at umass-sim0 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 1.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present My usbd.conf: 21:21:46 $ cat /etc/usbd.conf device "Novatel" devname "ucom0" vendor 0x1410 product 0x4100 attach "/usr/sbin/ppp -auto novatel" detach "/usr/sbin/pppctl /var/run/ppp/novatel-ppp quit all" Avery now and then, I see some of these messages: umass0: at uhub3 port 1 (addr 2) disconnected (cd0:umass-sim0:0:0:0): lost device (cd0:umass-sim0:0:0:0): removing device entry umass0: detached umass0: on uhub3 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-2 device da0: 1.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present My /etc/ppp/ppp.conf: novatel: set device /dev/ucom0 set speed 115200 set phone "#777" # 1 refers to CID set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \ \"\" AT OK-AT-OK ATE1Q0 OK \\dATDT\\T TIMEOUT 40 CONNECT" enable dns set authname wap set authkey wap accept PAP set login add default HISADDR set ifaddr 10.0.0.1/0 10.0.0.2/0 0.0.0.0 0.0.0.0 disable ipv6cp disable mppe set reconnect 3 15 From thompsa at FreeBSD.org Mon Jan 12 14:04:29 2009 From: thompsa at FreeBSD.org (Andrew Thompson) Date: Mon Jan 12 14:04:38 2009 Subject: hints on setting up usb cdma modem? In-Reply-To: <33615c8e0901121328h5e594c7fw43ff42943baf70d0@mail.gmail.com> References: <33615c8e0901121328h5e594c7fw43ff42943baf70d0@mail.gmail.com> Message-ID: <20090112220422.GA1995@citylink.fud.org.nz> On Mon, Jan 12, 2009 at 04:28:12PM -0500, Rohit Tripathi wrote: > I'm running current and after many failed attempts to setup my Novatel > U727, I'm posting here with whatever information could be of interest. > > When the modem is plugged in: > > umass0: addr 2> on uhub3 > cd0 at umass-sim0 bus 0 target 0 lun 0 > cd0: Removable CD-ROM SCSI-2 device > cd0: 1.000MB/s transfers > cd0: Attempt to query device size failed: NOT READY, Medium not present You should start by loading the u3g driver, it will likely just work. > My usbd.conf: > 21:21:46 $ cat /etc/usbd.conf > device "Novatel" > devname "ucom0" > vendor 0x1410 > product 0x4100 usbd was removed some 3 years ago, you will want to use devd for this now. Andrew From Peter.Ross at alumni.tu-berlin.de Mon Jan 12 15:15:41 2009 From: Peter.Ross at alumni.tu-berlin.de (Peter Ross) Date: Mon Jan 12 15:15:48 2009 Subject: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) In-Reply-To: <496B1471.1080900@unsane.co.uk> References: <61484.71762.qm@web32708.mail.mud.yahoo.com> <20090111044448.GC5661@server.vk2pj.dyndns.org> <342292.89033.qm@web32703.mail.mud.yahoo.com> <496A98B3.1010301@freebsd.org> <496B1471.1080900@unsane.co.uk> Message-ID: On Mon, 12 Jan 2009, Vincent Hoffman wrote: > Peter Ross wrote: > > > > AFAIK you _need_ a C compiler to keep your system secure, to apply > > security patches. > > > > E.g. http://security.freebsd.org/advisories/FreeBSD-SA-09:02.openssl.asc > > > > .. > > make obj && make depend && make && make install > > > > Or more recently, > freebsd-update fetch && freebsd-update install > > its really not needed if you are just following -RELEASE except of > course for ports. I have to apologize for my outdated knowledge. It is around for two years, and well-described in the handbook:-) Thanks for correcting me. Still, there are "real world" cases when the standard install is not good enough. I do not run into them daily but they are not that rare either. The last one, some days ago: A Dell desktop had USB keyboard problems. I fixed it by compiling the USB2 kernel. It did not work with -STABLE and -CURRENT's GENERIC kernel (with the "old" USB stack). Regards Peter From eitanadlerlist at gmail.com Mon Jan 12 16:16:10 2009 From: eitanadlerlist at gmail.com (Eitan Adler) Date: Mon Jan 12 16:16:19 2009 Subject: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) In-Reply-To: <496B46D6.6060403@math.missouri.edu> References: <20090112094429.GA87628@lpthe.jussieu.fr> <496B46D6.6060403@math.missouri.edu> Message-ID: <496BDD3E.1000507@gmail.com> > As for Michel's point that the results of the compilation are not > covered by GPL - this seems to be stated explicitly in the GPLv3 license. Which is my question. Why do we need update the compiler when the license shouldn't matter? Has anyone asked the FSF about this issue anyway? Does the FSF claim that the output of the compiler becomes "free" software? > > Stephen > _______________________________________________ > 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" > -- Eitan Adler "Security is increased by designing for the way humans actually behave." -Jakob Nielsen From ttw+bsd at cobbled.net Mon Jan 12 16:55:48 2009 From: ttw+bsd at cobbled.net (n0g0013) Date: Mon Jan 12 16:55:55 2009 Subject: testing for 'sysconf' interface Message-ID: <20090113002905.GA6683@holyman.cobbled.net> can anyone advise the correct way to test for the presence of the 'sysconf' interface in 'unistd.h'? i'm guessing it's #ifdef POSIX but i'd appreciate if someone can confirm that. -- t t w From oberman at es.net Mon Jan 12 20:52:58 2009 From: oberman at es.net (Kevin Oberman) Date: Mon Jan 12 20:53:05 2009 Subject: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) In-Reply-To: Your message of "Mon, 12 Jan 2009 19:15:58 EST." <496BDD3E.1000507@gmail.com> Message-ID: <20090113044111.134EC1CC0B@ptavv.es.net> > Date: Mon, 12 Jan 2009 19:15:58 -0500 > From: Eitan Adler > Sender: owner-freebsd-current@freebsd.org > > > As for Michel's point that the results of the compilation are not > > covered by GPL - this seems to be stated explicitly in the GPLv3 license. > Which is my question. Why do we need update the compiler when the > license shouldn't matter? > Has anyone asked the FSF about this issue anyway? Does the FSF claim > that the output of the compiler becomes "free" software? Smells like FUD to me. In all of my reading, I have never seen such a claim. There may be some GPLv3 issues, but I seriously doubt this is one. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From stephen at math.missouri.edu Mon Jan 12 20:56:57 2009 From: stephen at math.missouri.edu (Stephen Montgomery-Smith) Date: Mon Jan 12 20:57:04 2009 Subject: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) In-Reply-To: <20090113044111.134EC1CC0B@ptavv.es.net> References: <20090113044111.134EC1CC0B@ptavv.es.net> Message-ID: <496C1F14.2020207@math.missouri.edu> Kevin Oberman wrote: >> Date: Mon, 12 Jan 2009 19:15:58 -0500 >> From: Eitan Adler >> Sender: owner-freebsd-current@freebsd.org >> >>> As for Michel's point that the results of the compilation are not >>> covered by GPL - this seems to be stated explicitly in the GPLv3 license. >> Which is my question. Why do we need update the compiler when the >> license shouldn't matter? >> Has anyone asked the FSF about this issue anyway? Does the FSF claim >> that the output of the compiler becomes "free" software? > > Smells like FUD to me. In all of my reading, I have never seen such a > claim. There may be some GPLv3 issues, but I seriously doubt this is > one. I just wanted to clarify (because my post is a bit ambiguous) - I was trying to say that the GPLv3 seems to be explicitly saying that the output of the compilation is NOT covered by GPL: To quote (** added): 2. Basic Permissions. All rights granted under this License are granted for the term of copyright on the Program, and are irrevocable provided the stated conditions are met. This License explicitly affirms your unlimited permission to run the unmodified Program. **The output from running a covered work is covered by this License only if the output, given its content, constitutes a covered work.** This License acknowledges your rights of fair use or other equivalent, as provided by copyright law. From yanefbsd at gmail.com Mon Jan 12 22:49:04 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Mon Jan 12 22:49:11 2009 Subject: snd_hda(4): getting line-in to work In-Reply-To: <49670AF2.7040901@FreeBSD.org> References: <7d6fde3d0901061032n72e9d0c4refe3c695f441c827@mail.gmail.com> <4963C4C0.6000509@FreeBSD.org> <7d6fde3d0901062029j694d63c1h66c52dfbb80c13d8@mail.gmail.com> <49647602.9060402@FreeBSD.org> <49649333.6060902@gmail.com> <7d6fde3d0901080937t29ec42f5i6684b9223d0b368a@mail.gmail.com> <49664FD8.1060700@FreeBSD.org> <7d6fde3d0901082336o6291c3a8r5cbb91a89db13ef7@mail.gmail.com> <49670AF2.7040901@FreeBSD.org> Message-ID: <7d6fde3d0901122249i6e760afdw510b3b84e3df68ad@mail.gmail.com> On Fri, Jan 9, 2009 at 12:29 AM, Alexander Motin wrote: > Garrett Cooper wrote: >> On Thu, Jan 8, 2009 at 11:11 AM, Alexander Motin wrote: >>> Garrett Cooper wrote: >>>> Ok, I got stuck again. Can you possibly push me in the right >>>> direction (complete verbose dmesg attached)? The line-in and SPDIF >>>> (not so much of a concern) are the only issues that I'm aware of. I'll >>>> have to open up my case and wire up the front ports in order to test >>>> them for you. >>> Ok. Let's stop for a moment and start from the beginning, because now it is >>> already like a puzzle for me too. Let me explain once more what I see you >>> have and then you explain me where is your problem. >>> >>> You have 3 PCM devices configured: >>> - pcm0: 7.1 playback via 4 rear jacks (Green, Black, Orange and Grey) + >>> record from mic (front Pink), line (rear Blue), monitor (second mic, rear >>> Pink), cd (internal Black) or mix (sum of all these). >>> - pcm1: stereo playback via front Green jack. >>> - pcm2: SPDIF output >>> >>> As for me, this configuration is correct and good enough. You can record >>> from your line-in via pcm0 after selecting that source via `mixer =rec line` >>> command. You can playback via SPDIF by using pcm2 device. >>> >>> So what's wrong? What are you doing and what is not working and how? >> >> Ok, just checking my sanity, I started swapping around the plugs in >> the back, checking my connections, etc. I tried my mic, worked (the >> gain was a bit small, sound was _really_ distorted), then switched > > It is possible to control external mic phantom power via loader.conf. I > have never tried it myself, but it may be related. > >> back to my line-in and sure enough, it now works :D. >> >> What changed since yesterday: >> - I hadn't set mixer_enable="YES" in rc.conf. This brought up a LOT >> more channels and options than I had originally. > > Don't very understand what you mean by channels. mixer_enable just loads > mixer settings saved on shutdown. > >> - Rebooted the machine with fixed device.hints (unchanged from the default :P). >> - I changed the volume for mix from 0:0 to 30:30. > > mix now controls volume of mixed inputs recording (if you select this > record source. I would prefer direct line recording) and input > monitoring. Sure it is not very good, I am thinking to somehow separate > them. > >> My summary (experience) thus far: >> >> So far the driver functions as expected, but the frequency response >> seems a bit off for the output -- it's really focused around the vocal >> range (the lower 3 frequencies on the audacity, iTunes, xmms equalizer >> -- forget the frequencies). >> >> It's not so bad with PCM sound, but It's really off with Line-in / >> Mic. Any hints or hacking I can do to adjust the voltage levels sent >> to the ADC's in the hardware? > > There is no standardized ADC controls in HDA specification. Some codecs > allows loading some unstandardized "processing coefficients" for some > widgets, but I don't see respective "PROC" capability in your verbose > output. All you can is to control amplifiers gains and Vref for mics. > > If you have distorted sound on line-in, I would recommend you to check > gains of all amplifiers inside codec where signal passes. Most inputs of > your codec (including line) have +30dB mic pre-amplifiers. It is good > for mics, but not needed for line-in. Set mixer "line" level to the > lowest nonzero value to disable pre-amplification (without muting it) > and avoid signal clipping there. Control recording level by other > controls. If you are recording from mix, but not from the line, take > note that mix control also have +12dB upper amplifier control range, so > setting it to maximum values can also produce clipping. All this > information obtained from your dmesg. Good call -- perhaps this tip should be noted in the manpage (or at the very least in the handbook under the sound section)? Here are my current values (yes, line is set to 2% per channel ;)...): [gcooper@orangebox /usr/home/gcooper]$ mixer Mixer vol is currently set to 100:100 Mixer pcm is currently set to 100:100 Mixer speaker is currently set to 75:75 Mixer line is currently set to 2:2 Mixer mic is currently set to 0:0 Mixer cd is currently set to 75:75 Mixer mix is currently set to 86:86 Mixer rec is currently set to 0:0 Mixer monitor is currently set to 75:75 Recording source: line This definitely makes playing DVD's from my PS2 bearable (no clipping; it's on par with the volume from my pcm / vol channels) while I wait for mplayer's libdvdcss support to be supported by my BlueRay DVD drive. Let me know if you ever need someone to feature test something with snd_hda(4) for you in the future ;). Thanks again for all of the help Alexander! Cheers, -Garrett From stas at FreeBSD.org Mon Jan 12 23:06:31 2009 From: stas at FreeBSD.org (Stanislav Sedov) Date: Mon Jan 12 23:06:38 2009 Subject: [RFC]: flex/lex update In-Reply-To: <20090112200128.GA85280@freebsd.org> References: <20090112200128.GA85280@freebsd.org> Message-ID: <20090113100623.493b3b43.stas@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 12 Jan 2009 21:01:28 +0100 Roman Divacky mentioned: > hi > > I noticed there is an update to lex/flex. The version in our tree > is ancient and there seems to be some updates (http://flex.sourceforge.net/) > > Can someone comment on the state of lex in our tree? It's not considered > a contributed software (it resides in usr.bin) but it was taken from elsewhere. > > what is our position? is it preferable for me to work on updating it or > just fixing the one bug I ran into? > > thnx! > > roman Are there any benefits in updating? Does it worth the hassle? We have this version of flex in ports for those who needs extended features. If there're no critical echancements/fixes in the updated flex version I'd prefer to stay with what we have and just fix the bugs encountered locally. - -- Stanislav Sedov ST4096-RIPE -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAklsPXQACgkQK/VZk+smlYGzJQCfcM5KxhDxcJNva3m6A/xREsF4 8V4An0+ICazLoWg1IJNB+uIJZNk2lWpM =wBWG -----END PGP SIGNATURE----- !DSPAM:496c3d74967002107598870! From yanefbsd at gmail.com Mon Jan 12 23:32:33 2009 From: yanefbsd at gmail.com (Garrett Cooper) Date: Mon Jan 12 23:32:40 2009 Subject: [RFC]: flex/lex update In-Reply-To: <20090113100623.493b3b43.stas@FreeBSD.org> References: <20090112200128.GA85280@freebsd.org> <20090113100623.493b3b43.stas@FreeBSD.org> Message-ID: <7d6fde3d0901122332k3279624ajf1282a5f831cbf38@mail.gmail.com> On Mon, Jan 12, 2009 at 11:06 PM, Stanislav Sedov wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Mon, 12 Jan 2009 21:01:28 +0100 > Roman Divacky mentioned: > >> hi >> >> I noticed there is an update to lex/flex. The version in our tree >> is ancient and there seems to be some updates (http://flex.sourceforge.net/) >> >> Can someone comment on the state of lex in our tree? It's not considered >> a contributed software (it resides in usr.bin) but it was taken from elsewhere. >> >> what is our position? is it preferable for me to work on updating it or >> just fixing the one bug I ran into? >> >> thnx! >> >> roman > > Are there any benefits in updating? Does it worth the hassle? We have this > version of flex in ports for those who needs extended features. > > If there're no critical echancements/fixes in the updated flex version I'd > prefer to stay with what we have and just fix the bugs encountered locally. But our version of flex is almost 6 years old 0-0? (for anyone oblivious of its need -- including me a few minutes ago) we apparently need it for the following sourcefiles: [gcooper@orangebox /usr/home/gcooper/Desktop/flex-2.5.35]$ find /usr/src/ -name '*.l' /usr/src/bin/sh/arith_lex.l /usr/src/cddl/contrib/opensolaris/lib/libdtrace/common/dt_lex.l /usr/src/contrib/amd/amd/conf_tok.l /usr/src/contrib/amd/fsinfo/fsi_lex.l /usr/src/contrib/bc/bc/scan.l /usr/src/contrib/binutils/binutils/arlex.l /usr/src/contrib/binutils/binutils/deflex.l /usr/src/contrib/binutils/binutils/rclex.l /usr/src/contrib/binutils/binutils/syslex.l /usr/src/contrib/binutils/gas/itbl-lex.l /usr/src/contrib/binutils/ld/ldlex.l /usr/src/contrib/com_err/lex.l /usr/src/contrib/csup/token.l /usr/src/contrib/csup/rcstokenizer.l /usr/src/contrib/gcc/gengtype-lex.l /usr/src/contrib/gdb/gdb/ada-lex.l /usr/src/contrib/ipfilter/iplang/iplang_l.l /usr/src/contrib/libpcap/scanner.l /usr/src/lib/libc/net/nslexer.l /usr/src/lib/libipsec/policy_token.l /usr/src/sbin/devd/token.l /usr/src/sbin/setkey/token.l /usr/src/sys/contrib/dev/acpica/compiler/aslcompiler.l /usr/src/sys/dev/aic7xxx/aicasm/aicasm_macro_scan.l /usr/src/sys/dev/aic7xxx/aicasm/aicasm_scan.l /usr/src/usr.bin/ar/acplex.l /usr/src/usr.bin/colldef/scan.l /usr/src/usr.bin/lex/scan.l /usr/src/usr.bin/mklocale/lex.l /usr/src/usr.bin/xlint/lint1/scan.l /usr/src/usr.sbin/apmd/apmdlex.l /usr/src/usr.sbin/bluetooth/bthidd/lexer.l /usr/src/usr.sbin/bluetooth/hcsecd/lexer.l /usr/src/usr.sbin/config/lang.l /usr/src/usr.sbin/kbdcontrol/lex.l /usr/src/usr.sbin/ndiscvt/inf-token.l /usr/src/usr.sbin/rrenumd/lexer.l /usr/src/crypto/heimdal/lib/asn1/lex.l /usr/src/crypto/heimdal/lib/com_err/lex.l /usr/src/crypto/heimdal/lib/sl/lex.l /usr/src/crypto/heimdal/lib/sl/slc-lex.l Cheers, -Garrett From delphij at delphij.net Mon Jan 12 23:50:48 2009 From: delphij at delphij.net (Xin LI) Date: Mon Jan 12 23:50:55 2009 Subject: [RFC]: flex/lex update In-Reply-To: <20090113100623.493b3b43.stas@FreeBSD.org> References: <20090112200128.GA85280@freebsd.org> <20090113100623.493b3b43.stas@FreeBSD.org> Message-ID: <496C47CD.7030701@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stanislav Sedov wrote: > On Mon, 12 Jan 2009 21:01:28 +0100 > Roman Divacky mentioned: > >> hi > >> I noticed there is an update to lex/flex. The version in our tree >> is ancient and there seems to be some updates (http://flex.sourceforge.net/) > >> Can someone comment on the state of lex in our tree? It's not considered >> a contributed software (it resides in usr.bin) but it was taken from elsewhere. > >> what is our position? is it preferable for me to work on updating it or >> just fixing the one bug I ran into? > >> thnx! > >> roman > > Are there any benefits in updating? Does it worth the hassle? We have this > version of flex in ports for those who needs extended features. > > If there're no critical echancements/fixes in the updated flex version I'd > prefer to stay with what we have and just fix the bugs encountered locally. My $0.02 personal opinion: if we (say, nobody among -committers@ or someone who is actively answering PRs if any) do not intend to maintain it ourselves, then it would be probably a good idea to make it up-to-date with the vendor version, or rename it to something like 'bsdlex' and teach the build infrastructure about it. Build tools should work out-of-the-box and act similar, or at least, not very far from other POSIX operating systems IMHO =-) Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAklsR80ACgkQi+vbBBjt66AwzgCgwmfKI5JMNKW+zQSMbpZg/ZmF eUAAn0n6VjVqztx4v7xUi/v/6iyfFTBy =dH/3 -----END PGP SIGNATURE----- From admin at lissyara.su Mon Jan 12 23:55:28 2009 From: admin at lissyara.su (Alex Keda) Date: Mon Jan 12 23:55:35 2009 Subject: Warnings when insert USB flash Message-ID: <496C48E8.6050709@lissyara.su> This is - well? Flash drive work correct ============ FreeBSD lissyara.moskb.local 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sun Jan 11 12:17:46 MSK 2009 lissyara@lissyara.moskb.local:/usr/obj/mnt/jabber/DISTR/FreeBSD/src/CURRENT/sys/USB2 amd64 ============ Jan 13 10:51:27 lissyara kernel: ugen4.2: at usbus4 Jan 13 10:51:27 lissyara kernel: umass1: on usbus4 Jan 13 10:51:27 lissyara kernel: umass1: SCSI over Bulk-Only; quirks = 0x0000 Jan 13 10:51:28 lissyara kernel: umass1:6:1:-1: Attached to scbus6 Jan 13 10:51:28 lissyara kernel: da4 at umass-sim1 bus 1 target 0 lun 0 Jan 13 10:51:28 lissyara kernel: da4: < Flash Disk 5.00> Removable Direct Access SCSI-2 device Jan 13 10:51:28 lissyara kernel: da4: 1.000MB/s transfers Jan 13 10:51:28 lissyara kernel: da4: 126MB (259840 512 byte sectors: 64H 32S/T 126C) Jan 13 10:51:28 lissyara kernel: (da4:umass-sim1:1:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 Jan 13 10:51:28 lissyara kernel: (da4:umass-sim1:1:0:0): NOT READY asc:3a,0 Jan 13 10:51:28 lissyara kernel: (da4:umass-sim1:1:0:0): Medium not present Jan 13 10:51:28 lissyara kernel: (da4:umass-sim1:1:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 Jan 13 10:51:28 lissyara kernel: (da4:umass-sim1:1:0:0): NOT READY asc:3a,0 Jan 13 10:51:28 lissyara kernel: (da4:umass-sim1:1:0:0): Medium not present Jan 13 10:51:28 lissyara kernel: (da4:umass-sim1:1:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 Jan 13 10:51:28 lissyara kernel: (da4:umass-sim1:1:0:0): NOT READY asc:3a,0 Jan 13 10:51:28 lissyara kernel: (da4:umass-sim1:1:0:0): Medium not present Jan 13 10:51:28 lissyara kernel: (da4:umass-sim1:1:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 Jan 13 10:51:28 lissyara kernel: (da4:umass-sim1:1:0:0): NOT READY asc:3a,0 Jan 13 10:51:28 lissyara kernel: (da4:umass-sim1:1:0:0): Medium not present ================== lissyara# mount_msdosfs /dev/da4s1 /mnt/da0/ lissyara# cd /mnt/da0/ lissyara# rm * lissyara# dd if=/dev/zero of=file bs=1m count=10 10+0 records in 10+0 records out 10485760 bytes transferred in 13.117922 secs (799346 bytes/sec) lissyara# file file file: data lissyara# when dettach: Jan 13 10:54:52 lissyara kernel: (da4:umass-sim1:1:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 Jan 13 10:54:52 lissyara kernel: (da4:umass-sim1:1:0:0): NOT READY asc:3a,0 Jan 13 10:54:52 lissyara kernel: (da4:umass-sim1:1:0:0): Medium not present Jan 13 10:54:52 lissyara kernel: (da4:umass-sim1:1:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 Jan 13 10:54:52 lissyara kernel: (da4:umass-sim1:1:0:0): NOT READY asc:3a,0 Jan 13 10:54:52 lissyara kernel: (da4:umass-sim1:1:0:0): Medium not present Jan 13 10:54:52 lissyara kernel: (da4:umass-sim1:1:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 Jan 13 10:54:52 lissyara kernel: (da4:umass-sim1:1:0:0): NOT READY asc:3a,0 Jan 13 10:54:52 lissyara kernel: (da4:umass-sim1:1:0:0): Medium not present Jan 13 10:54:52 lissyara kernel: (da4:umass-sim1:1:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 Jan 13 10:54:52 lissyara kernel: (da4:umass-sim1:1:0:0): NOT READY asc:3a,0 Jan 13 10:54:52 lissyara kernel: (da4:umass-sim1:1:0:0): Medium not present Jan 13 10:54:54 lissyara kernel: umass1: at ushub4, port 2, addr 2 (disconnected) Jan 13 10:54:54 lissyara kernel: (da4:umass-sim1:1:0:0): lost device Jan 13 10:54:54 lissyara kernel: (da4:umass-sim1:1:0:0): removing device entry Jan 13 10:54:54 lissyara kernel: ugen4.2: at usbus4 (disconnected) From rea-fbsd at codelabs.ru Tue Jan 13 00:50:19 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Tue Jan 13 00:50:44 2009 Subject: hints on setting up usb cdma modem? In-Reply-To: <33615c8e0901121328h5e594c7fw43ff42943baf70d0@mail.gmail.com> References: <33615c8e0901121328h5e594c7fw43ff42943baf70d0@mail.gmail.com> Message-ID: <+BE8V3eWlNumNoeRVXGwF9oosbU@Nxyl89WskzuM4RJ7pF/cdJZbOMo> Mon, Jan 12, 2009 at 04:28:12PM -0500, Rohit Tripathi wrote: > I'm running current and after many failed attempts to setup my Novatel > U727, I'm posting here with whatever information could be of interest. > > When the modem is plugged in: > > umass0: addr 2> on uhub3 > cd0 at umass-sim0 bus 0 target 0 lun 0 > cd0: Removable CD-ROM SCSI-2 device > cd0: 1.000MB/s transfers > cd0: Attempt to query device size failed: NOT READY, Medium not present It is not the ucom endpoint -- it is some mass-storage endpoint that your modem seem to implement too. Or you showed us not all dmesg parts that are related to your CDMA modem. Do you have /dev/cuaU* devices? For the reference, mine CDMA modem attaches with the following dmesg (it's not U727, but it is CDMA modem that is supported by ucom): ----- ucom0: on uhub5 ucom0: iclass 2/2 ucom0: data interface 1, has CM over data, has break ucom0: status change notification available ---- So, the basic questions are: - had you compiled-in/kldloaded the ucom module? - do you have ucom-related messages in dmesg? - you might also need modules 'uplcom' and/or 'umodem' -- try them. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From stas at FreeBSD.org Tue Jan 13 02:24:25 2009 From: stas at FreeBSD.org (Stanislav Sedov) Date: Tue Jan 13 02:24:56 2009 Subject: [RFC]: flex/lex update In-Reply-To: <7d6fde3d0901122332k3279624ajf1282a5f831cbf38@mail.gmail.com> References: <20090112200128.GA85280@freebsd.org> <20090113100623.493b3b43.stas@FreeBSD.org> <7d6fde3d0901122332k3279624ajf1282a5f831cbf38@mail.gmail.com> Message-ID: <20090113133620.a4a90197.stas@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 12 Jan 2009 23:32:30 -0800 "Garrett Cooper" mentioned: > On Mon, Jan 12, 2009 at 11:06 PM, Stanislav Sedov wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On Mon, 12 Jan 2009 21:01:28 +0100 > > Roman Divacky mentioned: > > > >> hi > >> > >> I noticed there is an update to lex/flex. The version in our tree > >> is ancient and there seems to be some updates (http://flex.sourceforge.net/) > >> > >> Can someone comment on the state of lex in our tree? It's not considered > >> a contributed software (it resides in usr.bin) but it was taken from elsewhere. > >> > >> what is our position? is it preferable for me to work on updating it or > >> just fixing the one bug I ran into? > >> > >> thnx! > >> > >> roman > > > > Are there any benefits in updating? Does it worth the hassle? We have this > > version of flex in ports for those who needs extended features. > > > > If there're no critical echancements/fixes in the updated flex version I'd > > prefer to stay with what we have and just fix the bugs encountered locally. > > But our version of flex is almost 6 years old 0-0? > (for anyone oblivious of its need -- including me a few minutes > ago) we apparently need it for the following sourcefiles: > We don't do software updates just for updates only. If it works why touch it? You can't garantee the new version won't break anything. If people want to use new flex why not install it from ports? - -- Stanislav Sedov ST4096-RIPE -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAklsbq0ACgkQK/VZk+smlYGMtgCeNy9GwP50rrhX16pSuBmYQedT MsMAnRKN3hnsjHIh+4nx+XIdTUyTafZd =6lph -----END PGP SIGNATURE----- !DSPAM:496c6bd6967001359969560! From stas at FreeBSD.org Tue Jan 13 02:29:38 2009 From: stas at FreeBSD.org (Stanislav Sedov) Date: Tue Jan 13 02:29:46 2009 Subject: [RFC]: flex/lex update In-Reply-To: <496C47CD.7030701@delphij.net> References: <20090112200128.GA85280@freebsd.org> <20090113100623.493b3b43.stas@FreeBSD.org> <496C47CD.7030701@delphij.net> Message-ID: <20090113134141.a87a8ecf.stas@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 12 Jan 2009 23:50:37 -0800 Xin LI mentioned: > > My $0.02 personal opinion: if we (say, nobody among -committers@ or > someone who is actively answering PRs if any) do not intend to maintain > it ourselves, then it would be probably a good idea to make it > up-to-date with the vendor version, or rename it to something like > 'bsdlex' and teach the build infrastructure about it. Build tools > should work out-of-the-box and act similar, or at least, not very far > from other POSIX operating systems IMHO =-) > I agree, but it should be deeply analyzed what we'll receive with an updated version, and what loose. If there were local patches, they should be analyzed an reimplemented for the new version as well. - -- Stanislav Sedov ST4096-RIPE -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAklsb+UACgkQK/VZk+smlYFQQQCfZBbsodlfXXY0IomC8MBnbDQy b5cAn1/15JmI14tQVtHKGlf/R4GBpNl5 =Yj9C -----END PGP SIGNATURE----- !DSPAM:496c6d0f967001753717818! From ulf.lilleengen at gmail.com Tue Jan 13 03:14:11 2009 From: ulf.lilleengen at gmail.com (Ulf Lilleengen) Date: Tue Jan 13 03:14:18 2009 Subject: [RFC]: flex/lex update In-Reply-To: <20090112200128.GA85280@freebsd.org> References: <20090112200128.GA85280@freebsd.org> Message-ID: <20090113094444.GC54243@nobby> On Mon, Jan 12, 2009 at 09:01:28PM +0100, Roman Divacky wrote: > hi > > I noticed there is an update to lex/flex. The version in our tree > is ancient and there seems to be some updates (http://flex.sourceforge.net/) > > Can someone comment on the state of lex in our tree? It's not considered > a contributed software (it resides in usr.bin) but it was taken from elsewhere. > > what is our position? is it preferable for me to work on updating it or > just fixing the one bug I ran into? I would like to see a new version of flex in base, as the current version doesn't support generating reentrant code, which is needed for the lexer used in csup for tokenizing rcs files. I solved this by just including the generated lexer, but would prefer if it could be generated from the source instead. I think philip@ started to work on this, so you should poke him regarding the work he's already done. -- Ulf Lilleengen From hselasky at c2i.net Tue Jan 13 04:01:23 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Tue Jan 13 04:01:38 2009 Subject: Warnings when insert USB flash In-Reply-To: <496C48E8.6050709@lissyara.su> References: <496C48E8.6050709@lissyara.su> Message-ID: <200901131303.44014.hselasky@c2i.net> Hi, USB2 is compiled with extra debugging by default. That's why you get some extra warnings. On Tuesday 13 January 2009, Alex Keda wrote: > This is - well? > Flash drive work correct > ============ > FreeBSD lissyara.moskb.local 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sun Jan > 11 12:17:46 MSK 2009 > lissyara@lissyara.moskb.local:/usr/obj/mnt/jabber/DISTR/FreeBSD/src/CURRENT >/sys/USB2 amd64 > ============ > Jan 13 10:51:27 lissyara kernel: ugen4.2: at usbus4 > Jan 13 10:51:27 lissyara kernel: umass1: class 0/0, rev 1.10/1.00, addr 2> on usbus4 > Jan 13 10:51:27 lissyara kernel: umass1: SCSI over Bulk-Only; quirks = > 0x0000 > Jan 13 10:51:28 lissyara kernel: umass1:6:1:-1: Attached to scbus6 > Jan 13 10:51:28 lissyara kernel: da4 at umass-sim1 bus 1 target 0 lun 0 > Jan 13 10:51:28 lissyara kernel: da4: < Flash Disk 5.00> Removable > Direct Access SCSI-2 device > Jan 13 10:51:28 lissyara kernel: da4: 1.000MB/s transfers > Jan 13 10:51:28 lissyara kernel: da4: 126MB (259840 512 byte sectors: > 64H 32S/T 126C) > Jan 13 10:51:28 lissyara kernel: (da4:umass-sim1:1:0:0): SYNCHRONIZE > CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 > Jan 13 10:51:28 lissyara kernel: (da4:umass-sim1:1:0:0): NOT READY asc:3a,0 > Jan 13 10:51:28 lissyara kernel: (da4:umass-sim1:1:0:0): Medium not present > Jan 13 10:51:28 lissyara kernel: (da4:umass-sim1:1:0:0): SYNCHRONIZE > CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 > Jan 13 10:51:28 lissyara kernel: (da4:umass-sim1:1:0:0): NOT READY asc:3a,0 > Jan 13 10:51:28 lissyara kernel: (da4:umass-sim1:1:0:0): Medium not present > Jan 13 10:51:28 lissyara kernel: (da4:umass-sim1:1:0:0): SYNCHRONIZE > CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 > Jan 13 10:51:28 lissyara kernel: (da4:umass-sim1:1:0:0): NOT READY asc:3a,0 > Jan 13 10:51:28 lissyara kernel: (da4:umass-sim1:1:0:0): Medium not present > Jan 13 10:51:28 lissyara kernel: (da4:umass-sim1:1:0:0): SYNCHRONIZE > CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 > Jan 13 10:51:28 lissyara kernel: (da4:umass-sim1:1:0:0): NOT READY asc:3a,0 > Jan 13 10:51:28 lissyara kernel: (da4:umass-sim1:1:0:0): Medium not present > ================== > lissyara# mount_msdosfs /dev/da4s1 /mnt/da0/ > lissyara# cd /mnt/da0/ > lissyara# rm * > lissyara# dd if=/dev/zero of=file bs=1m count=10 > 10+0 records in > 10+0 records out > 10485760 bytes transferred in 13.117922 secs (799346 bytes/sec) Transfer speed is Ok, and about what you can get from a full speed device. --HPS From hselasky at c2i.net Tue Jan 13 04:01:23 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Tue Jan 13 04:01:39 2009 Subject: Warnings when insert USB flash In-Reply-To: <496C48E8.6050709@lissyara.su> References: <496C48E8.6050709@lissyara.su> Message-ID: <200901131303.44014.hselasky@c2i.net> Hi, USB2 is compiled with extra debugging by default. That's why you get some extra warnings. On Tuesday 13 January 2009, Alex Keda wrote: > This is - well? > Flash drive work correct > ============ > FreeBSD lissyara.moskb.local 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sun Jan > 11 12:17:46 MSK 2009 > lissyara@lissyara.moskb.local:/usr/obj/mnt/jabber/DISTR/FreeBSD/src/CURRENT >/sys/USB2 amd64 > ============ > Jan 13 10:51:27 lissyara kernel: ugen4.2: at usbus4 > Jan 13 10:51:27 lissyara kernel: umass1: class 0/0, rev 1.10/1.00, addr 2> on usbus4 > Jan 13 10:51:27 lissyara kernel: umass1: SCSI over Bulk-Only; quirks = > 0x0000 > Jan 13 10:51:28 lissyara kernel: umass1:6:1:-1: Attached to scbus6 > Jan 13 10:51:28 lissyara kernel: da4 at umass-sim1 bus 1 target 0 lun 0 > Jan 13 10:51:28 lissyara kernel: da4: < Flash Disk 5.00> Removable > Direct Access SCSI-2 device > Jan 13 10:51:28 lissyara kernel: da4: 1.000MB/s transfers > Jan 13 10:51:28 lissyara kernel: da4: 126MB (259840 512 byte sectors: > 64H 32S/T 126C) > Jan 13 10:51:28 lissyara kernel: (da4:umass-sim1:1:0:0): SYNCHRONIZE > CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 > Jan 13 10:51:28 lissyara kernel: (da4:umass-sim1:1:0:0): NOT READY asc:3a,0 > Jan 13 10:51:28 lissyara kernel: (da4:umass-sim1:1:0:0): Medium not present > Jan 13 10:51:28 lissyara kernel: (da4:umass-sim1:1:0:0): SYNCHRONIZE > CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 > Jan 13 10:51:28 lissyara kernel: (da4:umass-sim1:1:0:0): NOT READY asc:3a,0 > Jan 13 10:51:28 lissyara kernel: (da4:umass-sim1:1:0:0): Medium not present > Jan 13 10:51:28 lissyara kernel: (da4:umass-sim1:1:0:0): SYNCHRONIZE > CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 > Jan 13 10:51:28 lissyara kernel: (da4:umass-sim1:1:0:0): NOT READY asc:3a,0 > Jan 13 10:51:28 lissyara kernel: (da4:umass-sim1:1:0:0): Medium not present > Jan 13 10:51:28 lissyara kernel: (da4:umass-sim1:1:0:0): SYNCHRONIZE > CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 > Jan 13 10:51:28 lissyara kernel: (da4:umass-sim1:1:0:0): NOT READY asc:3a,0 > Jan 13 10:51:28 lissyara kernel: (da4:umass-sim1:1:0:0): Medium not present > ================== > lissyara# mount_msdosfs /dev/da4s1 /mnt/da0/ > lissyara# cd /mnt/da0/ > lissyara# rm * > lissyara# dd if=/dev/zero of=file bs=1m count=10 > 10+0 records in > 10+0 records out > 10485760 bytes transferred in 13.117922 secs (799346 bytes/sec) Transfer speed is Ok, and about what you can get from a full speed device. --HPS From lastewart at swin.edu.au Mon Jan 12 23:53:24 2009 From: lastewart at swin.edu.au (Lawrence Stewart) Date: Tue Jan 13 04:13:10 2009 Subject: HEADS UP: imminent TCP ABC commit Message-ID: <496C3FE6.2040407@swin.edu.au> Hi All, Just a quick note to let you know that I plan to commit my TCP appropriate byte counting (ABC) patch [1,2] to HEAD within the next two days. This work has been sponsored by the FreeBSD Foundation [3] as part of the "Enhancing the FreeBSD TCP Implementation" project [4]. I don't anticipate any nastiness, but let me know if you run into any issues with your TCP workloads when running with the patch. The behaviour will default to on when committed, so any new kernel built after the commit will be using ABC by default. Note that the patch changes the size of the tcpcb structure, thus you will get ABI breakages with any utilities that rely on the size of the tcpcb e.g. sockstat will error with "sockstat: struct xtcpcb size mismatch". A rebuild/install of world will obviously solve the issue. However, copying the patched tcp_var.h from /usr/src/sys/netinet to /usr/include/netinet and selectively rebuilding these utilities as they crop up should also solve the issue faster if you're impatient and familiar with the src tree and make glue. Cheers, Lawrence http://caia.swin.edu.au [1] http://people.freebsd.org/~lstewart/patches/tcp_ffcaia2008/tcp_abc_8.x.r186471.patch [2] http://people.freebsd.org/~lstewart/patches/tcp_ffcaia2008/tcp_abc_8.x.r186471.patch.readme [3] http://www.freebsdfoundation.org/ [4] http://caia.swin.edu.au/freebsd/etcp09/ From ohartman at mail.zedat.fu-berlin.de Tue Jan 13 01:30:24 2009 From: ohartman at mail.zedat.fu-berlin.de (O. Hartmann) Date: Tue Jan 13 04:19:51 2009 Subject: X becomes unresponsive with nvidia and hardlocks with gdb (was Re: X becomes unresponsive with nvidia / xscreensaver and desktop panics) In-Reply-To: <7d6fde3d0901111853k40f26893j722d95d3556c820@mail.gmail.com> References: <7d6fde3d0901091705v6eb4c7bfxe23708f8651e2125@mail.gmail.com> <7d6fde3d0901111853k40f26893j722d95d3556c820@mail.gmail.com> Message-ID: <496C5F37.4070006@mail.zedat.fu-berlin.de> Garrett Cooper wrote: > On Fri, Jan 9, 2009 at 5:05 PM, Garrett Cooper wrote: > >> On Fri, Jan 9, 2009 at 2:05 PM, Garrett Cooper wrote: >> >>> On Fri, Jan 9, 2009 at 1:40 PM, Doug Barton wrote: >>> >>>> Garrett Cooper wrote: >>>> >>>>> Thanks for the tips Doug -- I'll give them a shot of course... >>>>> >>>> Glad I could help. The one thing I forgot to mention is to try the >>>> nvidia-settings app if you have not already done so. There are various >>>> things there that you can tweak that might yield better results. >>>> >>>> Doug >>>> >>> I did in fact set everything up via nvidia-settings. I'm running >>> some stress tests right now to see whether or not I can simulate the >>> issue -- it doesn't appear to be as straightforward as I thought.. >>> -Garrett >>> >>> >> I believe my actual problem with panicking is related to gdb, not X11. >> So the actual problem is two-fold: >> >> - X11 livelocks, where I can login via ssh and kill . >> - When I use gdb -p, it prints out the same message reported here: >> . The only >> thing is that if I press `y' on the first go-around, the machine >> hardlocks on the first try with hitting `y'. If I hit `n' so gdb >> coredumps, I can either go on my merry way, or go back to the >> confirmation dialog. If I hit it again, it doesn't hardlock. It does >> hardlock though, and for whatever reason my PC speaker beeps, and I >> have to warm boot it. I haven't been able to get a kernel dump though, >> so something else mysteriously is going on that I can't track. >> >> So, just to simplify: >> >> first_try := True >> >> while gdb is running: >> if prompt_for_coredump() and first_try is True: >> panic() >> first_try := False >> >> Thanks, >> -Garrett >> > > Ok, I've been doing some more poking around this weekend, and here's > what I discovered: > > - I've rebuilt my xorg-server a few times and it's still claiming that > it was built with 7.1-RC2 -_-... > - I can get the Xorg server to go full tilt by just compiling > something, like buildworld, via an xterm. > I also experienced this, but not only with the mentioned 'nv' driver, also with 'vesa'. Compiling a kernel or making buildworld, even with no -jX option, turns the box sometimes in a state of unresponseness. Mouse jumping, no keyboard response, sometimes for more than a minute. This happens on a FBSD 8.0-CUR/AMD64 UP box and it also happens on a FreeBSD 7.1-STABLE box (also amd64, 4 cores). But on SMP boxes I reralized that the problem does not impact that harsh as seen on UP boxes. We also had several P4 32bit machines with HTT enabled around, one of them was built with FreeBSD 7.1-STABLE AND Xorg and I never realized the bumpy X11, even when disabling HTT and running UP and Xorgs vesa driver. Well, it also seems to make no difference whether I use USB2 stack (in FreeBSD 8) or the old one. > - I can't attach truss to Xorg, or the Xorg will livelock. > > Now, trying out the nv driver: > - It constantly uses up ~20% CPU on one of my four cores. When I > compile something it chews up ~50% CPU. > The same on FreeBSD 8.0-CUR, recently built with a fresh install of xorg out of the ports! > - I can attach truss to Xorg, but it drags the CPU up to ~100%. Xorg > was spending a LOT of time pinging socket data around, which makes me > think that what the nvidia driver is doing is actually unrooting a > performance issue with the IPC mechanism in Xorg, as nv suffers from > the same thing, just on a less grand scale; mind you, I can get both > of my screens up and running under nvidia at different resolutions -- > 1920x1200 and 1680 x 1050 -- but under nv I only get 2 displays setup > at 1680 x 1050. > - Detaching truss causes the livelock condition (again). > > Rebuilding xorg-server has proven to help so far. I did > delete-old-files, and it appears that xorg-server may have been > picking up some old libraries still. > > Let's see if this sticks or not... > > Cheers, > -Garrett > _______________________________________________ > 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" > Oliver From hselasky at c2i.net Tue Jan 13 04:25:00 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Tue Jan 13 04:25:13 2009 Subject: hints on setting up usb cdma modem? In-Reply-To: <+BE8V3eWlNumNoeRVXGwF9oosbU@Nxyl89WskzuM4RJ7pF/cdJZbOMo> References: <33615c8e0901121328h5e594c7fw43ff42943baf70d0@mail.gmail.com> <+BE8V3eWlNumNoeRVXGwF9oosbU@Nxyl89WskzuM4RJ7pF/cdJZbOMo> Message-ID: <200901131326.49448.hselasky@c2i.net> On Tuesday 13 January 2009, Eygene Ryabinkin wrote: > Mon, Jan 12, 2009 at 04:28:12PM -0500, Rohit Tripathi wrote: > > I'm running current and after many failed attempts to setup my Novatel > > U727, I'm posting here with whatever information could be of interest. > > > > When the modem is plugged in: > > > > umass0: > 1.10/0.00, addr 2> on uhub3 > > cd0 at umass-sim0 bus 0 target 0 lun 0 > > cd0: Removable CD-ROM SCSI-2 device > > cd0: 1.000MB/s transfers > > cd0: Attempt to query device size failed: NOT READY, Medium not present > > It is not the ucom endpoint -- it is some mass-storage endpoint that > your modem seem to implement too. Or you showed us not all dmesg parts > that are related to your CDMA modem. Do you have /dev/cuaU* devices? > For the reference, mine CDMA modem attaches with the following dmesg > (it's not U727, but it is CDMA modem that is supported by ucom): > ----- > ucom0: 2.00/0.00, addr 2> on uhub5 ucom0: iclass 2/2 > ucom0: data interface 1, has CM over data, has break > ucom0: status change notification available > ---- > Hi, Also try: ugensa, if you are using USB2. grep -d recurse CMOTECH /sys/dev/usb2 --HPS From hselasky at c2i.net Tue Jan 13 04:25:00 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Tue Jan 13 04:25:14 2009 Subject: hints on setting up usb cdma modem? In-Reply-To: <+BE8V3eWlNumNoeRVXGwF9oosbU@Nxyl89WskzuM4RJ7pF/cdJZbOMo> References: <33615c8e0901121328h5e594c7fw43ff42943baf70d0@mail.gmail.com> <+BE8V3eWlNumNoeRVXGwF9oosbU@Nxyl89WskzuM4RJ7pF/cdJZbOMo> Message-ID: <200901131326.49448.hselasky@c2i.net> On Tuesday 13 January 2009, Eygene Ryabinkin wrote: > Mon, Jan 12, 2009 at 04:28:12PM -0500, Rohit Tripathi wrote: > > I'm running current and after many failed attempts to setup my Novatel > > U727, I'm posting here with whatever information could be of interest. > > > > When the modem is plugged in: > > > > umass0: > 1.10/0.00, addr 2> on uhub3 > > cd0 at umass-sim0 bus 0 target 0 lun 0 > > cd0: Removable CD-ROM SCSI-2 device > > cd0: 1.000MB/s transfers > > cd0: Attempt to query device size failed: NOT READY, Medium not present > > It is not the ucom endpoint -- it is some mass-storage endpoint that > your modem seem to implement too. Or you showed us not all dmesg parts > that are related to your CDMA modem. Do you have /dev/cuaU* devices? > For the reference, mine CDMA modem attaches with the following dmesg > (it's not U727, but it is CDMA modem that is supported by ucom): > ----- > ucom0: 2.00/0.00, addr 2> on uhub5 ucom0: iclass 2/2 > ucom0: data interface 1, has CM over data, has break > ucom0: status change notification available > ---- > Hi, Also try: ugensa, if you are using USB2. grep -d recurse CMOTECH /sys/dev/usb2 --HPS From christoph.mallon at gmx.de Tue Jan 13 04:34:38 2009 From: christoph.mallon at gmx.de (Christoph Mallon) Date: Tue Jan 13 04:34:44 2009 Subject: X becomes unresponsive with nvidia and hardlocks with gdb (was Re: X becomes unresponsive with nvidia / xscreensaver and desktop panics) In-Reply-To: <496C5F37.4070006@mail.zedat.fu-berlin.de> References: <7d6fde3d0901091705v6eb4c7bfxe23708f8651e2125@mail.gmail.com> <7d6fde3d0901111853k40f26893j722d95d3556c820@mail.gmail.com> <496C5F37.4070006@mail.zedat.fu-berlin.de> Message-ID: <496C8A59.6090301@gmx.de> O. Hartmann schrieb: > Garrett Cooper wrote: >> - I've rebuilt my xorg-server a few times and it's still claiming that >> it was built with 7.1-RC2 -_-... >> - I can get the Xorg server to go full tilt by just compiling >> something, like buildworld, via an xterm. >> > I also experienced this, but not only with the mentioned 'nv' driver, > also with 'vesa'. Compiling a kernel or making buildworld, even with no > -jX option, turns the box sometimes in a state of unresponseness. Mouse > jumping, no keyboard response, sometimes for more than a minute. This > happens on a FBSD 8.0-CUR/AMD64 UP box and it also happens on a FreeBSD > 7.1-STABLE box (also amd64, 4 cores). But on SMP boxes I reralized that > the problem does not impact that harsh as seen on UP boxes. > We also had several P4 32bit machines with HTT enabled around, one of > them was built with FreeBSD 7.1-STABLE AND Xorg and I never realized the > bumpy X11, even when disabling HTT and running UP and Xorgs vesa driver. > > Well, it also seems to make no difference whether I use USB2 stack (in > FreeBSD 8) or the old one. I regularly can observe that batch jobs like large compile jobs get a lower priority number (i.e. they get preferred by the scheduler) than X on my UP machine with SCHED_ULE (7.0-STABLE from early July). Just a bit X activity (switching desktops, scrolling in a browser etc.) is enough to make its priority number higher than that of make+gcc. This also causes interesting cascades like stuttering music: - gcc preferred over X - X cannot redraw xterm fast enough - buffer of xterm fills - mplayer cannot write its status line to xterm and blocks - because mplayer blocks it cannot feed more data to the sound device - music stutters From christoph.mallon at gmx.de Tue Jan 13 04:41:48 2009 From: christoph.mallon at gmx.de (Christoph Mallon) Date: Tue Jan 13 04:41:54 2009 Subject: X becomes unresponsive with nvidia and hardlocks with gdb (was Re: X becomes unresponsive with nvidia / xscreensaver and desktop panics) In-Reply-To: <496C8A59.6090301@gmx.de> References: <7d6fde3d0901091705v6eb4c7bfxe23708f8651e2125@mail.gmail.com> <7d6fde3d0901111853k40f26893j722d95d3556c820@mail.gmail.com> <496C5F37.4070006@mail.zedat.fu-berlin.de> <496C8A59.6090301@gmx.de> Message-ID: <496C8C09.3050204@gmx.de> Christoph Mallon schrieb: > This also causes interesting cascades like stuttering music: > - gcc preferred over X > - X cannot redraw xterm fast enough > - buffer of xterm fills > - mplayer cannot write its status line to xterm and blocks > - because mplayer blocks it cannot feed more data to the sound device > - music stutters I just realised that this is the classical priority inversion scenario: mplayer has a far higher priority than the compile job, but cannot run because it is waiting for X. This reminds me of the poor little mars probe Sojourner. From gavin.atkinson at ury.york.ac.uk Tue Jan 13 05:50:16 2009 From: gavin.atkinson at ury.york.ac.uk (Gavin Atkinson) Date: Tue Jan 13 05:50:27 2009 Subject: X unresponsive with SCHED_ULE (was: Re: X becomes unresponsive with nvidia and hardlocks with gdb) In-Reply-To: <496C8A59.6090301@gmx.de> References: <7d6fde3d0901091705v6eb4c7bfxe23708f8651e2125@mail.gmail.com> <7d6fde3d0901111853k40f26893j722d95d3556c820@mail.gmail.com> <496C5F37.4070006@mail.zedat.fu-berlin.de> <496C8A59.6090301@gmx.de> Message-ID: <1231854612.70382.15.camel@buffy.york.ac.uk> On Tue, 2009-01-13 at 13:34 +0100, Christoph Mallon wrote: > O. Hartmann schrieb: > > Garrett Cooper wrote: > >> - I've rebuilt my xorg-server a few times and it's still claiming that > >> it was built with 7.1-RC2 -_-... > >> - I can get the Xorg server to go full tilt by just compiling > >> something, like buildworld, via an xterm. > >> > > I also experienced this, but not only with the mentioned 'nv' driver, > > also with 'vesa'. Compiling a kernel or making buildworld, even with no > > -jX option, turns the box sometimes in a state of unresponseness. Mouse > > jumping, no keyboard response, sometimes for more than a minute. This > > happens on a FBSD 8.0-CUR/AMD64 UP box and it also happens on a FreeBSD > > 7.1-STABLE box (also amd64, 4 cores). But on SMP boxes I reralized that > > the problem does not impact that harsh as seen on UP boxes. > > We also had several P4 32bit machines with HTT enabled around, one of > > them was built with FreeBSD 7.1-STABLE AND Xorg and I never realized the > > bumpy X11, even when disabling HTT and running UP and Xorgs vesa driver. > > > > Well, it also seems to make no difference whether I use USB2 stack (in > > FreeBSD 8) or the old one. > > I regularly can observe that batch jobs like large compile jobs get a > lower priority number (i.e. they get preferred by the scheduler) than X > on my UP machine with SCHED_ULE (7.0-STABLE from early July). Just a bit > X activity (switching desktops, scrolling in a browser etc.) is enough > to make its priority number higher than that of make+gcc. Yes, ULE does still have a few issues, especially with jobs that should have a low priority getting the CPU when higher priority jobs should have it. This is especially noticeable with processes that want to use 100% cpu but are supposed to run at idprio (a good example is ports/misc/dnetc) - and is why my desktops are still using 4BSD. If you can retest with SCHED_4BSD, it would be worth doing so. Gavin From ohartman at mail.zedat.fu-berlin.de Tue Jan 13 06:49:01 2009 From: ohartman at mail.zedat.fu-berlin.de (O. Hartmann) Date: Tue Jan 13 07:22:29 2009 Subject: X becomes unresponsive with nvidia and hardlocks with gdb (was Re: X becomes unresponsive with nvidia / xscreensaver and desktop panics) In-Reply-To: <496C8A59.6090301@gmx.de> References: <7d6fde3d0901091705v6eb4c7bfxe23708f8651e2125@mail.gmail.com> <7d6fde3d0901111853k40f26893j722d95d3556c820@mail.gmail.com> <496C5F37.4070006@mail.zedat.fu-berlin.de> <496C8A59.6090301@gmx.de> Message-ID: <496CA9E3.90700@mail.zedat.fu-berlin.de> Christoph Mallon wrote: > O. Hartmann schrieb: >> Garrett Cooper wrote: >>> - I've rebuilt my xorg-server a few times and it's still claiming that >>> it was built with 7.1-RC2 -_-... >>> - I can get the Xorg server to go full tilt by just compiling >>> something, like buildworld, via an xterm. >>> >> I also experienced this, but not only with the mentioned 'nv' driver, >> also with 'vesa'. Compiling a kernel or making buildworld, even with no >> -jX option, turns the box sometimes in a state of unresponseness. Mouse >> jumping, no keyboard response, sometimes for more than a minute. This >> happens on a FBSD 8.0-CUR/AMD64 UP box and it also happens on a FreeBSD >> 7.1-STABLE box (also amd64, 4 cores). But on SMP boxes I reralized that >> the problem does not impact that harsh as seen on UP boxes. >> We also had several P4 32bit machines with HTT enabled around, one of >> them was built with FreeBSD 7.1-STABLE AND Xorg and I never realized the >> bumpy X11, even when disabling HTT and running UP and Xorgs vesa driver. >> >> Well, it also seems to make no difference whether I use USB2 stack (in >> FreeBSD 8) or the old one. > > I regularly can observe that batch jobs like large compile jobs get a > lower priority number (i.e. they get preferred by the scheduler) than > X on my UP machine with SCHED_ULE (7.0-STABLE from early July). Just a > bit X activity (switching desktops, scrolling in a browser etc.) is > enough to make its priority number higher than that of make+gcc. > This also causes interesting cascades like stuttering music: > - gcc preferred over X > - X cannot redraw xterm fast enough > - buffer of xterm fills > - mplayer cannot write its status line to xterm and blocks > - because mplayer blocks it cannot feed more data to the sound device > - music stutters ... try moving/draging a xterm rapidly over your screen while playing music, copying a file or encoding, decoding or even compiling something. In my case, suddenly those activities stop running. It is sometimes only noticable when listening to music. I realised those ghost-stops also without X11 - when high disk I/O and/or network I/O happens. This is even harsh on a NFS-server. As I mentioned, this is significantly on UP boxes, but can also be watched on some slower/older SMP hardware (both with FreeBSD 7.1-STABLE AND FreeBSD 8.0-CURRENT). From nick at van-laarhoven.org Tue Jan 13 07:28:34 2009 From: nick at van-laarhoven.org (Nick Hibma) Date: Tue Jan 13 07:28:45 2009 Subject: hints on setting up usb cdma modem? In-Reply-To: <+BE8V3eWlNumNoeRVXGwF9oosbU@Nxyl89WskzuM4RJ7pF/cdJZbOMo> References: <33615c8e0901121328h5e594c7fw43ff42943baf70d0@mail.gmail.com> <+BE8V3eWlNumNoeRVXGwF9oosbU@Nxyl89WskzuM4RJ7pF/cdJZbOMo> Message-ID: <200901131627.38073.nick@van-laarhoven.org> You might want to try the attached u3g.c driver file. I've not been able to verify that the switch mode command in it actually works as I have not had a report back. If your IDs for the unswitched and switched devices are not yet in u3g and/or usbdevs please add them. Let me know how things work! Nick > Mon, Jan 12, 2009 at 04:28:12PM -0500, Rohit Tripathi wrote: > > I'm running current and after many failed attempts to setup my Novatel > > U727, I'm posting here with whatever information could be of interest. > > > > When the modem is plugged in: > > > > umass0: > 1.10/0.00, addr 2> on uhub3 > > cd0 at umass-sim0 bus 0 target 0 lun 0 > > cd0: Removable CD-ROM SCSI-2 device > > cd0: 1.000MB/s transfers > > cd0: Attempt to query device size failed: NOT READY, Medium not present > > It is not the ucom endpoint -- it is some mass-storage endpoint that > your modem seem to implement too. Or you showed us not all dmesg parts > that are related to your CDMA modem. Do you have /dev/cuaU* devices? > For the reference, mine CDMA modem attaches with the following dmesg > (it's not U727, but it is CDMA modem that is supported by ucom): > ----- > ucom0: 2.00/0.00, addr 2> on uhub5 ucom0: iclass 2/2 > ucom0: data interface 1, has CM over data, has break > ucom0: status change notification available > ---- > > So, the basic questions are: > - had you compiled-in/kldloaded the ucom module? > - do you have ucom-related messages in dmesg? > - you might also need modules 'uplcom' and/or 'umodem' -- try them. From nick at van-laarhoven.org Tue Jan 13 07:40:35 2009 From: nick at van-laarhoven.org (Nick Hibma) Date: Tue Jan 13 07:40:46 2009 Subject: hints on setting up usb cdma modem? In-Reply-To: <+BE8V3eWlNumNoeRVXGwF9oosbU@Nxyl89WskzuM4RJ7pF/cdJZbOMo> References: <33615c8e0901121328h5e594c7fw43ff42943baf70d0@mail.gmail.com> <+BE8V3eWlNumNoeRVXGwF9oosbU@Nxyl89WskzuM4RJ7pF/cdJZbOMo> Message-ID: <200901131627.38073.nick@van-laarhoven.org> You might want to try the attached u3g.c driver file. I've not been able to verify that the switch mode command in it actually works as I have not had a report back. If your IDs for the unswitched and switched devices are not yet in u3g and/or usbdevs please add them. Let me know how things work! Nick > Mon, Jan 12, 2009 at 04:28:12PM -0500, Rohit Tripathi wrote: > > I'm running current and after many failed attempts to setup my Novatel > > U727, I'm posting here with whatever information could be of interest. > > > > When the modem is plugged in: > > > > umass0: > 1.10/0.00, addr 2> on uhub3 > > cd0 at umass-sim0 bus 0 target 0 lun 0 > > cd0: Removable CD-ROM SCSI-2 device > > cd0: 1.000MB/s transfers > > cd0: Attempt to query device size failed: NOT READY, Medium not present > > It is not the ucom endpoint -- it is some mass-storage endpoint that > your modem seem to implement too. Or you showed us not all dmesg parts > that are related to your CDMA modem. Do you have /dev/cuaU* devices? > For the reference, mine CDMA modem attaches with the following dmesg > (it's not U727, but it is CDMA modem that is supported by ucom): > ----- > ucom0: 2.00/0.00, addr 2> on uhub5 ucom0: iclass 2/2 > ucom0: data interface 1, has CM over data, has break > ucom0: status change notification available > ---- > > So, the basic questions are: > - had you compiled-in/kldloaded the ucom module? > - do you have ucom-related messages in dmesg? > - you might also need modules 'uplcom' and/or 'umodem' -- try them. From admin at lissyara.su Tue Jan 13 10:30:45 2009 From: admin at lissyara.su (Alex Keda) Date: Tue Jan 13 10:30:52 2009 Subject: About bwi Message-ID: <496CDDD8.6020704@lissyara.su> We want to know - that the driver bwi Are there any time limits may need some help feasible From admin at lissyara.su Tue Jan 13 10:40:39 2009 From: admin at lissyara.su (Alex Keda) Date: Tue Jan 13 10:40:47 2009 Subject: About bwi In-Reply-To: <496CDDD8.6020704@lissyara.su> References: <496CDDD8.6020704@lissyara.su> Message-ID: <496CE02A.5000002@lissyara.su> Alex Keda ?????: > We want to know - that the driver bwi > Are there any time limits may need some help feasible Explain =) We want to know - how to promote the development of the driver, is there a time frame for its appearance in the source tree? From sam at freebsd.org Tue Jan 13 10:51:59 2009 From: sam at freebsd.org (Sam Leffler) Date: Tue Jan 13 10:52:05 2009 Subject: About bwi In-Reply-To: <496CE02A.5000002@lissyara.su> References: <496CDDD8.6020704@lissyara.su> <496CE02A.5000002@lissyara.su> Message-ID: <496CE2CC.300@freebsd.org> Alex Keda wrote: > Alex Keda ??????????: >> We want to know - that the driver bwi >> Are there any time limits may need some help feasible > > Explain =) > We want to know - how to promote the development of the driver, is > there a time frame for its appearance in the source tree? I know of noone working on bwi. Until there's a developer willing to support/maintain the code it's unlikely to go in the tree. Sam From admin at lissyara.su Tue Jan 13 11:06:52 2009 From: admin at lissyara.su (Alex Keda) Date: Tue Jan 13 11:08:13 2009 Subject: About bwi In-Reply-To: <496CE2CC.300@freebsd.org> References: <496CDDD8.6020704@lissyara.su> <496CE02A.5000002@lissyara.su> <496CE2CC.300@freebsd.org> Message-ID: <496CE64F.3060703@lissyara.su> Sam Leffler ?????: > Alex Keda wrote: >> Alex Keda ??????????: >>> We want to know - that the driver bwi >>> Are there any time limits may need some help feasible >> >> Explain =) >> We want to know - how to promote the development of the driver, is >> there a time frame for its appearance in the source tree? > > I know of noone working on bwi. Until there's a developer willing to > support/maintain the code it's unlikely to go in the tree. Can you porting bwi from perforce to CURRENT? I know human who working with driver... Only porting. From jeremie at le-hen.org Tue Jan 13 12:42:09 2009 From: jeremie at le-hen.org (Jeremie Le Hen) Date: Tue Jan 13 12:42:22 2009 Subject: WITH_SSP in src.conf(5) breaks the build Message-ID: <20090113202046.GH41799@obiwan.tataz.chchile.org> Hi list, I'd like to have SSP MFC'd for 7.2. However, there is still a problem: WITH_SSP breaks the build if set in src.conf(5). See my previous mail explaining this below. On Thu, Sep 04, 2008 at 04:17:05PM +0200, Jeremie Le Hen wrote: > We indeed already have WITH_SSP/WITHOUT_SSP knob which is turned into > MK_SSP="yes" or MK_SSP="no" respectively. > > The actual problem lies in Makefiles that define WITHOUT_SSP for some > reason. For instance, in Makefile.inc1 the toolchain (namely > bootstrap-tools, build-tools, cross-tools and a few other things) is > built without SSP thanks to -DWITHOUT_SSP. For example: > > 224 BMAKE= MAKEOBJDIRPREFIX=${WORLDTMP} \ > 225 ${BMAKEENV} ${MAKE} -f Makefile.inc1 \ > 226 DESTDIR= \ > 227 BOOTSTRAPPING=${OSRELDATE} \ > 228 -DWITHOUT_SSP \ > 229 -DWITHOUT_HTML -DWITHOUT_INFO -DNO_LINT -DWITHOUT_MAN \ > 230 -DWITHOUT_NLS -DNO_PIC -DWITHOUT_PROFILE -DNO_SHARED \ > 231 -DNO_CPU_CFLAGS -DNO_WARNS -DNO_CTF > > There is a problem is the user defines WITH_SSP in src.conf or on > command-line. In this case, bsd.own.mk screams because both WITH_SSP > and WITHOUT_SSP are defined. The attached patch fixes this by using the trick proposed by Ruslan [1] where possible, or overriding SSP_CFLAGS otherwise. Once committed, I expect to provide a patch to introduce SSP for RELENG_7 a few weeks later. Thank you. Best regards, [1] http://lists.freebsd.org/pipermail/freebsd-hackers/2008-September/025891.html -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > -------------- next part -------------- A non-text attachment was scrubbed... Name: MK_SSP=no.diff Type: text/x-diff Size: 11575 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090113/78a746c0/MK_SSPno.bin From jeremie at le-hen.org Tue Jan 13 13:07:55 2009 From: jeremie at le-hen.org (Jeremie Le Hen) Date: Tue Jan 13 13:08:03 2009 Subject: fstab type "dp" Message-ID: <20090113210716.GI41799@obiwan.tataz.chchile.org> Hi, A year ago, I discussed with rwatson@ about having a new fs_type for dump devices. I initially implemented it as "du" but I later noticed that NetBSD already has this feature as "dp". I'd like to get some review about this patch in the hope of getting this patch eventually committed. This patch contains: - New fs_type "dp" for dump devices, along with "sw" for swap devices. - dumpon(8) and savecore(8) updated accordingly. - New dumpon(8) option -a that implements the logic to automatically select a correct dump devices by scanning fstab(5). The logic is backward compatible, that is if no "dp" entry is present, it will use the first "sw" entry. Also, etc/rc.d/dumpon has been modified to use this new option. - New dumpon(8) option -f to force the use of a device not marked as "dp" or "sw". This is a bonus. - Manpages updated. Note that both dumpon(8) and savecore(8) required the fs_vfstype to be "swap" for "sw" devices for "XXX backward compatibility". Despite this wasn't documented in the manpage, I didn't removed it and added "dump" as a valid fs_vfstype. The fstab(5) manpage still doesn't mention them though. Thank you. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From randy at psg.com Tue Jan 13 13:11:09 2009 From: randy at psg.com (Randy Bush) Date: Tue Jan 13 13:11:15 2009 Subject: GEOM and moving to CURRENT from 7.1 In-Reply-To: References: Message-ID: <496D0364.2060505@psg.com> installed amd64 7.1 from cdrom partitioned two sata drives to single partitions labeled and gmirrored upgraded to 8-current ad0 started falling off mirror ad2 started reporting smart errors and now we seem to have a partition that is too big # atacontrol cap ad2 Protocol Serial ATA v1.0 device model ST3250310NS serial number 9SF0LECT firmware revision SN05 cylinders 16383 heads 16 sectors/track 63 lba supported 268435455 sectors lba48 supported 488397168 sectors dma supported overlap not supported Feature Support Enable Value Vendor write cache yes yes read ahead yes yes Native Command Queuing (NCQ) yes - 31/0x1F Tagged Command Queuing (TCQ) no no 31/0x1F SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management no no 0/0x00 automatic acoustic management no no 0/0x00 254/0xFE # fdisk ad2 ******* Working on device /dev/ad2 ******* parameters extracted from in-core disklabel are: cylinders=484521 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=484521 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 488397105 (238475 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 168/ head 15/ sector 63 The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: randy From jeremie at le-hen.org Tue Jan 13 13:11:28 2009 From: jeremie at le-hen.org (Jeremie Le Hen) Date: Tue Jan 13 13:11:35 2009 Subject: fstab type "dp" In-Reply-To: <20090113210716.GI41799@obiwan.tataz.chchile.org> References: <20090113210716.GI41799@obiwan.tataz.chchile.org> Message-ID: <20090113211048.GJ41799@obiwan.tataz.chchile.org> On Tue, Jan 13, 2009 at 10:07:16PM +0100, Jeremie Le Hen wrote: > [...] And well, yes... The patch. -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > -------------- next part -------------- A non-text attachment was scrubbed... Name: fstab_dp.patch Type: text/x-diff Size: 10264 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090113/19bd16a2/fstab_dp.bin From kostikbel at gmail.com Tue Jan 13 13:24:08 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Tue Jan 13 13:24:16 2009 Subject: fstab type "dp" In-Reply-To: <20090113210716.GI41799@obiwan.tataz.chchile.org> References: <20090113210716.GI41799@obiwan.tataz.chchile.org> Message-ID: <20090113212355.GG2247@deviant.kiev.zoral.com.ua> On Tue, Jan 13, 2009 at 10:07:16PM +0100, Jeremie Le Hen wrote: > Hi, > > A year ago, I discussed with rwatson@ about having a new fs_type > for dump devices. I initially implemented it as "du" but I later > noticed that NetBSD already has this feature as "dp". > > I'd like to get some review about this patch in the hope of getting this > patch eventually committed. > > This patch contains: > - New fs_type "dp" for dump devices, along with "sw" for swap devices. > - dumpon(8) and savecore(8) updated accordingly. > - New dumpon(8) option -a that implements the logic to automatically > select a correct dump devices by scanning fstab(5). The logic is > backward compatible, that is if no "dp" entry is present, it will use > the first "sw" entry. Also, etc/rc.d/dumpon has been modified to use > this new option. > - New dumpon(8) option -f to force the use of a device not marked as > "dp" or "sw". This is a bonus. > - Manpages updated. > > Note that both dumpon(8) and savecore(8) required the fs_vfstype to be > "swap" for "sw" devices for "XXX backward compatibility". Despite this > wasn't documented in the manpage, I didn't removed it and added "dump" > as a valid fs_vfstype. The fstab(5) manpage still doesn't mention them > though. What are the supposed advantages of this approach over the dumpdev variable in rc.conf ? I see that having whole partition usage configuration in fstab is natural, so the idea of the patch is probably right. One the other hand, is it possible to enchance this to allow specification of the swap partition that is also a dump partition, in fstab ? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090113/20805e3d/attachment.pgp From minimarmot at gmail.com Tue Jan 13 13:35:26 2009 From: minimarmot at gmail.com (Ben Kaduk) Date: Tue Jan 13 13:35:33 2009 Subject: GEOM and moving to CURRENT from 7.1 In-Reply-To: <496D0364.2060505@psg.com> References: <496D0364.2060505@psg.com> Message-ID: <47d0403c0901131335h46e7b151p3768de9a3e2c2027@mail.gmail.com> On Tue, Jan 13, 2009 at 4:11 PM, Randy Bush wrote: > installed amd64 7.1 from cdrom > partitioned two sata drives to single partitions > labeled and gmirrored > > upgraded to 8-current > ad0 started falling off mirror > ad2 started reporting smart errors Interesting. I have been seeing similar behavior when trying to update my 7.1-prerelase box to current, except that it seems to be random _which_ disk falls off the mirror. I'm also seeing panics if I try to stress the (then-degraded) mirror with the current kernel. The mirror is rock-solid with the 7.1-pre kernel. The panic is "initiate_write_inodeblock_ufs2: already started", and I've got some details of the other messages I've seen logged up here: http://stuff.mit.edu/afs/sipb.mit.edu/user/kaduk/freebsd/periphrasis/20090107/panic.txt I just added a new swap device, so I'll see if I can actually get a dump once the mirror rebuilds. -Ben Kaduk From rdivacky at freebsd.org Tue Jan 13 13:55:42 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Tue Jan 13 13:55:58 2009 Subject: [PATCH]: set C dialect when compiling world Message-ID: <20090113215520.GA29635@freebsd.org> hi in my effort to make world compile in gnu99 mode I'd like this patch to be commited: Index: bsd.sys.mk =================================================================== RCS file: /home/ncvs/src/share/mk/bsd.sys.mk,v retrieving revision 1.47 diff -u -r1.47 bsd.sys.mk --- bsd.sys.mk 23 Jul 2008 06:14:21 -0000 1.47 +++ bsd.sys.mk 13 Jan 2009 21:36:04 -0000 @@ -8,8 +8,11 @@ # for GCC: http://gcc.gnu.org/onlinedocs/gcc-3.0.4/gcc_3.html#IDX143 -.if !defined(NO_WARNS) && ${CC} != "icc" -. if defined(CSTD) +# the default is gnu89 for now +. if !defined(CSTD) +CSTD = gnu89 +. endif + . if ${CSTD} == "k&r" CFLAGS += -traditional . elif ${CSTD} == "c89" || ${CSTD} == "c90" @@ -23,7 +26,8 @@ . endif # -pedantic is problematic because it also imposes namespace restrictions #CFLAGS += -pedantic -. endif + +.if !defined(NO_WARNS) && ${CC} != "icc" . if defined(WARNS) . if ${WARNS} >= 1 CWARNFLAGS += -Wsystem-headers the rationale behind this: we set CSTD to gnu89 so typical {library|app|whatever} build gets added ".... -std=gnu89 ...." to its CFLAGS. the command line looks like this for example: cc -O2 -pipe -DMALLOC_PRODUCTION -march=native -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -DPOSIX_MISTAKE -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu89 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c getppid.S it's nicely hidden in the 4th line near the end ;) I want this to be able to easily switch the C dialect used for various parts of the world. We dont want to mess with expected C dialect of contributed software. Hence once I switch the default to gnu99 I can just put CSTD=gnu89 to cddl/Makefile etc. and be fine. note that this change is a nop as gcc defaults to gnu89 mode but we need it because of the intended switch to gnu89. comments? roman -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090113/74c771a5/attachment.pgp From eitanadlerlist at gmail.com Tue Jan 13 14:04:35 2009 From: eitanadlerlist at gmail.com (Eitan Adler) Date: Tue Jan 13 14:04:41 2009 Subject: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) In-Reply-To: <20090113044111.134EC1CC0B@ptavv.es.net> References: <20090113044111.134EC1CC0B@ptavv.es.net> Message-ID: <496D0FE5.1040903@gmail.com> > Smells like FUD to me. In all of my reading, I have never seen such a > claim. There may be some GPLv3 issues, but I seriously doubt this is > one. Which leads to my next question: why not upgrade? -- Eitan Adler "Security is increased by designing for the way humans actually behave." -Jakob Nielsen From rdivacky at freebsd.org Tue Jan 13 14:11:58 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Tue Jan 13 14:12:05 2009 Subject: [PATCH]: set C dialect when compiling world In-Reply-To: <20090113215520.GA29635@freebsd.org> References: <20090113215520.GA29635@freebsd.org> Message-ID: <20090113221127.GA31906@freebsd.org> On Tue, Jan 13, 2009 at 10:55:20PM +0100, Roman Divacky wrote: > hi > > in my effort to make world compile in gnu99 mode I'd like this > patch to be commited: > > Index: bsd.sys.mk > =================================================================== > RCS file: /home/ncvs/src/share/mk/bsd.sys.mk,v > retrieving revision 1.47 > diff -u -r1.47 bsd.sys.mk > --- bsd.sys.mk 23 Jul 2008 06:14:21 -0000 1.47 > +++ bsd.sys.mk 13 Jan 2009 21:36:04 -0000 > @@ -8,8 +8,11 @@ > > # for GCC: http://gcc.gnu.org/onlinedocs/gcc-3.0.4/gcc_3.html#IDX143 > > -.if !defined(NO_WARNS) && ${CC} != "icc" > -. if defined(CSTD) > +# the default is gnu89 for now > +. if !defined(CSTD) > +CSTD = gnu89 > +. endif > + CSTD += gnu89 of course :) > . if ${CSTD} == "k&r" > CFLAGS += -traditional > . elif ${CSTD} == "c89" || ${CSTD} == "c90" > @@ -23,7 +26,8 @@ > . endif > # -pedantic is problematic because it also imposes namespace restrictions > #CFLAGS += -pedantic > -. endif > + > +.if !defined(NO_WARNS) && ${CC} != "icc" > . if defined(WARNS) > . if ${WARNS} >= 1 > CWARNFLAGS += -Wsystem-headers > > > the rationale behind this: > > we set CSTD to gnu89 so typical {library|app|whatever} build gets added > ".... -std=gnu89 ...." to its CFLAGS. the command line looks like this for > example: > > cc -O2 -pipe -DMALLOC_PRODUCTION -march=native -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include > -I/usr/src/lib/libc/i386 -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 > -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -DPOSIX_MISTAKE -I/usr/src/lib/libc/locale -DBROKEN_DES > -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu89 -fstack-protector > -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c getppid.S > > it's nicely hidden in the 4th line near the end ;) > > I want this to be able to easily switch the C dialect used for various parts of > the world. We dont want to mess with expected C dialect of contributed software. > Hence once I switch the default to gnu99 I can just put CSTD=gnu89 to cddl/Makefile > etc. and be fine. > > note that this change is a nop as gcc defaults to gnu89 mode but we need it because > of the intended switch to gnu89. switch to gnu99 of course thnx to Christoph Mallon for the corrections From brooks at freebsd.org Tue Jan 13 14:37:33 2009 From: brooks at freebsd.org (Brooks Davis) Date: Tue Jan 13 14:37:39 2009 Subject: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) In-Reply-To: <496D0FE5.1040903@gmail.com> References: <20090113044111.134EC1CC0B@ptavv.es.net> <496D0FE5.1040903@gmail.com> Message-ID: <20090113222023.GA51810@lor.one-eyed-alien.net> On Tue, Jan 13, 2009 at 05:04:21PM -0500, Eitan Adler wrote: > > Smells like FUD to me. In all of my reading, I have never seen such a > > claim. There may be some GPLv3 issues, but I seriously doubt this is > > one. > Which leads to my next question: why not upgrade? Given the number of FreeBSD using companies who are completely banned the presence of GPLv3 source from their sites, improvements would have to be extremely compelling and there would have to be a straight forward way to produce snapshots of the src tree with out any GPLv3 components as well as a simple way to build said source tree with a non-GPLv3 compiler. -- Brooks -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090113/8bebfee2/attachment.pgp From sobomax at FreeBSD.org Tue Jan 13 15:08:34 2009 From: sobomax at FreeBSD.org (Maxim Sobolev) Date: Tue Jan 13 15:08:41 2009 Subject: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) In-Reply-To: <20090113222023.GA51810@lor.one-eyed-alien.net> References: <20090113044111.134EC1CC0B@ptavv.es.net> <496D0FE5.1040903@gmail.com> <20090113222023.GA51810@lor.one-eyed-alien.net> Message-ID: <496D1ED6.4090202@FreeBSD.org> Brooks Davis wrote: > On Tue, Jan 13, 2009 at 05:04:21PM -0500, Eitan Adler wrote: >>> Smells like FUD to me. In all of my reading, I have never seen such a >>> claim. There may be some GPLv3 issues, but I seriously doubt this is >>> one. >> Which leads to my next question: why not upgrade? > > Given the number of FreeBSD using companies who are completely banned the > presence of GPLv3 source from their sites, improvements would have to > be extremely compelling and there would have to be a straight forward > way to produce snapshots of the src tree with out any GPLv3 components > as well as a simple way to build said source tree with a non-GPLv3 > compiler. Crazy idea perhaps, but can we make gcc 4.3 (as well as other GPLv3 components) an opt-in, just like we used to have crypto parts in the good old days when US was trying to limit export of this technology? Then can make both camps happy. Yes, it probably means that more efforts would be required to maintain it and keep code compatible with both versions, but since our current GPLv2 compiler is pretty much frozen it should not be much of the hassle as long as the initial work to support both versions have been done. -Maxim From onemda at gmail.com Tue Jan 13 15:14:09 2009 From: onemda at gmail.com (Paul B. Mahol) Date: Tue Jan 13 15:14:17 2009 Subject: About bwi In-Reply-To: <496CE64F.3060703@lissyara.su> References: <496CDDD8.6020704@lissyara.su> <496CE02A.5000002@lissyara.su> <496CE2CC.300@freebsd.org> <496CE64F.3060703@lissyara.su> Message-ID: <3a142e750901131514i9473a56u9c886bbe8eb635b5@mail.gmail.com> On 1/13/09, Alex Keda wrote: > Sam Leffler pishet: >> Alex Keda wrote: >>> Alex Keda D-?D-,N^D-uN': >>>> We want to know - that the driver bwi >>>> Are there any time limits may need some help feasible >>> >>> Explain =) >>> We want to know - how to promote the development of the driver, is >>> there a time frame for its appearance in the source tree? >> >> I know of noone working on bwi. Until there's a developer willing to >> support/maintain the code it's unlikely to go in the tree. > Can you porting bwi from perforce to CURRENT? > I know human who working with driver... > Only porting. > _______________________________________________ > 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" > It actually was ported, and sources for 8.0-CURRENT was available for testing(and probably still is). Last time I checked it, bwi was still in perforce but development stopped. On other hand bwi have its own bugs (performance was suboptimal in my environment) and development of driver itself is in stagnation. Not mentioning imposibility for supporting newer broadcom chips. -- Paul From dickey at radix.net Tue Jan 13 15:47:01 2009 From: dickey at radix.net (Thomas Dickey) Date: Tue Jan 13 15:47:11 2009 Subject: [RFC]: flex/lex update In-Reply-To: <20090113100623.493b3b43.stas@FreeBSD.org> References: <20090112200128.GA85280@freebsd.org> <20090113100623.493b3b43.stas@FreeBSD.org> Message-ID: <20090113233353.GA24233@saltmine.radix.net> On Tue, Jan 13, 2009 at 10:06:23AM +0300, Stanislav Sedov wrote: > On Mon, 12 Jan 2009 21:01:28 +0100 > Roman Divacky mentioned: > > > hi > > > > I noticed there is an update to lex/flex. The version in our tree > > is ancient and there seems to be some updates (http://flex.sourceforge.net/) > > > > Can someone comment on the state of lex in our tree? It's not considered > > a contributed software (it resides in usr.bin) but it was taken from elsewhere. > > > > what is our position? is it preferable for me to work on updating it or > > just fixing the one bug I ran into? > > Are there any benefits in updating? Does it worth the hassle? We have this > version of flex in ports for those who needs extended features. The newer version will break some existing programs (for instance, the last time I looked, it had broken the %option lines) - which is one of the reasons I chose to work on "old" flex: http://invisible-island.net/reflex/reflex.html > If there're no critical echancements/fixes in the updated flex version I'd > prefer to stay with what we have and just fix the bugs encountered locally. You've probably best off leaving the base flex as-is (ports are always a different matter). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090113/d9b9600b/attachment.pgp From ken at mthelicon.com Tue Jan 13 15:56:45 2009 From: ken at mthelicon.com (Pegasus Mc Cleaft) Date: Tue Jan 13 15:56:52 2009 Subject: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) In-Reply-To: <496D1ED6.4090202@FreeBSD.org> References: <20090113044111.134EC1CC0B@ptavv.es.net> <20090113222023.GA51810@lor.one-eyed-alien.net> <496D1ED6.4090202@FreeBSD.org> Message-ID: <200901132356.40820.ken@mthelicon.com> On Tuesday 13 January 2009 23:08:06 Maxim Sobolev wrote: > Brooks Davis wrote: > > On Tue, Jan 13, 2009 at 05:04:21PM -0500, Eitan Adler wrote: > >>> Smells like FUD to me. In all of my reading, I have never seen such a > >>> claim. There may be some GPLv3 issues, but I seriously doubt this is > >>> one. > >> > >> Which leads to my next question: why not upgrade? > > > > Given the number of FreeBSD using companies who are completely banned the > > presence of GPLv3 source from their sites, improvements would have to > > be extremely compelling and there would have to be a straight forward > > way to produce snapshots of the src tree with out any GPLv3 components > > as well as a simple way to build said source tree with a non-GPLv3 > > compiler. > > Crazy idea perhaps, but can we make gcc 4.3 (as well as other GPLv3 > components) an opt-in, just like we used to have crypto parts in the > good old days when US was trying to limit export of this technology? > Then can make both camps happy. Yes, it probably means that more efforts > would be required to maintain it and keep code compatible with both > versions, but since our current GPLv2 compiler is pretty much frozen it > should not be much of the hassle as long as the initial work to support > both versions have been done. > > -Maxim At the moment you can already compile gcc 4.3 from the ports tree, however things like binutils only seems to exist in the ports as a cross compiling tool. How hard would it be to add binutils as a port and make the gcc 4.x ports dependent on it? This way you can install gcc 4.3 with the assembler and linker that play nice together during the build? At the moment, I have had to make binutils from a gnu downloaded source and then make gcc 4.3 with a silly make, IE: make AS=/usr/local/bin/as .......... Unless the makers of gcc 4.3 changed this, I had all sorts of compiling problems when a port was using g++ due to headers that were not included by default (that g++ 4.2 did). I would imagine there would be a lot of rework to do in the ports tree making it happy. Once you get a happy and stable 4.3 (and later) installed on your machine, its just a simple change in the make.conf to choose what compiler you want to use. Would this approach get around the need to have 4.3 installed as a BSD default? Peg From jeremie at le-hen.org Tue Jan 13 17:11:36 2009 From: jeremie at le-hen.org (Jeremie Le Hen) Date: Tue Jan 13 17:11:44 2009 Subject: fstab type "dp" In-Reply-To: <20090113212355.GG2247@deviant.kiev.zoral.com.ua> References: <20090113210716.GI41799@obiwan.tataz.chchile.org> <20090113212355.GG2247@deviant.kiev.zoral.com.ua> Message-ID: <20090114011055.GK41799@obiwan.tataz.chchile.org> Dear Kostik, On Tue, Jan 13, 2009 at 11:23:55PM +0200, Kostik Belousov wrote: > What are the supposed advantages of this approach over the dumpdev > variable in rc.conf ? I see that having whole partition usage > configuration in fstab is natural, so the idea of the patch is > probably right. This is exactly the point. fstab(5) will describe every partition usage. > One the other hand, is it possible to enchance > this to allow specification of the swap partition that is also > a dump partition, in fstab ? Well, actually I think it makes more sense to automatically add "dp" device as swap. You will find an updated patch attached where swapon(8) has been modified to implement this behaviour. Is it better now? Thank you. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > -------------- next part -------------- A non-text attachment was scrubbed... Name: fstab_dp_2.patch Type: text/x-diff Size: 12223 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090114/c2bee101/fstab_dp_2.bin From max at love2party.net Tue Jan 13 18:20:31 2009 From: max at love2party.net (Max Laier) Date: Tue Jan 13 18:20:39 2009 Subject: fstab type "dp" In-Reply-To: <20090114011055.GK41799@obiwan.tataz.chchile.org> References: <20090113210716.GI41799@obiwan.tataz.chchile.org> <20090113212355.GG2247@deviant.kiev.zoral.com.ua> <20090114011055.GK41799@obiwan.tataz.chchile.org> Message-ID: <200901140320.28524.max@love2party.net> On Wednesday 14 January 2009 02:10:55 Jeremie Le Hen wrote: > Dear Kostik, > > On Tue, Jan 13, 2009 at 11:23:55PM +0200, Kostik Belousov wrote: > > What are the supposed advantages of this approach over the dumpdev > > variable in rc.conf ? I see that having whole partition usage > > configuration in fstab is natural, so the idea of the patch is > > probably right. > > This is exactly the point. fstab(5) will describe every partition > usage. > > > One the other hand, is it possible to enchance > > this to allow specification of the swap partition that is also > > a dump partition, in fstab ? > > Well, actually I think it makes more sense to automatically add "dp" > device as swap. You will find an updated patch attached where swapon(8) > has been modified to implement this behaviour. Is it better now? I don't agree here. The point of having a dedicated dump device could be to not overwrite the state of the swap when dumping core. In addition, a dump device could double as a place for suspend to disk if/when we implement this - in this scenario it would also be required that the dump device does not hold valuable swap data. -- /"\ 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 sobomax at FreeBSD.org Tue Jan 13 20:06:13 2009 From: sobomax at FreeBSD.org (Maxim Sobolev) Date: Tue Jan 13 20:06:21 2009 Subject: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) In-Reply-To: <200901132356.40820.ken@mthelicon.com> References: <20090113044111.134EC1CC0B@ptavv.es.net> <20090113222023.GA51810@lor.one-eyed-alien.net> <496D1ED6.4090202@FreeBSD.org> <200901132356.40820.ken@mthelicon.com> Message-ID: <496D64A0.1090309@FreeBSD.org> Pegasus Mc Cleaft wrote: > Would this approach get around the need to have 4.3 installed as a BSD > default? Well, this is workaround not a solution. Sooner or later FreeBSD will hit some principal limitation of the current compiler, like for example it was in the old days of gcc 2.xx, when FreeBSD had stuck with version that was outdated by few years resulting in inability to use any more or less modern C++ code with the system compiler. Existing processors develop all the time (SSE 4.2 for example) and the new architectures emerge (Cell for example), so that it's just matter of time when it happens again. -Maxim From minimarmot at gmail.com Tue Jan 13 20:59:13 2009 From: minimarmot at gmail.com (Ben Kaduk) Date: Tue Jan 13 20:59:20 2009 Subject: GEOM and moving to CURRENT from 7.1 In-Reply-To: <47d0403c0901131335h46e7b151p3768de9a3e2c2027@mail.gmail.com> References: <496D0364.2060505@psg.com> <47d0403c0901131335h46e7b151p3768de9a3e2c2027@mail.gmail.com> Message-ID: <47d0403c0901132059x472f4cfdw56568854589c549b@mail.gmail.com> On Tue, Jan 13, 2009 at 4:35 PM, Ben Kaduk wrote: > On Tue, Jan 13, 2009 at 4:11 PM, Randy Bush wrote: >> installed amd64 7.1 from cdrom >> partitioned two sata drives to single partitions >> labeled and gmirrored >> >> upgraded to 8-current >> ad0 started falling off mirror >> ad2 started reporting smart errors > > Interesting. I have been seeing similar behavior when trying to > update my 7.1-prerelase box to current, except that it seems to be > random _which_ disk falls off the mirror. I'm also seeing panics if I > try to stress the (then-degraded) mirror with the current kernel. The > mirror is rock-solid with the 7.1-pre kernel. > > The panic is "initiate_write_inodeblock_ufs2: already started", and > I've got some details of the other messages I've seen logged up here: > http://stuff.mit.edu/afs/sipb.mit.edu/user/kaduk/freebsd/periphrasis/20090107/panic.txt > I just added a new swap device, so I'll see if I can actually get a dump once > the mirror rebuilds. Grr. I built a kernel with WITNESS and INVARIANTS, and though I get some (previously-reported, and apparently harmless) LORs on boot, I can no longer reproduce the gmirror failure or the panic. (The i/o scheduler is not too shabby, either, as I'm seeing something like 20MB/s on each disk with four parallel bonnie++ processes.) So ... a race condition, then? -Ben Kaduk From minimarmot at gmail.com Tue Jan 13 21:13:48 2009 From: minimarmot at gmail.com (Ben Kaduk) Date: Tue Jan 13 21:13:54 2009 Subject: GEOM and moving to CURRENT from 7.1 In-Reply-To: <47d0403c0901132059x472f4cfdw56568854589c549b@mail.gmail.com> References: <496D0364.2060505@psg.com> <47d0403c0901131335h46e7b151p3768de9a3e2c2027@mail.gmail.com> <47d0403c0901132059x472f4cfdw56568854589c549b@mail.gmail.com> Message-ID: <47d0403c0901132113g2c31b631o39408bf56ec101be@mail.gmail.com> On Tue, Jan 13, 2009 at 11:59 PM, Ben Kaduk wrote: > > Grr. I built a kernel with WITNESS and INVARIANTS, and though I get > some (previously-reported, and apparently harmless) LORs on boot, > I can no longer reproduce the gmirror failure or the panic. Actually, I appear to have rebooted into the old kernel at some point (it's been a busy day and I've been running around a lot). Sorry for the noise. -Ben Kaduk From adrian at freebsd.org Tue Jan 13 22:04:31 2009 From: adrian at freebsd.org (Adrian Chadd) Date: Tue Jan 13 22:04:38 2009 Subject: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) In-Reply-To: <496D64A0.1090309@FreeBSD.org> References: <20090113044111.134EC1CC0B@ptavv.es.net> <20090113222023.GA51810@lor.one-eyed-alien.net> <496D1ED6.4090202@FreeBSD.org> <200901132356.40820.ken@mthelicon.com> <496D64A0.1090309@FreeBSD.org> Message-ID: 2009/1/13 Maxim Sobolev : > Well, this is workaround not a solution. Sooner or later FreeBSD will hit > some principal limitation of the current compiler, like for example it was > in the old days of gcc 2.xx, when FreeBSD had stuck with version that was > outdated by few years resulting in inability to use any more or less modern > C++ code with the system compiler. Existing processors develop all the time > (SSE 4.2 for example) and the new architectures emerge (Cell for example), > so that it's just matter of time when it happens again. So have people actually done some tests with the latest gcc and the freebsd world/kernel and -demonstrated- a speedup with that? I'd be happy with a crappy but fast and standard compiler in /usr/src if it build the world and kernel and the kernel was within 5% or so of the hyper-optimised very-latest compiler. But then, I seem to have falled square in the "compilers can't do all the magic; stop writing crappy code" school who believes you should only need a magically awesome compiler for about 1% of your codebase, and the rest should just be well-written to start with. So I re-iterate. Why all of the discussion having the default compiler be something new and shiny, when those who need the performance gains can just install -that- compiler as a port and use that? Adrian From rohit.trip at gmail.com Tue Jan 13 22:28:46 2009 From: rohit.trip at gmail.com (Rohit Tripathi) Date: Tue Jan 13 22:28:53 2009 Subject: hints on setting up usb cdma modem? In-Reply-To: <+BE8V3eWlNumNoeRVXGwF9oosbU@Nxyl89WskzuM4RJ7pF/cdJZbOMo> References: <33615c8e0901121328h5e594c7fw43ff42943baf70d0@mail.gmail.com> <+BE8V3eWlNumNoeRVXGwF9oosbU@Nxyl89WskzuM4RJ7pF/cdJZbOMo> Message-ID: <33615c8e0901132228p4c2554e1h326a0248ac42cf08@mail.gmail.com> > It is not the ucom endpoint -- it is some mass-storage endpoint that > your modem seem to implement too. Or you showed us not all dmesg parts Yes, under Fedora, the moment I plug in my CDMA card, its built in storage drive is mounted first. I have to eject this drive before I could do anything. Something similar is happening under freebsd. > ----- > ucom0: on uhub5 > ucom0: iclass 2/2 > ucom0: data interface 1, has CM over data, has break > ucom0: status change notification available > ---- > > So, the basic questions are: > - had you compiled-in/kldloaded the ucom module? Yes, this was the very first thing I had tried before wandering off into usbd land > - do you have ucom-related messages in dmesg? Yes, but they seem to appear only after I give a reboot command....i.e. right before filesystems are being unmounted (which makes sense considering how we have to "free" up the mass-storage part before using the modem under fedora) > - you might also need modules 'uplcom' and/or 'umodem' -- try them. Yes I have tried these earlier, then I discovered usbd, ubsa, and now u3g (compiled and loaded, and yes entries for U727 are already there, thanks Nick!) but so far with my limited knowledge of FreebBSD I haven't been able to get any of it moving. Here's an approximate description of steps I took: 1. Update kernel src, remove ubsa from kernel config, and add u3g 2. Build, install, merge configs 3. Setup ppp according to instructions given on Nick's page: http://people.freebsd.org/~n_hibma/u3g.html 4. Plugin modem, plugout, and watch as nothing happens 5. Post on freebsd-current 6. Wait :) From christoph.mallon at gmx.de Tue Jan 13 23:32:16 2009 From: christoph.mallon at gmx.de (Christoph Mallon) Date: Tue Jan 13 23:32:23 2009 Subject: Question about panic in brelse() Message-ID: <496D94FD.9030300@gmx.de> Hi, I wrote this to hackers@ two days ago, but I got no response so far. Maybe somebody with some VFS experience sees it on this list. I observe a failed assertion in the VFS regarding a buffer. I investigated a bit and now I want to present my findings and I have a question: Assume I have a buffer with b_iocmd = BIO_WRITE b_ioflags = BIO_ERROR b_error = EIO b_flags = B_NOCACHE passed to brelse() in kern/vfs_bio.c[0]. - This particular combination of values (line 1144) causes BIO_ERROR to be cleared (line 1152) and B_DELWRI is set in bdirty() (line 1031, called in line 1153). - Because of B_NOCACHE (line 1343) this buffer gets moved to QUEUE_CLEAN (line 1349). Also B_INVAL gets set here (line 1345). - A few lines down (line 1375) bundirty() gets called because of B_INVAL and B_DELWRI. - bundirty() instantly panics because the buffer is not in QUEUE_NONE (line 1075). My question is: Is this a bug in brelse() or was the combination of flag B_NOCACHE with a failed write attempt (BIO_WRITE, BIO_ERROR, EIO) invalid when the buffer was passed to brelse()? Below is a dump of the buffer right when the assertion is triggered. If you want any further information about this issue, please tell me. Hopefully somebody can shed some light on this Christoph { b_bufobj = 0xffffff0030005e00, b_bcount = 16384, b_caller1 = 0x0, b_data = 0xfffffffea2c57000 "", b_error = 5, (EIO) b_iocmd = 2 '\002', (BIO_WRITE) b_ioflags = 2 '\002', (BIO_DONE) b_iooffset = 98304, b_resid = 16384, b_iodone = 0, b_blkno = 192, b_offset = 98304, b_bobufs = { tqe_next = 0x0, tqe_prev = 0xffffff0030005e40}, b_left = 0x0, b_right = 0x0, b_vflags = 0, b_freelist = { tqe_next = 0xfffffffe92d747c8, tqe_prev = 0xffffffff80d340f0 }, b_qindex = 1, (QUEUE_CLEAN) b_flags = 41092, (B_NOCACHE | b_INVAL | B_DELWRI | B_ASYNC) b_xflags = 33 '!', b_lock = { lock_object = { lo_name = 0xffffffff808d01b6 "bufwait", lo_flags = 91947008, lo_data = 0, lo_witness = 0xfffffffe40206180 }, lk_lock = 18446744073709551608, lk_timo = 0, lk_pri = 80 }, b_bufsize = 16384, b_runningbufspace = 0, b_kvabase = 0xfffffffea2c57000 "", b_kvasize = 16384, b_lblkno = 192, b_vp = 0xffffff0030005ce8, b_dirtyoff = 0, b_dirtyend = 0, b_rcred = 0x0, b_wcred = 0x0, b_saveaddr = 0xfffffffea2c57000, b_pager = {pg_reqpage = 0}, b_cluster = { cluster_head = { tqh_first = 0xfffffffe92d747c8, tqh_last = 0xfffffffe92d73ad0 }, cluster_entry = { tqe_next = 0xfffffffe92d747c8, tqe_prev = 0xfffffffe92d73ad0 } }, b_pages = { 0xffffff00de3ce5a0, 0xffffff00de3ce610, 0xffffff00de3ce680, 0xffffff00de3ce6f0, $0x0 }, b_npages = 4, b_dep = { lh_first = 0x0 }, b_fsprivate1 = 0x0, b_fsprivate2 = 0x0, b_fsprivate3 = 0x0, b_pin_count = 0 } [0] r183754 in head/, which is the latest version of kern/vfs_bio.c. From Yuriy.Tsibizov at gfk.com Wed Jan 14 00:14:43 2009 From: Yuriy.Tsibizov at gfk.com (Yuriy Tsibizov) Date: Wed Jan 14 00:14:49 2009 Subject: _rw_wlock_hard: recursing but non-recursive rw radix node head @ /usr/src/sys/net/route.c:831 Message-ID: Kip, this happens on fresh -CURRENT, with configuration similar to one described in http://docs.freebsd.org/cgi/mid.cgi?3a142e750812080658r645dc1c4sdd612585 fe9ad7d6 (wpa_supplicant is main suspect in triggering this panic). No crashdump / backtrace available. Somehow needlock!=0, and rnh is already locked. HW is Intel Atom D945GCLF2 (2core + HT enabled) + D-Link Atheros-based card with WPA and static ip. Yuriy From konfer at mikulas.com Wed Jan 14 01:10:49 2009 From: konfer at mikulas.com (Guli) Date: Wed Jan 14 01:10:56 2009 Subject: INET6 tcp md5 signature Message-ID: <496DAC15.30904@mikulas.com> Hello Is there anyone, who could merge this feature into CURENT / RELENG_7 please ? (we want use it for secured IPv6 BGP sessions in Quagga) http://people.freebsd.org/~bz/20080913-02-tcp-md5-ack-rst.diff Thanks for reply Jiri From sobomax at FreeBSD.org Wed Jan 14 01:40:32 2009 From: sobomax at FreeBSD.org (Maxim Sobolev) Date: Wed Jan 14 01:40:48 2009 Subject: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) In-Reply-To: References: <20090113044111.134EC1CC0B@ptavv.es.net> <20090113222023.GA51810@lor.one-eyed-alien.net> <496D1ED6.4090202@FreeBSD.org> <200901132356.40820.ken@mthelicon.com> <496D64A0.1090309@FreeBSD.org> Message-ID: <496DB2FB.6020406@FreeBSD.org> Adrian Chadd wrote: > So I re-iterate. Why all of the discussion having the default compiler > be something new and shiny, when those who need the performance gains > can just install -that- compiler as a port and use that? First of all let's make it clean that I did not tell anything about expecting any magic speed up by just dropping a new compiler in, at least not for the software in the base system. You are simply putting somebody's else words into my mouth. Anybody who has even small understanding of compiler technology understands that without major paradigm changes there is not much room for improvement left for better code generation in C language, especially for the kind of code we have in /usr/src. My point is that in 1-2 years from now our outdated compiler might get in the way of using new features in state of the art CPUs and porting FreeBSD to new architectures. If nothing else, some new ideas should come out of CPU/GPU fusion work and/or massively multi-core designs soon and they would likely to require some kind of compiler support. Also, outdated C++ could cause issues with importing 3rd party software to the base system. I am only one who still remember horrible base system compiler C++ performance during gcc 2.7x times and eventual painful upgrade that broke all third-party libraries and required everything to be recompiled? Not to mention important new features like TLS support, symbol versioning and so on. If my memory serves, all of them required some kind binutils/compiler upgrade. And I am pretty sure something else of similar importance will appear on radar relatively soon. I don't have the answer to the GPLv2 vs. GPLv3 compiler issue. My point is that anybody here who thinks that we can get away with stale compiler in the base system for a long period of time by just hiding head in the sand, ignoring the issue and doing nothing is fooling himself. IMHO it seems highly unlikely that some new kid on the block like llvm will be able to answer our problems. The argument that "it's good for Apple, it should be good for us" to me seems to be little out of touch with reality. First of all, Apple cares about significantly lesser number of architectures. They don't have IA64, Sparc or MIPS, they will probably drop PPC soon. Second, they have a capacity (read "big money") to port compiler to a new architecture, fix it as needed or extend it to support some features provided by never chips if they need to. We don't have that capacity. -Maxim From rdivacky at FreeBSD.org Wed Jan 14 01:49:35 2009 From: rdivacky at FreeBSD.org (Roman Divacky) Date: Wed Jan 14 01:49:46 2009 Subject: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) In-Reply-To: <496DB2FB.6020406@FreeBSD.org> References: <20090113044111.134EC1CC0B@ptavv.es.net> <20090113222023.GA51810@lor.one-eyed-alien.net> <496D1ED6.4090202@FreeBSD.org> <200901132356.40820.ken@mthelicon.com> <496D64A0.1090309@FreeBSD.org> <496DB2FB.6020406@FreeBSD.org> Message-ID: <20090114094913.GA70285@freebsd.org> > IMHO it seems highly unlikely that some new kid on the block like llvm > will be able to answer our problems. The argument that "it's good for > Apple, it should be good for us" to me seems to be little out of touch > with reality. First of all, Apple cares about significantly lesser > number of architectures. They don't have IA64, Sparc or MIPS, they will > probably drop PPC soon. Second, they have a capacity (read "big money") > to port compiler to a new architecture, fix it as needed or extend it to > support some features provided by never chips if they need to. We don't > have that capacity. llvm currently supports: X86 Sparc PowerPC Alpha IA64 ARM Mips CellSPU PIC16 XCore CBackend MSIL CppBackend From dougb at FreeBSD.org Wed Jan 14 03:25:06 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Wed Jan 14 03:25:12 2009 Subject: fstab type "dp" In-Reply-To: <20090113210716.GI41799@obiwan.tataz.chchile.org> References: <20090113210716.GI41799@obiwan.tataz.chchile.org> Message-ID: <496DC9FC.4060807@FreeBSD.org> Jeremie Le Hen wrote: > Hi, > > A year ago, I discussed with rwatson@ about having a new fs_type > for dump devices. I initially implemented it as "du" but I later > noticed that NetBSD already has this feature as "dp". As long as you don't break existing configurations (via rc.d) then I have no objection, and I think it's a good addition. Doug -- This .signature sanitized for your protection From dougb at FreeBSD.org Wed Jan 14 03:27:55 2009 From: dougb at FreeBSD.org (Doug Barton) Date: Wed Jan 14 03:28:01 2009 Subject: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) In-Reply-To: <200901132356.40820.ken@mthelicon.com> References: <20090113044111.134EC1CC0B@ptavv.es.net> <20090113222023.GA51810@lor.one-eyed-alien.net> <496D1ED6.4090202@FreeBSD.org> <200901132356.40820.ken@mthelicon.com> Message-ID: <496DCC38.4010809@FreeBSD.org> Pegasus Mc Cleaft wrote: > At the moment you can already compile gcc 4.3 from the ports tree, however > things like binutils only seems to exist in the ports as a cross compiling > tool. How hard would it be to add binutils as a port and make the gcc 4.x > ports dependent on it? This way you can install gcc 4.3 with the assembler and > linker that play nice together during the build? At the moment, I have had to > make binutils from a gnu downloaded source and then make gcc 4.3 with a silly > make, IE: make AS=/usr/local/bin/as .......... I think this would be an excellent approach. I am not sure I agree with the idea that we _must_ have a compiler toolchain in the base but it should definitely be possible to "replace" the toolchain in the base with one from ports with a minimum of hassle. Of course I'm aware that this will entail a non-trivial amount of work, not only in changing our existing infrastructure to some extent but also work to non-toolchain code so that it can work with newer versions of th build tools. However, if we are fortunate and one of the current BSDL contenders emerges down the road as a viable alternative to gcc most of the work necessary to make this change now will have to be done anyway. On the one hand I like the "BSD approach" of sticking with tools that work rather than constantly chasing the latest and greatest. However I think we can run the risk of becoming mired in our own success, and losing the agility that we'll need to keep things moving forward in what will only become a more dynamic environment. Doug -- This .signature sanitized for your protection From christoph.mallon at gmx.de Wed Jan 14 03:58:58 2009 From: christoph.mallon at gmx.de (Christoph Mallon) Date: Wed Jan 14 03:59:06 2009 Subject: Alternatives to gcc (was Re: gcc 4.3: when will it become standard compiler?) In-Reply-To: <496DCC38.4010809@FreeBSD.org> References: <20090113044111.134EC1CC0B@ptavv.es.net> <20090113222023.GA51810@lor.one-eyed-alien.net> <496D1ED6.4090202@FreeBSD.org> <200901132356.40820.ken@mthelicon.com> <496DCC38.4010809@FreeBSD.org> Message-ID: <496DD37E.5010900@gmx.de> Doug Barton schrieb: > Pegasus Mc Cleaft wrote: >> At the mo