Re: TSO panic

[Andre Oppermann]

On 02.09.2010 00:11, ben wilber wrote:

On Sep 1, 2010, at 8:57 AM, Andre Oppermann wrote:


On 01.09.2010 01:13, ben wilber wrote:

Hi,

I just upgraded from r210042 to r212073 and keep getting the panic
introduced in r211317:

panic: tcp_output: len= tso_segsz


Please try the attached patch and report back whether it
fixes the issue.


The system ran for 8 hours or so before I received the same panic.  Previously, 
it would panic within 20 minutes.

db:0:kdb.enter.default   bt
Tracing pid 17131 tid 100601 td 0xff0236603440
kdb_enter() at kdb_enter+0x3d
panic() at panic+0x1c8
tcp_output() at tcp_output+0x1495
tcp_usr_send() at tcp_usr_send+0x267
sosend_generic() at sosend_generic+0x49e
sosend() at sosend+0x1f
soo_write() at soo_write+0x51
dofilewrite() at dofilewrite+0x87
kern_writev() at kern_writev+0x46
write() at write+0x4e
syscallenter() at syscallenter+0x251
syscall() at syscall+0x39
Xfast_syscall() at Xfast_syscall+0xe2
--- syscall (4, FreeBSD ELF64, write), rip = 0x800f5d1ac, rsp = 0x7fffc3b8, 
rbp = 0x8007a1340 ---


Can you send me the core.txt.X file and the output of p len from
DDB or kgdb on a crash dump in private email?

--
Andre
___
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: Call for Documentation Contributors

[Mehmet Erol Sanliturk]

On Wed, Sep 1, 2010 at 6:46 PM, Gabor PALI p...@freebsd.org wrote:

 Hello there,

 I am looking for volunteers who are interested in writing
 documentation, i.e. working with the FreeBSD Handbook and the
 documentation set.  Many of our great documentation writers have
 decided to retire from their work over the last years, which means the
 FreeBSD Documentation Project is in need of talented, skilled,
 determined, and ambitious people who would help to maintain the
 tradition of producing high quality documentation for the FreeBSD
 operating system.

 The documentation set is prepared in DocBook that might seem a bit
 complicated at first sight, but I can assure you it can be learned
 quickly.  All you need is good writing skills in English, some
 knowledge of FreeBSD systems, and willingness to learn even more about
 them.  To coordinate and encourage the efforts, I have created a site
 [1] called The FreeBSD Contributor's Documentation Project that
 contains the necessary information.  Note that there are many ways of
 contribution: you can comment open Problem Reports or write patches
 (by using Mercurial Queues for example), etc. depending on your free
 time.  I can help with anything at the regular weekly IRC meetings,
 and you can contact me via email directly any time, and hopefully
 other documentation developers will also join me.


 Thank you for any help in advance.

 :g

 [1] http://doc.hu.freebsd.org/




I want to repeat my suggestion once more :


Please separate Handbook with respect to distributions , i.e. , maintain a
different Handbook for each distribution . I think , this is more easier to
maintain a combined Handbook . A combined Handbook is giving also an
impression that the both distinct distributions are the SAME . Then what is
the difference between distributions 7.3 and 8.1 ?  Personally I do NOT have
any idea about differences , because up to now I did not see such a document
associated with distributions .


The combined Handbook is making it very difficult to  make any improvement
suggestions , because it requires knowledge of related two distinct
distributions .


For example , the current Handbook is about Release 7.3 and 8.1 . If a
person is using 8.x series , and NOT 7.x series will be in difficulty to
identify her/his
suggestion whether it is contrary to her/his unused distribution .


Thank you very much .

Mehmet Erol Sanliturk
___
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: Call for Documentation Contributors

[Ed Schouten]

* Mehmet Erol Sanliturk m.e.sanlit...@gmail.com wrote:
 Please separate Handbook with respect to distributions , i.e. , maintain a
 different Handbook for each distribution .

The problem with that is that it will cause documentation for older, but
still supported releases, to become stale. Most doc changes apply to
functionality provided by both releases, or at least functionality that
is MFC'd.

-- 
 Ed Schouten e...@80386.nl
 WWW: http://80386.nl/


pgpGMCzJmSIXQ.pgp
Description: PGP signature

Re: Difficulty playing DVDs under AHCI/CAM?

[Andriy Gapon]

on 01/09/2010 21:21 Garrett Wollman said the following:
 On Wed, 01 Sep 2010 19:16:03 +0300, Andriy Gapon a...@icyb.net.ua said:
 
 Just want to draw attention of those who use ahci, have hald running and burn
 optical media to couple of known issues:
 
 What about those of us who use ahci, don't have hald running, and just
 want to read their DVDs?

I am not aware of any known but not resolved issues in this context.
But I think that I gave you a good advice.

 I never heard any response from you when I
 asked for a more specific debugging procedure.

Sorry about that, forgot to tell you about google.
Now, apologies about the joke, no offense meant :-)
These links should give a good overview for the start:
http://wiki.freebsd.org/DTrace
http://wiki.freebsd.org/DTrace/Examples
http://www.freebsd.org/doc/handbook/dtrace.html
http://wikis.sun.com/display/DTrace/Documentation

And, oh, here is a script that I used to investigate a somewhat similar problem
with failing ioctl.  I think you should be able to easily adapt it to your 
needs.

syscall::ioctl:entry
/execname == k3b  arg1 == 3299349762/
{
self-trace = 1;
}

fbt:::entry
/self-trace/
{
}

fbt:::return
/self-trace/
{
printf(%d, arg1);
}

syscall::ioctl:return
{
self-trace = 0;
}

 My next step was going
 to be enabling CAMDEBUG and trying to find out which specific
 operation was failing, but I'm not a SCSI expert by any means

Not sure if debugging with CAMDEBUG would be easier or not.
There could be lots of output.

-- 
Andriy Gapon
___
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: ZFS v28 is ready for wider testing.

[Pawel Jakub Dawidek]

On Thu, Sep 02, 2010 at 01:55:51AM -0700, Rob Farmer wrote:
 On Tue, Aug 31, 2010 at 2:59 PM, Pawel Jakub Dawidek p...@freebsd.org wrote:
 
  Ok, now that I know you read everything carefully, here is the patch:
 
         http://people.freebsd.org/~pjd/patches/zfs_20100831.patch.bz2
 
 
 buildworld on i386 (yes I know ZFS isn't ideal there):
[...]

Yes, I know about this problem, You can use attached patch or wait for
full patch, which I'll be sending later today.

-- 
Pawel Jakub Dawidek   http://www.wheelsystems.com
p...@freebsd.org   http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!
--- sys/cddl/compat/opensolaris/sys/atomic.h
+++ sys/cddl/compat/opensolaris/sys/atomic.h
@@ -39,10 +39,9 @@
 #ifndef __LP64__
 extern void atomic_add_64(volatile uint64_t *target, int64_t delta);
 extern void atomic_dec_64(volatile uint64_t *target);
-extern void *atomic_cas_ptr(volatile void *target, void *cmp,  void *newval);
 #endif
 #ifndef __sparc64__
-extern uint64_t atomic_cas_32(volatile uint32_t *target, uint32_t cmp,
+extern uint32_t atomic_cas_32(volatile uint32_t *target, uint32_t cmp,
 uint32_t newval);
 extern uint64_t atomic_cas_64(volatile uint64_t *target, uint64_t cmp,
 uint64_t newval);
@@ -119,21 +118,19 @@
 }
 
 #ifndef COMPAT_32BIT
-#if defined(__LP64__)
+#ifdef __LP64__
 static __inline void *
 atomic_cas_ptr(volatile void *target, void *cmp,  void *newval)
 {
-	return ((void *)atomic_cas_64((volatile uint64_t *)target, (uint64_t)cmp,
-	(uint64_t)newval));
+	return ((void *)atomic_cas_64(target, (uint64_t)cmp, (uint64_t)newval));
 }
 #else
 static __inline void *
 atomic_cas_ptr(volatile void *target, void *cmp,  void *newval)
 {
-	return ((void *)atomic_cas_32((volatile uint64_t *)target, (uint64_t)cmp,
-	(uint64_t)newval));
+	return ((void *)atomic_cas_32(target, (uint32_t)cmp, (uint32_t)newval));
 }
 #endif
-#endif
+#endif	/* !COMPAT_32BIT */
 
 #endif	/* !_OPENSOLARIS_SYS_ATOMIC_H_ */


pgppo82knRdQW.pgp
Description: PGP signature

Re: ZFS v28 is ready for wider testing.

[Rob Farmer]

On Tue, Aug 31, 2010 at 2:59 PM, Pawel Jakub Dawidek p...@freebsd.org wrote:

 Ok, now that I know you read everything carefully, here is the patch:

        http://people.freebsd.org/~pjd/patches/zfs_20100831.patch.bz2


buildworld on i386 (yes I know ZFS isn't ideal there):

=== cddl/lib/libdtrace (all)
cc -O2 -fno-strict-aliasing -pipe -march=prescott
-I/usr/obj/usr/src/cddl/lib/libdtrace -I/usr/src/cddl/lib/libdtrace
-I/usr/src/cddl/lib/libdtrace/../../../sys/cddl/dev/dtrace/i386
-I/usr/src/cddl/lib/libdtrace/../../../sys/cddl/compat/opensolaris
-I/usr/src/cddl/lib/libdtrace/../../../cddl/compat/opensolaris/include
 -I/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/head
-I/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libctf/common
 
-I/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common
 -I/usr/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/common
-I/usr/src/cddl/lib/libdtrace/../../../sys/cddl/contrib/opensolaris/uts/intel
-DDIS_MEM -DNEED_SOLARIS_BOOLEAN -std=gnu89 -fstack-protector
-Wsystem-headers -Werror -Wno-pointer-sign -Wno-unknown-pragmas -c
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_aggregate.c
In file included from
/usr/src/cddl/lib/libdtrace/../../../sys/cddl/compat/opensolaris/sys/bitmap.h:36,
 from
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_impl.h:33,
 from
/usr/src/cddl/lib/libdtrace/../../../cddl/contrib/opensolaris/lib/libdtrace/common/dt_aggregate.c:33:
/usr/src/cddl/lib/libdtrace/../../../sys/cddl/compat/opensolaris/sys/atomic.h:132:
error: static declaration of 'atomic_cas_ptr' follows non-static
declaration
/usr/src/cddl/lib/libdtrace/../../../sys/cddl/compat/opensolaris/sys/atomic.h:42:
error: previous declaration of 'atomic_cas_ptr' was here
cc1: warnings being treated as errors
/usr/src/cddl/lib/libdtrace/../../../sys/cddl/compat/opensolaris/sys/atomic.h:
In function 'atomic_cas_ptr':
/usr/src/cddl/lib/libdtrace/../../../sys/cddl/compat/opensolaris/sys/atomic.h:133:
warning: cast from pointer to integer of different size
/usr/src/cddl/lib/libdtrace/../../../sys/cddl/compat/opensolaris/sys/atomic.h:134:
warning: cast from pointer to integer of different size
/usr/src/cddl/lib/libdtrace/../../../sys/cddl/compat/opensolaris/sys/atomic.h:134:
warning: passing argument 1 of 'atomic_cas_32' from incompatible
pointer type
/usr/src/cddl/lib/libdtrace/../../../sys/cddl/compat/opensolaris/sys/atomic.h:134:
warning: cast to pointer from integer of different size
*** Error code 1

I tried applying the patch to r212087 to rule out recent changes to
dtrace, but it made no difference. I used patch -E -p0  patch.

-- 
Rob Farmer
___
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: One-shot-oriented event timers management

[Ian FREISLICH]

On Wed, Sep 1, 2010 at 2:16 PM, Alexander Motin m...@freebsd.org wrote:
 Brandon Gooch wrote:
 This latest patch causes an interrupt storm with the HPET timer on my
 system. The machine took about 8 minutes to boot and bring me to a
 login prompt. System interactivity (i.e. input from keyboard, output
 on console) was fine, but after checking the output of `systat vmstat
 -1`, I saw the interrupt rate on each HPET entry was over 120k!

 Can I provide any useful detail? Of course, test patches are always welcom
e :)

 I was able to reproduce alike storm in some situations.

 Try new version: http://people.freebsd.org/~mav/timers_oneshot7.patch

Interrupt rates are definitely reduced.

[mini] /usr/home/ianf $ vmstat -i
interrupt  total   rate
irq1: atkbd01154  1
irq9: acpi010829 15
irq16: ath0 uhci3+ 16226 23
irq18: uhci2  16  0
irq19: uhci1+   7090 10
irq20: hpet0  169288240
irq23: uhci0 ehci064  0
irq256: hdac0187  0
Total 204854291

[mini] /usr/home/ianf $ sysctl dev.cpu |grep usage
dev.cpu.0.cx_usage: 0.00% 0.04% 0.80% 99.15% last 1601us
dev.cpu.1.cx_usage: 0.00% 0.00% 0.65% 99.34% last 2078us

Ian

-- 
Ian Freislich
___
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

panic in get_next_dirent

[Andriy Gapon]

Brian,

after I upgrade from beginning-of-June kernel to end-of-August one (r211758) I
get a panic in get_next_dirent which happens during parallel access to FS like
during buildworld with -jN.
I am upgrading kernel to the latest revision as of today.

Could this be something that you accidentally broke and then fixed while
pursuing your NFS issue?

-- 
Andriy Gapon
___
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

bge(4) problem on sparc64 between r204991M and r212097

[Anton Shterenlikht]

I just updated world and kernel from r204991M to r212097 on sparc64.

Now I can't ping my gateway. If I boot kernel.old, then
the network works fine. As far as I could see mergemaster
didn't update any network files.

Please advise

In the meantime I'll try intermediate revisions.

many thanks
anton


-- 
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 331 5944
Fax: +44 (0)117 929 4423
___
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

panic in get_next_dirent

[Andriy Gapon]

Brian,

after I upgraded my kernel from beginning of July version to end of August
version I started to get panics in get_next_dirent under parallel FS load, like
e.g. during buildworld with -jN.

Is this something that might have been broken by accident and then fixed later?
I've seen that you were making some changes in the related code while working on
your NFS problem.

I am upgrading kernel to the latest version now to see if that helps.

Here is panic information:

Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address   = 0xff80151b8abb
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x803f6f54
stack pointer   = 0x28:0xff8124353580
frame pointer   = 0x28:0xff8124353650
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 12295 (sh)
trap number = 12
panic: page fault
cpuid = 1
KDB: stack backtrace:
db_trace_self_wrapper() at 0x801b84ba = db_trace_self_wrapper+0x2a
kdb_backtrace() at 0x803a2c62 = kdb_backtrace+0x32
panic() at 0x8036cb54 = panic+0x1b4
trap_fatal() at 0x805471ad = trap_fatal+0x39d
trap_pfault() at 0x805473bd = trap_pfault+0x1ed
trap() at 0x805479a4 = trap+0x484
calltrap() at 0x80531428 = calltrap+0x8
--- trap 0xc, rip = 0x803f6f54, rsp = 0xff8124353580, rbp =
0xff8124353650 ---
get_next_dirent() at 0x803f6f54 = get_next_dirent+0x164
vop_stdvptocnp() at 0x803f749a = vop_stdvptocnp+0x31a
VOP_VPTOCNP_APV() at 0x805a3af8 = VOP_VPTOCNP_APV+0xe8
vn_vptocnp_locked() at 0x803f339c = vn_vptocnp_locked+0x1fc
vn_fullpath1() at 0x803f36b8 = vn_fullpath1+0x1e8
kern___getcwd() at 0x803f3b4a = kern___getcwd+0xda
__getcwd() at 0x803f3cd4 = __getcwd+0x14
syscallenter() at 0x803b088e = syscallenter+0x26e
syscall() at 0x80547432 = syscall+0x42
Xfast_syscall() at 0x80531702 = Xfast_syscall+0xe2
--- syscall (326, FreeBSD ELF64, __getcwd), rip = 0x800939cfc, rsp =
0x7fffe0b8, rbp = 0x800c2a208 ---

-- 
Andriy Gapon
___
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

problem with amd64 minidump

[Andriy Gapon]

Not sure if this is some local issue or a problem in FreeBSD code.
I remember minidumps working perfectly well for me, but now I can not get data
from them.
Example:
dmesg -M /var/crash/vmcore.4
dmesg: _kvm_vatop: direct map address 0xff012fe0 not in minidump
dmesg: kvm_read: invalid address (0xff012fe0)

Needless to say kgdb refuses to work with that core too.

With kgdb on live system I can access that address:
(gdb) x/a 0xff012fe0
0xff012fe0: 0xff012ffe

Looks like perhaps we do not include something that we should into the dump?
Thanks!
-- 
Andriy Gapon
___
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: panic in get_next_dirent

[Andriy Gapon]

on 02/09/2010 13:01 Andriy Gapon said the following:
 
 Brian,
 
 after I upgraded my kernel from beginning of July version to end of August
 version I started to get panics in get_next_dirent under parallel FS load, 
 like
 e.g. during buildworld with -jN.
 
 Is this something that might have been broken by accident and then fixed 
 later?
 I've seen that you were making some changes in the related code while working 
 on
 your NFS problem.
 
 I am upgrading kernel to the latest version now to see if that helps.


Update to r212138 seems to have helped.
Sorry if my report is useless.

 Here is panic information:
 
 Fatal trap 12: page fault while in kernel mode
 cpuid = 1; apic id = 01
 fault virtual address   = 0xff80151b8abb
 fault code  = supervisor read data, page not present
 instruction pointer = 0x20:0x803f6f54
 stack pointer   = 0x28:0xff8124353580
 frame pointer   = 0x28:0xff8124353650
 code segment= base 0x0, limit 0xf, type 0x1b
 = DPL 0, pres 1, long 1, def32 0, gran 1
 processor eflags= interrupt enabled, resume, IOPL = 0
 current process = 12295 (sh)
 trap number = 12
 panic: page fault
 cpuid = 1
 KDB: stack backtrace:
 db_trace_self_wrapper() at 0x801b84ba = db_trace_self_wrapper+0x2a
 kdb_backtrace() at 0x803a2c62 = kdb_backtrace+0x32
 panic() at 0x8036cb54 = panic+0x1b4
 trap_fatal() at 0x805471ad = trap_fatal+0x39d
 trap_pfault() at 0x805473bd = trap_pfault+0x1ed
 trap() at 0x805479a4 = trap+0x484
 calltrap() at 0x80531428 = calltrap+0x8
 --- trap 0xc, rip = 0x803f6f54, rsp = 0xff8124353580, rbp =
 0xff8124353650 ---
 get_next_dirent() at 0x803f6f54 = get_next_dirent+0x164
 vop_stdvptocnp() at 0x803f749a = vop_stdvptocnp+0x31a
 VOP_VPTOCNP_APV() at 0x805a3af8 = VOP_VPTOCNP_APV+0xe8
 vn_vptocnp_locked() at 0x803f339c = vn_vptocnp_locked+0x1fc
 vn_fullpath1() at 0x803f36b8 = vn_fullpath1+0x1e8
 kern___getcwd() at 0x803f3b4a = kern___getcwd+0xda
 __getcwd() at 0x803f3cd4 = __getcwd+0x14
 syscallenter() at 0x803b088e = syscallenter+0x26e
 syscall() at 0x80547432 = syscall+0x42
 Xfast_syscall() at 0x80531702 = Xfast_syscall+0xe2
 --- syscall (326, FreeBSD ELF64, __getcwd), rip = 0x800939cfc, rsp =
 0x7fffe0b8, rbp = 0x800c2a208 ---
 


-- 
Andriy Gapon
___
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: Call for Documentation Contributors

[Niclas Zeising]

On 2010-09-02 00:46, Gabor PALI wrote:

Hello there,

I am looking for volunteers who are interested in writing
documentation, i.e. working with the FreeBSD Handbook and the
documentation set.  Many of our great documentation writers have
decided to retire from their work over the last years, which means the
FreeBSD Documentation Project is in need of talented, skilled,
determined, and ambitious people who would help to maintain the
tradition of producing high quality documentation for the FreeBSD
operating system.

The documentation set is prepared in DocBook that might seem a bit
complicated at first sight, but I can assure you it can be learned
quickly.  All you need is good writing skills in English, some
knowledge of FreeBSD systems, and willingness to learn even more about
them.  To coordinate and encourage the efforts, I have created a site
[1] called The FreeBSD Contributor's Documentation Project that
contains the necessary information.  Note that there are many ways of
contribution: you can comment open Problem Reports or write patches
(by using Mercurial Queues for example), etc. depending on your free
time.  I can help with anything at the regular weekly IRC meetings,
and you can contact me via email directly any time, and hopefully
other documentation developers will also join me.


Thank you for any help in advance.

:g

[1] http://doc.hu.freebsd.org/


Hi!
Just a nitpick, would it be possible to move that site to the wiki, 
where most other stuff related to FreeBSD development is? It's not meant 
as critique towards your work, just a suggestion.
Also, a list of open tasks would probably be valuable. For instance a 
list where people who find errors or discrepancies in the docs can add 
them so other people find them and can work on them. I know this is what 
the PR system is built for, but the PR system might be a bid cumbersome 
for just making annotations and stuff like that.
Just some suggestions on how to make this flow better. Hopefully I will 
have some time to actually do some of the work involved too. :)

Keep up the good work!
Best Regards!
//Niclas
___
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: One-shot-oriented event timers management

[Alexander Motin]

Ian FREISLICH wrote:
 On Wed, Sep 1, 2010 at 2:16 PM, Alexander Motin m...@freebsd.org wrote:
 Brandon Gooch wrote:
 This latest patch causes an interrupt storm with the HPET timer on my
 system. The machine took about 8 minutes to boot and bring me to a
 login prompt. System interactivity (i.e. input from keyboard, output
 on console) was fine, but after checking the output of `systat vmstat
 -1`, I saw the interrupt rate on each HPET entry was over 120k!

 Can I provide any useful detail? Of course, test patches are always welcom
 e :)
 I was able to reproduce alike storm in some situations.

 Try new version: http://people.freebsd.org/~mav/timers_oneshot7.patch
 
 Interrupt rates are definitely reduced.
 
 [mini] /usr/home/ianf $ vmstat -i
 interrupt  total   rate
 irq1: atkbd01154  1
 irq9: acpi010829 15
 irq16: ath0 uhci3+ 16226 23
 irq18: uhci2  16  0
 irq19: uhci1+   7090 10
 irq20: hpet0  169288240
 irq23: uhci0 ehci064  0
 irq256: hdac0187  0
 Total 204854291

Nice. But 240 still quite a lot. Have you applied tm6292_idle.patch and
was this system idle at the moment?

 [mini] /usr/home/ianf $ sysctl dev.cpu |grep usage
 dev.cpu.0.cx_usage: 0.00% 0.04% 0.80% 99.15% last 1601us
 dev.cpu.1.cx_usage: 0.00% 0.00% 0.65% 99.34% last 2078us

It is the first time I see in practice system reporting 4 different ACPI
C-states. What is this system? What CPU is there? Could you show me full
`sysctl dev.cpu` output?

-- 
Alexander Motin
___
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: One-shot-oriented event timers management

[Ian FREISLICH]

Alexander Motin wrote:
 Ian FREISLICH wrote:
  On Wed, Sep 1, 2010 at 2:16 PM, Alexander Motin m...@freebsd.org wrote:
  Brandon Gooch wrote:
  This latest patch causes an interrupt storm with the HPET timer on my
  system. The machine took about 8 minutes to boot and bring me to a
  login prompt. System interactivity (i.e. input from keyboard, output
  on console) was fine, but after checking the output of `systat vmstat
  -1`, I saw the interrupt rate on each HPET entry was over 120k!
 
  Can I provide any useful detail? Of course, test patches are always welco
m
  e :)
  I was able to reproduce alike storm in some situations.
 
  Try new version: http://people.freebsd.org/~mav/timers_oneshot7.patch
  
  Interrupt rates are definitely reduced.
  
  [mini] /usr/home/ianf $ vmstat -i
  interrupt  total   rate
  irq1: atkbd01154  1
  irq9: acpi010829 15
  irq16: ath0 uhci3+ 16226 23
  irq18: uhci2  16  0
  irq19: uhci1+   7090 10
  irq20: hpet0  169288240
  irq23: uhci0 ehci064  0
  irq256: hdac0187  0
  Total 204854291
 
 Nice. But 240 still quite a lot. Have you applied tm6292_idle.patch and
 was this system idle at the moment?

No, I didn't.  It was reasonably idle.  I missed that in the first
post - because I became interested in this when Brandon Gooch
reported lower power consumption.  I've compiled now with this patch
as well.  There was one rejection:

--- 2182,2189 
 * Ticks is updated asynchronously on a single cpu.  Check here to
 * avoid incrementing ts_ticks multiple times in a single tick.
 */
+ //if (ts-ts_incrtick == ticks)
+ //return;
/* Adjust ticks for pctcpu */
ts-ts_ticks += 1  SCHED_TICK_SHIFT;
ts-ts_ltick = ticks;

But, it appears to have already been applied by timers_oneshot7.patch.

The vmstat -i output is the rate since boot.  Currently at 240/s
since boot, the instantaneous rate when idle is about 60.

  [mini] /usr/home/ianf $ sysctl dev.cpu |grep usage
  dev.cpu.0.cx_usage: 0.00% 0.04% 0.80% 99.15% last 1601us
  dev.cpu.1.cx_usage: 0.00% 0.00% 0.65% 99.34% last 2078us
 
 It is the first time I see in practice system reporting 4 different ACPI
 C-states. What is this system? What CPU is there? Could you show me full
 `sysctl dev.cpu` output?

It's a compaq mini-110:
CPU: Intel(R) Atom(TM) CPU N270   @ 1.60GHz (1596.22-MHz 686-class CPU)

dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=\_PR_.P001
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%parent: acpi0
dev.cpu.0.freq: 1600
dev.cpu.0.freq_levels: 1600/25000 1400/21875 1333/18000 1166/15750 1067/11000 
933/9625 800/5000 700/4375 600/3750 500/3125 400/2500 300/1875 200/1250 100/625
dev.cpu.0.cx_supported: C1/1 C2/1 C3/17 C4/57
dev.cpu.0.cx_lowest: C1
dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% 0.00% last 379us
dev.cpu.1.%desc: ACPI CPU
dev.cpu.1.%driver: cpu
dev.cpu.1.%location: handle=\_PR_.P002
dev.cpu.1.%pnpinfo: _HID=none _UID=0
dev.cpu.1.%parent: acpi0
dev.cpu.1.cx_supported: C1/1 C2/1 C3/17 C4/57
dev.cpu.1.cx_lowest: C1
dev.cpu.1.cx_usage: 100.00% 0.00% 0.00% 0.00% last 4335us

Ian

-- 
Ian Freislich
___
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: Call for Documentation Contributors

[Gabor PALI]

Hello,


On Thu, Sep 2, 2010 at 11:45 AM, Niclas Zeising
niclas.zeis...@gmail.com wrote:
 would it be possible to move that site to the wiki, where
 most other stuff related to FreeBSD development is?

Almost all parts are on the FreeBSD wiki already.  Only the main
coordination page (which is only a single HTML page), the Mercurial
repository, and the generated PR list are outside of that.


 Also, a list of open tasks would probably be valuable.

Yes, indeed.


 For instance a list where people who find errors or discrepancies in the docs 
 can add them so
 other people find them and can work on them.

There is one already [1].


:g

[1] http://wiki.freebsd.org/ContribDoc/Tasks
___
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: One-shot-oriented event timers management

[b. f.]

In:

http://people.freebsd.org/~mav/timers_oneshot7.patch

you need to offset the declaration of 'cpu' in getnextevent() on line
256 of src/sys/kern/kern_clocksource.c by #ifdef SMP, because it is
not used otherwise, and will break UP kernel builds with our default
warnings and -Werror.

Incidentally, do you intend to commit the tm6292_idle.patch along with
the new timer code, after testing is satisfactory?  Or is this not
appropriate for general use?  If it isn't suitable for all users,
perhaps some of the periods of the events in that patch can be
abstracted and made tunable, so that we can make it possible to
conserve power, and also keep others happy?

Regards,
  b.
___
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: problem with amd64 minidump

[Andriy Gapon]

on 02/09/2010 13:10 Andriy Gapon said the following:
 
 Not sure if this is some local issue or a problem in FreeBSD code.
 I remember minidumps working perfectly well for me, but now I can not get data
 from them.
 Example:
 dmesg -M /var/crash/vmcore.4
 dmesg: _kvm_vatop: direct map address 0xff012fe0 not in minidump
 dmesg: kvm_read: invalid address (0xff012fe0)

Not sure if it can help, but it seems that this virtual address in DMAP
corresponds to a physical address in the last page of RAM.
Do we use that for anything special?  Message buffer?
I had a quick look at getmemsize() function in sys/amd64/amd64/machdep.c and it
looks like the following code in the function could be doing just that:

Maxmem = atop(phys_avail[pa_indx]);

/* Trim off space for the message buffer. */
phys_avail[pa_indx] -= round_page(MSGBUF_SIZE);

/* Map the message buffer. */
msgbufp = (struct msgbuf *)PHYS_TO_DMAP(phys_avail[pa_indx]);

Oh, and yeah:
(gdb) p msgbufp
$4 = (struct msgbuf *) 0xff012fe0

But we do dump the message buffer.
But somehow its dmap address is not resolved correctly.

This should ring a bell for someone knowledgeable of minidump and libkvm code, I
believe.

 Needless to say kgdb refuses to work with that core too.
 
 With kgdb on live system I can access that address:
 (gdb) x/a 0xff012fe0
 0xff012fe0: 0xff012ffe



-- 
Andriy Gapon
___
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: One-shot-oriented event timers management

[Alexander Motin]

b. f. wrote:
 In:
 http://people.freebsd.org/~mav/timers_oneshot7.patch
 
 you need to offset the declaration of 'cpu' in getnextevent() on line
 256 of src/sys/kern/kern_clocksource.c by #ifdef SMP, because it is
 not used otherwise, and will break UP kernel builds with our default
 warnings and -Werror.

Thanks.

 Incidentally, do you intend to commit the tm6292_idle.patch along with
 the new timer code, after testing is satisfactory?  Or is this not
 appropriate for general use?  If it isn't suitable for all users,
 perhaps some of the periods of the events in that patch can be
 abstracted and made tunable, so that we can make it possible to
 conserve power, and also keep others happy?

No, I am not going to commit it in present form. It is mostly made for
technology preview. May be some parts of it could be committed as-is,
but most of others are dirty hacks. I hope they should be safe enough,
but they made with assumption of some tradeoffs and require proper
rework or at least reevaluating. It would be nice if people aware with
these areas (SCHED_ULE, TCP, CPU time resources, yarrow, console, GEOM)
could review and reimplement them properly.

-- 
Alexander Motin
___
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: bge(4) problem on sparc64 between r204991M and r212097

[Anton Shterenlikht]

On Thu, Sep 02, 2010 at 11:00:14AM +0100, Anton Shterenlikht wrote:
 I just updated world and kernel from r204991M to r212097 on sparc64.
 
 Now I can't ping my gateway. If I boot kernel.old, then
 the network works fine. As far as I could see mergemaster
 didn't update any network files.
 
 Please advise
 
 In the meantime I'll try intermediate revisions.

I narrowed down the problem to between r212050 and r212080.
Will continue tomorrow.

many thanks
anton

-- 
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 331 5944
Fax: +44 (0)117 929 4423
___
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

[head tinderbox] failure on arm/arm

[FreeBSD Tinderbox]

TB --- 2010-09-02 17:20:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-09-02 17:20:00 - starting HEAD tinderbox run for arm/arm
TB --- 2010-09-02 17:20:00 - cleaning the object tree
TB --- 2010-09-02 17:20:24 - cvsupping the source tree
TB --- 2010-09-02 17:20:24 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/HEAD/arm/arm/supfile
TB --- 2010-09-02 17:54:12 - WARNING: /usr/bin/csup returned exit code  1 
TB --- 2010-09-02 17:54:12 - ERROR: unable to cvsup the source tree
TB --- 2010-09-02 17:54:12 - 0.60 user 9.23 system 2051.41 real


http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full
___
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

[head tinderbox] failure on i386/i386

[FreeBSD Tinderbox]

TB --- 2010-09-02 17:20:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-09-02 17:20:00 - starting HEAD tinderbox run for i386/i386
TB --- 2010-09-02 17:20:00 - cleaning the object tree
TB --- 2010-09-02 17:20:35 - cvsupping the source tree
TB --- 2010-09-02 17:20:35 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/HEAD/i386/i386/supfile
TB --- 2010-09-02 17:56:30 - WARNING: /usr/bin/csup returned exit code  1 
TB --- 2010-09-02 17:56:30 - ERROR: unable to cvsup the source tree
TB --- 2010-09-02 17:56:30 - 0.98 user 16.30 system 2189.84 real


http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full
___
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

[head tinderbox] failure on amd64/amd64

[FreeBSD Tinderbox]

TB --- 2010-09-02 17:20:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-09-02 17:20:00 - starting HEAD tinderbox run for amd64/amd64
TB --- 2010-09-02 17:20:00 - cleaning the object tree
TB --- 2010-09-02 17:20:38 - cvsupping the source tree
TB --- 2010-09-02 17:20:38 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/HEAD/amd64/amd64/supfile
TB --- 2010-09-02 17:57:06 - WARNING: /usr/bin/csup returned exit code  1 
TB --- 2010-09-02 17:57:06 - ERROR: unable to cvsup the source tree
TB --- 2010-09-02 17:57:06 - 1.05 user 18.48 system 2225.61 real


http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full
___
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

[head tinderbox] failure on i386/pc98

[FreeBSD Tinderbox]

TB --- 2010-09-02 17:20:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-09-02 17:20:00 - starting HEAD tinderbox run for i386/pc98
TB --- 2010-09-02 17:20:00 - cleaning the object tree
TB --- 2010-09-02 17:20:34 - cvsupping the source tree
TB --- 2010-09-02 17:20:34 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/HEAD/i386/pc98/supfile
TB --- 2010-09-02 17:58:41 - WARNING: /usr/bin/csup returned exit code  1 
TB --- 2010-09-02 17:58:41 - ERROR: unable to cvsup the source tree
TB --- 2010-09-02 17:58:41 - 0.90 user 15.32 system 2320.53 real


http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full
___
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: bge(4) problem on sparc64 between r204991M and r212097

[Pyun YongHyeon]

On Thu, Sep 02, 2010 at 06:03:16PM +0100, Anton Shterenlikht wrote:
 On Thu, Sep 02, 2010 at 11:00:14AM +0100, Anton Shterenlikht wrote:
  I just updated world and kernel from r204991M to r212097 on sparc64.
  
  Now I can't ping my gateway. If I boot kernel.old, then
  the network works fine. As far as I could see mergemaster
  didn't update any network files.
  
  Please advise
  
  In the meantime I'll try intermediate revisions.
 
 I narrowed down the problem to between r212050 and r212080.
 Will continue tomorrow.
 

Thanks for reporting. There was a big change in r212061, so try
backing out that revision and see whether this makes differences
or not.
___
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

ZFS Cache Log Device Failure Handling

[Jason J. W. Williams]

Hi Guys,

How well does ZFS on FreeBSD handle a dying/wedged log and/or cache
device? OpenSolaris handles this pretty well in my experience and will
fail through relatively quickly. But this tends to rely on FMA. Thank
you in advance.

-J
___
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

[head tinderbox] failure on powerpc64/powerpc

[FreeBSD Tinderbox]

TB --- 2010-09-02 17:58:41 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-09-02 17:58:41 - starting HEAD tinderbox run for powerpc64/powerpc
TB --- 2010-09-02 17:58:41 - cleaning the object tree
TB --- 2010-09-02 17:58:59 - cvsupping the source tree
TB --- 2010-09-02 17:58:59 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/HEAD/powerpc64/powerpc/supfile
TB --- 2010-09-02 18:14:46 - building world
TB --- 2010-09-02 18:14:46 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-09-02 18:14:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-09-02 18:14:46 - TARGET=powerpc
TB --- 2010-09-02 18:14:46 - TARGET_ARCH=powerpc64
TB --- 2010-09-02 18:14:46 - TZ=UTC
TB --- 2010-09-02 18:14:46 - __MAKE_CONF=/dev/null
TB --- 2010-09-02 18:14:46 - cd /src
TB --- 2010-09-02 18:14:46 - /usr/bin/make -B buildworld
 World build started on Thu Sep  2 18:14:47 UTC 2010
 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 Sep  2 19:48:52 UTC 2010
TB --- 2010-09-02 19:48:53 - generating LINT kernel config
TB --- 2010-09-02 19:48:53 - cd /src/sys/powerpc/conf
TB --- 2010-09-02 19:48:53 - /usr/bin/make -B LINT
TB --- 2010-09-02 19:48:53 - building LINT kernel
TB --- 2010-09-02 19:48:53 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-09-02 19:48:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-09-02 19:48:53 - TARGET=powerpc
TB --- 2010-09-02 19:48:53 - TARGET_ARCH=powerpc64
TB --- 2010-09-02 19:48:53 - TZ=UTC
TB --- 2010-09-02 19:48:53 - __MAKE_CONF=/dev/null
TB --- 2010-09-02 19:48:53 - cd /src
TB --- 2010-09-02 19:48:53 - /usr/bin/make -B buildkernel KERNCONF=LINT
 Kernel build for LINT started on Thu Sep  2 19:48:53 UTC 2010
 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
 Kernel build for LINT completed on Thu Sep  2 20:12:45 UTC 2010
TB --- 2010-09-02 20:12:45 - WARNING: skipping GENERIC kernel
TB --- 2010-09-02 20:12:45 - building GENERIC64 kernel
TB --- 2010-09-02 20:12:45 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-09-02 20:12:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-09-02 20:12:45 - TARGET=powerpc
TB --- 2010-09-02 20:12:45 - TARGET_ARCH=powerpc64
TB --- 2010-09-02 20:12:45 - TZ=UTC
TB --- 2010-09-02 20:12:45 - __MAKE_CONF=/dev/null
TB --- 2010-09-02 20:12:45 - cd /src
TB --- 2010-09-02 20:12:45 - /usr/bin/make -B buildkernel KERNCONF=GENERIC64
 Kernel build for GENERIC64 started on Thu Sep  2 20:12:45 UTC 2010
 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 -O -pipe  -std=c99 -g -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/src/sys 
-I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -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  -msoft-float -fno-omit-frame-pointer -msoft-float 
-mno-altivec -ffreestanding -fstack-protector -Werror  /src/sys/kern/md5c.c
cc -c -O -pipe  -std=c99 -g -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/src/sys 
-I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -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  -msoft-float -fno-omit-frame-pointer -msoft-float 
-mno-altivec -ffreestanding -fstack-protector -Werror  /src/sys/kern/p1003_1b.c
cc -c -O -pipe  -std=c99 -g -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/src/sys 
-I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -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  -msoft-float -fno-omit-frame-pointer -msoft-float 
-mno-altivec -ffreestanding -fstack-protector -Werror  
/src/sys/kern/posix4_mib.c
cc -c -O -pipe  -std=c99 -g -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  

[head tinderbox] failure on powerpc/powerpc

[FreeBSD Tinderbox]

TB --- 2010-09-02 17:57:06 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-09-02 17:57:06 - starting HEAD tinderbox run for powerpc/powerpc
TB --- 2010-09-02 17:57:06 - cleaning the object tree
TB --- 2010-09-02 17:57:23 - cvsupping the source tree
TB --- 2010-09-02 17:57:23 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/HEAD/powerpc/powerpc/supfile
TB --- 2010-09-02 18:31:23 - building world
TB --- 2010-09-02 18:31:23 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-09-02 18:31:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-09-02 18:31:23 - TARGET=powerpc
TB --- 2010-09-02 18:31:23 - TARGET_ARCH=powerpc
TB --- 2010-09-02 18:31:23 - TZ=UTC
TB --- 2010-09-02 18:31:23 - __MAKE_CONF=/dev/null
TB --- 2010-09-02 18:31:23 - cd /src
TB --- 2010-09-02 18:31:23 - /usr/bin/make -B buildworld
 World build started on Thu Sep  2 18:31:24 UTC 2010
 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 Sep  2 20:08:50 UTC 2010
TB --- 2010-09-02 20:08:50 - generating LINT kernel config
TB --- 2010-09-02 20:08:50 - cd /src/sys/powerpc/conf
TB --- 2010-09-02 20:08:50 - /usr/bin/make -B LINT
TB --- 2010-09-02 20:08:50 - building LINT kernel
TB --- 2010-09-02 20:08:50 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-09-02 20:08:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-09-02 20:08:50 - TARGET=powerpc
TB --- 2010-09-02 20:08:50 - TARGET_ARCH=powerpc
TB --- 2010-09-02 20:08:50 - TZ=UTC
TB --- 2010-09-02 20:08:50 - __MAKE_CONF=/dev/null
TB --- 2010-09-02 20:08:50 - cd /src
TB --- 2010-09-02 20:08:50 - /usr/bin/make -B buildkernel KERNCONF=LINT
 Kernel build for LINT started on Thu Sep  2 20:08:50 UTC 2010
 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
 Kernel build for LINT completed on Thu Sep  2 20:30:19 UTC 2010
TB --- 2010-09-02 20:30:19 - building GENERIC kernel
TB --- 2010-09-02 20:30:19 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-09-02 20:30:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-09-02 20:30:19 - TARGET=powerpc
TB --- 2010-09-02 20:30:19 - TARGET_ARCH=powerpc
TB --- 2010-09-02 20:30:19 - TZ=UTC
TB --- 2010-09-02 20:30:19 - __MAKE_CONF=/dev/null
TB --- 2010-09-02 20:30:19 - cd /src
TB --- 2010-09-02 20:30:19 - /usr/bin/make -B buildkernel KERNCONF=GENERIC
 Kernel build for GENERIC started on Thu Sep  2 20:30:20 UTC 2010
 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 -O -pipe  -std=c99 -g -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/src/sys 
-I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -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  -msoft-float -fno-omit-frame-pointer -msoft-float 
-mno-altivec -ffreestanding -fstack-protector -Werror  /src/sys/kern/md5c.c
cc -c -O -pipe  -std=c99 -g -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/src/sys 
-I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -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  -msoft-float -fno-omit-frame-pointer -msoft-float 
-mno-altivec -ffreestanding -fstack-protector -Werror  /src/sys/kern/p1003_1b.c
cc -c -O -pipe  -std=c99 -g -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/src/sys 
-I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -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  -msoft-float -fno-omit-frame-pointer -msoft-float 
-mno-altivec -ffreestanding -fstack-protector -Werror  
/src/sys/kern/posix4_mib.c
cc -c -O -pipe  -std=c99 -g -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I/src/sys 
-I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL 
-DHAVE_KERNEL_OPTION_HEADERS -include 

Re: ZFS v28 is ready for wider testing.

[Pawel Jakub Dawidek]

On Tue, Aug 31, 2010 at 11:59:15PM +0200, Pawel Jakub Dawidek wrote:
[...]
 Ok, now that I know you read everything carefully, here is the patch:
 
   http://people.freebsd.org/~pjd/patches/zfs_20100831.patch.bz2

Now it is even easier to test new ZFS! :)

Here you can find VirtualBox Appliance (113MB) with
FreeBSD 9-CURRENT and ZFSv28:

http://people.freebsd.org/~pjd/misc/FreeBSD9_ZFSv28_0.1.tgz

Untar it, import it (zfsv28.ovf) to VirtualBox and have fun.

You can log in as root with no password (via virtual console or via SSH).
The system IP address is IP 192.168.56.66/24.
There are 16 ada(4) disks to play with. For example:

zfsv28:root:~# zpool create tank raidz3 ada{0,1,2,3,4,5,6,7} raidz3 
ada{8,9,10,11,12,13,14,15}
zfsv28:root:~# zpool status
  pool: tank
 state: ONLINE
 scan: none requested
config:

NAMESTATE READ WRITE CKSUM
tankONLINE   0 0 0
  raidz3-0  ONLINE   0 0 0
ada0ONLINE   0 0 0
ada1ONLINE   0 0 0
ada2ONLINE   0 0 0
ada3ONLINE   0 0 0
ada4ONLINE   0 0 0
ada5ONLINE   0 0 0
ada6ONLINE   0 0 0
ada7ONLINE   0 0 0
  raidz3-1  ONLINE   0 0 0
ada8ONLINE   0 0 0
ada9ONLINE   0 0 0
ada10   ONLINE   0 0 0
ada11   ONLINE   0 0 0
ada12   ONLINE   0 0 0
ada13   ONLINE   0 0 0
ada14   ONLINE   0 0 0
ada15   ONLINE   0 0 0

errors: No known data errors

-- 
Pawel Jakub Dawidek   http://www.wheelsystems.com
p...@freebsd.org   http://www.FreeBSD.org
FreeBSD committer Am I Evil? Yes, I Am!


pgp3nDIzwUUuC.pgp
Description: PGP signature

Trouble with a atapi-cam backup..

[Randy Stewart]

Hi all:

So I finally upgraded my 7.3stable main server to 8.1stable...

And now my backup to atapi-cam is failing.. I get:

r...@lakerest /usr/tmp]# /usr/local/bin/growisofs -Z /dev/cd0 -R -J  
backup_init.08-31-2010.gz
:-( unable to CAMGETPASSTHRU for /dev/cd0: Inappropriate ioctl for  
device



Now atapi-cam I have built into the kernel (not a loaded module).. and  
so is scsibus.. and all

its friends. Cam control seems to see the device:

[r...@lakerest /usr/tmp]# camcontrol devlist
HP DVD Writer 1140r FH23 at scbus0 target 1 lun 0 (cd0,pass0)

Any suggestions of what I left out of the kernel  would be most  
helpful..


Oh my kern.conf is:

*
include GENERIC
ident   mymachine
device  atapicam
options IPDIVERT
options IPFIREWALL
***

And its an i386

Thanks

R

-
Randall Stewart
rand...@lakerest.net




___
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

problem with wpa_supplicant

[Davide Italiano]

Hi. I've been recently upgraded to -CURRENT (9.0).
After
# make buildworld
# make buildkernel KERNCONF=MYKERNEL
# make install kernel KERNCONF=MYKERNEL

I have rebooted to single-user mode, as suggested in the documentation.
No more wireless connection. I've a intel 2200 bg wireless card,
running using the kernel built-in iwi module.

In particular, when I run wpa_supplicant -i wlan0 -c
/etc/wpa_supplicant.conf I get this:

CTRL-EVENT-SCAN-RESULTS
CTRL-EVENT-SCAN-RESULTS
CTRL-EVENT-SCAN-RESULTS
...

My wpa_supplicant.conf is:

ap_scan=1
fast_reauth=1

network={
ssid=MY_SSID
psk=MY_KEY
}

Also, my /boot/loader.conf contains

legal.intel_iwi.license_ack=1
if_iwi_load=YES

and my rc.conf

wlans_iwi0=wlan0
ifconfig_wlan0=WPA inet 192.168.1.110 netmask 0xff00
defaultrouter=192.168.1.1

Again, it worked w/ freebsd 8.1 (stable). Also, I've read in the
UPDATING file in /usr/src this:

Applications such as wpa_supplicant(8) may require a full world
build without using NO_CLEAN in order to get synchronized with the
new structure.

But, I've done a make buildworld before, isn't enough?

Thanks a lot

Davide
___
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: Call for Documentation Contributors

[Daniel Gerzo]

I actually think there is some point in this idea. The problem is that many 
times we just leave notes or warnings specific for given releases, which can 
many times lead to confusion (or people just don't notice) and as time goes and 
we cut the support for given releases they get stale (e.g. We had many of those 
for 5.x).

We could just maintain the handbook in separate branches like we do with src, 
keeping them all built online, and merge relevant things where appropriate. 
This will, however, add quite a lot (for my taste) of additional work for us.

Daniel Gerzo

On 2.9.2010, at 5:02, Ed Schouten e...@80386.nl wrote:

 * Mehmet Erol Sanliturk m.e.sanlit...@gmail.com wrote:
 Please separate Handbook with respect to distributions , i.e. , maintain a
 different Handbook for each distribution .
 
 The problem with that is that it will cause documentation for older, but
 still supported releases, to become stale. Most doc changes apply to
 functionality provided by both releases, or at least functionality that
 is MFC'd.
 
 -- 
 Ed Schouten e...@80386.nl
 WWW: http://80386.nl/

___
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: Call for Documentation Contributors

[Adam Vande More]

On Thu, Sep 2, 2010 at 5:54 PM, Daniel Gerzo dan...@rulez.sk wrote:

 I actually think there is some point in this idea. The problem is that many
 times we just leave notes or warnings specific for given releases, which can
 many times lead to confusion (or people just don't notice) and as time goes
 and we cut the support for given releases they get stale (e.g. We had many
 of those for 5.x).

 We could just maintain the handbook in separate branches like we do with
 src, keeping them all built online, and merge relevant things where
 appropriate. This will, however, add quite a lot (for my taste) of
 additional work for us.


Wouldn't it be a lot easier to have a nice article on installing
/usr/ports/misc/freebsd-doc-* from the date of the release of the installed
system?  Or maybe offer archive web access to a handbook snapshot from that
date(Django does something similar)?  Maintaining separate handbook branches
seems unrealistic if there aren't enough doc contributors to maintain one to
expectations, and IME discrepancies aren't very frequent.


-- 
Adam Vande More
___
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: Call for Documentation Contributors

[Adam Vande More]

On Thu, Sep 2, 2010 at 11:10 PM, Adam Vande More amvandem...@gmail.comwrote:

 Wouldn't it be a lot easier to have a nice article on installing
 /usr/ports/misc/freebsd-doc-* from the date of the release of the installed
 system?  Or maybe offer archive web access to a handbook snapshot from that
 date(Django does something similar)?  Maintaining separate handbook branches
 seems unrealistic if there aren't enough doc contributors to maintain one to
 expectations, and IME discrepancies aren't very frequent.


I need to add to that installing release specific handbook/documentation via
sysinstall is the Easy Button.

-- 
Adam Vande More
___
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