Re: gptzfsboot error using HP Smart Array P410i Controller
Christoph Hoffmann writes: > Hello, > > The initial reboot followed the installation of ZFS-only version 5/28 system > reports error: > > Attempting Boot From Hard Drive (C:) > gptzfsboot: error 1 lba 32 > gptzfsboot: error 1 lba 1 > gptzfsboot: No ZFS pools located, can't boot The bug may be unrelated but try clang patches, too. http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026263.html http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026338.html ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [rfc] replacing /boot/kernel.old with a unique directory name
Freddie Cash writes:
> On Sat, Aug 13, 2011 at 12:51 PM, Alexander Best wrote:
>
>> hi there,
>>
>> i just had the following idea: how about instead of copying the current
>> kernel
>> to /boot/kernel.old and then installing the new one under /boot/kernel as
>> the
>> results of target installkernel, we create a unique directory name for the
>> old
>> kernel?
>>
>> something like /boot/kernel-r${revision}-${/dev/random}?
>>
>> that would let people not only boot the previous kernel, but all kernels
>> that
>> have been replaced by target installkernel. this would make tracking
>> issues,
>> which have been introduced by a certain commit much easier, imho.
>>
>> i don't think implementing this logic would be that difficult. the only
>> problem
>> i see is with ${/dev/random} in the case where people are running a kernel
>> without /dev/{u}random support.
>>
>
> A better method may be to use KODIR to install the *new* kernel to a unique
> directory via installkernel (make KERNCONF=SOMEKERNEL
> KODIR=/boot/SOMEKERNEL-rev-whatever installkernel) and then using "nextboot
> -k SOMEKERNEL-rev-whatever" to set that kernel as bootable on the next boot.
>
> You reboot, make sure everything works with SOMEKERNEL-rev-whatever, and
> then make that the default kernel (rm -rf /boot/kernel; cp -Rvp
> /boot/SOMEKERNEL-rev-whatever /boot/kernel; shutdown -r now).
[...]
nextboot needs write access in loader to reset kernel, which is only
available for ufs. So, forget about zfs and every other fs from
libstand(3), e.g. ext2fs, msdosfs, nfs.
bootonce is also only supported in gptboot (ufs), not gptzfsboot.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [rfc] replacing /boot/kernel.old with a unique directory name
Test Rat writes: > Eduardo Morras writes: > >> At 22:06 13/08/2011, Steven Hartland wrote: >>>> i just had the following idea: how about instead of copying the >>>> current kernel >>>>to /boot/kernel.old and then installing the new one under /boot/kernel as >>>>the >>>> results of target installkernel, we create a unique directory name >>>> for the old >>>>kernel? >>> >>>The default size of / is likely your biggest problem. >> >> Don't know how much compresable is /boot/kernel.old but tar with -z >> or -j may be a workaround. We can extract on demand and swap current >> /boot/kernel with new /boot/kernel. Other way of do it is link >> /boot/kernel to current kernel and update it, but i don't know >> (again) if it would work in single user mode. > > There is kgzldr that lets you boot compressed kernels. Try > > $ gzip /boot/kernel/* > $ reboot Nevermind, I've confused it with gzip support in loader, it also has bzip2 support which for some reason doesn't work for me bzf_read: BZ2_bzDecompress returned -3 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [rfc] replacing /boot/kernel.old with a unique directory name
Eduardo Morras writes: > At 22:06 13/08/2011, Steven Hartland wrote: >>> i just had the following idea: how about instead of copying the >>> current kernel >>>to /boot/kernel.old and then installing the new one under /boot/kernel as the >>> results of target installkernel, we create a unique directory name >>> for the old >>>kernel? >> >>The default size of / is likely your biggest problem. > > Don't know how much compresable is /boot/kernel.old but tar with -z > or -j may be a workaround. We can extract on demand and swap current > /boot/kernel with new /boot/kernel. Other way of do it is link > /boot/kernel to current kernel and update it, but i don't know > (again) if it would work in single user mode. There is kgzldr that lets you boot compressed kernels. Try $ gzip /boot/kernel/* $ reboot ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 9.0-BETA1/amd64 r224808: buildworld failure: ===> lib/clang/include (all), 1 error, *** Error code 2, 1 error, *** Error code 2, 1 error
Test Rat writes: [...] > Remaking `cat' > Results of making cat: > clang -O2 -pipe -O3 -Qunused-arguments -fcolor-diagnostics > -march=native -g -fno-omit-frame-pointer -std=gnu99 -fstack-protector > -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type > -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter > -Wcast-align -Wchar-subscripts -Winline -Wnested-externs > -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -o cat > cat.o > /home/foo/.cache/a/freebsd/tmp/usr/lib/libc.so: undefined reference to > `_nsyylex' > /home/foo/.cache/a/freebsd/tmp/usr/lib/libc.so: undefined reference to > `_nsyyin' > /home/foo/.cache/a/freebsd/tmp/usr/lib/libc.so: undefined reference to > `_nsyytext' > /home/foo/.cache/a/freebsd/tmp/usr/lib/libc.so: undefined reference to > `_nsyyerror' > /home/foo/.cache/a/freebsd/tmp/usr/lib/libc.so: undefined reference to > `_nsyylineno' > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > *** Error code 1 FYI, above error was tracked to broken /dev/stdout and fixed in r224842. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 9.0-BETA1/amd64 r224808: buildworld failure: ===> lib/clang/include (all), 1 error, *** Error code 2, 1 error, *** Error code 2, 1 error
"Hartmann, O." writes: > I run several boxes based on FreebSD 9.0-BETA1/amd64, compiled with > clang. Since yesterday, I run on all of these > machines into strange situations: buildworld won't build anymore, it > fails always on all boxes at > the very same position as showed by the error message below. I can > build and install a kernel, that's working all right. > [...] > ===> lib/clang/include (all) > 1 error > *** Error code 2 > 1 error > *** Error code 2 > 1 error The actual error should be there, too. If you build with multiple jobs use `-P' so the output would look like following which makes it more easy to notice. [...] ===> lib/clang/include (all) Remaking `libexec.all__D' Remaking `bin.all__D' Results of making libexec.all__D: ===> libexec (all) Remaking `all' Results of making all: ===> libexec/atrun (all) Remaking `atrun' Results of making atrun: clang -O2 -pipe -O3 -Qunused-arguments -fcolor-diagnostics -march=native -DATJOB_DIR=\"/var/at/jobs/\" -DLFILE=\"/var/at/jobs/.lockfile\" -DLOADAVG_MX=1.5 -DATSPOOL_DIR=\"/var/at/spool\" -DVERSION=\"2.9\" -DDAEMON_UID=1 -DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' -DDEFAULT_AT_QUEUE=\'c\' -DPERM_PATH=\"/var/at/\" -I/a/freebsd/libexec/atrun/../../usr.bin/at -I/a/freebsd/libexec/atrun -DLOGIN_CAP -DPAM -g -fno-omit-frame-pointer -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o atrun atrun.o gloadavg.o -lpam -lutil /home/foo/.cache/a/freebsd/tmp/usr/lib/libc.so: undefined reference to `_nsyylex' /home/foo/.cache/a/freebsd/tmp/usr/lib/libc.so: undefined reference to `_nsyyin' /home/foo/.cache/a/freebsd/tmp/usr/lib/libc.so: undefined reference to `_nsyytext' /home/foo/.cache/a/freebsd/tmp/usr/lib/libc.so: undefined reference to `_nsyyerror' /home/foo/.cache/a/freebsd/tmp/usr/lib/libc.so: undefined reference to `_nsyylineno' clang: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 Results of making bin.all__D: ===> bin (all) Remaking `all' Results of making all: ===> bin/cat (all) Remaking `cat.o' Results of making cat.o: clang -O2 -pipe -O3 -Qunused-arguments -fcolor-diagnostics -march=native -g -fno-omit-frame-pointer -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /a/freebsd/bin/cat/cat.c Remaking `cat.1.gz' Remaking `cat' Results of making cat: clang -O2 -pipe -O3 -Qunused-arguments -fcolor-diagnostics -march=native -g -fno-omit-frame-pointer -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -o cat cat.o /home/foo/.cache/a/freebsd/tmp/usr/lib/libc.so: undefined reference to `_nsyylex' /home/foo/.cache/a/freebsd/tmp/usr/lib/libc.so: undefined reference to `_nsyyin' /home/foo/.cache/a/freebsd/tmp/usr/lib/libc.so: undefined reference to `_nsyytext' /home/foo/.cache/a/freebsd/tmp/usr/lib/libc.so: undefined reference to `_nsyyerror' /home/foo/.cache/a/freebsd/tmp/usr/lib/libc.so: undefined reference to `_nsyylineno' clang: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Results of making cat.1.gz: gzip -cn /a/freebsd/bin/cat/cat.1 > cat.1.gz 1 error *** Error code 2 1 error *** Error code 2 2 errors *** Error code 2 1 error *** Error code 2 1 error ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: recent commit causes lock up
Alexander Best writes: > hi there, > > running r224715 i'm having no problems what so ever. after upgrading my kernel > to r224784, i'm experiencing fatal lock ups, where only a hard reset will > resolve the problem. > > the lock up happend two times while running chromium with only a decent number > of tabs (~ 5). also the lock up occured only after ~ 5 minutes uptime and an > uptime of chromium of only ~ 2 minutes. > > i've now reverted my kernel back to r224715 and everything's working again. Do you use x11/nvidia-driver? In r224778 fget(9) KPI changed which broke the port in src/nvidia_linux.c:linux_ioctl_nvidia(). It's probably only called when using linuxolator, e.g. flash plugin. Try below workaround. %% --- src/nvidia_linux.c~ +++ src/nvidia_linux.c @@ -26,6 +26,8 @@ #include "machine/../linux32/linux32_proto.h" #endif +#include + int linux_ioctl_nvidia(d_thread_t *, struct linux_ioctl_args *); int linux_ioctl_nvidia( @@ -37,7 +39,7 @@ int linux_ioctl_nvidia( int error; u_long cmd; -if ((error = fget(td, args->fd, &fp)) != 0) +if ((error = fget(td, args->fd, CAP_IOCTL, &fp)) != 0) return error; cmd = args->cmd; %% ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[bsdgrep] fgrepcomp(), ignore case and segfault with unicode locale
A quick test
$ env -i bsdgrep -Fi without_nls usr.bin/grep/grep.c
$ env -i gnugrep -Fi without_nls usr.bin/grep/grep.c
#ifndef WITHOUT_NLS
#ifndef WITHOUT_NLS
#ifndef WITHOUT_NLS
shows that bsd fgrep already fails to ignore case. And if you throw
a few more options to the mix it'd crash, e.g.
$ env -i LC_CTYPE=en_US.UTF-8 TERM=xterm bsdgrep --color -Fir without_nls
usr.bin/grep/
[...]
Program received signal SIGSEGV, Segmentation fault.
0x000801007ff2 in memchr (s=0x61167a, c=10, n=18446744073707490297) at
/usr/src/lib/libc/string/memchr.c:48
48 if (*p++ == (unsigned char)c)
(gdb) bt
#0 0x000801007ff2 in memchr (s=0x61167a, c=10, n=18446744073707490297)
at /usr/src/lib/libc/string/memchr.c:48
#1 0x000801007b03 in __sfvwrite (fp=0x801247770, uio=0x7fffd8f0) at
/usr/src/lib/libc/stdio/fvwrite.c:170
#2 0x000801007698 in fwrite (buf=0x608c03, size=18446744073709551606,
count=1, fp=0x801247770)
at /usr/src/lib/libc/stdio/fwrite.c:95
#3 0x00405498 in printline (line=0x7fffdb70, sep=58,
matches=0x7fffd990, m=9)
at /usr/src/usr.bin/grep/util.c:500
#4 0x00404f51 in procline (l=0x7fffdb70, nottext=0) at
/usr/src/usr.bin/grep/util.c:381
#5 0x0040489f in procfile (fn=0x80140b600
"usr.bin/grep/nls/es_ES.ISO8859-1.msg") at /usr/src/usr.bin/grep/util.c:239
#6 0x004044d7 in grep_tree (argv=0x7fffdd30) at
/usr/src/usr.bin/grep/util.c:163
#7 0x00403ea9 in main (argc=5, argv=0x7fffdd10) at
/usr/src/usr.bin/grep/grep.c:689
(gdb) bt f
#0 0x000801007ff2 in memchr (s=0x61167a, c=10, n=18446744073707490297)
at /usr/src/lib/libc/string/memchr.c:48
p = (const unsigned char *) 0x80
#1 0x000801007b03 in __sfvwrite (fp=0x801247770, uio=0x7fffd8f0) at
/usr/src/lib/libc/stdio/fvwrite.c:170
len = 18446744073709516159
p = 0x61167a ""
iov = (struct __siov *) 0x7fffd8f0
w = 880
s = 880
nl = 0x611679 "\n"
nlknown = 0
nldist = 0
#2 0x000801007698 in fwrite (buf=0x608c03, size=18446744073709551606,
count=1, fp=0x801247770)
at /usr/src/lib/libc/stdio/fwrite.c:95
n = 18446744073709551606
uio = {uio_iov = 0x7fffd8e0, uio_iovcnt = 1, uio_resid = -35457}
iov = {iov_base = 0x608c03, iov_len = 18446744073709551606}
#3 0x00405498 in printline (line=0x7fffdb70, sep=58,
matches=0x7fffd990, m=9)
at /usr/src/usr.bin/grep/util.c:500
a = 99
i = 9
n = 1
#4 0x00404f51 in procline (l=0x7fffdb70, nottext=0) at
/usr/src/usr.bin/grep/util.c:381
matches = {{rm_so = 0, rm_eo = 11}, {rm_so = 11, rm_eo = 22}, {rm_so
= 22, rm_eo = 33}, {rm_so = 33, rm_eo = 44}, {
rm_so = 44, rm_eo = 55}, {rm_so = 55, rm_eo = 66}, {rm_so = 66, rm_eo =
77}, {rm_so = 77, rm_eo = 88}, {rm_so = 88,
rm_eo = 99}, {rm_so = 21131328, rm_eo = 8}, {rm_so = -9696, rm_eo =
32767}, {rm_so = 16101362, rm_eo = 8}, {rm_so = 21131328,
rm_eo = 8}, {rm_so = 16103767, rm_eo = 0}, {rm_so = 37, rm_eo = 0},
{rm_so = 8, rm_eo = 0}, {rm_so = -9632, rm_eo = 32767}, {
rm_so = -8944, rm_eo = 32767}, {rm_so = -9664, rm_eo = 32767}, {rm_so =
16103767, rm_eo = 8}, {rm_so = 6327289, rm_eo = 0}, {
rm_so = 437, rm_eo = 0}, {rm_so = -9584, rm_eo = 10}, {rm_so = 6327200,
rm_eo = 0}, {rm_so = -9776, rm_eo = 0}, {
rm_so = 6327290, rm_eo = 0}, {rm_so = -9536, rm_eo = 32767}, {rm_so =
4204252, rm_eo = 0}, {rm_so = -9584, rm_eo = 32767}, {
rm_so = 6327200, rm_eo = 0}, {rm_so = -9352, rm_eo = 32767}, {rm_so =
21004392, rm_eo = 8}}
pmatch = {rm_so = 88, rm_eo = 99}
st = 99
i = 1
c = 1
m = 9
r = 0
#5 0x0040489f in procfile (fn=0x80140b600
"usr.bin/grep/nls/es_ES.ISO8859-1.msg") at /usr/src/usr.bin/grep/util.c:239
f = (struct file *) 0x801408068
sb = {st_dev = 745804815, st_ino = 171971, st_mode = 33188, st_nlink
= 1, st_uid = 1001, st_gid = 1001,
st_rdev = 4294967295, st_atim = {tv_sec = 1292381124, tv_nsec = 0}, st_mtim
= {tv_sec = 1280426577, tv_nsec = 0}, st_ctim = {
tv_sec = 1292381124, tv_nsec = 165601426}, st_size = 526, st_blocks = 2,
st_blksize = 4096, st_flags = 0, st_gen = 0,
st_lspare = 0, st_birthtim = {tv_sec = 1292381124, tv_nsec = 165601426}}
ln = {off = 0, len = 89,
dat = 0x608ba0 "$ $FreeBSD: head/usr.bin/grep/nls/es_ES.ISO8859-1.msg
210622 2010-07-29 18:02:57Z gabor $\n$\n$set 1\n$quote \"\n1 \"(entrada
estdar)\"\n2 \"no se puede leer el fichero comprimido bzip2\"\n3 \"opci
desconocid"...,
file = 0x801427040 "usr.bin/grep/nls/es_ES.ISO8859-1.msg", line_no = 1}
s = 32768
c = 0
t = 8
#6 0x004044d7 in grep_tree (argv=0x7fffdd30) at
/usr/src/usr.bin/grep/util.c:163
Re: awk(1) segfaults when building kernel modules
Ruslan Ermilov writes:
> On Wed, Aug 10, 2011 at 10:12:11PM +0400, Test Rat wrote:
>> `make -s buildkernel' seems to contain lots of segfaults after recent
>> update of one-true-awk in r224731. It chokes on sys/conf/kmod_syms.awk.
>> The case can be reduced to
>>
>> $ awk 'BEGIN { delete ARGV[1] } END { print ARGV[1] }' blah
>> [...]
>
> Should be fixed in r224776; please confirm.
Confirmed, it no longer crashes with either above example or when
building kernel modules.
--
FreeBSD 9.0-BETA1 r224776M amd64
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: makefs(8) & broken iso9660 images
Alexander Best writes: > On Wed Aug 10 11, Test Rat wrote: [...] >> $ find /media/usr/include >/dev/null >> find: /media/usr/include/c++/4.2/ext/pb_ds/detail/basic_tree_policy: >> Input/output error >> find: /media/usr/include/c++/4.2/ext/pb_ds/detail/binary_heap_: >> Input/output error >> find: /media/usr/include/c++/4.2/ext/pb_ds/detail/binomial_heap_: >> Input/output error >> find: /media/usr/include/c++/4.2/ext/pb_ds/detail/binomial_heap_base_: >> Input/output error >> find: /media/usr/include/c++/4.2/ext/pb_ds/detail/bin_search_tree_: >> Input/output error >> find: /media/usr/include/c++/4.2/ext/pb_ds/detail/cc_hash_table_map_: >> Input/output error >> find: /media/usr/include/c++/4.2/ext/pb_ds/detail/eq_fn: Input/output error >> find: /media/usr/include/c++/4.2/ext/pb_ds/detail/gp_hash_table_map_: >> Input/output error >> find: /media/usr/include/c++/4.2/ext/pb_ds/detail/hash_fn: Input/output >> error >> find: >> /media/usr/include/c++/4.2/ext/pb_ds/detail/left_child_next_sibling_heap_: >> Input/output error >> find: /media/usr/include/c++/4.2/ext/pb_ds/detail/list_update_map_: >> Input/output error >> find: /media/usr/include/c++/4.2/ext/pb_ds/detail/list_update_policy: >> Input/output error >> find: /media/usr/include/c++/4.2/ext/pb_ds/detail/ov_tree_map_: >> Input/output error >> find: /media/usr/include/c++/4.2/ext/pb_ds/detail/pairing_heap_: >> Input/output error >> find: /media/usr/include/c++/4.2/ext/pb_ds/detail/pat_trie_: Input/output >> error >> find: /media/usr/include/c++/4.2/ext/pb_ds/detail/rb_tree_map_: >> Input/output error >> find: /media/usr/include/c++/4.2/ext/pb_ds/detail/rc_binomial_heap_: >> Input/output error >> find: /media/usr/include/c++/4.2/ext/pb_ds/detail/resize_policy: >> Input/output error >> find: /media/usr/include/c++/4.2/ext/pb_ds/detail/splay_tree_: >> Input/output error >> find: /media/usr/include/c++/4.2/ext/pb_ds/detail/thin_heap_: Input/output >> error >> find: /media/usr/include/c++/4.2/ext/pb_ds/detail/tree_policy: >> Input/output error >> find: /media/usr/include/c++/4.2/ext/pb_ds/detail/trie_policy: >> Input/output error >> find: /media/usr/include/c++/4.2/ext/pb_ds/detail/unordered_iterator: >> Input/output error >> >> Am I alone in seeing this? > > was this fixed by rr224762? I guess only above IO errors, locally generated image produced different errors and they're gone. libarchive still has trouble reading it. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
awk(1) segfaults when building kernel modules
`make -s buildkernel' seems to contain lots of segfaults after recent
update of one-true-awk in r224731. It chokes on sys/conf/kmod_syms.awk.
The case can be reduced to
$ awk 'BEGIN { delete ARGV[1] } END { print ARGV[1] }' blah
[...]
Program received signal SIGSEGV, Segmentation fault.
0x0040b778 in isclvar (s=0x0) at
/usr/src/usr.bin/awk/../../contrib/one-true-awk/lib.c:674
674 if (!isalpha((uschar) *s) && *s != '_')
(gdb) bt
#0 0x0040b778 in isclvar (s=0x0) at
/usr/src/usr.bin/awk/../../contrib/one-true-awk/lib.c:674
#1 0x004092d7 in initgetrec () at
/usr/src/usr.bin/awk/../../contrib/one-true-awk/lib.c:92
#2 0x00409397 in getrec (pbuf=0x6267e0, pbufsize=0x6248a8,
isrecord=1)
at /usr/src/usr.bin/awk/../../contrib/one-true-awk/lib.c:113
#3 0x0040cd73 in program (a=0x8010830e8, n=258) at
/usr/src/usr.bin/awk/../../contrib/one-true-awk/run.c:193
#4 0x0040cbd0 in execute (u=0x8010830d0) at
/usr/src/usr.bin/awk/../../contrib/one-true-awk/run.c:162
#5 0x0040caaa in run (a=0x8010830d0) at
/usr/src/usr.bin/awk/../../contrib/one-true-awk/run.c:137
#6 0x0040bf85 in main (argc=2, argv=0x7fffd290) at
/usr/src/usr.bin/awk/../../contrib/one-true-awk/main.c:183
Anyone else?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
makefs(8) & broken iso9660 images
A quick example $ mkdir -p q/a q/b q/c q/d $ touch q/a/foo.c q/b/foo.c q/c/foo.c q/d/foo.c $ makefs -t cd9660 q.iso q $ tar tf q.iso . A B A/FOO.C B/FOO.C C D $ mkisofs -quiet -o q.iso q $ tar tf q.iso . A B C D D/FOO.C C/FOO.C B/FOO.C A/FOO.C $ makefs -t cd9660 inc.iso /usr/include $ tar tvvf inc.iso tar: Invalid location of extent of file Archive Format: ISO9660, Compression: none tar: Error exit delayed from previous errors. $ mkisofs -quiet -o inc.iso /usr/include mkisofs: Symlink /usr/include/float.h ignored - continuing. mkisofs: Symlink /usr/include/syslog.h ignored - continuing. mkisofs: Symlink /usr/include/sched.h ignored - continuing. [...] $ tar tvvf inc.iso drwx-- 54 0 0 12288 Aug 10 15:26 . drwx-- 2 0 02048 Jun 14 01:40 NETATALK [...] -r 1 0 06324 Jun 14 01:40 GSSAPI/GSSAPI_K.H Archive Format: ISO9660, Compression: none And for more real example grab a bootonly image from allbsd.org though official BETA1 would suffice, too, and try to extract kernel e.g. $ sha256 -q FreeBSD-9.0-HEAD-20110810-JPSNAP-bootonly.iso 9b8beabe007f88f85f3fc59dd1b40ce212132dde173e03d4a93d48a5477989a4 $ tar tf FreeBSD-9.0-HEAD-20110810-JPSNAP-bootonly.iso | fgrep -i kernel [nothing] $ mount -t cd9660 /dev/$(mdconfig -f FreeBSD-9.0-HEAD-20110810-JPSNAP-bootonly.iso) /media $ ls -1 /media/boot/kernel aac.ko accf_data.ko accf_dns.ko accf_http.ko acpi_asus.ko acpi_dock.ko acpi_fujitsu.ko acpi_hp.ko acpi_ibm.ko acpi_panasonic.ko ^C And the following is probably known but doesn't happen with 8.2-RELEASE image. $ find /media/usr/include >/dev/null find: /media/usr/include/c++/4.2/ext/pb_ds/detail/basic_tree_policy: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/binary_heap_: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/binomial_heap_: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/binomial_heap_base_: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/bin_search_tree_: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/cc_hash_table_map_: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/eq_fn: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/gp_hash_table_map_: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/hash_fn: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/left_child_next_sibling_heap_: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/list_update_map_: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/list_update_policy: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/ov_tree_map_: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/pairing_heap_: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/pat_trie_: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/rb_tree_map_: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/rc_binomial_heap_: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/resize_policy: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/splay_tree_: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/thin_heap_: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/tree_policy: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/trie_policy: Input/output error find: /media/usr/include/c++/4.2/ext/pb_ds/detail/unordered_iterator: Input/output error Am I alone in seeing this? -- FreeBSD 9.0-BETA1 r224746M amd64, clang-built ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [bsdgrep] --exclude-dir doesn't work
Test Rat writes:
> It seems fnmatch(3) args were accidentally swapped. Try
>
> $ bsdgrep -Fr --exclude-dir '*.svn*' grep_ usr.bin/grep | bsdgrep -c svn
> 72
And it should probably use FTS_SKIP to save time like textproc/gnugrep.
# turn off caching before testing
$ zfs set primarycache=none ...
$ zfs set secondarycache=none ...
$ time bsdgrep -Fr --exclude-dir .svn blah /usr/src/sys
$ time /usr/local/bin/grep -Fr --exclude-dir .svn blah /usr/src/sys
%%
Index: usr.bin/grep/util.c
===
--- usr.bin/grep/util.c (revision 224746)
+++ usr.bin/grep/util.c (working copy)
@@ -103,7 +103,6 @@ grep_tree(char **argv)
{
FTS *fts;
FTSENT *p;
- char *d, *dir = NULL;
int c, fts_flags;
bool ok;
@@ -135,6 +134,10 @@ grep_tree(char **argv)
case FTS_D:
/* FALLTHROUGH */
case FTS_DP:
+ if (dexclude || dinclude)
+ if (!dir_matching(p->fts_name) ||
+ !dir_matching(p->fts_path))
+ fts_set(fts, p, FTS_SKIP);
break;
case FTS_DC:
/* Print a warning for recursive directory loop */
@@ -144,18 +147,6 @@ grep_tree(char **argv)
default:
/* Check for file exclusion/inclusion */
ok = true;
- if (dexclude || dinclude) {
- if ((d = strrchr(p->fts_path, '/')) != NULL) {
- dir = grep_malloc(sizeof(char) *
- (d - p->fts_path + 1));
- memcpy(dir, p->fts_path,
- d - p->fts_path);
- dir[d - p->fts_path] = '\0';
- }
- ok = dir_matching(dir);
- free(dir);
- dir = NULL;
- }
if (fexclude || finclude)
ok &= file_matching(p->fts_path);
%%
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[bsdgrep] --exclude-dir doesn't work
It seems fnmatch(3) args were accidentally swapped. Try
$ bsdgrep -Fr --exclude-dir '*.svn*' grep_ usr.bin/grep | bsdgrep -c svn
72
%%
Index: usr.bin/grep/util.c
===
--- usr.bin/grep/util.c (revision 224705)
+++ usr.bin/grep/util.c (working copy)
@@ -84,7 +84,7 @@ dir_matching(const char *dname)
for (unsigned int i = 0; i < dpatterns; ++i) {
if (dname != NULL &&
- fnmatch(dname, dpattern[i].pat, 0) == 0) {
+ fnmatch(dpattern[i].pat, dname, 0) == 0) {
if (dpattern[i].mode == EXCL_PAT)
return (false);
else
%%
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: issues with bsdgrep and lang/go
Alexander Best writes:
> On Tue Aug 9 11, Test Rat wrote:
>> Alexander Best writes:
>>
>> [...]
>> > gmake -C 6g install
>> > gmake[1]: Entering directory
>> > `/usr/ports/lang/go/work/go-20110515/src/cmd/6g'
>> > quietgcc -I"/usr/ports/lang/go/work/go-20110515/include" -ggdb -O2 -c
>> > "/usr/ports/lang/go/work/go-20110515/src/cmd/6g/list.c"
>> > egrep: : error: .Each undeclared identifier|: error: for each function
>> > it appears|is dangerous, better use|is almost always misused|: In
>> > function |: At top level: |In file included from| from: No such file
>> > or directory
>>
>> Do you use GREP_OPTIONS?
>
> otaku% type $GREP_OPTIONS
> otaku% echo foo | env -i GREP_OPTIONS= bsdgrep foo
> env: bsdgrep: No such file or directory
> otaku%
Actually, it's lang/go that seems to set the environment variable.
$ fgrep -r GREP_OPTIONS $(make -V WRKSRC)
.../src/cmd/gc/mkopnames:export GREP_OPTIONS=""
.../src/Make.inc:GREP_OPTIONS:=
.../src/Make.inc:export LANG LC_ALL LC_CTYPE GREP_OPTIONS GREP_COLORS
.../src/Make.inc: @echo export GREP_OPTIONS="$(GREP_OPTIONS)"
.../test/run:unset GREP_OPTIONS # in case user has a non-standard set
.../doc/devel/weekly.html:* build: clear custom variables like GREP_OPTIONS,
Try below workaround. It also makes empty GREP_COLOR behave like gnugrep(1).
%%
Index: usr.bin/grep/grep.c
===
--- usr.bin/grep/grep.c (revision 224705)
+++ usr.bin/grep/grep.c (working copy)
@@ -304,7 +304,7 @@ init_color(const char *d)
char *c;
c = getenv("GREP_COLOR");
- return (c != NULL ? c : d);
+ return (c != NULL && c[0] != '\0' ? c : d);
}
int
@@ -360,7 +360,7 @@ main(int argc, char *argv[])
/* support for extra arguments in GREP_OPTIONS */
eargc = 0;
- if (eopts != NULL) {
+ if (eopts != NULL && eopts[0] != '\0') {
char *str;
/* make an estimation of how many extra arguments we have */
@@ -373,6 +373,7 @@ main(int argc, char *argv[])
eargc = 0;
/* parse extra arguments */
while ((str = strsep(&eopts, " ")) != NULL)
+ if(*str != '\0')
eargv[eargc++] = grep_strdup(str);
aargv = (char **)grep_calloc(eargc + argc + 1,
%%
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: issues with bsdgrep and lang/go
Alexander Best writes: [...] > gmake -C 6g install > gmake[1]: Entering directory `/usr/ports/lang/go/work/go-20110515/src/cmd/6g' > quietgcc -I"/usr/ports/lang/go/work/go-20110515/include" -ggdb -O2 -c > "/usr/ports/lang/go/work/go-20110515/src/cmd/6g/list.c" > egrep: : error: .Each undeclared identifier|: error: for each function > it appears|is dangerous, better use|is almost always misused|: In > function |: At top level: |In file included from| from: No such file > or directory Do you use GREP_OPTIONS? $ echo foo | env -i GREP_OPTIONS= bsdgrep foo bsdgrep: foo: No such file or directory ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [clang] (gpt)zfsboot is broken: zfs_alloc()/zfs_free() mismatch
Dimitry Andric writes: > On 2011-08-05 07:08, Test Rat wrote: >> Pawel Worach writes: > ... >>> A workaround for the hang on boot and "error 1 lba X" failures is the >>> following patch, it would be interesting if it also makes the >>> zfs_alloc/free error go away too. >> After applying the patch zfsboot and gptzfsboot boot successfully. >> Tested both inside qemu and only gptzfsboot on a living system. > > Hi, > > Can you please try the following alternative patch, which should fix the > problem without disabling -mrtd? E.g. revert the previous patch, then > apply this one. It boots fine after applying either of patches. I've made sure the bug appeared again before testing the new patch. zfsboot and gptzfsboot built with gcc still boot, too. > Of course, if any other posters in this thread that had problems with > gptzfsboot (or 'plain' zfsboot) can also confirm this patch works, it > would be nice. :) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [clang] (gpt)zfsboot is broken: zfs_alloc()/zfs_free() mismatch
Pawel Worach writes: > On Aug 1, 2011, at 14:24, Test Rat wrote: > >> Anyone else? I can still reproduce with trunk r136607. >> boot and gptboot seem to be unaffected. >> >> IIRC, with previous clang import it just stuck during boot >> without any error messages. > > A workaround for the hang on boot and "error 1 lba X" failures is the > following patch, it would be interesting if it also makes the > zfs_alloc/free error go away too. [...] After applying the patch zfsboot and gptzfsboot boot successfully. Tested both inside qemu and only gptzfsboot on a living system. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ichwd0: unable to reserve GCS registers
John Baldwin writes: > Hmmm, so your BIOS just outright lies then? :( > > Can you check devinfo -u with 'debug.acpi.disabled=hostres' to see where > those memory addresses show up? I/O memory addresses: 0x0-0x9e7ff (ram0) 0x9e800-0x9 (root0) 0xa-0xb (vga0) 0xc-0xc (root0) 0xd-0xd17ff (orm0) 0xd1800-0xd1fff (root0) 0xd2000-0xd3fff (orm0) 0xd4000-0xd6fff (orm0) 0xd7000-0xd7fff (acpi0) 0xd8000-0xd (root0) 0xe-0xe (acpi0) 0xf-0xf7fff (acpi0) 0xf8000-0xfbfff (acpi0) 0xfc000-0xf (acpi0) 0x10-0xdfed (ram0) 0xdfee-0xdfef (acpi0) 0xdff0-0xdfff (root0) 0xe000-0xefff (pcib1) 0xf000-0xf3ff (acpi0) 0xf400-0xf7ff (pcib1) 0xf800-0xf9ff (pcib5) 0xfa00-0xfa0f (pcib3) 0xfa10-0xfa103fff (hdac0) 0xfa104000-0xfa1043ff (ehci1) 0xfa104400-0xfa104fff (root0) 0xfa105000-0xfa1053ff (ehci0) 0xfa105400-0xfa105fff (root0) 0xfa106000-0xfa1067ff (ahci1) 0xfa106800-0xfa106fff (root0) 0xfa107000-0xfa1070ff 0xfa107100-0xfebf (root0) 0xfec0-0xfec00fff (acpi0) 0xfec01000-0xfecf (root0) 0xfed0-0xfed003ff (hpet0) 0xfed00400-0xfed0 (root0) 0xfed1-0xfed1dfff (acpi0) -0xfed1e000-0xfed1f40f (root0) -0xfed1f410-0xfed1f413 (isab0) -0xfed1f414-0xfed1 (root0) +0xfed1e000-0xfed1 (root0) 0xfed2-0xfed8 (acpi0) 0xfed9-0xfedf (root0) 0xfee0-0xfee00fff (acpi0) 0xfee01000-0xffaf (root0) 0xffb0-0xffb7 (acpi0) 0xffb8-0xffbf 0xffc0-0xffef (root0) 0xfff0-0x (acpi0) 0x1-0x11fff (ram0) 0x12000-0x (root0) ACPI I/O memory addresses: 0xd7000-0xd7fff (root0) 0xe-0xf (root0) 0xdfee-0xdfef (root0) 0xf000-0xf3ff (root0) 0xfec0-0xfec00fff (root0) 0xfed1-0xfed1dfff (root0) 0xfed2-0xfed8 (root0) 0xfee0-0xfee00fff (root0) 0xffb0-0xffb7 (root0) 0xfff0-0x (root0) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ichwd0: unable to reserve GCS registers
John Baldwin writes: > On Wednesday, August 03, 2011 1:23:29 pm Test Rat wrote: >> John Baldwin writes: >> >> > On Wednesday, August 03, 2011 4:49:24 am Test Rat wrote: >> >> Doug Barton writes: >> >> >> >> > On 08/02/2011 15:06, John Baldwin wrote: >> >> >> On Saturday, July 30, 2011 2:49:52 am Andriy Gapon wrote: >> >> >>> on 19/07/2011 18:16 John Baldwin said the following: >> >> >>>> Hmm, can you get devinfo -r output from a working kernel with ichwd > loaded? >> >> >>>> You might be able to just build the kernel with 'nooptions > NEW_PCIB'. >> >> >>> >> >> >>> I believe that I've got a similar problem with amdsbwd(4). >> >> >>> It needs some resources (I/O ports) that belong to ACPI. >> >> >>> The problem is that the driver attaches to isa bus which is under >> >> >>> isab->pci->pcib and those particular resources are not assigned to > the Host-PCI >> >> >>> bridge. >> >> >>> >> >> >>> I think that you already made a suggestion that perhaps isa bus > should directly >> >> >>> attach to acpi bus when acpi is available. Not sure if there are any >> >> >>> alternative approaches. >> >> >> >> >> >> Can you try this: >> >> > >> >> > Not so much. :) the first and last patches I can apply to HEAD by hand, >> >> > but /sys/dev/acpica/acpi_pcib_acpi.c is only 387 lines long, so I'm not >> >> > even sure where to start. >> >> >> >> $ svn cat > svn://svn.freebsd.org/base/head/sys/dev/acpica/acpi_pcib_acpi.c | wc -l >> >> 531 >> >> >> >> No difference here on ICH9, ichwd(4) still doesn't attach. >> > >> > Can you add some printfs to see if the new method is being called in >> > acpi_pcib_alloc_resource() and if it is failing when it is called? >> >> rman_reserve_resource() fails with SYS_RES_MEMORY for isab0 when ichwd0 >> tries to attach. And acpi_alloc_sysres() is not called when isab0 or >> isa0 are attached. >> >> isab0: found ICH9 or equivalent chipset: Intel ICH9 watchdog timer >> ichwd0: on isa0 >> isab0: found ICH9 or equivalent chipset: Intel ICH9 watchdog timer >> acpi_alloc_resource::acpi_alloc_sysres(child->nameunit=ichwd0, > type=SYS_RES_IOPORT, *rid=0, start=1072, end=1079, count=8, flags=6) > res=0xfe0007fed380 RF_ACTIVE activated >> pcib0: allocated type 4 (0x430-0x437) for rid 0 of ichwd0 >> acpi_alloc_resource::acpi_alloc_sysres(child->nameunit=ichwd0, > type=SYS_RES_IOPORT, *rid=1, start=1120, end=1151, count=32, flags=6) > res=0xfe0007fed400 RF_ACTIVE activated >> pcib0: allocated type 4 (0x460-0x47f) for rid 1 of ichwd0 >> acpi_pcib_acpi_alloc_resource::acpi_alloc_sysres(child->nameunit=isab0, > type=SYS_RES_MEMORY, *rid=0, start=4275172368, end=4275172371, count=4, > flags=6) res=0 failed to reserve >> ichwd0: unable to reserve GCS registers > > Hmm, so it is called, it just fails when it is called. The range is > 0xfed1f410 - 0xfed1f413. Can you verify that that is in the 'ACPI memory > I/O' > range in devinfo -u output? It doesn't seem to be there (minus lines = hostres disabled). acpi0 I/O ports: 0x400-0x4bf 0x4d0-0x4d1 I/O memory addresses: 0xfed1-0xfed1dfff 0xfed2-0xfed8 pcib0 pci0 isab0 - I/O memory addresses: - 0xfed1f410-0xfed1f413 isa0 - ichwd0 - ACPI I/O ports: - 0x430-0x437 - 0x460-0x47f ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ichwd0: unable to reserve GCS registers
John Baldwin writes: > On Wednesday, August 03, 2011 4:49:24 am Test Rat wrote: >> Doug Barton writes: >> >> > On 08/02/2011 15:06, John Baldwin wrote: >> >> On Saturday, July 30, 2011 2:49:52 am Andriy Gapon wrote: >> >>> on 19/07/2011 18:16 John Baldwin said the following: >> >>>> Hmm, can you get devinfo -r output from a working kernel with ichwd >> >>>> loaded? >> >>>> You might be able to just build the kernel with 'nooptions NEW_PCIB'. >> >>> >> >>> I believe that I've got a similar problem with amdsbwd(4). >> >>> It needs some resources (I/O ports) that belong to ACPI. >> >>> The problem is that the driver attaches to isa bus which is under >> >>> isab->pci->pcib and those particular resources are not assigned to the >> >>> Host-PCI >> >>> bridge. >> >>> >> >>> I think that you already made a suggestion that perhaps isa bus should >> >>> directly >> >>> attach to acpi bus when acpi is available. Not sure if there are any >> >>> alternative approaches. >> >> >> >> Can you try this: >> > >> > Not so much. :) the first and last patches I can apply to HEAD by hand, >> > but /sys/dev/acpica/acpi_pcib_acpi.c is only 387 lines long, so I'm not >> > even sure where to start. >> >> $ svn cat svn://svn.freebsd.org/base/head/sys/dev/acpica/acpi_pcib_acpi.c >> | wc -l >> 531 >> >> No difference here on ICH9, ichwd(4) still doesn't attach. > > Can you add some printfs to see if the new method is being called in > acpi_pcib_alloc_resource() and if it is failing when it is called? rman_reserve_resource() fails with SYS_RES_MEMORY for isab0 when ichwd0 tries to attach. And acpi_alloc_sysres() is not called when isab0 or isa0 are attached. isab0: found ICH9 or equivalent chipset: Intel ICH9 watchdog timer ichwd0: on isa0 isab0: found ICH9 or equivalent chipset: Intel ICH9 watchdog timer acpi_alloc_resource::acpi_alloc_sysres(child->nameunit=ichwd0, type=SYS_RES_IOPORT, *rid=0, start=1072, end=1079, count=8, flags=6) res=0xfe0007fed380 RF_ACTIVE activated pcib0: allocated type 4 (0x430-0x437) for rid 0 of ichwd0 acpi_alloc_resource::acpi_alloc_sysres(child->nameunit=ichwd0, type=SYS_RES_IOPORT, *rid=1, start=1120, end=1151, count=32, flags=6) res=0xfe0007fed400 RF_ACTIVE activated pcib0: allocated type 4 (0x460-0x47f) for rid 1 of ichwd0 acpi_pcib_acpi_alloc_resource::acpi_alloc_sysres(child->nameunit=isab0, type=SYS_RES_MEMORY, *rid=0, start=4275172368, end=4275172371, count=4, flags=6) res=0 failed to reserve ichwd0: unable to reserve GCS registers device_attach: ichwd0 attach returned 6 Do you need full bootverbose log? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
bsdtar(1) can't extract new ISO images
It's often convenient to extract pieces of iso9660 images for recovery purposes or a jail. As libarchive no longer recognizes them one has to resort to mdconfig + mount_cd9660. On a zfs-only system this populates bufspace unused by arc cache and never gives memory back... nevermind. $ tar tf FreeBSD-9.0-BETA1-amd64-bootonly.iso $ cpio -ti http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ichwd0: unable to reserve GCS registers
Doug Barton writes: > On 08/02/2011 15:06, John Baldwin wrote: >> On Saturday, July 30, 2011 2:49:52 am Andriy Gapon wrote: >>> on 19/07/2011 18:16 John Baldwin said the following: Hmm, can you get devinfo -r output from a working kernel with ichwd loaded? You might be able to just build the kernel with 'nooptions NEW_PCIB'. >>> >>> I believe that I've got a similar problem with amdsbwd(4). >>> It needs some resources (I/O ports) that belong to ACPI. >>> The problem is that the driver attaches to isa bus which is under >>> isab->pci->pcib and those particular resources are not assigned to the >>> Host-PCI >>> bridge. >>> >>> I think that you already made a suggestion that perhaps isa bus should >>> directly >>> attach to acpi bus when acpi is available. Not sure if there are any >>> alternative approaches. >> >> Can you try this: > > Not so much. :) the first and last patches I can apply to HEAD by hand, > but /sys/dev/acpica/acpi_pcib_acpi.c is only 387 lines long, so I'm not > even sure where to start. $ svn cat svn://svn.freebsd.org/base/head/sys/dev/acpica/acpi_pcib_acpi.c | wc -l 531 No difference here on ICH9, ichwd(4) still doesn't attach. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[clang] (gpt)zfsboot is broken: zfs_alloc()/zfs_free() mismatch
Anyone else? I can still reproduce with trunk r136607. boot and gptboot seem to be unaffected. IIRC, with previous clang import it just stuck during boot without any error messages. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
