Re: About 802.1Q tag

[YongHyeon PYUN]

On Mon, Nov 26, 2012 at 09:54:14AM +0900, Kohji Okuno wrote:
> Hi,
> 
> Would someone check the following code?
> 
> If the hardware do not process an 802.1Q tag, the kernel repacks mbuf
> in line 578-580. But, `struct ether_header *eh' was assigned at line 484.
> 
> And, in line 611-637, because of the kernel refers old eh pointer, the
> kernel will misjudges its ether packet.
> 
> I think that `eh = mtod(m, struct ether_header *);' is needed after
> line 580.

Yes, your analysis looks correct.

> 
> Thanks,
>  Kohji Okuno
> 
> sys/net/if_ethersubr.c:
> 448   static void
> 449   ether_input_internal(struct ifnet *ifp, struct mbuf *m)
> 450   {
> 451   struct ether_header *eh;
> 
> 484   eh = mtod(m, struct ether_header *);
> 
> 554   /*
> 555* If the hardware did not process an 802.1Q tag, do this now,
> 556* to allow 802.1P priority frames to be passed to the main 
> input
> 557* path correctly.
> 558* TODO: Deal with Q-in-Q frames, but not arbitrary nesting 
> levels.
> 559*/
> 560   if ((m->m_flags & M_VLANTAG) == 0 && etype == ETHERTYPE_VLAN) {
>   
> 578   bcopy((char *)evl, (char *)evl + ETHER_VLAN_ENCAP_LEN,
> 579   ETHER_HDR_LEN - ETHER_TYPE_LEN);
> 580   m_adj(m, ETHER_VLAN_ENCAP_LEN);
> 581   }
> 
> 610   
> 611   #if defined(INET) || defined(INET6)
> 612   /*
> 613* Clear M_PROMISC on frame so that carp(4) will see it when the
> 614* mbuf flows up to Layer 3.
> 615* FreeBSD's implementation of carp(4) uses the inprotosw
> 616* to dispatch IPPROTO_CARP. carp(4) also allocates its own
> 617* Ethernet addresses of the form 00:00:5e:00:01:xx, which
> 618* is outside the scope of the M_PROMISC test below.
> 619* TODO: Maintain a hash table of ethernet addresses other than
> 620* ether_dhost which may be active on this ifp.
> 621*/
> 622   if (ifp->if_carp && (*carp_forus_p)(ifp, eh->ether_dhost)) {
> 623   m->m_flags &= ~M_PROMISC;
> 624   } else
> 625   #endif
> 626   {
> 627   /*
> 628* If the frame received was not for our MAC address, 
> set the
> 629* M_PROMISC flag on the mbuf chain. The frame may need 
> to
> 630* be seen by the rest of the Ethernet input path in 
> case of
> 631* re-entry (e.g. bridge, vlan, netgraph) but should 
> not be
> 632* seen by upper protocol layers.
> 633*/
> 634   if (!ETHER_IS_MULTICAST(eh->ether_dhost) &&
> 635   bcmp(IF_LLADDR(ifp), eh->ether_dhost, 
> ETHER_ADDR_LEN) != 0)
> 636   m->m_flags |= M_PROMISC;
> 637   }
___
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: syscall cost freebsd vs linux ?

[Lukasz Wojcik]

On 11/19/12 20:32, Luigi Rizzo wrote:

today i was comparing the performance of some netmap-related code
on FreeBSD and Linux (RELENG_9 vs 3.2) and i was surprised to see that
our system calls are significantly slower.
On comparable hardware (i7-2600k vs E5-1650) the syscall
getppid() takes about 95ns on FreeBSD and 38ns on linux.

(i make sure not to use gettimeofday(), which in linux is through vdso,
and getpid(), which is cached by glibc).

Any idea on why there is this difference and whether/how
we can reduce it ?



I'm curious about how did you measure that ? Could you write some more 
about your methodology ?


-LW


cheers
luigi
___
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"



___
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 compiled kernel panic when mounting zfs root on i386

[sig6247]

Hi,

Just checked out r243529, this only happens when the kernel is compiled
by clang, and only on i386, either recompiling the kernel with gcc or
booting from a UFS root works fine. Is it a known problem?

Thanks,

--
WARNING: WITNESS option enabled, expect reduced performance.
Trying to mount root from zfs:zroot []...

Fatal double fault:
eip = 0xc0adc37d
esp = 0xc86bffc8
ebp = 0xc86c003c
cpuid = 1; apic id = 01
panic: double fault
cpuid = 1
KDB: enter: panic
[ thread pid 1 tid 12 ]
Stopped at  kdb_enter+0x3d: movl$0,kdb_why
db> bt
Tracing pid 1 tid 12 td 0xc89efbc0
kdb_enter(c1064aa4,c1064aa4,c10b806f,c139e3b8,f5eacada,...) at kdb_enter+0x3d
panic(c10b806f,1,1,1,c86c003c,...) at panic+0x14b
dblfault_handler() at dblfault_handler+0xab
--- trap 0x17, eip = 0xc0adc37d, esp = 0xc86bffc8, ebp = 0xc86c003c ---
witness_checkorder(c1fd7508,9,c109df18,7fa,0,...) at witness_checkorder+0x37d
__mtx_lock_flags(c1fd7518,0,c109df18,7fa,c135d918,...) at __mtx_lock_flags+0x87
uma_zalloc_arg(c1fd66c0,0,1,4d3,c86c0110,...) at uma_zalloc_arg+0x605
vm_map_insert(c1fd508c,c13dfc10,bb1f000,0,cba1e000,...) at vm_map_insert+0x499
kmem_back(c1fd508c,cba1e000,1000,3,c86c01d4,...) at kmem_back+0x76
kmem_malloc(c1fd508c,1000,3) at kmem_malloc+0x250
page_alloc(c1fd1d80,1000,c86c020b,3,c1fd1d80,...) at page_alloc+0x27
keg_alloc_slab(103,4,c109df18,870,cb99ef6c,...) at keg_alloc_slab+0xc3
keg_fetch_slab(103,c1fd1d80,cb99ef6c,c1fc8230,c86c02c0,...) at 
keg_fetch_slab+0xe2
zone_fetch_slab(c1fd1d80,c1fd0480,103,826,0,...) at zone_fetch_slab+0x43
uma_zalloc_arg(c1fd1d80,0,102,3,2,...) at uma_zalloc_arg+0x3f2
malloc(4c,c1686100,102,c86c0388,c173d09a,...) at malloc+0xe9
zfs_kmem_alloc(4c,102,cb618820,c89efbc0,cb618820,...) at zfs_kmem_alloc+0x20
vdev_mirror_io_start(cb8218a0,10,cb8218a0,1,0,...) at vdev_mirror_io_start+0x14a
zio_vdev_io_start(cb8218a0,c89efbc0,0,cb8218a0,c86c0600,...) at 
zio_vdev_io_start+0x228
zio_execute(cb8218a0,cb618000,cba1b640,cb90,400,...) at zio_execute+0x106
spa_load_verify_cb(cb618000,0,cba1b640,cb884b40,c86c0600,...) at 
spa_load_verify_cb+0x89
traverse_visitbp(cb884b40,cba1b640,c86c0600,c86c0ba0,0,...) at 
traverse_visitbp+0x29f
traverse_dnode(cb884b40,0,0,8b,0,...) at traverse_dnode+0x92
traverse_visitbp(cb884bb8,cba07200,c86c0890,cb884bf4,c16ce7e0,...) at 
traverse_visitbp+0xe47
traverse_visitbp(cb884bf4,cb9bf840,c86c0968,c86c0ba0,0,...) at 
traverse_visitbp+0xf32
traverse_dnode(cb884bf4,0,0,0,0,...) at traverse_dnode+0x92
traverse_visitbp(0,cb618398,c86c0b50,2,cb9f1c78,...) at traverse_visitbp+0x96d
traverse_impl(0,0,cb618398,3e1,0,...) at traverse_impl+0x268
traverse_pool(cb618000,3e1,0,d,c1727830,...) at traverse_pool+0x79
spa_load(0,1,c86c0ec4,1e,0,...) at spa_load+0x1dde
spa_load(0,0,c13d8c94,1,3,...) at spa_load+0x11a5
spa_load_best(0,,,1,c0adc395,...) at spa_load_best+0x71
spa_open_common(c17e0e1e,0,0,c86c1190,c16f5a1c,...) at spa_open_common+0x11a
spa_open(c86c1078,c86c1074,c17e0e1e,c135d918,c1fd7798,...) at spa_open+0x27
dsl_dir_open_spa(0,cb770030,c17e11b1,c86c11f8,c86c11f4,...) at 
dsl_dir_open_spa+0x6c
dsl_dataset_hold(cb770030,cb613800,c86c1240,cb613800,cb613800,...) at 
dsl_dataset_hold+0x3a
dsl_dataset_own(cb770030,0,cb613800,c86c1240,c1684e30,...) at 
dsl_dataset_own+0x21
dmu_objset_own(cb770030,2,1,cb613800,c86c1290,...) at dmu_objset_own+0x2a
zfsvfs_create(cb770030,c86c13ac,c17ee05d,681,0,...) at zfsvfs_create+0x4c
zfs_mount(cb78ed20,c17f411c,c9ff4600,c89cae80,0,...) at zfs_mount+0x42c
vfs_donmount(c89efbc0,4000,0,c86c1790,cb6c0800,...) at vfs_donmount+0xc6d
kernel_mount(cb7700b0,4000,0,0,1,...) at kernel_mount+0x6b
parse_mount(cb7700e0,c1194498,0,1,0,...) at parse_mount+0x606
vfs_mountroot(c13d95b0,4,c105c042,2bb,0,...) at vfs_mountroot+0x6cf
start_init(0,c86c1d08,c105e94c,3db,0,...) at start_init+0x6a
fork_exit(c0a42090,0,c86c1d08) at fork_exit+0x7f
fork_trampoline() at fork_trampoline+0x8
--- trap 0, eip = 0, esp = 0xc86c1d40, ebp = 0 ---
db> 
___
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: Upgrading FreeBSD to use the NEW pf syntax.

[Gleb Smirnoff]

  Paul,

On Sat, Nov 24, 2012 at 02:11:32PM -, Paul Webster wrote:
P> I only really need one question answered in honesty;
P> 
P> I personally think that by forking our own version of PF we have  
P> essentially made something totally different to what everyone wants to  
P> use. Which is fine, but because of that development of new features have  
P> dropped behind.
P> 
P> If we had kept up with OpenBSD's version even if we trailed it by one  
P> MAJOR release; at least part of the development would have been done.
P> 
P> So now we end up in a situation where we have these firewalls,  
P> IPFW2,ipf,pf(modded) and users wanting the newer features of OpenBSD's pf.  
P> So timewise the fork of pf may have actually cost more in time rather than  
P> less.
P> 
P> I don't however think the 'solution' to the problem is just to say no to  
P> the userbase by not even trying to port across the newer pf. I think we  
P> should look at bringing it across, slowly and seeing what the uptake is  
P> like; in a few MAJOR releases we can start to look at which of the  
P> firewalls realistically are not used that much and should be deprecated.

  If you see a large userbase that eagers to see new pf, then you can port
it to FreeBSD, maintain it, catch up with new versions from OpenBSD,
and so on. No one forbids you doing that.

-- 
Totus tuus, Glebius.
___
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 compiled kernel panic when mounting zfs root on i386

[Konstantin Belousov]

On Mon, Nov 26, 2012 at 06:31:34AM -0800, sig6247 wrote:
> 
> Hi,
> 
> Just checked out r243529, this only happens when the kernel is compiled
> by clang, and only on i386, either recompiling the kernel with gcc or
> booting from a UFS root works fine. Is it a known problem?
It looks like that clang uses more stack than gcc, and zfs makes quite
deep call chains.

It would be a waste, generally, to increase the init process kernel
stack size only to pacify zfs. And I suspect that it would not help
in the similar situations when the same procedure initiated for non-root
mounts.

> 
> Thanks,
> 
> --
> WARNING: WITNESS option enabled, expect reduced performance.
> Trying to mount root from zfs:zroot []...
> 
> Fatal double fault:
> eip = 0xc0adc37d
> esp = 0xc86bffc8
> ebp = 0xc86c003c
> cpuid = 1; apic id = 01
> panic: double fault
> cpuid = 1
> KDB: enter: panic
> [ thread pid 1 tid 12 ]
> Stopped at  kdb_enter+0x3d: movl$0,kdb_why
> db> bt
> Tracing pid 1 tid 12 td 0xc89efbc0
> kdb_enter(c1064aa4,c1064aa4,c10b806f,c139e3b8,f5eacada,...) at kdb_enter+0x3d
> panic(c10b806f,1,1,1,c86c003c,...) at panic+0x14b
> dblfault_handler() at dblfault_handler+0xab
> --- trap 0x17, eip = 0xc0adc37d, esp = 0xc86bffc8, ebp = 0xc86c003c ---
> witness_checkorder(c1fd7508,9,c109df18,7fa,0,...) at witness_checkorder+0x37d
> __mtx_lock_flags(c1fd7518,0,c109df18,7fa,c135d918,...) at 
> __mtx_lock_flags+0x87
> uma_zalloc_arg(c1fd66c0,0,1,4d3,c86c0110,...) at uma_zalloc_arg+0x605
> vm_map_insert(c1fd508c,c13dfc10,bb1f000,0,cba1e000,...) at vm_map_insert+0x499
> kmem_back(c1fd508c,cba1e000,1000,3,c86c01d4,...) at kmem_back+0x76
> kmem_malloc(c1fd508c,1000,3) at kmem_malloc+0x250
> page_alloc(c1fd1d80,1000,c86c020b,3,c1fd1d80,...) at page_alloc+0x27
> keg_alloc_slab(103,4,c109df18,870,cb99ef6c,...) at keg_alloc_slab+0xc3
> keg_fetch_slab(103,c1fd1d80,cb99ef6c,c1fc8230,c86c02c0,...) at 
> keg_fetch_slab+0xe2
> zone_fetch_slab(c1fd1d80,c1fd0480,103,826,0,...) at zone_fetch_slab+0x43
> uma_zalloc_arg(c1fd1d80,0,102,3,2,...) at uma_zalloc_arg+0x3f2
> malloc(4c,c1686100,102,c86c0388,c173d09a,...) at malloc+0xe9
> zfs_kmem_alloc(4c,102,cb618820,c89efbc0,cb618820,...) at zfs_kmem_alloc+0x20
> vdev_mirror_io_start(cb8218a0,10,cb8218a0,1,0,...) at 
> vdev_mirror_io_start+0x14a
> zio_vdev_io_start(cb8218a0,c89efbc0,0,cb8218a0,c86c0600,...) at 
> zio_vdev_io_start+0x228
> zio_execute(cb8218a0,cb618000,cba1b640,cb90,400,...) at zio_execute+0x106
> spa_load_verify_cb(cb618000,0,cba1b640,cb884b40,c86c0600,...) at 
> spa_load_verify_cb+0x89
> traverse_visitbp(cb884b40,cba1b640,c86c0600,c86c0ba0,0,...) at 
> traverse_visitbp+0x29f
> traverse_dnode(cb884b40,0,0,8b,0,...) at traverse_dnode+0x92
> traverse_visitbp(cb884bb8,cba07200,c86c0890,cb884bf4,c16ce7e0,...) at 
> traverse_visitbp+0xe47
> traverse_visitbp(cb884bf4,cb9bf840,c86c0968,c86c0ba0,0,...) at 
> traverse_visitbp+0xf32
> traverse_dnode(cb884bf4,0,0,0,0,...) at traverse_dnode+0x92
> traverse_visitbp(0,cb618398,c86c0b50,2,cb9f1c78,...) at traverse_visitbp+0x96d
> traverse_impl(0,0,cb618398,3e1,0,...) at traverse_impl+0x268
> traverse_pool(cb618000,3e1,0,d,c1727830,...) at traverse_pool+0x79
> spa_load(0,1,c86c0ec4,1e,0,...) at spa_load+0x1dde
> spa_load(0,0,c13d8c94,1,3,...) at spa_load+0x11a5
> spa_load_best(0,,,1,c0adc395,...) at spa_load_best+0x71
> spa_open_common(c17e0e1e,0,0,c86c1190,c16f5a1c,...) at spa_open_common+0x11a
> spa_open(c86c1078,c86c1074,c17e0e1e,c135d918,c1fd7798,...) at spa_open+0x27
> dsl_dir_open_spa(0,cb770030,c17e11b1,c86c11f8,c86c11f4,...) at 
> dsl_dir_open_spa+0x6c
> dsl_dataset_hold(cb770030,cb613800,c86c1240,cb613800,cb613800,...) at 
> dsl_dataset_hold+0x3a
> dsl_dataset_own(cb770030,0,cb613800,c86c1240,c1684e30,...) at 
> dsl_dataset_own+0x21
> dmu_objset_own(cb770030,2,1,cb613800,c86c1290,...) at dmu_objset_own+0x2a
> zfsvfs_create(cb770030,c86c13ac,c17ee05d,681,0,...) at zfsvfs_create+0x4c
> zfs_mount(cb78ed20,c17f411c,c9ff4600,c89cae80,0,...) at zfs_mount+0x42c
> vfs_donmount(c89efbc0,4000,0,c86c1790,cb6c0800,...) at vfs_donmount+0xc6d
> kernel_mount(cb7700b0,4000,0,0,1,...) at kernel_mount+0x6b
> parse_mount(cb7700e0,c1194498,0,1,0,...) at parse_mount+0x606
> vfs_mountroot(c13d95b0,4,c105c042,2bb,0,...) at vfs_mountroot+0x6cf
> start_init(0,c86c1d08,c105e94c,3db,0,...) at start_init+0x6a
> fork_exit(c0a42090,0,c86c1d08) at fork_exit+0x7f
> fork_trampoline() at fork_trampoline+0x8
> --- trap 0, eip = 0, esp = 0xc86c1d40, ebp = 0 ---
> db> 
> ___
> 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"


pgpQ2uVFtLShF.pgp
Description: PGP signature

Re: after upgrade, can't restart apache via cron

[Mateusz Guzik]

On Fri, Nov 23, 2012 at 11:37:54PM +0900, Hiroki Sato wrote:
> "Michael W. Lucas"  wrote
>   in <20121123031753.ga59...@bewilderbeast.blackhelicopters.org>:
> 
> mw> eval: setfib: not found
> mw> /usr/local/etc/rc.d/apache22: WARNING: failed to start apache22
> mw>
> mw> If I run /usr/local/etc/rc.d/apache22 restart from the command line, I
> mw> can restart httpd without trouble.
> mw>
> mw> Any thoughts?
> 
>  This was due to $PATH in the cron job as already pointed out, but
>  this should not happen.  I attached a patch to use full-path for
>  external commands in rc.subr.  If there is no objection to this
>  change I will commit it.
> 

service(8) tries to sanitize stuff before executing scripts. How about
making this the default behaviour?

Currently stuff like PATH "leak" to rc scripts and this can be harmful
(for instance daemon was happily executing stuff from /usr/local/bin,
yet after reboot it stopped working).

Also I doubt anyone relies on current environment and what not to start
a service, but we can provide another target tha would start the service
without sanitizing in case this is needed.

-- 
Mateusz Guzik 
___
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: About 802.1Q tag

[Gleb Smirnoff]

  Kohji,

On Mon, Nov 26, 2012 at 09:54:14AM +0900, Kohji Okuno wrote:
K> Would someone check the following code?
K> 
K> If the hardware do not process an 802.1Q tag, the kernel repacks mbuf
K> in line 578-580. But, `struct ether_header *eh' was assigned at line 484.
K> 
K> And, in line 611-637, because of the kernel refers old eh pointer, the
K> kernel will misjudges its ether packet.
K> 
K> I think that `eh = mtod(m, struct ether_header *);' is needed after
K> line 580.

Committed, thanks!

-- 
Totus tuus, Glebius.
___
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"

Samsung 830 and ZFS TRIM

[Johannes Dieterich]

Hello,

(initially posted this to -questions@ a week ago, w/o reply)

I installed CURRENT on a new Thinkpad equipped with a Samsung 830 SSD:

ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
ada0:  ATA-9 SATA 3.x device
ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 122104MB (250069680 512 byte sectors: 1H 63S/T 16383C)
ada0: Previously was known as ad4

as the setup is ZFS+GELI based (on ada0), I enabled ZFS TRIM support in 
loader.conf.


Interestingly, I encounter an IMHO strange behavior with the stats on that:

kstat.zfs.misc.zio_trim.zio_trim_bytes: 755712
kstat.zfs.misc.zio_trim.zio_trim_success: 97
kstat.zfs.misc.zio_trim.zio_trim_unsupported: 7891
kstat.zfs.misc.zio_trim.zio_trim_failed: 0

It seems unintuitive to me why the unsupported counter first increases 
(seems to stay constant after that each boot) and then slowly the 
success counter increases as well.


Probably there is a trivial explanation (GELI?) and/or fix for this that 
anyone is willing to share?


If you need further information, let me know.

Thanks a lot

Johannes
___
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 compiled kernel panic when mounting zfs root on i386

[Bruce Evans]

On Mon, 26 Nov 2012, Konstantin Belousov wrote:


On Mon, Nov 26, 2012 at 06:31:34AM -0800, sig6247 wrote:


Just checked out r243529, this only happens when the kernel is compiled
by clang, and only on i386, either recompiling the kernel with gcc or
booting from a UFS root works fine. Is it a known problem?

It looks like that clang uses more stack than gcc, and zfs makes quite
deep call chains.

It would be a waste, generally, to increase the init process kernel
stack size only to pacify zfs. And I suspect that it would not help
in the similar situations when the same procedure initiated for non-root
mounts.


Or to pacify clang...


--
WARNING: WITNESS option enabled, expect reduced performance.
Trying to mount root from zfs:zroot []...

Fatal double fault:
eip = 0xc0adc37d
esp = 0xc86bffc8
ebp = 0xc86c003c
cpuid = 1; apic id = 01
panic: double fault
cpuid = 1
KDB: enter: panic
[ thread pid 1 tid 12 ]
Stopped at  kdb_enter+0x3d: movl$0,kdb_why
db> bt
Tracing pid 1 tid 12 td 0xc89efbc0
kdb_enter(c1064aa4,c1064aa4,c10b806f,c139e3b8,f5eacada,...) at kdb_enter+0x3d
panic(c10b806f,1,1,1,c86c003c,...) at panic+0x14b
dblfault_handler() at dblfault_handler+0xab
--- trap 0x17, eip = 0xc0adc37d, esp = 0xc86bffc8, ebp = 0xc86c003c ---
witness_checkorder(c1fd7508,9,c109df18,7fa,0,...) at witness_checkorder+0x37d
__mtx_lock_flags(c1fd7518,0,c109df18,7fa,c135d918,...) at __mtx_lock_flags+0x87
uma_zalloc_arg(c1fd66c0,0,1,4d3,c86c0110,...) at uma_zalloc_arg+0x605
vm_map_insert(c1fd508c,c13dfc10,bb1f000,0,cba1e000,...) at vm_map_insert+0x499
kmem_back(c1fd508c,cba1e000,1000,3,c86c01d4,...) at kmem_back+0x76
kmem_malloc(c1fd508c,1000,3) at kmem_malloc+0x250
page_alloc(c1fd1d80,1000,c86c020b,3,c1fd1d80,...) at page_alloc+0x27
keg_alloc_slab(103,4,c109df18,870,cb99ef6c,...) at keg_alloc_slab+0xc3
keg_fetch_slab(103,c1fd1d80,cb99ef6c,c1fc8230,c86c02c0,...) at 
keg_fetch_slab+0xe2
zone_fetch_slab(c1fd1d80,c1fd0480,103,826,0,...) at zone_fetch_slab+0x43
uma_zalloc_arg(c1fd1d80,0,102,3,2,...) at uma_zalloc_arg+0x3f2
malloc(4c,c1686100,102,c86c0388,c173d09a,...) at malloc+0xe9
zfs_kmem_alloc(4c,102,cb618820,c89efbc0,cb618820,...) at zfs_kmem_alloc+0x20
vdev_mirror_io_start(cb8218a0,10,cb8218a0,1,0,...) at vdev_mirror_io_start+0x14a
zio_vdev_io_start(cb8218a0,c89efbc0,0,cb8218a0,c86c0600,...) at 
zio_vdev_io_start+0x228
zio_execute(cb8218a0,cb618000,cba1b640,cb90,400,...) at zio_execute+0x106
spa_load_verify_cb(cb618000,0,cba1b640,cb884b40,c86c0600,...) at 
spa_load_verify_cb+0x89
traverse_visitbp(cb884b40,cba1b640,c86c0600,c86c0ba0,0,...) at 
traverse_visitbp+0x29f
traverse_dnode(cb884b40,0,0,8b,0,...) at traverse_dnode+0x92
traverse_visitbp(cb884bb8,cba07200,c86c0890,cb884bf4,c16ce7e0,...) at 
traverse_visitbp+0xe47
traverse_visitbp(cb884bf4,cb9bf840,c86c0968,c86c0ba0,0,...) at 
traverse_visitbp+0xf32
traverse_dnode(cb884bf4,0,0,0,0,...) at traverse_dnode+0x92
traverse_visitbp(0,cb618398,c86c0b50,2,cb9f1c78,...) at traverse_visitbp+0x96d
traverse_impl(0,0,cb618398,3e1,0,...) at traverse_impl+0x268
traverse_pool(cb618000,3e1,0,d,c1727830,...) at traverse_pool+0x79
spa_load(0,1,c86c0ec4,1e,0,...) at spa_load+0x1dde
spa_load(0,0,c13d8c94,1,3,...) at spa_load+0x11a5
spa_load_best(0,,,1,c0adc395,...) at spa_load_best+0x71
spa_open_common(c17e0e1e,0,0,c86c1190,c16f5a1c,...) at spa_open_common+0x11a
spa_open(c86c1078,c86c1074,c17e0e1e,c135d918,c1fd7798,...) at spa_open+0x27
dsl_dir_open_spa(0,cb770030,c17e11b1,c86c11f8,c86c11f4,...) at 
dsl_dir_open_spa+0x6c
dsl_dataset_hold(cb770030,cb613800,c86c1240,cb613800,cb613800,...) at 
dsl_dataset_hold+0x3a
dsl_dataset_own(cb770030,0,cb613800,c86c1240,c1684e30,...) at 
dsl_dataset_own+0x21
dmu_objset_own(cb770030,2,1,cb613800,c86c1290,...) at dmu_objset_own+0x2a
zfsvfs_create(cb770030,c86c13ac,c17ee05d,681,0,...) at zfsvfs_create+0x4c
zfs_mount(cb78ed20,c17f411c,c9ff4600,c89cae80,0,...) at zfs_mount+0x42c
vfs_donmount(c89efbc0,4000,0,c86c1790,cb6c0800,...) at vfs_donmount+0xc6d
kernel_mount(cb7700b0,4000,0,0,1,...) at kernel_mount+0x6b
parse_mount(cb7700e0,c1194498,0,1,0,...) at parse_mount+0x606
vfs_mountroot(c13d95b0,4,c105c042,2bb,0,...) at vfs_mountroot+0x6cf
start_init(0,c86c1d08,c105e94c,3db,0,...) at start_init+0x6a
fork_exit(c0a42090,0,c86c1d08) at fork_exit+0x7f
fork_trampoline() at fork_trampoline+0x8
--- trap 0, eip = 0, esp = 0xc86c1d40, ebp = 0 ---
db>


43 deep (before the double fault) is disgusting, but even if clang has
broken stack alignment due to a wrong default and no
-mpreferred-stack-boundary to fix it, that's still only about 8*43
extra bytes (8 for the average extra stack to align to 16 bytes).
Probably zfs is also putting large data structures on the stack.

It would be useful if the stack trace printed the the stack pointer
on every function call, so that you could see how much stack each
function used.

All those ', ...' printed after 5 args show further appare

Re: syscall cost freebsd vs linux ?

[Luigi Rizzo]

a quick and easy way is to run the syscall in a tight loop for a sufficient
long time (1s or more) and use "time" to measure it.

At 100ns per call you need about 10M cycles to do one second.

cheers
luigi



On Mon, Nov 26, 2012 at 3:39 AM, Lukasz Wojcik wrote:

> On 11/19/12 20:32, Luigi Rizzo wrote:
>
>> today i was comparing the performance of some netmap-related code
>> on FreeBSD and Linux (RELENG_9 vs 3.2) and i was surprised to see that
>> our system calls are significantly slower.
>> On comparable hardware (i7-2600k vs E5-1650) the syscall
>> getppid() takes about 95ns on FreeBSD and 38ns on linux.
>>
>> (i make sure not to use gettimeofday(), which in linux is through vdso,
>> and getpid(), which is cached by glibc).
>>
>> Any idea on why there is this difference and whether/how
>> we can reduce it ?
>>
>>
> I'm curious about how did you measure that ? Could you write some more
> about your methodology ?
>
> -LW
>
>  cheers
>> luigi
>> __**_
>> freebsd-current@freebsd.org mailing list
>> http://lists.freebsd.org/**mailman/listinfo/freebsd-**current
>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@**
>> freebsd.org "
>>
>
>
>


-- 
-+---
 Prof. Luigi RIZZO, ri...@iet.unipi.it  . Dip. di Ing. dell'Informazione
 http://www.iet.unipi.it/~luigi/. Universita` di Pisa
 TEL  +39-050-2211611   . via Diotisalvi 2
 Mobile   +39-338-6809875   . 56122 PISA (Italy)
-+---
___
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: syscall cost freebsd vs linux ?

[Sergey Kandaurov]

On 26 November 2012 15:39, Lukasz Wojcik  wrote:
> On 11/19/12 20:32, Luigi Rizzo wrote:
>>
>> today i was comparing the performance of some netmap-related code
>> on FreeBSD and Linux (RELENG_9 vs 3.2) and i was surprised to see that
>> our system calls are significantly slower.
>> On comparable hardware (i7-2600k vs E5-1650) the syscall
>> getppid() takes about 95ns on FreeBSD and 38ns on linux.
>>
>> (i make sure not to use gettimeofday(), which in linux is through vdso,
>> and getpid(), which is cached by glibc).
>>
>> Any idea on why there is this difference and whether/how
>> we can reduce it ?
>>
>
> I'm curious about how did you measure that ? Could you write some more about
> your methodology ?

There is a nice tool at /usr/src/tools/tools/syscall_timing

-- 
wbr,
pluknet
___
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 --- 2012-11-27 04:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca
TB --- 2012-11-27 04:40:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2012-11-27 04:40:00 - starting HEAD tinderbox run for arm/arm
TB --- 2012-11-27 04:40:00 - cleaning the object tree
TB --- 2012-11-27 04:40:00 - checking out /src from 
svn://svn.freebsd.org/base/head
TB --- 2012-11-27 04:40:00 - cd /tinderbox/HEAD/arm/arm
TB --- 2012-11-27 04:40:00 - /usr/local/bin/svn cleanup /src
TB --- 2012-11-27 04:43:57 - /usr/local/bin/svn update /src
TB --- 2012-11-27 04:44:12 - At svn revision 243595
TB --- 2012-11-27 04:44:13 - building world
TB --- 2012-11-27 04:44:13 - CROSS_BUILD_TESTING=YES
TB --- 2012-11-27 04:44:13 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-11-27 04:44:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-11-27 04:44:13 - SRCCONF=/dev/null
TB --- 2012-11-27 04:44:13 - TARGET=arm
TB --- 2012-11-27 04:44:13 - TARGET_ARCH=arm
TB --- 2012-11-27 04:44:13 - TZ=UTC
TB --- 2012-11-27 04:44:13 - __MAKE_CONF=/dev/null
TB --- 2012-11-27 04:44:13 - cd /src
TB --- 2012-11-27 04:44:13 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Tue Nov 27 04:44:21 UTC 2012
>>> 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 Tue Nov 27 05:42:07 UTC 2012
TB --- 2012-11-27 05:42:07 - generating LINT kernel config
TB --- 2012-11-27 05:42:07 - cd /src/sys/arm/conf
TB --- 2012-11-27 05:42:07 - /usr/bin/make -B LINT
TB --- 2012-11-27 05:42:07 - cd /src/sys/arm/conf
TB --- 2012-11-27 05:42:07 - /usr/sbin/config -m LINT
TB --- 2012-11-27 05:42:07 - building LINT kernel
TB --- 2012-11-27 05:42:07 - CROSS_BUILD_TESTING=YES
TB --- 2012-11-27 05:42:07 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-11-27 05:42:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-11-27 05:42:07 - SRCCONF=/dev/null
TB --- 2012-11-27 05:42:07 - TARGET=arm
TB --- 2012-11-27 05:42:07 - TARGET_ARCH=arm
TB --- 2012-11-27 05:42:07 - TZ=UTC
TB --- 2012-11-27 05:42:07 - __MAKE_CONF=/dev/null
TB --- 2012-11-27 05:42:07 - cd /src
TB --- 2012-11-27 05:42:07 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Tue Nov 27 05:42:07 UTC 2012
>>> 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
[...]
/src/sys/dev/ath/if_ath_tdma.c:161: error: 'ATH_ALQ_TDMA_TIMER_SET' undeclared 
(first use in this function)
/src/sys/dev/ath/if_ath_tdma.c:161: error: (Each undeclared identifier is 
reported only once
/src/sys/dev/ath/if_ath_tdma.c:161: error: for each function it appears in.)
/src/sys/dev/ath/if_ath_tdma.c:162: error: storage size of 't' isn't known
/src/sys/dev/ath/if_ath_tdma.c:171: warning: implicit declaration of function 
'if_ath_alq_post'
/src/sys/dev/ath/if_ath_tdma.c:171: warning: nested extern declaration of 
'if_ath_alq_post' [-Wnested-externs]
/src/sys/dev/ath/if_ath_tdma.c:171: error: 'struct ath_softc' has no member 
named 'sc_alq'
/src/sys/dev/ath/if_ath_tdma.c:162: warning: unused variable 't' 
[-Wunused-variable]
*** [if_ath_tdma.o] Error code 1

Stop in /obj/arm.arm/src/sys/LINT.
*** [buildkernel] Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2012-11-27 05:45:58 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2012-11-27 05:45:58 - ERROR: failed to build LINT kernel
TB --- 2012-11-27 05:45:58 - 2703.08 user 586.17 system 3957.97 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"

Re: syscall cost freebsd vs linux ?

[Andrey Zonov]

On 11/19/12 11:32 PM, Luigi Rizzo wrote:
> today i was comparing the performance of some netmap-related code
> on FreeBSD and Linux (RELENG_9 vs 3.2) and i was surprised to see that
> our system calls are significantly slower.
> On comparable hardware (i7-2600k vs E5-1650) the syscall
> getppid() takes about 95ns on FreeBSD and 38ns on linux.
> 
> (i make sure not to use gettimeofday(), which in linux is through vdso,
> and getpid(), which is cached by glibc).
> 
> Any idea on why there is this difference and whether/how
> we can reduce it ?
> 

This is the cost of blocking mutexes.  Linux uses RCU instead [1].

Here are the numbers on current:

$ time ./getppid 1

real0m22.926s
user0m2.252s
sys 0m20.669s

After locking removing (patch below):

$ time ./getppid 1

real0m15.224s
user0m2.355s
sys 0m12.868s

Unfortunately, RCU can be used only in GPL code, but we can use "passive
serialization" for simple deref.  And even more, it's already
implemented in NetBSD.


[1]
https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=kernel/timer.c;h=367d008584823a6fe01ed013cda8c3693fcfd761;hb=HEAD#l1411
[2]
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/kern/subr_pserialize.c?rev=1.5&content-type=text/x-cvsweb-markup

diff --git a/sys/kern/kern_prot.c b/sys/kern/kern_prot.c
index 7c46b2d..a13a17c 100644
--- a/sys/kern/kern_prot.c
+++ b/sys/kern/kern_prot.c
@@ -123,9 +123,7 @@ sys_getppid(struct thread *td, struct getppid_args *uap)
 {
struct proc *p = td->td_proc;

-   PROC_LOCK(p);
td->td_retval[0] = p->p_pptr->p_pid;
-   PROC_UNLOCK(p);
return (0);
 }


-- 
Andrey Zonov



signature.asc
Description: OpenPGP digital signature

[head tinderbox] failure on ia64/ia64

[FreeBSD Tinderbox]

TB --- 2012-11-27 05:45:58 - tinderbox 2.9 running on freebsd-current.sentex.ca
TB --- 2012-11-27 05:45:58 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2012-11-27 05:45:58 - starting HEAD tinderbox run for ia64/ia64
TB --- 2012-11-27 05:45:58 - cleaning the object tree
TB --- 2012-11-27 05:45:58 - checking out /src from 
svn://svn.freebsd.org/base/head
TB --- 2012-11-27 05:45:58 - cd /tinderbox/HEAD/ia64/ia64
TB --- 2012-11-27 05:45:58 - /usr/local/bin/svn cleanup /src
TB --- 2012-11-27 05:46:26 - /usr/local/bin/svn update /src
TB --- 2012-11-27 05:46:32 - At svn revision 243595
TB --- 2012-11-27 05:46:33 - building world
TB --- 2012-11-27 05:46:33 - CROSS_BUILD_TESTING=YES
TB --- 2012-11-27 05:46:33 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-11-27 05:46:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-11-27 05:46:33 - SRCCONF=/dev/null
TB --- 2012-11-27 05:46:33 - TARGET=ia64
TB --- 2012-11-27 05:46:33 - TARGET_ARCH=ia64
TB --- 2012-11-27 05:46:33 - TZ=UTC
TB --- 2012-11-27 05:46:33 - __MAKE_CONF=/dev/null
TB --- 2012-11-27 05:46:33 - cd /src
TB --- 2012-11-27 05:46:33 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Tue Nov 27 05:46:38 UTC 2012
>>> 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 Tue Nov 27 07:23:45 UTC 2012
TB --- 2012-11-27 07:23:45 - generating LINT kernel config
TB --- 2012-11-27 07:23:45 - cd /src/sys/ia64/conf
TB --- 2012-11-27 07:23:45 - /usr/bin/make -B LINT
TB --- 2012-11-27 07:23:45 - cd /src/sys/ia64/conf
TB --- 2012-11-27 07:23:45 - /usr/sbin/config -m LINT
TB --- 2012-11-27 07:23:45 - building LINT kernel
TB --- 2012-11-27 07:23:45 - CROSS_BUILD_TESTING=YES
TB --- 2012-11-27 07:23:45 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-11-27 07:23:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-11-27 07:23:45 - SRCCONF=/dev/null
TB --- 2012-11-27 07:23:45 - TARGET=ia64
TB --- 2012-11-27 07:23:45 - TARGET_ARCH=ia64
TB --- 2012-11-27 07:23:45 - TZ=UTC
TB --- 2012-11-27 07:23:45 - __MAKE_CONF=/dev/null
TB --- 2012-11-27 07:23:45 - cd /src
TB --- 2012-11-27 07:23:45 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Tue Nov 27 07:23:45 UTC 2012
>>> 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
[...]
/src/sys/dev/ath/if_ath_tdma.c:161: error: 'ATH_ALQ_TDMA_TIMER_SET' undeclared 
(first use in this function)
/src/sys/dev/ath/if_ath_tdma.c:161: error: (Each undeclared identifier is 
reported only once
/src/sys/dev/ath/if_ath_tdma.c:161: error: for each function it appears in.)
/src/sys/dev/ath/if_ath_tdma.c:162: error: storage size of 't' isn't known
/src/sys/dev/ath/if_ath_tdma.c:171: warning: implicit declaration of function 
'if_ath_alq_post'
/src/sys/dev/ath/if_ath_tdma.c:171: warning: nested extern declaration of 
'if_ath_alq_post' [-Wnested-externs]
/src/sys/dev/ath/if_ath_tdma.c:171: error: 'struct ath_softc' has no member 
named 'sc_alq'
/src/sys/dev/ath/if_ath_tdma.c:162: warning: unused variable 't' 
[-Wunused-variable]
*** [if_ath_tdma.o] Error code 1

Stop in /obj/ia64.ia64/src/sys/LINT.
*** [buildkernel] Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2012-11-27 07:30:44 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2012-11-27 07:30:44 - ERROR: failed to build LINT kernel
TB --- 2012-11-27 07:30:44 - 4652.43 user 988.03 system 6285.40 real


http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.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 --- 2012-11-27 04:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca
TB --- 2012-11-27 04:40:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2012-11-27 04:40:00 - starting HEAD tinderbox run for i386/i386
TB --- 2012-11-27 04:40:00 - cleaning the object tree
TB --- 2012-11-27 04:40:00 - checking out /src from 
svn://svn.freebsd.org/base/head
TB --- 2012-11-27 04:40:00 - cd /tinderbox/HEAD/i386/i386
TB --- 2012-11-27 04:40:00 - /usr/local/bin/svn cleanup /src
TB --- 2012-11-27 04:42:57 - /usr/local/bin/svn update /src
TB --- 2012-11-27 04:43:28 - At svn revision 243595
TB --- 2012-11-27 04:43:29 - building world
TB --- 2012-11-27 04:43:29 - CROSS_BUILD_TESTING=YES
TB --- 2012-11-27 04:43:29 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-11-27 04:43:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-11-27 04:43:29 - SRCCONF=/dev/null
TB --- 2012-11-27 04:43:29 - TARGET=i386
TB --- 2012-11-27 04:43:29 - TARGET_ARCH=i386
TB --- 2012-11-27 04:43:29 - TZ=UTC
TB --- 2012-11-27 04:43:29 - __MAKE_CONF=/dev/null
TB --- 2012-11-27 04:43:29 - cd /src
TB --- 2012-11-27 04:43:29 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Tue Nov 27 04:43:36 UTC 2012
>>> 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 Tue Nov 27 07:44:46 UTC 2012
TB --- 2012-11-27 07:44:46 - generating LINT kernel config
TB --- 2012-11-27 07:44:46 - cd /src/sys/i386/conf
TB --- 2012-11-27 07:44:46 - /usr/bin/make -B LINT
TB --- 2012-11-27 07:44:46 - cd /src/sys/i386/conf
TB --- 2012-11-27 07:44:46 - /usr/sbin/config -m LINT
TB --- 2012-11-27 07:44:46 - building LINT kernel
TB --- 2012-11-27 07:44:46 - CROSS_BUILD_TESTING=YES
TB --- 2012-11-27 07:44:46 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-11-27 07:44:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-11-27 07:44:46 - SRCCONF=/dev/null
TB --- 2012-11-27 07:44:46 - TARGET=i386
TB --- 2012-11-27 07:44:46 - TARGET_ARCH=i386
TB --- 2012-11-27 07:44:46 - TZ=UTC
TB --- 2012-11-27 07:44:46 - __MAKE_CONF=/dev/null
TB --- 2012-11-27 07:44:46 - cd /src
TB --- 2012-11-27 07:44:46 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Tue Nov 27 07:44:46 UTC 2012
>>> 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
[...]
   ^
/src/sys/dev/ath/if_ath_tdma.c:171:3: error: implicit declaration of function 
'if_ath_alq_post' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
if_ath_alq_post(&sc->sc_alq, ATH_ALQ_TDMA_TIMER_SET,
^
/src/sys/dev/ath/if_ath_tdma.c:171:24: error: no member named 'sc_alq' in 
'struct ath_softc'
if_ath_alq_post(&sc->sc_alq, ATH_ALQ_TDMA_TIMER_SET,
 ~~  ^
5 errors generated.
*** [if_ath_tdma.o] Error code 1

Stop in /obj/i386.i386/src/sys/LINT.
*** [buildkernel] Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2012-11-27 07:54:34 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2012-11-27 07:54:34 - ERROR: failed to build LINT kernel
TB --- 2012-11-27 07:54:34 - 8334.95 user 1482.90 system 11674.29 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 i386/pc98

[FreeBSD Tinderbox]

TB --- 2012-11-27 04:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca
TB --- 2012-11-27 04:40:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2012-11-27 04:40:00 - starting HEAD tinderbox run for i386/pc98
TB --- 2012-11-27 04:40:00 - cleaning the object tree
TB --- 2012-11-27 04:40:00 - checking out /src from 
svn://svn.freebsd.org/base/head
TB --- 2012-11-27 04:40:00 - cd /tinderbox/HEAD/i386/pc98
TB --- 2012-11-27 04:40:00 - /usr/local/bin/svn cleanup /src
TB --- 2012-11-27 04:43:57 - /usr/local/bin/svn update /src
TB --- 2012-11-27 04:44:12 - At svn revision 243595
TB --- 2012-11-27 04:44:13 - building world
TB --- 2012-11-27 04:44:13 - CROSS_BUILD_TESTING=YES
TB --- 2012-11-27 04:44:13 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-11-27 04:44:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-11-27 04:44:13 - SRCCONF=/dev/null
TB --- 2012-11-27 04:44:13 - TARGET=pc98
TB --- 2012-11-27 04:44:13 - TARGET_ARCH=i386
TB --- 2012-11-27 04:44:13 - TZ=UTC
TB --- 2012-11-27 04:44:13 - __MAKE_CONF=/dev/null
TB --- 2012-11-27 04:44:13 - cd /src
TB --- 2012-11-27 04:44:13 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Tue Nov 27 04:44:21 UTC 2012
>>> 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 Tue Nov 27 07:49:06 UTC 2012
TB --- 2012-11-27 07:49:06 - generating LINT kernel config
TB --- 2012-11-27 07:49:06 - cd /src/sys/pc98/conf
TB --- 2012-11-27 07:49:06 - /usr/bin/make -B LINT
TB --- 2012-11-27 07:49:06 - cd /src/sys/pc98/conf
TB --- 2012-11-27 07:49:06 - /usr/sbin/config -m LINT
TB --- 2012-11-27 07:49:06 - building LINT kernel
TB --- 2012-11-27 07:49:06 - CROSS_BUILD_TESTING=YES
TB --- 2012-11-27 07:49:06 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-11-27 07:49:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-11-27 07:49:06 - SRCCONF=/dev/null
TB --- 2012-11-27 07:49:06 - TARGET=pc98
TB --- 2012-11-27 07:49:06 - TARGET_ARCH=i386
TB --- 2012-11-27 07:49:06 - TZ=UTC
TB --- 2012-11-27 07:49:06 - __MAKE_CONF=/dev/null
TB --- 2012-11-27 07:49:06 - cd /src
TB --- 2012-11-27 07:49:06 - /usr/bin/make -B buildkernel KERNCONF=LINT
>>> Kernel build for LINT started on Tue Nov 27 07:49:07 UTC 2012
>>> 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
[...]
   ^
/src/sys/dev/ath/if_ath_tdma.c:171:3: error: implicit declaration of function 
'if_ath_alq_post' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
if_ath_alq_post(&sc->sc_alq, ATH_ALQ_TDMA_TIMER_SET,
^
/src/sys/dev/ath/if_ath_tdma.c:171:24: error: no member named 'sc_alq' in 
'struct ath_softc'
if_ath_alq_post(&sc->sc_alq, ATH_ALQ_TDMA_TIMER_SET,
 ~~  ^
5 errors generated.
*** [if_ath_tdma.o] Error code 1

Stop in /obj/pc98.i386/src/sys/LINT.
*** [buildkernel] Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2012-11-27 07:56:41 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2012-11-27 07:56:41 - ERROR: failed to build LINT kernel
TB --- 2012-11-27 07:56:41 - 8542.04 user 1483.94 system 11800.47 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"